The basic building blocks for any verification environment are the components (drivers, sequencers, monitors ...) and the transactions (class objects that contain actual data) they use to communicate. From the UVM hierarchy, we can see that most of the classes in UVM are derived from a set of core classes that are described below.
uvm_void
This doesn't have any purpose, but serves as the base class for all UVM classes.
virtual class uvm_void;
endclass
It is an abstract class with no data members or functions. It allows for generic containers of objects to be created, similar to a void pointer in the C programming language. User classes derived directly from uvm_void inherit none of the UVM functionality, but such classes may be placed in uvm_void typed containers along with other UVM objects.
uvm_object
This is a virtual base class for all components and transactions in the UVM testbench. It's primary role is to define a set of methods for common operations like print, copy, compare and record.
virtual class uvm_object extends uvm_void;
extern function void print (uvm_printer printer=null);
extern function void copy (uvm_object rhs, uvm_copier copier=null);
extern function bit compare (uvm_object rhs, uvm_comparer comparer=null);
extern function void record (uvm_recorder recorder=null);
...
endclass
Read more about UVM Object !
uvm_report_object
Provides an interface to the UVM reporting facility. All messages, warnings, errors issued by components go via this interface. There's an internal instance of uvm_report_handler which stores the reporting configuration on the basis of which the handler makes decisions on whether the message should be printed or not. Then it's passed to a central uvm_report_server which does the actual formatting and production of messages.
// A report has 'severity', 'id_string', 'text_message', and 'verbosity_level'
`uvm_info ("STAT", "Status register updated", UVM_HIGH")
// severity : uvm_info
// id_string : "STAT"
// text_message : "Status register updated"
// verbosity_level : UVM_HIGH
The message is ignored if the verbosity level is greater than the configured maximum verbosity level. For example, if the maximum verbosity level is set to UVM_MEDIUM, then all INFO statements with verbosity greater than MEDIUM are ignored. This is useful for debug purposes where the message level can be set to UVM_HIGH for all debug related messages, while the maximum verbosity level is set to UVM_MEDIUM. This allows the ability to switch between different output levels without recompiling the testbench.
Read more about UVM Reporting Functions !
uvm_component
All major verification components like agents and drivers are derived from uvm_component. It has the following interfaces:
- Hierarchy : Defines methods for searching and traversing the component hierarchy like env0.pci0.master1.drv
- Phasing : Defines a phasing system that all components can follow eg : build, connect, run, etc
- Reporting : Defines an interface to the Report Handler, and all messages, warnings and errors are processed through this interface (derived from uvm_report_object)
- Recording : Defines methods to record transactions produced/consumed by component to a transaction database.
- Factory : Defines an interface to the uvm_factory (used to create new components/objects based on instance/type)
Read more about UVM Component !
uvm_transaction
This is an extension of uvm_object and includes a timing and recording interface. Note that simple transactions can be derived from uvm_transaction, but sequence-enabled transactions must be derived from uvm_sequence_item.
uvm_root
This is an implicit top-level UVM component that is automatically created when the simulation is run, and users can access via the global uvm_pkg:: variable, uvm_top, which has the following properties:
- Any component whose parent is set to null becomes a child of
uvm_top - It manages the phasing for all components
- It is used to search for components based on their hierarchical name
- It is used to globally configure report verbosity
- UVM's reporting mechanism is accessible from anywhere outside uvm_component such as in modules and sequences
It's worthwhile to note that uvm_top checks for errors during end_of_elaboration phase and issues a UVM_FATAL error to stop simulation from starting.
Read more about UVM Root !
