Factory & Config Scenario Interview Q&A

[INT][SENIOR][UVM] MODEL ANSWER

Q: Error injection test build_phase walkthrough?

A:
  MECHANISM:  1) Apply factory override (axi_driver → err_driver). 2) Create cfg,
              set error knobs. 3) config_db set cfg to env*. 4) config_db set vif (if
              not in top). 5) Create env via type_id::create.
  MOTIVATION:  Override before create; cfg before env build so agents get knobs in
              their build_phase get.
  WHEN:       Any scenario test extending base_test — override in apply_factory_overrides(),
              cfg in configure_scenario(), env create last in build.
  PITFALL:    Create env before override — agents built with original driver, override
              never consumed.
  EXAMPLE:    crc_error_test: override err_driver, cfg.inject_crc=1, set cfg, create env —
              err_driver built, injects bad CRC on 10% transactions per cfg knob.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Block env reuse at chip?

A:
  MECHANISM:  Block env compiles unchanged. Chip test sets different config_db paths
              (multiple vif, addr map), possibly wrapper env composing block envs.
  MOTIVATION:  Reuse is the ROI of factory/config decoupling — block VIP agents do
              not recompile for chip address space or multi-instance wiring.
  WHEN:       Chip test: set per-instance vif and cfg; block env get pattern unchanged.
              Factory override rarely needed at chip — mostly config_db scale-up.
  PITFALL:    Chip test modifies block agent source for addr map — breaks reuse,
              fork drift between block and chip repos.
  EXAMPLE:    Block: one agt, set(null,"env.agt*","vif",vif). Chip: 8 instances,
              generate loop set vif[i] to env.bd[i].agt* — block agt code identical.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Override works, cfg knob ignored?

A:
  MECHANISM:  Override affects component type; cfg affects behavior via get in build.
              If cfg get fails silently (no fatal), agent uses defaults despite test set.
  MOTIVATION:  Two independent wiring paths — factory print confirms override; cfg dump
              and sprint confirm config path.
  WHEN:       Triage: factory.print() OK → shift to config_db dump and cfg sprint.
              Compare set path vs agent get_full_name().
  PITFALL:    Assuming one debug path covers both — override and cfg are orthogonal.
  EXAMPLE:    err_driver active (factory print) but txn_count still 100 — cfg get
              failed due to type mismatch env_cfg vs agt_cfg; fix parameterized type.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Both factory and config_db fail?

A:
  MECHANISM:  Common root: test build_phase ordering or test not running (wrong
              +UVM_TESTNAME). Less common: package init order causing neither to run.
  MOTIVATION:  Single root cause (test not built) explains both symptoms — avoid
              parallel debug of factory and config as independent bugs.
  WHEN:       Step 1: confirm +UVM_TESTNAME and test build_phase entered (log marker).
              Step 2: factory print + config dump. Step 3: build order audit.
  PITFALL:    Debugging env internals when test class never instantiated — factory
              empty, config empty, obvious in hindsight.
  EXAMPLE:    Typo in +UVM_TESTNAME — default base_test runs without overrides or
              scenario cfg; 1 hour debug until test name log shows wrong class.

[INT][SENIOR][UVM] MODEL ANSWER

Q: 4-agent env, port 2 passive only?

A:
  MECHANISM:  No factory override needed. config_db set is_active=UVM_PASSIVE for
              env.agt[2] only; UVM_ACTIVE for others. Optional instance override
              if passive needs different monitor type.
  MOTIVATION:  Scenario policy in test build — env remains generic 4-agent composition.
  WHEN:       set(this, "env.agt[2]", "is_active", UVM_PASSIVE) before env build.
              Or per-agent cfg clone with is_active field.
  PITFALL:    set type override on one agent to 'passive agent class' when config_db
              is_active suffices — unnecessary factory complexity.
  EXAMPLE:    Chip integration test: ports 0,1,3 active VIP; port 2 passive tap for
              scoreboard-only observe — one config_db set, zero factory overrides.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Swap scoreboard for one test?

A:
  MECHANISM:  set_type_override(my_scoreboard, enhanced_scoreboard) in test build before
              env create. env creates scb via base type handle uvm_scoreboard or
              my_scoreboard base — factory returns enhanced version.
  MOTIVATION:  One test needs extra checking (latency measure) without forking env for
              all 50 regression tests.
  WHEN:       Instance override if env has multiple scb; type override if one scb.
  PITFALL:    env typed variable my_scoreboard scb — override to enhanced_scoreboard
              fails assignment; use factory create into base handle.
  EXAMPLE:    latency_test: type override enhanced_scoreboard; env code unchanged;
              enhanced version adds cycle count check in write() override.

[INT][SENIOR][UVM] test build_phase whiteboard (canonical order)

  1. log test entry (+ factory print at end)
  2. apply_factory_overrides()
  3. cfg = env_cfg::type_id::create(); apply_defaults(); configure_scenario()
  4. uvm_config_db::set cfg, vif (if needed)
  5. env = my_env::type_id::create("env", this)
  6. factory.print(1) + cfg.sprint() audit

[INT][SENIOR][UVM] MODEL ANSWER

Q: Design config for 100 tests?

A:
  MECHANISM:  Layered cfg object: base_test.apply_defaults() sets safe baseline;
              child configure_scenario() overrides subset; plusargs map to cfg fields
              in one base_test method.
  MOTIVATION:  Single cfg class with field macros documents all knobs; scenario tests
              touch 3-5 fields not 50 — reduces review burden and random cfg bugs.
  WHEN:       env_cfg with grouped fields (protocol, checking, stimulus, timeout).
              Testlist plusargs for regression matrix: +TXN_COUNT=5000.
  PITFALL:    100 tests each creating unrelated cfg classes — env cannot consume
              consistently, config_db type chaos.
  EXAMPLE:    env_cfg has txn_count, enable_err, timeout_ns; 100 tests override 1-3
              fields each; plusarg override for nightly matrix without recompile.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Factory override vs cfg knob for errors?

A:
  MECHANISM:  cfg knob: same driver class reads cfg.inject_rate in run_phase.
              factory override: different driver subclass with error logic built-in.
  MOTIVATION:  cfg knob when error is parameter on existing behavior; override when
              error requires fundamentally different drive algorithm or VIP variant.
  WHEN:       cfg for rate/limit/mode toggles. Override for protocol-violating driver
              subclass that skips legal state machine paths.
  PITFALL:    Override for simple 10% CRC flip — overkill, harder to maintain than
              cfg.inject_crc knob in existing driver.
  EXAMPLE:    CRC error: cfg knob in axi_driver (one class, regression friendly).
              Illegal burst termination: err_driver override (different drive FSM).