jtag-openocd behaviour doesn't match jtag-svf

[jeremyherbert]

Apologies in advance if this is an upstream bug in openocd or ecppack.

I have an SVF file which is just a blinky for an ECP5 (LFE5U-12F) FPGA built with ecppack. If I use the jtag-svf applet, it loads on the FPGA fine:

$ glasgow run jtag-svf -M --port A --pin-tck 0 --pin-tms 3 --pin-tdi 2 --pin-tdo 1 blink.svf 
I: g.device.hardware: building bitstream ID baa3e836c8b20784cde3bbff3b5fe82e
/home/jeremy/oss-cad-suite/bin/nextpnr-ice40: line 22: /home/jeremy/.config/yosyshq/fonts.conf: No such file or directory
I: g.cli: running handler for applet 'jtag-svf'
I: g.applet.interface.jtag_svf: port A voltage set to 3.3 V
W: g.applet.interface.jtag_svf: SVF: test vector did not reset DUT explicitly, resetting

However, if I try to use the jtag-openocd applet with the following configuration file:

adapter driver remote_bitbang
remote_bitbang port 33333
remote_bitbang host localhost

reset_config none separate

jtag newtap ecp5 tap -irlen 8 -expected-id 0x21111043

init
scan_chain
svf -tap ecp5.tap -quiet -progress blink.svf
shutdown

the FPGA does actually load the bitstream and start running (I can see the blinking LEDs), but openocd throws an error:

$ glasgow run jtag-openocd -M --port A --pin-tck 0 --pin-tms 3 --pin-tdi 2 --pin-tdo 1 tcp:localhost:33333
I: g.device.hardware: building bitstream ID b6ca43076c531bba087e54cd1f647cdb
/home/jeremy/oss-cad-suite/bin/nextpnr-ice40: line 22: /home/jeremy/.config/yosyshq/fonts.conf: No such file or directory
I: g.cli: running handler for applet 'jtag-openocd'
I: g.applet.interface.jtag_openocd: port A voltage set to 3.3 V
I: g.applet.interface.jtag_openocd: socket: listening at tcp:localhost:33333
I: g.applet.interface.jtag_openocd: socket: new connection from [127.0.0.1]:51492
I: g.applet.interface.jtag_openocd: socket: connection from [127.0.0.1]:51492 lost

$ openocd -f flash.ocd 
Open On-Chip Debugger 0.12.0+dev-00059-g0b6f53e94-dirty (2023-01-29-02:08)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselecting 'jtag'
Info : Initializing remote_bitbang driver
Info : Connecting to localhost:33333
Info : remote_bitbang driver initialized
Info : Note: The adapter "remote_bitbang" doesn't support configurable speed
Info : JTAG tap: ecp5.tap tap/device found: 0x21111043 (mfg: 0x021 (Lattice Semi.), part: 0x1111, ver: 0x2)
Warn : gdb services need one or more targets defined
svf processing file: "blink.svf"
95%    Error: tdo check error at line 28
Error:     READ = 0x6401e10
Error:     WANT = 0x0000000
Error:     MASK = 0x000b000
Time used: 0m16s183ms 


svf file programmed failed
Info : remote_bitbang interface quit

Presumably there isn't anything wrong with the SVF file because the jtag-svf applet works fine - unless there are some SVF lines that are skipped in the jtag-svf applet.

blink.svf.txt (.txt extension added to allow it to be uploaded)

[jeremyherbert]

Hmm, I’m thinking this is because there is no openocd remote_bitbang command for a delay. The glasgow server is accepting packets as fast as possible, and so the delay in data packets is not transferred to the device due to the fact that the output data rate of the FPGA is slower than the input data rate from the USB interface.

[jeremyherbert]

Indeed, that appears to be the issue. Something like this appears to fix the problem: https://review.openocd.org/c/openocd/+/7472

Basically, it just adds two commands to delay either 1ms or 1us. If the patch is accepted, then it should be straightforward to add some delays to the JTAG applet I think.

[whitequark]

I wonder if maybe applying backpressure to the bitbang source is actually the correct approach here? Can we do this?

[jeremyherbert]

I thought about this (both with some sort of XON/XOFF and a ‘checkpoint’ handshake at points in SVF execution), but I can’t think of a good way to send the back pressure indication to openocd without increasing the complexity of the remote_bitbang protocol (which I don’t think will fly). As I understand it, the original intention for the protocol was for use with simulations, so they probably want to keep it as simple as possible.

Though, I think there is no reason that Glasgow needs to utilise the functionality in the linked patch - perhaps a different way would be more suitable given the extreme flexibility of the hardware. I mostly put the patch together to confirm that was indeed the problem, and also because I’d like to use it with another non-Glasgow device. For this applet, I think that maybe long term it would be better to use/create another adapter in openocd that also allows one to set the clock rate and maybe some other options - this could also include back pressure indication.

[whitequark]

LGTM on adding support for this specific interface to jtag-openocd.

[whitequark]

The upstream continues being unresponsive for seemingly no reason. :(

[whitequark]

This has now been merged upstream: https://review.openocd.org/c/openocd/+/7472

[jeremyherbert]

See also https://review.openocd.org/c/openocd/+/8191