What’s next for RISC V?

Editor’s opinion: Generally speaking, we are big fans of RISC V. It does some things very well, does a lot of other things quite well, and has clear signs of acceptance and appeal. It meets the real needs of the market in an innovative way, exactly what we would like to see in our technology. So we say this from a position of love – RISC V will have big software problems. The good news is that it may not matter.

First, a little background. RISC V is an open source instruction set architecture (ISA), a “free” alternative to Arm. ISAs provide a set of general, important, but unattractive “blueprints” for processors. Every processor needs what ISA provides in order to perform basic mathematical operations. Designing and maintaining them requires a lot of work, but they don’t provide much end-product differentiation, meaning the chip makers who use them see great benefits in outsourcing that work to a third party like Arm.

The whole point of processors is to run some kind of software. Although ISA and the software developer are several levels apart, ISAs are so fundamental to chips that changes to ISAs create real software problems.

Try downloading some popular programming language on your new MacBook with an Apple M1 processor and you’ll likely find that the software doesn’t work on the M1 or requires some alternative beta. This is actually quite important because it means that anyone working with legacy code will have to face considerable difficulty in switching to the new ISA.

ISAs are incredibly sticky, switching to a new one is something most chip manufacturers hate to do. For example, Qualcomm has been building Arm-based chips for decades, and even though Arm is suing them, it’s unlikely that Qualcomm will ever migrate its core products to RISC V because all software written for the chips will do so. based on Qualcomm, bulky. , if not non-working. We don’t want to exaggerate, switching is not impossible, it’s just difficult. As we said above, this is a lot of friction.

A source: cadence

This could have been a big problem for the adoption of RISC V. However, it hit the market at almost the perfect moment. As soon as Arm went dormant in Softbank’s babysitting arms and lost motivation to acquire new customers, for the first time in a decade, convenience food startups began to rise again. This includes the promising growth of convenience food startups in the US and their absolute explosion in China. None of these companies had decades of legacy Arm dependencies and were happy to use a solution that cost nothing.

But there is one problem with all this. RISC V is open source, which means that anyone who wants to develop a RISC V chip is pretty much free to make all sorts of changes to their particular implementation of ISA. This means that RISC V is slightly different for everyone. The RISC V organization foresaw this problem and established a set of interoperability requirements, and while everyone wants to comply with them, there is no real enforcement mechanism to prevent this.

This means that implementation from leading offline RISC V chip developers such as SiFive, Andes, and CodaSIP may vary slightly. Everyone fully observes all the rules, but some people comply more fully. And who knows what’s going on inside many of the big chip companies with RISC V designs.

This probably means that software written for one RISC V chip will not work on another RISC V chip, or at least not work well.

Once upon a time, this would have been a show stop. In the 1980s, a whole war of operating systems broke out, the outcome of which was very dependent on the underlying chips and ISA. These kinds of software problems would seriously reduce the attractiveness of RISC V, especially for some of the more ambitious projects, such as server processors. But this time it will be different. There are actually two reasons why this fragmentation of RISC V software might not matter much.

First, the way we use software has changed. Operating systems matter less than they used to because of the internet and cloud computing (they’re still important, but not in the same way they used to be). As long as this core processor can handle basic web traffic, it will be possible to run software on it. There will likely be issues porting many common software applications to RISC V, and as we’ve often noted, this is a factor that keeps Arm away from the data center, but it’s only a small part of the market.

The second reason it may not matter much is that much of what RISC V is used for is independent of common software—hundreds of RISC V chips are being developed for IoT, industrial, and other embedded applications. We are thinking RISC V will dominate this market. Unless someone comes up with an operating system for the Internet of Things (IoT), these devices don’t really need a common chip architecture. And we firmly believe that will never operating system for the Internet of Things.

It is also possible that someday the RISC V software environment will merge with more compatible solutions. This will take years and cause a lot of problems – does anyone remember the incompatibility between printer and GPU drivers? – but it’s still likely.

At this stage, RISC V looks unstoppable. This is a good thing. But it’s not a one-size-fits-all solution and will face its share of growth issues, many of which will be related to and around software compatibility. It doesn’t present the same barrier that it once did.

Head credit: Rick Mason