Discussion RISC V Latest Developments Discussion [No Politics]

[DisEnchantment]

Some background on my experience with RISC V...
Five years ago, we were developing a CI/CD pipeline for arm64 SoC in some cloud and we add tests to execute the binaries in there as well.
We actually used some real HW instances using an ARM server chip of that era, unfortunately the vendor quickly dumped us, exited the market and leaving us with some amount of frustration.
We shifted work to Qemu which turns out to be as good as the actual chips themselves, but the emulation is buggy and slow and in the end we end up with qemu-user-static docker images which work quite well for us. We were running arm64 ubuntu cloud images of the time before moving on to docker multi arch qemu images.

Lately, we were approached by many vendors now with upcoming RISC-V chips and out of curiosity I revisited the topic above.
To my pleasant surprise, running RISC-V Qemu is smooth as butter. Emulation is fast, and images from Debian, Ubuntu, Fedora are available out of the box.
I was running ubuntu cloud images problem free. Granted it was headless but I guess with the likes of Imagination Tech offering up their IP for integration, it is only a matter of time.

What is even more interesting is that Yocto/Open Embedded already have a meta layer for RISC-V and apparently T Head already got the kernel packages and manifest for Android 10 working with RISC-V.
Very very impressive for a CPU in such a short span of time. What's more, I see active LLVM, GCC and Kernel development happening.

From latest conferences I saw this slide, I can't help but think that it looks like they are eating somebody's lunch starting from MCUs and moving to Application Processors.


And based on many developments around the world, this trend seems to be accelerating greatly.
Many high profile national and multi national (e.g. EU's EPI ) projects with RISC V are popping up left and right.
Intel is now a premium member of the consortium, with the likes of Google, Alibaba, Huawei etc..
NVDA and soon AMD seems to be doing RISC-V in their GPUs. Xilinx, Infineon, Siemens, Microchip, ST, AD, Renesas etc., already having products in the pipe or already launched.
It will be a matter of time before all these companies start replacing their proprietary Arch with something from RISC V. Tools support, compiler, debugger, OS etc., are taken care by the community.
Interesting as well is that there are lots of performant implementation of RISC V in github as well, XuanTie C910 from T Head/Alibaba, SWerV from WD, and many more.
Embedded Industry already replaced a ton of traditional MCUs with RISC V ones. AI tailored CPUs from Tenstorrent's Jim Keller also seems to be in the spotlight.

Most importantly a bunch of specs got ratified end of last year, mainly accelerated by developments around the world. Interesting times.

 

[Vattila]

Here is a nice little explainer about RISC-V, overview of current players, and discussion about RISC-V's prospects in the mainstream computing market.

 

[CHADBOGA]

What is your reference to "no politics" about?

It seems like Risc-V has wide industry backing.

 

[Leeea]

What is your reference to "no politics" about?

not sure, but I will give it a try:

implementations can be proprietary, and it seems the better ones are

implementations can support a subset of the instruction set, add there own extensions, and are binary incompatible with each other

implementations can require signed keys to run, effectively locking the user out of his or her hardware. This seems to be the most common.

some of the big players are pushing this as part of a nationalistic vanity project ( aka China )

much of the excitement seems server/desktop oriented, but much of the product seems embedded/toaster oriented

lacks integer overflow in hardware


some criticisms of the instruction set that go over my head are here:

RISC-V.md

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

[Mopetar]

I like RISC-V. It's got a tidy design and the open source nature of the ISA makes it easy for people to adopt and shape to fit their own needs.

It'll probably do more in the embedded systems market than anywhere else, but frankly that's fine. Not everything has to completely take over the industry to be successful.

If nothing else I think it makes a good teaching architecture since the design is simple and minimalist enough that concepts can be explored and explained without getting bogged down in details or decades of cruft like x86 has accumulated. The open nature also means that students could really build their own implementations and run something on them.

 

[nicalandia]

Some bold claims here...

MIPS Claims "Best-In-Class Performance" With New RISC-V eVocore CPUs - Phoronix

www.phoronix.com

 

[DrMrLordX]

Seems like it's easier to run RISC-V in VM than it is to source actual hardware.

Also:

implementations can be proprietary, and it seems the better ones are

That was inevitable.

implementations can support a subset of the instruction set, add there own extensions, and are binary incompatible with each other

Many are worried about this part right here. RISC-V becomes a lot less compelling from a user/enthusiast PoV when there isn't broad compatibility between implementations. Okay fine, if it's some embedded appliance with a limited ROM that you'll never interact with yourself, who cares? But for larger, more-robust systems . . . talk about a headache!

implementations can require signed keys to run, effectively locking the user out of his or her hardware. This seems to be the most common.

Can you expand upon that? I think i know where you're going there but it would be nice if you'd cite some possible examples. I could be wrong.

much of the excitement seems server/desktop oriented, but much of the product seems embedded/toaster oriented

That was expected. Kind of makes me wonder if AMD will replace TrustZone with RISC-V cores.

lacks integer overflow in hardware

Huh. Why?

 

[Mopetar]

According to the people behind the ISA, it's a matter of the 32-bit instructions not having enough room for a set of instructions that trap and simplifying the hardware design since you don't have to deal with exceptions from more than a small number of instructions.

Also if you're concerned with an overflow you can check for it fairly easily by branching if the result is negative (or positive if you're concerned with underfloor) due to the way most hardware will behave when overflow occurs.

If anyone really wanted to they could write their own instructions (since you can extend the ISA as much as you want) and implement some overflow detection in the hardware. However, it's just a case of not wanting to force that choice on everyone.

 

[Doug S]

Many are worried about this part right here. RISC-V becomes a lot less compelling from a user/enthusiast PoV when there isn't broad compatibility between implementations. Okay fine, if it's some embedded appliance with a limited ROM that you'll never interact with yourself, who cares? But for larger, more-robust systems . . . talk about a headache!

This is why I think consumers getting excited about RISC-V are misguided. Such fragmentation guarantees it will never move out of the embedded niche. I mean, who is going to be excited about having a RISC-V CPU in their router instead of ARM or MIPS?

I'm not even sure what people care about as far as RISC-V. Is it because the hardware is "open"? If you are a Linux purist who won't even use drivers containing binary blobs I guess this matters, but this would occupy some tiny niche of the market like Fairphone. Is it because they hope it will lead to cheaper stuff than ARM due to the lack of licensing costs? If so they are grossly overestimating that factor (or maybe they were worried Nvidia would buy ARM and raise prices a hundred fold)

For the average person it would require Windows supporting RISC-V and that will happen when hell freezes over. Microsoft can't even get people interested in Windows on ARM.

 

[moinmoin]

Keller arrived in the Risc-V camp:

https://twitter.com/x/status/1569161878244564992

 

[Saylick]

Keller arrived in the Risc-V camp:

https://twitter.com/x/status/1569161878244564992

Didn't Keller have an interview where he said something similar? That you can build a high performance core with any ISA you want, just that some ISAs have more baggage than others and at some point if you keep extending an ISA long enough it too will get long in the tooth. When that happens, someone else will create another ground up ISA that is leaner and the cycle continues. The statement that RISC-V will out pace other architectures is probably true until it isn't in the sense that it's currently a relatively lean and immature instruction set. When it starts to catch up to x86 and ARM, the pace of development will naturally slow down.

 

[moinmoin]

Didn't Keller have an interview where he said something similar? That you can build a high performance core with any ISA you want, just that some ISAs have more baggage than others and at some point if you keep extending an ISA long enough it too will get long in the tooth. When that happens, someone else will create another ground up ISA that is leaner and the cycle continues. The statement that RISC-V will out pace other architectures is probably true until it isn't in the sense that it's currently a relatively lean and immature instruction set. When it starts to catch up to x86 and ARM, the pace of development will naturally slow down.

Yeah, shared in the thread as well:

https://twitter.com/x/status/1569287204446343168

Personally I agree with one comment that Risc-V being open source (and many universities picking it up) will very likely make a significant difference in the long run.

 

[desrever]

Open sourced doesn't mean it will be better. It encourages fragmentation. Also generally the open standards move much slower than the implementations so it makes for massive incompatibility problems anyways. Every RISC-V design is radically different with only cosmetic compatibility to other RISC-V chips.

RISC-V will either splinter because the standard is too weak where everyone makes extensions which are incompatible or it will maintain strict guidelines which defeats it's open standard claims in the first place.

 

[eek2121]

There are RISC-V SBCs out there you can buy today, and many more being announced soon. However, they seem to be targeting power consumption and cost rather than performance, so I am rather pessimistic that we will see a high performing chip, except possibly in some cloud exclusive partnership. It is the same situation with ARM. The only ARM client product that performs somewhat well that you can buy is a Mac. Amazon has the Graviton series on AWS, which perform okay-ish, but you can't get those outside of AWS. There are a few other offerings, but again they are all lacking in some way.

Shoot, I'd settle for something with Skylake level of performance, but you can't even get that.

 

[Saylick]

Open sourced doesn't mean it will be better. It encourages fragmentation. Also generally the open standards move much slower than the implementations so it makes for massive incompatibility problems anyways. Every RISC-V design is radically different with only cosmetic compatibility to other RISC-V chips.

RISC-V will either splinter because the standard is too weak where everyone makes extensions which are incompatible or it will maintain strict guidelines which defeats it's open standard claims in the first place.

Yeah, this is the crux of it. If one is trying to avoid baggage, Mr/Mrs. Architect is going to have to be extremely judicious on what does and does not make it into the ISA. Sure, it will be open source and people are welcome to add onto it, but if one wants mass adoption while trying to keep bloat down, someone or some organization is going to have to mandate certain standards of RISC-V that constitution the main branch line. That's going to slow down development because said organization, being open source, is going to be ripe with compromise. Compromise eventually leads to bloat because you try to appease a ton of people, leading to bloat, ironically.

 

[Zor Prime]

I found it surprising that a relatively new Haiku OS (formerly OpenBeOS) dev walks in and gets Haiku OS running on real RISC-V hardware before anyone gets it running on ARM. You'd imagine it would be the other way around.

 

[Doug S]

His point about acquiring bloat is off the mark for ARM since ARM allows dropping AArch32 compatibility entirely and you leave behind the 20 years of accumulated cruft, and 16 bit Thumb, for a very clean and well thought out 64 bit only ISA. Which Apple has already done and ARM is in the process of doing with their cores. AArch32 still matters in the lower end of the embedded market, and RISC-V may fare well there - but because of cost not "bloat".

I don't see RISC-V supplanting ARM in the higher end (i.e. anything where using a 64 bit CPU isn't objectively silly) because 1) it is open but it is not as clean as AArch64, they made some questionable ISA design decisions; 2) it is nearly impossible to overcome ARM's sizeable market momentum/inertia and slow it down, the best RISC-V can do is gain its own market momentum and eat away at ARM's low end embedded market; 3) in markets where you are paying more than say $10 per chip the ARM licensing fees are so small the savings are too small to matter much; and 4) the value of "openness" overrated by techies - and the higher level your software value add is provided the less value any customization you might be able to do has. The companies who would benefit most from openness are the ones who have ARM architectural licenses - and they are the least likely to leave ARM for RISC-V.

 

[moinmoin]

Open sourced doesn't mean it will be better. It encourages fragmentation. Also generally the open standards move much slower than the implementations so it makes for massive incompatibility problems anyways. Every RISC-V design is radically different with only cosmetic compatibility to other RISC-V chips.

I think you guys miss the bigger picture there.

Fragmentation, incompatibilities, slowly moving open standards, that's all irrelevant at universities where fully open access to all aspects of a design is a huge boon. This translates to a huge advantage to teaching students hands on since we are at a point where tech is getting too complicated to not have low level access to all facets of a technology. One can't have that with proprietary ISAs. But unlike veterans who grew up with simpler designs and essentially grew together with the complexity of the industry, today's students have to face the existing complexity without being able to study much of it due to most of it being proprietary. That reason alone will ensure an academic ecosystem to grow around a fully open ISA like Risc-V or similar over the time. And with more and more universities including Risc-V in computer science curriculum more and more students will get hands on with and gain their most experience through it.

And that's were it's getting interesting over the long run, familiarity of graduates will be highest with ISAs they got the most access to during study. That's from today's pov likely is going to be Risc-V, proprietary ISAs like x86 and ARM don't stand a chance there. So companies looking for CPU designers will increasingly have the most available experience to draw from when using Risc-V. So even with existing fragmentation, incompatibilities, slowly moving open standards Risc-V would be the ISA the easiest to advance in, whereas other ISAs will always need further training.

 

[Thala]

And that's were it's getting interesting over the long run, familiarity of graduates will be highest with ISAs they got the most access to during study. T

You overestimate the impact of the ISA used during study. Since ages it typically has been MIPS. In any case, whatever you learn has much more generalized application outside of the sample ISA used.

 

[Thala]

I found it surprising that a relatively new Haiku OS (formerly OpenBeOS) dev walks in and gets Haiku OS running on real RISC-V hardware before anyone gets it running on ARM. You'd imagine it would be the other way around.

Not sure what you are talking about. You can build and run ARM64 builds of Haiku OS right now, while on RISC-V only parts of the bootloader works. You are right, the ARM64 build still has lots of issues but its far more advanced than the RISC-V build.

 

[moinmoin]

You overestimate the impact of the ISA used during study. Since ages it typically has been MIPS. In any case, whatever you learn has much more generalized application outside of the sample ISA used.

I don't think I am. MIPS is also proprietary (which inherently limits what one can do with it during and after study) and slowly on its way out since the late 1990s. Furthermore its owner MIPS Technologies announced last year that it's moving to Risc-V as well.

 

[DisEnchantment]

Fragmentation, incompatibilities, slowly moving open standards,

People who keep mentioning this have not seen what the world in MCUs is like.
PIC/PPC/SH4/ARM A7/8/9/11+/Xtensa/AVR/V850/8051/68K/C86/S32/Cortex M/ and so on, lets not talk about sub families many of which are instruction incompatible.

Imagine one single compiler, one single toolchain, one ISA (albeit many non standard extensions, consortium is working on that), infinite product differentiation, billions and billions of MCUs. Dream come true for these MCU companies, build a product and software support is already there. Minimal investment.
Renesas, NXP, Infineon, STM, MIPS, Imagination, lots of folks on this train. (Lets ignore national programs for developing RISC-V designs)

Somebody's lunch getting eaten there by RISC-V.
If you see RISC-V roadmap, they work from here up.

 

[Nothingness]

I don't think I am. MIPS is also proprietary (which inherently limits what one can do with it during and after study) and slowly on its way out since the late 1990s. Furthermore its owner MIPS Technologies announced last year that it's moving to Risc-V as well.

Sorry but you are overestimating the impact of the ISA. I studied and played with MIPS at Uni (back in a time it was used in workstations and servers, yes I'm old). If RISC-V had existed back then, I would surely have used it rather than MIPS, but that wouldn't haven't changed anything as I never used MIPS in my career in CPU design later on. When you have learned an ISA, you can switch to any other in very little time, or you are missing some of the qualities that make a good engineer.

 

[moinmoin]

Let's bookmark this thread and come back to it in one to two decades. Hope you all can stick around that long.

 

[Mopetar]

Imagine one single compiler, one single toolchain, one ISA (albeit many non standard extensions, consortium is working on that), infinite product differentiation, billions and billions of MCUs.

I'm reminded of xkcd here.

It's highly unlikely that RISC-V outright replaces all of it. Even if it did uproot ARM the open nature all but ensures that we get a similar problem all over again. In reality RISC-V just gets added to the end of your existing list.