-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jtag-openocd behaviour doesn't match jtag-svf #303
Comments
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. |
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. |
I wonder if maybe applying backpressure to the bitbang source is actually the correct approach here? Can we do this? |
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. |
LGTM on adding support for this specific interface to |
The upstream continues being unresponsive for seemingly no reason. :( |
This has now been merged upstream: https://review.openocd.org/c/openocd/+/7472 |
@jeremyherbert I think this should be fixed now--could you retest please? |
I tried running the following command with the SVF file in the original post:
But I receive the error:
I also tried with a freshly compiled openocd and the openocd config file above:
Probe does work though:
I am using the version |
@wanda-phi That sounds related to your changes, can you take a look? |
A small update - the openocd error was caused by me using an ECP5 25F to test rather than an ECP5 12F. Sorry, was just in a bit of a rush. Here is what a 12F looks like (working):
Unfortunately the
|
Indeed, that is my bug. Could you test if #615 fixes it? |
Works great now! Thanks for the fix. Please feel to close this as necessary @whitequark |
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:However, if I try to use the
jtag-openocd
applet with the following configuration file:the FPGA does actually load the bitstream and start running (I can see the blinking LEDs), but openocd throws an error:
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 thejtag-svf
applet.blink.svf.txt (.txt extension added to allow it to be uploaded)
The text was updated successfully, but these errors were encountered: