DFT Digest

It was an offbeat announcement, I thought, when I saw Synopsys’ press release stating they had hit the top500. Number 242 in the top 500 fastest supercomputers that is…

So, since when are EDA companies in the business of creating teraflop computers? Especially wheen they’re constantly engaged in making their software faster. But there it is, all you need are 329 linux servers all hooked up with 1GB ethernet, and you’re ready to take on your next big design (oh yeah, and unlimited licenses!).

None of the articles about the Synopsys screamer mentioned which software was being run, but then this blog post over at Mike Santarini’s blog on EDN shed a little light on why all the EDA compute power might be needed. Mentor is teaming up with supercompter specialists Mercury Computer Systems and IBM on their new offering in nm-scale OPC.

So the mass of data has become too massive for for your garden variety linux pool. You now need a supercomputer!

help…

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?

Forgive me, readers (assuming I have any), for I have sinned: it’s been over a week (almost 2) since my last post. I told myself and others that the right frequency for posting would be about 3-4 times a week, and I’ve been slacking - but it is the holidays, and if I may offer one more excuse: I’ve been doing more reading than writing.

I purchased and received my very own copy of VLSI Test Principles and Architectures, edited by Laung-Terng Wang, Cheng-Wen Wu and Xiaoqing Wen. It’s huge, just about 750 pages - 12 chapters covering pretty much all the aspects of DFT to one extent of the other.

Almost 30 people, from all the major DFT vendors and academia, contributed to this book. I recognize most of the names as long time contributors to the practice of design-for-test. As you can imagine, it turns out to be a very detailed and well informed volume of information. Topics covered include test generation, BIST (logic and memory), boundary scan and core test, test compression, and an excellent wrap up at the end covering the latest test technology trends.

I think there’s something here for every design for test practicioner. Most of us are not experts on everything DFT, and at some point or another will have to extend our knowledge of the craft. VLSI Test Principles is a great place to do that. It’s up-to-date, and detailed enough to provide a good understanding of any of several subjects in DFT. Beyond that it’s one of the most solid values in technical books I’ve ever seen - going for $56.95 at Amazon, when many technical books are well over $80-90…

I say it’s a steal.

I know you have many choices for DFT blogs, and I’d like to thank you for choosing DFT Digest. Welcome back!

Anyway, we have a cursory “why” discussion behind us for now. But where do we start? Do we make a plan? Have you ever heard of a DFT plan? Google “dft plan”. I found 282 matches. Now google “test plan” - over a million matches. Does that sound right to you? It does to me.

One thing we must remember: the test function is the customer of the DFT function. The Test Plan is our PRD (Product Requirements Document). The ultimate goal of design for test is to facilitate the efficient execution of that document. Right? We could do nothing to our IC design, and we can still test it. But not efficiently - and maybe not completely.

To continue the analogy, I suppose a DFT plan could be considered the reponse to the test plan. The test plan says the fault coverage will be 99%+; the DFT plan offers a way to accomplish that. The test plan says that each digital output must be tested for proper levels; The DFT plan specifies JTAG/boundary scan as the way to do that.

So therein lies the answer to “where do I start?” - the test plan. There are, of course, the obvious cornerstones of design for test features, such as scan, BIST and JTAG, whenever and wherever each are applicable. But to have a complete implementation, look to the test plan, and figure out what could be done to make it easier!
More to come on this later…

I’m just going to have to accept the fact that when I go back and read some of my posts, in retrospect they will seem like pointless rambling - and that I’ll try to go back and bandaid them only to make them worse. It seems that could happen more often in this type of forum, the blog, especially because we’re discussing something as involved as design for test.

I felt that way even as I posted my last post on why we do DFT at all. The answer was that it has to do with test economics. But my post only felt like qualitative poking and prodding at something much more substantial than the post would lead one to believe. Engineers do research and publish papers on test economics. It’s important and becoming more so, and I think it’s a must for every electronics engineer considering a new test feature to understand the subject.

I don’t believe I’ve understood test economics well enough myself over the years. So I did some reading. One of the books I’ve picked up in the last year is Essentials of Electronic Testing, for Digital Memory & Mixed-Signal VLSI Circuits, by Bushnell and Agrawal. It has a pretty nice section on test economics. One of the things I like about this book is that it has an extensive bibliography (almost 750 references) that it consistently points to throughout each chapter, if the reader wishes to drill deeper into any given subject.

One of my take aways from this particular section was the component of the overall cost of test that is yield related. (more…)