Introduction to UVM

What is Methodology?
.❖ Best practices by verification experts
l

❖ Base Class Library

❖ Standard communication mechanism to achieve interoperability

❖ Configuration of the testbench from the top level

❖ Generate scenarios independent of testbench environment

❖ Achieve Reusability in plug and play manner

 What is UVM?
• Universal Verification Methodology (UVM) is a standard to enable faster development and reuse of
verification environments and verification IP (VIP) throughout the industry.
• It is a set of class libraries defined using the syntax and semantics of SystemVerilog (IEEE
1800) and is now an IEEE standard.
• The main idea behind UVM is to help companies develop modular, reusable, and scalable
testbench structures by providing an API framework that can be deployed across multiple
projects.
• UVM is mainly derived from Open Verification Methodology (OVM) and is supported by
multiple EDA vendors like Synopsys, Cadence, Mentor and Aldec.
• The UVM class library provides generic utilities like configuration databases, TLM and
component hierarchy in addition to data automation features like copy, print, and compare.

• It brings in a layer of abstraction where every component in the verification environment

has a specific role.
• For example, a driver class object will be responsible only for driving signals to the design,
while a monitor simply monitors the design interface and does not drive signals to that
interface.
• These components already have the necessary code that will let them connect between
each other, handle data packets and work synchronously with others.
Evolution of UVM
.❖ Major EDA vendors had their own methodologies
l

➢ Mentor graphics - AVM for System Verilog

➢ Cadence - eRM for Spaceman e, uRM for System Verilog
➢ Synopsys - VMM for System Verilog

❖ Open Verification Methodology (OVM)

➢ Joint development initiative by Mentor graphics and Cadence
➢ Open, interoperable, System Verilog based Methodology

❖ Universal Verification Methodology (UVM)

➢ Common Methodology by Mentor graphics, Cadence and Synopsys
➢ Interoperability - Multi language support
➢ Based on OVM proven library
➢ Scales from Block level to System level
 What is UVM ?

• SystemVerilog is a language just like Verilog and has its own

constructs, syntax and features, but UVM is a framework of
SystemVerilog classes from which fully functional testbenches can
be built.
• There's only one prerequisite to learn UVM, and that is
SystemVerilog because it is the foundation for the tower that is
UVM.
Why do we need UVM ?

• The primary advantage is that the methodology specifies and lays out a set of
guidelines to be followed for creation of verification testbenches.
• This will ensure testbench uniformity between different verification teams,
cross-compatability between IP and standalone environment integration,
flexibility and ease of maintaining testbenches.
• For example, there can be many different ways to implement display messages
and control verbosity with different settings such as warning, error and debug.
• In UVM, the underlying reporting mechanism has been standardized and made
available so that engineers can instead focus on the most important part of their
job which is design verification.
• Another example is that the sequencer-driver handshake mechanism is taken
care of under the hood so that only stimulus needs to be written.
• This saves quite a lot of time in setting up a testbench structure since the
foundation itself is well defined.
 How does UVM help ?

• Every verification testbench has a few key components like

drivers, monitors, stimulus generators, and scoreboards.
• UVM provides a base class for each of these components with
standardized functions to instantiate, connect and build the
testbench environment.
• These are static entities called components in a verification
environment that exist throughout a simulation just like buildings
in a city.
• These components operate and process on some kind of data
that flows around the
• environment similar to people and vehicles in the city.
• The data or transactions are called objects or sequence items
since they appear and disappear at various times in the
simulation and is more dynamic in nature.
What is the UVM class hierarchy ?

• UVM provides a set of base classes from which more complex

classes can be built by inheritance and adding onto it certain
functions required for verification environment.
• For example, a new driver class for Wishbone protocol can be
built by extending from the UVM base class uvm_driver .
• Stimulus for the protocol can be written by extending from
uvm_sequence_item .
• How this sequence is built, and handed over to the driver is
taken care of internally by the UVM framework.
• uvm_void is the base of all classes, but it is primarily empty.
• uvm_object is the main class in which common functions to
print, copy, and compare two objects of the same class are
defined.
What is the UVM class hierarchy ?

• There are two branches in the hierarchy.

• The first one contains classes that define verification components like driver, monitor
and the rest shown in the diagram as everything underneath uvm_report_object .
• The second one defines data objects consumed and operated upon by verification
components shown in the diagram as everything underneath uvm_transaction .
Major UVM class categories UVM Objects

• The idea behind UVM is to enhance flexibility and reuse code so that the same testbench
can be configured in different ways to build different components, and provide different
stimulus.
• These new user defined configuration classes are recommended to be derived from
uvm_object .
• For example, a configuration class object can be built to have certain settings that define
how the testbench environment has to be built.
UVM Sequence

• UVM also introduces the concept of a sequence which is nothing but a

container for the actual stimulus to the design.
• If you put different stimuli into different sequences, it enhances the ability to
reuse and drive these sequences in random order to get more coverage and
verification results.
• All new user defined stimulus classes are recommended to be inherited
from uvm_sequence .
• Each sequence can be used inside other sequences to create different
scenarios.
• For example, individual sequences can be created, one each for "read" and
"write" transactions.
• They can be used in a random pattern in some other sequence to perform
R->W->R->W,or R->R->R->W, W->W->R->R and other similar patterns.
UVM Sequence Items

• Data objects that have to be driven to DUT are

generally called as sequence items and are
recommended to be inherited from
uvm_sequence_item .

• For example, a sequence item class can be defined

for an APB transaction that defines what the address,
write/read data and access type should be and send it
to an APB driver to drive the transaction to DUT.
UVM Components

• All major testbench components are derived from the

corresponding base class.
• For example, all new user defined driver classes are
recommended to be inherited
• from uvm_driver and monitor classes from uvm_monitor and so
on.
• A brief description of what each UVM component does is given in
the table below.
Register Layer

• Digital designs support control registers that can be configured

by software, and this has been very challenging in a
SystemVerilog testbench, because for each project you had to
build a separate set of classes that can store and configure
these registers.
• UVM has an extensive set of classes to make that task
relatively simpler and belong to something known as a register
model.
• This is very useful in the verification of IPs that can be reused
in various SoC designs.
TLM Connections

• Another really smart feature is the use of TLM from

System C.
• TLM helps to send data between components in the
form of transactions and class objects.
• It also brings a way to broadcast a packet to its
listeners without having to create specific channels
and attach to it.
UVM Phases

• Another main feature that verification components inherit from

their parent class uvm_component is Phasing.
• This enables every component to sync with each other before
proceeding to the next phase.
UVM Testbench Overview
.1.
l
UVM stand for the Universal Verification Methodology.
2. Created by Accellera based on the OVM (Open Verification
Methodology) version 2.1.1.
3. UVM is a methodology for functional verification using
SystemVerilog, complete with a supporting library of SystemVerilog
code.
4. UVM is a methodology for the functional verification of digital
hardware, primarily using simulation.
5. UVM is explicitly simulation-oriented, but UVM can also be used
alongside assertion-based verification, hardware acceleration or
emulation.
Why UVM Class Library?

The UVM Class Library provides generic utilities, such as

❖ component hierarchy,

❖ transaction library model (TLM),

❖ configuration database,

which enable the user to create virtually any structure for the
testbench.
Features of uvm_component Class

❖ hierarchy searching,

❖ phasing,

❖ configuration,

❖ reporting,

❖ factory,

❖ transaction recording
UVM Building Blocks

.
l

UVM UVM
UVM env
Components test

Main Building blocks of a UVM Test Bench

UVM Testbench

❖ Typical UVM Testbench Hierarchy

UVM Testbench Architecture

UVM Testbench
.
l
UVM Test
Sequences
UVM Environment
UVM Agent

UVM
Sequencer UVM Agent Design
UVM
Under Test
UVM
Scoreboard Environment ( DUT )
UVM
Config/Factory Environment
Overrides
UVM Testbench Architecture
Module TOP
UVM Test
UVM Env
Agent [0]

Sequencer Config
Config Interface
Sequencer [0]
Scoreboard 0
Scoreboard 0 Driver Driver

MonitorMonitor

Agent [1]
Config
Config Interface
Sequencer
Sequencer
[1]
Scoreboard 1
Scoreboard 1 Driver Driver

MonitorMonitor

Sequence 1 Sequence 2 Sequence 3 Run (task)

UVM Testbench

➢ Instantiate
● Design under Test (DUT) module
● UVM Test class

➢ Configure connection between DUT and Test Class

➢ Dynamically Instantiate
● UVM Test

➢ Advantage
● compiled once
● run with many different tests.
UVM Test

➢ The test is the topmost class. the test is responsible for,

● configuring the testbench.

● Initiate the testbench components construction process by building

the next level down in the hierarchy ex: env.

● Initiate the stimulus by starting the sequence.

UVM Test

class user_defined_test extends uvm_test;

----------------------

endclass

➢ uvm_test is the base class from UVM class library.

➢ uvm_test extends uvm_component.

➢ So uvm_test is a component.
UVM Environment

Agent/UVC
Mem Controller Agent DUT
Component
Repository
UVM
UVM Driver
Sequencer Memory
Controller

UVM Monitor

Peripheral Agent
UVM
UVM Driver
Sequencer
Peripheral

UVM Monitor
UVM Environment

➢ Env or environment: The environment is a container component for

grouping higher level components like agent’s and scoreboard.

➢ It is a hierarchical component which is extended from

uvm_component.

➢ It groups together other verification components that are interrelated.

➢ uvm_env is used to create and connect the uvm_components like

driver, monitors, sequencers, UVM Scoreboards etc.

➢ A environment class can also be used as sub-environment in another

environment.
UVM Environment

class user_defined_env extends uvm_env;

----------------------

endclass

➢ uvm_env is the base class from UVM class library.

➢ uvm_env extends uvm_component.

➢ So uvm_env is a component.
UVM Environment (Example)

➢ In a typical system on a chip (SoC) UVM Environment,

● one UVM Environment per IP
■ PCIe Environment,
■ USB Environment,
■ Memory Controller Environment, etc.).

➢ IP Environments are grouped together into Cluster Environments

● IO Environment,
● Processor Environment

These are grouped together eventually into SoC Environment.

What is UVM Agent?

➢ UVM agent groups the uvm_components specific to an interface or protocol.

➢ example: groups the components associated with BFM(Bus Functional Model).
➢ The components of an agent are,

➢ UVM Agent
● Encapsulated, Ready to use, Configurable components
● Reusable - plug and play

➢ UVM environment contains one or more agents.

● Agent - Driver, Monitor and Sequencer

➢ Agent can be configurable

➢ Testbench infrastructure can have more than one agents

➢ Also known as UVC (Universal Verification Component)

UVM Agent

Sequence
UVM Agent

UVM
UVM Driver
Sequencer

DUT
UVM Monitor interface
UVM Agent

➢ Verification Component includes

● Sequence_item
■ Data item based on the DUT protocol
■ Also known as stimulus

● Sequencer
■ Manage stimulus flow
■ Route sequence_items from a sequence to the driver

● Driver
■ It converts sequence_item into the pin level for DUT

● Monitor
■ It converts pin level data to the transactions for use in scoreboard, coverage
models, etc
UVM Agent

➢ Verification Component includes

● Configuration object
■ A container object, used to pass information to the agent which affects what
it does and how it is built and connected

● Sequencers and Drivers are connected using TLM ports

● Other components
■ coverage collectors,
■ protocol checkers,
■ TLM mode
UVM Agent

class user_defined_agent extends uvm_agent;

----------------------

endclass

➢ uvm_agent is the base class from UVM class library.

➢ uvm_agent extends uvm_component.

➢ So uvm_agent is a component.
UVM Agent

Interface
Config
DUT is_active = 0
UVM
Agent Monitor
vi

(Passive)

UVM
UVM
Sequen vi
Driver
Interface

cer
Config
DUT
is_active = 1
UVM
Agent Monitor
vi

(Active)
UVM Agent

➢ Needs to operate both in

● an active mode

It is capable of generating stimulus

● a passive mode

It only monitors the interface without controlling it.

UVM Sequencer

➢ Serves as an arbiter for controlling transaction flow from multiple

stimulus sequences.

➢ UVM Sequencer controls the flow of UVM Sequence Items

transactions generated by one or more UVM Sequences.
➢ Responsible for routing the data packet’s(sequence_item) generated in
sequence to the driver or vice verse.
UVM Sequencer

class user_defined_sequencer extends uvm_sequencer #(REQ, RSP);

----------------------

endclass

➢ uvm_sequencer is the base class from UVM class library.

➢ uvm_sequencer extends uvm_component.

➢ So uvm_sequencer is a component.
UVM Sequence

➢ It is an object that contains a behavior for generating stimulus.

➢ Defines the sequence in which the data items need to be generated and
sent/received to/from the driver.

➢ UVM Sequences are not part of the component hierarchy.

➢ A UVM Sequence instance can come into existence for a single

transaction.

➢ It may drive stimulus for the duration of the simulation, or anywhere in

between.
UVM Sequence

➢ Can operate hierarchically with one sequence, called a parent

sequence, invoking another sequence, called a child sequence.

➢ Each UVM Sequence is eventually bound to a UVM Sequencer.

➢ Multiple UVM Sequence instances can be bound to the same UVM

Sequencer.
UVM Sequence

class user_defined_sequence extends uvm_sequence #(REQ, RSP);

----------------------

endclass

➢ uvm_sequence is the base class from UVM class library.

➢ uvm_sequence extends uvm_object.

➢ So uvm_sequence is a object.
UVM Driver

➢ The UVM Driver receives individual UVM Sequence Item transactions

from the UVM Sequencer and applies (drives) it on the DUT Interface.

➢ A UVM Driver spans abstraction levels by converting transaction-level

stimulus into pin-level stimulus.

➢ TLM port
● Receive transactions from the Sequencer
● Access to the DUT interface in order to drive the signals.
UVM Driver

class user_defined_driver extends uvm_driver;

----------------------

endclass

➢ uvm_driver is the base class from UVM class library.

➢ uvm_driver extends uvm_cmponent.

➢ So uvm_driver is a component.
UVM Monitor

➢ Observes pin level activity on interface signals and converts into

packet level which is sent to components such as scoreboards.

➢ It samples the DUT interface and captures the information therein

transactions that are sent out to the rest of the UVM Testbench for
further analysis.

➢ It spans abstraction levels by converting pin-level activity to

transactions.

➢ It has TLM analysis port to broadcast the created transactions through.

➢ Perform coverage collection, checking, logging, recording, etc. or can

delegate that to dedicated components connected to the monitor's
analysis port.
UVM Monitor

class user_defined_monitor extends uvm_monitor;

----------------------

endclass

➢ uvm_monitor is the base class from UVM class library.

➢ uvm_monitor extends uvm_component.

➢ So uvm_sequence is a component.
UVM Scoreboard

• Receives data item’s from monitor’s and compares with expected values.
 Summary : UVM Testbench Overview
.1. UVM Testbench
l

2. UVM Test
3. UVM Environment
4. UVM Agent
5. UVM Sequencer
6. UVM Sequence
7. UVM Driver
8. UVM Monitor