Discussion RISC V Latest Developments Discussion [No Politics]

DisEnchantment

Golden Member
Mar 3, 2017
1,163
3,446
136
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.
1652093521458.png

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.
 

CHADBOGA

Platinum Member
Mar 31, 2009
2,066
718
136
What is your reference to "no politics" about? :frowning::confused2:

It seems like Risc-V has wide industry backing.
 

Leeea

Golden Member
Apr 3, 2020
1,504
1,886
106
What is your reference to "no politics" about? :frowning::confused2:
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:
 

Mopetar

Diamond Member
Jan 31, 2011
6,677
3,720
136
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.
 
  • Like
Reactions: Tlh97 and Leeea

DrMrLordX

Lifer
Apr 27, 2000
19,163
7,920
136
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?
 
  • Like
Reactions: Leeea

Mopetar

Diamond Member
Jan 31, 2011
6,677
3,720
136
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.
 
  • Like
Reactions: Leeea

Doug S

Golden Member
Feb 8, 2020
1,110
1,655
106
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.
 

ASK THE COMMUNITY