Re: Wanted: LM-709 (Spice model) National Op-Amp



"analog" <analog@xxxxxxxx> schrieb im Newsbeitrag
news:4336F7DD.A26C9ADC@xxxxxxxxxxx
>
> Helmut Sennewald wrote:
> > Paul Rako wrote:
>
> >> The one complaint I heard tonight at Bldg T was that you can't
> >> export the LTspice/SwitcherCAD III work to something that can
> >> layout a circuit board. Based on the other buncombe, some of
> >> which I may have inadvertently spouted, I will try it first and
> >> see.
>
> Usually a design's simulation is segmented by functionality rather
> than by circuit board boundaries and includes many simulation
> specific elements not needed or wanted on a layout oriented
> schematic. On the other hand, a circuit board layout needs things
> like connectors, test points, unused gates and gate associations,
> mounting holes, etc. Also, component secondary parameters required
> for a board layout are completely different than for a simulation.
>
> I really don't see the point of wanting or requiring a simulation
> schematic to be board layout capable.

Hello analog,

I can really second that. The more professional layout programs
allow a lot of control from the schematic. There are so many
properties on nets and components which you never get from another
schematic entry program. And finally postprocessing beyond layout
may be completely impossible without some special properties.

Btw, PSPICE has become harder to use since Cadence switched
to the ORCAD schematic interface which is intended for PCB designs.
This is ok for PCBs but you will need more time to make a
schematic for SPICE.

> ...

> > I will then try on this circuit with LTspice and give my
> > judgement. I think we should let the professionals do it who
> > know LTspice. It's like if you have to judge about a Porsche
> > car. If you have never driven it, you shouldn't judge it.
>
> Helmut, what's a mild mannered family man like you doing driving a
> Porsche!?? :) But your observation is well taken so I'll have to
> disqualify myself from judging sports cars, at least.

I have no Porsche, but when I think on LTspice I always think
LTSpice is the Porsche of the SPICE simulators.
It's very fast and precisely to control.
It requires a little bit practice and learning of course to
get this advantage.

I had posted a few days ago my tips about solving convergence
problems into the LTspice-Yahoo-group.

--- start
It's difficult to give a general help. I would try with the
following.

1. Set a useful maximum time step in the ".tran" line.
Try with some values.
Use/keep a maximum timestep regardless whether it still fails.

Most of the following settings are in the Control Panel.

Control Panel -> SPICE

If still not ok:
2. Try wth the Alternate solver

If srill not ok:
3. Back to Normal solver
Try with method: Gear

If still not ok:
4. Back to default settings.
Try with "startup" in the .TRAN setting .

If still not ok:
5. Back to default settings.
Try with Gmin, but not lower than 1e-10

Still not ok:
6. Back to default settings.
Try with Reltol=0.01

Still not ok:
7. Back to default settings.
Try with a combination of 6 and 7

Still not ok:
8. Back to default settings.
Try with .options Tseed=maxtimestep/10

Still not ok:
9. Have the components real values? Add a series resistor in the
capacitor(ESR) or inductor.

Still not ok:
10. Try with .ic and .nodeset

Still not ok:
11. Let try other people. :)

Don't under estimate hint 11.
--- end

"analog", I will add your tips to the FAQ in the LTspice-Yahoo group.

Best regards,
Helmut


> Here are my "driving tips" for LTspice:
>
> Because of the differing strategies used to handle them, convergence
> issues are best sorted into those relating to finding the initial dc
> operating point and those occurring during a transient run.
>
> At the dc operating point and with ideal elements, inductors become
> shorts and capacitors become opens, whereas just the opposite occurs
> with step-size compression during transient troubles. In one case,
> delta time goes to infinity, whereas in the other, it approaches
> zero. For transient convergence, spice depends on the fact that
> realistically modeled nonlinear elements should approach finite,
> linear, time invariant impedances as step size gets really small.
>
> LTspice has improved models for inductors and capacitors that allow
> realistic parasitics to be entered and computed as an integral part
> of the element. This prevents the corresponding branch admittances
> from going to zero or infinity for reduced time steps during a
> transient analysis, greatly improving run time convergence. Also,
> as I understand it, inductances (and voltage source) with series
> resistance are more computationally efficient, because they can
> then be directly "plugged" into the admittance matrix. Another
> benefit of specifying realistic parasitic resistances is that it
> avoids situations where unrealistic high frequency oscillations
> drive the time step to a crawl (not really a convergence issue).
>
> Bearing this in mind, LTspice transient convergence "fixes"/
> (standard good practice) in order of "goodness", im my opinion,
> are:
>
> 1) Specify series and parallel resistance parameters for capacitors
> and inductors.
> 2) Use the current source version of elements whenever possible.
> Note that specifying a series resistance for voltage sources
> actually changes them into current sources internally. For
> example, rather than behavioral voltage sources, use current
> sources in parallel with a small capacitor (1nF or less) edited
> to have a 1 ohm shunt resistance.
> 3) Make sure that all semiconductor junctions (and other nonlinear
> elements) are modeled with realistic series resistances and
> junction capacitances as well. The importance and effect of
> something seemingly so mundane as this cannot be overemphasized,
> for this is what forces linear behavior during time step
> compression.
> 4) Use LTspice's built-in alternate solver for three plus decades
> more numerical dynamic range (at a 2x speed penalty).
> 5) Use the Gear integration method to numerically dampen out "noise"
> that should better be taken care of by step 1).
> 6) Add .options Tseed=<maxtimestep>/10 (thanks Helmut)
> 7) Increase "reltol" above the default .001 (going higher than about
> .03 may be counter productive).
>
> Solving Operating Point Convergence Problems
>
> In addition to most of the steps above:
>
> Examine your simulation circuit for behavioral sources or other
> devices that may go highly nonlinear as the sources are stepped up
> from zero. Splitting a very nonlinear element into several pieces
> across several nodes can sometimes dilute the problem behavior to
> the point where the solver no longer gets hung up on one very bad
> element. In such cases, adding more nodes can actually make the
> simulation run much faster.
>
> If not already available somewhere in the circuit, a unity node may
> be created by setting up an isolated dc voltage source equal to one
> volt. Clearly, any expression may be multiplied by the voltage on
> this node as many times as needed without changing the value of the
> expression during an analysis. The only effect on such an expres-
> sion occurs during source stepping while seeking the operating
> point. Then, as this unity node is reduced to near zero, anything
> multiplied by it is also forced to approach zero.
>
> Bear in mind that unity node multiplication can be sprinkled
> throughout a simulation wherever you suspect misbehavior.
> Differencing circuits with a lot of dc and gain are always good
> candidates as are abrupt limiters and behavioral expressions with
> node voltages in their denominators such that when the sources go
> to zero, the expressions blow up (something gone small / something
> gone to zero => infinity). These types of expressions can be
> multiplied by the unity node raised to whatever power required to
> make them behave.
>
> Regards -- analog

.