home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pmafire!news.dell.com!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!dmw
- From: dmw@taurus.ece.cmu.edu (Hank Walker)
- Newsgroups: comp.lsi.testing
- Subject: Testing Thoughts
- Message-ID: <1992Aug28.161936.3110@fs7.ece.cmu.edu>
- Date: 28 Aug 92 16:19:36 GMT
- Sender: news@fs7.ece.cmu.edu (USENET News System)
- Reply-To: dmw@ece.cmu.edu
- Organization: Electrical and Computer Engineering, Carnegie Mellon
- Lines: 56
- Originator: dmw@taurus.ece.cmu.edu
-
-
- 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.
-