RTL Checklist

A checklist that reads "[ ] ACK works" has not reviewed anything. It has recorded that somebody thought about ACK.

A CHECKBOX WITHOUT EVIDENCE IS NOT A REVIEW.

This module converts the whole curriculum into a review system built on one shape:

REQUIREMENT  ->  INVARIANT  ->  EVIDENCE  ->  DECISION

1. What A Review Item Owes You

Every substantial item in these six chapters answers eight questions. Here is the schema, and one item filled in:

The classification field is not decoration. Six values are in use across this module, and mixing them up is how a reviewer loses an argument they were right about:

SPEC REQUIRED · SYSTEM INVARIANT · IMPLEMENTATION CHOICE · LOCAL POLICY · VERIFICATION QUALITY · REVIEW HYGIENE

2. Three Levels, And Stopping At One Is The Common Failure

Most reviews that go wrong went wrong at Level 3. The architecture was fine, the implementation was plausible, and nobody asked what would have been different if it were broken.

3. Dispositions

Use seven, and never collapse the fourth into the first:

PASS · FAIL · NOT APPLICABLE · NOT VERIFIED · OPEN RISK · LOCAL POLICY — ACCEPTED · LOCAL POLICY — REQUIRES DECISION

NOT VERIFIED is not PASS. It is the honest record that nobody looked. Writing PASS instead converts an open question into a closed one without doing any work, and the cost lands on whoever integrates the block.

4. The Clean Baseline

Nothing below means anything without a reference. Three operations against a three-wait slave, reviewed:

=== SIM A - CLEAN RTL REVIEW ===

  three operations against a three-wait slave

  ops retired                 3
  phases opened at the pins   3
  terminations at the pins    3
  acknowledgements            3
  wait clocks                 9
  commits                     2
  write-to-increment register 1
  unknown pins                0
  phase still open at the end 0

  review conditions failing   0
  unknown review conditions   0
  counter saturated           0

Eight review conditions, evaluated by a counter that can represent the number it claims to count — Chapter 30.2 explains why that sentence needed writing. Two commits for two writes. One increment for one write to the increment register. Nine wait clocks, which proves the waits actually happened rather than being configured and ignored.

5. RTL-03 — Request Stability

Review question. Do the qualified signals hold still for the whole open phase, at the boundary where it matters?

Classification. SPEC REQUIRED.

RULE 3.60 — MASTER MUST qualify with STB_O: ADR_O, DAT_O(), SEL_O(), WE_O, TAGN_O.

The trap. That rule binds the master. It says nothing about what an interconnect does to the request on the way down. A checker at the master port can report a clean run while the slave is receiving a different request every clock.

=== SIM B - REQUEST-STABILITY FAILURE ===

  waits  P0 context moves  P2 context moves  scoreboard  first bad boundary
  0                    0                 0           0    none
  3                    0                 3           0  P1->P2

Two findings, and the second is the more uncomfortable.

At zero wait states the defect does not exist. Not hidden — a phase one clock long has no interior for anything to move inside. A review that ran only the fast configuration has proved nothing about this item, and its correct disposition is NOT VERIFIED.

And the scoreboard reports zero at both latencies:

  AND NOTE THE SCOREBOARD COLUMN: 0.
  The address moved on three transfers and the data still
  came back correct, because each disturbed address landed
  on an equivalent read-write register. The functional
  checker is blind here and the protocol checker at P2 is
  not. A review that owns only one of them owns neither.

PASS criterion: zero context moves at every boundary the request crosses, at non-zero latency. FAIL: any context move at any boundary, regardless of what the scoreboard says.

6. RTL-07 — Exactly-Once Side Effects

Review question. Does an accepted write commit once, and only once?

Classification. SYSTEM INVARIANT. B3 has nothing to say about a slave's internal commit policy; it defines the termination, not what the slave does about it.

Inspection point. One expression:

  // THE COMMIT QUALIFIER. This one line is the difference between a
  // correct slave and Lab B's broken one.
  logic commit;
  assign commit = WRITE_ON_STB ? (present && we_i) : (ack_o && we_i);

EXECUTED RTL — the WRITE_ON_STB branch is an intentional defect, exercised in SIM C.

ack_o && we_i commits on the accepted clock. present && we_i commits on every presented clock. At zero wait states those are the same clock, which is why the wrong one survives review after review.

=== SIM C - DUPLICATE SIDE EFFECT ===

  rig                      presented  terminated  commits  increment reg
  correct,      3 waits           12           3        2              1
  WRITE_ON_STB, 0 waits            3           3        2              1
  WRITE_ON_STB, 3 waits           12           3        8              4

Read the terminated column: 3 in every row. A termination census cannot see this defect at all. Read the middle row: the broken design at zero waits is byte-identical to the correct one.

And note what makes it visible. The evidence register is write-to-increment, because writing the same value four times to ordinary storage leaves the same value. The review item is not "count the commits" — it is "count the commits against a location where repetition changes the answer."

Evidence required: a commit census, at non-zero latency, against a non-idempotent target. PASS: commits == accepted writes. FAIL: anything else.

7. RTL-12 — Termination Provenance

Review question. Does each termination correspond to exactly one live presented request, delivered to its owner?

Classification. SPEC REQUIRED for the shape, SYSTEM INVARIANT for the destination.

RULE 3.35 — ACK_O, ERR_O, RTY_O must be generated in response to the logical AND of CYC_I and STB_I.

RULE 3.35 governs whether a termination answers a request. Nothing in B3 governs whether it answers yours — because B3's model is point to point and has exactly one master per interface. Destination is your invariant, and Chapter 30.4 is where it gets reviewed.

8. The Review Escape

This is the chapter's thesis, made executable. One routing defect, run past every layer a shallow review trusts:

=== SIM L - REVIEW ESCAPE ===

  the same four register operations, one routing defect

  review layer                    control  defective  catches it?
  elaboration                       clean      clean  no
  protocol checks P0 / P2           0/0        0/0     no
  immediate assertions SPEC             0          0   no
  monitor transactions                  4          4   no
  scoreboard mismatches                 0          1  partly
  register-slave phases seen            7          0  YES

Four transfers acknowledged. Zero protocol violations at either boundary. Zero specification assertion failures. The same transaction count as the control. And the register bank was never strobed once.

Only the last row catches it, and that row is a decode census — a number no protocol layer computes, because no Wishbone rule encodes your address map.

The scoreboard says partly, and the qualifier matters: it caught one of four wrong transfers, the write to a read-only offset that the memory happily acknowledged. The other three wrote and read the same wrong location, and self-consistency is indistinguishable from correctness.

9. False Confidence

Every chapter in this module exposes one. Here are the two that belong to RTL:

"It compiles." Proves: the syntax is legal and the module elaborates. Does not prove: anything about behaviour. Both defects in SIM B and SIM C elaborate cleanly, with -Wall, with no warnings. Missing evidence: a simulation at non-zero latency with a census attached.

"The basic test passed." Proves: one stimulus produced one expected result. Does not prove: that the stimulus could have produced a different result if the design were wrong. SIM C's zero-wait row is a passing basic test on a design that commits four times per write. Missing evidence: the same test at a second latency, and a negative control.

10. The RTL Checklist

Eighteen items. Classification in brackets; NV marks the ones a fast review most often leaves NOT VERIFIED.

RTL-18 is the one that makes the other seventeen mean anything.

11. What To Carry Forward

• An item without a PASS criterion is a topic, not a review item.
• NOT VERIFIED is a disposition. Use it; it is the only honest record of what was not looked at.
• Run every functional item at two latencies. Two of this chapter's three defects cannot exist at zero.
• Count side effects against non-idempotent targets, or the count proves nothing.
• A termination census cannot see a commit defect, and a protocol checker cannot see a routing defect.
• "It compiles" and "the basic test passed" are both true of designs in this chapter that are badly broken.

Chapter 30.2 asks the harder question: could the verification environment have detected any of this?