Unlike density-driven IC design, system design is primarily propelled by diverse functionality demands. Many of today's system designs include analog, digital, electromechanical, and software components. Historically, system-level designers verified their designs by building a physical prototype. But many of them can no longer afford this luxury. In general, physical prototypes are a time-consuming, expensive, and difficult way to complete a project. Thus, virtual prototyping is becoming a necessity (Fig. 1).
Depending upon whom you ask, the term "virtual prototyping" has a number of different meanings. In the context of system verification, it means building an executable model of a design for simulation (Fig. 2). That model is used to verify and test various elements of the entire system design without actually committing any part of the system to hardware.
A pager is a good example of a system that benefits from virtual prototyping. It has digital and analog circuitry, an RF circuit, and a processor running software, as well as mechanical components such as a vibrator and keypad. Building an accurate physical prototype for a pager is a complex problem. Constructing that prototype to run at speed is even more difficult—if not impossible.
Physical prototypes have a number of drawbacks. For starters, debugging them is more cumbersome and difficult than it might be for a virtual prototype. Designers must devise some sort of lab setup, including various instruments to both stimulate the design and capture and analyze results. If problems are discovered, they must be isolated using different probing techniques. Problems are then fixed by modifying the physical prototype. At best, this process is very time consuming and frustrating.
In a virtual environment, everything is much less difficult. It's rela tively simple to look at a particular register value. Designers can set up the simulation environment to monitor a value with a command such as, "monitor register a." A window will then display the contents of that particular register.
Setting up equipment to capture register values in the physical domain can be tough. Signals may be completely inaccessible if they're internal to a component on the prototype. Because designers can't access these signals directly, it essentially becomes a guessing game. The designer may suspect that a certain part is faulty, replace that part, and determine if the system works properly—and repeat the process several times, if necessary.
When problems are found, it's hard to make modifications to the physical prototype. Designers may have to physically remove one or more components, put new ones in, and then properly rewire those parts. Furthermore, if the prototype is a printed-circuit board, it may mean having to re-route the board.
It's a minor task to replace logic or circuitry with alternative circuitry in the virtual environment. Just replace a model or modify a schematic or hardware-description-language (HDL) file. These issues, combined with today's ever-increasing time-to-market demands, make it tremendously challenging to build an accurate physical prototype.
In contrast, the verification process can be completed faster and with greater detail using virtual prototypes. Designers can move from concept to verified implementation in less time. Plus, making modifications to a virtual prototype is much simpler because the designer only needs to modify a model—not an actual piece of hardware. Even the iteration loop of finding and fixing problems is faster.
This process also tends to be more thorough—a trait that's a byproduct of the verification performance. Designers are likely to do more verification because they have the time, since they move through the design process more quickly. They even can use special-purpose tools that indicate how thoroughly they've performed verification. For example, code-coverage tools can determine how much of the design is actually exercised. In the physical domain, there's no comparable way to measure completeness.
The virtual-prototype debugging environment also is more robust. Designers can debug graphically, probe internal signals more easily, see registers, and watch events happen dynamically as they run an application. And they can easily do tradeoff analysis. They can explore the effects of replacing one portion of a design with some other circuitry or see the results of using an alternative processor in a relatively short period of time. Compare that to the complexities of changing a processor in an actual physical system.
Working virtually, designers can verify systems before all of the physical system components are available, as long as there's a model of those components (Fig. 3). The design team doesn't have to be held up waiting for an ASIC to be fabricated. Software developers can start developing software for a system right away.
Normally, the process is a serial one: Design the hardware, debug it, and then hand it off to a software team for application development. In theory, virtual prototyping can cut product development time significantly by giving software programmers a prototype up front in the design cycle.
It also can help refine ASICs or other custom parts before they're built. As previously stated, an ASIC is often constructed and debugged before any software is written for the system. If problems are found once the system is built, it may be too expensive to go back and modify the physical hardware even if that approach is the best solution.
The design team may have to compromise and implement a software-based fix or some other type of work-around. Designers working in a virtual environment don't need to make those types of compromises. They can implement the hardware change without drastically impacting the bottom line.
Reprints
