Introduction to UVM Connect (2024)

The UVM Connect library provides TLM1 and TLM2 connectivity between SystemC and SystemVerilog models and components. It also provides a UVM Command API for accessing and controlling UVM simulation from SystemC (or C or C++).

UVM Connect enables the following use models, all designed to maximize IP reuse.

The UVM Connect library makes connecting TLM models in SystemC and UVM in SystemVerilog a relatively straightforward process. However, because UVM Connect is effectively integrating several technologies, you’ll need to have basic knowledge of SystemC, SystemVerilog, and the UVM, and TLM standards. Refer to the References section for a partial list of relevant documentation. You may also wish to read the brief TLM Review included in this documentation.

This section enumerates some important characteristics of UVM Connect.

Definitions for terms used throughout this document.

See TLM Review for definitions of TLM-related concepts and terms.

How to navigate the documentation.

Click a major heading on the navigation bar at left to expand or collapse the list of items under that heading.

Each page in a major topic or adaptor class is summarized in a box like the one at the top of this page. Each heading or method has a one-line summary description for easy reference. Clicking on the heading or method will take you to its full description.

Clicking on the title of the summay box or full description heading will take you to the actual source file, if available.

Click on Index to look up a class or method name whose absolute location is unknown, or you can enter a keyword in the Search box to see a list of matches.

UVM Connect 2.2 and greater can be compiled to run with OVM 2.1.1 or greater. First, you must set an environment variable, OVM_HOME, to point to a valid OVM release. Then, to compile the OVM and OVMC libraries for 32 and 64 bit Linux, do the following

cd $UVMC_HOME/libmake -f Makefile.<tool> OVM=1 all

Where tool is the name of the simulator you are using.

Now, try running an example from the OVM-specific examples_ovm directory.

cd $UVMC_HOME/examples_ovm/connectionsmake -f Makefile.<tool> sv2sc

The latest version requirements

The latest version of UVM can be downloaded from Accellera. (http://www.accellera.org- /activities- /committees- /vip)

OVM can be downloaded from (http://www.verificationacademy.com).

UVM 1.1d adds a simple accessor method to uvm_port_base #(IF) for getting the interface mask of the port that is required by UVMC:

376a374,377> function int m_get_if_mask();> return m_if_mask;> endfunction

You can get back versions of UVM (1.0p1 or UVM-1.1) to work with UVM Connect by adding this method to the uvm_port_base #(IF) class in UVM_HOME/src/base/uvm_port_base.svh. You can make the edit directly in the source file, or you can replace the source file with the one included the UVM_HOME/compatibility directory in this kit. No other changes have occurred in this file between UVM 1.0p1 and 1.1d, so it is OK to replace the whole file.

No version of OVM has this accessor method, so port mask compatibility checks are not possible with any OVM release out-of-box. However, like UVM, you can enable port compatibility checks by replacing the file at OVM_HOME/src/base/ovm_port_base.svh with the file contained in the UVMC_HOME/compatibility directory.

The latest simulator requirements

UVMC is intended to work with all simulators--it uses standard SV, using only DPI-C behind the scenes. No simulator-specific use models are demonstrated by the examples, but that does not mean those use models are not possible with UVM Connect. For example, most simulators support SV-instantiates-SC and SC-instantiates-SV use models, but these are implemented differently by each vendor. The examples in this kit can be easily converted to employ those use models.

Based on end-user feedback, very minor modifications were made to enable UVM Connect to run on Synopsys’ VCS and Cadence’s Incisive simulators. The tool-specific makefiles included in this release are known to work on the given simulator version, but they may not represent best practice or recommended use models for those simulators. For tool-specific issues and questions, please consult the appropriate vendor.

There are some places in the source code where the coding had to be done differently for the different vendor simulators listed above.

In particular for the “fast packer” converters, techiniques for passing dynamic arrays by reference across the language boundary varied among the different vendor simulators. In some cases special extra code had to be added for the VCS and IUS simulators that was not needed for Questa.

To handle such cases you will see use of the following compiler directives for the SystemVerilog source files (~src/connect/sv/~),

`ifdef VCS # For Synopsys VCS specific code`ifdef INCA # For Cadence IUS specific code (auto-defined by analyzer)`ifdef VCS_OR_INCA # For VCS or IUS specific code

and the following for SystemC source files (~src/connect/sc/~),

#ifdef VCS # For Synopsys VCS specific code#ifdef NCSC # For Cadence IUS specific code#ifdef VCS_OR_NCSC # For VCS or IUS specific code

See comments in affected source code modules for more details of simulator specific concerns - particularly in the TLM GP packer/converter code (sc/uvmc_converter.svh, sv/uvmc_xl_converer.svh, sc/uvmc_tlm_gp_converter.cpp, sc/uvmc_xl_converter.cpp).

The latest platform requirements

How to prepare your environment

Generally you need to set up the environment for your vendor’s simulator in the recommended fashion for that product. If you know how to do this, the additional environment variables you will need to set for UVM and UVMC are shown below.

If you would like further guidance on a good template script that can be used for environment setups, please see the section entitled Regression testing. Specifically see the Environment setup template script topic. That section goes into considerable detail on environment setups that can be used when building special target libraries, and running all examples included in this package.

To run any example, you need compiled UVM and UVMC libraries.

The following environment variables should be set before compiling the UVM and UVMC libraries (if needed), and before running the examples included in this kit.

The UVMC library is intended to be portable across all simulators. If you had to make changes to the UVMC library source to accommodate your simulator, please let Mentor know via Verification Academy (http::/verificationacademy.com), your field representative(s), or Mentor’s general support line.

If you have a writable installation of the UVMC kit, you can compile the libraries and examples directly within the UVMC tree. In this case, you only need to specify the UVM_HOME environment variable.

It is possible to override the environment variable settings via Makefile arguments of the same name. This is not recommended because it will be easy to inadvertently compile libraries and examples using different paths.

The following statements set the four environment variables. For convenience, you may wish to put these in a setup script or in your .cshrc / .profile.

> setenv UVM_HOME <path to UVM 1.1d>> setenv UVMC_HOME <path to UVMC install dir>> setenv UVM_LIB $UVMC_HOME/lib/uvmc_lib> setenv UVMC_LIB $UVM_LIB

Compiled UVM and UVMC libraries are required before you can run the examples. Compilation is done separately from the examples in accordance with standard practice.

This kit provides a Makefile in $UVMC_HOME/lib for compiling the UVM and UVMC libraries. It is geared toward Questa compilation, so it will need to be adapted for use with other simulators. Please note the following:

• Before you attempt to compile, be sure you have prepared your environment as described in Env Setup.
• If you are compiling directly from the UVMC_HOME/lib directory (recommended), the Makefile uses default paths for UVMC_HOME, UVMC_LIB, and UVM_LIB. In this case, you need only define UVM_HOME via environment variable or make command line argument.

Questa users should not require building the UVM (or OVM) libraries, as they came precompiled and debug ready with the Questa distribution. Use the modelsim.ini to specifiy the UVM/OVM version you want to compile against.

Here is the general usage for the Makefile’s you see,

make [variable=value] <target(s)>

You can set the Makefile link to point to one of the vendor tool Makefile’s, for example,

ln -s Makefile.questa Makefile

Or, alternatively for each of the “make” commands you see below, simply substitute,

make -f Makefile.<vendor tool> ...

where vendor tool is one of questa, vcs, or ius.

And here are the common targets. You can combine targets to build more than one library.

make uvmc # makes both uvmc32 and uvmc64make uvmc32 # make UVM Connect (uvmc_pkg) 32bmake uvmc64 # make UVM Connect (uvmc_pkg) 64bmake ovmc # makes both ovmc32 and ovmc64make ovmc32 # make UVM Connect for OVM (ovmc_pkg) 32bmake ovmc64 # make UVM Connect for OVM (ovmc_pkg) 64b

To build a custom UVM/OVM, override the built-in library distributed with Questa, specify one or more of the following targets before any of the uvmc/ovmc targets above. You must define UVM_HOME (or OVM_HOME) when using these targets.

make uvm # makes both uvm32 and uvm64make uvm32 # make UVM lib (uvm_pkg) 32b (override built-in)make uvm64 # make UVM lib (uvm_pkg) 64b (override built-in)make ovm # makes both ovm32 and ovm64make ovm32 # make OVM lib (ovm_pkg) 32b (override built-in)make ovm64 # make OVM lib (ovm_pkg) 64b (override built-in)

The recommended usage is to build 32/64-bit libraries for UVM Connect, using built-in UVM,

make uvm

Here’s an alternate usage example for building 64 bit libraries for both UVM and UVM-Connect,

make uvm64 uvmc64 UVM_HOME=<path-to-UVM-source>

Some other options,

make clean # Remove all library directoriesmake help # Print this help information

Presently, the Makefiles are written for compilation on Linux platforms. Future releases may provide make targets for Windows compilation, subject to simulator support for that platform.

In addition to support for native Questa (and VCS and IUS) compiled SystemC libraries, support was also added for standalone libraries that can be used with OSCI SystemC and Vista SystemC.

You will find special Makefile’s for the standalone libraries here,

lib/ Makefile.uvmc_sysc_standalone Makefile.uvmc_sysc_standalone_osci Makefile.uvmc_sysc_standalone_vista

These each build a library called uvmc.so which can be directly linked into the Questa, OSCI SystemC or Vista SystemC kernel programs respectively.

NOTE: For the case of OSCI and Vista this assumes SV-UVM is not even being used. In fact, the SV-UVM infrastructure is completely removed from these libraries. They only support peer SC <-> SC UVM-Connect’ions for these use models.

To build each of these libraries first, make sure you properly setting up your normal OSCI SystemC or Vista environments (with appropriate gcc or vista_g++ env setup as well).

For further guidance on a good .toolsrc template script that can be used for environment setups, please see the section entitled Regression testing. Specifically see the Environment setup template script topic. That section goes into considerable detail on environment setups that can be used when building special target libraries, and running all examples included in this package. You’ll find a good customizeable .toolsrc template under the examples/ directory.

It is important to make sure the correct $UVMC_BUILD_PLATFORM is set depending on which gcc you’re using and 32 vs 64 bit builds.

Assuming you’ve made the documented adjustments to your .toolsrc template described in the section for native vendor simulator, OSCI SystemC, and/or Vista SystemC environments (with appropriate gcc/g++ or vista_g++ env setup as well), you can now follow this procedure to build the standalone libraries,

setenv MTI_VCO_MODE 64 # for 64 bit platforms, or '32' for 32 bit platformscd lib/source Env.script # Which references the pre-customized .toolsrc template# For Questa SystemC standalone lib ...gmake -f Makefile.uvmc_sysc_standalone# For OSCI SystemC standalone lib ...gmake -f Makefile.uvmc_sysc_standalone_osci# For Vista SystemC standalone lib ...gmake -f Makefile.uvmc_sysc_standalone_vista

NOTE: You can continue to use the default way of building UVMC libraries for Questa (or VCS or IUS) SystemC+SV-UVM applications. Standalone libraries are not needed in this case and the builds of them do not interfere with the “normal” way of building UVM-Connect libraries.

You will see the resulting libraries placed in the following directories,

lib/ questa/ <platform dir>/ osci/ <platform dir>/ vista/ <platform dir>/

The <platform dir>/ areas are directory names formed by the setting of $UVMC_BUILD_PLATFORM which has a naming convention that accounts for 32 vs. 64 bit and what GNU gcc/g++ version is used.

TLM2 features not fully implemented in UVM

• Transport debug interface - tlm_transport_dbg_if
• Direct member interface - tlm_fw_direct_mem_if, tlm_bw_direct_mem_if
• Core initiator and target sockets - UVM provides sockets that provide blocking or non-blocking transport, but not both.
• Quantum keeper
• Payload event queue
• Instance-specific extensions

Should your SC models rely on SV-side implementation of these interfaces, further adaptation may be required to achieve successful interoperability.

There are also several limitations in the current UVM implementation.

• The core sockets in standard TLM2, tlm_initiator_socket and tlm_target_socket, have no direct counterpart in UVM SV. The standard defines initiator and target sockets that use/implement both the b_transport and nb_transport interfaces. UVM defines sockets that implement either blocking or non-blocking but not both. UVM Connect will still allow connections from SC initiator sockets to SV target UVM sockets, but a run-time fatal error will occur if a blocking call is made to a non-blocking UVM socket (e.g. uvm_tlm_nb_target_socket) or a non-blocking call is made to a blocking UVM socket (e.g. uvm_tlm_b_target_socket). Refer to Mantis 3682 (http://www.eda.org/svdb/view.php?id=3682)
• The uvm_tlm_generic_payload needs several fixes. Refer to (http://www.eda.org/svdb/view.php?id=3983)
• UVM does not fully implement TLM1 non-blocking interfaces. The ok_to_put, ok_to_get, and ok_to_peek methods are defined in the standard to return an event that is triggered once the non-blocking port is able to complete a put, get, or peek operation, respectively. Calls to these interface methods by connected SC-side ports will produce a run-time error and return an event that will never trigger.

Issues associated with starting SystemC and SystemVerilog

SystemC typically elaborates and begins simulation before SystemVerilog has completed elaboration. If the SC side attempts to communicate with SystemVerilog too early, you may get run-time errors or undefined behavior. SC-side ports that are bound to SV-side exports or imps are especially vulnerable to this condition. UVM Connect tries to prevent this from happening in two different ways:

• All UVM Command functions block until SV is ready
• All SC-side calls to TLM ports that are registered for connection across the language boundary will block until its cross-language connection is made.

The implication is that UVMC TLM and Command calls must be made from an SC thread process.

This section describes how to run the examples included in this kit. The examples show how UVMC can be used to integrate IP in a mixed SC and SV environment, without modifying existing IP.

Before attempting to run the examples, be sure to review the Getting Started section. Check for support for your platform, confirm that the UVM and UVMC libraries are compiled, and make sure your environment variables are set properly.

The UVM Connect kit provides examples in four major categories--connections, converters, field type support, and UVM commands

All examples can be found in the $UVMC_HOME/examples directory. Before attempting to run any example, be sure you have prepared your environment and compiled the UVM and UVMC libraries. See Getting Started for how to do this.

To run the examples, cd into the examples directory for the category of your choice (connections, converters, commands, field_types). Then type make or make help to get a menu of examples to run in that category.

Most examples utilize a common set of simple producer, consumer, and scoreboard models. The models use standard SystemC / UVM coding guidelines and provide standard TLM ports and exports for external communication. None of the models contain references to UVM Connect or any other external context, which is as it should be.

To run an individual example, cd into the examples directory of your choice.

> cd $UVMC_HOME/examples/commands

Type make without any arguments to get a list of all available examples in that directory.

Then, select an example from the menu. For eaxmple

> make phasing

This runs the ‘phasing’ example with the UVM source location defined by the UVM_HOME environment variable and the UVM and UVMC compiled libraries at their default location, ../../lib/uvmc_lib.

To run all UVM Command examples

> make all

The clean target deletes all the simulation files produced from previous runs.

> make clean

You can also combine targets in one command line

> make clean reporting

Mind your ENV

It is important that you use the same value for UVM_HOME and UVMC_HOME for compiling and running examples as for compiling the libraries themselves. The best way to ensure this is to define the environment variables once, perhaps using a shell script or .cshrc file.

> source my_uvmc_setup.shSetting required UVM and UVMC environment variables...> cd $UVMC_HOME/lib> make clean all>> cd ../examples/commands> make all> cd ../converters> make all> ...

Running the examples outside the install tree

To run the examples outside the UVMC_HOME install tree, all four environment variables must be defined either as environment variables or via the make command line. See Getting Started for details.

Each example directory relies on a master Makefile in the root examples directory. Copy the entire examples directory from the install location into a local, writable area, perhaps in your HOME directory or a shared workspace. Then cd to any subdirectory and run make as before.

Running all the examples as a regression test

If you would like further guidance on a good template script that can be used for environment setups, please see the section entitled Regression testing below. That section goes into considerable detail on environment setups that will work for all examples in included in this package and can be used to drive automated regression test procedure.

A partial list of sources for information on SystemC, SystemVerilog, UVM, and related topics

• [1] Standard SystemC Language Reference Manual; IEEE 1666-2011, March 8, 2011. http://standards.ieee.org- /getieee- /1666- /download- /1666-2011.pdf
• [2] IEEE Standard for SystemVerilog-Unified Hardware Design, Specification, and Verification Language; IEEE 1800-2009; December 11, 2009
• [3] OSCI TLM 2.0 Language Reference Manual, version TLM 2.0.1, Document JA32; copyright Open SystemC Initiative, July 2009 (absorbed into [1] above)
• [4] Universal Verification Methodology (UVM) Accellera; http://www.accellera.org/activities/vip
• [5] Verification Academy - http://verificationacademy.com
• [6] UVM Cookbook - http://verificationacademy.com/uvm-ovm
• [7] UVM World - http://uvmworld.com
• [8] “Are UVM/OVM Macros Evil? A Cost-Benefit Analysis”; DVCon 2011, Feb 2011. http://verificationacademy.com- /uvm-ovm- /MacroCostBenefit

//------------------------------------------------------------//// Copyright 2009-2015 Mentor Graphics Corporation //// All Rights Reserved Worldwide //// //// Licensed under the Apache License, Version 2.0 (the //// "License"); you may not use this file except in //// compliance with the License. You may obtain a copy of //// the License at //// //// http://www.apache.org/licenses/LICENSE-2.0 //// //// Unless required by applicable law or agreed to in //// writing, software distributed under the License is //// distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR //// CONDITIONS OF ANY KIND, either express or implied. See //// the License for the specific language governing //// permissions and limitations under the License. ////------------------------------------------------------------//