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?
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.
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 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.
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.
Can you clarify what you mean by 'dynamic fault' - is this a failure to config, or a timing violation, or ??
and by regular updates to the device speed/timing files, that the simulation SW engine uses :)
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.
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.
Peter Alfke wrote: [OP wants to know how to do BIST for dynamic faults on FPGAs]
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.
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.
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.
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...
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 ;-)
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?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.