REVIEW 4 major objections 5 minor 5 references
CVA6S+: A Superscalar RISC-V Core with High-Throughput Memory Architecture
T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash
Pith's one-line read CVA6S+ is a superscalar RISC-V core that the paper claims runs Embench-IoT integer kernels 43.5% faster than scalar CVA6 and 10.9% faster than CVA6S, at 9.30% area overhead, with a 74.1% bandwidth gain from the HPDCache.
desk verdict Useful incremental superscalar CVA6 extension with plausible numbers, but the abstract overstates performance and the configuration details need to be pinned down. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The argument rests on the dual-issue superscalar pipeline of CVA6S, extended with four mechanisms: register renaming that tracks the latest writer to each integer and floating-point register to remove Write-After-Write hazards; a two-level branch predictor with 128 entries and 3-bit private history per entry, reported to cut misprediction penalties by 30% relative to the bimodal predictor; same-cycle ALU-to-ALU operand forwarding so a second ALU operation can use the first's result directly; and an FPU that shares the write-back port with the secondary ALU under new hazard logic. On the memory side, the load-bearing component is the HPDCache, a three-stage pipelined, non-blocking L1 data cache with multiple request ports, a deep miss-status holding register, a hardware prefetcher, and support for write-through/write-back policies and atomics. These mechanisms are what the paper varies between otherwise similar configurations, so they carry the attribution of the measured IPC and bandwidth gains.
What would settle it
Re-synthesize CVA6S and CVA6S+ with identical FPU configuration and with the load-unit output register disabled on all cores, then run the same Embench-IoT kernels on the same SoC platform; if the IPC gap between the two cores drops well below 10.9% or the area overhead climbs above 9.30%, the central attribution fails. A second check is to disable register renaming alone in CVA6S+ and see whether the IPC gain over CVA6S persists.
Extended reading notes
Core claim
The central claim is that the performance ceiling of an in-order open-source RISC-V core can be raised substantially with a small set of back-end microarchitectural changes. The paper reports that CVA6S+ executes the Embench-IoT integer kernels at 3.69 CoreMark/MHz, against 3.41 for CVA6S and 2.83 for scalar CVA6, corresponding to IPC gains of 10.9% and 43.5%, respectively; the whole-core area penalty is 9.30%, and the pipeline-only penalty is 28.6%. It further claims that replacing the blocking write-back data cache with the HPDCache improves memory bandwidth by 74.1% on average across sequential and non-sequential access patterns, while the HPDCache's SRAM organization actually shrinks the data-cache area by 19% and enables a higher maximum frequency (1095 MHz versus 960 MHz). These numbers are presented as the payoff of the four pipeline additions working together rather than any single one.
Load-bearing premise
The comparison assumes the three cores differ only in the advertised features; in practice CVA6S lacks the floating-point unit and an extra output register adds one cycle of load latency in the other cores, so the measured gaps might partly come from those configuration differences.
Editorial extensions
If this is right
- A scalar in-order core can reach roughly 30% higher CoreMark/MHz by moving to a dual-issue front end with renaming, better branch prediction, and forwarding, at under 10% total area cost.
- The 74.1% bandwidth gain implies that memory-bound workloads with working sets larger than the L1 cache benefit substantially from a non-blocking cache, while the area reduction means the HPDCache is not a penalty.
- With the FPU integrated and sharing the write-back port, CVA6S+ covers both integer and floating-point workloads that CVA6S could not, extending the usable application space of the core.
- A 30% reduction in branch-misprediction penalty makes the core more attractive for control-heavy code where branches dominate.
- The 1095 MHz maximum frequency with HPDCache versus 960 MHz with the legacy cache suggests the memory subsystem change can also improve timing closure, not just throughput.
Reading between the lines
- A natural next experiment is to disable each of the four pipeline additions one at a time and re-measure Embench-IoT, which would reveal how much of the 10.9% gain over CVA6S comes from renaming versus branch prediction versus forwarding; the paper reports only the combined effect.
- Because the evaluation is 32-bit with the integer Embench-IoT kernels, the gains for 64-bit code, floating-point-heavy code, and OS/Linux workloads remain untested; those are the cases where register pressure and branch behaviour differ most.
- The same recipe of renaming, private-history branch prediction, and same-cycle forwarding could be applied to other scalar in-order open-source RISC-V cores, and the 9.30% area figure suggests it would be cheap to try.
- The cache comparison uses a working set twice the data-cache size, which deliberately stresses bandwidth; on working sets that fit in cache, the HPDCache's 74.1% advantage should shrink, so the meaningfully comparable number for embedded code is the IPC gain, not the bandwidth gain.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents CVA6S+, a superscalar RISC-V core derived from the CVA6S design, and integrates it with the OpenHW HPDCache. The microarchitectural additions are register renaming, a two-level private-history branch predictor, ALU-to-ALU operand forwarding, and FPU integration. The authors report a 43.5% IPC improvement over the scalar CVA6 and a 10.9% IPC improvement over CVA6S on the Embench-IoT integer kernels, a 74.1% bandwidth improvement over the legacy cache subsystem on RaiderSTREAM, and a total area overhead of 9.30% over CVA6. The paper is a short workshop-style report with synthesis results on GF22 FDX and FPGA measurements on a Genesys 2 board.
Significance. If the evaluation is sound, the contribution is a meaningful, open-source-oriented RISC-V core with a modest area cost and a higher-throughput memory path. The paper has several strengths: it uses external benchmark suites (Embench-IoT, CoreMark, RaiderSTREAM), reports synthesis results in a modern technology node, and builds on publicly available designs (CVA6, CVA6S, HPDCache). The central architectural ideas—register renaming, improved branch prediction, forwarding, and non-blocking cache integration—are plausible and of value to the embedded and open-hardware communities. However, the current evaluation does not fully isolate the effect of the new features because of configuration differences across the compared cores and missing per-benchmark and clock-level details. These issues are fixable within the manuscript's scope.
major comments (4)
- [Abstract and Evaluation] The abstract states that CVA6S+ achieves a 43.5% performance improvement over the scalar configuration, but the Evaluation section reports this as an IPC gain on the integer kernels of Embench-IoT. In the same section, CoreMark/MHz improves from 2.83 to 3.69, which is a 30.2% increase, not 43.5%. The paper must explicitly distinguish IPC from overall performance and reconcile these numbers, for example by reporting CoreMark scores and per-benchmark IPC results, so that the headline claim is not overstated.
- [Evaluation, configuration matching] The IPC comparison between CVA6, CVA6S, and CVA6S+ is potentially confounded by configuration differences. The paper states that CVA6S lacks the FPU while CVA6 and CVA6S+ have it; since the FPU shares the write-back port with the secondary ALU and adds hazard logic, its presence can affect scheduling even for integer code. The paper also states that an optional Load Unit output register is enabled to improve timing closure, adding one cycle of load latency, but does not specify for which of the three cores this option is enabled. If the load-use latency differs across the compared cores, the measured IPC differences directly include a configuration effect rather than isolating the listed pipeline enhancements. The authors should report the exact configuration of each core, including toolchain flags, memory map, and the load-unit register setting, or run a sensitivity analysis showing that the reported gains are insensitive to these settings.
- [Evaluation, RaiderSTREAM bandwidth] The RaiderSTREAM bandwidth comparison reports only a 74.1% average improvement and gives no per-pattern results, error bars, or the actual FPGA clock frequency used for the legacy-cache and HPDCache runs. Table 1 lists different maximum synthesis frequencies for CVA6S+ with the Legacy cache (960 MHz) and with HPDCache (1095 MHz); if the FPGA clock also differs between the two measurements, the bandwidth gain is at least partly a clock effect. The paper must state the FPGA clock configuration and provide per-benchmark bandwidth numbers for the sequential and non-sequential patterns.
- [Evaluation, Table 1 area comparison] The reported 9.30% area overhead is computed between CVA6+HPDCache and CVA6S++HPDCache, not between the scalar core with its legacy cache and the new core with the new cache. The text says 'The overall area of CVA6S+ increases by only 9.30%' without noting that the baseline CVA6 row also uses HPDCache. To make the area claim transparent and comparable with the abstract's 'area overhead over the scalar core (CVA6)', the paper should either present the area of CVA6 with the legacy cache and compare it against CVA6S+ with the legacy or HPDCache, or clearly state that the 9.30% figure holds only when both cores use HPDCache.
minor comments (5)
- [Abstract] The phrase '43.5% performance improvement' should be changed to '43.5% IPC improvement' to match the Evaluation section and Figure 1.
- [Evaluation] The sentence 'all supporting the RV32IMAC ISA along with thea, b, c, and s bitmanip extensions' contains a typo: 'thea' should be 'the a'.
- [Evaluation and Table 1] The text 'T able 1' at the top of the results section is a typo and should be 'Table 1'.
- [Throughout] The name 'HPDCache' is spelled inconsistently as 'HPDcache' in the Implementation and Conclusion sections; the paper should use a single spelling.
- [Figure 1] Figure 1 does not show per-benchmark data points or error bars, so the reported averages cannot be assessed for variance; adding markers for individual benchmarks would improve confidence in the claimed gains.
Circularity Check
No significant circularity: the claimed IPC and bandwidth gains are direct benchmark measurements against external suites, not derivations from the paper's own inputs.
full rationale
The paper's central claims are experimental measurements, not analytical derivations. The 43.5% IPC improvement over CVA6, the 10.9% improvement over CVA6S, and the 74.1% bandwidth improvement from HPDCache are all reported as measured results from the Embench-IoT and RaiderSTREAM benchmarks. No fitted parameters are introduced, no equation is used to predict a quantity from another quantity of the same paper, and no uniqueness theorem or ansatz is imported from prior work via citation. The cited baselines CVA6S and HPDCache are prior works with overlapping authorship, but they serve as comparison points that were actually implemented and measured against, not as unverified premises from which the new results are derived. The Evaluation section states that the cores differ in FPU availability and that 'An optional Load Unit output register is enabled to improve timing closure, adding one cycle of latency for load operations,' and these configuration differences are a legitimate correctness or reproducibility concern about whether the IPC comparison isolates the microarchitectural changes. However, that concern is about experimental methodology, not circularity: the measured numbers are not constructed to equal the inputs. The only self-citations are to baseline hardware that the present paper extends, and no load-bearing claim reduces to a self-citation. Under the given criteria, the paper is self-contained against external benchmarks, so the appropriate circularity score is 0.
Assumptions & free parameters
assumptions (3)
- domain assumption Benchmark suites (Embench-IoT, CoreMark, RaiderSTREAM) are representative of the target workloads and their configurations are adequate to support the performance claims.
- domain assumption The compared configurations differ only in the described microarchitectural features and the cache subsystem.
- domain assumption The RTL implementations are functionally correct on the tested workloads.
Cite this review
Pith. "Pith review of CVA6S+: A Superscalar RISC-V Core with High-Throughput Memory Architecture." pith.science (2026). https://pith.science/paper/V4PZL6JF
@misc{pith2026250503762,
author = {Pith},
title = {Pith review of: CVA6S+: A Superscalar RISC-V Core with High-Throughput Memory Architecture},
year = {2026},
howpublished = {\url{https://pith.science/paper/V4PZL6JF}},
note = {Machine review of arXiv:2505.03762}
}
read the original abstract
Open-source RISC-V cores are increasingly adopted in high-end embedded domains such as automotive, where maximizing instructions per cycle (IPC) is becoming critical. Building on the industry-supported open-source CVA6 core and its superscalar variant, CVA6S, we introduce CVA6S+, an enhanced version incorporating improved branch prediction, register renaming and enhanced operand forwarding. These optimizations enable CVA6S+ to achieve a 43.5% performance improvement over the scalar configuration and 10.9% over CVA6S, with an area overhead of just 9.30% over the scalar core (CVA6). Furthermore, we integrate CVA6S+ with the OpenHW Core-V High-Performance L1 Dcache (HPDCache) and report a 74.1% bandwidth improvement over the legacy CVA6 cache subsystem.
Figures
Reference graph
Works this paper leans on
-
[1]
F. Zaruba and L. Benini, “Cost of application-class processing: Energy and performance analysis of a 1.7-ghz 64-bit risc-v core,”IEEE Trans. VLSI Syst., vol. 27, pp. 2629–40, 2019
work page 2019
-
[2]
Using a performance model for su- perscalar cva6 implementation,
C. Allart, J.-R. Coulon, A. Sintzoff, O. Potin, and J.-B. Rigaud, “Using a performance model for su- perscalar cva6 implementation,” inProc. ACM CF: Workshops, 2024, pp. 43–6
work page 2024
-
[3]
Hpdcache: Open-source high- performance l1 data cache for risc-v,
C. Fuguet, “Hpdcache: Open-source high- performance l1 data cache for risc-v,” inProc. 20th ACM CF, 2023, pp. 377–8. 2 RISC-V Summit Europe, Paris, 12-15th May 2025
work page 2023
-
[4]
Cheshire: A lightweight, linux-capable risc-v host platform,
A. Ottaviano, T. Benz, P. Scheffler, and L. Benini, “Cheshire: A lightweight, linux-capable risc-v host platform,” IEEE Trans. Circuits Syst. II: Express Briefs, vol. 70, pp. 3777–81, 2023
work page 2023
-
[5]
Raiderstream: Adapting stream for modern hpc systems,
M. Beebe, B. Williams, S. Devaney, J. Leidel, Y. Chen, and S. Poole, “Raiderstream: Adapting stream for modern hpc systems,” inProc. IEEE HPEC, 2022, pp. 1–7. RISC-V Summit Europe, Paris, 12-15th May 2025 3
work page 2022
Reviewed August 16, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.