Ltspice is a big dissapointment !

[Nominal Animal]

Speed, numerical stability and accuracy as well as convergence are much more important for a pro than GUI issues.

Have you actually compared LTspice and ngspice performance, or this based on the old "because LTspice is the market leader, it must be better than the competitors" fallacy?

(While I am only a hobbyist in electronics, I've worked on simulators and HPC quite a lot, more on the development side than on the end user side.)

[shapirus]

Have you actually compared LTspice and ngspice performance, or this based on the old "because LTspice is the market leader, it must be better than the competitors" fallacy?

I have. LTSpice was much, like several times at least, faster than ngspice. This is only anecdotal evidence, though, so take it with a grain of salt. Proper testing would require setting all simulation parameters to the same values (because defaults may differ), making sure the models are as close as possible, etc.

Ngspice can be very fast, too. Just relax the tolerances, and in practice they can be relaxed quite significantly, almost to the levels that seem unreasonable, and it'll still deliver correct simulation results, only maybe somewhat less precise in some situations, or it may show some artifacts that can be ignored, once you know they aren't real.

[Nominal Animal]

LTSpice was much, like several times at least, faster than ngspice.

Now that does not surprise me, as ngspice uses a single thread per simulation.  It was the numerical stability, accuracy, and convergence claim that surprised me and made me suspicious.

That said, in addition to being single-threaded only, it is not a drop-in replacement LTspice nor meant to be one.  However, being supported in Altium Designer, Eagle, DipTrace, and other commercial software is an indicator that at least some professionals do use it already.

Anyway, this kind of brand loyalty is exactly why I nowadays shirk away from professional software development: to do it properly, one must invest more in marketing and branding than the development itself.

[mawyatt]

Sorry but this is BS. Take Electro Magnetic simulators - they employ much more complex science but also have decent UI and plotting capabilities.

Sorry but this is BS, models used in EM simulations are nowhere near as complex or involved as some semiconductor models utilized in Spice and its' various derivatives. It can take many man-years to develop a single semiconductor transistor model with sufficient fidelity to bet a complex and expensive IC design on. If you doubt this just take a look at the much older Mextram, HiCum, PSP (Pen State Phillips) BSIM 6 models just to name a few general purpose ones utilized in IC design.

Take note of the parameters involved, and image what the proprietary models that are utilized in SOTA semiconductor design today (@ 3nm), considering that modern SOTA semiconductor designs involve EM simulations within the overall framework of the semiconductor device itself, so the EM simulations are a small subset of a much more involved and complex structure which is dealing with atomic level details as well as macro level device details.

Best,

[Wolfgang]

LTSpice was much, like several times at least, faster than ngspice.

Now that does not surprise me, as ngspice uses a single thread per simulation.  It was the numerical stability, accuracy, and convergence claim that surprised me and made me suspicious.

That said, in addition to being single-threaded only, it is not a drop-in replacement LTspice nor meant to be one.  However, being supported in Altium Designer, Eagle, DipTrace, and other commercial software is an indicator that at least some professionals do use it already.

Anyway, this kind of brand loyalty is exactly why I nowadays shirk away from professional software development: to do it properly, one must invest more in marketing and branding than the development itself.

There are some YT videos where Engelhard explains why and how LtSpice has superior math compared to other Spices.

[Wolfgang]

Sorry but this is BS. Take Electro Magnetic simulators - they employ much more complex science but also have decent UI and plotting capabilities.

Sorry but this is BS, models used in EM simulations are nowhere near as complex or involved as some semiconductor models utilized in Spice and its' various derivatives. It can take many man-years to develop a single semiconductor transistor model with sufficient fidelity to bet a complex and expensive IC design on. If you doubt this just take a look at the much older Mextram, HiCum, PSP (Pen State Phillips) BSIM 6 models just to name a few general purpose ones utilized in IC design.

Take note of the parameters involved, and image what the proprietary models that are utilized in SOTA semiconductor design today (@ 3nm), considering that modern SOTA semiconductor designs involve EM simulations within the overall framework of the semiconductor device itself, so the EM simulations are a small subset of a much more involved and complex structure which is dealing with atomic level details as well as macro level device details.

Best,

The problem with complicated device models covering almost all areas of operating conditions is the extraction of the a lot of parameters from measurements. This is an absolute orgy of a huge data collection and curvefitting effort. In the end, you have a super model valid just for the part you measured. When you look at the strays of, e.g., transistor beta between devices this raises the general questions about the benefit of "overparametrized" models that only work for a single specific device. What you rather want is a robust design that can work with devices within datasheet value ranges. 

[shapirus]

That said, in addition to being single-threaded only, it is not a drop-in replacement LTspice nor meant to be one.

Well, once you make your product public, it starts to live a bit of its own life :).

Naturally, people (or at least myself!) will want it to be as capable as possible regardless of its original goals: fast, well-converging, accurate, and supporting as many models of varying syntax as possible. In other words, be well suited for real life applications. Currently it's far from ideal in that regard, especially out of the box with default settings, but it's being actively developed, so hopefully it'll become a much more mature tool eventually, especially considering the Kicad's native integration.

[PlainName]

Sorry but this is BS. Take Electro Magnetic simulators - they employ much more complex science but also have decent UI and plotting capabilities.

Sorry but this is BS, models used in EM simulations are nowhere near as complex or involved as some semiconductor models utilized in Spice and its' various derivatives. It can take many man-years to develop a single semiconductor transistor model with sufficient fidelity to bet a complex and expensive IC design on. If you doubt this just take a look at the much older Mextram, HiCum, PSP (Pen State Phillips) BSIM 6 models just to name a few general purpose ones utilized in IC design.

Perhaps this is the problem: the workings of the model isn't separated from the interface to it?

AFAIK, the model complexity has zero to do with the GUI. All that does it let you place things here, change stuff there, join this to that. Shouldn't the models be backend black boxes? The complexity of their internals should be a non-issue in relation to what key does copy, how the schematic is zoomed, making the text always be upright when a symbol is rotated, etc.

[mawyatt]

The problem with complicated device models covering almost all areas of operating conditions is the extraction of the a lot of parameters from measurements. This is an absolute orgy of a huge data collection and curvefitting effort. In the end, you have a super model valid just for the part you measured. When you look at the strays of, e.g., transistor beta between devices this raises the general questions about the benefit of "overparametrized" models that only work for a single specific device. What you rather want is a robust design that can work with devices within datasheet value ranges.

The later part of our career was involved with SOTA IC design and processes, and believe me there's lots more to a modern SOTA device model at the IC level that just curve fitting a bunch of data. Most modern process models are highly semiconductor physics based, some completely, and some employ physics based and "curve fitted" data behavioral type models.

Over 2 decades ago we were working with very complex models in SOTA SiGe BiCMOS processes which included proximity and local neighbor effects, these effects were not limited to just electrical/fields, but included sophisticated multiple time constant thermal effects (BTW we started doing time domain thermal effects in Spice in the 80s!!). If you've ever been involved with detailed simulator behavior (we had to design our own simulators way back in the beginning silicon RFIC era as nothing was available at that time), you'll appreciate the enormous computational burden these models impose. However you'll happily pay that price as you may have a $20M SOTA IC design that's totally influenced by those very models and the folks that developed them

IC design mistakes, changes, mods, rewires, updates, tweaks and so on requiring a "respin" with long delays (often 4 months or more) are quite expensive and career limiting the IC design world, and one is almost totally dependent on these very models for a successful chip design and career!!

Lots more than just "curve fitting" a bunch of data is required for SOTA modern semiconductor models

Best,
 

[mawyatt]

Sorry but this is BS. Take Electro Magnetic simulators - they employ much more complex science but also have decent UI and plotting capabilities.

Sorry but this is BS, models used in EM simulations are nowhere near as complex or involved as some semiconductor models utilized in Spice and its' various derivatives. It can take many man-years to develop a single semiconductor transistor model with sufficient fidelity to bet a complex and expensive IC design on. If you doubt this just take a look at the much older Mextram, HiCum, PSP (Pen State Phillips) BSIM 6 models just to name a few general purpose ones utilized in IC design.

Perhaps this is the problem: the workings of the model isn't separated from the interface to it?

AFAIK, the model complexity has zero to do with the GUI. All that does it let you place things here, change stuff there, join this to that. Shouldn't the models be backend black boxes? The complexity of their internals should be a non-issue in relation to what key does copy, how the schematic is zoomed, making the text always be upright when a symbol is rotated, etc.

We weren't disputing the GUI interface but the statement about EM simulation complexity, and why we highlighted such.

Agree the GUI is totally disconnected from the simulation engine and models. However, treating a complex semiconductor model as a "blackbox" is risky, as most seasoned IC designers are quite knowledgable and often involved with the model development and behavior.

One must realize that the models aren't prefect representations of the device, and simulations often mislead or "lie" about the results and require a competent designer to recognize such. Recall cases where we discovered a non-realistic beta (over 1100) in a SiGe bipolar device under certain operating conditions, or the discontinuity in the second derivative of channel conductance with channel current direction change in the popular BSIM CMOS model, or a violation of charge conservation in another CMOS model.

Also, as semiconductor model complexity grows, so do the non-convergence events and simulation hang ups. Having "inside" information on the models involved can help alleviate such and/or create work arounds!!

Best,

[Nominal Animal]

Perhaps this is the problem: the workings of the model isn't separated from the interface to it?

Yes, I believe so.

Unfortunately, that choice itself is a huge divide in the software world.  We have the integrated framework approach, and we have the modular minimalism approach.  Even talking about this I risk starting a flamewar.

(Don't mistake my choice of mascot as an ideology or zealotry.  I've worked with both proprietary and open source code, and signing NDAs has never been a problem for me.  What I do trust, is the test of time and use cases, rather than the opinion of some "authority", though.)

AFAIK, the model complexity has zero to do with the GUI.

Exactly.

If the user interface was separated from the actual simulator, other schematic capture programs could use it as a simulator, and different user interfaces for the same simulator to support different workflows.

There are some YT videos where Engelhard explains why and how LtSpice has superior math compared to other Spices.

Mike Engelhardt is the author of LTspice, and the only one with access to its sources.  I'm very hesitant to believe any authors word as to why their solution is superior, if I cannot verify it for myself.

This is not a slight on Engelhardt, mind you.  I apply the same, strictly, to my own solutions and even examples and suggestions.  I never just claim something; I always show how to verify the claim for yourself.

Agree the GUI is totally disconnected from the simulation engine and models.

Except in the case of LTspice, where they are inseparable, even though we have the exact information that the simulation engine needs.

The practical result of this is that LTspice only runs on Windows (7-10) and MacOS (10.15+) on x86 and x86-64, and has a single user interface.


This sidetrack started because I mentioned I've seriously considered writing my own (portable) schematic capture and symbol editor on top of ngspice.
To make it worthwhile, I'd need to do what I usually do when designing a serious user interface, and examine the actual work flow of both professionals and hobbyists.  That way, I can make it efficient.  I'm pretty good at that, actually; I typically end up significantly speeding up users' workflows.
The problem in this is that many professionals, for some reason, completely drop interest when they find out it would use ngspice instead of ltspice, and I cannot understand why.  I know ltspice is a faster simulator, but nothing I've seen indicates it is more precise, numerically stable, or otherwise more reliable than ngspice.  Just faster.

There already exist a number of user interfaces to do this.  KiCad 7 and later are the most accessible (as in, both free, and available for most operating systems and architectures), but there are quite a few others.

Thus, in a very real sense, it is very, very much about the user interface, and not really about the simulator engine itself at all (except that because of Mike's choices, we cannot use LTspice's engine only; we either use the engine and its UI, or not at all).

From practical experience, the user interface affects your workflow efficiency more than you think or feel.  When you use a specific interface long enough, it does become muscle memory and thus both fast and with low cognitive load, but before that, you end up wasting a lot of time and effort before you get there.  (Plus, it is said that a human can get used to and comfortable with anything at all, possibly excepting an icicle up their butt, because that will melt before you get used to it.)

For example, there is no good technical reason why simulation results are not shown as the simulation progresses, why running a simulation should preclude other work on the schematic or symbols, or why you couldn't run several simulations (with the same or different schematics) in parallel.  (KiCad 7 + ngspice precludes all those; I'm not sure about LTspice on native Windows/MacOS.)
It all depends only on the UI, and exactly how the UI is connected to the simulation engine.

And my point is, we fundamentally could do better with what we already have, except users are not interested in helping to find out what that "better" would be.  It seems the more professional you are, the more intent you are in hoping for an Authority like Mike Engelhardt tells you what that is.

[mawyatt]

The history of Spice is interesting. Larry Nagel at Berkeley developed SPICE in 1973, and recall Berkeley licensed SPICE to all folks for $25. Many folks took this license and started all the various SPICE flavors back then, these were all text based "net-lists".

Microsim PSPICE was one of these folks and later developed a Schematic Capture interface to the core SPICE engine. Cadence appeared much later and developed their versions with much improved convergence and speed. Recall their ability to "spot" tiny circuit nuances, where traditional SPICEs would completely overlook such and the skip by these in TD simulations. Because of the superior SPICE performance linked with good IC layout tools Cadence became the popular design tool for most IC designers, even tho quite expensive.

Best,   

[Nominal Animal]

Yep, the original SPICE was open source.  ngspice itself originates from SPICE3f5 (written in C).

As I am a hobbyist on the electronics side, ngspice is the only SPICE I've really used, but I've also used QUCS and QUCS-S.  I don't currently have any licenses to run Windows or Mac OS (on hardware or virtually), and while Wine exists, it is far from perfect, so I don't want to form any opinions based on running LTspice, PSPICE, TINA-TI etc. on top of Wine.

The list of no-cost electronics circuit simulators is very interesting.

I was surprised to find that Sandia National Laboratories' xyce is also no-cost and open source, and even SPICE-compatible.  Surprisingly, very few posts here mention Xyce at all, and it is obviously (and publicly) developed for Sandia Labs' internal use (with the GPL'd version not including any national-proprietary bits), so I wonder if any professional members have used it for circuit simulation.  Perhaps it is my background showing, but I really like how its mathematical basis is explicitly documented.  Parallel processing requires OpenMPI making it better suited for distributing simulations (for example, in a HPC cluster) than utilizing multiple cores in the same desktop processor, though.

[mike449]

I don't currently have any licenses to run Windows or Mac OS (on hardware or virtually), and while Wine exists, it is far from perfect, so I don't want to form any opinions based on running LTspice, PSPICE, TINA-TI etc. on top of Wine.

From my experience, LTSpice runs faster under Wine than on native Windows. The difference in the installation time is especially dramatic. This is most likely because of the Windows antivirus snooping on all activity.

[Zero999]

I don't currently have any licenses to run Windows or Mac OS (on hardware or virtually), and while Wine exists, it is far from perfect, so I don't want to form any opinions based on running LTspice, PSPICE, TINA-TI etc. on top of Wine.

From my experience, LTSpice runs faster under Wine than on native Windows. The difference in the installation time is especially dramatic. This is most likely because of the Windows antivirus snooping on all activity.

I don't see why that should be the case. I find LTSpice running under WINE much slower for file operations, compared to Windows. It takes a long time to change from one directory, to another in the file selection box.

Regarding the GUI: most electronic design and simulation software have quirky, non-standard GUIs. I find LTSpice's reasonable, but I can see why some people struggle with it.

[mawyatt]

Recall in the 80s and 90s lots of shenanigans going on with the various flavors of SPICE.

HSPICE showing improved sim times compared to others, only to find that they had reduced the default convergence parameters in HSPICE to achieve quicker but less accurate convergence!!

Or DR SPICE showing improved sim times by partitioned the circuit into sections and each section assigned a separate SPICE engine and linking the sections together, only to find that the circuit they used for comparisons was DRAM which is highly repeatable sub-circuits which lends itself to this type of partitioning, most conventional circuits don't!!

Another SPICE flavor which partitioned the circuit and ran the different sections at different Time Rates and then attempted to "Stitch" the section together at longer Time Increments. This kinda worked on some circuits if the partitioning could be setup correctly, for example a high speed section would be simulated with smaller time steps than the lower speed sections like the Power Supply. However, this required careful assisting and tweaking from a knowledgable user for proper partitioning and often multiple trial/error attempts to make things work, and often was more effort/time than just running a traditional SPICE simulation and waiting for the result.

Lots of various versions of SPICE back then, which just compounded the situation and made things difficult for most users.

Reason we were so involved was we were in the middle of writing our own simulator specifically tailored for Silicon RFIC design based upon the core SPICE engine, but that's another story.

Best, 

[joeqsmith]

I've never used SPICE for anything outside of basic building block circuit design.   That part about Integrated Circuit Emphasis, is wasted on me.    My introduction was on a VAX.  Our output graphs were made using ASCII characters. 

I'm not a big user of LtSPICE as it's missing some features I tend to use.  When MicroCap was made available for free, I started to use it.   My history of SPICE:

[RoGeorge]

Agree the GUI is totally disconnected from the simulation engine and models.

Except in the case of LTspice, where they are inseparable, even though we have the exact information that the simulation engine needs.

The practical result of this is that LTspice only runs on Windows (7-10) and MacOS (10.15+) on x86 and x86-64, and has a single user interface.

Not sure what you mean by inseparable, LTspice can run a SPICE text-file netlists, no need for a GUI at all, plus there are a few libs already to call LTspice or to read the results from another program (first 2 search results):
https://groups.io/g/LTspice/topic/how_to_simulate_spice_netlist/58954862
https://electronics.stackexchange.com/questions/496593/using-python-to-simulate-an-ltspice-netlist
Also, I remember at least one funny use case, in which LTspice was called from another program, so to simulate analog electronic circuits, which analog circuits (their topology) were generated based on randomness + genetic algorithms.  And there was at least one unusual circuit resulted from that, which was verified in practice. 

About LTspice being for Windows/Mac only, for me LTspice always ran just fine on Linux.  It installs and runs out of the box, no WINE tuning required.

[Nominal Animal]

Correction to my claim above: it is possible to use only the simulation engine of LTspice.

I just found out that even LTspice can be used in batch mode without a GUI.  This means it is possible for example a Python 3 + Qt 5 graphical user interface to use ngspice or ltspice or xyce or other circuit simulators with a command-line interface for the actual simulation.  (While the LTspice compressed output format is not officially disclosed, it seems that it is already known and relatively stable, as a Python module already exists.  One can always use ASCII output format anyway.)

I think this changes a few things for me personally.  Time to setup a virtual machine with most recent Wine, LTspice, ngspice, et cetera, and do some experiments.

Not sure what you mean by inseparable

We posted at practically the same time.  I only now found out that LTspice batch mode does not invoke the interactive GUI.  It does need the related libraries et cetera, but it will not create any actual visible windows, which means it can (at least technically) be used as a simulation backend.

[iMo]

..
Also, I remember at least one funny use case, in which LTspice was called from another program, so to simulate analog electronic circuits, which analog circuits (their topology) were generated based on randomness + genetic algorithms.  And there was at least one unusual circuit resulted from that, which was verified in practice.  ..

So, you may now integrate the LTspice with the ChatGPT results, automate the KiCAD to draw the pcb out of the LTspice schematics, then automatically send the pcb files to China and just wait on the populated ready to run board.. 

[RoGeorge]

graphical user interface to use ngspice or ltspice or xyce or other circuit simulators

For the potential project of a new GUI (no matter the engine), I remember a nice feature from LabVIEW:  the picture of a drawing (.png ) was also containing the schematic, embedded in some picture descriptor tag, don't recall the details.  The effect was that one could drag&drop a schematic picture from any webpage, and run the "picture" locally into LabVIEW.  It was an impressive gimmick when I've first found out that was possible at all, to "run a picture". 

LTspice can plot "live" during simulation, though this is not of much use since most of the time the simulation completes almost instantly.  As for longer 1+ minutes simulation, live plot is not that great, because it slows down computation (long simulations implies millions of datapoints crammed into a small plot of a thousand or so pixels width.

Sure, tons of improvements can be added to LTspice (or to any other GUY), for example one feature that I almost implemented once in LTspice (unintended) was to add live "Slider", but then I've discovered QucsStudio already has sliders, and used that instead of my Python + matplotlib sliders cobbling.  The "live" sliders feature is absolutly great to have (particularly when learning), but is only works if the simulation is fast enough to finish in less than a second (the slider drag event starts a new simulation + plot update).

This is a 1 minute video with a slider (in QucsStudio, a slider is attached to the coupling factor, and another to a capacitor, then the effect of changing K or C can be seen "live" upon the two coupled oscillators, the resonance of the other circuit is affected/pushed by dragging the respective sliders): 


Might be common knowledge, but to me, seeing the line splitting (live) was one of those "aha!" moments, with deep implications  (way outside of the electronics area).  My point is, live interacting with the values in a schematic can be a very powerful feature, LTspice/ngspice/etc. can have this feature, too, such sliders are a GUI feature.