Hello All, I hope ya’ll are having a nice day. I am working on a simple miss match Monte Carlo simulation on an inverter, but it isn’t working correctly; all of the runs are identical. I’ve read a bunch of previous posts (including one from @Stefan Schippers that mentions it might be broken) and I am not sure what I’m doing wrong. Does anyone have any ideas? I would appreciate any help or thoughts. Thanks a lot!

Try

.option SEED=random

.

@Tim Edwards thanks for the quick reply. I have that on line 33

Sorry, missed that. At a glance, it looks right to me.

@Tim Edwards No worries 🙂. I’m glad it isn’t obvious, but I’m quite puzzled. I even checked the value of

mc_mm_switch

parameter after loading the libraries to make sure nothing in there set it a different value using `csparam`and it is still 1.

I think the problem is just one of understanding how the mismatch computations are done. They are computed as the netlist is read in. If you run the above netlist through ngspice multiple times, you get different results between each run. Within the program, though, inside a loop, you get the same devices with the same parameters, which don't get calculated again.

Ah, Interesting!

The only solution that I know of is to take data from multiple ngspice runs and aggregate data in another application like octave or python/numpy. There might be a better solution that I don't know about.

@Tim Edwards That makes sense now. After reading the ngspice example and an example from bminch on youtube more closely, I noticed now the

reset

command (https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/Monte_Carlo/MC_ring.sp#l49 and ). I think that’s the key, but now I’m running into an issue where reset (and

mc_source

) are loosing net names in the circuit. You’ve helped a lot. Thank you. I may just write a python script.

you need to add a

reset

instruction after run = run + 1

@Stefan Schippers thank you so much! That's perfect!

@Holger Vogt: Can I please implore you to change

src/frontend/inp.c

lines 434 to 442 from

/* option seed=random [seed='random'] */
            if (eq(token, "random") || eq(token, "{random}")) {
                time_t acttime = time(NULL);
                /* get random value from time in seconds since 1.1.1970 */
                int rseed = (int)(acttime - 1600000000);
                cp_vset("rndseed", CP_NUM, &rseed);
                com_sseed(NULL);
                has_seed = TRUE;
            }

to

/* option seed=random [seed='random'] */
            if (eq(token, "random") || eq(token, "{random}")) {
                struct timeval tv;
                gettimeofday(&tv, NULL);
                /* get random value from current timestamp microseconds */
                int rseed = (int)(tv.tv_usec);
                cp_vset("rndseed", CP_NUM, &rseed);
                com_sseed(NULL);
                has_seed = TRUE;
            }

? Using

.option SEED=random

has the unfortunate property of asserting a new random value based on

time()

every time

reset

is called or every time the program is run (even overriding the use of

setseed

within a control block), and using

time()

to generate the seed has the very unfortunate property of returning a value in seconds which is a long, long time on a computer. If I am trying to do a mismatch analysis on a simple circuit using a

DC

analysis, then it can end up running 30 or 40 analyses with the exact same random seed. There are really multiple issues here: (1)

.option SEED

should not be able to override `setseed`; and (2) random seeds should be based on microseconds or even CPU clock tick counts. If you want to be pedantic and avoid the case where an analysis takes exactly one second, then I would suppose that

int rseed = (int)(<http://tv.tv|tv.tv>_usec) + (int)random();

would be a reasonable solution.

Thanks for the patch. I will have a look.

@Holger Vogt: Does Windows support

clock_gettime()

? That would be even better because it uses

struct timespec

with field

tv_nsec

for a timestamp in nanoseconds.