To check a layout, type SoS 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 & SoS) in the pop-up menu. This command will first execute Sinix to produce an appropriate Core design, and subsequently SoS 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.

SoS 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 (SoS), presents a pop-up menu listing the names of the Core cells in which design rule violations were found by SoS. 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 (SoS), 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 SoS. 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).

SoS provides a procedural interface. For its clients SoS maintains an error count and a list of pairs {rectangle, message} in the Core cells, which can be accessed using the property with key $SoSError.

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 SoSCommandImpl.debug to true during your development.

Since SoS 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 SoS 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 SoS 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. SoS can just say `separation violation' or `width violation' [it nevertheless uses the Core data structure to specify the affected wire names]. The fact that SoS 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 SoS, which he can incorporate in the generating program. The first step of the switch should consist of a verification of the base cells with SoS and doing all the cosmetics to avoid unwanted error messages.

Remember that SoS 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 SoS is easy to prove by using the propagation stack, its main invariant. The completeness of SoS depends on specific extraction and verification procedures with which objects are decorated.