[time-nuts] Small CPLD/FPGA for microcontroller replacement

Didier Juges didier at cox.net
Fri Feb 5 22:20:14 UTC 2010

Thank you Jim, that was a very useful comment.

------------------------ Sent from my BlackBerry Wireless thingy while I do other things... 

-----Original Message-----
From: "Lux, Jim (337C)" <james.p.lux at jpl.nasa.gov>
Date: Fri, 5 Feb 2010 07:17:08 
To: Discussion of precise time and frequency measurement<time-nuts at febo.com>
Subject: Re: [time-nuts] Small CPLD/FPGA for microcontroller replacement

On 2/5/10 6:14 AM, "paul swed" <paulswedb at gmail.com> wrote:

On Fri, Feb 5, 2010 at 9:04 AM, Didier Juges <didier at cox.net> wrote:

> Part of the requirement is that the devices be immune (as much as
> practical)
> from SEU malfunction. I was told Atmel (or Actel?) makes flash-based small
> FPGAs that may fit the bill. Most SRAM devices are deemed to be excessively
> sensitive to SEU, even though I cannot imagine how a CPLD/FPGA could be
> made
> that does not use SRAM at all. Maybe it's a matter of quantity? A few
> working registers may be an acceptable risk, but the entire device
> operating
> from SRAM is not acceptable?

It is somewhat relevant to time-nuttery, with respect to the recent discussion about CPLDs.  The Actel parts we use for spaceflight are anti-fuse type, so the logic configuration is radiation hard.  However, the actual gates and latches you instantiate are susceptible to SEU, so if you need an "upset proof" implementation, you have to go to TMR type schemes (many of which are automatically implemented by the design tools.. That is, they have TMR registers, etc. as part of the libraries)

I think there are onchip charge pumps and such for generating internal  bias voltages, and I don't know what the noise implications of them might be.

But the SRAM devices aren't all that susceptible to upset on a "per gate" basis.  The problem is that if you have a 3-6 million gate part,  the probability of an upset "somewhere" is fairly high (in a world where we worry about 1E-12 rates).  Again, you can use TMR type techniques.  You can google "Xilinx Upset probability" or "Xilinx radiation effects"  and get some typical numbers. There are a variety of schemes for scrubbing the configuration memory (basically always rewriting the configuration, so that a configuration upset doesn't last for very long)

One needs to be careful in looking at upset rates in SRAM based parts, too... You need to distinguish between an upset in the data and an upset in the configuration memory, and they have different rates.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

More information about the time-nuts mailing list