The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Christian Dreier via TUHS <tuhs@tuhs.org>
To: tuhs@tuhs.org
Subject: [TUHS] Re: Circuit design tool mentioned in AT&T Unix promotion
Date: Sun, 19 Feb 2023 22:31:58 +0100	[thread overview]
Message-ID: <d88dc90e-279f-36f7-093c-bb2aa91530d4@googlemail.com> (raw)
In-Reply-To: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com>

I got an answer from Steve Johnson himself. He didn't keep up with the 
TUHS mailing list and is not sure whether he could post here currently 
-- so he asked me to post his answer here.

He wrote an outline of what he remembers. Without some archived data 
from 40 years ago, this might be all, which could be known about this 
"L-Gen" tool.

Thank you, Steve!


Steve Johnson's answer >>>>>

The Bell Labs Mead Conway Course

Steve Johnson

In the early 1980’s, semiconductor technology was a very hot topic.  At 
that time I was a department head and recruited at CalTech, where Carver 
Mead taught a class that allowed students to design nMOS chips and get 
them fabricated and then test the hardware.  My boss, Sandy Fraser, had 
a lot of hardware experience, and many of us were curious to see what 
this new chip technology could make possible.  After some negotiation, 
Carver agreed to visit the labs for 6 weeks and teach the class.  Sandy 
pulled some strings and negotiated some aid from the AT&T chip makers. 
We would design a wafer with multiple different designs, and then the 
wafer would be sliced apart and each of us would get a few (3-5) chips 
they designed.

Having written the portable C compiler, and also one of the more 
enthusiastic supporters of this visit, I found myself “nominated” to 
write the software to support the design.  We had just got our first VAX 
computer, which seemed to be powerful enough to support a dozen or so 
designers.  I had about six weeks to throw together the software to 
support the chip design class.

To our surprise, there were roughly 30 people who signed up for the 
class.  So, what kind of design should we provide.

The Mead/Conway “method” involved laying out the chip by hand following 
certain design rules.  There were three kinds of wires: red, green, and 
black.  The red and green wires were special: if a red wire crossed over 
a green wire, it made a transistor.  The black wires carried the power 
and some of the data signals.  In addition to the transistors, there 
were Vias – these allowed signals to cross between the red, green and 
black layers.  The whole circuit was included in a “box” made up of 
pads, where the circuit would be connected to the pins of the fabricated 
chip.

There were also design rules.  Transistors cannot be to close to other 
transistors or vias.  To make logic circuits we needed to provide 
voltage and ground using the black wires.  The whole circuit was 
designed on graph paper.

It quickly became clear to me that the design language should, as much 
as possible, hide the design rules so we could concentrate on the 
geometry.  So the design language allowed you to define transistors and 
vias, and connect the wires to one of the four sides of the transistors 
or vias or pads.  I don’t remember the exact syntax, but the design was 
a series of statements.  Some statements defined names of transistors or 
vias or pads, without saying how they were connected.  Then the heart of 
the language was doing the interconnections.  The active elements had 
connection points U, D, L or R  (for up, down, left, right).  If V was a 
via, we might connect it to a transistor T by writing something like
	T.RU = V.D

Which connected the right port of the transistor T with a wire that goes 
to the right and then up, and is connected to the down port of the via. 
Then the program would determine from the design rules how long the wire 
needed to go to the right and then upwards to hit V.

The design language also allowed you to design functional blocks like 
adders and treat them the same way as the builtin basic elements.

The design compiler became an exercise in finding the smallest layout 
that satisfies all the design rules.  There were a variety of quirks 
that needed to be handled, especially regarding power and ground.

When transcribing a design with a few hundred wires it was remarkably 
easy to confuse left and right or up and down when describing the wire. 
This led to a cycle that could not be satisfied.  To salvage something, 
hopefully, when there was a cycle, I deleted one of the constraints in 
the cycle, and tried again.  Unfortunately, if the cycle had, say, 6 
constraints I had less than a 20% chance of removing the bad one.  So a 
large design with a single flaw could collapse into a murky mudball of 
elements with occasional wires and transistors sticking out of it.  It 
was most demoralizing.

To add to the problems, when our VAX was delivered, apparently at some 
point something rolled over one of the cables, creating an intermittent 
fault.  So for the first two weeks the VAX would take a very long time 
to get through all the designs.  A frantic week’s work allowed me to 
package the design rule checker to draw a map of part of the circuit in 
24x80 characters.  You could zoom in to the site of the design rule 
error with a few keystrokes.  It quickly became the preferred way to 
design.  I remember giving a talk at MIT about the language and the 
design rule checker that was well received, but I doubt that it was 
recorded.

We produced, I think, 5 multiproject chips, roughly 2 a year.  A sixth 
try was a failure: I had changed the checker to describe the elements by 
its center rather than the edges, which sped up the checker quite a bit. 
  But when the design went to fab, the guy who usually checked the 
design for sanity was unavailable and the flaw was missed.

Some very interesting chips were produced in the course.  Dave Ditzel 
implemented some ideas in silicon that later showed up in the AT&T 
Hobbit chip.  There were also several network chips.   For the third 
chip, I implemented a real silicon compiler.  You could write a logic 
expression and it would compile it and produce output that could be used 
in the design.  I generated a circuit that could take 16 binary inputs 
and produce the signals to drive five numerical outputs—a binary to 
decimal converter.  The logic was complicated, but the program laid it 
out and the chip worked.

There were two reasons why the Silicon impulse petered out, in my 
opinion.   One was, we didn’t have a good way to install the chips into 
any of the computers running Unix.  And, if we had managed to do it, the 
chip would have to have some notion of which process it should respond 
to — it got complicated…

For me personally, I realized that the next step would be to dive into 
the physics of the system, and I had just accepted a transfer to the 
AT&T computer company spinoff, managing the language products for System 
V.   This included the portable C compiler, the first commercial C++ 
compiler, Ada, FORTRAN and Pascal, and a debugger that worked with all 
of these, so I had my hands full with that.

<<<<<


Am 10.02.23 um 06:36 schrieb Christian Dreier:
> Hello there,
> 
> I recently watched an old Unix promotion video by AT&T on YouTube (AT&T 
> Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and 
> they mention a design tool for integrated circuits (apparently named 
> L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284).
> 
> Part of this software is a language implemented with YACC that appears 
> to describe the behavior of digital logic, like modern hardware 
> description languages, i.e. Verilog and VHDL.
> 
> Does anyone have information about this, in particular:
> - Documentation
> - Which projects were realized with this?
> - Source code, if possible
> 
> I asked this question on retrocomputing.stackexchange.com (see 
> https://retrocomputing.stackexchange.com/q/26301/26615) but so far there 
> is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned 
> and there is some good information about it but it has another syntax 
> (as shown in the video vs. the documentation about CDL) and apparently 
> another purpose (description of board wiring vs. logic behavior).
> 
> Best regards,
> Christian

      parent reply	other threads:[~2023-02-19 21:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  5:36 [TUHS] " Christian Dreier via TUHS
2023-02-10 12:56 ` [TUHS] " Douglas McIlroy
2023-02-10 13:20   ` Clem Cole
2023-02-10 15:03     ` Clem Cole
2023-02-10 15:22       ` Heinz Lycklama
2023-02-10 19:08       ` Lawrence Stewart
2023-02-11  8:06   ` Christian Dreier via TUHS
2023-02-13  9:22 ` Christian Dreier via TUHS
2023-02-19 21:31 ` Christian Dreier via TUHS [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d88dc90e-279f-36f7-093c-bb2aa91530d4@googlemail.com \
    --to=tuhs@tuhs.org \
    --cc=flipper.x3r@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).