Releases · riscv/integrated-matrix-extension

Arithmetic model

• Floating-point multiply-accumulate semantics defined by three implementation-defined parameters (G, psm, rnd),
  disclosed per (SEW, W, lambda).
  • G is the number of sub-dot-products combined into a partial sum.
  • psm selects between exact internal computation and a bulk-normalized (RVBNA) representation.
  • rnd controls an optional round-to-odd step before accumulation into C.
  • Final accumulation into C uses the dynamic rounding mode from frm; exception flags accumulate into fflags.

Interrupt and execution model

• vstart = 0 required for all 11 GEMM multiply-accumulate instructions (illegal-instruction if non-zero). Tile
  load/store instructions continue to honor vstart through their body loops.

Dimensional consistency

• N_tile divisor unified to lambda × LMUL across all integer and floating-point GEMM instructions.
• MUL_C requirements tightened: lambda^2 must divide VLEN/SEW, and the C register group index must be a
  multiple of MUL_C.

Terminology

• "Widening" (arithmetic) and "packing" (storage layout) distinguished consistently, with both coupled through
  parameter W.

Format support

• Mixed-format floating-point inputs permitted on the non-widening vfmmacc.vv (E4M3 × E5M2, FP16 × BF16); prior
  restriction removed.
• Mixed OFP8 inputs permitted on all four floating-point multiply-accumulate instructions (vfmmacc.vv,
  vfwmmacc.vv, vfqmmacc.vv, vf8wmmacc.vv).

Editorial

• vsetivli mentioned alongside vsetvli where altfmt_A/altfmt_B/bs sit outside the immediate field.
• Assorted normative cross-references added; consistent use of "non-widening"/"widening" throughout.
• SAIL tile load/store: LD declared mutable (var) since it is reassigned within the body.

Read more

Release Notes — Zvvm Family of Integrated Matrix Extensions

Scope: All changes to src/integrated-matrix.adoc since the repository
baseline at f83dff03.

New specification: Zvvm Family of Integrated Matrix Extensions

This release introduces the complete specification for the Zvvm family of
Integrated Matrix Extensions, a set of RISC-V ISA extensions that add matrix
multiply-accumulate instructions operating entirely within the standard V
register file, with tile geometry derived algebraically from existing vtype
fields (VLEN, SEW, LMUL) and a new aspect-ratio field λ.

Specification content

Core integer multiply-accumulate (Zvvmm)

• vmmacc.vv (W=1), vwmmacc.vv (W=2), vqwmmacc.vv (W=4) covering the
  full integer subextension family from Zvvmmi4b (Int4×Int4→Int8) through
  Zvvmmd (Int64×Int64→Int64).
• Independent altfmt_A / altfmt_B fields in vtype select signed or
  unsigned interpretation of each input independently; the accumulator is
  always signed.
• Vector masking (vm=0) is explicitly reserved for the integer family; all
  integer multiply-accumulate instructions require vm=1.
• LMUL is restricted to integer values (1, 2, 4, 8); fractional LMUL is not
  permitted.

Core floating-point multiply-accumulate (Zvvfmm)

• vfmmacc.vv (W=1), vfwmmacc.vv (W=2), vfqwmmacc.vv (W=4) covering
  OFP4, OFP8, FP16, BF16, FP32, and FP64 input/accumulator combinations.
• Mixed-format inputs (altfmt_A ≠ altfmt_B) are permitted for widening
  instructions; vfmmacc.vv with mixed FP16/BF16 inputs raises an
  illegal-instruction exception.
• Mixed OFP8 inputs (E4M3 × E5M2) are permitted only with widening
  instructions.

Tile load/store (Zvvmtls)

• vmtl.v (row- or column-major tile load), vmttl.v (transposing tile
  load), vmts.v (tile store) with leading-dimension stride operand.
• Tail and mask policy aligned with base V; partial-VL semantics specified for
  embedded streaming use cases.

Microscaling support (Zvvfmm MX variants)

• vm=0 on FP multiply-accumulate opcodes selects microscaling decode: E8M0 block scale factors in v0, block size selected by bs field in vtype (32 or 16 elements), input formats selected by altfmt_A/altfmt_B.
• vfwimmacc.vv and vfqwimmacc.vv: integer (MXINT) inputs with FP accumulator, microscaling only; altfmt_A=1 and altfmt_B=1 are reserved (MXINT inputs are always signed).
• Full subextension coverage: MXFP4, MXFP8, MXINT8, MXINT4 with BS=32 (Zvvfmmmx*) and BS=16 (Zvvfmmnx*) variants.
• Scale data layout in v0 is tile-strided with row stride R = λ × SEW ÷ 16; M × R = VLEN ÷ 16 always fills exactly one register.

W=8 octal-widening carve-out

• Subextension names defined for future W=8 instructions: Zvvmmbd (Int8→Int64), Zvvfmmofp4f (OFP4→FP32), Zvvfmmofp8d` (OFP8→FP64), and MX counterparts for MXFP4→FP32, MXFP8→FP64, and MXINT8→FP64.
• Encoding space reserved: funct6 = 0x3b in OPIVV (following vmmacc/vwmmacc/vqwmmacc at 0x38–0x3a) and funct6 = 0x17 in OPFVV (following vfmmacc/vfwmmacc/vfqwmmacc at 0x14–0x16).

Supporting material

• C-language intrinsics: Proto-intrinsic API covering all (SEW, λ, LMUL) combinations for integer, widening, FP, and microscaling variants, using vtype.h to expose the full vtype control surface without requiring compiler support.
• GEMM pseudocode: Illustrative tiling loop for both FP and integer GEMM using vmtl.v / vfmmacc.vv / vmts.v.
• Arithmetic considerations: Analysis of rounding, exception flag accumulation, and precision requirements for widening and microscaling paths.
• Figures: Diagrams for tile load/store geometry (row-major vs. column-major, partial-VL), microscaling v0 layout, and lane-local scale alignment.

Encoding