Arm reportedly changing licensing model to prohibit custom GPUs and TPUs
9to5google.comThat seems like an incredibly dumb decision. They do realize that RISC-V is right around the corner, and could quickly end much of the ARM chip market if licensing deals are this onerous?
It’s not just right around the corner, those chips are already in design phase: Jim Keller at Tenstorrent first wanted to license x86, then ARM to build AI chip, but as both said no, he went with RISC-V.
The funniest part is that he licensed the RISC-V chip from SiFive, which is now part of Intel.
SiFive is not part of Intel. There were reportedly talks last year that fell through.
https://www.tomshardware.com/news/intel-failed-to-buy-sifive
Rumor is Intel made an offer and were laughed out of the room.
Walking away from 2bn is gutsy.
It is a short term cash grab, which will accelerate investment in RISC-V.
RISC-V seems increasingly inevitable in much of ARM's former feeding grounds, something I doubt ARM is unaware of, so it makes sense from a business perspective to squeeze out every cent while you still can.
There's an IMHO better article[0] on the same subject.
0. https://www.semianalysis.com/p/arm-changes-business-model-oe...
So it begins.
RISC-V and Chinese chips are coming for ARMs lunch.
Wasn’t this whole thing a somewhat sketchy attempt by Qualcomm to change its licensing terms by acquiring a company with a different business model and therefore different Arm license?
Seems like Arm is trying to close licensing loopholes.
I doubt that there's any credible claim to the acquisition of a license from an acquired company being a loophole. If it was, it wasn't something ARM paid attention to for 20+ years. ARM didn't have a problem with Compaq/DEC transferring its StrongARM IP to Intel. Nor did ARM have a problem with Intel selling off part of the XScale line to Marvell. Even if Nuvia merely sold its architectural license in place of being acquired outright, Qualcomm would still have a strong case to claim that it does have architectural rights.
It comes down to specific legal language of the various licenses, not an analysis of what Arm did in the past. The claim is credible enough that the court didn't dismiss it out of hand. Armchair analysis without the actual licenses and some legal knowledge aren't all that helpful.
The lawsuit states
"Nuvia's licensing fees and royalty rates reflected the anticipated scope and nature of Nuvia's use of the Arm architecture. The licenses safeguarded Arm's rights and expectations by prohibiting assignment without Arm's consent, regardless of whether a contemplated assignee had its own Arm licenses."
So Arm's case seems to hinge on whether or not the license language covering the prevention of assignment will be held up in court as applicable to this situation. That's the kind of legal dispute which will be very technical and not easy to speculate about... definitions of individual words and intent and all of that.
> Armchair analysis without the actual licenses and some legal knowledge aren't all that helpful.
I didn't claim that ARM lacked a case. My point was that acquiring another company's license is not in and of itself a "loophole", a word I find to be heavily abused. As you mentioned, the language of the particular licenses will dictate the outcome of this case. But as ARM has not as yet made those terms clear to the public, the most one can do is look at past behaviors and rule out certain arguments. My evaluation may change as more information becomes available.
And given the circumstances, ARMChair analysis is entirely appropriate.
No one is suggesting they cant sell their license to another company. ARM is only claiming those special deals, likely cost per core are only applicable to Nuvia and not Qualcomm.
Arm is suggesting that they have language in their license explicitly preventing sale of the license.
It would be irrelevant to the lawsuit, as Qualcomm have a license that allows them to create designs such as the one they got from Nuvia, to begin with.
Yes I am wondering if those are specific to Qualcomm. And we wont know until all the details are given. But from the POV of ARM, Qualcomm got Nuvia's license which was favourable to Startup, and Server Market. Qualcomm intend to use it on PC and Smartphone. Obviously ARM think the terms would be different but Qualcomm disagree.
The original article and other media keeps painting it as some sort of revenge for not allowing Nvidia buying ARM. I dont even see how the two comes together when regulations and other parties are at play as well.
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.
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.
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.
>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.
> 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.
>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.
>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.
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.
> 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.
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.
Why would this prevent SoCs?
"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...
It will not.
The industry will simply speed up RISC-V adoption.
Isn't this basically the nightmare scenario that everyone feared about the NVIDIA acquisition?
Not really. The NVIDIA acquisition would be done already.
This is happening way later, with an industry that's already chosen to and taken steps to migrate to RISC-V, and thus is much better prepared to cope.
Apple migrating to RISC-V in 3... 2... 1...
This change doesn't affect Apple. Apple has a perpetual "do whatever you want" license because they were involved with ARM early on.