BIST FPGA testing - Applying a test vector

Thomas Stanka wrote:
>
> Well, I believe you're achieving 100% of stuck-at failures, but do you
> really do some tests to achieve a 100% coverage for delay faults? I'm
> just curios because I know no way doing propper delay tests without a
> lot of additional testing hw on chip. But maybe there are some
> improvements made the last three years.

We do test the delay parameters very carefully and very thoroughly, by
many means, including on-chip oscillators. Instead of expensive on-chip
hardware, we use reconfiguration to reach the many subcircuits on the chip.

Don't forget, making and testing FPGAs is our livelihood. We have
invested many hundred man-years in the development and fine-tuning of
our test procedures. We must guarantee functionality and performance
over temperature and voltage extremes for each single part shipped. 

Apparently we know how to test our devices, otherwise we would not be in
business anymore.
> 
> Anyway, you can't do tests before selling a fpga, that replaces Bist
> for dynamic faults in the way I understood dynamic faults. Dynamic
> faults will occure sometime during lifetime of the fpga due to
> material aging or (especially in SRam based Fpgas) due to single event
> effects.

All Xilinx FPGAs support configuration readback, which can be performed
at any time, without any impact on the device operation. That's a BIST function.

The affect of aging is described in our reliability reports, and is
quantified in a number called FIT = failure in time. 1 FIT is one
failure in one thousand million ( american billion) device hours. This
is all well understood and documented. It is amazing that the FIT value
has remained fairly constant over the years, while device complexity has
increased thousandfold. Of course, that was necessary for the
penetration of ever more complex ICs into almost every aspect of
civilization. 

Single-event upsets are soft failures, mostly caused by various
radiation types. They can only be described in statistical terms, and
they disappear once data is re-written.  
This is a totally different subject...

Peter Alfke
>================================= 
> bye Thomas

Besides reiterating that our devices are tested thoroughly through our own
internal test programs, I should point out that it takes a large team of
engineers working for ~1 year before a chip is released to come up with the
suite of tests we throw at our chips to make sure that they function.  I
believe this includes tests of all varieties that you mention.

Even if you had the resources to develop a good suite of tests to achieve
99+% coverage of the parts of our chip your design uses, there are a huge
number of configurations required to achieve this coverage.  We employ
special test pins and test modes to improve the throughput and reduce the
data requirements for these configurations, but it still would take a hefty
amount of ROM to store the configs.

My guess would be that it would be cheaper to build redundant hardware (for
example, use triple modular redundancy) for your design than it would be to
develop and deploy a self-testing capability.  The chances that you've got a
fault that we didn't detect that isn't covered by your TMR circuitry would
be very very small.

Not that I'd have a problem with you finding a way to re-test EasyPath parts
yourself ;-)

Regards,

Paul Leventis
Altera Corp.

Hello,

Peter Alfke <peter@xilinx.com> wrote:
> Thomas Stanka wrote:
> > Anyway, you can't do tests before selling a fpga, that replaces Bist
> > for dynamic faults in the way I understood dynamic faults. Dynamic
> > faults will occure sometime during lifetime of the fpga due to
> > material aging or (especially in SRam based Fpgas) due to single event
> > effects.
[..]
> Single-event upsets are soft failures, mostly caused by various
> radiation types. They can only be described in statistical terms, and
> they disappear once data is re-written.  
> This is a totally different subject...

SEU are critical if they change the configuration of your device, but
uncritical in static devices with proper protection (eg. ASIC with
TMR).
I thought more about single event effects with permanent impact on the
device like wire degrading due to ESD or critical failures in your
power supply (or heavy ion in radiation environment).
Just the kind of error that's a bit to weak to instantly kill your
device but strong enough to have an permanent influence.
These failures might be very seldom, but maybe just because they are
so hard to detect?

bye Thomas