Douglas A Santos

Andr Pablo M Aviles
email: paviles@ing.uc3m.es.

M P Mattos

Mario García-Valderas

Luis Entrena
email: entrena@ing.uc3m.es.

Almudena Lindoso
email: alindoso@ing.uc3m.es.

Luigi Dilillo
email: luigi.dilillo@umontpellier.fr

A M P Mattos

Hybrid Hardening Approach for a Fault-Tolerant RISC-V System-on-Chip

Keywords: Checkpoint, Fault Tolerance, Neutron, Radiation, RISC-V, Rollback, Soft Error I

We propose fault tolerance strategies applied to a soft-core RISC-V-based System-on-Chip. Notably, we investigate the effectiveness of a multilayer hardening strategy, which combines software recoverability and hardware redundancy. As validation, a neutron irradiation campaign was performed

and roll-forward operations. In [START_REF] Marques | Lock-V: A heterogeneous fault tolerance architecture based on ARM and RISC-V[END_REF] the authors propose a heterogeneous fault-tolerant architecture based on Dual-Core Lockstep (DCLS) of different architectures. It combines two different processor architectures: a hardcore processor with ARM architecture and a softcore processor with RISC-V architecture. In both systems, the rollback mechanism is incorporated to deal with the occurrence of errors and mitigate failures by returning to an error-free state. Similarly, in [START_REF] Aviles | Radiation testing of a multiprocessor macrosynchronized lockstep architecture with FreeRTOS[END_REF], we presented another recovery technique aimed to be applied in SoCs, in which a high-end ARM multiprocessor hardened with a Macrosynchronized Lockstep (MSLS) was evaluated. The MSLS technique is based on detecting errors with a loosely-coupled lockstep architecture that triggers software rollbacks from execution context saved in safe memory.

In this work, we combined the recovery strategies explored in [START_REF] Aviles | Radiation testing of a multiprocessor macrosynchronized lockstep architecture with FreeRTOS[END_REF] with the SoC presented in [START_REF] Santos | Reliability analysis of a fault-tolerant risc-v system-on-chip[END_REF], [START_REF] Santos | Neutron irradiation testing and analysis of a fault-tolerant RISC-V system-on-chip[END_REF], as a joint effort to improve the SoC reliability. Therefore, we analyze the effectiveness of the key elements of the MSLS architecture implemented in a fault-tolerant RISC-V SoC. In order to best exploit the system characteristics, our main contribution in this work is to use the error reporting of the SoC to trigger the MSLS recovery operations. Since the SoC detects several types of radiation-induced events (e.g., upsets in registers, controlling logic errors) in its internal structures, the rollbacks can be triggered for these error events. Hence, an additional processing core for the lockstep approach is dismissed and the potential non-correctable errors detected by the SoC can be potentially recovered with the MSLS protection at the software level.

This paper is organized as follows. The recovery strategy used in the proposed approach is presented in Section II. Section III describes the implementation of the rollback operation in the fault-tolerant RISC-V processor. Section IV details the experiments that have been performed to validate this approach and presents the experimental results for the radiation test campaign. Finally, Section V summarizes the conclusions of this work.

II. RECOVERY STRATEGY

In this section, the most significant aspects related to the recovery strategy are presented. It is based on two distinct operations: checkpoint and rollback. They allow the processor to return to a previous state in the execution when an error is detected. Being able to restore the state implies the need of storing the current state, so that the system can access this information and use it when required in the restore process. This approach can lead to unsuccessful recoveries in some cases and must be combined with other strategies (e.g., software reset, watchdog timers), supporting harsh environment applications, in which abnormal behavior and hangs are frequently observed. In our scenario, the processor will be working in a harsh environment and exceptions can be triggered because of radiation-induced effects. Being able to correctly detect the exception by the system and to try to restore regular execution is mandatory.

To implement the proposed recovery strategy, we use context switching. Processor context can be defined as the relevant information that characterizes the processor state and it may include the content of the register file, control registers, cache memory, and others. Processors use the stack for context switching, so that they can easily switch to another context, and then return to the previous state by restoring the previously stored context. The stack is composed of several frames, and each application function has its unique frame to store its context. The start of the frame is pointed to by the Frame Pointer (FP) register, while the last element of the frame is pointed to by the Stack Pointer (SP) register.

A. Context Saving: Checkpoint

The checkpoint is the mechanism that performs the processor context saving in safe memory. The return of the processor to a previous point in the execution can be achieved successfully if at least the essential context information is stored. A better choice is to store in safe memory not only these values, but also local variables and some global variables defined as critical for the application execution. Since local variables are stored on the stack for context switching during function calls, as well as the register file, the stack can be used for checkpoint operation. The FP and SP special registers may be used as references for copying the program stack partially or totally. This allows getting a copy of all the local variables, or many of them belonging to specific program functions. On the other hand, for the storage of critical global variables, some additional strategies must be implemented. In general, we can decide how large is the data set we want to protect in our hardened system. It is important to consider that a large amount of data will increase recovery (checkpoint and rollback) and will decrease the whole system's performance. Only relevant data should be stored, and it is quite important to select the data we want to protect, which is application dependent.

Another important aspect is the granularity of checkpoints. The decision of how frequently the checkpoint is made affects the overhead in execution time and memory size. When checkpoints are made frequently, it implies a higher overhead but the gap to a functioning saved state is smaller. Checkpoints can be application-dependent, done after user-structured blocks of code, or they can be done periodically via interrupts to be more transparent and simple to be used.

B. Context Restoration: Rollback

The rollback is the operation performed when an error is detected and requires recovery handling. It restores the processor context to a previous state, that is, data that has been stored in the safe memory is restored to continue the execution from the last checkpoint. If this checkpoint was successfully saved and contains a valid context, the system can return execution from this error-free state. The validity of a context can be checked using a checksum method. Several consecutive rollbacks can be performed: if a rollback process is not able to restore the system, another rollback is called pointing to an older checkpoint. Several consecutive rollbacks could have the potential to restore a higher number of errors. A maximum number of consecutive rollbacks (rollback depth) must be set, depending on the amount of checkpoints established and available in our hardened system. When the rollback depth is reached, more severe actions should be performed.

III. IMPLEMENTATION

In this section, we detail the decisions and characteristics of our implementation based on the concepts introduced in section II.

The checkpoint operation was implemented through a periodic interrupt. When the interrupt is triggered, the context of the SoC is transferred to a safe memory. The context includes all the registers in the register file and the local variables of the application. For that purpose, we used BRAM memory blocks with SECDED protection. In order to add robustness, during the writing process to the BRAM, a Cyclic Redundancy Check of 32-bit words (CRC32) is performed. Hence, while these values are extracted from the BRAM during the rollback operation, the CRC32 verification is performed again, and the value obtained is compared with the one previously calculated and stored during the checkpoint process. If the values match, we proceed to restore the processor context to the last stored checkpoint. However, if the CRC32 values do not match, restoration to checkpoint N-1 will be attempted.

The rollback operation, like the checkpoints, is also performed using an interrupt service routine. The SoC has built-in error detection, which is reported through exceptions. When any internal structure is affected, the SoC outputs the error information and informs the system ability to correct it. Thus, we defined that the rollback operations must be performed only when uncorrectable or external errors are detected. For example, this is the case for a double-bit upset in a register or a configuration memory corruption, respectively. It is worth mentioning that, this error classification is determined by the corrections enabled in the SoC, and despite that, reporting is always enabled.

Additional reset protection has been implemented. This allows restarting the system in case of critical errors. If the rollback depth is reached without any successful rollback, then a soft reset is performed, and the FPGA is reprogrammed. For our experiments, we have used a rollback depth equal to three, as determined experimentally in [START_REF] Aviles | Radiation testing of a multiprocessor macrosynchronized lockstep architecture with FreeRTOS[END_REF]. Since abnormal behaviors and hangs must also be managed, a system Watchdog Timer (WDT) is used. The WDT is refreshed inside the checkpoint and rollback operations. Its value has been set to allow proper operation with a margin to accommodate execution time variations, but the value is configurable and can be tuned according to the application requirements.

IV. RESULTS

To evaluate the proposed system for radiation environments, we proceeded with an experimental approach, conducting an irradiation campaign in ChipIR beamline, part of the ISIS Neutron and Muon Source, at the Rutherford Appleton Laboratory, UK. The facility has a neutron spectrum representative of the atmospheric environment, generating up to 5×10 6 cm -2 s -1 for energies with E n >10 MeV [START_REF] Cazzaniga | First tests of a new facility for device-level, board-level and system-level neutron irradiation of microelectronics[END_REF]. In this work, the irradiation on the device reached an accumulated total fluence of 5.83×10 10 n/cm 2 at the end of the test campaign.

A. Experimental Setup

The experimental setup consisted of a Zybo Z7 development board containing a Xilinx Zynq-7010 All Programmable System-On-Chip (APSoC) device, with a dual-core ARM Cortex-A9 microprocessor and an SRAM-based FPGA. To host our SoC, we used the SRAM-based FPGA contained into the Zynq 7010 device. The board is accessed through serial interface for reporting results. Differently from the experiments performed in [START_REF] Santos | Neutron irradiation testing and analysis of a fault-tolerant RISC-V system-on-chip[END_REF] with the SoC focusing on flashbased FPGAs, the usage of an SRAM-based FPGA imposes characteristics that are at the same time beneficial and concerning for the experiment, i.e., with higher device sensitivity, more events are generated, hence additional preparation is required for a proper test. Notably, the configuration memory required additional protection and a nonvolatile memory for bitstream retention. Using an external flash available on the board, we prepared a procedure for self-reconfiguration of the bitstream from the flash to the configuration memory after a power cycle, improving the test flow and mitigating the impact of error accumulation. Also, the configuration memory itself was protected, using the FPGA's partial reconfiguration and scrubbing capabilities. Although, it is important to mention that the authors did not use the Soft Error Mitigation (SEM) core provided by the vendor, but implemented a customized solution using the device's internal blocks. This strategy was adopted to allow better integration and correlation between the device and the SoC error reporting, in which the SoC is aware of device errors and can actually trigger rollbacks depending on the hardening options.

In order to improve workload homogeneity, we used EEMBC's CoreMark™ [START_REF] Gal-On | Exploring CoreMark a benchmark maximizing simplicity and efficacy, Embedded Microprocessor Benchmark Consortium[END_REF] as the main stimuli for the processor execution. Designed for measuring the processors' performance in embedded applications, the benchmark is composed of four algorithms: list processing, matrix manipulation, state machines, and Cyclic Redundancy Check (CRC). The latest is used as a workload and provides a self-checking mechanism for the inner steps of the benchmark execution. CoreMark is split into several iterations and outputs a final summarizing score. The benchmark was executed throughout the experiment. A fully hardened design was used, in which all errors correctable by the SoC are handled and only the remaining errors trigger rollbacks, as a second layer of protection since it disturbs the execution flow.

B. Experimental Results

The irradiation campaign was very effective to stress the system and generate several radiation-induced faults. In total, the system was able to perform 162 runs, which are defined as the execution between external power cycles (independently of its case), i.e., from power on to power off. Each run may be composed of several inner executions split per watchdog or software resets, as part of the recovery strategies, whereas the external power cycles are triggered only when the system stops responding. For the recovery strategies, the systems performed 217 rollback attempts.

In order to evaluate the system's endurance, we performed a Mean Fluence To Failure (MFTF) analysis. This result allows seeing the endurance of the system under neutron irradiation with a very high fluence, in which we can extrapolate the result to the targeted environments. For that, we created three error categories: 1. CoreMark error, when the benchmark result has errors, but the system continues operational; 2. hangs, when the SoC stops responding (e.g., the processor in execution loop, serial interface issues); 3. FPGA failures, when a double bit upset in configuration memory is encountered or if a CRC error has been encountered, which had a higher potential to affect the execution. Subsequently, the failure category Processor Failure represents the joined results for Hang and Coremark Error, which are failures within the SoC; and All, combining the failures from the SoC and FPGA. Even though FPGA failures are not part of the SoC reliability, we included them to show their impact on the SoC. Table I presents the MFTF results. Also, we defined two applications to provide specific estimations for Mean Time To Failure (MTTF) based on their target environments considering all failure types: terrestrial, with reference to New York sea level, and avionics, at a typical cruising altitude of 10 Km. For the first environment, the expected MTTF is about 7335 years. For the second, it is estimated in 24 years. These results give a good margin for the operation of most commercial systems.

Regarding the implemented recovery strategies, in Table II, we focus on the rollbacks and their effectiveness. The rollback types were defined as follows: 1. effective, when the system resumes normal execution with subsequent checkpoints, and could be at first attempt or after two or three (which is the rollback depth) consecutive rollbacks; 2. failed, when the rollback did not have an effect. The failed attempt category includes the rollbacks failed at first, second and third attempt, as well as executions terminated before a single checkpoint was set and, consequently, a software reset was performed.

The results demonstrate the positive impact of the rollback operation in the hardening approach. The rollback was effective in 45.09 % of cases considering all the cases when a rollback was needed, and the 44.51 % was achieved in the first attempt. The rollback failed in 54.91 % of the cases, which implies that a software reset was needed. If the error occurs before having a checkpoint available, it is also inevitable to perform a software reset. Only in 9.25 % of the cases this was necessary. We should highlight that, although performing a software reset is a severe action, it is an effective method to recover the system. With these results, we could also corroborate the assumption that having multiple rollback levels could enhance recoverability, but more than the defined rollback depth, no significant improvements are obtained.

V. CONCLUSION

In this work, we proposed and evaluated a hybrid approach for the radiation hardening of a RISC-V SoC by combining software and hardware strategies. A recovery strategy based on checkpoint and rollback operations was implemented. The results show the effectiveness of the proposed approach, achieving a 45.09 % of effective rollbacks. Also, using a custom configuration memory protection strategy, the authors improved fault awareness at SoC level, reduced FPGA resource utilization, and avoided the use of additional communication interfaces for reporting. In future work, we envision extending the recovery coverage by efficiently saving other aspects of the execution context and exploiting opportunities in other software domains, such as operating systems.

Failure Reason MFTF [n/cm²] Cross-section [cm²/device]

		TABLE I
	MFTF SUMMARY BY FAILURE TYPE
	Hang	1.01E+09	5.49E-10
	Coremark Error	1.46E+08	1.37E-10
	FPGA failure	2.04E+08	2.09E-09
	Processor failure	8.35E+08	6.86E-10
	All	3.60E+08	2.78E-09

This study has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement no. 101008126.

The author would like to acknowledge the support from the irradiation facility personnel, notably Carlo Cazzaniga and Maria Kastriotou. Also,


M P Mattos

Douglas A Santos

Viyas Gupta

Thomas Borel

Luigi Dilillo

Investigation on Radiation-Induced Single-Event Latch-up in SRAM Memories on-Board PROBA-V

Keywords: SRAM, Radiation, Single-Event Effects, Flight Data, Memory, Heavy ions, Protons

This work is a study on Single-Event Latch-up on an SRAM memory used in the PROBA-V mission. We investigate and draw hypotheses about the behavior observed in the mission by comparing the experimental results with the in-flight data.

I. INTRODUCTION

Being a type of Single-Event Effect (SEE), Single-Event Latch-up (SEL) is a phenomenon that affects electronic devices, notably memories, in the space environment [START_REF] Adams | A verified proton induced latch-up in space (CMOS SRAM)[END_REF]. This event occurs when an ionizing particle affects a region of the transistor that results in a parasitic current, causing the current consumption of a device to significantly increase and potentially leading to a critical failure of the system [START_REF] Bruguier | Single particle-induced latchup[END_REF], [START_REF] Schrimpf | Radiation effects and soft errors in integrated circuits and electronic devices[END_REF].

The PROBA-V satellite [START_REF] Francois | The PROBA-V mission: the space segment[END_REF], Project for On-Board Autonomy, with V standing for vegetation, introduced a miniaturized version of the VEGETATION instruments, which were specially designed to track the vegetation's evolution and its links to climate changes from the SPOT 4 and 5 satellites. PROBA-V was launched in May 2013 on a low Earth heliocentric orbit at an altitude of 820 km, and its main mission ended in June 2020. Regardless, PROBA-V is still in operation, continuing its vegetation monitoring activity in a more experimental manner. The PROBA-V mission included Static Random-Access Memory (SRAM) memories that presented unexpected behavior during the mission, in which different error rates were observed throughout the mission duration.

This paper investigates the in-flight behavior observed for these SRAM devices, mainly targeting SELs, as part of a broader SEEs study. For this purpose, we performed two experiments in irradiation facilities representative of space environments [START_REF] Ferlet-Cavrois | Essentials for electronics in the space radiation environment -test methods and facilities[END_REF]: protons and heavy ions. The results are compared with the flight data acquired by PROBA-V, providing an insightful discussion and allowing initial hypotheses.

The remainder of the paper is organized as follows. Section II introduces the SEL fault mechanism and the observed behavior of the SRAM devices in flight. Section III details the proposed methodology to investigate this behavior. Section IV presents the experimental results and the flight data. Then, Section V discusses the obtained results and elaborates on the hypotheses. Section VI concludes the paper.

II. BACKGROUND

This section briefly introduces the latch-up phenomenon in SRAM memories and details the behavior observed in these memories during the PROBA-V mission.

A. Latch-ups in SRAM Memories

An SRAM cell is generally composed of six transistors implemented in CMOS technology. Each cell stores a bit since it has two stable states that denote high and low logical levels. The CMOS technology is susceptible to latch-ups due to a structure known as a thyristor, which nominally is in a high-impedance state. The SEL, a radiation-induced latch-up, occurs when this parasitic structure is affected by an ionizing particle interaction. In this event, the thyristor can enter a conducting state, generating a high-current state in the cell [START_REF] Bruguier | Single particle-induced latchup[END_REF], [START_REF] Schrimpf | Radiation effects and soft errors in integrated circuits and electronic devices[END_REF], with consequent cell content loss. However, if a power cycle is quickly performed, this high-current state is suppressed, and the device may restore its nominal operation (besides the loss of data). When this occurs, the event is defined as a non-destructive SEL, in which permanent damage in the cell due to thermal runaway is avoided.

B. In-Flight SRAM Behavior and DUT Description

PROBA-V mission uses Commercial Off-The-Shelf (COTS) memories from Samsung with the part number K6R4016V1D-TI10: a 4Mib SRAM with a 16-bit parallel interface (from Rev. D). The memories used in this work are from two distinct manufacturing lots, including those from the same lot as the devices on-board PROBA-V for better phenomena correlation. In PROBA-V, these memories are located on the Mass Memory Unit (MMU) board of the Advanced Data and Power Management System (ADPMS). They are used as buffers to store the payload data on the mass memories of the satellite. There are two MMU lines in cold redundancy, each having two SRAM memories. When an event requiring a power cycle occurs, such as an SEL, an automatic procedure was defined to switch between the redundant lines, i.e., data is transferred to the redundant line, which stores it for a brief period, allowing the primary line to be power cycled, and then the data is restored from the redundant line. This procedure takes about 3 to 4 minutes to complete.

Each memory has Error Correcting Code (ECC) protection that is also used to report the events. They are then classified into two main types of event flags that are reported as part of the satellite housekeeping telemetry: type 406, correlated with ECC failure (uncorrectable errors); and type 369, when more than 1000 single ECC upsets are detected but the memory remains fully operational. When an error occurs related to a particular flag type, all these events are also timestamped. During the mission, many errors classified as type 406 were detected, possibly indicating radiation-induced latch-ups. This assumption was made during the initial phases of the satellite when current information on these memories was available, and an important correlation was seen between SEL and ECC failures. It is worth mentioning that these devices were experimentally characterized prior to the mission, but the provided information gave insufficient insights to understand the flight behavior, which will be discussed in Section IV.

III. METHODOLOGY

The methodology in this work is based on performing experimental irradiation campaigns to evaluate the SRAM memories and compare them with the observed flight behavior.

A. Flight Data Estimations

In order to analyze the log file of all events related to the SRAM memories, we used the Scilab open-source environment. Also, the CelestLab toolbox for Scilab was used to propagate the orbit, perform some mission-related calculations, and plot specific graphs. Regarding estimations for the radiation environment of PROBA-V, we used OMERE tool version 5.3. It was assumed that with protons above 20 MeV, a proton particle is likely to hit the SRAM memories since their penetration in aluminum is approximately 2.1 mm. Hence, our calculations accounted for trapped and solar proton contributions for energies above 20 MeV. Based on this environment, simplified South Atlantic Anomaly (SAA) and polar regions were defined for the analysis.

Using the CelestLab toolbox, the PROBA-V orbit was propagated and the average duration passing through the defined regions, as well as the orbital period, were estimated. The results show an orbital period of around 101 minutes, with approximately 10 and 22 minutes over SSA and polar regions, respectively. The algorithm step used for the propagation was 120 seconds and the orbit was propagated from 8th May 2013 until 18th March 2020. This calculated duration was then used to estimate the average error rates.

B. Experimental Setup

We performed experiments in two facilities with different particles: heavy ions and protons. The experimental setup was reused for the facilities, with minor adaptations. It consisted of a controlling board, hosting an FPGA, and a test board, where the SRAM and measuring components were included. To allow handling current variations, we included power switches that were disabled just at 50 ms (hold time) after an SEL event, allowing monitoring of the initial behavior under SEL and protecting the circuit from unrecoverable damage, and enabled again after 200 ms (cut time) to continue the test execution. The data acquisition, handled by the controller, was made through a serial interface connected to a host computer. For current measurements, we used dedicated digital current sensors, which allowed precise measuring and a convenient interface with the controller.

This setup was proposed to allow flexibility, precise and coherent measurements, and representative test stimuli (e.g., static and dynamic test modes). Since the experiments focus on SEL characterization, we designed a test board where current monitoring is done in the memory supply line and the IO banks. With the controlling board simultaneously managing these measurements and the test algorithms, it allowed coherent time stamping between both events, i.e., current variations and detected bit flips. Also, we applied edge parametric conditions to better evaluate the worst test conditions (e.g., highest supply voltage within nominal range). Four test modes were used: 1. standby, when no operations are performed, and the device remains powered on; 2. chip-enabled, similar to the standby, but the memory chip-select is set; 3. static, the memory is written, then, after a sufficient period, it is readback; 4. dynamic, in which the memory is constantly written and read with different patterns, and errors are reported when detected.

For the heavy-ions experiment, eight SRAM devices were evaluated, covering the two manufacturing lots previously mentioned, and they required delidding for proper particle penetration. It allowed verifying the die markings and some internal structures, but unfortunately, some of the devices were compromised during the process and removed from the analysis. Various irradiation angles and test modes were explored in the heavy-ion campaign. For the protons experiment, four SRAM devices were used, of which two were reused from the previous experiment for better lot correlation and two were pristine to avoid cumulative biases. Only the most relevant test modes were applied in this campaign, based on the outcomes from the heavy-ion experiments.

C. Irradiation Facilities

The Radiation Effects Facility (RADEF) at the University of Jyv äskyl ä, Finland, was used for irradiation with heavy ions inside a vacuum chamber. The beam has a 10% homogeneity for the selected irradiation area and heavyions cocktail of 16.3 M eV /n, capable of generating a flux up to approximately 3 • 10 5 ions/cm 2 /s. The ions selection includes the following species and LET (at silicon surface and vacuum mode in M eV.cm 2 /mg): 17 O 6+ , 1.52; 40 Ar 14+ , 7.2; 57 F e 20+ , 13.3; 83 Kr 29+ , 24.5; and 126 Xe 44+ , 48.5.

The Proton Irradiation Facility (PIF) at the Paul Scherrer Institute (PSI), Switzerland, was used for proton irradiation. The selected proton energies were: 16, 29, 51, 70, 101, 151, and 200 M eV . Copper plates were introduced in the beam path to generate different energies and two primary proton energies were used to allow proper testing at the lower energy range: 100 and 200 M eV . Proton fluxes of about 3 • 10 7 to 8 • 10 7 p/cm 2 /s were used, and all tests were performed at ambient room temperature and air pressure. The beam homogeneity was checked for each energy setting and the reported beam homogeneity is inferior to 10%.

IV. DATA ANALYSIS

In this section, we present and analyze the results from the experimental campaigns and the flight data.

A. Heavy Ions

Fig. 1 presents the estimated SEL cross sections for the experiments with heavy ions. These cross sections were obtained by combining all the test modes due to the similar SEL responses: standby, chip-enabled, static, and dynamic. Some LETs were introduced by changing the DUTs angle in relation to the beam irradiation and are indicated as empty squares on the graph (instead of the solid squares). The error bars represent a 95% confidence interval with a 10% beam fluence uncertainty. Based on these cross sections, we did a Weibull fitting, in which we excluded the LETs lower than 7.2 M eV.cm 2 /mg. Despite the reasonable capabilities of demonstrating the cross section trend for higher energies, the Weibull did not fit the lower LETs. We still are investigating this behavior, as further discussed in Section V. An important outcome of this test was that we did not observe part variability, which was an initial assumption before the test. During the execution of dynamic tests, the occurrence of SELs caused a sudden increase in the number of upsets in memory cells. This behavior is classified as a Single-Event Functional Interrupt (SEFI) since the number of upsets is so high that an ECC cannot handle the error rate, requiring the system to power cycle the device.

Fig. 2 presents an example of an SEL increasing the error rate. It is noticeable that before it, the current consumption of the memory during each dynamic operation follows a pattern, and right after the SEL occurs by significantly increasing the current, the error rate also suddenly increases. This example is just one of the many SELs that also caused significant error rates to increase, and they were the typical behavior occurring in more than 95% of the events.

B. Protons

Fig. 3 presents the estimated cross sections for protons. It is worth noting that the tested energies 16 and 29 M eV did not produce any latch-up events, so they are not presented in the graph. The DUTs 90 and 04 were reused from the previous experiment with heavy ions, so they already had some accumulated dose, and the DUTs 07 and 08 are memories that were never irradiated before this experiment. Based on the obtained results, no significant nor consistent differences were observed on the cross sections for these devices, suggesting that the accumulated dose for the tested ranges did not substantially impact the SEL response. Thus, the cross sections were combined to determine the Weibull parameters in the figure. The error bars represent a 95% confidence interval with a 10% beam fluence uncertainty.

C. Flight Data

Since the launch, on the 7th of May 2013, until the 3rd of March 2020, 1054 events flagged as type 406 and 77 events flagged as type 369 have been recorded. Note that type 369 was not initially in use, starting to be registered only later. The first error, type 406, occurred on the 8th of May 2013. Fig. 4 presents the mapping of all the errors reported between the 8th of May 2013 and the 18th of March 2020 for both flag types. As expected, most errors occur either in the SAA or both polar regions. Moreover, between April 2016 and May 2017, as indicated by vertical lines in the figure, the average error rate was more than two times higher than that experienced before and after this period. After investigating this behavior with the PROBA-V operators, we found that during this exact period, the lines were reassigned, i.e., the primary was line two, whereas before and after, the primary was line one. Hence, line two indicates a higher sensitivity since the primary line is constantly in use, leaving just a short period of operation for the redundant line during the automatic recovery procedures. We still are investigating this behavior since the experimental campaigns did not point to our initial assumptions, such as part variability. V. DISCUSSION Similar to the behavior observed during flight, the effects identified in the particle accelerator experiments have shown that SELs lead to many upsets in the memory cells. Notably, although the PROBA-V did not monitor the current of the memories in the nominal mode to unequivocally classify SELs, the mission operators noticed this behavior at the beginning of the mission (commissioning), in which more housekeeping data were available and this correlation could be assumed, allowing the classification of the flag types with the support of the ECC behavior. Hence, with the corroboration of the experimental campaigns' behavior, we can consider a sufficient correlation between flag type 406 and SELs, as initially assumed.

Regarding the presented cross sections, we observed agreement between devices from the two tested manufacturing lots and trends similar to Weibull curves. However, with low LET for heavy ions, we observed higher cross sections than expected for the Weibull fitting, which is intriguing since these LET values were not expected to significantly contribute to the error rates and were not even characterized before flight. Any SEL events were observed for lower energy protons, suggesting a more significant contribution of energies superior to 50 M eV . Despite these conclusions, the presented results alone did not enable a full explanation of the observed flight behavior, despite many characterization efforts and analyses (e.g., cumulative effects influence, correlations with SEL current levels) that were not herein reported due to size constraints. In order to provide more insights, we scheduled a test campaign using a laser facility, in which we aim to evaluate whether different regions of the device have distinct SEL cross section responses, explaining the lower LET discrepancy with the fitted Weibull curve, and verify the impact of the temperature in the SEL sensitivity. Therefore, based on the characteristics of the errors presented in the flight, in this work, we propose the following hypotheses to be further investigated in the final paper:

• The SRAM devices on-board PROBA-V had similar error rates, but environmental conditions were different within the satellite, such as temperature or shielding effects, and this caused the different average rate seen in Fig. 5; • Distinct affected regions of the device triggered SEL with different responses, in which current levels and SEFI patterns might differ.

VI. CONCLUSION

This work presented an analysis of the behavior observed in the PROBA-V SRAM memories, which presented sudden increases in the error rate, which were likely due to SELs in the SRAM memories. To investigate this behavior, we performed experiments in particle accelerator facilities, where we replicated the system characteristics for the accelerated environment to obtain the same phenomenon and analyze the memory with more detailed error rate information. Based on that, initial hypotheses were formulated and further experiments were planned, aiming to provide more concrete conclusions concerning the observed flight behavior.

Fig. 1 .

 1 Fig.1. SEL cross sections for the tested devices on the heavy-ions campaign. σsat = 1.03 • 10 -01 cm 2 and LET th = 7.2 M eV.cm 2 /mg.

Fig. 2 .

 2 Fig. 2. Example of error rate variation during SEL for heavy ions with 14.4 M eV.cm 2 /mg.

Fig. 3 .

 3 Fig.3. SEL cross sections for the tested devices on the protons campaign. σsat = 4.29 • 10 -10 cm 2 and E th = 50.9 M eV .

Fig. 4 .

 4 Fig. 4. Mapping of SRAM errors occurring on-board PROBA-V between the 8th May 2013 and the 18th March 2020.

Fig. 5

 5 Fig.5presents the accumulated errors over a long period of the PROBA-V mission, from which average error rates were observed and estimated. It is possible to conclude that the sensitivity of flag type 369 errors appears to be much lower than for errors of flag type 406, solely looking at the error rate (almost 19 days/error in comparison to close to 3 days/error).Moreover, between April 2016 and May 2017, as indicated by vertical lines in the figure, the average error rate was more than two times higher than that experienced before and after this period. After investigating this behavior with the PROBA-V operators, we found that during this exact period, the lines were reassigned, i.e., the primary was line two, whereas before and after, the primary was line one. Hence, line two indicates a higher sensitivity since the primary line is constantly in use, leaving just a short period of operation for the redundant line during the automatic recovery procedures. We still are investigating this behavior since the experimental campaigns did not point to our initial assumptions, such as part variability.

Fig. 5 .

 5 Fig. 5. Cumulative error plot with reference to time occurring on-board the PROBA-V SRAM memories.

This study has received funding from the European Union's Horizon 2020 research and innovation programme (grant agreement no. 101008126), from an ESA contract (contract no. 4000134557/21/NL/KML/rk), and from the Region d'Occitanie and the École Doctorale I2S from the University of Montpellier (contract no. 20007368/ALDOCT-000932).


Douglas A Santos

M P Mattos

Douglas R Melo

Luigi Dilillo
email: luigi.dilillo@umontpellier.fr

Enhancing Fault Awareness and Reliability of a Fault-Tolerant RISC-V System-on-Chip

Keywords: RISC-V, System-on-Chip, dependability, radiation effects, radiation testing, neutrons, mixed-field

ecent research has shown interest in adopting the RISC-V processors for high-reliability electronics, such as aerospace applications. The openness of this architecture enables the implementation and customization of the processor features to increase their reliability. Studies on hardened RISC-V processors facing harsh radiation environments apply fault tolerance techniques in the processor core and peripherals, exploiting system redundancies. In prior work, we present a hardened RISC-V System-on-Chip (SoC), which could detect and correct radiation-induced faults with limited fault awareness. Therefore, in this work, we propose solutions to extend the fault observability of the SoC implementation by providing error detection and monitoring. For this purpose, we introduce observation features in the redundant structures of the system, enabling the report of valuable information that supports enhanced radiation testing and support the application to perform actions to recover from critical failures. Thus, the main contribution of this work is a solution to improve fault awareness and the analysis of the fault models in the system. In order to validate this solution, we performed complementary experiments in two irradiation facilities, comprehending atmospheric neutrons and a mixed-field environment, in which the system proved to be valuable for analyzing the radiation effects on the processor core and its peripherals. In these experiments, we were able to obtain a range of error reports that allowed us to gain a deeper understanding of the faults mechanisms, as well as improve the characterization of the SoC.ecent research has shown interest in adopting the RISC-V processors for high-reliability electronics, such as aerospace applications. The openness of this architecture enables the implementation and customization of the processor features to increase their reliability. Studies on hardened RISC-V processors facing harsh radiation environments apply fault tolerance techniques in the processor core and peripherals, exploiting system redundancies. In prior work, we present a hardened RISC-V System-on-Chip (SoC), which could detect and correct radiation-induced faults with limited fault awareness. Therefore, in this work, we propose solutions to extend the fault observability of the SoC implementation by providing error detection and monitoring. For this purpose, we introduce observation features in the redundant structures of the system, enabling the report of valuable information that supports enhanced radiation testing and support the application to perform actions to recover from critical failures. Thus, the main contribution of this work is a solution to improve fault awareness and the analysis of the fault models in the system. In order to validate this solution, we performed complementary experiments in two irradiation facilities, comprehending atmospheric neutrons and a mixed-field environment, in which the system proved to be valuable for analyzing the radiation effects on the processor core and its peripherals. In these experiments, we were able to obtain a range of error reports that allowed us to gain a deeper understanding of the faults mechanisms, as well as improve the characterization of the SoC.R

I. INTRODUCTION

The increasing dependence on electronic systems developing complex and critical tasks in modern technologies creates several challenges related to reliability requirements. Many systems are based on powerful processing units that must be fail-safe and guarantee continuous service delivery. Each application sector must comply with standards and guidelines to meet such requirements as seen in the automotive [START_REF] Xie | Recent Advances and Future Trends for Automotive Functional Safety Design Methodologies[END_REF], aerospace [START_REF] Schwierz | Assurance Benefits of ISO 26262 Compliant Microcontrollers for Safety-Critical Avionics[END_REF], [START_REF]Description, Implementation and General Requirement[END_REF], and military [START_REF] Gangl | A case study on U.S. government military standard development[END_REF] industries. With the introduction of the RISC-V architecture, several projects and research efforts were initiated to adopt these novel RISC-based processors in many application domains. In particular, the open and modular nature of the architecture provided traction for its adoption in high reliability and critical systems [START_REF] Di Mascio | Leveraging the Openness and Modularity of RISC-V in Space[END_REF].

Within these application domains, several reliability requirements are derived from the environmental conditions, in which these systems are exposed: temperature variations, pressure profile, mechanical stress, and ionizing radiation. For avionics flying in high altitudes or in orbit, ionizing radiation seriously threatens the dependable operation of such systems [START_REF] Cannon | Chapter 7 and 9-Radiation impacts on satellites and Ionising radiation impacts on avionics and ground systems[END_REF], [START_REF] Boudenot | Radiation space environment[END_REF]. The interaction of ionizing particles with electronic devices generates a plethora of effects. Single-Event Effects (SEEs) are an important phenomena, which induce transient, intermittent, and permanent faulty behaviors [START_REF] Yang | Fault-Tolerance Techniques for Spacecraft Control Computers[END_REF]. For processors, these effects can be observed as corrupted bits, wrong calculations, and transients, which may result in application output error, data corruption, unexpected termination, and hangs [START_REF] Cho | Quantitative Evaluation of Soft Error Injection Techniques for Robust System Design[END_REF].

In order to ensure the dependability of these processing systems, several fault tolerance techniques are applied to the processors' architecture and the surrounding peripherals. These techniques exploit temporal, spatial, and informational redundancies [START_REF] Sorin | Fault tolerant computer architecture[END_REF]. Recent work explored and analyzed the effectiveness of these techniques applied to the RISC-V architecture with fault injection campaigns, implemented as soft-core modules inside Field-Programmable Gate Array (FPGA) devices. In [START_REF] Ramos | Efficient Protection of the Register File in Soft-Processors Implemented on Xilinx FPGAs[END_REF], [START_REF] Ramos | An ALU Protection Methodology for Soft Processors on SRAM-Based FPGAs[END_REF], the authors explore different approaches for improving the architectural elements of the processor. In [START_REF] Wilson | Neutron Radiation Testing of Fault Tolerant RISC-V Soft Processor on Xilinx SRAM-based FPGAs[END_REF], [START_REF] Wilson | Neutron Radiation Testing of a TMR VexRiscv Soft Processor on SRAM-Based FPGAs[END_REF], RISC-V cores with Triple Modular Redundancy (TMR) were implemented and validated, achieving significant reliability improvements but with a high resource utilization penalty. As seen in [START_REF] Sim | A Dual Lockstep Processor System-on-a-Chip for Fast Error Recovery in Safety-Critical Applications[END_REF], the design of a lockstep RISC-V was proposed to address safety-critical applications. Other works presented hybrid solutions with similar strategies to find an optimal trade-off between performance, resource utilization, and reliability, such as [START_REF] Gupta | A Fault Tolerant Microprocessor Architecture[END_REF], [START_REF] De Oliveira | Evaluating Soft Core RISC-V Processor in SRAM-Based FPGA Under Radiation Effects[END_REF], [START_REF] Li | DuckCore: A Fault-Tolerant Processor Core Architecture Based on the RISC-V ISA[END_REF]. In prior work, we proposed a fault-tolerant implementation of a RISC-V system [START_REF] Santos | Reliability analysis of a fault-tolerant RISC-V system-on-chip[END_REF], [START_REF] Santos | Neutron Irradiation Testing and Analysis of a Fault-Tolerant RISC-V System-on-Chip[END_REF] designed for FPGAs, known as HARV-SoC, where hybrid architectural redundancy techniques were applied, compared, and evaluated.

These fault-tolerant designs are usually validated through fault injection campaigns, either with simulation environments, emulation strategies, software frameworks, or real stimuli (e.g., exposition to radiation in particle accelerators). All those strategies offer valuable data to enable the reliability assessment of complex systems [START_REF] Cho | Quantitative Evaluation of Soft Error Injection Techniques for Robust System Design[END_REF], [START_REF] Entrena | Soft Error Sensitivity Evaluation of Microprocessors by Multilevel Emulation-Based Fault Injection[END_REF]. For application domains with demanding dependable systems (i.e., aerospace, military), performing fault injection campaigns with real stimuli is a mandatory step to meet standards criteria [START_REF]Description, Implementation and General Requirement[END_REF]. These campaigns are mostly adopted during the development and validation phases of new systems. For this, designers instrument their systems with observation points [START_REF] Santos | Neutron Irradiation Testing and Analysis of a Fault-Tolerant RISC-V System-on-Chip[END_REF] and prepare meaningful benchmarks [START_REF] Quinn | Using Benchmarks for Radiation Testing of Microprocessors and FPGAs[END_REF] to enable observation and measuring of the system's fault sensitivity. However, most fault-tolerant RISC-V implementations explored in the literature focus mainly on tolerating faults, making indepth reliability analysis complicated due to the lack of information. As a result, this approach leads to a limited understanding of these complex systems in harsh radiation environments. However, implementing observation structures is a challenging task, given that hard-core processors do not have customization capabilities, and soft-core processors in FPGAs require additional configuration structures that are also susceptible to failures.

In this work, we propose a strategy targeting enhanced error tracking in the HARV-SoC by extending the fault observability of the SoC implementation through runtime error detection. For this purpose, we monitor critical structures of the SoC architecture to report relevant information about the errors triggered by radiation-induced events. This solution allows a better understanding of the underlying impacts of SEEs in the design compared to alternative strategies. Furthermore, it enables more efficient use of the hardening countermeasures and provides the means for the application to perform actions to recover in case of critical failures. To implement and validate the concept, we instrument the HARV-SoC with this solution and evaluate the observability effectiveness through neutron and mixed-field irradiation campaigns. It is worth mentioning that this solution presented many technical challenges since many internal structures had to be prepared for this purpose. Furthermore, prior field expertise was important in guiding the definition of the information to be monitored and reported in an effective manner.

The remaining of the paper is structured as follows: Section II presents the related work; Section III describes key aspects of our RISC-V implementation and its fault tolerance and awareness features; Section IV presents the proposed experimental strategy; Section V presents the results and analysis; Section VI discusses these results and outcomes; and Section VII concludes the work.

II. RELATED WORK

Recent studies explored fault tolerance techniques to improve the reliability of RISC-V systems but provided a superficial analysis of the reported errors. Table I presents and compares the different approaches for the detection and observation of errors found for RISC-V systems in the literature. We grouped the works using horizontal lines in the table based on their fault injection strategy: simulation, emulation, or radiation, respectively. Moreover, six categories were defined for comparison: 1. core architecture, providing the used RISC-V core implementation; 2. hardening strategy, showing the different fault tolerance techniques applied; 3. configuration memory check, to evidence its impact in the injection campaign; 4. evaluation coverage, showing the observed elements; 5. output classification, to compare the provided execution classification; and 6. error analysis, in which the types of analyses are described.

For simulation-based validations [START_REF] Sim | A Dual Lockstep Processor System-on-a-Chip for Fast Error Recovery in Safety-Critical Applications[END_REF], the authors perform initial validation of their systems and only provide functional analysis. This approach provides full information on internal components and faulty behavior but uses limited fault models. When emulation is used [START_REF] Ramos | An ALU Protection Methodology for Soft Processors on SRAM-Based FPGAs[END_REF], [START_REF] Ramos | Efficient Protection of the Register File in Soft-Processors Implemented on Xilinx FPGAs[END_REF], [START_REF] Aranda | Analysis of the Critical Bits of a RISC-V Processor Implemented in an SRAM-Based FPGA for Space Applications[END_REF], authors often use dedicated components to inject and monitor errors in the configuration memory of the target FPGA. In some cases, more high-level techniques are employed to inject faults during the software execution [START_REF] Li | DuckCore: A Fault-Tolerant Processor Core Architecture Based on the RISC-V ISA[END_REF]. Nevertheless, emulations are similar to simulations, in other words, they are as good as the used fault models are realistic, i.e., in correlation to the real phenomena generation the faults.

For injections using radiation experiments [START_REF] Wilson | Neutron Radiation Testing of Fault Tolerant RISC-V Soft Processor on Xilinx SRAM-based FPGAs[END_REF], [START_REF] Wilson | Neutron Radiation Testing of a TMR VexRiscv Soft Processor on SRAM-Based FPGAs[END_REF], [START_REF] De Oliveira | Evaluating Soft Core RISC-V Processor in SRAM-Based FPGA Under Radiation Effects[END_REF], [START_REF] Santos | Neutron Irradiation Testing and Analysis of a Fault-Tolerant RISC-V System-on-Chip[END_REF], authors attempt to provide a description of the observed errors and their possible impact on their systems. Then, the main goal is to assess and correlate the observed phenomena with known fault models and measure the sensitivity of the systems to the specific tested radiation source. Despite that, this approach is prone to limited availability of information, leading to conclusions with error rates uncorrelated with architectural elements or inconclusive behavioral trends.

Therefore, this work contributes with solutions that provide additional information during irradiation test campaigns. The proposed technique is capable of reporting the errors intervening in protected internal structures. Then, in a RISC-V implementation with the employment of hardening techniques in the entire SoC or in the critical elements, the main architecture-related errors can be reported. With the combination of multiple observation points and report generation in runtime, the experiment can be better monitored, allowing posterior enhanced analysis with coherent and resourceful execution logs. This supports the cross-analysis of the phenomena from different perspectives and increases the correlation between the observed hardware errors and software behavior. Notably, the experiments reported on [START_REF] Wilson | Neutron Radiation Testing of Fault Tolerant RISC-V Soft Processor on Xilinx SRAM-based FPGAs[END_REF], [START_REF] Wilson | Neutron Radiation Testing of a TMR VexRiscv Soft Processor on SRAM-Based FPGAs[END_REF], [START_REF] De Oliveira | Evaluating Soft Core RISC-V Processor in SRAM-Based FPGA Under Radiation Effects[END_REF] would greatly benefit from the observation strategy adopted in this work, since more valuable outcomes and conclusions could be reported, even enhancing the opportunities for architectural and hardening techniques comparisons. TABLE I: Summary of RISC-V fault tolerance and awareness in related work.

III. FAULT TOLERANCE AND AWARENESS

In prior work, we introduced the processor core, which presented reliability improvements in its RISC-V organization [START_REF] Santos | A Low-Cost Fault-Tolerant RISC-V Processor for Space Systems[END_REF]. Following that, we extended it to a System-on-Chip, containing a bus implementation with peripherals, whose reliability was also evaluated through simulations [START_REF] Santos | Reliability analysis of a fault-tolerant RISC-V system-on-chip[END_REF]. After that, we focused on the characterization and analysis of the SoC under neutron irradiation [START_REF] Santos | Neutron Irradiation Testing and Analysis of a Fault-Tolerant RISC-V System-on-Chip[END_REF].

This work presents results from a new fault injection campaign with atmospheric neutron irradiation, detailing the improvements proposed for our fault-tolerant architecture at the processor and SoC levels.

A. RISC-V Processor Core

In previous test campaigns, we identified that error counters could quantify the number of radiation-induced faults detected by the implemented fault tolerance techniques. These techniques were TMR at the control and Arithmetic Logic Unit (ALU) and Error Correcting Code (ECC) with Single Error Correction and Double Error Detection (SECDED) in the processor core registers and the data memory. In this implementation, the errors were detected and corrected in the background, not affecting the application execution time.

Although the error counting technique was effective, the information provided about each detected error was very scarce, comprising only the number of occurrences for each error, which was later reported by the application. Therefore, in this work, we propose a solution that makes use of more processor assets to provide further information in execution time. The solution consists of implementing an error handler component in the processor core that requests traps when errors are detected. It monitors the signals from the fault-tolerant structures, saving relevant information about the detected errors, as presented in Figure 1. The trap controller handles the request as an exception, ensuring that the processor will handle this error as soon as possible. The detectable errors in the error handler include the following errors of the processor: Program Counter (PC) single-and double-bit upsets, Instruction Register (IR) single-and double-bit upsets, register file single-and double-bit upsets, control TMR error, and ALU TMR error. The detected errors are all reported through exceptions, regardless of their correctability. Besides reporting errors in the processor core, the error handler design also includes the external error input, which is available as a processor core input signal. The purpose of this signal is to enable the SoC to report errors in its structures, such as interconnections and peripherals.

Error handler

External errors

Register

The error handler has a set of registers that store information upon detecting an error. These registers are implemented in the error handler component and are mapped in the memory. This way, we save the data at the moment the error was detected and provide additional information regarding the error details. The basic error information comprises the error identifier, a register in which each bit corresponds to one type of error. The application must clear this register to indicate that the error has been handled, and the execution should continue. Further information that supports additional analysis of the error is provided such as the values from the ALU output, PC, IR, and cycle register. For bit-upset errors, the encoded data with the bit upset and its ECC are recorded. Besides that, the application context is provided. The error handler has a number of registers that store the PC whenever a function is called, which is cleared when it returns. This part is implemented by a rotating queue, which increments the queue pointer when a function is called and decrements it when it returns. With this information, it is possible to identify the context in which the error has occurred.

B. RISC-V System-on-Chip

The implementation of the error handler provides more details on the errors occurring in the RISC-V processor. However, errors are also prone to appear at the SoC level. For that, we improved the reliability of the SoC by adding additional logic to the bus master controller, which now has the ability to identify a timeout for bus accesses. Furthermore, we changed the memory, which was previously implemented with FPGA internal resources, to an external Synchronous Dynamic Random-Access Memory (SDRAM). This implementation enables more complex applications since the size of memory available increases significantly. We implement an exclusive error handler to provide observability at the SoC level, which requests traps to the error handler through the external error input.

This separation of core and SoC handlers simplified the design for the processor core error handler since it does not need to consider all different kinds of errors that may be implemented for different SoC designs. In addition, it provides more flexibility for the SoC error handler since designs may require more complex error handling. An overview of the HARV-SoC implementation is shown in Figure 2, in which the SoC error handler monitors errors from the bus master and the memory controller, signaling to the core when an error has occurred. The following subsections describe the integration of an external SDRAM into the design, including its memory controller that adds error correction and detection capabilities, and the implementation of the SoC error handler, respectively.

1) SDRAM EDAC Controller:

Neither the SDRAMs nor the standard SDRAM controllers provide Error Detection and Correction (EDAC) for the stored values. Therefore, we extended the implementation of Microchip's SDRAM controller by adding components that equip it with EDAC capabilities. For that, we provide SECDED for each 32bit word, and we store both the data and ECC in the memory. Considering the size of 7 bits of the ECC and 32 bits for the word, we separated the first three-quarters of the memory for the data and the last quarter for the correcting code. This way, the data will have its equivalent ECC address calculated by dividing the data address by 4 and adding three-quarters of the memory size as an offset.

Three components were required to extend the support of this controller: bus bridge, unaligned access converter, and ECC adapter. The bus bridge interfaces the memory access to be supported through the bus. The unaligned access converter modifies unaligned memory accesses to aligned accesses, transforming one access into two when required. This converter simplifies the ECC adapter logic. The ECC adapter is responsible for reading from the SDRAM controller and performing error correction and detection. When an error is detected, this component has an output interface that reports the detected single-and double-bit upsets to the SoC error handler.

2) SoC Error Handler:

The SoC error handler requests exceptions directly to the core error handler through the external errors input, enabling the software application to identify when errors originated from the SoC. The errors implemented for our SoC error handler are bus access timeout and memory single-and double-bit upsets. Besides this register, it also provides additional information for the data memory itself, such as the memory address in which the error was found, the address of the ECC information related to this word, the encoded data with the uncorrected word, and the previous address upset.

Furthermore, SDRAM memories have power-on values that are not necessarily all zeroes, then it is required to initialize the memory if ECC-valid values to avoid several exceptions in the initialization. For that, the exception for memory errors is controlled by an enable register, which is disabled only until the memory is initialized with zeroes and enabled as soon as it is done. This enable register is implemented with TMR.

In related work, it was identified that SDRAM might be prone to stuck bits [START_REF] Luza | Technology Impact on Neutron-Induced Effects in SDRAMs: A Comparative Study[END_REF], which would cause the software application to stay in a permanent loop, reporting the same error repeatedly. Therefore, we save the two last upset addresses, and each reported memory error is compared to these. If the new error's upset address is equal to both of these, the error is ignored in order to continue the application execution. In addition, the SoC error handler also provides a bus access timeout error report. This error is reported by the bus master controller, which timeouts if a bus access takes too long to respond.

IV. RADIATION EXPERIMENTS

We performed irradiation test campaigns in order to validate the proposed approach for enhancing error observation. For that, we used a complementary approach in which the experiments investigated distinct radiation sources and explored different aspects of fault awareness. The following subsections present the irradiation facilities, experimental setup, and test execution.

A. Irradiation Facilities

Two radiation experiments were conducted: the first in ChipIr beamline, part of the ISIS Neutron and Muon Source, at the Rutherford Appleton Laboratory, United Kingdom; and the second in the CHARM mixed-field environment, part of the European Organization for Nuclear Research (CERN), Switzerland.

ChipIr generates a neutron beam with a spectrum that is representative of atmospheric environments [START_REF] Cazzaniga | Progress of the Scientific Commissioning of a fast neutron beamline for Chip Irradiation[END_REF]. The facility is capable of generating neutron irradiation with fluxes that are several orders of magnitude higher than those found at ground level on Earth, which enables an accelerated characterization of devices and systems. The beam flux is 5 × 10 6 cm -2 /s for energies higher than 10 MeV.

CHARM provides a high-penetrating radiation environment with different particle spectra and fluxes, mainly depending on the shielding and location. For our experiment, we selected a configuration that is mostly concerned with higher energy neutrons and protons, but many other particle species are present with less SEE impact (e.g., electrons, muons). It also accumulated a significant total dose. The facility monitored and reported the irradiation in four main categories: Thermal Neutrons (ThN), which are composed of neutrons with lower energies; High-Energy Hadrons (HEH), including all particle types with energy higher than 20 MeV in an equivalent measure; N1MeV, for 1 MeV neutrons; and Total Ionizing Dose (TID), showing the accumulated degradation. For this study, the particles species and spectra of interest for SEE characterization are represented as HEH, which present an estimated flux of 8 × 10 9 cm -2 /day for the selected configuration.

B. Experimental Setup

The experiments consisted of system-level evaluation setups made of identical boards, in which six Systems Under Test (SUTs) boards were used in ChipIr and two boards in CHARM. These boards host a flash-based FPGA device: the Microchip's SmartFusion2 M2S010. Each board includes an SDRAM memory, used as system memory for the SoC. Serial connections were used to transmit the logs generated in the SUTs to a host computer outside the irradiation room. For that, custom transceiver boards were used to extend these serial interfaces. The setup is fixed in a frame containing the mentioned test boards and logging transceivers. Each test board has independent and monitored power supply lines. Figure 3 These setups offer a compact and effective testing platform for HARV-SoC. In particular, regarding the configuration memory, the flash-based FPGA provides high immunity to SEEs [START_REF] Dsilva | Neutron SEE Testing of the 65nm SmartFusion2 Flash-Based FPGA[END_REF], improving the platform's availability for the experiment. Also, the usage of a custom transceiver solution mitigated logging errors that could affect post-irradiation analysis, since they are based on a robust industrial protocol that reduces the amount of complex and sensitive components in the irradiation room (e.g., serial to USB converters, USB extenders).

C. Benchmarks and Test Execution

To homogeneously sensitize the SoC, two workloads were used during the experiment: CoreMark [START_REF] Gal-On | Exploring CoreMark a Benchmark Maximizing Simplicity and Efficacy[END_REF] and Embench [START_REF] Bennett | An Evolving Benchmark Suite for Embedded IoT Computers from an Academic-Industrial Cooperative[END_REF]. CoreMark is an industry-standard performance benchmark composed of four algorithms: list processing, matrix manipulation, state machines, and Cyclic Redundancy Check (CRC). CRC is employed not only as a workload but also provides a self-checking capability for the inner steps of the benchmark execution. Embench is another performance benchmark and intends to provide a broader set of operations, resulting in twenty-two algorithms. We used a custom subset of these algorithms due to memory size constraints.

Using the proposed error handler policy and exception triggers, the application handles the radiation-induced events and can continue the execution accordingly. For example, in the case of an uncorrectable error, the application might continue its execution, it can restart the execution, or even trigger its methods for recovery before the error leads to a possible execution failure. For the proposed experiment, we focused on reporting the errors instead of triggering specific countermeasures. Thus, the benchmarks are cyclically executed until errors are detected. During execution, the exception handling routine reports all the available information, it corrects or ignores the detected error depending on the hardening configuration, and it returns to the previous context (i.e., normal benchmark execution). The benchmarks provide a final result that includes a pass and fail criteria.

For ChipIr, each FPGA hosted a RISC-V SoC running CoreMark cycling between two configurations of the system: hardened and baseline, in this order. The hardened configuration consists of the RISC-V SoC with all the fault tolerance techniques enabled, while the baseline disables the processor core ECC and TMR corrections. Similarly, for CHARM, CoreMark and Embench were used with the specified hardening configurations. In addition, we monitored the power consumption of each board separately to ensure proper operation and safety throughout the entire campaign.

V. RESULTS

This section discusses first the design implementation results, including the resource usage and execution time overheads. After, the section analyzes the results obtained during the irradiation campaigns performed at the ChipIr and CHARM facilities.

A. Synthesis

Table II presents a resource usage comparison between the previous work [START_REF] Santos | Characterization of a RISC-V Systemon-Chip under Neutron Radiation[END_REF], and this work's baseline (with hardening disabled) and the different hardened configurations of the HARV-SoC. The design presented in this paper has several architectural improvements compared to the previous work, both in the processor core and the SoC. As a result of these modifications, the Logic Element (LE) resource usage of the baseline processor increased by 37.8% (from 4649 to 6471), and the frequency improved by 38.6% (from 33.71 MHz to 46.76 MHz). Implementing the fault tolerance and observability structures also increases resource usage, showing an overhead of 38% when only the redundant blocks are included and 64% when the error handler block is also included (column 'Usage overhead'). Because the error handler block is implemented the resource usage increases since it requires several registers to store the trap details and the processor interfacing logic.

As a result of the hardening implementation, the critical path increased, causing a reduction in the maximum operating frequency (Fmax), which became around 33 MHz for both hardened versions. The maximum frequencies of the hardened versions were similar because the error handler block did not affect the critical path. Nonetheless, the processor's multicycle implementation allows for a higher actual maximum operating frequency, running at 50 MHz during validation and experiments.

B. Performance Overhead

Besides the overhead in resource usage of the FPGA, the handling of the errors introduces an execution time overhead. We measured the handling of each error report and obtained an average of approximately 30 ms. Considering the experiments in the mixed-field environment, which has an accelerated irradiation environment, the overhead in execution time is negligible.

Within the handling routine, the step that takes longer to execute is reporting the error information through the serial interface. Actual applications will not be required to externally report the details from the traps, simplifying the error handler and reducing the execution overhead even further.

C. ChipIr: Atmospheric Neutrons

For this experiment, we focused on the errors in the processor architecture, which were presented with limited understanding in prior work. It reached a total accumulated fluence of 3.64×10 11 n/cm 2 . In order to provide a comparison basis, according to the device characterization [START_REF] Dsilva | Neutron SEE Testing of the 65nm SmartFusion2 Flash-Based FPGA[END_REF] and the obtained fluence, we calculated that 43 upsets were expected in critical system registers, those protected by ECC. However, it was also expected to have fewer observed errors than the provided by this estimation, since to be observed and tracked as an error, the register must be actually used by the application and affect its execution. For instance, temporary registers usually hold values only for a short period of time, while the stack pointer register retains important values at all times, hence being more susceptible to bit upsets. Thus, as expected, the detected errors in the processor core were single-bit upsets from the register file, which was the most likely to present errors since it is the monitored structure with the largest amount of registers. In addition, no upsets were detected in the PC and instruction registers.

1) Errors Classification: Besides the detected errors, there were processor execution failures, in which the origin could not be identified. These failures appeared as load exception faults, more specifically, memory accesses to invalid addresses. In total, we identified processor core traps in 17 runs distributed across all the boards used for the experiment. Between these, 14 traps were related to single-bit upsets in the register file and 3 to load exception faults.

Regarding the identified errors, we could gather the error details previously mentioned. The errors were recognized as single-bit upsets, recognizable by reading the error identifier register. We also provided further information for all detected errors using the implemented error handler solution. In one run, for example, we reported the encoded data with the bit upset, and the application could recognize the upset in the 30th bit. Besides that, we also provided additional information that supports the error analysis, such as the PC, instruction register, mcycle register, and ALU output.

Throughout the test campaign, no errors were detected in more than 99.9% executions, and the CoreMark execution ran perfectly. Only a few executions presented error traps, which is expected considering the previously mentioned analysis on the number of upsets. We classified the errors for each tested processor configuration according to the ability to correct and observe it (Table III). Most of the errors were correctable in the hardened configuration since they were single-bit upsets. There were a few errors that could not be corrected by the hardened processor configuration, which were identified as load access fault exceptions. On the other hand, the baseline configuration does not correct single-bit upsets, which were classified as not correctable errors. It is worth noticing that, in one case, the baseline configuration experienced an error classified as correctable, which was an upset in the ECC part of the data that did not affect the execution. Although most of the errors were detected, there were a few executions for which the system could not recognize the cause. These errors were detected as timeouts by the Watchdog Timer (WDT) reset mechanism, which restarted the processor execution by resetting the entire SoC. Considering the processor architecture, these errors are most likely caused by faulty interconnect or peripheral components, which resulted in the processor waiting indefinitely for bus transactions.

2) Execution Context: Using the error handler enables the application to identify the context in which the error has occurred. In one of the runs, for example, using the report we could identify that the upset occurred while executing the multiplication function of the compiler standard library, which was called by the CoreMark's matrix multiplication routine. The application could identify the entire path taken by the application flow, identifying the context in which the upset has occurred. Figure 4 presents the most common contexts in which error traps were triggered. The functions recognized as the most common to have errors were the core init state and core list mergesort, which correspond to the functions in the Coremark benchmark operation that were taking the longest to execute, making them more likely to be affected by errors. Following that, the matrix test was affected in 16.67% of the errors. There were a few errors (16.67%) in which it was not possible to identify the context in which the error appeared because these errors occurred in unprotected parts of the SoC. Lastly, the puts r and core init matrix functions had 11.11% of the errors each. 3) Failure Characterization: In order to correlate the failures based on the fluence in the radiation environment, we estimated the Mean Fluence to Failure (MFTF) and the failure cross section (XS). We consider a failure, when the device requires a power cycle to recover the processor operation, where the hardening techniques and soft resets do not work. The MFTF metric is the mean of the fluences that lead to critical failures in the experiment, and the cross section is a calculation of the failure rate of the device based on the fluence, given in cm 2 /device. Table IV presents the summary of MFTF and failure cross section results for each tested board, with respect to the fluence of neutron particles. It is worth noting that all the boards were tested in the same conditions, with a beam homogeneity lower than 10%. Also, we defined two applications to provide specific estimations for Mean Time To Failure (MTTF) based on their target environments: terrestrial, with reference to New York sea level, and avionics, at a typical avionic cruising altitude, about 300× the sea level flux, as discussed in [START_REF] Lei | An atmospheric radiation model based on response matrices generated by detailed Monte Carlo Simulations of cosmic ray interactions[END_REF], [START_REF] Goldhagen | Measurement of the energy spectrum of cosmic-ray induced neutrons aboard an ER-2 high-altitude airplane[END_REF] based on the NASA-Langley model. For the first environment, the expected MTTF is about 180,566 years. For the second, it is estimated in 601 years. These results provide sufficient safety margins for the operation of most commercial systems.

D. CHARM: Mixed-Field Environment

The experiment performed in CHARM was a follow-up of the neutrons campaign. In this second characterization, we were interested in extending the validation of the observability technique. To achieve that, we provided the same execution classification based on the reported errors and investigated other aspects to demonstrate the error reporting capabilities. In addition, this campaign allowed the evaluation of the system under another radiation source. The reported total fluence for both boards during the experiment was approximately 9.61 × 10 11 HEH/cm 2 , and the total accumulated dose was about 3.62 × 10 1 krad. V presents the classification of errors for the CHARM experiment. We classified the errors for each processor and benchmark configuration according to the SoC's ability to correct and observe them. Thus, it includes the percentage of correctable, not correctable, and non-recognized errors. These errors enabled the application to observe and report important information about the effects caused by the radiation in the SoC. Only a few processor execution failures were observed, in which the origin could not be identified. The majority of failures were identified and traceable, mainly in the fully hardened version. Among those, the most common were single-bit upsets in the register file, single-and double-bit upsets in the memory, and the least common were double-bit upsets in the PC. Besides these errors, load and store exception faults also caused errors during the execution, which were not correctable errors, and triggered soft-resets of the processor to recover its execution. Most of the errors were correctable in the hardened configuration since they were single-bit upsets. There were a few errors that could not be corrected for the hardened processor configuration, which were identified as load access fault exceptions. On the other hand, the baseline configuration, which had a single-bit upset correction in the memory still enabled, presented mainly register and bus errors as not correctable errors.

1) Errors Classification: Table

2) Failure Characterization: Similar to the ChipIr campaign, we performed a failure characterization by reporting the MFTF and cross section for the different boards. The failure of these metrics is also considered a critical failure that requires a device power cycle. MFTF: Mean Fluence to Failure.

3) Error Analysis: The reports and data from the error handler enabled a meticulous analysis of the errors detected during the experiment. This thorough examination enabled us to gain a comprehensive understanding of these errors.

Table VII presents a summary of the errors detected in the mixed-field experiment regardless of processor configuration. The most common errors were from the memory, responsible for approximately 78% of all the errors, followed by single-bit upsets from the register file, store/access fault exceptions, and finally, a PC double-bit upset.

Furthermore, the reports enabled a calculation of the cross section for each different error. These cross sections provide valuable information for the estimation of the number of errors in actual radiation environments. For further analysis of the detected errors details, we compiled a summary of the instructions that were interrupted to handle exceptions. Table VIII presents the number of error occurrences per instruction, with an overall percentage. We notice that the most common instructions are memory access, consistent with the previously reported errors. However, besides the errors from memory access functions, 10 errors were during flow control and arithmetic instructions.

The operation made by these instructions is related to the triggered error. Most memory access instructions, for example, were interrupted due to errors in the data memory. While the flow control and arithmetic are more likely to be affected by errors in registers. Besides that, this table also presents the cross section for each different instruction, which enables a correlation between fluence and instruction with an error. 4) Detected Block Error Event: Here, we describe one of the most notable errors that occurred while the processor was executing a CoreMark with the hardened configuration. In a short span of time, several traps were reported due to multiple single-and double-bit upsets from the SDRAM memory in neighboring addresses. In total 72 errors were reported sequentially, including 42 single-bit upsets and 34 double-bit upsets. Thus, we identified this error as a memory block error, which occurs in SDRAM memories [START_REF] Luza | Technology Impact on Neutron-Induced Effects in SDRAMs: A Comparative Study[END_REF]. Despite the block error, the execution continued, and the CoreMark benchmark result was still correct. To further analyze this behavior, we ran a simulation and compared the expected data at those addresses with a fault-free execution. We identified that the simulation and reported addresses actually stored the same values, indicating that multiple-bit upsets occurred in the ECC memory section.

Figure 5 presents a visualization of the block error in a logical bitmap representation of the memory. The block error is enlarged and highlighted since it only affected a small area of the memory. Bits are represented in vertical lines of 16 bits (i.e., word size) and horizontal positions represent each memory address. It is worth mentioning that the actual block error may be larger than the detected, but the remaining part of the block error was not accessed during the execution.

5) Error Propagation:

We also performed an analysis of the error's impact on the execution of the benchmarks.

The main objective was to find the proportion of errors capable of interfering with the execution for each processor hardening configuration. Even for the hardened configuration, some errors can be masked within the execution or not present an impact on the final benchmark result. Thus, we were interested in the improvement obtained on the hardened configuration related to this difference.

Another interesting outcome was in the baseline processor configuration, in which the error correction was disabled. In this configuration, since the errors are only reported but not corrected, we noticed that some errors led to further errors and consequent failures. In a particular case, for example, a single-bit upset in the register file led to a load access fault, causing a failure in the processor execution due to access to an invalid memory address. Four occurrences of this type of propagation were identified, of which three single-bit upsets on the register file itself and a double-bit upset in the program counter. As expected, this same error propagation was not observed in the hardened configuration.

In Table IX, we present the different error propagations for the baseline and hardened processor versions. The #Errors column shows the total number of that specific error, while the #Propagated errors reports the number of those errors that actually resulted in an error in the benchmark execution. It is worth noting that this number of propagated errors is closely related to the benchmark algorithms and will have different results for different algorithms. Besides the number of detected errors, we also report the HEH cross section for the propagated errors.

Fig. 1 :

 1 Fig. 1: Error handler implementation.

Fig. 2 :

 2 Fig. 2: RISC-V SoC architecture.

Fig. 3 :

 3 Fig. 3: Experimental setups prepared for irradiation campaigns. (a) ChipIr: six test boards, in two layers, and logging interfaces (highlighted). (b) CHARM: two test boards, in parallel, and logging interfaces (highlighted).

Fig. 4 :

 4 Fig. 4: Errors triggered per function.

Fig. 5 :

 5 Fig. 5: Logical bitmap representation of the SDRAM memory showing the block error.

TABLE II :

 II Resource usage comparison of different configurations of HARV-SoC in the flash-based FPGA: Microchip's SmartFusion2 M2S010.

	Error Handler	Hardening	4LUT	DFF	LEs 1	LEs Usage	Usage	Fmax
							Overhead
	n.a. 2	disabled	4344	2150	4649	38.47 %	-	33.71 MHz
	disabled	disabled	5922	2799	6471	53.55 %	1×	46.73 MHz
	disabled	enabled	8382	3131	8957	74.12 %	1.38×	33.34 MHz
	enabled	enabled	9730	4471	10596	87.69 %	1.64×	33.27 MHz

TABLE III :

 III Classification of errors in the neutron experiment.

	Error Classification	Baseline	Hardened
	Correctable error	14.29%	55.56%
	Not correctable error	71.42%	11.11%
	Non-recognized error	14.29%	33.33%

TABLE IV :

 IV Summary of MFTF and cross section per board.

	Board	MFTF [n/cm²]	Neutron Failure XS [cm²/device]
	#B1	1.66 × 10 10	6.03 × 10 -11
	#B2	1.85 × 10 10	5.42 × 10 -11
	#B3	2.19 × 10 10	4.56 × 10 -11
	#B4	2.15 × 10 10	4.66 × 10 -11
	#B5	1.89 × 10 10	5.29 × 10 -11
	#B6	2.60 × 10 10	3.84 × 10 -11
		MFTF: Mean Fluence to Failure.

TABLE V :

 V Classification of errors in the mixed-field experiment.

	Error Classification	Baseline	Hardened
	Correctable error	39.02%	60.00%
	Not correctable error	43.90%	37.14%
	Non-recognized error	17.07%	2.86%

  Table VI presents these results, indicating the rates with respect to the fluence of HEH particles.

TABLE VI :

 VI Summary of MFTF and cross section per board in the mixed-field experiment.

	Board	HEH MFTF [H/cm²]	HEH Failure XS [cm²/device]
	#B1	1.31 × 10 11	5.20 × 10 -12
	#B2	1.31 × 10 11	5.20 × 10 -12

TABLE VII :

 VII Reported errors in the mixed-field experiment.

	Error	#Errors	Percentage	HEH XS [cm²/device]
	Memory single-bit upset	71	52.21%	7.38 × 10 -11
	Memory double-bit upset	35	25.74%	3.64 × 10 -11
	Register file single-bit upset	21	15.44%	2.18 × 10 -11
	Load access fault	6	4.41%	6.24 × 10 -12
	Store access fault	2	1.47%	2.08 × 10 -12
	Program counter double-bit upset	1	0.74%	1.04 × 10 -12

TABLE VIII :

 VIII Instructions in reported errors.

	Class	Instruction	#Occurrences	Percentage	HEH XS [cm²/device]
		lbu	78	57.35%	8.11 × 10 -11
		sw	31	22.79%	3.22 × 10 -11
	Memory access	lw sb	10 4	7.35% 2.94%	1.04 × 10 -11 4.16 × 10 -12
		lh	2	1.47%	2.08 × 10 -12
		lb	1	0.74%	1.04 × 10 -12
	Flow control	jalr	4	2.94%	4.16 × 10 -12
	Arithmetic	addi add	3 3	2.21% 2.21%	3.12 × 10 -12 3.12 × 10 -12

The authors would like to acknowledge the support given by both irradiation facilities staff. Notably, Carlo Cazzaniga and Maria Kastriotou from ChipIr, and Salvatore Danzeca and Andrea Coronetti from CERN, for CHARM facility. In addition, we would like to thank Ivan Slipukhin (UM/CERN), Antonio Scialdone (UM/CERN), and Pablo Aviles (UC3M), for the support in the execution of the experiments.

The LE (Logic Element) report combines the 4-input Look-Up Tables (4LUTs) and DFFs (D-type Flip-Flops);

not applicable for HARV-SoC version presented in[START_REF] Santos | Characterization of a RISC-V Systemon-Chip under Neutron Radiation[END_REF].

This work presents fault awareness and reliability improvements in a fault-tolerant RISC-V SoC (HARV-SoC) by implementing a solution to observe errors in the processor architecture and SoC. This solution provides detailed information on the application errors in execution time. This way, the application can discern the errors' origin and impact on the processor's structures.We validated the implementation by using fault injection in irradiation facilities, in which we could identify various errors occurring at the processor core. It is worth mentioning that real radiation environments cause effects that are not easily predictable and depend on several factors, which are limited in simulation and emulation-based experiments. As a result, we identified the radiation-induced events and provided information that could point the application to the compromised structure.In future work, we intend to perform further radiation characterizations of the processor by using other particle types (e.g., proton and heavy ions that are representative of the space radiation environment). Moreover, we forecast further improvements in the recovery capabilities of the application upon detecting uncorrectable errors and block errors.

VI. DISCUSSION

The acquired information on the errors proved to be useful in identifying and understanding the SoC behavior in radiation environments. More specifically, the information provided details such as the application context, error origin, affected structure, and corrupted data. We were able to characterize the system for each environment, complementing the classification of the types of errors and investigating their impact on the system. For instance, for the ChipIr campaign, we performed an MFTF analysis, showing the robustness of the system, and an execution classification with further description at the software level. For CHARM, we provided a deeper analysis of the errors' cross sections, discussed fault-masking, and investigated a block error in detail.

For protected elements of the processor core, this observation mechanism supported fault awareness at the application level, which could be applied to improve the system's reliability, since it enables the implementation of recovery routines that consider the affected element within the application. With these details, the application could mitigate the impact of uncorrectable errors (e.g., double-bit upsets, load/store access fault) in execution time by preventing error propagation. For instance, this hardware-level information could be used to implement software rollback routines, resulting in hybrid hardening solutions. The rollbacks would restore the processor context, using a non-corrupted state, when these uncorrectable errors are detected by the error handler.

With the reported information, we noticed that the recovery capabilities from errors originating on the bus interconnect structure should be improved since some load/store access faults were detected and led to execution errors. Moreover, due to the analysis performed on the observed block error, we could identify that the memory error handling should be improved. For that, a possible solution is to implement early block error identification based on monitoring the number of memory errors over time and, when a certain threshold is achieved, triggering a recovery procedure.

Considering the many alternatives for exploiting the proposed observability features, one of the most important achievements is the possibility of operating a proper SEE characterization with enhanced analysis. This is not a trivial endeavor and the proposed solution greatly supports this effort, as presented in the results section. In addition, it is worth mentioning that identifying errors and reporting them through exceptions is not a novel concept, but applying this approach to radiation-induced faults provides many new opportunities for processors and SoC evaluation, contributing to the research community. Notably, as exemplified for the MTTF in avionic applications, the system not only provided enough reliability to be used as part of critical avionic systems, but also could be characterized and validated in more detail to meet safety requirements.

Finally, another outcome of the performed experiments is a comparison between the irradiation campaigns. From the critical error cross sections, it is possible to observe a significant difference in sensitivity for each campaign. Performing the average of the cross sections of all boards for ChipIr, we obtained 4.97 × 10 -11 cm 2 /device, and for CHARM considering the HEH, 5.20 × 10 -12 cm 2 /device. As expected, different particles and energy spectra can induce very distinct error rates. In this case, we observed an order of magnitude difference in which the SoC, in combination with the FPGA, suggests more sensitivity to atmospheric neutrons than the tested mixed-field environment.

VII. CONCLUSIONS