SVA in a UVM Class-based Environment

by Ben Cohen, author, consultant, and trainer

INTRODUCTION use of scoreboarding, which is supported by the analysis

Verification can be defined as the check that the design ports. Though scoreboarding solves many verification
meets the requirements. How can this be achieved? tasks, SystemVerilog Assertions (SVA) provide another
Many verification approaches have been used over the complementary and supporting set of solutions that can
years, and those are not necessarily independent, but speed up the verification and model building processes and
often complementary. For example, simulation may be can provide additional verification data to UVM for further
performed on some partitions while emulation in other actions. Specifically, SVA provides a simpler definition of
partitions. The verification process in simulation evolved temporal design properties for verification and coverage;
throughout history from simple visual (and very painful) for the support of covergroup sampling-controls that are
examination of waveforms with the DUT driven by a driver based on a sequence of events; and for localized detection
using directed tests, to transaction-based pseudo-random of errors and effective debug via on-demand waveform/
tests and checker modules. This has led to the development transaction recording.
of class-based frameworks (e.g., e, VMM, OVM, UVM) that
This article demonstrates how SVA complements a UVM
separate the tests from the environment, are capable of
class-based environment. It also demonstrates how the
generating various concurrent scenarios with randomness
UVM severity levels can be used in all SVA action blocks
and constraints, and are capable of easily transferring data
instead of the SystemVerilog native severity levels.
to class-based subscribers for analysis and verification. In
parallel, designers and verification engineers have improved
SCOREBOARD IN UVM
the detection and localization of bugs in their design code
Figure 1.0 demonstrates a typical verification model. The
using assertion-based languages (e.g., PSL, SVA).
scoreboard is part of the analysis group and is most often
Those recent verification technologies need not be used for the verification of the design behavior.
independent. Specifically, verification approaches consist
Scoreboards are analysis components that collect the
of several methodologies that work well, particularly
transactions sent by the monitor and perform specific
when combined in symphony. UVM is a class-based
analysis activities on the collection of transactions.
methodology that, because of its nature, tends to stress the
Scoreboard components determine whether or not the
device is functioning properly. The best scoreboard
architecture separates its tasks into two areas of concern:
prediction and evaluation. The prediction is based on the
requirements. A predictor model, sometimes referred to as
a “Golden Reference Model”, receives the same stimulus
stream as the DUT and produces known good response
transaction streams. The scoreboard
evaluates the predicted activity with
actual observed activity on the DUT.
Thus, in essence, a scoreboard is a
piece of checking code that keeps
track of the activities of the design and
calculates the expected calculated
responses based on scenarios, and
compares those against actual.
24
SVA AS COMPLEMENTARY/ next subsections, assertions provide many benefits in a
SUBSTITUTION APPROACH verification environment, and if values of class variables
The concept of assertions is not new; any verification are needed for use in concurrent assertions, those
methodology or code “asserts” that the design meets variables can be copied onto class-static variables or in
the properties of the requirements. Thus, broadly SystemVerilog virtual interfaces (to be connected later
speaking, one can state that the UVM scoreboarding to actual interfaces), and then used in the assertions.
approach provides assertions about the correctness Assertions provide several unique capabilities, as
of the design, and in its own rights is a coding style/ described in the following subsections.
language/methodology with its macros, data structures,
Detection of temporal violations
and libraries. Assertion languages, such as PSL and
and use of action block to modify flow
SVA, evolved to address the need to specify the temporal
SVA handles cycle accurate checks more effectively than
requirement properties of a design in an executable
with an application using scoreboarding because the
language that is easy to write and read, and yet meets the
verification of the signals is done at every cycle rather than
needs of the design space for both simulation and formal
at the completion of the data gathering process. The action
verification. Thus, in a manner similar to frameworks, SVA
block of an assertion can modify SystemVerilog interface
is a language that expresses behavioral properties and
variables or static class variable on either a pass or a fail
supports directives to do something with those properties,
action of the assertion. Those variables can then be used
such as assert for their correctness, assume for the input
by a class instance to drop an objection or to modify the
space constraints, and cover for the coverage of those
flow of the class. Figure 2.0 demonstrates these concepts.
properties.

The unique capabilities of SVA Figure 2.0 Using the results of an assertion to stop the
simulator3 http://SystemVerilog.us/verizons/sc2uvm.sv
in a verification environment
SVA provides two types of assertions: immediate and
concurrent. Immediate assertions are executed like a import uvm_pkg::*; `include “uvm_macros.svh”
statement in a procedural block and do not need a clocking class dut_xactn extends uvm_sequence_item;
event to trigger the assertion, as that is controlled by the endclass : dut_xactn
procedural block when the code reaches the assertion. k and h are static class variables
class C; that can be read and written from
An example of an immediate assertion commonly used in static int k=9; within modules and interfaces.
UVM is something as the following: static bit h;
int v =5;
assert($cast(rsp_item, req_item.clone()) else rand int r; k is updated in a class
`uvm_error(“driver”,$sformatf(“%m : error in task test(); (in this or some other class)
casting rsp_item”))); // some actions
if(v==5) k=1000; else k=0;
Concurrent assertions are temporal, are based on clock endtask : test
semantics, and use sampled values of static variables. endclass : C
Assertions can also access static variables defined in
interface bus_if(input bit clk);
classes; however, access to dynamic or rand variables is class declaration
C c; (no instantiation needed)
illegal. Concurrent assertions are illegal within classes, but bit a, b, d;
can only be written in modules, SystemVerilog interfaces, bit done_abc; // for use by class
and SystemVerilog checkers2. As will be shown in the clocking cb @ (posedge clk); endclocking
25
// update statis class variable and interface variable apabc : assert property (@ (cb)
for use by other classes $rose(a) |=> (b, f(1’b1), $dumpon ) ##[1:10] (c,
task updates(bit done); $dumpoff));
done_abc <= done; c.k is used in an assertion.
Action block updates c.h initial begin
c.h <= done; and done_abc $dumpvars (0, top); Other functions can also be
endtask : updates end called, including system level
apEndProp : assert property (@ (cb) functions.
endinterface
$rose(a) && c.k==1000 |=> b ##[1:10] d) module top;
updates(1’b1); logic x =1, y=0, z;
endinterface endmodule : top

class dut_driver extends uvm_driver #(dut_xactn,

dut_xactn);
Minimizing use of scoreboarding
C c; // Class has the static variables read
and modified by the assertions with assertions
in the SV interface In class-based model, the scenario may modify class
virtual interface dut_if.bus_if vif; variables (e.g., the rand variables) that are used in the
// ... verification properties of the DUT. Those variables are
task run_phase(uvm_phase phase); often transferred to the scoreboard for the necessary
phase.raise_objection(this,”dut_driver”);
computations and comparisons. However, assertions offer
fork
begin another, easier to use alternative that in some cases may
//.. also work in conjunction with scoreboards. For example, if a
get_and_drive(); new occurrence of signal a occurs, then DUT signal b must
end remain at 0 for a number of cycles, as determined by the
begin scenario (the class). Signal a should then go to a logical 1
wait (this.vif.done_abc && c.h);
within 5 cycles after that. To achieve this with assertions, a
phase.drop_objection(this,”dut_
driver”); task in the class copies the value of that number of cycles
end into a SystemVerilog interface (or a static class variable, as
join c.h and done_abc are discussed previously). The assertion in the interface makes
endtask : run_phase used in a class to affect use of that copied variable and other signals of the interface
decisions or the flow
endclass : dut_driver to determine compliance to the requirements. Any detected
error is reported by the assertion; that error can also be
reported back to the class via an interface variable (or a
Sequence match to modify interface variables
static class variable). That variable is set or reset by the
or trigger system level functions
Assertions can be used to call functions or system functions action block. Below is a snapshot of the key elements of
during any cycle of a sequence upon the success of an this concept and assertion in figure 4.0.
evaluation during that cycle. This capability also allows for
Figure 4.0 Use of values of class variables and
changes to the SystemVerilog interface variables or static class
assertions in interfaces
variable for use by the class. For example, in Figure 3.0:
(Code and simulation results are in http://SystemVerilog.us/
Figure 3.0 Variables and function verizons/test_if_assertions.zip)
calls from assertion statements

variable abc is accessible by a interface b_if (input logic clk);

interface bus_if(input logic clk); class instance. It is modified by
a function called from within a logic a, b, ab_error; // f ab_error to be used
// … signal declarations sequence of an assertion. by the class
bit abc, a, b, c; clocking cb @ (posedge clk); endclocking
clocking cb @ (posedge clk); endclocking int count; // f Value set from the class
function void f(logic v); // If $rose(a), then b==0 for count cycles,
abc =v; Other functions can also be called,
including system level functions. count >= 1.
endfunction : f

26
// This is then followed by b==1 within 5 cycles cache_hit_error <= 1’b0; else cache_hit_
after that. error <= 1’b1;
property p_ab_min; ap_cache_miss_access: assert property(@ (cb)
int count_v; rd |=> !cache_hit |->
($rose(a), count_v=count) |=> !data_valid[*4] ##1 data_valid)
(!b, count_v-=1’b1)[* 1:$] ##1 count_v==0 cache_miss_error <= 1’b0; else cache_
##[1:5] b; miss_error <= 1’b1;
endproperty : p_ab_min endinterface : c_if
ap_ab_min: assert property(@ (posedge clk)
p_ab_min)
ab_error <= 1’b0; else ab_error <= 1’b1;
endinterface : b_if Enhanced coverage sampling
SystemVerilog assertion statements enable the control of
transaction recording from action blocks or sequence match
For more complex problems, a scoreboard data structure item, i.e., from any clocking event when a variable is true.
can keep track of conditions (driven and expected), and This can be used in the setting of values within a module
the assertions in the SystemVerilog interfaces can then or interface, or to call any function, including the call of the
sample() function to sample group coverage. The following
determine the correctness of DUT’s responses. For
example demonstrates the concepts.
example, assume that a scoreboard keeps track of the
expected caching of data in the variable abc is accessible Figure 6.0 Use of assertions for covergroup sampling
by a class instance It is modified by a function called from
within a sequence of an assertion. Other functions can
also be called, including system level functions. DUT’s typedef enum {NOP, ADD, SUB, MULT, JMP, MOV,
READ, WRITE,
memory based on a caching algorithm. The scoreboard
IDLE} instr_e;
can keep track of an expected miss or hit (cache_hit), typedef enum {FETCH, DECODE, EXECUTE} mode_e;
and transfer that information, along with the value of any typedef enum {PC, IR1, IR2, REGA, REGB, MAR,
expected data (expected_data) into a SystemVerilog REG_FILE, STK} resource_e;
interface. Assertions in that interface can then verify the interface cpu_if(input logic clk);
correct response from the DUT and log in any detected clocking cb @ (posedge clk); endclocking
instr_e instr;
errors (cache_hit_error, cache_miss_error), which can
resource_e resource;
then be read by the class instance. mode_e mode;
Figure 5.0 Use of scoreboard values from class
logic[15:0] addr;
variables for use in assertions covergroup instr_cg;
InstXrsc : cross instr, resource;
endgroup : instr_cg
interface c_if (input logic clk); instr_cg instr_cg1 =new();
bit rd, wr, data_valid; covergroup addr_cg @(clk);
bit cache_hit_error, cache_miss_error; // f for addr_cp : coverpoint addr
use by class-based verification unit { bins instruction = {[0:255]};
bit cache_hit; // f for this read address, bins data = {[256:32767]};
supplied by scoreboard }
Sampling of cover group
in cycle after the rd endgroup : addr_cg from a sequence
logic [15:0] mem_data; addr_cg addr_cg1 =new();
logic [15:0] expected_data; // f supplied by sequence q_fetch; @ (clk)
scoreboard mode==FETCH ##1 (1, instr_cg1.sample(),
logic [31:0] addr; addr_cg1.sample());
clocking cb @ (posedge clk); endclocking endsequence : q_fetch
ap_cache_hit_access: assert property(@ (cb) cover property (q_fetch); // f Enables the sampling
rd |=> cache_hit |-> in cycle following the mode==FETCH
mem_data==expected_data) endinterface : cpu_if

27
UVM SEVERITY LEVELS IN SVA For bus protocol types of verification properties (signal level
verification), we recommend SVA at the interfaces instead
UVM provides several macros that resemble the of using scoreboarding with compare as a verification
SystemVerilog severity levels, but provide more options, technique. If a tool supports SystemVerilog checkers
verbosity, and consistency with the UVM verification (1800-2009 and 2012), use checkers bound to interfaces.
environment. In our SystemVerilog Assertions Handbook, Assertion results can be written into the interface variables
3rd Edition, we recommend the use of the UVM severity or class static variables for control and access by the UVM
levels in all SVA action blocks instead of the SystemVerilog environment. For coverage of temporal properties, use
native severity levels. For example, assertions in SV interfaces. For covergroups that require the
completion of temporal sequences as the sampling trigger,
use SVA sequences that can transfer the sampling triggers
string tID=”UART “;
ap_MEDIUM: assert property(a) else
to class variables. Use UVM severity levels in all SVA
`uvm_info(tID,$sformatf(“%m : error in a %b”, a), action blocks instead of the SystemVerilog native severity
UVM_MEDIUM); levels. Use SVA immediate assertions to flag unsuccessful
ap_handshake : assert property ($rose(req) |=> randomization and terminate the simulation run.
##[0:4] ack) else
`uvm_error(tID, $sformatf(“%m req = %0h, END NOTES
ack=%0h”, $sampled(req),
$sampled (ack))); 1. MENTOR GRAPHICS UVM/OVM documentation
verification methodology online cookbook
See http://systemverilog.us/uvm_hi_low3.pdf for a
discussion on this topic along wth simulation results. 2. See Chapter 17 of SystemVerilog 1800-2012.
3. SystemVerilog Assertions Handbook, 3rd Edition
with IEEE 1800-2012, ISBN 978-0-9705394-3-6
CONCLUSIONS AND RECOMMENDATIONS http://SystemVerilog.us

Verification consists of several methodologies that work

well, particularly when combined in symphony. UVM is
a class-based methodology that tends to stress the use
of scoreboarding to compare expected results against
actual observations. Though the scoreboarding approach
solves many verification tasks, SVA provides another
complementary approach that works with UVM to speed
up the model building process, to support the class-based
environment, and to quickly localize errors at the cycle level.

SVA provides complementary advantages for UVM. This

includes the simpler definition of temporal design properties
for verification and coverage; the support of covergroup
sampling control based on sequence of events; the localized
detection of errors and effective debug via on-demand
waveform/transaction recording; the control of system level
tasks based on sequence of events; and the reporting of
errors back to the UVM environment for flow control.

28
Editor: Tom Fitzpatrick
Program Manager: Rebecca Granquist

Wilsonville Worldwide Headquarters

8005 SW Boeckman Rd.
Wilsonville, OR 97070-7777
Phone: 503-685-7000

To subscribe visit:
www.mentor.com/horizons

To view our blog visit:

VERIFICATIONHORIZONSBLOG.COM