SystemVerilog Testbench

Introduction to
SystemVerilog for Testbench

Agenda 2
 Introduction
 Methodology Introduction
 Getting Started
 Testbench Environment
 Language Basics
 OOP Basics
 Randomization
 Controlling Threads
 Virtual Interfaces
 Functional Coverage
 Coverage Driven Verification
 Testbench Methodology
SystemVerilog Testbench with VCS 05/07/2007
Lecture Objectives 3
By the end of this class, you should be able to:
 Develop self checking testbenches using VCS and

SystemVerilog
 How to connect your Design to a SV testbench
 How to perform random constrained testing
 How to take advantage of powerful concurrency
 How to implement Functional Coverage
Look for
coding tips!

Introduction 4
SystemVerilog for Verification

 Based on IEEE P1800-2005 Standard
 Detailed in Language Reference Manual
 Verification-specific language features
 Constrained random stimulus generation
 Functional coverage
 SystemVerilog Assertions (SVA)
SystemVerilog Testbench with VCS

Agenda 5
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Verification Environment 6
Definitions
Checks Testbench
Creates correctness
stimulus Verification
Environment Identifies
Executes Test transactions
transactions
Transactor Scoreboard Checker Observes
Supplies data data
to the DUT from DUT
Driver Assertions Monitor
DUT

Methodology Introduction 7
 To maximize design quality

 Provides guidance:
 Find bugs fast!
 Identify the best practices
 Make the most of Synopsys tools
 Methodology
 One verification environment, many tests
 Minimize test-specific code
 Reuse
Across tests
Across blocks
Across systems
Across projects

Methodology Introduction 8
 Testbench Design
 Start with a fully randomizable testbench
 Run many randomized simulation runs
 Analyze cumulative coverage and coverage holes
 Then with minimal code changes:
 Add constrained stimulus to fill coverage holes
 Finally:
 Make few directed tests to hit the remaining holes

Coverage-Driven Verification 9
 Measure progress using functional coverage
Coverage-Driven Productivity
With
Methodology gain
VIP
Goal Directed
% Coverage
Methodology
Self-checking
random environment
development time
Time

Key Benefits: Testbench Environment 10
 Environment Creation takes less time

 Testbench is easy constrain from the top level file
 All Legal Device Configurations are tested
 Regression can select different DUT configurations
 Configuration object is randomized and constrained
 Enables reuse

Agenda 11
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Getting Started 12
What are We Going to Discuss?
 SystemVerilog Testbench Verification Flow

 Compiling and Running in VCS
 Documentation and support

Getting Started 13
Compiling and Running with VCS

 Compile:
vcs -sverilog –debug top.sv test.sv dut.sv
 -sverilog Enable SystemVerilog constructs
 -debug Enable debug except line stepping
 -debug_all Enable debug including line stepping
 Run:
simv +user_tb_runtime_options
 -l logfile Create log file
 -gui Run GUI
 -ucli Run with new command line debugger
 -i cmd.key Execute UCLI commands
See the VCS User Guide for all options

Getting Started 14
Legacy Code Issues

 SystemVerilog has dozens of new reserved keywords such as
bit, packed, logic that might conflict with existing Verilog code
 Keep your Verilog-2001 code separate from SystemVerilog
code and compile with:
vcs –sverilog new.v +verilog2001ext+.v2k old.v2k
 or
vcs +systemverilogext+.sv old.v new.sv
// Old Verilog-1995/2001 legacy code

integer bit, count;
initial begin
count = 0;
for (bit = 0; bit < 8; bit = bit + 1)
if (adrs[bit] === 1'bx)
count = count + 1;
end
Debug: Getting Started 15
 Invoke DVE > simv –gui -tbug
Source
code
tracing
Active
threads
Local
variables

Getting Started 16
Documentation and Support

 SystemVerilog documentation > vcs -doc
 Examples
 $VCS_HOME/doc/examples
 Email Support:
 vcs-support@synopsys.com
 On-line knowledge database

 http://solvnet.synopsys.com
 Testbench Discussion Forum
 http://verificationguild.com
 SystemVerilog LRM
 www.Accellera.org or www.eda.org/sv

Agenda 17
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Testbench Environment 18
How Should You Connect to DUT

 Someone gives you a DUT, now what?
reset
request[1:0]
grant[1:0]
clock
arb.sv

Testbench Environment 19
Steps to hook up a DUT to a Testbench
1. Create DUT interface with

modports and clocking top.sv
blocks
2. Create testbench program
3. Create top module
4. Compile and run
test.sv arb.sv
clock

Testbench Environment -- Interfaces 20
Introduction
 The complexity of communication between
blocks requires a new design entity
 Top level net-lists are too verbose and error prone
 An interface encapsulates this communication
 Connectivity (signals)
 Directional information (modports)
 Timing (clocking blocks)
 Functionality (routines, assertions, initial/always blocks)
 An interface can be:
 Connected at compile-time (default)
 Connected at run-time – virtual interfaces
 An interface can not:
 Be hierarchical, or extended Device 1 interface Device 2

Before Interfaces
 The RTL code was connect with a netlist
mem cpu
top
module mem ( module cpu (
input bit req, input bit clk,
bit clk, bit gnt,
bit start, bit rdy,
wire [1:0] mode, inout wire [7:0] data,
wire [7:0] addr, output bit req,
inout wire [7:0] data, bit start,
output bit gnt, wire [1:0] mode,
bit rdy); wire [7:0] addr);
… …
module top;
logic req, gnt, start, rdy;
bit clk;
always #10 clk = !clk;
logic [1:0] mode;
logic [7:0] addr;
wire [7:0] data;
mem m1(req, clk, start, mode, addr, data, gnt, rdy);
cpu c1(clk, gnt, rdy, data, req, start, mode, addr);
endmodule
Named Bundle of Signals
 The RTL code is connected with bundled signals
simple_bus
clk
mem cpu
top
interface simple_bus; module mem( module cpu(

logic req, gnt; simple_bus sb, simple_bus sb,
logic [7:0] addr; input bit clk); input bit clk);
wire [7:0] data; … …
logic [1:0] mode; endmodule endmodule
logic start, rdy;
endinterface module top;
logic clk = 0;
simple_bus sb();
mem m1(sb, clk);
cpu c1(sb, clk);
endmodule
Referencing Signals in Interface
 Use hierarchical names for interface signals in a module
module cpu(simple_bus sb, input bit clk);
logic addr_reg;
always @(posedge clk)
sb.addr <= addr_reg;
endmodule : cpu
interface simple_bus;
logic req, gnt;
logic [7:0] addr;
wire [7:0] data;
logic [1:0] mode;
logic start, rdy; Label on end
endinterface: simple_bus statement
 Signals with multiple drivers must be wire

 Signals driven by procedural assignment must be logic
Dividing an Interface
 Not every device has the same access to an interface
 Restrict signal access & direction with modport
interface simple_bus;
logic req, gnt;
logic [7:0] addr;
wire [7:0] data;
logic [1:0] mode;
logic start, rdy;
modport SLAVE (input addr, gnt, mode, start,
output req, rdy,
inout data);
modport MASTER (output addr, gnt, start, mode,
input req, rdy,
inout data);
endinterface: simple_bus
module cpu(simple_bus.MASTER sb, module mem(simple_bus.SLAVE sb,

input bit clk); input bit clk);
… …
endmodule endmodule
Adding Timing Step 1
 An interface can use a clocking block to control timing
 Directions are relative to program block
interface arb_if (input bit clk);
logic [1:0] grant, request; reset
logic reset; request[1:0]
grant[1:0]
clocking cb @(posedge clk); clock
input grant; // TB input
output request; // TB output arb.sv
endclocking
modport DUT (input clk,

input request, reset, // Design under test
output grant);
modport TB (clocking cb, // Synch signals
output reset); // Async signals
endinterface: arb_if
Clocking Blocks
 Use in the interface, just for testbench
 Benefits:
 Creates explicit synchronous timing domains
 Provides race-free operation if input skew > 0
 Your testbench will always drive the signals at the right time!
 Functionality:
 An interface can contain multiple clocking blocks
 There is one clock per clocking block.
 Default is “default input #1step output #0;”
 “1step” specifies that the values are sampled immediately
upon entering this time slot in Prepone region, before any
design activity

SystemVerilog Scheduling 27
SystemVerilog Scheduling Details

 Each time slot is divided into 5 major regions (plus PLI)
 Prepone Sample signals before any changes (#1step)
 Active Design simulation (module), including NBA
 Observed Assertions evaluated after design executes
 Reactive Testbench activity (program)
 Postpone Read only phase
 Assertion and testbench events can trigger more design evaluations
in this time slot
clock
data
REGION Prepone Active Observed Reactive Postpone
ACTIVITY sample design assertions testbench $monitor
Previous Current Next

Testbench Environment - Program Block 28
Program Block
 Benefits:
 Encapsulates the testbench
 Separates the testbench from the DUT
 Provides an entry point for execution
 Creates a scope to encapsulate program-wide data
 Functionality:
 Can be instantiated in any hierarchical location
 Typically at the top level
 Interfaces and ports can be connected in the same
manner as any other module
 Leaf node, can not contain any hierarchy, just classes
 Code goes in initial blocks & routines, no always blocks
 Executes in the Reactive region

Testbench Environment – Program 29
 Create testbench program: test.sv Step 2
program test(arb_if.TB arbif); clk

initial begin reset
// Asynch drive reset request
arbif.reset <= 0;
#15ns arbif.reset <= 1; interface arb_if (input bit clk);
#35ns arbif.reset <= 0; logic grant, request, reset;
ns! clocking cb @(posedge clk);
// Synch drive request input grant;
##1 arbif.cb.request <= 1; output request;
##1 arbif.cb.request <= 0; endclocking
modport TB (clocking cb,
wait (arbif.cb.grant == 1);
output reset);
end endinterface: arb_if
endprogram
Common mistake: forgetting
Wait 1 clock cycle “cb.” in signal reference
Error: arbif.request not
visible via modport
Using the Clocking Block 30
Synchronous Signal Access
 Clocking Block signals are referenced by pre-
pending the clocking block name to the signal:
All drives must use non-blocking assignment
arbif.cb.request <= 1; // drive
value = arbif.cb.grant; // sample
 Assignment will happen at next active clock edge

 Time will NOT advance unless you use #1 or ##1
logic grant, request, reset;
clocking cb @(posedge clk);
input grant;
output request;
endclocking
modport TB (clocking cb, output reset);
endinterface: arb_if
Driving, Sampling, Synchronizing 31
Signal Synchronization
 Synchronize to active clock edge specified in clocking block
@arbif.cb; // continue on posedge of arb_if clk
repeat (3) @arbif.cb; // Wait for 3 posedges
 Synchronize to any edge of signal

@arbif.cb.grant; // continue on any edge of grant
@(posedge arbif.cb.grant); // continue on posedge
@(negedge arbif.cb.grant); // continue on negedge
wait (arbif.cb.grant==1); // wait for expression
// no delay if already true
 Wait for N clock cycles with ##n – blocking statement

##2 arbif.cb.request <= 0; // Wait 2 cycles
// then assign

Testbench Timing 32
SystemVerilog Testbench in Simulation

 When you are using interfaces with a clocking block:
 There is a 1-cycle delay from DUT output to testbench input
“Virtual synchronizer” added to TB input
 No delay from testbench output to DUT input
default input #1step output #0;”
clock
Design
Testbench
Sample inputs Drive outputs
before clock at clock
Testbench Environment – Top Block 33
Step 3
 Create top module
module top; // Synchronous TB

bit clk; program test(arb_if.TB arbif);
test t1 (.*); …
arb d1 (.*); endprogram
arb_if arbif(.*);
always #50
clk = !clk; module arb(arb_if.DUT arbif,
endmodule bit clk);
// Some logic here…
endmodule

…
The syntax .* connect ports endinterface: arb_if
and signals with same names

Testbench Environment - Scoping 34
Scoping Rules
 SystemVerilog defines a global scope, $root,
outside any module or program
 Define global items such as shared enums
 Use parameters for global constants, not macros
`timescale 1ns/1ns
typedef enum {IDLE, RUN, WAIT} fsm_state_t; root.sv
parameter TIMEOUT = 1_000_000;
module state_machine(…);
fsm_state_t state, next_state; dut.sv
endmodule
program test;
fsm_state_t state; test.sv
initial #TIMEOUT $finish;
endprogram
Testbench Environment -- Communication 35
DUT visibility
 The program block can see all signals & routines in
the design
 A module can not see anything in program block
 Use absolute hierarchical path to access DUT
 Start with $root, then top-level instance name, DUT, etc.
 Use care when calling DUT routines from program
 Good practice is to use a function to get info
 Don’t try to trigger DUT code
 SV accesses ports & XMR signals immediately
(asynchronously)
dstate = top.dut.state; // Immediate XMR sample

dstate = $root.top.dut.state; // Absolute path

SV Language Basics 36
Check signal values

 Check a SVA procedurally
 Non-blocking statement
program test (arb_if arbif);

initial begin
arbif.cb.request <= 1;
repeat (2) @arbif.cb; SystemVerilog
a1: assert (arbif.cb.grant==1); Assertion
end
in case of error…
“test.sv", 7: top.t1.a1: started at 55ns failed at 55ns
Offending '(arbif.cb.grant == 1)‘

Check signal values

 Optional then & else clauses for success / failure
 If SVA failure and no else-clause, a generic error is printed
 Use $info, $warn, $error, and $failure for reporting
 These are only valid in SVA’s (IEEE-1800)
program test (arb_if arbif);

initial begin
arbif.cb.request <= 1;
repeat (2) @arbif.cb;
a1: assert (arbif.cb.grant==1)
success++;
else
$error(“No grant received”); Custom
end message

Testbench Environment – Compile and Run 38
Step 4
 Compile and run
> vcs -sverilog -debug

root.sv top.sv arb_if.sv test.sv arb.sv
> simv –gui -tbug
Run with
debugger

Agenda 39
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
What are We Going to Discuss?

 SystemVerilog basics
 Data types
 Arrays
 Subroutines
 Interfaces
 This class assumes you already know most Verilog-1995

and 2001 constructs

Basic SystemVerilog Data Types 41
SystemVerilog Data Types

reg [31:0] r; // 4-state
logic [7:0] w; // 4-state
In SystemVerilog, the old reg type has been extended so it can be driven by
single drivers (gates, modules, continuous assignments) like a wire. It has a
new name logic. It can not have multiple drivers – use a wire.
bit [31:0] b; // 2-state bit 0 or 1

integer i; // 4-state, 32-bits, signed Verilog-1995
int i; // 2-state, 32-bit signed integer
byte b8; // 2-state, 8-bit signed integer
shortint s; // 2-state, 16-bit signed integer
longint l; // 2-state, 64-bit signed integer
Explicit 2-state variables give better performance,

but they will not propagate X or Z, so keep away from DUT
assert(!$isunknown(ifc.cb.data));

 User defined types
 Use typedef to create a synonym for another type
Useful
typedef bit [31:0] uint;
type typedef bit [0:5] bsix_t; // Define new type
bsix_t my_var; // Create 6-bit variable
 Define a structure with multiple variables

typedef struct {bit [7:0] opcode;
Use classes bit [23:0] addr; }
instead! instruction; // named structure type
instruction IR; // define variable
 Use union for merged storage

typedef union {int i; shortreal f; } num_t;
num_t un;
un.f = 0.0; // set n in floating point format


 Enumerated type
 Explicitly typed and scoped (program or class-level)
 Can only create variables at class level, not typedef
 Allows compile time error checking
// Declare single enum variable
enum {RED, BLUE, GREEN} color;
// declare data type
typedef enum {INIT, DECODE, IDLE} fsmstate_t;
fsmstate_t pstate, nstate; // declare variables
int i = 1;
case (pstate)
IDLE: nstate = INIT; // data assignment
INIT: nstate = DECODE;
default: nstate = IDLE; Print the
endcase symbolic
name
$display(“Next state is %0s”, nstate.name);
nstate = fsmstate_t’(i); // cast integer to enum
Fixed Size Arrays type name [constant];

 Fast, static size
Multiple dimensions supported
 Out-of-bounds write ignored
 Out-of-bounds read returns X, even for 2-state
 Array data stored in 32-bit words
int twoD1[0:7][0:23]; // 2D array

int twoD2[8][24]; // same as above
twoD1 = twoD2; // Array copy
if (twoD1==twoD2)… // Array compare
Use bit & word
subs together
bytes[0][3] bytes[0][1][6] with fixed arrays
bytes[0] 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0
bytes[1] 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0
bytes[2] 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0 7 65 4 3 21 0
bit [3:0][7:0] bytes [0:2]; // 3 entries of packed 4 bytes

Dynamic Arrays type name [ ];
 Fast, variable sized with call to new()

 Similar to a fixed size array, but size given at run time
 Single dimension only, never packed
 Out-of-bounds access causes run-time error
int d[], b[]; // Two dynamic arrays
d = new[5]; // Make array with 5 elements
foreach (d[j]) // Initialize
d[j] = j;
b = d; // Copy a dynamic array
b[0] = 5;
$display(d[0],b[0]); // See both values (0 & 5)
d = new[20](d); // Expand and copy
d = new[100]; // Allocate 100 new integers
// Old values are lost
d.delete(); // Delete all elements
Queues type name [$];
 Flexible – size can easily change

 Variable size array with automatic sizing, single dimension
 Many searching, sorting, and insertion methods (see LRM)
 Constant time to read, write, and insert at front & back
 Out of bounds access causes run-time error
int q[$] = {0,1,3,6};
int j = 2, b[$] = {4,5};
q.insert(2, j); // {0,1,2,3,6} Insert before s[2]
q.insert(4, b); // {0,1,2,3,4,5,6} Insert whole queue
q.delete(1); // {0,2,3,4,5,6} Delete element #1
q.push_front(7); // {7,0,2,3,4,5,6} Insert at front
FAST!
j = q.pop_back(); // {7,0,2,3,4,5} j = 6
q.push_back(8); // {7,0,2,3,4,5,8} Insert at back
j = q.pop_front(); // {0,2,3,4,5,8} j = 7
$display(q.size); // “6”
foreach (q[i]) $display(q[i]);
Checking Results with Queues 47
Queues for Scoreboards

 What if transactions get out of order, are dropped or are
corrupted in the DUT?
 Store expected transactions in a queue, with a timestamp
 Contents are addressable, push/pop
 Look up transaction ID on arrival for out-of-order delivery
 If actual transaction not found: corrupted data
 Periodically scan array for old transactions. Mark them as
dropped and remove
Tr2 @3000
Transactor Tr1 @1000 Checker

Tr4 @2000
Driver Monitor
DUT
Associative Arrays type name [*];
 Great for sparse memories

 Dynamically allocated, non-contiguous elements
 Accessed with integer, or string index, single dimension
 Great for sparse arrays with wide ranging index
 Array functions: exists, first, last, next, prev
int aa[*], i; // Print full array

foreach(aa[i])
reg[7:0] mydata[string];
$display(i,,aa[i]);
Standard array Associative array
All memory Unused elements

allocated, even don’t use memory
unused elements

Array Methods
 Search through arrays (fixed, dynamic, queue, assoc.)
 Many more methods will be implemented, such as sort…
 Returns a queue or scalar
 a.sum of single bit values returns 0/1
 Unless you compare to wider value: a.sum == 32’h3
 Also available: product, and, or, xor
int q[$] = {1,3,5,7}, tq[$]; IEEE changed array
int d[] = {9,1,8,3,4}; const from {0,1} to ’{0,1}
int f[6] = {1,6,2,6,8,6}; (VCS issues Warning for
old usage)
$display(q.sum, q.product); // 16 105
LRM requires
tq = q.min(); // {1}
a queue
tq = q.max(); // {7}
tq = f.unique; // {1,6,2,8}
tq = d.find with (item > 3); // {9,8,4}
tq = d.find_index with (item > 3); // {0,2,4}
Strings string name;
 Arbitrary length array of chars (like C), grows automatically

 Compare operators ==, !=, and compare() and icompare()
methods
 Use { } for concatenation
 Built-in conversion itoa, atoi, atohex, atooct, atobin
string s = “SystemVerilog”;
$display(s.getc(0),, s.toupper());
s = {s, “3.1b”}; // string concat
s.putc(s.len()-1, “a”); // change b-> a
$display(s);
$display(s.substr(2, 5)); // 4 characters
// Create temporary string, note format

my_log($psprintf(“%s %5d”, s, 42));
Tasks and Functions

task reset();
function int add2(int n);
reset_l = 1’b0;
return n + 2;
#100
endfunction
reset_l = 1’b1;
endtask
Function can never contain blocking statements or calls to tasks

Void functions do not return a value
function void print_sum(ref int a[], input int start=0);

int sum = 0;
for (int j=start; j<a.size; j++)
sum += a[j];
$display(“Sum of array is %0d”, sum);
endfunction
…
print_sum(my_array); Default value
print_sum(my_array, );

Tasks and Functions

 Static vs. Automatic Tasks and Functions
 All calls to static routine shares the same storage space within a
module instance. It can’t be reentrant or recursive. (Verilog-1995)
 An automatic routine allocates new space for each call. (This is
the default in other languages.) (Verilog-2001)
 Class routines are automatic by default, while routines in
modules and program are static by default. (SystemVerilog)
 The print_sum example on the previous slide will NOT work
with static storage as sum will only be initialized at time 0.
program automatic test;

Change storage default
for programs task is_automatic();

Tasks and Functions

 Argument Passing
 Type is sticky, following arguments default to that type
 input - copy value in at beginning - default
 output - copy value out at end
 inout - copy in at beginning and out at end
 ref - pass by reference (effects seen right away)
 Saves time and memory for passing arrays to tasks & functions
 Modifier: const - argument is not allowed to be modified
Default dir is input, Watch out for ref

default type is logic followed by input…
task T3(a, b, output bit [15:0] u, v);
a, b: input logic
u, v: output bit [15:0]
Lab 1 54
Verify an arbiter
 Objective
 Verify the arbiter’s reset
 Verify arbiter handles simple requests and grants
 Verify proper handling of request sequences
 Key Topics
 Port list, clocking block, program block, assert, drive samples
and check responses.
 Time Allotted
 45 minutes

Agenda 55
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
OOP Basics 56
What Are We Going to Discuss?
 What is OOP
 Terminology
 An example class
 Default methods for classes
 Static attribute
 Assignment and copying
 Inheritance
 Polymorphism

Introduction to OOP 57
What is OOP?
 OOP: Object Oriented Programming
 Traditional programming deals with data structures and
algorithms separately
 OOP organizes transactions and transactors better
 Objects group data and algorithms together logically
 Routines are actions that work on the grouped data
 OOP closely ties data and functions together -

encapsulation
 Extend the functionality of existing objects -
inheritance
 Wait until runtime to bind data with functions -
polymorphism

OOP Basics 58
What is OOP?
 OOP breaks a testbench into blocks that work together
to accomplish the verification goal
 Advantages
• Objects are easily reused and extended
• Allows for complex data structures
• Allows access to advanced SystemVerilog
testbench features
• Variables, functions, and tasks are protected from
side effects or misuse by other code
• Debug small sections of code, one class at a time

OOP Basics 59
Terminology
HDL OOP
Verilog SystemVerilog
Block definition module class
Block instance instance object
Block name instance name handle
Data Types registers & wires Properties:

Variables
Executable Code behavioral blocks Methods: tasks
(always, initial), and functions
tasks, functions
Communication Ports or cross- calls,
between blocks module task calls mailboxes,
semaphores,
etc.

OOP Basics 60
Terminology
Blueprint for  Class
a house  Programming element “containing” related group of features
and functionality
 Encapsulates functionality
 Provides a template for building objects
 Can be used as data structures
A complete  Object
house  An object is an instance of a class
Address of  Handle
a house  Type-safe pointer to an object – can not be corrupted
Light  Properties
switches  Variables contained in the instance of the class
 Methods
Turn on/off
switches  Tasks/functions (algorithms) that operate on the properties in
this instance of the class
OOP Basics 61
Class Example Variables & methods are
class Transaction; public by default
// properties (variables)
logic [31:0] src, dst, data[1024], crc;
logic [7:0] kind;
// methods
function void display;
$display(“Tr: %h, %h”, src, dst);
endfunction
function void calc_crc();

crc = src ^ dst ^ data.xor;
endfunction
In a class, methods
endclass
are always automatic
endprogram

OOP Basics 62
Creating an Object From a Class
 Call new() to create an object
 The class constructor allocates memory and initializes variables
 Result stored in a handle to the object
 You must to call new() for every handle in an array
 SystemVerilog uses a predefined new() for every class,

but you can redefine your own
Declare first
 Coding style: don’t call new in declaration then construct
 Otherwise objects are created before any procedural code
task init;
Transaction tr; // A single handle
Transaction tr_arr[5]; // An array of handles
// Handles are null until initialized
tr = new(); // Create a new object
foreach (tr_arr[i]) // Create an array
tr_arr[i] = new(); // of new objects
endtask
OOP Basics 63
Working with Objects
 Call new(), assigned values to the object
properties
 Handles have the default value of null
 Using a null handle is an error
Error: null object access in file xx.sv line 38
 Every call to the constructor creates a new

object that is independent of all other objects
 Properties and methods accessed through handle
 Handles are type safe – can’t misused or modified, unlike C
 Class Destruction/De-allocation
 Automatic Garbage Collection taken care of by SystemVerilog
(like Java, unlike C++)
 When an object is no longer being referenced, it is garbage
collected
 No segmentation faults from manual memory deallocation
 No memory leaks or unexpected side effects 
if (tr.done) // No longer needed?
tr = null; // clear handle
Where are all the objects? 64
A transactor can be an object too!
Scoreboard holds Verification

Extended transactions Environment
class
Compares
Executes Test transactions
transactions
Transactor Self Check Checker
Drives
transactions Monitor
Driver
into the DUT
Puts data
DUT
into
transactions
OOP Basics 65
Accessing Class Members
 Reference properties by pre-pending the object handle
class Transaction;
bit [31:0] src, dst, data[1024];
bit [7:0] kind;
function void display;
$display(“Tr: %h, %h”, src, dst);
endfunction
endclass
Transaction tr;
initial begin
tr = new();
tr.src = 5;
tr.dst = 7;
tr.display();
end

OOP Basics 66
Initializing Class Properties
 Initialize the class properties in the constructor when the
object is created
 Function type not needed
program automatic test1; program automatic test2;
class Transaction; class Transaction;
bit [31:0] src, dst; bit [31:0] src, dst;
function new(); function new (int src, int dst=3);
src = 5; this.src = src; // Disambiguate
dst = 3; this.dst = dst;
endfunction endfunction
endclass endclass
Transaction tr; Transaction tr;
initial initial
tr = new(); tr = new(5); // dst uses default
endprogram endprogram
Static attribute 67
 How do I create a variable shared by all objects of a

class, but not make a global?
 A static property is associated with the class
definition, not the instantiated object.
 It is often used to store meta-data, such as number of
instances created
 It is shared by all objects of that class.
class Transaction;
Using a id field can
static int count = 0;
help keep track of
int id;
transactions as they
… flow through test
function new();
id = count++;
endfunction
endclass

Assignment is not a copy 68
 Assignment of one handle to another only affects

the handles. It does not copy data
class Thing;
int data;
endclass
… t1
Thing t1, t2; // Two handles
initial begin
t1 = new(); // Allocate first thing data=1
t1.data = 1;
t2 = new(); // Allocate second
t2.data = 2; t2
t2 = t1; // Second Thing is lost
t2.data = 5; // Modifies first thing
$display(t1.data); // Displays “5”
end


class Thing;
int data;
endclass
… t1
initial begin
t1.data = 1;
t2.data = 2; t2
$display(t1.data); // Displays “5” data=2
end


class Thing;
int data;
endclass
… t1
initial begin
t1.data = 1;
t2.data = 2; t2
$display(t1.data); // Displays “5” data=2
end


class Thing;
int data;
endclass
… t1
initial begin
t1.data = 1;
t2.data = 2; t2
$display(t1.data); // Displays “5”
end

How to copy objects 72
 Assigning handles does not change objects

 To copy the data, pass it into new: t2 = new t1;
 This is a shallow copy, only data in top object is copied.
Your new() is not called!
t1 t1
id=5 id=5
body stuff body stuff
t2 t2
id=5
body
 SystemVerilog does not currently support deep
object copy – look for it in a future IEEE version
 To do a deep copy of all objects, make a copy() method
for all objects nested inside the class.
Inheritance 73
 How do I share code between classes?

 Instantiate a class within another class
 Inherit from one class to another (inheritance/derivation)
 Inheritance allows you to ‘add’ extra:
 Add extra Properties (data members)
 Add extra Methods
 Change the behavior of a method
 Common code can be grouped into a base class
 Additions and changes can go into the derived class
 Advantages:
 Reuse existing classes from previous projects with less
debug
 Won’t break what already works

Inheritance 74
Extended a class with new fields
 Add additional functionality to an existing class
class Transaction; Transaction

reg [31:0] src, dst, data[1024], crc; src dst
endclass
data crc
class BadTr extends Transaction; BadTr

rand bit bad_crc; bad_crc
endclass
BadTr bt;
bt = new; BadTr =
bt.src = 42; Transaction + bad_crc
bt.bad_crc = 1;

Inheritance 75
Override existing fields to a class
 Change the current functionality of a class
class Transaction;
reg [31:0] src, dst, data[1024], crc;
function void calc_crc(); Transaction
crc = src ^ dst ^ data.xor; src dst
endfunction
endclass data crc
calc_crc
class BadTr extends Transaction; BadTr

bad_crc
rand bit bad_crc;
function void calc_crc(); calc_crc
crc = super.calc_crc();
if (bad_crc) crc = ~crc;
endfunction
endclass

Inheritance 76
Error injection
 Create a transactor that works with a base object
 Extend the transaction class to inject errors
 Send these into the transactor from the test
class Driver;
task send(Transaction tr);
tr.calc_crc();
// Drive interface signals
endtask
endclass
class Transaction; program

program good_test;
BadTest;
virtual function void calc_crc(); Transaction tr;
BadTr bt = new;
endclass task
task main();
main();
assert(tr.randomize());
assert(bt.randomize());
class BadTr extends Transaction; my_driver.send(tr);
rand bit bad_crc; my_driver.send(bt);
endtask
endtask
functionfunction
virtual void calc_crc();
void calc_crc(); endprogram
endclass endprogram
Overriding Methods 77
Inheritance allows methods to be overridden
 By default, a method is found using the handle type
 What happens when extended object is referenced
by a base handle?
class Transaction; task main(); Transaction
reg [31:0] crc; Transaction tr; src dst
function void calc_crc(); BadTr bt;
endclass tr = new(); data crc
bt = new();
class BadTr calc_crc
extends Transaction; tr.calc_crc();
bit bad_crc; bt.calc_crc();
BadTr
bad_crc
endclass tr = bt;
tr.calc_crc(); calc_crc
endtask
Oops, this extended object
just used base class method!
Polymorphism 78
Allow a single name refer to many methods
 Virtual – lookup method at runtime, not compile
 The object’s type is used to find the right method
 Analogous to virtual memory that can have many locations
class Transaction; task main(); Transaction
reg [31:0] crc; Transaction tr; src dst
virtual function void BadTr bt;
calc_crc(); tr = new(); data crc
endclass bt = new();
calc_crc
class BadTr tr.calc_crc();
extends Transaction; bt.calc_crc();
BadTr
bit bad_crc; bad_crc
virtual function void tr = bt;
calc_crc(); tr.calc_crc(); calc_crc
endclass Virtual method so… endtask
‘tr’ is really ‘bt’ => BadTr
=> call BadTr.calc_crc();
Handle Assignment 79
Handles for base and extended class
 The handles for the base and extended classes are
not interchangeable
 A base handle can not access extended properties
class Transaction;
reg [31:0] src, dst;
virtual function void calc_crc(); src, dst Base
endclass
class BadTr extends Transaction; bad_crc Extend

bit bad_crc;
virtual function void calc_crc();
endclass
Transaction tr;
BadTr bt, b2;
bt = new(); // Allocate extended object
tr = bt; // Assign to base handle
Compile check tr.calc_crc(); // Calculate CRC
b2 = tr; // Error! Not allowed
$cast(b2, tr); // Allow assign
Run-time check if ($cast(b2, tr)) // Check if legal
b2.calc_crc();
Inheritance 80
 Why do I want all this complexity?

 Driver will treat all transactions the same way
 Transaction class knows how to perform actions
 Cell.display()
 Print ATM cell data if I’m at ATM cell
 Print Ethernet MCA data if I’m an Ethernet packet
 Print Sonet frame data if I’m a Sonet frame
 Print USB packet data if I’m a USB packet
 Code calling display doesn’t need to know what type of

cell/packet ‘cell’ handle references
 Classes are self-contained, they know how to perform
actions on themselves based on their type
 Self-contained, robust, reusable code.

Agenda 81
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Randomization 82
 Why use randomization
 Randomization options
 Randomization of objects
 Class constraints and distributions
 In-line constraints and distributions
 Tricks and techniques

Randomization 83
Why Use Randomization?
 Automatic stimulus generation
 Change the characteristics of the data driving the DUT
 Random setting of parameters
 Select ports, addresses, operational parameters randomly.
Directed testing detects the bugs you expect.
Random testing detects the bugs you did not expect.
 A random test’s behavior depends on the seed

 If you run the same test with the same seed, you will get the
same behavior
 If you run the same test with many different seeds, you will get
the equivalent of many different tests

Randomization 84
Randomization Example rand: rolling dice
randc: dealing cards
class Transaction;
rand bit [31:0] src, dst, data[]; // Dynamic array
randc bit [2:0] kind; // Cycle through all kinds
constraint c_len
{ data.size inside {[1:1000]}; } // Limit array size
endclass
Transaction tr;
initial begin
tr = new();
send(tr);
end
endprogram

Randomization 85
Randomization of Objects
 Random variables
 rand – returns values over the entire range
 randc – random cyclic value up to 16 bits
 Object variables are randomized by randomize()
 The method is automatically available to classes with random
variables.
Always check
 Returns a 1 upon success, 0 on failure
randomize()
 Optional: pre_randomize() & post_randomize() void
functions which will be called automatically
 pre_randomize() – set up random weights
 post_randomize() – cleanup calculations like CRC
 Remember calc_crc ?

Randomization 86
Constraining Randomness
 Purely random stimulus takes too long to do something
interesting
 Specify the interesting subset of all possible stimulus with
constraint blocks
 You can define separate, non-overlapping constraints for different
tests
 Constraints and distribution weights can form the basis for a
“test writer interface” to your testbench
Your Testbench:
- all legal stimulus vectors
- all legal stimulus sequences
User-Created Test:
- subset of legal stimulus vectors
- subset of legal stimulus sequences SIM

Randomization 87
Class Constraints
 Constraint Blocks
 Made of relational expressions, not assignments
 Constraints can be dynamically enabled/disabled with:
handle.[constraint_name.]constraint_mode(1/0)
 Unsolvable or conflicting constraints cause a run-time error
constraint c_default {
data.size <= 1000;
data.size > 0;
kind == 0; // Equivalent, not assignment
cntrl inside {[2:10], 20, 40, [100:107]};
if (test_mode == CONGEST)
dest inside {[src-100:src+100]};
}
Disable this with:
constraint c_long {
handle.c_long.constraint_mode(0)
data.size > 5000;
}
Randomization 88
Distributions
 dist constraint
 Distribution weights can be variables or constants
 Weighted probabilities
:= assigns weight to each element
:/ divides weight evenly in range
Value Dist
0 30/210
1 60/210
constraint c_0 {
2 60/210
src dist {0:=30, [1:3]:=60}; 3 60/210
dst dist {0:/30, [1:3]:/60};
} Value Dist
0 30/90
1 20/90
Distributions do not have to add up to 100% 2 20/90
3 20/90

Randomization 89
In-Line Constraints and Distributions
 Constraints may be defined at the time of randomization
 Allows test-specific constraints
 Don’t modify the original class for just a single test
 In-line constraints are additive with existing class constraints
 Supports all SystemVerilog constraints and distributions
class Transaction;
rand bit [31:0] src, dst, data[1024];
constraint valid {src inside{[0:100], [1000:2000]}; } src: 50-100,
endclass 1000-1500
dst<10
initial begin
Transaction t = new();
s = t.randomize() with {src >= 50; src <= 1500; dst < 10;};
driveBus(t);
// force src to a specific value

s = t.randomize() with { src == 2000; dst > 10;}; src==2000
driveBus(t); dst>10
end
Randomization 90
SystemVerilog requires a strong constraint solver!
 The solver has to handle algebraic factoring, complex Boolean
expressions, mixed integer and bit expressions and more
 All constraints interact bidirectionally and are solved
concurrently
 Keep in mind rules regarding precedence, sign extension,
truncation and wrap-around when creating constraints
class Parameters;
rand bit [15:0] a, b, c, d, e, f;
constraint c_0 {
(a + b) < 4;
0<c; c<d; d<e; e<150;
f == e % 16’d6; // Restrict width for: * % /
}
endclass
Randomization 91
Constraint constructs in SystemVerilog
 Conditional operator: if … else if … else
 Behaves like a procedural “if”, except the conditionals
are evaluated bi-directionally. Equivalent to implication.
 Implication Operator: ->
 Short version of “if”
 Ex: (mode == SMALL) -> (data.size < 10);
 Global Constraints: x < other_object.y;
 References to rand object data members in the
constraints get solved simultaneously
 Variable ordering: solve x before y;
 Otherwise VCS solves all constraints simultaneously

Randomization 92
Array constraints
 Create a random array
 Constrain its size, individual elements, or all elements
class C;
rand bit [5:0] a[];
Array size constraint cc {
a.size inside {[1:5]}; // Output
array[0] > 0; a[0] = 1;
Single element a[1] = 2;
foreach (a[i])
if (i > 0) a[2] = 33;
Multiple elements
a[i] > a[i-1]); a[3] = 39;
} a[4] = 40;
function void pre_randomize;
a.delete; // Needed in 2005.06
endfunction
endclass

Randomization 93
Array Constraints
 Set valid on 3 cycles out of 5
class ValidOn;
rand bit valid[5];
constraint cv
{valid.sum == 32’d3;}
endclass
 Two foreach loops with relationships

 Constraints solved class E;
simultaneously rand bit [15:0] x[10], y[10];
 x[] in 1:8 constraint size_cons {
foreach (x[i]){
 y[] in 2:9 x[i] > 0; x[i] < y[i];
foreach (y[i])
y[i] inside {[1:9]};
}
endclass
Randomization 94
Tricks and Techniques
 Watch out for signed variables
 What are legal values for first and second?
class Environment;
first second
rand byte first, second;
constraint c { 9. ‘h09 20. ‘h14
first + second < 8’h40; 85. ‘h55 -70. ‘hba
} -20. ‘hec -32. ‘he0
endclass
class Nesting;
 Make instances rand rand SubClass data;
endclass
 Or they won’t be randomized
 Don’t call randomize() in new() constructor
 Test may want to change constraints first
 Use rand_mode to make a variable random / non-random
 env.first.rand_mode(0);
 Just replace result of randomization for a directed test
Randomization 95
More Tricks and Techniques
 Need to modify a constraint in a test?
 Use a variable in the constraint
rand int size;
int max_size = 100;
constraint c {
size inside {[1:max_size]}; }
 Extend the base class to override original constraint

class Base; class Bigger extends Base;
rand int size; constraint c {
constraint c { size inside {[1:1000]};}
size inside {[1:10]};} endclass
endclass
 Use constraint_mode() to turn it off

Randomization 96
Procedural randomization
 Want to randomize without a class?
 Use randcase or $urandom_range
randcase
1: len = $urandom_range(0, 2); // 10%: 0, 1, or 2
8: len = $urandom_range(3, 5); // 80%: 3, 4, or 5
1: len = $urandom_range(6, 7); // 10%: 6 or 7
endcase
 Good for creating single variable, stateless

code, or nested set of actions
 Constrained randomization is easier to modify,
and can make state variables for scoreboard
 The bad_crc variable can be used for both
generating stimulus and checking the response

Agenda 97
 Introduction
 Getting Started
 Language Basics
 Connecting to HDL
 OOP Basics
 Randomization
Controlling Threads 98
 The power of parallel threads
 Concurrency defined
 Creating and controlling threads
 Communication between threads

The Power of Threads 99
Concurrency is Essential for Verification
Port0 port0
Data Self-
port1 port1
Generation DUT Checking
--- ---
Create stream of
port7 port7 Check received
transactions
transactions
Functional
Coverage
Sent transactions to all

ports?
FIFO overflow checked?

Threads 100
Fork / Join fork

execute();
The execute() task runs in parallel begin
with the begin-end block. The tasks generate();
check();
generate() and check() run serially.
end
join_none
fork fork fork
join join_any
join_none

Threads 101
Creating and Controlling Threads:
 fork / join | join_none | join_any create threads
 disable label; terminate just the named block
 disable fork; terminate all child threads below the current
context level
 Use carefully – may stop more threads than you wanted!
 wait fork; suspend a process until all children have completed
execution
 wait (expression) suspend a process until the expression is true
 Level sensitive
 @(edge-exp) suspend a process until the edge-exp value changes

 Edge sensitive

Threads 102
 If there are multiple threads ready to execute at a given

simulation time, their order of execution is
indeterminate
 Execution order for threads scheduled at the same time
can be manipulated within the code
// Timeout example
fork : check_block
wait (arbif.cb.grant == 1); // May never complete
#1000 $display(“@%0d: Error, grant never received”, $time);
join_any
disable check_block;

Communication Between Threads 103
Mailbox
Exchange messages / objects between two threads
Features
FIFO with no size limit
get/put are atomic operations, no possible race conditions
Can suspend a process
Default mailbox has no data type
Queuing
of multiple threads is fair
mailbox mbx; // Declare a mailbox
mbx = new(); // allocate mailbox
mbx.put(p); // Put p object into mailbox
mbx.get(p); // p will get object removed from FIFO
success = mbx.try_get(p); // Non-blocking version
mbx.peek(p); // Look but don’t remove, can block
success = mbx.try_peek(p); // Non-blocking version
count = mbx.num(); // Number of elements in mailbox
Mailbox Example
program mailbox_example(…);
mailbox mbx = new();
Generator g = new(); Get data from mailbox
Driver d = new();
initial begin class Driver;
fork Allocate mailbox Transaction t;
g.main();
d.main(); task main;
join repeat (10) begin
end mbx.get(t);
endprogram @(posedge busif.cb.ack);
busif.cb.addr <= t.addr;
class Generator; busif.cb.kind <= t.kind;
Transaction t; …
task main; end
repeat (10) begin endtask
t = new();
assert(t.randomize());
mbx.put(t);
end
endtask
endclass
Put data into mailbox
Semaphore
Used for mutual exclusion and synchronization.
Features
Variable number of keys can be put and removed
Controlled access to a shared object, such as sharing a bus from models
Thinkof two people wanting to drive the same car – the key is a
semaphore
Be careful – you can put back more keys than you took out!
Syntax
semaphore sem;
sem = new(optional_initial_keycount = 0);
sem.get(optional_num_keys = 1);
sem.put(optional_num_keys = 1);

Semaphore Example
semaphore sem;
initial begin Allocate a semaphore, 1 key available
sem = new(1);
…
fork
task sequencer();
sequencer();
repeat($random()%10) @bus.cb;
sequencer();
sendTrans();
join
endtask
end
…
task sendTrans();
sem.get(1);
@bus.cb;
bus.cb.addr <= t.addr;
Wait for bus to be available bus.cb.kind <= t.kind;
bus.cb.data <= t.data;
When done, replace key sem.put(1);
endtask
endprogram
Events
Synchronize concurrent threads
Features
 Synchronize parallel threads
 Sync blocks process execution until event is triggered
 Events connect triggers and syncs
 Can be passed into tasks
event ev; // Declare event
-> ev; // Trigger an event
@ev; // Block process, wait for future event
wait (ev.triggered); // Block process, wait for event,
// including this timeslot
// Reduces race conditions
driver = new(ev); // Pass event into task

Event Example
Main Testbench Generator transactor
event gen_done[4]; class Generator;
event done;
Generator gen[4]; // Pass event from TB
function new (event done);
initial begin this.done = done
// Instantiate testbench endfunction
foreach (gen[i])
gen[i] = new(gen_done[i]); task main( );
fork
// Run transactors begin
gen[i].main(); // Create transactions
… -> done;
end
// Wait for finish join_none
foreach (gen[i]) endtask
wait(gen_done[i].triggered);
end endclass
Lab 2 109
Verify the APB Interface, Part 1
 Objective
 Write a structured testbench to learn more about classes,
randomization, threads and mailboxes
 Verify that a basic transaction can be created, randomized, and
sent through the design
 Time Allotted
 1 hour

Lab 2 110
apb_trans
apb_gen
apb_mbox
apb_master DUT

Agenda 111
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Virtual Interfaces 112
 Virtual interfaces
 Why are they needed?
 Creating virtual interfaces
 Connecting to physical interfaces
 Using in classes and methods

Virtual Interfaces Advanced
 Allow grouping of signals by function topic
 Create a handle to an interface
 Virtual interfaces can be passed to routines with different values.
 Promotes reuse by separating testbench from implementation
names
enable_1
soc_1
data_1[7:0]
RX_1
4x4
enable_3
ATM
soc_3
data_3[7:0]
RX_3 Switch

The Five Steps to Virtual Interfaces
1. Define physical interfaces
Use clocking blocks and modports
2. Connect the interfaces
Usually in top netlist
3. Create procedural code that uses virtual interface
A generic method that is not tied to any one interface
4. Create virtual interface & connect to physical
Procedural code in testbench
5. Use virtual interfaces with classes and methods
A generic method can operate on many interfaces

Virtual Interfaces Syntax
 STEP 1: Define a physical interface
// ATM Rx interface
interface Rx (input logic clk);
logic [7:0] data;
logic soc, en, clav;
clocking Rcb @(posedge clk);

output data, soc, clav; // Relative to
input en; // testbench
endclocking : Rcb
modport DUT (output en, // DUT connection

input data, soc, clav);
modport TB (clocking Rcb); // TB connection

endinterface : Rx

Binding signals to a physical interface
 STEP 2: Connect the interface
Interface
module top; instances
Interface logic clk = 0;
name
Rx Rx0(clk), Rx1(clk), Rx2(clk), Rx3(clk);
Tx Tx0(clk), Tx1(clk), Tx2(clk), Tx3(clk);
atm_switch a1 (Rx0, Rx1, Rx2, Rx3,

Tx0, Tx1, Tx2, Tx3, clk);
test t1 (Rx0, Rx1, Rx2, Rx3,

Tx0, Tx1, Tx2, Tx3, clk);

endmodule : top

Define virtual interface
 STEP 3: Define procedural code that uses virtual
interface Interface
class Driver; & modport
virtual Rx.TB Rx;
function new(virtual Rx.TB Rx);

this.Rx = Rx; // Initialize VI
endfunction
task sendCell();
Rx.Rcb.soc <= 0; // Drive signal w/clocking block
...
endtask
endclass

Using Virtual Interfaces
 STEP 4: Define virtual interface & connect to physical
 STEP 5: Call routine with virtual interface variables
program automatic test(Rx.TB Rx0, Rx1, Rx2, Rx3, … );
`include “driver.vh”
Driver driver[4];
virtual Rx.TB vRx[4];
initial begin
vRx[0] = Rx0; …
for (int i=0; i<4; i++)
driver[i] = new(vRx[i]);
driver[$random % 4].sendCell(); // Send to random port
end
One variable in the method references different connections.
This allows for a single class to operate on many physical interfaces.
Lab 3 119
Verify the APB Interface, Part 2
 Objective
 Create virtual interfaces for communication between
design and testbench
 Time Allotted
 1 hour

Lab3 120
mon2scb
apb_trans scoreboard
apb_gen mas2scb
apb_monitor
apb_mbox
apb_master DUT

Agenda 121
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Functional Coverage Example 122
Have I tried all transaction kinds?
program automatic test(busifc.TB ifc);
class Transaction;
rand bit [31:0] src, dst, data;
rand bit [ 2:0] kind;
endclass
covergroup CovKind;
coverpoint tr.kind; // Measure coverage
endgroup
Transaction tr = new(); // Instantiate transaction
CovKind ck = new(); // Instantiate group
initial begin
repeat (32) begin // Run a few cycles
ifc.cb.kind <= tr.kind; // Transmit transaction
ifc.cb.data <= tr.data; // onto interface
ck.sample(); // Gather coverage
@ifc.cb; // Wait a cycle
end
end
endprogram
Sample HTML Reports 123

Coverage Group 124
Define your coverage model
 Encapsulates the coverage specification (bins, transitions)
for a set of coverpoints and cross combinations of
coverpoints
 Variables in a group belong together:
 Data members of a class
 Cross coverage across these variables
 Sample them on the same event (trigger)
 Write specification once (just like a class definition),
Instantiate many times
covergroup CovKind @(posedge ifc.cb.valid);
coverpoint global;
coverpoint ifc.cb.kind;
The variable global and
endgroup
signal ifc.cb.kind are
…
sampled every posedge
CovKind ck = new;
of ifc.cb.valid signal

Embedded Coverage Group 125
Embed covergroup in a class
 Easy way to cover a subset of the members of a class
 You must instantiate the coverage group to gather results
 For efficiency, put coverage groups in “static” objects
 A simulation could have 10,000 transactions, but just 1 driver object
 SystemVerilog automatically creates bins for cover points
without having to specify the bins explicitly
class Driver;
bit [3:0] x, y;
covergroup cg;
coverpoint x;
coverpoint y; Members x and y will be
endgroup sampled on the active
function new; edge of the ifc.cb clock.
cg = new;
endfunction
endclass
Automatic Bin Creation (Example 1) 126
bit [3:0] x, y;
covergroup Cov1;
coverpoint x;
coverpoint y;
endgroup
…
Cov1 c1 = new();
x = 1; Level where
y = 8; coverage “counts”
c1.sample();
x = 2;
c1.sample();
x = 15;
y = 9;
c1.sample();

bit [3:0] x, y;
covergroup Cov1;
coverpoint x;
coverpoint y;
// Divide ranges in 1/2
option.auto_bin_max = 2;
endgroup
…
Cov1 c1 = new();
x = 1;
y = 8;
c1.sample();
x = 2;
c1.sample();
x = 15;
y = 9;
c1.sample();

User Defined Coverage Bins for Coverpoints 128
 User defined bins for coverage using ranges of values

 Bin lo is associated with values of port_number between 0 and 1
 Bin hi_4 to hi_7 are associated with values between 4 and 7
 Bin misc is associated with values 2 & 3
 Transition bin t1 is associated with any value transition (single) of
port_number from 0=>1, 0=>2, 0=>3
logic [2:0] port_number;

covergroup CovPorts; 0: lo
1: lo
coverpoint port_number { 2: misc
3: misc
bins lo = {[0:1]}; // 1 bin for 2 values 4: hi_4
bins hi[] = {[4:$]}; // 4 separate bins 5: hi_5
6: hi_6
bins misc = default; // Unspecified values 7: hi_7
bins t1 = (0=>1), (0=>2), (0=>3); // transitions
}
endgroup
 If you create bins with the [] syntax, VCS will not create new bins for
values that are out of bounds
bit [3:0] x, y; Coverage

covergroup Cov1; holes
coverpoint x {
bins s[] = {[0:4]};
}
coverpoint y;
endgroup
…
Cov1 c1 = new();
x = 1;
y = 8;
c1.sample();
x = 2;
c1.sample();
x = 15;
y = 9; Out of bounds
c1.sample(); value ignored

Cross Coverage 130
 Specified in the coverage group using cross

 Cross argument can be a coverpoint or variable
 Bins are automatically created for the cross products
bit [3:0] global
class MyClass; Use label for
bit [4:0] y; coverage report
covergroup cg;
cc1: cross y, global;
endgroup
function new;
cg = new;
endfunction
endclass
…
MyClass obj1 = new();
obj1.y = ‘h14;
global = 2;
obj1.cg.sample();
obj1.cg.sample();
obj1.y++;
obj1.cg.sample();
Defining the Sample Event 131
 Specifying the coverage event

 You can specify an event expression in the coverage group
definition. This will be used for all instances of a coverage
definition.
 Or use instance.sample();
 Valid event expressions
 @SV_event;
 @(SV_variable);
 You can use interface signals, including ones in clocking
blocks
 Values are sampled upon occurrence (triggering) of the
coverage event expression

Assertion Coverage 132
 A covergroup can react to a SystemVerilog Assertion

 Use SVA action block to trigger event,
 Have covergroup sample on event
covergroup Write_cg @$root.mem.write_event;

coverpoint $root.mem.data;
coverpoint $root.mem.addr;
option.auto_bin_max = 2; SVA
endgroup
module mem(simple_bus sb);
Write_cg wcg; bit [7:0] data, addr;
event write_event;
initial begin cover property
wcg = new(); (@(posedge clk) write_ena==1)
-> write_event;
// Apply stimulus here
// Other logic here
#10000 $finish; endmodule
end
endprogram
Coverage 133
Databases
 VCS writes coverage data to a binary database file
 The database file is named simv. db
 VCS report formats
 HTML > urg –dir simv.vdb
 Text: > urg –dir simv.vdb –format text
 HTML data presented hierarchically using hypertext links
 $set_coverage_db_name ( name );
 Sets the filename of the coverage database into which
coverage information is saved at the end of a simulation run.
 $load_coverage_db ( name );
 Load from the given filename the cumulative coverage
information for all coverage group types.

Agenda 134
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Starting Point : Design Spec and Test Plan 135
Design Spec:
• A packet consists address in valid address range and variable
sized payload.
• The valid address range is between 0 and 8’hBF.
• Data length support is max 1024 bytes transfers
Test Plan (Partial):

 Define 3 address regions as [0:0x3F], [0x40:0x7F]
and[0x80:0xBF].

More Complete Class Example 136
 Classes are containers of data objects, transactors, generators,
verification environments, etc.
class packet;
typedef enum {WRITE, READ} transtype_t;
Data rand bit [`ADDR_WIDTH:0]addr;
Members rand bit [`DATA_WIDTH-1:0] data[];
rand transtype_t trans_type;
constraint addr_c {
Constraint addr inside {[0:8’hBF]};
Block }
constarint data_c {
data.size <= 1024;
}
Procedural
Code task display();
$display(“ %s, %h”, pkt.trans_type.name(), a
endtask
Coverage
covergroup pktCov;
Group coverpoint addr,data,trans_type;
endgroup
endclass
Coverage Driven Verification 137
 Start with a fully randomizable testbench

 Run many randomized simulation runs
 Analyze cumulative coverage and coverage holes
 Then with minimal code changes:
 Add constrained stimulus to fill coverage holes
 Make few directed tests to hit the remaining holes
Constrainable Many runs,

Random Generation different seeds
Directed
Add Testcase Functional
constraints Coverage
Minimal Code Identify

Modifications holes
Capture Input Stimulus and Randomize 138
Design Spec: A packet consists of a destination address and a
variable sized payload.
Implementation: Declare variables as rand so constraint solver will
fill with random values.
Packet Class Basic Test

class packet;
packet pkt;
rand bit [31:0]addr;
rand bit [7:0] data[]; initial begin
rand transtype_t trans_type; pkt = new();
repeat(50) begin
endclass
pkt.randomize();
transmit(pkt);
end
end
endprogram
Constrain the Randomness (Design Spec) 139
Design Spec:
• Size of the payload is between 0 and 1024 bytes.
Implementation:
• Without constraints, VCS solver generates random data which may be
illegal and will either be ignored by device or result in errors. Add a new
control field pktSize.
class packet;
rand bit [7:0] data[];
rand transtype_t trans_type;
rand bit[7:0] pktSize;
constraint packetSize_c {
pktSize inside {[0:1024]};
data.size() == pktSize;
}
endclass
Constrain the Randomness (Design Spec) 140
Design Spec:
• The valid address range is between 0 and 8’hBF.
• Address 8’hBB is not writable
Implementation: See below.
class packet;
rand bit [7:0] data[];
... Implication
rand transtype_t trans_type; Constraints
constraint addr_c {
(trans_type == WRITE) -> addr != 8'hBB;
addr inside {[0:8’hBF]};
}
endclass

Directed Random Testing 141
Test Plan:
 Test device with WRITE type , data size 20 bytes at address
8’h55.
Implementation:
 Override constraint custom_c. Same testbench as before.
constraint packet::custom_c {
pktSize == 20;
trans_type == WRITE;
addr == 8’h55;
}

Change Default Distribution 142
Test Case:
 Test device with 80% WRITE and 20% READ.
Implementation:
 Use distribution constraint to change probability
 Minimal declarative changes needed for new testcase
Packet Class Test with 20% READ trans

class packet; constraint packet::custom_c {
rand address_e addrTyp; trans_type dist {WRITE:=80, READ:=20
.
. program automatic test;
constraint custom_c; packet pkt;
initial begin
endclass
pkt = new();
pkt.randomize();
transmit(pkt);
end
endprogram
Directed Random Stimulus Generation 143
Test Plan: Inject the device with 50 WRITE packets mostly targeting the
hi_range of addresses.
Implementation: Add a test specific constraint to direct generation to
the area of interest. Create an instance of the packet class in the test and
randomize 50 times.
constraint packet::custom_c {
addr dist {[8’h80:8’hBF] := 90, [0:8’h7F] := 10};
trans_type == WRITE;
}
packet pkt;
initial begin
pkt = new();
repeat(50) if (pkt.randomize())
transmit(pkt);
end
endprogram
Derive Coverage Model From Test Plan 144
Test Plan:
• Define 3 address regions: 0:0x3F, 0x40:0x7F and 0x80:0xBF
• Test with packets of all types = 2 bins
• Test with packets targeted to all address regions = 3 bins
• Test with all permutations of all packets types to all address
regions = 6 bins
• Implementation:
• Do not write directed test for each test item
• Instead map each test item into an executable coverage point
• Run random suite of tests and collect functional coverage.
• Analyze coverage results and to improve functional coverage
either run more random tests or for hard-to-reach coverage
points create a more constrained test (Directed random).

Implement Coverage Model 145
covergroup pktCov;
coverpoint trans_type; // Creates 2 bins
coverpoint addr { // Item 2: Creates 3 bins
bins low_range = {[0:0x3F]};
bins mid_range = {[0x40:0x7F]};
bins hi_range = {[0x80:0xBF]};
}
cross trans_type, dst; // Item 5: Creates 6 bins
endgroup

Lab 4 146
Implementing Coverage
 Objective
 Add functional coverage to the APB Interface
 Create a constrained random test
 Use this test to make directed test
 Analyze the functional coverage in URG
 Time Allotted
 1 hour

Agenda 147
 Introduction
 Getting Started
 Language Basics
 OOP Basics
 Randomization
Testbench Methodology 148
 Reference Verification Methodology
 Testbench Structure
 Simple Testbench Building Blocks

Testbench Methodology - Architecture 149
Layers
 Constrained random tests
Test Tests
Scenario Generators
Functional Coverage
Functional Transactor Self Check Checker
Command Driver Assertions Monitor
DUT
Signal

Testbench Methodology - Overview 150
 How do you use these concepts such as OOP and

randomization to build a verification environment?
 Synopsys’ Verification Methodology Manual (VMM)
contains guidelines, coding styles, and base
classes
 Based on many years of experience
 This is an overview to show basic concepts,
highlights of the VMM 2-day class
 This does NOT show how to use VMM base classes

VMM Methodology 151
Guiding Principles
 Maximize design quality

 More testcases
 More checks
 Less code
 Approaches
 Reuse
 Across tests
 Across blocks
 Across systems
 Across projects
 One verification environment, many tests
 Minimize test-specific code
 Assertions
 VMM Methodology emphasizes

“Coverage Driven Verification”
Transactions and Transactors 152
 Transaction Data models  Interfaces

 Variant data  Transaction interface
 Error protection  Physical interface
properties  Sub-layering
 Standard methods
 Reusable transactors
 Constraints
 Starting & stopping
 Transaction objects  Notifications
 Objects vs. procedures  Integrating scoreboards
 Transaction response  Adding functional
 Transactor Categories coverage
 Master vs. slave  Injecting errors
 Driver vs. monitor  Customization and
extensibility

Data & Transactions 153
Implementation
class Transaction;
 Data modeled using classes rand enum {READ, WRITE}
kind;
 Packets rand bit [ 7:0] sel;
 Frames rand bit [31:0] addr;
rand bit [31:0] data;
 Cells endclass
 Instructions
 Pixels
 Samples
 Flows through the verification environment
 100,000+ instances created and freed during a
simulation
 100+ in existence at any given time
 Duplicated only when necessary

Data & Transactions 154
Flow
Tests
Created Accumulated Freed
here here here
Generators
Duplicated
here
Transactor Scoreboard Checker
Driver Assertions Monitor
Created
Freed DUT here
here

Transactions 155
Generating Transactions
 Simple to generate random streams of data

Transaction tr;
tr = new;
apb.do(tr);
 Can use constraints and solver

 Add or override constraints via extensions
 Constraints across multiple instances
class my_tr extends Transaction;
constraint available_targets {
sel inside {[0:3]};
if (sel == 0 && kind == READ) {
addr inside {[0:15], 27, 31};
} else {
addr < 31;
}
}
endclass
Transactions 156
Transaction Interface
 Can use transaction interface object

 Transactors connected via objects
sw_driver sw_driver
mbx.put(tr);
apb.write(...);
Mailbox
apb_master
task write(...); mbx.get(tr);
apb_master
Procedural Interface
interface object

Transactions 157
Transaction Interface Objects
 Can mix and match transactors without

modifications
mii_phy
phy.get(tr);
Test
eth_gen mac_layer
gmii_phy
mac.get(tr); phy.get(tr);
mac.put(tr); phy.put(tr);
xgmii_phy
phy.get(tr);

Transactors 158
 Building blocks of the verification environment

 Transactors modeled using classes
 Bus-functional models
 Functional layer components
 Generators
 Few instances
 Created at the start of simulation
 Remain in existence for duration
 Data and transactions flow through them
 Scheduling
 Transformation
 Processing

Transactor 159
Categories
 Active Transactors – Master

 Initiate transactions
 Supply data to other side
 Example: AHB master, Ethernet Tx
 Reactive Transactor – Slave
 Transaction initiated by other side
 React by supplying requested data
 Example: AHB slave
 Passive Transactor – Monitor
 Transaction initiated by other side
 Collect transaction data from other side
 Slave monitor example: AHB bus monitor

Creating a transactor 160
 Main routine contains loop that receives a

transaction, processes it, and sends it out.
class apb_xactor;
function new(mailbox mgen, mdrv); generator
(xactor)
task main();
forever begin
mgen.get(t); transactor
// process transaction t (xactor)
mdrv.put(t);
end
endclass
driver DUT
(xactor)

Generators 161
 Randomizable objects
 Data streams
 Configuration
 Error injection
 Election
 Atomic generators atomic generator
blueprint
 Modifying constraints Copy
 Run-time generator control
 Inserting directed stimulus
scenario generator
 Scenario generators scenario
 Atomic scenarios
 Grammar-based scenarios
 Defining new scenarios
 Modifying scenario distributions
Randomizable Aspects 162
Disturbance Injection
 Variations specific to a level of abstraction

 Delay
 Collisions
 Abort/Retry
 No handshake
 Data corruption
 Ordering
 Should be controlled in relevant transactor
 Not at transaction source
Generate MAC-level Generate MII-level
disturbances here disturbances here
Not here
eth_gen mac_layer mii_phy

Randomize DUT & TB Configuration 163
Configurations
 Generated by verification environment

verif_env
cfg_gen

Generates
one instance
Used to
build
class cfg;
... ahb_mstr
endclass
Downloaded
into DUT via...

Self-Checking Functionality 164
 Entirely DUT-specific
 Can only detect errors
 Detected errors identified in planning stage
 Each error detection mechanism part of coverage model
 Ensure that opportunity to check error existed
 No error was actually found
 Can be implemented in different ways

 Transfer function + Scoreboard
 Reference model
 Maybe in different language
 Off-line
 Assertions
 Self-Checking methodology is a full day topic

Generator Design 165
Controllable Aspects
 Good controllable random generators don't

"just happen"
 Design constraint controls
 Plan for trivial testcases
 Generate only 1 object
 Generate simple objects
 Plan for corner cases
 Scenarios
 Synchronization
 Plan for directed stimulus
 Interruption
 Reactivity

Verification Environment 166
Execution Flow
 All testbenches must have the same execution flow

 Some steps may be blank Randomize test
 Extend base environment to configuration descriptor
implement DUT-specific
Allocate and connect
environment
environment components
 Basic flow is: Download test
 pre-test configuration into DUT
 run-test Start components
 post-test
End-of-test detection threads
(ends when returns)
Stop data generators &

Wait for DUT to drain
Check recorded stats &

sweep for lost data

Onward! 167
 Where do I go next?
 Complete the labs / and QuickStart
($VCS_HOME/doc/examples)
 Read the Verification Methodology Manual
 Take the VMM-Basic and Advanced classes
 Please let us know your feedback on this training

vcs-support@synopsys.com
 THANK YOU!!!

SystemVerilog Testbench

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SystemVerilog Testbench

Uploaded by

Copyright:

Available Formats

Introduction to

SystemVerilog for Testbench

By the end of this class, you should be able to:

 Develop self checking testbenches using VCS and

SystemVerilog Testbench with VCS 05/07/2007

SystemVerilog for Verification

SystemVerilog Testbench with VCS

SystemVerilog Testbench with VCS

 To maximize design quality

SystemVerilog Testbench with VCS

SystemVerilog Testbench with VCS 05/07/2007

 Measure progress using functional coverage

SystemVerilog Testbench with VCS 05/07/2007

 Environment Creation takes less time

SystemVerilog Testbench with VCS 05/07/2007

What are We Going to Discuss?

 SystemVerilog Testbench Verification Flow

SystemVerilog Testbench with VCS 05/07/2007

Compiling and Running with VCS

See the VCS User Guide for all options

Legacy Code Issues

// Old Verilog-1995/2001 legacy code

SystemVerilog Testbench with VCS 05/07/2007

Documentation and Support

 On-line knowledge database

SystemVerilog Testbench with VCS 05/07/2007

How Should You Connect to DUT

SystemVerilog Testbench with VCS 05/07/2007

Steps to hook up a DUT to a Testbench

1. Create DUT interface with

SystemVerilog Testbench with VCS 05/07/2007

SystemVerilog Testbench with VCS 05/07/2007

interface simple_bus; module mem( module cpu(

 Signals with multiple drivers must be wire

module cpu(simple_bus.MASTER sb, module mem(simple_bus.SLAVE sb,

modport DUT (input clk,

SystemVerilog Testbench with VCS 05/07/2007

SystemVerilog Scheduling Details

REGION Prepone Active Observed Reactive Postpone

ACTIVITY sample design assertions testbench $monitor

Previous Current Next

SystemVerilog Testbench with VCS 05/07/2007

 Create testbench program: test.sv Step 2

program test(arb_if.TB arbif); clk

 Assignment will happen at next active clock edge

 Synchronize to any edge of signal

 Wait for N clock cycles with ##n – blocking statement

SystemVerilog Testbench with VCS 05/07/2007

SystemVerilog Testbench in Simulation

module top; // Synchronous TB

interface arb_if (input bit clk);

SystemVerilog Testbench with VCS 05/07/2007

dstate = top.dut.state; // Immediate XMR sample

SystemVerilog Testbench with VCS 05/07/2007

Check signal values

program test (arb_if arbif);

SystemVerilog Testbench with VCS 05/07/2007

Check signal values

program test (arb_if arbif);

SystemVerilog Testbench with VCS 05/07/2007

> vcs -sverilog -debug

SystemVerilog Testbench with VCS 05/07/2007

What are We Going to Discuss?

 This class assumes you already know most Verilog-1995