Type vs Instance Overrides Hub: Scope, Precedence, and Safety

Overview

Factory overrides let tests say build B when env requests A . Scope determines blast radius: type overrides are broad, instance overrides are surgical. Precedence and timing decide whether policy actually takes effect.

Treat overrides as test-owned policy registered before hierarchy construction. Env code should keep requesting stable base types.

Sub-lessons in this topic

1. type-overrides-scope - global replacement by requested type.

2. instance-overrides-scope - path-targeted replacement for one node.

3. override-precedence-rules - who wins when multiple policies apply.

4. override-timing-before-create - register before super.build_phase.

5. liskov-substitution-safety - structural/behavioral contracts for derivatives.

6. overrides-debug-patterns - print, path checks, and conflict triage.

[FACTORY][UVM] override scope ladder

TYPE (broad)
  base_driver -> err_driver
  affects every create(base_driver)

INSTANCE (surgical)
  "env.agt_tx.drv" -> stress_driver
  affects only matching full path

PRECEDENCE at create:
  instance on path > type on requested type > default

class err_inject_test extends base_test;
  `uvm_component_utils(err_inject_test)

  function void build_phase(uvm_phase phase);
    base_driver::type_id::set_inst_override(
      err_driver::get_type(),
      "env.agt_tx.drv"
    );
    super.build_phase(phase);
  endfunction
endclass

Key takeaways

• Type overrides are powerful defaults; instance overrides are precise tools.

• Instance override wins over type override on the same path.

• Register overrides before any create() for the target instance.

Common pitfalls

• Blanket type overrides in multi-agent envs when only one agent should change.

• Registering overrides after super.build_phase builds the env.

• Override classes that break base ports or parameterization.

Applied override standards

Use explicit override helpers in tests so policy stays auditable across scenarios.

Test override template

[FACTORY][UVM] override policy template

build_phase order:
  1) apply_factory_overrides()   // test-owned
  2) super.build_phase()         // env create chain
  3) post_build_sanity_checks()  // optional type name logs

documentation:
  - why override exists (scenario intent)
  - scope (type vs instance)
  - expected get_full_name() path

• Centralize overrides in one virtual method per test.

• Log active overrides at UVM_LOW on scenario start.

• Never hide overrides in unrelated config helpers.

[FACTORY] override ownership

base_test may define:
  apply_factory_overrides() default empty

scenario test overrides:
  apply_factory_overrides() with explicit scope

env must not:
  set test-scenario overrides silently