uvm_config_db Hub: Hierarchical Typed Configuration

Overview

The uvm_config_db is UVM's standard mechanism for passing handles and parameters into components without hard-wiring values in the environment. It is a typed, hierarchical key/value store layered on the global resource database — producers set() values scoped to paths; consumers get() them during build_phase or later.

Mastering config_db means mastering four aligned arguments on every set/get, deliberate path design with wildcards, resolution precedence when multiple sets compete, and typed patterns that scale from a single agent to multi-interface SoCs.

Sub-lessons in this topic

1. config-db-set-get-contract — the four-argument contract and context rules.

2. inst-path-wildcards — instance paths, wildcards, and scope discipline.

3. config-resolution-order — precedence when multiple sets target one consumer.

4. typed-config-patterns — config objects, scalars, enums, and virtual handles.

5. config-db-vs-parameters — when to use config_db vs #() parameters.

6. config-db-debug — triage for silent get failures and path mismatches.

Configuration stack map

Legend: [CONFIG] [HDL] [UVM]

[HDL] top.sv
  initial: config_db.set(null, path, "vif", if_i)   ◄── static publish
       │
       ▼
[CONFIG] uvm_config_db pool
  keyed by: full_path + field_name + type #(T)
       │
       ▼
[UVM] test.build_phase
  config_db.set(this, "env.apb", "cfg", acfg)
       │
       ▼
[UVM] agent.build_phase
  config_db.get(this, "", "cfg", cfg)   ◄── hierarchical lookup
  config_db.get(this, "", "vif", vif)

FACTORY picks WHICH class; CONFIG_DB supplies WITH WHAT settings

[CONFIG] hierarchical lookup (consumer at uvm_test_top.env.apb.drv)

  lookup walks UP from consumer, matching:
    1) instance path pattern
    2) field name string
    3) template type #(T)

  set from test:     "env.apb" + "cfg" + apb_config
  get from driver:   "" + "cfg" + apb_config   → finds test set ✓

Key takeaways

• config_db is the standard UVM configuration transport — not ad-hoc globals.

• All four set/get arguments must align: context, path, field name, and type.

• Path specificity and hierarchy position determine resolution precedence.

• Check get() return value for critical fields; silent failure is the #1 debug trap.

Common pitfalls

• Type mismatch between set and get — get returns 0 with no compile error.

• Field-name typo — same silent failure as type mismatch.

• Over-broad wildcards leaking config into unintended components.

• Setting config after consumer build_phase — too late for build-time gets.