mark@mips.UUCP (04/11/87)
In message <8704090953.a008691@Huey.UDEL.EDU>, Foster@UDEL.EDU (Russ Foster) writes: > I have been attempting to run some simulations of some dynamic > CMOS circuits using SPICE2G6 and encountered some problems with > the numerical integration time step...... > .... This is very dependent on the sampling time and the clock period. > > The error I get in the output file is "INTERNAL TIME STEP TO SMALL". > I am using a LEVEL 2 MOS model, with parameters obtained from MOSIS. > At this point I really have no idea what to do. If anyone out there > has some insight to my problem, it would be much appreciated. ========================================================================== I believe you have the answer, embedded in your question. In our experience with Berlekey Spice and its product-ized commercial bretheren, "TRANSIENT TIMESTEP TOO SMALL" errors are *usually* caused by the choice of printing (not internal analysis, printing) timestep on the .tran "card". The problem basically goes away if you set the printing-timestep to be smaller than about 1/10th of the **fastest** RC timeconstaant at any node in the circuit. To give an example, our "2 micron CMOS" inverters have a risetime of about 2 nsec at high voltage & low temperature, so we specify .tran 0.2ns 40ns (i.e. a printing timestep of 0.2ns) to avoid TIMESTEP TOO SMALL. Beware, you have to estimate the **fastest** RC timeconstant. This gets ugly when you're simulating a distributed RC line (long poly run?) with a lumped model of several fast pieces. Another nasty case is a series-stack of transistors - the intermediate nodes between the transistors are very low capacitance (especially if you forget to include the source/drain diode!). So, why does the external printing-timestep affect the internal calculation-timestep? I don't know for certain, so I'll guess ... It its zeal to use tha biggest possible timestep (thus the smallest number of iterations), Spice occasionally uses one that's too big on, say, iteration j. It "oversteps" the beginning of a waveform edge. Then on iteration j+1 Spice notices a large error, so it halves the timestep and tries again. It heeps halving the timestep for iteration j+1 and keeps getting an unacceptably large error - finally bobming the run. Problem is, the timestep used back in iteration j was the culprit but Spice doesn't realize that. The external printing-timestep sets an upper bound for how *big* Spice lets itself set the internal timestep, so you can protect Spice from itself by using a suitably small external-printing timestep. Course, that's only a theory. This little bit of voodoo seems to work pretty well for us. It does, of course, increase the run time and the size of the output file. Hoping this helps, -- -Mark Johnson DISCLAIMER: The opinions above are personal. UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark TEL: 408-720-1700 x208 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086