Learning Advantages

"Wishbone is a better bus to learn on" is a claim about people, not about silicon. No testbench can settle it, and every other chapter in this curriculum settles things with testbenches.

So this chapter splits the question: here is the part that was counted, and here — labelled as such — is the part that is a judgement.

1. What Was Counted

Two pairs of modules, each pair doing the same job, written by the same author in the same style in the same session, differing only in 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

One number in there is worth defending and one is nearly worthless, and the script says which is which:

    THE ROW THAT MATTERS IS handshake pairs.
    A Wishbone slave sequences ONE. An AXI4-Lite slave
    sequences FIVE, and they are independent, which is the
    whole reason the protocol can overlap work at all.
    Chapter 20.3 measured what that buys and what it costs.

    THE ROW THAT MATTERS LEAST IS code lines, and it is
    published anyway so that nobody has to take the claim on
    trust. Comment density and coding style dominate it.

    WHAT IS NOT COUNTED HERE, because it cannot be:
      how long a learner takes to understand either one
      how many mistakes a first attempt contains
      whether reading AXI first would have been easier
    Chapter 20.4 states those as a judgement and names its
    assumptions rather than pretending to have measured them.

2. Why handshake pairs Is The Honest Metric

Because it counts what a designer has to hold in their head simultaneously.

A Wishbone slave has one question to answer: is [CYC_I] && [STB_I] asserted, and am I ready? An AXI4-Lite slave has five independent handshakes, and — crucially — they are not synchronised with each other. Write data may arrive before its address. A response may be waiting while a new address is accepted. Each of those is a separate piece of state.

It is not five times harder. It is one idea learned once and then instantiated five times, which is why Chapter 20.2 spends its first section showing that the two handshakes are the same mechanism. But it is five places to get the bookkeeping wrong instead of one, and §5 is what that looks like in practice.

3. What The Specifications Ask Of A First Slave

Counted from the two documents this session:

RULE 3.40 is the most teaching-friendly sentence in either document. It tells a beginner exactly which five signals constitute a master, and everything else is optional. There is nothing comparable in IHI 0022H — not because it is worse written, but because a protocol with five independent channels has no meaningful five-signal subset.

4. What A First Slave Actually Has To Do

The clearest way to see the difference is to write the smallest useful slave on each bus and compare what you had to think about.

On Wishbone, the whole request-tracking mechanism is this:

  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;

Three assignments. A request exists when CYC_I and STB_I are both high; it is ready when it has waited long enough; the answer is ACK_O. A beginner who writes those three lines has a conformant slave, and RULE 3.40 told them exactly which five signals a master needs to talk to it.

On AXI4-Lite, the equivalent is the three queues and six pointers in Chapter 20.1 §5, plus a decision the Wishbone version never had to make: how many requests will this slave accept before it stalls? That is ODEPTH, it has no Wishbone counterpart, and getting it wrong is invisible until something is slow.

Three questions a first AXI slave must answer that a first Wishbone slave never encounters:

1. When do I raise BVALID? Not when BREADY arrives — A3.3.1 forbids the dependency. A beginner's instinct ("wait until they're ready, then tell them") is a protocol violation, and it is the only defect in this module a conformance checker catches.
2. What if write data arrives before its address? Legal, and A3.3.1 gives it as an example. A slave that assumes otherwise passes every bench test.
3. What order do my responses come back in? For one slave, in order. Across slaves or IDs, A6.1 says no guarantee — and §5 is what happens when a master assumes otherwise.

None of the three has a Wishbone equivalent, because all three are consequences of the channels being independent.

5. A Mistake I Actually Made Building This Module

This is the most useful evidence in the chapter and it is first-person.

The AXI-Lite master built for Chapter 20.3 originally tracked its in-flight transactions in one queue, popped by whichever response arrived first. It looked correct, it elaborated cleanly, and it passed every check in SIM A through SIM I.

SIM J caught it — the deep-outstanding rig returned 0x44441111 for a read of address 0x023, which is the value of a different address entirely.

The bug: write responses and read data return on independent channels, so they do not come back in issue order. A single queue attributes a read's data to a write's slot. The fix was two queues:

  // TWO in-flight queues, not one.
  //
  // A single queue popped by whichever response arrives first assumes B
  // and R come back in issue order. They do not: the write response
  // channel and the read data channel are independent, and the
  // specification says so - ordering is not guaranteed between "Read and
  // write transactions" (A6.1). A one-queue master therefore attributes
  // a read's data to a write's slot and reports the wrong value for an
  // index it never read.
  //
  // That is a real defect and it is the FIRST thing an engineer gets
  // wrong when moving from a coupled protocol to a decoupled one: the
  // bookkeeping that Wishbone did not need is now the master's job, and
  // there is nothing in the protocol to remind you.
  logic [4:0] wfifo_idx [0:7];

It also took a particular kind of test to find. SIM A through SIM I each check one rig against its own expectations. SIM J is the only one that checks four rigs against each other, and the defect was invisible to every test that did not have a second opinion to compare against.

6. The Judgement, And Its Assumptions

THIS IS A TEACHING JUDGEMENT, NOT A MEASUREMENT. Stated plainly so it can be disagreed with:

For a first bus, Wishbone gets a learner to a working, correct, complete master-and-slave pair faster, and makes the failure modes visible sooner.

It rests on these assumptions, and if you reject one, the judgement weakens:

1. The goal is understanding bus mechanics, not employability in the next six months.
2. The learner will build something, not only read about it. The argument is about writing RTL, and a reader who only ever reads specifications gets much less from it.
3. Getting to a working thing early matters. If a learner is content to spend three weeks before anything runs, the advantage shrinks a lot.
4. The five-channel structure is the hard part. §2's count says so; if you think address decoding or arbitration dominates the difficulty, both buses look similar and the judgement is close to void.
5. RULE 3.40's five-signal minimum is genuinely usable. It is, in this curriculum — Chapter 16.1 onward builds real masters from it.

What would change my mind: a learner cohort reaching a working AXI-Lite slave in comparable time to a Wishbone slave; or evidence that the concepts unique to AXI (outstanding transactions, ordering, IDs) are better learned early than late. Neither has been measured here, by me or by anyone I am citing.

7. What Wishbone Does Not Teach

Being honest about this is the price of the judgement above. A learner who only ever uses Wishbone has never had to think about:

Every one of those is load-bearing in a modern SoC. A Wishbone-only education is incomplete in a way that matters, and Chapter 20.3 §6 showed one of them costing real clocks.

8. AXI's Pedagogical Advantage, Unhedged

It is what you will actually meet at work.

That is not a small point and it should not be buried at the bottom of a comparison written by a Wishbone curriculum. A learner who spends their time on AXI is learning the interface they will be handed on their first day, in the vocabulary their colleagues use, with tooling and verification IP that exist. A learner who spends their time on Wishbone has to make the translation themselves.

The counter-argument — which is the one this curriculum acts on — is that the translation is cheap once the mechanics are understood, and Chapter 20.2 §1 is the evidence: the handshake is the same idea in both, described in nearly the same words. What transfers is the thinking; what does not transfer is the signal names, and those are the easy part.

But "cheap" is a judgement too, and it rests on assumption 2 in §6.

9. The Defensible Summary