Zoozve: RISC-V Vector Extension

• Zoozve is a RISC-V vector extension that eliminates strip-mining by enabling flexible register configurations and arbitrary register groupings.
• It employs a data-adaptive compiler strategy to align register allocation with actual vector lengths, reducing overhead in long-vector applications.
• Evaluations report up to a 10.1× reduction in dynamic instruction count for FFT and significant speedups in dotproduct and axpy with only a 5.2% area increase.

Searching arXiv for the specified paper and closely related RVV context. Zoozve is a proposed RISC-V vector instruction-set extension intended to remove strip-mining as a bottleneck in long-vector execution. It targets the limitations of standard RISC-V “V” Vector Extension (RVV) when vectors exceed what the hardware can process in one pass, particularly under a fixed architectural vector-register file and power-of-two register grouping. The design combines flexible vector register lengths and counts, arbitrary vector register groupings, a data-adaptive register allocation strategy, LLVM-based compiler support, and a SystemVerilog proof-of-concept. In the reported evaluation, Zoozve yields a minimum $10.10\times$ reduction in dynamic instruction count for fast Fourier transform (FFT), with a $5.2\%$ increase in overall silicon area (Xu et al., 22 Apr 2025).

1. Motivation and problem setting

Zoozve was proposed to address three limitations attributed to standard RVV for ultra-long vectors, described as common in signal processing, communications, AI, and scientific kernels (Xu et al., 22 Apr 2025). The first is static register count limitations: RVV has a fixed architectural vector-register file, so for long vectors a large portion of data cannot stay resident in registers at once. The stated consequence is greater register pressure, spilling, and repeated loop iterations.

The second limitation is the power-of-two LMUL and register grouping constraint. RVV uses LMUL and grouped registers, but the grouping is restricted to power-of-two sizes. The paper states that this causes underutilization when the vector length does not fit neatly into those sizes, and that small leftover chunks in strip-mined loops can still consume a full large register group, wasting capacity (Xu et al., 22 Apr 2025).

The third limitation is strip-mining overhead. In the formulation used here, a long vector is divided into smaller pieces and each piece is processed separately. The cited overheads are extra loop control, repeated setup and teardown, tail handling, and more instructions overall. The paper further notes that RVV forces a tradeoff: large LMUL reduces the number of available vector registers, whereas small LMUL requires more strip iterations. Zoozve is presented as a way to eliminate that balance by allowing the hardware/compiler stack to allocate registers according to the actual data shape (Xu et al., 22 Apr 2025).

2. Architectural model and departure from RVV

Zoozve differs from standard RVV in two architectural respects. First, instead of a fixed set of vector registers and conventional LMUL scaling, it allows the quantity and dimensions of vector registers to be configured more flexibly. The design notes support for a large number of vector registers, exemplified as V0 to Vn, and states that the register access field can scale to up to $2^{13}$ vector registers (Xu et al., 22 Apr 2025).

Second, Zoozve supports arbitrary register grouping rather than RVV’s power-of-two register groups. The stated purpose is to let register allocation match the actual vector length and datatype more precisely. The paper explicitly connects this to better utilization for short or irregular vector lengths, less waste on tails, reduced spilling, and fewer strip-mined iterations (Xu et al., 22 Apr 2025).

This architectural framing is significant because the contribution is not described merely as an enlarged register file. Rather, the paper presents a coupled ISA and compilation model in which flexible vector register length and count configurations, together with arbitrary grouping, are meant to sustain long-vector execution without the conventional strip-mined loop structure. A plausible implication is that Zoozve redefines the granularity at which vector resources are exposed to the compiler, shifting the optimization target from power-of-two group sizing to data-shaped allocation.

3. Data-adaptive register allocation

The central compiler concept is a data-adaptive register allocation strategy. Instead of forcing register groups to be powers of two, the compiler determines the register group based on the starting register number, RG_head, and the data type or vector length requirement, RG_type (Xu et al., 22 Apr 2025).

The paper defines the datatype-dependent grouping size as

$RG_{type}=L \cdot VEW$

where $L$ is the programming vector length and $VEW$ is the vector element width. At compile time, register groups are allocated by computing

$RG_{tail} = RG_{head} + RG_{type}/VLEN$

where $VLEN$ is the bit width of a vector register (Xu et al., 22 Apr 2025).

The stated effect of this formulation is that grouping is aligned to actual data size rather than to a fixed LMUL power-of-two rule. The paper attributes to this adaptive allocation a reduction in unused register space, closer matching of vector lengths, lower register overhead, and reduced performance loss due to strip-mining. It also emphasizes that Zoozve “accurately aligns vector lengths,” which is presented as essential to practicality for long-vector kernels (Xu et al., 22 Apr 2025).

The same discussion places Zoozve against the RVV LMUL grouping limitation using the notation n_lmul, VLEN, and VEW, and identifies problematic vector-length ranges of the form

$(2^{n_{lmul}-1}+1) \cdot \frac{VLEN}{VEW}.$

The text indicates that these are ranges where RVV’s power-of-two grouping can lead to underutilization (Xu et al., 22 Apr 2025). This suggests that Zoozve’s grouping rule is intended not only as a capacity increase, but as a remedy for representational mismatch between vector length and allocatable register extent.

4. Instruction classes, operand model, and asymmetric operations

Zoozve vector instructions are organized into three classes: vector load/store, vector arithmetic and logical, and vector control. They use RISC-V custom opcode regions, specifically custom-0/1/2 (Xu et al., 22 Apr 2025).

A notable mechanism is the v_head field, including vd_head, vs2_head, and vs1_head. These fields are used to address large register groups efficiently by storing the starting addresses of vector registers. According to the paper, this mechanism enables access to up to $2^{13}$ vector registers, with further extensibility via vsetcsr writing extra bits into CSRs. Another key operand is rs_avl, a scalar register holding the target vector length. The combination of v_head, rs_avl, and flexible group allocation is presented as the basis for the strip-mining-free model (Xu et al., 22 Apr 2025).

Zoozve also introduces asymmetric instructions for cases in which source and destination vectors have different lengths. The paper gives two examples:

• scatter for lengthening: vd[vs2[i]] ← vs1[i]
• gather for shortening: vd[i] ← vs1[vs2[i]]

Unlike RVV’s vrgather, which keeps the same vector length for source and target, Zoozve allows the destination length to match the index length (Xu et al., 22 Apr 2025). The stated importance of this choice is that it avoids allocating larger-than-needed register groups for mismatch-heavy operations, thereby improving utilization. In context, this is a specific extension of the general arbitrary-grouping principle to irregular data movement.

5. LLVM compilation pipeline

Zoozve is accompanied by a custom LLVM-based compilation workflow. The first stage uses Zoozve-specific built-in functions in Clang, described as providing an intuitive interface and allowing explicit specification of vector value types. Clang then maps these built-ins into LLVM intrinsics, after which SSA form converts variables into virtual registers (Xu et al., 22 Apr 2025).

A custom Zoozve intrinsic splitting pass transforms the original intrinsic IR into a split form with specific value types. The paper states that this makes the virtual-register range explicit, enables precise handling of long vector values, and helps register allocation work with arbitrary grouping. It further specifies that the number of split instances is determined by the split count, and that delimiter intrinsics are inserted before and after each split. These delimiters indicate to register allocation that certain registers must be assigned consecutively to form a register group (Xu et al., 22 Apr 2025).

During register allocation, the compiler scans eligible registers, traces back to delimiter intrinsics, determines the LMUL, and modifies lifetimes so split virtual registers share aligned lifespans. The stated purpose is to preserve spatial continuity of grouped registers. After register allocation, the split IR is translated into Zoozve assembly, and an assembly coalescing pass merges consecutive Zoozve instructions if vector registers are consecutive and other parameters match. The paper describes this as reducing instruction count and reconstructing the original high-level operation (Xu et al., 22 Apr 2025).

The artifact pipeline listed in the paper indicates an end-to-end toolchain from C source to executable code and disassembly.

Artifact output	Role stated in the workflow
venusbuiltin.h	Compiler artifact output
venustype.h	Compiler artifact output
test.0.ll	LLVM artifact output
test.split.ll	Split-form LLVM artifact output
test_before_merge.s	Pre-coalescing assembly output
test.s	Final assembly output

The inclusion of executable and disassembly outputs suggests a fairly complete compilation flow rather than an isolated prototype pass (Xu et al., 22 Apr 2025).

6. Hardware realization

Zoozve includes a SystemVerilog proof-of-concept based on prior RISC-V vector work, with additional control-path and data-path components. On the control path, the design adds logic to support flexible register grouping and hazard detection between instructions. Comparators (CMPs) check whether register indices fall within RG_head and RG_tail, and their outputs are OR’ed to generate a hazard signal (Xu et al., 22 Apr 2025).

On the data path, the implementation adds a shuffle engine consisting of a crossbar and multiple processing elements (PEs). The paper states that this supports inter-lane asymmetric operations, while lanes handle symmetric operations (Xu et al., 22 Apr 2025). This is consistent with the ISA-level support for asymmetric gather and scatter and indicates that arbitrary grouping is reflected in execution hardware as well as compiler allocation.

The hardware is synthesized in SMIC 40nm at 400 MHz for a configuration of 64 lanes and 1024 registers. The reported results are a 7.2 mm² synthesis area, an 11.9 mm² layout area, and a 5.2% area overhead (Xu et al., 22 Apr 2025). Within the paper’s framing, these figures are used to argue that the flexibility introduced by Zoozve incurs a modest silicon cost.

7. Reported performance and interpretive significance

The headline performance result is a minimum $5.2\%$0 reduction in dynamic instruction count for FFT (Xu et al., 22 Apr 2025). The same benchmark family is also reported to reach $5.2\%$1 speedup at 32 points and $5.2\%$2 speedup at 2048 points. The paper interprets this as evidence that removing strip-mining and improving grouping can substantially reduce overhead in FFT-like workloads with long vectors and repeated data movement.

For dotproduct, RVV instruction count is reported to grow from 52 to 1292 and strip-mining iterations from 8 to 256, whereas Zoozve keeps instruction count constant at 17, with up to $5.2\%$3 speedup (Xu et al., 22 Apr 2025). For axpy, RVV instruction count grows from 25 to 707 and strip-mining iterations from 2 to 64, while Zoozve holds at 12 instructions, with up to $5.2\%$4 speedup (Xu et al., 22 Apr 2025).

These results are best understood in the paper’s own terms: Zoozve is presented as a strip-mining-free alternative to conventional RVV-style vector processing for workloads with very long vectors and irregular register needs. Its main contribution is described as a combined ISA, compiler, and hardware design that removes strip-mining overhead, supports arbitrary register grouping, aligns register allocation with actual vector lengths, improves handling of asymmetric vector operations, and does so with a reported 5.2% area increase (Xu et al., 22 Apr 2025).

A common misconception would be to interpret Zoozve solely as “more vector registers.” The paper’s formulation is narrower and more technical. It emphasizes that the key contribution is the combination of flexible register length and count configuration, arbitrary register grouping, data-adaptive register allocation, and asymmetric instruction support. This suggests that the performance improvements are not attributed to register-file scaling alone, but to the elimination of strip-mining-induced control and allocation inefficiencies across the ISA/compiler/hardware stack (Xu et al., 22 Apr 2025).