Region Merge is inaccurate to the original input layer


I have been writing some simple DRC checks and have noticed that some areas of the merged layer that DRC checks (width, spacing) run on are inconsistent with the original layer. This causes some false positives (i.e. by creating extraneous edge or changing a 90 angle into an acute angle) that show up that I would like to avoid. Here is an example (red-orange is original input layer, hatched pink is merged layer) at an intersection of a 10um track and 15um polygonal pad (error offset is on order of few nm):

Here's an example of merging creating "spurs" (also just few nm) at seemingly perfect intersection of straight paths (red hatched in original, hatched to show it is 2 paths, pink is merged layer).

I don't think this is intended behavior of merging. Matthais did mention that merging was a "weak spot in the DRC implementation", so in that case, does behavior like this fall within what can be expected from the merge operation for now? Is there a possible workaround to or fix for this that I can use now?


  • Hello,

    An intersection point of two overlapping polygons/paths might not be on the DBU grid. Once merged this (polygon) point will snap to the DBU grid by default.



  • Thanks for the tip tomas, it was a DBU issue.
    I thought I had tweaked the DBU already but turns out, I had to manually resave the file to change its DBU. Changing the technology in the top panel and trying to set things through File->Layout Properties doesn't seem to change either tech nor DBU, but after reading this seems to be the correct behavior.

  • Note that for any DBU, the intersection points of overlapping polygons/paths/boxes might not be on the DBU grid, especially for non-diagonal angles, hence some minor differences (< 1DBU) with the merged equivalent can be noticed...

  • Do any of the snap related settings in Editor Options
    or Setup affect this? Such as "snap to other objects",
    or setting the grid down to base DB unit? Figure you
    would not want off-grid points generated in any case.

  • edited June 2021

    @dick_freebird No, that's a plain DBU effect. The editor settings do not have effect here. In the database, everything is stored as multiples of DBU. If the DBU is large, snapping will occur, but as a rounding effect, not intentional "snap to something".

    If you want to have high precision, you can reduce the DBU to 0.1nm for example. I'd not go lower because first that's the dimension of an atom already and second the overall range is limited to roughly +/- 1e9 DBUs. With 0.1nm for the DBU that is +/- 100mm. Big enough for most chips, but too small for full wafers already.


Sign In or Register to comment.