 |
 |
|
|
Functional- and behavioral-level simulators allow the use of sophisticated data and control representations. This class offers the highest performance but the connection to the implementation that ultimately emerges is not always obvious and is even more rarely automatically generated. Functional-level simulators may use the same logic values as logic-level simulators, or may allow more sophisticated data representations (such as integers). Circuit elements are modeled as functional blocks that correspond to the architecture's hardware functional blocks. Behavioral-level simulators allow sophisticated data representations and model only the behavior of a design. The partitioning of the behavior into pieces may not directly map to isolatable hardware functional units.
Functional- and behavioral-level simulators are similar, differing chiefly in that functional-level simulators map functional units onto actual hardware units [Insinga; Lathrop and Kirk; Frey; Lightner et al.]. In both approaches the design consists of a number of units that have behavior that is specified by the designer.
In a functional-level simulator, the structure of the behavior (what units are connected to what other units, the signals entering and leaving a unit) of each unit duplicates the intended hardware structure. Behavioral-level simulators seek to mimic the behavior of the intended design, but not necessarily in precisely the same way that the hardware will implement it. Functional-level simulators might be thought of as the generalization of gate-level simulators, where the design can contain user-defined gates (the function boxes). Sometimes high-level data representations are allowed; for example, ones that show integers as single entities rather than as a collection of bits.
Often the behaviors of computational units in this class of simulator are specified in a simulation language that is similar to a modern programming language. This technique offers good performance and ease of experimentation, but is also far from the actual hardware implementation and therefore cannot catch many types of low-level errors.
Simulating at a higher level of abstraction usually allows the inclusion of more of the design for a given amount of computation time. This gives the designer confidence in the correctness of the design as a whole. The drawback is that subtle errors can be missed because of the lack of detail; for example, race conditions may well be detectable only by a circuit-level simulation. This is a consequence of the fact that the link to the underlying implementation technology becomes progressively weaker as the simulation moves to higher levels of abstraction.
It is useful to be able to simulate part or all of a design at varying levels of abstraction. For this reason, several multilevel simulators have been developed that allow different parts of the design to be simulated at different levels [Insinga]. Sometimes the level of simulation can intermixed in the course of the same simulation run; for example, 49 of the instances of a buffer might be simulated at the switch level, whereas the fiftieth is simulated at the circuit level. Presumably, all instances would produce the same behavior so that the expense of simulating 49 of the instances in detail is avoided.
Other simulators mix two or more computational techniques at the same level of abstraction [Chen et al.; Lathrop and Kirk]. These mixed-mode simulators achieve improved performance by the dynamic, judicious choice of algorithms.
The impossibility of exhaustively simulating a design means that the quality of the verification process is ultimately limited by the designer's patience and the available computer time.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |