Part 11 · Senior Prep · Intermediate

Type & Instance Overrides Interview Q&A

Model answers on set_type_override vs set_inst_override, override precedence, scoping, and multi-agent override strategy.

Override scope and precedence

Override questions are about scope and specificity — instance beats type, and path typos silently do nothing.

Q: Type override vs instance override?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Type vs instance override?

A:
  MECHANISM:  set_type_override swaps all instances of original type. set_inst_override
              targets one hierarchy path — more specific, wins over type override.
  MOTIVATION:  Type for class-wide substitution in a test; instance for one agent in
              multi-agent env (corrupt only port 3).
  WHEN:       set_type_override for test-wide driver swap; set_inst_override for
              env.agt[3].drv only in 4-port PCIe env.
  PITFALL:    Instance path typo — override applies to nothing, factory print shows
              no match, debug starts in wrong place.
  EXAMPLE:    Four identical PCIe agents; instance override on env.pcie_agt[1].mon
              for enhanced logging without touching other three ports.

Q: What is override precedence when multiple overrides exist?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Override precedence?

A:
  MECHANISM:  Most specific wins: instance override > type override > no override.
              Last-writer wins among same specificity level.
  MOTIVATION:  Predictable resolution lets test override one instance while base_test
              sets type-wide default — hierarchy of override policy.
  WHEN:       base_test sets type override for debug driver; child test sets instance
              override on one agent to use production driver for golden compare.
  PITFALL:    base_test and child_test both set instance override on same path —
              last-writer wins silently, intent becomes unclear across inheritance.
  EXAMPLE:    Type override: all axi_driver  err_driver. Instance override on
              env.agt_golden.drv  axi_driver (original). Golden agent clean, rest corrupt.

Q: Where should overrides be applied in the phase timeline?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: When to apply overrides?

A:
  MECHANISM:  Overrides must be registered before create() of the target component —
              typically test build_phase before env.build creates agents.
  MOTIVATION:  create() consults factory at construction time — late override after
              component exists has no effect on already-constructed instance.
  WHEN:       test.build_phase first lines: apply_factory_overrides() then super/build env.
              base_test centralizes override policy; child tests extend apply_factory_overrides().
  PITFALL:    Override in run_phase — env and agents already constructed with original types.
  EXAMPLE:    test.build: apply overrides  cfg create  env create. env.build creates
              err_driver because override registered before env type_id::create.

Q: Global vs local override — what is set_inst_override_by_type?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: set_inst_override_by_type?

A:
  MECHANISM:  set_inst_override_by_type(original_type, override_type, instance_path)
              replaces only instances of original_type matching instance_path pattern.
  MOTIVATION:  Finer than type override, broader than single named component — match
              all drivers under env.agt* without listing each index.
  WHEN:       Multi-agent env: override all monitors under env.tx_agt* with debug_mon.
  PITFALL:    Path glob mismatch — "env.agt*" vs "env.agt" behave differently;
              verify with factory print instance path column.
  EXAMPLE:    set_inst_override_by_type(axi_monitor, debug_monitor, "env.slave_agt*")
              — all slave agents get debug monitor, master agents unchanged.

Key takeaways

  • Instance override beats type override; last-writer at same level.

  • Apply overrides before create() — typically start of test build_phase.

  • Glob path patterns need factory print verification.

Common pitfalls

  • Late override after component construction — no effect.

  • Competing overrides from base_test and child_test without ordering policy.


Override strategy and debug

Q: How do you prevent override leaks between tests?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Prevent override leaks?

A:
  MECHANISM:  Each simulation run starts fresh factory state — overrides do not persist
              across separate sim invocations. Within one sim, overrides persist until
              explicitly replaced.
  MOTIVATION:  Regression runs one test per sim — leak is intra-test (global override
              affecting unintended paths), not inter-test.
  WHEN:       Prefer instance overrides in scenario tests. Avoid set_type_override without
              path restriction in shared base_test unless all child tests expect it.
  PITFALL:    set_type_override in package initial block — applies to every test in
              regression without test author awareness.
  EXAMPLE:    Package init sets global err_driver override — smoke test fails because
              it expected clean driver; move override to error_injection_test only.

Q: How do you override a parameterized type?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Override parameterized types?

A:
  MECHANISM:  Factory keys on parameterized type identity — uvm_driver#(axi_item) and
              uvm_driver#(apb_item) are different factory entries.
  MOTIVATION:  Parameterized VIP must register and override with exact parameter match.
  WHEN:       Override using #(exact_item_type) on both original and override types.
  PITFALL:    Override axi_driver without parameter — matches wrong registry entry or
              none; override appears set but create uses original.
  EXAMPLE:    set_type_override_by_type(axi_driver#(axi_item)::get_type(),
              axi_err_driver#(axi_item)::get_type()) — parameter must match.
diagram
[INT][SENIOR][UVM] override scope ladder (whiteboard)

  global type override     ← broadest, highest leak risk
    set_type_override_by_type
  instance-by-type         ← path glob, preferred for multi-agent
    set_inst_override_by_type("env.agt*.drv")
  single instance          ← most specific, best isolation
    set_inst_override_by_type("env.agt_tx.drv")

Q: Describe override strategy for a 50-test regression

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Override strategy for 50-test regression?

A:
  MECHANISM:  base_test.apply_factory_overrides() empty by default; each scenario test
              overrides apply_factory_overrides() with instance-scoped substitutions.
  MOTIVATION:  Centralized hook documents override policy; factory print in base_test
              build logs active overrides for every test — audit trail in regression log.
  WHEN:       Instance override per scenario; type override only in dedicated debug
              test classes; never in package init or env.build.
  PITFALL:    Copy-paste override block into 10 tests with slightly different paths —
              maintenance nightmare; extract helper set_agent_override(agent_id, type).
  EXAMPLE:    50 tests, 3 use overrides (error drv, debug mon, slow seq item) — each
              instance-scoped, factory print in log proves exactly one substitution each.

Key takeaways

  • Parameterized overrides require exact type parameter match.

  • Package-init global overrides are the main intra-regression leak pattern.

  • Centralize override policy in base_test.apply_factory_overrides().

Common pitfalls

  • Wrong parameterized type in override — silent no-match.

  • Global type override in shared package init block.