Arrow Devices Uvm

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 Configura0on •  UVM Messaging •  UVM Sequences •  UVM Test •  UVM Phasing •  UVM Overriding

2 Arrow Devices Pvt Ltd

Introduc0on

Arrow Devices Pvt Ltd

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)




•  Descrip0on of Pop Agent



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 Configurable Bus Environment


UVM Configura0on


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 Configura0on 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


Arrow Devices Uvm

Documents

uvm agent

uvm database

db arrow devices pvt

introduc0on arrow devices

allocated uvm

active uvm

uvm configuration mechanism

uvm fifo testbench