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

Everett Lumpkin and Casey Alford

June 22, 2010

Everett Lumpkin and Casey Alford

Virtual prototype testability
Testability refers to the capability of the virtual prototype to self-check the firmware; and to allow testing where use of physical prototypes may be unsafe or inaccessible. Testing and development of a product requires putting the product through possible failure modes.

For some products, such as airbag deployment, testing normal operations in full context may require destruction of the end product. Just as model-based design has been used in other disciplines to test systems that are unsafe, or cost prohibitive, VPs allow this type of testing to be applied to embedded control systems.

In these cases, VPs can be particularly valuable to engineers even if real hardware is available. Using models to test destructive or dangerous conditions is not new to engineering.

In vehicle crash tests, for example, it used to be very common to have to crash many prototypes of the same vehicle to see how it might perform. Today, engineers perform initial and repetitive crash tests virtually without the destruction of an actual vehicle by using injected acceleration waveforms.

VPs bring this usefulness to embedded design, both in the early design phases and also late in the development stage where hardware and software have to be put through various potential failure modes.

Allowing engineers and verification personnel to run experiments in the virtual environment before committing to the physical product saves money and increases safety. Developers can then be assured the design will work prior committing to a real physical product.

Much more system insight can be gained by an engineer who is able to develop the target product in the context that it will be used. Take for example the graphic shown in Figure 9 below that shows the virtual world for an adaptive cruise control system. Access to the physical controller hardware doesn't make the development process easier.

Figure 9. The multi-vehicle adaptive cruise control system simulation allows validation in a multiple (virtual) vehicle context, and avoids expensive and costly design iterations.

Due to the size, cost, and complexity of the entire system (in this case several vehicles) most of the physical hardware firmware development takes place in isolation from the rest of the systems using a pre-generated set of test vectors. While the engineer knows if changes to the code will pass the pre-set test cases, it is difficult to assess the change on the whole system.

In the virtual world, this type of in context development can be achieved much cheaper and safer. Once the design is refined and tested, it can simply be validated in the multiple (virtual) vehicle context, and avoid expensive and costly design iterations.

The only cost effective path forward for this level of development is virtual prototypes and the engineering value of the VP continues to be high even after the hardware becomes available. Simply put, in this case, the development with physical prototypes is impractical and a multiple vehicle grid simulation of virtual prototypes is capable of validating the design.

The second aspect of testability is the use of extensive warnings which monitor the execution of the firmware running across the MCU and ASIC simulation models. For example, an internal EEPROM/Flash peripheral model knows when it is in the write state and thus an intervening read of the same EEPROM/Flash block returns invalid data.

Internal to physical EEPROM/Flash devices, high voltages supply the internal memory cells during write sequences. During the several millisecond write state, data reads are not electrically possible.

The physical part offers no indication of the illegal read during a write condition, and incorrectly written firmware may compute critical algorithms using invalid data. In the VP, the model of the EEPROM/Flash memory is constructed to output a message under this invalid condition:

WARNING: EEPROM1 data read from address 0xXXXX while in the write state.

This message alerts the software engineer of the specification violation. This system problem due to the specification violation could easily remain latent in normal product development. The failure mode due to invalid data read often exhibits in an obscure way which makes debugging of the issue very difficult and time consuming.

The number of warnings provided in a peripheral or ASIC simulation varies with the complexity of the model. Typically 2 to 20 warning messages are included in each microcontroller peripheral or external ASIC model.

Many of these warnings monitor subtle requirements and caution statements in the specification. The software developer thus benefits as if an omnipotent field application engineer for the device were watching the code development.

The simulation essentially contains a FAE in the box which constantly checks the software execution for correct interaction with the hardware design. Without the aid of the warnings, the author may unknowingly violate requirements, potentially resulting in a quality or field return issue.

ASIC self-checks and have been known to detect split SPI (serial transmission) device transfer, a discrete pin left in an improper state to for device communication, or conflicts between two active drivers on the same schematic signal.