RISC‑V Is AI‑Native.

A couple of months back, when I was chairing the RISC‑V AI Market Development Committee, with invaluable input from its members, we put together an article that makes the architectural case for RISC‑V as the foundation of next-generation AI compute. The global AI processor market sits at $261bn today and is projected to reach $385bn by 2030. The ISA is open, modular, and customisable in ways that closed architectures cannot match. The standards work — IME, VME, AME — is being done empirically, with real workload data, by engineers arguing their decisions in public. That case is real, and I stand behind it.

What I want to add here comes from a different vantage point — not the committee room, but the day-to-day work at VRULL, where the question we deal with isn’t whether RISC‑V has a compelling architecture, but what it actually takes to make that architecture usable in the real world.

A compelling architecture and a production-ready platform are two entirely different things. And the distance between them is where most of the honest work — and most of the honest conversation — still needs to happen.

The gap nobody wants to name

RISC‑V’s current adoption story is strongest where it has always been strongest: microcontrollers, small embedded cores, low-power sensor nodes. That’s not nothing — it’s a foundation. But the ambition the community is articulating — AI-native compute from edge to data centre, automotive to enterprise infrastructure — demands a different level of ecosystem maturity than exists today.

The challenge isn’t the ISA. It’s everything above it.

When a silicon company builds a RISC‑V-based AI chip and wants to sell it into a demanding vertical — automotive, industrial automation, enterprise AI infrastructure — the conversation very quickly stops being about the elegance of the instruction set and starts being about something else entirely. Does the toolchain meet the certification requirements? Is there validated middleware for this application domain? Is the compiler support upstreamed and stable, or does the customer’s engineering team have to carry that burden themselves? What does the support model look like in three years? Who is responsible when something breaks in production?

These are not edge cases. They are the standard questions that any serious procurement process asks, and right now, for most RISC‑V deployments in demanding verticals, the answers are incomplete. Not because the people working on it aren’t capable — they are — but because the ecosystem hasn’t yet concentrated the sustained, disciplined effort that mature software infrastructure requires.

What mature actually looks like

At VRULL, we work in mature ecosystems every day — ARM-based projects, enterprise-grade production environments, supply chains where the software stack has to meet requirements that are specific, documented, and non-negotiable. That work gives us a reference point. We know what it takes to deliver a toolchain that a serious integrator can actually bet on. We know what certified looks like, what supported means over a multi-year product lifecycle, and what the difference is between software that demos well and software that holds up under the conditions of a real deployment.

The bar is high. It should be high. The verticals RISC‑V is reaching for — automotive Tier 1s, industrial controls, enterprise AI infrastructure — are not forgiving environments. A toolchain that mostly works is not a toolchain a safety-critical system can depend on. Middleware that hasn’t been validated against real application requirements is not middleware an OEM will integrate. Framework support that exists in a branch somewhere, not yet upstreamed, is not support a product team can build a roadmap on.

This is not a criticism of the community’s ambition. It is a description of the work that ambition requires.

What the software ecosystem actually needs

Let me be specific, because specificity is what this conversation is missing.

RISC‑V needs toolchain completeness — not just compiler support for the base ISA, but full, upstreamed, maintained support for the extensions that matter to AI workloads. LLVM, GCC, and the runtime libraries need to support new RISC‑V AI extensions from day one, not as a follow-on project after silicon ships. The moment a chip comes back from the fab, the software stack should be ready. That requires sustained investment in upstream compiler work that happens in parallel with hardware development, not after it.

RISC‑V needs validated middleware for the verticals it wants to serve. Automotive has AUTOSAR. Industrial has its own certification frameworks. Enterprise infrastructure has its own procurement requirements. Each of these domains has existing software stacks that RISC‑V-based silicon needs to integrate with cleanly and certifiably. That integration work is not glamorous. It doesn’t get announced at summits. But it is what determines whether a chip gets designed in or passed over.

RISC‑V needs software partners who understand both the architecture and the application domain — who can sit between a silicon company and its target market and build the layer that makes the hardware usable. Not in a demo. In production. At scale. With a support model that gives the customer confidence over the lifetime of their product.

And RISC‑V needs silicon companies to engage that work early — not as an afterthought once the hardware is done, but as a co-development effort that runs in parallel with the chip itself. The hardware/software co-design model that RISC‑V’s open standards process enables is only valuable if it’s actually used. Too often, the software layer is treated as something that will figure itself out once the silicon is proven. It won’t. It needs to be built deliberately, by people who know what they’re doing, starting earlier than feels necessary.

Where VRULL fits

This is the work we do. Not as a peripheral activity, but as the core of what VRULL exists to contribute to the RISC‑V ecosystem.

Philipp’s work on the AME and IME specifications — alongside contributors from Akeana, Alibaba, IBM, Rivos, Tenstorrent, Ventana, and others — is part of it. That work ensures that the matrix extension standards being written today are grounded in real workload requirements, and that when they are ratified, the software infrastructure to support them is already being built. Standards work and engineering work, inseparable.

But beyond the specifications, VRULL’s role is to be the partner that silicon companies engage when they want their hardware to land in the real world. When a RISC‑V chip needs a production-ready software stack — toolchain, runtime, middleware integration, framework support — that’s the work we know how to do. We know how to do it because we’ve done it, in demanding environments, to the standards that serious customers require.

The RISC‑V ecosystem needs more of this kind of engagement. Not more architectural enthusiasm — there is plenty of that — but sustained, expert software investment that treats ecosystem readiness as a first-class deliverable, not a follow-on project.

The opportunity

None of this diminishes what RISC‑V has already achieved or where it is going. The architectural case is real. The community building it is serious. The standards process is producing work that will matter for decades. NVIDIA shipping over a billion RISC‑V cores in 2024, CUDA coming to the RVA23 profile, Red Hat Enterprise Linux running on RISC‑V hardware — these are not small signals.

But signals are not the destination. The destination is a platform that silicon companies can build on with confidence, that system integrators can adopt without heroic effort, and that end customers in demanding verticals can depend on. Getting there requires the community to direct as much energy toward the software stack as it has toward the ISA — and it requires silicon companies building on RISC‑V to treat software ecosystem development as a strategic investment, not an afterthought.

The architecture has earned the right to be taken seriously. The platform needs to earn it next. That work is available to be done, the expertise exists to do it, and the window to do it well is now.