Hi,
according to uvm reference manual, description of create in uvm_object_registry and uvm_component_registry is :
static function T create (string name = “”,uvm_component parent = null,string contxt = “” )
Returns an instance of the object type, T, represented by this proxy, subject to any
factory overrides based on the context provided by the parent’s full name. The contxt
argument, if supplied, supercedes the parent’s context. The new instance will have the
given leaf name, if provided.
Can anyone explain what is the significance of contxt parameter here.
static function T create (
string name = "",
uvm_component parent = null,
string contxt = ""
)
Argument “uvm_component parent = null” if provided changes hierarchical position of the object/component regardless of where its created. This argument is hierarchical path for new parent of this object/component.
and argument string contxt = “” is useful to create type of the object based on factory overrides if any. Override type, if not provided, is determined based on parent argument context at which override is set and if supplied, supersedes the parent’s context.
To understand the working, create some example and vary 2nd and 3rd args to see the effects!
I think you may have this backwards. The parent argument is only used by uvm_component_registry::create() to place the newly created component in its hierarchy. The contxt argument is used by both uvm_component_registry::create() and uvm_component_registry::create() as the context for determining instance based factory overrides.
Thanks Mayur, Dave for the explanations. I have one more question:
while creating objects, we supply only one argument (name string) to the create. (unlike component where we supply name and parent handle to create method) If uvm_object_registry::create method is not provided second argument (uvm_component argument) it will take default value of null. So how does an object know its hierarchical path? The hierarchical path will be required for example, to implement instance based overrides for objects. As an example, function : function void set_inst_override_by_type (uvm_object_wrapper original_type, uvm_object_wrapper override_type,string full_inst_path) will require full instance path if an instance is an object.
rgs,
-sunil
In reply to puranik.sunil@tcs.com:
Only classes derived from uvm_component are associated with a hierarchical tree structure. The uvm_component has handles to its parent and an array of its child components so that from any component, you can navigate up or down the hierarchical tree. All other UVM classes not derived from uvm_component do not maintain a hierarchical tree. (uvm_sequences do maintain a sequence path similar to a call stack, but that is managed as sequences get started, not when constructed).
Thanks Dave for explanation. However, in that case, how does a function like
virtual function string get_full_name() which is part of uvm_object class return full hierarchical path of object?
As per your explanation, get_full_name should be able to return full hierarchical path only for components (and classes derived from them). For other objects, it should return only the name of object. Is this correct understanding?
If sequences maintain a path similar to components, then can get_full_name when called on sequence or sequence_item return a full path of the sequence/sequence_item instance.
Also is it possible to override a particular instance of sequence by a derived type in test case by using set_inst_override_by_type? (I have seen only a component instance being replaced by derived type using set_inst_override_by_type).
In reply to puranik.sunil@tcs.com:
Please read the UVM reference manual for a description of how uvm_object::get_full_name() works; I think it is described clearly.