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.
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.
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 !
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 !
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 !
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.
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
- 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 !