Part 11 · Senior Prep · Intermediate

config_db set/get Interview Q&A

Model answers on uvm_config_db path matching, field names, type parameters, wildcard pitfalls, and set/get ordering.

config_db matching rules

config_db failures are the #1 integration debug task — senior engineers name the four mismatch modes instantly: path, name, type, ordering.

Q: Why does config_db get fail?

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

Q: config_db get fails — causes?

A:
  MECHANISM:  set stores (scope path, field name, type); get retrieves if all three
              match the requesting component's context and lookup rules.
  MOTIVATION:  Decouple top-level test wiring from deep component internals — agent
              asks for "vif" without knowing which test set it.
  WHEN:       set from test/top before build of consumer; get in consumer build_phase.
  PITFALL:    Path mismatch ("env.agt" vs "env.agt.drv"), name typo, wrong parameterized
              type (#(virtual axi_if) must match exactly), or set after get (ordering).
  EXAMPLE:    set(null,"*","vif",vif) works broadly; set(env,"agt.drv","vif") fails
              if drv looks under "" inst_path expecting upward search from agt context.

Q: Explain inst_path in set vs get

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

Q: inst_path in set vs get?

A:
  MECHANISM:  set(setter, inst_path, field_name, value) — inst_path is target scope
              pattern. get(this, inst_path, field_name, variable) — inst_path refines
              lookup from calling component's full name.
  MOTIVATION:  Hierarchical scoping mirrors UVM tree — set from test with "env.agt*"
              reaches all agents without knowing internal structure.
  WHEN:       set from test with null or this as setter; get in component with "" or
              explicit relative path for local lookup.
  PITFALL:    set(this, "env", "cfg", cfg) vs get in env with inst_path "" — works.
              set(this, "env.agt", "cfg") vs get in agt.drv with "" — drv may not see
              agt-level set depending on search rules — verify hierarchy.
  EXAMPLE:    Test: set(null, "env.agt*", "cfg", cfg). Agent get: get(this,"", "cfg", cfg)
              — agent finds it. Driver get with wrong inst_path: miss.

Q: Wildcard set — when is it acceptable?

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

Q: Wildcard set acceptable?

A:
  MECHANISM:  set(null, "*", "field", value) or set("*","*","field", value) broadcasts
              to broad scope — any get matching field name succeeds regardless of path.
  MOTIVATION:  Quick bring-up and virtual interface broadcast from top when hierarchy
              unstable during early development.
  WHEN:       Early block bring-up only. Replace with explicit paths before code review
              merge and definitely before chip-level integration.
  PITFALL:    Wildcard masks path bugs — block TB passes, chip TB fails because two
              agents get wrong vif from global wildcard collision.
  EXAMPLE:    set(null,"*","vif", vif) in top — both tx and rx agents get same vif handle
              when rx needed different interface — silent wrong-capture bug.

Q: set/get ordering — what breaks if set is too late?

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

Q: Late set breaks what?

A:
  MECHANISM:  get in build_phase expects value already in config_db — late set in
              run_phase arrives after consumer build already failed or got default.
  MOTIVATION:  build_phase is configuration window — components snapshot config at
              construction, not continuously poll config_db.
  WHEN:       All config_db set before or during early build_phase of consumer. Test
              build runs before env build in top-down phase order.
  PITFALL:    Setting cfg knob in run_phase — agent built with default cfg in build,
              run_phase set never re-read unless component explicitly re-gets.
  EXAMPLE:    test run_phase sets cfg.txn_count=5000 — agent already randomized with
              default 100 in build — test appears to set knob but stimulus unchanged.

Key takeaways

  • Four failure modes: path, name, type, ordering.

  • Wildcards for bring-up only — explicit paths for production TBs.

  • set must precede consumer build_phase get.

Common pitfalls

  • Wildcard set hiding dual-agent vif collision until chip integration.

  • Late cfg set in run_phase — consumer already snapshotted defaults.


config_db debug and patterns

Q: How do you debug config_db in under two minutes?

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

Q: Debug config_db quickly?

A:
  MECHANISM:  uvm_config_db#(T)::dump() prints all entries. Check get return value
              (0=fail). Compare set inst_path against consumer get_full_name().
  MOTIVATION:  Structured triage beats random set/get edits — four mismatch modes
              localize in one dump review.
  WHEN:       On any uvm_fatal from config get. Step 1: dump. Step 2: match path/name/type.
              Step 3: verify set call executed before get (build order log).
  PITFALL:    Adding wildcard set to 'fix' get failure — hides root path typo.
  EXAMPLE:    dump shows set at "env.agt_tx" but get from env.agt_rx — path typo
              in test copy-paste, fix inst_path not broaden wildcard.

Q: config_db vs uvm_resource_db?

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

Q: config_db vs resource_db?

A:
  MECHANISM:  config_db is resource_db with component-context convenience API —
              set/get infer scope from component hierarchy.
  MOTIVATION:  Hierarchical scope matches UVM tree intuition for TB wiring.
  WHEN:       config_db for vif, cfg objects, per-agent ints/strings. resource_db for
              truly global name-only lookup without hierarchy context.
  PITFALL:    Wildcard abuse in config_db — set("*","*","vif",vif) masks path bugs.
  EXAMPLE:    cfg object via config_db to agt; integer verbosity via resource_db with
              name "VERBO" if truly global across non-UVM SV modules.
systemverilog
// config_db — interview pattern
uvm_config_db#(env_cfg)::set(this, "env*", "cfg", cfg);
if (!uvm_config_db#(env_cfg)::get(this, "", "cfg", cfg))
  `uvm_fatal("CFG", "cfg not found")

uvm_config_db#(env_cfg)::dump();  // debug

Q: Should config objects be shared handles or cloned per agent?

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

Q: Shared vs cloned cfg?

A:
  MECHANISM:  config_db stores handle — all getters share same object unless deep
              copy performed. Per-agent cfg requires separate create + set per agent.
  MOTIVATION:  Shared cfg for global policy (timeout, enable_scoreboard); per-agent
              cfg for port-specific knobs (address map, active/passive).
  WHEN:       Shared: one env_cfg to env*. Cloned: agt_cfg array with per-index set
              to env.agt[i] before agent build.
  PITFALL:    One shared cfg mutated by agent[0] in build — agent[1] sees mutated
              values unintentionally (order-dependent randomization).
  EXAMPLE:    4-port env: cfg[4] array, set each to env.agt[i] with unique addr_offset;
              shared env_cfg only for global enable_coverage bit.

Key takeaways

  • dump() + return check localizes config failures fast.

  • config_db is hierarchical sugar over resource_db.

  • Shared cfg handle means shared mutations — clone when per-agent knobs needed.

Common pitfalls

  • Wildcard masking path typo instead of fixing inst_path.

  • Shared cfg mutated by one agent affecting siblings.