VERIFICATION IN GENERAL

As designs increase in complexity, verifying their functionality consumes  more and more time and resources. Such verification includes implementing  a verification environment, creating a testbench, performing logic simulations,  analyzing the results to detect and isolate problems, and so forth. In fact, verifying one of today’s high-end ASIC, SoC, or FPGA designs can consume 70  percent or more of the total development effort from initial concept to final  implementation.

Verififi cation IP   

One way to alleviate this problem is to make use of verification IP . The idea  here is that the design, which is referred to as the device under test (DUT) for the  purposes of verification, typically communicates with the outside world using  standard interfaces and protocols. Furthermore, the DUT is typically communicating with devices such as microprocessors, peripherals, arbiters, and the like.   

The most commonly used technique for performing functional verification  is to use an industry-standard event-driven logic simulator. One way to test the  DUT would be to create a testbench describing the precise bit-level signals to  be applied to the input pins and the bit-level responses expected at the outputs.  However, the protocols for the various interfaces and buses are now so complex that it is simply not possible to create a test suite in this manner.   Another technique would be to use RTL models of all of the external devices forming the rest of the system. However, many of these devices  are extremely proprietary and RTL models may not be readily available.  Furthermore, s imulating an entire system using fully functional models of all of the processor and I/O devices would be prohibitively expensive in terms of  time and computing requirements.

The solution is to use verification IP in the form of bus functional models (BFMs) to represent the processors and the I/O agents forming the system  under test ( Figure 7-13 ).   

A BFM doesn’t replicate the entire functionality of the device it represents;  instead, it emulates the way the device works at the bus interface level by generating and accepting transactions. In this context, the term transaction refers  to a high-level bus event such as performing a read or write cycle. The verification environment (or testbench) can instruct a BFM to perform a specific  transaction like a memory write. The BFM then generates the complex lowlevel ( “ bit-twiddling ” ) signal interactions on the bus driving the DUT’s interface transparently to the user.   

Similarly, when the DUT (the design) responds with a complex pattern of  signals, another BFM (or maybe the original BFM) can interpret these signals  and translate them back into corresponding high-level transactions. (See also  the discussions on verification environments and creating testbenches below.) 

Verififi cation Environments and Creating Testbenches   

When I was a young man starting out in simulation, we created test vectors  (stimulus and response) to be used with our simulations as tabular ASCII  text files containing logic 0 and 1 values (or hexadecimal values if you were  lucky). At that time, the designs we were trying to test were incredibly simple  compared to today’s monsters, so an English translation of our tests would be  something along the lines of:  
At time 1,000 make the reset signal go into its active state.   

At time 2,000 make the reset signal go into its inactive state.   

At time 2,500 check to see that the 8-bit data bus is 00000000.   

At time … and so it went.   

Over time, designs became more complex, and the way in which they could  be verified became more sophisticated with the advent of high-level languages  that could be used to specify stimulus and expected response. These languages  sported a variety of features such as loop constructs and the ability to vary the  tests depending on the state of the outputs (e.g., “ If the status bus has a value  of 010, then jump to test xyz ” ). At some stage, folks started referring to these  tests as testbenches.

Insider Info  

To be a tad more pedantic, the term “ testbench ” really refers to the infrastructure  supporting test execution. 

The current state of play is that many of today’s designs are now so complex that it’s well nigh impossible to create an adequate testbench by hand.  This has paved the way for sophisticated verification environments and languages. Perhaps the most sophisticated of the languages, known by some as  hardware verification languages (HVLs), is the aspect-oriented e offering from  Verisity Design ( www.verisity.com ).   

In case you were wondering, e doesn’t actually stand for anything now, but  originally it was intended to reflect the idea of “ English-like ” in that it has a  natural language feel to it. You can use e to specify directed tests if you wish,  but you would typically only wish to do this for special cases. Instead, the concept behind e , which you can think of as a blend of C and Verilog with a hint  of Pascal, is more about declaring valid ranges and sequences of input values  (along with their invalid counterparts) and high-level verification strategies.  This e description is then used by an appropriate verification environment to  guide the simulations.

Analyzing Simulation Results   

Almost every simulator comes equipped with a graphical waveform viewer  that can be used to display results interactively (as the simulator runs) or  to accept and display postsimulation results from a value change dump (VCD) file.   Sad to relate, however, some of these tools are not as effective as one might  hope when it comes to really analyzing this information and tracking down  problems. In this case, you might wish to use a tool from a third-party vendor.