PipalExtractDoc.tioga
Copyright Ó 1986, 1987, 1988 by Xerox Corporation. All rights reversed.
Created by Bertrand Serlet, October 14, 1986 0:29:56 am PDT
Bertrand Serlet, April 25, 1988 11:06:13 pm PDT
Jean-Marc Frailong January 4, 1988 6:07:24 pm PST
PipalExtract
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
PipalExtract
Interpreting Pipal Pictures
Bertrand Serlet
Abstract: PipalExtract is a package grouping the extraction engine [PipalSinix], the layout extractor and the schematics extractor [PipalSisyph]. It also defines the important notion of decorated Core [PipalCore].
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, Geometry Decorations
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
The documentation describing the Schematics editor is in SisyphDoc.tioga
Changes for designs
TestSisyph -> TestPipalSisyph:
globalNames ← List ["WeirdGlobal", "Gnd", "Vdd"]
commented globalNames ← (map cedar '("WeirdGlobal" "Gnd" "Vdd"))
enum: CD.Orientation[mirrorX]
commented
gndprop2: $bar
gndprop2: 'bar
gndprop1: $foo
gndprop1: 'foo
atom: $Atom
atom: 'Atom
bool: TRUE
bool: #t
OBSOLETE AFTER THIS POINT
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.
InstanceTable
This interface, adapted from Intervals in CedarChest has been tailored to Sinix, in particular to be memory and CPU efficient.
SchCDUtils
Provides functions to make icons objects.
Things to do waiting for CoreCDUser
SinixOps: Highlight of both the schematics and the corresponding layout
SinixOps: Registration mechanism for commands like "Sisyph & ..."
Waiting for RB's CoreCDUser.
ExtractAnd [design, allowMultiple, PROC [result, props], incontext: BOOL]
Error catching. Interpreter error not handled right.
Cleanup in the MenuTable. Rename Sequence icon in sequence cell (in the menu)
Extract and Debug command
18-Feb-87 ross.pa Extracting Schematics
Date: 18 Feb 87 13:14:00 PST
From: ross.pa
Subject: Extracting Schematics
To: Frailong, Serlet
cc: ross
Reply-To: ross
I was told that one of you is the right person to contact about a problem with SinixOps having to do with schematic extraction. The problem arises if I wish to extract a cell which is not at the top level (it is nested one or more levels down). If I push into a cell and select a subcell as the schematic to extract, the extractor seems to think that the cell to extract is the top level cell (not the one which is selected). Is there anything that can be done about this problem or am I destined to put all cells which I wish to extract at the top level?

  -Mark
18-Feb-87 Frailong.pa SinixOps and Core commands
Date: 18 Feb 87 14:03:13 PST
From: Frailong.pa
Subject: SinixOps and Core commands
To: Serlet
cc: Frailong
Reply-To: Frailong
This is a follow-up to Mark Ross' message about context or non-context extraction in commands. It appears that we need to fix things up a bit.
I think we need two flavors of Core designator procs:
- In context: extract the cell and all its ascendants, return the CoreFlat wires/instances. This is the good one for Highlight
- Out of context: extract the cell just by itself, not taking in account its CD environment. Probably the right thing for commands like Static, Layout
The implementation of the two flavors is quite obvious. I don't know whether this should be 2 different procs or just a flag passed to the current proc. In any case, we also need to do a pass over all current commands to do the right thing for everyone: the current implementations use random choices...
By the way, I don't know if you ever noticed that in 24, in the MakeIcon menu, the entry for building an icon from a schematic appears twice. Could you correct that?
Jean-Marc
2-Mar-87 ross.pa ExtractAndLayout
Date: 2 Mar 87 09:54:52 PST
From: ross.pa
Subject: ExtractAndLayout
To: Serlet
cc: ross
Reply-To: ross
There seems to be a bug in the use of the "Extract and Layout". Unlike its cousin of Sysiph extract, it seems to want to pop out of any cell that it is in and extract this top level cell. The vanilla extract simply extracts the selected cell (regardless of whether you are pushed into a cell).
Impact - annoying but not severe.

  -Mark
SinixOps: Highlight by name when pushed does not work
Wait that Push By name is exported
SinixOps: pdif and the like
When highlighting, both wires should be highlighted
SinixOps: Bug Compilo?
Code in SinixOpsImpl used to provoke a Compiler bug. Check if it is still there. [BS+JMF]
SinixOps varia
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 ???
Wish List for CoreGeometry and Sinix
Sinix: Parsing satellites and expressions
In Sinix?
SinixOps: Repair Background Extraction
Sinix: Extract Overlaid Cells
New ExtractProc that promotes all the internals to publics.
SinixCMosB.Touch
TouchProc May be it should be in the decoration!
pwellCont (resp. nwellCont) and pdif (resp. ndif) should not touch!
CoreGeometry.CreateShell
Problem of duplicates: Still there? Check it when one does a PutPins!
Wish List for Sisyph
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".
Sisyph one day
3 properties: $ConnectedByname, $PromoteToPublic, $PropagateName
Values: $Once=$Always>$SubOnce=$SubAlways>NIL>SUBNIL
SisyphImpl: Contexts
It is possible to displace the CopyTV from the creation of contexts to the evaluation. That would mean much faster copy of contexts.
Sisyph: Imports
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 seem of them are really important. So I believe it would be worthwhile to check a little more on the subject. [JMF]
Stack of design: [JMF]
Separately, Louis and I think we need to make some modification to the context carried around imports. The problem came because there is a new icon around that provides a testProc described in a file (the Oracle, c.f. LogicRosemaryImpl for more details). The problem is, where do we look for the parameter file? Conceptually, the file should be looked for in the directory from which the initial design was read. The trick is that when the Oracle icon is extracted, the context does not carry any information regarding the source design from which the import was called. Hence the idea of keeping in the context a history of the designs through which the extraction process has been (remember that it's possible through CDEnvironment.GetWorkingDirectory to recover the directory from which a design was read). The idea I currently have is to keep track of the list of designs (or the list of design directories) through the Sisyph.Create function, which is the only one that creates new contexts: if there is a previous context, then Store in the new context "designHistory←CONS[newDesign, designHistory from previous context] else Store in the new context either NIL or newDesign according to whether we want the current design to be part of the list. You may of course replace the designs by directory names, thus getting a search path (probably in the wrong order...).
Sisyph: publics
Check that all publics are named.
Sisyph: Color
28-Feb-87 sindhu.pa Re: Sisyph modification
Date: 28 Feb 87 21:04:25 PST
From: sindhu.pa
Subject: Re: Sisyph modification
In-reply-to: "Jacobi's message of Fri, 27 Feb 87 11:12:24 PST"
To: Jacobi
cc: Serlet, Sindhu
Christian,
I must have been in outer space when you mentioned this to me, because I don't remember having a discussion about colors in schematics.
My general feeling is as follows. Color is nice as long as we are able to have color layers that are exclusively for schematics. However, I find the use of poly, metal etc. in schematics quite dangerous, especially since people tend to put layout and schematics in the same design.
In addition, I believe we need to think about how color can be usefully employed in schematics before providing it. In particular we need to think what the touch semantics ought to be. If we get these semantics "wrong", and we let people have color, it will be incredibly hard to fix it afterwards. Also, without some tasteful guidelines about the use of color, I can lots of different styles developing, with no one able to easily understand any one else's schematics.

  - Pradeep -
Design Considerations
Caching
In order to have Lichen work it is important that ct1#ct2 <=> PWCore.Layout[ct1]#PWCore.Layout[ct2]; but also that layout1#layout2 <=> Sinix.Extract[layout1]#Sinix.Extract[layout2]. Therefore the Object cache must be used for all objects that return a cell type. For a counterexample, if there is no object caching on the extraction of rotated objects, two extractions of the same rotated object (with may be different properties) might return different cellTypes.
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.
Copying of properties in wire icons
  5-May-87 Frailong.pa Static in Cedar 7.0
Date: 5 May 87 16:53:39 PDT
From: Frailong.pa
Subject: Static in Cedar 7.0
To: Serlet, Barth
cc: Frailong
Reply-To: Frailong
Static does not work properly in Cedar 7: the unconnected icon from the Logic library does not propagate the $UnconnectedOK property onto the attached wire. I believe the implementation problem (all inside Sisyph) are as follows:
1. Extracting a wire icon returns copies of the underlying wires but do not copy properties. Thus, a property set directly on a wire is lost when extracting a wire icon.
2. ExtractNamedWireIcon cautiously set the result wire properties to be the CoreProps from the context, except that it does not do it if the wire is atomic (the special hack to avoid the CheckAndDecorate forgets about properties). This means that setting the property as an object property of the wire icon does not work either for the unconnected icon since it is an atomic wire.
The fact that properties of wires do not carry across wire icons should not be too troublesome (I believe this was already the case in 6.1). Copying properties together with the wires is a bit dangerous (implicit data sharing). Not copying the wires when they are obtained from code is an alternative if code clients are to be trusted to provide `unique' wires. Whatever the choice, the Sisyph documentation should state what happens to wire properties in wire icons.
I see 3 solutions to the specific problem of the unconected icon:
- solve the general problem of properties copying
- correct the bug in ExtractNamedWireIcon regarding CoreProps for atomic wires and setup the unconnected icon with an explicit Core property.
- create inside Static a special Sinix.ExtractProc that returns a wire pre-decorated with the UnconnectedOK property.
Jean-Marc
Slowness of extraction
After some anonymous denunciations, the inspector Gadget strikes again ...
I once again spied schematics extraction on the real life design you gave me (I had not seriously done that in 7.0 yet).
Spying the CPU time does not yield any interesting action item: the time is spend all over the code, and there is nothing worth optimizing.
Spying the Allocations gives the following results:
1 - Copying the contexts:      19.2%
2 - Allocations in the interpreter:    16.2%
3 - Various internal SymTab/RefTab allocations: 16%
4 - CDSatellites.GetSatelliteRopes:    9.8%
5 - Creation of wires in Sinix or Sisyph:   7.7%
6 - CoreProperties.PutProp:     5.3%
It is easy to fight some of 1 by avoiding copying of contexts when not necessary (for extracting wires for example). It cannot be done by reallocating the same tables all over again, since they are still pointed to by the cache. Estimate: 2 man days for a 10% gain.
3 is hard to fight because there is at least 10 different places that allocate/deallocate HashTables, such as in CoreOps. Estimate: 1 afternoon for a few % gain, 1 man day for a 10% gain. The gain would be for all DA, not only for schematics extraction.
I can not do much for the rest.
My conclusion is: there is nothing I can do that is really worth the effort (although I might some day I want to lose time remedy to 1 or 3). And, unless something changes dramatically in the whole system, that was the last time I spied extraction ...
Life is hard.
Varia
10-Apr-87 To: Barth, Sindh... Sisyph proposal
Date: 10 Apr 87 01:51:32 PDT
From: serlet.pa
Subject: Sisyph proposal
To: Barth, Sindhu, Frailong
cc: DAToolsImplementors^.pa
Reply-To: serlet
I had to seriously dig into the inner of Sisyph for this jump (due to differences in the interpreter), and so I thought this is a time as good as any other to do things we've been talking about for months. I would not like, for example, to revisit the Sisyph Context issue one more time in the future.
1. Sisyph Contexts
One of the change of the interpreter has been to have a list of SymTab (instead of just one) as context. We need in Sisyph to test (fast) to context for equality. If a Sisyph context was a list of SymTab we would still have to create a SymTab in order to do the comparison. So we might as well use a unique SymTab for Sisyph context.
We could avoid copying of Contexts if TVs were not modified in place. But that means that we will have to copy TVs at interpretation time, and we would have to keep a Copy of each context in the Sinix cache. I doubt it is worth the effort.
It should be possible to avoid copy of contexts when extracting a leaf cell (wire), noted Jean-Marc. Once the other improvements are done I'll try to estimate if it is still worth the code.
2. Names
It is well known that Sisyph instance names are screwed. The reason of the mess is the presence in the Context of a variable "name" that holds the name, while there is another variable "coreProps" (or "coreInstProps" if we are evaluating an instance satellite/expression) that holds it. I got rid of that (although a still accept the old syntax, and scream when I see it).
People who want to set the name of a CellType/Instance/Wire should now use a satellite/expression just containing the name, or containing "CoreName: <name>" if the name has to be evaluated.
3. Parsing
I changed Sisyph to tokenize the ropes instead of using pattern matching. It should avoid problems such as the ones arising with variables containing the characters "wire", "cI", or "wI" ... (e.g "wireA" matches "*wire*") and such as spaces in names (" foo"). I believe it will not degrade performance. The only down side is not to be able to use variables which are not single tokens, such as "f[3]", unless the parser is made more clever.
4. Fusion by name, Global Wires, Wire Icons
Pradeep has a scheme to do all that in a much cleaner way, and in Sinix instead of Sisyph. The proposal still needs to be refined however before making one more change to delicate code (the global variables ...)
5. Result Expressions
I would like to phase out the cI←, wI←, wire← hack, by having 2 extract procs, one for CellIcon, one for WireIcon. Those extract procs would look on the object for either the property $IconFor, or $CodeFor. The idea here is to to the dispatch in Sinix (using the standard mechanism) and to get rid of Sisyph.ExtractSchematics.
The implementation of 5. might have to change slightly if 4. is implemented, but not much, and only for the WireIcons ExtractProc. So I believe we should go ahead and do it.
6. Declarations of variables and minimizing usage of the interpreter
So far the Sisyph syntactic sugar consists in:
A - <var> ← <value>
B - <pname>: <pvalue>
C - Result Expressions
D - Names (everything that does not contain "←" or ":"). Not evaluated.
E - Sisyph.Store[cx, <var>, NEW [<type> ← <value>]]
F - All the rest...
A and B are semantically clean if we restrict values to be side-effect free (no big deal). 4. takes care of C. D does not call the interpreter. E could be as clean as A and B with the same restriction and a syntax.
I have not see any occurrences of F in the libraries, and I would like to keep allowing it, but to discard such expressions in things like parameter computations (see 6.) and to warn people when they use it.
I would also prefer to have a syntax for E (although I am usually reluctant about adding syntactic sugar). The reason is that it is frequent enough to justify a syntax, and it would make easy differentiating between E and F. We could have the sugar be
a: <var> ~ <value> or
b: <var> ~ {<type> ← <value>}
But I think that b does not buy much compared to a because of the way the interpreter works (the type being part of the TV anyway, and all coercions being done automatically by the interpreter). a is also extremely simple to implement, and sort of coherent with A and B (if not with Cedar syntax ...).
6. Parameters and better use of the cache
The cache could be hitting more often if we knew what are the parameters of the cell we are extracting. If we knew the parameters, when copying we could also restrict the Copy to the useful parameters. There is already a property on the CD object that indicates the list of parameters (LIST OF ROPE), and a user interface to set this property. All we need is:
- to ask designers to specify parameters as often as possible (especially for Icons from code, for which there is no way we can ever find out what are the parameters, if we do not restrict the expressions interpreted).
- to provide a function that computes parameters of a cell from unioning the parameters of its sons. This function should be paranoiac every time there is no way to predict (Icon from code) and warn users about it.
- Modify the copy to not copy useless parameters.
I do expect any difficulty in implementing those 3 points if 5. and 6. are done, in order to avoid a painful recognition of the syntax.
It should be noted that this parameters improvement does NOT affect functionality, just speed.
Please give me feedback on all that, I would like to make it the last time I think about all those issues ...

  -- Bertrand --