World Class Verilog & SystemVerilog Training

OVM & UVM Techniques for Terminating Tests
Clifford E. Cummings

Tom Fitzpatrick

Sunburst Design, Inc.
www.sunburst-design.com
cliffc@sunburst-design.com

Mentor Graphics Corp
www.mentor.com
tom_fitzpatrick@mentor.com

ABSTRACTThe Open Verification Methodology (OVM) and the new Universal Verification methodology (UVM)
have a number of methods for terminating the run() phase at the completion of a test, usually via a
combination of sequence completion, calls to the global stop_request mechanism and/or the recentlyadded objection mechanism. Many users also use built-in event and barrier constructs on a more
application-specific basis to achieve their goals. This plethora of choices has led to some confusion
among the user community about how best to manage this important aspect of the testbench.
This paper describes various techniques for gracefully terminating an OVM/UVM test, and proposes a
set of guidelines to avoid further confusion.
Categories and Subject Descriptors
D.3.3 [Programming Languages]: Language Constructs and Features – abstract data types,
polymorphism, control structures.
General Terms
Algorithms, Documentation, Performance, Design, Experimentation, Standardization, Languages,
Theory, Verification.
Keywords
UVM, OVM, SystemVerilog, testbench, global_stop_request() , raise objection, drop objection.

DVCon 2011
Rev 1.1

1

OVM & UVM Techniques
for Terminating Tests

Table of Contents
1. INTRODUCTION ................................................................................................................................ 5
1.1 Versions .......................................................................................................................................... 5
2. COMPILING DESIGNS & RUNNING UVM..................................................................................... 6
3. PHASES................................................................................................................................................ 7
3.1 Run() Phase..................................................................................................................................... 8
3.2 Run() Phase Stages ......................................................................................................................... 9
3.3 Run() Phase Threads ..................................................................................................................... 10
3.3.1 Non-Stopping Threads ............................................................................................................ 10
3.3.2 Stop-Request Threads ............................................................................................................. 10
3.3.3 Objections-Raised Threads ..................................................................................................... 11
3.3.4 Enabling Stop-Interrupts In Threads....................................................................................... 11
4. HOW UVM 1.0EA SIMULATIONS WORK .................................................................................... 13
4.1 uvm_root ....................................................................................................................................... 14
4.2 uvm_root Typical Use................................................................................................................... 16
4.3 run_test() ....................................................................................................................................... 18
5. HOW UVM SIMULATIONS RUN ................................................................................................... 20
5.1 Choosing A Test To Run .............................................................................................................. 20
5.2 Common +UVM_TESTNAME Errors......................................................................................... 20
5.3 Verilog-Style Testbench ............................................................................................................... 21
5.4 Common New-User UVM Testbench Coding Mistake................................................................ 22
5.5 Proper Use of global_stop_request() Command........................................................................... 23
6. HOW UVM SIMULATIONS STOP.................................................................................................. 27
6.1 Timeouts ....................................................................................................................................... 27
6.2 Stop-Interrupt Enabled Example .................................................................................................. 29
6.3 Stop_Timeout Example ................................................................................................................ 31
6.4 Global_Timeout Example............................................................................................................. 33
6.5 Delayed Global_Timeout Example............................................................................................... 35
6.6 run() Task Sets Timeout Value Example...................................................................................... 37
6.7 build() Phase Sets Global_Timeout Value Example .................................................................... 39
6.8 Raising And Dropping Objections Example ................................................................................ 41
6.9 Raising And Dropping Multiple Objections Example.................................................................. 43
6.10 Multiple Objections And forever-Loop Example ......................................................................... 45
6.11 Multiple Objections Then Stop-Interrupt Activity Example ........................................................ 47
6.12 Dropped Objection And Early global_stop_request() Example ................................................... 51
6.13 Dropped Objection And Late global_stop_request() Example..................................................... 53
7. SUMMARY & GUIDELINES ........................................................................................................... 56
8. ACKNOWLEDGMENTS .................................................................................................................. 57
9. REFERENCES ................................................................................................................................... 57
10. AUTHOR & CONTACT INFORMATION .................................................................................... 58
11. Revisions.......................................................................................................................................... 58
11.1 Revision 1.1 (February 2011) - What Changed? .......................................................................... 58

DVCon 2011
Rev 1.1

2

OVM & UVM Techniques
for Terminating Tests

Table of Figures
Figure 1 - (1) Compiling designs & running UVM - overview................................................................. 6
Figure 2 - UVM Phase Usage comments.................................................................................................... 7
Figure 3 - uvm_component directory structure and file locations.............................................................. 8
Figure 4 - run() phase - Active Stage, Stop-Interrupt Stage and Timeout.................................................. 9
Figure 5 - run() phase execution flow diagram (without timeouts)............................................................ 9
Figure 6 - UVM_FATAL - No components instantiated - missing test name ......................................... 20
Figure 7 - UVM_FATAL - +UVM_TESTNAME not found - test not registered with the factory......... 21
Figure 8 - Verilog style testbench output.................................................................................................. 22
Figure 9 - Test timeout - BAD global_stop_request() after run_test() command .................................... 23
Figure 10 - global_stop_request() terminates the run() phase and post-run() phases execute ................. 24
Figure 11 - UVM report output after proper termination of the run() phase using call to
global_stop_request().............................................................................................................. 24
Figure 12 - $finish command causes the run() phase to abort and post-run() phases never execute ....... 25
Figure 13 - $finish; causes simulation to abort run() phase - no final reports printed ............................. 26
Figure 14 - run() phase execution flow diagram (with timeouts) ............................................................. 28
Figure 15 - test3 UVM reported output .................................................................................................... 30
Figure 16 - (1) run() phase - Active Stage and Stop-Interrupt Stage....................................................... 30
Figure 17 - test4 UVM report output after Stop-request timeout ............................................................. 32
Figure 18 - test5 UVM report output after Watchdog (global) timeout ................................................... 34
Figure 19 - test6 UVM report output after Watchdog (global) timeout ................................................... 36
Figure 20 - test7 UVM report output after Stop-request timeout ............................................................. 38
Figure 21 - test8 UVM report output after Watchdog (global) timeout ................................................... 40
Figure 22 - test9 UVM report output after all objections were dropped .................................................. 42
Figure 23 - test10 UVM report output after all objections were dropped ................................................ 44
Figure 24 - test11 UVM report output after all objections were dropped ................................................ 47
Figure 25 - test12 UVM report output after all objections were dropped and stop() task completed ...... 50
Figure 26 - test13 UVM report output after all objections were dropped ................................................ 53
Figure 27 - test14 UVM report output after all objections were dropped ................................................ 55

DVCon 2011
Rev 1.1

3

OVM & UVM Techniques
for Terminating Tests

Table of Examples
Example 1 - uvm_component base stop() method definition ................................................................... 12
Example 2 - Abbreviated uvm_pkg.sv file ............................................................................................... 13
Example 3 - Abbreviated uvm.svh file (with some `include files commented out) ................................. 13
Example 4 - Abbreviated base/base.svh file (shows inclusion of 2 of 28 included files) ........................ 13
Example 5 - Abbreviated base/uvm_root.svh file .................................................................................... 15
Example 6 - uvm_root code snippet - uvm_root construction.................................................................. 17
Example 7 - uvm_root code snippet - const uvm_root uvm_top.............................................................. 17
Example 8 - Simple test module example that calls the uvm_top.uvm_rocks() method.......................... 17
Example 9 - uvm_rocks() method definition ............................................................................................ 17
Example 10 - Top module example with run_test() call .......................................................................... 18
Example 11 - Abbreviated base/uvm_globals.svh file ............................................................................. 18
Example 12 - run_test command with test name ...................................................................................... 20
Example 13 - run_test test name passed by +UVM_TESTNAME command line option ....................... 20
Example 14 - Verilog style testbench with task call followed by $finish ................................................ 21
Example 15 - BAD - top module with common mistake - global_stop_request() after run_test() .......... 22
Example 16 - test1 with NO global_stop_request().................................................................................. 22
Example 17 - GOOD - top module with run_test() and NO global_stop_request()................................. 23
Example 18 - GOOD - test2 terminates with global_stop_request()........................................................ 23
Example 19 - Bad - test2a terminates with $finish; - run() phase aborts early ........................................ 25
Example 20 - test3 with enabled stop() task ............................................................................................. 30
Example 21 - top module - set_global_stop_timeout() ............................................................................ 31
Example 22 - test4 - stop() task timeout .................................................................................................. 32
Example 23 - top module - set_global_stop_timeout() & set_global_timeout() ...................................... 33
Example 24 - test5 - times out due to set_global_timeout() set to 550ns................................................. 34
Example 25 - top module - set_global_stop_timeout(), set_global_timeout() and delayed startup ......... 35
Example 26 - test6 with run() and stop() tasks ......................................................................................... 36
Example 27 - Simple top module used for testing - no timeout values set and no startup delays............ 37
Example 28 - BAD: test7 with & set_global_timeout() set in the run() task - too late ............................ 38
Example 29 - test8 with set_global_timeout() set in the build() method - stop-timeout is active............ 40
Example 30 - test9 with raise_objection()/drop_objection() to terminate the test ................................... 41
Example 31 - test10 & env with raise_objection()/drop_objection() - last drop ends test ....................... 44
Example 32 - test11 - tb_driver with forever loop (loop will be cancelled when all objections are
dropped).............................................................................................................................. 46
Example 33 - test11 - env and test11 raise and drop objections............................................................... 46
Example 34 - test12 - tb_driver with cancelled forever loop but still executes stop() task...................... 49
Example 35 - test13 - tb_driver with forever loop (loop will be cancelled when all objections are
dropped).............................................................................................................................. 52
Example 36 - test13 - global_stop_request() ignored until env drops objections .................................... 52
Example 37 - test14 - tb_driver with forever loop (loop will be cancelled when all objections are
dropped).............................................................................................................................. 54
Example 38 - test14 - global_stop_request() comes too late after all objections dropped and is ignored 55

DVCon 2011
Rev 1.1

4

OVM & UVM Techniques
for Terminating Tests

1. INTRODUCTIONUVM version 1.0ea is a verification class library based largely on the OVM version 2.1.1 class library.
The descriptions in this paper reference the UVM code and methods but the comments on this topic are
just as applicable to OVM. Terminating the simulation run() phase is identical using either classlibrary except where noted.
Unlike all of the design modules and interfaces that are called during compilation and elaboration, noneof the UVM testbench environment is setup until after simulation starts.
To help understand these topics, it is often useful to understand some basics about how the UVM classlibrary files are laid out in the uvm directory. This paper details important basics on vital files and where
they are located. The location of important files, class definitions and global variables and tasks can bedifficult to find. This paper will help to partially navigate the UVM maze that hides many importantdetails.

1.1 Versions
This paper is based on UVM version 1.0ea (ea - Early Adopter version), which is largely based on OVM
version 2.1.1. All of the examples in this paper were tested with QuestaSim version 6.6.

DVCon 2011
Rev 1.1

5

OVM & UVM Techniques
for Terminating Tests

2. COMPILING DESIGNS & RUNNING UVM
To help understand how UVM simulations work within the SystemVerilog testbench environment, it isuseful to have a big-picture view of the entire simulation flow.

Figure 1 - (1) Compiling designs & running UVM - overview

As shown in Figure 1, a design and testbench are first compiled, then the design and testbench areelaborated. Design and elaboration happen before the start of simulation at time-0.
At time-0, the procedural blocks (initial and always blocks) in the top-level module and in the restof the design start running. In the top-level module is an initial block that calls the run_test()
task from uvm_top. When run_test() is called at time-0, the UVM pre-run() global function
phases (build(), connect(), end_of_elaboration(), start_of_simulation()) all
execute and complete. After the pre-run() global function phases complete (still at time-0), the global
run() phase starts. The run() phase is a task-based phase that executes the entire simulation,
consuming all of the simulation time. When the run() phase stops, the UVM post-run() global
function phases (extract(), check(), report()) all run in the last time slot before simulationends.
By default, when run_test() is done, $finish is called to terminate the simulation.

DVCon 2011
Rev 1.1

6

OVM & UVM Techniques
for Terminating Tests

3. PHASESFor discussion purposes, it is useful to start with a quick reminder of the standard UVM 1.0EA phases.
Some brief references will be made to these phases throughout the content of this paper.
IMPORTANT: A somewhat poorly documented fact about OVM/UVM phases is the fact that thephases are named for the methods that execute in those phases. Perhaps this was too obvious to plainly
document. For example, when the OVM/UVM simulation is in the build() phase, it executes thebuild() void function methods. When the simulation is in the connect() phase, it executes theconnect() void function methods. And of course, when the simulation is in the run() phase, it forks
and executes all the run() task methods, etc.
Some of the best UVM (and OVM) documentation is actually buried in the comments of the UVM baseclass source files themselves, if you know where to look. A concise description of the UVM phases canbe found in the uvm_phases.sv file in the uvm/src/base subdirectory. The documentation buriedin the source files is automatically extracted, via NaturalDocs[6], into the UVM Reference Manual[10],which is provided in both PDF and HTML formats. This will continue to be the case for UVM version
1.0[11]. This information can be found in the Base > uvm_phase > Usage section of the UVM Reference
Manual.
// Section: Usage//// Phases are a synchronizing mechanism for the environment. They are// represented by callback methods. A set of predefined phases and corresponding// callbacks are provided in uvm_component. Any class deriving from// uvm_component may implement any or all of these callbacks, which are executed// in a particular order. Depending on the properties of any given phase, the// corresponding callback is either a function or task, and it is executed in// top-down or bottom-up order.
//// The UVM provides the following predefined phases for all uvm_components.
//
//
build
- Depending on configuration and factory settings,//
create and configure additional component hierarchies.
////
connect - Connect ports, exports, and implementations (imps).
////
end_of_elaboration - Perform final configuration, topology, connection,//and other integrity checks.
////
start_of_simulation - Do pre-run activities such as printing banners,//
pre-loading memories, etc.
//
//
run
- Most verification is done in this time-consuming phase. May fork//
other processes. Phase ends when global_stop_request is called//
explicitly.
////
extract - Collect information from the run in preparation for checking.
//
//
check
- Check simulation results against expected outcome.
////report- Report simulation results.
Figure 2 - UVM Phase Usage comments

DVCon 2011
Rev 1.1

7

OVM & UVM Techniques
for Terminating Tests

In fact, the preceding excellent summary-description of the UVM version 1.0ea phases comes fromcomments on lines 284-316 of the uvm_phases.sv file, as shown in Figure 2.
Of these eight standard pre-defined phases, four of the phases are pre-run() function phases that
execute in zero-time after compiling and elaborating the design (typically at time-0) but before therun() phase commences, and three of the phases are post-run() function phases that execute in zerotime at the end of the simulation after the run() phase completes.
3.1 Run() Phase
The run() phase is the only standard pre-defined UVM version 1.0ea phase where all simulation
activity is executed.
Included in lines 284-425 of the 427 lines that make up the uvm_phases.sv file, are brief
descriptions of: a summary-description of the UVM phases (lines 284-316), discussion of the UVM
phase subtype (lines 317-320), requirements to create a user-defined phase (lines 321-355) and a
description of the optional Phase Macros (lines 321-425).
This paper largely deals with starting and stopping the run() phase. We briefly mention the prerun() function phases by way of introduction, but then most of this paper describes how the run()phase is started and how it is gracefully terminated. Graceful termination of the run() phase allows therest of the UVM post-run() function phases to do their intended jobs and then to terminate gracefully.
Graceful termination of the run() phase often requires the use of UVM built-in terminationcommands, such as global_stop_request(), and others described in this paper.
The run() phase is a time-consuming phase. The run() phase will unconditionally execute all of therun() tasks, and conditionally all of the stop() tasks in the UVM testbench. run() and stop()
are empty virtual tasks defined in the uvm_component. Any testbench component that is derived from
uvm_component can override the run() and stop() tasks and they will be executed during therun() phase either unconditionally (run()) or conditionally (stop()).
Some of the common UVM components that are derived from uvm_component include:
Location: uvm/src/base/uvm_root.svh:

class uvm_root

Location: uvm/src/methodology/
uvm_agent.svh:
virtual class uvm_agent
uvm_driver.svh:
class uvm_driver#( ... )uvm_env.svh:
virtual class uvm_env
uvm_monitor.svh:
virtual class uvm_monitor
uvm_scoreboard.svh:
virtual class uvm_scoreboard
uvm_subscriber.svh:
virtual class uvm_subscriber #( ... )uvm_test.svh:
virtual class uvm_test
Location: uvm/src/methodology/sequences/uvm_sequencer_base.svh:
class uvm_sequencer_base
uvm_sequencer.svh:
class uvm_sequencer #( ... )Figure 3 - uvm_component directory structure and file locations

DVCon 2011
Rev 1.1

8

OVM & UVM Techniques
for Terminating Tests

3.2 Run() Phase Stages
For reference purposes in this paper, the run() phase has been divided into two stages and the threedifferent types of execution threads that can run in those stages (the different threads are discussed in
section 3.3). The two run() phase stages are the Active Stage, and the Stop-Interrupt Stage, as shownin Figure 4.

Figure 4 - run() phase - Active Stage, Stop-Interrupt Stage and Timeout

Figure 5 - run() phase execution flow diagram (without timeouts)

DVCon 2011
Rev 1.1

9

OVM & UVM Techniques
for Terminating Tests

Execution flow of the run() and stop() tasks in these stages is shown in the flow diagram of Figure5.
All run() tasks are forked at the beginning of the Active Stage of the run() phase, while only
components that have set the enable_stop_interrupt bit will execute their respective stop()tasks during the Stop-Interrupt Stage.
More details about the execution of run() and stop() tasks are detailed throughout the remainder ofthis paper.

3.3 Run() Phase Threads
Again, for reference purposes in this paper, the run() phase execution threads can be divided into
three types: Non-Stopping threads, Stop-Request threads and Objections-Raised threads.
All three types of execution-threads are coded as run() tasks that are defined in tests or components
and are directly or indirectly extended from uvm_component. All three begin execution as forked
run() tasks at the beginning of the Active Stage of the run() phase

3.3.1 Non-Stopping Threads
Non-Stopping threads are run() tasks that either execute their code without issuing a stop command or
are run() tasks with a forever loop that never ends.
A run() task that does not make a call to global_stop_request() or that does not raise any
objections would be a non-stopping thread.
A common run() task example that includes a forever loop would be a UVM testbench driver. The
drivermight
haveaforeverloop
thatcontinuously
loops
and
calls
seq_item_port.get_next_item(tx) to get the next transaction that will be supplied by theUVM sequencer. Placing a forever loop in a driver is a common practice that makes the driver
independent of the number of transactions that may be supplied by the test through the sequencer.

3.3.2 Stop-Request Threads
Stop-Request threads are run() tasks that call the global_stop_request() command inside of
the run() task. If there are no Objections-Raised threads, the run() phase will immediately process
the stop_request(), terminate the Active Stage and start the Stop-Interrupt Stage if any of theenable_stop_interrupt bits were set in any of the run() phase threads.
If there are any Objections-Raised threads, the global_stop_request() command is largely
ignored. For this reason, using the global_stop_request() command is largely discouraged as away to terminate the Active Stage of the run() phase. It only takes is a single Objections-Raised
thread to invalidate all of the global_stop_request() commands in all of the Stop-Request
threads.

DVCon 2011
Rev 1.1

10

OVM & UVM Techniques
for Terminating Tests

3.3.3 Objections-Raised Threads
Objections-Raised threads are run() tasks that call the command
uvm_test_done.raise_objection(), typically at the beginning of the run() task.
A run() task that calls uvm_test_done.raise_objection(), is specifying that it "objects tothe termination of the Active Stage of the run() phase," until the objection is dropped using the
uvm_test_done.drop_objection()command.
Once
anythreadcalls
uvm_test_done.raise_objection(),
all
calls
to
global_stop_request() from Stop-Request threads will be ignored. For this reason, thefollowing guideline is recommended:
Guideline: Use the raise_objection() / drop_objection() mechanism to terminate theActive Stage of the run() phase.
Reason: Adding a single Raised-Objection thread to a test that previously used Stop-Request threads
exclusively will turn off all stopping mechanisms that were present in the Stop-Request threads.
Choosing Objection-Raised threads over Stop-Request threads, is a defensive coding style that will
prevent confusion related to global_stop_request() commands inexplicably failing to stop the
Active Stage of the run() phase.
Once all of the threads with raised objections have been dropped, the run() phase will immediately
process an implicit stop_request(), terminate the Active Stage and start the Stop-Interrupt Stage if
any of the enable_stop_interrupt bits were set in any of the run() phase threads.
Dropping all objections will issue an immediate and implicit stop_request(), even if there is afree-running forever-loop in a Non-Stopping thread.
As a general rule, issuing the uvm_test_done.raise_objection() command in an ObjectionsRaised thread should be done at the beginning of the run() task, but it can actually be issued anywherein the run() task as long as it is issued before the end of the Active Stage. Once the Stop-Interrupt
Stage starts, calling uvm_test_done.raise_objection()will be too late and will have noeffect; therefore, no objection for that thread will be raised.
A thread cannot object to the termination of the Stop-Interrupt Stage. Setting theenable_stop_interrupt bit in one or more threads is the mechanism that is used to interrupt thetermination of the Stop-Interrupt Stage, as described in the next section.

3.3.4 Enabling Stop-Interrupts In Threads
Any of the three thread types can also delay completion of the run() phase by declaring their intent tointerrupt the stopping of the run() phase.
To interrupt the stoppage of the run() phase requires that a thread set theenable_stop_interrupt bit, typically at the beginning of the run() task. Once theenable_stop_interrupt bit is set, the thread will also execute a stop() task in the StopInterrupt Stage. Even Non-Stopping threads with forever loops can set theenable_stop_interrupt bit and include a stop() task that will execute in parallel with thethread's forever-loop activity in the Stop-Interrupt Stage.
DVCon 2011
Rev 1.1

11

OVM & UVM Techniques
for Terminating Tests

As a general rule, setting the enable_stop_interrupt bit for any thread type should be done at
the beginning of the run() task, but it can actually be set anywhere in the run() task as long as it isset before the end of the Active Stage. Once the Stop-Interrupt Stage starts, setting theenable_stop_interrupt bit will have no effect and any local stop() tasks will be ignored.
The base class stop() method is defined in the uvm_component.sv file as a simple empty task asshown in Example 1.
task uvm_component::stop(string ph_name);
return;endtask
Example 1 - uvm_component base stop() method definition

If the thread with enable_stop_interrupt=1 does not include a local stop() task, then thedefault empty stop() method will execute and return in zero time.
As a general rule, threads that set the enable_stop_interrupt bit should also define a local
stop() task to override the default stop() method. The authors can think of no good reason to set
the enable_stop_interrupt bit and omit the inclusion of a local stop() task.

DVCon 2011
Rev 1.1

12

OVM & UVM Techniques
for Terminating Tests

4. HOW UVM 1.0EA SIMULATIONS WORK
There are a few poorly-understood features that if generally understood would help explain how UVM
version 1.0ea simulations work.
First, how do some of the important UVM commands work and how do they become available?
Briefly, in a top-level module, an engineer:
1. Imports the uvm_pkg.
2. Instantiates a Design Under Test (DUT) with design interface that is used to tie the class-based
testbench to the DUT.
3. Calls a UVM run_test() method.

Of course there is more to a UVM top-module than just these three pieces, but this will serve as astarting point.
What do we get when we import uvm_pkg::*; ?
The uvm_pkg.sv is located in the uvm/src directory and is little more than an `includecommand enclosed within a package as shown in Example 2.
package uvm_pkg;`include "uvm.svh"
endpackage
Example 2 - Abbreviated uvm_pkg.sv file

The included uvm.svh file itself includes global UVM macros, and calls on three more include files
located in the uvm/base, uvm/uvm_tlm and uvm/methodology subdirectories respectively as
shown in Example 3.
//`include "uvm_macros.svh"`include "base/base.svh"//`include "uvm_tlm/uvm_tlm.svh"//`include "methodology/methodology.svh"
Example 3 - Abbreviated uvm.svh file (with some `include files commented out)

In Example 3, we have commented out all of the include commands except for the"base/base.svh" include command, because we are going to put together a simple example toshow how some important UVM simulation commands are used.
The base.svh file actually includes 28 other files from the src/base subdirectory, but we are only
going to focus on two of the included files as shown in Example 4.
`include "base/uvm_component.sv"//---------------------------------// uvm_component includes uvm_root//---------------------------------`include "base/uvm_globals.svh"
Example 4 - Abbreviated base/base.svh file (shows inclusion of 2 of 28 included files)

DVCon 2011
Rev 1.1

13

OVM & UVM Techniques
for Terminating Tests

The uvm/base subdirectory actually contains 39 files, but some of the files in this subdirectory include
other files in the same subdirectory. In fact, as indicated in Example 4, the uvm_component.sv fileincludes the very important uvm_root.svh file, which is described next.

4.1 uvm_root
From comments in the uvm_root.svh source code file[13] (also in the ovm_root.svh sourcecode file[9]):"The uvm_root class serves as the implicit top-level and phase controller for all UVM components.
Users do not directly instantiate uvm_root. The UVM automatically creates a single instance of<uvm_root> that users can access via the global (uvm_pkg-scope) variable, uvm_top. "Among other things, the uvm_root.svh file, contains the uvm_root class definition, which is anextension of uvm_component. uvm_root also has some very important methods and variables thatare used at the beginning of the simulation. Important pieces of an abbreviated uvm_root file with line
numbers are shown in Example 5 and will be discussed in more detail in this section.
1 class uvm_root extends uvm_component;
2extern protected function new (); // Later line
3
4
extern static function uvm_root get();56extern virtual task run_test (string test_name="");
7
8
extern task run_global_phase ();910extern function void stop_request();
11
12
time phase_timeout = 0;
13time stop_timeout = 0;1415//extern `_protected function new ();16
17
static local uvm_root m_inst;
18
19function void uvm_rocks ();20$display("\n*** UVM rocks! - This is the future of verification! ***\n");21
endfunction
22 endclass23
24 //--------------------------------------------------------------------------25 // IMPLEMENTATION
26 //--------------------------------------------------------------------------27
28 function uvm_root uvm_root::get();29
if (m_inst == null)30
m_inst = new();
31
return m_inst;
32 endfunction

DVCon 2011
Rev 1.1

14

OVM & UVM Techniques
for Terminating Tests

33
34 function uvm_root::new();
35 endfunction
36
37 //--------------------------------------------------------------------------38 // Create a top-level handle called: uvm_top
39 //--------------------------------------------------------------------------40
41 const uvm_root uvm_top = uvm_root::get();4243 //--------------------------------------------------------------------------44 // Primary Simulation Entry Points
45 //--------------------------------------------------------------------------46
47 task uvm_root::run_test(string test_name="");
48
bit testname_plusarg;
49
string msg;
50
51
testname_plusarg = 0;5253// plusarg overrides argument54
if ($value$plusargs("UVM_TESTNAME=%s", test_name))55
testname_plusarg = 1;56
57// if test_name is not "", create it using common factory58
if (test_name != "") begin59
msg = testname_plusarg ? "command line +UVM_TESTNAME=":60"call to run_test(";61$display("INVTST",
62{"Requested test from ",msg, test_name, ") not found." });63$finish;
64
end
65
66
$display("RNTST", {" Running test ",test_name, "..."});
67
68
run_global_phase();69 endtask
70
71 task uvm_root::run_global_phase();72$display("run_global_phase() Phases now running");
73 endtask
74
75
76 //--------------------------------------------------------------------------77 // Stopping
78 //--------------------------------------------------------------------------79
80 function void uvm_root::stop_request();81// ->m_stop_request_e;82$display("Executing stop_request();");
83 endfunction
Example 5 - Abbreviated base/uvm_root.svh file

DVCon 2011
Rev 1.1

15

OVM & UVM Techniques
for Terminating Tests

The uvm_root class includes the following important extern method definitions:protected function new(), get(), run_test(), run_global_phase(), andstop_request().The external definitions are actually included later in the same file (for example,
the task uvm_root::run_test(...); definition starts on line 47). In fact all of the definitions
for the extern methods are actually defined later in the same file, which means they are not very
extern-al! So why declare all of these methods as extern methods? By declaring all of the methods
as extern methods, the first 240 lines of the uvm_root.svh file serve as documentation for andprototypes of the methods and important variables that make up the uvm_root non-virtual class. The
details of how the methods work are included in lines 266-1218 of the rest of this file. When you open
the file, the top portion has an explanation of what you will find in the uvm_root class and the bottom
portion has the implementation details.
The uvm_root class also includes definitions for the time variables phase_timeout,
stop_timeout and the static local m_inst handle of type uvm_root.
This abbreviated version of uvm_root has been augmented with the function void
uvm_rocks() method, which is not in the actual uvm_root.svh file, but has been included in thisabbreviated file for demonstration purposes as shown in Example 8 (on the next page).

4.2 uvm_root Typical Use
Before talking about the base/uvm_globals.svh file, it is instructive to look at how the
uvm_root file is used in a typical verification environment.
The top-level module, calls the import uvm_pkg::*; command. uvm_pkg includes uvm.svh,
which includes base/base.svh, which includes base/uvm_component.sv, which includes
base/uvm_root.svh.
The inclusion of uvm_root.svh is where UVM gets interesting. The following discussion will referto the abbreviated uvm_root.svh line numbers shown in Example 5.
On line 2, there is an extern protected function new(). This line does not exist in theactual uvm_root.svh file, but the commented out extern `_protected function new()on line 15 does, and accomplishes the same goal. Declaring the new() constructor as protectedmeans that only methods inside of uvm_root can call the constructor. uvm_root cannot be declaredand constructed outside of uvm_root.
On line 17 is the declaration of a local static handle called m_inst of type uvm_root. On line 4
is the extern static function uvm_root get(); declaration, and on lines 28-32 is theexternal definition of the get() function. The first time that uvm_root::get() is called, them_inst handle will be null so the get() function will call the protected new() constructor to createa uvm_root object with handle name m_inst and return the handle to the calling code. All
subsequent calls to get() will just return the static m_inst handle value.

DVCon 2011
Rev 1.1

16

OVM & UVM Techniques
for Terminating Tests

17 static local uvm_root m_inst;
4

extern static function uvm_root get();28 function uvm_root uvm_root::get();29
if (m_inst == null)30
m_inst = new();
31
return m_inst;
32 endfunction
Example 6 - uvm_root code snippet - uvm_root construction

In the same uvm_root.svh file is a declaration for a const uvm_root uvm_top (a constanthandle of type uvm_root with handle name uvm_top) that calls uvm_root::get() in its
declaration.
41 const uvm_root uvm_top = uvm_root::get();Example 7 - uvm_root code snippet - const uvm_root uvm_top

This is how the uvm_top is created and it is all done by importing the uvm_pkg in the top-level
module and the construction of uvm_top happens right after simulation starts at time 0. uvm_top is
constructed before we even execute the UVM phases; in fact, the UVM phases are executed by calling
the run_test() method from this instance (object) of uvm_top. Now uvm_top is a fully
constructed object of type uvm_root, and it is now possible to call any uvm_root method (including
run_test()) just by using the uvm_top handle.
Consider the simple test module example in Example 8. After importing uvm_pkg, although we havenot directly called a constructor to create a uvm_top handle of type uvm_root, we can still call the
uvm_rocks() method (shown in Example 9) using the uvm_top handle.
module test;
import uvm_pkg::*; // import uvm base classes
initial begin
uvm_top.uvm_rocks();
end
endmodule
Example 8 - Simple test module example that calls the uvm_top.uvm_rocks() method

19
20
21

function void uvm_rocks ();$display("\n*** UVM rocks! - This is the future of verification! ***\n");endfunction
Example 9 - uvm_rocks() method definition

The uvm_rocks() method shown in Example 9 is our simple replacement for the ubiquitous Clanguage "hello world" example (which is so passé!)
DVCon 2011
Rev 1.1

17

OVM & UVM Techniques
for Terminating Tests

A more typical usage example is a top-level module that calls a run_test() method as shown in
Example 10.
module top;
import uvm_pkg::*; // import uvm base classes
initial begin
run_test();end
endmodule
Example 10 - Top module example with run_test() call

4.3 run_test()
The run_test() method is also defined in the uvm_root class. Most initial block calls to
run_test() do not reference this method with the uvm_top handle name. Why does this work?
Now examine the base/uvm_globals.svh
uvm_globals.svh file is shown in Example 11.

file.

An

abbreviatedversionofthe//-------------------------------------------------// Group: Simulation Control//-------------------------------------------------task run_test (string test_name="");
uvm_root top;
top = uvm_root::get();top.run_test(test_name);
endtaskfunction void global_stop_request();uvm_root top;
top = uvm_root::get();top.stop_request();endfunction
function void set_global_timeout(time timeout);
uvm_root top;
top = uvm_root::get();top.phase_timeout = timeout;
endfunction
function void set_global_stop_timeout(time timeout);
uvm_root top;
top = uvm_root::get();top.stop_timeout = timeout;
endfunction
Example 11 - Abbreviated base/uvm_globals.svh file

DVCon 2011
Rev 1.1

18

OVM & UVM Techniques
for Terminating Tests

The tasks and functions in the uvm_globals.svh file are also in the uvm_pkg, but they are not partof any class definition.
A call to run_test(), as shown in Example 10, calls the run_test() task defined in Example 11.
The run_test() task declares a handle called top of the uvm_root class type. Then the
uvm_root::get() method is called, which will return the local static uvm_root handle,
m_inst, and store it into the top handle declared in the task (the uvm_root::get() method
ensures that only one uvm_root object will ever be created), and using the top handle, the local
run_test() calls the top.run_test() method in the uvm_top object, which starts up all theUVM simulation phases.
The uvm_globals.svh file also contains the set_global_timeout()
set_global_stop_timeout() methods, which will be discussed in section 6.1.

and

As a side note, although not shown in the abbreviated version of the uvm_globals.svh file in
Example 11, the uvm_globals.svh file also contains the UVM standard message commands:
uvm_report_info(),
uvm_report_warning(),
uvm_report_error()anduvm_report_fatal(). These commands are also available anywhere the uvm_pkg routines havebeen imported.
As an additional side note, the uvm_pkg also indirectly includes the uvm_message_definse.svh
file from the src/macros/ directory that contains the definitions for all of the recommended`uvm_info/fatal*() macros, which automatically add file and line numbers to the reported
messages.
These
macrosare
typically
recommendedasreplacementsfortheuvm_report_info/fatal*() messaging commands because they do include the file and line
numbers in the reported messages to assist in debugging.
To summarize what has been discussed in this section, import uvm_pkg::*; creates the uvm_top
top-level testbench object and includes important global commands including: run_test(),global_stop_request(), set_global_timeout(), set_global_phase_timeout().
Users of the uvm_pkg have access to these commands and more without being required to construct
any class objects.

DVCon 2011
Rev 1.1

19

OVM & UVM Techniques
for Terminating Tests

5. HOW UVM SIMULATIONS RUN
As mentioned in the previous section, the run_test() command starts all of the UVM phases. Thissection gives more details on what happens when simulations run.

5.1 Choosing A Test To Run
The run_test() command must be passed a valid test name that has been registered in the UVM
factory. There are two ways to pass a valid test name to the run_test() command, (1) coded into the
top module or (2) passed to the UVM testbench through the command line switch +UVM_TESTNAME.
The inline coded method passes the test name string as an argument to the run_test() method in the
top-level module, similar to what is shown below.
module top;...
initial begin
run_test("test1");...
end
endmodule
Example 12 - run_test command with test name

The inline coded method is not typically recommended since it ties the testbench to a specific test that
requires the top module to be modified, recompiled and simulated for each new test.
The +UVM_TESTNAME command line switch is the preferred method for executing tests since thesimulation executable can be called with a new testname without the requirement to re-compile theentire testbench. Below is shown an example command line switch using Questa:
vsim -c -do "run -all" top +UVM_TESTNAME=test1
Example 13 - run_test test name passed by +UVM_TESTNAME command line option

5.2 Common +UVM_TESTNAME Errors
If no top-module run_test() argument is included in the top module, and if there is no+UVM_TESTNAME command line argument, UVM reports the error shown in Figure 6.

UVM_FATAL @ 0: reporter [NOCOMP] No components instantiated.
You must instantiate at least one component before calling run_test.
To run a test, use +UVM_TESTNAME or supply the test name in theargument to run_test(). Exiting simulation.
Figure 6 - UVM_FATAL - No components instantiated - missing test name

DVCon 2011
Rev 1.1

20

OVM & UVM Techniques
for Terminating Tests

If the run_test() test name argument included in the top module has not been registered in the
UVM factory, or if the +UVM_TESTNAME test name has not been registered in the UVM factory, thenUVM reports the error shown in Figure 7.
UVM_WARNING @ 0: reporter [BDTYP] Cannot create a component of type
'test2' because it is not registered with the factory.
UVM_FATAL@ 0: reporter [INVTST] Requested test from command line
+UVM_TESTNAME=test2 not found.
Figure 7 - UVM_FATAL - +UVM_TESTNAME not found - test not registered with the factory

5.3 Verilog-Style Testbench
Before looking at common UVM testbench styles, consider how Verilog verification engineers typicallybuild a testbench.
Verilog tasks are encapsulated, time-consuming subroutines that execute their code when called andreturn when done. The experienced Verilog verification engineer typically assembles a large number oftasks and then makes calls to the tasks from a Verilog testbench. The tasks are used as high levelcommands that either execute important Verilog testbench activity or are used to apply stimulus to, orcheck outputs from a Verilog DUT.
At the end of the test, after all of the testing tasks have run, the typical verification engineer terminates
the test with a call to $finish; as shown in Example 14.
module top;
import uvm_pkg::*;logic
clkgenck

clk;(clk);

initial begin
myrun_task();$finish;end
task myrun_task;`uvm_info("top","myrun_task running", UVM_LOW);#100ns;endtask
endmodule
Example 14 - Verilog style testbench with task call followed by $finish

Since the uvm_pkg was imported in Example 14, the top module has access to the UVM reporting
commands and macros, which happened to be called from the Verilog testbench myrun_task. Even
though the uvm_pkg was imported, it was not necessary to call the UVM run_test() command, so
none of the UVM phases were executed, including the final reporting phase, and the final output simply
shows that UVM_INFO was called and that the top module finished at time 100ns, as shown in Figure
8.
DVCon 2011
Rev 1.1

21

OVM & UVM Techniques
for Terminating Tests

UVM_INFO top.sv(23) @ 0: reporter [top] myrun_task running** Note: $finish: top.sv(19)Time: 100 ns Iteration: 0 Instance: /top
Figure 8 - Verilog style testbench output

5.4 Common New-User UVM Testbench Coding Mistake
Based on the previous Verilog coding style, the novice UVM verification engineer frequently tries to
use the Verilog style by calling the run_test() command followed immediately by calling a
global_stop_request() command, as shown in Example 15.
module top;
import uvm_pkg::*; // import ovm base classes
import tb_pkg::*; // import testbench classes
logic
clk;
clkgenck (clk);
Runs all UVM phases so
global_stop_request()
initial begin
run_test();will never executeglobal_stop_request();end
endmodule
Example 15 - BAD - top module with common mistake - global_stop_request() after run_test()

Engineers who assemble testing code as shown in Example 15 fail to understand that the run_test()
command will execute all of the UVM phases and the placement of the global_stop_request()
command immediately after the run_test() command is too late to be included in the execution of
any of the UVM phases. In this example, the only call to global_stop_request() is placed in the
top module, so the run_test() command will execute the requested run() phase test1 code,
shown in Example 16 , then keep executing simulation in the run() phase until simulation times out
with the error message shown in Figure 9.
class test1 extends uvm_test;`uvm_component_utils(test1)
env e;
function new (string name="test1", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;#100ns;endtask
endclassrun() task executes a 100ns
delay but does not include a
global_stop_request()
Example 16 - test1 with NO global_stop_request()

DVCon 2011
Rev 1.1

22

OVM & UVM Techniques
for Terminating Tests

UVM_INFO @ 0: reporter [RNTST] Running test test1...
UVM_ERROR @ 9200000000000: reporter [TIMOUT] Watchdog timeoutof '9200000000000' expired
Figure 9 - Test timeout - BAD global_stop_request() after run_test() command

The test1 code of Example 16 was run with the top module shown in Example 15, but since thetest1 code did not include a global_stop_request() command, and since theglobal_stop_request() command of the top module was never executed, test1 executed its
code and then the run() phase continued until the simulation timed-out.
Placement of a global_stop_request() command after a call to run_test() is a Verilog-likecoding style that does not work in UVM.
5.5 Proper Use of global_stop_request() Command
The proper use of the global_stop_request() command is to omit it from the top module asshown in Example 17, and to include the global_stop_request() command in the test code asshown in Example 18.
module top;
import uvm_pkg::*;import tb_pkg::*;logic
clkgenck

clk;(clk);

initial begin
run_test();end
endmodule
Example 17 - GOOD - top module with run_test() and NO global_stop_request()class test2 extends uvm_test;`uvm_component_utils(test2)
env e;
function new (string name="test2", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
run() task executes a 100ns
task run;delay but followed by a call to#100ns;global_stop_request()
global_stop_request();endtask
endclass
Example 18 - GOOD - test2 terminates with global_stop_request()

DVCon 2011
Rev 1.1

23

OVM & UVM Techniques
for Terminating Tests

The top module of Example 17 still includes the run_test() command, which is responsible for
initiating and executing all of the UVM phases.

Figure 10 - global_stop_request() terminates the run() phase and post-run() phases execute

After the test2 code of Example 18 terminates with global_stop_request(), the rest of the
post-run() phases will execute (as shown in Figure 10) and the full UVM report-output will be
displayed as shown in Figure 11.
UVM_INFO @ 0: reporter [RNTST] Running test test2...
--- UVM Report Summary --** Report counts by severity
UVM_INFO :1
UVM_WARNING :0
UVM_ERROR :0
UVM_FATAL :0** Report counts by id[RNTST]
1** Note: $finish ...
Time: 100 ns ...
Figure 11 - UVM report output after proper termination of the run() phase using call to global_stop_request()

DVCon 2011
Rev 1.1

24

OVM & UVM Techniques
for Terminating Tests

If the global_stop_request() command in the test code is replaced with the Verilog $finish
command as shown in Example 19, the simulation will abort in the middle of the run() phase and thepost-run() phases will not execute as shown in Figure 12. Since the UVM phases abort in the middleof the run() phase, no final UVM reports will be printed as can be seen in the resultant output in
Figure 13.
class test2a extends uvm_test;`uvm_component_utils(test2a)
env e;
function new (string name="test2a", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;#100ns;$finish;endtask
endclass
Example 19 - Bad - test2a terminates with $finish; - run() phase aborts early

Figure 12 - $finish command causes the run() phase to abort and post-run() phases never execute

DVCon 2011
Rev 1.1

25

OVM & UVM Techniques
for Terminating Tests

UVM_INFO @ 0: reporter [RNTST] Running test test2a...
** Note: $finish: test2a.sv ...
Time: 100 ns Instance: /uvm_pkg::uvm_root::m_do_phase
Figure 13 - $finish; causes simulation to abort run() phase - no final reports printed

In Figure 13, there is no UVM Report Summary because the post-run() report() phase was never
executed.

DVCon 2011
Rev 1.1

26

OVM & UVM Techniques
for Terminating Tests

6. HOW UVM SIMULATIONS STOPUVM has a number of important, built-in global simulation and control commands to set timeouts and toterminate the run() phase. Descriptions of these UVM commands can be found in the UVM Class
Reference manual[10] (also in the OVM Class Reference manual[7]).
run_test() - is a commonly used convenience function (as described in section 4.3) that calls
uvm_top.run_test(). It is used to start the execution of the specified test.

global_stop_request() - is a commonly used convenience function that calls
uvm_top.stop_request(). It is used to terminate the Active Stage if there are no raised
objections (see Objections-Raised Threads in section 3.3.3).
set_global_timeout() - is a convenience function that calls uvm_top.phase_timeout =timeout.
set_global_stop_timeout()is a convenience function that calls uvm_top.stop_timeout= timeout.
The basic UVM simulation termination command is the global_stop_request() call as
previously shown in Example 18.
Two other ways to terminate simulations are timeouts and a combination of raised-objections and stopinterrupts.

6.1 Timeouts
When the run() phase starts, a parallel timeout timer is also started. If the timeout timer reaches one of
the specified timeout limits before the run() phase completes, the run() phase will timeout and:All run() tasks will be immediately disabled.
1. A timeout message will be issued.
2. Execution of the post-run() phases will begin.

There are two timeout counters that may become active during the run() phase and their timeout limits
are kept in the variables uvm_top.phase_timeout and uvm_top.stop_timeout.
The phase_timeout is the time that the entire run() phase (Active Stage and Stop-Interrupt Stage)is allowed to run before timing out. The phase_timeout is often referred to as theglobal_timeout limit as shown in Figure 14. If the phase_timeout time limit is reached, a
UVM_ERROR will be reported.
DVCon 2011
Rev 1.1

27

OVM & UVM Techniques
for Terminating Tests

The default value for the phase_timeout limit is set from the `UVM_DEFAULT_TIMEOUT macroand has a default timeout value of 9200 seconds. This value can be shortened by using the
set_global_timeout() command.
As part of the run() phase, various components of a test might execute stop() tasks in the StopInterrupt Stage. The maximum execution time of the stop() tasks is stored in the stop_timeout
limit and can be controlled by the set_global_stop_timeout() command. The default
stop_timeout value is also 9200 seconds. The stop_timeout is often referred to as theglobal_stop_timeout limit as shown in Figure 14.

Figure 14 - run() phase execution flow diagram (with timeouts)

DVCon 2011
Rev 1.1

28

OVM & UVM Techniques
for Terminating Tests

6.2 Stop-Interrupt Enabled Example
The test3 code in Example 20 demonstrates the use of the enable_stop_interrupt bit and alocal stop() task.
A test or component (thread) can interrupt the scheduled stopping of the run() phase by setting theenable_stop_interrupt bit at the beginning of the run() task in the test. Any thread that sets
this bit should also override the default stop() task with functionality that shall be executed in the
Stop-Interrupt Stage before this run() phase finishes.
The run() task in test3, shown in Example 20, has set the enable_stop_interrupt bit. Any
thread that has this bit set will run the stop() task after a stop_request is called. Wheneverenable_stop_interrupt=1, the same thread typically includes a local stop() task that has
important commands that should be executed before the end of the simulation, and these commands
typically take additional simulation time before the run() phase is allowed to finish.
When test3 runs, the following sequence of actions will be executed:
run() phase starts at time 0ns (start of Active Stage).
test3 executes:• run() task (starts running at time 0ns)
• enable_stop_interrupt bit will be set (indicates that the test3 stop() task
should interrupt and execute its code before the end of the run() phase.
• Delays for 100ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 100ns):• print a "stop task running" message.
• delays for 100ns.
• print a "stop task done" message.
run() phase finishes at time 200ns (end of both Stop-Interrupt Stage and run() phase).
class test3 extends uvm_test;`uvm_component_utils(test3)
env e;
function new (string name="test3", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;enable_stop_interrupt = '1;#100ns;global_stop_request();

DVCon 2011
Rev 1.1

29

OVM & UVM Techniques
for Terminating Tests

endtask
task stop (string ph_name);`uvm_info("test3", "stop task running ...", UVM_LOW);#100ns;`uvm_info("test3", "stop task done", UVM_LOW);
endtask
endclass
Example 20 - test3 with enabled stop() task

The printed messages and test3 UVM Report summary are shown in Figure 15. The first printed
message came from the run_test() command itself, the next two printed messages came from thestop() task in Example 20, and the UVM Report Summary came from the UVM report() phase at
the end of the simulation.
UVM_INFO @ 0: reporter [RNTST] Running test test3...
UVM_INFO test3.sv(33) @ 100: uvm_test_top [test3] stop task running ...
UVM_INFO test3.sv(35) @ 200: uvm_test_top [test3] stop task done--- UVM Report Summary --** Report counts by severity
UVM_INFO :3
UVM_WARNING :0
UVM_ERROR :0
UVM_FATAL :0** Report counts by id[RNTST]1[test3]
2** Note: $finish ...
Time: 200 ns ...
Figure 15 - test3 UVM reported output

The test in Example 20 executed the run() task code in the Active Stage of the run() phase, while
the stop() task code executed in the Stop-Interrupt Stage of the run() phase as shown in Figure 16.

Figure 16 - (1) run() phase - Active Stage and Stop-Interrupt Stage

DVCon 2011
Rev 1.1

30

OVM & UVM Techniques
for Terminating Tests

6.3 Stop_Timeout Example
The test4 code in Example 22 demonstrates the use of the set_global_stop_timeout()
command in the top-level module and the stop() task timing out during execution of code during the
Stop-Interrupt Stage.
The top module in Example 21 has issued the set_global_stop_timeout(50ns) command,
which means that if any thread executes code during the Stop-Interrupt Stage, the code must complete inless than 50ns otherwise a Stop-request timeout warning will be reported. test4 will exceed thestop_timeout limit and the warning will be reported.
As was done in the Stop-Interrupt Enabled example, the run() task in test4, shown in Example 22,
has set the enable_stop_interrupt bit and a local stop() task includes a pair of
uvm_report_info commands separated by a 100ns delay.
When test4 runs, the following sequence of actions will be executed:
top module executes (starts running at time 0ns):• initial block starts.
• Call the set_global_stop_timeout(50ns) command.
• Call the run_test() command.
run() phase starts at time 0ns (start of Active Stage).
test4 executes:• run() task (starts running at time 0ns)
• enable_stop_interrupt bit will be set.
• Delays for 100ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 100ns):• print a "stop task running" message.
• delays for 100ns.
• UVM_WARNING - Stop-request timeout (reported at 150ns)
run() phase times out at time 150ns (terminates both Stop-Interrupt Stage and run() phase).
module top;
import uvm_pkg::*;import tb_pkg::*;logic
clkgenck

clk;(clk);

initial begin
set_global_stop_timeout(50ns);
end
initial begin
run_test();end
endmodule
Example 21 - top module - set_global_stop_timeout()

DVCon 2011
Rev 1.1

31

OVM & UVM Techniques
for Terminating Tests

class test4 extends uvm_test;`uvm_component_utils(test4)
env e;
function new (string name="test4", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;enable_stop_interrupt = '1;#100ns;global_stop_request();endtasktask stop (string ph_name);
uvm_report_info("test4", "stop task running ...");#100ns;
uvm_report_info("test4", "stop task done");endtask
endclass
Example 22 - test4 - stop() task timeout

The printed messages are shown in Figure 17 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came from thestop() task in Example 22, and the UVM_WARNING timeout message came from the phase execution
mechanism in uvm_root. The UVM Report Summary (not shown) came from the UVM report()
phase at the end of the simulation.
UVM_INFO @ 0: reporter [RNTST] Running test test4...
UVM_INFO @ 100: uvm_test_top [test4] stop task running ...
UVM_WARNING @ 150: reporter [STPTO] Stop-request timeoutof 50 expired. Stopping phase 'run'
Figure 17 - test4 UVM report output after Stop-request timeout

The test4 example executed the run() task code in the Active Stage and the stop() task code in
the Stop-Interrupt Stage before ending early with a UVM stop_timeout warning also executed in the
Stop-Interrupt Stage.

DVCon 2011
Rev 1.1

32

OVM & UVM Techniques
for Terminating Tests

6.4 Global_Timeout Example
The test5 code in Example 24 demonstrates the use of the set_global_stop_timeout()
command in the top-level module and the stop() task timing out during execution of code during the
Stop-Interrupt Stage.
The top module in Example 23 has issued the set_global_stop_timeout(100ns) command,
which means that if any thread executes code during the Stop-Interrupt Stage, the code must complete inless than 100ns otherwise a Stop-request timeout warning will be reported. The top module also issued
the set_global_timeout(550ns) command, which means that all the code must complete in lessthan 550ns otherwise a watchdog timeout (global_timeout) error will be reported. test5 will exceed
the global_timeout limit and the error will be reported.
When test5 runs, the following sequence of actions will be executed:
top module executes (starts running at time 0ns):• initial block starts.
• Call the set_global_stop_timeout(100ns) command.
• Call the set_global_timeout(550ns) command.
• Call the run_test() command.
run() phase starts at time 0ns (start of Active Stage).
test5 executes:• run() task (starts running at time 0ns)
• enable_stop_interrupt bit will be set.
• Delays for 500ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 500ns):• print a "stop task running" message.
• delays for 200ns.
• UVM_ERROR - global_timeout (reported at 550ns)
run() phase times out at time 550ns (terminates both Stop-Interrupt Stage and run() phase).
module top;
import uvm_pkg::*;import tb_pkg::*;logic
clkgenck

clk;(clk);

initial begin
set_global_stop_timeout(100ns);
set_global_timeout(550ns);
end
initial begin
run_test();end
endmodule
Example 23 - top module - set_global_stop_timeout() & set_global_timeout()

DVCon 2011
Rev 1.1

33

OVM & UVM Techniques
for Terminating Tests

class test5 extends uvm_test;`uvm_component_utils(test5)
env e;
function new (string name="test5", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;enable_stop_interrupt = '1;#500ns;global_stop_request();endtasktask stop (string ph_name);`uvm_info("test5", "stop task running ...", UVM_LOW);#200ns;`uvm_info("test5", "stop task done", UVM_LOW);
endtask
endclass
Example 24 - test5 - times out due to set_global_timeout() set to 550ns

The printed messages are shown in Figure 18 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came from thestop() task in Example 24, and the UVM_ERROR timeout message came from the phase execution
mechanism in uvm_root.

UVM_INFO @ 0: reporter [RNTST] Running test test5...
UVM_INFO test5.sv(32) @ 500: uvm_test_top [test5] stop task running ...
UVM_ERROR @ 550: reporter [TIMOUT] Watchdog timeout of '550' expired.
Figure 18 - test5 UVM report output after Watchdog (global) timeout

The test5 example executed the run() task code in the Active Stage and the stop() task code in
the Stop-Interrupt Stage before ending early with a UVM global_timeout error also executed in the
Stop-Interrupt Stage.

DVCon 2011
Rev 1.1

34

OVM & UVM Techniques
for Terminating Tests

6.5 Delayed Global_Timeout Example
The test6 code in Example 26 demonstrates the use of the set_global_stop_timeout()
command in the top-level module when the run_test() command startup is delayed in the top
module.
The top module in Example 25 has issued the set_global_stop_timeout(100ns) and
set_global_timeout(550ns) commands. In this example, the top module delays for 100ns
before issuing the run_test() command, which means that all the code must complete in less than
100ns + 550ns otherwise a watchdog timeout (global_timeout) error will be reported. test6 will
exceed the global_timeout limit and the error will be reported at time 650ns.
When test6 runs, the following sequence of actions will be executed:
top module executes (starts running at time 0ns):• initial block starts.
• Call the set_global_stop_timeout(100ns) command.
• Call the set_global_timeout(550ns) command.
• Delay for 100ns then call the run_test() command.
run() phase starts at time 100ns (start of Active Stage).
test6 executes:• run() task (starts running at time 100ns)• enable_stop_interrupt bit will be set.
• Delays for 500ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 600ns):• print a "stop task running" message.
• delays for 200ns.
• UVM_ERROR - global_timeout (reported at 650ns)
run() phase times out at time 650ns (terminates both Stop-Interrupt Stage and run() phase).
module top;
import uvm_pkg::*;import tb_pkg::*;logic
clkgenck

clk;(clk);

initial begin
set_global_stop_timeout(100ns);
set_global_timeout(550ns);
end
initial begin#100ns run_test();end
endmodule
Example 25 - top module - set_global_stop_timeout(), set_global_timeout() and delayed startup

DVCon 2011
Rev 1.1

35

OVM & UVM Techniques
for Terminating Tests

class test6 extends uvm_test;`uvm_component_utils(test6)
env e;
function new (string name="test6", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;enable_stop_interrupt = '1;#500ns;global_stop_request();endtasktask stop (string ph_name);`uvm_info("test6", "stop task running ...", UVM_LOW);#200ns;`uvm_info("test6", "stop task done", UVM_LOW);
endtask
endclass
Example 26 - test6 with run() and stop() tasks

The printed messages are shown in Figure 19 (UVM Report summary not shown). The first printed
message came from the run_test() command itself at time 100ns, the next printed message came
500ns later from the stop() task in Example 26, and the UVM_ERROR timeout message came from thephase execution mechanism in uvm_root at time 650ns.

UVM_INFO @ 100: reporter [RNTST] Running test test6...
UVM_INFO test6.sv(32) @ 600: uvm_test_top [test6] stop task running ...
UVM_ERROR @ 650: reporter [TIMOUT] Watchdog timeout of '550' expired.
Figure 19 - test6 UVM report output after Watchdog (global) timeout

The test6 example did not start the run() phase and global_timeout counter until 100ns into thesimulation, then test6 executed the run() task code in the Active Stage and the stop() task codein the Stop-Interrupt Stage before ending early with a UVM global_timeout error also executed in the
Stop-Interrupt Stage.

DVCon 2011
Rev 1.1

36

OVM & UVM Techniques
for Terminating Tests

6.6 run() Task Sets Timeout Value Example
The test7 code in Example 28 demonstrates the use of the set_global_stop_timeout() andthe set_global_timeout() commands in the run() task of the test7 code instead of in the
top-level module.
The top module in Example 27 is a simple top module with no timeout settings and no startup delays.
The
test7
code
has
issuedthe
set_global_stop_timeout(100ns)
andset_global_timeout(550ns) commands in the run() task. The problem with setting the
global_timeout in the run() task is that the timeout must be set before starting the run() taskotherwise the global_timeout will not work, which is what happens in this test. After the simulation
passes the 550ns time without a global_timeout, it will trigger the stop_timeout, which can be set fromthe run() task.

When test7 runs, the following sequence of actions will be executed:
run() phase starts at time 0ns (start of Active Stage).
test7 executes:• run() task (starts running at time 0ns)
• Call the set_global_stop_timeout(100ns) command.
• Call the set_global_timeout(550ns) command (TOO LATE!)• Set the enable_stop_interrupt bit.
• Delays for 500ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 500ns):• print a "stop task running" message.
• delays for 200ns.
• UVM_WARNING - stop_timeout (reported at 600ns)
run() phase times out at time 600ns (terminates both Stop-Interrupt Stage and run() phase).
module top;
import uvm_pkg::*;import tb_pkg::*;logic
clkgenck

clk;(clk);

initial begin
run_test();end
endmodule
Example 27 - Simple top module used for testing - no timeout values set and no startup delays

DVCon 2011
Rev 1.1

37

OVM & UVM Techniques
for Terminating Tests

class test7 extends uvm_test;`uvm_component_utils(test7)
env e;
function new (string name="test7", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;
set_global_stop_timeout(100ns);
set_global_timeout(550ns);
enable_stop_interrupt = '1;#500ns;global_stop_request();endtasktask stop (string ph_name);`uvm_info("test7", "stop task running ...", UVM_LOW);#200ns;`uvm_info("test7", "stop task done", UVM_LOW);
endtask
endclass
Example 28 - BAD: test7 with & set_global_timeout() set in the run() task - too late

The printed messages are shown in Figure 20 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came 500ns later fromthe stop() task in Example 28, and the UVM_WARNING timeout message came from the phase
execution mechanism in uvm_root at time 600ns.

UVM_INFO @ 0: reporter [RNTST] Running test test7...
UVM_INFO test7.sv(34) @ 500: uvm_test_top [test7] stop task running ...
UVM_WARNING @ 600: reporter [STPTO] Stop-request timeoutof 100 expired. Stopping phase 'run'
Figure 20 - test7 UVM report output after Stop-request timeout

The test7 example shows that the global_timeout limit must be set before executing the run() task,otherwise the setting will be too late and the global timeout counter will not start.

DVCon 2011
Rev 1.1

38

OVM & UVM Techniques
for Terminating Tests

6.7 build() Phase Sets Global_Timeout Value Example
The test8 code in Example 29 demonstrates the use of the the set_global_timeout()
command in the build() method of the test8 code instead of in the run() task.
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The test8 code has issued the set_global_stop_timeout(100ns) command in the run()task and has issued the set_global_timeout(550ns) command in the build() method.
Although this coding style is not recommended, setting the global_timeout in the build() method
allows the setting to be active before executing the run() task; hence, the setting will be active. Afterthe simulation reaches the 550ns time the global_timeout, will trigger as expected.
When test8 runs, the following sequence of actions will be executed:

test8 executes:
build() phase starts at time 0ns.
• Call the set_global_timeout(550ns) command (ACTIVE!)
run() phase starts at time 0ns (start of Active Stage).
• run() task (starts running at time 0ns)
• Call the set_global_stop_timeout(100ns) command.
• Set the enable_stop_interrupt bit.
• Delays for 500ns.
• Call the global_stop_request() command (causes end of Active Stage and startof Stop-Interrupt Stage) .
• stop() task (starts running at time 500ns):• print a "stop task running" message.
• delays for 200ns.
• UVM_ERROR - stop_timeout (reported at 550ns)
run() phase times out at time 550ns (terminates both Stop-Interrupt Stage and run() phase).

DVCon 2011
Rev 1.1

39

OVM & UVM Techniques
for Terminating Tests

class test8 extends uvm_test;`uvm_component_utils(test8)
env e;
function new (string name="test8", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
set_global_timeout(550ns);
endfunction
task run;
set_global_stop_timeout(100ns);
enable_stop_interrupt = '1;#500ns;global_stop_request();endtasktask stop (string ph_name);`uvm_info("test8", "stop task running ...", UVM_LOW);#200ns;`uvm_info("test8", "stop task done", UVM_LOW);
endtask
endclass
Example 29 - test8 with set_global_timeout() set in the build() method - stop-timeout is active

The printed messages are shown in Figure 21 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came 500ns later fromthe stop() task in Example 29, and the UVM_ERROR timeout message came from the phase execution
mechanism in uvm_root at time 550ns.

UVM_INFO @ 0: reporter [RNTST] Running test test8...
UVM_INFO test8.sv(34) @ 500: uvm_test_top [test8] stop task running ...
UVM_ERROR @ 550: reporter [TIMOUT] Watchdog timeout of '550' expired.
Figure 21 - test8 UVM report output after Watchdog (global) timeout

The test8 example shows that the global_timeout limit can be properly set in the build() phase,before executing the run() task in the run() phase. Although this style works, this is not necessarilya recommended coding style.

DVCon 2011
Rev 1.1

40

OVM & UVM Techniques
for Terminating Tests

6.8 Raising And Dropping Objections Example
The test9 code in Example 30 demonstrates the raising and dropping of objections in the run() taskusing the uvm_test_done.raise_objection() / uvm_test_done.drop_objection()commands respectively.
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The
test9
code
has
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in the run() task. Once an objection is raised,
all objections must be dropped before an implicit global_stop_request() will force the Active
Stage to complete. In test9, there is only one raised objection so once that objection is dropped, theActive Stage finishes.
When test9 runs, the following sequence of actions will be executed:
test9 executes:
run() phase starts at time 0ns (start of Active Stage).
• run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 500ns.
• Call the uvm_test_done.drop_objection() command. All objections havebeen dropped because there was only one objection (causes implicit call to
global_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• No active stop() task (starts running at time 500ns):run() phase finishes at time 500ns (end of both Stop-Interrupt Stage and run() phase).
class test9 extends uvm_test;`uvm_component_utils(test9)
env e;
function new (string name="test9", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;
uvm_test_done.raise_objection();#500ns;
uvm_test_done.drop_objection();endtask
endclass
Example 30 - test9 with raise_objection()/drop_objection() to terminate the test

DVCon 2011
Rev 1.1

41

OVM & UVM Techniques
for Terminating Tests

The printed messages are shown in Figure 22 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came 500ns later andis the TEST_DONE message, which shows that the dropping of all objections has forced an implicit callto the global_stop_request() command.

UVM_INFO @ 0: reporter [RNTST] Running test test9...
UVM_INFO @ 500: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Calling global_stop_request()
Figure 22 - test9 UVM report output after all objections were dropped

The test9 example shows that after all objections have been dropped that there is an implicit call to
the global_stop_request() command, which will terminate the Active Stage of the run()phase.
Later tests will show that any active Objections-Raised threads will take control of when the Active
Stage completes.

DVCon 2011
Rev 1.1

42

OVM & UVM Techniques
for Terminating Tests

6.9 Raising And Dropping Multiple Objections Example
The test10 code in Example 31 demonstrates the raising and dropping of objections from different
components. Example 31 includes the code for the test10 test and a testbench environment
component (env).
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The
test10code
has
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in the run() task. The environment env
component
has
also
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in its local copy of the run() task. Once an
objection is raised, all objections must be dropped before an implicit global_stop_request()
will force the Active Stage to complete. The test10 run() task drops its objection at time 500ns,
while the env run() task drops its objection at 700ns. The last dropped objection happens at time
700ns so that is when the Active Stage finishes. It is not necessarily recommended to override therun() task in the environment component, but since uvm_env is derived from the uvm_component
class, it is possible to add a run() task to the environment.

When test10 runs, the following sequence of actions will be executed:
test10 executes:
run() phase starts at time 0ns (start of Active Stage).
• test10 run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 500ns.
• Calls the uvm_test_done.drop_objection() command at 500ns.
• env run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 700ns.
• Calls the uvm_test_done.drop_objection() command at 700ns.
• All
objections
have
now
been
dropped(causes
implicit
calltoglobal_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• No active stop() task (starts running at time 700ns):run() phase finishes at time 700ns (end of both Stop-Interrupt Stage and run() phase).

DVCon 2011
Rev 1.1

43

OVM & UVM Techniques
for Terminating Tests

class env extends uvm_env;`uvm_component_utils(env)function new (string name, uvm_component parent=null);super.new(name, parent);
endfunction
task run;
uvm_test_done.raise_objection();#700ns;
uvm_test_done.drop_objection();endtask
endclassclass test10 extends uvm_test;`uvm_component_utils(test10)
env e;
function new (string name="test10", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;
uvm_test_done.raise_objection();#500ns;
uvm_test_done.drop_objection();endtask
endclass
Example 31 - test10 & env with raise_objection()/drop_objection() - last drop ends test

The printed messages are shown in Figure 23 (UVM Report summary not shown). The first printed
message came from the run_test() command itself, the next printed message came 700ns later andis the TEST_DONE message, which shows that the dropping of all objections has forced an implicit callto the global_stop_request() command.

UVM_INFO @ 0: reporter [RNTST] Running test test10...
UVM_INFO @ 700: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Calling global_stop_request()
Figure 23 - test10 UVM report output after all objections were dropped

The test10 example shows that after all objections have been dropped that there is an implicit call to
the global_stop_request() command, which will terminate the Active Stage of the run()phase.
DVCon 2011
Rev 1.1

44

OVM & UVM Techniques
for Terminating Tests

6.10 Multiple Objections And forever-Loop Example
The test11 code in Example 33 demonstrates the raising and dropping of objections from different
components and how they interact with another component that is executing forever-loop code aanother run() task. Example 32 includes the code for a testbench driver component (tb_driver)and Example 33 includes the code for the test11 test and environment component (env).
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The
test11code
has
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in the run() task. The environment env
component
has
also
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in its local copy of the run() task. The
testbench driver tb_driver has a run() task that is executing a forever loop, but has no
objections. Once an objection is raised, all objections must be dropped before an implicit
global_stop_request() will force the Active Stage to complete. The test11 run() task
drops its objection at time 500ns, while the env run() task drops its objection at 811ns. Dropping of
all objections has forced an implicit call to the global_stop_request() command at 811ns,
which does not require the tb_driver run() task to complete, so even though the tb_driver
run() task may continue to run, the Active Stage completes with the last dropped objection and theStop-Interrupt stage can now start. In test11, there are no enabled stop() tasks, so the run()phase finishes right after the Active Stage finishes.
When test11 runs, the following sequence of actions will be executed:
test11 executes:
run() phase starts at time 0ns (start of Active Stage).
• test11 run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 500ns.
• Calls the uvm_test_done.drop_objection() command at 500ns.
• tb_driver run() task (starts running at time 0ns)
• forever-loop cycles every 120ns and prints a repeating message. The forever-loop
keeps running until the run() phase finishes.
• env run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 811ns.
• Calls the uvm_test_done.drop_objection() command at 811ns.
• All
objections
have
now
been
dropped(causes
implicit
calltoglobal_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• No active stop() task (starts running at time 811ns):run() phase finishes at time 700ns (end of both Stop-Interrupt Stage and run() phase).

DVCon 2011
Rev 1.1

45

OVM & UVM Techniques
for Terminating Tests

class tb_driver extends uvm_driver;`uvm_component_utils(tb_driver)function new (string name, uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();
endfunction
task run();forever begin#120 `uvm_info("tb_driver", "driver run() loop", UVM_LOW);
end
endtasktask stop(string ph_name);`uvm_info("tb_driver", "start of stop task", UVM_LOW);#1000 `uvm_info("tb_driver", "endof stop task", UVM_LOW);
endtask
endclass
Example 32 - test11 - tb_driver with forever loop (loop will be cancelled when all objections are dropped)class env extends uvm_env;`uvm_component_utils(env)tb_driver drv;function new (string name, uvm_component parent=null);super.new(name, parent);
drv = tb_driver::type_id::create("drv", this);
endfunction
task run;
uvm_test_done.raise_objection();#811ns uvm_test_done.drop_objection();endtask
endclassclass test11 extends uvm_test;`uvm_component_utils(test11)
env e;
function new (string name="test11", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;
uvm_test_done.raise_objection();#500ns uvm_test_done.drop_objection();endtask
endclass
Example 33 - test11 - env and test11 raise and drop objections

DVCon 2011
Rev 1.1

46

OVM & UVM Techniques
for Terminating Tests

The printed messages are shown in Figure 24 (UVM Report summary not shown). The first printed
message came from the run_test() command itself. The next six printed messages came at 120ns
intervals from the tb_driver component. The next printed message came 811ns after the start of the
Active Stage and is the TEST_DONE message, which shows that the dropping of all objections has
forced an implicit call to the global_stop_request() command, even though the forever loop
continued to run.
UVM_INFO @ 0: reporter [RNTST] Running test test11...
UVM_INFO tb_driver.sv(25) @ 120: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 240: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 360: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 480: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 600: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 720: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO @ 811: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Calling global_stop_request()
Figure 24 - test11 UVM report output after all objections were dropped

The test11 example shows that after all objections have been dropped that there is an implicit call to
the global_stop_request() command, which will terminate the Active Stage of the run()phase, even if there was a forever loop running in another run() task.

6.11 Multiple Objections Then Stop-Interrupt Activity Example
The test12 code in Example 34 demonstrates the raising and dropping of objections from different
components and how they interact with another component that has another run() task that is
executing a forever-loop and an enabled stop() task in that same component. Example 34 includes
the code for the test12 test, a testbench driver component (tb_driver) and environment
component (env).
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The
test12code
hasissuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in the run() task. The environment env
component
has
also
issuedthe
uvm_test_done.raise_objection()/
uvm_test_done.drop_objection() commands in its local copy of the run() task. The
testbench driver tb_driver has a run() task that is executing a forever loop, but has no
objections. The same tb_driver also has an enabled stop() task that runs another 1,000ns before
returning. Once an objection is raised, all objections must be dropped before an implicit
global_stop_request() will force the Active Stage to complete. The test12 run() task
drops its objection at time 500ns, while the env run() task drops its objection at 811ns. Dropping of
all objections has forced an implicit call to the global_stop_request() command at 811ns,
DVCon 2011
Rev 1.1

47

OVM & UVM Techniques
for Terminating Tests

which does not require the tb_driver run() task to complete, so even though the tb_driver
run() task continues to run into the Stop-Interrupt Stage, the Active Stage completes with the last
dropped objection and the Stop-Interrupt stage can now start. In test12, there is an enabled stop()
task, so the run() phase does not finish until after the tb_driver stop() task has finished.
Throughout the Stop-Interrupt Stage, the forever loop continues to run and print its periodic
repeating message.
When test12 runs, the following sequence of actions will be executed:
test12 executes:
run() phase starts at time 0ns (start of Active Stage).
• test12 run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 500ns.
• Calls the uvm_test_done.drop_objection() command at 500ns.
• tb_driver run() task (starts running at time 0ns)
• forever-loop cycles every 120ns and prints a repeating message. The forever-loop
keeps running throughout the Stop-Interrupt Stage.
• stop() task (starts running at time 811ns).
• print a "start of stop task " message• Delays for 1,000ns.
• print an "end of stop task " message at 1,811ns.
• env run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 811ns.
• Calls the uvm_test_done.drop_objection() command at 811ns.
• All
objections
have
now
been
dropped(causes
implicit
calltoglobal_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• tb_driver stop() task (finishes at 1,811ns):run() phase finishes at time 1,811ns (end of both Stop-Interrupt Stage and run() phase).
class tb_driver extends uvm_driver;`uvm_component_utils(tb_driver)function new (string name, uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();
endfunction
task run();enable_stop_interrupt = '1;

DVCon 2011
Rev 1.1

48

OVM & UVM Techniques
for Terminating Testsforever begin#120 `uvm_info ("tb_driver", "driver run() loop", UVM_LOW);
end
endtasktask stop(string ph_name);`uvm_info("tb_driver", "start of stop task", UVM_LOW);#1000;`uvm_info("tb_driver", "endof stop task", UVM_LOW);
endtask
endclassclass env extends uvm_env;`uvm_component_utils(env)tb_driver drv;function new (string name, uvm_component parent=null);super.new(name, parent);
drv = tb_driver::type_id::create("drv", this);
endfunction
task run;
uvm_test_done.raise_objection();#811ns;
uvm_test_done.drop_objection();endtask
endclassclass test12 extends uvm_test;`uvm_component_utils(test12)
env e;
function new (string name="test12", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;
uvm_test_done.raise_objection();#500ns;
uvm_test_done.drop_objection();endtask
endclass
Example 34 - test12 - tb_driver with cancelled forever loop but still executes stop() task

DVCon 2011
Rev 1.1

49

OVM & UVM Techniques
for Terminating Tests

The printed messages are shown in Figure 25 (UVM Report summary not shown). The first printed
message came from the run_test() command itself. The next six printed messages came at 120ns
intervals from the tb_driver component. The next printed message came 811ns after the start of the
Active Stage and is the TEST_DONE message, which shows that the dropping of all objections has
forced an implicit call to the global_stop_request() command, even though the forever loop
continued to run. The next message came from the tb_driver stop() task while the tb_driver
run() task continued to execute the forever loop. The next nine printed messages continued tocome at 120ns intervals from the tb_driver component, while the last printed message came fromthe tb_driver stop() task just before the Stop-Interrupt Stage finished.

UVM_INFO @ 0: reporter [RNTST] Running test test12...
UVM_INFO tb_driver.sv(26) @ 120: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 240: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 360: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 480: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 600: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 720: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO @ 811: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Calling global_stop_request()
UVM_INFO tb_driver.sv(31) @ 811: uvm_test_top.e.drv [tb_driver] start of stop task
UVM_INFO tb_driver.sv(26) @ 840: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 960: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1080: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1200: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1320: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1440: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1560: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1680: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(26) @ 1800: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(33) @ 1811: uvm_test_top.e.drv [tb_driver] end of stop task
Figure 25 - test12 UVM report output after all objections were dropped and stop() task completed

The test12 example shows that after all objections have been dropped that there is an implicit call to
the global_stop_request() command, which will terminate the Active Stage of the run()phase, even if there was a forever loop running in another run() task. It also shows that eventhough test12 entered the Stop-Interrupt Stage for the next 1,000ns, that the run() task foreverloop continued to run throughout the Stop-Interrupt stage. It can be seen that not all run() tasks haveto finish before the Stop-Interrupt Stage activity can commence.

DVCon 2011
Rev 1.1

50

OVM & UVM Techniques
for Terminating Tests

6.12 Dropped Objection And Early global_stop_request() Example
The test13 code in Example 36 demonstrates that the raising and dropping of even a single objection
will disable an Active Stage call to global_stop_request() from a run() task in the test.
Example 35 includes the code for a testbench driver component (tb_driver) and Example 36
includes the code for the test13 test and environment component (env).
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The environment env component has issued the uvm_test_done.raise_objection() /uvm_test_done.drop_objection() commands in its local copy of the run() task. The
test13 code has issued a global_stop_request()command in its run() task before the env
issued the drop objection command. The testbench driver tb_driver has a run() task that is
executing a forever loop, but has no objections. Once an objection is raised, all objections must be
dropped before an implicit global_stop_request() will force the Active Stage to complete. The
test13 call to global_stop_request() happened while there was an active raised objection, so
the test13 global_stop_request() command was effectively ignored until all objections
were dropped. In test13, there are no enabled stop() tasks, so the run() phase finishes right after
the Active Stage finishes.
When test13 runs, the following sequence of actions will be executed:
test13 executes:
run() phase starts at time 0ns (start of Active Stage).
• test13 run() task (starts running at time 0ns)
• Delays for 100ns.
• Calls the global_stop_request() command at 100ns (ignored)• tb_driver run() task (starts running at time 0ns)
• forever-loop cycles every 120ns and prints a repeating message. The forever-loop
keeps running throughout the Active Stage.
• env run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 811ns.
• Calls the uvm_test_done.drop_objection() command at 811ns.
• All
objections
have
now
been
dropped(causes
implicit
calltoglobal_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• No active stop() task (starts running at time 811ns):run() phase finishes at time 811ns (end of both Stop-Interrupt Stage and run() phase).

DVCon 2011
Rev 1.1

51

OVM & UVM Techniques
for Terminating Tests

class tb_driver extends uvm_driver;`uvm_component_utils(tb_driver)function new (string name, uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();
endfunction
task run();forever begin#120 `uvm_info("tb_driver", "driver run() loop", UVM_LOW);
end
endtask
endclass
Example 35 - test13 - tb_driver with forever loop (loop will be cancelled when all objections are dropped)class env extends uvm_env;`uvm_component_utils(env)tb_driver drv;function new (string name, uvm_component parent=null);super.new(name, parent);
drv = tb_driver::type_id::create("drv", this);
endfunction
task run;
uvm_test_done.raise_objection();#811ns;
uvm_test_done.drop_objection();endtask
endclassclass test13 extends uvm_test;`uvm_component_utils(test13)
env e;
function new (string name="test13", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;#100ns;global_stop_request();endtask
endclass
Example 36 - test13 - global_stop_request() ignored until env drops objections

DVCon 2011
Rev 1.1

52

OVM & UVM Techniques
for Terminating Tests

The printed messages are shown in Figure 26 (UVM Report summary not shown). The first printed
message came from the run_test() command itself. The next six printed messages came at 120ns
intervals from the tb_driver component. The next printed message came 811ns after the start of the
Active Stage and is the TEST_DONE message, which shows that the dropping of all objections has
forced an implicit call to the global_stop_request() command, even though the forever loop
continued to run. NOTE: there was a call to global_stop_request() at 100ns, but the command
was ignored until all objections were dropped. The final message makes reference to the "Previous callto global_stop_request()," which is "now (being) honored."

UVM_INFO @ 0: reporter [RNTST] Running test test13...
UVM_INFO tb_driver.sv(25) @ 120: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 240: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 360: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 480: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 600: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 720: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO @ 811: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Previous call to global_stop_request() will now be honored.
Figure 26 - test13 UVM report output after all objections were dropped

The test13 example shows that explicit calls to global_stop_request() are ignored if there
are any raised objections. Only after all objections have been dropped is there an implicit call to theglobal_stop_request() command, which will terminate the Active Stage of the run() phase.
6.13 Dropped Objection And Late global_stop_request() Example
The test14 code in Example 38 demonstrates that the raising and dropping of even a single objection
will disable any future call to global_stop_request() from a run() task in the test. Example
37 includes the code for a testbench driver component (tb_driver) and Example 38 includes the codefor the test14 test and environment component (env).
The top module used for this test is the same simple top module used with test7 (shown in Example
27).
The environment env component has issued the uvm_test_done.raise_objection() /uvm_test_done.drop_objection() commands in its local copy of the run() task. The
test14 code has issued a global_stop_request()command in its run() task after the env
issued the drop objection command. The testbench driver tb_driver has a run() task that is
executing a forever loop, but has no objections. Once an objection is raised, all objections must be
dropped before an implicit global_stop_request() will force the Active Stage to complete. The
test14 call to global_stop_request() happened after there was an active raised objection, so
DVCon 2011
Rev 1.1

53

OVM & UVM Techniques
for Terminating Tests

the test14 global_stop_request() command was never executed. In test14, there are no
enabled stop() tasks, so the run() phase finishes right after the Active Stage finishes.

When test14 runs, the following sequence of actions will be executed:

test14 executes:
run() phase starts at time 0ns (start of Active Stage).
• test14 run() task (starts running at time 0ns)
• Delays for 1,000ns.
• Calls the global_stop_request() command at 1,000ns (too late - run() phasehas already completed)• tb_driver run() task (starts running at time 0ns)
• forever-loop cycles every 120ns and prints a repeating message. The forever-loop
keeps running throughout the Active Stage.
• env run() task (starts running at time 0ns)
• Call the uvm_test_done.raise_objection() command.
• Delays for 811ns.
• Calls the uvm_test_done.drop_objection() command at 811ns.
• All
objections
have
now
been
dropped(causes
implicit
calltoglobal_stop_request()), which causes the end of the Active Stage and start ofStop-Interrupt Stage) .
• No active stop() task (starts running at time 811ns):run() phase finishes at time 811ns (end of both Stop-Interrupt Stage and run() phase).

class tb_driver extends uvm_driver;`uvm_component_utils(tb_driver)function new (string name, uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();
endfunction
task run();forever begin#120 `uvm_info("tb_driver", "driver run() loop", UVM_LOW);
end
endtask
endclass
Example 37 - test14 - tb_driver with forever loop (loop will be cancelled when all objections are dropped)

DVCon 2011
Rev 1.1

54

OVM & UVM Techniques
for Terminating Tests

class env extends uvm_env;`uvm_component_utils(env)tb_driver drv;function new (string name, uvm_component parent=null);super.new(name, parent);
drv = tb_driver::type_id::create("drv", this);
endfunction
task run;
uvm_test_done.raise_objection();#811ns uvm_test_done.drop_objection();endtask
endclassclass test14 extends uvm_test;`uvm_component_utils(test14)
env e;
function new (string name="test14", uvm_component parent);
super.new(name, parent);
endfunction
function void build;
super.build();e = env::type_id::create("e", this);
endfunction
task run;#1000ns global_stop_request();endtask
endclass
Example 38 - test14 - global_stop_request() comes too late after all objections dropped and is ignored

The printed messages are shown in Figure 27 (UVM Report summary not shown). The first printed
message came from the run_test() command itself. The next six printed messages came at 120ns
intervals from the tb_driver component. The next printed message came 811ns after the start of the
Active Stage and is the TEST_DONE message, which shows that the dropping of all objections has
forced an implicit call to the global_stop_request() command, even though the forever loop
continued to run. NOTE: there was a call to global_stop_request() at 1,000ns, but thecommand came after the run() phase had finished.
UVM_INFO @ 0: reporter [RNTST] Running test test14...
UVM_INFO tb_driver.sv(25) @ 120: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 240: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 360: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 480: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 600: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO tb_driver.sv(25) @ 720: uvm_test_top.e.drv [tb_driver] driver run() loop
UVM_INFO @ 811: uvm_test_done [TEST_DONE]
All end_of_test objections have been dropped.
Calling global_stop_request()
Figure 27 - test14 UVM report output after all objections were dropped

DVCon 2011
Rev 1.1

55

OVM & UVM Techniques
for Terminating Tests

The test14 example shows that after all objections have been dropped there is an implicit call to theglobal_stop_request() command, which will terminate the Active Stage of the run() phase.
7. SUMMARY & GUIDELINESThe UVM (and OVM) run() phase is composed of two stages: the Active Stage that runs
unconditionally, and the Stop-Interrupt Stage that executes conditionally if any
enable_stop_interrupt bits were set during the Active Stage.
There are three types of threads that can be started at the beginning of the Active Stage when the
run_test() command is executed. These threads are the Non-Stopping threads, Stop-Request threads
and Objections-Raised threads.
If there are any Objections-Raised threads, the global_stop_request() command is largely
ignored. For this reason, the global_stop_request() command is probably not the best way toterminate the Active Stage of the run() phase. All it takes is a single Objections-Raised thread toinvalidate all of the global_stop_request() commands in all of the Stop-Request threads. The
Stop-Request threads effectively become Non-Stopping threads if there are any active Objection-Raised
threads.
UVM testbench development follows a different coding pattern than the typical Verilog testbench style.
Understanding the differences will help the UVM verification engineer to successfully build efficient
UVM tests that gracefully terminate without timing out. To help build correct UVM testbenches, weoffer the following guidelines to successfully setup UVM tests that gracefully terminate.
Guideline: Do not use a $finish command in a UVM testbench. If executed, the $finish
command will abort the UVM run() phase and never execute the post-run() phases.
Guideline: Do not place any global_stop_request() or $finish command in the top module
after the run_test() command. The stop or finish command will never execute and the simulation
will either hang or timeout.
Guideline: In general, avoid using the global_stop_request() command. This command does
not work if any active objections have been raised and its apparent failure to terminate at the expect time
is a point of global_stop_confusion!
Guideline: Use uvm_test_done.raise_objection() / uvm_test_done.drop_objection()commands in all test and component run() tasks to control when that test or component has finished
its testing activity.
The next two guidelines only apply to OVM testbenches. UVM 1.0 best practices discourage use of theenable_stop_interrupt bit and stop() task. UVM 1.0 has multiple new run() phases toreplace the need for a stop-interrupt stage in the run() phase.
Guideline: When using the stop interrupt capabilities, set the enable_stop_interrupt bit at the
beginning of the run() task. Setting this bit will allow the run() phase to execute the Stop-Interrupt
Stage.
Guideline: Any test or component that sets the enable_stop_interrupt bit should also include astop() task to describe the testing activity that should be executed during the Stop-Interrupt Stage ofthe run() phase.
DVCon 2011
Rev 1.1

56

OVM & UVM Techniques
for Terminating Tests

UVM simulations rarely hang, but if the tests are improperly terminated, the simulations will run for avery long time and appear to be hung. A good test will never need to set either the phase_timeout or
stop_timeout limits. The test will properly execute and gracefully terminate on its own. If the simulation
run seems to be hanging, then the timeout limits can be added to check for a never-ending test.
Guideline: Do not call the set_global_timeout() command in the run() task (it is too late to
become active)
Guideline: Place the set_global_timeout() and set_global_stop_timeout()
commands in an initial block in the top module before calling the run_test() command.
Following these guidelines will help avoid frustration related to improper UVM test termination.
8. ACKNOWLEDGMENTS
Our thanks to our colleague Kelly Larson for sharing useful comments and feedback during thedevelopment of this paper. Also thanks to our colleague Mike Horn for sharing important information
related to the use of the run_test() command and new phase information related to the pending
UVM 1.0 release. Also thanks to Heath Chambers and Anders Nordstrom for corrections and commentsthat helped clarify ambiguities in the original paper.
9. REFERENCES[1]"IEEE Standard For SystemVerilog - Unified Hardware Design, Specification and Verification Language,"
IEEE Computer Society, IEEE, New York, NY, IEEE Std 1800-2009.
http://standards.ieee.org/findstds/standard/1800-2009.html[2]Mark Glasser, "Open Verification Methodology Cookbook", Springer, www.springeronline.com, 1st Edition.,
2009. ISBN: 978-1-4419-0967-1 Free downloadable PDF Version at: http://verificationacademy.mentor.com/content/open-verification-methodology-advanced-ovm-uvm-module[3]

Mentor Graphics Corp. 10 Dec 2010. EOT/Guide. http://uvm.mentor.com/mc/EOT/ovm_test_done[4]

Mentor Graphics Corp. 28 Feb 2011. UVM/OVM Methodology Cookbook.
http://uvm.mentor.com/uvm/EOT/Guide[5]

Mike Horn - personal communication.

[6]

Natural Docs - open-source documentation generator for multiple programming languages,
www.naturaldocs.org[7]

OVM Class Reference, Version 2.1.1, March 2010. In OVM source code:
ovm-2.1.1/OVM_Reference.pdf[8]

OVM 2.1.1 kit - includes OVM base class libraries - Free downloads - www.ovmworld.org (choose
Download).

[9]

ovm-2.1.1/src/base/ovm_root.svh - comments in the source code file.

[10] Universal Verification Methodology (UVM) 1.0 EA Class Reference, May 2010, Accellera, Napa, CA. In

UVM source code: uvm1.0ea/uvm_reference_guide_1.0_ea.pdf[11] Universal Verification Methodology (UVM) 1.0 Class Reference, February 2011, Accellera, Napa, CA.

www.accellera.org/home (choose Download UVM Reference Manual 1.0)
[12] UVM 1.0EA (Early Adopter) kit - includes UVM base class libraries - Free downloads - www.uvmworld.org(choose Download).

DVCon 2011
Rev 1.1

57

OVM & UVM Techniques
for Terminating Tests

[13] uvm1.0ea/src/base/uvm_root.svh - comments in the source code file.

10. AUTHOR & CONTACT INFORMATION
Cliff Cummings, President of Sunburst Design, Inc., is an independent EDA consultant and trainer with
29 years of ASIC, FPGA and system design experience and 19 years of SystemVerilog, synthesis andmethodology training experience.
Mr. Cummings has presented more than 100 SystemVerilog seminars and training classes in the past
eight years and was the featured speaker at the world-wide SystemVerilog NOW! seminars.
Mr. Cummings has participated on every IEEE & Accellera SystemVerilog, SystemVerilog Synthesis,
SystemVerilog committee, and has presented more than 40 papers on SystemVerilog & SystemVerilog
related design, synthesis and verification techniques.
Mr. Cummings holds a BSEE from Brigham Young University and an MSEE from Oregon State
University.
Sunburst Design, Inc. offers World Class Verilog & SystemVerilog training courses. For more
information, visit the www.sunburst-design.com web site.
Email address: cliffc@sunburst-design.com
Tom Fitzpatrick, Verification Technologist and Editor of Verification Horizons at Mentor Graphics.
Design and verification expert using SystemVerilog; developing, educating and writing about industry
standards.
Email address: top_fitzpatrick@mentor.com
An updated version of this paper can be downloaded from the web sites:www.sunburst-design.com/papers
11. Revisions
After the first publication of this paper, there have been updates to the following revisions. Each of thefollowing revision subsections describe the changes that were made to each revision.
11.1 Revision 1.1 (February 2011) - What Changed?
Minor typo corrections were made within the contents of the paper and the font sizes were made larger
than the fonts that were required with the original DVCon submission to make the paper easier to read.
In the example code, replaced calls to uvm_report_info() methods with calls to the recommended`uvm_info() macros, which automatically add file and line numbers to the reported messages.
Added more references to the fact that this version of the paper is based on UVM 1.0EA.
Added information that UVM source files are extracted automatically using NaturalDocs to create theUVM Reference Manual.
Added important phase-name / method-name information at the beginning of section 3.
Modified the final guidelines to reflect that UVM 1.0 now discourages the use of theenable_stop_interrupt bit and stop() task.
DVCon 2011
Rev 1.1

58

OVM & UVM Techniques
for Terminating Tests