Wishbone · Module 31

"AXI Always Replaces Wishbone"

Always is one problem and treating AXI as a single interface is the bigger one. Five subsystems, their required capabilities, and what a bridge actually costs.

There is no winner column in this chapter. Protocol ranking is not an engineering activity, and any page that produces one has stopped analysing.

Two words are doing the damage, and the second is worse than the first.

1. "Always", And The Bigger Problem

"Always" asserts that one comparison outcome holds across every requirement set. Chapter 31.1 produced three design contexts that reach three different conclusions; a universal quantifier is refuted by one counterexample, and there are three.

"AXI" is the bigger problem, because it names a family. Comparing "B3 Classic" with "AXI" is comparing one specific interface with a set whose members differ from each other more than one of them differs from Wishbone.

Before any comparison can be made, both sides need scoping:

you must name	because otherwise
the Wishbone profile — Classic or pipelined	pipelined has `STALL` and multiple outstanding; Classic has neither
the AXI interface — full, lite, or stream	a lite interface has no bursts and no IDs; a stream interface has no addresses at all

A comparison between B3 Classic and a lite interface is a genuinely close one. A comparison between B3 Classic and a full burst-capable interface is not, and neither result generalises to the other.

2. Compare Capabilities, Not Names

The only comparison that survives scrutiny is a capability list against a requirement list.

capability	what needs it
separate read and write paths	independent read and write flow at once
multiple outstanding transactions	hiding target latency
transaction identity	out-of-order completion
bursts	sustained sequential bandwidth
per-channel backpressure	independent flow control
single-transfer handshake	everything else

B3 Classic supplies the last row and none of the others. That is not a criticism; it is the specification. A subsystem needing rows one through five needs a protocol designed for them, and Chapter 31.2 measured the constraint directly: one outstanding transfer by construction, 41 cycles against 20 on the same eight operations in a pipelined model.

3. Five Subsystems, Requirements Only

No conclusions in this table. Requirements are the input; the reasoning comes after.

subsystem	throughput	outstanding	bursts	latency	area	verification budget	existing IP
A eight control/status peripherals	very low	1	none	irrelevant	tight	days	none
B DRAM path	near memory limit	many	essential	tolerant, pipelined	generous	weeks	vendor controller
C DMA-capable subsystem	moderate	1–2	helpful	moderate	moderate	weeks	own engine
D existing Wishbone IP in an AXI-facing SoC	inherited	inherited	inherited	inherited	moderate	inherited + bridge	substantial, Wishbone
E small educational CPU	very low	1	none	irrelevant	tight	small	none

A and E require nothing beyond a single-transfer handshake with byte lanes. Every additional capability is area and verification surface with no consumer. A single-outstanding protocol is not a compromise here; it is the requirement.

B requires outstanding transactions, identity and bursts. Classic cannot supply them and no topology adds them. This is the row that makes the chapter honest.

C is the interesting one, and Chapter 31.6 measures it: a DMA engine is an ordinary bus master, and whether Classic suffices depends on whether the latency it cannot hide costs you anything at the throughput you need.

D has an answer that is not "pick one" — see below.

4. Replacement Is Not The Only Option

Subsystem D is the case the word always erases entirely. The architecture is frequently:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

AXI-facing SoC  ->  bridge  ->  Wishbone subsystem

Module 29 inspected a repository whose entire purpose is that boundary — ZipCPU/wb2axip, bridges and interconnect between the two families, at commit 2e8d3bc2, Apache-2.0, checked canonical and not archived on 2026-09-22. The architecture in which one protocol meets another through a bridge is common enough to have dedicated open-source projects.

But a bridge moves complexity. It does not erase it, and a review of one asks about all nine of these:

concern	the question
buffering	how deep, and what happens when it fills?
concurrency mismatch	what does a single-outstanding side do with several outstanding requests?
ordering	can responses return out of order, and who reorders?
width conversion	how are partial transfers and byte lanes mapped?
burst decomposition	one burst becomes how many single transfers?
error translation	which error maps to which, and what is lost?
termination capability	does each side observe what the other can assert?
timeout policy	who owns the timer, and what does expiry mean?
verification	the bridge is now the most complex block in the path

Row seven is not hypothetical. Chapter 30.4 measured two individually-conformant endpoints deadlocking because one asserted ERR on 39 clocks into a master with no input to receive it — the specification anticipates it in OBSERVATION 3.35, and a bridge is exactly where that gets resolved or reproduced.

Replacement and integration are different decisions. "Always replaces" forecloses the second one without examining it.

5. What Changes The Answer

The useful skill is knowing which requirement flips a conclusion.

if this changes	the answer moves because
throughput rises past what one outstanding transfer sustains	latency can no longer be hidden; Classic's limit binds
the target becomes slow	outstanding transactions start to matter; with a fast target they may not
substantial Wishbone IP already exists	a bridge may cost less than porting, and the comparison becomes bridge-versus-port
the toolchain generates one family	ecosystem cost enters, and it is real even though it is not technical
area tightens	the protocol with fewer required signals and simpler endpoints is worth something
the verification budget shrinks	the smaller contract is easier to prove

Notice that half of those are not performance. A protocol decision made only on throughput is made on one axis of six.

6. The Design Consequence

Porting working IP for a slogan. Subsystem D's IP is tested, integrated and understood. Replacing its interface discards that and buys capabilities the subsystem does not consume. The bridge may be the cheaper and lower-risk path — and it may not, but that is a comparison somebody has to actually make.

Under-specifying and then discovering row B. The opposite error, and it appears late. A DRAM path built on a single-outstanding contract does not fail a protocol check; it simply never reaches the bandwidth, and the fix is architectural rather than a tuning exercise.

Treating a bridge as free. The nine rows above are where the complexity went. It did not evaporate at the boundary.

7. The Replacement Statement


Instead of	"AXI always replaces Wishbone."
Say	"Neither name is a single interface, so the comparison needs both scoped — B3 Classic or pipelined, and which AXI interface. Then list the capabilities this subsystem requires. A path needing multiple outstanding transactions, identity and bursts is not served by B3 Classic; eight control registers do not need any of them; and where Wishbone IP already exists, a bridge is a third option whose cost is buffering, ordering, error translation and verification rather than zero."

Instead of

"AXI always replaces Wishbone."

Say

"Neither name is a single interface, so the comparison needs both scoped — B3 Classic or pipelined, and which AXI interface. Then list the capabilities this subsystem requires. A path needing multiple outstanding transactions, identity and bursts is not served by B3 Classic; eight control registers do not need any of them; and where Wishbone IP already exists, a bridge is a third option whose cost is buffering, ordering, error translation and verification rather than zero."

8. What To Carry Forward

"Always" is refuted by one counterexample, and Chapter 31.1 supplies three.
Scope both sides. A family name is not an interface.
Compare capabilities against requirements, never names against names.
Say plainly where Classic does not fit. Subsystem B is that row, and omitting it would make the rest advocacy.
Replacement is not the only architecture. Bridges exist, have dedicated projects, and cost nine specific things.
Half the deciding factors are not performance.

Chapter 31.5 turns to the one misconception in this module that a specification can settle directly.

Continue learning

Standards & specifications

Governing standard: Wishbone SoC Interconnection Architecture (OpenCores)(opens OpenCores in a new tab)
Defines the Wishbone signal set, the bus cycles built from it and the interface rules a portable IP core must follow. It deliberately leaves interconnect topology, address map and arbitration policy to the integrator, so those are system decisions rather than requirements of the specification.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the Wishbone curriculum.