NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lsi/testing/205

Text File | 1992-08-30 | 4.3 KB | 80 lines

Newsgroups: comp.lsi.testing
Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!math.fu-berlin.de!unidui!du9ds3!veit
From: [e-mail] (Holger Veit)
Subject: Re: Testing vs. verification (was: Change this group name?)
References: <[e-mail]> <veit.714837724@du9ds3> <[e-mail]> <[e-mail]>
Date: 31 Aug 92 06:59:27 GMT
Reply-To: [e-mail]
Organization: Uni-Duisburg FB9 Datenverarbeitung
Sender: @unidui.uni-duisburg.de
Message-ID: <veit.715244367@du9ds3>
Lines: 67

In <[e-mail]> [e-mail] (JUSTIN HARLOW) writes:

[...original topic deleted...]
>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?

>Let's see if that stirs the pot....

>JEH
>--
>-------------------------------------------------------------------------
>Justin E. Harlow III        Office:    [e-mail]
>Vox:    919/541-9464        School: [e-mail]
>Fax:     [phone]        Snail:    SRC, PO Box 12053, RTP, NC 27709

I think your last sentence hits the spot. Testing must start with the first
model that is developed, on whatever design level. Finding design flaws after
the chip is in the production line is much more expensive than the additional
efforts of the designer to *validate* his design (Usually, they do not do
*verification*, although the task is often called *design "verification"*).

Testing on lower design levels, even with a 100% yield production line, is
not a replacement for the deisgner's job. From the test patterns you have
at the gate or switch level, it is hard to find out a wrong *function*
(function in the sense "what does this circuit really do, e.g. multiplication",
not "what is the boolean expression of this structure), because the tests are
not made for this. For instance, your circuit may multiply 16x16 bit very nice,
but when there is a some type of carry, there may be an unexpected result
(remember the "single sigma chip" of some well-known company? ;-). You need
special pathological patterns to find out that (which you do not get from
production testing, usually). You may have them, when you still know what the
circuit is performing, and when you know the kind of refinement steps in the
design process.

I think the future of design will be much like the current software design
process: There is a designer who writes a model of the circuit in some
higher level HDL (this does include VHDL, but not Verilog, for instance.
Flame me about that if you think I am wrong!), and puts it into a silicon
compiler (much like the Fortran or C compiler this days, with the exception
that it emits layout, or at least netlists), and the circuit will be correct
compared to the designer's model, and it will be testable (scan path, 1149.*,
BIST or whatever you count as DFT) by default. The compiler, of course, must
be *correct*, which is, with respect to current software compilers, really a
problem. In this environment, not very much will be done with "assembler", i.e.
hand coding or optimization of the output of the compiler, as it is the case
with software today. (There will be "assembler designs" of course, for special
very high speed circuits, for instance, but this won't be the normal situation
like it is still today.

I think the real challenge of the future will be "testing" within the
design process (this includes *formal verification*, although these guys
seem to hate the word "testing" - but I think they have no chance to do this
on (non-structural) higher levels (this is a different topic to discuss)).

Holger

--
|  |   / Holger Veit             | INTERNET: [e-mail]
|__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
|  | /   Dept. of Electr. Eng.   | "No, my programs are not BUGGY, these are
|  |/    Inst. f. Dataprocessing |          just unexpected FEATURES"