We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 58249

7 series/ 6 series - Device may not fallback correctly if multiboot bitstream is corrupted in certain places.


The bitstream can be corrupted when a host is updating a multiboot bitstream remotely but fails to update the whole bitstream successfully.

Even with WDT set in the bitstream, if the command part before the CRAM data in the bitstream is corrupted, the device might not fallback to the golden bitstream.


In most cases, this issue is due to bad packet error.

Packets used for configuring FPGA are constructed in a special format.

The FPGA will check packet format on the fly and stops the configuration process after a corrupted or bad format packet is received.

Because the FPGA configuration process logic gets stuck after receiving a corrupted packet, no further action (for example fallback) will be taken.

The FPGA hangs and can never boot until the configuration image is properly updated again. 

For more information on bad packet errors, please refer to (Xilinx Answer 38077) 

For Spartan-6 devices, extra care needs to be taken. 

The Watchdog Timer of Spartan-6 devices is different to other devices.

It only gets to time-out if no SYNCWORD is received, instead of the completion of the whole configuration process. 

If system power or data link goes down in the middle of field update, the latter part will be lost. 

The CRC check command is included in the latter part of the bit file.

Without the CRC check command, the FPGA will be unable to detect the CRC error and trigger a fallback.

As a result, fallback will not occur as no timer-out or CRC error occurred. 

The FPGA will keep on sending CCLK but no valid data will be loaded to the FPGA and it will never stop.

If a 100% update for multiboot image is needed, the traditional method is not sufficient.

There are two recommended methods to update the multiboot image safely.

Method 1:

Erase the sync word first and program the sync word last.

This method was previously used in the Spartan 6 device fallback multiboot process.

It still applies for the 7 series device.

This can ensure that the multiboot image is not found until the multiboot image is fully updated.

Please refer to (Xilinx Answer 58090) for more information.

Method 2:

Refer to XAPP1081 "QuickBoot Method for FPGA Design Remote Update"

A critical switch is inserted before the warm boot jump sequence.

Before updating the multiboot image, the switch is set to turn "OFF" the warm boot jump sequence. 

If the multiboot image is not updated successfully due to a power lost or system malfunction, the warm boot jump sequence will be bypassed and the FPGA will load the golden image directly.


Linked Answer Records

Associated Answer Records

Answer Number Answer Title Version Found Version Resolved
58090 FPGA Multiboot - When updating Multiboot image, what erase/program ordering is recommended? N/A N/A
AR# 58249
Date Created 11/03/2013
Last Updated 06/10/2015
Status Active
Type General Article
  • Artix-7
  • Kintex-7
  • Virtex-7
  • More
  • Virtex-6
  • Spartan-6
  • Less