Newsgroups: alt.os.multics,alt.sys.pdp10,alt.folklore.computers,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!vsocci
From: vsocci@netcom.com (Vance Socci)
Subject: Re: Retro-Computing!
Message-ID: <vsocciD6Kvsp.Kyy@netcom.com>
Sender: vsocci@netcom17.netcom.com
Organization: Vcc Technical Services
X-Newsreader: News Xpress Version 1.0 Beta #2.1
References: <D6JBr5.Hu1@bonkers.taronga.com> <3lu1a3$qpj@ns0.emc.com> <vsocciD6KqrL.CG2@netcom.com> <3lupvb$qpj@ns0.emc.com>
Date: Wed, 5 Apr 1995 17:08:34 GMT
Lines: 105

What hath I wrought?
walton@emc.com (John Walton) wrote:
>walton@emc.com (John Walton) wrote:

>Cool is not the point. It's accuracy in design representation. Whenever
>an abstraction comes between the designer and the end product, the more
>work you have to do to ensure that the abstraction generated what you implied.

True statement, but you are assuming that a graphical representation would
come between the designer and the end product more than your text ASIC
language. This is the point we are arguging.

Since the subsets of the gates in an ASIC used for the various structures don't
even have to be related (e.g. using one section for a serial to parallel converter
and one section for a register file) what is the advantage of having the corresponding
descriptions in any particular order in a text file?

Suppose you wanted to connect two constructs with a higher-level construct. Can't
you imagine a way to use graphics to describe this better than some crufty
set of nested boolean statements?

>>For example, if you are used to doing hierarchical schematics, you could imagine
>>that the architecture level of the device you were designing could actually
>>be the language that compiled down into the ASIC programming mask.
>
>I'm completely baffled by this statement for two reasons:
>1) I don't understand the example.
>2) The subset of the language that the synthesis tool processes
>   allows precise macro inference, which is the goal.

Perhaps if I weren't limited to describing this in the very same text that so many
people think is superior, I would be more successful!

Let's say you were designing a CPU. Draw a box with the proper inputs and outputs
labeled, and grouped according to what they are objective-ly. That's your first level.
Click on the big box.

Now we see the next level: the CPU has a micro-engine, a paging translator, and
a memory interface. Look at all the control signals and datapath wires going between
the elements. A lot of the wires are more than 1 bit wide. Look; I can click on the
wires and see a detail of what they are and see timing diagrams for the rules on
how they are used.

Click on the CPU. Now I see the internal elements of the CPU. Shifters, adders, registers,
microengine parts. I can see the interconnections between the elements, and view or set
information about them.

Eventually I can click on down to the gate level. Perhaps on the way we'll encounter
one of your ASIC text language pages, if you like.

No one is going to tell me that they don't have pictures of a sort in their head when they
design a significantly large piece of hardware. Block diagrams, timing diagrams, etc.
Why not use graphical computers to formally communicate this valuable information
to the other designers and maintainers of the system? There are many advantages to such
systems: first, you can do logic simulations at multiple levels, since you have system
descriptions available at multiple levels. Second, the information is better organized. No more
off-page-connectors on schematics. Third, you could have automated design tools
figure out which ASICs held which elements in multiple ASIC designs, and pick the optimal
set of ASIC sizes to use. At the design level that corresponds to ASICs, you could just
write the code for the particular structure you needed in that section of the grand design.

I'm old enough to remember hardware designers having their drawings done *by hand*.
I can easily imagine myself arguing with those hardware designers about how using
computers to input the schematics would advance the state of the art. Some of them
would probably tell me what a stupid idea it was, since pencil and paper worked just
fine. And who needs to draw up block diagrams of the device? Would take too much
extra drafting time. Let 'em figure it out from the schematic.

>[snip]
>>
>>			But it would be even better to just draw an n-bit
>>register or something in a graphical language and have that compile down
>>to the ASIC programming configuration.
>
>What could be simpler than "always @ (posedge clock) a[7:0] <= b[7:0];"
>I can say it at work, I can say it home, I can say it anywhere!
>You cannot say the same for any other design entry "language", they cost
>money, they are platform specific, and they are _buggier_ than my editor.

Many text editors are platform specific too.

Your example is too simple to illustrate the advantages that graphical interfaces
can bring. Do you go so far as to advocate the elimination of all graphical
CAD packages in favor of strictly linear text descriptions of hardware designs?
What do the hardware guys you work with use to design the boards your
ASICs plug into?

Granted that advanced technology doesn't always pay off for small tasks where it
is easy to use just about any method to generate a solution. For very complex
things, though, such as large software or hardware designs, graphical CAD techniques
have a lot to offer.
>
>
>



- Vance

/=======================================\
|    Vance Socci   vsocci@netcom.com	|
| "The worst secrets are those we keep	|
|   from ourselves . . ."		|
| "I am not a number; I am a free man!	|
\=======================================/
