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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a UVM Methodology Tutorial

Semelhante a UVM Methodology Tutorial (20)

Mais de Arrow Devices

Mais de Arrow Devices (6)

Último

Último (20)

UVM Methodology Tutorial