home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lsi / testing / 200 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  4.0 KB

  1. 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
  2. From: dmw@taurus.ece.cmu.edu (Hank Walker)
  3. Newsgroups: comp.lsi.testing
  4. Subject: Testing Thoughts
  5. Message-ID: <1992Aug28.161936.3110@fs7.ece.cmu.edu>
  6. Date: 28 Aug 92 16:19:36 GMT
  7. Sender: news@fs7.ece.cmu.edu (USENET News System)
  8. Reply-To: dmw@ece.cmu.edu
  9. Organization: Electrical and Computer Engineering, Carnegie Mellon
  10. Lines: 56
  11. Originator: dmw@taurus.ece.cmu.edu
  12.  
  13.  
  14. From Justin Harlow @ SRC:
  15. |> I'll throw a thought game onto the table: Suppose we had a
  16. |> manufacturing line whose yield was 100%...  would we then not need to
  17. |> test products? <Everyone cringes... of COURSE we would test, they cry!>
  18. |> You could take the position that, in this ideal environment, what we
  19. |> are actually doing through end-of-line testing was verifying the
  20. |> function of the design; could we not do that through formal methods as
  21. |> we designed the device? More generally speaking, how much of what we
  22. |> call testing is actually a cover for lack of design verification?
  23.  
  24. When I worked at DEC in the early 80s, I recall a problem with the F-11
  25. (LSI-11/23 CPU) chips where they would pass end-of-line test at the vendor
  26. (Intel if I recall), but fail incoming test.  After much investigation, it
  27. turned out the problem was a difference in interpretation of the chip
  28. specifications.  So in some sense, this is an example of where test was used
  29. to help verify the design.  This is what I call "dumb luck" verification
  30. (Monte Carlo verification?) since it occurs because two people implement
  31. things independently, and just happen to expose an ambiguity or error.
  32.  
  33. But if you develop a test using intimate knowledge of the implementation
  34. (e.g. layout-driven test generation), then test does not provide design
  35. verification, since it only uses knowledge of the logic, circuit and layout
  36. design, not the spec.  So the chip can pass test but not be what the
  37. customer wanted.  The more efficiency and fault coverage gained in the test
  38. procedure due to incorporation of implementation and manufacturing
  39. knowledge, the less design verification will occur.  Does this mean we have
  40. to trade test quality (more escapes) in order to gain design verification?
  41. I would gladly let a few faulty chips out if a test caught a bad design,
  42. since all the chips are "faulty", but the customers who get faulty chips
  43. of a good design will probably not appreciate your efforts.
  44.  
  45. I believe test is fundamental in the sense that if your yield is 100%, then
  46. you will not be manufacturing competitive top-of-the-line chips.  There is
  47. always a large market for chips that are twice as fast at twice the price,
  48. or twice the functionality for twice the price to save more than twice as
  49. much at the board level.  Of course, you can go overboard with test like the
  50. military does, and cause more faults than you catch.
  51.  
  52. Regarding Allingham's comment that testing isn't taught in school.  The good
  53. schools :-) do include some testing in their curriculums, and ideally make
  54. the students test chips they have designed and sent off to MOSIS for fab.  I
  55. think the real problem is that most schools cannot afford to buy enough
  56. bottom-of-the-line test equipment to give students any real testing
  57. experience.  Additionally, relatively few schools can afford commercial CAD
  58. software for test, but they might limp along with university software.  All
  59. their testing is more scope and logic analyzer on an SSI/MSI protoboard,
  60. with handwritten test sequences, if any.  Students can be taught to
  61. incorporate DFT into their designs, and then use it in debugging, but I
  62. think discussions of test generation or other synthesis algorithms must be
  63. left for grad courses.  In the ideal world, students would be taught test
  64. theory and DFT, use Cadence, Mentor, or something similar for design and
  65. test generation, build or fab the design, get it back, and then use a small
  66. commercial tester to test the implementation.  High quality tools are
  67. necessary to do all that in one semester for anything other than a toy
  68. design.
  69.