A Look Back at the Evolution of RISC-V and a Peek at What’s Next from Krste Asanović

This post was written by Krste Asanović, Chairman of the Board of the RISC-V Foundation
I still remember the first public RISC-V rollout at Hot Chips in August 2014, where our gaggle of Berkeley students and faculty wore bright blue RISC-V t-shirts and asked passerby to come see our demo silicon and grab a RISC-V button. The t-shirts are a little worse for wear, but the free and open RISC-V ISA has become an industry-changing movement with over a hundred members of the RISC-V Foundation, including many of the largest semiconductor companies.
 
While “free and open” perhaps catches the most attention in the media, in this blog post I want to focus on RISC-V as a standard. The real value of RISC-V is enabling the software and tools community to develop around a single common hardware specification, with hardware developers and users reaping the benefits of this large and rapidly growing software ecosystem. Chip builders choosing RISC-V have the advantage of knowing there are many competing suppliers for RISC-V IP. They can select among multiple commercial RISC-V IP vendors, or use an open-source core, or even roll their own. This is even more important for a second-generation chip product, where selecting a proprietary ISA would have led to vendor lock-in or worries about vendor long-term viability. Chip customers will also be assured of many sources of supply for RISC-V parts spanning a wide range of applications. At this point, it is clear RISC-V is not going away, even if individual companies come or go.
 
We designed RISC-V to be a modular and extensible ISA and some fear this will inevitably lead to fragmentation, diluting the benefit of an open standard, and so perhaps it would be safer to remain with a single proprietary ISA vendor. But it is clear from inspecting the history of proprietary ISAs that having a single source for an ISA does not reduce ISA drift. In fact the opposite seems true. Perhaps emboldened by monopoly power, many vendors have ever-expanding ISAs, with implementations having clashing subsets of available instructions, differences in the behavior of instructions, or completely different ISAs for 32-bit versus 64-bit address spaces.
 
I believe there are two powerful factors that will work towards keeping the RISC-V ISA standard coherent, one technical and one sociological.
 
Technically, to help prevent fragmentation while supporting customization, the RISC-V strategy is to have a small simple fixed base ISA and modular fixed standard extensions that work well for the large majority of code, while leaving ample space for application-specific extensions that do not interfere with the standard ISA core. Keeping the base simple reduces the incentive for an implementer to dump or alter parts of the spec to save on hardware cost or verification effort. Multiple independent evaluations at large processor companies have found this simple ISA to be very competitive with far more complex industry ISAs. By using flexible macro-op fusion at runtime, high-end RISC-V processors gain nearly all the benefits of a richer instruction set without expanding the ISA definition to the detriment of simpler cores. Only small portions of an application would use a custom extension in most cases, and so standard tools can compile most of the code for an application using the standard ISA while ignoring custom extensions.
 
Sociologically, vendors are motivated to avoid incompatibility because customers will reject non-conforming ISA modifications as these weaken their ability to multi-source IP, chips, and tools. Also, the open-source software community is a powerful force, developing and porting much of the software used by any ISA. No vendor can afford to maintain a high-quality private fork of all of this software. While custom extensions can be part of each vendor’s value proposition, these typically are highly application-specific and affect only small portions of the entire software base. Any widely applicable features should be put up for standardization at the Foundation level, and we can see this ongoing activity in our task groups.
 
In 2018, the Foundation members will be working to ratify large parts of the core ISA specs, and to complete formal machine-readable ISA specifications. Even before this is in place, the community has demonstrated a large degree of interoperability among various implementations. When we released version 2.0 of the ISA right before that Hot Chips in 2014, the Berkeley team boldly and unilaterally declared we had “frozen” the spec of the base and the first few standard extensions. Perhaps surprisingly, apart from the removal of a few minor ambiguities and holes in the spec, and with the major addition of a community-designed and well-specified memory model, the membership has agreed to stay with 2.0. It is good to know that in years to come, while there’ll be more logos on the T-shirts and a lot more than demo silicon, the ISA will remain the same.