{"id":"8a67dd0f-46fc-48b6-a6f9-2a1ab47d9682","arxiv_id":"2508.20653","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A custom RISC-V instruction that computes one SHA-3 Keccak round in hardware is reported to speed up hashing by 8x to 46x in simulation with 11% to 15% area overhead.","lead":"This paper designs a custom SHA-3 instruction for RISC-V and tests it in a simulator and on an FPGA. It reports large speedups in hashing, from 8x to 46x, with modest added hardware.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The GEM5 timing model for shatr — latency, pipeline occupancy, and 1600-bit state-transfer cost — is never reported, so the 8.02x/46.31x speedups are not reproducible and may depend on optimistic one-cycle assumptions.","rationale":"The reader's weakest assumption — the unstated GEM5 timing model for shatr — is exactly the load-bearing concern. The paper provides a reasonable architectural direction, a correctness check against NIST vectors, and an FPGA resource prototype, but the performance claim rests on a self-built GEM5 model whose instruction latency, pipeline behavior, and state-transfer costs are not disclosed. This does not require rejecting the paper; it means the current conditional verdict is appropriate. The proposed concrete test would settle whether the 8.02x/46.31x figures survive once the timing model is made explicit and varied across realistic values.","tokens_in":8530,"tokens_out":3948,"duration_ms":43339,"concrete_test":"Re-run the GEM5 benchmark (e.g., SHA-224 short, RISC-V-optimized baseline, Table I) while varying the shatr instruction latency/occupancy in the custom execution unit from 1 to 2, 5, and 10 cycles, and add the measured cycle cost of loading/storing 200 bytes of state through standard 64-bit load/store instructions per absorption block. If the resulting speedup changes by more than ~20% from the reported 8.02x/46.31x, the headline numbers are sensitive to the unspecified timing model. Also, inspect the exact GEM5 patch/configuration to confirm the published latency and state-transfer settings.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central performance claim comes from a custom GEM5 RISC-V model, but it never states how many cycles the shatr instruction occupies in the execute/memory stages, whether it is fully pipelined or blocks the pipeline, or how the 200-byte internal state is transferred into and out of the dedicated registers using 'standard CPU instructions' (Sections III and IV.B). Table I reports total execution cycles, but every one of those cycles depends on this undisclosed timing and data-movement cost. If shatr is modeled as a one-cycle instruction with zero-cost state transfer, the speedups could be materially inflated. The FPGA prototype validates only area and 50 MHz timing, not the speedup. Additionally, Section III introduces 200 bytes of dedicated internal flip-flops, while Section IV.B says 'No additional registers ... were applied into ISA or CPU'; the GEM5 cost of moving state across that ambiguous boundary is exactly where cycles could hide. This concern is load-bearing because it is the only evidence for the headline speedups.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a custom RISC-V instruction named shatr that executes one round of the Keccak-f permutation as combinational logic in a dedicated execution unit, with a 200-byte internal state buffer. The authors evaluate the design in a custom cycle-accurate GEM5 RISC-V model against two SHA-3 software distributions and report speedups of up to 8.02x and 46.31x, plus an FPGA prototype on CV A6 showing a 15.09% flip-flop and 11.51% LUT increase. The central performance claim rests on the cycle count of shatr and the cost of moving state between the CPU datapath and the internal state buffer, neither of which is reported.","tokens_in":8861,"tokens_out":4511,"duration_ms":41923,"significance":"If the performance numbers are accurate, the paper addresses a relevant and under-explored topic: direct microarchitectural integration of SHA-3 as an ISA extension rather than as a coprocessor. The FPGA synthesis results (Table II) are concrete and give independent evidence that the hardware overhead is modest and the 50 MHz timing target is met. However, the paper does not provide enough information to reproduce or verify the simulation-based speedups. The missing timing model for the custom instruction is load-bearing, and the speedup values in Section V.A are not consistent with the cycle counts in Table I. As a result, the central contribution is currently not substantiated, although the issues are addressable with additional experimental detail.","major_comments":[{"comment":"The GEM5 timing model for shatr is never described. The paper reports total execution cycles in Table I but does not state the instruction latency, pipeline occupancy (whether shatr is pipelined, multi-cycle, or blocking), or the cycle cost of transferring the 1600-bit state between the 200-byte internal registers and the standard RISC-V datapath. Section III says the internal registers are 'managed exclusively through standard CPU instructions', but standard RISC-V instructions cannot address a 200-byte internal file unless new addressing modes or memory-mapped access are defined. Since every cycle count in Table I depends on these undisclosed parameters, the headline 8.02x and 46.31x speedups are not reproducible and could be materially inflated if shatr is modeled as a single-cycle instruction with zero-cost state transfer.","section":"Section III and IV.B"},{"comment":"The claimed maximum speedups do not match the paper's own cycle data. From Table I, the RISC-V distribution speedup is about 8.62x for SHA-384 long input (1562.557e7/181.221e7), not 8.02x. For the Keccak distribution, the SHA-256 long input speedup is about 64.79x (31313.550e7/483.317e7), while the claimed maximum is 46.31x. Also, the phrase 'average improvements of up to' is ambiguous: it does not state whether the values are arithmetic means, geometric means, or maxima across configurations. The text and Table I must be reconciled, and the exact definition of the reported speedup must be given.","section":"Section V.A, Table I"},{"comment":"There is an internal contradiction about additional registers. Section III introduces 200 bytes of dedicated internal flip-flops inside the execution unit to buffer the Keccak state. Section IV.B then states 'No additional registers, features or optimizations were applied into ISA or CPU' and says 'Customized vector-based registers are exclusively employed to connect the proposed shatr instruction with the combinational logic of the Keccak-f Execution Unit on GEM5.' If the internal registers are part of the execution unit and are not ISA-visible, the mechanism by which standard CPU instructions load and store the 200-byte state must be explained. If they are visible or accessed via some new mechanism, that contradicts the claim that no registers were added to the ISA. This ambiguity directly affects the measured cycle counts and must be resolved.","section":"Section III vs Section IV.B"}],"minor_comments":[{"comment":"The claim of being the 'first microarchitectural study of SHA-3 instruction integration directly into CPU datapath' is too strong given the cited prior work on ASIPs (Ref. [8]) and vector ISA extensions for Keccak (Ref. [13]). Please temper the novelty claim or provide a clearer comparison.","section":"Section I"},{"comment":"The phrase 'this unit recursively operates on a 200-byte data chunk' is misleading; the unit implements one combinational Keccak round, not a recursive operation. Also, 'with vectorisation, parallel read/write capabilities are achieved' is unclear because the baseline RISC-V core has no vector ISA extension.","section":"Section III"},{"comment":"The sentence 'it partially supports implementation as pure combinational logic' is vague. One round is combinational, and 24 rounds can be unrolled or iterated; please state precisely what is meant by 'partially'.","section":"Section II.A"},{"comment":"The GEM5 memory configuration is given as '8GB DDR3 with 1600 MT/s and 8 banks', but the CPU core model (in-order vs out-of-order, pipeline width, issue rate) is not described. This is needed to assess whether the baseline cycles are representative.","section":"Section IV.B"},{"comment":"The statement 'the integration of the custom instruction results in approximately 60% ALU instructions' is hard to interpret without the absolute instruction counts for the custom configuration. Also, Figures 4-6 are not referenced precisely in the text; please add explicit references.","section":"Section V.A"}],"recommendation":"major_revision","confidential_remarks":"The discrepancy between the claimed speedup bounds and the numbers directly computable from Table I is more than a cosmetic issue; it suggests the reported performance analysis needs a careful audit. The authors should be asked to provide the missing GEM5 timing parameters, the state-transfer mechanism, and corrected speedup statistics. If those cannot be supplied, the empirical performance claim should be withdrawn or downgraded."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the short version. The paper is the first I know to put an entire Keccak-f round into a RISC-V datapath as a single instruction, with a dedicated 200-byte state buffer, and the CV A6 FPGA numbers make the area story credible: 15% more flip-flops, 11.5% more LUTs, same 50 MHz. That alone is worth a read for anyone thinking about crypto instruction sets.\n\nWhat the paper does well: it modifies the RISC-V toolchain to accept shatr, validates hash outputs against NIST vectors, runs a RISC-V-optimized SHA-3 implementation and the Keccak reference implementation, and reports instruction-count breakdowns per round. The design goal — accelerate the permutation round, leave padding/squeezing alone — is sensible and honestly stated. The authors also acknowledge that the RISC-V-optimized baseline is the fairer comparison.\n\nThe soft spot is the one your note flagged, and it is load-bearing. The GEM5 speedups are computed from total cycle counts, but the paper never reports the shatr instruction's latency, whether it blocks the pipeline, or how the 200-byte state gets in and out. Section III says dedicated internal registers are managed by standard instructions, Section IV.B says no additional registers were applied into ISA or CPU. Those two sentences do not reconcile, and the transfer cost is exactly where the reported speedups could hide. If shatr is modeled as one cycle with zero-cost moves, the 46x number would be inflated. The FPGA result proves feasibility and area, not performance.\n\nTwo more minor points: the 46.31x is against the Keccak reference implementation that is not RISC-V-optimized; 8.02x against the RISC-V-optimized code is the representative headline. And the paper includes figures with no content in the version I read — instruction breakdown figures are referenced but not visible, so I could not check the details. Also, no artifacts are released; the whole timing model is a black box.\n\nBottom line: the microarchitecture idea is solid and the hardware cost data is real. The performance numbers need to be re-derived with a disclosed timing model. This is a paper for CPU architect readers, and it deserves a serious referee, but only after a major revision that reports the shatr timing and resolves the register ambiguity.","headline":"A genuinely new SHA-3 round-instruction design with credible area cost, but the speedup numbers rest on a GEM5 timing model that is never disclosed.","tokens_in":9310,"tokens_out":2570,"would_cite":false,"duration_ms":28131,"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":"A custom RISC-V instruction performing one Keccak-f round in hardware claims SHA-3 speedups of 8x to 46x with modest area overhead.","keywords":["SHA-3","Keccak-f","RISC-V","custom instruction","microarchitecture","GEM5 simulation","FPGA prototyping","cryptographic acceleration"],"falsifier":"Instrument the GEM5 model to count cycles spent in shatr versus cycles spent moving state into and out of the 200-byte buffer, and rerun the two SHA-3 benchmarks with shatr priced at a realistic multicycle latency plus explicit state-transfer instructions. If the resulting speedups drop well below 8.02x and 46.31x, the headline gains are an artifact of free internal-buffer access.","tokens_in":8470,"feed_emoji":"🔐","tokens_out":6186,"duration_ms":62821,"temperature":0.7,"pith_summary":"The paper proposes adding one custom instruction, named shatr, to the RISC-V ISA. Each execution of shatr performs a full Keccak-f permutation round in hardware using combinational logic and a dedicated 200-byte internal state buffer. In cycle-accurate GEM5 simulation, replacing the software Keccak round loop with 24 shatr executions cuts execution cycles by up to 8.02x for a RISC-V-optimized SHA-3 and 46.31x for the Keccak team's reference software. An FPGA prototype of the modified CV A6 core reports a 15.09% increase in flip-flops and an 11.51% increase in LUTs with no change to the 50 MHz clock rate. The paper's central claim is that SHA-3 acceleration belongs inside the CPU pipeline as an instruction, not only in coprocessors.","feed_headline":"One custom instruction speeds SHA-3 by up to 46x","feed_subtitle":"One Keccak-f round becomes combinational hardware on RISC-V, cutting cycles while adding only ~15% logic.","key_machinery":"The shatr instruction together with the Keccak-f Execution Unit: a custom RISC-V instruction whose execution-stage unit contains the combinational logic for one full Keccak-f round (theta, rho/pi, chi, iota) plus a 200-byte internal flip-flop buffer. Executing shatr 24 times completes a full permutation, and the internal buffer avoids repeatedly spilling the 1600-bit state to memory or general-purpose registers.","core_discovery":"The central discovery is that the Keccak-f permutation, usually treated as a coprocessor or software workload, fits into an ordinary RISC-V pipeline as a custom instruction. The authors implement shatr so that one instruction completes one of the 24 Keccak-f rounds; the round's theta, rho-pi, chi, and iota logic is a combinational block, and a 200-byte register file inside the execution unit holds the state across rounds. Standard CPU instructions move data into and out of this internal buffer, so no new memory model is needed. Benchmarking two SHA-3 software distributions with NIST test vectors shows large cycle reductions, and the FPGA prototype shows the added logic costs less than a 16%","pith_inferences":["The reported speedups are sensitive to baseline quality: the 46.31x figure comes from the Keccak reference implementation, which the paper describes as memory-heavy on RISC-V, so a real deployment should expect gains closer to the 8.02x of the RISC-V-optimized baseline.","The internal 200-byte buffer is not part of the architectural register file, so an operating system context switch would have to save and restore it; the paper's stability tests do not measure this cost.","The paper reports no per-instruction latency or pipeline occupancy for shatr, so if a real high-frequency core needs multiple cycles or extra state-transfer instructions, the headline speedups would shrink.","Because any sponge construction built on Keccak-f (for example cSHAKE or KangarooTwelve) invokes the same permutation, the instruction could accelerate those hashes at no extra hardware cost, though the paper benchmarks only the NIST SHA-3 variants."],"forward_implications":["Software changes stay small: only the Keccak round loop is replaced by 24 shatr calls, so existing SHA-3 code ports with assembly-level edits rather than a rewrite.","The same instruction serves all SHA-3 output sizes (SHA-224/256/384/512), since they share the Keccak-f permutation; the paper's table shows gains across all eight configurations.","A processor with shatr keeps its clock rate unchanged in the FPGA prototype (50 MHz), so the added logic does not push the critical path on this implementation.","The design is portable beyond this prototype: the required toolchain changes span assembler, linker, compiler, and simulator, and the authors state the approach can be tailored to any CPU architecture."],"supporting_citations":[{"why":"Supplies the RISC-V-optimized SHA-3 software baseline that the 8.02x speedup is measured against.","marker":"[17]"},{"why":"Supplies the standalone Keccak reference implementation that the 46.31x speedup is measured against.","marker":"[18]"},{"why":"Provides the NIST test vectors used to validate bit-level correctness of the custom instruction.","marker":"[19]"},{"why":"Defines the CV A6 RISC-V core onto which the shatr instruction is integrated for FPGA prototyping.","marker":"[20]"},{"why":"Provides the specific CV A6 v5.3.0 release used for the 50 MHz timing and resource comparison.","marker":"[23]"},{"why":"RISC-V unit tests confirm the custom instruction does not break ISA compliance.","marker":"[21]"},{"why":"MiBench workloads are used to confirm stable performance under computational load.","marker":"[22]"}],"fun_headline_variants":["SHA-3 as a single RISC-V instruction: up to 46x faster","Custom SHA-3 instruction on RISC-V hits 46x speedup","One instruction, 46x SHA-3 boost on RISC-V","RISC-V gets SHA-3 instruction: 46x Keccak speedup","46x SHA-3 speedup with a single custom instruction"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The speedups rest on the simulator's assumed cost of the new instruction: the paper never states how many cycles a single shatr takes or how many cycles are spent moving the 200-byte state into and out of the internal buffer, and the authors wrote the GEM5 model themselves. If that transfer is expensive in a real pipeline, the measured speedups shrink.","fun_headline_variants_meta":{"raw":{"variants":["SHA-3 as a single RISC-V instruction: up to 46x faster","Custom SHA-3 instruction on RISC-V hits 46x speedup","One instruction, 46x SHA-3 boost on RISC-V","RISC-V gets SHA-3 instruction: 46x Keccak speedup","46x SHA-3 speedup with a single custom instruction"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000419,"raw_usage":{"total_tokens":2019,"prompt_tokens":797,"completion_tokens":1222,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":541,"completion_tokens_details":{"reasoning_tokens":1121}},"tokens_in":541,"tokens_out":1222,"duration_ms":9514,"temperature":1.0,"reasoning_tokens":1121,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T14:55:13.758991+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument the GEM5 model to count cycles spent in shatr versus cycles spent moving state into and out of the 200-byte buffer, and rerun the two SHA-3 benchmarks with shatr priced at a realistic multicycle latency plus explicit state-transfer instructions. If the resulting speedups drop well below 8.02x and 46.31x, the headline gains are an artifact of free internal-buffer access.","supporting_citations":[{"cited_title":"Risc-v cryptography extensions standardisation work,","cited_arxiv_id":null,"evidence_quote":"Supplies the RISC-V-optimized SHA-3 software baseline that the 8.02x speedup is measured against."},{"cited_title":"Keccakcodepackage,","cited_arxiv_id":null,"evidence_quote":"Supplies the standalone Keccak reference implementation that the 46.31x speedup is measured against."},{"cited_title":"Cryptographic algorithm validation program: Secure hashing,","cited_arxiv_id":null,"evidence_quote":"Provides the NIST test vectors used to validate bit-level correctness of the custom instruction."},{"cited_title":"The cost of application-class processing: Energy and performance analysis of a linux-ready 1.7-ghz 64-bit risc- v core in 22-nm fdsoi technology,","cited_arxiv_id":null,"evidence_quote":"Defines the CV A6 RISC-V core onto which the shatr instruction is integrated for FPGA prototyping."},{"cited_title":"Cva6 v5.3.0,","cited_arxiv_id":null,"evidence_quote":"Provides the specific CV A6 v5.3.0 release used for the 50 MHz timing and resource comparison."},{"cited_title":"Risc-v tests,","cited_arxiv_id":null,"evidence_quote":"RISC-V unit tests confirm the custom instruction does not break ISA compliance."},{"cited_title":"Mibench: A free, commercially represen- tative embedded benchmark suite,","cited_arxiv_id":null,"evidence_quote":"MiBench workloads are used to confirm stable performance under computational load."}],"review_version":1}