Louis Monier first designed and implemented PatchWork (PW) as a module generator on top of Parquet [Mayo]. It was rewritten so to be independent of Parquet and more integrated into ChipNdale (CD), but also mostly for supporting new functionnalities, as matching of CD pins. The pins are the same ones as the router's. The idea behind automatic stretching governed by pins is to stretch uninteresting and non critical cells, as routing cells.

The Basic primitives in PW are AbutX and AbutY. AbutX with 2 arguments constructs a new CD cell having 2 subcells which are the arguments. The right edge of the first subcell is in contact with the left edge of the second subcell. The edges of an object are defined by the Interest Rectangle of the object, which is not necessarily the limit of the object on the display (for example n-Well does not count for this purpose), and which can be set by user. This allows abuting overlapping objects. The objects are given as ropes which are the CD names in the design, but one can deal directly with CD objects through a client interface and avoid use of this syntactic sugar.

AbutX and AbutY can take up to 8 arguments, and if that is not enough the AbutListX and AbutListY fonctions, which take a list of arguments, can be used. NIL represents a neutral element for the Abut operation. If no argument is given in an AbutX or AbutY, the result is NIL.

If the two objects do not match, i.e. do not have the same size, the smaller one is stretched. The only class of CD objects which is stretchable is wires, presently, and cell stretchability is defined recursively on subcells. It should be easy to specify for other primitive objects whether they are stretchable or not.

A generator program for describing Abutments of cells previously defined in the current design could look like:

It is possible to add pins on a particular cell. PW will only take into account pins which are at the border of the cell, that is pins for which the pinRect is adjacent to the interestRect of the cell on one (and only one) border. When abuting 2 cells which have pins, PW will count the pins, assume there are the same number of them, and match them, possibly by stretching the area between the pins. Two abuted pins must have same size. Their layer is not yet taken in consideration, but this might change in a future version, when we will know what the rules for pin matching should be.

To make an object conditional, stick on it the property $PWCond with any rope as a value. Think of it as a symbolic name for this object. Then use the function Inst which takes three 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, . . .

The conditional objects should nicely replace the overlay operator, avalaible in a previous version.

Some higher lever functions than AbutX and AbutY have been introduced, such as Arrays. The best way to see what is available is to refer to the client interface (PW.mesa). Users must anyway import this interface for writing PW generators. MapFunction tries to generalize the concept of an array, for the case where cell on row i and on column j depends of the values of i and j.

Things like Rotations and symetries also exist, and some utilities for manipulating base 2 log have been written. (And this time, they should work!). The aim of those facilities is to be able to describe fairly complicated structures such as arrays of trees including glue.

The neutral element in Abuting is NIL. That is Abuting a cell with NIL returns the cell itself.

A naming of the instances generated by PW is possible, so that programs like Spinifex (ChipNDale circuit extractor) can use the names. To specify an instance name for a given object, the user must prefix the name of the object by the instance name followed by ":". For example, if "Adder" is the name of the object, and if the instance must be called "Adder[8]" the full name given as parameter to an abut will be "Adder[8]:Adder". For such a named cell, a new anonymous cell is created, with only Adder as a sub-object, but with a $InstanceName property on the application containing the Adder object.

Currently, PW users should bringover [indigo]<chipndale>5.2>Top>PW20.df. PW uses CD 20 and Cedar 5.2.

For using PW, one must be able to create pins, set the interest rectangle of cells, and to start PW menu. One gets the last one by adding in his (or her) UserProfile PW.TIP, a bringovered complement to ChipNDale TIP-table.The UserProfile entry should look like:

PW menu (obtained by Space-U) proposes as a first option to compile and run a user given PW generator program. When a generator is run, the name and the UserProc are registred, and PW creates a new option in PW menu. Clicking any of the recorded generators activates the corresponding UserProc and inserts its result in the design.

Run PW files by typing the command "///
DirectoryWherePWLives/runpw" after starting CD.

Parsing objects to find where it is possible to stretch and stretching them are slow operations. Therefore, there are avoided when necessary, mostly by the mean of sharing via cache mechanism. If the cell does not have to stretch then the program should run faster. All the sharing done by user is kept, as long as possible, so to minimize both space and time. It is so highly recommended to reuse the same objects. The array primitives generate binary trees of shared objects for improving sharing, so do not expect the CD structure to look exactly as your program's structure. Because of the chosen algorithm for low-level abutment primitives, only binary abutments are effectively computed from the n-ary abutments given by the user. That means that the CD structure generated by abutment of n objects, is not always a one level structure.

Four interfaces are available in PW:

During the computation of the layout, PW might create some cells that are not finally included in the resulting object, but which belong to the design. It is the responsability of the user to use the CD Directory menu for deleting unused objects. When this is done, the PW Caches should also be flushed. But perhaps there should be a general CD mechanism for destroying unused objects created by programs. Related to this problem is the naming of PW created objects, which all currently bear the "noname" name.

Time and space efficiency can be highly improved. It is only a matter of doing it ...