<d1b2>
<pln> It states that it support openocd/gdb. It contains a jtag block, but I haven't figured out howto connect to it using openocd. I guess you need to setup openocd to use ftdi bitbanging the jtag of the target RISC-V.
<d1b2>
<pln> (I'm on an icebreaker fpga, running linux (arch).)
<d1b2>
<pln> There is a sample gdb config file, but haven't found any sample openocd file for it.
<josuah>
@pln: not sure about anything, but https://lib.rs/crates/wishbone-tool mentions GDB vor RISC-V in the context of LiteX. Not Amaranth, but still...
<d1b2>
<pln> Thanks will look into that.
<josuah>
I am also wondering if anyone already uses something to access an FPGA internal bus (such as Wishbone) from USB
<d1b2>
<pln> I looked briefly, I think they solve a bit another problem.
<d1b2>
<pln> There is already a "transport" in place. I just wanna let openocd know about it.
<josuah>
@pln: oh right! not debugging the same segment...
<d1b2>
<pln> Actually there are two problems here.
<d1b2>
<pln> 1st) configuring openocd to use the correct gpios for the bit banging.
<d1b2>
<pln> 2nd) knowing what the correct pins would be.
<d1b2>
<pln> openocd docs are blurry. I don't understand, they refer to some bitmask but not how its setup.
<d1b2>
<pln> The second part is also blurry, my understanding of the pin mapping in Amaranth is close to 0.
<josuah>
@pln: that might be a very good question for OpenOCD, at least some part of the answer is there
<josuah>
I mean #openocd
<josuah>
in case you do not have much luck here
<josuah>
Is that not just a regular JTAG debugger that you are after?
<josuah>
Ah #openocd is on libera.chat
<josuah>
I cal help with a bit of each part, about Amaranth, I'll start here:
<josuah>
one reason why I really like Amaranth is its powerful yet simple hardware support tools
<josuah>
simply because it has conventions on how to do something, then everyone wishing to contribute can use this common language
<josuah>
are you interested in hardware pins or your CPU core pins?
<d1b2>
<zyp> the wishbone-tool debug functionality is vexriscv specific
<d1b2>
<zyp> mtkcpu says it's compatible with the standard risc-v debug spec, so I'd expect a fairly standard risc-v openocd config should work
<d1b2>
<zyp> but I'm no openocd expert 🙂
<josuah>
maybe it is more about finding an adapter that works well in OpenOCD, the GD32VF103 (as in sipeed longan nano) use standard RISC-V debugging with JTAG iirc, if you have one, you could try to use it as a way to configure the tooling, then switch to the soft RISC-V core
smkz has quit [Quit: smkz]
smkz has joined #amaranth-lang
<josuah>
@pln: on something like Verilog and several other languages, you would have an architecture-specific configuration file, such as .pcf for iCE40, that would allow you to do mapping between the package pin number and names that can immediately be used in the HDL of choice
<josuah>
on Amaranth, this is what Pin() roughly provides: a way to access the hardware pins as HDL signals
<josuah>
but this is not how board definitions are done, which is where all hardware definitions are done:
<josuah>
pins are always going to PCB traces, then eventually to other chips using some protocol, or an external connector
<josuah>
Amaranth allows to group the pins together in Connectors, which then allow you to tell "pin 3 of connector 1": it does the mapping with the FPGA chip for you: no more need to lookup the board pinout reference over and over to figure the right pinout
<josuah>
since connectors are now very portable (able to just swap the connector name, the pin number withint that connector are the same), it is further possible to give every pin a name within that connector
<josuah>
for instance, if it is a connector for a standard protocol, present on some board, the board itself can set the naming for that connector
<josuah>
then, from the FPGA HDL author point of view, it is possible to request "give me the Ethernet/USB/... interface", and you would get the right pins, organized together with subsignals with human-readable names
<josuah>
so what you would need to do as an FPGA HDL author is to lookup on your board definition file what resources are available (named Resource() in the board definition), and see if you notice your connector/component/... in here
<josuah>
the very different names are just the many different kind of resources with standardised pinout, but they work the same way
<josuah>
this files gives the equivalencies between the pin numbers and the human friendly named resources types that you can grab to build a project out of it
<josuah>
if your resource appears to already have a wrapper for it, such as LEDs, you can use them in your project with platform.request("led_r") for the red led, and you would have a Signal out of it, that you can use in Amaranth
<josuah>
If you do not see a ready-made Resource() for what you need, you can build yourself one by adding it to your platform in your HDL files, just like it was done here: same syntax, just nothing in the default resources was fitting so adding one more