UNIT-3: System Verilog-II: Connecting the Testbench and design

• Separating the Testbench and Design

• The Interface Construct
• Stimulus Timing
• Interface Driving and Sampling
• Connecting It All Together
• Top-Level Scope
• classes, objects and methods in system Verilog
• Randomization in System Verilog
Steps required to verify the design under test(DUT)
1.Generate stimulus
2.Capturing response
These are the functions of proper Test
3.Determining correctness bench
4.Measuring progress
• So we need a proper testbench
• The 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
• The testbench simulates everything not in the design under test
• Test bench should also describe the timing so that synchronous
signals are always driven and sampled at the correct time
E.g. microprocessor, Video chip, Wi-fi Router etc..

Fig. The testbench – design environment

Separating the Testbench and Design (Importance of Interface)
• In the real world, all projects have two separate groups: one to create
the design and one to verify it
• The designer has to create code that meets that specification
(synthesizable RTL code)
• The verification engineer has to create scenarios where the design
does not match its description i.e. figuring out new ways to find bugs
in the design
• In Verilog, each goes in a separate module but using a module to hold
the testbench often causes timing problems around driving and
sampling
• Hence System-Verilog introduces the program block to separate the
testbench
• As designs grow in complexity, the connections between the blocks increase
and any mismatched or misplaced connection leads to design failure
• If it is required to add a new signal between two blocks we need to edit the
blocks to add the new port and the higher-level modules that wire up the
devices
Design may not give correct functionality
due to wrong connection at any level

Solution: Interface
Interface
• It represents a bundle of wires with signal direction(i/o) ,timing
• It can also include functional code to modify the signals
Communication Between the Testbench and DUT with ports
• The Fig. shows diagram of the top level design including a testbench,
arbiter(DUT) , clock generator, and the signals that connect them
E.g.
Bus Arbitar
-It contains data and address bus
-give allocation of buses to proper device
-can communicate with one device at a time
-if two or more devices are requesting based on
priority bus will be granted
code to explain the functionality of Arbitar (DUT)
rst r[1] r[0] g[1] g[0]

1 X X 0 0

0 0 1 0 1

0 1 0 1 0

0 1 1 0 1

Note: Assuming g[0] has

more priority than g[1]
The testbench kept in a module to separate it from the design
• The top module connects the testbench and DUT, and includes a
simple clock generator
Communication Between the Testbench and DUT with Interface
• For complex designs SystemVerilog uses the interface construct
intelligent bundle of wires
• It contains the connectivity, synchronization, and optionally, the
functionality of the communication between two or more blocks and,
optionally, error checking
• They connect design blocks and/or testbenches.
Steps
1.Create an interface
2.Use it in DUT and test-bench
modules
3.Combine them with top-module
Fig. An interface straddles two modules
• All the blocks are instantiated and connected in the top module

• The connections become cleaner and less prone to mistakes

• A new signal can be added to the interface definition without changes in
the top module
• This language feature greatly reduces the chance for wiring errors.
 Grouping Signals in an Interface Using Modports
• The modport construct in an interface provide grouping of signals and
specify directions i.e input or output

Keyword

Signals used in Testbench

Signals used in DUT

• Modport may not contain all the signals present in the interface
declaration

• This interface with modports more accurately represents the real

design, especially the signal direction
• There are two ways to use these modport names in your design
 Top-module
Interface with Modports (1st style)

Interface with
modports

DUT

Test bench

Specify the Modport names in the modules that connect to the interface
signals and the top module does not change
Interface with Modports (2nd style)
Top-module

Modules are unchanged and modports names are

specified in Top-module
Creating an Interface Monitor
• Monitor is used to check the signals how they are interacting
• Status of the signals can be printed
Interface Trade-Offs
advantages of using an interface
• Use an interface when two or more blocks are communicating with a
specified protocol using more than two signals
• 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
The disadvantages of using an interface
• For point-to-point connections, interfaces with modports are almost
as verbose as using ports with lists of signals
• You must now use the interface name in addition to the signal name,
possibly making the modules more verbose, but more readable for
debugging
• 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
Stimulus Timing
• 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

Test Bench DUT

Drive Sample
(connecting inputs)
Controlling Timing of Synchronous Signals with a Clocking Block
• An interface should contain a clocking block to specify the timing of
synchronous signals relative to the clocks
• Clocking blocks are mainly used by testbenches so that proper
synchronous models are created to test the DUT
• Signals in a clocking block are driven or sampled synchronously,
ensuring that your testbench interacts with the signals at the right
time.
• Synthesis tools do not support clocking blocks hence we can’t use
clocking blocks while writing the design
• An interface can contain multiple clocking blocks, one per clock
domain, as there is a single clock expression in each block
• if you change the clock or edge in the clocking block, no need to change in the
testbench.
Testbench – Design Race Condition
• Race condition occurs when two or more statements that are
scheduled to execute in the same simulation time step, would give
different results when the order of statement execution is changed
E.g. writing data into memory
• 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
• but the write signal still has its old value, while addr and data have
new values
• The root of the problem is the mixing of design and testbench events
during the same time slot i.e. both are written in terms of separate
mdules and both execute concurrently
• This can be avoided if test-bench events are scheduled separately
from the design events
• For this purpose, system-Verilog introduces a separate block named
“programming block” which holds the testbench code
• a program block cannot have any hierarchy such as instances of
modules, interfaces, or other programs
• A programming block can contain code and variables and can be
instantiated in other modules
The Program Block and Timing Regions

• In verilog, both test-bench and DUT

are at module level active and
Observed regions are present
• In active region blocking
assignments and display functions
are executed
• In Inactive region, #0 delay
statements are executed
• In NBA, non-blocking assignments
are evaluated
• In Observed region, all concurrent
assertions statements are
evaluated
• In System -verilog, test-bench and DUT are
not at the same level
• Program block starts its execution in the
reactive region
• Reactive region- blocking
assignments,display functions
• Re-Inactive region: #0 delay statements
• Re-NBA : non-blocking assignments
• In postponed region $display, $strobe
statements
• Note that time does not flow strictly in forward direction
• Events in the observed region and reactive region can trigger further
events in active region in current cycle
• Last is the postponed region, which samples signals at the end of the
time-slot, in the read only period after design activity has completed
• The default timing of the clocking block is to sample inputs with a
skew 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 program block, running in the Reactive region, generates the
stimulus that is applied to the DUT, which is then evaluated in the Active
region during the same time slot
• The DUT evaluates its logic and drives its outputs, which are the inputs
to the testbench through the clocking blocks. These are sampled in the
Postponed region and the cycle repeats.

imagine that the clocking block

inserts a synchronizer between
the design and testbench, as
shown in Fig

Fig. A clocking block synchronizes the DUT and

testbench
Interface Driving and Sampling
• Testbench needs to drive and sample signals from the design,
primarily through interfaces with clocking blocks
Interface Signal Sample
• When you read a signal from a clocking block, you get the value
sampled from just before the last clock edge, i.e., from the Postponed
region
The default timing of the clocking
block is to sample inputs with a skew
of #1step and to drive the outputs
with a delay of #0
Driving Interface Signals Through a Clocking Block
• If the testbench drives the synchronous interface signal at the active edge of the clock,,
the value propagates immediately to the design.
• This is because the default output delay is #0 for a clocking block
• If the testbench drives the output just after the active edge, the value is not seen in the
design until the next active edge of the clock
• Driving clocking block signals asynchronously can lead to dropped
values. Instead, drive at the clock edge by using a cycle delay prefi x
on your drives
Connecting It All Together
• a design described in a module, a testbench in a program block, and
interfaces that connect them together with the top-level module that
instantiates and connects all the pieces.
• It uses a shortcut notation.* (implicit port connection) that automatically
connects module instance ports to signals at the current level if they have
the same name and data type
Top-Level Scope
• It is possible to create things in the simulation that are outside of a
program or module so that they are seen by all blocks
• The scope outside the boundaries of any module, macro module,
interface, program, package , or primitive is known as the
compilation-unit scope , also referred to as $unit
• Anything such as a parameter defined in this scope is similar to a
global because it can be seen by all lower-level blocks
• we can define variables, parameters, data types and even routines in
this space known as Top-Level scope
• The instance name $root allows you to unambiguously refer to names
in the system, starting with the top-level scope