ExtractDoc.tioga
Created by Bertrand Serlet, October 14, 1986 0:29:56 am PDT
Bertrand Serlet, December 13, 1986 2:45:53 pm PST
Extract
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
Extract
Interpreting Pictures
Bertrand Serlet
© Copyright 1986 Xerox Corporation. All rights reversed.
Abstract: Extract is a package grouping the extraction engine [Sinix], the layout extractor and the schematics extractor [Sisyph].
Created by: Bertrand Serlet
Maintained by: Serlet <Serlet.pa>, Frailong <Frailong.pa>, Sindhu <Sindhu.pa>
Keywords: Layout Extractor, Schematics Extractor, Extraction, Technology Independent Extraction, Core, ChipNDale, Schematics, Wire Icons, Icons, Visual Programming, Schematics
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
0. The documentation describing the Schematics editor is in SisyphDoc.tioga
1. Structure of the package
CoreGeometry
CoreGeometry interface describes how geometry is attached to Core data structures. This attachment is mostly independent of the semantic of the picture. Conceptually this interface is below all the others of the package, and just above Core and ChipNDale
Sinix
Sinix defines the extraction engine.
SinixOps
SinixOps exports allows to link the editor and the Core data structure, by exporting functions to highlight or specify a selection. It also allows registration of extraction modes, and registration of CD commands.
Sisyph
Sisyph defines the schematics extractor.
WireIcons
WireIcons provides the designer with a set of icons for dealing with structured wires.
2. User Interface
SPACE-O menu in ChipNDale.
3. Design Considerations
Extracting CMos Wells
Several options are thinkable.
1 - Do not put well in the data structure (the current solution). Ugly, because it means that decorated Core data structures do not contain all the truth. It is very pragmatic since Gismos only use the CD file for now.
2 - Core transistors have 3 terminals. I do not know in that case how to extract p-transistors properly and have the well fused with the current Sinix engine. For example a very unusual place has to be found to put well decorations. I am not even sure if it possible to change the engine to make it coherently work, even if you are ready to have SinixImpl depend on CMosB.
3 - Core transistors have 4 terminals. I do not know in that case how to extract n-transistors properly and have all the substrate of the world fuse together.
4 - Core n-transistors have 3 terminals, Core p-transistors have 4 terminals. No problem to do the extraction and have the right thing happen. It is also probably no problem for the transistor schematics (the 4th pin of p-transistors is connected to the global wire "Vdd").
5 - Core transistors have 4 terminals, and we change CD to also indicate the substrate.
I think that 1 - 4 - 5 are the only possible options. The day we see a significant problem in the current option (1), we should jump to 4 (or maybe 5).
Promoting public
Wires which have some geometry intersecting the border (the interest rect) are promoted public. In the future more wires than just the ones intersecting the border might be promoted. Users should not depend on the fact the only wires promoted public are the ones intersecting the border. It is NOT possible to do the following rule (because it works only one level): If a property $IsPublic (with an atomic value being $TRUE or $FALSE) is attached to a piece of geometry, the promotion is done accordingly to the value of the "boolean".