IoT Cookbook Part II: Sensor Fusion to Bus Modeling

IoT system-level modeling and prototyping challenges are examined by ARM, Mathworks, Cadence, Synopsys, Analog Devices, Atrenta, and STMicroelectronics.
By John Blyler, Editorial Director
In Part I, master design “chiefs” shared how analog, sensors and wireless ingredients combined with available high-end bus structures like ARM’s AMBA to create deliciously innovative IoT embedded applications. In Part II, these same experts discuss the available system-level modeling and prototyping tools/techniques for the integration of sensor fusion devices with digital buses. As before, out master chiefs include Paul Williamson, Senior Marketing Manager, ARM; Rob O’Reilly, Senior Member Technical Staff at Analog Devices; Mladen Nizic , Engineering Director, Mixed Signal Solution, Cadence; Ron Lowman, Strategic Marketing Manager for IoT, Synopsys; Corey Mathis, Industry Marketing Manager –  Communications, Electronics and Semiconductors, MathWorks; Daniel Chaitow, Marketing Manager, Hillcrest Labs; Bernard Murphy, CTO, Atrenta; and Sean Newton, Field Applications Engineering Manager, STMicroelectronics. What follows is a portion of their responses. — JB
Blyler: What system-level modeling and prototyping tools/techniques are available for the integration of sensor fusion devices with digital buses? 
Williamson @ ARM: 2. Today, designers develop an RTL model of the analog peripheral and interface for use in system test bench development. To improve system level validation the digital portion of the peripheral can be emulated along with the Cortex-M and bus architecture using an FPGA. The radio or analog peripheral can be emulated in discrete analogue components to test system level functions prior to tape out.
Furthermore a simulation model can be written so the end-to-end signal path can be verified using a standard digital simulator. If a power aware simulator is used, a UPF description of the internals of the analog component can be created. Things like power up/down and isolation of the analog peripheral can then be modeled so that behavior in a real chip can be verified in systems with power domain splits that cross the analogue/digital boundary. For integration into a digital system (of any kind) the user needs to have access to other models of the analogue sensor or component. Static timing models, for example, (.lib or .db) are essential in order to guarantee operation of the analogue/digital interface as well as the digital interface to the bus system.
O’Reilly @ Analog: In addition to the other ultra-low power (ULP) challenges mentioned in Part I, a flexible interface is needed. I2C and SPI have been available for decades and widely used in many IoT approaches, however the I3C from MIPI Alliance will address some of the limitations of I2C and SPI. Design teams today use a variety of simulation environment tools such as Simulink, System Verilog, and SystemC to model the sensor and data interface, for complete system architecture exploration and validation. 

Nizic @ Cadence: From a design methodology point of view, Real Number Modeling (RNM) brings significant advantages by enabling sensors and other analog components to be included in virtual system prototyping and functional verification based on mixed-signal simulation. RNM model generation and validation tools help designers and verification engineers create models in friendly schematic environment without having to write code and ensure the models represent spec or actual circuit with required accuracy. Further, these RNM models are used to verify complete system including all hardware components and software in many different scenarios achieving high coverage. The same platforms can typically be used for bus protocol verification available for ARM AMBA® and other protocols.
Lowman @ Synopsys: EDA tools companies provide development and IP prototyping kits in applications that require real-time control such as automotive engine control, but can be leveraged for any sensor and control application. A validated IP configuration can be easily modified to explore design tradeoffs for the target application. Development kits enable hardware engineers to start work immediately and achieve the best performance without multiple iterations. From a software development perspective, these IP-based development enviornments provide immediate boot-up, and early software bring-up, debug and test to ensure high quality, all before silicon arrives. 
Mathis @ Mathworks: With the availability of new FPGA based SoCs, embedded engineers can now prototype their hardware-software designs more rapidly than ever before. By targeting these devices directly from an environment like Simulink which is fully integrated with SoC prototyping platforms for both software and hardware workflows, SoC architects can implement their hardware based signal processing designs by generating HDL, and at the same time, generate C code to program an ARM with the software-based design components. Using FPGA-in-the-loop (FIL) and Processor-in-the-loop simulation (PIL), the simulation and implementation models can be compared, and designs can be iterated and optimized for functional adequacy, design accuracy, and system performance. Further, functional representations can be exported with appropriate digital representations or mixed-signal interfaces, enabling designers to assemble and perform complete system simulations including analog sensors in standard EDA workflows.
Murphy @ Atrenta: ARM reference boards are probably one of the better starting points, though Samsung recently released a digital watch with replaceable sensors, which looks like an interesting starting point for a hobbyist. In theory System-C Analog Mixed Signal (AMS) should be a good system-modeling flow.
Newton @ ST: Most of today’s marketplace for standard 9-axis sensor fusion systems use I2C, SPI or UART to connect processing devices to the sensors. The ability to calculate sensor fusion requires a central processing unit, memory and interface circuitry to the sensors to produce the orientation vectors. Pure modeling can be done with standard mathematical analysis tools such as MatLab. Once algorithms have been tune, additional modeling can be done on the digital device using known inputs – test vectors – and the desired results compared to those produced by the mathematical analysis tools. Connecting the analog devices will introduce variation in the outputs of the sensor fusion algorithm due to natural variation and noise contained in the analog sensors.
Along with the this variation and noise, bus latency and sensor digital update rates must also be taken into account. This will result in a deviation between theoretical and actual results. With analysis of this deviation, modification of the sensor fusion algorithm can occur. Techniques such a calibration, filtering and fine tuning of control loops will assist in tightening the actual results to the theoretical. Most sensor update rates are slow compared to modern bus speeds – perhaps as high as 200-400 Hz. So the actual bus transfer mechanisms may not present much of an effect on the overall sensor fusion calculation as the communication speeds are low compared to device processing and internal bus speeds.