1. General Information
DF file: /DATools/DATools6.1/Top/Spinifex23.df
To prepare to use Spinifex, bringover the DF file and type either
CMosBSpinifex
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
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.