Research Platforms

This is the chapter most likely to be written badly, because the temptation is to call a repository a "research platform" on the strength of a university address and move on.

So the standard here is stricter, and the first thing to say is what we are not claiming.

1. What We Inspected, And What We Are Claiming

What we claim: the inspected source defines a Wishbone slave boundary between a management SoC and a user project area, and gates every master-side wire of that boundary with a power-domain enable.

What we do not claim: anything about how many designs used it, what any of them achieved, whether it constitutes "industry", or that Wishbone caused any research result. Those would each need different evidence, and we did not gather it.

2. The Boundary Is Nine Wires

    // Wishbone Slave ports (WB MI A)
    input wb_clk_i,
    input wb_rst_i,
    input wbs_stb_i,
    input wbs_cyc_i,
    input wbs_we_i,
    input [3:0] wbs_sel_i,
    input [31:0] wbs_dat_i,
    input [31:0] wbs_adr_i,
    output wbs_ack_o,
    output [31:0] wbs_dat_o,

ORIGINAL SOURCE EXCERPT — efabless/caravel, verilog/rtl/__user_project_wrapper.v, commit 27cbe49c.

That comment is worth reading twice. "WB MI A" is Wishbone's own datasheet vocabulary — MASTER/SLAVE Interface A — from the datasheet obligation RULE 2.00 imposes on every conformant core. The harness is not merely using Wishbone signals; it is declaring an interface in the specification's own terms.

And look at what is not there: no wbs_err_o, no wbs_rty_o. A user project's entire termination vocabulary is one wire.

The other side of the same boundary, in caravel_core.v:

	.wbs_cyc_i(mprj_cyc_o_user),

ORIGINAL SOURCE EXCERPT — efabless/caravel, verilog/rtl/caravel_core.v, commit 27cbe49c.

	.wbs_ack_o(mprj_ack_i_user),

ORIGINAL SOURCE EXCERPT — same file.

The management SoC is the master. The user project — whatever it is, whoever wrote it — is a slave.

3. Why A Fixed Contract Is What Makes The Thing Possible

The structural observation is simple and it is the whole chapter:

The harness cannot know what the user project does. It only has to know how to talk to it.

Everything above the bus is free to vary — the peripheral's function, its internal architecture, its clocking, whether it is digital at all. What cannot vary is the nine-wire contract, because the harness was fabricated before the user project existed.

This is the same argument Chapter 29.4 made about CPU wrappers, scaled up: a contract separates two problems so they can be solved by different people, at different times. Here the separation is unusually strict, because the harness side is settled in the repository before any particular user project exists — so the contract cannot be renegotiated once somebody starts designing against it.

4. The Gate On Every Wire

The finding that makes this chapter worth reading is in mgmt_protect.v:

	// The remaining circuitry guards against the management
	// SoC dumping current into the user project area when
	// the user project area is powered down.

ORIGINAL SOURCE EXCERPT — efabless/caravel, verilog/rtl/mgmt_protect.v, commit 27cbe49c.

	assign mprj_cyc_o_user = mprj_cyc_o_core & mprj_logic1[3];
	assign mprj_stb_o_user = mprj_stb_o_core & mprj_logic1[4];
	assign mprj_we_o_user  = mprj_we_o_core  & mprj_logic1[5];
	assign mprj_sel_o_user = mprj_sel_o_core & mprj_logic1[9:6];
	assign mprj_adr_o_user = mprj_adr_o_core & mprj_logic1[41:10];
	assign mprj_dat_o_user = mprj_dat_o_core & mprj_logic1[73:42];

ORIGINAL SOURCE EXCERPT — same file.

Every master-to-user wire is ANDed with a bit derived from the user power domain, each with its own bit of a wide vector. Count them: 1 + 1 + 1 + 4 + 32 + 32 = 71 bits, one per wire.

Three things follow.

First, this is a physical concern expressed in the bus contract. Nothing in Modules 1–28 needed it, because nothing there could be powered down independently. The bus boundary turned out to be the natural place to put an isolation boundary too.

Second, CYC being in that list is exactly right, and it is RULE 3.30 earning its keep:

RULE 3.30 — SLAVE interfaces MAY NOT respond to any SLAVE signals when CYC_I is negated.

Forcing CYC low is, by the specification's own rule, sufficient to guarantee the user project does not respond — whatever else is on the other wires. The remaining 70 gates are about current, not protocol. One rule from Chapter 3 of a bus specification is doing work in a power-isolation strategy, and that is not a connection anybody would predict from reading the rule.

Third, a deselected user project is deselected in the strongest possible sense. LiteX's decoder gates only CYC and relies on RULE 3.30 for the rest (Chapter 29.2); this design gates CYC and everything else, because it has a reason the protocol does not know about.

5. What The Missing Wires Cost

No ERR_O. No RTY_O. No timeout anywhere in the inspected path.

DERIVED INFERENCE: a user project that fails to assert wbs_ack_o leaves the management SoC's transfer open indefinitely, because B3 bounds no latency and there is no other termination available. A user project also has no way to say this address means nothing to me or I am busy, come back.

That is a real constraint on every design that uses this boundary, and it is the kind of constraint you only find by reading the port list rather than the block diagram. It is also a perfectly reasonable position for a harness: the alternative — accepting ERR from an arbitrary untested user design — is not obviously safer, and Chapter 29.2 showed a framework choosing ACK for the same reason.

NOT VERIFIED: whether the management SoC's firmware implements a software-level timeout around user-project accesses. We inspected RTL, not firmware.

The local policies, and the trade-off they make

The first two rows are the same bet: push failure handling out of the bus and into whatever the management side does about it. Chapter 29.2 measured what the alternative looks like when a framework takes the other side of that bet — a watchdog that answers ACK with all-ones data, turning a hang into a plausible-looking register read:

  operations retired      2 of 2
  watchdog expiries       2
  data returned to the master on the second operation
    0xffffffff

OUR MEASUREMENT, from the Chapter 29.2 reconstruction — included here because it is the measured shape of the option this harness did not take.

6. Which Results Belong To Wishbone

This is the question §27 of any honest case study has to answer, and the answer here is: almost none of them.

The transferable lesson is the third row, and it is not about Wishbone: a stable, small, fully-specified interface is what lets independent work compose. Wishbone is a good fit for that job here — 9 wires, no optional profiles in use, a datasheet convention that names the interface — but the property belongs to the stability, not to the protocol.

Claiming otherwise would be the error Chapter 29.3 warned about in a different form: attributing a system-level outcome to whichever component happened to be in the middle of it.

7. Evidence Limitations, Stated

Honesty requires listing what this chapter could not establish.

• We inspected RTL at one commit. We did not build it, simulate it, or examine any user project that used it.
• We are not citing a research paper. The evidence class here is source code plus an in-source comment, which is strong for structural claims and weak for claims about purpose or outcome.
• The commit date is 2024. The repository head we inspected is not recent, and we describe it as a snapshot rather than as current practice.
• "Research platform" is our framing, chosen because a fixed harness hosting independent unrelated designs is structurally an experimentation platform. The source does not use that phrase.
• We make no deployment claim. Not how many chips, not how many projects, not how many worked.

If that reads as a thin case compared to 29.1 or 29.2, that is the correct impression and it is deliberate. The structural finding is solid and the surrounding claims are unverified, so only the structural finding is made.

8. What Not To Generalize

Do not conclude that Wishbone is the research interconnect. One harness chose it. Others choose AXI, or a custom NoC, and none of those choices is evidence about the others.

Do not conclude that a fixed contract guarantees composition. It removes one class of incompatibility. A user project that hangs the bus still hangs the bus.

Do not turn "open silicon programme" into "industry standard". The verified statement is: an Apache-2.0 harness repository defines a Wishbone slave boundary. Everything beyond that needs its own evidence.

9. What To Carry Forward

• A bus contract is an organisational tool before it is a technical one: it says what two groups must agree on and, more importantly, what they need not.
• Count the wires on the boundary. Nine, here, and the two that are missing are the interesting ones.
• RULE 3.30 can do work far outside protocol correctness. Forcing CYC low is a specification-backed guarantee of silence, which is why it is the natural place to put an isolation gate.
• Name the evidence class. Source code proves structure. It does not prove purpose, outcome or adoption.
• Attribute results to the thing that produced them. A shared harness is a programme's achievement; the protocol in the middle is a component.

Module 29 ends here. Five systems, five recorded commits, and one habit worth keeping: open the source, find the address decision, and let the code tell you what the architecture is.