Skip to content
Tech HistoryHistory Published Updated 7 min readViews unavailable

RISC-V: From Berkeley Research ISA to an Open Standard

Trace RISC-V from Berkeley research and its 2011 28-nm FDSOI tapeout to the 2014 open-ISA case and member-governed specifications.

RISC-V began as a university instruction-set architecture project and became a shared specification maintained by a global membership organization. Its history is not simply “RISC became open source.” An instruction-set architecture (ISA) is the contract software targets and processors implement. Publishing that contract openly is distinct from publishing a processor’s RTL, licensing a particular implementation, or guaranteeing that every RISC-V chip has identical capabilities.

That distinction explains the project’s trajectory: an academic group needed a clean architecture for experiments and teaching; early specifications documented the design; a 2014 paper made the case for an openly available ISA; and later governance moved specification work beyond a single laboratory. This is a different chapter from Berkeley RISC I/II and Stanford MIPS, the 1980s projects covered in the companion history.

A clean slate for research and education

RISC-V’s designers at the University of California, Berkeley, describe starting the project in May 2010 inside the Parallel Computing Laboratory. The project’s immediate context was research and instruction, not a product roadmap handed down by a CPU vendor. An initial version of the 32-bit RISC-V instruction subset was used in Berkeley’s Fall 2010 CS250 VLSI systems design class; this wording avoids applying the later RV32I name retrospectively. The first published ISA report followed in May 2011: The RISC-V Instruction Set Manual, Volume I: Base User-Level ISA, authored by Andrew Waterman, Yunsup Lee, David Patterson, and Krste Asanović.

The choice of a new ISA carried an obvious cost. Existing architectures already had compilers, operating systems, and software. Reusing one could shorten an experiment. But research into instruction encodings, execution engines, accelerators, and specialized cores is harder when the interface being studied is controlled by a third party or tied to licensing terms. A small team also needs to know that a teaching implementation can be built and examined without a commercial disclosure process.

RISC-V International’s historical timeline records the first RISC-V chip tapeout in 28-nanometer FDSOI in 2011. That milestone shows that implementation work accompanied the early written ISA; a tapeout is not evidence of a production launch, commercial availability, or a mature software platform.

RISC-V’s own retrospective says the Par Lab’s industrial sponsors funded the lab’s parallel-computing research but did not explicitly commission RISC-V itself. That nuance matters: the ISA emerged as a research need within a broader project, rather than as a deliverable specified by a sponsor. It also helps separate later commercial adoption from the conditions that led to the first design.

From a classroom design to a public argument

The early ISA reports documented technical work, but a specification alone does not establish who may improve it, how changes are decided, or whether an ecosystem can rely on it. In August 2014, Asanović and Patterson published the Berkeley report Instruction Sets Should Be Free: The Case for RISC-V. The authors argued that SoC designers should have a free, open instruction set in the same way that open networking standards and operating systems had enabled shared infrastructure. They presented RISC-V as a candidate for research and industry, not as a claim that one processor implementation would suit every product.

The report’s argument reflected a change in the economics of chip design. A processor core could be only one component in a system-on-chip; vendors and researchers increasingly wanted to combine CPU designs with domain-specific accelerators and other custom blocks. If each architecture required a separate permission structure, small research groups and new entrants faced costs before they could even test a design. A common ISA could let more parties invest in implementations and software while retaining freedom to differentiate the microarchitecture and system around it.

The 2014 argument should be read as a design and policy position authored by the project’s leaders. It is not proof that proprietary architectures disappeared, that RISC-V had already achieved commercial scale, or that all software would become portable between any two RISC-V processors. Software compatibility still depends on the selected base ISA, standard extensions, ABI, execution environment, and operating-system support.

A modular contract is not one fixed processor

The ISA’s modular structure is central to its history. A base integer ISA such as RV32I or RV64I describes a defined core instruction set; extensions add standardized capabilities such as multiplication, atomics, floating-point operations, compressed instructions, or vectors. The RISC-V specification names the base and extension set so that toolchains, operating systems, and binary interfaces can reason about what software expects.

This modularity gives small embedded implementations a path to use a smaller supported set, while larger systems can implement more extensions. It also creates a compatibility obligation: a binary compiled for an extension cannot assume that every processor implements it. Profiles and platform standards help define interoperable feature sets, but a bare architecture name is not a substitute for checking the actual target. A practical engineering review records the exact ISA string and ABI, then checks compiler flags, boot firmware, kernel support, and the device’s published capability information.

This is where “open” must be used precisely. RISC-V International describes the ISA and ratified extensions as an open, royalty-free standard. It also says that implementations may be free or proprietary. The standard therefore defines a common hardware/software interface, not a single open-source core, compiler, Linux distribution, board, or firmware stack. Nor should a general statement about an open standard be treated as legal advice about patents or third-party IP in a particular implementation or product.

Governance moved beyond Berkeley

The first RISC-V Workshop was held in January 2015. Later that year, the RISC-V Foundation was launched with founding members from outside Berkeley. This marked an institutional shift: the technical work was becoming a community standard project whose future could not depend on one university lab’s ability to maintain every specification.

In March 2020, the organization transitioned into the RISC-V International Association, incorporated in Switzerland. Its current structure uses member representation and technical bodies to manage standards work. RISC-V International describes technical committees and working groups as the groups that create and maintain the ISA and related specifications. The exact rules for participation and ratification are organizational questions, not properties of the instruction encoding itself; they should be checked in the current governance documents rather than inferred from early Berkeley reports.

That evolution is part of the technical history, not administrative trivia. An ISA can remain available as a document while its change process becomes fragmented or controlled by one implementer. Moving to a member-governed specification effort was intended to give implementers, tool authors, operating-system projects, and other participants a forum for maintaining shared interfaces. It does not mean every implementation or downstream extension is automatically interoperable: users still need to distinguish ratified extensions and profiles from vendor-specific additions.

What the timeline does and does not prove

The current ratified specifications show that the project has grown well beyond the small initial instruction subset, while the 2011 and 2014 reports preserve what the designers first published and argued. The historical sequence is therefore visible in primary sources: an instructional prototype context, a written architecture, an explicit open-ISA rationale, and a standards organization that later took over specification maintenance.

It would be misleading to describe RISC-V as a direct commercial copy of Berkeley RISC I, or as a processor invented in 2015 when the Foundation was created. It would also be inaccurate to say that an open ISA guarantees open hardware, universal compatibility, or a patent-free product. The history is more concrete: Berkeley researchers and students designed an architecture for use in their own research; they documented it; the authors argued for an open instruction-set model; and a larger community organized to steward the specification.

RISC-V’s legacy is still being written as implementations, operating systems, compilers, profiles, and governance evolve. The durable lesson is not that openness removes engineering constraints. It is that a stable, inspectable interface can let many teams experiment on implementation and software without first negotiating control of the base ISA. Whether a specific RISC-V system is usable still depends on the precise extensions it implements and the surrounding platform contract.

Related:

Sources:

Comments