9-7: Network Consistency Checking (NCC) 9-7-4: Annotations

For certain situations, NCC cannot figure out that two cells are equivalent unless the designer supplies extra information. The designer supplies this information by adding NCC annotations to layout and/or schematic cells. This is done with the subcommands of the Tools / NCC / Add NCC Annotations to Cell menu.

NCC annotations are represented by attributes placed on cells. The attribute's name is NCC and it contains one or more lines of text, each with a separate NCC annotation. Thus, although a cell can have at most one attribute named NCC, that attribute can contain any number of NCC annotations.

exportsConnectedByParent <string or regular expression>

Layout cells sometimes contain multiple exports that are supposed to be connected by the parent cell. For example, a layout cell might export "vdd", "vdd_1", "vdd_2", and "vdd_3". The designer expects that instances of this cell will connect all the vdd exports to a single network. However, because the corresponding schematic cell usually only contains a single export, "vdd", the NCC of the schematic and layout cells fails. This situation is most common for the power and ground networks, although it occasionally arises for signal networks such as clock or precharge.

The Exports Connected by Parent vdd and Exports Connected by Parent gnd commands create this annotation which tells NCC which exports will be connected by the parent. The keyword is followed by a list of strings and/or regular expressions (regular expressions must begin and end with a '/'). These two example solve the problem, but the second example is more general:
    exportsConnectedByParent vdd vdd_1 vdd_2 vdd_3
    exportsConnectedByParent vdd /vdd_[0-9]+/

Note that any special characters inside of the regular expression must be quoted with a backslash. So, for example, to merge the exports A and B[0], B[1], B[2], ..., use this:
    exportsConnectedByParent A /B\[[0-9]+\]/

When NCC compares a cell with an exportsConnectedByParent annotation it performs the comparison as if those exports were connected. It is safe for NCC to believe this annotation because NCC also checks the assertion. When NCC encounters an instance of a cell with an exportsConnectedByParent annotation it reports an error if that assertion isn't satisfied.

exportsToIgnore <exportNames>

This annotation, created with the Exports To Ignore command, tells NCC to ignore certain exports in the cell. At the next level up, the equivalent ports on instance of the cell are also ignored, so the network connected to that port does not see the port or the instance. If the port is further exported up the hierarchy, the new export needs to be ignored and another exportsToIgnore annotation is required.

The exportNames field can be a set of names or a regular expression (surrounded by "/").

The annotation works only on the current cell (not any associated cells in the same cell group).

For example, suppose a layout cell has extra exports: "E1" and "E2" which do not exist in the schematic. This can happen when there are exports on dummy polysilicon. In the layout cell, add the annotation exportsToIgnore E1 E2. This will ignore the extra layout cells, and it will also ignore the use of these exports, higher up the hierarchy.

skipNCC <comment>

The skipNCC annotation should be added to a cell when:

• Its schematic and layout won't pass either flat or hierarchical NCC and
• You want a hierarchical NCC of the cell's parent to flatten the cell.

A common reason for needing this annotation is the unfortunate situation in which the exports of the schematic and the layout don't match. A skipNCC prevents NCC from reporting export mismatches because 1) The cell is not checked by itself and 2) When a parent of the cell is checked, the cell's exports are discarded because NCC flattens through the cell. Although not always possible, it's better to fix export mismatches, because fixing them will yield clearer mismatch diagnostics when there is a problem.

All the characters following the keyword to the end of the line serve as a comment. This is useful for documenting why this annotation was necessary. When you ask NCC to compare every cell in the design, NCC will tell you which cells it is skipping and why. For example, if a cell includes the NCC annotation:
    skipNCC layout is missing ground connection

then NCC will print:
    Skipping NCC of A because layout is missing ground connection.

The skipNCC annotation is created by the Skip NCC command and may be placed on any schematic or layout cell in the cell group. In general, it is preferable to place the annotation on the schematic cell because it's more visible to the designer.

flattenInstances <string or regular expression> ...

Hierarchical NCCs do not require a perfect match between the schematic and layout hierarchies. Instead, hierarchical NCC uses heuristics to determine which cell instances must be flattened and which can be compared hierarchically. The heuristic sometimes make mistakes. When that happens, the flattenInstances annotation can guide the heuristic.

The list of strings and/or regular expressions are used to match instance names within the cell. Those cell instances that match are always flattened.

notSubcircuit <comment>

The designer should add the notSubcircuit annotation to a cell if:

• The schematic and layout will pass NCC when compared separately but
• Hierarchical NCC of a parent of the cell should not treat the cell as a hierarchical element but should, instead, flatten it.

When hierarchical NCC encounters a notSubcircuit annotation it prints a message that includes the comment in a manner similar to skipNCC.

The notSubcircuit annotation only affects hierarchical NCC; it is ignored by flat NCC.

The notSubcircuit annotation is created by the Not a Subcircuit command and may be placed on any schematic or layout cell in the cell group. In general, it is preferable to place the annotation on the schematic cell because it's more visible to the designer.

joinGroup <cell name>

Memberships in cell groups is important when NCC performs hierarchical comparisons because NCC assumes that cells in the same cell group are supposed to be topologically equivalent.

Occasionally it is impractical to place the layout and schematic views of a cell in the same cell group. For example when layout is automatically generated from hand drawn schematics it may be better to place the layout in a different library than the schematics.

The designer should use the Join Group command to add a joinGroup annotation to a cell if NCC should behave as if that cell belongs to a different cell group (which may be in a different library). The cell group to move the cell to is the cell group that contains the cell named in the annotation. That specification should be fully qualified: "library:cell{view}".

transistorType<type>

This annotation, created with the Transistor Type command, changes the nature of transistors in the cell. The type field has the following structure:
   <MOSOPTION>nMOS-<STYLE>transistor
   <MOSOPTION>pMOS-<STYLE>transistor
   NPN-<STYLE>transistor
   PNP-<STYLE>transistor
   n-type-JFET-<STYLE>transistor
   p-type-JFET-<STYLE>transistor
   <STYLE>depletion-mesfet
   <STYLE>enhancement-mesfet

   <MOSOPTION>: <blank> | depletion- | native- | floating-gate- | carbon-nanotube- | low-threshold- | high-threshold- |
         high-voltage-1- | high-voltage-2- | high-voltage-3- | native-high-voltage-1- | native-high-voltage-2- | native-high-voltage-3-

   <STYLE>: <blank> | 4-port-

So, for example, you can have a "high-voltage-1-nMOS-transistor" (typically a 1.8 volt transistor).

resistorType<type>

This annotation, created with the Resistor Type command, changes the nature of all polysilicon resistors in the cell. The type field may be one of the following: N-Poly-RPO-Resistor, N-Poly-RPO-Resistor, P-Poly-RPO-Resistor, or P-Poly-RPO-Resistor. Unlike all other resistors, polysilicon resistors are not treated as short circuits by NCC. Instead, NCC tries to match these schematic polysilicon resistors with layout polysilicon resistors.

Warning: This annotation is used very infrequently. Typically it is used only inside special libraries such as the "red" library (see Section 9-9). Most designers simply instantiate resistors from those special libraries.

forcePartMatch <partName>

This annotation, created with the Force Part Match command, forces nodes with the given name in the schematic and layout to be associated. This annotation is useful when local partitioning fails to detect a mismatch but hash code partitioning does. In that case forceWireMatch can be used to tell NCC that certain node were intended to match. With luck, a strategically placed forcePartMatch can cause NCC to display fewer hash code mismatches and help the user narrow in on the actual error.

After fixing the problem, you should try to remove all forcePartMatch annotations.

forceWireMatch <wireName>

Same as forcePartMatch except that this command works on wires rather than nodes.

blackBox <comment>

This annotation, placed with the Black Box command, tells NCC to ignore the cells in this cell group and assume they are topologically equivalent. This annotation is useful when a particular arrangement of layout geometry implements a construct that Electric doesn't understand. For example, to handle resistors and parasitic bipolar transistors in the layout.

The blackBox annotation should be used with care because, unlike the other annotations, NCC has no way of double checking the assertion to insure that it is correct.

The blackBox annotation may be placed on any schematic or layout cell in the cell group. In general, it is preferable to place the annotation on the schematic cell because it's more visible to the designer.

Previous

Table of Contents

Next