Deciphering UVM - 1

The Methodology
There is enough written about OVM/UVM and the methodology. The need and use of it etc. etc. UVM is a collaborative effort by the EDA fraternity. It has standardized or atleast attempted to standardize the building of testbenches across the semiconductor industry. The pros and cons can be debated. But thats not the point. I was not quite happy just by using the methodology. So from the "how" the question turned into "why". And thats what I am exploring and in doing so I will go by the first principles way...

Lets look at the very basic building blocks of UVM.

UVM base classes

uvm_void
Present in uvm/src/base/uvm_misc.svh
This is the basic base class from which everything gets created. We can say the basic substratum of UVM (a little exaggeration !!). This is an abstract class with no data members or methods.
The code looks like this

virtual class uvm_void;
endclass

uvm_object
Present in uvm/src/base/uvm_object.svh
The code looks like this

virtual class uvm_object extends uvm_void;
'
'(properties / methods)
'
endclass

The uvm_object class is the base class for all further classes.
This class has approx. 36 methods which can be used for different purposes.
The uvm reference doc has details of how to use these methods. Of course the code also has comments. Some of the important methods are set_name, get_name, get_full_name, get_inst_id, get_inst_count, get_object_type, get_type_name, print, sprint, do_print, convert2string, record, copy, do_copy, compare, pack_bytes, unpack, set_int_local, use_uvm_seeding, reseed etc.There are some pure virtual methods like get_type_name and create.

uvm_report_object
Present in uvm/src/base/uvm_report_object.svh
The code looks like this 

class uvm_report_object extends uvm_object;
'
'(properties / methods)
'
endclass

This class provides an interface to the uvm reporting mechanism. Through this interface uvm components generate different kinds of messages.
Some of the methods in this class are uvm_report, uvm_report_info, uvm_report_warning, uvm_report_error, uvm_report_fatal etc., The uvm_report_object takes help from the uvm_report_handler for most of its functions.

uvm_report_handler
Present in uvm/src/base/uvm_report_handler.svh
The code looks like this

class uvm_report_handler;
'
'(properties / methods)
'

endclass

uvm_report_handler handles most of the functions of the uvm_report_object. There is a one-to-one relationship between uvm_report_object and uvm_report_handler, but it can be many-to-one if several uvm_report_objects are configured to use the same uvm_report_handler object. The uvm_report_handler delegates handling of its reports to the uvm_report_server. The relationship between uvm_report_handler and uvm_report_server is many-to-one.

uvm_report_server
Present in uvm/src/base/uvm_report_server.svh
The code looks like this

class uvm_report_server extends uvm_object;
'
'(properties / methods)
' 
endclass

uvm_report_server is a global server that processes all of the reports generated by an uvm_report_handler. Testbench is not supposed to be using the methods of the uvm_report_server.

uvm_report_catcher
Present in uvm/src/base/uvm_report_catcher.svh
The code looks like this

virtual class uvm_report_catcher extends uvm_callback;
'
'(properties / methods)
'
endclass

The uvm_report_catcher is used to catch messages issued by the uvm_report_servers.

We just discussed the uvm_report* classes just to get a hang of their utility and how things work under the hood.

Going back to our basic uvm_base classes...

uvm_component
Present in uvm/src/base/uvm_component.svh
The code looks like this

virtual class uvm_component extends uvm_report_object;
'
'(properties / methods)
'
endclass

The uvm_component class is the root base class for all uvm components. It contains all the features of uvm_object and uvm_report_object. On top of that it provides interfaces for hierarchy, phasing, configuration, reporting, transaction recording and factory. The uvm_component is automatically seeded during the construction using UVM seeding, if enabled. All other objects must be manually reseeded. Some of the methods in this class are: get_parent, get_full_name, get_children, get_child, set_name, lookup, get_depth, build, build_phase, connect_phase, connect, end_of_elaboration, end_of_elaboration_phase, start_of_simulation_phase, run_phase, run, pre_reset_phase, reset_phase, post_reset_phase, pre_configure_phase, configure_phase, post_configure_phase, pre_main_phase, main_phase, post_main_phase, shutdown_phase, extract_phase, check_phase, report_phase, final_phase, phase_started, phase_ready_to_end, phase_ended, set_domain, get_domain, suspend, resume, status, kill, do_kill_all, stop_phase, set_config_int, set_config_object, set_config_string, get_config_int, get_config_object, get_config_string, check_config_usage, apply_config_settings, print_config_settings, raised, dropped, all_dropped, create_object, create_component, set_type_override_by_type, set_type_override_by_inst, set_type_override, set_inst_override, set_report_verbosity_level_hier, begin_tr, do_being_tr, end_tr, do_end_tr etc.

From the list of the methods in the uvm_component class, we can easily infer is that this is a heavy weight class and host of methods which are at the heart of the UVM methodology. Hence it is important to make the discretion, when to use a uvm_component and when to use a uvm_object which is much lighter in weight.

uvm_transaction
Present in uvm/src/base/uvm_transaction.svh
The code looks like this

virtual class uvm_transaction extends uvm_object;
'
'(properties / methods)
'
endclass

The uvm_transaction class is the root base class for UVM transactions. It inherits all the methods and properties of the uvm_object. On top of that the uvm_transaction class adds a timing and recording interface. This class provides timestamp properties, notification events and transaction recording support. Important to note here, use of this class as a base for user-defined transactions is deprecated. Its subtype/child class uvm_sequence_item, shall be used as the base class for all user-defined transaction types.
Some of the methods in this class are: accept_tr, do_accept_tr, begin_tr, end_tr, get_tr_handle, disable_recording, enable_recording, is_active, get_event_pool, set_initiator, get_initiator, get_begin_time, get_end_time, set_transaction_id, get_transaction_id etc.

uvm_sequence_item
Present in uvm/src/seq/uvm_sequence_item.svh
The code looks like this

class uvm_sequence_item extends uvm_transaction;
'
'(properties / methods)
'
endclass

This is the base class for user-defined sequence items as well as for the uvm_sequence class. This class provides the basic functionality for objects, both sequence items and sequences, to operate in the sequence mechanism. 

Some of the methods in this class are: get_type_name, set_sequence_id, get_sequence_id, set_item_context, set_use_sequence_info, get_use_sequence_info, set_id_info, set_sequencer, get_sequencer, set_parent_sequence, get_parent_sequence, get_depth, is_item, get_full_name, get_root_sequence_name, get_sequence_path, uvm_report, uvm_report_info etc. 

Well, this is a basic overview of the base classes that ultimately build UVM. The details of the methods and their applications can be found in the uvm source code. From a user perspective this post should connect some of the dots. This is just the beginning, more discussions to follow...

(source : UVM source code)