Scoreboard + Coverage Hub: Integrated Checking Pipelines

Overview

A robust environment connects monitor output into both scoreboard and coverage consumers with deterministic ordering and transparent counters. Integration quality determines checker trust and closure velocity.

Treat this as one system: monitor publish -> analysis transport -> checkers + coverage -> reporting .

Sub-lessons in this topic

1. analysis-port-fanin - merging monitor streams into checker pipelines.

2. scoreboard-env-wiring - env-side wiring contracts for scoreboard ingest.

3. coverage-subscriber-env - coverage subscriber placement and fan-out.

4. dual-stream-checking - expected-vs-observed stream alignment patterns.

5. env-checking-pipeline - staged checking pipelines for scale.

6. checking-integration-debug - deterministic triage for integrated checking.

[ENV][UVM][CHECK] integrated checking stack

monitor streams:
  ctrl_mon.ap -----------  data_mon[i].ap ---------+--> scoreboard exports
  err_mon.ap  ------------/
                       +--> coverage subscribers

pipeline:
  sample -> normalize -> correlate -> compare -> report

invariants:
  no dropped stream silently
  no post-publish mutation
  counter visibility in report_phase

class env_scoreboard extends uvm_component;
  `uvm_component_utils(env_scoreboard)
  uvm_analysis_imp_ctrl #(ctrl_txn, env_scoreboard) ctrl_imp;
  uvm_analysis_imp_data #(data_txn, env_scoreboard) data_imps[int];
  int ctrl_hits, data_hits;

  function new(string name, uvm_component parent);
    super.new(name, parent);
    ctrl_imp = new("ctrl_imp", this);
  endfunction
endclass

Key takeaways

• Scoreboard and coverage are complementary, not competing, consumers.

• Analysis transport correctness is as important as compare logic.

• Visible counters are mandatory for trust in integration health.

Common pitfalls

• Treating coverage-only activity as proof checker paths are live.

• Hiding dropped or filtered transactions without diagnostics.

• Allowing mutable transaction objects to fan out to multiple consumers.

Applied Patterns

Adopt one canonical analysis graph style so fan-out and fan-in remain readable at scale.

[ENV][CHECK] canonical graph rules

fan-in:
  many monitor ports -> dedicated exports

fan-out:
  one monitor port can feed scoreboard + coverage

ownership:
  monitor publishes immutable/clone-safe object
  consumers never mutate shared payload

instrumentation:
  per-port ingress counters
  per-stage compare counters
  fail bins for triage

function void report_phase(uvm_phase phase);
  `uvm_info("CHK_HEALTH",
    $sformatf("ctrl_hits=%0d data_hits=%0d compares=%0d mismatches=%0d",
      ctrl_hits, data_hits, compare_hits, mismatch_hits),
    UVM_LOW)
endfunction

• Keep checker stages explicit: ingest, align, compare, diagnose.

• Coverage subscribers should mirror checker normalization where relevant.

• Fail early on missing stream ingress in smoke tests.

Integration Drilldown

Run one traffic smoke and one error-injection smoke to prove both success and failure reporting paths.

[CHECK] hub validation routine

smoke A:
  legal traffic
  expect compares > 0
  expect mismatch == 0

smoke B:
  injected protocol mismatch
  expect mismatch > 0
  expect clear diagnostic fields

Key takeaways

• Both pass and fail paths must be exercised for integration confidence.

• A checker that never fails in testing may be disconnected.

Common pitfalls

• Shipping integration changes without negative-path validation.