BIST FPGA testing - Applying a test vector

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

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

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

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.

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.

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

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

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
>

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
> >

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