Design with low complexity fine-grained Dual Core
Lock-Step (DCLS) RISC-V processors

Pegdwende Romaric Nikiema, Angeliki Kritikakou, Marcello Traiola, Olivier Sentieys

Inria, Univ Rennes, CNRS, IRISA

pegdwende.nikiema@inria.fr, angeliki.kritikakou@irisa.fr, marcello.traiola@inria.fr, olivier.sentieys@inria.fr

***Abstract***—Embedded systems in critical domains require both hard real-time and reliable execution. Real-time execution requires bounds in the worst-case execution time, while reliable execution is under threat, as systems are becoming more and more sensitive to transient faults. Thus, systems should be enhanced with fault-tolerant mechanisms with bounded error detection and correction overhead. Such mechanisms are typically based on redundancy at different granularity levels. Coarse-grained granularity has low comparison overhead, but may jeopardize timing guarantees. Fine-grained granularity immediately detects and corrects the error, but its implementation has increased design complexity. To mitigate this design complexity, we leverage high-level specification languages to design intrusive fine-grained lockstep processors based on the use of shadow registers and rollback, with bounded error detection and correction time, being appropriate for critical systems.

***Index Terms***—Transient faults, Reliability, Real-time, Fault-tolerance, RISC-V, High level specification

I. INTRODUCTION

Embedded systems in critical domains, such as automotive,
aviation, space domains, often require both hard real-time and
reliable execution. Real-time execution is provided through
timing guarantees that ensure that the worst-case execution
time of the application can be bounded and it does not exceed
a given latency requirement [1]. However, reliable execution is
under threat due to the increased fault susceptibility of modern
electronic systems. Due to the reduced transistor sizes and
lower supply voltages of modern technologies [2], systems
are becoming more and more sensitive to environmental
sources [3], such as ionization, radiation, and high-energy
electromagnetic interference, leading to temporary reliability
violations, called transient faults. With the technology reduc-
tion, transient faults become dominant [3], occurring even
under normal operation conditions, which was not the case
with technology used a decade ago [4]. As systems become
more and more prone to transient faults during execution [5],
they should be enhanced with fault-tolerant mechanisms in
order to provide reliable execution.

Fault-tolerant mechanisms are typically based on redundancy. To deal with faults occurring in the processors, the same set of operations with same inputs is executed on different processors. Such approach is promising, since the probability of having the same fault concurrently occurring on all processors is very small [6]. To detect/correct a fault, the outputs of redundant operations must be compared. This comparison can be performed at different granularity levels,

from coarse-grained granularity, defined at the memory and
I/O interface taking place at the end of application execution,
to fine-grained granularity, occurring at the instruction level
during the application execution. Although coarse-grained
granularity has low overhead in terms of comparison, error
detection/correction may occur long after the fault affects
the system, thus jeopardizing timing guarantees in hard real-
time systems [7]. On the contrary, fine-grained granularity
provides immediate error detection/correction. Non-intrusive
fine-grained approaches have typically high comparison over-
head, since the outcome of all instructions (i.e., values and
addresses) has to cross the shared communication network to
reach memory and I/O in order to be compared [7]. Therefore,
intrusive approaches are required, which, however, have in-
creased design complexity due to large processor modifications
required and the complex validation of the circuitry to perform
the across-core comparisons every cycle [8].

To mitigate such complexity increase during the design
process, we leverage high-level specification languages to de-
sign intrusive fine-grained lockstep processors, with bounded
error detection and correction time, thus being appropriate for
critical systems. By using high-level specification languages,
such as C and C++, the processor design becomes less com-
plex, as the processor model can easily be modified, expanded
and verified, compared to HDL implementations [9]. With
the help of High-Level Synthesis (HLS) tools, such high-
level processor descriptions can be interpreted to create digital
hardware which implements the same functionality. More
precisely, we use an on open-source HLS implementation of a
32-bit RISC-V processor [9] as case study and we propose two
intrusive fine-grained lockstep approaches, with different area
and upper bound detection and correction time, , i.e., Partial
Shadow Register with Rollback (PSRR) and Full Shadow
Register (FSR). While dual Modular Redundancy (DMR) en-
ables only fault detection, Triple Modular Redundancy (TMR)
allows achieving error correction but also entails significant
area and power overhead. Thus, we extend a DMR approach
with fine-grained correction mechanisms – based on register
shadowing and rollback mechanisms – in order to perform
error correction, with reduced area overhead w.r.t. TMR.

II. RELATED WORK

Existing redundancy approaches applied for processors can
be categorized as *non-intrusive* and *intrusive*.
Non-intrusive approaches do not modify the processor architecture, and are typically used when the internal architecture details are hidden or difficult to modify, e.g., Commercial Off-The-Shelf (COTS) processors. Depending on the type of cores, the approaches can be homogeneous or heterogeneous. For instance, a homogeneous approach uses two MicroBlaze soft cores to implement Dual Core LockStep (DCLS). When a core mismatch is detected, a roll-forward correction is applied that excludes temporary the faulty core, which is repaired through reconfiguration. Meanwhile, the correct processor continues execution and its state is copied as soon as faulty core is reconfigured. A heterogeneous DCLS approach uses ARM A9 as hard core and RISC-V as soft core [10]. Lockstep execution is achieved by inserting checkpoints in the application, where a synchronisation module is activated to check for mismatch between the status of the cores and apply roll-back. Heterogeneous approaches may have reduced performance, due to the low-speed processor that sets an upper bound to the DCLS performance. Note that, to perform lockstep with hard cores, processors should have specific architecture support. However, this functionality is not present on all processors [10]. Non-intrusive approaches are less flexible as they do not modify the internal processor architecture, leading to higher communication overhead.

Intrusive approaches modify internally the processor architecture. Hence, when rollback mechanisms are applied, they do not require to insert checkpoints at the application level. For instance, the Dynamic Adaptive Redundancy Architecture (DARA) is a homogeneous DCLS approach that was applied to RISC ISA SH-2 processors and is based on rollback to achieve error correction [11]. DARA adds additional hardware to check the consistency of all pipeline stage registers, between the lockstep cores. However, the proposed mechanism does not support faults occurring in branch instructions. Interleaved multithreaded execution is used to implement a dual lockstep approach using two virtual RISC-V cores [12]. Other approaches extend the pipeline registers with error detection and correction codes, e.g., Duckcore extends a RISC-V core with Single Error Correction Double Error Detection (SECDED) in the pipeline stages [13]. However, such an approach can add significant overhead due to the encode and decode time. Other approaches apply triplicate components inside the RISC-V core to enhance its repliability. For instance, Control and Status Registers, Program Counter and the register file [14], FFs, LUTs, BRAMS, and DSPs [15], and the arithmetic and logic unit (ALU) are triplicated [16]. Furthermore, existing fine-grained approaches are based on HDL implementations, which are significantly more complex than high-level description, and they do not focus on providing upper bounds regarding the error detection and correction time of the applied fault-tolerant hardware mechanisms.

### III. PROPOSED FINE-GRAINED INTRUSIVE DCLS

This section describes the two proposed DCLS approaches, i.e., *Partial Shadow Register with Rollback (PSRR)* and *Full Shadow Register (FSR)*, and reports the upper bound w.r.t.

<figure><img src="image_1.png" /><figcaption>Fig. 1. Dual Core Lock-Step principle illustration</figcaption></figure>

their detection and correction time. In this paper, we assume that register file, instruction memory, and data memory are protected by an Error Correction Code (ECC) mechanism.

In both PSRR and FSR DCLS mechanisms, we use two identical cores executing the same instruction at each clock cycle. Each pipeline stage stores the result of its logic computation in a pipeline register. At each cycle, the proposed mechanism checks for execution consistency by comparing the pipeline registers of the two cores, as sketched in Figure 1. If no error is detected, the execution runs normally. Otherwise, the detected error indicates that a fault impacted the logic, which in turn generated a wrong result, or that a fault impacted the pipeline register itself, flipping a bit in the result. In this case, correction is applied, as described in the following sections.

#### A. *Partial Shadow Register with Rollback (PSRR)*

When an error is detected, the PSRR approach re-executes the instruction being processed in the faulty stage, i.e., it has to be re-fetched and go through the whole pipeline again. To be able to re-execute the instruction that was in the faulty pipeline stage, we modified the micro-architecture to store in each given pipeline stage the address of the current instruction being processed in that stage. In this way, when a fault is detected, we are able to retrieve the address of the instruction to re-execute. Furthermore, the result of the previous and current stages (that have already started processing the new instructions) have to be discarded, e.g. if an error was detected in the *EX* stage, the stages discarded are *IF*, *ID* and *EX*. As for the next stages, we let them continue as their execution is not impacted by the error, e.g., for an error detected in the *EX* stage, we let *MEM* and *WB* to continue. Finally, No Operation (NOP) instructions are introduced in the pipeline.

In the above described approach, the correctness of the address of the instruction, being processed in each stage, is key for the rollback mechanism to work correctly. A fault could modify such address, jeopardizing the rollback procedure. Therefore, we store a copy of such address for each pipeline stage – this is why we refer to the approach as *'Partial Shadow Register'*.
<figure><img src="image_2.png" /><figcaption>Fig. 2. PSRR error detection and rollback mechanism</figcaption></figure>

achieve that, a vote among the addresses stored in the cores and the copy is made before rolling back. Figure 2 sketches the PSRR approach. To illustrate this mechanism, let us consider the assembly code snippet in the listing 1.

```
$1      addi   a5,a5,-16
$2      addi   a5,a5,-16
$3      add    a5,a4,a5
$4      sw     a5,-32(s0)
$5      mv     a4,a5
$6      jal    target
$7      mv     a4,a5
$8      mv     a5,a0
---
<target>
$9      sw     a5,-32(s0)
$10     mv     a4,a5
---
```

<caption>Listing 1. Illustration example program assembly code</caption>

<table><caption>TABLE I
PIPELINE STATUS FOR FAULT-FREE EXECUTION</caption><thead><tr><th rowspan="2">Pipeline stage</th><th colspan="5">Execution cycle</th></tr><tr><th>n-1</th><th>n</th><th>n+1</th><th>n+2</th><th>n+3</th></tr></thead><tbody><tr><th>IF</th><td>5</td><td>6</td><td>7</td><td>8</td><td>9</td></tr><tr><th>ID</th><td>4</td><td>5</td><td>6</td><td>7</td><td>NOP</td></tr><tr><th>EX</th><td>3</td><td>4</td><td>5</td><td>6</td><td>NOP</td></tr><tr><th>MEM</th><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td></tr><tr><th>WB</th><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td></tr></tbody></table>

Table I shows a snapshot of the processor pipeline stages during a non-faulty execution of this program. NOP instructions at cycle $n + 3$ in ID and EX stages are due to the jump instruction $6$. Let us suppose that, at some point during cycle $n - 1$, an error impacts the result of ID stage, which is processing instruction $4$. As already mentioned, the result of ID stage can be impacted by a fault in the ID logic or directly in the pipeline register between ID and EX stages

(IDtoEX). The mismatch is detected at cycle $n$ by comparing the IDtoEX pipeline registers of the two cores in the DCLS. This makes invalid the instructions $4$, $5$, and $6$ in IF, ID, and EX stages. Hence, the rollback mechanism discards the execution results of these stages; the MEM and WB results are valid and instructions $3$ and $2$ will continue their execution, since they are not impacted by the fault effect. Finally, the Program Counter (PC) in cycle $n + 1$ will be assigned to instruction $4$, after a vote among current instruction addresses stored in the cores and the copy (EX_PC_BKP in the figure). After the correction, we obtain the pipeline state shown in Table II. Finally, at cycle $n + 2$ we obtain the same pipeline

<table><caption>TABLE II
PIPELINE STATUS WITH PSRR CORRECTION</caption><thead><tr><th rowspan="2">Pipeline stage</th><th colspan="5">Execution cycle</th></tr><tr><th>n-1</th><th>n</th><th>n+1</th><th>n+2</th><th>n+3</th></tr></thead><tbody><tr><th>IF</th><td>5</td><td>6</td><td>4</td><td>5</td><td>6</td></tr><tr><th>ID</th><td>4</td><td>5</td><td>NOP</td><td>4</td><td>5</td></tr><tr><th>EX</th><td>3</td><td>4</td><td>NOP</td><td>NOP</td><td>4</td></tr><tr><th>MEM</th><td>2</td><td>3</td><td>NOP</td><td>NOP</td><td>NOP</td></tr><tr><th>WB</th><td>1</td><td>2</td><td>3</td><td>NOP</td><td>NOP</td></tr></tbody></table>

state that we had at cycle $n - 1$ when the fault occurred (except for instructions $1$, $2$, and $3$ that were not impacted by the fault). Thus, in this example, the error detection and correction overhead is three cycles (from $n - 1$ to $n + 1$).

In general, the PSRR mechanism has a minimal error detection and correction overhead of two cycles: the cycle when the fault occurs and the cycle to detect the fault. Then, the deeper the impacted stage is in the pipeline, the more extra cycles are required. Thus, the upper bound in time for error detection and correction is given by the pipeline depth.

## B. Full Shadow Register (FSR)

In the Full Shadow Register approach, we create a backup copy (BKP) of all the pipeline registers of the core, i.e.
<figure><img src="image_3.png" /><figcaption>Fig. 3. FSR error detection and correction mechanism</figcaption></figure>

for all the stages. The error detection and correction logic is the following: in each clock cycle $n$, we compare the pipeline registers of the two cores, containing the results of the computation of cycle $n-1$. If no error is detected, all the pipeline registers are copied to the backup copy BKP. When an error is detected in the comparison, a flag is raised, the results of the current computation are discarded and the pipeline registers of both cores are restored with the values in BKP. In this way, in the next cycle $n+1$, the pipeline will re-execute the cycle that was impacted by a fault. Figure 3 sketches the described FSR approach. Let us use again listing 1 as an example. As shown in Table III, let us suppose that,

<table><caption>TABLE III
PIPELINE STATUS WITH FSR CORRECTION</caption><thead><tr><th rowspan="2">Pipeline stage</th><th colspan="5">Execution cycle</th></tr><tr><th>n-1</th><th>n</th><th>n+1</th><th>n+2</th><th>n+3</th></tr></thead><tbody><tr><td>IF</td><td>5</td><td>6</td><td>7</td><td>6</td><td>7</td></tr><tr><td>ID</td><td>4</td><td>5</td><td>6</td><td>5</td><td>6</td></tr><tr><td>EX</td><td>3</td><td>4</td><td>5</td><td>4</td><td>5</td></tr><tr><td>MEM</td><td>2</td><td>3</td><td>4</td><td>3</td><td>4</td></tr><tr><td>WB</td><td>1</td><td>2</td><td>3</td><td>2</td><td>3</td></tr></tbody></table>

at the end of cycle $n-1$, the computation had no errors. In cycle $n$, the pipeline registers are compared and, since there was no error, the content of the pipeline is copied to the BKP register. Let us now suppose that a fault impacts the ID stage in cycle $n$. In cycle $n+1$, the pipeline registers of the two cores are compared and an error is detected, due to the fault in cycle $n$. Thus, the results of the computations is discarded and the content of BKP is copied back. Finally – in cycle $n+2$ – the cycle impacted by the fault can be re-executed and the computations goes back to normal. The FSR approach entails a constant overhead of two clock cycles, namely the one where the fault occurred, and one to detect it and restore the BKP register. Therefore, compared to PSRR, FSR entails higher overhead to copy all the pipeline registers, but reduces the upper bound for the error detection and correction to two

cycles.

### C. Enhancement w.r.t. state of the art

Thanks to the high-level description of the proposed approaches and the RISC-V processor, we are able to perform fast iterations of both designing and evaluated through fault injection and to expose some drawbacks of the state-of-the-art approaches from which we derived our DCLS.

To give an example, the proposed PSRR approach has been inspired by DARA [11], where we were able to find and fix some shortcomings. To illustrate that, let us consider again the assembly code snippet in the listing 1 and the pipeline status in Table I. At cycle $n+2$ instruction $S6$ – a jump – is in the EX stage. This will set the PC of the next cycle ($n+3$) to address $S9$. Let us imagine that at cycle $n+1$ a fault impacted the results of the fetch stage, executing instruction $S7$. The rollback approach used in DARA (and presented in section III-A) would detect the error in cycle $n+2$ and re-execute – in cycle $n+3$ – instruction $S7$. However, this instruction was not meant to be executed, since instruction $S6$ was an immediate jump to instruction $S9$. We were able to spot this condition thanks to the proposed high-level DCLS implementation enabling fast design iterations and fault injections. Without any countermeasure, this condition would lead to wrong program execution, i.e., executing instructions that were not meant to be in the pipeline, ignoring the jump instruction. Thus, as a countermeasure, we added a further condition: if an error happens in a pipeline stage processing an instruction that will be discarded due to a jump being processed in the EX stage, we do not initiate the rollback procedure.

## IV. EXPERIMENTAL RESULTS

### A. Experimental setup

The open-source 32-bit RISC-V processor [9] consists of a standard 5-stage pipeline, i.e., Instruction Fetch (IF), Instruction Decode (ID), EXecute (EX), MEMory (MEM), Write-
Back (WB), including a forwarding mechanism, a hardware multiplier in its execution stage, and a Register File (RF) with 32 registers in the write-back stage.

<figure><img src="image_4.png" /><figcaption>Fig. 4. RISC core with 5-stage pipeline, forward mechanisms, and data and instruction caches [9].</figcaption></figure>

We perform Fault Injection (FI) experiments on four benchmarks, i.e., Matmult, Qsort, Gaussian Filter, Moving Average. We compare the FI results of three different configurations i) PSRR ii) FSR iii) the unprotected RISC-V. The FI campaign is achieved through a FI tool using a cycle-accurate bit-accurate (CABA) simulator for PSRR, FSR and the unprotected RISC-V processor versions. Prior to any fault injection, we execute the benchmark under study, without faults, in order to obtain a set of golden references: i) the application output, ii) the system state (processor registers), and iii) the number of cycles required for the execution of the application. Then, the core simulator executes the benchmark and injects faults to the registers, while the benchmark runs. The cycle to inject the faults is chosen randomly between the first cycle and the total number of cycles needed for the fault-free execution. The fault injection location is selected randomly following a uniform distribution. The injected fault is a bit-flip. After the fault injection and upon benchmark termination, the results are compared to the golden references, and the impact of faults is categorized as follows:

* Execution Cycles Mismatch (ECM): the execution cycles are different from those of the golden reference.

* Hang (H): the execution time of the application has exceeded a waiting threshold, and thus, it is assumed that it has entered an infinite loop. For these experiments, we set the threshold to eight times the golden number of cycles.

* Crash (C): the execution of the application has terminated unexpectedly and an exception has been thrown (out of bound memory access, misaligned PC, hardware trap, etc.)

* Application Output Mismatch (AOM): the application output is different from the golden reference.

* Internal State Mismatch (ISM): The system state (processor registers) are different from the golden reference.

* Functionally Masked (FM): The application has finished execution, with no difference w.r.t. the golden application.

In order to evaluate the proposed approaches, we follow the statistical fault injection approach [17] for each bench-

mark and processor version. The number of injected faults needed to obtain statistically meaningful results is given by $fault_injections = \frac{N}{1+e^2 \times \frac{N-1}{t^2 \times 0.25}}$, where N is the number of possible injection points (pipeline register bits × clock cycles), e is the desired error margin (1%), and t depends on the desired confidence level (t=3.1 for 99.8% confidence level). This leads to 25,000 injections per benchmark and processor version, giving a total of 300,000 injections.

## B. Results

The Table IV shows the vulnerability metrics obtained by the FI campaign for the unprotected version and the two proposed DCLS mechanisms. The injected fault impacts significantly the unprotected processor, compared to the protected versions. When the fault is not masked, usually the application ends, but produces incorrect result (represented by the AOM). On the contrary, the DCLS RISC-V versions with the PSRR and FSM mechanisms are able to detect and correct the error.

<table><caption>TABLE IV
VULNERABILITY METRICS</caption><thead><tr><th>Benchmark</th><th>AOM</th><th>ECM</th><th>ISM</th><th>Crash</th><th>Hang</th></tr></thead><tbody><tr><td colspan="6"><strong>Unprotected version</strong></td></tr><tr><td>Matmult</td><td>2,977</td><td>1,466</td><td>1,093</td><td>566</td><td>609</td></tr><tr><td>Qsort</td><td>930</td><td>1,687</td><td>1,451</td><td>737</td><td>629</td></tr><tr><td>Gaussian Filter</td><td>2,359</td><td>1,209</td><td>768</td><td>423</td><td>497</td></tr><tr><td>Moving Average</td><td>2,867</td><td>1,454</td><td>908</td><td>507</td><td>517</td></tr><tr><td colspan="6"><strong>PSRR mechanism</strong></td></tr><tr><td>Matmult</td><td>0</td><td>18,165</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Qsort</td><td>0</td><td>18,412</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Gaussian Filter</td><td>0</td><td>16,819</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Moving Average</td><td>0</td><td>17,568</td><td>0</td><td>0</td><td>0</td></tr><tr><td colspan="6"><strong>FSR mechanism</strong></td></tr><tr><td>Matmult</td><td>0</td><td>22,141</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Qsort</td><td>0</td><td>20,015</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Gaussian Filter</td><td>0</td><td>18,034</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Moving Average</td><td>0</td><td>18,948</td><td>0</td><td>0</td><td>0</td></tr></tbody></table>

A fault may significantly impact the timing behavior of the application, as highlighted by the number of ECM observed during the FI campaign in Table IV. For the unprotected version, the timing impact of the fault may be unpredictable, jeopardizing the timing bounds computed considering a fault-free system. Table VI depicted the maximum number of clock cycles when an ECM occured. For instance, for the Gaussian Filter the maximum observed cycles is 350,636, whereas the fault-free execution is 59,084 cycles, which is almost 6× more. On the contrary, the proposed DCLS approaches bound the timing impact of the fault by detecting and correcting with a bounded overhead. From the experimental result, we have verified that the time to perform error detection and correction with FSR mechanism is constantly two execution cycles, whereas with the PSRR mechanism is bounded by 5 clock cycles. Note that, the ECM value of Table IV highlights how many times the proposed mechanisms have performed a rollback. The ECM difference between PSRR and FSR is the result of the selective protection of the PSRR, which performs
rollback from a mismatch, only if the value is going to be used.

<table><caption>TABLE V
ERROR DETECTION AND CORRECTION OVERHEAD</caption><thead><tr><td>Approach</td><td>Max cycles observed</td><td>Additional bits</td></tr></thead><tbody><tr><td>PSRR</td><td>5</td><td>160</td></tr><tr><td>FSR</td><td>2</td><td>716</td></tr></tbody></table>

Table V also shows the area overhead per protection mechanism. With the PSRR mechanism, we have achieved similar results compared to the FSR one, with lower area overhead.

<table><caption>TABLE VI
ECM VALUE FOR UNPROTECTED VERSION</caption><thead><tr><td>Benchmark</td><td>Max cycles observed</td><td>Baseline cycle</td></tr></thead><tbody><tr><td>Matmult</td><td>82,859</td><td>12,887</td></tr><tr><td>Qsort</td><td>33,125</td><td>4,429</td></tr><tr><td>Gaussian Filter</td><td>350,636</td><td>59,084</td></tr><tr><td>Moving Average</td><td>38,962</td><td>10,314</td></tr></tbody></table>

<table><caption>TABLE VII
PER PLACE IMPLICATION, NO PROTECTION</caption><thead><tr><th rowspan="2">Benchmark</th><th rowspan="2">Error Type</th><th colspan="4">Pipeline register (%)</th></tr><tr><th>FtoDc</th><th>IDtoEX</th><th>ExtoMem</th><th>MemtoWb</th></tr></thead><tbody><tr><td rowspan="6">Matmult</td><td>AOM</td><td>18.61</td><td>34.53</td><td>14.58</td><td>10.14</td></tr><tr><td>ISM</td><td>14.64</td><td>21.41</td><td>7.50</td><td>4.85</td></tr><tr><td>ECM</td><td>23.47</td><td>36.43</td><td>13.23</td><td>8.66</td></tr><tr><td>HANG</td><td>10.67</td><td>14.45</td><td>2.46</td><td>0.49</td></tr><tr><td>CRASH</td><td>13.07</td><td>30.74</td><td>8.30</td><td>4.06</td></tr><tr><td>Qsort</td><td>20.22</td><td>33.98</td><td>13.87</td><td>6.13</td></tr><tr><td rowspan="6">Gaussian Filter</td><td>AOM</td><td>13.71</td><td>28.46</td><td>14.40</td><td>8.06</td></tr><tr><td>ISM</td><td>21.64</td><td>37.05</td><td>16.54</td><td>7.94</td></tr><tr><td>ECM</td><td>9.38</td><td>23.37</td><td>8.90</td><td>6.20</td></tr><tr><td>HANG</td><td>12.21</td><td>38.94</td><td>15.06</td><td>5.70</td></tr><tr><td>CRASH</td><td>19.92</td><td>39.38</td><td>12.80</td><td>4.92</td></tr><tr><td>Moving Average</td><td>15.10</td><td>17.32</td><td>4.43</td><td>4.95</td></tr><tr><td rowspan="6"></td><td>AOM</td><td>15.20</td><td>24.32</td><td>41.85</td><td>11.00</td><td>4.05</td></tr><tr><td>ISM</td><td>10.46</td><td>13.08</td><td>1.41</td><td>0.4</td><td>0.4</td></tr><tr><td>ECM</td><td>14.89</td><td>31.91</td><td>15.37</td><td>1.65</td><td>1.65</td></tr><tr><td>HANG</td><td>19.99</td><td>38.47</td><td>12.98</td><td>8.06</td><td>6.06</td></tr><tr><td>CRASH</td><td>15.20</td><td>18.94</td><td>7.38</td><td>6.06</td><td>6.06</td></tr><tr><td>FSR</td><td>23.04</td><td>37.48</td><td>14.31</td><td>9.35</td><td>9.35</td></tr><tr><td rowspan="6"></td><td>AOM</td><td>10.25</td><td>8.90</td><td>1.55</td><td>1.16</td><td>1.16</td></tr><tr><td>ISM</td><td>12.62</td><td>38.86</td><td>11.64</td><td>2.76</td><td>2.76</td></tr><tr><td>ECM</td><td>350,636</td><td>59,084</td><td>4,429</td><td>10,314</td><td>10,314</td></tr><tr><td>HANG</td><td>10.67</td><td>14.45</td><td>2.46</td><td>0.49</td><td>0.49</td></tr><tr><td>CRASH</td><td>13.07</td><td>30.74</td><td>8.30</td><td>4.06</td><td>4.06</td></tr><tr><td>FSR</td><td>2</td><td>716</td><td>4,429</td><td>10,314</td><td>10,314</td></tr></tbody></table>

Furthermore, the participation of each faulty pipeline register in each observed vulnerability class is shown in Table VII. For instance, for the Gaussian Filter, 1,209 injections have produced ECM, and 41.85% of the 1,209 (which corresponds to 506 injections) the injection occurred in the IDtoEX pipeline register. We notice also the the IDtoEX has a higher implication to the different error types.

## V. CONCLUSION

This work focuses on critical systems that require high reliability and real-time execution, such as aerospace and defense systems, automotive, medical devices. Two fine-grained lockstep designs have been proposed for a RISC-V architecture using high-level specification language. Note that, the use of RISC-V architecture provides an open-source and customizable solution, which, along with HLS, allow the

designers to quickly obtain reliable processors that can also be adapted to suit different reliability and timing needs, even for fine-grained intrusive approaches. The proposed mechanisms are based on shadow registers and rollback and ensure the correct execution of instructions by comparing the results of two identical processors at the end of each clock cycle. The mechanisms have been implemented and evaluated using a FI tool based on a CABA simulator and the results showed that they are able to quickly detect and correct errors with bounded performance overhead, whereas the consistency check is being done in parallel to the pipeline normal execution flow. Especially the PSRR approach has showed to be effective for dependable system while providing significant low area overhead compared to a TMR version.

Our future work directions include the implementation of the proposed DCLS designs on a FPGA and perform FI and extend the proposed approaches for Multiple Bit Upset (MBU).

## ACKNOWLEDGMENT

This work has been funded by the French National Research Agency (ANR) through the FASY research project (ANR-21-CE25-0008).

## REFERENCES

[1] S. Skalistis et al., “Timely fine-grained interference-sensitive run-time adaptation of time-triggered schedules,” in IEEE RTSS, 2019.

[2] A. Dixit et al., “The impact of new technology on soft error rates,” in Int. Reliability Physics Symp., Apr. 2011, pp. 5B.4.1–5B.4.7.

[3] S. Rehman et al., Reliable Software for Unreliable Hardware: A Cross Layer Perspective. Springer Publishing, 2016.

[4] F. Catthoor et al., “Will chips of the future learn how to feel pain and cure themselves?” IEEE Design & Test, vol. 34, no. 5, pp. 80–87, 2017.

[5] S. Hamdioui et al., “Reliability challenges of real-time systems in forthcoming technology nodes,” in IEEE/ACM DATE, March 2013, pp. 129–134.

[6] M. Cui et al., “Fault-tolerant mapping of real-time parallel applications under multiple dvfs schemes,” in IEEE RTAS, 2021, pp. 387–399.

[7] C. Hernandez et al., “Timely error detection for effective recovery in light-lockstep automotive systems,” IEEE TCAD, vol. 34, no. 11, pp. 1718–1729, 2015.

[8] J. Abella et al., “Security, reliability and test aspects of the risc-v ecosystem,” in IEEE ETS, 2021, pp. 1–10.

[9] S. Rokicki et al., “What you simulate is what you synthesize: Designing a processor core from c++ specifications,” in IEEE/ACM ICCAD, 2019, pp. 1–8.

[10] A. B. de Oliveira et al., “Lockstep dual-core arm a9: Implementation and resilience analysis under heavy ion-induced soft errors,” IEEE TNS, vol. 65, no. 8, pp. 1783–1790, 2018.

[11] J. Yao et al., “Dara: A low-cost reliable architecture based on unhardened devices and its case study of radiation stress test,” IEEE TNS, vol. 59, no. 6, pp. 2852–2858, 2012.

[12] M. T. Sim et al., “A dual lockstep processor system-on-a-chip for fast error recovery in safety-critical applications,” in IEEE IECON, 2020, pp. 2231–2238.

[13] J. Li et al., “Duckcore: A fault-tolerant processor core architecture based on the risc-v isa,” Electronics, vol. 11, no. 1, 2022.

[14] L. Blasi et al., “A RISC-V fault-tolerant microcontroller core architecture based on a hardware thread full/partial protection and a thread-controlled watch-dog timer,” in APPLEPIES, 2019, pp. 505–511.

[15] A. E. Wilson et al., “Neutron radiation testing of fault tolerant risc-v soft processor on xilinx sram-based fpgas,” in IEEE SCC, 2019, pp. 25–32.

[16] D. A. Santos et al., “A low-cost fault-tolerant risc-v processor for space systems,” in DTIS, 2020, pp. 1–5.

[17] R. Leveugle et al., “Statistical fault injection: Quantified error and confidence,” in IEEE/ACM DATE, 2009, pp. 502–506.