This is necessary to guarantee forward progress with RVC, since if the
BTB keeps mispredicting, the processor might never successfully
fetch both halves of a misaligned instruction.

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.

 * No need to check that release ID bits and acquire ID bits the same
 * Check that inner and outer coherence policies match

useful to have upstream so that tape-outs can construct
rocket-chip to have cores on different clocks without
forking rocket