7 ms·
Qualcomm starts a RISC-V joint venture
- 5ADBEEF 3y agoQualcomm, Nordic, NXP, Infineon, Bosch. Wonder what the value add for smaller companies is. Nordic is incorporating RISC-V cores into their new part but they have never done automotive certs before. also Qualcomm and Nordic partnering is like cats and dogs living together lol
- Dalewyn 3y agox86 is locked down by Intel and AMD, and ARM demands tribute-- I mean license fees for ARM. That leaves only RISC-V for those who want to make their own processors without paying someone for the privilege. That's the value add.
- crote 3y agoYou could always go for Xtensa, PIC/AVR, or 68k. Still plenty of those around - although ARM has rapidly been eating their lunch the last few years.
- FirmwareBurner 3y agoPIC and AVR (along with 8051 and 6502 based designs) are still used in current consumer products reusing older designs. Yes, ARM Cortex-M0 can cost the same while offering 2x the processing processing power, but redesigning the PCB and rewriting the entire codebase for a new MCU would offset the processing power gains, which are not needed anyway. Most white-label consumer goods just need to poll some keypad buttons, react to some interrupts, and turn a relay ON/OFF depending on a simple state machine reading an ADC, where an 8-/16-bit PIC/AVR is more than enough. If they have a built-in DSP even better.
- brucehoult 3y agoA 6502 or 8051 can do the job but their prices haven't dropped a lot. You can get a 48 MHz RISC-V from WCH (a big 8051 supplier) or Cortex-M0 from Puya for $0.10 to $0.15 depending on whether it's an 8, 16, or 20 pin package. Both the CH32V003 has 2 KB SRAM and 16 KB flash, and the Puya 3 KB SRAM and 20 KB flash. You get the above prices for the WCH at qty 50 (i.e. $5 - $7) on their Aliexpress store, plus a couple of bucks shipping. Being "too powerful" for the job is irrelevant if it's cheaper anyway. Plus easier to use because both use standard GCC/LLVM, support debugging etc.
- aborsy 3y agoOnce RISC-V gains market share, Intel and ARM will gradually react, lowering fees and opening their platforms proportionately, if needed. They will try to block the addition of value and market capture.
- eunos 3y agoIn that case the main strength of RISC-V would be Chinese companies since it is theoretically sanction resistant.
- deleted 3y ago[deleted]
- dkjaudyeqooe 3y agoIf that happens it's a win for everyone, but unlikely in practice, given their business models. Don't see how they can block RISC-V. But an additional advantage for RISC-V is that it's a clean slate specification and very simple at its core, and that enables a lot more use cases that would otherwise be impossible due to legacy cruft.
- hashtag-til 3y agoBlocking won’t happen, but remember theses companies also detain a massive patent portifolio which is hard not to break while implementing similar techniques. Despite personally I really wish it was different, there is a lot of fragmentation already in RISC-V and I feel it only tends to grow given managers will always push to create some internal secret sauce.
- RetroTechie 3y agoWhat I like about RISC-V is that it's not just open for the sake of being open, but actually a well-designed architecture. Practical & effective from embedded to enterprise & beyond. For example, modularity: most other ISAs have had heaps of extensions bolted onto the ISA over time, in order to produce fast CPU cores. Things like MMX, SSEx, AVX, ARM's Thumb, Neon, etc etc. So if (for example) you want x86 core with some form of AVX, you get at least a 64 bit, 2-core cpu with SSEx, single & double precision floating point, a long list of addressing modes, support for i386 software/memory models, the works. If you want a 'minimal' core, you're looking at ancient 386 or 486, and neither AMD or Intel will bake those for you. Over in the RISC-V camp, a vendor can take a minimal core, add only those extensions needed for a System-on-Chip's intended uses, bring that to a foundry, and have software toolchain in place the day silicon is taped out. Instruction encoding is mostly (entirely?) the same between 32-bit and 64-bit versions. 64-bit simply having wider registers. Compressed "Thumb" instructions translate 1:1 to instructions with the standard 32-bit encoding. Bit fields encoding source & destination registers are always in the same place. Sign extension is trivial. No myriad of obsolete memory models. Etc, etc, as I said: well designed architecture. All these goodies enable efficient / small / cheap hardware, and relatively easy software support.
- dkjaudyeqooe 3y ago> That leaves only RISC-V for those who want to make their own processors without paying someone for the privilege. That's the value add. I don't think that's the value add for larger companies who want to pay and get a high level of support, it's that there are multiple vendors in theory and practice.
- ThrowawayR2 3y ago> "That leaves only RISC-V for those who want to make their own processors without paying someone for the privilege." OpenSPARC? OpenPOWER? There are plenty of solid open ISAs for anyone who wants to do that.
- CameronNemo 3y agoWhy would someone use OpenSPARC rather than riscv? Seems like the Linux distros have some a-tier support for riscv64, or will soon. Debian supports SPARC right? Anyone else? That's not even getting into upstream testing. I imagine there is more development attention to riscv tooling e.g. GCC, llvm, glibc, musl, util-linux, et cetera.
- NovaDudely 3y agoOpenSPARC/POWER is the reason why I am not too excited about RiscV. We have had open GPL designs for close to 20 years and they just sort of went nowhere. RiscV seems to be something neat for those that design processors or work with them low level but for the general person I do not think it will result in anything amazingly different.
- panick21_ 3y agoSPARC was only open for 32 bit and POWER was not actually open until many years after RISC-V. > RiscV seems to be something neat for those that design processors or work with them low level but for the general person I do not think it will result in anything amazingly different. For the general person of course nothing technical matters. But for the industry it matters a whole lot.
- panick21_ 3y agoSPARC only has a 32bit version that's open. Its really not a option. Even if want to use something 32bit, you would like some upgrade path for the future. And technically its also just worse in pretty much every way. After the standardisation there was very little continued progress and investment. OpenPOWER only became open many, many years after RISC-V was open. OpenPOWER was basically just a marketing name, it was not actually open. Once RISC-V was opened for real, eventually the pressure was on OpenPOWER to actually be opened. However by the time they opened it up RISC-V already had all the momentum both commercially and in terms of open development.
- baq 3y agoNot a word about uefi or any other kind of standardized booting. Not surprising given the use case list but still disappointing.
- camel-cdr 3y agoNo idea why they would talk about that in such a blog post, but as I understand it, the booting process will be standardized by the platform specification [0]. [0] https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...
- xvilka 3y agoUEFI is a bad choice for embedded. It has too much of the PC quirks, which is mostly irrelevant on ARM or RISC-V. They should have tried to create something new, without x86 cruft.
- pgeorgi 3y agoARM: "This document defines the Boot and Runtime Services expected by an enterprise platform Operating System or hypervisor, for an SBSA-compliant Arm AArch64 server which follows the UEFI and ACPI specifications." (https://documentation-service.arm.com/static/5fb7e415d77dd807b9a80c80?token= https://documentation-service.arm.com/static/5fb7e415d77dd80...) Also "This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include the PSCI, SMCCC, UEFI, ACPI, SMBIOS, and DT interfaces. Requirements that are based on these interfaces are specified. In addition, various recipes are created to accommodate the various operating systems and hypervisors." (https://documentation-service.arm.com/static/627a75d3148af93a314a2b36?token= https://documentation-service.arm.com/static/627a75d3148af93...) Two out of three "recipes" are UEFI-based. -- As for RISCV, they're embracing UEFI, too: https://riscv.org/announcements/2022/06/risc-v-announces-first-new-specifications-of-2022-adding-to-16-ratified-in-2021-risc-v-international/ https://riscv.org/announcements/2022/06/risc-v-announces-fir... Note that the announcement also refers to SBI, which is RISCV's poor-man's implementation of x86 SMM, quickly becoming a required component on the platform because OSes call into that.
- Havoc 3y ago> At first, the group will be focused on automotive uses Slightly ironic given how geohot has been ranting on stream non-stop for the last few days about how terrible it is to work with them for his comma.ai self-driving startup
- localplume 3y agonot really. just because Qualcomm is pursuing RISC-V doesn't mean their customer service isn't absolute dogshit, which is what geohot was talking about.
- crote 3y agoI bet that is just a matter of multinationals not wanting to bother with tiny startups. Unless you are ordering hundreds of thousands of chips, they are not even going to respond to your emails. You just aren't worth their time, so they except you to stick to public documentation, buy their dev kit, and figure out out on your own. Want to use a part without public documentation? Tough luck!
- nomilk 3y agoI have no idea if it's a lot or not, but for reference, Comma's initial (trial) order was for 10k chips.
- pclmulqdq 3y agoThat's very small for an automotive product, particularly when you don't have a much bigger follow-up order on your timeline. Around million units is the normal volume, and it's where companies like Qualcomm will start to talk to you. Many companies are a lot more friendly to small customers, though.
- FirmwareBurner 3y ago>That's very small for an automotive product Also automotive customers tend to stick with their long term partners. It's why Renesas, Infineon and NXP(former Freescale) own the automotive MCU market. Once you heavily invest in the ecosystem and buy all the tooling, compilers, debuggers, JTAG trace probes, and your workforce is already accustomed to all the pitfalls and workarounds of an architecture, it's too expensive too switch to a different provider.
- hruzgar 3y agoI hope they don't create any license themselves and open source everything too
- h2odragon 3y agoYeah, "Qualcomm" is one of those places information never gets out of, right? This might turn out to be "influenced by RISC-V" but completely different actual instructions; with the NDA and lien on your soul before you can even sniff documentation .
- bogwog 3y agoQualcomm is a patent troll. They probably already have a few dozen over-broad patents on things crucial for RISC-V implementations and are just fishing for more.
- snvzz 3y agoThey (alongside every other member) signed an agreement with the RISC-V consortium that limits them on what funny business they can do.
- pgeorgi 3y agoRISC-V is the ISA plus some auxiliary specs. A CPU, and even more so a SoC, contains enough other stuff that Qualcomm can torment their partners (and their lawyers) with. And of course they will do that.
- gchadwick 3y agoWould be great if they actually provided some details of what this joint venture actually aims to do. Is it developing CPUs and other IP? Will it produce actual chips? Perhaps it's just a way for the various companies to pool money and resources to develop RISC-V standards and ecosystem things (like conformance test suites) and maybe bits of IP? The current info: > aimed at advancing the adoption of RISC-V globally by enabling next-generation hardware development. Doesn't tell you much!
- photonbeam 3y agoI read this as “If you’re reading this ARM, stop raising prices or we’ll replace you”
- jkestner 3y agoIt’s too late. ARM has shown that it’s no longer a stable partner. Even if it walks the pricing proposal back, everyone knows it’s on the table the next time ARM changes ownership or has to give shareholders a growth story.
- RetroTechie 3y agoOr as "hey ARM, we'll replace you anyway, but if you sweeten the deal we won't hurry"
- hashtag-til 3y agoUntil same folks are confronted with the costs to validate their own custom chips and realize this is where the real cost is. It’s not on creating an ISA, as there are already many that are free. If you’re in this market long enough, you know that apart from the current hype, RISC-V is not special.
- panick21_ 3y ago> Until same folks are confronted with the costs to validate their own custom chips Except that there are many suppliers who have verified chips that they are happy to sell you. And for some categories of chips, even open ones that are verified. > It’s not on creating an ISA, as there are already many that are free. There are not actually many that are free. And non that a are free and practical with lots of suppliers. > If you’re in this market long enough, you know that apart from the current hype, RISC-V is not special. Ah that is why RISC-V has a insane growth rate and it getting increasing adoption in lots of different market. Maybe somebody should have told all those people that its not actually special.
- lnsru 3y agoLooking at the stock price development and this one announcement sounds desperate and not like a serious strategy. I remember there was something with server ARM processors in the past. Now it’s all gone.
- imtringued 3y agoQualcomm didn't spend enough time reading riscv-basics.com
- monocasa 3y agoThis feels like a shot across the bow in Qualcomm's fight against ARM wrt their core designs bought with Nuvia and whether Qualcomm's ARM architectural license applies to those designs. https://www.engadget.com/arm-qualcomm-lawsuit-trademark-infringement-license-agreements-nuvia-chips-cored-architecture-144307561.html https://www.engadget.com/arm-qualcomm-lawsuit-trademark-infr...
- bfrog 3y agoDoesn’t Qualcomm have more lawyers than engineers? What’s the play here?