{"id":"47dfb74e-d703-46af-89db-6313d86bac9f","arxiv_id":"2607.03153","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Inter-stage liveness monitoring of a deployed L1 GNN trigger estimates MTTF up to 78.7% lower than output-only monitoring, revealing a detection-latency bias in current FPGA verification.","lead":"This paper injects more than 1.4 million simulated bit-flip faults into the FPGA design of Belle II's neural-network trigger to find where radiation-induced stalls occur. It shows that watching only the final output hides internal deadlocks and proposes monitoring between pipeline stages, which changes the estimated time-to-failure by up to 78.7%.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Per-stage MTTFs in Table IV are attributed to the silent AXI-Stream interface, not the fault origin; backpressure mislabels downstream faults as upstream GNN deadlocks, so the hardening-priority conclusion is unsupported even though the MTTF-inflation asymmetry holds.","rationale":"The reader's strongest claim, that output-only observation inflates MTTF estimates for DUEs, is well supported by the same-run comparison: earlier detection shortens measured time-to-failure, and the 78.7% deviation is a real consequence of the monitoring view. My concern targets a different part of the central claim: the per-stage attribution used to identify hardening priorities. The paper states 'each deadlock is attributed to a specific stage' but then admits that a Postprocessing stall is classified as a GNN DF output deadlock, so the attribution is to the first silent interface, not the fault origin. This is directly evidenced in the paper's own results and is not just an external limitation. The uniform cross-section assumption flagged by the reader is also a limitation, but the fixed-rate campaign reaches the same priorities, so it is less decisive. The offline-vs-live-monitor equivalence is plausible for detection timing and does not affect the internal comparison. The proposed single-fault re-run with cycle-accurate tracing would settle whether backpressure contamination is negligible or large enough to shift hardening priorities. The reader's CONDITIONAL verdict remains appropriate; no verdict change is needed, but the condition should include origin-tracing validation.","tokens_in":9689,"tokens_out":11812,"duration_ms":132885,"concrete_test":"Take a random sample of 500 fixed-rate Postprocessing-injected runs that were classified as 'GNN DF output' deadlocks. Re-run each with a single fault per run and cycle-accurate internal tracing (e.g., RTL waveforms or added per-stage progress counters) to identify the first stage that stops making forward progress and the signal that caused it. If most of these runs actually originate in Postprocessing, Table IV's per-stage MTTFs and the hardening-priority ranking must be re-derived; if the stall truly originates in the GNN or upstream, the attribution is adequate.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Inter-stage liveness monitoring identifies a deadlock by the first monitored interface that stays silent for more than 2 µs and labels that interface as the failing stage. This attributes the failure to the observation point, not to the fault origin. The paper's own §V-B shows the consequence: a stall in Postprocessing back-pressures the GNN-to-Postprocessing stream, so 4.13% of Postprocessing-injected proportional-rate runs and 33.14% of fixed-rate runs are classified as 'GNN DF output' deadlocks even though the fault was injected in Postprocessing. Because any downstream stall freezes all upstream interfaces, every per-stage deadlock column in Table IV except Belle2Link MAC (where no monitor sits downstream) is contaminated by backpressure. The per-stage MTTFs and the resulting 'highest-priority hardening targets' (GNN Dataflow Accelerator, Preprocessing) therefore conflate where the pipeline first appears silent with where the fault actually originated. The core asymmetry result, that output-only detection inflates MTTF and inter-stage monitoring lowers it by up to 78.7%, is not invalidated because earlier detection of any stall is still earlier; but the stated per-stage attribution is not supported by the measurements.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents an RTL fault-injection study of GNN-ETM, the Belle II L1 trigger module for the electromagnetic calorimeter, implemented on an FPGA. Using two campaigns (proportional-rate and fixed-rate injection) and approximately 1.44 million single-event upsets across 211,245 signals, the authors characterize deadlocks, timeouts, and packet-integrity violations. They compare the existing baseline detection setup (an HLS watchdog plus a Belle2Link output checker) with a proposed inter-stage AXI-Stream liveness monitoring approach, reporting that MTTF estimates differ by up to 78.7% and using per-stage data to identify the GNN Dataflow Accelerator and Preprocessing Stage as the highest-priority hardening targets.","tokens_in":9977,"tokens_out":3116,"duration_ms":36735,"significance":"If the central asymmetry claim holds, this is a valuable contribution: it is, to my knowledge, the first RTL fault-injection study of a deployed L1 hardware neural-network trigger, and the scale of the campaign is substantial. The two-campaign design is thoughtful, and re-analyzing the same simulation logs under two detection views is a clean way to isolate detection latency effects. The observation that output-only DUE detection systematically inflates MTTF is well motivated and internally consistent. However, the per-stage hardening-priority conclusion is undermined by the backpressure misattribution problem identified in the text itself, and the priority ordering also depends on the uniform-cross-section assumption. The paper's primary methodological point about monitoring placement is defensible, but the stronger per-stage claims need additional work.","major_comments":[{"comment":"The paper states that 4.13% (proportional-rate) and 33.14% (fixed-rate) of Postprocessing-injected runs are classified as GNN DF output deadlocks because a Postprocessing stall back-pressures the upstream interface. This is exactly the problem for the hardening-priority claim: every monitored interface that is upstream of a fault origin can be declared deadlocked when the fault actually injected downstream. Consequently, the per-stage MTTF columns in Table IV conflate the observation point with the fault origin, and the conclusion that the GNN Dataflow Accelerator and Preprocessing Stage are the highest-priority targets is not supported by these measurements. The paper should either report a joint distribution of injected target versus observed deadlock interface, or explicitly limit the claim to interface-level observability rather than component-level hardening priority.","section":"§V-B, Table IV"},{"comment":"The proportional-rate campaign assumes that sensitive area is uniformly distributed across signals, i.e., every signal has equal per-signal cross-section. The paper acknowledges this is necessary for a platform-agnostic RTL study, but the resulting MTTF ordering and the hardening priorities derived from it are sensitive to this assumption. If, for example, memory elements or particular control signals have materially higher per-signal cross-sections after FPGA mapping, the component-level rankings in Table IV could shift. A sensitivity analysis varying per-signal weights, or at least a qualitative statement of how robust the ordering is, is needed before the proportional-rate priority conclusion can be accepted.","section":"§IV-B, Eq. (2)"},{"comment":"The asserted equivalence between offline log re-analysis and an implemented live monitor ('An equivalent live monitor would catch the same events with the same detection latency') is an assumption, not a demonstrated fact. A hardware monitor would itself consume resources, may be affected by faults, and could interact with the pipeline's timing or backpressure behavior. The paper proposes these monitors as a practical addition, but it does not validate that the 2-µs silence threshold or the event classification observed in simulation would reproduce in hardware. At minimum, this should be framed as a design premise and an implementation/validation plan should be indicated.","section":"§IV-C"},{"comment":"The headline quantitative result is the MTTF deviation of up to 78.7%, but the reported 95% margin of error applies to percentage cells only. MTTF and MTTF-deviation values are presented as point estimates without confidence intervals. Since the magnitude of the deviation is a central claim, the authors should report uncertainty on the MTTF estimates (e.g., bootstrap or binomial-derived intervals), even if the qualitative direction of the asymmetry is clear.","section":"§V, Table IV"}],"minor_comments":[{"comment":"The MTTF deviation formula is not defined. Please state explicitly that it is (MTTF_baseline - MTTF_interstage)/MTTF_baseline × 100%, or give the definition in the text.","section":"Table IV caption"},{"comment":"The Full Design row is identical in the two campaigns and the total faults are counted once, but Table IV repeats the row and the caption does not clarify this relationship. A note would prevent confusion.","section":"Table III/IV"},{"comment":"The phrase 'a single bit of the targeted signal is flipped and remains flipped until the next normal write to that signal' is clear, but it may help to state explicitly whether the injected bit is in a flip-flop or could also be a wire/combinational node, given that the RTL signal set is heterogeneous.","section":"§IV-A"},{"comment":"The failure classes under inter-stage monitoring are described as mutually exclusive by priority, but the baseline classes (HLS watchdog, packet integrity, timeout) also need explicit priority ordering. The current text says only that inter-stage signatures take priority; the reader should know how a run with both a watchdog and a packet-integrity event is classified.","section":"§V-A"}],"recommendation":"major_revision","confidential_remarks":"The backpressure misattribution is the key issue; the paper itself contains the evidence against its own per-stage attribution. The asymmetry result is likely sound, but the abstract and conclusion overstate the hardening-priority finding. If the authors can reframe the per-stage claims as observability-based or provide a corrected attribution, the paper would be acceptable."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The thing you should know: this paper is genuinely first. Nobody has run RTL SEU injection on a deployed L1 hardware trigger running a neural network before, and the scale is serious — 1.44M injected faults across 211k signals, with two complementary campaigns. The core empirical claim, that output-only observation inflates MTTF for DUEs, is well supported by the same-log re-analysis: reclassifying identical runs with inter-stage monitors drops timeouts to near zero and shifts MTTF by up to 78.7%. That asymmetry is the real result, and it holds up.\n\nWhat it does well: the two-campaign design (proportional-rate and fixed-rate) is the right way to separate exposure from per-fault sensitivity. The failure taxonomy — deadlock, timeout, packet-integrity violation — is appropriate for a real-time trigger. Margins of error are given for the percentage cells, the backpressure phenomenon in §V-B is disclosed honestly, and the comparison to prior work is fair and not padded.\n\nSoft spots, in proportion. The uniform cross-section assumption in §IV-B is load-bearing for any absolute MTTF ordering, and the paper correctly says per-signal cross-sections are unknowable at RTL, but it doesn't sweep the assumption or bound its effect. MTTF estimates themselves come without confidence intervals. The claimed equivalence between offline log re-analysis and a hardware live monitor is asserted, not demonstrated. No campaign artifacts or data are released. And the backpressure misattribution — 33% of fixed-rate Postprocessing faults get tagged as GNN DF output — is disclosed but not corrected. The stress-test note says this kills the hardening-priority conclusion; that is overstated. The priority ranking is actually based on per-injection-target MTTF, which survives the contamination. But the paper calls the classification \"per-stage attribution\" and the abstract leans on \"per-stage data\" to justify priorities, which does conflate the silent interface with the fault origin. That wording needs revision, not the underlying asymmetry.\n\nWho it is for: people doing reliability verification for HEP triggers and FPGA-based NN accelerators, and anyone comparing DUE detection strategies in RTL fault injection. It deserves a serious referee. Send it to review, but expect the authors to add CIs on MTTF, discuss the cross-section sensitivity, and separate the detection-point finding from the fault-origin attribution.","headline":"First RTL fault-injection study of a deployed HEP L1 NN trigger; the MTTF-inflation asymmetry is credible, but the per-stage attribution and hardening-priority wording outrun what the measurements actually support.","tokens_in":10493,"tokens_out":4997,"would_cite":true,"duration_ms":49541,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Watching only a trigger's output hides deadlocks and overstates its time-to-failure by up to 78.7%.","keywords":["fault injection","single-event upset","RTL simulation","graph neural network","FPGA trigger","Belle II","deadlock detection","mean time to failure"],"falsifier":"A neutron-beam test of the target FPGA running GNN-ETM with the four inter-stage liveness monitors implemented in fabric would settle the core claim: if hardware stall-detection latency differs from the simulated 2 µs silence window, the reported MTTF gap of up to 78.7% would need revision.","tokens_in":9558,"feed_emoji":"⚛️","tokens_out":10888,"duration_ms":98030,"temperature":0.7,"pith_summary":"This paper reports the first register-transfer-level fault-injection study of a deployed Level-1 hardware neural-network trigger: Belle II's GNN-ETM, a graph-neural-network dataflow accelerator for calorimeter clustering. The authors inject 1,442,840 single-event upsets across all 211,245 RTL signals and classify failures into deadlocks, timeouts, and packet-integrity violations. Their central claim is that the existing verification setup, which watches an internal GNN watchdog and the design output, suffers from a monitoring asymmetry: a stalled pipeline is counted only when the output eventually misbehaves or times out. Re-analyzing the same simulations with four inter-stage liveness monitors on the AXI-Stream interfaces reclassifies most timeouts as stage-level deadlocks and lowers mean-time-to-failure estimates by up to 78.7%. The result identifies the GNN dataflow accelerator and preprocessing stage as the highest-priority hardening targets for a radiation-exposed trigger.","feed_headline":"Output-only checks inflate trigger failure-time by up to 78.7%","feed_subtitle":"Deadlocks go unnoticed until output; inter-stage monitors give truer failure-time estimates and pinpoint hardening targets.","key_machinery":"The key mechanism is the inter-stage liveness monitor: four monitors placed on the AXI-Stream handshake interfaces between the pipeline's stages (preprocessing-to-header, GNN output, postprocessing-to-CPS, postprocessing-to-GDL). In normal operation each stream emits a transaction roughly every 125 ns; a stream is declared deadlocked if it stays silent for more than 2 µs after the design's 1,846 ns end-to-end latency, a threshold chosen to avoid false positives from natural backpressure. The paper re-analyzes the same simulation logs with these monitors and compares that view with the baseline view (GNN watchdog plus output-level protocol checker). Two injection campaigns support the compari","core_discovery":"The central discovery is a monitoring asymmetry in how failures of a deployed trigger are observed. The baseline infrastructure can see deadlocks only inside the HLS-generated GNN dataflow accelerator, via an embedded watchdog, and packet-integrity violations only at the Belle2Link output; failures originating in the Chisel-based preprocessing, postprocessing, and MAC blocks therefore surface only as late packet violations or simulation timeouts. By re-analyzing the same simulation logs with four liveness monitors placed at the inter-stage AXI-Stream interfaces, the paper reclassifies nearly all of those timeouts as deadlocks localized to a particular stage, and shows that output-only observ","pith_inferences":["If per-signal cross-sections were measured from synthesis or beam tests instead of assumed uniform, the proportional-rate MTTF ordering could shift; the hardening priorities are only as robust as that assumption.","The asserted equivalence between offline log re-analysis and a live hardware monitor is testable: implementing one inter-stage liveness monitor in the target FPGA fabric and measuring real stall-detection latency would validate the 2 µs silence-window assumption, and a longer latency would compress the 78.7% gap.","The monitoring approach should transfer to any pipelined FPGA trigger with AXI-Stream or similar interfaces; inter-stage liveness monitoring is a low-cost observability upgrade that separates deadlocks from timeouts and could become a standard verification step before radiation testing.","The 2 µs silence threshold is a free parameter: the paper notes a tighter threshold would lower MTTF further at the cost of false positives from backpressure, so reporting MTTF as a function of threshold would give designers a fuller picture of the trade-off."],"forward_implications":["For hangs and deadlocks, output-only observation is systematically optimistic: the same fault-injection runs give mean-time-to-failure estimates up to 78.7% higher than inter-stage liveness monitoring, so output-level reliability numbers should be treated as upper bounds.","Most simulation timeouts in the baseline setup are actually deadlocks at a specific pipeline stage; inter-stage liveness monitoring reclassifies them and drops the timeout class below 0.5% for the preprocessing and GNN targets.","Under proportional-rate injection, the GNN dataflow accelerator and preprocessing stage have the shortest mean times to failure, making them the highest-priority hardening targets; the fixed-rate campaign reaches the same conclusion even when small stages are injected at up to 35 times higher rates.","The liveness monitors are not part of the accelerator pipeline, so they could be implemented as parallel hardware IP without affecting the 1,846 ns latency budget, and a reset on detected deadlock would restore normal operation most of the time.","The Belle2Link MAC is not covered by the four monitors because all of them sit upstream of it; a fifth monitor at the Belle2Link output would close that gap, though with longer detection latency since Belle2Link packets arrive less often."],"fun_headline_variants":["Trigger failure times off by up to 78.7% due to monitoring blind spot","Inter-stage monitors recalculate Belle II trigger failure risk","Why output-only monitoring misreads trigger deadlocks by 78.7%","Belle II trigger: hidden deadlocks inflate failure estimates by 78.7%"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The paper's conclusions rest on two assumptions: that every RTL signal contributes equally to the FPGA's radiation cross-section, and that offline log re-analysis matches what a live monitor with a 2 µs silence window would catch; if either fails, the MTTF gap and the hardening priorities would shift.","fun_headline_variants_meta":{"raw":{"variants":["Trigger failure times off by up to 78.7% due to monitoring blind spot","Inter-stage monitors recalculate Belle II trigger failure risk","Why output-only monitoring misreads trigger deadlocks by 78.7%","Belle II trigger: hidden deadlocks inflate failure estimates by 78.7%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000663,"raw_usage":{"total_tokens":2858,"prompt_tokens":731,"completion_tokens":2127,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":475,"completion_tokens_details":{"reasoning_tokens":2042}},"tokens_in":475,"tokens_out":2127,"duration_ms":13424,"temperature":1.0,"reasoning_tokens":2042,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T08:51:32.802299+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A neutron-beam test of the target FPGA running GNN-ETM with the four inter-stage liveness monitors implemented in fabric would settle the core claim: if hardware stall-detection latency differs from the simulated 2 µs silence window, the reported MTTF gap of up to 78.7% would need revision.","supporting_citations":[],"review_version":2}