Automating UVM Testbench Generation and Code

Management

Shakerin Ahmed, Naveed Mahmud

Ulkasemi Private Limited

House #430, Road #7, Baridhara DOHS, Dhaka-1212, Bangladesh

www.ulkasemi.com

ABSTRACT

It is well established that functional verification takes up a hefty portion of electronic design
process. Standard verification methodologies such as UVM is commonly used in the build
process of testbenches and Verification IP to increase productivity and reusability. We propose a
script based methodology for reducing verification process time by expediting creation of UVM
and System Verilog class based testbench code. Our proposed method involves systematic and
user controlled generation of code templates to build up an entire UVM testbench framework.
This script based utility can be used for automatically creating testbench files, writing
appropriate codes in corresponding files and adding any components to the existing testbench
during the whole process of verification. A graphical user interface has also been developed for
easier control of the utility. Users can create entire testbench hierarchy from scratch and add
individual components to existing testbench environment.
 Table of Contents
1. Introduction ........................................................................................................................... 6
2. UVM Testbench Structure .................................................................................................... 6
3. Testbench Code Generation and Management ..................................................................... 7
3.1. Creating Whole Testbench Structure .................................................................................... 7
3.2. Adding New Components .................................................................................................. 8
3.3. Managing Testbench............................................................................................................ 8
3.4. Generate Testbench from Graphical User Interface ........................................................... 8
4. Scripts used for Testbench Automation and Management ................................................... 8
5. Testbench Generation from Terminal ................................................................................. 11
5.1. Terminal Commands .......................................................................................................... 11
5.1.1. Creating New Class/es ................................................................................................. 11
5.1.2. Creating Instances of Existing Classes......................................................................... 13
5.1.3. Creating Port Connections ........................................................................................... 14
5.2. Creating Initial Testbench Structure from Terminal ......................................................... 15
5.2.1. Top File ........................................................................................................................ 15
5.2.2. Base Test File ............................................................................................................... 16
5.2.3. Environment File .......................................................................................................... 16
5.2.4. Other Generated Files................................................................................................... 18
5.3. Adding New Agent Class from Terminal ........................................................................... 22
5.3.1. Created Files ................................................................................................................. 22
5.3.2. Changes inside Existing Environment ......................................................................... 24
5.4. Adding New Environment Class to Existing Testbench from Terminal ............................ 26
5.4.1. Created Files ................................................................................................................. 26
5.4.2. Updated Files................................................................................................................ 27
6. Testbench Generation from GUI ........................................................................................ 28
6.1 Creating Whole Testbench .................................................................................................. 28
6.2 Adding an Environment....................................................................................................... 30
6.3 Adding an Agent .................................................................................................................. 31
7. Simulation Results .............................................................................................................. 33
8. Future Aspects .................................................................................................................... 35
8.1. Include More UVM Features .............................................................................................. 35
8.2. Different Structure Creation ............................................................................................... 35
8.3. Easier Management Tool .................................................................................................... 35
9. Conclusion .......................................................................................................................... 35
10. References ........................................................................................................................... 36

SNUG 2015 2 Automating UVM Testbench

Generation and Code Management
 Table of Figures
Figure 1 - Generic UVM testbench environment ........................................................................... 6
Figure 2 - Important portion of script hierarchy ............................................................................. 9
Figure 3 - Script for initial structure generation ............................................................................. 9
Figure 4 - Script for generating new environment class ............................................................... 10
Figure 5 - Script for creating instance of environment class inside base test file ......................... 10
Figure 6 - Script for declaring interface file at top level file ........................................................ 11
Figure 7 - Generated top file ......................................................................................................... 15
Figure 8 - Generated base test file ................................................................................................ 16
Figure 9 - Generated environment file (instantiation and build phase) ........................................ 17
Figure 10 - Generated environment file (connect phase and run phase) ...................................... 18
Figure 11 - Generated virtual sequence class ............................................................................... 19
Figure 12 - Virtual sequencer class ............................................................................................... 19
Figure 13 - Driver, monitor and sequence instances declared in agent class ............................... 20
Figure 14 - Connecting driver, monitor, sequencer in connect phase of agent class .................... 20
Figure 15 - Generated driver class ................................................................................................ 21
Figure 18 - Instances declared in new agent class ........................................................................ 22
Figure 19 - Created monitor file for new agent ............................................................................ 23
Figure 20 - Driver class generated for new agent ......................................................................... 23
Figure 21 - Agent instantiated automatically in environment class .............................................. 24
Figure 22 - Created agent instance in build phase ........................................................................ 24
Figure 23 - New code generated for new agent class in environment .......................................... 25
Figure 24 - Package file edited ..................................................................................................... 25
Figure 25 - Generated environment class ..................................................................................... 26
Figure 26 - Edited base test file .................................................................................................... 27
Figure 27 - Updated portion of package file ................................................................................. 27
Figure 28 - Graphical user interface for testbench generation ...................................................... 28
Figure 29 - Main window for generating entire testbench............................................................ 29
Figure 30 - Generated files using “Create entire testbench” GUI option ..................................... 29
Figure 31 - GUI window for adding environment ........................................................................ 30
Figure 32 - New environment files generated using “Add env” GUI option ............................... 31
Figure 33 - Adding an agent using GUI........................................................................................ 32

SNUG 2015 3 Automating UVM Testbench

Generation and Code Management
Figure 34 - New Agent files generated using “Add Agent” GUI option ...................................... 33
Figure 35 - Simulation of UVM ‘build’ and ‘connect’ phases ..................................................... 33
Figure 36 - End of simulation reports ........................................................................................... 34
Figure 37 - Command log entries ................................................................................................. 34

SNUG 2015 4 Automating UVM Testbench

Generation and Code Management
 Table of Tables
Table 1 - Commands for creating new classes/interfaces ............................................................. 12
Table 2 - Commands for creating instances of existing classes.................................................... 13
Table 3 - Commands for creating connection among instances using port .................................. 14

SNUG 2015 5 Automating UVM Testbench

Generation and Code Management
1. Introduction
In electronic design automation, functional verification is the task of checking and making sure
that design conforms to specification. In general, for most designs, there are many possible
scenarios and corner cases which have to be thoroughly verified by writing multiple test cases.

Verification process must be time efficient hence the right methodology must be followed for
verifying a particular design. Universal Verification Methodology is a much improved and
universal tool than its predecessors and has become the most widely used among verification
engineers since its advent. UVM based testbenches have robust, easily reusable structure and as a
result, improves the quality of verification. It has a base class library from which typical
components of a self-checking testbench can be extended. Developing a UVM testbench with
various class components and interconnections requires a significant amount of coding time,
especially for engineers unaccustomed to UVM and System Verilog. In this paper we propose an
automation methodology which will help accelerate development process of UVM testbenches.
To implement this we have developed a script based utility that can be used to generate code
templates for developing and managing any testbench in System Verilog using UVM. In the next
sections we will elaborate on generic UVM testbench structure, working methodology and
implemented features of the tool, the graphical user interface developed and simulation test
results.

2. UVM Testbench Structure

UVM is a popular methodology used in design verification and verification IP development. Its
built-in class library [1] is one of its main conveniences and its multi-vendor tool support and
industry standard features [2] has been crucial to its success. Self-checking UVM testbenches
generally fall into a common structure and organization with some typical verification
components [3]. For this reason our proposed automation methodology fits in perfectly with
UVM testbench development process. A UVM environment is very flexible and can be
configured according to the testbench developer’s needs. A generic UVM environment may be
similar to that shown in Figure 1.

uvm_top
test1 Env1
UVM agent - master
Env2
subscriber sequencer monitor driver
Design
testcases scoreboard Under
UVM agent - slave Test
virtual sequencer monitor driver
sequencer

Figure 1 - Generic UVM testbench environment

SNUG 2015 6 Automating UVM Testbench

Generation and Code Management
In verification process many testcases have to be developed and for certain cases the
environment has to be reconfigured. In large designs multiple environments may be needed. In
UVM, to add any component to the environment or to reuse existing classes, new components
have to be extended from uvm base classes or user defined classes. This gives the testbench
flexibility and reusability.

In the setup in Figure 1 there are multiple tests and each test contains one or more environments.
One particular test is shown in detail. It contains two different environments. ‘Env1’ contains a
‘Master’ and a ‘Slave’ agent component. The agents are built up of sub-classes such as driver,
monitor etc. The environment also contains components such as scoreboard, subscribers and
virtual sequencers. During testbench code compilation all UVM components are built following
a certain hierarchy.

Using our proposed methodology, one can develop such a testbench structure easily. The
structure contains a top level, base test, interface, environment and sub-components. The base
test contains an instance of the environment, and sub-components such as virtual sequencer,
scoreboard, agents etc. are instantiated inside that environment. Necessary interconnections
between sub-components are automatically made inside environment. The agents contain
instances of classes such as driver, monitor and sequencer. Virtual sequencer contains instances
of the local agent sequencers and connects to a virtual sequence which contains sequences. Test
instantiates and starts this virtual sequence. Scoreboard, subscriber and monitor contain
necessary ports for data transaction.

Using scripts, users can add any class component to the existing structure. In this way multiple
testcases, environments, agents, sequencers, monitors, etc. can be implemented in the testbench.
The tool options are discussed in detail in the following sections.

3. Testbench Code Generation and Management

The proposed script based utility can generate any UVM testbench structure automatically based
on provided user inputs. Also, there are options to add components and manage overall
testbench.

3.1. Creating Whole Testbench Structure

This script based utility makes it possible for users to create the whole testbench structure by
passing inputs through the terminal. User has to run a command “rtg tb $arg1 $arg2
....” to generate whole testbench structure code.The important arguments for executing this
command are: prefix for the generated files, top level file name, base test file name and base test
class name. Prefix will be added to all generated file names and it will also be used for naming
different class and instances throughout the testbench. Other three arguments are just for
generating top level and base test files. After executing this command 16 files will be generated
in the current working directory. Generated files include: top level, base test, virtual sequencer,
virtual sequence, environment, scoreboard, subscriber, agent and other sub-classes. A script is
generated along with the testbench so that the testbench can be simulated just after generation.

SNUG 2015 7 Automating UVM Testbench

Generation and Code Management
User has to write codes manually for necessary transaction inside driver, monitor and other
classes.This utility only generates codes that are not dependent on any protocol or design.

3.2. Adding New Components

After creating the initial testbench structure, user can add as many components as needed to the
existing testbench. It is useful for developing testbenches for verifying large SoCs. In such cases
user can just create individual environment for each block and connect them together from top
level. Currently there are 26 options available for adding, instantiating and connecting new
classes and instances to the existing testbench.

3.3. Managing Testbench

Testbench management can become complicated for large SoCs. Testbenches developed for
SoCs may have multiple environments for individual blocks. It becomes tough to keep track of
the updates in different portions of the testbench. This utility generates a log file to keep track of
the updates made to any testbench. The log file keeps track of three things, the executed
command, generated file names after execution of any command and time of command
execution. This log file can be used for proper management of any generated testbench.

3.4. Generate Testbench from Graphical User Interface

Executing scripts from the terminal can often be a difficult task and is not always the fastest
option for user. Hence, a graphical user interface option was created for the script utility. New
UVM users can use it to create and manage testbench easily. User can choose any one of the two
methods for generating codes. The GUI was developed using the open source QT Creator [5] in
Linux. Before using the GUI, Qt must be installed on the Linux operating system.

4. Scripts used for Testbench Automation and Management

Bash scripts are created to automate UVM based testbench code generation. 40+ scripts are
created to generate different classes, add new instances and automate connections. All scripts are
written in Bash Shell language. The hierarchy of working scripts is shown in figure 2.
Depending on executed commands, specific scripts run for automating tasks. To add new classes
or connections appropriate script has to be chosen from this hierarchy. Different scripts are
generating different portions of testbench.

SNUG 2015 8 Automating UVM Testbench

Generation and Code Management
 Figure 2 - Important portion of script hierarchy

Scripts are working based on common bash commands such as: cat, echo, touch etc. SED is used
in order to add codes in specific locations [5]. Some of these scripts are shown in figure 3-6.

common=${1:-auto}
top_file=${2:-top.sv}
destination=${3:-mydir}
base_test_file=${4:-base_test.sv}
test_name=${5:-base_test}
$DIR/create_interface $interface_class
>$destination/$interface_file
$DIR/create_top $interface_file > $destination/$top_file
$DIR/create_test_base $test_name >
$destination/$base_test_file
$DIR/env_generate $common $base_test_file $destination
$active

Figure 3 - Script for initial structure generation

SNUG 2015 9 Automating UVM Testbench

Generation and Code Management
 common=${1:-auto};
base_test_file=${2:-base_test.sv}
destination=${3:-mydir};
active=${4:-ACTIVE};
mon_active=${5:-PASSIVE};

$DIR/create_env $env_class ....... $destination>

$destination/$env_file

$DIR/create_vsequencer $virtual_sequencer_class .......

$destination > $destination/$virtual_sequencer_file

$DIR/create_vsequence $virtual_sequence_class ......

$destination > $destination/$virtual_sequence_file

$DIR/do_agent $env_file ........ $destination

$DIR/do_subscriber $subscriber_file ........ $destination
$DIR/do_scoreboard ....... $destination

Figure 4 - Script for generating new environment class

sed -i "/uvm_test/a \ $env_class $env_ins;"

$destination/$base_test_file
sed -i "/$build/a \
$env_ins=$env_class::type_id::create(\"$env_ins\",this)
;" $destination/$base_test_file

cat << _EOF_

class $env_class extends uvm_env;
.
.
.
.
endclass : $env_class

Figure 5 - Script for creating instance of environment class inside base test file

SNUG 2015 10 Automating UVM Testbench

Generation and Code Management
 if grep "$interface_name " $destination/$file
then
sed -i '/run_test()/i \ uvm_config_db#(virtual
'$interface_with_modport')::set(....);'
$destination/$file
else
sed -i '/module /a \ '$interface_name'
'$interface_name'();' $destination/$file
sed -i '/run_test()/i \ uvm_config_db#(...);'
$destination/$file
fi

Figure 6 - Script for declaring interface file at top level file

Scripts are written for creating and connecting other classes also. Testbench generation using
these scripts from terminal and GUI are discussed in the following sections.

5. Testbench Generation from Terminal

The proposed script based utility can be used in different ways to generate whole or different
parts of testbench. User has to run specific scripts from terminal to generate codes.

5.1. Terminal Commands

Three different types of commands can be executed for generating testbench. They are
commands for (1) creating new class or component, (2) creating instance of any class inside
another class and (3) creating interconnections between classes. Code is generated following
UVM class structure.

5.1.1. Creating New Class/es

After creating initial testbench structure any number of new classes can be added to the existing
testbench. A bash script is created that executes other necessary scripts to create necessary
classes depending on the command. Table 1 shows these commands which can be used for initial
structure generation and creating new classes. Each command requires specific arguments to
create the testbench properly. There are 11 commands to create new class/es. Each command is
created for different purposes.

SNUG 2015 11 Automating UVM Testbench

Generation and Code Management
 Table 1 - Commands for creating new classes/interfaces

No. Command Arguments Output on Execution

01 tb a. Prefix Whole testbench framework
b. Top File Name (virtual sequencer, virtual
c. Base Test File Name sequence, environment, agent
d. Base Test Class Name and other sub classes)
e. Interface File
f. InterfaceClass Name
02 env a. Prefix Environment class and Sub-
b. Base Test File Name classes (environment, agent
etc.)
03 scb a. Prefix Single Scoreboard Class
b. Environment File Name
c. Sequence Item Class Name
04 sbr a. Prefix Single subscriber class
b. EnvFileName
c. Sequence Item Class Name
05 agent a. Prefix Agent class and sub classes
b. Environment File Name (agent, driver, monitor,
c. Environment Prefix sequencer etc.)
06 drv a. Prefix Single driver class
b. Driver Prefix
c. Destination Folder Name
07 mon a. Prefix Single monitor class
b. Agent Prefix
08 sqr a. Prefix Single sequencer class
b. Agent Prefix
c. Environment File Name
d. Sequence Item Class Name
09 n_seq a. Extended Sequence Prefix New Sequence class
b. New Sequence File Name
c. Parent Sequencer Name
d. Sequence Item Class Name
10 test a. New Test File Name New test class
b. New Test Case Name
c. Environmental Class Name
d. Virtual Sequence Class Name
11 new_intf a. Interface Class Name New Interface class

SNUG 2015 12 Automating UVM Testbench

Generation and Code Management
5.1.2. Creating Instances of Existing Classes

In UVM, classes are organized in a very systematic way [1]. Objects of some classes are
instantiated in other classes. Objects of any class can be instantiated inside other classes
automatically using this utility. Currently seven commands can be executed for creating
instances of necessary classes. These commands are shown in Table 2.

Table 2 - Commands for creating instances of existing classes

No. Command Arguments Output on Execution

01 env_i a. Environment Class Name Environment instance created
b. Environmental Class Instance inside Base test class
c. Base Test File Name
d. Destination Folder Name
02 scb_i a. Scoreboard Class Name Scoreboard instance created
b. Scoreboard Instance inside environment class
c. ACTIVE or PASSIVE
d. Environment File Name
e. Destination Folder Name
03 sbr_i a. Subscriber Class Name Subscriber instance created
b. Subscriber Instance Name inside environment class
c. ACTIVE or PASSIVE
d. Environment File Name
e. Destination Folder Name
04 agent_i a. Agent Class Name Agent instance created inside
b. Agent Instance Name environment class
c. ACTIVE or PASSIVE
d. Environment File Name
e. Destination Folder Name
05 drv_i a. Driver Class Name Driver instance created inside
b. Driver Instance Name agent class
c. Agent File Name
d. Destination Folder Name
06 mon_i a. Monitor Prefix Monitor instance created
b. Monitor Instance Name inside agent class
c. Agent Prefix Name
d. Destination Folder Name
07 sqr_i a. Sequence Class Name Sequencer instance created
b. Sequencer Instance Name inside agent class
c. Agent File Name
d. Destination Folder Name

SNUG 2015 13 Automating UVM Testbench

Generation and Code Management
5.1.3. Creating Port Connections
In UVM, ports are used for creating communication bridge between multiple classes [1]. All
ports are not connected initially. The following commands in Table 3 can be used for creating
proper port connection in appropriate instances of classes. Interface can be created and connected
to different classes using this method.

Table 3 - Commands for creating connection among instances using port

No. Command Arguments Output on Execution

01 scb_c a. Environment File Name Scoreboard port connected to
b. Agent Instance Name monitor port through agent
c. Monitor Instance Name port
d. Monitor Port Name
e. Scoreboard Instance Name
f. Scoreboard Port Name
02 sbr_c a. Environment File Name Subscriber port connected top
b. Agent Instance Name agent port
c. Subscriber Instance Name
d. Agent Port Name
03 c_sqr a. Agent File Name Sequencer gets connected to
b. Driver Instance Name driver through agent
c. Sequencer Instance Name
04 intf a. Interface With Modport Interface connected at the top
b. Interface Name level
c. Environment Class Instance
d. Agent Class Instance
e. Top File Name
05 c_intf a. Interface With Modport Interface connected at lower
b. Interface Instance level classes
06 a_intf a. Extended Sequence Prefix Adding new interface to the
b. Base Sequence Class Name testbench
c. Parent Sequencer Name
d. Sequence Item Class Name
07 add_mon_port a. Monitor Class Name Create new port inside
b. Monitor Port Name monitor class
c. Sequence Item Class Name
08 add_drv_port a. Driver Class Name Create new port inside driver
b. Driver Port Name class
c. Sequence Item Class Name
09 add_scb_port a. Scoreboard Class Name Create new port inside
b. Scoreboard Port Name scoreboard class
c. Sequence Item Class Name

SNUG 2015 14 Automating UVM Testbench

Generation and Code Management
5.2. Creating Initial Testbench Structure from Terminal

Codes are generated depending on the command executed on linux terminal. The main script in
this utility is “rtg” . The terminal commands discussed earlier follow this script on terminal.
For example, executing “rtg tb XYZ XYZ_top.sv XYZ_base_test.sv
XYZ_base_test XYZ_intf.sv XYZ_intf” on terminal, the basic UVM testbench
structure is generated. In this generated testbench, all file names have a common prefix “XYZ”.
Testbench files are created inside the destination folder “/home/ius/XYZ_test”. The basic
testbench structure includes the following files.

a. XYZ_top.sv …………………………………. < Top Level >

b. XYZ_base_test.sv …………………………... < Base Test >
c. XYZ_env.sv ………………………………… < Environment >
d. XYZ_vsequencer.sv ………………………… < Virtual Sequencer >
e. XYZ_vsequence.sv …………………………. < Virtual Sequence >
f. XYZ_scb.sv ………………………………… < Scoreboard >
g. XYZ_subscriber.sv …………………………. < Subscriber >
h. XYZ_agent.sv ………………………………. < Agent >
i. XYZ_driver.sv………………………………. < Driver >
j. XYZ_monitor.sv ……………………………. < Monitor >
k. XYZ_sequencer.sv ………………………….. < Sequencer >
l. XYZ_sequence_item.sv …………………….. < Sequence Item >
m. XYZ_sequence.sv …………………………. < Sequence >
n. XYZ_intf.sv ………………………………… < Interface >
o. XYZ_pkg.sv ………………………………... < Package >

5.2.1. Top File

Inside the top file, UVM package and generated package files are imported automatically.
Interface file is included for creating connection between classes in lower level of hierarchy.

`include "XYZ_pkg.sv";
`include "XYZ_intf.sv"
module top;
import uvm_pkg::*
`include "uvm_macros.svh"
import XYZ_pkg::*;
initial
begin
run_test();
// Run Test Function
end
endmodule

Figure 7 - Generated top file

SNUG 2015 15 Automating UVM Testbench

Generation and Code Management
5.2.2. Base Test File

Base test file is one of the most important portions of testbench. All other tests added to the
existing testbench have to be extended from this base class. Generated codes for this base test
class includes instantiation of environments and declaration of virtual sequence.

class XYZ_base_test extends uvm_test;

// Instantiation
XYZ_vsequence XYZ_vsequence_ins ;
XYZ_env XYZ_env_ins;
`uvm_component_utils(XYZ_base_test)
.
.
virtual function void build_phase(uvm_phase phase);
super.build_phase(phase);
XYZ_env_ins=XYZ_env::type_id::create("XYZ_env_ins",t
his);
endfunction : build_phase

virtual task run_phase(uvm_phase phase);

super.run_phase(phase);
phase.raise_objection(this, "Objection raise");
XYZ_vsequence_ins=XYZ_vsequence::type_id::create("XY
Z_vsequence_ins");
XYZ_vsequence_ins.start(XYZ_env_ins.XYZ_vsequencer_i
ns);
phase.drop_objection(this, "Objection_drop");
endtask : run_phase
endclass : XYZ_base_test

Figure 8 - Generated base test file

5.2.3. Environment File

In any UVM testbench, usually environment represents a complete module. All agents,
sequences, drivers and monitors related to a certain block belongs to single environment. In this
testbench generation process, each environment is assumed to be representing individual blocks
in a large SoC. The following example shows generated code for XYZ environment.

SNUG 2015 16 Automating UVM Testbench

Generation and Code Management
 class XYZ_env extends uvm_env;

XYZ_scb XYZ_scb_ins ;
XYZ_sbr XYZ_sub_ins ;
XYZ_agent XYZ_agent_ins ;
XYZ_vsequencer XYZ_vsequencer_ins ;

`uvm_component_utils_begin(XYZ_env)
`uvm_component_utils_end

.
.

virtual function void build_phase(uvm_phase phase);

super.build_phase(phase);
`uvm_info(get_full_name(), "Build Phase(ACTIVE)",
UVM_LOW);
XYZ_scb_ins=XYZ_scb::type_id::create("XYZ_scb_ins",this);
XYZ_sub_ins=XYZ_sbr::type_id::create("XYZ_sub_ins",this);
XYZ_agent_ins=XYZ_agent::type_id::create("XYZ_agent_ins",t
his);
XYZ_agent_ins.is_active=UVM_ACTIVE;
XYZ_vsequencer_ins=XYZ_vsequencer::type_id::create("XYZ_vs
equencer_ins",this);
`uvm_info(get_full_name(), "Build Phase(PASSIVE)",
UVM_LOW);

endfunction : build_phase

Figure 9 - Generated environment file (instantiation and build phase)

Connections among lower level classes such as agent, scoreboard and subscriber are done in
connect phase of generated environment class.

SNUG 2015 17 Automating UVM Testbench

Generation and Code Management
 virtual function void connect_phase(uvm_phase phase);
.
.

XYZ_vsequencer_ins.XYZ_sequencer_ins=XYZ_agent_ins.XYZ_seq
uencer_ins;
if(XYZ_agent_ins.is_active == UVM_ACTIVE)begin
.
.
XYZ_agent_ins.XYZ_monitor_ins.XYZ_monitor_port.connect(XYZ
_scb_ins.port_XYZ_sent_pkt);

XYZ_agent_ins.XYZ_a_port.connect(XYZ_sub_ins.analysis_expo
rt);
end
else if(XYZ_agent_ins.is_active == UVM_PASSIVE)begin
.
.
XYZ_agent_ins.XYZ_monitor_ins.XYZ_monitor_port.connect(XY
Z_scb_ins.port_XYZ_sent_pkt);
XYZ_agent_ins.XYZ_a_port.connect(XYZ_sub_ins.analysis_exp
ort);
end
endfunction : connect_phase
virtual task run_phase(uvm_phase phase);
super.run_phase(phase);
factory.print();
endtask: run_phase

endclass : XYZ_env

Figure 10 - Generated environment file (connect phase and run phase)

5.2.4. Other Generated Files

Along with environment, base test classes, all other commonly used classes are generated from
“rtb tb” command execution. Some of them are shown below.

SNUG 2015 18 Automating UVM Testbench

Generation and Code Management
 class XYZ_vsequence extends uvm_sequence;
// Instantiation
XYZ_sequence XYZ_sequence_ins;
`uvm_object_utils(XYZ_vsequence)
`uvm_declare_p_sequencer(XYZ_vsequencer)

function new(string name="XYZ_vsequence");

super.new(name);
endfunction : new

task body();
fork
`uvm_do_on(XYZ_sequence_ins,p_sequencer.XYZ_sequencer_ins)
join
endtask: body

endclass : XYZ_vsequence

Figure 11 - Generated virtual sequence class

class XYZ_vsequencer extends uvm_sequencer;

// Instantiation
XYZ_sequencer XYZ_sequencer_ins;
`uvm_component_utils(XYZ_vsequencer)

function new(string name="XYZ_vsequencer",

uvm_component parent=null);
super.new(name, parent);
//New Function
endfunction:new

endclass: XYZ_vsequencer

Figure 12 - Virtual sequencer class

SNUG 2015 19 Automating UVM Testbench

Generation and Code Management
 class XYZ_agent extends uvm_agent;
XYZ_sequencer XYZ_sequencer_ins ;
XYZ_monitor XYZ_monitor_ins ;
XYZ_driver XYZ_driver_ins ;
uvm_active_passive_enum is_active = UVM_ACTIVE;
`uvm_component_utils_begin(XYZ_agent)
`uvm_field_enum(uvm_active_passive_enum, is_active,
UVM_ALL_ON)
`uvm_component_utils_end

// Declare Port For External Connections

uvm_analysis_port#(XYZ_trans) XYZ_a_port;

Figure 13 - Driver, monitor and sequence instances declared in agent class

virtual function void connect_phase(uvm_phase phase);

super.connect_phase(phase);
if(is_active == UVM_ACTIVE) begin
`uvm_info(get_full_name(), "Connect Phase(ACTIVE)",
UVM_LOW);
XYZ_driver_ins.seq_item_port.connect(XYZ_sequencer_ins.seq_
item_export);
XYZ_monitor_ins.XYZ_monitor_port.connect(XYZ_a_port);
end
else if(is_active == UVM_PASSIVE) begin
`uvm_info(get_full_name(), "Connect Phase(PASSIVE)",
UVM_LOW);
XYZ_monitor_ins.XYZ_monitor_port.connect(XYZ_a_port);
end
endfunction : connect_phase

Figure 14 - Connecting driver, monitor, sequencer in connect phase of agent class

Driver, monitor and sequencer classes include port and task declarations. Design specific codes
have to be manually added to the testbench.

SNUG 2015 20 Automating UVM Testbench

Generation and Code Management
 class XYZ_driver extends uvm_driver #(XYZ_trans);
`uvm_component_utils(XYZ_driver)

function new(string name, uvm_component parent);

super.new(name, parent);
endfunction : new

virtual function void build_phase(uvm_phase phase);

super.build_phase(phase);
endfunction : build_phase

virtual function void connect_phase(uvm_phase

phase);
super.connect_phase(phase);
`uvm_info(get_full_name(), "In connect :
UVM_CONNECT", UVM_LOW);
endfunction : connect_phase

virtual task run_phase(uvm_phase phase);

XYZ_trans XYZ_trans_ins;
super.run_phase(phase);
endtask : run_phase
endclass : XYZ_driver

Figure 15 - Generated driver class

Interface remains empty as no information regarding the design is provided through terminal.
Verification engineer has to edit this file to make it work for specific design.
package XYZ_pkg;
`timescale 1ns/1ps import uvm_pkg::*;
`include "uvm_macros.svh"
interface XYZ_intf; `include "XYZ_sequence_item.sv"
`include "XYZ_sequencer.sv"
// Signal Declaration `include "XYZ_driver.sv"
`include "XYZ_sequence.sv"
endinterface `include "XYZ_subscriber.sv"
`include "XYZ_scb.sv"
`include "XYZ_monitor.sv"
`include "XYZ_agent.sv"
Figure 16 - Generated interface file `include "XYZ_vsequencer.sv"
`include "XYZ_env.sv"
`include "XYZ_vsequence.sv"
`include "XYZ_base_test.sv"
endpackage

Figure 17 - Generated package file

SNUG 2015 21 Automating UVM Testbench

Generation and Code Management
Package files include all generated files. Files are included maintaining correct hierarchy level so
that compiler can compile them properly.

5.3. Adding New Agent Class from Terminal

To add a new agent to the existing testbench, “rtg agent XYZ_2 XYZ_env.sv XYZ”
command is executed. The following files are generated in the testbench working directory.

a. XYZ_2_agent.sv ………………………………. < Agent >

b. XYZ_2_driver.sv………………………………. < Driver >
c. XYZ_2_monitor.sv ……………………………. < Monitor >
d. XYZ_2_sequencer.sv ………………………….. < Sequencer >
e. XYZ_2_sequence_item.sv …………………….. < Sequence Item >
f. XYZ_2_sequence.sv …………………………... < Sequence >

5.3.1. Created Files

The new agent class is named XYZ_2_agent. Driver, monitor and other classes related to this
agent class is also created. All of these classes have the same prefix XYZ_2.

class XYZ_2_agent extends uvm_agent;

// Instantiation
XYZ_2_monitor XYZ_2_monitor_ins ;
XYZ_2_sequencer XYZ_2_sequencer_ins ;
XYZ_2_driver XYZ_2_driver_ins ;
uvm_active_passive_enum is_active = UVM_ACTIVE;
`uvm_component_utils_begin(XYZ_2_agent)
`uvm_field_enum(uvm_active_passive_enum, is_active,
UVM_ALL_ON)
`uvm_component_utils_end
// Declare Port For External Connections
uvm_analysis_port#(XYZ_2_trans) XYZ_2_a_port;

Figure 16 - Instances declared in new agent class

SNUG 2015 22 Automating UVM Testbench

Generation and Code Management
 class XYZ_2_monitor extends uvm_monitor;

`uvm_component_utils(XYZ_2_monitor)
uvm_analysis_port#(XYZ_2_trans) XYZ_2_monitor_port;
XYZ_2_trans XYZ_2_trans_ins;
function new(string name,uvm_component parent);
.
.
endfunction:new

virtual function void build_phase(uvm_phase phase);

.
.
XYZ_2_trans_ins =
XYZ_2_trans::type_id::create("XYZ_2_trans_ins");
endfunction:build_phase

virtual function void connect_phase(uvm_phase phase);

.
.
endfunction:connect_phase
virtual task run_phase(uvm_phase phase);
.
.
endtask:run_phase

endclass:XYZ_2_monitor
Figure 17 - Created monitor file for new agent

class XYZ_2_driver extends uvm_driver #(XYZ_2_trans);

`uvm_component_utils(XYZ_2_driver)
.
.
virtual function void connect_phase(uvm_phase phase);
.
.
endfunction : connect_phase
virtual task run_phase(uvm_phase phase);
.
.
endtask : run_phase

endclass : XYZ_2_driver

Figure 18 - Driver class generated for new agent

SNUG 2015 23 Automating UVM Testbench

Generation and Code Management
5.3.2. Changes inside Existing Environment

Generated agent class is instantiated inside the specified environment class.

class XYZ_env extends uvm_env;

// Instantiation
XYZ_2_agent XYZ_2_agent_ins ;
.
.
.
;

`uvm_component_utils_begin(XYZ_env)

Figure 19 - Agent instantiated automatically in environment class

Instance of the new agent class is created inside build phase of specified environment and gets
connected to scoreboard, subscribers in the connect phase.

virtual function void build_phase(uvm_phase phase);

super.build_phase(phase);
`uvm_info(get_full_name(), "Build Phase(ACTIVE)",
UVM_LOW);

XYZ_2_agent_ins=XYZ_2_agent::type_id::create("XYZ_2_agent_
ins",this);
XYZ_2_agent_ins.is_active=UVM_ACTIVE;
.
.
endfunction : build_phase

Figure 20 - Created agent instance in build phase

The following code shows the connect phase of environment class. In connect phase no
scoreboard or subscriber is connected to this agent. This agent can be connected to any
scoreboard or subscriber using connection scripts.

SNUG 2015 24 Automating UVM Testbench

Generation and Code Management
 virtual function void connect_phase(uvm_phase phase);
super.connect_phase(phase);
XYZ_vsequencer_ins.XYZ_2_sequencer_ins=XYZ_2_agent_ins.
XYZ_2_sequencer_ins;
if(XYZ_2_agent_ins.is_active == UVM_ACTIVE)begin
`uvm_info(get_full_name(), "Connected to Active
XYZ_2_agent_ins", UVM_LOW);
end
else if(XYZ_2_agent_ins.is_active == UVM_PASSIVE)begin
`uvm_info(get_full_name(), "Connected to Passive
XYZ_2_agent_ins", UVM_LOW);
end
.
.
.
endfunction : connect_phase

Figure 21 - New code generated for new agent class in environment

All generated files are included inside package file for compiling total testbench structure.

package XYZ_pkg;
import uvm_pkg::*;
`include "uvm_macros.svh"
`include "XYZ_2_sequence_item.sv"
.
.
`include "XYZ_2_sequencer.sv"
`include "XYZ_2_driver.sv"
`include "XYZ_2_sequence.sv"
.
.
`include "XYZ_2_monitor.sv"
`include "XYZ_2_agent.sv"
.
.
endpackage

Figure 22 - Package file edited

SNUG 2015 25 Automating UVM Testbench

Generation and Code Management
5.4. Adding New Environment Class to Existing Testbench from Terminal

Large SoCs contain many blocks. Different environment classes can be modelled for each block.
To connect a new block to the existing XYZ_test testbench
“rtg env ABC XYZ_base_test.sv” command is used. Generated new files include:

a. ABC_env.sv ………………………………… < Environment >

b. ABC_vsequencer.sv ………………………… < Virtual Sequencer >
c. ABC _vsequence.sv …………………………. < Virtual Sequence >
d. ABC _scb.sv ………………………………… < Scoreboard >
e. ABC_subscriber.sv …………………………. < Subscriber >
f. ABC_agent.sv ………………………………. < Agent >
g. ABC_driver.sv………………………………. < Driver >
h. ABC_monitor.sv ……………………………. < Monitor >
i. ABC_sequencer.sv ………………………….. < Sequencer >
j. ABC_sequence_item.sv …………………….. < Sequence Item >
k. ABC_sequence.sv …………………………... < Sequence >

5.4.1. Created Files

All the codes are generated in the same way as mentioned in previous sections. The following
example codes shows the generated environment file for this new ABC block.

class ABC_env extends uvm_env;

ABC_scb ABC_scb_ins ;
ABC_sbr ABC_sub_ins ;
ABC_agent ABC_agent_ins ;
ABC_vsequencer ABC_vsequencer_ins ;
`uvm_component_utils_begin(ABC_env)
`uvm_component_utils_end
.
.
.
.
endclass : ABC_env

Figure 23 - Generated environment class

SNUG 2015 26 Automating UVM Testbench

Generation and Code Management
5.4.2. Updated Files
class XYZ_base_test extends uvm_test;
ABC_vsequence ABC_vsequence_ins ;
ABC_env ABC_env_ins;
.
.
.
virtual function void build_phase(uvm_phase phase);
.
.
ABC_env_ins=ABC_env::type_id::create("ABC_env_ins",this);
endfunction : build_phase

virtual task run_phase(uvm_phase phase);

.
.
ABC_vsequence_ins=ABC_vsequence::type_id::create("ABC_vse
quence_ins");
ABC_vsequence_ins.start(ABC_env_ins.ABC_vsequencer_ins);
endtask : run_phase

endclass : XYZ_base_test

Figure 24 - Edited base test file

package XYZ_pkg;
import uvm_pkg::*;
`include "uvm_macros.svh"
.
.
.
`include "ABC_sequencer.sv"
`include "ABC_driver.sv"
`include "ABC_sequence.sv"
`include "ABC_subscriber.sv"
`include "ABC_scb.sv"
`include "ABC_monitor.sv"
`include "ABC_agent.sv"
`include "ABC_vsequencer.sv"
`include "ABC_env.sv"
`include "ABC_vsequence.sv"
`include "XYZ_base_test.sv"
endpackage

Figure 25 - Updated portion of package file

SNUG 2015 27 Automating UVM Testbench

Generation and Code Management
6. Testbench Generation from GUI

Testbench generation options are also available via a graphical user interface which has been
developed using QT Creator in Linux. The GUI incorporates options provided by the automation
scripts discussed earlier. Figure 28 shows the home window of the GUI.

Figure 26 - Graphical user interface for testbench generation

This window contains options for testbench generation available for user. Clicking on any option
will bring out its respective window where user can pass necessary input arguments. Some
examples of generating testbench structure using the GUI are described below.

6.1 Creating Whole Testbench

Figure 29 shows the “Create whole Testbench” window that appears when the “Create entire
testbench from top down” option is selected form the home window. The input arguments have
been filled in the respective boxes.

SNUG 2015 28 Automating UVM Testbench

Generation and Code Management
 Figure 27 - Main window for generating entire testbench

Arguments for generating initial testbench structure are on the left. The “Create Testbench”
option will take the three arguments Prefix, Top level filename and Destination and generate
testbench files. The generated folder window shown in Figure 30 is automatically brought up
upon button click.

Figure 28 - Generated files using “Create entire testbench” GUI option

SNUG 2015 29 Automating UVM Testbench

Generation and Code Management
On the right in Figure 29 are options for adding and connecting interface. The “Connect
interface at top level” option requires four arguments as shown in the figure and adds an
interface file to the folder. It also adds relative interface code at the top level file. The third
option in the window is “Import interface to file”. It requires the filename of the file at a lower
level in hierarchy to which the user wishes to connect an interface from the top level. In this case
it is the lower level component file XYZ_driver.sv. Interface can be connected to monitor class in
the same way.

6.2 Adding an Environment

Now the second option is selected from the home window in Figure 28 i.e. “Add env”. Choosing
that option brings up the “Create/Add Env” window as shown in Figure 31, where the necessary
arguments have been provided.

Figure 29 - GUI window for adding environment

This option requires four arguments, Prefix, testFileName, Destination and agent type. This can
be used to add a new environment to the previously created testbench. The previous test filename
and destination has been provided as arguments and a new prefix for the new environment
components has been given. Clicking on the “create” button will generate the new environment
files in the destination. A screenshot of the destination folder with the added files is shown in
Figure 32.

SNUG 2015 30 Automating UVM Testbench

Generation and Code Management
 Figure 30 - New environment files generated using “Add env” GUI option

6.3 Adding an Agent

Third option in the home window is “Add Agent”. Clicking on the corresponding button brings
up the “Create/Add Agent” window, shown in Figure 33. Input arguments have been provided.

SNUG 2015 31 Automating UVM Testbench

Generation and Code Management
 Figure 31 - Adding an agent using GUI

“Prefix of new Agent” is used to identify the new agent and its subcomponents. “Prefix of env”
and “envFileName” is used to identify the environment class in which the new agent will be
instantiated. There is also an input that specifies the active or passive nature of the monitor
instantiated inside new agent. Clicking the “create” button will execute scripts and the new
agent will be generated and added to the destination folder. The new generated files are shown in
Figure 34.

SNUG 2015 32 Automating UVM Testbench

Generation and Code Management
 Figure 32 - New Agent files generated using “Add Agent” GUI option

7. Simulation Results

To check if generated code represents correct testbench structure and is free of syntax errors, we
have run a simulation of a UVM based testbench generated using this utility.

The command rtg tb .. .. is used to generate a testbench with basic components.

Synopsys VCS is used to compile and simulate the code. The simulation results are shown in
Figure 35 and 36.

Figure 33 - Simulation of UVM ‘build’ and ‘connect’ phases

SNUG 2015 33 Automating UVM Testbench

Generation and Code Management
In figure 35 the different build and connect phases of the testbench components are indicated by
UVM message reporting. Build phases are executed in a top down manner and connect phases
are executed in bottom up hierarchy. From these results it is concluded that testbench structure
and connections are done correctly in the generated code.

Figure 34 - End of simulation reports

In figure 36 shows the end of simulation report. There are no UVM errors or fatal errors,
indicating correct compilation and simulation of the testbench. A command log keeps record of
script executions and generated files. Figure 37 shows the command log entry recorded for the
above simulation.

Figure 35 - Command log entries

SNUG 2015 34 Automating UVM Testbench

Generation and Code Management
8. Future Aspects

This utility can be updated in many ways. New scripts can be added to the existing tool for
enabling more options for users.

8.1. Include More UVM Features

UVM is a highly accepted and used methodology for developing testbench for verifying RTL
models. It is being developed regularly. New features are being added to the existing
methodology. This utility can be improved by adding more features of UVM to the generated
codes. It will make generated testbench more robust and reusable.

8.2. Different Structure Creation

Currently this tools generates testbench following a single structure. Depending on the RTL
model or protocol, engineers may use different structures for developing testbenches. So
enabling this feature to this utility will make it more efficient and useful.

8.3. Easier Management Tool

This tool’s testbench management feature can be enhanced to make it a better management tool.
Engineers may need to create some files manually. In that case monitoring manual changes in
working directory can be very helpful to engineers. So testbench management features can
enhance its performance in different ways.

9. Conclusion

Script based testbench code generation makes it really easy to start a new SoC verification
project. Verification engineers do not need to write the common structure each time they start a
new project. As a result they can spend more time on testing design and finding bugs. Using
smart logging system, generated testbenches can be managed in a better way. Moreover
command logging system makes it possible to track advancement of generated testbench.
In conclusion, it can be expected that adding advanced UVM features, this utility will certainly
become a handy tool for automating testbench generation and management.

SNUG 2015 35 Automating UVM Testbench

Generation and Code Management
10. References
[1] “UVM 1.1 Class Reference.” [Online]. Available:
http://accellera.org/images/downloads/standards/uvm/UVM_1.1_Class_Reference_Final_0606201
1.pdf. [Accessed: 08-Jul-2015].

[2] B. Bailey, TLM-Driven Design and Verification Methodology, 1st ed. 2010.

[3] “SELF CHECKING TESTBENCH.” [Online]. Available:

http://www.testbench.in/TB_06_SELF_CHECKING_TESTBENCH.html. [Accessed: 08-Jul-
2015].

[4] “Unix Sed Tutorial: Append, Insert, Replace, and Count File Lines.” [Online]. Available:
http://www.thegeekstuff.com/2009/11/unix-sed-tutorial-append-insert-replace-and-count-file-
lines/. [Accessed: 08-Jul-2015].

[5] “Qt - Open Source.” [Online]. Available: https://www.qt.io/download-open-source/. [Accessed:

08-Jul-2015].

SNUG 2015 36 Automating UVM Testbench

Generation and Code Management