fetch/icache: Fit icache in BRAM
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>
Fri, 27 Sep 2019 03:23:56 +0000 (13:23 +1000)
committerBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tue, 8 Oct 2019 03:46:38 +0000 (14:46 +1100)
commitd415e5544afe69469bb58445d818d87f7d2b352f
tree19aea63e0d74a2abe1637f49541f1af95d4bf00d
parent3589f92d5ac7921917a3b3bc573e838de760e569
fetch/icache: Fit icache in BRAM

The goal is to have the icache fit in BRAM by latching the output
into a register. In order to avoid timing issues , we need to give
the BRAM a full cycle on reads, and thus we souce the BRAM address
directly from fetch1 latched NIA.

(Note: This will be problematic if/when we want to hash the address,
we'll probably be better off having fetch1 latch a fully hashed address
along with the normal one, so the icache can use the former to address
the BRAM and pass the latter along)

One difficulty is that we cannot really stall the icache without adding
more combo logic that would break the "one full cycle" BRAM model. This
means that on stalls from decode, by the time we stall fetch1, it has
already gone to the next address, which the icache is already latching.

We work around this by having a "stash" buffer in fetch2 that will stash
away the icache output on a stall, and override the output of the icache
with the content of the stash buffer when unstalling.

This requires a rewrite of the stop/step debug logic as well. We now
do most of the hard work in fetch1 which makes more sense.

Note: Vivado is still not inferring an built-in output register for the
BRAMs. I don't want to add another cycle... I don't fully understand why
it wouldn't be able to treat current_row as such but clearly it won't. At
least the timing seems good enough now for 100Mhz, possibly more.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
common.vhdl
core.vhdl
core_debug.vhdl
fetch1.vhdl
fetch2.vhdl
icache.vhdl
icache_tb.vhdl