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):
Affected system - when ALL of the following are true with an affected device:
Notes:
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:
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:
Note:
The attached AR67645.zip includes files for both the Preloader and Reloader work-arounds described above.
文件名 | 文件大小 | File Type |
---|---|---|
AR67645.zip | 43 KB | ZIP |