Dario Asciolla

Luigi Dilillo

Douglas Santos

Douglas Melo

Alessandra Menicucci

Marco Ottavi

Characterization of a RISC-V Microcontroller through Fault Injection

This article reports the results of fault injection on a microcontroller based on the RISC-V (Riscy) architecture. The fault injection approach uses fault simulation based on Modelsim and targets a set of 1000 fault injected per microcontroller block and per benchmarck. The chosen benchmarks are the Dhrystone and CoreMark that may represent generic workloads. The results show certain block are more prone to fault than others, as also confirmed by a vulnerability analysis that correlates the number of observed faults and the rate of access to the blocks.

I. INTRODUCTION

The space environment interaction with electronics represents an important challenge for satellite missions. Ionizing particles and electromagnetic radiations affect electronic devices by inducing faults in specific circuit areas that may lead to system failures. These failures can be temporary, with the occurrence of the so-called Soft Errors, or permanent with the occurrence of Hard Errors [START_REF] Calligaro | Rad-hard Semiconductor Memories[END_REF]. Moreover, the exposition of electronics to radiation induces to premature aging, with the deterioration of performance and/or functionality of the systems. For this reason, the space industry resorts to hardening techniques that are generally based on hardware and software redundancy, with the generation of custom devices. This type of solutions, while effective, are energy and hardware greedy and leads to costs several times higher than for conventional COTS (Commercial Off The Shelf) electronics.

Completely programmable hardware platforms such as FPGA make the development of a system extremely flexible but, at the same time, require ad-hoc designing and therefore they are not available to a broad programming community. On the other side, the use of standard processors ISA architectures allows many developers to design applications, but the closeness of the architectures does not allow the designers to make easy and cheap modifications to the underlying hardware.

RISC-V allows developers to combine the advantages of both worlds [START_REF] Di Mascio | The case for risc-v in space[END_REF], providing flexibility to both hardware and software.

The purpose of this paper is characterizing a RISC-V core, through an extensive simulation-based fault injection campaign with the target of identifying the most critical modules within the core. For this purpose, the study of sequential modules is fundamental, especially for COTS components, because they can suffer from bit flips [START_REF] Dilillo | Soft errors in commercial off-the-shelf static random access memories[END_REF]. The data stored in the memory element can be corrupted, with Single Event Upsets (SEUs), after the interaction with ionizing particles and electromagnetic radiations in general.

II. PLATFORM

The chosen RISC-V platform is the Parallel Ultra Low Power (PULP) Platform. It is been designed from Integrated Systems Laboratory (IIS) of ETH Z ürich and Energy-efficient Embedded Systems (EEES) group of the University of Bologna [START_REF]Pulp-Platform[END_REF]. It is an open-source platform and very useful for our purposes, because it is possible to access all parts of the system. In this specific case, from this platform, the Pulpino microcontroller has been chosen.

Riscy core architecture overview [START_REF]PULPino: Datasheet[END_REF] is shown in Fig. 1. For the characterization campaign, we are focusing over all sequential modules inside the core. For replicating the typical effects of space radiation environment on electronics [START_REF] Gupta | Mtcube project: See ground-test results and in-orbit error rate prediction[END_REF], a simulation-based fault injection technique was chosen. This technique allows full access to the entire processor without any architectural modifications. The first step of the procedure, a golden simulation, with no injected fault , is performed to obtain the reference data to be used for the detection of mismatches caused by fault injections. The Riscy core fault injection is performed for all sequential subsystems. For each sequential subsystem, 1000 simulations are performed, 1 fault injected per simulation run. The following steps [START_REF] Travessini | Processor core profiling for seu effect analysis[END_REF] summarize the tasks executed for each simulation:

1) Selection of a flip-flop, in a certain sequential subsystem, where the fault will be injected. This is done selecting, in a random way, from a list that contains all signals, in the VHDL code, which implement registers. Each signal corresponds to each bit of the register. 2) Selection of a random instant when the fault will be injected. In order to avoid a fault during the logging process, the fault is injected before the reporting process. 3) Simulation runs until the chosen injection instant. 4) Injection of the fault by forcing a bit flip in the target sequential element. 5) Simulation runs until the end of the algorithmic benchmark. 6) Making a copy of the register file content. 7) Storing the print out of the program results. Data obtained during the simulation campaign are used to classify fault effects that can be summarized in five categories [START_REF] Travessini | Processor core profiling for seu effect analysis[END_REF] that are listed below:

• No Effect -The simulation finishes obtaining the correct result from the program and the content of the register file is equal to the reference one. • Latent -The simulation finishes obtaining the right result, but the content of the register file is not equal to the reference. • Wrong result -The system has a failure and the simulation finishes obtaining the wrong program result.

• Timed out -The simulation takes an abnormal amount of time to finish the program execution compared to the reference. • Exceptions -The core generates exceptions during the simulation. Latent errors potentially can propagate and lead to a system failure in the future, but these errors may also be masked by the normal core functioning.

IV. SIMULATION RESULTS

This section presents and discusses the results of the fault injection campaign and the measure of the utilization of sequential modules. These simulations are useful for vulnerability estimation. The chosen benchmarks, for this campaign, are Dhrystone and CoreMark, they offer a generic workload that can cover almost all operations that a core can execute.

The resources utilization has been measured using a Modelsim simulation running a TCL script. Coremark is configured to perform 1 cycle while Dhrystone 1000 cycles. In this study, the focus is over the sequential parts inside modules that are the target of the characterization through fault injection. A simulation both for Dhrystone and CoreMark is performed obtaining the resources utilization for the entire simulation time. The workload is similar for both simulations, as shown in Fig. 2, for Dhrystone and CoreMark. In Fig. 3 are shown the results of the simulation campaign using Dhrystone as workload. As mentioned above, for each microcontroller block, 1000 simulations were performed, with a fault has been injected for each run. This procedure is repeated for each block, obtaining the results showed in the plot. Fig. 4 shows the results of the simulation campaign, using Fig. 3. Fault injection campaign results using Dhrystone Benchmark CoreMark as workload, with the same procedure used above. Like in the analysis concerning the other benchmark, it can be noticed that the most critical modules are the controller and the register file, which present a large number of latent errors and wrong results. The controller is again accessed with lower frequency w.r.t. the register file, but it displays high vulnerability.

V. VULNERABILITY ESTIMATION

Results obtained from the fault injection campaigns present similar trends for the two workloads. In this section, we try to calculate the vulnerability of each block of the RISC-V Riscy core, by introducing the following equation:

v = f u × c, if u > 0 0, otherwise (1)
• v resource vulnerability.

• f failure rate. It is equal to the number of wrong results normalized to the number of simulations;

• u resource utilization. For each module, it is equal to the number of clock cycles of activity over the total number of clock cycles. • c normalization constant equal to 100. This approach allows to extrapolate a general evaluation of the block vulnerability that is independent of the used benchmark algorithm. Since it is based on the correlation between the amount of detected failures and the actual use of the blocks of the microcontroller. Fig. 5 shows the results of the vulnerability associated with each block.

The plot uses a logarithmic axis to easily visualize the results.

It can be noticed that there is a correlation between the vulnerability calculated from both campaigns. The subsystems that show a high vulnerability are the instruction fetch registers, the controller and the register file.

Lower but significant vulnerability magnitude is showed for the prefetch unit, instruction fetch-instruction decode pipeline register, the instruction decode-execution pipeline register, ex-wb pipeline register and the load store unit.

The limitation of the adopted vulnerability model is due to the occurrence of system failures that are observed also in blocks that are not supposed to be used by the algorithm. From simulation results, showed in Fig. 3 for Dhrystone workload and in Fig. 4 for CoreMark workload, the most critical sequential modules are the controller and the register file. Despite the fact that the controller is used with lower frequency than the register file, it causes a large number of failures when it undergoes to fault injection. Exceptions are caused by faults injected in modules inside the instruction fetch stage, in the instruction decoder stage and in the execution-write back pipeline register. CoreMark stimulates the usage of the hardware loop module and we noticed a relevant system failures caused by faults injected inside this module.

The interrupt controller and the control-state registers don't cause any failure when faults are injected.

The most used resources are the prefetch unit, the instruction fetch-instruction decode pipeline register and the instruction decode-execute pipeline register. There are modules that are never used during the benchmark execution like the hardware loop for Dhrystone and the multiplier registers and the interrupt controller for both benchmarks (in the run simulations).

From the study of vulnerability, showed in Fig. 5, the most critical module result to be the controller module. The Vulnerability can be used to estimate, for each module, the system failure rate when executing other software. This can be done simply making the product between the tabled vulnerability values and the utilization value measured for the given application. These represents an important information for the design of fault-tolerant Risc-V core, since it can be used to evaluate the best redundancy techniques in terms of time usage and hardening impact for each composing block, on the base of its vulnerability.

Fig. 1 .

 1 Fig. 1. RISC-V Riscy core Architecture Overview

Fig. 2 .

 2 Fig. 2. RISC-V Riscy sequential resources utilization

Fig. 4 .

 4 Fig. 4. Fault injection campaign results using CoreMark Benchmark

Fig. 5 .

 5 Fig. 5. RISC-V Riscy sequential Resources Vulnerability