METHOD AND APPARATUS FOR POINT LANDMARK DESIGN OF INTEGRATED CIRCUITS

Abstract: A method and apparatus for point landmark design of integrated circuits. A computer is programmed to present a graphical interface to and to receive commands from a user in response to the graphical interface. The computer also receives a description of the features of an integrated circuit design and of the design rules pertaining to a given process technology and other design constraints. The computer then associates at least one feature point with each feature in the integrated circuit design and associates a list of attributes with each type of feature used in the integrated circuit design. The computer also associates at least two constraints (ref1, p1) with each feature point and associates a list of constraint attributes with each constraint. Then the computer performs operations on the list of attributes associated with each point landmark to determine the relative geometric placement of the feature points.

Description: Description Method and Apparatus for Point Landmark Design Of Integrated Circuits Reference to Provisional Application This application claims the benefit of U.S. Provisional Application No. 60/000,159, filed June 12, 1995. Technical Field The present invention relates to methods and apparatus for using point landmark for integrated circuit design. Summary of the Invention In accordance with a first embodiment, the invention is a method for designing an integrated circuit having 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 design rules associated with a process technology. The design rules specifying physical requirements among the members 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 information 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 value, and c) preparing a list for each of the attributes associated 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 including a list of constraint attributes associated with the type 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 of features, the list including the values of the constraint attributes. Further, the invention includes the step of g) performing operations on each of the lists, the operations corresponding to constraints in the design rules, and the results of the operations being relative geometric placement of the feature points. In accordance with another aspect, the invention is an apparatus for designing an integrated circuit having 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 design rules associated with a process technology. The design rules specify physical requirements 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 is 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 constraints with each feature point. The fifth circuit means is for associating additional constraint information with each constraint. The constraint information includes a list of constraint attributes associated with the type of the constraint. Each attribute in the list of constraint attributes has a value. The sixth circuit means is for preparing a list for each of the constraints attributes associated with a constraint that is associated with each feature in the plurality of features, the list including the values of the constraint attributes. The a seventh circuit means is for performing operations on each of the lists. The operations correspond to constraints in the design rules, and the results of the operations are relative geometric placement of the feature points. Brief Description of the Drawings Figure 1 is a schematic diagram of a portion of the method of the present invention. Figure 2 is a schematic diagram of a portion of the method of the present invention. Figures 3A-B are schematic diagrams of a portion of the method of the present invention. Figure 4 is a schematic diagram of a portion of the method of the present invention. Figure 5 is a schematic diagram of a portion of the method of the present invention. Figures 6A-B are schematic diagrams of a portion of the method of the present invention. 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 method of the present invention. Figures 10A-B are schematic diagrams of a portion of the method of the present invention. Figure 11 is a schematic diagram of a portion of the method of the present invention. Figure 12 is a schematic diagram of a portion of the method of the present invention. Figure 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 of the present invention. Figure 15 is a schematic diagram of a portion of the method of the present invention. Figures 16A-B are schematic diagrams of a portion of the method of the present invention. Figures 17A-B are schematic diagrams of a portion of the method of the present invention. Figures 18A-B are schematic diagrams of a portion of the method of the present invention. Figures 19A-D are schematic diagrams of a portion of the method of the present invention. Figure 20 is a schematic diagram of a portion of the method of the present invention. Figure 21 is a schematic diagram of a portion of the method of the present invention. Detailed Description of the Preferred Embodiment of the Invention Al.0 Introduction In the old landmark-based methodology, there was a trade¬ off to be made between having too-many and too-few landmarks. If there were too many, the cell would be difficult to debug in Iview. If there were too few, then the landmark equations would become complicated and it was easy for them to be incorrect. The point-landmarks approach is an attempt to automate the process of coming up with correct equations. In this approach, a new structure (the "point" landmark) is used to identify box corners and wire points. These point landmarks have both an X and a Y location which makes it possible to have more of them without cluttering up the display. Instead of landmark equations, constraints are used between point-landmarks. 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 elements (wires, boxes and polygons) . The point must contain information about the type, layer, extension and nodes as indicated in table 1. This information is used to calculate distances 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 contacts and vias that are created in CDS. These contacts and vias are considered to have geometry on three layers - the contact or via layer plus the two layers being connected. Table 1: Type Is the point a wire center or an edge Layer The layer that the geometry is on or the type of contact or via that the point rep¬ resents. Extension The direction(s) that the geometry extends from the point. Node Electrical node that the point is on A3.0 Constraints 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 from. A3.2 Direction The direction specifies the orientation of the target with respect to the reference. For example, the constraint might specify that the target point is north of the reference point. A3.3 Type Several types of constraints are available for specifying the relationship between points. The type affects how the distance 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 . 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 before its Y coordinate can be calculated yet its Y coordinate is also dependent on X. When this occurs, the solver will pick one of the default constraints and treat it as a side constraint. Delta constraints allow user-specified values to be used instead of the minimum space dictated by the design rules. Align constraints specify that two points should be aligned in X or Y. Connect constraints are used to specify the connection • between a narrow wire and a wider wire or contact . They allow the wire to slide from one side of the contact strip to the other as long as the connection is fully maintained. Table 2: Constraint Types Side Basic 1 -dimensional constraint. Corner Corner constraints use the Pythagorean theorem if applicable when determining the distance. Default Attempts to act as a corner constraint but can be switched to a side constraint if necessary to break a cycle. Align Specifies that the points share the same X or Y coordinate. Delta A side constraint with a user-specified value. Connect Constraint used for connecting wires to contacts. Origin Used to specify an origin point. τ j-,1. A3 .4 Link The constraint link is used to specify what happens to the reference point after the target is used. Often, a point will move further 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 "attach" constraint. After a point is moved, an attempt will be made to pull all attached references towards it as much as possible. A weaker version of the attach link is also available and is called "attract" . If a reference is attracted, ■ it will be pulled in the direction of the attract, but only as far as- it can go without pushing anything else away or causing constraints to be violated. The attach will actually push things along with it if necessary. The most common link is "free". Constraints with this link do not have any effect on the reference point. Table3:ConstraintLinks Free The reference point is unaffected by this constraint Attach The reference point should be moved as close as possible to the target point, even if other points have to be moved as well. Attract The reference point should move toward the target point, but should not cause other points to be moved. This move¬ ment is done after all constraints have been evaluated. A4.0 Solving Constraints A4.1 How constraints are organized 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 is also created which contains each of these lists. A4.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 maximum value is chosen. The requirements for whether a constraint is ready to be evaluated depend on whether it is being treated as a corner 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. Align constraints have no target only a reference. When all of the references in the list have known values, the alignment can be performed. A4.3 Order of evaluation 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 depend 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 evaluate as a side constraint. This is also done in an arbitrary way and it might be better in the future to investigate ways to add some intelligence to this choice. Each time the algorithm gets stuck, one default constraint will be switched. Eventually it will be able to continue. A4.4 Attaches After a point's location is calculated, an attempt will be made to resolve any constraints which had an attach link. There are additional considerations which make the handling of attaches fairly complicated. Sometimes attaches will conflict with each other as shown in Figure 1. In Figure 1, the bold lines represent attach constraints and the numbers indicate the spacing value for the constraint. If point P3 is pulled up to P2, the distance from Pi to P4 will be 5 - 2 + 5 or 8 units. The attach from PI 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 from PI to P4 because a path can be found from PI 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 reference are analyzed to see how much slack they have. This includes corner constraints which are in the other dimension. After determining how far the point can move without causing any constraints to be broken, the point is moved. In the case of 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 not be allowed to move. This may be overly restrictive since it might be okay to move such a target if the corresponding reference can also be moved. In the future the algorithm should be enhanced to take this into account. The difference between attracts and attaches is 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 from P3 to P2 becomes critical (as shown in the middle diagram) . It will not cause P2 to move. If P3 is attached to P4 it will push P2 up as shown in the diagram on the right. A4.6 Calculating constraint values Constraint values are calculated at run-time based on the point types. Information about extension directions and overlaps is taken into account to determine how far apart the points need to be. The exception to this is delta (user) constraints where the value is user specified. A5.0 Future Enhancements A5.1 Grid Snapping There is currently no way to snap ports or other geometry to a user-defined grid. A5.2 45-degree geometry A5.3 Halation checks A5.4 Performance improvements As part of the productization effort, ways to make the evaluation more efficient should be investigated. B. Introduction to the CDS Point Landmark Design Methodology Overview This document describes some of the features of the point landmark design methodology and its advantages over the conventional method of defining and using landmarks. It is assumed that the reader is familiar with the current method of geometry generation and landmark definition. Introduction A conventional landmark consists of an integer value representing an x or a y location. There is no other information associated with the landmark, except for possibly a string representing the landmark name. If a landmark could indicate what type of geometry it represents, then, given two landmarks, it is possible to determine what the minimum required spacing is between the two landmarks. A one-dimensional landmark may partially represent the location of one or more geometry items, but cannot fully represent the location of a geometry, since a description of a location requires values in two dimensions. Because of this, a two-dimensional landmark point can better represent the geometry it is attached to. This is the main premise for the point landmark design methodology. Given the location of a landmark the geometry, it can be determined just how close in any direction another landmark point, with its geometry item type and node, c; east, of the 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 compare the y values of the two points, and, if they are far enough apart, return a value that represents 'no constraint 1 for the x position of the second point. If the y values indicate that the point landmarks are in a diagonal configuration, then the Pythagorean theorem may be applied to determine the closest possible x value for the second point. With point landmarks representing geometry locations instead of independent x and y landmarks, several of the geometry generating commands may be simplified. For example, the box routine can be replaced with a routine that requires only two arguments 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 over the point landmarks. This design methodology should shorten the learning curve for a new CDS user. Since there are no micros or macros required in the user's module code, the 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 of micros and macros total up to around 290, where the list of geometry item types is expected to be around 30. It is typically easier to identify 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 working code in less time using this method than that of the current landmark generating methods. DRC errors are often due to missing micros or macros in a landmark calculation of the module compiler code. Typically these errors are not detected earlier because they are dependent on the current ruleset. If a carefully written routine is calculating the required spacing, all spacing requirements for all rulesets would be taken into account. Even if one instance was overlooked, one change to the spacing routine DRCs of one 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) , its width (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_dir[5] ; char node [16] ; } 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 placeholders for line_of_code filename 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 structure, strcpy "PointA" to the name element, initialize the x and y values of the structure to UNDEFINED, set the item element to the number representing PYC (the items are in an enumerated list) , and strcpy "NE" into the ext_dir element and "nodel" into the node element. PointA would have previously been defined as a pointer to a structure. If a point represents a wire with an arbitrary ' 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 building blocks for the design methodology. 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 location of PointA might be defined 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: eas (PointA, 1, PointB) ; 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 would be compatible with the existing landmark design methods. An example 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-dimensional landmark constrained by another, is that the absolute distance between the represented geometries can be calculated. With a geometry attached to a one-dimensional landmark, 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 its constraining points, both the x and y values of the constraining 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 NOCDNSTRAINT. If the routine returns NOCONSTRA1NT after checking all the constraining points, then the returned value may be set equal to) the value of the minimum or maximum constraining point. Besides doing the standard 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 transistor. If the extension directions of the active within the two MACs are toward each other, and the electrical node names are different, then the MACs are most likely parts of the same transistor, and all of the rules for two MACs that are adjacent to a poly gate can be applied (See Fig. 4) . Some landmarks are determined by electrical constraints rather than physical constraints, so routines similar 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 of the structure pointed to by PointA to be the proper spacing from Points to create a horizontal n-channel transistor with a width of Wn. If the item types of PointA and Points were metal- active contacts, the routine could subtract the appropriate overlap of active-over-contact distance during the constraint calculation (see Fig. 5) . The routines tNorth, tsouth, and tWest would also be available. Arbitrary spacing values may be required in certain circumstances, such as pitch-matching metal routes to another cell, or setting a standard cell height. A routine that would allow a user to specify the distance or delta between points might look like: the distance or delta between points might look like: dWest (PointA, PointB, v2v) ; In the above 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 of PointB. This routine would only apply the distance in orthogonal directions, not diagonally. The routines dNorth, dSouth, and dEast would also be available. Standard cells have a unique spacing constraint in- that any geometries close to the left or right edges of the ell must be spaced far enough from the edge so that another standard 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 landmark using a number of calculations containing many micros and macros in the module code. If a landmark is associated with the edge of a standard cell, then any landmarks representing geometries inside of the cell can use that landmark as a constraint, and their location 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 (specified) so that they evaluate as they are executed (during run time) , or they may be defined as being symbolic, where an entry is made in a table during execution, and later evaluated. Each approach has its advantages and disadvantages. If the constraint equations are evaluated as they are executed, then the location of each point is available immediately after execution. But this requires that the order of the constraint equations 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 landmarks . 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 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 the ordering of the equations in the source code is less critical . The constraints may be evaluated in an order based on a priority tag or number (one of the arguments to the equation) . Even if the priority numbers are not 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 symbol method is that the location of the points are not immediately available 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 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) ) {... 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's value returned for evaluation in the conditional . After the remaining statements 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 landmark definitions, and the geometry definition section could be started. Point Landmark initialization and Utilities An initialization routine would probably be required to support the point landmark design methodology. The call to the routine might look like: pointLandlnit () ; Several utilities may be written to simplify the generation of landmarks . Often several geometries need to be aligned within a cell to simplify the layout process. Since each point would represent one geometry, instead of a one-dimensional landmark 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 maximum x element of each of the point structures and set all of the point structures to that value. If any of the x elements were set to UNDEFINED, or NOCONSTRAINT, then they would not be considered when calculating the MAX value, but would still be set to the MAX x element value of the remaining points. The argument name (xAlignMAX3) indicates the number 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 value that was calculated. To specify the starting point, or origin or a cell, the following routine could be used: progom( ointA) ; This routine would allow a point to be associated with a starting point (probably 0,0) without having to explicitly assign the x and y elements of 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 required offset. Geometry Generation It would be very advantageous to be able to view the defined point landmarks while viewing the associated geometry. A routine to include a landmark 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 landmark points as part of the database. If line_of_code information 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 landmark 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) ,- These macros would continue to draw the current wire or polygon to Point->x or Point->y, respectively. 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 macro would draw to Point->y, then to Point->x. These macros could be turned into intelligent routines, where the item types and locations of 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) . 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 PointA and Points are similar, then draw an array of appropriate contacts, or vias around the points. Initial Definitions Below is a list of item types and other definitions used in the prototype code for the point landmark routines (if not mentioned above) : A working prototype of an standard cell inverter module generator, along with all of the supporting code can be found in the directory /home/marc/base3/lib/src/newcds. Item types: layer items ACT active PY poly Ml metal1 M2 metal2 M3 metal3 NPLUS nplus PPLUS pplus PWELL pwell NWELL nwell CUT cut V via V2 via2 EDGE edge of standard cell 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 specified width MW metal wire BM big metal wire MWW metal wire with specified width M2W metal2 wire BM2 big metal2 wire M2WW metal2 wire with specified width M3W metal3 wire BM3 big τnetal3 wire 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 via MMVZ metal2-to-metal3 via SCON substrate contact PCON pwell contact Other definitions: #define UNDEFINED 0x7FFFFFFF /* largest INT32 #define NOCONSTRAINT -Ox7FFFFFFF /* smallest INT32 #define DEF_POINT(pname, itm,extd,nodname) \pt= (POINTRECORD *)malloc (sizeof (POINTRECORD) ) ;\ strcpy(pt->name,pname) ;\ pt->item= (itm) ,-\ pt->x=UNDEFINED; \ pt->y=UNDEFINED; \ pt->width=0;\ strcpy(pt->ext_dir,extd) ,- \ strcpy (pt->node,nodname) #define NORTH 8 /* for use with extension directions #define SOUTH 4 #define EAST 2 #define WEST 1 C. Constraint Generation Overview C1.0 Graf Data Structures Cl.1 Elements Graf is built on top of the point-landmark data structures. The basic geometry elements in graf (boxes, wires, etc.) use points rather than x-y coordinate pairs to specify locations. The types of elements are: boxes--a box consists 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 of 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 contain geometry on three different layers--the contact 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 "llBorder" and "urBorder" . Constraints are generated between the border and points which are near the edge of the cell. Cl.3 Edges For the purpose of generating constraints, edge data structures are created. Edges are similar to landmarks in CDS except that they have a start and end (rather than being a continuous line) . These data structures are generated for each edge of a box or polygon and for the centers of wires, strips and squares. In general, each point will be represented by an X and a Y edge. It is common for two points to be represented by the same edge. The edges contain information about what points they represent. They also contain pointers to edges on the opposite 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.0 Constraint Generation Table 1: Graf Layers Geometry Layers active poly metal metal2 nplus pp us nwell pwell Contact Layers nactivecut pactivecut polycut via Other border C2.1 Ports The first constraints generated are for ports. A list of elements touching the port is generated and an attempt is made to pick a point from one of these elements which 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 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-ele ent constraints In this step, constraints pertaining to points within an element are generated. This involves 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 "side-attract" constraints. 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 A small amount of pre-processing is done before generating contact and connect constraints. This usually entails extending wires further 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 connectivity. 2.4 Contact constraints Constraints are generated between contacts and elements which connect to them. This step is probably going to be phased 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 dimension. • One edge touching one edge • One edge between two edges • Two edges connected to two edges • Two edges connect The first 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. 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 used in this step. Some exceptions are: • A box connecting to a wire. If the box extends past the closest edge of the wire and ends on the farthest edge then a side constraint will be used. • A contact which touches a wire without overlapping. A "touch" constraint will be used in this case. The difference between the connect and touch constraints is shown below in Figures 10A-B. The two structures in Fig. 10A show the play allowed in a wire connected to a contact using a connect constraint. The two structures in Fig. 10B 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 conductive layers. These constraints are skipped for the implant and well layers. To generate these constraints, the data structure for edges is used. An array of edges (in each dimension) is constructed and sorted by coordinate. This array contains 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 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 E . This is because E3 represents geometry that extends to edge E5. These edges don't need constrained because they are taken care of 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 dimension).. When E2 and E4 are compared, a constraint will not be ■ generated because 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 far to the side it is. Diagonal constraints may be significant between items which don' t directly cast a shadow on each other. A fudge factor is used to determine how far to the side two edges can be before they are considered insignificant. Edges in the orthogonal dimension are also considered for purposes of filtering out unnecessary constraints. For- example, if there were a long vertical wire between E2 and E8, there would definitely be no constraint generated. 2.7 Inter-layer constraints Constraints are generated between layers. This is done between active and each of 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. 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 constraint allows a contact to move from one-side of a wire to the other, it is possible that a constraint is missed. One example of where this can happen is shown in Figure 12. The contact edge E3 is above E2. The constraint generation algorithm will generate a constraint 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 fix 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 appropriate) . 3.0 Constraint Cleanup 3.1 Filtering Some constraints are discarded immediately through various filtering rules. A couple examples are: • 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. • Two X-edges must overlap in the Y-dimension or at least come within some fudge-factor of overlapping. (The same applies for Y-edges overlapping in X) . 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 them. 3.2.1 Identify corner constraints The first operation is to find the case where two default constraints exist between the same two edges one in X and one in Y. One of the constraints will be removed and the other will be turned 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 constraints. If the two points represent elements having the same width, such as a big-metal wire and a contact, the constraint is turned into an align. They should be functionally identical but aligns are more easily processed than attaches. 3.2.3 Turn overlaps into attaches The constraints are analyzed to determine if they represent an overlap condition (such as pplus overlapping active) . If the constraint is exactly satisfied, it is assumed that this is 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. 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- contact to an active contact. If the constraint is exactly satisfied in the original design, it is turned into an attach. This tends to keep the contact at the top instead of letting it fall to the bottom. 3.2.5 Cleanup well-constraints This algorithm removes constraints between wells and objects which are in different wells. For example, in Figure 13 two wells are shown, each containing an active box. The constraint shown, from the active on the left to the well on the right, is not necessary and would be deleted. 3.2.6 Change 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 dimension 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 improves the efficiency of the constraint solver and sometimes yields better results. 3.2.7 Cleanup geometry port constraints 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 removal 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 referencing point B and 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 of 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 Standard Cells and Buffer Sizing Standard-cell and buffer-sizing constraints are implemented using our methodology. When doing buffer-sizing, the transistor width is compared 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. Standard-cell constraints consist of the following: 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 slipping down. It also tends to keep the ports more toward the center of the cell. In the future we intend to experiment with constraints that will move the ports further to the center if there is no effect on density. 4.4 Pitch-match nwell if the original cell conformed to the height 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 standard-cells will have a different set of requirements. For them, many of the Y-coordinates are pre¬ determined and can be specified through user constraints. The point-landmarks code has certain rules for constraining 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 specifying grid constraints. 5.0 Other Technologies Some attempts have been made to make this prototype technology independent. There is some cmos-specific code, but most of the technology specific information is contained in a start-up file which is parsed in at run-time. The point- landmarks code which this is built on top of would be more of a concern in converting to other technologies . A different set of filtering and cleanup routines may need to be provided for other technologies. 6.0 User functions and variables Users can make their own functions and variables available to graf by editing a file and recompiling. This is similar to the way Verilog-XZ, and certain other products with C-language interfaces work. Variables in the rules file are available by default. D. Software Requirements Specification for the CDS Point Landmark Design Methodology Dl.0 Introduction Dl.i Purpose The purpose of this document is to describe enhancements to the CDS language. It is intended for use by CDS users, including Cascade Design Automation Module Designers. D1.2 Scope The scope of this software specification is to define a method of associating landmarks with geometries so that constraints between landmarks can be calculated by specific routines rather than discrete equations, and also to define geometry generating routines compatible with the current CDS geometry generating routines that take advantage of two- dimensional point descriptions rather than one-dimensional landmark 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 that are related to the defined functions 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 Automatic constraint generation Graphical CDS geometry editor D1.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 Dl.4 References Introduction to the CDS Point Landmark Design Methodology, Marc Buchanan, Cascade Design Automation Software Requirements Specification for CDS Enhancements for base cells, Brad Roetcisoender, Cascade Design Automation XBased Layout Viewer Requirements Specification, Doug Sebastian, Cascade Design Automation Dl.5 Overview This software requirements specification describes the details of a CDS point landmark, how it should be used, and what its structure contains. Also described are the constraint routines that use this point landmark. The function of the constraint routines are to calculate the location of a point landmark with respect to other point landmarks. Using the information attached to each point, the routines can calculate the x- or y- location of a point so that the minimum possible distance between the geometries represented is achieved without any DRC or LVS 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 . Several geometry generation routines are also described. These routines take advantage of the information associated with the point landmarks to simplify code writing and to make the module code less susceptible to errors when applied to multiple rulesets . A2.0 General Description 2.1 Product Perspective All of the routines and definitions described in this document 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 CellDefineO and CellEnddef () routines as described in the document Software Requirements Specification for CDS Enhancements for base cells. The point definitions and the constraint routines may be used before or after the CellDefineO routine, but must be used before any of the geometry generation routines that reference a point landmark are used. If a cell is compiled with the line_of_code debugging information 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 program. This information includes point landmark locations, extension directions, and relative constraints to other point landmarks. See the document Xbased Layout View Requirements Specification for details on how this information will be represented within the Lview program. 2.2 Product Functions 2.2.1 Point Landmark and Landmark Routines A point landmark is used to mark the location of a geometry item (i.e. poly-metal contact, end of a metal wire, etc.) and store information in a structure describing the name of the landmark, the geometry item, the direction the geometry extends from the point, the electrical node name of the represented geometry, and optionally the width of the geometry (if the point is representing an arbitrary with wire) , and the line_of_code information (file name, line number, and constraint reference points) . The landmark routines are used to name and partition groups of landmarks, 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. 2.2.3 Geometry Generating Routines The geometry generating routines are used to create geometries in the geocell database. The functions will be similar to the current CDS geometry generating routines in that they will create boxes, wires, etc., but with fewer arguments. Some of the information required to describe the geometries being created will come from the point landmarks referenced in the argument lists of the routines. 2.3 User Characteristics The routines described in this document are intended to be used by a CDS Module developer. 2.4 Benefits The described 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 contained within CDS, but instead use the 30 to 40 geometry item types used by the routines . These geometry item types are more intuitive to use since they represent common layout geometries, instead of the various widths, spacing values, and overlaps represented by the micros and macros . These routines are intended to replace the current equations and geometry routines 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 these new routines, while leaving the bulk of the code unchanged. 2.5 General Constraints Other than the constraints described in the previous sections, the only concern that the programmer might have, is that the order the routines are specified in the code may affect the outcome of the physical layout. In certain instances, the programmer should try re-ordering the constraint routines to find an optimal solution. 3.0 Specific Requirements 3.1 Functional Requirements: Point Landmark Definition, and Landmark 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 landmark, the x and y location, the geometry item type, the width of the represented wire (if the point represents an arbitrary width wire) , the extension directions of geometries from the point, and the electrical node name. If the line_of_code debug flag is set, then a list of constraint reference points, line_of_code file name, and line_of_code line number information will also be contained within the point structure. 3.1.1.2 Processing The elements of 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 3.1.2.1 Introduction The newPointGroup routine is used to define a new group which will contain a set of points and symbolic constraints. The syntax is shown here: newPointGroup(group_name) ,- 3.1.2.2 Inputs group_name - char* indicating the name for a group of landmarks and constraints . 3.1.2.3 Processing The newPointGroup routine is a required routine that will first verify that the group does not currently exist, then create static pointers to a new point list and a new symbolic constraint (SC) table. This group will then become the currently active group and any points or constraint as defined subsequent to the newPointGroup call and previous to another newPointGroup or setPointGroup call will belong to the specified group. Points and constraints within different groups will be independent of one another. If group_name has been previously defined and not freed by a subsequent call to freePointGroup, an error will be reported. A call to the newPointGroup must be made prior to defining any points or symbolic 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 3.1.3.1 The setPointGroup routine is used to change the current active group as defined with a newPointGroup call . The syntax of the command 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. Any points or constraints defined subsequent to the call (until 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 memory used by the various point and constraint definitions within the specified group, and to remove the group pointers, The syntax of the command is: freePointGroup(group_name) ; 3.1.4.2 Inputs group_name - char* indicating the name for the point/SC group. 3.1.4.3 Processing The freePointGroup routine will verify 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 routine must 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 command to define 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: name - a char* that contains the string representing the name of the point landmark. item - an INT32 containing the item number of the geometry represented by the point landmark. Macro names from an enumerated list will be used for this argument. See geometry item types at the end of this document. ext_dir - a char* containing any or all of "NSEW" , which represent the extension directions of the geometry represented by the landmark. node_name - a char* containing the string representing the electrical node name of the represented geometry. 3.1.5.3 Processing As this routine is executed, it will first allocate the amount of space required to contain the structure, then the arguments will be copied to the appropriate elements of the structure. Also, the x, y, and width elements will be initialized with the integer representing UNDEFINED. As various constraints are evaluated, the x and y elements ' will be modified to contain the location of the point landmark. Two integer values are reserved to represent a location that is either undefined, or found not to be constrained by any other points. These values are defined as UNDEFINED and NOCONSTRAINT, respectively. 3.1.5.4 Outputs The routine will return a char* containing the name of 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 command is: point_width(point,width) ; 3.1.6.2 Inputs point - char* indicating the name of the point to have its width modified. width - *INT32 indicating the geometry width. 3.1.6.3 Processing 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. An error will be reported if the item type of 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 Requirements: Constraint Routines Setting the origin of a cell 3.2.1.1 Introduction To set the origin or starting point for the constraint equations, the following command 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. Since the origin routine and the point group reference routines each set the location of a point to an absolute 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 status. 3.2.2 Setting the absolute location of a point 3.2.2.1 Introduction A user may be required to set the location of a point that is not dependent on any other point landmarks, but is dependent on some other object, such as a placed cell. To allow for situations like this, routines are needed to allow the user to set the absolute location of a point. Three routines that will allow the user to set 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 absolute location for the y element of the point 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 evaluated, the x element of the point will be set to the value specified by x. Similarly, 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 specified by y. The pSetLoc routine will place two entries in the current 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 taken when using these routines. Since the location of the point is solely based on the arguments as specified by the user, the system cannot verify that the point will be referencing the same origin as the other 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 determine the location of a point based on the location of a point defined within a different group. The syntax for each of the point group reference routines is shown here: pRefGroup(pi, ref_pt,group_name) ; pxRefGroup(pi, ref_pt,group_name) ; pyRefGroup(pi, ref_pt,group_name) ; 3.2.3.2 Inputs pi - char* indicating the name of the point. ref_pt - char* indicating the name of the point within the group. group_name - char* indicating the name of the group to reference 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 (if applicable) of refpt and pi 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 evaluated. The location of refpt (x only for pxRefGroup, y for pyRefGroup) will then be copied to pi . Errors will be reported if the group specified by group_name does not exist, or if the point ref_pt does not exist within that group. An error will be reported if the SC table within the group specified 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. 3 . 2 . 3 . 4 Outputs The routines will return an INT32 representing their status. 3.2.4 The delta 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 the current group. The syntax for each of the routines is shown here: dxRefGroup(ref_ptl, ref_pt2,group_name) ; dyRefGroup(ref_p l,ref_pt2,group_name) ; 3.2.4.2 Inputs ref_pl, ref_p2 - char* indicating the names of the reference points. 3.2.4.3 Processing Each of the delta group reference routines will first verify that the group and points specified by group_name, refpi, 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 immediately 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. 3.2.5 The directional physical constraint functions 3.2.4.1 Introduction The directional physical constraint routines use the common compass names to indicate the location of a point landmark with respect to one or more reference point landmarks. The syntax of each of the direction physical constraint routines are shown here: north(pi, ref1) ; north2 (pi, ref1, ref2) ; north3 (pi, ref1, ref2, ref3) ; north4 (pi, refl, ref2, ref3, ref4) ,- north5 (pi, refl, ref2, ref3, ref4, ref5) ,- south(pi, refl) ; south2 (pi, refl, ref2) ; souths (pi, refl, ref2, ref3,ref4,ref5) ; east (pi, refl) ; east2 (pi, refl, ref2) ; easts (pi, refl,ref2, ref3, ref4, ref5) ,- west (pi, refl) ; west2 (pi, refl, ref2) wests (pi, refl, ref2,ref3,ref4, ref5) ,- The multiple routines with enumerated names for each function 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. 3.2.5.2 Inputs pi - char* indicating the name of the point to have its x or y element modified (the east and west commands will modify the x element, the north and south commands will modify the y element) . refl, ...ref5 - char* indicating the names of the reference points. 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 between the point pi and the reference points refl...ref5. When this constraint is evaluated by calling the evalConstraints, xEval, or yEval routine, the location of pi will be determined by applying all known physical layout rules to the geometries represented by the point pi and the reference point (s) refl (,ref2, ... ref5) . During the evaluation of a constraint, the geometry item of pi would be compared with that of refl to determine the required distance between them, then with ref2, etc. and then use the worst case distance to determine the location of pi. A point may represent a complex geometry item, a wire, the edge of a geometry, or the edge of a standard cell. A complex item would represent multiple geometries such as a poly-metal contact, which contains geometry on three different layers - metal, poly, and cut. A wire item would represent the center of a single-layer wire, and a layer item would represent the edge or corner of a single layer geometry. The cell edge item would represent the left or right edge of a standard 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 spacing. Figures 14A-B show how the horizontal location of pi may be set by referencing refl. Diagonal space checking is required to obtain optimal density of a layout. If the x and y location of the reference point is known, and 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 14B) . The routines are to be able to determine when the point pi and a reference point are representing metal active contacts on opposite sides of a transistor. If the extension directions of pi 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 (see Figure 15) . As each constraint equation is executed, an entry will be put in an SC table until a command is executed to evaluate the constraints. During evaluation, if the x location of pi 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 UNDEFINED, 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 evaluated, but the x location of pi still needs to be set and the y location of any of the points is still UNDEFINED, then the worst-case spacing 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 pi is being set and the x location of all of the reference points is set to NOCONSTRAINT, or the y location of any of the reference points or the set point is set to NOCONSTRAINT, then the constraint will be skipped. A second pass through the SC table will then be required. If, after several passes through the SC table, the evaluation routine has reached a point where no more constraints can be evaluated and the x location of pi has not yet been set, and the y location of any of the reference points is still set to NOCONSTRAINT, .then the worst-case spacing from that point will be calculated (no corner-to-corner checking) . If pi and the reference point have the same node name, and the items are of the same layer, or one point is simple and the other is complex and contains a geometry of the same layer, then off-set spacing will be applied, i.e., if pi represents a poly- metal contact, and refl 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, meaning that the worst-case constraint defined will be used (unless a delete constraint function had been executed after the first constraint definition and 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 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 NOCONSTRAINT values) , the constraint will not be evaluated, even if no other constraints can be evaluated. The syntax is as follows : cNorth(pl, refl) ; cNorth2 (pi, refl, ref2) ,- cNorth3 (pi, refl, ref2,ref3) ; cNorth4 (pi,refl, ref2,ref3, ref4) ,- cNorthS (pi,refl, ref2, ref3, ref4, ref5) ,- cSouth(pi, refl) ,- cSouth2 (pi, refl, ref2) ; cSouth5 (pi, refl, ref2, ref3, ref4, ref5) ; cEast (pi, refl) ; cEast2 (pi, refl, ref2) cEast5 (pi, refl,ref2,ref3, ref4,ref5) ; cWest (pi, refl) ; cWest2 (pi, refl, ref2) ; cWest5 (pi, refl,ref2, ref3, ref4, ref5) ; 3.2.6.2 Inputs pi - char* indicating the name of the point to have its x or y element modified. refl, ... ref5 - char* indicating the names of the reference points for determining the location of pi. 3.2.6.3 Processing The corner-check physical 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, before the constraint will be evaluated. Unlike the directional physical constraint routines which will do corner-to-corner checking only if the information is available, these routines require that the 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 dimension physical constraint functions 3.2.7.1 Introduction The single dimension physical constraint routines are similar to the directional physical constraint routines described above with the exception of no corner-to-corner checking. The syntax is as follows: sNorth(pl, refl, width) ; sSouth(pl, refl, width) ,- sEast(pl, refl, width) ,- sWest (pl , ref l , width) ; 3 .2 . 7 .2 Inputs pi - char* indicating the name of the point to have its x or y element modified. refl, ...ref5 - char* indicating the names of the reference points for determining the location of pi . 3.2.7.3 Processing 3.2.7.4 The function of the single dimension physical constraint routines are equivalent to that of the directional physical . constraint routines described above except for that corner-to- corner 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 dimension 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: nort (pi, refl) ; sNorth(pl,ref2) ,- cNorth(pl, ref3) ; In the above example, point pi will be constrained by points refl, ref2, and ref. When the constraint is evaluated between pi and refl, corner-to-corner checking will be done if the x elements of pi and refl are known (which may take several passes through the SC table) , otherwise no corner-to-corner checking will occur. When the constraint is evaluated between pi and ref2, no corner-to-corner checking will be done, and the constraint between pi and ref. will require that corner-to- corner checking be done. Before the group of constraints will be evaluated, the y elements of points refl, ren, and ref. must be known, and the x elements of pi 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 the conditions are met. If the conditions are never met, an error will be reported. 3.2.7.5 Outputs The routines 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 pi - char* indicating the name of the point to have its x or y element modified. refl - char* indicating the name of the reference point. refl - c delta - INT32 indicating the desired distance in an orthogonal direction pi is to be placed from refl. 3.2.8.3 Processing The routine dNorth, when evaluated, will modify the y element of pi to be equal to refl->y + delta. The routine dSouth will modify the y element of pi to be equal to refl->y - delta. The routine dEaεt will modify the x element of pi to be equal to refl->x + delta. The routine dWest will modify the x element of pi to be equal to refl->x - delta. If a DRC error is likely to occur between the represented geometries of pi and refl, a warning will be reported.- If the specified delta is not a multiple of gridsize, ' an error will be reported. 3.2.8.4 Outputs The routines will return an INT32 representing their status. 3.2.9 The attach constraint functions 3.2.9.1 Introduction The attach constraint routines have the same function as the respective directional, single dimension, 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: northAttach(pl,refl) ,- southAttach(pl, refl) ; eastAttach(pl, refl) ; westAttach(pl, refl) ,- cNorthAttach(pi, refl) ,- cSouthAttach(pi, refl) ; cEastAttach(pl, refl) ; cWestAttach(pl,refl) ; sNorthAttach(pl, refl) ,- sSouthAttach(pl, refl) ; sEastAttach(pl,refl) ,- sWestAttach(pl, refl) ; dNorthAttach(pi, ref1,delta) ,- dSouthAttach(pi, refl,delta) ; dEastAttach(pi, refl,delta) ,- dWestAttach (pi,ref1,delta) ,- 3.2.9.2 Inputs pi - char* indicating the name of the point to have its x or y element modified. refl - char* indicating the name of the reference point for determining , the location of pi. delta - INT32 indicating the desired distance in an orthogonal direction pi 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 reference point will move with it. All other functionality of the attach constraint routines are equivalent to the respective directional, single dimension, and corner-check constraint routines. If the set point is constrained by more than one reference point, and a non-critical (not worst case) reference point is attached to the set point, then the attached reference point will be moved as close as possible to the set point without violating any of the defined constraints. Figure 16A shows an example where pi is constrained by refl and ref2, and ref2 is the critical reference point. Figure 16B shows how the point refl will be moved if the constraint between pi and refl. is changed from an east constraint to an eastAttach 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 reference point is allowed in the attach constraint commands, 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 transistor of the specified width. The syntax is as follows: tNorth(pl, refl, width); tSouth(pl, refl, width) ; tEast (pi, refl, width) ; tWest(pl, refl, width) ; 3.2.10.2 Inputs pi - char* indicating the point to have its location set. refl - char* indicating the reference point, width - INT32 indicating the desired width of the transistor. 3.2.10.3 Processing The transistor constraint routines use the width argument to determine the distance from the reference point to place the point pi. Offsets will be applied to the point location pi based on the geometry types of pi and refl . For each point that represents a metal-active contact of an n- or p- channel transistor (NMAC or PMAC) or an n- or p- channel big active wire (PBA or NBA) the offset [hac] 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 represents an n-channel poly gate (NGL) with extension direction(s) only parallel to the gate direction, the offset [ngtx - ngl + hac] will be applied. For each point that represents a p-channel poly gate (PGL) with extension direction(s) only parallel to the gate direction, the offset [pgtx - pgl + hac] will be applied. For each point that represents an NGL with extension direction(s) perpendicular to the gate direction, the offset [ac2ngtx - ngl - hac] will be applied. For each point that represents a PGL with extension direction(s) perpendicular to the gate direction, the offset [ac2pgtx - pgl - hac] will be applied. No offset will be applied for points representing active (ACT) . For the CMOS technology, if the geometry item type of either of the points is other than NMAC, PMAC, NBA, PBA, AW, AWW, NGL, or PGL, then an error will be reported. If the item types of pi 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 pi will be modified. The extension direction perpendicular to the gate direction will be removed (See Figures 17A-B) . If the width of the transistor is less than new (for n- channel transistors) or pg. (for p-channel transistors) an error will be reported. If the point geometry item types represent different 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 reference point (see the attach constraint functions above) . D3.2.10.4 Outputs The routines will return an INT32 representing their status. D3.2.11 The align routines D3.2.11.1 Introduction The align routines are used to vertically or horizontally align two or more point landmarks . The syntax for the various align routines are shown here: xAlign(pl,p2) ; xAlign3 (pi, p2, p3) ; xAlign4 (pi, p2, p3, p4) ; xAlignδ (pi, p2, p3, p4, p5) ; yAlign(pl,p2) ; yAlign3 (pi, p2, p3) ; yAlign4 (pi, p2, p3, p4) ; yAlign5 (pi, p2, p3, p4, p5) ; D3.2.11.2 Inputs pl..p5 - 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 landmarks, and the yAlign routines are used to vertically align two or more point landmarks. The xAlign routine first checks the direction of the constraints on point specified by the arguments, and then sets each of 4h x elements of the structures pointed to by the arguments to the minimum (for west constraints) or maximum (for east constraints) value in the set (UNDEFINED and NONCONSTRAINT values will not be considered when finding the minimum/maximum value) . The yAlign routines operate 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 the point in the argument list will stay the same. Since these routines can potentially modify a point that constrains another point, during evaluation, the SC table must be searched for constraints that use any of the arguments as reference points and mark them as needing re-evaluation (if they have been previously evaluated) . If any of the arguments belong to a group of attached points, then any constraints that reference any of the points 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 commands are used to delete a previously defined constraint. The syntax is shown here: xDeleteConstraint (pi) ,- yDeleteConstraint (pi) ,- 3.2.12.2 Inputs pi - 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 west routines. It will also examine any x-direction alignment commands and, if pi exists as an argument, remove it from the argument list, or remove the whole alignment constraint 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- direction alignment routine. If no constraint previously exists on pi, a warning message will be displayed. 3.2.12.4 Outputs The routines 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: cNorthCheck(pl,refl) ,- cSouthCheck(pl, refl) ; cEastCheck(pl,refl) ; cWestCheck(pl, refl) ; sNorthCheck(pl,refl) ,- sSouthCheck(pl, refl) ; sEastCheck(pl,refl) ; sWestCheck(pl, refl) ; dNorthCheck(pi,refl,delta) ; dSouthCheck(pi,refl,delta) ,- dEastCheck(pl,ref1,delta) ; dWestCheck(pi,refl,delta) ; 3.2.13.2 Inputs pi - char* indicating the point name. refl - char* indicating the reference point name. delta- INT32 indicating the allowed distance between pi and refl.. 3.2.13.3 Processing The function of the constraint check routines is similar to that of the corner-to-corner, single dimension, and delta physical constraint routines in that they are used to calculate the distance between the points pi and refl, but instead of setting the location of pi, will report the difference between the calculated location for pi and the actual location of pi. The returned value will be equal to the difference between the actual location of pi and the calculated location of pi in the direction specified by the name of the constraint check. If the actual location of pi extends beyond the calculated location in actual the specified direction from refl, then a positive integer will be returned. If the actual location and the calculated location of pi extend an equal amount from refl in the direction specified, the value O will be returned, and if the actual location does not extend as far as the calculated location of pi in the specified direction from refl, a negative integer will be returned. This information can be used to determine an error condition, since a value that is negative indicates a possible DRC error. The routines sNorthCheck, sSouthCheck, sEastCheck, and sWestCheck will calculate in a single dimension (either horizontal or vertical) the minimum required distance between pi and refl. The routines will then compare this distance to the actual single dimension distance. The routines cNorthCheck, cSouthCheck, cEastCheck, and cWestCheck will calculate the absolute minimum required distance between pi and refl, and then compare the x element (for 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 pi . The routines dNorthCheck, dSouthCheck, dEastCheck, and dWestCheck will use the value of delta as the required space (in a single dimension) between pi 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 definitions exist that have not been evaluated, an error will be reported. For the routines sEastCheck, sWestCheck, dEastCheck, and dWestCheck, if the x element of pi or refl is set to UNDEFINED or NOCONSTRAINT, then an error will be reported. For the routines sNorthCheck, sSouthCheck, dNorthCheck, - and dSouthCheck, if the y element of pi or refl is set to UNDEFINED or NOCONSTRAINT, then an error will be reported. For the routines cNorthCheck, cSouthCheck, cEastCheck, and cWestCheck, if the either the x or y element of pi or refl is set to UNDEFINED or NOCONSTRAINT, 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. 3.2.14 The xEval and yEval routines 3.2.14.1 Introduction The xEval and yEval routines 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 is shown here: xEval(point) ; yEval(point) ; The intended use for these routines is to determine the value of a point structure's x or y element before all of the constraints have been defined. A user may require that definition of a landmark or group of landmarks depend on the relative location of two previously defined landmarks. Since the actual location of a landmark is not available until its constraint equations have been evaluated, these previously defined landmarks must be evaluated before their locations can be compared. An example of how the xEval routine might be used is shown here: if (xEval(pl) > xEval(p2)) east(p4, pi); else west(p4, p3) ; In the above example, the constraint definition of p4 is determined by the relation of pi and p2. The xEval routine evaluates any of the previously defined constraints so that the x location of pi 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 returned. 3.2.14.3 Processing The xEval and yEval routines will attempt to evaluate all of the constraint equations defined previous to its call. If a constraint equation cannot be evaluated because of a reference point with an x or y element that is set to UNDEFINED or NOCONSTRAINT, then it will be skipped and another pass through the SC table required. When all of the constraints have been evaluated, or no additional constraints evaluated after one full pass, then the x element (for the xEval routine) or the y element (for then tt the yEval routine) of the point structure will be returned. If the value is set to UNDEFINED or NOCONSTRAINT, 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.14.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 from the yEval 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 of the constraints entered into the SC table . Its syntax is shown here: evalConstraints 0 ; A call to this routine will be required before referencing any of the point landmarks from a geometry generating routine. 3.2.15.2 Inputs There are no direct inputs to the evalConstraints 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. 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 UNDEFINED, or a north or south constraint that references a point with a y element set to UNDEFINED, 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 of its reference points with y elements set to NOCONSTRAINT, the constraint will be skipped. As each constraint is successfully evaluated, the evaluate flag of the 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. After the evaluation process has completed, the locations of the point landmarks can be verified by making one more pass through the SC table. If any constraints are violated, a warning will be reported with the name of the constraint . If any x or y elements of the point structures are still set to UNDEFINED, then they should be listed as having no constraint definition, and an error reported. If an xEval or a yEval routine had been previously executed and no additional constraints were defined, then evaluation of the constraints is not necessary, so no evaluation will occur. However the checks for unevaluated constraints, violated 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 example, if an east constraint had been placed on a point, then an error would be reported if a west constraint were placed on the same point. Cyclical reference paths are not allowed. All references of all points must directly or indirectly reference 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 for an xAlign routine must have at least one constraint in the horizontal direction other than an align constraint. Any additional 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 constraints on any of the points must all be in the same direction. Any points in the argument list for an xAlign constraint must not reference any of the other points in the argument list in a different horizontal constraint. Any points in the argument list for a yAlign constraint must not reference any of the other points in the argument list in a different vertical constraint. 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 attached to more than one reference 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 landmark information into the database. The names and coordinates of each defined landmark 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 the reference point list is also included for each point landmar . The syntax is shown here: tPoints (group_name) ; 3.3.1.2 Inputs group_name - char* indicating the name for a group of land- marks. 3.3.1.3 Processing The tPoints routine will reference the pointer to the. first (last) point landmark containing the specified group name and place the point landmark name and coordinate into the current database. The next (previous) point landmark will be referenced by using the 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 landmark 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 database must be open before executing the tPoints command 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 The pBox routine is a geometry generating routine that will create a rectangular geometry. The routine will automatically calculate the required overlap of 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 pi, p2 - char* indicating opposite corners of the box to be created. 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 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 commands. The syntax is shown below: pWire (width,pi) ,- 3.3.3.2 Inputs width - INT32 indicating the desired width of the new wire, pi - char* indicating the location to start the wire. 3.3.3.3 Processing The function of the pWire routine will be very similar to that of the wire routine. The wire width will be set by the width argument, and the starting location will be determined by the x and y elements of the structure point to by pi. If the iterm type of pi does not indicate a geometry on the same layer as the current drawing layer an error will be reported. 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 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 is shown below: px(pl) ; py(pl) ; 3.3.4.2 Inputs pi - char* indicating the x or y location to draw the current wire. 3.3.4.3 Processing The px routine will draw the current wire in the horizontal direction to the value specified by the x element of the structure pointed to by pi. 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 pi. After the wire has been drawn, if the end point of the wire is located exactly at the location of pi, then intelligent wire operations may occur if the next wire routine to be used is either the pxy or pyx command. 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 warning will be reported. 3.3.4.4 Outputs The routines will return an INT32 representing their status. 3.3.5 The pxy and pyx routines 3.3.5.1 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 decisions as to how to draw the wire is certain situations to help avoid DRC errors. For example, if a metal width wire is being drawn from a poly-metal contact to another poly-metal contact, the wire may be automatically shifted by the value dmc to avoid any possible metal "notches", . And if the two.poly-metal contacts happen to ' be close enough to create a metal spacing error, the wire width may be increased to fill in the gaps. The syntax is shown below: pxy(pi) ; . pyx(pi) ; 3.3.5.2 Inputs pi - char4 indicating the new location to draw the current wire. 3.3.5.3 Processing The pxy routine will draw a wire with a width specified by the width argument in the last pWire or wire routine to the location first in the horizontal direction to pl->x, then in the vertical direction to pl->y. The pyx routine will draw a wire with a width specified by the width argument in the last pWire or wire routine to the location first in the vertical direction to pl->y, then in the horizontal direction to pl->x. If the starting point of the wire segment being drawn represents a geometry on the current drawing layer that is wider than the current wire width, and the location of pi is in a nonorthogonal direction from the starting point, then the wire starting point will be shifted 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 pi is wider than the current wire width, the wire ending point will be shifted to the closest edge of the geometry represented by pi. After the wire segment is drawn, the reported wire end point will be shifted back to the location of pi. If the pxy or pyx command is creating a wire segment between two points that are close enough to create a DRC error ' when considering the item types 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 19A-D) . Figure 19A shows a wire drawn up to the start point. Figure 19B shows a wire continued to pi. Figure 19C 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 Outputs The routines will return an INT32 representing their status. 3.3.6 The pContacts routine 3.3.6.1 Introduction 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 of the point landmarks. The syntax is shown below: pContacts (pi,p2) ,- 3.3.6.2 Inputs pi, 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 contacts, substrate contacts, pwell contacts, vias, or via2s. The type of contacts drawn will depend on the item type of the point landmarks. The maximum dep number of contacts possible will be placed in a fiay configuration in the box defined by the two point landmarks pi and p2 with the appropriate overlap. This routine will work similar to the contacts routine. The item types allowed are NMAC, PMAC, PYC, SCON, PCON, VIA, and VIA2 (see the description of geometry item types below) . If the item type of either of the point landmarks is something other than these, an error will be reported. An error will be reported if the item types of the two point landmarks do not match. 3.3.6.4 Outputs The routine will return an INT32 representing its status. 3.3.7 The pxContacts and pyContacts routines 3.3.7.1 Introduction The pxContacts and pyContacts routines work similar to the pContacts routine, except that only one row of contacts is generated instead of a full array. The first argument will represent an "anchor" point for the row of contacts, and the second argument will determine length of the row. Typically 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 example of how the rows of metal-active contacts can be generated with the pxContacts routine. The syntax of the routines is shown here: pxContacts (pi,p2) ; pyContacts (pi,p2) ; 3.3.7.2 Inputs pi - char* indicating the anchor point for the row of contacts. p2 - char* indicating the opposite end point of the contact array by the x or y element in its structure. 3.3.7.3 Processing The pxContacts routine will create a horizontal row of contacts from the location indicated by pi to the coordinate p2- >x, pl->y. The pyContacts routine will create a vertical row of contacts from the location indicated by pi to the coordinate pl- >x, p2->y. An overlap value appropriate to the item type of pi will be applied to each end of the row. The item type of pi must be one of the following: NMAC, PMAC, PYC, SCON, PCON, VIA, or VIA2 - otherwise an error will be reported. 3 . 3 . 7 . 4 Outputs The routines will return an INT32 representing their status . 3.3.8 The single contact routines 3.3.8.1 Introduction The single contact routines will place a contact macro (group of geometries) of the specified type centered at the point landmark. The syntax of each of the routines is shown here: pPYM(pl) ; pMA(pl) ; pM2M(pl) ,- pM3M2(pl) ; pVIA(pl) ; pVIA2(pl) ; 3.3.8.2 Inputs pi - 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 pi . Any extensions of poly in the direction of metal will be determined by the extension directions specified by the point structure. The pMA routine will place a metal-active contact centered at point pi . The pM2M routine will place a metal-to-metal2 via centered at point pi . The pM3M2 routine will place a metal2-to-metal3 via centered at point pi. The pVIA routine will place a via (metal-to-metal2) centered at point pi. No metal or metal2 geometry will be included. The VIA2 routine will place a via2 (metal2-to-metal3) centered at point pi. No metal2 or metal3 will be included. If the item type of pi does not match the type of contact being at pi, an error will be reported. 3.3.8.4 Outputs The routines will return an INT32 representing 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 landmarks required as arguments . The minimum overlap of 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(pi,p2,p3) ,- pPolygon3 (pl,p2,p3) ; pPolygon4 (pi,p2,p3,p4) ; pPolygon5 (pi,p2,p3,p4,p5) ; pPolygonδ (pl,p2,p3,p4,p5,p6) ; pPolygon7 (pi,p2,p3,p4,p5,p6,p7) ; pPolygonβ (pi,p2,p3,p4, 5, 6,p7,p8) ; pPolygon9 (pi,p2, 3 ,p4,p5,p6,p7,p8,p9) ; 3.3.9.2 Inputs pi - p9 - char* indicating corner points of the polygon. 3.3.9.3 Processing The function of 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 polygon surrounding all of the points . The second point in the argument list is required to be in an orthogonal direction from the first point, so that a starting direction may be established. The rest of the arguments 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 . If 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 segment will be drawn in the y direction, then in the x direction. All of 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 pPort 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) ,- 3.3710.2 Inputs pi - 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 routine with the following exceptions. The location of the port will be specified by the argument pi, instead of two arguments specifying the x and y location, and the port layer and size information will be extracted from the point structure, instead of using arguments to the routine. The text string attached to the port is specified by port_name, and the name of the electrical node assigned to the port will be the value stored in the node name element 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 pNodeLabel routine is used to attach a node label to the geometry at a specific location. The syntax is: pNodeLabel (pi) ,- 3.3.11.2 Inputs pi - 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 pi, instead of two arguments specifying the x and y location, and the port layer 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 value 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 structure associated with the poin . The information contained in the structure that a user 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 information is shown here: xl = pGetX(pl) ; pGetY(pl) ; wl = pGetWidth(pl) ,- str = pExtDir(pl) ; item = pitern(pi) ,- str = pNodeName(pi) ; 3.3.12.2 Inputs pi - char* indicating the name of the point 3.3.12.3 Processing The point structure access routines will find the structure containing the named point, then return the requested information from the structure. An error will be reported if the point specified by pi does not exist. 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 INT32 representing the width value of the point structure. The pExtDir routine will return a char* containing the extension direction(s) of the point, . The pitern routine will return a cdsITEM representing the item name/number of the point. The pNodeName 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 geometries, such as a poly-metal contact (PYC) , or a substrate contact (SCON) . If an item is not complex, then it is a simple item, meaning the geometry is contained on one layer. Simple item types may be within two groups : wire items, or edge items . A wire item indicates that the point landmark 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 enumerated 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 . edgeitems ACT active PY poly Ml metall M2 metal2 M3 metal3 NPLUS nplus PPLUS pplus PWELL pwell NWELL nwell CUT cut V via V2 via2 EDGE edge of standard 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 specified width MW metal wire BM bigmetal wire MWW metal wire with specified width M2W metal2 wire BM2 big metal2 wire M2WW metal2 wire with specified width M3W metal3 wire BM3 big metal3 wire 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 via MMV2 metal2-to-metal3 via SCON substrate contact PCON pwell contact miscellaneous items EDGE edge of standard cell NDLBL node label GEN generic 3.5 Functional Requirements: Debugging Routines The development process of modules using the various point landmark 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 Inputs 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.1.3 Processing The dump_sc_table routine will print a formatted partial or full list of the constraints contained 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 constraints) , and its location (x and y) . The listing may be sorted in various ways, depending on the gvalue of the sofrt argument: 0 - no 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 the SC table, the start and stop arguments may be used to specify a range. After the specified sort occurs, the routine will print the entry 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 program handler. 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 list of defined points in the current group. The list may be sorted in different ways, and partial listings may be generated. The syntax is shown here: dump_pt_list (sort, start, stop) ,- 3.5.2.2 Inputs 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_ptlist routine will print a formatted partial or 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 width, 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 listed, and stop indicates the last. A value of 0 for stop indicates the end of the list. Output will be sent to the message program handler. 3.5.2.4 Outputs The routine will return an INT32 representing its status. 3.5.3.1 Introduction The dump_pt routine is used 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 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 arbitrary width wire) , the item type, the extension directions, and the electrical node name. Output will be sent to the message program handler. 3.6 Performance Requirements Execution speed in the constraint equations will be critical because of their potentially high frequency of use. This should be considered when approaching the design of these routines. 3.7 Attributes 3.7.1 Maintainability Certain subroutines of the constraint routines will be specific to the process - CMOS or GaAs. These subroutines should be separated from the rest of the routines to simplify maintenance. 3.8 Other Requirements 3.8.1 Data Base Since additional data will be stored in the geometry database when line of code information is included, a new database element may need to be defined to store to be defined to store this information.

Claims: Claims 1. A method for designing an integrated circuit having a plurality of features defined on a plurality of layers on the surface of a substrate, the features being taken from a set of possible feature types and being subject to a set of design rules associated with a process technology, the design rules specifying physical requirements among the members of the set of possible features, the method comprising the steps of: a) associating at least one feature point with each feature in the plurality of features; b) associating additional information 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 value c) preparing a list for each of the attributes associated with a feature point that is associated with each feature in the plurality of features, the list including the values of the attributes; d) associating at least two constraints with each feature point,- e) associating additional constraint information with each constraint, the constraint information including a list of constraint attributes associated with the type of the constraint, each attribute in the list of constraint attributes having a value,- f) prepariag" a list for each of the constraint attributes associated with a constraint that is associated with each feature in the plurality of features, the list including the values of the constraint attributes; and g) performing operations on each of the lists, the operations corresponding to constraints in the design rules, and the results of the operations being relative geometric placement of the feature points . 2. The method of claim 1, wherein the type of the feature includes the geometric shape of the feature, the geometric shape of the feature being represented by the value of the corresponding attribute, and step c) includes preparing a list for each value of an attribute. 3. The method of claim 2, wherein step g) includes performing operations corresponding to the geometric shapes of the features and producing relative geometric placements of the features corresponding to the feature points . 4. The method of claim 2, wherein step g) includes the operations of measuring relative placement of and determining distance between features of the same type. 5. The method of claim 1, wherein step a) includes associating the at least one feature point through a graphical interface. 6. The method of claim 1, wherein step b) includes associating the additional information through a graphical interface. 7. The method of claim 1, wherein step c) includes preparing a list for each of the attributes through a graphical interface. 8. The method of claim l, wherein step d) includes associating the at least two constraints through a graphical interface. 9. The method of claim l, wherein step e) includes associating the additional constraint information through a graphical interface . 10. The method of claim 1, wherein step f) includes preparing a list for each of the constraint attributes through a graphical interface. 11. The method of claim 1, wherein step g) includes performing operations on each of the lists through a graphical interface. 12. Apparatus for designing an integrated circuit having a plurality of features defined on a plurality of layers on the surface of a substrate, the features being taken from a set of possible feature types and being subject to a set of design rules associated with a process technology, the design rules specifying physical requirements among the members of the set of possible features, the apparatus comprising: a first circuit means for associating at least one feature point with each feature in the plurality of features; a second circuit means for associating additional information 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 value,- a third circuit means for preparing a list for each of the attributes associated with a feature point that is associated with each feature in the plurality of features, the list including the values of the attributes; a fourth circuit means for associating at least two constraints with each feature point; a fifth circuit means for associating additional constraint information with each constraint, the constraint information including a list of constraint attributes associated with the type of the constraint, each attribute in the list of constraint attributes having a value; a sixth circuit means for preparing a list for each of the constraint attributes associated with a constraint that is associated with each feature in the plurality of features, the list including the values of the constraint attributes; and a seventh circuit means for performing operations on each of the lists, the operations corresponding to constraints in the design rules, and the results of the operations being relative geometric placement of the feature points. 13. The apparatus of claim 12, wherein the type of the feature includes the geometric shape of the feature, the geometric shape of the feature being represented by the value of the corresponding attribute, and the third circuit means includes list circuit means for preparing a list for each value of an attribute. 14. The apparatus of claim 13, wherein the fourth circuit means includes first operation means for performing operations corresponding to the geometric shapes of the features and second operation means for producing relative geometric placements of the features corresponding to the feature points. 15. The apparatus of claim 13 , wherein the second operation means includes feature placement means for performing the operations of measuring relative placement of and determining distance between features of the same type. 16. Apparatus for designing an integrated circuit having a plurality of features defined on a plurality of layers on the surface of a substrate, the features being taken from a set of possible feature types and being subject to a set of design rules associated with a process technology, the design rules specifying physical requirements among the members of the set of possible features, the apparatus comprising: a computer programmed to associate at least one feature point with each feature point; a computer programmed to associate additional information 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 value; a computer programmed to prepare a list for each of the attributes associated with a feature point that is associated with each feature in the plurality of features, the list including the values of the attributes,- a computer programmed to associate at least two constraints with each feature point; a computer programmed to associate additional information with each constraint, the constraint information including a list of constraint attributes associated with the type of the constraint, each attribute in the list of constraint attributes having a value; a computer programmed to prepare a list for each of the constraint attributes associated with a constraint that is associated with each feature in the plurality of features, the list including the values of the constraint attributes; and a computer programmed to perform operations on each of the lists, the operations corresponding to constraints in the design rules, and the results of the operations being relative geometric placement of the feature points. 17. The apparatus of claim 16, wherein the type of the feature includes the geometric shape of the feature, the geometric shape of the feature being represented by the value of the corresponding attribute, and the computer programmed to prepare a list includes a computer programmed to prepare a list for each value of an attribute. 18. The apparatus of claim 17, wherein the computer programmed to perform operations includes a computer programmed to perform operations corresponding to the geometric shapes of the features and a computer programmed to produce relative geometric placements of the features corresponding to the feature points. 19. The apparatus of claim 17, wherein the computer programmed to associate additional information includes a computer programmed to perform the operations of measuring relative • placement of and a computer programmed to determine distance between features of the same type.

Inventors: BUCHANAN MARC E, LIPPINCOTT GEORGE P, BUCHANAN, MARC, E., LIPPINCOTT, GEORGE, P.
Applicants: CASCADE DESIGN AUTOMATION, CASCADE DESIGN AUTOMATION CORPORATION
Application year: 1996
Main classification: G06F17
IPC codes: G06F17, H01L21