RISC-V's 2025 annual report: MCUs, AI acceleration and automotive ramp lead

RISC-V International published its RISC-V Annual Report 2025 in January 2026. The report documents the past year’s progress across the RISC-V ecosystem in written form; its value is not any single headline but the view it gives of where the ecosystem is focusing attention, and where it is still stuck. Note that this is an annual document published by the standards body itself, aligned with the RISC-V camp; read it as a roadmap rather than a scorecard.

The growth priorities it lists are embedded MCUs, AI acceleration and the upcoming standardised microcontroller (MCU) profile. On its public account, the ecosystem is moving from evaluation and pilot projects toward volume deployment in automotive and industrial settings. Together the three say one thing: RISC-V is turning “it runs” into “it ships” — the first earns it a seat in the discussion, the second decides whether orders follow. In other words, the report cares less about catching up on benchmarks than about getting onto somebody else’s bill of materials.

First, what RISC-V actually is

RISC-V is an open instruction set architecture. “Open” has two layers here: the specification is maintained publicly by a non-profit organisation for anyone to read, and anyone can implement, extend and ship a processor core based on it without paying a licence fee for the core itself. Commercial processor IP is usually licensed for a fee, with the tier deciding how much you can change and how much you pay — the original motivation for many chip companies weighing a change of architecture. Licence fees are only the book cost, though: moving architecture also means reworking toolchains, rebuilding documentation and retraining teams, which often costs more.

Three layers are worth separating: the instruction set is a contract defining which instructions a processor understands; the microarchitecture is the implementation that decides how fast and how efficiently those instructions run; and a profile sits in between, collapsing “which extensions are optional” into a predictable list. The same instruction set can have wildly different implementations, which is why “a RISC-V chip” is itself a vague phrase. For buyers and designers, asking which profile and which extensions a part implements is far more useful than asking whether it is RISC-V.

Open does not mean free, and certainly not simple. RISC-V lets vendors add their own extensions, which enables differentiation at the cost of fragmentation risk: if every vendor’s extensions differ, software has to be adapted to each combination and the value of a shared layer erodes. That is exactly why standardised profiles exist — they give software authors a promise that a chip claiming a profile really has everything on the list.

Why MCUs are the easiest way in

To see why MCUs top the list, look at the nature of the business. A single MCU is not worth much, but volumes are enormous, so any per-unit cost at any layer gets magnified; and MCUs are relatively forgiving about software ecosystems — no need to run a full operating system or cover a vast application library, as long as toolchains, real-time operating systems and key middleware are in place. Conversely, once the MCU layer falls, application processors above it often follow along the same toolchain — the deeper reason everyone contests this segment.

The forthcoming standardised MCU profile is therefore a key step. It makes “profile-compliant” a checkable line: chip vendors build to it, software vendors write to it, and the two sides no longer have to be matched one by one. For the ecosystem that is the turn from everyone doing their own thing toward interchangeability — and the precondition for RISC-V to move from hobbyist toy to supply-chain option.

AI acceleration and automotive: the harder directions

The second priority is AI acceleration. Edge inference workloads differ widely: one approach uses vector extensions to raise general compute, suiting scenarios with many operators and frequent iteration; another puts dedicated matrix accelerators on the die for higher efficiency at the cost of flexibility. Listing AI acceleration separately suggests the industry treats it as a piece RISC-V must fill in, not an optional extra.

Automotive and industrial are a harder threshold. The difficulty there is usually not compute but determinism: long certification cycles, long supply commitments, and software that must not drift between versions; a chip used on a production line for a decade needs toolchains and documentation that live just as long. When the ecosystem starts talking about volume deployment, those constraints are on the table rather than waved away with “the ecosystem is immature”.

The industry mood points the same way: at Embedded World 2026 the RISC-V narrative was likewise about moving from prototype to production, with automotive and industrial systems as the main battlefield. That corroborates the report’s tone — both emphasise deployment, not benchmark scores. For chip vendors that changes the pitch: customers no longer ask whether it runs but whether it ships on time and passes certification.

A few examples from 2026

Events in 2026 illustrate the shift. Espressif pushed RISC-V into a higher-performance application SoC (the ESP32-S31), showing it can move from low-power wireless into display-equipped HMI and edge AI; Raspberry Pi used the RP2350 to bring RISC-V into mainstream MCUs as one of two selectable cores, reaching education and hobbyist markets — evidence that being chosen is no longer unusual.

The other side is just as informative: STM32 stays on the Arm path. RISC-V’s pressure is not universal but starts in low-cost wireless and edge IoT, where products depend least on an existing software ecosystem, are most sensitive to cost and supply, and are quickest to accept a new toolchain. Conversely, the further up the stack and the thicker the software, the greater the resistance to migration.

As an annual document it offers direction rather than a scorecard: RISC-V has moved past “does it work” and is now solving “can it be produced in volume, can it pass automotive qualification”. The first advances on engineering enthusiasm; the second needs long-term documentation, certification and support — which is where the difficulty lies.

The answers will probably be clearer only in the next annual report. For developers, a more practical move is to watch the segment you actually work in: for low-cost connectivity and edge inference, RISC-V has gone from “worth a try” to “worth evaluating”; for scenarios needing a large software ecosystem or strict certification, waiting one or two generations is reasonable.