Thank you Jim, that was a very useful comment. Didier ------------------------ Sent from my BlackBerry Wireless thingy while I do other things...
-----Original Message----- From: "Lux, Jim (337C)" <[email protected]> Date: Fri, 5 Feb 2010 07:17:08 To: Discussion of precise time and frequency measurement<[email protected]> Subject: Re: [time-nuts] Small CPLD/FPGA for microcontroller replacement On 2/5/10 6:14 AM, "paul swed" <[email protected]> wrote: On Fri, Feb 5, 2010 at 9:04 AM, Didier Juges <[email protected]> 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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
