ACK Generation

Every chapter in this module so far has taken a commit clock as an input and never asked where it came from. Chapter 24.2's FIFO pops on it; Chapter 24.3's registers change on it. This chapter decides what it is.

It is the Critical chapter of Module 24 for a reason that has nothing to do with difficulty. [ACK_O] is the only signal in a Wishbone slave that every other decision depends on, and B3 — unusually — tells you the price of getting it wrong, in clocks, in advance.

OBSERVATION 3.50: "Using registered [ACK_O], [ERR_O], and [RTY_O] signals significantly reduces this loopback delay, at the cost of one additional wait state per transfer."

Measured, on eight transfers: exactly eight extra wait clocks. One per transfer. B3's own prediction, confirmed to the clock.

1. Four Ways To Answer

  parameter int unsigned SCHEME = 0,   // 0 COMB, 1 REG, 2 COUNT, 3 TIED

Each is one expression:

  logic raw_ack;
  assign raw_ack = (SCHEME == S_COMB)  ? selected :
                   (SCHEME == S_REG)   ? ack_q    :
                   (SCHEME == S_COUNT) ? (selected && (held_q >= WAITS[7:0]))
                                       : 1'b1;      // S_TIED

2. B3 Argues With Itself, In Order, Within Five Paragraphs

This is the passage every one-clock claim in this curriculum has had to reckon with. Read it as a sequence:

PERMISSION 3.10 — "If the SLAVE guarantees it can keep pace with all MASTER interfaces and if the [ERR_I] and [RTY_I] signals are not used, then the SLAVE's [ACK_O] signal MAY be tied to the logical AND of the SLAVE's [STB_I] and [CYC_I] inputs."

PERMISSION 3.30 — "The assertion of [ACK_O], [ERR_O], and [RTY_O] MAY be asynchronous to the [CLK_I] signal (i.e. there is a combinatorial logic path between [STB_I] and [ACK_O])."

OBSERVATION 3.40 — "The asynchronous assertion ... assures that the interface can accomplish one data transfer per clock cycle. Furthermore, it simplifies the design of arbiters..."

OBSERVATION 3.45 — "The asynchronous assertion of [ACK_O], [ERR_O], and [RTY_O] could proof impossible to implement. For example slave wait states are easiest implemented using a registered [ACK_O] signal."

OBSERVATION 3.50 — "In large high speed designs the asynchronous assertion ... could lead to unacceptable delay times, caused by the loopback delay from the MASTER to the SLAVE and back to the MASTER. Using registered ... signals significantly reduces this loopback delay, at the cost of one additional wait state per transfer."

Five identifiers. Two of them permit the fast path, one praises it, and two take it back. Modules 1 through 23 cited the first three and never the last two — OBSERVATION 3.45 and OBSERVATION 3.50 appear in this curriculum for the first time here.

This is not B3 being inconsistent. It is a specification describing one design choice honestly: here is the fast way, here is why it is fast, here is why you may not be able to build it, and here is exactly what the alternative costs. Very few specifications quantify their own trade-offs.

3. Measured

Eight writes, one master, one map, one workload. SCHEME is the only difference:

      scheme            clocks  xfers  wait clks  clk/xfer
      COMB  (P 3.10)        23      8          0      2.8
      REG   (O 3.50)        31      8          8      3.8
      COUNT W=3             47      8         24      5.8
      TIED  (P 3.35)        23      8          0      2.8

And the prediction, tested:

      COMB wait clocks  0   over 8 transfers
      REG  wait clocks  8   over 8 transfers
      difference        8
      -> EXACTLY ONE ADDITIONAL WAIT STATE PER TRANSFER.
         B3's prediction holds for this implementation.

Eight extra wait clocks over eight transfers. Not approximately one per transfer — exactly one, because the registered scheme decides one clock ahead and that decision is the wait state.

Swept across wait-state settings, the relationship is linear with no surprises:

      WAITS   clocks   clk/xfer   vs COMB
        0         23      2.8       baseline
        1         31      3.8       +8 clocks
        2         39      4.8       +16 clocks
        3         47      5.8       +24 clocks
        4         55      6.8       +32 clocks

      -> Each wait state costs exactly one clock per
         transfer: 8 clocks for 8 transfers, linearly.

Notice that COUNT with WAITS=1 costs exactly what REG costs. They are 31 clocks each. A registered termination is a one-wait-state slave, structurally — which is precisely what OBSERVATION 3.50 says, and seeing two different implementations land on the same number is the useful form of the confirmation.

4. The Scheme That Is Legal And Trips Every Checker

SCHEME_TIED holds [ACK_O] asserted permanently. It looks exactly like the bug Chapter 23.2 called HOLD_ACK. It is not a bug:

PERMISSION 3.35 — "Under certain circumstances SLAVE interfaces MAY be designed to hold [ACK_O] in the asserted state. This situation occurs on point-to-point interfaces where there is a single SLAVE on the interface, and that SLAVE always operates without wait states."

RULE 3.55 — "MASTER interfaces MUST be designed to operate normally when the SLAVE interface holds [ACK_I] in the asserted state."

RULE 3.55 is a MUST. Every conformant Wishbone master must already cope with a permanently-asserted [ACK_I], whether or not it ever meets one.

Pointed at Module 23's Classic conformance monitor:

      scheme   term-without-request  termination-held  viol
      COMB                      0                 0     0
      REG                       0                 0     0
      COUNT                     0                 0     0
      TIED                     50                 8    58

      -> TIED scored 58 violations AND IS LEGAL.

      THE MONITOR IS A MULTI-SLAVE CLASSIC MONITOR AND
      PERMISSION 3.35 IS A POINT-TO-POINT CARVE-OUT.
      Neither is wrong. The rig is outside the monitor's
      stated scope, and a checker applied outside its
      scope reports violations that are not violations.

This refines something Chapter 23.2 said

Chapter 23.2 presented its HOLD_ACK parameter as a flat RULE 3.50 violation. That was correct in the rig it was measured in and incomplete as a statement about the specification.

• In a multi-slave interconnect, a slave that never releases [ACK_O] answers for its neighbours. RULE 3.50 binds and HOLD_ACK is a genuine defect.
• On a point-to-point link with a single always-zero-wait slave, PERMISSION 3.35 explicitly permits it, and RULE 3.55 obliges the master to cope.

The rule did not change; the scope did. Module 23's measurement stands and its wording was too broad, and this is the correction — published rather than quietly fixed, because Module 23 is frozen.

5. The Negation Half, Which Is A Separate Question

NO_NEGATE is the real defect, distinct from TIED:

  // RULE 3.50's negation half. For every scheme but TIED the termination
  // must fall when [STB_I] falls; TIED is exempt by PERMISSION 3.35.
  // NO_NEGATE removes the obligation and is a real violation.
  logic gated_ack;
  assign gated_ack = (SCHEME == S_TIED) ? raw_ack
                   : (NO_NEGATE ? raw_ack : (raw_ack && selected));

selected is RULE 3.50 enforced in one term. And testing it turned up something that matters more than the defect:

      NO_NEGATE IS PAIRED WITH ITS OWN CONTROL, because it
      is only EXPRESSIBLE on the registered scheme. Under
      COUNT the raw termination already contains the
      CYC/STB gate, so deleting the outer gate changes
      nothing and the rig comes back clean. A DEFECT
      PARAMETER THAT CANNOT ARM IS NOT EVIDENCE OF A
      CORRECT DESIGN - the first run of this gate reported
      exactly that and it meant nothing.

The first version of the negative control ran NO_NEGATE on the COUNT scheme and it scored zero. Under COUNT, raw_ack already contains selected, so removing the outer gate changes nothing. The defect was configured, compiled, and inert.

With the scheme corrected and a matching control beside it:

      rig                  C1   C2   C3   C4   C5   C6   FUNC
      REG, correct          0    0    0    8    0    0    ok
      NO_NEGATE    3.50     5    0    0    8    5    0    ok

Five violations against a control that is identical but for one bit. And note the FUNC column: ok. The data was correct. Only the handshake was wrong — which is the exact inverse of Chapter 24.2's SIDE_ON_STB, where the handshake was perfect and the data was destroyed.

6. A Registered Termination Must Not Answer Twice

The registered scheme has a failure mode the combinational one cannot have, and it hides in a single term:

      // the registered scheme decides one clock ahead, and must not
      // re-assert on the clock after it has already answered
      ack_q <= selected && !(ack_q && selected);

Without !(ack_q && selected) the slave answers every other clock, forever, as long as [STB_I] stays up. A master that negates [STB_O] promptly never notices. A master that holds it — a slow one, a stalled one, or one in the middle of an arbitration handover — collects a second termination for a request it already retired.

That is not a theoretical concern. This module's own testbench hit it. The negative-control rig drives [STB] for a fixed number of clocks rather than releasing it on the first termination, and a COUNT-scheme slave duly terminated twice within one strobe. The capture logic latched the second one:

  // ONE capture per request, not one per ACK. The drive task holds
  // [STB] for a fixed number of clocks, so a COUNT-scheme slave reaches
  // its wait threshold, terminates, resets, and TERMINATES AGAIN while
  // the strobe is still up. Capturing every ACK therefore latched a
  // value read after a later write had already landed, and made three
  // different rigs look identical. A real master takes one response per
  // request; so does this.

Three rigs with different defects all read back 0x44444444 and the gate reported a false pass on one of them. The instrument was wrong and the symptom was that the defects became invisible — which is the same shape as every other measurement failure in this curriculum.

A slave that re-terminates and a testbench that re-samples are the same bug from two sides. B3 settles neither directly: RULE 3.50 ties the termination to the assertion and negation of [STB_I], and a strobe that never negated has, on a strict reading, never asked a second question.

And the reset behaviour, which is a MUST

One more rule governs this module and has not been cited anywhere in this curriculum:

RULE 3.20 — "The following MASTER signals MUST be negated at the rising [CLK_I] edge following the assertion of [RST_I], and MUST stay in the negated state until the rising [CLK_I] edge that follows the negation of [RST_I]: [STB_O], [CYC_O]."

It constrains the master, and it is what lets the slave's wait counter be as simple as it is: [CYC_I] and [STB_I] are guaranteed low across reset, so selected is low, so held_q resets to zero with no special case. A slave that had to defend against a strobe surviving reset would need a reset-qualified gate on every one of these expressions.

7. The Commit Clock, Exported

  // The transfer commits on the clock a termination is asserted while the
  // request is presented. For TIED that is the first presented clock,
  // because [ACK_O] was already high before the master arrived.
  assign commit_o = selected && (ack_o || err_o || rty_o);

One wire, and it is why the two datapath chapters did not have to know about any of this. Change SCHEME and the FIFO still pops once, the register still writes once, and neither module contains the word ACK.

// EVERY DATAPATH KEYS OFF commit_o, NEVER OFF [STB_I]. That single
// discipline is what makes the datapaths independent of which ACK scheme
// is selected, and the whole FIRE_ON_STB / SIDE_ON_STB family of bugs is
// what happens when it is broken.

The clock census proves the separation holds:

      rig             total  IDLE  REQ  WAIT  DONE  xfers viol
      COMB  W=0          23     8    8     0     7      8    0
      COUNT W=2          39     8    8    16     7      8    0

      -> 23 = 8+8+0+7 and 39 = 8+8+16+7.
         NO CLOCK IS UNACCOUNTED FOR.

IDLE, REQ and DONE are identical across the two schemes; the entire difference lands in WAIT. A wait state is a property of the slave, and the master's own bookkeeping never learns about it.

8. RULE 3.45, Quoted Correctly For The First Time

Modules 9 through 23 quoted RULE 3.45 like this: "the SLAVE MUST NOT assert more than one of the following signals at any time." That drops the opening clause. The full text:

RULE 3.45 — "If a SLAVE supports the [ERR_O] or [RTY_O] signals, then the SLAVE MUST NOT assert more than one of the following signals at any time: [ACK_O], [ERR_O] or [RTY_O]."

The one-hot obligation is conditional. A slave with only [ACK_O] — which RULE 3.40 permits, since [ERR_O] and [RTY_O] are optional — has nothing to be one-hot against, and the rule is vacuous for it.

No use this curriculum made of RULE 3.45 was wrong: every slave quoted against it supported ERR or RTY. But a rule quoted without its antecedent is a rule that will eventually be applied where it does not hold, and a checker built from the short version will flag a perfectly legal ACK-only slave.

9. What The Clock Count Does Not Settle

Every number in this chapter is a clock count.

      WHAT THIS DOES NOT SETTLE:
      Every row above is a CLOCK COUNT. COMB reaches
      2.8 clocks per transfer through a combinatorial
      path from [STB_I] to [ACK_O] which B3 s4.1 calls
      "the dominant timing factor" in a large SoC, and
      OBSERVATION 3.45 warns could "proof impossible to
      implement". NO SYNTHESIS TOOL WAS RUN. A design that
      halves the clock count and misses timing has not
      improved anything, and only synthesis can say which
      of these rows is actually faster in nanoseconds.

B3 §4.1, in full:

"...this results in an asynchronous loop from the MASTER, through the INTERCONN to the SLAVE, and then from the SLAVE through the INTERCONN back to the MASTER... In large System-on-Chip devices this routing delay between MASTER and SLAVE is the dominant timing factor."

COMB is 26% faster than REG in clocks and may be slower in nanoseconds. No measurement in this module can tell you which, because no synthesis tool was run on any of it. OBSERVATION 3.45 goes further than "slower" — it says the fast path may be unbuildable at all, and a designer who reads only the 2.8-against-3.8 table has been handed half an answer.

10. What This Chapter Did Not Build

• No registered-feedback termination. PERMISSION 4.15 lets a slave terminate without checking [STB_I], which changes three of the rules above. Chapter 22.5 measured it.
• No timeout. The slave answers or it does not; Chapter 24.5 is where the bus's own patience is discussed.
• No synthesis. Stated above and in the datasheet, where item 12 records the absence of a constraint rather than the presence of a guarantee.
• No arbitration interaction. RECOMMENDATION 3.05 warns that "Keeping [CYC_O] asserted may lead to arbitration problems" — a master-side concern that Chapter 17.5 owns.

Next: Chapter 24.5 — Error Generation asks the question this chapter deliberately skipped: when should the answer be "no", which of the two "no"s to use — and it finds that a claim Module 23 published four times is contradicted by the specification.