UVM Class Hierarchy

@shraddha_pawankar Date:21/03/2024
UVM Class Hierarchy
UVM classes have 3 major types

1. UVM object
2. UVM transaction
3. UVM component
As shown in the above diagram,

uvm_object is derived from the uvm_void class.
1|Page
Further component and sequence branches are inherited from the

uvm_object class.
UVM_VOID :
The uvm_void is the base class for all the UVM classes.
It is an abstract class that does not have any data members or methods
implemented.
Syntax:
virtual class uvm_void
🧩 Demystifying uvm_void in UVM: A Simple Explanation
1) 📦 Empty Box Analogy: Just as an empty box doesn't hold any specific
items, uvm_void doesn't have any predefined data or methods inside it.
It's like a blank slate waiting to be filled.
2) 🔄 Abstract Nature: uvm_void is what we call an abstract class. This
means it's more of a blueprint than an actual object. You can't directly
use uvm_void to create instances because it lacks concrete
implementation. Instead, it acts as a template for other UVM classes.
UVM_OBJECT:
The UVM object is a data structure used for testbench configuration and it is
the base class available for component and sequence branch.
The uvm_object provides methods like create, clone, copy, record, compare,
print, etc.
An Easy Explanation
1) uvm_object as the central hub for handling data within our testbench.
2) It's like a versatile container that can hold various types of information
needed for verification.
2|Page
3) uvm_object acts as the base class for other UVM components like
components and sequences.
4) It provides a common framework for managing data across different
parts of the testbench.
UVM_REPORT_OBJECT:
• The uvm_report_object provides reporting functionality for UVM.

• The message, error, or warning prints are very important for debugging
purposes that are being facilitated by the uvm_report_object class.
• Most of the methods in uvm_report_object are passed to an instance of
uvm_report_handler that stores reporting configuration.
• Based on the configurations, uvm_report_handler decides whether to
display the message or not.
• It is then passed to uvm_report_server for actual formatting and
producing the messages.
• The detailed report has information for id string, verbosity level,
severity, and a complete message string.
3|Page
UVM_TRANSACTION
• UVM transaction is used for generating stimulus and its analysis.

• They are transient in nature.
• The simple transactions can be derived from the uvm_transaction class.
• But sequence-specific transactions are recommended to derive from
uvm_sequence_item.
An Easy Explanation
Stimulus Generation and Analysis: UVM transactions are like messengers that
carry information between different parts of our verification environment.
They're responsible for generating stimulus (input signals) for our design and
analyzing the results.
4|Page
🏃♂️ Transient Nature: Transactions are temporary and don't stick around for
long. They come into existence, do their job, and then vanish.
Sequence-Specific Transactions: However, for more complex tasks, like

sequences that involve specific scenarios or behaviors, it's recommended to
use specialized transactions derived from uvm_sequence_item
While basic transactions cover general tasks, specialized transactions derived

from uvm_sequence_item are recommended for more complex and
sequence-specific scenarios.
UVM_COMPONENTS
UVM components are used to build a class-based hierarchical structure for the
testbench.
The uvm_component are static and physical components that exist
throughout the simulation.
The uvm_component class is a base class for all UVM components.
For testbench hierarchy, base class components are available in UVM as
uvm_env, uvm_agent, uvm_monitor, uvm_driver, uvm_sequencer, etc.
🔧 Understanding UVM Components: A Simple Overview
🌟 Building Blocks: UVM components are like the building blocks of our
testbench. They help us organize different parts of our verification environment
into a structured hierarchy, making it easier to manage and maintain.
🔩 Static and Persistent: Once they're created, UVM components stick around
throughout the simulation. They're like the solid foundation of a building,
always there to support the rest of the structure.
5|Page
🏗️ Base Class: At the core of UVM components is the uvm_component class.

It serves as the base class for all other UVM components, providing common
functionality and interfaces that they can inherit and use.
🧩 Testbench Hierarchy: Think of UVM components as different types of rooms

in a house. We have rooms for different purposes, like living rooms, bedrooms,
and kitchens. Similarly, in UVM, we have base class components like uvm_env,
uvm_agent, uvm_monitor, uvm_driver, uvm_sequencer, and more, each
serving a specific function in our testbench hierarchy.
🔌 Interfaces: Now, what do these components actually do? Well, they

provide various interfaces that allow them to interact with each other and with
the rest of the verification environment. These interfaces include:
Configuration: Setting up parameters and settings for the component.
Construction: Creating and initializing the component.
Connections: Communicating with other components.
Reporting: Sending messages, errors, and warnings for debugging purposes.
Phasing: Managing the lifecycle of the component during simulation.
In essence, UVM components act as the backbone of our testbench, providing
structure, organization, and functionality to ensure smooth verification
processes.
Difference between uvm_object,uvm_transaction and uvm_sequence_item

1. The uvm_transaction class is inherited from uvm_object that adds
additional information of a timing, notification events, and
recording interface.
2. The uvm_sequence_item class is derived from the
uvm_transaction class that adds basic functionality for sequence
and sequence items like get_sequence_id, set_sequencer,
get_sequence, etc.
3. It is important to note that uvm_transaction usage is deprecated
as a base class for user-defined transactions. Hence, the
uvm_sequence_item class shall be used as a base class for user-
defined transactions.
6|Page
7|Page

UVM Class Hierarchy

Uploaded by

Copyright:

Available Formats

UVM Class Hierarchy

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UVM Class Hierarchy

Uploaded by

Copyright:

Available Formats

@shraddha_pawankar Date:21/03/2024

UVM Class Hierarchy

UVM classes have 3 major types

As shown in the above diagram,

Further component and sequence branches are inherited from the

🧩 Demystifying uvm_void in UVM: A Simple Explanation

• The uvm_report_object provides reporting functionality for UVM.

• UVM transaction is used for generating stimulus and its analysis.

Sequence-Specific Transactions: However, for more complex tasks, like

While basic transactions cover general tasks, specialized transactions derived

🔧 Understanding UVM Components: A Simple Overview

🏗️ Base Class: At the core of UVM components is the uvm_component class.

🧩 Testbench Hierarchy: Think of UVM components as different types of rooms

🔌 Interfaces: Now, what do these components actually do? Well, they

Difference between uvm_object,uvm_transaction and uvm_sequence_item

You might also like