I have updated

open_pdks

now to enable both mismatch and process variation statistical analysis for sky130. The major change for the end-user is that ngspice testbenches will require the line

.param mc_mm_switch=0

or

.param mc_mm_switch=1

at the top to disable or enable device mismatch. Process variation is enabled by a corner-model-like specification using

.lib _<path>_/sky130.lib.spice mc

and then requires

.option SEED=random

or

.option SEED=_<value>_

to ensure that every run of ngspice will produce another set of random parameter values.

What's the difference between the

mc

choice and other choices like

tt

,

ss

, etc.?

mc

means "monte carlo". Instead of values being tuned to a specific process corner like

ss

or

ff

, all the process variables are randomized with a normal distribution. With

SEED=random

you will get a different set of parameters every time you do a run. So you can do 1,000 simulations and get a statistical distribution of circuit behavior over a statistically significant set of possible process runs. Since it is hard, with a random distribution or in real life, for all variables to be at extremes, the monte carlo distributions tend to be less severe than the process corners, and so are more representative of real circuit behavior from a real fabrication run.

I selected the

mc

library and when trying to simulate a design with

sky130_fd_pr__nfet_01v8_lvt

, I get the following error:

Error: unknown subckt: x0.x10 x0.amplifier_0/vq x0.amplifier_0/vx 0 0 x0.0.0+mc_pr_switch*agauss 0 x0.1.0 x0.1 <http://x0.ad|x0.ad>=5.6e+11p x0.pd=4.00207e+06u as=7.38427e+12p ps=4.18992e+07u w=2e+06u l=2e+06u
    Simulation interrupted due to error!

The subckt should be:

X10 amplifier_0/Vq amplifier_0/Vx GND GND sky130_fd_pr__nfet_01v8_lvt ad=5.6e+11p pd=4.00207e+06u as=7.38427e+12p ps=4.18992e+07u w=2e+06u l=2e+06u

It looks like

sky130_fd_pr__nfet_01v8_lvt

was replaced with

0.0 + MC_PR_SWITCH*AGAUSS(0,1.0,1)

. I checked

open_pdks/sky130A/libs.tech/ngspice/sky130.lib.spice

and

open_pdks/sky130A/libs.tech/ngspice/parameters/critical.spice

and saw there's a

.param sky130_fd_pr__nfet_01v8_lvt = 0.0 + MC_PR_SWITCH*AGAUSS(0,1.0,1)

. I saw in the commented out section a corresponding

vary sky130_fd_pr__nfet_01v8_lvt dist=gauss std=1.0

. The latter format looks like it's for a different SPICE simulator, so do I need the

.param sky130_fd_pr__nfet_01v8_lvt = 0.0 + MC_PR_SWITCH*AGAUSS(0,1.0,1)

at all? I tried commenting that line out and saw that it's referenced by other .param statements, so it's gotta be there. My model names in the .spice aren't in quotes or braces, so I'm confused as to why the substitution of

.param sky130_fd_pr__nfet_01v8_lvt = 0.0 + MC_PR_SWITCH*AGAUSS(0,1.0,1)

for

sky130_fd_pr__nfet_01v8_lvt

is happening in the first place.

I noticed the collision between the parameter names and the device names and since that was true of the original SkyWater decks I assumed it would not be an issue. It could be that ngspice is treating the parameter by doing a wholesale search-and-replace, which would be an incorrect implementation, but would match what you're seeing.

I think there's a limited number of conflicts. It looks like model names appear throughout lines 51 to 68 of

libs.tech/ngspice/parameters/critical.spice

Now I have two mysteries, because some of those entries add in the random variable twice, which looks like a parsing error in my patch script.

A nice little surprise

After spending much more of the day than I intended on this problem, open_pdks now converts the offending parameter names, and I confirmed that it works with the

nfet_01v8_lvt

device now. The list of parameter names to correct was hand-compiled from inspecting the file, but I think it's comprehensive.

That's awesome. Thanks so much Tim!!!