Speeding up DRC Checks

Hi,

I have a layout with multiple GDS layers. I want to check just one layer for width and space checks and so my DRC code is really simple. See lines below.

wg01 = input( 1, 0)
wg01.width( 0.50.um, projection, angle_limit(22.5)).output("R1.1w1", "wg01 width violations - 0.5um")
wg01.space( 4.00.um).output("R1.2s1", "wg01 space violations - 4.0um")

The challenge I have is that the GDS layer wg01 has a lot of points due to significant number of curves and bends. Also, this GDS is imported from shapes drawn in AutoCad and hence has lots of slivers and gaps, which I want to find and is the purpose of my check.

When I run the code above, the DRC run just hangs. When I isolate the checks (a separate width check and a separate space check), it seems that the code hangs at the space check.

I have also tried using the layout.select to remove some sub-cells from the hierarchy during the check but while that speeds up the checks, it eliminates the interaction of the wg01 layer between the sub-cell and top-cell. This is not what I want.

The general question I have is whether there is a way of speeding up the DRC perhaps through use of multiple cores (I am using a MacBook Pro)? Any other pointers to speed up the DRC would be most appreciated.

Best regards,

VikasG

Comments

  • edited January 2019

    Hi Vikas,

    yes there is.

    First, the DRC is flat, which is not the optimum solution. A hierarchical DRC can exploit the repetitive nature of a hierarchy and speed up thinks. I'm working on such a thing, but it's not ready. You're description also doesn't mention hierarchy, so I think you'd not benefit from this anyway.

    For speeding up a flat DRC, you have the option to parallelize the computation by splitting the layout into tiles:

    For example using

    tiles(1000)
    

    at the beginning of the script will make KLayout use 1x1 mm tiles and work on each tile separately. This computation can be distributed on many cores using

    threads(4)     # for 4 cores
    

    Tiling is a simple yet efficient approach. Each tile will have a much smaller memory requirement than the full layout and often speed improves because the CPU cache becomes more efficient with less data.

    You can play with the tile size to find the best solution. I usually start with 1000 for typical CMOS layouts. Smaller is not necessarily better because at some point the tile preparation overhead becomes significant.

    You find more about the tile feature here: https://www.klayout.de/doc-qt4/manual/drc_runsets.html#h2-639.

    Regards,

    Matthias

  • Matthias - thank you very much for your quick response! Really appreciate it....

    Best regards,

    Vikas

Sign In or Register to comment.