DFT Digest

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…

Although automation tools have been around for 15-20 years, given a large chunk of digital logic, the testability method of choice has been full scan for only the last 10 years or so now. And already, ‘just full scan’ is obsolete, because designs have outgrown ATE vector memory, and constantly changing failure modes have outgrown the single stuck-at fault models that classic scan/ATPG testing assumes. Therefore, additional planning is necessary to bring efficiency to the scan implementation while covering new and different types of defects.

Efficiency can be had in the form of logic BIST and/or test compression. Which approach one takes depends upon one’s goals. Are they mutually exclusive? Probably not, but I’m not sure I could come up with a good reason to do both. They both accomplish, for the most part, the same thing by reducing the amount of vectors needed at the tester. Both can be run at speed. However, both have their advantages and disadvantages.

Logic BIST is a more complicated implementation (see some notes on that in this comment), but does have the advantage of being useful all the way into field, and is an even more compact vector set than a test compression implementation. Test compresion is easier to implement, and is more capable of targeting the small delays, if the tool is built right. Due to the fact that both approaches compact their response data, neither of them likes structures that produce undetermined values (X’s). These structures complicate the implementation.

Unfortunately in a typical design, there are many complicating factors. One of the most common ones would be embedded memory, notorious X-generators during scan. They must be controlled (usually by bypassing them) during test mode. Any other non-scan entities will cause the same problems. Another likely place in a typical SOC would be an analog-digital boundary.

When planning for DFT, make sure to take stock of these structures and boundaries. Write them into your plan – keep them there to remind you throughout the design process to check and re-check that they have been taken care of.

In this forum, a blog, it feels like I’m a stone skipping across this huge lake that is design for test. Oh well – it only takes time… When I continue, I’ll stay in the digital domain, but touch on some other important digitally-based techniques for making your device as testable as possible.

Cheers..