Reliability of LEON3 Processor’s Program Counter Against SEU, MBU, and SET Fault Injection

Abstract

This paper presents a comprehensive register transfer-level (RTL) fault injection study targeting the program counter (PC) of the LEON3 processor, a SPARC V8-compliant core widely used in safety-critical and radiation-prone embedded applications. Using the enhanced NETFI+ framework, over four million faults, including single-event upsets (SEUs), multiple-bit upsets (MBUs), and single-event transients (SETs), were systematically injected into the PC across all pipeline stages. The analysis reveals that early stages, particularly Fetch (FE), Decode (DE), Register Access (RA), and Execute (EX), are highly sensitive to SEU and MBU faults. The propagation of errors detected in the two early stages of the pipeline (FE and DE) is classified with an important percentage of halt execution and timeout traps. Intermediate stages, such as RA and EX, exhibited a higher incidence of silent data corruption and halt execution, while the Memory (ME) and Exception (XC) stages demonstrated greater resilience through fault masking. SET faults were mostly transient and masked, though they occasionally resulted in control flow anomalies. In addition to error classification, detailed trap and exception analysis was performed to characterize fault-induced failure mechanisms. The findings underscore the need for pipeline-stage-specific hardening strategies and highlight the value of simulation-based fault injection for early design validation in safety-critical embedded processors.

1. Introduction

As embedded systems become increasingly integrated into safety-critical domains, including automotive, aerospace, healthcare, and industrial automation, the need for reliable, resilient, and fault-tolerant designs has become more pressing than ever. These systems are often subject to stringent functional safety requirements, where even transient faults, such as those induced by radiation, can compromise system integrity and lead to potentially catastrophic failures [1].

To validate system robustness and uncover hidden vulnerabilities, fault injection (FI) has emerged as a widely adopted technique in both academia and industry [2,3,4]. Fault injection involves the deliberate insertion of faults into a system to evaluate its behavior and asses the effectiveness of error detection, correction, and recovery mechanisms. It plays a critical role in verifying fault tolerance, supporting early design validation, and ensuring compliance with safety standards, such as ISO 26262 [5,6,7] for functional safety and ISO/SAE 21434 [8] for cybersecurity in automotive systems.

Fault injection techniques can be implemented at various abstraction levels, namely system level, register transfer level (RTL), and gate or transistor level, each presenting specific trade-offs between accuracy, observability, simulation efficiency, and modeling complexity [9].

At the system level, faults are typically injected into high-level software or architectural models such as those developed in SystemC or transaction-level modeling (TLM) environments. These techniques enable the observation of error manifestations like memory corruption or control flow violations, at the application or functional level. System-level injection is particularly effective for evaluating the overall dependability of embedded systems and software-based fault tolerance mechanisms. For example, Miele et al. [10] proposed a framework for system-level FI capable of tracing task-level behavior and analyzing fault propagation across multiprocessor embedded platforms. However, such high-level approaches lack the granularity required to model fine-grained timing behavior or transient hardware faults, such as single-event transients (SETs), which originate from physical disturbances.

The RTL level offers a balanced compromise between simulation performance and fault modeling fidelity. At this level, faults are injected directly into flip-flops or internal signals at the register transfer level, enabling accurate modeling of bit-flips, transient glitches, and other low-level anomalies. This abstraction is ideal analyzing error propagation through combinational and sequential logic, making it particularly suitable for characterizing SETs and single-event upsets (SEUs). Moreover, RTL-level injection maintains manageable simulation complexity and scales efficiently for large randomized fault campaigns [11,12,13].

At the gate or transistor level, fault injection achieves the highest fidelity by simulating physical-level faults such as charge disturbances, stuck-at faults, or timing glitches within logic gates and interconnects. This level captures the electrical behavior and precise timing characteristics intricacies of hardware, making it essential for studying radiation-induced soft errors at the circuit level. However, these methods are computationally intensive and require detailed netlists and technology libraries, limiting their applicability for large-scale or higher-level fault analysis [11,14].

Fault injection techniques can be broadly categorized into two major types [15,16]: hardware-implemented fault injection (HwIFI) and software-implemented fault injection (SwIFI). As illustrated in Figure 1, HwIFI introduces faults directly into the physical hardware through methods such as pin-level manipulation [17], power supply disturbance [18,19], clock jitter [20], laser fault injection [21,22], and radiation testing using heavy-ion or neutron beams [23,24,25]. These techniques provide high-fidelity emulation of physical fault effects and are especially valuable for post-silicon validation or testing under realistic operational conditions. HwIFI is also crucial for certification and regulatory compliance, as it provides empirical evidence of a system’s resilience to physical fault stimuli [26].

In contrast, SwIFI, illustrated in Figure 2, introduces faults through simulation, binary instrumentation, application programming interface (API) modification, or code transformation. SwIFI is particularly advantageous during the early stage of design and verification due to its non-intrusive, cost-effective, and highly controllable nature. It enables repeatable experiments, supports automated fault campaigns, and provides detailed observability of system behavior under fault conditions [27].

This research specifically focuses on a subtype of SwIFI, simulation-based fault injection (SBFI), which is performed at the RTL level or above using simulators and virtual platforms [28,29]. SBFI offers precise control over fault parameters (e.g., type, location, and timing), and enables systematic evaluation of fault effects in complex digital architectures during the design and validation phases. Unlike hardware-based techniques, SBFI does not require a physical prototype, making it ideal for pre-silicon validation, architectural exploration, and design-for-reliability analysis.

Modern simulation platforms, such as ModelSim^® [30], SystemC [31,32], and QEMU [33], support high-resolution modeling of both hardware and software components. These platforms allow researchers to inject faults into critical sub-systems, such as the program counter, register files, and control logic, and to observe their effects across a wide range of operational scenarios. The ability to monitor internal signals and state transitions in real time makes these tools particularly powerful for analyzing error propagation and system-level impact.

Complementing simulation-based injection, error propagation analysis tools are essential for assessing how localized faults evolve and influence global system behavior. These tools trace the error’s trajectory from its origin point, (e.g., a flip-flop in a control unit), through successive logic stages and memory structures, identifying whether the fault is masked, corrected, or results in silent data corruption (SDC) or system failure. This level of insight is critical for identifying vulnerable components, guiding selective hardening, and improving fault isolation mechanisms [34,35].

A conceptually related technique to fault injection is fuzzing [36,37,38,39,40,41], also referred to as fuzz testing. This software testing approach involves providing unexpected or malformed inputs to a system in order to expose security vulnerabilities or unexpected behaviors. While both fuzzing and fault injection aim to evaluate system robustness, they differ in scope and abstraction level. Fuzzing typically operates at the input or application level and is widely used in software security testing, whereas fault injection targets internal hardware states or signals (e.g., flip-flops, registers) to emulate faults such as SEUs or MBUs. The complementary nature of these techniques makes them particularly valuable when assessing system dependability under both adversarial threats and environmental stressors.

Table 1. Comparison between fuzz testing and fault injection methodologies.

Feature	Fault Injection	Fuzzing
Goal	Evaluate system resilience to hardware/software faults	Discover software bugs and security vulnerabilities
Target level	Hardware/RTL level, firmware, or runtime state (registers, memory, control flow)	Application/Input interface (e.g., files, network, APIs)
Fault model	Bit flips, signal glitches, stuck-at faults, timing violations	Malformed or adversarial input data
Execution context	Instruction-level, micro-architectural, or gate-level	Application-level
Typical use	Reliability analysis, safety certification, system validation	Vulnerability discovery, penetration testing
Injection mechanism	Physical (laser, electromagnetic), clock glitching, voltage, or simulation	Input manipulation (e.g., random, mutation-based)
Automation & coverage	Moderate to high (in simulation), lower in physical tests	High (via feedback-driven fuzzing)
Detection focus	Silent data corruption, trap generation, control flow errors	Crashes, hangs, memory errors
Complementarity	Can inform fuzzing by revealing fault-induced execution paths	Can be combined with fault injection to test error propagation from hardware to software

summarizes the key characteristics of both methodologies.

In addition to fault injection itself, several complementary tools and techniques have been introduced in the literature to enhance the accuracy and efficiency of fault tolerance evaluation. These include model-based testing (MBT) tools [42], real-time operating system (RTOS) simulators and automotive safety integrity-level (ASIL) assessment frameworks [43,44], continuous integration (CI) pipelines integrated with fault injection frameworks [45], and trap and exception-logging mechanisms [46,47]. MBT tools enable early exploration of fault scenarios using formal models, while RTOS simulators and ASIL frameworks extend fault analysis to real-time and safety-critical domains. CI pipelines automate the execution of fault injection campaigns throughout development process, ensuring continuous validation. Trap and exception logging facilitates failure diagnosis by capturing runtime anomalies, thereby improving error handling and system robustness.

In this context, the present study employs the enhanced NETFI+ framework, an RTL simulation-based fault injection tool, to evaluate the error manifestation sensitivity of the PC in the standard LEON3 processor. While prior studies have extensively examined the fault tolerance of LEON3, limited attention has been devoted to the PC, despite its critical role in sequencing instruction execution and maintaining control flow. This research addresses that gap by conducting fault injection campaigns targeting the PC under three major soft error types: single-event upsets (SEUs), multiple-bit upsets (MBUs), and single-event transients (SETs). Faults are injected across six pipeline stages: FE, DE, RA, EX, ME, XC to assess their impact on system behavior. The write-back (WR) stage was excluded from the fault injection campaign due to its limited influence on control flow and overall system behavior. Through a combination of simulation-based fault injection, error classification and trap analysis, the study characterizes how failures in the PC disrupt instruction flow and trigger system-level exceptions.

The remainder of this paper is structured as follows. Section 2 provides a brief review of faults injection on LEON3 processor and its built-in fault tolerance features. Section 3 presents an architectural overview of the LEON3 integer unit, highlighting its pipeline structure and key control components. Section 4 describes the operational principles and capabilities of the NETFI+ fault injection framework used in this study. Section 5 outlines the benchmark and simulation setup employed for injecting SEU, MBU, and SET faults into PC registers. Section 6, Section 7 and Section 8 analyze the classification of fault effects, offering a comprehensive discussion, supported by statistical data, on system behavior under injected SEU, MBU, and SET faults, respectively. Section 9 compares the impact of the key findings with results from other studies, including discussion of the LEON3 fault-tolerant version. Finally, Section 10 concludes the paper and highlights directions for future research.

2. Fault Injection Studies and Fault Tolerance in LEON3

2.1. Fault Injection Techniques Applied to the LEON3 Processor

LEON3 is widely adopted processor in fault-tolerant embedded applications, a synthesizable 32-bit core developed by Aeroflex Gaisler^® and based on the SPARC-V8 architecture [48]. Designed for deployment in harsh environments, LEON3 can include built-in protection mechanisms, tailored to mitigate radiation-induced soft errors making it a preferred solution in space and aerospace systems [49]. Its open-source nature also allows for architectural customization, which is critical for meeting the stringent requirements of safety-critical applications.

Numerous studies have investigated the fault tolerance of the LEON3 single-core processor using fault injection techniques to evaluate its behavior under soft error conditions [50,51,52]. These efforts often focus on assessing the processor’s performance in real-time and mission-critical systems, validating its ability to maintain deterministic behavior under transient fault events. While multicore variants of LEON3 exist, fault injection in such systems introduces additional challenges, including inter-core communication, shared resource interference, and concurrency effects [36]. Common research approaches include injecting SEU and SET into various components of the processor to assess their vulnerability as well as developing error detection and correction schemes aimed at enhancing overall system reliability [53].

Memory structures, particularly SRAM and cache, are among the most affected components, which make them highly susceptible to radiation-induced soft errors due to their continuous role in data storage and retrieval. Previous work using virtual platform (ViP) modeling has shown that instruction memory is especially vulnerable, with instruction code frequently identified as a critical failure point [54]. Similarly, fault injection studies targeting the LEON3’s functional units have demonstrated that the IU is highly sensitive to transient faults including SEU and SET [55]. High-level fault injection targeting memory and register locations has been explored, although lower-level methods such as flip-flop-level injection, have proven to offer more accurate and realistic fault characterization [56].

A comprehensive SEU injection campaign conducted via FPGA-based emulation further emphasized the vulnerability of the LEON3’s SRAM, confirming that even single-bit errors in memory can compromise data integrity system-wide [57]. Building on this findings, emulation-based fault injection targeting cache memory revealed that all cache addresses are susceptible to SEUs, highlighting the need for robust error mitigation techniques within cache subsystems [58].

2.2. Overview of Built-In Fault Tolerance Mechanisms

LEON3 incorporates several architectural features aimed at ensuring high reliability, fault detection, and fault tolerance. The processor is available in two variants: a standard (non-hardened) version and a fault-tolerant (FT) version. Understanding the baseline and enhanced protection mechanisms is essential for correctly interpreting fault injection results. The LEON3-FT represents a radiation-hardened extension of the standard LEON3 core, designed to tolerate transient SEU errors through the implementation of multiple mitigation techniques that operate across different abstraction levels [59]:

• Triple modular redundancy (TMR): Selected critical flip-flops, particularly those associated with control flow, are implemented using TMR. A majority-voting mechanism masks single-bit upsets in these registers at runtime, thereby improving resilience against SEU-induced control flow disruptions [60,61].
• Error detection and correction (EDAC): On-chip EDAC mechanisms provide protection for embedded RAM structures, including the instruction cache (icache), data cache (dcache), and internal memory blocks. These components typically employ single-error correction and double-error detection (SEC/DED) codes to enable runtime correction of soft errors [62]. Pipeline registers and certain internal control buses are safeguarded using parity bits. Although parity protection does not support error correction, it facilitates the detection of single-bit faults and enables error recovery mechanisms to be triggered [63].
• Pipeline restart and resynchronization logic: To recover from detected transient errors, LEON3-FT includes mechanisms such as pipeline flushing, instruction replay, and trap redirection. These techniques allow the processor to recover gracefully without requiring a complete system reset [64].
• Forced cache miss and watchdog monitoring: To mitigate undetected errors in cache tags or lines, forced cache miss logic is used. Additionally, watchdog timers and bus monitoring logic are used to identify faults in peripheral interfaces or interconnects that might otherwise lead to system lockups [64].

In contrast, the standard LEON3 core does not include built-in error mitigation techniques by default, making it more suitable for performance-centric deployments or research studies focused on evaluating raw fault susceptibility.

3. Architectural Overview of the LEON3 Integer Unit

This study focuses on the single-core version of the LEON3 processor, which features a seven-stage in-order pipeline. It incorporates an integer unit (IU), a coprocessor interface, and an optional floating-point unit (FPU), providing flexibility to accommodate a wide range of computational demands. Figure 3 illustrates the bloc diagram of the IU. It is responsible for executing arithmetic and logical operations, performing memory address calculations, managing instruction flow control, maintaining the PC, and controlling the next program counter (nPC).

To enhance instruction-level parallelism and overall execution throughput, the LEON3 processor employs a seven-stage pipelined architecture [65]. Within this pipeline, the PC and nPC are central to sequencing instructions across all stages. At the beginning of each instruction cycle, the PC provides the address of the instruction to be fetched, while the nPC stores the address of the subsequent instruction. Rather than being propagated as a single physical register, the PC and nPC are instantiated as stage-local copies (or latched values) stored in flip-flops or pipeline registers specific to each pipeline stage. The stage-specific behavior can be summarized as follows:

–

FE stage fetches the instruction at the address stored in ‘fpc’, the local copy of the global PC;

–

DE stage decodes the instruction and computes potential branch or jump targets using ‘dpc’ and ‘dnpc’, which are local representations of the PC and the nPC;

–

RA may perform PC-relative address calculations, particularly for branch or trap-related instructions;

–

EX executes conditional logic that may change control flow, potentially updating ‘epc’/‘enpc’;

–

ME and WR do not typically modify the PC directly; however, faults in these stages can still corrupt status flags or trigger exceptions that result in control flow deviations.

When a fault is injected into a stage-local PC copy, several outcomes are possible:

1.

The corrupted value may propagate forward through subsequent stages, causing control flow divergence if not masked;

2.

It may trigger traps or exceptions, particularly if the corrupted PC causes misaligned instruction access or illegal operations;

3.

In rare cases, the faulty value may be overwritten or implicitly corrected if a later stage recomputes the control flow path.

It is important to note that the global PC register is physically updated only in the WR stage, and its value is derived from the PC/nPC values propagated from earlier pipeline stages. Therefore, even if the global PC itself is not directly corrupted, faults in intermediate stage copies can mislead the update logic or branching mechanism, leading to architectural state corruption or erroneous control flow.

The IU oversees overall processor control and manages two main classes of registers: general-purpose registers and control/status registers. The general-purpose register file comprises 32-bit ‘r’ registers, including eight global registers and a 24-register window structured into eight input, eight local, and eight output registers. This register windowing mechanism, a distinctive feature of the SPARC architecture, enables rapid and efficient context switching by minimizing memory accesses during function calls and interrupts. Rather than saving and restoring registers to memory, the processor simply shifts the window pointer to expose a new set of registers, thereby reducing overhead and latency associated with task or procedure transitions. The control and status register set of the IU includes several critical components:

• The processor state register (PSR), which monitors the processor’s operational state;
• The window invalid mask (WIM), used to manage register window availability;
• The trap base register (TBR), which defines trap vector base address;
• The multiply/divide register (Y);
• The program counters (PC and nPC).

4. The NETFI+ RTL Fault Injection Framework

The NETlist Fault Injection (NETFI) tool, introduced in [66,67], was developed to perform fault injection on the LEON3 processor using both simulation, and emulation environments. NETFI-2 is an updated version of the original tool, primarily applied to the MicroBlaze soft-core processor, and designed to maintain minimal hardware overhead compared to the original NETFI framework [68]. It extends the capabilities of its predecessor by enabling fault injection directly at the RTL-level for various fault types, including single-event upsets (SEUs), and single-event transients (SETs), thereby improving accuracy and utility in the evaluation of digital system reliability. NETFI+ [69] is an enhanced version of the NETFI-2 fault injection tools, extending their capabilities with improved RTL-level support, expanded fault models, and increased automation for fault injection campaigns.

Previous studies have primarily focused on arithmetic and control units, identifying the integer unit and multiplier as among the most vulnerable components of the LEON3 processor to radiation-induced soft errors such as SEU and MBU [70,71]. To assess fault tolerance with greater precision, the NETFI+ framework is introduced to simulate both transient and permanent faults at the netlist level, including in the program counter. Building on this foundation, the enhanced NETFI+ tool is employed in this study to perform RTL-level fault injection, focusing on SEUs, MBUs, and SETs.

The NETFI+ tool enables fault injection at the RTL level, supporting both simulation and FPGA-based emulation, enabling accurate fault injection into the processor’s netlist, targeting any functional block at any clock cycle. It allows for fault complain to be conducted in either randomized or exhaustive mode, enhancing flexibility and coverage. Figure 4 illustrates the NETFI+ workflow in the simulation context.

The process begins with the synthesis of the LEON3 core’s HDL description using Synplify© tools, which generates a gate-level netlist. This netlist is subsequently modified using the MODify NETlist (MODNET) tool [72], which inserts an additional control signal, ‘INJ’, into all flip-flops and selected combinational logic elements. This modification enables precise and controllable fault activation during simulation. For SEU and MBU injection, the ‘INJ’ signal is asserted to deliberately alter the contents of a targeted flip-flop, thereby emulating single-bit or multi-bit errors, respectively. In contrast, SETs are emulated by injecting a transient glitch, where the ‘INJ’ signal is asserted for one clock cycle along specific combinational logic paths. Unlike SEUs and MBUs, which result in persistent flip-flop value changes, SETs are modeled as short-duration signal disturbances that alter the transient behavior of logic propagation in the combinational domain.

To support this functionality, the Xilinx library was extended to recognize the ‘INJ’ control signal within the ModelSim^® simulation environment provided by Mentor Graphics^® [70]. Additionally, the testbench architecture was adapted to manage fault injection events and to enable the measurement of error rates. This setup facilitates the systematic evaluation of soft error effects and provides a robust platform for assessing fault tolerance mechanisms in RTL-level digital systems.

5. Reliability Assessment of the LEON3 Program Counter

5.1. Fault Injection Strategy for Program Counter Evaluation

Previous research has proposed fault injection methodologies to assess the vulnerability of processor subsystem components to soft errors. In particular, [71] introduced a technique targeting the program counter in ARM processors by manipulating load instructions that directly update the PC. Because these instructions govern control flow, the study highlighted their pronounced susceptibility to transient faults and their potential exploitation in control flow integrity attacks.

Building on this foundation, the present work extends error manifestation sensitivity analysis to the LEON3 single-core processor, with a specific focus on the program counter across its pipeline stages. We investigate the effects of SEU, MBU, and SET on the PC, evaluating its critical role in preserving control flow integrity under fault conditions. Fault injection is applied to the 30 most significant bits (MSBs) of the PC across six pipeline stages: FE, DE, RA, EX, ME, and XC, while excluding the WR stage. The two least significant bits (LSBs) are intentionally excluded from the fault injection campaigns for two primary reasons: (1) altering these bits often results in misaligned instruction addresses, which would deterministically trigger a trap and therefore offer limited insight into latent or silent fault behavior; and (2) modifying these bits at the HDL simulation level can lead to ModelSim runtime errors or unnecessary synthesis overhead, complicating the classification and analysis of error outcomes. Their exclusion therefore focuses the evaluation on non-trivial and analytically meaningful fault scenarios that better reflect real-world vulnerabilities in instruction flow.

In addition to the spatial distribution of faults across pipeline stages, the time distribution of injections was systematically controlled. For each selected pipeline stage, the fault was injected into the stage-local copy of the PC/nPC during the exact clock cycle in which that stage was actively processing an instruction. This ensured a direct temporal correlation between fault activation and the execution of the stage’s intended function, minimizing the risk of injecting faults into inactive or idle registers. Consequently, masking effects purely due to pipeline inactivity were avoided, and the observed masking rates primarily reflected architectural fault tolerance rather than timing misalignment.

For this study, the fault injection campaigns were conducted on the standard, non-fault-tolerant version of the LEON3 core, without built-in mitigation mechanisms such as TMR or ECC [51]. This configuration permits a more accurate assessment of raw fault susceptibility and provides a clearer view of error propagation pathways.

To carry out this analysis, we utilize the enhanced NETFI+ framework, which supports precise RTL-level injection of SEU, MBU, and SET faults. The tool modifies the flip-flops (FFs) associated with the PC in each of the selected pipeline stages (see Figure 3), with a total of 180 flip-flops instrumented for fault injection. In the case of MBUs, two adjacent flip-flops are corrupted simultaneously during a single clock cycle to emulate the concurrent inversion of multiple bits, thereby increasing the likelihood of control flow divergence. This two-bit corruption model serves as a representative approximation of real MBU effects, enabling repeatable fault campaigns while preserving relevance to physical fault scenarios, such as those caused by energetic particle strikes in radiation-rich environments.

5.2. Benchmark Description and Simulation Workflow

The fault injection campaigns are conducted using the MulMatrix benchmark, a 30 × 30 matrix multiplication workload, in which each element is represented as an 8-bit signed integer. This benchmark is selected for its short simulation time and high instruction redundancy, which together increase the likelihood of detecting fault-induced anomalies. The program utilizes char data types and performs nested loop iterations to simulate sequential instruction execution, arithmetic logic operations, and memory accesses. This controlled setup facilitates fine-grained observation of fault effects across the LEON3 pipeline stages and is particularly effective in revealing the behavior of the PC under various fault conditions.

The benchmark is written in C and compiled using the SPARC GCC cross-compiler, generating LEON3-compatible assembly code. Correctness evaluation is performed by comparing the output matrix to a golden reference result obtained under fault-free execution conditions. Faults are injected randomly during a single clock cycle, and the resulting system behavior is monitored to assess the fault sensitivity and robustness of the LEON3 PC under SEU, MBU, and SET scenarios.

This targeted analysis of the PC yields novel insights into one of the processor’s most critical control elements, providing a more detailed understanding of its vulnerability to soft errors. To the best of our knowledge, this study represents the first detailed RTL-level fault injection analysis of the LEON3 program counter using the NETFI+ framework. Figure 5 shows a waveform trace captured from the ModelSim^® simulation environment, illustrating the behavior of the system when SEU and MBU faults are injected into the ‘fpc’ register at the FE pipeline stage. The red circle marks the exact clock cycle at which the error is triggered.

6. SEU Fault Injection Campaign and Analysis

To assess the susceptibility of the LEON3 processor pipeline to SEU, a large-scale RTL fault injection campaign was conducted. A total of 1,080,000 SEU faults were injected using a uniform random distribution over the set of flip-flops associated with the PC across six pipeline stages: FE, DE, RA, EX, ME, and XC, explicitly excluding the WR stage. This exclusion is justified by the functional role of the WR stage, which primarily manages the final storage of computed results into the register file. Faults occurring at this stage are less likely to propagate backward or influence the control flow, and thus contribute minimally to errors in instruction sequencing. As such, the WR stage is considered less diagnostically relevant for evaluating control-related error sensitivity compared to earlier pipeline stages.

For each fault injection, the trigger event was randomly assigned to a specific clock cycle during the execution of the MulMatrix benchmark, emulating realistic, non-deterministic transient fault conditions. To enhance fault coverage and better represent the stochastic nature of soft errors, injections were distributed over multiple clock cycles, thereby increasing the likelihood of observing fault-induced anomalous behavior.

6.1. Pipeline Stage Sensitivity Analysis

To further investigate the failure mechanisms triggered by SEUs, a detailed trap analysis was conducted at each pipeline stage, as illustrated in Figure 6. The results revealed a distinct variation in sensitivity across the pipeline. Flip-flops in the FE and DE stages exhibited complete sensitivity, with every fault injection resulting in a deviation from normal processor behavior. The elevated vulnerability of the DE stage can be attributed to its critical role in decoding instructions and disseminating control signals to downstream stages. Faults in the PC during this stage may lead to immediate and severe misinterpretation of instruction flow, often resulting in the activation of trap conditions or execution of invalid operations in the subsequent cycle.

Similarly, the RA and EX stages showed high sensitivity, with more than 90% of injected faults leading to observable errors. While slightly less vulnerable than FE and DE, these stages are responsible for operand retrieval and instruction execution, making them prone to error propagation and control flow corruption. By contrast, the ME and XC stages displayed no observable fault sensitivity under the tested conditions. This apparent robustness may be due to architectural features that inherently limit error propagation in these stages, or it may reflect the diminished criticality of the PC during memory access and exception handling operations.

This stage-wise variation in response establishes an error sensitivity gradient, with early pipeline stages (FE and DE) identified as the most vulnerable, followed by moderate susceptibility in RA and EX, and negligible impact in ME and XC. These findings are critical for informing stage-specific error mitigation strategies, such as the deployment of hardened flip-flops, redundancy mechanisms, or error detection techniques in the most sensitive regions of the pipeline.

As depicted in Figure 6, RTL-level simulations also allowed for the classification of observed SEU-induced fault behaviors into three primary categories:

• Fault masking: In a subset of injections, the faults were either overwritten or did not affect execution, leaving the final outputs unchanged. Natural faults masking was observed in 6.7% of RA-stage injections, 3.3% of EX-stage injections and 100% in both EX- and ME-stage injections, suggesting some degree of inherent fault containment in the latter stages.
• Silent data corruption: A substantial portion of SEUs led to SDC, where incorrect outputs were produced while the system appeared to execute normally. This behavior was particularly prominent in the RA and EX stages, affecting 48.0% and 50.3% of fault cases, respectively. SDC is particularly dangerous in safety-critical applications due to its undetectable nature, potentially leading to mission-critical failures.
• Halt execution and timeout: In many cases, injected faults triggered severe disruptions, such as premature termination or simulation timeout (beyond the 4365 µs threshold), typically due to deadlocks or unhandled exceptions. This was the sole observed outcome for all SEU injections in the FE and DE stages (100%), and was recorded in 45.3% of RA-stage and 46.3% of EX-stage fault injection.

These results underscore the critical vulnerability of the FE and DE stages to catastrophic control flow failures, whereas the RA and EX stages are more susceptible to silent data corruption or partial masking. The ME and XC stages exhibited strong fault resilience, suggesting either intrinsic architectural robustness or a reduced functional dependency on the PC during these phases.

Comparable levels of system vulnerability have been reported in earlier studies employing SwIFI, particularly when targeting processor functional units and control flow components. For instance, Madeira et al. [73] demonstrated that SwIFI techniques can effectively emulate transient faults, revealing critical system vulnerabilities. Similarly, Carreira et al. [74] showed that faults injected into the PC and instruction flow logic can lead to significant error propagation and silent data corruption. These findings corroborate the high sensitivity of the PC observed in our RTL-level fault injection campaigns, thereby reinforcing the validity of our experimental results.

6.2. Trap Analysis and Error Propagation Insights

One of the primary advantages of performing fault injection at the RTL level is the ability to analyze system behavior with fine-grained precision. RTL simulations provide comprehensive observability of internal signals, pipeline registers and control logic, enabling accurate tracking of error propagation paths across the processor. Moreover, by correlating these low-level signal transitions with the assembly instruction trace, it becomes possible to identify how injected faults evolve into observable anomalies, such as trap conditions or system exceptions.

As summarized in

Table 2. Breakdown of trap types triggered by SEU injection per pipeline stage.

Type of Trap	Stages of Pipeline
	FE	DE	RA	EX
Illegal_instructions	50.79%	67%	52.04%	63.66%
Privileged_instructions	14%	2.99%	6.91%	10.03%
Window_overflow	-	-	34.34%	23%
Window_underflow	35.2%	30%	-	-

, a variety of trap events were triggered during the fault injection campaign. These events offer important diagnostic insights into the failure modes of the processor, and further emphasize the architectural sensitivity of the LEON3 core to transient faults in control flow components such as PC.

6.2.1. Illegal Instruction Trap

The illegal instruction trap emerged as the most frequently triggered exception during the fault injection campaign. This trap occurs when the processor attempts to execute an instruction that contains an undefined or unimplemented opcode. In the context of SEU and MBU faults targeting the PC, such faults may alter the instruction address, leading the processor to fetch from an unintended memory location. If the fetched address does not correspond to a valid opcode, then the processor attempts to decode an invalid instruction, thereby triggering an illegal instruction trap. It is important to emphasize that, under this fault model, the instruction memory itself remains unmodified; instead, the error originates from incorrect instruction addressing. For example, a fault that alters the PC to incorrectly point to a SAVE instruction address (e.g., save %sp, -0x0060, %sp (trapped)) may result in an illegal processor state during the DE stage, even if the instruction is syntactically correct, thus raising an exception due to semantic misinterpretation.

6.2.2. Privileged Instruction Trap

The privileged instruction trap is triggered when a non-privileged (user-mode) process attempts to execute an instruction that requires supervisor-mode privileges. In the context of fault injection, disruptions introduced at the FE occasionally impeded the proper incrementation of the PC increment, causing it to point to invalid or restricted memory regions. Consequently, the processor fetched an instruction address or contain malformed data. For instance, the corrupted instruction address ldub [%o4], %o5 [0x0000XXXX], may reference a protected memory region, thereby invoking a privileged instruction trap during exception.

6.2.3. Window Overflow Trap

The window overflow trap is a distinctive mechanism of the SPARC-based LEON3 architecture, which employs register windows to minimize memory access latency during procedure calls. A SAVE instruction initiates a register window switch by decrementing the current window pointer (CWP). If the updated CWP references a window marked as invalid in the window invalid mask (WIM), then a window overflow trap is triggered. In the faults injection experiments, errors affecting the CWP or its associated control logic, particularly in deep pipeline stages, were found observed to result in erroneous window pointer updates. These miscalculations led directly to the activation of the window overflow trap.

6.2.4. Window Underflow Trap

The window underflow trap occurs when a RESTORE or RETT instruction attempts to access a register window that is marked invalid in the WIM. In LEON3 architecture, the RESTORE instruction also functions as an arithmetic operation that modifies the CWP. Fault injection affecting the PC or pipeline control registers was observed to disrupt the restore logic, causing the CWP to reference an invalid register window. When the corresponding bit in WIM is set, a window underflow trap is triggered. These traps appeared sporadically, often following sequences of fault-induced pipeline misbehavior.

6.2.5. Summary of Trap Behavior

The occurrence of these trap types illustrates the diagnostic power of RTL-level fault injection. Each trap event reflects a specific class of failure, ranging from instruction corruption to control flow violations and architectural mismanagement of processor state. Table 2 summarizes the trap categories, their triggering conditions, and representative instruction traces observed during fault injection.

This analysis demonstrates that trap monitoring during RTL simulation not only aids in identifying fault-induced anomalies, but also reveals the architectural constraints and processor vulnerabilities that compromise system resilience. It provides critical insights to guide the development of error mitigation strategies, including instruction-level redundancy, hardened control logic, and trap-aware recovery mechanisms.

Compared to our prior study [69], which employed a high-level fault injection methodology, the results presented in this work exhibit greater precision in both error localization and propagation tracking. The trap and exception patterns observed in Table 2 notably exceed those reported in the earlier analysis, reflecting the enhanced sensitivity of RTL-level simulations in capturing microarchitectural vulnerabilities. Furthermore, the previous study’s exclusive focus on SEU limited the diversity of observable behaviors, whereas the current multi-fault campaign (SEU, MBU, SET) exposes a broader spectrum of failure mechanisms. This methodological evolution contributes to a more comprehensive assessment of PC reliability under radiation-induced fault scenarios.

7. MBU Fault Injection Campaign and Analysis

To assess the robustness of the LEON3 processor pipeline against MBU, a comprehensive RTL fault injection campaign was conducted. A total of 2,160,000 MBU faults events were injected with each consisting of two simultaneous bit flips introduced over multiple clock cycles. This setup emulates realistic fault scenarios encountered in radiation-intensive environments such as space mission, where MBU commonly arise from high-energy particle strikes [75,76,77].

7.1. Fault Impact and Error Rate Classification

The campaign evaluated the impact of MBU across all pipeline stages (FE, DE, RA, EX, ME, and XC) focusing on three primary failure modes: incorrect execution (Error), halted simulation (Stopped), and simulation timeout (Timeout). As illustrated in Figure 7, the FE, DE, RA, and EX stages exhibited a high frequency of critical failures, followed closely by the RA and EX stages. These findings confirm the heightened vulnerability of the early and mid-pipeline stages to multi-bit faults.

Figure 7 presents the classification of simulation outcomes into four distinct behavioral categories to better characterize the nature of MBU fault effects:

• Fault masking: A small percentage of MBU injections did not result in any functional error. For example, when an MBU was injected at the ME stage, corrupting two adjacent bits of the PC, the altered address still referenced a valid instruction within the same code block. Consequently, the processor continued execution without any observable malfunction, effectively masking the injected fault at runtime.
• Silent data corruption: SDCs were observed when the system completed execution but produced incorrect outputs. For instance, an MBU in the DE stage modified the PC value, causing the program to skip a loop iteration during matrix multiplication. As no exception was triggered, the output deviated from the reference without detection, silently compromising correctness.
• Simulation timeout: In certain cases, MBUs disrupted control flow or instruction decoding to such an extent that program termination was not achieved. A representative scenario involved an MBU in the EX stage, which redirected the PC to an address outside the valid instruction memory range. This fault caused the processor to enter an undefined loop, leading to non-termination and ultimately exceeding the maximum simulation duration.
• Halt execution: This was the most frequently observed failure mode. In one illustrative case, an MBU in the FE stage caused the PC to point to an invalid or non-executable address. As a result, the LEON3 processor triggered a trap, halting execution prematurely. This behavior demonstrates the role of the built-in exception mechanism in preserving system integrity under fault conditions.

7.2. Trap Analysis in MBU Fault Injection

The injection of MBU revealed distinct trap behaviors within the LEON3 processor, reflecting the diverse manifestations of fault-induced errors and their impact on system-level behavior.

Table 3. Breakdown of trap types triggered by MBU injection per pipeline stage.

Type of Trap	Stages of Pipeline
	FE	DE	RA	EX
Illegal_instructions	61.02%	67.69%	65.75%	1.83%
Privileged_instructions	25.22%	14.28%	6.85%	29.74%
Window_overflow	2.29%	13.06%	17.25%	58.51%
Window_underflow	1.83%	0.22%	-	-
Memory_address_misalignment	1.83%	0.22%	4.65%	0.92%
Fp_exception_traps	0.91%	0.22%	-	5.09%
Interrupting_traps	3.5%	1.51%	-	0.21%

provides a detailed classification of the trap types triggered during the MBU fault injection campaign, along with their corresponding fault conditions.

Consistent with the finding from the SEU fault injection campaign, the ME and XC stages exhibited no observable sensitivity to MBU faults. This apparent robustness is due to the limited number of critical flip-flops in these stages, or to architectural features, providing inherent redundancy or fault masking capabilities.

In contrast, RTL-level simulation results demonstrated heightened sensitivity in specific flip-flops associated with the PC register. Given the PC’s central role in managing instruction sequencing and control flow, even minor corruptions can rapidly propagate through the pipeline particularly affecting the FE, DE, and EX stages. These findings underscore the importance of incorporating hardened flip-flops or error detection mechanisms within the PC, related logic to strengthen the processor’s resilience against MBU-induced faults.

7.2.1. Memory Address Misalignment Trap

Among the newly observed traps during MBU injection were alignment-related exceptions. This trap is triggered when load or store instructions compute memory addresses that violate the alignment constraints defined by the SPARC architecture. Additionally, control flow instructions, such as jump and link (JMPL) or return from trap (RETT), may generate or rely on misaligned target addresses due to corrupted PC values, resulting in instruction fetch failures or illegal memory access. These traps represent fundamental violations of architectural memory access rules, and are typically managed by error containment mechanisms designed to prevent system instability.

7.2.2. Floating-Point (FP) Exception Trap

Triggered during the execution of floating-point operations (FPop), this trap arises from conditions such as incomplete hardware support, corrupted instruction operands, or transient disturbances in the execution path. In our experiments, although the MulMatrix benchmark uses 8-bit integer data, floating-point instructions can still appear in the execution stream due to corrupted PC values redirecting control flow to unintended code segments containing FP opcodes. When these instructions were fetched and decoded, the absence of valid operands or support logic under the given configuration triggered the FP exception. Errors in floating-point control logic or data paths can inhibit the successful execution of these operations, thereby initiating a trap condition and causing premature termination of the instruction.

7.2.3. Interrupt and Control Path Traps

These traps may result from either external interrupt requests or internal exceptions during instruction execution. In the context of fault injection, internal traps typically emerge in response to corrupted control signals or invalid processor states. Interruption traps indicate that faults have compromised critical control paths, prompting the processor to redirect execution to a trap handler. A representative case from the MBU fault injection campaign involved corruption of the register selection field during instruction decoding. For instance, an injected error modified the source register of a load signed byte (LDSB) instruction, replacing %r4 with an invalid register specifier. As a result, the processor triggered an ‘r_register_access’ trap due to illegal operand access. This example demonstrates how control path faults during the decode stage can result in immediate exception handling rather than undetected silent failures.

7.3. Comparative Analysis: SEU vs. MBU Effects

A comparative analysis using the NETFI+ fault injection framework shows that MBUs result in a higher incidence of system-level failures compared to SEUs. While SEUs typically affect a single bit and may lead to localized or recoverable errors, MBUs simultaneously corrupt multiple flip-flops, significantly amplifying error manifestation as faults propagate through the processor pipeline. This is particularly critical for components such as the PC, where even minor disruptions can cause control flow divergence or trap activation. The increased propagation depth associated with MBUs emphasizes the necessity for error mitigation strategies that address both single-bit and multi-bit fault scenarios, particularly in radiation-hardened and safety-critical embedded applications.

In summary, MBU-induced faults were observed to trigger a range of architectural traps including memory misalignment, floating-point exceptions, and interrupt-related faults, each indicative of specific classes of functional failure. Compared to SEUs, MBUs cause more severe and widespread disruptions, reinforcing their importance in the fault model for of radiation-tolerant system design. These results underscore the need to develop comprehensive fault tolerance mechanisms capable of mitigating the effects of both single- and multiple-bit errors, to ensure dependable operation in harsh environments.

8. SET Fault Injection Campaign and Analysis

Single-event transients are faults that primarily affect combinational logic. These transient signals, typically induced by radiation, can propagate through the circuit and disrupt normal system operation. The impact of an SET can resemble that of an SEU in terms of system-level consequences. However, unlike SEUs, which typically alter the state of flip-flops or memory cells, SETs originate within combinational paths and may propagate through logic within a single clock cycle. This fault injection campaign is potentially causing multiple simultaneous faults if latched at various points in the design.

This study investigates the SET sensitivity of the program counter in the LEON3 processor using the NETFI+ fault injection framework. A total of 1,080,000 SET faults were injected randomly into pipeline registers during a single clock cycle, emulating a brief pulse behavior characteristic of SET events. In contrast to SEUs, which are injected synchronously with the rising clock edge and may persist, SETs are inherently transient and may dissipate before producing any observable effects. However, this behavior depends on the timing characteristics and logical depth of the circuit.

8.1. Sensitivity and Error Manifestation Analysis

The results in Figure 8 indicate that SET-induced faults rarely led to observable effects, with the majority of injected faults naturally masked by the surrounding logic. Only a small subset of cases resulted in observable error manifestations, including silent data corruption, timeouts, or halted execution.

The observed error behaviors were classified into three primary categories:

• Fault masking: The majority of SET injections had no observable effects. For example, when a transient pulse was injected into the combinational logic driving the PC during the RA stage, the glitch either failed to reach a latch or was overwritten in the subsequent cycle. This allowed the processor to restore nominal behavior. This effect was particularly common in early pipeline stages, such as FE, where greater timing slack and shallower logic depth inherently suppressed transient propagation.
• Silent data corruption: In some cases, SETs introduced subtle control flow perturbations that were not detected during program execution. For instance, an SET affecting the PC computation logic in the DE stage caused the processor to skip a single instruction. The program completed normally, but the output matrix from the multiplication benchmark was incorrect. This kind of latent error is especially concerning in real-time or safety-critical systems.
• Halt execution and timeout: Although less frequent than in MBU scenarios, halted execution still occurred. In one example, a transient injected into the PC logic during the EX stage caused the processor to branch to an invalid memory address, triggering a trap and prematurely halting execution. This highlights the processor’s ability to detect some control flow anomalies, even those originating from transient events. In rare cases, SETs caused simulation timeouts. One notable instance involved an SET during the RA stage, which corrupted the PC and caused the processor to enter a non-terminating loop, thereby preventing the simulation from completing within the allotted time window. This indicates a serious disruption of sequential control.

8.2. Comparative Insights and Trap Analysis

As with SEU and MBU fault injection campaigns, several architectural traps were also triggered during the SET fault injection experiments. These included illegal instruction traps, interrupt exceptions, and privileged operation errors, each arising from corrupted instruction paths or compromised control signals. A detailed classification of the trap types and their triggering conditions is provided in

Table 4. Breakdown of trap types triggered by SET injection per pipeline stage.

Type of Trap	Stages of Pipeline
	FE	DE	RA	EX
Illegal_instructions	6%	6%	3.2%	-
Window_overflow	-	-	-	2.4%

.

Overall, the analysis demonstrates that while SETs exhibit a lower overall fault impact compared to SEUs and MBUs, they remain a non-negligible threat, particularly due to their ability to cause undetected silent errors or infrequent but critical execution halts. These findings reinforce the importance of temporal masking analysis, combinational logic hardening, and pipeline-aware error detection mechanisms to enhance system resilience against transient logic faults in radiation-exposed environments.

9. Cross-Fault Comparison and Discussion

In comparative terms, our experimental findings reinforce a consistent pattern observed in the literature: MBUs tend to cause more severe system-level consequences than SEUs. Specifically, MBUs affecting both the PC and related control registers, such as the processor state register (PSR) or trap base register (TBR), were more potentially to provoke anomalous trap handling, misrouted control signals, or incorrect return addresses. These results align with the study by Rao et al., who, through post-layout Monte Carlo simulations, demonstrated that transient events in combinational logic often lead to adjacent multiple-bit flips, with probabilities reaching up to 31% [78]. Moreover, broader investigations into embedded systems under fault injection and radiation exposure confirm that MBU-like errors result in higher rates of silent data corruption, exceptions, and control flow failures compared to isolated SEUs [79,80].

The LEON3 processor is also available in a fault-tolerant configuration (LEON3-FT), featuring hardware mechanisms such as TMR for critical flip-flops (including PC and nPC), ECC in memory subsystems, parity-protected buses, and on-chip logic for pipeline restart and forced cache misses. These mechanisms are designed to mitigate system failures caused by transient faults.

Previous radiation testing campaigns, such as those reported in [36,63], have shown that LEON3-FT implementations on radiation-hardened FPGAs. These implementations exhibit extremely low functional failure rates, often correcting thousands of SEUs autonomously without software-level intervention. In contrast, our experiments focus on the unprotected (non-FT) variant of the LEON3 core, where none of the aforementioned mitigation features are enabled. Under this baseline configuration, our fault injection campaigns revealed high vulnerability of the PC, with frequent illegal instruction traps, execution halts, and silent data corruption resulting from SEU, MBU, and SET injections. The lack of fault tolerance mechanisms in the non-FT variant used in our work explains the heightened sensitivity of the PC, and underscores the critical role of hardware-level protection in safeguarding control-critical components.

These findings highlight the trade-offs inherent in embedded system design: while enabling FT features significantly enhances reliability, it also incurs additional costs in terms of area, power consumption, and design complexity. Nevertheless, our investigation provides valuable insights into the intrinsic fault behavior of the PC and its propagation through pipeline stages. These insights are highly relevant for residual risk assessment, selective hardening strategies, or the development of lightweight systems that may not support full FT integration.

10. Conclusions and Future Work

This work presents a detailed RTL-level fault injection analysis of the LEON3 processor’s program counter, a critical control unit in SPARC-based embedded systems. Using the NETFI+ framework and a more complex MulMatrix benchmark, the study represents a significant advancement over our earlier work by expanding the analysis of PC fault sensitivity to include SEUs, MBUs, and SETs across all pipeline stages. While the previous study was limited to SEUs and TMR-based mitigation, the current analysis provides a deeper understanding of how diverse fault types propagate through the pipeline, affect control flow, and lead to traps or silent data corruption. The results demonstrate that the early and middle pipeline stages (Fetch, Decode, Register Access, and Execute) are highly susceptible to SEU and MBU faults, often resulting in control flow failures, while the Memory and Exception stages exhibited greater resilience. Although SETs were largely masked, they still posed a non-negligible risk of undetected errors in select scenarios.

One of the key advantages of software-based fault injection lies in its ability to trace the propagation of non-resilient faults throughout the system. This approach provides fine-grained visibility into how injected faults evolve over time and interact with the processor pipeline. In this study, SEUs in intermediate stages often caused undetected corruptions, whereas MBUs were more likely to trigger observable execution failures. Traps generated by early-stage faults further emphasize the sensitivity of instruction sequencing and control flow logic to soft errors.

By combining fault injection with trap and exception analysis, this study offers valuable insights into the mechanisms by which transient faults disrupt execution. The findings support the need for stage-specific mitigation strategies, particularly for the PC, which governs instruction flow and system state transitions. As a potential countermeasure, we propose the implementation of a selective dual-redundancy scheme for the PC, activated dynamically based on environmental risk assessment. This adaptive protection approach could balance performance and reliability, activating fault-tolerant logic only in high risk scenarios, such as radiation-prone deployments. We also plan to investigate how memory layout density and the position of corrupted PC bits influence the likelihood of trap activation versus SDC, providing deeper insight into system-level error observability.

Future research will aim to extend the fault injection methodology to hardware emulation platforms, such as FPGA-based test benches, and apply it to a broader range of real-time and mixed-criticality domains. This will further enhance the applicability of the approach to mission-critical domains. Examples include autonomous spacecraft navigation or automotive safety controllers, where resilience to soft errors is paramount. Additionally, in order to determine whether higher-order bit flips are more likely to induce critical control flow disruptions or trap activations. Future investigations may explore the correlation between the bit significance of SEU locations within the PC and the severity of resulting error manifestations.