Post by @david_chisnall@infosec.exchange

@whitequark

RISC-V gained a lot of early adoption by replacing weird in-house ISAs that people were using for control-plane things. Most of these didn’t really have serious PPA requirements. They were a tiny fraction of a total chip so even doubling the area or power made a negligible impact on the total chip.

When I was at MS, I worked with a team to replace an Arm core with a RISC-V core. The core was around 1% of the total area of the subsystem, the subsystem was around 1% of the total area of the SoCs that it went in. The choices were:

Arm
Some bespoke in-house ISA.
Some other licensed core.
RISC-V

RISC-V won because we could get (or build) cores that we could integrate in the subsystem and license onwards (Arm would not allow us to sublicense one of their cores in the subsystem, their lawyers don’t like money unless they’re allowed to lick it first). Anything else came with toolchain-maintenance expenses which would easily be more than the cost of a core license.

The big win for RISC-V was that someone else paid for the toolchain and the licenses were lower than anything else where that was the case.

@krono @whitequark

SPARC had an open ISA. Leon was a series of 32-bit SPARC backed by ESA. Sun also opened the UltraSPARC T1. Both were fairly low-end cores (the T1 was okay in aggregate but pretty slow per core).

SPARC had a bunch of interesting ideas. Register windows are one of those ideas that was good on simple cores, annoying on more complex ones, but I think would actually be nice on a very high-end core if you nicely integrate it with register rename and asynchronous spill, but not quite the way SPARC specifies it. SPARC had a simple SIMD extension, but it was roughly comparable to MMX, nothing newer.

SPARC at Sun / Oracle stagnated because the Rock team (building high-per-thread performance cores) and the Niagara team (building massively multithreaded systems) hated each other. To add anything new to the architecture required both to agree, but if one agreed the other would disagree on principle. So the architecture is quite a nice '90s design that hasn't evolved.

After the Oracle acquisition, everyone got quite nervous that Oracle probably had some patents on things that might be necessary for good SPARC implementations and would be very aggressive about enforcing them.

POWER is more fun. When I was at Microsoft, we had a choice for first-party cores for Azure (later cancelled in favour of first-party SoCs using Arm-licensed cores) of:

Buy AMD and do x86. AMD's market cap was $30 B, so easily affordable (Microsofts' was around $850 B), but probably impossible to get past the regulators. They were already tested at-scale in Azure and Xbox, not clear what would be useful differentiation.
An in-house ISA. We went a really long way along this and concluded that we could do 0-20% (depending on workload) better performance than AArch64 by learning from their experience. The cost of this would be huge for the software ecosystem and most customers weren't willing to pay for performance so the business case wasn't there.
AArch64 is a nice mature ecosystem (not as mature as x86-64 but well supported by a bunch of things), a well-designed ISA, and Arm has nice agreements with architecture licensees that mean you can collaborate on designing a feature and be first to market with it, but also know that other people will adopt it so your customers will use it knowing that there's no long-term potential for lock-in.
RISC-V. Discounted because the number of extensions you'd need to turn it into a competitive server architecture was close to designing a custom architecture. The ecosystem was immature and so this had no real benefits relative to a custom architecture.
POWER. Visual Studio could target PowerPC and Windows could run on it because of the Xbox 360. IBM supported Linux and so a fairly good ecosystem. OpenPOWER was, apparently, an open-source ISA, so this gave us the benefits of RISC-V but with a mature server architecture (and not just the ISA, all of the RAS things for POWER were mature because IBM knows how to build mainframes).

The problem with POWER was that we never got IBM to say what 'open source' meant. Is there a license for all patents required to implement the ISA? If so, does this apply if we made changes? Is there a process for extending the architecture in a way that won't conflict with other vendors (or, at least, is discoverable)?

I suspect we'd have gone with POWER if IBM's lawyers had been willing to give Microsoft's lawyers a straight answer to pretty much any question.

The patent issue is also a problem for RISC-V. Members of RVI have to disclose IP for extensions that they participate in designing, but that's it. There's no defensive patent portfolio for RISC-V and there are a lot of patents in techniques for implementing high-performance microarchitectures.

Arm has the Arm Partner Agreement that gives some quite impressive protection. It not only gives all partners access to all patents owned by other partners that are required to implement the architecture (not necessarily with the most efficient implementation), it also gives Arm the ability to use any of those patents to sue anyone who sues any Arm partner for anything necessary to implement the architecture.

A former colleague pointed out that Arm gets to specify what their patent shield covers, which gives them a fairly easy path to coopting the RISC-V ecosystem: they could bless a set of extensions and say 'Any Arm partner implementing this is covered by patent shield'. Anyone who isn't an Arm licensee is screwed.