{"id":"e7500535-ccd2-46fa-b712-fa23fcdc311e","arxiv_id":"2506.15070","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"SPiME is a parameterized FPGA architecture for parallel AES-128 encryption in processing-in-memory arrays, claiming sub-5% logic utilization at 4096 units and over 25 Gbps throughput.","lead":"SPiME is a Verilog design that places AES-128 encryption cores next to processing-in-memory controllers on FPGAs, scaling to thousands of parallel units. The paper claims low resource use and over 25 Gbps throughput, but the reported numbers are internally inconsistent.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported sub-5% LUT utilization at 4096 AES units implies ~12 LUTs per AES core, which is physically impossible; the scalability claim rests on an unverified synthesis result.","rationale":"The central claim requires that each of 4096 parallel PiM units contain a full AES-128 datapath and controller while consuming, on average, about 12 LUTs per unit on the U55C. This is arithmetically incompatible with the architecture described in Section III: an AES S-box alone, whether implemented in LUTs or BRAM, consumes far more than this per-unit budget. The reader's weakest_assumption identifies exactly this load-bearing point, and I agree with it. The paper provides no synthesis reports, netlists, bitstreams, or per-unit resource tables that could resolve the contradiction; Section V even lists real hardware benchmarking as future work. A secondary internal inconsistency also exists in the throughput model: Equation 2 converts bits per microsecond to Gbps by dividing by 10^6 rather than 10^3, and the stated 'over 23 Gbps at 4096 units' cannot be reproduced from the stated block size and latency. However, the resource-utilization mismatch is the more fundamental problem because it undermines the architecture's scalability and efficiency value proposition directly. The modular AES-in-PiM design idea is reasonable, and the submodule descriptions are internally coherent, but the quantified claims are not supported by the evidence presented. I would keep the reader's REJECT verdict unchanged.","tokens_in":8870,"tokens_out":5237,"duration_ms":55854,"concrete_test":"Independently synthesize one PiM unit (pim_controller + aes_core with sub_bytes, shift_rows, mix_columns, and key expansion) on xcu55c-fsvh2892 and report post-implementation LUT, FF, and BRAM counts; multiply by 4096 and compare with the device totals (1,304K LUTs, 2,607K FFs, 2016 BRAMs). If per-unit LUTs exceed ~12, the claimed 3.65% utilization for 4096 units cannot be correct; if BRAM per unit exceeds ~36 Kbit, the 4096-unit array also exceeds available BRAM. This test directly settles whether the reported synthesis is compatible with the described architecture.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section IV.B reports 3.65% LUT utilization for 4096 PiM units on U55C/U280. These devices have 1,304K LUTs, so 3.65% is about 47.6K LUTs, i.e., roughly 11.6 LUTs per PiM including the AES-128 core described in Section III. That budget cannot cover even one 8-bit AES S-box, let alone the 16 S-boxes, MixColumns, ShiftRows wiring, key expansion, and the PiM controller. Mapping S-boxes to block RAM does not help: 16 S-boxes per core need about 32 Kbit per unit, and 4096 units need ~128 Mbit of BRAM, while the U55C has only ~72 Mbit of BRAM. The reported numbers therefore imply that the synthesized design did not contain the full AES datapath, or that the utilization was measured on stubs, or that the units shared a single AES core (which would destroy the parallel-throughput claim). The paper's central scalability assertion rests entirely on this unverified synthesis result. The paper itself lists 'real hardware benchmarking' as future work (Section V), so no independent measurement is available. Until per-unit resource data or a synthesis report is released, the sub-5% scalability claim is physically unsupported.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents SPiME, an FPGA-based architecture that arrays Processing-in-Memory (PiM) units, each comprising an AES-128 core and a lightweight controller. The design is parameterized by NUM_PIMs, and the paper claims it scales to 4,096 units while consuming less than 5% of key FPGA resources on high-end devices, with throughput exceeding 25 Gbps and deterministic latency. The paper describes the modules, provides latency and throughput formulas, and reports resource-utilization statistics for five FPGA platforms.","tokens_in":9118,"tokens_out":9166,"duration_ms":81198,"significance":"A scalable, configurable AES engine with a per-unit overhead of a few LUTs would be a valuable building block for secure processing-in-memory at the edge, and the claimed portability across FPGA families is appealing. The paper also has useful strengths: the modular Verilog organization, the parameterized instantiation, and the explicit goal of providing predictable, constant-time latency. However, the quantitative claims are not supported by the evidence in the manuscript: the reported utilization contradicts the standard resource cost of AES-128, the throughput and latency equations contain unit errors, and no hardware measurements are provided. Because the central scalability and performance assertions rest on these unsupported figures, the contribution cannot currently be assessed as valid.","major_comments":[{"comment":"For 4096 PIMs on the U55C (1,304K LUTs), the reported LUT utilization of 3.65% corresponds to about 47,600 LUTs, or roughly 11.6 LUTs per PIM. A full AES-128 core with SubBytes, ShiftRows, MixColumns, key expansion, and a controller cannot be implemented in that budget; even a single 8-bit S-box typically requires dozens of LUTs or a BRAM, and 16 S-boxes per core would need on the order of 32 Kbit per unit, totaling approximately 128 Mbit for 4096 units, which exceeds the U55C's ~72 Mbit of BRAM. The sub-5% utilization claim is therefore physically implausible for the described architecture and needs a detailed synthesis report to be credible.","section":"Section IV.B, Figure 3, Table I"},{"comment":"The latency formula Latency (µs) = 1000 × (Cycles/fmax) is dimensionally incorrect. If fmax is in Hz, the conversion to microseconds is a factor of 1e6, not 1000; if fmax is in MHz, the factor 1000 is extraneous. The reported example (0.11 µs at 100 MHz for 11 cycles) corresponds to Cycles/fmax without the factor, so the printed equation contradicts the numbers used in the text.","section":"Section IV.C, Eq. (1)"},{"comment":"The throughput equation Throughput (Gbps) = (Block size / Latency (µs)) ÷ 1e6 is off by a factor of 1000: bits per microsecond must be divided by 1000 to obtain Gbps (since 1 Gbps = 1000 bits/µs), not by 1e6. Using the values implied by the text (4096 PIMs, 128-bit blocks, 0.022 µs latency), the correct throughput is about 23,800 Gbps, not 23 Gbps; the reported 23 Gbps arises only from the erroneous factor. This reveals an internal inconsistency between the architecture description and the claimed results.","section":"Section IV.D, Eq. (2)"},{"comment":"Section IV states that designs were \"synthesized and tested\" on AMD UltraScale and UltraScale+ FPGAs, yet Section V lists \"real hardware benchmarking\" as future work. No tool versions, synthesis reports, timing constraints, or measurement methodology are provided. Given the implausible resource numbers, the absence of any reproducible synthesis or hardware data leaves the central scalability and throughput claims unverified.","section":"Section IV vs. Section V"},{"comment":"The 'block size' used in the throughput evaluation is ambiguous. The AES core processes a single 128-bit block per operation, but Figure 6 is described as using a fixed block size of 1024 bits. If block size is per PIM, the total throughput should scale with NUM_PIMs in a way that is not reflected in the equation; if it is total across all PIMs, the text and the equation are inconsistent. The relationship between block size, NUM_PIMs, and latency needs to be defined unambiguously.","section":"Section III.D and Figure 6"}],"minor_comments":[{"comment":"SPiME is spelled inconsistently as 'SPiMe' in the Abstract, Section IV, and the Conclusion; use a single consistent spelling throughout.","section":"Throughout"},{"comment":"There are several typos, including 'followning' in Section III and 'Evaluational' in Section IV; the manuscript should be proofread.","section":"Section III, Section IV.A"},{"comment":"Equations (1) and (2) are referenced by number but not explicitly numbered in the displayed text; add equation numbers.","section":"Section IV.C"},{"comment":"The figures are not included in the manuscript text, and their captions are too brief to convey the block-level structure; the architecture description would benefit from complete figures with labeled components.","section":"Figures 1 and 2"},{"comment":"The AES core is described as 'pipelined,' but the FSM-based round loop described in Algorithm 2 is a sequential datapath; clarify whether the intent is round-level pipelining, block-level pipelining, or neither.","section":"Section III.C"},{"comment":"The claim that SPiME is \"the first FPGA-compatible, parameterizable PiM-based encryption core\" is not substantiated by the related-work survey; a comparison table with prior AES/PiM implementations would be more appropriate.","section":"Section V"}],"recommendation":"reject","confidential_remarks":"The reported resource utilization and throughput figures are internally inconsistent with the described architecture and with standard FPGA resource costs. In particular, the 3.65% LUT utilization at 4096 PIMs implies roughly 12 LUTs per AES-128 core, which is not physically possible, and the throughput equation is off by a factor of 1000. The paper also claims hardware testing while listing real hardware benchmarking as future work. These issues are load-bearing and cannot be resolved by a minor revision; rejection is recommended unless the authors can provide a complete, reproducible synthesis report with corrected equations and resource numbers."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nPunchline: the resource utilization numbers are the load-bearing wall, and they don't hold up. The paper reports 3.65% LUT utilization for 4096 PiM units on U55C/U280. That works out to about 11.6 LUTs per unit, including a full AES-128 core. It's not enough for a single S-box, let alone 16 of them plus ShiftRows, MixColumns, key handling, and the controller. Even if all S-boxes went into BRAM, 4096 cores would need roughly 128 Mbit of BRAM; the U55C has about 72 Mbit. Either the synthesis was of stubs, or the units share one AES core, which would destroy the parallel throughput claim. No synthesis reports are provided, and the paper itself lists 'real hardware benchmarking' as future work.\n\nThe throughput and latency equations are also off. Equation 1 multiplies cycles/fmax by 1000, which gives milliseconds, not microseconds. Equation 2 divides by 10^6 after dividing by latency in microseconds, introducing another factor of 1000 error. The text is internally inconsistent: it says over 23 Gbps at 500 MHz with 4096 PIMs in one place, and over 25 Gbps in the abstract. So the advertised 25 Gbps is not derivable from their own definitions.\n\nWhat is actually new? Not much. A parameterized array of AES cores with lightweight controllers is a modest extension over Xu et al., Iranfar et al., and Liu et al., all of which the paper itself cites. Credit where due: the Verilog structure is described clearly enough that someone could reimplement it, and the FSM descriptions are unambiguous. That's a real plus, but it doesn't compensate for the unsupported central claims.\n\nA softer issue: the AES core depends on prior work [14]–[27] without saying which RTL was used or whether S-boxes are LUT-based or BRAM-based. The related work is adequate, and self-citation is not a problem by itself.\n\nWho is this for? Someone wanting a template for a parameterized AES-in-PiM array might find the structure useful, but they should not trust the numbers. If the authors release the actual Verilog and synthesis logs, the claims could be checked. Until then, the paper is not publishable as is.\n\nRecommendation: reject. It still deserves a serious referee if it comes your way, because the architectural idea is legitimate and the flaws are checkable in review, but it needs major revision and real measurements.\n\nBest,\n[Your name]","headline":"The paper's central scalability and throughput claims don't survive contact with its own equations or with the physical limits of the FPGAs it targets; the architecture idea is reasonable, but the evidence presented is not.","tokens_in":9626,"tokens_out":4572,"would_cite":false,"duration_ms":45519,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SPiME embeds AES-128 into FPGA memory-side units, scaling to 4,096 parallel encryptors.","keywords":["FPGA","AES-128","Processing-in-Memory","Encryption","Edge Computing","Parallel Architecture","Scalability","Verilog"],"falsifier":"Synthesize the 4,096-PiM configuration on the U55C device with the full AES datapath (SubBytes S-boxes, ShiftRows, MixColumns) present in every unit and read the post-implementation LUT utilization; at under 5% of 1.3 million LUTs the budget is roughly 16 LUTs per AES core, which a complete S-box-based datapath cannot meet, so checking whether that report is produced would settle the scalability claim.","tokens_in":8654,"feed_emoji":"🔐","tokens_out":6093,"duration_ms":58193,"temperature":0.7,"pith_summary":"The paper introduces SPiME, an FPGA-based architecture that places a full AES-128 encryption core and a small controller inside each processing-in-memory (PiM) unit, so data can be encrypted in place near memory instead of being moved to a CPU. The authors argue that this modular arrangement removes the throughput bottleneck of conventional CPU-centric encryption while keeping per-unit overhead low enough to scale. They report instantiating 256 to 4,096 parallel PiM units on AMD UltraScale and UltraScale+ FPGAs, with LUT utilization below 5% on large devices at the largest configuration and throughput above 25 Gbps in optimal settings. The design's fixed 11-cycle per-block latency gives predictable, low-latency encryption that would fit latency-sensitive edge and IoT workloads.","feed_headline":"SPiME puts AES-128 beside memory, scaling to 4,096 parallel units","feed_subtitle":"An FPGA processing-in-memory design claims >25 Gbps encryption with fixed 11-cycle latency.","key_machinery":"The load-bearing mechanism is the PiM unit: a pipelined AES-128 datapath plus a small pim_controller state machine, replicated as an array under a parameterized NUM_PiMs. The controller handles start/done handshaking and routes plaintext, key, and round keys; the AES core sequences through IDLE, INIT, ROUND, and FINAL states, applying SubBytes, ShiftRows, MixColumns, and AddRoundKey with the Rijndael key schedule. This fixed 11-cycle FSM gives each unit constant latency, so array throughput is obtained by parallel replication rather than by deeper pipelining.","core_discovery":"The central claim is that a parameterized array of lightweight PiM units, each containing an AES-128 core (SubBytes, ShiftRows, MixColumns) and a minimal FSM controller, can provide scalable, in-place AES encryption on standard FPGAs without custom memory technology. Each unit runs a fixed 11-cycle encryption sequence, and the top-level NUM_PiMs parameter tiles these units across the FPGA; the paper reports that 4,096 units fit in under 5% of the logic on large UltraScale devices and that throughput scales nearly linearly with unit count and block size, exceeding 25 Gbps in batched configurations. The authors position SPiME as the first FPGA-compatible, parameterizable PiM-based AES core, in contrast to prior PiM-AES work that relied on custom DRAM or spintronic memory.","pith_inferences":["Beyond the paper, the controller/AES split suggests other ciphers could be dropped into the same PiM template, since the handshaking and data routing are cipher-agnostic.","Beyond the paper, the reported per-unit efficiency implies the array could also be used as a coarse-grained cryptographic accelerator for independent blocks, which would fit counter-mode encryption naturally; the authors do not discuss modes of operation.","Beyond the paper, the 11-cycle deterministic latency could be exploited by scheduling encryption in fixed time slots on a shared memory bus, turning latency variability into a compile-time constant."],"forward_implications":["Encryption throughput becomes a linear function of the number of units and the block size, so a designer can budget bandwidth by choosing NUM_PiMs.","The fixed 11-cycle latency makes SPiME's completion time deterministic, which suits real-time edge systems that need worst-case timing guarantees.","Because the design is plain Verilog with no custom memory technology, the same source can be retargeted across different FPGA families by changing the device part.","Batch and buffered workloads benefit most, since larger blocks amortize control and I/O overhead in the throughput model.","The architecture provides a foundation for secure PiM platforms where encryption happens close to the data it protects."],"supporting_citations":[{"why":"PiM-based AES in DRAM; the main prior art SPiME contrasts with by avoiding custom memory technology.","marker":"[9]"},{"why":"Polymorphic AES core merging SubBytes and MixColumns; supplies an alternative low-resource AES construction.","marker":"[30]"},{"why":"Spintronic PiM AES with side-channel resistance; establishes the PiM-AES design space SPiME enters.","marker":"[31]"},{"why":"AESPIM for video encryption; provides system-level parallelism and QoS scheduling that SPiME compares against.","marker":"[32]"},{"why":"Fully pipelined memoryless 17.8 Gbps AES-128; a throughput baseline for parallel AES designs.","marker":"[8]"},{"why":"Balanced-logic side-channel countermeasure; motivates secure AES hardware in PiM settings.","marker":"[13]"},{"why":"Rijndael key expansion algorithm; the source of the round-key schedule used by the AES core.","marker":"[34]"}],"fun_headline_variants":["SPiME packs 4,096 AES cores into <5% of FPGA","AES-128 moved next to memory for 25 Gbps","FPGA PiM: AES at scale with 11-cycle latency","SPiME: parallel AES that fits almost for free","Scale AES to 4K units without breaking FPGA"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the 4,096-unit synthesis reports include a complete AES-128 datapath in every PiM unit, since without that the sub-5% LUT utilization would not apply to a functional encryption core.","fun_headline_variants_meta":{"raw":{"variants":["SPiME packs 4,096 AES cores into <5% of FPGA","AES-128 moved next to memory for 25 Gbps","FPGA PiM: AES at scale with 11-cycle latency","SPiME: parallel AES that fits almost for free","Scale AES to 4K units without breaking FPGA"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000339,"raw_usage":{"total_tokens":1866,"prompt_tokens":937,"completion_tokens":929,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":553,"completion_tokens_details":{"reasoning_tokens":840}},"tokens_in":553,"tokens_out":929,"duration_ms":8577,"temperature":1.0,"reasoning_tokens":840,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:44:07.857470+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Synthesize the 4,096-PiM configuration on the U55C device with the full AES datapath (SubBytes S-boxes, ShiftRows, MixColumns) present in every unit and read the post-implementation LUT utilization; at under 5% of 1.3 million LUTs the budget is roughly 16 LUTs per AES core, which a complete S-box-based datapath cannot meet, so checking whether that report is produced would settle the scalability claim.","supporting_citations":[{"cited_title":"A processing-in-memory aes implementation in dram for secure and efficient data encryption","cited_arxiv_id":null,"evidence_quote":"PiM-based AES in DRAM; the main prior art SPiME contrasts with by avoiding custom memory technology."},{"cited_title":"Reconfigurable memory based aes co-processor","cited_arxiv_id":null,"evidence_quote":"Polymorphic AES core merging SubBytes and MixColumns; supplies an alternative low-resource AES construction."},{"cited_title":"Power attack-immune spintronic-based aes hardware accelerator for secure and high-performance pim architectures","cited_arxiv_id":null,"evidence_quote":"Spintronic PiM AES with side-channel resistance; establishes the PiM-AES design space SPiME enters."},{"cited_title":"Enabling PIM-based AES encryption for online video streaming","cited_arxiv_id":null,"evidence_quote":"AESPIM for video encryption; provides system-level parallelism and QoS scheduling that SPiME compares against."},{"cited_title":"A fully pipelined memoryless 17.8 gbps aes-128 encryptor","cited_arxiv_id":null,"evidence_quote":"Fully pipelined memoryless 17.8 Gbps AES-128; a throughput baseline for parallel AES designs."},{"cited_title":"Securing encryption algorithms against dpa at the logic level: Next generation smart card technology","cited_arxiv_id":null,"evidence_quote":"Balanced-logic side-channel countermeasure; motivates secure AES hardware in PiM settings."},{"cited_title":"The rijndael algorithm","cited_arxiv_id":null,"evidence_quote":"Rijndael key expansion algorithm; the source of the round-key schedule used by the AES core."}],"review_version":2}