I'm seeing an issue on my version of ghdl:
core.vhdl:137:24:error: actual expression must be globally static
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
This works with both the sim socket and urjtag, and supports the
new core functions, loading a file in memory etc...
The code still needs a lot of cleanup and a help!
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This module adds some simple core controls:
reset, stop, start, step
along with icache clear and reading the NIA and core
status bits
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org
This adds a local socket that can be used to communicate with
the debug tool (which will be committed separately) and generates
the JTAG signals.
We generate the low level JTAG signals, thus directly driving the
simulated BSCANE2, and the Xilinx DTM
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This adds a debug module off the DMI (debug) bus which can act as a
wishbone master to generate read and write cycles.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This adds a simple bus that can be mastered from an external
system via JTAG, which will be used to hookup various debug
modules.
It's loosely based on the RiscV model (hence the DMI name).
The module currently only supports hooking up to a Xilinx BSCANE2
but it shouldn't be too hard to adapt it to support different TAPs
if necessary.
The JTAG protocol proper is not exactly the RiscV one at this point,
though I might still change it.
This comes with some sim variants of Xilinx BSCANE2 and BUFG and a
test bench.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We are seeing some timing issues with the second cycle of loadstore,
and we aren't doing much in the first cycle, so move it here.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
The pipeline had a cycle in writeback. Writeback is pretty
simple and unlikely to be a bottleneck, so lets remove it.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
We need to finish support for all the trap instructions, but for now
we at least need a decode entry for tw, so we know to stall until the
previous instruction completes. Some of our test cases were failing
because the trap executed before the previous instruction completed.
All these trap instructions need to be resolved at completion, not
in execute.
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Anton Blanchard