BIST FPGA testing - Applying a test vector

[BrakePiston]

Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?

Thanks very much

 

[Mike Treseler]

BrakePiston wrote:

Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

FPGA *devices* are tested at the factory.
The FPGA design function is tested using simulation.
Dynamic faults are eliminated by using
synchronous design style and by meeting static timing requirements.

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

In theory you can shift any pattern you like into the boundary scan
registers on any compliment device. In practice, this requires lots
of software to do anything useful. Here we license boundary scan software,
but use it only in production for the purpose of
finding solder opens and shorts on circuit boards.

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?

I expect that the number of people actually doing functional test
of fpgas using boundary scan vectors is near zero. It would be
very difficult and very slow.


-- Mike Treseler

 

[Peter Alfke]

Each individual Xilinx FPGA is 100% functionally and performance tested
( at high temperature and low Vcc). We drive tens of millions of test
vectors at hundreds of different device configurations, trying to test
every little part of the device. We may not reach exactly 100%, but we
are extremely close to it. This is a large effort, and it is based on
almost 20 years of experience with our parts, and on intimate knowledge
of all their features. If any device misses one test, it gets scrapped.
That's the way we do it at Xilinx, and I am convinecd other
manufacturers do it similarily. The days of "incoming inspection" by the
customer are long gone...
I do not quite understand what BrakePiston wants to achieve. Maybe he
can elaborate...
Peter Alfke

Mike Treseler wrote:

BrakePiston wrote:
Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

FPGA *devices* are tested at the factory.
The FPGA design function is tested using simulation.
Dynamic faults are eliminated by using
synchronous design style and by meeting static timing requirements.

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

In theory you can shift any pattern you like into the boundary scan
registers on any compliment device. In practice, this requires lots
of software to do anything useful. Here we license boundary scan software,
but use it only in production for the purpose of
finding solder opens and shorts on circuit boards.

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?

I expect that the number of people actually doing functional test
of fpgas using boundary scan vectors is near zero. It would be
very difficult and very slow.

-- Mike Treseler

 

[Eric Smith]

Peter Alfke <peter@xilinx.com> writes:

If any device misses one test, it gets scrapped.
That's the way we do it at Xilinx,

Really? It doesn't get used for an EasyPath design? It thought the
point of EasyPath was that you could sell devices that don't pass full
functional test.

 

[Peter Alfke]

Eric's statement is correct. When we have a customer who has a "frozen"
design, and wants to buy large quantities of FPGAs at a significantly
lower price, we create a program that compares the error file with that
customer's specific design, and, if the failure does not affect that
user's design in any way, the part gets specially marked and sold into
that application. That's called EasyPath, since it offers an easy path
to lower cost, without any timing differences nor the need to re-verify
the design ( as was required by the now obsolete old Xilinx Hardwire and
also by the not-so-old Altera alternative, two methods that really
change the chip completely and offer a "functional alternative" with the
possibility of nasty timing surprises ).
I did not mention this, becauseEasyPath is a special case, and a fairly
new development.
All these "cheap" variations make the FPGA non-reconfigurable and must,
therefore, be described as special cases ...
Peter Alfke, Xilinx Applications
===========================
Eric Smith wrote:

Peter Alfke <peter@xilinx.com> writes:
If any device misses one test, it gets scrapped.
That's the way we do it at Xilinx,

Really? It doesn't get used for an EasyPath design? It thought the
point of EasyPath was that you could sell devices that don't pass full
functional test.

 

[jim granville]

Mike Treseler wrote:

BrakePiston wrote:

Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

Can you clarify what you mean by 'dynamic fault' - is this a failure
to config, or a timing violation, or ??

FPGA *devices* are tested at the factory.
The FPGA design function is tested using simulation.
Dynamic faults are eliminated by using
synchronous design style and by meeting static timing requirements.

and by regular updates to the device speed/timing files, that
the simulation SW engine uses

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

Some FPGA SW allows a 'flying probe' to be compiled with the design,
rather like the 'Scope probe onto a PCB with a sea of TTL gates' many
years ago. Mainly used for early design cycle debug problems.

You design can (should?) also include test modes, allowing things
like preload and readback.

For example, if your FPGA is a slave to a Micro, it can be usefull for
POST (and debug) uses to include read-back even of write registers.
Slightly more logic is used, but rarely does that bump you into the
next device.

In theory you can shift any pattern you like into the boundary scan
registers on any compliment device. In practice, this requires lots
of software to do anything useful. Here we license boundary scan software,
but use it only in production for the purpose of
finding solder opens and shorts on circuit boards.

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?


I expect that the number of people actually doing functional test
of fpgas using boundary scan vectors is near zero. It would be
very difficult and very slow.

We do Physical Vector Test a lot with SPLD/CPLD designs, but the FPGAs
have a slightly different feature mix.
FPGAs have much higher logic/pin ratios, and the high reliance on
simulation puts pressure on the vendors to get the simulation files
right asap.

-jg

 

[Thomas Stanka]

Hello,

Peter Alfke <peter@xilinx.com> wrote:
[OP wants to know how to do BIST for dynamic faults on FPGAs]

Each individual Xilinx FPGA is 100% functionally and performance tested
( at high temperature and low Vcc). We drive tens of millions of test
vectors at hundreds of different device configurations, trying to test
every little part of the device.

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.

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.

bye Thomas

 

[BrakePiston]

Thank you very much for all your replies.

I think I better clarify a few statements!


First of all: I have been looking at academic research in the fault
and defect tolerance field.
- Defect tolerance is aimed at, say, yield improvement whereby a chip
with a specific defect can still be used in certain types of
applications. Xilinx's Easypath solution is seen by academics as a
defect tolerance problem. Or so I seem to understand.
- Fault tolerance is aimed at dynamic faults, these are faults
developed during the lifetime of a device, as Thomas Stanka explained
in his post.

All of the project I have looked at have described a way to detect and
diagnose (locate) a fault. For what I have understood, there are 3
different ways of conducting these tests, with an unprogrammed FPGA.

- Reconfigure the FPGA to implement a test circuit
- Design for Testability (introduce extra hardware into the FPGA with
the sole aim of testing)
- Iddq testing

I am interested exclusively in the first of these options. Now, these
tests can be further subcategorized into BIST and non-BIST tests.
Non-BIST tests require an external "test driver" which generates and
analyses the test vectors. BIST, on the other hand, uses different
configurations (stored in a ROM outside teh chip) to do all the
testing on-chip without need for extra hardware.

Now, a possible scenario where I would like to carry these tests is in
mission critical applications, where I need to know that the device is
working properly. I am not, at this stage, interested in having the
chip on- or off-line during testing. Another possible scenario is
(very unrealistic, of course) if I buy a Easypath device from Xilinx
and want to use it for a different design than the original one. I
would then have to test the device, and find where the defect is.

So my original question was: if I want to test a wire between CLB A
and CLB B, how would I configure CLB A to force a 1 (or a 0) onto the
wire? All the work I have seen (academic research) does not tell me
how the test vectors are applied, the only say how they are analysed.

I would like to point out that I understand the limitations of these
types of tests, and I do not want in any way breach any copyright from
any manufacturer. I am just an FPGA enthusiast.

Best regards to all

Nick C






On Tue, 20 Jan 2004 17:05:50 +0000, BrakePiston
<brakepiston@REMOVEyahoo.co.uk> wrote:

Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?

Thanks very much

 

[Peter Alfke]

I think I gave you the Xilinx perspective already.
We configure each device multiple times, and apply millions of test vectors.
How we figured out these configurations and test vectors is beyond an
e-mail message. It's the result of many engineers working for over 15
years on this problem, and continuously refining it. Our goal is 100%
test coverage, and we are very, very close to that goal.

Peter Alfke
=============================
BrakePiston wrote:

Thank you very much for all your replies.

I think I better clarify a few statements!

First of all: I have been looking at academic research in the fault
and defect tolerance field.
- Defect tolerance is aimed at, say, yield improvement whereby a chip
with a specific defect can still be used in certain types of
applications. Xilinx's Easypath solution is seen by academics as a
defect tolerance problem. Or so I seem to understand.
- Fault tolerance is aimed at dynamic faults, these are faults
developed during the lifetime of a device, as Thomas Stanka explained
in his post.

All of the project I have looked at have described a way to detect and
diagnose (locate) a fault. For what I have understood, there are 3
different ways of conducting these tests, with an unprogrammed FPGA.

- Reconfigure the FPGA to implement a test circuit
- Design for Testability (introduce extra hardware into the FPGA with
the sole aim of testing)
- Iddq testing

I am interested exclusively in the first of these options. Now, these
tests can be further subcategorized into BIST and non-BIST tests.
Non-BIST tests require an external "test driver" which generates and
analyses the test vectors. BIST, on the other hand, uses different
configurations (stored in a ROM outside teh chip) to do all the
testing on-chip without need for extra hardware.

Now, a possible scenario where I would like to carry these tests is in
mission critical applications, where I need to know that the device is
working properly. I am not, at this stage, interested in having the
chip on- or off-line during testing. Another possible scenario is
(very unrealistic, of course) if I buy a Easypath device from Xilinx
and want to use it for a different design than the original one. I
would then have to test the device, and find where the defect is.

So my original question was: if I want to test a wire between CLB A
and CLB B, how would I configure CLB A to force a 1 (or a 0) onto the
wire? All the work I have seen (academic research) does not tell me
how the test vectors are applied, the only say how they are analysed.

I would like to point out that I understand the limitations of these
types of tests, and I do not want in any way breach any copyright from
any manufacturer. I am just an FPGA enthusiast.

Best regards to all

Nick C

On Tue, 20 Jan 2004 17:05:50 +0000, BrakePiston
brakepiston@REMOVEyahoo.co.uk> wrote:

Hi there, I am trying to gain a deeper understanding of the way
testing is conducted on FPGA devices. I am interested in BIST testing
for dynamic faults, not manufacturing testing.

My question is: how exactly can you apply a test vector (or even just
a 1 or 0) to an interconnect line? Can you just connect the output of
a LUT to the wire and observe the output?

I am asking this because of all the documentation I have read, nobody
mentions where they get the test vectors from.

Am i just being stupid and failing to see the obvious here?

Thanks very much

 

[Peter Alfke]

Thomas Stanka wrote:

Hello,

Peter Alfke <peter@xilinx.com> wrote:
[OP wants to know how to do BIST for dynamic faults on FPGAs]
Each individual Xilinx FPGA is 100% functionally and performance tested
( at high temperature and low Vcc). We drive tens of millions of test
vectors at hundreds of different device configurations, trying to test
every little part of the device.

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.

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.

bye Thomas

 

[Peter Alfke]

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

 

[Paul Leventis (at home)]

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.

 

[Thomas Stanka]

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