Why Wishbone Was Created

Six chapters have produced every ingredient of an argument without once assembling it. This one assembles it, and it closes Module 1.

The aim is not to describe Wishbone. It is to reach it — to arrive at a set of requirements sharp enough that the design becomes the obvious response, and then to be equally clear about what it refuses to do.

1. The Requirements, Collected

Every requirement below was derived in an earlier chapter from engineering pressure. None of them came from a specification.

Read that list as a design brief and two things stand out.

It is unusually specific about the interface and silent about the system. Every row constrains what crosses the boundary between two blocks. Not one row constrains how many blocks there are, where they live, how fast the result runs, or how good any of them is.

Three rows are about adoption rather than about signals. Checkability, agreement, and freedom from legal review are properties of the document, not of the hardware. A specification that satisfied only the technical rows would be a good design nobody could use.

2. The Scope Decision

Before any signal, the design has to decide what it is responsible for. This is the decision that shapes everything else.

The left column must be identical across blocks or nothing composes. Two blocks that disagree about what a signal means, or about when the address may change, cannot exchange a transfer — and Chapter 1.3 showed that both can be individually reasonable while disagreeing.

The right column must differ between systems or the specification is unusable. Chapter 1.2 showed the map being driven by the system's own needs. Chapter 1.5 showed the fabric being driven by target count, critical path and device family. A specification that fixed either would serve one system shape and exclude the rest.

That is the whole scope decision, and it is why the specification is called an interconnection architecture for portable IP cores rather than a system architecture. The portability is the product. Everything the specification declines to decide is something that would have cost portability.

3. What the Interface Has to Carry

With the scope settled, the contents follow almost mechanically from Chapter 1.1's derivation. This section deliberately names no signals — Module 4 owns the signal table, and reading it before the requirements are clear is exactly the mistake Module 1 exists to prevent.

Seven of the eight are unsurprising. The sixth deserves a sentence, because it is the one that is easy to overlook and impossible to omit.

A request has to be qualified. Signals carrying an address and data are always driving something — a bus does not go blank between transfers. Something separate has to distinguish these values are a request you must act on from these values are whatever was left on the wires. Without it, a target either acts on garbage or has to infer intent from a change in the address, which is not a signal a synchronous design can rely on.

Two more properties follow from the requirements rather than from the list.

The interface is synchronous, referenced to a common clock. Every transfer is defined in terms of clock edges rather than in terms of propagation delays or level sensitivity. This is not an aesthetic choice: asynchronous handshakes are hard to close timing on, hard to verify, and hard to port between devices. For a specification whose users are largely FPGA projects with a single system clock, a synchronous definition is the one that makes a transfer's rules checkable by a simulator and closable by a timing tool.

Reset is part of the contract. Chapter 1.3 §3 showed three blocks arriving with three reset conventions, and Chapter 1.5 §5 showed why that fails on an FPGA specifically — the block comes up correct from the bitstream and fails only after a warm restart. A specification that fixed every data signal and left reset to the author would have standardised the easy half.

4. Why the Fabric Is Left Open

The specification names several interconnection topologies rather than mandating one: point-to-point, many-to-many — the classic shared bus — hierarchical arrangements, and switched fabrics such as crossbar switches.

This is the scope decision applied to the hardest case, and it is worth seeing why each of those topologies is genuinely necessary to somebody.

Point-to-point is one initiator and one target with no decode and no arbitration. Chapter 1.1 §6 argued this is the right answer for a core and a tightly-coupled accelerator, and it remains so.

A shared arrangement is the small SoC of Chapter 1.5: one decoder, one response multiplexer, cheap until the target count pushes the multiplexer past the device's LUT width.

A hierarchy is that chapter's own answer to the multiplexer problem — decode to a group, then within it — and it is why real address maps cluster peripherals into a contiguous band.

A crossbar lets two initiators reach two different targets at once, which the shared arrangement cannot. It costs area that grows with the product of the counts, so it is right exactly when the concurrency is worth it.

A specification that mandated any one of these would have excluded the others, and with them most of its intended users. The consequence is stated honestly rather than hidden: conformance tells you a block will connect; it tells you nothing about what the system will do. Throughput, latency, arbitration fairness and concurrency are all properties of a fabric the specification declined to design.

5. Why It Had To Be Unencumbered

The technical requirements would be satisfied by a good proprietary specification. Three of the twelve rows in Section 1 would not.

Chapter 1.6 §3 established the documented position: the standard is not copyrighted, is in the public domain, and documents prior art specifically so its techniques cannot easily be preempted by a third-party patent.

Why that is an engineering requirement and not a commercial preference. The intended adopters — volunteer projects, individual authors, small teams, university groups — cannot evaluate or insure legal risk. A specification whose patent position is uncertain is not merely expensive for them; it is unusable, because the cost of finding out is larger than the whole project.

And there is a second-order effect worth naming. A standard that some authors can adopt and others cannot does not produce a partial ecosystem; it produces a fragmented one, which Chapter 1.4 §6 identified as the worst available outcome — the coordination cost of a standard with none of the reuse. Universal adoptability is what makes the m + n collapse actually happen rather than remaining theoretical.

6. What Wishbone Deliberately Does Not Do

A chapter that only assembled the case for something would be advocacy. This list is what a reader must not expect, and every item is a direct consequence of the scope decision rather than a shortcoming.

It does not define your address map. Region sizes, base addresses, decode and unmapped behaviour are yours in every system. Chapter 1.2 is the whole of that contract and none of it is inherited.

It does not define your topology, arbitration or performance. Section 4. Two conformant systems can differ by an order of magnitude in throughput.

It does not make a block correct. Conformance is about the interface. A conforming peripheral can still have an unsafe clock-domain crossing, an undocumented erratum, or no verification at all — Chapter 1.4 §4 is the honest account.

It does not give you semantic agreement. Two blocks can exchange transfers flawlessly and disagree about what a register means.

It does not carry interrupts. Chapter 1.1 §5 noted this: a peripheral needing to interrupt drives an ordinary output that the integrator routes to an interrupt controller, which is itself a target the core reads. The bus carries accesses, not events.

It does not remove the cost of generality. A standard interface carries signals a given block does not need and imposes a handshake a trivially fast block would not require. For one core and one accelerator, a private interface is still smaller and faster.

And it is not a claim to be the best interconnect. Whether Wishbone or AXI or APB suits a given system depends on that system's throughput, concurrency and ecosystem — Module 20 compares Wishbone with AXI, Module 21 with APB, and Module 22 covers performance. Each needs evidence this chapter does not have, and an adjective is not an argument.

7. What the Specification Actually Is

Stated plainly and factually, for reference rather than for argument.

The document is WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores. It states that it exists to guarantee compatibility between compliant IP cores and to improve cooperation among different users and suppliers, and to provide an open, freely usable interconnect architecture for IP cores.

It defines a synchronous interface between an initiator and a target, referenced to a common clock, carrying the information in Section 3's table, with rules governing when each item is valid and how a transfer completes. It supports the topologies in Section 4. It is in the public domain.

Revisions include B3, published in 2002, and B4, published in 2010, which added a pipelined mode alongside the existing cycle types. The details of the revisions, the signals and the cycle types are not this chapter's subject — Module 3 lays out the architecture, Module 4 the signals, Module 5 the handshake, and Modules 6 through 15 the cycles and their variants.

8. Common Misconceptions

"Wishbone is an open-source bus."

The wrong model: the phrase is a description of what it is.

What it costs: it collapses three separate facts into a slogan and teaches nothing. It also invites the assumption that "open source" means somebody maintains it, reviews it, or guarantees it.

The corrected model: it is a specification — not source — that is in the public domain — not merely free of charge — and it defines an interface — not a system. All three distinctions carry engineering consequences, and Sections 2, 5 and 6 are those consequences.

"Adopting Wishbone settles how my SoC is built."

The wrong model: a bus standard is a system architecture.

What it costs: an undocumented address map that everyone assumed was inherited, and an expectation of performance the specification never offered.

The corrected model: Section 6. The map, topology, arbitration and performance are yours in every system, and the specification's refusal to fix them is what makes it portable.

"A simple bus must be a slow bus."

The wrong model: fewer features implies worse performance, so simplicity is a compromise.

What it costs: dismissing an interconnect without measuring, and — more often — adopting a complex one for a system of low-rate control peripherals where none of its complexity is ever exercised.

The corrected model: these are separate questions. Interface complexity determines what can be expressed — outstanding transactions, out-of-order completion, multiple channels. Achieved performance depends on the fabric, the clock and the workload. A system of register-mapped control peripherals exercises none of the mechanisms a complex interconnect provides, and Module 22 is where this is measured rather than asserted.

"The specification is old, so it is behind."

The wrong model: revision date is a proxy for fitness.

What it costs: the same error as calling it obsolete — an adjective substituted for a comparison.

The corrected model: an interface specification is a contract, and a stable contract is a feature rather than a symptom. The useful questions are whether it expresses what your system needs and whether the ecosystem you are drawing IP from uses it. Both have real answers; neither is settled by a date.

9. Interview Reasoning

10. Understanding Check

11. What's Next

Module 1 is complete, and its argument is one chain.

A CPU reaches hardware only by addressed reads and writes, so peripherals expose locations. Those locations need names, which is memory-mapped I/O, and the map answers where without touching how. Private interfaces answer how incompatibly and multiply as they go, starving the verification that would have caught it. Reuse needs a contract something can check, not source somebody can read. A single FPGA with six peripherals makes all of it concrete — exhaustive decode, a response multiplexer on the critical path, four different latencies and a completion signal that turns out to be what keeps the design modifiable. An ecosystem of independent authors has no architect and can only standardise by agreement, which is why the convention it adopted had to be unencumbered as well as good.

Wishbone is that convention, scoped to the interface and deliberately silent about the system.

What Module 1 has not done is define any of it. The vocabulary every on-chip bus shares — initiators and targets, address spaces, transfers, the control signals that frame them, transactions as the unit of work, and what it means for a resource to be shared — has been used informally throughout and defined nowhere.

Before Wishbone's own architecture can be laid out, what does every on-chip bus mean by a master, a slave, a transaction and a shared resource — and which of those ideas are universal rather than Wishbone's?

Module 2 — On-Chip Bus Fundamentals establishes that vocabulary, and Module 3 then lays out Wishbone's architecture on top of it. Bold rather than linked is this track's convention for chapters that have not shipped yet. The full path is on the Wishbone curriculum index.