StdCellLib DRC fixes and via enclosure improvement

[FatsieFS]

• 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]

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

[FatsieFS]

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]

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]

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

[FatsieFS]

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]

And I rebased also on main branch.

[gatecat]

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]

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_upstream
Running: 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.tcl
Running in directory: /home/verhaegs/eda/code/c4m-pdk-sky130/drc

Magic 8.3 revision 239 - Compiled on vr 10 dec 2021 13:59:22 CET.
Starting magic under Tcl interpreter
Using the terminal as the console.
Using NULL graphics device.
Processing system .magicrc file
Sourcing design .magicrc for technology sky130A ...
2 Magic internal units = 1 Lambda
Input style sky130(vendor): scaleFactor=2, multiplier=2
Scaled tech values by 2 / 1 to match internal grid scaling
Loading 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.0
Library name: LIB
Reading "a2_x2".
Reading "a3_x2".
...
Reading "nor4_x0".
Creating new cell
Loading DRC CIF style.
No errors found.
Using technology "sky130A", version 1.0.227-0-g527bfa4
Error message output from magic:
CIF file read warning: CIF style sky130(vendor): units rescaled by factor of 2 / 1
File StdCellLib_upstream.mag couldn't be read
No such file or directory
Done!

[FatsieFS]

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

[FatsieFS]

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

[gatecat]

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]

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]

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

[FatsieFS]

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

[gatecat]

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]

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]

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

[FatsieFS]

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]

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]

OK for me to merge.