{"id":"a0d26ab1-7536-4de7-92d5-14b8c98c2ce3","arxiv_id":"2501.00686","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A soft-core processor based Ethernet DAQ module for RPC detectors in the INO-ICAL experiment reports event dead times near 125 microseconds and was validated on a 20-unit mini-ICAL prototype.","lead":"The authors built and tested a network-connected data acquisition module for the proposed INO-ICAL neutrino detector, using an FPGA soft-core processor to handle event readout, detector health monitoring, high-voltage control, and remote firmware updates. The design aims to run 28,800 detector units with only Ethernet connections back to a few servers.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Dead-time numbers are internally inconsistent and the operational random-trigger test was never done; at 2 kHz Poisson triggers, the measured 250–500 µs dead time loses 39–63%, so the 'meets 2 kHz' claim is unsupported.","rationale":"The reader's weakest_assumption correctly flags that mini-ICAL validation with fixed-frequency triggers and a 500 µs blocking window is not representative of full ICAL operation, and that no scaling or network-congestion analysis supports the jump from 20 to 28,800 units. I agree with that concern, but I see the more immediate and quantifiable problem as per-DAQ dead time: even before considering network scaling, the arithmetic in Table 3 is incompatible with the dead-time values stated in Table 2 and Section 8. The paper explicitly says physics triggers occur randomly at 2 kHz, yet the only deployed test used fixed-frequency triggers. Using the paper's own 250–500 µs mICAL dead time and a Poisson arrival model, the accepted trigger rate falls below 2 kHz, so the central claim that the current design 'meets the trigger and data throughput requirements' is not supported. The 125 µs hardware-accelerated scheme is a plausible fix, but it has not been deployed, and even 125 µs would incur ~22% loss at 2 kHz Poisson rate, not the ~0% shown in Table 3. I retain the reader's conditional verdict rather than moving to reject, because the proposed hardware acceleration might resolve the dead-time problem if validated in situ; however, the paper needs a corrected loss analysis, a real Poisson-trigger test, and a scaling study before the production-readiness conclusion can be accepted.","tokens_in":7716,"tokens_out":7798,"duration_ms":78534,"concrete_test":"","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim rests on the RPC-DAQ handling 2 kHz random physics triggers at ~120-byte average event size. The paper's own numbers contradict this. Section 4 first states an event dead-time of 350 ns, but Table 2 totals 281 µs for a 600-byte event. Section 8 says the mICAL firmware 'incurs a dead time of around 250 to 500 microseconds' and uses a 500 µs trigger blocking window. Table 3 then reports losses of 0.0006–0.0022% at 5 kHz random triggers, which would require a dead time below 1 µs, not 125–500 µs. For a 2 kHz Poisson trigger source, the loss formula 1−exp(−λτ) gives 22% loss at the claimed 125 µs dead time and 39–63% at 250–500 µs; a fixed 500 µs blocking window alone drops the accepted rate far below 2 kHz. Because the only in-situ tests used fixed-frequency triggers with the blocking window enabled, and because the improved 125 µs scheme was 'tested only in the test-bench and has not been deployed in the real experiment yet', the paper does not demonstrate that the current design meets the 2 kHz random-trigger requirement. The full-scale network-congestion question is additional, but the per-DAQ dead-time arithmetic is sufficient to undermine the stated conclusion.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes an FPGA-based RPC-DAQ for the INO-ICAL experiment, with a NIOS II soft-core processor implementing event readout, health monitoring, HV control, command handling, and remote firmware upgrade over a 100 Mbps Ethernet interface using a Wiznet W5300 controller. It reports bench measurements of dead time and event loss at trigger rates up to 5 kHz, and describes commissioning of 20 modules in the mini-ICAL prototype. The central claim is that the system meets the experiment's requirements of a 2 kHz minimum trigger rate and 2 Mbps event throughput.","tokens_in":7962,"tokens_out":6626,"duration_ms":56583,"significance":"If the central claim were established, the paper would provide a useful engineering template for distributed DAQ in large neutrino detectors, especially the NIOS software architecture, the command handshaking scheme, and the remote firmware upgrade protocol. The strengths are the detailed description of the socket configuration, the HPCI command interface, and the in-situ commissioning in mini-ICAL. However, because the dead-time and loss data are internally inconsistent and the 2 kHz random-trigger requirement was not tested, the main performance claim is currently unsupported. With corrected measurements and a proper dead-time model, the design could be a valuable contribution to JINST.","major_comments":[{"comment":"The reported dead-time values and loss percentages are internally inconsistent. Section 4 states that an event dead time of 350 ns is achieved for a 600-byte event, while Table 2 gives a total dead time of 281 µs for the same event size. At a random trigger rate of 5 kHz, the Poisson loss fraction 1 − exp(−λτ) would be about 75% for τ = 281 µs and about 46% for τ = 125 µs, not the 24.8% and 0.0014% shown in Table 3 for 600-byte events. The 24.8% figure is close to the loss expected for 281 µs at 1 kHz, not 5 kHz, and the 0.0006% entry for 120 bytes would require a dead time below 1 µs. The loss percentages therefore do not follow from the stated dead times, and the Section 10 claim that the system 'meets the trigger and data throughput requirements' is not supported by the presented data.","section":"§4, Table 2, Table 3"},{"comment":"The in-situ validation used fixed-frequency triggers with a 500 µs trigger blocking window, not the random 2 kHz Poisson triggers specified in Section 2. With the stated mICAL dead time of 250–500 µs, a 2 kHz Poisson source would lose between 1 − exp(−0.5) ≈ 39% and 1 − exp(−1) ≈ 63% of triggers. The mICAL tests therefore do not demonstrate that the system can record events at the required 2 kHz random trigger rate, and the conclusion that the system has undergone 'successful testing within the mICAL' overstates what was actually tested.","section":"§8, §2"},{"comment":"The hardware-accelerated Ethernet FIFO access that reduces dead time from 281 µs to 125 µs 'has been tested only in the test-bench and has not been deployed in the real experiment yet.' This is the only configuration for which the paper claims an improved dead time, yet the deployed mICAL system uses the 250–500 µs firmware. The central throughput claim therefore rests on an untested configuration, and even the 125 µs value would still lose about 22% of triggers at 2 kHz Poisson.","section":"§4, last paragraph"},{"comment":"The paper extrapolates from a 20-DAQ mini-ICAL setup with one Data Concentrator to 28,800 DAQs with two tiers of Gigabit Ethernet switches, but provides no queuing, bandwidth, or congestion analysis. At the stated 1.92 Mbps average event throughput per DAQ (120 bytes at 2 kHz), a single 1 Gbps link would saturate with only a few hundred simultaneous event streams, so the full-scale 'ready for production' claim requires a quantitative scaling argument that is absent.","section":"§3, §8"}],"minor_comments":[{"comment":"The table header 'Dead Time 281 (μs) 125 (μs)' lacks a column label and a statement of the loss formula; please specify that these are per-event dead times and give the exact model used to compute the percentages.","section":"Table 3"},{"comment":"The sentence 'an event dead-time of 350 ns is achieved' appears to be a typo, since Table 2 and the following paragraph use 281 µs as the per-event dead time; please correct and reconcile.","section":"§4"},{"comment":"The statement that this RPC-DAQ version 'is finalized and ready for production' conflicts with Section 4's statement that the reduced-dead-time scheme has not been deployed; please clarify which firmware version is production-ready.","section":"§8"},{"comment":"The requirement is stated as a 'minimum trigger rate of 2 kHz', but the conclusion claims an 'optimal trigger rate of 5 kHz'; please define whether 5 kHz is a demonstrated upper limit or a design target, and distinguish it from the experiment's actual requirement.","section":"§2, §10"},{"comment":"The worst-case command processing time of 615 µs is not tied to the dead-time budget; please comment on whether command processing during event runs can contribute to trigger loss.","section":"§3"}],"recommendation":"major_revision","confidential_remarks":"The dead-time inconsistencies are serious enough that I would not accept the paper in its current form. However, the issues are in principle fixable with corrected measurements, a clear dead-time model, and a scaling analysis, so I recommend major revision rather than rejection. The paper may be better framed as a design description with a narrower performance claim until the 2 kHz random-trigger test is actually performed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a straightforward engineering report on the software side of the INO-ICAL RPC-DAQ, and the Nios/Wiznet work is real. But the dead-time numbers are self-contradictory, and the paper's central claim that the system meets the 2 kHz random-trigger requirement does not hold up.\n\nWhat's actually new: the hardware-accelerated Wiznet FIFO access (reducing the FIFO transfer step from 190 µs to 35 µs in test-bench) and the mini-ICAL commissioning with 20 RPC-DAQs. The command-processing, monitoring, HV control and remote firmware-upgrade software descriptions are detailed and useful. The mini-ICAL tests show the modules work in situ, which is real evidence.\n\nThe soft spots are not minor. Section 4 claims a 350 ns dead time for a 600-byte event, while Table 2 totals 281 µs for the same operation. Section 8 puts the mICAL firmware dead time at 250–500 µs with a 500 µs trigger block. Table 3 then reports event losses of 0.0006–0.0022% at 5 kHz random triggers. For a Poisson trigger process at 5 kHz, 281 µs dead time loses about 75%; 125 µs loses about 46%. The table is off by orders of magnitude. At the actual 2 kHz requirement, the claimed 125 µs dead time loses about 22%, and 250–500 µs loses 39–63%. The conclusion that the design meets the requirement is not supported by the paper's own evidence.\n\nOn top of that, the improved 125 µs scheme is explicitly test-bench-only, not deployed in mICAL. The in-situ tests used fixed-frequency triggers with the blocking window enabled, which does not exercise random 2 kHz physics triggers. And there is no scaling or network-congestion analysis for moving from 20 units to 28,800.\n\nThis is fixable. The engineering description is coherent, and the commissioning results, however limited, are real. The authors need to correct the dead-time arithmetic, report actual measured loss rates, and either provide a scaling analysis or soften the production-readiness claim. A serious referee would flag exactly these issues.\n\nRecommendation: send to peer review with the expectation of major revision. The errors are central but correctable, and the detector-instrumentation community could use this documentation if the numbers are made honest.","headline":"Useful engineering write-up, but the dead-time numbers are self-contradictory and the central performance claim does not hold.","tokens_in":8525,"tokens_out":4877,"would_cite":false,"duration_ms":41170,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"An RPC-DAQ built around a NIOS soft-core processor and a Wiznet Ethernet controller is reported to meet the INO-ICAL requirements of 2 kHz minimum trigger rate and 2 Mbps throughput, with validation in the 20-unit mini-ICAL prototype.","keywords":["data acquisition module","FPGA","NIOS II soft-core processor","INO-ICAL","resistive plate chamber","Ethernet","event dead time","remote firmware upgrade"],"falsifier":"A scaling test with several hundred RPC-DAQs streaming 120-byte events at random 2 kHz triggers through the two-tier Gigabit switch network, with command and monitoring traffic running at the same time, would show whether per-unit event loss stays at the designed fractions; if losses rise measurably above the paper's Table 3 values, the claim that the design meets INO-ICAL requirements fails.","tokens_in":7517,"feed_emoji":"⚛️","tokens_out":9935,"duration_ms":93848,"temperature":0.7,"pith_summary":"This paper describes a data-acquisition board, the RPC-DAQ, in which an Intel Cyclone IV FPGA instantiates a NIOS II soft-core processor and communicates with a hardwired Wiznet W5300 Ethernet controller. The design is proposed as the complete control, monitoring, and event-transfer solution for the 28,800 resistive plate chambers of the planned INO-ICAL neutrino detector. The central claim is that this combination meets the experiment's stated requirements: a minimum average trigger rate of 2 kHz, event throughput up to 2 Mbps, and an average event size of about 120 bytes. The paper reports dead times of 281 microseconds for 600-byte events, reducible to 125 microseconds by moving the Ethernet FIFO access into hardware handshake logic, and a mini-ICAL test with 20 RPC-DAQs is used to argue the system is ready for production. A reader would take away that a customizable soft-core processor on an FPGA, paired with an Ethernet controller, can absorb the distributed data acquisition and control duties of a large detector array.","feed_headline":"Soft-core processor DAQ meets INO-ICAL trigger needs","feed_subtitle":"NIOS-based RPC readout handles 2 kHz triggers and cuts event dead time to 125 microseconds","key_machinery":"The load-bearing mechanism is the NIOS II soft-core processor and its interrupt-driven software stack, configured with event handling at highest priority, UDP command handling next, and monitoring third. The event path is the SCEDA scheme: the event ISR fills a hardware event FIFO, the main loop transfers it to the W5300 transmit socket, and the FIFO space decides whether to block the next trigger; this converts trigger handling into a buffering problem. The Wiznet W5300 supplies six sockets with fixed transmit and receive buffers, and the dead-time improvement comes from a hardware handshake that shifts W5300 FIFO access out of NIOS software, cutting the write cycle from 350 to about 80 nanoseconds and the FIFO transfer time from 190 to 35 microseconds. Command reliability is provided by a hybrid UDP protocol with a 16-bit CRC and optional acknowledgment, and remote firmware upgrade runs over TCP using Begin, Data, Fin, and Ack packets written to flash pages.","core_discovery":"On the paper's own terms, the discovery is that a NIOS II soft-core processor on a Cyclone IV FPGA, working with the Wiznet W5300 Ethernet controller, can act as the embedded computer inside each RPC-DAQ. When a global trigger arrives, the event interrupt service routine reads X/Y strip and timing information and writes variable-length event records into a hardware event FIFO; the main loop then transfers the FIFO contents to the W5300 transmit buffer and onto the network. Separate sockets carry TCP event data, TCP monitoring data, remote firmware upgrade traffic, and UDP multicast/unicast command traffic, and the software includes CRC-checked command handshakes, health-monitoring interrupts, SPI-based high-voltage control, and flash-based remote firmware upgrade. The paper's quantitative claim is that this system meets the INO-ICAL run requirements of 2 kHz minimum trigger rate and up to 2 Mbps throughput, with average 120-byte events, and that the event dead time for 600-byte events can be reduced from 281 to 125 microseconds by moving Wiznet FIFO writes from software to hardware handshake logic. The 20-unit mini-ICAL deployment, where the firmware runs at 50 MHz with 250 to 500 microseconds dead time and a 500 microsecond trigger-blocking window, is presented as evidence that the design is mature and ready for production.","pith_inferences":["The full-scale claim would benefit from a network-congestion study the paper does not include: emulating thousands of simultaneous TCP event streams and UDP command packets through two tiers of Gigabit switches would show whether per-unit throughput holds.","The 125 microsecond dead-time path is a test-bench result, so inserting it into the mICAL firmware and measuring under random physics triggers would turn an achievable claim into a demonstrated one.","The same soft-core-plus-network-controller pattern could be reused in other large distributed detectors as a low-cost, remotely upgradeable per-channel DAQ architecture, with firmware scheduling of soft-core timing becoming the main design constraint."],"forward_implications":["At a random 5 kHz trigger rate, the computed event-loss fraction for 120-byte average events is 0.0022% with 125 microsecond dead time, giving margin above the 2 kHz INO-ICAL requirement.","Remote firmware upgrade takes about 21 seconds per module and can upgrade 10 modules simultaneously in that time, with batching enabling 100-module campaigns.","The NIOS software handles high-voltage control, rate monitoring, command execution, and event transfer over standard TCP/IP and UDP, so back-end servers can run the detector over Ethernet without per-module physical access.","The mICAL deployment with 20 RPC-DAQs is reported as successful validation, and the paper states the RPC-DAQ version is finalized and ready for production."],"supporting_citations":[{"why":"Supplies the RPC-DAQ module's earlier performance review, the baseline this paper's software and dead-time work extends.","marker":"[1]"},{"why":"Introduces the soft-core processor based data acquisition concept for ICAL RPCs that this paper implements and details.","marker":"[2]"},{"why":"Defines the INO-ICAL experiment and its scale, providing the 28,800-RPC context and the requirements the design must meet.","marker":"[4]"},{"why":"Provides the Ethernet command and data acquisition scheme, including the TCP/UDP socket structure adopted by the NIOS software.","marker":"[5]"},{"why":"Describes the back-end data concentrator systems that receive and process the RPC-DAQ event streams.","marker":"[6]"},{"why":"Gives the W5300 write-cycle timing used to compute the reduced dead time when FIFO access moves to hardware.","marker":"[7]"},{"why":"Provides the remote firmware upgrade protocol that the RFU implementation builds on.","marker":"[9]"},{"why":"Describes the mini-ICAL prototype where the 20 RPC-DAQ modules were integrated and tested.","marker":"[10]"}],"fun_headline_variants":["NIOS II soft-core runs RPC-DAQ for INO-ICAL","Soft-core DAQ cuts dead time to 125 µs for INO-ICAL","NIOS II + W5300 power 28,800 network DAQs","FPGA soft-core enables 2 kHz trigger DAQ","NIOS II meets INO-ICAL 2 Mbps DAQ throughput"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The claim rests on the assumption that behavior observed with 20 RPC-DAQs in the mini-ICAL prototype, driven by fixed-frequency triggers with a 500 microsecond pause after each trigger, will hold when 28,800 units run under random 2 kHz physics triggers and share two tiers of Gigabit Ethernet switches; the paper's improved 125 microsecond dead-time path is also only a test-bench result, not a deployed measurement.","fun_headline_variants_meta":{"raw":{"variants":["NIOS II soft-core runs RPC-DAQ for INO-ICAL","Soft-core DAQ cuts dead time to 125 µs for INO-ICAL","NIOS II + W5300 power 28,800 network DAQs","FPGA soft-core enables 2 kHz trigger DAQ","NIOS II meets INO-ICAL 2 Mbps DAQ throughput"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000336,"raw_usage":{"total_tokens":1924,"prompt_tokens":1075,"completion_tokens":849,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":691,"completion_tokens_details":{"reasoning_tokens":751}},"tokens_in":691,"tokens_out":849,"duration_ms":8363,"temperature":1.0,"reasoning_tokens":751,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T22:44:13.956290+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A scaling test with several hundred RPC-DAQs streaming 120-byte events at random 2 kHz triggers through the two-tier Gigabit switch network, with command and monitoring traffic running at the same time, would show whether per-unit event loss stays at the designed fractions; if losses rise measurably above the paper's Table 3 values, the claim that the design meets INO-ICAL requirements fails.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the RPC-DAQ module's earlier performance review, the baseline this paper's software and dead-time work extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the soft-core processor based data acquisition concept for ICAL RPCs that this paper implements and details."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the INO-ICAL experiment and its scale, providing the 28,800-RPC context and the requirements the design must meet."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the Ethernet command and data acquisition scheme, including the TCP/UDP socket structure adopted by the NIOS software."},{"cited_title":"Phys.277 (2022) 839–842","cited_arxiv_id":null,"evidence_quote":"Describes the back-end data concentrator systems that receive and process the RPC-DAQ event streams."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Gives the W5300 write-cycle timing used to compute the reduced dead time when FIFO access moves to hardware."},{"cited_title":"Yuvaraj, M","cited_arxiv_id":null,"evidence_quote":"Provides the remote firmware upgrade protocol that the RFU implementation builds on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Describes the mini-ICAL prototype where the 20 RPC-DAQ modules were integrated and tested."}],"review_version":1}