Uvm_config_db inst_name constructed with names given to objects in new()/create() methods

Hi,

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

uvm_config_db#(<type>)::set(uvm_component cntxt, string inst_name, string field_name, <type> value).

For example, in uvm env, we have the agent constructed as follows in build_phase


function void build_phase (uvm_phase phase);
  agent_x = agent::type_id::create(“agent_name_x”, this);

After that, we are able to pass the agent configuration for that particular agent in build phase of the test


function void build_phase (uvm_phase phase);
  agent_cfg_inst = agent_cfg::type_id::create("agent_config");
  uvm_config_db#(agent_cfg)::set(this, "env_inst.agent_name_x", "agent_config", agent_cfg_inst);

But, if we are trying to pass configuration by using the following,


function void build_phase (uvm_phase phase);
  agent_cfg_inst = agent_cfg::type_id::create("agent_config");
  uvm_config_db#(agent_cfg)::set(this, "env_inst.agent_x", "agent_config", agent_cfg_inst);

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?

Thanks in advance!

BR,

Vaino

In reply to Vaino:

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.

In reply to ayehia:

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?

-Vaino

In reply to Vaino:

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.

I ran into to check source code of uvm_object and found the following method

function uvm_object::new (string name="");

  m_inst_id = m_inst_count++;
  m_leaf_name = name;
endfunction

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?

In reply to Vaino:

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.

In reply to dave_59:

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?

In reply to Vaino:

Hi Dave,

Do you have anything to deliver for my previous question?

-Viljami

In reply to Vaino:

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.

In reply to dave_59:

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.

Does my hypothesis set it correctly?

  • Vaino

In reply to Vaino:

Hi Dave,

Could you comment my hypothesis to get this thread closed, thanks!

  • Vaino

*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 .

In reply to dave_59:

Thanks for your clarification. But anyway, I think my hypothesis was mainly correct with your clarification?

  • Vaino

In reply to Vaino:

Hi Dave,

Could you end this thread by commenting my previous question addressed to you, thanks!

  • Vaino