{"id":"4f51f869-d862-4935-88f9-22e3b54795ec","arxiv_id":"2506.22156","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":6,"one_line_summary":"An FPGA-based training implementation for MRF neural networks is estimated to cut training time from about 16 hours to 200 seconds, but no full end-to-end training was demonstrated.","lead":"This paper proposes training a neural network for Magnetic Resonance Fingerprinting directly on an FPGA chip, estimating a 200 second training time versus about 16 hours on a CPU. The idea is to let MRI machines retrain their reconstruction models quickly when scan settings change, which could help bring quantitative brain imaging into real-time clinical and mobile settings.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eq. (3) counts only forward/backward compute cycles, but the optimizer and data movement are deferred to future work, so the 200-second training claim is not supported by the reported implementation.","rationale":"The paper's strongest quantitative claim is Eq. (3): a 200-second FPGA training time, which is used to derive a 200x speedup over CPU. This estimate is not a measurement; it is an arithmetic product of a per-sample cycle budget (56 forward + 104 backward) and a 250M-sample count. For that product to describe training, the 160 cycles must cover one complete training step. The manuscript contains direct evidence that this condition is unmet: the only implemented VHDL blocks are a generic node and a backpropagation gradient module, while the optimizer is explicitly deferred to future work. The reference CPU training uses Adam, whose stateful updates add cycles and memory operations absent from Eq. (3). Memory, PCIe, and control overhead are likewise omitted. A separate internal inconsistency compounds the problem: Section 3 first states the whole network cannot be implemented, then reports utilization figures (8% LUTs, 40% DSPs) that suggest it can, calling the implementation 'entirely viable'. If the full network fits, the time-multiplexing assumption behind 56+104 cycles is called into question; if it does not, the utilization report is wrong. In either case, the cycle count has no consistent hardware basis. The quantization accuracy results in Table 1 are a useful preliminary, but they do not bear on training latency. A cycle-accurate implementation of one full training step would settle whether 160 cycles per sample is realistic. Until that is done, the central claim is unsupported, and the REJECT verdict stands without modification.","tokens_in":5271,"tokens_out":6966,"duration_ms":71893,"concrete_test":"Implement the complete training loop for the adapted network in RTL (or cycle-accurate simulation) using the described time-multiplexed 16-node forward block and backpropagation module, including weight updates, the optimizer, weight/bias memory access, input streaming, PCIe transfer, and the control state machine. Measure the average number of clock cycles per training sample for at least one full pass over the dataset. If the measured cycle count exceeds 160, or if the design cannot close timing at 200 MHz with the reported resource usage, then Eq. (3)'s 200-second estimate and the 200x speedup claim do not hold.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim rests entirely on Eq. (3): 250M samples x (56+104) cycles x 5 ns = 200 s. For this to represent NN training, the 160-cycle budget must be a complete per-sample training step. The manuscript does not establish this. Section 2.2 implements a generic node and a backpropagation module that computes gradients (Eq. 2), but no weight-update or optimizer hardware is described; Section 4 explicitly lists 'developing an optimiser' as future work. The reference CPU training uses Adam, which requires additional momentum, variance, and parameter-update operations per step. Memory access for streaming 250M input signals, PCIe transfer, weight/bias read/write, control logic, and time-multiplexed scheduling across layers are also outside the 56+104 cycle count. Additionally, Section 3 first states that the whole network and backpropagation cannot be implemented on the FPGA, then reports full resource usage of 145k LUTs / 5k DSPs / 146k FFs, which is only 8% of LUTs and 40% of DSPs, and calls the implementation 'entirely viable'. If the full design fits, the time-multiplexing model behind Eq. (3) is unjustified; if it does not, the resource claim is inconsistent. Either way, the 200-second figure is a lower bound on an incomplete design, not a measured or validated training time.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript reports an FPGA-based implementation of a simplified, quantized fully connected network for MRF T1/T2 map reconstruction. The authors implement a generic node and a backpropagation module in VHDL, verify the node against Python, estimate resource usage on an Alveo U250 board, and extrapolate from Eq. (3) to claim a 200 s training time for 250M samples, about 200 times faster than CPU training. The paper's central quantitative claim is the 200 s estimate, and the reported contribution is the claim that on-device retraining of the MRF reconstruction network becomes practical.","tokens_in":5608,"tokens_out":3371,"duration_ms":36795,"significance":"If the 200 s estimate were supported by a complete, measured implementation, the result would be significant for MRF standardization and real-time deployment, since the network would need retraining whenever acquisition parameters change. The quantized network preserves accuracy reasonably well (T1 MAPE increases from 2.15% to 2.36%, T2 MAPE from 8.89% to 11.07%), and the hardware-software equivalence check for the single node is a useful verification step. The resource estimates (145k LUTs, 5k DSPs, 146k FFs) also suggest that the design is plausible in resource terms. However, the central training-time claim is an extrapolation from assumed cycle counts rather than a demonstrated or measured result, and the manuscript contains an internal contradiction about whether the full network and backpropagation can fit on the FPGA.","major_comments":[{"comment":"The 200 s figure counts only 56 + 104 clock cycles per sample for forward and backward computation, but it does not include any cycles for data movement, PCIe transfer, weight/bias memory access, control logic, or optimizer updates. The CPU baseline uses Adam, while the implemented backpropagation is stochastic gradient descent, so the comparison is not an apples-to-apples accounting of a complete training step. The 56 and 104 cycle numbers are asserted without RTL simulation, timing analysis, or on-board measurement, so Eq. (3) should be read as a lower-bound assumption for compute cycles only, not a validated training-time estimate.","section":"Section 2.2, Eq. (3)"},{"comment":"The text first states that 'the whole network and backpropagation algorithm cannot be implemented on the FPGA', then immediately reports 145k LUTs, 5k DSPs, and 146k FFs, which it says is 8% of LUTs and 40% of DSPs, and calls the implementation 'entirely viable from the resource point of view'. These statements are internally inconsistent. If the resource estimate covers the full network and backpropagation, then the time-multiplexing rationale for Eq. (3) is unnecessary; if it does not, then the 56 + 104 cycle count cannot represent the full training loop. This contradiction undermines the central claim.","section":"Section 3, resource assessment"},{"comment":"The manuscript does not specify how the 16-node forward block and the 16-to-32-node backpropagation block are iterated to cover all layers of the network, nor how many additional cycles are required for scheduling, weight updates, and control. The statement that 'by iterating these two blocks multiple times in a semiparallelised way, all the operational requirements of the network can be covered' is not accompanied by a layer-by-layer cycle breakdown, so the 56 and 104 cycle totals have no verifiable relation to the actual network architecture shown in Fig. 2.","section":"Section 2.2, time-multiplexing description"}],"minor_comments":[{"comment":"References [8] and [10] are the same work by Sanaullah et al.; one of them should be removed or renumbered.","section":"References"},{"comment":"The abstract reports that CPU training 'can be up to 250 times slower', while Section 3 reports a speedup of '200 times'; since 16 hours versus 200 s corresponds to a factor of about 288, the speedup figures should be reconciled.","section":"Abstract and Section 3"},{"comment":"The board name is given as 'AL VEO U250'; the correct vendor name is 'Alveo U250'.","section":"Section 2.2"},{"comment":"The notation '250′000′000' is nonstandard; it should be written as 250,000,000.","section":"Section 2.2, Eq. (3)"},{"comment":"The adapted network in Fig. 2 is not described in the text with explicit layer sizes, which makes it difficult to verify that the 16-node and 16-to-32-node blocks actually cover all layers.","section":"Figures"}],"recommendation":"reject","confidential_remarks":"The paper is a preliminary report whose central claim is a back-of-the-envelope calculation. The most serious issue is the direct contradiction in Section 3 about whether the full network and backpropagation can fit on the FPGA; this is not a presentation issue but a fundamental inconsistency in the evidence supporting Eq. (3). The 200 s figure would need to be rederived from a complete implemented design with measured cycle counts and an actual comparison against the Adam-based CPU training. As written, the claim goes well beyond what the reported implementation supports, so I recommend rejection rather than major revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe one thing to know: this paper is not a demonstration of FPGA training. It is a feasibility study with one implemented neuron block and one backpropagation block, plus an extrapolated training-time figure. The extrapolation is the entire basis for the 200 s claim, and it does not hold together as stated.\n\nWhat is genuinely new: prior FPGA work on MRF and medical NNs is inference-only. The motivation here, that MRF retraining is needed when acquisition parameters change and that mapping reconstruction and training onto an FPGA could remove that bottleneck, is a real and worthwhile problem. The authors also do some honest work: they implement a generic VHDL node and a backprop module, verify node outputs against Python, and report resource usage for the full design (145k LUTs, 5k DSPs, 146k FFs, 8% LUT and 40% DSP). If those resource numbers are accurate, fitting the whole quantized network is plausible, which is relevant.\n\nNow the soft spots, in proportion. First, Eq. (3) is a lower bound, not a training time. The 56+104 cycles cover only forward and backward compute blocks as time-multiplexed; the Adam optimizer used on CPU is explicitly deferred, and data movement, PCIe transfer, memory access, control logic, and scheduling across layers are not counted. The stress-test note is right about this. Second, there is a direct contradiction: Section 3 first says the whole network and backpropagation cannot be implemented on the FPGA, then reports resource usage for the entire network and backpropagation and calls it 'entirely viable.' That needs to be resolved. Third, the speedup comparison to CPU is sloppy—the abstract says up to 250x, the text says 200x, and the CPU baseline is for the original, unquantized network, not the adapted one.\n\nThese flaws are load-bearing for the central quantitative claim, so I agree with the reader's reject verdict as a paper standing on its current evidence. But I would not dismiss the direction. The problem is well-motivated, the authors are transparent about what is implemented versus estimated, and the resource estimate is a useful data point. A serious revision that either implements the full training loop or clearly labels the 200 s as a back-of-envelope compute-cycle-only projection, plus fixes the contradiction, could be worth another look.\n\nFor peer review: I would send this to a referee. The application is real, the implementation pieces are checkable, and the flaws are correctable enough to justify referee time rather than a desk reject—though the expected outcome would be heavy revision.","headline":"A plausible feasibility pitch for on-device MRF retraining, undercut by a 200 s estimate built on incomplete cycle accounting and an internal contradiction about whether the full network fits.","tokens_in":6112,"tokens_out":2693,"would_cite":false,"duration_ms":28101,"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 that an FPGA can train the MRF reconstruction network in an estimated 200 seconds at a 200 MHz clock, roughly 200 times faster than the CPU training baseline, which would make on-device retraining practical whenever…","keywords":["magnetic resonance fingerprinting","neural network training","FPGA acceleration","hardware implementation","quantization-aware training","backpropagation","T1 and T2 mapping","real-time MRI"],"falsifier":"Run the actual training on an Alveo U250 with the same 250 million simulated MRF signals streamed over PCIe under the same 500-epoch, 1000-step schedule, and measure wall-clock time. If the measured time exceeds roughly five minutes by a significant margin, the 200-second estimate and the 200-times speedup over CPU do not hold.","tokens_in":5095,"feed_emoji":"🧠","tokens_out":8966,"duration_ms":83865,"temperature":0.7,"pith_summary":"This paper tries to establish that neural-network training for Magnetic Resonance Fingerprinting (MRF) reconstruction can be moved onto an FPGA, and that on-hardware training would take under five minutes: about 200 seconds at a 200 MHz clock, compared with roughly 16 hours on CPU. If true, this changes the practical MRF workflow, because MRF is not standardized and any change in scanner, field strength, or reconstruction parameters currently forces an expensive retraining step. The authors adapt the existing nine-layer network by removing two layers and applying quantization-aware training, then implement the neuron and backpropagation operations in VHDL. They estimate that time-multiplexing a 16-node forward block and a 16-to-32-node backpropagation block covers the whole network, yielding the 200-second figure. The paper is best read as a feasibility argument backed by synthesis estimates and by identical outputs between the VHDL node and the Python implementation.","feed_headline":"FPGA retrains MRF brain map network in under five minutes","feed_subtitle":"Estimated 200-second training beats CPU by ~200x, opening on-device retraining when scan settings change.","key_machinery":"The load-bearing device is time-multiplexed hardware reuse of two generic blocks: a 16-node forward block (each node takes 4 clock cycles, and all layers together take 56 cycles per sample) and a 16-to-32-node backpropagation block (3 cycles per node, 104 cycles total), run at a 200 MHz clock with a 5 ns period. These blocks are iterated over the whole quantized network, so the total training time is estimated as $5\\,\\mathrm{ns}\\cdot 250{,}000{,}000\\cdot(56+104)=200\\,\\mathrm{s}$. The supporting piece is the VHDL implementation of the single-neuron equation $y=\\sigma(\\sum_{i} x_i w_i + b)$ and the backpropagation delta equations, with identical outputs between hardware and Python for the same inputs, weights, and biases.","core_discovery":"The central claim is that both inference and training for the MRF neural network can be implemented on an FPGA, with training time dominated by a simple arithmetic budget: each training sample costs 56 clock cycles for forward propagation and 104 cycles for backpropagation, and with 250 million samples at a 5 ns clock period the total is 200 seconds. The paper grounds this in a concrete hardware picture: one generic node function in VHDL, 16 nodes deployed in a semiparallel block, a backpropagation module between layers of 16 and 32 nodes, repeated across the network, using 8 percent of the LUTs and 40 percent of the DSPs of an Alveo U250. It also shows that the quantized integer network keeps reconstruction quality close to the original, with MAPE for T1 rising from 2.15 to 2.36 percent and for T2 from 8.89 to 11.07 percent. The claim is not that a finished accelerator exists, but that the per-node arithmetic and resource budget already fit on the board, so the 200-second training estimate is presented as a realistic projection.","pith_inferences":["The 200-second figure counts only forward and backward arithmetic cycles; a wall-clock measurement would add PCIe transfer, memory access, control logic, and optimizer overhead, so the realized speedup is likely below 200 times until those costs are absorbed.","The FPGA port uses plain stochastic gradient descent while the software baseline used Adam; if convergence differs, the 500-epoch, 1000-step schedule may not be equivalent, which would shift the CPU-versus-FPGA comparison.","The estimate also ignores the cost of generating or loading the 250 million simulated training signals, which a fair comparison against the 16-hour CPU run would need to include.","A stronger end-to-end test would be to train the quantized network on the FPGA and compare the resulting T1/T2 maps against the reported quantized error metrics, separating speed gains from accuracy effects."],"forward_implications":["If the estimate holds, MRF reconstruction networks can be retrained on the scanner or on a nearby FPGA in minutes whenever acquisition parameters change, removing the main obstacle to MRF standardization.","The quantized network's error metrics stay close to the original, so the speed gain does not obviously come at the cost of reconstruction quality.","The resource figures (8 percent of LUTs and 40 percent of DSPs) suggest the same FPGA could host a second copy of the network for parallel processing, roughly doubling throughput.","FPGA-based training could lower energy per training run and make telemedicine scenarios practical, because the accelerator can sit inside the scanner rather than in a GPU cluster.","The same hardware approach extends to other MRF parameter sets: retraining for different T1/T2 ranges or field strengths is just another training run on the same blocks."],"supporting_citations":[{"why":"Introduces MRF and the dictionary-based reconstruction problem that the neural network replaces.","marker":"[3]"},{"why":"Proposes the original nine-layer fully connected network for MRF parameter maps, the architecture this paper adapts.","marker":"[6]"},{"why":"Documents the deep-learning MRF reconstruction approach, its scaling behavior, and the software baseline the FPGA port is compared with.","marker":"[7]"},{"why":"Example of an FPGA-accelerated neural network for MRI that runs inference only, motivating the paper's move to on-FPGA training.","marker":"[9]"},{"why":"Reports CPU and GPU speedups for an FPGA MLP processor, used as prior evidence that FPGA acceleration is feasible.","marker":"[10]"},{"why":"Adam optimizer used in the original software training, defining the optimization schedule the FPGA version must replace or approximate.","marker":"[11]"},{"why":"TensorFlow/Keras implementation used for the CPU training baseline and for quantization procedures.","marker":"[12]"},{"why":"Quantization-aware training method that produces the full-integer network enabling efficient FPGA arithmetic.","marker":"[13]"}],"fun_headline_variants":["FPGA trains MRF network in 200 seconds","MRF brain mapping network trains on FPGA in minutes","250x faster MRF training on FPGA hardware","Real-time MRF parameter mapping via FPGA training","FPGA enables 200-second retraining for MRF scans"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that reusing one 16-node forward block and one 16-to-32-node backpropagation block covers every layer of the whole network at a fixed cost of 56 plus 104 clock cycles per training sample, with no additional latency from memory access, data transfer, control logic, optimizer updates, or layer-to-layer differences.","fun_headline_variants_meta":{"raw":{"variants":["FPGA trains MRF network in 200 seconds","MRF brain mapping network trains on FPGA in minutes","250x faster MRF training on FPGA hardware","Real-time MRF parameter mapping via FPGA training","FPGA enables 200-second retraining for MRF scans"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000254,"raw_usage":{"total_tokens":1525,"prompt_tokens":860,"completion_tokens":665,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":476,"completion_tokens_details":{"reasoning_tokens":589}},"tokens_in":476,"tokens_out":665,"duration_ms":6989,"temperature":1.0,"reasoning_tokens":589,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T22:09:38.446442+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the actual training on an Alveo U250 with the same 250 million simulated MRF signals streamed over PCIe under the same 500-epoch, 1000-step schedule, and measure wall-clock time. If the measured time exceeds roughly five minutes by a significant margin, the 200-second estimate and the 200-times speedup over CPU do not hold.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Proposes the original nine-layer fully connected network for MRF parameter maps, the architecture this paper adapts."},{"cited_title":"BMC bioinformatics 22(1), 421 (2021) https://doi.org/10.1186/ s12859-021-04347-6","cited_arxiv_id":null,"evidence_quote":"Example of an FPGA-accelerated neural network for MRI that runs inference only, motivating the paper's move to on-FPGA training."},{"cited_title":"BMC Bioinformatics 19 (2018) https://doi.org/10.1186/s12859-018-2505-7","cited_arxiv_id":null,"evidence_quote":"Reports CPU and GPU speedups for an FPGA MLP processor, used as prior evidence that FPGA acceleration is feasible."},{"cited_title":"International Conference on Learning Representations (2014)","cited_arxiv_id":null,"evidence_quote":"Adam optimizer used in the original software training, defining the optimization schedule the FPGA version must replace or approximate."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"TensorFlow/Keras implementation used for the CPU training baseline and for quantization procedures."}],"review_version":1}