Universal Verification Methodology

Last updated

The Universal Verification Methodology (UVM) is a standardized methodology for verifying integrated circuit designs. UVM is derived mainly from the OVM (Open Verification Methodology) which was, to a large part, based on the eRM (e Reuse Methodology) for the e verification language developed by Verisity Design in 2001. The UVM class library brings much automation to the SystemVerilog language such as sequences and data automation features (packing, copy, compare) etc., and unlike the previous methodologies developed independently by the simulator vendors, is an Accellera standard with support from multiple vendors: Aldec, Cadence, Mentor Graphics, Synopsys, Xilinx Simulator(XSIM).

Contents

History

In December 2009, a technical subcommittee of Accellera — a standards organization in the electronic design automation (EDA) industry — voted to establish the UVM and decided to base this new standard on the Open Verification Methodology (OVM-2.1.1), [1] a verification methodology developed jointly in 2007 by Cadence Design Systems and Mentor Graphics.

On February 21, 2011, Accellera approved the 1.0 version of UVM. [2] UVM 1.0 includes a Reference Guide, a Reference Implementation in the form of a SystemVerilog base class library, and a User Guide. [2]

Factory

A factory is a commonly-used concept in object-oriented programming. It is an object that is used for instantiating other objects. There are two ways to register an object with the UVM factory. In the declaration of class A, one can invoke the `uvm_object_utils(A) or `uvm_component_utils(A) registration macros. Otherwise, the `uvm_object_registry(A,B) or `uvm_component_registry(A,B) macros can be used to map a string B to a class type A. [3] The UVM factory provides a variety of create methods that allow the user to instantiate an object with a particular instance name and of a registered type. [4]

Sequencer

The sequencer is responsible for three main functions:

Initialization

In this stage the DUT (Device Under Test) and the environment it is in should be set to the conditions desired before the simulation. Likely, this includes:

Scoreboard

Description

A scoreboard can be implemented in various ways. Generally speaking, a scoreboard takes the inputs to and outputs from the DUT, determines what the input-output relationship should be, and judges whether the DUT adheres to the specification. This input-output relationship is often specified by a model, called a predictor. [5] The predictor may be implemented in a higher-level programming language, like SystemC.

Implementation Details

UVM scoreboard classes are implemented as subclasses of the uvm_scoreboard class, which itself is a subclass of uvm_component. uvm_scoreboard is a blank slate for implementing a scoreboard. It only contains one class method, namely the "new" constructor method. The rest of the implementation is user-defined. [6]

Agent

Description

In modern VLSI, a DUT may have multiple interfaces. Each of these interfaces may have different UVM objects associated with them. For instance, if the DUT is the full-chip, there may be separate interfaces for PCI, Ethernet, and other communication standards. The scoreboard and monitor for a PCI interface will be different from the ones for the Ethernet interface. The various UVM objects can be organized as members of a wrapper class known as an agent. Passive agents will only analyze port values of the interface and should contain a monitor member. Active agents will drive ports and should contain a driver member, perhaps in addition to a monitor member. [7]

Implementation Details

UVM agent classes are implemented as subclasses of the uvm_agent class, which itself is a subclass of uvm_component. Much like uvm_scoreboard, uvm_agent is lightweight in terms of class methods. Its only class methods are the "new" constructor and the "get_is_active" method. If the agent is being used to drive ports, get_is_active returns UVM_ACTIVE. Otherwise, get_is_active returns UVM_PASSIVE.

Driver

Description

Sequence items for a test are described abstractly. For example, if the DUT is a register file, it may have ports for a read address and a write address. The sequence item object may have member variables for the read address and the write address. However, these values need to eventually become bits at the input pins to the DUT. [8] There may even be an exotic encoding used when providing the stimulus to the DUT that should be abstracted from the rest of the agent. The driver's responsibility is to take these sequence items and provide the proper stimulus to the DUT's ports. [5]

Implementation Details

UVM driver classes are implemented as subclasses of the uvm_driver class, which itself is a subclass of uvm_component. [6]

Definitions

UVM Macros

UVM allows the use of Macros

namefunctionrelated toparameterspurposeType of Macro
`uvm_createobject constructor`uvm_sendSequence or Itemto create the object and allow user to set values via overloading or parameter passingSequence action macro
`uvm_sendprocessor`uvm_createSequence or Itemprocesses what is created by `uvm_create without randomizationSequence Action Macros for Pre-Existing Sequences
`uvm_doprocessor`uvm_createSequence or Itemexecutes class or item with randomizationSequence action macro

Related Research Articles

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state and implementations of behavior. In many languages, the class name is used as the name for the class, the name for the default constructor of the class, and as the type of objects generated by instantiating the class; these distinct concepts are easily conflated. Although, to the point of conflation, one could argue that is a feature inherent in a language because of its polymorphic nature and why these languages are so powerful, dynamic and adaptable for use compared to languages without polymorphism present. Thus they can model dynamic systems more easily.

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:

Java Platform, Standard Edition is a computing platform for development and deployment of portable code for desktop and server environments. Java SE was formerly known as Java 2 Platform, Standard Edition (J2SE).

In computer engineering, a hardware description language (HDL) is a specialized computer language used to describe the structure and behavior of electronic circuits, and most commonly, digital logic circuits.

In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class. The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern as well as to the Open-Closed Principle, by allowing the functionality of a class to be extended without being modified. Decorator use can be more efficient than subclassing, because an object's behavior can be augmented without defining an entirely new object.

In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions.

<span class="mw-page-title-main">Accellera</span>

Accellera Systems Initiative (Accellera) is a standards organization that supports a mix of user and vendor standards and open interfaces development in the area of electronic design automation (EDA) and integrated circuit (IC) design and manufacturing. It is less constrained than the Institute of Electrical and Electronics Engineers (IEEE) and is therefore the starting place for many standards. Once mature and adopted by the broader community, the standards are usually transferred to the IEEE.

SystemC is a set of C++ classes and macros which provide an event-driven simulation interface. These facilities enable a designer to simulate concurrent processes, each described using plain C++ syntax. SystemC processes can communicate in a simulated real-time environment, using signals of all the datatypes offered by C++, some additional ones offered by the SystemC library, as well as user defined. In certain respects, SystemC deliberately mimics the hardware description languages VHDL and Verilog, but is more aptly described as a system-level modeling language.

The Perl Object Environment or POE is a library of Perl modules written in the Perl programming language by Rocco Caputo et al.

<span class="mw-page-title-main">Class diagram</span> Type of static structure diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations, and the relationships among objects.

<span class="mw-page-title-main">SystemVerilog</span> Hardware description and hardware verification language

SystemVerilog, standardized as IEEE 1800, is a hardware description and hardware verification language used to model, design, simulate, test and implement electronic systems. SystemVerilog is based on Verilog and some extensions, and since 2008, Verilog is now part of the same IEEE standard. It is commonly used in the semiconductor and electronic design industry as an evolution of Verilog.

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructors, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed acyclic graph.

Functional verification is the task of verifying that the logic design conforms to specification. Functional verification attempts to answer the question "Does this proposed design do what is intended?" This is complex and takes the majority of time and effort in most large electronic system design projects. Functional verification is a part of more encompassing design verification, which, besides functional verification, considers non-functional aspects like timing, layout and power.

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

e is a hardware verification language (HVL) which is tailored to implementing highly flexible and reusable verification testbenches.

Aldec, Inc. is a privately owned electronic design automation company based in Henderson, Nevada that provides software and hardware used in creation and verification of digital designs targeting FPGA and ASIC technologies.

Catapult C Synthesis, a commercial electronic design automation product of Mentor Graphics, is a high-level synthesis tool, sometimes called algorithmic synthesis or ESL synthesis. Catapult C takes ANSI C/C++ and SystemC inputs and generates register transfer level (RTL) code targeted to FPGAs and ASICs.

The Open Verification Methodology (OVM) is a documented methodology with a supporting building-block library for the verification of semiconductor chip designs. The initial version, OVM 1.0, was released in January, 2008, and regular updates have expanded its functionality. The latest version is OVM 2.1.2, released in January, 2011.

<span class="mw-page-title-main">Composition over inheritance</span> Software design pattern

Composition over inheritance in object-oriented programming (OOP) is the principle that classes should achieve polymorphic behavior and code reuse by their composition rather than inheritance from a base or parent class. This principle of OOP is discussed in the book Design Patterns (1994).

References

  1. ↑ Accellera Status
  2. 1 2 "404".{{cite web}}: Cite uses generic title (help)
  3. ↑ "Universal Verification Methodology (UVM) 1.2 User's Guide" (PDF). p. 130.
  4. ↑ "UVM Factory".
  5. 1 2 https://www.accellera.org/images/downloads/standards/uvm/uvm_users_guide_1.2.pdf [ bare URL PDF ]
  6. 1 2 https://www.accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf [ bare URL PDF ]
  7. ↑ "UVM Rapid Adoption: A Practical Subset of UVM" (PDF). p. 10.
  8. ↑ "UVM Sequence item".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.