Discussion RISC V Latest Developments Discussion [No Politics]

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

DisEnchantment

Golden Member
Mar 3, 2017
1,605
5,795
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.
 

moinmoin

Diamond Member
Jun 1, 2017
4,952
7,663
136
Ah k, I must have gotten the wrong end of the stick with the govmt funding part.
Not necessarily, the DIR-V (Digital India RISC-V) program seems to support both SHAKTI and Vega and push their commercial use (notably involving Sony's India branch).

In the same pursuit, the DIR-V program has announced five memorandums of understanding (MoUs) for the use of indigenously developed RISC-V Processors Shakti and Vega. They include:

  • MoU between SONY India and DIR-V SHAKTI Processor (IIT Madras) for the systems/products developed by SONY.
  • MoU between ISRO Inertial Systems Unit (IISU), Thiruvananthapuram, and DIR-V SHAKTI Processor (IIT Madras) for the development of high-performance SoCs (System on Chip) and Fault-Tolerant Computer Systems.
  • MoU between Indira Gandhi Centre for Atomic Research (IGCAR), Department of Atomic Energy, and DIR-V SHAKTI Processor (IIT Madras) for the systems/products developed by IGCAR.
  • MoU between Bharat Electronics Limited (BEL) and DIR-V VEGA Processor (C-DAC) for Rudra server board, cyber security, and language solutions.
  • MoU between Centre for Development of Telematics (C-DOT) and DIR-V VEGA Processor (C-DAC) for the 4G/5G, broadband, IoT.

Definitely a promising approach and development. I'm not aware of similarly aggressive government pushes in other countries.
 
  • Wow
Reactions: soresu

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
Definitely a promising approach and development. I'm not aware of similarly aggressive government pushes in other countries.
Yeah I've noted their progress from years ago and it is pretty stellar.

They seem to be willing to go quite experimental in terms of feature set too vs the more standard faster, faster, faster approach of other RV efforts.
 

BorisTheBlade82

Senior member
May 1, 2020
664
1,014
106
From a Hardware point of view this sounds mightily impressive:
  • 8-wide, 3.6Ghz, 16c Clusters, 48 MByte shared L3, 5nm, 62mm2
  • D2D interface with twice as much bandwidth as AMD IFoP, 2ns latency, <0.5pJ/bit, rather cheap compared to EMIB (comparable to InFO-R)
  • They sell the CPU chiplets standalone
  • Customers can design custom IODs from standardized building blocks
  • Fast time to market, highly customisable
They claim to beat Sapphire Rapids and EPYC Genoa in certain workloads.

 

eek2121

Platinum Member
Aug 2, 2005
2,930
4,026
136
I recently received my StarFive VisionFive 2 and I am absolutely impressed.

Don't get me wrong, software support is poor (they are mostly waiting on patches to get accepted and for the GPU guys to drop a decent driver stack) and drivers are in shambles, but despite benchmarks, certain tasks that the Pi 4 lagged a (for me, development oriented ones), the new board had no issues dealing with. I know the CPU isn't supposed to be faster than the one in the pi 4, but you can definitely feel a bit of snappiness that the Pi 4 does not have.

Both my Pi 4 and my VF2 have the same amount of RAM (8 GB). Both were running off the same brand/make/model/size of SD card. The VF2 had an NVME drive installed, but I haven't yet used it.

I suspect that we are coming close to a bit of a revival when it comes to new/unique entrants in the computing market, and I hope at least some of those expand into client computing.
 

DisEnchantment

Golden Member
Mar 3, 2017
1,605
5,795
136
A bit old, but Android will treat RISC-V as tier-1 architecture alongside arm64 and x64.

1677444973468.png

Also first commits for getting official support for dotnet on RISC-V are landing.

In 2018 we were asking MS folks to get some support for dotnet on arm64, where we run some automation tests on our arm64 systems using multi arch SW. 3 years later things got on par with x64 feature set.
Let's see how fast it takes for RISC-V, given that crossgen is already good on arm64 it should be much faster this time.
 

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
Also first commits for getting official support for dotnet on RISC-V are landing.
In 2018 we were asking MS folks to get some support for dotnet on arm64, where we run some automation tests on our arm64 systems using multi arch SW. 3 years later things got on par with x64 feature set.
Let's see how fast it takes for RISC-V, given that crossgen is already good on arm64 it should be much faster this time.
Something to bare in mind, that initial commit is from a Samsung engineer so it's likely more related to Samsung's internal RISC-V plans and their dotNET based software infrastructure.
 

DisEnchantment

Golden Member
Mar 3, 2017
1,605
5,795
136
Something to bare in mind, that initial commit is from a Samsung engineer so it's likely more related to Samsung's internal RISC-V plans and their dotNET based software infrastructure.
1677492396312.png

They are already accepting the contribs, and there are releases attached to the arch-riscv tagged items already. There is a merge to the runtime to enable running hello world app on dotnet.
So I see this is something they already willing to integrate.
 

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
They are already accepting the contribs, and there are releases attached to the arch-riscv tagged items already. There is a merge to the runtime to enable running hello world app on dotnet.
So I see this is something they already willing to integrate.
Wasn't implying otherwise, just to labor the point that Samsung seems to be at the very least laying the groundwork for possibilities, if not straight up working toward a future RISC-V ecosystem roadmap for their own purposes.
 

coercitiv

Diamond Member
Jan 24, 2014
6,203
11,909
136
A quick keynote from SiFive. Ironically they say ARM is at a disadvantage against RISC-V due to...having to support legacy software. They claim to have better compute density and/or performance over competing ARM solutions.

 

moinmoin

Diamond Member
Jun 1, 2017
4,952
7,663
136
Ironically they say ARM is at a disadvantage against RISC-V due to...having to support legacy software.
While that does sound somewhat ridiculous, it's also a neat point to empathize the openness: Closed ISA do have to be all inclusive regarding backward compatibility, whereas an open ISA like RISC-V theoretically could be optimized to the OS and software used, e.g. Android with a specific runtime that doesn't require the full ISA, and no assembly coding allowed beyond the adapted OS.
 
  • Like
Reactions: Tlh97 and coercitiv

Exist50

Platinum Member
Aug 18, 2016
2,445
3,043
136
A quick keynote from SiFive. Ironically they say ARM is at a disadvantage against RISC-V due to...having to support legacy software. They claim to have better compute density and/or performance over competing ARM solutions.

I mean, they're not wrong in that legacy support slows down IP development...but it's also a powerful purchasing incentive, and one way or another the RISC-V vendors will have to contend with it eventually.
 
  • Like
Reactions: Ajay

A///

Diamond Member
Feb 24, 2017
4,352
3,154
136
I mean, they're not wrong in that legacy support slows down IP development...but it's also a powerful purchasing incentive, and one way or another the RISC-V vendors will have to contend with it eventually.
It isn't just legacy slowing down development. Integration and general performance slows down. Not completely related but this is why Windows 11 locks out so many older processors. There's a new article on Windows 12 you should read if you're curious how M$ are positioning themselves to improve Windows going forward.
 

A///

Diamond Member
Feb 24, 2017
4,352
3,154
136
its on the homepage of windows central, greg. if true it explains everything including microsoft rebuilding basic functions they took out but idk why unless they were calling for legacy apis that were removed. it should go rtm sometime next june to august. it talks a lot of built in ai but I don't believe that is correct. what i do believe is future windows will include the necessary code to run some of the ai modules being designed nto intel and amd processors beginning with 14/5th gen and zen 5. ai and hardware accelarators for the masses on chip are following apple's lead. Tiger lake h has some ai ip that helps it boost performance in certain software. That was intel's version of sprinkling pumpkin spice on their lattes aka computers to entice consumers. sadly intel spent most of their marketing money on tiger lake demonstrating their competitor amd and helping amd sales. see the video that puffy haired heavy set youtuber whose hair is reminscent of 80s troll doll toys for the complete breakdown.
 
Last edited:
Jul 27, 2020
16,325
10,337
106
So the big thing is the separate possibly hidden partition for windows updates and OS files while also maintaining some sort of virtualization scheme to make legacy apps see a virtual shared state partition for the sake of backwards compatibility.

Here's what I predict: more headaches for power users like us and dumbing down of the OS for the typical user (maybe a good thing).
 

A///

Diamond Member
Feb 24, 2017
4,352
3,154
136
No not remotely close. Updates will be faster due to them heading to a specific partition in the background. critical system files will be read only. It's adopting a varied hybrid between osx and linux. A litle bit of a and b. The virtualization layer is only for legacy software that won't function with the new os design. I expect this number to be less than 5% of software due. No software needs write access to system files unless the app relies on installing system hooks like tera copy or advanced deleting software or writing your own system hooks to integrate features. 7zup, windzup and rar are other examples of system hooks but they don't need access to system files and won't need virtualization.
 

Nothingness

Platinum Member
Jul 3, 2013
2,418
748
136
That Arm legacy is the typical stupidity RISC-V marketing droids spit. Legacy is a good thing to have as it means you have an existing software base. And beyond that, Arm has already broken compatibility in the past. ARMv8 is not fully backward compatible with all previous ARM ISA. And latest Arm CPUs are dropping 32-bit support.

Of course Arm will not move as fast as an open ISA, but I have already been through hell with MIPS lack of compatibility between various CPUs and lack of tools (PS2 R5900i) and don’t want to live that again (it seems some RISC-V players such as Andes are doing this right and cooperate with mainstream, fingers crossed :)). So yes legacy can be a good thing as you have to take a minimum care of your past. Saying otherwise just means you have no software.
 

coercitiv

Diamond Member
Jan 24, 2014
6,203
11,909
136
Tenstorrent loves RISC-V and they had a few babies. We already knew some of this from one of Jim Keller's interviews, but now we get to see it crystalized in marketing slides. The IP is supposed to be used inside their AI chips, but apparently they're also making it available for clients as standalone options.


Since Tenstorrent is looking forward and addressing AI applications at large, it needs not only different system-on-chips or system-in-packages but also various CPU microarchitecture implementations and system-level architectures to hit diverse power and performance goals. This is exactly the department of Wei-Han Lien.

A humble consumer electronics SoC and a mighty server processor have little in common but can share the same ISA and microarchitecture (albeit implemented differently). This is where Lien's team comes in. Tenstorrent says that the CPU crew has developed an out-of-order RISC-V microarchitecture and implemented it in five different ways to address a variety of applications.

Tenstorrent now has five different RISC-V CPU core IPs — with two-wide, three-wide, four-wide, six-wide, and eight-wide decoding — to use in its own processors or license to interested parties. For those potential customers who need a very basic CPU, the company can offer small cores with two-wide execution, but for those who need higher performance for edge, client PCs, and high-performance computing, it has six-wide Alastor and eight-wide Ascalon cores.

Each out-of-order Ascalon (RV64ACDHFMV) core with eight-wide decode has six ALUs, two FPUs, and two 256-bit vector units, making it quite beefy. Considering that modern x86 designs use four-wide (Zen 4) or six-wide (Golden Cove) decoders, we are looking at a very capable core.

1680198317164.png
1680198409798.png
 

Mopetar

Diamond Member
Jan 31, 2011
7,837
5,992
136
Unless they're going to put their AI instructions into the standard, this really isn't that big for RISC-V. The exciting part about the AI cores is what they can do and add.

RISC-V is just an inexpensive way for them to produce a product they can sell more easily in a mass market manner or avoid the ugliness of trying to figure out how their product integrates with existing servers/workstations.

If you're doing heavy AI work you don't need a particularly impressive CPU. It's just their to manage everything and RISC-V doesn't cost anything to license and is designed to make a basic implementation pretty simple.

It's great that companies can use it to make products we might not otherwise see, but it's even better if they contribute back by working to create new extensions to the ISA that are open for everyone else to use just as freely.
 

serpretetsky

Senior member
Jan 7, 2012
642
26
101
Unless they're going to put their AI instructions into the standard, this really isn't that big for RISC-V. The exciting part about the AI cores is what they can do and add.

RISC-V is just an inexpensive way for them to produce a product they can sell more easily in a mass market manner or avoid the ugliness of trying to figure out how their product integrates with existing servers/workstations.

If you're doing heavy AI work you don't need a particularly impressive CPU. It's just their to manage everything and RISC-V doesn't cost anything to license and is designed to make a basic implementation pretty simple.

It's great that companies can use it to make products we might not otherwise see, but it's even better if they contribute back by working to create new extensions to the ISA that are open for everyone else to use just as freely.
I'd agree that this isn't exciting for people that want AI open source hardware/solutions now or even near future.

However I'd argue that a big thing for any new ISA is for more and more companies to use it (regardless if its for AI, or just some dumb embedded FSM control). More people use it, means more people are comfortable with it, means engineers will use it more in future products, means the cores using RISCV will become more and more optimized, and more varieties of cores will appear to fill different applications (some paid, some free,).

Adding a particular extension back to the ISA might be good, or might have no benefit for anybody, depending if anyone uses it. But I agree that the fact that RISCV has provisioned for custom instructions is great, and if there is a library of custom instructions (and hopefully open source implementations for those instructions!) that would be great.

However I'd also point out that it might not be that big of a deal either, since people are always free to add their own IP of their choosing and connect to their CPU of choice using any bus they want (AXI, wishbone, etc). Ofcourse there are latency benefits to having custom instructions that are closely integrated to the core cpu (and maybe other benefits too? not a CPU arch expert...)
 
  • Like
Reactions: Mopetar