Why AI Accelerators Choose RISC‑V

Every AI accelerator starts with an architecture decision — and increasingly, that decision leads to RISC‑V. Not because it’s fashionable, but because the economics and the engineering point the same way. These are arguments VRULL has been making in the open — at the AI Summit London in April and RISC‑V Summit EU Munich in June, our Chief Technologist Philipp Tomsich laid out the structural case for RISC‑V as the foundation for AI silicon. The reasoning has only sharpened since.

The freedom to customise — without leaving the ecosystem

Start with a comparison that lands differently with an AI audience than a general hardware one. With x86, your architectural choice is AMD or Intel. With Arm, you can take a core licence or an architecture licence. With either, you cannot freely add domain-specific acceleration — the ISA is what it is.

With RISC‑V, that constraint doesn’t exist. You can build a core optimised for transformers, or CNNs, or spiking neural networks, each with exactly the extensions that workload requires and none that it doesn’t. The base ISA is the common foundation; everything above it is your choice.

What makes this practically useful — rather than just architecturally elegant — is that the customisation doesn’t require leaving the ecosystem behind. Compiler support, Linux, toolchains, profiling infrastructure: all available from day one, before you’ve added a single custom instruction. The RISC‑V profile system reinforces this by bundling ratified extensions into defined, targetable feature sets. The software stack above your chip adapts cleanly to differentiated implementations without per-chip bespoke work.

Freedom at the hardware level. Without fragmenting the software layer above it.

The economics of building on a shared base

That combination — a shared ecosystem base plus the freedom to differentiate — drives the economics argument. The specific numbers vary by project, but the structure is consistent: the overwhelming share of what you need to build a competitive AI accelerator already sits in the RISC‑V ecosystem. You pick up the base ISA, compiler support, and the cores you need off the shelf. Then you add the one to ten percent that is genuinely yours — a custom matrix unit, a domain-specific instruction, a specialised memory interface — and the result is a fully customised, AI-optimised product built on a foundation you didn’t have to build yourself.

You’re not reinventing the compiler. You’re spending your engineering budget on the part of the chip that actually creates competitive advantage.

Why this matters especially for AI

The economic argument has particular force in AI because of something specific to the domain: AI and ML are software-defined in a way that most other compute workloads are not. Nobody writes an AI solution in assembly. The entire stack operates through frameworks — TensorFlow, ONNX, IREE, OpenXLA — that distribute intermediate representations and bind to hardware late, at runtime. The algorithm, the model, the weights: all mediated by software abstractions sitting well above the ISA.

The consequence is that AI is not constrained by binary compatibility the way a server OS environment is. It’s driven by cost and performance metrics and runs through frameworks that can retarget to new hardware without recompiling the application. More importantly, the algorithms themselves move faster than silicon. Transformers were first published in 2017 — seven years from a research paper to the dominant architecture for large language models in broad deployment. Nobody designing hardware in 2017 was optimising for transformers.

An architecture that can be extended to match software’s evolving demands, rather than one that locks in assumptions about workloads that haven’t been invented yet, is structurally better suited to that pace. RISC‑V is that architecture.

Open standards, open reasoning

The same logic applies to how the standards themselves should be developed. With any proprietary ISA, the reasoning behind past decisions is opaque — instructions exist in the form they do because of trade-offs made in meetings nobody outside the vendor attended.

RISC‑V does this differently. The process is open: companies bring their real application requirements — AI, DSP, HPC, embedded — and the trade-offs are made publicly, with the reasoning documented. The result is a standard that reflects what markets actually need, and one that future extensions can build on rather than work around.

Think global, act local. Pool resources on the shared interoperability specifications. Differentiate at the implementation layer.

Two paths to matrix compute

The two matrix extension efforts currently underway at RISC‑V International illustrate this approach in practice.

IME — the Integrated Matrix Extension — builds on top of the existing RISC‑V Vector Extension, reusing its register file and microarchitectural resources. It’s the evolutionary path: a matrix layer composing cleanly with what’s already field-proven, aimed at implementors with existing RVV investment. The tile geometry is algebraic rather than fixed, scaling with the hardware’s vector length, so a single design serves everything from embedded AI to HPC.

AME — the Attached Matrix Extension — takes a different approach entirely: a self-contained, orthogonal execution unit with no dependency on the vector registers, designed for maximum performance and minimum footprint across the full range from IoT to data-centre AI, and intended as the foundation for future tensor operations.

Rather than forcing a compromise between these two design philosophies, RISC‑V supports both — unified above by a common software abstraction layer through LLVM and MLIR, so the developer ecosystem doesn’t fragment even as the hardware implementations diverge. The goal is a path that can grow with the algorithms, rather than one that locks in today’s assumptions about what AI compute looks like.

VRULL is actively involved in shaping both specifications — Philipp serves as Vice-Chair of both the Technical Steering Committee and the AME Task Group, and VRULL’s engineers participate in the IME Task Group while building the compiler and toolchain implementations that validate every design decision against real workloads. Standards work and engineering work, inseparable.

The architecture decision

Building AI silicon is expensive. The architecture you build on determines how much of that expense goes toward shared infrastructure you didn’t have to create and how much goes toward the differentiation that actually matters to your customers. RISC‑V makes that split more favourable than any alternative — and the open standards process ensures the shared foundation evolves with the workloads, not behind them.

The companies that understand this are already building. The ones shaping the standards are building the fastest — because they’re not waiting for the architecture to catch up with their requirements. They’re writing it.