INVENTIVE

Universal Verification Methodology

(UVM) Workshop

November 2012 UVM1.1

 2008-2012Cadence Design Systems, Inc. All rights reserved worldwide.

Printed in the United States of America.
Cadence Design Systems, Inc., 2655 Seely Avenue, San Jose, CA 95134, USA
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are
attributed to Cadence with the appropriate symbol. For queries regarding Cadence's trademarks, contact the corporate legal
department at the address shown above or call 800.862.4522.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or registered trademarks
of Open SystemC Initiative, Inc. in the United States and other countries and are used with permission.
All other trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and contains trade secrets and
proprietary information owned by Cadence. Unauthorized reproduction or distribution of this publication, or any portion of it,
may result in civil and criminal penalties. Except as specified in this permission statement, this publication may not be
copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written
permission from Cadence. Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers
permission to print one (1) hard copy of this publication subject to the following conditions:
The publication may be used only in accordance with a written agreement between Cadence and its customer;
The publication may not be modified in any way;
Any authorized copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary
notices and this permission statement;
The information contained in this document cannot be used in the development of like products or software, whether for
internal or external use, and shall not be used for the benefit of any other party, whether or not for consideration
Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of
Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is
supplied subject to, and may be used only by Cadence's customer in accordance with, a written agreement between
Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly
disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in
this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does
Cadence assume any liability for damages or costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and
DFAR252.227-7013 et seq. or its successor.

Setting Your Expectations

Start building knowledge on the Universal Verification

Methodology (UVM)

We will cover many of the basic UVM concepts

You will test some UVM features with simple labs
See how UVM is supported by Cadence verification platform
Understand how Coverage Driven Methodology (CDV) works
with UVM

The workshop will not cover

SystemVerilog language syntax

UVM Workshop Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
Labs

Labs and DUT Introduction

This workshop includes hands-on labs
We follow the process of creating a verification environment for a
simple UART DUT that is part of a larger SoC system
The labs allow further understanding of the lectures and provide a
simple UVM example for hands-on exploration
UART block: Converts parallel
data from the APB bus into serial
CPU
data and vice versa

DMA

Memory

AHB
Parallel
APB bus

Bridge
APB

UART
UART
Serial UART
protocol
5

UART
Serial

APB
Core

USB

Ethernet

UART DUT and Verification Environment

Module Verification
Component

UVM Testbench

Scoreboard

Imitates external
device by
generating frames

Interface & white-box

coverage

Programs the
UART and
transfers traffic

UART DUT (Verilog RTL)

APB
Verification
Component

APB

Tx FIFO

txd

Transmitter

APB
Interface

Mode
Switch
Rx FIFO

Receiver

Control/Status
Registers

UART
Serial

rxd

UART
Verification
Component

Control/Interrupt
Logic

Multi-channel controller

Controls APB and

UART components
Test 1
6

Test 2

Test 3

Tests indicate which

stimulus sequences to
execute

UVM Workshop Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
Labs

What is UVM?
UVM is the Universal Verification Methodology
A methodology and a library that codifies the best practices for
efficient and exhaustive verification.
A complete, proven solution
Proven solution, with a success record and large community of users
with methodology knowledge and commitment
Well-thought-out solution for a wide variety of verification challenges

Open
A key motivation for moving to SystemVerilog
An Accellera standard, supported by Cadence, Mentor and Synopsys

Enables reuse of verification environments

Verification IP can dramatically speed-up delivery and improve quality
A common methodology that also works for other languages
(SystemVerilog, e, SystemC)

2011 Cadence Design Systems, Inc. All rights reserved.

UVM is Production Ready

Cadence Verification Methodology Leadership from the Beginning
2000 eRM

Jan
2006URM
2008 OVM

Feb 2011 UVM

eVC

OVC

UVC

Configuration

DUT I/F

Configuration

DUT I/F

Configuration

DUT I/F

Passive Agent

Active Agent

Passive Agent

Active Agent

Passive Agent

Active Agent

Monitor

Sequence_driver

Monitor

BFM

Coverage

Checks

Architecture
Sequences
Messaging/logging
Reset/clocking
Common test interface
Packaging & code structure

SystemVerilog support
Architecture
Sequences
Factory
Configuration mechanism
Field automation
Message macros
Register pkg (contribution)
Integration of AVM base classes
TLM Communication Channel
Multi-language interoperability

OVM 2.1.1

Added:

2011 Cadence Design Systems, Inc. All rights reserved.

Coverage

Driver

Included:

Module to system reuse

Register package (vr_ad)
HW/SW co-verification

Sequencer
Seqs.

Checks

Added:

Monitor

Seqs.

Seqs.
Checks
Coverage

Sequencer

Driver

Added:
SV callback enhancements
Report catching callback
SV end of test enhancements
Closer to eRM capability
Register support
Enhanced phasing
Partial TLM2 support
Improved configuration and
command line support
Script for o to u migration for
OVM users

UVM and Coverage Driven Verification

Coverage-driven verification(CDV) combines the

following aspects to significantly reduce the time spent
verifying a design:
Automatic stimulus generation
Self-checking testbenches
Coverage metrics

Why CDV?
Eliminate the effort and time to write hundreds of tests
Ensure thorough verification using upfront goal setting

UVM provides the framework to achieve CDV

10

Coverage Driven Verification

Components of a coverage driven verification
environment
Coverage

Automated Stimulus Generation

Independent Checking
Coverage Collection
Scoreboard
Data Checking

Coverage

seed
23098432
38748932
23432239
17821961
10932893
20395483
18902904
23843298
23432432
24324322
55252255
09273822
13814791
4098e092
23432424
24242355
25262622
26452454
24524522

11

Monitor

Monitor

Random
Generation
Tests
Tests

Random
Stimulus
Sequence
Generator
Generator

Driver

DUT
UART

APB

Coverage Driven Verification Flow

Verification
Plan
vPlan

Create a verification plan

Verification
Environment
Verification
Architecture

Adjust and Add

Constraints
and Stimulus
Sequences

Assertions,
Constraints
& Coverage

Simulation,
Acceleration,
Emulation

Refine Coverage
Model
Review Coverage

12

Based on specification requirements

Decide what to test and how

Create smart testbench that:

Generates random legal stimulus
Includes assertions and coverage to
measure progress against the goals
Checks for undesired behavior (BUGS!)

Implement coverage model based on

the verification plan, in place early on
Iteratively run simulations and analyze
coverage
Adjust constraints and add new
scenarios targeting coverage holes
Refine and enhance the coverage
model

Coverage Driven Verification Example

This table represents the attributes we want to verify:
Goals
Functional requirements
Checks
Block-level coverage

Multiple coverage metrics

should be used:

A1 A2 A3 A4
Features

B1 B2 B3 B4
C1 C2 C3 C4
D1 D2 D3 D4

Specification Blocks
Functional coverage
Assertions (Static Formal Verification and Simulation)
Directed tests
Code coverage

For some attributes, multiple metrics are required to

determine coverage
For others, a single metric is sufficient
13

Integrating Coverage Techniques

Initial Coverage Results

Directed Tests: 19%

Assertions: 31%

Functional Coverage: 62%

Code Coverage: 43%

We recommend:
Start with explicit coverage to represent
verification goals: Static and dynamic
assertions and functional coverage

Coverage
full
partial

Balance with implicit, implementation

coverage to ensure thoroughness: code,
FSM and assertion coverage
14

none
Total Coverage: 68%

Coverage Driven Verification - Summary

Combination of automated random test creation and

functional coverage
Coverage is your executable test plan

Advantages:
Saves test writing efforts
Reliable metrics to check your progress throughout the
verification cycle
Ensures efficient verification
Eventually determines completeness

UVM Methodology Implements the CDV Concepts

15

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
Labs

16

The UVM Library

Using inheritance and encapsulation in class libraries
Three layers of elements
TLM

Existing TLM standard for

class communication

Structural Elements
Methodology

Classes common to most

methodologies: components,
messages, simulation
phases, etc.

The main user interface that enables

reuse including classes that capture
the high-level methodology and wrap
the low-level classes
17

UVM Class Hierarchy

(UVM 1.1)
uvm_object

Base class for all UVM

data and hierarchical
components

name
copy(),
clone()

print()

uvm_transaction
uvm_sequence_item
uvm_sequence

uvm_report_object

body()

uvm_report_*()

uvm_port_base #(IF)

uvm_report_handler
uvm_component

uvm_subscriber

uvm_env

uvm_*_export

parent
children
get/set_config_*(), create ()
build_phase(),
connect_phase(),
end_of_elaboration_phase();
start_of_simulation_phase();
run_phase(),

uvm_tlm_fifo
uvm_tlm_analysis_fifo

uvm_test
uvm_driver

uvm_monitor

uvm_agent

uvm_scoreboard
18

uvm_*_port

TLM
uvm_*_imp

uvm_tlm_req_rsp_channel
uvm_tlm_transport_channel

uvm_sequencer

Using the UVM Class Library

Deriving an environment from the class library allows:
Exploiting built-in automation

Sequences standard & powerful test writer interface

Built-in factory for rapid reuse
Transaction manipulation (packing, deep copying etc)
Flexible automatic test phase interface
Messaging utilities

Adhering to a proven methodology

19

Modular topology (monitors, drivers, agents)

Out-of-the box or partial reuse
TLM communication for language independent modularity
A powerful component configuration scheme

Where Do I Get UVM?

Option 1

Option 2

Download the UVM library from

www.uvmworld.org
You will be redirected to
http://www.accellera.org/activities/vip
Included in Incisive Release
Located at: `ncroot`/tools/uvm
Will contain bug fixes not on UVM world
Contains Cadence additions to UVM
Tcl commands
Transaction recording
Register generator
Templates for verification component generation

20

What the release looks like?

uvm/
UVM_Reference.html
uvm_release-notes.txt
uvm/bin/
ovm2uvm.pl
uvm/doc/
uvm/src/
base/
comps/
dpi, reg/
macros/
seq/
tlm1, tlm2/
uvm_pkg.sv
uvm.sv
uvm_macros.svh
21

UVM Reference Manual

UVM Release information
OVM to UVM migration script
User Guide and Reference
UVM source files
low-level library components
methodology layer (agent, env)
register package and reg dpi
macro definitions
sequence-related code
TLM layer components
`include file required for UVM

What the release looks like? (cont.)

Cadence-specific additions (only
found in the IUS version of UVM)
Directories of examples that run on
multiple simulators
Includes: basic_examples, callbacks,
configuration, factory, phases, etc
more complex UVM examples
UVM equivalent of the xbus
To run on IES: irun f compile_ius.f

uvm/sv/cdns_additions
uvm/examples/
simple/

integ/
xbus/
examples/
sv/

codec/
apb/

22

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Modeling Data Items
Reusable Sequences

Building Reusable Verification Components

Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
23

Modeling Data Items

Data items
Represent the main transaction input to the DUT
Adhering to a protocol, consistent values are generated and sent
Examples include packets, transactions, instructions, and so on

Test environment randomizes data items (transactions)

A default distribution should be generated
Tests further steer generation by layering constraints or
selecting from pre-defined scenarios
This makes test short, readable, easier to write and maintain
Test 3
Test 2
Test 1

UVM
Smart Testbench
24

SystemVerilog Data Item: A UART Frame

class uart_frame;
rand int delay;
rand bit start_bit;
rand bit [7:0] payload;
rand bit [1:0] stop_bits;
rand bit [3:0] error_bits;
bit parity;

Fields to be randomized

How will the test-writer

request a bad parity frame?

// utility functions
parity is calculated using a function
extern function bit calc_parity( );
extern function void print( );
extern function bit compare(uart_frame rhs);

endclass: uart_frame

25

Design for Test-writing using Knobs

typedef enum bit {BAD_PARITY, GOOD_PARITY} parity_e;
class uart_frame;
Define
an find
enumeration
make it
Can
you
another to
possible
rand int delay;
easy to describe
parity
type
control
field in the
frame?
rand bit start_bit;
rand bit [7:0] payload;
Can have zero, short, medium
rand bit [1:0] stop_bits;
and long delays
rand bit [3:0] error_bits;
bit parity;
Knobs are control fields that
allow easy user interface
// control fields
rand parity_e parity_type;
// utility functions
extern function bit calc_parity( );

endclass: uart_frame

Test writers can specify the

distribution of GOOD vs. BAD
parity
Extra logic can set the parity based
on the generated parity_type

26

Recommendation: Think of the desired scenarios and make sure you have the
needed control knobs to achieve them

Setting Default Distribution

typedef enum bit {BAD_PARITY, GOOD_PARITY} parity_e;
class uart_frame;
rand int delay;
By default we dont want
rand bit start_bit;
a huge delay
rand bit [7:0] payload;
rand bit [1:0] stop_bits;
Can you think of another
rand bit [3:0] error_bits;
possible default constraint?
bit parity;
// control fields
In typical traffic, most
rand parity_e parity_type;

frames are legal

constraint default_delay { delay >= 0;

delay < 20; }
constraint default_parity_type {parity_type dist {
GOOD_PARITY:=90, BAD_PARITY:=10};}
// utility functions

endclass: uart_frame
27

Layering Constraints for Testing

In a specific test, a user may want to:
Adjust the randomness
Disable existing constraints
Further change the generation using new constraints

This is achieved using class inheritance

Create a new class that inherits from the parent class
frame

class uart_frame;

endclass

short_delay_frame class short_delay_frame extends uart_frame;

// additions here

New class
members
28

endclass

Example: Layering Constraints

You can redefine the default_delay
// original frame declaration code constraint block or change its constraint
mode to zero
class uart_frame;
rand int delay;
// This is a default constraint that could be overriden
constraint default_delay {delay > = 0;
delay < 20;}
endclass: uart_frame

How can you get a

delay of 25?

Use of inheritance

These constraint blocks

will be resolved together

// Test code
class short_delay_frame extends uart_frame;
// This constraint further constrains the delay values
constraint test1_delay {delay < 10;}
endclass: short_delay_frame

What is the legal range in

a short_delay_frame?

29

How Are Data Items Generated?

A Simple Generator
Generator

Produces data
(transactions)
i/f

i/f

Bus Driver
Gets data and
sends to DUT

interface

DUT
30

Randomize in a loop a
transaction or create an
array of transactions to
send one-by-one

class simple_generator;
rand int count;
uart_frame frame;
task gen_and_push();
frame = new();
for (int i=0; i<count; i++) begin
assert(frame.randomize());
driver.send_tx_frame(frame);
end
endtask
endclass: simple_generator

class driver;
virtual interface dut_if if;
task send_tx_frame(input uart_frame frame);
. . . // implements protocol-specific code
if.txd = frame.start_bit; .
endtask
endclass
Gets a frame and drives it

following the timing protocol

Data Item Example

class uart_frame;
rand int delay;
rand bit start_bit;
rand bit [7:0] payload;
bit parity;
rand bit [1:0] stop_bits;
rand bit [3:0] error_bits;

User defined function

// Utility functions
extern function bit calc_parity( );
extern function void print();
extern function bit compare(uart_frame rhs);

endclass: uart_frame

31

Required for most

transactions!

Where SV Language Stops and UVM Begins

Example: Data Items
class uart_frame;
bitrand bit
start_bit;
start_bit;
bitrand
[7:0]bit
payload;
[7:0] payload;
bitrand bit
parity; parity;
parity_e
rand parity_e
parity_type;
parity_type;
intrand inttransmit_delay;
delay;
endclass: uart_frame

Does language alone support all the necessary customization operations?

Randomization
Printing

No! Only randomization is defined

in the SystemVerilog LRM

Cloning
Comparing
Copying
Packing
Transaction Recording
32

UVM provides the rest!

Enabling Data Item Automation

class uart_frame extends uvm_sequence_item;
rand bit
start_bit;
UVM data items are derived
rand bit [7:0] payload;
from uvm_sequence_item
bit
parity;
rand parity_e parity_type;
Enables all automation for
rand int
delay;

uart_frame fields

// *optional* field declarations and automation flags

`uvm_object_utils_begin(uart_frame)
`uvm_field_int( start_bit, UVM_ALL_ON)
`uvm_field_int( payload, UVM_ALL_ON)
`uvm_field_int( parity, UVM_ALL_ON)
`uvm_field_enum( parity_e, parity_type, UVM_ALL_ON + UVM_NOCOMPARE)
`uvm_field_int( delay, UVM_ALL_ON + UVM_DEC + UVM_NOCOMPARE)
`uvm_object_utils_end
endclass: uart_frame
Specify field level flags:
33

UVM_NOCOMPARE,
UVM_NOPRINT, etc.

UVM Macros: `uvm_object_utils and `uvm_field_*

UVM provides macros to reduce
coding and enable automation of
common verification functions

`uvm_object_utils_begin (name)
`uvm_field_int (name, FLAGS)
`uvm_field_enum(etype, name, FLAGS)
`uvm_field_array_int (name, FLAGS)
`uvm_object_utils_end

The `uvm_object_utils macro implements a set of utility functions

for UVM objects.
get_type_name() and create() methods are implemented
The object is also configured for built-in automation
print(), compare(), copy(), clone(), pack(), unpack(), etc

`uvm_field_* macros specify the automation requirements for each

field of the data item
Flags indicate whether the field is to be included in printing, copying, etc
UVM_ALL_ON enables everything

Note: These macros are optional but highly recommended!

34

Example: Data Type Automation

uart_frame frame1, frame2;

initial
begin
frame1 = new(my_frame);
assert(frame1.randomize());
frame1.print();
$cast(frame2, frame1.clone());
frame2.set_name(my_frame2)
frame2.print(tree_printer);
end

--------------------------------------Name
Type
Size
Value
--------------------------------------my_frame
uart_frame @607
start_bit
integral
1
h1
payload
integral
8
hfc
parity
integral
1
h0
parity_type parity_e
32 BAD_PARITY
delay integral
32 d382
---------------------------------------

Create a new uart_frame

and copy frame1 to frame2
my_frame2: (uart_frame@788) {
start_bit: h1
payload: hfc
parity: h0
parity_type: BAD_PARITY
delay: d382

Three built-in printers

can be used
}
35

Transaction Recording in IES

// inside driver or monitor code
uart_frame frame1;
int handle;
...
handle = begin_tr(frame1); // start recording
// body including timing
end_tr(frame1));
// end recording

SimVision: Automatic
transaction recording.
36

Automatic recording methods built into UVM items

Flag Argument Definitions Table (partial list)

37

FLAG

DESCRIPTION

DEFAULT

UVM_ALL_ON /
UVM_DEFAULT

Turns on the COPY, COMPARE, PRINT, RECORD,

CLONE, PACK , UNPACK and DEEP flags

UVM_DEFAULT

UVM_COPY /
UVM_NOCOPY

setting COPY includes the field in copy(), clone()

operations. NOCOPY excludes the field

UVM_COPY

UVM_COMPARE/
UVM_NOCOMPARE

setting COMPARE includes the field in compare

operations. NOCOMPARE excludes the field

UVM_COMPARE

UVM_PRINT /
UVM_NOPRINT

PRINT includes the field in print(), sprint() operations

UVM_PRINT

UVM_PACK/
UVM_NOPACK

PACK includes the field in pack and unpack operations

UVM_PACK

UVM_PHYSICAL /
UVM_ABSTRACT

Treat as a PHYSICAL fields.

Treat as an abstract field.

UVM_READONLY

Do not allow setting of this field from the set_*_local

methods.

Radix
(for printing)
ADD UVM_ to each
radix listed

Provide a specific radix to use when printing integral

fields (or arrays of integral fields). Available radix
values are: BIN, DEC, UNSIGNED, OCT, HEX,
STRING, TIME

UVM_HEX

Messages for Debug & Error Reporting

Messages

While developing or using environments, users need to print messages

$display does not allow non-intrusive filtering and control
User may want to get trace messages from a suspect component
Critical to large environment with many verification components

Error reporting
The testbench must produce clear and descriptive error messages to
communicate a checker mismatch
Should affect simulation based on severity

Error stop
Warning record and proceed
Allow customization of above

38

Message Requirements

Simplicity of
Writing messages
Turning messages on and off

Uniformity of
Output format
Turning on and off

User control over formatting of output

39

UVM Messaging Facility

Messages print trace information with advantages over $display:

Aware of its hierarchy/scope in testbench

Allows filtering based on hierarchy, verbosity, and time
uvm_report_info("PKT", "Packet Sent");

Output

id

time

message body

UVM_INFO @10 uvm_test_top.test.generator [PKT]: Packet Sent

severity

scope

Simple Messaging:
uvm_report_*(string id, string message);

Where * (severity) is one of fatal, error, warning, info

Tips:
Use get_type_name() to give an id of the class type
Use $sformatf() to create message string using $display syntax
40

Messages and Verbosity

uvm_report_info(get_type_name(), $sformatf("addr %h",addr), UVM_LOW);

Additional argument to uvm_report* defines verbosity

UVM_NONE, UVM_LOW, UVM_MEDIUM, UVM_HIGH, UVM_FULL

By changing the verbosity maximum, messages can be filtered

For example, if the verbosity is set to UVM_LOW, all messages coded with
UVM_MEDIUM and higher will not print

Ways to change verbosity without recompiling!

1. Command-line:

% irun . +UVM_VERBOSITY=UVM_NONE

2. Procedural (test): set_report_verbosity_level_hier(UVM_MEDIUM);

41

Enhancing the Messaging Methods

The uvm_report* built-in methods raise a few issues:

The string manipulations are executed whether the
message is printed or not.
String manipulation is costly and gets worse when data items
are large or complex.

A single mechanism is used to control trace messages

and error messages: (+UVM_VERBOSITY)
Errors and warnings are also sensitive to verbosity.
The default verbosity for warnings is MEDIUM and for fatal/error
is LOW.
When UVM_NONE verbosity setting is specified on the
command line, errors and warnings will not be printed (or
executed).
42

Enhancing the Messaging Methods

We suggest using macros to address these issues:
Allows checking the verbosity before string manipulation
Enables printing line number and file name
Hard-codes errors to use severity UVM_NONE

Macros are the ONLY reasonable way to address the

first two items
Syntax
`uvm_info(string id, string message, int verbosity)
`uvm_warning(string id, string message)
`uvm_error(string id, string message
`uvm_fatal(string id, string message)

Note: warning/error/fatal have hard-coded verbosity of

UVM_NONE
43

Using the UVM Library with Incisive Simulators

irun allows users to run the simulator by specifying all input files and
command-line options on a single command line.
Each file is compiled using the appropriate compiler based on the file
extension used.
Verilog, SystemVerilog, VHDL, e, C and C++
Command-line options are also recognized and passed to the compiler,
the elaborator and the simulator
% irun -access +r -gui test.sv verify.e top.v sub.vhd

irun supports UVM-specific options:

-uvm
-uvmhome $UVM_HOME
+UVM_TESTNAME
+UVM_VERBOSITY
44

Searches <install_dir>/tools/uvm/src and

sets command-line options to compile the lib
Optionally specifies a different directory for
the UVM installation
Passes the default test name for run_test()
Sets the verbosity level for UVM messages

Its Lab Time! Lab 1

Data Item Modeling:

UART serial data
interface frames

Objectives:
Transaction generation
and constraint layering
UVM automation
Use UVM message
facility

UVM
Testbench

Scoreboard
coverage

APB
UVC

UART
DUT

Multi-channel
controller

Labs 1-3 focus on the

UART UVM Verification
Component
45

UART
UVC

Lab1: Data Item Modeling Discussion

What did we do?

Generated constrained-random UART frames in a loop
Explored the UVM built-in automation and messaging
Altered the distribution of generated items using constraint
layering

Questions
What advantages do you see in using `uvm_info() over $display?
When we introduced a test1_frame, we had to modify the
frame_generator to create test1_frames
Can you think of a scenario in which this would be problematic?
Can you send a stream of transactions with incrementing
payload values using constraint layering?

46

Constraint Layering Using the Factory

In lab 1 you had to modify the generator in order to use
the test1_frame derived class
This is problematic for large SOC designs because you will have
to modify many files

UVM includes a mechanism (called a factory) for

allowing users to override the default behavior
The factory is automatically built into the library
Powerful tool for test-writing & reuse

Lets revisit the previous lab example to understand how

the factory works
47

Constraint Layering Using the Factory

typedef enum {SHORT, MEDIUM, LONG} delay_t;
// extended class uses control knob for delay
class delay_frame extends uart_frame;
Add control knob to
rand delay_t delay_knob;
constrain delay
constraint delay_type_c {
delay > 0;
delay_knob == SHORT -> delay < 10;
delay_knob == MEDIUM -> delay < 40
delay_knob == LONG -> delay > 100; }
`uvm_object_utils_begin(delay_frame)
`uvm_field_enum(delay_t, delay_knob, UVM_ALL_ON|UVM_NOCOMPARE)
`uvm_object_utils_end

48

function new (string name=delay_frame);

endclass: delay_frame

Registers delay_frame with

the factory

// In the generator class:

uart_frame frame; // data item declaration
...
frame
frame == uart_frame::type_id::create(frame));
new(frame); // create a new data item

Replace frame=new();
with create ()

What is the UVM Factory?

type and instance override list

Central location to create

class instances on demand
Each type is registered with the
factory
Instances created via factory
call
Not via class constructor

delay_frame

Apply override instructions to factory

Make all uart_frame

instances delay_frame
instead

to

uart_frame
...

delay_frame
...

Factory

Class Hierarchy
uart_frame

Create uart_frame
Factory allocates instance
of required type

from

+create

registered types
uart_frame
delay_frame

delay_frame
+create

Register type with factory

Factory Overrides
Type override replaces ALL instances: For a specific test, replace all uart_frame
packets with delay_frame packets

A uart_frame

drv_c

B delay_frame

drv1_c

set_type_override_by_type(uart_frame::get_type(),
env1
delay_frame::get_type());

Instance override replaces specific

instances:
Replace uart_frame in agent[0] sequencer
Replace agent[1] driver drv_c with
dvr1_c
set_inst_override_by_type("env1.agent[0].seqr",
uart_frame::get_type(),delay_frame::get_type());

agent[0]

agent[1]

seqr
A
B

seqr
A
B

driver monitor
A
B
A
B

driver monitor
B
A
A
B

env1
agent[0]

agent[1]

seqr
A
B

seqr
A

set_inst_override_by_type("env1.agent[1]",
drv_c::get_type(), drv1_c::get_type());

driver monitor
A
A

driver monitor
A
A
A

Using Factory for Object

Substitution from Test

uart_frame
new_frame

Replace ALL instances

Syntax:
object::type_id::set_type_override(derived_obj::get_type())

Example:
uart_frame::type_id::set_type_override
(delay_frame::get_type());

Replace specific instances

Syntax:
object::type_id::set_inst_override
(derived_obj::get_type(), hierarchical path);

Example:
uart_frame::type_id::set_inst_override
(delay_frame::get_type(), A.B);
51

Using Factory for test1_frame from Lab1

class test1_frame extends uart_frame;
macro registers the
constraint default payload { payload <= 8h3f; }
object with the factory
`uvm_object_utils(test1_frame)
function new(string name=test1_frame);
super.new(name);
class frame_generator;
endfunction : new
uart_frame frame;
endclass : test1_frame

task gen_and_push();
// replace frame = new(); with the following:
module lab1_top;
frame = uart_frame::type_id::create(frame);

frame_generator generator;
endclass : frame_generator

initial begin
uart_frame::type_id::set_type_override (test1_frame::get_type());
generator = new();

endmodule : lab1_top
52

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Modeling Data Items
Reusable Sequences

Building Reusable Verification Components

Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
53

Reminder: Simple, Non-UVM Generator

Generator

Produces data
i/f

i/f

Bus Driver
Consumes and
send to DUT

54

class generator;
Randomize in a loop a
rand int count;
transaction or create an
uart_frame frame;
array of transactions
virtual task gen_and_push();
for (int i=0; i<count; i++) begin
frame = new();
assert(frame.randomize());
// send frame to bus driver interface
end
endtask
endclass: generator
Issues with generators:
Limited control
Not easy to define ordered transactions
Can not define timing without code override
Unable to react to the state of the DUT
Generator is not reusable at system-level
Does not support multi-channel control

Many critical randomization concepts are up to

the environment builder to implement

Key Randomization Concepts

Everything should be random within spec (infinity minus)
Reactive generation and pre-run generation
Standard solution for various scenarios
Interrupt modeling, looking at previously generated data, protocol
layering, modeling timing

Maximum flexibility for test creation

You can never predict all test requirements

Stimulus is reproducible with small changes in the design

Random Stability

System-level scenarios and control

Some scenarios will be reused at the system level

Ideal methodology should address the requirements

above out-of-the-box, even for non-expert users!

55

Scenario Creation Requirements

Achieving full coverage using constraint layering is highly

recommended
The technology evenly selects items from legal ranges
Efficient in capturing unanticipated bugs

Many times, single items cannot capture high-level intention

Ordered streams of transactions are required
Examples: configuration of a device, program generation

A sequence is a set of transactions that accomplish a defined

task
Sequences are provided as part of a reusable component
Capture important scenarios that should be exercised

UVM provides an advanced sequence generation mechanism

56

UVM Sequencer an Advanced Generator

Sequencer
Generator

Produces data
i/f

UVM sequencer
By default works exactly like a generator
Generates random transactions on request
We replace the generator
Addresses all randomization requirements:
with a sequencer
random by-default, reactive generation,
system-level ready, modeling timing, etc

sequences
i/f

Bus Driver
Consumes and
send to DUT

User-defined sequences of transactions are

created and executed
For example, a user creates a sequence that
interleaves legal and illegal frames

Test writer sets the sequencer to execute a

specific sequence
Provides built-in random stability
Random sequence immune to changes in other
parts of TB/design

57

Sequences Example: UART Retry Sequence

// Send one BAD_PARITY frame followed by a GOOD_PARITY
extend from uvm_sequence
// frame with the same payload
class retry_seq extends uvm_sequence #(uart_frame);
// uart_frame req; // built-in data item field
Data item
`uvm_object_utils(retry_seq)
Registers the retry_seq with
the factory
rand bit [7:0] pload; // randomizable sequence parameter
...
virtual task body ( ); // sequence behavior
`uvm_do_with(req, {payload == pload; parity == BAD_PARITY;} )
`uvm_do_with(req, {payload == pload; parity==GOOD_PARITY;} )
endtask : body
body() can also include time consuming
endclass
statements, forkjoin, function calls, etc
58

The uvm_do Operation

virtual task body (); // sequence behavior

`uvm_do_with(req, {payload == pload; parity == BAD_PARITY;} )
endtask
Reactive generation

Translates into:

Combines procedural and

declarative (constraint layering)
directives
Factory support out-of-the-box

Wait till item is requested

Create items using a factory
Randomize (with constraints or not)
Return the item to the requester
Block code execution till item_done()

Inline constraints for

additional control

Allows modeling timing

built-in TLM to allow reuse
e.g. scenario that calls for
and support multi-language
a frame, wait for FIFO full
communication
New and expert users deploy all key randomization
concepts!
and do illegal frame
59

Sequences Example: Manual Approach

...
virtual task body ( ); // sequence behavior
//`uvm_do_with(req, {payload == pload; parity == BAD_PARITY;} )
req = uart_frame::type_id::create(req);
start_item(req);
if (!req.randomize() with
{payload == pload; parity == BAD_PARITY;} ) begin
`uvm_fatal(get_type_name(), "Randomization failed")
end
finish_item(req);

endtask : body
endclass
60

Nesting Sequences
// call retry sequence wrapped with random frames
class rand_retry_seq extends uvm_sequence #(uart_frame);
`uvm_object_utils(rand_retry_seq)
retry_seq retry_sequence;

Using a previously
defined sequence

virtual task body (); // executable sequence behavior

`uvm_do (req)
`uvm_do_with(retry_sequence , {pload inside {[0:31]};})
`uvm_do(req)
Create and randomize a
endtask
retry_seq sequence and
endclass
call its body

61

Sequence Execution
Sequencer
// Sequence: rand_retry_seq
class rand_retry_seq extends
//uart_frame req; //built into seq
retry_seq retry;
virtual task body ();
`uvm_do(req)
`uvm_do_with(retry, {pload
inside {[0:31]};))
`uvm_do(req)
endtask
endclass

// Sequence: retry_seq
class retry_seq extends uvm_sequence #();
// uart_frame req; // built into base seq
rand bit[7:0] pload;
virtual task body ();
`uvm_do_with(req, {payload ==pload;
parity==BAD_PARITY;})
`uvm_do_with(req,{payload==pload;
parity==GOOD_PARITY;})
endtask
endclass

get_next_item()
get_next_item()
item_done()

Driver
62

Controlling Sequencer Behavior

How do we control which sequences run on a UVC
sequencer and when?
1. run_phase() (and every run sub-phase) has a default_sequence
property.

Set default_sequence to a sequence to execute in that

phase.
// Test: Set uart_tx_sequencer to use retry_seq as the default sequence
uvm_config_db#(uvm_config_wrapper)::set(this,"uart_tx_sequencer.run_phase
", "default_sequence",
retry_seq::type_id::get());

63

2.

Execute a sequence directly on a UVC sequencer from a test class, by

calling the sequences start method

3.

Group sequences into a sequence library; Set default_sequence to

execute the sequence library

Notes: 2 & 3 will be covered in UVM Training class

The UVM Driver

Pulls transactions from the sequencer and drives the DUT interface
Sequencer

// uart_frame req; // built-in field

Produces data

`uvm_component_utils(uart_tx_driver)

i/f

virtual task get_and_drive();

forever begin
seq_item_port.get_next_item(req);
send_tx_frame(req);
seq_item_port.item_done ();
end
endtask

i/f

Driver
Consumes and
send to DUT

64

class uart_tx_driver extends uvm_driver #(uart_frame);

Derived from
uvm_driver

Main control loop

Interface to the
sequencer via TLM

virtual task send_tx_frame(input uart_frame cur_tx_frame);

...
endtask
endclass
Drive interface signals
following the protocol

Summary - UVM Sequences

Easy to use; no need to learn complex mechanism

Combines declarative and procedural constraints
Can be generated on-the-fly or at time zero
Can nest sequences
Can use events or time to delay transactions
Ability to create a system-level sequence
Control multiple interfaces from a single consistent sequences
E.g. Configure the registers via the bus, then start external
stimuli

Provide built-in random stability

Sequences are at the heart of testbench automation and reuse!
65

Other Sequence Applications

Sequences are a standard mechanism to create, control

and drive complex hierarchical inputs into the DUT
Provide proven solution for block and system level
solutions

66

Multi-channel sequences
Pre-run sequences (zero-time-generation)
Reactive sequences
Interrupt sequences
Protocol layering
And more

SimVision - Advanced UVM Analysis and Debug

UVM-aware dynamic object

debug
Debug testbench configuration
and hierarchy
Set breakpoints
Step in, step through classes

Flexible TCL to manipulate

testbench at run-time

UVM transaction analysis

UVM transaction recording
Stripe chart

Debug constraint conflicts

Identify over-constrained
issues
Interactively reduce constraints
and randomize on the fly

67

Design Browser

Icon for UVM data

members Click on icon
will route to Design
Browser

68

Methods Tab

Methods Tab of the

displayed UVM
Component

69

Interactive Sequence Debug

Callstack Viewing
When stopping a breakpoint, you can use the callstack
sidebar to see where your method was called from and
to traverse the callstack.

70

Transaction Visualization - Sequences

class concurrent_u2a_a2u_rand_trans_vseq extends uvm_sequence;

// APB sequences
program_dut_csr_seq config_dut;
apb_to_uart_wr raw_seq;
// UART sequences
uart_transmit_seq uart_seq;
intrpt_seq rd_rx_fifo;
virtual task body();

endtask
endclass

class do_something_seq extends uvm_sequence;

concurrent_u2a_a2u_rand_trans_vseq my_vseq;

`uvm_sequence_utils(do_something_seq,apb_uart_virtual_sequencer )
task body();
uvm_report_info("do_something_seq","Doing Nothing First", UVM_NONE);
#2000
uvm_report_info("do_something_seq",
"Doing concurrent_u2a_a2u_rand_trans sequence NOW", UVM_NONE);
`uvm_do(my_vseq);
endtask
endclass

71

Transaction Stripe Chart (TSC)

72

Constraint Debugger

73

When there is a constraint solver failure, a new

constraint debugger window is created for
showing random variables and constraints
associated with the class instance.

Constraint Debug

At the top of the window is a toolbar which has

buttons that allow the user to create or delete a
new constraint.

This portion
lists the
variables and
their values. All
variables are
listed in the
object since
state variables
can be used in a
constraint.

Source view region will show the selected rand

variables and constraints in context.
74

This portion lists

the constraints for
the object. This
displays the
constraint name
and the first line of
the constraint
from the source
file.

Constraint Debug Dynamic Analysis

Show All constraints

Click to add new constraints

Click to disable constraint

Do a run rand_solve for this
instance
With refined
constraints,
constraint
solver success
now.

75

Its Lab Time! Lab 2

UVM
Testbench

coverage

UVM Sequences:
Objectives:
Explore the driver and
sequencer interaction
Review the sequencer
default behavior
Execute a specific
sequence
Write a new sequence

APB
UVC

UART
DUT

UART
UVC

Multi-channel
controller

uart_tx
sequencer
sequence
seq_item_export

seq_item_port

uart_tx
driver

76

Scoreboard

Sequencer:
Creates and executes sequences of
transactions
Sends UART frames to the Driver
Sequence :
Creates randomized UART frames
Driver :
Gets UART frames from the Sequencer
Converts to signal-level details ( it just
prints the frame in this lab)
Indicates its ready for another frame

Recap: Sequence Sequencer Driver DUT

Interaction
Sequencer:
2. Executes the default_sequence
- Creates, randomizes, and calls the sequence
body() task

4. Sends frame to the driver via TLM port

5. Waits for item_done() from driver
before generating next frame
Sequence:
3. Generates a sequence item (aka data
items, transactions, etc)
Driver:
1. Requests a frame from the sequencer
6. Gets a frame via TLM port
7. Sends frame to the DUT via SV
interface
8. Indicates item_done() to sequencer

77

sequences

sequencer
Default_sequence

seq_item_export

uart frames
seq_item_port

driver
virtual i/f

uart signals
interface

UART DUT

simple_tx_seq
transmit_seq
repeat_seq
incr_payload
bad_parity

sequence_items
BAD_PARITY
GOOD_PARITY

uart_frames

Lab2: Creating Sequences Discussion

What did we do:

Explore the driver and sequencer interaction

Review the sequencer default behavior
Execute a specific sequence
Write a new sequence

Questions
What benefits do sequences provide?
What is the sequence body() task?
How to control a sequencer execution?

How can Sequences enable reuse?

78

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Concepts for reuse
Reusable environment topology

Testbench Creation Using Reusable Components

Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
79

Reusable Environments

CDV and UVM shorten the verification process

Avoid the need to create hundreds of tests
UVM provides base classes and automation to quickly build the
testbench environment
Allows fine control over the created scenarios

One of the core values of the UVM methodology is the

ability to reuse these components
As you move from block to system-level (vertical reuse)
From one project to the next (horizontal reuse)

80

Creating a Reusable Verification Environment

UVM Testbench

BUS UVC
Mon
Mon

Module VC

Apply stimulus on each external interface

Coordinate stimulus across multiple ports for
system-level scenarios
Emulate the CPU by reading and writing device
registers

BFM
BFM

SEQR

Scoreboard
Mon

coverage

DRV

VC3

Project1 DUT
Multi Channel Sequence Generator

CPU

Periph

Mon
Mon
Mon

BFM
BFM
DRV

SEQR

Protocol1
VC3 UVC
81

Mem

Periph

Mon
Mon
Mon

BFM
BFM
DRV

SEQR

VC3 UVC
Protocol2

Tasks to be done:

Issues:
How do we model complex environments?
Generation? Checking? Coverage?
How do we facilitate reuse?

Solution: divide and conquer

Create a reusable verification component per
interface
Following the protocol, each component:
Stimulates the interface
Checks for protocol correctness
Collects coverage
Add a mechanism for multi-channel traffic
generation
Create end-to-end checker and coverage
collector

Packaging UVM Components for Reuse

UVM methodology combines all components
for a single interface into a reusable package

Coverage

Scoreboard
Data Checking

Coverage

Monitor

Monitor

seed
23098432
38748932
23432239
17821961
10932893
20395483
18902904
23843298
23432432
24324322
55252255
09273822

82

Tests
Tests

Sequencer

Driver

Packaged for reuse

DUT
UART

APB

Reuse at the System Level

Configure APB UVC as passive:
Monitor still collects coverage

Coverage

New blocks are added as they are developed

Reuse of scoreboard for checking

Scoreboard
Checking
Coverage

Passive

Coverage

Monitor

Random
AHB
to APB
Tests
Tests

Sequence
Bridge
Generator

Driver

Reusable Component
83

Monitor

DUT
APB

UART

Reusable Environments: Main Players

Contributors have different skill sets and responsibilities

Who are they?
Reusable component developers
Experts in protocol knowledge and verification
Environment integrators
Build test environments using reusable components
Less protocol knowledge, more target system knowledge
Test-writers
May have little verification expertise

UVM allows each contributor to focus on his responsibilities and be

productive quickly
Note: At times the same person is doing two or all the roles above

84

Facilitating Reuse
Testbench

Mon
BFM
Mon
BFM
Mon DRV

SEQR

VC3
VC2
Multi Channel Sequence Generator

Project2 DUT
Periph

Create a components repository

Reuse existing components for next project
Can use various languages based on needs
and preferences

New components are added as needed

Over time, components repository grows
and matures
Proven on multiple projects
Becomes a major company strength!

Periph

VC Repository
Mon
BFM
Mon
BFM
Mon DRV

Module VC

Mon
BFM
Mon
BFM
Mon DRV

Scoreboard

Mon
BFM
Mon
BFM
Mon DRV

BUS
VC
Mon
BFM
Mon

BFM

SEQR
SEQR

SEQR

SEQR
Mon DRV

SEQR

coverage

VC3
85

Mon
BFM
Mon
BFM
Mon BFM

VC3

VC3
eVC

VC3
VC2

VC3

Component RepositorySounds Trivial?

Verification methodologies have existed for many years

Many components have been created
Limited success on sharing components between teams and
across companies

Proven UVM concepts have delivered success!

Well-defined, easy-to-learn architecture

Verification component encapsulation at the interface level
Configuration scheme for reuse
Capable scenario generation for multiple protocols and
unanticipated needs

Lets see how to do it right!

86

Coverage and Checking

Sequencer

Produces data
i/f

From where should we collect

coverage?
Neither the sequencer nor the driver
are the ideal option
What if we want to monitor an interface
that we do not drive?

i/f

Driver
Consumes and
send to DUT

87

For this we need a third component

called a Monitor

The Monitor

Monitor
A passive component that collects information on a monitored
interface
Builds abstract transactions
Contains events, status, checkers and coverage

Protocol specific
Passive entity

Monitor

Never drives signals!

Monitor is independent of the driver!

May need to monitor information driven
by the testbench

88

Checking and
coverage

The UVM Monitor Coverage Implementation

class uart_monitor extends uvm_monitor;
`uvm_component_utils(uart_monitor)
uart_frame frame; // data item to be collected

Derived from uvm_monitor

and registered with the
factory

covergroup uart_trans_frame_cg;
NUM_STOP_BITS : coverpoint frame.nbstop {
bins ONE = {0};
Implement coverage
bins TWO = {1};
model based on your
}
verification plan
DATA_LENGTH : coverpoint frame.char_length { }
PARITY_MODE : coverpoint frame.parity_mode { }
endgroup
function new (string name = "", uvm_component parent = null);
super.new(name, parent);
new() covergroup in the constructor
uart_trans_frame_cg = new();
endfunction: new
Task to collect data items
task collect_frame ( );
// Collect uart data from interface
from the DUT interface
uart_trans_frame_cg.sample();
endtask: collect_frame
Sample coverage when
endclass: uart_monitor
frame is collected
89

Creating Assertion/Formal-Ready Interface

Components
Assertions are useful for dynamic simulation
Can identify overlooked issues
DUT and reference model can be wrong
May capture performance concerns
Can significantly reduce debug time vs. end-to-end checkers

Can be leveraged in formal verification

Another efficient, complementary path to discover bugs
Can be exploited before a dynamic environment exists

Interface UVCs are protocol specific

Ideal place to capture protocol assertions inside

UVM introduces a unified flow for dynamic and formal

verification
90

UVM Assertions Methodology

The methodology was designed to:
Combine upfront planning and
assertions development into your
flow
Instantiate and control assertions
Reuse assertions
Between projects
Across teams (designers,
verification engineers, etc)
Using multiple technologies
Measure thoroughness using
assertions

Env
(UVC)

Immediate assertion
Agent
checks in the monitor
Agent
Agent
Config:
active_passive

91

sequences
tlm i/f

tlm i/f

Monitor

tlm i/f

Coverage
Checking

Driver

vif

vif

Concurrent assertions
reside in the SV interface
Ask us for information or T=training
on UVM and Assertions

Sequencer

I/F

DUT

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Concepts for reuse
Reusable environment topology

Testbench Creation Using Reusable Components

Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
92

How to Facilitate Reuse?

Reuse of low-level components
Integrator places drivers, sequencers and monitors
within his project testbench environment
Integrator needs to learn:
Class names and their roles
How these components communicate with each other
How to configure components separately or create and
communicate with a central configuration facility
How to set the right signals or learn to use a central signal map

Lots of manual work and understanding is required

No single consistent guidelines
Different per reusable component

93

Consider This: Your Next Verification

Challenge!
Trace Port
Analyser

SDRAM
Bank 0

SDRAM
Bank 2

SDRAM
Bank 1

SDRAM
Bank 3

SRAM

ROM

Flash

LCD Display

PC Cards

ETM

MOVE

Static
Memory
Interface

SDRAM
Controller

ARM926
CPU

Vectored
Interrupt
Control

Color
LCD

DMA
M

PCMCIA
Host

ARM I AHB
ARM D AHB
LCD AHB

SRAM
Buffer

DMA 1 AHB (Periph)

DMA 2 AHB (Memory)
EXPANSION AHB

DMA APB

Core APB
WATCHDOG

AHB/
APB

TIMERS

AHB/
APB

MPEG-4
Engine

Colour
Convert

SSP
Camera
Interface
Camera

GPIO (x4)
GPIO
x4

SYSTEM
CONTROL

RTC

Clk/Reset
Generator
32 GPIO
lines

32KHz
CLK
Xtal Osc

UART

SIM Card

USB
Interface
Transceiver

PLL
Xtal Osc

USB Connection
to PC

94

Scalability is a must! Class level

reuse is not enough!

Camera
Control

Our new
system
specs are
in the mail

The Solution: Agents

uvm_agent
uvm_
sequencer

Config:

sequences
seq_item_export

uvm_monitor
events,
status,
data

Integrator does not need to worry about

this

A standard agent has:

seq_item_port

uvm_driver

vif

vif

interface

DUT
95

Agents provide all the verification logic

for a device in the system
Instantiation and connection logic is
done by the developer in a standard
manner

Sequencer for generating traffic

Driver to drive the DUT
Monitor

Note: that the monitor is independent of

the driving logic to allow a passive
operation mode
Agent has standard configuration
parameters for the integrator to use

Agent Standard Configuration

A standard agent is configured using
an enumeration field: is_active

uvm_agent
uvm_
sequencer

Config:

is_active:
UVM_PASSIVE
UVM_ACTIVE

min_addr:
16h0100

sequences
seq_item_export

UVM_ACTIVE:
Actively drive an interface or device
Driver, Sequencer and Monitor are
allocated

passive
uvm_monitor
events,
status,
data

seq_item_port

uvm_driver

vi

vi

interface

DUT
96

UVM_PASSIVE:
Only the Monitor is allocated
Still able to do checking and collect
coverage

Other user-defined configuration

parameters can also be added
Example: address configuration for
slave devices

Creating the Agent

Derived from uvm_agent

Configuration field
class master_agent extends uvm_agent;
uvm_active_passive_enum is_active = UVM_ACTIVE;
UVM field declaration for
library automation
`uvm_component_utils_begin(master_agent)
`uvm_field_enum(uvm_active_passive_enum, is_active, UVM_ALL_ON)
`uvm_component_utils_end
// agent sub component instances
Using the constructor to allocate the
master_driver
driver;
sub-instances is problematic
master_sequencer sequencer;
because new() is not polymorphic
master_monitor
monitor;
function new( input string name, input uvm_component parent);
agent
super.new( name, parent);
sequencer
// create the sequencer, driver and monitor
Config:
Is_active
sequences
monitor = new (monitor,this);
if (is_active == UVM_ACTIVE) begin
driver = new(driver,this);
monitor
events,
sequencer = new(sequencer, this);
status,
driver
end
data
Allocation using new() forces a
vi
vi
endfunction
re-write when modifications are
endclass
required
97

Creating the Agent Using build_phase() Method

class master_agent extends uvm_agent;
active_passive_enum is_active = UVM_ACTIVE;
`uvm_component_utils_begin(master_agent)
`uvm_field_enum(active_passive_enum, is_active, ALL_ON)
`uvm_component_utils_end
// agent sub component instances
master_driver
driver;
Constructor is still required
master_sequencer sequencer;
master_monitor
monitor;
function new(input string name, input uvm_component parent);
super.new(name, parent);
Use the build_phase() method to
allocate components and address
endfunction
virtual function void build_phase(uvm_phase phase); the polymorphism requirement
// Allocate sequencer, driver and monitor here
endfunction
virtual function void connect_phase(uvm_phase phase);
// Make TLM connections here
Use the connect_phase() method
endfunction
to make TLM connections between
the sub-components
endclass
98

The Agent build_phase() and connect_phase()

99

class master_agent extends uvm_agent;

class v2_mdriver extends master_driver;
...
// add attributes + override virtual methods
// agent sub component instances
endclass
master_driver
driver;
// syntax for introducing the new driver in test
master_sequencer sequencer;
master_driver::type_id::set_type_override (
master_monitor
monitor;
v2_mdriver::get_type());
...
virtual function void build_phase(uvm_phase phase);
Use the factory to override
super.build_phase(uvm_phase phase);
the driver for a specific test
// create sequencer, driver and monitor Call super.build_phase()
monitor = master_monitor::type_id::create( monitor, this);
if (is_active == UVM_ACTIVE) begin
driver = master_driver::type_id:: create(driver, this);
sequencer = master_sequencer::type_id::create(sequencer, this);
end
Use create() for factory
allocation
endfunction
virtual function void connect_phase(uvm_phase phase);
driver.seq_item_port.connect(sequencer.seq_item_export);
endfunction
Standard TLM mechanism for connecting
endclass
the driver and sequencer

Verification Environments
Many protocols have a variable number of devices
Example: AHB has multiple masters and slaves

These are represented as agents in UVM

Agents share a common configuration or common signals
Example: Bus speed

Agents communicate with each other directly or via a central

component
Example: A single bus monitor can serve multiple agents

Environment classes (envs) are introduced to

encapsulate and configure multiple agents
Contain all the reusable logic for an interface
Also referred to as UVM Verification Components (UVCs)
Usually have two or more agents

100

Allows changing the number

Example: Bus
of agents without further
SomeEnvironment
agent config
parameters come from configuration per agent
Environment the environment config
master agent
master agent
master
agent
sequencer
sequencer
Config:
sequencer
Config:
Config:

slave agent
slave agent

monitor
monitor
monitor

Config:
Config:

i/f
events,
events,
status,
events,driver
status,
driver
data
status,
driver
data
data
vi
vi
vi
vi
vi
vi

101

monitor
monitor
events,
events,
status,
status,
data
data
vi
vi

i/f
i/f

driver
driver
vi
vi

interface
Envs allow reuse at the interface
level!
DUT

num_masters=3
num_slaves=2

Virtual
interface

seq

i/f vi
i/f

vi

i/f

Sometimes common
sequencer
for all agents
Config:

seq
seq

i/f
i/f

arbiter agent

sequencer
sequencer

seq
seq
vi
i/f seq
i/f

Config:

i/f

monitor

monitor
i/f

events,
status,
data
vi

driver

events,
status,
data

vi

vi

Bus level monitoring can

be used by all agents

Simulation Phases and Coordination

When moving to classes you need to manage

environment creation at run-time
Test execution is divided to phases
Configuration, testbench creation, run-time, check, etc

Unique tasks are performed in each simulation phase

Set-up activities may be 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

A set of standard phases enables VIP plug & play

Allows orchestrating the activity of components that were
created by different resources
102

Simulation Phases and Coordination

Simulation Phases
What if UVC1 starts
sending traffic right
after build_phase()?

Now we can start

sending traffic

build_phase
connect_phase

end_of_elaboration_phase

start_of_simulation_phase
run_phase

UVC1

DUT

UVC2

extract_phase
check_phase
report_phase

Can this VC check for nonempty scoreboard?

Environment was not fully
elaborated yet!
Must wait for run_phase()

UVC3

Not yet! All components must finish

their run phase first!
Now can check
scoreboards

103

UVM Simulation Phases

UVM components built-in phases run in order
All phases except run_phase()
Execute in zero time

build
build_phase
connect_phase
connect

Build Top-Level Testbench Topology

Connect environment topology

end
of elaboration_phase
end
of elaboration Post-elaboration activity (e.g. print topology)
start_of_simulation_phase
start_of_simulation Configure verification components

104

run
run_phase

task Run-time execution of the test

extract_phase
extract

Gathers details on the final DUT state

check
check_phase

Processes and checks the simulation results

report
report_phase

Simulation results analysis and reporting

2011 Cadence Design Systems, Inc. All rights reserved.

UVM Run-Time Phases

Time consuming and run in parallel to run_phase
build_phase

pre-reset
reset

connect_phase
end of elaboration_phase
start of simulation_phase

post-reset
pre-configure
configure
post-configure

run_phase
pre-main
extract_phase

Allow components to
perform operations
related to reset

main
post-main

Perform operations
related to device
configuration (register
settings and more)
Defines the normal
operation of the
component for the
bulk of the test

check_phase
report_phase
finalize
105

2011 Cadence Design Systems, Inc. All rights reserved.

pre-shutdown
shutdown
post-shutdown

Data can drain from

the device and other
operations for
graceful termination

Its Lab Time! Lab 3

UVM
Testbench

Scoreboard
coverage

Reusable Environment
Topology:

UART
DUT

APB
UVC

Objectives:
Review the UVM
Verification Component
architecture: sequencer,
driver, monitor, agent, env
Understand how to make
an agent PASSIVE

Multi-channel
controller

UART UVC
tx_agent
Config:
Is_active

rx_agent
sequencer
sequenc
es i/f

monitor
events,
data
coverage
vi

106

UART
UVC

i/f

driver
vi

Config:
Is_active

sequencer
sequenc
es i/f

monitor
events,
data
coverage
vi

i/f

driver
vi

Reusable Environment - Summary

Creating reusable environments requires

Streamlining environment design and topology to use factory
design patterns
Reducing the learning-curve and support on the integrator side

UVM topology uses

Environment as top-level reuse component
Agents to stimulate and monitor devices
Agents have standard structure, sub-components with well
defined roles and configuration scheme to ensure quick
adoption

107

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Controlling verification environment
Automating environment creation with IVB

Coverage Analysis and Regression

UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
108

Test Requirements

Simple to write and understand

Minimize the verification knowledge required to create a test
Provide a basic, intuitive test-writer interface
Offers additional guidance to hit complex corner cases

Tests should be as reusable as possible

Ability to write hierarchy independent tests (reusable from block
to system)
No need to re-describe the testbench topology for every test

Compile once, run many simulations

Avoid re-elaboration of the environment for multiple tests

109

Try 1: Tests as Program Blocks

module top ( );
program test();

Mon

BFM

SEQR

Module VC
Scoreboard

Mon

DRV

VC3

coverage
Multi Channel Sequence Generator

CPU

Mem

Periph

Periph

Mon
BFM
Mon
BFM
Mon DRV

UVC1
VC3

Utilizes the program block reactive

region

Disadvantages

DUT

SEQR

110

BUS
Mon UVC
BFM

Instantiate the reusable components

within a program block
Advantages

Mon
BFM
Mon
BFM
Mon DRV

SEQR

UVC
VC32

Test writer needs to know how to

instantiate verification environment
Config change requires changes in
many tests
No reuse (Can not extend
programs)
Timing problems in multi-language
environments

Try 2: Top Test Class

Instantiate the reusable
components within a class

module top ( );
class test();

BUS
Mon UVC
BFM
Mon

SEQR

Module VC
Scoreboard

Mon

DRV

VC3

coverage
Multi Channel Sequence Generator

DUT
CPU

Mem

Periph

Periph

Mon
BFM
Mon
BFM
Mon DRV

SEQR

UVC1
VC3

111

BFM

Mon
BFM
Mon
BFM
Mon DRV

SEQR

UVC
VC32

Instantiate the test class inside the

top level module

Advantages
Allows reuse through inheritance
Can instantiate and modify
Can compile many tests and
elaborate once
Allows multi-language testbenches

Disadvantages
Test writer still needs to know how
to instantiate the verification env
Config change requires modifying
many tests

Best: Testbench Environment (TB)

module top ( );

Separate the env configuration

and the test

class test extends

BUS
class tb extends uvm_env
Mon UVC
BFM
Mon
BFM
Module VC

SEQR

Scoreboard

Mon

coverage
Multi Channel Sequence Generator

DUT
CPU

Mem

Periph

Periph

Mon
BFM
Mon
BFM
Mon DRV

SEQR

UVC1
VC3

112

DRV

VC3

Mon
BFM
Mon
BFM
Mon DRV

SEQR

UVC
VC32

TB class instantiates and configures

reusable components

Specific tests are built on top of

testbenches (tbs)
Specify the nature of generated traffic
Can modify configuration parameters
as needed

Benefits
Tests are shorter, and descriptive
Less knowledge to create a test
Easier to maintain changes are done
in a central location

Using a tb for Multiple Tests

A single tb describes the
testbench topology and
run-time settings
Multiple tests instantiate
this testbench

tb

Test1
Test2
- Use only
legal frames
Test3
Use zero frame
delay
- Do not Have
sendTest4
out-of-order
4 masters
Back-to-back
short
Send long
frame streams
frames frames
Change the clock speed
Send many illegal frames

113

If config needs to be
changed, no need to
visit all tests

Tests determine the

nature of the generated
traffic

The Test Launching Mechanism

test3
tbtest2
tbtest1

env
tb
env
env
env
env
env
env
env

virtual task run_phase();

endtask

Multiple tests

module top
`include . // uvm lib, test, and components
IF

IF

IF
DUT

initial begin
run_test(test1);
end

rst

clks

Creates the test and

starts the simulation
phasing mechanism
for all components

endmodule : top
DUT snapshot

the entire
together
and use
Allows execution Compile
of multiple
teststest
on suite
the same
snapshot
command-line option to select a test:
% irun f run.f +UVM_TESTNAME=test3

114

Testbench Example
class uart_ctrl_tb extends uvm_env;
`uvm_component_utils(uart_ctrl_tb)
Extends from uvm_env
apb_env apb0; // APB UVC
uart_env uart0; // UART UVC
uart_ctrl_env uart_ctrl0; // Module UVC

Configure using wildcards

Minimal effort and

virtual function void build();
component knowledge
super.build();
required
uvm_config_db#(uvm_bitstream_t)::set(this,apb0.master*,
is_active, UVM_ACTIVE);
uvm_config_db#(uvm_bitstream_t)::set(this,uart0.tx, is_active,
UVM_ACTIVE);
uvm_config_db#(uart_ctrl_config)::set(this,uart_ctrl0, cfg, cfg);
Create and build using
apb0 = apb_env::type_id::create(apb0, this);
standard mechanism
uart0 = uart_env::type_id::create(uart0, this);
uart_ctrl0 = uart_ctrl_env::type_id::create(uart_ctrl0, this);
endfunction
endclass
115

How a Test Uses a UVM Testbench?

class apb_uart_rx_tx extends uvm_test;
`uvm_component_utils(apb_uart_rx_tx)

Extends from uvm_test

uart_ctrl_tb uart_ctrl_tb0; //testbench

virtual function void build_phase(uvm_phase phase);
Configuration information
super.build_phase(phase);
specific for this test
// Set the default sequence for master
uvm_config_db#(uvm_object_wrapper)::set(this,uart_ctrl_tb0.apb0.master.
sequencer.run_phase",default_sequence",
"read_modify_write::type_id::get()");
//Construct and build the uart_ctrl_tb0 environment
uart_ctrl_tb0 = uart_ctrl_tb::type_id::create(uart_ctrl_tb0, this);
endfunction: build_phase
Test creates and builds
the testbench

virtual task run_phase(uvm_phase phase);

uvm_top.print_topology();

run() task is optionally used for runendtask

time test control or status. e.g.,
endclass: apb_uart_rx_tx
print dynamic testbench topology
116

Multi-Channel Sequences

So far, we have seen how to control stimulus for a single

channel (interface)
Create a sequencer
Create and register sequences

In a verification environment, we need to coordinate

traffic on multiple interfaces in parallel
Coordinate data and time
After finishing configuring the device send Ethernet traffic

Multi-channel sequences are called virtual sequences

Single procedural thread to control multiple interfaces
Can create reusable system-level sequences

117

Multi-Channel Sequences
uart_ctrl_env
virtual_sequencer
config_dut

u2a_incr_payload

uart_incr_seq
p_apb_seqr
p_uart_seqr

apb_rd_rx_fifo

class u2a_incr_payload extends uvm_sequence;

. . .
virtual task body();
`uvm_do_on (config_dut,
p_sequencer.p_apb_seqr);
fork
`uvm_do_on(uart_incr_seq,
p_sequencer.p_uart_seqr);
`uvm_do_on(apb_rd_rx_fifo,
p_sequencer.p_apb_seqr);
join
endtask

uart_env

apb_env
apb_agent

uart_agent
uart_sequencer

apb_sequencer

seq

config_dut
uart_incr_seq

seq
rd_rx_fifo

Driver

118

Driver

Determining End-of-Test
Virtual Sequencer
coordinates traffic on
UVC1 and UVC2

virtual
sequences

Virtual
Sequencer

sequences

vseq2

UVC2

seqr

DUT

We cant just rely on the

virtual sequence because
other sequences may be
executing in parallel

mon agent

sequences
ovc2_seq1

drvr seqr

drvr

Sequences (and virtual

sequences) can be nested.

How do we decide
when to end a test?

119

...
fork
`uvm_do_on(ovc2_seq1, ovc2)
`uvm_do_on(ovc1_seq3, ovc1)
Join
...

UVC1
agent mon

ovc1_seq3

Each UVC and the virtual

sequencer have a list of
executable sequences

UVC3
sequences
ovc3_seq1

agent mon
seqr

drvr

Reactive: runs forever, serving

requests as they appear

Ending Simulation

An objection (consensus) mechanism is

used to elegantly end simulation
run_phase and every sub-phase has a
built-in objection mechanism called
phase_done
The objection mechanism tries to end
every phase immediately
A sequence must raise an objection when it
starts to hold off the end execution
A sequence must drop the objection on
finishing
After a certain time (drain time) with no
objections raised, the phase ends

raise

drop

drain time

sequence

start

stop
called

stop
executed

Phase ends if no objections were raised,

or when all objections are removed
Expandable, reusable and flexible

120

120

Raising and Dropping Objections

class retry_seq extends uvm_sequence#(uart_frame);
...
task body();
`uvm_info(get_type_name(), Executing retry_seq", UVM_LOW)
starting_phase.raise_objection(this, retry_seq");
`uvm_do_with(req, {payload == pload; parity == BAD_PARITY;} )
...
starting_phase.drop_objection(this, " retry_seq ");
endtask
endclass

starting_phase is a pointer to the phase in which the sequence is executed

Objections are handled hierarchically
Every component has a objection count (phase_done) for every run phase
Both raised and dropped objections propagate up the hierarchy
When the uvm_top objection count for a phase returns to zero, the phase
can end
Not all sequences should raise objections
Not appropriate for background traffic, response generators, sub-sequences
etc.
121

20 September 2012

Cadence Confidential

Drain Time
When all raised objections are dropped, simulation is stopped
A drain time allows propagation of outstanding items (e.g., DUT
response)
If no drain time is set, the test will stop immediately

Drain time can be set as:

Absolute delay by calling set_drain_time for a specific phase
Usually from a test class
task run_phase(uvm_phase phase);
. phase.phase_done.set_drain_time(this, 200ns);
endtask : run_phase

Event delay by defining method all_dropped in env or other

component
Automatically called when objection count for component returns to 0.
task all_dropped (uvm_objection objection, uvm_object source_obj,
string description, int count)

122

20 September 2012

Cadence Confidential

Objections: Messaging, Debug and Usage

UVM objections are derived from uvm_report_object so their

messaging can be controlled by UVM_VERBOSITY
uvm_test_done.set_report_verbosity_level(UVM_FULL);

The package also provides a number of debug APIs

uvm_test_done.get_objection_count(env0.agent);
// count of objections for that scope
uvm_test_done.get_objection_total(env0.agent);
// count of objections for that scope and all the descendents

123

Objection Debug

To see more debug information about objections turn on

command-line messaging:
irun +UVM_OBJECTION_TRACE

To query the number of objections raised (in code):

function int get_objection_count(uvm_object)
function int get_objection_total(uvm_object)

Both functions return the number of objections for a

given object (get_objection_total includes its
descendants).

124

20 September 2012

Cadence Confidential

Its Lab Time! Lab 4

Test Creation Using

Reusable Components:

UVM
Testbench

Scoreboard
coverage

APB
UVC

UART
DUT

UART
UVC

Objectives:
Multi-channel
Examine test creation and
Controller
control using the UART tb
Examine an existing test and observe how it instantiates an
environment
Control environment behavior from the test
Show how to control test execution and execute multiple tests
without recompiling/re-elaborating the design

125

UART DUT and Verification Environment

UVM Testbench

Scoreboard
Interface & white-box
coverage

UART DUT (Verilog RTL)

Tx FIFO

APB
Verification
Component

txd
Transmitter

APB
Interface

Mode
Switch
Rx FIFO

Receiver

Control/Status
Registers

Control/Interrupt
Logic

Virtual Sequencer
(Multi-channel controller)
126

Test 1

Test 2

Test 3

rxd

UART
Verification
Component

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Controlling verification environment
Automating environment creation with IVB

Coverage Analysis and Regression

UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary
127

IVB About the Incisive Verification Builder

What is IVB ?
Incisive Verification Builder (IVB) is a GUI-based tool
Automates the process of creating reusable multi-language
verification environments from the interface-level to the systemlevel

Creates UVM-compliant Verification Component skeleton

UVC architecture, including agents, data-items, sequencers,
driver, monitor, tb, test

Specifies (via NOTES) where to add protocol-specific

implementation code
Produces a working example on how to use the UVC in a
simulation environment

128

Automated Creation of UVCs with IVB

129

Its Lab Time! Lab 5

Verification Component Build with IVB

Objectives:
Create a simple point-to-point verification Component
Understand how IVB flow works to facilitate the UVM VC
creation
Analyze the created code
Run a simple test

130

IVB - Summary

Interface Builder quickly creates UVM-compliant

verification components
For users new to the methodology, it gives guidance
about how to create a UVC
For experienced verification engineers, it is a
productivity tool, enabling quick ramp-up for a new UVC
The templates are completely customizable and can
incorporate company-specific guidelines

131

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
MDV/EMGR - Metrics Driven Methodology
Filling coverage holes

UVM Multi-Language and UVM Acceleration

Migration to UVM
Summary
132

Recall: Multiple Coverage Metrics Must Be

Integrated

Directed Tests: 19%

Assertions: 31%

Functional Coverage: 62%

Code Coverage: 43%

How do we make sure the team has

set the required goals?
Coverage
full

How do combine
the massive
regression
Remember
this slide?
results into a readable report?
Can all members of the team participate
and analyze the report?

133

partial
none
Total Coverage: 68%

Metric-Driven Verification (MDV)

Planning with unified verification metrics
Functional
specification
.PDF
.DOC

Yes
Done

No
Plan

Signoff?

Target Metrics Milestones

Actual Metrics Achieved

Enterprise Planner
metric-based plan

Successful Milestone
Missed Milestone

Measure
and analyze
VE Start

Module
Set One

Module
Set Two

UVM
VIP
portfolio

Chip
Integration

Prototype

Construct

Production

Metric
definitions

Failure and
metric analysis

Execute

Testbench simulation, formal, hybrid, HW/SW

co-sim, equivalence checking, CDC, constraint
checking, LPV, MSV, sim acceleration, emulation
134

coverage
checks
assertions
reuse

Benefits of an Executable Feature-based Plan

Without a vPlan

With a vPlan

(Coverage Driven Verification)

(Metric Driven Verification)

Without a vPlan, all coverage appears flat

Difficult to correlate to verification plan

With a vPlan, sections can be created to isolate areas of

interest

Difficult to differentiate between high priority and

lower priority coverage

Various types of coverage can be mapped to each

section
Very easy to measure progress relative to your plan and
priorities

135

Creating the Verification Plan:

Enterprise Planner (EP)
Team Brainstorm
Planning

EP automates the creation of verification plans

Functional
and Design
Specs

Enterprise Planner

Spec
Annotator

Verification
Plan
Editor

Export the vPlan for coverage tracking,

analysis and management
Specification changes are identified and
highlighted

Functional Coverage
mapping/building

Spec Change Auditor

Verification Plan
Documenter

Collect ideas in a brainstorming session

Able to use existing specifications and requirements
Drag and drop specification sections into the plan
Map functional coverage into the plan

Prevents specification, plan and implementation

misalignment

Create HTML documents for sharing

Existing plan can be referenced in another
vPlan allows reuse!
vPlan

HTML/RTF

136

vPlan
Export

System
vPlan

Executable Verification Plan - vPlan

Incorporates data from
many metrics
Directed tests

UART Verification Plan (Word doc)

1.1 Functional Interfaces

Test
Pass/Fail
metrics

Functional Specs

Specification
of features

1.1.1 Serial Data Interface

The UART transmits and receives serial data. The data formats and
speed are configurable to match those of an industry standard 16c550a
UART.

1.1.1.1 Serial Link Configuration Rx

The UART can receive and transmit data in a configurable word format
and size. These configuration features are common to both Rx and Tx
traffic. All combinations shall be tested except for baud rate.

1.1.1.1.1 Word Length

Coverage of possible word lengths: 6, 7, 8 bits
Cover Group: uart_monitor::uart_trans.DATA_LENGTH

Code coverage and other metrics

1.1.1.1.2 Stop Bits

Coverage of stop bit length:
Cover Group:uart_monitor::uart_trans.NUM_STOP_BITS

Other vPlans

1.1.1.1.3 Parity Type

Coverage of good and bad parity frames.
Cover Group: uart_monitor::uart_trans.PARITY_TYPE

Coverage
1.1.1.1.4 Cross Length Parity Type
metrics

Cross of length versus parity.

Cover Group: uart_monitor::uart_trans.LENGTH_x_PTYPE

UART Verification Plan

4 of 20

Project Team
Brainstorming

137

Other
contributing
vPlans

Verification Planning and Management Flow

Enterprise Manager (EManager)
Design
Specification

Done!

Plan

Verification
Plan

Yes
Verification
Closure?

Optimized Process
Automation Engine

No
Enterprise Manager

Sessions

React

Status

Test_name
# iterations
Cmd line args
Seed

Failure
Analysis
Progress
Analysis

Execute
Verification Environment

DUT

Measure
138

Specman Elite
Specman
Elite
+
+
Simulation
Incisive
Simulator
Simulation

Its Lab Time! Lab 6

Coverage Analysis with Verification Planning and

Management
Objectives:
Use an executable verification plan to do coverage hole
analysis across multiple simulation runs (regression)
Use test ranking to eliminate redundant tests
Perform coverage correlation to identify how to proceed
Run a new simulation and analyze progress across multiple
regression runs

139

Agenda
Introduction to UVM and Coverage Driven Verification
UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary

140

UVM Multi-Language (ML) Enable Mixed-Language Env

UVM is an umbrella term for

environment construction and
reuse methodology + libraries
OOP

All libraries are open

source under the
Apache license

AOP

VM

SystemC

System
Verilog

SV

SysC
Methodology includes TLM
communication between implementations

Proven methodology independent of language

Built-in language interoperability
14
1

September 20, 2012

Cadence Confidential

VM

UVM

UVM Enables Mixed-Language Verification

Reduces risk and unifies SoC verification teams

e
UVC

SV
UVC

UVC

Single UVM methodology for

SystemVerilog, e and SystemC
Unifies VIP for reuse

SoC
SC
UVC
SC
UVC

C/C++
VIP

SV
VIP

Choose best language for

application and group skills
VMM
VIP

Enables companies to choose

best verification solution
142

UVM for acceleration

Extending agents for acceleration
UVMUVM
Acceleration
Simulation

Cadence provides

Hardware Accelerator

Simulator
SoftwareSoftware
Simulator

Agent
Agent
Sequencer
Sequencer

Monitor
Monitor
events,
Coverage
status,
Checking
data

sequences
sequences

Collector
Collector
UVM ACCEL mode

Driver
Driver
UVM ACCEL mode

VIF
SCE-MI
PROXY

VIF
SCE-MI
PROXY

I/F
(collector_bfm)

I/F

I/F
(driver_bfm)

DUT
DUT

143

UVM library extensions: UVM_Accel

Methodology
Examples

Support SV and e
Enables verification re-use
between simulation and
acceleration

Using SCE-MI 2.0 Pipe Proxies

UVM_Accel library provides two SCE-MI pipe proxy base classes
uvm_accel_input_pipe_proxy: put() api to send transaction to DUT
uvm_accel_output_pipe_proxy: get() api to get transaction from DUT

put

Transaction
goes in!

get

SCE-MI PIPE
PROXY

Supports serialization and buffering of

variable sized transactions
Blocking TLM API
The proxies are templates with the data
item type

Byte-stream
comes out!

DUT

144

SCE-MI pipe

The Software HDL Interface

SCE-MI 2.0 modules
scemi_input_pipe
scemi_output_pipe

Simulator

Transactions

SCE-MI pipe C
interface

Host
Workstation

145

SCE-MI
2.0
Interface

HDL Side API

Sce-mi modules
(RTL)

UVM
Pipes Proxy

Driver
(HVL)

UVM
Testbench

Accelerator

Clock

DUT
BFM
(HDL)

signal-level
interface

Cadence
PdXP

Design & Verification Flow

Incremental Design Refinement with Localized Verification
Plan 1
Algorithm Verification

Tests
Architecture Verification

Verification

TLM Generic
payload

Simulation/formal

Verification

3
Micro-Architecture Verification

TLM Non-GP
Simulation
Environment

Verification

RTL
Simulation

3
Verification

vPlan

HW
Accel

Environment

Unified
Metrics

Environment

Coverage

&
Checking

Environment

Agenda
Introduction to UVM and Coverage Driven Verification
UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary

147

Migration from OVM to UVM

Migration Steps:
1 Download the UVM Early Adopter Kit
2 Convert OVM testbench to UVM using provided perl
script
3 Make small adjustments to the run script to pickup
UVM library
4 Add Incisive transaction recording support
5 Start verifying!

148

Migrating from VMM to UVM

UVM Environment

Module UVM VC
Reg Model
Scoreboard

UVM Virtual Sequencer

Sys_monitor

Input UVM VC

Channel UVM VC

sequencer
Agent
agent0
monitor

driver
DUT

Virtual
Sequence

agent1

VMM VIP
Gen

Driver
Monitor

agent2

Encapsulate VMM environment

Use uvm_vmm_interop library being tested by Accellera
bfms/monitors/transactions may be reusable

Expect encapsulation and swap-out occurring over several projects

Work with Cadence and UVM partner migration services
149

VMM UVM Conversion Process Overview

1. Discovery scoping session

Understand customer DUT & existing VMM environment

DUT block diagram

VMM environment block diagram & code

2. Analyzing VMM environment

Review block diagrams, code

Generate UML diagram, using SV2xmi script and ArgoUML (optional)

3. Map VMM environment to UVM environment

a) Identify DUT interfaces & develop interface UVCs
Use IVB to generate template code for the interface UVCs
Reuse code from VMM drivers, monitors/checkers, scenarios

b) Develop module UVC, register sequencer, and virtual sequencer

Possibly reuse code from VMM scoreboard
Map VMM test phases to UVM virtual sequence

150

Download UVM Early Adopter Kit

Download library from
http://www.accellera.org/activities/vip/uvm1.1tar.gz
This kit contains UVM source code, user guide, pdf and
html reference.
A perl script in uvm/bin/OVM_UVM_Rename.pl
this script parses all .v, .vh, .sv, .svh files and converts
the ovm/tlm prefix on class names to uvm/uvm_tlm
prefix coded in the UVM base classes.

151

Agenda

Introduction to UVM and Coverage Driven Verification

UVM Class-based Workshop:
The UVM Library
Stimulus Generation
Building Reusable Verification Components
Testbench Creation Using Reusable Components
Coverage Analysis and Regression
UVM Multi-Language and UVM Acceleration
Migration to UVM
Summary

152

What Have We Seen Today?

Introduction to coverage-driven verification concepts

Using UVM methodology and the UVM library to:
Accelerate CDV environments creation
Build reusable environments (and not only reusable classes)

Ways to automate the verification process and achieve

plan-driven verification
Deploying the concepts and technology above allow
you to:
Significantly shorten your verification cycle
Get better leverage of your entire team
Improve the overall quality of your DUTs

153

Beyond UVM
Inside the Incisive Platform
Unique Metrics Driven Methodology around UVM
Scalable register & memory modeling package
reg_mem downloadable from uvmworld.org/contributions.php

Only proven plan-based verification management solution

VIP plug & play with module-based SystemVerilog and eRM
Mixed-language methodology and automation

Best simulation, formal, and hardware verification engines

Wizards for environment creation (IVB)
Transaction level dynamic environment debug
Over 200 worldwide verification Applications Engineers with
Plan-to-Closure and methodology expertise to ensure
successful project deployment
154

Useful Websites
UVM World Website:
http://uvmworld.org
Download latest version of UVM library, join the Community Forum to share
ideas and have discussions with other UVM users

Cadence User Community Website:

http://www.cdnusers.org
Share ideas and have discussions with other Cadence tool users

Cadence Educational Services Offerings:

http://www.cadence.com/support/education/index.aspx

155

SystemVerilog Advanced Verification using UVM

SystemVerilog Language and Application

Learning more
A Practical Guide to Adapting the Universal
Verification Methodology (UVM), by Sharon
Rosenberg and Kathleen A Meade

UVM Reference Flow

http://uvmworld.org /uvm-reference-flow.php

156

An open-source contribution by Cadence Design systems, Inc.

Providing a UVM reference for users to train and learn
Enabling a uniform environment for executing UVM code
Establishing a standardized solution for benchmarking
Demonstrating the features provided with UVM Verification
Components (UVCs)

Thank You!

157