Introduction to Verification

Why Verification?
Features of Verification
Verification Process
Basic Testbench Functionality
Directed Testing
Testbench Componenets:
 Introduction
• There are several steps needed to verify a design: generate stimulus, capture responses, determine
correctness, and measure progress.

• But first, you need the proper testbench, connected to the design.

• Your testbench wraps around the design, sending in stimulus and capturing the design’s response.

• The testbench forms the “real world” around the design, mimicking the entire environment.

• For example, a processor model needs to connect to various busses and devices, which are modeled in
the testbench as bus functional models.

• A networking device connects to multiple input and output data streams that are modeled based on
standard protocols.
 Introduction
• A video chip connects to buses that send in commands, and then forms images that are written into
memory models.

• The key concept is that the testbench simulates everything not in the design under test.

• Your testbench needs a higher-level way to communicate with the design than Verilog’s ports and the

error-prone pages of connections.

• You need a robust way to describe the timing so that synchronous signals are always driven and sampled at

the correct time and all interactions are free of the race conditions so common to Verilog models.
 Separating the Testbench and Design
• In an ideal world, all projects have two separate groups: one to create the design and one to verify it.

• In the real world, limited budgets may require you to wear both hats.

• Each team has its own set of specialized skills, such as creating synthesizable RTL code, or figuring out new
ways to find bugs in the design.

• These two groups each read the original design specification and make their own interpretations.

• The designer has to create code that meets that spec, while you, the verification engineer, have to find ways
to prove the design does not match the spec.

• Likewise, your testbench code is in a separate block from design code. In classic Verilog, each goes in a
separate module.
 Separating the Testbench and Design
• However, using a module to hold the testbench often causes timing problems around driving and sampling, so
SystemVerilog introduces the program block to separate the testbench, both logically and temporally.

• As designs grow in complexity, the connections between the blocks increase. Two RTL blocks may share dozens
of signals, which must be listed in the correct order for them to communicate properly.

• One mismatched or misplaced connection and the design will not work. If it is a subtle bug, such as swapping
pins that only toggle occasionally, you may not notice the problem for some time. Worse yet is when you add a
new signal between two blocks. You have to edit not only the blocks to add the new port but also the higher-level
netlists that wire up the devices. Again, one wrong connection at any level and the design stops working. Or
worse, the system only works intermittently!

• The solution is the interface, the SystemVerilog construct that represents a bundle of wires, with intelligence
such as synchronization, and functional code. An interface can be instantiated like a module but also connected
to ports like a signal.
Communication between the testbench and
DUT
• The next few sections show a testbench connected to an arbiter, using individual signals and again
using interfaces.

• Here is a diagram of the top level design including a testbench, arbiter, clock generator, and the
signals that connect them.

• This is a trivial design, so you can concentrate on the SystemVerilog concepts and not get bogged
down in the design.
 Communication with ports
• The following code fragments show the elements of connecting an RTL block to a testbench. First is the
header for the arbiter model.

• This uses the Verilog-2001 style port declarations where the type and direction are in the header.

• Most of the code and declarations have been left out for clarity.

• SystemVerilog has expanded the classic reg type so that you can use it like a wire to connect blocks.

• In recognition of its new capabilities, the reg type has the new name of logic. The only place where you
cannot use a logic variable is a net with multiple drivers, where you must use a net such as wire.
Communication with ports
Communication with ports
• The testbench is a module with ports. A small piece of the test is shown.
Communication with ports
• The top netlist connects the testbench and DUT.

• In Example 5-3, the netlists are simple, but real designs with
hundreds of pins require pages of signal and port declarations.
• All these connections can be error prone. As a signal moves through

several layers of hierarchy, it has to be declared and connected over

and over.
• Worst of all, if you just want to add a new signal, it has to be declared

and connected in multiple files.

• SystemVerilog interfaces can help in each of these cases.
 The Interface Construct

• Designs are so complex that even the communication between them may

• need to be separated out into separate entities.

• To model this, SystemVerilog uses the interface construct that you can think
of as an intelligent bundle of wires.

• They contain the connectivity, synchronization, and optionally, the

functionality of the communication between two or more blocks. They
connect design blocks and/or testbenches.
Using an interface to simplify connections
• The first improvement is to bundle the wires together
into an interface block.

• Figure 5-3 shows the testbench and arbiter,

communicating using a interface.

• Note how the interface extends into the two blocks,

representing the drivers and receivers that are
functionally part of both the test and the DUT.

• The clock can be part of the interface or a separate port.

Using an interface to simplify connections
• The simplest interface is just a bundle of nondirectional signals. Use logic so you can drive the
signals from procedural statements.
 Using an interface to simplify connections
• Example 5-6 shows the testbench. You refer to a signal in an interface by making a hierarchical
reference using the instance name: arbif.request.

• Interface signals should always be driven using nonblocking assignments.

 Using an interface to simplify connections
• Lastly is the device under test, the arbiter, that uses an interface instead of ports.

• You can see an immediate benefit, even on this small device:

the connections become cleaner and less prone to mistakes.
• If you wanted to put a new signal in an interface, you would just
have to add it to the interface definition and the modules that
actually used it.
• You would not have to change any module such as top that just pass

the interface through.

• This language feature greatly reduces the chance for wiring errors.