DFT Digest

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!