“A hen is only an egg’s way of making another egg.”
Samuel Butler (1835-1902)

It’s always valuable to keep in mind the point of view of your customer, but sometimes we fail to appreciate exactly who the customer is. In chip design, it’s easy to overlook the fact that before the fruits of your labor end up in a computer or an MP3 player or a cell phone, they pass through the hands of another “customer,” an engineer who, if all goes well, you will never meet. That’s the test engineer, and if the test engineer isn’t satisfied, your chips may never reach their intended market. If prototype chips fail, there are three possibilities: design flaw, manufacturing flaw, or test pattern flaw. Years of experience shows that of the three, test patterns should always be presumed guilty until proven innocent.

You created your chip design and test patterns for it, and you think the purpose of the test patterns is to verify the chips. But the test engineer’s final product is the test program derived from your patterns, and from her point of view, the purpose of the prototype chips is to verify the test program. Keeping that in mind, and following good Design-For-Test (DFT) practices, will ensure that you never need to meet the test engineer to debug a test program in the heat of a shipment deadline.

You may think you were hired to design a chip, but you were in fact hired to design a product. If you were hired to design a chip, you wouldn’t have to worry about all this DFT and Design-For-Manufacturability (DFM) stuff, anyway. Getting one chip to work on one board would be sufficient. Trial and error will accomplish that, given enough prototype chips. But any fool can make one of anything work. The object of the exercise is to design something that’s manufacturable, and in the world of integrated circuits, manufacturable means testable. There are two very different environments where your design has to work, and the end product is the second. The test environment is the first. Verify your design for both environments.