Note: Descriptions are shown in the official language in which they were submitted.
-
CA 02224588 1997-12-12
W O 96/42060 PCTrUS96/10275
Descri~tion
Method and Apparatus for Point T~n~m~k Design
0~ Integrated Circuits
Reference to Provisional A~plication
This application claims the benefit of U.S. Provisional
Application ~o. 60/000,159, filed June 12, 1995.
Technical Field
o The present invention relates to methods and apparatus for
using point lAn~m~rk for integrated circuit design.
S~mmary of the Invention
In accordance with a f ir8t embodiment, the invention is a
method for designing an integrated circuit ha~ing a plurality of
features defined on a plurality of layers on the surface of a
substrate. The features are taken from a set of possible feature
types and are subject to a set of de5ign rules as50ciated with a
process technology. The design rules specifying physical
requirements among the m~mhers of the set of possible features.
The method comprises the steps of: a) associating at least one
feature point with each feature in the plurality of features; b)
associating additional infonmation with each feature point, the
information including a list of attributes associated with the
type of the feature, each attribute in the~list of attributes
having a ~alue, and c) preparing a list for each of the
attributes a~sociated with a feature point that is associated
with each feature in the plurality of features, the list
including the values of the attributes. The method further
includes the steps of d) associating at least two constraints
~ with each feature point, e) associating additional constraint
information with each constraint, the constraint information
SUBSTITUTE SHEET (RULE 26~
CA 02224~88 1997-12-12
~ ~W O 96/42060 PCTAUS96/1027~
includi~g a list of constraint attributes as~ociated with the
~ype of the constraint, each attribute in the list of constraint
attributes having a value. and f ) preparing a list for each of
the constraint attributes associated with a constraint that is
associated with each feature in the plurality ol~ features, the
list including the value5 of the constraint attribute~. Further,
the invention includes the step of g) per~orming operations on
each of the lists, the operations correspon~; n~ to constraint~
in the design rules, and the results of the operations being
o relative geometric plac~m~nt of the feature points.
In accordance with another a~;pect, the inv~nt~ Qn iS an
apparatu~ for designing an integrated circuit ha~ing a plurality
of features de~ined on a plurality of layers on the surface of a
substrate. The ~eatures are taken from a set o~ possible feature
S types and are subject to a ~et o~ design rules associated with a
process technology. The design rules specify physical
re~uirenents among the members of the set of possible features.
The apparatus includes first, second, third, fourth, fifth,
sixth and seventh circuit means. The first circuit means is for
associating at least one feature point with each feature in the
plurality of features. The second circuit means is for
associating additional information with each feature point. The
information includes a list of attributes associated with the
type of the feature, each attribute in the list of attributes
having a value. The third circuit means is for preparing a list
for each of the attributes associated with a feature point that
i8 associated with each feature in the plurality of features.
The list includes the values of the attributes. The fourth
circuit means is for associating at least two con~traints with
each feature point. The fifth circuit means is for associating
additional constraint information with each constraint. The
constraint in~ormation includes a list of constraint attributes
SUBSTITUTE SHEET (RULE 26)
CA oi224588 1997-12-12
W O 96/42060 PCT~US96/10275
associated with the type of the constraint. Each attribute in
the list o~ constraint attributes has a value. The sixth circuit
means is for preparing a list for each of the constraints
attribute~; aF2sociated with a constraint that i8 as80ciated with
s each feature in the plurality of features, the list including
the values o~ the constraint attributes- The a 8eventh circuit
means i8 for performing operation~; on each of the lists. The
operations correspond to constraints in the design rules, and
the results of the operations are relative geometric rl Ac~~ent
o of the feature points.
Brief Description of the Drawinqs
Figure 1 is a schematic diagram of a portion of the method
of the present invention.
Figure 2 i8 a schematic diagram of a portion of the methodL
of the present invention.
Figures 3A-B are schematic diagrams of a portion of the
method Of the present invention.
Figure 4 i8 a schematic diagram o~ a portion of the method
20 of the present invention.
Figure S is a schematic diagram of a portion of the method
of the present inventlon.
Figures 6A-B are schematic diagrams of a portion of the
method of the present inv~t; on,
2s Figures 7A-C are schematic diagrams of a portion Of the
method of the present invention.
Figures 8A-B are schematic diagrams of a portion Of the
method of the present invention.
Figures 9A-B are schematic diagrams of a portion Of the
30 method of the present invention.
Figures lOA-B are schematic diagrams of a portion of the
method of the present invention.
SUBSTITUTE SHEET (RULE 26~
CA 02224588 1997-12-12
r
W O 9~42060 PCTAUS96/10275
Figure 11 is a schematic diagram of a portion of the method
o~ the present in~ention.
Figure 12 is a ~chematic diagram of a portion of the method
of ~he present invention.
sFigure 13 is a schematic diagram of a portion of the method
of the present invention.
Figures 14A-B are schematic diagrams of a portion of the
method o~ the present invention.
Figure 15 i8 a schematic diagram of a portion of the method
o of the present invention.
Figures 16A-B are schematic diagram8 o~ a portion of the
method of the pre~ent invention.
Figures 17A-B are schematic diagrams of a portion of the
method of the present invention.
15Figures 18A-B are schematic diagrams ol~ a portion of the
method of the present invention.
Figures l9A-D are schematic diagrams o~ a portion of the
method of the present invention.
Figure 20 is a schematic diagram of a portion of the method
of ~he present inv~nt~n .
Figure 21 is a schema~ic diagram of a portion of the method
of the present invention.
Detailed De~cription of the Preferred Em~o~jment of the
Invention
Al.O In~roduction
In the old lAn~m~rk-based methodology, there wafi a trade-
off to be made between having too-many and too-few l~n~m~rk~. If
30 there were too many, the cell would be di~ficult to debug in
SUBSTITUTE SHEET (RULE 26)
CA 02224588 l99i-l2-l2
r ~
W O 96/42060 PCTAUS96/10275
Iview. If there were too few, then the l~n~m~k equations would
become complicated and it was easy for them to be incorrect.
The point-lAn~ks approach is an attempt to automate the
proce~s o~ coming up with correct equations. In this approach, a
s new structure (the ~point" l~n~-~k) is used to identify box
corners and wire points. These point l~n~m~rks have both an X
and a Y location which makes it possible to have more of them
without cluttering up the display.
Instead of lAn~m~rk equations, constraints are u~ed betwee~
o point-lAn~-rks. The constraints specify information about the
relationship between the two points, but the value of the
constraint is usually calculated automatically.
A2.0 Points
Points are used to represent geometry el~m~nt~ (wires,
boxes and polygons). The point must ~ont~;n information about
the type, layer, extension and nodes as indicated in table 1.
This information is used to calculate diStAnc~ for constraints
( instead of having the designer specify explicit equations).
Boxes require two points (in opposite corners), polygons
require a point in each corner, and wires require a start-point
plus one point for each segment.
In addition to simple geometry, points can be used to
represent the various types of cont~cts and vias that are
created in CDS. These contac~s and vias are considered to have
geometry on three layers - the cont~ct or via layer plus the two
layers being connected.
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
- ' W O 96/42060 PCT~USg6/10275
Tablel:
l~pe I~thep~ntaun~ ce~ora~edge
Lay~ Thelay~thatthe~ ~y ~onorthe
~ypeofcontQ~ or~athatthepo~nt
F.~ Thed~nn(~) t~stthe~i----l~
. '-fi~m thepo~
Node ~,l~ lnodethatthepo~t~on
A3.0 Constraint~
Constraints have a reference point, a target point, a
direction, type and link. These will be explained below.
A3.1 Reference and Target
The target is the point that the constraint applies to. The
reference is the point that the target is being spaced away
o from.
A3.2 Direction
The direction specifies the orientation of the target with
respect to the reference. For example, the constraint might
lS specify that the target point is north of the reference point.
A3.3 Type
Se~eral types of constraints are aVA; 1 ~hl e for specifyi~g
the relatinn~h;p between points. The type affects how the
dis~ance is calculated. If a constraint is a "side" constraint,
the distance is the basic manhattan distance that is required by
the design rules. If the constraint is a "corner" constraint in
the X-direction, then the Y-coordinates of each point will be
taken into account in order to come up with a Pythagorean
distance for offsetting the two points.
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
,
W096/42060 PCT~S96/1027s
Default constraints will try to act like side constraints,
but when a lot of default constraints are used a cycle can occur.
where it is necessary to know the X coordinate of a point be~ore
its Y coordinate can be calculated yet its Y coordinate is also
dependent on X. When this occurs, the solver will pick one o~
the default constraints and treat it as a side constraint.
Delta constraints allow user-speci~ied values to be used
instead of the ~n;~-lm space dictated by the design rules.
Alig~ constraints specify that two points ~ho~ be aligned
o in X or Y.
r~nn~t constraints are used to speci~y the c~nn~ction
between a narrow wire and a wider wire or ront~t. They allow
the wire to slide from one side of the ~Qnt~ct strip to the
other as long as the connection is ~ully maintA; n~,
l~ble 2: Constraint I ype~
Side Basic l-~lim~ cv ~ t.
Con~er Cor~er cv~sL~ u~e the
~,~ll~ov~ LL~~ ~ifnrE-lirPl '~ when
~lrt~.. ;.. ;.~g 'che .l;cl .. ~
Default ~ to act as a corner cc~L~t,
but can be 8- i~ed to a side c~ Y I P;~t
if ~ oc~ to break a cy~le.
r.~ thatthe points share the same
X or Y c~ Le.
Del~a A side ev~L-~t with a user-~e- :
value.
Cnnn~ C~ t used for c ~ P~ vnres to
r....,lD 1~,
Origin U~ed to 8pet~ onigir~point.
.
A3.4 Link
SUBSTITUTE SHEET (RULE 26
CA 02224588 1997-12-12 ' --
W O 96/42060 PCTrUS96/10275
The constraint link is used to speci~y what happens to the
reference point after the target is used. Often, a point will
move ~urther than a constraint requires. (This is generally due
to the presence of other constraints). often, it is desirable to
keep the two points close together, for example the gate of a
transistor should usually stay close to the drain if possible.
This can be done by making the constraint an "attachl~
constraint. After a point is moved, an atte~pt will be made to
pull all attached references towards it as much as possible.
A weaker version o~ the attach link is al~;o av~ ble and
is called "attractn. I~ a reference is attracted, it will be
pulled in the direction o~ the attract, but only as far as it
can go without rl~hing anything else away or causing constraints
to be violated. The attach will actually push things along with
it if necessary.
The most co~mon link is "~ree". Constraints with this; link
do not have any effect on the reference point.
Iable~:G~ nks
:Free The ~ef~ca point is ~ <1 by this
~ttach The ~ ,e point should 'oe mwed as
close a8 poq~ihle ts~ the target point,
even if other points have to be moved as
well.
~ttract The .~f~cc point should move toward
the target point, but should not csuse
other points to be mo~red. This m~e-
- ment is done after all c~L~ b have
been evS~ t~
A4.0 Solving Constraints
A4.1 How constraints are organized
--8--
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 l997-l2-l2
~YO 9Ct~:-C60 PcTlus96/1027
The constraints are all grouped according to their
direction and target point and whether they are an align
constraint or not. For each point, there are four lists of
constraints, X, Y, X-aligns and Y-aligns. A master list i8 also
created which cont~;nR each of these lists.
~4.2 Evaluating a constraint list
Constraints are evaluated in groups. When all of the
constraints in a list are ready to be evaluated, the evaluation
is done and the m~ m value is chosen. The requir~m~nt~ for
o whether a constraint is ready to be evaluated ~r~nA on whether
it is being treated as a corn~ or a side constraint. A corner
constraint in an X direction requires that the X and Y
coordinate of the reference point and the Y coordinate of the
target point be known. A side constraint in the X direction
would only require the x coordinate of the reference to be
known.
~lign constraints have no target only a reference. When all
of the references in the list have known values, the alignment
can be per~onmed.
~4.3 Order of evalllAt;on
The order that the constraints are evaluated is arbitrary.
The lists of constraints are themselves part of a master list.
This master list is traversed in order to find the constraints
which can be evaluated. The first constraint that will be
evaluated will be the origin constraint since it has no
references to wait on. Next, any points which ~ep~n~ only on
that point will be ready to be evaluated, then points which only
depend on those, and so on. When the end of the list is reached,
another pass will be made.
On each pass, the algorithm keeps track of whether any
constraints were evaluated. If none were, then a cycle is
present and it is necessary to pick a default constraint to
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
W O 96t42060 PCTAUS96/10275
evaluate as a side constraint. This is also done in an arbitrary
way and it might be better in the ~uture to investigate ways to
add some intelligence to this choice. Each time the algorithm
gets ~tuck, one de~ault constraint will be switched. Eventually
it will be able to continue.
A4.4 Attaches
A~ter a point's location is calculated, an attempt will be
made to resolve any constraints which had an attach link. There
o are additional considerations which make the handling of
~att~ch~s fairly complicated. Sometimes attaches will con~lict
with each other as shown in Figure 1.
In Figure 1, the bold lines represent attach constraint~
and the numbers indicate the spacing value for the constraint.
If point P3 i8 pulled up to P2, the distance from P1 to P4 will
be 5 - 2 + 5 or 8 units. The attach from Pl to P4 is trying to
keep the distance down to 6. For this to occur, the space
between P3 and P2 should be 4. This conflict is resolved by
giving priority to the attach ~rom Pl to P4 because a path can
be îound from P1 through P2, through the attach to P3 and up to
P4. The attach between P2 and P3 cannot be processed until the
location of P4 is known.
A4.5 Attracts
After all of the constraints have been processed, the final
step is to move points which are attracted. For each point that
has an attract constraint, all of the constraints which use this
point as a re~erence are analyzed to see how much slack they
have. This includes corner constraints which are in the other
~;men~ion. After determining how far the point can move without
causing any constraints to be broken, the point is moved.
-10-
SUBSTITUTE SHEET (RULE 26)
CA oi224588 1997-12-12
WO 96/42060 PCI'/US96/1027~i
In the case o~ points which are aligned and attracted, each
point in the align is analyzed to see how far it can move in
that direction.
If any point is the target of an attach constraint, it will
5 not be allowed to move. This may be overly restrictive since it
might be okay to move such a target i~ the corresponding
reference can also be moved. In the future the algorithm should
be ~nhA~A to take this into account.
The difference between attracts and attaches i8 shown in
Figure 2. On the left, three points are shown. The locations of
P2 and P4 are set by constraints which are not shown (the
constraints shown are not critical constraints.) If P3 is
attracted to P4, it will move up until the constraint ~rom P3 to
P2 becomes critical (as shown in the middle diagram). It will
15 not cause P2 to move. If P3 is attached to P4 it will push P2 up
as shown in the diagram on the ~ight.
A4.6 Calculating constraint ~alues ''
Constraint values are calculated at run-time based on the
zo point types. In~ormation about extension directions and overlap~
i8 taken into account to deter,mine how far apart the points need
to be. The exception to this is delta (user) constraints where
the value i5 user specified.
25 A5.0 Future RnhAnc~ment8
A5.1 Grid Snapping
There is currently no way to snap ports or other geometry
to a user-defined grid.
AS.2 45-degree geometry
A5.3 Halation checks
A5.4 Performance imp.u~ ts
-11-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
WO 96142060 PCT~US96/10275
As part of the productization effort, ways to make the
evaluation more efficient should be investigated.
B. Introduction to the CDS Point T.~n~mArk Design Methodology
Overview
This document describes some of the features of the point
1~n~m~rk design metho~ology and its ad~antages over the
10 con~rentional method of defining and using lAnAm~rkF:. It i8
assumed that the reader is familiar with the current method of
geometry generation and lAn~m~rk definition.
Introduction
A conventional lAn~m~rk consists of an integer value
representing an x or a y location. There is no other information
associated with the l~n~m~rk, except ~or possibly a string
representing the l~nAm~rk name. If a lAn~m~rk could indicate
20 what type of geometry it represents, then, given two lAn~lm~rks,
it is possible to determine what the m;n;Tn-lm required spacing is
between the two lAn~mArkS.
A one-A;m~n~ional lAn~mArk may partially represent the
location of one or more geometry items, but cannot fully
25 repre~ent the location of a geometry, since a description of a
location requires ~alues in two ~;m~nsions. Because of thi~, a
two-~;m~n~ional lAnAm~rk point can better represent the geometry
it is attArh~A to. This is the main premise for the point
lAn~m~rk design methodology.
Given the location of a lAn~mArk the geometry, it can be
determined just how close in any direction another lAn~m~rk
point, with its geometry i~em type and node, c; east, of the
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
' W 0 96~42060 PCT~US96/lOt75
first point, a routine can easily check the geometry item type
of each point, and return the required x position for the second
point. If the y position of the second point is already known,
then the routine can ~o~r~e the y values of the two points,
and, if they are far enough apart, return a value that
represents ~no constraint' ~or the x position of the second
point. If the y values indicate that the point l~n~ k~: are in
a diagonal con~iguration, then the Pythagorean theorem may be
applied to determine the closest po5sible x value for the second
o point.
With point lAn~m~rks representing geometry locations
instead of independent x and y lAn~mArks, several of the
geometry generating c~mm~n~ may be simplified~ For ~A~rle, the
box routine can be rPplA~e~ with a routine that requires only
S two argllnsnts instead of four. It could even check what type Of
geometries are being represented by the two points in the
argument list, check the current drawing layer, and determine
the required overlap Of the drawing material o~er the point
l~n~-~ks.
This design meltho~lology should shorten the learning curve
for a new CDS user. Since there are no micros or macros required
in the user' 8 module code, ~che user would not have to become
familiar with them. Instead, the user would need to become
familiar with the list Of geometry item types. The current list
0~ micros and macros total up to around 290, where the list of
geometry item types is expec~ed to be around 30. It is typically
easier to ir~ tify a geometry item, such as a poly-metal
contAct, than it is to identify the spacing between two geometry
items (ac2pyc, or is that ac2pycm, or ac2pycmd...). Since there
would be less material for a new user to learn, and it being
more straightforward, a new CDS user should be able to have
-13-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT/US96/10275
working code in less time using this method than that of the
current l~n~m~rk generating methods.
DRC errors are often due to missing micros or macros in a
l~n~m~k calculation of the module compiler code. Typically
these errors are not detected earlier because they are depPn~.Qnt
on the current ruleset. If a carefully written routine is
calculating the required spacing, all 8pacing requirPm~nts for
all rulesets would be taken into account. Even if one instance
was overlooked, one change to the spacing routine DRCs of one
o type in the whole module library.
Point Structure
The definition of a point consists of its name, the point's
X and y values, its item type (i.e. PYC), its extension
directions (a poly-metal contact has extensions in the direction
of metal~, ts widt.h (if representing a wire), and its
electrical node name. This information might be kept in a
structure that would look like:
typedef struct xpointstruct
{ - char name[16];
INT32 a, y;
' INT32 item;
INT32 width;
char ext_dirt5];
char nodetl6];
} POINTRECORD;
Additional information that may be considered as part of
the structure definition would include a pointer to the next
point structure for the creation of a linked list, and
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
,W O 96/42060 PCT~US96/102
placeholders for line_of_code f~ilename and line number
information might look something like this:
PointA = DEF_POINT("PointA", PYC, "NE", nodel~);
The macro would first allocate space for the point
structure with PointA being the pointer to the struct~re, strcpy
"PointA" to the name element, initialize the x and y values of
the structure to UND~:~'lN~:V, ~et the item element to the number
o representing PYC (the items are in an ~n~lme~a~ed listl~ and
strcpy "NE" into the ext_dir element and "nodel" into the node
element. PointA would have previously been def-ined as a pointer
to a structure. If a point represents a wire with an ar~itrary
width, a macro such as the following might be used to specify
the width of the wire:
Pwidth(PointA, railSize);
Directional Functions
The directional functions would be the basic bn;l~; n~
blocks for the design metho~ology. The location of new points
would be determined by the relative direction from other points.
For example, PointA would be east of Points (see Fig 3A). If a
point is constrained by more than one point, the loc~tion of
PointA might be de~ined as north of Points and PointC (see Fig.
3B). When more than one constraint is specified, the worst case
constraint would be used.
The C source code calls to the routines would look like:
east(PointA, 1, PointB);
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~W O 96/42060 PCT/US96~10275
north2(PointA, 1, PointB, PointC);
The first argument is the pointer to the point structure to
be modified (the x value is modified in the routines east and
west, the y value in north and south). The next argument is the
priority on the constraint (lower numbers have higher priority -
see section on Symbolic Constraints), followed by each of the
pointers to the reference point structures. The routines would
return an INT32 value (the x or y calculated value) so that they
o would be compatible with the existing lAn~m~k design methods.
An ~Ample showing how the returned value might be used is shown
here:
,
x2 = east(PointA, 1, PointB);
An advantage of using a point as a constraint to another
point vs. a one-~;m~n-~ional l~n~rk constrained by another, is
that the absolute distance between the represented geometries
can be calculated. With a geometry attached to a one-~;mPn~ional
lAn~lm~rk, say in the x direction, it is constrained only by the
x location of its constraining geometry not the absolute
distance. The y values of the geometries may be very far apart,
and, without some if-then type checking, unnecessary space may
be wasted between the geometries. In the routines north, south,
east and west, as the point being set is compared to each of i~
cons~raining points, both the x and y values of the constr~;ni~
points are checked, and the point is placed as close as
possible. If the opposite value distance (y distance for the
east or west routines) is large enough to avoid any possible
spacing problems, the value returned is set to NO WNS1~AINT. If
the routine returns NOCONSTRA1NT after checking all the
-16-
SUBS~ITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~VO 96/42060 PCTAUS96/10275
constraining points, then the returned value may be set equal to~
the value o~ the m;ni~ll~ or m~imllm constraining point.
Besides doing the st~n~rd spaCing checks, the directional
routines may also be able tO handle special cases. For example,
if the location of a metal-active contact (MAC) is being
calculated with respect to another MAC, it can be determined if
the MACs are on the opposite sides of a poly gate as part of the
same ~ransistor. If the extension directions of the active
within the two MACs are toward each other, and the electrical
o node names are di~ferent, then the MACs are most likely parts of
the same transistor, and all of the rules ~or two MACs that are
adjacent to a poly gate can be applied (See Fig. 4).
So~e lAn~k~ are determined by electrical constraints
rather than physical constraints, so routines s;m;l~r to those
described above could be written, but with a transistor size
argument:
tEast(PointA, PointB, Wn);
In the above example, the routine tEast sets the x element
o~ the structure pointed to by PointA to be the proper spacing
~rom Points to create a horizontal n-ch~nn~l transis~or with a
width o~ Wn. If the item types of PointA and Points were metal-
active contacts, the routine could subtract the appropriate
25 overlap of active-over-cont~ct distance duriny the constraint
calculation (see Fig. 5). The routines tNorth, tsouth, and tWest
would also be aVA; 1 ~hl e.
Arbitrary spacing values may be required in certain
circumstances, such as pitch-matching metal routes to another
30 cell, or setting a stAn~d cell height. A routine that would
allow a user to specify the distance or delta between points
-17-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
' W O 96142060 PCTrUS96/1027~
might look like: the distance or delta between points mi~ht look
like:
dWest(PointA, Poin~B, v2v);
In the abo~e example, the routine dWest sets the x element
of the structure pointed to by PointA to be the distance v2v
(via to via spacing) to the left o~ PointB. This routine would
o only apply the distance in orthogonal directions, not
diagonally. The routines dNorth, dSouth, and dEast would al~o be
avA;~Ahle
St~nAArd cells ha~e a unique spacing constraint in that any
geometries close to the left or riyht edges o~ the ell must be
spaced far enough ~rom the edge 80 that another 8t~nA~rd cell
may be placed beside it and all spacing requirements between the
geometries of the cells be met. Typically this is done by
calculating a l~n~rk using a number of calculations cont~; n; ~g
many micros and macros in the module code. If a lAnA~rk is
associated with the edge of a st~n~ ~d cell, then any l~nrlm~k~
representing geometries inside of the cell can use that l~n~m~k
as a constraint, and their loca~ion be appropriately calculated
by the east or west routines.
,
Symbolic Constraints
The constraint equations, or routines, such as east, dWest,
tNorth, etc., may be defined (speci~ied) so that they e~aluate
as they are executed (during run time), or they may be de~ined
as being symbolic, where an entry is made in a table during
execution, and later e~aluated. Each approach has its advantages
and disadvantages.
-18-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
~W O 96/42060 PCTAUS96/10275
If the constraint equations are e~aluated as they are
execu~ed, then the location of each point is available
~ tely after execution. But this requires that the order of
the constraint e~uations in the module source code be determined
by the order that they are to be evaluated, which is equivalent
to our current method of defining l~n~m~rks. This may not be
advantageous in cases where design flow is different than
constraint flow. If constraint equations are place out-of-order
in the source code, an error will result when a constraint
o function tries to reference a point with an undefined
coordinate.
If the constraints are made symbolic with evaluation taking
place at a later time, then l~he ordering of the equations in the
source code is less critical. The constraints may be e~aluated
in an order based on a priority tag or number (one of the
a~y~e~t~ to the equation). Even if the priority numbers are no~
used, or are in an invalid order, during evaluation, if a
constraint is referencing a point with an undefined coordinate,
the constraint may be 'put on hold' until all of its reference
points are defined, and then later evaluated. The user would
have ultimate control as to the evaluation order, first by
ordering the constraint equations as desired, then by
prioritizing the constraints with a tag or number, which would
override the ordering. The disadvantage to the symhol method is
that the location of the points are not ;mm~ tely avA;lAhle
for use in something like a conditional statement. Often times a
series of constraints are dependent upon the outcome of a
comparison of previously defined constraints, but since the
constraints are later evaluated, this information is not
available. A work-around to this problem would be to give the
user a function that evaluates the constraints defined so far.
This method would require that enough constraints are defined to
- 1 9 -
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
t WO 96/4~060 PCTAUS96/10275
determine the location of the desired points. Routines called
xEval and yEval could be defined to evaluate all of the
constraints defined so far, check to see if the desired point is
defined and, if so, return its x or y location - otherwise
return an error. An example of how the xEval routine might be
used is shown here:
if (xEval(PointA) < xEval(PointB)) {...
o In this example, the xEval routine would evaluate all of
the previously specified constraint equations, verify that the x
element of the PointA structure is defined, then return its
value for evaluation in the conditional- As the xEval routine is
called again, a flag could indicate that the constraint
evaluation does not need to be repeated, the x element of the
Points structure would be checked, then it '8 value returned for
evaluation in the conditional.
After the r~m~; n~ ng stat~m~nts are specified in the source
code, a routine would be used to do a final evaluation of all of
the constraint equations, check for any undefined locations, and
check for violated constraints. If a debug flag was set, a list
of constraints would be printed in the order they were
evaluated. The call for this routine might look like:
evalConstraints();
This routine would mark the end of the lAn~m~rk
definitions, and the geometry definition section could be
started.
Point T~n~k initialization and Utilities
-20-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 l997-l2-l2
W O 96/42060 PCTAUS96/1027s
An initialization routine would probably be required to
support the point l~n~m~rk design methodology. The call to the
routine might look like:
pointT~n~Tn;t();
Several utilities may be written to simpli~y the generation
of l~ rks. Often several geometries need to be aligned within
o a cell to simplify the layout process. Since each point would
represent one geometry, in8tead of a one-~;men~ional l~n~~rk
representing all the geometries that are aligned, a routine to
align the desired points could exist:
xAlignMAX3(1, PointA, PointB, PointC);
This example would determine the m~ m x element of each
of the point structures and set all of the point structures to
that ~alue. If any of the x elements were set to UND~ ~, or
NOCONSTRAINT, then they would not be considered when calculating
the M~X ~alue, but would still be set to the MAX x element value
of the re~?;n;ng points. The argument name (xAlignMAX3)
indicates the nllmh~ of reference points, in this case, 3. The
first argument to the routine is the priority number. Routines
that would work similarly would be xAlignMIN, yAlignMAX, and
YAlignMIN. The routines would return the INT32 ~alue that was
calculated.
To specify the starting point, or origin or a cell, the
following routine could be used:~0
progom(PointA);
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 9~ kO PCTAUS96tlO275
This routine would allow a point to be associated with a
star~ing point (probably 0,0) without having to explicitly
assign the x and y elements o$ a point to 0,0. If a set of
constraints were to be placed relative to another set of
constraints, this routine could be responsible for calculating
the re~uired offset.
Geometry Generation
It would be very advantageous to be able to view the
o defined point l~n~m~rks while ~iewing the associated geometry. A
routine to include a l~n~rk as part of a geometry database
might look like:
tpoint(~name~, Point);
where "name" is a string attached to the point, and Point is the
pointer to the structure. If the point structures were set up as
a linked list, then possibly only one call would be required to
include all of the l~n~m~rk points as part of the database. If
line of code in~ormation were part of the point structure, then
this routine would place the information into the database.
Many routines and macros could be written to take advantage
of this point l~n~m~rk design methodology. Below are several
examples:
Pwire(width, Point) ;
This macro would start a width wide wire on the current
drawing layer at point Point.
Px(Point);
Py(Point);
-22-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
W O 96/42~60 PCTAUS96/1027
These macros would continue to draw the current wire or
polygon to Point->x or Point-~y, re~pectively.
Pxy( Point);
Pyx(Point);
The Pxy macro would continue to draw the current wire or
polygon first to Point-~x, then to Point->y. Similarly, the Pyx
o macro would draw to Point-~y, then to Point-~x. These macros
could be turned into intelligent routines, where the item types
and locations o~ the origin and destination points would be
checked and any appropriate dmc, dpyc, etc. offsets would be
applied to avoid DRC errors or simplify coding (See Figs. 6A-B).
. 15
Pbox(PointA, PointB);
The Pbox routine could check the item types of PointA and
PointB, and also check the current drawing layer, and then draw
a box around the points with the appropriate overlaps.
Pcontacts(PointA, PointB);
The Pcontacts routine would verify that the item types of
2S PointA and Points are similar, then draw an array of a~Lu~riate
contac~s, or vias around the points.
Initial Definitions
Below is a list of item types and other definitions used i~
the prototype code for the point l~nrlm~rk routines (if not
mentioned above): A working prototype of an st~n~rd cell
SU~STITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTAJS96/lOZ75
inverter module generator, alony with all o~ the supporting code
can be found in the directory /home/marc/base3/lib/src/newcds.
Item types:
s layer items
ACT active
PY poly
M1 metall
M2 metal2
o M3 metal3
NPLUS nplus
PPLUS pplus
PWELL pwell
NWEL~ nwell
CUT cut
V via
V2 via2
EDGE edge of stAn~rd cell
wire items
NBA n-type big active
PBA p-type big active
Awn active wire with specified width
PYW poly wire
NGT n gate
PGT p gate
PYWW poly wire with specified width
MW metal wire
BM big metal wire
MWW metal wire with specified width
~o M2W metal2 wire
BM2 big metal2 wire
M2WW metal2 wire with specified width
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTrUS96/1027
M3W metal3 wire
BM3 big metal3 wire
M3WW metal3 wire with specified width
complex items
PYC poly-metal contact
N~AC n-type metal-active contact
PMAC p-type metal-active c~ntAct
MMV metal-to-metal2 via
MMVZ metal2-to-metal3 ~ia
SCON substrate contact
PCON pwell contact
Other de~initions:
#define UND~lN~:v Ox7~ r~ /* largest INT32
*/
~define NOCONSTRAINT -Ox7~ /* smallest INT32
*/
#define DEF POINT(pname,itm,extd,nodname)
\pt=(PO IN-~RECO~D *) malloc(sizeof(POINTRECORD));\
strcpy(pt-~name,pname);\
pt-~item=(itm);\
pt-~X=UN~'lN~; \
pt->y=UN~h'l~; \
pt-~width=0;\
strcpy(pt-~ext dir,extd); \
strcpy (pt-~node,noAnAme)
~define NORTH 8 /* for use with extension directions
*/
30 #define SOUTH 4
#define EAST 2
#define WEST 1
SUBSTITUTE 5HEET (RULE 26)
CA 02224~88 1997-12-12
W O 96/42060 PCTAUS96/lOt7s
C. Constraint Generation Overview
C1.0 Graf Data Structures
s
C1.1 Elements
Graf is built on top of the point-l~n~m~rk data structures.
The basic geometry elements in graf(boxes, wires, etc.) use
points rather than x-y coordinate pairs ~o specify locations.
The types of elements are:
. .
boxes--a box con~ists of two points
wires--a list of points and a width.
strip--two points and a width. This is the same as a wire
with two points.
square--a single point.
polygon--a list o~ points
Cl.2 Layers
In addition to the above information, elements have a layer
associated with them. The layer may be a physical layer or it
may be a special contact layer. A list of layers used in the
prototype is given in table 1.
Contacts are represented as a single element, but are
considered to contF~; n geometry on three different layers--the
ront~ct or via layer and the two layers which the contact (or
via) connects. There are four types of contacts-metall/metal2
vias, metal/n-active contacts, metal/p-active contacts and
metal/poly contact. Each of these is stored on a separate layer.
An additional layer is created to represent the cell
border. This layer contains a rectangle connecting the points
SU~STITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTAUS96/10275
~llBorder" and "urBorder". Constraints are generated between the
border and points which are near the edge of the cell.
C1.3 Edyes
For the purpose of generating constraints, edge data
structures are created. Edge~ are Sim; 1~9 r to lAn-lm~ks in CDS
except that they have a start and end (rather than being a
continuous line). The~e data structures are generated for each
edge of a box or polygon and ~or the centers of wires, strips
o and squares. In general, each point will be represented by an X
and a Y edge. It is commr~n for two points to be represented by
the same edge.
The edges contain information about what points they
represent. They also contAi n pointers to edges on the opposite
S side of the box (or other element) that the edge represents.
This is used to determine overlap conditions during constraint
generation. The edges for a particular element are stored with
the element. In addition, each layer has sorted arrays listing
all of the edges on that layer.
C2.p Constraint Generation
-27-
SU~STITUTE SHEET (RULE 26
CA 02224588 1997-12-12
W O 9~ C~0 PCTAUS96/1027
Thblel:GrnfLayers
G~omebyLayer~ ac~ve
poly
me~
me~2
nplus
pplu~
nwe~
pwe~
Con~ctLaye~ nncL
~acLv~L
~a
O~er border
C2.1 Ports
The first constraints generated are for ports. A list of
el~m~nts touching the port is generated and an attempt is made
to pick a point from one of these elements whi~ch the port should
be connected to. Contacts or vias are considered to be the best
choice with wires being a second choice. If possible, the port
will be aligned with the point, but connect-attach constraints
o will be used if necessary.
If the port is located inside of a box or polygon, the
appropriate constraints will be generated by other routines.
C2.2 Intra-element constraints
In this step, constraints pert~i ni ng to point~ within an
element are generated. This in~olves alignments to keep wires
and polygon edges on a manhattan grid (in the future, 45-degree
alignments will be allowed as well). In addition to this,
constraints are generated to preserve the relative locations of
the points. These constraints are ~Iside-attract~ constraints.
-28-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
~W O ~f'~-~6~ pCTAUS96/10275
The ~attract~ link is used to help keep the element as small as
possible. Some examples are shown below in Figures 7A-C
2.3 Pre-processing
s A ~mall amount of pre-processing is done before generating
con~rt and connect constraints. This usually ~ntA;ls extending
wires ~urther into the contact or wire that is being connected
to. An example is shown in Figures 8A-B where point P3 is
extended past point P2. This simplifieS the constraint necessary
to maintain the connecti~ity.
2.4 Contact constraints
Constraints are generated between contacts and el~nts
which connect to them. This step is probably going to be phased
S out since the next step is more general and should be able to
generate the same constraints.
2.5 Connect constraints '
Elements which touch each other are constrained so that
they will remain touching. This is generally done through the
use of connect constraints as shown in Figures 9A-B. When
generating these constraints, three cases are considered in each
~;m~n~ion.
~ One edge touching one edge
o One edge between two edges
o Two edges connected to two edges
o Two edges connect
The ~irst case is shown one in the X-connection of the wire
and contact. The wire has one X-edge and the contact has one. An
attach is used to make sure they stay together.
-29-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
,W O 96/42060 PCTAUS96110275
The other constraints illustrate the second case, where an
edge is between two others.
The third case occurs when two vertical wires connect or
when a vertical wire connects to a vertical contact strip.
In general, connect constraints will be u8ed in this step.
Some exceptions are:
~ A box connecting to a wire. If the box Q~t~nA~ past
the closest edge of the wire and ends on the farthest edge then
a side constraint will be used.
0 ~ A contact which touches a wire without o~rerlapping. A
~touch" constraint will be used in this case.
The difference between the connect and touch constraints is
shown below in Figures lOA-B. The~two structures in Fig. 1~A
show the play allowed in a wire connected to a cont~ct using a
connect constraint. The two structures in Fig. lOB show that
with a touch constraint the wires can move further out of the
contact as long as they are still touching. The! anywhere in
between the two positions illustrated (for example, the wire
could be centered on the contact). Side constraints could be
used to lock the topology into one of the two structures shown
on the right.
2.6 Intra-layer constraints
: Spacing constraints are generated for conducti~e layers.
These constraints are skipped ~or the ;mrl~nt and well layers.
To yenerate these constraint , the data structure for edges is
used. An array of edges (in each ~;mQn~ion) is constructed and
sorted by coordinate. This array cont~; n~ edges for the layer
itself and for any contacts which share the layer. For example,
metal edges include edges on the layers metal, nactivecut,
pactivecut, polycut and via. An algorithm scans through the
-30-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
UNO 96142060 PCTAUS96/10275
array and determines if a constraint should be generated between
two edges. The criteria that are considered are:
Do the edges represent an overlap?
Do the edges cast a shadow on each other?
Are the edges adjacent?
In Figure 11, an overlap exists between edge E3 and edge
E4. This is because E3 represents geometry that extends to ed~e
E5. These edges don't need constrained because they are taken
o care o~ in step 2.5.
Edges E2 and E3 will have a constraint generated because
they are adjacent (they extend in opposite directions) and'
shadow each other (they overlap in the other ~im~n~ion).~
When E2 and E4 are comr~red, a constraint will not be
generated becau~e E3 is in the way and a constraint is not
necessary. Similarly, no constraint will be generated to E6.
A constraint might be generated between E2 and E8 depending
on how ~ar to the side it is. Diagonal constraints may be
significant between items which don't directly cast a shadow on
each other. A ~udge factor is used to determine how far to the
side two edges can be before they are considered insignificant.
Edges in the orthogonal ~;m~n~ion are also considered for
purposes of ~iltering out unnecessary constraints. For example,
if there were a long vertical wire between E2 and E8, there
2s would de~initely be no constraint generated.
2.7 Inter-layer constraints
Constraints are generated between layers. This is done
between active and each o~ the implant and well layers; poly and
active; nplus and pplus; and nwell and pwell. Constraints
involving contact layers are generated in the previous steps.
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
, W O 96M2060 PCTAUS96/10275
The method for generating inter-layer constraints is
basically the same as for single layer, except that two arrays
of edges are used. Also, instead of discarding overlaps, side
constraints are generated.
2.8 Other constraints
Since the connect con~traint allows a contact to move from
one-side of a wire to the other, it is possible that a
constraint is missed. One example o~ where this can happen is
shown in Figure 12. The contact edge E3 is above E2. The
constraint generation algorithm will generate a con~traint
between El and E2 but not between El and E3. The contact may
move down a little during constraint evaluation and could
produce a DRC error if the constraint doesn't exist. An
algorithm is run to detect and ~ix these situations
2.9 Loose jog constraints
After constraints have been generated and cleaned up a
little, the design is analyzed to see if there are any wire jogs
which have the potential to move significantly. If so,
constraints are merged between the two sides of the jog (as
a~pL~p~iate).
3.0 Constraint Cleanup
3.1 Filtering
Some constraints are discarded ; ~ tely through various
filtering rules. A couple examples are:
o If a constraint is proposed between two edges of the
same layer but another edge will keep them spaced apart, then no
constraint is necessary.
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~VO 96/42060 PCTAUS96/10275
~ Two X-edges must o~erlap in the Y-~;m~n~ion or at
least come within some fudge-factor of overlapping. (The same
applies for Y-edges overlapping in X).
s If two points are enclosed within the same contact, no
constraint is necessary. Connecting to the contact itself is
sufficient.
3.2 Cleanup
After the constraints are generated, they are analyzed in
various ways to try to improve the~.
3.2.1 Identify corner constraints
The first operation is to ~ind the case where two de~ault
constraints exist between the same two edges---one in X and one
in Y. One of the constraints will be l~..,oved and the other will
be turn~d into a corner constraint. If both constraints remain,
a cycle is created and one of the two will be treated as a side
constraint. It is not necessary to have both constraints since
satisfying one will automatically satisfy the other.
3.2.2 Turn connect attaches into aligns
This algorithm checks points connected using connect-attach
constrain~s. If the two points represent elements having the
same width, such as a big-metal wire and a cor-t~ct, the
constrain~ is turned into an align. They should be functionally
;~nt;cal but aligns are more easily processed than att~ch~fi.
3.2.3 Turn overlaps into att~rh~s
The constraints are analyzed to detenmine if they represent
an ov~rlap condition (such as pplus overlapping active). If the
constraint is exactly satisfied, it is assumed that this is
-33-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 199i-12-12
W O 96/42060 PCT~US96/10275
significant and the constraint is turned into an attach
constraint. This is an optional step and the same result might
be accomplished with the attract constraints which are
automatically generated.
s
3.2.4 Attach poly contacts
Many of our cells have poly contacts at the top and bottom
of a strip of metal (one near a P-transistor and one near an N-
transistor). This algorithm looks for a constraint from a poly-
o contact to an active contact. If the constraint is exactlysatisfied in the original design, it is turned into an attach.
This tends to keep the ro~t~ct at the top instead of letting i~
fall to the bottom.
3.2.5 Cleanup well-constraints
This algorithm L~ oves constraints between wells and
objects which are in di~ferent wells. For example, in Figure 13
two wells are shown, each contai n; ng an active box. The
constrain~ shown, from the active on the left to the well on the
right, is not necessary and would be deleted.
3.Z.6 Chanye defaults to side constraints
When a default constraint exists from an edge to another
edge, a check is done to see if there is a constraint path in
the other ~;m~n~ion from the start of the edge to the point and
from the end of the edge to the point. If these paths exist, it
can be assumed that target of the constraint will always be in
the shadow of the reference point and the constraint can be
converted to a side constraint. This iu~Lo~es the efficiency of
the constraint solver and sometimes yields better results.
3.2.7 Cleanup geometry port constraints
-34-
SU~STITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~VO 96/~2060 PCT~US96/10275
Edges representing geometry ports are used during
constraint generation so that constraints to the ports will be
generated. These ports should not be used to constrain other
points, however, and any such constraints will be deleted.
3.3 Constraint circle detection and ~ ,ovdl
Constraint circles occur when a path of constraint
references leads back to the original point where the path
started. An example would be point A referenciny point B and
o point B referencing point k The location of point A cannot be
calculated without knowing the location of point B (and vice-
versa). It is possible for corner constraints to create
constraint circles which are more complicated than this (and
harder to identifier). In these circles, it may not be possible
to calculate the X-location of point A without knowing the Y-
location o~ point B and vice-versa.
A routine is run which will identify any constraint circles
which may exist. If the constraint circles are caused by corner
constraints, one of the corner constraints in the circle will be
converted to a default constraint in order to break the circle.
Other types of constraint circles cannot be automatically
broken.
4.0 St~nAArd Cells and Buffer Sizing
St:~nA~rd-cell and bufi~er-sizing constraints are implemented
using our methoAnlogy. When doing buffer-sizing, the transistor
width is co~r~red to widths returned by getn() or getp() in
order to determine the effective size. User constraints are
generated which call these functions. A more general-purpose
method will need to be identified.
St~n~rd-cell constraints consist of the following:
-3s-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
, W096/42060 PcT~ss6/lo27s
4.1 Pitch-match the power ports.
A user constraint is added with the equation "sthpitch".
This is a global variable which is set for each ruleset.
4.2 Align power-ports with the east and west cell borders
4.3 Align signal ports if they were aligned in the original
topology.
This tends to keep individual parts from ~lipping down. It
o also tends to keep the ports more toward the center of the cell.
In the future we intend to experimen~ with con~traints that will
move the ports further to the center lf there is no effe~t on
density.
4.4 Pitch-match nwell if the origi~al cell conformed to the
heigh~ requirement.
Most of our old cells ignored this rule. This is done by
adding a user constraint between a ground port and the bottom of
each nwell box with the equation ~stdnwellheight". This is a
global variable which is set for each ruleset.
The new st~n~rd-cells will have a different set of
re~uirements. For them, many of the Y-coordinates are pre-
determined and can be specified through user constraints.
The point-l~n~m~rks code has certain rules for constr~ining
geometry to the cell edges. These default rules may not be
appropriate for all types of leaf-cells and it may be necessary
to investigate alternatives in the future.
We also need a way of speci~ying grid constrain~s.
5.0 Other Technologies
Some attempts have been made to make this prototype
technology independent. There is some cmos-specific code, but
-36-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~YO 96/42060 PCTrUS96/10275
most of the ~echnology specific information is cont~i~P~ in a
start-up file which is parsed in at run-time. The point-
lAn~mArks code which this is built on top of would be more of a
rnnr~rn in converting to other technologies.
A different 8et of filtering and cleanup routines may need
to be pro~ided for other technologies.
6.0 user functions and variables
Users can make their own functions and variables available
o to graf by editing a file and recompiling. This is 8~mil~-- to
the way Verilog-XZ, and certain other products with C-language
interfaces work. Variables in the rules file are a~ le by
defaul~.
D. Sof~ware Reguirements Specification for the CDS Point
T.An~m~rk Design MethodolOgy
D1.0 Introduction
20 Dl.l Purpose
The purpose of this doc~m~nt is to describe ~nhAn~m~ntS tc
the CDS language. It is intended for use by CDS users, including
Cascade De~ign Automation Module Designers.
D1.2 Scope
The scope of this software specification is to define a
method of associating l~n~lm~rks with geometries 80 that
constraints between lAn~m~k~ can be calculated by specific
routines rather than discrete e~uations, and also to define
geometry generating routines compatible with the current CDS
geometry generating routines that take ad~antage of two-
~;m~nsional point descriptions rather than one-~;m~ional
SU~STITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
' W O 96/42060 PCTnUS96/10275
lAn~m~rk descriptions. The definition of these routines will
focus on the current technologies used by Cascade Design
Automation to process integrated circuits (CMOS and GaAs).
Many functions exist tha~ are related to the defined
~unction~3 outlined in this software specification, but are not
intended to be included in its scope. Several of these functions
are listed here:
Geometry Compactor
Technology independent constraint routines/equations
0 Automatic constraint generation
Rxaphical CDS geometry editor
Dl.3 Definitions, Acronyms, and Abbreviations
CDS = Compiler Development System
CMOS = Complementary Metal-Oxide Semiconductor
GaAs = Gallium Arsenide
SC = Symbolic Constraint
DRC = Design Rule Check
LVS = Layout Versus Schematic
D1.4 References
Introduction to the CDS Point T.An~m~rk Design Methodology,
Marc Bur-hAn~n, Cascade Design Automation
Software Requirements Specification for CDS ~nh~nC~m~ntS
for base cells, Brad Roetcisoender, Cascade Design Automation
XBased Layout Viewer Requirements Specification, Doug
Sebastian, Cascade Design Automation
D1.5 Overview
-38-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
r WO 9f _ 0~0 PCTAUS96/10275
This so~tware requirements specification describes the
details of a CDS point lAn~m~rk, how it 8hould be used, and what
its structure contains. Also de~cribed are the constraint
routines that use this pointCl~n~m~k. The function of the
constrai~t routines are to calculate the location of a point
~ k with respect to other point lAn~m~ks. Using the
information attached to each point, the routines can calculate
the x- or y- location of a point so that the m;~ m possible
distance between the geometries represented is achieved without
o any DRC or ~VS errors. Some of these routines calculate this
distance based on the physical constraints of a layout, while
other routines use electrical parameters such as transistor.
sizes to determine the proper point locations. Se~eral geometry
generation routines are also described. These routines take
advantage of the information associated with the point l~n~m~rlcs
to simplify code writing and to make the module code less
susceptible to errors when applied to multiple rulesets.
A2.O General Description
2.1 Product Perspecti~e
All of the routines and definitions described in this
docl-mPnt are to be used in the geometry generating, or geo,
section of a CDS module. The routines described as geometry
generation routines must be within the CellDefine() and
C~ll~n~ f() routines as described in the document Software
Re~uiL~ -nt~ Specification for CDS ~nh~ncements for base cells.
The point definitions and the constraint routines may be used
before or after the CellDefine() routine, but must be used
before any of the geometry generation routines that reference a
point lAn~m~k are used.
-39-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
, W O 96/42060 PCT/US96/10275
If a cell is compiled with the line_o~_code debugging
informa~ion included, then an interface to the Lview geometry
viewer becomes prevalent. Debugging information stored in the
database of the cell may be retrieved and viewed by the Lview
5 program. This information includes point lAn~m~k locations,
extension directions, and relative constraints to other point
lAnAm~ks See the document Xbased Layout View Requir~m~nt.s
Specification for details on how this information will be
represented within the Lview pLO~ldlll.
2.2 ~roduct Functions
2.2.1 Point T.~n~m~rk and T-~n~k Routines
A point l~n~m~k is used to mark the location of a geometry
item (i.e. poly-metal contact, end of a metal wire, etc.) and
store in~ormation in a structure describing the name of the
l~n~m~rk, the geometry item, the direction the geometry extends
~rom the point, the electrical node name of the represented
geometry, and optionally the width of the geometry (if the point
20 is representing an arbitrary with wire), and the line_of_code
information (file name, line number, and constraint reference
points)~
. .
The lAn~m~k routines are used to name and partition groups
of l~n~m~rks, and the associated symbolic constraints.
2.2.2 Constraint Routines
The majority of the constraint routines are used to define.
constraints that, when evaluated, will determine either the x-
or the y- position of a point relative to one or more reference
points in either the north, south, east, or west direction.
Other routines are used to delete, evaluate, or check previously
defined constraints.
-40-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~W O 9~A~6C PCTrUS96/10275
2.2.3 Geometry Generating Routines
The geometry generating routines are used to create
geome~ries in the geocell database. The functions will be
s similar to the current CDS geometry generating rou~ines in that
they will create boxes, wires, etc., but with fewer ar~-m~nt~.
Some o~ the in~ormation required to de~cribe the geometries
being created will come from the point l~n~m~ks referenced in
the argument lists of the routines.
2.3 U~er Characteristics
The routines described in this document are intended to be
used by a CDS Module developer.
lS 2.4 Benefits
The ~escribed routines may replace, or be used in
conjunction with existing CDS routines to make code easier to
generate and more robust. For a new CDS user, these routines
should allow the user to have operational code in less time than
without them. The user would no longer be required to become
familiar with the approximately 300 micros and macros cont;~ eA
within CDS, but instead use ~he 30 to 40 geometry item types
used by the routines. These geometry item types are more
intuitive to use since they represent cv~ layout geometries,
instead o~ the ~rarious widths, spacing ~ralues, and overlaps
represented by the micros and macros. These routines are
intended to replace the current equations and geometry routine~
used in the module code, but will also work concurrently with
them. A user may modify module code to simplify certain
functions by replacing error prone or hard to debug equations
with the~e new routines, while lea~ing the bulk of the code
unchanged.
-41-
SUBSTITUTE Sl IEET (RULE 26)
,
CA 02224588 1997-12-12
W O 96/42060 PCTAUS96/10275
2.5 General Constraints.
Other than the cons~raints described in the previous
sections, the only concern that the ~lGyLd-.u.,er might have, is
s that ~he order the routine8 are specified in the code may affect
the outcome of the physical layout. In certain instance~, the
proy~ u~l~r should try re-ordering the constraint routines to
find an optimal solution.
o 3.0 Speci~ic Requirements
3.1 Functional Requiremen~s: Point T~n~m~k Definition and
T.;lnrlm;3rk Routines
3.1.1 Point Structure
3.1.1.1 Introduction
The point structure is defined to contain the following
information: The name of a point l;ln~m:l~k, the x and y location,
the geometry item type, the width of the reprèsented wire (if
the point represents an arbitrary width wire), the extension
directions of geome~cries from the point, and the electrical node
name. If the line_of_code debug flag i8 set, then a list of
constraint reference points, line_of_code file name, and
l~ne_of code line number infonmation will also be cont~ine~
within the point structure.
3.1.1.2 Processing
The el~m~nt o~ the structure are set and modified with the
def point and point_width routines, and with the various
constraint routines.
3.1.2 The newPointGroup routine
-42-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
.W O 96/4Z060 PCTrUS96/10275
3.1.2 1 Introduction
The newPointGroup routine is used to define a new group
which will contain a set o~ points and symbolic con8traints. The
syntax is shown here:
newPointGroup(group_name~;
3.1.2.2 Inputs
group_name - char* indicating the name for a group of
o l~n~m~ks and con~train~s.
3.1.2.3 Processing
The newPointGroup routine is a required routine that will
~irst veri~y that the group does not currently exist, then
create static pointers to a new point li8t and a new symbolic
constraint (SC) table. This group will then become the ~ tly
active group and any point~ or con~traint as defined subsequen~
to the newPointGroup call and pre~ious to another newPointGroup
or setPointGroup call will belong to the specified group.
Points and constraints within different groups will be
indep~n~ent of one another.
If group_name has been previously defined and not freed by
a subsequent call to ~reePointGroup, an error will be reported.
A call to the newPointGroup must ~e made prior to defining
any points or sylObOliC constraints.
3.1.2.4 Outputs
The routine will return an INT32 representing its status.
3.1.3 The setPointGroup routine
3.1. 3.1 Introduction
SUBSTITUTE SHEET (RULE 26
CA 02224588 1997-12-12
, W O 9C/~0~0 PCT~US96/10275
3.1.3.1 The setPointGrouP routine is used to change the
current active group as de~ined with a newPointGroup call. The
syntax o~ the COm~-n~ iS:
setPointGroup(group_name);
3.1.3.2 Inputs
group name - char* indicating the name for the
point/SC group.
3.1.3.3 Processing
The setPointGroup routine will verify that the group
exists, and mark this group as the currently active group. A~y
points or constraints defined subsequent to the call (until
15 another setPointGroup or newPointGroup call is encountered) will
belong to this group.
If group name does not exist, an error will be reported.
3.1.3.4 OUtputs
The routine will return an INT32 representing its status.
3.1.4 The freePointGroup routine
3.1.4.1 Introduction
The freePointGroup routine is used to de-allocate the
Il~ llULy used by the various point and constraint definitions
within the speci~ied group, and to le,.,o~e the group pointers.
The syntax of the Comm~n~ is
freePointGroup(group_name);
3.1.4.2 Inputs
-44-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT/US96/10275
group_name - char* indicating the name ~or the point/SC
group.
3.1.4.3 Processing
The freePointGroup routine will ~rerify that the group
exists, and then free the memory used by the point list and the
SC table associated with the specified group.
If a freePointGroup routine is executed with group_name
indicating the current group, a newPointGroup or setPointGroup
o routine mu~t be executed before any points may be defined or
referenced, or before any constraints may be defined or
evaluated.
If group_name does not exist, an error will be reported.
3.1.4.4 Outputs
The routine will return an INT32 representing its status.
3.1.5 Defining a Point
3.1.5.1 Introduction
The syntax of the co-mmAn(l to de~ine a point is as follows:
point = def_point(name, item, ext_dir, node_name);
3.1.5.2 Inputs
The inputs to the defpoint routine consist of the
following: c
name - a char~ that contains the string representing the
name of the point lAn~mA~k.
item - an INT32 contAining the item number of the geometry
represented by the point lAn-lmArk. Macro names from an
Pnnm~rated list will be used for this argument. See geometry
i~em types at the end of this document.
-45-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTAUS96/10275
ext_dir - a char* cont~; n; ng any or all of "NSEW", which
represent the extension directions of the geometry represented
by the l~nAm~k.
node_name - a char* containing the string representing the
electrical node name of the represented geometry.
3.1.5.3 Processing
A~ this routine is executed, it will first allocate the
amount of space re~uired to contain the structure, then the
o ar~m~nts will be copied to the appropriate elem~nts o~ the
structure. Al~o, the x, y, and width el~m~nt~ will be
initialized with the integer representing I~ lN~:V.
As various constraints are evaluated, the x and y el~m~nt~
will be ~odi~ied to contain the location o~ the point l~n~m~rk.
Two integer ~alues are reser~ed to represent a location that is
either unde~ined, or found not to be constrained by any other
points. The~e ~alues are defined as UND~hlN~:~ and NOCONSTRAINT,
respecti~ely.
20 3.1.5.4 Output
The routine will return a char* cont~; n; ng the name o~ the
point.
3.1.6 The point_width routine
3.1.6.1 Introduction
The point width routine is used to indicate the width of an
arbitrary width wire. The syntax of the co~m~n~ is:
point_width(point,width);
~ 30
3.1.602 Inputs
-46-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
s UNO 9f~ fiO PCTAUS96/1027~
point - char~ indicating the name o~ the point to have its
width modified.
width - *INT32 indicating the geometry width.
5 3.1.6.3 ProcesE;ing
This routine will set the width element of the point
structure to the width value.
An error will be reported if width is not a multiple of
2~gridsize.
o An error will be repor~ed if the item type o~ point is not
an arbitrary width wire type.
3.1.6.4 Outputs
The routine will return an INT32 representing its status.
3.2 Functional Require~nt~: Constraint Routines
Setting the origin of a cell
3.2.1.1 Introduction
To set the origin or starting point for the constraint
equation~;, the following co~ nA Will be used:
origin(point);
3.2.1.2 Inputs
point - char+ indicating the name of the point.
3.2.1.3 Processing
This routine will place an entry into the SC table to be
later evaluated by a routine such as evalconstraints. During
evaluation, the x and y elements of the point structure will be
set to 0. It will always be the first constraint to be
evaluated.
-47-
SuBsTlTuTE SHEET (RULE 26)
CA 02224588 1997-12-12
, W O 96142060 PCTAUS96/1027s
Since the origin routine and the point group reference
routines each set the location of a point to an ab~olute value
independent of other points in the current group environment,
calls to any of the point group reference routines are not
allowed if the origin routine is used. Calls to the delta group
reference routines are allowed since they return relative
distances rather than absolute locations.
3.2.1.4 Outputs
The routine will return an INT32 representing its statu~.
, ..
3.2.2 Setting the absolute location of a point
3.2.2.1 Int-roduction
A user may be required to set the location of a point that
iS not dep~nA~nt on any other point l~n~lm~ks, but is dependellt
on some other object, such as a placed cell. To allow for
situations like this, routines are ne~e~ to allow the user to
set the absolute location of a point. Three routines that will
allow the user to se~ the x, y, or the x and y location of a
point are shown here.
pxSetLoc(point,x);
pySetLoc(point,y);
pSetLoc(point,x,y);
3.2.2.2 Inputs
point - char* indicating the name of the point.
x - INT32 indicating the absolute location for the x
element of the point
y - INT32 indicating the ab~olute location for the y
element of the point
-48-
SUBSTITUTE SHEET (RULE 26
CA 02224~88 1997-12-12
.W O 96/42060 PCTAUS96/1027s
3.2.2.3 Processing
The pxSetLoc routine will place an entry in the current SC
table to be evaluated at a later time. When the entry in the SC
table is e~aluated, the x element o~ the point will be set to
the value speci~ied by x. Sim;l~rly~ the pySetLoc routine will
place an entry in the current SC table, and, when evaluated,
will set the y element of the point to the value speci~ied by y.
~he pSetLoc routine will place two entries in the current
o SC table, one to represent the horizontal constraint on the
point, one to represent the vertical constraint on the point.
These entries will be identical to the ones placed by the .
pxSetLoc and pySetLoc routines, and will be evaluated in the
same way.
Caution should be ta~en when using these routines. Since
the location of the point is solely based on the aLyu~ ts as
speci~ied by s:he user. the system cannot verify that the point
will be referencing the same origin as the othér points.
If any constraints are placed on the point in the
horizontal direction along with a pxSetLoc routine, or in the
vertical direction along with a pySetLoc routine, or in either
direction along with a pSetLoc routine, an error will be
reported.
3.2.2.4 Outputs
The routines will return an INT32 representing their
status.
3.2.3 The point group reference routines
3.2.3.1 Introduction
The point group reference routines are used to detenmine
the location of a point based on the location of a point defined
-49-
SUBSTITUTE SHEET (RULE 26)
CA 02224~88 1997-12-12
. W O 9~2060 PCT~US96/10~75
within a different group. The syntax ~or each o~ the point group
reference routines is shown here:
pRefGroup(pl,ref_pt,group_name);
pxRe~Group(pl,ref_ pt, group_name~;
pyRefGroup(pl,ref pt,group_name);
3.2.3.2 Inputs
pl - char* indicating the name of the point.
o ref ~t - char* indicating the name o~ the point within the
group.
group_name - char~ indicating the name of the group to
reference
S 3.2.3.3 Processing
Each of the point group reference routines will place an
entry in the current SC table, and verify that the item types,
extension directions, and point widths (i~ applicable) of re~pt
and pl match. When the constraints are evaluated, they will
first verify that the group exists and the point exists within
the group, and that the group_name SC table has been e~aluated.
The location of refpt (x only for pxRefGroup, y for pyRefGroup)
will ~hen be copied to pl.
Errors will be reported if the group specified by
group_name does not exist, or if the point ref_pt does not exi~t
within that group.
An error will be reported if the SC table within the group
speci~ied by group_name has not been evaluated.
If any of the point group reference routines are used, a
call to the origin routine is not allowed.
-50-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT/US96/1027
3.2.3.4 Outputs
The routines will return an INT3 2 representing their
status.
'5 3.2.4 The del~a group reference routines
3.2.4.1 Introduction
The delta group reference routines are used to determine
the relative distance between two points within a group other
than ~he current group. The syntax for each of the routines is
o shown here:
dxRefGroup(ref Ptl~ref-pt2~group-name);
dyRefGroup~ref_ptl,ref Pt2,yroup_name);
3.2.4.2 Inputs
ref pl, ref p2 - char* indicating the names of the
reference points.
3.2.4.3 Processing
. Bach of the delta group reference routines will first
verify that the group and points specified by group_name, refpl,
and refp2 exist, and that the group SC table has been evaluated.
They will then use the locations of ref Pl and ref P2 to
determine the x or y difference.
The results will be ~mm~t~tely calculated, so it is not
necessary to make an entry in the current SC table.
3.2.4.4 Outputs
The delta group reference routines return an INT32
indicating the vertical or horizontal distance between the two
points.
-51-
SUBSTITUTE SHEET (RULE 26~
CA 02224588 1997-12-12
, W O 96/42060 PCTrUS96/10275
3.2.5 The directional physical constraint ~unctions
3.2.4.1 Introduction
The directional physical cons~raint routines use the OO~UIIO~1
compass names to indicate the location of a point lAn~m~k with
respect to one or more reference point lAn~m~rkS~ The syntax of
each of the direction physical constraint routines are shown
here:
north(pl,refl);
north2(pl,refl,ref2);
north3(pl,refl,ref2,ref3);
north4(pl,refl,ref2,ref3,ref4);
north5(pl,refl,ref2,ref3,ref4,ref5);
south(pl,refl);
south2(pl,refl,ref2);
. . . .
south5(pl,refl,ref2,ref3,ref4,ref5);
~ east(pl,refl);
east2(pl,refl,ref2);
. . .
east5(pl,refl,ref2,ref3,re~4,ref5)i
west(pl,refl)i
west2(pl,refl,ref2)
... .
west5(pl,refl,ref2,ref3,ref4,ref5);
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
' W O ~G/4-C~C PCTrUS96/10275
The multiple routines with Pn--m~rated names for each
~unction was chosen instead of one routine with a variable
number of arguments so that during development of a CDS module,
the debugging stage may be more thorough.
s
3.2.5.2 Inputs
pl - char~ indicating the name of the point to have its x
or y element modified (the east and west co~m~n~S will modify
the x element, the north and south CO~m~n~ will modify the y
o element).
refl,...ref5 - char~ indicating the names of the re~erence
point~.
D3.2.5.3 Processing
The function of each of the physical constraint routines is
to place an entry into the SC table that represents the
constraints ~etween the point pl and the reference points
refl...ref5.
When this constraint is evaluated ~y calling the
evalConstraints, xEval, or yEval routine, the location of pl
will be determined by applying all known physical layout rules
to the geometries represented by the point pl and the reference
point(s) refl(,ref2, ... refS). During the evaluation of a
constraint, the geometry item of pl would be compared with that
of ref~l to determine the required distance between them, then
with ref2, etc. and then use the worst case distance to
det~rm; n~ the location of pl.
A point may represent a complex geometry item, a wire, the
edge of a geometry, or the edge of a st~n~rd cell. A complex
item would represent multiple geometries such as a poly-metal
cnnt~ct~ which contains geometry on three different layers -
me~al, poly, and cut. A wire item would represent the center of
-53-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
WO 96/42060 PCTAUS96/10275
a single-layer wire, and a layer item would represent the edge
or corner of a single layer ~eometry- The cell edge item would
repre~ent the left or right edge of a st~n~rd cell. As two
points are compared, the item geometry type of each point is
checked, and each layer of each point is checked to determine
the proper ~pacing. Figure8 14A-B show how the horizontal
location of pl may be set by referencing refl.
Diagonal space checking is re9uired to obtain optimal
density of a layout. If the x and y location of the reference
o point is known, an~d either the x or the y location of the point
to be set is known, then the unknown location element may be set
to an optimal solution by using the Pythagorean theorem (see
Figure 148).
The routines are to be able to detenmine when the point pl
and a reference point are representing metal active contacts on
opposite sides of a transistor. If the extension directions of
pl and the reference point are toward each other, they both
represent metal-active contact, and they are on different
electrical nodes, then the rules for transistor spacing will be
applied lsee Figure 15).
As each constraint equation is executed, an entry will be
put in an SC table until a cgmm~n~ is executed to evaluate the
cons~raint~.
During evaluation, if the x location of pl is being set and
the x location of any of the reference points, or the y location
of any of the reference points or the set point is set to
UN~-lN~V, then the constraint will be skipped. A second pass
through the SC table will then be required. If after one or more
passes through the SC table the evaluation routine has reached a
point where no more constraints can be e~aluated, but the x
location of pl still needs to be set and the y location of any
of the points is still UNDEFINED, then the worst-case spacing
-54-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT~US96/1027~
from the reference point will be calculated (no corner-to-corner
checking), and the evaluation of other constraints within the SC
table may continue.
If the x location of pl is being set and the x location of
s all of the reference points is set to NO~ON~l~AINT, or the y
location of any of the re~erence points or the set point is set
to NO~N~l~AINT, then the constraint will be 8kipped. A second
pass through the SC table will then be reguired. If, after
~everal passes through the SC table, the evaluation routine has
r~chP~ a point where no more constraints can be evaluated and
the x location of pl has not yet been 8et, and the y location of
any of the reference points is still set to NO~ON~-lKAINT, then
the worst-case spacing from that point will be calculated (no
corner-to-corner checking).
If p1 and the reference point have the same node name, and
the items are of the same layer, or one point is ~imple and the
other is complex and c~nt~; n~ a geometry of the same layer, then
off-set spacing will be applied, i.e., if pl represents a poly-
metal contact, and re~1 represents a metal wire, and they are on
the same node, then the distance applied between them will be
dmc (delta-metal contact to metal wire).
If more than one constraint in the same direction (north,
south, east, west) is specified for the same point, then the
constraints will be additive, m~Aning that the worst-case
constraint defined will be used ~unless a delete constraint
function had been executed after the first constraint definition
~nd before the second). If a constraint is specified for a point
that is in the opposite direction of a previously defined
constraint (east vs. west), then a warning message will be
given.
D3.2.5.4 Outputs
-55-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 l997-l2-l2
' w o 96/42060 PCTAUS96/lOZ75
The routines will return an INT32 indicating its status.
D3.2.6 The corner-check physical constraint functions
3.2.6.1 Introduction
The corner-check physical constraint routines are
equivalent to the physical constraint routines described above
with one exception. If the absolute distance between the point
being set and any of the reference points cannot be calculated
(because of UNKNOWN or NOC'~N~l~AINT ~alues), the constraint will
o not be evaluated, even if no other constraints can be e~aluated.
The 8yntax is as follows:
cNorth(pl,refl);
cNorth2~pl,refl,ref2);
cNorth3(pl,refl,ref2,ref3);
cNorth4(pl,refl,ref2,ref3,ref4);
cNorth5(pl,refl,ref2,ref3,ref4,ref5);
cSouth(pl,refl);
cSouth2(pl,refl,ref2);
.
cSouth5(pl,refl,ref2,ref3,ref4,ref5);
.,,
cBast(pl,refl);
cEast2(pl,refl,ref2)
. . .
cEast5(pl,refl,ref2,ref3,ref4,ref5);
cWest(pl,refl);
cWe~t2(pl,refl,ref2);
. . .
cWest5(pl,refl,ref2,ref3,ref4,ref5);
-56-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~vo 96/42060 PCT~US96/10275
3.2.6.2 Inputs
pl - char* indicating the name of the point to have its x
or y element modi~ied.
s refl, .... ref5 - char* indicating the names of the
re~erence points ~or determining the location of pl.
3.2.6.3 Processing
The corner-check phy~ical constraint routines are
equivalent to the directional physical constraint routines
described above
with one exception. The coordinate of each of the reference
points must be known, both the x and y element, along with the
opposite direction element of the point being set, be~ore the
constraint will be evaluated. Unlike the directional physical
constraint routines which will do corner-to-corner checking only
i~ the irl~orma~ion is available, these routines require that t~e
information be available before they will be evaluated.
3.2.6.4 Outputs
The routines will return an INT32 indicating their status.
3 2.7 The single ~;m~n~ion physical constraint functions
3.2.7.1 Introduction
The single ~ n~ion physical constraint routines are
8;m; 1 ~r to the directional physical constraint routines
described above with the exception o~ no corner-to-corner
check.ng. The syntax is as follows:
.
sNorth(pl, refl, width);
sSouth~pl, refl, width);
sEasttpl, refl, width);
-57-
SU3~TITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
WO 96/42060 PCT~US96/10~7s
sWest(pl, refl, width);
.
3.2.7.2 Inputs
pl - char* indicating the name of the point to have its x
or y element modi~ied.
refl,...ref5 - char* indicating the names of the reference
poin~s for determining the location of pl.
i.2.7.3 Processing
3.2.7.4 The function of the single ~im~n5ion physical constraint
routlnes are equivalent to that of the directional phy~ical
constraint routines described above except for that corn~-to-
~o~n~r checking is never done. This means that an sEast or sWest
routine will calculate (when evaluated) the x element of the set
point independent of the y element values of the set point and
the reference point. Conversely, the sNorth and sSouth routines
will calculate the y element of the set point independent of the
x element values.
The single ~im~nsion physical constraint routines may be
used in conjunction with the directional and corner-check
physical constraint routines. This is done by specifying several
constraints on one point. For example:
north(pl,re~1);
sNorth(pl,ref2);
cNorth(pl,re~3);
In the above example, point pl will be constrained by points
refl, ref2, and ref. When the constraint is evaluated between pl
and re~1, corner-to-corner checking will be done if the x
elements o~ pl and re~1 are known (which may take se~eral passes
-58-
SUBSTITUTE Sl IEET ~RULE 25)
CA 02224588 1997-12-12
W O ~ 60 PCTrUS96/10275
through the SC table), otherwise no corner-to-corner checking
will occur. When the constraint is evaluated between pl and
ref2, no corner-to-corner checking will be done, and the
constrain~ between pl and ref. will require that corner-to-
s corner checking be done. Before the group of constraints will bee~aluated, the y elements of points refl, ren, and ref. must be
known, and the x elements of pl and ref. must be known,
(required by the cNorth routine). If any of these conditions are
not met, the group of constraints will not be evaluated until
o the conditions are met. I~ the conditions are never met, an
error will be L~U' Led.
3.2.7.5 Outputs
The routine~ will return an INT32 indicating their status.
3.2.8 The delta constraint functions
3.2.8.1 Introduction
The delta constraint routines are used to set the desired
distance between two points. The syntax is as follows:
dNorth(pl, refl, delta);
dSouth(pl, refl, delta);
dEast(pl, refl, delta);
dWest(pl, refl, delta);
3.2.8.2 Inputs
pl - char* indicating the name of the point to have its x
~o or y element modified.
~efl - char* indicating the name of the reference point.
-59-
SU~STITI lTE SHEET (RULE 26
CA 02224588 1997- i2- 12
J WO 96/42060 PCT/US96/1027!;
refl - c delta - INT32 indicating the desired distance in
an orthogonal direction pl is to be placed from refl.
3.2.8.3 Processing
The routine dNorth, when evaluated, will modify the y
5 element of pl to be equal to refl-~y ~ delta.
The routine dSouth will modify the y element of pl to be
equal to refl-~y - delta.
The routine dEast will modify the x ele~ent of pl to be
equal to refl-~x + delta.
o The routine dWest will modify the x element of pl to be
e~ual to refl-~x - delta.
If a DRC error is likely to occur between the represented
geo~etries of pl and refl, a warning will be reported.
I~ the specified delta is not a multiple of gridsize, an
error will be reported.
3.2.~.4 Outputs
The routines will return an INT32 representing their
2 0 status.
3.2.9 The attach constraint functions
3.2.9.1 Introduction
The attach constraint routines have the same function as
~he respective directional, single ~;men~ion, and corner-check
physical constraint routines with the added function of
attaching the set point to the reference point. The syntax of
each of the attach constraint functions is shown here:
nor~hAttach(pl,refl);
-~0 -
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~NO 96/42060 PCT/US96/1027
southAttach(pl,refl);
eastAttach(pl,refl);
westAttach(pl,refl);
cNorthAttach(pl,refl);
cSouthAttach(pl,re~l);
cEastAttach(pl,refl);
cWestAt~ach(pl,refl);
o sNorthAttach(pl,refl);
~SouthAttach(pl,refl);
~EastAttach(pl,refl);
~WestAttach(pl,refl);
dNorthAttach(pl,refl,delta);
dSouthAttach(pl,refl,delta)
dEastAtt~ch(pl,refl,delta);
dWestAttach (pl,refl,delta);
3.2.9.2 Inputs
pl - char* indicating the name of the point to have its x
or y element modified.
refl - char* indicating the name of the re~erence point for
determining.the location of pl.
delta - INT32 indicating the desired distance in an
orthogonal direction pl is to be placed from refl.
3.2.9.3 Processing
As the attach constraint routines are evaluated, the set
point will be attached to the reference point, in that if the
set point moves because of an additional constraint, the
-61-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT~US96/1027~
re~erence point will move with it. All other functionality of
the attach constraint routines are equivalent to the respective
directional, single ~ ncion, and corner-check constraint
routines.
s I~ the set point is constrained by more than one reference
point, and a non-critical (not wor8t case) reference point is
attached to the set point, then the attached reference point
will be moved as close as possible to the 8et point without
~iolating any of the defined constraints. Figure 16A shows an
o, example where pl is constrained by refl and re~2, and ref2 is
the critical reference point. Figure 16B 8how8 how the point
re~l will be moved if the constraint between pl and ref1 is
changed from an east constraint to an ea8tAttach constraint.
The set point will be attached to the reference point in
only the vertical or horizontal direction, not both, unless a
second attach constraint is specified.
Note that only one re~erence point is allowed in the attach
constraint co~n~, this is to avoid potential cyclical
references that cannot be resolved.
D3.2.9.4 Outputs
The routines will return an INT32 representing their
status.
D3.2.10 The transistor
3.2.10.1,Introduction
The transistor constraint routines are used to set the proper
distance between two points to create a transi~tor of the
specified width. The syntax is as follows:
tNorth(pl, refl, width);
tSouth(pl, refl, width);
-62-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
,W O 96M?r60 PCT~US96/1027
tEa~t(pl, re~l, width);
tWe~t(pl, re~1, width);
3.2.10.2 Inputs
pl - char* indicating the point to have it8 location set.
re~l - char~ indicating the reference point.
width - INT32 indicating the desired width of the
transistor.
o 3.2.10.3 Processing
The transistor const~aint routines use the width al~,..e.lt
to de~enmine the distance from the reference point to place the
point pl. Offsets will be applied to the point location pl based
on the geometry types of pl and refl.
For each point that represents a metal-active contact of an
n- or p- chArlnel transistor (NMAC or PMAC) or an n- or p-
~h~nn~l big active wire (PBA or NBA) the o~set thac] will be
applied.
For each point that represents an active width wire (AW),
the offset [aw/2] will be applied.
For each point that represents an arbitrary width active
wire (AWW), the offset [width/2] will be applied, where width is
the width of the active wire.
For each point that represent~; an n-rh~nn~l poly gate (NGL)
with ~tpn~ion direction(s) only parallel to the gate direction,
the offset tngtx - ngl + hac] will be applied.
For each point that represents a p-rh;lnn~l poly gate (PGL)
with ~t~n~ion direction(s) only parallel to the gate direction,
the offset ~pgtx - pgl + hac] will be applied.
SURSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
, W O 96/42060 PCT~US96/10275
For each point ~hat represents an NG~ with extension
direction(s) perpendicular to the gate direction, the o~fset
tac2ngtx - ngl - hac] will be applied.
For each point that represents a PGL with extension
s direction(s) perpendicular to the gate direction, the o~fset
tac2pgtx - pgl - hac] will be applied.
No o~fset will be applied for points representing active
(ACT).
For the CMOS technology, if the geometry item type of
o either o~ the points is other than NMAC, PMAC, NBA, PBA, AW,
AWW, NGL, or PGL, then an error will be reported.
I~ the item types o~ pl and refl are NMAC, PMAC NBA, or
PBA, and the width of the transistor is less than the width of a
big active contact, the extension direction of pl will be
modified.
The extension direction perpendicular to the gate direction
will be e~..o~ed (See Figures 17A-B).
If the width of the transistor is less than new (~or n-
rh~nnel transistors) or pg. (~or p-chAnn~l transistors) an error
Will be reported.
If the point geometry item types represent di~ferent
transistor types, i.e. one NMAC and one PMAC, an error will be
reported.
. . .
The transistor constraint routines will always attach the
set point to the re~erence point (see the attach constraint
~unctions above).
D3.2.10.4 Outputs
The xoutines will return an INT32 representing ~heir
status.
D3.2.11 The align routines
-64-
SUBSTITUTE SHEET (RULE 26)
-
CA 02224588 1997-12-12
W O 96/42060 PCT~US96/10275
D3.2.11.1 Introduction
The align routines are u6ed to vertically or horizontally
align two or more point l~n~m~rkS~ The syntax for the various
5 align routines are shown here:
xAlign(pl,p2) ;
xAlign3 (pl, p2, p3) ;
xAlign4 (pl, p2, p3, p4) ;
o xAlign5 (pl, p2, p3, p4, pS) ;
yAlign(pl,p2) ;
yAlign3 (pl, p2, p3) ;
yAlign4 (pl, p2, p3, p4) ;
S yAlignS (pl., p2, p3, p4, pS) ;
D3.2.11., Inputs
pl..pS - char~ indicating the names of the points that will
have its x or y element modified.
3.2.11.3 Processing:
The xAlign routines are used to horizontally align two or
more point lAn~m~ks, and the yAlign routines are used to
2s vertically align two or more point 1~n~-rk~. The xAlign routine
first checks the direction of the constraints on point specified
by the ar~lm~nts~ and then sets each of 4h x elements of the
structur~s point~d to by the arguments to the m;n;ml~m (for west
constrair.ts) or m~l~;mnm (for east constraints) value in the set
(uND~ N~ and NONCONSTRAIN~ values will not be considered when
finding the m;n;mllm/m~;mllm value). The yAlign routines operate
-65-
SUBSTITUTE SHEET (RULE 20)
CA 02224588 1997-12-12
' W O 9f'4'CCû PCT/US96/loz7~
similarly on the y elements of the structures pointed to by the
arguments.
If any points are attached to one of the points in the
argument list, the relative distance to the attached point from
s the point in the argument list will stay the same.
Since ~hese routines can potentially modify a point that
constrains another point, during evaluation, the SC table must
be searched ~or constraints that use any of the arguments as
reference points and mark them as needing re-evaluation ~if they
o have been previously evaluated). If any of the ar~u~ ts belong
to a group of attached points, then any constraints that
reference any of the poin~s in the group must be re-evaluated.
3.2.11.4 Outputs
The routines will return an INT32 representing their
status.
3.2.12 The delete constraint routines
3.2.12.1 Introduction
The delete constraint cn ~ ~n~ are used to delete a
previously defined constraint. The syntax is shown here:
xDeleteConstraint(pl);
yDeleteConstraint(pl);
i.2.12.2 Inputs
pl - char* indicating the name of the point to have its x
or y element modified.
3.2.12.3 Processing
The xDeleteConstraint routine will delete any entries in
the SC table entered there by any of the versions of the east or
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~WO 96/42060 PCTAUS96/10275
west routines. It will also P~mine any x-direction align~ent
co~m~nA~ and, if pl exists as an argument, remove it from the
argument list, or e...~v~ the whole ali~nment con~traint if there
are only two arguments in the alignment constraint.
Similarly, the yDeleteConstraint routine will delete SC
table entries originated by a north or south routine, or a y-
direc~ion alignment routine.
If no constraint previously exi~ts on pl, a warning message
will be displayed.
3.2.lZ.4 Outputs
The routine~ will return an INT32 representing their
status.
3.2.13.1 Introduction
The constraint check routines are used to determine if a
possible DRC error may exist, or some other undesirable
condition. The syntax for each of the routines is shown here:
cNorthChecl~(pl,refl);
cSouthCheck(pl,refl);
cEastCheck(pl,refl);
cWestCheck(pl,refl);
sNorthCheck(pl,refl);
sSouthCheck(pl,refl);
~astCheck(pl,refl);
sWestChec~.(pl,refl);
dNorthCheck(pl,refl,delta)
dSouthCheck(pl,refl,delta);
dEastCheck(pl,refl,delta);
-67-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 9~'A~C6Q PCT~US96/1027
dWestCheck(pl,re~l,delta) ;
3.2.13.2 Inputs
pl - char* indicating the point name.
ref~l - char* indicating the reference point name.
delta- INT32 indicating the allowed distance between pl and
refl
3.2.13.3 Processing
o The ~unction of the constraint check routines is similar to
that of the corner-to-cor~, sin~le ~;m~n~ion, and delta
physical constraint routines in that they are used to calc~late
the distance between the points pl and refl, but instead of
setting the location o~ pl, will report the dif~erence between
15 the calculated location for pl and the actual location of pl.
The returned value will be equal to the difference between
the actual location of pl and the calculated location of pl in
the direction specified by the name of the constraint check. If
the actual location o~ pl extends beyond the calculated location
20 in actual the
specified direction from re~l, then a positi~e integer will be
returned. I~ the actual location and the calculated location of
pl extend an equal amount from refl in the direction specified,
the value O will be returned, and if the actual location does
2S not P~tencl as ~ar as the calculated location of pl in the
specified direction ~rom re~1, a negative integer will be
returned. This in~ormation can be used to determine an error
condition, since a ~alue that is negative indicates a possible
DRC error.
The routines sNorthCheck, sSouthCheck, sEastCheck, and
sWestCheck will calculate in a single ~;mension (either
horizontal or vertical) the m;nimnm required distance between pl
-68-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~WO g~ C6C PCT/US96/10275
and refl. The routines will then compare this distance to the
actual single ~m~n~ion distance.
The routines cNorthCheck, cSouthCheck, cEastCheck, and
cWestCheck will calculate the ab501ute m; n;ml~m reguired distance
s between pl and refl, and then c~r~re the x element (~or
cEastCheck or cWestCheck) or y element (for cNorthCheck or
cSouthCheck) of the calculated coordinate and compare it to that
of the actual x- or y- location of pl.
The routines dNorthCheck, dSouthCheck, dEastCheck, and
o dWestCheck will use the value of delta as the required space (in
a single ~m~n~ion) between pl and refl and compare that with
the actual distance.
Unlike the physical constraint routines, these routines do
not place an entry into the SC table for later evaluation, but
evaluate as they are encountered. If previous constraint
defi~itions exist that have not been evaluated, an error will be
reported.
For the routines sEastCheck, sWestCheck, dEastCheck, and
dWestCheck, if the x element of pl or refl is set to UNV ihlN~
20 or NO~'O~SlKAINT, then an error will be reported.
For the routines sNorthCheck, sSouthCheck, dNorthCheck, and
dSouthCheck, if the y element of pl or refl is set to UND
or NOCO~lKAINT, then an error will be reported.
For the routines cNorthCheck, cSouthCheck, cEastCheck, a~d
cWestCheck, if the either the x or y element of pl or refl is
set to UND i~lN~iV or NO~:ON~l~cAINT, then an error will be
reported.
3.2.13.4 Outputs
The routines will return an INT32 equal to the calculated
distance subtracted from the actual distance.
-69-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT~US96/10275
3.2.14 The xEval and yEval routines
~ 3.2.14.1 Introduction
The xEval and yEval routine~ will partially or fully
evaluate the constraints defined by any constraint routines
executed prior to this point in the code. The syntax of these
routines i8 shown here:
xEval(point);
yEval(point);
o The intended use for these routines is to determine the
value of a point structure's x or y element before all of the
. .
con~traints have been de~ined. A user may require that
definition of a l~n~m~rk or group of lAn~m~ks depend on the
relative location of two previously defined l~n~m~rks. Since ~he
S actual location of a l~nAm~rk is not available until its
cons~raint equations have been evaluated, these pre~iously
defined l~n~m~rks must be evaluated before their locations can
be compared. An example of how the xEval routine might be used
i8 show~ here:
if (xEval(pl) ~ xEval(p2)) east(p4, pl);
else west(p4, p3)i
In the above example, the constraint definition of p4 is
determined by the relation of pl and p2. The xEval routine
evaluates any of the previously defined constraints so that the
x location of pl and p2 will be available.
3.2.14.2 Inputs
point - char* indicating the name of the point structure to
have its x or y element evaluated and ret~r~
-70-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O ~ 60 PCTrUS96/10275
3.2.14.3 Processing
The xEval and yEval routines will attempt to evaluate all
of the constraint equations de~ined previous to its call. If a
constraint equation cannot be evaluated because of a re~erence
point with an x or y element that is set to UND~lN~;V or
NOCONSTRAINT, then it will be skipped and anot~er pass through
the SC table required. When all of the constraints have been
evaluated, or no additional constraint8 evaluated after one full
pass, then the x element (for the xEval routine) or the y
o element (~or then tt
the y~val routine) of the point structure will be returned. I~
the value is set to UND~:~lN~!iV or NO~ON~l~AINT, then an error
will be reported.
During execution, the constraints will not be re-evaluated
if an xEval or yEval routine has previously been executed and no
other constraints have been defined.
3.2.1~.4 Outputs
The output from the xEval routine will be an INT32 value
equal to the x element of the point structure after evaluation.
The output ~rom the yBval routine will be an INT32 value
equal to the y element of the point structure after evaluation.
3.2.15 The evalConstraints routine
3.2.15.1 Introduction
The evalConstraints routine will evaluate all o~ the
constraints entered into the SC table. Its syntax i8 shown here:
evalConstraints();
A call to this routine will be required before referencing
any of the point l~n~m~rks from a geometry generating routine.
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT/US96/10275
3.2.15.2 Inputs
There are no direct inputs to the evalCon8traints routine.
The indirect inputs are the entries in the SC table.
3.2.15.2 Inputs
There are no direct inputs to the evalConstraints routine.
The indirect inputs are the entries in the SC table.
o 3.2.15.3 Processing
The evalConstraints routine will attempt to evaluate the
defined constraints in the order they were placed in the SC
table. if an entry in the SC table represents an east or.west
constraint that references a point with an x element set to
15 UND~lN~V, or a north or south constraint that references a
point with a y element set to UNV~ lN~, the constraint will be
skipped until the next pass through the table. Similarly, if an
east or west constraint has all of its reference points with x
elements set to NOCONSTRAINT, or a north or south constraint has
all o~ its reference points with y elements set ~o NOC:O~
the constraint will be skipped.
As each constraint is successfully evaluated, the evaluate
flag of ~he constraint will be set to the current value of the
SC table pass counter. This will allow for later analysis to
determine the order of constraint evaluation. As soon as all of
the constraints have been evaluated, or after making a full pass
through the SC table without evaluating any constraints, the
evaluation process can stop. If there were any constraints that
could not be evaluated, an error will be reported along with a
list of constraints that could not be evaluated.
~ fter the evaluation process has completed, the locations
of the point l~n~m~rks can be verified by making one more pass
-72-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~VO 96/4Z060 PCTAUS96/10275
through the SC table. If any constraints are ~iolated, a warnillg
will be reported with the name o~ the constraint.
If any x or y elements of the point structures are still
set to UND~lN~iL, then they should be listed as having no
s constraint definition, and an error reported.
If an xEval or a yEval routine had been pre~iously executed
and no additional constraints were de~ined, then evaluation of
the constraints is not neces~ary, so no evaluation will occur.
However the checks ~or unevaluated constraints, violated
o constraints, and undefined points will still occur.
3.2.15.4 Outputs
The routine will return an INT32 representing its status:
3.2.16 Restrictions
3.2.16.1 Constraint Definition Restrictions
Constraints are not allowed to be placed on a point in
opposite directions. For ~A~rle, i~ an east constraint had been
placed on a point, then an error would be reported i~ a west
constraint were placed on the same point. Cyclical re~erence
paths are not allowed. All re~erences o~ all points must
directly or indirectly re~erence a point placed by the origin
routine, a point group reference routine, or an absolute
location routine.
3.2.16.2 Align Statement Restrictions
At least one point in the argument list ~or an xAlign
routine must have at least one constraint in the horizontal
direction other than an align constraint. Any additional
-73-
SUBSTITUTE SHEET (RULE 20)
CA 02224588 1997-12-12
' W O 96/42060 PCT/US96/1027s
constraints on any of the points must all be in the same
direction.
At least one point in the argument list for a yAlign
routine must have at least one constraint in the vertical
direction other than an align constraint. Any additional
cons~raints on any of the points must all be in the 8ame
direction.
Any points in the argument list for an xAlign constraint
must not reference any of the other points in the argument list
o in a different horizontal constraint.
Any points in the argument list for a yAlign constraint
must not re~erence any of the other points in the argument liSt
in a di~ferent vertical constraint.
15 3.2.16.3 Attach Statement Restrictions
An attachment to a point placed with the origin routine, a
point group reference routine, or an absolute location routine
will have no effect.
A reference point should not be attached to more than one
set point (a set point may be attAch~A to more than one
re~erence point.
3.3 Functional Requirements: Geometry Generating Routines
3.3.1 The tPoints routine
3.3.1.1 Introduction
The tPoints routine is a geometry generating routine that
is used to place l~n~mArk information into the database. The
names and coordinates of each defined lAn~lmArk within the
specified group will be saved. If the line_of_code flag is set
then the line_of_code file name, line_of_code line number, and
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/4206~ PCT~US96tlO275
the reference point liSt is also included for each point
1 A n~-rk,
The syntax is shown here:
tPoints(group_name);
3.3.1.2 Inputs
group name - char~ indicating the name for a group of land-
o marks.
3.3.1.3 Processing
The tPoints routine will reference the pointer to ~he ~irst
(last) point l~n~m~k cont~;n;ng the speci~ied group name and
S place the point l~n~m~rk name and coordinate into the current
database. The next (pre~ious) point lAn~m~k will be referenced
by using t~e next element in the structure, and, if it also
contains the specified group name, the name and coordinate of
the next point will also be placed in the database. This pattern
Will continue until the end of the linked list of lAn~m~rk
points has been searched. If the line_of_code flag is set, then
the file name, fileline number, and pointer reference string for
each point will also be placed in the database.
A geo databafie must be open before executing the tPoints
COlm~ n~ or an error will be reported.
3.3.1.4 Outputs
The routine will return an INT32 representing its status.
3.3.2 The pBox routine
3.3.2.1 Introduction
SUBSTI TUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTnJS96/10275
The pBox routine is a geometry generating routine that will
create a rectangular geometry. The routine will automatically
calculate the required overlap o~ the geometry over the point
locations based on the geometry item type of each point. The
syntax is shown here:
pBox(pl,p2);
3.3.2.2 Inputs
o pl, p2 - char~ indicating opposite corners of the box to be
crea~ed.
3.3.2.3 Processing
The pBox routine will check the current drawing layer and
the item types of each point, and calculate the proper overlap
of each point based on that information. It will then create a
box geometry surrounding the two points with the correct
overlap.
If the current drawing layer and the item type of either
point conflict, then an error will be reported.
If either of the points represent an arbitrary width wire,
the overlap of the point will be one half of the wire width. If
the wire width is not a multiple of two times the grid unit, an
error will be reported.
3.3.2.4 Outputs
The routine will return an INT32 representing its status.
3.3.3 The pWire routine
3.3.3.1 Introduction
-76-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96~'4-C~0 PCTAJS9~1027~
The pWire routine is a geometry generating routine that
will define the starting point of a new wire. The wire is to be
continued with the px, py, pxy, and/or pyx comm~n~. The syntax
5 iS shown below:
pWire(width,pl);
3.3.3.2 Inputs
wid~h - INT32 indicating the desired width of the new wire.
pl - char* indicating the location to start the wire
,
3.3.3.3 Processing
S The ~unction of the pWire routine will be very similar to
that of the wire routine. The wire width will be set by the
width argumeI~t, and the starting loc~tion will be determined by
the x and y elements of the structure point to~by pl.
If the iterm type of pl does not indicate a geometry on the
same layer as the current drawing layer an error will be
repor~ed.
If the value of the width argument is not a multiple of
2~gridsize, an error will be reported.
3.3.3.4 Outputs
The routine will return an INT32 representing its status.
3.3.4 The px and py routines
3.3.4.1 Introduction
SUBSTITUTE SHEET (RULE 26
-
CA 02224588 1997-12-12
t WO 96/42060 PCT~US96/1027s
The px and py routines are geometry generating routines
that will continue to draw a wire that has been started by the
pWire or wire routine. The syntax i8 ~hown below:
pX(pl);
py(pl);
3.3.4.2 Inputs
pl - char* indicating the x or y location to draw the
current wire.
3.3.4.3 Proce~sing
The px routine will draw the current wire in the horizontal
direction to the ~alue specified by the x element of the
structure pointed to by pl.
The py routine will draw the current wire in the vertical
direction to the value specified by the y element of the
structure pointed to by pl.
After the wire has been drawn, if the end point of the wire
is located exactly at the location of pl, then intelligent wire
operations may occur if the next wire routine to ~e used is
either the pxy or pyx cnmm~n~ See the description of
intelligent wire operations in the section describing the
operation of the pxy and pyx routines.
If the electrical node names of the wire starting point and
ending point do not match, and the current drawing layer is
poly, metal, metal2, or metal3, a w~n; n~ Will be reported.
3.3.4.4 Outputs
-7~-
SUBSTITUTE SHEFI (RULE 26)
CA 02224588 1997-12-12
~VO 96/42060 PcTAJs96110275
The routines will return an INT32 representing their
status.
3.3.5 The pxy and pyx routine~
s 3.3.5.l Introduction
The pxy and pyx routines are geometry generating routines
that will continue to draw a wire started by the pWire routine.
These routines will make intelligent deci~ions as to how to draw
the wire i5 certain situations to help avoid DRC errors. For
example, if a metal width wire is being drawn ~rom a poly-metal
contact to another poly-metal contact, the wire ~ay be
automatically ~hifted by the value dmc to avoid any possible
metal "notchesn,. And i~ the two poly-metal contacts happen to
be close enough to create a metal spaciny error, the wire width
lS may be increa~ed tO ~ill in the gaps. The syntax is shown below:
pxy(pl);
pyx(pl);
20 3.3.5.2 Inputs
pl - char4 indicating the new location to draw the curren~
wire .
3.3.5.3 Proc~ssing
The pxy ;routine will draw a wire with a width specified by
25 the width aly4-.,e1,t in the last pWire or wire routine to the
location ~irst in the horizontal direction to pl-~x, then in the
vertical directlon to pl-~y.
The pyx routine will draw a wire with a width speci~ied by
the width arqument in the last pWire or wire routine to the
30 location first in the vertical direction to pl-~y, then in the
horizontal direction to pl-~x.
-79-
SU~STITUTE SHEET (RULE 2~)
CA 02224588 1997-12-12
' W O 96/42060 PCTrUS96/10275
If the starting point of the wire segment being drawn
repre~ents a geometry on the current drawing layer that is wider
than ~he current wire width, and the location of pl is in a
nonorthogonal direction ~rom the starting point, then the wire
star~ing point will be shi~ted to the closest edge of the
geometry represented by the starting point (see Figures 18A-B).
Similarly, if the item type of the geometry pointed to by pl i8
wider than the current wire width, the wire ending point will be
shifted to the closest edge of the geometry repre~ented by pl.
o ~fter the wire segment is drawn, the reported wire end
point will be shifted back to the location of pl.
If the pxy or pyx COm~nA iS creating a wire segment
between two points that are clo~e enough to create a DR~ error
when considering the item type~ involved, then either the width
of the wire will be increased, or a box geometry will be added
next to the wire to avoid the DRC error (see Figures l9A-D).
Figure l9A shows a wire drawn up to the s~art point. Figure l9B
shows a wire continued to pl. Figure l9C shows~a DRC error that
occurs at a current width. Figure 19D shows a wire width
increased.
If the electrical node names of the wire starting point and
ending point do not match, and the current drawing layer is
poly, metal, metal, or metal3, a warning will be reported.
~ .
3.3.5.4 Output~
The routines will return an INT32 representing their
statu~.
3.3.6 The pContacts routine
3.3.6~1 Introduction
-80-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
~VO 9~ 6~ PCT/US9611027S
The pContacts routine is a geometry generating routine that
will create an array of contacts or vias. The type of contact or
via will be determined automatically by the item type o~ the
point l~n~m~rks. The syntax is shown below:
pContacts(pl,p2);
3.3.6.2 Inputs
pl, p2 - char* indicating the end or corner points for the
contact array.
3.3.6.3 Processing
The function of the pContacts routine is to draw an array
of metal-active contacts, poly-metal oont~cts, substrate.
contact~, pwell contacts, via~, or via2s. The type of contacts
drawn will depend on the item type of the point l~n~ks. The
m~; ml?m dep number
of contacts possible will be placed in 1 fiay configuration in
the box defined by the two point lAn~m~rks pl and p2 with the
appropriate overlap. This routine will work similar to the
contacts routine.
The item types a~lowed are NMAC, PMAC, PYC, SCON, PCON,
VIA, and VIA2 (see th~ description of geometry item types
below). I~ the item type of either o~ the point lAn~m~rks is
something other than these, an error will be reported.
An error will be ~eported if the item types of the two
point l~n~m~ks do not match.
3.3.6.4 Outputs
The routine will rbturn an INT32 representi.~g its status.
3.3.7 The pxContacts an~ pyContacts routines
3.3.7.1 Introducti~l
-81-
SUBSTITUTE SHEET (~ULE 26)
CA 02224588 1997-12-12
. W O 96142060 PCT~US96/10275
The pxContacts and pyContacts routines work similar to the
pContacts routine, except that only one roW o~ contacts is
generated instead of a ~ull array. The first argument will
represent an "anchor" point ~or the row o~ contacts, and the
~econd argument will determine length of the row. I'ypically
these routines will be used to create a row of metal-active
contacts on an active box where only two points are defined in
opposite corners of the box. Figure 20 shows an ~le of how
the row~ of metal-active contacts can be generated with the
o pxContacts routine. The ~yntax o~ the routines is shown here:
pxContacts(pl,p2);
pyContacts(pl,p2);
3.3.7.~ Inputs
pl - char~ indicating the anchor point for the row of
contacts.
p2 - char~ indicating the opposite end point of the con~act
array by the x or y element in i~s ~tructure.
3.3.7.3 Processing
The pxContacts routine will create a horizontal row of
contacts from the location indicated by pl to the coordinate p2-
>x, pl->y.
The pyContacts routine will create a vertical row of
contacts from the location indicated by pl to the coordinate pl-
>x, p2-~y.
An overlap value appropriate to ~he item type of pl will be
applied to each end of the row.
The item type of pl must be one of the following: NMAC,
PMAC, PYC, SCON, PCON, VIA, or VIA2 - otherwi~e an error will be
repor~ed.
-82-
SUBSTITUTE SH~Er (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTAJS96/10275
3.3.7.4 Outputs
The routines will return an INT32 representing their
status.
s 3.3.8 The single contact routines
3.3.8.1 Introduction
The single contact routines will place a contact macro
(group of geometries) o~ the ~peci~ied type centered at the
o point l~n~m~rk. The syntax of each of the routines is shown
here:
pPYM(pl);
pMA (pl );
pM2M(pl);
pM3M2(pl);
pV~A(pl);
pVIA2(pl);
3.3.8.2 Inputs
pl - char+ indicating the center point to place the
contact.
3.3.8.3 Processing
The pPYM routine will place a poly-metal contact at
location pl. Any extensions of poly in the direction of metal
will be detenmined by the extension directions specified by the
point structure.
The pMA routine will place a metal-active contact centered
at point pl.
The pM2M routine will place a metal-to-metal2 ~ia centered
at poin~ pl.
-83-
SUBSTITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
VVO 96/4Z060 PCT~US96/1027
The pM3M2 routine will place a metal2-to-metal3 via
centered at point pl.
The pVIA routine will place a via (metal-to-metal2)
centered at point pl. No metal or metal2 geometry will be
included.
The VIA2 routine will place a via2 (metal2-to-metal3)
centered at point pl. No metal2 or metal3 will be included.
I~ the item type o~ pl does not match the type of contAct
being at pl, an error will be reported.
o 3.3.~8.4 Outputs
The routines will return an INT32 repres~nt~ ng their
status.
D3.3.9 The pPolygon routine
D3.3.9.1 Introduction
The pPolygon routine is a geometry generating routine used
to create a polygon with only a list of point l~n~rks re~uired
as arguments. The mi n; ml2m overlap o~ the polygon geometry over
each point is calculated automatically. The polygon shape is
restricted to being rectilinear, so it is not necessary to
- specify every corner of the polygon. Except for the first two
points, the point list needs only to describe every other corner
to define the polygon shape (see Figure 21). The syntax of the
pPolygon routines are shown here: '-
pPolygon(pl,p2,p3);
pPolygon3(pl,p2,p3);
pPolygon4(pl,p2,p3,p4);
pPolygon5(pl,p2,p3,p4,pS);
pPolygon6(pl,p2,p3,p4,p5,p6);
pPolygon7(pl,p2,p3,p4,p5,p6,p7);
pPolygon8(pl,p2,p3,p4,pS,p6,p7,p8);
-8~-
SUBSTITUTE ~HEET (RULE 26)
CA 02224~88 1997-12-12
'W O 9614~060 PCTrUS96/10275
pPolygons~pl,p2,p3,p4,p5,p6,p7,p8,ps);
3.3.9.2 Inputs
pl - p9 - char* indicating corner points of the polygon.
3.3.9.3 Processing
The ~unction o~ the pPolygon routine is to determine the
proper overlap of the current drawing layer over each of the
points specified in the argument list, and create a rectilinear
o polygon surrounding all of the points. The ~econd point in the
argument list is required to be in an orthogonal direction from
the ~irst point, so that a starting direction may be
established. The rest o~ the argllmPnts will specify points that
may or may not be orthogonal to the previous point.
If a point is not orthogonal to the previous point, then
the polygon edge will be drawn it two segments. I~ the previous
edge was drawn in the y direction, then the first segment will
be in the x direction and the second in the y direction. If the
previous edge was drawn in the x direction, then the first
20 segment will be drawn in the y direction, then in the x
direction. All o~ the points must have item types associated
with the current drawing layer, otherwise an error will be
reported.
3.3.9.4 Outputs
The routine will return an INT32 representing its status.
3.3.10 The p~ort routine
3.3.10.1 Introduction
The pPort routine is used to place a signal or geometry
port label at the specified location. The syntax is:
pPort(pl,port_name,attrib);
-85-
SUBSTITUT, .,t ~EET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 ' PCTAUS96110275
3.3.10.2 Inputs
pl - char~ indicating the location of the port
port_name - char~ indicating the text string to be assigned
to the port
attrib - char~ indicating the attributes to be place on the
port
3.3.10.3 Processing
The pPort routine will work similar to the CDS tport_nl
o routine with the following exceptions. The location of the port
will be specified by the argument pl, instead of two a y~ enLs
., _ .
specifying the x and y location, and the port layer and size
information will be extracted from the point structure, instea~
of using arguments to the routine. The text string attached to
the port is speci~ied by port_name, and the name of the
electrical node assigned to the port will be the value stored in
the node name elemen~ of the point structure. The entries in the
attribute string will be equivalent to those used in the tport
or tport_nl routine.
3.3.10.4 Outputs
The routine will return an INT32 representing its status.
3.3.11 The pNodeLabel routine
The pNo~T~hel routine is used to attach a node label to
the geometry at a specific location. The syntax is:
pNoA~T.Ahel(pl);
3.3.11.2 Inputs
pl - char~ indicating location of port
3.3.11.3 Processing
The pNodeLabel routine will work similar to the CDS
nodelabel routine with the following exceptions. The location of
the node label will be specified by the point pl, instead of two
arguments specifying the x and y location, and the port layer
-86-
S'J9STITUTE SHEET (RULE 26)
CA 02224588 1997-12-12
W O 9f'~1-G~0 PCTAUS96/10275
information specify will be extracted from the
point structure, instead of using an argument to the routine.
The name assigned to the port will be the ~alue stored in the
node name element of the point structure.
3.3.11.4 Outputs
The routine will return an INT32 representing its status.
3.3.12 The point structure
3.3.12.1 Introduction
To access the information describing a point, routines are
required that can read the elements of the 8tructure associated
with the point. The information cont~ine~ in the structure that
a u~;er may want tO access is the location of the point, the
width of the point, the extension directions, the item type, and
the electrical node name. The syntax for six different routines
that will access this informa~ion is shown here:
xl = pGetX(pl);
pGetY(pl);
Wl = pGetWidth(pl);
str = pExtDir(pl);
item = pItem(pl);
str = pNodeName(pl);
3.3.12.2 Inputs
pl - char~ indicating the name of the point
3.3.12.3 Procèssing
T].e point structure access routines will find the structure
cont~; n~ ng the named point, then return the re~uested
information from the structure. An error will be reported if the
point specified by pl does not exist.
-87-
SUBST~TUTE SH~ ULE 26)
CA 02224588 1997-12-12
' W0 96/42060 PCT~US96/1027
3.3.12.4 Outputs
The pGetX and pGetY routines will return an INT32
representing the value of the x or y value of the point
structure, respectively. The dGetWidth routine will return an
s INT32 representing the width value of the point structure. The
pExtDir routine will return a char~ contA; ni ny the extension
direction(s) of the point,. The pItem routine will return a-
cdsITEM representing the item name/number of the point. The
pNo~P~T~m~ routine will return a char* contAining the electrical
node name assigned to the point.
3.4 Functional Requirements: CMOS specific Internals
3.4.1 The geometry item types
3.4.1.1 Introduction
The geometry item types are used to represent the different
geometries encountered in a typical layout. Some are considered
to be complex, where an item represents a group of ~eometries,
such as a poly-metal contact (PYC), or a substrate contact
(SCON). If an item is not complex, then it is a simple item,
20 m~An;ng ~he geometry is cont~;nPA on one layer. Simple item
types may be within two groups: wire items, or edge items. A
wire item indicates that the point lAn~m~rk represents the
center point of a wire, while an edge item represents the edge
or corner of a geometry.
3.4.1.2 Processing
The geometry item types are to be defined in an ~nl~m~rated
list. This will allow faster processing than if stored as
character strings, and also allow for easier checking for
elements of a group.
Below is the initial list of item types. More item types
may be defined as the need for them arises.
-88-
SUBST~T.,', . SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTrUS96/1027
edgeitems
ACT active
PY poly
~1 metall
M2 metal2
M3 metal3
NPLUS nplus
PPLUS pplus
~WELL pwell
0 NWELL nwell
CUT cut
V via
V2 via2 . .
EDGE edge of st~n~d cell
NDLBL node label
wire items
NBA n-type big active '
PBA p-type big active
AWW active wire with specified width
PYW poly wire
NGT n gate
PGT p gate
PYWW poly wire with ~pecified width
MW metal wire
BM bigmetal wire
MWW metal wire with specified width
M2W me al2 wire
BM2 big metal2 wire
M2WW metal2 wire with specified width
M3W metal3 wire
BM3 big metal3 wire
_~9_
SUBSTITU it ~HEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCT~US96/lOZ75
M3WW metal3 wire with specified width
complex items
PYC poly-metal contact ,
NMAC n-type metal-active contact
PMAC p-type metal-active contact
MMV metal-to-metal2 ~ia
MMV2 metal2-to-metal3 via
SCON substrate cont~ct
o PCON pwell contact
miscellaneous items
EDGE edge o~ st~n~rd cell
NDLBL node la~el
GEN generic
3.5 Functional Requirements: Debugging Routines
The development process of modules using the various point
l~n~m~k routines, several debugging routines will be available.
3.5.1 dump_sc_table
- 3.5.1.1 Introduction
The dump_sc_table routine is used to view the internal SC
table of the current group. The list may be sorted in different
ways, and partial listings may be generated. The syntax is shown
here:
dump_sc_table(sort,start,stop);
3.5.1.2 Input~
sort - INT32 indicating the sort type
start - IN~T32 indicating the first entry to be printed
stop - INT32 indicating the last entry to be printed
-90-
v~ TlTUTE SHEET (RULE 26)
CA 02224588 1997-12-12
0 96/42060 PCTAJS96/10275
3.5.1.3 Processing
The dump_sc_table routine will print a formatted partial or
full list of the constraints cont~inP~ within the current SC
table. The information printed for each constraint will include
the point name, the direction of the constraint, the value of
the eval flag, the location of the point (x and y), and a list
of reference points. each including: the reference point
constraint type and attach information, its delta offset (for
delta con~traints), and its location (x and y).
o The listing may be sorted in various ways, dependiny on the
gvalue of the sofrt argument:
0 - ~o sort, print constraints in definition order
1 - sort by evaluation order
2 - sort by point name
3 - sort by constraint direction
4 - sort by constraint type
To allow for printing partial listings of Lhe SC table, ~he
start and stop arguments may be used to speci~y a range. After
the specified sort occurs, the routine will print the entry
20 specified by start, and all subsequent entries until reaching
the entry specified by stop. If the value of stop is 0, entries
will continue to be printed until the end of the SC table is
reached.
Output will be sent to the message p~y~ handler.
25 3.5.1.4 Outputs
The routine will return an INT32 representing its status.
3.5.2 ;]'
3.5.2.1 IntroduCtion
The dump ptlist routine is used to view the lis~ of defined
points in the current group. The list may be sorted in different
-91-
SUBSTlTUTt ~ f r (RULE 26)
CA 02224588 1997-12-12
'W O 96M2060 PCT~US96/10275
ways, and partial listings may be generated. The syntax is shown
here:
dump pt_list(sort,start,stop);
3.5.2.2 Inputs
s sort - INT32 indicating the sort type
start - INT32 indicating the first entry to be printed
stop - INT32 indicating the last entry to be printed
3.5.2.3 Processing
The dump Dtli~t routine will print a ~ormatted partial or
o full list of the points defined in the current group.
Information listed for each point will include the point name,
,. . .
the point location (x and y), the item name, the point widthr
the extension directions, and the~electrical node name.
The listing may be sorted by point name, node name, or item
type, as indicated by the sort argument:
0 - no sort, print points in definition order
1 - sort by point name
2 - sort by node name
3 - sort by item type
Partial listings may be generated by using the start and
stop arguments, where start indicates the first point to be
li~ted, and stop indicates the last. A value of 0 for stop
indicates the end of the list.
Output will be sent ~o the message pL~yL~... handler.
3.5.2.4 Outputs
The routine will return an INT32 representing its status.
3.5.301 Introduction
The dump pt routine is ufied to view the information stored
in a structure for a specific point. The syntax is shown here:
dump pt(point);
3.5.3.2 Inputs
-92-
SU~v~llJlt SHEET (RULE 26)
CA 02224588 1997-12-12
W O 96/42060 PCTfUS96/10275
point - char~ indicating the name of the point
3.5.3.3 Processing
The dump pt routine will display the name of the point, the
location of the point (x and y), the width of the point (if an
s arbitrary width wire), the item type, the extension directions,
and the electrical node name.
Output will be sent to the message pl~yld--- handler.
3.6 Performance Requi~ - ts
o Execution speed in the constraint equations will be
critical because o~ their pot~nt; Al 1 y high ~requency o~ use.
This should be considered when approaching the de8ign of these~
routines.
15 3.7 Attributes
3 . 7 . 1 I~A; nt;li nAhility
Certain ~ubroutines of the constraint routines will be
specific to the process - CMOS or GaAs. These subroutines should
be separated ~rom the rest of the routines to simplify
20 maintF~nAnC~.
3.8 Other Requirements
3.8.1 Data Base
Since additional data will be stored in the geometry
25 database when line of code infonmation is included, a new
database element may need to be defined to store to be defined
to store this information.
_9~ _
SUu~ I, , I i c SHEET (RULE 26)
