Inter-Office MemorandumToChipmonk UsersDateMarch 18, 1982FromRich PascoLocationPalo AltoSubjectNuts ManualOrganizationPARC VLSI Systems DesignXEROX Filed on: [Indigo]Nuts>NutsManual.Bravo, .PressNuts are what Chipmonks eat.Nuts.bcd is a D-machine program which translates integrated circuit layout data files from CaltechIntermediate Form (CIF) to Chipmonk Format. It runs on D-Machines under Alto/Mesa 6.0.It accepts a limited subset of CIF commands, specifically:Define SymbolBoxCall SymbolMirror, TranslateRotate (multiples of 90 degrees only)UserExtension 9 = symbol names (compatible with SIF).UserExtension 94 = node names.Symbol hierarchy is preserved, although symbol definitions are re-ordered to eliminate forwardreferences.To use, retrieve [Indigo]Nuts>Nuts.bcd and type "Nuts" to your Alto Executive. Atypical Mesa.typescript follows:Alto/Mesa 6.0 of 13-Oct-80 11:4713-Jan-82 2:10>Nuts -- 146500BNUTS of January 13, 1982File Name (no extension): ExampleLambda (CIF units): 250Initializing Parser, InterpreterParsing Example.cif...100...200...finished.Writing Example.chip...finished.Nuts is intended to translate any syntactically valid .CIF file into a valid .Chip file, with allexceptions (constructs Chipmonk cannot handle) flagged with an error message describing thedifficulty and the fix taken.]gpi c8q]rX -q7Br ]q]r -q7Br Yq]r -q 7BrSsr M3 H6 EQ W CF @X:> <: 9w7%6o54 2:$ 0 -R ,)4t'&,$#$!! + /rN ; '6=R"Nuts Manual2Examples of exceptions and their fixes are:Lambda = odd number of CIF units - not allowed, aborted[Chipmonk internal dimensions are in terms of half-lambda]Items not aligned on lambda grid - dimensions quantizedCIF dimensions too big to represent in Chipmonk's 16-bit-integers - set to 045-degree (and worse) boxes - deletedUser extension 94 = node names - placed on zero-by-zero metal rectangle (see below)Undefined user commands - ignoredRoundFlash, Wire, Polygon - deletedTo answer in advance the most commonly asked questions:Q.How does Nuts recognize transistors, contacts, etc?A.It doesn't. Transistors are translated as red crossing green. If you want to use the Chipmonktransistor and contact primitives, you'll need to edit them in by hand.Q.What about cut, implant, etc? I thought there was no way to draw rectangles on these layersin Chipmonk.A.Right, there isn't any way to draw them in Chipmonk. But there is a way to represent them,and Nuts uses that.It is interesting to note that contacts translated from CIF appear differently on a color display than contactprimitives drawn in Chipmonk. Apparantly when drawing a contact primitive the black of the cut replaces thecolor of the other layers, while when drawing a naked contact superimposed on other layers its black is added tothe color map by some other algorithm. This should help the designer visually locate such contacts.Q.What about CMOS layers?A.The current Nuts won't handle them; they were just recently added to Chipmonk. But Nutshas provisions for them, and they will be added once standardized CIF names for them areagreed upon.Q.Will nuts be expanded to handle 45 degree angles?A.It would be medium-easy, but there's no point, until Chipmonk can handle them. TheChipmonk file format allows 45's, but Chipmonk itself can't presently handle them.Q.Will red-crossing-green transistors, naked cuts, etc. be flagged?A.Regarding red-crossing-green transistors, naked cuts, etc. it is not really in my immediateplans to detect and flag these in Nuts, as they are structures which can be literally translatedand will live happily in the Chipmonk environment. (You could even draw a red-crossing-green transistor in Chipmonk!) Indeed, for Nuts to replace red-crossing-green with a call ona Transistor primitive would require second-guessing the designer's intent, and wouldseriously complicate the present clean, simple code of Nuts. There are planned features ofChipmonk which will not properly handle them (e.g. circuit extractor). It is my feeling thatall red-crossing-green transistors, naked cuts, etc., both those translated from CIF and thosedrawn in Chipmonk, should be detected and flagged within Chipmonk during Chipmonk'sinternal design-rule-checking phase.Node Names. The next item on the Nuts development plan is node names. The best way tohandle them is not clear. In Icarus, text items may be placed anywhere, but in Chipmonk, textmust be a property of an underlying wire item (box on metal, poly, or dif). The Icarus designermay place a text item in the top level to label a node in a symbol nested several layers deep. Theproposed approach is to find which layers lay under the loose text item. If there is exactly one, aone-lambda square of that layer is generated to hold the text. Otherwise, the text is flagged andignored. Comments on this approach are solicited. fr G bX+_97(]qF:\1rX7ZLY)%WSV!!T# Q7 N3 KVJjG G5'F Cur*urA>q'G=T vq<\^ vq;'= 8]rX 5xA3<2p /X1 ,J+"R (=XA %X)2#'9"P J ]H IX@FH88$ w rB KD 2. CS d ;,6 2 : p=\SNuts Manual3As an interim hack, Nuts now represents all node names as a text property of a zero-by-zero pieceof Metal in the right place (and flags them appropriately). If the desired node was on some otherlayer, it is necessarily to manually edit the appropriate cell, but this should be easier than startingfrom scratch with node names.Architecture / How it WorksNuts is built around the same CIFParser and Interpreter used by Magic. The communication goessomething like this:Nuts is in control. There are two phases of operation. During the first phase CIF Parser andInterpreter build an internal representation of the design in the Interpreter's virtual memory. In thesecond phase, Nuts writes out the Chip file, interrogating the Interpreter to obtain the necessaryinformation.During the CIFParsing phase, Nuts calls ParserDefs.ParseStatement repeatedly. The parser returnsto Nuts after each CIF statement, and Nuts increments the statement count and displays it asappropriate. When the Parser finds a User Command, it calls OutputDefs.OutputUserCommand.Nuts then parses the User Command, allocates a UserObject of the appropriate size and type, andpasses it to the Interpreter (for inclusion in the Interpreter's data base) by callingIntDefs.IUserObject. After parsing each (non-User) statement, the Parser hands it (directly) to theInterpreter, which calls OutputDefs.BB* (where * is one of Wire, Flash, Polygon, Box, orUserObject). Nuts responds to these calls by returning the appropriate bounding box. Also,constructs not handled by Nuts (such as non-manhattan boxes) are flagged at this point.Chipmonk files are so constructed that before each list of items there is a count of how many itemsfollow. [See [Indigo]Nuts>ChipFileFormat.press]. In order to write out a chip file, multiplepasses are made over the Interpreter data base, first to count and later to actually output the objects.In addition, Chipmonk requires that there be no forward symbol references, a constraint notimposed by CIF. To meet this constraint, Nuts maintains a dictionary of symbols in such an orderthat there are no forward references.The first pass over the interpreter's data base simply counts the symbols and allocates the dictionary.The second pass enters the symbols in the dictionary in an order such that each symbol appearsbefore it is called. This is achieved by the recursive procedure Mark, which enters a symbol in thedictionary only after first entering all the symbols it calls.The contents of a symbol definition held by the Interpreter are examined by callingAuxIntDefs.IExpand. The Interpreter responds by calling AuxOutputDefs.Aux* for each object inthe definition, where * is one of Wire, Flash, Polygon, Box, UserObject, or Call. How Nutsresponds to these calls depends on its state Mode, which may be one of Idle, Marking,ScanningSymbol, CountingItems, PuttingDefn, or PuttingItems.In Marking mode, Nuts ignores all items except Calls.Once forward references have been resolved, Nuts may write out the definitions. For each symbol(in dictionary order), mode ScanningSymbol is invoked and the symbol definition is expanded, tosearch for the symbol name (user extension 9 anywhere in the definition) and to count the itemsinside. Then mode PuttingDefn is invoked and the symbol is again expanded, this time with theobjects being written to the Chip file. This is repeated until all symbol definitions have beenwritten.Two more modes, CountingItems and PuttingItems, apply to top-level items. These correspond toScanningSymbol and PuttingDefn except that instead of a real symbol the pseudo-symbol obtainedby IGetRootID is used to signal the interpreter to use top-level items. fr G b+6 `<& _Y ] ZwX WrE VD S_)4 Q/8 PW:( N KY Jj!; H= Gb@ Ej+k+ DZ31 B3% AR> ?W <7, ;eb 980 8]> 6Q 5U% 2pP 0E /h X -> *HI; ){0. 'V &s J $< " 5 %D *5 ? K 9'  I (%9 Gz ]>VO TIMESROMAN  TIMESROMAN TIMESROMAN LOGOGACHA  TIMESROMAN  TIMESROMAN TIMESROMAN A j/6$NutsManual.bravoPascoMarch 18, 1982 4:39 PM