Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!think!bloom-beacon!mit-eddie!bbn!rochester!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: comp.software-eng
Subject: Re: H/W vs. S/W
Message-ID: <280@ritcv.UUCP>
Date: 19 Mar 88 00:03:44 GMT
References: <2586@Shasta.STANFORD.EDU> <1396@ur-tut.UUCP> <3867@bloom-beacon.MIT.EDU>
Reply-To: mjl@ritcv.UUCP (Michael Lutz)
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 23

In article <3867@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>With S/W, the "turnaround" time is typically compile time.  A programmer
>can make changes and almost immediately see what the difference are.
>
>With H/W, the "turnaround" time is the time it takes to make a new chip, which
>is *much* longer.
>
>So... the hardware people have to be very certain that there work is correct
>because iterations through the design/test/modify loop are much longer and 
>more expensive.  This forces them to check their work very carefully.  

There are, of course, ways to address this, such as the Cleanroom Software
approach at IBM (described in several papers by Harlan Mills).  In this
approach, semi-forl methods of program proofs and rigorous reviews replace
the compile/debug cycle.  Testing is only done to predict product reliability;
it's considered a failure to have many errors found in testing.  And it's
only at test time that the code gets *compiled* at all.

Mike Lutz
rochester!ritcv!mjl
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA