1 Introduction↩︎

Edge AI deployments in safety-critical domains (e.g., autonomous vehicles, industrial automation, etc.) require fault tolerance under tight hardware and environmental constraints [1]–[5]. Dual and triple modular redundancy (DMR/TMR) remain the de facto standard in such systems [6]–[9], e.g., Tesla’s full self-driving [2] and OpenTitan’s root of trust [10]. DMR (at least) doubles, and TMR triples, the hardware footprint, increasing area and power and constraining resources for the primary application.

Software-based fault tolerance offers a lower-cost alternative to hardware redundancy. Examples include checkpoint-and-rollback, which periodically saves system state and restores it upon fault detection [11], and algorithm-based fault tolerance (ABFT), which embeds checksums into neural network (NN) computations to detect errors without full hardware replication  [12], [13]. On FPGA SoCs, however, checkpointing requires dedicated support for efficient state capture that commercial devices do not provide [11], [14], and ABFT has not yet been integrated with FPGA accelerators to achieve complete fault coverage [15]. Moreover, both approaches lack the fine-grained error localization needed for precise recovery.

Fig. 1 outlines our proposed framework EIR , which combines digital twin notions with FPGA SoC hardware-software co-design to enable self-healing at a system level. The key novelty of EIR is its hierarchical digital-twin architecture that (i) exploits idle processing system (PS) cycles, (ii) avoids DMR/TMR area overhead, (iii) uses a checkpoint policy, and (iv) incorporates a state-capture-and-restoration mechanism to opportunistically snapshot programmable logic (PL) state into off-chip memory. This digital twin hierarchy consists of: (i) Rabbit, a fast (coarse-grained) behavioral model that monitors execution and detects deviations (of its PL counterpart) by recomputing at a higher-level abstraction in software. This twin prioritizes speed over cycle-accurate fidelity, enabling rapid periodic validation of accelerator outputs to detect faults. (ii) Tortoise, a slower (fine-grained) gate-level equivalent model that remains idle until a fault is detected. When activated, Tortoise emulates execution from a known-good checkpoint and reconstructs a correct system state for on-chip recovery.

To address the inherent speed and resource imbalance between the PS and the accelerator,  EIR employs a latency-aware checkpointing policy that twins only critical computation phases. At selected checkpoints, Rabbit executes the same inputs as the PL accelerator and compares outputs. Upon detecting a mismatch, Rabbit triggers Tortoise to replay a fault-free checkpoint at gate-level fidelity to emulate the correct system state¹. PL then restores this state, enabling software-like checkpoint-based recovery without DMR/TMR hardware redundancy.

 EIR’s hierarchical approach offers three advantages over conventional redundancy: (i) it activates only during detection and recovery instead of running redundant hardware continuously, (ii) it avoids duplicating PL accelerator logic by hosting twins on the PS and storing checkpoints in off-chip memory, and (iii) it supports mid-execution state restoration through the gate-level twin, whereas DMR typically halts operation without in-situ recovery.

The key contributions of this work are:

• Hierarchical digital twin architecture: We introduce the first dual-granularity digital twin framework specifically designed for FPGA SoC accelerators, combining rapid functional detection with precise gate-level recovery.

• Hardware-software checkpoint integration: We demonstrate a practical implementation of checkpoint-based fault tolerance leveraging FPGA SoC-specific features with execution speed-informed checkpoint selection that balances detection latency against storage overhead.

• Self-healing methodology for edge AI: We present an end-to-end system enabling autonomous fault recovery in resource-constrained accelerators, offering an alternative to full redundancy that delivers comparable empirical fault coverage at reduced energy and area cost.

• Experimental validation: We demonstrate EIR’s applicability on representative neural network topologies, achieving top \(30\)% neuron coverage with \(\geq95\)% fault detection rate, while quantifying its resource benefits against DMR baselines. Moreover, we evaluated \(11\) applications as representative benchmarks. Across the tested accelerators, EIR preserves the baseline PL area, whereas DMR increases LUT/FF utilization by approximately \(2.0\)–\(2.25\times\) and raises power consumption from \(2.98\) W to \(5.79\) W (\(\approx89.1\)%), on average.

Unlike prior works that either replicate hardware or detect errors without recovery, EIR  is the first to combine software-based detection with cycle-accurate state reconstruction for in-place recovery on FPGA SoCs. EIR ’s hierarchical twin design allows fault tolerance to be achieved without modifying accelerator RTL or duplicating logic in the reconfiguration fabric.

2 Background and Related Work↩︎

This section reviews prior efforts in fault tolerance, redundancy reduction, and FPGA SoC resilience, most relevant to EIR.

2.1 Hardware Redundancy for Fault Tolerance↩︎

Spatial redundancy is a common technique for fault tolerance [1], [8]. TMR replicates a module three times with majority voting to mask single faults. TMR achieves high coverage but consumes \(2\)-\(3\times\) more resources and increases power [7]. DMR reduces this overhead using two replicas, but lacks automatic correction [6]. Recent work proposed HMR-NEureka, a selective scheme for FPGA neural accelerators [9]. However, it still incurs sizable overheads—reporting a \(2.1\times\) area increase for a RISC-V core with integrated error prediction. Hierarchical designs, such as HyCA reduce cost by pairing \(2\)D processing element (PE) array with a backup unit that recomputes operations mapped to faulty PEs, but they still require dedicated spare hardware in the fabric [16]. In edge AI deployments with stringent area and power budgets, even partial hardware redundancy, such as selective replication of critical components, can be impractical due to its resource overhead. By contrast, EIR sidesteps fabric-level duplication entirely by repurposing underutilized PS to achieve comparable fault resilience via software-based replication.

2.2 Algorithm-Based Fault Tolerance (ABFT)↩︎

ABFT uses mathematical structure of computations to embed fault detection and correction capabilities without full hardware duplication [8]. For NNs, ABFT typically augments matrix operations with row and column checksums computed during forward propagation in which mismatches between output and expected checksums indicate errors. ApproxABFT extends this concept by introducing approximate, tolerance-aware checksums and reports a \(43.39\)% reduction in overhead compared to traditional ABFT while increasing tolerable error rates [15]. However, deploying ABFT on FPGA SoCs faces three challenges: (i) architecture-agnostic designs miss hardware-specific efficiency opportunities, (ii) checksum computation and verification may violate edge inference latency budgets, and (iii) ABFT primarily detects, but does not correct, faults [12]. For mission-critical applications, this detection-only capability is insufficient, as it neither prevents silent data corruption nor restores correct operation; instead, timely fault localization and automated state recovery are required to maintain correct operation.

2.3 Checkpoint and Rollback Mechanisms↩︎

Checkpoint-based fault tolerance periodically saves system state to stable storage and restores it upon errors, enabling backward recovery without full re-execution [11], [13], [17]. While effective in processor-centric systems, applying checkpointing to FPGA SoC accelerators is non-trivial because: (i) Accelerator state spans registers, distributed memories, pipeline buffers, and configuration bits, and (ii) checkpoint intervals must balance detection latency (longer intervals increase exposure to undetected faults) against memory traffic and storage overhead. Recent FPGA debugging frameworks (e.g., StateMover [18], Zoomie [19]) combine FPGA execution speed with simulation observability using checkpoint-based flows [14], [20]. These approaches, however, assume PC-based host-in-the-loop simulation and target pre-deployment verification. By contrast, EIR: (i) pursues autonomous, in-field fault tolerance rather than verification workflows, (ii) uses hierarchical twins—for runtime fault-detection and recovery, and (iii) runs entirely on the chip, enabling self-healing at the edge, avoiding host dependence.

2.4 Existing Self-Healing Architectures↩︎

Self-healing FPGA systems detect and repair configuration upsets by combining scrubbing—periodically reading and correcting configuration memory—with partial reconfiguration (PR) to replace faulty regions [21], [22]. Scrubbing fixes only configuration-memory faults, not logic errors in on-chip data or registers. Early PR-based systems recover from single-event upsets (SEUs) but depend on an external host (often a PC) to regenerate bitstreams, reducing autonomy and increasing latency and complexity [23]. Scalable self-healing circuits automate recovery but focus on control logic, leaving silent data corruptions and subtle computation errors in accelerator datapaths unresolved [24]. Auto-Healer detects perception faults in autonomous driving by monitoring runtime behavior and triggering recovery [3]. Although aligned with EIR’s goals, Auto-Healer operates at the software algorithm level (e.g., misclassification detection) and relies on DMR-style replication for error detection. By contrast,  EIR removes fabric-level redundancy and uses hierarchical digital twins to detect and repair circuit-level faults directly, preventing them from propagating into misclassifications.

2.5  EIR’s Scope and Assumptions↩︎

 EIR targets FPGA SoC platforms, e.g., AMD/Xilinx Zynq-\(7000\)/UltraScale/UltraScale+ devices. The primary accelerator executes in the PL, while the PS runs the application’s twins and hosts the EIR framework. EIR can mitigate both single and multi-bit transient faults caused by voltage fluctuations, electromagnetic interference, and radiation-induced bit flips that may affect (i) PL configuration memory, (ii) on-chip data memories (storing weights and biases²). We assume Block-RAMs, PS, and off-chip checkpoint memory (DDR) are protected by error-correcting code (ECC) or similar mechanisms and thus remain trustworthy for hosting the twins and coordinating recovery [25]. Permanent faults are outside EIR’s scope, focusing on transient errors that can be corrected by restoring a known-good state.

EIR is best suited to digital accelerators whose relevant state can be checkpointed and replayed without irreversible external side effects, and platforms where PS can run Rabbit at checkpoints and Tortoise on rare faults. EIR is well-suited to applications that demand lower PL area and energy overhead and can accommodate bounded recovery stalls e.g., edge AI and cloud FPGAs  [26].

3 The Proposed Framework: EIR↩︎

Fig. 2 shows EIR’s system-level architecture. The PL hosts the target accelerator, while an AXI-GPIO core monitors its outputs. Fault detection and recovery are assigned to the PS, preserving precious PL resources by avoiding fabric-level replicas. EIR uses the PCAP to read/write PL state, leveraging a logic-location (*.ll) map stored on an attached SD card to selectively read back only utilized regions into off-chip DDR memory. The PS hosts the two digital twins and the checkpoint policy described in Sections 3.1 and 3.2, respectively.

3.1 Hierarchical Twins: Architecture and Flow↩︎

Rabbit (Twin #1) is a coarse-grained twin that operates at a higher abstraction level, replicating the functional behavior of the PL accelerator without modeling individual clock cycles or hardware signal transitions. It executes on the PS, producing expected outputs based on equivalent computational logic, written in C/C++. This higher level abstraction enables fast execution, rapid fault detection and consistency verification—Rabbit (typically) completes its operation faster than a cycle-accurate simulation would require [14], [19]. However, Rabbit cannot shadow the PL accelerator continuously, as in DMR, for three reasons: (i) Typically, the PS executes an application slower than the PL, so a full, always-on replica would lag behind, (ii) continuously running Rabbit would monopolize PS cycles needed for other system tasks, and (iii) persistent execution would increase energy consumption, conflicting with edge constraints. To address this inherent speed and resource imbalance, EIR employs a latency-aware decision mechanism that selectively identifies critical computation phases to twin (refer Sec. 3.2). At these checkpoints, Rabbit processes the same input batch as the PL accelerator and compares outputs. Upon a mismatch, it triggers Tortoise for fault mitigation and system recovery.

Tortoise (Twin #2) is a fine-grained, gate-level twin that provides cycle-accurate emulation of the PL accelerator. Tortoise uses the Yosys CXXRTL backend to convert the same RTL used for the PL bitstream into a C++ model that runs on the PS [27]. This preserves registers, combinational logic, and signal level details, allowing Tortoise to reproduce the hardware’s internal state evolution. Although slower than Rabbit or native PL execution, Tortoise’s fidelity makes it suitable for precise fault localization and recovery. Starting from a verified checkpoint, it can emulate forward to compute the correct PL state and regenerate fault-free outputs. EIR assumes Rabbit consumes only a fraction of available PS cycles during steady-state execution, and that Tortoise is invoked infrequently through exception mechanisms only when needed. The effectiveness of Rabbit depends on the availability of PS compute resources. As PS utilization increases—due to application or system-level workloads—the fraction of computation that can be validated online may decrease. While this may increase fault-detection latency, it does not affect the correctness of recovery once a fault is detected. In such cases, coarser checkpointing or more selective validation policies can be employed to maintain system responsiveness.

3.2 Checkpoint Selection Policy↩︎

Running programs on PS instead of PL could slow it down considerably, making continuous cycle-accurate shadowing infeasible. Guided by prior work and our LeNet-\(5\) case study, EIR instead uses a policy that targets decision-critical computations and places checkpoints around them to bound divergence. We used an AI workload for characterization because neural networks are both highly error-sensitive and representative of modern edge deployments on FPGA SoCs, especially in safety-critical domains, such as autonomous driving, robotics, and industrial automation [2], [28], [29]. Moreover, neural networks exhibit highly non-uniform fault sensitivity across layers, making them a realistic and rigorous benchmark for evaluating EIR’s fault detection, localization, and recovery capabilities [30], [31].

We derive the selection policy in two stages: (i) literature informed sensitivity analysis to identify where faults have the greatest impact [30]–[34], and (ii) a model-specific case study to quantify how much comparison is sufficient. Prior work indicates that (a) faults in early convolutional layers are often masked, while deeper fully connected and output (logit) layers are likely to corrupt outputs [32], [35], (b) vulnerability concentrates in high-magnitude multiply-accumulate (MAC) operations, so protecting high-activation regions yields the largest resilience gain [33], [36], [37], and (c) in fixed-point designs, higher-significance bits (e.g., MSBs) dominate fault impact [38]. While neural networks exhibit inherent error masking, our sensitivity analysis (see Sec 4.3) shows that a small subset of high-contribution MACs dominates outcome-altering faults. This observation motivates  EIR’s selective validation strategy, which targets these critical regions rather than uniformly protecting all computations, enabling efficient fault coverage despite the presence of masking effects.

The checkpoint and validation policy used in this work is intentionally profiling-guided. It is designed to prioritize computation phases that are most likely to affect the final output under the evaluated workload, rather than to provide architecture-independent or formally complete coverage. For workloads with different fault-propagation behavior, dynamic control flow, or shifting input distributions, the protected subset and checkpoint boundaries may need to be re-profiled or selected adaptively. Based on these insights, we next detail our case study.

3.2.1 Model-specific case study↩︎

We implement the LeNet-5 architecture for image classification and pre-train it on CIFAR-10 to obtain inference weights ‘\(w\)’. After training, we apply post-training quantization to the \(w\) and activations to reduce resource usage and align with the deployed accelerator’s precision. The model includes eight layers—two convolutional, two pooling, one flatten, and three fully connected (dense) layers. We describe the design in VHDL at the RTL and synthesize it for FPGA deployment.

3.2.2 Benign baseline and fault injection.↩︎

For each input ‘\(x\)’, we begin with a fault-free execution and record (i) the per-layer outputs and (ii) the final predicted class to establish a reference label and a per-layer catalogue of MAC contribution magnitudes \(|x\!\cdot\!w|\). We then apply a SEU fault model at the MAC-operation level: for a target layer and MAC instance ‘\(i\)’, we inject bit flip (s) into the MAC result register at the cycle of its generation. We perform runtime fault injection through testbench simulations to assess the system’s fault tolerance.

3.2.3 Stage 1 (layer-level sensitivity).↩︎

To examine whether different layers contribute equally to output corruption, we conduct per-layer fault injection campaigns that randomly select MAC instances within the target layer and inject bit-flip(s) per inference. For each injection, we compare the resulting classification with the fault-free baseline to determine whether it causes a misclassification. Aggregating results across all injections produces a per-layer misclassification profile, revealing that convolutional layers generally mask faults, whereas fully connected (dense) and logit layers are more likely to alter the final decision.

3.2.4 Stage 2 (magnitude-aware sensitivity)↩︎

Building on the observation that dense layers have the greatest impact on output integrity, we next quantify which MAC operations within each dense layer contribute most to fault susceptibility. For each dense layer \(l\), input \(x\), and corresponding weight \(w\), we compute the absolute MAC contributions as follows: \[m_{l,i}(x) \;=\; \big|\,x_{l,i}\cdot w_{l,i}\,\big|\]

We rank all MAC operations in descending order of \(|MAC_{l,i}|\) and divide them into contiguous percentiles (e.g., deciles) to study how fault sensitivity varies with contribution magnitude. We then sample MAC indices from each percentile and inject single or multi-bit faults as before. For each percentile, we record misclassifications and class transitions. Aggregating results across percentiles shows that faults cluster in the top ranges, revealing a compact top-\(k_l\) subset in each dense layer responsible for most misclassifications.

3.3 System Checkpoint and Rollback↩︎

 EIR leverages PCAP to read/write the PL state, building on [17], enabling fine-grained state readback of heterogeneous FPGA elements with safe clock gating and synchronized resumption, which directly informs EIR’s checkpointing strategy³. EIR repurposes these primitives of  [17] from preemption to fault tolerance by (i) introducing hierarchical twins for precise fault detection and localization, (ii) triggering recovery only upon detected divergence, and (iii) limiting readback to active PL regions to reduce partial reconfiguration (PR) related read/write traffic and area overhead.

3.4 Fault Detection and Recovery↩︎

EIR’s operation involves three phases: (1) normal operation with periodic validation (against Rabbit’s output), (2) fault localization (via Tortoise), and (3) state correction with in-place recovery.

3.4.1 Normal Operation with Periodic Validation↩︎

PL accelerator executes its operation on the input data. At checkpoint intervals (e.g., after each layer), EIR captures PL state and offloads it to off-chip memory [17]. Concurrently, EIR invokes Rabbit (coarse-grained functional twin) with the same input batch to compute the expected outputs \((O_{\texttt{Rabbit}})\). EIR then compares \(O_{\text{\texttt{Rabbit}}}\) against actual PL outputs \((O_{\text{PL}})\). If \(|O_{\text{\texttt{Rabbit}}} - O_{\text{PL}}| < \epsilon\) (within tolerance \(\epsilon\)), the system continues its normal operation. However, if \(|O_{\text{\texttt{Rabbit}}} - O_{\text{PL}}| \geq \epsilon\), a potential fault is flagged, and EIR transitions to the second phase.

3.4.2 Fault Localization↩︎

Upon detecting divergence between PL and Rabbit‘s output—indicative of a fault—EIR loads the most recent checkpoint (captured at cycle’\(t_{capture}\)’) into Tortoise’s memory, including all registers, control signals, and the input sequence processed by the PL from cycle \(t_{capture}\) to the current faulty cycle \((t_{\text{fault}})\). Tortoise then starts emulating it forward, cycle-by-cycle, computing the expected hardware state evolution. At \(t_{\text{fault}}\), Tortoise produces the fault-free values \((O_{\text{\texttt{Tortoise} }})\) that the PL accelerator would have produced in the absence of the fault. After computing the fault-free output, EIR transitions to the third phase.

3.4.3 State Correction and Recovery↩︎

EIR extracts the corrected state \(O_{{\texttt{Tortoise}}}\) from Tortoise to construct a PR bitstream \((t_{restore})\) to write \(O_{{\texttt{Tortoise}}}\) state to the corresponding PL registers and memories⁴. The PL accelerator resumes execution from the corrected state, continuing its operation without full re-execution.

Replay cost may scale with both the checkpoint distance (\(\Delta\)) and the complexity of the emulated accelerator. Therefore, Tortoise serves as an infrequent exception-path mechanism rather than a continuously active companion. However, state replay over only \(\Delta\) cycles remains less expensive than full re-execution, and the worst-case recovery latency stays bounded by checkpoint spacing and the execution rate of the Tortoise.

4 Experimental Setup and Results↩︎

Test-Platform. We evaluated EIR on the AMD/Xilinx Zynq-\(7000\) (XC\(7\)Z\(020\)), which represents a widely deployed platform in safety-critical domains, powering multi-camera advanced driver assistance systems (ADAS) in autonomous vehicles [28], [40], intelligent traffic management using edge AI [41], high-availability industrial IoT networks with zero-downtime redundancy [42], aerospace [6], and defense avionics [43]. On this platform, we evaluated several canonical benchmarks of varying complexity. All accelerators were written in Verilog and synthesized with Vivado \(2024.2\). The EIR framework uses C/C++ on the PS via Vitis SDK, and Tortoise models are generated with Yosys CXXRTL \(0.50\) [27], [39].

Experimentation flow. Fig. 3 presents the eight steps that capture the essence of the EIR framework and the flow of our experiments. While the figure shows snippets for the \(8\)-bit upcounter example, the steps are universally applicable for any accelerator. The accelerator code is written in RTL language. At this stage, the accelerator is mapped to a specific location using a partition block to track its position. The RTL code is converted into a C++ model using the Yosys CXXRTL backend. The RTL is synthesized with the logic location file generation setting enabled (later exported to the SD card attached to the PS). This enables EIR to identify the contents of each logic element and combine their bit values to create complete and consistent state checkpoints. The bitfile is programmed onto the PL, and execution begins.

3.9pt

A testbench calls the C++ model generated by Yosys. The testbench provides the necessary input values and handles the initialization process. EIR opportunistically captures the state of the accelerator running on the PL and saves it in off-chip DDR memory [17]. Rabbit is periodically executed, computing an independent system state. To check if the data values of the PL diverge from the expected values, the system state (computed by the Rabbit) is compared against the output of the PL. In case of a fault, Tortoise runs for a few \(\Delta\) cycles, computing the latest fault-free state, which is then restored onto the PL, completing fault mitigation and recovery.

3.9pt

4.1 Fault Injection Setup↩︎

0.001pt

To emulate transient faults (without relying on radiation sources or system glitching equipment), we adopted a readback-level fault injection technique, as established in prior works [44]–[49]. During normal execution, the PL accelerator processes inputs, and EIR periodically captures checkpoints via configuration/state readback [17]. To accelerate fault campaigns and ensure rapid, repeatable exposure to fault presence, we inject faults by deliberately corrupting the readback image after checkpoint acquisition but before the subsequent integrity comparison against Rabbit (Sec. 3.2.3). Specifically, EIR XORs selected bit positions with \(1\), thereby emulating transient bit flips, e.g., flipping bit #\(3\) in an \(8\)-bit register holding \(0b1011\boldsymbol{0}101\) produces \(0b1011\boldsymbol{1}101\).

Crucially, this injection point is a methodological convenience rather than a limitation of the EIR. Corrupting readback data is used only to speed up and systematize fault injection (location/rate sweeps) without requiring invasive hardware fault sources. EIR’s operational principle remains unchanged—when live PL faults occur naturally (or are induced by physical means), their effects are captured in its checkpoint state/output. EIR detects this by comparing the checkpoint-derived state/output against Rabbit. Thus, while our campaign uses readback corruption to emulate the presence of a fault efficiently, the same checkpoint-and-compare pipeline is fully capable of detecting faults originating in the live PL computation.

4.2 Benchmarks↩︎

To evaluate EIR, we implemented various canonical designs, inspired from prior works [4], [50], [51]. Table 1 reports the resource utilization for each of these designs and the digital twins (in terms of code size). The considered workloads span a broad spectrum of microarchitectural characteristics: (i) a minimal \(8\)-bit upcounter, used as a sanity check for checkpoint–restore and fault-detection correctness under controlled injections (see Sec. 4.1), (ii) cryptographic accelerators (SHA-\(256\) and AES-\(128\)) that exercise EIR on control-dominated, multi-stage datapaths with finite-state-machine (FSM) control, where faults are injected during active computation to emulate transient cryptographic fault scenarios representative of practical fault-injection attacks [4], [52], [53], and (iii) representative signal-processing and machine-learning kernels, including dense and Conv2D layers, single and multi-head (\(4\)) attention layer, general matrix multiplication (GEMM), fast Fourier transform (FFT-64), and digital filters (finite impulse response (FIR)/Conv1D and infinite impulse response (IIR).

For the edge-AI workloads, implementations follow an \(8\)-bit quantized, systolic-array-style organization (inspired by the Google Edge TPU) to reflect resource-constrained inference settings [54]. Faults are injected into parameter storage and accumulation state (e.g., weights, accumulator registers), consistent with adversarial perturbations of NN parameters in edge deployments [55].

For all benchmarks, Rabbit (Twin #1) was implemented in C as a behavioral model reflecting the functionality of the corresponding hardware design, while Tortoise (Twin #2) was generated from each design’s Verilog description using the CXXRTL backend to produce a cycle-accurate gate-level C++ model. Table 2 presents the execution latencies for the benchmarks on both the PL and the digital twins running on the PS. It also reports the speed ratio relative to the PL, defined as ‘S’ = Twin speed/PL speed.

While Rabbit and Tortoise can be regarded as redundancies in the PS, their overhead is confined to code memory footprint and modest additional PS execution, both of which are easily absorbed by the PS budget. By contrast, DMR in the PL requires a second copy of the accelerator datapath and its on-chip memories, roughly doubling fabric utilization and increasing static and dynamic energy consumption. From Table 3, this advantage is visible across all case studies: DMR⁵ increased PL area (LUT/FF) usage by approximately \(2.0\)–\(2.25\times\) and power consumption from \(2.98\) W to \(5.79\) W (\(\approx 89.1\)%), on average.  EIR incurs a \(t_{capture}\) latency of \(31.46\) ms, state validation (\(\epsilon\)) of \(39.3\)ms, and fault localization \(t_{fault}\) of \(31.91\)ms. By contrast, the actual fault-recovery step \(t_{restore}\) that writes the corrected state back to the PL via PCAP completes in only \(5.7\)ms.

The \(t_{capture}\) and \(t_{fault}\) phases (\(\approx\) \(30\)–\(40\) ms) are dominated by conservative software implementation choices and PCAP bandwidth, and they are triggered only on rare fault events, leaving steady-state accelerator throughput unaffected. Our evaluation indicates that EIR can replace continuous hardware redundancy with an on-demand software recovery path while preserving a favorable overhead profile. The resulting downtime from fault detection to PL state recovery remains within only a few milliseconds, which is consistent with typical control-loop deadlines in edge-AI settings [56]–[58]. In general,  EIR is well-suited for resource-constrained FPGA SoCs in which brief recovery stalls are acceptable and eliminating continuous redundancy yields greater overall value.

4.3 Fault Coverage Across Dense Layer↩︎

Using the percentile-sweep procedure (see Sec. 3.2.4), we ranked the dense layer MAC operations by their absolute contribution magnitude \(|x\!\cdot\!w|\) and injected multiple bit flips per sampled MAC to measure the fraction of trials resulting in misclassification. The results show that outcome-altering faults are heavily concentrated in the highest-percentile MACs. The smallest top slice capturing all observed misclassifications corresponds to 30% of MACs in layer 6, \(\sim\)​17% in layer 7, and \(\sim\)​18% in layer 8. When aggregated across all dense layers, these findings indicate that auditing approximately 25% of dense-layer MACs—or only 5% of all network MACs—is sufficient to capture all observed misclassifications for the evaluated model under the adopted fault-injection campaign.

Guided by prior work [30]–[33], [35]–[37] and our LeNet-5 case study, we show that restricting comparisons to the dense/logit layers and auditing only the highest-magnitude MACs captures nearly all outcome-altering faults. Focusing on the edge AI workload, we show that by auditing the top \(30\%\) of neurons EIR provides sufficient fault coverage. Timing profile of dense layer from Table 2 shows that PL computes the entire layer in approximately \(43.54~\mu\)s, corresponding to about \(10.62\) ns per MAC operation. By contrast, Rabbit’s complete execution on PS processes takes about \(585~\mu\)s, or \(0.14~\mu\)s per MAC. Given the PL’s total layer time \(t_{\text{PL,layer}}\approx43.54~\mu\)s (the time for the PL to compute one dense layer) and the PS per-MAC latency \(t_{\text{PS,MAC}}\approx0.14~\mu\)s, the PS can recompute at most:

\[C_{\text{MAC}} \;=\; \frac{t_{\text{PL,layer}}}{t_{\text{PS,MAC}}} \;\approx\; \frac{43.54~\mu\text{s}}{0.14~\mu\text{s}/\text{MAC}} \;\approx\; 311~\text{MACs}\]
Where \(C_{\text{MAC}}\) denotes the number of MACs the PS can verify in-line while the PL completes the layer. This defines the real-time computational budget for in-line comparisons, showing that the PS can verify roughly \(7.6\)% of all \(4096\) MAC operations per layer. Therefore, selectively checking the most critical \(30\)% of neurons (those contributing the largest MAC magnitudes) remains both computationally feasible and sufficient for effective fault coverage. If the PS recomputed the entire dense layer, it would process \(4096-311=3785\) MACs that overlap (\(MAC_{\text{overlap}}\)) with PL execution and the corresponding PS verification time (\(t_{\text{PS,full}}\)) would be: \[t_{\text{PS,full}} \;=\; MAC_{\text{overlap}} \times t_{\text{PS,MAC}} \;=\; 3785 \times 0.14~\mu\text{s} \;\approx\; 530~\mu\text{s},\] Where \(t_{\text{PS,full}}\) is the PS time to verify the non-overlapping MACs. This implies a complete PS-side verification would stall PL operation for roughly \(0.53\) ms if isolation is required—undesirable for real-time edge inference with tight latency margins. To avoid such downtime, EIR employs an importance-aware selection policy that ranks dense-layer MAC operations by their contribution magnitude and verifies only the most influential subset. Let \(k\) denote the selected fraction (default \(k{=}0.30\) for \(30\%\)), \(N_{\text{sel}}\) the number of selected MACs, and \(t_{\text{PS,sel}}\) the PS time to verify them: \[\begin{align} N_{\text{sel}} &= k \times 4096 \;=\; 0.3 \times 4096 \;=\; 1228~\text{MACs},\\ t_{\text{PS,sel}} &= N_{\text{sel}} \times t_{\text{PS,MAC}} \;=\; 1228 \times 0.14~\mu\text{s} \;\approx\; 0.17~\text{ms}. \end{align}\] By auditing only the top \(30\%\) of MACs,  EIR reduces the PL isolation window from \(530~\mu\text{s}\) to \(170~\mu\text{s}\)–a nearly threefold improvement–while focusing validation precisely where computation errors are most likely to impact inference accuracy. We set \(k{=}30\%\) as the default selection threshold because it (i) aligns with magnitude-aware robustness improvements reported in prior work [37], (ii) matches the selective-protection coverage versus overhead trade-offs demonstrated in larger CNNs [33], and (iii) fits within the PS timing budget, allowing a \(\sim 0.17\) ms audit burst (as shown above).

These results should be viewed as workload-specific empirical findings from the evaluated LeNet-5-style dense-layer case study under the assumed multi-bit transient fault model. Accordingly, the \(30\)% threshold should not be treated as a universal value for other neural networks or accelerator designs. Instead, it shows that EIR can leverage measured fault sensitivity to reduce validation cost while maintaining high observed coverage in any representative edge-AI setting.

5 Discussions↩︎

We now discuss  EIR’s efficacy and outline steps for future work.

5.1 Limitations and Scope↩︎

EIR depends on three system-level assumptions: (i) The PS can provide sufficient slack to execute Rabbit at checkpoint boundaries without interfering with higher-priority software tasks. (ii) Fault events remain infrequent enough that Tortoise’s slower recovery path does not affect end-to-end performance. (iii) The target application can tolerate brief interruptions during fault detection and state restoration. These conditions hold for the evaluated prototype and, in turn, identify the class of FPGA SoC deployments for which EIR is most effective.

EIR currently provides empirical fault-detection and recovery coverage for the evaluated transient fault model, workloads, and checkpoint policy. Therefore, the observed coverage depends on the workload’s sensitivity to injected faults, checkpoint placement, and the portion of architectural state that Rabbit validates and Tortoise reconstructs. Extending EIR to dynamic workloads with time-varying fault sensitivity or adaptive execution graphs remains future work. However, the present evaluation demonstrates that hierarchical twins can deliver practical self-healing with modest overhead on FPGA SoCs.

EIR’s current implementation uses workload-specific sensitivity profiling (e.g., top \(30\)% of neurons as specified in Sec 3.2) to identify the subset of computations that Rabbit re-executes. Therefore, it presently provisions for neural networks that can leverage top-\(k\) checkpoint selection (where \(k\) represents the number of layers amenable to checkpoint boundaries). Networks with highly irregular control flow or dynamic execution graphs may require adaptive checkpoint placement algorithms, which is an area of ongoing research. Sec. 4.3 evaluates fault coverage on a dense layer as a representative, challenging edge-AI workload. Extending the same per-fault coverage analysis to other accelerators (e.g., SHA-256, AES-128, GEMM, attention layer, etc.) can be carried out analogously and is omitted due to space constraints. However, it does not alter the main conclusion. The benchmarks employed in our evaluation demonstrate that EIR generalizes across heterogeneous workloads and quantifies its area/power cost, while the dense layer stress-tests its fault detection and recovery.

5.2 Digital Twins for Fault Detection↩︎

Digital-twin systems are well established in manufacturing and energy domains but remain largely unexplored for hardware fault tolerance on FPGA SoCs [59]–[62]. Existing twins operate at coarse time scales (seconds to minutes) and assume abundant computing resources, whereas FPGA faults occur at nanosecond scales on resource-constrained edge platforms [63]. EIR addresses this gap by tailoring hierarchical digital twins to FPGA SoCs, enabling explicit speed–accuracy trade-offs and opportunistic PS execution without contending for PL resources.

The hierarchical twin design plays a central role in scalability because it avoids continuous invocation of the fine-grained twin. However, as system complexity increases, the cost gap between Rabbit’s coarse-grained validation and Tortoise’s replay-based recovery may grow. Under these conditions, selective activation, partial-state replay, and modular decomposition become increasingly important for preserving responsiveness without sacrificing recovery capability. Evaluating these tradeoffs on larger SoC platforms, therefore, remains a key direction for future work.

5.3 Conditions for Correct Recovery↩︎

In case of faults, correct restoration depends on deterministic replay from the most recent trusted checkpoint to the point of fault detection. EIR therefore assumes deterministic replay over bounded execution windows. EIR does not claim correctness in the presence of untracked nondeterminism, such as asynchronous software intervention, uncontrolled external input streams, or timing-dependent side effects outside the state replay/restoration window.

5.4 Safe Update and State Injection↩︎

EIR applies recovery updates only after the design enters a controlled quiescent state.  EIR halts system clock(s) only at safe synchronization points using a handshake mechanism⁶, thereby preserving the tick relationship among clock domains and preventing a ‘torn’ state. EIR’s mechanism also promotes completing in-flight transactions before recovery begins, thereby avoiding protocol violations and inconsistent states during partial reconfiguration.

To avoid collateral modification, EIR only changes the configuration bits associated with the target state elements identified by the offline state-to-frame mapping (see Sec  5.5). This implementation-specific mapping localizes each update to the relevant frame addresses and bit positions of the target state elements. Consequently, EIR does not modify unrelated LUT initialization bits or routing resources. During fault recovery, the injected update remains confined to the intended architectural state.

5.5 sec:Fault32Recovery32and32Restore-Path↩︎

EIR builds on the checkpoint-and-resume mechanism of [17] and repurposes it for fault recovery. Presently, EIR restores architectural state that satisfies three conditions: it is (i) observable in the deployed design, (ii) reproducible by Tortoise from the same RTL description used to generate the final bitstream, and (iii) writable through the implementation-specific restore path. This state includes flip-flops, pipeline registers, control registers, and other sequential elements as represented in Tortoise’s cycle-accurate model. Recovery, therefore, targets a state that is checkpoint-visible, replay-reproducible, and restorable through configuration updates.

The mapping from Tortoise-visible state to PL’s configuration frames—and vice versa—is derived offline for each finalized implementation from the logic location (*.ll) file. The *.ll file is produced during bitstream generation and contains the physical locations of context-relevant state-bearing elements, such as flip-flops, thereby identifying the configuration frames that hold their implemented state, enabling precise state extraction and restoration [17]. Because the mapping is derived from the finalized placed-and-routed design, it is bitstream-specific rather than synthesis-independent, as outlined in prior works [14], [17], [64]. It therefore remains valid only for a fixed implementation and must be regenerated whenever RTL logic, synthesis, placement and routing, or toolchain versions modify the implemented layout.

5.6 Scalability↩︎

EIR’s scalability is governed by the interaction between checkpoint spacing, accelerator complexity, and available PS resources. The cost of Rabbit scales with the fraction of computation selected for validation, while Tortoise’s recovery latency scales with checkpoint spacing and the structural complexity of the accelerator. As accelerator size increases, larger state and deeper pipelines may increase replay cost. However, this overhead remains bounded by checkpoint intervals rather than full re-execution. EIR is therefore best suited for providing fault tolerance in designs where chip area is limited—making full hardware copies, such as DMR/TMR, infeasible—and where fault events are infrequent, allowing for selective validation to capture high-impact errors without proportional increases in area and power overhead.

6 Conclusion↩︎

This work introduced EIR, a hierarchical digital-twin framework for self-healing FPGA SoCs in edge AI applications. By decoupling fast detection (coarse-grained Rabbit) from precise recovery (fine-grained Tortoise), EIR provides fault tolerance without the PL area and power overheads of DMR/TMR. Opportunistic twin invocation and checkpoint-driven recovery enable energy-efficient operation on resource-constrained devices. Experiments on an AMD/Xilinx Zynq-\(7000\) across multiple benchmarks demonstrate successful detection and correction of transient faults. Future work includes scaling EIR to larger accelerators, studying adaptive checkpoint placement under dynamic workloads, and developing more selective replay and recovery mechanisms to manage checkpoint size, twin latency, and PS utilization.

References↩︎