dcache: Fix bug with dcbz closely following stores with the same tag

This fixes a bug where a dcbz can get incorrectly handled as an
ordinary 8-byte store if it arrives while the dcache state machine is
handling other stores with the same tag value (i.e. within the same
set-sized area of memory).  The logic that says whether to include a
new store in the current wishbone cycle didn't take into account
whether the new store was a dcbz.  This adds a "req.dcbz = '0'" factor
so that it does.  This is necessary because dcbz is handled more like
a cache line refill (but writing to memory rather than reading) than
an ordinary store.

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

diff --git a/dcache.vhdl b/dcache.vhdl
index 705393a5aab909e1b25bc86c6bd3afc53453d9d6..34dbda2cd2f4e4803090690499cd7fbdcdac3df2 100644 (file)
--- a/dcache.vhdl
+++ b/dcache.vhdl
@@ -1537,7 +1537,7 @@ begin
                             r1.wb.dat <= req.data;
                             r1.wb.sel <= req.byte_sel;
                         end if;
-                        if acks < 7 and req.same_tag = '1' and
+                        if acks < 7 and req.same_tag = '1' and req.dcbz = '0' and
                             (req.op = OP_STORE_MISS or req.op = OP_STORE_HIT) then
                             r1.wb.stb <= '1';
                             stbs_done := false;