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?
[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
[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?
[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?
[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?
[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?
[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.// 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(); // debugQ: Should config objects be shared handles or cloned per agent?
[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.