Posts Tagged ‘methodology’

24 February, 2012

Advanced verification techniques including functional coverage and constrained random stimulus generation have proven themselves invaluable in the design of the smallest FPGAs to the largest SoCs today. Still many design and verification teams that need to and are willing to embrace these technologies have yet to do so. Verification environments written with basic hardware description languages like Verilog and VHDL, as well as home grown environments patched together with C, Tcl, or PERL scripts are entrenched and difficult to move away from. Adopting these new techniques requires training on several fronts. You need to learn the SystemVerilog language along with Object-Oriented programming skills. And to make your verification environments reusable and interchangeable with Verification IP (VIP) that you may want to get from outside sources, you need to learn the Universal Verification Methodology (UVM).

Or do you?

Maybe you can get started by using the minimal amount of things to get started. But how can you know what you need to know when there is so much to learn? That’s where the UVM Express comes in.

The UVM Express is a carefully planned path with a few key steps along the way to get you up and running. You learn just the things you need to be more productive at each step and advance at your own pace. There’s no need to digest everything at once to get up and running. The UVM Express path has four key steps:

Step #1 Organize your Testbench into a BFM

  • Use a SystemVerilog Interface to group your Signals
  • Write your test in terms of transactions
  • Call tasks to execute transactions

Step #2 Add Functional Coverage

  • Use Metrics to check Verification quality- How good are your tests?
  • Add coverage agents
  • Leverage pre-built VIP in passive mode

Step #3 Add Constrained Random Stimulus

  • Improve your test quality by generating stimulus efficiently
  • Leverage pre-built VIP in active mode

Step #4 Use the full power of the UVM

  • Modify your environment to improve reusability and configurability
  • Leverage all your code from the previous steps

The UVM Express adds to the many guides and examples in the UVM/OVM Online Methodology Cookbook on the Verification Academy. There is also a new UVM Express module that provides a multi-media walk through each of the steps. You can discuss this with me at next week’s DVCon 2012.

, , ,

8 March, 2011

by Rich Edelman and Dave Rich


The UVM is a derivative of OVM 2.1.1. It has similar use model, and is run in generally the same way.

One significant change is that the UVM requires a DPI compiled library in order to enable regular expression matching, backdoor access and other functionality.

When running UVM based testbenches, we recommend using the built-in, pre-compiled UVM and DPI compiled libraries. This will remove the need to install any compilers or create a “build” environment.

One other issue to mention if you are converting from OVM to UVM, and if you use stop_request() and/or global_stop_request(), then you will need to use the following plusarg, otherwise your testbench will end prematurely without awaiting your stop_request().


Simulating with UVM Out-Of-The-Box with Questa

The UVM base class libiraries can be used out of the box with Questa 10.0b or higher very easily. There is no need to compile the SystemVerilog UVM package or the C DPI source code yourself. The Questa 10.0b release and every release afterwards contains a pre-compiled DPI library, as well as a pre-compiled UVM library. The only dependency is that your host system requires glibc-2.3.4 or later installed. Questa 10.0c Windows users only, please read this important note about the location of the DPI libraries.

You can easily use these steps:

vlib work
vsim hello …

Notice that we don’t have to specify +incdir+$(UVM_HOME)/src,  $(UVM_HOME)/src/  to vlog, or add a -sv_lib command to the vsim command to load the uvm_dpi shared object.

Controling UVM Versions

Each release of Questa comes with multiple versions of the UVM pre-compiled and ready to load.  By default, a fresh install of Questa will load the latest version of UVM that is available in the release.  If an older version of UVM is needed, this version can be selected in one of two ways.

Modify the modelsim.ini File

Inside the modelsim.ini file, it contains a line which defines a library mapping for Questa.  That line is the mtiUvm line.  It looks something like this:

mtiUvm = $MODEL_TECH/../uvm-1.1b

This example is pointing to the UVM 1.1b release included inside the Questa release.  If we wanted to downgrade to UVM 1.1a, then we would simply modify the line to look like this:

mtiUvm = $MODEL_TECH/../uvm-1.1a

Command Line Switch

The Questa commands can also accept a switch on the command line to tell it which libraries to look for.  This switch overrides what is specified in the modelsim.ini file if there is a conflict.  The switch is ‘-L’.  If this switch is used, then all Questa commands with the exception of vlib will need to use the switch.

vlib work
vlog -L $QUESTA_HOME/uvm-1.1a
vsim hello -L $QUESTA_HOME/uvm-1.1a ...

If you are using some other platform, or you want to compile your own DPI library, please follow the directions below.

If you use an earlier Questa installation, like 6.6d or 10.0, then you must supply the +incdir, and you must compile the UVM.

For example, with 10.0a on linux, you can do

vlib work
vsim -c -sv_lib $UVM_HOME/lib/uvm_dpi …

if you use your own UVM download, or you use Questa 6.6d or 10.0 you need to do the following:

vlib work
vlog +incdir+$UVM_HOME/src $UVM_HOME/src/
mkdir -p $UVM_HOME/lib
g++ -m32 -fPIC -DQUESTA -g -W -shared
-o $UVM_HOME/lib/
vlog +incdir+$UVM_HOME/src
vsim -c -sv_lib $UVM_HOME/lib/uvm_dpi …

Building the UVM DPI Shared Object Yourself

If you don’t use the built-in, pre-compiled UVM, then you must provide the vlog +incdir+ and you must compile the UVM yourself, including the DPI library.

In $UVM_HOME/examples, there is a Makefile.questa which can compile and link your DPI shared object.

For Linux (linux):

cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make -f Makefile.questa dpi_lib

> mkdir -p ../lib
> g++ -m32 -fPIC -DQUESTA -g -W -shared
>   -I/u/release/10.0a/questasim//include
>   ../src/dpi/ -o ../lib/

For Linux 64 (linux_x86_64)

cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make LIBNAME=uvm_dpi64 BITS=64 -f Makefile.questa dpi_lib

> mkdir -p ../lib
> g++ -m64 -fPIC -DQUESTA -g -W -shared
>   -I/u/release/10.0a/questasim//include
>   ../src/dpi/ -o ../lib/

For Windows (win32):

cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make -f Makefile.questa dpi_libWin

> mkdir -p ../lib
> c:/QuestaSim_10.0a/gcc-4.2.1-mingw32vc9/bin/g++.exe
>   -g -DQUESTA -W -shared
>   -Bsymbolic -Ic:/QuestaSim_10.0a/include
>   ../src/dpi/ -o
>   ../lib/uvm_dpi.dll
>   c:/QuestaSim_10.0a/win32/mtipli.dll -lregex

Note: For Windows, you must use the GCC provided on the Questa download page: (

Save to /tmp/
unzip /tmp/
<creates the GCC directories in the MTI_HOME>

Using the UVM DPI Shared Object

You should add the -sv_lib switch to your vsim invocation. You do not need to specify the extension, vsim will look for ‘.so’ on linux and linux_x86_64, and ‘.dll’ on Windows.


vsim -sv_lib $UVM_HOME/lib/uvm_dpi -do “run -all; quit -f”


vsim -sv_lib $UVM_HOME/lib/uvm_dpi64 -do “run -all; quit -f”


cp $UVM_HOME/lib/uvm_dpi.dll .
vsim -sv_lib uvm_dpi -do “run -all; quit -f”

Running the examples from the UVM 1.1 Release

If you want to run the examples from the UVM 1.0 Release you need to get the Open Source kit – it contains the examples.

1. Download the UVM tar.gz and unpack it.

2. set your UVM_HOME to point to the UVM installation.

  • setenv UVM_HOME /tmp/uvm-<version#>

3. Go to the example that you want to run.

  • cd $UVM_HOME/examples/simple/hello_world

4. Invoke make for your platform:

  • For Windows (win32)
cd $UVM_HOME/examples/simple/hello_world
make DPILIB_TARGET=dpi_libWin -f Makefile.questa all
# Note: for windows, you need a "development area", with make, gcc/g++, etc. Using cygwin is the easiest solution
  • For Linux (linux)
cd $UVM_HOME/examples/simple/hello_world
make -f Makefile.questa all
  • For Linux 64 (linux_x86_64)
cd $UVM_HOME/examples/simple/hello_world
make BITS=64 -f Makefile.questa all

Migration from OVM to UVM

An OVM design can be migrated to UVM using a script. Many OVM designs can work without any hand coded changes or other intervention. It is a good idea to first get your design running on the latest version of OVM 2.1.2, before starting the migration process.

These designs can be converted from OVM to UVM using the distributed conversion script:


In certain cases hand coded changes might be required.

Using the ovm2uvm script, you can run a “dry run” try and see what must be changed. There are many options to the script. Before using it, you should study it carefully, and run it in ‘dry-run’ mode until you are comfortable with it. In all cases, make a backup copy of your source code, before you use the script to replace-in-place.

By default it does not change files.

Here is a simple script which copies the ovm code, then applies
the script.

# Copy my ovm-source to a new place.
(cd ovm-source; tar cf – .) | (mkdir -p uvm-source; cd uvm-source; tar xf -)

# Do a dry-run
$UVM_HOME/bin/ -top_dir uvm-source

# Examine the *.patch file

# If satisfied with the analysis, change in place
$UVM_HOME/bin/ -top_dir uvm-source -write

If you are migrating to the UVM from OVM, you are NOT required to use this script, but you must do a conversion by some means.

Once your OVM design is converted to UVM, you are almost ready to run.

The UVM requires that you use some DPI code. Additionally, the UVM defines a different semantic for run(). If you are using an OVM design converted to UVM, and you use stop_request() or global_stop_request(), then you need to add a switch:


In order to NOT use this switch, you need to change your OVM design. You need to NOT use stop_request() or global_stop_request(). You should cause your test and testbench to be controlled by raising objections as the first thing in your run tasks, and then lowering your objections where you previously had your stop requests.

More information about migrating from OVM to UVM can be found in the Verification Academy Cookbook (registration required).

, , , ,

8 April, 2010


Requirements set for Accellera UVM-EA (Early Adopter) Release

This was a productive week for Accellera. After months of discussions, the Accellera Verification IP Technical Subcommittee (VIP-TSC) voted to adopt OVM 2.1.1 as the base of its verification methodology. Accellera’s OVM version will be called UVM.

In adopting OVM 2.1.1, Accellera signaled it will make further changes. The VIP-TSC has approved changes to (1) modify file names that have OVM in them to UVM, (2) modify any function calls and element names from “ovm” to “uvm,” (3) make possible changes to the “end-of-test” and “callback” code found in OVM 2.1.1, and (4) add a “message catching” feature.

This is good news for Accellera and great news for those who have adopted OVM and use OVM today. I believe OVM users will find it easier to interoperate with this third methodology. As a strong supporter of Accellera standards, we will keep you updated on Accellera UVM as developments merit. Users should expect solid industry support in all their popular tools as the Big-3 EDA suppliers have all voiced public support for this standards project.

You can follow Accellera VIP-TSC developments directly at

, , , , , ,

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

Follow dave_59

@jhupcey tweets

Follow jhupcey