›

Tiling processor

marwaneltoukhymarwaneltoukhy
edited August 2021 in KLayout Support

Hello @Matthias hope you are doing well.

I have been trying to use the tiling processor on a DRC deck in order to decrease the runtime of the DRC checks. I wanted to ask about the limitation of tiling in klayout. First of all, what are the recommended rules to use with tiling? from what I've experienced, boolean operations and size checks are working fine, but some checks like separation_check, interacting/non_interacting & with_area are not useful with tiling as the tile might cut the region even if the region is not fully inside the tile.
Also, when using the tile_border to get overlapping tiles, if there's a region where part of it is in the overlapping area and the rest of the region is fully inside a tile, will the part of the region in the overlapping area be processed twice, or is tiling smart enough to process it once inside the tile which has the whole region?! i.e. in Image does C get processed only in B or in both A and B?!

Thank you for your time!
Marwan

Comments

  • MatthiasMatthias

    @marwaneltoukhy You're right the limitations are exactly the ones you describe. Sometimes you can use worst-case estimations, for example for with_area: Consider you need to check for a minimum area of 1 square micrometer. If your layout features are not smaller than 100nm (guaranteed by a DRC width rule), you need to look 10µm max to capture all parts of features which give you 1 square micrometer area. So you can use a tile border of 10µm. But there is no general rule.

    You can dynamically disable or enable tiling inside your script - so if you have parts which need full-chip coverage you can turn off tiling using "flat":

    tiles(500.um)
... (with tiling)
flat
... (without tiling)

    Another option is deep mode, but it needs some improvement before it is useful for general DRC scripts. It's quite easy to blow memory for example by trying to invert a layer with a simple NOT vs. chip boundary.

    Matthias

  • stosto

    Can I request you to add warnings about such limitations in the documentation?

    Paraphrasing: the traditional drc-script, using tiles(), has exact same limitations (horizon effect of what is visible within the tile+border) as a Region-based script using (the relatively newer) TilingProcessor()?
    Neither will auto/selectively "gather" more data beyond one tile+border, to accurately implement a specific check?
    Violator-cells should be corresponding more complex for both tiling modes, and may also need redesign if the tile&border sizes change?
    Thanks.

  • MatthiasMatthias

    I have tried to explain that here: https://www.klayout.de/doc-qt5/manual/drc_runsets.html#h2-948

    But documentation is hardly appreciated, never good enough and quickly outdated. Plus English isn't my first language, so that doesn't make it easier.

    Matthias

Sign In or Register to comment.
Powered by Vanilla