DRC checking speed is too slow!

[ZhishengZeng]

Hello！

When I use the DRC checking tool, it runs very slowly. And command 'threads(8)' doesn't work.

Can you give an example of how to use it?

Thank you!

[klayoutmatthias]

Sorry, this is not a proper issue. It lacks a DRC script which tells me what you're doing. It lacks a description or - better - a sample of your layout. It lacks timing numbers, reference values, expectations, memory footprint, machine information and everything else necessary to give some advice.

[gatecat]

I can provide a concrete example: run.sh in https://ds0.me/klayout-drc-perf.tar.xz - this is about a 2.9mm x 3.5mm SoC on sky130 built using Coriolis

"space" in: sky130A_mr.drc:332 takes 2465s it then gets stuck on "enclosing" in: sky130A_mr.drc:335 for many hours after which I terminated it

I can provide more detailed profiling if you like. For comparison Magic takes about 10 minutes to do DRC. My machine is a i9-8950HK with 32GB of RAM.

[klayoutmatthias]

Thanks. I'll take a look.

[klayoutmatthias]

I could confirm there is a performance issue.

Deep mode is not well optimized for DRC measurement functions yet. It's intended mainly for use with booleans in LVS. I'm working on that, but my suggestion for now is to use tiled mode.

I have modified the DRC script to use 500 um tiles when setting the "tiles" global variable ("klayout ... -rd tiles=1 .."):

if $tiles
    tiles(500.um)
    # use a tile border of 10 micron:
    tile_borders(1.um)
else
    # hierachical
    deep
end

With this tiled mode (tile size 500um), the run time is about 30min on 4 cores on an i7. By far most of that is spent in the "enclosing" function here:

li_edges_with_less_enclosure = li.enclosing(licon_peri, 0.08, not_opposite, projection).second_edges

When disabling this function, the FEOL DRC finishes after 260 seconds (4:20 min) with 500 µm tiles and 4 cores.

I'll try to figure out why the enclosing function is that slow in this example.

Matthias

[klayoutmatthias]

I got some further analysis and improvements.

The root cause for the poor enclosing performance is the "not_opposite" filter. This filter applied to the local interconnect shapes does not have a good performance as these shapes are potentially huge and the filter does not have a defined search range.

A better solution was to apply this check from "inside to outside" - namely from the licon to li. In that scenario the "opposite" will be applied to the licon shapes which are very local.

Sadly, there is no "reverse" feature available instead of "enclosing" yet.

I have experimentally added a "enclosed" feature which is basically the reverse of "enclosing": a.enclosed(b) is identical to b.enclosing(a).

When changing the DRC code to this feature for li.5 and using tiled mode with 500µm tile size and 4 CPUs, the BEOL DRC part takes 3 minutes on the given sample.

I think I'll publish the feature and propose to use that for the DRC.

Matthias

[klayoutmatthias]

There is an ongoing activity to deal with that topic triggered by the GF180 open source PDK development.