Emulation-Based Analysis of Multiple Cell Upsets in LEON3 SDRAM: A Workload-Dependent Vulnerability Study

Abstract

The reliability of embedded processors in safety- and mission-critical domains is increasingly threatened by radiation-induced soft errors, particularly multiple-cell upsets (MCUs) that simultaneously corrupt adjacent cells in external SDRAM. While prior studies on the LEON3 processor have largely focused on single-event upsets (SEUs) in internal SRAM structures, they overlook MCU effects in off-chip SDRAM, a critical gap that limits fault coverage and compromises system-level reliability assessment in modern high-density embedded systems. This paper presents an SDRAM-based fault injection framework using FPGA emulation to evaluate the impact of MCUs on the LEON3 soft-core processor, with faults directly injected into the external memory subsystem where data corruptions can rapidly propagate into system-level failures. The methodology injects spatially correlated two-bit MCUs directly into SDRAM during realistic workload execution. Three architecturally diverse benchmarks were analyzed, each representing a distinct computational workload: a numerical (matrix multiplication), signal-processing (FFT), and a cryptographic (AES-128 encryption) application, chosen to capture arithmetic-intensive, iterative, and control-intensive execution profiles, respectively. The results reveal a distinct workload-dependent vulnerability profile. Matrix multiplication exhibited >99.99% fault activation, with outcomes overwhelmingly dominated by data store errors. FFT showed >97% activation in steady-state execution, following an initial phase sensitive to alignment and data access exceptions. AES displayed 88.12% non-propagating faults, primarily due to injections in inactive memory regions, but remained exposed to critical memory access violations and control-flow exceptions that enable fault-based cryptanalysis. These findings demonstrate that SEU-only models severely underestimate real-world MCU risks and underscore the necessity of selective, workload-aware fault-tolerance strategies: lightweight ECC for cryptographic data structures, alignment monitoring for signal processing, and algorithm-based fault tolerance (ABFT) for numerical kernels. This work provides actionable insights for hardening LEON3-based systems against emerging multi-bit threats in radiation-rich and adversarial environments.

1. Introduction

Fault emulation has emerged as a cornerstone methodology for evaluating the resilience of embedded processors to radiation-induced soft errors, offering a practical balance between the realism of hardware experiments and the scalability of simulation. Within this domain, FPGA-based emulation has become particularly powerful, enabling near-real-time injection of faults into synthesized designs while executing realistic workloads. Recent advances include Xilinx’s TMR SEM IP, which supports runtime fault injection and correction via dynamic partial reconfiguration [1,2,3,4,5], and ICAP/JTAG-based platforms that enable bit-accurate injection of multi-cell upsets (MCUs) without disrupting system execution [4,5,6,7]. These capabilities make FPGA emulation the method of choice for studying workload-dependent fault propagation in soft-core processors like LEON3.

Despite significant progress, a critical research gap persists in the characterization of MCUs affecting external SDRAM in FPGA-based embedded systems. Most prior LEON3 studies have concentrated on single event upsets (SEUs) and single event transients (SETs) within on-chip SRAM structures such as caches, register files, and tightly coupled memories [8,9,10,11,12,13,14,15,16,17,18,19,20,21,22]. However, external SDRAM, which typically stores program data, heap, and stack segments, has received little attention, even though its dense cell geometry and charge-sharing effects make it highly susceptible to spatially correlated multi-bit errors [23]. The lack of MCU-oriented investigations in SDRAM limits fault coverage and hinders the development of accurate reliability models for modern embedded processors.

The consequences of this gap are twofold. First, system-level reliability may be overestimated, as internal hardening mechanisms (e.g., TMR, ECC) do not protect off-chip memory [24]. Second, in cryptographic workloads, undetected SDRAM faults can enable fault-based attacks (e.g., differential fault analysis) that bypass traditional side-channel protections, yet SEU-centric models fail to capture these multi-bit threats.

To address this limitation, this work proposes a hardware-based MCU fault injection framework that directly targets the SDRAM subsystem of the LEON3 soft-core processor implemented on a Xilinx Virtex-5 FPGA. Unlike traditional SEU emulation, which perturbs individual bits in isolation, the proposed approach injects spatially correlated two-bit upsets across adjacent SDRAM cells, closely reflecting multi-bit failure patterns observed in radiation tests [25]. This design enhances fault realism and diversity, enabling the analysis of correlated error propagation paths and their impact on system behavior during runtime execution.

The study analyzes three architecturally distinct benchmarks to capture the workload-dependent nature of MCU effects:

−

Matrix multiplication (arithmetic- and memory-intensive),

−

FFT (iterative, alignment-sensitive signal processing), and

−

AES-128 (control-intensive, security-critical cryptographic kernel).

Together, these benchmarks cover numerical, signal-processing, and cryptographic domains, offering a comprehensive evaluation of MCU-induced fault behaviors under distinct operational profiles.

Experimental results reveal clear workload-dependent fault characteristics. Matrix multiplication exhibited nearly 100% data store errors with negligible masking, indicating direct vulnerability to memory corruption. FFT showed address alignment and data access exceptions during early injections, transitioning to store-dominated failures in later campaigns. AES demonstrated a high proportion of non-propagating faults (~88%), though a small fraction of unmasked faults triggered instruction and data access exceptions with potential security implications. These findings demonstrate that MCU-induced errors propagate differently across workload classes and emphasize the importance of selective, application-aware fault-tolerance strategies in embedded processor design.

The remainder of this paper is organized as follows. Section 2 reviews related work on fault injection methodologies and LEON3 reliability analyses. Section 3 details the proposed MCU fault injection framework and experimental setup. Section 4 presents and discusses the results of the emulation campaigns across the three benchmarks. Section 4 presents and analyzes the experimental results for MulMatrix, FFT, and AES benchmarks. It then provides a contextual comparison with prior SEU-centric studies and a detailed workload-based comparative analysis. Section 5 concludes with key findings, design implications, and future research directions.

2. Related Work

The LEON3 soft-core processor has become a widely adopted reference standard in aerospace and satellite systems owing to its modular design, open availability, and proven track record in space missions. LEON3 is highly susceptible to radiation-induced faults, which may compromise reliability under harsh environments. To address these challenges, numerous studies have investigated its vulnerability and mitigation through diverse fault injection (FI) methodologies.

Early simulation-based approaches include the work of Abbasitabar et al. [8], who analyzed error propagation in flip-flops, registers, register files, and L1/L2 caches of the LEON3 processor using VHDL simulation, and the work of Mansour and Velazco [9], who extended this analysis with a direct fault injection (DFI) method targeting register-level vulnerabilities. At a higher level of abstraction, SystemC-based transaction-level modeling has been adopted to accelerate fault injection campaigns using dynamic binary instrumentation (DBI) techniques. This approach enables faster evaluation of the system-level impacts of transient faults [10].

Several works have also explored hybrid fault-tolerant implementations. For instance, Lindoso et al. [11] combined single-error correction and double-error detection (SEC/DED), software validation, and configuration memory scrubbing in a LEON3 processor implemented on Artix-7 FPGAs, demonstrating enhanced resilience with modest overhead. Similarly, in our previous work [12,13], we performed an exhaustive SEU injection campaign into the SRAM of LEON3, providing detailed insights into workload sensitivity, error propagation mechanisms, and overall processor vulnerability, which informed the design of more robust mitigation techniques.

More recent studies have introduced sophisticated FI platforms and fault models. For example, Sari et al. [14,15] developed an open-source RapidSmith-based FI framework capable of injecting SEUs in configuration memory, while leveraging on-chip microcontrollers and performance counters to analyze fault effects. In a different context, Yuce et al. [16] analyzed pipeline-level vulnerabilities of a 7-stage LEON3 running AES on a Spartan-6 FPGA, demonstrating how FI attacks can compromise cryptographic applications. Similarly, Chekmarev et al. [17,18] proposed an IP-core based FI infrastructure integrated directly into system-on-chips (SoCs), simplifying the environment and enabling long autonomous campaigns on LEON3.

To address emerging fault models such as single-event multiple transients (SEMTs), Nethula et al. [19] proposed a formal framework using satisfiability modulo theories (SMT) to evaluate layout-aware SEMT vulnerabilities in a LEON3 ASIC core, reporting propagation probabilities of 30% for SEMT3 and 54% for SEMT4. On the other hand, Travessini et al. [20] used simulation-based fault injection into CPU registers, revealing that a small subset of registers accounts for the majority of critical failures, and showing that a partial TMR strategy covering only these registers achieved >99% SBU tolerance with marginal area overhead.

Complementing these works, Mannos et al. [21] developed a hardware-accelerated gate-level FI platform on Xilinx UltraScale boards, achieving a ~7200× speedup compared to simulation. Their study, focused on AES-128 execution on LEON3, uncovered 22 distinct faulty behaviors, including key and plaintext leakage through the serial port, with delay faults proving the most effective at inducing exploitable leakage. This underscores the importance of efficient FI platforms and highlights the security implications of subtle fault mechanisms.

Building further, our recent work [22] presented a comprehensive register transfer-level (RTL) FI campaign on the program counter (PC) of LEON3 using the enhanced NETFI+ framework. Over four million SEUs, multiple-bit upsets (MBUs), and single event transients (SETs) were systematically injected across all pipeline stages. The analysis revealed stage-dependent vulnerabilities: early stages (Fetch, Decode) were highly prone to halts and traps, intermediate stages (Register Access, Execute) produced more silent data corruptions, while later stages (Memory, Exception) benefited from fault masking. SETs were mostly transient but occasionally induced control-flow anomalies. This study highlighted the need for pipeline-stage-specific hardening strategies and demonstrated the diagnostic value of simulation-based FI for early design validation.

These works demonstrate the breadth of FI methodologies applied to LEON3, ranging from simulation-based and formal models to hardware-accelerated and attack-oriented platforms, providing both dependability insights and security assessments.

Table 1. Survey of fault injection approaches applied to the LEON3 processor.

Ref./Year	Methodology	Fault Model	Target	Main Findings
[8]/2012	VHDL simulation + FPGA emulation	SETs, SEUs, MBUs, METs	Flip-flops, Register file, Registers, Cache memories,	Characterized soft error propagation and masking in integer and multiplier unit.
[9]/2013	FPGA emulation campaigns	SEUs	Register-level units	Analyzed vulnerability of registers under SEUs
[10]/2015	Structural pipeline analysis combined with experimental biased FI attacks	Fault attacks modeled via biased fault injection	7-stage pipeline LEON3 (Spartan-6 FPGA)	Identified most vulnerable pipeline stages for AES; highlighted risks in cryptographic software
[11]/2017	Hybrid design (SEC/DED codes, hardware monitors, software validation, scrubbing) on Artix-7	SEUs + control-flow errors	Full LEON3 system	Demonstrated improved reliability with multi-layer mitigation
[12,13]/ 2018	Large-scale FPGA-based emulation (>200 k injections)	SEUs	Xilinx SRAM-based FPGA hosting LEON3 focuses SRAM memories	Provided detailed characterization of error propagation, workload sensitivity, and limits of detection mechanisms
[14,15]/ 2017	Open-source FI platform (RapidSmith) with on-chip microcontroller injects/monitors	SEUs injected at configuration bit/frame level	Xilinx SRAM-based FPGA hosting LEON3 focuses on configuration memory and per-component sensitivity	Estimates soft-error sensitivity per bit/frame
[16]/2015	Structural pipeline analysis combined with experimental biased FI attacks	DFIA + clock glitch	7-stage pipeline LEON3 (Spartan-6 FPGA)	Identified most vulnerable pipeline stages for AES; highlighted risks in cryptographic software
[17,18]/ 2015	Embedded IP-core fault injector inside SoC	SEUs	LEON3 in SoC	Simplifies fault injection setup; enables autonomous, long campaigns
[19]/2022	Formal SMT-based framework with layout-aware analysis	SEMTs (SEMT3, SEMT4)	LEON3 ASIC core	Estimated propagation probability. 30% (SEMT3), 54% (SEMT4); rigorous vulnerability assessment
[20]/2018	Simulation-script-based FI	SBUs	LEON3 CPU registers	Identified small set of highly vulnerable registers
[21]/2019	Gate-level FI using synthesizable saboteur + scan chain; hardware-accelerated on UltraScale FPGAs	Static faults (incl. delay faults)	LEON3 running AES-256	Identified 22 faulty behaviors incl. crypto/memory leakage; delay faults most effective; ~7200× faster than simulation
[22]/2025	Netlist fault injection based simulation	SEUs, MBUs, SETs	LEON3 Program Counter across pipeline stages	Early/middle stages (FE–EX) highly vulnerable; ME/XC resilient; SET mostly masked but risky.

summarizes fault injection methodologies and findings on the LEON3 processor.

While the studies summarized in Table 1 provide valuable insights into LEON3 fault tolerance, none address the combined impact of (i) multiple-cell upsets (MCUs), (ii) external SDRAM as the fault injection target, and (iii) diverse real-world workloads. Most prior efforts focus on single-bit faults (SEUs/SETs) in internal structures (registers, caches, configuration memory) and often use synthetic or single-application benchmarks. In contrast, this work is the first to emulate spatially correlated two-bit MCUs directly in the SDRAM subsystem of LEON3 under three architecturally distinct workloads (numerical, signal-processing, cryptographic), enabling a workload-dependent vulnerability analysis that reveals new fault manifestations (e.g., alignment traps in FFT, control-flow exceptions in AES) and quantifies the limitations of SEU-centric models for system-level reliability assessment.

The workload-dependent vulnerability patterns identified in this study stem primarily from SDRAM physics (cell density, charge sharing) and application memory access behavior, rather than LEON3-specific microarchitecture. Consequently, these findings are expected to generalize to other embedded soft-core processors, including RISC-V, ARM Cortex-R, and MicroBlaze, that similarly rely on external SDRAM for data-intensive workloads in safety-critical systems.

Beyond LEON3-specific studies, FI has been broadly employed as one of the most effective methodologies to evaluate the resilience of FPGA-based systems against transient and permanent faults. At the simulation level, netlist- and HDL-based tools (e.g., the frameworks of Fibich et al. and Monopoli et al.) introduce controlled perturbations into logic descriptions, enabling systematic analysis with detailed observability [26,27]. Higher-level platforms such as RASP-FIT automate design modifications to accelerate large-scale FI campaigns [28,29]. Hardware-based approaches, on the other hand, leverage physical disturbances including heavy-ion irradiation [30], laser beams [31], or voltage glitches [32], offering high fidelity at the cost of limited accessibility. In between these two extremes, FPGA-accelerated emulation methods, such as the approaches of López-Ongil et al. [33] and Entrena et al. [34], provide a practical compromise by injecting faults directly in hardware while executing realistic workloads, thus combining realism with scalability.

Within this framework, SRAM-based FPGAs have received particular attention due to their extreme sensitivity to radiation. The configuration memory, composed of millions of SRAM cells, controls all functional aspects of the device. Early emulation tools such as FLIPPER [35] enabled high-throughput SEU injection in configuration bits, while later frameworks like ACME [36] or ACME-2 [37] introduced selective injection targeting essential bits, reducing experimental overhead without sacrificing fault representativeness. The Xilinx soft error mitigation (SEM) IP [38] and ICAP-based approaches [4,5,6,7,8] further advanced this field by supporting runtime fault injection and correction, enabling non-intrusive experimentation. These developments have established FPGA-based emulation as a cost-effective and flexible alternative to beam testing [39,40]. A comprehensive tutorial about emulation-based fault injection platforms for SRAM-based FPGAs can be found in Ref. [41].

While most FI studies initially focused on single-bit upsets (SBUs), recent evidence from radiation tests shows that MCUs, where a single particle strike flips several adjacent bits, occur frequently in modern high-density technologies. This has motivated several MCU-aware fault injection strategies. For instance, Pérez-Celis et al. [25] reproduced realistic MCU spatial patterns observed in beam experiments, demonstrating significantly higher error rates than single-bit fault models. Other studies have proposed clustered injection strategies to emulate correlated upsets in configuration memory, while dual-circuit modeling has been employed to evaluate MCU effects in user memories such as register files and caches [42,43]. These contributions highlight the importance of extending fault injection beyond SEUs to accurately capture the impact of radiation-induced phenomena.

Despite this progress, relatively few studies have explicitly investigated MCU effects in the context of LEON3. Existing LEON3 fault injection campaigns have predominantly focused on SEUs and SETs, characterizing error propagation and evaluating mitigation techniques [44] such as TMR [45,46], ECC [47], and memory scrubbing [48]. However, the susceptibility of LEON3’s SDRAM memories, especially under spatially correlated MCU events, remains largely unexplored. Addressing this gap, the present work introduces an emulation-based MCU fault injection methodology for the LEON3 processor, combining dynamic modeling of two-bit upsets in adjacent SDRAM cells with benchmark-driven evaluation. This approach provides new insights into the resilience of LEON3 under realistic MCU scenarios and contributes to the broader understanding of fault tolerance in FPGA-based aerospace processors.

3. MCU Fault Injection Methodology on SDRAM LEON3

While SEUs assume isolated bit flips, modern high-density SDRAM is increasingly prone to spatially correlated MCUs due to technology scaling, charge sharing, and reduced critical charge [23,49]. Empirical beam testing by Pérez-Celis et al. [25] demonstrated that over 70% of radiation-induced memory errors in nanoscale devices involve exactly two adjacent bits, with multi-bit clusters dominating the error profile. By modeling spatially correlated two-bit upsets directly in external SDRAM, our methodology expands fault coverage beyond traditional SEU models, which fail to capture these realistic, correlated multi-bit disturbances that overwhelm conventional single-error correction codes [23,49].

3.1. The LEON3 Soft-Core Processor and Its SDRAM Subsystem as a Case Study

The LEON3 processor, developed by Cobham Gaisler^® as part of the GRLIB IP library, is a synthesizable 32-bit soft-core CPU implementing the SPARC V8 architecture. It is widely adopted in space, avionics, and other safety- and security-critical domains thanks to its configurability, open-source availability, and radiation-hardened implementations [50,51]. As a fully synthesizable design, the LEON3 can be mapped onto FPGAs, which makes it a suitable platform for emulation-based fault injection studies where accurate, real-time observation of fault effects is essential.

At the heart of LEON3’s architecture lies its memory hierarchy, which combines both on-chip SRAM-based storage and external memory components:

• Instruction and data caches, typically configurable between 1 KB and 64 KB, implemented using FPGA block RAMs (BRAMs). These accelerate memory access by storing recently used instructions and data.
• Register file, holding general-purpose and control registers, implemented as SRAM-based structures in FPGA realizations.
• Scratchpad or tightly coupled memories (TCMs), optional on-chip SRAM memories used for deterministic data access in real-time or safety-critical applications.
• External memory subsystem, managed by the LEON3 memory controller (MCTRL), which supports several memory devices such as SRAM, PROM, and SDRAM.

The MCTRL plays a crucial role in LEON3’s memory organization by mapping external memories into specific address regions, as illustrated in Figure 1. Its configuration enables flexible partitioning of system memory across chip-select (CS) regions. Of particular importance in this work is the main memory region (SDRAM mapped to CS0), which spans the address range 0x40000000 to 0x7FFFFFFF. This region typically hosts program data, heap, and stack segments during benchmark execution. As such, it contains the majority of runtime variables that are directly exposed to soft errors, including state arrays, intermediate matrices, and key data structures. The SDRAM represents the most fault-prone component due to its dynamic cell architecture, high density, and reduced critical charge in modern process technologies.

Due to technology scaling, SDRAM cells have become increasingly sensitive to radiation-induced effects such as SEUs and MCUs. While SEUs affect isolated bits, MCUs simultaneously flip multiple adjacent cells, an effect exacerbated by charge sharing and shrinking cell capacitance in nanometer-scale DRAM technologies. In FPGA-based LEON3 systems, this vulnerability is particularly critical: although on-chip SRAM structures (caches, scratchpads) benefit from spatial isolation and lower density, the external SDRAM remains exposed to high-probability multi-bit corruption events.

3.2. Benhchmark Selection

To capture the full spectrum of workload-dependent MCU vulnerability in embedded systems, three representative benchmarks were selected to fundamentally represent distinct computational archetypes commonly found in safety- and mission-critical applications:

• Matrix Multiplication (30 × 30 character-type matrices): an arithmetic- and memory-intensive workload that stresses sustained data movement and compute density. This benchmark is representative of numerical kernels in aerospace, scientific computing, and real-time control systems. In this benchmark, intermediate matrix elements are stored in SDRAM and repeatedly retrieved during computation, making the memory subsystem the dominant source of vulnerability.
• Fast Fourier Transform (FFT): a signal-processing workload characterized by iterative feedback, regular memory access patterns, and high sensitivity to address alignment. FFT is widely used in radar, communications, and sensor signal processing, where small perturbations can significantly alter output integrity. Even minor errors in intermediate results can propagate rapidly through the computation pipeline, making FFT an effective vehicle for exposing error propagation mechanisms.
• AES-128 encryption: a control-intensive, security-critical workload that stresses control logic, stateful round-based execution, and irregular memory access patterns through lookup tables (S-boxes). As a cryptographic standard in secure communications, AES is highly sensitive to data corruption, even single-bit errors in key schedule or state arrays can compromise correctness and enable fault-based attacks [52]. Both the key schedule and state arrays reside in SDRAM during execution, directly exposing security-critical data to memory faults.

This deliberate selection ensures that observed fault manifestations reflect generalizable vulnerability patterns across major embedded application domains, numerical, signal-processing, and cryptographic, rather than idiosyncrasies of a single algorithm [53,54]. The benchmarks are written in C and compiled using the SPARC GCC cross-compiler for LEON3, generating compatible executable applications.

3.3. Proposed MCU Fault Injection Methodology

This study introduces a dedicated fault injection framework specifically designed to emulate multiple-cell upsets in the SDRAM of the LEON3 soft-core processor. Figure 2 illustrates the experimental architecture, composed of the following key components:

• Host computer: defines and controls injection campaigns, manages benchmark execution, and collects output data.
• Fault injection controller (FIC): injects MCU events into specified SDRAM addresses according to configurable parameters (e.g., fault type, address range, fault location).
• Monitor/Checker module: tracks processor activity during execution to identify erroneous outputs, exceptions, or system stalls.
• Benchmark suite: numerical and cryptographic workloads running on the LEON3 to represent distinct application domains.

The setup is implemented on a Xilinx Virtex-5 FPGA (ML507), where the LEON3 core and its off-chip SDRAM act as the primary targets. All experiments were conducted on a hardware emulation platform based on a single Xilinx FPGA device, with the LEON3 hosted as the design under test (DUT). A host computer connected via a JTAG interface controlled the injections through the JTAG configuration manager (JCM), which handled FPGA configuration, fault activation, and monitoring.

The fault injection campaigns were performed under controlled conditions with the following parameters:

• Timing: Faults were injected during active benchmark execution, after the completion of the initialization phase and before final output generation, ensuring perturbations affect only the computational core of each workload. Injections occurred across multiple clock cycles to capture timing-dependent vulnerabilities.
• Spatial location: The data segment resides in the SDRAM address range 0x40000000–0x7FFFFFFF, where each address corresponds to a 128-bit memory size. Each SDRAM address was partitioned into four words. Within each 128-bit, one bit was flipped in the least significant bit (LSB) position of the first word and one bit in the LSB of the second adjacent word, emulating a spatially correlated two-bit MCU within the same physical memory access unit. This pattern was applied exhaustively across all valid data-segment addresses.
• Total injection events: The experiments comprised 661,870 injections for MulMatrix, 662,870 for FFT, and 661,888 for AES, ensuring comprehensive coverage of the active memory footprint under each workload.

The MCU injection mechanism operates through a two-stage scripting process. In the first stage, the memory layout is dynamically mapped during benchmark loading, with the runtime location of the data segment determined through allocation analysis. In the second stage, the injector flips one bit in each of two physically adjacent SDRAM cells, exhaustive emulating a two-bit upset.

As shown in Figure 3, each campaign follows a cycle of injection and evaluation: after a fault is injected, the benchmark resumes execution, and the ‘END INJ’ signal initiates post-injection analysis. Input vectors are applied, the resulting outputs are stored in text files and compared against expected results, and discrepancies are logged before the process advances to the next injection site. This iterative methodology enables a systematic and large-scale exploration of MCU-induced error behaviors under representative workloads.

In a limited number of campaign cases, the last event of the injected fault consistently forced the processor into a stopped mode, requiring manual reconfiguration of the FPGA to resume testing. This recurring behavior highlights a practical limitation of emulation-based fault injection, where halted states reduce throughput and complicate automation in large-scale campaigns. The described procedure is used to conduct the fault injection emulation experiments described in the next section.

4. Experimental Results and Analysis

4.1. MCU Fault Manifestations in MulMatrix Execution

This section presents the classification and analysis of MCU fault injection results obtained during the execution of the matrix multiplication benchmark (30 × 30 char type) on the LEON3 soft-core processor. Table 2 shows the fault injection results by executing the MulMatrix benchmark.

Result classification revealed that the LEON3 processor exhibits a pronounced vulnerability to MCUs in the SDRAM. Across all campaigns, only a single masked fault was observed, while the remainder produced visible system effects. This extremely low masking rate contrasts with typical SEU fault injection studies [13], where natural masking by application behavior or hardware redundancy often results in much higher tolerance.

Table 2. MulMatrix benchmark: fault injection results.

FI Campaign (Total FI: 661,870)	Masked Faults	Silent Faults	Data Store Errors	Stopped Mode
116,497 (Series 1)	0	0	116,496	1
53,058 (Series 2)	1	0	53,056	1
59,970 (Series 3)	1	0	59,968	1
116,364 (Series 4)	1	0	116,362	1
55,490 (Series 5)	1	0	55,488	1
116,362 (Series 6)	1	0	116,360	1
144,129 (Series 7)	1	0	144,128	0

Table 2. MulMatrix benchmark: fault injection results.

FI Campaign (Total FI: 661,870)	Masked Faults	Silent Faults	Data Store Errors	Stopped Mode
116,497 (Series 1)	0	0	116,496	1
53,058 (Series 2)	1	0	53,056	1
59,970 (Series 3)	1	0	59,968	1
116,364 (Series 4)	1	0	116,362	1
55,490 (Series 5)	1	0	55,488	1
116,362 (Series 6)	1	0	116,360	1
144,129 (Series 7)	1	0	144,128	0

The experimental campaigns revealed that data store errors overwhelmingly dominated the fault outcomes, representing nearly 99.99% of all observed failures. In the LEON3 architecture, such traps occur when the processor receives an AMBA error response for a memory location that is about to be accessed. Specifically, in this study, the failures correspond to the trap “IU in error mode (tt = 0x2B, data store error)”, which indicates a write buffer exception. This condition can arise during sub-word store operations that trigger a read–modify–write cycle, where the EDAC mechanism reports an error on the read phase [55,56]. The high concentration of store-related corruptions aligns with the characteristics of the executed benchmark, which is dominated by frequent and regular memory write operations. Consequently, corrupted data are rapidly propagated and amplified through subsequent arithmetic computations.

In contrast, stopped mode faults were consistently observed as the last injection for each series, reflecting either fatal control-flow corruption or unhandled traps. Similar limitations in handling halted states have been reported in our previous work [13], which emphasized the challenges of maintaining automated injection workflows on FPGA platforms without integrated reset mechanisms.

Overall, the results confirm that the LEON3 processor exhibits minimal resilience to MCU-induced faults when executing memory-bound workloads. The near absence of masked faults indicates that virtually all injected upsets propagate to observable failures. These results are consistent with earlier SEU studies on LEON3 and comparable architectures, which did not quantify the proportion of faults leading to system-level failures [13].

Table 3. MulMatrix benchmark: classification traps and faults by categories.

Fault Category	Description	Detection Mechanisms	Example Behavior	Observed Frequency
Data store error	Incorrect value written to memory, Write buffer error	ECC, parity	Corrupted data in memory	Predominant (>99.99% of faults in each series)
Stopped mode	Processor enters halted state	Watchdog, exception flags	System stops execution	Always present (1 per campaign, negligible)
Masked fault	Fault that does not affect program output	N/A	No visible effect	Always present (1 per campaign, negligible)

summarizes the observed fault categories, including:

−

data store errors (≈99.99% in each campaign);

−

stopped mode and masked faults (negligible for each type).

This distribution demonstrates the strong bias of MCU effects toward immediate, detectable corruption, with minimal opportunities for natural fault tolerance. Such outcomes reaffirm that while MCUs present a severe threat to system reliability, dedicated architectural and coding-level countermeasures can significantly enhance resilience in radiation-prone or safety-critical environments.

4.2. MCU Fault Manifestations in FFT Execution

This section presents the classification and analysis of MCU fault injection results obtained during the execution of the FFT benchmark on the LEON3 soft-core processor. The experimental outcomes are summarized in

Table 4. FFT benchmark: fault injection results.

FI Campaign (Total FI: 662,870)	Masked Faults	Silent Faults	Data Access Exception	Data Store Errors	Mem. Address Not Aligned	Stopped Mode
10,622 (Series 1)	146	3	1086	556	8830	1
66,818 (Series 2)	830	0	0	65,987	0	1
78,018 (Series 3)	2424	0	1	75,592	1	1
90,930 (Series 4)	830	0	0	90,099	0	1
87,490 (Series 5)	830	0	0	86,659	0	1
67,650 (Series 6)	830	0	0	66,819	0	1
67,778 (Series 7)	830	0	0	66,947	0	1
91,858 (Series 8)	830	0	0	91,027	0	1
74,434 (Series 9)	830	0	0	73,603	0	1
27,272 (Series 10)	830	0	0	25,441	0	0

, which details the distribution of fault manifestations and their impact on system behavior.

In the first campaign (series 1), the FFT benchmark exhibited a diverse fault profile. A relatively high number of masked faults (146 cases) and a few silent faults (3 cases) were observed, alongside substantial occurrences of data access exceptions (1086 cases). These exceptions, reported as “IU in error mode (tt = 0x09, data access exception)”, occur when the processor receives an AHB error response during load or store operations. If the corrupted word corresponds to the pipeline’s requested data, a trap is triggered; otherwise, the cache memory controller suppresses the valid bit without raising an exception [56]. In addition, a large number of unaligned memory access exceptions (8830 cases) were recorded, indicated by “IU in error mode (tt = 0x07, mem address not aligned)” [55]. These errors point to vulnerabilities in memory addressing consistency, attributed to MCU-induced disturbances in address registers. Their occurrence strongly depends on the timing of injections relative to pointer or index updates. Interestingly, these misalignment errors disappeared in later campaigns, suggesting that such events are highly sensitive to runtime conditions such as temporal coincidence and memory allocation patterns [56].

In subsequent campaigns (series 2–10), the fault behavior shifted dramatically, becoming dominated by data store errors, which consistently accounted for more than 97% of all injected faults (e.g., 90,099 in series 4 and 91,027 in series 8). Each campaign ultimately terminated in a stopped mode, requiring a manual reset of the emulation platform, thereby underscoring the disruptive impact of MCUs on sustained FFT execution.

Masked faults remained present in later campaigns, typically averaging around 830 per run (≈0.9–3.1% of injections, depending on campaign size). By contrast, silent faults, initially observed in the first campaign, did not reappear in subsequent runs. This suggests that once the FFT benchmark reached a steady-state execution, MCU effects were either detected through traps or manifested as store errors, with virtually no silent data corruptions escaping detection.

The overall distribution indicates that FFT, as a computation- and memory-intensive benchmark, is particularly sensitive to data corruption, where memory writes dominate the execution profile and propagate errors rapidly through the computation pipeline. The rarity of alignment and access exceptions beyond the first series suggests that these were more likely tied to initial memory setup and pointer handling rather than to the steady-state FFT benchmark itself.

Table 5. FFT benchmark: classification traps and faults by categories.

Fault Category	Description	Detection Mechanisms	Example Behavior	Observed Frequency
Data store error	Corruption during write operations to SDRAM, leading to inconsistent or invalid data values	Detected through execution mismatches and exception handling	Incorrect FFT output values, rapid propagation of numerical errors	Dominant (~93–99% of faults in Series 2–10; ~5% in Series 1)
Stopped mode	System halts due to unrecoverable error or watchdog trigger	Requires manual reset of FPGA platform	Emulation stopped execution cannot proceed	Always present (1 per campaign, negligible fraction)
Masked fault	Faults that do not alter program state or output	Inherent masking through algorithm redundancy or unused resources	Execution proceeds normally without errors	Low (~1–3% across campaigns)
Silent faults	Errors that propagate without detection	Not detected by hardware/software mechanisms	Incorrect results without triggering exceptions	Rare (only 3 cases, ~0.03% in Series 1)
Data access exceptions/misalignment memory	Invalid memory addressing due to MCU-induced corruption	Exception handlers in LEON3 pipeline	Addressing trap, memory misalignment	Significant in Series 1 (83% not aligned, 10% access), absent later

summarizes the observed fault categories and traps, including:

−

data store errors (~93–99% of faults in Series 2–10; ~5% in Series 1);

−

stopped mode faults, silent faults (negligible for each type);

−

masked faults (~1–3%) and;

−

misaligned memory/data access exception (83% misaligned, 10% access in Series 1).

This distribution confirms that MCU effects during FFT execution overwhelmingly manifest as data store corruptions, with only marginal contributions from masked or silent faults. The results underline the FFT benchmark’s susceptibility to memory-related disturbances.

4.3. MCU Fault Manifestations in AES Execution

To evaluate the resilience of the LEON3 processor against MCUs in security-critical workloads, fault injection campaigns were conducted during the execution of the AES-128 encryption algorithm. Because cryptographic routines are highly sensitive to even minor data corruptions, MCU-induced errors can lead to severe consequences, including incorrect ciphertext generation or, in adversarial contexts, side-channel vulnerabilities that expose secret keys. Thus, evaluating the LEON3 soft-core processor under AES execution provides critical insights into its fault tolerance in secure embedded applications.

The fault injection experiments were carried out using the same emulation-based platform as in the matrix multiplication benchmark, with the LEON3 soft-core processor running AES on an FPGA device. Faults were injected exhaustive into the processor’s SDRAM during AES execution, and system responses were classified according to their impact. Table 6 provides a breakdown of the fault injection results obtained while running the AES benchmark.

The analysis revealed that, unlike the matrix multiplication workload, the AES application exhibited a diverse set of fault manifestations. Data store errors remained the dominant category in the first series; their frequency was somewhat diminished (11.67%) compared to the high percentage (>97%) seen in FFT and matrix multiplication benchmarks. Although halted executions (i.e., “stopped mode”) occurred in only a small number of injections (one case in our campaign), they reflect the algorithm’s control-intensive nature: corrupted loop indices or state variables can disrupt AES’s round-based structure, preventing further progress.

Table 6. AES benchmark: fault injection results.

FI Campaign (Total FI: 661,888)	Masked Faults	Silent Faults	Illegal Instruction	Data Access Exception	Data Store Errors	Mem. Address Not Aligned	Instruction Access	Stopped Mode
83,139 (Series 1)	4561	82	1	1273	77,212	8	1	1
578,695 (Series 2)	578,695	0	0	0	0	0	0	0

Table 6. AES benchmark: fault injection results.

FI Campaign (Total FI: 661,888)	Masked Faults	Silent Faults	Illegal Instruction	Data Access Exception	Data Store Errors	Mem. Address Not Aligned	Instruction Access	Stopped Mode
83,139 (Series 1)	4561	82	1	1273	77,212	8	1	1
578,695 (Series 2)	578,695	0	0	0	0	0	0	0

In addition to the dominant store errors and halted executions, rare exceptions were observed during the campaigns. Instruction-related traps were recorded only once each, specifically instruction access and illegal instruction events. These anomalies are most likely attributable to MCU-induced corruption of control words or instruction fetch addresses, which subsequently result in invalid opcode decoding. The instruction access exception is reported as “IU in error mode (tt = 0x01, instruction access exception)”. This trap occurs when the processor receives an AHB error response while fetching instructions. In normal operation, if the error arises during a prefetch of an instruction that is not immediately required, the cache controller simply avoids setting the corresponding valid bit in the instruction cache tag. Should the IU later attempt to execute from that address, a cache miss forces a retry, thereby triggering the instruction access exception [55,56]. Illegal instructions, in contrast, were identified by the message “IU in error mode (tt = 0x02, illegal instruction)”, corresponding to the decoding of an invalid opcode.

Another category of faults consisted of data access exceptions, which accounted for approximately 0.2% of all experiments, with a slightly higher rate (1.53%) observed in the first injection campaign. While relatively infrequent, these faults can cause severe disruptions in program execution and, in the case of AES, compromise the correctness of cryptographic outputs. Notably, no such exceptions occurred during the matrix multiplication benchmark, reinforcing the observation that control-intensive workloads expose distinct vulnerability patterns compared to purely arithmetic ones.

A final, particularly rare class of errors involved unaligned memory access exceptions, occurring in approximately 0.01% of cases during the first injection series.

Interestingly, the AES campaign exhibited a high proportion of non-propagating faults (88.12%), compared to matrix multiplication (<0.001%). However, this apparent “masking” is largely attributable to faults injected in unused SDRAM regions or transient intermediate states that do not influence the final ciphertext, rather than intrinsic error resilience of the algorithm.

Overall, the AES workload highlights that MCU effects in cryptographic applications not only threaten functional correctness but also carry broader security implications. While the majority of observable outcomes were immediate and detectable (e.g., corrupted ciphertexts, halted execution, or processor exceptions), the near-absence of silent data corruptions does not guarantee safety. Although AES exhibited a high proportion of non-propagating faults under MCU injection, even a very small fraction of unmasked errors can have severe security implications. Transient memory corruptions in SDRAM, such as those observed in data store errors, may alter intermediate cryptographic states, including the round key or state matrix, leading to faulty ciphertexts. Such deviations enable fault-based cryptanalysis, notably differential fault analysis (DFA). As demonstrated by Piret and Quisquater [57], a single-byte fault injected during the final or penultimate round of AES-128 allows recovery of the full 128-bit secret key with only two faulted encryptions, reducing the effective security from 2¹²⁸ to approximately 2³² operations. This confirms that MCU-induced faults in external memory are not merely reliability concerns but constitute actionable vulnerabilities in security-critical applications. These results reinforce that MCU-aware fault modeling is essential when evaluating cryptographic processors like LEON3, as SEU-only injection campaigns significantly underestimate the risks posed by multi-bit upsets. Furthermore, they emphasize the necessity of combining robust multi-bit ECC mechanisms with architectural protections, such as temporal redundancy or instruction-level integrity checks, to ensure both reliability and security in MCU-prone environments.

Table 7. AES benchmark: classification traps and faults by categories.

Fault Category	Description	Detection Mechanisms	Example Behavior	Observed Frequency
Masked faults	Fault that does not affect program output	N/A	AES output remains correct; fault overwritten or unused memory	Overwhelmingly prevalent (100% of faults in Series 2)
Silent faults	Faults that occur without detection	N/A	Corrupted AES computation may produce incorrect cipher-text without errors	Extremely low (~0.01% of faults in Series 1)
Illegal instructions	Fault triggers in-valid opcode execution, UNIMP or other un-implemented instruction	CPU exception	Processor executes invalid instruction; may halt or trigger fault handler	Rare (only 1 case)
Data access exceptions	Memory access violation, Access error during load or store instruction	CPU exception, MMU	Program halts or triggers exception; AES execution interrupted	Very low (~2% of faults in Series 1)
Data store errors	Incorrect value written to memory, Write buffer error	ECC, parity	AES key or state corrupted; incorrect ciphertext generated	Predominant (~93% of faults in Series 1)
Memory address not aligned	Memory access to un-aligned address	CPU exception	Program halts due to misaligned memory access	Negligible (only 8 cases in Series 1)
Instruction access faults	Fault in instruction fetch, Error during instruction fetch	CPU exception, ECC	AES execution may halt or incorrect instructions executed	Rare (only 1 case)
Stopped mode	Processor halts completely	Watchdog, exception flags	AES execution stops entirely	Rare (only 1 case)

UNIMP: Unimplemented Instruction.

summarizes the observed fault categories, including:

−

data store errors (~12% of total faults; ~93% in Series 1);

−

masked faults (~88% of total faults; 100% in Series 2);

−

data access exception (~0.2%);

−

silent faults, illegal instructions, memory address not aligned, instruction access faults, and stopped mode (negligible for each type).

In our earlier study, SEU injections on LEON3 revealed a natural masking rate above 93%, with only about 5.19% of injected faults resulting in processor halt states [13]. The present results indicate that MCUs create a distinctly harsher fault profile: although the raw masking rate under MCUs (88.12%) appears comparable, it primarily reflects injections into non-critical memory regions, unlike the intrinsic masking observed under SEUs. Consequently, MCU-induced faults that do affect active data are far more likely to produce observable errors, revealing a harsher effective fault profile despite the high overall non-propagation rate. These results emphasize that evaluations limited to SEUs may underestimate the true vulnerability of cryptographic applications, underscoring the necessity of MCU-aware fault models when assessing the robustness of secure embedded processors.

4.4. Contextual Comparison with Prior SEU-Centric Studies

While a direct comparison under identical memory targets (i.e., SEU vs. MCU both in external SDRAM) was not feasible, as no prior work has injected SEUs into LEON3’s external SDRAM (see Table 1), our results can be contextualized against the closest available baselines: multiple SEU studies targeting internal SRAM structures under the same LEON3 configuration.

Abbasitabar et al. [8] and Mansour & Velazco [9] reported high masking rates in caches and registers due to architectural isolation. Our own SEU campaign [13] observed >93% masking in on-chip SRAM, with only ~7% of injections causing observable errors. Travessini et al. [20] found that partial TMR could achieve >99% tolerance in CPU registers, confirming strong inherent SEU resilience in internal units.

In stark contrast, our MCU injections in external SDRAM, a resource without ECC or redundancy, yield dramatically higher observable error rates:

−

<0.01% masking in MulMatrix (vs. >0.0099% in SRAM [13]),

−

~2% masking in FFT (vs. low detection ~0.259% in SRAM [13]),

−

88% non-propagating faults in AES, but only because injections occurred in inactive memory, faults in active regions caused security-critical exceptions absent in SEU models.

Furthermore, MCUs introduced new fault classes not observed under SEUs, such as alignment traps in FFT (from corrupted address registers), reflecting the spatial correlation of multi-bit upsets. Given that external SDRAM lacks the protections of internal SRAM, even a hypothetical SEU injection in SDRAM would shows also worse resilience similar to Ref. [13]. The fact that microcontrollers already cause almost total activation of faults confirms that multi-bit disturbances are a significant threat, analogous to single-bit errors in unhardened external memory.

Table 8. Contextual comparison of MCU (this work) vs. SEU study in LEON3 [13].

Workload	SEU in SRAM (Our Prior Work)	MCU in SDRAM (Our Work)
MulMatrix	>0.0099% masking	<0.01% masking
FFT	~0.259% masking	~2% masking; alignment traps emerge
AES	93.34% masking	88% non-propagating (inactive memory), but active faults enable DFA

summarizes this contextual comparison.

4.5. Comparative Analysis: MulMatrix, AES and FFT

Figure 4 presents a comparative visualization of the fault classification results for three benchmark applications: MulMatrix, FFT and AES-128 encryption. The bar chart summarizes the distribution of observed fault outcomes, offering an intuitive comparison of each benchmark’s vulnerability profile.

The experimental outcomes provide three main insights. First, the matrix multiplication benchmark on LEON3 was overwhelmingly dominated by data store errors (~99%), with halted states and masked events occurring only marginally. This indicates that memory-intensive numerical workloads are highly susceptible to direct corruption of stored data, offering minimal inherent resilience or masking. Second, the AES workload exhibited a markedly different fault distribution: approximately 88% of injected faults did not lead to observable errors. However, this apparent resilience is largely attributable to injections in non-active memory regions (e.g., unused SDRAM) or transient intermediate values that do not influence the final ciphertext, rather than intrinsic fault masking by the algorithm itself. Nevertheless, even a small fraction of unmasked errors in cryptographic workloads is critical, since they can compromise system security through fault-based attacks. Finally, the FFT benchmark revealed yet another fault profile: subsequent runs were almost entirely dominated by data store errors (>97%), accompanied by a consistent but small fraction of masked faults (~1–3%). This indicates that FFT, like matrix multiplication, is strongly memory-bound and thus highly sensitive to MCU-induced corruption, though with a slightly higher but still limited degree of masking.

These results emphasize the workload-specific impact of MCUs. Numerical applications such as matrix multiplication and FFT are dominated by catastrophic memory corruption, leaving little natural fault tolerance. In AES, many faults do not affect the output because they occur in inactive memory. However, the absence of true error masking means that even a single fault in critical data or control structures can compromise security. Consistent with earlier SEU-centric studies [8,13,22], our results further show that MCUs amplify reliability threats in memory-intensive computations and security vulnerabilities in cryptographic workloads. Consequently, protection strategies must be tailored to workload characteristics: lightweight redundancy may suffice for numerical workloads, whereas cryptographic and signal-processing workloads demand dedicated multi-bit error detection and correction mechanisms to safeguard both functional correctness and security in radiation-rich or adversarial environments.

5. Conclusions and Future Work

This work presents a comprehensive evaluation of the impact of multiple-cell upsets (MCUs) on the LEON3 soft-core processor, using emulation-based fault injection targeting its SDRAM subsystem during execution of three representative benchmarks: MulMatrix (numerical), FFT (signal processing), and AES (cryptographic). By classifying and analyzing the observed fault manifestations, the study provided new insights into the MCU-induced vulnerability of LEON3 and demonstrated the strong workload dependency of fault outcomes.

The results reveal clear distinctions across workloads. MulMatrix was highly sensitive to memory corruptions, with fault outcomes overwhelmingly dominated by data store errors and limited evidence of masking or recovery. FFT displayed yet another fault profile: early campaigns revealed a mix of data access exceptions, misaligned memory address traps, and silent faults, but as execution stabilized, the workload became dominated by data store errors (>98%) with only a small fraction of masked outcomes. This behavior reflects FFT’s iterative, memory-intensive nature, where injection timing and address alignment play a decisive role in determining fault visibility. AES, by contrast, exhibited a higher proportion of non-propagating faults, primarily because injections occurred in inactive memory regions; AES itself provides no intrinsic fault masking due to its avalanche effect. When faults did affect active data or control structures, they typically manifested as store errors or access exceptions, carrying critical security implications.

The contributions of this study are twofold. First, it shifts the focus from traditional SEU- and SET-based analyses toward MCU-specific fault injection, reflecting the growing importance of multi-cell disturbances in nanoscale SDRAM technologies. Second, it introduces a framework that combines FPGA-based emulation with fine-grained fault taxonomy, offering both the realism of hardware campaigns and the diagnostic precision required to assess resilience in embedded processors.

The analysis also points to practical directions for enhancing dependability. The classification of fault manifestations enables the design of selective fault mitigation strategies: lightweight ECC or parity can be prioritized for AES-critical memory regions, algorithm-based fault tolerance (ABFT) techniques may better protect numerical workloads like MulMatrix, while address-alignment checks or improved memory access monitoring could enhance FFT resilience. Furthermore, identifying workload-specific masking patterns provides opportunities to optimize reliability without incurring unnecessary performance or energy overheads.

This work delivers a novel methodology for evaluating MCU-induced effects on embedded processors and provides actionable insights for improving fault tolerance in LEON3-based systems. As future work, the fault model will be extended to include MBUs, representing a more realistic failure mode in advanced technology nodes. Expanding the benchmark suite to encompass broader application classes will further enable the exploration of adaptive resilience mechanisms, where protection strategies dynamically adjust to workload profiles. Such approaches hold strong potential to significantly enhance the reliability and efficiency of space- and safety-critical embedded systems.

While this study was conducted on a Xilinx Virtex-5 FPGA and a specific LEON3 configuration, representative of legacy space-grade systems, the observed workload-dependent vulnerability patterns are expected to scale to newer FPGA generations. Modern FPGAs (e.g., Xilinx UltraScale+, Intel Agilex) feature smaller feature sizes (<16 nm), higher integration density, and 3D stacking, all of which increase susceptibility to spatially correlated MCUs.