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. NCC annotation's are represented by attributes placed on cells (see Section 6-8-5). 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:

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.


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:

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 NCCs, it is ignored by flat NCCs.


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.


blackBox <comment>

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

The blackBox is useful when a particular arrangement of layout geometry implemements a construct that Electric doesn't understand. For example, we have used this construct to handle resistors and parasitic bipolar transistors in the layout.