From Jangi on the Web Case she/he claims that ECC works - but the status register might not...
So will await clarification of this with much interest.
The key problem that I see is we try to say "Here buy this ECC protected box, sorry we can't demonstrate that it works, just trust us that when that cosmic ray hits it will protect you ..." is not going to make for a good sales line. :-)
Thanks Austin - see what turns up next week.
This has gotten a few folks eye, so there are people actively looking at it right now.
Xilinx never asks anyone to just "trust us." We will always provide what is required for you to solve your problem, and meet your system requirements.
We are the ONLY company, in the world, to publish our FIT rates, soft,a nd hard, every quarter. And, we state the standards we used to get those numbers. Time after time, the numbers get (re-) verified by those who are not able to even "trust" that the published informatiojn is accurate and true. So, littel things like the ECC counter are of great importance to us, as we recognize our devices get designed into all kinds of safety critical systems, and I for one, do ride in high speed trains, and in airplanes (just two of the many places we get designed into).
I want to know (personally) where we are, and what we are doing. I enjoy talking to the ICE train engineer in Germany, the airplane engineer in Washington state, the 1 MW windmill systems engineer, etc. I like to know that all these systems are using proven hardware and IP to solve their problems, and keep me safe.
Thanks Austin - that's a pretty gun-ho attitude.
Love to see you guys deliver on that high bar.
At this stage we are thinking about building with ECC enabled and if we can
verify it later - then we can push that feature otherwise as long it is not actually
causing problems it's probably a hidden benefit. So please let me know
if we can verify this.
I will provides updates as they become available.
I am surprised that you haven't requested the soft error testing results.
Did you miss that offer?
I can't imagine that you are interested in the ECC_counter, and you do not care to know the soft error behavior of the device!
Ta. I think I missed that offer- yes you are right I am interested in soft error testing results and I will ask about them in the Web case. - BTW what are they?
Twice as good as the initial estimate,
Sorry, but I had to say that. We had estimates from Arm, and we came in at almost exactly half of their estimates.
That said, it depends on many factors, but using both cpus, both fpus, all peripherals, all caches, OCM memory we come in under a few hundred FIT (entire processor system). If you have a specific target to meet, by consulting your FAE, we can show you how to get it under your goal. All errors result in exceptions or interrupts. The silent data corruption (no exception, no interrupt) is less than about 15 FIT in our testing. All the details can be discussed with your FAE.
If you have any difficulties getting the info, let me know.
Does that mean that I need an interrupt to check the ECC status and counters? I was getting the same data abort exception (no parity) for the BRAM but only when I injected two or more errors. For a single, thus correctable, bit everything worked fine (including counters).