Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!lethin
From: lethin@athena.mit.edu (Richard A Lethin)
Newsgroups: comp.arch
Subject: Re: Testability Features
Message-ID: <8496@bloom-beacon.MIT.EDU>
Date: 17 Dec 88 15:31:48 GMT
References: <8453@bloom-beacon.MIT.EDU> <28200252@mcdurb>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: lethin@athena.mit.edu (Richard A Lethin)
Organization: Massachusetts Institute of Technology
Lines: 48

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.


Doesn't that depend on the context?  If you're designing a new computer,
you've got at least three sets of tests to develop:

 "Manufacturing Tests"
 "Validation Tests"
 "Diagnostic Tests"

with different time and coverage constraints.

Most VLSI test methodologies seem geared toward getting the most
coverage with the smallest set of test vectors, primarily because VLSI
test equipment is very expensive -- they're manufacturing tests.

Diagnostics and validation suites are run in a context where time is
free, but coverage has to be TOTAL.  Diagnostics have the additional
constraint that they ought to be able to identify the faulty
component.  Are there some principles people follow when designing
diagnostics and validation tests, or is everything bound to be ad-hoc?

And how do people go about finding design errors anyway?

Would any real-life diagnostic engineers care to comment?