Spatz: Compact RISC-V Vector Processing

• Spatz is a compact RISC-V vector processing architecture featuring both 32-bit integer and 64-bit floating-point capabilities optimized for energy-efficient clusters.
• It achieves high performance through modular design, low-overhead VRF co-design, and innovative scalar-vector coupling, realizing up to 285 GOPS and 15.7 DP-GFLOPS.
• The architecture incorporates run-time reconfigurability and targeted fault sensitivity analyses to enhance reliability and performance in clustered environments.

Searching arXiv for relevant Spatz papers to ground the article. Spatz denotes a sequence of compact RISC-V-based vector processing architectures developed for high-performance, energy-efficient clusters with tightly coupled local memory. In its 2022 formulation, Spatz is a compact, modular 32-bit vector processing unit based on the integer embedded subset of the RISC-V Vector Extension version 1.0; in its 2023 formulation, it is a compact 64-bit floating-point-capable vector processor based on RISC-V’s Vector Extension Zve64d (Cavalcante et al., 2022, Perotti et al., 2023). Across these formulations, the architecture couples a lightweight Snitch scalar core to a vector backend, uses a private Vector Register File (VRF) as a low-level data-reuse structure, and targets shared-L1 or scratchpad-centric clusters rather than classical large-vector supercomputer designs. Subsequent work extends the baseline with run-time reconfigurability and evaluates transient-fault sensitivity under SET and SEU models (Perotti et al., 2024, Cai et al., 6 May 2026).

1. Design lineage and scope

The name Spatz is used across several closely related papers to describe an architectural line rather than a single immutable microarchitecture. The 2022 work focuses on integer vector processing in MemPool-style shared-L1 clusters, while the 2023 work generalizes the concept to a floating-point-capable dual-core cluster with a shared Scratchpad Memory (SCM). Later work introduces Spatzformer, a reconfigurable dual-core RVV cluster derived from the Snitch+Spatz baseline, and a fault-injection study of the open-source RISC-V vector cluster Spatz (Cavalcante et al., 2022, Perotti et al., 2023, Perotti et al., 2024, Cai et al., 6 May 2026).

Work	Formulation	Representative result
(Cavalcante et al., 2022)	32-bit integer VPU, Zve32x, MemPool integration	Up to 285 GOPS and 266 GOPS/W on 256x256 32-bit integer matrix multiplication
(Perotti et al., 2023)	64-bit floating-point-capable vector processor, Zve64d	15.7 DP-GFLOPS and 95.7 DP-GFLOPS/W at 1 GHz
(Perotti et al., 2024)	Reconfigurable dual-core RVV cluster	Merge mode accelerates mixed scalar-vector kernels by up to 1.8x
(Cai et al., 6 May 2026)	Transient-fault sensitivity study	FD accounts for at least 86% of manifesting SET errors and at least 91% of manifesting SEU errors

A consistent objective across these papers is mitigation of the Von Neumann Bottleneck by amortizing instruction fetch and decode over long vector operations. This objective is explicit in the 2022 paper, which argues that architecting PEs as vector processors can greatly reduce instruction fetch bandwidth, but that classical vector machines often include micro-architectural mechanisms for ILP that increase fetch and decode energy overhead (Cavalcante et al., 2022). A plausible implication is that Spatz is best understood as a deliberately lean vector architecture: it retains vector-length amortization while avoiding the control and buffering complexity associated with classical high-end vector machines.

2. The 32-bit integer Spatz for shared-L1 clusters

The 2022 Spatz is introduced as a compact, modular 32-bit vector processing unit intended as a small and efficient PE for large-scale shared-L1 clusters. It implements the integer embedded subset of the RISC-V Vector Extension version 1.0, specifically Zve32x, and is evaluated by integrating it within MemPool, a large-scale many-core shared-L1 cluster (Cavalcante et al., 2022).

Architecturally, the design is highly parametric. A Spatz-based cluster can be instantiated with a configurable number $N$ of Multiply-Accumulate Units (MACUs), with {2} and {4} MACU configurations discussed in the paper. The controller manages instruction dispatch, execution, completion, and vector state/control registers such as vlen and vtype. The vector backend is organized around a centralized, latch-based, multi-banked VRF with four banks, each 3R1W, and three functional blocks: the VAU, the VLSU, and the VSLDU. The VAU contains $N$ MACUs and supports simultaneous 32b/16b/8b operations via packed-SIMD; the VLSU provides $N$ independent 32b-wide memory interfaces; and the VSLDU implements permutation operations such as slides and shuffles (Cavalcante et al., 2022).

The scalar-vector split is central to the design. Spatz is described as fully co-processor-agnostic and interfaced via the generic CORE-V X-Interface, with Snitch handling scalar code and vector instruction issue. The 2022 paper also describes pseudo-double-issue behavior, in which the VAU, VLSU, and VSLDU can run in parallel without out-of-order or superscalar hardware (Cavalcante et al., 2022). This arrangement is intended to preserve MIMD flexibility at cluster scale while minimizing scalar-core energy overhead during DLP-dominated execution.

Quantitatively, the reported gains over scalar Snitch clusters are substantial. A Spatz-based cluster with four MACUs needs only 7.9 pJ per 32-bit integer multiply-accumulate operation, 40% less energy than an equivalent cluster built with four Snitch scalar cores. In MemPool, the Spatz-based system achieves up to 285 GOPS when running a 256x256 32-bit integer matrix multiplication, 70% more than the equivalent Snitch-based system, and up to 266 GOPS/W on the same kernel, compared with 128 GOPS/W for the Snitch-based MemPool system (Cavalcante et al., 2022). The same study reports 7.67 op/cycle for Spatz-{4} on matrix multiplication, corresponding to 95.8% MACU utilization, and 3.84 op/cycle for Spatz-{2}, corresponding to 96.0% utilization (Cavalcante et al., 2022).

These results are significant because they support the paper’s core claim: lean vector processors are viable as high-performance and energy-efficient PEs for large-scale clusters with tightly coupled L1 memory. The comparison is not between vector processing and fixed-function acceleration, but between vector and scalar programmability under similar cluster assumptions.

3. Floating-point-capable Spatz and the compact-VRF thesis

The 2023 paper reformulates Spatz as a compact 64-bit floating-point-capable vector processor based on RISC-V’s Vector Extension Zve64d and uses it as the main PE in an open-source dual-core vector processor architecture with a shared SCM (Perotti et al., 2023). This work places particular emphasis on the relationship between vector efficiency, local storage sizing, and cluster balance.

A central claim of the paper is that, unlike typical vector processors whose VRFs are hundreds of KiB large, Spatz can achieve peak energy efficiency with a latch-based VRF of only 2 KiB. In the reported implementation, each PE comprises a lightweight Snitch scalar core tightly coupled to Spatz, and the dual-core cluster shares a 128 KiB L1 SPM implemented as 16 banks × 8 KiB. The VRF is centralized, two-banked, multi-ported at 3R1W per bank, latch-based, and typically 2 KiB in total size, corresponding to 32 × 64-byte vector registers (Perotti et al., 2023).

The paper further contrasts latch-based SCM-style storage with SRAM for small-capacity VRFs. For small buffers such as 2 KiB, the reported access energy is 0.38 pJ/byte for the latch-based VRF versus 0.58 pJ/byte for SRAM at similar scales. The authors also provide fitted read and write energy models for an $W \times R$-byte VRF of $K = WR$ bytes, reinforcing the methodological emphasis on right-sized L0 storage rather than maximal vector length (Perotti et al., 2023). This suggests that the 2023 Spatz is organized around storage-efficiency co-design: the VRF is not merely a programmer-visible register structure but an explicitly optimized locality buffer.

The performance figures are correspondingly framed in terms of FPU utilization and energy efficiency. An implementation in GlobalFoundries’ 12LPP process with eight double-precision FPUs achieves an FPU utilization just 3.4% lower than the ideal upper bound on a double-precision floating-point matrix multiplication. The cluster reaches 7.7 FMA/cycle, corresponding to 15.7 DP-GFLOPS and 95.7 DP-GFLOPS/W at 1 GHz and nominal operating conditions (TT, 0.80V, 25C), with more than 55% of the power spent on the FPUs. The optimally balanced Spatz-based cluster reaches a 95.0% FPU utilization, 7.6 FMA/cycle, 15.2 DP-GFLOPS, and 99.3 DP-GFLOPS/W on a 2D workload with a 7x7 kernel, resulting in 171 DP-GFLOPS/W/mm2 (Perotti et al., 2023).

The scalar comparison remains important in this later formulation. At equi-area, the compact-vector cluster reaches a 30% higher energy efficiency than a cluster with the same FPU count built upon scalar cores specialized for stream-based floating-point computation (Perotti et al., 2023). The significance of that claim is methodological: the paper is not arguing for oversized vector engines, but for compact vector units whose private VRFs reduce dependence on wide, power-hungry L1 interconnects.

4. ISA profile and microarchitectural organization

Across the Spatz papers, the programming model is anchored in RVV, but the implemented subset and datapath capabilities differ by generation. The 2022 integer design implements Zve32x and focuses on 8b/16b/32b integer DLP tasks. Supported instruction classes include vector arithmetic such as vadd, vmul, and vmacc, vector memory operations including unit-stride, stride, and constant-stride loads/stores, and vector permutation operations supported by the centralized VRF. The 2022 paper explicitly notes that vector reductions or scatter/gather are not yet implemented, although the microarchitecture contains provisions for later inclusion (Cavalcante et al., 2022).

The 2023 design shifts to Zve64d and supports 8/16/32/64-bit integer and floating-point vector operations. In that formulation, the VAU contains multiple FPU lanes and one Integer Processing Unit (IPU), the VLSU exposes dedicated 64-bit memory interfaces to the shared SPM, and the VSLDU handles permutations, slides, and reductions (Perotti et al., 2023). Both generations use vector chaining, hazard detection, and a scalar core that issues vector instructions through the X-Interface.

Several RVV features recur across the papers. VLEN is software-visible and configurable through CSRs; LMUL allows vector register grouping; and the decoupling between logical vector length and datapath width allows microoperation time-multiplexing. In the 2022 four-MACU configuration, the reported VLEN reaches up to 4096 bits with LMUL=8 (Cavalcante et al., 2022). These features matter because Spatz relies on vector-length agnostic programming to amortize instruction overhead without requiring a monolithic vector datapath.

A common misconception about compact vector processors is that they must either sacrifice utilization or rely on oversized register files and aggressive issue logic. The Spatz papers argue the opposite. The 2022 work reports near-peak MACU utilization even for small DLP sizes, and the 2023 work argues that peak energy efficiency is reached with a 2 KiB latch-based VRF rather than with the hundreds-of-KiB VRFs typical of classical vector processors (Cavalcante et al., 2022, Perotti et al., 2023).

5. Spatzformer and run-time reconfigurability

Spatzformer extends the baseline dual-core Snitch+Spatz cluster into a reconfigurable RVV architecture for mixed scalar-vector workloads. It is described as the first reconfigurable RISC-V V architecture developed from a baseline open-source dual-core cluster based on Snitch scalar cores augmented with compact Spatz vector units (Perotti et al., 2024).

The architecture operates in two distinct modes. In split mode, it functions as a dual-core vector architecture in which two scalar+vector pairs handle vectorizable tasks concurrently. In merge mode, two vector units are driven by a single scalar core, while the remaining scalar core handles non-vectorizable control tasks. The stated rationale is that conventional multi-core vector architectures often underutilize resources when sequential and control work cannot be vectorized (Perotti et al., 2024).

The reported hardware cost of this reconfigurability is small. Implemented in a 12-nm technology node, Spatzformer does not degrade the architecture’s maximum frequency, which remains 1.2GHz at TT, 0.8V, 25C. The area impact is given as +1.4%, with a worst-case energy efficiency drop of only 7% relative to the non-reconfigurable baseline (Perotti et al., 2024). The paper also reports an absolute area overhead of +55 kGE and average energy-efficiency losses of 5% in split mode and 1% in merge mode, although the most salient abstract-level summary is the negligible area impact and preserved frequency.

The performance effects are workload-dependent. Merge mode accelerates mixed scalar-vector kernels by up to 1.8x compared to split mode, and it accelerates vector kernels that require fine-grained synchronization, such as FFT, by up to 20% with respect to the baseline. For FFT specifically, the paper reports a 2.5% energy-efficiency increase in merge mode due to reduced instruction fetch and improved vector-lane utilization (Perotti et al., 2024). These data indicate that Spatzformer is not a new vector core so much as a control-plane extension to the Spatz cluster concept, intended to improve utilization under phase-heterogeneous workloads.

6. Reliability characterization and fault sensitivity

The 2026 fault study examines the open-source RISC-V vector cluster Spatz under SET and SEU fault models. The evaluated platform consists of one core complex with a Snitch scalar core, Spatz vector backend, TCDM, VRF, and VFU with FPnew units. Using the Synopsys VC Z01X RTL fault-injection tool, the study performs 100,000 injections on six MatMul and Widening MatMul configurations across FP32, FP16, BP16, and FP8 (Cai et al., 6 May 2026).

The dominant manifestation is Faulty Data Corruption rather than crash behavior. Across all evaluated workloads, FD accounts for at least 86% of manifesting errors in the SET campaigns and at least 91% in the SEU campaigns. Faulty System Crash is rare, accounting for 0.25% in SET and 0.05% in SEU according to the detailed summary. At the module level, SET sensitivity is concentrated in the vector execution path, while TCDM is the major contributor to FD manifestations; VRF and TCDM are also identified as major contributors to SDC via FD (Cai et al., 6 May 2026).

The paper further characterizes SDC severity through the average number of corrupted outputs and RMSE,

$$\mathrm{RMSE} = \sqrt{\frac{1}{K}\sum_{i\in\mathcal{I}} (y_i^{FM} - y_i^{GM})^2}.$$

FP8 shows the lowest output impact overall, while FP16 Widening MatMul reduces both corruption spread and RMSE compared with FP16 MatMul. By contrast, the effect of widening on FP8 is limited in the reported experiments. Exponent-targeted corruptions induce the most severe SDC events, with the largest deviations observed in FP32 and BP16 (Cai et al., 6 May 2026).

The study’s practical implication is selective protection rather than uniform hardening. The details emphasize the priority of exponent bits in FP32 and BP16 operand paths, handshake/control ports of VFU/VLSU, and storage elements such as VRF, TCDM, and the instruction cache. This suggests that, within the Spatz design space, reliability optimization is expected to follow the same cost-aware philosophy as performance optimization: focus on the highest-impact datapaths and fault cases rather than indiscriminate protection of all state and logic (Cai et al., 6 May 2026).