There's really no disagreement about the increasing complexity of designing system-on-chip (SOC) devices. It's clear that design is a relatively bounded problem compared to verification. Just as design reuse through semiconductor IP (aka design IP) helped bring the designers up the productivity curve, in the last decade, verification IP (VIP) has done the same for the verification engineers. Two leading methodologies, Verification Methodology Manual (VMM) and Open Verification Methodology (OVM), helped accelerate the adoption of structured verification methodologies using SystemVerilog as well as the creation of commercially available verification IP to independently validate integration of design IP in SOCs. Essentially, both methodologies are a collection of SystemVerilog classes with inherent semantics for their behavior in different phases of the simulation. The user creates verification objects from these classes and attaches them to the design components as traffic/ data generators, monitors, checkers, etc.

Both verification methodologies are built on SystemVerilog, both have been available under Apache license, and both have been successfully deployed in production environments — with one caveat, i.e., as long as the verification IP was built on only one of them and not the other. This is where the problem arises. Many projects acquire VIP from multiple vendors, and occasionally even multiple groups inside a company may have worked independently using different methodologies. Naturally, there's a conflict for integrating such VIPs into one consistent verification environment.

In 2007-08, this was recognized as an issue, and leading users formed the Verification IP Technical Subcommittee (VIP-TSC) under Accellera. By July 2009, 12 recommended practices were formalized in the form of an API to allow interoperability of VMM and OVM VIPs in a single environment. However, it was only seen as the first step in solving a larger problem — that of having publicly available universal base classes that can be used for creating a wide variety of VIPs. Naturally, if all VIPs are based on the same base class library, one doesn't need to go through an interoperability API. This brought to life the second phase of the VIP-TSC efforts — UVM base classes.

The UVM base class is based on SystemVerilog. OVM 2.1.1 was used as the starting point to define UVM. In Accellera's Early Adopter release of the UVM (UVM-EA), there were some enhancements to Callbacks and End-of-Test features, and a new type of Message Catcher callback was added, along with renaming of objects to UVM_*.The VIP-TSC has a list of items that brings features from OVM, VMM and other home-grown methodologies to add to UVM-EA for release 1.0 and beyond. However, current and planned features of UVM base class can be best described as the reflection of collective knowledge of the verification experts participating in VIP-TSC.

But are we just transferring the knowledge from syntactically and semantically different methodologies into a new one? What is the real value to this exercise? If we fast forward by a year, what would the UVM base class release X look like? What features should it have to solve the problems faced a year from now? Three years from now? Are we looking at adding more of the same or making a quantum leap in our ability to deal with much larger and significantly more complex designs? What specifically are we doing to improve our ability to find bugs in the design and then fix them?

This is the time for you to learn more and chime in.

By Dennis Brophy,

Stan Krolikoski,

and Yatin Trivedi.

Dennis Brophy is Director of Strategic Business Development, Mentor Graphics Corp., and Accellera Vice-Chair; Stan Krolikoski is Group Director, Standards and Interoperability, Cadence Design Systems, Inc. and Accellera Secretary; Yatin Trivedi is Director, Standards and Interoperability Programs, Synopsys, Inc., and Accellera Treasurer.