DFT Digest

Over there to the right of this web page, you’ll see a link named ‘DFT in the News‘ to a page that I keep at blogspot. Its www.dftdigest.blogspot.com.

Well, I couldn’t figure out how to maintain two pages of posts, sorted from newest to oldest, so I just started another blog to contain just links to DFT news articles and press releases, no comments offered. I’ll probably merge them into one site eventually… it only takes time, and effort, both of which are in short supply when the day is done.

Anyway, there it is… I’m short on time this week, so I haven’t posted - but please send me ideas of what you’d like to see covered in a future post!

Thanks!

I’m learning new things every day. Just recently, a friend of mine asked if I’d like to review a few papers for this year’s ITC. Being a part of the organizing committee, her areas are microprocessor test, SoC test, and NoC test.

Feeling a bit ignorant, I asked, “uhh, what’s ‘NoC’?”. “Network on Chip” was her reply. Oh, OK, what’s a ‘Network on Chip’? Well, I decided to go looking around on my own. What’s the first thing anyone does in this situation? I Googled it. Of course, one of the first hits was a Wikipedia entry, so I went there for an intro.

One of the first things I noticed as I started reading was that On-chip Networks are not necessarily communications chips, which was my first thought. It’s really more about data communication within a SoC. Someone realized that passing data around a huge chip might be more efficient if implemented like a communications network, rather than a bus-based architecture, like many are today. Fascinating! This idea has been developing over the last several years; According to the wiki article (which was lifted from an article in this newsletter), a full day workshop in conjuction with DATE was held last year, and the first dedicated NoC symposium will be held this May in Princeton, NJ.

Although neither DFT nor test were specifically mentioned in the CFP for the NoC Symposium, the following paper made the cut: Implementation of a Design-for-Test Architecture for Asynchronous Networks-on-Chip (Xuan-Tu Tran, et. al.). This paper targets a globally-asynchronous, locally-synchronous (GALS) system. The same authors have presented similar work a couple times in the last year.

If you look hard enough, you can dig up a few papers on NoC test. Almost all of them produced in the last year or two. Unfortunately, many can only be had for a price through IEEE.

Any of you readers out there have more information on NoC test or DFT? Care to share?

Way back in the dark ages, we’d hand craft test patterns for our circuits. We would brainstorm corner cases, and even after we were done, we’d cook up even more patterns to cover odd defects in chips returned from customers. Now, that was living!

Then the logic simulator came to be, and on its heels, the fault simulator. Glory be, we could prove our vectors in the comfort of our own cubicle, and evaluate their effectiveness to boot!

As ICs followed the edict of Moore’s Law (is it just me or does this Moore’s Law appear in 80% of all EDA related articles… still?), the practice of using functional vectors has become but just a facet of the total test solution for best fault coverage. In fact, one hopes that good fault coverage is obtained chiefly with structural test vectors generated by ATPG. Functional vectors are still used mostly to cover speed-related defects. Right? No need to actually fault grade them…

Well, in the real world, most ICs do not consist of 100% scannable sea-of-gates logic. There’s always some custom digital logic, usually too speed or area sensitive for scan. And in some cases, we have large portions or entire chips of this ATPG-unfriendly stuff. These chips must still be tested - so functional patterns or functional BIST (not the commercially available full-scan logic BIST) must serve the objective.

So how do we fault grade them? A friend and fellow DFTer has recently wrestled with this very issue, and offered DFT Digest some insights on the matter. I would like to summarize some of his findings, after the click… (more…)

How much is enough? I mean, the more the better right? Shorter test time, fewer I/Os needed, what’s not to like about that?

If you were at ITC last year, and you were clued in on device-level design for test issues as I was, you may have noticed that both Mentor and Synopsys came up with papers addressing this issue. Interestingly enough, it seeemed they were coming from completely opposite points.

Chris Allsup from Synopsys brought the paper entitled The Economics of Implementing Scan Compression to Reduce Test Data Volume and Test Application Time.

Janusz Rajski of Mentor, et. al., presented a paper that describes a new test compression architecture, entitled X-press Compactor or 1000x Reduction of Test Data.

If you missed them, related articles have appeared at Test & Measurement World Online: The Mentor article called simply, Test Compression, and the Synopsys called Optimizing Compression in Scan-based ATPG DFT Implementations.

So now that you’ve clicked on the links and thoroughly read and considered each article, what do you think?  Do they argue opposite points?  Leave a comment below and tell me.

My take is after the click.. (more…)