Wishbone Architecture Overview

Chapter 2.7 ended with a working fabric and nine unwritten rules — a system that functioned and that nobody else could connect a block to, because everything a block must obey lived in prose rather than in a specification.

Module 3 is what a published specification looks like when it answers that. It is architecture-first on purpose: the aim is that you can draw a Wishbone system and say what each part is responsible for, before you can recite a signal table.

What are the architectural pieces of a Wishbone system, and how do they relate?

1. Four Roles, Two of Which Are Interfaces

Wishbone defines four architectural entities, and the distinction between them is the first thing worth getting right.

Read the right-hand column, because it carries the architecture. MASTER and SLAVE are interfaces: the specification says precisely what signals they present and what rules govern them. INTERCON and SYSCON are modules: the specification says what job they do and leaves how they do it to the integrator.

That asymmetry is the whole design, and it is Chapter 1.7's scope decision arriving with names attached. Standardise the endpoints so independently written blocks compose; leave the fabric open so one block serves systems of very different shapes.

One correction to a common picture, worth making immediately. MASTER does not mean CPU and SLAVE does not mean peripheral. The definitions are about generating versus receiving bus cycles — nothing else. A DMA engine is a MASTER on its memory port and a SLAVE on its configuration port, exactly as Chapter 2.1 established for the generic case, and Wishbone's definitions make that explicit rather than incidental.

2. The Naming Convention, and Why It Confuses People Once

Wishbone signal names carry an _I or _O suffix, and the suffix is relative to the interface it appears on.

That means one physical wire has two names:

The row that catches everybody is the data pair. DAT_O on a master and DAT_O on a slave are different wires going in opposite directions. There is no single "DAT_O net" in a Wishbone system; there is a master-to-slave data path and a slave-to-master data path, and each is an output at one end and an input at the other.

Why the convention is worth the initial confusion: it means a module's port list reads correctly from inside that module, with no need to know what it is connected to. That is the same reuse property Chapter 1.2 argued for with local offsets — a block should be describable without reference to its system.

Engineering interpretation, not a rule: the practical habit is to say the direction out loud when reading a Wishbone port list — "address, master output" rather than "ADR_O" — until the suffix stops needing translation.

3. What Crosses the Interface, by Category

Module 3 does not give each signal its own treatment; Module 4 owns that. What matters here is the categories and who owns them, which is Chapter 2.1's ownership table with Wishbone names attached.

Master-originated, travelling toward the slave:

• an address, ADR_O;
• write data, DAT_O;
• a direction, WE_O — asserted for a write;
• byte-lane selects, SEL_O;
• two distinct qualifiers, CYC_O and STB_O, which Chapter 3.2 argues are the most important architectural feature of the interface.

Slave-originated, travelling back toward the master:

• read data, DAT_O on the slave;
• a termination: one of ACK_O, ERR_O or RTY_O.

System-wide, from SYSCON:

• CLK_I and RST_I, to every interface.

4. RTL 1 — The Architectural Shell

Before any behaviour, here is what the two interfaces look like as port lists. This module does nothing except connect a master to a slave point-to-point, which is the simplest Wishbone system the specification recognises.

// ─────────────────────────────────────────────────────────────────────────
// wb_p2p — the smallest complete Wishbone system: one MASTER interface
// wired directly to one SLAVE interface, with no INTERCON between them.
//
// PURPOSE. Make the architecture concrete as wiring before any behaviour.
// Every port below is a real Wishbone Classic signal; this module shows
// which side owns each one and which wire pairs with which.
//
// WHAT THIS IS NOT. It is not a handshake tutorial. The rules governing
// when these signals may change and how a transfer completes are Module 5's
// subject, and each signal's full semantics are Module 4's.
//
// Reset is SYNCHRONOUS and ACTIVE HIGH throughout Module 3, per RULE 2.30
// (active-high logic) and RULE 3.00 (initialise on the rising CLK_I edge
// following assertion of RST_I). This differs from Module 2's convention
// and the difference is deliberate.
// ─────────────────────────────────────────────────────────────────────────
module wb_p2p #(
  parameter int unsigned AW = 32,   // address width
  parameter int unsigned DW = 32    // data width
) (
  // ── From SYSCON, to both interfaces ──────────────────────────────────
  input  logic            clk_i,
  input  logic            rst_i,          // synchronous, ACTIVE HIGH

  // ── MASTER-side ports, named from the MASTER's perspective ───────────
  //    Everything the master OWNS is an input to this module, because the
  //    master is outside it driving in.
  input  logic [AW-1:0]   m_adr_o,        // master drives the address
  input  logic [DW-1:0]   m_dat_o,        // master drives WRITE data
  input  logic            m_we_o,         // master drives direction
  input  logic [DW/8-1:0] m_sel_o,        // master drives byte selects
  input  logic            m_stb_o,        // master qualifies the transfer
  input  logic            m_cyc_o,        // master frames the bus cycle
  output logic [DW-1:0]   m_dat_i,        // master RECEIVES read data
  output logic            m_ack_i,        // master RECEIVES termination
  output logic            m_err_i,
  output logic            m_rty_i,

  // ── SLAVE-side ports, named from the SLAVE's perspective ─────────────
  output logic [AW-1:0]   s_adr_i,        // slave RECEIVES the address
  output logic [DW-1:0]   s_dat_i,        // slave RECEIVES write data
  output logic            s_we_i,
  output logic [DW/8-1:0] s_sel_i,
  output logic            s_stb_i,
  output logic            s_cyc_i,
  input  logic [DW-1:0]   s_dat_o,        // slave DRIVES read data
  input  logic            s_ack_o,        // slave DRIVES termination
  input  logic            s_err_o,
  input  logic            s_rty_o
);
  // ── Point-to-point interconnection is literally wires. There is no
  //    decode because there is only one slave, and no arbitration because
  //    there is only one master. The specification recognises this as a
  //    topology in its own right: "An interconnection system that supports
  //    a single WISHBONE MASTER and a single WISHBONE SLAVE interface."
  //
  //    Note what the suffixes do here: m_adr_o connects to s_adr_i, and
  //    they are the same wire under two names. m_dat_o and s_dat_o are
  //    NOT the same wire — they travel in opposite directions.

  // Request path: master → slave
  assign s_adr_i = m_adr_o;
  assign s_dat_i = m_dat_o;
  assign s_we_i  = m_we_o;
  assign s_sel_i = m_sel_o;
  assign s_stb_i = m_stb_o;
  assign s_cyc_i = m_cyc_o;

  // Response path: slave → master
  assign m_dat_i = s_dat_o;
  assign m_ack_i = s_ack_o;
  assign m_err_i = s_err_o;
  assign m_rty_i = s_rty_o;
endmodule

Reading this module

Purpose. Show that an interconnection can be nothing and still be a legitimate Wishbone system. Everything an INTERCON does in a larger design — decode, routing, arbitration — is absent here because a single master and a single slave make all of it unnecessary.

Ownership, read off the port directions. Six signals flow left to right and four flow right to left, and no signal is driven from both ends. That is Chapter 2.1's ownership table, now enforced by the port list rather than by a convention.

The naming trap, made visible. m_dat_o connects to s_dat_i, and s_dat_o connects to m_dat_i. Four port names, two wires, two directions. A reader who assumes DAT_O is one net will mis-wire this the first time.

No combinational or sequential behaviour at all. There is nothing to decide. clk_i and rst_i pass through to both endpoints and are used by neither in this module — they are used by the master and slave that connect to it.

Deliberate simplifications. No tag signals (TGA, TGC, TGD), no LOCK_O. Those are optional in the specification and none of Module 3's material needs them.

How it could fail. Cross m_dat_o to m_dat_i and you have connected the master's write data to its own read-data input — a plausible-looking wiring error that produces reads returning whatever was last written. Omit s_cyc_i and the slave sees strobes with no cycle framing, which RULE 3.35 makes meaningless: termination must be generated in response to the logical AND of CYC_I and STB_I.

Scaling. Add a second slave and every assign on the request path needs a decode in front of it, and every assign on the response path needs a multiplexer behind it. That is Chapter 3.5, and it is exactly the structure Chapter 2.2 and Chapter 2.3 built generically.

5. Topologies — What the Specification Names

The specification names four interconnection arrangements and describes each. This is the clearest evidence of the scope decision from Section 1.

The specification is explicit that arbitration methodology is the integrator's, naming priority and round-robin as examples of choices the designer may make. That is Chapter 2.6's subject and Module 17's, and Wishbone deliberately does not decide it.

The architectural consequence, stated plainly: a MASTER interface and a SLAVE interface are identical across all four topologies. Only the INTERCON changes. That is what lets one GPIO core serve a two-block FPGA design and a crossbar SoC without modification — the portability claim from Chapter 1.7, now traceable to a specific structural decision.

6. Failure Modes at the Architecture Level

These are integration faults rather than protocol faults — they occur before any handshake rule is exercised.

Symptom: reads return the value most recently written, regardless of address.

Candidate causes. The master's DAT_O has been wired to its own DAT_I, either directly or through an INTERCON that treats "the data bus" as one net.

Discriminating evidence. Write a distinctive value, then read a different address. If the write value comes back, the read path is looped to the write path rather than reaching any slave.

Likely RTL location. The interconnection's data wiring, not any endpoint.

Symptom: a slave responds to every transfer in the system.

Candidate causes. The slave's STB_I is driven from the master's STB_O directly rather than from a decoded, per-slave strobe.

Discriminating evidence. Probe each slave's STB_I on an access aimed elsewhere. A slave whose STB_I asserts for another slave's address is being given an undecoded strobe.

Likely RTL location. The INTERCON's request distribution — Chapter 3.5 is where this is built correctly.

Symptom: a slave works point-to-point and misbehaves once an INTERCON is added.

Candidate causes. The slave decodes the full system address internally rather than a local offset, so it hits at addresses the integrator did not intend — or, worse, hits correctly only in the system it was written for.

Discriminating evidence. Read the slave's RTL for a comparison against an absolute address. Its presence is conclusive.

Likely RTL location. Inside the slave, which is the wrong place for it — Chapter 2.2 §9 is the argument.

Symptom: the interface behaves correctly after configuration and wrongly after a warm reset.

Candidate causes. A block built against Module 2's asynchronous active-low convention connected to a Wishbone RST_I, which is synchronous and active high. The block is either never reset, or reset on the wrong polarity.

Discriminating evidence. Capture rst_i and one internal register at reset assertion. A block holding non-zero state while rst_i is high was never reset.

Likely RTL location. The endpoint's reset branch. This is the most likely mistake a reader carries out of Module 2, which is why it has its own callout in Section 3.

7. Common Mistakes

"MASTER means CPU and SLAVE means peripheral."

Wrong mental model: the roles describe what kind of block something is.

Concrete bug: a DMA engine designed with a single Wishbone port, because its author believed it had to choose one role — so there is no way for the CPU to configure it.

Observable evidence: an integration where the DMA engine's registers are unreachable.

Correct model: the specification's definitions are about generating versus receiving bus cycles, and they apply per interface. A DMA engine has a MASTER interface and a SLAVE interface, both active.

"DAT_O is the data bus."

Wrong mental model: one bidirectional data path with one name.

Concrete bug: the master's write-data output wired to its own read-data input, or a slave's read data driven onto the write-data net.

Observable evidence: reads that return the last value written, independent of address.

Correct model: DAT_O and DAT_I are separate unidirectional paths, and the suffix is relative to the interface. On a master, DAT_O is write data; on a slave, DAT_O is read data. Same name, opposite directions, different wires.

"The interconnect is part of the protocol."

Wrong mental model: adopting Wishbone determines how blocks are connected.

Concrete bug: an integrator looking in the specification for the decode structure, the arbitration policy, or the address map, and concluding the document is incomplete.

Observable evidence: an undocumented address map that everyone assumed was inherited.

Correct model: MASTER and SLAVE are specified interfaces; INTERCON is a module defined by its job. The specification names four topologies precisely because it does not mandate one, and it states that arbitration methodology is the end user's choice.

"A slave decides whether a transfer is for it."

Wrong mental model: every slave watches the address bus and recognises its own.

Concrete bug: a slave containing its own base address, which then cannot be instantiated twice or relocated, and which answers at unintended addresses if its comparison is incomplete.

Observable evidence: adding a second instance of the peripheral requires editing the peripheral.

Correct model: selection is the INTERCON's job. The slave receives a strobe that has already been decoded and interprets a local offset. Chapter 3.4 builds a slave that does this correctly.

8. Interview Reasoning

9. Understanding Check

10. What's Next

The architecture is now drawable: two specified interfaces, two modules defined by their jobs, four named topologies, and a scope boundary that puts decode, arbitration and the address map on the integrator's side of the line.

What the picture does not yet give is a way to reason about a transfer without consulting a signal table. And there is one feature in Section 3's list that a reader arriving from Module 2 will almost certainly misread: Wishbone has two master-side qualifiers where the generic interface had one.

What compact mental model lets an engineer reason about a Wishbone transfer — and why is "Wishbone is valid/ready with different names" a genuinely wrong description rather than a harmless simplification?

Chapter 3.2 — The Wishbone Mental Model answers both. The full path is on the Wishbone curriculum index.