DFT Digest

As I was in the middle of being flogged into a tapeout frenzy, I didn’t get the chance to visit ITC in November. But I guess there always must be some excuse, because I haven’t been to ITC since ‘97 or ‘98, when I was a full-on test engineer. Just the same, I try to keep track of what subjects are being discussed each year.

Anyhoo… As the frenzy died down, I started searching for all the coverage that I must have missed, being so busy and all. And I searched in vain. There really was none! I began to wonder why. I searched EE Times; they cover everything EE right? Nada. A Google search turned up two tiny articles in Test & Measurement World [1] [2] (both of which read like press releases to me), a smattering of pre-conference corporate announcements, and a couple of bibliographical references to papers that were given. After some more concentrated digging, I actually found a blog-post detailing one person’s visit to ITC.

Well good, I guess it did happen after all. I was starting to ponder the question: “What if they held ITC, and nobody came?” - those of you that are old enough might recognize a similar slogan during the Vietnam era…. hey wait! If I have to explain it - never mind.

Seriously, though - why the non-coverage? Nobody cares about test? Not exciting enough? Well, I know the former is not true; everybody cares about test So, it must have been the latter. But I needed to see for myself, so I begged a table of contents pdf from a colleague that did go. After a couple of looks at it, there are a few papers I’d like to give a read; they run the gamut from mixed-signal to microprocessor test, as well as several on delay testing which looked intersting, in title, of couurse. ITC 2005 Program chair Ken Butler cited a “resurgence in attendance and participation”. So again - why the non-coverage?

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?

So here it is, New Year’s day. No Rose Parade, no Rose Bowl… what’s a guy to do? Think about DFT? Why not? Today’s a good day to reflect upon what’s been done in the past, and what’s to become of the future. After all, this is the time of the year where the pundits and analysts release their summations of the last year and forecasts for the next year and beyond.

The big stories of last year, according to this article, were DFM (Design-for-Manufacturability) and ESL (English as a Second Language? no, Electronic System Level) tools. The latter deals with the complexity of large electronic systems, whereas the former addresses the complexities of smaller process geometries.

Similarly, DFT methods and technologies need to address these problems: What is test at the system level? And what are the problems of smaller geometries, and what tools are being offered to today’s DFT engineer to help deal with these problems?

What DFT engineers fought for the last two decades to implement in designs (scan, BIST) is now common practice and a bare minimum. But the next few years will see us fighting to implement more rigorous schemes (at-speed scan, test compression, etc.) to keep the escaped defect levels low and keep the device on a reasonably priced ATE. I’d like to explore some of these topics in the coming days and weeks. I think maybe I’d like to start with some discourse on at-speed scan (or delay test, if you prefer).