DFT Digest

This week, I’ll try to pass along Design-for-Test related DAC news as it comes along…

First, it was announced today that the standards organization Accellera has selected Bruce Cory, a DFT manager at NVIDIA, to receive the 5th annual Technical Excellence Award, for leading the effort to bring the Open Compression Interface (OCI) to be approved by the Accellera membership, and continuing the effort to pass it as an IEEE standard (IEEE 1450.6.1, which I guess is an extension to the CTL standard).

The OCI standard will be an important step in establishing tool independence with regard to test data compression and diagnosis, while still protecting EDA vendor’s compression IP. Currently, once test compression IP from a certain vendor is incorporated into a design, ATPG tools from the same company must be used, as well as any other tool down the line (yield analysis, for example) that hopes to use ATPG data. This can get particularly problematic, especially in manufacturing and test environments that would have to support as many tool flows as there are test compression schemes.

Also today,  LogicVision announced the Dragonfly Test Platform, which will be demonstrated at DAC.  The new tool seems to be  an integration of existing, and in some cases improved versions of LogicVision’s embedded test tools addressing memory BIST and logic BIST, as well as debug and analysis tools such as Silicon Insight and Yield insight.

Earlier this month Genesys Testware announced announced yet another Design-for-X tool: Design-for-Leakage-Test (DFLT).  This is actually a feature added to their Hierarchical DFT tool, HiertestMaker, and addresses problems due to lack of testability around power-aware design structures, such as “power switches, and isolations gates”, and I assume level-shifters.  Here’s the press release.  Someone over at Genesys needs to work on their website: you may notice if you go to their homepage, the latest news is from ITC 2006, and the upcoming event is DAC 2007

Winterlogic, maker of the fault simulation tool Z01X will be exhibiting at DAC for the first time.

SynTest will also be exhibiting - stop by and congratulate L.T. Wang for being elected IEEE fellow earlier this year

Nothing test-related for Synopsys, and this is not necessarily DAC-related, but I have to brag that Synopsys has added a link to this blog on their Galaxy DFT page.  Mentor, Cadence?   Hello? 

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…

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…)

Another article, this by Sanjiv Teneja of Cadence Design Systems, promoting DWT, or “Design-With-Test” has been posted over at Test & Measurement, as a guest commentary. I blogged a few weeks ago about a similar article by another marketing man from the same company. I smell a conspiracy! Just kidding, go to DeepChip for conspiracies.

Tomato, tomahto, DFT, DWT - the point is clear: Design-for-Test is not what it used to be.  Some of the areas touched on in this article were:

• Power concerns with ATPG and test compression
• Routing congestion concerns with test compression
• Improved defect coverage through timing aware
• Physical awareness during all embedded test (scan, BIST, 1500 core)

I’ve got a couple more - how about:

• Design of AC-JTAG for high-speed differential signals
• Low impact mixed-signal test features

All these issues work to draw the DFT engineer, once upon a time concerned mostly with stuck-at fault coverage and cleverly concocting ATE test modes, deep into the floorplanning, placement, routing and physics of the design flow.  You want test compression? Make sure you understand the router’s scan chain re-ordering  requirements and limitations. Are your ATPG patterns going to smoke your chip?  What happens to your scan chains when your design team decides to use voltage islands?

This is not your daddy’s DFT…

The Cell Broadband Engine, that is.  Neat article over at Evaluation Engineering.  Written bt DFT engineers from IBM and Brion Keller from Cadence, the article details the overall test approach for this multicore SoC.   I don’t know how new the article is, since Cadence released this PR in April of last year.  But it was still an interesting read.

With low pin count (128 pins were used for test) as a key goal, they took advantage of the modularity  by broadcasting scan to all the Synergistic Processor Elements (SPE) cores at once.  In BIST mode they can be tested together or independently.

One of the more interesting bits, I thought, was that for performance and power consumption, much of the data path part of the design was left non-scan.  About 40% of the total design turned out to be non-scan, if I read it right.  I would classify that as ‘partial-scan’.  Anyway, despite the data path being mostly non-scan, they did limit the number of consecutive non-scan stages, enabling them to use ATPG to test it anyway, in sequential mode.

All in all they threw the DFT book at this device, including scan, memory BIST, logic BIST, JTAG and test compression, using Cadence’s OPMISR+ (which should come as no surprise, since that technology was developed at IBM before Cadence bought it).

Impressive job!