The RTY Signal

Module 10 treated every failure as final. Nothing asked to be tried again, and no master re-issued anything — RTY appeared only to close the taxonomy.

What does a target do when it cannot serve a request now but could later?

1. Three Classes, Three Different Consequences

The classification itself has been settled since Chapter 10.1: the STB_O description says the slave asserts either ACK_I, ERR_I or RTY_I in response to every assertion of STB_O, and RULE 3.45 forbids a slave that supports the optional ones from asserting more than one at a time.

What Module 11 adds is that the three classes imply three different actions.

The Transfer row is the one to memorise. All three end the transfer. RTY is a termination, not a pause, and Chapter 11.4 is built on the consequence: a later attempt is a different transfer.

The Read data row differs from ERR in a way worth noticing. RULE 3.65 requires the slave to qualify DAT_O() with ACK_O, ERR_O or RTY_O, so a conformant slave drives something at an RTY termination. But the signal description says the interface is "not ready to … send data" — so on an RTY there is definitionally no read result, which is a stronger statement than the specification makes for ERR.

And both optional classes are genuinely optional. PERMISSION 3.25 says master and slave interfaces may be designed to support RTY_I / RTY_O; PERMISSION 3.20 says the same for error. OBSERVATION 3.35 records the hazard when they disagree: if the slave supports RTY_O but the master does not, deadlock may occur.

2. What the Specification Does Not Require

It does not require the master to retry. There is no numbered rule to that effect anywhere. The signal description says the signal indicates that the cycle should be retried, and the very next sentence hands when-and-how to the IP core supplier.

So "retry" is a policy the master implements, not an obligation the bus imposes. A conformant master could reasonably:

All four are legal. What is not legal is leaving the choice undocumented — RULE 2.15 requires a master supporting RTY_I to describe how it reacts.

It does not guarantee the next attempt will succeed. The target said it is not ready; it said nothing about when it will be. A retry can be answered with another RTY, indefinitely, which is why Chapter 11.2 treats bounding as a correctness requirement rather than a refinement.

It does not define a retry delay. No minimum gap, no backoff, no maximum rate. Chapter 11.4 defines one as local policy and measures it.

And "temporary" versus "permanent" is system meaning, not hardware fact. Nothing in the protocol marks an ERR as permanent or an RTY as transient. What the two classes carry is where the problem is — your request, or the target's availability — and a system chooses what to do about each.

3. Two Levels of State

The distinction Module 11 depends on, and the reason its counters are worth keeping separate:

  CLIENT REQUEST              one accepted client operation
    ├── BUS ATTEMPT 0         presented ... terminated by RTY
    ├── BUS ATTEMPT 1         presented ... terminated by RTY
    └── BUS ATTEMPT 2         presented ... terminated by ACK
                              -> client request SUCCEEDED

A client request has one outcome. A bus attempt has one termination. They are different counts, and in a retrying system they differ routinely.

retry-exhausted is not a bus state at all. No termination class means it; it is what a master reports when its own policy runs out. Conflating it with ERR is the mistake Chapter 11.5 spends its debugging section separating.

4. The Running Hardware — A Resource That Can Be Full

Module 11 needs a target whose "not now" is genuine, and the peripheral already has one: the COMMAND register at word 9, introduced in Chapter 7.4 and given a FIFO here.

All three come from one mechanism, which is what makes the comparison honest: the slave is not three special cases wearing one name.

And the FIFO drains only when the testbench says so. There is no randomness anywhere in this module; every scenario is reproducible.

5. RTL — A Slave That Can Say Not Now

// wb_cmd_fifo_slave — the running peripheral's COMMAND port, backed by a
// small FIFO that can genuinely be full.
//
// This is the hardware condition Module 11 is built on, and it was chosen
// because it produces all three termination classes from ONE mechanism
// rather than from three unrelated special cases:
//
//   write COMMAND, FIFO has space   -> ACK_O   the command was accepted
//   write COMMAND, FIFO is full     -> RTY_O   not now; space is expected
//   offset not implemented here     -> ERR_O   never; nothing will change
//
// THAT MIDDLE ROW IS THE POINT. "Full" is a condition that a draining
// consumer is expected to clear without the master doing anything. Nothing
// failed; the target simply cannot accept data at this moment — which is
// what the RTY_I signal description says the signal means:
//
//   "indicates that the interface is not ready to accept or send data,
//    and that the cycle should be retried. When and how the cycle is
//    retried is defined by the IP core supplier."
//
// THE POLICY BELOW IS THIS SLAVE'S, NOT WISHBONE'S. RULE 2.15 requires a
// slave supporting RTY_O to document the conditions generating it, and a
// slave supporting ERR_O likewise. This header is that documentation.
// A different peripheral could answer a full FIFO with wait states instead
// (Chapter 11.3 builds one and measures the difference) and be equally
// conformant.
//
// SIDE-EFFECT CONTRACT, which Chapter 11.4 measures: an attempt terminated
// with RTY_O pushes NOTHING. The push and the acknowledge are computed from
// one condition, so a retried command cannot be enqueued twice.
//
// DETERMINISM: there is no randomness anywhere. The FIFO drains only when
// drain_i is asserted, so every scenario in this module is reproducible.
// ─────────────────────────────────────────────────────────────────────────
module wb_cmd_fifo_slave #(
  parameter int unsigned OFF_AW = 4,
  parameter int unsigned DW     = 32,
  parameter int unsigned DEPTH  = 2
) (
  input  logic                clk_i,
  input  logic                rst_i,
  input  logic                cyc_i,
  input  logic                stb_i,
  input  logic                we_i,
  input  logic [OFF_AW-1:0]   adr_i,
  input  logic [DW-1:0]       dat_i,
  input  logic [DW/8-1:0]     sel_i,
  output logic [DW-1:0]       dat_o,
  output logic                ack_o,
  output logic                err_o,
  output logic                rty_o,

  // the consumer side, driven by the testbench so every run is deterministic
  input  logic                drain_i,

  // observation only — not part of the Wishbone interface
  output logic [3:0]          level_o,
  output logic                full_o,
  output int unsigned         pushes_o,      // commands actually enqueued
  output logic [DW-1:0]       last_cmd_o
);
  localparam logic [OFF_AW-1:0] O_STATUS = 4'd0;   // RO
  localparam logic [OFF_AW-1:0] O_ID     = 4'd4;   // RO
  localparam logic [OFF_AW-1:0] O_CMD    = 4'd9;   // WO, enqueues
  localparam logic [DW-1:0] ID_VALUE = 32'h5742_1101;

  logic [3:0]    level_q;
  logic [DW-1:0] last_q;
  logic          xfer, mapped, is_cmd, full, accept;

  // RULE 3.35: every termination class is generated from the AND of
  // CYC_I and STB_I. RTY_O is qualified exactly like ACK_O.
  assign xfer   = cyc_i && stb_i;
  assign mapped = (adr_i == O_STATUS) || (adr_i == O_ID) || (adr_i == O_CMD);
  assign is_cmd = (adr_i == O_CMD) && we_i;
  assign full   = (level_q >= 4'(DEPTH));

  // ── THE DECISION, in one term. `accept` drives the acknowledge AND the
  //    push, so an attempt that is retried cannot have enqueued anything.
  assign accept = xfer && mapped && is_cmd && !full;

  // RULE 3.45 holds by construction: the three expressions are mutually
  // exclusive because `mapped`, `is_cmd` and `full` partition the cases.
  assign ack_o = xfer && mapped && (!is_cmd || !full);
  assign rty_o = xfer && mapped &&   is_cmd &&  full;
  assign err_o = xfer && !mapped;

  // RULE 3.65 qualifies DAT_O() with whichever termination is asserted.
  // On RTY the signal description says the interface is "not ready to
  // accept or send data", so there is definitionally no read result here;
  // this slave drives zero.
  always_comb begin
    dat_o = '0;
    if (xfer && !we_i && mapped && !rty_o) begin
      case (adr_i)
        O_STATUS: dat_o = {27'd0, full, level_q[2:0]};
        O_ID:     dat_o = ID_VALUE;
        default:  dat_o = '0;
      endcase
    end
  end

  assign level_o    = level_q;
  assign full_o     = full;
  assign last_cmd_o = last_q;

  always_ff @(posedge clk_i) begin
    if (rst_i) begin
      level_q <= '0; last_q <= '0; pushes_o <= '0;
    end else begin
      // A push and a drain in the same clock leave the level unchanged.
      case ({accept, (drain_i && (level_q != 4'd0))})
        2'b10: level_q <= level_q + 4'd1;
        2'b01: level_q <= level_q - 4'd1;
        default: ;                       // 2'b00 and 2'b11 hold
      endcase

      if (accept) begin
        last_q   <= dat_i;
        pushes_o <= pushes_o + 1;
      end
    end
  end
endmodule

Reading it

The three termination expressions partition the cases, so RULE 3.45 holds by construction rather than by inspection. mapped, is_cmd and full divide every qualified transfer into exactly one class, and no ordering of tests can make two true.

accept drives both the acknowledge and the push. That single term is the side-effect contract: an attempt terminated with RTY_O enqueues nothing, because the same condition that suppresses the push suppresses the acknowledge. Section 7 measures it, and Chapter 11.4 builds the slave that gets it wrong.

rty_o is qualified by xfer exactly as ack_o is — RULE 3.35 makes no distinction between the classes. A slave that asserted RTY_O from internal state without the qualification would be generating a termination for a request nobody made.

dat_o is driven to zero on an RTY. RULE 3.65 requires the slave to qualify DAT_O() with whichever termination it asserts, so the signal must be in a defined state — but the signal description says the interface is "not ready to … send data", so there is no read result to give. Driving zero is a defined value that is deliberately not a plausible one.

The push-and-drain arithmetic is written as a case on both events rather than as two independent increments. A push and a drain in the same clock leave the level unchanged, and expressing that explicitly avoids the classic FIFO bug where the two paths disagree at the boundary.

Timing. All three terminations are combinational in the qualified transfer, so this slave answers in the presenting clock — the zero-wait shape PERMISSION 3.30 explicitly allows. An RTY is not slower than an ACK; the class carries the information, not the timing.

Reset. Active high, synchronous, consistent with the module.

Simplifications. SEL_O is ignored — Module 13 owns byte lanes. The FIFO holds a level rather than storage, because nothing in this module reads the queued commands back. There is no wait-state path; Chapter 11.3 adds one to compare against.

6. Waveform — Three Classes, One Structure

CYC+STB is one row because it is one trace. All three accesses are presented at cycle 2 and released by cycle 3. Up to the terminating edge there is nothing to distinguish them.

Cycle 2 is the terminating edge for all three. ACK_I, RTY_I and ERR_I, one each, all qualified by the same CYC_O && STB_O. An RTY costs exactly what an ACK costs — one clock, here — and carries completely different architectural meaning.

Cycle 3 is where the clients learn. done for all three; ok, rty and err respectively. Exactly one outcome accompanies each completion.

And all three released the bus. CYC+STB is low at cycle 3 in every rig. The RTY transfer is over — a master that kept presenting after one would be waiting for an answer it had already been given, which is Chapter 11.2's first misconception.

What the figure cannot show is what happens next. The ACK rig is finished. The ERR rig is finished. The RTY rig has a decision to make, and nothing on the bus makes it.

7. Simulation — SIM A

Five accesses through one slave with DEPTH = 2 and no draining, so the FIFO fills and the fourth access meets a full queue.

  === SIM A - one request path, three termination classes ===
    COMMAND FIFO, DEPTH=2, no draining. Each write fills it further.

    access                             ok   err  rty   level  pushes
    read  word 4   ID                  1    0    0     0      0
    write word 9   COMMAND (space)     1    0    0     1      1
    write word 9   COMMAND (space)     1    0    0     2      2
    write word 9   COMMAND (FULL)      0    0    1     2      2
    read  word 7   not implemented     0    1    0     2      2

    bus     presented 5   ACK 3   ERR 1   RTY 1
    client  done 5   ok 3   err 1   rty 1
    FIFO    level 2   pushes 2   last command 0xc0de0002

Read the level and pushes columns down the table. The first two COMMAND writes each raise the level and each increment pushes. The third does neither.

pushes = 2 after three COMMAND writes is the side-effect result, and it is the reason this slave is safe to retry against. The RTY-terminated attempt enqueued nothing, so re-issuing that command later cannot enqueue it twice.

last command = 0xc0de0002 confirms it from the other direction: the third command's payload never reached the queue.

The bus and client counters agree on totals and disagree on nothing. Five presented clocks, five terminations — 3 ACK, 1 ERR, 1 RTY — and five completions classified 3 / 1 / 1. Every attempt terminated and every termination was classified.

One access was refused and one was deferred, and the client can tell which. err = 1 for the unimplemented offset; rty = 1 for the full queue. Collapsing them would lose exactly the information a retry policy needs — one of those is worth attempting again and the other never will be.

And notice what SIM A does not show. No attempt was re-issued. The master in this chapter classifies and reports; it does not retry, which is a legitimate policy and the simplest correct one. Chapter 11.2 builds a master that does retry, and finds that the hard part is not the retrying.

8. Simulation — SIM B: The Conformance Audit

Section 5's slave answers three ways. SIM B checks that all three are signalled the way the specification requires, by driving the slave directly — no master — so the slave is audited alone, including two stimuli a well-behaved master never produces.

Four continuous monitors run for the whole simulation. Each is a verified requirement, not a house rule:

  === SIM B - termination-class conformance audit ===
    the slave is driven directly, DEPTH=1, no master involved.

    stimulus                           state         class
    read ID            mapped          level=0 full=0   ACK
    write COMMAND      space free      level=0 full=0   ACK
    write COMMAND      full            level=1 full=1   RTY
    read word 7        unmapped        level=1 full=1   ERR

    holding STB_I asserted for 3 clocks on a full COMMAND write
    RTY_O across the hold: still asserted (a held strobe is one transfer)
    one clock after STB_I fell: ACK=0 ERR=0 RTY=0

    driving STB_I with CYC_I LOW (an illegal request)
    ACK=0 ERR=0 RTY=0   pushes now 1

    qualified strobe clocks 8   ACK 2   ERR 1   RTY 5
    violations   multi-class 0   unqualified 0   silent 0   stuck 0
    FIFO         pushes 1   last command 0xaaaa0001

  === errors: 0 ===

Reading it

Zero violations across eight qualified strobe clocks, and that is the whole result. Two ACK, one ERR, five RTY — every qualified strobe answered exactly once, none answered twice, none answered outside a transfer.

The held-strobe case is the one worth staring at. STB_I was held asserted for three clocks and RTY_O stayed asserted throughout — and the monitors counted three qualified strobe clocks, not three attempts. Chapter 11.4 makes this exact point from the master's side: without a negation there is no second transfer, and this is the slave's half of the same fact. RULE 3.50 is satisfied because the termination fell when the strobe did — the line one clock after shows all three low.

The CYC_I low case produced no termination at all and no push. RULE 3.35 makes CYC_I part of the qualification, so a strobe without it is not a transfer, and the slave correctly treated it as nothing. pushes stayed at 1 — the one accepted command — which is also the side-effect contract holding against malformed stimulus.

9. Failure Modes and Discriminating Evidence

Symptom: a command is executed twice.

Candidate causes. A target that enqueued the command and then returned RTY, followed by a master that retried.

Discriminating evidence. Compare the target's push count against the number of ACK terminations. They must be equal. A push count exceeding acknowledges means the target acted on an attempt it deferred — Chapter 11.4 measures one.

Likely RTL location: separate conditions for the acknowledge and the side effect. wb_cmd_fifo_slave computes both from accept.

Symptom: a master hangs against a slave that returns RTY correctly.

Candidate causes. The master does not implement RTY_I, so the termination arrives on a wire nobody is watching.

Discriminating evidence. RTY_O asserted at the slave while the master still presents. Both interfaces can be individually conformant — PERMISSION 3.25 makes support optional on both sides — and OBSERVATION 3.35 records that deadlock may occur when they disagree.

Where the fault sits: integration, and RULE 2.15's datasheets are what would have caught it on paper.

Symptom: software reports a failure for an operation that would have worked a moment later.

Candidate causes. A client contract that folds RTY into the error path.

Discriminating evidence. Compare the client's failure count against bus ERR terminations. Failures exceeding errors means retry-class terminations are being reported as errors.

Whether that is a bug is a policy question — a client with no concept of "later" may legitimately convert them — but it should be a decision, not an accident.

Symptom: a read returns a plausible value from an RTY-terminated access.

Candidate causes. Data captured on any termination rather than on ACK.

Discriminating evidence. The RTY_I description says the interface is not ready to send data, so there is nothing valid to capture. A value that matches a previous read is the signature of a stale capture register — the shape Chapter 10.1 §7 measured.

10. Verification

// Properties for a slave that supports all three termination classes.
// The split matters: the first three are the specification's and hold for
// any conformant slave; the last two are THIS slave's contract, and a
// different peripheral could define them differently.
//
// NOTE ON EXECUTION: Icarus Verilog does not support SVA. These were
// reviewed by inspection and are NOT claimed to have been executed. The
// numbers in Sections 7 and 8 come from procedural checks, which Icarus
// does run — SIM B's four monitors are the executable form of P1, P2 and P4.
// ─────────────────────────────────────────────────────────────────────────
module wb_fifo_slave_props (
  input logic       clk_i, rst_i,
  input logic       cyc_i, stb_i, we_i,
  input logic [3:0] adr_i,
  input logic       ack_o, err_o, rty_o,
  input logic       full_i,
  input int unsigned pushes_i
);
  default clocking cb @(posedge clk_i); endclocking
  default disable iff (rst_i);

  logic xfer, cmd_write;
  assign xfer      = cyc_i && stb_i;
  assign cmd_write = xfer && we_i && (adr_i == 4'd9);

  // S1 — SPECIFICATION (RULE 3.45). A slave supporting ERR_O or RTY_O must
  //      not assert more than one class at a time. Here it is structural,
  //      but the property is what proves the structure.
  S1_exclusive: assert property ( $onehot0({ack_o, err_o, rty_o}) );

  // S2 — SPECIFICATION (RULE 3.35). Every class is generated from the AND
  //      of CYC_I and STB_I. RTY_O is qualified exactly like ACK_O.
  S2_qualified: assert property ( (ack_o || err_o || rty_o) |-> xfer );

  // S3 — SPECIFICATION (RULE 3.50 / OBSERVATION 3.10). A termination is
  //      negated in response to the negation of STB_I, so no class
  //      survives into a clock where nothing is presented.
  S3_negates: assert property ( !xfer |-> (!ack_o && !err_o && !rty_o) );

  // S4 — LOCAL CONTRACT, and the one Module 11 depends on. An attempt
  //      terminated with RTY_O performs no architectural side effect.
  //      Without this, retrying is unsafe and no master can fix it.
  S4_no_push_on_rty: assert property (
    (cmd_write && rty_o) |=> $stable(pushes_i)
  );

  // S5 — LOCAL CONTRACT. This slave's documented policy: a COMMAND write
  //      is deferred exactly when the queue is full, and accepted
  //      otherwise. RULE 2.15 requires the policy to be published; this
  //      is the checkable form of the header comment.
  S5_policy: assert property ( cmd_write |-> (full_i ? rty_o : ack_o) );
endmodule

S4 is the property that makes retry safe, and it is worth being clear that it is not a Wishbone rule. Nothing in the specification says a deferring target must leave its state unchanged. It is a contract this slave offers so that a master may safely re-issue — and a target that does not offer it cannot be retried against, whatever the master does.

S3 is easy to omit and catches a real class of bug. Chapter 9.5 measured a slave that held a stale acknowledge into the following transfer; the same defect with RTY_O would defer a request the target had never seen.

S5 encodes the datasheet. RULE 2.15 requires a slave supporting RTY_O to document the conditions generating it. Writing that as a property means the documentation and the RTL cannot drift apart silently.

11. Common Mistakes

"RTY means keep STB_O asserted until the slave is ready."

Wrong mental model: a retry is a request to wait.

What is true: RTY is a termination. The STB_O description says the slave asserts either ACK_I, ERR_I or RTY_I in response to every assertion of STB_O — one class per presented transfer, and the transfer is then over.

Concrete bug: a master that holds STB_O after an RTY, waiting for an acknowledge that will never come. The slave, honouring RULE 3.50, keeps asserting RTY_O for as long as the request is presented — a stable livelock at the signal level.

Observable evidence: RTY_I asserted on consecutive clocks with STB_O never negating.

Correct model: release, then decide. Chapter 11.2 measures the release.

"RTY means the access failed."

Wrong mental model: anything that is not an acknowledge is an error.

What is true: the signal description says the interface is not ready to accept or send data — a statement about the target's availability, not about the request's validity. The same request may succeed unchanged moments later.

Concrete bug: a client contract that folds RTY into the error path, so a transient full queue is reported to software as a device failure.

Observable evidence: client failures exceeding bus ERR count.

Correct model: ERR says something about your request; RTY says something about the target.

"RTY guarantees the next attempt will succeed."

Wrong mental model: deferral implies imminent availability.

What is true: the target said it is not ready. It said nothing about when it will be, and a retry can be answered with another RTY indefinitely.

Concrete bug: an unbounded retry loop against a resource that never clears — a livelock in which every component behaves correctly.

Observable evidence: a rising attempt count with no change in the target's ready condition.

Correct model: bound the retries. Chapter 11.2 treats this as a correctness requirement.

"The specification requires the master to retry."

Wrong mental model: the signal's name is an instruction.

What is true: there is no such rule. The description says the signal indicates the cycle should be retried and then hands when-and-how to the IP core supplier. A master that reports RTY upward without retrying is conformant — and must document that, per RULE 2.15.

Correct model: retry is a policy. The bus provides the class; the architecture provides the response.

"A target may perform the operation and then return RTY."

Wrong mental model: the master will just try again, so an early commit is harmless.

What is true: it is only harmless if the operation is idempotent, and a command queue is not — the retry enqueues it a second time.

Concrete bug: separate conditions for the push and the acknowledge, which Chapter 11.4 builds and measures.

Observable evidence: the target's push count exceeding its ACK count.

Correct model: one condition drives the termination and the side effect, as accept does here.

12. Interview Reasoning

13. Understanding Check

14. What's Next

The class is established: a termination that says not now, exclusive with the others, costing one clock, leaving the target's state untouched.

And the master in this chapter did nothing about it. It classified the deferral, reported it upward, and stopped — which is a legitimate policy and the simplest one that is correct.

What does it actually take to attempt the operation again?

Chapter 11.2 — Retry Concepts builds a retrying master, establishes that every attempt is a separate transfer, and measures what happens when a master re-reads its client instead of remembering what it accepted. The full path is on the Wishbone curriculum index.