FPGA and CPLD bootloader

Question

Coming from the world of MCUs, I create bootloaders so that customers can update the firmware.

How is this done with FPGAs and CPLD.

For FPGA:

Since the firmware is stored in external flash memory, does the FPGA image just write to it's external flash and then restart? But what happens if the new file is corrupt or the connection is removed while updating? Is there a way to make a default backup? In MCUs, the bootloader is never overwritten so the application can mess up anytime and the bootloader will still work.

Is there a separate dedicated non-volatile memory portion that is not re-configured on power up that you can load a bootloader in?

For CPLD:

Since the image is stored internally, do they have a way to configure themselves? How would one make a bootloader for a CPLD?

Other thoughts:

Maybe you can put an FTDI chip of some sort with GPIO that you can control from a PC app via USB. This way you can bitbang an SPI to load in a new image on the external flash? Anybody do that? That way the FPGA image can be corrupt or missing and still will be able to load a new image.

Note that i'm assuming that the FPGA or CPLD is alone on a board. Meaning there is not an MCU on the board to do all this.

Any insight as to how the industry achieves this task would be great.

Answer 1

FPGAs

There is no single common answer to this question. It is different for different FPGAs, and for different types of applications.

Some FPGAs have the capability to have two bitstreams in the external flash, so that if one bitstream is corrupted it will fallback to the second bitstream. You must check the datasheet for your exact FPGA to find out if it has this kind of recovery feature, and exactly how it works.

Another common way to do it is to have a MCU sitting beside the FPGA, and let the MCU manage the bitstream update of the FPGA. Make it the MCUs responsibility to ensure there is a valid bitstream in the external flash. Or, you can skip the external flash completely and make the MCU send the bitstream to the FPGA at every startup.

Some FPGAs, like the Xilinx ZYNQ, has a built-in hard processor. That processor can boot independent of the FPGA, so you write a normal bootloader for that processor, and make it the processors responsibility to update the FPGA bitstream.

If your application is a USB peripheral, then one nice way of handling it is to skip the flash memory, and make the USB driver on the PC load the bitstream to the FPGA at every startup. Bitbanging it via a FTDIchip GPIO is not recommended as it would take a very long time. FTDIchip and other manufactuers have hardware support for both SPI and JTAG. With these you can do it quickly at each startup, with no bitbanging.

CPLDs

Typically no built-in recovery mechanism. (There may be exceptions)

CPLDs are very basic devices. If you want bitstream update capability, then it typically has to be done by an external MCU. Normally you do not implement bitstream update function for CPLDs. You make your design error-free from the start instead.

Answer 2

Is there a way to make a default backup?

There is Intel MAX 10 family of fpga, it has on-chip configuration flash memory, and supports dual configuration. If anything wrong happens with one config, the other is still there and will be used as a fallback image.

But that's probably an exception, and not a typical case in fpga world.

Answer 3

In case the FPGA does not support dual configuration, and you are programming the FPGA directly ( not through a microcontroller), and somehow the new bitfile or the connection gets messed up, you have to program it again from scratch. However, in Spartan 6, there are two ways to load the program directly to the FPGA : 1. This one is relatively fast and happens withing a couple of minutes. But if the setup gets messed up you have to start from scratch. This method is mostly used when you are doing minor modification (specially time related fine tuning) as the loading of the bitfile doesn't take up much time. 2. There's an external memory on which you load the program. The bitfile loaded on this memory remains unless you decide to explicitly re-write it. Loading the bitfile on this memory takes way more time (depending on the complexity of the code), but it stays there and you can load this code onto the FPGA.