Wait-State Bugs

Module 9 explained what wait states are. This chapter is about a specific and slightly unnerving fact:

A whole class of defect does not exist at zero latency. Not "is hard to see" — does not exist.

A phase with no wait states has no inside. Nothing can move within it, nothing can happen twice inside it, and nothing can go stale during it. Add one wait clock and the phase acquires an interior, and everything that was structurally impossible becomes merely rare.

1. The Question Is Not "Why Is This Slow"

A slow transfer is the symptom people arrive with, and it is almost never the defect. B3 bounds no latency; a slave that takes forty clocks is conformant. The useful question is different:

What was supposed to stay still while the transaction was waiting, and did it?

RULE 3.60 answers half of that. The master qualifies ADR_O, WE_O, SEL_O() and — on a write — DAT_O() with STB_O, and must hold every one of them steady for as long as the phase is open. A master that moves any of them has changed the question after asking it.

The other half is the slave's, and B3 says nothing about it: a slave must not perform its side effect more than once, must not lose its own pending state, and must not answer from data it captured at the wrong moment. Those are local policy, which is exactly why no protocol checker in this module will catch any of them.

2. The Wait-State Fingerprint

Five numbers per transfer are enough to characterise almost every wait-state defect:

Three of those five are meaningless at zero latency, because the phase is one clock long.

3. SIM F — The Differential Experiment

Run the same logical transaction at three latencies. On a correct design the architectural result must be identical and only the clock count may differ.

=== SIM F - THE WAIT-STATE DIFFERENTIAL ===

  CORRECT SYSTEM, THREE LATENCIES
  op  address  lat0 term data        lat1 term data        lat3 term data
   0  0x0000  ACK 0xc0de0001  ACK 0xc0de0001  ACK 0xc0de0001
   1  0x0000  ACK 0xc0de0001  ACK 0xc0de0001  ACK 0xc0de0001
   2  0x0002  ACK 0xc0de0002  ACK 0xc0de0002  ACK 0xc0de0002
   3  0x0002  ACK 0xc0de0002  ACK 0xc0de0002  ACK 0xc0de0002
   4  0x0003  ACK 0x00000000  ACK 0x00000000  ACK 0x00000000

  architectural differences across latency   0
  clocks presented at P0     lat0 5   lat1 10   lat3 20
  register writes committed  lat0 2   lat1 2   lat3 2
  scoreboard mismatches      lat0 0   lat1 0   lat3 0
  ONLY TIMING DIFFERS. That is what correct looks like.

Five operations, three latencies, fifteen transfers. Target identical, termination identical, committed data identical, side-effect count identical. Clocks presented: 5, 10, 20 — a 4× cost difference with a zero architectural difference.

That row is the specification of "correct" for this experiment. Everything below is measured against it.

4. The Defect That Passes At Zero

Now arm a fabric that perturbs the request it has already forwarded, and run the identical three-latency sweep:

  MOVING_REQUEST, THE SAME THREE LATENCIES
  latency  scoreboard  data  term  P0 violations  P2 violations  P2 ctx moved
  0                 0     0     0              0              0             0
  1                 3     1     2              0              5             5
  3                 3     1     2              0              5             5

  AT LATENCY 0 THE BROKEN SYSTEM IS INDISTINGUISHABLE FROM
  THE CORRECT ONE. The phase never stays open long enough
  for anything to move inside it.

At latency 0 the defective rig is perfect. Zero mismatches, zero violations, five clean transfers. A regression suite built on a zero-wait model signs this design off.

At latency 1 it produces three scoreboard mismatches and five protocol violations. The defect did not appear; the phase acquired an interior and the defect had somewhere to live. Note that latency 3 produces exactly the same counts as latency 1 — one wait clock is enough. More waiting does not find more bugs of this kind; it only makes them slower to reproduce.

Here is what the transfers became:

  op  address  correct term data        broken term data
   0  0x0000  ACK      0xc0de0001  ACK     0xc0de0001
   1  0x0000  ACK      0xc0de0001  ACK     0xc0de0001
   2  0x0002  ACK      0xc0de0002  ERR     0xc0de0002
   3  0x0002  ACK      0xc0de0002  ACK     0x00000000
   4  0x0003  ACK      0x00000000  ERR     0x00000000

The first two transfers are correct. The address moved from 0x0000 to 0x0004 inside the phase, so the write landed at offset 4 and the read that followed was moved to offset 4 as well — a self-consistent lie. Only when the disturbed address lands on a different kind of register — the read-only one at offset 6, the reserved one at offset 7 — does the system report anything.

That is not a coincidence in the stimulus. It is the reason the program was written this way:

  // MOVING_REQUEST flips ADR bit 2 once a phase has been open for a
  // clock. These five operations are chosen so the disturbed address
  // lands on a different KIND of register each time - a plain one, the
  // read-only one, a reserved one - because a defect that only ever
  // moves data between two equivalent locations is invisible.

5. Two Checkers, One Property, Different Answers

The defect breaks RULE 3.60 — the request did not hold still. Ask both checkers:

  The master holds ADR, SEL and WE still for the whole open
  phase - RULE 3.60 - and the checker at P0 agrees: 0
  The checker at P2 sees the same property broken 5 times.

Zero at the master port. Five at the slave boundary. Same rule, same run, same clock.

The master is not lying. It really is holding everything still, exactly as the specification obliges it to. The corruption happens after the master port and before the slave, and a checker at the master port cannot see a region of the design it is upstream of.

Chapter 26.2 measured this effect — 0 failures at one boundary, 16 at another. Here it is structural rather than incidental: the observation point is part of the property. An assertion is a claim about signals at a place, and moving the place changes the claim.

Seven signals. Two of them are the same address on two different wires, and the whole chapter is in the gap between them.

6. SIM G — The Side Effect That Happens Four Times

The second wait-state defect has nothing to do with the request moving. The register bank has a FIFO at offset 5; reading it pops. A slave that acts on the presented clock rather than the accepted one performs its side effect once per clock it was presented.

=== SIM G - THE SIDE EFFECT THAT HAPPENS FOUR TIMES ===

  rig                         presented  terminated  pops  underflows
  correct,        3 waits            16           4     4           0
  SIDE_ON_STB,    3 waits            16           4     4          12
  SIDE_ON_STB,    0 waits             4           4     4           0

  architectural transfers   correct 4   broken 4
  pop ATTEMPTS  (pops+underflows)
                            correct 4   broken 16
  side effects per transfer correct 1   broken 4

Every rig answered four transfers. The termination census is identical across all three. What differs is the number of times the queue was disturbed, and only a side-effect counter can see it.

Read the two columns separately, because the underflow number is easy to misread:

  READ THE TWO COLUMNS SEPARATELY. The broken rig popped
  four real entries and then underflowed twelve times, and
  those twelve are not a second bug - they are the first
  one continuing after the queue ran out. THE FIRST READ
  ALONE CONSUMED ALL FOUR ENTRIES, because it was presented
  for four clocks. Reads two, three and four found an empty
  queue.

And the third row of the table is the one that closes the argument. The same defect at zero waits pops exactly four times and underflows never. At zero latency the presented clock and the accepted clock are the same clock, and the bug is not merely hidden — it is not expressible.

  protocol violations   correct P0 0 P2 0   broken P0 0 P2 0
  Neither rig violates a Wishbone rule. RULE 3.60 governs
  what the MASTER holds still, not how many times a slave
  acts on what it is holding.

7. Activation, Measured

The module carries five executable immediate assertions. A5 is RULE 3.60 checked at the slave boundary:

  rig            A1   A2   A3   A4   A5   SPEC  LOCAL
  correct lat3    0    0    0    0    0     0      0
  broken  lat0    0    0    0    0    0     0      0
  broken  lat3    0    0    0    0    5     5      0

A5 fires five times with wait states and zero times without, on the same design. Chapter 26.2's vacuity lesson arrives here as an operational fact: a clean assertion report from the middle row is worthless, and nothing in that report says so. The assertion did not become true; the stimulus became capable of exercising it.

This is why a wait-state sweep belongs in a regression suite and not in a "performance" suite. It is not measuring speed. It is arming checks that cannot fire otherwise.

8. The Debug Record

The zero-latency behaviour row is the chapter.

9. What To Carry Forward

• Long latency is not the bug. The bug is something that should have stayed invariant and did not.
• Run every functional test at zero, one and several wait states. The architectural result must be identical; if it is not, the difference is the finding.
• One wait clock is enough to arm the class. Three found nothing that one did not.
• A design that passes only at zero latency has not been tested; it has been avoided.
• The observation point is part of the property. RULE 3.60 reported 0 and 5 on the same clock at two boundaries, and both numbers were right.
• Count side effects, not terminations. Four transfers and sixteen pops is a defect no termination census contains.

Chapter 27.4 adds a second master, and with it the question of who a completed transfer actually belonged to.