RISC-V RVA23 Profile: A major milestone
25 comments
·April 22, 2025fidotron
rwmj
I'm not aware of any chips, even in development, that will genuinely have full RVA23 support. If you'll settle for "near enough" then my betting is we'll have SiFive P650/P670 hardware first (https://www.sifive.com/cores/performance-p650-670). There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in very end 2025 / early 2026. These are server-class parts so the development boards will not be cheap.
Some parts of RVA23 like a complete implementation of the vector sub-extensions, and hypervisor support, are pretty complex.[1]
If you just want RVA23 now (with poor performance) then qemu implements it. We found it's not very useful for software development, not just because it's slow, but also because it performs so differently from the real hardware, so you cannot, for example, optimize your vectorized code.
[1] I wrote a general article about RISC-V extensions last year: https://research.redhat.com/blog/article/risc-v-extensions-w...
pantalaimon
> There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in 2026. These are server-class parts so the development boards will not be cheap.
I can get a 3A6000 system for 400€ with decent (~Zen2) performance, are we talking more than that?
rwmj
[deleted - didn't realise you were talking about loongarch, see reply below]
acka
It is a sad day in history to see both a RISC-V-related acronym and NDA used in the same sentence. The term oxymoron barely cuts it IMO. I thought that RISC-V used to stand for open hardware and freedom, TIL.
rwmj
The RISC-V specs are all free to download and implement. Some (by no means all) implementations are proprietary. Red Hat (the company I work for) talks to all sorts of server vendors, x86, Arm, POWER, RISC-V all the time under NDA so we can find out what new products those vendors are developing before they are released, and have software ready in time. The software we write is all open sourced. This is nothing particular to do with RISC-V, and has nothing to do with the RISC-V ISA, nor with open sourcing of software.
boredatoms
Riscv is an open ISA specification, not implementation
Organizations are free to make closed and even secret implementations of it if they like
camel-cdr
My bets are on Tenstorrent Ascalon. They are currently taping out and planning to release a 8 core@2.25GHz devboard and laptop next year. The cores have an 8 wide decode/issue/dispatch and dual issue 256-bit RVV support. Their the scalar part of their scheduling model is already upstream in LLVM as tt-ascalon-d8.
See also: https://youtu.be/ttQtC1dQqwo
The only I can think of that may deliver earlier is Ventana with the Veyron V2, they plan to have chiplets in the first half of this year. I'm not sure if they are planning on releasing devboards though, as they target big servers. The cores have a 16 issue backend, with 5 512-bit RVV execution units (arithmetic,mask,permut,load,store) and a decode of up to 10 instructions per cycle.
See also: https://youtu.be/OPgjCjNhqKQ
Both of these claim to support full RVA23 and are high perf OoO cores.
jitl
After Chimera Linux’s pessimistic view on RISC-V application processors, I’m not holding my breath
https://chimera-linux.org/news/2025/03/dropping-riscv.html
Note they eventually received a donation of CPU time that allows them to continue RISC-V support but it’s still a grim situation.
galangalalgol
This release adds the cray style variable length vector instructions. Compiling with avx512 and running without it will crash, but this just uses whatever length the chip supports with the same instruction. Also means you don't have to wait on llvm to update every time they grow the vector size.
justahuman74
The link is pretty light on details, should this be replaced with the 'read more' link within
rwmj
Maybe link straight to the profile: https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/161547...
null
bagswatchesus
[dead]
benob
[flagged]
bjourne
I don't get why they decided to create all these very complicated extensions before even getting solid hardware for the base instruction set. RVV support is many, many years into the future and I bet many of its instructions will be micro coded since they aren't very useful for compilers anyway. Specifying standards for the future before you have working prototypes is very (ahaha) risky.
beej71
I can only speculate that the base was insufficient for high commercial traction.
The question we all want the answer to is what is the current most likely contender for a decent performance widely available implementation of this profile, and when is it due?