Published on March 23rd, 2007

SystemVerilog Transmigrations Lead to Flexible and Interoperable Verification

Using standard object-oriented-programming techniques, one can implement the same functionality found in aspect-oriented programming to modify classes and behavior.
Within the next two years, a recent industry survey stated that 70% of North American designers are expected to be using SystemVerilog. SystemVerilog offers useful advanced verification features like assertions, constrained randomization, functional coverage, and testbench constructs. This open, nonproprietary language brings with it all of the good things that standards deliver. It supports interoperability, reuse, global teamwork, the use of third-party intellectual property (IP), and verification IP (VIP). In addition, it is supported by new tools and methodologies--some of which have been specifically built to take advantage of the language itself.

Because SystemVerilog offers such benefits, a designer may find him- or herself in a position where the decision to use it has been made by corporate fiat or the dictates of a new project or manager (see Figure 1). The designer must then figure out how to move from his or her current language to this one. At AMCC, we faced this challenge when we decided that it was to our advantage to move from an aspect-oriented-programming (AOP) to an objectoriented- programming (OOP) language. We also wanted to go with a non-proprietary standard.

AMCC was using a popular set of tools for testbench automation and system-level verification including the Verisity e language. But we wanted to move to a standards-based design and verification flow to get the global design and verification teams on a common language, better accommodate the use of verification IP, and encourage standardization with suppliers. SystemVerilog met those criteria while elevating the methodology with capabilities like unified coverage with assertions and formal proofs. It also offered traditional hardware-verification-language (HVL) functional-coverage points derived from the coverage-drivenverification (CDV) process. The e language didn't support formal proofs using SystemVerilog assertions. In addition, SystemVerilog allowed us to integrate our different toolsets within a single source for both simulation and formal verification.

Figure 1
Figure 1: The use of SystemVerilog and SystemC is growing rapidly worldwide.

At the time, we were working on an integrated communication processor that presented some tricky spots for the verification of its dataplane and control-plane functions. We needed to find a way to transition from e to SystemVerilog in a relatively painless and timely fashion. We found support from Mentor Graphics- -particularly through its Advanced Verification Methodology (AVM) and Questa Advanced Verification Environment. Both of these offerings were conceived and realized with SystemVerilog in mind. In addition, Mentor Consulting provided expertise to help us move to a new language.

At the time, we were working on an integrated communication processor that presented some tricky spots for the verification of its dataplane and control-plane functions. We needed to find a way to transition from e to SystemVerilog in a relatively painless and timely fashion. We found support from Mentor Graphics- -particularly through its Advanced Verification Methodology (AVM) and Questa Advanced Verification Environment. Both of these offerings were conceived and realized with SystemVerilog in mind. In addition, Mentor Consulting provided expertise to help us move to a new language.

The AVM "Verification Cookbook" library components, such as examples of stimulus generators and functional coverage in monitors, also eased the transition to SystemVerilog. Mentor's real-world experience with SystemVerilog OOP implementations is captured in the AVM Cookbook examples. It allowed the AMCC team to bring its own verification expertise to bear in the new language very quickly. The AVM makes it very easy to share this captured and encoded knowledge base among different working groups and on future projects. The library set the stage for implementing and adding AMCC VIP that's reusable on multiple projects under the AVM framework. Another bonus was that AVM supports both SystemVerilog and SystemC. In addition, it includes implementations of the same base classes under both languages. This dual-language support strengthens the interoperability between the modeling and verification disciplines. The result was a reusable, advanced verification flow that bridges design and verification teams and multiple projects.

As a recent EETimes survey showed, the most important languages to emerge for advanced design and verification are SystemVerilog and SystemC. It is therefore worth saying a little about the relationship between the two. Both languages share the ability to model higher levels of abstraction by supporting object-oriented programming. In addition, both contain verification components like randomization. There are some differences. For instance, SystemC supports transaction-level modeling (TLM) including the describing, recording, and viewing of transactions at high levels of abstraction. SystemVerilog doesn't yet fully support TLM. Yet it does deliver significant verification advantages through the support of assertions, functional coverage, and improved constrained random test generation. The two languages overlap somewhat in their capabilities, thereby providing a smooth transition when building systems using both of them.

The SystemVerilog direct programming interface (DPI) provides the necessary high-performance, easy-to-use link between SystemC and SystemVerilog. Using the SystemVerilog DPI, system architects and software engineers can design in SystemC and then move directly to the SystemVerilog domain for verification. This capability allows them to take advantage of constrained random techniques, testbench automation, assertions, and functional coverage.

Because it is a direct connection, the SystemVerilog DPI is easier and faster than a standard application-programming interface (API), such as a programming language interface (PLI). The objectoriented features of SystemVerilog make it easier to create reusable test environments by allowing constraints and other aspects to be controlled or overridden via inheritance. For those who aren't ready or willing to pursue object-oriented programming, however, the ability to write tests and constraints at the transaction level greatly enhances the effectiveness of the tests (see Figure 2).

Figure 2
Figure 2: The SystemVerilog DPI opens a common communication channel that enables testbench reuse across many languages and engines.

To show precisely how an e user goes about making the transition to SystemVerilog, we'll compare how e and SystemVerilog handle abstract factory patterns. In doing so, it's possible to demonstrate how easy it is to replicate the AOP functionality of e in SystemVerilog OOP. For e users, AOP is a known, good mechanism for modifying, adding, or inserting functionality to a class. Fortunately, these goals can be easily achieved using OOP techniques in SystemVerilog. Because the difference isn't that great, the learning curve is gentle.

Ultimately, the difference between OOP and AOP comes down to the organization of the code. In AOP, the code is organized by functionality and it's easy to layer new code into existing environments. Yet it also is very easy for a project code base to grow into an unorganized and scattered set of code fragments, thereby disrupting existing and working functions. New code is often placed in new files. The number of files can grow out of control, producing implications and placing extra burdens on the project file importing and dependency ordering. This can wreak havoc in large projects, where there are many contributors to the verification environment. The team will then feel like it is taking backward steps and become hesitant to touch anything that already works.

In OOP, code is organized by objects and classes. Simply put, an object is a bundle of related members (variables) and methods (functions and tasks). A class is a prototype that defines the properties (variables, tasks, and functions) common to all objects of a certain kind. For example, an Ethernet packet and all of its related methods can be modeled as a class object.

Factory patterns provide an easy way to replicate the AOP functionality of e in SystemVerilog. Say, for example, a class called EtherPacket is instantiated throughout a design with a certain number of properties (variables, methods, and constraints). The designer wants to make a change to some constraints under the following two conditions: He or she wants either the changes reflected everywhere in the design or EtherPacket to be completely replaced functionality-wise by EtherLargePacket (another class derived from PacketBase). But the designer doesn't want to modify the base or EtherPacket class.

In e, the class is extended without changing the structure name. As a result, every instantiation is changed globally. This aspect makes life very difficult if the intent is to change only 99 out of 100 base-class instantiations. It also becomes a challenge when there are other object modifications during the project life cycle that need to re-define or reflect back into existing structures. In SystemVerilog, factory patterns will allow the designer to perform such tasks.

The following class forms the base class:

class PacketBase;
  byte header;
  rand bit[7:0] src;
  rand bit[5:0] len;
  rand bit [7:0] payld [];
  constraint payload_size {payld.size >0 ;
  payld.size < 15;}
  constraint c1 { foreach(payld[i]) { (payld[i])
  == 'hff; }}
  virtual function show;
  $display("PacketBase=%h %h %h",src,len,payld);

Next, the class can be extended by replacing and adding properties as follows:

class EtherPacket extends PacketBase;
  rand bit[15:0] len;
  constraint c1 { src inside {[8'h2A:8'h2F]};}
  constraint c2 {len inside{ [64:1518] };}
  constraint payload_size {payld.size >15 ;
  payld.size < 20;}
  constraint c3 { foreach(payld[i]) { (payld[i])
  == 'haa; }}
  virtual function show;
  $display("EtherPacket=%h %h
endclass : EtherPacket

Notice that the function show is redefined and a variable len is added, which is 16-bits wide. There are now two different len variables--one in the base class and one in the subclass. The reason for this is that virtual methods have polymorphism, not members. OOP users utilize polymorphism to create factory patterns that mimic the AOP functionality of e. In SystemVerilog, methods called using polymorphism must be declared as virtual. The constraints also are new.

The essence of the factory pattern is next. First, define an intermediate class, stim_fact, as follows:

class stim_fact;
  static function PacketBase create_stim;
  EtherPacket s = new;
  return s;
endclass : stim_fact

The purpose of the intermediate class is to return a class handle of the user's choice--either the base class or any of its derived classes. The reason it works is polymorphism. It is fully legal to assign a derived class handle to a base-class object, but not vice versa. Therefore, the class that is used in a design (for example, PacketBase or EtherPacket) is controlled from stim_fact. As a result, the designer can essentially mimic AOP while fully retaining OOP functionality, as he or she can still independently instantiate PacketBase or EtherPacket.

For example, given the following code:

class stim_gen;
task run;
PacketBase s;
  s = stim_fact::create_stim;
endclass: stim_gen

which produces:

qverilog ./src/
# vsim -do {run -all; quit -f} -l qverilog.log -c
# run -all
# EtherPacket=2a 013b aa aa aa aa .
# EtherPacket=2f 008d aa aa aa aa .
# EtherPacket=2a 0116 aa aa aa aa aa .
# EtherPacket=2f 042b aa aa aa ..
# EtherPacket=2a 018d aa aa aa .
# EtherPacket=2c 0236 aa aa aa aa aa aa .

First, an object of the base type is instantiated. Next, a function is called from the intermediate class, which returns a handle to a class of the designer's choosing (in other words, either the base class or the derived classes). From that point on, whenever the base-class handle is randomized, the designer is essentially randomizing the extended class--all controlled from a central location.

By using standard OOP techniques, one can implement the same functionality as in AOP to modify classes and customize or modify behavior without breaking previously known "good" code. This is the basic capability underlying any advanced verification methodology, regardless of the language that is used to implement it. When SystemVerilog, a truly unified hardware design and verification language, is applied to the problem, the designer can quickly construct extensible and reusable testbench environments to take advantage of functional coverage, assertions, and testbench automation. In the proverbial sense, AOP and OOP are simply two ways of skinning this particular cat. e users that choose to or must use SystemVerilog will find that it is very easy to accomplish the same verification objectives as in e.
Pete LaFauci recently joined Mentor Graphics from AMCC, where he was a Senior Principal Design Engineer. At AMCC, LaFauci was responsible for establishing and setting company direction in functional verification. Recently, AMCC consolidated on Mentor tools and transitioned to the SystemVerilog platforms for simulation and formal verification. With 18 years of experience in the chip-verification field, LaFauci brings tremendous field experience in guiding new efforts and helping Mentor customers move to open standards for functional verification. LaFauci is an Application Engineer Consultant at Mentor Graphics Corp., Durham, North Carolina, e-mail:

Allan Crone is a Technical Marketing Engineer in the Questa functional-verification group at Mentor Graphics. Since joining Mentor in 1998, Crone has held a variety of technical positions in synthesis, design-for-test, and dynamic and formal verification. Prior to joining Mentor Graphics, he was R&D engineer, ASIC methodology manager, and applications engineer. Crone holds an Electronics Engineering Technology degree from the Technical University of Copenhagen, Denmark. He is a Technical Marketing Engineer at Mentor Graphics Corp., Kista, Sweden, e-mail:

Tech Videos

©2019 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.