Examining the Top Five Fallacies About RISC-V

 

By David Patterson, Pardee Professor of Computer Science, Emeritus, at UC Berkeley, vice chair of the RISC-V International Board of Directors and Advisor at Hex Five.

EETimes (December 13, 2022)

In a little over a decade, RISC-V has arguably become at least the third most important instruction set architecture (ISA) for future applications of computing. In the next few years, it may become just as surprising to pick a proprietary ISA over the open RISC-V for a new project as it would be to pick a closed alternative to Ethernet or USB.

My colleagues at UC Berkeley and I predict that by the end of this decade, the dominant ISA for future product development will be the open RISC-V architecture. Companies around the world are already designing with RISC-V and the momentum is rapidly increasing, so this is a good time for the industry to take a closer look at RISC-V and examine some fallacies about it.

Fallacy No. 1: RISC-V is an open-source processor, like Linux is an open-source operating system.

Linux has a single-master open-source code base you can download, while RISC-V is an open specification of the hardware/software interface, for which there are many different implementations. A better analogy than Linux is Ethernet, as both Ethernet and RISC-V are free and open specifications.

Before the Ethernet standard, companies had their own proprietary local area networks. In 1980, Digital Equipment Corporation, Intel, and Xerox (DIX) joined forces to create a local network standard based on Ethernet. They also created an organization — IEEE 802.3 working group — that has advanced the Ethernet standard over the past four decades. Ethernet made rapid advances in cost and performance because many companies could build network products that ran the same software stack on top of the Ethernet standard.

The popular Universal Serial Bus (USB) also followed the Ethernet game plan by providing a free and open standard for peripheral interconnect that is embraced by many companies plus an organization to evolve it.

Like Ethernet and USB, RISC-V is an open standard (which is also run by a foundation) that lets many organizations design hardware, which fosters competition to improve its cost performance and develop a rich, shared software ecosystem that offers RISC-V products in many markets. Like Ethernet and USB, you can buy RISC-V hardware, build it yourself, license designs, or download open-source designs.

Fallacy No. 2: Picking an established, closed ISA is a safer business decision than picking the open RISC-V.

It’s easy to forget that a closed ISA is tied to the success of the company that owns it, and it can disappear if the company falters. For example, the once-popular DEC VAX, DEC Alpha, and Sun SPARC ISAs are extinct.

It’s also hard to remember that closed ISAs are intellectual property that can be sold to companies with different goals than its predecessors. For example, the MIPS ISA has had more than a half-dozen owners, and so far, the Arm ISA has had three: Acorn, ARM Holdings plc, and Softbank. By comparison, RISC-V is driven by the collective participation of hundreds of companies in a neutral open-standard organization, RISC-V International. Their collective interests determine the evolution of RISC-V through this nonprofit foundation.

Like Ethernet and USB, RISC-V is not tied to the fortunes of any one company, so it is a more prudent bet for a company’s software ecosystem development for the long haul.

Fallacy No. 3: Closed ISAs do not have fragmented software ecosystems.

Older closed ISAs have suffered from unforeseen incompatibilities over their long lifetimes. Examples include:

• Despite trying to share the x86-64 ISA, AMD and Intel require different virtual machines.
• Intel AVX-512 is significantly fragmented (e.g., the ML floating-point format BF16 comes and goes).
• ARMv1 through ARMv7 use a 32-bit address space but are incompatible with ARMv8-A and successors, which offer both 32- and 64-bit address versions. ARMv8-M adds new features to the older 32-bit ISA but is incompatible with ARMv8-A.

No software environment is more fragmented than today’s system-on-chip (SoC) for edge devices. They include many incompatible ISAs and software stacks for the many types and brands of processors (application CPUs, embedded CPUs, DSPs, ML accelerators, and ISPs). One reason is because these processors use closed ISAs that cannot be used for third-party IP, so each processor block has its own ISA.

Fallacy No. 4: RISC-V’s modularity leads to a more fragmented software ecosystem than those of closed ISAs.

This fallacy has been raised since my colleagues and I began advocating for RISC-V, so it’s not been neglected. Some market segments require a stable ISA and even binary compatibility, which RISC-V addresses with profiles. They specify a set of ISA choices from the standard extensions that capture the most value for most users in a market, enabling the software community to focus resources on building an appropriate software ecosystem. Similarly, hardware vendors structure their offerings around standard profiles to ensure their designs will have mainstream software support. For example, RISC-V offers them for 64-bit address UNIX systems. Profiles are the foundation upon which portable apps and OSes can be built.

Beyond profiles, the RISC-V ISA offers the exciting possibility of a common base ISA with custom enhancements and a shared software stack across the many processors of an SoC. RISC-V potentially could dramatically reduce the fragmentation of today’s SoC software ecosystems.

Fallacy No. 5: Given the points above, RISC-V cannot become the dominant ISA.

As long as there are both 32-bit and 64-bit address versions, there is no technical disagreement that a single base ISA could be used everywhere from embedded systems to supercomputers; the main argument is a business one, of whether it should be a closed ISA or an open ISA. If we do achieve a lingua franca for computing, it seems self-evident that it would be too dangerous for the fate of the entire information technology industry to be tied to the fortunes of a single company. It would be much safer if we could instead depend upon a free and open standard, just as we did for networking and peripheral interconnect.