Qualcomm starts a RISC-V joint venture
arstechnica.com
arstechnica.com
https://www.engadget.com/arm-qualcomm-lawsuit-trademark-infr...
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
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!
I certainly see Qualcomm engineers frequently leave and transition to FANG.
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 huge paychecks but those are the exception, as some people in the trenches are burning the candle on both ends to make the deadlines of masks reaching the fabs on time.
Unfortunately the location is undesirable at the moment.
Tooling is also very specific. There are gazillions of scripts written in all possible languages for all sorts of semiconductors. Some colleagues will happily backstab you not sharing information about their tools.
Oh yeah, that sounds familiar.
The churn level is high. People are constantly fired, let go, or leave after their relocation bonus expires if they don't see any promotions after their tolls.
Lots of "Game of Thrones" backstabbing going on behind the scene inside the org between managers, each trying to get the spotlight for the successes on them to get that sweet promotion, while disregarding their team and workers as disposable commodities that can always be replaced by overseas workers if they don't fall in line and deliver on the impossible deadlines.
The difference in pay between junior and seniors/managers is huge, so they dangle that carrot in front of you so you put up with everything just for the chance of hopefully making it to that level one day.
Many companies are a lot more friendly to small customers, though.
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.
Chips are usually sold in reels of 1k or 3k. For quantities like 10k chip vendors will just redirect you to a distributor like Mouser or Digikey - who will be able to ship an order of 150k to you next-business-day without any issues.
The problems start when the chips you want aren't redistributed. You're a rounding error to the manufacturer. Why spend the time and effort assisting a startup with a one-off 10k order when the next email is from a large car manufacturer placing a guaranteed 15M order?
For reference https://www.linkedin.com/posts/george-hotz-b3866476_comma-3x...
https://www.linkedin.com/posts/george-hotz-b3866476_qualcomm...
[0] https://github.com/riscv/riscv-platform-specs/blob/main/risc...
You only need something like uefi when you start using mostly hardware-independent software, like trying to run Linux on it. A lot of the chips these companies make are not even remotely close to that.
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/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-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.
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 it through APIs that are part of the spec, and even take over all its roles. It has been co-designed by hardware and software (operating systems and embedded) people across the industry, both companies and independent members. It's not even comparable.
Go read the SBI 1.0 spec, and the SBI 2.0 draft.
I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
Why make an implementation in the first place? There's no reason to use anything else than opensbi.
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.
"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.
The current info:
> aimed at advancing the adoption of RISC-V globally by enabling next-generation hardware development.
Doesn't tell you much!
It seems extremely likely that the goal is to create a RISC-V ecosystem, which ranges from design, to chips, to endproducts in automotive.
To rival ARM you need an actual competitive industrial product.
- You need to define use-cases "what chips does a car need?", specific technical requirements "what communication, what instruction sets, what speed, etc.?"
- Figure out how produce chips at scale
- Create suitable development environments, libraries and integration into other buisiness tools
-Use that tooling to create an embedded product
ARM has all of that in their ecosystem, RISC-V does not. None of the companies listed can do all of that on their own. If they want to compete with ARM they need to compete with the entire ARM ecosystem and it seems that is their goal.
If you’re in this market long enough, you know that apart from the current hype, RISC-V is not special.
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.
OpenSPARC? OpenPOWER? There are plenty of solid open ISAs for anyone who wants to do that.
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.
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.
"In March 2006, the complete design of Sun Microsystems' UltraSPARC T1 microprocessor was released-in open-source form, it was named OpenSPARC T1. In early 2008, its successor, OpenSPARC T2, was also released in open-source form. These were the first (and still only) 64-bit microprocessors ever open-sourced. " -https://www.oracle.com/servers/technologies/opensparc.html
As far as I know without joining SPARC International you are not allowed to commercially use SPARC 64bit commercially.
There might be open implementations, but that doesn't mean you can be sued for using the architecture.
> 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.
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.
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.
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.
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.
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.
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.