The generic PIPELINE_DEPTH can be set to 0 to keep it operating
as a non-pipelined slave, or a larger value indicating
the amount of extra cycles between requests and acks.
It will always generate a valid stall signal, so it can be used
in either mode with a pipelined master (but only in non-pipelined
mode with a non-pipelined master).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
For now ... it reduces the routing pressure on the FPGA
This needs manual adjustment of the address decoder in soc.vhdl, at
least until I can figure out how to deal with std_match
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
# Conflicts:
# soc.vhdl
# Conflicts:
# soc.vhdl
All that needs to be changed now is the size in wishbone_types.vhdl
and the address decoder in soc.vhdl
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We don't yet have a proper snooper for the icache, so for now make
icbi just flush the whole thing
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The instruction works by redirecting fetch to nia+4 (hopefully using
the same adder used to generate LR) and doing a backflush. Along with
being single issue, this should guarantee that the next instruction
only gets fetched after the pipe's been emptied.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We used the variable "way" in the wrong state in the cache when
updating a line valid bit after the end of the wishbone transactions,
we need to use the latched "store_way".
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Clearly separate the 2 stages of load hits, improve naming and
comments, clarify the writeback controls etc...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Adding lines seems to add only little extra as the BRAMs aren't
full, 2 ways is our current comprimise to limit pressure on small
FPGAs. We could go to 64 lines for a little more, but timing is
becoming a bit too right to my linking on the tags/LRU path of
the icache, so let's leave it at 32 for now.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This makes the BRAMs use an output buffer, introducing an extra
cycle latency. Without this, Vivado won't make timing at 100Mhz.
We stash all the necessary response data in delayed latches, the
extra cycle is NOT a state in the state machine, thus it's fully
pipelined and doesn't involve stalling.
This introduces an extra non-pipelined cycle for loads with update
to avoid collision on the writeback output between the now delayed
load data and the register update. We could avoid it by moving
the register update in the pipeline bubble created by the extra
update state, but it's a bit trickier, so I leave that for a latter
optimization.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This replaces loadstore2 with a dcache
The dcache unit is losely based on the icache one (same basic cache
layout), but has some significant logic additions to deal with stores,
loads with update, non-cachable accesses and other differences due to
operating in the execution part of the pipeline rather than the fetch
part.
The cache is store-through, though a hit with an existing line will
update the line rather than invalidate it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This might slightly increase the logic in synthesis but avoids
us looking at uninitialized tags when not servicing an active
request
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Few tweaks based on a newcomers experience getting an Arty A7-100 up and running
Forgot to add DCO in initial PR, now corrected.
Signed-off-by: Hugh Blemings <hugh@blemings.org>
The icache_test.bin file was missing. This adds it (along with a python3
script to generate it).
We also add better reporting on errors
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Initialize to 0 forces the mux to have an extra leg fed with zeros.
Instead initialize data_in to one of the mux inputs
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The current code has the possibility that we could set reg_addr
or reg_ctrl and then increment reg_addr in the same cycle, resulting
in some long timing paths. Rearrange the code to make it clear
that we are not trying to add an auto-increment to data from
outside the module; in any given cycle we either set one of
reg_addr and reg_ctrl, or we possibly increment reg_addr.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Since the condition setting got moved to writeback, execute2 does
nothing aside from wasting a cycle. This removes it.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This makes the exts[bhw] instructions do the sign extension in the
writeback stage using the sign-extension logic there instead of
having unique sign extension logic in execute1. This requires
passing the data length and sign extend flag from decode2 down
through execute1 and execute2 and into writeback. As a side bonus
we reduce the number of values in insn_type_t by two.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds code to writeback to format data and test the result
against zero for the purpose of setting CR0. The data formatter
is able to shift and mask by bytes and do byte reversal and sign
extension. It can also put together bytes from two input
doublewords to support unaligned loads (including unaligned
byte-reversed loads).
The data formatter starts with an 8:1 multiplexer that is able
to direct any byte of the input to any byte of the output. This
lets us rotate the data and simultaneously byte-reverse it.
The rotated/reversed data goes to a register for the unaligned
cases that overlap two doublewords. Then there is per-byte logic
that does trimming, sign extension, and splicing together bytes
from a previous input doubleword (stored in data_latched) and the
current doubleword. Finally the 64-bit result is tested to set
CR0 if rc = 1.
This removes the RC logic from the execute2, multiply and divide
units, and the shift/mask/byte-reverse/sign-extend logic from
loadstore2.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
We have all the machinery in place to implement the neg instruction
as OP_ADD. Doing that means we can ditch OP_NEG, and saves about
66 slice LUTs on the A7-100.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Timing analysis showed that even with the output register, timing
was still a bit tight in the output stage, where the carry has to
propagate all the way through the 64-bit negater, and we were then
testing the top 33 bits to determine if a 32-bit operation had
overflowed.
Instead of detecting overflow at the end, we watch for any 1
bits getting shifted into the top 32 bits of the quotient register
as we are doing the division. That is relatively easy to do and
simplifies the output stage.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This puts the output of the divider through a register. With the
addition of the logic to detect overflow, the combinatorial output
logic of the divider was becoming a critical path. Adding the
output register adds a cycle to the latency of the divider but
helps make timing at 100MHz on the A7-100.
This also makes the valid, write_reg_enable and write_cr_enable
fields of the output be registered, which eliminates warnings
about register/latch pins with no clock.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Anything that isn't a load or store and anything that doesn't read the
CR can go as soon as its inputs are ready.
While we could also allow SPR read/write and carry read/write, we plan
to change them to be read in decode2 and written in writeback soon and
they will need separate hazard detection to be added.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>