DFT Digest

In today’s 65nm and beyond world, DFT’ers are stretching their wings and flying into the land of new technologies such as test compression, at-speed scan, and newer fault models such as bridging faults. And it’s completely necessary. But don’t forget that no matter how you plan to trap more and different types of defects, you still have to cover the basics.

Think like a test engineer for a moment. Run through your standard test flow: continuity/shorts, power/ground shorts, input leakage, vil/vih, vol/voh… these are the old stand-by tests that all devices, great and small must pass.

And what does DFT have to do with these simple tests? Design for Test can make sure they ARE simple! OK, there’s not a lot you can do to facilitate a continuity/shorts test, or a pure input leakage test, for that matter.

“Ah, yes, but we have boundary scan!�? you say. All this can be taken care of with boundary scan. Well, yes and no. There is a 1149.6 standard that addresses LVDS, but let’s pretend for a second there isn’t. You still have to provide some simple access to device outputs so that the levels can be tested. NAND-tree, loop back modes, test-mode routing of inputs directly to outputs; any more ideas?

Getting bidirectional pins easily to their output state for levels, and to their input states for leakage. All important. Don’t forget the basics

If I had to express the holy grail for testability, it would be “automated coverage”. The most desirable kind of manufacturing test has been automatically generated by tools that leverage design elements and modes to make test time and resource efficient. Of course, I’m talking scan, BIST, and extensions thereof.

But no matter what you do, there will always be the exceptions: analog circuitry, clock generation logic, or custom digital logic, too time-constrained for synthesis, much less scan.

The last one is one I’m thinking about lately. This happens a lot in datapath design, and I’ve run into it a couple of times in my career. One time, I lost a battle with a designer who believed he needed the extra time he could get by using a completely latch-based FIR design. Maybe he did. But what did it mean for me? Loss of automatically driven fault coverage, since we had to make the entire block transparent during scan to get any fault coverage at all. I also got an agreement from the designer that he would come up with enough functional patterns to make our coverage goals. You might already have guessed that I never got those patterns.

SO… the question on my mind today is: In general, what approaches are available and viable enough to get good coverage in a non-scan block (perhaps many stages deep)? What kind of tricks can I play to possibly get an ATPG tool to be able to test such a block - and finish sometime this decade? Am I stuck with functional patterns? Maybe with control/observe points? And is anyone out there actually dong fault-grading anymore?

Let me know…

It’s been quite awhile since I’ve posted here. But I do think this blog is a worthwhile effort, since, in the long run, maybe I can share some experience, and get other people to share their experiences.

So look for more posts to come on several subjects like At-speed scan, Test Compression and BIST!