Hello,
I switched to an Analog Devices ADA4522 quad opamp for my integrator circuit (small part of my biasing project), and tried comparing the NGSpice simulation results with that of LTSpice on my Windows PC. Unfortunately, the two output voltage results differ by about 0.6V, and I don’t know which simulation software to believe at this point. Result screenshots and my KiCad project are attached.
Note that the LTSpice output from U2 is about 2 mV, whereas the NGSpice output from the same opamp section (out_B) is much greater, 2.4 V. This doesn’t seem right, given that NGSpice reports that the B section inverting and noninverting imputs are at 3.38268 V and 3.38267 V, only 10 uV difference. I can only assume that my LTSpice software uses functionally the same model file for each opamp section as the model file I downloaded for KiCad NGSpice from the Analog Devices website.
Might you please have any insight on this?
Thank you very much!
It would be more user friendly if you drew your KiCad quad op amp so it looked more like the LTSpice version with four op amp units. I detect one error.
In the KiCad schematic I see D inputs 12 and 13 (+ and - inputs) connected together. This is not correct. The amplifier output will swing according to the amplifier’s input offset voltage.
This is not the way to connect an amplifier unit which is not being used. Connect it as a follower of some voltage…probably the power supply midpoint.
Most likely this is not the cause of your problems but it is possible.
Thanks for the D inputs suggestion, fixed it but no behavioral change. Agree that the ADA4522 symbol I received from the Analog Devices website makes it difficult to understand the wiring, sorry about that. I should mention that the purpose of this circuit is for the output to follow the input voltage, but limited to a slow ramped correction instead of an immediate response.
I’m trying to focus all my efforts on why opamp section B is misbehaving, ignoring sections A and C (D is not used). Please refer to the comment I’ve attached to one of the circuit wires (circuit screenshot attached). First note that, except for the small current through 1 Meg ohm resistor R4, OUT_B is essentially driving a load (R5, R6, R7 and R8) that sits close to ground, primarily due to a connection to section A opamp that is buffering a 108 mV input bias. I’m only interested in the DC operating point, so ignore R9 and capacitor C1.
Next, note that the voltage at +IN_B comes from opamp section C output, which happens to sit at +3.38V. If that wire is broken and +IN_B sees a fixed +3.38V supply instead, it should not “see” the difference. However when I actually broke that wire and ran the simulation with +IN_B tied to +3.38V, OUT_B dropped to about 850 uV, a small value along the lines of what LTSpice simulated with the original circuit.
I think we’re onto some kind of circuit error here, but I’m not able to resolve it. I hope these thoughts help, and appreciate the forum’s time spent troubleshooting this.
Why not just simplify your circuit first by using ONE opamp using a generic model (and symbol with 3 or 5 pins) first and once you understand that you can gradually introduce another and so on. What makes the ADA4522 different from a standard opamp such as a 741/TL081 etc?
Thank you for the suggestion. I actually started this integrator/ramp circuit using a different opamp, the LMC6484. The simulation ran ok, but the output voltage was much lower than with the ADA4522. I had picked the LMC6484 early on due to other problems (possibly due to my inexperience) with the ADA4522, but the latter is actually what was used by the author of the original circuit (from Electronic Design News) so that is why I’m trying the ADA4522 again.
Because I anticipated difficulties getting the SPICE files to work in my overall project, I simulated each active component in ngSpice individually as I mentioned previously (just applying fixed voltages to the device inputs), but that has turned out to not be as reliable as trying to get the simulation to run in my actual project.
Unfortunately, I’ve run into a new problem, a 4V precision reference (REF198) that worked fine during individual simulation shows no output when I ran the simulation to completion with my overall project. In view of the multiple problems I’m now encountering, I’m now forced to try a new approach to KiCad, at least temporarily. I’m going to try out the LTSpice environment for my overall project simulation instead of NGSpice, while continuing to use KiCad for schematic capture and PCB layout. I’ve no complaints about any of the helpful contributors who have responded promptly during my struggles in the last couple of weeks, I just want to see if the LTSpice environment is a better fit for me given my inexperience.
I know that all of you have invested considerable time with me, and I appreciate that.
Best regards,
Oliver
As much as I love KiCad or FOSS in general , LTSpice is really just “better” than ngspice. Yes that’s heavily opinionated and people can hate me for that but really, it’s no coincidence that LTSpice got more or less a standard in a lot of industries. It’s fast to use as a user and has a nice solver. And best is the fast way to modify / create plots by drag and drop and associated shortcuts. I can draw and simulate a simple circuits in seconds , not minutes. Mike Engelhard demonstrated a lot of comparisons of LTSpice and competitors some years ago that were impressive.
Just QSpice can beat it at the moment which is Mike’s latest achievement. I would never simulate in any ECAD (as another “wrapper” to a simulator ) If i have LTSpice at hand.
That depends on how you weigh your factors. For me, FOSS, integration in to KiCad and running natively on Linux are mayor factors. ngSpice has some convergence problems, does not come with many models pre installed, and it can not work with encrypted models. The solver in ngSpice may also well be less sophisticated or slower, but for me personally, those are all secondary factors.
I had to look up the “Mike Engelhardt” name. One of the first was a youtube vid with the title: Exclusive Interview with Mike Engelhardt the Creator of LTspice and now QSPICE I’m sure he’s a smart guy, but and interview with him is also likely to be (strongly?) biased.
But mine is too. If you don’t feel too strongly about FOSS and integration into KiCad, then there are quite a few other SPICE simulators that you can choose from. But I don’t know much about them.
It certainly is easier to get started with many of the other simulators. ngSpice forces you to dive a bit deeper in how it works, where to get models, maybe make small modifications (i.e. use a single opamp model for a quad opamp IC), and this does make the learning curve steeper and longer. But it’s still a quite capable simulator and once you’ve learned to work with it (and setup your own libraries) the integration in KiCad remains a bonus. (Even though simulations are most often from only separate parts of whole schematics).
yes , Qspice is another level. mixed signal simulation, you can “co”-simulate Verilog and C++, just to name a few.
I like FOSS but what I even like more are tools that help in getting a job done efficiently. And really, in a world of virtual machines, what’s the problem. You may hate MS, but just for LTspice and QSpice i would install Windows instead of learning 7 other tools that somehow together with a lot of reading may achieve the same thing. In my world, this is a waste of worthful life time.
But we should stop here as we have left the original topic =)
I found this discussion on ngspice vs Spice vs QSpice very interesting and a bit eye opening, as was the KiCon 2025 video of Dr. Engelhardt’s presentation.
Having only recently used KiCAD 8’s ngspice simulator for a simple (at least what I thought as simple) simulation to test the Bode plot curve of a Sallen Key LPF in a differential, balanced input, TL084 op amp circuit (using only one (pins 1,2 3, 4 and 11) of the 4 op amps in the schematic) I got different results depending on which op amp model I used, the ngspice default op amp or TI’s TL084 model. And neither results agreed with the Laplace Transform analysis.
Thanks for bringing this “disagreement” to light and the responses for caveats that may need to be paid attention to.
