Hello everyone, I need some assistance with critical issues I'm encountering in the finish step of ORFS regarding the GDS file produced by KLayout. Issue: The GDS file shows mismatches with the DEF file, leading to DRC violations specifically for the VIA ARRAY Cell (VIA-METAL1 and VIA-METAL2). Observations: The DEF file is free of this issue and passes DRC checks. The issue is specific to the GDS file generated by KLayout. I've provided an example illustration as I'm using a closed-PDK. Investigations: Layer mapping has been verified and appears correct. Units are set to 0.001 DBU (defined in the .lyt file). Tech LEF DATABASE MICROS is set to 1000. Queries: How can I debug and resolve these DEF-GDS mismatches? Also, Where in ORFS can I find options for: • a) Increasing the VIA enclosure to allow more tolerance. • b) Adjusting the number of VIAs. Currently, there's only one via connecting metal 3 to metal 4, but there's clearly plently of space for more VIAs. • c) Where can I access more detailed documentation regarding the .lyt file, other than the documentation available at https://www.klayout.de/0.23/doc/about/technology_manager.html? • d) Is it possible to perform the DEF to GDS conversion in Cadence Virtuoso instead of KLayout? Any insights or guidance would be greatly appreciated. Thank you for your assistance.

Are you using the most recent version of KLayout? Previous versions have had bugs when converting from LEF to GDS. If you can pin down the exact LEF statements causing the issue, you can submit a GitHub issue for KLayout with a minimum reproducible version of the issue. You should be able to change the values in the LEF statement for the minimum reproducible, and then there are no more confidentiality concerns. Adjusting the number of vias depends on if it's a power net or routed net. For power nets, you need to look at the power grid script to change the properties. PDN is good about figuring out the maximum number of vias that can fit. For signal nets, the router unfortunately only works with single-cut vias right now. There are workarounds which involve editing double-cut vias to remove the extra cut during routing, then adding the cut back in during GDS merge. This only works some of the time, because the double cut vias have different DRC constraints. You can use Cadence Virtuoso for the DEF to GDS conversion, provided that you have a Virtuoso layermap file to map LEF layers to GDS.

Hi @Austin Rovinski, Thank you for your prompt response. I've taken the time to try out all your suggestions, and here are my findings: - I have checked that the DEF file doesn't have the DRC issue both OpenROAD GUI and Virtuoso. - Regarding the Klayout version: 1) Inside the ORFS docker, the Klayout version is 0.28.8. It's worth noting that while the Klayout GUI starts, it displays a blank/empty window. However, the OpenROAD GUI functions properly after installing the necessary graphics drivers. 2) Additionally, I've used a local installation of KLayout (version 0.28.5) along with the def2stream.py scripts in /util for the DEF2GDS process. Both versions produce the same GDS with identical DRC errors. Both versions produce the same GDS with the same DRC error. - Trying Virtuoso: When using Virtuoso for the DEF to GDS conversion, the output GDS does not have DRC issues. However, it does not add labels on pins, unlike Klayout, which is configured to do so with the (.lyt) file. - Solving it by editing the techlef: Upon further investigation, I've found that all the DRC issues are in some via rule generate cells that are generated based on the techlef. While I was initially hesitant to edit the techlef file, I read the LEF/DEF standard and increased the overhang value of the via enclosure to correct the faulty DRCs. This adjustment fixed the DRC issue. I wish I knew how to create a minimum reproducible with just "a via". I hope this reply provides some insight for anyone facing a similar issue. Best

Was the overhang value in the tech LEF too small? Or the overhang was correct but you needed to increase it more in order to eliminate the DRC violation? Can you check that there isn't a mismatch in DBU between the LEF and GDS? Because otherwise, that sounds like a bug and you shouldn't have to fix that manually. If your design isn't private and you could submit a test case as a GitHub issue, that would be helpful.

The overhang was correct but I had to increase it a bit to overcome the DRC issue. (Is this going to bite me later?) The DBU is the same. I have tried changing it in both the techlef and the .lyt file and the output gds was garbage. The DEF is correct, the gds from virtuoso is correct. Unfortunately, the pdk is private.

So the overhang value in LEF did not match the value in the design rule manual? That sounds like a PDK bug then.

The overhang values in the techlef is conforming to the DRC rules of the PDK. The DEF file, created by openroad, produces the fixed vias and the via arrays correctly. And the DEF2GDS conversion in virtuoso doesn't exhibit the DRC issues in the via arrays found in the gds produced by klayout. I doubt it's a pdk issue.

Okay so to clarify once again, the overhang value in the LEF is X, the overhang value in the DEF is X, the overhang value when using Virtuoso to convert to GDS is X, but then the overhang value when using KLayout to convert to GDS is Y? If so, then that's a KLayout conversion issue. Can you specify what LEF property is used to define the overhang? Or is it just part of the via rule?

Thanks a lot. Will do soon! Is it okay if I linked to this thread as well?

Sure

The LEF property used.