Question on instance overrides

UVM
1

Hello,
the UVM reference 1.1, while explaining set_inst_override_by_type and set_inst_override_by_name states following on page 83:
“When the factory processes instance overrides, the instance queue is processed in order of override registrations, and the first override match prevails. Thus, more specific overrides should be registered first, followed by more general overrides.”

Does this mean that there are multiple overrides to the same component instance (these could be from different parts of code), they are stored in a queue. Also last sentence “Thus, more specific overrides should be registered first, followed by more general overrides.” is also not clear.
Can someone explain in detail.

Also uvm reference 1.1 states following on page 85 while explaining the create_component_by_type and create_component_by_name :
“Override searches are recursively applied, with instance overrides taking precedence over type overrides. If foo overrides bar, and xyz overrides foo, then a request for bar will produce xyz. Recursive loops will result in an error, in which case the type returned will be that which formed the loop. Using the previous example, if bar overrides xyz, then
bar is returned after the error is issued.”

Does this mean factory stores the information about instance and type overrides in same data structure and “create” function first checks if there is an instance override and if there is no instance override, checks for type override and accordingly returns the instance of the overriden type (decided by instance or type override with instance override taking priority). Also is it possible to set multiple type overrides on same type (for example type1 overridden by type2 in one place and type1 overridden by type3 in another place? In that case which one takes effect?) Also can same type by overridden recursively, like type1 overriden by type2 and type2 overriden by type3 etc?
Can someone explain in detail please.

regards,
-sunil puranik

2

In reply to puranik.sunil@tcs.com:

“Ordered list” would have been more descriptive than a “queue”

If you were trying to create an object in “A.B.C” and had the following overrides

  1. abc overrides xyz in instance A.B.C
  2. def overrides xyz in instance A.*

A.B.C is the more specific override. If the list was created with 1 first, then 2, then abc would be the override. But if the list was entered 2, than 1, the wider scope A.* would match first, and then def would be the override.

3

In reply to dave_59:

Hi Dave ,

config_db :: set() has a similar scenario about
Generic ( Using wildcard ‘*’ ) N Specific String via string argument ’ inst_name ’ ( Configuring Sequences )

As you explained in the link above that ::

With config_db :: set() Calls :: " The more specific string setting must come after the less specific string setting. "

This made sense logically since base test can call config_db :: set() via wildcard and Extended Tests can set specific string via config_db :: set() .
Hence the 2nd set() via extended test would be read first .

However with instance override I Observe the opposite .
I tried going through the Source Code ( It’s a bit convoluted to follow , hence I didn’t look into it in depth ) has a queue which does a push_back for each instance override .

Within source code I observe ::
Instance Override are pushed_back in a Queue whereas config_db::set() are push_front in Queue ( as per your comments in the above thread )

**The read would be done from front to back it seems in both cases .
**

[Q1] Why is Instance Override ( First Instance Override wins ) opposite to the config_db::set() Last config_db::set() wins ( when set() from build_phase() at Same Level of Hierarchy ) approach ?

Does it have a logical reasoning behind or is it simply what was chosen as
the implementation .