|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Mar 24 2003 - 17:24:59 EST
Dear Jeff, > by any chance, did you also put in a wide-metal rule facility ? (to > force larger spacing when one of the edges is of a "wide" width > shape). Yes, I did, but something I have not quite grasped about the corner stitching tile structures prevents it from noticing the DRC error in a lot of situations, which are dependent on the tile structure around the edge being checked. At some point I intend to inspect the routine more closely and fix the error. Note the following comment that I added to the routine drcSpacing(): * Notes: * Extended to include the rule syntax: * * widespacing layers1 width layers2 distance adjacency why * * This extension covers rules such as "If m1 width > 10um, then spacing to * unconnected m1 must be at least 0.6um". This assumes that the instantiated * edge4way rule is a standard "spacing" rule in which "dist" and "cdist" * (corner extension) distances are always the same, so we can use the "cdist" * record to encode the width of "layers1" which triggers the rule. We re-use * the CheckMaxwidth() code, but with the following differences: 1) it does not * trigger any error painting functions, 2) it returns a value stating whether * the maxwidth rule applies or not, 3) it uses the DBLayerTypeMaskTbl[] for * the tile type in question, not "oktypes", for its search, and 4) it uses * the max width in the "cdist" record, not the "dist" record, for the max * width rule. The "dist" record is copied to "cdist" before actually applying * the spacing rule, so that the rule acts like a proper spacing rule. So you can see that it's a bit of a kludge to overlay the widespace rule on top of the existing spacing rule, but it's not the kludgy bits which cause it to fail. Regards, Tim
|
|
|
|