Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!ukc!stc!praxis!gauss!mct
From: mct@praxis.co.uk (Martyn Thomas)
Newsgroups: comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <1379@newton.praxis.co.uk>
Date: Thu, 29-Oct-87 06:51:56 EST
Article-I.D.: newton.1379
Posted: Thu Oct 29 06:51:56 1987
Date-Received: Wed, 4-Nov-87 04:43:50 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3471@sol.ARPA> <590@ihopa.ATT.COM> <5077@utah-cs.UUCP>
Sender: nobody@praxis.co.uk
Reply-To: mct@praxis.co.uk (Martyn Thomas)
Organization: Praxis Systems plc, Bath, UK
Lines: 51
Keywords: formal methods.  design
Summary: Hardware Design Technology is rather Primitive

I don't understand the comparisons which are being made between hardware and
software technology - they seem to be comparing the wrong things.

The advances in hardware technology are advances in *fabrication* technology
mostly.  The feature sizes get smaller, the substrates can be grown with
fewer impurities, the masks can be drawn more accurately.  There are few
useful analogues of this in software.

Software is design, in a pure form.  The *design* technology of hardware, at
the logical, behavioral level rather than the physical place-and-route, is a
long way behind software - mostly because the complexity of most hardware
designs is relatively low.  (This is changing rapidly, as 100K+
gate-equivalent ASICs become more common).  Surely a reasonable comparison
would be:

HARDWARE		SOFTWARE

Schematic capture	Flowcharting
Gate-level design	Assembly-language programming
Most HDLs		FORTRAN
ELLA/VHDL		Modula 2 / ADA		(Don't take this too
						seriously - these
						are not really close enough
						to compare).

LCF/LSM			VDM or Z or CSP		ie formal methods.


The main weakness of this sort of comparison is that the design problems are
different, and that there is no agreed taxonomy of software design
techniques.  The table above is *not* a linear progression from
less-advanced to more-advanced, it is rather an unstructured, pairwise
comparison of different aspects of hardware design technology with rough
software equivalents.

In general, hardware designers are using only limited "structured methods"
(to use a software phrase) and almost no (mathematically) "formal methods".
There are notable exceptions: in the UK, Inmos are using CSP and OCCAM to
prove the correctness of transputer components;  RSRE (UK MoD) are using
LCF/LSM to prove the correctness of VIPER, their formally-verified 32-bit
microprocessor; and increasingly other companies are learning the benefits
of a (more) formal approach to design.  Such methods are in much more
widespread use for software development, and the corresponding research
papers were published about ten years earlier for software.

The hardware designers are catching up fast, though, just in time to merge
their skills with the software engineers' to make a new breed of systems
engineer.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
+44-225-444700.   ...!mcvax!ukc!praxis!mct OR mct%praxis.uucp@ukc.ac.uk