Verification Academy

Welcome to the Demo Tour of the UVM/OVM Cookbook on Mentor's Verification Academy.
This is an overview of the pages in the cookbook - there are hundreds of articles that are available to you,
including real example code on the article pages and for offline download, once you register for full access.

Navigation:

Previous Page in Tour: Tour/Emulation Tour/Cookbook Next Page in Tour: Tour/PageList

The UVM 1.0 release is intended to be backwards compatible with the functionality present in OVM 2.1.1, with the UVM 1.0 functionality being a superset of the original OVM 2.1.1 functionality. In order to run OVM code with the UVM, all of the name strings used by the OVM have to be changed from "ovm" to "uvm" to pick up their equivalent in the UVM class library - for instance the ovm_pkg has to be changed to the uvm_pkg and so on.

A conversion script is provided in the UVM distribution to allow OVM users to translate testbench code written for OVM 2.1.1 so that it can be compiled and simulated with the UVM class library. This script does most of the translation but it does not catch everything, and the known issues are documented on this page.

Although UVM 1.0 is compatible with OVM 2.1.1, any deprecated classes or methods in OVM 2.1.1 are not present in the UVM and support for legacy classes and methods associated with the AVM or the URM have also been dropped.

Using The ovm2uvm Conversion Script

The UVM distribution kit contains a perl script call ovm2uvm.pl which is located in the /bin directory. This script runs through each file with a '.sv' or '.svh' extension in the OVM test bench code and converts it to UVM by translating "ovm" to "uvm". The script has a number of options:

The recommended way to use the script is with all these options. If --top_dir is not specified, then the script will overwrite all the files from the current directory downwards.

#
# Assuming that the OVM source code is in the directory tb_build
#
$UVM_HOME/bin/ovm2uvm.pl --backup --all_text_files --write --top_dir=tb_build
 
# Where $UVM_HOME contains the directory path to the UVM installation

When the script has completes it will have done the following:

• All strings containing ovm in .sv and .svh files are converted to uvm
• Files having a name containing ovm will be changed to uvm (e.g. ovm_container.sv will be converted to uvm_container.sv)
• Directory names containing ovm are left unchanged
• A patch file is generated, listing the before and after differences for the conversion
• If the backup option is specified, then a backup tarball will have been created containing the original file set
• If the all_text_files option is specified, then any text files will have had their ovm strings changed to uvm

Known Script Limitations

The ovm2uvm conversion script is not perfect and the following names are known to be missed by it:

This list will be updated if more escaping names are discovered.

Script Side-Effects

The script produces some side effects in the converted files which you will have to work through. Examples of these side effects include:

• If a `include statement includes a path that spans a directory path with 'ovm' somewhere in the string, then the path will no longer be valid since the directory name would not have changed
• If you have deprecated methods that can be migrated, then the function name will be changed but if the 'endfunction: <method_name>' coding style is used the end label string will not be updated

Scripts and make files that are updated because of the all_text_files option should be checked to ensure that, for instance:

• Directory paths containing ovm have not been changed to uvm
• Paths to what was OVM package source code are now pointing to the UVM package source code
• Questa OVMdebug switches will be converted to UVMdebug - this will only work in versions of the simulator that support UVM_DEBUG

Other Migration Steps

Although running the conversion script migrates the testbench code, there are other changes to the overall compile and simulation flow:

• Environment variables such as OVM_HOME need to be replaced with UVM_HOME
• The UVM package source will have to be compiled (at least in the short term)
• The simulation command line switch to choose the test class changes from +OVM_TESTNAME to +UVM_TESTNAME
• The UVM uses a shared object to support some of the new features such as the PLI code to do backdoor register accesses, this needs to be specified at the simulator command line. In Questa this is done using the -sv_lib switch which, by default, should point to the location of the UVM dpi shared object ($UVM_HOME/lib/uvm_dpi)
• If run_test() is called after time 0, that will cause an error in UVM. The top level module code which calls run_test() will need to be updated to call it at time 0. The UVM testbench code may also need to be updated to synchronize with the previous simulation time when run_test() was called an OVM testbench.

Creating the UVM Shared object file

The shared object file will need to be created for the simulator version and the computing platform in use. The UVM installation package has a set of simulator specific make files in the $UVM_HOME/examples directory and these will compile the object and place it in the $UVM_HOME/lib directory. The name of resultant file will be uvm_dpi.so in the case of a linux shared object and the make file will generate the appropriate extension for other operating systems.

#
# To compile the UVM shared object file for Questa
#
cd $UVM_HOME/examples
make -f Makefile.questa dpi_lib
 
#
# This will create a file called $UVM_HOME/lib/uvm_dpi.so (on a Linux platform) 
#

Running an UVM simulation with Questa:

As an example - In order to run a Questa simulation the following steps will need to be taken:

# 
# $UVM_HOME = <path_to_uvm_install>
#
# UVM shared object file:
# $UVM_LIB = $UVM_HOME/lib/uvm_dpi
#
# Compile the UVM package:
vlog +incdir+$UVM_HOME/src $UVM_HOME/src/uvm_pkg.sv
 
# Compile the rest of the test bench code ...
 
# Simulate the converted test bench:
vsim my_ovm_tb -sv_lib $UVM_LIB +UVM_TESTNAME=<my_test>

Known Differences Between The OVM and The UVM

Deprecated code

See also OVM2UVM/DeprecatedCode for more information.

Summary: The UVM makes a clean break from the OVM, any deprecated code identified in the 'deprecated.txt' file from the OVM 2.1.1 release tree will not be present in the UVM class library. If your OVM code was originally translated from the AVM, then there is a risk that you may have some AVM code which has survived, examples of which include ovm_threaded_components, and references to AVM phases such as export_connections().

The sequencer is_locked() method has been deprecated and the has_lock() method should be used instead, strictly speaking this is an OVM deprecation, but it is not documented in the 'deprecated.txt' file.

A copy of the deprecated.txt file can be downloaded as a tarball via the link below:

Download a complete working example (as used by ) (tarball: deprecated.tgz)

Objection differences

The uvm_objection callback methods have an additional description argument to their ovm_objection equivalents:

//
// Dropped:
function void dropped(
  ovm_objection objection,
  uvm_object source_obj, 
  int count);
 
 
// Raised:
function void raised(
  ovm_object obj,
  ovm_object source_obj, 
  int count);
 
 
// Raise objection:
function void raise_objection(
  ovm_object obj = null, 
  int count = 1);
 
 
// Drop objection:
function void drop_objection(
  ovm_object obj=null, 
  int count = 1);
//

//
// Dropped:
function void dropped(
  uvm_objection objection,
  uvm_object source_obj, 
  string description,
  int count);
 
// Raised:
function void raised(
  uvm_object obj,
  uvm_object source_obj, 
  string description,
  int count);
 
// Raise objection:
function void raise_objection(
  uvm_object obj = null, 
  string description = "",
  int count = 1);
 
// Drop objection:
function void drop_objection(
  uvm_object obj=null, 
  string description = "",
  int count = 1);

Sequence Library Differences

The old OVM sequence library has been completely deprecated, and is not recommended for new designs. A new uvm_sequence_library is in development, and a beta code implementation of it is included with UVM. For full details see the page OVM2UVM/SequenceLibrary

UVM_USE_OVM_RUN_SEMANTIC Plusarg

In OVM, there were two user initiated ways to stop a testbench when the time comes. The first and oldest way is to call the ovm_pkg::global_stop_request() method. This method will cause all run() tasks to be terminated. The other way which was introduced in OVM 2.1 is to use Objections|objections, specifically the ovm_test_done objection. If the testbench uses global_stop_request(), then after the conversion the testbench will not run correctly. This is because by default the only accepted user initiated way to stop a test in UVM is to use objections. To enable the use of the global_stop_request(), +UVM_USE_OVM_RUN_SEMANTIC has to be added to the simulation command line. If ovm_test_done was used, this will be converted to uvm_test_done by the script. The testbench will work, but is not fully converted to the new UVM phasing scheme.

Beyond the Script

After the ovm2uvm.pl script has been run and the testbench is working, then further steps should be taken to ensure future compatibility with UVM. The first of these steps is to update your phase names and possibly to take advantage of the new phases introduced in UVM. To see how to do this, please visit the OVM2UVM/Phasing article.