StdCellLib DRC fixes and via enclosure improvement by FatsieFS · Pull Request #5 · ChipFlow/mpw4

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS · 2021-12-19T11:09:20Z

Fix DRC errors:
- min tap licon enclosure
- minimum licon on poly difftap space
- minimum poly to difftap space
Update via enclosure for routing to make width/height same as the
wire in the routing direction.
TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-19T11:10:08Z

Hopefully I did magic DRC properly this time and is the design DRC clean.

FatsieFS · 2021-12-19T12:19:17Z

Having top layer not as CRL.RoutingLayerGauge.PowerSupply does not seem to cause a problem. I can do P&R only I seem to have one failed route.

FatsieFS · 2021-12-20T09:41:15Z

Out of the discussion in #4 I think I now how to improve the routing gauge computation. Will try to see if I can squeeze that in today.

FatsieFS · 2021-12-20T09:57:48Z

And there seems to be implant spacing errors after routing also be left...

FatsieFS · 2021-12-20T12:50:50Z

Pushed new commit that should fix DRC errors of minimum implant spacing after placement and also the computed via enclosure should be more in line with #4.

FatsieFS · 2021-12-20T13:02:34Z

And I rebased also on main branch.

gatecat · 2021-12-20T20:28:20Z

I've tried this branch and I think I'm still seeing a DRC error in decap_w0 at least:

poly contact spacing to P-diffusion < 0.235um (licon.9 + psdm.5a)

The tap issue does seem to be fixed though; and it could well be the remaining problem is just something setup wrong on my side...

FatsieFS · 2021-12-21T09:23:35Z

How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out.
I am trying to run the script from the open_pdk

% ~/eda/open_pdks/sky130/sky130A/libs.tech/magic/run_standard_drc.py StdCellLib_upstream.gds Evaluating full DRC results for layout StdCellLib_upstreamRunning: magic -dnull -noconsole -rcfile /home/verhaegs/eda/Chips4Makers/CIIC/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc /home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tclRunning in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drcMagic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.Starting magic under Tcl interpreterUsing the terminal as the console.Using NULL graphics device.Processing system .magicrc fileSourcing design .magicrc for technology sky130A ...2 Magic internal units = 1 LambdaInput style sky130(vendor): scaleFactor=2, multiplier=2Scaled tech values by 2 / 1 to match internal grid scalingLoading sky130A Device Generator Menu ...Loading "/home/verhaegs/eda/code/c4m-pdk-sky130/drc/run_magic_drc_StdCellLib_upstream.tcl" from command line.DRC style is now "drc(full)"Warning: Calma reading is not undoable! I hope that's OK.Library written using GDS-II Release 6.0Library name: LIBReading "a2_x2".Reading "a3_x2"....Reading "nor4_x0".Creating new cellLoading DRC CIF style.No errors found.Using technology "sky130A", version 1.0.227-0-g527bfa4Error message output from magic:CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1File StdCellLib_upstream.mag couldn't be readNo such file or directoryDone!

FatsieFS · 2021-12-21T09:38:27Z

OK, I can reproduce the DRC error now in the magic GUI; will fix.

FatsieFS · 2021-12-21T12:23:50Z

I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal.

gatecat · 2021-12-21T13:41:19Z

Unfortunately I now seem to be seeing a different error in decap_w0?

poly spacing to Diffusion < 0.075um (poly.4)

fwiw, I am using the rcfile open_pdks/sky130/sky130A/libs.tech/magic/sky130A.magicrc with Magic

gatecat · 2021-12-21T13:42:46Z

oh, I should note, I'm running DRC on the GDS coming out of Coriolis (and loading cells inside it) and not on the StdCellLib.gds

StdCellLib.gds looks alright here; so I guess something is slightly off in the Coriolis techlib

FatsieFS · 2021-12-21T13:54:07Z

Seems I botched the commit as I saw and fixed that problem; mmm...

FatsieFS · 2021-12-21T14:06:21Z

Seems I only regenerated gds files and not the Coriolis files for last commit.
I keep on trying...

gatecat · 2021-12-21T15:19:33Z

Cell library looks good now, although I seem to be seeing some DRC failures in the local interconnect vias - li spacing failure due to the horizontal extension:

gatecat · 2021-12-21T15:35:18Z

Looks like a possible fix to the above issue is:

--- a/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py+++ b/thirdparty/open_pdk/C4M.Sky130/libs.tech/coriolis/techno/etc/coriolis2/node130/sky130/StdCellLib.py@@ -29,7 +29,7 @@ def _routing():
rg.setSymbolic(False)
metal = tech.getLayer('li')
via = tech.getLayer('li_mcon_m1')
- setEnclosures(via, metal, (u(0.075), u(0.0)))+ setEnclosures(via, metal, (u(0.0), u(0.0)))
rg.addLayerGauge(CRL.RoutingLayerGauge.create(
metal, CRL.RoutingLayerGauge.Horizontal, CRL.RoutingLayerGauge.PinOnly, 0, 0.0,
u(0.0), u(0.51), u(0.17), u(0.17), u(0.17), u(0.17),

after that I think the last remaining DRC issues are relating to #6 for which a Coriolis commit just landed and I need to test -- EDIT; yes this does fix the remaining DRC issues!

FatsieFS · 2021-12-21T17:48:00Z

The horizontal and vertical enclosure seem to be mixed up, will have a closer look.

* Fix DRC errors: * min tap licon enclosure * minimum licon on poly to difftap and nsdm space * minimum poly to difftap space * minimum implant space after P&R * Update via enclosure for routing to make width/height same as the routing layers above and below. In order to compute enclosures properly also right orientation has to be used for PinOnly layer. * TODO: CRL.RoutingLayerGauge.PowerSupply

FatsieFS · 2021-12-22T08:53:11Z

Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly.
Should be fixed now and rebased on main.

gatecat · 2021-12-22T13:37:49Z

Looks good, I'm seeing some last remaining metal1 spacing issues that I think are HTree related:

But I don't think the bug now is in this PR; so it can be merged now if you are happy

FatsieFS · 2021-12-22T13:40:03Z

OK for me to merge.

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

FatsieFS mentioned this pull request Dec 19, 2021
Adjust the gauge & the VIA size to have square endings. #4
Open

FatsieFS force-pushed the staf/drcfix branch from 451fce9 to b562871Compare December 20, 2021 12:47

FatsieFS mentioned this pull request Dec 20, 2021
Overlapping DC block with routing wire #6
Closed

FatsieFS force-pushed the staf/drcfix branch from b562871 to 65a3a69Compare December 21, 2021 12:22

FatsieFS force-pushed the staf/drcfix branch from 65a3a69 to 2687ae7Compare December 21, 2021 14:05

FatsieFS force-pushed the staf/drcfix branch from 2687ae7 to 6ebf089Compare December 22, 2021 08:52

gatecat merged commit 6744c5f into mainDec 22, 2021

gatecat deleted the staf/drcfix branch December 22, 2021 13:48

Uh oh!

Conversation

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

gatecat commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

gatecat commented Dec 21, 2021

Uh oh!

gatecat commented Dec 21, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

gatecat commented Dec 21, 2021

Uh oh!

gatecat commented Dec 21, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 22, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gatecat commented Dec 22, 2021

Uh oh!

FatsieFS commented Dec 22, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 19, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 20, 2021

Uh oh!

gatecat commented Dec 20, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

FatsieFS commented Dec 21, 2021

Uh oh!

gatecat commented Dec 21, 2021

gatecat commented Dec 21, 2021•
edited
Loading

gatecat commented Dec 21, 2021•
edited
Loading

FatsieFS commented Dec 22, 2021•
edited
Loading

gatecat commented Dec 21, 2021•
edited
Loading

gatecat commented Dec 21, 2021•
edited
Loading

FatsieFS commented Dec 22, 2021•
edited
Loading

gatecat commented Dec 21, 2021•
edited
Loading