I'm trying to run MC simulations with ngspice and the results are repeating. I don't know why. Here is my circuit

* Monte carlo test

* Include SkyWater sky130 device models
.lib "/usr/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice" tt
.param mc_mm_switch=1

.include "../aux/array.spice"
.include "../aux/inv.spice"

.param pVDD = 3.3

VDD  vdd 0 dc {pVDD}
VSS  vss 0 0

x0 q q vdd vss inv1_1

.option seed=random
.control
	echo # Monte carlo run > mc.txt
	let run = 1
	dowhile run <= 100
		reset
		op
		print q
		let q = v(q)
		echo $&run $&q >> mc.txt
		let run = run + 1
	end

.endc

.end

and my results

# Monte carlo run
1 1.60672
2 1.60672
3 1.60672
4 1.6164
5 1.6164
6 1.6164
7 1.6164
8 1.6164
9 1.61179
10 1.61179
11 1.61179
12 1.61179
13 1.61179
14 1.61632
15 1.61632
16 1.61632
17 1.61632
18 1.61632
19 1.61632
20 1.61632
21 1.60583
22 1.60583
23 1.60583
24 1.60583
25 1.60583
26 1.60583
27 1.61683
28 1.61683
29 1.61683
30 1.61683
31 1.61683
32 1.61683
33 1.61683
34 1.61374
35 1.61374
36 1.61374
37 1.61374
38 1.61374
39 1.61631
40 1.61631
41 1.61631
42 1.61631
43 1.61631
44 1.61631
45 1.61631
46 1.61606
47 1.61606
48 1.61606
49 1.61606
50 1.61606
51 1.61606
52 1.6167
53 1.6167
54 1.6167
55 1.6167
56 1.6167
57 1.6167
58 1.61162
59 1.61162
60 1.61162
61 1.61162
62 1.61162
63 1.61162
64 1.61162
65 1.61726
66 1.61726
67 1.61726
68 1.61726
69 1.61726
70 1.61726
71 1.61863
72 1.61863
73 1.61863
74 1.61863
75 1.61863
76 1.61863
77 1.60948
78 1.60948
79 1.60948
80 1.60948
81 1.60948
82 1.60948
83 1.60948
84 1.61978
85 1.61978
86 1.61978
87 1.61978
88 1.61978
89 1.61978
90 1.61307
91 1.61307
92 1.61307
93 1.61307
94 1.61307
95 1.61307
96 1.61317
97 1.61317
98 1.61317
99 1.61317
100 1.61317

Thanks for explaining this weird behavior, @User I really didn't understand the runs of 3/5 identical values, sounds like the seed is updated with the unix time in seconds.

SEED=val|random Sets the seed value of the random number generator. val may be
any integer number greater than 0. As an alternative, random will set the seed
value to the current Unix epoch time, which is the time in seconds since 1.1.1970
excluding leap seconds.

@User: If you are doing mismatch simulation then you should be using the

tt_mm

corner in the

.lib

statement, not the

.tt

corner. Possibly it is the same to just set

mc_mm_switch

to

1

afterward, but SPICE does not necessarily respect the order in which statements appear in a netlist, so what you have above has conflicting settings for

mc_mm_switch

. That said, I agree with Stefan that it may be due to the use of

SEED

as

random

. The way I have done mismatch simulations (and which I know works) is to run ngspice independently N times on the same circuit but changing the value of option

SEED

for each run.

My problem with running it independently is that I don't know yet how to use outside scripts for multiple runs. And it should be slow, as for each run it would take time to set the models. I'm used to run process only, mismatch only and all settings while running monte carlo simulations in cadence tools. Are there any settings like those in sky130 and Open PDKs?

@User (@User) I don't fully understand your point with the seed, as far as i know the .option seed=... just initializes the start sequence of the pseudorandom number generator. However whenever a gauss() / agauss() function is present in model parameters it gets another number from the pseudorandom sequence, and this happen even if no seed is changed between one call and the next call. From my experience when doing mismatch or montecarlo sims i want to change the seed if by coincidence the set of (pseudo)random values are not exploring the whole parameter space, (expecially if due to circuit size the number of runs most be kept low). That said, a fixed seed (.option seed=<n>) is good to have a reproducible mismatch/MC simulation. Example, you run such a sim, see some weird behavior, but you didn't save the voltages you want to inspect, so you need to run another identical sim with those voltages saved, with the same set of random values.

Initially, I thought that the MC results were not changing was the seed fault, not that the random numbers were not being update in less than one second. I wanted to force the simulation to change its random parameters by using another seed. In the end, I just didn't know how the seed worked at all.