Xic provides a number of internal rule evaluation functions, to be described in this section. These should cover basic and common design rules as published for a particular fabrication process. More complex rules can perhaps be accommodated with the user-defined rule capability.
Design rules are associated with Xic physical and derived layers. In the technology file, the rule definitions appear in layer blocks for physical and derived layers.
The rules, and derived layers, make use of layer expressions. A layer expression can be a single layer name, or a more complicated expression involving other normal and derived layer names. In a rule specification, the expression syntactically represents a single token, though the expression may include white space. The expression in the specification is parsed as far as possible (white space is ignored), and the rest of the line is taken as further input to the specification.
The result of the evaluation of a layer expression can be thought of as a set of geometric figures representing areas where the expression is true. Below are two example rule specifications that use layer expressions.
Overlap M1 | M2 #layer must be covered by M1 or M2
NoOverlap Via&!M1 #layer must never overlap Via without M1
Where a layer expression can be used, a derived layer can also be used. The examples above can be expressed alternatively using derived layers.
DerivedLayer m1orm2 M1 | M2
DerivedLayer vianotm1 Via&!M1
...
Overlap m1orm2 #layer must be covered by M1 or M2
NoOverlap vianotm1 #layer can't overlap Via without M1
Whether it is ``better'' to use layer expressions or derived layers in the rules is still a bit open, as derived layers are a new feature. There may be performance differences, as evaluation is quite different. In the case of derived layers, all geometry on the derived layers is computed before a DRC run, and cleared after the run. Thus, during rule evaluation, existing geometry is simply accessed. When a layer expression is used, the expression is evaluated in test regions while the rule is being evaluated. Thus, the expression requires evauation, over a tiny area, many times. It is not clear that one method or the other would be generally faster, users should experiment. Use of layer expressions may be preferred if memory is constraining, as the amount of memory required to save derived layer geometry may be substantial.
Use of derived layers may be required for certain types of rules. For example, suppose that we have a constraint:
(NP or PP) Enclosure of PO 0.15
What this means is that layers NP or PP must cover layer PO, with 0.15 microns distance surrounding PO covered by NP or PP. This translates directly to the MinNoOverlap rule, but applied on the layer combination NP|PP, which can be accomplished with a derived layer.
DerivedLayer implant NP|PP
MinNoOverlap PO 0.15 # (NP or PP) Enclosure of PO 0.15
Ordinarily, a design rule evaluation proceeds as follows. All evaluation is performed using a ``pseudo-flat'' representation of the cell hierarchy, which effectively translates the coordinates of every object in the hierarchy to the space of the top-level cell. Each object in this space can be tested without having to know which cell in the hierarchy actually contains the object. The ``global'' tests, that are not associated with individual objects, such as checking for holes, are done first. Then, the per-object tests are performed on each object in the pseudo-flat representation. For each object (box, polygon, or wire), each test listed for the layer of the object is run in sequence. The per-area tests, which are done first, are applied to the area of the object, and remaining tests are applied to constructed regions along each edge of the object.
Below are descriptions of the built-in design rule test functions, and the syntax used to specify the test in a layer block in the technology file. Each rule line starts with the defining keyword, followed by an optional Region expression, required parameters, and an optional explanation string.
If the Region keyword and associated expression are given in the rule specification, the source area becomes those regions where the expression is true, within the boundaries of the object. The per-area tests are applied to the areas where the expression is true, and the other tests are applied to the edges of these regions. In simple cases, the Region expression is not necessary, but it does provide additional capability for more complex testing.
Use of Region is very similar to defining the rule on a derived layer consisting of the original layer ANDed with the Region expression.
An optional descriptive string can follow the rule specification. This string will be saved and included in violation reports. It is a good idea start the explanation string (if any) with the script comment character `#' to guarantee termination of the preceding expression. Recall that white space is ignored when parsing the expression. Most of the time, the parser can recognize the end of the expression, so the comment character is not necessary, but it is possible that the explanation string might start with an operator token such as `*' or a reserved keyword such as ``not'', and the expression parse would fail.
For certain rules, the description may have multiple components, i.e., it actually consists of multiple strings. This syntax will be described below for the affected rules, but is amounts to simply double-quoting the individual strings. When constraints are imported from a Virtuoso ASCII technology file, there are occasions where multiple constraints, each with a description string, map to a single Xic primitive rule. These strings will be recovered when converting back to Virtuoso format with the !dumpcds command.
In the discussion that follows, the following definitions will be used. An ``object'' is a physical entity found in the database. A ``figure'' is a geometrical shape and an associated layer expression which is true within the shape. A figure can represent an object and the object's layer, for example, or one of the regions where a layer expression is true, and the layer expression. The ``source'' is a set of figures where rule evaluation is to be performed. If no Region is given, the source is simply the figure representing the object's geometry and the object's layer. Otherwise, the source is the set of figures where the region expression is true within the object. Two or more figures are ``compatible'' if they are associated with the same layer expression.