Script: Part I
1. Introduction (1)
PARC sign, Pinto drives by
(Narrator) What you are about to see is a description of the architecture of a custom integrated circuit design environment.
pan to driveway, VLSI car drives towards camera, zoom on license plate   
(Narrator) This tape reflects the implementation constructed at the Xerox Palo Alto Research Center as available at the beginning of 1988.
Cut to designer's face sitting in front of workstation, want to establish an association of the designer in front of the workstation as meaning examples of the use of the system   
(Louis) Hi, I'm Louis Monier.  My job in this tape is to demonstrate the features of our system and show you how they help me take a chip from specification to layout.  
Turns to programmer sitting at his side in front of whiteboard.  Zoom out to include them both
(Rick) This is Rick Barth.  Throughout this tape he will explain the conceptual models we use and the underlying structure of the system.
Zoom on programmer at whiteboard, want to establish programmer at white board as meaning explanation of underlying system.  Drawing on whiteboard shows program captured as text and pictures, executed to produce annotated net list with tools working off of that.
(Rick) This circle whole picture is a model of our design aid system.  In it we capture the point source description of a design as a mixture of text and pictures.  This source is then point evaluated to create an point annotated net list which is the common data structure used point by all of our tools as their design description.  point Some of the tools use a flattened representation of the circuit to do their job, but most of them work off the hierarchical representation.  
He relaxes and looks at the camera
(Rick) Since we use general purpose text and graphic editors to capture the source there is no need to write a special purpose editor for each type of design information nor must designers learn a new set of manipulation commands for each type.
Cut to designer in front of workstation.
(Louis) Let me outline the contents of the rest of this tape.  
Voice off; fixed slide1 superimposed on a view of a param. sch., rosemary viewer, and a scope underneath on BW screen.
(Louis) First we'll describe how we capture, simulate, and layout simple designs.  
Same with on color screen of an annotation Layout: Mumble, followed by some layout  
(Louis) This will introduce you to the basic concepts of our system.  
Same with a brief clip of an FSM
(Louis) Then we'll cover several higher level descriptions such as finite state machines.  This will demonstrate the extensibility of the system and the legibility of designs captured using it. 
Same with the memory controller wafer
(Louis) Finally we'll wrap up with examples of large circuits built with the system.
2. Design Capture (2.5)
Louis
Close slide viewer and open viewer with /Dragon/Dragon7.0/Top/MemoryController.df MemoryController.dale IOAddressMatch-A.sch specification and an almost completed implementation in it.  Circle specification.  Here is the specification for the block of logic we'll use to demonstrate low level design capture using graphics: a register address decoder.  The address consists of four fields; point the high order bits are unused; point the next field encodes the static device type; point the next the dynamic device number; point and the last the specific register within the chip.  I've begun the design already, let's continue.  Copy 3 input AND gate from Logic, draw the output wire and name it Match.  This simple sequence of actions demonstrates many of the basic concepts of the system.  Let's have Rick explain them.
Rick
Cut to programmer at white board with and3 icon, properties, and schematic.  Have icon wires and picture in different colors.  Louis drew the AND gate by selecting it from a library.  This library has no special status in the system, it is just a particularly handy collection sharedby many designers.  Louis can create his own logic symbols quite simply.  Each logic symbol consists of a visible portion, which indicates its functionality and connection points, and some invisible properties, which tells the interpreter how to convert the graphical item into a net list.  The AND gate has the IconFor property, which indicates a procedure that converts schematics into net lists.  This procedure looks for another property on the icon which names the schematic that describes the implementation of the AND gate.  This schematic contains a number of symbols which we'll return to in a second.
Pan to next section of whiteboard which has wire with name.  First lets look at the wire Louis drew and named.  This introduces the concept of a text satellite.  Our editor has a general notion of attaching text to specific graphical items but it knows nothing about the interpretation of that text.  That job is left to the interpreter which converts pictures into net lists.  By convention the interpreter converts a simple sequence of characters into a name since that is the most frequent use of text.
Pan back to AND schematic.  In this schematic we see five pieces of text.  Four of them are names but the fifth has the back arrow or assignment character in it.  The interpreter recognizes this special character and passes the whole piece of text to a general purpose expression evaluator which assigns the value three to the variable n.  
Pan to another section of whiteboard which has n input and gate with its hidden properties.  If we look at the properties which control the conversion of the n input and gate into a net list we see that instead of the IconFor property this graphical item has a CodeFor property with the value Logic dot And of n.  This is the manner in which graphical pieces of the program describing our circuit can invoke textual pieces of the program written in an ordinary programming language.  In this case we are invoking the And procedure in the Logic package and passing the value of n to it.  The procedure will compute the net list for our 3 input nand gate.  Its possible for the And procedure to invoke the graphical interpreter again so that the program bounces back and forth between text and pictures, using the most natural mode of expression at each level in the hierarchy.  Since it is possible to call an arbitrary procedure to convert a graphical item into a net list this mechanism also provides for extending the system in arbitrary ways.
Pan back to AND schematic.  The last graphical item in this schematic is this large black box which we call a composer.  Its function is to compose simpler wires into more complex collections.  In this case it is composing three atomic wires, or wires which consist of single electrical nodes, into a composite wire which matches the structure of the input wire of the 3 input and gate.  The procedure which translates schematics into net lists makes a single pass over the source, calling the procedures for each graphical item which convert them into wires or cells and on the fly the rectangles of each wire are intersected to establish the connectivity of the cell.  The final result is the production of a single cell in a hierarchy of net lists.
Zoom out to include programmer's face.  We've seen how the 3 input AND gate is converted into a net list representation.  The recursive evaluation of program fragments made out of pictures or text is the fundamental paradigm of this system.  Everything else is embelishments of this idea.  Lets return to the register decoder example.
Louis
Cut to finished schematic on screen.  While you've been gone I've finished drawing this schematic.  Let me point out a few more examples of handling wires and then we can try executing the program represented by this block to produce a net list.  point Over here are examples of wire extractors.  These are graphical items that pick a single wire out of a composition.  point This wire extractor is a range extractor.  Rather than a single wire it selects a set of wires from a composition.  point This little black dot tells our static checker that its ok for the low order 10 bits of this bus not to be connected to anything.
Invoke space-O Sisyph extract.  Let's convert this block into a net list.  Extract and wait cue.  Cut to terminal viewer with IOAddressMatch-A: Record Cell Type at top.  This is a textual representation of the net list.  We rarely look at this so it is a bit hard to read but it is important that you have a clear idea of the result.  Pending delete select IOAddressMatch-A: Record Cell Type.  At the top we see the name of the cell and its type.  A record cell is somewhat similiar to a Pascal record type in that it collects together cells of arbitrary types.  Pending delete select the public wire.  Every cell has a public wire which indicates the wires which must be bound when the cell is instantiated.  We can see the two input wires, DevNum and Address, and the output wire, Match.  Pending delete select the internal wire.   Record cells also have internal wires which are those that are used to wire together the instances inside of it.  Scroll and pending delete select the instances.  Finally we see the instances of subcells such as pending delete select the and3 instance and3 and the binding of its public wires to the internal of the current cell, for example the binding of X which is the output of the and3 cell, to Match, which is the output of the parent cell.
Zoom out to see designer with screen in background.  Lets shift our attention to a block which is more naturally expressed by code.  Zoom into screen.  Louis changes it to focus on the map cache fifo controller and selects the Logic.Driver icon.  This icon represents a buffer which takes a parameter that specifies the number of unit loads which must be driven.  Cut to following cleaned-up code from LogicSimpleImpl.Driver.
Driver: PROC [d: NAT] RETURNS [ct: CellType] = {
SELECT d FROM
<=0 => Error["Please specify strength of driver"];
<=4 => ct _ Extract["driver4.sch"];
<=8 => ct _ Extract["driver8.sch"];
ENDCASE => { -- use constant amplification in 2 stages, correct up to 64
n2: NAT = (d+3)/4; -- second stage: 1 inverter may drive 4, round up
n1: NAT = Real.Round[Real.SqRt[n2]]; -- first stage, sqrt of second stage
ct _ Extract["driver.sch", LIST[["n1", n1], ["n2", n2]]];
};
};

The implementor of the parameterized buffer decided that its implementation need only consider four cases. point The first is when the number of loads was not specified.  In this case the designer is simply given an error message.  point The second and third cases handle 1 to 4 or 5 to 8 loads respectively and they are implemented by simply calling the extractor recursively on schematics which are not parameterized.  The last case uses another parameterized schematic whose parameters are the number of parallel unit inverters for each of the first and second stages.  The first stage uses the square root of the number of inverters in a single second stage.  This sort of case analysis followed by the computation of parameters clearly requires standard programming language control constructs.  Rather than try to invent a graphical language which reimplements these ideas we chose to use an existing language.
Zoom out to designer face.  This completes our description of low level design capture.  It has demonstrated the need for both graphic and textual descriptions and shown how viewing these descriptions as executable programs rather than static net list descriptions allows parameterized designs and allows the system to be easily extended.
3. Simulation (1)
Louis
Zoom in to screen as designer displays cache fifo controller centered on the screen.  The simple net list which we showed you is not the whole story.  Actually it is decorated with properties that link the net list back to the original graphical representation.  We will use simulation as an example application which demonstrates what can be done with these links.
This is the control logic for a fifo.  It has the obvious read counter and write counter implementation plus a counter to keep track of the amount of data in the fifo.  Move oracle cell to center.  This cell is used to test the fifo controller.  It has the fifo controller icon in it, a clock generator, and a special cell called an oracle.  An oracle is just a cell which emulates an integrated circuit tester.  
Show FifoCtrl.oracle.  This is the file which provides a simple test of the fifo controller.  When fed with these inputs point on the left, the circuit under test should produce the expected outputs point on the right.  
Cut back to oracle cell.  Lets convert this schematic into a net list and make a simulation.  Invoke space F Rosemary Create Simulation.  Wait cue. 
Cut to simulation control panel.  Here is the simulation control panel.  It mostly does the obvious thing you would expect a simulation control panel to do so lets just push Start Test push start test, wait for evals to hit 5, interrupt it push Interrupt and then demonstrate the capability to do "source level" debugging.  
Cut to pushed in fifo control schematic.  V left click on NewRqst.  I'll invoke a key sequence which means post the selected wire on the oscilloscope display.  
Cut to sillyscope display with selection viewer above it.  We can see by cycle 5 that new request has made only one transition.  But there is another viewer that was created by posting this wire.  Let's have Rick tell us about it.
Rick
Cut to Rick in front of whiteboard.  There is diagram similiar to the first one he used to give the overall system model on the board with a DAG with at least one node that has indegree greater than one.  The source also has multiple pointers to nodes in the DAG which have only one in-pointer.  Well just as the simple action of dropping down an and gate took us into a discussion that exposed some complex functionality, the simple action of posting a wire also invokes a complicated mechanism.  When a particular rectangle is selected the corresponding electrical node in the flattened representation of the circuit is potentially ambiguous.  point The cell in the net list DAG (is that a well-known term, Rick?) may be instantiated more than once.  point Or the net list cell may only be instantiated once but the same graphical piece of program generated multiple cells.  relax In either case some additional information is required to disambiguate the choice.  Disambiguation is the purpose of the additional viewer which popped up when Louis posted his wire.
Fundamentally disambiguation means choosing a unique path from the root cell of a DAG to some subcell.  point  For instance this cell is only used once in this design; it has a single path from the root cell to it.  point This cell is used twice in this design; it has this path point; and this path point.  Choosing a unique path amounts to picking a particular out-pointer from the root cell.  Cut to viewer on display.  In the viewer each cell in which the designer might have to pick an out-pointer is given a line.  point  Each line contains the name of the cell and the name of each instance, or out-pointer, in the cell.  click an instance The designer selects a particular instance by clicking on its name.
Zoom out to face shot.  An alternative method to pick a specific path through the hierarchy is to follow the graphical hierarchy.  This mechanism could completely eliminate the need for the disambiguation viewer if every instance had a graphical instance.  Of course this is not so, consider having to draw a schematic instance for every instance of a ram; that simply is not reasonable;  it is easier for the designer to give the index of the ram bit in the manner that the disambiguation viewer presents it.
This is probably as clear as mud.  Even though this may be difficult to conceptualize it turns out to be easy to use.  
Well that's enough about simulation and the relationship between the design source and the flattened design representation.  The other major use of the common data structure is layout generation.
4. Layout (2)
Cut to top-level icon of BIC on the color monitor.
(Louis)  Ideally, the layout generation of a circuit for which one has a logical description should proceed as follows...
Add satellite "Layout: Grok it!", click Generate Layout in menu.
(Louis) ... simply ask the DA system ...
Cut to blinking eye icon through the magnifier.
(Louis) ... and in the blink of an eye ...
Cut to finished layout on screen with simplification set to show all.
(Louis) ... one should get layout.
Cut to designer in front of large plots of memory controller and map cache on the wall.  
(Louis) Many systems offer this capability by restricting to a very specific design style, such as gate arrays or standard cells.  If a circuit does not completely fit in this style, it must be designed with an entirely different set of tools.  Even with systems which allow some extensibility, the design suffers from lack of uniformity. For example, a system might allow standard cells with a few imported macro blocks; if these blocks are designed using a different set of tools, then they are most likely imported as low level pieces of layout; and so it is unlikely that the same set of analysis tools, such as behavioural simulators, can be applied to them.  
Louis points to the various components on the plots
What we have here is an architecture to express all styles of layout; hand packed tilings for RAMs, more automatically and slightly less packed tilings for data paths, standard cells for random logic, and pad frame construction.
Cut to color monitor.
(Louis) For circuits with very simple structures, our system is pretty close to the ideal.  
Louis shows "Layout: SCRemote" in DEX design
If one only needs to place and route a block of standard cells ...  
Louis shows "Layout: PadFrame" in same design
... and surround it with a set of pads, then the layout can be generated with minimum effort, simply by adding these annotations to the existing description.
Cut to small plot from Mt Fuji.
(Louis) The resulting layout is similar to that produced by any decent standard cell system.  However, the general layout mechanism we use is similar, and only requires adding annotations to the circuit description.
Cut to white board which has DAG with Get tags at the bottom, a SC tag collecting some of them with some intervening levels of hierarchy, an Abut tag collecting others, and a Route tag at the top.  
Cut to color monitor: BIC, delay.sch, part of the extract cache is loaded.  
(Louis) Leaf cells offer the simplest situation.  We see here point the schematic for a simple cell, and point the corresponding hand-drawn layout.  The schematic carries point an annotation which invokes the Get operator.  When I apply the layout generator to this cell click and SPACE-F, the schematic is converted into an annotated netlist extract cue, and then the recursive layout process begins. This layout operator fetches the layout cell point, extracts it, checks both interfaces for conformance, and move result layout to color screen returns the hand-drawn cell as the result.
Color monitor: BIC, tap4.sch.
(Louis) It is very common for full-custom parts to be assembled from cells which are carefully pitch-matched in order to abut.  This example point shows four identical cells abutted with a different cell on the right.  Notice that the order of the cells is implied by the schematics; the layout generator has access to the schematic representation as a picture, and can parse it to infer a lot of information; the schematic is thus used as a graphical language.  
The "Abut" layout generator first asks for the layout point of these two cell types; then assembles the five instances to form the resulting layout.  Generate Layout.
Color monitor: layout of tap4.
An interface check is performed to guarantee that the connections made by abutment are the same as the connections specified by the schematic.  This check is performed by every layout operator.  A complete check that the schematic and the layout are identical is performed after layout generation is completed.
Other layout operators in this class perform geometrical transformations and assemble tilings and sequences.  They are generally used to construct dense full-custom blocks.  
Color monitor: MapCache, pushed into Inner.sch.
(Louis) Higher-level operators offer more freedom of assembly.  magnifier on Layout: Channel Here a channel router is used to assemble two blocks: a block of standard cells on the right and a stack of three rams on the left.
The set of hints found in the schematic includes point the orientation of the channel, the order of cells and the wires appearing at the exits.  Options specified by text embedded in the schematic include point the minimum width for a net, and the materials used for routing.  These schematic annotations drive the layout generation.  Generate layout.
Color monitor: MapCachelayout, entire view, then zoom on the crowded part of the channel.
(Louis) Notice how the use of structured wires in the schematics simplifies the description compared to the layout.
Color monitor: BIC, DBusControl.sch; use magnifier to show Layout annotation.
(Louis) Another operator constructs a block of standard cells.  The schematics must be expressed in terms of elements corresponding to a library of standard cells.  Only the top-level schematic carries the layout annotation point to Layout: StandardCells.  The side and position of wires exiting the layout can be controlled from the schematics.  Textually specified options include the number of rows and which algorithm to use for placement, in this case a placer on a remote machine.  Generate layout.
Color monitor: BICLayout, SC block.
(Louis) This is the layout for this small block. During layout, the structure is simply flattened until leaves carrying a layout annotation are reached: the general layout procedure is called to return the layout of each leaf.  
Color monitor: SCLibCMOSB, area around or3.
(Louis) These leaf-cells are usually part of a library, like this one.  The library can be shared among designers, or private.  Leaf-cells can also be obtained by abutting other cells or generated by program: since standard cells are nothing special to the system, adding a new cell is a benign operation.  This illustrates the extensibility of the system and the uniformity of the layout generation.
Color monitor: BIC, BIC.sch; use magnifier to show Layout annotation.
(Louis) The last step in the physical design of a circuit is the pad routing.  This schematics features the core of the circuit, and the four sides of its padframe.  As everywhere else in our system, zoom to text the layout is specified by adding annotations to the top-level schematic.  The direction of materials, the width of the power buses and the position of the core of the circuit within the pad frame are all textual options.
Color monitor: BICLayout, zoom to a dense routing area showing powr busses.  
(Louis) The assembly generates the layout of the four sides and the inner part of the circuit, then calls a router which uses no less than 20 different routing areas in order to guarantee a good power routing.  
Cut to Face shot.  
(Louis) As we just saw, generating the layout of a circuit is a batch operation, in the sense that the final layout is produced by running a program on the source.  This layout is never edited by hand.  If the result is unsatisfactory, the source, either schematics, code, or layout of small cells, is updated, and the generation started all over.  Great confidence in the final mask results from
Cut to Slide5.
the very compact and legible source
the use of well-debugged generators 
interface checks during the layout generation
the read-only nature of the final mask.
5. Transition (0.25)
Face shot.  
(Rick) This completes the first part of this tape.  So far, we have introduced all of our system's basic concepts.  
Superimpose slide4.
(Rick) These include 
combination of graphical and textual specification,
capture of designs as programs which produce net-lists rather than directly capturing net-lists,
use of a common net-list data structure to drive the tools,
and use of the logical specification to drive layout generators.  
Face shot.  
(Rick) In the second part we go over higher level design abstractions such as data paths.  Some of these abstractions were added to the system long after its foundation had solidified and so demonstrate the robustness of the system architecture.
Script: Part II
1. Sequence (1)
Louis
Turns to screen.  Follow him and zoom into screen.  It has a tristate driver with a 4 bit bus runing up to it and another at its output.  The first abstraction we will consider is the sequence cell.  Suppose that I have a 4 bit tristate bus.  I could individually draw the extractors that pick out each of the 4 bits from each bus and draw 4 tristate drivers.  It would be much simpler to draw a single tristate driver and then indicate that I want 4 of them.  Draw the four wires and put sequencing slashes on the input and output.  In our system this is done by drawing wires for each of the connections on the tristate driver and then graphically indicating which of them are to form a bus by putting this sequencing slash on them.  The wires that do not have these marks are assumed to all be connected to a single electrical node.  Drag in a finished cell with Seq in it and border mode on.  Here is the finished cell with the special marker that indicates that this cell represents a sequence of the base cell.  Rick can give us a more detailed model of what is happening here.
Rick
Cut to Rick at whiteboard with series of boxes and single box above to represent the base cell.  What we are doing is inventing a terse graphical language for an operation which is common in custom integrated circuit logic design, that of repeating a cell in a linear sequence.  point This is a sequence of some point arbitrary cell.  It could have a wire in the direction parallel to the axis of repetition draw such a wire all the way through the cell or it could have wires perpendicular to the axis draw a pin out of the top and bottom.  When a wire is parallel all of the wires in the subcells are connected together in the sequence cell draw this.  When a wire is perpendicular the collection of wires in the sequence cell form a bus draw this.  relax More complicated variations of this idea are possible.  Sketch each example.  Each cell might tap the nth wire of a bus draw 4 horizontal wires above the cells and draw a wire down to each cell or wires might flow from one cell to another in a stitch fashion, possibly flowing through some intermediate cells.  relax Treating all of these cases so that the picture unambiguously describes the intended semantics has proven to be a difficult job.  Of course all of the facilities which are available graphically also have a textual expression as well.
Pan to a DAG with a node that is connected by a dotted line horizontally to another.  In addition to reducing the size of the design description capturing higher level abstractions allows tools to work more efficiently.  A sequence cell is not only a design capture abstraction, point it is also has a better representation in the common data structure.  Since the designer has explicitly declared that the cell is to be repeated it is simple to use the Array layout operator to construct the layout.  However explicit recognition of the sequence cell may not be any advantage for many tools.  Such tools should not have to know of the existence of this abstraction; otherwise each additional abstraction would require modification of all of the tools.  To avoid this we have introduced the notion of procedural conversion of abstractions like a sequence cell into a simpler representation that all tools are required to handle.  point Whenever a tool encounters a cell of a type not know to the tool it invokes this procedure and then trys again with the simpler representation.  With this mechanism every tool in the system only has to know about a few base types and the rest are interpreted only if the tool needs to deal with that abstraction.

2. Finite State Machine (1)
Louis
Cut to designer in front of terminal.  Lets turn to a mode of description which is substantially further away from physical design, that of finite state machines.  Zoom into screen which has CompDecTopDown.dale ArrayArbiter.  This machine is used to arbitrate access to a RAM array between two competing state machines.  The most notable thing about this picture is that anybody who has studied the classical finite state machine literature is instantly able to interpret it.  The states are point these octagons; each state has point a name; beneath the states are point the outputs; these arrows are point the transitions and are labeled point with the transition expressions.
Put /Dragon/Dragon7.0/SmallCache>Code>SmaleCachePmCodeFSMImpl.mesa up.  Scroll to IfState[HMReturn2PC].  Zoom on only that state.  Another classical description of a finite state machine, this time textual instead of graphical, is that of a microcoded machine.  In this case the outputs are associated with the transitions rather than the states.  Select IfState[HMReturn2PC]. Here we see the declaration of a state.  Select all of the If statements.  It is followed by 4 transitions which are a function of 2 variables, NonFBTIP and TimeOut.  Select AddOut.  Here are the outputs associated with a transition.  Select JmpState.  And here is the definition of the next state.
Put ArrayArbiter back on screen.  Lets run a simulation of the graphical state machine.  space F Rosemary Create Simulation; push Start Test.  Push into oracle cell; select outputs and plot them.  In this simulation we can see the state machine running.  However, we have to infer the state of the machine from its outputs.  That's no problem for this state machine, where each state is uniquely identified by the outputs, but that is not always the case.  Another extensible mechanism in our system is the recording of the state of abstract blocks.  In the case of a state machine the abstract state of the cell is the current state name.  select state machine icon; space F Rosemary Plot Cell State;  We can see here that the state names are plotted.  This is far easier then inferring the state from the outputs and eliminates any ambiguity.
Zoom out to face shot.  If the logical description of this arbitration state machine were embedded in a standard cell layout the designer has nothing more to do.  An algorithm synthesizes the feedback and output equations from this specification; converts the equations into a multilevel logic network, including the feedback latches; and casts all the logic in terms of standard cells.  The physical design is then handled by the standard cell system.  In many cases the equations are best implemented as a PLA structure and so that method of physical implementation is available as well.
Many significant advantages accrue from high level design capture.  Tedious, error prone work is dramatically reduced.  The design is more easily understood by both the original designer and others.  The choice of target technologies is wider; for instance the same state machine could be implemented as a PLA on a custom chip, or programmed into a set of PALs.  Simulation can take advantage of the higher level of abstraction to go faster, thus increasing the amount of design verification which can be performed.
3. Data Path (0.75)
Rick
Cut to whiteboard.  It has rows of functional blocks, 4 columns wide, labeled with functions such as Xor, tristate driver, latch, and.  There are horizontal wires going all the way through and vertical wires sharing tracks which are repeated in each column.  The final example of design description that we'll cover is the data path.  We assume that a data path has a point regular two dimensional layout with rows of functional elements of various heights.  The purpose of the data path operator is to wire these low level components together in a more efficient manner than is possible with an ordinary standard cell system.  The data path operator relies on a set of predesigned cells just as a standard cell system does.  These cells are carefully designed so that power distribution can be easily accomplished.  In his schematic the designer supplies the point cell placement information, the point order of wires in the vertical channels, and the point places where horizontal channels occur to supply connections to the data path along its height, or to permute the wiring from the cell above to the cell below.  relax When multiple data paths have lots of bit level interconnection the designer can specify that the data paths be interleaved at the bit level, eliminating the routing of buses as wide as each data path, thus converting an order n squared layout problem into an order n problem.  Functional blocks may be synthesized algorithmically so that functions such as multiplexors which vary greatly from one data path to another can be generated from a terse graphical description.  Lets look at a piece of a datapath to make this discussion more concrete.
Louis
Cut to screen with /Dragon/Dragon7.0/IFUSch/IFUSch.dale on it pushed into PCFormBot with focus on PCAltPipe1A including one blue box on top and two below.  This is a portion of a 32 bit data path taken from an instruction fetch unit.  point Each vertical wire you see represents 32 wires.  point Each horizontal wire represents a single wire which controls all 32 bits of the data path.  point at 3rd channel from left Vertical channels can be occupied by more than one wire.  Each blue or green box represents a function that occupies a row in the data path.  Here we see three types of functions; point tristate driver, point multiplexor and point latch.  Cut to layout of this portion of the data path.  Here is the resulting layout.  We see the 6 vertical channels, the set of tristate drivers and latches, along with the synthesized multiplexor.
Zoom out to face shot.  The datapath operator is a good example of requiring a designer to specify only the minimal amount necessary to optimize his design adequately.  Since the system is easily extended the designer can find out half way through a design that some particular piece of logic requires tighter manual control over its optimization and he can fix it within the framework of the system rather than having to start over.
4. Example Circuits (0.5)
Louis, sitting in front of the probe station. Scope on, lights flashing, low light level, circuit visible on video display ... 2001 decor.
(Louis) Even though our system was developed in a research environment, it has produced more than toy examples over the past three years. In fact, it has been stress tested with a variety of large circuits which are at the state-of-the-art in complexity.
Show EU on wafer and highlight the blocks the areas as designer talk.
(Louis) The earliest circuits formed a 5-MIPS processor on two chips. The datapath chip shows a datapath including a large register file, two PLAs, and a small block of standard cells.  
Same with IFU on wafer, highlight the datapath and both control blocks.
(Louis) The control section of the processor is made of a datapath and a variety of PLAs.  Both circuits were designed while the system was still evolving, and make heavy use of the simpler layout operators.
Same with BIC on wafer: highlight the SC block, a slice, and then all slices.
(Louis) In addition to a strange aspect ratio, this interface circuit has a standard cell block and a full-custom part made of high-power cells, hand-placed, then routed and duplicated.  The padframe router described earlier was used here for the first time.  
Same with Clock toy on wafer; highlight the circuit.
(Louis) This simple test circuit was generated in a similiar fashion.  Its complete design, up to layout generation, was accomplished in a matter of hours.
Same with wafers of AFS; highlight the circuit.
(Louis) Several circuits were designed which use only one type of layout generator.  This frequency synthesizer is a large interleaved datapath.  
Same with wafers of Arbiter and Dynabus Exerciser.
(Louis) These two cicuits are made solely from standard cells, making their layout generation close to trivial.  
Louis in front of a plot of the mapcache; he points as he talks.
(Louis) A remarkable aspect of the system is the size of the source for the circuits: here is a 170,000 transistors circuit, layed out with standard cells and standard memory blocks.  
Louis now points to a plot of the schematics; then camera zooms on portions such as the FSM, a portion of the pad frame, wire icons.
(Louis) This circuit is entirely described by this page of annotated schematics; the implementation took one man-month.
Back to wafer shot of IO Bridge then plot of Display Controller
(Louis) The minimal use of designer manpower calls for a design using only library elements, such as standard cells, memories, and pads.  This circuits are built this way.
Wafer shot of Memory Controller; highlight the data path.
(Louis) When sufficient performance cannot be obtained this way, more time must be spent to add more specific blocks, such as a datapath. 
Plots of Testarossa and array portion of the Cache.
(Louis) Finally, in order to benefit fully from a new technology, a few circuits will always need full-custom parts, such as this tester chip or this cache.
5. Review (0.5)
Zoom out to include both designer and programmer in face shot.
(Rick) This completes the tour through our system.  In this tape we emphasized the explanation of basic principles rather than a complete review of all the tools available.  Timing analysis, design rule checking, LVS, and circuit simulation are examples of tools which we did not have time to present. 
What we have shown in this tape is that the capture of a design as a program composed of both textual and graphical elements is simple and effective.  
Both textual and graphical modes of expression are needed because some parts of a design, generally the declarative parts, are most naturally described with pictures while others are most naturally described algorithmically.   It's important to have clear descriptions to prevent mistakes from being made during the initial design and to communicate the design to people other than the original designer. 
Cut to slide3, which matches what he says
(Rick) Designs are expressed as programs which compute net lists rather than captured directly as net lists in order to 
provide an extensible system,
radically reduce the number of logic library primitives required,
reuse designs in different contexts,
postpone sizing decisions,
and debug minimal size implementations followed by algorithmic scaleup to full size versions.
Face shot
(Rick) The common design data structure with links to the original source vastly simplifies the implementation of the system and leads to a consistent user interface which is easy to use.  It reduced the number of lines of code in the design automation system enormously.
Finally the architecture for layout generation utilizes the logical source in a natural manner thereby eliminating redundant design description.
All of these features help people be more productive.  They reduce the number of people and the time required to design integrated circuits.  This is specially important at PARC where circuit design is done according to the tall and thin designer paradigm: one designer is responsible for the complete conception of the circuit, including description, validation, layout and test.
This concludes our presentation.  Thank you for your attention.
6. Credits (0.25)
Slide2 superimposed on fixed frame of group picture.
(Narrator) Many people in the PARC Computer Science Laboratory contributed to the evolution of this set of tools over the past three years, especially the designers in the Dragon project.  Rapid software development was made possible by the Cedar programming environment.
Switch to Xerox logo cut from some Xerox ad spinning up and filling frame.  
(Narrator) The research environment that made this project possible was provided by the Xerox corporation.

---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 
Slide1
Basic System
Design Capture
Simulation
Layout Generation
Some Extensions
Sequence
Finite State Machines
Data paths
Example Circuits
Review
Slide2
Slide3
provide an extensible system,
radically reduce the number of logic library primitives required,
reuse designs in different contexts,
postpone sizing decisions,
and debug minimal size implementations followed by algorithmic scaleup to full size versions.
Slide4
combination of graphical and textual specification,
capture of designs as programs which produce net-lists rather than directly capturing net-lists,
use of a common net-list data structure to drive the tools,
use of the logical specification to drive layout generators,
Slide5
compact and legible source
well-debugged generators 
interface checks
read-only final mask

Conventions and Such
Organization
The tape should be constructed so that it fits naturally into two parts each lasting 20 to 25 minutes.  We will have 5 to 10 minutes for setup and questions in each of the first two half hours.  The last half hour will be devoted to questions.  If there are no questions we will have some 35mm slides prepared that rehash what we said in the papers.  That talk should be planned for 20 minutes.  If there are no questions then we'll just break early.
Script Conventions
Script is in normal text, visual descriptions are bold and precede the voice over.
Cues
Extract: shot of Sisyph log (specific to situation)
Wait: coffee cup leaves table full, comes back empty
Joke: Blinking eye while saying ".. happens in the blink of an eye."
Display Synchronization
Fix the display before shooting
_ TerminalFace.SetFieldRate[lfPhillips60hz]
Fix it back
_ TerminalFace.SetFieldRate[normalLF]
Tape Abstract
The key idea we are trying to get across is that a design is captured as a mixed textual and pictorial program which is then executed to produce an annotated net list which is used to drive tools such as a simulator or a layout generator.  The layout generator is able to take its specification from the program, including both the pictorial and textual parts.
Why?
Text and pictures to express things in a natural manner
Program to gain benefits of parameterization
extensibility
radical reduction of the number of logical library primitives required
reuse of design in different contexts,
postpone sizing decisions
debug minimal size designs
Annotated net list to provide common design description for tools and thus a common user interface.
Layout by decorating logical source to eliminate redundant design description
Fixups
Change d to loads.
Scalability, e.g. a big RAM is made about as fast as a small one.
Instead of talking head, illustrate with clips of editing, Mint script, stretchy moves, sch of fsm, large areas of routing, arrays, sc, dp, ...
Paste Buffer
Rick:
Table of comparisons between picture capture and netlist capture.
	Editors
Picture	Schematic
Draw rectangle	Create net
	Connect port
Copy cell	Create Nand
We capture a design by drawing a picture rather than editing a netlist. The picture is then translated, or "extracted", to produce a netlist.  This process uses a general evaluation mechanism.  During this evaluation, expressions are evaluated, but also arbitrary programs can be called which return numerical expressions or net-lists.  Such programs can in turn require the extraction of a particular picture: we thus alternate easily between the graphical and programming domains.  This allows us to use the most suitable representation.
Wires as DAG?
Finish non-parametrized part: a name, a gate and a few wires  This looks like a conventionnal schematics entry tools, but it is not.  For one thing, I am editing a picture, and not a netlist.
Louis:
It is important to perform design capture in a natural form.  Buses can be given arbitrary structure with the following icons point Draws buses, extractors, composers
Cut to Logic on BW display, zoom on the library part  The basic elements have been pulled out of this library, which includes point basic gates and flip flops; point larger blocks like registers, counters, and rams; and a point collection of multiplexors.  
The basic gates correspond to a fixed net-list, such as point the 2-input, 3-input and 4-input nand gate.  However, there are parameterized gates, such as point this n-input nand gate.  This gate can be used by associating an expression attach satellite n_7 .  During the extraction, this expression is evaluated and the result stored into an interpreter context where it can be used by the program creating the corresponding net-list.  
The input wire of the nand gate becomes a 7-wire bus. show range extractors, use param expression
Actually, all annotations can be parameters instead of simple values use Don's search and substitute to change 47 to addressWidth
Cut to fifo controller from map cache Here is another example of a parameterization which helps describing a cell in a natural way: the load of this buffer is passed to a program show cleaned-up code for LogicSimpleImpl.Driver on BW display which decides of its structure according to the value.  Notice that this code in turn extracts cells from this part of the library show in Logic.  These cells point to driver4.sch and driver8.sch are used for small buffers.  These cells point to driver.sch are used for larger buffers.  
Notice that these schematics are themselves parameterized, thus closing the loop from sch. to code to sch.  This shows that there is no conceptual difference between a schematics produced by a designer, and a library element.  In fact, within our system, many pieces have started as specific circuits and ended up as part of a library.
Back to Logic The use of parameterization has reduced the size of our library.  This library was sufficient design a dozen large chips.
Make icon for fifo control explain icon, interface; now we want to simulate
Fancy Features
X left click to show push into implementation, even if in library
Pan to two 3 wire composers with a single common wire and a drawing of the resulting DAG structure.  Here is a slightly more complicated example where two composite wires share a single atomic wire.  This illustrates that our model of wires must be a directed acyclic graph rather than a simple tree structure.
The placement can either be done locally or by a remote placer.

ÂDACTape.tioga
Louis Monier March 25, 1988 9:59:35 am PST
Barth, March 23, 1988 5:22:46 pm PST
(Rick) Layout generation proceeds by a recursive process of bottom-up construction using the net-list DAG.  Certain levels in the description carry an annotation which specifies the layout operator to be applied there.  Each layout operator gathers its parameters from the schematic, recursively ensures that each child has a layout, and then composes its own layout.  Let's examine a few of the layout operators currently accessible through our system.
R. Barth	G. Beretta	L. Bland	D. Curry
J.-M. Frailong	J. Gasbarro	C. Jacobi	C. Le Cocq
E. McCreight	L. Monier	B. Preas	B. Serlet
P. Sindhu	M. Spreitzer
�Ê
›˜™
Icode™*K™$—
head˜˜Ibodyš
Ðiw˜Mš
œ|˜|Mš�GÏw˜IMš
œŠ
˜Š
Mš�²
ž˜´
Mš
ϩ
˜©
Mš
�^˜^Mš
œ‰
˜‰
Mš�yž�‰
˜…Mš
œÏiœ<ŸœXŸœŸœ<Ÿœ3ŸœŽ
˜âMš
�"˜"Mš
ϙ
˜ô
Mš
�(˜(Mš
œ?˜?Mš�hž˜vMš
œS˜SMš�Sž
˜TMš
œF˜FMš
� ˜ Mš
œÂ
˜Â
Mš
�%˜%Mš
œT˜T—š
œ˜š
œ˜MšŸ¸
œŸœ¸
Ÿœ!Ÿœ0Ÿœ%ŸœfŸ
ÏsŸ;œu˜¶—˜MšŸ}œ œ± œß
 œV˜ýMšŸ;œ¾˜ùMšŸ Ÿœº˜ÔMšŸ[œº˜•MšŸ ŸœÕ˜ïMšŸ&œ œˆ˜Î—˜MšŸ$œÓ
ŸœvŸœuŸœ‚
˜óMšŸ œ+Ÿ_œ¥
Ÿ9œ«
Ÿ'œ½
Ÿ)œtŸ/œ3Ÿ'œÃ
˜€
MšŸ5œPŸqœvŸ5Ðin
Ÿ˜©šÏnœÏkœ£œ£œ˜0š£œ£˜
Kš
œ2˜2Kš
œ#˜#Kš
œ#˜#š£œÏc;˜HKšœ£œ¤1˜DKšœ£œ¤$˜IKšœ£œ˜9Kš
œ˜——K˜K˜—MšœkŸœxŸœ§˜”MšŸœ¸˜Ò——˜˜MšŸVœ—˜íMšœ¨
Ÿœ×
˜�MšŸœbŸœIŸœ˜Ü
MšŸœDŸ6˜”
MšŸ"œ—
Ÿ(œŸœF˜ÄMšŸDœ\˜ 
MšŸ;œ«
˜æ
—˜Mš
Ÿ¨œÞŸœž"œ&ŸœwŸœ·
˜©MšœhŸœkŸœ:ŸœŸœ[ŸœdŸœgŸœD˜ÊMšŸœç˜ýMš
œw˜wMš
œÃ
˜Ã
——˜
Iblockš
�2˜2Nš
œy˜yNš
�@˜@Nš
œ(˜(Nš
�/˜/Nš
œ*˜*Nš
�E˜ENš
œ"˜"Nš�Xž
˜YNš
œ™˜™Nš
Ÿ3˜3Nš
ϊ
˜ä
Nš
�˜Nš
œ\˜\Nš
Ÿ,˜,Nš
œD˜DNš
Ÿ-˜-Nš
œ�
˜�
Nš�ž
˜Nš
œ×
˜×
Nš�Ä
ž˜Æ
Nš
œÅ™ÅNš�Jž˜LNšœ>Ÿœ&Ÿœ=Ÿœ_Ÿœ7Ÿœ]Ÿœ;Ÿ"œ+˜ÌNš�ž
˜Nšœ�
Ÿœ½˜ÏNšœ6Ÿœ[Ÿœ
˜¦
Nš�ž
˜Nš
œ¶˜¶Nš
Ϩ
˜®
Nš
�/˜/Nšœ@Ÿœ„
˜à
Nšœ1Ÿœ—
Ÿœ}Ÿ˜ßNš�ž�ž
˜YNš
œs˜sNš�ž�(˜MNšœà
Ÿœê
Ÿ˜øNš�"ž
˜#Nš
ϊ
˜ä
Nš�ž
�ž
˜+Nš
œ�˜�Nš�ž	�*˜ENšœÈ
ŸœÞ
˜²Nš�Jž˜MNš
œÓ
˜Ó
Nš
ž˜Nš
œŒ˜Œš
�˜Mš
œ#˜#Mš
œ$˜$Mš
œ-˜-Mš
œ'˜'——˜Nš�
ž˜Nš
œt˜tNš
�˜š
œ˜Nš
œ3˜3Nš
œ`˜`Nš
œ;˜;Nšœ?Ÿ
œ˜B—Nš�
ž˜Nš
ϛ
˜õ
——˜˜˜MšŸ2œŸTœÅŸGœ±Ÿ:œ¼
˜»—˜MšŸaœ¶
ŸœŸœ[Ÿ.œ1Ÿ$œhŸ	œXŸ	œŸœ9Ÿœ,ŸIœvŸœê
˜œ
MšŸTœÃ
Ÿœ†Ÿœ¹˜à	M˜——˜˜MšŸ%œŸ>œŠŸœ Ÿœ ŸœŸœ!Ÿœ!˜¦Mš
Ÿƒ
œÙ
Ÿœ)Ÿ œ^Ÿœ4Ÿœ-˜£MšŸ œ9Ÿjœ�Ÿ
ϡ
Ÿ>œ�
˜ÌMšŸœ·˜ÍM˜ƒ——˜˜MšŸ�œoŸœçŸœ!Ÿœ2Ÿœ¢
Ÿœ£˜ˆ
—˜MšŸœ
œOŸœ2Ÿœ]Ÿœ
Ÿœµ
ŸœŸœŸœ	Ÿ1œ�
˜ÒMšŸœ›˜±——š
œ˜Mš
žŠ
˜Š
Mš
œþ
˜þ
Mš�ž0˜EMš
ϼ
˜º
Mš�ž
�
ž�˜GMš
œÏ
˜Ï
Mš�ž	�,˜MMš
œ„˜„Mš�ž	�
˜4Mš
œ›
˜›
Mš�ž	�
˜/Mšœ�
Ÿ˜’
Mš
�2˜2MšœnŸ˜qMš
ž@˜@Mš
œ¸
˜¸
Mš
ž„
˜„
Mš
œw˜wMš
�?˜?Mš
œ«
˜«
Mš�!ž	�˜9Mš
œŠ
˜Š
Mš�ž�˜3Mš
œœ
˜œ
—š
œ˜Mš
�>˜>Mš
œ®˜®Mš
œ—
˜—
Mš
œ•˜•Mš
�)˜)š
œx˜xIitem˜O˜AO˜$O˜O˜]—Mš
�	˜	Mš
œ�˜�Mš
œ�
˜�
M˜üM˜?—š
œ˜Mš
ž4˜4Mš
œ�˜�Mš
�L˜LMš
œj˜j——M˜M˜n˜š
œ˜Oš
œ˜Oš
œ
˜
Oš
œ˜—š
œ˜Oš
œ˜Oš
œ˜Oš
œ
˜
—Oš
œ˜Oš
œ˜—˜Itable1™%P™/P™)P™—˜O˜O˜AO˜$O˜O˜]—˜Oš
œ3˜3Oš
œ`˜`Oš
œ;˜;Oš
œ<˜<—˜Oš
Ïx˜Oš
¥˜Oš
¥˜Oš
¥˜—J˜˜˜M˜Â—L˜M˜R˜O˜3O˜4O˜D—˜˜J˜+—˜J˜%——˜
M˜è˜O˜7˜,O˜
O˜FO˜&O˜O˜—O˜cO˜M——˜O˜O˜AO˜�
——˜˜š
ŸA˜AItableš
Ÿ˜QšÐizŸ
¦	˜Qš
Ÿ˜Qš
Ÿ
˜
Qš
Ÿ˜—Jš
œ›˜›J˜
—JšŸ<œƒ
˜¿
š
œ˜Jšœ~Ÿœ#˜¦
JšŸ6œHŸœŸœ9Ÿœ˜�Jšœ8Ÿœ^ŸœMŸœ´
˜µJšœ6Ÿ+˜aJšœDŸ=˜�
JšŸ%œŽ
Ÿ(¡
Ÿœ„
Ÿ
œŸ$œ*Ÿœ˜�Jš
œÏ˜ÏJšŸ
œz˜‡
JšŸœ1˜K—L˜J˜AMšŸeœÑ
˜¶Mš
œ?˜?J˜——…—¶ôÄQ