{"id":"4e03f6c3-907e-45f2-a660-e7e3cff45fdc","arxiv_id":"2505.03762","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"CVA6S+ combines dual-issue execution, register renaming, improved branch prediction, and the HPDCache to achieve 43.5% higher IPC than CVA6 and 74.1% higher memory bandwidth.","lead":"This paper describes CVA6S+, an upgraded open-source RISC-V processor core that can issue two instructions at once and uses better branch prediction and register renaming. In tests, it ran benchmark programs about 43% faster than the original single-issue CVA6 core, and its new memory system moved data about 74% faster.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"IPC comparison may be confounded by mismatched configurations: CVA6S lacks FPU and possibly lacks the optional load-unit register, so the 43.5%/10.9% gains may not isolate the described microarchitectural changes.","rationale":"The reader’s weakest assumption is the same one I find most load-bearing: configuration equivalence across the compared cores. The paper’s own evaluation paragraph explicitly discloses two configuration asymmetries (FPU presence in CVA6S and an optional load-unit output register) without explaining how their effects are separated from the claimed IPC gains. Since the reported improvements are on the order of 11-43%, a one-cycle change in load-use latency or the presence of an FPU can plausibly shift IPC by several percent on integer kernels, so the central attribution is not secure without matched configurations or per-benchmark sensitivity data. I agree with the reader’s conditional verdict rather than moving to reject: the measurements appear internally consistent and the design is plausible, but the documentation gap is real and directly tied to the headline numbers. My concrete test is designed to settle the question by rerunning with and without the two identified configuration differences. I do not see a stronger concern about the HPDCache bandwidth claim, which is a cache-subsystem comparison that also deserves the same configuration-match scrutiny but is less central to the paper’s main microarchitecture contribution.","tokens_in":3353,"tokens_out":1671,"duration_ms":13031,"concrete_test":"Obtain or reconstruct the exact configuration files and toolchain settings used for CVA6, CVA6S, and CVA6S+, then rerun the Embench-IoT integer kernels twice: once with the FPU enabled in CVA6S (if the ISA permits) and once with the Load Unit output register disabled for all three cores. If the 43.5% and 10.9% IPC differences persist to within a few percent under both matched configurations, the attribution holds; if the gains drop or reverse, the headline claim is confounded. As a minimal standalone check, the authors should state per-core whether the optional load-unit register was enabled and report per-benchmark IPC values with and without it.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim is that CVA6S+’s IPC gains (43.5% over CVA6, 10.9% over CVA6S) come from the listed pipeline enhancements: register renaming, two-level branch prediction, ALU-to-ALU forwarding, and FPU integration. For that attribution to hold, the compared cores must differ only in those features, with ISA, toolchain, and timing-related configuration held constant. The paper itself reports two configuration differences that are not isolated. First, CVA6S lacks the FPU while CVA6 and CVA6S+ have it, so the RV32IMAC configuration is not identical across all three cores and FPU presence could affect the integer-kernel measurements and area comparisons. Second, the evaluation section says an optional Load Unit output register is enabled to improve timing closure, adding one cycle of load-use latency, but does not state for which cores this option is enabled. If the load-use latency differs between the compared cores, the IPC comparison directly measures a configuration difference rather than the stated pipeline improvements. The paper also reports no per-benchmark results, no confidence intervals, and no artifact or configuration commit hashes, so the reader cannot verify that the FPGA frequency, memory map, and toolchain flags are matched. Because the claimed improvements (43.5% and 10.9%) are moderate, even a one-cycle load-latency difference or FPU-related scheduling difference could materially change the ranking. The area overhead figure (9.30% over CVA6, excluding cache changes) is also computed against a CVA6 configuration whose FPU presence is not stated as identical, so the area attribution is similarly at risk.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":3589,"tokens_out":5493,"duration_ms":45207,"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":[{"comment":"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.","section":"Abstract and Evaluation"},{"comment":"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.","section":"Evaluation, configuration matching"},{"comment":"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.","section":"Evaluation, RaiderSTREAM bandwidth"},{"comment":"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.","section":"Evaluation, Table 1 area comparison"}],"minor_comments":[{"comment":"The phrase '43.5% performance improvement' should be changed to '43.5% IPC improvement' to match the Evaluation section and Figure 1.","section":"Abstract"},{"comment":"The sentence 'all supporting the RV32IMAC ISA along with thea, b, c, and s bitmanip extensions' contains a typo: 'thea' should be 'the a'.","section":"Evaluation"},{"comment":"The text 'T able 1' at the top of the results section is a typo and should be 'Table 1'.","section":"Evaluation and Table 1"},{"comment":"The name 'HPDCache' is spelled inconsistently as 'HPDcache' in the Implementation and Conclusion sections; the paper should use a single spelling.","section":"Throughout"},{"comment":"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.","section":"Figure 1"}],"recommendation":"major_revision","confidential_remarks":"The paper is a short workshop-style contribution, but the evaluation issues touch the central claims. The fact that two baseline designs (CVA6S and HPDCache) involve co-authors is not a problem per se because the measurements are against external benchmark suites, but the configuration differences must be documented for the results to be credible. I would be willing to look at a revised version."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a solid but incremental engineering paper on the open-source CVA6 RISC-V core. The headline IPC gains are probably real, but the abstract overstates them as 'performance improvement' and the evaluation leaves a couple of configuration details ambiguous that should be resolved before I'd quote the exact percentages.\n\nWhat's new: the specific combination of register renaming, a two-level branch predictor, ALU-to-ALU forwarding, and FPU integration on CVA6S, plus the HPDCache integration. Each piece is known, but the integrated open-source core is a concrete deliverable. The synthesis results are internally consistent, and the HPDCache bandwidth gain is measured on a standard stream benchmark with a sensible working set.\n\nSoft spots: first, the abstract says 43.5% performance improvement, but the actual performance metric in the eval is CoreMark/MHz, which improves 30.4% over CVA6. The 43.5% is IPC on Embench-IoT only. Those are not equivalent, and the abstract should be fixed. Second, the eval says an optional Load Unit output register adds one cycle of load latency but never states which cores enable it. If CVA6S+ runs with it and the baselines don't, the measured IPC gain would be conservative; if the reverse, it would be inflated. This needs a configuration table. Third, CVA6S lacks the FPU, so its ISA is RV32IMAC while CVA6 and CVA6S+ have F. For integer kernels that probably doesn't matter, but it's a silent configuration difference. Also, there are no per-benchmark numbers, error bars, or artifact links, which makes it hard to gauge how much the averages depend on a few outliers.\n\nThese are all fixable. The central engineering claim—that these superscalar tweaks plus a better cache give a meaningful speedup at modest area—is likely correct. The paper deserves a proper referee, preferably one who asks for the configuration spreadsheet and a corrected abstract.\n\nThis is a useful data point for anyone working on open-source RISC-V cores or evaluating CVA6-based SoCs. I'd take a look, but I'd want the config details before citing the specific numbers.","headline":"Useful incremental superscalar CVA6 extension with plausible numbers, but the abstract overstates performance and the configuration details need to be pinned down.","tokens_in":4261,"tokens_out":5473,"would_cite":true,"duration_ms":44714,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["superscalar RISC-V core","IPC improvement","register renaming","branch prediction","operand forwarding","HPDCache","Embench-IoT","memory bandwidth"],"falsifier":"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.","tokens_in":3113,"feed_emoji":"⚙️","tokens_out":6986,"duration_ms":54184,"temperature":0.7,"pith_summary":"Building on the scalar open-source CVA6 core and its dual-issue variant CVA6S, the paper introduces CVA6S+, a superscalar RISC-V core that adds register renaming, a two-level branch predictor with private per-entry history, ALU-to-ALU operand forwarding, and an integrated FPU. On the integer kernels of the Embench-IoT suite, CVA6S+ is reported to achieve an average IPC gain of 43.5% over scalar CVA6 and 10.9% over CVA6S, with a total area overhead of 9.30%. Paired with the non-blocking HPDCache L1 data cache, the design also reports a 74.1% bandwidth improvement over the legacy cache subsystem on RaiderSTREAM patterns. If these measurements are right, a large part of the performance gap between scalar open-source cores and higher-end application cores can be closed at modest silicon cost.","feed_headline":"RISC-V core CVA6S+ gains 43.5% IPC at 9.3% area cost","feed_subtitle":"Open-source dual-issue design also lifts memory bandwidth 74.1% with a non-blocking L1 cache.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the scalar CVA6 core that serves as the baseline for IPC and area comparisons.","marker":"[1]"},{"why":"Introduces the CVA6S dual-issue superscalar variant that CVA6S+ extends.","marker":"[2]"},{"why":"Supplies the HPDCache, the non-blocking L1 data cache whose bandwidth replaces the legacy cache.","marker":"[3]"},{"why":"Provides the SoC testbed on which all three cores are measured on FPGA.","marker":"[4]"},{"why":"Supplies the RaiderSTREAM benchmarks used for the sequential and non-sequential memory bandwidth comparison.","marker":"[5]"}],"fun_headline_variants":["CVA6S+ boosts RISC-V IPC by 43.5% with tiny area hit","Open-source core CVA6S+ lifts IPC 43.5%, bandwidth 74.1%","43.5% faster RISC-V core, 9.3% more area: CVA6S+","CVA6S+ superscalar core: +43.5% IPC, +74.1% bandwidth","RISC-V core CVA6S+ hits 3.69 CoreMark/MHz"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["CVA6S+ boosts RISC-V IPC by 43.5% with tiny area hit","Open-source core CVA6S+ lifts IPC 43.5%, bandwidth 74.1%","43.5% faster RISC-V core, 9.3% more area: CVA6S+","CVA6S+ superscalar core: +43.5% IPC, +74.1% bandwidth","RISC-V core CVA6S+ hits 3.69 CoreMark/MHz"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000682,"raw_usage":{"total_tokens":3086,"prompt_tokens":925,"completion_tokens":2161,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":541,"completion_tokens_details":{"reasoning_tokens":2030}},"tokens_in":541,"tokens_out":2161,"duration_ms":13059,"temperature":1.0,"reasoning_tokens":2030,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T11:42:39.880315+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Using a performance model for su- perscalar cva6 implementation,","cited_arxiv_id":null,"evidence_quote":"Introduces the CVA6S dual-issue superscalar variant that CVA6S+ extends."},{"cited_title":"Cost of application-class processing: Energy and performance analysis of a 1.7-ghz 64-bit risc-v core,","cited_arxiv_id":null,"evidence_quote":"Defines the scalar CVA6 core that serves as the baseline for IPC and area comparisons."},{"cited_title":"Hpdcache: Open-source high- performance l1 data cache for risc-v,","cited_arxiv_id":null,"evidence_quote":"Supplies the HPDCache, the non-blocking L1 data cache whose bandwidth replaces the legacy cache."},{"cited_title":"Cheshire: A lightweight, linux-capable risc-v host platform,","cited_arxiv_id":null,"evidence_quote":"Provides the SoC testbed on which all three cores are measured on FPGA."},{"cited_title":"Raiderstream: Adapting stream for modern hpc systems,","cited_arxiv_id":null,"evidence_quote":"Supplies the RaiderSTREAM benchmarks used for the sequential and non-sequential memory bandwidth comparison."}],"review_version":1}