UVM Takes Shape in the Accellera VIP-TSC

UVM is Taking Shape

While you have all been happily verifying your complex SoCs the Accellera VIP Technical Subcommittee (VIP-TSC), otherwise known as the Committee, has been working hard to define UVM. Their work is beginning to pay off. The body of code that will eventually be known as UVM-1.0 is starting to take shape. Today I will give you a short tour through the features of UVM-1.0.

Registers

Mentor and Synopsys collaborated on a register package for UVM. Building on the base data structures from Synopsys VMM RAL, Mentor provided the expertise to “UVM-ize” the package. Along the way the code was optimized and cleaned up to create a high-performance, very flexible register modeling package. This package was chosen by the committee to be included with UVM. For more information see Dennis Brophy’s blog post “Mentor/Synopsys Collaboration Bears Fruit.”

Phasing

In UVM-EA and its predecessor OVM, the phase ordering was represented by a linear list. This proved to be insufficient for complex testbenches, including modeling such things as resets and interrupts. In UVM-1.0 phase ordering will be represented by a directed acyclic graph (DAG). While the term sounds fancy, the idea is pretty simple. The graph-based ordering allows some phases to operate in parallel with other. In the new system it will be easier to add new phases and to integrate IP together that have been built with different phasing schemes.

The set of built-in phases will be:

Initialization Phases

• build
• connect
• end-of-elaboration
• start-of-simulation

Execution Phases

• run
• *pre-reset
• *reset
• *post-reset
• *pre-config
• *config
• *post-config
• *pre-main
• *main
• *shutdown
• *post-shutdown

Termination Phases

• extract
• check
• report
• *final

The starred phases are new ones; the ones without stars are the same phases found in OVM and UVM-EA. The phases are in three groups: initialization, execution, and termination. The initialization phases are the same as in OVM and have the same semantics. The new execution phases will execute in parallel with run. In the termination set final is provided as the very last phase. This allows the possibility of test concatenation where multiple tests are run, each through extract, check, and report. Only when the last test completes is final executed.

TLM-2

TLM-2 has been standardized and available in the SystemC community since 2009. Now, the same facilities will be available for the SystemVerilog community as well. In creating a TLM-2 facility for SystemVerilog, the goal as defined by the Committee is to translate the SystemC TLM-2 LRM into SystemVerilog as faithfully as possible. Because of the differences in SystemC and SystemVerilog there are necessarily some differences in the SystemVerilog and SystemC versions. It’s like translating a poem from English to French. There are a lot of different translations, each of which would be considered “accurate,” but which one best expresses the sense of the original? This can be tricky. The Committee is working hard to ensure the best possible translation.

(As an aside, there is a wonderful book on this topic called “Le Ton beau de Marot: In Praise of the Music of Language” by Douglas Hofstadter [Basic Books, 1997]. The book uses a simple poem written by Clement Marot to discuss the issues and subtleties of translation. I highly recommend it for anyone interested in languages — computer or natural.)

Resources

The configuration system in UVM-EA has many limitations, including the fact that only components can be configured. It’s possible, but not easy to get configuration information into other kinds of objects such as sequences. In UVM-1.0 the set_config/get_config configuration system will be replaced with a more generalized facility called “resources.” It provides a means for storing objects of any data type, not just strings, ints, and things derived from uvm_object, including virtual interfaces. A compatibility layer is also provided that has an implementation of set_config/get_config in terms of resources.

Command Line Options

Everyone who has written any significant testbench code has also written some means to capture command line options and to process them. Now UVM-1.0 will contain a facility that does that for you. It will grab all the command line options and store them in a data structure. You can locate specific ones by name, or you can locate groups using regular expression. You can obtain argument values for those options that take a value.  Additionally some pre-defined command line options are provided for consistency, such as +uvm_set_verbosity, +uvm_timeout, or +uvm_max_count, as well as others.

UVM-1.0 will retain backward compatible with OVM-2.1.1 (save the Os changed to Us) while bringing a wealth of new features and capabilities to testbench writers. I am personally pleased with the technical direction that UVM is taking and I hope you will be too.