SystemVerilog Reference Verification Methodology: VMM Adoption

This is the last in a series of four articles outlining a reference verification methodology that meets these goals for both RTL and system-level verification. This methodology is enabled by the SystemVerilog hardware design and verification language standard and is documented in the Verification Methodology Manual (VMM) for SystemVerilog, a book jointly authored by ARM and Synopsys. This article focuses on ways to adopt the VMM methodology and deploy it quickly throughout an entire SoC project.

Methodology Adoption

Advanced verification techniques are not always adopted easily; verification teams are not just sitting around looking for something new to try. Instead, they investigate new approaches when older methods break down due to designs growing larger and more complex. Techniques such as constrained-random stimulus generation, coverage-driven verification, assertions, and formal analysis moved from theory to practice precisely because they were needed for real designs in real projects.

Thus, adoption of the techniques recommended in the VMM for SystemVerilog may occur when the most recent SoC project has suffered serious bugs in silicon. However, many verification teams are well aware of the limitations of older methods and do recognize the challenges of new projects before disaster strikes. In either case, the goal is to get up to speed on the VMM methodology as quickly as possible.

There are really two forms of adoption required in order to benefit fully from the book. One is embracing the general verification techniques that the reference methodology supports. For example, engineers unfamiliar with the concept of adding assertions or properties need to become comfortable with this approach independent of whatever assertion language or library they may use. Similarly, adopting constrained-random stimulus generation requires familiarity with the role of constraints, regardless of the language used.

The object-oriented nature of the VMM methodology may seem to be the biggest hurdle for some of the engineers considering adoption. Encapsulation, classes, inheritance, extensions, and other aspects of object-oriented programming do require thinking about the verification environment differently than with a traditional testbench. Fortunately, many engineers have had some exposure to languages such as C++ and Java, so they just need to carry their object-oriented concepts into the verification domain.

The other form of adoption is using the SystemVerilog-specific techniques in the book, which is aided greatly by the building-block libraries specified in the appendices. While it's true that comfort with the general verification concepts can help with adoption of the methodology for SystemVerilog, it's also the case that the SystemVerilog libraries help users understand the concepts. For example, the assertion-checker library suggests concrete places to place assertions and the base-class library is a great starting point for using object-oriented verification.

The VMM for SystemVerilog specifies four libraries that help accelerate and ease adoption:

• The VMM Standard Library, a set of SystemVerilog testbench base and utility classes
• The VMM Checker Library, a set of SystemVerilog assertion checkers
• The XVC Standard Library, a set of SystemVerilog system-level base and utility classes
• The Software Test Framework, a C library for software verification

Using these libraries allows development teams to get started more quickly and easily when setting up their verification environments. Users of these libraries have reported saving at least several months in the early phases of projects. Further, adoption of standard libraries establishes consistency among different users, across multiple projects, and with vendors providing VMM-compliant verification components.

The following sections provide brief overviews of the four libraries.

The VMM Standard Library

As described in the second article of this series, the VMM for SystemVerilog defines a layered testbench architecture that supports advanced verification and fosters reuse. The control of this testbench and the execution of testcases involve a series of well-defined steps under the control of "virtual methods." The VMM Standard Library defines the vmm_env base class to control the run of each test case, as shown in (Fig. 1).

The process shown in (Fig 1) involves generating the test case configuration, building the testbench, resetting the design under test (DUT), configuring the DUT, running the test, performing cleanup at the end, and generating reports. The virtual methods in the vmm_env base class provide the infrastructure for each of these steps, however many of the methods have to be "extended" to perform actions specific to the DUT.

The vmm_log class provides an interface to the VMM message service so that all messages, regardless of their sources, can have a common "look and feel." The message service describes and controls messages based on several concepts:

• Message source (transactor, generator, test case, etc.)
• Message filters (promote, demote, or suppress messages)
• Message type (failure, timing error, debug information, etc.)
• Message severity (fatal error, non-fatal error, warning, etc.)
• Simulator message handling (continue, abort, invoke debugger, etc.)

The vmm_data base class is the basis for all transaction descriptors and data models in the testbench. This class can be extended to build any model appropriate for the particular testbench, for example an Ethernet MAC frame data model or the description of a packet on a serial bus. Transactions are modeled by transaction descriptors, also extended from the vmm_data class. This makes it easier to create streams of random transactions than is the case with traditional procedure calls.

Other classes in the VMM Standard Library include:

• vmm_channel: provides a generic transaction-level interface mechanism
• vmm_broadcast: replicates transactions on multiple channels
• vmm_notify: interfaces to synchronization for concurrent execution threads
• vmm_xactor: serves as the basis for all transactors

Together, all of these classes provide essential building blocks for the overall verification environment, accelerating testbench development while providing the hooks for a wide range of customization to meet the verification needs for the particular design under test. The extensibility of predefined base classes is a key to the object-oriented approach; each verification team can customize the testbench environment and its operation without having to modify the base classes themselves. SystemVerilog source code for the base classes can be helpful when developing proprietary classes, so Synopsys offers a no-cost license for its implementation of the VMM Standard Library.

The VMM Checker Library

The role of assertions in finding more bugs, more quickly has been well-documented for many years. Assertions capture critical designer intent in executable form, isolate design errors close to the source, speed up debug time, and enable formal analysis to find corner-case bugs that might be missed by simulation. Given these advantages, it is surprising that not all design and verification teams use assertions as a matter of course.

One past barrier to assertion adoption is that engineers had to learn special languages and buy expensive tools. Now that SystemVerilog includes powerful assertion constructs that are directly supported by leading simulators, adoption is much easier. In fact, recent surveys have shown a significant increase in assertion usage since SystemVerilog support became available. However, it may still take time for engineers to become comfortable with assertions; it can be hard to "think of what to check."

An assertion-checker library is an excellent way to make it easier to add assertions to RTL designs. The checkers are designed to map to common design elements, such as FIFOs, stacks, arbiters, memories, state machines, and handshake interfaces. Engineers don't have to think about what sort of assertions might be appropriate for these structures; they can simply connect an arbiter's request and grant signals to an arbiter checker or the memory address bus and control signals to a memory checker.

Surveys have also shown the value of assertion-checker libraries; the Open Verification Library (OVL) from the language standards body Accellera has been widely adopted. The VMM for SystemVerilog specifies a superset of OVL that adds support for types of design elements"including arbiters, FIFOs, synchronous and asynchronous memories, and stacks"not covered by OVL. Fig 2 shows the complete set of 50 assertion checkers defined in the VMM Checker Library.

These checkers are implemented as SystemVerilog modules, so they can be placed anywhere in the design or testbench that is legal for module instantiation. Usage is quite simple; the user simply connects the clock, reset, and signals to be checked. For example, the following checker instantiation ensures that two signals, hot and cold, are mutually exclusive (never on at the same time):

Synopsys recently donated its SystemVerilog implementation of the VMM Checker Library to Accellera with the expectation that a future version of OVL will include the full set of assertion checkers defined in the VMM for SystemVerilog.

The XVC Standard Library

As described in the third article of this series, the VMM for SystemVerilog defines the extensible verification component (XVC), a system-level transactor extended from a block-level transactor or a combination of block-level transactors. The book also specifies the XVC standard library, a set of classes for use in building an XVC for system-level verification as shown in (Fig 3).

The XVC manager is an optional verification component responsible for the high-level synchronization of XVCs. The synchronization and XVC control mechanisms can be user-defined according to the need of the system or a specific test. The XVC Standard Library specifies the xvc_manager base class, as well as the pre-defined XVC manager vmm_xvc_manager class, which is implemented as an extension to the base class.

The vmm_xvc_manager class provides several additional elements beyond xvc_manager, including notifications to control actions, a pre-defined command file structure, and a command format that includes action control, event control, interrupts, execution, and logging. Because the command files describe the test scenarios, it is not necessary to recompile the testbench or DUT to run different scenarios. The user can reuse or modify the command files as needed.

The xvc_xactor base class is used to implement XVC-compliant transactors. It is derived from the vmm_xactor class but offers additional features, including trace logging, an input channel (xvc_action_channel) for actions to be executed in order, another input channel for interrupts, and a notification service interface. Finally, the xvc_action base class is used to define the commands and the actions they produce.