extraction routine gives different connectivity depending on cif istyle about magic HOT 8 OPEN

@d-m-bailey : Two things that would affect this: (1) I made a correction to magic two days ago that fixes an issue with connectivity through subcells in the SPICE netlist. That error might be implicated here. (2) I made a change to sky130A.tech a few weeks ago to make "sky130(vendor)" the default input style, since after some changes were made to the sky130(vendor) style maybe half a year ago, I no longer have any issues interpreting ports and labels from GDS files, whether they are from magic or elsewhere, so there doesn't appear to be any reason to use the sky130() (previously default) style.

from magic.

@RTimothyEdwards The tar file was missing some files (.magicrc and sky130A.tech in the wrong directory). I recreated it with the latest setup and tech files. The title of this issue is now somewhat misleading.
The with the current program, the current tech file yields an incorrect extraction.

The magic version I'm using is 8.3.196 (MAGIC_COMMIT=597ef4857a02f1d0748475dcff118801e91b0e88) which should be the most recent.

The tech file that openram was using did not have the vendor style as default. The tar file that I've attached is using a more recent version with vendor as the default. The data is taken, as is, from the sky130_sram_1kbyte_1rw1r_32x256_8 macro of the sky130_sram_macros repo. The run_ext.sh and run_lvs.sh scripts have been modified to write to a subdirectory, magic, and to use the installed versions of magic (8.3.196) and netgen (1.5.196).

./run_ext.sh
./run_lvs.sh
./run_lvs_fix.sh

The run_lvs.sh script does not pass as you can see in the magic/sky130_sram_1kbyte_1rw1r_32x256_8.lvs.report result. However, running run_lvs_fix.sh, which creates a modified netlist magic/sky130_sram_1kbyte_1rw1r_32x256_8.fix.spice, does pass as you can see in magic/sky130_sram_1kbyte_1rw1r_32x256_8.fix.lvs.report.

The netlist modifications are contained in the file vdd.sed and are connecting 29 vdd_uq* signals to vdd.

I was expecting run_lvs.sh to pass.

sram_lvs_196_196.tar.gz

from magic.

Thanks for putting together the example tarball.

from magic.

@d-m-bailey : I started off by writing my own version of the extract and LVS scripts. Then, seeing that I was using the default extraction style with the 1.0E6 scalefactor, I removed the "u" from all the dimensions in the LVS netlist. Then I ran extraction and LVS and everything matched. A bit surprised by that, given your result, I then switched back to your LVS netlist and changed my extraction script to use the ngspice(si) extract style. And then I ran extraction and LVS and got the same error as you did. The implication is that it's the extraction style that makes the difference. . . in spite of the fact that the only thing different about the extraction style is the scalefactor! I am now making two sets of all files for runs "good" and "bad", to see if I can see anything in the files that's different other than the scalefactor, and also to make sure that this result can be duplicated.

from magic.

@d-m-bailey : I figured out why changing the style affects the outcome; the tech setup has an error that multiplies one of the scalefactors twice, such that changing the extract style in any way will change the extraction step size. That doesn't really solve the issue, which I'm aware of and which is caused by the extraction "cookie cutter" method. Solving that error is difficult; fixing the SRAM extraction by fixing the step size calculation and then choosing a step size that doesn't cause the issue to show up when extracting the SRAM is easier.

from magic.

@RTimothyEdwards Is it easy to fix the tech file? The previous sram setup used the blank style and extracted the connectivity correctly. I'd like to see if fixing the tech file solves the problem.

from magic.

@d-m-bailey : In this case, the schematic netlist has SI units for width and length, which makes it effectively unsimulatable. My preference would be to have Matt bring the schematic netlist in line with the SkyWater device models (e.g., "W=0.21", not "W=0.21u"). So you can extract with the default style, but you will get property errors for every transistor unless you change the schematic netlist. If you want it to extract correctly using SI units for length and width, then you can modify the tech file to specify the extract styles as "ngspice variants (si),(orig),()", which would make "ngspice(si)" the default. I want to reiterate that the problem is not with the tech file, the problem is in the magic source code which is (as I think I have figured it out, now) using an old scale value when computing the extraction step size when the extraction style is changed. I am working on fixing that problem now. But then I also want to reiterate that there is a more difficult underlying problem in that the extraction can get confused when a net is connected together in different levels of hierarchy and also extends through several stepped regions. You can see from the example that the problem occurs when using "extract unique", in which the power supply line is seen as six or seven separate nets and is given unique net names, so when the extraction steps through different areas, it sees the power net as, say "vdd_uq1" instead of "vdd", and doesn't merge it into a single net. Possibly there is something I can do to the way the "extract unique" command works that would fix the issue, but I haven't looked into that yet.

from magic.

@d-m-bailey : Sorry I had to punt on this issue for a few weeks. I just looked into it more closely and realized that whenever the "extract style" command is used to set or change the extraction style, all the dimensional parameters of the extraction get scaled twice, so the extraction result will get screwed up in many ways. This should be fixed now (just pushed a fix to the repository on opencircuitdesign.com).

from magic.