RISC-V takes steps to minimize fragmentation

The momentum behind RISC-V is growing with the backing of tech heavyweights, but it comes with a challenge: encouraging CPU designers to stay on the same page, and to avoid the sort of fragmentation that happened in MIPS and Android.

With that in mind, RISC-V International, which coordinates the development of the open-source instruction set architecture (ISA), has turned to its community for guidance and to determine what its priorities should be in the coming years.

Last week, the organization shared a survey on its mailing list to collect feedback to "help identify ISA gaps, build plans for future extensions, and preserve compatibility among RISC-V applications."

The point of the survey is to get an idea of what the community is working on, and if there's a strong desire to standardize some of the non-standard extensions being developed privately, RISC-V International chief technology officer Mark Himelstein told The Register.

RISC-V is sometimes referred to as the Linux of chips, with a wide world of engineers collaborating to design, set, and improve the architecture.

RISC-V is essentially a set of specifications that define how, from a software point of view, compatible CPU cores should operate: what kinds of instructions are available, how they are formatted in memory, and other central functionality.

These specs are then royalty-free to implement in processors and system-on-chips: it's up to semiconductor engineers to decide exactly how to structure the plumbing and logic in their chips to run software built for RISC-V machines.

RISC-V has a modular approach: its ISA has a base set of features as well as optional extensions, such as atomic operations and floating-point math, that can be implemented as necessary in silicon.

Some extensions are openly published and ratified by the community; engineers are also free to come up with their own private custom extensions for their particular chips.

Adding functionality, such as instructions for accelerating AI operations, at the CPU core extension level can, depending on the design, avoid the need to develop and hook up separate co-processors and their interfaces.

Chip developers can therefore create and implement a mix of open and proprietary extensions for their RISC-V CPU cores. And that's where fragmentation may happen.

One company could implement in its processor family a set of standard RISC-V extensions and bolt on a custom, non-standard extension that some applications come to rely on.

Those applications may struggle to run on another company's RISC-V chip that doesn't implement that extension because it's not ratified or able to be implemented for whatever reason.

RISC-V International is keen to avoid this uncontrolled expansion of the ISA by getting groups to standardize their extensions in an open, collaborative manner when it seems smart to do so.

If something makes sense, then we can bring people back together and have less of these non-conforming and non-standard extensions

"A part of the reason for the survey is to figure out what else is out there. If something makes sense, then we can bring people back together and have less of these non-conforming and non-standard extensions," Himelstein said.

Standardization will encourage application developers to tap into RISC-V features, as they'll know their code will run smoothly across a multitude of compatible chips. Some organizations may still prefer to work on their own proprietary extensions in private for commercial reasons, or because they've thought of an addition no one else has considered, or because their chips will only ever run their code anyway. That's fine by Himelstein.

"It's a contributor culture. If there's enough people willing to [collaborate to standardize an extension], then it happens. And if not, then it doesn't and people may go off and do their own thing, and it's okay with us," Himelstein said.

For example, if the survey shows enough enthusiasm for support for 8-bit floating point, or FP8, which Nvidia boasted about last week as a feature in its Hopper GPU, RISC-V International will start a discussion on standardizing such an extension. If not, folks are free to come up their own custom extensions for it.

"There are alternative floating point formats out there. Last year we did ... half-width IEEE floating point. But another one that's really popular especially in embedded is bfloat16 for machine learning. We couldn't get to it last year. We're working on getting to it this year," Himelstein said.

Imagination, which licenses GPU blueprints to system-on-chip makers and has its own RISC-V-compatible CPU designs, said components shipping with ratified extensions is key for establishing a strong RISC-V ecosystem.

"Having many custom unratified extensions in the market will hinder the wide adoption of RISC-V," Shreyas Derashri, Imagination's vice president of computing, told The Register. "Imagination fundamentally wants to strengthen the RISC-V ecosystem."

If Imagination produces custom extensions, the biz will work with RISC-V International to get those ratified. "This includes the work around graphics extensions on RISC-V as well," Derashri said.

• SiFive bags $175m to further challenge Arm with RISC-V
• If you want to make your own chip and aren't Microsoft rich, who do you turn to?
• RISC-V's SiFive sells connectivity IP to Alphawave
• Russian chip makers face uncertainty as war drags on

RISC-V released 16 specifications last year, and with more coming this year: what was closed and custom yesterday could be opened up and standardized by the community tomorrow. "Just like in Linux, what may be proprietary today will be sedimented technology in five or three or two years," Himelstein said. "Everybody understands that game because we've been living with it in computers for a long time."

The RISC-V website also has clear nomenclature on the status of specs under development: whether it's under discussion, development, public review, frozen, and whether it's been ratified.

"We're not going to rush to do something and then waste the opcode space and have to redo something later. We can create a new extension, but we'd rather try to do it right," Himelstein said.

It took six years for the RISC-V world to standardize vector specifications. Now RISC-V's leaders are trying to minimize extension overlap on common functionality, such as matrix operations, which are relevant to the ISA's special interest groups focusing on graphics and machine learning.

"The vector team is creating a special interest group that will merge with these guys, and then decide what this thing looks like because there's overlap not only there but in some other places in computer science," Himelstein said. ®