This 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.
> 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
I 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!
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 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.
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
NXP has bought so many companies that it depends on the unit and country a lot.
Likely quite a bit of difference between former Philips and former Freescale/Motorola for example.
I found Samsung very good. My direct experience was as an English-speaking foreigner doing compilers and JITs etc in their Moscow R&D office mid 2014-early 2018, and visiting colleagues working on the same project in San Jose. You had to be around the office 45 hours a week (first entry to last exit each day, so that includes breaks), but they were serious about people taking weekends off, and their legally-entitled vacation (28 days, plus about 10 statutory holidays, plus about 8 days from New Year to Orthodox Christmas). If your manager asked you to work in the weekend then you got double or triple time.
Unfortunately the location is undesirable at the moment.
There are insane deadlines in semiconductor industry. We started many times already being too late to make main customer happy. I was able to catchup couple times doing 55-65 hour weeks. But it gets slowly normal practice instead of exception.
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.
Heavily depends on manager/team/business unit, but the main issue is usually insane workload and insane deadlines on projects that are already late from the moment they start because sales/marketing/execs promised $MAJOR_CUSTOMER something totally unrealistic will be delivered.
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.
That'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.
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.
That's pretty much an overgrown hobbyist project to them.
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?
not 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.
No 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].
Uefi is pretty pointless when your device doesn't even run a full-blown operating system. In the embedded world your software knows exactly what hardware it is going to run on, so uefi is just a waste of time.
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.
Many of these devices will run Linux though, and it's becomming increasingly more common as even the low end chips are pretty capable nowadays. It could be worthwhile to build some lightweight alternative to UEFI that just handles disk identification and handing off a devtree to whatever bootloader comes after it instead of implementing the behemoth of a spec that is all of UEFI. Call it "LWFI", "light-weight firmware interface"?
Not really, no. Linux isn't going to run on a chip with 48k of memory which doesn't even have an MMU, and doing disk identification is pretty pointless when your "disk" is 256k on on-chip flash - or a hardsoldered 2M SPI chip if you are really lucky.
UEFI 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.
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 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.
>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 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.
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.
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.
"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.
Would 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.
I think you can tell a lot from the companies themselves.
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.
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.
> 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.
It’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.
Qualcomm, 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
x86 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.
Why 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.
SPARC 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.
OpenSPARC seems to have had open 64-bit designs released before RISC-V was launched?
"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
OpenSPARC/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.
SPARC 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.
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.
Blocking 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.
PIC 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.
A 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.
> 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.
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.
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.
Looking 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.
https://www.engadget.com/arm-qualcomm-lawsuit-trademark-infr...