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

Hardware/Software Co-Development

A hardware/software co-development environment supports the early integration of hardware and software via functional or behavioral hardware simulation. The key advantage of this approach is that a virtual prototype of the board is available for software test and integration long before the physical prototype is available. By testing on the simulator, problems can be identified and remedied much earlier, the hardware/software teams can provide feedback and improvements, and the requirements and development progress can be tracked objectively.

Figure 1b) shows how the embedded product time line ideally changes when a hardware/software co-development environment is used. The initial concept and requirement specification stages do not change from the traditional model in Figure 1a), and similarly the software and hardware designs can begin simultaneously once the specifications are formed. At this point Figure 1b) shows a new Simulator Development step that is the basis for the early hardware/software integration. It is important to include this step in the time line, since even a very high-level simulation environment requires some engineering resources, and the simulator is now in the critical path of software test. While the physical prototype arrives at the same time in both the traditional and simulation assisted product cycles of Figure 1a) and 1b), the time to product release from this point is significantly reduced when co-development is used. The reason for this time reduction is that by the time the first physical prototype arrives the software and virtual prototype have been working together for some time - the moment of truth as the software boots for the first time is more of a yawner than a nail-biter. As well, many functionality related hardware bugs have already been reported and fixed, so the likelihood of needing a hardware re-spin is reduced. Proponents of hardware/software co-development report that time-to-market savings of 20 to 40 percent are typical [1].

Hardware/software co-development is actually one point in a spectrum of hardware/software integration and verification tools. Although terms and exact definitions vary, the full spectrum can be classified as follows:

Co-Design: refers to the functional decomposition of a product into its hardware and software sub-systems. Co-design environments help system architects decide which product features belong in software and which features should be placed in hardware. For example, if the product is a digital camera, a co-design tool can help evaluate whether the JPEG encoding algorithm should be done in hardware or software. Clearly, this sort of tool is of most use early in the product cycle. An example of a co-design tool is CoWare's N2Cä product.

Co-Development: refers to the simultaneous development of hardware and the software targeted for that hardware. The software is run on a simulation of the hardware, which is continuously and progressively refined to reflect the current hardware specification. For example, a product may involve the design of a new ATM chip. The simulator will typically model the entire board, including the CPU, the new chip, and any other peripherals. Initially, the ATM simulator may only support reading and writing registers from the CPU. As the project progresses, the simulator is enhanced to support interrupts and packet processing according to the ATM hardware specifications. The Cygnus simulator for the SONY Next Generation Playstation is an example of a co-development tool.

Co-Verification: refers to the validation of a hardware design by application software. Like a co-development environment, a co-verification tool is based on simulation, but typically the simulator is based on the HDL models that will be used to generate the actual hardware. In the ATM chip example above, a co-verification tool could use a high-level processor simulator coupled to an HDL simulator that would execute the VHDL/Verilog model of the ATM. Because of the slow speed but high accuracy of the HDL simulation, co-verification tools are typically used later in the product development cycle, just before the chip is taped-out for fabrication. Synopsys makes a co-verification tool called Eagleiâ.

Clearly, the domains of the three paradigms overlap. For example, a co-development tool could be used to study performance of an algorithm with or without floating point support, and a co-verification tool with high-level behavioral HDL models can be used for co-development. Still, since each tool is primarily targeted at a particular point in the product development cycle, they are tuned differently to optimize their respective goals.

Properties of a Co-development Environment
A co-development environment primarily targets software developers, which defines the goals and focus of the tool. The most important features of a good co-development environment are:

Transparency: To the extent required by the application, the simulator should model the functionality of the target hardware exactly. In a highly transparent system, the user cannot discern whether an application is running on the virtual or physical hardware (except for the speed at which it runs). This has a number of implications. Ideally, the same binary executable that runs on the simulator is also downloaded to the real hardware. This is important in order to minimize the risk in the transition from virtual to physical prototype when the real hardware is ready. (Risk would be introduced if the build or download procedure changed significantly from the virtual to the physical prototype.)

Having the same executable means that the target CPU is supported by the simulator, even if the software is developed on a different host platform, as is often the case. Not only must the CPU instructions be supported, but also the architectural structure of the processor, so that things like interrupts, protection modes, and MMUs, can be handled properly. This level of detail is necessary to boot the RTOS on the simulator. Also, the simulator must support the same memory map as the hardware, including memory and peripherals.

Visibility: While the simulator must be transparent with respect to functionality, it must also make the internal details visible for debugging purposes. The co-development environment must support full symbolic debugging of the simulated target CPU, and should include features such as breakpoints, stepping, and memory watchpoints. Profiling, memory and instruction tracing, and cache statistics are also easier to obtain on a simulated target than on the real hardware.

The best co-development environments will also integrate hardware information such as pin and register states of peripherals, and will even provide trigger points that stop the simulation when a particular pin or register assumes a specified value. Debugging capabilities are enhanced by correlating these types of hardware events back to the code that was executing at the time. We call this level of co-development an immersive environment, in that hardware and software visibility are completely and seamlessly integrated.

Performance: While the simulation environment must be functionally transparent, the demands of co-development dictate that the speed of simulation is critical. This is because the developers need to run either relatively large programs (for example, the RTOS and several simultaneous user applications) or relatively large numbers of small programs (for example, the test suite for a compiler or run-time library).

Often, these requirements mean that detailed timing accuracy is sacrificed so that higher performance can be obtained. For example, many HDL simulators can only achieve 1-100 simulated instructions per second. At this rate, it can take a week just to boot the RTOS! A high-level instruction set simulator (ISS) can generally achieve 1-5 million simulated instructions per second (MIPS), so the RTOS boots in only a few minutes.

We have found that the lack of timing detail does not affect the functionality of most software, so the bulk of the applications can be developed on a high-level simulator. As the product nears release, a more detailed simulator can be substituted for validation purposes. Still later, the project may switch to co-verification tools to guarantee the final product readiness.