Metal spacing for DRC


My metal rules is 0.8um for width and 1.0u for spacing. Then I got a problem to code the DRC for the spacing rule.
I was using :, euclidian).output("ME_space", "Minimum Metal spacing: 1.0m")

But I got the wrong error 1 below. The easy solution is to use :

    metal.isolated(1.0, euclidian).output("ME_space", "Minimum Metal spacing: 1.0m")

But Then I don't get the notch error 2, It only finds the error 3.

What is the best way to code a spacing rule to find the errors 2 and 3, but not the error 1 ?



  • From the marker form I have to wonder whether there
    are "trivial notches" (e.g. rounding error in the merge of
    the 2 verticals and the horizontal).

    A very close in (to min DBU at least) zoom inspection?

    And what happens if you merge those three objects and
    reinspect, rerun?

    I have observed that "rotate" of polygons and paths can
    put the object vertices off-grid, does not respect the same
    grid-snapping as original placement does.

    We've also recently seen some beefs about rounding errors
    as I recall (but not specifically, which thread). It could be
    a combination of the two, perhaps - rounding error on horiz
    path width, followed by failure-to-snap?

    Just some off-the-cuff thoughts.

  • Thank you dick for your inputs, but it is not a rounding error. And if i merge the shape I still got the error 1.
    The error 1 is due to the fact the width of the metal is 0.8um and the space 1.0um.
    So if the 2 vertical shapes are separated by 0.9um, KLayout find by mistake this error is I used the space DRC command.


  • Hi guys,

    thanks for discussing this :)

    I need to say that looks like a bug :(

    I'm suspecting an issue with shielding: I have sketched the situation from error 1:

    The two marked edges qualify as space violation (they are closer than 1 µm and face opposite with their "outer" sides). But no error should be flagged here because their line of sight is interrupted by the horizontal bar in between.

    Technically this is implemented by removing all violations that cross polygon area.

    Somehow this does not seem to work here. I have tried to reproduce the issue with the data you've given - but without success.
    I have used 0.8µm width for the paths with various distances and rule values. My script is very simple:

    metal = input(1, 0), euclidian).output("ME_space", "Minimum Metal spacing: 1.0m")

    The attached test case does not give errors in my case. I'd like to look into this issue. Maybe you can adjust the values so your case is reproduced.



  • Hi Matthias,

    The layout I used comes from a digital circuit routed with a commercial Place&Route tool.
    I have sent you by email the test case.


  • What is peculiar in my view, is that the merged version gives the same error #1 - I would expect that the new polygon would not have the vertices to trigger those errors anymore.

    Laurent, if you would like to send me the same DB I would like to look at it myself.

  • Thank you Dick, I already sent it to Matthias, who found the bug and fixed it in the last preliminary version.


  • The problem was actually that shielding failed because of the very narrow nature of the (undesired) initial space violation. You can find the details here:

    Thank you all for your contributions.


Sign In or Register to comment.