Solution - Solution

 

Solutions: Avoiding or Clearing the Fallback Condition to Enable POST_CRC Operation

Basic Work-around: Determine if the system requires SEU Mitigation or Security Monitor Functionality in the Fallback design. If not, do not enable POST_CRC (or use of the SEM IP or Security Monitor IP) in the Fallback design.

Avoiding the fallback condition:

• Ensure the flash memory contains a valid update bitstream for the FPGA to successfully load, e.g. immediately restore a bad update image with a good .bit.
• Use BPI mode with RS pin address control for MultiBoot and fallback
• Start with an initial bitstream load that then loads a selected operation bitstream using the MultiBoot method (without fallback).
  Example reference design:
• For UltraScale/Vivado: XAPP1191 bitstream revision selection

If the Basic Work-around is not a fit for your system and you cannot avoid fallback, the fallback condition must be cleared before using POST_CRC. 

The following two work-arounds can be used to clear the fallback condition:

Clearing the Fallback Condition:

• For the golden/fallback image, use a two-stage bitstream load sequence that first loads an initial bitstream which then applies an IPROG reconfiguration⁽¹⁾ sequence to clear the fallback condition and load the operational golden bitstream.
  This is referred to as the Preloader work-around.
• In the golden/fallback FPGA design, implement a check of the configuration boot history (BOOTSTS) register.
  If BOOTSTS indicates that the bitstream was loaded by a fallback event, then apply an IPROG reconfiguration⁽¹⁾ sequence to the Internal Configuration Access Port (ICAP) to reload the golden/fallback bitstream, clearing the fallback condition.
  This is referred to as the Reloader work-around.

Note:

1. See the IPROG Reconfiguration section in the family configuration user guide.

 

The attached AR67645.zip includes files for both the Preloader and Reloader work-arounds described above.

For attachments, refer to the link below:

View Attachment