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: 
Visitor rockrs2001
Visitor
531 Views
Registered: ‎04-08-2019

ICAP internal readback then CRC

I've read that the configuration data can be read back and CRC'ed but that a 'msk' bitmask file must be used to mask out the potentially changing bits that would change the CRC value.  I'm trying to find a more workable solution and calculate or obtain internally a CRC for specific load.

I'm also confused about the block types listed as part of the Frame Address Register (FAR) in the ICAP.  There are 3 usable block types: 000-CLB, IOB, Clks ; 001 Block Rams ; 010 CFG CLBs.

Is there a way to limit the block type of readbacks to eliminate possible changing bits? . Can one read, for example, just the CFB CLBs to get a CRC value that indicates that this is a specific version of the FPGA?

I've also read that there is a primitive FRAME_ECC that can mask the data on the fly and run a continuous CRC without the mask file. Is there a way to get at the calculated CRC value inside the series 7 FPGAs?

Thanks for any help,

Richard

0 Kudos
9 Replies
Highlighted
Xilinx Employee
Xilinx Employee
424 Views
Registered: ‎01-10-2012

Re: ICAP internal readback then CRC

@rockrs2001 

Can you please let us know what is the aim/goal on what you want to implement?

The specific CRC queries and block type info is limited to what is documented in the UG, So perhaps we can come suggest you an alternative if we know what is that you are trying to achive.

If its just for revision check/control there might be other simpler alternatives.

 

 

Visitor rockrs2001
Visitor
412 Views
Registered: ‎04-08-2019

Re: ICAP internal readback then CRC

I need to get a CRC value of the internal configuration load, not just for version but to confirm at the system level that this load does not have an SEU or other error and that it has not been tampered with. I can't use just a bit that indicates it's ok becuase it easy to spoof.

I was hoping not to have to read in a .msk file to mask off the changing bits and then internally CRC the ICAP configuration readback.

 

Thanks for your help.

 

-Rick

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

Re: ICAP internal readback then CRC

Hi @rockrs2001,

I’m wondering would enabling POST_CRC be an option which can have a PRE_COMPUTED CRC generated and you could also monitor the output of the FRAME_ECC to check for errors if you required testing.

FRAME_ECC is further documented in UG470 and UG953

https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_3/ug953-vivado-7series-libraries.pdf

Some testing I’ve done recently.

Enable POST_CRC with the following settings.

     set_property POST_CRC ENABLE [current_design]

     set_property POST_CRC_ACTION CONTINUE [current_design]

     set_property POST_CRC_INIT_FLAG ENABLE [current_design]

     set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]

If you check the bitstream, you’ll see the PRE_COMPUTED value in there.

When post-configuration CRC check is in pre-computed mode, it’s covering the path from config logic into CRAM, and then also covers unexpected runtime changes in CRAM. 

 

Then you could test error injection by changing the PRE_COMPUTED value. However, you’d first need to turn off normal CRC for bitstream loading.

     set_property BITSTREAM.GENERAL.CRC DISABLE [current_design]

     set_property POST_CRC ENABLE [current_design]

     set_property POST_CRC_ACTION CONTINUE [current_design]

     set_property POST_CRC_INIT_FLAG ENABLE [current_design]

     set_property POST_CRC_SOURCE PRE_COMPUTED [current_design]

Monitoring the output of the FRAME_ECC signals via an ILA will show the CRC error.

 

If this is an option for you, we can certainly provide more details in the thread.

 

Thanks,
Wendy
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
399 Views
Registered: ‎09-17-2018

Re: ICAP internal readback then CRC

Type 2 frames,

Are the static configuration.  LUTRAM (LUTROM), SRL are masked (all 1's).  So, one could readback all type 2 frames, and compute a CRC.  That is what the readback CRC does for you, but that golden CRC is not visible to you.

Or, you could use the SEM IP core to do everything for you (I invented it, so believe me, just use it, everyone from security [NSA] to safety critical [planes, trains, automobiles] uses it).  It is recognized by certifying agencies (in fact, required).

l.e.o.

Visitor rockrs2001
Visitor
386 Views
Registered: ‎04-08-2019

Re: ICAP internal readback then CRC

With the ICAP and using block type 2 frames, I'm going to try to read back and CRC the configuration that has changing Block RAMs/ LUTRAMs to see if I can get a steady and different CRC across several loads and on each load, PR a wire to see if this changes the CRC computed. Thanks,
0 Kudos
383 Views
Registered: ‎09-17-2018

Re: ICAP internal readback then CRC

r,

BRAM is not in type 2 (only their static configuration).

As stated, LUT memory, SRL are masked to 1's on readback.  This is done by the GLUT MASK CRAM bit in a CLB tile, which is set by Vivado when LUT are used for dynamic memory.

l.e.o.

 

0 Kudos
Visitor rockrs2001
Visitor
298 Views
Registered: ‎04-08-2019

Re: ICAP internal readback then CRC

l.e.o. ,

I think you have the answer I need to calculate a constant CRC value from periodically reading back the ICAP using block type 2 frames.  However I must have missed something in my experiment. 

I set the ICAP CTL0 mask regester to 0x100 and wrote 0x000 to the CTL0 register to turn off the ICAP CTL0 GLUT_MASK_B bit in the control regester.  Then I read back the configuration load through the ICAP using block type 2 frames twice.  The readbacks were different from each other.

Do you have an idea af where I'm going wrong?

 

Thanks,

0 Kudos
290 Views
Registered: ‎09-17-2018

Re: ICAP internal readback then CRC

If it is changing,

Then GLUT_Mask is not set, so it is reading dynamic LUTRAM and SRL values.  GLUT_Mask bits must ALL be set for all LUTRAM, SRL, or else you cannot get a good static repeatable CRC.  Understand the CRC you are calculating is only useful to you, as you cannot force load the RBCRC (golden CRC), and it is different from a bitstream CRC at the end of configuration.  It is also only good for the type two frames for this exact .bit file.

l.e.o.

0 Kudos
Visitor rockrs2001
Visitor
262 Views
Registered: ‎04-08-2019

Re: ICAP internal readback then CRC

l.e.o

At this time I'm only trying to set the ICAP:CTL0:GLUT_MASK_B bit and nowhere else. Then read back the type 2 frames to compute a load-consistant, readback CRC to store off for this internal readback.

In Vivado with a K7 device, Is there another place I should be setting the GLUT_MASK:yes or some other mask enable?  Is there another required setting?

I'm working with our Software team to be sure and verify that we have read the ICAP:CTL0 register back and that it is set properly and that the frame block type is definately type 2 frames.

Thanks for all your help.

 

-Rick

0 Kudos