DFT Digest

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!

Very interesting article over at embedded.com, by Tom Jackson of Cadence Design Systems. He makes some excellent points about the necessity of being aware of power consumption throughout the design flow, including the insertion of test structures. But “Design-With-Test”? What he’s describing is what I thought was termed “Power Aware Design and Power Aware DFT”.

So is Mr. Jackson creating a new design discipline? No, maybe just a new term. Maybe it’ll catch on. Regardless, it doesn’t take away from the points he’s trying to make in the article. Some of them I’ve touch on in earlier posts, such as being aware of the effects of all of the flops on your device being toggled at once during ATPG - it may be more activity than ever seen in functional mode. Test compression may exacerbate the problem, and since test compression is designed in ahead of time, ahead of time is when you need to think about it.

But “Design-With-Test”?

I started this thread a ccouple of weeks ago, a post - something about writing a DFT plan. My contention was that a testability plan is an outgrowth of the test plan, adding efficiency and coverage.

One comment (thanks, Craig!) on that post got us off to a good start by defining some of the goals and ownership of the DFT plan.

But now I’m going to venture off into the vast terrain of actually deciding what to do for a given design. What kind of design do you have? A small analog design? A big digital design? Many of today’s designs have some of each, right? I think the key is to break down the design into its main components, and then make sure to cover the boundaries.

What I mean by that is that digital circuits have their own applicable techniques, as do analog - but if the boundaries betweeen them are not considered, a loss in fault coverage is bound to occur. We’ll discuss all that later. The point is that subdividing your plan into digital and analog is a good way to start.

Considering the fact that I’m a ‘mostly digital’ guy, that’s where I’m going to start. No worries, I’ll get to the analog - quicker if there are requests - but DFT-wise, digital’s the low hanging fruit and the biggest bang for the buck. How’s that for multiple metaphors?

Let’s explore…

(more…)

Pssst!! Want to boost your profit margins by a few percent? Here’s the secret: take your test to the design (you know… DFT!). This is the message of a commentary by Jim Healy, CEO of LogicVision.

“Manufacturing should have the ability to drive test cost and final package yield criteria into design specs…”

Like a whisper to a scream, such is the mantra of the the entire DFM movement this year. I couldn’t agree more. The hard part is implementing those “design specs” during the design phase. A score of start-ups, each one pushing to develop the next killer design tool, are betting it can be done.

Now, a commentary from the CEO of LogicVision must contain the obligitory plug for BIST vs. ATPG. Stated as such, I’ll agree. Just ATPG is obviously not sufficient.

But I guess I’m not totally won over in the BIST vs. ‘ATPG + compression + at-speed scan’. In the ‘ease of use’ column, I’m thinking it’s a wash, if not a slight victory for ATPG. I think at-speed scan targeted toward small-delay defects will go farther in the yield improvement category than BIST. Diagnostics? Not sure…

But unless there exists an explicit requirement for some POST-like self-test to be used in the field, I’m going with ATPG+.

Am I wrong?

Today, Accellera has approved the Open Compression Interface standard (OCI version 1.0). See the EE Times article by Richard Goering here.

Back in Test Compression Series - Installment #2, I made brief mention of OCI, which is an effort that was undertaken by Accellera due to a need in the industry for flexibilty in test compression solutions. At this time, test compression implementations come in tightly bound pairs consisting of compression IP and ATPG software; both must come from the same company. This poses problems especially for silicon targeted for more than one foundry, where the different foundries support different yield diagnostics software.

The OCI breaks the need for pairing the IP and software by defining a common interface, which provides just enough information about the compression IP so that any ATPG tool can understand how to generate vectors, but not so much as to give away the secrets of the IP’s implementation.

Next stop, IEEE standards process. Who’s on board?