{"id":"66382dcc-a371-40e4-9c36-4f519b950e3f","arxiv_id":"2607.12126","paper_version":1,"verdict":"UNVERDICTED","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"An Artix-7 FPGA receives 16×16 grayscale images over UART, stores them in BRAM, detects and corrects injected offset/gain pixel errors with fixed thresholds, and returns the image with LED/LCD error reporting.","lead":"A student team built a small FPGA demo that receives a 16\times16 grayscale test image, finds artificial offset and gain pixel errors, corrects them in on-chip memory, and returns the image while showing error counts and locations. It is an educational proof-of-concept of the digital steps between a detector and a host PC, not a new medical imaging method.","discovery_kind":"incremental","skeptic_critique":{"model":"grok-4.5","headline":"No significant objection identified beyond the reader's framing of this as an educational prototype.","rationale":"The manuscript is an ECE course project that demonstrates UART receive into BRAM, threshold-based offset/gain flagging, constant replacement, UART return, LED count, and LCD coordinate display on hand-injected 16×16 grayscale frames. Section 4.3's claim is limited to that pipeline succeeding on the demos; Sections 1.2 and 2.1 already disclaim commercial-detector fidelity. The reader's weakest_assumption (fixed thresholds + baseline replacement on synthetic data) is therefore a correct characterization of limited transferability, but it is not a soft spot under the claim the paper actually makes. Residual BRAM shift and LCD lag are real and reduce polish, yet the paper reports them and still shows correct error counts and locations. No independent code/data release exists, novelty is teaching-level, and the long self-citation block does not support the demo; none of these overturn the UNVERDICTED educational-prototype framing. A concrete latency-pipeline re-test would settle whether the remaining bug is cosmetic. Verdict stays UNVERDICTED.","tokens_in":14285,"tokens_out":498,"duration_ms":4868,"concrete_test":"Re-run the light-image demo after inserting one extra FSM wait state between BRAM address update and write-back (or capture of bram_dout) and check whether the one-column shift disappears while LED error count and LCD coordinates remain correct; if the shift vanishes and counts stay matched, residual latency is a fixable implementation detail rather than a pipeline-correctness failure.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's strongest claim is a working proof-of-concept pipeline on synthetic 16×16 data (Section 4.3), not a claim that fixed thresholds and constant-baseline replacement transfer to real detector nonuniformity. The residual one-column BRAM-latency shift (Section 4.1.3) and unspecified exact thresholds are acknowledged bugs, but they do not falsify the enumerated demo steps that the claim actually asserts. The reader's weakest_assumption correctly notes limited realism, yet that is a scope limitation the authors already state (Sections 1.2, 2.1, 4.2), not a hidden load-bearing failure of the reported result.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The manuscript presents a class-scale FPGA proof-of-concept for a simplified X-ray detector front-end on an Artix-7 AC701 board. A host Python script generates 16×16 grayscale test images with deliberately injected offset or gain defects, sends them over UART, and receives a corrected image. On the FPGA, a modular pipeline stores the frame in BRAM, uses a DIP-switch-selected mode to flag pixels against fixed dark/gain thresholds, replaces flagged pixels with constant baselines (10 or 180), stores error coordinates, returns the corrected frame, reports the error count on LEDs, and displays error locations on an LCD under button control. Implementation results report very low utilization, timing closure at 10 MHz, and successful detection of the injected defects in dark and light demos, with an acknowledged residual one-column shift in the returned light image attributed to BRAM latency.","tokens_in":14462,"tokens_out":1266,"duration_ms":11082,"significance":"As an educational demonstration of modular FPGA design for a medical-imaging-inspired pipeline (UART, BRAM arbitration, image-processing FSM, LCD feedback), the work is useful and the hardware demos (Figures 8–9, Tables 2–3) and resource/timing numbers are concrete. It does not claim a new detector-correction algorithm or transfer to real flat-field calibration; the contribution is a working, documented student-scale system that separates communication, memory ownership, and correction. That limited claim is supported by the reported demos. The long closing citation block to the same research group does not add technical novelty to the pipeline itself.","major_comments":[{"comment":"The manuscript is written as a course final-project report (motivation from lab experience, class LCD notes [5], “bonus” LCD, residual bugs left for future work) rather than a research article. For a serious cs.AR journal, the central claim is only a working 16×16 synthetic demo; there is no comparison to prior FPGA front-ends beyond brief citations, no quantitative latency/throughput analysis of the pipeline, and no evaluation against real detector data or standard flat-field methods. Without a clear research question and baseline comparison, the work does not meet typical archival standards even if the demo is correct.","section":null},{"comment":"Section 3.1.3 and 4.1.2–4.1.3: correction is fixed-threshold flagging plus replacement by constant baselines (dark=10, light=180). Exact threshold values are never stated, and no calibration-frame or per-pixel gain-map path is implemented. The authors acknowledge this as a simplification (Sections 1.2, 2.1, 4.2), but the abstract and introduction still frame the work as a mini X-ray detector front-end. Either the claim language must be narrowed strictly to “synthetic threshold demo” or a more representative correction path (or at least explicit thresholds and sensitivity analysis) is needed for the medical-imaging framing to hold.","section":null},{"comment":"Section 4.1.3 reports a residual one-column shift in the returned light image, attributed to BRAM read latency / FSM alignment, and Section 3.3 notes remaining latency issues. Because the strongest claim (Section 4.3) includes returning a correctly ordered corrected image, this is a load-bearing functional defect for the output path. A fix (explicit address/data pipelining or corrected write-back/TX sequencing) or a clear demonstration that the shift is eliminated should be required before acceptance of the pipeline claim.","section":null}],"minor_comments":[{"comment":"Abstract and Section 1.1 largely repeat the same medical-imaging motivation paragraph; tighten and state the concrete 16×16 UART–BRAM–correct–return scope up front.","section":null},{"comment":"Figures 1–9 are referenced but not available as high-resolution captions with signal names; ensure waveforms (Figures 3–6) label key signals (process_start, bram_we, error_count, etc.) so the simulations are reproducible from the text alone.","section":null},{"comment":"References [6]–[59] are almost entirely from one research group and are used mainly to assert that FPGAs are generally suitable; prune to works that directly inform detector front-ends, flat-field correction, or the specific architecture choices.","section":null},{"comment":"Table 1 and peripheral description are clear; add the exact dark/high-gain/low-gain threshold constants and BRAM address map (image 0–255, error list from 256) in a small table for reproducibility.","section":null},{"comment":"Minor typos and formatting: “frontend”/“front-end” inconsistency, “image process core” vs “image-processing,” and incomplete DOI/URL punctuation in the reference list.","section":null}],"recommendation":"major_revision","confidential_remarks":"Fit for a serious journal is marginal: this reads as a solid ECE course project report with honest residual bugs, not as a research contribution in FPGA architecture or medical imaging electronics. The self-citation block ([6]–[59]) is disproportionate to the technical content and may raise editorial concerns about padding. If the venue is a student/education track or workshop, minor revision after fixing the column-shift and narrowing claims could suffice; for a standard research track I would lean reject unless the authors add a clear research delta (e.g., comparison, larger images, real calibration path, or open HDL)."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"This is a cleanly written ECE rapid-prototyping project report, not a research advance. The authors built a modular Artix-7 pipeline that takes a 16×16 synthetic grayscale image over UART, stores it in BRAM, flags offset or gain errors by fixed thresholds, writes corrections and error coordinates, returns the image, and shows counts/locations on LEDs and an LCD. That pipeline works for the injected defects they put in, meets timing at 10 MHz with very low utilization, and is documented with block diagrams, FSM arbitration, and simulation waveforms. For a class project that is exactly what you want: clear modularity, honest residual bugs (one-column BRAM-latency shift, LCD lag), and a future-work section that knows the difference between constant-baseline replacement and real flat-field calibration.\n\nWhat is new is essentially nothing algorithmic or architectural. UART RX/TX, single-port BRAM frame buffer, threshold scan, and top-level ownership muxing are standard lab techniques. The medical-imaging framing is motivational scaffolding; the authors themselves say they are not building a real detector front-end. The long closing citation block ([6]–[59]) is almost entirely the advisor group’s prior FPGA work and does not support the demo. Exact threshold values are never stated, and no code or data are released, so independent re-run is impossible.\n\nThose are scope and presentation limits, not hidden failures of the claim they actually make. The claim is a working proof-of-concept on synthetic data with known defects; the demos and tables match that claim. Realism of fixed thresholds on 256 pixels is a limitation they already flag, not a load-bearing flaw.\n\nWho gets value: instructors and students looking for a worked example of BRAM arbitration and image-path FSMs. Not someone hunting a new correction method or clinical front-end result. I would not cite it for research, and I would not bring it to reading group. A serious editor would desk-reject it as a research submission; it is fine as a technical report or teaching artifact. No need to spend referee time on it as a journal paper.","headline":"Solid course-project demo of a modular UART/BRAM/FSM image-correction pipeline; educational value is real, research novelty is not.","tokens_in":15061,"tokens_out":530,"would_cite":false,"duration_ms":4927,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"A small FPGA pipeline can receive, store, detect, correct, and return synthetic X-ray-style pixel errors in real time.","keywords":["FPGA","medical imaging front-end","offset correction","gain correction","BRAM","UART","X-ray detector simulation","Artix-7"],"falsifier":"Run the same dark and light test images through the board and check whether every deliberately injected error pixel is both counted on the LEDs, listed at the correct (x,y) on the LCD, and restored to the exact baseline value (10 or 180) in the returned image with no residual column shift or missed detections.","tokens_in":15146,"feed_emoji":"💻","tokens_out":845,"duration_ms":9433,"temperature":0.7,"pith_summary":"This project shows that a classroom-scale FPGA can act as a mini detector front-end: it takes a 16×16 grayscale test image from a PC, holds it in on-chip memory, finds offset or gain pixel defects, fixes them, and sends the cleaned image back while reporting error counts and locations on board LEDs and an LCD. The work is deliberately simplified—no real X-ray sensor—but it walks through the same digital steps a real imaging front-end needs: transfer, frame buffering, analysis, correction, and feedback. A sympathetic reader cares because medical imagers need predictable, low-latency hardware between the sensor and the display, and FPGAs are a practical way to prototype that path without fabricating a custom chip. The design stays modular so each block can be built and checked alone before the whole pipeline is stitched together.","feed_headline":"FPGA pipeline finds and fixes fake X-ray pixel errors","feed_subtitle":"16×16 grayscale frames travel PC–FPGA–PC with offset/gain correction, LED counts, and LCD locations","key_machinery":"A top-level control FSM that arbitrates single-port BRAM ownership among the UART receive controller, image-processing core, UART transmit controller, and LCD logic so only one module drives memory at a time while the image core scans row-major, thresholds pixels, packs error coordinates, and writes corrected baselines.","core_discovery":"The completed FPGA design successfully receives a 16×16 grayscale image over UART, stores it in BRAM, detects offset or gain-related pixel errors according to a selected mode, corrects those pixels, returns the corrected image to the host, shows the error count on LEDs, and lists stored error locations on an LCD, thereby proving a working proof-of-concept of the major detector-front-end pipeline steps.","pith_inferences":["The same arbitration pattern could be reused for streaming larger frames if multi-ported or dual-buffer memory replaced the single-port BRAM.","Replacing constant baselines with a short calibration-pass average would move the design closer to real flat-field correction without changing the outer FSM.","The residual one-column shift points to a general lesson: synchronous BRAM latency must be pipeline-matched in any write-back image path."],"forward_implications":["A modular UART–BRAM–FSM pipeline can demonstrate detector-style offset and gain correction without a physical X-ray sensor.","Low resource use (under 0.5 % LUTs/FFs, half a BRAM block) leaves headroom for larger frames or extra defect types on the same Artix-7 board.","Separate RX/TX controllers and a single clock domain keep serial transfer and image logic independently debuggable.","Fixed-threshold correction plus LED/LCD feedback is enough for a controlled classroom proof-of-concept of front-end data flow."],"fun_headline_variants":["FPGA spots and fixes offset-gain errors in 16x16 X-ray frames","Mini FPGA pipeline detects corrects fake pixels shows LED LCD faults","UART-BRAM FPGA corrects X-ray pixel errors returns frames with counts","FPGA front-end proof: fix gain-offset pixels list locations on LCD","16x16 grayscale FPGA demo finds fixes errors lights LEDs displays sites"],"cache_read_input_tokens":128,"weakest_assumption_plain":"The claim rests on treating a few hand-placed defects in a tiny synthetic grayscale image, fixed numeric thresholds, and constant baseline replacement as enough to stand in for real detector offset and gain nonuniformity.","fun_headline_variants_meta":{"raw":{"variants":["FPGA spots and fixes offset-gain errors in 16x16 X-ray frames","Mini FPGA pipeline detects corrects fake pixels shows LED LCD faults","UART-BRAM FPGA corrects X-ray pixel errors returns frames with counts","FPGA front-end proof: fix gain-offset pixels list locations on LCD","16x16 grayscale FPGA demo finds fixes errors lights LEDs displays sites"]},"model":"grok-4.5","effort":"low","cost_usd":0.005168,"raw_usage":{"total_tokens":1360,"prompt_tokens":652,"num_sources_used":0,"completion_tokens":82,"cost_in_usd_ticks":51680000,"prompt_tokens_details":{"text_tokens":652,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":626,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":652,"tokens_out":82,"duration_ms":5931,"temperature":1.0,"reasoning_tokens":626,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-15T07:31:22.550359+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Run the same dark and light test images through the board and check whether every deliberately injected error pixel is both counted on the LEDs, listed at the correct (x,y) on the LCD, and restored to the exact baseline value (10 or 180) in the returned image with no residual column shift or missed detections.","supporting_citations":[],"review_version":1}