Step 1: Checking status of MSHR entry
For a REPLY, the function L1ProcessTagReq uses the FindInMshrEntries function to find the MSHR number corresponding to the REPLY.
If there is no MSHR entry for the REPLY, then it must be a response to a non-allocated write or to an L2 prefetch REQUEST. For such a REPLY, GlobalPerformAndHeapInsertAllCoalesced should be immediately called. This function calls the GlobalPerform function for the corresponding REQUEST and any other REQUESTs that may have coalesced with this REQUEST at the write-buffer or L2 cache, while also inserting the REPLYs into the MemDoneHeap described in Section 11.
Step 2: Processing REPLYs that match an MSHR
If the REPLY matches an MSHR, the function GetCoheReq is used to determine if any coherence message coalesced into the MSHR while it was outstanding. If so, any possible effects of this coherence message will be processed along with the REPLY.
Step 2a: Processing upgrade REPLYs
For upgrades, the REPLY handler calls the cache's coherence routine to determine the final state of the cache line. If any writes are present in the MSHR for the cache line and the state of the line is exclusive, the state changes to modified. If a COHE was merged into the MSHR, its effect on the cache line state is now carried out. (Note: no coherence message that requires a copyback or cache-to-cache transfer will ever merge into an MSHR, as discussed in Section 13.3.3.)
Step 2b: Processing cache miss REPLYs
For cache misses (REPLYs other than upgrades), the REPLY handler calls either premiss_ageupdate or miss_ageupdate based on whether or not the line is a ``present miss'' (a line whose tag remains in cache after a COHE, but is in an INVALID state).
If the line is
not a ``present miss'', the miss_ageupdate function tries to find a
possible replacement candidate. If any set entry is INVALID,
this line is used so as to avoid replacement. If a line must be
replaced, then the least-recently used SH_CL line is used; if
none is available, the least-recently used PR_CL or, finally,
PR_DY line is used
.
If no victim is available because all lines in the set have upgrades pending, the REPLY is not taken and a message needs to be sent back to the sender. This is done in the NackUpgradeConflictReply function. This function uses the MSHR allocated reserved by the REQUEST corresponding to this rejected REPLY as a resource from which to issue the new message. This resource is added to the smart MSHR list simulator abstraction (discussed in Section 13.2).
For REPLYs that do find a space in which to insert the new line, the cache's coherence routine is called to determine the state for the new line being brought in. If any writes are present in the MSHR for the cache line and the state of the line is exclusive, the state changes to modified. If a COHE was merged into the MSHR, its effect on the cache line state will also be carried out.
If this line replaces a current line, the cache's coherence routine is called to determine any possible requests that must be sent as a result. If the variable blw_req_type is set, a writeback must be sent as a result of this replacement (occurs if the victim had been in modified state). In this case, the GetReplReq function must be called to create a write-back message. This function sets up all the fields for a new message that writes back the line being replaced. This new write-back message is sent out in Step 3.
Step 3: Returning replies to processor
Regardless of REPLY type processed, the system now prepares to remove the corresponding entry from the MSHRs.
If some non-MSHR accesses (L2 prefetches, writes with a write-through cache) are also coalesced with the reply, the function GlobalPerformAndHeapInsertAllCoalescedWritesOnly or GlobalPerformAndHeapInsertAllCoalescedL2PrefsOnly is called to provide replies all of them to the processor.
Then, MSHRIterateUncoalesce is called, passing through all the responses coalesced into the REPLY and the MSHR itself and informing the processor of these.
If this reply does not cause a write-back, its MSHR is freed. Otherwise, the MSHR is temporarily used as storage space for the write-back, and will be thus held until the write-back is able to issue from the MSHR to the next level of cache. As with other resources held to issue messages to the ports, the MSHR is added to the smart MSHR list.
L1ProcessTagReq does not currently account for cache fill time.