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

Text File | 1992-08-29 | 4.2 KB | 84 lines

Newsgroups: comp.lsi.testing
Path: sparky!uunet!cs.utexas.edu!milano!sirius.mcc.com!praveen
From: [e-mail] (Praveen Vishakantaiah)
Subject: Rise and shine
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: sirius.mcc.com
Organization: Microelectronics and Computer Technology Corp.
Date: Fri, 28 Aug 1992 14:36:21 GMT
Lines: 72

It is very interesting to delve into the reasons why this group is having
problems getting any postings. Here are my two cents worth to motivate
test engineers to generate useful and relevant discussions even in the
midst of unencouraging number of postings in this group.

Holger> I cannot imagine that everyone is interested in design
Holger> (comp.lang.vhdl, comp.lang.verilog, comp.sys.mentor, comp.lsi*),
Holger> but nobody in testing of all the stuff produced.

Well, isn't testing harder than designing ;-). Nobody has proved VLSI
design to be an NP-complete problem (as far as I know)!

Also, if you look at the topics that are discussed in the design groups,
most of them are centered around the usage/bugs of a commercial design
tool or how to obtain free software. There are not as many commercial test
tools or free test software that is as widely used as design software in
order to generate postings in this category.

Allingham> Hopefully, someday all designers will realize that test needs
Allingham> to be considered up front.

This is a very interesting point, but test engineers or project managers
cannot just hope for this to happen:-). I don't think the designers can be
forced to learn the test strategies from somewhere and expect them to
start putting lot of man hours into incorporating test ideas as they
design. The test tools and research should be directed towards automating
the interaction between design and test and I feel that this is happening
now. Test research and tools should not just aim at producing 100% fault
coverage for a particular category of faults.

Harlow> Come on, Janak: you have lots of good things going on at UIUC: how
Harlow> about some timely, controversial postings from you and/or your
Harlow> group?

Although this is a very good and useful suggestion, it is very unlikely
that researchers are ready to discuss their ideas openly due to competitive
reasons. But, we can always discuss published work as well as get feedback
from people in the industry as to the research direction in testing which
would be useful to them.

Harlow> Suppose we had a manufacturing line whose yield was 100%...
Harlow> would we then not need to test products? .........
Harlow> .................
Harlow> More generally speaking, how much of what we call testing is
Harlow> actually a cover for lack of design verification?

The way I would look at this question before answering it, is -
To prove that the yield was 100%, would I use design verification or
testing? I would use testing since formal verification of designs does
not handle manufacturing defects in the strict sense. But again, you can
use information generated during formal verification to potentially obtain
test vectors. I would say, formal verification and testing are two sides
of the same coin. The value is the same, but they look different depending
on which side you want to look at!

Rise and shine, all you testing folks. Spend some time posting useful
discussions pertaining to VLSI testing. Don't work too hard on the testing
problem [I hope my advisor does not see this:-)]. After all, the testing
problem was NP-complete, is NP-complete and will be NP-complete!!

Praveen Vishakantaiah.

------------------------------------------------------------------------------
-- Microelectronics and Computer Technology Corporation, | Ph : [phone]|
-- 3500 W. Balcones Center Drive                         | e-mail :          |
-- Austin, TX 78759.                                     | [e-mail]   |
------------------------------------------------------------------------------
-- ALSO A HARD WORKING MEMBER OF :-)
-- Computer Engineering Research Center,                 | Ph : [phone]|
-- University of Texas, Austin.             e-mail : [e-mail] |
-----------------------------------------------------------------------------