Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers

by Sutherland HDL, Inc., Portland, Oregon, 2016

Adopting the SystemVerilog

Universal Verification
Methodology (UVM)
An in-depth examination of whats inside
a UVM testbench, and what is needed to
be successful at adopting UVM
by Stuart Sutherland

Training Engineers to be SystemVerilog wizards

www.sutherland-hdl.com
contains proprietary, confidential and copyrighted material of Sutherland HDL, Inc.

Adopting the SystemVerilog Universal

Verification Methodology (UVM)
Copyright 2016: This seminar handout is the proprietary, confidential and
copyrighted material of Sutherland HDL, Inc., Portland, Oregon. All rights reserved. No
material from this handout may be duplicated or transmitted by any means or in any
form, in whole or in part, without the express written permission of Sutherland HDL,
Inc. Much of this seminar handout is excerpted from Sutherland HDLs UVM training
materials, first published in 2011 with the title Mastering the SystemVerilog Universal
Verification Methodology (UVM). Registered 2013.
Intellectual Property License: This seminar handout and associated materials are the
Intellectual Property of Sutherland HDL, Inc. They are licensed without transfer of
rights for individual use by participants in Sutherland HDL training workshops and
seminars only. Sutherland HDL retains full and exclusive title and rights to this
Intellectual Property. These materials may not be duplicated or distributed in any form,
in whole or in part, without the express written permission of Sutherland HDL.
Sutherland HDL Incorporated
22805 SW 92nd Place
Tualatin, OR 97062 USA

phone: +1-503-692-0898
e-mail: [email protected]
web: www.sutherland-hdl.com

printed 26 January 2016

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

Seminar Objectives...

This seminar will:

Discuss the benefits of UVM (and some disadvantages, too)
Provide an in-depth overview of what is inside a UVM testbench
Examine what it takes to adopt UVM in your next project

The presentation assumes:

You are familiar with the requirements of design verification
You are familiar with the SystemVerilog language

At least enough to recognize the general idea of code examples

And the hidden agenda we want you to know that

Sutherland HDL is in the business of training engineers to be

SystemVerilog and UVM Wizards!

Primary Goals of the UVM

Verification Methodology

Some of the goals of a standard verification methodology are:

Reuse, Reuse, Reuse

Configurable test environments that can be used for many tests

Reusable testbench components from project to project
Interoperability
Verification that works with many types of tools from many vendors
Verification Intellectual Property (VIP) models
In-house verification code of components that make up a design
Commercial verification code for commercial components
Separate stimulus generation from stimulus delivery to the DUT
The verification team can develop verification code in parallel
Best practices
A consistent way of using SystemVerilog at all companies
And the reason no one talks about Sell More Verification IP
The major EDA companies make a lot of money selling VIP models

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

In an effort to create a universal methodology

that would be all things for all designs, the
engineers on the UVM standards committee drew
from existing methodologies, and created

UVM
an Ugly Vicious Monster!

UVM is very complex because it is intended to work

with any type of design in the entire universe

The complexity of UVM can make it difficult to adopt

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

Good training and expert help can change

the Ugly Vicious Monster into a

Useful Verification Methodology

I found your design bug Its right here!
module controller (...);
enum {WAIT, LOAD, STORE} State, NextState;
always @(posedge clock or posedge resetN)
if (!resetN) State <= WAIT;
else State <= NextState;
always_comb
case (State)
WAIT:
NextState = LOAD;
LOAD:
NextState = STORE;
STORE: NextState = WAIT;
endcase
...
endmodule

UVM was created by an organization called Accellera

A non-profit think tank that creates new EDA standards
Comprises EDA companies and companies creating electronic chips
UVM is a summation of verification knowledge and experience

2000 vAdvisor (Verification Advisor) by Verisity (acquired by Cadence)

2002 eRM (e Re-use Methodology) by Verisity (acquired by Cadence)
2003 RVM (VERA Reuse Verification Methodology) by Synopsys
2006 VMM (SystemVerilog Verification Methodology Manual) Synopsys
2006 AVM (SV Advanced Verification Methodology) by Mentor Graphics
2007 URM (SV Universal Re-use Methodology) by Cadence
2008 OVM (SV Open Verification Methodology) by Cadence & Mentor

UVM draws from all of these!

UVM Origins

May 2010 UVM 1.0EA (early adopter) very preliminary version

Rapid
Feb 2011 UVM 1.0 major changes to 1.0EA, still preliminary
evolution of a
Jun 2011 UVM 1.1 major changes to 1.0, stable for 1.1a1.1d standard with
backward
Jun 2014 UVM 1.2 updates and major changes to 1.1
compatibility
issues
2015/16? IEEE 1800.2 anticipate major changes to 1.2

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

What UVM Provides

UVM is SystemVerilog source code that provides:

A library of base classes

For coding testbench components (drivers, monitors, scoreboards)

A factory
For constructing objects and substituting objects
Verification phases
For synchronizing concurrent processes
A reporting mechanism
For a consistent way of printing and logging results
Transaction-Level Modeling (TLM)
For communication between verification components
Macros
To semi-automate generation of required UVM code
UVM requires advanced-level SystemVerilog and OOP programming skills!

10

UVM Class Hierarchy

( is a relationships)

The UVM library provides a set of base classes

Your code will be derived from one of these base classes
Stimulus branch
(transient objects)

Testbench branch
(permanent objects)
uvm_object

uvm_transaction
uvm_sequence_item

uvm_report_handler

uvm_report_object
uvm_sequence

uvm_subscriber

uvm_test

uvm_component

uvm_agent
uvm_env

proprietary and confidential property of Sutherland HDL, Inc.

TLM Ports

uvm_driver

uvm_sequencer

uvm_scoreboard
uvm_monitor

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

11

UVM Testbench Hierarchy

( has a relationships)
A test class has sequence objects and an environment object
An environment class has component objects to talk to the DUT
test

configuration and factory settings

Stimulus

transaction
generator
(sequence)

(test behavior)

scoreboard

coverage collector

Separation of stimulus from

testbench structure:
Allows the testbench to be
reused for many tests
Allows parallel effort
within a verification team
Allows teams with specific
focus and expertise

agent(s)

monitor

coverage collector
sequencer

transactions

DUT
interface
signals
interface
signals

driver

interface

virtual sequencer

transactions

predictor evaluator

configuration

(test structure)

environment

configuration

Testbench

transaction
generator
(sequence)

transactions

12

TLM Communication
TLM ports pass handles of
sequence_item objects

UVM also
implements the
TLM 2.0 standard

UVM uses the SystemC TLM 1.0 Transaction Level

Modeling standard for communication between components
A port or analysis port specifies a set of communication methods
An export or imp export implements the ports methods

producer pushes transactions

to consumer
producer
port

consumer

consumer pulls transactions

from producer
producer

export

The port and export have

a user-defined name,
similar to Verilog ports

consumer

export

port

analysis ports push transactions

consumer
producer
analysis port

UVM drivers pull

transactions from a
sequencer

consumer
imp export

UVM monitors broadcast

transactions to scoreboards
and coverage collectors

A port must be paired with exactly one export (one-to-one)

An analysis port is paired with zero or more imp exports (one-to-many)

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

13

The UVM Factory

The UVM factory is used to build the UVM object hierarchy

Constructs the class objects

A factory create() method is used instead of directly calling new()

Allows tests to swap out testbench components for specific tests

Can change drivers, scoreboards or other components
Can change method behavior, add constraints, etc.
give me a

usb2_test

USB 1 agent

swap in a USB 3 agent in

place of a USB 1 agent

here is a
USB 3 agent

A factory is an advanced-level, complex Object Oriented

programming technique with UVM, the factory is
provided in the base classes your just need to use it!

14

UVM Phases

UVM components synchronize with each other using UVM phases

build
connect
end of elaboration

The construction phases are where the

construction
phases

testbench is configured and constructed

All construction phases execute in zero

time and at simulation time zero

start of simulation
run

run
phase

extract
check
report

The run phase is where simulation time is

consumed in running the tests

The run phase can be further subdivided

into several phases (later slide)

cleanup
phases

The cleanup phases are where the results

of the tests are collected and reported

All cleanup phases execute in zero time

final

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

15

UVM Phase Tasks

and Functions
Each UVM component can start activity in any of the phases
class my_agent extends uvm_agent;
...
function void build_phase(...);
... // construct components
endfunction

class my_sb extends uvm_scoreboard;

...
function void build_phase(...);
... // construct components
endfunction

function void connect_phase(...);

... // connect components
endfunction

function void connect_phase(...);

... // connect components
endfunction

endclass: my_agent

task run_phase(...);
... // evaluate dut outputs
endtask

class my_driver extends uvm_driver;

...
task run_phase(...);
... // get transaction & drive
endfunction
endclass: my_driver

function void report_phase(...);

... // report the pass/fail score
endfunction
endclass: my_sb

Each phase does not end until all activity for that phase type has completed in every
component (e.g.: all build phases must complete before any connect phase can start)

16

Who Invokes Phase Methods?

Pay no attention
to that man behind
the curtain!
This famous quote from the

The Wizard of OZ
movie (1939) applies to UVM!
A virtual wizard behind the scenes
takes care of running the UVM
testbench all you need to do is tell
the wizard which test to run

The top-level module invokes a run_test() method

This method is the wizard behind the curtain that controls the
UVM execution, including invoking the phase methods in order

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

Objection Flags Control How Long

the Run Phase Actually Runs

17

The UVM run phase:

Automatically starts running at simulation time 0, after the
construction phases have completed
Continues to run as long as at least one run_phase() task
objects to the run phase ending

class test1 extends uvm_test;

...
task run_phase (uvm_phase phase);
phase.raise_objection(this);
... // do test 1 stuff
phase.drop_objection(this);
endtask
endclass

class sb extends uvm_scoreboard;

...
task run_phase (uvm_phase phase);
phase.raise_objection(this);
... // do verification stuff
phase.drop_objection(this);
endtask
endclass

The objection flag can be abused if not careful two GOTCHAS to watch out for:

Simulation will end at time 0 if no run_phase() tasks raise their objection flag
Simulation will never end if a run_phase() task raises its objection flag and then
locks up waiting for something to happen (or gets stuck in an infinite loop)

18

Run Phase Divisions

build
connect
end of elaboration
start of simulation

UVM 1.0 and 1.1 allow dividing

pre-reset

the run phase into sub-phases

Gives greater control over the
order of complex stimulus
Allows phase jumping
forward or backward within the
run phase ordering

reset
post-reset
pre-config
config
post-config

run

CAUTION:
The UVM 1.0/1.1 standards have
problems with the implementation of
run phase subdivisions
UVM 1.2 deprecates the UVM 1.0/1.1
subdivided run phases and replaces it
with a different mechanism

pre-main
extract
check
report
final

main
post-main
pre-shutdown
shutdown

RECOMMENDATION:
Avoid using the additional run-time
phases, unless absolutely needed

post-shutdown

proprietary and confidential property of Sutherland HDL, Inc.

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

19

A Simple UVM Example

The UVM example on the following pages verifies a simple design

Shows the basic structure and hierarchy of a UVM testbench
Shows how to connect UVM testbench components
Shows how to start a UVM simulation
NOTE: This seminar focuses on the BIG PICTURE we will
avoid getting into too much nuts and bolts details

The design prints the message Hello World!

Every programming course
must have an example that
prints Hello World Its
the law!

Sutherland HDLs full UVM training course

uses a more complex and realistic example
than the one shown in this seminar

module hello_dut (input logic clk,

input logic go,
output logic done);
always @(posedge clk)
if (go) begin
$display("\nHello World!\n");
done = 1;
end
else done = 0;
endmodule

20

Sequence Items
(aka Transactions)

A sequence_item contains transaction data and methods

The methods can be hand written or generated using macros

class hello_tx extends uvm_sequence_item;

rand bit
go;
logic done;

// input to DUT
// output from DUT

// class constructor (called by factory)

function new(string name="hello_tx");
super.new(name);
endfunction
// register this class name in the factory
`uvm_object_utils_begin(hello_tx)
// automate implementation of methods
`uvm_field_int(go,
UVM_DEFAULT)
`uvm_field_int(done, UVM_DEFAULT)
`uvm_object_utils_end
endclass: hello_tx

proprietary and confidential property of Sutherland HDL, Inc.

10

Extended from a UVM base class

Variables hold the stimulus values
and DUT responses
The base class new() constructor
has a name argument SV syntax
requires the child call super.new()
and pass in a name (which comes
from the factory)
User class names are registered
with the factory using a macro
Macros can be used to automate
generation of the standard
transaction methods, such as print(),
copy() and compare()

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

21

Sequences
The Transaction Generator

A UVM sequence contains a body() virtual task that generates

one or more sequence_item objects (transactions)
Parameter redefinition
Derived from the uvm_sequence base class

class hello_sequence extends uvm_sequence #(hello_tx);

specializes the
sequence to a specific
sequence_item type

`uvm_object_utils(tx_sequence)
function new(string name="hello_sequence"); Register class name; call super.new
super.new(name);
endfunction
Generating a transaction involves 4 steps:
task body();
tx = hello_tx::type_id::create("tx"); First transaction:
start_item(tx);
1) Create a transaction using the factory
tx.go = 1'b1;
2) Wait for driver to ask for a transaction
finish_item(tx);
3) Set the transaction values
tx = hello_tx::type_id::create("tx"); 4) Pass the transaction to the driver
start_item(tx);
tx.go = 1'b0;
The next transaction repeats the 4 steps
finish_item(tx);
endtask: body
endclass: hello_sequence

22

Sequencers and Drivers

A sequencer routes transactions to the driver

All sequencer
class hello_sequencer extends uvm_sequencer #(hello_tx);
functionality is
... // register this class name in the factory
inherited from its base
endclass: hello_sequencer

The driver sends the stimulus to the Device Under Test (DUT)
Specialized to work with a
class hello_driver extends uvm_driver #(hello_tx);
specific sequence_item type
... // register this class name in the factory
function void build_phase(uvm_phase phase);
if (!uvm_config_db #(virtual hello_if)::get(this, "", "vif", vif))
`uvm_fatal("NOVIF","No virtual interface") The virtual interface is retrieved
endfunction: build_phase
from a database
task run_phase(uvm_phase phase);
The driver is a forever infinite loop it runs
hello_tx tx;
until the test drops its objection flag
forever begin
@(negedge vif.cb) ;
// sync up with inactive edge of DUT clock
seq_item_port.get(tx); // request a transaction from the sequencer
vif.cb.go <= tx.go;
// drive the DUT with the stimulus
end
UVM drivers use an interface clocking block to avoid race
endtask: run_phase
conditions enables reuse of UVM testbenches
endclass: hello_driver

proprietary and confidential property of Sutherland HDL, Inc.

11

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

23

Monitors

A UVM monitor samples the DUT input and output ports

Sampled values are saved in transaction objects (sequence items)
The transactions are sent to scoreboards and coverage collectors

A UVM monitor:
Observes the values going in to the DUT

Bundles the input values into an input transaction

Sends a copy of the transaction to a scoreboard predictor
Sends a copy of the transaction to a coverage collector
Observes the values coming out of the DUT
Bundles the output values into an output transaction
Sends a copy of the transaction to a scoreboard evaluator

1-24

An Example Monitor

class hello_monitor extends uvm_monitor;

Extended from uvm_monitor
... // register this class name in the factory
virtual hello_if vif;
uvm_analysis_port #(hello_tx) dut_in_tx_port;
uvm_analysis_port #(hello_tx) dut_out_tx_port;
Add two TLM analysis
function void build_phase(uvm_phase phase);
ports (one-to-many)
dut_in_tx_port = new("dut_in_tx_port", this);
dut_out_tx_port = new("dut_out_tx_port", this);
if (!uvm_config_db #(virtual hello_if)::get(this, "", "vif", vif))
`uvm_fatal("NOVIF","No virtual interface found!")
endfunction: build_phase
Get virtual interface from database
task run_phase(uvm_phase phase);
hello_tx tx_in, tx_out;
fork
1. Create a transaction object
forever @(vif.cb) begin // monitor DUT inputs 2. Capture input values
tx_in = hello_tx::type_id::create("tx_in"); 3. Send to scoreboard/cover
tx_in.go = vif.cb.go;
4. Do the loop again, as long
dut_in_tx_port.write(tx_in);
as run_phase continues
end
forever @(vif.cb) begin // monitor DUT outputs
tx_out = hello_tx::type_id::create("tx_out");1. Create a transaction object
2. Capture output values
tx_out.done = vif.cb.done;
3. Send to scoreboard
dut_out_tx_port.write(tx_out);
4. Do the loop again
end
join
endtask: run_phase
Like drivers, UVM monitors use an interface clocking block
to avoid race conditions enables reuse
endclass: hello_monitor

proprietary and confidential property of Sutherland HDL, Inc.

12

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

25

UVM Agents

An agent is a reusable and configurable building block

An agent contains a
sequencer, driver, monitor
and coverage collector for a
specific bus protocol (e.g.
USB, AXI, )

class hello_agent
... // register
hello_sequencer
hello_driver
hello_monitor

extends uvm_agent;
this class name in the factory
sqr;
drv;
mon;

Agents are extended from the

uvm_agent base class

The build phase

function void build_phase(uvm_phase phase);
constructs the agents
sqr = hello_sequencer::type_id::create("sqr", this); components using the
drv = hello_driver::type_id::create("drv", this);
factory
mon = hello_monitor::type_id::create("mon", this);
endfunction: build_phase
The connect phase
function void connect_phase(uvm_phase phase);
connects the driver to its
drv.seq_item_port.connect(sqr.seq_item_export);
sequencer (see Section 4
endfunction: connect_phase
for details)
endclass: hello_agent

26

Scoreboards

A UVM scoreboard receives transactions from a monitor

Predicts what DUT outputs should occur based on DUT inputs
1. Receives transactions containing the values driven into the DUT
2. Calculates what the DUT outputs should be for those inputs

Can be done using SystemVerilog, an abstract reference model

(perhaps in SystemC), reading from a file, etc.

Compares the predicted results to the actual DUT outputs

1. Stores the predicted results until the DUT outputs are available
2. Receives transactions containing the values of the DUT outputs
3. Compares the actual outputs to the predicted outputs

Can use the sequence_item compare() method or a more

complex algorithm written in SystemVerilog code

proprietary and confidential property of Sutherland HDL, Inc.

13

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

27

An Example Scoreboard

The scoreboard class takes care of the output verification

class hello_scoreboard extends uvm_scoreboard;

... // register this class name in the factory

hello_predictor
hello_evaluator

predictor;
evaluator;

Handles for the predictor and evaluator

// declare TLM communication ports

uvm_analysis_export #(hello_tx) dut_in_pass_port;
uvm_analysis_export #(hello_tx) dut_out_pass_port;

TLM ports connect the

predictor and evaluator

function void build_phase(uvm_phase phase);

dut_in_pass_port = new("dut_in_pass_port", this);
Construct the ports
dut_out_pass_port = new("dut_out_pass_port", this);
and the predictor /
predictor = alu_predictor::type_id::create("predictor", this);
evaluator blocks
evaluator = alu_evaluator::type_id::create("evaluator", this);
endfunction: build_phase
function void connect_phase(uvm_phase phase);
dut_in_pass_port.connect(predictor.analysis_export);
dut_out_pass_port.connect(evaluator.actual_export);
predictor.expected_port.connect(evaluator.expected_export);
endfunction: connect_phase

Connect up the
predictor and
evaluator

endclass: hello_scoreboard

The code for the predictor and evaluator components are not shown for this example

28

The Environment is the Testbench

The environment encapsulates agents and scoreboards:

An environment can
contain any number
of agents, one for
each bus protocol
(e.g. USB, AXI, )

Environments are extended

class hello_env extends uvm_env;
... // register this class name in the factory from the uvm_env base class
hello_agent agent;
hello_scoreboard scorebd;
function void build_phase(uvm_phase phase);
agent = hello_agent::type_id::create("agent", this);
scorebd = hello_scoreboard::type_id::create("scorebd", this);
endfunction
The UVM factory is used to
... // connect phase connects components
construct UVM components
endclass: hello_env

proprietary and confidential property of Sutherland HDL, Inc.

14

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

29

Tests and Stimulus

The test encapsulates

sequences (stimulus)
and the environment

class hello_test extends uvm_test;

... // register this class name in the factory
function void build_phase(uvm_phase phase);
env = hello_env::type_id::create("env", this);
endfunction

The tests run phase:

1. Creates a sequence
task run_phase(uvm_phase phase);
using the factory
hello_sequence seq;
2. Starts the sequence
phase.raise_objection(this);
3. Objects to the run
seq = hello_sequence::type_id::create("seq", this);
phase completing
seq.start(env.agent.sqr);
until the sequence
phase.drop_objection(this);
has finished
endtask
endclass: hello_test

30

Hooking Everything Up
and Starting UVM

A module connects the interface to the DUT and starts UVM

module top;

Structural
Construction

interface and DUT instances,

logic clk;
connect interface to DUT ports
hello_if io (clk);
hello_dut dut (.clk, .go(io.go), .done(io.done));
initial begin
clock generator (or clock module instance)
clk <= 0;
forever #5ns clk = ~clk;
import the UVM class library
end
import uvm_pkg::*;
import my_components_pkg::*;

Object
Construction

import the testbench classes

store interface instance name

in configuration database
initial
uvm_config_db #(virtual hello_if)::set(null, "*", "vif", io);
initial begin
run_test();
end
endmodule

the run_test() task constructs a test class and

starts the UVM phases (and other UVM magic)
The test class that run_test() creates is specified using an
invocation option (e.g. +UVM_TESTNAME=hello_test )

proprietary and confidential property of Sutherland HDL, Inc.

15

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

1-31

And Thats The Big Picture!

The simple DUT does not use all
the types of UVM components,
but enough to show what a UVM
testbench looks like

Theres just a few miscellaneous topics to discuss...

32

The UVM Methodology

Needs a Methodology!

A UVM testbench can involve several dozen files

For tests, environments, agents, sequencers, sequences, drivers,
transactions, monitors, scoreboards, predictors, configurations,
For VIP source code, documentation, simulation logs, coverage,
A methodology is needed to manage the UVM methodology
Can be a home-grown approach developed within a company
Can use commercial tools

There are commercial tools, such as the Paradigm Works

VerificationWorks that can:
1) Create a complete UVM testbench directory structure
2) Create skeleton classes that have all the boilerplate code filled in
With some tools, the skeleton testbench will run even before
engineers begin filling in design-specific details

proprietary and confidential property of Sutherland HDL, Inc.

16

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

33

Additional Resources

There are many more advanced UVM features, including:

Interrupt driven sequences and UVM callbacks
Virtual sequences and sequencers
The Register Abstraction Layer (RAL)
Using UVM Verification IP
(and much more)

Some great resources for many of these advanced topics include:

Getting Started with UVM: A Beginners Guide, Vanessa Cooper, 2013

The UVM Primer, Ray Salemi, 2013
A Practical Guide to Adopting the Universal Verification Methodology
(UVM), 2nd Edition, Rosenberg and Meade, 2013
Mentors UVM Cookbook (verificationacademy.com/cookbook)
Accelleras UVM World (www.accellera.org/community/uvm)
DVCon and SNUG conference papers

34

Summary:
UVM Pros and Cons

Some advantages of UVM

Testbenches can be highly reusable can ultimately save time
Verification IP is available from a wide variety of sources
EDA companies provide tools specific for UVM coding and debug
Knowledgeable consultants are available
Engineers with prior UVM experience can be recruited
Online forums and other resources are readily available

Some disadvantages of UVM

UVM is massive can be overkill for many verification projects
UVM is complex can have a steep learning curve
UVM is evolving it is not a completely stable standard

UVM 1.1 is good, but UVM 1.2 is not backward compatible and will
likely be changed as the IEEE make it a standard
UVM will let engineers do things wrong limits VIP and reuse

proprietary and confidential property of Sutherland HDL, Inc.

17

may not be reproduced in any form without written permission

Adopting the SystemVerilog Universal Verification Methodology (UVM)

A Seminar for Engineering Managers and Lead Verification Engineers
by Sutherland HDL, Inc., Portland, Oregon, 2016

35

Successfully Adopting UVM

Three things that are important for successfully adopting UVM

1) The best software tools

Tools that organize the many files that make up a UVM testbench
Tools that generate skeleton UVM components

2) Top-notch consultants

An experienced expert on the team is essential for success

A knowledgeable consultant shortens the first UVM project

3) Really good training

UVM uses advanced SV Object Oriented Programming techniques

UVM will let engineers go the wrong direction if not careful
Expert training is an investment with continuous pay back

36

And Thats a Wrap!

Two-line Summary
UVM really works and has major advantages
UVM is very complex with a steep learning curve
Any questions,
comments, or real-life
experiences to share?

Sutherland HDL provides world-wide

on-site and eTutored-live online training
www.sutherland-hdl.com [email protected]

proprietary and confidential property of Sutherland HDL, Inc.

18

may not be reproduced in any form without written permission