Qualcomm acquires RISC-V focused Ventana Micro Systems(qualcomm.com)
qualcomm.com
Qualcomm acquires RISC-V focused Ventana Micro Systems
https://www.qualcomm.com/news/releases/2025/12/qualcomm-acquires-ventana-micro-systems--deepening-risc-v-cpu-ex
80 comments
Ventana's cores were 15 instruction wide, massively out of order cores that on paper compete with the application cores in Apple's M series SoCs.
They're a totally different gate count niche than a Cortex-M equivalent.
They're a totally different gate count niche than a Cortex-M equivalent.
Yea, this to me signals that Qualcomm is starting to hedge its ARM bets. Given all the kerfuffle around licensing they have had with ARM already, I suspect that they are signaling to ARM that they have options and so ARM's leverage is a lot lower than it might be. That said, there are also huge switching costs to Qualcomm's customers, so this is not a move it takes lightly. In the mean time, I'm sure those Ventana engineers can also help them improve their ARM designs, too.
My guess is that this was mostly an acquihire. I had heard that Ventana had a lot of people that were laid off from Intel for instance.
I would guess the same. Although Android is adding support for RISC-V so I could potentially see them looking into RISC-V Android phones.
Feels kind of unlikely though. Ventana probably ran out of money.
Feels kind of unlikely though. Ventana probably ran out of money.
Maybe Ventana's software engineers can also help Qualcomm fix its BSPs.
.
.
.
Fully agree - Ventana's cores are more like Cortex A76 kinds of things, and are on a completely different scale from typical Cortex-M cores.
But switching to RISC-V would shut Qualcomm out from QNX and would limit its Android compatibility. And on the Qualcomm chips that I've seen so far, they're really bought in on both QNX and Android. That's why I think this is probably an aquihire more than a desire to ship Ventana's CPU cores.
But switching to RISC-V would shut Qualcomm out from QNX and would limit its Android compatibility. And on the Qualcomm chips that I've seen so far, they're really bought in on both QNX and Android. That's why I think this is probably an aquihire more than a desire to ship Ventana's CPU cores.
> Ventana's cores are more like Cortex A76 kinds of things
More like Neoverse-V3: https://www.ventanamicro.com/technology/risc-v-cpu-ip/
BTW: "Silicon platforms launching in early 2026."
I wonder if this will be delayed due to the acquisition.
More like Neoverse-V3: https://www.ventanamicro.com/technology/risc-v-cpu-ip/
BTW: "Silicon platforms launching in early 2026."
I wonder if this will be delayed due to the acquisition.
Doubtful. To have silicon in early 2026 would mean tapeout happened months ago.
Porting QNX would be very possible.
bad, bad, bad sign, when a company starts to penny pinch like that.
but unfortunately very in-line with the thesis that qualcomm is getting squeezed by a commodifying market where value-add opportunity is shifting outside of the SoC platform.
but unfortunately very in-line with the thesis that qualcomm is getting squeezed by a commodifying market where value-add opportunity is shifting outside of the SoC platform.
Could be good if a large firm stabilized the RISC-V version fragmentation with a massive standard SoC product boost in the Android space.
But more likely, the early product line will meet the same fate as the dog in "Old Yeller" (1957) in a market consolidation push. =3
But more likely, the early product line will meet the same fate as the dog in "Old Yeller" (1957) in a market consolidation push. =3
I'd be surprised if Qualcomm replaces their application processors (the cores that typically run Android/Linux or QNX) with RISC-V any time soon. Aarch64's ecosystem is huge, and Qualcomm would cut their customers off from it by moving fully to RISC-V.
They're more likely to replace the smaller CPU cores imo.
They're more likely to replace the smaller CPU cores imo.
> Aarch64's ecosystem is huge
ARMv8 hardware (other than Apple) only shipped 3-6 years before RV64GC/RVA20, and ARMv9 is only about two years before the equivalent RVA23 -- at least in SBCs/Laptops. Obviously ARMv8 hardware went into mobile devices a lot earlier, though it was often running 32 bit code for the first few years.
It's nothing at all like the maturity lead x86 has over both.
ARMv8 hardware (other than Apple) only shipped 3-6 years before RV64GC/RVA20, and ARMv9 is only about two years before the equivalent RVA23 -- at least in SBCs/Laptops. Obviously ARMv8 hardware went into mobile devices a lot earlier, though it was often running 32 bit code for the first few years.
It's nothing at all like the maturity lead x86 has over both.
Agreed, at $5/pc for a ARM64 7/8/9 SoC that can run a real OS, the Aarch64 is likely the minimum now for most designs. =3
What version fragmentation?
Pretty much everything coming out in 2026 -- including Ventana's Veyron V2 -- is RVA23.
One profile to rule them all.
Currently-shipping applications processors are either RVA20 (plus the B extension in practice) or RVA22 with V as a standard option.
That's not fragmentation, it's just a standard linear progression. Each thing can run all the software from the previous thing:
Pretty much everything coming out in 2026 -- including Ventana's Veyron V2 -- is RVA23.
One profile to rule them all.
Currently-shipping applications processors are either RVA20 (plus the B extension in practice) or RVA22 with V as a standard option.
That's not fragmentation, it's just a standard linear progression. Each thing can run all the software from the previous thing:
RVA20 (what e.g. Ubuntu 25.04 and earlier require)
-> RVA20 + B
-> RVA22
-> RVA22 + V
-> RVA23 (what Ubuntu 25.10 and later require)The exact same mistakes were made in ARM6. RISC-Y biggest competitor is mature architecture ecosystems and variants of itself.
https://en.wikipedia.org/wiki/Second-system_effect
Even most ARM software compilers still cripple the advanced vendor specific asic features simply for stability mitigation. ARM 8/9 was actually a much leaner design. Cheers =3
https://xkcd.com/927/
https://en.wikipedia.org/wiki/Second-system_effect
Even most ARM software compilers still cripple the advanced vendor specific asic features simply for stability mitigation. ARM 8/9 was actually a much leaner design. Cheers =3
https://xkcd.com/927/
What mistakes?
No one is ever going to design an ISA that is complete and finished forever on Day #1. There are always going to be new data types and new algorithms to support e.g. the current rush to add "AI" support to all ISAs (NPUs, TPUs, whatever you want to call them).
Arm has ARMv9-A following on from ARMv8-A, and they are already up to Armv9.7-A in addition to as many ARMv8-A enhancements.
Intel/AMD have all kinds of add-ons to x86_64, and not even linear e.g. the here now gone now AVX512. Finally here to stay (presumably) in x86-64-v4. And there is already APX and AVX10 to add to that.
No one is ever going to design an ISA that is complete and finished forever on Day #1. There are always going to be new data types and new algorithms to support e.g. the current rush to add "AI" support to all ISAs (NPUs, TPUs, whatever you want to call them).
Arm has ARMv9-A following on from ARMv8-A, and they are already up to Armv9.7-A in addition to as many ARMv8-A enhancements.
Intel/AMD have all kinds of add-ons to x86_64, and not even linear e.g. the here now gone now AVX512. Finally here to stay (presumably) in x86-64-v4. And there is already APX and AVX10 to add to that.
If people standardized around something like the RISC-V X280, added some standard license-free hardware codecs, and quietly ejected every other distraction. Than RISC-V may have dropped into mobile SoC markets like amd64 did with x86 hard-to-use failed successor IA-64. Note, the silicon business is about selling sustained volumes of identical product, and not about a CEOs ego selling bespoke chips in sub 100k batches.
There were many great chips that never survived in consumer product spaces. When manufacturers tell chip houses there is a permutation compatibility risk issue, and people take a petulant stance on the feedback... “Not my circus, not my monkeys” as they say.
1. Intel is kept alive by the promise of an integrated NVIDIA RTX SoC.
2. AMD understood something important about the software market, and that was easy backward-compatibility wins over _every_ other feature. Even Intel had to learn this the hard way.
3. 93% of the market is change sensitive... anyone that assumes cross-compiling is on the queue for that sector is greatly mistaken. Note, it took ARM over a decade driven by Googles dominance with mobile to gain traction.
4. Most software libraries will only enable advanced chip features if hardware is detected, and most compiled code simply uses the compatibility subset of compiled features (sure its 3 times slower, but it works everywhere.) No one is going to go through every permutation of an ISA with vendor specific features. The NERF'd subset of features in most Aarch64 and amd64 packages should be enough indication software people won't give a bean about unstable vanity silicon features.
We shall see how RISC-Y plays out in the market. Old Yeller sure looks nervous. =3
There were many great chips that never survived in consumer product spaces. When manufacturers tell chip houses there is a permutation compatibility risk issue, and people take a petulant stance on the feedback... “Not my circus, not my monkeys” as they say.
1. Intel is kept alive by the promise of an integrated NVIDIA RTX SoC.
2. AMD understood something important about the software market, and that was easy backward-compatibility wins over _every_ other feature. Even Intel had to learn this the hard way.
3. 93% of the market is change sensitive... anyone that assumes cross-compiling is on the queue for that sector is greatly mistaken. Note, it took ARM over a decade driven by Googles dominance with mobile to gain traction.
4. Most software libraries will only enable advanced chip features if hardware is detected, and most compiled code simply uses the compatibility subset of compiled features (sure its 3 times slower, but it works everywhere.) No one is going to go through every permutation of an ISA with vendor specific features. The NERF'd subset of features in most Aarch64 and amd64 packages should be enough indication software people won't give a bean about unstable vanity silicon features.
We shall see how RISC-Y plays out in the market. Old Yeller sure looks nervous. =3
The X280 is nothing special as a CPU core. It's basically the U74 with added 512 bit vector unit (but only 256 bit ALU), which makes it pretty much equivalent to SpacemiT's X60 core in their K1/M1 SoCs.
There is no X280 hardware available yet for general purchase. There is the HiFive Xara X280 announced in May, but that is believed to be available to SiFive licensees only. The SG2380 was going to have X280s as an NPU alongside P670 main cores, but that's been cancelled as a result of US sanctions on Sophgo. The PIC64-HSPC is a rad-hard chip using the X280 for NASA and other space customers, but will not be cheap -- the RAD750 PowerPC chip it is replacing reportedly costs $200,000 each.
There is no X280 hardware available yet for general purchase. There is the HiFive Xara X280 announced in May, but that is believed to be available to SiFive licensees only. The SG2380 was going to have X280s as an NPU alongside P670 main cores, but that's been cancelled as a result of US sanctions on Sophgo. The PIC64-HSPC is a rad-hard chip using the X280 for NASA and other space customers, but will not be cheap -- the RAD750 PowerPC chip it is replacing reportedly costs $200,000 each.
Indeed, the U.S. Government $8.9 billion investment in Intel common stock could be an indication the entire force of the political structure may drop a boot on competitors.
Regulatory capture is something people need to take seriously. Some may shelve product IP for a few years, or set-up parallel factories in other countries without the artificial trade/global-talent barriers.
A standard doesn't have to be perfect, but must be consistent over significant periods of time to matter. Consider what happened to OpenSparc, Cell, IA-64, dojo tiles, and early RISC (Windows NT prototype was ported off by Microsoft.)
The NVIDIA CUDA card kludge wasn't necessarily "better" than something like the M3/M4/M5 at every task. But was economical hardware due to volume pricing, has 92% of the ecosystem, and most software already worked given it isn't walled-off.
Note people tend to avoid buying work, or porting to short-lived hardware. Best of luck, =3
Regulatory capture is something people need to take seriously. Some may shelve product IP for a few years, or set-up parallel factories in other countries without the artificial trade/global-talent barriers.
A standard doesn't have to be perfect, but must be consistent over significant periods of time to matter. Consider what happened to OpenSparc, Cell, IA-64, dojo tiles, and early RISC (Windows NT prototype was ported off by Microsoft.)
The NVIDIA CUDA card kludge wasn't necessarily "better" than something like the M3/M4/M5 at every task. But was economical hardware due to volume pricing, has 92% of the ecosystem, and most software already worked given it isn't walled-off.
Note people tend to avoid buying work, or porting to short-lived hardware. Best of luck, =3
It may be a while off yet, but it's pretty clear that companies, Qualcomm chief among them, are ready to replace arm as soon as possible.
If it happens, Arm will have only themselves to blame. Suing your own customers is not the smartest move.
Qualcomm acquired Nuvia in order to bypass the licence fees charged by ARM, with I can guess ARM tried to block in good terms first, and latter in bad terms without success as we saw. It may make sense now that ARM is refusing to license them the newer ones.
Qualcomm may be solely to blame themselves, as they now has to invest in researching and developing an underdeveloped architecture, quickly, while their competitors -including Chinese ones- take advantage with newer ARM designs (and perhaps they could even develop their own alternatives peacefully in the meantime).
Qualcomm may be solely to blame themselves, as they now has to invest in researching and developing an underdeveloped architecture, quickly, while their competitors -including Chinese ones- take advantage with newer ARM designs (and perhaps they could even develop their own alternatives peacefully in the meantime).
> Qualcomm acquired Nuvia in order to bypass the licence fees charged by ARM
Both Nuvia and Qualcomm had Arm Architecture licenses that allowed them to develop and sell their own Arm-compatible CPUs.
There was no bypassing of license fees.
If Qualcomm had hired the Nuvia engineers before they developed their core at Nuvia, and they developed exactly the same core while employed at Qualcomm, then there would be no question that everyone was obeying the terms of their licenses.
Arm's claim rests on it being ok for Nuvia to sell chips of their own design, but not to sell the design itself, and not to transfer the design as part of selling the company.
Both Nuvia and Qualcomm had Arm Architecture licenses that allowed them to develop and sell their own Arm-compatible CPUs.
There was no bypassing of license fees.
If Qualcomm had hired the Nuvia engineers before they developed their core at Nuvia, and they developed exactly the same core while employed at Qualcomm, then there would be no question that everyone was obeying the terms of their licenses.
Arm's claim rests on it being ok for Nuvia to sell chips of their own design, but not to sell the design itself, and not to transfer the design as part of selling the company.
Now they're getting counter sued by Qualcomm because it turns out they allegedly violated their own TLA (license to get off the shelf cores) and their ALA (architecture license).
Qualcomm is claiming that Arm is refusing to license the v10 architecture to them and refused to license some other TLA cores requiring them to get the Nuvia Custom CPU team to build cores for those products instead.
This explains their expansion into Risc-V it's a hedge against Arm interfering with QC's business.
Qualcomm is claiming that Arm is refusing to license the v10 architecture to them and refused to license some other TLA cores requiring them to get the Nuvia Custom CPU team to build cores for those products instead.
This explains their expansion into Risc-V it's a hedge against Arm interfering with QC's business.
It'll turn out OK. They'll just be acquired by Apple, who will continue putting out the most powerful CPUs on the market with AArch64 architecture.
Why does Qualcomm need this? They don't need to license RISC-V.
Is all the IP they acquired with Nuvia[1] tainted? Or were they just using ARM-derived internals?
From my understanding, just slapping on a different instruction decoder isn't a big technical hurdle. Actually, I wonder if it would be possible to design a chip with both an ARM and a RISC-V decoder on the same die and just fuse-off the ARM die on select units to avoid any fees...
[1] https://en.wikipedia.org/wiki/Qualcomm#2015%E2%80%932024:_NX...
Is all the IP they acquired with Nuvia[1] tainted? Or were they just using ARM-derived internals?
From my understanding, just slapping on a different instruction decoder isn't a big technical hurdle. Actually, I wonder if it would be possible to design a chip with both an ARM and a RISC-V decoder on the same die and just fuse-off the ARM die on select units to avoid any fees...
[1] https://en.wikipedia.org/wiki/Qualcomm#2015%E2%80%932024:_NX...
ARM cancelled their architecture license and sued them, Qualcomm won, but with a threat like that to your core business it's best to have an escape hatch.
They'll need to license future versions of the ARM ISA and now they know the licensor is hostile.
They'll need to license future versions of the ARM ISA and now they know the licensor is hostile.
They are basically acquiring talent and/or preexisting IP. RISC-V is free but implementations are the sole IP of the company.
Implementing ARM and RISC-V decoders might depend on licensing fine print for each licensee
Implementing ARM and RISC-V decoders might depend on licensing fine print for each licensee
This. SiFive, for example, is a proprietory core design based on the open source RISC V spec. Hazard3 [0] on the other hand, is an open source core design.
[0] https://github.com/Wren6991/Hazard3
[0] https://github.com/Wren6991/Hazard3
Another opensource core design is XiangShan https://xiangshan.cc/en/
Another opensource is https://github.com/SpinalHDL/VexRiscv
[deleted]
Eating the competitor is one way to win. If you're scared of them, just buy them out.
Doesn't have to be fear, it can be simple greed, too. "Hey, look, .05% revenue boost, nomnomnom".
No big company would bother with an acquisition if the top result is 0.05% increase in revenue.
> They don't need to license RISC-V.
Correct. However you need circuitry on silicon to implement said architecture which is the expensive and time consuming part.
Correct. However you need circuitry on silicon to implement said architecture which is the expensive and time consuming part.
There are a lot of little cores in phones doing little core things. Having a first rate design team experienced in an ISA that is royalty free probably makes sense. They'll be able to expand the use of RISCV up the value chain ver time.
Buying a team that's already working on RISCV also reduces the chances of ARM lawyers getting involved.
Buying a team that's already working on RISCV also reduces the chances of ARM lawyers getting involved.
Why would you acquire massive out-of-order super fast CPU team if you wanted a bunch of small cores. There are much cheaper teams and cores you could use for that.
Some modems and radios need more than reference-implementation performance and everything in a phone benefits from power efficiency.
Sure but there are teams that work on radios and modems that likely could be acquired and not sure Qualcomm needs that. RISC-V isn't so different that you need to acquire a team.
Ventana is a company founded and build around a team to do massive ultra wide chips for data-center, and their focus was not efficiency primary. The kinds of chips they build are just not the right fit. Moving all that team over to something on the literal other end of the spectrum and dropping their existing products and costumers seems a bit silly.
Ventana is a company founded and build around a team to do massive ultra wide chips for data-center, and their focus was not efficiency primary. The kinds of chips they build are just not the right fit. Moving all that team over to something on the literal other end of the spectrum and dropping their existing products and costumers seems a bit silly.
https://patents.justia.com/assignee/ventana-micro-systems-in...
RISC-V being freely available does not mean that implementations of it will not be patented from here to the Orion nebula and back.
RISC-V being freely available does not mean that implementations of it will not be patented from here to the Orion nebula and back.
It's probably just for IP and talent acquisition, if I had to guess. People who can design high performance server-class CPU microarchitectures are rare.
Frankly, Ventana seemed like an interesting entry in the space, but I have no idea who would have actually bought their servers at the end of the day. They taped out multiple designs, but none actually seem to exist outside their labs. I don't really see any path to meaningful RISC-V server adoption for at least several more years and by that time Qualcomm could design something on their own, assuming they are serious about re-entering the market. Grabbing the talent and any useful IP/core design components makes the most sense to me, anyway.
Frankly, Ventana seemed like an interesting entry in the space, but I have no idea who would have actually bought their servers at the end of the day. They taped out multiple designs, but none actually seem to exist outside their labs. I don't really see any path to meaningful RISC-V server adoption for at least several more years and by that time Qualcomm could design something on their own, assuming they are serious about re-entering the market. Grabbing the talent and any useful IP/core design components makes the most sense to me, anyway.
> Actually, I wonder if it would be possible to design a chip with both an ARM and a RISC-V decoder on the same die and just fuse-off the ARM die on select units to avoid any fees...
That's not quite what Raspberry Pi did with the RP2350 (the ARM and RV cores are wholly separate) but they did include the ability to fuse off one side or the other, so I wonder if they'll release a cheaper RV-only version at some point.
That's not quite what Raspberry Pi did with the RP2350 (the ARM and RV cores are wholly separate) but they did include the ability to fuse off one side or the other, so I wonder if they'll release a cheaper RV-only version at some point.
QC likely use a lot of Arm IP, Nuvia notwithstanding, and want a way out of the general Arm monopoly. Seems to be a growing trend.
A dual ISA decoder with with fuse-off options will likely have unwelcome power-perf-area and yield consequences.
A dual ISA decoder with with fuse-off options will likely have unwelcome power-perf-area and yield consequences.
Fused off silicon consumes power? I assumed it just went dark.
You’re right. But consider that in order to be useful when not fused off, the design would need to have a bunch of additional logic (interconnect ports, power control machinery etc) at the periphery of the to-eventually-be-fused-off area that would likely remain even when things were fused off. That may impact power.
Apart from that there’s the other usual angles: The very fact that there’s additional logic in the compute path (eventually fused off) means additional design and verification complexity. The additional area, although dark, eats into the silicon yield at the fab.
Not saying it’s not possible.
Apart from that there’s the other usual angles: The very fact that there’s additional logic in the compute path (eventually fused off) means additional design and verification complexity. The additional area, although dark, eats into the silicon yield at the fab.
Not saying it’s not possible.
Acquihire and hedging bets.
Because the ISA that a modern microprocessor is engineered to execute is different from the Micro-ops execution engine/Other(The Actual Hardware) that's a custom design that's the IP of the creator. And so Qualcomm wants that RISC-V running CPU core design IP that belongs to Ventana Micro Systems and the ISA on modern microprocessors is just a set of execution rules that the actual hardware(Micro-Ops execution engine and associated cache subsystems/other parts of the hardware and that IP that belongs to Ventana!) is engineered to execute.
Qualcomm also wants the RISC-V engineers and their Knowledge and the Software Ecosystem and SDKs/Tools that Ventana has developed over the years to create CPU cores that execute that RISC-V ISA. And that includes all the design Verification tools/EDA tools that Ventana developed for their specific CPU core designs and all that non hardware stuff that takes a larger investment in dollars than just the hardware's development alone costs!
So the RISC-V ISA is Royalty free but not anyone's actual RISV-V ISA executing CPU core designs that cost millions to create and are the proprietary part of the Acquisition that Qualcomm is after. I'd imagine that Qualcomm's Nuvia engineers could more rapidly swap out the ARM ISA Instruction Decoders on any Oyron cores with some RISC-V Decoders and use most of the same Oryon Micro-op engine design that's native to the current Oryan generation cores but maybe Ventana's micro-op execution engine has something that's valuable to Qualcomm as well.
And so ISAs on modern microprocessors are abstracted away at the actual hardware level by the Micro-ops execution engine desogns that are proprietary to the ones that created them. And the reason that many license from ARM holdings is not just the ISA but the software/OS/Drover ecosystem that's built up over the decades for the ARM ISA ecosystem and that costs many times more than the hardware's costs to develop and maintain over the years. And so the ARM OS/Software/API and driver ecosystem is decades more mature than the RISC-V OS/Software/API and driver ecosystem, and that took years and 100s of billions in investments to get ARM where it is today!
But since RISC-V is royalty free there are hundreds of companies using RISC-V, including Nvidia for it's FALCON(FAst Logic CONtrollers) that are used all over Nvidia's GPUs and other accelerators. And with RISC-V one is free to implement only a subset of the RISC-V ISA or create custom RISC-V ISA extensions unlike ARM holdings where licensees have to implement the entire ARM Licensed ISA regardless of if all the instructions are needed for the task and no ISA extensions allowed.
So maybe Qualcomm is interested in the micro-controller market that's lower margin and that makes RISC-V's Royally Free more attractive! Or Qualcomm, like Nvidia, wants to develop some RISC-V Micro-Controllers for it's own in-house needs and not have to pay for ARM Holdings ISA based Micro-Controller designs. Look at Nvidia's dozens of on GPU die Controllers(Encoder/Decoder Logic,Etc) and because that's Nvidia FALCON RISC-V based that's quite a bit of savings in Royalty Payments and CPU core design payments to ARM Holdings or anyone else because FALCON is Nvidia's In-House IP and that RISC-V ISA is free to use for Nvidia or others to save billions that way.
Qualcomm also wants the RISC-V engineers and their Knowledge and the Software Ecosystem and SDKs/Tools that Ventana has developed over the years to create CPU cores that execute that RISC-V ISA. And that includes all the design Verification tools/EDA tools that Ventana developed for their specific CPU core designs and all that non hardware stuff that takes a larger investment in dollars than just the hardware's development alone costs!
So the RISC-V ISA is Royalty free but not anyone's actual RISV-V ISA executing CPU core designs that cost millions to create and are the proprietary part of the Acquisition that Qualcomm is after. I'd imagine that Qualcomm's Nuvia engineers could more rapidly swap out the ARM ISA Instruction Decoders on any Oyron cores with some RISC-V Decoders and use most of the same Oryon Micro-op engine design that's native to the current Oryan generation cores but maybe Ventana's micro-op execution engine has something that's valuable to Qualcomm as well.
And so ISAs on modern microprocessors are abstracted away at the actual hardware level by the Micro-ops execution engine desogns that are proprietary to the ones that created them. And the reason that many license from ARM holdings is not just the ISA but the software/OS/Drover ecosystem that's built up over the decades for the ARM ISA ecosystem and that costs many times more than the hardware's costs to develop and maintain over the years. And so the ARM OS/Software/API and driver ecosystem is decades more mature than the RISC-V OS/Software/API and driver ecosystem, and that took years and 100s of billions in investments to get ARM where it is today!
But since RISC-V is royalty free there are hundreds of companies using RISC-V, including Nvidia for it's FALCON(FAst Logic CONtrollers) that are used all over Nvidia's GPUs and other accelerators. And with RISC-V one is free to implement only a subset of the RISC-V ISA or create custom RISC-V ISA extensions unlike ARM holdings where licensees have to implement the entire ARM Licensed ISA regardless of if all the instructions are needed for the task and no ISA extensions allowed.
So maybe Qualcomm is interested in the micro-controller market that's lower margin and that makes RISC-V's Royally Free more attractive! Or Qualcomm, like Nvidia, wants to develop some RISC-V Micro-Controllers for it's own in-house needs and not have to pay for ARM Holdings ISA based Micro-Controller designs. Look at Nvidia's dozens of on GPU die Controllers(Encoder/Decoder Logic,Etc) and because that's Nvidia FALCON RISC-V based that's quite a bit of savings in Royalty Payments and CPU core design payments to ARM Holdings or anyone else because FALCON is Nvidia's In-House IP and that RISC-V ISA is free to use for Nvidia or others to save billions that way.
I wonder why SiFive wasn't the acquisition target
SiFive have apparently been shopping themselves around for a while. But they've been around for a long time, taken loads of investment, had a huge number of employees at one point (not now), and don't have very competitive products. My speculation is they're just not a very attractive acquisition with a complex ownership structure, and are demanding too much money to compensate their earlier investors.
A perfect target for Intel then, followed by a rapid exodus of the employees and destruction of the IP (like every other Intel acquisition).
They almost got bought by Intel, but then even Intel noped out.
https://www.tomshardware.com/news/intel-failed-to-buy-sifive
https://www.tomshardware.com/news/intel-failed-to-buy-sifive
Does anyone know or have they leaked potential cost of acquisition?
The $2B deal with Intel fell through. Thought they were arguably worth more on paper then. My guess is that they're in a weird place where a fair offer at the moment is less than the investment they've gotten so far.
Note that the $2 billion deal story was always "according to people with knowledge of the matter", and I wonder if it was nothing more than Intel taking a peek at Sifive's technology and books.
https://archive.is/FVMLI#selection-3331.81-3331.129
https://archive.is/FVMLI#selection-3331.81-3331.129
[deleted]
Might be worth more than Qualcomm is willing to spend and/or introduce antitrust concerns. This feels like a hedging of bets, no need for Qualcomm to buy the biggest name in the RISC-V space.
Is this just Qualcomm buying itself another vote on the RISC-V foundation board?
No, it's one company == one vote. There's a similar situation with IBM & Red Hat. Since IBM owns Red Hat, Red Hatters (like myself) may participate in meetings but where individuals from both companies are present "there can be only one."
2025 and counting. Apple launched the M1 in 2020. I am an Apple user but not a fanboy but everyday I wonder about the magic in Apple that is unique because even established competitors with virtually infinite money and incredible processes can't move forward. Another incredible aspect is the early addition of an NPU by Apple in a SoC.
I would love to resurrect my XPS 13s with a durable battery and working in Linux without trigerring the fan. The same for my Lenovo Xs.
In my imagination I am waiting for the billionaire geeks doing their part for fun (e.g. energy management in Linux).
I would love to resurrect my XPS 13s with a durable battery and working in Linux without trigerring the fan. The same for my Lenovo Xs.
In my imagination I am waiting for the billionaire geeks doing their part for fun (e.g. energy management in Linux).
> Apple launched the M1 in 2020.
which means the M1 was being worked on since at least 2018, I'd bet much earlier than that, for sure much earlier than that if you count silicon which never left the lab.
reminder iphones run on apple silicon since 2010, which means they had to be working on it at least since 2008. they have a lot of experience in silicon design by now.
which means the M1 was being worked on since at least 2018, I'd bet much earlier than that, for sure much earlier than that if you count silicon which never left the lab.
reminder iphones run on apple silicon since 2010, which means they had to be working on it at least since 2008. they have a lot of experience in silicon design by now.
My point holds even if they started earlier, companies such as Samsung has their own chips and they could also put notebooks on the market.
Why would Samsung do that? They have no sweetheart ARM licensing deal, they make more money selling their fab space to other customers.
Softbank could extend more generous architectural licenses to these businesses if they wanted to stimulate ARM PC sales. But they don't, so now we're here.
Softbank could extend more generous architectural licenses to these businesses if they wanted to stimulate ARM PC sales. But they don't, so now we're here.
Qualcomm has had DSPs in its chips for a long time, providing a lot of NPU-like functionality before the term NPU had been coined. What Qualcomm currently calls its NPUs are just Hexagon DSP cores with specific instructions and abilities for matrix math and common inferencing datatypes.
The original Apple M1's performance per Watt and physical battery size may have been special when it first came out, but nowadays there's nothing special about its hardware specs relative to a modern x86 laptop.
The difference you perceive is mostly software. Windows and Linux are really just designed for desktop machines first and foremost. MacOS was too, but when they transitioned to Apple Silicon, they replaced a lot of the internals with stuff taken from iOS, and iOS is designed with batter life first and foremost.
Getting the level of battery life out of non-apple laptops is just going to be a long, hard slog of going through the operating systems and auditing *everything* and every design decision for how it affects battery life and how much resources its using.
The difference you perceive is mostly software. Windows and Linux are really just designed for desktop machines first and foremost. MacOS was too, but when they transitioned to Apple Silicon, they replaced a lot of the internals with stuff taken from iOS, and iOS is designed with batter life first and foremost.
Getting the level of battery life out of non-apple laptops is just going to be a long, hard slog of going through the operating systems and auditing *everything* and every design decision for how it affects battery life and how much resources its using.
Interesting, I thought Apple Silicon was still ahead on raw numbers, would you mind pointing me at any resources to learn more?
Is that still true when you consider the whole system power consumption vs performance? I was under the impression that Apple's ram and storage solutions give them a small edge here (at the cost of upgradability / repairability)
Is that still true when you consider the whole system power consumption vs performance? I was under the impression that Apple's ram and storage solutions give them a small edge here (at the cost of upgradability / repairability)
Apple Silicon has a lead in performance per watt over the competition (not a gigantic one, but a real one nontheless), but we were talking about M1, which is 5 years old now and has no appreciable hardware advantages compared to an AMD or Intel laptop made in the last few years.
The reason an old M1 laptop gets better battery life is almost entirely a software difference.
The reason an old M1 laptop gets better battery life is almost entirely a software difference.
Thanks for the explanation. I see where I got confused now
"raw numbers" always means a lot of things. Apple's CPU benchmarks are neck-and-neck in multicore and usually top-of-class in single-core performance compared to other desktop chips. x86 will draw more power when idling and during bursty workloads, but is typically more efficient during sustained SIMD-style workloads.
If you want an example of where Apple's design chops are pretty weak, look at their GPUs: https://browser.geekbench.com/opencl-benchmarks
The M3 Ultra is putting up some of the saddest OpenCL benches I've ever seen from a 200-300w GPU. The entry-level RTX 5060 Ti runs circles around it with a $400 MSRP and 180w TDP. I truly feel bad for anyone that bought a Mac Studio for AI inference.
If you want an example of where Apple's design chops are pretty weak, look at their GPUs: https://browser.geekbench.com/opencl-benchmarks
The M3 Ultra is putting up some of the saddest OpenCL benches I've ever seen from a 200-300w GPU. The entry-level RTX 5060 Ti runs circles around it with a $400 MSRP and 180w TDP. I truly feel bad for anyone that bought a Mac Studio for AI inference.
> Another incredible aspect is the early addition of an NPU by Apple in a SoC.
I'm going to go out on a limb and guess that you've not used CUDA yet. NPUs are a lot of things, but "incredible" is the last word an engineer would use to describe them these days.
I'm going to go out on a limb and guess that you've not used CUDA yet. NPUs are a lot of things, but "incredible" is the last word an engineer would use to describe them these days.
Incredible means they follow a SoC approach where the RAM is shared between CPU, GPU, and NPU instead of separated like in a typical GPU such as Nvidia.
I consider the Tegra chip several times more incredible. What's so special about Apple's architecture to you?
Tegra was interesting for its time but saying it’s “several times more incredible” than Apple’s architecture is just opinion. Apple builds custom high-performance CPU/GPU designs with industry-leading perf-per-watt and tight OS integration. Tegra and Apple SoCs were built for very different goals, so the comparison only makes sense with concrete metrics, not broad claims.
So much for the $1.4B spent on NUVIA.
https://www.allaboutcircuits.com/news/startup-key-apple-goog...
https://www.allaboutcircuits.com/news/startup-key-apple-goog...
If I were to guess, Qualcomm wants to replace its various Cortex-M cores with RISC-V equivalents. This saves them money on licensing, reduces their dependency on ARM, and doesn't break customer-facing compatibility. Ventana is probably more of an aquihire to get their designer team.
"We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile." -Qualcomm, probably