Next generation applications in logistics, robotics, automation, smart home and building, consumer and white goods, smart city and renewable energy require the adaption of smart and secure sensors with data connectivity. Existing semiconductor standard solutions often provide insufficient flexibility and missing software environment. The most critical item, however, is the missing inherent data security approach encompassing the complete value chain of the product.
Sensry is a newly established company offers an smart edge sensor construction kit with highly flexible and customizable hardware configurations according to customer requirements. The universal sensor platform USeP combines cutting-edge assembly and packaging technologies with new design methods as well as various integration possibilities for sensors.
|1.8V and 3.3V
|MRAM voltage reference
|Analog Subsystem voltages
|0.8V and 1.8V
|Maximum total power dissipation
Three different power domains and one reference voltage are required for the Ganymed® system.
|Low power operation clock/boot clock
|System reference clock(external oscillator)
|System clocks (internal)
|Generated from external clock via PLL,
as required for functional units
The CPU clock frequency can be set exclusively by the DAQU CPU core. All DPU cores operate at the same clock frequency (unless disabled), while the DAQU core frequency may be different.
All the internal clocks are derived from a single PLL operating at a VCO clock source of 2 GHz generated from an extern reference clock of 25MHz. Most of the internal clock dividers are configurable. The DAQU and the peripheral logic can be multiplexed into the 25MHz reference clock domain to provide basic functionality if the PLL and clock dividers are uninitialized.
The following table describes the standard boot values for the clock divider:
|Default Reset Value
|DAQU main SoC Clock
|Peripherals Clock (Including Ethernet)
|High-Speed SAR ADC Clock
|CAN-TRNG sample Clock
|Ultralow-Power SAR ADC Clock
|Delta Sigma ADC Clock
|Process Monitor Clock (not used)
|USB Ref. Clock (not used)
There are different types of volatile and non-volatile memories available on the Data Acquisition Unit (DAQU) and the Data Processing Unit (DPU) cluster. The different memories are accessible with different privileges in the memory map. External memory can be added via HyperBus interface in the Bottom-Level (PCB). Since the energy and performance cost of accessing external RAM over external buses is higher compared to the internal memory, generally this should be avoided as much as possible. In consequence, program code is loaded from external flash at boot into the DAQU SRAM.
The secure memory part is not accessible from normal user mode privileges. All MRAM parts are FlashMRAM which means it has an internal flash memory interface. The Memory Map gives an overview over the address space.
|Secure Boot ROM
|Only for DMA usage
|Only for DMA usage
|DPU Data Memory SRAM
|Tightly Coupled Memory
The processing core is based on the Open Source RISC-V instruction set architecture. The implementation consists of a Data Acquisition Unit (DAQU) which handles the wired and wireless communication, security features and memory and the Data Processing Unit (DPU) which consists of eight powerful RISCY processing cores with tightly coupled own memory and separate floating-point units. Additional several interfaces are integrated and distributed to the Top-Level and the BottomLevel. Figure 5 shows an overview of system interfaces and their connection to the different Levels.
The processing core is divided basically into a data acquisition unit (DAQU) which controls the interfaces, main memory security subsystem (see Figure 4 for the DAQU schematic overview) and the data processing unit (DPU). The DPU is part of the heterogeneous multicore system and includes eight independent RISCY cores with tightly coupled memory and dedicated floating point units to enhance the system to high performance calculation platform. The DPU is designed to process sensors data independently to the main core and exchange data due to a direct memory access (DMA) controller. This allows to implement computationally intensive operations and data preprocessing needed for Edge and Fog Computing approaches.
Beside the standard interfaces like JTAG for programming and debugging, several serial interfaces, GPIOs and the HyperBus for HyperRAM and HyperFlash memory extension, the device includes a powerful analog interface to adapt raw analog sensors. This includes several analog-to-digital and digital-to-analog converter and their matching circuits. The RGMII interface implements a set of IEEE 802 Ethernet sub-standards in order to provide an ethernet time sensitive network (Ethernet TSN) interface. The automotive interface CAN is implemented regarding the latest standard ISO 11898-1 with flexible data rate (CAN-FD).
Five reset modes are available. After reboot, the cause for the previous reset can be read from a status register during boot mode, except for power-on reset:
The watchdog reset can be issued by an internal watchdog controller.
The core chip has three different analog-to-digital conversion blocks to allow the processing of a wide range of sensor signals. Each block can be shut down individually for optimized power consumption. A high speed 25MS/s SAR ADC with four parallel sampled inputs is used to convert the multiplexed analog signals with a resolution of 12 bit. It may be used to convert up to 4 parallel sensor signals with 3 MHz bandwidth in normal operation mode or in fast mode a 12 MHz analog signal at channel 0. For ultralow power applications a 100kS/s SAR ADC with 11bit resolution is available for the conversion of sensor signals up to 50kHz. Finally, a high resolution 16bit delta sigma ADC is provided for audio signals up to 16kHz, allowing audio applications like sound activation or speech recognition.
The analogue channels are controlled by the digital controller. Output data is provided to the digital part via a register bank. The three different conversion blocks can run in parallel.
The fast 25 MS/s 12bit ADC is provided with a S&H stage which samples the four differential input signals x at the ADCx_VIN_P / ADCx_VIN_N interface (x=0 to 4) simultaneously. Then the sampled signal is multiplexed to the input of the 25 MS/s SAR ADC for conversion. After end of conversion, the 12bit output data is stored in a register to be read by the controller. This multichannel input block is intended for parallel sensors channels where a synchronous sampling is needed. The ADC run on a 500 MHz clock provided by the internal clocking block. However, in a fast mode the first of the four input channels can be selected permanently and an analog signal with a bandwidth up to 12,5MHz may be processed. All four input channels ADCx_VIN_P / ADCx_VIN_N interface (x=0 to 4) are specified for a differential input signal range of 0.4V +/- 0.3V, however they tolerate input signal levels from 0 to 0.8 Volt. Multichannel ultra sound or vibration sensors are one of the classes of sensors suitable for this block, due to its high frequency range. The digital result is provided in a 16bit frame – 12bit data, 2bit channel address, 2bit not used – to a FIFO register to be read by the controller on demand.
An ultralow power SAR ADC with less than 40µA is implemented, to allow the conversion of sensor signals up to 50kHz bandwidth in battery operated mobile applications, e. g. for audio stand by and wake up modes. Sounds from the environment are monitored in an ultralow power standby listening mode and after activation the USOC is awakened to its full performance. Further applications may include standalone intrusion alarm or energy harvesting based early anomaly detection in machinery. The ADC is directly connected to the analog inputs ADC4_IINVO / ADC5_IINVO interface. The inputs are specified for a differential input signal range of 0.4V +/- 0.35V, however they tolerate input signal levels from 0 to 0.8 Volt. The maximum ADC sampling rate is specified with 100kS/s. The ADC can be operated in continuous conversion mode and in single shot operation mode. The conversion clock of 1.25 MHz is provided by the clocking block.
A 16bit Delta Sigma ADC is implemented for high resolution analog signal conversion. It may be used in combination with the low power ADC in audio and speech processing applications where the former is utilized in standby mode and after sound or command wakeup the DS-ADC provides a highresolution audio signal to the digital processor. The ADC is directly connected to the analog inputs ADC0_IIN / ADC1_IIN pads. The inputs are specified for a differential input signal range of 0.4V +/- 0.3V, however they tolerate input signal levels from 0 to 0.8 Volt. A block diagram of the ADC is shown in the following figure.
A 2nd Order Delta Sigma Modulator is followed by a 64-tap decimation filter and a FIR Half Band filter. The filter with an order of 120 is designed for a 20 kHz Bandwidth as shown in the following figure.
The security-relevant aspects of the universal sensor platform consist of four key areas: the device state, cryptographic functions, watchdog timers, and system boot:
Figure 11 shows an overview of the hardware part of the security subsystem from a functional perspective. The chip key and key control and status registers (CSRs) are designed to be compatible with the Trusted Computing Group (TCG) Device Identifier Composition Engine (DICE) architectures specification.
The device states regulate the access to privileged information in the system. The device state consists of two parts: the life cycle and the run-time state. The life cycle state is persistent on the device, the run-time state will be initialized with every reset. Both states together controls read and write access to memory locations and CSRs. The level of access to sensitive information is determined by the device state.
In general, there are four different life-cycle states:
The allowed transition between the states is shown in Figure 12.
The run-time state primarily controls access to the chip key via the machine mode key (mkey). It is used by software, in its secondary function, to determine software access permissions. The Run-time state consists of four different states: evaluate, secure, non-secure, and security violation. It is a dynamic state, which is reevaluated at every reset.
Figure 13 shows the transition scheme between the four different states. The transit from one state to another, security conditions have to be fulfilled.
Cryptographic functions provided by the platform are divided into four categories: key management, device identification, accelerators, and secure non-volatile memory. They are summarized below:
Key management consists of two parts, the chip key in combination with the key CSRs and certificate slots. Key CSRs are used on the platform to store and use cryptographic keys. The mkey CSR makes the chip key — a device-unique key — available to machine mode software. The user mode key (ukey) CSR is an optional key CSR available to user mode software. Certificate slots are used on the platform to store certificates for secure boot and secondary purposes. The platform has two certificate slots, one for Universal Sensor Platform and customer certificates each.
The platform provides a set of cryptographic accelerators, listed above. They are only available to the main processor. Additionally, the system provide dedicated non-volatile storage for security-critical information, including cryptographic keys, configuration data, and software states. It is only accessible to machine mode software, but parts of it may be made available to user mode software through an Application Programming Interface (API).
A conventional watchdog timer consists of a timer with a software-configurable timeout interval. Once started, software can defer the watchdog timer to reset it to the specified timeout value. If the timer elapses and is not deferred, the device is reset by the watchdog timer.
The security-enhanced watchdog timer extends the conventional watchdog timer with a set of new requirements. Each requirement may be set to enforcing by software. However, the watchdog timer is only considered to be a security-enhanced watchdog timer if all requirements are set to enforcing.
The system boot process securely starts and initializes the Universal Sensor Platform. This process is performed by ROM software, which is the first software to run after a reset. It performs the necessary steps to load and verify software images on the platform as part of secure boot.
Secure boot uses certificates verify software and data. The secure boot mode configuration determines how the certificate chain is used in the secure boot process. It must be set during manufacturing by configuring the relevant entry in OTP memory. There are two modes, CA mode (optionally with enforce CA signature configuration) and legacy mode.
The following describes the individual steps of the secure boot process. All steps of the process are implemented in ROM software. A security violation is raised if an error occurs at any part of the secure boot process:
The Software Eco System consists of three parts:
Generally, the embedded software is running as a Real-Time-OS (RTOS) implementation which divides in a Machine-Mode and User-Mode (comparable to Kernel- and User-Mode on Linux based Systems). The two modes allow a different level of access to critical parts of the system. Figure 14 shows the general functionality of the API system.
The Sensor API controls the low-level communication and data transfer between the sensor and the system. An overview of the Sensor API is shown in Figure 15.
The Interface-API provides a socket-based communication to all interfaces. An overview of the Interface-API is show in Figure 16.
The CoreCom-API controls all operating system relevant features including management of the DPU cluster. This API initiate and controls “Tasklets” running independently on one of the DPU cores. The Security-API interfaces between the hardware security features and software.
The system in package (Top- and Mid-Level) will be manufactured in the supply chain of Sensry. The Bottom-Level can be manufactured by costumer or system integration partner of Sensry. The possible workflow is shown in Figure 2.
The device contains a strong security concept which allows to set-up trustful and reliable sensor data driven business models. The hardware integrated security core includes a secure one-timeprogrammable memory model for the device states, keys and certificates as well as cryptographic functions, security watchdog timer and a secure system boot process. The costumer deployed software must interact with these security features in order to fulfill the desired security standard. The security concept itself is explained in a different chapter.