DFT Digest

The stream of ITC-related press releases has come and gone, and I do plan on discussing more of them, but in between, I’d like to continue to offer some observations of people who were there - something exclusive, that you won’t find anywhere else but DFT Digest.

One such person is Teresa McLaurin, DFT manager at ARM. Teresa is very involved in IEEE activities: She was on the program committee for this years ITC (a topic coordinator for microprocessor test), she was in the working group responsible for creating the IEEE 1500 Core Test standard, and has co-written a book on the subject. Teresa also presented a tutorial at ITC (she and the same people with whom she wrote the book), and presented at the Synopsys SIG event. She was very busy… so I thank her for sharing some of her experience.

Teresa describes the Monday night panel, “At-speed Scan Tests: Reality or Fantasy“:

[It was] a fairly lively panel about whether at-speed scan test can replace functional test. One of the more interesting things that came out of this was that the audience was asked how many thought at-speed structural test could replace functional test, the majority of the audience raised their hands. If this were asked 5 years ago, it probably would have been me and maybe two other people who raised their hands. This may be happening out of necessity. The panel was split on this issue, with Freescale, Intel on one side (functional of course) and TI, LSI Logic and AMD on the other.

I was curious how this panel would go. The title was provocative enough. I thought maybe it meant, “does it exist or not” :-)  Actually I thought that maybe part of the discussion would be a continuation of the logic-BIST vs. at-speed scan debate.

Anyway, it appears that even though for years, EDA vendors have been constantly improving this technology, they haven’t yet convinced everyone. People still like the warm fuzzy  feeling of seeing their device re-verified, at wafer probe, package test, and beyond.  But when you’ve got thousands of man-years invested in your functional patterns, it’s got to be hard to let go.

Pssst!! Want to boost your profit margins by a few percent? Here’s the secret: take your test to the design (you know… DFT!). This is the message of a commentary by Jim Healy, CEO of LogicVision.

“Manufacturing should have the ability to drive test cost and final package yield criteria into design specs…”

Like a whisper to a scream, such is the mantra of the the entire DFM movement this year. I couldn’t agree more. The hard part is implementing those “design specs” during the design phase. A score of start-ups, each one pushing to develop the next killer design tool, are betting it can be done.

Now, a commentary from the CEO of LogicVision must contain the obligitory plug for BIST vs. ATPG. Stated as such, I’ll agree. Just ATPG is obviously not sufficient.

But I guess I’m not totally won over in the BIST vs. ‘ATPG + compression + at-speed scan’. In the ‘ease of use’ column, I’m thinking it’s a wash, if not a slight victory for ATPG. I think at-speed scan targeted toward small-delay defects will go farther in the yield improvement category than BIST. Diagnostics? Not sure…

But unless there exists an explicit requirement for some POST-like self-test to be used in the field, I’m going with ATPG+.

Am I wrong?

Tonight there will be all manner of kids, big and small, traipsing through your neighborhood, masquerading as one thing or another. Be kind, or be tricked… Last week, at ITC, I felt a little like a trick-or-treater, walking around dressed up like a real DFT engineer.

Well, yes, I am a DFT engineer, and I have been hanging around the semiconductor test industry for many years, but ITC always makes me feel this way. I’ve actually only been to two ITC weeks. This was my first in 9-10 years. I went to a VLSI Test Symposium once also. And I always feel like a bystander among some very hard-working engineers who are consistently striving to keep the electronic test industry where it should be with respect to other electronics disciplines.

In general, for me, it was a successful trip. I re-connected with colleagues from “past lives”, and met for the first time some others who opened my eyes to new directions for this blog. Everyone I approached with the idea seemed to be supportive and positive. Now if only I can start registering some of these people. However, I will always grant partial immunity for some of those who are busy being one of those hard-working folks mentioned above. Partial.

I’d like to report on everything I saw and heard that migh be of interest, and I probably will, but it will inevitably span several posts. Where to start? Find out beyond the link…

(more…)

I’ve run across a couple of items in my reading lately about concerns with test-mode power. Not that it’s a new issue, but sometimes when you’re looking for something else, a subject will jump out you a couple of times, causing you to take notice.

Much has been studied and written about test-mode power consumption in the past few years, especially as “at-speed” scan methods have matured and become mainstream. Several different approaches have been considered for dealing with it. DFT tool vendors offer “power-aware” products to mitigate the effects.

The idea is that during ATPG, for example, or logic BIST, most if not all the flops in the device are toggling at once, perhaps for an extended period of time. The massive power draw due to above normal switching activity may cause damage to the device, resulting in reliability failures, and/or lower than normal yield at time zero, especially during at-speed test. Instantaneous switching power can cause voltage drop in the power grid, slowing down the logic and causing false negative results.

I think a good discussion of the different aspects of this issue and methods for mitigation is in order - it also ties into our on-and-off discussion of DFM issues.

More on this later…

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?