[Conan_Kudo]

This change would potentially lead to ARM licensees switching from integrated SoC models to more conventional split architecture designs where the CPU, GPU, and other significant processors are split into separate dies to maintain flexibility.

The main problem with this is going to be on mobile phones, where board space is at a steep premium. Other form factors that typically have multiple processors will probably be fine, though.

[ErikCorry]

For ARM to force their customers to avoid SoC designs would be a huge issue, not just in phones.

I can't imagine what ARM are thinking. It's been a competitive advantage over Intel for over a decade that SoC was easy to do with ARM, while it was almost impossible with x86, because of the way IP is managed in the x86 world.

[Conan_Kudo]

I can imagine what Arm is thinking: "we want higher margin customers".

You think that "competitive advantage" helped them any? It certainly didn't. They really want the PC and datacenter space. Apple has proven that alternative architectures aren't dead there, and Arm wants it.

Me personally? I hope this works. The ARM ecosystem as it stands today is horribly broken and promotes e-waste to an extreme degree. I am also under no delusions that RISC-V would be better at this.

[snvzz]

>I am also under no delusions that RISC-V would be better at this.

RISC-V is already way better at this.

e.g.:

The early boot process (SBI) was standardized years ago, and widely deployed in current hardware.

Late boot process (UEFI on RISC-V) was standarized early this year, ahead of relevant hardware (servers, laptops, workstations).

ISA Profiles standard 2022 is in public review right now, and will likely be effective before the year ends. Hardware where this is relevant (e.g. SoC used in VisionFive2) already released this year is already compliant with the draft.

Future hardware will be widely compliant. Linux distributions and other operating systems target these profiles.

Relative to the utter chaos ARM has when it comes to these important topics, RISC-V is way ahead, being well prepared before the hardware floods the world.

[Conan_Kudo]

> The early boot process (SBI) was standardized years ago, and widely deployed in current hardware.

>

> Late boot process (UEFI on RISC-V) was standarized early this year, ahead of relevant hardware (servers, laptops, workstations).

UEFI was standardized for ARM many years before hardware arrived. It didn't matter. It was widely ignored.

As long as we have to use U-Boot and use DTs provided by the OS instead, we're going to be in the same mess that ARM is in. The key is that UEFI needs to be so cheap to integrate by default that nobody can use the excuse of "low end" to avoid UEFI. I have a feeling that's not what's happening in RISC-V.

> ISA Profiles standard 2022 is in public review right now, and will likely be effective before the year ends.

The ability to chop up the ISA is going to have ugly side-effects for development and support of RISC-V. Various ISA profiles and modes already result in different psABIs, which flips the idea from an extensible ISA to a fragmented one.

[Vt71fcAqt7]

>The ability to chop up the ISA is going to have ugly side-effects

The instruction set is already reduced (hense RISC) to the bare minimum for the two important profiles: microcontrolers and linux machines. Microcontrollers will be 32-bit and will nessesarliy have a different tool-chain from 64 bit computers as they won't be running Linux. The only question is will most Linux machines use vector. That is probably a yes. X-86 and ARM are allready fragmented and the software ecosystem survived. Nobody is adding custom instruction to a reduced instuction set just for the sake of it. Also, as RISC-V machines will only run on Linux for at least the next few years, all the software and compilers are open already. So there is no way for a single vendor to lock in the ecosystem.

[snvzz]

>The only question is will most Linux machines use vector. That is probably a yes.

And, while RVA22 does not require vector, the next profile, whenever that happens, is.

[ErikCorry]

You don't think it helped ARM?

For years Intel and AMD wanted Android on x86 to happen, and wanted embedded x86 to compete with ARM. It never happened because in small devices SoC is a requirement.

As transistor sizes shrink it becomes more and more insane to divide your system up into two or more dies just because some IP licensing requires it. ARM are swimming against the tide that lifted them for 20 years here.

They seem to be abandoning the embedded market that made them a huge success in favour of trying to enter a super competitive server market where they are only one of many players.

[Conan_Kudo]

> They seem to be abandoning the embedded market that made them a huge success in favour of trying to enter a super competitive server market where they are only one of many players.

There are two problems here: the assumption that they are "a huge success" and that the server market is "super competitive".

It is extremely clear that Arm is not "a huge success" as a company. They get squeezed by Qualcomm on a regular basis. The margins have been super-thin for many years, and development of initiatives to make ARM more broadly successful have been hamstrung by their own partners and customers who do not care to make the ARM platform bigger. They've hit their limits in the space they're in now.

There are only two players in the server market: AMD and Intel. There are specialized cases of "third leg" options, like the AWS-only Graviton built on ARM ISA and Ampere Altra based on ARM CPU designs on Azure and GCP. There's a ton more opportunity in the server space than the embedded space if they can just get things worked out there. Server customers are more high-value because they are more willing to upgrade equipment. Server designs usually have socketable CPUs, which means there is multiple opportunities to sell to the same customer within a 10 year timespan. It's also cheaper to sell to server customers, because there's less up-front engineering work required to build something to sell. It's just a way better market to target.

[hakfoo]

ARM-the-architecture is wildly successful. ARM-the-company is not.

To me, that says the problem is that ARM-the-company didn't have the right business plan.

However, to say I'm skeptical of this alternative business plan is an understatement. As was said everywhere else, the ability to build a pick-and-mix SoC is what got ARM-the-platform into the niches where it's strongest today.

Maybe the argument they're going for is to deliberately stab at the Innovator's Dilemma: if they burn their ships on mobile and embedded, they won't be reliant on it in the next 10 years as RISC-V eats their lunch.

That requires a huge commitment to this grand new vision of ARM For The Datacentre(tm), and I sort of wonder if this move might spook even that market.

I could imagine that there was some interest in ARM from hyperscalers because it was amenable to more customized SoC-style designs-- bolting on your own preferred bag of accelerators, management features, and specialized communication fabrics on top of a bag of standardized cores.

[yunohn]

Why would this prevent SoCs?

[ErikCorry]

"Qualcomm claims that Arm is telling the OEMs that semiconductor manufacturers will not be able to provide other elements of their Arm-based SOCs that Arm also offers as a licensed product. This includes GPUs, NPUs, and ISP."

From https://www.semianalysis.com/p/arm-changes-business-model-oe...

[snvzz]

It will not.

The industry will simply speed up RISC-V adoption.