Verification Academy Patterns Library

Verification Academy Patterns Library

Pattern Name: Parameterized UVM Tests Pattern
 Intent: Parameters used in a design in most cases must also be used in a
testbench to ensure proper connections and communication can be performed.
Parameterized UVM tests (which are not available by default) provide an easy
mechanism for sharing of parameters.

 Motivation: Engineers create parameterized design IP so it can be verified once

and then reused in multiple contexts. The parameters used in this IP can control
design elements such as bus widths, generate statements to control if specific
logic is available or not, etc. To verify the parameterized IP, the testbench must
also have access to the parameters and knowledge of the values assigned to
those parameters. With UVM being a hierarchical collection of objects with the
test being the top level, why not just pass the same parameters to both the
design and the UVM testbench. This will simplify the exploration of multiple
parameter configurations and allow for verification of the full parameter state
space.

 Applicability: This pattern is useful in cases where a design is parameterized and

the full or at least multiple values of the parameter state space must be verified.

 Structure: To use this pattern parameters are defined in a single location such
as the top level testbench module and then those parameter values are shared
between the design under test (DUT) and the UVM test which contains the
environment and the rest of the UVM testbench.

Page 1 © Mentor Graphics Corporation, all rights reserved.

Verification Academy Patterns Library

 Implementation: To implement this pattern, the top level testbench module

must define a set of shared parameters, instantiate the design and pass the
parameters to it and start the UVM test with parameters passed to it. The
parameterized UVM test must be registered with both the type-based UVM
Factory and the string-based UVM Factory. Since by default a parameterized
UVM class is only registered with the type-based factory, the
`uvm_component_param_utils() macro must be expanded and added to.

Page 2 © Mentor Graphics Corporation, all rights reserved.

Verification Academy Patterns Library

 Example: An example implementation of these requirements result in a top

level module that looks something like this:

module tb_top ();

parameter BUS_WIDTH = 32;

parameter GEN_PARITY = 0;

dut #(BUS_WIDTH, GEN_PARITY) i_dut(...);

typedef test1 #(BUS_WIDTH, ADDR_WIDTH) test1_t;

initial begin

run_test("test1");

end

endmodule

The green highlighted code is where the shared parameters are defined. The
yellow highlighted code is the instantiation of the DUT with the shared
parameters passed through. The blue highlighted code is first where the shared
parameters are passed to the uvm_test. Then the call to run_test() creates
an instance of the uvm_test with the correct parameter values set.

If the uvm_test is defined as is typically done with the usage of

`uvm_component_param_utils(), the tb_top code will not work. That is
because the `uvm_componenet_param_utils() factory registration macro
only registers with the type-based UVM Factory. The task run_test() on the
other hand requires the test to be registered with the string-based UVM
Factory. To solve this mismatch, we need to expand the
`uvm_component_param_utils() macro and add to it which results in the
test definition looking like this:

class test1 #(int BUS_WIDTH = 16, bit GEN_PARITY = 1) extends

test_base_c;

typedef uvm_component_registry #(test1 #(BUS_WIDTH, GEN_PARITY),

Page 3 © Mentor Graphics Corporation, all rights reserved.

Verification Academy Patterns Library

"test1") type_id;

static function type_id get_type();

return type_id::get();

endfunction

virtual function uvm_object_wrapper get_object_type();

return type_id::get();

endfunction

const static string type_name = $sformatf("test1 #(%1d, %1d)",

BUS_WIDTH, GEN_PARITY);

virtual function string get_type_name ();

return type_name;

endfunction

...

endclass : test1

The code in blue is code that is added to the default expansion of the
`uvm_component_param_utils() macro. The “test1” string added to the
uvm_component_registry typedef is what registers this class with the
string based factory. The other additions are convenience code which is
included with when non-parameterized classes use the
`uvm_component_utils() factory registration macro.

 Consequences: By using this pattern the full set of parameters that a design
requires can easily be shared with the testbench. This allows for easy
modification of those parameters to fully verify the entire parameter state
space of the design.

 Contributor: Michael Horn

This pattern is discussed further in two DVCon papers:

“Parameters, UVM, Coverage & Emulation – Take Two and Call Me in the
Morning” from DVCon USA 2016

Page 4 © Mentor Graphics Corporation, all rights reserved.

Verification Academy Patterns Library

“Parameters and OVM — Can’t They Just Get Along?” from DVCon USA
2011

• Release Date: May 5, 2016

Corrections and Suggestions: To improve the quality of the Verification Academy

Patterns Library we welcome your comments, suggestions, and corrections. Please
contact us at: https://verificationacademy.com/contact

Page 5 © Mentor Graphics Corporation, all rights reserved.