In almost every discussion of RISC V’s position in the ecosystem the Instruction Set Architecture (ISA) is positioned as a direct competitor to Arm. Most people view the two ISAs as being engaged in a winner-take-all, zero-sum contest, where there can only be one. We think the world, at least for the foreseeable future will see much more mixing and matching, with both sitting beside each other in ever more heterogenous chips.

Admittedly, the entire history of technology is against us on this one. Over the past forty years we have seen the same pattern repeat itself – software ecosystems tend to consolidate down to a single platform. No one wants to have to write the same software twice, and not just write but design, test and debug. Developers have thus tended to follow their specific profit-maximizing path, which leads in time to one platform.

That being said, that old truism is not 100% accurate. Moreover, ISAs are not exactly software.

Much of the functionality of ISAs rests in providing a common set of low-level language tools that make it possible for higher level software to make the most use of the chip running each ISA. So some of those software tendencies still hold. For user-level functionality (aka applications, infrastructure and apps) a penalty remains for having to support multiple ISAs, witness Arm’s decade long slog to enter the data center. On the other hand, ISAs are rarely touched directly by this kind of software developer. Instead, the ISAs matter most to chip designers. They do not necessarily want to support multiple ISAs either. This requires having multiple sets of tools and expertise. But this is a much smaller audience and a much more manageable problem. The cost/benefit math works out differently here. For a growing number of chip designers, the benefits of using multiple ISAs are enough to merit the cost of supporting both.

Chip designers tend to have teams sizable enough to support multiple layers of design expertise. And not all chip workloads are equal. In many cases, designing RISC V cores next to Arm cores can lead to better solutions. RISC V cores are not exactly free, but Arm cores tend to cost more and the company seems intent on raising those prices further. Arm cores are also largely fixed in their capabilities, while RISC V cores are positioned as being very ‘flexible‘ (again, not exactly, but close enough for our purposes here). By mixing and matching the two systems, chip designers can find more optimal paths for what they need.

We have seen this in practice widely already. Apple’s A- and M-Series processors seem to have both Arm and RISC V cores in them, as do Google’s TPUs. And this is true for many, many other chips as well. We recently spoke with one designer deep in the IoT landscape who we assumed used only RISC V, but he was quick to point out that no, “I use both”. This all costs a bit more in terms of upfront costs and design team size, but the benefits clearly outweigh those costs in many cases.

Will this remain the case forever? Ask anyone on either side, and they are quick to say no. Highlander rules apply, there can be only one. However, in practice we are not so sure. Chips are changing, becoming more diverse and heterogeneous, as designers search for ways to cope with the slowing of Moore’s Law. This has opened up the door to a rethinking of past rules. And so we expect that for a long time to come, we will see both RISC V and Arm sitting next to each other in many chips.