Protocol Monitoring

Monitors · Module 13 · Page 13.3

The Engineering Problem

Reconstruction (Module 13.2) assembles what happened on the interface into a transaction — the data the scoreboard will check for correctness. But there is a second, orthogonal question the scoreboard cannot answer: was what happened legal? An interface is governed by a protocol contract — handshake rules (valid must stay asserted until ready, signals stable while valid), ordering rules (every response matches a prior request, IDs return in legal order), timing rules (a response within N cycles, no control signal toggling mid-transaction). A DUT can produce perfectly correct data while violating the contract — and in your lenient testbench it passes, then fails in silicon the moment it's connected to a strict partner that drops the malformed transaction. The scoreboard checks the data; nothing checks the protocol — unless the monitor does. The problem this chapter solves is interface legality: watching the bus for contract violations and flagging each one at the cycle it occurs.

Protocol monitoring is the monitor acting as a protocol checker — continuously verifying that the interface behavior obeys the protocol contract, and flagging each violation at the exact cycle it happens. It is distinct from the scoreboard's job: the scoreboard checks data correctness (did the right value come out), protocol monitoring checks interface legality (did the signals obey the rules). These are orthogonal — a transaction can be functionally correct but protocol-illegal, or protocol-legal but functionally wrong — so you need both. And protocol violations must be flagged immediately, at the source, because an unchecked violation either escapes to silicon (passing your lenient sim) or propagates downstream into a confusing data mismatch far from its cause. This chapter is protocol monitoring: the legality-vs-correctness distinction, the three rule categories, why flagging at the source matters, and the contract violation that passes in sim but fails in silicon.

How does a monitor check the legality of interface behavior against the protocol contract — handshake, ordering, and timing rules — flagging each violation at the cycle it occurs, and why is this orthogonal to the scoreboard's data-correctness check?

Motivation — why data correctness isn't enough

It's tempting to think "if the data is right, the design is right." Protocol monitoring exists because legality is a separate property the scoreboard can't see:

• Correct data can ride an illegal protocol. A DUT can deliver the right value while violating the handshake (deasserting valid before ready, changing a payload while valid). The data is fine; the protocol is broken — and the scoreboard, checking data, sees nothing wrong.
• A lenient testbench hides contract violations. Your driver/monitor may tolerate a sloppy handshake (still capturing the data), so the test passes. A strict real-world partner (or the silicon's neighbor block) won't tolerate it — it drops the transaction, and the bug appears for the first time in silicon. Protocol monitoring catches it in sim.
• Protocol violations are local; their symptoms are remote. A violation happens at a specific cycle at the interface. Left unflagged, it may corrupt downstream state and surface thousands of cycles later as a data mismatch with no obvious link to the cause. Flagging at the source turns a multi-day debug into an instant one.
• The contract is the integration boundary. Blocks are integrated by their interfaces. A block that violates its interface contract is unintegrable — it breaks whoever connects to it. Protocol monitoring verifies the block is a good citizen at its boundary, independent of internal function.
• Some violations never corrupt data but are still bugs. A response that arrives one cycle too late, an X on an unused-but-contractually-stable signal — these may not change this test's result, but they're contract breaches that a strict checker (or a future configuration) will punish.

The motivation, in one line: data correctness and protocol legality are orthogonal properties — a DUT can be right on data and wrong on protocol — so a testbench that checks only the scoreboard is blind to contract violations that pass in lenient sim and fail in strict silicon; protocol monitoring closes that gap by checking legality at the interface and flagging violations at the source.

Mental Model

Hold protocol monitoring as the referee who enforces the rules, separate from the scorekeeper who tracks the points:

The scoreboard is the scorekeeper — it tracks whether the right result happened. The monitor's protocol checker is the referee — it watches every play for an illegal move and blows the whistle the instant one occurs, regardless of the score. Picture a sports match. The scorekeeper (the scoreboard) cares about one thing: the final result — did the right team score the right points. The referee (protocol monitoring) cares about something entirely different: did every play obey the rules — no offside, no foul, no illegal handoff. These are orthogonal. A team can score a perfectly good goal (correct result) via an illegal move (a foul in the buildup) — the scorekeeper would happily record the goal, but the referee must call the foul, because the play was illegal even though the outcome looked fine. And a foul might not change this play's score at all — yet it's still illegal, and still called. Crucially, the referee blows the whistle immediately, at the spot of the foul — not at the end of the match, when untangling "which earlier play caused this" would be hopeless. The referee localizes the infraction to the exact moment and place it happened. The two roles are deliberately separate: the scorekeeper can't see fouls (it only watches the scoreboard), and the referee doesn't track points (it only watches for rule-breaking) — you need both officials for a valid game.

So protocol monitoring is the referee, separate from the scorekeeper: it checks legality of play (the protocol contract) independent of the result (data correctness), and blows the whistle at the instant and spot of each violation. The scoreboard can't see protocol fouls — it only watches the outcome; protocol monitoring only watches for rule-breaking, at the interface, as it happens. A testbench with only a scoreboard is a game with a scorekeeper but no referee — fouls go uncalled until they blow up the result.

Visual Explanation — two orthogonal checks on the same interface

The defining picture is two independent checkers watching the same interface for different properties: protocol monitoring for legality, the scoreboard for correctness.

The figure shows the orthogonality that is the chapter's core. The monitor observes the interface (Module 13.1) and feeds two independent checkers. Protocol monitoring examines the interface behavior — the sequence and timing of the signals — and checks it against the contract: does the handshake obey the rules, do responses match requests in legal order, does the timing stay within bounds? When the behavior is illegal, it flags a contract violation at the cycle it occurs. The scoreboard examines the reconstructed transaction (Module 13.2) — the data — and checks it against expected: is the value right? When it's wrong, it flags a data mismatch. The crucial reading is that these checkers see different properties of the same interface: protocol monitoring sees the form (is the behavior well-formed per the contract), the scoreboard sees the content (is the data correct). A transaction can pass one and fail the other: correct data over an illegal handshake sails through the scoreboard (the value is right) but trips protocol monitoring (the handshake was illegal); conversely, a protocol-legal transaction with wrong data passes protocol monitoring but fails the scoreboard. Neither checker subsumes the other — they are orthogonal axes, and a complete testbench needs both. The diagram is the argument for protocol monitoring's existence: without it, the testbench has one eye closed — it sees wrong data but is blind to illegal behavior, exactly the class of bug that passes lenient sim and fails strict silicon.

RTL / Simulation Perspective — the three rule categories

Protocol rules fall into three families — handshake, ordering, and timing — each expressible as a check (often a SystemVerilog Assertion) that fires at the cycle the rule is broken. The code shows representative checks.

// === HANDSHAKE: once asserted, valid must hold until ready, and payload must be stable ===
property valid_holds_until_ready;
  @(posedge clk) disable iff (!rst_n)
  (valid && !ready) |=> valid;                 // valid must NOT drop before the handshake
endproperty
assert property (valid_holds_until_ready) else `uvm_error("PROTO", "valid dropped before ready")
 
property payload_stable_while_valid;
  @(posedge clk) (valid && !ready) |=> $stable(data);  // data must not change mid-handshake
endproperty
assert property (payload_stable_while_valid) else `uvm_error("PROTO", "payload changed while valid")
 
// === ORDERING: every response must match an outstanding request (no orphan responses) ===
function void check_response(bit [3:0] id);
  if (!outstanding.exists(id)) `uvm_error("PROTO", $sformatf("orphan response, id=%0d", id))
  else outstanding.delete(id);
endfunction
 
// === TIMING: a request must get a response within MAX_LATENCY cycles ===
property response_within_bound;
  @(posedge clk) req |-> ##[1:MAX_LATENCY] resp;   // no unbounded stall
endproperty
assert property (response_within_bound) else `uvm_error("PROTO", "response exceeded max latency")

The code shows the three families of protocol rule. Handshake rules govern the valid/ready contract: valid_holds_until_ready asserts that once valid is raised it stays until ready (a DUT that drops valid early breaks the handshake), and payload_stable_while_valid asserts the data doesn't change mid-handshake (a moving payload corrupts whoever samples it). Ordering rules govern request/response correspondence: check_response verifies every response matches an outstanding request — an orphan response (no matching request) is a protocol violation (and a sign of internal corruption). Timing rules govern bounded latency: response_within_bound asserts a request gets a response within MAX_LATENCY (an unbounded stall is a contract breach, even if the data would eventually be correct). The common structure is the point: each check is a property of the interface behavior that fires uvm_error at the cycle the rule is broken — immediately, at the source. Whether written as SVA (the assert property forms) or as procedural checks in the monitor's run_phase (the check_response function), the role is identical: watch the contract, flag the breach where it happens. The shape to carry: protocol monitoring is a set of contract checks — handshake, ordering, timing — each local to the interface and firing at the violating cycle, independent of whether the data is ultimately correct.

Verification Perspective — flagging at the source

The value of protocol monitoring is not just that it catches violations — it's that it catches them at the source, before they turn into remote, confusing symptoms. Seeing the propagation is seeing why immediacy matters.

The figure contrasts the two fates of a protocol violation. A violation happens at a specific cycle, at the interface — say, valid drops before ready at cycle N. With protocol monitoring, it's flagged at the source: the check fires at cycle N, naming the exact signal and cycle — an instant, localized diagnosis ("valid dropped before ready at cycle N"), and the fix is usually one line in the DUT. Without protocol monitoring, the violation goes unflagged and propagates: the malformed handshake causes a transaction to be dropped or mis-captured, which corrupts downstream state, which eventually surfaces — thousands of cycles later — as a remote data mismatch the scoreboard reports with no obvious link to the original cause. Now the debug is a multi-day archaeology: working backwards from a data mismatch at cycle 5000 to a handshake glitch at cycle 100, through all the intervening state. The verification insight is that the same bug costs radically different amounts to find depending on where it's caught: at the source it's trivial; from its remote symptom it's brutal. This is why protocol monitoring flags immediately — the whole point is to catch the violation at the cycle and signal it occurs, before it can propagate into something unrecognizable. A protocol checker is, in effect, a fail-fast mechanism for the interface contract: it stops the lie at the source rather than letting it travel and mutate. The scoreboard can only see the remote symptom (it checks data, downstream); protocol monitoring sees the root cause (it checks behavior, at the interface) — which is exactly why the two together localize bugs the scoreboard alone would only discover, baffled, much later.

Runtime / Execution Flow — checking the contract every cycle

At run time, protocol monitoring is a continuous, per-cycle evaluation: every clock, observe the interface, evaluate the contract rules, and flag any that are broken — concurrently with reconstruction. The flow shows the cycle-by-cycle check.

The flow is protocol monitoring as a perpetual contract evaluation. Observe (step 1): each clock, sample the current interface state — read-only and passive, the same discipline as all monitoring (Module 13.1). Evaluate (step 2): check the contract rules — handshake (is valid/ready legal this cycle), ordering (does this response match an outstanding request), timing (has any pending request exceeded its latency bound) — against the current state and recent history (some rules span cycles, e.g., "valid held since last cycle"). Flag (step 3): if any rule is broken, raise an error immediately, naming the exact cycle and signal — at the source, this cycle, not later. Advance (step 4): move to the next cycle and repeat — continuously, forever, concurrently with reconstruction. The runtime insight is that protocol monitoring is always on and cycle-granular: it doesn't wait for a transaction to complete (the way reconstruction does) — it evaluates the contract every single clock, because a violation can occur at any cycle, even mid-transaction, and must be caught there. It runs alongside reconstruction on the same observed interface: reconstruction asks "what transaction is forming?" while protocol monitoring asks "is this cycle's behavior legal?" — two concurrent questions about every cycle. This is why protocol checks are often written as SVA (assert property), which the simulator evaluates every cycle automatically, or as concurrent procedural checks in the monitor — both give the always-on, per-cycle, flag-at-the-source behavior the contract demands. The flow is the contract being continuously enforced: every cycle observed, every rule evaluated, every breach flagged the instant it happens.

Waveform Perspective — a handshake violation caught at its cycle

A protocol violation is visible on a timeline: the moment the signals break the contract, the check fires — at that cycle. The waveform shows a valid-dropped-before-ready handshake violation flagged at the source.

The waveform shows protocol monitoring firing at the violating cycle. The contract for this handshake: once valid asserts, it must hold until ready completes the handshake. At cycle 1, valid asserts with data=A7 — the handshake begins — but ready has not yet come. At cycle 2, valid is still high, ready still low — legal so far (valid is holding, as required). Then at cycle 3, valid drops — before ready ever asserted — breaking the contract: the handshake was abandoned mid-flight. The protocol check fires exactly there: proto_error pulses at cycle 3, naming the violating signal (valid dropped early) and the exact cycle. The crucial reading is the alignment: the error pulse sits precisely at the cycle the contract was broken — not earlier, not later — at the source. And note what the scoreboard would see: the data was A7 — possibly the correct value — so a data check would find nothing wrong; only protocol monitoring catches this handshake breach. This is the orthogonality made visual: the data axis is clean, the protocol axis is violated, and only the protocol checker sees it. Reading a waveform for protocol legality — does each handshake complete legally? does valid hold until ready? do the protocol-error signals stay quiet? — is how you verify the interface obeys its contract, independent of whether the data is right. The picture to carry: a protocol violation is a contract breach visible at a specific cycle, and protocol monitoring flags it there — at the source, where it's cheap to diagnose, before it can escape to silicon or propagate into a remote mismatch.

DebugLab — the bug that passed in sim and failed in silicon

✗ testbench checked DATA only (scoreboard), not PROTOCOL legality:
  - DUT deasserts valid before ready  →  HANDSHAKE VIOLATION (contract breach)
  - lenient TB driver tolerates it, still captures data  →  scoreboard sees CORRECT data → PASS
  - no protocol checker → the violation is NEVER flagged → escapes to silicon
  - strict silicon neighbor enforces the contract → DROPS the transaction → data loss in lab
 
✓ add PROTOCOL MONITORING — a handshake check fires at the violating cycle:
  assert property (@(posedge clk) (valid && !ready) |=> valid)
    else `uvm_error("PROTO", "valid dropped before ready");
  - now the SAME stimulus that passed before FAILS in sim, at the exact cycle valid dropped
  - bug caught pre-silicon, at the source — one-line DUT fix, no tape-out escape

Common Mistakes

• Relying on the scoreboard for everything. The scoreboard checks data, not protocol legality; correct data can ride an illegal handshake, so a passing scoreboard doesn't mean a legal protocol.
• A testbench more lenient than silicon. A driver/monitor that tolerates contract violations hides them; the protocol checker must be as strict as the strictest real partner.
• Deferring violation reports. A protocol violation flagged downstream (as a data mismatch) is far harder to debug; flag at the cycle and signal it occurs.
• Checking only handshake, ignoring ordering and timing. All three rule families are part of the contract; an orphan response or an unbounded stall is as illegal as a dropped valid.
• Not evaluating every cycle. Violations can occur mid-transaction; protocol checks must run continuously, not only at transaction boundaries.
• No protocol checks for unused-but-contractual signals. A signal the contract requires stable must be checked even if this test ignores its value.

Senior Design Review Notes

Interview Insights

Exercises

1. Separate the axes. Give an example of a transaction that passes the scoreboard but fails protocol monitoring, and one that does the reverse.
2. Write a handshake check. Express "valid must hold until ready" as an assertion and explain at which cycle it fires for a violation.
3. Trace the escape. Describe how a handshake violation can pass a lenient simulation and fail in silicon, and what check would have caught it.
4. Categorize the rules. Classify each as handshake, ordering, or timing: orphan response; payload changed while valid; response exceeded max latency.

Summary

• Protocol monitoring is the monitor acting as a protocol checker — verifying that interface behavior obeys the protocol contract (handshake, ordering, timing rules) and flagging each violation at the cycle it occurs.
• It is orthogonal to the scoreboard: the scoreboard checks data correctness (right value), protocol monitoring checks interface legality (legal signaling) — a transaction can be correct on data but illegal on protocol, so a testbench needs both.
• The three rule families: handshake (valid holds until ready, payload stable while valid), ordering (every response matches an outstanding request), timing (bounded latency, no forbidden toggles) — each a check that fires at the violating cycle.
• Violations must be flagged at the source: an unchecked violation either escapes to silicon (passing lenient sim, failing a strict partner) or propagates into a remote data mismatch far from its cause — the same bug is trivial at the source and brutal from its symptom.
• The durable rule of thumb: check protocol legality alongside data correctness — add handshake, ordering, and timing checks that fire at the violating cycle, as strict as the strictest partner — because the scoreboard is blind to contract violations, and an unchecked one passes your lenient sim only to fail in strict silicon.

Next — Monitor Analysis Ports: the monitor reconstructs transactions and checks the protocol — now it must deliver what it observed to the rest of the testbench. The next chapter covers analysis ports: the broadcast mechanism by which one monitor feeds its observed transactions to many independent subscribers — scoreboard, coverage, loggers — without coupling to any of them.