How to make virtual prototyping better than designing with hardware: Part 1

Everett Lumpkin and Casey Alford

June 22, 2010

Everett Lumpkin and Casey AlfordJune 22, 2010

Engineers embrace model-based design in many different disciplines associated with product development, for example, finite element analysis in mechanical engineering and circuit simulation for electrical engineering.


Modeling enables development before physical prototypes are available. It enables development that is not possible, or is very difficult, with the physical or actual product. Virtual prototyping of embedded hardware brings the model-based design paradigm to embedded system development.


The use of virtual prototypes prior to hardware delivery has well-documented benefits for architectural exploration, early software development, golden reference specifications, reduced silicon turns, and software/hardware co-verification. [5] This article focuses on the virtual prototype benefits after physical prototype availability. The Google Android Emulator is a well known example of how a VP delivers value even after silicon is available [3].


A successful virtual prototype (VP) of Electronic Control Units (ECU) has five key characteristics:


1) Provides for simultaneous verification of hardware and software (co-verification)


2) Consists of behavioral models of the CPU, peripherals and Application Specific Integrated Circuits (ASICs) that provide bench look and feel for the software programmer


3) Loads and executes the same executable image as the physical ECU


4) Executes target firmware no less than one order of magnitude slower than the physical hardware (20-200 million instructions per second), fast enough for software development.


5) May be aggregated into larger super-simulations of multiple ECUs and include sensor and actuator plant models


The increasing complexity in embedded software development, such as multiple cores and integration of external IP, conspire against the best software designers and push requirements for better verification tools in the implementation phases of software design and coding.


In addition to the increased functional complexity, automotive ECUs are now multi-sensor/actuator systems with network protocols that encompass entire vehicles or even multiple vehicles. Systems of systems, decreased package size, and hermetically sealed packages all reduce (or even eliminate) the visibility of the firmware.


In automotive, and many other industries, feature sets are now growing beyond one dedicated controller or subsystem and into distributed subsystems. VPs, when combined with models of devices under control (often called plant models), open the door for developers and verification engineers to work with the product in the context of the "full" system.


While there will always be the requirement to verify the performance of an actual system with the physical product, a virtual environment enables testing that may be very difficult or impossible to do in a repeatable manner.


Take for example someone who is developing an adaptive cruise control for a vehicle fleet. While the base target firmware can likely be brought-up in isolation, complete testing of the controller requires interaction with many vehicle mechanical and electrical systems.


Testing such systems with only a physical prototype can lead to very costly, and often dangerous, test procedures. Virtual environments of full vehicles allow developers to conduct tests and experiments that would be costly and dangerous on the real vehicle even after the hardware ECU is available.


A common misconception is that once the physical hardware is available all software development should switch to bench development and no longer use the VP. A more efficient and economical method uses the VP benefits of visibility, controllability, availability, repeatability and testability even when suitable bench hardware is available.


At the management and user level we also discuss the acceptability of VPs for software, systems, and verification engineering development environments. This paper makes the case that the VP is much more than a pre-hardware tool. The VP increases productivity and provides essential debug and test capabilities that complement hardware benches.


Giving developers more visibility
VPs provide many levels of visibility to the engineer. VPs can record signal changes, or even internal RAM modifications in a VCD (Value Change Dump) dump format, or other file output. VCD is an ASCII-based format commonly used by EDA logic simulation tools and may be viewed by various programs including GtkWave and SimVision.


Figure 1 below shows an example output of the viewer and illustrates a communication sequence between the Microcontroller Unit (MCU) and RF receiver IC in an automotive body controller.


Figure 1. An example output of the waveform viewer illustrating the communication sequence between the automotive body controller microcontroller unit and radio frequency receiver integrated circuit.


The protocol consists of reset markers, an opcode transmission of 0x0D7A (twice) followed by data transmission of 0x01C8 (also twice). Figure 2 below shows a detailed view of the entire communication sequence with a zoom-in on the five sections of the communication sequence.


Similar to the use of a storage oscilloscope, the VCD waveform allows easy comparison of the entire communication sequence. Because the simulation is deterministic, repeated captures are identical to previous ones allowing easy comparison of a small virtual hardware or algorithm change.


As shown in Figure 2 below, confirmation of the critical timing parameters and the addition of annotations are possible. VPs, even after hardware is available, open up this level of debugging without complicated and costly bench tools.


Figure 2. Detailed view of the radio frequency receiver to microcontroller communication sequence with a zoom-in on the five sections of the communication sequence.

To view an expanded image, click here


The large benefit of VCD traces is that simulation visibility also extends to the inner workings of the MCU, for example, the measurement of interrupt latency.


On the bench, it is often difficult, if not impossible, to measure the time from interrupt request assertion to the beginning of the actual software interrupt service routine. The inner workings of each ASIC (or SOC or FPGA) model are also created with special registers that provide visibility of the inner functionality.


A special register may be read-only (allowing visibility) or read/write (allowing visibility and control). For example, an accelerometer model may provide a writable register called "acceleration" that represents the applied force in units of gravity (Gs).


The test bench, via a GUI or automated scripts, will modify the acceleration register during simulation to represent vehicle deceleration. In another example, a power supply model uses special registers to display the contents of internal registers, computer operating properly status, as well as visual indicators of the output voltages of the ASIC.


While tracing of external data is possible with various test tools on the bench, the VP allows the software engineer access to the internal states of the hardware as well. The VP allows the engineer to quickly and easily access traces of internal signals and software events that are not visible on the bench and focus debug effort directly on the problem.


Communication messages are often abstracted to a transaction level that sends the entire message as a packet between models, primarily to increase simulation speed. Common automotive message formats such as Controller Area Network (CAN), Local Interconnect Network (LIN), Inter-Integrated Circuit (I2C) and Synchronous Peripheral Interface (SPI) protocols can all be expressed as transactions.


The transaction protocol retains transmission timing information. The higher level of abstraction increases simulation speeds and avoids implementation of shift registers and transmission of unnecessary information. In addition, it also provides an easier level of viewing of the data by the software engineer.


For example, instead of trying to decipher individual bits of a CAN message the software developer views the entire message as one piece of data. The underlying models of the MCU CAN controller correctly arbitrate the messages and emulate the bit by bit physical hardware layer.


As part of the abstraction, the VP may be commanded to display the communication messages between the MCU and the various ASICs, or to display the signal communications between the ECU and the user interface.


VPs include bus monitor instrumentation to record the SPI transfers when a chip select is active. For example, at the trailing edge of a chip select, the bus monitor buffer is output with a simple print statement resulting in a display such as:

MCU SPI to EE: 0x03 0x00 0x3C 0x00 0x00
EE SPI to MCU: Hi-Z Hi-Z Hi-Z 0x9F 0xFF


Intra-model checking requires advanced planning. As described previously, the communication interface for SPI is transaction based and is designed to communicate the phase and polarity from the master to the slave device.


Phase and polarity describe if the synchronous clock idles high or low, and also which edge shifts/samples the data. Improper phase/polarity SPI communications may work on the bench due to bus capacitance and hold times, but may fail when exposed to temperature, or part-to-part differences.


Because of the checking built into the slave ASIC devices, the virtual prototype has detected (and prevented release of) improper phase and polarity hardware/software configurations.



< Previous
Page 1 of 4
Next >

Loading comments...