Table of Contents
Why matrix, and why it is late
RISC-V ratified a vector extension (RVV) in 2021. Vectors handle element-wise work well, but the dominant operation in neural inference is the outer product of two tiles, and doing that with vector instructions costs register pressure and accumulator traffic. A matrix extension folds the outer product into one instruction with a dedicated accumulator.
RISC-V deliberately did not standardise one matrix extension. At Summit Europe 2025 in Paris the effort was restructured into a family.
The three tracks, plus one
- VME — Vector Matrix Extension (spec name reported as Zvopmm). Matrix elements live in and execute against the vector registers; built around outer products with an independent matrix accumulator.
- IME — Integrated Matrix Extension. Matrix state integrated with the vector unit rather than standing alone.
- AME — Attached Matrix Extension. A more independent engine with its own register file and encoding.
- A fast-track vector-based option also exists, alongside the three.
The split exists because RISC-V spans 32-bit microcontrollers to datacenter parts. One extension sized for the top of that range does not fit the bottom, and forcing a single answer would produce the fragmentation the profiles work was meant to end.
VME: the one with a schedule
VME is the furthest along. Its published ratification plan, as relayed by the Shanghai Jiao Tong University ISC RISC-V group's technical digest, sets these dates:
| Milestone | Date |
|---|---|
| Specification freeze | 2026-09-25 |
| Public review opens | 2026-10-09 |
| TSC approval | 2026-11-04 |
| Board of Directors approval | 2026-11-18 |
The Unprivileged ISA Committee ran a ratification-plan approval vote through OpaVote in July 2026, closing 2026-07-31.
The action item: freeze is 18 days out from publication of this draft. If your workloads depend on matrix instruction semantics, the window to get comments in is the public review starting 2026-10-09, not after.
IME and VME are converging, not competing
A Summit Europe 2026 talk by Philipp Tomsich (VRULL; chair of the RISC-V Applications & Tools Committee, RISC-V board member, vice-chair of the TSC, and principal editor of IME) reports that IME and VME are converging on specification freeze. The architectural decisions named: algebraic tile geometry that scales with VLEN, so one instruction shape works across different vector widths; deliberate reuse of RVV state, so software needs no parallel register-file abstraction; and dedicated accumulator registers where implementations need higher computational intensity.
The talk also states that work is starting to unify IME and VME through a common LLVM/MLIR lowering path, giving compilers and AI/ML frameworks one abstraction targeting both. That is the most consequential item here: two matrix extensions with one compiler path do not fragment the software stack. Two with separate paths do.
AME is the one still under review pressure
In July 2026, Krste Asanović raised two objections to the AME ratification plan: Spike support was not listed in the simulator section, and no hardware proof-of-concept was listed. On the second, his position is that a credible entity should indicate it has built something similar — even for a different ISA — to show the extension is efficiently implementable; the implementation itself can stay private. Thomas Gall added that Spike support also matters for certification, which wants test suites checked against as many simulators as possible. The plan was updated 2026-07-28 to add both.
Read that as a process signal, not a blocker: an extension adding a large independent register file is a bigger silicon commitment than one reusing vector state, and the committee wants evidence before the spec becomes immutable.
What this means if you are picking silicon today
Nothing here ships yet. No ratified matrix extension means no portable matrix intrinsics, so any matrix-accelerated RISC-V part you buy today uses a vendor extension with vendor toolchain support — defensible for a fixed-function product, poor if you need to move the codebase. The dates to plan against are the VME freeze (2026-09-25), public review (2026-10-09), and BoD approval (2026-11-18).
What is not disclosed
- Concrete VLEN, MLEN or tile-geometry parameters for VME, IME or AME — no ratified values exist yet.
- Any measured TOPS/W or speedup for any of the three. Instruction-count comparisons in third-party explainers are arithmetic, not a measurement.
- Which silicon vendors have committed to VME, IME or AME, and in which process nodes.
- Availability dates for compilers, intrinsics headers or framework backends.
- Whether IME and VME merge or stay separate with a shared lowering path. The Summit material says unification work is starting; it commits to no outcome.
Sources
- RISC-V Summit Europe 2026 session, "Matrix Extensions for RISC-V: Delivering on the Promise" (Philipp Tomsich) — https://cfp.riscv-europe.org/eu-summit-2026/talk/BLF3DX
- RISC-V tech-unprivileged list, VME ratification plan approval vote — https://lists.riscv.org/g/tech-unprivileged/topic/vote_unprivileged_ic/120313814
- RISC-V tech-unprivileged list, AME ratification plan review and Krste Asanović / Thomas Gall comments — https://lists.riscv.org/g/tech-unprivileged/topics?threadid=113596737
- RISC-V VME ratification plan (referenced by the SJTU ISC RISC-V group technical digest) — https://riscv.atlassian.net/wiki/spaces/VMEX/pages/663617995/Ratification+Plan
- NC Labs, "RISC-V Adoption Update at Hot Chips 2026" (AME / IME / VME grouping, fast-track vector option) — https://nc-labs.com/risc-v-standards-update-hot-chips-2026.html
Verification notes
- The VME milestone dates come from the ratification plan as quoted in the SJTU ISC RISC-V group digest. The primary wiki page was not retrieved; confirm against the VMEX wiki before these go into a schedule.
- The Summit Europe 2026 talk description is an abstract submitted by the speaker; it states status as of submission, not a ratified outcome. IME/VME architectural details are quoted from it.
- AME objections are quoted from the public mailing list, attributed to Krste Asanović and Thomas Gall.