Qualcomm didn't spend enough time reading riscv-basics.com
Qualcomm starts a RISC-V joint venture
41–50 of 82 posts
Re: Qualcomm starts a RISC-V joint venture
#42Earlier quoted context omitted.
ARM: "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/5fb7e415d77dd80... ) Also "This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include…
OpenSBI is open source so hardly comparable to SMM. https://github.com/riscv-software-src/opensbi
There's Open Source SMM as well (e.g. https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/...) and it's still a pain.
"There's services outside the kernel's control that may or may not do what the kernel/userland/user expect because they can be independently updated, and, oh by the way, they're really powerful" is simply a pain to deal with.
Re: Qualcomm starts a RISC-V joint venture
#43Earlier quoted context omitted.
ARM: "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/5fb7e415d77dd80... ) Also "This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include…
>SBI, which is RISCV's poor-man's implementation of x86 SMM, SMM is totally opaque and does whatever it wants, kidnapping the cpu and giving it back after a random amount of time if at all. Fuck determinism or meeting any sort of hard realtime requirements. It hides bugs and architecture details from the OS, and it often can't even be disabled. SBI serves a similar role, without the opacity. OS can make requests to i…
This is a thread about Qualcomm looking into RISC-V. Seeing how "great" their ARM-based designs are, they will manage to make a real mess out of SBI soon enough and there will be weeping and gnashing of teeth.
I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
Re: Qualcomm starts a RISC-V joint venture
#44I hope they don't create any license themselves and open source everything too
Yeah, "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 .
Qualcomm 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.
Re: Qualcomm starts a RISC-V joint venture
#45I hope they don't create any license themselves and open source everything too
Yeah, "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 .
RISC-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.
Re: Qualcomm starts a RISC-V joint venture
#46Earlier quoted context omitted.
>SBI, which is RISCV's poor-man's implementation of x86 SMM, SMM is totally opaque and does whatever it wants, kidnapping the cpu and giving it back after a random amount of time if at all. Fuck determinism or meeting any sort of hard realtime requirements. It hides bugs and architecture details from the OS, and it often can't even be disabled. SBI serves a similar role, without the opacity. OS can make requests to i…
This is a thread about Qualcomm looking into RISC-V. Seeing how "great" their ARM-based designs are, they will manage to make a real mess out of SBI soon enough and there will be weeping and gnashing of teeth. I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
Nevermind about making a non-compliant SBI implementation.
Why make an implementation in the first place? There's no reason to use anything else than opensbi.
Re: Qualcomm starts a RISC-V joint venture
#47Earlier quoted context omitted.
Salary in Germany is good compared to regular automotive companies because Qualcomm has this nice stock bonus. Environment is rather toxic. The salary does not compensate that.
> Environment is rather toxic. The salary does not compensate that. Same with NXP. Salaries and bonuses are very good(by European standards, ignore FAANG wages) but the overtime, work pressure and workplace toxicity makes that a difficult proposition if you can't stomach the ascension to the level where the REAL money starts to come in. There are indeed people at these big semi companies who can slack off and collect…
I actually heard good things from friends working at NXP. Long term career incentives, good salary, training and incentives to collaborate to OSS… quite good signs to me
Re: Qualcomm starts a RISC-V joint venture
#48Earlier quoted context omitted.
This is a thread about Qualcomm looking into RISC-V. Seeing how "great" their ARM-based designs are, they will manage to make a real mess out of SBI soon enough and there will be weeping and gnashing of teeth. I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
Nevermind about making a non-compliant SBI implementation. Why make an implementation in the first place? There's no reason to use anything else than opensbi.
Because Qualcomm _really_ dislikes letting others take a look at their (usually very boring) secret sauce. Even partners working on projects shoveling revenue counted with a sizable number of digits their way.
That's also why QCSBI (or whatever they'll call it) won't be replaced by the kernel even though the architecture theoretically allows for it: That would be ceding control.
Re: Qualcomm starts a RISC-V joint venture
#49Would 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 b…
I read this as “If you’re reading this ARM, stop raising prices or we’ll replace you”
Until 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.
Re: Qualcomm starts a RISC-V joint venture
#50Earlier quoted context omitted.
Once 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.
If 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.
What 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.