We can force all existing code to use the UART console
by passing 0 in bit zero of the sim config register.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
(And rename it to mw_soc_memory).
This makes soc.vhdl simpler and provides the same interface as
the simulated memory, which will help when sharing soc.vhdl
with sim later
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This will be useful when we start needing different toplevels for
different boards.
We keep the reset and clock generators in the toplevel as they will
eventually be taken over by litedram when we integrate it, and they
are more likely to change on different system types.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We no longer gate multiply with the valid signal, so it's complaining
a lot. Comment out the warning.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
We weren't actually forwarding writes in the same cycle. Not a
problem right now, but noticed when testing the pipelining series.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
We want to make sure we never complete more than one
instruction per cycle, or write back more than one GPR
or CR per cycle.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
We only need two write ports for load with update instructions.
Having two write ports just for this instruction is expensive.
For now we will force them to be the only instruction in the
pipeline, and take two cycles of writeback.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
It simulated fine, but didn't synthesize. Fix some obvious issues
to get us going again.
Fixes: 9fbaea6f08 ("Rework CR file and add forwarding")
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Right now we continually print all 3 possible GPRs an instruction
may be using. Add signals so we only print GPRs when they are
actually read. This should hopefully optimise away when synthesized.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Handle the CR as a single field with per nibble enables. Forward any
writes in the same cycle.
If this proves to be an issue for timing, we may want to revisit
this in the future. For now, it keeps things simple.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>