This reverts commit 8db5bbbae0.
This attempt at clarification instead results in confusing generated verilog like:
`dcache_data_arrays_0 icache_data_arrays_0 (...);`
because of deduplication of identically dimensioned SRAMs...
This fixes a deadlock (and possibly memory corruption, though that is
unconfirmed). The following sequence manifests it, assuming t0
is 32-byte aligned:
sw t0, 0(t0)
sw t0, 16(t0)
lw t1, 4(t0)
lw t2, 4(t0)
Since the correction updates the entire word, the WAW hazard detection
logic is not sufficient to prevent overwriting a recent store. So,
re-read the word after all pending stores have drained.
This assertion made sure the D$ controller was able to write the tag RAM
when a cache line was refilled. However, it is benign if it fails to do
so: the metadata is invalid at this point, so the miss will simply happen
a second time.
This happens when resolving a tag ECC error during hit-under-miss.
If the queue is not empty before a dirty miss, C could block D.
I haven't seen this in the wild, but it could happen because of
dirty probe responses backed up in the queue.
Don't examine a packet's xcpt signal if it might be invalid. In this case,
the correct fix is to not examine xcpt at all; the deleted code was vestigial.
(Note, the other use of xcpt(j+1) in this code is indeed safe.)
The following sequence would drop the first store when eccBytes=4:
sb x0, 0(t0)
nop
sb x0, 4(t0)
nop
sb x0, 1(t0)
Because the first and second store are to different ECC granules, the
hazard check correctly allowed the second one to proceed, but the third
was merged with the second, even though it conflicted with the first.
So, don't allow the third to be merged with the second, since the second
stored to a different ECC granule.
