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? 

System Verilog was signed off as a standard by IEEE in late 2005. In the 2-1/2 years since, front-end design tools for synthesis and verification have been making significant strides in support of the standard - not without limitations and missteps - but the effort is there. Progress has been made. So what of the DFT tools? Well, so far - in my experience - it ain’t happening.

The first thing I hear the peanut gallery saying is, “So what? ATPG tools read synthesized netlists, and they’re almost always structural Verilog anyway”! True, for the most part. But how about the situation where you’ve got a mixed SoC where the top level is not synthesized? Designers, when given the chance, will take advantage of the shortcuts available in the newer incarnations of the Verilog language (both 2001 and System Verilog). So the DFT engineer is forced to retrofit the top-level modules to old Verilog.

OK - no big deal… right?

But what about other kinds of DFT tools? memory BIST tools? Boundary scan tools? In a typical flow, these tools provide efficient implementation of Design for Test by reading the design RTL, integrating the test structures into the code, and outputting the augmented RTL, ready for synthesis. So what’s a DFT engineer to do when the design team decides to transition to System Verilog? If these tools aren’t supporting System Verilog, the DFT engineer (or designer) is in for more manual work.

So what is the typical response of the DFT vendor when asked about the lag? “Not enough customer demand”. So does that mean the uptake of System Verilog is not as swift as reported?

What’s your experience?

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…

I was perusing the latest version of IEEE Design & Test, which focuses on ICs for Secure Embedded Computing, and it reminded me of a small flap a couple years back about the security, or lack thereof, of scan chains (Scan design called portal for hackers, EETimes, 10/25/2004). Although I haven’t personally noticed any other discussion on the subject since then, a quick Google found a paper as recent as 2006 (A Low-Cost Solution for Protecting IPs Against Scan-Based Side-Channel Attacks, VTS ‘06).

FYI, “Side-channel Attacks” are attempts to decipher or learn encryption algorithms (or learn the IP inside a chip, maybe) by gaining information about the physical implementation of the device itself - in this case, via the scan-chains. Methods for side-channel attacks run the gamut from glitch and power analysis to fault injection attacks. It’s amazing what people can learn by causing a chip to work abnormally.

As it turns out, it’s pretty easy to hack an encryption chip using scan chains (Scan Based Side Channel Attack on Dedicated Hardware Implementations of Data Encryption Standard). So what’s the alternative? Mention was made in the EE Times article that a “primary alternative [to scan/ATPG] is built-in self-test (BIST), which is more secure because it doesn’t require visible scan chains”. And so we see another facet to the “Scan vs. BIST” debate.

Interestingly enough, there were no direct references to scan-based attacks in any of the D&T articles. So what is the status of this issue? Did it not pan out to be that much of a problem? The applications for embedded security can only be growing. Are any of you readers close to this issue?

I’d love to hear from you…

The stream of ITC-related press releases has come and gone, and I do plan on discussing more of them, but in between, I’d like to continue to offer some observations of people who were there - something exclusive, that you won’t find anywhere else but DFT Digest.

One such person is Teresa McLaurin, DFT manager at ARM. Teresa is very involved in IEEE activities: She was on the program committee for this years ITC (a topic coordinator for microprocessor test), she was in the working group responsible for creating the IEEE 1500 Core Test standard, and has co-written a book on the subject. Teresa also presented a tutorial at ITC (she and the same people with whom she wrote the book), and presented at the Synopsys SIG event. She was very busy… so I thank her for sharing some of her experience.

Teresa describes the Monday night panel, “At-speed Scan Tests: Reality or Fantasy“:

[It was] a fairly lively panel about whether at-speed scan test can replace functional test. One of the more interesting things that came out of this was that the audience was asked how many thought at-speed structural test could replace functional test, the majority of the audience raised their hands. If this were asked 5 years ago, it probably would have been me and maybe two other people who raised their hands. This may be happening out of necessity. The panel was split on this issue, with Freescale, Intel on one side (functional of course) and TI, LSI Logic and AMD on the other.

I was curious how this panel would go. The title was provocative enough. I thought maybe it meant, “does it exist or not” :-)  Actually I thought that maybe part of the discussion would be a continuation of the logic-BIST vs. at-speed scan debate.

Anyway, it appears that even though for years, EDA vendors have been constantly improving this technology, they haven’t yet convinced everyone. People still like the warm fuzzy  feeling of seeing their device re-verified, at wafer probe, package test, and beyond.  But when you’ve got thousands of man-years invested in your functional patterns, it’s got to be hard to let go.