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 rharker
Visitor
845 Views
Registered: ‎06-21-2018

Continuous verification of configuration after programming

I'm working on an application for a high EMI environment and need to constantly verify the configuration of an FPGA to ensure that the circuit isn't being damaged/altered by the noise.  I know I can do it prior to programming the device, but how do I go about reading/verifying the configuration of a chip that's already been programmed?  Is there a way to access the LUTs from the JTAG header?  I don't need to know where the problem occurs, only whether something's been altered.  A go/no go scenario, where any change causes me to halt the chip.  If not JTAG, is there any other way for me to accomplish this?  

0 Kudos
6 Replies
Highlighted
Explorer
Explorer
834 Views
Registered: ‎05-08-2018

Re: Continuous verification of configuration after programming

rh,

 

For continuous RBCRC checking, in 7 series, this is a bitstream option in bitgen.  INIT_b will assert if a configuration bit changes value.  It does not check data in BRAM, does not check LUT used as SRL or LUTRAM, and does not check any DFF.  It is 100% check for any upset value for all of the static configuration.

 

You may wish to use the free SEM IP core instead, as it provides more information, and provides status to your design so you may take action from your design (I recommend this).

 

In any safety critical system, use of the SEM IP is required.

 

Use of BRAM ECC or parity, use of parity in all internal data paths is also good practice.

 

SEM IP was productized in Virtex 4, depricated for V4 due to test issues, re-supported in Virtex 5 as XAPP 864 (now obsolete), re-introduced in Virtex 6, and has been stable with new features at each new technology node.

 

It is used as an anti-tamper defense in secure systems as well as for safety critical systems. It is not for use in space, as space has its own versions which apply.

 

Moderator
Moderator
830 Views
Registered: ‎06-05-2013

Re: Continuous verification of configuration after programming

Vivado® IDE can verify and/or readback the configuration data (i.e., .bit file) downloaded into an FPGA. When using write_bitstream to generate the .bit file, use the -mask_file option to create a corresponding mask (.msk) file. For more check UG#908 Chapter 7.

Use the readback_hw_device Tcl command with at least one of the following options to
read back the FPGA configuration data:
• To save readback data in ASCII format:
-readback_file <filename.rbd>
• To saves readback data in binary format:
-bin_file <filename.bin>
Example: Readback FPGA configuration data in both ASCII and binary formats
readback_hw_device [current_hw_device] \
-readback_file kcu105_cnt_ila_uncmpr_rb.rbd \
-bin_file kcu105_cnt_ila_uncmpr_rb.bin
Note:
1. Bitstream, and readback operations are done through the Tcl Console.
2. Verify and readback operations do not work for FPGAs programmed with encrypted
bitstreams. Encrypted bitstreams contain commands that disable readback. Readback is re-enabled by pulsing the FPGA PROG pin, or if the FPGA/board is powered down and powered back up again.
3. The data readback using readback_hw_device contains configuration data only (no configuration commands are included).

Also you can refer to following XAPP https://www.xilinx.com/support/documentation/application_notes/xapp1230-configuration-readback-capture.pdf for configuration readback.

Thanks
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Tags (1)
Visitor rharker
Visitor
817 Views
Registered: ‎06-21-2018

Re: Continuous verification of configuration after programming

Thanks, both of these options seem to be viable, especially in the design phase.  The IP solution seems promising, but is there any way I can get the latency down to sub-ms?  

0 Kudos
Moderator
Moderator
803 Views
Registered: ‎06-05-2013

Re: Continuous verification of configuration after programming

Refer to performance section on page# 21 https://www.xilinx.com/support/documentation/ip_documentation/sem_ultra/v3_1/pg187-ultrascale-sem.pdf

Thanks
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor rharker
Visitor
752 Views
Registered: ‎06-21-2018

Re: Continuous verification of configuration after programming

Is there anything similar for the CPLD devices?  

0 Kudos
Explorer
Explorer
747 Views
Registered: ‎05-08-2018

Re: Continuous verification of configuration after programming

rh,

 

Nope.  No way to verify the CPLD shadow memory (SRAM based) is unchanged.  The Flash eprom memory cells get transfered to the shadow SRAM during power-on.  The flash is unlikely to be corrupt as these cells were designed for 10K+ programming cycles and cannot be upset by atmospheric neutrons (terrestrial rad hard).  The shadow SRAM will be upset by atmospheric neutrons, but due to the older technology, and only a few hundred thousand bits, the mean time between upsets is long (~100 years or more).  Of course, every time the CPLD device is powered on, the SRAM is re-written.

 

I would not use any CPLD from any vendor in a safety critical system (my personal opinion), as there is no way to verify it is without fault (unlike the FPGA device which is 100% verifiable).

0 Kudos