I beleive that large chips should be designed by programs. More precisely, cells should be drawn with a good graphic editor (ChipNDale), and assembled by program, with no hand-edition of program-generated pieces.

Let me give you several good reasons to do so.

PatchWork was designed with the idea of helping you with the regular parts of a chip, i.e. datapath, control, arrays, . . . It needs in addition a placer/router, on which other people are now working, in order to be completely general.

PatchWork is based on a few simple ideas. First, it provides novice users with a way of defining chips by program which is simple, safe and efficient. Simple means that it is not necessary to know the inside of CD in order to generate geometry. Safe means that there will be no nasty surprise, like pieces of design which "are in there", but don't plot, or worse, don't appear in the CIF (it happened to me!). Efficient means that the few primitives provided go a long way, and allow you to describe a lot of chips by program.

Another key idea of PW is to be well-integrated with other tools. This is obtained by sharing as many concepts as possible with the existing basic tool, ChipNDale. Object, Instance, Design, Pin, orientation, ... , are exactly the same as CD, and this saves a lot of unnecessary code and prevents a lot of confusion.

To start, get PW from

and read in PWExample.dale (cmos technology). As you read this document, you can refer to cells in this design which illustrate the text.

It is necessary to have used CD before using PW, so please refer to the basic documentation and give yourself the time to play with CD. I assume that you know the meaning of the words: design, object, instance, directory, cell, pin, and that you know how to start CD, draw objects, save a design and read it again.

It is also a good idea to read the interface PW.mesa, soon after this document. You will notice that almost all functions use a "design" first argument. This design is the target design, i.e. the one in which the assembled objects will end up. In interactive mode, it is provided by PW as the argument of the UserProc.

What I am describing here is a methodology which the early users of PW have adopted pretty instinctively, so give it a try.

To start, you need a set of cells. The easiest way is to draw them interactively with CD. Have a separate design for that, like MyChipCellLibrary.dale. You might use several designs if you prefer. The point is that you don't want to mix program-generated objects with hand-drawn ones. Reasons:

So, one (or several) precious "source designs", or "library cells", and a scratch-pad design.

The basic primitive in PW is abuting two objects, and comes in two flavors, AbutX and AbutY.

Let's consider AbutX[a, b], where a and b are ChipNDale objects in a design. PW will abut a and b so that the right edge of the InterestRect of a matches the left edge of the InterestRect of b. If the heights of the objects differ, PW comes to a halt, and returns the two culprits so that you can figure out by yourself why they don't match. Respectively, for an AbutY, the widths should match. The resulting object is not a cell, but an Abut. You don't really need to understand the difference, since as soon as you do something to an abut —like push into it— it turns into a cell (never feed it after midnight).

AbutX and AbutY can take up to 6 arguments, and if that is not enough, the AbutListX and AbutListY functions take a list of arguments. Omnipresent NIL is the neutral element for the Abut operation. If no argument is given in an AbutX or AbutY, the result is NIL. AbutCheck (not implemented yet) performs an additionnal check that all pins along the abuting edge match in position, size, layer and name.

Higher-lever functions have been introduced, such as Arrays. The best way to see what is available is to refer to the client interface (PW.mesa). We find ArrayX, ArrayY, Array and MapFunctionX, MapFunctionY, MapFunction. MapFunction tries to generalize the concept of an array, for the case where the cell on row i and on column j is a function of i and j. Very useful for making a decoder for example.

The following functions create an instance of the object and encase it in a new cell. The idea is that PW produces new objects, not instances, and that instanceName or orientation are properties of an instance, not of an object. We find FlipX (changes the sign on the X axis, i.e. symmetry wrt the vertical axis), FlipY, Rot90 (counter-clockwise), Rot180, Rot270, and InstanceName.

Here is a typical user program, and you'll find the corresponding cells in the example:

[Conditional object as they are present major problems. Avoid using them BS August 3, 1986 8:07:53 pm PDT]

The first step in the direction of parametrized cells: conditional objects. It is very often the case that several cells will be identical, except for a tiny geometrical difference: a contact will be missing, a wire will be shorter, . . . The idea is to draw only one cell, and create by program a family of cells which relate to it, by simply taking out some of the geometry, which thus becomes conditional. Of course you don't want to refer to an object by saying "the poly contact at coords [12, 45]", because this will be a pain to trace through edits, so we use names: to make an instance conditional, stick on it the property $PWCond with any rope as a value. Think of it as a symbolic name for this instance. Then use the function Inst which takes four arguments:

Let's say the cell Decoder contains two objects named (with the property $PWCond) "OptionalContact" and "FatWire", among other things. If in the Patchwork program you use "Decoder", you get the complete cell with these two objects, just like usual. If you use

you get a copy of the cell with neither objects, and if you use

then "FatWire" will be present, but not "OptionalContact". Of course, several objects can carry the same name, and thus disappear always simultaneously. Any object can thus be made conditional: rectangle, contact, transistor, cell, . . .

Sometimes, abutment of hand-drawn cells is not sufficient to describe a piece of a chip. You might want a more powerful way of parametrizing a cell, down to the point where you want to create a cell from scratch. I assume then that you are a grown-up, and can read the interface. Briefly, let's go through an example, in the right order. You create a new cell, insert an object obj1, and finish properly:

Two important fine points: coordinate systems and repositioning.

ChipNDale has many coordinate systems: one for the design, one for each cell, one associated with the InterestRect, . . . Don't ask! Now, PW tries to make your life a little easy: unless it is explicitely mentionned, all coordinates refer to the [0, 0] of the InterestRect. For example, in the example above, the semantic is:

Repositioning: whenever you create a new cell, or modify its content, CD has to reposition it, and propagates the changes throughout the design. The function IncludeInDirectory does it too, but it is important to remember that it should be called last, when the cell is in its final form. If you modify the content of an object and don't reposition it, it will display funny, plot funny, and worst of all, fabricate funny, so don't forget.

In Cedar 6.1, bringover

Now start Chipndale, and issue the command

to start PatchWork. Create a new CD design, and click inside its viewer. P-Middle calls the generator menu. At this point, you need a set of cells and a Cedar program. You can copy and edit the example of code shown previously. If you have compiled and ran your program, the menu should show "Run YourStuff Generator", where "YourStuff" is the name you registered with ChipNDale: click it to start. After some time (usually pretty short), an instance of the object should appear in the viewer.