DFT Digest

I sometimes wonder this.

It seems in the past several years, the design-for-test job has grown more complicated (as any other facet of the electronics design discipline), what with new (or more prominent) defect mechanisms and fault models, and new DFT methods and technologies to address them.

I was reading an interview at T&M World with Atun Domic of Synopsys, and the question came up about whether DFT Engineers are necessary to implement the constantly evolving (my words) structures for manufacturing test.  Actually, here’s the exchange:

Q: Is design for test (DFT) strictly the domain of DFT engineers?

A: Certainly, there are DFT specialists, and their responsibility is to construct the DFT strategy for the chip. But verification engineers also need to understand DFT, since they must verify the chip functionality in its test mode. As for design engineers, we see that users of our Design Compiler tool—traditional logic design engineers—also run DFT Compiler and DFT MAX, our scanning and compression tools. We’ve made these tools part of the design flow, so these engineers don’t have to call in test experts.

So DFT engineers can basically sit back and say “let’s do scan!  And JTAG!, Oh, how about some BIST!” And then everyone else will do the implementation and verificaton?  Generate patterns?  How many of you DFT engineers out there have it that easy?

Here’s the thing:  Designers aren’t interested in doing our job.  Verification engineers have enough of a challenge trying to figure out when their job is done.  Again, not interested.

I suppose, as many organizations do, it is possible to plug the DFT gap with people from the design and verification teams, and even the test engineering organization (if one exists).  However, every one of those teams has no better ally than the DFT engineer, because being the multi-disciplinarian he or she is, the DFT engineer understands how trade-offs in testability will affect the test development as well as what impact the DFT implementation may have on the performance of the design, for example.  The good DFTe lives in both the design and test worlds, and can verify the testability as well.  All that and a bag of chips, as they say…

Last week, John Cooley published the results of his 2008 DeepChip Synopsys Survey, and of course I went straight to item #6, entitled “Synopsys DFT Compiler/TetraMAX vs. Mentor DFT Advisor/FastScan“. There are some surprises and head scratchers:

• By John’s count, Synopsys DFT Compiler only has 50% of the scan insertion market. Gary Smith believes it’s more like 78%.
• According to his respondents, Synopsys TetraMAX is used twice as much as Mentor FastScan! Gary Smith’s numbers say the exact opposite.

Even John wonders, “…according to Gary, my DFT Compiler percentage is too low and my TetraMAX percentage is too high. Why that is, I don’t know“.

Well, a couple things occurred to me:

First, I believe John’s audience (and by extention, survey respondents) is skewed in a couple of ways:

• It’s ESNUG (The S stands for Synopsys), so mostly Synopsys users responded.
• It’s my belief that the Deep Chip audience are mostly designers, who are famous for not knowing exactly what’s going on in the DFT world, even on their own chips.

Second, related to my characterization of chip designers’ ignorance of their own DFT methodology, is that many don’t realize that the tools don’t stack up one for one - in other words, If I use Synopsys DFT MAX (compression tool) and Synopsys TetraMAX (ATPG tool), it’s not the same as using Mentor TestKompress (compression tool) and Mentor FastScan (ATPG tool). That’s because FastScan comes as a part of TestKompress. The Synopsys tools are separate. So when someone reports using TestKompress, you must put a mark in both The TestKompress and FastScan columns in order to make an apples-to-apples comparison.

So what do I think? Well, I believe Gary Smith’s DFT Compiler number. I think fewer and fewer people are inserting scan after synthesis is complete, most now compile scan-ready as part of their synthesis flow. Scan stitching can be done also with the place & route tool in some cases. So about 80% seems right.

On the other hand, I don’t believe either Gary or John about the ATPG tool balance. I think it’s closer than either of them say, but with TetraMAX slightly in the lead.  There are many decision makers out there today putting together cost-driven tool bundles - and will go Synopsys because they’ve got the whole flow integrated.

I have no hard data to support any of my claims, but it’s the sense I get when I talk to people…