DFT Digest

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

The mission of this website is to educate and discuss electronics design for test. At the end of the day, I want to help anyone trying to tackle the DFT problem, including myself, get through their day. What are we trying to solve? What tools are available to help us solve those problems? How do we know when the design-for-test job is done?

These are the questions I’d like to address in a series of posts (I’ll call it the basics series), which will go on for some time. I will stray into more advanced topics on a regular basis, but, I will advance the basics series just as regularly.

Topics include all those you see on the right side of this web page, in the ‘Categories’ section: scan, ATPG, BIST, JTAG, and any number of other acronyms

Of course, I should repeat often, that I would like feedback, in the form of corrections, criticisms and additional information as often as you readers can find a few spare moments of your busy day.

So please, visit often, and contribute when you can!

Well, I told myself that as the ITC faded into the past, I was going to delve into the basics - explain to myself and anyone who cares to read how things like scan, ATPG, JTAG, and memory BIST work, and how some of the tools implement them.

But just as I was about to settle down, I tripped upon this little item on John Cooley’s DeepChip.com. And it made me think. Do I care how fast my ATPG tool is, and how much do I care?

If you didn’t already follow the links and read, John was asking whether Synopsys’ claims of TetraMAX’s 12x performance increase over the past year is just hot air. I for one did not question the veracity of their claims. After all APG vendors are constantly tweeking their algorithms. I was just wondering why it was a story at all.

Update: I just tripped on this article.  This is one of the real stories in design for test today…

My reasoning below the fold… (more…)

…well at least the marketing folk do, if not the poor integration team or board test team downstream, trying to test your chip, in-situ.

While I was at ITC, I had the pleasure to meet with Ben Bennetts, who, after perusing DFT Digest noticed a distinct lack of material related to JTAG or boundary scan. It’s true that the material thus far in this blog has been device-level DFT oriented, design-for-test is important at the board level too.

Believe it or not, I had planned to write some discussion fodder for JTAG. Just the basics, and maybe some on the couple of extensions of 1149.1 that I knew about. But during my conversation with Dr. Bennetts, he called my attention to currently on-going activities extending the standards even further to address specific applications of JTAG test: SJTAG and IJTAG.

Without going into too much detail in this one post, SJTAG, which stands for System JTAG, arose from the need to be able to test several boards across backplanes, a common situation in telecom applications, for example. IJTAG, or Internal JTAG is targeted toward the ability to access any of several different types of on-chip test/measurement “instruments”.

The IEEE 1149.1 standard, commonly known as JTAG, has been around since 1990. Since then there has been work on a few extensions: 1149.4 (analog), 1149.5 (module test and maintenance), 1149.6 (advanced digital networks) and 1149.7 (reduced pin count) - who knows what happened to the numbers in between… but it’s clear the concept hasn’t run out of gas.

So in future posts, I’ll try to put together some brief descriptions of JTAG concepts, its applications and extensions. Hopefully, Dr. Bennetts and/or you readers will be kind enough to fill in some of the detail and experiences to make it a truly educational discussion!