Wrong-way width is incorrect in def2gds conversion

mliberty

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.

mliberty

The constraint is of the form:
PROPERTY LEF58_WIDTHTABLE "
WIDTHTABLE ... ;
WIDTHTABLE ... WRONGDIRECTION ;

mliberty

I made up a small reproducer

mliberty

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

Matthias

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.

Matthias

mliberty

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

StefanThiede

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

mliberty

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.

Matthias

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.

Thanks,

Matthias

StefanThiede

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.

Matthias

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

Matthias

StefanThiede

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’.

test.or:

read_lef test.lef
read_def test.def