Each solution involves a trade-off between different attributes such as iteration time, performance, capacity, debug visibility and cost. Even HDL execution engines require various solutions. Some perform better at the block level, others at the chip or system level. Conversely, in-circuit emulation will be inappropriate for verifying relatively small sub-blocks of a chip design if an HDL software simulator can accomplish the task. Identifying which tools are optimal for the given verification task and having them available will enhance design productivity.
The following are the available technologies for scalable verification:. It can also be used as a testbench for hardware verification. Support of increased reuse through transactionbased methods and high-level verification languages creates a more productive testbench methodology.
Emulation assures designers that their chip will function in an actual system.
Moreover, note that highperformance, hardware-assisted or hardware-oriented solutions are critical to achieve verification completeness in system-level environments. Aside from the ability to move between tools, it is important to maximize their productivity. This allows the verification process to stay within a single environment until there is an absolute need to move to another solution.
Scalability within tools can be demonstrated in different ways. For example, in regression testing, numerous tests might need to be run frequently. Most companies want this done overnight so problems are discovered and resolved in the morning or before doing another work. It is unlikely that a single simulator can provide enough performance to accomplish this large task in a reasonable time. A simulation farm, which allows many jobs to be queued and executed on any available machine, makes regression testing both easier and more feasible.
If very long runs are included in the regression suite, then conducting emulation may be necessary. A single emulator is scalable in itself because its capacity can be adjusted to accommodate various design sizes, provided the gate count fits within the emulator families' maximum capacity limitations. If necessary, capacity can be extended by connecting more than one emulator together.
Another example is formal equivalence checking. Equivalence-checking tools reduce the time or frequency of a regression run. However, these tools must be constructed to be memory-efficient, and to enable full-chip verification and regression. Relying on physical memory in a workstation to solve this is not an option. Simultaneously, equivalence checking must scale with the complexity of the designs, and when more processing power is required, multiple machines can be instructed to work together to have quicker regression runtime.
Another aspect of scalability within tools is particularly important in emulation. An emulator's performance is fairly constant with design size.
However, if a connection to a logic simulator is required, as in the case of behavioral testbenches, then performance will quickly degrade to more traditional simulator speeds. This range of solutions must also include high-speed, transaction-level interfaces to ensure efficient connection to the parts that must remain on a workstation. Such requires advanced synthesis techniques not limited by normal requirements of the design flow, but are built to provide good results for emulators.
Across levels of abstraction Over time, it will be essential to move some aspects of functional verification to the initial phases of the design process. Doing so has several advantages. Models at this stage are faster to write, have higher throughput and can constructively influence design decisions.
Working at this higher level of abstraction also improves the reusability of the testbenches. There comes a point where more abstract representations of the design become absolutely necessary. This is not just for the design but also for the testbench. System-level tests can be created and used to verify these abstract models. As the system is divided into hardware and software blocks, or the design hierarchy is refined, verification tools can help with the interfaces between them.
This allows each of the blocks to progress through time without waiting for all the blocks to reach the same level of abstraction before conducting verification. For a multilevel abstraction strategy to work, it must combine both technology and intellectual property IP. The models that enable designers to both switch between levels of abstraction and tie the levels together are essential.
Hierarchical verification is achieved using a set of transactors for the key interfaces of a design. This allows for a mixing of design descriptions at various levels of abstraction. The transactors are assembled as a testbench or an environment to check if an implementation matches a higher- level model. An advantage of this strategy is that it does not require all the models to exist at a single level of abstraction.
This flexibility allows the team to mix and match whatever is available at a given time and provide the necessary level of resolution relative to execution time.
Transaction-based interfaces can link abstract system models to the design, providing an ideal system-level testbench. For example, using transaction-based simulation, a team can define a system at a high level of abstraction. They then take single levels, or single blocks, within that high-level system definition and - using the IP required for the transaction to work - substitute them into a more detailed implementation model.
They can run the model on the system as an instant testbench.
The team immediately has real use of the existing testbenches, resulting in a natural stimulus provided to the block. The result is higher verifi- cation productivity and higher confidence in the design. Figure 5. Engineers create stimuli that they feed into an execution engine so they can analyze the response produced.
To support a scalable verification solution, debug tools must be integrated, consistent across levels of abstraction and consistent across scalability tools. The goal is to improve the speed at which bugs are identified, the cause tracked down and the problem fixed, thus minimizing feedback time and iteration loops. Today, over 50 percent of the time of both the design and verification teams is taken up with debug, and so improvements in this area promise a significant impact on time-to-market.
At the system level, debug is made more complex by mixed levels of abstraction and by the differing semantics that exist within a system. This becomes even more challenging within a heterogeneous environment, such as hardware and software or digital and analog. Thus, information must be made available in the correct semantic context and at the required level of abstraction.
For example, when debugging software, all of the information about the software program execution is contained within the memory of the hardware, and yet none of it is readily available. Identifying the location of the variable is just the start of the solution. The memory chip information and its relative address within the chip, assuming it is not in a cache or a register, must also be determined. Nonetheless, in many cases, the data is not in a logical order within the chip because of data or address interleaving.
New debug methodologies To address some of these challenges, new debug methodologies are being introduced such as assertions and checkers. Another area of consideration is coverage. Many engineers don't realize that satisfying code coverage metrics does not mean that the system has been adequately verified. Additional metrics, such as functional or assertion coverage, must also be used to ensure that the design is fully verified. Most engineers today create stimuli that they feed into an execution engine so they can analyze the response produced Figure 5, above.
In many cases, they compare the waveforms between one implementation of the design against a golden model, looking for differences. This is a tedious, hit-and-miss way to debug and leads to many missed mistakes. It is too easy to concentrate on the given problem, missing the fact that something else went wrong or that the current testbench did not reveal the new problem.
Designers must get away from the tedious, repetitive, blind-alley nature of most current debugging methodologies. In the later stages of the design process, equivalence checking can be a very powerful tool. Equivalence checking tests implementations against a golden model in a formal method, rather than comparing two sets of waveforms through simulation. New useful test bench components Recently, some additional testbench components Figure 6, below have matured to the point of usefulness, such as generators, predictors and checkers.
These allow test scenarios to be automatically generated and the corresponding results checked for legal behavior.
Figure 6. In traditional testbenches, the problem must be propagated to the output and must be detected. Checkers are the most mature of these, and of course, checkers are assertions. Two types of assertions exist: test-dependent and test-independent.
Test-independent assertions are easily inserted into an existing verification methodology without requiring additional tool support while test-dependent assertions coupled with generators require additional tools and methodology changes. It does not end there because several testbench components are not yet well-defined today, such as functional coverage, test plans and verification management. Though the completion of this testbench transformation is still some years off, once completed, an executable specification will be realized.