SoS traverses a Core data strucure to retrieve and verify the layout geometry it contains. Verification is done against a simple set of design rules provided by ChipNDale. It uses a brute force quadratic algorithm, offsetting the time complexity penalty by performing heavy pruning on the data and by using a special dynamic cache.

The actions to be performed both on Core and ChipNDale objects depend upon their class. Therefore we use the object oriented formalism consisting in attaching a specific procedure as a property to each class. This procedure is applied on the object itself when it is encountered. Since this is quite expensive from a running time point of view due to the heavy list processing, the most frequent cases are treated separately in special cases.

As a means to speed up the verification of regular structures such as memory cells, SoS maintains special dynamic cache called neighbourhood 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.

Separation violations are allowed if the pieces of material involved are equipotential. The design rule violations are reported in the Core data structure. If the Core data structure contains sufficient information, the design rule violations are reported also in the ChipNDale design.

Bring over [DATools]<DATools®>Top>SoS—.df, where ® is the current Cedar release number and — is the current ChipNDale version.

To check a layout, type SoS in the command viewer. Then read a ChipNDale design and select a set of cells. Hit the p key while holding down the space bar. Select the entry Extract & DRC in the pop up menu. This command will first execute Sinix to produce an appropriate Core design and subsequently verify it. Upon termination the design rule violations will be visible as highlight rectangles in the ChipNDale design.

You may want to avoid the verification of certain cells. This can be achieved by assigning the property $DoNotDRC to such cells.

SoS also 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. If you want to make sure that your Core design contains all the geometry, you may want to set the variable SoSCommandImpl.debug to true during your development.

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.

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 "← SoSImpl.Debug[]" in the Command Tool, SoS will create a typescript viewer into which he keeps a log of the cells and wires analysed. If you also say "← SoSCommandImpl.Debug[]", SoS will verify that all ChipNDale objects are examined. If your debugging session extends over several rollbacks, you may want to remake the package with "SoSImpl.debug ← TRUE" and "SoSCommandImpl.debug ← TRUE".

Second case. a. Two rectangles violate a design rule but are not detected. Give to both instances of them the ChipNDale propriety $SoSBreak (command N-space). When they will be processed SoS will call the debugger when it comes to a point called probe 1 in procedure MaterialSeparation. 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 $SoSBreak. When you have examined a pair, simply press the button Proceed in the debugger viewer.

If SoS 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 SoSCommandImpl.mesa and set a break point after the line marked Probe 2 in procedure MaterialSeparation. 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.

If a design is specified and the ChipNDale cell containing the violation can be accessed, an error rectangle is inserted at the proper location. This allows to verify a Core cell which does not have a corresponding ChipNDale cell (depends on the version of Sinix). For debugging this can be a nuisance, therefore SoS can be made more persistent in finding correspondent ChipNDale cells by setting the variable SoSImpl.persist ← TRUE. (This is the default at the current time.)

Good luck !