UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 

How to do error testing using POST_CRC in 7 Series FPGAs

Xilinx Employee
Xilinx Employee
10 0 242

Note: this blog addresses error testing using POST_CRC, but in general Xilinx recommends using the Soft Error Mitigation (SEM) IP for all architectures.

The Soft Error Mitigation (SEM) IP provides a mechanism to test SEU detection and correction, and provides further debug capabilities.

The feature discussed in this blog is supported for 7 Series devices only.

Feature

7 Series

Kintex® UltraScale™ and Virtex® UltraScale™ Kintex UltraScale+™ and Virtex UltraScale+™

Readback CRC/POST_CRC

Yes

No, use SEM IP instead

No, use SEM IP instead

 

 

Different types of Cyclic Redundancy Checks (CRCs) in Xilinx FPGAs:

 

1) General CRC Checking

During general bitstream loading, CRC checking is done using the CRC register. This ‘CRC Register’ is described in (UG470) 7 Series FPGAs Configuration User Guide.

The FPGA calculates a CRC value as the bitstream is loaded, and that value is compared with the expected CRC value in the bitstream towards the end of bitstream loading. If both values match, then the FPGA successfully loads.

The general CRC check is enabled by default. The bitstream property is BITSTREAM.GENERAL.CRC, where valid options include ENABLE or DISABLE.

2) Readback CRC/POST CRC Checking

POST_CRC checking occurs after the FPGA is configured, while the design is running.

The general bitstream CRC check is an independent feature and has a CRC check register of its own. 

The post-configuration CRC check has a different register for storing the check value.

 

What is the purpose of enabling POST_CRC checking?

The purpose of enabling POST_CRC checking is to allow for detection of Single Event Upsets (SEU). SEUs cause configuration memory bits to flip.

POST_CRC can be used together with the FRAME_ECCE2 primitive, to provide extra functionality and better visibility of such errors.

The outputs of the FRAME_ECCE2 can be leveraged to monitor the status of the Error Correction Code (ECC) and readback CRC circuitry.

For further details on the FRAME_ECCE2 primitive, please see (UG953): Vivado Design Suite 7 Series FPGA and Zynq-7000 SoC Libraries Guide.

Users often want to test an example of this corruption occurring, in order to ensure that such errors are successfully detected.

One way to test error injection is by editing the PRE_COMPUTED CRC value.

 

Steps to test error injection:

Place the following settings in the design XDC:

set_property POST_CRC ENABLE [current_design]
#Enables the Post CRC checking

set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]
#Determines an expected CRC value from the bitstream

set_property POST_CRC_ACTION CONTINUE [current_design]
#Even if a CRC error is detected, continue CRC checking.
#Other options include HALT, CORRECT_AND_CONTINUE and CORRECT_AND_HALT

set_property POST_CRC_INIT_FLAG ENABLE [current_design]
#Leaves the INIT_B pin enabled as a source of the CRC error signal. Useful especially if FRAME_ECC is not used

 

For further details on these settings, see (UG912) Vivado Design Suite Properties Reference Guide.

Run through the design flow and generate the bitstream.

When the bitstream is generated, the value for the PRE_COMPUTED CRC can be checked in the .bit file.

It will be non-zero.

image2.png

 

To determine where the PRE_COMPUTED CRC value would be in the bitstream, check the sample 7 Series bitstream in (UG470) 7 Series FPGAs Configuration User Guide.

image3.png

 

To test error injection, you will want to disable the general CRC check to allow for the successful loading of the bitstream.

Remember, if any edits are done to the bitstream inside the scope of the normal CRC coverage, this will flag a CRC error and prevent the bitstream from loading.

To disable the general CRC check, you should use the settings below:

set_property BITSTREAM.GENERAL.CRC DISABLE [current_design]
#Disables the general CRC checking

set_property POST_CRC ENABLE [current_design]
#Enables the Post CRC checking

set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]
#Determines an expected CRC value from the bitstream

set_property POST_CRC_ACTION CONTINUE [current_design]
#Even if a CRC error is detected, continue CRC checking.
#Other options include HALT, CORRECT_AND_CONTINUE and CORRECT_AND_HALT

set_property POST_CRC_INIT_FLAG ENABLE [current_design]
#Leaves the INIT_B pin enabled as a source of the CRC error signal. Useful especially if FRAME_ECC is not used

 

Run through the design flow again and generate the bitstream.

 

When the bitstream is generated, you should observe that the value for the PRE_COMPUTED CRC is zero. This is a result of disabling the GENERAL.CRC, to allow for testing of an error.

As the previous non-zero value was expected, configure the device and observe the behavior.

Monitoring of the INIT_B pin should show the CRC error.

 

FRAME_ECCE2 can also be used to have the output signals from the FRAME_ECCE2 connected to ILAs. It will then be possible to observe a CRCERROR.

The below instantiation can be used for the connection of the FRAME_ECCE2 primitive:

image5.png

The outputs can then be passed to an ILA.

 

When the device is programmed, it should be possible to view output similar to the example below by checking the signals on the ILA.

For example, a CRCERROR flagged because the expected non-zero PRE_COMPUTED value is not found.

image6.png

 

Understandably, most users want to test error detection to be certain that when such errors are detected, they will be reported in some form. This testing allows users to be confident that in a real scenario, the error will be correctly detected and reported.

 

As previously stated, Xilinx recommends using the Soft Error Mitigation (SEM) IP rather than POST_CRC due to the capabilities offered by the SEM IP. POST_CRC is not a feature that is supported in later architectures.