Simulation

Simulating embedded systems is challenging because they are heterogeneous. In particular, most contain both software and hardware components that must be simulated at the same time. This is the co-simulation problem. The basic co-simulation problem is reconciling two apparently conflicting requirements:
_ to execute the software as fast as possible, often on a host machine that may be faster than the final embedded CPU, and certainly is very different from it; and
_ to keep the hardware and software simulations synchronized, so that they interact just as they will in the target system. One approach, often taken in practice, is to use a generalpurpose software simulator (based, e.g., on VHDL or Verilog) to simulate a model of the target CPU, executing the software program on this simulation model. Different models can be employed, with a tradeoff between accuracy and performance:
_ Gate-level models These are viable only for small validation problems, where either the processor is a simple one, or very little code needs to be run on it, or both.
_ Instruction-set architecture (ISA) models augmented with hardware interfaces
An ISA model is a standard processor simulator (often written in C) augmented with hardware interface information for coupling to a standard logic simulator.
_ Bus-functional models These are hardware models only of the processor interface;
they cannot run any software. Instead, they are configured (programmed) to make the interface appear as if software were running on the processor. A stochastic model of the
processor and of the program can be used to determine the mix of bus transactions.
_ Translation-based models These convert the code to be executed on a processor into
code that can be executed natively on the computer doing the simulation. Preserving timing information and coupling the translated code to a hardware simulator are the major challenges.
When more accuracy is required, and acceptable simulation performance is not achievable on standard computers, designers sometimes resort to emulation. In this case, configurable hardware emulates the behavior of the system being designed. Another problem is the accurate modeling of a controlled electromechanical system, which is generally governed by a set of differential equations. This often requires interfacing to an
entirely different kind of simulator.
A. Simulation