Checking Magic Cells

A unix script program is available to perform basic checks on magic cells.

The syntax for use of the script is:

    check_magic_cell [-v] [-q] [-T <tech>] [-M <n>] <cellname>

    check_magic_leaf_cell [-v] [-q] [-T <tech>] [-M <n>] <cellname>

options:

For example typing

    check_magic_leaf_cell -v -T c35b4 -M 1 inv

will check the magic leaf cell inv (in the file inv.mag) assuming that the cell uses just one metal layer and that the c35b4 technology is used. Verbose status information will be given during the execution of the script (without the -v option, very little status information is given making it easier to identify the warning and error messages).

The checks performed by the script are detailed below:

File Checks

Before performing any other checks, the script will check that the <cellname>.mag file is a magic file with the correct technology and that it has not been obviously corrupted. The most common corruption is the inclusion of DOS format control characters caused by the mailing of magic files using PC based mail programs like Microsoft Outlook.

Should you believe one of your cells to be corrupted in this manner, you should be able to recover it using the following command:

    dos2unix  <cellname>.mag  <cellname>.mag

Origin Check

The script will check that the lower left hand corner of the cell is at position (0,0). Cells without their origins at (0,0) will work well in magic but cannot be ported easily to other layout tools such as Tanner L-Edit.

In some cases the nwell layer may overlap the bounding box of the cell, under these circumstances the nwell layer will be ignored when performing this check.

Sub-cell Check

If the script is invoked as check_magic_leaf_cell, it will check that no sub-cells are used in the cell.

Simple Label Checks

• I/O not aligned

  The I/O must be aligned along the edge of the cell. The figure below shows the in and out signals at the top of the cell at different heights:

  

• I/O labels must be correct shape

  I/O labels must be line labels in order to support automated routing.

  In the figure below the out label is a box label:

  

  In the figure below the out label is a point label:

  

  Note that internal labels (not along the cell edge and not used for routing) must be point labels. These labels have not been used in the example inverter design.

  

• Label in wrong place

  In each of the following figures, the label for the out signal is misplaced.

  In the first case, the label is not at the end of the polysilicon and hence does not line up with the edge of the cell:

  

  In the second case the label is floating free of the polysilicon (it is described as a label on a virtual mask layer named "space"):

  

  Although in the third case there is a partial overlap between the label and the polysilicon this is not sufficient to anchor the label so the again the label is considered to be on the "space" layer:

  

• Label for I/O too narrow (less than minimum width)

  Labels must be at least as wide as the minimum conductor width in order to support automated routing.

  The figure below shows the out label is not as wide as the polysilicon conductor to which it is attached:

  

• Signal I/O too wide (not minimum width)

  For inter cell signal routing, minimum width tracks should be used. Although this results in increased track resistance this is more than offset by the reduction in the track capacitance. For this reason signal I/O connections are checked for minimum width.

  Note that this restriction is not applied to power/ground I/O connections since we expect wider tracks for these (increased track capacitance is beneficial for power/ground but detrimental for signal wires).

  In the figure below the out connection is too wide:

  

Label Conflict Checks

• Unconnected Nodes With The Same Name

  Where two identical labels are connected to two different nodes in a leaf cell, the magic extraction tool will flag a warning. For hierarchical cells this may not represent a problem but for leaf cells the most likely causes are an unintended open circuit or a misplaced label. For this reason the script rejects cells that include this type of label conflict.

• Multiple Names For The Same Node

  This situation is not considered as an error by the magic extraction tool since it assumes that the names represent different aliases for the node. Unfortunately the concept of node aliasing is not portable between CAD tools. For this reason and to avoid overlooking an unintended signal short, the script rejects cells that include this type of label conflict.

  Note that labels are case sensitive so a node labelled Out in one position and out in another represents a label conflict.

Label Layer Checks

• Designs with just One Metal Layer

  For designs with just one metal layer (as indicated by the -M 1 option on the command line), the script checks that vertical I/O is in polysilicon and horizontal I/O is in metal1:

  

• Designs with Two Metal Layers

  For designs with two metal layers, the script checks that vertical I/O is in metal2 and horizontal I/O is in metal1:

  

Label Layer Confusion

Where a label overlays more than one layer, it is not obvious which layer was labelled. In the figure below the label sig1 may be on the metal1 layer or the metal2 layer:

Where a label overlays multiple layers, magic will tell you which layer is labelled when you create it. For example in response to the :label sig1 command it may respond Moving label "sig1" from space to metal2 in cell xxx. If you would rather the label was placed on another layer you will need to specify the text position and the layer in the label command. Hence :label sig1 down metal1 will cause the label to be placed on metal1 rather than metal2 with the text positioned below the label anchor.

To avoid confusion, it is best to place labels in positions that overlay only one layer:

Sometimes it is not possible to place a label over just one layer. This is the case in the figure below where the Vdd! label overlays nwell and metal1:

Where the wrong layer has been labelled it is likely to be picked up by either the label layer checks or the label conflict checks performed be the script.

Required Items Checks

• Power/Ground Label Checks

  The script expects all cells to have horizontal power and ground rails. It will reject the cell if it doesn't find horizontal I/O labels for Vdd! and GND! (remember it is case sensitive; Vdd! ≠ VDD! and you can't miss out the exclamation mark).

• Well and Taps

  Where transistors exist within a cell, the script expects an explicit n-well and at least two taps, one for the n-well and one for the p-substrate.

Correcting Labels

Although magic labels can be selected using area select and then moved to another location using the standard move and stretch commands, magic does not provide facilities to edit the shape of a label or its text. For this reason the only solution for a label with the wrong shape or wrong text is to delete it and create a new one. It is possible to delete only the labels in the area under the box (leaving the paint intact) by using the :erase label command.

Remember that the label command allows you to specify the position of the label text (e.g. up down left right) and the layer to which the label will be attached. The arrangement of square brackets [] in the label command syntax below tells us that both position and layer are optional parameters, but layer cannot be specified without position:

    :label <labelname> [<position> [<layer>]]

If labelling seems to be taking up too much time, the netlist menu window, documented in Magic Tutorial #7: Netlists and Routing, provides a number of more advanced facilities and is particularly useful where bus signals are to be labelled.