Error detection by duplicated instructions in super-scalar processors

Abstract

This paper proposes a pure software technique, Error Detection by Duplicated Instructions (EDDI), for detecting errors during normal system operation. Compared to other error detection techniques that use hardware redundancy, our method does not require any hardware modifications to add error detection capability to the original system. In EDDI, we duplicate instructions during compilation and use different registers and variables for the new instructions. Especially for the fault in the code segment of memory, we have derived formulas to estimate the error detection coverage of EDDI using probabilistic methods. These formulas use statistics of the program, which are collected during compilation. We applied our technique to eight benchmark programs and estimated the error detection coverage. Then, we verified the estimates by simulations, in which a fault injector forced a bit flip in the code segment of executable machine codes. The simulation results validated the estimated fault coverage and show that approximately 1.5% of injected faults produced incorrect results in eight benchmark programs with EDDI, while on average, 20% of injected faults produced undetected incorrect results in the programs without EDDI. Based on the theoretical estimates and actual fault injection experiments, we show that EDDI can provide over 98% fault coverage without any extra hardware for error detection. This pure software technique is especially useful when designers cannot change the hardware system but they need dependability in the computer system. The Control Flow Checking by Software Signatures (CFCSS) technique can be used with EDDI to increase the fault coverage. In order to reduce the performance overhead, our technique schedules the instructions that are added for detecting errors such that Instruction-Level Parallelism (ILP) is maximized. We have showed that the execution time overhead in a 4-way super-scalar processor is less than the execution time overhead in the processors that can issue 2 instructions in one cycle.

Selective SWIFT-R

“…The so-called Software Implemented Hardware Fault Tolerance (SIHFT ) [25] techniques can be divided in two main categories according to the type of error they pretend to detect/correct: errors that may affect the control flow execution [26]; or errors that may affect the program data [27].…”

“…Some examples of these include ControlFlow Checking by Software Signatures (CFCSS ) [26], Assertions for Control Flow Checking (ACFC ) [28], Yet Another Control flow Checking Approach (YACCA) [29], and Control-flow Error Detection through Assertions (CEDA) [30]. Moreover, those approaches included in the second group are mainly based on the N-versions programming approach [31], which can be applied at different granularity levels: program [11,32], procedure [33], and the most commonly used, instruction level [27,[34][35][36].…”

“…Some of them apply redundancy to highlevel source code (e.g., C language) by means of automatic transformation rules [37], whereas others use instruction redundancy at a low level (assembly code) in order to reduce the code overhead and performance degradation, and improve detection rates [26,27,36]. Only a few of these techniques have been extended to allow system recovery, but they incur, as a consequence, in higher overheads in terms of code size and execution time [17,38].…”

“…Therefore, a fault injected in an unused register bit is considered as unACE because it does not affect the expected program output. This way of testing has been carried out by others researchers as well [26,27,36,17,37], which allows to obtain homogeneous result sets comparable to each other.…”

A Tunable, Software-Based DRAM Error Detection and Correction Library for HPC

“…EDDI [4] duplicates instructions and memory in the compiled form of an application in a manner similar to the source-to-source transformations, but achieves more support for programming constructs at the cost of platform dependence. Unlike the source-to-source transformations, EDDI compiles applications to binary form, redundantly executes all calculations, ensures separation between calculations by using differing memory addresses and differing registers, and attempts to order instructions to exploit super-scalar processor capabilities.…”