RISC-V—Instruction Sets Want to Be Free

I had never heard of the RISC-V (pronounced five, not vee) instruction set until earlier this year when there was a presentation about it at EDPS in Monterey. I immediately texted the daughter of a friend of mine who is a CS major at Berkeley where it originated and she gave me a bit more background. Then, at DAC last week, Krste Asanovic, one of her professors, gave a SkyTalk on the topic. It was the only pavilion presentation I went to during DAC where every seat was filled and there were lots of what MUNI here in San Francisco calls "standees" (wouldn't they be people being stood on?).

Instruction set architectures (ISAs) matter

As Krste pointed out, it is one reason that Intel struggles to get a foothold in mobile. Or that ARM struggles in servers. As Krste pointed out, the main instruction set in all those datacenters is officially the AMD 64-bit x86 ISA, even though most of the processors are built by Intel. When the 32-bit to 64-bit transition happened, Intel tried to move everyone to its new instruction set (jointly developed with HP) called Itanium, but people preferred to stick with an x86-compatible architecture. When AMD got traction, Intel had to compete aggressively and eventually Itanium was left to die a slow death. ISAs are also where the software meets the hardware, so they are one of the key interfaces in any system.

There are a lot more ISAs than the obvious ones of x86, ARM, and Power. For example, most mobile SoCs contain an ARM^® processor, but there are also GPUs and DSPs and other embedded processors where the ISA is not exposed to the high-level software level as with the application processor itself. There is no reason, apart from inertial, that all these instruction sets couldn't be the same, with all sorts of economies in the software stack and the tool ecosystem. It would need to be open, so not something that exists already. Krste joked that the smallest unit of time is meant to be between a light going green and a New Yorker honking their horn, but even shorter is the time between putting an open implementation of an ARM processor on the net and getting a letter from ARM's lawyers.

RISC-V started in 2010. Krste wondered what ISA they should use for their next projects. Just based on ubiquity, the obvious choices were x86 and ARM. The x86 ISA is too large and complicated for student projects, so impossible. ARM is better (mostly impossible), but both ISAs come with a lot of licensing issues. He concluded that the existing ISAs were "dismal."

So they decided to develop their own ISA, that eventually came to be called RISC-V. Their list of requirements were:

• it should work well with existing software stacks and languages
• it should be a native ISA implementable in hardware, not a virtual machine
• it should be suitable for all processors from microcontrollers up to supercomputers
• it should be implementable in many physical ways: FPGA, ASIC, full custom
• the ISA should not be tied to the implementation style (in order, superscalar, etc.)
• it should be the base for customized extensions for specific types of processing
• it should be stable and not changing
• it should survive the death or change of business models of companies (the VAX and Alpha ISAs died when DEC went out of business, for example)

Demand for an open instruction set architecture

There was a clear need for an open ISA since groups all over the world discovered RISC-V and started to use it. When Krste changed the ISA for a student project, he got emails from people he had never met, complaining. So in 2014 they froze the base (non privileged) ISA. They knew from day one that they would need a compressed instruction extension (like the ARM Thumb) to reduce code size for embedded systems and to produce better cache behavior in large systems. There are other extensions for vectors, floating point, and more. Even so, the whole instruction set fits on one slide. "You know it's a RISC since the manual doesn't come with a staple."

There have been 12 tapeouts of implementations in process technologies from 28nm to 45nm and these implementations are competitive with existing industry chips in area, power, and performance. Industry benchmarks are competitive with x86 and ARM for things like the number of memory accesses and so on.

Last year, 2015, the RISC-V foundation was created. Krste is the chairman. Anyone who wants to use the RISC-V trademark needs to be a member. Also, to prevent fragmentation, any implementation must pass the compatibility suite. ARM used an even stricter standard in its early days, insisting that an implementation passed its manufacturing test vectors. Existing members of RISC-V include a lot of industry heavyweights including Google, IBM, Oracle, BAE Systems, Western Digital, and more.

Of course, an ISA needs software, both compilers and other development tools, and operating systems and software stacks. Some of the existing tools are:

• SPIKE, the "golden" simulator for RISC-V. The golden spike was the last spike to join up the transcontinental railroad. In Utah, which gives you some idea of how hard it was to build the western part of the railroad compared to the east
• QEMU, one of the major virtual platform jitted processor modeling environments, originally written by the legendary Fabrice Bellard (author of tcc and other barely believable projects)
• Linux, which runs on all of silicon, SPIKE, and QEMU
• gcc and gdb
• And more coming all the time

Mass momentum seems to be building up behind RISC-V, since it is a good instruction set with no significant licensing issues. It reminds me in some ways of Linux, which wasn't initially seen as any sort of competitor to Windows but eventually has become the main operating system used in datacenters.

As Krste wrapped up at DAC, his last slide hinted at similar ambition: "Our modest goal," he said, "is to become the industry standard for all computing devices."

For all things RISC-V go to the RISC-V Foundation website.

Next: 99.7% of Transistors Manufactured Are Memory

Previous: Seamless Verification