{"id":"00abe729-2b5f-413d-941d-fa1ff5177fc2","arxiv_id":"2508.03567","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"First reported UPMEM implementation of non-binary LDPC decoders reaches up to 76 Mbit/s compute-only throughput, competitive with low-power GPUs in the authors' measurements.","lead":"This paper maps two standard non-binary LDPC error-correction decoding algorithms, FFT-SPA and Min-Max, onto UPMEM, a commercial processing-in-memory system, and reports decoding throughput up to 76 Mbit/s across 2540 in-memory cores. A generalist should read it to see whether near-memory computing can realistically host error-correction workloads that normally run on GPUs, though the comparison omits bit-error-rate validation and data-transfer costs.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 76 Mbit/s claim is a compute-only throughput figure for a decoder with no measured BER/FER, no stated iteration cap, and no matched GPU operating point; until the kernel is shown to correct errors at the target SNR, the 'competitive with edge GPUs' claim lacks its load-bearing support.","rationale":"I read the paper in good faith as a PiM feasibility study. The architecture and optimization descriptions are specific and plausible; I found no obvious mathematical inconsistency that would make Algorithm 1 or Algorithm 2 invalid on their face. The binding problem is validation. The strongest claim is comparative ('competitive with edge GPUs'), and a comparison of throughput is meaningful only if both systems are delivering the same error-correction quality at the same iteration and stopping conditions. The paper's own text acknowledges that parity checks and hard decisions are excluded from the timings and that early termination is not used, but it does not state Imax or provide BER/FER. This is not a cosmetic omission: quantized FFT-SPA can lose error-correction performance through underflow and normalization effects, and the cited [47] does not cover the exact probability-domain FFT-SPA implementation. The GPU baseline [13] is the authors' own previous work; without matched operating points, the Fig. 10 comparison cannot be interpreted. The reader's conditional verdict is thus appropriate, and I would keep it: the paper should be accepted only with a BER/FER measurement and disclosure of Imax, the PCMs, and end-to-end transfer timing. If those measurements are favorable, the headline can stand; if not, the results should be presented as raw compute rates rather than competitive decoding. This is an evidentiary gap in the argument, not a criticism of the authors.","tokens_in":23722,"tokens_out":9586,"duration_ms":105066,"concrete_test":"Run a Monte Carlo AWGN evaluation for C1-C3 over GF(4) through GF(256) with the exact deployed kernels: report BER and FER versus Eb/N0 for the 8-bit and 32-bit integer decoders and for a 32-bit floating-point reference, all with the same disclosed Imax and stopping rule, and overlay the GPU results from [13] at a matched FER (e.g., 10^-3). If the fixed-point curves degrade by more than about 0.1 dB relative to the floating-point reference, or if the UPMEM kernel cannot reach the target FER at any tested SNR, the throughput headline should be re-labeled as a raw compute rate rather than competitive decoding.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract's headline is a throughput comparison ('competitive with edge GPUs'), but the measured throughput is not attached to a demonstrated error-correcting decoder. Section 5 reports only execution times: no bit-error-rate or frame-error-rate result appears anywhere in the paper. Section 4.1 justifies 8-bit fixed-point operation by citing Wymeersch et al. [47], but that reference concerns the log-sum-product algorithm and does not cover the probability-domain FFT-SPA or the min-max kernels, field sizes, and code lengths used here. Section 5 also states that the timings 'exclude the processing of the parity check equation verifications' and 'do not assume early termination,' yet the iteration cap Imax is never disclosed. The reported 76 Mbit/s is, in fact, the 32-bit integer FFT-SPA maximum from Fig. 7; the 8-bit FFT-SPA reaches only 20.7 Mbit/s, so the quantization discussion is not even the source of the headline number. None of this would matter if the kernel were independently validated, but the paper provides no code or PCMs and no syndrome/BER evidence. If the 8-bit or 32-bit kernels do not drive the syndrome to zero or reach the target FER at the SNR of interest, the throughput numbers describe a raw arithmetic pipeline, not a decoder, and the comparison with edge GPUs in Fig. 10 has no common error-correction operating point.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript reports implementations of non-binary LDPC decoders, specifically FFT-SPA and Min-Max, on UPMEM processing-in-memory hardware. It describes the mapping to the UPMEM memory hierarchy (WRAM/MRAM), multithreading with 16 threads per DPU, and multicodeword execution across 2540 DPUs, and reports operation counts, execution times, and throughput for three short CCSDS-derived codes over GF(4) through GF(256). The central claim is that the UPMEM implementation is the first PiM-based NB-LDPC decoder and that its maximum 76 Mbit/s throughput is competitive with low-power edge GPUs.","tokens_in":23992,"tokens_out":6583,"duration_ms":78620,"significance":"If properly validated, this would be a useful first demonstration of NB-LDPC decoding on commercial PiM hardware, providing concrete data on WRAM/MRAM placement, 8-bit quantization, loop unrolling, and multicodeword throughput. The complexity validation in Sec. 5.1 (Fig. 5) is valuable because it ties counted UPMEM operations to theoretical expressions without fitted constants. The main limiting factor is that the throughput claims are not yet attached to verified error-correction performance or a matched GPU operating point, so the significance of the headline comparison is currently conditional.","major_comments":[{"comment":"No BER/FER validation is reported anywhere in the manuscript; Section 5.2 measures only execution time and throughput. Section 4.1 justifies 8-bit quantization by citing reference [47], but that reference addresses log-sum-product decoding and does not validate the probability-domain FFT-SPA or Min-Max kernels for the code lengths and field sizes used here. Because the decoders exclude parity-check verification from timing and no syndrome or error-rate result is given, the 76 Mbit/s figure is not tied to a demonstrated error-correcting decoder. Please add BER/FER curves versus SNR for each algorithm, quantization mode, and code, with a floating-point reference, and report syndrome-validated operation.","section":"Sec. 5.2 (Figs. 6–8); Sec. 4.1"},{"comment":"The comparison to edge GPUs is not shown to be at a common operating point. The manuscript does not report the maximum iteration count Imax used in the UPMEM runs or in the GPU results taken from [13], nor whether the GPU numbers include parity-check overhead or use the same early-termination policy. Since both sets of numbers come from the authors' own implementations, reporting matched conditions is feasible. Without a stated iteration cap and matched protocol, the claim that UPMEM is 'competitive with edge GPUs' is not established. Please specify Imax, quantization, and early-termination status for both platforms, and report throughput at matched error-correction performance or at equal iteration counts.","section":"Sec. 5.4, Fig. 10"},{"comment":"The abstract's headline 76 Mbit/s is the 32-bit integer FFT-SPA maximum from Fig. 7, whereas the 8-bit FFT-SPA reaches 20.729 Mbit/s. This is important because the quantization discussion in Sec. 4.1 motivates the 8-bit decoder, and the conclusion describes 'message quantization' as a key balance. The headline should either refer to the validated/deployed configuration or be qualified as the 32-bit integer implementation.","section":"Sec. 5.2, Fig. 7"},{"comment":"The maximum iteration count Imax is never disclosed, despite being an input to Algorithms 1 and 2 and determining throughput when early termination is disabled and parity-check processing is excluded from the timing. Please report Imax for all experiments and, ideally, report throughput per iteration so that the numbers can be compared across platforms and reproduced.","section":"Sec. 5; Algorithms 1 and 2"}],"minor_comments":[{"comment":"The caption contains the typo 'strucutre'; it should read 'structure'.","section":"Fig. 3 caption"},{"comment":"The manuscript alternates between '32-bit fixed-point' and '32-bit integer' for the same implementation; please use one consistent term.","section":"Sec. 4.1 and Fig. 7"},{"comment":"The sentence 'The performance decreases from 2.5× to 1.5× for every GF increment' is ambiguous; please state explicitly whether this is a multiplicative slowdown and over which GF range it applies.","section":"Sec. 5.2"},{"comment":"The comparison uses 2540 DPUs for UPMEM but 16,384 or 32,768 decoders for the GPUs; reporting a per-decoder throughput or a power-normalized metric would clarify whether the comparison reflects the architecture or simply the number of parallel workers.","section":"Sec. 5.4"},{"comment":"The method used to obtain the counted 'UPMEM Ops' and 'UPMEM Mem.' values is not described; please state briefly how the counts were instrumented.","section":"Sec. 5.1, Fig. 5"},{"comment":"No code or PCM definitions are provided; including the parity-check matrices or a public source for them would improve reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The missing BER/FER validation is the decisive issue. The authors are well positioned to fix it within the scope of a revision because they already have GPU implementations [13] and presumably a reference simulator; I therefore recommend major revision rather than rejection. The use of the authors' own prior GPU results as the comparison baseline is not itself problematic, but it makes the absence of protocol details (iteration count, early termination, parity-check overhead) more surprising and easier to resolve."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the single most useful thing to know: this is a genuine engineering contribution, the first real-hardware PiM implementation of NB-LDPC decoders (FFT-SPA and Min-Max) on UPMEM, with measured throughput on 2540 DPUs. That part is real. But the paper's headline claim—that the result is 'competitive... against edge GPUs'—is not supported by the evidence presented. The measurements are compute-only, the decoder's error-correction capability is never demonstrated, and the GPU comparison comes from the authors' own prior work without a matched operating point.\n\nWhat the paper does well: the mapping to UPMEM is nontrivial and described in useful detail—GF arithmetic via LUTs and barrel shifts, permutation networks, WRAM/MRAM placement decisions, multithreading with 16 threads, and multicodeword reuse. The complexity analysis in Section 2.3 is textbook, but the measured cycle counts in Fig. 5 give an honest sense of where time goes. The throughput scaling across code sizes and field sizes (Figs. 7 and 8) is new data and looks plausible.\n\nThe soft spots are real and load-bearing. No BER or FER result appears anywhere. The 8-bit quantization justification cites Wymeersch et al. [47], which covers log-sum-product decoding, not the probability-domain FFT-SPA or the min-max kernels used here. Section 5 explicitly excludes parity-check verification and early termination, yet the iteration cap Imax is never stated. So we cannot tell whether the 76 Mbit/s figure (which is actually the 32-bit fixed-point FFT-SPA, not the 8-bit version) corresponds to a kernel that drives syndromes to zero. The GPU comparison in Fig. 10 uses the authors' own [13] numbers, with no assurance that iteration counts, quantization, or code parameters match. Throughput also excludes host-device transfers. None of this kills the engineering value, but it does kill the competitive claim as written.\n\nMy take: this deserves a serious referee, but with the expectation of major revision. Add BER/FER curves for the tested codes and quantization, disclose Imax, and either produce a like-for-like GPU comparison or soften the abstract to claim raw throughput rather than competitiveness. For people working on PiM or NB-LDPC acceleration, this is a useful reference even in its current form; for the coding theory community, it is an implementation note with an important missing measurement.","headline":"First PiM NB-LDPC hardware mapping is real; 'competitive with edge GPUs' is unproven because no BER/FER is reported and the GPU baseline is not matched.","tokens_in":24585,"tokens_out":3119,"would_cite":true,"duration_ms":32877,"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":"The paper claims the first hardware processing-in-memory implementations of non-binary LDPC decoders—FFT-based sum-product and min-max—running on UPMEM and reaching 76 Mbit/s, competitive with low-power edge GPUs.","keywords":["Processing-in-memory","UPMEM","Non-binary LDPC","FFT-SPA","Min-Max decoding","Multicodeword decoding","Fixed-point quantization","Embedded GPU"],"falsifier":"Run the implemented C1, C2, and C3 decoders over an AWGN channel with BPSK modulation at several signal-to-noise ratios, using the exact 8-bit quantized FFT-SPA and Min-Max kernels, and compare their bit-error and frame-error rates against a floating-point reference at the same iteration count. If the quantized versions show more than about 0.1 dB degradation or any error floor in the simulated range, the competitive throughput claim would be describing a computing engine rather than a usable error-correcting decoder.","tokens_in":23467,"feed_emoji":"📡","tokens_out":12098,"duration_ms":125510,"temperature":0.7,"pith_summary":"Non-binary LDPC decoding is a computationally heavy error-correction workload that usually runs on parallel processors, moving large amounts of data between memory and compute units. This paper claims the first hardware processing-in-memory (PiM) implementations of two NB-LDPC decoders—the FFT-based sum-product algorithm and the min-max algorithm—running on the UPMEM system, where simple RISC cores sit inside DRAM. The implementations decode short codes of 16 to 64 symbols over fields GF(4) through GF(256), decode many codewords concurrently on 2540 in-memory cores, and use quantized fixed-point arithmetic to avoid floating-point emulation. The headline measured result is 76 Mbit/s for the FFT-SPA decoder in 32-bit integer mode, which the authors report as competitive with low-power embedded GPUs from the Jetson family. What the paper is establishing is that processing-in-memory is a workable platform for batch NB-LDPC decoding, not just a theoretical proposal.","feed_headline":"First in-memory decoder for non-binary LDPC hits 76 Mbit/s","feed_subtitle":"FFT-SPA and min-max decoders run inside UPMEM memory chips and stand between Jetson TX2 and Xavier on throughput.","key_machinery":"The central mechanism is the UPMEM DRAM Processing Unit (DPU): a 32-bit in-order RISC core embedded beside a 64 MB DRAM bank, with a 14-stage pipeline, up to 24 hardware threads, a 64 KB SRAM scratchpad (WRAM), an 8-bit native multiplier, and no floating-point unit. The argument is carried by a specific mapping strategy: Tanner graph topology and frequently accessed messages stay in WRAM, larger auxiliary buffers spill to MRAM, Galois-field multiplications become look-up table reads and barrel shifts, the FFT-SPA uses a radix-2 FFT with edge-level parallelism and stage barriers, and the Min-Max decoder computes its forward, backward, and beta matrices with comparison passes. With 2540 DPUs each decoding an independent codeword, the design hides per-core latency through massive multicodeword parallelism and converts the data-movement bottleneck into computation performed next to the data.","core_discovery":"The central claim is that the UPMEM processing-in-memory system, despite its low clock rate and simple ALUs, can execute non-binary LDPC decoding at throughputs comparable to low-power GPUs. The authors design an FFT-SPA decoder (floating-point, 32-bit integer, and 8-bit variants) and a Min-Max decoder (32-bit and 8-bit fixed-point), using a multicodeword mapping in which each DRAM Processing Unit decodes its own codeword, eliminating inter-DPU synchronization. The mapping keeps the Tanner graph and hot buffers in WRAM, offloads less-used buffers to MRAM, performs Galois-field multiplication as look-up table reads and barrel-shift permutations, and parallelizes the radix-2 FFT and forward/backward matrix passes over edges with barrier synchronization. On codes of sizes (16,8), (32,16), and (64,32), the multi-DPU FFT-SPA reaches 76.7 Mbit/s in 32-bit integer mode and the Min-Max reaches 145.2 Mbit/s at GF(8). In the GF(16) FFT-SPA comparison, the published results place the UPMEM system between the Jetson TX2 and the Jetson Xavier, and the authors argue the performance difference is set mainly by the number of cores rather than per-core capability.","pith_inferences":["Because the paper never reports bit-error or frame-error rates, the natural test of its central claim is to connect the same kernels to an AWGN channel simulator and measure actual decoding quality; until then, the throughput figures describe the compute engine, not a verified error-correcting decoder.","The 8-bit FFT-SPA variant (20.7 Mbit/s) is slower than the 32-bit variant (76.7 Mbit/s), which suggests the limiting resource on short kernels is instruction issue and pipeline utilization rather than arithmetic width; a testable extension would pack two 8-bit symbols per 32-bit word and remeasure.","The paper's 'add more modules' scalability is a linear-scaling hypothesis; a direct check is to measure throughput on one, two, and four UPMEM modules at a fixed code and field and compare the scaling exponent, rather than inferring from the modular architecture.","Reading the paper's batch-decoding conclusion (massive MIMO, optical receivers, cloud-RAN), the result is aimed at high-density parallel decoding of many codewords; in single-stream low-latency links, the host-to-DPU transfer and setup latency would dominate, so this is not a general replacement for GPU decoding."],"forward_implications":["Processing-in-memory hardware, not just simulated models, can run complete FFT-SPA and Min-Max NB-LDPC decoders, opening a concrete low-power path for error-correction workloads in memory-centric systems.","For short CCSDS-family codes at GF(16), the UPMEM system's throughput sits between a Jetson TX2 and a Jetson Xavier, indicating near-memory decoding can compete with low-power GPUs when the data-movement bottleneck is dominant.","Fixed-point quantization to 32-bit and 8-bit integers keeps the decoders inside a practical performance band without floating-point units, based on the cited quantization study.","The one-codeword-per-DPU multicodeword strategy removes inter-DPU synchronization, and throughput scales with the number of DPUs, so adding PiM modules increases decoding capacity without redesign.","The reported figures are compute-only at a fixed number of iterations, deliberately excluding parity-check verification and early stopping, so they provide an SNR-independent throughput baseline."],"supporting_citations":[{"why":"Supplies the CCSDS code construction from which the three parity-check matrices C1, C2, and C3 are derived.","marker":"[1]"},{"why":"Provides the low-power GPU throughput baselines (Jetson Nano, TX2, Xavier) that the UPMEM results are compared against.","marker":"[13]"},{"why":"Documents the UPMEM DPU architecture and WRAM/MRAM bandwidth numbers that motivate the memory placement strategy.","marker":"[27]"},{"why":"Defines the Min-Max decoding algorithm implemented in the second decoder.","marker":"[41]"},{"why":"Supplies the UPMEM ISA details, pipeline depth, thread count, and 8-bit multiplier hardware that shape the optimizations.","marker":"[42]"},{"why":"Establishes the multicodeword, one-decoder-per-DPU mapping strategy for LDPC decoding on UPMEM that this work extends to non-binary codes.","marker":"[44]"},{"why":"Provides the quantization-loss bound the paper relies on to claim that 8-bit fixed-point decoding has minimal error-rate degradation.","marker":"[47]"},{"why":"Gives the radix-2 FFT implementation used inside the FFT-SPA check node processing.","marker":"[48]"}],"fun_headline_variants":["First in-memory non-binary LDPC decoder hits 76 Mbit/s","UPMEM runs LDPC decoding in memory, rivals edge GPUs","Non-binary LDPC decoding inside DRAM: 76 Mbit/s","Processing-in-memory LDPC decoder matches low-power GPUs","In-memory non-binary LDPC decoding: 76 Mbit/s on UPMEM"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the implemented decoders actually correct errors at usable quality: the paper never reports bit-error or frame-error rates, instead citing a published quantization study to argue that 8-bit fixed-point arithmetic costs less than roughly 0.1 dB, so the throughput figures describe a compute engine whose error-correction performance still needs to be demonstrated.","fun_headline_variants_meta":{"raw":{"variants":["First in-memory non-binary LDPC decoder hits 76 Mbit/s","UPMEM runs LDPC decoding in memory, rivals edge GPUs","Non-binary LDPC decoding inside DRAM: 76 Mbit/s","Processing-in-memory LDPC decoder matches low-power GPUs","In-memory non-binary LDPC decoding: 76 Mbit/s on UPMEM"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00023,"raw_usage":{"total_tokens":1540,"prompt_tokens":1059,"completion_tokens":481,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":675,"completion_tokens_details":{"reasoning_tokens":374}},"tokens_in":675,"tokens_out":481,"duration_ms":5623,"temperature":1.0,"reasoning_tokens":374,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T04:21:38.458513+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the implemented C1, C2, and C3 decoders over an AWGN channel with BPSK modulation at several signal-to-noise ratios, using the exact 8-bit quantized FFT-SPA and Min-Max kernels, and compare their bit-error and frame-error rates against a floating-point reference at the same iteration count. If the quantized versions show more than about 0.1 dB degradation or any error floor in the simulated range, the competitive throughput claim would be describing a computing engine rather than a usable error-correcting decoder.","supporting_citations":[{"cited_title":"Short Block length LDPC codes for TC synchronization and cha nnel coding","cited_arxiv_id":null,"evidence_quote":"Supplies the CCSDS code construction from which the three parity-check matrices C1, C2, and C3 are derived."},{"cited_title":"On the Pe rformance of Link Space Communications using NB- LDPC Codes on Embedded Parallel Systems","cited_arxiv_id":null,"evidence_quote":"Provides the low-power GPU throughput baselines (Jetson Nano, TX2, Xavier) that the UPMEM results are compared against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the Min-Max decoding algorithm implemented in the second decoder."},{"cited_title":"The true Processing In Memory accelera tor","cited_arxiv_id":null,"evidence_quote":"Supplies the UPMEM ISA details, pipeline depth, thread count, and 8-bit multiplier hardware that shape the optimizations."},{"cited_title":"Unlocking the Potential of LDPC Decoders with PiM Acceleration","cited_arxiv_id":null,"evidence_quote":"Establishes the multicodeword, one-decoder-per-DPU mapping strategy for LDPC decoding on UPMEM that this work extends to non-binary codes."},{"cited_title":"C omputational complexity and quantization effects of decoding algorithms for non-binary ldpc codes","cited_arxiv_id":null,"evidence_quote":"Provides the quantization-loss bound the paper relies on to claim that 8-bit fixed-point decoding has minimal error-rate degradation."},{"cited_title":"FFT-SP A non-binary LDPC decoding on GPU","cited_arxiv_id":null,"evidence_quote":"Gives the radix-2 FFT implementation used inside the FFT-SPA check node processing."}],"review_version":1}