<agg>
i want to design a board with an ecp5 that will run a riscv softcore (probably minerva) which provides a jtag debug option, in theory at least i think i could daisychain the jtag so one connector/probe can debug both fpga and softcore
<agg>
but in practice would this be dumb? for instance afaict if the software was not working or not configured, there'd be no daisychain, so I wouldn't get jtag to the fpga either
<agg>
alternatively does the ecp5 have any internal access to the jtag chain which could be done at configuration time? i can't see anything about that in TN02039
<daveshah>
You can use the JTAGG primitive for that
<agg>
aah, that sounds like precisely the answer i wanted, i'll check the tech lib
<daveshah>
It's not really documented, but it enables access to the fabric via JTAG at runtime using two private opcodes
<agg>
I see what you mean by not really documented
<agg>
"Most users would typically not use this
<agg>
component directly."
<agg>
if it needs private opcodes that means my jtag debugger would have to do more than the usual scan chain to find the softcore?
<agg>
not sure if that's a problem really, definitely running before walking with this project
<daveshah>
Yes, the JTAG debugger would need to understand those
<agg>
how worthwhile is the ecp5 jtag access? i'm coming from ice40 where of course it's just spi configuration and no jtag
<zyp>
oh, there is a jtag primitive? I actually went looking for that in the ecp5 docs a few weeks ago and came to the conclusion that there didn't appear to be one
<agg>
zyp: the "FPGA Libraries Reference Guide" document has it and all(?) the other primitives
<agg>
it doesn't seem to have a document number or other identifier, heh
<zyp>
yeah, you're right
<agg>
but it doesn't really have much to say about it beyond its existence
<zyp>
it's not mentioned at all in e.g. TN-02039
<agg>
yea, that's where i was looking and not finding anything either
<zyp>
that said, is there a particular reason you want to use jtag as a debug transport? just saving pins?
<agg>
what else would I use as a debug transport? I've not used a risc-v core at all before or really any softcore, just used to mcus where i'd always bring out jtag or swd
<agg>
i expect my first attempt will just be writing the spi flash with both the bitstream and the firmware image and hoping an led blinks first time :p
<zyp>
uart, for instance
<zyp>
e.g. vexriscv on litex can be debugged over any wishbone bridge, including the uart bridge
<agg>
huh, I guess that works too
<zyp>
I've also toyed with the idea of running a gdbserver on e.g. a serv instance, managing a larger cpu, accessable through a uart or usb-serial
<daveshah>
sounds like blackmagicprobe
<zyp>
daveshah, exactly
<zyp>
I'm using blackmagic probe for all my cortex-m stuff, big fan of the simplicity :)
<agg>
i have a little firmware for an stm32f0 that does usb to spi/swd/jtag/uart, so was going to stick that on for doing flash programming anyway
<agg>
mm, bmps are lovely
<agg>
but yea i guess i can basically already have a usb-serial into the fpga. I guess at this point i'll just route a lot of things and keep my options open :P
<agg>
i was planning on using minerva in nmigen and probably doing the bus/interconnects myself since I don't need much here, but maybe that is a waste of effort, i'll check out litex again