Hidden gems of UVM Base Class Library - debug

techniques for UVM users

Pranesh Sairam, ASIC Design Verification Engineer, CVC Pvt. Ltd, Bangalore, India
(pranesh@cvcblr.com)
Azhar Ahammad, ASIC Design Verification Engineer, CVC Pvt. Ltd, Bangalore, India
(azharahammad@gmail.com)
Arun P C, ASIC Design Verification Engineer, CVC Pvt. Ltd, Bangalore, India
(mailz4apc@gmail.com)

Abstract Universal Verification Methodology (UVM) is the industry standard verification methodology for
Verification using SystemVerilog (SV). UVM provides means of doing verification in a well-defined and structured
way. It is a culmination of well-known ideas, thoughts and best practices. Given the major adoption of UVM across
the globe and across the industry, advanced users are looking for tips and tricks to improve their productivity.
Keywordstricks;vault;framework;

I.

INTRODUCTION

UVM does define a structured framework for building complex test benches, given the strong OOP
nature of UVM (and underlying SystemVerilog) and the relatively less familiar audience (as many DesignVerification, DV engineers come from hardware, electronics background and not a heavy Software
background), it gets tricky for users to debug UVM based test benches when things do not work as expected.
In this paper the authors share tips and tricks for run time debug of common UVM issues and potential
solutions to them. During our various training and consulting engagements using UVM we have seen DV
engineers struggling to debug relatively simple UVM issues though the error messages are cryptic at times
and do not point to the actual source code, rather somewhere from the base classes, making the debug difficult.
We have captured a series of such common issues and error messages into a collateral form that we call it as
UVM Vault
Specifically, we will highlight the following features in UVM and how to debug them at run time:

Factory

Objections

Config-DB

UVM CLP - Command Line Processor

II.

FACTORY

UVM provides a convenient way to control which objects get manufactured at run time via the well-known
Factory Design pattern.In class-based programming, the factory method pattern is a creational pattern that uses
factory methods to deal with the problem of creating objects without having to specify the exact class of the
object that will be created. This is done by creating objects by calling a factory method rather than by calling a
constructor.
In UVM to use factory, there are three important steps:

Registration all classes shall be registered with a global factory singleton table
Use class::type_id::create() instead of new()
Use set_type_override functions

A. Multiple override- Replace:

There are cases when multiple overrides are set on the same object. There are use cases to "ignore"
such overrides and then other situations where-in it is desired to "replace". UVM's factory override mechanism
supports both requirements. Consider a transaction model derived as shown in Figure 1 , there are two similar
error transactions derived from a base ahb_xactn.

Replaces the previous override

Figure 1: Replace override

This is a handy trick to run a test with a few 100 transactions first with one type and then replace with
another derived type and run another few 100s within the same test!
B. Factory_undo
A work-around for achieving the same in UVM 1.1d version could be to derive a dummy, new class from the
base class and use it. The new class that is derived should contain no extra code and is intended to just fool the
compiler to treat it as a derived type, but functionally same as the base type. Figure 2 shows a possible
ahb_undo_xactn UML diagram to explain this.

VF
a
c
c_
_
a
oh
b
y_
x_
xa
ac
c t
n
n
n

l
t
r

tt
Figure 2: Factory undo

C. Impact of name in overrides

In the build_phase the environment is constructed using factory's create() but for experimentation sake the
name has been changed to CRAZY_ENV as shown in the Figure 3.This directly impacts the hierarchical name
of this component and all underneath (as the path has a different name). Fast-forward, consider a test writer
setting an instance based factory override for the sequence item within this env-agent-sequencer .This is shown
in figure 4.

Figure.3: env name is changed as CRAZY_ENV

Figure 4: CRAZY_ENV is used while overriding

III.

OBJECTIONS:

UVM Objections are used to control when a time consuming phase is going to end, Understanding when an
objection is raised and dropped can be difficult especially since all the raised objection call must be matched
with the number of dropped objections by +UVM_OBJECTION_TRACE in CLP

# UVM_INFO @ 0: reset_objection [OBJTN_TRC] Object

uvm_test_top.apb_env_0.agent0.driver raised 1 objection(s): count=1 total=1
# UVM_INFO @ 0: reset_objection [OBJTN_TRC] Object
uvm_test_top.apb_env_0.agent0 added 1 objection(s) to its total (raised from
source object ): count=0 total=1

** Report counts by id
# [OBJTN_TRC] 912
Figure 5:

IV.

CONFIG_DB

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.
If the run time +UVM_CONFIG_DB_TRACE command line option is specified, all configuration DB
accesses (read and write) are displayed.

+UVM_CONFIG_DB_TRACE

Figure 6:

V.

UVM CLP - COMMAND LINE PROCESSOR

It provides an interface to the command line arguments given for the simulation intended to be used as a
singleton, Generation of the data structures hold the command line argument a global variable called
uvm_cmdline_proc is created at initialization time and may be used to access command line information.

string foo_values[$]
initial
begin
void'(uvm_cmdline_proc.get_arg_values("+foo=",foo_va
lues));
Figure 7:

REFERENCES
[1]

Accellera UVM standard http://accellera.org/downloads/standards/uvm

[2]

UVM training material from: http://www.cvcblr.com/trng_profiles/Comprehensive-UVM.pdf

[3]

Go2UVM http://www.go2uvm.org

[4]

UVM Vault http://www.verifworks.com