Handshake Rules

Seven chapters have introduced rules where they were needed. This one gathers them, organised by who is responsible rather than by rule number, and draws the line that matters most in practice.

Which handshake obligations are Wishbone rules, which are good local policy, and how do you tell them apart?

1. Master Initiation

M2 is the one that bites. Qualified by means meaningful for as long as the strobe is asserted, which across a multi-cycle presentation means held still. Chapter 5.5 measured a master violating it for 3 of 4 cycles while reporting success.

M5 exists to make M2 achievable. The specification does not mention latching — it constrains the bus signals and leaves the mechanism alone. Latching is simply the only practical way to satisfy M2 against a client that may change its mind.

Assertion: stb_o |-> cyc_o (M1, spec) · (cyc_o && stb_o && !terminated) |=> $stable({adr_o, we_o, dat_o, sel_o}) (M2, spec) · acc_o |-> !busy_o (M6, policy).

2. Master Holding

H3 and H4 together are the specification's clearest example of "legal but inadvisable". Holding CYC_O breaks no rule and starves a shared bus, and because Wishbone deliberately leaves arbitration policy to the integrator, a recommendation is the strongest instrument available.

H5 is a consequence, not a rule. Nothing forbids negating CYC_O early — but Chapter 5.2 showed what happens: RULE 3.30 stops the slave responding, no termination ever arrives, and if the slave had begun a side effect nobody learns whether it completed.

Assertion: (cyc_o && stb_o && !terminated) |=> cyc_o (H1, spec).

3. Slave Response

S4's two preconditions are routinely misquoted. The slave must keep pace and not use ERR_O/RTY_O. A slave with an error output is covered by S5, not S4.

S8 is the trap of this module. Chapter 5.3 measured a conformant bus — one transfer, one termination, zero trace differences — with four register updates instead of one. No specification rule was broken, because Wishbone does not know what side effects a slave has.

S9 comes from the STB_O signal description — "The SLAVE asserts either the [ACK_I], [ERR_I] or [RTY_I] signals in response to every assertion of the [STB_O] signal" — rather than from a numbered rule. It is why silence is never an acceptable answer.

Assertion: ack_o |-> (cyc_i && stb_i) (S2, spec) · $changed(state) |-> $past(ack_o && we_i) (S8, design obligation, needs white-box access).

4. Termination

T4 is the rule most masters are written without reading, and it is unusual: it constrains a master's design rather than any wire. Chapter 5.4 measured an edge-detecting master counting 1 transfer where a level-sampling one counted 3, from a single rising edge.

T5 is specification; T6 is not. The rule constrains the slave. What the master does with that window is the master's design — which is why Chapter 5.6 labels its capture property a design obligation despite resting on a real rule number.

Assertion: $onehot0({ack_o, err_o, rty_o}) (T1, spec) · !stb_i |-> !ack_o (T2, spec) · (cyc_i && stb_i && ack_o) |-> m_progress (T4, spec, needs white-box access) · $changed(rdat_q) |-> $past(cyc_o && stb_o && ack_i && !we_o) (T6, design obligation).

5. Reset

R3 is why every master in Modules 4 and 5 clears its state flag on reset rather than assigning the outputs directly — the flag drives both qualifiers, so clearing it satisfies R3 through the encoding. A reviewer checking R3 must trace that, which is worth a comment.

R6 is the one exception to slave gating. RST_I is not qualified by anything: Chapter 4.2's slave has its reset outside every qualification term.

6. Data Validity

D1's omission is deliberate and consequential. Because DAT_O is qualified by the strobe alone, a master may legally leave stale write data on the bus during a read — and Chapter 4.6 showed the slave bug that follows: a write path missing WE_I writes a register on every read, with the previous write's value.

D6 is policy, not a rule. D2 requires a slave to qualify its read data; driving zero otherwise is a convention that keeps a merged return path clean, and Chapter 4.7 noted a slave returning the full word is equally conformant.

7. Cycle and Transfer

C5 is worth restating because it is a three-part claim and the specification supplies one part. Chapter 4.9 showed a read-modify-write losing an update with CYC_O held perfectly — because the slave had a second port.

8. The Handshake Invariants

Seven statements. If all hold, the handshake is legal.

I1. STB_O never asserted without CYC_O. (RULE 3.25)

I2. Everything STB_O qualifies is stable from presentation to termination. (RULE 3.60)

I3. A slave acts only on CYC_I & STB_I. (RULES 3.30, 3.35)

I4. At most one termination at a time. (RULE 3.45)

I5. Terminations negate when STB_I negates. (RULE 3.50)

I6. Read data is meaningful only in the termination cycle. (RULE 3.65)

I7. Every qualified transfer eventually receives a termination. (STB_O description)

All seven are checkable from the bus alone. A passive monitor implementing them catches every conformance failure in this module.

And it catches none of these, each measured in an earlier chapter:

That table is the most important thing in this chapter. Conformance is necessary, finite, and reusable. It is not sufficient, and the gap is not an oversight — it is the boundary of what a protocol specification can say.

9. Local Policies Worth Having

None of these is a Wishbone rule. All are worth adopting, and RULE 2.15 requires the ones affecting the interface to be documented.

One outstanding transaction, unless the architecture genuinely needs more.

Explicit acceptance signalling. Chapter 5.5 §9 argued that an inferred boundary is maintained in two places.

Side effects gated on the termination, always — even when it is redundant. Chapter 5.7 §11 showed why: registering an acknowledge for timing reasons turns the redundant term into the only defence, and nobody re-reviews the slave for a timing change.

Distinct ERR and RTY handling. Merging them discards the one bit of information the third wire exists to carry.

Deterministic inactive outputs. Driving '0 when not responding keeps a merged return path clean.

Bounded completion, as a system policy — and the specification says where to put it:

RECOMMENDATION 3.10 — "Design INTERCON modules to prevent deadlock conditions. One solution to this problem is to include a watchdog timer function that monitors the MASTER's [STB_O] signal."

Note where it goes: the interconnect, not the master. A master cannot legally abandon a transfer — that is H5 — so a watchdog in the master would have nothing legal to do. A watchdog in the interconnect can terminate the transfer, turning a silent hang into a reported error with an address attached.

Registered outputs on the qualifiers, per RECOMMENDATION 3.15: no intermediate logic between a flop and STB_O/CYC_O.

10. Debug Checklist

Ordered so each step eliminates the largest number of candidates.

Symptom: master hangs, no termination.

1. CYC_O at the master. Negated while STB_O is asserted? → RULE 3.25 duration violation. Check this first — the slave is innocent and its waveform looks identical to three other causes.
2. CYC_I/STB_I at the intended slave. Absent? → decode or forward routing.
3. ACK_O at that slave. Absent? → the slave has an unterminated path, usually an unhandled default.
4. ACK_I at the master. Present at the slave, absent here? → return path, or the master does not implement the termination the slave produced. OBSERVATION 3.35 names that case.
5. Is ACK_I high while the master sits still? → not a hang. RULE 3.55 violation; the master is edge-detecting.

Symptom: wrong read data.

1. Slave's DAT_O in the acknowledged cycle correct? No → RULE 3.65 violation in the slave.
2. Correct there, wrong at the master? → capture edge. Every read returning the previous value is diagnostic.
3. All reads return zero, address-independent? → capture one cycle late in a quiet system (5.6 measured exactly this).
4. Data register changed on an errored read? → capture gated on terminated rather than ack_i.

Symptom: side effect happens too many times.

1. Count side effects against wait length, not transfer count. Equal to the presented duration → gated on presented, not accepted.
2. Did someone recently register the acknowledge for timing? → that change made a redundant term load-bearing.
3. Idempotent state only? → look at counters and FIFOs; the bug hides in registers.

Symptom: works alone, fails under arbitration.

1. cyc_i at the slave when it misbehaves. Low while stb_i high → RULE 3.30 violation in the slave.
2. Competing access visible on the bus? Yes → arbiter granted during an open cycle. No → back-door port.

Symptom: closes function, fails timing.

1. Read the critical path, not the slack. Master flop → decode → slave → merge → master flop is the OBSERVATION 3.50 loopback.
2. Register the termination, or cut the loop once with a hierarchical bridge. Do not register every slave reflexively.

11. Interview Reasoning

12. Understanding Check

13. What's Next

Module 5 is complete. The handshake is no longer three signal definitions but a timed contract: a cycle that frames, a strobe that presents and persists, a termination that answers once and is sampled as a level — with a clear line between what Wishbone requires and what a design decides.

Every transfer so far has been a vehicle for the handshake. The next module stops using reads as examples and makes one its subject — the address phase, how a slave produces returned data, when it generates its acknowledge, and how wait states appear in a real read waveform.

What happens, end to end, in a single Wishbone read cycle?

Module 6 — Read Transactions answers it, beginning with Read Cycle Flow. The full path is on the Wishbone curriculum index.