I am eager to get a kind of fundamental explanation why the names given to objects in new()/create() methods are used to construct inst_name instead of object handle names? The inst_name I am meaning is the following field in uvm_config_db
it will fails, because we are using the object handle name of the agent (agent_x) to build the hierarchy path. So, why those object names in crates()/new() methods should be used instead of object handle names?
This is how it works in UVM. The UVM builds a hierarchical tree of components based on components names and their parents names.
Ever wondered why you pass a string representing the name (e.g. “agent_name_x” above) and the parent of a component (e.g. {this} above) to a uvm_component constructor new()? UVM uses these string names for many utilities, e.g. traversing the hierarchy, passing configurations, etc.
That’s why it is a fair enough practice to use similar string names and handles names to avoid confusion.
Yep, basically I agree your answer and explanation. I always see the same comment “It is good
practice to create the objects with the same name as the object handle name.”, but no detailed explanation why it is good practice and what is “fact” behind that. I think the fact behind the UVM hierarchy tree building should be documented somewhere in official UVM documents, so could you point that document to me?
It’s probably for flexibility. There may be some case where your object name is different than the label; perhaps, if it’s a base class handle pointing to an extended class, and you want the string lookup to be something more interesting than “my_base”. I’d just gobble up the blue pill, and name them the same thing.
So, I think that local fields of uvm components named m_leaf_name are utilized when constructing uvm hierarchy? If yes, which uvm base element and its method(s) finally build the uvm hierarchy?
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.
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.
Hi Dave and thanks! Now I got details I was looking for. So, as you said uvm_component builds the uvm hierarchy, that is reasonable yes. But, I still take this deeper by asking that which is a role of uvm_factory (+uvm_registery)? Does responsibility of collecting and connecting of the created (new()/create()) uvm components lie on the uvm factory?
I don’t understand your question. The uvm_factory and uvm_component hierarchy are independent concepts. The only connection is that the component hierarchy creates pathnames for objects that may be used to make factory or config_db overrides more selective .
Perhaps you need to start over with a new question thread.
Dave, I need to admit it was not a good idea to mess things up by adding uvm_factory related sub question to this thread. I will not create the new question thread, but instead of it I will try to summarize this thread to get it finalized.
So, basically, my very first question originated from confusion how the UVM component hierarchy path should be constructed for uvm_config_db. After replies, I have now understanding that the UVM component hierarchy path is built upon names given for objects in new()/create(). With those names and also with their parent names (voluntarily given in new()/create()), uvm_component class builds the UVM component hierarchy independently without any connection to the another concepts of UVM.
*In reply to Vaino:*No, didn’t say there was no connection, I said:
The only connection is that the component hierarchy creates pathnames for objects that may be used to make factory or config_db overrides more selective .