DFT Digest

I’ve had some feedback on this website that pointed out that although the concept is good, the information people are looking for is not easy to find (or not there!). My mission for the near future is to try to address that.

One of the ways (that I sort of lucked into) is the addition of the DFT Forum as an affiliated website, in cooperation with Siyad Ma. I believe once we get enough people signed up and sharing information, that DFT Forum will be a valuable resource for anyone wading in the waters of design-for-test.

Another way to make information more accessible is my new effort: The Tutorials/Resources page. If you look over on the right-hand sidebar, under the ‘Pages’ heading, you’ll see a link called ‘Tutorials/Resources‘. This will lead to a more organized (maybe) set of pages of my own writing, as well as links to other material available on the web on a variety of design-for-test subjects. It’s a work in progress, I’m going to try to add a section or do every month. Cross your fingers, and let me know what you think…

The other thing that I’m going to try and do is go back and re-categorize some of my posts, so that information within those posts are easier to find.

I don’t know if I ever mentioned it before, but a DFT blog was not my original objective for creating an IC design oriented website. In truth, a couple of buddies and I had visions of a well-oiled EDA forum site with experienced professionals trading tricks of the trade – I was just going to be the design for test moderator. But, as always, engineers get busy or distracted, and well, we haven’t pulled it off yet.

However, there are other websites with forums out there. A couple come to mind: design-for-test.com (this would be my preferred place to post a DFT question, as it’s run by an expert), edaboard.com, and edacafe.com also has a forum. One thing about these forums – it seems DFT still remains somewhat an esoteric art. Some of the questions: “Why DFT?”, “What is DFT?”, or “Please state all the DFT design rules and their solutions…”

Once again, design for test is often lobbed to a junior member of the design team, who more often than not, has no idea where to start. And since a majority of our engineering schools spend next to no time on test, well, here we are.

Dave Letterman counts down from 10 to 1, but I’m pretty much a bigendian digital DFT engineer, so I’m going from 9 to 0. So without further ado, I present to you my ‘Top 10 Scan Design Rules’:

9 - Melting pot: NOT! don’t mix scan cell types in a design
8 - Primary input controlled resets
7 - Primary input controlled clocks
6 - Fight the scourge of internal tri-state busses
5 - Mixing clocks and data is racy
4 - Avoid combinational feedback
3 - Remember your memories
2 - Proceed with caution (from one clock domain to another)
1 - Know your ATE
0 - Scan everything

The longer winded explanations are after the click. Have a read, and let me know what you think! (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…

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…)

Any good introduction to a topic starts with some discussion of motivation. DFT is no exception. In fact, over the years, most DFT and test engineers have spent more time than they would have liked justifying to designers and design managers the inclusion of test hardware in electronics products.

It’s seemed to me through the years that the only thing designers were taught about design-for-test was that it made their designs bigger and slower, something to avoid. Unfortunately, there is truth to that: one of the biggest concerns in most of today’s challenging designs is power, and smaller designs normally use less power. So it seems that we DFT folk are always at least somewhat at odds with the marketing requirements…

My own path to design for test was hacked out of desperation, after spending years on the ATE trying to implement functional patterns that, in the end, were not even sufficient enough to keep me (or some poor product engineer) from seeing devices again as customer returns. In a lot of cases, this was an acceptable use of my time, and being in a more consumer oriented market, was not critical to life or limb in the field.

Fortunately however, we do have an analysis weapon to use, pre-tapeout, in this fight, and any book on electronics test will have a section devoted to it: the economics of test. It remains the single most useful tool to determine whether or not to include a test feature as part of a design.

More below the fold… (more…)