make test gds cause "ERROR first and last coordinate of boundary (10 coordinates) on 67:20 not equal 0 -85 0 0"

[stefanottili]

Description

I ran "make test" after having installed OpenLane on MacOS Ventura M1.

Reading the resulting gds with my own gds reader triggers errors for 3 out of the 4 identical gds. (why are there 4 identical gds written ????) "ERROR first and last coordinate of boundary not equal". Only the klayout gds doesn't trigger this error.

read_gds (Lib #1) OpenLane/designs/spm/runs/openlane_test/results/signoff/spm.gds ERROR sky130_ef_sc_hddecap_12 first and last coordinate of boundary (10 coordinates) on 67:20 not equal 0 -85 0 0 read_gds (Lib #2) OpenLane/designs/spm/runs/openlane_test/results/signoff/spm.klayout.gds read_gds (Lib #3) OpenLane/designs/spm/runs/openlane_test/results/signoff/spm.magic.gds ERROR sky130_ef_sc_hddecap_12 first and last coordinate of boundary (10 coordinates) on 67:20 not equal 0 -85 0 0 read_gds (Lib #4) OpenLane/designs/spm/runs/openlane_test/results/final/gds/spm.gds ERROR sky130_ef_sc_hd__decap_12 first and last coordinate of boundary (10 coordinates) on 67:20 not equal 0 -85 0 0

The error is already in the source gds.

read_gds (Lib #1) pdks/sky130A/libs.ref/sky130_fd_sc_hd/gds/sky130_fd_sc_hd.gds ERROR sky130_ef_sc_hd__decap_12 first and last coordinate of boundary (10 coordinates) on 67:20 not equal 0 -85 0 0

klayout fixes that, magic doesn't. magic should warn/fix this, but it also has to be fixed in sky130_fd_sc_hd.gds

The lower rectangle on 67:20 is a 5 point boundary, klayout writes it as a 4 point rectangle.

0.00 -85.00 0.00 0.00 0.00 85.00 5520.00 85.00 5520.00 -85.00

67/20 - Box(0,-0.085;5.52,0.085)

Expected Behavior

The first and last coordinate of any gds BOUNDARY should be the same, even though the last one is usually not used. There should be at least a warning when they're not the same and the writer could fix that.

Environment report

Kernel: Darwin v22.2.0
Distribution: macOS 13.1
Python: v3.10.9 (OK)
Container Engine: docker v20.10.22 (OK)
OpenLane Git Version: 0b94d33d942814fceeab05ec4881c90b5bc386ac
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

0b94d33d 2023-01-19T15:24:17+02:00 Fix LEC (#1628) - Anton Blanchard -  (HEAD -> master, tag: 2023.01.20, origin/master, origin/HEAD)
1d87bce6 2023-01-18T17:13:26+02:00 Fix issue reproducibles for variables with multiple files (#1630) - Kareem Farid -  (tag: 2023.01.19)
1c950442 2023-01-18T17:03:19+02:00 Fix loading design configs again (#1626) - Kareem Farid -  ()
---
Git Remotes

origin  https://github.com/The-OpenROAD-Project/OpenLane (fetch)
origin  https://github.com/The-OpenROAD-Project/OpenLane (push)

Reproduction material

pdks/sky130A/libs.ref/sky130_fd_sc_hd/gds/sky130_fd_sc_hd.gds

Relevant log output

.

[stefanottili]

44 1003 XY 0,-85 5520,-85 5520,85 0,85 0,0

klayout converts this ill formed 4 point boundary (5 xy coordinates) into a 5 point polygon (with 6 xy coordinates).

52 1003 XY 0,-85 0,0 0,85 5520,85 5520,-85 0,-85

[kareefardi]

Which tool is printing these errors? I can read both gds from magic and klayout in two layout editors, Klayout and LayoutEditor

[stefanottili]

http://bitsavers.informatik.uni-stuttgart.de/pdf/calma/GDS_II_Stream_Format_Manual_6.0_Feb87.pdf “The first and last coordinates of a boundary or border must coincide.”

So I check this in my own gds reader.

I wrote and used other readers that also checked this, but this is the first time in 25 years that I’ve seen this error being triggered.

Mathias mentioned that Klayout treats all xy coordinates as valid. It removes the last if it’s equal to the first as part of the redundant point removal. But then it always writes boundaries with a last=first coordinate.

[kareefardi]

I see. @RTimothyEdwards any feedback on this ?

[stefanottili]

I would say that the important outcome should be that sky130_ef_sc_hd__decap_12 gets fixed. And I’m curious which tool wrote pdks/sky130A/libs.ref/sky130_fd_sc_hd/gds/sky130_fd_sc_hd.gds I didn’t look into how to file a bug report against the sky lib, please do so.

[kareefardi]

@stefanottili can you verify that the same error is present in the original source of sky130 pdk found here https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/tree/main/cells

[stefanottili]

sky130_ef_sc_hd__decap_12 is not in the sky130_fd_sc_hd google git repository ... So where do I find the "source" ?

[stefanottili]

https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/main/cells/decap/sky130_fd_sc_hd__decap_12.gds has the same size but differs significantly from sky130_ef_sc_hd__decap_12 in 66:44 (cont) and 67:20 (met1)

[RTimothyEdwards]

@stefanottili : The SkyWater version of the cell has way too much local interconnect, such that if anyone makes a standard cell layout and uses decap_12 for fill, and there's a significant amount of fill, then the layout will fail local interconnect density. The Efabless version of the cell cuts back the local interconnect (and by necessity, the contacts to poly) to keep an approximately 50% density for the local interconnect layer, which is generally ideal for meeting the overall chip density.

[RTimothyEdwards]

@stefanottili : The Efabless versions of cells are installed by open_pdks, and the GDS source can be found in the open_pdks repository: https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/custom/sky130_fd_sc_hd/gds/sky130_ef_sc_hd__decap_12.gds

[RTimothyEdwards]

Fixed upstream in open_pdks. @kareefardi : Please see that volare and other places where we have the open_pdks installation get updated to version 1.0.387. If anyone plans to do the update within the next 12 hours, let me know and I'll force the mirror copy from opencircuitdesign.com to github.

[stefanottili]

https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/custom/sky130_fd_sc_hd/gds/sky130_ef_sc_hd__decap_12.gds (Dec 16) has the "last != first coorindate" error. I'm assuming that "fixed upstream in open_pdks" means that the fixed cell will eventually show up on GitHub.

Let me know whether anybody thinks that a not standard conforming boundary in gds should be a warning in either magic or klayout and I'll file tickets. Since writers seem to do the right thing, this issue has such a low probability that it's likely to be very low on the list of things to do.

[RTimothyEdwards]

@stefanottili : Agreed, and I'll add the warning in magic's GDS read routine (I can confirm that magic simply closes off the polygon if the last point does not match the first, without issuing any messages about it).

[stefanottili]

Case closed. Thanks

[stefanottili]

.