Resources & Field Macros Hub: config_db, resource_db, and Automation

Overview

UVM configuration has two layers: uvm_config_db for hierarchical component policy, and uvm_resource_db as the typed global pool underneath. Field automation macros complete the picture by generating print, copy, compare, and pack for transaction objects.

Treat config_db for scoped wiring and field macros for object introspection as separate concerns — mixing them casually creates hard-to-debug regressions.

Sub-lessons in this topic

1. uvm-resource-db-vs-config - when to use hierarchical config_db vs flat resource_db.

2. field-automation-macros - uvm_field_* registration and generated do_* methods.

3. print-copy-compare-pack - practical sprint/copy/compare/pack workflows.

4. resource-pool-patterns - scope naming, typed pools, and global knob conventions.

5. field-macro-performance - FLAGS tuning for hot-path transactions.

6. resources-field-debug - symptom-first triage for resource and field issues.

[UVM][CONFIG] resource + field stack

top / package init
  -> resource_db::set("global", knob, value)     [flat scope]
  -> config_db::set(test, "env*", "cfg", cfg)    [hierarchical]

component build_phase
  -> config_db::get(this, "", "cfg", cfg)
  -> config_db::get(this, "", "vif", vif)

transaction class
  -> uvm_field_* macros
      -> auto do_print / do_copy / do_compare / do_pack

use config_db for WHO gets WHAT; field macros for HOW objects report and clone

// config_db: scoped component configuration
uvm_config_db#(env_cfg)::set(this, "env*", "cfg", cfg);

// resource_db: global knob with no hierarchy
uvm_resource_db#(int)::set("global", "max_outstanding", 8, null);

// field macros: transaction introspection
`uvm_object_utils_begin(bus_txn)
  `uvm_field_int(addr, UVM_ALL_ON)
  `uvm_field_int(data, UVM_ALL_ON)
`uvm_object_utils_end

Key takeaways

• config_db is the ergonomic hierarchical layer over resource_db.

• Field macros are for uvm_object data — not uvm_component plumbing.

• Pick one storage model per knob; avoid duplicate set paths.

Common pitfalls

• Using resource_db globals where scoped config_db is clearer.

• UVM_ALL_ON on every field including large arrays and queues.

• Forgetting uvm_field_object on nested items — shallow copy breaks checkers.

Applied Resources & Field Standards

Use a consistent review checklist before promoting new config objects or transaction classes into nightly regressions.

Release checklist

[UVM][CONFIG] resources-field release gate

config contract:
  - every get has a documented set owner
  - path conventions match env/agent hierarchy
  - fatal on missing required cfg/vif in build_phase

field macro contract:
  - FLAGS documented for non-default fields
  - nested objects use uvm_field_object
  - custom do_compare only when semantics differ

hygiene:
  - no duplicate knob in config_db and resource_db
  - no UVM_ALL_ON on megabyte-scale payload arrays

• Document scope strings for resource_db globals in one package init block.

• Keep field macro blocks adjacent to member declarations.

• Log active resource_db globals once at test start for auditability.

[CONFIG] ownership boundaries

config_db owns:
  - per-component cfg handles
  - virtual interface distribution
  - test-to-env policy propagation

resource_db owns:
  - simulation-wide knobs
  - package-level defaults
  - debug dumps of typed pools

field macros own:
  - transaction/config object print and clone semantics

function void audit_resources();
  uvm_resource_db#(int)::dump();
  uvm_config_db::dump();
endfunction

Key takeaways

• Separate hierarchical config from flat global resources by design.

• Field automation should be deliberate — not copy-pasted UVM_ALL_ON.

• Audit dumps are cheap insurance before large regression promotions.

Common pitfalls

• Skipping build_phase fatal checks and deferring config failures to run_phase.

• Hand-writing do_print while also using conflicting field flags.

• Global resource names that collide across VIP packages.