https://open-source-silicon.dev
Join Slack
<@U0175T39732> I noticed a difference between scaled w/l mosfet parameters of the older `sram_1rw1r_...
# openram
m
@User I noticed a difference between scaled w/l mosfet parameters of the older 
sram_1rw1r_32_256_8_sky130.sp
(
W=0.21 L=0.15
) and those of the newer unscaled 
sky130_sram_1kbyte_1rw1r_32x256_8.lvs.sp
(
W=0.21u L=0.15u
) in the 
sky130_sram_macros
repo. I believe the sky130 magic extraction rules use the scaled 
w=70000u l=150000u
(=
W=0.21 L=0.15
).
m
Yes, the original was done in Cadence with Calibre extraction which was different than Magic.
I am using the current magic extraction rules and comparing with the .lvs.sp... so I'm not sure what you mean?
Actually, there may be a bug saving the final lvs if it "forgot" it was using magic/netgen vs calibre.
I saw this with the spice stimulus as well.
But when I ran LVS, it used the correct scale.
I just double checked and magic extracts W=0.21u L=0.15u with my settings...
Maybe you are setting a different extraction mode?
m
Good catch! Maybe we're getting closer to a solution.
For reference, I looked at the 
sky130_fd_sc_hd.spice
file, and it appears the parameters are 
w=420000u l=150000u
, which I believe matches the default magic extraction style. I found this in the tech file
Copy code
style ngspice variants (),(orig),(si)
 cscale 1
 # NOTE: SkyWater SPICE libraries use .option scale 1E6 so all
 # dimensions must be in units of microns in the extract file.
 # Use extract style "ngspice(si)" to override this and produce
 # a file with SI units for length/area.
Maybe you're using the 
si
style for the newer modules?
m
I've included my script so you should be able to replicate it.
I'll check more tomorrow.
m
Checked the 
run_ext.sh
script in the repo and found
Copy code
extract style ngspice(si)
So that's where it's coming from. Now what to do about it?
Right, it's just that it doesn't match the standard cells or the rest of the caravel cells.
So, if everything's black boxed, no problem, but I'm trying to do full device level LVS of the whole chip.
m
I see. That would require me going through and modifying all the SRAM cells in the build space
m
Or we could have @User convert the parameters during the 
open_pdks
build.
m
These cells aren't a part of that
Can't you use the simulation spice instead?
That will be the same thing with the different scale
m
Good solution! @User It appears that when openlane's 
build pdk
copies the 
sky130_sram_macro
data to 
pdks/sky130A/libs.ref/sky130_sram_macros/spice
directory, it just copies 
*.lvs.sp
to 
*.spice
. The 
*.lvs.sp
version has W/L parameters in 
si
units which don't match the rest of the 
sky130A/lib.ref
libraries. The 
sky130_sram_macro
repo also contains 
*.sp
files which have the expected W/L units. Do you see any problems with copying 
*.sp
instead of 
*.lvs.sp
? It's not a simple change of `open_pdks/sky130/Makefile`'s
Copy code
-spice %l/*/*.lvs.sp filter=custom/scripts/sp_to_spice.py \
to
Copy code
-spice %l/*/*.sp filter=custom/scripts/sp_to_spice.py \
because there are 3 files in each module directory that end in 
.sp
. For example,
Copy code
functional_stim.sp
sky130_sram_1kbyte_1rw1r_32x256_8.lvs.sp
sky130_sram_1kbyte_1rw1r_32x256_8.sp
Maybe
Copy code
-spice %l/*/*[0-9].sp filter=custom/scripts/sp_to_spice.py \
m
I'm not sure why I chose si units but it was while the PDK was evolving.
I find them more standard than the odd micron units of the PDK I guess
m
I think we've delineated the issue pretty clearly. Shouldn't be too hard to come up with a resolution that requires only a minimal change. Don't think you need to do anything on your side.
👍 1
m
Cool. Thanks again for your help
m
Using the 
run_lvs.sh
script in the repo I get
Copy code
bash-4.2$ netgen -batch
Netgen 1.5.208 compiled on Fri Nov 12 03:05:51 UTC 2021
bash-4.2$ magic -dnull -noc
Magic 8.3 revision 225 - Compiled on Fri Nov 12 03:02:01 UTC 2021.
bash-4.2$ run_lvs.sh
...
Circuit 1 contains 89357 devices, Circuit 2 contains 89357 devices.
Circuit 1 contains 20507 nets,    Circuit 2 contains 19488 nets. *** MISMATCH ***

Result: Cells failed matching, or top level cell failed pin matching.

Logging to file "sky130_sram_1kbyte_1rw1r_32x256_8.lvs.report" disabled
LVS Done.
Fri Nov 19 11:21:27 UTC 2021: Finished (0) LVS using Netgen /build/bin/netgen
I've made some experimental changes to my local copy of netgen that are intended to clear up some of the problems with pin count mismatches. I'm running that now.
With the modified netgen, I still get
Copy code
Circuit 1 contains 90512 devices, Circuit 2 contains 90512 devices.
Circuit 1 contains 21112 nets,    Circuit 2 contains 20093 nets. *** MISMATCH ***

Final result: 
Netlists do not match.
Is the clean LVS log file from your run available? Also, what versions of magic and netgen are you using?
t
@User: Should I go ahead and make that change in open_pdks?
@User: I tested the glob wildcard 
*[0-9].sp
and it works, so I'm going ahead and making that change to the open_pdks sky130 Makefile.
m
Thanks for the quick response.
@User The somewhat good news is that I finagled a clean LVS run with
Copy code
Magic 8.3 revision 233
Netgen 1.5.206 (modified)
Some of the vdd connections to the memory cells aren't being connected so I ran the extracted spice through this sed
Copy code
s,vdd_uq1854,vdd,
s,vdd_uq3134,vdd,
s,vdd_uq1982,vdd,
s,vdd_uq1918,vdd,
s,vdd_uq3838,vdd,
s,vdd_uq2622,vdd,
s,vdd_uq3070,vdd,
s,vdd_uq2558,vdd,
s,vdd_uq2686,vdd,
s,vdd_uq4030,vdd,
s,vdd_uq3902,vdd,
s,vdd_uq3774,vdd,
s,vdd_uq2238,vdd,
s,vdd_uq3966,vdd,
s,vdd_uq2366,vdd,
s,vdd_uq2174,vdd,
s,vdd_uq2302,vdd,
s,vdd_uq2750,vdd,
s,vdd_uq2430,vdd,
s,vdd_uq3582,vdd,
s,vdd_uq3646,vdd,
s,vdd_uq2814,vdd,
s,vdd_uq4094,vdd,
s,vdd_uq3006,vdd,
s,vdd_uq3454,vdd,
s,vdd_uq3518,vdd,
s,vdd_uq2110,vdd,
Maybe that's fixed with the latest magic update. I'll check next week. netgen (my version) took a little over an hour. @User A couple weeks ago, the change to use 
sky130_sram_*.sp
instead of 
sky130_sram_*.lvs.sp
when creating 
sky130_sram_*.spice
was suggested and incorporated into open_pdks. Unfortunately, even though this corrects the device size problems, the 
sky130_sram_*.sp
memory cells do not contain the parasitic transistor necessary to match the extracted version. Fixing the sizes in 
sky130_sram_*.lvs.sp
yields a match (with the extracted vdd changes mentioned above). These are the sed commands I used.
Copy code
s/\([Ww]=[0-9\.]*\)u/\1/
s/\([Ll]=[0-9\.]*\)u/\1/
m
Which SRAM is this on?
A single or dual port? Edit: need to read better
And which cells had the extraction problem? Can you share your results?
t
@User: Seems easy enough to implement the patch in a simple filter script.
m
The unique extraction sed bit worries me because I didn't need to do that.
Then again, I'm using Magic 8.3.197
m
I'll respond on Monday.
@User I'm rerunning with magic 8.3.237. I'll post the results if there's a problem. One of the reasons I suspect LVS takes so long is that the memory cell contains parasitic transistors that are shared with the adjacent cell. netgen has to flatten the entire bit array to get a match. I'm thinking about a change that may speed up flattening and can hopefully do some testing this week. @User I agree that it should be possible to change the device sizes with a simple filter. If it's ok with you, I can probably submit a PR this week.
Unfortunately, I didn't get the results I was expecting with magic 8.3.237. (@User please refer to github - the subckt calls have duplicate ports and don't match the instance port counts). I don't know if this is related, but the layout appears to have upper and lower case signals on the same net. Here's the results I got with magic 8.3.233 with the changes I made to the extracted netlist.
sram_1rw1r.tar.gz
9 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by