Hi,
Could anyone suggest a good reference for performing monte carlo analysis? Why do we go for it?

Also i read that prior to monte carlo analysis it is mandatory to perform DC, AC an transient analysis. Is it so?
If it is why so??

Thanks for reading... any suggestions??

This is not true in Spectre. The monte carlo analysis only requires that you run an analysis within it, otherwise what would the point of the monte carlo be. There is a parameter to the monte carlo "donominal" which is by default set to "yes". This will first do a nominal run, verifying that your sub-analyses are correct, export statements are correct, etc.

Regards,
 John

Hi Pravinkumar,

I am not aware of a good reference on Monte Carlo simulation - possibly some of the early Pspice manuals may be of help to you.

As a "newbie" it may be a better question to ask: "why do you need to do a monte carlo simulation?"

- to give a brief answer from my perspective (a "spicer" of some 20 years experience with tools such as spectre, hspice, eldo, winspice3, pspice, Cohesion, LTspice etc) I would guess that you do not need to do so - about 25 years ago I used a fore-runner of Pspice for pcb designs, which entailed some monte carlo simulations.  After an extensive career designing analogue and RF ASICs and not using monte carlo tchniques, I have only just this year rediscovered a need to use it and then only in a very structured way.  Let me explain:

Initially monte carlo simulation was used predominantly by pcb type simulation tools (the initially the target application for tools such as Pspice) as it was difficult to know the exact tolerance of individual components in individual batches of resistors capacitors, discrete bjts etc.  Typically to resolve tolerance issues one needed to simulate 100 or so cases with a random distribution.  This worked well for ideal representations of the components used for a design of perhaps 100 components, with perhaps 5 or 9 bins on each component (and was much better than the alternative - hand calculation with a HP32C).

To do this many monte carlo simulations on a typical ASIC design, even now would be prohibitive.  We tend to use other methods such as process case (usually referred to as something like TT, FF, SS, FS, SF for p and nmos, TT, FF, SS for resistors and so on for bjts, capacitors etc).  It does not take a great deal of thought to see that if you were to start doing random simulation runs for all these cases with each instance of each component type taking a random value, then it would take a lifetime to simulate the average ASIC.  Rather we take advantage of the fact that all (for example) resistors tend to have the same value of tolerance on one die, so we need only simulate all resistors high, low and typical.  Simularly for MOS, BJTs etc.  This reduces the task to something like 32 or 64 cases rather than what maybe many tens of thousands for an equivalent coverage monte carlo.  Typically for an "all digital" cmos design this reduction may come down to 2 or 3 critical cases.  A manageable task.

This leads me to the present - Analogue-RF ASIC cells: as speed and performance of the analogue sections of SOCs have increased, we see the "random walk" of the "mask" geometry, implant inhomogeneity effects and proximity over- or under-etch having a noticeable effect on the final tolerance of our designs.  It becomes useful in simulation to be able to skew the Length and Width as well as Threshold Voltage of critical devices within a cell design to gain an idea of its sensitivity to changes in these parameters.  Provided we can identify the critical nodes (opamp diff-pair inputs, current mirror inputs, etc) with a cell then run a monte carlo simulation which randomly sets each node to its maximum and minimum value, then monte carlo becomes a useful tool.  This "ASIC method" for using monte carlo is not to be confused with how monte carlo is run on pcb designs - there a random distribution of values is applied to each component.  For ASICS each component only takes one of three values: min, typ, max, which component (or group of components) is changed is done so at random.  It is extremely useful at the design phase to be able to identify, then choose any one of these cases (typically the worst) to be re-run as a single isolated simulation.  For ASIC designs it is really nice to be able to do this without any intervention in the circuits' netlist(s) particularly if those netlists have been extracted from a layout.

As an experienced user, I would give the warning that monte carlo sims are notoriously difficult to get to run to completion, typically due to convergence issues associated with cascode devices, "totem-pole" logic gates, high gain diff-pairs and other nodes which maybe  indeterminate at some point in the startup transient.  Judicious use of nodeset and 1e12 pull-ups and pull downs will help, but they are remedial and will only buy you an ability to simulate a relatively complex cell, not a full ASIC (yet).  You will find that TRAN sims are more stable than DC sweeps, which are more stable that OP sims.  Although there is a perception that you should do an"OP" first, this should not be necessary on the more mature and established versions of SPICE (ie spectre, hspice, eldo etc).

In summary: any multiple run simulation (including monte-carlo) is really about convergence and requires an intimate understanding of how the underlying matrix solving algorithm functions.

Just as an anecdote: two of the "best" tools in terms of convergence that I have ever used came from AT&T-Bell Labs in the early '90s: being Celerity and S-frame.  These ran under unix, relying on a homotopy convergence technique and could regularly converge 5k+ nodes reliably; something none of the "modern" tools seem yet to be able to achieve.  (Would anyone out there know what happened to them?)

Hope this helps.

I would also like to hear the opinions of other experienced asic designers on the "usefulness" of monte carlo and how they work around the convergence issues so often encountered in multiple PVT sim runs.

Cheers,
           SimonH.