Resources & Field Macros Interview Q&A

[INT][SENIOR][UVM] MODEL ANSWER

Q: resource_db vs config_db?

A:
  MECHANISM:  resource_db is flat name+scope lookup; config_db adds component-relative
              path resolution on top of same storage backend.
  MOTIVATION:  config_db for hierarchical TB wiring; resource_db for global settings
              or non-UVM SV code that lacks component context.
  WHEN:       config_db: vif, cfg, per-agent knobs. resource_db: simulator-wide verbosity
              control, PLI tool settings, shared backdoor map handle.
  PITFALL:    Using resource_db to bypass path discipline — same wildcard masking as
              config_db set("*","*").
  EXAMPLE:    UVM agent gets cfg via config_db; DPI C model gets memory map via
              resource_db set by name "DUT_BACKDOOR" — no component parent needed.

[INT][SENIOR][UVM] MODEL ANSWER

Q: uvm_field_* macros?

A:
  MECHANISM:  `uvm_object_utils_begin/end with `uvm_field_int/string/object_enum
              generates do_print, do_copy, do_compare, do_pack, do_record automatically.
  MOTIVATION:  Config and transaction classes need consistent print/compare for debug
              without hand-writing every method — regression log diff relies on it.
  WHEN:       cfg objects, seq_items, transaction classes — any uvm_object needing
              print in uvm_info or compare in scoreboard.
  PITFALL:    Field macro on class member that should not print (security key, huge
              array) — floods log or leaks sensitive test data.
  EXAMPLE:    axi_item with field macros — driver prints req after randomize;
              scoreboard compare uses auto-generated do_compare for mismatch report.

[INT][SENIOR][UVM] MODEL ANSWER

Q: component_field vs field?

A:
  MECHANISM:  uvm_field_* for uvm_object members; uvm_component_field_* additionally
              supports config_db automation via uvm_config_db hooks in utils macro.
  MOTIVATION:  Component members (like enable_coverage bit on agent) benefit from both
              print/compare AND optional config_db set/get automation.
  WHEN:       field on seq_item/cfg object; component_field on uvm_component integer
              or enum knobs that test may set via config_db without manual get.
  PITFALL:    component_field on handle types — automation may not deep-copy correctly;
              manual get/set safer for object handles.
  EXAMPLE:    Agent has uvm_component_field_int(enable_coverage) — test can
              uvm_config_db::set(agent, "", "enable_coverage", 0) without agent code.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Field macro downsides?

A:
  MECHANISM:  Macros expand to verbose code at compile time — increase compile memory
              and time; generated methods hard to customize without override conflicts.
  MOTIVATION:  Teams hit macro limits when needing custom print format or partial compare.
  WHEN:       Use macros for standard cfg/items; hand-write do_compare when scoreboard
              needs mask/compare with tolerance or ignore fields.
  PITFALL:    Override do_print and also use field macros for same fields — double
              print or conflicting formats in log.
  EXAMPLE:    Large 512-bit payload item — field macro prints entire payload at UVM_HIGH
              flooding 10GB log; hand-write do_print truncating display.

[INT][SENIOR][UVM] MODEL ANSWER

Q: config_db automation via component_field?

A:
  MECHANISM:  uvm_component_utils with component_field registers field name for
              automatic uvm_config_db::get in apply_config_settings phase hook.
  MOTIVATION:  Test sets integer/string/enum on agent without agent manually calling
              get for each knob — reduces boilerplate in agent build_phase.
  WHEN:       Simple scalar knobs: is_active, enable_coverage, max_delay. Not for
              virtual interfaces or cfg object handles — manual get required.
  PITFALL:    Relying on automation for vif — component_field does not handle virtual
              interface types correctly in all UVM versions.
  EXAMPLE:    Test: uvm_config_db#(uvm_active_passive_enum)::set(this, "env.agt*",
              "is_active", UVM_PASSIVE). Agent build auto-applies — no manual get.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Print config object state?

A:
  MECHANISM:  cfg.print() or `uvm_info with %s and cfg.sprint() — uses field macro
              generated do_print. uvm_config_db::dump for raw db entries.
  MOTIVATION:  Stimulus/debug mismatch often traces to wrong cfg value — sprint at
              test start documents exact knobs for regression log audit.
  WHEN:       base_test build after apply_defaults and configure_scenario: cfg.sprint().
              On failure: compare sprint between passing and failing seed.
  PITFALL:    Printing cfg before configure_scenario override — log shows defaults
              not actual scenario values used in run_phase.
  EXAMPLE:    Nightly log includes cfg.sprint at UVM_LOW — triage shows txn_count=100
              when test expected 5000, traces to child test override not called.

[INT][SENIOR][UVM] MODEL ANSWER

Q: copy vs clone?

A:
  MECHANISM:  copy(dest) copies into existing object; clone() creates new object and
              copies — both use field macro generated do_copy unless overridden.
  MOTIVATION:  Per-agent cfg needs independent copy so mutations do not alias shared
              handle — clone in test before per-agent set.
  WHEN:       Shared defaults: one cfg, read-only in agents. Per-agent: cfg.clone()
              in loop, customize, set to each agent path.
  PITFALL:    Shallow copy of object handle field — two cfg copies share same sub-object;
              mutation in one visible in other.
  EXAMPLE:    agt_cfg = base_cfg.clone(); agt_cfg.addr_offset = i*0x1000;
              uvm_config_db::set(null, $sformatf("env.agt[%0d]",i), "cfg", agt_cfg);