🚀 go-pugleaf

From Justin Harlow @ SRC:
|> I'll throw a thought game onto the table: Suppose we had a
|> manufacturing line whose yield was 100%...  would we then not need to
|> test products? <Everyone cringes... of COURSE we would test, they cry!>
|> You could take the position that, in this ideal environment, what we
|> are actually doing through end-of-line testing was verifying the
|> function of the design; could we not do that through formal methods as
|> we designed the device? More generally speaking, how much of what we
|> call testing is actually a cover for lack of design verification?

When I worked at DEC in the early 80s, I recall a problem with the F-11
(LSI-11/23 CPU) chips where they would pass end-of-line test at the vendor
(Intel if I recall), but fail incoming test.  After much investigation, it
turned out the problem was a difference in interpretation of the chip
specifications.  So in some sense, this is an example of where test was used
to help verify the design.  This is what I call "dumb luck" verification
(Monte Carlo verification?) since it occurs because two people implement
things independently, and just happen to expose an ambiguity or error.

But if you develop a test using intimate knowledge of the implementation
(e.g. layout-driven test generation), then test does not provide design
verification, since it only uses knowledge of the logic, circuit and layout
design, not the spec.  So the chip can pass test but not be what the
customer wanted.  The more efficiency and fault coverage gained in the test
procedure due to incorporation of implementation and manufacturing
knowledge, the less design verification will occur.  Does this mean we have
to trade test quality (more escapes) in order to gain design verification?
I would gladly let a few faulty chips out if a test caught a bad design,
since all the chips are "faulty", but the customers who get faulty chips
of a good design will probably not appreciate your efforts.

I believe test is fundamental in the sense that if your yield is 100%, then
you will not be manufacturing competitive top-of-the-line chips.  There is
always a large market for chips that are twice as fast at twice the price,
or twice the functionality for twice the price to save more than twice as
much at the board level.  Of course, you can go overboard with test like the
military does, and cause more faults than you catch.

Regarding Allingham's comment that testing isn't taught in school.  The good
schools :-) do include some testing in their curriculums, and ideally make
the students test chips they have designed and sent off to MOSIS for fab.  I
think the real problem is that most schools cannot afford to buy enough
bottom-of-the-line test equipment to give students any real testing
experience.  Additionally, relatively few schools can afford commercial CAD
software for test, but they might limp along with university software.  All
their testing is more scope and logic analyzer on an SSI/MSI protoboard,
with handwritten test sequences, if any.  Students can be taught to
incorporate DFT into their designs, and then use it in debugging, but I
think discussions of test generation or other synthesis algorithms must be
left for grad courses.  In the ideal world, students would be taught test
theory and DFT, use Cadence, Mentor, or something similar for design and
test generation, build or fab the design, get it back, and then use a small
commercial tester to test the implementation.  High quality tools are
necessary to do all that in one semester for anything other than a toy
design.