This post came about after reading John Ford's post about the value of a DFT education for designers. Forget appreciation, DFT is usually the least-understood specialization in the ASIC design flow.
In my opinion, DFT is not that easy to "get" primarily because it requires a viewpoint different from synthesis, timing and place-and-route. In those fields, you usually worry about timing, area and power. It's easier to apply your knowledge from synthesis to PNR. In DFT, you worry about fault coverage, controllability and observability; concepts alien to the rest of the ASIC design flow. It gets worse. More often than not, project and design managers are from a place-and-route, synthesis or timing background. Not many DFT engineers managing projects out there. Ergo: A clear understanding of DFT is lacking at most higher levels of the engineering hierarchy. Is it any wonder that DFT is the least of the design team's priorities?
What are your options? This list is AND'ed not OR'ed (do (1) AND (2) AND (3)...).
- Have a set of non-negotiable DFT rules that everyone has to follow. This would include ensuring controllability of resets and clocks, etc. I think it's important to have a list that is not open to negotiation (or else the DFT engineer ends up having to explain each and every rule to each and everyone). This is not a enlightened approach but it saves both DFT and non-DFT groups time and energy.
- Have a DFT checklist like John's that can be used by all designers to ensure DFT compliance. This list would be a checklist form of the aforementioned non-negotiable rules.
- Use a tool like Atrenta's Spyglass-DFT to check your RTL for DFT issues. Automated approaches to verify DFT compliance is so much more error-proof than looking through millions of lines of uncommented code.
- Have a very well-defined handoff mechanism between DFT and other functions to ensure minimum confusion for the non-DFT folks. The idea is to give them what they can use without knowing the first thing about DFT. Don' t explain the differences between scan shift, scan capture and scan transition modes to the STA engineers; give them a set of appropriate constraints (comes straight out of Tetramax, if you have it) that they can use as-is. Don't explain how to identify scan chains for re-ordering to the PNR engineers; give them a scandef file that can be read both in Synopsys and Magma.
