CodingStyle: handle name vs create's string name. To match or not?

[ljepson74]

CodingStyle: handle name vs create's string name.  To match or not to match?

 

What pros, cons, or team rules can you share about whether the string name passed into create should match the handle?

 

i.e. 

 

//1) object declared, with handle name m_xyz_agent

xyz_agent  m_xyz_agent;

 

//2) object created.  what-string-name will you pass in to ::create?   m_xyz_agent or smthg else?

m_xyz_agent = xyz_agent::type_id::create("what-string-name",this);

 

 

When I first started with uvm, I was tripped up a bunch in situations where I confused the handle and the string.  A prime example is in the place of what-string-name below.

uvm_config_db#(uvm_object_wrapper)::set(this,"*.what-string-name.asdf.main_phase", "default_sequence",xyz_seq::type_id::get());

 

 

When different developers use different styles, it can be a headache.

 

So, besides suggesting 'just be consistent', which I fully agree with, what are your preferences, and why?

 

 

thanks,

 

 

Most examples I find have the string name passed to create and the handle match.

(Having them differ does help a newbie understand what is going on a bit better, I believe.)

 

[dave_59]

ljepson74,

 

The reason for this is more than just visual consistency, but for better interoperability with debugging aids.

 

Unlike the static Verilog module hierarchical world, there is no authoritative ownership of objects for the tool to construct a hierarchical pathname. In other words, there is no permanent relationship between the object being created, and the object creating it. The Verilog elaboration process builds a pathname for you for you. When you call new as part of a dynamic procedural thread, you just get a handle to an object that you can store, or you can pass it around to another object. In fact, when you call the factory's create, you are delegating creation to another object; a proxy for that object.

 

For objects derived from uvm_component and uvm_sequence, the UVM has a mechanism to assemble a string pathname for you that is used in reporting. When you debug, it is much easier to navigate through your environment when the pathnames match the actual class variable names that you would use to reference a class variable.

[ljepson74]

Thanks a lot for that clear explanation, Dave.  It looks like that's the way we're going (handle==create's string name).

Does anyone see any reason or case when this doesn't make sense?

[uwes]

hi,

 

normally i have the vlog name and the logical name being the same. exceptions for me are when arrays,QDA etc are involved or when generic code is used

 

 

some examples when the logical name and the vlog instance path can diverge (for me).

 

/uwe

string names[$] ='{"AHB","FOO","BLA"};
uvm_component c[$];

foreach(names[i]) 
  c.push_back(uvm_component::type_id::create(names[i],this));

// stored in assoc array
comp["AHB"]=uvm_component::type_id::create("AHB",this);

btw althrough its convenient to use the string or logical names they are typically unchecked strings and may certain errors during compile. using the facility has a likelihood to hide static errors and only reveal them at runtime. for most code situations the vlog names are a better choice while for debug situations the string names are the better choice.

 

/uwe