Hardware Module Implementation

PODER is composed of two separated implementations the software transformation implementation and the hardware module implementation. Both will be described in detail in the following. 

Table 4.5 shows the size and performance of the implemented processor and the hardware module. The hardware module implementation has a total of 128 registers. It was not protected against SEEs because of the fact that the worst case scenario is an incorrect fault detection, which would not compromise the system. The implemented hardware module occupies 15 % of the total area of the miniMIPS microprocessor, while maintaining the same operating frequency. It is important to note that the hardware module has a fixed size, independent of the processor being used. That means that a bigger processor would lead to a smaller hardware module percentage, when compared to the processor. 

The implementation of HETA consists of the hardware module implementation and the software transformation. We have used the miniMlPS mieroproeessor as platform to implement the technique. The following subsections describe the implementations required to harden two case-study applications with HETA. 

Hardware-based non-intmsive module an additional non-intrasive hardware module is added to the architecture. This module implements watchdog and decoder characteristics in order to analyze the processor s control flow and decode instmctions sent from the inserted software instmctions. 

The last kind of detection is the control flow loop (4). In order to detect this type of error, a watchdog timer is implemented. The counter is reset eveiy time the execution flow enters a BB, with the reset XOR instraction. When the counter overflows, an error is flagged. By doing so, the hardware module can detect a control flow loop that causes the execution flow to be stuck at a single instraction. 

In order to do the first, PODER has to implement three operations (1) send the BID value of the BB being executed to the hardware module, (2) store the CFID... 

Operations send BID and enqueue CFID ate implemented in assembly, by storing the BID or CFID value at given predefined memory addresses. By doing so, the hardware module can decode the store instmction and read the values from the memory buses. The operation dequeue CFID does not have to send ary data and therefore is performed by a store instmction with an unknown value to a given predefined memory address. 

The XOR value management also requires transformations in the program code. In order to do that, PODER implements another two operations, which are (4) reset the XOR value in the hardware module, and (5) compare a given XOR value with the one calculated at rantime by the hardware module. Operation (4) has to be performed in the beginning of the BB, like operations (1) and (2), while operation (5) has to be performed in the end of the BB, like operation (3). 

Both operations are implemented by using store instruction at predefined memory addresses. The only difference between them is that the check XOR has to send a value to the hardware module, so that it can compare to its calculated one, while the reset XOR is a simple store instruction with an irrelevant value. 

When combining all operations, one can notice that operations (1), (2), and (4) are performed in the beginning of the BB, while operations (3) and (5) are inserted in the end of the BB. In order to optimize the technique, we combine a few operations. The bottleneck in implementing these operations lays in the value that has to be sent to the hardware module, since only one value can be sent per instruction. The reset XOR does not have to send any data and therefore can be combined with the send BID or the enqueue CFID . The same applies to the dequeue CFID , which can be combined with the check XOR . The result of both techniques apphed to the same example code can be seen in Fig. 4.10. 

Hybrid Error-detection Technique using Assertions (HETA) is the third and final hybrid technique presented in this book. It was initially based in the CEDA software-based technique and its abiUty to efiSciently detect control flow errors between different BBs, and PODER and its ability to detect control flow errors inside the same BB. HETA is aimed at both FPGAs and ASICs, since it implements a non-intrasive hardware module combined with transformation rules on the program code. 

The hardware module was implemented in VHDL language, based on a timer that signals an error if not reset. To calculate the XOR value, we added a 16-bit accumulator register that performs a XOR operation between its current and new values so that it is not only able to calculate the real-time XOR value, but also to stores it. A decoder was also added to identify instructions from the software-based side. 

The hardware implementation has a total of 64 flip-flops. It is not protected against farrlts, since in the worst case seenario there will be only a false error detection. Table 4.10 shows the size and performance of the miniMlPS and the hardware module. As one can see, the hardware module has 11% of the area of the miniMlPS, while rrraintaining the same operation frequency. The hardware module is still smaller than PODER s, but shghtly bigger than the ones presented in OCFCM. 

Such results show that software-based techniques combined with HETA can be used in harsh environments and allow designers to reach fast fault diagnosis and correction. When comparing to hardware-based techniques, such as Xilinx Triple Modular Redundancy (XTMR) with scmbbing, that require modifications to the microprocessor s hardware, we can notice an area reduction higher than 66% and still acceptable fault coverage of 96.9%. On the other hand, the hardened application takes 1.48 times the original time to execute and 6.5 % more area to implement the OCFCM hardware module. 

The main idea of the methodology is to use link modules to make connections between measurements, logic modules and equipment. The link modules are parameterised with links to the hardware that implement that link, as hardware failures may cause the received value of a variable to be interpreted differently. 

---