2. RESUMEN DE LA EJECUCIÓN DEL PROGRAMA OPERATIVO
2.2. Información sobre conformidad con la legislación comunitaria
2.2.4. Reglas de competencia
it executes, it resolves the address and data, updating only the store queue. When a store commits (Figure 7.4(b)), it releases its entry in the store buffer, and fills an entry of the MOVT with its StID. Note that the MOVT works as a cache, and hence, if at commit time it does not keep an entry holding information for the store address, another entry will be used (either a free one or evicting one). Top of Figure 7.4(c) shows that after the store with age 5 committed, one younger store and two younger loads entered the pipeline and computed their effective address. Specifically, the figure shows that the store with age 6 (store 6) wants to update address 0xEF01 with data 0x0001, and the loads 7 and 8 will access addresses 0xABCD and 0xEF01, respectively. Bottom of Figure 7.4(c) reflects that a load can obtain its prodID either from the MOVT or from the store queue: load 7 obtains its prodID exclusively from the MOVT (because there is no older in-flight store to address 0xABCD), whereas load 8 obtains it from the store queue at execution time. As a result, load 7 will receive the StID from store 5, and load 8 will get it from store 6. When a load commits, it releases the entry in the load queue and compares the prodID value with the corresponding StID in the MOVT. Figure 7.4(d) shows that after store 6 commits, load 7 hits the MOVT when committing and checks its prodID.
7.4.4 Failure Recovery
We rely on flushing the pipeline to restore correct state in the event of an error detection. This mechanism is already used to handle the recovery of wrong memory ordering detection in the load-store queue, or to handle branch misprediction recovery. By flushing the pipeline we can recover from multiple sources of failures. Re- execution will start from the offending load, and therefore, since the pipeline and MOVT will be empty, the load will go directly to cache and bypass the LSQ logic.
For permanent / intermittent faults, we would like to disable/replace the affected hardware to avoid performance overheads when exercising a fault repeatedly. How this is done is out of the scope of this thesis. The real challenge is indeed locating the fault and diagnosing it, so that (i) the repair and reconfiguration mechanism can be conducted and (ii) to help validators understand the reason behind the recovered error. The diagnosis of failures in the LSQ will be covered in Chapter 8.
7.5 Design #1: MOVT Access at Execute
In this section we describe an implementation of the general design proposed in Section 7.4, that performs the prodID acquisition during load execution. This means
146
·
Chapter 7. Memory Flow Validation Load Queue Store Queue Format Data To D$ From D$ St-ld frwd? Data Data Address Ld Producer Info Match? To RF MOVT Data PROD StID StID StID AddressFig. 7.5: MOVT hardware for design #1: prodID acquisition at execute time
that after a load has resolved its effective address, it will access the MOVT in order to obtain its producer StID.
ProdID Acquisition
Figure 7.5 shows how the prodID acquisition works in the execute stage. Once a load is issued, a regular LSQ would access the data cache and perform an associative search in the store queue looking for possible producers. The particularity of this design is that the load also accesses (in parallel) the MOVT. If there is no forwarding from the store queue, the prodID field of the executing load is filled with the StID obtained from the MOVT.
In case a load does not find a matching store either in the store queue or in the MOVT at execution time, its prodID field is updated with a special NULL value.
Validating Memory Ordering
When loads commit, they check the MOVT to see if there is information of the producer (store instruction) that produced their data. In the best case, the load will hit in the MOVT and will find the StID of the store that produced the data.
7.5. Design #1: MOVT Access at Execute
·
147 Table 7.1: Protocol when loads hit the MOVT at commit time (Design #1)prodID match? bit Action
VALID N/A Check
NULL N/A Fix
Table 7.2: Protocol when loads miss the MOVT at commit time (Design #1)
prodID match? bit Action
N/A Set Fix
N/A Unset None
However, due to the limited space of the MOVT it may happen that a later store evicted the information.
Table 7.1 shows the different actions taken when loads effectively hit in the MOVT at commit. Notice that the match? bit is not important in this first case:
(i) The prodID field holds a valid StID if the load hit in the MOVT at the execute stage or obtained it through forwarding. We compare the StID stored in the prodID and the StID obtained from the MOVT. A mismatch indicates an error. (ii) It may happen that the load missed in the MOVT at execute time. This means that the load checked the stores in the store queue and the MOVT without finding any match. If that is the case, the prodID field would have the NULL special value. At commit time, the MOVT holds a subset of the information stored in the MOVT and store queue at execute time. Therefore, a load that hits at commit time can only correspond to a failure. The load should have obtained a StID during execution, either through store-to-load forwarding case or through the corresponding entry in the MOVT.
Due to address aliasing, entries from the MOVT may be evicted, or some memory locations may have never been accessed by a store. As a consequence, some loads may miss in the MOVT at commit time when they check whether the StID they carry in the prodID is correct. Table 7.2 shows the different scenarios:
(iii) If the match? bit is set, it means that the store producing the data is very close. Thus, we would expect the load to hit when accessing the MOVT table. However, it is possible that a forwarded load misses in the MOVT, because the producer store could be evicted.
We observe that such scenario when a load misses the MOVT after getting the value through forwarding is very rare because most of the store-load matching
148
·
Chapter 7. Memory Flow Validationpairs are close to each other. Therefore, we consider this scenario as suspicious of a potential error and apply the correction mechanism conservatively (flush the pipeline and restart execution).
(iv) If match? bit is unset, the most likely situation is one where it was not for- warding store. In that case, the behavior would be correct in most of the cases. However, it may be the rare case where there was a forwarding store which was not identified by the LSQ logic, the store updated the MOVT and that entry was evicted later on. As mentioned, the case where a load gets the data through forwarding and does not hit in the MOVT is very unlikely. Therefore, we opt for ignoring this case (at the expense of coverage), and no action is taken.
Potential Issues
For this implementation, the MOVT is accessed simultaneously from two different pipeline stages (the commit stage and the execute stage).
One of the possible problems with this approach is that depending on the proces- sor layout it may be hard to accommodate the MOVT accesses within the existing processor timing restrictions. For some designs, if the ROB and LSQ are distant in the processor die, design efforts would be required to implement the technique. In Section 7.6 and Section 7.7 we explore two designs to alleviate this potential difficulty.