Forum Discussion
Hi,
- Can you provide details on the test procedures you have performed (JESD-89) ?
This question is sufficiently answered.
- Can you provide numerical data - or some sort of report of your testing ?
The reliability report you are referring to does not contain the data I was looking for.
The reliability report contains the data for life time testing under temperature and humidity cycling (mainly JESD22, as declared in Table II and Table II of the mentioned document).
It however does not contain results of the JESD-89 testing.
I am looking for a report explicitly dealing with the SEU testing mentioned on the website in my initial post.
- Can you elaborate on the statement to the error detection capability of the CRC circuit ?
I am not sure I fully understand your arguments.
I am quite aware how the CRC function within the FPGA works, and how it does read back the bitfile, constantly checking the CRC within the bitfile (desired value), with the one computed (actual value).
In case of a mismatch between those two an error is raised.
As an "end user" I do not mind whether the circuitry actually counts the number of errors or not. For any number of errors the mitigation is identical. The bitfile has to be (re-)programmed into the device.
A CRC however has (as any other error detection algorithm) a limited detection capability.
The total size of the configuration RAM within the device has a large amount of bits. An EP4CE40 device has an uncompressed raw binary size of 9'534'304 bits.
Therefore the (theoretical worst case) would be to have 9'534'304 errors (meaning each single bit has flipped)
Mathematically a CRC is only able to detect certain types of errors. It can for example detect any single bit error. That is regardless of which of the 9’534’304 bits flip, the CRC will detect it.
The situation however changes when multiple bits are flipped. In this case the error detection will only be able to detect the change with a certain probability.
The exact performance depends not only on the CRC polynomial but also on the length of the bit file stream and the location of the flipped bits (you may refer to https://users.ece.cmu.edu/~koopman/crc/ for some details).
If a single event can cause multiple bits to flip you need to apply some additional constrains to be able to claim 100% detection ratio.
Such an additional constraint might be that the flipped bits are located close to each other.
This is the kind of information I was asking for.