Reliability CPLD/FPGA vs Microcontroller

"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag 
news:4448ed30$0$18265$9b4e6d93@newsread2.arcor-online.net...
> Falk Salewski schrieb:
>> I am doing some research on the reliability of microcontrollers software 
>> in
>> comparison to hardware description languages for PLDs (CPLD/FPGA).
>>
>> Another interesting point is whether there are general benefits of one
>> hardware regarding reliability, e.g. in an automotive environment.
>
> This all depends on the type of errors you are talking about. To get an
> overall estimate will be really difficult.
>
> E.g. in automotives a big issue are real time constraint violations when
> many things happen at once. You can easily specify the timing of most
> hardware implemented algorithms with a granularity of nanoseconds
> because there is real concurrency in the implementation. For uC it is
> hard to get below tens of microseconds.
>
> Also, error detection and correction on ALUs, busses and memory is just
> not available for commercial uC, while you can easily implement it for
> your FPGA circuit. In theory a uC using all these techniques would be
> more reliable, but if you can not buy it....
> (BTW: I talked to Bosch about that topic, and apparently the volume of
> their orders is not big enough to have Motorola design such a uC for 
> them.)
>
> Formal model checking and property checking are becoming mainstream for
> hardware development but are hardly ever used for software development.
>
> These are all factors in favor of FPGAs that are often not considered,
> but I am sure that you come up with many reasons why uCs are more
> reliable. (Less transistors for example)
>
> Kolja Sulimma
>

Thanks for your reply! I am also of the opinion that applications realizing 
hard real-time parallel functionality are easier to verify on a device 
allowing real parallelism.
Possible integration of error detection and correction functionalities in 
FPGAs are also a big plus, in my opinion.
Finally it seems that the aspect MCU vs. FPGA regarding reliability is, 
again, application dependent.

Falk Salewski 

Falk Salewski wrote:

> I am doing some research on the reliability of microcontrollers software in 
> comparison to hardware description languages for PLDs (CPLD/FPGA).
> 
> Another interesting point is whether there are general benefits of one 
> hardware regarding reliability, e.g. in an automotive environment.
> 
> 
> 
> I read about certification problems if a SRAM based FPGA is programmed every 
> system start and that Flash or Fuse based systems are preferable. I also 
> read that CPLDs (Flash) in general are more robust than FPGAs.
> 
> Can you confirm/confute this?

What are the allowed failure modes ? All of them ?
That includes alpha particles, fast protons, thermal
cycles, vibrations, supply and signal issues, electric
and magnetic fields, the lot.
Plus how failure prof is the design. How can it handle
unexpected values. While in some points 90nm technology
is more sensitive, it is not that an acre of 2N3055
doing the same would be more reliable.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Kolja Sulimma wrote in
news:4448ed30$0$18265$9b4e6d93@newsread2.arcor-online.net :

"[..]

Formal model checking and property checking are becoming mainstream for
hardware development but are hardly ever used for software development.

[..]"

There is a difference between being mainstream and being available. Formal 
methods have existed for a long time for software. Just as one should not 
be willing to take a software developer opposed to formal methods, one 
should not be willing to take a hardware developer who has only acquired 
exposure to formal methods because of a trend instead of actively 
appreciating the need for formal methods.

On Thu, 27 Apr 2006, Falk Salewski wrote:

"[..] I am also of the opinion that applications realizing 
hard real-time parallel functionality are easier to verify on a device 
allowing real parallelism.
[..]"

Of course implementing parallelism with real parallelism is easier, but 
verifying something whether it is implemented with true parallelism or 
interleaved sequential code should take the same effort no matter the 
implementation: check whether the inputs and the outputs match.

"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> schrieb im Newsbeitrag 
news:20060503210430.A70973@docenti.ing.unipi.it...

> Of course implementing parallelism with real parallelism is easier, but
> verifying something whether it is implemented with true parallelism or
> interleaved sequential code should take the same effort no matter the
> implementation: check whether the inputs and the outputs match.

I still believe that verifying parallel structures on a PLD is easier than 
on a CPU. Imagine a program, that has to handle certain communication 
interfaces (CAN, RS232,..) and has to measure some real-time signals at the 
same time. In case of a PLD these modules could be checked separately, since 
no dependencies according to a single CPU are present. In case of a CPU 
based system this dependencies are crucial (in real-time systems) and a lot 
of test efford is spend to examine these.