RVV FFT Acceleration: From 12.8 us to 2.4 us on a RISC-V Vector Core

A post published on September 10, 2026 on the 21ic RISC-V forum documents the port of a 512-point radix-2 FFT to the RISC-V Vector Extension (RVV) and provides concrete timing numbers on the XuanTie C906 core. The results are a useful reference for anyone evaluating RVV for digital signal processing workloads.

Why RVV for FFT?

The RISC-V Vector Extension differs from ARM Neon and SVE in one important way: the vector length is discovered at runtime through the vlenb CSR. The same binary can therefore run efficiently on hardware with different vector register widths, without recompilation. For embedded signal-processing applications, this is a significant portability advantage.

Test Setup

• Core: XuanTie C906 at 1 GHz
• Vector register width: VLEN = 256 bit, vlenb = 32 bytes
• Compiler: RISC-V GCC 12.x or newer
• Build flags: -march=rv64gc_v -mabi=lp64d -O3 -ftree-vectorize

The FFT implementation is a classic radix-2 butterfly algorithm. The dominant costs are complex multiplications and twiddle-factor table lookups.

Benchmark Results

The 5.3x speedup comes primarily from using vector loads and fused multiply-add operations across the butterfly stages.

Key Implementation Techniques

The author highlights four RVV-specific techniques that matter for FFT performance:

1. Twiddle table loading. Use vle32.v with vlenb-aligned buffers to load twiddle factors in batches.
2. Bit-reversal permutation. Use vid.v and viota.m to construct index vectors for the bit-reversed lookup table.
3. Precision. Keep intermediate butterfly accumulations in fp64 and truncate at the end to reduce error accumulation.
4. Runtime vector length. Always call vsetvl to set the active vector length from the actual vlenb, rather than assuming a fixed width.

Pitfalls to Avoid

The post also lists four common mistakes when moving scalar FFT code to RVV:

1. Wrong vector length. Assuming vlenb = 64 bytes causes out-of-bounds accesses. Always read vlenb at runtime.
2. Twiddle table size. The table should contain N/2 + 1 entries, not N/2. Missing the extra entry leads to segmentation faults.
3. Floating-point CSR. When writing frcsr to mask exceptions, preserve the default round-to-nearest mode. Other modes can silently corrupt results.
4. Interrupt context. RVV adds vstart, vxsat, and vcsr to the context that must be saved on interrupt entry. In RTOS environments, consider disabling preemption for DSP tasks shorter than roughly 100 us to avoid that overhead.

Portability Notes

The techniques above are written for a 64-bit RVV implementation, but the same principles apply to 32-bit cores such as the WCH QingKe V4 series when they include the vector extension. For developers working with CH32V003 or CH32V307, the scalar baseline is still the practical starting point; however, as V4F and future QingKe variants add RVV support, the same FFT optimization path will become relevant.

On the SpacemiT side, the K1 IME matrix extension and the K3 A100 AI cores offer alternative acceleration paths for larger FFT sizes, but RVV remains the most portable starting point for general signal-processing kernels.

Takeaway

A 5.3x speedup on a 512-point FFT with hand-tuned RVV intrinsics demonstrates that the RISC-V vector extension is competitive for embedded DSP work. The main prerequisites are a compiler that supports RVV, a runtime check of vlenb, and careful attention to twiddle-table bounds and floating-point CSR state.

Source: RISC-V向量扩展(RVV)在FFT加速中的移植与性能实测