2

One thing that always confuses me: is whether add uvm_component parent in the class constructor of UVM objects or not. As I understood for all items inherited from uvm_component, they all need uvm_component parent as part of constructor input argument.

function new (string name, uvm_component parent);
    super.new(name, parent);
endfunction

But all classes inheretied from uvm_object, they dont need.

My question is why?

Per my understanding we are providing uvm_component parent for factory can replace these objects, why uvm_object inherited class dont need to be replaced by factory?

And one more interesting fact I noticed for uvm_sequence: so uvm_sequence constructor does nor require uvm_component parent attribute, but when we create the sequence by factory we provide the parent argument.

haykp
  • 435
  • 12
  • 29

3 Answers3

3

The reason why the constructor of a class derived from uvm_component needs to know its parent is because classes derived from uvm_component are part of the infrastructure of your test environment; that test environment has hierarchy and each component needs to know where it sits in that hierarchy. (For example, the configuration database uses the component hierarchy.)

Classes derived from uvm_object are not part of the the infrastructure of your test environment; they are data that flows through it.

Matthew Taylor
  • 13,365
  • 3
  • 17
  • 44
2

In UVM, there are mainly 3 types of classes.

  • uvm_component - For class based hierarchical testbench structure
  • uvm_object - Data structures for testbench configuration
  • uvm_transaction - Stimulus generation & analysis

The values of the arguments of new method are used to create an entry in a linked list which the UVM uses to locate uvm_components in a pseudo hierarchy, this list is used in the messaging and configuration mechanisms. So ideally, while creating the components through create methods, the name argument string should be the same as the declaration handle of the component and the parent argument should be the keyword "this" so that it refers to the uvm_component in which the component is being created.

uvm_object class does not require such things, because it is not used to make the hierarchy of the testbench. And uvm_sequence is also derived from uvm_object only.

uvm_object -> uvm_transaction -> uvm_sequence_item -> uvm_sequence_base -> uvm_sequence

Karan Shah
  • 1,912
  • 1
  • 29
  • 42
1

Per my understanding we are providing uvm_component parent for factory can replace these objects, why uvm_object inherited class dont need to be replaced by factory?

I think you are a little confused about parent and base classes.

In the UVM test hierarchy, a parent class is the class that is one level above in the test heirarchy. For example:

uvm_test is the parent of uvm_env
uvm_env is the parent of uvm_agent
uvm_agent is the parent of uvm_driver, uvm_sequencer, uvm_monitor

This is the parent you specify when instantiating child uvm components. It is needed for the config db, build phasing, check phasing, etc etc.

Now, on the other hand, base classes are an OOP concept. You can extend a base class and add on functionality to it. So for example, you may have something like:

my_agent_base extends uvm_agent (uvm_agent is base class, my_agent_base is derived)
my_agent_derived1 extends my_agent_base
my_agent_derived2 extends my_agent_base

If you register all these components with the factory, it allows you to override my_agent_base with my_agent_derived1. This allows for swapping-in-and-out of components with different behaviour in your testbench.

You can do this with uvm_components and uvm_objects, no problem. The only requisite is your register them with the factory.

Normally, uvm_objects are dynamic objects created and destroyed during a test multiple times.

uvm_components persist for the entire duration of the test and have phases of execution.

Hope this helps

noobuntu
  • 903
  • 1
  • 18
  • 42