GenistaDoc.tioga
Written by Giordano Bruno Beretta, October 17, 1985 4:37:14 pm PDT
gbb, November 25, 1987 1:14:08 pm PST
GENISTA
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
Genista
Grandson of Spinifex
Giordano Beretta
© Copyright 1985, 1986, 1987 Xerox Corporation. All rights reserved.
Abstract: Genista is the Grandson of Spinifex. It is a partially hierarchical design rule checker that enumerates a Core design and uses the ChipNDale geometry with which it is decorated.
Created by: Giordano Beretta
Maintained by: DAToolsImplementors^.pa
Keywords: Core, Design Rule Checking, Layout Verification, Design Automation Tools, Technology Independence
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
1. Principles of Operation
Genista traverses a Core data structure to retrieve and verify the layout geometry it contains. Two passes are made: in the first pass, incorrect layout in the Core data structure (e.g., wells) is verified "flat" extracting the layout information directly from ChipNDale. The second pass is hierarchical. For every Core wire in every Core cell, two operations are performed. The first verifies the width rules and the second verifies the separation rules.
If a cell is a record, verification is performed among children and among the parent and the children. If a cell is a transistor, the only operation consists in extracting it, since atomic objects can still be considered to be correct by construction.
The violations found are placed in the Core data structure (see definition module for the details) as well as logged in the file []<>Temp>DRC>Genista.log.
As a means to speed up the verification of regular structures such as memory cells, Genista maintains special dynamic cache called neighborhood table. It holds the most recently analysed pairs of objects. If an object pair to be analysed is found in this table, then the analysis of their interaction is skipped.
The width and separation rules are taken from the ChipNDale module CDSimpleRules. More "complex" (?) rules such as separation to gate, well contact rules, and via flatness are coded explicitly in the technology dependent part of Genista. In the grand and glorious future when we will have a method to specify technology parameters, they will go to such a database.
2. Usage
Bring over [DATools]<DATools®>Top>Genista.df, where ® is the current Cedar release number.
To check a layout, type Install Genista or Install Drc in the command viewer. For the CMOS-B technology use the command Install DrcCMOSb.
You may want to avoid the verification of certain cells. This can be achieved by assigning a non-nil value to the property $DoNotDRC to such cells.
Typical running times:
- EU-4 minimal DRC using the connectivity information in Core: 05:35:13
- same without connectivity information: 05:43:50
Interactive
To check a layout, type DrcCdCMOSb in the command viewer. As soon as the DRC package is loaded, it retrieves a test design and performs a regression test. Due to racing conditions when writing in the terminal viewer, you should not start a DRC before this regression test has terminated.
Go to the viewer containing your ChipNDale design and select a set of cells. Hit the k key while holding down the space bar. Select one of the entries ... DRC (Genista) in the pop-up menu. This command will first execute Sinix to produce an appropriate Core design, and subsequently Genista to verify it. Finally, the command will back-annotate the ChipNDale design with the discovered design rule violations. Upon termination these design rule violations will be visible as highlight rectangles in the ChipNDale design. Eventually a summary is produced.
There are three menu entries labelled ... DRC (Genista), one for small and one for large inputs, as well as one for a minimal DRC. A large input is a cell with more than three hierarchy levels, while a small input is one with less hierarchy levels. The difference is that via flatness is not verified for large inputs. The minimal DRC omits also that part of the well and diffusion verifications that require a corner stitched plane and can be used for large chips.
Genista registers also two commands to list all design rule violations found in a previously analyzed cell. These commands do not apply to cells analyzed by program. The first command, List Violations, only displays the number of violations found during the last execution. Remember, that if you execute Genista on a cell which has previously been verified but not edited, no action takes place.
The second design rule violations listing command, List All Violations, lists all design rule violations it found in the last extraction and verification pass for design in the viewer with the input focus.
All commands can be aborted in the usual way (i.e. ESC DEL).
By program
Genista provides a procedural interface. Genista maintains for its clients an error count and a list of pairs {rectangle, message} in the Core cells, which can be accessed using the property with key $DrcError.
Comparison to Spinifex
Basically Genista is the union of the previous packages SoS and Gismo..
The use of the neighborhood table makes Genista very fast in comparison to Spinifex in repetitive parts of a layout (e.g. RAMs). Spinifex cannot take shortcuts in such cases and has to instantiate and analyze the geometry for all terms of the repetition.
On small irregular designs with few cell overlaps, Spinifex will be faster than Genista due to the superiority of the corner stitched data structure over our quadratic algorithm. However, the limited virtual memory available on the Dorado is a show-stopper for the extraction code in Spinifex.
Spinifex takes advantage of being based upon a geometrical data structure to produce detailed error messages. Genista can just say `separation violation' or `width violation' [it nevertheless uses the Core data structure to specify the affected wire names]. The fact that Genista processes the geometry locally (pairs of rectangles)—in opposition to globally (cells) in Spinifex—causes it to flag more design rule violations than Spinifex for some layouts.
The designer can avoid this problem by adapting his design style to the new fashion of the Cedar world. His cells should be correct in isolation. `Artificial' cells whose only purpose is to connect wires left open in child cells are bad. If the connections are included in the child cells, locality is preserved, the layout is easier to understand and `wrong' error messages are avoided.
In conclusion, the designer can use Spinifex while he is doing the layout of his base cells, in order to get more detailed error messages. When he assembles the cells, he can switch to Genista, which he can incorporate in the generating program. The first step of the switch should consist of a verification of the base cells with Genista and doing all the cosmetics to avoid unwanted error messages.
Profile Options
Genista.EmulateSoS: BOOL ← FALSE
Performs only the width and separation tests.
Genista.EmulateMayday: BOOL ← TRUE
Ignores the connectivity information stored in Core.
Genista.Debug: BOOL ← FALSE
Can also be started by typing ← DrcDebug.Debug[].
3. Advanced Usage
The DRC may die off because of lack of virtual memory. However, not everything is lost when the ChipNDale command is used. After the extraction, the Core data structure is written onto disk in a file with the fixed name []<>Temp>DRC>Genista.Core. On a dead machine, simply boot and install DrcRestart, which registers the command DrcRedo. This command does the design rule checking part. When this is through (a prompt reappears in the Command Tool), the Core cell with the design rule violations hangs at DrcRestartImpl.lastCore. Now type Install DrcCdCmosb.Install, read in your ChipNDale design, make a selection anywhere, and press ^ while holding the left mouse button down. Select the menu entry detached debug and you get an event viewer. Stuff the following two lines in this event viewer:
DrcCommandImpl.stateHandle.design ← design;
EnumerateCore [DrcRestartImpl.lastCore, DrcCommandImpl.BackAnnotation, DrcCommandImpl.DrcCommandImpl.stateHandle, NIL]
4. Maintenance Hints
Try to determine whether the bug has to do with the exploration of the Core structure (first case) or with the finding of the geometry (second case).
First case. If you enter "← DrcDebug.Debug[]" in the Command Tool, Genista will create a typescript viewer into which he keeps a log of the cells and wires analysed. In addition, it will open a CoreView viewer showing the contents of the Core data structure, Finally, it presents a CoreView icon, which, if opened, will display each rectangle of a wire as it is being verified and pauses. If your debugging session extends over several rollbacks, you may want to use the user profile option.
Second case. a. Two rectangles violate a design rule but are not detected. Give to both instances of them the ChipNDale propriety $break (ChipNDale command N-space). When they will be processed Genista will call the debugger when it comes to a point called DrcDebug.break. You will find all you need on the stack.
You may examine several pairs at the same time. To this purpose give different values to the property $break. When you have examined a pair, simply press the button Proceed in the debugger viewer.
If Genista terminates without ever calling the debugger, this is a clear sign that something is wrong with the properties attached to the Core cells.
Second case. b. Two rectangles are flagged to violate a design rule but this is not true. Open DrcCMOSBimpl.mesa and WellsEtcImpl.Mesa and set break-points before calls of MarkError. You will find all you need on the stack. Either the design rule will be wrong or the bindings of the wire will be wrong.
Good luck !