Bitstream

Sync words

On startup the FPGA is very stubborn: it goes through the SPI Flash chip and searches for a bitstream to load it’s configuration from. And to find this bitstream it looks for a very specific pattern: the sync word.

The sync word is 0xaa995566, and as soon as the FPGA reads this sequence from flash, it will start reading everything that follows (until the end – TODO: what is the end?) into itself to configure all the logic it has.

There is one caveat: after the bitstream started, there is no guarantee that a second bit sequence inside the bitstream also resembles the sync word. And this is what our slot 0 recovery mechanism does not like, as it requires the FPGA to search through all slot 0 without finding a single sync word, and the one at the start of slot 1 being the one that then will load the configuration.

So, if there is a second sync word in the bitstream, and we erase only the start sync word, then the FGPA will find the sync word in the middle of slot 0 and load something broken, never reaching slot 1. This is why the new flasher needs to erase all those extra sync words to reduce the window in which a JTAG-less flash can soft-brick your MEGA65.

Corefile

What is a corefile?

A core file is a container format the MEGA65 Team developed to provide a header with information about the bitstream, the bitstream (or perhaps bitstreams in the future) itself, and extra files.

The header of the core file is exactly 4096 bytes long. You can find it’s layout in mega65-tools bit2core.c (better look for the latest version, might be called coretool in the future!).

In the very last sectors of the core file a banner image can be stored for quick access during bootup. After the bitstream a number of files can be embedded. These are currently only used by MEGA65-FDISK to populate a freshly formatted SD card.

Open