Potential regression in KLayout 0.30.10

[mole99]

Hi Matthias,

When upgrading from KLayout 0.30.9 to 0.30.10, I suddenly see violations in a layout where there were none before.

The changelog for 0.30.10 shows a number of bug fixes, so it's possible that this is wrong behavior that has been fixed.
But if a layer is fully covered by another layer, then the separation operator should not generate any edge markers, is that right?

Here, we have GUARD_RING_MK and Metal5 in the sealring. GUARD_RING_MK fully covers Metal5, and yet separation generates edge markers.

2026-08-17 15:16:08 +0200: Memory Usage (484752K) : DRC RESULT: FAILURE (24 violation(s))
2026-08-17 15:16:08 +0200: Memory Usage (484752K) : Violated Rules:
2026-08-17 15:16:08 +0200: Memory Usage (484752K) :   'GR.2'               :    24 violation(s)
2026-08-17 15:16:08 +0200: Memory Usage (484752K) : # DRC Total Run time 0.241625524 seconds

I tried to reproduce the same issue in a smaller DRC script, like this one:

report("A simple script")

deep

guard_ring_mk = input(167, 5)
metal = input(81, 0)

gr2_l1 = metal.separation(guard_ring_mk, 10.um)
gr2_l1.output('GR.2', "GR.2 : Min GUARD_RING_MK space to prime die Metal5: 10")

Unfortunately, I cannot trigger it this way. Therefore, I have packaged a reproducible with the full gf180mcu DRC runner.

You can find it here: reproducible_klayout_0_30_10.zip
To start the DRC, simply run: klayout -b -r gf180mcu.drc -rd input=sealring.gds -rd decks="guard_ring" -rd report=report.lyrdb

Please let me know if you need any more information.

[mole99]

I just found #2418, compiling the latest master right now to give it a try!

Edit: Unfortunately, I still see the GR.2 violations.

[hpretl]

Same thing on a stock gf180mcu standard cell, with flat/deep as the discriminator.

gf180mcu_fd_sc_mcu7t5v0__dffrnq_1, straight out of the PDK library GDS, stock gf180mcu.drc:

	flat	deep
0.30.9	7	7
0.30.10	7	10

The three extra are DF.6_MV (enclosing), PL.5a_MV and PL.5b_MV (separation). Flat agrees across versions, so they look like deep-mode false positives.

klayout -b -zz -r $PDK_ROOT/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc \
  -rd input=$PDK_ROOT/gf180mcuD/libs.ref/gf180mcu_fd_sc_mcu7t5v0/gds/gf180mcu_fd_sc_mcu7t5v0.gds \
  -rd topcell=gf180mcu_fd_sc_mcu7t5v0__dffrnq_1 -rd report=out.lyrdb \
  -rd variant=gf180mcuD -rd decks=all,-antenna,-density -rd run_mode=deep

Markers (identical in both orientations of the cell):

DF.6_MV   edge-pair: (9.98,1.14;9.98,0.78)/(9.68,1.405;9.68,0.56)
PL.5a_MV  edge-pair: (1.74,2.14;2.24,2.14)/(2.444,2.36;1.536,2.36)
PL.5b_MV  edge-pair: (1.74,2.14;2.24,2.14)/(2.444,2.36;1.536,2.36)

Deck and cell geometry are byte-identical between the two versions (md5 over the whole libs.tech/klayout tree, and a flattened per-layer polygon dump of the cell). Adding .merged to the first input of all three rules changes nothing, so this is not the #2416 path.

[klayoutmatthias]

There was a regression with separation having "props_ne" qualifier (#2416). Let me check if this applies as well here.

The number of violations may differ between 0.30.10 and 0.30.9.

The reason is this: before a space check is done, a merge was performed in order to join all involved polygons. In the single-layer space check this was eliminated by skipping the merge and checking individual polygons against each other, while not testing internal edges found by a local merge. This "local merge" gives a significant performance benefit: a region merge may not only consume significant resources, but also renders huge polygons that are expensive to work with. The price to pay is an increased number of violation markers, because now you may see violations between multiple polygons, when there were only two in the "global merge first" case. In the end however, the combined error markers should render the same results as before. These additional markers should not be false positives - it's rather that a single marker gets split (BTW: commercial tools show the same behavior). If one is interested in combined marker counts, one can basically convert markers to polygons and merge them, before taking the count.

This scheme was in place since long now for the single-layer space. While investigating performance issues in the IHP PDK, I found that the global merge spoils performance in the two-layer space (separation) check as well, so I extended the same scheme to two-layer separation, with the same benefit and effect on the marker count.

Since that was so far accepted in the single-layer space, I hope it's also acceptable in the two-layer case.

The regression in the #2416 case was a logic error when properties were involved. Maybe it explains this issue as well. Like said, I'll check.

Best regards,

Matthias

[klayoutmatthias]

BTW: here is a good one:

-rw-r--r-- 1 matthias matthias 31054670 Aug 17 14:54 sealring.gds
-rw-rw-r-- 1 matthias matthias     1436 Aug 19 23:47 sealring.oas

31M vs. 1.4k :)

[klayoutmatthias]

So here is my simple reproducer:

source("sealring.oas")  # or .gds 
verbose(true)
target("debug.gds")

deep

comp = polygons(22, 0)
guard_ring_mk = polygons(167, 5)

comp.output(1, 0)
guard_ring_mk.output(2, 0)

# Rule GR.2: Min GUARD_RING_MK space to prime die COMP, NWELL, Poly2, Metal 1, 2, 3, 4, 5 and metal Top: 10
gr2_l1 = comp.separation(guard_ring_mk, 10.um)
gr2_l1.output(100, 0)

At first glance it's a border case with a kissing-corner situation that gets interpreted as separation. That has not been there before as the whole ring would have been merged - but that exactly is the point. Because if you merge a sealring it's bounding box approximation includes the whole chip and interaction tests based on the bounding box are not working well. Not merging (and splitting) reduces the seal ring to the edges only and that should give a great performance improvement when you apply separation on the whole chip.

But the problem needs some debugging. I don't think that's a big issue thanks to that nicely prepared test case :)

Thanks,

Matthias

[klayoutmatthias]

I created a patch to fix that issue. The original test case now is clean.

I assume this is the development repo for GF180: https://github.com/fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv.

Running the DRC tests there does not give me fails, but it did not give me any fails with 0.30.10 either :(

Matthias

[mole99]

Thanks a lot, Matthias! 👏

Thanks also for the detailed explanation of the issue. Better performance is indeed worth it :)
I don't mind potentially having more error markers. If any DRC errors occur, I need to take a closer look as to why anyway.

I can confirm that #2425 fixes the padring issue, as well as all the other issues in my full chip design. I haven't reported them just yet because I had the hunch that these would be related, and indeed, that was the case! So, the additional 'DF.6_MV', 'PL.5a_MV' and 'PL.5b_MV' violations do not show up anymore, which matches what @hpretl previously observed in the standard cells. Great!

Running the DRC tests there does not give me fails, but it did not give me any fails with 0.30.10 either :(

Yes, the unit tests in there are limited in scope, so I'm not surprised it isn't caught there.

However, here's an example of the runtime of the full DRC deck on a full chip design:

0.30.9: DRC Total Run time 514.18943909 seconds
your branch: DRC Total Run time 486.598669789 seconds

A nice gain indeed!

PS: OASIS for the win :)

[klayoutmatthias]

Very good. Thanks for the feedback!

The gain is just a piece in the puzzle, but I'm working on performance step by step :)

Best regards,

Matthias