UVM Factory : how to solve type_name conflict across multiple packages?

Hi,
I am facing the following issue
I have 2 uvm_objects classes with the same name in different packages. These 2 classes register their type name in the factory via `uvm_object_utils()

This results in the following message during simulation
“UVM_WARNING @ 0: reporter [TPRGED] Type name ‘bar’ already registered with factory. No string-based lookup support for multiple types with the same type name”

when calling any of the override functions (set_inst_override* set_type_override*), since the factory only holds one entry per type name regardless of the context of the type, how do we solve the type name conflict ?

example


package pkg1;
   class foo extends uvm_object;
      `uvm_object_utils(foo)
   endclass

   class bar extends foo;
      `uvm_object_utils(bar)
   endclass
endpackage 


package pkg2;
   class bar extends uvm_object;
      `uvm_object_utils(bar)
   endclass
endpackage 



class env extends uvm_env;
   function void build_phase (uvm_phase phase);
      super.build_phase(phase);

      set_type_override_by_type(pkg1::foo::get_type(), pkg1::bar::get_type());
endfunction : build_phase

endclass

since pkg1::bar::get_type() returns the same type name as pkg2::bar::get_type(), what would the factory do ? I am hitting some inconsistent results with a similar case when integrating various environment from multiple team, when some class name are conflicting across package.

Thanks for your help

In reply to Romain2511:

My recommendation is to develop a naming convention for your code base which incorporates uniqueness so that there won’t be any conflicts.

For example:
Agents use ‘company_protocol_XXX’ format for all packages/components.
Environments and tests use ‘design_XXX’ for everything.

This makes vertical reuse easier because it also allows you to track where everything was imported from.

In reply to cgales:

Hi cgales
Thanks for your reply. So your comment seems to confirm that the uvm factory does not store any context for each of the type_name that are registered to its table. so any class with the same name, even if there in complete different cluster/package for a complete different part of the system, will clash in the factory table.

That sounds like a challenge for big projects with multiple teams and sometimes companies involved (outsourcing)

I am still a bit surprised about this limitation and concluded that I was missing something about the factory mechanism.

In reply to Romain2511:

Some suggestions:

You can use
`uvm_object_param_utils(bar)
instead of `uvm_object_utils(bar). This simply removes the string-based factory registration.

Type based factory registration is more efficient and gives you earlier compilation errors for most mistakes. String comparison in SystemVerilog is cumbersome and checking can only be performed at runtime. Use instance-based string overrides only if absolutely necessary.

In reply to dave_59:

Hi Dave
Thank you for your suggestion.

Could you help clarify something ?
since I am calling set_type_override_by_type, there is no string-base lookup involved is that correct ? (as opposed to set_type_override_by_name)

can the return value of pkg1::bar::get_type() match the type registered by pkg2::bar::get_type() in the factory table during the call to set_type_override_by_type() ?

I think that this is what is happening in my scenario.

Thank you
Romain

In reply to Romain2511:

The warning is coming from the registration macro, not the override. It registers just the first “bar” and ignores the rest. Whether the first bar is in pkg1 or pkg2 is indeterministic.

All user defined type names are unique to the scope they are declared in. The return type of get_type is an object extended from uvm_object_wrapper, and that extension is a specialization of uvm_object_registry paramterzied by the class being wrapped. So yes they a unique return types from each package.