Width_Space special DRC

edited June 2019 in Layout

Hi,

I don't know how to catch this space / width DRC error where 2 squares are just attached by a corner, any idea ;) :

Laurent

Comments

  • Like: input(1).sized(1.um).width(3.um).output("corner")

  • Or better: input(1).raw.sized(1.um).merged(2).output("corner")

    @Matthias: The documentation mentions the example layer.sized(300.nm).raw.merged(2), but am I right to say that this example is wrong? In the example of the "corner" above, it seems necessary to put the raw operator before the sized operator, not after.

  • Thank you Ocasta. I was using the standard checks :

    # ---------------------------------
    # METAL1_S
    
    min_metal1_s = 300.nm
    r_metal1_s = metal1.space(min_metal1_s, euclidian)
    r_metal1_s.output("METAL1_S: metal1 space < #{'%.12g' % min_metal1_s} µm")
    
    # ---------------------------------
    # METAL1_W
    
    min_metal1_w = 300.nm
    
    r_metal1_w = metal1.width(min_metal1_w, euclidian)
    r_metal1_w.output("METAL1_W: metal1 width < #{'%.12g' % min_metal1_w} µm")
    
    # ---------------------------------
    

    But none of the proposed method (euclidian, square, projection, whole-edges) can catch the fact that either the width, either the space is not enough at the common corner.

    Laurent

  • @Matthias: When two shapes are touching at only one corner point...

    • Is it normal that layer.merged gives one unique single shape?
    • Is it normal that layer.merged(2) gives nothing?
  • Oh well ... the famous "kissing corner" problem.

    @ocasta:

    Putting "raw" after "sized" works, if the polygons are not touching. In this case, the sizing would be applied individually and using raw post-size makes the sized polygons not being merged. Hence "merged(2)" gives the overlap. Putting "raw" before "sized" will not make the polygons merged before size even if they touch, so you would detect butting-polygon cases too (polygons that share edges, not just points).
    The reason why "raw" after "sized" is not working here is a different one: the kissing corner situation is recognized as "coherent" and the two rectangles are merged into a single polygon. Hence "sized" would not create overlapping parts there.

    There is a switch inside KLayout's "Region" object to control this ("min coherence"), but unfortunately it's not recognized by "sized". You can force a pre-size merge and then go to raw mode:

    l1 = input(1, 0)
    # keeps kissing-corner rectangles separate:
    l1.data.min_coherence = true
    l1.merged.raw.sized(0.1.um).merged(2).output("corners")
    

    And to answer the second question: yes, it's normal that "layer.merged" gives one polygon for kissing corner cases, because "min_coherence" is false by default.

    @laurent_c: thanks for the suggestion. Width doesn't give a marker here as the edges involved don't face towards each other with their inner sides. I'm afraid a solution is possible only by special treatment of this case inside "width".

    Kind regards,

    Matthias

  • For information, here is the way I solved it :

    # ---------------------------------
    # METAL1_S
    
    min_metal1_s = 300.nm
    r_metal1_s = metal1.sized(-1.nm).space(min_metal1_s)
    r_metal1_s.output("METAL1_S: metal1 space < #{'%.12g' % min_metal1_s} µm")
    
    # ---------------------------------
    # METAL1_W
    
    min_metal1_w = 300.nm
    r_metal1_w = metal1.sized(1.nm).width(min_metal1_w)
    r_metal1_w.output("METAL1_W: metal1 width < #{'%.12g' % min_metal1_w} µm")
    # ---------------------------------
    

    Laurent

  • For your information: I have provided a fix in the master and will release a 0.25.9 soon which has this fix ported. After this, the kissing corners will be reported as width or space violations.

    Regards,

    Matthias

  • That sounds good! However, I would add this comment: "touching corners" are legal patterns, they can be accepted by mask shops. They should not necessarily be thought as illegal.

  • Ocasta, you are right for mask shops. But the foundries will refuse to process with such shapes on your circuit, because it does not pass their DRC.
    Laurent

  • the foundries will refuse to process with such shapes on your circuit

    No, this depends on the DRM of the foundry. I wrote my previous remark after checking that such "kissing corner" pattern was indeed present on MPW wafers made by a certain foundry in Belgium.

  • I know that both happens: sometimes these pattern are legal, sometimes the aren't. In the sense of "connected" figures they are legal, because a connection cannot be guaranteed. But on implant layers they are perfectly legal, because there is no connection implied and they do not comprise a manufacturing issue like resist failures.

    But I think that most tools will flag them as illegal, so there is a certain compatibility then.

    I actually thought about making the feature configurable. But you can essentially disable it already by using "projection" metrics:

    layer.width(100.nm, projection)   # does not report kissing corners
    # will report kissing corners:
    layer.width(100.nm)   
    layer.width(100.nm, square)   
    layer.width(100.nm, euclidian)   
    

    Which looks kind of consistent to me.

    Regards,

    Matthias

Sign In or Register to comment.