In UVM we are writing a default Class Constructor in Every Class.
What is the need of it and What is the relation between create and constructor.
If you do not define a constructor in an extended class, SystemVerilog automatically inserts the following constructor for you:
function new;
super.new();
endclass
You need to define a constructor for every class you extend from a base class that has a constructor with arguments that have no defaults, otherwise you will get a compiler error for the missing argument. the uvm_component class’s constructor looks like
function uvm_component::new (string name, uvm_component parent);
...
super.new(name);
...
endfunction
Whenever you extend a class from uvm_component, you need to provide a name and parent argument to pass to the uvm_component’s constructor.
The constructor to uvm_object looks like:
function uvm_object::new (string name="");
...
endfunction
You can extend from uvm_object without defining a constructor because it supplies a default value “” for you.
In reply to raja.kuraku:
By default the constructor new() will create the class object (i.e., allocate space for all the properties/methods in the memory). Often new(), is also used to initialize the properties of the class object.
On the other hand a create() call, first determines the type of the object (by looking at the factory overrides for the given type) that needs to be created and then calls ‘new’ to create the object.
So, you can think of create() as “new() + some more code”.
Note that you have to first register a class with the factory before using create() to create the object.
If factory registration is not done, new() can be used to create a driver (or for that matter any class object), but cannot use factory create method as it can’t find the type to be created from the factory.
In reply to S.P.Rajkumar.V:
It is highly recommended that you register all of your UVM components and objects with the factory, even if you think you won’t use any overrides.
If a class is not registered with the factory, then you cannot use the create() function. Since create() is the recommended method in UVM to create new objects, any other UVM users who will potentially re-use your code will have to deviate from the standard UVM methodology.
Registering with the factory is one simple line of code and is well worth the effort. With respect to the new() function, there is a compile define which can force the user to implement constructors, but pre-compiled UVM versions vary on the use of this define.
In reply to cgales:
Also, if you don’t provide the constructor, we have no way of determining the hierarchical name for the component.
In reply to dave_59:
Hi Dave,
COuld you please tell me what should be the string name and parent in component constructor and the string name in object constructor. Iam so much confused what they can be? How does this namings affect our testbench?
In reply to janudeep3:
In the future, a new question should should be posted in a new topic, especially one that has already been marked as solved.
The uvm_component class builds the hierarchy and will provide a cryptic unique name for your object if you don’t provide a name. So it’s better to provide a name that makes sense to you for reporting and debugging. Debugging with a UVM-aware tool becomes a lot easier if the component name matches the class variable name that holds the component handle. Also, then names of all the child classes under the same parent must be unique, just like all the class variables in a single object must be, so you should be using the same naming scheme.
The reason the UVM has to manage the hierarchy is that the SystemVerilog Object-Oriented Programming model does not have a static class instance concept, like module instances in Verilog. There is no such thing as a parent/child class unless you have a methodology to add class properties to your object that represent that relationship. A class variable can only hold a reference to another class object - it is up to the methodology to distinguish whether that object “belongs” to it or not.
UVM sequences can also have parent/child relationships, but the class variable names of sequence and sequence items are usually the same or similar (req). So it would help to provide more meaningful names.
The names of other classes derived from uvm_object are not as important, but it helps to use the same convention of using the same names of the class variable the object handle is stored in as the string name of the object.