It was possible that the result of a store-conditional could get lost if it
did not depend on the result of the corresponding load-reserved.
This was because the MSHR does not update the client state based on the
secondary requests. So the LR would acquire the line in clientExcusiveClean,
but then we would fail to update the metadata array to change the state
to clientExclusiveDirty.
The solution is to track whether a secondary acquire would cause the
line to be dirty. If so, use M_XWR instead of the primary command to
generate the update coherence state.
The deadlock condition occurs when the acquire tracker attempts to
request a writeback while the writeback unit is still busy and a
voluntary release for the block to be written back is coming in.
The voluntary release cannot be accepted because it conflicts with the
acquire tracker. The acquire tracker can't merge the voluntary release
because it is waiting to send the writeback. The writeback can't
progress because the release it is waiting on is behind the voluntary
release.
The solution to this is to break the atomicity guarantee between the
acquire tracker and the writeback unit. This allows the voluntary
release tracker to take the voluntary release before the writeback unit
accepts the conflicting request. This causes a potential race condition
for the metadata array. The solution to this is to have the writeback
unit re-read the metadata after accepting a request.
* SimpleHellaCacheIF now properly handles both the non-blocking data
cache and blocking data cache.
* SimpleHellaCacheIF maintains ordering of replayed requests
* L2 VoluntaryReleaseTracker sends voluntary release grant properly
* Coherence protocols now downgrade for probeCopy
This addresses a bug in which changes in mstatus could
propagate to RoCCs before their time. Existing RoCCs that use
the status port will need to be modified to match this change.
This addresses the first half of #40.
