REVIEW 4 major objections 5 minor 12 references
NIOS II Soft-Core Processor and Ethernet Controller Solution for RPC-DAQ in INO ICAL
T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash
Pith's one-line read 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.
desk verdict Useful engineering write-up, but the dead-time numbers are self-contradictory and the central performance claim does not hold. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
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.
What would settle it
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.
Extended reading notes
Core claim
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.
Load-bearing premise
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.
Editorial extensions
If this is right
- 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.
Reading between the lines
- 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.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
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.
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 (4)
- [§4, Table 2, Table 3] 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.
- [§8, §2] 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.
- [§4, last paragraph] 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.
- [§3, §8] 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.
minor comments (5)
- [Table 3] 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.
- [§4] 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.
- [§8] 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.
- [§2, §10] 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.
- [§3] 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.
Circularity Check
No circularity found: the paper's central claims rest on its own measurements and on externally specified requirements, not on self-referential definitions or fitted inputs.
full rationale
The paper is an engineering description with laboratory measurements: the SCEDA dead-time values in Table 2, the loss estimates in Table 3, and the mini-ICAL commissioning results in Section 8 are presented as measured or calculated outputs, not as restatements of the 2 kHz / 2 Mbps requirement. The cited prior work by the same authors ([1], [2], [5], [6], [9], [10]) supplies background, context, or protocol details, but the load-bearing performance claims are not derived from those citations; they are asserted from this paper's own test-bench and mICAL measurements. The self-citations are therefore not load-bearing, and no equation or parameter is defined in terms of the target conclusion. The internal inconsistency between the claimed 250–500 microsecond dead time, the 125 microsecond test-bench result, and the very small loss percentages in Table 3 is a scientific-validity concern rather than a circularity, as is the fact that the improved 125 microsecond scheme 'has been tested only in the test-bench and has not been deployed in the real experiment yet'. Those issues weaken the support for the 'meets the trigger and data throughput requirements' conclusion, but they do not make the derivation circular. Accordingly, no circular step is identified and the score is 0.
Assumptions & free parameters
assumptions (2)
- domain assumption Event triggers arrive as a stationary Poisson process at the stated average rate
- domain assumption The 20-DAQ mini-ICAL test configuration is representative of the full 28,800-DAQ ICAL network with two-tier Gigabit switches
Cite this review
Pith. "Pith review of NIOS II Soft-Core Processor and Ethernet Controller Solution for RPC-DAQ in INO ICAL." pith.science (2026). https://pith.science/paper/53DJQRQM
@misc{pith2026250100686,
author = {Pith},
title = {Pith review of: NIOS II Soft-Core Processor and Ethernet Controller Solution for RPC-DAQ in INO ICAL},
year = {2026},
howpublished = {\url{https://pith.science/paper/53DJQRQM}},
note = {Machine review of arXiv:2501.00686}
}
read the original abstract
This paper introduces a high-performance Soft-Core Processor based data acquisition system designed for handling Resistive Plate Chambers (RPCs). The DAQ consist of FPGA-based hardware equipped with Soft-Core Processor and embedded hardwired Ethernet controllers named RPC-DAQ, offering a versatile and fast network-enabled data acquisition solution. A soft processor, NIOS, is instantiated within an Intel Cyclone IV FPGA, overseeing control, communication, and data transfer with remote processing units. These integrated RPC-DAQ units, in substantial numbers, connect to a limited set of high-end processing units via LAN switches. This paper provides a detailed account of the software implementation scheme for the NIOS processor in the RPC-DAQ system. A remarkable 28,800 RPC-DAQ units will be deployed in proximity to the RPCs, serving the proposed INO-ICAL experiment in Theni-Madurai, Tamil Nadu. The network-enabled RPC-DAQ units controlled by the soft processor offloads FPGA tasks including event data acquisition, periodic health monitoring of RPCs, command interfaces, high voltage control, and data transfer to back-end data concentrators. Communication and data transfer are executed efficiently via TCP and UDP protocols over a 100 Mbps Ethernet interface. This system provides innovative solutions to improve data acquisition and control in large-scale scientific experiments.
Reference graph
Works this paper leans on
-
[1]
M. N. Saraf et al.,INO’s RPC-DAQ module: Performance review and upgrade plans, J. Phys.: Conf. Ser.2374 (2022) 012102
work page 2022
-
[2]
Mandar et all.,Soft-Core Processor Based Data Acquisition Module for ICAL RPCs with Network Interface,XXI DAE-BRNS High Energy Physics Symposium86(2014) 8–12
work page 2014
-
[3]
Cyclone IV Device Handbook,Altera, Intel,https://www.intel.com/content/www/us/en/content- details/653974/cyclone-iv-device-handbook.html(2016). – 12 –
work page 2016
-
[4]
INO Project Report, Volume 1, India Based Neutrino Observatory http://www.ino.tifr.res.in/ino/OpenReports/INOReport.pdf, (2006)
work page 2006
-
[5]
Nagaraj P, Saraf. M. N, Satyanarayana B, Sil D, Upadhya S. S, Yuvaraj E.,Ethernet Scheme for Command and Data Acquisition for the INO ICAL Detector,Springer Proc. Phys.203(2018) 863–865
work page 2018
-
[6]
Panyam Nagaraj et al.,Back-end Systems for Mini-ICAL,Springer Proc. Phys.277 (2022) 839–842
work page 2022
-
[7]
W5300 Chip Datasheet v1.3.4,https://www.wiznet.io/product-item/w5300/, (2019)
work page 2019
-
[8]
Serial Configuration Devices Data Sheet, Altera Corporation,Intel, https://www.intel.com/content/www/us/en/content-details/654137/serial-configuration-devices-data- sheet.html,(2003)
work page 2003
Show all 12 references
-
[9]
Yuvaraj, M
E. Yuvaraj, M. Saraf, S. S. Upadhya and B. Satyanarayana,An ethernet based remote system upgradation technique for FPGA based inaccessible digital systems,2016 IEEE Bombay Section Symposium (IBSS)(2016) 1–3
2016
-
[10]
Majumder, Gobinda and Mondal, Suryanaraya,Design, construction and performance of magnetised mini-ICAL detector module, PosICHEP2018(2019) 360
2019
-
[11]
Saraf M. N. et al.,Electronics and DAQ for the Magnetized mini-ICAL Detector at IICHEP,Springer Proc. Phys.261 (2021) 779–786
2021
-
[12]
HPTDC Version 1.3, https://cds.cern.ch/record/1067476/files/cer-002723234.pdf, (2004). – 13 –
2004
Reviewed August 10, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.