Override Precedence Rules: Who Wins at create()

Precedence ladder

At create time the factory evaluates overrides in a fixed priority order . Instance match on exact path beats type replacement; default construction is last.

[FACTORY][UVM] precedence (highest wins)

1) Instance override on exact full path
2) Type override on requested type
3) No override -> build requested type

Example policies:
  type:    base_driver -> err_driver
  inst:    env.agt1.drv -> stress_driver

results:
  env.agt0.drv -> err_driver
  env.agt1.drv -> stress_driver   (instance wins)
  env.agt2.drv -> err_driver

base_driver::type_id::set_type_override(err_driver::get_type());
base_driver::type_id::set_inst_override(
  stress_driver::get_type(),
  "env.agt1.drv"
);

// create(base_driver) outcomes resolved by precedence rules above

Key takeaways

• Instance override is the precision tool that can override a type override.

• Precedence is per create() call using that call's resolved path.

• Conflicts are not errors — last effective policy wins by rule order.

Common pitfalls

• Assuming type override always wins because it was registered first.

• Registering two instance overrides for same path without replace flag.

• Interpreting factory.print order as runtime precedence order.

Replace flag and layered test hierarchies

Child tests and base tests may both define override policy. Understand replace semantics and intentional ordering.

replace argument behavior

factory.set_inst_override_by_type(
  base_driver::get_type(),
  stress_driver::get_type(),
  1,    // replace=1: replace existing inst override for same path/type
  this,
  "env.agt_tx.drv"
);

• replace=0 keeps existing override and may leave old policy active.

• replace=1 overwrites prior instance override on same key.

• Document ordering when base_test and child_test both set policy.

Layered hierarchy conflict diagram

[FACTORY] base/child override layering

base_test.apply_factory_overrides:
  type base_driver -> err_driver

child_test.apply_factory_overrides:
  inst env.agt_tx.drv -> stress_driver

final:
  agt_tx.drv -> stress_driver (instance precedence)
  agt_rx.drv -> err_driver (type only)

anti-pattern:
  child adds second type override without documenting interaction

[UVM] conflict triage

symptom: unexpected derivative on one agent only
check:
  1) list all type overrides affecting requested type
  2) list instance overrides matching that full path
  3) apply precedence ladder mentally
  4) confirm with get_type_name()

Common pitfalls

• Multiple child tests overriding same path with different derivatives.

• Relying on registration order instead of precedence rules.

• Silent partial overrides when replace=0 and duplicate keys exist.