-
Notifications
You must be signed in to change notification settings - Fork 41
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
Processing SVF files directly #23
Comments
Can you provide some concrete data? How does it compare with bin programming? What JTAG frequency do you use? Do you know where the bottleneck is? Can you share your SVF file? It turns out that the author of openFGPALoader wasn't all positive about enabling SVF support for every FPGA targets because SVF is inherently slow compared to bin programming. The reason is that some delays are typically inserted in places due to programming delays imposed by the hardware. In bin mode, openFPGALoader loops around a read register status until the device is ready. SVF do not allow this so a conservative delay is typically introduced which is always slower than the probe loop. |
The board I am using (MAX10 10M08 Evaluation Kit) does does not have bin support for comparison, but the SVF programming takes several minutes for a small device. I was running at the fastest 16Mbps supported by pick-dirtyJtag. There may be some potential optimizations like skipping verification of the image. I may attempt this myself. I am mostly wondering if you think the openFPGALoader SVF parsing could be ported to the RP2040 since you seem to be familiar with both. Or would you look for another SVF implementation to port? |
I am guessing you are right. SVF checking TDO may be the reason it is slow. However, there must be a generation mode where the generated SVF does not do this. For sure, this shortened Lattice file does not and loads 300KB in a couple of seconds. |
I'm not use FPGA at all. But i am facing the same situation. I'm using the OpenOCD, In my case, for read every 4bytes memory, At least, It need send 2 command queues to Pico. I guess it should be 1 for TAP_STATE_MOVE + write IR and 1 for TAP_STATE_MOVE + read DR. The OpenOCD not submit read command in bulk. In the screenshot, you can see Pico need about ~4ms to processing every command queue. It should explain why dump speed is 0.15kb/s. |
Besides of make openFPGALoader/OpenOCD running on Pico, I think the most generic way is use MPU to do this. So it no need for modify OpenOCD to really submit command in bulk. Just make a JTAG adapter driver as usual. I'm already do some test on Rockchip RV1106, MCU can do bit-bang at 1 MHz. Compare to ST/TI, the board is Pico sized, cheap and easy to get. |
How about J-Link and other commercial debugger to handle this? |
About Jlink and the Jlink GDB server. The microprocessor in the Jlink device handles all of the chatty traffic of the debug protocol. It only sends the results to the gdb server on the USB line. |
About Jlink and the Jlink GDB server. The microprocessor in the Jlink device handles all of the chatty traffic of the debug protocol. It only sends the results to the gdb server on the USB line. |
Got it, So the things like Black Magic Probe will be fastest. Thank you for your explanation. |
Loading devices from SVF files with openFPGALoader take forever.
How difficult would it be to take the SVF parsing from openFPGALoader and run it locally on the RP2040?
It would be nice to be able to send a .SVF file into the RP2040 through a virtual UART and process it locally.
Could we use the SVF parsing from openFPGALoader, or should we look for one that already runs on an MCU?
The text was updated successfully, but these errors were encountered: