ExtractDoc.tioga
Copyright Ó 1986, 1987 by Xerox Corporation. All rights reversed.
Created by Bertrand Serlet, October 14, 1986 0:29:56 am PDT
Bertrand Serlet, March 11, 1987 7:47:25 pm PST
Extract
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
Extract
Interpreting Pictures
Bertrand Serlet
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.
A semi private interface CoreGeometryBackdoor allows things like output on file. See me if you need to use it ...
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.
SinixD2Intervals and SinixIntervals
These two interfaces, copies of Intervals from CedarChest have been tailored to Sinix, in particular to make them more memory and CPU efficient.
2. 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".
Dealing with CD pins
Approach that does not work: CD symbolic objects are a pain: the interesting information (layer, name) is located in the instance instead of the object. This is obviously orthogonal to the notion of object. To deal with that a serious hack is implemented: a copy of the pin object is made (to avoid shared objects problem), then the interesting stuff (properties of the instance) is copied on the object.
The one that works: Make a cell object containing a pin.
4. Wish List
By priority order
Cleanup RawCMosB
Sisyph dispatch
Use Sinix to do the dispatch instead of cI ← .... Conversion code!
Imports: [JMH]:
Slight problem in extraction of Imports: it is not possible to attach an instance satellite "cI←mumble[]" to an imported object. If you do it, it is just ignored. I have been too lazy to look exactly what is going wrong, but the culprit seems to be the Imports ExtractProc in Sinix.
I've looked a little bit more into the problem. The trick is in Sisyph. The special handling of "cI←..." is done only in ExtractSchematic, and not also in ExtractImport. Net result, it is impossible to set an instance satellite "cI←Mumble.Foo[]" onto an import. Such a thing is sometimes interesting (the example on which the error was detected was using a Logic And gate replicated using Sch.CSeq). An obvious solution from the designer's point of view is to package the import inside a dummy cell, and put the "cI←Mumble.Foo[]" property on this dummy cell.
Nevertheless, this case raises in my mind some doubts as to the correction of the handling of Imports in Sisyph: there are other operations that are performed on cells and not on imports, and it is possible that soem of them are really important. So I believe it would be worthwile to check a little more on the subject.
WireIcons: [JMH]:
Obviously, my model of wire icons (in the generic sense) is completely wrong: I do not see how to use wire icons practically. My problem probably has to do (once again) with name propagation>
Assume I have somewhere in a schematic two flat buses A and B. Each of these buses has a number of interesting subfields. Let's assume they both have an identically named subfield C. If I have wire icons that split the buses into their respective subfields, and if I use both wire icons in the same schematic, then the two C wires are going to be connected (which obviously is NOT what I want...) since connection by name is flat inside a cell...
Hence my current understanding: wire icons carrying names cannot be used. Wire icons are of use only to describe a structure, not to name fields.
Having thought a little bit about the problem, I do not see any reasonable way to do generic (parameterized) WireIcons using the Sisyph wire icon mechanism. The problem is always the same, Sisyph wire icons keep the wire names, resulting in unwanted connections through fusion by name...
Then, I see two solutions:
1. Do exactly as WireIcons currently does, except that the construction of the wire itself must be postponed somewhat. Painful for two reasons:
- the generation of pins must be done twice (or pass dummy wire size parameters when creating the CD object)
- the values giving wire sizing must be evaluated using the Sisyph internal procedures, which is both hacky and heavyweight.
2. Put on each of these icons a special extract proc that will extract the underlying object using the regular Sisyph mechanism, but will prune the public of names before returning. This is at least as hacky as solution 1...
Registration mechanism for commands like "Sisyph & ..."
Error catching. Interpreter error not handled right.
Cleanup in the MenuTable
Extract and Debug command
Parsing satellites
In Sinix
Check for "SPACE-name" when parsing a name.
Highlight by name when pushed does not work
Wait that Push By name is exported
Repair Background Extraction
SinixOps
SinixOps.CDStackToPath fails with ERROR when you select a piece of geometry inside a wire icon. I admit this is quite vicious, but it may nevertheless happen (well, I did fall in that trap...).
In general, wire icons are quite ignored in SinixOps. For example, it's impossible to select a net by selecting a wire icon.
??? Highlight whole icon when trying to highlight an internal => change CoreGeometry ???
Sisyph Contexts
Use only the interpreter to interpret right side of affectations. Conversion code!
CoreGeometry.CreateShell
Problem of duplicates: Still there. Check it when one does a PutPins!