Montecarlo: generate immediately all netlists

Patrik,

If using Design Management then I would generally recommend working in a separate workspace where you don't see live updates so that you're isolated from external changes. If you can't do that, you can put this in your .cdsinit to do what  you want:

envSetVal("adexl.simulation" "ignoreDesignChangesDuringRun" 'boolean t)

Note, this has to go in your .cdsinit (as it must be read by both the foreground session and the background ICRP sessions). Also, you should be aware that this defeats the benefit of netlisting in parallel which can save you time for big simulations - but at least it isolates you from changes to the design during the simulation.

We are working on a better solution for this in the future, but for now this is probably the best option (other than working in a separate DM sandbox).

Regards,

Andrew.

Hello Andrew,

thanks for the quick answer. We will try this setting.

Unfortunately, our policy is to use common views/workspaces as private ones gave us more pain than benefits (and we _hate_ our DM tool).

Also, our company's policy it that every change should be visible worldwide as quickly as possible.

From a purely theoretical point of view... I wonder why ADE-XL does not generate all netlists in parallel in the first place.

Since they are MC simulations, the only difference should be in terms of firstrun parameter, so the tool can generate the full netlist only once, copy it to all other sim directories and change that parameter.

Or... am I missing something?

Thank you and best regards,

Patrik

Hello Andrew,

thanks for the quick answer. We will try this setting.

Unfortunately, our policy is to use common views/workspaces as private ones gave us more pain than benefits (and we _hate_ our DM tool).

Also, our company's policy it that every change should be visible worldwide as quickly as possible.

From a purely theoretical point of view... I wonder why ADE-XL does not generate all netlists in parallel in the first place.

Since they are MC simulations, the only difference should be in terms of firstrun parameter, so the tool can generate the full netlist only once, copy it to all other sim directories and change that parameter.

Or... am I missing something?

Thank you and best regards,

Patrik

Patrick,

In the simple case you describe, then it's obvious that it ought to generate the netlist first and re-use it for subsequent points. However, if you generalise and say have 50 tests, each with different test benches, and only run (say) 5 parallel jobs, then it normally runs the (incremental) netlister as each simulation job starts. Because it's incremental, normally that doesn't cost very much if you've netlisted it before - but it does have this unfortunate side effect. Similarly if you use the parameterisation capability, that requires each point in the sweep to be renetlisted after the callbacks have been run.

So put another way, it's a consequence of trying to deal with the "big" problem whereas many cases could be netlisted more optimally - we just need to build in better smarts to ensure that it can avoid re-netlisting unnecessarily without there being a big serial overhead at the beginning.

Anyway, good news is that we're working on this - but for now you have to use this workaround as a stop gap if you have this issue where the design could change during a large number of simulations.

Regards,

Andrew.

Ok, understood.

Many thanks

When you use the command envSetVal("adexl.simulation" "ignoreDesignChangesDuringRun" 'boolean t) that Andrew mentioned, the netlist is indeed generated only once and is then added to all input.scs files with an include statement (and symbolic links in the file system). However, if you are using features like parameter sweep (as opposed to variable sweep) or config sweep, this option will be disabled automatically and netlists will again be generated just before the corresponding simulation starts. I also don't see why it should not be possible to generate all netlists before the first simulation starts even in those cases.

Frank,

It's an efficiency tradeoff and this was an option that was retrofitted later; ultimately we want to do this differently so that you simply don't have to set any magic environment variable such that it works in all cases.

Andrew.