There have been some important rumors in the press over the weekend. First, came reports that Intel is looking to buy SiFive, the leading commercial RISC-V implementer. Then news broke that Qualcomm is looking to participate in a syndicate to invest in Arm. Both of these would be very important developments for the semiconductor industry, and highlight the foundational roles of the intellectual property (IP) these companies provide.
First, some background. Modern chips do a lot of things under the hood. And designing those chips is analogous to designing a blueprint for a giant office building. The architect of that building wants to specialize in the overall appearance of the building, major structural issues, customer’s key requirements – thing that will differentiate that architect in winning business. There are a lot of other elements of the design that are hugely important but far less glamorous. Bathrooms for example. The design of the bathrooms is crucial for the people using the building. hey require a lot of thought to sort out plumbing and electrical issues, but the architect has almost no incentive to spend much time on their design. In this example, processor cores are the bathrooms – crucial, design intensive, subject to duplication but totally unglamorous. There are certain types of math that are common to all chips. These are finicky, require a lot of investment, and generally provide no competitive differentiation. Advanced modern chips need many of these. So rather than design these cores themselves, the big chip companies have largely chosen to license these designs from third parties, and copy/paste them into their chips.
Where the bathroom analogy starts to fall apart is that one of the key parts of these processor cores is that they include programming tools. The processor cores interact with the rest of the chip – and through them the software that runs on the chip – through a set of instructions. (These processor cores are also sometimes called Instruction Sets, for this reason.) This is really important because the ability to program these chips creates immense stickiness. Once a company sells a chip that runs software it becomes much harder to switch away from those chips. The instruction set market is prone to monopolies because of that software element. If a company is building a chip they can really only run one instruction set on each chip. They really want to use that same instruction set on all their other chips. There is a fair amount of learning involved for the chip designers and using two instruction sets effectively requires two teams. Moreover, once customers start using those chips they are going to write their own code, and indirectly the instruction set will affect that code’s performance when running on the chip. Which means the customer does not want the chip designer to use multiple instruction sets either. And then in the case of Arm, that has lead to a whole class of engineers trained to use Arm, and thus a re-enforcing cycle is established.
Arm’s instruction sets underlay almost all electronics products today (with the exception of the CPUs in most PCs and servers). For many years, Arm has had an effective monopoly on this corner of the market, a monopoly it established just as the mobile market exploded. Not surprisingly, over the years, Arm began to show all the signs of being a monopoly. Their roadmap slowed, they stumbled to enter new markets, their pricing scared away new entrants. The list goes on. And so a competitor emerged. The RISC V project began life as an academic project and then emerged into a full blown open source community in its own right. RISC V has some nice technical advantages over Arm, but is also subject to all the friction typical of open source – cumbersome decision making, inconsistent quality, and commercialization woes. Despite those, RISC V has grown nicely. Every major chip company has a RISC V design in the works – ranging from science project to fully commercial offering. And there are hundreds of start-ups, especially in China, pushing RISC V into many other products.
As RISC V emerged, Arm has gone through a change in ownership. In 2016, Softbank acquired Arm. And then last year announced they were selling Arm to Nvidia. As we have noted often, this deal threatens to disrupt the status quo. Arm supplies all the large chip makers, if Nvidia acquires this crucial building block of the industry, it will put Arm’s IP in the hands of everyone else’s competitor. There are some clear competitive problems that could prevent the deal from getting regulatory approval. Reportedly, several US companies have complained to the regulators about the deal. China’s regulators are also scrutinizing the transaction, an important market for both Arm and RISC V, and a place where Arm has a whole other set of problems. Our sense is that after Nvidia announced this deal, all the RISC V projects out there got a lot more attention from their corporate parents.
Which bring us to the recent news. Qualcomm’s new CEO is willing to put up $10 billion as part of a consortium to buy Arm, sending is a clear signal. Softbank really, really wants to sell Arm. Almost none of Arm’s customers want to see Nvidia buy them. So maybe an industry consortium of buyers’, managing Arm at arm’s length (pun intended) could solve this problem. A consortium like this that could get close to Nvidia’s asking price may look more attractive to Softbank then a multi-year fight with the regulators. The chip industry has seen this sort of deal work in the past. In 2012, a group of the leading chip manufacturers co-invested in ASML, to help that company fund the investment needed for EUV machines which are now at the heart of leading edge chip production.
At the same time, Intel is taking a close look at one of the leading RISC V companies – SiFive. This is a lower stakes transaction. SiFive does not own or control RISC V, it is just a company that helps commercialize RISC V products. The best analogy is to Red Hat, a leading Linux provider. Chip designers can build their own RISC V chip, but for many it is easier to pay SiFive to do the repetitive bits. It is not entirely clear what Intel would gain from buying SiFive, and can probably be best viewed as a customer support organization to help build up Intel’s nascent foundry ambitions. Or maybe it is just one more attempt by Intel to diversify away from its increasingly struggling CPU business. If Intel does a good job with SiFive (a very big If), they could propel RISC V immensely and create serious competition for Arm.
This leaves us with an immense amount of industry uncertainty. The industry has a dependency on Arm, and its sale could tilt the industry in an entirely different direction. RISC V is enjoying building momentum, but that could deflate if Arm’s neutrality could be guaranteed. And a lot of the outcome will depend not only on the acquisitions but more crucially on the integration of the acquired companies. Good management and a healthy balance sheet will mean the difference between an industry flowing smoothly and one backed up with leaks and busted pipes.
Photo by Bruce Warrington on Unsplash
Um, I think, based on years of working at Google & AWS, that instruction sets are MUCH less sticky than they used to be. Almost all production code is written on mature platforms (e.g. Java. .NET, NodeJS) that make it shockingly easy to change processors. A decade or two ago, when libraries and runtimes were less mature, you would have been right. But I was amazed how easy it was to move big, complicated online services from, for example, x86 to ARM. Which doesn’t invalidate your real points about ARM and RISC V. But it does make Intel’s position look even shakier than many people think.
Fair point. But I’m coming at it from the perspective of someone selling silicon into AWS, GCP etc. We can show them all kinds of great performance numbers, but the conversation always comes down to switching. It takes a fair amount of engineering time to port to a new instruction set. To overcome that hurdle performance has to be A LOT better (which it probably is now for Arm).
My sense is that moving code to a new instruction set is easy enough, compilers and tools, as you say, are pretty good. But the most labor intensive part comes next in optimizing the software for the new instruction. It is one of those 90/10 problems where 10% of the code requires 90% of the work. And when we are dealing with hyperscale scale those performance gains are meaningful.