Sampling Discipline

Sample the right stream at the right time

Functional coverage must reflect DUT-visible behavior . The monitor samples pins after the DUT has processed the transaction. The driver knows what it intended to send — which may differ if the DUT transforms, drops, or errors on the transaction.

Legend: [COVER] [UVM]

  MONITOR vs DRIVER SAMPLING

  DRIVER (wrong for functional coverage)
  ──────────────────────────────────────
  seq ──► driver ──► item: { write=1, addr=0x100, data=0xFF }
                         │
                         ▼ (DUT may modify)
                    DUT transforms addr, drops write, sets SLVERR

  MONITOR (correct for functional coverage) [COVER]
  ───────────────────────────────────────────────────
  pins ──► monitor ──► item: { write=1, addr=0x104, data=0xFF, slverr=1 }
                              ↑ actual DUT behavior ↑

Sampling rules

Four discipline rules

• Monitor stream — DUT-visible behavior (required for functional coverage).

• Driver stream — stimulus intent only (wrong for functional coverage).

• Once per complete transaction — sample on RESPONSE, not per beat or per cycle.

• Gate in_reset — invalid states during reset pollute closure and inflate bin hits.

class bus_cov extends uvm_subscriber #(bus_txn);
  bit in_reset;

  // Called by reset sequence or env at reset deassert
  function void set_reset(bit r);
    in_reset = r;
  endfunction

  function void write(bus_txn t);
    if (in_reset) return;              // rule 4: skip reset phase
    if (t.kind != RESPONSE) return;     // rule 3: complete txn only
    cg.sample(t);
  endfunction
endclass

// In env or reset sequence:
// cov.set_reset(1) at reset assert
// cov.set_reset(0) after reset deassert + N idle cycles

Monitor vs driver — side by side

Scenario: DUT remaps addr 0x100 → 0x104, sets SLVERR

  Driver item:   { addr=0x100, slverr=0 }  → cp_addr hits bin "low"
  Monitor item:  { addr=0x104, slverr=1 }  → cp_addr hits bin "high", cp_resp hits "error"

  Driver sampling: misses addr remap bug, misses error response
  Monitor sampling: catches both — correct functional coverage

Key takeaways

• Functional coverage = observed DUT behavior from monitor.

• Sample once per complete transaction on RESPONSE kind.

• Gate in_reset to prevent reset-phase pollution of closure metrics.

Common pitfalls

• Sampling during reset — false closure progress on invalid states.

• Driver sampling — misses DUT-transformed behavior and error responses.

• Per-beat sampling on burst — inflates bin hit counts without new scenarios.