With virtual platform simulation, developers can implement applications without resorting to hardware (see the figure). Development then can proceed prior to the availability of hardware. Additionally, it reduces the need for additional hardware platforms for programmers.
Such a development approach is typical for electronic-system-level (ESL) simulation vendors such as CoWare, VaST, Virtio, and Virtutech as well as other EDA vendors. But the degree of simulation can be critical to its effectiveness and efficiency.
EDA simulations at the register transfer level (RTL) can provide detailed electrical and timing analysis in addition to a simulated software runtime environment, but often at a significant cost in hardware, software, or execution speed. The level of detail typically means the simulation operates slower than the actual hardware.
On the other hand, software development doesn't usually need this level of accuracy. The simulation must be semantically accurate instead. Yet frequently, timing needs to be optimized to run the simulation as quickly as possible. This approach normally uses instruction set simulation (ISS).
Execution is so much faster than electrical level simulations, a simulated environment may run faster than the real hardware. Likewise, implementation optimizations such as the identification of idle loops can permit efficient, real-time simulation of multiple targets on the same host system. In fact, some vendors provide simulation support for entire networks.
Simply being able to run applications without hardware is a significant advantage, especially when system reconfiguration is necessary. Dragging some icons around and wiring them up with a mouse is significantly faster than plugging in power supplies and cables.
Even more important is the ability to debug applications on the simulated environment. One way is to use a native debugger running within the environment. Another is to link an external debugger to a debugging stub within the environment the same way it would be linked to a remote hardware platform using something like an Ethernet connection. Simulation allows for a third approach that often uses remote debugging.
In this instance, the simulator provides the debug stub. So from the application and operating-system perspective, the simulated environment doesn't have to be changed. That's a big advantage. Also, the simulator's debug support often exceeds the capabilities of the target hardware and what a native debugger has access to. For example, access to cache, pipeline, and other hardware states be may possible.
Likewise, access to a system's internal state is significantly more efficient than it is with external hardware. For instance, accessing a hardware platform's memory through JTAG is a relatively slow process, which is only a memory access away with a simulator. This can be one or two orders of magnitude faster than it is with hardware, making it feasible to perform analysis and display data in real time.
Breakpoints and tracing can be enhanced, and check-pointing a system is simply a matter of saving a file. In fact, saving the system state to a file and restoring it later provides key benefits in remote and cooperative debugging since anyone can use the simulator to continue the system's execution.
Tracing relates to saving lots of state information as well. Most environments support forward and reverse execution. With reverse execution, bugs can be detected. The program then can be stepped backward to see why the problem occurred. The more information that can be retained, the easier it is to figure out the problem.
The ability to move forward and backward in simulation time combined with check-pointing lets vendors support multiple execution trees. Execution can be restarted at a checkpoint, but the I/O changes with the different input from a simulated keyboard. Most products can collect multiple trees into a single file that can be exchanged with other developers looking into a problem.
The ability to restart a system from a saved state can save a lot of time. That's because it's now possible to save a known state—for example, after all applications are initialized—and enable designers to use the system from that point on.
Most of these products start out at about $100,000 per project for maybe a dozen developers. Still, they can cut costs by an order of magnitude or more.
Reprints
