Introduction to UVM

UVM stands for Universal Verification Methodology. But to answer what exactly it means and why it’s so important for functional verification, keep reading this blog and all related articles.

What is UVM?

UVM is not a language, but it’s a library of classes written in System Verilog, which implements the building blocks of a verification environment. It’s an open-source library, maintained by the industry standard body “Accellera”. The library API is defined as IEEE standard 1800.1. It’s the latest standardized methodology for verifying digital hardware designs and System on Chips (SoCs) in semiconductor-related companies.

To understand it much simpler, UVM is a library of classes, set of guidelines and best practices on how to create a verification environment to verify any digital design. it covers everything from how to create an environment, running simulation and checking results.

Which methodology was king before UVM?

Before UVM became so popular among verification engineers, there were several other verification techniques and methodologies used to verify digital hardware designs. These techniques evolved over time to address the complexity of digital design, to focus on automation, and the reusability of the same verification environment for multiple projects. Some of the known verification methodologies used before UVM include:

1. Directed testing

In the early days of digital verification, verification engineers used to create direct test cases to verify the functionality of a design. The biggest drawbacks of this approach were:

• If the understanding of design is incorrect, it results in missing the correct scenario verification.
• The corner cases cannot be identified and tested with this approach.
• No reusability. This type of environment and test cases cannot be reused for other projects to save time.
• This type of approach cannot handle complex design verification.

2. VHDL/ Verilog/ System Verilog Testbenches

With the evolution of hardware languages, creating testbenches and test environments using VHDL, Verilog, System verilog also became quite popular. Engineers used to create verification environment with these languages and write dedicated testcases to verify the functionality of a digital design. The result can be seen as a waveform in multiple industry simulators.
A few problems with this approach were:

• Reusability was still not answered. The environment is not reusable for different projects.
• Complex design verification was not easily handled by this approach
• There was no standard approach or methodology. For the same design, multiple verification engineers can create different testing environments as per their knowledge, and it creates problems and consumes time to understand the testing environment from engineer to engineer
• Lots and lots of code have to be written to automate basic functionalities. Examples can be like deep copy, complex comparison, etc.

3. Open Verification Methodology (OVM)

OVM was introduced in 2008, and it was system verilog based verification methodology, guidelines and best practices to create reusable verification environments and to verify complex designs. It was developed by Mentor graphics (now part of Siemens) and later became an Accellera standard.
UVM was released in 2011, and it is an enhanced and improved version of OVM. As UVM is the more advanced and standardized methodology, the verification community gradually shifted towards adopting UVM.

WHAT IMPROVEMENTS UVM BROUGHT OVER OVM?

Some of the major improvements that UVM brought over OVM are:

• Base class library: UVM introduced a new base class library, which is the foundation of UVM. This base class library includes reusable base classes for different verification components (discussed later in the course), like sequencer, driver, monitor, etc. It simplified the task of creating a verification environment directly by using these base classes and promoting reusability.
• Sequences: UVM first introduced the concept of sequences to represent transaction-level stimulus generation. To understand this in simple languages, rather than dealing with individual signals like address, data, read etc. A transaction or packet class is created which encapsulates these signals like address, data, read etc. So the sequence defines the scenario to be verified in terms of transaction class or packet like eg. send 100 packets of write to 100 consecutive addresses with random data. Sequences provide a more structured way to model stimuli.
• Phasing Mechanism: Phasing is one of the most important feature of UVM. Phasing allows a structured and synchronized approach to a verification task. This ensures various components of the testbench proceeds through different phases of the testbench lifecycle systematically.
• Configuration database: UVM introduced a global configuration database that allows easy sharing of configuration data among different components in the testbench. This simplifies parameterization and promotes configurability and reusability. In simpler terms, you can set variables from top-level classes. This feature is explained better in upcoming blogs.
• Transaction-Level Modeling TLM: UVM provides a TLM layer, which allows to communicate between different components of Testbench using ports, exports and imports of TLM.
• Factory: UVM introduced a factory layer, enabling more flexible and efficient creation and configuration of verification components. A parent class can be overridden by a child class without changing the code in the verification environment.
• Improved Reporting and Messaging: UVM introduced improved reporting and messaging features, making it easier to understand and debug verification issues by providing more detailed and customizable messages. There are levels of switches via which you can control how many messages or the verbosity of messages in log files to aid debugging. The print messages can pinpoint from which line of code or which component called this print.
• Component Hierarchies: UVM introduced better support for hierarchical testbenches and testbench reusability, allowing verification engineers to organize and manage the complexity of larger projects effectively. This makes it a systematic approach.
• Enhanced RAL (Register Abstraction Layer): UVM refined the RAL to provide a more robust and efficient way of modeling, accessing, and verifying design registers.
• Supports Metric Driven verification (MDV)

PREREQUISITES FOR LEARNING UVM

UVM is a library of classes written in System Verilog. To understand it, you should have a basic to good level of understanding of System Verilog and C++ OOP concepts.

WHY UVM?

There are some concrete reasons to support UVM and to say it’s better to use UVM rather than simply verifying a design via VHDL, Verilog, etc.

UVM is a library of classes, and these classes provide a lot of handy and important functionalities. These methods, functions can be directly used by just extending from these classes while creating components or objects during verification. For example

• Components: There are pre-defined classes for each component of a Testbench like Driver, Monitor etc. Verification engineer just need to follow guidelines and extend from these classes to use the inbuilt functions.
• Automation: UVM provides pre-defined functions like deep copy, clone, compare. So the verification engineer don’t need to write these smallest functions every time. There are ways to even create user defined functions as well.
• Simulation Control: UVM introduced phases, which give much more control and clarity to verification engineers. Like building hierarchies happen in ‘build_phase’, TLM ports are connected in ‘connect_phase’, testcase runs in ‘run_phase’, reporting happens in reporting_phase’, etc.
• Print control: There are multiple ways to control how much of print statements the verification engineer wants in a log file. If it’s for a debug, all prints can be enabled by changing print verbosity to UVM_DEBUG. If engineers don’t want all prints, verbosity can be made higher.