Super.new(name, parent) point which component class

Hi
I am confused in super.new(name, parent); becouse super is point a base class function

class agent extends uvm_agent ;

`uvm_component_utils(agent)

function new(string name, uvm_component parent = null);
super.new(name, parent);
endfunction
class env extends uvm_env ;

`uvm_component_utils(env)

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

here in agent class the super.new(name, parent); is point which class uvm_agent or env class also what is meaning of
uvm_component parent = null

In reply to taufeeq_khan:

uvm_component parent = null

provides a default value to the parent argument. A component whose parent is null is considered a top-level module. When you create a child component, you pass ‘this’ as the parent argument so UVM knows the component hierarchy

child = child_t::type_id::create("child",this);

We call super.new() in the constructor to make sure that the name and parent arguments get passed down into the constructors of the UVM base classes, which are necessary to manage the hierarchy.

I’d like to point out once again that you shouldn’t call new() directly when instantiating a component. If you do, you’ll miss the Factory functionality. You should call create() and that in turn will call new() on the class type returned by the factory.

In reply to tfitz:

thanks for reply
I got it
I have one more question that has been asked
uvm_component is created during the build phase and live throughout the simulation
how to check that uvm_component live throughout the simuation and uvm_object is disappear when not used

In reply to taufeeq_khan:

In reply to tfitz:
how to check that uvm_component live throughout the simuation and uvm_object is disappear when not used

There is no need to check. That’s what they do. There is no way to delete a uvm_component once it’s created. I can’t think of a reason why you’d want to check that a uvm_object disappears, since checking would mean that it’s still “used” even though you’re not doing anything useful with it other than checking it.

As an example, a uvm_sequence_item gets created by a uvm_sequence. It gets randomized and sent to the driver. The driver extracts information from the sequence_item and executes the transaction. Sometimes, the driver puts the result back in the sequence_item to allow the sequence to do some bookkeeping. At that point, the sequence can either create a new sequence_item, or it can re-randomize the same sequence_item. There are advantages and disadvantages to both use-models.

By the way, this is why we recommend the MCOW (Mandatory Copy On Write) policy. If anyone else used the sequence item, they must first copy its contents to a new sequence_item. That way, if the original sequence (or anyone else) modifies the contents of the item, the monitor would still have the copy of the original sequence_item rather than a handle to the item that gets rewritten.