Power of UVM's Command Line Argument Usage in Verification Test benches

Shashank Mistry, Bipin Patel (eInfochips)

Introduction

The growing complexity of ASIC/FPGA designs in recent era has caused simulation times to increase drastically. This is because there is a growing need to ensure that the simulation matches the expectations of a business outcome-driven verification environment. In any case, the compilation of complex designs and test bench remains the single biggest concern for any verification engineer. The more flexibility you have in your VE to simulate design again and again without compiling the bulky complex design, the more time you can save which can be used in other important tasks during design verification phase. Such flexibility includes simulating designs with Test bench reconfigurations, applying effective constraints to important control knobs (like altering the lower or upper cap of control variables) etc.

The ability to change the configuration or parameters without being forced to recompile can result in significant time savings. UVM (Universal Verification Methodology) is the most powerful methodology that has become the most cutting-edge and popular SV methodology in the verification world. At eInfochips, we have been successfully leveraging complex projects in networking, consumer devices, automotive, smartphones, camera equipment, multimedia, aerospace, servers, automated test equipment, and MEMS. As per one of our clients, have perfected the art, so as to speak.

As such, there are many things recommended for a user to follow in various UVM manuals but in this article, we will discuss one of the most powerful – no, THE most powerful feature of UVM which is “uvm_cmdline_processor”. Effective usage of “uvm_cmdline_processor” can lead to remarkable time savings in any design verification project.

What is UVM COMMANDLINE PROCESSOR?

The class of “uvm_cmdline_processor” provides a general interface to command line arguments that were provided for any given simulation. The “uvm_cmdline_processor” class also provides support for setting up various UVM variables from the command line such as components’ verbosities and configuration settings for integral types and strings. With a same compiled database, it allows more flexible and useful controls to run tests with different values of many control variables and ultimately, it can help cover more scenarios with less number of tests.

“uvm_cmdline_processor” has various in-built methods like get_args(), get_plusargs(), get_uvm_args() and get_arg_matches() to retrieve command line arguments. The “get_arg_values” can be used to retrieve the suffix values of an argument. Based on any given scenario needed, the required constraints can be applied to other variables of a test. Let’s talk of one of the methods “get_arg_value()” in more detail to understand possible usage with few examples.

get_arg_value (arg, value)

This function is used to get the value of specific command line argument(s). For a VE having multiple possible configurations, the “get_arg_value” function can be used to run the same test with all different configurations, without re-compiling test bench again and again. That too without changing test(s) or sequence(s).

Example 1:

VE with PCIe as an interface protocol, taking into account the operating speed and number of lanes for which there are multiple configurations possible. VE can have multiple APIs targeted to configure specific speeds and number of lanes. Based on command line arguments like +link_speed and +lanes, a same set of test sequences can be run with all possible configurations. If user wants to run a test with PCIe speed = Gen2 and lanes = x2, then this can be achieved simply by having +link_speed=gen2 and +lanes=2 on command line arguments, and in verification environment fetching them by calling methods like get_arg_value(“+link_speed=”,link_speed) and get_arg_value(“+lanes=”, lanes) while using local variables (link_speed and lanes) in respective APIs.

Example 2:

User can control address range randomization through command line arguments. Such a control would really help in functional coverage closure where a set of tests can be run with desired control value(s) to hit functional coverage holes. Example codes in below snippet shows how one can control the generation of addresses using this method.

Figure 1: CLA to control address randomization

Example 3:

To verify the HDMI transmitter and receiver, there are many possible test cases based on proposed framework. Instead of developing many tests, multiple scenarios can be generates if the height and width information is controlled from the command line. If user wants to run a test with width=640 and height=480, then on the command line, all he needs to do is pass +width=640 and +height=480. The verification environment fetches these values by calling methods as get_arg_value(“+width=”,width) and get_arg_value(“+height=”, height).

So, as explained in above examples, any desired VE field can be controlled from command line itself to simulate more scenarios using same set of tests/sequences.

In addition, the “uvm_cmdline_processor” class has in-built UVM aware commands for better simulation control. Following are a few use cases.

Changing test configuration

For a complex design where compilation as well as simulation consumes lots of time (lengthy simulations), one can change any variable to desired value without recompile using UVM-aware commands like “+uvm_set_config_int=” and “+uvm_set_config_string=”.

As shown in below snippet, if the need is to override a variable “scb_en” in an environment class, then it is achieved by adding command line option as,

+uvm_set_config_int=uvm_test_top.env,scb_en,1

Figure 2: Overriding configuration control variable

Using above method, ”scb_en” variable is set to value 1 that overrides the initial value.

Additional Built-in UVM Aware Command Line Arguments

+UVM_TESTNAME

It allows the user to specify which uvm_test should be created via the factory and run through the UVM phases. Desired selected tests can be run using this option without recompiling test bench and design.

Example:

+UVM_TESTNAME=write_read_rst_read_test

+UVM_TESTNAME=fifo_ovfl_err_test

+UVM_VERBOSITY

It allows the user to specify initial verbosity for all UVM components. By default, it is set to UVM_MEDIUM OR UVM_LOW based on the EDA tool in use.

Example:

+UVM_VERBOSITY=UVM_HIGH

+UVM_VERBOSITY=UVM_LOW

Using “+uvm_set_verbosity“, the user can also change the verbosity of specific component at specific phases of the simulation.

Example:

+uvm_set_verbosity=uvm_test_top.env.agent_A.*,_ALL_,UVM_FULL,time,800

+UVM_TIMEOUT:

It allows the user to change the global timeout of the UVM framework.

Syntax is +UVM_TIMEOUT=<timeout>,<overridable>

The <overridable> argument (‘YES’ or ‘NO’) specifies whether user code can subsequently change this value

Example:

+UVM_TIMEOUT=2000000,NO

Changing Max Quit Count

Using in built +UVM_MAX_QUIT_COUNT command line option, user can change the max quit count for the report server to any desired value.

Example:

By adding “+UVM_MAX_QUIT_COUNT=5” in command line the test simulation ends when it encounters total 5 errors.

Summary:

To summarize, the effective usage of in-built methods of “uvm_cmdline_processor” can result in huge time savings to meet the verification deadlines and for timely completion of a verification project. Same set of test cases and sequences can be reused to make more meaningful scenarios by controlling various configurations and control knobs using in-built methods of uvm_cmdline_processor.

eInfochips has been working with hundreds of clients on V&V projects, of which UVM methodology has been a real value addition.

If you wish to download a copy of this white paper, click here