https://open-source-silicon.dev logo
#sky130
Title
# sky130
m

Matthew Guthaus

06/08/2021, 4:56 PM
@User @User In the spice device models, I see a parameter "dev/gauss" defined in the models but not referenced anywhere. Is this name for compatibiity with a known model or simulator? e.g.: https://github.com/google/skywater-pdk-libs-sky130_fd_pr/blob/f62031a1be9aefe902d6[…]7627436/cells/cap_var_lvt/sky130_fd_pr__cap_var_lvt.model.spice
t

Tim Edwards

06/08/2021, 4:58 PM
Yes, it is a spectre-ism. I left the relevant lines in the sky130_fd_pr library SPICE models as comments so they could be converted to an ngspice-compatible format. I have a script in open_pdks that does this. The models installed from open_pdks can run both process variation and mismatch monte carlo analysis in ngspice.
m

Matthew Guthaus

06/08/2021, 4:59 PM
This name seems to be illegal in Xyce (due to the /).
t

Tim Edwards

06/08/2021, 5:00 PM
Yes, it's only proper in spectre. However, the ngspice compatible version might also be illegal in xyce. Haven't tried it. At least it only requires that there exist a function agauss() recognized by the simulator.
Meaning that if it isn't supported by xyce, it would be, I think, relatively easy for them to implement.
m

Matthew Guthaus

06/08/2021, 5:03 PM
I'm debugging the Xyce now. It isn't compatible. I'd like to have a path forward without requesting features in Xyce right now. ngspice doesn't complain about a syntax error, at least.
@Tim Edwards Speaking of this, how do you differentiate the netlists for the different simulators in open_pdks? Do you just generate ngspice compatible? Or should I patch something so we have separate Xyce compatible in the case of things that are different? For example, .option scale=1u must be .options parser scale=1u in Xyce.
t

Tim Edwards

06/08/2021, 5:06 PM
It does appear that the model file you cited above was missed in the handling of monte carlo parameters. I will have to look into that. There should not be any "dev/gauss" in the model files that is not commented out.
m

Matthew Guthaus

06/08/2021, 5:07 PM
Ahh, that would work as well!
In that case, I'm down to 1 error to get the models working with Xyce. Most changes aren't too bad and should be compatible with ngspice
t

Tim Edwards

06/08/2021, 5:09 PM
open_pdks can support any number of simulators, but since I only have ngspice here to work with, that's the only one I've done anything to support. To support xyce would require that somebody figure out exactly what needs to be done to support sky130 (other than tell the developers to go add/fix something), and write scripts to generate the right files. The libraries, though, have directories "spice" rather than "ngspice", which is sort of assuming a universally accepted format that is probably wishful thinking.
m

Matthew Guthaus

06/08/2021, 5:11 PM
@Tim Edwards Yup, I'm doing that right now with Erik's help
t

Tim Edwards

06/08/2021, 5:11 PM
If you have only one error, though, perhaps it's not wishful thinking after all. For the "option scale" thing, that would be in the tools directories, and would presumably be wanting a directory "xyce" to go along with the directory "ngspice", and the "all.spice" file or whereever it is that that option occurs would be patched up correctly for xyce there.
m

Matthew Guthaus

06/08/2021, 5:12 PM
There are only two other fixes so far: 1. Replace $ end of line comment with ; which is ngspice compatible. Simple regex. 2. Add .ENDL <libname> in sky130.lib.spice which should also be ngspice compatible.
@Tim Edwards Yup, I've got Xyce working with the models now
t

Tim Edwards

06/08/2021, 5:23 PM
I think the dev/gauss thing may be the result of the monte carlo patch-up script not looking through the cells/ directory. I had not seen any mismatch parameters there. What's in the libraries would be wrong in ngspice whether or not it's flagged as illegal syntax. My understanding is that, for example,
cx1='5.75e-16' dev/gauss='sky130_fd_pr__cap_var_lvt__cmax_slope_l/sqrt(2*ld*vm)'
should be converted to
cx1='5.75e-16*mc_mm_switch*sky130_fd_pr__cap_var_lvt__cmax_slope_l/sqrt(2*ld*vm)
. . . or something like that? No, there must have to be a call to agauss() in there somewhere. Elsewhere they use a
statistics
block and it says what the mean and standard deviation are. So somebody needs to tell me what
dev/gauss
really means.
m

Matthew Guthaus

06/08/2021, 5:24 PM
I just commented it out for now with a
; dev/gaus...
t

Tim Edwards

06/08/2021, 5:24 PM
That was my previous solution, but I had recently been trying to get the monte carlo simulations working correctly.
m

Matthew Guthaus

06/08/2021, 5:34 PM
@Tim Edwards Do we do PRs on github for this stuff or?
t

Tim Edwards

06/08/2021, 5:34 PM
If it's for open_pdks, then yes, a PR on github works fine.
m

Matthew Guthaus

06/08/2021, 5:39 PM
I think this is directly in the source from sky130_fd_pr
t

Tim Edwards

06/08/2021, 5:39 PM
Can't do a pull request on the skywater databases yet, which is why I apply all these things as scripts and patches in open_pdks.
m

Matthew Guthaus

06/08/2021, 5:40 PM
So if I just send a patch is that ok?
Some of the stuff can be done with regex, some can't easily
t

Tim Edwards

06/08/2021, 5:42 PM
I don't try to patch the repositories directly from open_pdks, I patch the installed libraries. For the most part, it's the same. It would work better if you give me the scripts and let me figure out how to apply them.
@Matthew Guthaus: In reference to the
dev/gauss
syntax: I poked around and determined that this is PSPICE syntax. I don't know why this is variously scattered around the SkyWater files in addition to the spectre syntax. Apparently it is a shorthand for a device-level (e.g., monte carlo mismatch) parameter gaussian variation with zero mean and a standard deviation equal to the value that it is set to. So I am working now on an automatic conversion that would make your original example look like
Copy code
+ cm3='6.529e-16*cnwvc_cdepmult+MC_MM_SWITCH*AGAUSS(0,1.0,1)*sky130_fd_pr__cap_var_lvt__cmin_slope_wl*cnwvc_cdepmult/sqrt(2*ld*wd*vm)'
I think that this treatment is correct.
m

Matthew Guthaus

06/09/2021, 5:44 PM
@Tim Edwards I dont see the AGAUSS stuff anywhere in the sky130_fd_pr library, this is added by open_pdks? Where does open_pdks place its libraries -- I have been just using the ones in skywater-pdk/libraries/sky130_fd_pr/latest.
OHH, I should be including from open_pdks. I see.
We can make a separate xyce directory with that .options parser scale difference then?
t

Tim Edwards

06/09/2021, 5:49 PM
Yes. The idea is to have
libs.tech/xyce
in addition to
libs.tech/ngspice
. Probably it is okay just to have that one file in there, and then everything in it would point to the ngspice directory. I am currently working on the open_pdks scripts and have knocked down everything in your list except for the "vt" issue and the ".endl" issue (no issues other than time).
m

Matthew Guthaus

06/09/2021, 6:12 PM
The AGAUSS stuff does not work in Xyce
@Tim Edwards Did you notice that all of the .lib statements include the TT corner spice?
@Tim Edwards I manually applied my fixes to the sky130A ngspice files to get a jump on it. ~It seems the AGAUSS is actually ok, but there are some other parameter issues~:
Copy code
/software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter LDIF found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter HDIF found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter RD found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter RS found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter RSC found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter RDC found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice
 at or near line 34
 No model parameter NQSMOD found for model
 SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0 of type NMOS, parameter ignored.
Parameter TOX for model
 XSRAM:XBANK0:XBITCELL_ARRAY:XBITCELL_ARRAY:XBIT_R0_C0:X0:SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0
 contains unrecognized symbols:
 4.148e-009*sky130_fd_pr__special_nfet_latch__tox_mult+MC_MM_SWITCH*AGAUSS(0,1.0,1)*(4.148e-009*sky130_fd_pr__special_nfet_latch__tox_mult*(sky130_fd_pr__special_nfet_latch__tox_slope/sqrt(l*w*mult)))
*** Xyce Abort ***
Parameter TOX for model
 XSRAM:XBANK0:XBITCELL_ARRAY:XBITCELL_ARRAY:XBIT_R0_C0:X0:SKY130_FD_PR__SPECIAL_NFET_LATCH__MODEL.0
 contains unrecognized symbols:
 4.148e-009*sky130_fd_pr__special_nfet_latch__tox_mult+MC_MM_SWITCH*AGAUSS(0,1.0,1)*(4.148e-009*sky130_fd_pr__special_nfet_latch__tox_mult*(sky130_fd_pr__special_nfet_latch__tox_slope/sqrt(l*w*mult)))
t

Tim Edwards

06/09/2021, 6:25 PM
You do need to define
.param MC_MM_SWITCH = 1
(or
= 0
) at the top of any simulation because the corner models can work either with or without mismatch enabled. I have been considering changing
sky130.lib.spice
to just have different category names for each corner with- and without- mismatch, so that it is not necessary for the testbench to define
MC_MM_SWITCH
. The other issues are all
parameter ignored
and it looks like those would not stop Xyce from running (but are they important?).
m

Matthew Guthaus

06/09/2021, 6:26 PM
No, Xyce terminates with a fatal error
t

Tim Edwards

06/09/2021, 6:27 PM
Even with
MC_MM_SWITCH
defined?
m

Matthew Guthaus

06/09/2021, 6:27 PM
It's interesting that I never defined that for ngspice...
Yes, it still aborts with that
t

Tim Edwards

06/09/2021, 6:28 PM
It was only introduced recently and only matters for the files as generated by open_pdks.
Can you post (or send me) the netlist that you are simulating (with testbench, if separate) so I can try it with my current changes to open_pdks (which I have not committed yet)?
m

Matthew Guthaus

06/09/2021, 6:29 PM
That will require another "feature" to add extra stimulus code for certain PDKs 😕
sh_stim.sp,sky130_fd_bd_sram__openram_dff.sp
t

Tim Edwards

06/09/2021, 6:31 PM
Which is why I was considering just changing the
sky130.lib.spice
to avoid it. For example, there would be corner
tt
as usual meaning typical-without-mismatch, and
tt_mm
meaning typical-with-mismatch. If you think that's a much better solution than introducing parameters that have to be added to testbenches, then I can make that change. It doubles the size of `sky130.lib.spice`; given ngspice's weird parsing, I don't know if that will increase the simulation startup time, which is the one reason I've been hesitant to do it.
m

Matthew Guthaus

06/09/2021, 6:32 PM
Ah, I think it's a good idea. BTW, Xyce is MUCH faster at parsing. Orders of magnitude..
t

Tim Edwards

06/09/2021, 6:33 PM
I have been avoiding Xyce due to compatibility issues. But if we successfully work through this list, that will be a game-changer.
So have you determined that the
AGAUSS()
function is something that Xyce isn't happy with? Does Xyce have a concept of user-definable functions? I'm wondering if there is some way to work around it.
m

Matthew Guthaus

06/09/2021, 6:37 PM
I haven't looked into that yet. Xyce seems to have it's own ways of doing MC and such
t

Tim Edwards

06/09/2021, 6:44 PM
The current setup is probably good for that, since (other than "dev/gauss" lines that got left in) the monte carlo stuff from spectre is mostly just commented out, so I can generate an entire secondary set of files for Xyce if necessary based on Xyce syntax. Somebody will need to point me to some documentation, though.
m

Matthew Guthaus

06/09/2021, 9:44 PM
Do you do something with the dimensions in the sky130A processing? I see that you converted the ngspice all.spice to use .options parser scale=1u which I don't think is compatible with ngspice.
I get lots of scale warnings:
Copy code
Netlist warning in file
 /software/PDKs/sky130A/libs.tech/xyce/../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8__tt.pm3.spice
 at or near line 33
 Device instance
 XSKY130_FD_BD_SRAM__OPENRAM_DFF:X1020:MSKY130_FD_PR__PFET_01V8: Source
 conductance reset to 1.0e3 mho
This might be related to the AGAUSS scaling...
t

Tim Edwards

06/10/2021, 12:43 AM
I didn't do anything to "all.spice" at all. If you have Xyce syntax in it, it must be yours.
m

Matthew Guthaus

06/10/2021, 6:51 PM
Can confirm that the other errors were due to my using my modified skywater-pdk. Now I get just those model errors. The only difference is the AGAUSS stuff, it appears.
t

Tim Edwards

06/10/2021, 6:53 PM
Now I just need to figure out why Xyce on my machine is throwing weird errors about zero channel length. It seems really close to working.
m

Matthew Guthaus

06/10/2021, 6:55 PM
Yes, that is what I get too:
Copy code
Effective channel width <= 0
...
Effective channel length for C-V <= 0
I'm looking at the differences between it and sky130_fd_pr and it seems fine for these computations:
Copy code
< + toxe = {4.23e-09+MC_MM_SWITCH*AGAUSS(0,1.0,1)*(4.23e-09*(sky130_fd_pr__pfet_01v8__toxe_slope/sqrt(l*w*mult)))}
---
> + toxe = {4.23e-09+sky130_fd_pr__pfet_01v8__toxe_slope_spectre*(4.23e-09*(sky130_fd_pr__pfet_01v8__toxe_slope/sqrt(l*w*mult)))}
t

Tim Edwards

06/10/2021, 6:57 PM
Does that mean that you are currently unable to run Xyce with sky130?
m

Matthew Guthaus

06/10/2021, 6:57 PM
Yes
(Unless I go back to my hacked sky130_fd_pr)
t

Tim Edwards

06/10/2021, 6:58 PM
Oh, so your hacked version sky130_fd_pr was simulating, but you have not yet tracked down what the difference is that breaks Xyce.
m

Matthew Guthaus

06/10/2021, 6:59 PM
Exactly. I'm diffing with the version that simulated fine. The only difference is the AGAUSS stuff from what I can tell. With the spectre stuff it was fine
t

Tim Edwards

06/10/2021, 7:01 PM
Although you said that the expression above with AGAUSS was fine. . . ? There are, in a way, two uses of AGAUSS, one of which comes from the spectre "statistics" block stuff and has been pretty well vetted, and then the one which comes from the "dev/gauss" PSPICE entries, which I just added, and which has not been vetted at all except that I have been able to run ngspice.
m

Matthew Guthaus

06/10/2021, 7:04 PM
Sorry, with AGAUSS doesn't work. It looks fine. The one with toxe_slope_spectre is fine.
11 Views