<@U016EM8L91B> do you have a copy of the instructi...
# analog-design
@User do you have a copy of the instructions for using MC now that you've setup the libraries correctly? @User is asking and I can't go far enough in time to see your previous posts
I don't have instructions per se. It is relatively easy to set up. Once you have an open_pdks installation, the
file has numerous corner sections relating to monte carlo simulation. Each simulation corner has a corresponding mismatch analysis corner, such as
for transistors, or
for resistors and capacitors, which will perform device mismatch. For monte carlo process variation, use the corner
, which will then randomize process parameters on each run. Note that there is no mixture of front-end and back-end mismatch; the front-end corners use typical back-end parameters, and the back-end corners use typical front-end parameters. If more corner types are needed (such as
for transistors plus
for resistors and capacitors), you can always spin your own version of
. The proper invocation for the file in a SPICE netlist is
.lib /_path_/_to/_sky130.lib.spice _corner_
, e.g.,
.lib /usr/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice tt_mm
for transistor mismatch analysis at the typical process corner.
@Tim Edwards Thank you Tim. I directly worked on the original PDK - this was why I couldn't find the correct setup. I will definitely try your open_pdk tool and get back to you. Thank you for your gret contribution to this community
Thanks @Tim Edwards
@Chen Zach: The monte carlo equations weren't in the original PDK because I didn't have time to figure out how to make them compatible with ngspice. So I left them in commented-out lines. Later I wrote a script to convert those commented lines into the proper syntax for ngspice, and added the script to open_pdks. So you can only get the monte carlo simulation working by using the PDK from open_pdks (there are also about a dozen patch files total to fix various issues with the device models).
@Tim Edwards I'm pretty sure it now works well with ngspice, yet I have a quite special need here. For some reasons we wish to use hspice to simulate, and we expected a minor modification to your ngspice netlist. Our modifications do work correctly for corner simulations, but it shows errors when we tried to add random variables agauss(0, 1.0, 1) like what you did. The error message (attached) shows certain parameters are not positive in BSIM4 model. Is it because ngspice and hspice do not have the same MOSFET model file? I would appreciate any insights.
@Chen Zach: In principle a gaussian goes to infinity in both directions and if applied to something like tox (oxide thickness) which must be strictly positive, could result in a bad value. However, the probability of that should be vanishingly small if the coefficients are correct. It would be helpful to find the expression for
for the device in question and figure out what scaling was applied to the gaussian (e.g.,
). I can only advise that I took the spectre models, and where they had, for example,
vary _parameter_ dist=gauss std=1.0
, I parsed through the device model and replaced
, which I believe to be the equivalent ngspice expression.
@Tim Edwards What you explained makes good sense. I did exactly the same thing to HSPICE and used the same scaling factor (sky130_fd_pr__nfet_01v8__toxe_slope), but it reports errors. I am wondering if anyone found similar errors in ngspice before. Could it be a bug from the PDK?
If it's not a bug, the only reason could be that HSPICE and ngspice have different MOSFET models, especially differ in the scaling factor, which is also hard to believe because ngspice is compatible with HSPICE netlist as far as I know.
@Tim Edwards I managed to find out the issue. It seems that the length units in ngspice and HSPICE are different. I managed to clear the errors once I modify 1/sqrt(l*w*mult) to 1/sqrt(l*w*mult*1e12). But I'm not sure if this scale is correct. Would like to hear some insights
@Chen Zach: Are you able to do a simulation in both hspice an ngspice and get the same result with the scalefactor? I'm trying to figure out if the scalefactor is needed in ngspice (that is: is the problem not a difference between ngspice and hspice, but between spectre and (ngspice, hspice)). If the scalefactor is needed for both ngspice and hspice, then I just need to fix the mismatch models. If the scalefactor must be different for hspice than for others, then we'd need to figure out if it is a bug in ngspice or if I just need to add some additional 1-or-0 parameter like
1/sqrt(l*w*mult*(1 + HSPICE_SWITCH*1e12))
@Tim Edwards I haven't made comparisons - will do more testing later. I guess scalefactor may not be needed for ngspice, because the default length unit for ngspice is micro. In other words, if I need a NMOS with 500 nm width, in hspice I need to put in 500n but ngspice needs 0.5
No, the default length and width units of microns is something set by SkyWater (and a huge annoyance). There is a
.option scale
in one of the library files (
, I think, or something included from that) that sets the scale. It is not specifically an ngspice thing.
I see.
Then the problem is not from the tools or PDKs. I only partially included the library files for hspice simulation, because tons of modifications need to be made to get the entire PDK compatible with hspice. That's why I didn't have that scale factor
The device parameters are all assuming the scalefactor. It's very difficult to work through the parameters equations and figure out how to pull the scalefactor out of them, otherwise I would have changed everything back to SI units a long time ago.
Then it's better for me to add the scalefactor back instead of modifying the equations in case there will be other conflicts. Thank you again Tim