PatchWorkDoc.tioga
Copyright Ó 1987, 1988 by Xerox Corporation. All rights reserved.
Created by Bertrand Serlet, October 14, 1985 5:27:22 pm PDT
Bertrand Serlet May 7, 1988 11:29:30 pm PDT
Jean-Marc Frailong January 17, 1988 11:08:12 pm PST
PatchWork
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
PatchWork
Bertrand Serlet
Abstract: PatchWork is the general framework for connecting CD layout to Core. The Core structure either comes from schematics, or by a piece of code. In both cases, this Core data structure is decorated with some properties, which permit the construction of the corresponding layout. When the layout is constructed, publics of cells having layout are decorated with the interface geometry, to allow for routing. An interface check is made at decoration time.
Created by: Bertrand Serlet, Louis Monier
Maintained by: Serlet <Serlet.pa>
Keywords: Comparator, Core, ChipNDale, PatchWork, Extraction, Sinix, Decorations, Interface Geometry
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
Design decisions
Layout generation as we doing in June 85, only based on layout, present some inherent problems. The major one is the obligation for the designer to rename pins, that is to somehow specify that the pin input is rename input[0] in the leftmost cell, input[1] in the second cell, etc... . A related problem is the difficulty to specify connections when routing. The introduction of Core is a first step in solving those problems. But the Core data structure must be linked to the Layout data structure. A simple link from a Core CellType to a CD Object is not enough, because routers have to know the answer to the following question: given a public of a CellType, where is its interface geometry.
These considerations lead us to the following scheme: when layout is associated to some Core CellType, the Core must be decorated, that is every public must be able to enumerate its interface geometry.
Other wanted features were the ability to generate layout in a lazy way, so that layout generation is not required when simulating, for example, and the ability to accept different structures for layout and schematics, knowing that there might be a price to pay for this feature.
There are several ways to implement that scheme. One is to extract and make the isomorphism on the fly. In that case, the user code does not have to decorate publics, but just have to give enough information to the isomorphism. The problem with this approach is double: realizing the isomorphism is a costly operation both in time and in space; the construction of the layout now depends on a non-trivial piece of software. The retained scheme is to avoid all extraction, except at the leaves (Get), and to write for each generator a proc that does the decoration.
Interface invariants
When decorating publics with geometry, several checks are made:
A single geometrical wire can not correspond to more than one atomic public.
Every atomic public must correspond to al least one geometric wire.
Beware of Rotations
Let's call FOO a schematics for which you have layout.
Experiment #1:
Put next to each other ("abut" in X) 2 instances of FOO, by using C-middle click (to make sure nothing is rotated). Put them in a cell, let's say TWOFOO, with the layout atom $AbutX.
Extract and Layout of TWOFOO => you get what you meant.
Experiment #2:
Rotate by 90 degrees TWOFOO itself.
Extract and Layout of TWOFOO, it goes fast (nothing changed!) => you get the reverse of what you meant.
Experiment #3:
Reach inside TWOFOO, select the two instances of FOO, and rotate them by 90 degrees.
Rotate also TWOFOO by 90 degrees.
Everything looks like in experiment #1. Nevertheless PatchWork has to way to figure out how you wanted your instances sorted ...
Extract and Layout of TWOFOO => you get something more or less random.
I would consequently strongly recomment against rotating .sch cells (.icons are OK).
$Abut that might do a better job than $AbutX and $AbutY, but if you rotate things you might still get the reverse of what you wanted.
To Do List
Layout Atom $Abut: Do not sort in place the instances
New Layout Atom $Overlay:
Subcells are extracted with "exports all"
parameters to the layout atom specifies areas in subcell where contacts can be made
parameters to the layout atom specifies where resulting publics should appear
Intelligently adds contacts and AbutZ those.
Put a cache on PatchWork.LayoutInfo if it slows down PWCoreLichen. That would be at the cost of memory, of course!
Notify when fusion by source?
TilingClass: Split between Core and PatchWork?
Context????
If it is really necessary, How about adding this to PatchWork?
ExtractLayoutByName:
PUBLIC
PROC [design:
CD.Design, name:
ROPE]
RETURNS [cell: CoreCreate.CellType] = {
obj: CD.Object = CDDirectory.Fetch[design, name].object;
IF obj=NIL THEN {TerminalIO.PutF["*** Error: ExtractLayoutByName cannot find object '%g' in design '%g'.\n", IO.rope[name], IO.rope[design.name]]; ERROR};
cell ← FromLayoutWithoutPublic[obj];
[] ← CoreOps.SetCellTypeName[cell, Rope.Substr[name, 0, Rope.Length[name]-5]];
};
Testing the package [for maintainers only]
PatchWorkInverter.cm:
Reads a CD file, and registers a PW command called Layout2Inverter that, when executed, should produce a layout made of two inverters in serie. This is the basic test. If that does not work debug!
PatchWorkDecoder.cm:
Tests quite a lot of things, including the Checkpoints. Attention should be paid on the commandTool to the log, to check for correct completion of all commands. Several windows open on the way.