For REQUESTs, L1ProcessTagReq first checks the tag in the tag array and in the outstanding MSHRs by calling notpres_mshr.
Step 1: Calling notpres_mshr
For a REQUEST, notpres_mshr first checks to see if the request has a tag that matches any of the outstanding MSHRs. Additionally, the notpres function is called to determine if the desired line is available in the cache. If the line is not present in any MSHR, the coherence routine for the cache ( cohe_pr for L1, cohe_sl for L2) is called to determine the appropriate actions for this line, based on whether or not the line is present, the current MESI state of the line in cache, and the type of cache.
Step 1a: Behavior of notpres_mshr when REQUEST does not match MSHR
If the REQUEST being processed does not match an outstanding MSHR, the operation of notpres_mshr depends on whether or not the line hits in the cache and the state of the line.
If the line being accessed hits in the cache in an acceptable state,
this request will not require a request to a lower module. As a
result, the cache will return NOMSHR, indicating that no MSHR
was involved or needed in this request
.
If the request goes to the next level of cache without taking an MSHR at this cache level (either by being a write in a write-through cache or an L2 prefetch), the value NOMSHR_FWD is returned to indicate that no MSHR was required, but that the request must be sent forward.
If the request needs a new MSHR, but none are available, the value NOMSHR_STALL is returned. In the case of the L2 cache, a request that is not able to reserve a space in the write-back buffer leads to a NOMSHR_STALL_WRBBUF_FULL return value.
Otherwise, the cache books an MSHR and returns a response based on whether this access was a complete miss (MSHR_NEW) or an upgrade request (MSHR_FWD). In the case of upgrades, the line is locked into cache by setting mshr_out; this guarantees that the line is not victimized on a later REPLY before the upgrade reply returns. In all cases where the line is present in cache, the hit_update function is called to update the ages of the lines in the set (for LRU replacement).
Step 1b: Behavior of notpres_mshr when REQUEST matches MSHR
On the other hand, if the REQUEST matches a current MSHR, the operation of notpres_mshr depends on the type of the REQUEST and the previous accesses to the matching MSHR.
If the access is a shared prefetch or an exclusive prefetch to an MSHR returning in exclusive state, the prefetch is not necessary because a fetch is already in progress. In this case, this function returns MSHR_USELESS_FETCH_IN_PROGRESS to indicate that the REQUEST should be dropped.
If the access is an L2 prefetch or an exclusive prefetch in the case of a write-through L1 cache, the REQUEST should be forwarded around the cache. In this case, the function returns NOMSHR_FWD. If the request was an exclusive prefetch, it is converted to an L2 exclusive prefetch before being forwarded around the cache.
In certain cases, the REQUEST may need to be stalled.
Possible scenarios that can result in stalls and the values they
return are as follows. If the MSHR is being temporarily held for a
write-back, notpres_mshr
returns MSHR_STALL_WRB. If the MSHR is marked with an
unacceptable pending coherence message, the function returns
MSHR_STALL_COHE. If the MSHR already has the
maximum number of coalesced REQUESTs for an MSHR, the
return value is MSHR_STALL_COAL. The maximum number of
coalesced accesses is a configurable parameter.
Finally, when a write (or exclusive prefetch) REQUEST comes to
the same line as an MSHR held for a read (or shared prefetch)
REQUEST, the value MSHR_STALL_WAR is returned. This last case
can significantly affect the performance of hardware
store-prefetching, and is called a WAR stall. The impact of WAR stalls can be reduced through software prefetching, as
an exclusive prefetch can be sent before either the read or write
accesses [15, 16].
If the access was not dropped, forwarded, or stalled, it is a valid access that can be processed by merging with the current MSHR. In this circumstance, the cache merges the request with the current MSHR and returns MSHR_COAL.
Step 2: Processing based on the results of notpres_mshr
L1ProcessTagReq continues processing the REQUEST based on the return value of notpres_mshr.
For a hit (NOMSHR), the request is marked as a hit and returned to the processor through the GlobalPerformAndHeapInsertAllCoalesced function.
For new misses (MSHR_NEW), upgrades (MSHR_FWD), or write-throughs (NOMSHR_FWD), the cache attempts to send the request down, returning a successful value if the request is sent successfully.
For MSHR_COAL, the element is considered to have been processed successfully.
On MSHR_USELESS_FETCH_IN_PROGRESS, the request is dropped.
For each of the stall cases, the processing is generally considered incomplete, and the function returns 0 to indicate this. However, if the stalled request is a prefetch and DISCRIMINATE_PREFETCH has been set with the ``-T'' option, the request is dropped and processing is considered successful. Note that DISCRIMINATE_PREFETCH cannot be used to drop prefetches at the L2 cache, as these prefetches may already hold MSHRs with other coalesced requests at the L1 cache.