UVM Study - Introduction



introduction

The blogs in this column are all related to the study of UVM . Learning reference:

 【1】UVM Tutorial

 【2】Written by Zhang Qiang, UVM Combat (Volume Ⅰ)

 【3】Download UVM (Standard Universal Verification Methodology)

This article first introduces the basic content of UVM.


UVM concept

UVM (Universal Verification Methodology) is an industry-wide standard that enables faster development, reuse of verification environments, and IP verification.

It is a set of class libraries defined using the syntax and semantics of SV, SystemVerilog (IEEE 1800), now an IEEE standard. The main idea behind UVM is to help companies develop modular, reusable and scalable (promotable) testbenches
by providing an API framework that can be deployed across multiple projects . UVM is mainly derived from the open verification method (OVM technology) and supports multiple EDA suppliers, such as Synopsys, Cadence, Mentor and Aldec. The UVM class library provides common tools such as configuration databases, TLMs and component hierarchies in addition to data automation functions such as copying, printing and comparing. It will validate at an abstraction layer that each component in the environment has a specific role. For example, the object of the driving class will only be responsible for driving the signals in the design, while the monitoring is only for monitoring the design interface and not driving the interface signals. The figure below shows a typical verification environment by extending the available UVM classes that are prefixed with uvm_*. These components already have the necessary code to allow them to connect to each other, process packets and cooperate with others synchronously.

It has also undergone many revisions, adding new features and removing some old ones. The reference manual for UVM is available here: Download UVM (Standard Universal Verification Methodology) , which contains a description of the class hierarchy, functions and tasks.

Here are the following descriptions for the download and learning of UVM resources:

1. After clicking the link, select the latest version to download:

 2. After the download is complete, you will get a compressed package named UVM-18002-2020-20tar.gz. Decompression needs to be done through power shell. (Win 10)

Search for powershell:

 

Then open the app.

 After the decompression is complete, the following files are obtained:

 Of course, if you don’t want to bother, go directly to my fan exchange group (there is a link at the end of the article), I have uploaded it to the group file:

 

If you need to learn, it is recommended to directly open the web document shown below:

 You can follow the index on the right to learn systematically:

 

Hierarchy of UVM classes

UVM provides a set of base classes from which more complex classes can be built by inheritance and to which are added certain functions needed to validate the environment. For example, new driver classes for the Wishbone protocol can be built by extending from the UVM base class uvm_driver. Stimuli for this protocol can be written by extending from uvm_sequence_item. How this sequence is constructed and passed to the driver is handled internally by the UVM framework.
uvm_void is the base of all classes, but it is an empty class. uvm_object is the main class where the common functions for printing, copying and comparing two objects of the same class are defined.

There are two branches in this hierarchy. The first branch contains classes that define verification components such as drivers, monitors, and the rest are shown in the diagram as everything under UVM_REPORT_OBJECT. The second branch defines the data objects used and manipulated by the validation components, which are shown in the diagram as everything under UVM_TRANSACTION

Main categories of UVM classes

UVM Objects   
The idea behind UVM is to enhance flexibility and reuse code so that the same test bench can be configured in different ways to build different components and provide different stimuli. It is recommended that these new user-defined configuration classes be derived from uvm_object . For example, a configuration class object can be built with certain settings that define how the testbench environment must be built.


UVM Sequence (Sequence)
UVM also introduces the concept of a sequence, which is just a container for the actual incentive design. If you put different stimuli into different sequences, it enhances the ability to reuse and randomly drive those sequences for more coverage and validation results. It is recommended that all new user-defined stimulus classes inherit from uvm_sequence .
Each sequence can be used in other sequences to create different scenes. For example, separate sequences could be created , one for each "read" and "write" transaction. They can be used in random patterns in other sequences to do R->W->R->W, or R->R->R->W, W->W->R->R and other similar patterns .

UVM sequence item (Sequence item)
The data object that must be driven to the DUT is usually called a sequence item, and it is recommended to inherit from uvm_sequence_item . For example, a sequence item class can be defined for an APB transaction, which defines the address, write/read data, and access type, and sent to the APB driver to drive the transaction to the DUT.


UVM Components
All main testbench components derive from corresponding base classes. For example, it is recommended that all new user-defined driver classes inherit  from uvm_driver , and monitor classes from uvm_monitor  , etc. A brief description of the operations performed by each UVM component is given in the table below.

Register Layer
Digital designs support control registers that can be configured by software, which is very challenging in a system virtual log testbench because for each project you have to build a separate set of classes to store and configure these registers. UVM has an extensive set of classes that make this task relatively simple, and belongs to something called a register model. This is useful when validating IPs that can be reused in various SoC designs.


TLM Connection
Another really clever feature is the use of TLM from System C. TLM helps to send data between components in the form of transactions and class objects. It also brings a way to broadcast packets to listeners without having to create a specific channel and attach.


Another major feature of UVM phases
that the verification component inherits from its parent class uvm_component is phased. This keeps each component in sync with each other before moving on to the next stage. The next chapter describes each phase. Each component goes through a build phase of instantiation, connects to each other during a connection phase, consumes simulation time during a run phase, and stops together in the final phase.

 

Guess you like

Origin blog.csdn.net/qq_43045275/article/details/130015319