For certain situations, NCC cannot figure out that two cells are equivalent unless the designer supplies extra information. The designer supplies this extra 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. The attribute's value is one or more lines. Each line contains 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, A{lay}, might export vdd, vdd_1, vdd_2, and vdd3. The designer expects the cell that instantiates A{lay} will connect all the vdd exports to a single net: vdd. 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.

NCC allows the designer to add the annotation: exportsConnectedByParent to the cell to inform NCC which exports will be connected by the parent. The keyword is followed by a list of strings and/or regular expressions. A string matches an export name exactly, for example: vdd. Thus A{lay} can contain the NCC annotation:

exportsConnectedByParent vdd vdd_1 vdd_2

Alternatively, the designer can use regular expressions. Regular expressions begin and end with the character: '/'. Thus A{lay} can contain the NCC annotation:

exportsConnectedByParent vdd /vdd_[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 NCC reports an error whenever that assertion isn't satisfied.

### skipNCC <comment>

The skipNCC annotation should be added to a cell, say B, when:

- B{sch} and B{lay} won't pass either flat or hierarchical NCC and
- you want any hierarchical NCC of the parents of B to flatten the one level of hierarchy: cell B.

If cell B has a skipNCC annotation, then a hierarchical comparison won't check B and will simply flatten through the one level of hierarchy: B.

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 cell B includes the NCC annotation:

skipNCC layout is missing ground connection

then NCC will print:

Skipping NCC of A because layout is missing ground connection.

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

The skipNCC annotation may be placed on any schematic or layout cell in the cell group. We prefer a 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, say B, if:

- B{sch} and B{lay} will pass NCC when compared separately but
- hierarchical NCC of a parent of B should not treat B as a hierarchical element but should, instead, flatten through B.

One reason for using this annotation is to correct errors made by the heuristic that determines which cells to flatten and which to compare hierarchically. For example, suppose that the schematics instantiate cell B{sch} 1000 times and the layout instantiates cell B{lay} 500 times. In principle one could use the flattenInstances annotation to inform NCC which instances to keep and which to flatten. However sometimes that's more work than it's worth and it's better to add a single notSubcircuit annotation to cell B{sch} or B{lay} to tell NCC to never treat B as a hierarchical entity.

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 may be placed on any schematic or layout cell in the cell group. We prefer a schematic cell because it's more visible to the designer.

### joinGroup <cell name>

The designer should add a joinGroup annotation to, say, cell B if NCC should behave as if cell B belonged to a different cell group and that cell group is in a different library. The cell group to move B to is that cell group that contains <cell name>. That specification should be fully qualified: library:cell{view}.

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 identical. Membership of two cells in the same cell group is one criteria NCC uses to decide that it should treat them as hierarchical entities and it should compare them separately.

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.

### transistorType<type>

All schematic transistors in this cell are of type: type. The type field may be one of the following: N-Transistor, VTH-N-Transistor, VTL-N-Transistor, OD18-N-Transistor, OD25-N-Transistor, OD33-N-Transistor, NT-N-Transistor, NT-OD18-N-Transistor, NT-OD25-N-Transistor, NT-OD33-N-Transistor, P-Transistor, VTH-P-Transistor, VTL-P-Transistor, OD18-P-Transistor, OD25-P-Transistor, or OD33-P-Transistor.

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 transistors from those special libraries.

### resistorType<type>

All schematic polysilicon resistors in this cell are of type: type. 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.

### forceWireMatch <wireName>

Force the wire in the schematic named wireName to match the wire in the layout named wireName .

The forceWireMatch 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 wires were intended to match. With luck, a strategically placed forceWireMatch 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 forceWireMatch annotations.

### forcePartMatch <partName>

Same as forceWireMatch except that this command works on parts rather than wires.

### blackBox <comment>

Don't compare the cells in this cell group; just assume they are topologically equivalent.

The blackBox 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 this assertion should the user make a mistake.

The blackBox annotation may be placed on any schematic or layout cell in the cell group. We prefer a schematic cell because it's more visible to the designer.