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.

 

[JoeRambo]

Risc-V doesn't have fixed length instructions. Instruction length can vary from 16 to 192 bits and more. Risc-v differs from x86 how different length instructions are encoded, Risc-V encoding is aligned to 16 bits and instructions have sane encoding where instruction boundaries can be found easily.

But the base RV32I set is still 32bit and that's what general purpose CPU would be executing most the time. Having 36 bytes ( less than 6x48 bit but more than 6x32bits ) of instruction fetch to align with some SIMD instruction width would only make sense if they were building something like Fujitsu A64FX. But they are not, it's general purpose CPU focused on integer perf and not FPU/SIMD throughput.

 

[naukkis]

. Having 36 bytes ( less than 6x48 bit but more than 6x32bits )

Check your math, 36 bytes is exactly 6*48bit.

 

[Tuna-Fish]

My best guess is that it's for short branches where if you have some simple switch cases, etc. pulling in up to 17 other instructions means you might have already fetched the next one you need before you realize you need it. If the decoder is well designed for something like that it could theoretically discard fetched instructions that it knows it won't execute and keep the backend better fed.

There could be other reasons as well. Even assuming mostly sequential code, fetching more at once means fewer cache accesses. That could theoretically improve performance or even reduce power use.

No, that's fetch for decode in one cycle, the second cycle gets it's own 36bytes.

It's for instruction fusion, because RISC-V addressing modes are so simple that a lot of what fits into a single load instruction in x86 or arm needs to first do an alu op and then a load. The CPU can do very aggressive instruction fusion in such cases, which reduces the amount of instructions that need to be tracked past that point, but requires a lot of fetch bandwidth.

 

[Mopetar]

That makes a lot of sense. The RISC-V instructions for loads/stores would only let you offset ~1,000 bytes from an address, so a lot of memory accesses would take 2 or 3 instructions instead of just one.

 

[NostaSeronx]

SG2380 which will be used in the Milk-V Oasis has been announced:

https://forum.sophgo.com/t/about-the-sg2380-oasis-category/359

It is very likely that the Milk-V Pioneer successor or whatever will also switch to SiFive's P670: https://sc23.supercomputing.org/presentation/?id=misc250&sess=sess455
"Base on the SG2042, Sophgo is soon to release the SG2044, which supports vector 1.0, and also a high-performance RISC-V CPU based on SiFive IP Core. These offerings will accelerate the adoption of RISC-V in high-performance computing, data centers, and AI/ML scenarios, with a focus on delivering high performance, low power consumption, and affordability, thereby contributing to the growth of the RISC-V HPC ecosystem."

 

[Nothingness]

SiFive firing people, doesn't look good.

 

[SarahKerrigan]

If Cutress is right about Sifive exiting the core IP market, this is a big deal. I'm both surprised and unsurprised - I can't imagine the higher-end P-class cores were cheap to develop, and I never saw any high-volume design wins for them.

Not the first core IP vendor to get too aggressive, too fast.

 

[soresu]

SiFive firing people, doesn't look good.

IMHO it could be the same problem with the ARM server market a few years back when everyone and their dog were churning out custom cores that no one wanted.

Then Neoverse rolls around and it slowly builds itself into the ecosystem that allows you to design whatever kind of datacenter or server chip you want with updated core µArch performance every few years in each market category.

That being said if ARM/SoftBank keep taking this litigation business too far they will poison the well for the ISA and then the RISC-V people will just come back in.

Tenstorrent has the right approach by spreading their RISC-V goals to both CPU and AI, so if one market fails they can fall back on the other, and I don't see AI interest just evaporating overnight so at least one of them will do for the time being until RISC-V CPU interest picks up steam, by which time they will still have a great core design.

 

[Tuna-Fish]

There is an another big shakeup happening right now in the ISA definition side. Qualcomm is openly talking about how they want to add their code size reduction instructions (pdf), which is basically all of ARM64 addressing that they can fit into the corners left free in the RISC-V encoding space, starting with the most critical parts, and then remove the C extension (variable-width instructions)(pdf).SiFive is strongly and philosophically opposed, and it's entirely possible that this will fragment the RISC-V ecosystem, because Qualcomm's opinion on the opposition seems to be that they are going to do it with support or without.

I personally find the Qualcomm's proposal to be just a significantly better path forward, because by ditching the C extension they make high-performance implementations cheaper, faster, less power-hungry and simpler, while liberating 3/4 of the entire encoding space for future extensions, especially as the 32-bit encoding space for RISC-V is currently very full. After that, they can add a few branches with longer displacement and more complicated conditions. This does ditch most of the things that make RISC-V distinctive from ARM64, and well, good riddance. ARM64 is a better design, but that's not because ARM64 designers worked miracles, but because the academic researchers who built RISC-V put some real stinkers in there for reasons no-one seems to understand.

 

[SarahKerrigan]

There is an another big shakeup happening right now in the ISA definition side. Qualcomm is openly talking about how they want to add their code size reduction instructions (pdf), which is basically all of ARM64 addressing that they can fit into the corners left free in the RISC-V encoding space, starting with the most critical parts, and then remove the C extension (variable-width instructions)(pdf).SiFive is strongly and philosophically opposed, and it's entirely possible that this will fragment the RISC-V ecosystem, because Qualcomm's opinion on the opposition seems to be that they are going to do it with support or without.

I personally find the Qualcomm's proposal to be just a significantly better path forward, because by ditching the C extension they make high-performance implementations cheaper, faster, less power-hungry and simpler, while liberating 3/4 of the entire encoding space for future extensions, especially as the 32-bit encoding space for RISC-V is currently very full. After that, they can add a few branches with longer displacement and more complicated conditions. This does ditch most of the things that make RISC-V distinctive from ARM64, and well, good riddance. ARM64 is a better design, but that's not because ARM64 designers worked miracles, but because the academic researchers who built RISC-V put some real stinkers in there for reasons no-one seems to understand.

I actually kind of like what's being proposed by Qualcomm there. I don't expect it to go anywhere standardization-wise, because this is the RISC-V ecosystem we're talking about, but it looks like a mostly sane approach to getting RV's dismal dynamic density down. (Nice alliteration, SarahKerrigan!) It's nice to see pre- and post-increment ops as those are a particularly painful omission in RV as-is.

The "just fuse it" brigade will, I'm sure, show up shortly to tell me how it doesn't matter. Meanwhile, the commercial ecosystem will keep doing what it's already doing - making vendor-specific solutions to fill in lacunae in the spec.

 

[DrMrLordX]

Tenstorrent has the right approach by spreading their RISC-V goals to both CPU and AI, so if one market fails they can fall back on the other, and I don't see AI interest just evaporating overnight so at least one of them will do for the time being until RISC-V CPU interest picks up steam, by which time they will still have a great core design.

Tenstorrent seems to be offering a complete product from top to bottom that should work with existing AI frameworks, meaning that the success or failure of RISC-V in other arenas has no bearing on their potential success.

 

[soresu]

Tenstorrent seems to be offering a complete product from top to bottom that should work with existing AI frameworks, meaning that the success or failure of RISC-V in other arenas has no bearing on their potential success.

Ye, with the possibility of offering a straight RISC-V CPU still open for the future should the markets shift in their favour.

 

[DrMrLordX]

Ye, with the possibility of offering a straight RISC-V CPU still open for the future should the markets shift in their favour.

It certainly wouldn't hurt. I just don't know how many people are going to be writing non-portable code for Tenstorrent products.

 

[moinmoin]

Through its embedded department (Xilinx) AMD is now offering the option of using RISC-V cores as in AMD MicroBlaze V (instead only custom Xilinx cores which was MicroBlaze so far) for FPGAs (so these are soft cores):

AMD MicroBlaze™ V Processor

www.xilinx.com

 

[NostaSeronx]

From last August (August 2023):

-Tenstorrent -

2x Big Core + 4x Small Core configuration. For "Mobile" solutions. (Like: PHX2/Z1.)

-Ventana-

Client(Laptops to Desktops) CPU+GPU+Wifi+IOD chiplet.

- StarFive -

"The JH8100 CPU does not support vector operation." - Dec, 2023 // Four A76 + two A75 cores w/o SIMD. Four A55's (JH7110) to Six >A75 cores (JH8100) should still be a big upgrade.

- Chinese RISC-V Alliance's Opensource/Copyleft High Performance core -

First-Second [+3], Second-Third [+5], Third-Fourth would basically need to be [+7] to keep the pattern. {Huawei, Tencent, Zhaoxin, plus more are part of the CRVA thus have access to this core's patent pool} Innosilicon is likely to be the first to use Xiangshan v3 paired with Fenghua v3.

~~~~~~ August 2023 to Now:
First Gen client devices: Mid-2024+ and be only missing a few somewhat important extensions. (Like: ARMv8.0)
Second Gen client devices: Mid-2025+ and will not be missing any important extensions. (Like: ARMv8.2)

 

[soresu]

From last August (August 2023):

-Tenstorrent -
View attachment 94543
2x Big Core + 4x Small Core configuration. For "Mobile" solutions. (Like: PHX2/Z1.)

-Ventana-
View attachment 94544
Client(Laptops to Desktops) CPU+GPU+Wifi+IOD chiplet.

- StarFive -
View attachment 94547
"The JH8100 CPU does not support vector operation." - Dec, 2023 // Four A76 + two A75 cores w/o SIMD. Four A55's (JH7110) to Six >A75 cores (JH8100) should still be a big upgrade.

- Chinese RISC-V Alliance's Opensource/Copyleft High Performance core -
View attachment 94549
First-Second [+3], Second-Third [+5], Third-Fourth would basically need to be [+7] to keep the pattern. {Huawei, Tencent, Zhaoxin, plus more are part of the CRVA thus have access to this core's patent pool} Innosilicon is likely to be the first to use Xiangshan v3 paired with Fenghua v3.

~~~~~~ August 2023 to Now:
First Gen client devices: Mid-2024+ and be only missing a few somewhat important extensions. (Like: ARMv8.0)
Second Gen client devices: Mid-2025+ and will not be missing any important extensions. (Like: ARMv8.2)

It might be worth pumping on the enthusiasm brakes until we know who is fabbing what out of all this, especially given we know that the 5nm capacity China has is going to be capped in perpetuity it seems with the US govmt strongarming Dutch gov/ASML into stopping all sales of even the older DUV litho equipment.

 

[NostaSeronx]

It might be worth pumping on the enthusiasm brakes until we know who is fabbing what out of all this, especially given we know that the 5nm capacity China has is going to be capped in perpetuity it seems with the US govmt strongarming Dutch gov/ASML into stopping all sales of even the older DUV litho equipment.

Tenstorrent(NotCN) is likely to be on Samsung's SF4X. They haven't announced any GPU partners yet.
Ventana(NotCN) is likely to be on TSMC's N3 or N4 :: [“We are seeing strong customer interest to adopt RISC-V in Client and Automotive applications. Our partnership with Imagination enables us to address these needs with complete platform solutions consisting of best-in-class Veyron CPUs from Ventana and market leading GPUs from Imagination,” said Balaji Baktha, Founder and CEO of Ventana.] Which is the two designs above.

Most of the designs for CN cores happen to be TSMC 12nm for mass production. As well as simply licensing the IP to foreign companies for worldwide. As the XiangShan core permits as-is duplication/no modification in regards to Xiangshan's patents. Modification of Xiangshan is not protected thus if not in the patent pool, nuked.
"Further, it draws lots of attention and is under support of domestic and foreign companies, in which 16 companies collaboratively develop under the foundation of Xiangshan." <-- they haven't listed the foreign companies. Ten companies are CN-based, the other 6 are unknown.

"Customers can leverage the platform to develop their high-performance SoCs in a fast and efficient way. By making the platform accessible to global developers, we hope to contribute to the RISC-V community, enabling more customised RISC-V based SoCs tailored for different applications." - T-Head. These cores allow modification, but also has a nuke clause.

If this works, we will probably see RISC-V with CN cores at Intel Foundry Services.

 

[Nothingness]

CPU from China. What could go wrong?

 

[NostaSeronx]

CPU from China. What could go wrong?

Nothing. The CPU would be manufactured in North America for the Non-GC market. If Intel/Samsung/GlobalFoundries is inserting "chip in the middle" attacks in their masks. It would be a massive breach of trust.

Why would a royalty-free core be used if that customer base would be using Akeana/Rivos/Ventana/SiFive in position=0 or Tenstorrent/Andes in position=1.

The orientation of thought is game consoles, it is always games. If it is going west it is going to be games. Reduce the cost from an ARM64/AMD64 or an expensive Andes(AX67)/SiFive(P870) core for a lower cost/no cost CN core.
CPU: >4 XiangShan Kuminghu cores
GPU: IMG DXT-48-1536
Process Node: Intel 3 or 18A
Company: US HQ'd

Lower cost HW => Fast ROI
Addition to GaaS => Faster ROI
etc.

 

[DrMrLordX]

It might be worth pumping on the enthusiasm brakes until we know who is fabbing what out of all this, especially given we know that the 5nm capacity China has is going to be capped in perpetuity it seems with the US govmt strongarming Dutch gov/ASML into stopping all sales of even the older DUV litho equipment.

No sane business is going to send any more of their sensistive gear to the PRC than is absolutely necessary. It's just good for business not to get your equipment constantly torn down and reverse-engineered, only to be knocked off years later. Even if ASML didn't have Uncle Sam breathing down their necks, it would be . . . a very difficult decision to make, as to what to sell there.

 

[gdansk]

It might be worth pumping on the enthusiasm brakes until we know who is fabbing what out of all this, especially given we know that the 5nm capacity China has is going to be capped in perpetuity it seems with the US govmt strongarming Dutch gov/ASML into stopping all sales of even the older DUV litho equipment.

Strong-arming? All their EUV light sources are from ex-Cymer in San Diego. If they didn't want to be beholden to US export restrictions then they shouldn't buy US companies.

 

[soresu]

No sane business is going to send any more of their sensistive gear to the PRC than is absolutely necessary. It's just good for business not to get your equipment constantly torn down and reverse-engineered, only to be knocked off years later. Even if ASML didn't have Uncle Sam breathing down their necks, it would be . . . a very difficult decision to make, as to what to sell there.

DUV is older gear, problems solved and in mass production long before EUV was even close to production ready, let alone the high numerical aperture EUV machines that ASML are about to shift to producing at the cutting edge.

ASML were plenty fine with selling DUV equipment to SMIC until the US govmt stuck their oar into the issue again - probably because the Chinese managed to find a way to use older DUV machines to reach smaller geometries that are less than the 2 generations behind that the US govmt prefers Chinese semicon tech to be limited to domestically.

In reality though cutting off ASML DUV sales effectively puts them significantly more than 2 gens behind TSMC, Intel and Samsung - they are basically being penalised because they macguyvered more value out of the litho hardware they bought from ASML.

IMHO this seems like a very risky strategy (for ASML) as it will just prompt the Chinese to put more money into reverse engineering what they already have - and once they have that cracked they can just mass produce and sell them across the world to smaller fabs, thus even further cutting into ASML's bottom line and the Dutch economy.

 

[soresu]

Strong-arming? All their EUV light sources are from ex-Cymer in San Diego. If they didn't want to be beholden to US export restrictions then they shouldn't buy US companies.

I didn't say EUV.

 

[gdansk]

I didn't say EUV.

And for the other half there's Wilton.
ASML has thoroughly embedded itself in the US.

 

[soresu]

And for the other half there's Wilton.
The federals don't have to touch the Dutch because ASML has thoroughly embedded itself in the US.

So all the UV light sources that ASML litho machines use are manufactured in the US?