StdCellLib DRC fixes and via enclosure improvement #5
Conversation
|
Hopefully I did magic DRC properly this time and is the design DRC clean. |
|
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. |
|
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. |
|
And there seems to be implant spacing errors after routing also be left... |
FatsieFS
force-pushed
the
staf/drcfix
branch
from
451fce9 to
b562871
Compare
|
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. |
|
And I rebased also on main branch. |
|
I've tried this branch and I think I'm still seeing a DRC error in
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... |
|
How do you run DRC ? I guess I wrongly assumed DRC was OK but that it actually errored out. % ~/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! |
|
OK, I can reproduce the DRC error now in the magic GUI; will fix. |
FatsieFS
force-pushed
the
staf/drcfix
branch
from
b562871 to
65a3a69
Compare
|
I hope I have now solved the decap_w0 DRC error also. My magic DRC setup is still not ideal. |
|
Unfortunately I now seem to be seeing a different error in
fwiw, I am using the rcfile |
|
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 |
|
Seems I botched the commit as I saw and fixed that problem; mmm... |
FatsieFS
force-pushed
the
staf/drcfix
branch
from
65a3a69 to
2687ae7
Compare
|
Seems I only regenerated gds files and not the Coriolis files for last commit. |
|
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: |
|
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! |
|
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
force-pushed
the
staf/drcfix
branch
from
2687ae7 to
6ebf089
Compare
|
Problem was that I did not use the proper direction for the PinOnly layer and that way computed the enclosures wrongly. |
|
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 |
|
OK for me to merge. |
2 participants
wire in the routing direction.