This esoteric bug manifests if a tag-read error occurs when a FENCE.I is
executed, even if the error was correctable. Subsequently, an attempt to
flush a dirty line may flush the wrong line's data.
This esoteric bug manifests if a tag-read error occurs when a FENCE.I is
executed, even if the error was correctable. Subsequently, an attempt to
flush a dirty line may flush the wrong line's data.
We had planned for a while to add an 'Overwrite' message which obtains
permissions without requiring retrieval of data. This is useful whenever
a master knows it will completely replace the contents of a cache block.
Instead of calling it Overwrite, we decided to split the Acquire type.
If you AcquirePerm, you MUST Release and ProbeAck with Data.
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.
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.
Henry Cook
Andrew Waterman
Jacob Chang
Andrew Waterman
Gleb Gagarin
Wesley W. Terpstra