The needs of the various stakeholders in the design chain can be addressed with three different levels of accuracy: (1) LT modeling with very limited timing; (2) AT modeling, which offers flexibility in trading off accuracy and speed; and (3) cycle-accurate modeling (Fig. 4).
LOOSELY TIMED MODELING
For pre-silicon software development and integration, the LT modeling style offers the right amount of speed to satisfy software developers. Timing accuracy is limited, but the models of the virtualized hardware are fully registered and functionally accurate, enabling the same software image to run on the virtual platform as on the actual target hardware, i.e., binary compatibility.
Beyond actually modeling hardware execution, in the application view, or AV (Fig. 4, again), software function calls—like Open GL high-performance graphics API calls—are intercepted and passed on to the host OS, where they’re executed as native calls. This works well for application development, requiring less-detailed hardware models and abstracting the system at the OS API level.
To achieve higher simulation speed, each process in LT model simulation runs ahead to a simulation boundary called a quantum. The simulation time-stamp advances in multiples of the quantum. Deterministic synchronization between processes requires explicitly coded synchronization. The larger the quantum size chosen, the less overhead of scheduling between processes is required. SystemC offers a pre-defined keeper function for the user-configurable quantum. For more detailed debugging, the quantum can be made smaller, and for higher speed, its value can be increased. Processes can check their local time against the quantum and synchronize, if necessary.
Combined with the LT coding paradigm, the direct memory interface (DMI) avoids the expensive traversing of bus hierarchies when accessing data and instructions from memory. DMI gives initiator modules a direct pointer to memories in a target. For instance, instruction-set simulators (ISSs) can bypass the sockets and transport calls, and have read or write access to the memory by default. Extensions may permit other kinds of accesses to enable security modes. In addition, SystemC defines delay and side-effect-free debug access to memories.
APPROXIMATELY TIMED MODELING
For architecture exploration and real-time software development, the AT modeling level is an appropriate level of abstraction. It offers a flexible tradeoff between accuracy (by way of timing annotation) and speed, and reduces the overall model-creation effort, allowing for a broader and earlier exploration of the design space. In the AT coding style, each process is synchronized with the SystemC scheduler, and delays can be defined accurately or approximately.
In addition to simulation synchronization, SystemC defines a user-extendible base communication protocol for AT modeling. Four standard phases mark the beginning of a request, the end of a request, the beginning of a response, and the end of a response. With the associated timing parameters, the delays for accepting a request, for the actual latency of the target, and for the delay to accept the response can be precisely modeled.
CYCLE-ACCURATE MODELING
For system verification and timing validation, cycle-accurate models are the most suitable solution. However, they run slowly and are available later in the development phase because their development effort mirrors that of the RTL code used for the hardware development. In the past, cycle-accurate models were often developed as independent C models.
More recently, vendors have realized that it’s simply too costly to develop, verify, and maintain cycle-accurate C models to be economically feasible. They now recommend using automatically created C models from RTL or FPGA prototypes connected to the virtual world using high-speed transaction-level interfaces. The recent divestiture of ARM’s SoC Designer to Carbon Design Systems is an example of that trend.
In addition, the other abstraction levels can still be combined with RTL, resulting in a mixed abstraction-level simulation, to contribute to the overall verification effort. For instance, this allows embedded software to be included in the verification flow, enabling early hardware/software co-verification.
THE OUTLOOK FOR TLM-2.0
The standardization of the SystemC TLM-2.0 APIs has already had a profound impact on the virtual-platform market. All major industry players have endorsed SystemC TLM-2.0 APIs as the interconnect API best suited to assembling virtual platforms. With models now being truly interoperable, a restructuring has begun of the virtual platform offerings into interoperable libraries, simulators, and authoring environments. The structure of the Synopsys offerings in this space is a good example. The DesignWare System-Level Library, which has more than 100 TLM-2.0 based models, can be used in any SystemC TLM-2.0 simulator. The Innovator SystemC Integrated Development Environment (IDE) focuses on improving authoring and integration productivity. It offers not-yet-standardized capabilities like virtual and real I/O, performance profiling, register configuration, and debug interfaces.
Further restructuring of the tool landscape will likely occur as the connections of system-level design and verification strengthen and transform traditional hardware verification itself. In a recent survey, conducted by Synopsys at DVCon 2009, more than 50% of verification engineers stated that they’re already using software running on embedded processors in their design to verify the surrounding hardware. Verification trends of this nature may potentially trigger development of innovative tools spanning the hardware and software domains.
Reprints
