To check a layout, type Genista in the command viewer. Go to the viewer containing your ChipNDale design and select a set of cells. Hit the p key while holding down the space bar. Select the entry Extract & DRC (Sinix & Genista) in the pop-up menu. This command will first execute Sinix to produce an appropriate Core design, and subsequently Genista to verify it. Upon termination the design rule violations will be visible as highlight rectangles in the ChipNDale design (if there is a correspondence among the Core and ChipNDale data structures). Eventually a summary is produced.

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 (Genista), presents a pop-up menu listing the names of the Core cells in which design rule violations were found by Genista. If a name is selected, the command prints the design rule violations of the cell (type of violation, layers names and wire names). It subsequently attempts heuristically to find a corresponding ChipNDale cell, and if successful tries to push into it and to change the display to show the selected cell. I do not know what to do if you have edited the cell you are currently pushed in, so the last part of the command may fail. A way out is to pop out of the cell you are currently in.

The second design rule violations listing command, List All Violations (Genista), lists all design rule violations it found in the last extraction and verification pass for design in the viewer with the input focus.

There is no heuristics on what to do if you edit a cell after you grind it through Genista. The following is the state after a pop with replace. Error rectangles (including their messages) you have not deleted manually are left in the cell. The design rule violations listing for the cell is invalidated and can no longer be examined. This is not a fancy user interface, but it is predictable and hence less confusing.

All commands can be aborted in the usual way (i.e. ESC DEL).

Genista provides a procedural interface. If Genista is asked to be shy and can be so, it 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.

Clients can fully customize the verification by providing own procedures for all or part of the operations at the class or at the object level. Refer to the definition module for more details. If you want to make sure that you process all the geometry, you may want to set the variable GenistaCommandImpl.debug to true during your development.

Since Genista does not use a geometrical data structure, its memory requirements are minimal. The data space required are stack to propagate the binding, a cache of fixed size for the neighbourhood table, and a rectangle for each cell.

The use of the neighbourhood 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 analyse 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 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 is suggested to 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.

Remember that Genista verifies only the separation and the width rules. Use Gismo to check that vias are on flat topology. Although by construction with a catholic program you cannot have unconnected wells in your layout (they would be wires, but they do not conduct), it is nevertheless a good idea to use the well connection tool of Gismo, because it flags errors where there are not enough contacts.

The correctness of Genista is easy to prove by using the propagation stack, its main invariant. The completeness of Genista depends on specific extraction and verification procedures with which objects are decorated.