Sistemas informáticos

Comparing Figure 5.3 and Figure 5.5, and the detailed hardware modifications listed in Section 5.3.3 and Section 5.4.3, one observes that end-to-end signature checking and end-to-end residue checking implementations have pretty much the same hard- ware requirements. Therefore, we adopt the end-to-end residue checking design and propose to merge the calculated signatures attached to values with the residue values flowing through the backend of the processor.

We share the hardware infrastructure and amortize costs for implementing both error detection techniques simultaneously: we encode a new residue value that is a function of the original residue and the signature of the destination register. Similarly, each encoded residue value is decoded back to the original residue using the signature of the corresponding source (obtained at rename time).

74

·

Chapter 5. Register Dataflow Validation From RF (source 2) Execution port ok? From RF (source 1) From Bypasses From Bypasses Data

Opcode Tag comparison

1 2 To RF (write-back) T o B y p a s s e s T o B y p a s s e s Destination Tag RA’ RB’ Residue check Sign(Src1) Sign(Src2) Sign(Dst) È È RA RB RO RO’ È È È È

Fig. 5.6: Combined end-to-end signature and residue checking scheme: extensions in the backend logic (added hardware is shown colored)

The transformation function must be easy to implement. Besides, it has to be possible to construct the inverse function, so residues can be recovered. An extremely simple and fast function of this type is the bitwise XOR function (whose inverse func- tion is also the XOR function). For example, given a residue of 01 and a destination signature of 11, a XOR-based encoding will forward a transformed residue value of 10 to the register dataflow paths. Reversely, given a transformed residue value of 10 and a source signature of 11, a XOR-based decoder will provide an original residue value of 01.

For those functional units implementing a concurrent residue functional unit, there is no need to keep the signature comparators. Specifically, we leave the residue checkers and remove the signature checkers. The rationale is that if there is an error in any of the different end-to-end paths that we protect, we will not be able to decode a correct residue, and the residue checker will suffice to flag that an error has

5.4. End-to-End Register Value and Dataflow Validation

·

75 been detected. Conversely, for those functional units lacking residue functional units, we need residue generators for each incoming source operand value and a residue comparator for each incoming source residue value (after it has been decoded back using the expected signature). A residue generator for the produced value will also be needed.

Special attention must be paid to execution ports lacking ALUs. For example, the store data execution unit may just access the register file and write back the value and transformed residue value into the Load-Store Queue. In that possible scenario, we must extend these execution ports with residue decoders, in order to obtain the real residue (not the transformed one). It will be the residue generators and checkers of the consuming execution ports that will detect a possible failure at retire time, increasing the failure coverage therefore.

The whole encode/decode process is depicted in Figure 5.6. When an instruction is executed it writes back Data into the register file. Then, its residue Ro is XOR-ed with the destination signature Sign(Dst) of the instruction writing back (assigned at rename time). This encoded residue Ro’ will be written back into the register file and will travel through the bypass network together with its associated data.

A consumer instruction requires the correct signature to retrieve the original residue Ro. Consumers use the signatures received from the rename stage (Sign(src1) for the left operand and Sign(src2) for the right one) to decode the input residues (R′

A and RB′ ). If an error happens in the dataflow, the decode process will generate an incorrect residue. If an error in a data value happens, the residue decoders will obtain a residue that does not correspond to the expected for the the wrong input value, and the residue checker will detect the error.

When combining the signatures with the residues, the implementation of the spoil circuits (needed to protect the load replay system, as described in Section 5.3.1) also changes. Instead of corrupting the destination signatures, we corrupt the residues. We spoil residues by using the invalid residue value 11: residue functional units are modified so that when one of the sources is this invalid value, the output will also be the invalid residue. This way all instructions depending on the missing load will observe a wrong output residue.

5.4.3 Microarchitectural Changes

Assuming we need R bits per residue and B bits per signature, and being K = max(R, B), the mechanism requires the following hardware modifications:

76

·

Chapter 5. Register Dataflow Validation

• Allocation stages. Same as for our signature checking scheme (Section 5.3.3). • Issue queue. Same as for our signature checking scheme (Section 5.3.3). • Register files. Additional space to store per each register its transformed

residue (K bits per register).

• ROB. Same as for our signature checking scheme (Section 5.3.3).

• Bypass network. Additional wires to carry the transformed residue of each value (K bits per value). In addition, wider input multiplexors to obtain the proper transformed residue per operand are required.

• Execution units. For every functional unit, we need a signature decoder L for each source operand so that its transformed signature can be converted into a residue (two XOR functions operating on K bits each). In addition, for every functional unit, a residue unit that operates with these incoming residues, a residue generator for the produced value by the functional unit, and a residue checker that validates (compares) both redundantly generated residues.

For each execution unit that cannot operate with the incoming residues (no residue functional unit implemented), we need residue generators for the in- coming values, residue comparators (to compare against the pre-computed ones) and a residue generator for the produced value (if any). Note that this design does not need comparators for the source signatures.

Finally, a signature encoder L is also needed to encode the produced residue with the destination signature of the instruction being executed.

• Write-back network. Additional wires to carry the transformed residue of each value (K bits per value).

• Data cache. A residue generator for every load port.

• Replay Logic. Residue functional units are modified in such a way that when- ever they observe an invalid residue as an input, they produce an invalid residue as an output. For every data cache read port, we add a spoil circuit that pro- duces an invalid residue in case of a miss.

• Load-Store Queue. Additional space to store the residue for the data and address per entry (2 ∗ R bits per entry).

5.4. End-to-End Register Value and Dataflow Validation

·

77

Fig. 5.7: End-to-end signatures and residues operation: fault-free scenario example

In document PROGRAMA OPERATIVO DE BALEARES Objetivo: Competitividad Regional y Empleo FEDER INFORME DE EJECUCIÓN. Anualidad 2013 (página 102-107)