Bridging System Domains
The simulator interface provides a bridge between dissimilar domains. Interfacing techniques vary, depending on which domains are being linked. For mixed digital-analog simulation, for example, there are ways of mapping the discrete values of an HDL simulator (ones and zeroes) into the continuous representation of the analog domain.
The process is analogous to that of a digital-to-analog converter. On the other side of the interface, an analog-to-digital converter of sorts maps analog values, such as threshold voltage, into discrete values. Such mapping raises many issues in terms of accuracy and implementation details, like how to represent the digital concept of an unknown signal value in the analog domain.
Difficult mapping issues exist between other domains as well, such as analog-to-RF or digital-to-mechanical. Some of these can be significantly more complex than the digital-to-analog example just discussed.
Consider that typically, a mechanical simulation is a static solution. It's usually a solver-based approach that includes a representation of a mechanical component and a system of equations that solve for a particular parameter. For a hard-disk drive with a voltage-controlled armature, the equations may determine how fast the platter is rotating when driven at a certain voltage level.
Or, if a digital input directs the drive to a certain location of the disk, the equations may solve for how much time the drive needs to get to that point. Mechanical analysis generally doesn't include a concept of time-based simulation. Yet for virtual prototyping, the mechanical simulation must interface with time-based analog or digital algorithms.
EDA vendors must develop the necessary mapping techniques. Today, the limited solutions that interface two domains are merely a subset of the overall problem. Obviously, to do a full system-level verification, they'll probably be more involved than mixing two different types of simulation. Interfaces are needed between all of the possible algorithms, because a system design may contain any combination of domains.
Possible Solutions
In spite of all the difficulties and missing pieces associated with a virtual-prototyping environment, designers can take measures right now to begin implementing such a methodology. Using existing tools, they can certainly verify subsections of the system independently. They can then manually look at the results, assemble all of the subsections together, and verify that they will interoperate correctly by employing the results from one section as a stimulus for another. This would, of course, require the time to convert data from one domain's format to another—for example, manually converting analog waveforms to discrete digital values. These manual approaches, however, preclude the possibility of running application software on the virtual system.
Designers also have the opportunity to modify their existing environments to better accommodate virtual prototyping. Utilizing files and scripts to bridge the analysis of various domains, they can develop their own interfaces. Some design teams write their own interfaces that allow them to capture data from one simulator, re-format it, and provide it as an input automatically to another simulator. This approach creates a somewhat loosely coupled environment. It also requires a lot of work, and is only effective in some cases.
It's difficult, for example, for a team to write the interface if they're verifying a system with a tight analog-digital feedback loop. That mapping gets cumbersome when done manually because of the close interaction between the two sections. These homemade scripts can be generic, but tend to be customized toward the particular system being verified.
It's really the EDA vendors that need to develop the virtual-prototyping environment for designers. They don't necessarily need to scrap existing interface software, but rather build upon some of the existing solutions.
Difficulties arise because the expertise and algorithms involved in solving domain-specific problems tend to come from different sources. For example, an EDA vendor may have expertise in RF simulation, but not know much about mechanical analysis. Creating an integrated virtual-prototyping environment potentially requires bringing together multiple organizations.
The ideal environment doesn't consist merely of interfaces between simulators. It also needs some overall control mechanism. The verification system must be more than just boxes interacting. Some high-level control of the environment has to make sure all simulation and data is properly synchronized. In addition, the virtual-prototyping environment must support the team-based efforts inherent in system design.
Future system designs promise to become even more complex and diverse. Design teams, faced with Herculean verification tasks, will no longer have the time or resources to build physical prototypes. EDA vendors must develop the tools to create a viable virtual-prototyping environment. To do this, they can build upon existing and proven technology. The environment must offer high performance and be easy to use and well integrated with other tools in the design flow. Finally, for adoption of this methodology to be a success, designers must be educated about using the virtual-prototyping design process.