Chapter 4 Testbench Models

Verification has become as expensive and as important as design and as such, models and languages for verification are emerging that are highly directed towards their intended function. Most of what we think of as verification today is implementation verification taking place at the RTL level of abstraction, or physical verification taking place at even lower levels of abstraction. Very little of the total verification effort goes into design verification. To put that another way, we spend most of out time verifying that we have implemented something correctly, rather than determining that we have specified the right thing, or that the collection of pieces that are being assembled are capable of performing the right function within the constraints imposed the specification.

ESL verification attempts to ensure that the functional specification is right and complete, and looks not just at the hardware piece of the system, but also at the software running on the hardware. It attempts to ensure that the architectural decisions that are being taken are correct. In short, verification should concentrate on the design choices that are being made at that point in the design flow. For ESL verification that means system level functionality, performance and providing the reference models that are to be used for the implementation verification.

In this chapter we will introduce the major languages that are in use today and how they are used to create reusable verification models. This includes some of the methodologies that define frameworks for how these models play together to make complete testbenches.

A testbench is not a single model, or even a collection of models. It is a group of diverse models that, in conjunction with a set of tools, enables an act of verification to be performed. It is not possible, with the technology that exists today, to perform complete verification, and thus the goal is one of minimizing the risk of a serious bug escape while keeping to various budget constraints, such as manpower, size of server farms or elapsed time. In this chapter we will examine some of the more common models that make up a verification environment, but it should be understood that there are many ways to put these together to help perform the task of verification.

4.1 Testbench basics
     4.1.1 Testbench components
     4.1.2 Verification Methodologies
     4.1.3 Verification IP
4.2 Verification Plan
4.3 Comparison Model
     4.3.1 Testbench Languages
4.4 Progress Model
     4.4.1 Ad-hoc metrics
     4.4.2 Structural metrics
     4.4.3 Functional metrics
     4.4.4 Coverage metrics in SystemC
     4.4.5 Coverage Metrics in SystemVerilog
4.5 Input Constraints
4.6 Verification IP
     4.6.1 VIP Components
     4.6.2 VIP standardization
4.7 Conclusions
4.8 References

Errata

Feedback