UVM Methodology Tutorial

Any use of this material without specific permission of Arrow Devices is strictly prohibited
May 2015
UVM
Methodology

Topics
covered

•  Introduc0on

•  SV
Test-‐bench
Architecture

•  UVM
Test-‐bench
Architecture

•  UVM
Conﬁgura0on

•  UVM
Messaging

•  UVM
Sequences

•  UVM
Test

•  UVM
Phasing

•  UVM
Overriding

2
Arrow Devices Pvt Ltd

Introduc0on


UVM Core Capabilities
l Universal Verification Methodology or UVM
Ø  A methodology and a class library for building advanced
reusable verification component
l Relies on strong, proven industry foundations
Ø  The core of its success is adherence to a standard (i.e.
architecture, stimulus creation, automation, factory usage
standards etc.)

Origin of UVM

The Goal: Automation
l Coverage Driven Verification
(CDV) environments
l Automated Stimulus
Generation
l Independent Checking
l Coverage Collection
Following can be automated using UVM

SV
Test-‐bench
Architecture


SV
Testbench
Architecture


Example:
SV
FIFO
Testbench


UVM
Test-‐bench
Architecture


UVM Test-bench Architecture

Example:
UVM
FIFO
Testbench
(1/3)



Example:
UVM
FIFO
Testbench
(2/3)

•  Descrip0on
of
Pop
Agent


Example:
UVM
FIFO
Testbench
(3/3)

UVM
Class
Hierarchy


UVM Agent
l Agents provide all the verification
logic for a device in the system
l Instantiation and connection logic
is done by the developer in a
standard manner
l A Standard agent has:
Ø  Sequencer for generating
traffic
Ø  Driver to drive the DUT
Ø  Monitor
l Agent has standard configuration
parameters

UVM Agent: Standard Configuration
l  A standard agent is configured using an enumeration field:
“is_active”
Ø  UVM_ACTIVE:
Ø  Actively drive an interface or device
Ø  Driver, Sequencer and Monitor are allocated
Ø  UVM_PASSIVE:
Ø  Only the Monitor is allocated
l Still able to do checking and collect coverage
l Other user-defined configuration parameters can also be added
Ø  Example: address configuration for slave devices

Driver-Sequencer Model

UVM
Conﬁgurable
Bus
Environment


UVM
Conﬁgura0on


UVM Configuration Mechanism
l  The configuration mechanism allows a powerful way for attribute
configuration
l  Configuration mechanism advantages:
Ø  Mechanism semantic allows an upper component to override
contained components values
-  No file changes are required
Ø  Can configure attributes at various hierarchy locations
Ø  Wild cards and regular expressions allow configuration of multiple
attributes with a single command
Ø  Debug capabilities
Ø  Support for user defined types (e.g. SV virtual interfaces)
Ø  Run-time configuration support
Ø  Type safe solution

UVM Database
l uvm_config_db
l uvm_resource_db
UVM supports the following database

Example:
UVM
Conﬁgura0on
Database

l 
The
full
signature
of
set
method
is

uvm_config_db #( type T = int )::set( uvm_component cntxt ,
string inst_name , string field_name , T value );
interface ahb_if data_port_if( clk , reset );
interface ahb_if control_port_if( clk , reset );
...
uvm_config_db #( virtual ahb_if )::set( null , "uvm_test_top" ,
"data_port" , data_port_if );
uvm_config_db #( virtual ahb_if )::set( null , "uvm_test_top" ,
"control_port" , control_port_if );

UVM Messaging Facility
l Messages print trace information with advantages over
$display:
Ø Aware of its hierarchy/scope in testbench
Ø Allows filtering based on hierarchy, verbosity, and time
l Simple Messaging:
Ø `uvm_*(string id, string message, <verbosity>);Where
*(severity) is one of fatal, error, warning, info
Ø <verbosity> is only valid for uvm_info

UVM Sequences

Transaction : uvm_seq_item
l UVM provides all the necessary operations using factory
registration
Ø  Randomization
Ø  Printing
Ø  Cloning
Ø  Comparing
Ø  Copying
Ø  Packing
Ø  Transaction Recording

Fifo Sequence Item

UVM Sequences
l A sequencer controls the generation of random stimulus by
executing sequences
l A sequence captures meaningful streams of transactions
Ø  A simple sequence is a random transaction generator
Ø  A more complex sequence can contain timing, additional
constraints, parameters
l Sequences:
Ø  Allow reactive generation – react to DUT
Ø  Have many built-in capabilities like interrupt support,
arbitration schemes, automatic factory support, etc
Ø  Can be nested inside other sequences
Ø  Are reusable at higher levels

UVM Sequences
l A sequence is started by two ways
Ø  Setting as the default sequence
Ø  Using a call to its start() method
l Start Method and example

Virtual
task
start
(uvm_sequencer_base
sequencer,
//
Pointer
to
sequencer

uvm_sequence_base
parent_sequencer
=
null,
//
Relevant
if
called
within
a
sequence

integer
this_priority
=
100,
//
Priority
on
the
sequencer

bit
call_pre_post
=
1);
//
pre_body
and
post_body
methods
called

//
For
instance
-‐
called
from
an
uvm_component
-‐
usually
the
test:

apb_write_seq.start(env.m_apb_agent.m_sequencer);

//
Or
called
from
within
a
sequence:

apb_compare_seq.start(m_sequencer,
this);


Example: FIFO Sequence

Virtual Sequence

UVM Test

UVM Test
l Placing all components in the test requires lot of duplication
l Separate the env configuration and the test
Ø  TB class instantiates and configures reusable components
l Tests instantiate a testbench
Ø  Specify the nature of generated traffic
Ø  Can modify configuration parameters as needed
l Benefits
Ø  Tests are shorter, and descriptive
Ø  Less knowledge to create a test
Ø  Easier to maintain - changes are done in a central location

UVM Phasing

UVM Simulation Phases
l The Standard UVM phases
Ø  Build phases, Run-time phases and Clean up phases
l Unique tasks are performed in each simulation phase
Ø  Set-up activities are performed during “testbench
creation”while expected results may be addressed in “check”
Ø  Phases run in order –next phase does not begin until
previous phase is complete
l UVM provides set of standard phases enabling VIP plug&play
Ø  Allows orchestrating the activity of components that were
created by different resources

UVM Simulation Phases

Example: FIFO Environment Phases

UVM Overriding

Overriding SV components and
Data Objects
l UVM Provides a mechanism for overriding the default data
items and objects in a testbench
l “Polymorphism made easy” for test writers
l Replace ALL instances:
Ø  object::type_id::set_type_override(derived_obj::get
_type())
l Replace Specific instances
Ø  object::type_id::set_inst_override(derived_obj::get_
type(), “hierarchical path”);

Extensions Using Callbacks
l Like the factory, callbacks are a way to affect an existing
component from outside
l The SystemVeriloglanguage includes built-in callbacks
Ø  e.g. post_randomize(), pre_body()
l Callbacks requires the developer to predict the extension
location and create a proper hook
l Callbacks advantages:
Ø  They do not require inheritance
Ø  Multiple callbacks can be combined

UVM
Advantages
(1/2)

•  Standard
communica0on
between
components

•  End
of
test
is
well
defined

•  All
the
tasks
in
the
component
are
pre-‐defined
standard

names
by
using
Phasing

•  Standard
Sequencer
to
Driver
Communica0on

•  Separa0ng
testbench
into
structural
and
behavioral

•  Configura0on
database
ie
either
easy
to
use
or
to
change


UVM
Advantages
(2/2)

•  Using
Factory
registra0on

•  You
can
override
the
type
or
instance
of
trasac0ons,

components
etc.,

Ø  Configura0on
can
be
changed
easily

Ø  Overridden
components
can
be
used
with
less
efforts

Ø  Provides
user
more
flexbility
in
wri0ng
tests

•  Reusability

•  Debugging


Thank
you


UVM Methodology Tutorial

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to UVM Methodology Tutorial

Similar to UVM Methodology Tutorial (20)

More from Arrow Devices

More from Arrow Devices (6)

Recently uploaded

Recently uploaded (20)

UVM Methodology Tutorial