07-20-2010 06:46 AM
I am designing a system where remote FPGA configuration will be needed. We are using Spartan-6 FPGA devices which are connected to SFP optical transceivers and would like to use this optical connection also for remote configuration of the FPGA. A bitfile would basically have to be sent via optical link to the FPGA which would then have store this bitfile to a non-volatile memory and somehow re-configure itself from it. The system has to be very robust with fail-safes for power losses, corrupt bitfiles etc.
Any ideas? Thank you for your help.
07-20-2010 11:15 PM
Doing remote firmware/configuration update to flash, if that's what you are talking about , in a totally fail safe way, is tricky ... because if you get a glitch at any time during the update, you need to be able to recover from it.
We did a system system with a MicroBlaze that configured from a local SPI flash, and the only way we could figure out to do fail safe remote firmware/configuration update was to use a small 8-bit CPU.
During firmware/configuration update, the MicroBlaze writes the update to the SPI flash, but writes it to a different set of sectors in SPI flash - not the sectors used for configuration. If that goes OK, the MicroBlaze sets a flag in the EEPROM in the small CPU.
Upon power cycle, the small CPU sees that the flag is set, then pulls PROG_B low to hold the FPGA in reset, then copies the flash sectors just updated above into the configuration sectors. Only if that goes OK does the small CPU clear the flag in its EEPROM, then it raises PROG_B to allow the FPGA to load its new configuration.
This can recover from a glitch at any time during the update process, and has worked well for us.
If you are talking about configuring it remotely on each power-up then that is much easier and you don't need local flash. You just set the FPGA M0,1,2 pins for something like slave serial mode and the FPGA will start only if the CRC checks out.
07-21-2010 06:20 AM
This is possible when you make use of the MultiBoot feature. Spartan-6 has improved MultiBoot features as well. I don't think the remote updating is implemented, but the MultiBoot is, and the fail-safe update is described very well in the SP605 MultiBoot reference design:
Although not Spartan-6 (so it doesn't make use of the new S6 features, like the sticky registers), here is a remote configuration update example where the MultiBoot image is updated over ethernet for the Xilinx Spartan-3A DSP Starter (1800A) Kit.
www.em.avnet.com/spartan3a-dsp --> Support Files & Downloads --> > S3A1800DSP Serial Flash Bitstream Update over Ethernet
07-22-2010 01:49 AM
Thank you so much for the answers, it was all very helpful. So if FPGA boots from an SPI flash it is possible that it also overwrites the existing bitfile with a new one? That wouldn't be possibe for example with Xilinx's Platform Flash, because it doesn't have the MOSI data line. Can the FPGA utilize the pins with which it boots itself as IO pins when it has finished booting (so that it can write to and read from boot flash)?
07-22-2010 10:23 AM
If your using the XCFP flash parts they are updated via JTAG. iMPACT will create SVF files for "Safe Update" that will just update data portions of the flash or change the rev sel values. These files can be played from the FPGA via xapp058 or xapp424 where the FPGA drives its own JTAG lines.
The following thread has more details on XAPP058: http://forums.xilinx.com/t5/General-Technical-Discussion/XAPP058-files/m-p/43450
07-22-2010 11:41 AM
Spartan-6, similar to Spartan-3A, can re-use the SPI configuration pins after configuration for general-purpose use. In the example that I referenced, the pins are connected to a SPI master peripheral in a MicroBlaze design inside the FPGA.
It is possible for the FPGA to overwrite the Golden bitstream in the Flash, but in a safe update scenario, you would make sure not to do that. In a safe update scenario, you would leave a Golden bitstream in a recovery position in the Flash, and it would never be touched. You would only ever update your application bitstream. Furthermore, if you have enough space in your Flash, you could maintain multiple copies of previous versions of bitstreams.
Spartan-6 handles the Golden bitstream different than Spartan-3A. Spartan-6 gives you more control which allows for more sophisticated configuration strategies.
I think if you will read over the Remote Update example, you will begin to see the potential of what you are asking. Just remember the example is based on Spartan-3A, and Spartan-6 can do all that plus a little more. The "little more" to which I am referring are the sticky registers and the header bitstream documented in the Spartan-6 Configuration User Guide, UG380.
05-20-2015 12:13 AM