AR# 67645

|

Design Advisory for 7 Series and UltraScale Architecture FPGA configuration fallback and POST_CRC limitation

描述

This Design Advisory covers the readback CRC functionality in 7 Series and UltraScale/UltraScale+ devices after a Configuration Fallback has occurred.

Issue:

The readback CRC (POST_CRC) does not operate when a golden/fallback bitstream is loaded by a configuration error+fallback condition from a SPI/BPI(2) flash.

Affected devices(1):

  • 7 Series FPGAs
  • UltraScale and UltraScale+ FPGAs

Affected system - when ALL of the following are true with an affected device:

  • FPGA configuration by SPI or BPI(2) mode from a flash memory
  • FPGA, flash memory, and bitstreams set for config MultiBoot (via IPROG) and fallback (BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE)
  • POST_CRC enabled (or use of the Soft Error Mitigation IP or the Security Monitor IP) in the fallback bitstream

Notes:

  1. Zynq-7000 and Zynq UltraScale+ MPSoC devices are NOT affected
  2. BPI Exception: Systems using BPI mode MultiBoot+fallback and FPGA RS[1:0] pins to select a flash address range for bitstream loading instead of the embedded IPROG command are NOT affected.

Customer impact:

When a fallback occurs due to an issue with an update bitstream and instead loads/runs the golden/fallback bitstream in an affected system, the POST_CRC does not operate in the fallback bitstream.

This can result in undetected soft errors or undetected configuration memory changes. The Soft Error Mitigation (SEM) controller and Security Monitor (SecMon) IP depend on POST_CRC.

Use of these IPs will indicate that the readback CRC issue has occurred.

The SEM controller IP detects the readback CRC issue during its startup and will not deassert its status_initialization signal.

The Security Monitor IP will detect the readback CRC issue during its startup self tests and will not assert its SM_INIT_DONE signal.

解决方案

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

Basic Workaround: 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 designs:
    • For UltraScale/Vivado: XAPP1191 bitstream revision selection
    • For 7 Series/ISE: XAPP1081 bitstream selection switch

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(1) 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(1) 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.

附件

文件名 文件大小 File Type
AR67645.zip 43 KB ZIP
AR# 67645
日期 12/12/2016
状态 Active
Type 设计咨询
器件 More Less
People Also Viewed