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# 30214

Spartan-3A/AN - How can multi-boot be used with a design revision manager for a fail safe application?


The Spartan-3A family of devices offers a multi-boot capability. In these applications a design will be running in the FPGA and will re-image the Flash and then trigger a reload of the FPGA. After the Flash has been imaged, the REBOOT command is issued via the ICAP and another image can be loaded into the FPGA.

In these applications a "fail safe" application needs to be created with the hardware and user logic to ensure the system is functional after an error occurs. Errors can occur when the Flash is being erased or programmed. These errors can cause the reboot to fail due to a timeout or CRC error. In this scenario, golden image will be reloaded and the design will have the opportunity to re-image the flash.

If the REBOOT fails, the golden image will be loaded back into the device. At this point, the golden image will need to know what has occurred. Is this the first load of the FPGA? Has the reboot been attempted and failed? Has a reboot been attempted multiple times?

How are multi-boot attempts tracked my the user application, and how should these failures be handled?


The attempts to reboot the FPGA with another image in the flash will have to be tracked by the FPGA and a 'mailbox' in the Flash. The design will need to keep track of reboot attempts and function different based on the status of this flag.

A 'mailbox' can be created at an address location in the Flash. The design should be able to read and write to the Flash, so the infrastructure to support the 'mailbox' system should be in place.

The 'mailbox' will hold the status of the number of trials of a multi-boot application. The flag should be set before a reboot attempt and cleared if this is successful. The new image should clear the flag, and the golden image should always check the flag. If the flag is set, the original design will know that a reboot has been attempted and failed. At this point, the original image should re-program the flash, create the counter in the 'mailbox' and issue a reboot. If this fails, the system might need to be flagged as errors are occurring. If this works at any point the new design will clear the flag.

The new design can also erase the flash and re-program the flash. When this occurs the original design will need to set the bit in the 'mailbox'. If this fails, the original design will be loaded; and if this works, the new design will be loaded and the flag can be cleared.

AR# 30214
Date 12/15/2012
Status Active
Type General Article
Page Bookmarked