# ENFOR-SA: End-to-end Cross-layer Transient Fault Injector for Efficient and Accurate DNN Reliability Assessment on Systolic Arrays

Rafael Billig Tonetto, Marcello Traiola, Fernando Fernandes, Angeliki Kritikakou

<figure><img src="image_1.png" /></figure>

## To cite this version:

Rafael Billig Tonetto, Marcello Traiola, Fernando Fernandes, Angeliki Kritikakou. ENFOR-SA: End-to-end Cross-layer Transient Fault Injector for Efficient and Accurate DNN Reliability Assessment on Systolic Arrays. VTS 2026 - IEEE VLSI Test Symposium, Apr 2026, Napa Valley, CA, United States. hal-05487559

HAL Id: hal-05487559

https://hal.science/hal-05487559v1

Submitted on 31 Jan 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# ENFOR-SA: End-to-end Cross-layer Transient Fault Injector for Efficient and Accurate DNN Reliability Assessment on Systolic Arrays

Rafael B. Tonetto, Marcello Traiola, Fernando Fernandes dos Santos, Angeliki Kritikakou

Univ Rennes, CNRS, Inria, IRISA - UMR 6074, F-3500

{rafael.billig-tonetto, marcello.traiola, fernando.fernandes-dos-santos, angeliki.kritikakou}@inria.fr

**Abstract**—Recent advances in deep learning have produced highly accurate but increasingly large and complex DNNs, making traditional fault-injection techniques impractical. Accurate fault analysis requires RTL-accurate hardware models. However, this significantly slows evaluation compared with software-only approaches, particularly when combined with expensive HDL instrumentation. In this work, we show that such high-overhead methods are unnecessary for systolic array (SA) architectures and propose ENFOR-SA, an end-to-end framework for DNN transient fault analysis on SAs. Our two-step approach employs cross-layer simulation and uses RTL SA components only during fault injection, with the rest executed at the software level. Experiments on CNNs and Vision Transformers demonstrate that ENFOR-SA achieves RTL-accurate fault injection with only 6% average slowdown compared to software-based injection, while delivering at least two orders of magnitude speedup (average $569 \times$) over full-SoC RTL simulation and a $2.03 \times$ improvement over a state-of-the-art cross-layer RTL injection tool. ENFOR-SA code is publicly available<fnref n="1" />.

## I. INTRODUCTION

Reliability assessment is crucial for evaluating DNN robustness to hardware faults, which can significantly degrade model accuracy. Fault injection is the primary method for identifying vulnerable components and designing fault-tolerance mechanisms, but modern DNNs have drastically expanded the fault space, making exhaustive evaluation impractical. For example, evaluating CIFAR-10 on ResNet-20 requires over 17 million simulations, translating to months of runtime [1]. Therefore, efficient fault injection techniques are essential to reduce evaluation time while preserving accuracy.

Producing realistic and statistically meaningful reliability results requires fault injection tools to account for fault masking effects across multiple abstraction levels [2]. High-level approaches (e.g., at the instruction or application level) offer rapid evaluation, but often neglect essential masking effects, and usually rely on simplified or incomplete fault models [2]. In contrast, low-level hardware simulations (e.g., RTL-based) provide high accuracy, but incur orders-of-magnitude longer execution times. These conflicting requirements highlight the need for scalable fault injection methodologies that balance accuracy and efficiency. Cross-layer approaches attempt to bridge the gap between high-level speed and low-level accuracy by combining multiple simulation layers [3], [4], [5], [6]. Such methods have shown reasonable effectiveness for small and moderate-sized models (e.g., MLPs [7], [8], [9], LeNet-5 [10],

[8], [4], [11], AlexNet [7], [9], [12], [4], and small-dataset ResNets [10], [12]). Yet, accurately assessing the reliability of today's highly complex DNNs, especially when deployed on increasingly common Systolic Array (SA) accelerators, requires much more aggressive solutions. Even with existing cross-layer tools, evaluation times remain unacceptable for such modern workloads and architectures.

To address these challenges, we introduce ENFOR-SA, a fast and accurate cross-layer fault-injection framework that integrates PyTorch-level DNN inference with efficient RTL fault injection. ENFOR-SA is explicitly designed to support SA hardware accelerators, enabling scalable and realistic reliability assessment without requiring large infrastructures. As explained in detail in Section III, ENFOR-SA performs high-speed inference at the Python level while enabling fine-grained, white-box RTL fault injection of SA components. Extensive experimental results show that ENFOR-SA significantly reduces evaluation time compared with full RTL fault-injection methodologies (average speedup of $569 \times$, with a minimum of $198.66 \times$), achieving an average slowdown of only 6% compared to full-SW injection. In summary, our contributions are:

* A fully integrated cross-layer framework that couples PyTorch-level inference with Verilator-based RTL fault injection for SA architectures. ENFOR-SA maps intermediate tensors from DNN execution graph to RTL data paths, allowing for cycle-accurate RTL fault injection, while maintaining runtime close to software-level experiments.

* A scalable methodology supporting diverse SA configurations and DNN workloads. ENFOR-SA integrates SA implementations generated with Chipyard [13], enabling rapid exploration of microarchitectural parameters. ENFOR-SA supports any pre-trained PyTorch model, allowing fault analysis across a range of networks and tasks.

* A detailed evaluation against a state-of-the-art fault-injection framework. We conduct quantitative and qualitative comparisons, demonstrating that ENFOR-SA overcomes key limitations of existing tools by achieving significantly faster fault-injection campaigns, while preserving RTL accuracy.

* An open-source, end-to-end, and extensible framework enabling future research on DNN reliability.

## II. RELATED WORKS

Fault injection frameworks have been proposed for reliability assessment dedicated to DNN workloads [14], [15], [16]. Ta-

<footnote n="1">¹ENFOR-SA is available at https://github.com/rafaabt/ENFOR-SA</footnote>
ble I highlights representative fault-injection studies operating at different abstraction levels.

Simulation-based fault injections can be classified as Gate-Level (GL), Register-Transfer Level (RTL), microarchitecture, or software-level (SW). Speedup techniques have been proposed to accelerate GL simulation [17], [18]. Other approaches adopt machine learning strategies that model GL behavior on a structured graph representation of the circuit's netlist [19], [20]. Fault analysis is performed by predicting a node's state from the graph representation. Although such methods maintain approximate accuracy for gate-level masking, none offer seamless end-to-end integration of DNNs with low-level accelerator representation.

At RTL, the approaches of [26], [27] propose injection methodologies for the Gemmini systolic array [31]. In [26], although accurate, the simulation is performed entirely at RTL and no simulation time improvement methodology is provided. Thus, fault analysis tends to be highly constrained in terms of the input space, the number of evaluated DNN layers, and the hardware configurations. Alternatively, [27] proposes a hybrid approach in which only the code portion subject to faults executes in detailed RTL models. However, it requires heavy RTL code annotations - in the Hardware Description Language (HDL) - for each individual fault target (fault position, cycle, or hardware-specific conditions must be annotated in HDL), and no further speedup methodology is provided. FIDELITY [6] proposes an error model framework for fast and accurate resilience analysis of DNN accelerators by incorporating hardware semantics to approximate RTL effects. While it provides an end-to-end framework achieving near-RTL accuracy, it is not a full RTL replacement and does not reproduce the exact faulty values produced by some faults (e.g., local-control FFs), replacing them with random values. Finally, it has been validated on NVDLA-like accelerators rather than on systolic arrays. SAFFIRA [28] proposes an end-to-end HW-aware fault injection method using a SA model derived from Uniform Recurrent Equations (URE), capturing spatial and temporal behavior. Although it is much faster than RTL, it

<table><caption>TABLE I: Fault injection works supporting DNN workloads.</caption><thead><tr><th>Paper</th><th>SA support</th><th>FI level</th><th>End-to-end No instr. framework overhead</th></tr></thead><tbody><tr><td>[21] (MRFI)</td><td>✗</td><td>SW</td><td>✓</td></tr><tr><td>[22] (BinFI)</td><td>✗</td><td>SW</td><td>✗</td></tr><tr><td>[23] (PyTorchFI)</td><td>✗</td><td>SW</td><td>✓</td></tr><tr><td>[24] (LLTFI)</td><td>✗</td><td>Architectural (ISA/IR)</td><td>✓</td></tr><tr><td>[25] (Saca-FI)</td><td>✓</td><td>Microarchitecture</td><td>✓</td></tr><tr><td>[26]</td><td>✓</td><td>RTL</td><td>✗</td></tr><tr><td>[27] (SiFI-AI)</td><td>✓</td><td>RTL</td><td>✗</td></tr><tr><td>[6] (FIDELITY)</td><td>✗</td><td>RTL (SW model)</td><td>✓</td></tr><tr><td>[28] (SAFFIRA)</td><td>✓</td><td>RTL (URE equations)</td><td>✓</td></tr><tr><td>[29]</td><td>✓</td><td>RTL</td><td>✗</td></tr><tr><td>[17] (EPICS)</td><td>✗</td><td>GL</td><td>✗</td></tr><tr><td>[18]</td><td>✗</td><td>GL</td><td>✗</td></tr><tr><td>[19]</td><td>✗</td><td>GL (fault model)</td><td>✓</td></tr><tr><td>[20]</td><td>✓</td><td>GL (fault model)</td><td>✓</td></tr><tr><td>[30] (HDFIT)</td><td>✓</td><td>GL (RTL also possible)</td><td>✗</td></tr><tr><td>ENFOR-SA (ours)</td><td>✓</td><td>RTL</td><td>✓</td></tr></tbody></table>

sacrifices accuracy by missing RTL-only effects (e.g., control and interconnects). Another study [29] presents an RTL-SW cross-layer framework to balance speed and accuracy. Still, it requires heavy RTL instrumentation, relies on the less-used N2D2 framework, lacks full end-to-end support, and remains time-consuming because it simulates full convolution channels in RTL.

Micro-architectural fault models for SAs have also been proposed [25]. While such approaches suffice for fault analysis on storage-based components (e.g., scratchpad memories, input buffers, etc.), they lack hardware representation of key components of SAs that also influence fault characterization, such as clock events modeling, pipeline registers, and control-related signals. Sec. IV-B shows how lower-level fault analysis is more suitable to guide selective protection mechanisms.

SW-based solutions [21], [22], [23] or ISA-level approaches [24] have been proposed. Although these approaches are faster than HW simulation, they come at the cost of low accuracy, as such fault models flip bits directly in the SW variables (e.g., the layer outputs or weights) or intermediate representations (e.g., ISA registers), and do not take into account how tensors and operations are mapped to HW during computation. This results in faulty output layers, such as single-bit errors, that do not accurately reflect realistic scenarios. Indeed, when a HW model is used, a single bit flip in a register can lead to multiple bit errors in the output.

Among all works shown in Tab. I, HDFIT [30] is the only open-source tool fully comparable to our approach, sharing the same fault abstraction level and the ability to map fault instrumentation to an SA architecture. The HDFIT tool provides a fine-grained methodology for instrumenting hardware descriptions of arbitrary designs with fault-injection capabilities in Verilator [32]. HDFIT was initially proposed for DNN reliability assessment and was also used for fault analysis of HPC workloads [33], where customized matrix multiplication kernels are offloaded to a gate-level SA simulation. HDFIT can be used with arbitrary hardware descriptions, supporting gate-level netlists or RTL designs. One key shortcoming, however, is that HDFIT relies on instrumenting every combinational and sequential assignment in the HDL. We claim that this is unnecessary for regular RTL designs. Finally, HDFIT does not provide an end-to-end integration with widely used frameworks (e.g., PyTorch). However, thanks to its low-level, API-based approach (oneDNN), we integrated HDFIT-instrumented verilated designs at the RTL level (i.e., not at the gate level) into our framework. As described in the next section, ENFOR-SA achieves faster RTL injection time by avoiding such high-overhead HDL instrumentation.

### III. PROPOSED RELIABILITY ASSESSMENT FRAMEWORK

#### A. Verilator Fault Injection Approach

We propose an alternative solution for Verilator-based fault injection. Unlike previous works, such as [27], [30], our solution does not require HDL instrumentation, thereby avoiding the associated runtime overhead. Fig. 1 illustrates the general idea with an example. It shows the Verilog code for a simple
<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /><figcaption>Fig. 1: Example of Verilog and equivalent verilated codes for a chain of register assignments: ENFOR-SA injects in reg3 by targeting the reg2 variable; HDFIT requires instrumenting each assignment, resulting in additional operations per cycle, even when a single signal is injected (e.g., an 8x8 mesh has 632 assignments, all instrumented).</figcaption></figure>

register assignment chain and the equivalent C++ (verilated) code used in simulation. Verilator generates a C++ RTL model that is functionally equivalent to the original Verilog description. To test the circuit, the user sets the input signals and advances the simulation by toggling the clock and invoking the model's step() function to execute a complete evaluation step. To preserve the semantics of Verilog's register updates, Verilator inverts the order of register assignments, as the figure shows, ensuring that each register's update cycle remains consistent with the hardware behavior. This transformation enables a simple yet effective fault-injection strategy: instead of modifying the HDL (e.g., similar to how HDFIT operates), one can inject into the register's data source by acting on the simulation wrapper code achieving the same effect with a cleaner, more controllable, and free from HDL instrumentation overhead. The same idea of Fig. 1 applies to SA architectures, where PEs propagate signals to neighbours. Hence, we integrate our injection approach with the Gemmini SA [31]. In Gemmini, we can target any signal inside the Processing Elements (PEs), as shown in Fig. 2. In particular, we can inject all pipelined registers used to propagate the inputs and weights, accumulators, and local control signals (Propag and Valid). We provide a brief analysis of the effects of errors in these bits in Sec. IV-B. Note that, for highly regular architectures, such as an RTL SA, injection points can be instrumented by tracking the source-register pointers associated with each PE signal. Fault injection is then performed by randomly flipping bits in these pointers (i.e., the inject() function), effectively corrupting the data sources feeding the PE without modifying the register structures

themselves or requiring high-overhead HDL instrumentation. Following the example shown in Fig. 2, fault injections in the register Rb target (lower PE) can be simulated by targeting Rb source (upper PE). Note that Rb source is not actually affected due to the way Verilator layouts the code by inverting the assignment order: Rb target is assigned first, copying the contents of Rb source (fault injected). Rb source is assigned afterwards, receiving its intended data from its preceding PE. Due to the nature of the SA, we can apply the same approach to all signals within the PEs, including the control signals, which are also propagated through the array. For example, to inject in Reg propag B, one can target Reg propag A, in the upper PE. The lower part of Fig. 2 shows a code snippet of a real verilated case for the propagation of a control signal, e.g., the PE_1_0 propagate register receives data from the PE above it (PE_0_0).

## B. Mesh Isolation for Faster Cross-layer Fault Injection

Fig. 3 shows an abstract view of a conventional heterogeneous SoC design from Chipyard [13], consisting of a core, cache memories and a Gemmini SA. Typically, design exploration is conducted by specifying the relevant hardware parameters, elaborating the design (Step 1), and then mapping it to FPGAs or using Verilator [32] to simulate the design in a host machine. Our framework works on the basis of Verilator. Though verilator has been shown to generate well optimized code for RTL simulation - even surpassing commercial tools in terms of simulation performance [34], [35], the high complexity of a complete SoC model imposes prohibitive overheads for large-scale fault injection campaigns.

1) **Compilation time:** As shown in Fig. 3, the reference accelerator is (loosely) coupled to a core, together with the full memory hierarchy, crossbars, peripherals, and the interfaces to communicate with the SA. On the accelerator side, a full SA architecture is available, with scratchpad memories, a DMA engine, control-related circuitry, an activation unit, and the Mesh

<figure><img src="image_5.png" /><figcaption>Fig. 2: The Gemmini PE's architecture (Simplified. Output stationary). ENFOR-SA can inject in all signals inside the PEs.</figcaption></figure>
unit, which comprises arrays of Multiply-Accumulate (MAC) units for matrix multiplication. Gemmini provides both output-stationary (OS) and weight-stationary (WS) execution modes. Our goal is to perform fault analysis on the SA by capturing only Mesh-related computation (i.e., the Mesh.v block) and its masking properties. This unit comprises pipelined MAC units and all relevant RTL signals for fault injection. Essential signals are the PE input and output (accumulator) registers, and valid/propagate control signals. Our approach consists of a **compilation** phase, where we generate the SoC (Step 1) and isolate the Mesh unit (Step 2) to avoid RTL simulation of other HW blocks. This phase is done only once per HW configuration, and is transparent w.r.t. DNN models.

2) Runtime: Fig. 4 shows the **runtime** phase of our tool. We use interface adapters to drive PyTorch tensors to the Mesh unit. By bypassing hardware components irrelevant to fault analysis, our platform delivers significant speedups over conventional full-SoC simulation (details in Sec. IV-B). The ENFOR-SA tool enables fault injection into pretrained PyTorch CNN models [36] and Vision Transformer (ViT) models [37]. For CNNs, fault injection is performed by hooking the forward pass of target convolutional layers: to map this type of layer to Gemmini, convolutions are expressed as matrix multiplications by using the im2col procedure. For the ViT models, we target matmul-related tasks inside the attention blocks and the classification layer. As Fig. 4 shows, at runtime, the forward pass of a target layer is redirected to a custom implementation that binds to Gemmini mesh. For a single transient fault, only a single activation tile and one from the weight tensors is extracted and offloaded to the accelerator. Cross-layer simulation is achieved by using a low-cost binding approach (pybind11) to bind the PyTorch-level tensor tiles to C++, which is then

<figure><img src="image_6.png" /><figcaption>Fig. 3: In step 1, we generate the original SoC system; in step 2, we extract the Mesh module and couple it to interface adapters that emulate major hardware blocks required for systolic simulation (e.g., shift registers, transposers). A library is generated and used at runtime.</figcaption></figure>

converted to native data types for direct offloading to the Mesh for matrix multiplication in Verilator. To perform the matrix multiplication, the complete Mesh unit is simulated, and a single transient fault is injected into a given target MAC unit during computation. Lastly, the matrix multiplication result is flushed from the mesh (in OS mode) and mapped back to the PyTorch layer's output.

# IV. EXPERIMENTAL RESULTS

## A. Experimental setup

We experiment with the pre-trained quantized models shown in Tab. II [36], [38]. These models are optimized for reduced-precision integer arithmetic (int8) and can be seamlessly integrated with state-of-the-art accelerators such as Gemmini. Our experimental setup uses a 96-core AMD EPYC 7443 server processor @2.8GHz for the CNNs, as the quantized CNN models do not support CUDA. With the ViT models, we were able to utilize an NVIDIA A40 GPU. We use a subset of 20 input batches, each with 32 inputs, randomly selected from the ImageNet validation set. Our experiments aim to 1) compare the achievable performance improvements w.r.t the HDFIT tool, and 2) show that ENFOR-SA achieves RTL accuracy with performance comparable to SW-based injections. Thus, we experiment with three fault injection scenarios: 1) our ENFOR-SA methodology, 2) HDFIT instrumentation approach; and 3) software-only fault injection, used as a baseline for injection time comparison. For RTL performance evaluation, we consider varying array configurations. For injection experiments, we used an 8×8 OS config (referred to as DIM8). For both SW and RTL, we inject 500 transient faults per layer per input, totaling nearly 42M faults and ensuring statistical significance according to [1]. From the fault injection campaigns, we derive the Architectural Vulnerability Factor (AVF) [39] of the array, based on the percentage of critical inferences across all injection trials. We consider a fault as critical if it causes the model's Top-1 classification label to diverge from the golden (fault-free) classification.

## B. Evaluation Results

We compare the mean cycle time of ENFOR-SA to the HDFIT case (both Mesh-only). Tab. III shows the mean cycle time, averaged after 1 million simulation cycles (i.e., 1M raw calls to *dut* → *step*()), for both approaches. We used the same SA configurations for both HDFIT and ENFOR-SA at the

<table><caption>TABLE II: Evaluated quantized models.</caption><thead><tr><td>Quantized model</td><td>Accuracy (Top-1)</td><td>Parameters</td></tr></thead><tbody><tr><td>MobileNetV2</td><td>71.60%</td><td>3.50M</td></tr><tr><td>DeiT-T</td><td>72.24%</td><td>5.00M</td></tr><tr><td>GoogLeNet</td><td>69.8%</td><td>6.60M</td></tr><tr><td>ShuffleNetX20</td><td>75.3%</td><td>7.40M</td></tr><tr><td>ResNet18</td><td>69.4%</td><td>11.7M</td></tr><tr><td>DeiT-S</td><td>80.1%</td><td>22.0M</td></tr><tr><td>ResNet50</td><td>80.2%</td><td>25.6M</td></tr><tr><td>InceptionV3</td><td>77.1%</td><td>27.2M</td></tr><tr><td>ResNeXt64</td><td>82.8%</td><td>83.5M</td></tr><tr><td>ResNeXt32</td><td>82.5%</td><td>88.8M</td></tr></tbody></table>
<figure><img src="image_7.png" /><figcaption>Fig. 4: Runtime cross-layer call stack. A lightweight model instrumentation offloads the (per-tile) matmul kernel (e.g., convolutions or an attention blocks) down to an RTL SA module to perform matrix multiplication. The SA result is flushed from the internal PE accumulators and sent back to the PyTorch layer through fast interfaces.</figcaption></figure>

RTL level, but instrumented HDFIT HDL for fault injection, as described in the original HDFIT approach. HDFIT's heavy instrumentation incurs considerable runtime overhead compared to non-instrumented HDL. Thus, ENFOR-SA achieves an average performance improvement of 2.66×.

**Matrix multiplication performance:** Tab. IV shows the mean time taken to perform matrix multiplications ($C = A \cdot B + D$) with varying array sizes (averaged after 1k matmuls) for both ENFOR-SA and HDFIT cases. The time taken comprises the cumulative steps of all phases of systolic computation, accounting for: time for preloading a bias matrix (D) to the PE accumulators, propagating the input matrices through the array (A and B) and performing MAC computations, and flushing the PE output into a result matrix (C). On average, we outperform HDFIT by a factor of 2.19×.

**Case study - ResNet50 performance:** We assess the performance improvements of ENFOR-SA w.r.t the full-SoC design by measuring the time taken for a full forward pass on the ResNet50's first convolution layer, shown in Tab. V. We simulate the layer in three cases: (i) the full-SoC, the original Chipyard Gemmini accelerator, consisting of the complete chip design, encompassing a RISC-V Rocket core + the full Gemmini SA, (ii) the Mesh-only HDFIT design, and (iii) ENFOR-SA. All approaches run completely on Verilator. As expected, simulating only the Mesh design has significant performance improvements w.r.t. the full-SoC simulation. Note that the performance improvement decreases as the array size increases. As all configurations differ only in the number of PEs (sharing the same configurations for all other parameters), the proportion of Mesh signals increases with larger DIM sizes, thereby reducing

the effectiveness of Mesh-only simulation relative to the whole chip. Moreover, ENFOR-SA improves upon the full-SoC by at least two orders of magnitude. HDFIT imposes significant overhead when compared to ENFOR-SA. Across all configurations, ENFOR-SA outperforms HDFIT by an average of 2.03× in terms of simulation performance.

**Case study - ResNet50 injection:** To demonstrate the capabilities of our approach, we perform cross-layer fault injections by offloading a single matmul to RTL (to be injected). We consider faults in control-related signals of the Gemmini SA, which are typically available only in RTL representation. In Gemmini, each PE has two local control signals: 1) a propag signal is used to propagate the data in the PE accumulators to the next PE below (used for preloading bias matrices and flushing the results out of the SA), and 2) a valid signal is asserted for every new incoming valid data in each PE. Fig. 5a shows the AVF for each PE when control signals are affected. When valid=1, the PE will perform a MAC operation using the inputs for that cycle. If a fault sets valid=0, the PE will not update its accumulator for one cycle, corrupting the PE output. During output-stationary computation, the propag bit must remain fixed at 0 (it is set to 1 only during preloading and output flushes). Consequently, a fault that erroneously asserts this bit to 1 during computation forces the PE accumulator to receive propagated accumulator data from the PE above for one cycle. Since this bit is forwarded to downstream PEs, the resulting corruption propagates through the entire column (affecting the target PE and all PEs below it), thus making the upper rows more critical. This insight is particularly relevant for evaluating selective protection mechanisms at the PE level,

<table><caption>TABLE III: Mean cycle time for the explored array sizes.</caption><thead><tr><th>Array Size</th><th>ENFOR-SA (mesh only)</th><th>HDFIT (mesh only)</th><th>Improvement</th></tr></thead><tbody><tr><td>DIM4</td><td>0.084µs</td><td>0.245µs</td><td>2.91x</td></tr><tr><td>DIM8</td><td>0.403µs</td><td>1.189µs</td><td>2.95x</td></tr><tr><td>DIM16</td><td>1.859µs</td><td>5.788µs</td><td>3.11x</td></tr><tr><td>DIM32</td><td>16.73µs</td><td>39.65µs</td><td>2.36x</td></tr><tr><td>DIM64</td><td>100.1µs</td><td>199.9µs</td><td>1.99x</td></tr></tbody></table>

<table><caption>TABLE IV: Mean matmul time for the explored array configs.</caption><thead><tr><th>Array Size</th><th>ENFOR-SA (mesh only)</th><th>HDFIT (mesh only)</th><th>Improvement</th></tr></thead><tbody><tr><td>DIM4</td><td>0.006ms</td><td>0.014ms</td><td>2.08x</td></tr><tr><td>DIM8</td><td>0.040ms</td><td>0.087ms</td><td>2.15x</td></tr><tr><td>DIM16</td><td>0.248ms</td><td>0.669ms</td><td>2.69x</td></tr><tr><td>DIM32</td><td>4.607ms</td><td>9.328ms</td><td>2.02x</td></tr><tr><td>DIM64</td><td>48.97ms</td><td>98.02ms</td><td>2.00x</td></tr></tbody></table>
<table><caption>TABLE V: Mean time for a full forward pass of the ResNet50's 1st convolution layer. All cases have RTL accuracy.</caption><thead><tr><th>Array Size</th><th>ENFOR-SA (mesh only)</th><th>Full SoC</th><th>ENFOR-SA vs Full SoC</th><th>HDFIT (mesh only)</th><th>ENFOR-SA vs HDFIT</th></tr></thead><tbody><tr><td>DIM4</td><td>19.8s</td><td>06h21min</td><td>1155.6x</td><td>31.4s</td><td>1.58x</td></tr><tr><td>DIM8</td><td>5.86s</td><td>01h16min</td><td>785.23x</td><td>10.6s</td><td>1.82x</td></tr><tr><td>DIM16</td><td>3.75s</td><td>28min55s</td><td>462.55x</td><td>9.51s</td><td>2.53x</td></tr><tr><td>DIM32</td><td>7.35s</td><td>29min24s</td><td>240.33x</td><td>17.2s</td><td>2.34x</td></tr><tr><td>DIM64</td><td>17.4s</td><td>57min46s</td><td>198.66x</td><td>32.7s</td><td>1.87x</td></tr></tbody></table>

where a low-level architectural representation is necessary.

We complement our analysis by injecting faults into the registers holding the DNN weights, which in our configuration flow horizontally across the SA from left to right (though in OS mode, weights may also flow vertically from top to bottom). Faults in these registers may be masked when multiplied by zero-valued activations. Figure 5b reports the probability that a fault in these registers becomes exposed to the SW layer, i.e., the probability of not being masked, thus corrupting a layer's output. Notably, the first columns are more critical: faults occurring in “earlier” PEs have more opportunities to propagate to subsequent units (i.e., the fault tends to be more “reused” along the row), thereby reducing the likelihood of fault masking within the array. Note that the software layer may mask exposed faults due to inherent DNN noise robustness, so high exposure probabilities do not necessarily translate into high model AVF.

Table VI shows the estimated AVF (computed at RTL) for DNNs. For each DNN, we also estimate the Program Vulnerability Factor (PVF) obtained from SW-only injections. The PVF only encapsulates SW-level masking properties [40] and does not account for HW-level masking. This yields pessimistic vulnerability estimates. Overall, our mean PVF estimation is 5.3x higher than the mean AVF. Although this observation is not new [41], we leverage it here to illustrate the gap between HW-aware and HW-agnostic fault injection, further justifying the importance of accurate analysis.

**Injection time evaluation:** Tab. VI shows the total injection time for all models. We compare the SW-only injection time, where injections are performed in SW variables (with no RTL modules involved) against our cross-layer procedure (faults at RTL). Although faster, SW injection does not capture any HW-related masking properties, thus providing less accurate results,

<figure><img src="image_8.png" /><figcaption>(a) Targeting the control signals. (b) Targeting the registers holding weights (left to right propagation)</figcaption></figure>

<caption>Fig. 5: ReNet50: a) AVF for control signals. b) Fault exposure probability for data registers. The config is an 8×8 SA (OS).</caption>

<table><caption>TABLE VI: Injection time and AVF/PVF vulnerability factors.</caption><thead><tr><th>Model</th><th>SW (inputs)</th><th>ENFOR-SA (RTL)</th><th>Slowdown</th><th>PVF*</th><th>AVF*</th></tr></thead><tbody><tr><td>MobileNetV2</td><td>2.44h</td><td>2.80h</td><td>14.7%</td><td>2.67%</td><td>1.00%</td></tr><tr><td>DeiT-T</td><td>4.76h</td><td>4.93h</td><td>3.57%</td><td>9.95%</td><td>0.91%</td></tr><tr><td>GoogLeNet</td><td>2.73h</td><td>3.10h</td><td>13.5%</td><td>0.97%</td><td>0.61%</td></tr><tr><td>SuffleNetX20</td><td>12.1h</td><td>12.6h</td><td>4.13%</td><td>2.11%</td><td>0.60%</td></tr><tr><td>ResNet18</td><td>1.66h</td><td>1.80h</td><td>8.43%</td><td>1.76%</td><td>0.64%</td></tr><tr><td>DeiT-S</td><td>7.93h</td><td>8.21h</td><td>3.53%</td><td>9.02%</td><td>0.85%</td></tr><tr><td>ResNet50</td><td>6.64h</td><td>7.00h</td><td>5.42%</td><td>0.97%</td><td>0.34%</td></tr><tr><td>InceptionV3</td><td>7.90h</td><td>8.00h</td><td>1.26%</td><td>0.76%</td><td>0.29%</td></tr><tr><td>ResNeXt64</td><td>24.0h</td><td>24.6h</td><td>2.71%</td><td>1.02%</td><td>0.19%</td></tr><tr><td>ResNeXt32</td><td>25.4h</td><td>26.0h</td><td>2.67%</td><td>0.60%</td><td>0.11%</td></tr><tr><td>Mean</td><td>9.55h</td><td>9.91h</td><td>6.00%</td><td>2.98%</td><td>0.55%</td></tr></tbody></table>

as previously shown.

Other HW-agnostic tools, such as LLTFI (ISA-level error modeling) [24], suffer from instrumentation overheads of up to 117% (mean 68%). We take a different direction by offloading only a single tile for RTL injection, resulting in a relatively modest maximum overhead of 14.7% (mean 6%). This enables us to deliver RTL-accurate results with lower overhead than previous (less accurate) ISA-level approaches. Overall, our method bridges the performance-accuracy gap in error analysis, achieving RTL fidelity while maintaining injection times comparable to SW-based techniques.

**Accuracy validation against HDFIT [30]:** We validate ENFOR-SA accuracy by comparing it with the fully instrumented HDFIT method. For both ENFOR-SA and HDFIT, we perform random matrices while injecting faults into the PE signals. The same input matrices, fault locations, and injection cycles are used for both methods. We then compare the resulting faulty output matrices and confirm that ENFOR-SA and HDFIT produce identical results. This demonstrates that our approach reproduces HDFIT's injection behavior with no loss in accuracy while enabling significantly faster analysis.

## V. CONCLUSIONS AND FUTURE WORK

We propose an accurate and efficient end-to-end transient fault injection methodology that tightly integrates DNN workloads with RTL-level SA hardware models. To reduce RTL simulation time, we introduce a non-intrusive injection method and target only the Mesh component of the SA. Our approach uses cross-layer simulation by mapping to the RTL level only the PyTorch tensors to inject, while executing the remaining simulation in software. We achieve a speedup of at least two orders of magnitude compared to full-SoC RTL simulation, with an average speedup of 569x and a runtime similar to the full-SW approach (only a 6% average slowdown). Additionally, we outperform a state-of-the-art instrumentation tool by an average of 2.03x in injection performance, all while maintaining RTL accuracy.

## ACKNOWLEDGMENT

This work was supported by the French National Research Agency through the RE-TRUSTING project ANR-21-CE24-0015 and the FASY project ANR-21-CE25-0008-01.

<footnote>*percentage of critical inferences</footnote>
REFERENCES

[1] A. Ruospo et al., "Assessing convolutional neural networks reliability through statistical fault injections," in *2023 Design, Automation & Test in Europe Conference & Exhibition (DATE)*, 2023, pp. 1–6.

[2] G. Papadimitriou et al., “Demystifying the system vulnerability stack: transient fault effects across the layers,” ser. ISCA ’21. IEEE Press, 2021, p. 902–915.

[3] F. F. d. Santos et al., “Revealing gpus vulnerabilities by combining register-transfer and software-level fault injection,” in *2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)*, 2021, pp. 292–304.

[4] A. Tyagi et al., “Thales: Formulating and estimating architectural vulnerability factors for dnn accelerators,” 2024.

[5] C. Bolchini et al., “Fast and accurate error simulation for cnns against soft errors,” *IEEE Trans. Comput.*, vol. 72, no. 4, p. 984–997, Apr. 2023.

[6] Y. He et al., “Fidelity: Efficient resilience analysis framework for deep learning accelerators,” in *2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)*, 2020, pp. 270–281.

[7] J. Zhang et al., “Thundervolt: enabling aggressive voltage underscaling and timing error resilience for energy efficient deep learning accelerators,” in *Proceedings of the 55th Annual Design Automation Conference, ser. DAC ’18*. New York, NY, USA: Association for Computing Machinery, 2018.

[8] X. Jiao et al., “An assessment of vulnerability of hardware neural networks to dynamic voltage and temperature variations,” in *2017 IEEE/ACM International Conference on Computer-Aided Design (IC-CAD)*, 2017, pp. 945–950.

[9] J. J. Zhang et al., “Analyzing and mitigating the impact of permanent faults on a systolic array based neural network accelerator,” in *2018 IEEE 36th VLSI Test Symposium (VTS)*, 2018, pp. 1–6.

[10] X.-X. Wu et al., “Accuracy tolerant neural networks under aggressive power optimization,” in *2020 Design, Automation and Test in Europe Conference and Exhibition (DATE)*, 2020, pp. 774–779.

[11] L. A. de Melo et al., “Microfi: Tensorflow lite based fault injection framework for microcontrollers,” in *2025 IEEE 43rd VLSI Test Symposium (VTS)*, 2025, pp. 1–7.

[12] A. Veronesi et al., “Cross-layer reliability analysis of nvdla accelerators: Exploring the configuration space,” in *Proceedings of the 29th IEEE European Test Symposium 2024*, May 2024.

[13] A. Amid et al., “Chipyard: Integrated design, simulation, and implementation framework for custom socs,” *IEEE Micro*, vol. 40, no. 4, pp. 10–21, 2020.

[14] F. Su et al., “Testability and dependability of ai hardware: Survey, trends, challenges, and perspectives,” *IEEE Design & Test*, vol. 40, no. 2, pp. 8–58, 2023.

[15] A. Ruospo et al., “A Survey on Deep Learning Resilience Assessment Methodologies,” *IEEE Computer Magazine*, February 2023.

[16] M. H. Ahmadilivani et al., “A systematic literature review on hardware reliability assessment methods for deep neural networks,” *ACM Comput. Surv.*, vol. 56, no. 6, Jan. 2024.

[17] M. Wang et al., “Epics: Efficient parallel pattern fault simulation for sequential circuits via strongly connected components,” in *Proceedings of the 62nd Annual ACM/IEEE Design Automation Conference, ser. DAC ’25*. IEEE Press, 2025.

[18] A. Porsia et al., “On the resilience of int8 quantized neural networks on low-power risc-v devices,” in *2025 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W)*, 2025, pp. 119–122.

[19] L. Lu et al., “Machine learning methodologies to predict the results of simulation-based fault injection,” *IEEE Transactions on Circuits and Systems I: Regular Papers*, vol. 71, no. 5, pp. 1978–1991, 2024.

[20] A. Chaudhuri et al., “Efficient fault-criticality analysis for ai accelerators using a neural twin,” in *2021 IEEE International Test Conference (ITC)*, 2021, pp. 73–82.

[21] H. Huang et al., “Mrfi: An open-source multiresolution fault injection framework for neural network processing,” *IEEE Transactions on Very Large Scale Integration (VLSI) Systems*, vol. 32, no. 7, pp. 1325–1335, 2024.

[22] Z. Chen et al., “Binfi: an efficient fault injector for safety-critical machine learning systems,” in *Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’19*. New York, NY, USA: Association for Computing Machinery, 2019.

[23] A. Mahmoud et al., “Pytorchfi: A runtime perturbation tool for dnnss,” in *2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W)*, 2020, pp. 25–31.

[24] U. K. Agarwal et al., “Lltfi: Framework agnostic fault injection for machine learning applications (tools and artifact track),” in *2022 IEEE 33rd International Symposium on Software Reliability Engineering (ISSRE)*, 2022, pp. 286–296.

[25] J. Tan et al., “Saca-fi: A microarchitecture-level fault injection framework for reliability analysis of systolic array based cnn accelerator,” *Future Generation Computer Systems*, vol. 147, pp. 251–264, 2023.

[26] U. K. Agarwal et al., “Towards reliability assessment of systolic arrays against stuck-at faults,” in *2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks - Supplemental Volume (DSN-S)*, 2023, pp. 230–236.

[27] J. Hoefer et al., “Sifi-ai: A fast and flexible rtl fault simulation framework tailored for ai models and accelerators,” in *Proceedings of the Great Lakes Symposium on VLSI 2023*, ser. GLSVLSI ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 287–292.

[28] M. Taheri et al., “Saffira: a framework for assessing the reliability of systolic-array-based dnn accelerators,” in *2024 27th International Symposium on Design & Diagnostics of Electronic Circuits & Systems (DDECS)*, 2024, pp. 19–24.

[29] S. Pappalardo et al., “A fault injection framework for ai hardware accelerators,” in *2023 IEEE 24th Latin American Test Symposium (LATS)*, 2023, pp. 1–6.

[30] P. Omland et al., “Api-based hardware fault simulation for dnn accelerators,” *IEEE Design & Test*, vol. 40, no. 2, pp. 75–81, 2023.

[31] H. Genc et al., *Gemmini: Enabling Systematic Deep-Learning Architecture Evaluation via Full-Stack Integration*. IEEE Press, 2022, p. 769–774.

[32] V. . W. Snyder, “Verilator: fast verilog/systemverilog simulator,” https://www.veripool.org/verilator/, 2025.

[33] P. Omland et al., “Hpc hardware design reliability benchmarking with hdfit,” *IEEE Transactions on Parallel and Distributed Systems*, vol. 34, no. 3, pp. 995–1006, 2023.

[34] S. Beamer et al., “Efficiently exploiting low activity factors to accelerate rtl simulation,” in *2020 57th ACM/IEEE Design Automation Conference (DAC)*, 2020, pp. 1–6.

[35] D.-L. Lin et al., “Fromrtl to cuda: A gpu acceleration flow forrtl simulation with batch stimulus,” in *Proceedings of the 51st International Conference on Parallel Processing*, ser. ICPP ’22. New York, NY, USA: Association for Computing Machinery, 2023.

[36] TorchVision Contributors, “Torchvision: Pytorch’s computer vision library,” https://docs.pytorch.org/vision/main/models\#quantized-models, 2025, accessed: 2025-11-17.

[37] Z. Li et al., “I-vit: Integer-only quantization for efficient vision transformer inference,” in *2023 IEEE/CVF International Conference on Computer Vision (ICCV)*, 2023, pp. 17019–17029.

[38] I-VIT Contributors, “I-vit: Integer-only quantization for efficient vision transformer inference,” https://github.com/zkkli/I-ViT, 2025, accessed: 2025-12-09.

[39] S. Mukherjee et al., “A systematic methodology to compute the architectural vulnerability factors for a high-performance microprocessor,” in *Proceedings. 36th Annual IEEE/ACM International Symposium on Microarchitecture*, 2003. MICRO-36., 2003, pp. 29–40.

[40] V. Sridharan et al., “Quantifying software vulnerability,” in *Proceedings of the 2008 Workshop on Radiation Effects and Fault Tolerance in Nanometer Technologies*, ser. WREFT ’08. New York, NY, USA: Association for Computing Machinery, 2008, p. 323–328.

[41] V. Sridharan et al., “Using hardware vulnerability factors to enhance avf analysis,” in *Proceedings of the 37th Annual International Symposium on Computer Architecture*, ser. ISCA ’10. New York, NY, USA: Association for Computing Machinery, 2010, p. 461–472.