Layered TB in SV
1.signal layer:
This layer connects the TestBench to the RTL design. It consists of interface, clocking, and
modport constructs.
2.command layer:
This layer contains lower-level driver and monitor components, as well as the assertions.
This layer provides a transaction-level interface to the layer above and drives the physical
pins via the signal layer.
3.functional layer:
This layer contains higher-level driver and monitor components, as well as the self-checking
structure (scoreboard/tracker).
4.scenario layer:
This layer uses generators to produce streams or sequences of transactions that are applied
to the functional layer. The generators have a set of weights, constraints or scenarios
specified by the test layer. The randomness of constrained-random testing is introduced
within this layer.
5.test layer:
Tests are located in this layer. Test layer can interact with all the layers. This layer allows to
pass directed commands to functional and command layer.
SystemVerilog TestBench Architecture
TESTBENCH ARCHITECTURE in SV
Fig. Testbench architecture
About TestBench
Testbench or Verification Environment is used to check the functional
correctness of the Design Under Test (DUT) by generating and driving a
predefined input sequence to a design, capturing the design output and
comparing with-respect-to expected output.
Verification environment is a group of class’s performing specific operation.
i.e, generating stimulus, driving, monitoring, etc. and those classes will be
named based on the operation
TestBench Components
Name Type Description
Defines the pin level activity generated by agent (to drive to
transaction class
DUT through the driver) or the activity has to be observed
by agent (Placeholder for the activity monitored by the
monitor on DUT signals)
Generates the stimulus (create and randomize the
generator class
transaction class) and send it to Driver
Receives the stimulus (transaction) from a generator and
driver class drives the packet level data inside the transaction into pin
level (to DUT
Observes pin level activity on interface signals and converts
monitor class into packet level which is sent to the components such as
scoreboard
An agent is a container class, which groups the class’s
agent class (generator, driver, and monitor) specific to an interface or
protocol
Receives data items from monitors and compares them with
expected values.
scoreboard class
Expected values can be either golden reference values or
generated from the reference model
The environment is a container class for grouping higher
environment class
level components like agent’s and scoreboard
The test is responsible for,
test program
Configuring the testbench
Initiate the testbench components construction process
Initiate the stimulus driving
This is the topmost file, which connects the DUT and
testbench_top class TestBench. It consists of DUT, Test and interface instances,
the interface connects the DUT and TestBench
TestBench Hierarchy
SystemVerilog TestBench hierarchy
TestBench Architecture
SystemVerilog Testbench
SystemVerilog TestBench Example — Adder
Let’s Write the SystemVerilog TestBench for the simple design “ADDER”.
Before writing the SystemVerilog TestBench, we will look into the design
specification.
ADDER:
Below is the block diagram of ADDER.
“Adder” Design block diagram
Adder is,
fed with the inputs clock, reset, a, b and valid.
has output is c.
The valid signal indicates the valid value on the a and b, On valid signal
adder will add the a and b, drives the result in the next clock on c.
Adder add/Sum the 4bit values ‘a’ and ‘b’, and drives the result on c in the
next clock.
waveform diagram:
“Adder” Waveform
waveform snapshot from EPWave – EDAPlayground
‘ADDER’ TestBench With Monitor and
Scoreboard
Table of Contents
‘ADDER’ TestBench With Monitor and Scoreboard
o TestBench Architecture
o Monitor
o Scoreboard
o Environment
TestBench Architecture
SystemVerilog TestBench
Only monitor and scoreboard are explained here, Refer to ‘ADDER’
TestBench Without Monitor, Agent, and Scoreboard for other components.
Monitor
Samples the interface signals and converts the signal level activity to
the transaction level.
Send the sampled transaction to Scoreboard via Mailbox.
Below are the steps to write a monitor.
1. Writing monitor class.
class monitor;
------
endclass
2. Declare interface and mailbox, Get the interface and mailbox handle
through the constructor.
//creating virtual interface handle
virtual intf vif;
//creating mailbox handle
mailbox mon2scb;
//constructor
function new(virtual intf vif,mailbox mon2scb);
//getting the interface
this.vif = vif;
//getting the mailbox handles from environment
this.mon2scb = mon2scb;
endfunction
3. Sampling logic and sending the sampled transaction to the scoreboard.
task main;
forever begin
transaction trans;
trans = new();
@(posedge vif.clk);
wait(vif.valid);
trans.a = vif.a;
trans.b = vif.b;
@(posedge vif.clk);
trans.c = vif.c;
@(posedge vif.clk);
mon2scb.put(trans);
trans.display("[ Monitor ]");
end
endtask
4. Complete monitor code.
class monitor;
//creating virtual interface handle
virtual intf vif;
//creating mailbox handle
mailbox mon2scb;
//constructor
function new(virtual intf vif,mailbox mon2scb);
//getting the interface
this.vif = vif;
//getting the mailbox handles from environment
this.mon2scb = mon2scb;
endfunction
//Samples the interface signal and send the sample packet to scoreboard
task main;
forever begin
transaction trans;
trans = new();
@(posedge vif.clk);
wait(vif.valid);
trans.a = vif.a;
trans.b = vif.b;
@(posedge vif.clk);
trans.c = vif.c;
@(posedge vif.clk);
mon2scb.put(trans);
trans.display("[ Monitor ]");
end
endtask
endclass
Scoreboard
Scoreboard receives the sampled packet from the monitor and compare
with the expected result, an error will be reported if the comparison results
in a mismatch.
class scoreboard;
------
endclass
1. Declaring the mailbox and variable to keep count of transactions,
connecting handle through the constructor,
//creating mailbox handle
mailbox mon2scb;
//used to count the number of transactions
int no_transactions;
//constructor
function new(mailbox mon2scb);
//getting the mailbox handles from environment
this.mon2scb = mon2scb;
endfunction
2. logic to compare the received result with the expected result,
Note: As the DUT behavior is simple, a single line is added for generating
the expected output.
Complex designs may use the reference model to generate the expected
output.
(trans.a+trans.b) == trans.c
//Compares the Actual result with the expected result
task main;
transaction trans;
forever begin
mon2scb.get(trans);
if((trans.a+trans.b) == trans.c)
$display("Result is as Expected");
else
$error("Wrong Result.\n\tExpeced: %0d Actual: %0d",(trans.a+trans.b),trans.c);
no_transactions++;
trans.display("[ Scoreboard ]");
end
endtask
3. Complete scoreboard code.
class scoreboard;
//creating mailbox handle
mailbox mon2scb;
//used to count the number of transactions
int no_transactions;
//constructor
function new(mailbox mon2scb);
//getting the mailbox handles from environment
this.mon2scb = mon2scb;
endfunction
//Compares the Actual result with the expected result
task main;
transaction trans;
forever begin
mon2scb.get(trans);
if((trans.a+trans.b) == trans.c)
$display("Result is as Expected");
else
$error("Wrong Result.\n\tExpeced: %0d Actual:
%0d",(trans.a+trans.b),trans.c);
no_transactions++;
trans.display("[ Scoreboard ]");
end
endtask
endclass
Environment
Here only updates are mentioned. i.e adding monitor and scoreboard to
the previous example.
1. Declare the handles,
//generator and driver instance
generator gen;
driver driv;
monitor mon; //---NEW CODE---
scoreboard scb; //---NEW CODE---
//mailbox handle's
mailbox gen2driv;
mailbox mon2scb; //---NEW CODE---
//virtual interface
virtual intf vif;
2. In Construct Method, Create
Mailbox (mon2scb)
Monitor
Scoreboard
and pass the interface handle through the new() method.
//constructor
function new(virtual intf vif);
//get the interface from test
this.vif = vif;
//creating the mailbox (Same handle will be shared across generator and driver)
gen2driv = new();
mon2scb = new(); //---NEW CODE---
//creating generator and driver
gen = new(gen2driv);
driv = new(vif,gen2driv);
mon = new(vif,mon2scb); //---NEW CODE---
scb = new(mon2scb); //---NEW CODE---
endfunction
3. Calling monitor and scoreboard tasks,
task pre_test();
driv.reset();
endtask
task test();
fork
gen.main();
driv.main();
mon.main(); //---NEW CODE---
scb.main(); //---NEW CODE---
join_any
endtask
task post_test();
wait(gen.ended.triggered);
wait(gen.repeat_count == driv.no_transactions);
wait(gen.repeat_count == scb.no_transactions); //---NEW CODE---
endtask
4. Complete environment class code.
`include "transaction.sv"
`include "generator.sv"
`include "driver.sv"
`include "monitor.sv"
`include "scoreboard.sv"
class environment;
//generator and driver instance
generator gen;
driver driv;
monitor mon;
scoreboard scb;
//mailbox handle's
mailbox gen2driv;
mailbox mon2scb;
//virtual interface
virtual intf vif;
//constructor
function new(virtual intf vif);
//get the interface from test
this.vif = vif;
//creating the mailbox (Same handle will be shared across generator and driver)
gen2driv = new();
mon2scb = new();
//creating generator and driver
gen = new(gen2driv);
driv = new(vif,gen2driv);
mon = new(vif,mon2scb);
scb = new(mon2scb);
endfunction
//
task pre_test();
driv.reset();
endtask
task test();
fork
gen.main();
driv.main();
mon.main();
scb.main();
join_any
endtask
task post_test();
wait(gen.ended.triggered);
wait(gen.repeat_count == driv.no_transactions); //Optional
wait(gen.repeat_count == scb.no_transactions);
endtask
//run task
task run;
pre_test();
test();
post_test();
$finish;
endtask
endclass
