In sky130, the parameters

MC_MM_SWITCH

and

MC_PR_SWITCH

correspond to what you refer to as

mm_ok

and

mc_ok

. Equations take a form like

mismatch_factor*MC_MM_SWITCH*AGAUSS(0,1.0,1)

, where the gaussian mean in the

AGAUSS

function call is always set to zero and the sigma is alwasy set to one; the expression result is then multiplied by

mismatch_factor

(which takes care of the sigma) and is added to the parameter nominal value (which takes care of the mean). Example usage suggests that

mismatch_factor = 1

corresponds to 3 sigma. This can vary from foundry PDK to foundry PDK, but when converting from, say, spectre models to ngspice, this is generally the easiest way to do the conversion.

The other question I have is about separating process variation analysis and mismatch variation analysis. For the IHP-Open-PDK we would like to provide mismatch variation and the question is if it does make sense to keep process, mismatch, process + mismatch variation separated from designers point of view.

@Krzysztof Herman: For all the PDKs that I have seen, process and mismatch parameters are handled separately. For sky130, I created the

sky130.lib.spice

file and made a number of different categories, most of which were combinations of corners and mismatch; process variation (monte carlo) is a single

.lib

section and not combined with anything. It probably should include sections where process and mismatch are combined. I did not do that because at the time ngspice was struggling with the

.lib

files and unfortunately processing all the

.lib

sections instead of just the one being requested, which was causing ngspice to take ages to start up a simulation. That has been fixed, so there is no reason not to include every kind of useful combination of variations in the

.lib

file.