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…

May I be the first to call for the removal of the ‘T’ in DATE (Design Automation & Test in Europe)? If you read the trade press, there was no Test there! DATE 2008 came and went, and for those of us interested in Test - if you weren’t lucky enough to attend - well, it may as well not have even happened. One out of seven technical tracks was dedicated to test issues, but precious little energy was spent by the ‘legitimate’ trade press regarding any test-related activity at DAtE. Oh, I did see one word-for-word regurgitation of Atrenta’s announcement of a DFT-related tool enhancement supporting RTL analysis for transition faults and low at-speed fault-coverage. Good thing we had a ‘journalist’ to vet that story out…

DAC will be the same this year - according to the published conference program, there is exactly one session that is test-related, grouped together with about ten verification events/sessions, under the heading ‘Verification and Test’. DFM garners slightly more mindshare. I guess that’s fine. At least DAC doesn’t have ‘Test’ in the name of their conference.

So what do you think, Test and DFT folks? Are we not stepping up to the plate and contributing? Or is the existence of test-related categories in these conferences just a token nod to us guys on the other side of the wall between design and test?

Good day DFT folk - just a reminder, DATE 2008 started today. For those of you readers who are lucky enough to be in Munich this week for the event: What are you looking for? What sessions, and/or events do you have your eye on?

One person there this week is JL Gray of Verilab, and author of the blog Cool Verification (there’s a link to his blog in my blogroll over in the right-hand sidebar). You can see his initial post regarding this year’s DATE here.

JL solicited suggestions for interesting session or events from his verification readers. I had to chime in from the perspective of a test guy. Here’s what I said:

For Tuesday, First, I’d go to session 1.5, Advances in BIST for mixed-signal devices, and see if I could make it through all the math without a brain implosion. It’s an area of test that needs attention.

Then I’d stagger over to session 2.5, Advances in SoC Test, where I’d be a bit more comfortable, because that’s where I live - very concerned about test data volume.

Wednesday, I’d attend Session 6.5, the Hot Topic: Test Challenges for Low Power Devices. I think this is the top test issue for 2008.

Beyond that, I’m pretty interested in any of the musings surrounding the next couple of technology nodes (45nm, 22nm). I’ll be living through them in the next couple of years. Exciting times… the variability dimension in chip design is a new frontier, I think.

Low-power test design is also a big interest for me - so any of those papers would attract my attention.

So what do you all think? What interests you? Again, if any of you are in attendance, I’d really appreciate an update from you.

Bis Später!!

I was reading Peggy Aycinena’s DVCON post at EDACafe this past week, and ran across a couple of thought provoking (at least for me) paragraphs. Ms. Aycinena was describing the Wednesday keynote speech given by Wally Rhines of Mentor. He opened his talk with a discussion of DFT. I’m reproducing most of the DFT part, and only a portion of his verification discussion, for brevity:

…He said on-chip complexity forced folks to search for better ways to test over the years. Bigger and faster computers had helped, as had testing for stuck-at faults, but the number of transition faults still got bigger. Test engineers beat that stuff back, Rhines said, by shifting to scan-based test, by introducing ATPG, BIST, and ordered-test patterns, and had increased test efficiencies by up to 10x. But it wasn’t enough because even though the cost of components came down, the cost of test did not.

Then in 2001, Rhines said Mentor’s DFT guru Janus Rajski came up with a new approach based on the theory that folks should stop testing what they’ve already tested. Rhines said implementation of the algorithms behind on Rajski’s theory, in combination with test-data compression, has increased test capability 100x and will increase that capability 1000x in the next 5 years. He concluded, “We moved from a mode where we added more cycles of test, to a mode where we added more test per cycle.

Rhines moved on to verification and reiterated what everyone knows – except those who’ve been on a different planet for the least 10 years – verification costs more than design, and that’s way, way too much. [snip - and Rhines says] “I believe that there’s something out there that will do for verification what test-data compression did for test,

So how about that? For so many years, test borrowed from verification, in that functional patterns originally used for verification were re-targeted to the ATE to screen parts. Advances in DFT methodology, from necessity, made huge gains in efficiency by looking at the problem structurally. Now verification, painfully expensive and time consuming, could benefit from the same kind of innovation.

Any ideas out there? There’s money to be made….

Now let’s face it: Design for Manufacturing (DFM) is the hottest sector of the EDA industry. Everything else is, well, meh. From what I can gather, there are those who feel the sector of the future should be ESL, but it’s my opinion that true system-level design is many years out. Let designers get accustomed to SystemVerilog, I say. DFM, on the other hand is an immediate need. It cuts to the bottom line of profitability for every semiconductor company pursuing leading edge products. These are problems the industry needs to solve.

I started writing this post a few days ago, and let it lie as a near casualty in my recent fight with blogging burn-out. In the mean-time, John Busco wrote a post on Sramana Mitra’s contention that DFM/DFY provider PDF Solutions needs to find an eligible EDA company (or vice versa) for company nuptials. John wonders just how big the DFM sector can get, when it’s main customers are fabs and big IP providers. That’s a good point.

But I still contend that this sector is crucial to semiconductor companies, fabless or not. Very few chips, without it, will make it out of the fab alive. And that’s no way to run a chip business. So maybe Sramana is right - DFM/DFY companies need to be hooked up with EDA vendors as part of their portfolio. The business model should be different in that the actual benefactors (chip companies) will be using the tool, through the tool owner (the fab) - unless the chip company is big enough and pushes enough volume to warrant having their own tool. I rent my ski equipment, if you get the analogy.

So what does this have to do with Design-for Testability? I’ve mentioned a few times that DFT/Test are essential to a successful DFM strategy. It should be obvious - I mean, without a feedback mechanism, and data collection, how can yield be improved?

In a new article: DFT, ATE drive yield improvement, in T&M World written by Ajay Khoche of Verigy and Wu Yang of Mentor, the benefits and challenges of leveraging structural test results by linking them back to the design itself. The EDA industry is actively working to create these linkages - companies that provide yield analysis tools should be able to take scan failure data and attempt to automatically isolate the failing circuitry in the schematic, and ultimately, the layout. Yet another reason for DFM/DFY tools to be part of a EDA vendor’s portfolio, because, as of now, standard linkages are not yet in place.