DFT education for designers - is it worth it?
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?
Stumble It!
“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?”
We have learned that while you must have specs and educate the
design teams that it is critical that you have a tool that
will catch any deviation from the specs.
Our code base has zero verilog syntax errors. That is not because our designers are diligent about reviewing their code
against the verilog spec. Most of us rarely look at the spec.
It is because we require that everybody run at least one
simulation before checking in any new code.
Designs have grown to the point where if a human must review
your code to ensure that it is correct then you will miss
something. There is not enough time in the schedule to check
everything.
We rely on rtl checker tools and I can catch any problem
and have a fix for it within 24 hours. That is for issues
checked in by our East Asian teams. Mistakes made on the
west coast are found and fixed in about three hours.
The biggest problem I have is that the people in the trenches
writing RTL are the last ones to hear about any new dft
requirements. My guys get third party IP and assure me that
it is testable. I find out that it was state of art ten years
ago but can’t support some of the new techniques that we now
have to use.
I want to point them to some IEEE rtl coding spec and tell
them not to send us any code that doesn’t conform.
Our management has enough experience with chip delays due
to last minute test issues that there is support for
designing test in as early as possible and supporting
it though the life cycle. But it would be nice to have a
few “dog and pony” shows that I could give to explain what
to do and what bad things will happen if you don’t.
John Eaton
That would be a nice thing to have, I agree. And it does sound like people are working on it - see TMAG. I’ll bet the people associated with this effort would be glad to hear your views (and of course, I always welcome you to share them here at DFT Digest. Thanks for your comments!
JMF
There are many checklists - different for ICs, then boards or systems. We sell a spreadsheet program, called The Testability Director that has hundreds of guidelines and provides means to score how well designer meet testability criteria. The Surface Mount Technology Association (www.smta.org) also has a 2002 Testability Guideline for board testability, which they sell for under $100.
Finally, the Testability Management Action Group (TMAG) mentioned earlier is actively collecting information on all aspects of testability. The group’s mission is to become a resource for testability professionals who seek to bring testability to their companies. The TMAG Tools committee is in the process of compiling testability tools and make the information available to the testability community.