|
|
Magic Mailing List |
|
From: Jeff Sondeen (sondeen AT ISI DOT EDU) Date: Mon Feb 10 2003 - 14:37:04 EST
Philippe Pouliquen writes: > > At first, I thought that the root problem was that it is meaningless to > > supply a corner extension distance that is larger than the original > > distance of the error checking. > > No, the thing that is 'unusual' about this rule, is that the cornerTypes > is exactly equal to the types1 (both brown in this case). > > So the vertical edge between brown (types1) and space (types2) doesn't > necessarily end at the junction between brown and green, because of the > fracturing of the space tiles. > > > I would call this a definite error on magic's part. > > Nope. (read on) > > > Not only is it an error, it's an error in ALL 3 cases, because the > > middle layout only shows the error to 1 unit, whereas the error area > > should be a 2x2 box, reaching all the way to the maximum corner > > extension distance. > > There should be NO errors in the layout, because the corner extension > should (normally) not be performed -- the corner material up and to the > right of the brown->space edge is: green! And green is not in the list of > cornerTypes. isn't 'space' the material up and to the right of the brown->space vertical edge ? but your point is right, since the rule requires brown, so the middle case should not show an error. the following variant of the rule is the one i think should work, flagging errors in all three cases, but doesn't. edge4way brown ~(green,brown)/plane 2 ~(green)/plane ~(green,brown)/plane 4 "Error" or quivalently, edge4way brown space 2 ~(green)/plane space 4 "Error" i remember now that magic is "edge-driven" and where there isn't an edge, magic can't check anything. ironically, this rule is at least consistent: edge4way brown space 2 ~(green)/plane green 4 "Error" so it would appear that magic considers the cornertype adjacent to the type1 part of the type1/type2 edge (contrary to my previous post) ((that seems not have have made it)) so i think i confused enough people for one day :-) > > > This should not be dependent on the configuration of space tiles. > > The problem is in the way I used the edge rule. What I was trying to > check for is: when green abuts brown, make sure that green doesn't make > any 'turns' until it is at least two lambdas away (and vice-versa). I > shouldn't have used a cornerDist of 4 -- it was unnecessary, just a > leftover from a previous implementation attempt. Now I'm using something > like the following to avoid spurious error generation: > > edge4way green ~(brown,green)/plane 2 ~(brown)/plane green 1 "Error" > edge4way brown ~(green,brown)/plane 2 ~(green)/plane brown 1 "Error" > these are a nice pair of rules. > This is the type of rule needed to ensure that the auto-generated select > masks around diffusion/ohmic don't overlap. Jeff handles it differently, > but I'm trying to make the rules behave similarly in Magic, Cadence and > L-Edit (so that I don't confuse the poor poor Freshmen and Sophomores that > are taking my Intro to VLSI class). so you'll need spacing between unequal (p vrs. n), non-touching actives >= 2* select overlap, right ? /jeff > > Philippe Pouliquen > The Johns Hopkins University > > >
|
|
|
|