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?