CPLDs and Safety? Re: ASICs Vs. FPGA in Safety Critical Apps.

I am interested in safety for embedded applications. So I read this articels dealing with "ASICs Vs. FPGA in Safety Critical Apps." posted around 1996 with great interest.

People listed a lot of advantages of FPGAs, however the major problem (related to safety) left was that the FPGA has to be reprogrammed at each power up.

My question: isn't an CPLD a good solution for small safety critical applications?

Falk

---------------------------------------------------------- Chair of Computer Science XI RWTH Aachen University Germany

Reply to
Falk Salewski
Loading thread data ...

Could you post a link to the original article?

There are lots more concerns other than the reprogramming. One such thing is the effect of Single Event Upsets. For example, configuration bits of the FPGA/CPLD can be flipped by SEUs (even at sea-level this is more important than MTBF) making the logic you designed behave incorrectly.

Of course mitigation techniques exist, such as Triple Mode Redundancy, (and Device read-back and reconfiguration for some devices)

Having said that CPLDs are much smaller devices, often at higher internal voltages, hence don't have the same problems with MTTE. If your system is small enough, and can be made fully redundant to cover MTBF failures, CPLD would be my advice.

You want to check out the IEC-61508 Standard, and the Xilinx Military applications page. (or

formatting link
HTH Ben

articels

Reply to
Benjamin Todd

Thanks for the reply!

I got the original article from

formatting link

You can find there the problem you mentioned, too. I was just wondering if a CPLD would meet safety requirements better than a FPGA.

Falk

"Benjamin Todd" schrieb im Newsbeitrag news:clt313$3or$ snipped-for-privacy@sunnews.cern.ch...

Reply to
Falk Salewski

Let's keep things in pespective. Yes, "SRAM-based" FPGAs can be upset by random SEUs. But how likely is this? We at Xilinx have done extensive real-time tests with thousands of large devices (XC2V6000) over more than a year, and here is a snapshot of the result: A device of Virtex-II 1000 complexity ( "1 million FPGA gates") is likely to pick up a functional error due to SEU roughly once per thousand years of operation. The much smaller XC2V40 is about twice the complexity of the largest CPLD, and it would encounter a functional error once per 25000 years. That's a pretty good MTBF. Better than the FIT rate of many other, even passive, coponents. Peter Alfke, Xilinx Applications =====================

Reply to
Peter Alfke

Apparently, some CPLD's get reprogrammed after each power cycle. There is at least one where the programmed bits are stored in non-volatile flash, but program RAM LUT's(?) upon powerup that is transparent to the user. I would suspect that the CPLD RAM values are susceptable just like RAM based FPGA's, but that is only a guess on my part.

Reply to
newman

Is this reliability data availible? Can I find it in your Xilinx Device Reliability Report? And still there is the question, if CPLDs might have a higher reliability than FPGAs.

Falk

"Peter Alfke" schrieb im Newsbeitrag news:BDA7AF5C.99DE% snipped-for-privacy@xilinx.com...

Reply to
Falk Salewski

What principle advantage do you think to gain with an CPLD over an FPGA? If you think about a flash based CPLD, why not using a flash based FPGA?

A lot of Hi-Rel applications use fuse-based fpgas which are (almost) immune against functional changes after programming and are ready to start after power-up. So you end nearly in a safety level you reach with asics.

bye Thomas

Reply to
Thomas Stanka

Didn't know about flash based FPGAs before. Maybe it's something to think about. Thanks for your reply!

Falk

"Thomas Stanka" schrieb im Newsbeitrag news: snipped-for-privacy@post>> I am interested in safety for embedded applications. So I read this

Reply to
Falk Salewski

The ones I have seen are actually SRAM FPGAs with an automatic loader from on-chip flash. This loads much faster than an external flash would, but otherwise the process is the same.

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com Ignore the reply address. To email me use the above address with the XY removed.

Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL

formatting link

4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply to
rickman

As far as I know, are Actel ProAsic Plus not SRAM-Cells with on-chip flash. Of course there are SRAM-Cells for embedded RAM, but the logic itself seems to be stored in flash technology.

The only fpga I unterstood using SRAM-logic with on-chip flash are lattice Fpgas. But feel free to correct me, I like to learn something new :=).

bye Thomas

Reply to
Thomas Stanka

As far as I know, are Actel ProAsic Plus not SRAM-Cells with on-chip flash. Of course there are SRAM-Cells for embedded RAM, but the logic itself seems to be stored in flash technology.

The only fpga I unterstood using SRAM-logic with on-chip flash are lattice Fpgas. But feel free to correct me, I like to learn something new :=).

bye Thomas

Reply to
Thomas Stanka

Thomas,

Soon there will appear (I just reviewed it) a Tech Xclusive on failure rates, both soft and hard. Bottom line, is that 4/5ths of the failures (or more) of any typical system are hardware failures (solder, connectors, capacitor shorts, etc.) as opposed to soft errors induced by cosmic rays (example here was a complete cellular base station with ten

2VP100's! radios and all).

Additionally, there are three known ways to eliminate soft errors as a cause of functional failures, so you had better worry about the 'real' problem, and not chase red herrings (where in the world does that colloquialism come from?).

Just keep checking:

formatting link

the article should be posted in a week or so.

Aust> "Falk Salewski" wrote:

Reply to
Austin Lesea

Would you think it is possible to have a design in an Xilinx fpga with FIT rates below 20 usable in Orbit? I can't sell my customers a single component with FIT rates of several hundreds. Even if I could prove, that other failures are dominant over fpga failures.

My answer based on the question if an Cpld would be better than an Fpga in safty critical applications which is not the overall case in my opinion, because I see no technical advantage of an Cpld, which might be seen by people thinking Fpgas are always SRAM-based. I would like to have you proving that even SRAM-based Fpgas are good enough.

bye Thomas

Reply to
Thomas Stanka

Thomas,

The soft FIT rate can be brought down to below 20.

Present FPGAs being designed into spacecraft, or already in use (like the Mars Rovers) utilize one of the techniques I alluded to.

On Mars, they reconfigure the devices on a scheduled basis to remove any possibility of a soft errors accumulating and upsetting the rovers.

If a fault is discovered between reconfigurations, they reconfigure again.

For more demanding environments, there is the XTMR tool that we released, which can be used to convert a design to a completely triple modular redundant design. Now no single hard, or soft fault, affects operation (virtually bulletproof).

The XTMR tool supports selecting only those areas of the design which are critical to be TMR'd (for example, a critical state machine).

Combine the full TMR with scrubbing (which is where you continually reconfigure even while operating), and it becomes bulletproof (highest level of reliability). This is what is considered for low earth orbit applications.

So, if the soft error rate is 30 FIT/Mb for the configuration bits (a real number for Virtex II -- includes the SEUPI factor), depending on the size of device, and the techniques chosen, and the goal FIT rate, it becomes a matter of engineering the system to get it down to the desired goal.

Contact one of our Mil/Aero FAEs through your local Xilinx representative's office for all of the details. Also please be aware that Xilinx has strong disclaimers regarding any application involving human life. These applications must be reviewed and approved by Xilinx.

A good example is someone who wants to use our FPGA in a nuclear power plant better talk to us first. We would not want them to do a simplistic design and not take all possible failure mechanisms into account -- and neither would you!

How would like a typical PC to be controlling a nuclear power plant, or the descent of an airplane? Not me! It isn't Intel's or Microsoft's fault if you use a device for an application that it was not intended for (and you have an accident).

Aust> Hi,

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.