07-23-2018 09:48 AM
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?
07-23-2018 10:08 AM
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.
07-23-2018 10:12 AM
07-23-2018 10:40 AM
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?
07-23-2018 11:20 AM
07-26-2018 09:14 AM
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).