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.
Hi Aditya:
ReplyDeleteVery thoughtful comments! I especially like your last bullet - a proactive 'don't tell - Do!' approach to getting successful DFT results!
That is something I left out of my post. In real life, I've worked with the front-end design team to put in all the DFT hooks - constraints and scandef - into the standard DC scripts that the whole design team uses. So my results are pretty consistent, at the block level. However, graduating those constraints to the top is something I haven't tackled yet. Is that something that TetraMAX makes easy, even in the presence of Adaptive scan?
cheers,
JMF
Where I see Tmax adding value is that its a semi-simulator and it knows the state of the flops at any point. For some designs with complex test init procedures, this can be a godsend. For example, if you have a TAP instruction enabling scan mode, the tool writes out the final stable flop values of your TAP into the SDC. From what I've seen, pretty much any non-scan register that is a constant during scan is given the proper case analysis command in the SDC.
ReplyDeleteW/respect to adaptive scan, one thing to be careful about might be to remove the case analysis for scan compression on/off control signal in scan shift mode. the scan path during scan compression is different from the scan path in normal scan mode. This way you can time both scan modes in one shot. Alternatively, run scan shift timing in both modes.