Zynq/UltraScale Ports + JTAG

[stefanct]

Hi, I was wondering if there are any plans for other FPGA ports. I'd mostly be interested in Zedboard and ZCU102.

In the past these ports (and softcores as standalone projects in general) have been a bit annoying because you had to use an external JTAG programmer since the on-board USB-JTAG was only connected to the ARM CPU (PS). I am currently evaluating if it would be possible to get rid of that with an IP core xilinx added to vivado 2019.2 (I think... hard do determine with Xilinx "documentation"): https://www.xilinx.com/products/intellectual-property/bscan-to-jtag-converter.html Does anybody have some insights into that?

Also, is there any communication channel/mailing list used specifically for core-v mcu? is there a openhwgroup irc channel?

[zarubaf]

Hey @stefanct,

yes, we are definitely interested in that. We are trying to switch to fusesoc which should make adding another FPGA board (at least from the perspective of a script) much easier. Also, @timsaxe has put a lot of effort into making the IO system reconfigurable and adaptable depending on the FPGA board. Everything is still in a very early phase (for example we didn't yet change over to fusesoc).

Communication-wise we do have a channel over in our Mattermost group, please join for discussion and questions. Although Github issues are also fine and maybe a bit more accessible.

I completely agree with your statement about the JTAG tap and coincidentally I also want/need to look into it - having an entire processing system in there is pretty wasteful for a single JTAG tap :-). The adapter you sent looks promising, I also saw that it might be possible to directly instantiate the BSCAN primitive back in the days. What we basically need is a JTAG TAP controller for Xilinx devices and the appropriate OpenOCD (driver) infrastructure. Do you want to open the issue on the riscv-dbg repository and we continue the discussion there in case you are interested in helping :-D?

[zarubaf]

I just found this:

• https://www.cl.cam.ac.uk/~jrrk2/docs/jtag/
• https://github.com/riscv/riscv-openocd/issues/385
• https://github.com/chipsalliance/Cores-SweRVolf/issues/29

which seem to indicate that one can use the BSCANE2 primitives by remapping the IR register in OpenOCD to the user IR registers of the BSCANE2 primitives.

What I didn’t check so far: Is the primitive available on all 7series and UltraScale+ devices :-)

[stefanct]

After sending it, I have also found a blog post with some interesting details: https://jsteward.moe/risc-v-hardware-design-part-b-edgeboard-series.html From that, I'd say that the primitive exists for all relevant devices. I don't currently have access to the IP core yet (I've requested a license update for that) but apparently it might be better to directly instance the primitive to avoid potential problems with the IP module(?).

I cannot completely wrap my head around all of it but shouldn't at least the hardware/bascan part be independent of the debug unit (and thus outside the riscv-dbg repo)? After all it is only some wrapper to get it attached to the FPGA.

(And for the record: I joined the MM server.)

[zarubaf]

Okay after some more digging it seems we have two options which all rely on the BSCANE2 Xilinx primitive. As an explanation of why I think this is a debug module related request:

The debug module contains two big components:

1. The DTM (Debug Transport Module) is a specific protocol that translates to a relatively agonistic ready/valid handshakes request to the DM. The RISC-V specification currently specifies a JTAG DTM. That is also what is included in the debug module repository.
2. The DM (Debug Module), the actual device which performs external debugging in the system. Not really relevant here.

1. bscane tunneling

Here the bscane2 routine is instantiated in the design and drives the five JTAG pins (tck, tdi, tdo, tms, trstn) directly. It does so by implementing a custom protocol designed by SiFive (I haven't found the specification yet - apparently SiFive wants to open it eventually, this translated page is the closest information I could find) which in turn drives the JTAG pins. The required hardware seems relatively simple and can be found here. There seems to be support in upstream OpenOCD.

Pros

• Drives JTAG pins directly, so we are also stressing the existing JTAG DTM (which may end up on an ASIC).
• It only uses one BSCANE2 primitive.

Cons

• Quite a lot of code on the OpenOCD side. Potentially a bit convoluted.
• There seem to be different implementations around (at least the SiFive one and the link you shared above), not sure whether they are compatible.
• Potentially a bit slower because JTAG is simulated with JTAG :-) Especially when loading larger binaries that can become quite annoying (although one could also arguable tunnel through PCIe or so).

2. Multiple BSCANE2

The BSCANE2 primitives allow for custom user ir register. The only issue is that by default the RISC-V debug specification expects them at a different location. But luckily there is a command called riscv set_ir .. which allows remapping the IR registers to something we can use with the BSCANE2 primitives.

In SweRVolf there is an implementation that we potentially could take 1:1. The module would replace the existing dmi_jtag module in case we would implement it for FPGA.

Pros

• More straightforward implementation.
• Potentially faster.
• No extra OpenOCD code needed (except the trivial remapping of the idcode, dtmcs, and dmi register).

Cons

• The existing dmi_jtag implementation will not be tested (which will end up on an ASIC for example).

In light of what I've read, I would slightly prefer option 2 for now. We can eventually think about supporting option 1 as well for verification purposes.

[zarubaf]

I've drafted up an implementation of 2 here: https://github.com/pulp-platform/riscv-dbg/pull/111

[stefanct]

As discussed on mattermost... This is indeed working with pulpissimo on the zedboard with some peculiar openocd configs, which is listed below for reference. The vid/pid are just the USB IDs of the ftdi chip. The layout settings depend on how the ftdi is connected on the board. The two expected-id numbers represent the arm cpu and the bscane2 interface respectively and depend on the xilinx fpga device. The set_ir commands depend also on the fpga.

interface ftdi
transport select jtag

ftdi_vid_pid 0x0403 0x6014

ftdi_layout_init 0x2088 0x3f8b
ftdi_layout_signal nSRST -data 0x2000
ftdi_layout_signal GPIO2 -data 0x2000
ftdi_layout_signal GPIO1 -data 0x0200
ftdi_layout_signal GPIO0 -data 0x0100

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 6 -expected-id 0x23727093

# just to avoid a warning about the auto-detected arm core
jtag newtap arm_unused tap -irlen 4 -expected-id 0x4ba00477

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME -coreid 0x3e0

riscv set_ir idcode 0x09
riscv set_ir dtmcs 0x22
riscv set_ir dmi 0x23

adapter_khz     1000

[stefanct]

However, I was not able to get it to work on a ZCU102 (see the merged riscv-dbg changeset)

[zorrolee777]

@stefanct Any luck with implementation on ZCU102? We are also trying to make it work on ZCU102 and also got some problems.

[MikeOpenHWGroup]

Hi @stefanct, what is the status of this issue?

[stefanct]

Unchanged, I had not time to investigate how to correctly fix our implementation. The TAP on the Ultrascale+ is slightly different and would need some additional shifts as described here: https://jsteward.moe/risc-v-hardware-design-part-b-edgeboard-series.html

[MikeOpenHWGroup]

Thanks @stefanct. We are moving up to "RTL Freeze" for V1.0.0 of the CORE-V-MCU so I will mark this as "won't fix" and "enhancement". If you are interested, you can help us resolve the issue for a future release of the MCU.

[likewise]

For ZCU102, I solved this issue in my project: https://github.com/likewise/ibex/blob/super_system/examples/fpga/zcu102/openocd_zynqmp_bscane2.cfg

This requires upstream OpenOCD 0.11.0 or later.

[stefanct]

Hm, interesting but I am still stuck. I presume you are using the official openocd repo (or a binary based on that)? I initially tried the current riscv fork but that segfaults (I guess they did not merge some patch(es) from the vanilla 0.11 branch). With the current HEAD of the official repo it gets further but similar to earlier the debug module of the riscv core cannot be initialized correctly. I have attached the -d3 log with exactly your oocd config and some bscane-enabled pulpissimo bitstream that I have created in the summer. I have attached the -d3 log. Can you please post yours so that I can compare?

openocd_vanilla-0.11.0+dev-00551-gaad8718.txt

[likewise]

I am using OpenOCD 0.11.0 upstream with Ibex RISC-V. I have not tried CORE-V (yet). I will provide you with my OpenOCD log for Ibex in a follow-up.

openocd --version Open On-Chip Debugger 0.11.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html

[7777777all]

@stefanct Hello, may I ask how to configure BSCAN using OpenOCD? My chip is xczu19eg