Part 10 · Advanced Topics · Intermediate

Reporting and Factory Diffs That Affect Real Regressions

Differences and migration traps in message control and factory override usage across 1.2-style and 1800.2-focused flows.

Why reporting/factory are migration hotspots

Most code compiles after a library swap; most regressions fail because of behavior expectations. Reporting and factory are where teams encode those expectations: log IDs, verbosity targeting, override precedence, and debug assumptions.

A tiny semantic mismatch can flood logs, hide errors, or instantiate unexpected component types. These are high-cost failures because they distort triage signal across thousands of tests.

diagram

[ADV] impact map

  Reporting mismatch  -> log volume spikes / missing diagnostics / false confidence
  Factory mismatch    -> wrong type instantiated / override ignored / hidden behavior
  Combined effect     -> triage noise, flaky signatures, slow migration

Reporting deltas to audit

The safest reporting migration strategy is explicitness: explicit IDs, explicit component paths, explicit severity actions. Implicit defaults are where mode and vendor variation hurts most.

diagram

[UVM] reporting audit table

  Audit item                     Why it breaks                     Preferred direction
  ---------------------------------------------------------------------------------------------
  ID naming inconsistency        +uvm_set_verbosity misses target  normalize IDs by subsystem
  Path wildcard overuse          noisy or under-filtered logs      scope patterns intentionally
  Reliance on default actions    vendor/mode differences           set actions explicitly
  Legacy helper wrappers         strict lane rejects               migrate to standard calls

systemverilog

// Explicit reporting intent is migration-friendly
function void build_phase(uvm_phase phase);
  super.build_phase(phase);
  set_report_id_verbosity("SCB", UVM_MEDIUM);
  set_report_severity_action(UVM_ERROR, UVM_DISPLAY | UVM_COUNT);
endfunction

Prefer stable report IDs (`CFG`, `SCB`, `DRV`) over ad-hoc strings.
Document wildcard patterns used in CLI verbosity controls.
Audit old wrappers that indirectly call reporting APIs.

Factory override differences in practice

Factory issues usually appear as 'test behaves differently' rather than compile errors. Root causes include override timing, path mismatch, and assumptions about instance-vs-type precedence.

systemverilog

class base_test extends uvm_test;
  `uvm_component_utils(base_test)

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);

    // Type override example
    my_driver::type_id::set_type_override(my_driver_errinj::get_type());

    // Instance override example
    my_monitor::type_id::set_inst_override(
      my_monitor_trace::get_type(),
      "uvm_test_top.env.agt*.mon"
    );
  endfunction
endclass

diagram

[UVM] factory migration checklist

  1) Confirm override executed before create()
  2) Confirm instance path matches final hierarchy
  3) Confirm no later override masks earlier intent
  4) Dump factory in debug lane for deterministic evidence
  5) Compare strict/compat logs for override registration differences

Factory debug instrumentation

systemverilog

function void start_of_simulation_phase(uvm_phase phase);
  super.start_of_simulation_phase(phase);
  if ($test$plusargs("DUMP_FACTORY"))
    uvm_factory::get().print(1);
endfunction

Use targeted factory dumps; full dumps in every test are expensive.
Capture dumps in failing strict-lane seeds for reproducible triage.
Keep hierarchy naming conventions stable to protect instance overrides.

Diff triage flow for mixed failures

When logs change and behavior changes together, triage in two passes: reporting stability first, then factory behavior. Otherwise changed diagnostics can hide the override bug.

diagram

[ADV] two-pass triage

  Pass A (signal stabilization):
    - normalize verbosity targets
    - confirm expected report IDs visible
    - remove log noise from wildcard misuse

  Pass B (behavior validation):
    - assert expected override registrations
    - trace create() type resolutions
    - compare DUT-facing stimulus and monitor output

diagram

[UVM] reporting/factory risk chart

  Risk category         Symptom                          Typical fix
  -------------------------------------------------------------------------------
  Low                   minor log wording drift          update log parser patterns
  Medium                missing debug IDs               normalize report ID conventions
  High                  wrong component subtype created fix override path/timing
  Critical              silent disabled checker         enforce explicit severity actions

Key takeaways

Reporting and factory behavior should be made explicit before migration runs.
Override bugs manifest as behavioral drift, not just compile failures.
Stabilize diagnostics first, then resolve factory semantics.

Common pitfalls

Debugging factory issues with noisy, unstable reporting configuration.
Applying instance overrides with stale hierarchy paths.
Assuming one passing seed implies override logic is safe.

Practice this lessonQuestions tagged for this topic in the bank