@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

sky130.lib.spice

file has numerous corner sections relating to monte carlo simulation. Each simulation corner has a corresponding mismatch analysis corner, such as

ff_mm

for transistors, or

ll_mm

for resistors and capacitors, which will perform device mismatch. For monte carlo process variation, use the corner

mc

, 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

ff

for transistors plus

ll

for resistors and capacitors), you can always spin your own version of

sky130.lib.spice

. 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

toxe

for the device in question and figure out what scaling was applied to the gaussian (e.g.,

sky130_fd_pr__nfet_01v8__toxe_slope

). 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

parameter

with

MC_MM_SWITCH*AGAUSS(0,1.0.1)

, 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?

@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 (

all.spice

, I think, or something included from that) that sets the scale. It is not specifically an ngspice thing.

I see.

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