Wait-State Impact

A wait state is the slave saying "not yet" by doing nothing. There is no stall signal in Wishbone Classic — the slave simply withholds all three terminations and the master holds everything still.

Wait states change WHEN bytes move. They never change HOW MANY.

1. Efficiency Has To Be Defined Before It Is Used

"Efficiency" is not a term B3 defines. So this module defines it, publishes the definition, and repeats it wherever a number from it appears:

efficiency = clocks on which a transfer completed
             ------------------------------------
             clocks elapsed while the master had work

Only the completing clock is called useful, because it is the only clock on which data moves.

2. What A Wait State Looks Like

ADR_O does not move during any of the waits, and that is required rather than polite. RULE 3.60: "MASTER interfaces MUST qualify the following signals with [STB_O]: [ADR_O], [DAT_O()], [SEL_O()], [WE_O], and [TAGN_O]." The request stands still until it is answered.

And the ACK_W0 row is the one B3 warns about. A termination asserted in the same clock as the strobe means a combinational path from master through interconnect to slave and back — permitted by PERMISSION 3.10, and named in §4.1 as "the dominant timing factor" in large devices. Chapter 22.1 §2 has the full quotation.

3. Efficiency Across Four Settings

    4. EFFICIENCY AND PAYLOAD
       waits  useful  total   eff    payload  bytes/clock
         0      16      32    50%      54       1.69
         1      16      48    33%      54       1.12
         2      16      64    25%      54       0.84
         4      16      96    17%      54       0.56

       payload is identical at 54 bytes everywhere,
       because wait states change WHEN bytes move and not
       HOW MANY. bytes-per-clock falls because the
       denominator grows.

4. The Half Of The Loss That Is Not The Slave's

Look at the W=0 row again: 50% efficiency with a slave that never waits once.

  === SIM E - efficiency, and where the lost clocks went ===
    EFFICIENCY is defined by this module, because B3 does
    not define it:

      efficiency = clocks a transfer completed
                   -------------------------------
                   clocks the master had work to do

    Only the completing clock is called useful, because it
    is the only clock on which data moves. A wait state is
    real work by the slave and is still not a transfer.

      waits  useful  total  efficiency  lost:wait  lost:idle
        0      16      32      50%         0          16
        4      16      96      17%        64          16

      lost:wait  + lost:idle + useful  =  total
        W=0   0 + 16 + 16 = 32
        W=4   64 + 16 + 16 = 96
      -> every clock attributed, both settings.

      NOTE WHAT THE W=0 ROW SAYS: 50% efficiency with a
      slave that never waits. Half the clocks are the
      master's own recovery - the clock SIM A's audit
      named. Efficiency measures the PAIR, not the bus.

Sixteen lost clocks at zero wait states, and every one of them is lost:idle — the master's. The slave contributed nothing to the loss because it never withheld an acknowledgement.

Efficiency measures the PAIR, not the bus. A reader who sees 50% and goes looking for a faster slave will find nothing to fix.

5. The Erosion, As Arithmetic

From Chapter 22.1 §3, a transfer occupies 1 + W clocks of [STB_O]. With the master's one recovery clock per transfer, the whole run is:

STB clocks   = N × (1 + W)
wall clocks  = N × (2 + W)
efficiency   = N ÷ (N × (2 + W)) = 1 / (2 + W)

Exact at every setting. And the shape is worth naming: efficiency does not fall linearly with wait states — it falls as 1/(2+W), so the first wait state costs 17 percentage points and the fourth costs 8.

The consequence is counter-intuitive and practical: the first wait state is the expensive one. Going from a zero-wait slave to a one-wait slave costs more efficiency than going from four waits to eight.

6. Bytes Per Clock, Eroded

These are the numbers to hand a system architect, and they carry no time unit. Multiply by a clock frequency established for a real design and they become bytes per second — a step Chapter 22.1 §1 explains this module cannot take, and Chapter 22.5 explains why taking it is harder than it looks.

7. How A Slave Actually Inserts One

There is no stall signal. A Wishbone slave inserts a wait state by doing nothing at all — withholding all three terminations — and the master's obligation to hold the request still does the rest.

  logic [7:0]  held_q;
  logic        ack_q;
  logic [15:0] nwr_q, nrd_q, nbt_q;

  logic xfer, waited;
  assign xfer   = cyc_i && stb_i;
  assign waited = held_q >= WAITS[7:0];

xfer is a request existing; waited is that request having waited long enough. The counter behind waited is the only state a wait-stating slave needs:

      if (xfer && !ack_o) held_q <= held_q + 8'd1;
      else                held_q <= 8'd0;

It resets whenever the request is not standing, and whenever the request is answered. So a slave that has just answered starts its next wait from zero, which is what makes PRESENT in Chapter 22.2 exactly W per transfer rather than drifting.

8. Where Wait States Come From

Not all wait states have the same fix, and the decomposition in Chapter 22.2 cannot tell them apart — they all land in PRESENT.

The fourth row is the interesting one and it is Chapter 22.5's subject. A slave whose latency is a pipeline fill rather than a per-access cost pays it once at the head of a burst — and that distinction turns out to matter more than the choice of termination scheme.

9. What Wait States Do Not Change

    1. DID EVERY RIG DO THE SAME WORK, AND GET THE SAME ANSWERS?
       rig     issued answered  signature
       W=0       16      16      0x98b97cbd
       W=1       16      16      0x98b97cbd
       W=2       16      16      0x98b97cbd
       W=4       16      16      0x98b97cbd
       -> ALL FOUR IDENTICAL. Wait states change the
          clock count and nothing else.

Four rigs, four wait-state settings, one order-sensitive signature: 0x98b97cbd. Identical everywhere.

Wait states are a pure cost and never a hazard. Nothing reordered, nothing was lost, no value differed — which is a direct consequence of RULE 3.35 and one transfer in flight. Chapter 20.3 §7 found the opposite in an AXI rig with four outstanding transactions, where the answers came back in a different order.

A protocol that cannot have two transactions in flight cannot reorder them, and that safety is the other side of the throughput ceiling Chapter 22.2 §8 described.

10. A System Has An Average, And The Weights Are Yours

Every table in this chapter fixes one wait-state count for the whole run. A real address map does not work that way — different destinations answer at different speeds, and the number that matters is a weighted mean.

Taking the four measured settings as four destinations and applying an access distribution:

Now move a tenth of the traffic from SRAM to the off-block peripheral and the mean becomes 3.70 — a 9% throughput loss with no RTL changed anywhere.

11. What To Do About Them