[Cyan]<DATools6.1>Spinifex24>Spinifex24Doc.Tioga!1

Spinifex24Doc.tioga

Written by Shand, July 31, 1984 6:56:57 am PDT

gbb January 30, 1987 3:09:54 pm PST

SPINIFEX

DATOOLS 6.1 — FOR INTERNAL XEROX USE ONLY

Spinifex - The ChipNDale DRC/Extraction Package

Shand & Beretta

Abstract: Spinifex is a circuit extractor and design rule checker. It features a new approach to the processing of hierarchically defined VLSI artwork, called level-order conflict resolution. The approach has the attractive features of retaining the cell hierarchy specified by the designer, and being applicable to the task of combined circuit extraction and geometric rule checking. Spinifex operates on constrained layouts and provides incremental analysis. The DRC part is corner-based.

Created by: Shand & Beretta

Maintained by: Giordano Beretta <Beretta.PA>

Keywords: Corner-Based DRC, Design Automation Tools, Design Rule Checking, Extraction, Layout Verification, Level-Order Conflict Resolution, Technology Independence

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

For Internal Xerox Use Only

1. General Information

DF file: /DATools/DATools6.1/Top/Spinifex24.df

To prepare to use Spinifex, bringover the DF file and type either

CMosBSpinifex

CMosASpinifex

NMosSpinifex

to the CommandTool (depending on your design's technology. Note: do not type Run ... , the above file are .load files). There will be a message .load file failed to register a command — ignore this message.

Now to actually do a Extraction/DRC select (in the ChipNDale sense) a cell you are interested in and invoke the `program' menu (with the space-p command), there are three menu entries related to Spinifex, basically they control the style of extracted output, you can choose DRC (design rule checking only), Thyme or RosemaryComparison (we are working on a better name for this last output format). Note that the algorithms used in Spinifex require a circuit extraction to be produced whether you want to output it or—this is because a number of DRC rules depend on information from the extractor. Time passes ... , something like the following appears in the ChipNDale `Terminal' viewer:

select (cell SumOfProd)
menu Additional Programs selects DRC & extract Thyme
Spinifex.
Analysis and Thyme format extraction of
cell SumOfProd
analyzing: "NORgate" . . . . . 4/4 transistors.
analyzing: "SumOfProd" . . . . . 12/0 transistors.
Commencing output of "[]<>Users>EtherBunny.pa>SumOfProd.thy" file — done.

By selecting a cell you were actually asking for Extraction/DRC of the branch of the cell hierarchy rooted at the cell you selected (in the example above SumOfProd contained 3 instances of a subcell called NORgate, and NORgate contained no subcells). The 4/4 means cell NORgate contained a total of 4 transistors in it and its subcells, all 4 of which appeared in NORgate itself, SumOfProd contained 12 transistors total, none of which did not come from subcells.

Currently the only circuit description formats supported are Thyme and a format devised by Mike Spreitzer for structural comparison to Rosemary circuit descriptions. The Thyme file looks something like this:

[]<>Users>EtherBunny>CD>ExtractedOutput.thy, Written by Spinifex, March 21, 1986 6:55:33 pm PST

SumOfProd: circuit[| N𡤁] = {

Gnd: node; ?:Stray[Gnd| anD←N*88, pnD←N*52, aM←N*224, pM←N*120];

Vdd: node; ?:Stray[Vdd| apD←N*60, ppD←N*42, aM←N*652, pM←N*334];

-- ALIAS[ $B-1$, $NOR-1$] --

$B-1$: node; ?:Stray[$B-1$| aM←N*135, pM←N*78, anD←N*40, pnD←N*28, apD←N*20, ppD←N*14, aP←N*144, pP←N*144];

-- ALIAS[ $A-1$, $NOR-2$] --

$A-1$: node; ?:Stray[$A-1$| apD←N*20, ppD←N*14, anD←N*40, pnD←N*28, aM←N*135, pM←N*78, aP←N*180, pP←N*180];

$B-2$: node; ?:Stray[$B-2$| aP←N*116, pP←N*120];

$A-2$: node; ?:Stray[$A-2$| aP←N*176, pP←N*180];

-- ALIAS[ C, $B-3$] --

C: node; ?:Stray[C| aP←N*116, pP←N*120];

-- ALIAS[ D, $A-3$] --

D: node; ?:Stray[D| aP←N*176, pP←N*180];

-- ALIAS[ $(A+B)*(C+D)$, $NOR-3$] --

$(A+B)*(C+D)$: node; ?:Stray[$(A+B)*(C+D)$| aM←N*135, pM←N*78, anD←N*40, pnD←N*28, apD←N*20, ppD←N*14, aP←N*28, pP←N*28];

C1: NORgate[Vdd, Gnd, $B-2$, $A-2$, $A-1$| N←N];

C2: NORgate[Vdd, Gnd, $B-1$, $A-1$, $(A+B)*(C+D)$| N←N];

C3: NORgate[Vdd, Gnd, C, D, $B-1$| N←N];

};

NORgate: circuit[ Vdd, Gnd, B, A, NOR| N𡤁] = {

n1: node; ?:Stray[n1| apD←N*8, ppD←N*4];

n2: node;

Q1: CTran[B,n1,NOR| W←N*4];

Q2: CTran[A,Vdd,n1| W←N*4];

Q3: ETran[B,NOR,Gnd| W←N*4];

Q4: ETran[A,NOR,Gnd| W←N*4];

};

and yes its a tioga node structured file! This makes it a real joy to do the required hand editing. Currently there is not much left, but for one you have to nest internal procedure in the calling procedure (you find them at the end of the calling procedure). Moreover, you will have to declare and initialize N.

There are a number of deficiencies, I'll try to list them but I'm sure to leave something out, and when you come and berate me I'll just say "Oh yeah, that's right, hmm I forgot to mention that".

1) The design rules are not 100% complete, this is particularly true of rules with regard to well contacts (though Spinifex does insist that wells are connected to by one and only one node) and via flatness. Gismo contains tools that close the gap.

2) The .thy files produced require some hand editing.

3) Aliases for signal names are not handled fully, currently one name is chosen and a comment is insert in the .thy file indicating the choices which were available to Spinifex.

4) Strays are fairly accurate but there could be bugs in this computation (if there are it is only a few percent error).

5) When Spinifex extracts Thyme for a transistor it includes the poly from the gate in the gate's stray statement. The gate poly should be omitted from the stray statement since its effects are usually included in the transistor models already. The capacitance and resistance from the gates are negligible with respect to the imprecision of the model, hence it does not matter if the poly from the gates is included or not. The reason Spinifex includes the poly in the gate's stray statement is to handle correctly sets of transistors in series gate to gate.

I almost forgot to show off one of the key features of Spinifex. Here is the example above, with a DRC error introduced in SumOfProd:

Analysis of hierarchy complete
.
.
.
select (cell SumOfProd)
Push into cell SumOfProd
metal for default
Add wire
pop
Pop from cell SumOfProd
flush: undo modifications
new cell: Create a new cell
replace: Replace the original cell
replace
Add selection (cell SumOfProd)
menu Additional Programs selects DRC & extract Thyme
Spinifex.
Analysis and Thyme format extraction of
cell SumOfProd
skipped: NORgate, already analyzed. 5/5 transistors.
analyzing: "SumOfProd" . . . ||||. . 12/0 transistors.; 4 errors
Commencing output of "[]<>Users>EtherBunny.pa>SumOfProd.thy" file — done.

Notice that NORgate did not change between the two Extraction/DRCs, so it was not re-processed. Also note the reporting of design rule violations. Each `|' is a primitive rule violation, generally several primitive rule violations are generated for each logical violation (perhaps I should have put this on my `deficiencies', however it is unlikely that things will improve in this regard, and if one uses ShowErrors it is in any case quite bearable).

Perform the following steps to look at the errors in the Chipndale representation.

Set the input focus in the Chipndale viewer and hit <space><c> at the same time.

Select the menu entry 'Push by name'.

Copy the name of the offending cell from the Spinifex summary to the prompt in the terminal viewer.

Look at the errors by repeatidly pressing <CTRL><next> or <next><right mouse buttons>. Each time a message explayning the nature of the error is displayed in the terminal viewer. Forthermore the highlight rectangle is added to the current selection, so that it can be removed by pressing <CTRL><d>.

Spinifex also maintains an error log on disk in the file []<>Temp>DRC>Spinifex.log

2. Spinifex/HighlightNode - Highlighting Electrically Connected Regions.

Spinifex has the ability to interactively highlight electrical nodes the command is activated by MiddleDown WHILE Slash. If material on the current layer as selected in the control panel is found at the point indicated and it is part of a cell which has been previously extracted then all regions electrically connected to that region have boxes on the ChipNDale highlightShade level laid over them. Be warned that shading does not extend to material in cells which have not been analyzed or above the current pushed in level.

The ChipNDale program menu also contains a command to highlight a node by specifying a coordinate pair as it can be found in the .thy file after setting SXOutputImplA.printLocalNodeLocation ← TRUE with the interpreter.

3. Useful Atoms

$Export: If an object has a property with this key and if the value is $TRUE and the cell is at the root of analysis, then the signal name of the node with this property is used as a parameter (port).

$SXCrystal: If a transistor has this property, then its rope value is placed in the Thyme parameter list preceded by a semicolon.

$SpinifexCircuitDescription: for CDPropTool [used to attach a Rope.ROPE to a ChipNDale cell which contains the rosemary structural description of a cell].

$Opaque: believed to prevent Spinifex from looking inside an object. The code to implement it was not found yet at the time of writing.

4. Useful Hints

Date: Sat, 22 Nov 86 18:58:21 PST

From: Beretta.pa

Subject: How I DRCed the EU-3 in One Day

To: DAToolsUsers^.pa

Reply-to: Beretta.pa

Yesterday I DRCed the EU-3. This is how I did it.

First I attacked the inner part. I skipped the RAM, which had already been checked by Louis. I worked down the hierarchy expanding the cells until they were of reasonable size (say of maximal height 1 cm on the screen when the whole inner part is displayed; full length). Then I selected all the cells and fired up Spinifex, in order to verify them one by one. (To make things more exciting, I also fired up Summoner — even if the CPU usage was up at 100%, the Controller still assigned me compilations).

While Kearsarge was crunching and I was reading, I kept an eye to the figures about the garbage collector the Watch Tool wrote in his viewer. Every time the garbage collector got a big chunk of memory (Spinifex releases 10 corner-stitched planes at a time after a cell is done), I sorted the free lists and returned them to the VM. To do this I used Russ Atkinson's ForceReclaimFreePages command, which is used to reclaim pages that are composed of entirely free collectible objects in the SafeStorage heap.

When all cells were done, I ensured all free storage was returned to the VM. I then grouped reasonable numbers of cells, created new cells, and fired up Spinifex again in order to verify the overlaps. After I threw at such a new cell-group also the Gismos, I expanded it again and formed a new cell-group containing a common cell with the previous cell-group.

When I had done all cells and all their overlaps, I rolled back. If I had not run Summoner, I could probably have continued right ahead.

To verify the outer part, I used a different strategy. I worked myself from the outer layers or belts of cells towards the interior. First I expanded cells until they were of reasonable size. Subsequently I selected the outer two belts and created a new cell, onto which I fired Spinifex. When it was done, I re-expanded it and and made L-shaped cells containing only one corner and threw the Gismos at them (unless they were routing channels). The restructuration was wise because the Gismos are flat and the corner-stitched methods can easily get the machine to bend over when there are big holes.

When I had done all L-shaped cells, I expanded them, deleted the outermost belt of cells, cleaned up the ChipNDale directory, and ensured all free collectible storage was returned to the VM using Russ Atkinson's ForceReclaimFreePages command. The reason I removed the cells was that the big memory sucker in many of our tools are the extractors, which store the geometry in a data structure of their own, usually with quite an overhead per rectangle. Removing the ChipNDale cells, I got rid of both the ChipNDale and the extractor's geometry, thus giving me back quite some memory after cleaning it up.

I worked myself this way using groups of double belts towards the interior of the design, always including the innermost of the previous group as the new outermost in the new group.

When I had DRCed the whole EU-3, I still had more than 17000 free pages of VM, more than enough to run Walnut. The Watch Tool showed that there has not been much paging during the whole exercise (Kearsarge temporarily has maximum virtual and physical memory).

For the verification of the IFU, I had tried to use AutoReclaimFreePages, which is a process reclaiming the free pages every minute. The idea was to let it run all alone during the night. However, AutoReclaimFreePages made a considerably worse job than the manual usage of ForceReclaimFreePages.

In the glorious future, when Spinifex will have been supplanted by its son, all this will no longer be necessary, because SoS uses only little storage for itself.