moraes@csri.toronto.EDU.UUCP (04/15/87)
Russ Foster (foster@huey.udel.edu) raises what must be an old and well- known SPICE problem. To get SPICE to converge on some circuits seems to require the services of your friendly neighbourhood warlock 8-) Some tricks which seem to work (sometimes!) are: 1. Try SPICE2F.1! Analog circits like op-amps often refuse to work with the 2G or 3 family. But they do work on 2F.1. Question: What is the difference in the F and G versions? Are the results of 2F inaccurate? They LOOK ok. 2. For DC convergence, raise the temperature, or re-arrange the nodes numbers so that SPICE sets its internal matrices up differently. This is suggested in "The Design and Analysis of VLSI Circuits" by Glasser and Dobberpuhl. I've found it sometimes works, presumably because the raised temperature lowers the gain of the circuit, which is something else suggested in the book. There is a neat Appendix on "Spice Techniques" in it. 3. Try changing TRTOL to a larger number, which sometimes works, or VNTOL. Oddly enough, changing ABSTOL from 1 picoamp to 1 nanoamp seems to cause SPICE to die faster! 4. If you're into simulation and FORTRAN, try hacking around in dctran.f which is where the Internal Timestep Too Small error originates. But be prepared for a big task! Question: At a really small timestep, like 1e-15 secs, a CMOS circuit shold be doing absolutely nothing (well, except for a few electrons here or there!) Even for a stiff problem, SPICE shold not complain too much at this time-step. After all, the trapezoidal method is A-stable and guarantees not to blow up even for relatively large time-steps. So why can't SPICE just go ahead with a warning message? 5. Either strip off the really small capacitors (anything less than 100ff is usually redundant) which circuit extractors tend to tag on to internal nodes, by setting a threhold or something. Those "stiffen" the problem, and probably cause SPICE to lower the time-step. Alternatively, increase them with some sort of fudge value. If you're into dynamic circuits, the latter course may produce spurious charge sharing, if the internal caps start getting near the order of the output node caps. And the former course may cause you to miss some charge sharing, if for example you have an output node of 0.05pF and you knock off a 0.01pF cap on a connected internal node. Proceed with caution. I'd be interested to know how the problem is really solved, and if anyone knows precisely why this happens. As far as I know, one plays around with any or all of the above till SPICE accepts the circuit. Does anyone have a source code fix? Any SPICE gurus out there know an answer? How about a collection of SPICE techniques? Anyway, that's my two cents worth. Hope it helps. Mark Moraes. (moraes@csri.toronto.edu, moraes@utcsri.uucp)
greenberg@decsim.DEC.COM.UUCP (04/15/87)
> What is the difference in the F and G versions? For analog MOS circuits, the difference is a change in the implementation of the Ward capacitance model. The matrix techniques in the G versions should be more robust than in the F versions. >3. Try changing TRTOL to a larger number This would cause SPICE to take larger time steps. I think the only reason why this would work is that it is a random shift that gets SPICE away from the particular model glitch that is causing problems. >Question: At a really small timestep, like 1e-15 secs, a CMOS circuit >shold be doing absolutely nothing (well, except for a few electrons >here or there!) Even for a stiff problem, SPICE shold not complain too >much at this time-step. After all, the trapezoidal method is A-stable >and guarantees not to blow up even for relatively large time-steps. So >why can't SPICE just go ahead with a warning message? A glitch in the current versus voltage equation of a model causes tremendous problems which only get worse as the time step gets smaller. A glitch is a constant delta V no matter how small the delta t, so the current gets huge. This behavior is contrary to the expected error behavior of the numerical methods where the error of Newton-Raphson and the error of the integration formulae get smaller with smaller time-step. Even if you stay away from the Ward capacitance model and use the Meyer model you are going to run into problems. There is a potential glitch problem around VDS=0. >How about a collection of SPICE techniques? Fix the model bugs is my recommendation. This may not be too practical a recommendation because these types of bugs are very hard to find. Barring that, all the recommendations that have been made so far are probably reasonable ways to mask the problem. /Steve
nje@philabs.UUCP (Norman J. Elias) (04/16/87)
You will also encounter convergence problems if the input driving signal changes too rapidly, for example a PULSE input with rise-time less than the stepsize specified in the .tran statement. What happens is that SPICE steps over the pulse edge and encounters an apparent discontinuity in the input signal. The SPICE time-step reduction algorithm merely jumps the time-point back and forth around the discontinuity and the algorithm never converges. Try checking your input signal specifications and see if the rise-time is consistent with the time-steps and circuit time constants. A more gradual rise or fall will correct some convergence problems.
klein%gravity@Sun.COM (Mike Klein) (04/17/87)
In article <6654@philabs.UUCP> nje@philabs.UUCP (Norman J. Elias) writes: > >You will also encounter convergence problems if the input driving signal >changes too rapidly, for example a PULSE input with rise-time less than >the stepsize specified in the .tran statement. What happens is that SPICE >steps over the pulse edge and encounters an apparent discontinuity in the >input signal. The SPICE time-step reduction algorithm merely jumps the >time-point back and forth around the discontinuity and the algorithm never >converges. Seems to be a common misconception... the time step given on the .TRAN line has nothing to do with the internal time steps that SPICE takes. It only governs the print and plot increments on transient output. The fast rise time causing SPICE to scale back its time step that Norman mentions is something that occurs commonly in most simulations, and the algorithm is designed to (ideally) handle it just fine. If for any reason the Newton-Raphson iterations at a chosen time point don't converge in an acceptable number of iterations, the time step is scaled back, and the Newton-Raphson iterations start again at that time point. The simulator will keep scaling back the time step until either it achieves convergence or the time step has shrunk below a certain number. This number is defaulted to something pretty small (typically about 10e-14 or 10e-15 seconds), and may be overridden by some parameters on some versions on SPICE (I forget the magical incantations, but numerous articles on this subject have explained how to do this). It is unusual, although it does happen, that a fast-rising but realistic input waveform alone forces SPICE into nonconvergence. You would need a signal that has a rise time of, say, 10e-13 seconds. Note that after each convergence at a time point, the integration algorithm does a check to see whether its estimate of the local truncation error (LTE), due to the approximation inherent in the numerical integration method used, is acceptable. If the LTE is very low, the simulator will increase its step size. Thus it is almost certain that after the circuit has settled, and the simulator is taking big time steps with low LTEs, that the next change in input stimulus will cause it to scale back its time steps many times until it finally converges. -- Mike Klein klein@sun.{arpa,com} Sun Microsystems, Inc. {ucbvax,hplabs,ihnp4,seismo}!sun!klein Mountain View, CA