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.

The easiest way to decorate is to do an extraction. But that means that an Object must extract as its corresponding CellType. To obtain this effect, the extraction process is faked, and layout attached to a CellType has a fake ExtractProc. This is no conflict with extraction caches, since anyway, an indirection is inserted automaticly when correlating CellType and Object. But most client programs (such as HighLight or Capacitance extractor) do not want to know whether or not the layout has been created with PWCore, and so the extraction should return the real extracted data structure. To find a way out of this apparent contradiction, a new class (PWCore.layoutClass) has been introduced, and the extraction of indirect objects issued from PWCore returns a CellType of such a class. That way clients who want to know about object of that class can (source cellType is stored in the data field of those cellTypes), and the others simply do a recast. The mecanism to do the Recast is a bit tricky, since the correspondence between layout and source Core was sort of trusted until that point. It works by enumerating the interface geometry of the extracted CellType, and trying to match that with the layout decorations of the source CellType. It should be noted that this scheme has the nice property of delaying extraction.

When decorating publics with geometry, several checks are made:

Exported by PWCore itself:

Exported by other packages:

PWCoreInverter.cm:

PWCoreDecoder.cm: