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: 
Voyager
Voyager
1,434 Views
Registered: ‎05-30-2018

Enabling FPGA programming with injected errors

Hello,

I've already created a post in relation with injection errors in the bitstream.

The story turned out to be more complicated than I thought.

If I modify bitstream (i.e. inject errors in a "healthy" bitstream) and try to program FPGA with "CRC check" enable, it fails.

If  I corrupt bitstream and program FPGA with "CRC check" disable, it works, but for my exercise (i.e. testing FRAME_ECC2) it has no sens, because new CRC value is calculated during programming, that takes into account corrupted bits and such corrupted bitstream is considered by CRC control staff as non-corrupted.

So my question is: does exist some option that deactivates invalidation of FPGA programming with corrupted bits (I hope that you understand what I mean).

Thanks.

 

0 Kudos
14 Replies
Xilinx Employee
Xilinx Employee
1,409 Views
Registered: ‎06-06-2018

Re: Enabling FPGA programming with injected errors

Hi @pavel_47,

 

I belive you meant how to disable FPGA Programming from incorrect bitstream. If you meant it like that, then CRC enabling is the only way. 

 

Regards,

Deepak D N

-------------------------------------------------------------------------------------------------------------------------------------------

Please Reply or Give Kudos or Mark it as an Accepted Solution.

-------------------------------------------------------------------------------------------------------------------------------------------

0 Kudos
Moderator
Moderator
1,392 Views
Registered: ‎01-15-2008

Re: Enabling FPGA programming with injected errors

Hi Pavel,

probably you can use the SEM IP & try to inject errors and then use the frame_ecc2 as mentioned in the following link

https://www.xilinx.com/support/answers/54350.html

SEM IP => https://www.xilinx.com/support/documentation/ip_documentation/sem/v4_1/pg036_sem.pdf

 

--Krishna

0 Kudos
Moderator
Moderator
1,385 Views
Registered: ‎01-15-2008

Re: Enabling FPGA programming with injected errors

SEM IP includes frame_ecc2, so you dont need to instantiate again .

so you can inject error and detect through SEM IP controller. does this not help in your case?

0 Kudos
Voyager
Voyager
1,378 Views
Registered: ‎05-30-2018

Re: Enabling FPGA programming with injected errors

Hi Deepak,

I belive you meant how to disable FPGA Programming from incorrect bitstream.

Well, to be more precise I want to disable invalidation of a corrupted bitstream once it's injected into a device.

Here is extract from UG470 (pp. 105 - 106) - bitstream composition for devices 7-series.

7series_bitstream_composition.jpg

Actually there are 2 locations for CRC:

  • placeholder for actual CRC value (calculated by FPGA itself during FPGA programming) - red square
  • CRC value, calculated by Vivado during generating of a bitstream - blue square

If, after FPGA programming, these two values are different, the bistream is rejected and device proceed with some kind of roll-back, isn't it ?

What is actually occured ... if I flip some bit in payload and try to use this corrupted bitstream to program device, the blue CRC (Vivado version) is different from the red CRC (device version) ... and such bitstream is rejected.

If I disable "CRC check" (option in project settings in Vivado), the blue CRC isn't calculated and indeed, I can flip a bit (i.e. corrupt bitstream) and use this corrupted bitstream to program FPGA.

So, if my comprehension is correct with disabled "CRC check" only red CRC is calculated by device. But for this red CRC there is no errors because a bit was corrupted before passing the corrupted bitstream into device. In other words this corrupted bitstream "is legitimate" for red CRC.

And consequently FRAME_ECC2 primitive will not detect any errors, so my initial goal (i.e. evaluate the performance of FRAME_ECC2) is not achieved.

So, my question is: is it possible to disable invalidation of a corrupted bitstream, i.e.

  • inject a corrupted bistream with "CRC check" enable, i.e. blue CRC is calculated and bitstream isn't rejected but accepted
  • use blue CRC as reference CRC for FRAME_ECC2 operation

Possible ?

Thanks

 

Tags (2)
0 Kudos
Voyager
Voyager
1,375 Views
Registered: ‎05-30-2018

Re: Enabling FPGA programming with injected errors

Hi Krishna,

Well, I will explore this track.

At first glance it sounds Ok ... though it's a bit ambiguous: error injection staff and error reparation staff are gathered in the same module ... not very clear how to combine two opposite actions.

 

0 Kudos
Xilinx Employee
Xilinx Employee
1,362 Views
Registered: ‎06-06-2018

Re: Enabling FPGA programming with injected errors

Hi @pavel_47,

 

Red Square indicates CRC value calculated, during Bitstream generation.

Blue Square indicates, As the configuration data frames are loaded, the device calculates a Cyclic Redundancy Check (CRC) value from the configuration data packets. After the configuration data frames are loaded, the configuration bitstream can issue a Check CRC instruction to the device, followed by an expected CRC value. If the CRC value calculated by the device does not match the expected CRC value in the bitstream, the device pulls INIT_B Low and aborts configuration.

 

If, after FPGA programming, these two values are different, the bistream is rejected and device proceed with some kind of roll-back, isn't it ?

If there is single Bitsream then there will be no Fallback, and INIT_B goes low.  If you are using multiboot concept then it will fallback to golden bit file.

 

So, my question is: is it possible to disable invalidation of a corrupted bitstream, i.e.

  • inject a corrupted bistream with "CRC check" enable, i.e. blue CRC is calculated and bitstream isn't rejected but accepted
  • If you inject corrupted Bitstream, In CRC check, error will be detected and INIT_B goes low (configuration stops).
  • use blue CRC as reference CRC for FRAME_ECC2 operation
  • I didnt understand about taking refernce. But device will calculta CRC value and compares it with the CRC value generated during Bitstream generation. So tool is doing this job.
  • CRC value is calculated for the whole bitstream. In FRAME_ECC2, CRC value will be calculated for each packet. 

 

Regards,

Deepak D N

---------------------------------------------------------------------------------------------------------------

Please Reply or Give Kudos or Mark it as an Accepted Solution.

---------------------------------------------------------------------------------------------------------------

0 Kudos
Voyager
Voyager
1,353 Views
Registered: ‎05-30-2018

Re: Enabling FPGA programming with injected errors

Hi Deepak,

Red Square indicates CRC value calculated, during Bitstream generation.

No. After Bitstream generation this value is 0x00000000. I've checked it in a generated bitstream.

Blue Square indicates, As the configuration data frames are loaded, the device calculates a Cyclic Redundancy Check (CRC) value from the configuration data packets....

Here I didn't properly understand what you mean. Anyway, this value is already present in the generated bitstream if "CRC check" is set to ENABLE. If "CRC check" is disabled, this value is 0x0000000 and previous command in the bitstream isn't related to CRC. I suppose that this value serve as "expected CRC" (as you say) for comparing with CRC value calculated by the device.

If there is single Bitsream then there will be no Fallback, and INIT_B goes low.

Again, I didn't understand clearly: you mean the if there is a difference between CRC value calculated by the device and the golden one (i.e. blue CRC), there is no Fallback ? According to what I've experienced, in the case of such difference, the new bitstream isn't accepted and device return to its previous state. By the way I don't understand how does it work ... it sounds that device should be capable to keep 2 bitstreams at the same time: the new bistream and the old one (that is resumed if the new one is considered as corrupted)

If you inject corrupted Bitstream, In CRC check, error will be detected and INIT_B goes low (configuration stops).

It's what I'm precisely looking for ... deactivate error detection just after device programming, but once programmed, activate it again.

I didnt understand about taking refernce. But device will calculta CRC value and compares it with the CRC value generated during Bitstream generation. So tool is doing this job.

Here I mean once device start to operate, where CRC check staff picks the golden CRC value: blue CRC which is part of bitstream or CRC value calculated by the device (that is stored somewhere in a dedicated FPGA register).

CRC value is calculated for the whole bitstream. In FRAME_ECC2, CRC value will be calculated for each packet.

Hmm.. According to what I've learned, FRAME_ECC2 calculates a specific value called "syndrom" (that indeed indicate the presence (or not) of errors inside a frame. Thi value of this syndrome is calculated from ECC code (not CRC), that is stored in the middle of each frame.

Sincerely

Pavel

 

0 Kudos
Highlighted
1,337 Views
Registered: ‎01-22-2015

Re: Enabling FPGA programming with injected errors

@pavel_47

I’m no expert on this topic, but here is what I understand from reading the Xilinx documentation.

  1. Don’t confuse “Normal-Loading” of the bitstream during FPGA power-up with “Readback-CRC”.
    During Normal-Loading of the bitstream, the FRAME_ECCE2 primitive and (what you call) the “red square” value are not used. Instead, CRC checking is done using the CRC register (see pg 110, UG470). That is, the CRC register is used by the FPGA to calculate a CRC value as the bitstream is loaded. Then, near the end of bitstream loading, a CRC value stored in the bitstream file is compared to the value found in the CRC register. If the two values match then FPGA startup is allowed to continue.

    Readback-CRC is something that occurs after the FPGA is configured/running and is done in the background of the user design (see Chap 8 of UG470). Its purpose is to detect corruption of the FPGA configuration memory that might occur (eg. by ionizing radiation). Readback-CRC uses the FRAME_ECCE2 primitive (see pg 297 of UG953) and could use (what you call) the “red square” value.

  2. There are many “blue square” values in the bitstream.
    The “blue square” values (as you call them) in the bitstream have the Packet Header, hex(3000 0001), which Tables 5-20 thru 5-23 of UG470 identify as “Write CRC Register”. Comments in Table 5-19 indicate “(If written CRC does not match computed CRC value, then error)”. I’m not sure why there is more than one “blue square” value in the bitstream – perhaps some are intermediate checks of the bitstream CRC. However, a “blue square” value found near the end of the bitstream must contain the CRC value that validates the entire bitstream. I believe that these “blue square” values are used only during Normal-Loading of the bitstream and not during Readback-CRC.

  3. The “red square” value is optional. 
    I believe that the “red square” value is used only by Readback-CRC and is optional. As described on about page-298 of UG912, the “red square” value is the CRC value for the entire bitstream that is calculated by Vivado if you use the POST_CRC_SOURCE=PRE_COMPUTED constraint. If you do not use this constraint, then Readback-CRC (ie. the FPGA) will compute the CRC value for the entire bitstream (again see pg298 of UG912).

  4. Manual corruption of bitstream will affect Normal-Loading (if CRC checking is enabled) but may not affect Readback-CRC.
    Unless you use the POST_CRC_SOURCE=PRE_COMPUTED constraint, your manual corruption of the bitstream should not be detected by Readback-CRC (and the FRAME_ECCE2 primitive) because they check only for bitstream corruption that occurs after the bitstream is loaded (eg. by ionizing radiation).  -again, see page-298 of UG912.

  5. Xilinx recommends using the Soft Error Mitigation (SEM) IP instead of Readback-CRC. -see page-298 of UG912 and document, PG036.


So, if your exercise is to test the FRAME_ECCE2 (ie. ensure that it detects a corrupted bitstream) then I suspect you should do all of the following:

  • Disable CRC checking during Normal-Loading of the bitstream
  • Use the following XDC constraint:
         set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]
  • Manually flip some bit(s) in the bitstream file or manually change the “red square” (precomputed CRC) value.

Cheers,
Mark

Voyager
Voyager
1,298 Views
Registered: ‎05-30-2018

Re: Enabling FPGA programming with injected errors

Hi Mark,

Very good summary of problems ! Thanks.

Here are my comments


markg@prosensing.com wrote:

@pavel_47

I’m no expert on this topic, but here is what I understand from reading the Xilinx documentation.

  1. ... Then, near the end of bitstream loading, a CRC value stored in the bitstream file is compared to the value found in the CRC register. If the two values match then FPGA startup is allowed to continue.

With one of two "blue CRC" values I suppose.

Readback-CRC is something that occurs after the FPGA is configured/running and is done in the background of the user design (see Chap 8 of UG470). Its purpose is to detect corruption of the FPGA configuration memory that might occur (eg. by ionizing radiation). Readback-CRC uses the FRAME_ECCE2 primitive (see pg 297 of UG953) and could use (what you call) the “red square” value.

Here I'm not sure: according to my understanding it's FRAME_ECCE2 that uses Readback-CRC staff: at least FRAME_ECCE2 primitive has CRCERROR output. ... and could use (what you call) the “red square” value. Sure, it must use some reference. I didn't find any information when "red Square" is filled and with which value. If it's filled with CRC Register value at the end of bitstream loading it seems logic.

  1. There are many “blue square” values in the bitstream.
    The “blue square” values (as you call them) in the bitstream have the Packet Header, hex(3000 0001), which Tables 5-20 thru 5-23 of UG470 identify as “Write CRC Register”. Comments in Table 5-19 indicate “(If written CRC does not match computed CRC value, then error)”. I’m not sure why there is more than one “blue square” value in the bitstream – perhaps some are intermediate checks of the bitstream CRC. However, a “blue square” value found near the end of the bitstream must contain the CRC value that validates the entire bitstream. I believe that these “blue square” values are used only during Normal-Loading of the bitstream and not during Readback-CRC.
    Actually the two ones ... and filled with different values (I've checked in bitstream)
  1. The “red square” value is optional. 
    I believe that the “red square” value is used only by Readback-CRC and is optional. As described on about page-298 of UG912, the “red square” value is the CRC value for the entire bitstream that is calculated by Vivado if you use the POST_CRC_SOURCE=PRE_COMPUTED constraint. If you do not use this constraint, then Readback-CRC (ie. the FPGA) will compute the CRC value for the entire bitstream (again see pg298 of UG912).

I understood page-298 in another way: with PRE_COMPUTED the Readback-CRC uses the value calculated by FPGA during bitstream loading that is initially located in CRC Register and can be (optionally ???) be copied in the "red CRC" placeholder of the loaded bitstream.

With FIRST_READBACK option the CRC is calculated (and saved into CRC register) when user proceed with 1st readback (using either of config intefaces ... JTAG, SelectMAP, ICAP or PCAP (only for Zynq devices)). So if user doesn't proceed with reedback, the CRC is never calculated ... at least it's my understanding.

I also didn't understand what you mean saying "... for the entire bitstream". To my opinion, the CRC is always calculated for the entire bitstream

  1. Manual corruption of bitstream will affect Normal-Loading (if CRC checking is enabled) but may not affect Readback-CRC.
    Unless you use the POST_CRC_SOURCE=PRE_COMPUTED constraint, your manual corruption of the bitstream should not be detected by Readback-CRC (and the FRAME_ECCE2 primitive) because they check only for bitstream corruption that occurs after the bitstream is loaded (eg. by ionizing radiation).  -again, see page-298 of UG912.

Well, I suppose that manual corruption of the bitstream can affect Readback-CRC if one of "blue CRC" (i.e. CRC calculated during bitstream generation in Vivado) could be put in CRC register or some other location that serves as golden reference for Readback-CRC operation.

  1. Xilinx recommends using the Soft Error Mitigation (SEM) IP instead of Readback-CRC. -see page-298 of UG912 and document, PG036.

This IP is composed from FPGA fabric that is under configuration bitstream control. So, injecting errors in the bitstream, one can "damage" this IP. There is another approach at least for Zynq devices that is adapted by NASA. This approach suppose using ARM devices for detecting errors in configuration bitstream. 


So, if your exercise is to test the FRAME_ECCE2 (ie. ensure that it detects a corrupted bitstream) then I suspect you should do all of the following:

  • Disable CRC checking during Normal-Loading of the bitstream
  • Use the following XDC constraint:
         set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]
  • Manually flip some bit(s) in the bitstream file or manually change the “red square” (precomputed CRC) value.
    You mean put one of two "blue square" values (which one ?) into "red square" ?

Cheers,
Mark


Thanks a lot.

Sincerely,

Pavel.

0 Kudos
1,278 Views
Registered: ‎01-22-2015

Re: Enabling FPGA programming with injected errors

Pavel,

     With one of two "blue CRC" values I suppose.     
     Actually the two ones ... and filled with different values (I've checked in bitstream)
Yes, there are multiple “blue CRC” values in the bitstream and they are different. Again, I’m not sure why. However, I understand that during FPGA configuration (Normal-Loading), the FPGA is doing a running-calculation of the CRC value (ie. the running-calculation is updated with every bitstream bit that is clocked into the FPGA). When the FPGA receives a “Write CRC Register” command (which includes a “blue square" value) from the bitstream, this “blue square” value is compared to the running-calculation of the CRC value. If the two don’t match, there is a CRC error. So, I suspect that the “blue square” value near the end of the bitstream is most important since only when the end of the bitstream is being clocked into the FPGA will the FPGA’s running-calculation of the CRC value be ready for a full-bitstream CRC check.

     I didn't find any information when "red Square" is filled
The bitsteam is a file of data.
  Every bit in the bitstream, including the “red square” value is put there by Vivado.

     …can be (optionally ???) be copied in the "red CRC" placeholder of the loaded bitstream.
Page 298 of UG912 says “The POST_CRC_SOURCE property defines the expected CRC value as either coming from a pre-computed value, or as being taken from the configuration data in the first readback pass”. I’m pretty sure that the “pre-computed value” is the “red square” value in the bitstream.

     I also didn't understand what you mean saying "... for the entire bitstream". To my opinion, the CRC is always calculated for the entire bitstream
As I described above, the FPGA does a running-calculation of the CRC as the bitstream is being clocked into the FPGA. So, at different times during bitstream loading, it is possible for the FPGA to compare is current running-calculation against an intermediate CRC value stored in a “blue square” of the bitstream. I’m not sure this is actually done, but this could explain why there are multiple (and different) “blue square” values in the bitstream.

     …or some other location that serves as golden reference for Readback-CRC operation.
Based on above text from page 298 of UG912, I believe the “red square” value is the “golden reference” for readback-CRC when you use the "POST_CRC_SOURCE PRE_COMPUTED" constraint.

     You mean put one of two "blue square" values (which one ?) into "red square" ?
Simply edit the bitstream and change the “red square” value. This should destroy the “golden reference” for readback-CRC.

Mark

0 Kudos
Voyager
Voyager
1,270 Views
Registered: ‎05-30-2018

Re: Enabling FPGA programming with injected errors


Hello Mark
markg@prosensing.com wrote:

Pavel,

     With one of two "blue CRC" values I suppose.     
     Actually the two ones ... and filled with different values (I've checked in bitstream)
Yes, there are multiple “blue CRC” values in the bitstream and they are different. Again, I’m not sure why. However, I understand that during FPGA configuration (Normal-Loading), the FPGA is doing a running-calculation of the CRC value (ie. the running-calculation is updated with every bitstream bit that is clocked into the FPGA). When the FPGA receives a “Write CRC Register” command (which includes a “blue square" value) from the bitstream, this “blue square” value is compared to the running-calculation of the CRC value. If the two don’t match, there is a CRC error. So, I suspect that the “blue square” value near the end of the bitstream is most important since only when the end of the bitstream is being clocked into the FPGA will the FPGA’s running-calculation of the CRC value be ready for a full-bitstream CRC check.

Probably the last "blue square is more important, but it's the 1st one that fixes the payload, i.e. configuration bits.

     I didn't find any information when "red Square" is filled
The bitsteam is a file of data.
  Every bit in the bitstream, including the “red square” value is put there by Vivado.

I checked this value: it's empty ... well 0x00000000

     …can be (optionally ???) be copied in the "red CRC" placeholder of the loaded bitstream.
Page 298 of UG912 says “The POST_CRC_SOURCE property defines the expected CRC value as either coming from a pre-computed value, or as being taken from the configuration data in the first readback pass”. I’m pretty sure that the “pre-computed value” is the “red square” value in the bitstream.

Here I'm not agree: "red square" cannot be pre-computed value because in the generated bitstream its value is 0x00000000. I suppose that this "red-value" (that is, BTW, qualified as placeholder in the comments of table 5-19) can only be filled once bistream inside FPGA and most likely it is filled with CRC Register vale.

     I also didn't understand what you mean saying "... for the entire bitstream". To my opinion, the CRC is always calculated for the entire bitstream
As I described above, the FPGA does a running-calculation of the CRC as the bitstream is being clocked into the FPGA. So, at different times during bitstream loading, it is possible for the FPGA to compare is current running-calculation against an intermediate CRC value stored in a “blue square” of the bitstream. I’m not sure this is actually done, but this could explain why there are multiple (and different) “blue square” values in the bitstream.

I think that "blue square" only matters at first instants after bitstream loading: if its value equal to CRC Register value, calculated during bitstream loading, the new bitstream is accepted, otherwise - rejected. When device start to operate it is rather CRC Register value (or "red square" that should be a copy of it) that serves as "golden" reference for subsequent errors detection.

     …or some other location that serves as golden reference for Readback-CRC operation.
Based on above text from page 298 of UG912, I believe the “red square” value is the “golden reference” for readback-CRC when you use the "POST_CRC_SOURCE PRE_COMPUTED" constraint.

Probably with this PRE_COMPUTED option the "blue square" value is merely copied into the "red square" ?

     You mean put one of two "blue square" values (which one ?) into "red square" ?
Simply edit the bitstream and change the “red square” value. This should destroy the “golden reference” for readback-CRC.

Change the "red square" ... copy "blue square" in it ?

Mark


Sincerely,

Pavel

0 Kudos
1,254 Views
Registered: ‎01-22-2015

Re: Enabling FPGA programming with injected errors

Pavel,

Perhaps you could try the following:

  1. Place the following constraints in your XDC file:
    set_property POST_CRC ENABLE [current_design];  #enable readback-CRC 
    set_property POST_CRC_SOURCE PRE_COMPUTED [current_design];   #this should fill “red square”
    set_property POST_CRC_ACTION CONTINUE [current_design];  #if CRC error, continue CRC checking
    set_property POST_CRC_FREQ 1 [current_design];  #1MHz frequency for CRC checking
    set_property POST_CRC_INIT_FLAG ENABLE [current_design];  #INIT_B flags CRC error
  2. Generate the bitsteam
  3. Does the “red square” now have a nonzero value?
  4. Does the “red square” value match any of the “blue square” values?

Thanks,
Mark

0 Kudos
Xilinx Employee
Xilinx Employee
661 Views
Registered: ‎01-21-2013

Re: Enabling FPGA programming with injected errors

Hi markg@prosensing.com@pavel_47,

 

I’ve recently carried out some testing and so wanted to provide some feedback on this thread.

The 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.

 

I set out to carry out some testing to edit the PRE_COMPUTED CRC value to test error injection.

I used the following settings:

     set_property POST_CRC ENABLE [current_design]; 

     set_property POST_CRC_SOURCE PRE_COMPUTED [current_design];  

     set_property POST_CRC_ACTION CONTINUE [current_design]; 

     set_property POST_CRC_FREQ 1 [current_design]; 

     set_property POST_CRC_INIT_FLAG ENABLE [current_design]; 

 

When the bitstream was generated, I checked the bitstream and observed the value for PRE_COMPUTED CRC. It was nonzero.

I then wanted to test the error injection, so I disabled the general CRC and regenerated the bitstream.

     set_property BITSTREAM.GENERAL.CRC DISABLE [current_design]

     set_property POST_CRC ENABLE [current_design]; 

     set_property POST_CRC_SOURCE PRE_COMPUTED [current_design];  

     set_property POST_CRC_ACTION CONTINUE [current_design]; 

     set_property POST_CRC_FREQ 1 [current_design]; 

     set_property POST_CRC_INIT_FLAG ENABLE [current_design]; 

 

When the bitstream was generated, I checked the bitstream and observed that the value for the PRE_COMPUTED CRC was zero.

As the previous non-zero value was expected, I configured the device.

I had the output signals from the FRAME_ECC connected to ILAs, and was able to observe a CRCERROR.

 

I hope this helps. Please don't hesitate to reply with any queries on my steps above.

Thanks,
Wendy
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
651 Views
Registered: ‎01-22-2015

Re: Enabling FPGA programming with injected errors

Wendy,

Thank you!

Mark

0 Kudos