It's worse than that -- there is not a single piece of hardware that implements RVA23 available to be bought on the market today.

There are SoCs on the market that implement RVV (Vector extensions), and SoCs on the market that implement H (Hypervisor extensions).

There are no SoCs on the market that implement both at the same time. And both are mandatory for RVA23.

I'd love to be proven wrong on the hardware availability. If there's hardware to be bought in western countries that implements both RVV and H, please let me know.

>Still, no consumer based RV23 mini-ITX or micro-ATX or ATX form factor devices.

Sure. But there are RVA22+V such devices. RVA23 will eventually succeed these.

Many IP vendors announced RVA23 cores, but understand that the process from having a core design available for licensing to having a chip is very long, measured in years.

Among the designs that are further down in the pipeline of development, a highlight is Tenstorrent's Ascalon. According to them, a tapeout is "imminent". This was in the RISC-V Summit EU a few weeks ago. That'd mean RVA23 chips competitive with Zen5 in early 2026.

Seems unlikely.

>Does this line up with what riscv android will also require?

AIUI both Google and Microsoft selected RVA23 as baseline.

> RVA23 is actually a decent ISA for linux machines for the long term, RVA20 was not.

This is setting it all up to happen again with whatever is found to be wrong with RVA23.

> that Ubuntu has early knowledge of.

They aren’t big enough to get advance notice of hardware from any serious SoC makers. So I bet not.

Rva20 lacks vector support and hypervisor instructions, among other things.

You’re welcome to put a ton of effort in for dogshit performance on a bunch or $35 SBCs but the rest of us will just upgrade

And don’t worry, some vendor won’t come in and magically save you - fedora is eyeing rv22 as their baseline.

The profile includes not just additional instructions but also architectural requirements that can't be emulated. The size of cache lines and reservation sets must be 64 bytes (there is no instruction to query it, like there is on ARM). Data-independent execution latency is important for protecting cryptography against timing attacks.

Those were already in RVA22, and the difference from that to RVA23 could probably be emulated with traps though.

However, I think that some of the new instructions in RVA23 may potentially become very common in some binaries later on and could possibly trap so often that they would slow down those programs considerably.

The original two generations of iPhone were armv6 with hardware floating point, so that always felt to me like the sane baseline. Android wasn't using hardware floating point on armv6, but I think that was only because the compilers they had sucked (an issue that didn't apply to Apple), and many/most of the devices in fact shipped with the same hardware. I dunno... like, I don't know exactly what went into Debian's decision there, but I could see it having been made for the wrong reasons: looking at what software had been deployed rather than what hardware was common?