Open arbrauns opened 1 year ago
Sounds good! It wasn't needed for our use-case but I can see how that could be useful.
Feel free to propose a PR with the changes! Make sure the new callback is optional so that current drivers continue to work without any modifications
Hi @cfriedt,
This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.
Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.
@arbrauns you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.
Thanks!
It's possible that some FPGAs might have timing requirements on bitstream loading that might make this somewhat tricky, but that might just be during the handshake phase.
It seems useful though.
I don't have an immediate need for this feature though. @arbrauns - would you care to make a PR?
We've since added external flash to the device where this would have been relevant, so no current need from our side either.
Ok - we can leave it open until someone needs this feature
Is your enhancement proposal related to a problem? Please describe. Currently,
fpga_load()
expects the entire bitstream to be stored in a contiguous memory region. Because bitstream files tend to be quite large and sparse, it is tempting to 1) store them on external, non-memory-mapped storage and/or 2) compress them. With the current FPGA driver, the entire bitstream would have to be loaded into memory first, which would defeat the purpose and might not be possible at all.Describe the solution you'd like If possible, FPGA drivers should allow the bitstream to be loaded in chunks by calling a supplied callback. This callback can then load data from external storage and/or uncompress the bitstream. The API would look something like the following:
For this to be supported, the hardware has to support pauses during the programming process (while the callback produces more data).
Describe alternatives you've considered None.
cc @tgorochowik @kgugala as code owners