# Proposal of an Adaptive Fault Tolerance Mechanism to Tolerate Intermittent Faults in RAM
## 4 Assessment of the Adaptive Fault Tolerance Mechanism
### Comparison with Other Proposals  
Table 3 shows a comparison of the two versions of our proposal with some of the previous works included in Section 2 applied to memories. In the table, besides the reference and a short description of the work, we have included aspects such as:  
* The _type of memory_ to which is applied. * How is the adaption _management implemented_ (hardware vs. software)? * The adaption _trigger_. * The list of _alternative ECCs_. * Do the alternative ECCs have the _same redundancy_? * Does the system _physically reconfigure_? That is to say, is the system reprogrammed/reconfigured, or are all the ECCs physically implemented in the system as spares? In the table, we can see that most proposals use ECCs with different redundancy. From these, in the ones where no physical reconfiguration is performed ([41, 42, 50] and the static version of our proposal), the encoding and decoding circuitry of all ECCs is physically implemented, increasing the hardware overhead. If we analyze the other proposal that keeps the redundancy [42], we realize that actually, only one code is implemented in the alternatives. The only difference between the alternatives is the decoding mode, being possible to opt between a simple and fast (although with fewer correction capability) mode and a higher correction capability mode (but more complex and slow). Analyzing the ECCs used, we utilize in our proposals two simple ECCs, while in most proposals in the table, other more complex ECCs (BCH [42, 50], OLSC [47, 48] or CLC [42]) are applied. The reason is mainly the fault hypothesis assumed. In our proposal, we assume that only single transient faults may occur until a single intermittent fault appears. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**Work** & **Description** & **Memory Type** & **Management Implementation** & **Trigger** & **Alternative ECCs** & **Same Redundancy?** & **Physical Economfiguration*** \\ \hline
[11] & Adaptive ECC for cache & SSAM & Hardware & Voltage scaling & 1-2, 4-bit PCI & No & No \\
[12] & CLC with low resolution mode & Undefined & Hardware & Decoding error & CLCS, CLC-E & Yes & No \\
[47] & Adaptive error correction & SRAM & Software & Voltage variation & SSC-DD, GLSC, Varying & No & Yes \\
[17] & scheme for cache & & & & & & \\
[8] & Adaptive error correction & & & & & & \\
[9] & Adaptive ECC for NAND flash & NAND- flash & Hardware & Bit error rate & Hamming, 2-, 4-bit PCI & No & No \\ Static & Static version & RAM & Hardware & Instrumented error & SSC-DD, EPS302 & Yes & No \\ Dynamic & Dynamic extension of & RAM & Hardware & Instrumented error & SSC-DD, EPS302 & Yes & Yes \\ Dynamic & Trans.ADAPTIVE & & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of the adaptive fault-tolerance (AFT) mechanism proposed with other previous works. Thus, we have selected two ECCS able to cope with these two fault hypotheses: the SEC-DED when only single transient faults occur, and the EPB3932 when an intermittent fault is detected. However, as mentioned in Section 3.3, this is only a case example, and other ECCs (either well-known or UEC evolved from traditional) could be used in the system. It just depends on the fault hypothesis. For instance, if the initial fault hypothesis is that double transient faults can occur before an intermittent fault appears, then:  
1. A 2-bit BCH could be used as the initial ECC. 2. It should swap to another (UEC) ECC able to support at least one intermittent error plus multiple (adjacent or random) additional errors. Compared with the proposals where physical reconfiguration is applied [47; 48], only our dynamic proposal is controlled by hardware, whereas in the others, reconfiguration is carried out by the operating system. Last but not least, the only proposals that trigger the system adaption by the detection of an intermittent error are our proposals.