1

2
• There are several steps needed to verify a design:
1. Generate stimulus,
2. Capture responses,
3. Determine correctness, and
4. Measure progress.

3
• As a starting example, let’s model and test a decade counter
• It counts from 0 to 9, in the normal cases, when Enable is active
• It has an asynchronous reset signal MR (Master Reset).
• It can be loaded by any value P, using the synchronous Load line.

4
• In the shown code, the netlists are simple.
• In real designs, you may find hundreds of pins that 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. (Here
for example, the same signals are defined in the top module, the design, and
the testbench).
• 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.

5
• Using the generated waveforms from simulation, you visually inspect the
responses, and determine the correctness of your design.
• Again, this is possible for this simple design, but with large designs, we may
need an automated process to make sure of the correctness of all the aspects of
the design.
• In this example, we generated the stimulus manually to test each feature of the
design. In big designs, we may need to use random inputs, but in the same
time we may need to measure what is called the coverage, to make sure we
tested all features of the design.

6
• 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 buses and devices,
which are modeled in the testbench.
 A networking device connects to multiple input and output data streams
that are modeled based on standard protocols in the testbench.
 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.
 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, that are so common in
Verilog models.

7
• In an ideal world. all projects have two separate groups: one to create the
design and one to verify it, but in the real world, limited budgets may require
you to wear both hats.
• The designer has to create code that meets that specification, and he owns a
set of specialized skills such as creating synthesizable RTL code.
• Whereas the verification engineer has to create scenarios where the design
does not match its description. He must have skills in finding bugs in the
design.
• Your testbench code is in a separate block from design code. In classic
Verilog, each goes in a separate module.
• Using a module to hold the testbench often causes timing problems.
• 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. You can reduce errors by
using the connect-by-name syntax, but this more than doubles your typing
burden.
• Again, one wrong connection at any level and the design stops working.
• The solution is the interface, the System Verilog construct that represents a
bundle of wires, with intelligence such as synchronization, and functional
code.
• In the next, we will explain interfaces.

8
• Designs have become so complex that even the communication between
blocks 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 testbenches.
• The first improvement to the counter example is to bundle the wires together
into an interface. The figure shows the testbench and the counter,
communicating using an interface. Note how the interface extends into the two
blocks, representing the drivers and receivers that are functionally part of both
the testbench and the DUT. The clock can be part of the interface or a separate
port.

9
• The first improvement to the counter example is to bundle the wires together
into an interface.
• Here, the testbench and DUT, communicate using an interface.
• The clock can be part of the interface or a separate port.
• The interface instance name, (e.g ifc in the above code) should be kept as short
as possible as you are going to type it a lot in the design and testbench.
• You might even consider using a single character, as long as this is not
ambiguous.
• 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.
• Make sure you declare your interfaces outside of modules and program
blocks. If you forget, expect all sorts of trouble.

10