loadstore1: Move logic from dcache to loadstore1
authorPaul Mackerras <paulus@ozlabs.org>
Sat, 28 Mar 2020 09:24:13 +0000 (20:24 +1100)
committerPaul Mackerras <paulus@ozlabs.org>
Sat, 28 Mar 2020 09:24:13 +0000 (20:24 +1100)
commitb349cc891a52c0453e7c721b98b96025995a4588
tree6603ae05b47291d83990af1155f2b3d9e699efbb
parentef9c1efd72e39c86a63d85c440f13a431d90bae8
loadstore1: Move logic from dcache to loadstore1

So that the dcache could in future be used by an MMU, this moves
logic to do with data formatting, rA updates for update-form
instructions, and handling of unaligned loads and stores out of
dcache and into loadstore1.  For now, dcache connects only to
loadstore1, and loadstore1 now has the connection to writeback.

Dcache generates a stall signal to loadstore1 which indicates that
the request presented in the current cycle was not accepted and
should be presented again.  However, loadstore1 doesn't currently
use it because we know that we can never hit the circumstances
where it might be set.

For unaligned transfers, loadstore1 generates two requests to
dcache back-to-back, and then waits to see two acks back from
dcache (cycles where d_in.valid is true).

Loadstore1 now has a FSM for tracking how many acks we are
expecting from dcache and for doing the rA update cycles when
necessary.  Handling for reservations and conditional stores is
still in dcache.

Loadstore1 now generates its own stall signal back to decode2,
so we no longer need the logic in execute1 that generated the stall
for the first two cycles.

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
common.vhdl
core.vhdl
dcache.vhdl
dcache_tb.vhdl
execute1.vhdl
loadstore1.vhdl
writeback.vhdl