Introduction in UVM

Daian Stein
Junior Verification and Design Engineer at EtherGate
Polytehnic University of Timisoara
1. Overview
• The Universal Verification Methodology (UVM) is a standardized
methodology for verifying integrated circuit designs. UVM is derived
mainly from the OVM (Open Verification Methodology) which was, to
a large part, based on the eRM (e Reuse Methodology) for the e
Verification Language developed by Verisity Design in 2001.
• The UVM class library brings much automation to
the SystemVerilog language such as sequences and data automation
features (packing, copy, compare) etc., and unlike the previous
methodologies developed independently by the simulator vendors, is
an Accellera standard with support from multiple vendors: Aldec,
Cadence, Mentor Graphics, and Synopsys.
1. Overview
• The Universal Verification Methodology (UVM) consists of class
libraries needed for the development of well constructed, reusable
SystemVerilog based Verification environment.

• In simple words, UVM consists of set of base classes with methods

defined in it, SystemVerilog verification environment can be
developed by extending these base classes.
2. DUT Specification
• This DUT is a simple Ethernet switch,
which can drive the incoming packet to
destination ports based on the address
contained in the packet.
• The actual chip contain one input
interface from which the packet enters
into the DUT. It has four output
interfaces where the packet is driven
out.
• The switch contains a configuration
interface too. Through this, the output
addresses are indexed to some
specified values.
http://testbench.in/VS_01_DUT_SPECIFICATION.html?fbclid=IwAR0ekz-
sJznE8dVYmVDBiQ3nDxuIPHpsnm6M4SAqKsxMWGG99UWvwOn41Fk
2. Switch specification and interface
description
• Packet format:

Packet contains Header, data and frame check sequence(FCS). Packet

width is 8 bits and the length of the packet can be between 4 bytes to
259 bytes.
2. Switch specification and interface
description
• The switch has one input Interface, from where the packet enters the dut and 4 output interfaces from
where the packet comes out and one memory interface, through the port address can be configured.
• Memory Interface:
• Through memory interfaced output port address are configured. It accepts 8 bit data to be written to
memory. It has 8 bit address inputs. Address 0,1,2,3 contains the address of the port 0,1,2,3 respectively. If
the DA in the packet matches with the configured address of any port ,then the packet comes out of that
port.
• Input Interface:
• The status signal has to be high when data is when packet is sent on to the dut it has to become low after
sending last byte of the packet.
• When the dut is busy, and if it is not in a position to accept any more data, it will assert busy signal. Data
which is sent during this busy signal is lost if input is driving when busy is high
• Output Interface:
• There are 4 ports, each having data, ready and read signals.
• When the data is ready to be sent out from the port, dut makes the ready signal high indicating that data is
ready to be sent.
• If the read signal is made high when ready is high, then the data comes out of the data signal.
3. Verification plan
• To verify and validate a DUT(especially an Ethernet Switch), in the real
industry, there are many teams whose only job is to coordinate the
verification team(actual engineers and programmers). Most of the time, a
verification plan is careful build and partitioned to the whole team.
• For this switch, the following verification scenarios are followed, at a level
of full chip:
Basic functionality: after configuration, a normal flow of packets from
input will go to their output port based on their DA addresses
Boundary functionalities: burst activity, empty packets, etc
Hostile condition: chip not configured, packet with different addresses
3. Verification plan
• In real situation, a lot of verification happens before, at unit level(not
the case here), every unit being tested much more carefully than the
full chip, in some cases.
• After that comes the integration testing, which represent a key point
in the whole verification plan. Most of the time, here are find the
majority of the errors and bugs.
• There are also syntactical scenarious that should be covered:
connectivity tests, registers and tables checks, etc
• Usually, methodologies as black box and white box come into play
4. UVM architecture
4. UVM Architecture – Switch DUT
• UVM Test instantiates and configures the environment which, at its turn,
creates and configures the agents.
• There is an agent for every interface: one agent for configuring memory(+
its interface together with its transaction object), one agent for input
packet(+interface and packet transaction) and 4 agents for the output
ports(+ 4 interfaces and the same packets transaction objects)
• Then environment contains also a monitor for every input and output
ports, which monitors every transaction with the switch
• The verification part for this chip is the scoreboard which is connected to
every monitor and captures its packets; from this it compares every packet
at output with its input one and gives a verdict if the packets are as
expected
Project structure
• Top.sv – instantiates the interfaces, DUT and test
• Sw_pkg.sv – contains a list of includes for every file used throughout
the architecture
• Rtl.sv – the dut
• Run.do – commands for simulator
• Filelist.f – a list of all files needed for compilation
• The tb_classes contains class for every component and object from
the architecture
Project structure – Tb_Classes
• - agent* file – contains the class for every agent(output is overwritten from input one)
• - env, driver, scoreboard – components presented earlier
• - config* files – configuration files for various components(every agent, active or passive)
• - monitor* - monitors for every interface
• Conf_mem and packet files – transaction for memory and input and output ports
• Sequence* files – sequences used to send packets and to configure memory
• Sequencer files – simple subclasses of an uvm_sequencer
• Base_test – a base class which does the majority of instantiation and configuration for
further test; it is not used by himself
• Sw_test – the test used in this project; extends base_test; it’s main function is the body
• The program structure(from SystemVerilog) that represents the entry point of the
simulation is contained in the kernel of the UVM(in uvm_root file from uvm_library)
Project structure
4. UVM Architecture
5. UVM features used
• UVM Factory
• UVM Configuration Database
• UVM Base Classes
• UVM TLM FIFO
• UVM Phases
• UVM Sequencer
• UVM Scoreboard
UVM Configuration Database
• The uvm_config_db class provides a convenience interface on top of the
uvm_resource_db to simplify the basic interface that is used for configuring
uvm_component instances.
• void uvm_config_db#(type T = int)::set(uvm_component cntxt, string inst_name,
string field_name, T value);
• bit uvm_config_db#(type T=int)::get(uvm_component cntxt, string inst_name,
string field_name, ref T value);
UVM Configuration Database
• Usually, the setting part of the database is done in higher components of
the testbench(test, environment) and are get in the lower parts(in agent
for getting the configuration, in monitors for getting the interfaces, etc)
• There are also special cases when you want to have a resource available
everywhere. In that case, the cntx is specified as null, inst_name being
“*”(anything). This means that every part of the testbench can reach that
configuration data
• It is usually done by the engineer in order to simplify the access of a
sequence to the hardware components(i.e. a net from the design part, in
clock connectivity), although not recommended(huge overhead)
UVM Factory
UVM Factory - Type Overriding:
• A type overriding means that every time a component class type is
created in the Testbench hierarchy, a substitute type i.e. derived class
of the original component class, is created in its place. It applies to all
the instances of that component type.
• Syntax:
• <original_type>::type_id::set_type_override(<substitute_type>::get_t
ype(), replace);
• where “replace” is a bit which is when set equals to 1, enables the
overriding of an existing override else existing override is honoured.
UVM Factory – Instance Overriding
• In Instance Overriding, as name indicates it substitutes ONLY a particular
instance of the component OR a set of instances with the intended
component. The instance to be substituted is specified using the UVM
component hierarchy.

• Syntax:
• <original_type>::type_id::set_inst_override(<substitute_type>::get_type(),
<path_string>);

• Where “path_string” is the hierarchical path of the component instance to

be replaced.
UVM Factory
• Type overriding is usually performed in the test, when at runtime the
tester wants to replace the default sequence; it implies that all old
types are substituted by the newer ones, whenever a call to
type_id::create is done
• Instance overriding helps changing a particular instance of a type,
recognized by its path(as a string usually), and it is realized when
overriding configuration object(or components)
• Both imply the need of polymorphism
• Implemented by look-up in huge associative arrays
UVM TLM FIFO
UVM TLM FIFO
• There are many variations of Intra Process or Inter Process communication
primitives(get_port,put_port, analysis_port, tlm_fifo), all based on simple
mailboxes(actually much more advanced stuff)
• Intra process: usually some monitors are hook-up to the scoreboard, and
they run in the same thread with some interfaces; usually a pair of
analysis_port with a subscriber will do the job; implemented by a queue or
by callback(see write function in a uvm_subscriber)
• Inter process: the majority of the components, because of the need of high
parallelism between them; from previous slide, the usage of the fifo being
needed in case of huge traffic
• The connection of the two ends of a channel is done in the parent of the
two components that enclose them(for monitor to agent connection it is
done always in the environment method connect_phase)
UVM Phases
• The UVM core calls
every phase(method) for
every object; rigorous
mechanism.
• Essentials: build,
connect, main(with its
body method)
UVM Sequencer
• The sequencer control the flow of request – response of the sequence
items between sequences and the driver. Intuitively, it is like an
arbiter(with a channel) between the object part and component part of the
test(being an object there is a smaller overhead of being overridden by the
“user”)
• Sequencer and driver uses TLM Interface to communicate transactions.
• uvm_sequencer and uvm_driver base classes has seq_item_export and
seq_item_port defined respectively. User need to connect them using TLM
connect method.
• Example:
• driver.seq_item_port.connect(sequencer.seq_item_export);
• Sequencer can be written by extending the uvm_sequencer parameterized
with seq_item type.
UVM Sequencer
• mSequencer – handle of generic uvm_sequencer(at runtime becomes
explicit) in the sequence used to send item to driver
• pSequencer – handle to concrete type of sequencer in a sequence
used to transmit data from components to objects(sequences and/or
virtual sequences); used to replace the uvm_config_db(null,”*”…)
UVM Virtual Sequence and Sequencer
• In real life projects, there are hundreds of sequences and sequencers,
and, because of that, the need of synchronization and arbitration is
needed
• A virtual sequencer is an instance of a class that contains pointers to
concrete sequencers. By having those references, a virtual sequencer
it is able to control the activity of everyone of them, imposing a
certain order
• The concept was firstly introduced for sequences. For example, firstly
you configure the switch, after which you are capable of sending
packets
• It is the same for sequences
UVM Scoreboard
• Scoreboard is a component that makes automated checking based on
what input and output data receives
• Contains TLM FIFO’s for connection with monitor
• Usually a subclass of uvm_subscriber(it contains by default an
analysis_export) for capturing data(in our case from input by calling
write(packet) method)
• Like a monitor, this component runs throughout the entire of the
simulation, having an important role in the verification process
6. Constraints and Coverage
• Constraints are used in building the transactional object
• Here are simply used to randomize data, build FCS field and most
important, the DA and SA field used to filter the packet to output port
• As coverage, the DA and SA give the principal coverage options:
all output ports are covered
Error packet(wrong DA, wrong number of field in a packet, packet with a
smaller byte count, etc) coverage
Corner cases: burst activity only on one port
Empty data and FCS fields
Default options of line coverage
Constraints
 As depicted, every output port should be
tried at least once
 Also, a special case with a totally random DA
address is performed
 Much more cases can be easily implemented:
• Length 0 which is analogous with byte count
0(actually implemented in the code)
• A special case for data would be all zero, but
usually random
• A special case of wrong fcs could be
introduced just to see how the switch reacts
Coverage
• A good coverage metric is the packet_type: an additional random
variable introduced by the tester in order to help him build some
predefined settings such as: a normal packet(together with covering
all the output ports), a flow of burst packets, a wrong DA packet(a
packet which doesn’t correspond to any output port), a wrong FCS
field, a length-0 packet, all 0 payload, cross coverage between them,
etc
7. Conclusion
• UVM is one of the most important verification methodologies used in
the industry
• Advantages: OOP(System Verilog), a stable runtime core functionality,
customizable components, very versatile and a rich library, possibility
to run with precompiled code(vendor methodologies)
• Disadvantages: cannot get rid of hardware knowledges(or not?) and
waver tools, dependent of the vendors
• Contains more features than presented here: Register model,
user_module component, clock frequency checkers, etc
References
• https://www.slideshare.net/shivoo.koteshwar/coverage-and-
introduction-to-uvm
• https://www.researchgate.net/figure/UVM-test-bench-Architecture-
All-complex-test-benches-may-be-architected-as-shown-in-
the_fig1_303759959
• http://testbench.in/VS_01_DUT_SPECIFICATION.html
• http://low-powerdesign.com/picts/UVM_fig1_684x438.jpg