{"id":"2b4b8a19-0b18-41d2-b10d-586f92f0999f","arxiv_id":"2505.04108","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Two control-flow checkers, one built from specification Petri nets and one from golden-simulation state sequences, detect 48% to 100% of injected control faults at a few to about 10% area overhead across four hardware designs.","lead":"This paper proposes two low-cost hardware checkers that watch a chip's control signals and raise a fault flag when the observed order of events deviates from the expected order. The checkers caught 48% to 100% of injected control-flow faults on four accelerator-style designs while adding only a few percent to about 10% area overhead.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"State-sequence detection is validated only on the exact golden input trace used to build the normal table; legal workloads producing an unseen state transition will raise false alarms, so the reported in-sample detection rates do not yet establish deployment-time rates.","rationale":"The reader's weakest_assumption is exactly the premise I consider load-bearing: the normal state-sequence table is built from a single golden simulation, and the claimed detection rate is measured under the same closed input class. I agree with that identification, and the recommended CONDITIONAL verdict remains appropriate because the paper is a credible engineering study whose reported detection rates are real for the tested traces, but whose deployment claim is not yet supported. The concrete test above would settle the issue by measuring unseen legal transitions and out-of-sample detection rates. I do not see a stronger objection: the Petri-net method is specification-based rather than trace-based and is therefore less exposed to this completeness problem, and the abstract's 'datapath' phrasing is an overstatement rather than a collapse of the central argument. The paper also earns credit for reporting area/DR trade-offs across four non-trivial designs and for comparing against GoldMine, but without artifact release or statistical repetition the in-sample evaluation remains the limiting factor.","tokens_in":20729,"tokens_out":2457,"duration_ms":33537,"concrete_test":"Run golden RTL simulations of the Conv. design (and at least the NoC router) over a deliberately varied but legal input set: e.g., 1,000 random MNIST 32x32x1 activations and several legal input schedules (back-to-back, paused, variable inter-arrival) using the same configuration as Section IV-A. For each golden run, compare every observed state transition against the normal_seq tables of Table IV, and count runs that raise the fault flag or produce an unseen transition. Then repeat the Case 1/2 fault injections on a held-out subset of these legal inputs and report DR and false-positive rate. If no golden run produces an unseen transition and DR remains stable on held-out inputs, the concern is resolved; if legal inputs generate novel sequences, the method needs an explicit legal-input contract or a data-driven table built from that contract.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The state-sequence method's correctness hinges on Algorithm 1's normal_seq table being complete for every legal behavior of the monitored circuit. Section III-B1 explicitly restricts the problem by assuming a specific application, and Section IV-A2 constructs the Conv. table from one golden simulation of a single 32x32x1 activation input (322 sequences at Level 1(1)). All fault-injection experiments then presumably run the same stimulus class used to build this table. Under that closed trace, the reported DR is internally consistent, but the central claim generalizes to 'in-situ' monitoring only if the table is also a complete model of all legal control-flow behavior. That completeness is not established: a different legal input pattern, data-dependent timing, or a permitted interruption could produce a transition absent from the table, and Algorithm 2 would flag a false fault; conversely, a fault that maps the machine to a transition pair that is in the table escapes detection. The paper reports no false-positive measurements and no out-of-sample legal runs. The problem is not an internal inconsistency but an unmeasured generalization gap: the load-bearing premise is that one golden trace per configuration covers the legal state-transition space, and nothing in the paper verifies that premise.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes two in-situ hardware error detection methods for control-flow monitoring in accelerators: (1) Petri-net checkers constructed from control-flow specifications, and (2) state-sequence checkers built from golden RTL simulation traces. Both are implemented as hardware monitors and evaluated via RTL fault injection into control registers and primary control inputs on four designs: a CNN convolutional layer, Gaussian blur, AES encryption, and a NoC router. The paper reports detection rates from 48% to 100%, detection latency, and synthesis-based area overhead trade-offs, and it compares the proposed methods with GoldMine assertion-based detection on one of the four designs.","tokens_in":20949,"tokens_out":6280,"duration_ms":64696,"significance":"If the reported detection rates hold beyond the specific traces used in the experiments, the methods are a useful addition to the error-detection toolbox: unlike register duplication or TMR, they can detect faults in primary control inputs, and the area-overhead trade-off study gives designers concrete options. The paper's strengths are its four realistic target designs, the large fault-injection campaigns, the explicit algorithms for sequence acquisition and detection, and the synthesis results. The main limitation is that the state-sequence checker is built from and evaluated on the same single input scenario per design, so the reported detection rates are in-sample estimates; the Petri-net method is less exposed to this issue because it is specification-derived, but it still depends on manually chosen event sets and on the assumed application behavior. The abstract's claim about 'datapath' faults is not directly supported by the fault-injection targets, and no false-positive measurements are reported.","major_comments":[{"comment":"The state-sequence checker's normal table is built by Algorithm 1 from one golden record per design (e.g., the 32x32x1 activation input for Conv., Section IV-A2), and the fault-injection experiments in Section V-A are described for the same designs and scenarios; no other legal input pattern is specified. This makes the detection rates in Tables XIII-XVI in-sample: Algorithm 2 flags any transition not in normal_seq, so a legal workload that produces a previously unseen state pair will cause a false positive, while a fault that keeps the machine on an in-table transition escapes. Section III-B1 acknowledges the specific-application assumption, but the paper does not verify that the single golden trace covers all legal control-flow transitions, and no false-positive or out-of-sample experiments are reported. Please either provide a coverage argument (for example, a formal enumeration of the legal control-flow state graph for the assumed application) or add experiments with multiple legal input patterns, reporting the detection rate and the false-positive rate separately.","section":"IV-A2, Algorithm 1, V-A"},{"comment":"The abstract and introduction claim high detection rates 'in both datapath and control logic,' but Section V-A restricts fault injection to control registers (Case 1) and primary control inputs (Case 2). No faults are injected into datapath registers, arithmetic units, or output data paths; datapath corruption is only observed indirectly as a consequence of control-flow faults. The datapath part of the claim is therefore not directly supported. Please add datapath fault-injection experiments or revise the claim to state that the evaluation covers control-flow-affecting faults.","section":"Abstract, I, V-A"},{"comment":"Case 2 perturbs 'primary control inputs across ten consecutive cycles,' and the perturbation duration is a free parameter. The preliminary experiments justify that such perturbations can arise from bit flips, but no sensitivity analysis is given. The Router results differ sharply between Case 1 and Case 2 (Petri-net DR 95.4% versus 47.8% in Tables XI and XII), so the reported Case 2 detection rates may depend on the chosen duration and width of the perturbation. Please report results for at least one additional perturbation configuration or provide a sensitivity study showing that the conclusions are robust.","section":"V-A"},{"comment":"In Case 2, the state-sequence method's detection is dominated by the final-transition check: DR_TO is 94.9-99.9% for Conv. (e.g., Level 2(2): DR_TO=99.9% with Lat=4363.5 cycles; Level 3(2): DR_TO=99.9% with Lat=8417.5 cycles). This means the checker usually fires only at the end of the run or at the final-state check, not at the moment the abnormal transition occurs. The abstract's statement that the detectors 'quickly detect' failures is therefore overstated for the state-sequence method in Case 2. Please report the distribution of detection latencies and separate the contribution of the end-state check in the summary claims.","section":"V-C1, Table XIII"}],"minor_comments":[{"comment":"The text says 'except for hierarchy Level 3(3) in Case 2,' but Table XIV lists only Level 3(2) and shows DR=1.9% for that row; the hierarchy label in the text should be Level 3(2).","section":"V-C2, Table XIV"},{"comment":"Section IV-D1 states that the router uses 14 Petri nets (R9 and R10 each mapping to two virtual channels), while Section V-B2 and Fig. 13(d) refer to 'all seven Petri nets.' Please clarify whether the comparison is per port or total, and make the numbers consistent.","section":"IV-D1, V-B2, Fig.13(d)"},{"comment":"Algorithm 2 line 6 assigns 'seq <- (prev state, new trans)', but 'new trans' is not defined in that algorithm and Algorithm 1 uses 'state' in the analogous line; the accompanying text also refers to 'SEQ' while the code uses 'seq'. Please make the pseudocode and text consistent.","section":"Algorithms 1 and 2"},{"comment":"The AES section says the 1.0% area overhead for Level 3(1) is 'as shown in Table VI,' but Table VI is the Gaussian blur table; the correct reference is Table VIII.","section":"V-C3"},{"comment":"The area-overhead percentages are useful, but the paper does not report absolute LUT/FF counts for the state-sequence checkers. Adding absolute numbers would make the comparison across designs and with the Petri-net detectors more reproducible.","section":"Tables IV, VI, VIII, X"},{"comment":"No information is given about fault-injection seeds, determinism, or variation across repeated runs. Reporting confidence intervals or stating that the simulations are deterministic would help readers assess the precision of the reported detection rates.","section":"V-A, Tables XI-XVI"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the journal's scope and the experimental effort is substantial. My main concern is the gap between the in-sample evaluation of the state-sequence method and the general in-situ monitoring claim; I believe this is addressable with additional out-of-sample experiments and a clearer statement of coverage assumptions. I therefore recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things worth knowing. The Petri-net half is the stronger contribution: because the nets come from the specification rather than simulation traces, its detection numbers are not entangled with the in-sample evaluation problem that affects the second method. The state-sequence half is genuinely new and the four-design comparison is a useful addition, but its headline numbers are in-sample — the normal-sequence table is built from one golden simulation and the fault injections run the same stimulus class. The paper states the \"specific application\" premise (Section III-B1) honestly but never measures the false-alarm rate on legal inputs outside the golden trace, so the deployment claim rests on an unverified completeness assumption.\n\nWhat it does well. The fault-injection campaign is substantial (roughly half a million injections across both methods) and the synthesis numbers are concrete. The head-to-head against control-register duplication makes the right point: input-side faults are invisible to TMR-style redundancy, and both proposed checkers catch most of them in the three simpler designs. Reporting the NoC router's 48% Case 2 rate rather than burying it is honest work, as is the admission that neither method is universally better. The event-set taxonomy (Types 1–4) and the hierarchical signal-selection analysis are genuinely useful for designers.\n\nSoft spots. The abstract's phrase \"high error detection rates in both datapath and control logic\" oversells a bit — fault injection targets control registers and primary control inputs only; datapath faults are never injected. The body is clear about this, so it is a wording problem, not a defect in the results. Bigger issue: for the state-sequence method, treat the reported rates as an upper bound under a closed trace. The completeness of the normal-sequence table is plausible for data-independent control flow (the Conv design under fixed input dimensions, AES with uninterrupted plaintexts), but the paper does not show it, and for the NoC router the scenario-dependence is explicit. No false-positive experiments, no out-of-sample legal runs, and no artifact release (code, netlists, or scripts). For a paper whose value proposition is that designers can use this, the missing artifacts and missing out-of-sample test are real costs. The manually chosen event sets are a minor limitation the authors themselves acknowledge.\n\nBottom line. The central claim holds for what was actually tested, and the Petri-net approach earns its keep as a spec-derived alternative. The state-sequence numbers should be read with the in-sample caveat. This deserves a serious referee; I would send it to review and ask for the out-of-sample false-positive measurement and artifact release. Desk rejection would be a mistake.","headline":"Solid and mostly honest engineering study: spec-derived Petri nets are the stronger half, while the new state-sequence checker's detection rates are in-sample and its out-of-sample false-alarm behavior is unmeasured.","tokens_in":21465,"tokens_out":8174,"would_cite":true,"duration_ms":72871,"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":"This paper claims that control-flow errors in hardware accelerators can be detected cheaply in situ by watching the order of events, using specification-derived Petri nets and behavior-derived state sequences, with reported detection…","keywords":["soft error detection","control-flow monitoring","Petri net","state sequence","fault injection","hardware accelerator","area overhead","in-situ monitoring"],"falsifier":"Run the protected design on a legal input workload that was not used when building the normal-state-sequence table, with no faults injected: if the detector asserts a fault flag, the coverage premise is false. Conversely, inject a bit flip whose resulting state trajectory stays entirely inside the table and show the detector stays silent despite an incorrect output.","tokens_in":20545,"feed_emoji":"🛰️","tokens_out":7094,"duration_ms":68799,"temperature":0.7,"pith_summary":"The paper is trying to establish that soft errors that corrupt an accelerator's control flow can be caught cheaply by watching the order of events rather than by duplicating computation. It proposes two such monitors: Petri nets generated from the design specification, and a table of legal state transitions gathered from an error-free simulation. Fault-injection experiments across a convolutional layer, Gaussian blur, AES encryption, and a NoC router report detection rates of 48–100% of output-error-producing faults, with peak detection usually reached at a few percent to about 10% area overhead. The practical payoff is a tunable reliability-area trade-off that also covers faulty primary inputs, which register duplication and triple modular redundancy cannot detect.","feed_headline":"Petri-net, state-sequence checkers catch 48–100% of control faults","feed_subtitle":"In-situ monitors flag soft errors in accelerator control logic for a few to ~10% area overhead.","key_machinery":"The load-bearing objects are the event set and the state bundle. For the Petri-net method, each event set from the specification becomes a small bipartite Petri net whose transitions represent allowed signal changes; the detector is a hardware module that watches firings and compares them against a normal-sequence table. For the state-sequence method, a state is a concatenation of control-related signal bits taken from primary outputs, sub-module outputs, or control registers, and normal behavior is the list of predecessor-successor pairs extracted from a golden simulation. The hierarchy level and bit-selection type (all bits, MSBs, MSBs in the used range, LSBs) give the designer the area-versus-detection dial, because they determine both the size of the state and the number of normal sequences.","core_discovery":"The central claim is that an accelerator can be made self-diagnosing for control-flow faults by precomputing legal behavior and checking runtime signal orderings against it. The specification-derived method encodes each extracted event set as a compact Petri net; the detector raises a fault flag when transitions fire out of the normal order or the process ends on the wrong final transition. The behavior-derived method defines a state as a bundle of selected control signals at a chosen hierarchy level, collects every observed two-state transition from one golden RTL simulation, and flags any transition missing from that table. On the four evaluated designs, the methods detected 99.5% of output errors from register upsets in the convolutional layer, 95.4% in the router, and, for input-related faults, 99.9% in the convolutional layer and AES, with detection latency ranging from about a cycle to a few hundred cycles depending on the configuration.","pith_inferences":["Editorial inference: the manual step of extracting event sets from specifications will probably become the practical bottleneck, although the paper notes that LLMs or automated assertion miners could generate these sets and make the method nearly turnkey.","Editorial inference: the state-sequence approach's reliability is bounded by input coverage; a legal workload that produces a transition absent from the one-simulation table would cause a false alarm, so the technique fits fixed-behavior accelerators better than general-purpose processors.","Editorial inference: flexible controllers with many legal interleavings are the hard case, since the router's input-fault detection dropped to 47.8% for Petri nets and 45.7% for state sequences; tightening the assumed communication pattern should raise detection but narrow applicability.","Editorial inference: combining these control-flow monitors with periodic golden-data checks could catch datapath faults that leave control flow untouched, though that combination is not evaluated in the paper."],"forward_implications":["Small area budgets still buy high detection: on the convolutional layer, 1% area overhead already gave 93.7% detection of register-induced output errors and 99.9% of input-induced output errors.","The monitors cover primary-input faults where register duplication and TMR give zero detection, because all replicated modules would see the same faulty input.","Designers can span a wide range of area constraints by choosing Petri nets, state sequences, or a combination, since neither method dominates in all four designs.","When fast detection matters, Petri nets are often the better choice, whereas state sequences tend to be cheaper but, in some configurations, detect only via the wrong final state, with DR_TO above 90% for the convolutional layer in input-fault cases.","For register-heavy designs like the NoC router, control-register duplication becomes expensive, while a state-sequence checker reaches about 94.5% detection of register-induced errors at 12.5% area overhead."],"supporting_citations":[{"why":"Fault-injection study establishing control registers as a primary soft-error target, motivating the fault-injection choices.","marker":"[13]"},{"why":"Additional fault-injection evidence linking control-flow registers to severe accelerator failures.","marker":"[14]"},{"why":"Assertion-based bit-flip detection method used as the comparison baseline for detection rate and overhead.","marker":"[24]"},{"why":"Authors' preliminary Petri-net-based detector, extended here to more designs and a second detection method.","marker":"[26]"},{"why":"Provides the CNN accelerator architecture used as the first test design.","marker":"[43]"},{"why":"Describes the Gaussian-blur pipeline used as the second design example.","marker":"[44]"},{"why":"Provides the AES implementation used as the third design example.","marker":"[45]"},{"why":"Supplies the NoC router architecture and simulation setup for the fourth design.","marker":"[46]"},{"why":"Defines the NoC-CNN workload scenario used to set the router's traffic pattern.","marker":"[48]"},{"why":"Provides the assertion-generation tool used in the comparison experiments.","marker":"[49]"}],"fun_headline_variants":["Petri-net monitors catch 48-100% of control faults","Self-diagnosing accelerators via Petri nets and state sequences","In-situ checkers flag soft errors for ~10% area overhead","Control-flow fault detection with specification-derived Petri nets","Behavior-derived state sequences detect 99.9% of control faults"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The state-sequence checker's normal table must contain every legal control-flow transition the circuit can make; it was built from one golden simulation per design, so a legal workload that produces an unlisted sequence would trigger a false alarm, and a fault that keeps the circuit on listed sequences would be missed.","fun_headline_variants_meta":{"raw":{"variants":["Petri-net monitors catch 48-100% of control faults","Self-diagnosing accelerators via Petri nets and state sequences","In-situ checkers flag soft errors for ~10% area overhead","Control-flow fault detection with specification-derived Petri nets","Behavior-derived state sequences detect 99.9% of control faults"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000448,"raw_usage":{"total_tokens":2249,"prompt_tokens":921,"completion_tokens":1328,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":537,"completion_tokens_details":{"reasoning_tokens":1242}},"tokens_in":537,"tokens_out":1328,"duration_ms":10987,"temperature":1.0,"reasoning_tokens":1242,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T23:37:09.711833+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the protected design on a legal input workload that was not used when building the normal-state-sequence table, with no faults injected: if the detector asserts a fault flag, the coverage premise is false. Conversely, inject a bit flip whose resulting state trajectory stays entirely inside the table and show the detector stays silent despite an incorrect output.","supporting_citations":[{"cited_title":"SiFI-AI: A Fast and Flexible RTL Faul t Simulation Framework Tailored for AI Models and Accelerators,","cited_arxiv_id":null,"evidence_quote":"Fault-injection study establishing control registers as a primary soft-error target, motivating the fault-injection choices."},{"cited_title":"Reconfigurable Framework for Resil ient Semantic Segmentation for Space Applications,","cited_arxiv_id":null,"evidence_quote":"Additional fault-injection evidence linking control-flow registers to severe accelerator failures."},{"cited_title":"Automated Selection of Assertions for Bit-Flip Detection During Post-Silicon V alidation,","cited_arxiv_id":null,"evidence_quote":"Assertion-based bit-flip detection method used as the comparison baseline for detection rate and overhead."},{"cited_title":"Hardware Error Detection with In-Si tu Monitoring of Control Flow-Related Specifications,","cited_arxiv_id":null,"evidence_quote":"Authors' preliminary Petri-net-based detector, extended here to more designs and a second detection method."},{"cited_title":"A High Performance Multi-Bit-Width B ooth V ector Systolic Accelerator for NAS Optimized Deep Learning Neura l Net- works,","cited_arxiv_id":null,"evidence_quote":"Provides the CNN accelerator architecture used as the first test design."},{"cited_title":"A Describing Method of An Image Pro cessing Software in C for A High-level Synthesis Considering A Funct ion Chaining,","cited_arxiv_id":null,"evidence_quote":"Describes the Gaussian-blur pipeline used as the second design example."},{"cited_title":"V erilog Implementation of the Symmetric Bl ock Cipher AES (NIST FIPS 197),","cited_arxiv_id":null,"evidence_quote":"Provides the AES implementation used as the third design example."},{"cited_title":"NoC Simulator for simulating intra-chip data flow in Neural Network Accelerator,","cited_arxiv_id":null,"evidence_quote":"Supplies the NoC router architecture and simulation setup for the fourth design."},{"cited_title":"Simba: Scaling Deep-Learning Infer ence with Multi- Chip-Module-Based Architecture,","cited_arxiv_id":null,"evidence_quote":"Defines the NoC-CNN workload scenario used to set the router's traffic pattern."},{"cited_title":"Goldmine: Automatic assertion g eneration using data mining and static analysis,","cited_arxiv_id":null,"evidence_quote":"Provides the assertion-generation tool used in the comparison experiments."}],"review_version":1}