LEF/DEF Import - skip duplicate Macros feature

[andioddi]

First of all thank you very much for this great tool! So far I used it only for GDS viewing. Lately I wanted to test the DEF/LEF import. However when importing DEF with LEFs I discover the following runtime error: Duplicate MACRO. Our vendor delivers a set of standard cells with different VTs (SVT,LVT,HVT,etc). Each library contain the same set of Gate Array Cells. This leads to the above error during DEF/LEF import. I could now patch out the duplicate MACRO definitions but honestly think the approach below is better.
I implemented the attached patch to change the error to a warning and continue the import. The MACRO read first will be used and all following ones will be ignored (this could be changed to let the last read macro win but I am going for first come first serve). For these cells this approach is reasonable as I am aware of these cells. I attached a patch below in case you are interested to add this feature to klayout.

I tested the patch on my testcase and works well.

You can find the latest patch here : https://github.com/andioddi/klayout

[klayoutmatthias]

Thanks for the patch, but frankly, I don't think that's a good idea.

I think there is something wrong with your setup. Either you want to use standard cells from different libraries in the same design - in that case, the names of the standard cells must be different - or you want to use one flavor only. In that case you should only include the LEF file you really need.

Unless you want to turn your tapeout into a thrill, "first come, first serve" is definitely not a good strategy to resolve name conflicts.

Conflicting names indicate an ambiguity and I'd strongly advise for resolving that ambiguity rather than patching the reader code.

Matthias

[andioddi]

I am sure our setup is correct. The files I have are provided by the foundry. We have 9 different standard cell libraries for different VT and OD spacings. The cells which are duplicate in the libraries are GateArray cells sired as decoupling cells (they can be rewired by metal to allow logic fixes with single mask changes), TAP-Cells for connecting substrate and nwells and Boundary Cells. The choice to have these cells duplicated in some of these libraries was not mine but the IP providers. I agree it would have been better to have these cells in a different library file to prevent these duplication warnings. However I am stuck with the setup and do not want to patch the lef files to get rid of the issue. Therefore I think it is reasonable to allow duplicate cells in lef files and not just abort. That is at least the way that our EDA tools handle this situation -> They throw warnings at us and continue... It would be nice if you can reconsider having this feature added.

Andi

[klayoutmatthias]

Do you know that you don't have to read all LEF files, but can select the one that you actually need?

[andioddi]

I am aware, but we are using in our project a mixture of standard cells for power and timing optimization. This is a standard procedure for digital designs. So yes, I have to read them all. 13.06.2026 23:37:13 Matthias Köfferlein ***@***.***>:

…

[Bild]*klayoutmatthias* left a comment (KLayout/klayout#2374)[#2374 (comment)] Do you know that you don't have to read all LEF files, but can select the one that you actually need? — Reply to this email directly, view it on GitHub[#2374?email_source=notifications&email_token=AGVLIMICIPHQIEEIRG3EOXL47XCQPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4DMNJWGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4699865612], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AGVLIMLDADU4ZI3QOI3QOF347XCQPAVCNFSNUABEKJSXA33TNF2G64TZHM4DCNZSGI2DKNB3JFZXG5LFHM2DMNBRHE3TQMZWGWQXMAQ]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS[https://github.com/notifications/mobile/ios/AGVLIMOCJ667NS7G7OFAZKL47XCQPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4DMNJWGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG] and Android[https://github.com/notifications/mobile/android/AGVLIMMC675GGCOZBZZSE4T47XCQPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4DMNJWGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA]. Download it today! You are receiving this because you authored the thread. [Verfolgungsbild][https://github.com/notifications/beacon/AGVLIMMM3TG7J5PWL7GA5A347XCQPBFCNFSM6AAAAAC2FCMZBOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACGBCIIGKM4TFMFZW63VGMF2XI2DPOI.gif]

[klayoutmatthias]

Sorry, that does not make sense.

So you have two types of cells, both with the same name. Then, how does DEF tell which one to take? "first come, first serve" will just give you one.

[andioddi]

It seems I did not explain that very good. I have multiple standard cells lef files : 30nmSVT 30nmLVT 30nmHVT Each "normal" logic cell in each of the libraries has the above string as postfix like And2D1_30nmSVT and so on However, each library contains some cells which do not have that unique extension l, e.g. tapcell (to connect the wells and substrate) .  There are other cells which are physically identical in each lib and therefore not unique across the libraries. Again I agree that it would have been nice if the ip Provider would have split up theses cells into a separate library. So to be clear : the cells which lead to the "duplicate" violation are in fact the same physical cell but are defined in each of the lef libraries again. After reading the cell from any of the lef files there is no need to read it again as it would be identical. Thus I implemented the skip option . I hope I explained it better now. Andi 13.06.2026 23:56:41 Matthias Köfferlein ***@***.***>:

…

[Bild]*klayoutmatthias* left a comment (KLayout/klayout#2374)[#2374 (comment)] Sorry, that does not make sense. So you have two types of cells, both with the same name. Then, how does DEF tell which one to take? "first come, first serve" will just give you one. — Reply to this email directly, view it on GitHub[#2374?email_source=notifications&email_token=AGVLIMPI6NY3IGUGWC56T2T47XEZRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4TAOJVGQZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4699909542], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AGVLIMP57ZYND6CTFMUZV2347XEZRAVCNFSNUABEKJSXA33TNF2G64TZHM4DCNZSGI2DKNB3JFZXG5LFHM2DMNBRHE3TQMZWGWQXMAQ]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS[https://github.com/notifications/mobile/ios/AGVLIMPWKRFBOR75YTNX62L47XEZRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4TAOJVGQZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG] and Android[https://github.com/notifications/mobile/android/AGVLIMIPQD42DKREV5H3GAD47XEZRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHE4TAOJVGQZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA]. Download it today! You are receiving this because you authored the thread. [Verfolgungsbild][https://github.com/notifications/beacon/AGVLIMJKLQEQK6FEO7E6G5L47XEZRBFCNFSM6AAAAAC2FCMZBOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACGBC5WTKM4TFMFZW63VGMF2XI2DPOI.gif]

[klayoutmatthias]

I see. So it's really a special case, and physical identity is part of the contract.

The way I know PDKs, such cells go into separate LEF files instead of being embedded in different files, so there is no multiple choice.

There is some risk connected with the "treat duplicate cells as warnings", but as that feature is opt-in, it's a user choice to take that risk.

I think the "safe block skipping" is not needed - it's enough to run the parser without a GeometryBasedLayoutGenerator object. There is also an opportunity to at least test the basic cell parameters like origin and bounding box for consistency across multiple occurrences. And for completeness, the new option needs to become available for the buddy tools and the reader options. I will take a look.

Matthias

[andioddi]

I agree it is a special case. Thanks for your understanding. if there is anything I can help in terms of testing let me know.

Andi