"Wishbone Is Obsolete"

Thirty modules of evidence end here, with a different skill: taking apart a sentence that sounds like an engineering conclusion and is not one.

A misconception is often a locally true observation promoted into a universal rule.

That is the whole module. Somebody saw something real, compressed it, and dropped the conditions that made it true.

1. Obsolete For What?

"Wishbone is obsolete" is not one claim. It is at least eight, and they need entirely different evidence:

The last row is the only one that can inform a design decision, and it is the only one that never mentions the word obsolete.

2. Why The Claim Sounds Plausible

It is not invented. Three real observations produce it, and each is true in its own scope:

The vendor toolchains standardised elsewhere. If your FPGA flow's IP generator emits AXI interfaces, every block you instantiate speaks AXI, and a Wishbone block is the one that needs a bridge. That is a genuine, local, ecosystem fact.

The specification is old. B3 dates from the 2000s and has not accumulated the annual revisions a commercially-backed standard does. Stability reads as abandonment if you expect churn.

Classic is genuinely narrow. Chapter 30.4 measured the consequence: one transfer at a time, no native transaction IDs, no standardised burst decomposition. For a DRAM path that is disqualifying, and somebody who has hit that wall has learned something true.

None of the three supports "obsolete" as a universal. They support "in my ecosystem, for my subsystem, I chose otherwise" — which nobody would argue with.

3. Current Source, With Dates

We inspected five repositories fresh on 2026-09-22, checked their fork and archive status against the GitHub API the same day, and record exactly what that supports.

What this supports: at the inspected commits, these five repositories contain Wishbone interfaces, and three of them received pushes within the last month of the inspection date.

What this does not support: that Wishbone is widely used, popular, an industry standard, or present in commercial silicon. Five repositories are five repositories. Module 29 made the same point at length and it has not become less true.

Two honest caveats. wb2axip and caravel have both been pushed since the commits we read, so our architectural claims are scoped to those commits and not to current HEAD. And picorv32 is archived — its Wishbone wrapper is a fixed historical artifact, which makes it better evidence for a case study and worse evidence for "actively maintained".

4. Age Is Not Fitness

The engineering content of "obsolete" is supposed to be unfit. Fitness is a comparison between what a protocol provides and what a design requires — and nothing in that comparison has a date in it.

What Classic provides, established across this curriculum:

• a synchronous handshake with unbounded, slave-controlled latency (Module 9);
• one outstanding transfer, by construction (Chapter 30.4);
• optional ERR and RTY, with no mandated master response;
• byte lanes (Module 13);
• block and read-modify-write structures (Module 8);
• nothing about topology, arbitration, timeouts or address maps — all yours.

That last line is the important one. Most of what people evaluate when they evaluate "a bus" is not in this specification at all, which is why the same protocol appears in a two-module interconnect and in a parameterised crossbar with a starvation timeout.

5. Three Contexts, Three Answers

The same protocol, three designs, three conclusions. No winner column, because there is no winner without requirements.

A. A small FPGA control subsystem. Eight status and configuration registers, a UART, a timer. Bandwidth: a few transfers per millisecond. Latency: irrelevant. Concurrency: none. Verification budget: days.

Required capabilities: address a handful of registers, byte lanes, an error response for unmapped accesses. Nothing else. Classic supplies all of it, an interconnect here is two combinational modules, and every additional protocol feature is area and verification surface with no consumer. Conclusion: Classic fits, and the reason is the requirements list, not the protocol's age.

B. A high-throughput DRAM path. Sustained bandwidth near the memory's limit, many outstanding requests, reordering tolerated, bursts essential.

Required capabilities: multiple outstanding transactions with identity, burst decomposition, independent read and write flow control. Classic provides none of these, and no topology fixes that — Chapter 30.4 measured max outstanding as 1 by construction, not by implementation quality. Conclusion: choose a protocol designed for it, or adopt a pipelined profile and accept that you are no longer in the contract this curriculum taught.

C. An open educational or research SoC. A small RISC-V core, a memory, a few peripherals, read by people learning the system.

Required capabilities: a contract small enough to hold in your head, and observable enough to teach from. Classic's narrowness becomes the feature — Module 29 traced a whole SoC's bus path through two combinational modules and a two-bit decode. Conclusion: fits, for a reason that has nothing to do with performance.

Notice that B is a real limitation, stated plainly. A chapter that could not produce case B would be advocacy, not analysis.

6. The Design Consequence Of Believing It

Two failure modes, and the second is more common:

Rejecting a fit protocol on vibes. Context A implemented over a protocol chosen for context B pays area, verification effort and integration complexity for capabilities nothing in the design consumes.

Accepting an unfit one for the same reason. "It is modern" is exactly as empty as "it is obsolete", and the design that needs case B's capabilities will not get them from a protocol chosen by reputation either.

Both errors come from the same place: a decision made about the label rather than about the requirements.

7. The Replacement Statement

Longer, and it can be argued with. That is the point.

8. What To Carry Forward

• Ask "for what?" Eight claims hide in one word and they need different evidence.
• Match the evidence to the claim type. A specification rule cannot establish adoption; repository activity cannot establish timing semantics.
• Date every ecosystem claim, and scope it to the revision you read.
• Five repositories prove five repositories.
• Age is not fitness. Fitness is required capabilities against provided ones.
• State the case where it does not fit, or you are not analysing, you are advocating.

Chapter 31.2 takes a word that hides even more claims than this one.