As mentioned in the title I use LTspice as my main workflow to simulate circuits. One of my circuits is using an OPA656 amplifier. I attach a picture of a simple schematic I made to test the issue. It is a simple voltage follower. However, attempting to simulate this yields an error. also seen on the picture enter image description here

I also have checked the log output. which shows the following warnings and errors

ERROR: Node U1:I0:I21:1:102 is floating and connected to current source G:U1:I0:I21:1:RA

ERROR: Node U1:I0:I19:1:102 is floating and connected to current source G:U1:I0:I19:1:RA

ERROR: Node U1:I0:I19:1:302 is floating and connected to current source G:U1:I0:I19:1:RC

Now. Reading the .cir model I found what I thought might be the issue. A current source defined on lines 762,808,850 and 818 (GRA and GRC) which connect to a capacitor at nodes 102 and 302.

Nevertheless, I downloaded the Spice model this time for Tina-TI and downloaded the program, just to test since it seemed weird to me that the simulation would just fail like that.

Once testing the testbench provided by TI on Tina I saw that DC, Transient and AC simulations work without issues

Testbench circuit used by Tina

Picture showing the simulation results

I've also tried to simulate the testbench circuit on LTspice. It does show the same errors. This time however it does not interrupt the transient simulation. However, the results are also incorrect

Atempting to simulate the testbench on LTspice also yields no useful results

I would appreciate any help with this issue. I thought that the spice models of the components were able to be read by all simulators. Is there a compatibility option I need to activate on LTspice? Is it perhaps a problem with the inner workings of the simulator?

Any help is appreciated

  • \$\begingroup\$ Please link the data sheet for the op-amp. \$\endgroup\$
    – Andy aka
    Commented Apr 10 at 18:12
  • \$\begingroup\$ I added a Hyperlink at the beginning of the question \$\endgroup\$
    – Victor
    Commented Apr 10 at 18:40
  • \$\begingroup\$ I think you now need to embed the model details that causes the fault. There may be pins numbers that need correcting. \$\endgroup\$
    – Andy aka
    Commented Apr 10 at 18:58
  • \$\begingroup\$ Lines 40 thru 48 in the PSpice model show the connections to the model. Did you follow the correct pin order numbering in your symbol? \$\endgroup\$
    – qrk
    Commented Apr 10 at 20:28
  • 2
    \$\begingroup\$ On top of VVTs answer below, after fixing that, please test both normal and alternate solver in LTspice and see if you see any difference. \$\endgroup\$
    – winny
    Commented Apr 11 at 12:07

1 Answer 1


It may happen that the simulation, with specific excitation signals or in specific opamp configurations, gives incorrect or at least not quite exact results with both simulators, PSpice and LTspice. Of course, the PSpice simulations with OPA656 cover multiple use cases, but it is the result of great effort put into parameter selection with extensive testing, and therefore the random (but still technically legal) test may accidentally fail.

Mike Engelhardt's presentation in SPICE Differentiation article is rather convincing. Still, Berkley SPICE's code is open source, while LTspice is proprietary software. It is impossible and maybe not required to enumerate all the software features in documentation. If you follow the guidelines of Analog Devices/Texas Instruments, most often you would not have problems when running simulations for their respective products with recommended simulators, but you cannot expect to receive trustworthy results when simulating unconventional circuits. However, when you are in doubt and you are running Berkley SPICE, you have a source code as the last resort; when you use LTspice, you can only guess and ask forums.

Indeed, examining the source code is the last resort; typically, you simplify the circuit you are developing and estimate your simulation results with the help of manual calculations of maybe even common sense.

For example, with the intention to understand LTspice's modified trap implementation, I'm running the simulation:


and seek an explanation of "time step too small, ... trouble with node 'pivot'".

First idea: the constraint of behavioral source B1 V=uramp(Vp**2-V(osc1)**2-V(osc2)**2)/Vp) is to blame, because function uramp zeroes negative values of the expression. But here, the trouble starts when V(pivot) is safely nonzero positive, ca. 4.5V. Decreasing the time step down to 1ps, still no luck (in finding culprit). Noticing that the smooth behavior is broken only when the osc1/2 voltages are approaching each other at their respective minima, I decide to shift waveforms by slightly changing C2 capacitance, to 1.001n. The pesky "time step too small" survives this modification, but the waveform behavior noticeably changes:


Zooming in the waveform, I see the parabolic crests and troughs in the waveforms:


The solver has encountered instability, radically decreases the timestep, and these wandering steps are leaked into the waveform. Some of these intermittent iterations show negative V(pivot) values! Strange things may happen when the node value becomes negative, although the voltage source B1 that is connected to this node presumably generates only non-negative voltage. Maybe it's time for me to learn about tripdv/tripdt parameters.

Another approach is to follow Mike Engelhardt's advice and avoid not only discontinuities, but require a continuous first derivative in constraints, like that:


Here, I eliminated uramp entirely; however, it might be of interest to iron out the transition to zero in the earlier expression for constraint and see if this solves the "time step too small" problem.

LTspice's modified trap is said to use implicit integration. With implicit integration, no additional regularization is required. On the other hand, Gear's method is to reduce the DAE system to the form suitable for explicit integration, see C. W. Gear Towards Explicit Methods For DAES in http://www.princeton.edu/~wgear/ExplicitDAE.pdf.

To explain his method, Gear uses the example with mechanical pendulum. In electrical networks, Kirchhoff current laws give rise to algebraic relationships; but these are trivial constraints. To see real problems generated by constraints, non-linear expressions are required, as in the above circuit with the behavioral voltage source. A more typical arrangement for electrical networks would include VCCS, as the FET transistor models use VCCSs:


In mathematical parlance, the constraint I=(Vp**2-V(osc1)**2-V(osc2)**2)/Vp/R is non-holonomic: it contains both voltages (which play the role of mechanical coordinates in electromechanical analogy) and currents (which play the role of mechanical velocities). Double check my words, but, as non-holonomic constraints give rise to index 2 DAEs, these, meseems, are less exacting w.r.t. regularization requirement.

C. W. Gear is quite restrained as regards using his technique for calculations of electrical networks (page 3, a paragraph right above heading 3. Regularization and Damping).

  • \$\begingroup\$ Thanks for the help. However, I can't quite get the correct results. When attempting to simulate the comparator testbench as seen in Tina I do not get anywhere close to the results I should see. Only the alternate simulator yields a result and the normal simulator returns an error stating that the timestep is too small and also reporting an error on node e:u1:i0:i30:i11:0#branch. I will also start reading the wiki to try and learn as much as possible \$\endgroup\$
    – Victor
    Commented Apr 11 at 13:49
  • 1
    \$\begingroup\$ @Victor After using V.V.T's fixes, I tried all the tricks in my bag but can't get this subcircuit to work properly in LTspice. I can get the simulation to run but the results don't match your TINA-TI results. Unfortunately, this is quite common when trying to use TI's models in LTspice. They write very complicated netlists and only test them in PSpice (which is more forgiving with bad syntax). They'll test them in TINA too, and then if it works they'll republish the same LIB file as a TINA model (as done with the OPA656). \$\endgroup\$
    – Ste Kulov
    Commented Apr 11 at 21:38
  • 1
    \$\begingroup\$ @Victor I have to decrease the square-wave frequency by a factor of 4 to get a proper waveform. The last observation I have is that I can't even get the AC response to match. This AC response at least explains the transient response with the 100Meg square-wave. I still think something is "up" with this model and suggest maybe trying to use UniversalOpamp2 as shown here: electronics.stackexchange.com/a/613637 \$\endgroup\$
    – Ste Kulov
    Commented Apr 11 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.