Pith. sign in

REVIEW 4 major objections 6 minor 50 references

In-Situ Hardware Error Detection Using Specification-Derived Petri Net Models and Behavior-Derived State Sequences

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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…

desk verdict 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. read the letter →

arxiv 2505.04108 v2 pith:XOHAA5AJ submitted 2025-05-07 cs.AR

Tomonari Tanaka , Takumi Uezono , Kohei Suenaga , Masanori Hashimoto This is my paper · ORCID
classification cs.AR
keywords softerrordetectioncontrol-flowmonitoringPetrinetstatesequencefaultinjectionhardwareacceleratorareaoverheadin-situ
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

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.

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 (4)
  1. [IV-A2, Algorithm 1, V-A] 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.
  2. [Abstract, I, V-A] 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.
  3. [V-A] 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.
  4. [V-C1, Table XIII] 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.
minor comments (6)
  1. [V-C2, Table XIV] 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).
  2. [IV-D1, V-B2, Fig.13(d)] 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.
  3. [Algorithms 1 and 2] 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.
  4. [V-C3] 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.
  5. [Tables IV, VI, VIII, X] 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.
  6. [V-A, Tables XI-XVI] 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.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the two detectors are derived from specification and golden-simulation behavior, and the reported detection rates are empirical fault-injection measurements, not quantities forced by the construction.

full rationale

The paper's first method builds Petri nets from specification event sets (Section III-A2) and the second builds a normal state-sequence table from a golden RTL simulation (Algorithm 1, Section III-B1). Neither reduces to the fault-injection outcomes it is used to report: a fault-injected run either does or does not produce a transition outside the table, and the measured DR in Tables XI-XVI is an empirical ratio NTP/NOE, not an algebraic consequence of the table. The self-citation of the authors' preliminary work [26] is used only to motivate the approach and to note a false-positive problem in a competing ML-based method; it is not the load-bearing justification for any detection-rate result. The main legitimate weakness is a generalization/coverage assumption, not circularity: Section III-B1 says 'since we assume a specific application, the number of input patterns producing different state sequences can be restricted,' and Section IV-A2 obtains the Conv. table from one simulation of a 32x32x1 activation input. Thus the state-sequence detector is validated in-sample, and a legal workload that produces an unseen transition would be flagged as faulty; this limits external validity but does not make the reported derivation circular. The paper also states for the NoC router that the test patterns 'do not aim to cover all possible communication patterns' (Section IV-D1), again a coverage limitation rather than a definitional reduction. Because the central claims are supported by independent fault-injection experiments on detectors built from specification and golden traces, the circularity score is low.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

No fitted constants appear in the methods themselves. The ledger captures the manual event selection, the single-scenario golden simulation, and the chosen fault perturbation duration, all of which the measured detection rates depend on.

free parameters (1)
  • Case 2 perturbation duration = 10 consecutive cycles
    Primary control inputs are randomized across ten consecutive cycles in Case 2 (Section V-A). This hand-chosen duration shapes the input-fault error model, and no sensitivity analysis over duration is reported.
assumptions (4)
  • domain assumption A specification document fully describes the relevant signal changes in the target hardware.
    Section III-A states the Petri-net method "assumes the existence of a specification document that fully describes signal changes within the hardware." If the specification is incomplete, generated Petri nets can miss or wrongly flag behavior.
  • domain assumption Event occurrence order is consistent across multiple executions of the monitored scenario.
    Section III-A2 requires "at least two target events, and their occurrence order must remain consistent across multiple executions." Data-dependent variations would make fixed Petri nets raise false alarms.
  • domain assumption Normal input patterns used for golden simulation produce all legal state sequences relevant to deployment.
    Section III-B1 restricts input patterns for a specific application, and Section IV-A2 uses one golden simulation per design. Real workloads with different legal sequences would not be covered by the normal sequence table.
  • domain assumption Ten consecutive cycles of randomized primary-control-input perturbation is a realistic proxy for propagated soft errors.
    Section V-A justifies this with preliminary bit-flip experiments, but it remains an assumed fault model without sensitivity analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of In-Situ Hardware Error Detection Using Specification-Derived Petri Net Models and Behavior-Derived State Sequences." pith.science (2026). https://pith.science/paper/XOHAA5AJ

@misc{pith2026250504108,
  author       = {Pith},
  title        = {Pith review of: In-Situ Hardware Error Detection Using Specification-Derived Petri Net Models and Behavior-Derived State Sequences},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XOHAA5AJ}},
  note         = {Machine review of arXiv:2505.04108}
}
read the original abstract

In hardware accelerators used in data centers and safety-critical applications, soft errors and resultant silent data corruption significantly compromise reliability, particularly when upsets occur in control-flow operations, leading to severe failures. To address this, we introduce two methods for monitoring control flows: using specification-derived Petri nets and using behavior-derived state transitions. We validated our method across four designs: convolutional layer operation, Gaussian blur, AES encryption, and a router in Network-on-Chip. Our fault injection campaign targeting the control registers and primary control inputs demonstrated high error detection rates in both datapath and control logic. Synthesis results show that a maximum detection rate is achieved with a few to around 10% area overhead in most cases. The proposed detectors quickly detect 48% to 100% of failures resulting from upsets in internal control registers and perturbations in primary control inputs. The two proposed methods were compared in terms of area overhead and error detection rate. By selectively applying these two methods, a wide range of area constraints can be accommodated, enabling practical implementation and effectively enhancing error detection capabilities.

Figures

Figures reproduced from arXiv: 2505.04108 by the authors.

Figure 2
Figure 2. shows a simple Petri net with two places and one transition. In the initial marking, Place 1 contains one token, while Place 2 is empty. The transition T1, whose input is Place 1 and output is Place 2, is enabled since Place 1 contains a token. After T1 fires, the token in Place 1 is consumed, and a token is produced in Place 2. Petri nets have been widely used in studies related to hard￾ware security [36]–[39]. How… view at source ↗
Figure 3
Figure 3. Architecture of Petri-net-based error detector. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 5
Figure 5. Monitored signals at different hierarchical levels [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figures from the paper (9 more)
Figure 6
Figure 6. Figure 6: Normal-state-sequences-based error detector. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: Architecture of CNN accelerator. White boxes are mai [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: Petri nets for monitoring control-flow in Conv. [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 10
Figure 10. Figure 10: Architecture of AES encryption. A white box is the ma [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 12
Figure 12. Figure 12: NoC architecture and simulation scenario. [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]
Figure 11
Figure 11. Figure 11: NoC router architecture. status, ”valid” for valid data, and ”vch” for the virtual channel, with two virtual channels per port. All ports include an input unit with a FIFO and a routing computation module. YX routing with static arbitration is used, prioritizing multi…
Figure 13
Figure 13. Figure 13: Trade-off between area overhead and DR in Petri-net [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 15
Figure 15. Figure 15: Performance comparison of Petri-nets, state seque [PITH_FULL_IMAGE:figures/full_fig_p013_15.png]
Figure 14
Figure 14. Figure 14: Performance comparison of Petri-nets and state seq [PITH_FULL_IMAGE:figures/full_fig_p013_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 49 canonical work pages

  1. [1]

    Artificial Neural Networks for Space and Safety -Critical Appli- cations: Reliability Issues and Potential Solutions,

    P . Rech, “Artificial Neural Networks for Space and Safety -Critical Appli- cations: Reliability Issues and Potential Solutions,” IEEE Transactions on Nuclear Science , vol. 71, no. 4, pp. 377–404, 2024

    work page 2024

  2. [2]

    ML-Based Fault Injection for Autonomous V ehicles: A Case for Bayesian Fault Injection,

    S. Jha, et al., “ML-Based Fault Injection for Autonomous V ehicles: A Case for Bayesian Fault Injection,” in 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networ ks (DSN) , jun 2019, pp. 112–124

    work page 2019

  3. [3]

    Single Event Upset tests and failure r ate estimation for a front-end ASIC adopted in high-flux-particle therapy appl ications,

    F. Fausti, et al., “Single Event Upset tests and failure r ate estimation for a front-end ASIC adopted in high-flux-particle therapy appl ications,” Nuclear Instruments and Methods in Physics Research Sectio n A: Accelerators, Spectrometers, Detectors and Associated Eq uipment, vol. 918, pp. 54–59, 2019. 14

    work page 2019

  4. [4]

    Impact of Neutron-Induced SEU in FPGA CRAM on Image-Based Lane Tracking for Autonomous Driving: From Bit Upset to SEFI and Erroneous Behavior,

    T. Tanaka, et al., “Impact of Neutron-Induced SEU in FPGA CRAM on Image-Based Lane Tracking for Autonomous Driving: From Bit Upset to SEFI and Erroneous Behavior,” IEEE Transactions on Nuclear Science , vol. 69, no. 1, pp. 35–42, 2022

    work page 2022

  5. [5]

    Data Center Silent Data Errors: Impli cations to Artifi- cial Intelligence Workloads & Mitigations,

    B. Bittel, et al., “Data Center Silent Data Errors: Impli cations to Artifi- cial Intelligence Workloads & Mitigations,” in 2024 IEEE International Reliability Physics Symposium (IRPS) , 2024, pp. 1–5

    work page 2024

  6. [6]

    The Impact of Terrestrial Radiatio n on FPGAs in Data Centers,

    A. M. Keller, et al., “The Impact of Terrestrial Radiatio n on FPGAs in Data Centers,” ACM Trans. Reconfigurable Technol. Syst. , vol. 15, no. 2, dec 2021

    work page 2021

  7. [7]

    Exploration of Fault Identification an d Automatic Recovery in Cloud-based FPGA Systems,

    S. Konno, et al., “Exploration of Fault Identification an d Automatic Recovery in Cloud-based FPGA Systems,” in 2024 IEEE International Conference on Consumer Electronics (ICCE) , 2024, pp. 1–6

    work page 2024

  8. [8]

    Soft Error and Its Countermeas ures in Terrestrial Environment,

    M. Hashimoto and W. Liao, “Soft Error and Its Countermeas ures in Terrestrial Environment,” in 2020 25th Asia and South Pacific Design Automation Conference (ASP-DAC) , 2020, pp. 617–622

    work page 2020

Show all 50 references
  1. [9]

    Temperature, V oltage, and Agi ng Effects in Ring Oscillator Physical Unclonable Function,

    M. Mustapa and M. Niamat, “Temperature, V oltage, and Agi ng Effects in Ring Oscillator Physical Unclonable Function,” in 2015 IEEE 17th International Conference on High Performance Computing an d Com- munications, 2015 IEEE 7th International Symposium on Cybe rspace Safety an...

    2015

  2. [10]

    Trustworthy Integrated Circuits: Fro m Safety to Security and Beyond,

    E. Rama, et al., “Trustworthy Integrated Circuits: Fro m Safety to Security and Beyond,” IEEE Access , vol. 12, pp. 69 603–69 632, 2024

    2024

  3. [11]

    Reliability analysis on case-stud y traffic sign convolutional neural network on APSoC,

    I. C. Lopes, et al., “Reliability analysis on case-stud y traffic sign convolutional neural network on APSoC,” in 2018 IEEE 19th Latin- American Test Symposium (LATS) , 2018, pp. 1–6

    2018

  4. [12]

    Ultrahigh Energy Heavy Ion Test Beam on Xi linx Kintex- 7 SRAM-Based FPGA,

    B. Du, et al., “Ultrahigh Energy Heavy Ion Test Beam on Xi linx Kintex- 7 SRAM-Based FPGA,” IEEE Transactions on Nuclear Science , vol. 66, no. 7, pp. 1813–1819, 2019

    2019

  5. [13]

    SiFI-AI: A Fast and Flexible RTL Faul t Simulation Framework Tailored for AI Models and Accelerators,

    J. Hoefer, et al., “SiFI-AI: A Fast and Flexible RTL Faul t Simulation Framework Tailored for AI Models and Accelerators,” in Proceedings of the Great Lakes Symposium on VLSI 2023 , ser. GLSVLSI ’23. Association for Computing Machinery, 2023, pp. 287–292

    2023

  6. [14]

    Reconfigurable Framework for Resil ient Semantic Segmentation for Space Applications,

    S. Sabogal, et al., “Reconfigurable Framework for Resil ient Semantic Segmentation for Space Applications,” ACM Trans. Reconfigurable Technol. Syst., vol. 14, no. 4, sep 2021

    2021

  7. [15]

    Microcontroller Compiler-Assiste d Software Fault Tolerance,

    M. Bohman, et al., “Microcontroller Compiler-Assiste d Software Fault Tolerance,” IEEE Transactions on Nuclear Science , vol. 66, no. 1, pp. 223–232, 2019

    2019

  8. [16]

    A Triple Core Lock-Step (TCLS) ARM® C ortex®- R5 Processor for Safety-Critical and Ultra-Reliable Appli cations,

    X. Iturbe, et al., “A Triple Core Lock-Step (TCLS) ARM® C ortex®- R5 Processor for Safety-Critical and Ultra-Reliable Appli cations,” in 2016 46th Annual IEEE/IFIP International Conference on Dep endable Systems and Networks W orkshop (DSN-W) , 2016, pp. 246–249

    2016

  9. [17]

    Lockstep Dual-Core ARM A9: Implem entation and Resilience Analysis Under Heavy Ion-Induced Soft Error s,

    ´A. B. de Oliveira, et al., “Lockstep Dual-Core ARM A9: Implem entation and Resilience Analysis Under Heavy Ion-Induced Soft Error s,” IEEE Transactions on Nuclear Science , vol. 65, no. 8, pp. 1783–1790, 2018

    2018

  10. [18]

    Selective Hardening for Neural Netw orks in FPGAs,

    F. Libano, et al., “Selective Hardening for Neural Netw orks in FPGAs,” IEEE Transactions on Nuclear Science , vol. 66, no. 1, pp. 216–222, 2019

    2019

  11. [19]

    Fault-Tolerant Neural Network Ac celerators With Selective TMR,

    T. G. Bertoa, et al., “Fault-Tolerant Neural Network Ac celerators With Selective TMR,” IEEE Design & Test , vol. 40, no. 2, pp. 67–74, 2023

    2023

  12. [20]

    Improving the Reliability of TMR W ith Nontrip- licated I/O on SRAM FPGAs,

    M. J. Cannon, et al., “Improving the Reliability of TMR W ith Nontrip- licated I/O on SRAM FPGAs,” IEEE Transactions on Nuclear Science , vol. 67, no. 1, pp. 312–320, 2020

    2020

  13. [21]

    Soft Error Mitigation for Deep Convoluti on Neural Network on FPGA Accelerators,

    W. Li, et al., “Soft Error Mitigation for Deep Convoluti on Neural Network on FPGA Accelerators,” in 2020 2nd IEEE International Conference on Artificial Intelligence Circuits and Systems (AICAS), 2020, pp. 1–5

    2020

  14. [22]

    Making Convolutions Resilient Vi a Algorithm- Based Error Detection Techniques,

    S. K. S. Hari, et al., “Making Convolutions Resilient Vi a Algorithm- Based Error Detection Techniques,” IEEE Transactions on Dependable and Secure Computing , vol. 19, no. 4, pp. 2546–2558, 2022

    2022

  15. [23]

    Soft errors in DNN accelerators: A c omprehensive review,

    Y . Ibrahim, et al., “Soft errors in DNN accelerators: A c omprehensive review,” Microelectronics Reliability, vol. 115, p. 113969, 2020

    2020

  16. [24]

    Automated Selection of Assertions for Bit-Flip Detection During Post-Silicon V alidation,

    P . Taatizadeh and N. Nicolici, “Automated Selection of Assertions for Bit-Flip Detection During Post-Silicon V alidation,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and System s, vol. 35, no. 12, pp. 2118–2130, 2016

    2016

  17. [25]

    Assertion Checkers in V erification, S ilicon Debug and In-Field Diagnosis,

    M. Boule, et al., “Assertion Checkers in V erification, S ilicon Debug and In-Field Diagnosis,” in 8th International Symposium on Quality Electronic Design (ISQED’07) , 2007, pp. 613–620

    2007

  18. [26]

    Hardware Error Detection with In-Si tu Monitoring of Control Flow-Related Specifications,

    T. Tanaka, et al., “Hardware Error Detection with In-Si tu Monitoring of Control Flow-Related Specifications,” in Proceedings of Asia and South Pacific Design Automation Conference (ASP-DAC) , 2025, pp. 966–973

    2025

  19. [27]

    Light-Weight Soft-Errors Det ection Mecha- nism in High-Level Synthesis,

    Z. Zhu and B. C. Schafer, “Light-Weight Soft-Errors Det ection Mecha- nism in High-Level Synthesis,” in 2020 IEEE International Symposium on Circuits and Systems (ISCAS) , 2020, pp. 1–5

    2020

  20. [28]

    Low-cost program-level detector s for reducing silent data corruptions,

    S. k. S. Hari, et al., “Low-cost program-level detector s for reducing silent data corruptions,” in IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2012) , 2012, pp. 1–12

    2012

  21. [29]

    Generic Soft Error Data and Contro l Flow Error Detection by Instruction Duplication,

    M. Didehban, et al., “Generic Soft Error Data and Contro l Flow Error Detection by Instruction Duplication,” IEEE Transactions on Depend- able and Secure Computing , vol. 21, no. 1, pp. 78–92, 2024

    2024

  22. [30]

    DeepVigor: VulnerabIlity V alue RanGes and FactORs for DNNs’ Reliability Assessment,

    M. H. Ahmadilivani, et al., “DeepVigor: VulnerabIlity V alue RanGes and FactORs for DNNs’ Reliability Assessment,” in 2023 IEEE European Test Symposium (ETS) , 2023, pp. 1–6

    2023

  23. [31]

    BinFI: an efficient fault injector for s afety-critical machine learning systems,

    Z. Chen, et al., “BinFI: an efficient fault injector for s afety-critical machine learning systems,” in Proceedings of the International Con- ference for High Performance Computing, Networking, Stora ge and Analysis, ser. SC ’19. New Y ork, NY , USA: Association for Computing M...

    2019

  24. [32]

    Reliability-aware register bi nding for control- flow intensive designs,

    L. Chen and M. Tahoori, “Reliability-aware register bi nding for control- flow intensive designs,” in 2014 51st ACM/EDAC/IEEE Design Automa- tion Conference (DAC) , 2014, pp. 1–6

    2014

  25. [33]

    StitchUp: Automatic con trol flow pro- tection for high level synthesis circuits,

    S. T. Fleming and D. B. Thomas, “StitchUp: Automatic con trol flow pro- tection for high level synthesis circuits,” in 2016 53nd ACM/EDAC/IEEE Design Automation Conference (DAC) , 2016, pp. 1–6

    2016

  26. [34]

    MLC: A Machine Learning Based Check er For Soft Error Detection In Embedded Processors,

    N. Nosrati, et al., “MLC: A Machine Learning Based Check er For Soft Error Detection In Embedded Processors,” in 2022 IEEE 28th International Symposium on On-Line Testing and Robust Syst em Design (IOLTS), 2022, pp. 1–5

    2022

  27. [35]

    An automated SA T-based method for the design of on-chip bit-flip detectors,

    P . Taatizadeh and N. Nicolici, “An automated SA T-based method for the design of on-chip bit-flip detectors,” in 2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD) , 2017, pp. 101–108

    2017

  28. [36]

    Hardware Security Module Cryptosys tem Using Petri Net,

    B. Guechi, et al., “Hardware Security Module Cryptosys tem Using Petri Net,” Indonesian Journal of Electrical Engineering and Informat ics (IJEEI), vol. 11, 06 2023

    2023

  29. [37]

    Monitor petri nets for security mon itoring,

    L. Patzina, et al., “Monitor petri nets for security mon itoring,” in Pro- ceedings of the International W orkshop on Security and Depe ndability for Resource Constrained Embedded Systems . New Y ork, NY , USA: Association for Computing Machinery, 2010

    2010

  30. [38]

    An improved petri net for fault analysis of an electronic system with hybrid fault of software and hardware,

    S. Bai, et al., “An improved petri net for fault analysis of an electronic system with hybrid fault of software and hardware,” Engineering Failure Analysis, vol. 120, p. 105077, 2021

    2021

  31. [39]

    Fault Tolerance of Multiprocessor-St ructured Control System by Hardware and Software Reconfiguration,

    P . Wang, et al., “Fault Tolerance of Multiprocessor-St ructured Control System by Hardware and Software Reconfiguration,” in 2007 Interna- tional Conference on Mechatronics and Automation , 2007, pp. 3745– 3749

    2007

  32. [40]

    Automatic Assertion Generation for S imulation, Formal V erification and Emulation,

    T. Zhang, et al., “Automatic Assertion Generation for S imulation, Formal V erification and Emulation,” in 2017 IEEE Computer Society Annual Symposium on VLSI (ISVLSI) , 2017, pp. 471–476

    2017

  33. [41]

    HARM: A Hint-Based Assertion Mi ner,

    S. Germiniani, et al., “HARM: A Hint-Based Assertion Mi ner,” IEEE Transactions on Computer-Aided Design of Integrated Circu its and Systems, vol. 41, no. 11, pp. 4277–4288, 2022

    2022

  34. [42]

    AssertLLM: Generating and evaluating hardware verification assertions from design specifications via mult i-LLMs,

    W. Fang, et al., “AssertLLM: Generating and evaluating hardware verification assertions from design specifications via mult i-LLMs,” arXiv preprint arXiv:2402.00386, 2024

    2024

  35. [43]

    A High Performance Multi-Bit-Width B ooth V ector Systolic Accelerator for NAS Optimized Deep Learning Neura l Net- works,

    M. Huang, et al., “A High Performance Multi-Bit-Width B ooth V ector Systolic Accelerator for NAS Optimized Deep Learning Neura l Net- works,” IEEE Transactions on Circuits and Systems I: Regular Papers , pp. 1–13, 2022

    2022

  36. [44]

    A Describing Method of An Image Pro cessing Software in C for A High-level Synthesis Considering A Funct ion Chaining,

    A. Y amawaki, et al., “A Describing Method of An Image Pro cessing Software in C for A High-level Synthesis Considering A Funct ion Chaining,” IEICE Transactions on Information and Systems , vol. E101D, no. 2, pp. 324–334, Feb. 2018

    2018

  37. [45]

    V erilog Implementation of the Symmetric Bl ock Cipher AES (NIST FIPS 197),

    B. Degnan, “V erilog Implementation of the Symmetric Bl ock Cipher AES (NIST FIPS 197),” https://github.com/secworks/aes, 2 021

  38. [46]

    NoC Simulator for simulating intra-chip data flow in Neural Network Accelerator,

    K. R. Kyle Jonghyuk Park, “NoC Simulator for simulating intra-chip data flow in Neural Network Accelerator,” https://github.com/KyleParkJong/Network-on-Chip-Simulator

  39. [47]

    Prediction router: Y et another l ow latency on- chip router architecture,

    H. Matsutani, et al., “Prediction router: Y et another l ow latency on- chip router architecture,” in 2009 IEEE 15th International Symposium on High Performance Computer Architecture , 2009, pp. 367–378

    2009

  40. [48]

    Simba: Scaling Deep-Learning Infer ence with Multi- Chip-Module-Based Architecture,

    Y . S. Shao, et al., “Simba: Scaling Deep-Learning Infer ence with Multi- Chip-Module-Based Architecture,” in Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture , ser. MICRO ’52. New Y ork, NY , USA: Association for Computing Machinery , 2019,...

    2019

  41. [49]

    Goldmine: Automatic assertion g eneration using data mining and static analysis,

    S. V asudevan, et al., “Goldmine: Automatic assertion g eneration using data mining and static analysis,” in 2010 Design, Automation & Test in Europe Conference & Exhibition (DATE 2010) , 2010, pp. 626–629

    2010

  42. [50]

    Combinational profiles of sequentia l benchmark cir- cuits,

    F. Brglez, et al., “Combinational profiles of sequentia l benchmark cir- cuits,” in 1989 IEEE International Symposium on Circuits and Systems (ISCAS), 1989, pp. 1929–1934 vol.3

    1989

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.