Latency

Chapter 22.1 measured how many clocks a transfer costs. This one asks where those clocks went, because the total is the least useful form of the answer.

"This transfer took four clocks" is not an analysis. Each of those clocks has a different owner and a different fix.

1. The Four Components

ANSWER is exactly one clock per transfer and cannot be anything else. RULE 3.45: "the SLAVE MUST NOT assert more than one of the following signals at any time: [ACK_O], [ERR_O] or [RTY_O]." One termination, one clock.

The other three are all optional in principle and all real in practice.

2. Why The Split Matters More Than The Total

Two systems can take the same number of clocks per transfer for completely different reasons, and the fix for one makes no difference to the other:

Optimising the slave in the second row buys nothing. The reader who only has the total cannot tell which row they are in.

3. One Transfer, Traced

The two dashed self-messages on the MASTER lifeline are the clocks this curriculum has been quietest about, and Chapter 22.1 §5 found one of them in its own reused master.

4. The Same Transfer On A Timebase

Read the phase row. Two transfers, two wait states each, and ten clocks for two transfers. Four of those ten are ISSUE and RECOVER — clocks the master spent, not the bus.

5. The Instrument

Attribution is only trustworthy if it can be checked, so the decomposer is built so the four components must sum to the total:

// below is in exactly one of them on every clock, and total_o is
// incremented from the same place. SIM J checks
//   issue + present + answer + recover == total
// and the negative control DOUBLE_COUNT breaks it deliberately, because
// an attribution that cannot fail has not been shown to attribute.
//
// ── WHY RECOVER IS MEASURED AT ALL ──────────────────────────────────────

  logic [15:0] ni_q, np_q, na_q, nr_q, nt_q, nx_q;
  logic [7:0]  ci_q, cp_q;          // this transfer's running components
  logic        seen_q;              // a transfer has completed already

  logic phase_present, phase_answer, phase_issue, phase_recover;
  assign phase_answer  = cyc_i && stb_i && term_i;
  assign phase_present = cyc_i && stb_i && !term_i;
  assign phase_issue   = want_i && !stb_i && !seen_q;
  assign phase_recover = want_i && !stb_i &&  seen_q;

SIM J verifies the sum at every wait-state setting, and Chapter 22.5 §6 seeds a meter that double-counts on purpose — because an attribution that cannot fail has not been shown to attribute.

6. The Decomposition, Measured

    3. LATENCY DECOMPOSITION - every clock counted once
       waits  issue present answer recover   sum  total
         0      1      0     16      15      32    32
         1      1      16     16      15      48    48
         2      1      32     16      15      64    64
         4      1      64     16      15      96    96
       -> conservation holds at every setting.

Read the present column down: 0, 16, 32, 64. That is the wait states, exactly N × W. Read issue and recover across: 1 and 15, unchanged at every setting. They are properties of the master and do not respond to the slave at all.

And answer is 16 everywhere — one clock per transfer, as RULE 3.45 forces.

7. What The Decomposition Reveals That The Total Hides

    THE STATE-MACHINE CLOCK AUDIT - read this before any
    number in this module is quoted.

      RECOVER is 15 clocks over 16 transfers. That is one
      clock per transfer, after the first, during which the
      master has work and is not asserting [STB_O].

      NO RULE IN B3 REQUIRES IT. It is wb_master_seq
      registering its next request - the same reused master
      Chapters 20 and 21 measured with. A master that drove
      [STB_O] combinationally from its request queue would
      spend zero here and be harder to time-close.

      SO TWO DIFFERENT TRUE NUMBERS EXIST FOR THIS RUN:
        clocks with [STB_O] asserted   16
        clocks from start to finish    32

      The formula in SIM B predicts the FIRST. It is a
      property of the protocol. The second is a property of
      this master, and Module 21 found the same class of
      clock making APB look 50% worse than it was.
      Every clocks-per-transfer figure in Module 22 is
      [STB_O] clocks and says so.

8. A Latency Budget For A Real Address Map

A system does not have one latency. It has one per destination, and the useful artefact is a budget rather than a number.

Taking the four settings this module measured and reading them as four different slaves on one bus:

Three of the four columns do not move. ISSUE and RECOVER are constants of the master, and ANSWER is fixed at one by RULE 3.45. Only PRESENT tracks the destination.

The budget makes the design conversation concrete. A client that needs an answer in three clocks can use the first two rows and not the last two, and no amount of bus tuning changes that — the PRESENT column is the peripheral's, and Chapter 22.3 §8 is about what to do when it is too large.

9. Client Latency Is Not Bus Latency

Everything above measures the bus. A client asking a master for an access sees more than that, and the difference is the part of the system a bus measurement cannot reach:

wb_master_seq delivers its result on the same clock the termination arrives — Chapter 16.3's rule that read data is meaningful only on the qualifying clock — so for this master the two happen to coincide.

A master with a registered output port would add a clock that no instrument in this module would see, because the instruments watch the bus and that clock is behind the master. Saying so is the point: a latency figure is only as complete as the boundary it was measured at, and this module's boundary is [CYC_O]/[STB_O]/[ACK_I].

10. The Bound B3 Does Not Provide

Every latency in this chapter is a measurement of one system. None of them is a guarantee, and the specification offers no way to make one.

B3 has no timeout, no maximum wait-state count and no bound of any kind on how long a slave may withhold a termination. Chapter 12.6 established that, and it is worth restating with numbers attached: PRESENT in §6 reached 64 clocks at four wait states, and nothing in the specification would have objected to 64,000.

So a latency budget is an agreement between designers, not a property of the bus. The PRESENT column in §8's table is something each peripheral's author has to tell you — which is RULE 2.00's obligation arriving in yet another chapter:

"Each WISHBONE compatible IP core MUST include a WISHBONE DATASHEET as part of the IP core documentation." — B3, RULE 2.00

That documentary obligation is the only latency bound Wishbone has — exactly the pattern Chapter 19.4 found for error response, where RULE 2.15 made a master's reaction to [ERR_I] a thing to write down rather than a thing to obey.

11. Latency Is Not Throughput

A system can have excellent latency and poor throughput, or the reverse, and Wishbone Classic makes the relationship unusually tight — which is itself a finding.

In a protocol with one transaction outstanding, latency and throughput are the same measurement in different units. Chapter 20 measured an AXI rig reaching four outstanding transactions, where they come apart completely.

That is why Chapter 22.5 matters: registered feedback is the only mechanism in B3 that lets a Wishbone slave answer a beat it has not yet been asked about.