Overview

UVM reporting controls log noise, failure counting, and test PASS/FAIL. Every `uvm_info, `uvm_warning, `uvm_error, and `uvm_fatal message flows through a structured pipeline before reaching the log file and the report server's severity counters.

Understanding this pipeline is essential for regression triage: knowing why a message printed, why another was suppressed, and how the final PASS/FAIL decision is made from UVM_ERROR and UVM_FATAL counts.

Sub-topics

1. Reporting Architecture — handler, server, catcher flow and report pipeline.

2. Severities & Actions — info, warning, error, fatal with decision tree.

3. Message IDs & Verbosity — filter keys, plusargs, verbosity ladder.

4. Report Catchers — demote VIP noise, THROW vs CAUGHT flow.

5. PASS/FAIL & Debug Playbook — report server counts, quit limits, triage steps.

Legend: [UVM]

  REPORT PIPELINE (every message)

  `uvm_info/error/warning/fatal("ID", "msg", verbosity)
       │
       ▼
  uvm_report_handler          ← per-component verbosity + action mask
       │  (message passes filter?)
       ▼
  uvm_report_catcher chain     ← optional: demote, promote, swallow
       │  (THROW → continue, CAUGHT → stop)
       ▼
  uvm_report_server            ← global severity counters
       │
       ├──► log file (UVM_LOG action)
       ├──► stdout   (UVM_DISPLAY action)
       └──► counter   (UVM_COUNT action) → PASS/FAIL

Key takeaways

• PASS/FAIL from report server UVM_ERROR + UVM_FATAL counts.

• Only uvm_info is verbosity-gated; errors always print and count.

• Message IDs enable selective debug without global UVM_FULL.