Qualcomm is known for having a particularly aggressive & hardball-style legal department to enforce its patents on core telecom IP. I believe the most likely outcome is they just settle the dispute here. Arm fighting hardball with hardball.
Which would not really affect the ecosystem of phones using Qualcomm arm chips, it would just change the margins / market cap of Qualcomm.
Yes, longterm Q might invest in their own RISC implementations, but I don't see a viable business case for Qualcomm to just stop ARM development for the foreseeable future.
Qualcomm doesn't have nearly as much to lose as ARM does and they know it.
Qualcomm is almost certainly ARM's biggest customer. If ARM loses, Qualcomm doesn't have to pay out. If ARM wins, Qualcomm moves to RISC-V and ARM loses even harder in the long-term.
The most likely outcome is that Qualcomm agrees to pay a slight bit more than they are currently paying, but nowhere near what ARM is demanding and in the meantime, Qualcomm continues having a team work on a RISC-V frontend for Oryon.
Thing is businesses don't work like side-projects do.
Qualcomm is more or less a research company, the main cost of their business is paying engineers to build their modems/SoCs/processors/whatever.
They have been working with ARM for the last, I dont know, 20 years? Even if they manage to switch to RISC-V, and each employee has negative performance impact of like 15% for 2-3 years this ends up in billions of dollars, because you have to hire more people or lose speed.
If corporate would force me to work with idk Golang instead of TypeScript I could certainly manage to do so, but I would be slower for a while, and if you extrapolate that on an entire company this is big $$.
Just the impact of making this move will have a chilling effect, regardless of the long term outome.
ARM Ltd wants to position itself as the ISA. It is highly proprietary of course, but the impression they want to give is that it is "open" and freely available, no lock-in, etc.
This really brings the reality back into focus that ARM controls it with an iron fist, and they're not above playing political games and siding against you if you annoy their favored customers. Really horrible optics for them.
> Qualcomm is slightly bigger than ARM so it seems like a fair fight to me.
I'm not really sure what you're responding to. It's got nothing to do with size whether or not something is fair, it's what is in the contract. None of us know exactly what's there so if it becomes disputed then a court is going to have to decide what is fair.
But that was entirely not the point of my comment though. I'm talking about how corporations looking to make chips or get into the ecosystem view ARM and its behavior with its architecture and licensing. ARM Ltd might well be in the right here by the letter of their contracts, but that canceling their customer's license (ostensibly if not actually siding with another customer who is in competition with the first) is just not a good look for positioning they are going for.
> 1. Qualcomm develops a chip that competitive in performance to ARM
Virtually all high performance processors these days operate on their own internal “instructions”. The instruction decoder at the very front of the pipeline that actually sees ARM or RISC-V or whatever is a relatively small piece of logic.
If Qualcomm were motivated, I believe they could swap ISAs relatively easily on their flagship processors, and the rest of the core would be the same level of performance that everyone is used to from Qualcomm.
This isn’t the old days when the processor core was deeply tied to the ISA. Certainly, there are things you can optimize for the ISA to eke out a little better performance, but I don’t think this is some major obstacle like you indicate it is.
> 2. The entire software world is ready to recompile everything for RISC-V
#2 is the only sticking point. That is ARM’s only moat as far as Qualcomm is concerned.
Many Android apps don’t depend directly on “native” code, and those could potentially work on day 1. With an ARM emulation layer, those with a native dependency could likely start working too, although a native RISC-V port would improve performance.
If Qualcomm stopped making ARM processors, what alternatives are you proposing? Everyone is switching to Samsung or MediaTek processors?
If Qualcomm were switching to RISC-V, that would be a sea change that would actually move the needle. Samsung and MediaTek would probably be eager to sign on! I doubt they love paying ARM licensing fees either.
But, all of this is a very big “if”. I think ARM is bluffing here. They need Qualcomm.
> Everyone is switching to Samsung or MediaTek processors?
Why not? MediaTek is very competitive these days.
It would certainly perform better than a RISC-V decoder slapped onto a core designed for ARM having to run emulation for games (which is pretty much the main reason why you need a lot of performance on your phones).
Adopting RISC-V is also a risk for the phone producers like Samsung. How much of their internal tooling (e.g. diagnostics, build pipelines, testing infrastructure) are built for ARM? How much will performance suffer, and how much will customers care? Why take that risk (in the short/medium term) instead of just using their own CPUs (they did it in some generations) or use MediaTek (many producers have experience with them already)?
Phone producers will be happy to jump to RISC-V over the long term given the right incentives, but I seriously doubt they will be eager to transition quickly. All risks, no benefits.
Naively, it would seem like it would be as simple as updating android studio and recompiling your app, and you would be good to go? There must be less than 1 in 1000 (probably less than 1 in 10,000) apps that do their own ARM specific optimizations.
Without any ARM specific optimizations, most apps wouldn’t even have to recompile and resubmit. Android apps are uploaded as bytecode, which is then AOT compiled by Google’s cloud service for the different architectures, from what I understand. Google would just have to decide to support another target, and Google has already signaled their intent to support RISC-V with Android.
1. That doesn't mean you can just slap a RISC-V decoder on an ARM chip and it will magically work though. The semantics of the instructions and all the CSRs are different. It's going to be way more work than you're implying.
But Qualcomm have already been working on RISC-V for ages so I wouldn't be too surprised if they already have high performance designs in progress.
That is a good comment, and I agree things like CSR differences could be annoying, but compared to the engineering challenges of designing the Oryon cores from scratch… I still think the scope of work would be relatively small. I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.
> I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.
That makes a lot of sense. RISC-V is really not at all close to being at parity with ARM. ARM has existed for a long time, and we are only now seeing it enter into the server space, and into the Microsoft ecosystem. These things take a lot of time.
> I still think the scope of work would be relatively small
I'm not so sure about this. Remember that an ISA is not just a set of instructions: it defines how virtual memory works, what the memory model is like, how security works, etc. Changes in those things percolate through the entire design.
Also, I'm going to go out on a limb and claim that verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design.
That's not really comparable. Raspberry Pi added entirely separate RISC-V cores to the chip, they didn't convert an ARM core design to run RISC-V instructions.
What is being discussed is taking an ARM design and modifying it to run RISC-V, which is not the same thing as what Raspberry Pi has done and is not as simple as people are implying here.
> Virtually all high performance processors these days operate on their own internal “instructions”. The instruction decoder at the very front of the pipeline that actually sees ARM or RISC-V or whatever is a relatively small piece of logic.
If that's true, then what is arm licensing to Qualcomm? Just the instruction set or are they licensing full chips?
Qualcomm has historically licensed both the instruction set and off the shelf core designs from ARM. Obviously, there is no chance the license for the off the shelf core designs would ever allow Qualcomm to use that IP with a competing instruction set.
In the past, Qualcomm designed their own CPU cores (called Kryo) for smartphone processors, and just made sure they were fully compliant with ARM’s instruction set, which requires an Architecture License, as opposed to the simpler Technology License for a predesigned off the shelf core. Over time, Kryo became “semi-custom”, where they borrowed from the off the shelf designs, and made their own changes, instead of being fully custom.
These days, their smartphone processors have been entirely based on off the shelf designs from ARM, but their new Snapdragon X Elite processors for laptops include fully custom Oryon ARM cores, which is the flagship IP that I was originally referencing. In the past day or two, they announced the Snapdragon 8 Elite, which will bring Oryon to smartphones.
ARM already did the hard work. Once you've ported your app to ARM, you've no doubt made sure all the ISA-specific bits are isolated while the rest is generic and portable. This means you already know where to go and what to change and hopefully already have testing in place to make sure your changes work correctly.
Aside from the philosophy, lots of practical work has been done and is ongoing. On the systems level, there has already been massive ongoing work. Alibaba for example ported the entirety of Android to RISC-V then handed it off to Google. Lots of other big companies have tons of coders working on porting all kinds of libraries to RISC-V and progress has been quite rapid.
And of course, it is worth pointing out that an overwhelming majority of day-to-day software is written in managed languages on runtimes that have already been ported to RISC-V.
The thing about RISC-V is that they indirectly have the R&D coffers of the Chinese government backing them for strategic reasons. They are the hardware equivalent of Uber's scale-first-make-money later strategy. This is not a competition that ARM can win purely relying on their existing market dominance.
That's what's magical about Apple. It was a decade-long transition. All the 32-bit code that was removed from macOS back in 2017 was all in preparation for the move in 2019.
Apple has done it multiple times now and has it down to a science.
68k -> PPC -> x86 -> ARM, with the 64 bit transition you mixed in there for good measure (twice!).
Has any other consumer company pulled a full architecture switch off? Companies pulled off leaving Alpha and Sparc but that was servers which has a different software landscape.
I don't believe any major company has done it. Even Intel failed numerous times to move away from x86 with iAPX432, i960, i860, and Itanium all failing to gain traction.
For Apple it was do or die the first few times. Until x86, if they didn’t move they’d just be left in the dust and their market would disappear.
The ARM transition wasn’t strictly necessary like the last ones. It had huge benefits for them, so it makes sense, but they also knew what they were doing by then.
In your examples (which are great) Intel wasn’t going to die. They had backups, and many of those seem guided more by business goals than a do-or-die situation.
In a way that's also true for the x86->ARM transition, isn't it? I had an MacbookAir 2018. And.. "it was crap" is putting it very, very mildly. Yes it was still better than any Windows laptop I got since and much less of a hassle than any Linux laptop that I'm aware of in my circle. But the gap was really, really small and it cost twice as much.
But the most important part for the working of the transition is probably that, in any of theses cases, the typical final user didn't even notice. Yes a lot of Hackernews-like people noticed as they had to recompile some of their programs. But most people :tm: didn't. They either use AppStore apps, which were fixed ~immediately or Rosetta made everything runnable, even if performance suffered.
But that's pretty much the requirement you have: You need to be handle to transition ~all users to the new platform with ~no user work and even without most vendors doing anything. Intel never could provide that, not even aim for it. So they basically have to either a) rip their market in pieces or b) support the "deprecated" ISA forever.
> Rosetta made everything runnable, even if performance suffered.
I think a very important part was that even with the Rosetta overhead, most x86 programs were faster on the m1 than on the machines which it would have been replacing. It wasn’t just that you could continue using your existing software with a perf hit; your new laptop actually felt like a meaningful upgrade even before any of your third party software got updated.
But ARM and RISC-V are relatively similar and it's easy to add custom instructions to RISC-V to make them even more similar if you want so you could definitely do something like Rosetta.
Qualcomm's migration would be much easier than Apple's.
Most of the Android ecosystem already runs on a VM, Dalvik or whatever it's called now. I'm sure Android RISC-V already runs somewhere and I don't see why it would run any worse than on ARM as long as CPUs have equal horsepower.
Yeah, but Qualcomm doesn’t control Android or any of the phone makers. It’s hard for large corps to achieve the internal coordination necessary for a successful ISA change (something literally only Apple has ever accomplished), but trying to coordinate with multiple other large corps? Seems insane. You’re betting your future on the fact that none of the careerists at Google or Samsung get cold feet and decide to just stick with what works.
it's not about that, it's about running the apps whose makers are out of business or just find it easier to tell their customers to buy different phones
Moving to a whole new architecture is really really hard, no? The operating systems and applications all need to be ported. Just because Qualcomm cannot be friends with arm, every single Qualcomm customer from google to some custom device manufacturer needs to invest years and millions to move to a new architecture? Unless I am fundamentally misunderstanding this, it seems like something they won’t be able to achieve.
On modem side they can move to whatever they want without impacts. But on the apps side they need to run Linux/Android/Windows/etc so are dependent on Arm.
You’re suggesting that Snapdragon processors would switch to RISC-V and that would be no big deal? Presumably Qualcomm is committed to numerous multi-year supplier agreements for the arm chipsets.
Qualcomm pitched Znew quite a while ago. It mostly ditched 16-bit instructions and added a bunch of instructions that were basically ripped straight from ARM64.
The idea was obviously an attempt at making it as easy as possible to replace ARM with RISC-V without having to rework much of the core.
This affects their custom Nuvia derived cores. I'm sure Qualcomm will be able to keep using ARM designed cores to cover themselves while they ween off ARM in favor of RISC-V if they need to.
Apple has (to a first approximation) a royalty-free license to ARM IP by virtue of the fact that they co-founded ARM - so yes, Qualcomm is most likely paying ARM more than Apple is.
Just to clarify for those that don't know ARMs history, Acorn were building computers and designing CPUs before they spun out the CPU design portion.
Apple did not help them design the CPU/Architecture, that was a decade of design and manufacturing already, they VC'ed the independence of the CPU. The staffing and knowledge came from Acorn.
Oh, I was just wanting to clarify the "Apple co-founded".
They had the Newton project, found ARM did a better job than the other options, but there were a few missing pieces. They funded the spun out project so they could throw ARM a few new requirements for the CPU design.
As a "cofounder" of ARM, they didn't contribute technical experience and the architecture did already exist.
Not just telecom, they are just super aggressive in general as a bully with weapons pile. I remember they tried to threaten Opus codec with patents just becasue, when IETF proposed it for Internet standard. Luckily that failed, but it shows their nasty approach very clearly. So now they are getting the taste of their own medicine.
This "cancellation" is likely to be paused until the lawsuit is resolved so it's hard to say what this means. Presumably this is a part of the negotiations going on behind the scenes.
Because of all the discussions in the comments about ARM and RISC-V, could someone explain to me the difficulties of designing a chip for a new ISA?
I'm wondering because to me as a layman it sounds like it's 'only' a different language, so why is it not that easy to take already existing designs and modify them to 'speak' that language and that's it?
Or is an ISA more than just a different 'language'?
Or is hardware not really the biggest problem, but rather Software like compilers, kernels, etc.?
Your view even of human languages is simplistic. Forgive me, I don't mean to be rude, I'm just trying to explain.
You might think that languages are just have different words for the same things.
In reality the problems are where the same things don't exist. People don't view the world the same way and don't have an equivalent word. In Turkish it's very important whether your aunt is on your mother's side or your father's side so there are different words for each....but there's no words for "he" or "she" as they don't bother with gender in sentences.
So for example every conversation converted from Turkish to English loses an important bit of meaning about relationships and the sex of a person has to be inferred from context which is not easy to do automatically.
Similarly computer software....and there's a lot of it.
> Or is an ISA more than just a different 'language'?
It tends to be more like going from C89 to Haskell. You're not just switching the keywords around, but also fundamental architectural concepts. There's still some parts you can recycle and some skills that transfer, but less than you'd like.
> Or is hardware not really the biggest problem, but rather Software like compilers, kernels, etc.?
That's the next problem. Kernels, device drivers, support hardware, a lot of low level stuff needs to be adapted, and even a company the size of Qualcomm doesn't necessarily do everything inhouse, there will be lots of external IPs involved and all those partners need to also be willing to migrate over to a different ISA.
I'd perhaps put ARM vs RISC-V closer to like C# vs Java (or maybe JS vs Python) - on a high level rather similar, but a majority of the specifics don't really line up (especially at the uop level requiring dumping a bunch of previous optimized cases, and adding a bunch of new ones).
> If Arm follows through with the license termination, Qualcomm would be prevented from doing its own designs using Arm’s instruction set
i'm not sure this is true. certainly "chip" IP has been a real legal quagmire since, forever.
but it was my understanding that you could neither patent nor copyright simply an "instruction set".
presumably what you get from ARM with an architecture license would be patent licenses and the trademark. if so, what patents might be relevant or would be a problem if you were to make an "ARMv8-ish compatible" ISA/Architecture with a boring name? i haven't seen much about ARM that's architecturally particularly unique or new, even if specific implementation details may be patent-able. you could always implement those differently to the same spec.
to further poke at the issue, if it's patents, then how does a RISC-V CPU or other ISA help you? simply because it's a different ISA, doesn't mean its implementation doesn't trample on some ARM patents either.
if it's something to do with the ISA itself, how does that affect emulators?
what's ARM's IP really consist of when you build your own non-ARM IP CPU from scratch? anyone have examples of show-stopper patents?
You can patent something like "any possible hardware circuit that implements [the functionality of some weird yet mandatory ARM instruction]". The patent doesn't cover emulators because they're not hardware.
Way back in the day there were some MIPS patents that only covered a few instructions so people would build not-quite-MIPS clone CPUs without paying any royalties.
Most comments here seem to think that Qualcomm has to settle or switch to RISC-V. But from my understanding the article is only about their license to design custom chips with ARM IP, not about using ARM's designs.
For example the Snapdragon 8 Gen 1 uses 1 ARM Cortex-X2, 3 ARM Cortex-A710 and 4 ARM Cortex-A510, which are ARM designs. Their latest announced chip though, Snapdragon 8 Elite, uses 8 Oryon cores, which Qualcomm designed themselves (after acquiring Nuvia).
So is Qualcomm not still able to create chips like the former, and just prevented from creating chips like the latter? Or does "putting a chip together" (surely there is a bit more going into it) like the Snapdragon 8 Gen 1 still count as custom design?
They’re only losing their license to make custom cores. They’re still free to use ARMs own cores.
The reason being that ARM gave Nuvia a license to design cores at a specific rate, then Qualcomm bought them to use those cores. ARM claims that the license to design cores does not have a transferable rate to it.
On mobile devices efficiency is so important, I don't see how Qualcomm would be able to live without ARM licences. RISC-V and other architectures like x86-64 are nice, actually I think the peripheral libraries, boot and stuff like that are bigger headache to replace for Qualcomm's clients given that they can just switch the gcc to a different arch - still if your code is 25% less efficient, that'll be quite noticable for the consumer - or in your battery and weight costs.
What am I not seeing here? I think they'll just settle.
This move doesn't stop Qualcomm from licensing ARMs reference cores, it only blocks them from designing their own in-house ARM cores like Apple does. The vast majority of Qualcomm chips currently on the market are built around reference cores, they only recently got back into the custom core game with their acquisition of Nuvia which also kicked off this dispute with ARM.
There are probably Risc-V companies eagerly anticipating an opportunity in that space, but I don't know if any are in the performance ballpark right now.
Intel's latest Arrow Lake stuff, about to go on sale, is said to have much better power efficiency, FWIW. Something like half the wattage for roughly equivalent benchmark results, according to them.
Samsung phones use both, in a very literal sense. Their flagship devices usually have both Snapdragon and Exynos variants for different regions, and their lower end devices are mostly Exynos across the board.
The S23 line was an exception in using Snapdragon worldwide, but then the S24 line switched back to using Snapdragon in NA and Exynos everywhere else, except for the S24 Ultra which is still Snapdragon everywhere.
Yes it's a confusing mess, and it's arguably misleading when the predominantly NA-based tech reviewers and influencers get the usually superior QCOM variant, and promote it to a global audience who may get a completely different SOC when they buy the "same" device.
Last time I checked, the latest Qualcomm Snapdragon was faster and more energy efficient than the latest Exynos. Especially the top-binned chips that Samsung gets.
Still, the fact that Samsung can swap out the chip in their flagship product with virtually no change other than slightly different benchmark scores means that these chips are pretty much fungible. If either manufacturer runs into serious problems, the other one is ready to eat their market share for lunch.
And Qualcomm is the only competitive ARM chip on the market besides Apple's. And now they are being taken out by ARM. Is it really that expensive to re-license things? This seems self-defeating.
Graviton4 is based on Neoverse V2 which is based on X3.
Neoverse V3 was announced Feb of this year. It should have an 80-85% performance increase and should basically be based on something very close to x925.
ARM licenses cores for both CPU and GPU, not just the architecture.
There are not “plenty of ARM chips designed by multiple companies”, almost all of them except for Apple (and now Qualcomm) use ARMs off the shelf design.
That said, RISC-V is good for embedded applications where raw performance isn't a factor. I think no other markets are yet accessible to RISC-V chips until their performance massively improves.
There is a chip out there that contains both an ARM and a RISC-V core, the RP2350. It's reasonable to assume that the ARM part and RISC-V part are manufactured in the same process. There are some benchmarks pitting the two against each other on e.g. this page: https://forums.raspberrypi.com/viewtopic.php?t=375268
For a generic logic workload like Fibo(24), the performance is essentially the same (quote from above page):
Average Runtime = 0.020015 Pico 2
Average Runtime = 0.019015 Pico 2 RiscV
Note that neither core on the RP2350 comes with advanced features like SIMD.
We're not quite there yet. A bunch of mission critical stuff like SIMD were only added in the last 2-3 years. As it takes 4-5 years to design/ship high-performance chips, we still have a ways to go.
Qualcomm pitched making a bunch of changes to RISC-V that would move it closer to ARM64 and make porting easier, so I think it's an understatement to say that they are considering the idea. If ISA doesn't matter, why pay tons of money for the ISA?
You're confusing the ISA with the chip. Current RISC-V chips are slower than high performance ARM ones, but that's because you don't start by designing high performance chips! You start with small embedded cores and work your way up.
Exactly the same thing happened with ARM. It started in embedded, then phones, and finally laptops and servers. ARM was never slow, they just hadn't worked up to highly complex high performance designs yet.
you don't start by designing high performance chips! You start with small embedded cores and work your way up.
I disagree. For example, the first PowerPC was pretty fast and went into flagship products immediately. Itanium also went directly for the high end market (it failed for unrelated reasons). RISC-V would be much better off if some beastly chips like Rivos were released early on.
The question is more of will your customers agree to go along with this major architectural shift that sets you back on price-performance-power curves by at least five years and moves you out of the mainstream of board support packages, drivers, and everything else software-wise for phones.
Also we should not pretend that ARM is just going to sit there waiting for RISC-V to catch up.
It certainly is easy to casually spread fear and doubt.
But it is really far-fetched to think that the people at Tenstorrent, who have successfully delivered very high performance microarchitectures in other companies before, are lying about Ascalon, and that LG is helping them do that.
It would even be more far fetched to claim that Ventana Veyron V2, SiFive P870, Akeana 5000-series, all of them available high performance IP, are lying about performance.
Two years ago you were saying last year. Last year you were saying this year. Now you’re saying next year. Maybe it’s coming someday but I’m surely not going to believe you for it. Especially since you never seem to have anything to back it up other than, like, random people moving around between these companies soaking up VC funding. Where is the chip that is 70% as good as the competition? Where’s the chip that is competitive with Zen 3? Still seems a ways off, no?
>Two years ago you were saying last year. Last year you were saying this year. Now you’re saying next year. Maybe it’s coming someday but I’m surely not going to believe you for it.
Your apparent beef with me is misguided.
>Especially since you never seem to have anything to back it up
Refer to public announcements by these companies. I am but an observer.
Well you need several years to catch up - and those doing arm are not standing still. Same problem big software rewrites have, some are successful but it takes a large investment while everyone is still using the old stuff that is better for now.
Whether Microsoft has windows running on an architecture is a very different level from whether it’s feasible to use it as a daily driver on windows. The ecosystem is what matters for most people.
Windows for arm hails back to 2011. They’re only just now getting native arm ports for several major packages. That’s ~13 years for a well established architecture that’s used much more universally than RISC-V. They don’t even have arm ports for lots of software that has arm ports on macOS.
RISC-V will take an aeon longer to get a respectable amount of the windows ecosystem ported over.
Arm on windows may date to 2011, but it was mostly a side project with 1-2 maintainers. With sufficient investment, it shouldn’t take 13 years to build up RISC-V support.
Like everything else, it doesn’t matter much. Windows ran on Itanium, Alpha, and as pointed out ARM for over a decade.
Without the ISVs, it’s a flop for consumers.
MS has had an abysmal time getting them to join in on ARM, only starting to have a little success now. Saying “Ha ha, just kidding, it’s RISC-V now” would be a disaster. That’s the kind of rug pull that helped kill Windows Mobile.
Emulators aren’t good enough. They’re a stop gap. Unless the new chip is so much better than the old it’s faster with emulation then the old one was native no one will accept it long. Apple’s been there, but that’s not where MS sits today.
And if your emulator is too good, what stops ISVs from saying “you did it for us, we don’t have to care”? So once again they don’t have to do it at all and you have no native software.
MS can’t drop their ARM push unless they want to drop all non-x86 initiatives for a long time.
>And if your emulator is too good, what stops ISVs from saying “you did it for us, we don’t have to care”? So once again they don’t have to do it at all and you have no native software.
x86 emulation enables adoption.
Adoption means having an user base.
Having an user base means developers will consider making the platform a target.
>Saying “Ha ha, just kidding, it’s RISC-V now” would be a disaster.
Would it now? If anything, offering RISC-V support as well would further reinforce the idea that Windows is ISA-independent, and not tied to x86 anymore.
Fair, though I don’t think translation is a good long term strategy. You need native apps otherwise you’re always dealing with a ~20-30% disadvantage.
The competition isn’t sitting still either and QC already hit this with Intel stealing their thunder with Lunar Lake. They’re efficient enough that the difference in efficiency is far overshadowed by their compatibility story.
Ecosystem support will always go to the incumbent and this would place RISC-V third behind x86 and ARM. macOS did this right by saying there’s only one true way forward. It forces adoption.
I think you just ignored the rest of my comment though which specifically addresses why I don’t think just relying on translation is an effective strategy. Users aren’t going to switch to a platform that has lower compatibility when the incumbent has almost as good efficiency and performance.
I think it's already a great thing for RISC-V, imagine things somehow go well for Qualcomm, do you really think they wouldn't prepare a plan B given ARM tried to get them out of the market?
I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.
This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia.
At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite.
The proposed extension was actually not bad, and could very reasonably be adopted.
Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years.
So they'd have to support both "C" and its replacement anyway.
Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.
They can roll their sleeves up and do the small amount of work that they tried to persuade everyone else was not necessary. And I'm sure they will have done so.
It's not that hard to design a wide decoder that can decode mixed 2-byte and 4-byte instructions from a buffer of 32 or 64 bytes in a clock cycle. I've come up with the basic schema for it and written about it here and on Reddit a number of times. Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.
Not that anyone is going that wide at the moment. SiFive's P870 fetched 36 bytes/cycle from L1 icache, but decodes a maximum of 6 instructions from it. Ventana's Veyron v2 decodes 16 bytes per clock cycle into 4-8 instructions (average about 6 on random code).
This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
If you trust PR (I don't, and I worked on Android for 7 years until a year ago) - this is a nitpick 5 levels down -- regardless of how you weigh it, there is no Android RISC-V
There is no Android RISC-V. There isn't an Android available to run on RISC-V chips. There is no code to run on RISC-V in the Android source tree, it was all recently actively removed.[1]
Despite your personal feelings about their motivation, these sites were factually correctly relaying what happened to the code, and they went out of their way to say exactly what Google said and respected Google's claim that they remain committed, with 0 qualms.
I find it extremely discomfiting that you are so focused on how the news makes you feel that you're casting aspersions on the people you heard the news from, and ignoring what I'm saying on a completely different matter, because you're keyword matching
I'm even more discomfited that you're being this obstinate about the completely off-topic need for us all to respect Google's strong off-topic statement of support[2] over the fact they removed all the code for it
[1] "Since these patches remove RISC-V kernel support, RISC-V kernel build support, and RISC-V emulator support, any companies looking to compile a RISC-V build of Android right now would need to create and maintain their own fork of Linux with the requisite ACK and RISC-V patches."
[2] "Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI)."
It's certainly more than just disabling a build type - it's actually removing a decent bit of configuration options and even TODO comments. Then again, it's not actually removing anything particularly significant, and even has a comment of "BTW, this has nothing to do with kernel build, but only related to CC rules. Do we still want to delete this?". Presumably easy to revert later, and might even just be a revert itself.
Flagged, 3rd reply in a row where you make personal attacks coupled to 0 factual content. I've been here 15 years, on the internet for 25, and I'm shocked at how little curiosity or interest you have in the subject, and how fascinating you find telling other people whats in their heads. Not something I'm familiar with on HN at all at this magnitude.
Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V.
It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful.
I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.
Next week, Qualcomm will likely announce a 64 core RISC-V RVA23.
ARM really shouldn't pursue an aggressive posture with lines outside iOS or Win11 ecosystems. The leverage won't hold a position already fractured off a legacy market. =3
Funnily enough Qualcomm tried to persuade RISC-V to let them drop compressed instructions. Presumably because they're trying to crowbar a RISC-V decoder onto the Nuvia design and compressed instructions are breaking it somehow.
They should buy the intel alumni founded RISC-V startup, and pour resources into a RVA23 based chip with dual on-chip SDR asic sections (they have the IP).
i.e. create a single open-chip solution for mid-tier mobile communication platforms.
They won't do this due to their cellular chip line interests. However, even if it just ran a bare bones Linux OS... it would open up entire markets. =3
Depends what you mean by performance (most vendors ARM accelerated features are never used for compatibility reasons), as upping the core count with simpler architecture is a fair trade on wafer space.
i.e. if ARM is using anti-trust tactics to extort more revenue, that budget is 100% fungible with extra resources. Note, silicon is usually much cheaper than IP licenses.
One can ask polity to explain things without being rude to people. Have a wonderful day =3
That would require pretending Ventana Veyron V2, Tenstorrent Ascalon/Alastor, SiFive P870, Akeana 5000-series and others do not exist or do not yet have any customers.
Pretending, because they actually exist, have customers, and are thus bound to show up in actual products anytime now.
Qualcomm is known for having a particularly aggressive & hardball-style legal department to enforce its patents on core telecom IP. I believe the most likely outcome is they just settle the dispute here. Arm fighting hardball with hardball.
Which would not really affect the ecosystem of phones using Qualcomm arm chips, it would just change the margins / market cap of Qualcomm.
Yes, longterm Q might invest in their own RISC implementations, but I don't see a viable business case for Qualcomm to just stop ARM development for the foreseeable future.
Qualcomm doesn't have nearly as much to lose as ARM does and they know it.
Qualcomm is almost certainly ARM's biggest customer. If ARM loses, Qualcomm doesn't have to pay out. If ARM wins, Qualcomm moves to RISC-V and ARM loses even harder in the long-term.
The most likely outcome is that Qualcomm agrees to pay a slight bit more than they are currently paying, but nowhere near what ARM is demanding and in the meantime, Qualcomm continues having a team work on a RISC-V frontend for Oryon.
Thing is businesses don't work like side-projects do.
Qualcomm is more or less a research company, the main cost of their business is paying engineers to build their modems/SoCs/processors/whatever.
They have been working with ARM for the last, I dont know, 20 years? Even if they manage to switch to RISC-V, and each employee has negative performance impact of like 15% for 2-3 years this ends up in billions of dollars, because you have to hire more people or lose speed.
If corporate would force me to work with idk Golang instead of TypeScript I could certainly manage to do so, but I would be slower for a while, and if you extrapolate that on an entire company this is big $$.
Just the impact of making this move will have a chilling effect, regardless of the long term outome.
ARM Ltd wants to position itself as the ISA. It is highly proprietary of course, but the impression they want to give is that it is "open" and freely available, no lock-in, etc.
This really brings the reality back into focus that ARM controls it with an iron fist, and they're not above playing political games and siding against you if you annoy their favored customers. Really horrible optics for them.
Qualcomm is slightly bigger than ARM so it seems like a fair fight to me. Does Qualcomm police it's IP at all?
> Qualcomm is slightly bigger than ARM so it seems like a fair fight to me.
I'm not really sure what you're responding to. It's got nothing to do with size whether or not something is fair, it's what is in the contract. None of us know exactly what's there so if it becomes disputed then a court is going to have to decide what is fair.
But that was entirely not the point of my comment though. I'm talking about how corporations looking to make chips or get into the ecosystem view ARM and its behavior with its architecture and licensing. ARM Ltd might well be in the right here by the letter of their contracts, but that canceling their customer's license (ostensibly if not actually siding with another customer who is in competition with the first) is just not a good look for positioning they are going for.
>Qualcomm moves to RISC-V and ARM loses even harder in the long-term.
I think long term is doing a lot of heavy lifting here. How long until:
1. Qualcomm develops a chip that competitive in performance to ARM
2. The entire software world is ready to recompile everything for RISC-V
Unless you are Apple I see such a transition taking a decade easily.
> 1. Qualcomm develops a chip that competitive in performance to ARM
Virtually all high performance processors these days operate on their own internal “instructions”. The instruction decoder at the very front of the pipeline that actually sees ARM or RISC-V or whatever is a relatively small piece of logic.
If Qualcomm were motivated, I believe they could swap ISAs relatively easily on their flagship processors, and the rest of the core would be the same level of performance that everyone is used to from Qualcomm.
This isn’t the old days when the processor core was deeply tied to the ISA. Certainly, there are things you can optimize for the ISA to eke out a little better performance, but I don’t think this is some major obstacle like you indicate it is.
> 2. The entire software world is ready to recompile everything for RISC-V
#2 is the only sticking point. That is ARM’s only moat as far as Qualcomm is concerned.
Many Android apps don’t depend directly on “native” code, and those could potentially work on day 1. With an ARM emulation layer, those with a native dependency could likely start working too, although a native RISC-V port would improve performance.
If Qualcomm stopped making ARM processors, what alternatives are you proposing? Everyone is switching to Samsung or MediaTek processors?
If Qualcomm were switching to RISC-V, that would be a sea change that would actually move the needle. Samsung and MediaTek would probably be eager to sign on! I doubt they love paying ARM licensing fees either.
But, all of this is a very big “if”. I think ARM is bluffing here. They need Qualcomm.
> Everyone is switching to Samsung or MediaTek processors?
Why not? MediaTek is very competitive these days.
It would certainly perform better than a RISC-V decoder slapped onto a core designed for ARM having to run emulation for games (which is pretty much the main reason why you need a lot of performance on your phones).
Adopting RISC-V is also a risk for the phone producers like Samsung. How much of their internal tooling (e.g. diagnostics, build pipelines, testing infrastructure) are built for ARM? How much will performance suffer, and how much will customers care? Why take that risk (in the short/medium term) instead of just using their own CPUs (they did it in some generations) or use MediaTek (many producers have experience with them already)?
Phone producers will be happy to jump to RISC-V over the long term given the right incentives, but I seriously doubt they will be eager to transition quickly. All risks, no benefits.
Naively, it would seem like it would be as simple as updating android studio and recompiling your app, and you would be good to go? There must be less than 1 in 1000 (probably less than 1 in 10,000) apps that do their own ARM specific optimizations.
Without any ARM specific optimizations, most apps wouldn’t even have to recompile and resubmit. Android apps are uploaded as bytecode, which is then AOT compiled by Google’s cloud service for the different architectures, from what I understand. Google would just have to decide to support another target, and Google has already signaled their intent to support RISC-V with Android.
https://opensource.googleblog.com/2023/10/android-and-risc-v...
1. That doesn't mean you can just slap a RISC-V decoder on an ARM chip and it will magically work though. The semantics of the instructions and all the CSRs are different. It's going to be way more work than you're implying.
But Qualcomm have already been working on RISC-V for ages so I wouldn't be too surprised if they already have high performance designs in progress.
That is a good comment, and I agree things like CSR differences could be annoying, but compared to the engineering challenges of designing the Oryon cores from scratch… I still think the scope of work would be relatively small. I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.
> I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.
That makes a lot of sense. RISC-V is really not at all close to being at parity with ARM. ARM has existed for a long time, and we are only now seeing it enter into the server space, and into the Microsoft ecosystem. These things take a lot of time.
> I still think the scope of work would be relatively small
I'm not so sure about this. Remember that an ISA is not just a set of instructions: it defines how virtual memory works, what the memory model is like, how security works, etc. Changes in those things percolate through the entire design.
Also, I'm going to go out on a limb and claim that verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design.
The bigger question is how much of their existing cores utilize Arm IP… and how sure are they that they would find all of it?
> That doesn't mean you can just slap a RISC-V decoder on an ARM chip and it will magically work though.
Raspberry Pi RP2350 already ships with ARM and RISC-V cores. https://www.raspberrypi.com/products/rp2350/
It seems that the RISC-V cores don't take much space on the chip: https://news.ycombinator.com/item?id=41192341
Of course, microcontrollers are a different from mobile CPUs, but it's doable.
That's not really comparable. Raspberry Pi added entirely separate RISC-V cores to the chip, they didn't convert an ARM core design to run RISC-V instructions.
What is being discussed is taking an ARM design and modifying it to run RISC-V, which is not the same thing as what Raspberry Pi has done and is not as simple as people are implying here.
Nevertheless, several companies that originally had MIPS implementations did exactly this, to implement ARM processors.
> Virtually all high performance processors these days operate on their own internal “instructions”. The instruction decoder at the very front of the pipeline that actually sees ARM or RISC-V or whatever is a relatively small piece of logic.
If that's true, then what is arm licensing to Qualcomm? Just the instruction set or are they licensing full chips?
Sorry for the dumb question / thanks in advance.
Qualcomm has historically licensed both the instruction set and off the shelf core designs from ARM. Obviously, there is no chance the license for the off the shelf core designs would ever allow Qualcomm to use that IP with a competing instruction set.
In the past, Qualcomm designed their own CPU cores (called Kryo) for smartphone processors, and just made sure they were fully compliant with ARM’s instruction set, which requires an Architecture License, as opposed to the simpler Technology License for a predesigned off the shelf core. Over time, Kryo became “semi-custom”, where they borrowed from the off the shelf designs, and made their own changes, instead of being fully custom.
These days, their smartphone processors have been entirely based on off the shelf designs from ARM, but their new Snapdragon X Elite processors for laptops include fully custom Oryon ARM cores, which is the flagship IP that I was originally referencing. In the past day or two, they announced the Snapdragon 8 Elite, which will bring Oryon to smartphones.
thank you for explaining
ARM already did the hard work. Once you've ported your app to ARM, you've no doubt made sure all the ISA-specific bits are isolated while the rest is generic and portable. This means you already know where to go and what to change and hopefully already have testing in place to make sure your changes work correctly.
Aside from the philosophy, lots of practical work has been done and is ongoing. On the systems level, there has already been massive ongoing work. Alibaba for example ported the entirety of Android to RISC-V then handed it off to Google. Lots of other big companies have tons of coders working on porting all kinds of libraries to RISC-V and progress has been quite rapid.
And of course, it is worth pointing out that an overwhelming majority of day-to-day software is written in managed languages on runtimes that have already been ported to RISC-V.
Interesting, does anyone know what percentage of top Android apps run on RISC-V? I'd expect a lot of apps like games to only have binaries for ARM
The thing about RISC-V is that they indirectly have the R&D coffers of the Chinese government backing them for strategic reasons. They are the hardware equivalent of Uber's scale-first-make-money later strategy. This is not a competition that ARM can win purely relying on their existing market dominance.
Aren’t Android binaries in Dalvik so you only need to port that to get it to run on RISC-V?
Many games, multimedia apps (native FFMPEG libs), and other apps that require native C/C++ libs would require a recompile/translation for RISC-V.
https://developer.android.com/ndk
Aren't most applications NOT using the ndk?
NDK usage is pretty high among applications that actually matter.
Most major apps use the NDK.
That's what's magical about Apple. It was a decade-long transition. All the 32-bit code that was removed from macOS back in 2017 was all in preparation for the move in 2019.
Apple has done it multiple times now and has it down to a science.
68k -> PPC -> x86 -> ARM, with the 64 bit transition you mixed in there for good measure (twice!).
Has any other consumer company pulled a full architecture switch off? Companies pulled off leaving Alpha and Sparc but that was servers which has a different software landscape.
I don't believe any major company has done it. Even Intel failed numerous times to move away from x86 with iAPX432, i960, i860, and Itanium all failing to gain traction.
For Apple it was do or die the first few times. Until x86, if they didn’t move they’d just be left in the dust and their market would disappear.
The ARM transition wasn’t strictly necessary like the last ones. It had huge benefits for them, so it makes sense, but they also knew what they were doing by then.
In your examples (which are great) Intel wasn’t going to die. They had backups, and many of those seem guided more by business goals than a do-or-die situation.
I wonder if that’s part of why they failed.
In a way that's also true for the x86->ARM transition, isn't it? I had an MacbookAir 2018. And.. "it was crap" is putting it very, very mildly. Yes it was still better than any Windows laptop I got since and much less of a hassle than any Linux laptop that I'm aware of in my circle. But the gap was really, really small and it cost twice as much.
But the most important part for the working of the transition is probably that, in any of theses cases, the typical final user didn't even notice. Yes a lot of Hackernews-like people noticed as they had to recompile some of their programs. But most people :tm: didn't. They either use AppStore apps, which were fixed ~immediately or Rosetta made everything runnable, even if performance suffered.
But that's pretty much the requirement you have: You need to be handle to transition ~all users to the new platform with ~no user work and even without most vendors doing anything. Intel never could provide that, not even aim for it. So they basically have to either a) rip their market in pieces or b) support the "deprecated" ISA forever.
> Rosetta made everything runnable, even if performance suffered.
I think a very important part was that even with the Rosetta overhead, most x86 programs were faster on the m1 than on the machines which it would have been replacing. It wasn’t just that you could continue using your existing software with a perf hit; your new laptop actually felt like a meaningful upgrade even before any of your third party software got updated.
IBM also did it, with mainframes. But otherwise, no.
I think windows-on-arm is fairly instructive as to how likely RISC-V would go.
>> 1. Qualcomm develops a chip that competitive in performance to ARM
Done. Qualcomm is currently gunning for Intel.
2. The entire software world is ready to recompile everything for RISC-V
Android phones use a virtual machine which is largely ported already. Linux software is largely already ported.
And with VM tech, and the power of modern devices even some emulator/thunking layer is not too crazy for apps that (somehow) couldn't cross compile.
2. Except games...
But ARM and RISC-V are relatively similar and it's easy to add custom instructions to RISC-V to make them even more similar if you want so you could definitely do something like Rosetta.
Keep in mind, Apple _did_ actually take a good decade from starting with ARM to leaving x86.
With 100% control of the stack and an insanely good emulator in Rosetta.
Qualcomm's migration would be much easier than Apple's.
Most of the Android ecosystem already runs on a VM, Dalvik or whatever it's called now. I'm sure Android RISC-V already runs somewhere and I don't see why it would run any worse than on ARM as long as CPUs have equal horsepower.
Yeah, but Qualcomm doesn’t control Android or any of the phone makers. It’s hard for large corps to achieve the internal coordination necessary for a successful ISA change (something literally only Apple has ever accomplished), but trying to coordinate with multiple other large corps? Seems insane. You’re betting your future on the fact that none of the careerists at Google or Samsung get cold feet and decide to just stick with what works.
NDK exists.
The companies with large relevant apps running on the NDK are well staffed and funded enough to recompile.
it's not about that, it's about running the apps whose makers are out of business or just find it easier to tell their customers to buy different phones
Is the transition fully over if the latest MacOS still runs an x86 emulator for old software?
>2. The entire software world is ready to recompile everything for RISC-V
This would suggest that RISC-V is starting from scratch.
Yet in reality it is well underway; RISC-V is rapidly growing the strongest ecosystem.
> Qualcomm develops a chip that competitive in performance to ARM
That’s what Oryon is, in theory.
> Qualcomm doesn't have nearly as much to lose as ARM does and they know it.
question: isn't arm somewhat apple?
...Advanced RISC Machines Limited and structured as a joint venture between Acorn Computers, Apple, and VLSI Technology.
https://en.wikipedia.org/wiki/Arm_Holdings#Founding
Moving to a whole new architecture is really really hard, no? The operating systems and applications all need to be ported. Just because Qualcomm cannot be friends with arm, every single Qualcomm customer from google to some custom device manufacturer needs to invest years and millions to move to a new architecture? Unless I am fundamentally misunderstanding this, it seems like something they won’t be able to achieve.
On modem side they can move to whatever they want without impacts. But on the apps side they need to run Linux/Android/Windows/etc so are dependent on Arm.
>>Qualcomm moves to RISC-V and ARM
That is a HUGE cost!
You’re suggesting that Snapdragon processors would switch to RISC-V and that would be no big deal? Presumably Qualcomm is committed to numerous multi-year supplier agreements for the arm chipsets.
Qualcomm pitched Znew quite a while ago. It mostly ditched 16-bit instructions and added a bunch of instructions that were basically ripped straight from ARM64.
The idea was obviously an attempt at making it as easy as possible to replace ARM with RISC-V without having to rework much of the core.
https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
An attempt that failed miserably. (it was formally rejected a year ago)
But, by now, it is expected that Qualcomm's RISC-V designs have been re-aligned to match the reality that Qualcomm does not control the standard.
This affects their custom Nuvia derived cores. I'm sure Qualcomm will be able to keep using ARM designed cores to cover themselves while they ween off ARM in favor of RISC-V if they need to.
> Qualcomm is almost certainly ARM's biggest customer.
You think Qualcomm is larger than Apple?
Apple has (to a first approximation) a royalty-free license to ARM IP by virtue of the fact that they co-founded ARM - so yes, Qualcomm is most likely paying ARM more than Apple is.
Just to clarify for those that don't know ARMs history, Acorn were building computers and designing CPUs before they spun out the CPU design portion.
Apple did not help them design the CPU/Architecture, that was a decade of design and manufacturing already, they VC'ed the independence of the CPU. The staffing and knowledge came from Acorn.
> Apple did not help them design the CPU/Architecture
I believe they had a big hand in ARM64. Though best reference I can find right now is this very site: https://news.ycombinator.com/item?id=31368489
Oh, I was just wanting to clarify the "Apple co-founded".
They had the Newton project, found ARM did a better job than the other options, but there were a few missing pieces. They funded the spun out project so they could throw ARM a few new requirements for the CPU design.
As a "cofounder" of ARM, they didn't contribute technical experience and the architecture did already exist.
is risc-v anywhere near the same efficiency ballpark?
RISC-V is very competitive with ARM when comparing similar PPA niches.
High performance and low power laptop and phone SoC’s, no way. There exists no competitive risc-v chip.
We're all assuming that Oryon-V is already being developed.
The phones haven't been custom ARM chips since 32-bit Krait, IIRC.
This is about Nuvia.
https://en.m.wikipedia.org/wiki/Krait_(processor)
Snapdragon 805 had a 32-bit Krait designed by Qualcomm
https://www.qualcomm.com/products/mobile/snapdragon/smartpho...
810 had a 64-bit core designed by ARM
https://www.qualcomm.com/products/mobile/snapdragon/smartpho...
820/821 had a 64-bit Kryo custom core designed by Qualcomm
https://www.qualcomm.com/products/mobile/snapdragon/smartpho...
After that it was all cores from ARM. The custom CPU team worked on their server chip before getting cancelled and most of the team went to Microsoft
When you look at https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-socs.ht... table then you can see that in Snapdragon 8xx series the first "ARM cores out of shelf" was 888 in 2020.
865 (2019) has Cortex-A77 + Kryo 4xx Silver 888 (2002) uses Cortex-X1 + Cortex-A78 + Cortex-A55 cores
I need to have a closer look. Thanks.
Not just telecom, they are just super aggressive in general as a bully with weapons pile. I remember they tried to threaten Opus codec with patents just becasue, when IETF proposed it for Internet standard. Luckily that failed, but it shows their nasty approach very clearly. So now they are getting the taste of their own medicine.
Qualcomm should put a giant bid on SiFive tomorrow, to remind ARM that its not unassailable
When do Qualcomm's patents run out?
This "cancellation" is likely to be paused until the lawsuit is resolved so it's hard to say what this means. Presumably this is a part of the negotiations going on behind the scenes.
Because of all the discussions in the comments about ARM and RISC-V, could someone explain to me the difficulties of designing a chip for a new ISA?
I'm wondering because to me as a layman it sounds like it's 'only' a different language, so why is it not that easy to take already existing designs and modify them to 'speak' that language and that's it?
Or is an ISA more than just a different 'language'?
Or is hardware not really the biggest problem, but rather Software like compilers, kernels, etc.?
Your view even of human languages is simplistic. Forgive me, I don't mean to be rude, I'm just trying to explain.
You might think that languages are just have different words for the same things.
In reality the problems are where the same things don't exist. People don't view the world the same way and don't have an equivalent word. In Turkish it's very important whether your aunt is on your mother's side or your father's side so there are different words for each....but there's no words for "he" or "she" as they don't bother with gender in sentences.
So for example every conversation converted from Turkish to English loses an important bit of meaning about relationships and the sex of a person has to be inferred from context which is not easy to do automatically.
Similarly computer software....and there's a lot of it.
> Or is an ISA more than just a different 'language'?
It tends to be more like going from C89 to Haskell. You're not just switching the keywords around, but also fundamental architectural concepts. There's still some parts you can recycle and some skills that transfer, but less than you'd like.
> Or is hardware not really the biggest problem, but rather Software like compilers, kernels, etc.?
That's the next problem. Kernels, device drivers, support hardware, a lot of low level stuff needs to be adapted, and even a company the size of Qualcomm doesn't necessarily do everything inhouse, there will be lots of external IPs involved and all those partners need to also be willing to migrate over to a different ISA.
I'd perhaps put ARM vs RISC-V closer to like C# vs Java (or maybe JS vs Python) - on a high level rather similar, but a majority of the specifics don't really line up (especially at the uop level requiring dumping a bunch of previous optimized cases, and adding a bunch of new ones).
> If Arm follows through with the license termination, Qualcomm would be prevented from doing its own designs using Arm’s instruction set
i'm not sure this is true. certainly "chip" IP has been a real legal quagmire since, forever.
but it was my understanding that you could neither patent nor copyright simply an "instruction set".
presumably what you get from ARM with an architecture license would be patent licenses and the trademark. if so, what patents might be relevant or would be a problem if you were to make an "ARMv8-ish compatible" ISA/Architecture with a boring name? i haven't seen much about ARM that's architecturally particularly unique or new, even if specific implementation details may be patent-able. you could always implement those differently to the same spec.
to further poke at the issue, if it's patents, then how does a RISC-V CPU or other ISA help you? simply because it's a different ISA, doesn't mean its implementation doesn't trample on some ARM patents either.
if it's something to do with the ISA itself, how does that affect emulators?
what's ARM's IP really consist of when you build your own non-ARM IP CPU from scratch? anyone have examples of show-stopper patents?
You can patent something like "any possible hardware circuit that implements [the functionality of some weird yet mandatory ARM instruction]". The patent doesn't cover emulators because they're not hardware.
Way back in the day there were some MIPS patents that only covered a few instructions so people would build not-quite-MIPS clone CPUs without paying any royalties.
thanks for the hint. i found https://www.probell.com/lexra/
sheesh, patent https://patents.google.com/patent/US4814976A/en is a real "gem"
but its probably a good example: faulty patent (later invalidated) to do something obvious
MIPS sues a company that doesn't even implement the odd instructions because it traps them, allowing a possibility of emulation.
there's literally no case here
just to sue them into oblivion and squish them with superior cash resources. and then to get squished by ARM because they weren't paying attention.
it's like a dark fairy tale. i hate corporate lawyers.
https://archive.ph/FcXRW
Most comments here seem to think that Qualcomm has to settle or switch to RISC-V. But from my understanding the article is only about their license to design custom chips with ARM IP, not about using ARM's designs.
For example the Snapdragon 8 Gen 1 uses 1 ARM Cortex-X2, 3 ARM Cortex-A710 and 4 ARM Cortex-A510, which are ARM designs. Their latest announced chip though, Snapdragon 8 Elite, uses 8 Oryon cores, which Qualcomm designed themselves (after acquiring Nuvia).
So is Qualcomm not still able to create chips like the former, and just prevented from creating chips like the latter? Or does "putting a chip together" (surely there is a bit more going into it) like the Snapdragon 8 Gen 1 still count as custom design?
They’re only losing their license to make custom cores. They’re still free to use ARMs own cores.
The reason being that ARM gave Nuvia a license to design cores at a specific rate, then Qualcomm bought them to use those cores. ARM claims that the license to design cores does not have a transferable rate to it.
On mobile devices efficiency is so important, I don't see how Qualcomm would be able to live without ARM licences. RISC-V and other architectures like x86-64 are nice, actually I think the peripheral libraries, boot and stuff like that are bigger headache to replace for Qualcomm's clients given that they can just switch the gcc to a different arch - still if your code is 25% less efficient, that'll be quite noticable for the consumer - or in your battery and weight costs.
What am I not seeing here? I think they'll just settle.
Let’s just assume this happens for a moment.
What do Android OEMs do? They can’t use Apple chips, or now Qualcomm chips. Switching to another architecture is a big deal.
Would this basically hand the Android market to Samsung and their Exynos chips? Or does another short term viable competitor exist?
This move doesn't stop Qualcomm from licensing ARMs reference cores, it only blocks them from designing their own in-house ARM cores like Apple does. The vast majority of Qualcomm chips currently on the market are built around reference cores, they only recently got back into the custom core game with their acquisition of Nuvia which also kicked off this dispute with ARM.
There are probably Risc-V companies eagerly anticipating an opportunity in that space, but I don't know if any are in the performance ballpark right now.
Qualcomm itself is one such company.
MediaTek is still available.
I notice how 'viable' isn't an operative in your statement.
They've come a long way, Samsung is apparently considering Mediatek chips for their next flagship phone (S25).
They're pretty good. Just can't beat qualcomm / Apple flagship. So around Intel level ;)
300W in a phone chip is a bit toasty.
Intel's latest Arrow Lake stuff, about to go on sale, is said to have much better power efficiency, FWIW. Something like half the wattage for roughly equivalent benchmark results, according to them.
Dimensity 9400 looks good
Without (complete) kernel sources, they're already e-waste.
Don't know about cell phones but their Chromebooks are pretty good.
Everyone's going to have to buy a Pixel phone, ahahahahaahahha.
Samsung phones are presumably firm as well. They recently switched to snapdragon (qualcomm) chips but before they were using exynos (samsung) chips.
Samsung phones use both, in a very literal sense. Their flagship devices usually have both Snapdragon and Exynos variants for different regions, and their lower end devices are mostly Exynos across the board.
The S23 line was an exception in using Snapdragon worldwide, but then the S24 line switched back to using Snapdragon in NA and Exynos everywhere else, except for the S24 Ultra which is still Snapdragon everywhere.
Yes it's a confusing mess, and it's arguably misleading when the predominantly NA-based tech reviewers and influencers get the usually superior QCOM variant, and promote it to a global audience who may get a completely different SOC when they buy the "same" device.
Is the Qualcomm chip still considered significantly better than the Exynos? I remember that was the case a few years ago.
Last time I checked, the latest Qualcomm Snapdragon was faster and more energy efficient than the latest Exynos. Especially the top-binned chips that Samsung gets.
Still, the fact that Samsung can swap out the chip in their flagship product with virtually no change other than slightly different benchmark scores means that these chips are pretty much fungible. If either manufacturer runs into serious problems, the other one is ready to eat their market share for lunch.
Samsung still uses qualcomm in US markets and exynos outside US even for their flagships.
There is MTK that offers the Dimensity series SoCs with Arm cores. Qcom can also go back to using Arm Cortex cores in the next Snapdragon SoC.
And Qualcomm is the only competitive ARM chip on the market besides Apple's. And now they are being taken out by ARM. Is it really that expensive to re-license things? This seems self-defeating.
Samsung and MediaTek make pretty competitive ARM processors.
MediaTek 9400 is literally the top-performing SoC on the market.
Samsung Exynos 2400, 2400e
MediaTek Dimensity 9400, 9300 Plus, 9300
https://nanoreview.net/en/soc-list/rating
AWS has the Graviton ARM CPU that is pretty competitive but you can only rent them.
Graviton is just an ARM neoverse core no? It's not a bespoke design.
Ampere has Graviton-like chips that you can actually buy, but neither Graviton or Ampere are really in the same market segment as Qualcomm and Apple.
System76 recently released an ampere desktop. It starts at about half the price of a Mac Pro and seems to top out at many more cores.
I’m not sure if the low end ampere is as slow as a high end mac though.
I believe Graviton is competitive in the server market yes, but not in mobile or laptops.
Graviton4 is based on Neoverse V2 which is based on X3.
Neoverse V3 was announced Feb of this year. It should have an 80-85% performance increase and should basically be based on something very close to x925.
Ah? ARM doesn't build chips but provides the architecture and license it to other companies.
There are plenty of ARM chips designed by multiple companies and built by multiple foundries
ARM licenses cores for both CPU and GPU, not just the architecture.
There are not “plenty of ARM chips designed by multiple companies”, almost all of them except for Apple (and now Qualcomm) use ARMs off the shelf design.
Also NPU
Now that the Nvidia deal has fallen through, SoftBank is trying to ramp up profitability while continuing to search for another buyer.
I guess they'll have to give ARM all that money they got from Apple over their modem dispute.
What does all this have to do with Intel and AMD calling a truce?
https://archive.is/FcXRW
I hope Qualcomm wins and wins its countersuits too.
Damn!
So what happens to the Raspberry Pi?
Edit: OK, following the discussion now. Nothing in the short term, potentially longer term.
The Raspberry Pi uses Broadcom, not Qualcomm chips. It also uses cores designed by Arm, which are not affected by today's news.
Could be the best thing that's ever happened for RISC-V!
Most people do not realize how slow RISC-V is right now. Yes, it will definitely get better, but it will take some time given how far behind it is.
Like 30x slower than a top of the line Apple Mx series CPU. Maybe there is a high performing RISC-V chip out there but I haven't yet run into one.
RISC-V benchmarks: https://browser.geekbench.com/search?q=RISC-V. Compare to an Apple M4 benchmark: https://browser.geekbench.com/v6/cpu/8224953
That said, RISC-V is good for embedded applications where raw performance isn't a factor. I think no other markets are yet accessible to RISC-V chips until their performance massively improves.
There is a chip out there that contains both an ARM and a RISC-V core, the RP2350. It's reasonable to assume that the ARM part and RISC-V part are manufactured in the same process. There are some benchmarks pitting the two against each other on e.g. this page: https://forums.raspberrypi.com/viewtopic.php?t=375268
For a generic logic workload like Fibo(24), the performance is essentially the same (quote from above page):
Note that neither core on the RP2350 comes with advanced features like SIMD.We're not quite there yet. A bunch of mission critical stuff like SIMD were only added in the last 2-3 years. As it takes 4-5 years to design/ship high-performance chips, we still have a ways to go.
Ventana Veyron looks interesting. Tenstorrent's upcoming 8-wide design should perform well.
Qualcomm pitched making a bunch of changes to RISC-V that would move it closer to ARM64 and make porting easier, so I think it's an understatement to say that they are considering the idea. If ISA doesn't matter, why pay tons of money for the ISA?
You're confusing the ISA with the chip. Current RISC-V chips are slower than high performance ARM ones, but that's because you don't start by designing high performance chips! You start with small embedded cores and work your way up.
Exactly the same thing happened with ARM. It started in embedded, then phones, and finally laptops and servers. ARM was never slow, they just hadn't worked up to highly complex high performance designs yet.
you don't start by designing high performance chips! You start with small embedded cores and work your way up.
I disagree. For example, the first PowerPC was pretty fast and went into flagship products immediately. Itanium also went directly for the high end market (it failed for unrelated reasons). RISC-V would be much better off if some beastly chips like Rivos were released early on.
Is it slower by design or just because it’s implementations have not been aggressively optimized?
I believe it is just lacking aggressive optimization. ARM is basically RISC as well, so it isn't an architectural limitation.
(Naive question) then is it really a big hurdle for a company who knows how to make arm chips to try making riscv chips?
The question is more of will your customers agree to go along with this major architectural shift that sets you back on price-performance-power curves by at least five years and moves you out of the mainstream of board support packages, drivers, and everything else software-wise for phones.
Also we should not pretend that ARM is just going to sit there waiting for RISC-V to catch up.
Yes. This caveat is most clear. I am wondering about the question of performance raised in this thread,
I suspect not? I think the principles and methods of optimization are the same.
But I say this as a software guy who doesn't actually know CPU design.
Making the chip isn’t an issue for them. It’s the software compatibility post facto.
It’s not a big hurdle so long as they hire Jim Keller to rapidly improve yet another architecture. (Only half-joking.)
Jim Keller is actually working on this right now at Tenstorrent.
Ascalon (claiming Zen5-tier performance) is done, and has been available for licensing for about a year now.
It was then made public that LG bought a license right away.
It’s easy to claim a lot of things.
>It’s easy to claim a lot of things.
It certainly is easy to casually spread fear and doubt.
But it is really far-fetched to think that the people at Tenstorrent, who have successfully delivered very high performance microarchitectures in other companies before, are lying about Ascalon, and that LG is helping them do that.
It would even be more far fetched to claim that Ventana Veyron V2, SiFive P870, Akeana 5000-series, all of them available high performance IP, are lying about performance.
Two years ago you were saying last year. Last year you were saying this year. Now you’re saying next year. Maybe it’s coming someday but I’m surely not going to believe you for it. Especially since you never seem to have anything to back it up other than, like, random people moving around between these companies soaking up VC funding. Where is the chip that is 70% as good as the competition? Where’s the chip that is competitive with Zen 3? Still seems a ways off, no?
>Two years ago you were saying last year. Last year you were saying this year. Now you’re saying next year. Maybe it’s coming someday but I’m surely not going to believe you for it.
Your apparent beef with me is misguided.
>Especially since you never seem to have anything to back it up
Refer to public announcements by these companies. I am but an observer.
Well you need several years to catch up - and those doing arm are not standing still. Same problem big software rewrites have, some are successful but it takes a large investment while everyone is still using the old stuff that is better for now.
Maybe fine for Android but this will set their windows plans back another decade if it happens
It has taken them that long to make arm be a thing on windows and that’s building on people porting stuff to arm for Mac to finally get momentum.
RISC-V with windows will be an eternity to be feasible.
>RISC-V with windows will be an eternity to be feasible.
Will it now?
Microsoft was already deeply involved in 2021 as per that years' summit RISC-V Foundation's technical talks. Ztso was pushed by them.
Whether Microsoft has windows running on an architecture is a very different level from whether it’s feasible to use it as a daily driver on windows. The ecosystem is what matters for most people.
Windows for arm hails back to 2011. They’re only just now getting native arm ports for several major packages. That’s ~13 years for a well established architecture that’s used much more universally than RISC-V. They don’t even have arm ports for lots of software that has arm ports on macOS.
RISC-V will take an aeon longer to get a respectable amount of the windows ecosystem ported over.
Arm on windows may date to 2011, but it was mostly a side project with 1-2 maintainers. With sufficient investment, it shouldn’t take 13 years to build up RISC-V support.
This.
It is evident to anybody paying attention that Microsoft has RISC-V support well underway.
But even if they had to start from scratch, it would be much easier, thanks to ARM having paved the way.
Like everything else, it doesn’t matter much. Windows ran on Itanium, Alpha, and as pointed out ARM for over a decade.
Without the ISVs, it’s a flop for consumers.
MS has had an abysmal time getting them to join in on ARM, only starting to have a little success now. Saying “Ha ha, just kidding, it’s RISC-V now” would be a disaster. That’s the kind of rug pull that helped kill Windows Mobile.
Emulators aren’t good enough. They’re a stop gap. Unless the new chip is so much better than the old it’s faster with emulation then the old one was native no one will accept it long. Apple’s been there, but that’s not where MS sits today.
And if your emulator is too good, what stops ISVs from saying “you did it for us, we don’t have to care”? So once again they don’t have to do it at all and you have no native software.
MS can’t drop their ARM push unless they want to drop all non-x86 initiatives for a long time.
>And if your emulator is too good, what stops ISVs from saying “you did it for us, we don’t have to care”? So once again they don’t have to do it at all and you have no native software.
x86 emulation enables adoption.
Adoption means having an user base.
Having an user base means developers will consider making the platform a target.
>Saying “Ha ha, just kidding, it’s RISC-V now” would be a disaster.
Would it now? If anything, offering RISC-V support as well would further reinforce the idea that Windows is ISA-independent, and not tied to x86 anymore.
> If anything, offering RISC-V support as well would further reinforce the idea that Windows is ISA-independent, and not tied to x86 anymore.
Anymore? It’s been independent since the 90s. It’s only ISVs that have been an issue.
And a rug pull is a fantastic way to scare all the ISVs far far away.
Whose's rug would even be pulled?
How do you imagine ARM having helped?
The x86 emulator for one.
Fair, though I don’t think translation is a good long term strategy. You need native apps otherwise you’re always dealing with a ~20-30% disadvantage.
The competition isn’t sitting still either and QC already hit this with Intel stealing their thunder with Lunar Lake. They’re efficient enough that the difference in efficiency is far overshadowed by their compatibility story.
Ecosystem support will always go to the incumbent and this would place RISC-V third behind x86 and ARM. macOS did this right by saying there’s only one true way forward. It forces adoption.
>You need native apps
For native apps, you need users. For users, you need emulation.
It cannot be overstated how important successful x86 emulation is for the migration to anything else to be feasible.
I think you just ignored the rest of my comment though which specifically addresses why I don’t think just relying on translation is an effective strategy. Users aren’t going to switch to a platform that has lower compatibility when the incumbent has almost as good efficiency and performance.
So which of Microsoft’s false starts would you take as them taking ARM seriously?
Why do you think they’d take RISC-V any more seriously than their previous attempts at ARM?
There are two fallacies to overcome here.
>The ecosystem is what matters for most people.
Absolutely agree.
The key development Microsoft has demonstrated recently is the ability to run x86 Windows software in non-x86 Windows systems.
Now that this is in place -and will only get better-, there is no longer a chicken and egg situation.
Instead, what we have is a clearly defined path to migrate away from x86.
I think it's already a great thing for RISC-V, imagine things somehow go well for Qualcomm, do you really think they wouldn't prepare a plan B given ARM tried to get them out of the market?
I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.
Qualcomm have a Plan B.
This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia.
At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite.
The proposed extension was actually not bad, and could very reasonably be adopted.
Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years.
So they'd have to support both "C" and its replacement anyway.
Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.
What do you mean by Plan B? From what you've just said it sounds like their proposal was rejected, so there is no plan b now?
They can roll their sleeves up and do the small amount of work that they tried to persuade everyone else was not necessary. And I'm sure they will have done so.
It's not that hard to design a wide decoder that can decode mixed 2-byte and 4-byte instructions from a buffer of 32 or 64 bytes in a clock cycle. I've come up with the basic schema for it and written about it here and on Reddit a number of times. Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.
Not that anyone is going that wide at the moment. SiFive's P870 fetched 36 bytes/cycle from L1 icache, but decodes a maximum of 6 instructions from it. Ventana's Veyron v2 decodes 16 bytes per clock cycle into 4-8 instructions (average about 6 on random code).
Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question.
Android was never really Linux though.
This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
>Support _reversed_ for it, got pulled 5 months ago
Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.
If you trust PR (I don't, and I worked on Android for 7 years until a year ago) - this is a nitpick 5 levels down -- regardless of how you weigh it, there is no Android RISC-V
It is no nitpick.
The Android RISC-V effort did not suffer any delay from this pure technicality that some news sites farmed at the time for drama and clicks.
There is no Android RISC-V. There isn't an Android available to run on RISC-V chips. There is no code to run on RISC-V in the Android source tree, it was all recently actively removed.[1]
Despite your personal feelings about their motivation, these sites were factually correctly relaying what happened to the code, and they went out of their way to say exactly what Google said and respected Google's claim that they remain committed, with 0 qualms.
I find it extremely discomfiting that you are so focused on how the news makes you feel that you're casting aspersions on the people you heard the news from, and ignoring what I'm saying on a completely different matter, because you're keyword matching
I'm even more discomfited that you're being this obstinate about the completely off-topic need for us all to respect Google's strong off-topic statement of support[2] over the fact they removed all the code for it
[1] "Since these patches remove RISC-V kernel support, RISC-V kernel build support, and RISC-V emulator support, any companies looking to compile a RISC-V build of Android right now would need to create and maintain their own fork of Linux with the requisite ACK and RISC-V patches."
[2] "Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI)."
Please stop this blatant FUD effort.
Thank you.
Here are the actual commits that all the fuss was about: https://android-review.googlesource.com/c/kernel/build/+/306... and those at https://android-review.googlesource.com/q/topic:%22ack_riscv...
It's certainly more than just disabling a build type - it's actually removing a decent bit of configuration options and even TODO comments. Then again, it's not actually removing anything particularly significant, and even has a comment of "BTW, this has nothing to do with kernel build, but only related to CC rules. Do we still want to delete this?". Presumably easy to revert later, and might even just be a revert itself.
Flagged, 3rd reply in a row where you make personal attacks coupled to 0 factual content. I've been here 15 years, on the internet for 25, and I'm shocked at how little curiosity or interest you have in the subject, and how fascinating you find telling other people whats in their heads. Not something I'm familiar with on HN at all at this magnitude.
This is a little rich coming from you of all people.
Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V.
https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
I suppose Google ( + Samsung ) can bear that cost in the context of Android Arm -> Android RISC-V.
It would be naive to think that Qualcomm is only starting its RISC-V effort today and from scratch.
Qualcomm's been involved with RISC-V for several years now.
If anything, ARM is the plan B that they'll likely end up abandoning.
It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful.
I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
Typo. Meant to write "ARM is the plan A that they'll likely end up abandoning".
No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.
Until arm or risc-v fix standardize the bootloader, it’s always going to be a big deal for each arm/risc device added anywhere…
Relevant RISC-V specs were released years ago and implementations follow them.
I know of no boards that have application processors and yet not implement SBI. Furthermore, everybody seems to be using the opensbi implementation.
ARM and RISC-V are not the same.
Next week, Qualcomm will likely announce a 64 core RISC-V RVA23.
ARM really shouldn't pursue an aggressive posture with lines outside iOS or Win11 ecosystems. The leverage won't hold a position already fractured off a legacy market. =3
Funnily enough Qualcomm tried to persuade RISC-V to let them drop compressed instructions. Presumably because they're trying to crowbar a RISC-V decoder onto the Nuvia design and compressed instructions are breaking it somehow.
They should buy the intel alumni founded RISC-V startup, and pour resources into a RVA23 based chip with dual on-chip SDR asic sections (they have the IP).
i.e. create a single open-chip solution for mid-tier mobile communication platforms.
They won't do this due to their cellular chip line interests. However, even if it just ran a bare bones Linux OS... it would open up entire markets. =3
you think they can just flip a RISC-V switch and keep all the performance instantly? I can't really understand the logic from some people here.
"keep all the performance instantly"
Depends what you mean by performance (most vendors ARM accelerated features are never used for compatibility reasons), as upping the core count with simpler architecture is a fair trade on wafer space.
i.e. if ARM is using anti-trust tactics to extort more revenue, that budget is 100% fungible with extra resources. Note, silicon is usually much cheaper than IP licenses.
One can ask polity to explain things without being rude to people. Have a wonderful day =3
1. I am fairly sure games and other performance sensitive apps are using the Android NDK which is not available for RISC-V.
2. I am fairly sure a competitive RISC-V CPU is not days or weeks but years away.
> 2. I am fairly sure a competitive RISC-V CPU is not days or weeks but years away.
And chasing a moving target fueled by the largest technology companies on the planet.
Tying products to Googles ecosystem is usually financially risky. Not a good long-term strategy for startups. =3
I think it is more of a "chicken and egg" ordering problem.
1. The RISC-V design standard fragmentation issue has been addressed.
2. A reasonable mobile class level SoC will be available for integration after any large production run of the chips.
If ARM forces #2 out of silliness, than it also accelerates #1 in the market.
In general, there is plenty of use-cases even if a chip is not cutting edge. =3
Bloomberg disappoints by failing to mention RISC-V at all in the entire article.
They have to be doing this deliberately, as it's hard to explain otherwise.
If the comments in here are correct, RISC-V is really not an option at this time due to performance.
>due to performance
That would require pretending Ventana Veyron V2, Tenstorrent Ascalon/Alastor, SiFive P870, Akeana 5000-series and others do not exist or do not yet have any customers.
Pretending, because they actually exist, have customers, and are thus bound to show up in actual products anytime now.
I don’t feel like you addressed the performance issue.
I don’t think anyone said they don’t exist.