OpenCores Origins

Chapter 1.5 reached its conclusions from engineering pressure alone. A careful team, given six peripherals and one FPGA, arrives at the need for exhaustive decode, a completion signal and a common interface without ever hearing the word Wishbone.

This chapter is about what happened when that pressure was applied not to one team but to a community — and it is a history chapter with a narrow purpose. It is not a biography of a website, and the engineering question it serves is specific:

Why would an ecosystem of independently developed, freely available hardware blocks need an open interconnection convention, when each author could simply document their own interface?

1. The Ecosystem, and the Shape of Its Problem

Documented. OpenCores was founded in October 1999 by Damjan Lampret as an open-source community for the development and distribution of VHDL and Verilog IP cores. Its early activity centred on the OpenRISC instruction set architecture; the OpenRISC 1200 implementation was designed by Lampret in 2000, in Verilog.

Interpretation. What makes that founding interesting for this curriculum is not the cores. It is the structure it created — and that structure has a shape Chapter 1.3 already described in the abstract.

Interpretation. Three properties of that structure are what make the interface question urgent rather than merely convenient, and each one removes a mechanism a single company would have relied on.

Authors and integrators never meet. In a company, an interface disagreement is resolved by a conversation. In a public repository there is no conversation: the author may have moved on, the project may be dormant, and the integrator's only channel is the code.

Neither side can see the other's constraints. An author does not know whether their core will land next to a fast RAM or behind a bridge, whether the system has one initiator or three, or what reset convention the rest of the design uses. They cannot design for a system they cannot see, so they design for none — and produce, reasonably, whatever interface suited their block.

Nobody owns the composition. Every block has an author. The system has no author until an integrator appears, and by then every interface decision has already been made independently.

That third point is the one worth keeping. A closed design house has an architect who fixes interface conventions before any block is written. An open repository has no such role, and the only substitute available to it is a published convention that authors adopt voluntarily. This is the same argument Chapter 1.4 made about the five columns of reusability — the interface is the one a community can supply by agreement rather than by labour — arriving here from the direction of who is in the room.

2. Wishbone's Authorship and Transfer

Documented. Wishbone was created by Wade D. Peterson of Silicore Corporation, who was its original author and steward. The specification's title is WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores.

Documented. OpenCores released the Revision B3 specification on 7 September 2002, and Silicore transferred Wishbone stewardship to OpenCores on 8 December 2002. Note the order: the release preceded the formal transfer by three months. Revision B4 followed in 2010.

Documented. The name is descriptive of the interconnect's structure rather than an acronym. Peterson was looking for a name for a bi-directional data bus built from either multiplexers or three-state logic; connected to three-state logic, the paths form a Y shape that resembles a wishbone. The name itself was settled on at a Thanksgiving dinner that included roast turkey.

Interpretation, and worth a sentence because it is a real engineering observation. That Y shape is the same structure Chapter 1.5 built as an AND-OR reduction — many sources converging on one path back to one initiator. The naming anecdote is trivia; the topology it describes is the response multiplexer that chapter showed carrying the fabric's critical path.

3. The Public-Domain Decision, and What It Was Defending

Documented. The Wishbone standard is not copyrighted and is in the public domain. It may be freely copied and distributed by any means. There is no licence to accept, no fee, and no registration.

Documented, and more interesting than it first appears: to prevent its techniques from being preempted by aggressive patenting, the specification includes examples of prior art, so that its concepts are demonstrably already public.

Interpretation. That second decision is the one worth understanding, because it addresses a threat most engineers never consider.

Publishing a specification does not, by itself, stop a third party from patenting a technique the specification uses. If that happened, every adopter would inherit a legal exposure created by a document they were told was free — and the cost would land on exactly the volunteers and small projects least able to absorb it.

Documenting prior art inside the specification is a defensive move, not a legal guarantee. It makes the techniques demonstrably public at a known date, which is what a patent claim over them would have to contend with.

Why this belongs in an engineering curriculum rather than a legal one: it illustrates that an interconnect standard for an open ecosystem has to be free in a stronger sense than "no invoice". A standard with an uncertain patent position is not adoptable by a volunteer project, because the project cannot evaluate or insure the risk. Freedom to adopt without a legal review is a technical requirement for this ecosystem, in the same way that freedom from a royalty is — and the two are not the same thing.

Set against Chapter 1.4's honest account, this is the one column where open hardware's answer is unusually strong. Documentation and verification vary enormously across published cores. The licensing position of the interconnect they share does not vary at all.

4. What the Specification Set Out to Do

Documented. The specification states that it is intended to guarantee compatibility between compliant IP cores and to improve cooperation among different users and suppliers, and that it exists to provide an open, freely usable interconnect architecture for IP cores.

Read that sentence against the previous five chapters and it is almost a summary of them.

Documented. The specification supports several interconnection topologies: point-to-point, many-to-many — the classic shared bus — hierarchical arrangements, and switched fabrics such as crossbar switches.

Interpretation. That list is the specification declining to make a decision, and it is the right decision to decline. Chapter 1.5 showed the fabric's structure being driven by target count, critical path and device resources — all properties of a particular system on a particular part. A specification that mandated a topology would have made itself unusable for most of the systems it was aimed at. Fixing the interface and leaving the fabric open is what lets one UART core serve a two-block FPGA project and a crossbar SoC.

5. What the History Does and Does Not Establish

Open-hardware history attracts confident retelling, so it is worth stating plainly what the record above supports and what it does not.

It establishes that Wishbone was authored outside OpenCores, by a named engineer at a named company, and was transferred to community stewardship after adoption. It establishes the public-domain status and the deliberate prior-art defence. It establishes the revision dates and the specification's own stated aims.

It does not establish that Wishbone is the best on-chip bus, that it is widely used in commercial ASICs, that it outperforms or undercuts any other interconnect, or that it is obsolete. Every one of those claims is made routinely and none of them follows from anything in this chapter. Several are addressed properly later in this track — Module 20 compares Wishbone with AXI, Module 22 covers performance, and Module 31 is a dedicated misconceptions module — and each requires evidence this chapter does not have.

It does not establish motive. The reasoning in Sections 1 and 3 is an engineering reconstruction: it explains why an ecosystem of independent authors needs a common convention, and it is consistent with what was built. It is not a claim about what anyone was thinking.

The one thing the history does settle for this curriculum is the direction of causation. Wishbone was not designed and then given an ecosystem. The ecosystem existed first, the integration problem was real and recurring, and the specification was adopted into it — which is why the previous five chapters could derive the need for it without mentioning it, and why Chapter 1.7 can now derive the thing itself.

6. Common Misconceptions

"OpenCores invented Wishbone."

The wrong model: the specification came out of the repository that hosts it.

What it costs: not much technically, but it obscures the more useful fact — that the specification was written independently and adopted, which is evidence it solved a problem people already had rather than one its authors imagined.

The corrected model: Wade Peterson at Silicore Corporation authored it; OpenCores published B3 in September 2002 and received stewardship in December 2002.

"Public domain just means free of charge."

The wrong model: the licensing position is an accounting detail.

What it costs: underrating what makes a standard adoptable by volunteer projects, and missing why the specification bothers to document prior art.

The corrected model: no royalty is necessary but not sufficient. A specification a small project cannot adopt without a patent review is not usable by that project regardless of price. The prior-art documentation is a defensive measure aimed precisely at that, and it is a design decision about the standard's usability.

"Wishbone is a historical artefact."

The wrong model: an older specification with community stewardship is a museum piece.

What it costs: dismissing an interconnect that is a reasonable engineering choice for a class of systems, and — more practically — being unable to read the many open cores that present a Wishbone interface.

The corrected model: age and current applicability are different claims requiring different evidence. What this chapter establishes is that the specification exists, is unencumbered, has had revisions in 2002 and 2010, and is widely present in open IP. Whether it is the right choice for a given system is Module 20's and Module 22's subject, and it deserves a comparison rather than an adjective.

"The history explains why Wishbone's signals look the way they do."

The wrong model: origin determines design.

What it costs: expecting this chapter to have taught something it deliberately did not.

The corrected model: the history explains why a common convention was needed and why it had to be unencumbered. Why the signal set is what it is, is an engineering question answered by Modules 3 and 4, from requirements rather than from provenance.

7. Sources

The factual claims in this chapter come from the following. Where a claim is interpretation it is marked as such in the text.

• OpenCores — the project's own Wishbone pages and specification downloads, which carry the revision history, the public-domain statement and the stewardship transfer dates. Registered in this repository as the governing reference authority for the Wishbone track.
• The Wishbone specification itself — WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores — for the document title, the stated aims, the supported topologies, and the prior-art provision.
• General reference material on OpenCores and on the Wishbone bus for the founding date, the founder, the OpenRISC connection, the later transfer of the OpenCores brand to ORSoC AB in 2007, and the 2015 formation of the FOSSi Foundation.

What is deliberately not cited: adoption figures, market-share claims, and performance comparisons. This chapter makes none of them, and the sources available would not support them.

8. Interview Reasoning

9. Understanding Check

10. What's Next

The history establishes the setting: an ecosystem of independently authored cores existed, its integration problem was real, and an unencumbered interconnect specification written outside it was adopted into it and then stewarded by it.

Six chapters have now produced every ingredient of an argument without once assembling it.

Given all of it — that a CPU reaches hardware only by addressed reads and writes, that an address map answers where and not how, that private interfaces multiply, that reuse needs a checkable contract, that an FPGA fabric needs exhaustive decode and a completion signal, and that an open ecosystem can only standardise by agreement — what would you design?

Chapter 1.7 — Why Wishbone Was Created answers that by deriving it rather than describing it, and closes Module 1. The full path is on the Wishbone curriculum index.