sized or extended_out in 1 direction

edited November 2022 in Verification


How to size a layer but only in 1 direction : top or right or bottom or left ?
I guess I have to use the extended_out method because .sized() will extend in both direction top and bottom or left and right.
Maybe extent.refs is a better method ?
Any proposal ?

Thank you, BRgds,


  • My proposal was size and move by half the size amount. At least that is how I would implement it internally :)

    So like:

    # bottom and left sized by 1µm:
    sized_bottom_left = original.sized(,

    This simple solution suffers from non reproducing 45 degree edges:

    To mitigate this, you can split the size in two steps for x and y:

    # bottom and left sized by 1µm:
    sized_bottom_left = original.sized(, 0).sized(0,,

    I'd be careful in general - this will break isotropy and if you intend to do that hierarchically, variant generation will happen.


  • edited November 2022

    Thank you Matthias, furthermore I needed to mixed moved and sized functions, it perfectly meets my need, except ... that I cannot resize the result. As in your exemple :

    sized_bottom_left = original.sized(, 0).sized(0,,
    sized_sized_bottom_left = sized_bottom_left.sized(1.0)

    the second line will return an error :'( :

    'sized': Internal error: ../../../src/db/db/dbShape.h:1239 m_type == PolygonRef was not true in Region::sized in Executable::execute

    I use the very latest version 0.28 of yesterday under Windows-10.

  • edited December 2022

    Hi @laurent_c

    I assume that is deep mode, right?

    I think that "original" for some reason has a wrong binding. If "original" comes from "extended", the problem may be related to this bug:

    I merged it November 25, so maybe you just missed it :)


  • edited December 2022

    Indeed, I was using the deep mode, but with random shapes (polygons, paths, ...). Now, it works fine in tile mode, but not in deep mode :'(
    As usual, I was using your latest version ;) , now, I use the version of December 2.


  • That's bad.

    Can you say where "original" comes from? Maybe there are more cases like the "extended" problem - although I don't know of one.



  • Sorry, stupid me. You're perfectly right. I can easily reproduce the problem

    Here is the ticket:

    I'll fix it asap.


  • Fixed in master.

  • "original" for me is the result of place&route of OpenROAD. I am trying to run some check on it, so "original" can be rectangles, polygons or paths from the current level of a hierarchy below.


  • Sorry for the confusion, I had to try myself before understanding the problem.

    I have fixed that issue in 0.28 which has been released yesterday.


Sign In or Register to comment.