Configuring Your Resources the UVM Way!

Parag Goel, Amit Sharma, Rajiv Hasija,

Synopsys, India Synopsys, India LSI, India
91.80.40188000 +91.80.40188000 +91.80.41977811
[email protected] [email protected] [email protected]

Thus, dynamic testbench reconfiguration and modeling of

ABSTRACT configurable scenarios are required to verify real world
scenarios for the complex chips. From a horizontal and
vertical reuse point of view, it is imperative that that the
With increasing complexity of semiconductor designs, and components are made sufficiently configurable. The
with more and more IP blocks to be integrated in SoC's, there specification of the base classes in the Universal Verification
is an increasing need of verifying their numerous Methodology (UVM) provides a convenient interface for
configurations. The large numbers of permutations through achieving some of these requirements. Leveraging the UVM
which different functionalities can be enabled at any given configuration mechanism, we will show how a resource
time require the verification environment to mimic the same. management infrastructure can be created which will make
The testbench configuration classes with different properties all the components configurable by design. We would also
are typically used in verification environments to model demonstrate the usage of the capabilities available to achieve
these various aspects. The constraints across the various different verification requirements. Specific guidelines
properties ensure that the testbench can pick up valid would be highlighted so that optimal usage is achieved.
configurations.
2. UVM Configuration Mechanism: A Feature
Now, these configuration classes have to be available or
accessible across all the testbench components. This ensures Description
that all the components can independently configure
themselves based on the testbench topology and the relevant From Figure 1, it can be seen that each component ideally
DUT configuration that is currently being verified. needs a configuration component to bring in the desired
Additionally, the testbench components need to be able to flexibility or reusability. The configuration of each
change the properties of the configuration classes component needs to be changed based on the different
dynamically based on the DUT responses and also be able to requirements. Depending on the configuration changes, the
react to similar changes affected by the other components. components need to be Also, as the various configurations
Efficient resource management is also vital in such complex are changed or applied across the testbench; individual
environments. components have to be aware of all such changes.

The reference implementation of the base classes as specified

in the Universal Verification Methodology (UVM) provides
a lot of relevant functionality to achieve some of these
requirements. To ensure that these capabilities are optimally
leveraged, the paper helps the reader achieve a deeper
understanding of the mechanism through which this
functionality is delivered. The different usage scenarios
demonstrated show how the desired benefits can be achieved
in the effective configuration and management of testbench
resources.

Categories and Subject Descriptors

Testbench Methodology, UVM, Testbench Configuration.
General Terms
Management, Performance, Verification, Design
Keywords Figure 1: Configuration Requirements in a Verification
Testbench, Configuration, UVM, SystemVerilog Environment

For efficient synchronization and integration, a uniform

1. INTRODUCTION configuration should be propagated across the hierarchy.
Hence, as a general recommendation, the attributes that
Managing the testbench configuration is a challenge in control functional aspect of a verification component must be
complex verification environments today. The different encapsulated in a class wrapper. This class object can be
power modes, performance optimizations, memory accesses passed down to different components in the testbench
modes and their management, and other interrelated environment. The testbench configuration attributes which
functionality require different components in the verification decides on the topology and coarse testbench controls can
environment to be configured differently. Each component in continue to be distributed across discrete elements.
a verification environment would typically support different
capabilities which might not be required for a specific project
or a DUT configuration. Thus, different testbench
components could require information to be passed to it from
external sources. To encapsulate this information, there is a
need for a structured container, with appropriate constraints,
and values which are themselves configurable. This
container or class needs some knowledge of the circumstance
at hand so that it can alter its topology or behavior
accordingly.
Figure 2: A Typical Configuration Class
A typical example of a Configuration class is shown in The class uvm_resource_db#(T) is a convenience layer on
Figure 2. The constraints across the various properties ensure top of the low-level database. It can be used on its own and
that the valid combinations are generated when the class is different layers of type-specific specializations can be built
randomized. The Configuration class should be implemented on top of it. A collection of static functions operate on the
by extending the uvm_object or the uvm_sequence_item resources and the resource pool. The uvm_config_db#(T)
base class. This object must be factory-enabled. class provides a layer on top of the uvm_resource_db#(T) to
enable the accesses in the hierarchical context. These classes
How do we ensure that this Configuration class can easily be enable the users to retrieve different attributes and objects
propagated across the testbench environment? In UVM, with the appropriate look-up names. User can "set" a default
objects are often instantiated through the factory configuration object in the environment, "get" the
infrastructure. The factory infrastructure is responsible for configuration object in the test and modify it, then "get" the
invoking the constructors and the user does not have the modified configuration object in the VIP or the block level
possibility to modify constructor arguments. Hence, it is not agents.
recommended to pass configuration objects in constructor Users can retrieve a testbench attribute from the resource
arguments. Thus, we need a capability through which database or dump an attribute into the database either by the
functions can put or retrieve configuration attributes and type or by name of the attribute. Given that both these
objects from a central database dynamically. parameterized classes share the same underlying database, it
is possible to write to the database using
UVM provides a facility called 'resources' which provides uvm_config_db::set() and retrieve from the database using
the configuration infrastructure and API. It is comprised of uvm_resource_db::read_by_name(). With respect to usage,
polymorphic resource containers, a database for storing those uvm_config_db is a type-specific UVM configuration
resource containers and an infrastructure for locating mechanism which creates a visibility of a resource over a
resources in the database. This infrastructure can then be specified scope defined by the uvm_component hierarchy
used to propagate configuration information to different whereas uvm_resource_db is mainly for general purpose
components. Each component retrieves a value from the usage, which is used to set shared resource which can be
resource pool and uses the retrieved value to control its accessed anywhere in the testbench scope. A resource is set
behavior. through non-hierarchical context while for uvm_config_db, a
hierarchical uvm_component context is required. Hence, the
2.1 Understanding UVM Resources APIs provided by both these interfaces differ primarily in
ability to provide the hierarchical context as shown in Figure
The generic resource database provided by UVM is a low- 4.
level database which has its own access classes and methods.
The Figure 3 represents the organization of the resource
database., The UVM Resources provides multiple APIs
which are distilled down to the user to access, retrieve, audit,
query, lock and set priority levels while interfacing with the
underlying database. For the user, UVM configuration
facility provides two separate API interface. These are the
uvm_resource_db and uvm_config_db. These two classes
interface between the UVM resource facility and the actual
user.

Figure 4: UVM Resource Access APIs

Also, there are distinct methods for the retrieval of a

configuration object or attribute in case of uvm_resource_db
by name or by type. These are:

uvm_resource_db#(type)::read_by_name(scope,
key, type_var, accessor);
uvm_resource_db#(type)::read_by_type(scope,
type_field, accessor);

The scope can be a regular expression in set only. In get,

it must be an actual value.
Now, going back to the Configuration class, once it is
randomized, the test writer can use the uvm_config_db::set()
mechanism to assign the configuration object to one or more
environments within the testbench.

2.2. Basic Use Cases

2.2.1 Getting and Setting Configuration Attributes:

Using uvm_resource_db : The following will create a new

resource, populate it and insert it into the resource pool.

uvm_resource_db#(int)::set(top.env*,A,",12
34,this);

The above code snippet will create a new resource of type

int, assign a value of "1234" to it, and set it in the database
using the name A. This resource would be made visible
Figure 3: UVM BCL Organization of Resource Facility
in the scopes identified by "top.env.*". This assumes there is class is required. This is because the data type of the
only one matching argument A in top*, which happens to configuration class, drv_cfg, is strongly typed. A get() call
be top.env.A. The last argument is used for auditing. could be avoided if the configuration object passed was of
type uvm_object. In this case, an explicit cast has to be made
The component that retrieves this resource would read the to the extended configuration class handle.
value from the database.
The precedence rules ensure that when multiple overrides or
if(!uvm_resource_db#int)::read_by_name(get_ sets are applied, the one applied at the end succeeds. For a
full_name(),A,value,this)) testbench configuration class, it is always intended that
`uvm_error(get_full_name(),"The resource A configurations set at the highest-level of testbench
cannot be retrieved. It is not found in the hierarchy always override the configurations set from the
specified scope ");
lower-level components.
Here, read_by_name() returns a bit that indicates whether or
The configuration object can also be propagated down to
not the lookup succeeded. It is always a good coding practice classes which is not necessarily an uvm_component
to check the return value of uvm_config_db::get() or extension as shown in Figure 6
uvm_resource_db::read_by_name(). An appropriate message
can be issued to report whether a retrieval was successful or
not. This can help avoid unnecessary debug cycles.

Using uvm_config_db:

class my_mon extends uvm_monitor;

bit check_en;
`uvm_object_utils(my_mon)
. . .
function void build_phase(uvm_phase
phase) Figure 6: Configuration Passing Across Component and Object
uvm_config_db #(bit)::get(this, , Hierarchy
check_en, check_en)
endfunction Here, the important thing to note is that the scope is made
endclass null. Not doing the same will result in an error. This is
because the set is invoked the uvm_component scope and
The corresponding code snippet for setting the value of the the corresponding get in the uvm_object scope.
check_en attribute would be the following :

uvm_config_db #(bit)::set(this, .*mon*,

3. Addressing Verification Requirements Using
check_en, 1); UVM Resources

The above code ensures that the setting of the value Here, we look at the common verification challenges and see
happens in the monitor instance path only. The how the UVM configuration mechanism help us address
uvm_config_db #(bit)::get() call can be avoided if the field some of them.
automation macros are used in the UVM component instance
as shown below: 3.1 Propagating Virtual Interfaces
`uvm_field_int(check_en, UVM_PRINT| The Resource Database works with all SystemVerilog data
UVM_COPY); types. One ubiquitous requirement across all verification
environments is to have a mechanism which enables passing
The uvm_component, which in this case is the Monitor class the virtual interfaces easily across different verification
should be instantiated in the component hierarchy and that components. It is important to avoid using cross-module
super.build_phase() or apply_config_settings() should be references (XMRs) in environments as it makes it impossible
called in the component's build_phase(). In this case, the to put them in packages and thus compile them separately. It
get call is implicitly invoked. However, the also makes the environment inherently non-reusable.
recommendation is not to rely on the field automation
macros, and invoke an explicit uvm_config_db::get(). This Thus, a better approach is to "push" the virtual interface into
enables better type checking and traceability through the the Configuration Database from the top-level module. That
issuing of a warning/error message on an unsuccessful get). top-level module is specific to the environment used to verify
the DUT. It is thus perfectly acceptable to specify
2.2.2 Propagating the Configuration Object Across environment-specific hierarchical names in that module.
the Testbench Hierarchy Since the module is not an uvm_component, "null" is
specified as the context argument and the absolute
To set the configuration object across the hierarchy, see Figure 5. hierarchical name is specified for the agent where the virtual
interface is assigned. As the environment is usually
instantiated by the test, the absolute hierarchical name will
start with "uvm_test_top.".

Figure 5: Setting the Configuration Object Across Components

Here, irrespective of whether the field automation macros are Figure 7: Propagating Virtual Interfaces using UVM Resources
used or not, an explicit get() for the class object in the driver
Agents should extract their virtual interfaces from the that a right set of sequences are executed in different phases.
Configuration Database entry named "vif" during Also, this allows the UVM components themselves to be
the build phase. A fatal error should be issued if no virtual generic in nature which makes them reusable easily across a
interface is retrieved. The agents are then responsible for wider range of requirements.
propagating that virtual interface to the drivers and monitors To execute a sequence in a specific phase in UVM, one
it encapsulates. needs to override the default_sequence string for a specific
. sequencer for that phase. The easiest mechanism is to use the
Resource Database to override the default_sequence string
from the test case or in the environment.

uvm_config_db
#(uvm_object_wrapper)::set(this,
<path_to_sequencer>.main_phase,
default_sequence,
sequence_name>::type_id::get());

The same or different sequences can be made to run in

different phases easily as well.
Figure 8: Trickling the Interface to the Sub-Components

3.2 Configurability in Stimulus Generation and

Execution

There might be specific requirements when the sequence

item's constraints depend on the values in configuration
object. The Resource Database can be used in the sequences
as well. Though the UVM configuration mechanism is
designed around components, when a non-component object Figure 10: Setting Phase-Specific Sequences
needs to access specific attributes, this non-component object
must access the configuration field through a component
handle. In the case of sequences, m_sequencer is the handle 3.3 Improving Verification Throughput
to the sequencer that is executing the sequence. It is a built-
in member of the uvm_sequence class. The configuration With long running simulations and the increasing times
object can be accessed through the m_sequencer handle as which are required to load up complex verification
shown in Figure 9. environments, it is desired to derive the maximum possible
simulation throughput for each simulation.

3.3.1 Using the Command Line Manager

It is important to be able to propagate changes in the

environment without having to recompile the design and also
to ensure that these changes can also create new verification
patterns. UVM provides for mechanism to capture values
from the command line and again propagate them through
the testbench through its configuration mechanism. This
functionality can be leveraged appropriately by providing
appropriate hooks in the testbench so that users are provided
with a template to maximize the useful simulation data that
Figure 9: Configurable Sequences can be extracted out of each simulation run.

The m_sequencer handle is no longer required if global Configuration Parameters: The Command Line Processor
configuration is desired. This can then be achieved through class provides a general interface to the command line
uvm_resource_db. arguments that are provided for the given simulation. The
uvm_cmdline_processor class also provides support for
uvm_resource_db#(int)::read_by_name("SEQ_CNTR setting various UVM variables from the command line, such
L", "item_count", item_count); as components verbosities and configuration settings for
integral types and strings. As far as overriding configurations
The item_count value for the resource then can be set in the settings are concerned, the command line option can only be
testcase as: used for setting the integer/string only in a class derived from
uvm_component. The control of the testbench configuration
uvm_resource_db#(int)::set("SEQ_CNTRL", of the scalar types through command line can be done as
"item_count", 10);
follows:
This essentially allows the sequences to reconfigure +uvm_set_config_int=<comp>,<field>,<value>
themselves based on the scenarios at any point in time. For +uvm_set_config_string=<comp>,<field>,<value>
example, a sequence can retrieve the memory allocation
patterns from the Register Model, and target the next set of An example of the same would be :
accesses in the un-allocated regions. The sequences +uvm_set_config_int=uvm_test_top.*.drv,delay,
themselves become more reusable from a vertical reuse 10
perspective as they reconfigure themselves based on newer
constraints applied in the configuration space. It has to be ensured that the user must register the field which
would be overridden using the field automation macros.
With the new run time phases in the UVM domain, There should not be any white spaces between the strings
sequences can be made to run in different phases. This gives passed to the command line argument. This can be very
a lot of granularity in terms of stimulus control and ensuring easily extended to the sequence or sequence library specific
parameters which can thus end up saving a lot of simulation uvm_config_db#::get(). If the return value denotes a
cycles. In this case, the user has to explicitly do a get in the successful retrieval, the rand_mode() of that specific
respective sequences as shown below. parameter can be turned to 0, so that the variable no longer
participates in the randomization.

if(uvm_resource_db#int)::read_by_name("*",
A,value,this))
A.rand_mode(0);

3.3.3 Dynamic Feedback, Coverage Convergence

Figure 11: Controlling the Parameters of the Sequence Library and Modifying Cover Groups

Subsequently, the following command line will change the Coverage Convergence:
total number of sequences executed for a specific sequence The SystemVerilog language provides capabilities to query
library to be 25 instead of the default 10. the functional coverage results on the fly. An intelligent
reactive testbench can thus use this information obtained
+uvm_set_config_int=uvm_test_top.tb.sequencer through constructs like get_coverage() to change its
,default_sequence.max_random_count,25 stimulus. Thus, without quitting simulation, the testbench in
an automated way identifies holes that it needs to target and
Thus, for specific values which are used as knobs and other changes the constrained random stimulus accordingly. One
discrete configuration parameters, additional tests do not of the pre-requisites to achieve this is to create your
have to be written. Different permutations can be tried out constraints in a way that it can also be modified during
from the command line without requiring any recompiles. simulation. This is made possible if variables are used to
Debug modes can also be enabled through the same model the testbench constraints. Thus by dynamically
mechanism. changing the value of the variables during simulation, the
overall stimulus sample space can be expanded or shrunk.
Factory Overrides from the command line: The changes that Thus, an intelligent reactive testbench can help raise the
can be propagated from the command line extends to factory productivity, by helping the user to cut down on the number
overrides as well. The testbench objects which are registered of tests to reach his or her coverage goals.
with the UVM factory can be overridden globally or in a
given hierarchy specified by an instance path in the The coverage model itself can be set in the Configuration
command line. Database. It can be retrieved easily in the sequences through
the Resource Mechanism, queried and based on the coverage
+uvm_set_inst_override=<req_type>,<override_t query results, the generation of the subsequent sequence
ype>,<inst_path> items can be biased by modifying specific constraint
+uvm_set_type_override=<req_type>,<override_t
ype>
variables as well as testbench parameters across the
environment [4].This can be done by biasing the weights on
An example of the above overrides would be : a randsequence branch, or by changing the distributions
modeled through variables.
+uvm_set_inst_override=driver,NewDriver,*.drv
0 Covergroup manipulation:
+uvm_set_type_override=packet,newPacket The enabling or disabling a covergroup can be controlled
through the UVM Resource mechanism. The coverage
attributes like weight, at_least, coverpoint ranges can be
3.3.2 Randomization Control and Performance changed as well.

The cost that one has to pay for constrained randomization is

the potential of degradation of simulation performance. The
UVM Resources can conveniently be leveraged in the effort
of cranking up simulation performance by avoiding
redundant randomizations. A complex set of interleaved
constraints can cause a significant impact on runtime
performance. As the number of random variables and the
associated constraints increase, the demand on the constraint
solver can increase exponentially.

The UVM Resource mechanism is sometimes used for

overriding values of random parameters in the
Configuration classes. When defining these classes, the user
might not know whether a specific property would be
through the Resource mechanism. If it is not overridden, the
user might want that property to take a random value. If it is
overridden, the user would want to ensure that the value is
not subsequently randomized. How does he get the best of
both worlds?

For dynamic objects extending from uvm_object, the

uvm_config_db::get() should typically be in the constructor Figure 12: Modifying coverage shapes
or a method which will subsequently be invoked post the
creation of the object. Whenever a get on a specific In the code snippet in figure 12, we can see that the
property succeeds, we know that the property should not be coverage_collector class is retrieving the Configuration Coverage
Model from the Resource Database. The Coverage Model is
randomized with the other members of the class whenever
dumped into the Resource Database from the agent (figure 13) in
the class is randomized at a later point in time. This can be the build_phase. The user sequence then queries the current
ensured by checking for the return value of the
coverage results and tweaks the constraint variables so that
redundant stimulus is not generated.

Figure 15: Building Configurable Number of SRAM Models

Now, it is important that the RTL Configuration class which

is accessed across the verification environment is used
during the compilation of the RTL code as well. Also, the
testbench should then exercise its stimulus on the newly
configured RTL. This basically calls for a two parse process.
The first parse will generate the RTL configurations and the
second will apply the configurations. The first parse will
involve executing a UVM test which will insert a phase
before the build_phase. In this phase, the RTL configuration
will be randomized, the RTL configuration data packed and
written out into a RTL Configuration text file.. Then the test
will cause simulation to skip all the remaining phases and
Figure 13: Stimulus Guidance through Coverage Feedback jump to the final phase.

3.4 Synchronizing RTL and Testbench

Configuration

3.4.1 Verifying RTL Configurations

Verification engineers have to come up with testbenches to

verify RTL which itself is configurable. The
configurability of the RTL can vary from a few bus width
parameters, or a configurable IP block with optional features
to a whole chip with optional interfaces. Some of these can
affect the physical interface between the testbench and RTL,
for example, Bus widths, number of instances of external
interfaces or the number of interrupts. In specific cases, it has
to support partially specified RTL configurations, multiple
instances of the same RTL module with different Figure 16: Generating the Randomized RTL Configuration
configurations, and configurations which does not affect the
physical interface, but does affect the way the test bench has % simv +UVM_TESTNAME=rtl_config_gen
to interact with the DUT functionally. For example, FIFO
Depth, QoS algorithms. Finally, it is important to track the The generated file in the user defined phase can be suitably
functional coverage across all these configurations too. parsed to generate the RTL parameters or compile time
macros which can be fed back to the RTL compilation. For
In a UVM testebench, this can be mapped as a UVM RTL the actual testbench simulation, the base test will read back
configuration class like any testbench configuration class. the RTL configuration from the generated file, unpack the
This can be used to encapsulate the RTL configuration data and then set the RTL configuration in the Resource
parameters for the design such as bus widths, FIFO sizes, Database.
number of I/O ports, etc.

Figure 14: Class Containing Variable RTL Parameters

The RTL Configuration class itself can be registered to the Figure 17: Loading the Randomized RTL Configuration
Configuration Database. It can be retrieved in the Testbench
Configuration class which can then subsequently set In projects where highly configurable IP has to be verified, it
testbench parameters. The additional methods to load or store is convenient to control and observe the progress of
the RTL configuration from an external file can be provided. verification across, not only the modes of operation, but also
This configuration object is then instantiated in the UVM those modes relating to specific RTL configurations. The
environment as shown in Figure 15. added benefit of using this method is that constrained
randomization and functional coverage collection can be now
be used for RTL configurations.
3.4.2 Leveraging Dynamic Reconfiguration The following APIs helps to ensure that different
components can reconfigure themselves at any time when
As designs grow in size, memory size and simulation speed there is a relevant change in any of the attributes registered in
are becoming critical issues for many customers. It is the Configuration Database.
becoming increasingly difficult to accommodate large
designs in 32-bit memory. Although the entire design may wait_modified: Waits for a configuration setting to be
need a 64-bit for simulation, only a portion of the design may set for a testbench attribute in a specific context and for
be necessary to run many tests. The simulation speed can be a specific instance name.
improved by removing or replacing part of the design exists: Checks if a value for a specific testbench
hierarchy with alternate models. The removing portions of attribute is available in an instance with a specific
the hierarchy by replacing modules with empty modules, context as a starting point.
simpler modules or higher-level models allows the design
size to be reduced, resulting in decreased memory
As described earlier, the UVM sequences would look up the
requirements. This has the additional benefit of faster
Resource Database to generate appropriate stimulus based on
simulation due to the pruned design size.
the current configuration. They can be reactive when the
The Dynamic Reconfiguration provides a flexible
need arises. The coverage model would sample the
mechanism to replace portions of the design hierarchy at
appropriate cover bins, the scoreboard and protocol checkers
runtime. This enables many design configurations to be used
would verify and validate the traffic based on the dynamic
without the need to re-compile the design.
parameters. With all the components feeding in relevant
statistics back to the resource manager, different
performance metrics at the system level can be assessed and
improved upon. Thus, a significantly smaller yet
configurable verification setup can target a bigger chunk of
DUT functionality and avoid wasteful debug cycles to rule
out false negatives.

Figure 18: Reconfiguring Design Hierarchy 4. DEBUG Infrastructure for UVM Resources

This requires passing in a configuration file at compile time There is a lot of functionality and convenience that the UVM
specifying all the instances that can be substituted or black Resources provides. Along with the functionality, it is
boxed with empty shells. At run time, one or more important that appropriate debug hooks are provided so that
configuration file gets passed to the executable which the user can easily decipher any unexpected behavior is seen
specifies the actual instance hierarchies for that simulation. in the Testbench.
As in the case of modeling RTL configurations, a similar file
dumped out from the first parse can generate the appropriate UVM Configuration debug APIs enables the recording of all
configuration file which can be used for stubbing out reads and writes done to the Database. It stores information
specific hierarchies at runtime. This ensures that the about the accesses. It records the number of times a resource
testbench is aware of the changed hierarchy. Additionally, all is read or written at what times from which hierarchical
different permutations and combinations of the actual RTL component. A mechanism to turn off recording is provided
instances can be tracked in the testbench. as simulation performance can be affected because of the
same. Based on the information analyzed from the resource
3.5 Effective Resource Management (Bringing it All dump, one can improvise on the usage of UVM
Together) configuration APIs and use them more optimally

For System Level verification, the complexities and the Figure 19 shows the hierarchy of functions that are used in
permutations of functionalities that have to be verified debugging UVM Resources. The user is not expected to
increases manifold. Some of these include: invoke all of these and the pictorial representation basically
Exercising modes of the peripherals with all the illustrates the internal debug process. Invoking the dump()
possible modes of system configuration function of the uvm_resource_db triggers the entire process
provided the user has set the auditing parameter as arguments
Bandwidth issues in the system when multiple
when invoking the Resource APIs.
peripheral devices contest for system resources
IRQ Handling
Power Modes and how that affects different
components
Memory Allocation Management

Typically, the verification environments need to have their

own resource management infrastructure which enables
coordination across different components and would have
APIs to help the components be aware of all the changes in
the verification environment. Mailboxes, TLM ports or
shared queues are used for communication across threads but
then any form of bi-directional communication is typically
restricted to the subscriber and the producer. Also, creating
such an infrastructure would typically require a
parameterized interface to manage a set of resource
descriptors which are doled out and returned as needed by
the tests. Creating such an infrastructure is a significant
investment in time and resource. With the UVM Resource Figure 19: UVM BCL Resource Debug API
classes and the associated APIs, the additional investment in
creating a Resource Manager is no longer required. As The Command line arguments +UVM_CONFIG_DB_TRACE
different testbench elements are registered in the and +UVM_RESOURCE_DB_TRACE would also help trigger
Configuration Database, their current status and values can this process and the user can find out from the trace
be queried from across the testbench. messages in STDOUT as to which overrides succeeded,
which failed and what has been registered to the 9. Conclusion
Configuration Database.
The objective was to present an overview of the UVM
UVM_INFO Configuration mechanism and demonstrate how the
<path_to_uvm_install>/src/base/uvm_resource_d
functionality provided in the UVM base classes can be used
b.svh(129) @ 0: reporter [CFGDB/SET]
Configuration 'uvm_test_top.env.*.A' (type to model configurable testbench environments. This
logic signed[4095:0]) set by uvm_test_top.env understanding is then applied to come up with relevant usage
= (uvm_bitstream_t) 1011 scenarios and to demonstrate how complex verification
requirements can be met. We have seen very encouraging
UVM_INFO results with the different applications. With the save-restore
<path_to_uvm_install>/src/base/uvm_resource_d flow, we were able to have multiple runs to share single
b.svh(129) @ 0: reporter [CFGDB/GET] initialization. This gave us a 1.5x Regression Farm Speedup
Configuration 'uvm_test_top.env.leaf1.A'
for initialization sequence taking 33% of the complete
(type logic signed[4095:0]) read by
uvm_test_top.env.leaf1 = (uvm_bitstream_t) simulation. For the application of UVM resources in the
1011 dynamic reconfiguration flow, there was a considerable
reduction in the verification cycle time. The disk space
Additionally, after setting all the testbench configurations, requirement was reduced by around 90% for the example
the user is provided with APIs to check whether the design. Compute requirement was also reduced by
topology of the environment mimics what was expected approximately 85%. Additionally, we brought in a lot of
based on the configuration overrides. This can be done configurability to our coverage and constraint models to
through a simple call to print_topology() for the structural enable faster convergence. The testbench configuration and
correctness. resource management is one piece of the overall puzzle, but
to tackle this well using robust and powerful built-in
uvm_top.print_topology(); functionality ensures that the verification engineer is well
factory.print(); positioned to tackle the rest of the challenges in SoC
verification.

10. REFERENCES
[1] UVM User Guide
[2] UVM Reference Manual
[3] Accellera Verification IP Technical Subcommittee
Documents
http://www.accellera.org/apps/org/workgroup/vip
[3] UVM World Website http://www.uvmworld.org/
[4] A Practical Look @ SystemVerilog Coverage
Tips, Tricks, and Gotchas, Doug Smith, John Ansley
[5] Synopsys UVM CES Training
[6] http://www.vmmcentral.org/vmartialarts
[7] Advanced Testbench Conguration with Resources,
Mark Glasser, Mohamed Elmalaki