{"id":"e3ffc037-573d-4e3b-b594-ebc52ef74360","arxiv_id":"2602.22229","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"A GPU-integrated 16×8 systolic modulo-multiply-accumulate unit with Barrett reduction is claimed to speed CKKS NTT and base conversion by roughly 1.6–2.1x at 2.4% area cost.","lead":"FHECore adds a small systolic unit to GPU streaming multiprocessors to speed up the two most expensive pieces of fully homomorphic encryption (FHE): the number-theoretic transform and base conversion. The paper reports 1.5–2.1x simulated speedups on encrypted workloads with 2.4% area overhead, but the design assumes 32-bit modulo arithmetic that standard CKKS ciphertext moduli exceed.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"FHECore's 32-bit PE cannot handle the 60-bit RNS moduli of its own CKKS benchmarks, invalidating the no-decomposition NTT claim.","rationale":"The reader's weakest_assumption correctly identifies the 32-bit operand width as the fatal gap. The paper's own Table V parameters (logQP=1743, L=26) imply radix-2^32 cannot represent the residues; standard CKKS-RNS uses moduli around 55–60 bits. Section IV-C fixes the PE at 32-bit operands, and Section V-A claims no decomposition is needed. These two statements are mutually inconsistent for the evaluated workloads. If the unit were widened to 60 bits, the 2.4% area estimate would also change. The manual trace-insertion methodology (§IV-F) is a second serious weakness, but it is a reproducibility/validation gap that could conceivably be patched; the datapath width is a fundamental mismatch that no trace edit can fix. Therefore the central performance claims are unsupported, and the appropriate verdict is REJECT. I found no independent evidence (e.g., machine-checked proofs, released artifacts) that would offset this concern.","tokens_in":24634,"tokens_out":3835,"duration_ms":39381,"concrete_test":"Compute the RNS limb width for Table V: with L=26, dnum=3, and the extended moduli, a lower bound on the limb count is L+1+dnum = 30, giving logQP/30 ≈ 58 bits per modulus. Then instrument the FIDESlib NTT kernels used in §VI to count, for each coefficient, how many 32-bit limb operations would be needed under a Barrett-based multi-limb scheme (e.g., 2-limb or 3-limb). Recompute Table VI with FHEC instructions issued per limb rather than per 16×16 tile. If the instruction-count reduction falls below the claimed 2.41×/1.96× (or the per-tile FHEC count rises by ≥2×), the headline speedups are not supported.","verdict_should_be":"REJECT","load_bearing_attack":"The central value proposition is that NTT and base conversion reduce to one wide-precision modulo-MAC instruction, eliminating decomposition and intermediate reduction. But the PE datapath is explicitly 32-bit (§IV-C: 'computes a·b mod q over 32-bit operands'), while the evaluation's CKKS parameters (Table V: logQP=1743, L=26, dnum=3) imply RNS moduli of roughly 55–60 bits. A 32-bit multiplier cannot form the product of two such residues, let alone reduce modulo a 60-bit prime in a single step. The paper never explains how a 32-bit unit handles these operands; §V-A's assertion that FHECore runs NTT 'without any decomposition' is therefore unsupported for the stated workloads. If FHECore can only process 32-bit limbs, every modular multiply in the NTT requires multiple FHEC instructions or chunked operands, eroding the instruction-count reduction that underpins all speedup claims. This is not a minor parameter tweak; it is the load-bearing assumption of the entire evaluation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"FHECore proposes a specialized systolic-array functional unit, integrated into each Streaming Multiprocessor of an NVIDIA A100, to accelerate CKKS FHE workloads. The paper's key insight is that Number Theoretic Transforms and base conversion are modulo-linear transformations, allowing both to run on a common modulo-multiply-accumulate hardware unit. The authors add a new FHEC instruction, evaluate it by editing SASS traces and replaying them in Accel-Sim, and report geometric-mean dynamic instruction-count reductions of 2.41x for CKKS primitives and 1.96x for end-to-end workloads, translating to speedups of 1.57x and 2.12x, respectively, with a 2.4% area overhead estimated from RTL synthesis.","tokens_in":24914,"tokens_out":4672,"duration_ms":48736,"significance":"If the central claim were valid, FHECore would be a notable contribution: it would show that a small, area-efficient addition to commodity GPUs could roughly double FHE throughput while preserving the GPU programming model. The paper has genuine strengths: the RTL synthesis flow with ASAP7 and SiliconCompiler is a concrete, reproducible area estimate; the comparison to GME's 26.6% area overhead is informative; and the mapping of NTT/base conversion to a common modulo-linear formulation is conceptually appealing. However, the evaluation rests on two load-bearing assumptions that are not supported by the manuscript: the 32-bit datapath described in §IV-C cannot handle the ~55-60-bit RNS moduli implied by the paper's own CKKS parameters (Table V), and the performance results come from manually edited traces with an assumed 44-cycle latency rather than a validated integration model. These issues undermine the central speedup and instruction-count claims.","major_comments":[{"comment":"The PE is specified as computing 'a·b mod q over 32-bit operands' (§IV-C), and §V-A asserts that the NTT can run 'without any decomposition or intermediate reduction steps.' However, the benchmarks in Table V use logQP=1743, L=26, and dnum=3, which for standard CKKS-RNS implies individual moduli of roughly 55-60 bits. A 32-bit multiplier cannot even form the product of two such residues, let alone reduce modulo a 60-bit prime in one step. The manuscript nowhere states that the workloads use 32-bit moduli nor describes multi-limb handling. Consequently, the one-FHEC-instruction mapping to 16 or 64 INT8 Tensor Core instructions collapses for the stated parameters, invalidating the instruction-count and speedup numbers.","section":"§IV-C, §V-A, Table V"},{"comment":"The performance evaluation is based on manually inserting FHEC instructions into NVBit-collected traces and assigning them a 44-cycle latency, down from the 64 cycles used for Tensor Core instructions. This is not a faithful simulation of integrating a new functional unit: there is no validation of the register-file port sharing, warp-scheduler interaction, or issue constraints, and the latency reduction is an input assumption rather than a measured or modeled property of the complete SM. The resulting speedups are therefore partly definitional. The paper should at least provide a sensitivity analysis over FHEC latency and a detailed account of how FHEC operations interact with the existing pipeline before claiming end-to-end speedups.","section":"§VI-A"},{"comment":"The paper claims both that 'no modifications are required in either the compiler stack or the instruction stream sequence' (§IV-B) and that the closed-source nvcc backend prevents direct SASS insertion, requiring manual trace editing (§IV-F). More importantly, the occupancy and IPC improvements in Figure 7 are reported without any microarchitectural mechanism beyond replacing instructions with shorter-latency FHEC ops. Since non-FHE workloads are never evaluated, the repeated claim that FHECore 'does not compromise general-purpose GPU performance' is unsupported. The authors should either remove that claim or provide evidence, such as running standard GPU benchmarks with the FHECore unit present but idle.","section":"§IV-B, §IV-F, Fig. 7"}],"minor_comments":[{"comment":"Typo: 'inuring' should be 'incurring'.","section":"Abstract"},{"comment":"The reported geometric-mean instruction-count reduction for end-to-end workloads is 1.96x, but computing the geometric mean from Table VI (Bootstrap 2.12x, LR 2.68x, ResNet 1.89x, BERT-Tiny 1.71x) gives approximately 2.07x. Please reconcile the numbers.","section":"Table VI and Abstract/Conclusion"},{"comment":"The notation 'a·b mod q over 32-bit operands' is ambiguous: specify whether q is a 32-bit modulus, whether the product is truncated before reduction, and whether signed or unsigned operands are supported. This matters for the Barrett reduction implementation.","section":"§IV-C"},{"comment":"The proposed PTX instruction format and the SASS 'FHEC.16816' instruction are described only at a high level. Clarify how the 16x8x16 tile maps to 32-bit operands in the register file, especially since WMMA fragments for INT8 have a different layout.","section":"§IV-F"},{"comment":"Comparing latencies across different GPUs (RTX 4090, A100) and different libraries is informative but should be accompanied by a statement about architectural differences and clock speeds to avoid implying a head-to-head comparison.","section":"Table VII"}],"recommendation":"reject","confidential_remarks":"The 32-bit PE vs. ~60-bit modulus mismatch is explicitly present in the manuscript and is not a matter of interpretation. The evaluation method of editing traces and assuming a 44-cycle latency is also insufficient for the strength of the claims. I see no way to repair these issues within the manuscript's current scope without a substantially new design and evaluation. Rejection is appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"FHECore is a sensible idea with an honest RTL-based area number, but the performance story doesn't hold as written. What's new: a 16x8 systolic array of Barrett-reduction PEs that treats NTT and base conversion as modulo-linear matrix ops, plus a WMMA-style fhe_sync intrinsic. The observation itself isn't novel — TensorFHE/WarpDrive/NEO already formulate NTT this way — but the specific hardware datapath with integrated Barrett reduction is a legitimate design point, and the ASAP7 synthesis is a real artifact. I believe the 2.4% area figure.\n\nThe soft spots are serious. The PE is explicitly 32-bit ('computes a·b mod q over 32-bit operands', §IV-C), and the benchmarks use CKKS parameters (Table V) with logQP≈1743, L=26, dnum=3, which puts individual RNS moduli around 55–60 bits. The paper never explains how a 32-bit unit handles those residues. §V-A's claim that FHECore runs NTT 'without any decomposition or intermediate reduction steps' is therefore unsupported for the stated workloads. If the unit really is 32-bit, every modular multiply needs multiple passes or limb decomposition, eroding the single-instruction mapping that drives all the speedup numbers. This is the load-bearing assumption, and it's unstated and likely false.\n\nThe evaluation won't do as evidence either. The FHEC instructions are manually inserted into Accel-Sim traces, with a 44-cycle latency assumed rather than derived. That's not a faithful model of a real integration. There's no comparison against GME, the closest prior hardware work, and the instruction-count reductions are partly definitional: replacing 16 or 64 INT8 tensor-core ops with one FHEC trivially cuts dynamic count, but the speedup depends on the latency you assign. There's also a small internal inconsistency in the geometric means (Table VI gives ~2.07× for end-to-end, abstract says 1.96×). Minor, but it adds noise.\n\nNone of this means the idea is dead. A 64-bit datapath or an explicit multi-limb scheme, a cycle-accurate simulator integration, and a GME baseline would make the claims testable. The paper is clear and well-written, the RTL artifact is reproducible, and the authors are transparent about the trace-insertion compromise. It deserves a serious referee — the central hardware concept is worth engaging with even if the current evidence is inadequate. I'd want to see the revision before trusting the speedups, and I wouldn't cite the numbers today.","headline":"A plausible architecture with a credible area model, but the evaluation builds on a 32-bit datapath that doesn't fit the paper's own 60-bit CKKS moduli.","tokens_in":25503,"tokens_out":3755,"would_cite":false,"duration_ms":33696,"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 2.4%-area GPU unit that natively performs modulo-linear transformations could halve FHE bootstrapping latency and roughly double end-to-end encrypted workload speed.","keywords":["fully homomorphic encryption","CKKS","GPU microarchitecture","number theoretic transform","base conversion","systolic array","Barrett reduction","instruction count"],"falsifier":"Run a cycle-accurate trace of the bootstrap kernel using the stated CKKS parameters (logQP=1743) and count how many FHEC instructions are actually required when the 32-bit datapath is used. If any operand needs limb decomposition or extra reduction steps, the dynamic instruction count will not shrink by 2.41x/1.96x and the 50% bootstrapping speedup will not reproduce.","tokens_in":24550,"feed_emoji":"🔐","tokens_out":7065,"duration_ms":59190,"temperature":0.7,"pith_summary":"The paper argues that the two dominant kernels of CKKS fully homomorphic encryption—the Number Theoretic Transform and base conversion—are both modulo-linear transformations, and therefore can be executed on a single wide-precision modulo multiply-accumulate unit rather than as long chains of low-precision GPU instructions. It proposes FHECore, a small 16x8 systolic array placed in each GPU streaming multiprocessor, with built-in Barrett reduction and a new single instruction that consolidates many arithmetic and predication steps. Simulation on an A100-style GPU across four CKKS workloads shows a geometric-mean instruction-count reduction of 2.41x for primitives and 1.96x for end-to-end programs, translating to speedups of 1.57x and 2.12x, including a 50% drop in bootstrapping latency, all at 2.4% die-area overhead. If correct, this gives GPU-based FHE a path to practical acceleration without the time-to-market and flexibility costs of ASICs.","feed_headline":"New GPU unit halves FHE bootstrapping latency for 2.4% area","feed_subtitle":"Targets the two kernels behind 70% of CKKS runtime, yielding up to 2.12x speedups at low area cost.","key_machinery":"FHECore is a 2D systolic array organized as a 16x8 grid of processing elements, each computing a·b mod q with 32-bit operands; a six-stage pipeline and Barrett reduction module sit in every PE. The array uses output-stationary dataflow, completing a 16x8x16 modulo matrix multiplication in 44 cycles, and shares register-file ports with the existing tensor-core units. The load-bearing idea is the modulo-linear formulation: the NTT becomes a product of twiddle-factor matrices and base conversion becomes a mixed-moduli matrix-matrix product, so one instruction (FHEC.16816.S32) can replace the decompose–reassemble–reduce sequence that tensor-core approaches require.","core_discovery":"The central claim is that the CKKS bottleneck on GPUs is a datatype mismatch, not parallelism: NTT and base conversion together account for more than 70% of runtime and are currently implemented by splitting wide integers into INT8 chunks for tensor-core matrix multiply, then reassembling and reducing them. The paper shows both kernels can be formulated as modulo matrix multiplications, so a 16x8 systolic array of processing elements that each compute a·b mod q on 32-bit operands, with Barrett reduction embedded, can execute them as a single instruction. In the paper's trace-driven simulation, this new instruction—issued from the same register-file ports as tensor-core operations—cuts dynami","pith_inferences":["The CKKS parameters in the paper (logQP=1743, L=26) imply RNS moduli of about 55–60 bits, not 32 bits; the paper never states that its workloads use 32-bit moduli. If the modulo multiply-accumulate unit must handle larger residues via limb decomposition, the single-instruction mapping and the reported 2.41x/1.96x instruction-count reductions are unlikely to hold as reported.","The evaluation inserts FHEC instructions into traces manually because the compiler backend is closed; the real-world speedup depends on the compiler generating these instructions without extra register pressure or scheduling overhead, which the paper does not demonstrate.","A concrete next step would be to build a small FPGA prototype of the 16x8 FHECore and run NTT and base conversion with both 32-bit and 55-bit moduli, measuring whether the 44-cycle latency and instruction-count compression persist. This would separate the benefit of native modulo arithmetic from the benefit of the specific operand width."],"forward_implications":["Bootstrapping latency drops by roughly half in simulation (from 314.67 ms to 163.90 ms), which directly extends the usable depth of CKKS computations.","A single programmer-level intrinsic (fhe_sync) that mirrors existing matrix-multiply intrinsics lets GPU FHE libraries adopt the unit without a new compiler or ISA.","Because the same two kernels dominate BFV and BGV, and TFHE can be expressed with NTTs, the unit would likely accelerate other FHE schemes, not just CKKS.","The 2.4% area overhead (and an estimated 1.5% on newer GPUs) keeps the design within reticle limits, making it a physically feasible drop-in SM extension.","Non-FHE GPU workloads are unaffected because FHECore shares register ports with tensor cores and only activates when FHEC instructions are issued; the paper argues FHE and plaintext ML workloads are disjoint in practice."],"fun_headline_variants":["GPU unit targets FHE datatype mismatch: 2.12x speedup","Modulo-linear tricks cut CKKS bootstrapping latency by half","FHECore: 2.4% GPU area buys 2x FHE speedup","Redesigning GPU SM for wide-integer FHE: 50% less bootstrapping","NTT and base conversion mapped to one wide-modulo unit"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The design assumes every residue value in the evaluated CKKS workloads fits in the 32-bit modulo multiply-accumulate datapath, so no limb decomposition or intermediate reduction is needed; if the actual moduli are 55–60 bits, the single-instruction mapping collapses.","fun_headline_variants_meta":{"raw":{"variants":["GPU unit targets FHE datatype mismatch: 2.12x speedup","Modulo-linear tricks cut CKKS bootstrapping latency by half","FHECore: 2.4% GPU area buys 2x FHE speedup","Redesigning GPU SM for wide-integer FHE: 50% less bootstrapping","NTT and base conversion mapped to one wide-modulo unit"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000666,"raw_usage":{"total_tokens":2956,"prompt_tokens":906,"completion_tokens":2050,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":650,"completion_tokens_details":{"reasoning_tokens":1945}},"tokens_in":650,"tokens_out":2050,"duration_ms":11762,"temperature":1.0,"reasoning_tokens":1945,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T02:54:35.226852+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a cycle-accurate trace of the bootstrap kernel using the stated CKKS parameters (logQP=1743) and count how many FHEC instructions are actually required when the 32-bit datapath is used. If any operand needs limb decomposition or extra reduction steps, the dynamic instruction count will not shrink by 2.41x/1.96x and the 50% bootstrapping speedup will not reproduce.","supporting_citations":[],"review_version":1}