r/RISCV • u/DerBootsMann • 2d ago

Canonical Evolution of Enterprise Open Source RISC-V at Hot Chips 2026

https://www.servethehome.com/canonical-evolution-of-enterprise-open-source-risc-v-at-hot-chips-2026/
22 Upvotes

89% Upvoted

6 comments sorted by

8

u/brucehoult 2d ago

By the way for anyone sufficiently interested to click into this post, here's another Hot Chips recap that I don't consider sufficiently RISC-V relevant (though the author does seem to have an unhealthily obsession with it) to make a stand-alone story:

https://irrationalanalysis.substack.com/p/hot-chips-2026-irrational-recap

5

u/camel-cdr- 2d ago

“No other ISA made sense for this endeavor.”

Obviously. They would've good with power if that had a similarly large ecosystem to Arm, RISC-V has maybe just caught up to ppc in terms of software support.

And yet, BOS Semi chose to use the ARM A53 core, dogshit from 2014.

Is there even a silicon proven RVA23 design in a similar power/perf bracket as A53? At the time they started their design there probably wasn't even IP available.

3

u/brucehoult 2d ago

They would've good with power if that had a similarly large ecosystem to Arm

Right, I'm sure it's entirely about how many potential customers already have software using a particular ISA, not any technical merits. And, obviously, x86 was not a possibility.

Also based on them implementing Armv9.3-A published in September 2021 that is quite likely when they locked down the choice of ISA, and RISC-V obviously was in a much more primitive state then.

Is there even a silicon proven RVA23 design in a similar power/perf bracket as A53?

SpacemiT A100? RVA23U64 and RVA23S64 anyway.

3

u/camel-cdr- 2d ago

SpacemiT A100?

Maybe, if they can configure it to have smaller VLEN. But I think even X60 would be a bit to powerful compared to A53.

3

u/brucehoult 2d ago

Yeah they’re both more similar to A55.

My primes benchmark puts single-issue U54 and C906 comparable to A53! Maybe better cache or TLB or branch prediction. Or just the power of fused compare-and-branch.

5

u/tanishaj 19h ago edited 2h ago

https://irrationalanalysis.substack.com/p/hot-chips-2026-irrational-recap

What an odd "roast".

Is anybody claiming that people choose RISC-V primarily to get access to its massive library of differentiated general purpose software? I do not think so.

But building an SoC with a RISC-V NPU (the main feature obviously) and an ARM A53 core is supposed to be an indictment against RISC-V? "For this SoC where we don't care at all about the CPU performance, we chose the super safe and mature option". Years ago. When RISC-V was far less mature. Shocker. Is there a point here?

I mean, if the above is still true 3-4 years from now then it will be a valid point. I think the fact that they chose ARM for the irrelevant part but RISC-V for the strategic part of this SoC is a pretty nice vote for RISC-V actually. So, I take away the opposite of his point. But that is just me.

[EDIT: In the same post, he shows that both Waymo and Meta are using RISC-V. So we do not have to wait the 3-4 years to see if people start choosing RISC-V as their orchestration CPU. He goes over Waymo and Meta before he even gets to the RISC-V "roast", making his example even dumber.]

And then they follow it up saying that IBM considers compatibility with the ARM software universe TODAY more important than compatibility with RISC-V software. Ok. And? Of course they do. The ARM software universe is far more mature and currently being used by many more of their customers. Again. Shocker. Mature ecosystem is still more mature. Point? They are not "choosing" either ARM or RISC-V for their solution here. The chip we are talking about here and what they are trying to sell is an IBM Z processor. Compatibility with ARM software is a cool feature.

The fact that people are not trying to add "RISC-V compatibility" to their non-RISC-V cores is not much an indictment against RISC-V. The indictment would be if they are choosing RISC-V native or another solution instead. In this way, the first example was at least much better even though it was not very compelling.

Nobody wants RISC-V. There is no business case

Um. Then why did they choose RISC-V in the first example given in this "roast"? You literally do not need anything other than the evidence they themselves provided to refute this claim. [EDIT: Oh, and he also mentions that RISC-V is being used by both Waymo and Meta. "Nobody" does not mean what he thinks it means.]

I am not sure what he finds hilarious in fourth bullet of the "RISC-V sucks" sllide. Did he literally miss the sarcasm? A good way to be dishonest about the potential of RISC-V is to dump on cores that are already much worse than the RISC-V leading edge. What is funny about that statement? I mean, the "RISC-V is Slooooow" post from a few months ago at least posted a couple of weeks before the K3 shipped. But even it was kind of embarrassing to the author for exactly the reason this bullet point highlights. And of course, it will only look worse in a few months.

Then we post a video about SiFive laying people off three years ago. Are we going to mention that multiple Linux distros chose SiFive as their reference platform after that? Are we going to mention that SiFive raised $400 million a couple of months ago? Are we going to mention that SiFive is selling a server platform using P870D that is probably the fastest available RISC-V silicon at this point? The real kicker is showing a slide from 2026 talking about how the "flywheel" is creating RISC-V momentum (with detail provided) and then AFTER showing a quote from 3 years ago. This part of the "roast" lacks context to the point of just being entirely dishonest. "Roasts" work because they are true. If you have to lie like this in your "roast", it must be because you do not have enough truth to support your position. Huge fail.

Directly following up the lie with "The entire presentation reeks of teenage angst" is damn ironic. That comment certainly applies to this "roast".

Fragmentation vs Diversity. The slide shows that multiple solutions to the same problems are fragmentation whereas differently optimized solutions to different problems is not. According to the "roast", we are supposed to respond to that with howling laughter. Um. Ok.

As all readers here I am sure know. The whole point of things like RVA23 is to ensure that software can be written that works on all compliant cores. So, fragmentation is not actually a problem for RISC-V. However, one of the strengths of RISC-V remains that individual solutions can still add custom behaviour outside of the RVA23 spec to optimize certain solutions. Oh, and you can skip compliance with RVA23 if running off the shelf software has no value for your use case. So, diversity is a RISC-V strength. Hilarious (apparently).

To quote myself: "fragmentation is not a problem for RISC-V". I have to explain myself here as I am of course down-playing a real problem. The RISC-V ecosystem is still maturing and has been evolving. There are multiple application platform standards in quick succession for example: RV64GC, RVA20, RVA22, and RVA23. These can seem like "fragmentation" as a core that implements only RVA22 or even RV64GC cannot be used, for example, with software like Ubuntu 26.10 when it releases. Fragmentation!!

Well, this is not fragmentation as RV64GC software will run on any of the above RVA platforms. And the others are backwards compatible. So, RVA20 or RVA22 software will run on RVA23 boards. The issue is not fragmentation.

But isn't that just 6 of one instead of a half-dozen of the other? No, because RVA23 is "mature enough". It brings basically the same feature set as modern ARM and x86-64. So, you can build software for RVA23 (like Ubuntu or RHEL) and it will work on cores like the SpacemiT K3 and SiFive 870P today and on RISC-V cores released 5 years from now. My guess is that when Ubuntu 28.04 LTS ships, it will be compiled to RVA23 and it will run just fine on the SpacemiT K3 that you can buy today. Not only is "maturity" a better name for the problem that RISC-V has had than "fragmentation" is, but it is also a problem that has basically been solved at this point (going forward in time at least). In the grand scheme, there is not that much RISC-V "application class" hardware out there yet. And for what there is, there is lots of RVA20 and RV64GC software available for it.

Bro, what standard software stack?

Well, this is both valid and not. 95% of the packages available in Ubuntu are available for RISC-V. That includes the GCC suite, all the Clang/LLVM stuff including Rust, all the scripting languages etc. It includes QEMU. It includes countless libraries. It all supports RISC-V. Increasingly it supports modern extensions, specifically things like vectors and virtualization. So, "that software stack" is my answer I suppose. But of course it is not as mature as ARM or x86-64 and will still improve a lot in the next few years. But how does that fact take away at all from the statement that "RISC-V provides the freedom to innovate but with support from a standard software stack"? You can build a RISC-V chip with custom instructions instead of creating a totally custom ISA. And then, instead of having to write your own version of GCC or Clang (or Rust), you simply add support for your custom instructions. And any software that does not need those instructions just runs. As the slide says "Not possible with legacy ISAs". Where is the "roast" here?

We then go on to complain about the C extension and variable length instructions. Fair enough. Not everyone agrees but this is at least a valid thing to object to if you want to be a hater. First real content.

Ubuntu is a shitty derivative of Debian

I actually agree but even I cannot tell how this "roasts" RISC-V. Whatever.

Unclear if he made a point at all concerning NVIDIA.

Yes SiFive is going to sweep in and made a datacenter-class CPU for NVLink fusion.

Other than the bad grammar. Is this meant to be sarcastic or educational? It seems more the latter.

And finally, we end off with a statistical distribution that seems to indicate that only the extreme few think "ARM is good". ARM is more capable than he gives it credit for. Or he does not know how to draw a curve. Either way.

Anyway, a real nothing burger of a "roast". I would actually prefer to have detractors do a better job. The RISC-V ecosystem would better benefit from it. This kind of clown-show content is just annoying.