Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!deimos!uxc!uxc.cso.uiuc.edu!mcdurb!aglew From: aglew@mcdurb.Urbana.Gould.COM Newsgroups: comp.arch Subject: Re: Testability Features Message-ID: <28200253@mcdurb> Date: 17 Dec 88 19:32:00 GMT References: <8453@bloom-beacon.MIT.EDU> Lines: 79 Nf-ID: #R:bloom-beacon.MIT.EDU:8453:mcdurb:28200253:000:4226 Nf-From: mcdurb.Urbana.Gould.COM!aglew Dec 17 13:32:00 1988 >/* Written 6:39 pm Dec 16, 1988 by seeger@beach.cis.ufl.edu in mcdurb:comp.arch */ >In article <28200252@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: >| >|..> Richard A. Lethin of MIT asks about testing of VLSI RISCs >|..> and Mark Johnson of MIPs makes some comments. >| >|Talking about testing, I finally think that I have figured out >|one of the things that has been bothering me about hardware >|testability methodology. >| Most VLSI test methodology seems oriented towards detecting >|*implementation* or *fabrication* errors, not *design* errors. >|Ie. the tests look for bad transistors, or mis-wirings; they >|don't look for adherence to higher level specs. >| When people talk about test coverage, they mean test coverage >|over a limited space of implementation and fabrication errors, >|not over the much larger space of design errors. > >Why does that bother you? Design errors are supposed to be caught >during the design phase, where the design can be simulated with all >nodes equally observable. A physical test is only concerned with >testing that individual part, not the design of the part. Very >few nodes of the physical part are directly observable, which makes >this kind of test most unattractive for testing/debugging the design. > > ... > >Apologies in advance, if I have misunderstood your posting. > > Charles Seeger 216 Larsen Hall > Electrical Engineering University of Florida > seeger@iec.ufl.edu Gainesville, FL 32611 No need to apologize - you have understood the essence of my posting. Why does a testing methodology that tests for implementation errors rather than design errors bother me? First, because when I am designing a circuit I would like guidance as to what test vectors to simulate to test design correctness. Usually, of course, I have a separate software model to compare the simulation results to, but I would still like a methodology to help me choose the conditions that I run through both simulations. Testability tools that I know of take my circuit implementation, and give me vectors that cover it. Usually, running these through the circuit simulator and the higher level simulator catches trivial design errors well enough, but I know of at least one situation where they did not. So, I am left with all the standards: test boundary conditions, a few random patterns, etc., much like in software testing (see next point) and with no idea of "sufficiency". I suppose what I really want is a test generator that can take a high level spec and a low level spec, and generate tests that make you reasonably confident that the low level deesign actually implements the high level design. Whereas the test tools that I know of take a low level schematic and generate tests that make you reasonably certain that a physical implementation actually implements that schematic. You could get picky, and say that the low level design is actually an "implementation" of the high level design, but how does this help me gain any more confidence in the correctness of my design? Second, I get tired of hearing people say that VLSI hardware test methodology is far more advanced than software test methodolgy. Software "implementation" is what would be called "design" in a VLSI design system, so software testing is mainly design testing, not implementation testing. Implementation testing would correspond to testing for correct generation of code by the compiler; this needs to be done, but software testing goes much further than that. VLSI design correctness testing seems to be at the same level (I would almost say a little bit behind) software design testing methodology. I hope that I am terribly mistaken. Can anyone give me references for VLSI testing that cover design correctness, not fabrication? Andy "Krazy" Glew aglew@urbana.mcd.mot.com uunet!uiucdcs!mcdurb!aglew Motorola Microcomputer Division, Champaign-Urbana Design Center 1101 E. University, Urbana, Illinois 61801, USA. My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.