UVM base classes

02 Mar 2024

4 mins

From our previous discussion on UVM we know that UVM provides a set of base classes which is used to create user-specific components/objects. In this article we see in detail about the UVM base classes and their hierarchy. Knowing the hierarchy is important as it can be used to do up-casting of the user-defined components/objects.

Base classes

Let us discuss the base class of UVM and understand how the UVM hierarchy works.

uvm_void

This is the base class in UVM on which all other UVM classes are based on. This is an abstract class has no member and functions. As it is abstract class, thus it cannot be used directly to create any objects.

This is the parent class for all other uvm base/user classes. User class which is derived from uvm_void has none of the UVM functionality as uvm_void class has no functionality. It just acts as a container class.

uvm_object

uvm_object is derived class of uvm_void and is the base class for all UVM data classes. This class adds functionality like create, copy, clone, compare, print, record, etc.

uvm_object can be used to create user-defined classes which are dynamic in nature, i.e., can be created/destroyed in the simulation timeline. Most commonly use case is to create a configuration object, which can be used to configure test/env.

uvm_transaction

This is the base class for all the transaction items. It is derived from uvm_object and thus provides all the functionality of uvm_object. On top of that uvm_transaction adds timing and recording interface which can be used to track and record the various timestamps in stimulus life cycle. For example, when the packet was accepted, when packet ended, etc.

Use of uvm_transaction to create a user-defined transaction class is prohibited.

uvm_sequence_item

uvm_sequence_item is the child class of uvm_transactions. Only this class should be used to create user-defined transaction (Seq item) classes. This class adds some new data members like sequence_id, sequencer, etc.

uvm_report_object

This is the base class of uvm_component which is used to create any user-defined component in test bench.

uvm_report_object is derived from uvm_object and adds uvm reporting functions. These functions can be used to add prints for the logs. Each print in UVM is associated to a severity and verbosity level.

The verbosity level can be controlled while running simulation, which helps filter out prints. This is helpful as in large TB there can be lot of prints and thus the log would become big. Out of these prints some would be needed for debug and not needed in a general log. Thus, verbosity helps in filtering out the messages to make log concise.

uvm_component

This is the child class of uvm_report_object and base class for all other base component classes and user-defined component classes.

uvm_components add various functions like build_phase, run_phase, etc which adds the phasing functionality to components which we discussed in last article.

Each component needs to have a parent which defines the hierarchy of the test bench components. Like env comp will be parent component of agent component.

Here the env comp is a parent component of agent does not mean that the agent is a child class of env. In this context parent simply means that the agent is one hierarchy lower than the env. This helps relate to the actual test bench design where each component is represented in hierarchal way.

uvm_root

uvm_root is a special class in UVM. This class can neither be used to create any user-defined child class nor it can be instantiated.

This is acts as a top-level component class which controls the phase of all the components. Whenever a test is run, this class is automatically instantiated and can be accessed using uvm_top handle. Any component whose parent is null automatically becomes child of uvm_top.

Conclusion

This article gave a brief idea of the various uvm base classes and how they are defined without going deep down into actual implementation. This helps us understand the complex hierarchy of classes present in UVM.

We covered just the important base classes which are base of all other base classes as well. From next article onwards we will look into each and every base class in detail and understand how we can use them write our own classes and use it in TB.