Alchitry Au+ boot from non volatile memory

General
1

I have generated a bitfile in Vivado targeting the Alchitry Au+. I can then rename this bitfile to a .bin file extension and use the Alchitry Loader’s “Program RAM” button to load the run the code. This is successful I see my design running.

Now I want to burn this load into flash so whenever it powers on, my custom code is running by default. I tried simply clicking the “Program Flash” button with the same .bin file, but no luck, the DONE LED never comes on after the next power cycle. I then tried using Vivado to convert the *.bit to a *.mcs as is the normal flow on FPGA projects, renaming this to a .bin, and then doing “Program Flash”, but this also did not work.

Some questions:

  1. Sanity check: Is it possible to program an FPGA load into this board so that it comes up automatically after a power cycle (non-volatile load from Flash)?
  2. What file format is Alchitry Loader expecting for a flash image? I know it asks for a “bin” file, but what file format is this? MCS? How do I convert from Vivado’s *.bit file to whatever Alchitry Loader is expecting, specifically for non-volatile flash images?
  3. Are there any extra details I need to know about generating the file? Sometimes there are XDC constraints that affect the bitstream generation (flash clock speeds, bitstream compression, etc).
2

I’m surprised renaming a .bit file to .bin worked. A .bit file has some header information that I’ve had a hard time tracking down how to parse. A .bin file contains JUST the configuration data needed to be sent to the FPGA.

You can generate them by opening your project settings in Vivado then going to Bitstream and check the -bin_file option.

Screenshot 2024-06-14 114655
Screenshot 2024-06-14 1146551487×945 85.9 KB

This file can be loaded directly to the FPGA or to the flash to make it load automatically at power up.

3

I have an hypothesis about why the .bit file worked :
Since the file is reversed before beeing sent by the loader, the header is at the end, so maybe the FPGA seeing the config beeing complete, just ignored the extra header?