Feature Request: Support for updating embedded firmware in compiled bitstream

[gregdavill]

Suggestion/Feature Request

For many FPGA platforms there exists a method of inserting a proxy block of memory inside the compiled bitstream, and then replacing this proxy with different blocks of memory after the fact.

On ECP5, this tool is ecpbram. Which performs the generation of a proxy memory file, and the patching of nextpnr *.config files with new memory files. This can be used to edit and work on firmware that's embedded into an FPGA bitstream. i.e. compiled and replaced, without having to re-perform the synthesis and PnR steps, thus improving the cycle time for fixing firmware bugs and adding features.

I've been using this in some of my projects in a very "bolt-on' manner, but curious if it's a feature that could be supported as part of the LiteX build directly? Or if there are any ideas on ways this could be done in a cleaner fashion.

I'm also not sure how we deal with gateware source and build being different, maybe like how Make/meson do it checking file modification times against the resulting bitstream?

Example

https://github.com/butterstick-fpga/butterstick-bootloader/blob/main/gateware/butterstick-bitstream.py#L251-L292

The steps are

• Create proxy memory file (Need to know size of memory at this point)
• Synthesis/PnR
• Compile firmware (Note, can also be done before synth)
• Use ecpbram, with proxy, firmware, placed design.
• Run ecppack to create final bitstream.

This flow would break the "check firmware size and resize the bram" step that LiteX currently does.

[enjoy-digital]

Hi @gregdavill,

this could indeed be interesting to add support for this directly in the LiteX build. It would be interesting to setup a small PoC for this with LiteX generating the design and the required steps to do the update on the generated bitstream.

In the meantime, I've been doing something very similar in the LiteDRAM's bench to ease development of liblitedram. The approach is a bit different: A bridge is used to control the SoC from a Host machine, update the firmware and reboot the CPU:

• The ROM is set to Read-Write mode: https://github.com/enjoy-digital/litedram/blob/master/bench/arty.py#L78 (Which prevents resize of the ROM at the end of the build BTW, which would be also required withecpbram as you suggest).
• The ROM is updated with a very simple script: https://github.com/enjoy-digital/litedram/blob/master/bench/common.py#L95-L109

So the approach is a bit different but when it's possible to have a bridge in your design, can provide the same flexibility (At the exception that in the end, when your firmware is fully developed, you'll still have to do a full rebuild).