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?

Check out this top 10 list (h/t Maggies Farm) from the acknowledged creator of the term ‘weblogs’, Jorn Barger - indispensible advice for new bloggers (which I’m sure applies to all bloggers). Interestingly enough, his concept of a blog lines up more with a site like del.icio.us than with any of the most popular blogging platforms such as Blogger, Wordpress, etc., which is reflected in his rule #2:

2. You can certainly include links to your original thoughts, posted elsewhere … but if you have more original posts than links, you probably need to learn some humility.

So where does that leave us? I can certainly relate to the humility lesson. Even though I do try to create original content, because I think it will attract readers, I also try to always credit my sources, and link to content that supplements my material, because more than anyone else, I know what I don’t know, which is plenty.

Personally, I found the list to be helpful - I like numbers 9-10, which may help to aggregate more high quality DFT content for me to post (I do some aggregation of DFT News already - at my Blogger account).

On more thing. After checking out the picture, I think Mr. Barger belongs in the Motley Crew that John Busco blogged about last week!

An ‘advisory’ group that is… somehow DFT religion must be brought to upper management.

Introducing the Testability Management Advisory Group (TMAG), “a grass roots organization made up of test professionals who believe that success for Testability in general, and Design for Testability (DFT) in particular, requires the involvement of management at all levels.”

The first official meeting of TMAG will be held December 10th, from 9:30-11AM in San Jose, in conjunction with the IPC Test and Inspection Conference. One can attend personally, or by WebEx.

The motivation for the TMAG is the apparent lack of support from non-technical, and upper management for DFT efforts. The subject has been addressed prominently during panels at the last two AutoTestCon gatherings.

I think most every DFT professional has dealt with resistance on some level from designers, design managers, project managers, on up the line. I myself was told one time by a project manager not to speak to his designers anymore, because I was ‘confusing them’. Why DFT was confusing to a bunch of designers is a subject for another time, but the point is, we’ve all faced it.

Louis Ungar of A.T.E. Solutions is organizing this meeting, and hoping for participation from not only DFT and Test personnel, but from non-technical management as well, to help define and document Design-for-Test best practices and clear cost/benefit analysis tools to help crystallize the advantages of supporting the DFT effort.

For questions about this group and/or event, please contact Louis at LouisUngar@ieee.org

Two items from the news this past week (presumably timed to coincide with Semicon Japan):

First, it was announced Tuesday that Asset Intertech, who provides boundary scan solutions, acquired Intertest Tech (ITT), an Irish supplier of process emulation technology. This seems to be a cementing of the strategic relationship they’ve had for the past three years, which is targeted toward greater functional coverage using JTAG and CPU emulation for both structural and functional testing of PCBs.

Then, just announced today, Verigy (formerly, Agilent, formerly HP), a ‘big iron’ ATE company, has signed a deal to acquire Inovys, who offers ‘DFT Testers’, such as the Ocelot, Ocelot ZFP and Personal Ocelot. This is an interesting turn of events, given that Advantest (another ‘big iron’ ATE company) recently announced their T2000 tester, which claims to cut the cost of test in half.

My first thought is that it seems that in a tight semiconductor market, the test companies are circling the wagons and working together, a la Asset+ITT and Verigy+Inovys.

My second thought, regarding the IC ATE announcements (in conjunction with other articles that have appeared in the recent past), is that perhaps we’ll be seeing more ATE vendors crawling over toward standards-based systems, after years of resistance. At least with the DFT-class testers - most DFT testers are standards-based testers.

Anybody else have a take on this?

It still amazes me just how long DFT has been around. I suppose that time passes quicker than you think; turn around, and fifteen years have passed. It was about that long ago when I had my first exposure to scan and ATPG. And to me - it was brand new technology. So when I read about the concept of structural test and stuck-at fault models possibly being kicked around fifty years earlier… well, you see what I mean? Amazing…

Structural Test is Born…

“In order for the successful operation of a test routine to guarantee that a computing system has no faulty components, the test conditions imposed by the routine should devised at the level of the components themselves, rather than at the level of programmed orders”.

Richard D. Eldred realized fifty years ago that functional testing was not efficient - and documented it in his article entitled “Test Routines Based on Symbolic Logical Statements,” in the Journal of the ACM, Vol. 6, pp. 33-36, 1959 (as quoted above). And in those four pages, the future of electronics test was forever changed. Eldred wrote the article while working on the Honeywell/Datamatic-1000. The Datamatic was introduced by Honeywell and Raytheon in 1955, had a core memory of 24k decimal digits, and filled an entire room[ref.], if you can imagine that - if not, click here and check out the photo.

So this was the beginning of Test turning the corner; the paradigm shifted from one of, “let’s verify the function of our manufactured systems, again and again “- to “let’s make sure that our verified design has been put together correctly, by checking the structures“.

And almost 30 years later, again, to add to my amazement, I struggle to convince designers to this day that functional testing, on it’s own, is effective enough to screen defective product.

Who’s fault is that?