Delay Testing
What is ‘delay testing’? Some call it at-speed scan or ATPG. But the bottom line is that this technique involves loading scan data, parallel-clocking it twice (at functional speed – or faster), and shifting the result out of the chip.
First off – there are 2 kinds of delay test: Transition delay test and path delay test. They target similar types of faults, but differently. They both target resistive faults – slow to rise, or slow to fall transitions. However path delay testing targets that kind of fault with regard to a particular path – point a to point b. Transition delay testing targets a slow transition at a particular node, and the criterion for catching it is that its effects are propagated to any other cell in the scan chain. Since path delay tests target a particular path, the effects must propagate to a certain cell in the scan chain – point b.
ATPG tools are better geared to create patterns for transition tests, and therefore transition delay testing is, these days, what is referred to by most people as ‘delay testing’.
This is not to say that transition tests are the only kind performed. If the information is available, path delay tests are good, because they are aimed at the most critical timing paths in a design. In fact, it would seem to be a good strategy to do both, if possible. Why not make sure the most critical paths are covered, and then as much as feasible of the rest of the nodes in the design? What strategies are in use out there in the industry?
All delay tests require a ‘two-pattern test’, meaning that the data shifted into the scan chains must be calculated such that the desired transitions will result with the application of two at-speed capture clocks. The ATPG tool can generate patterns in two different ways: launch-off-shift (LOS) and launch-off-capture (LOC). Most people use the latter, since LOS requires that the scan enable signal is buffered up so that it can transition at speed, which is not usually done. However, LOS patterns are easier to generate, since the launch data is shifted in rather than captured, as in LOC (requiring the ATPG to generate only combinational patterns)
If all this confusing, I guess I’m not surprised, if you’ve not been exposed to it. A blog is not the best place for an introduction to at-speed ATPG. I have found articles (1) (2) on the net, however that do a fairly nice job of explaining things.
What I’d like to get at though, is what combinations of transition and path delay are being used out there? How are critical paths being selected? How many do you run? LOS or LOC? Why? And do these patterns do a good job of predicting whether a device meets speed or not?
January 5th, 2006 at 10:11 pm
At my previous company, delay fault testing was all about capturing defects. We pushed our ASIC vendor to implement a “delay fault first, stuck-at backfill” approach in an earlier chip that was having higher fallout rates at the board level than we wanted. The effects were pretty dramatic, and the vendor became a leader in this type of test methodology. The last chip we did with them had very low defect rates, in large part due to the delay fault testing.
We didn’t worry so much about whether the worst-case paths were chosen; we wanted maximum coverage in the delay fault test. The Mentor tool did a good job of optimizing the vectors so we got good coverage in the delay fault test, allowing the defects to be weeded out quite effectively. Correlation to a max speed was never an issue for us, though; no speed binning ever to be done.
I can’t remember if it was LOS or LOC; I would suppose the latter, though.
January 6th, 2006 at 9:39 am
Thanks for the comment! That’s seems like a good approach. For me, implementing delay faults has always been a matter of being able to supply the at-speed functional clocks to certain parts of the circuitry. Always trying to get around on-board PLLs (which, if you plan well, is trivial) and getting faster clocks than the I/O of the device is made for. In that case, something more creative is called for, such as scan-mode control signals to gate the internal clocks.
Any experience with that?
January 18th, 2006 at 10:08 am
Indeed, PLL bypass is a must for most tests. However, I think that going forward it will be critical to be able to run chips in full-functional mode in terms of clocks. This isn’t generally rocket science, but up-front planning is necessary to avoid too many PLL stabilization sequences. That gets expensive in terms of tester time.
I’m a fan of at-speed logic BIST, but haven’t gotten it onto a chip yet. I firmly believe that it will become the norm in the next few years just as scan became the norm many years ago. Then using the functional clocks on the tester will just be the norm for the bulk of the logic, and it will be the same test that can be run in-system during system assembly. Fewer correlation issues between board test and the chip tester which in my experience is a huge time sink.
January 18th, 2006 at 10:09 pm
As far as dealing with PLLs goes, I thinking more in terms of using the at-speed output from them to clock scan patterns - not for functional mode, which would be more applicable toward Logic BIST.
I’d like to save the Logic BIST thoughts for another thread, though. I would submit that Logic BIST will claim only a niche in the world of DFT practices where ‘in-system’ test is required (and I don’t believe that it is required in many cases). But I can see gap in our views, so I think another thread would be good.
However, to explain what I mean by using the on-board clock for scan patterns, there are techniques where one can define more complex capture clocking sequences within the ATPG tool. These provide controlled, at-speed capture bursts, therefore enabling the application of high delay-fault coverage patterns, without having to supply clocks at a blistering speed with ATE.