Editor's take: Generally speaking we are big fans of RISC V. It does some things very well, handles many others well enough, and has clear signs of adoption and appeal. It meets a real market need in an innovative manner, exactly what we like to see from our technology. So we say this from a position of love - RISC V is going to have a big software problem. The good news is that it may not matter.
First, some background. RISC V is an open-source instruction set architecture (ISA), a "free" alternative to Arm. ISAs provide a set of common, important but unglamorous "blueprints" for processors. Every processor needs what an ISA provides to do some basic math. They take a lot of work to design and maintain but do not provide much end-product differentiation, which means that the chip companies who use them see great advantage in outsourcing this work to a third party like Arm.
The whole point of processors is to run some form of software. And even though the ISA and the software developer are several layers apart, ISAs are so fundamental to chips that changes in an ISA create real software problems.
Editor's Note:
Guest author Jonathan Goldberg is the founder of D2D Advisory, a multi-functional consulting firm. Jonathan has developed growth strategies and alliances for companies in the mobile, networking, gaming, and software industries.
Try downloading some popular programming language on a new Apple M1-powered MacBook and you are likely to find that the software does not work on the M1 or requires some alternative beta version. This is actually fairly important because it means that anyone running legacy code has to endure significant friction to switch to a new ISA.
ISAs are incredibly sticky, changing to a new one is something that most chip companies loathe to do. For instance, Qualcomm has been building Arm-based chips for decades, and even though Arm is suing them, it is unlikely that Qualcomm would ever move its core products to RISC V because it would render all the software written for Qualcomm-based chips unwieldy, if not unworkable. We do not want to overstate this, switching is not impossible, it is just hard. As we said above, it is a lot of friction.
Source: Cadence
This could have been a big problem for RISC V to gain adoption. However, it entered the market at an almost perfect moment. Just as Arm went into hibernation in the coddling arms of Softbank and lost its motivation to attract new customers, semis startups started sprouting again for the first time in a decade. That includes budding growth of US semis startups and an absolute explosion of them in China. None of those companies had decades of legacy Arm dependencies and were happy to go with the solution that cost nothing.
But there is one problem with all of this. RISC V is open-source, which means that anyone who wants to design a RISC V chip largely has the flexibility to make all sorts of changes to their specific implementation of the ISA. That means that everyone's RISC V is a little different. The RISC V organization foresaw this problem and laid down a set of compatibility requirements, and while everyone wants to abide by those, there is no real enforcement mechanism to prevent it from happening.
This means that implementation from leading standalone RISC V chip designers like SiFive, Andes and CodaSIP may all be slightly different. Everyone complies completely with all the rules, but some people comply more completely. And within the many large chip companies with RISC V designs, who knows what is going on.
This probably means that software written for one RISC V chip will not run on another RISC V chip, or at least no run well.
Once upon a time that would have been a show stopper. The 1980's saw a whole war of operating systems whose outcome depended very heavily on the underlying chips and ISAs. This kind of software problem would have severely hobbled the appeal of RISC V, especially for some of the more ambitious projects out there like CPUs for servers. But this time will be different. There are really two reasons why this RISC V software fragmentation may not end up mattering that 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 still matter but not in the same way.) So long as that underlying processor can handle basic web traffic, there will be a way to run software on it. There will likely be problems porting many common software applications to RISC V, and as we have noted often, this is the factor that kept Arm out of the data center, but that is only a small part of the market.
The second reason why this may not matter much is that so much of what RISC V is being used for does not rely on common software - there are hundreds of RISC V chips being designed for IoT, industrial and other embedded applications. We think RISC V will come to dominate this market. Unless someone comes up with an operating system for the Internet of Things (IoT), there really is no need for a common chip architecture for these devices. And we are firm believers that there will never be an operating system for IoT.
It's also entirely possible that someday RISC V's software environment will converge on more compatible solutions. This will take years and be full of sorts of problems – anyone remember printer and GPU driver incompatibility? – but it is still likely.
At this stage, RISC V looks unstoppable. That is a good thing. But it is not a one-size-fits-all solution, and it will encounter its share of growing pains, and many of those will take place in and around software compatibility. This does not present the same barrier it once did.