Complexity Comparison

Nineteen chapters have built Wishbone systems. This module puts Wishbone next to AXI, and the comparison is worth making only if it starts from something both specifications actually say.

Wishbone couples address, data and response into one phase. AXI separates them into independent channels. Everything else is a consequence of that.

1. What Each Specification Can Even Talk About

Before arguing about which is better, it is worth counting what each document contains. These are case-sensitive counts over the full text of both, taken this session.

Neither document contains the other's central noun. B3 has no channels and no outstanding transactions; AXI has no CYC_O.

The zeros in the Wishbone column are not gaps. A specification in which the termination is generated in response to the request never needs a word for a second transaction in flight, because there cannot be one. outstanding is absent from B3 for the same reason carburettor is absent from a bicycle manual.

2. The Structural Picture

The top row has one arrow returning and the bottom row has none drawn, because on AXI the response is not a return path along the request — it is its own channel with its own handshake, and drawing it as a return would reproduce exactly the misunderstanding this chapter exists to remove.

3. The Three Consequences, In Order

1. COUPLING. A Wishbone master cannot accept a new address until the current one is answered. There is one [ADR_O], one [WE_O], one [SEL_O()] on the pins, and RULE 3.60 qualifies all of them with [STB_O]. Present a second address and you have destroyed the first.

2. OUTSTANDING WORK. Coupling caps outstanding transactions at one. Separation does not. Chapter 20.3 measures what that is worth, and the answer depends entirely on the slave.

3. ORDERING. Once more than one transaction can be outstanding, something has to say what order the answers come back in. Wishbone never needs that rule. AXI needs several — and this is the half of the comparison that usually gets left out. Chapter 20.3 §6 quotes AXI's own instruction for what to do when you need an ordering the protocol does not guarantee, and it is not what most readers expect.

4. Complexity, Counted Rather Than Asserted

"AXI is more complex" is easy to say and easy to over-claim. Here is a mechanical count over this module's own RTL — the same job, written by the same author in the same style in the same session, on each protocol.

  === MECHANICAL COMPLEXITY COUNT ===
    over this module's own RTL. Same job, same author, same
    session, two protocols. No synthesis was run and no number
    below is an area, gate-count or frequency figure.

    pair    measure           Wishbone   AXI4-Lite   ratio
    slave   port signals         27         41      1.52x
    slave   handshake pairs       1          5      5.00x
    slave   sequential blocks     1          1      1.00x
    slave   parameters            5          8      1.60x
    slave   code lines           53        124      2.34x

    master  port signals         51         70      1.37x
    master  handshake pairs       1          5      5.00x
    master  sequential blocks     1          1      1.00x
    master  parameters            3          4      1.33x
    master  code lines           77        130      1.69x

    THE ROW THAT MATTERS IS handshake pairs.

The row that matters is handshake pairs. A Wishbone slave sequences one. An AXI4-Lite slave sequences five, independently. That is the number that tracks what a designer has to hold in their head, and it is the number that makes the overlapping in Chapter 20.3 possible at all.

5. What Each Slave Has To Remember

The handshake pairs number is abstract until you look at the state it implies. Here is the entire request-tracking state of the Wishbone RAM this module reuses unchanged from Chapter 16.4:

  logic [15:0]   nwr_q;
  logic [7:0]    held_q;

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

  assign ack_o    = ready && !busy_i;
  assign rty_o    = xfer  &&  busy_i;
  assign err_o    = 1'b0;
  assign writes_o = nwr_q;

  logic [$clog2(WORDS)-1:0] widx;
  assign widx = adr_i[$clog2(WORDS)-1:0];
  assign dat_o = mem[widx];

One counter and one comparison. xfer is the request; ready is the request having waited long enough; ack_o is the answer. There is nothing to store, because the request is still on the wires — RULE 3.60 keeps it there until the phase terminates, so the slave can read the address off its own input pins at the moment it answers.

Now the AXI-Lite slave doing the identical job:

  // ── write-side queues, ODEPTH entries ──
  logic [AW-1:0] awq  [0:7];
  logic [DW-1:0] wdq  [0:7];
  logic [SW-1:0] wsq  [0:7];
  logic [3:0]    aw_wr_q, aw_rd_q, w_wr_q, w_rd_q;
  // ── read-side queue ──
  logic [AW-1:0] arq  [0:7];
  logic [3:0]    ar_wr_q, ar_rd_q;

  logic [7:0]    wcnt_q, rcnt_q;
  logic          bval_q, rval_q;
  logic [DW-1:0] rdat_q;
  logic          brsp_q, rrsp_q;
  logic [15:0]   nwr_q, nrd_q;

Three queues and six pointers, because each channel may accept something the others have not caught up with. The address is not still on the pins when the answer goes out — it was taken on a handshake that may be many clocks in the past, so the slave has to have kept it.

6. Capture Is Per-Channel, And That Is The Part To Read Twice

      // ── capture on each channel, independently of the others ──
      if (awvalid_i && awready_o) begin
        awq[aw_wr_q[2:0]] <= awaddr_i; aw_wr_q <= aw_wr_q + 4'd1;
      end
      if (wvalid_i && wready_o) begin
        wdq[w_wr_q[2:0]] <= wdata_i; wsq[w_wr_q[2:0]] <= wstrb_i;
        w_wr_q <= w_wr_q + 4'd1;
      end
      if (arvalid_i && arready_o) begin
        arq[ar_wr_q[2:0]] <= araddr_i; ar_wr_q <= ar_wr_q + 4'd1;
      end

Three independent if statements with no relationship between them. Nothing there says an address must arrive before its data, or that a read address cannot be taken while a write is mid-flight. That is not permissiveness in this implementation — it is required:

"The lack of relationship means, for example, that the write data can appear at an interface before the write address for the transaction. This can occur if the write address channel contains more register stages than the write data channel." — IHI 0022H, A3.3.1

A slave that sequenced those three captures would break on a perfectly legal master whose address path happens to be pipelined one stage deeper than its data path. Chapter 20.2 §5 counts how often this module's own master delivered data at or ahead of its address.

The equivalent Wishbone question does not exist. [ADR_O], [DAT_O()], [SEL_O()] and [WE_O] are one context qualified by one [STB_O]; they cannot arrive at different times because they are not separately acknowledged.

7. Where The Complexity Goes When You Do Not Want It

AXI4-Lite is the interesting data point here, because it is AXI with the bursts and the IDs removed — and it still has five channels. The channel separation is not an optional extra layered on top; it is the bottom of the protocol, and dropping everything else does not get rid of it.

// ── THE FIVE CHANNELS, AND WHY THEY ARE SEPARATE STATE ──────────────────
// "Each of the five independent channels consists of a set of information
// signals and VALID and READY signals that provide a two-way handshake
// mechanism."                              (ARM IHI 0022H, A1.2.1)
//
// AXI4-Lite drops bursts and IDs but keeps the channel separation, which
// is the part Module 20 is about. This slave therefore runs AW, W, B, AR
// and R as independent handshakes with their own state.
//
// ── THE DEPENDENCY RULE THIS SLAVE MUST NOT BREAK ───────────────────────
// "VALID signal of the AXI interface sending information must not be
// dependent on the READY signal of the AXI interface receiving that
// information."                            (ARM IHI 0022H, A3.3.1)
//
// For a slave that means BVALID must not wait for BREADY and RVALID must
// not wait for RREADY. Both are raised here the moment the access
// completes, with no reference to the master's ready signals.

That is the header of this module's AXI-Lite slave. Compare it with the Wishbone RAM reused unchanged from Chapter 16.4, which has one [STB_I]/[ACK_O] pair and no other handshake at all.

8. What This Chapter Has Not Established

That either bus is better. Complexity is a cost, and a cost is only meaningful against what it buys. Chapter 20.3 runs one identical workload across both protocols at two slave latencies, and the sign of the difference reverses between the two tables — which is the most useful single fact in this module and the reason a one-number benchmark would have been worthless.