1987

####################################################
Date: Thu, 15 Jan 87 12:57:50 PST
From: jacobi.pa
Subject: Proposed change for our DA System
To: DAToolsImplementors^.pa, Monier.pa, Serlet.pa
Cc: Jacobi
Reply-to: jacobi.pa

I propose the following deal; it will have a major impact on our DA system as a whole.

Concern

PWCore.Layout get a context parameter from which it is possible to find out a design into which the layout shall be put.  (Similar to Sisyph)

In return, ChipNDale would allow composite objects to exist without being included in the directory of the design.  (But still, composite objects must not be accessible from more then one design) 

Rationale from a ChipNDale view point
This deal would not mean ChipNDale would not pose any invariants about designs directory; just the invariants would be weaker.  To ChipNDale there would be two main differences between the proposed and the old requirements:
1) For all purposes, when a design is enumerated, or an object is enumerated recursively, a new algorithm must be used.  Designs or objects must be enumerated quite often! [pop, other interactive commands, redraw, propagate changes, IO, clean up, error messages, expand, copy].  
2) ChipNDale would not need to check and reinstall the invariants, since no malignant clients would be around.  Plain bugs do not justify such hard consistency checks.  
When the enumeration methods would be changed, ChipNDale itself could relax the directory invariants; the sole reason to then do the checks would be the knowledge that clients did things like put an object into two designs.  Now, in that case, the reason to keep the old, hard invariant, is that the cleanup wouldn't work with the weaker invariant. [To make a cleanup work correctly we would have to cleanup both designs]
Living clean, or cleanup, is necessary.  Remember the story from before we had cleanup:  
Brian generated a design with Patchwork.  Then he edited his design, but the edits where made in the library.  [A clear case of an object being included in two designs].

Minor points
When a design is given, it will be possible for a PWCore.Layout procedure to generate import objects. 

A design can be used as context for caching sub-objects; Right now it is impossible in a PWCore.Layout procedure to cache correctly results or sub objects.  Now, any caching must rely on being found by a clean up step, which results in making a copy [from the second time on when the cache is used].

Costs
Conversion costs:
To ChipNDale:
Changes in lots of code for changed internal invariants.
The main work was figuring out where changes will be necessary, it won't be doing those changes. [CDImportsImpl, CDCellsImpl, CDIn, CDOut, CDDirectoryImpl, CDDirectoryOpsImpl, CDCleanupImpl, CDCellsInteractionsImpl, CDErrorsImpl, CDBottomUpImpl, ChipmonkCmosWrite, ChipmonkNmosWrite, CDMarks, CDRepetitionsImpl, CDDynamicObsImpl plus the necessary interfaces].
To PWCore:
Rethink caching invariants; do the change.  Changes to DecorateProc, AttributesProc.  [AttributesProc needs some re thinking anyway, to make them powerful enough to collect layout hints.] 
To PWCore Clients:
Trivial syntactic changes, as long as they won't take advantage of new mechanisms.
To the DA system as a whole:
Some minor re-coding, a ChipNDale release [But you'll get that anyway].
Real costs after conversion:
To ChipNDale:
The new design enumeration methods would be slightly slower. O[1] per object. It won't be noticeable.
To PWCore:
An additional handle is passed around at run time.  Please consider, what is the inconvenience of having a handle?  Other applications require handle's without first thinking.  
Cached objects might be retrieved with two steps instead of one.  
To PWCore Clients:
An additional handle is passed around at run time
To the DA system as a whole:
An additional handle is passed around at run time

Benefits
To ChipNDale:
Peace.
The new design enumeration methods could be correct even when the directory is incomplete.
Possibility to get rid of complex clean up code, by being able to trust clients again.
Repetitions could be simplified.  
To PWCore:
You may dispute those benefits, however, but they aren't the issue for the change anyway.
The handle might be useful for more applications, e.g. it could contain information whether to make or read design from checkpoints.
Technology independence will be possible, because technology could be figured out.
Maybe speed up, because caching could work without need for indirect objects.
To PWCore Clients:
Caching objects will be possible. 
Possibility to be more honest ChipNDale clients.  [To be complete we would also need a procedure to extract CoreGeometry pins or whatever PWCore wants, from an object with ChipNDale pins]. 
Accessing imports will be possible.
Unknown further uses of the handle could be invented, e.g.
Find out Technology, working directories, special design rules. 
A place for error messages. 
A place to find/put hints for doing layout. [E.g. placement hints; aspect ratio]
Parametrization.
Together with an improved AttributesProc: iterations.
To the DA system as a whole:
Two important implementations could live together friendly.
Speed up because objects will be copied less.  
Possibly memory savings, but I'm not sure.
Layout is performed with a more complete state.
A natural place to specify checkpointing would exist.
Abuts and Routing-cells could make it onto ChipNDale files. [Because the weaker directory invariants would allow them to be nice citizens easier; now ChipNDale better does not write objects on files when they don't play the rules]

Alternatives
Keep status quo.
Thats too painful.
Real enforcement of ChipNDale's current invariants. 
The current PWCore would cease functioning (See** to understand why I mustn't care.) 
Introducing a concept of read only objects. 
That concept would still have some holes and problems, however, it would be much better than the status quo.  [Imports are NOT read only.]
That might be a good idea in general, independant of this proposal, unless carried to extremes, it would not solve all the problems which caused me to make this proposal.  
PWCore generate something else then ChipNDale objects. 
Clients could not use all the already existing constructors. Duplication of code.
Other ideas. 
Must have one first.

History
Why it came to the current bad state.  Different people might put different emphasis on different reasons; this is my story: 
In 1984 there were two performance bugs:
1) In ChipNDale: When an object with an already occupied name was included in a designs directory, an alternative name was tried, which was build in a predictable, repeatable way. 
2) In Patchwork: Abuts where included always with the same name "abut". 
For any abut to be included in the directory it was tried to include it as "abut"; then as "abut@1", "abut@1@2"... until "abut@1@2..@n" was tried. This caused n2/2 tries to include objects in a design, which, because of using small SymTab's, caused O(n3) rope comparisons [ropes with length of another O[n]].  [n=number of objects]
ChipNDale's performance bug was fixed immediately after I was told about the problem... Patchwork switched over to not play the rules with the directory.

**Another, less serious story
ChipNDale never allowed to make objects with interest rects larger than the bounding box.  This might have been painful and not the right thing, but it was the rule.  Now in the logic library this rule was violated; those objects never displayed correctly [They would even cause incorrect masks].  Then these objects did not pass the automatic conversion from CD23 to CD24.  I have been told [Ed] that ChipNDale allowed the construction of those objects; therefore it should also deal with them.  See, thats why I must enforce invariants; otherwise I forfeit my rights when problems occur later. 
[In CD24 interest rects are treated as "stuff"; they automatically add to the area used to compute the bounding box of cells] 

Timing
It would need a release, e.g. CD25 with Cedar7.0; The changes could delay the release of CD25 for two weeks, but it might still be ready before Cedar7.0 if I could start early. 
Changing PWCore would also need some time; I believe the thinking about it could be done in advance, before the CD25 release, such that the coding would only create minor additional delays.

If you don't want the changes for their major impact on our DA system, what about simply doing it to be able to live clean with ChipNDale?  
Christian

####################################################
ΐChipNDaleMessages1987.tioga
Copyright c 1987 by Xerox Corporation.  All rights reserved.
Created by Christian Jacobi 
Last edited by Christian Jacobi,  February 18, 1987 4:50:28 pm PST
Κ±˜™Jšœ
Οm
œ1™<Jš
œ™Jš
œB™B—J˜Jš
Πbl˜J˜Jš
œ4˜4JšΠbsœ˜!JšŸœ˜JšŸœ#˜*JšŸœ/˜1JšŸœ˜
JšŸ
œ	˜J˜J˜VJ˜š
Οb˜J˜J˜
J˜JšœZΟi	œa˜Δ
—J˜š
 %˜%˜ί
J˜—J˜©
—JšœήΟs:Πis’œ
˜₯˜YJšœp’7œ˜©
——J˜š
 ˜J˜fJ˜Jš
œ«˜«—J˜š
 ˜š
‘˜˜
J˜8Jšœb’„œ˜θ—˜
JšœW’cœ˜Ό
—˜J˜R—˜Jšœ+’œ˜G——š
‘˜˜
J˜e—˜
J˜±
J˜B—˜J˜1—˜J˜1——J˜—š
 ˜˜
J˜J˜ZJ˜VJš
œ"˜"—˜
J˜YJ˜„
J˜RJ˜M—˜Jš
œ"˜"Jšœ3’‡
œ˜½
J˜#˜:J˜@J˜Jšœ-’"œ
˜PJ˜Jš
œ5˜5——˜J˜;Jš
œ/˜/Jš
œ*˜*J˜/J˜5Jšœ=’¨
œ
˜ζ
——J˜š
 ˜˜J˜—˜4J˜U—˜,J˜Š
J˜¬
—˜7J˜Q—˜
J˜——J˜š
 ˜˜}˜(J˜΄
J˜H—Jšœ 
Οu
œ[€
œN˜Λ˜™
J˜——˜Jš
œΤ˜ΤJšœ
’{œ˜~——J˜š
 ˜J˜±
J˜½
—J˜J˜Œ
J˜	J˜Jš
œ4˜4—…—!œ%