MAGIC Magic Mailing List
 
 

From: Philippe Pouliquen (philippe AT alpha DOT ece.jhu.edu)
Date: Mon Feb 10 2003 - 13:23:52 EST

  • Next message: Jeff Sondeen: "Re: magic DRC error"

    > 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.
    
    > 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"
    
    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).
    
    Philippe Pouliquen
    The Johns Hopkins University
    


  •  
     
    Questions? Contact Rajit Manohar
    cornell logo