Deep mode DRC false positive

[egorxe]

Deep mode DRC produces false positives on GF180MCU DRC CO.6a rule in latest KLayout. I'm attaching an archive with a minimized GDS from my Open MPW project where error manifests itself and a DRC script with only CO.6a rule left.

If launched in deep mode KLayout incorrectly finds 7 DRC errors (see co6a_deep.lyrdb):

klayout -b -r co6.a.drc -rd input=deep_drc_co6a_fail.gds -rd topcell=user_project_wrapper -rd run_mode=deep -rd report=co6a_deep.lyrdb

In flat mode DRC is clean:

klayout -b -r co6.a.drc -rd input=deep_drc_co6a_fail.gds -rd topcell=user_project_wrapper -rd run_mode=flat -rd report=co6a_deep.lyrdb

deep_drc_co6a_fail.tar.gz

[klayoutmatthias]

What is the KLayout version you are using? Please give a commit - this is a very fast development track.

[egorxe]

Commit: 5f7ae00ed32778228cfbc41ecc772cf1214c8baf.

[egorxe]

I also would like to note that deletion of some absolutely unrelated GDS parts (even millimeters apart from DRC errors) made errors vanish.

[klayoutmatthias]

Thanks, I can reproduce the problem on a small testcase.

It's a kind of feature, but maybe can be improved.

In the configuration you presented, the first width measurement that delivers the metal edges for the line end detection is done hierarchically in two configurations (mirrored and non-mirrored). The width marker is the same in both configurations - but not exactly: first and second edge are swapped (as the width marker is a symmetric one this is valid). The effect is that the marker is there twice - with first_edges and second_edges both present at the same place. This screws up the double interact later and line end detection fails.

As a general topic, deep mode DRC aims for fast execution rather than a minimum error marker set. So that is one effect. The width check is not wrong - it reports width violations where they happen. It's just not useful the way the GF180 DRC needs it.

The initial merge of the layers contributes to this problem as merge is a long-range interaction and that is why you see effects when deleting shapes unrelated.

There are a number of ways to fix this issue.

First, I will look into the implementation. I think it is possible to avoid the duplicate width markers, but it's not going to be straightforward.

Another option is to use a line-end detection that does not rely on first_edges/second_edges. Like this (disclaimer: roughly tested only):

cop6a_cond = metal1.drc( width <= 0.34.um).with_length(0.24.um,nil,both)
cop6a_eol = metal1.edges.with_length(nil, 0.34.um).and(cop6a_cond.polygons.edges).not(cop6a_cond.edges)

A word on my own account here: even when this test case was well prepared, you can help me a lot further, if you also contribute this root cause analysis. Debugging KLayout code is one thing, debugging DRC another. This is a single-person, spare-time project and I have a busy daytime job. This analysis goes away from my night time. Should I die from sleep deprivation, this project is dead too.

Matthias

[egorxe]

Thank you very much for your analysis and superb piece of open silicon software! I'm very sorry for making you sleep deprived, I was not anticipating you to react so promptly. I've operated under assumption that deep mode is kind of hierarchical speedup for large designs and should always produce same results as flat (not like tiled). So when I've found a discrepancy I've reported it in hope that this fairly complex testcase will help with your ongoing effort in improving deep mode to speedup DRC (#1189 and others). Next time I'll hold back from reporting DRC problems until I'll find a root cause myself.

[klayoutmatthias]

Perfect! But be careful to get enough sleep yourself! :)

My goal is to make deep mode the preferred version and to be (as far as possible) compatible with flat mode, so I am interested in test cases. It's just easier to focus on the real problem than digging through a complex test case. Thanks for your efforts though.

I created smaller version of the test case that shows the issue. It's attached.

The effect are twofold edge pairs causing the problem.

As an interesting fact, the problem seems to be related to #1195. And more interesting, the workaround I proposed for this issue in https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/pull/5 - and which got merged in between - avoids the false positive marker in co6.a. The key is substituting

cop6a_cond = metal1.drc( width <= 0.34.um).with_length(0.24.um,nil,both)

by

cop6a_cond = metal1.width(0.34.um + 1.dbu).with_length(0.24.um, nil, both)

So maybe you can try with the DRC from https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr?

Matthias

small.tar.gz

[egorxe]

So maybe you can try with the DRC from https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr?

These rules produce same result on my design in flat and deep mode. So it seems that substituting drc( width <= 0.34.um).with_length with cop6a_cond = metal1.width(0.34.um + 1.dbu).with_length(0.24.um, nil, both) really helps.