Edouard Giacomin

@mithro @RTimothyEdwards this issue is quite old, but thought I would chime in real quick. I also agree that the right way is to add the pins in the .lef...

@RTimothyEdwards Indeed they seem to work fine now. By the way, I'm the one who mentioned the CUT and OVERLAP issues, but these ones are related to the "technology lef"...

Here is the one I used @nguyendao-uom. Let me know if you run into any issues when using it! ``` # CADENCE Stream layer mapping table for Skywater130nm # poly...

@nguyendao-uom I have access to the original PDK with the technology library, so I simply created a new library, attached it to the skywater technology_library and imported my GDS without...

@nguyendao-uom yes. Have you been able to import any standard cell GDS successfully by any chance? If yes, what mapfile/techfile did you use?

@jack-melchert @RTimothyEdwards FY, I just did a DRC check with Calibre and did not get any DRC error on this particular cell.

@RTimothyEdwards It's not clear to me as well to be honest. I haven't played with DRC syntax for some time. I'll give it a try in the coming weeks and...

That's right. However, there should not be a ANTENNADIFFAREA value either, as this is only for output pins. Looks like the "non-magic" lef is the correct one. [https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/master/cells/diode/sky130_fd_sc_hd__diode_2.lef](https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/master/cells/diode/sky130_fd_sc_hd__diode_2.lef)

@RTimothyEdwards your point makes sense. But I have personally never seen a .lef file from all the foundries I've worked with specifying the ANTENNADIFFAREA for something else than an output...

@RTimothyEdwards Thanks for checking that. I was not aware, so that is good to know. As @tdene mentioned, I believe that having it as input or output would not make...