# Proposal of an Adaptive Fault Tolerance Mechanism to Tolerate Intermittent Faults in RAM
## 4 Assessment of the Adaptive Fault Tolerance Mechanism
### Analysis of System Overhead  
In this section, we analyze the overhead from two points of view. First, we compare the temporal overhead of the two versions of Plasma_ADAPTIVE core (i.e., the static version, synthesized in a non-reconfigurable FPGA and the dynamic version, synthesized in a reconfigurable FPGA) by comparing their latencies. Moreover second, we have synthesized three cores: Plasma, Plasma_SEDED and both versions of the Plasma_ADAPTIVE in the two FPGAs, and compared their hardware overhead. We have included the Plasma_SEDED core (which implements an SEC-DED code and performs write-back on correction) for comparison purposes only, as it is an intermediate design between the non-fault-tolerant Plasma and the adaptive Plasma_ADAPTIVE proposed. Regarding the temporal overhead, we can classify system latencies in two groups: (i) detection and recovery latencies of transient errors, and (ii) reconfiguration latencies after intermittent error detection. Detection and recovery latencies do not depend actually on the AFT mechanism, but on the fault conditions (that is, on the fault model and timing) and on the average time that the target is accessed by the workload. Thus, it is very difficult to get a representative trend. Reconfiguration latencies, instead, do depend strongly on the actions taken by the AFT mechanism once an intermittent fault is detected. In this way, the reconfiguration latency of the static version of Plasma_ADAPTIVE core is:  
\[\mathfrak{t}_{\text{reconfiguration}}=(2\text{W}+2)\times\text{T}, \tag{7}\]  
where W is the size of the memory in (39-bit) words, and T is the clock cycle. This value comes from the sum of the duration of the following actions:  
* Switching the \"ECC Encoder\" (one clock cycle, as explained in Section 3.2), which corresponds to step 1 of the reconfiguration algorithm, is described in Section 3.1;
* Scrubbing the memory (two clock cycles per memory address; in total, \(2\times\text{W}\) clock cycles), which corresponds to step 2;
* Switching the \"ECC Decoder\" and the \"Error Manager\" (one clock cycle) of step 3. Hence, switching the ECC encoder and decoder is relatively fast and independent of the memory size (W). The highest temporal cost is due to the scrubbing, which is directly proportional to W. For the case study presented, where T = 100 ns and W = 512, we have \(\mathfrak{t}_{\text{reconfiguration}}(\text{static})=102.4\text{vs}\) (microseconds). In the dynamic version of Plasma_ADAPTIVE core, the reconfiguration latency is given by:  
\[\mathfrak{t}_{\text{reconfiguration}}=(2\text{W}+2)\times\text{T}+\mathfrak{ t}_{\text{e}}+\mathfrak{t}_{\text{d}}+\mathfrak{t}_{\text{m}}, \tag{8}\]  
where \(\mathfrak{t}_{\text{e}}\), \(\mathfrak{t}_{\text{d}}\) and \(\mathfrak{t}_{\text{m}}\) are the reconfiguration times of \"ECC Encoder\", \"ECC Decoder\" and \"Error Manager\" modules in the FPGA. The reconfiguration time of a module depends on the FPGA technology (i.e., the timing of the Processor configuration access port (PCAP) used to reconfigure the FPGA), the read timing from the \"Configuration ROM\", and the size of the bitstream file to be written. We can estimate with the following expression:  
\[\mathfrak{t}_{\text{reconf\_module}}=\frac{\text{M}}{\text{ROM}_{\text{ read\_rate}}}+\mathfrak{t}_{\text{PCAP\_init}}+\frac{\text{M}}{\text{PCAP}_{\text{transfer\_rate}}}, \tag{9}\]where M is the size of the bitstream file (in megabytes), \(\mathrm{t_{PCAP\_init}}\) is a fixed initialization delay of the port (in seconds), and \(\mathrm{ROM_{read\_rate}}\) and \(\mathrm{PCAP_{read\_rate}}\) are, respectively, the read from the ROM and write to the PCAP rates (in megabytes per second). Now, let us study the hardware overhead. All the three cores (i.e., Plasma, Plasma_SEDED and Plasma_ADAPTIVE) have been synthesized in two different types of device: in a non-reconfigurable FPGA and in a reconfigurable FPGA. We will calculate in each case the hardware required, the maximum operating frequency reached, and the power consumption.