System Design

Modeling Issues for Co-Verification

In lieu of any ideal modeling solution, one must plan a co-verification strategy that properly reflects individual design team priorities.

by Steven E. Schulz

In the ideal world, a universal co-verification environment might enjoy the following desirable characteristics: real-time code execution, support for any processor type, robust software debugging capabilities, support for IC/processor design and hardware system design, fast turnaround time, accurate timing information, accurate prediction of system behavior (with full compiled code), cost-effective verification environment, and avoidance of modeling/software development bottlenecks.

In lieu of any ideal modeling solution, however, we must instead plan a co-verification strategy that properly reflects individual design team priorities. In this article, we will summarize the major issues to consider.

Software execution speed Real-time requirements on external interfaces (e.g. networking applications) may not permit interactions to occur at simulated/emulated speeds. When only full-speed interaction is acceptable, then some physical hardware is probably necessary. In many cases, however, "near-speed" performance is sufficient, opening up several modeling options. This tradeoff becomes a necessity when no real processor exists, or exists only as a prototype board.

Software debugging needs In some design scenarios, it can be important to have access to the internal state of the processor (including registers, stacks, and program counters) to diagnose subtle errors in source code logic or algorithms. It can also be desirable to set breakpoints and override the values of registers as a means to greatly enhance the productivity of simulation time. Logic analyzers, source code debuggers, in-circuit emulators, and reverse assemblers are all useful tools; but the choice of hardware modeling approach can limit options.

Hardware debugging needs If the hardware under design is a new processor, then "internal" views of the model become a necessity. It may be critical to see how a conditional branch instruction responds when a non-maskable interrupt arrives, or find the source of a pesky floating-point division error. Oftentimes, however, a commercial off-the-shelf (COTS) microprocessor is being designed into a hardware system, where issues of general timing and external handshaking become more prominent than micro-architectural details.

Hardware computational domain Digital systems are based on one of several basic conceptual domains for delivering functionality. The synchronous dataflow model is typical of DSP applications, where the emphasis is on algorithmic conversion of input data to processed output form. The control flow model is typical with CISC, RISC and microcontroller applications, where the emphasis is on decision-making logic and programmed response to external events. A hybrid model of computation places roughly equal emphasis on both aspects, adding special challenges to prioritizing critical modeling needs in hardware-software co-design.

Existence of processor During system design, a COTS processor may not yet physically exist, forcing the use of emulated and/or simulated models for code execution. Nearly all IC design projects routinely deal with this constraint, although ASIC design utilizing embedded processor cores may find limited relief by running code on a plug-in (equivalent) processor during ASIC emulation.

Turnaround time Depending on overall design priorities, slow iteration time between hardware design changes may be unacceptable. Some modeling approaches require careful tradeoffs between turnaround time and other desired traits, such as code execution speed.

Interaction level The desired aspect of a design requiring focus is dynamic, based upon the highest perceived risks at any given point in the design cycle. The critical risk may be relatively abstract (as in algorithm validation) or highly specific (such as interrupt handshake timing). Each modeling approach has its own limits on visibility of the interaction of software with the surrounding hardware.

Processor/compiler co-design For modern RISC processors to take full advantage of pipelining and superscalar operation, optimizing compilers must carefully arrange the instructions and data operations. In this scenario, the compiler itself is the software under design, and no physical hardware exists--yet interaction is essential. Typically, the IC is modeled by its own specialized processor simulator that has scalable features (such as number of functional units, cache size, and bus width). A flexible, table-driven prototype compiler can then rapidly implement re-scheduled test code for any given architecture selection.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  August 1995