Spirit on Mars

[Austin Lesea]

Lest anyone spread rumors,

Spirit used a 4K QPRO part for the squibs that fired for the parachute,
the inflatable bag, etc for the Lander.

The rover has Virtex 1000's in the wheels for position/motor control.

The fact that the Spirit has stopped sending useful data back to NASA is
a terrible thing, but we got them there, and rolled them onto the
surface. Other folks parts are supposed to do the communicating with
Earth. Who volunteers to let us know whose components are used for
that? What processor did they use?

Hope those folks figure it out, as it is a tradegy for everyone to lose
the ability to gain knowledge of our solar system.

By the way, the self checks on the FPGAs after that solar flare that
destroyed that Japanese satellite's electronics showed that the FPGAs
were undamaged, and had suffered not at all from the flare (as we can
take many rads of radiation, and not be affected at all).

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

Austin

 

[Pablo Bleyer]

"Austin Lesea" <austin@xilinx.com> escribió en el mensaje
news:bup6dl$8dl2@cliff.xsj.xilinx.com...

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

Interesting. Under what conditions and what kind of tests are Xilinx
rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed
information about rad parameters...

Regards.

 

[Jake Janovetz]

You're saying that FPGAs enjoy higher volumes than SRAMs? Interesting...


Austin Lesea <austin@xilinx.com> wrote in message news:<bup6dl$8dl2@cliff.xsj.xilinx.com>...

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

Austin

 

[Uwe Bonnes]

Austin Lesea <austin@xilinx.com> wrote:
: Lest anyone spread rumors,

: Spirit used a 4K QPRO part for the squibs that fired for the parachute,
: the inflatable bag, etc for the Lander.

The Moessbauer Spectrometer has a Quicklogic QL30XX...

If I remember right, the APX has an Altera ...

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Austin Lesea]

Jake,

No, you are correct about SRAMs, I am wrong there. My only point is
that SRAMs can not all be tested at LANSCE in the beam, and when they do
get around to it, there have been some spectacular single event latch up
problems (ie instant destruction of the device).

Austin

Jake Janovetz wrote:

You're saying that FPGAs enjoy higher volumes than SRAMs? Interesting...


Austin Lesea <austin@xilinx.com> wrote in message news:<bup6dl$8dl2@cliff.xsj.xilinx.com>...

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

Austin

 

[Austin Lesea]

Uwe,

Thank you. Very interesting. This is the kind of info that is useful
to know.

Austin

Uwe Bonnes wrote:

Austin Lesea <austin@xilinx.com> wrote:
: Lest anyone spread rumors,

: Spirit used a 4K QPRO part for the squibs that fired for the parachute,
: the inflatable bag, etc for the Lander.

The Moessbauer Spectrometer has a Quicklogic QL30XX...

If I remember right, the APX has an Altera ...

Bye

 

[Austin Lesea]

Pablo,

Thanks for the opportunity to let us brag a bit:

Test

We test all technologies as part of the qualification in the proton beam
at UC Davis, and then at LANSCE in the neutron beam (the industry only
gets a few days a year to do tests at LANSCE which is the only facility
in the world with a HESS spectrum neutron beam).

Hot, Hot, Hot!

Can not take them home after the tests till they "cool off" as they are
radioactive after spending so much time in the beam. Oh, and none of
them ever suffer any damage -- they power on and meet all specs after
hundred and hundreds of rads.

Real Tests

We also do atmospheric testing. We call this the "Rosetta" experiments,
as they are intended to help us decipher the meaning of the LANSCE tests
which are, after all, just an arbitrary test that has only a correlation
to real performance.

Sea Level, 5100 Feet, 12,500 Feet, 13,200 Feet

We have 100 2VP50's here in San Jose, 100 2V6000's here in San Jose, 100
2V6000's in Albuquerque NM, 100 2V6000's on White Mountain, California
(outside of Bishop, Ca), 100 3s1500's due to go online soon here in San
Jose, and 100 2VP30's also here in San Jose. Another 110 2V6000's go to
Mauna Kea Hawaii next week to the Caltech Submillimeter Observatory.

All of them our monitored every 2 hours for any single cosmic ray
induced upset.

Analysis

This is a standard procedure, and we are the ONLY company that actually
KNOWS how our parts are affected by cosmic neutron showers, alpha
particles, etc in REAL applications from sea level to 60,000 feet (I
can't talk about the programs we have for mil/aerospace until you sign
an NDA).

Competitors

Other companies out there are in a state of "blissful ignorance" and
when (not if) they start to have customers complain of failures, they
will be saying, "gee, we don't see anything (because we can't), must be
something you are doing." Why can't they see anything when a customer
complains?

Xilinx Advanced Technology

Our advanced readback and internal access configuration port allows us
to actually check all memory cell states to see if anything anywhere has
flipped. We can then locate the exact cell that flipped (ie LUT, BRAM,
config latch, etc. and from than know what the susceptibility of each
one really is). We can identify if that bit is used in the customer's
design, and what it does. Because we have had to do this for the
military/aerospace community for years, we are able to do this for
everyone else who may suspect that they have soft errors.

Reality

Customers are unlikely to see the problem as anything but a background
annoying return rate of "no problems found" as powering down and up, or
reconfiguring makes the "problem" go away!

At least we have been working on this for 5+ years, have patents
pending, making improvements, and understanding exactly how things
happen (upsets do happen....most people are totally unaware of this fact).

How We Assure Reliability

In addition to design techniques in silicon, we also have application
design techniques to reduce the probability of soft error causing
failure to 0 (ie Spirit and Opportunity, not to mention the hundreds of
military and aerospace applications we "fly" in).

We are presenting papers at conferences (MAPLD 2003, for example)
detailing our results for .5u, .35u, .22u. .18u, .15u, .13u and 90
nanometer. If interested, email me directly, and I will send you the
MAPLD ppt presentation.

Call or Write for More Information

Or better yet, contact your Xilinx FAE for a full technical presentation!

Austin

PS: many have asked me if the information I present here is unique
(proprietary) in any way. It is not. All information posted is
published already (ie in the public domain). It is just that I do see
all Xilinx press releases, and see all marketing communications, so I am
aware of what we can (and are able to) post.


Pablo Bleyer wrote:

"Austin Lesea" <austin@xilinx.com> escribió en el mensaje
news:bup6dl$8dl2@cliff.xsj.xilinx.com...

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.


Interesting. Under what conditions and what kind of tests are Xilinx
rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed
information about rad parameters...

Regards.

 

[Nicholas C. Weaver]

In article <bup6dl$8dl2@cliff.xsj.xilinx.com>,
Austin Lesea <austin@xilinx.com> wrote:

The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

I seriously doubt the paranoid EEs at JPL would allow any device which
couldn't stand the radiation load, and wasn't batch-tested for the
radiation load, onto the rover.

My personal bet would be software fault or a nontransient hardware
fault in non-memory.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Jan Panteltje]

On a sunny day (Thu, 22 Jan 2004 10:56:52 -0800) it happened Austin Lesea
<austin@xilinx.com> wrote in <bup6dl$8dl2@cliff.xsj.xilinx.com>:

Hope those folks figure it out, as it is a tradegy for everyone to lose
the ability to gain knowledge of our solar system.
It is obvious whodidit:

http://www.home.zonnet.nl/panteltje/mars/easthills-bunny.jpg

 

[jim granville]

Austin Lesea wrote:

Pablo,

Thanks for the opportunity to let us brag a bit:
snip interesting info
Xilinx Advanced Technology

Our advanced readback and internal access configuration port allows us
to actually check all memory cell states to see if anything anywhere has
flipped. We can then locate the exact cell that flipped (ie LUT, BRAM,
config latch, etc. and from than know what the susceptibility of each
one really is). We can identify if that bit is used in the customer's
design, and what it does. Because we have had to do this for the
military/aerospace community for years, we are able to do this for
everyone else who may suspect that they have soft errors.

How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg

 

[Austin Lesea]

Jim,

It is true in the past that readback while operating caused some issues
(pre-Virtex). And even today, LUTRAM is disturbed by readback if it is
being used at the same time (address is changing).

With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
LUTRAM/SRL16 while it is operating and not disturb the static values,
nor disturb the customer design. In the next generation we have also
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
you, as you do not know what it is supposed to be (as it just might be
changing).

But you can readback the rest of the config memory. That covers 90% of
the static cells (excluding BRAM which has a parity bit that can be used
to see when the BRAM has been upset). BRAM is also more than 8 times
less likely to be upset than a static config latch (from actual data in
Rosetta).

In fact, you can in your design check that all static config bits are
unchanged by simply reading all of them back and comparing a checksum
with one calculated when first powered on.

Or, you can imagine making an error check AND correcting "crawler" that
goes around and fixes any soft errors that might have occurred before
they affect the customer design.....

Spirit and Opportunity use an even simpler method, which is they
continually re-program all static memory cells (skipping LUTRAM/SRL16,
BRAM if necessary) while operating. Of course they also used full
triple modular redundancy with voting, too. That level of reliability
is only required for applications where it can absolutely NOT ever fail!

If you can integrate these self-test and monitoring features with the
rest of the system, you can even check BRAM and LUTRAM by stopping the
processing at strategic moments.

Austin

jim granville wrote:

Austin Lesea wrote:

Pablo,

Thanks for the opportunity to let us brag a bit:

snip interesting info

Xilinx Advanced Technology

Our advanced readback and internal access configuration port allows us
to actually check all memory cell states to see if anything anywhere
has flipped. We can then locate the exact cell that flipped (ie LUT,
BRAM, config latch, etc. and from than know what the susceptibility of
each one really is). We can identify if that bit is used in the
customer's design, and what it does. Because we have had to do this
for the military/aerospace community for years, we are able to do this
for everyone else who may suspect that they have soft errors.


How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg

 

[Ray Andraka]

For the configuration bits, most of it can be read while the device is being
clocked. The exception is the block ram contents, and in Virtex, columns
containing SRL16's or CLB RAM. Not sure if they fixed the problem reading
back the SRL16/CLB Ram columns in VirtexII. The discovery was close to
virtexII tape-out IIRC.

jim granville wrote:

Austin Lesea wrote:
? Pablo,
?
? Thanks for the opportunity to let us brag a bit:
?snip interesting info?
? Xilinx Advanced Technology
?
? Our advanced readback and internal access configuration port allows us
? to actually check all memory cell states to see if anything anywhere has
? flipped. We can then locate the exact cell that flipped (ie LUT, BRAM,
? config latch, etc. and from than know what the susceptibility of each
? one really is). We can identify if that bit is used in the customer's
? design, and what it does. Because we have had to do this for the
? military/aerospace community for years, we are able to do this for
? everyone else who may suspect that they have soft errors.

How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[Peter Alfke]

Let me answer this in more general terms:
Anything that is stable can be reliably included in the readback, i.e.
configuration bits, LUTs, flip-flops that happen not to change., etc.

For stuff that toggles, it is even conceptually difficult to envision
what to do, and how to interpret the result.Especially with multiple
clock domains.
So, even if we do a prefect job in designing the part, the user would
still be faced with a complex job to specify the capture moment, and
then to interpret the result.

But the simple answer is:
you can read all static data, without interfering with the operation of
the FPGA...
Peter Alfke
========================
Austin Lesea wrote:

Jim,

It is true in the past that readback while operating caused some issues
(pre-Virtex). And even today, LUTRAM is disturbed by readback if it is
being used at the same time (address is changing).

With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
LUTRAM/SRL16 while it is operating and not disturb the static values,
nor disturb the customer design. In the next generation we have also
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
you, as you do not know what it is supposed to be (as it just might be
changing).

But you can readback the rest of the config memory. That covers 90% of
the static cells (excluding BRAM which has a parity bit that can be used
to see when the BRAM has been upset). BRAM is also more than 8 times
less likely to be upset than a static config latch (from actual data in
Rosetta).

In fact, you can in your design check that all static config bits are
unchanged by simply reading all of them back and comparing a checksum
with one calculated when first powered on.

Or, you can imagine making an error check AND correcting "crawler" that
goes around and fixes any soft errors that might have occurred before
they affect the customer design.....

Spirit and Opportunity use an even simpler method, which is they
continually re-program all static memory cells (skipping LUTRAM/SRL16,
BRAM if necessary) while operating. Of course they also used full
triple modular redundancy with voting, too. That level of reliability
is only required for applications where it can absolutely NOT ever fail!

If you can integrate these self-test and monitoring features with the
rest of the system, you can even check BRAM and LUTRAM by stopping the
processing at strategic moments.

Austin

jim granville wrote:
Austin Lesea wrote:

Pablo,

Thanks for the opportunity to let us brag a bit:

snip interesting info

Xilinx Advanced Technology

Our advanced readback and internal access configuration port allows us
to actually check all memory cell states to see if anything anywhere
has flipped. We can then locate the exact cell that flipped (ie LUT,
BRAM, config latch, etc. and from than know what the susceptibility of
each one really is). We can identify if that bit is used in the
customer's design, and what it does. Because we have had to do this
for the military/aerospace community for years, we are able to do this
for everyone else who may suspect that they have soft errors.


How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg

 

[Ray Andraka]

Peter,

My understanding is that there is a readback bug for SRL16/CLBRAM
that causes corruption of the user circuit if the column is read while
those elements are being clocked in Virtex, VirtexE, and possibly
VirtexII. As I recall, it was found right about the time VirtexII was
going into tape-out, and it didn't sound like it would be fixed for
VirtexII. We had to avoid readback during operation of columns
with SRL16s in it on one of my customer's projects that was destined
for space. The work-around included clustering the SRL16s to specific
columns and using a different approach to discover configuration faults
in those columns. My paper "A Low Complexity Method for Detecting
Configuration Upset in SRAM Based FPGAs" goes into a little bit more
detail (the paper is available on my website for download at no charge)
as to the problem and the technique I used to be able to still use the
SRL16's without compromising upset detection. As I recall, there was
also an issue reading BRAM columns while they were being clocked
because the readback circuits shared some of the user circuit in Virtex.
IIRC, that one was corrected in VirtexII.

The caveat to your statement is then, configuration bits can be read back
while the circuit is operating except for SRL16's CLB_RAM and in
virtex, block RAM as reading columns with those elements while they are
being clocked can corrupt the state of the user circuit.


Peter Alfke wrote:

Let me answer this in more general terms:
Anything that is stable can be reliably included in the readback, i.e.
configuration bits, LUTs, flip-flops that happen not to change., etc.

For stuff that toggles, it is even conceptually difficult to envision
what to do, and how to interpret the result.Especially with multiple
clock domains.
So, even if we do a prefect job in designing the part, the user would
still be faced with a complex job to specify the capture moment, and
then to interpret the result.

But the simple answer is:
you can read all static data, without interfering with the operation of
the FPGA...
Peter Alfke
========================
Austin Lesea wrote:

Jim,

It is true in the past that readback while operating caused some issues
(pre-Virtex). And even today, LUTRAM is disturbed by readback if it is
being used at the same time (address is changing).

With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
LUTRAM/SRL16 while it is operating and not disturb the static values,
nor disturb the customer design. In the next generation we have also
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
you, as you do not know what it is supposed to be (as it just might be
changing).

But you can readback the rest of the config memory. That covers 90% of
the static cells (excluding BRAM which has a parity bit that can be used
to see when the BRAM has been upset). BRAM is also more than 8 times
less likely to be upset than a static config latch (from actual data in
Rosetta).

In fact, you can in your design check that all static config bits are
unchanged by simply reading all of them back and comparing a checksum
with one calculated when first powered on.

Or, you can imagine making an error check AND correcting "crawler" that
goes around and fixes any soft errors that might have occurred before
they affect the customer design.....

Spirit and Opportunity use an even simpler method, which is they
continually re-program all static memory cells (skipping LUTRAM/SRL16,
BRAM if necessary) while operating. Of course they also used full
triple modular redundancy with voting, too. That level of reliability
is only required for applications where it can absolutely NOT ever fail!

If you can integrate these self-test and monitoring features with the
rest of the system, you can even check BRAM and LUTRAM by stopping the
processing at strategic moments.

Austin

jim granville wrote:
Austin Lesea wrote:

Pablo,

Thanks for the opportunity to let us brag a bit:

snip interesting info

Xilinx Advanced Technology

Our advanced readback and internal access configuration port allows us
to actually check all memory cell states to see if anything anywhere
has flipped. We can then locate the exact cell that flipped (ie LUT,
BRAM, config latch, etc. and from than know what the susceptibility of
each one really is). We can identify if that bit is used in the
customer's design, and what it does. Because we have had to do this
for the military/aerospace community for years, we are able to do this
for everyone else who may suspect that they have soft errors.


How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[jim granville]

Ray Andraka wrote:

Peter,

My understanding is that there is a readback bug for SRL16/CLBRAM
that causes corruption of the user circuit if the column is read while
those elements are being clocked in Virtex, VirtexE, and possibly
VirtexII. As I recall, it was found right about the time VirtexII was
going into tape-out, and it didn't sound like it would be fixed for
VirtexII. We had to avoid readback during operation of columns
with SRL16s in it on one of my customer's projects that was destined
for space. The work-around included clustering the SRL16s to specific
columns and using a different approach to discover configuration faults
in those columns. My paper "A Low Complexity Method for Detecting
Configuration Upset in SRAM Based FPGAs" goes into a little bit more
detail (the paper is available on my website for download at no charge)
as to the problem and the technique I used to be able to still use the
SRL16's without compromising upset detection. As I recall, there was
also an issue reading BRAM columns while they were being clocked
because the readback circuits shared some of the user circuit in Virtex.
IIRC, that one was corrected in VirtexII.

The caveat to your statement is then, configuration bits can be read back
while the circuit is operating except for SRL16's CLB_RAM and in
virtex, block RAM as reading columns with those elements while they are
being clocked can corrupt the state of the user circuit.

Sounds like that one, if true, needs a fix....
( and an alert -> someone might think they are increasing reliability
by reading back all nodes, and ignoring the 'might change' ones ) -

Austin Lesea wrote:

Jim,

snip
With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
LUTRAM/SRL16 while it is operating and not disturb the static values,
nor disturb the customer design. In the next generation we have also
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

So this fixed, 'next generation' is not Spartan 3, but whatever is
comming after that ?

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
you, as you do not know what it is supposed to be (as it just might be
changing).

If that BRAM was storing constants/lookup info (read only), then
I can see a need to verify the table is actually still correct ?

-jg

 

[rk]

Austin Lesea wrote:

[ snip ]

We are presenting papers at conferences (MAPLD 2003, for example)
detailing our results for .5u, .35u, .22u. .18u, .15u, .13u and 90
nanometer. If interested, email me directly, and I will send you the
MAPLD ppt presentation.

Here's the presentation, on-line (no paper available that I know of):

"NSEU Sensitivity of SRAM-based FPGAs"
Joe Fabula, Austin Lesea, Carl Carmichael, and Saar Drimer
Xilinx Corp.

http://klabs.org/richcontent/MAPLDCon03/presentations/c/c5_fabula_s.ppt

--
rk, Just an OldEngineer
"For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled."
-- R. Feynman, Appendix F.

 

[ram]

Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote in message news:<1074893678.673451@news-01.evisp.enertel.nl>...

On a sunny day (Thu, 22 Jan 2004 10:56:52 -0800) it happened Austin Lesea
austin@xilinx.com> wrote in <bup6dl$8dl2@cliff.xsj.xilinx.com>:

Hope those folks figure it out, as it is a tradegy for everyone to lose
the ability to gain knowledge of our solar system.
It is obvious whodidit:
http://www.home.zonnet.nl/panteltje/mars/easthills-bunny.jpg

Thats an interesting graphic to coool out the topic
Ram

 

[Jason]

"Pablo Bleyer" <pbleyerN@SPAMembedded.cl> wrote in message news:<4010abf0$1_1@nova.entelchile.net>...

"Austin Lesea" <austin@xilinx.com> escribió en el mensaje
news:bup6dl$8dl2@cliff.xsj.xilinx.com...
The reason for the failure of other parts could be that they are NOT
FPGAs. FPGAs are manufactured in huge volumes, and are all tested in
the qualification for latch up under irradiation. Many SRAM,s and other
products do not have the volume to afford such testing, and in fact
recent shrinks of common parts are known to latch up with a single
event, and destroy themselves.

Interesting. Under what conditions and what kind of tests are Xilinx
rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed
information about rad parameters...

Regards.

Pablo - they undergo the standard tests....TID per spec 1019.5, SEL
and SEU (Heavy Ion and Proton - Static and Dynamic). All of the
specifications (from krads to Cross Sections to energies, etc) are
listed in the datasheet. For more detailed info test results are
published via the Xilinx Single Event Effects Consoritum, which
includes major Aerospace companies, at the typical industry
conferences - NSREC, RADECS and MAPLD mainly.

Thanks
Jason
Xilinx Mil/Aero Group

 

[Thomas Stanka]

Hi,

Austin Lesea <austin@xilinx.com> wrote:

radioactive after spending so much time in the beam. Oh, and none of
them ever suffer any damage -- they power on and meet all specs after
hundred and hundreds of rads.

What about 100 krad? I'm just curios. In our company we have problems
to use devices without qualification for at least 30krad.

Analysis

This is a standard procedure, and we are the ONLY company that actually
KNOWS how our parts are affected by cosmic neutron showers, alpha
particles, etc in REAL applications from sea level to 60,000 feet (I
can't talk about the programs we have for mil/aerospace until you sign
an NDA).

This seems a bit too overconfident.
Actually I didn't know your effort, but I know the effort Actel is
doing for its devices. And they prove very sufficient analyses beside
the analyses spacecompanies are doing with Actel Fpgas for themself.

Competitors

Other companies out there are in a state of "blissful ignorance" and
when (not if) they start to have customers complain of failures, they
will be saying, "gee, we don't see anything (because we can't), must be
something you are doing." Why can't they see anything when a customer
complains?

I'm shure you wouldn't tell names, but did you _ever_ tried the
hotline of another fpga vendor? Tell us a bit about your experience.
I'm very satisfied the way Actel is reacting on complaints.



bye Thomas

 

[Austin Lesea]

Jim,

See below,

Austin

The caveat to your statement is then, configuration bits can be read back
while the circuit is operating except for SRL16's CLB_RAM and in
virtex, block RAM as reading columns with those elements while they are
being clocked can corrupt the state of the user circuit.


Sounds like that one, if true, needs a fix....
( and an alert -> someone might think they are increasing reliability
by reading back all nodes, and ignoring the 'might change' ones ) -

Austin Lesea wrote:

Jim,

snip
With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
LUTRAM/SRL16 while it is operating and not disturb the static values,
nor disturb the customer design. In the next generation we have also
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

So this fixed, 'next generation' is not Spartan 3, but whatever is
comming after that ?

Yes.

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
you, as you do not know what it is supposed to be (as it just might be
changing).


If that BRAM was storing constants/lookup info (read only), then
I can see a need to verify the table is actually still correct ?

If BRAM or LUTRAM is storing constants, then you may include it in the
readback verify.

-jg