Arm reportedly warns Qualcomm it will cancel its licenses

Chip designer Arm has reportedly warned chipmaker Qualcomm it will soon cancel its license to produce processors using its IP. News of that drastic step emerged on Tuesday in a Bloomberg report that claims the newswire has seen an Arm document sent to Qualcomm that warns its architectural license will be cancelled in 60 days …

[martinusher]

I can guess where this is leading

ARM seems to be suffering from hubris a bit, its generally the result of being outstandingly successful which causes you to be unable to conceive that the world could just conceivably pass you by if you make too much of a nuisance of yourself.

If I were running Qualcomm I'd be looking very hard at RISC-V -- not openly, of course, you don't want to tip your hand, but the idea that you can have an ISA that you actually control because its standardized must be incredibly attractive. Sure, the ecosystem isn't as widely developed at the moment but when the chips are down -- literally -- one RISC is very much like another.

So don't expect anything dramatic for a few years. The end, when it comes, will be swift and not very nice. I think a wise person would suggest that at this time ARM need Qualcomm just as much as Qualcomm needs ARM and it would definitely be in ARM's interest to keep it that way.

[CowHorseFrog]

Re: I can guess where this is leading

RISCV will never be a top tier ISA.

The idea of optional packages makes it limited to simple designs that are not performant and create fractured platforms. THe same is happening in x86/64 today and its why ARM is getting ahead recently. There are far too many new new instructions (thinking of the vector stuff) being added to x86. This mess means most s/w can only afford to do the work for the most popular not the cutting edge.

[JulieM]

Re: I can guess where this is leading

As long as you have a compiler that is smart enough to make use of the full enhanced instruction set if available or spit out a much longer binary otherwise that will still work on a less capable processor by emulating the missing instructions in software, and a non-fatal test for the presence or absence of the extra instructions, it needn't be a problem.

[CowHorseFrog]

Re: I can guess where this is leading

Oh yes the EPIC promise of wonderful compilers that do everything.

This simply does not exist, if you follow the dotnet or java you will see that leveraging unsupported/unused cpu instructions is still a laborous manual time consuming effort. There are very few players that can afford to do this. THe JIT compilers for both simply are no where near able to use all the wonderful instructions available.

[Tom66]

Re: I can guess where this is leading

Are you kidding? There is huge fracture in ARM ISAs!

For instance, you can target (with gcc): each of armv5hf through armv9hf (each architecture building above the predecessor, adding new instructions and instruction modes); and you can target most of those in non-FPU configuration too. Some of those processors will have vector engines (NEON), some will not even support native integer division (looking at you, Xilinx). All of this ISA madness needs to be sorted out by a combination of compile-time targeting and varying versions of libc or whatever C library you link against, or by the OS kernel trapping undefined instructions and emulating them (which is stupidly slow).

[CowHorseFrog]

Re: I can guess where this is leading

The arms you mention belong too different device markets, there is no real overlap. THis is a very different situation to what we see on x86, where. everybody has a slightly different cpu with slightly different available instructions.

[Proton_badger]

Re: I can guess where this is leading

The RISC-V RVA profile standardizes the set of ISA extensions for general-purpose cores. For example, RVA23 mandates the RISC-V vector extension and the hypervisor extension. In this way it's similar to Aarch64 versions (the latest being ARMv9.6-A) which also has mandatory ISA's for general-purpose cores and optional extensions. I'd say ARM is working hard on becoming almost as huge and complex as AMD64, it's inevitable.

[GraXXoR]

Re: I can guess where this is leading

Methinks you don’t know your ARM from your elbow. J/k.

There are multiple ARM architectures *currently* in production and widely used.

Not to mention all the coprocessors and SOCs based on those chips with wildly different capabilities.

[CowHorseFrog]

Re: I can guess where this is leading

You fail to grasp the concept i was addressing. Each of those different ARM arch address very different devices. THere is basically no overlap, nobody is trying to use ARM1 or ARM2, they are history and buried. Look at Apple as an example, they dont care and abandoned the 32bit arms a long time ago its all 64b. Again there is no overlap where platforms are trying to support dozens of variations.

The binaries produced for each target are not fat they are not trying to run different archtectures, unlike windows stuff which has a lot of cpuid and functional tests to figure out which code paths to use, which makes for very bloated binaries because of dead code.

[doublelayer]

Re: I can guess where this is leading

But you are not correct. Yes, nobody is bothering about ARM1, but they are bothering about ARMV8 and ARMV9. And those who bother about ARMV8 need to tell the difference between ARMV8 and ARMV8.1 and ARMV8.2 and ... That is done in software. There are extensions as well. For instance, I've written software that's running on SBCs and does a lot of AES work. It might be useful for you to know that most if not all of the SoCs used in the Raspberry Pi don't have hardware AES, but a lot of other SBCs do. If you're writing the AES library, you absolutely need to know that. Fortunately for most people, if you're just running it, the library authors already did it for you. There are more of those, and people do check them and respond accordingly. If I want my binary to run well on both platforms, I include a software AES branch and a hardware AES branch. Alternatively, I compile on each platform and I've still written both branches, I just don't compile both.

[CowHorseFrog]

Re: I can guess where this is leading

double: And those who bother about ARMV8 need to tell the difference between ARMV8 and ARMV8.1 and ARMV8.2 and ... That is done in software.

cow: You are taking things to extremes. Of course there are small differences. The differences betwen 8, 81, 82 are minor or small compared to the differences between all the x86 cpus that run on typical desktops.

How many vector instruction sets exist on x86 compared to ARMs with vector ins ?

Its more than 10, how many does ARM 8 have ? (2 or 3).

https://en.wikipedia.org/wiki/X86_instruction_listings

THis list is crazy there are several completely different FPU instruction sets, which all work on todays 86s and are completely different.

[3arn0wl]

What is Qualcomm up to?

Qualcomm expressed an interest in RISC-V in 2017, and had RISC- V microcontrollers in itheir chips by 2019. I'd be staggered if they aren't busy developing some performant RISC-V silicon. They've had the time and have the expertise to design something better than any RISC-V silicon currently available, so why not launch it?

a) They don't consider the lawsuit to be anything more than theatre, and haven't actually developed anything. In that case, Quintaris would be nothing more than leverage against Arm.

b) They have some RISC-V kit, but it's either not very performant, or it's too power-hungry. They announced that they were designing RISC-V silicon for wearables a year ago - where is it?

c) They have the designs, but aren't realising them. Why? Customers and revenue. Qualcomm's fortunes are largely tied to Google's software. For whatever reason, Google has downgraded the development of Android for RISC-V - Android on Arm is the cash cow.

Of course, the same Qualcomm chips could just as easily run AOSP but - outside Chinese handheld hardware - shipping with AOSP-based OSs isn't done (ask yourself 'why not'.) Qualcomm's chips have also been open enough to be able to port a mobile Linux OS, which some OEMs, like Shift, have worked on to offer. That still seems niche though.

Plus, Qualcomm is about to enjoy a lucrative love-in with Micro$oft who, at last, seem to see the value in Windows on ARM.

What if Arm does win the lawsuit? Would that prompt Qualcomm go all-out on RISC-V? Would the consumer stomach a slightly cheaper device with mid-range specs and AOSP?

[Helcat]

Re: What is Qualcomm up to?

You've missed D:

That RISK-V isn't significantly better than ARM, so it's not cost effective (at the moment) to switch manufacturing to the new RISK-V chip, and they're not going to invest in two parallel manufacturing lines so they can have both (again, not cost effective). But if ARM win and Qualcomm lose the licence (which I think would be unlikely) and RISK-V is as good as ARM, then I'd expect a sudden shift to that chipset and Google/Android would likely shift with it.

OR: Google will quietly have a word with ARM and things will just... fade away.

[fromxyzzy]

Re: What is Qualcomm up to?

Apple was working on computer-grade ARM CPUs for a long time before they switched off of Intel, and may not have ever made the switch had Intel not followed a diminishing price/performance curve into oblivion for the foreseeable future. Sure, Apple functionally has infinite money right now, but it's not as if Qualcomm can't finance parallel RISC-V development as a moderately short term drop-in replacement insurance policy if ARM tries to pull something similar.

RISC-V's issues at the moment in comparison to ARM would probably be more related to the swift development of newer standards of implementation, to the point where the newest performant RV chips are already either falling behind or not managing to live up to expectations. See the SpacemiT K1/M1 RVA22 situation. It doesn't help that most RISC-V implementor/manufacturers at this point are somewhere on the level of Rockchip, Mediatek or Allwinner in the ARM world. Building actually compliant and performant RV SOCs should not be a problem for larger manufacturers who are able to take their time getting product to market.

[abend0c4]

Re: I can guess where this is leading

The hard bit is designing and manufacturing the silicon. My guess is that if smaller alternative manufacturers look like they might put a dent in the sales of established chip suppliers they'll rapidly find out how much of that hard bit is the subject of patents or other IP encumbrances. There's also no corresponding barrier to established suppliers offering RISC-V parts in volume: the IP in their proprietary ISAs is a part of their armoury they may well trade to maintain market share.

Qualcomm, though, is a big fish and it will be interesting to see what the game plan is. I'm sure it would have been possible to make this go away and choosing not to suggests the plan is well developed.

[cjcox]

Clarifying

"Look, it's not like Arm was under some kind of license that freely allowed its use." - Matt Mullenweg

[ForthIsNotDead]

Licence

It comes down what it says in the small print of the license agreement. I'm assuming, from ARM's stance, that there is some sort of non-transferability clause in the license that causes the license to evaporate if the company is sold.

[heyrick]

Re: Licence

That may be so, but antagonising one of your main chip producers is... how can I put this delicately? FUCKING STUPID.

Now, maybe ARM sees some extra money in it and maybe that's justifiable. But they should consider the long term damage that could be done if their behaviour pushes a major partner to back RISC-V. Is a cash grab today worth pain tomorrow?

[mattaw2001]

Re: Licence

ARM is trying to setup a new business model over the last few years with their licenses, and my guess is 10's or 100's of $millions of revenue per year from Qualcomm riding on this case. That figure rises to potentially $billions per year as if a court win means ARM can renegotiate with Apple and the other other architecture licensees. That amount of money makes almost any game worth playing.

Additionally the ARM - Qualcomm relationship is more complex than your quick comment implies. Qualcomm is also a massive IP company in radio, video decode/encode, GPU, and SoC too. They are also very litigious as well. Likely there are license fees from ARM to Qualcomm for various patents (but nowhere near the fees Qualcomm pays to make ARM right now).

[Donn Bly]

Re: Licence

The problem I see is that if existing licenses aren't transferrable, then anybody who has such a license and has developed products or intellectual property with it cannot put any kind of a value on that IP or product design, as it would go away in any sale or merger.

The second problem is that if ARM is trying to build a business model on non-transferrable licenses, then they really can't consider those licenses to have recurring revenue because all a licensee has to do to terminate is sell themselves to themselves.

[doublelayer]

Re: Licence

Neither of those are realistic problems with such a license. The license is of lesser value than one without the prohibition and I wouldn't want to sign one, but it is easily accomplished. First, the license can be non-transferrable without ARM's permission, but if they approve, or more likely if the purchasing company gives ARM some of the money, they can accept it. That reduces rather than eliminates the sale value of the IP, to say nothing of the making actual products value of the IP. The problem of the license being easily cancelled is easily fixed by making it survive an attempt to sell to the same person, to a holding company owned by the same people, etc, and that's if you need to do that at all. There's not many reasons why a company would want to cancel the contract. They've already paid for their end, and if they cancel the contract, they have to stop selling and, if you believe ARM's lawyers in this case, destroy the plans for, the things they built under the contract, so they don't want that thing cancelled.

[Anonymous Coward]

Re: Licence

"The problem I see is that if existing licenses aren't transferrable, then anybody who has such a license and has developed products or intellectual property with it cannot put any kind of a value on that IP or product design, as it would go away in any sale or merger."

Isn't that exactly the situation that AMD & Intel are in regarding x86/x86_64? that their cross-licensing disappears in a "poof!" if either of them is bought...which is likely why no-one bought AMD years back (prior to their Zen renaissance) when they were in severe financial trouble.

[EvaQ]

Re: Licence

"The problem I see is that if existing licenses aren't transferrable, then anybody who has such a license and has developed products or intellectual property with it cannot put any kind of a value on that IP or product design, as it would go away in any sale or merger."

Is that a problem? Not for ARM, I would say. It puts ARM in a very powerful position. A potential buyer then clearly knows he has to negotiate with two separate parties: the to be taken-over party, and ... nice & friendly & understanding ARM. And ARM can look into the pocket of the (big) buyer.

[sjb2016reg]

Pyrric victory

As the first poster says, this seems like a bad battle to be having for Arm, and does show their hubris. Having worked there for a few years, I can see how that might happen ;)

But really, what is the upside here? Qualcomm is already a licensee of some sort, so surely if they bought Nuvia, then Qualcomm has a licence either way (either their own or Nuvia's). Obviously, I am not a lawyer.

Seems like these kinds of battles will push the lower end (but absolutely massive quantities of chips) to RISC-V, because compatibility and performance aren't required for these embedded chips. So, it might be harder for the high-end to leave the Arm ecosystem, but if Arm are bullying "partners" then the partners might try and put the effort in to make RISC-V more viable on the high-end. And surely, Apple is already working on RISC-V designs because they're Apple.

[VeryRealHuman]

Re: Pyrric victory

I think it's a different kind of license they're fighting about, specifically one to design custom Arm cores.

[FIA]

Re: Pyrric victory

But really, what is the upside here? Qualcomm is already a licensee of some sort,

They're a an architectural licensee, so can use Arm designed cores.

The instruction set licence (design your own core to implement the Arm instruction set) is more expensive.

so surely if they bought Nuvia, then Qualcomm has a licence either way (either their own or Nuvia's).

That's the argument. They claim they do because they bought the licence, Arm claim that licence couldn't be transferred so they don't. Lawyers will decide.

And surely, Apple is already working on RISC-V designs because they're Apple.

I'd be surprised if they were, there's probably no need for them to do so. Apple were one of the founders of ARM, putting in the cash. The rumour is they have a 'special' licence. If you've no financial or legal barriers to continue using the architecture, what would be the point in changing?

[martinusher]

Re: Pyrric victory

If you go back to basics then the the only difference between the original ARM and a RISC-V is the number of registers (16/32) and the ARM's built-in 'skip on test' capability in its instruction set. To put it simply -- one RISC looks very much like another.

Now obviously add in a few decades' worth of development and evolution and today's ARM is rather different from the original. But that's like saying that today's x86 is nothing like the original x86. The modern x86 incarnations are very much more capable but they evolved like fungal growth rather than being designed. This has led to compatibility issues (discussed elsewhere) and likely considerable inefficiencies. A clean slate design starting from what we know now rather than a series of "it seemed like a good idea at the time" steps will pose a formidable threat to the status quo.

(This is also the danger in software. HarmonyOS is the sort of product that would never be developed unless it was forced on a company -- commercially it makes more sense to go with the flow. But we forced the build/buy tradeoff to 'build' so now we have a competing clean room design that has learned from decades of industry experience.)

[CowHorseFrog]

Re: Pyrric victory

Todays x86 still suppots the original x86 instructions, even if they are executing in some protected mode.

Todays arms instructions are very very different from the original, encoding, binary and everything.

[Pope Popely]

"designed to strongarm a longtime partner"

I see what you did here

[An_Old_Dog]

Re: "designed to strongarm a longtime partner"

... or was that, [Intel] "StrongARM™"?

[druck]

Re: "designed to strongarm a longtime partner"

StrongARM was DEC, Intel were responsible for the short lived XScale abhoration, before they realised they couldn't design anything but x86 and flogged it to Marvell.

[Anonymous Coward]

Well...

...how does it work with Altera? They were bought by Intel and somehow their license still applies.

[Tom66]

Re: Well...

Altera don't design custom ARM cores, they use licenced ARM IP. Same as Xilinx now owned by AMD with their Zynq-7000/Zynq Ultrascale, it's just a regular-degular Cortex-A9 or Cortex-A53 + Cortex-R5F in those.

I expect ARM keep the "pre-baked IP core" and "implement your own processor using the ARM ISA" products as separate licences, with different fees and restrictions.

[HuBo]

Timely reminder

Great to read this update on the ARM-Qualcomm conflict which has lasted more than 2 years without a resolution, as reported on by Chris in 2022, and by Dylan in 2023 (also briefly mentioned by Tobias earlier this year), that resulted from Qualcomm's acquisition of Nuvia in 2021-2022 (piece by Matt) (as stated by Simon in TFA).

Oryon is a good core and it would be a shame not to see it come to market, but if ARM lets Qualcomm get away with its folkloric interpretation of license transfers it'll end up the IP laughing stock of the industry. With "trial fast approaching in December", it's high-time for a settlement that can satisfy both parties imho.

[StrangerHereMyself]

RISC-Y business

Or should I say RISC-V business.

RISC-V is already eating ARM's lunch in the embedded market. How long before Qualcomm releases a RISC-V device which attains parity with ARM's A-processor (application) offerings?

Google is already working on a RISC-V port of Android so when these two planets align ARM will be done for. ARM's merely gouging because they still have the upper hand and they know that in the end they'll fall by the wayside.

[JLV]

Seems a tad predatory and nuclear from ARM, but a) that's what a near monopoly allows and b) it'll be clear enough if it's in the contract. Anyway, that's the same Qualcomm that likes to bundle-foist immature 5G modems on phone vendors, right?

Popcorn. With beer.

[Proton_badger]

Yeah, ARM is doing to QC what QC is famous for doing with their modems. Pressuring them to an expensive settlement or else..

[mark l 2]

While RISC-V is almost certainly being investigated by Qualcomm for future SOC, the fact that at current Android and more importantly the millions of Android apps are not RISC-V compatible means that they will need to play ball with ARM or risk loosing their market share.

Plus Microsoft have bet big on Windows on ARM and im sure they aren't want to get to a situation where their largest Windows on ARM chip supplier is moving to another incompatible ISA.

[aks]

Re Microsoft: It seems to me that Microsoft want to unhook from x86 and become much more architecture independent. Assuming a more layered approach to their offerings. If that is so, x86, arm and RISC-V will reside within a discrete layer. Windows 8 (spit0 was an attempt to unify the UX layer across desktop, tablet and mobile, albeit a failed one.

[An_Old_Dog]

Huh-what?

I'd always thought Android apps were written in Java. Why would the apps be CPU-architecture dependent?

(I can see a Java interpreter being CPU-dependent, and an operating system [such as Android] being even moreso ...)

[CowHorseFrog]

Re: Huh-what?

JVM is a stack based machine, while the android byte code is for a cpu with a fixed number of registers. Diff cpus have diff general puprose register counts

[doublelayer]

Re: Huh-what?

Most of the frontend parts of apps are written in Java or another JVM-executed language. Kotlin is quite popular as well, but that is run in the JVM. Then they want to do something in the backend and most of them call out to a native library which is written for a specific architecture. In some cases, they may do similarly to write their frontend in something that isn't Java.

If you want to check this any time, you can see whether an application is architecture-dependent if you have an APK file for it (and if it's installed on your phone, you can get an APK for it). Open that file in an archive program and see if there's a lib folder at the top level. If there is and there's stuff in it, then it is architecture-dependent and you can see which ones they bothered to compile for. Usually, it's one chosen version of ARM and that's it. For things that are intended to be much more portable, it's usually ARM 32-bit and 64-bit and X86 32-bit and 64-bit, and that's it. It will still need recompiling if RISC-V is going to be used.

[ecarlseen]

Interesting watching people assume...

...Qualcomm can just spin up a bunch of RISC-V cores that are optimized to anywhere remotely near where their ARM cores are like it's no big thing. That's probably a five-year, multi-billion-dollar road, assuming you have the personnel and resources to divert to it. This is roughly how long it took Apple to get to their first fully-built-from-scratch ARM cores, and their current chips have more than a decade of refinement past that. Every micro-architecture engineer you move to RISC-V has to be taken from somewhere else, and they don't exactly grow on trees. The elite ones are so rare that if you want them you just buy the company they work for (as both Apple and Qualcomm have done).

In the meantime, Qualcomm either has no products to sell or they (likely) still have to cough up the Arm money.

Considering that Qualcomm is notorious as being one of the most abusive chip vendors in terms of licensing agreements (they are to hardware what Oracle is to software), and they're well-known for treating their engineers like disposable garbage, I'm just going to enjoy watching them reap some richly-deserved karma.

[druck]

Re: Interesting watching people assume...

Apple's fully built from scratch ARM's were designed by the team from the company Pa-semi that they bought, which was formed by the designers of the Alpha and StrongARM after they left DEC. So it actually goes back a very long way.

[ecarlseen]

Re: Interesting watching people assume...

Yes, that was a fantastic buy for a hell of a team. I think they paid under half a billion USD for it as well.

[Fruit and Nutcase]

RISC-Y Business

Reminded me of the plot for "Risky Business" 1983 film with Tom Cruise and Rebecca De Mornay.

https://en.wikipedia.org/wiki/Risky_Business

Let's just imagine that "Lana" is Arm, who licences her IP to paying punters, and that one such punter is "Joel" - Qualcomm...

At the end of the film...

"Joel meets Lana at a restaurant, and they speculate about their future. She tells him that she wants to keep on seeing him; he jokes that it will cost her."

icon: where's the parody icon

[Oh Homer]

Actually ...

ARM is technically correct, licenses are not transferable.

Although Qualcomm's argument seems to be that it was already licensed for exactly the same IP as Nuvia, which seems unlikely, but I guess we'll soon find out.

The only significant takeaway I get from this is that IP is, as ever, a cancer, and that we'd all be much better off if it had never been born.

[doublelayer]

Re: Actually ...

And if, therefore, every processor designer put in custom extensions designed to make it difficult to copy their designs because otherwise any of the expensive effort involved in designing a good chip or ISA was taken by free for others? That's what you would have gotten if IP wasn't a thing. And if anyone mentions it, RISC-V is not a counterexample. The core instruction set is public, but manufacturers' designs are protected by IP and extensions may be as well, though sometimes they choose to be open with those in the hopes that others will use them and require them in their software which would advantage their chips. That does a lot of negative things, for example why I'm worried about RISC-V fragmentation weakening the architecture, but it does mean companies can design new and better chip designs which is necessary for any meaningful progress.