Photo by Sebastian Ahmed (Sedona AZ)

Challenges and opportunities for open-source in Silicon — Part 4

In Part 3 we covered a lot of ground focusing on the main characteristics of open-source developments such as cost, licensing terms, governance, distributed/local development, and timing.

In this installment, we will focus squarely on what may be one of the biggest opportunities for open-source and silicon. This is the topic of the open Instruction Set Architecture (ISA), and specifically in the realm of reduced instruction set computers (RISC).

A common computer language

Image Credit: Google

No article about open-source and silicon would be complete without discussing RISC-V. So much has been written about RISC-V that it is somewhat challenging to not cover old ground.

Let us begin with first describing what RISC-V really represents to the electronics industry (at least my current view of things):

RISC-V is a pursuit towards an open, ideal, modular, and common computer language for industry, defined by industry.

All programming languages are ultimately translated to a computer language. A computer language is known as the Instruction-Set Architecture (ISA). The ISA defines the lowest-level programming view of a computer (“machine”). The machine ultimately carries out the duties prescribed by the programmer. No matter what the machine does under the hood, it must maintain congruence with the ISA semantics.

The diagram below shows a simplified view of where the ISA concept sits in relation to machine-specific tools and the machine implementation. Here we have an ISA called “Foo”.

Drawing by Sebastian Ahmed

As such, the ISA does not prescribe the higher-level programming language, the method of translation nor the machine implementation. It is merely a well-defined interface and a contract. When I say “well-defined”, I do not just mean in the completeness and specificity of its semantics, but that it has to be well-done (something approaching the “ideal”). The ISA tends to impact the “back-end” of compilers which deal with Register Transfer Level optimization steps and beyond (not to be confused the “RTL” of Hardware Description Languages). The “register” here refers to the ISA-visible registers.

Within the landscape of general-purpose programming languages (i.e., the languages which humans enter via keystrokes), such as C, C++, Java, Python, Julia, … the list goes on,

the idea of a proprietary language is almost unheard of.

In the silicon world, even the hardware description languages (HDLs) such as Verilog are open standards. Note, that having an open language does not imply open (permissive and free) or open-source tools, but it creates the right conditions to enable such things (e.g., GCC and LLVM). In fact, both can co-exist.

When it comes to ISAs however, the world has been one of proprietary specifications. This has not been a bad world, by any means. We have seen tremendous advancements across all the main computing segments including enterprise, cloud, mobile and embedded with such proprietary approaches.

It is possible however that an open ISA such as RISC-V can bring forth even more success because of its stand-alone nature allowing its use to be de-coupled from the layers above and below.

Proprietary ISA monoliths

Below is as diagram which shows a simplified view of how proprietary ISAs form monolithic structures consisting of machine implementations and their respective tool ports and variations. These monoliths are formed because of the proprietary nature. A proprietary ISA has a “stickiness” which congeals the machine implementation and tooling. There is no motivation to separate these in fact.

Drawing by Sebastian Ahmed

There are benefits of this approach. A monolithic ISA allows complete optimization across the stack. There is no governance body to ask when coming up with a new ISA. A complete monolith is delivered each time there is an update. In fact, the machine implementation itself may act as the retroactive golden model of the ISA, which means that the ISA could be updated to reflect some nuance in the machine.

The line between the ISA and the machine implementation is blurred.

The first drawback to this approach, is that the ability to create monolithic stacks such as these are only afforded by a very few who can fund full-stack development including processor micro-architecture all the way to tools and optimized libraries. Yet such enterprises do not have unlimited resources and thus need to minimize the number of variants of machine implementations. This results in a limited variety and pace of evolution.

The second major drawback to this approach is related to the first in that, if a selection criterion is based on machine specifications, it may require the customer to utilize a different monolith. It is not unusual to find three or more ISA monoliths on a chip. Each monolith requires its own tools, debug, unique optimized libraries and specialized embedded developers.

This is fragmentation because it involves additional resources being expended to achieve overlapping outcomes

Domain-specific architectures

I should make clear that there is definitely plenty of space and reason for proprietary ISAs. One area is in the realm of domain-specific architectures. Much like domain-specific languages, these are attempting to solve specific problems in a hyper-optimized way. A good example of a domain-specific architecture is an AI neural-engine.

Typically, in such domain-specific realms, there is little benefit or motivation for the global standardization of the low-level software interface. Specialized architectures often rely on low-level controlling software (such as micro-code) which abstracts the underlying machine from what compiled software interacts with. Standardization and commonality typically occurs at higher levels of abstraction such as user APIs (e.g. TensorFlow-Lite for AI).

This does not mean that a general purpose processor cannot be specialized in its application, but even in such specialized applications, it is still a general purpose reduced instruction set computer (RISC).

Open micro-ISAs

Now, let us consider how things may look with an open ISA such as RISC-V, which besides being open is also modular. We could perhaps call this a micro-ISA (to borrow a term from OS microkernels which exhibit this pattern of modularity).

Drawing by Sebastian Ahmed

Here we have something a bit different. We have made the computer language common across a variety of machines. What opportunities lie here for the silicon developers? The main opportunities appear to be related to the de-coupling effects:

  • The software parts of the industry can focus on building the best tools and libraries for a single ISA. This is a pattern of de-fragmentation.
  • The “machine” implementations become efforts which completely focus on providing a variety of excellent micro-architectures for the many segments and sub-segments of the processor market. This is neither fragmentation or de-fragmentation, it is a liberation to create more value and optimization points in computer design, free from the burdens of having to deliver monolithic stacks of enablement.
  • When a silicon vendor or IP provider wishes to provide some specialized capability such as a custom ISA extension, the possibility exists to do this in an incremental way. There is no need to create a completely new ISA (to avoid license infringement or otherwise) and simply build on an established foundation.

This is in fact a pattern of de-fragmentation because it localizes the “fork” only to the parts that need to be forked.

Open-source ISA Implementations

Much like the idea of open programming languages brought to fruition open-source tool-chains (which ultimately democratized programming in general), the openness of RISC-V has borne open-source implementations of the ISA.

An implementation of an ISA can span a multitude of uses and abstractions. An emulator (such as QEMU), formal model, instruction-set simulator (ISS) and silicon designs (digital RTL) all constitute implementations of an ISA.

What are the noteworthy developments in terms of actual silicon-ready RTL designs?

OpenHW Group CV32E40P : 4-stage embedded RISC-V CPU core

  • Originally based on the PULP-Platform “RI5CY” project (developed in collaboration between ETH-Zurich and University of Bologna), the CV32E40P represents the first open-source developed industrial-grade core.
  • This core was developed by the OpenHW Group which included significant contributions from the silicon industry. What makes this RISC-V implementation special is that it developed completely in the open-source, and second, it has been fully verified to modern industrial-standards (see here, and here) where all verification collateral is included (e.g., detailed verification plans and functional coverage).
  • The OpenHW Group is also developing other cores including the PULP-Platform “Ariane”- derived CVA6 which is a 6-stage 64-bit machine capable of running Linux.
  • All OpenHW Group projects can be found in this GitHub project.

lowRISC Ibex : 2-stage embedded RISC-V CPU core

  • Originally based on the PULP-Platform “Zero-riscy” project the Ibex also represents a fully open-source developed processor core
  • This core is being developed by lowRISC which is also a not-for-profit organization comprised of academic and industry members
  • Of note, the Ibex core formulates the main processing core within the Google-sponsored OpenTitan project (more on this in a future post)

CHIPS Alliance SwerRV™ : A variety of 4- to 9-stage single or dual-issue CPU cores

  • The SwerRV family of cores were developed internally at Western Digital and open-sourced in 2018 (following the completion of the development)
  • Unlike the OpenHW and LowRISC developments, the SweRV™ cores are more of an RTL and ISS release and full silicon deployment requires purchasing a support package from a commercial IP support provider.

There are many other implementations out there, a full catalog can be found here.

If I have missed any permissively-licensed industrial-grade, silicon-RTL open-source RISC-V projects, please let me know!

Summary

An open, modular and common ISA, can create the conditions for more diversity, focused value creation and optimization of products. This is afforded by the property of de-coupling the ISA as an interface from the machine implementation allowing software tools and silicon to be independently optimized and segmented.

Much like general purpose open programming languages have liberated innovation in software development, an open and common computer language has the potential to bring similar energy and innovation not only to silicon developers, but to the electronics industry as a whole.

Technology Leader | Systems Architect | Programmer | Photographer