The Open Verification Methodology has made SystemVerilog the language of choice for building verification infrastructures.

Imagine (or maybe you don’t have to) that you have to build an infrastructure for verifying a 100-million-gate system-on-a-chip (SoC) design. Obviously, the entire design can’t be verified at once. First, you need to verify the individual blocks—then the subsystems containing several blocks, and finally the entire system—but only after the composite pieces have been verified. Many of the blocks will have identical interfaces. You don’t want to start over for each block or subsystem. To the extent that there are similarities between them, you want to reuse work you’ve already done on each block or subsystem. You also will need to generate a vast amount of data to exercise the interesting aspects of the design—including the corner cases. Finally, you need to make sure that it behaves properly when presented with bad data. How do you approach a problem of this magnitude? You apply a repeatable and rigorous verification methodology, such as the Open Verification Methodology (OVM). The OVM was built on top of SystemVerilog specifically to address these sorts of verification problems.

SystemVerilog is now the de-facto standard language for building testbench infrastructures for functionally verifying register-transfer-level (RTL) designs. The use of other languages (like Verilog, VHDL, C, C++, and Perl) for testbench construction and assertions is in decline. Yet SystemVerilog is rising to the top, according to an industry-wide survey of engineers released by Far West Research in 2008. This wasn’t always the case. So how did SystemVerilog become the king of verification languages?

In recent years, the SystemVerilog language has certainly matured. When it first became available commercially, there were great differences in the SystemVerilog support of each vendor’s offering. As the standard emerged from Accellera and the IEEE, each company’s engineering team—working independently from its competitors—was left to interpret SystemVerilog on its own. It’s natural to assume that separate individuals reading a text of any sort would come away with a different view of its contents. So it’s not surprising that each team took a unique approach that it felt best served its company’s interests. As a result, SystemVerilog code that was written to run on one company’s tools wouldn’t necessarily work on another’s. Now, we’re seeing the gaps being closed as customers require multiple vendor support for SystemVerilog. This process is all part of the natural evolution of an emerging standard.

What drives this maturation of the language? Simply put, customer demand is the driving force behind the continuing growth and evolution of SystemVerilog. As more design and verification teams adopt the language for production usage, more stringent requirements are placed on the tool vendors. Those vendors have responded with better implementations and stronger toolsets. Of course, this begs the question: What is driving customer demand? The answer is verification. Building the software infrastructure necessary to verify a sophisticated SoC design is a non-trivial undertaking. It requires industrial-strength languages and tools that are up to the task. Verilog—the predecessor and now companion of SystemVerilog—is very well suited for creating designs. But it isn’t so well suited for building verification infrastructures.

The designers of SystemVerilog set out to augment Verilog with language features for building verification infrastructures. Rather than trying to shoehorn verification features into other languages, they wanted a single language that worked well for design (synthesizable constructs) and verification. What follows is a quick look at what some of those things are and why they’re important.

The ABCs Of Infrastructure
Classes and inheritance: Classes provide a means for encapsulating data and functionality into a single scope. Doing so prevents unwanted dependencies from creeping into the code, which would kill reusability. Inheritance—as the means for creating one class from another—is a primary means of reusing existing code. With inheritance, one can create a new class that extends the functionality of another class, letting the developer reuse code from the base class.

Parameterized classes: Parameterization lets the developer write generic code—code that’s independent of a particular data type, size, or other parameterizable characteristic. This capability increases the reusability of code.

Randomization and constraints: Creating properly randomized stimulus can be difficult. SystemVerilog provides the ability to randomize data in a class with a single call. The randomized data can be constrained to fit within specific simple ranges or to satisfy arbitrarily complex dependencies. Without this feature, the testbench writer is left with the problem of how to generate randomized data. In addition, he or she has to make sure that every newly generated datum is self-consistent and correct with respect to the application or protocol.

Random stability: Repeatability of results is important when verifying designs. However, minor changes in a testbench can perturb the random-number generators, causing the stream of random numbers to be different from run to run. Reconciling the results between runs (with different streams of random numbers) can be difficult or even impossible. To guarantee that random-number streams remain consistent between runs, SystemVerilog supports multiple, independent random-number generators and a means for generating and distributing random seeds.

Interfaces: In Verilog, binding ports with large numbers of pins can be a tricky thing. You have to match either pin names or pin ordering exactly. Usually, small changes in a port list of the device under test (DUT) require tedious changes throughout the testbench to ensure that everything still matches. The interface construct in SystemVerilog simplifies this problem. It enables one to treat all of the pins on a port list as a single bundle and connect them as a single entity. The compiler takes care of name matching. Virtual interfaces, which are references to interface instances, allow the developer to connect static modules to dynamic classes, thereby enabling classes to interact with modules.

Dynamic data: When writing any sort of code, it’s not always possible to know the exact size of certain data structures or the number of elements that will be processed at any given time. SystemVerilog provides dynamic data to deal with these kinds of situations. Queues, dynamic arrays, and linked structures are all ways of managing data sets with sizes that aren’t known until run time

Mastering The Finer Points
All of these language features exist in some form or another in other languages. Java, C++, even Perl and TCL, Haskell, Ruby, C#, and a whole host of new languages support these kinds of functionality. Why not just use one of them? They’re all general-purpose languages for building all kinds of applications. In other words, they aren’t specifically intended for building testbenches. The problems with using these languages fall into essentially two categories: consistency of data types and ease of creating linkages.

Consistency of data types refers to the challenge of manipulating data types in the testbench in a way that’s consistent with the data types in the design. For example, Verilog supports bit vectors of arbitrary length but C does not. One can create a verification library in C that supports arbitrary-length bit vectors. Although this has been done, it requires conversion of the C and Verilog (design) data as it’s transferred between language domains. If all of one’s work is done in a single language, data conversion is less of a concern.

The linkage problem involves binding the hardware to the testbench and linking modules from other compilers into the simulation environment. The problems associated with linking code that was written in different languages are obvious. One has to link the executable code, make sure that symbols are visible, and enable them for execution—usually through a programming language interface (PLI) or direct programming interface (DPI).

Data conversions can be expensive in terms of performance degradation. In addition, tricky linkages can lead to a fragile infrastructure. Because it is a testbench specialist, SystemVerilog eliminates these problems. Including all of the aforementioned features in a single language eliminates the problems associated with data conversion and linking in modules written in other languages. Through virtual interfaces, SystemVerilog provides an elegant means to bind the class-based testbench to hardware modules. The scheduling semantics of interfaces are well defined in SystemVerilog as well. As a result, issues relating to race conditions or missed events (between the DUT and testbench) are easily resolved.

The King Maker
With all of these features in a single language, one now needs a methodology that provides a consistent, repeatable way to utilize them. This methodology must help the developer to effectively take advantage of the features of a language as complex as SystemVerilog: to efficiently build high-quality verification infrastructures and—perhaps more importantly—to create elements of the verification infrastructure in a reusable fashion.

Here’s where OVM comes in. It is exactly that—a methodology that provides a way to take advantage of the sophistication of SystemVerilog and do so in a way that enables one’s work to be highly reusable. OVM is the quintessential application for SystemVerilog. As such, it has grown rapidly in popularity. In fact, since its initial release in January 2008, there have been nearly 20,000 OVM downloads by over 2000 different companies from the ovmworld.org website.

OVM provides a collection of utilities that enable the developer to build hierarchies of testbench components, connect them to each other through TLM ports and exports, and connect them to the hardware through virtual interfaces. It contains a special data structure called the factory, which allows one to override instances of components with other components from the same family of derived classes. With its configuration facility, the developer can create “hooks” that let one alter the structure and behavior of a component without changing its code. The methodology shows the user how to create reusable testbench elements. Called open verification components (OVCs), these elements encapsulate protocols. All of this is built on top of the functionality provided by SystemVerilog.

Figure 1: This depiction of the OVM testbench organization has components arranged in concentric layers.

In addition, OVM provides a means for reuse. Reuse saves the developer from starting from scratch on each project. In addition, it allows him or her to build upon what others have done before. OVM takes advantage of SystemVerilog features—classes, inheritance, parameterization. It then adds new features, such as the factory and configuration facilities, to create a framework for building well-structured, highly reusable testbench elements.

The emergence of OVM has fueled the eminence of SystemVerilog. In essence, OVM has elevated SystemVerilog as the language of choice for building verification infrastructures by delivering on the promise to provide a way to verify designs within a single language domain. Solving the problems associated with building complex testbenches will lead developers to SystemVerilog, which in turn will lead them to OVM. No longer is it the case that SystemVerilog is an outside language used by a fringe of early adopters. Clearly, the popularity of OVM shows that SystemVerilog and OVM are now the mainstream technology for functional verification.

Mark Glasser is a verification technologist at Mentor Graphics, where he is responsible for the development of verification methodologies. Glasser is the co-author of two patents relating to transaction recording technology. He also is the author of The OVM Cookbook. Glasser is a member of the board of directors of OSCI and a member of the SPIRIT verification working group. He holds a BS in computer science from California State University, Northridge.