Development Techniques for Using Simulation to Remove Risk in Software/Hardware Integration

Reducing Risk

This section describes a number of techniques and suggestions that show how a co-development tool can be used to reduce risk. The ideas are listed in rough chronological order, but of course they can be used at any time in the product development cycle.

Design Phase
Since co-development systems are used to model entire boards, many of them include a library of components. The components typically include several different processors, often with several different levels of timing accuracy for each CPU. As well, the component library will include various memory types such as RAM, ROM and Flash, I/O peripherals, DMA and LCD controllers, and so on. System designers can use this component library to rapidly configure different boards to evaluate a variety of "what-if" scenarios. The results can be used to confirm basic timing and space requirements, such as how fast the processor has to be, or how much ROM or cache is needed. This approach is particularly effective for follow-on products that can use legacy code for the evaluation. Technology risk is reduced by validating that the basic design is sound.

Early virtual prototypes can also be configured to provide "mock-ups" of the final product. Even though the core functionality may not be complete, these mock-ups can be used to demo early views of the product. The feedback can be used to refine the product specifications, and reduces market risk by confirming that the product will meet customer needs.

Development Phase
The simulation environment together with the software is the current embodiment of the product specification. This reduces both technology and schedule risk by providing a continuous view into the current state of the project. Design solutions can be verified as they are implemented, and problems or changes can be fed back to the design teams. The revisions must then be incorporated back into the virtual prototype so that it continues to reflect the true state of the product.

Early in the development time-line, the simulator components and even software can be modeled at a high or abstract level. As product development progresses, more detailed validation is required. This can be achieved by replacing components with functionally similar but more detailed models. Of course, a process must be in place to validate the new models, but the changes should be transparent except for the slower speed. More detailed models achieve two goals: they provide more timing accuracy, which can be used to verify timing dependencies (or the lack of them); and they can provide more visibility for activities like performance analysis or debugging.

A difficulty with using more detailed models as the system evolves is that usually there is more software to run, so using a more detailed but slower model can make the system too slow. Some co-development tools offer dynamic component replacement, so that you can, for example, boot the RTOS on an instruction accurate pror effect: the RTOS is booted; the simulation state is saved; and subsequent runs can restore the saved state and continue on [3].

We should point out that while more detail in a model usually provides more visibility, there are still many analysis tasks that can be served by higher level, less time accurate, models. Examples of this are code coverage tests, profiling using basic block counting or PC sampling, and memory usage or tracing. A good co-development tool will provide visibility into the RTOS, and integrate this view with the software and hardware views. This allows one to examine things such as the effect of task priorities and monitor locks for hot spots.

Post Product Release
The usefulness of the virtual prototype does not end when the hardware arrives, or even when the product ships. This is because the highly integrated debug environment can provide correlations and insight that are just not possible with the real hardware. For example, it is easy to set breakpoints in ROM or Flash using a simulator. Being able to set trigger points on register, pin, or bus transitions makes it easier to zero in on a problem. Also, it is easier to generate instruction or memory traces non-invasively, and state save and restore makes it easier to execute repeated runs of a buggy section of code.