UVM class hierarchy - type of relationship

UVM
,
1

I am looking at the UVM class hierarchy diagram and I am confused with the type of relationship across the class hierarchy.
For example, everything is represented using an arrow with white arrow head.
Does this mean that:

  1. uvm_report_object is derived from uvm_object
  2. uvm_component is derived from uvm_report_object
  3. uvm_report_handler is derived from uvm_report_object

Secondly, how uvm_report_object is utilized? Do testbench writers have to include this class before using it?
Same question applies for TLM classes also.

Thanks,

2

In reply to verif_learner:

  1. uvm_report_object is derived from uvm_object

Yes report object provides a sort of interface to the UVM reporting facility. Users can configure what actions are taken and what are output for individual messages from a particular component or for all messages from all components in the environment. User can set ACTION for each of the messages like UVM_DISPLAY, UVM_COUNT etc. Refer uvm_report_object.svh description.

  1. uvm_component is derived from uvm_report_object

Correct. Components are basically those classes which will be instantiated and used throughout the simulation. Unlike transaction/sequence objects, the components are generally not created per packet.

  1. uvm_report_handler is derived from uvm_report_object

The report handler is the class which stores actions, verbosity and files that affect the way reports are handled. It contains print method which can be used by printer to format the output. Refer to uvm_report_handler.svh description.

Secondly, how uvm_report_object is utilized? Do testbench writers have to include this class before using it?
Same question applies for TLM classes also.

By importing uvm_pkg with wildcard, it will import all the UVM related files. So no need to include individual files. Usually we use the following to get all the UVM functionality:

import uvm_pkg::*; // All UVM related files
`include "uvm_macros.svh" // UVM macros file
3

In reply to sharvil111:

Hi Sharvil,

I am not asking about functionality of these classes. These are readily available from UVM user manual. I am asking the class relationship between these classes.

To elaborate further, which classes have IS-A, HAS-A relation?
If yes, why is everything represented using an arrow with a white arrow head.
As per UML, there is a different representation for IS-A and HAS-A type of relation.

I hope my question is clear.

4

In reply to verif_learner:

Not sure which diagram you are looking at, but most of them are not strict UML. Sometimes, only the arrows going vertical represent inheritance.

uvm_report_object IS-A uvm_object.
uvm_component IS-A uvm_report_object
uvm_report_handler IS-A uvm_object. It is NOT a uvm_report_object.

Technically, SystemVerilog does not have HAS-A relationships to other classes, but it can have references to other class objects. Extending a class always results in a IS-A relationship.

uvm_report_object HAS-A reference to uvm_report_handler

5

In reply to dave_59:

Dave,

Thanks. Most of the UVM references show this figure including UVM cookbook. For example, the first figure in chapter on “COMPONENT” in uvm cookbook has this figure.

I am really confused with your statement that technically SV does not have HAS-A relation with other classes. I would have thought through if you said this for UVM but for SV, this confuses me.

HAS-A generally means that you have reference to or instance of other class. UVM agent containing instance of uvm driver, monitor is a good example.

PS: how to add figures in forum posts. I tried the image icon but it comes up with an option to add URL.