DFT Digest

I know, education is always good, but just how much effort should we as DFT Engineers put into educating designers about the whys and wherefores of design-for-test? Do your pleas for test access/features either turn into an endless negotiation, or fall on deaf ears altogether? Of course, test education for engineers and managers is an on-going issue for Test professionals. Committees have been formed over the years: the TTTC TAC, the newly formed TMAG.  So how do you communicate your requirements?

John Eaton writes in a comment posted to the tutorials/resources page:

I am looking for that one document that you can give to a component designer and say “Here, follow all these guidelines and we can test your stuff”.

My reply to him was that in my opinion, it doesn’t exist. And even if it did, there’s a good chance it would never get read. You can lead a horse to water, but you can’t make him drink. So what to do?

My suggestion was to generate checklists to be included in the discussion during design reviews. These DFT checklists provide a documentable set of guidelines and requirements - and very important - a place to justify and or itemize mitigating factors for DFT features that were excluded for any reason.

I have an example of such a checklist that I’ve used in the past (here it is in PDF format - it’s not all-inclusive, I’m sure, but it’s a start).  If nothing else, as long as the DFT Engineer is given the floor for a few minutes during design reviews, the issues contained within the document can be discussed.

So for all you readers out there: what kinds of documents and procedures do you have in place to make sure that Test gets a voice during the design process?

I’m having the hardest time ever keeping up on the blog this month. Call it an extended holiday hangover, crunch time at work, short spates of illness, whatever. I hope February sparks up here for me.

Last month I started writing about testability or DFT planning. Of course, I took the easiest route first. Full scan and memory BIST! Logic BIST! Easy for all digital chips. Didn’t mention JTAG, but I should have, since that’s another area where automated test insertion has worked for many years.

So, yes, we went over the low hanging fruit of the bulk digital logic. Those measures cover the mass of (usually) standard cell, scan-inserted logic. But in every sea of digital circuitry, there are spots where scan insertion is either not possible or imposes an unreasonable timing or area penalty. What methods are available to test this logic?

More after the click…

(more…)

I started this thread a ccouple of weeks ago, a post - something about writing a DFT plan. My contention was that a testability plan is an outgrowth of the test plan, adding efficiency and coverage.

One comment (thanks, Craig!) on that post got us off to a good start by defining some of the goals and ownership of the DFT plan.

But now I’m going to venture off into the vast terrain of actually deciding what to do for a given design. What kind of design do you have? A small analog design? A big digital design? Many of today’s designs have some of each, right? I think the key is to break down the design into its main components, and then make sure to cover the boundaries.

What I mean by that is that digital circuits have their own applicable techniques, as do analog - but if the boundaries betweeen them are not considered, a loss in fault coverage is bound to occur. We’ll discuss all that later. The point is that subdividing your plan into digital and analog is a good way to start.

Considering the fact that I’m a ‘mostly digital’ guy, that’s where I’m going to start. No worries, I’ll get to the analog - quicker if there are requests - but DFT-wise, digital’s the low hanging fruit and the biggest bang for the buck. How’s that for multiple metaphors?

Let’s explore…

(more…)

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…