05-21-2019 11:22 AM
05-21-2019 12:51 PM
First, why do you care?
Just use the existing SEM IP feature of frame replace correction. It is provided, for free, tested and working.
Xilinx* created the SEM IP core just because they (we) were tired of answering questions like yours.
*Ken Chapman and I created The SEM IP, and as I am no longer with Xilinx, I do not have to answer or advise anyone. But I do wonder why someone would choose not to use the free and tested solution to do exactly what they describe, if only to learn what feature(s) are missing from the SEM IP core as I still use Xilin FPGAs, and as a customer, I can make requests, especially if they benefit my new employer.
05-22-2019 04:40 AM
I really appreciate your work on the SEM IP. I do care because, for example, there may be more than one error detected by SEM. Then I have to react at a higher level, at the system level, and I wonder what possibilities I have. Or I might consider using Detect Only mode and then it would be useful to know what to do next after detecting the error.
For the second part of my question, knowing how to link a reported frame (LFA) with a particular module in my application would also allow me to assess how critical this problem is (because we know that SEM has a certain latency time in error detection, in which different things can happen when there is an error in the configuration memory).
I have one more thing I would like to make clear. Maximum Number of Configuration Frames is lower than all configuration frames in the device. I understand that it is not important which frames they are, but it is important that the whole design does not exceed this maximum number of frames? And if you have the time to write briefly why this limitation is, I would be grateful, I'm just curious.
Finally, I want to use SEM, which means that I care about the reliability of the design. And personally I feel better about doing something with high reliability when I know the mechanisms that are responsible for it :)
05-22-2019 10:02 AM
It is almost never that you get two non-adjacent upsets. Just does not happen. If you use frame replace 100% of upsets are repaired. If the SEM IP itself is hit is the only way this fails.
You do not need to know what frame, you need to know framne and bit. That would require a complete map of actual critical bits themselves, injecting faults one by one to find those that break your design (I have never heard of anyone doing that, ever). I am aware of people doing random fault testing to find out how a design acts, find the architectual vulnerability factor (roughly how many upsetrs it takes to break a design as not all upsets affect the design -- typically only 1 in 20 break a design).
Max number of frames are in the data sheet, and when you create your repair by replace file you will have all type 2 frames in your design.