Wrong-way width is incorrect in def2gds conversion

I have a proprietary PDK with a tech LEF containing a LEF58_WIDTHTABLE with a WRONGDIRECTION table. When I generate routing in OpenROAD it correctly uses the wider width for the non-pref dir. When we write the DEF we don't give any indication of the wrong way width as the DEF manual states that :
"The following LEF DRC rules allow a WRONGDIRECTION keyword that defines wrong-way widths that will affect the width of any wrong-way routes in the DEF NETS section: ... LEF58_WIDTHTABLE"

However when I look at the gds in KLayout I see it is min width in both directions. Does KLayout support this LEF constraint when converting DEF to GDS?

It would take some effort to build a dummy test case to illustrate the issue. Let me know if that is needed or not.


  • The constraint is of the form:
    WIDTHTABLE ... ;

  • I made up a small reproducer

  • If you run the KLAYOUT script the file routed.gds is produced and you can see the width is minimum in both directions:

  • edited November 8

    Hi Matt,

    WRONGDIRECTION is basically supported, but as a property. Like here: https://github.com/KLayout/klayout/blob/master/testdata/lefdef/specialwidths/test.lef. It's controlled by a property ("LEF58_MINWIDTH" or "LEF58_WIDTH").

    Here is what I found in my mails about this:

    The property syntax was introduced by cadence to be able to create new rules
    without breaking everybody's def parser.
    But now you have to "parse" the property strings ...

    @StefanThiede suggested that.


  • Is there an example that shows this working? In the test I attached it has the LEF properties but doesn't appear to work.

  • LEF58_MINWIDTH is implemented,
    LEF58_WIDTHTABLE is not, it's a different property.

    On a related note:
    The testcase uses klayout with def2stream.py to convert lef/def and merge it with gds.
    This can be also be achieved by using klayout's strm2gds buddy tool.

    strm2gds --lefdef-map gds.map --lefdef-lefs=tech.lef --dbu-out 0.0005 routed.def strm2gds.gds

  • Thanks for the info. I hope you'll implement LEF58_WIDTHTABLE in the future but I think I can workaround it by setting up LEF58_MINWIDTH for now.

  • Sure, but does anyone have more information about this? Ideally with a test case?

    I could not find a definition of WIDTHTABLE in the LEF/DEF 5.8 spec. Not even as a non-property.
    Ideally, maybe you can open an issue on GitHub.



  • Matt’s attached reproducer is a valid testcase and the WIDTHTABLE property is described in the lefdefref5.8 on page 104 with some examples.
    Essentially it’s a superset of the existing MINWIDTH functionality.

  • Hi @StefanThiede,

    Matt's attachment has a GDS, but I think that is the output of KLayout which is wrong. So ideally there is a GDS with the intended output.

    Looks like I have a different version of the spec, as mine of November 2012 (5.8) does not describe WIDTHTABLE on page 104, but something else. But I found some description here: http://coriolis.lip6.fr/doc/lefdef/lefdefref/LEFSyntax.html


  • I was referring to the this lefdefref pdf:
    http://coriolis.lip6.fr/doc/lefdef/lefdefref/lefdefref.pdf 5.8 May 2017

    No “golden” gds/oas, because OpenRoad uses klayout to generate that.
    To see how OpenRoad draws this testcase use ‘openroad -gui test.or’.


    read_lef test.lef
    read_def test.def
Sign In or Register to comment.