hi guys
i have seen that the ZPU has a jtag tap machine in its RTL level (1), so guys are trying to attach a second jtag in order to debug the firmware (the primary jtag is used to download the fpga bitstream), that's cool !
i guess, what about putting a tiny debug-processor inside the SoC, instead ?
Assuming you have enough resources to put two soft core inside your fpga(2)
the debug processor should be so cool because it can
- stop the Main Softcore's clock, at a particular PC, or at breakpoints
- access (reading/writing) the Main Softcore's registers (also to PC, EPC, cause, cop0 and whatever …)
- access (reading/writing) the Main Softcore's local bus (so r/w its iram/dram)
the idea is to put gdb-stub inside the tiny Debug Processor (which is validated, so you can trust it), and let it to (uart-serially-)-talk gdb-uart-protocol with the host in order to control the target !
in this ways you put much more intelligence in the debug module, which could simplify things like … attaching the host in order to control things
with a gdb-debug-processor the host could simply send commands (high level commands, also in pretty ASCII form) and gets replies instead of
hardly handling all the signals of a jtag tap machines (which also requires … a special file, BSDL file, that describe the target from the point of
view of the TAP machine)
what do you think ?
anything around ?
(2) for example, a smaller debug-processor-Softcore made with the Xilinx PicoBlaze, which is very essential and tiny
edit: repo's link added
(1) from the
ZPU repo, see
zpu.hdl.tap (vhdl source), it looks very interesting!