https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> <@U016ULGAUNM> In the spice device ...
# sky130
m
@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
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
This name seems to be illegal in Xyce (due to the /).
t
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
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
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
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
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
@Tim Edwards Yup, I'm doing that right now with Erik's help
t
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
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
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
I just commented it out for now with a 
; dev/gaus...
t
That was my previous solution, but I had recently been trying to get the monte carlo simulations working correctly.
m
@Tim Edwards Do we do PRs on github for this stuff or?
t
If it's for open_pdks, then yes, a PR on github works fine.
m
I think this is directly in the source from sky130_fd_pr
t
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
So if I just send a patch is that ok?
Some of the stuff can be done with regex, some can't easily
t
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
@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
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
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
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
No, Xyce terminates with a fatal error
t
Even with 
MC_MM_SWITCH
defined?
m
It's interesting that I never defined that for ngspice...
Yes, it still aborts with that
t
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
That will require another "feature" to add extra stimulus code for certain PDKs 😕
sh_stim.sp,sky130_fd_bd_sram__openram_dff.sp
sh_stim.spsky130_fd_bd_sram__openram_dff.sp
t
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
Ah, I think it's a good idea. BTW, Xyce is MUCH faster at parsing. Orders of magnitude..
t
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
I haven't looked into that yet. Xyce seems to have it's own ways of doing MC and such
t
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
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
I didn't do anything to "all.spice" at all. If you have Xyce syntax in it, it must be yours.
m
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
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
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
Does that mean that you are currently unable to run Xyce with sky130?
m
Yes
(Unless I go back to my hacked sky130_fd_pr)
t
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
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
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
Sorry, with AGAUSS doesn't work. It looks fine. The one with toxe_slope_spectre is fine.
12 Views
Open in Slack
PreviousNext
Powered by