Exploring the Ongoing Debate: Is RISC-V Rigid or Flexible?

Ian Ferguson, Senior Director Infrastructure Segment Marketing, SiFive

At the RISC-V Summit in North America this week, RISC-V International announced that the RVA23 Profile has been ratified. The fundamental objective behind RVA Profiles is to ensure software portability across hardware implementations.. This announcement reminded me of an important question that Krste Asanović, Co-founder and Chief Architect at SiFive and Chief Architect of RISC-V International, brought up during his 2024 presentations at the RISC-V Summit Europein Munich and (more recently) at the RISC-V Summit China in Hangzhou. During these sessions, Krste tackled the (much asked) question: is RISC-V flexible or rigid? The answer is “Yes!”

On the one hand, RISC-V is very flexible. There are many different things a company or individual can do with it. RISC-V was intentionally designed in a modular way such that:

• It can be extended.
• A core can be highly tuned for a specific application.

The “so what” from this approach is that the onus is then on that company or individual to deliver the software that supports these customizations. This approach has been successfully implemented by a number of companies, especially for black box applications such as solid state drives (SSD), where the provider of the SSD delivers all of the software that runs on that platform. What this means is that customizations to accelerate encryption functions, data movement, and wear leveling algorithms are not exposed to third-party programmers and programs.

RISC-V also enables companies to build a tightly controlled architecture, featuring (by design) mandated instructions and very few options. For companies that are building a core that is going to run tens of thousands of software packages, this rigidity is needed. The way this is achieved in the RISC-V community is with profiles.

When people raise the topic of fragmentation inside the RISC-V ecosystem, we find that they are confusing these two use cases.

RVA23 mandates a number of capabilities including vector extensions and hardware virtualization support for implementing hypervisors. SiFive has already announced products in its Performance and Intelligence families that are compliant with the RVA23 Profile. One of the strong value propositions behind RISC-V as an open standard is the ability for customers to avoid vendor lock-in, so it is great to see other members of the RISC-V ecosystem aligning behind this key profile. Fundamentally, RVA23 aligns implementations of RISC-V 64-bit application processors that will run rich operating systems (OS) stacks from standard binary OS distributions. Krste has also indicated that with RVA23 and other extensions that are currently in development or under review, RISC-V has caught up with other architectures.

That said, processor architectures have to keep adding features over time to remain competitive. We run into this challenging chicken and egg situation where:

• Software companies won't support a new function it if nobody has it deployed in field systems;
• And hardware folks will not deploy it if there is no software support.

In the RISC-V ecosystem, there needs to be an agreement about new architecture features. RISC-V Profiles were designed to resolve this problem. Vendors get together and agree on the roadmap over time of when the features are going to be added to the instruction set. Software vendors must know the mandatory set of features that their software can rely on to be present.

In addition to mandatory functions, profiles state optional elements. There are a few categories of these:

• Localized options: An example of this are cipher instructions since different ciphers are used in different locations around the world. Since RISC-V is a global standard, we embrace this diversity and enable customers to select the versions that work best for their use cases and go-to-market strategies.

• Development options: These are options that are early in the life cycle. Usually these relate to new features that are ratified and ones we intend to make mandatory in a subsequent profile. Given the timeline to support a new function, this approach enables the community to start to build support into products for this capability.

• Expansion options: These are capabilities that are very useful, but also tend to have a large cost. An example of this is matrix extensions. Not every system will want to have these mandated.

• Transitory: In this case, RISC-V is adding something in for developers to use as a stopgap or to experiment.

RISC-V International and the broader community are also working on RISC-V Platforms. Platforms are a much bigger set of specifications. As an example in the server domain, this is nailing down how a system boots up, how it runs and, potentially most importantly, how these systems will be certified. I will share more about this in a subsequent blog.