Update 5/4/17: SiFive has released their Coreplex IP for licensing RISC-V cores, with two available designs: the E31 Coreplex and the E51 Coreplex. You can learn more on their website.
There has been an upswell of interest in custom, open hardware among makers, in which community-developed and shared designs abound. The availability of low-cost development boards such as Arduino and Raspberry Pi, together with open source software, has made it easier to get started with making innovative, new hardware designs.
However, in terms of embracing open source to achieve greater innovation and productivity, the hardware industry is still far behind software. Up until now, the open source hardware movement has been limited by the use of off-the-shelf, commercial silicon chips. These chips often include blocks that are closed source. Their programming interfaces can only be accessed under non-disclosure agreements, or by using opaque precompiled software “binary blobs” that cannot be modified or reverse engineered.
Many advanced chips are not even available to purchase in small quantities, as the vendors are only interested in supporting high-volume customers. Without access to custom silicon technology, makers and small startups are currently constrained to using off-the-shelf microprocessors combined with field-programmable gate arrays (FPGAs), which can be reprogrammed to emulate a custom chip design.
FPGAs, although excellent for prototyping, are too expensive and power hungry to use in large production runs. This lack of open source chips led me, along with my computer architecture research group at UC Berkeley, to develop an open source instruction set architecture (ISA). The latest version, RISC-V, allows hardware developers open access and full power over their parts — down to the level of the chip.
Room for Improvement
Back in early 2010 at UC Berkeley, our research group was pondering which ISA to choose for our upcoming research projects. An ISA defines the set of instructions that a microprocessor understands. For example, laptop and server chips from Intel and AMD only run software encoded in the Intel x86 ISA, whereas mobile chips from Apple, Samsung, and others only run software encoded in the ARM ISA. Ideally, for our research projects, we wanted to evaluate our new processor ideas running a wide range of software. Using x86 or ARM for our projects would have seemed the obvious choice, but three big problems forced us down an alternative path.
First, both these ISAs are large and complex. The Intel x86 has its roots in the 16-bit 8086 chip, one quickly designed in ten weeks back in the late 1970s after a different, more ambitious Intel ISA was late to market. In a momentous decision, IBM chose the cheaper Intel 8088 variant of this chip for its first PC prototype and brought in third-party operating software from Microsoft. It inadvertently left the platform open for clones and enabled Intel and Microsoft to grow into industry titans on the back of the IBM PC platform’s dominance.
Flush with revenue from the PC business, Intel rapidly grew the x86 ISA, expanding from 16- to 32-bit and now 64-bit registers — all while being conscious not to sacrifice backwards compatibility with the original hastily constructed foundation. Nearly 40 years later, not even an Intel architect will claim the x86 ISA is elegant, and high-performance implementations of this baroque ISA require huge engineering resources, far beyond the reach of a small university team.
The ARM ISA, in contrast, has it roots in the RISC (Reduced Instruction Set Computer) movement pioneered by groups at IBM, Stanford University, and UC Berkeley in the early 1980s, a movement that promoted simple ISAs for high-performance implementations. “RISC” was coined by my colleague Dave Patterson to name the world’s first RISC-I and RISC-II chips that were produced in the project he led at UC Berkeley, but RISC is now used to refer to the style generally.
In 1985, inspired by the student-led UC Berkeley RISC effort, engineers at Acorn Computer in Cambridge, England, built their own high-performance 32-bit Acorn RISC Machine (ARM) to replace the 8-bit 6502 microprocessor used in their earlier desktops. Unfortunately, the Acorn RISC desktop machines could not survive the IBM PC onslaught.
However, noting its low cost and low power, Apple picked it for the original Newton handheld project. Apple, VLSI Technology, and Acorn formed a new company, ARM Ltd (ARM now meaning “Advanced RISC Machines”) in 1990 and created a new business model. Instead of selling its own chips, ARM licensed processor designs for customers to incorporate in their own systems on chip (SoCs). Back in 2010, the ARM ISA did not meet our needs; it lacked 64-bit addressing and had several quirks that complicated high-performance implementations. Now, ARM dominates the mobile and embedded SoC processor market and is at the heart of almost every smartphone and tablet.
The second big problem with both ISAs is that they are not open. The ISA is perhaps the most important interface in computing, as it connects software to hardware. However, there have been very few open ISAs, even though many other computing parts have a healthy ecosystem built around open standards.
Apart from Intel, only AMD and VIA have the right to build x86-compatible processors. ARM prohibits other companies to make or sell ARM-compatible processors without a license. We believed that it was important for researchers to share detailed core designs, both to improve the quality and reproducibility of research and to share the effort of building research infrastructure. We did consider the few existing open ISAs, but decided against them because they were not open source and lacked 64-bit design, among other technical deficiencies.
The third big problem was the lack of extensibility in these ISAs. With Moore’s Law scaling coming to an end, our research project was investigating specialized processors to improve compute capability. Existing ISAs were not designed to support much expansion, wastefully using up many instruction bits for the initial ISA design. After decades of enhancements, there was little encoding space left to add new extensions. Also, the mainstream ISAs had become too large to be an efficient base for a specialized processing engine.
Although we originally set out to use an existing ISA, we realized that creating our own might actually be the best path forward, so we began our design in May 2010. We named the new ISA “RISC-V” (pronounced “risk-five”) to represent the fifth generation of RISC designs from UC Berkeley.
Clamor for Community
While we worked on the design, we were also working on the supporting software and chip implementations. The first RISC-V implementation was the 64-bit Raven-1 chip in 2011, fabricated in a 28-nm FDSOI process donated by ST Microelectronics. Subsequently, over a dozen RISC-V implementations have been completed at UC Berkeley in a range of fabrication technologies, with more underway. In addition to research, RISC-V was used in a growing number of university classes, with our course material freely posted on class websites.
The design for the RISC-V ISA was influenced over these first few years by both our software and hardware implementation experience and learning from the mistakes made over the last thirty years of ISA design and use. Unfortunately, we started receiving emails from outside UC Berkeley complaining about these changes. There was a user community out there relying on RISC-V and our software tools for real engineering projects. We realized the demand for a free and open ISA standard was much larger than we previously thought.
By May 2014, we felt confident enough in the RISC-V base ISA design to call it done and freeze it permanently. That summer, in order to raise the profile of RISC-V in both academia and industry, Dave Patterson and I wrote a series of position papers on why instruction sets should be free. We could see no technical reason why a free and open ISA standard could not work just as well, if not significantly better, than the current proprietary standard. More importantly, we believed a free and open ISA would enable much more innovation by allowing competition between open-source and proprietary standards.
For example, a SoC designer currently has to first pick a processor vendor, possibly through a competitive bid, and is then stuck with that vendor’s proprietary ISA. Most SoC designers hope their product is successful enough to warrant a second version, but at that point, it would generally be too expensive to port all the chip’s software to another ISA. So the SoC team is effectively locked into the original choice of proprietary ISA, which makes the licensing negotiations for the next round much less competitive.
With an open ISA like RISC-V, an SoC designer can choose between multiple vendors of RISC-V cores, use an open-source design, or just build their own. In fact, when we held the first RISC-V workshop in January 2015, we were surprised to learn that the initial RISC-V processors were already shipping commercially in dental cameras produced by Rumble Development in Massachusetts. Rumble had built its own simple RISC-V softcore to fit in an FPGA in only three weeks.
Build a Solid Foundation
The next workshop in June 2015 also sold out with an even larger group of attendees. It was clear the RISC-V project was now larger than a university project. In August 2015, I founded the RISC-V Foundation, a 501(c)(6) non-profit trade association to manage, protect, and promote the RISC-V ISA and hired Rick O’Connor as the executive director.
We launched the foundation in January 2016 with sixteen member companies. By the fourth RISC-V workshop in July 2016, we had grown to nearly fifty member companies. Membership in the RISC-V Foundation ranges from small startup companies all the way up to some of the largest companies in the computing industry, including Google, Microsoft, IBM, HPE, Qualcomm, and AMD. It will ensure that the ISA remains free and open and uses licensing of the RISC-V trademark to ensure that commercial implementations remain compatible with the spec in order to avoid fragmentation.