CellLibrariesGenDoc.tioga
Copyright Ó 1987 by Xerox Corporation. All rights reserved.
Created by Bertrand Serlet, June 6, 1987 9:42:15 pm PDT
Bertrand Serlet, June 6, 1987 11:35:00 pm PDT
Last tweaked by Mike Spreitzer on February 17, 1988 11:52:38 am PST
CellLibrariesGen
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
CellLibrariesGen
Pickling CPU time
Bertrand Serlet
© Copyright 1987 Xerox Corporation. All rights reserved.
Abstract: CellLibrariesGen is a package precomputing information which is expensive to recompute. This information is capture in .corelib files belonging to the CellLibraries package. Therefore this module is reserved for maintainors of CellLibraries, and not for general public.
Created by: Bertrand Serlet
Maintained by: Maintainers of CellLibraries
Keywords: CellLibraries, .corelib Files
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
1. Package Composition
CMosB standard cells pickling
The file SCLibCMOSB.dale is the source file, that, with the command GenerateStdCellsCmosBLibrary.cm and its utility GenerateStdCellsCmosBLibrary.mesa recreates the 2 files SCLibCMOSBSch.corelib and SCLibCMOSBMask.corelib (found in CellLibraries.df).
Whenever SCLibCMOSB.dale is modified, the lock should be taken on CellLibraries.df, and those 2 files regenerated.
Generating the mask cells themselves
SCLibGen.mesa and Co.
I think this software is kind of dead.
2. Current State of Logic
Example: Logic.Or[3]
The question is what does it generate currently? Answer:
A record cell [A] containing one instance.
This instance is instance of a funny library cell [B] (with a funny class).
When you recast this funny cell (what you need not do for simulating, since there is an eval proc), you get a record cell [C] with one instance (permuted cell).
That instance is instance of the schematics [D] found in SCLibCMOSB.dale.
Now what happens when the SC system comes? Answer:
It flattens until it finds a $SCPlacableElement property (one of the previous cells carries it, which one I'm not sure, I suspect [B]).
It somehow ask layout of [C], which is $AbutX (!!!) which asks layout of [D], and at that point you get the mask of SCLibCMOSB.dale!
Let's count the CD.Object/Core.CellType
Imagine you draw the little or3.icon of the Logic.dale library.
How many CD.Object do you have? Answer: 7
or3.icon, or3.sch, C2OR03A.sch, C2OR03A.mask, AbutX[C2OR03A.mask], indirect[C2OR03A.mask], indirect[AbutX[C2OR03A.mask]]. (I plead guilty for the last two).
How many Core.CellType do you have (each with its own wires, etc)? Answer: 9
Extract[or3.icon], Extract[or3.sch], [A], [B], [C], [D], Extract[C2OR03A.mask], PWCoreCellType[[C]], PWCoreCellType[[D]] (I plead guilty for the last two).
Why it is ridiculous
It costs us in memory.
It costs us in time, especially start-up time.
It is a mess to maintain.
Why we MUST act NOW
Lots of people are going to generate SC soon.
3. What the right way is
Example: Logic.Or[3]
[A] would not be needed if things were renamed properly.
I do not think that the library cell class buys us anything. We can achieve delayed binding to CMosB by other means (see later). Therefore we get rid of [B] and [C].
We are just left with [D] when calling Logic.Or[3]!
That would reduce the CD.Object count to 5, and the Core.CellType count to 5 also!
Delayed binding
Is achieved at the time the CoreDirectory.Library named "CMOSB" is made, as now.
We can have at that point in that Library just Unspecified CellType, and then the EvalProc will get stuck on them, and there will be no problem to simulate them, as now.
Improvement
We can save common values of parameters on .corelib file(s).
4. Other things to do
Move test code from CellLibraries.df to CellLibrariesGen.df.
Lots of cleanup.
5. Dependencies
It is OK to have CellLibrariesGen.df depend on CellLibraries.df, but not the reverse!
The only "dependency" should stay in the .corelib files.
The lesser things CellLibraries.df depends on (at the cost of CellLibrariesGen.df depending on more) the better!