DFT Digest

Let me hear you say yeah!

Karen Bartleson over at her blog, The Standards Game, issued an invitation to all who care*, to become a part of the balloting process for the IEEE P1450.6.1, “Standard for Describing On-Chip Scan Compression”, or Open Compression Interface.  Karen has a short explanation of the idea behind the standard, and I’ve blogged about it here before. It was ratified by Accellera in October of 2006.

Why is this standard important? Because today, if you decide to implement test compression on your device, you are stuck with the tool vendor that sold you that IP - from cradle to grave.  I think of test compression as a three-part solution: the logical IP that is implemented on-chip, the ATPG tool that creates the vectors, and the yield analysis tool that interprets failures in those vectors.  Since the hardware of the first part is proprietary, the only way for the software of the second and third parts to understand it is for the whole solution to come from the same vendor.

I can think of several ways this is problematic.  Can you?  The short story is that interoperability is better, and this is the intent of IEEE P1451.6.1.

* I think, in this case, all who care should read “all companies and/or organizations who care”.  I don’t believe the balloting is open to individuals. Someone correct me if I’m wrong, and I’ll pay the $40 to vote…

I was feeling so popular!  I was getting new register blog readers every day… Then I started noticing the disproportionate number of new users coming from the same couple of Russian sounding domains… some with really cryptic names, like ‘ReaLLyCheaPViAgRa’ and I realized these users only wanted me for their own exposure.  Comment spammers registering so they could attempt to post comments selling their goods.  Luckily my anti-comment spam plugin (Askimet) is better than my registration page test.  I also moderate comments on DFT Digest (if you ever notice that lag time).

Anyway, I just disabled registration on DFT Digest - at least temporarily.  The CAPTCHA scheme I was using was useless, as are most, if not all CAPTCHA schemes, as I have read lately (h/t Slashdot).

You may wonder what registration buys the faithful DFTD reader; I’ve wondered myself.  Someone pointed out to me recently that they were unable to reach the tutorials/resources page (there’s not a huge amount of material there right now), and I think it’s because they weren’t registered.  It seems like a reasonable trade: you register yourself, and get more access to the site…

At some point before the end of the summer, I plan to give DFT Digest a facelift - I need to update the theme with something that supports a more flexible design, and looks a little more ‘web 2.0′ for lack of a better term.  So stay tuned - there’s more design-for-test to come.

It’s a full month after DAC has come and gone, so it’s kind of ridiculous to continue.  But I’ve been busy, lazy, on vacation, unmotivated - you pick, what the heck. I think maybe I need to write shorter posts more often, so I have less chance to procrastinate.

As I mentioned in my last post, I did have a couple more conversations with some test-related people.  I reported on Winterlogic last post - but right next to them on the show floor was TSSI.  Now TSSI’s been around a long time, but they’ve been thrrough so many incarnations, it’s like they were money being laundered.  I think I tried to trace their lineage once in a previous post, but bottom line is they’re back to being TSSI anyway.

The main product for TSSI, for years, has been TDS (Test Development Series).  Basically, it’s test vector translation software, but with algorithms built in to analyze event-based input (think VCD) at its core.  It’s modular in design, so it has several ‘readers’ for different simulator output formats, and many ‘writers’ to output vectors for one of many ATE formats.

TSSI introduced a new product at DAC - a tool called ‘FailMap‘ to visually compare ATE results (datalogs, which normally list pattern failures) with the the original simulation output, for easier debugging.  In addition to viewing the failures against the expected response from the simulation, the tool also provides the capability to mask the failures, or ‘learn’ the pattern (change the expected reponse to match actual silicon behavior, and rewrite it, thereby having a passing pattern).

To automate this capability can be a big plus while trying to quickly get patterns going on the tester when silicon first arrives, and real world operation doesn’t exactly match simulation (and face it, these days, with newer processes, it’s not uncommon)  Eventually you have to analyze the failures, but to get a quick initial screen going is tough without a tool like this…

Strolling down the aisle from there, I wandered into the Magma booth and asked about their ATPG tool.  But I’ve already told you that story.  Then I stopped in and chatted with L.T. Wang of SynTest.  Nice man.  I like the books he’s been publishing in the last few years (check out this one, and this one).  He told me he had been very busy, but was going to start writing some papers - to let people know that some of the techniques used for at-speed scan test have been patented (by SynTest).

My next stop was Genesys TestWare.  But this post is already too long.  So until next time…

Update: I could swear I published this article with a title, but then I noticed it coming up blank in my feed…

All along I’ve said that DAC’s not really my show, but it was more interesting this year, given the whole EDA Bloggers Birds of Feather deal. It inspired some good discussion, and I hope it becomes a repeated occurrence as we, the independent bloggers establish our value in the EDA community.

However, as I mentioned in a previous post, in my short walk about the floor, besides noting the distinct lack of ATPG in the Magma booth, I did have a couple of enjoyable conversations with some test-related exhibitors.

First, I talked to the guys in the WinterLogic booth. This was the first year at DAC for WinterLogic. Not quite a ‘household’ name in DFT circles, this company markets a product called Z01X, which is a “high-speed functional fault simulator for Verilog designs.”   Now, obtaining coverage by fault simulation, as a matter of practice for functional vectors, has taken a back seat in recent years to to the coverage achieved with structural methods (scan and BIST). But structural fault coverage is never a complete solution for the contemporary SoC, so the structural test-suite almost always has to be augmented with functional patterns.

Now the last time I actually used a fault simulator, nobody was talking about transition delay faults or bridge faults, but current fault simulators (I’ll go out on a limb here and say there are two: SynTest’s TurboFault and Z01X) cover both those classes of faults, and claim performance improvements and other added capabilities over previous generations of fault grading software.

One of the ways in which the folks at WinterLogic do believe they are unique is in their “test ordering and redundant test elimination capabilities“.  Z01X performs testability analysis on the design with respect to each test, then starting with the best coverage test, ranks and reorders the remaining tests after each run.  They claim to be able to reduce the overall test-set by as much as 50%.

This job of test optimization is many times tackled by the test or product engineer after a device has been in production to optimize test time. The decision to reorder or eliminate tests is based upon the statistics of how often particular tests catch defective parts, determined over time by testing many devices.  I’m sure a priori test selection in the pre-silicon domain by relative fault coverage is practiced also, in an ad hoc fashion, but Z01X would be the first productization of this as applied to functional pattern sets (ATPG tools also have this capability built-in, for structural patterns).

The folks in the Winterlogic DAC booth claimed to have produced excellent results with some very big customers with this technology.  After talking with them, I shuffled to the right (to the next booth) where TSSI was set up.  I’ll talk more about that in my next post, as well as my conversations with SynTest, Genesys TestWare, and LogicVision.

Stay tuned…

OK - lesson learned - maybe.  I was tipped on this a week or so before DAC - it was pointed out to me that any content (besides the original press releases from last year) on Magma’s website relating to Magma’s Talus ATPG was MIA.  Not wanting to jump the gun, I held back, thinking I could get a more complete story.  I got a little bit more detail, but was asked not to publish it.  I guess other folks weren’t asked the same, because here it is:

Magma ATPG is mothballed yet again.  Here are the two stories that just came to me through Google Alerts:

Chris Edwards’ Shrinking Violence post “Magma bids adieu to ATPG” , which in turn links to the following story, “Magma Cans Test Tools” at the IET website (update: The IET story is also Chris’ - see his comment).

So, I am assuming Mr. Sanjay Bali (a Magma Product Director) did give someone permission to publish the news.  Now it’s here.

The quote in the articles above from Mr. Bali was “We could not differentiate hugely with the ATPG solution” was a bit different from what he told me at DAC - “It’s cooking”, he said, indicating that the tool was just not ready for prime-time.  This is more along the same line of what I heard from others last fall when the original announcement was made, that this tool was a long way from being a real product.

I would have thought differentiation would have been fairly easy, since none of the ATPG vendors are offering “power-aware” algorithms yet, that I know of.  Synopsys’ latest work targets ’small-delay defects’, whereas Mentor’s latest efforts have been ultra-compression techniques.  Cadence’s Encounter Test boasts “true-time”  or faster than at-speed test with their ATPG.

Anyone out there know more of this story?

Do tell…