|| Jai Sri Gurudev ||

Sri Adichunchanagiri Shikshana Trust (R)

SJB Institute of Technology

Department of Electronics & Communication
Engineering

Advanced VLSI – 21EC71

Module-4
Connecting the Testbench and Design
By
Mrs. S Nithya
Assistant Professor
Dept of ECE, SJBIT
 Introduction
There are several steps needed to
verify a design:
• Generate stimulus,
• Capture responses,
• Determine correctness,
• Measure progress.
• But first you need write the proper
testbench, connected to the design
as shown in Figure 4-1.

Dept. of ECE, SJBIT 2

 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.
• 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
specification, whereas your job as the verification engineer is to create
scenarios where the design does not match its description.
• Likewise, your testbench code is in a separate block from the design code. In
classic Verilog, each goes in a separate module. However, using a module to
hold the testbench often causes timing problems around driving and
sampling, and so SystemVerilog introduces the program block to separate
the testbench, both logically and temporally.
Dept. of ECE, SJBIT 3
 Cont..
• 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.
• If it is an indirect error, such as swapping pins that only toggle occasionally,
you may not notice the problem for some time.
• 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 expressed like a module but also
connected to ports like a signal.
Dept. of ECE, SJBIT 4
 Cont..

1. 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 as
shown in Figure.

Dept. of ECE, SJBIT 5

 Cont..
2. Communication with Ports
• The following code 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.
• As 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 structural drivers, where you must use a net
such as wire.

Dept. of ECE, SJBIT 6

 The testbench is kept in a module to separate it from the
design. Typically, it connects to the design with ports.

Dept. of ECE, SJBIT 7

The top netlist connects the testbench and DUT and includes a simple clock generator.
Dept. of ECE, SJBIT 8
 The Interface Construct

• 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/or testbenches.

Dept. of ECE, SJBIT 9

1. Using an Interface to Simplify
Connections
• The first improvement to the arbiter
example is to bundle the wires together
into an interface. Figure 4-3 shows the
testbench and arbiter, communicating
using an interface.
• Note how the interface extends into the
two blocks, representing the drivers and
receivers that are functionally part of
The simplest interface is just a bundle of
both the test and the DUT. The clock can bidirectional signals. Use the logic data type so
be part of the interface or a separate port. that you can drive the signals from procedural
statements.
Dept. of ECE, SJBIT 10
Dept. of ECE, SJBIT 11
Dept. of ECE, SJBIT 12
2. Connecting Interfaces and Ports
• If you have a Verilog-2001 legacy design with ports that cannot be changed to use an
interface, you can just connect the interface’s signals to the individual ports.

Dept. of ECE, SJBIT 13

3. Grouping Signals in an Interface Using Modports
• Sample 4.5 uses a point-to-point connection scheme with no signal directions
in the interface. The original netlists using ports had this information that the
compiler uses to check for wiring mistakes.
• The modport construct in an interface lets to group signals and specify
directions. The MONITOR modport allows you to connect a monitor module.

Dept. of ECE, SJBIT 14

Dept. of ECE, SJBIT 15
4. Using Modports with a Bus Design
• Not every signal needs to go in every interface. Consider a CPU – memory bus
modeled with an interface.
• The CPU is the bus master and drives a subset of the signals, such as request,
command, and address.
• The memory is a slave and receives those signals and drives ready. Both master
and slave drive data.
• The bus arbiter only looks at request and grant, and ignores all other signals. So
your interface would have three modports for master, slave, and arbiter, plus an
optional monitor modport.

Dept. of ECE, SJBIT 16

5. Creating an Interface Monitor
• You can create a bus monitor using the MONITOR modport.

Dept. of ECE, SJBIT 17

6. Interface Trade-Offs
The advantages to using an interface are as follows.
• An interface is ideal for design reuse. When two blocks communicate with a specified
protocol using more than two signals, consider using an interface If groups of signals are
repeated over and over, as in a networking switch, you should additionally use virtual
interfaces,
• The interface takes the jumble of signals that you declare over and over in every module or
program and puts it in a central location, reducing the possibility of misconnecting signals.
• To add a new signal, you just have to declare it once in the interface, not in higher-level
modules, once again reducing errors.
• Modports allow a module to easily tap a subset of signals from an interface. You can specify
signal direction for additional checking.
Dept. of ECE, SJBIT 18
The disadvantages of using an interface are as follows.
• For point-to-point connections, interfaces with modports are almost as verbose as using
ports with lists of signals. Interfaces have the advantage that all the declarations are still in
one central location, reducing the chance for making an error.
• You must now use the interface name in addition to the signal name, possibly making the
modules more verbose.
• If you are connecting two design blocks with a unique protocol that will not be reused,
interfaces may be more work than just wiring together the ports.
• It is difficult to connect two different interfaces. A new interface (bus_if) may contain all the
signals of an existing one (arb_if), plus new signals (address, data, etc.). You may have to
break out the individual signals and drive them appropriately.

Dept. of ECE, SJBIT 19

 Stimulus Timing
• The timing between the testbench and the design must be carefully
arranged.
• At a cycle level, you need to drive and receive the synchronous signals at the
proper time in relation to the clock.
• Drive too late or sample too early, and your testbench is off a cycle. Even
within a single time slot (for example, everything that happens at time 100 ns),
mixing design and testbench events can cause a race condition, such as when a
signal is both read and written at the same time.
• SystemVerilog has several constructs to help you control the timing of the
communication.

Dept. of ECE, SJBIT 20

1. Controlling Timing of Synchronous Signals with a Clocking Block
• An interface block uses a clocking block to specify the timing of synchronous
signals relative to the clocks.
• Any signal in a clocking block is now driven or sampled synchronously,
ensuring that your testbench interacts with the signals at the right time.
• Clocking blocks are mainly used by test benches but also allow you to create
abstract synchronous models.
• An interface can contain multiple clocking blocks, one per clock domain, as
there is single clock expression in each block. Typical clock expressions are
@(posedge clk) for a single edge clock and @(clk) for a DDR (double data
rate) clock.
Dept. of ECE, SJBIT 21
Sample 4.14 is similar to Sample
4.10 except that the TEST
modport now treats request and
grant as synchronous signals. The
clocking block cb declares that the
signals are active on the positive
edge of the clock.
The signal directions are relative
to the modport where they are
used. So request is an output in the
TEST modport, and grant is an
input.

Dept. of ECE, SJBIT 22

2. Logic vs. Wire in an Interface
• This book recommends declaring the
signals in your interface as logic, while
the VMM has a rule that says to use a
wire. The difference is ease-of-use vs.
reusability.
• If your testbench drives an
asynchronous signal in an interface
with a procedural assignment, the
signal must be a logic type. A wire can
only be driven with a continuous
assignment statement. Signals in a
clocking block are always
synchronous and can be declared as
logic or wire. Sample 4.15 shows how
the logic signal can be driven directly,
whereas the wire requires additional
code.
Dept. of ECE, SJBIT 23
4. Testbench – Design Race Condition
• Sample 4.16 shows a potential race condition between the testbench and
design. The race condition occurs when the test drives the start signal and
then the other ports.
• The memory is waiting on the start signal and could wake up immediately,
whereas the write, addr, and data signals still have their old values.
• could delay all these signals slightly by using nonblocking assignments, but
remember that the testbench and the design are both using these assignments.
It is still possible to get a race condition between the testbench and design.

Dept. of ECE, SJBIT 24

Dept. of ECE, SJBIT 25
5. The Program Block and Timing Regions
• The root of the problem is the mixing of design and testbench events during
the same time slot, though even in pure RTL the same problem can happen.
• What if there were a way you could separate these events temporally, just as
you separated the code? At 100 ns, your testbench could sample the design
outputs before the clock has had a chance to change and any design activity has
occurred.
• By definition, these values would be the previous possible ones from the
previous time slot. Then, after all the design events are done, your testbench
will start.
• A new division of the time slot was introduced in SystemVerilog as shown in
Figure 4- 4. In Verilog, most events executed in the Active region.
Dept. of ECE, SJBIT 26
Dept. of ECE, SJBIT 27
• First to execute during a time slot is the Active region, where design events
run. These include your RTL and gate code plus the clock generator.
• The second region is the Observed region, where assertions are evaluated.
• Following that is the Reactive region where the testbench executes. Note that
time does not strictly flow forwards events in the Observed and Reactive
regions can trigger further design events in the Active region in the current
cycle.
• Lastly is the Postponed region, which samples signals at the end of the time
slot, in the read-only period, after design activity has completed as shown in
Table 4-1.

Dept. of ECE, SJBIT 28

7. Specifying Delays Between the Design and Testbench
• The default timing of the clocking block is to sample inputs with a delay of #1step and to
drive the outputs with a delay of #0.
• The 1step delay specifies that signals are sampled in the Postponed region of the
previous time slot, before any design activity. So, you get the output values just before the
clock changes.
• The testbench outputs are synchronous by virtue of the clocking block, and so they flow
directly into the design.
• The program block, running in the Reactive region, retriggers the Active region during the
same time slot.
• If you have a design background, you can remember this by imagining that the clocking
block inserts a synchronizer between the design and testbench as shown in Figure 4-5.

Dept. of ECE, SJBIT 29

Dept. of ECE, SJBIT 30
 System Verilog Assertions
• You can create temporal assertions about signals in your design using
System Verilog Assertions (SVA). Assertions are instantiated similarly to
other design blocks and are active for the entire simulation.
• The simulator keeps track of what assertions have triggered, and so you can
gather functional coverage data on them.
1. Immediate Assertions
• Your testbench procedural code can check the values of design signals
and testbench variables and take action if there is a problem. For
example, if you have asserted the bus request, you expect that grant will be
asserted two cycles later. You could use an if-statement.

Dept. of ECE, SJBIT 31

An assertion is more compact than an if-statement. However, If the grant signal is asserted correctly, the test
note that the logic is reversed compared to the if-statement continues. If the signal does not have the expected value,
above. You want the expression inside the parentheses to be the simulator produces a message similar to the
true; otherwise, print an error. following.

This says that on line 7 of the file test.sv, the assertion top.t1.a1 started at 55 ns to check the signal
bus.cb.grant, but failed immediately.
Dept. of ECE, SJBIT 32
• 2. Customizing the Assertion Actions
• An immediate assertion has optional then- and else-clauses. If you want to
augment the default message, you can add your own.

• If grant does not have the expected value, you’ll see an error message.

Dept. of ECE, SJBIT 33

• SystemVerilog has four functions to
print messages: $info, $warning,
$error, and $fatal.
• These are allowed only inside an
assertion, not in procedural code,
though future versions of
SystemVerilog may allow this.
• You can use the then-clause to
record when an assertion completed
successfully.

Dept. of ECE, SJBIT 34

• 3.Concurrent Assertions
• The other type of assertion is the
concurrent assertion that you can
think of as a small model that runs
continuously, checking the values of
signals for the entire simulation.
• need to specify a sampling clock in
the assertion. Here is a small
assertion to check that the arbiter
request signal does not have X or Z
values except during reset.

Dept. of ECE, SJBIT 35

4. Exploring Assertions
• There are many other uses for assertions. For example, you can put
assertions in an interface. Now your interface not only transmits signal
values but also checks the protocol.

Dept. of ECE, SJBIT 36