DFT Digest

If 2005 was the first time ITC had been held west of the Mississippi, then this year marks the International Test Conference’s first visit to the left coast. What better place than somewhere with more engineers per square mile than perhaps anywhere on the planet? The bay area! Santa Clara convention center, October 22-27.

So what’s on the agenda this year? The theme is “Getting More Out of Test“, apparently referring to the ever expanding test related activities throughout the design flow, from beginning to end. To this end, there will be diverse activities relating to everything from DFT to yield management. It’s pretty well rounded, although the more popular topics are high-speed test & measurement, debug & diagnosis, and mixed-signal test. DFM and DFY are covered by the keynote, a tutorial and a full workshop.
It seems all the big DFT vendors will be there, Mentor, Synopsys, Cadence (unless they’re feeling squirrely like they did at this year’s DAC), SynTest, LogicVision, Magma, and Novas are all on the list. ATE vendors Advantest, Agilent and Credence are there also. Hmmm… where are Teradyne and LTX?

So many topics, so little time. Are you going? And what are you going to see?

Just a note to re-iterate what this site is all about: discussing the technology, methodology and best-practices of IC design-for-test. It’s as simple as that. I don’t pretend to keep up with the wrinkles in the EDA industry - even though I depend upon them for my next tool. I’m to busy trying to make the ones I got work.

That said, I was trying to explain how test compression works, as concisely as possible, to provide a backdrop for understanding what is available to help implement it on an IC that needs it. In my previous installments, the introduction and installment #1, I briefly explained why one might use test compression, and how it provides its benefits.

In this installment, I’d like to explain some of the different methods of broadcasting data from a very few scan inputs across many internal parallel scan chains; the terminology for this implementation varies from tool to tool.

(more…)

As I blogged a couple of days ago, I’d like to write a series of posts about test compression: what it is, why you’d want to use it, it’s many variations, who in the EDA-sphere offers tools to implement it, etc.

In that previous post, I hinted at the fact that the primary reason for implementing test compression on your next chip is to address the ever-expanding volume of test vectors needed to test nanometer-scale designs. The status quo of using plain old stuck-at ATPG patterns has been broken by the need for transition fault and delay fault patterns, not to mention BIST and at-speed functional patterns.

So much for the reasons - how does test compression work?

(more…)

Just a short note this afternoon, after 5 hours of trying to make head or tail of some pattern failures on the tester. The message is: DFT and design engineers, spend some time on the tester! It will open your eyes to the pain experienced by test engineers, caused by your lack of communication or attention to detail, or both. Oh yeah, it’ll also make you realize that certain ATE developers have not yet started developing software reliable enough to be classified as “modern”. But that’s another story.

Anyway, I’m not trying to be a hardass (after all, I’m dissing myself here), but it’s a fact: if you’re passing vectors to a test engineer, who has relatively little knowledge of the chips internals compared to you, if you don’t disposition every device pin as “important” or “mask out”, you will very likely get test vectors shoved back in your face.

The reason is that most of us write simulations with very narrow purpose. So “good” results are normally based upon the behavior of very few pins. The rest of the pins are “don’t care” to you, but happily translated into relevant, strobe-able, events in the test pattern.

If you deal with large ICs, it’s very likely that you don’t even have all the physically accurate models contained in the testbench you’re simulating. What do you care if the real processor’s in there? You’re writing a simple boundary scan test! Your JTAG works, but the processor interfaces are all screwy.

The other thing that was triggered in my mind as I was fighting the ATE today: I must, with every design for test trick available, make sure that the next chip can be tested on a much, much simpler tester.

Have a great weekend!

I’d like to start a series of posts - they won’t necessarily be contiguous - on the use of test compression in design for test. The DFT job has gotten so much bigger in the last few years, and test compression is one of the most fundamentally different aspects of the expanding role.

I’d like to explore the different architectures being offered, the pros and cons, hopefully without turning the thread into an EDA pissing contest. I know what tool I’m using, but I’d like to discuss all the offerings in the hope of providing true design-for-test enlightenment for all those who read, and myself, of course.

If you deal in both DFT and multi-million gate ICs, this is a subject with which you should be familiar. The economics of test require it. Intuitively, it should be easy to grasp: Take the number stuck-at fault ATPG patterns you already have, and multiply by four. That’s about how many patterns you’ll have after adding transition fault ATPG vectors, and maybe some delay fault vectors. If you’re dealing in the high gate counts, that’s going to top out many top-of-the-line ATE pattern vector spaces - your results may vary. But I haven’t even mentioned BIST patterns or functional patterns… you get my drift?

(more…)