ngspice in the documentation

[holvo]

Fabrice,

I have two questions about ngspice appearance in the PySpice documentation:

Chapt. 5.1
The main drawback of Ngspice is to inherit the old C code base of Berkeley SPICE.
Why do you consider this a drawback? For the users? For ngspice performance? Or for some other reason?

Chapt. 1.21
Ngspice is not compliant with industrial quality assurance processes.
What is the reason for this statement? Can we improve here?
Consider the ngspice use in commercial products (Eagle, WeSpice, CoolCAD ..., see http://ngspice.sourceforge.net/resources.html )

Regards

Holger

ngspice maintainer

[FabriceSalvaire]

Hi Holger,

I have to admit it's a serious topic and I am not an expert in circuit simulation. Honestly, it would be better to arguments them with feedback from professional users and circuit simulation experts. By the way I never discussed about this with peoples around my. I should do it !

As a software project manager, I feel more comfortable with the C++ code of Xyce, it's extensive unit tests and maybe it's state of art numerical algorithms. Despite it's military origin ...

Up to know, the users of PySpice seems to be students. I use it personally for DIY applications. Thus I didn't have any feedback from "serious users".

[eps82]

Hello, just some opinions from a ngspice user.

I've been using it professionally although as a "side tool" and always validating the results with commercial simulators, and at least for moderately simple circuits the results have been satisfactory. My main use is evaluation of low-complexity MOS structures (mirrors, series transistors, isolated...). I cannot comment on its numerical stability for really large circuits though (realistically, the netlists of analog IC blocks can easily go into thousands of lines, and in any case I cannot rely on its results either).

In my opinion the vast advantage of ngspice over professional tools is its DLL. Launching simulations from Python (or whichever language; I used Matlab before) allows a type of dynamic tuning that isn't possible from commercial software with such ease. Handling of output data directly from Python is also much easier than with SKILL or AEL. Another problem is even though other simulators can be scripted they suffer from overhead if you need to relaunch them; as a DLL this isn't the case, and when doing thousands if not millions of runs this difference can be massive.

I do think it'd be very useful if ngspice came with its own test benches. For example in DC it is possible to generate random netlists replacing known voltages and currents with components with the same static resistance; same with impedances. Transient analysis is more complex but one can at least produce structures with variables spanning several orders of magnitude programmatically to compare its convergence with other simulators. I'm not an expert in numerical algorithms but it could be done in a rigorous way to at least compare it side by side with other tools (analysis aside, generic spice netlists are compatible in most cases).

By the way, a couple weeks ago I uploaded the wrapper I mentioned in another thread https://github.com/eps82/lyngspice As I explained there were quite a few things I didn't need from PySpice (I wanted full control on the inputs and outputs with my own netlister) so I went for a simpler approach. One thing I added was a method to reload the DLL to prevent memory leaks (which unfortunately are a thing); if you find it useful you could include something like that in PySpice too.

[FabriceSalvaire]

always validating the results with commercial simulators It's why FOSS simulators are problematic, since we can expect commercial simulators have been fixed over the time thanks to the feedback of their users. Just compare the number of users of ltspice, despite it's windows NT look !

I think also FOSS alternatives can be interesting when we need scripting.

Unload/reload the library should not be necessary, else it means ngspice is buggy !!! But I am afraid to encounter such issues, it's why I preferred to run ngspice in server mode.

Since few years, many people are uploading wrapper on Github, always based on ctypes, and thus reinventing the wheel ! I understand some peoples like to work with spice netlists. So I improved the situation and I believe now PySpice is nearly usable as just a wrapper, maybe the documentation must be improved. I will look in your code when I will have some time.

[eps82]

(apologies in advance if I'm now derailing a bit!)

Unload/reload the library should not be necessary, else it means ngspice is buggy !!!

No question about it, but in the meantime it's a simple workaround, and using it like this is still the fastest option.

Since few years, many people are uploading wrapper on Github, always based on ctypes, and thus reinventing the wheel* !

Thing is there isn't much to reinvent at all; any ctypes wrapper for such a simple interface will look the same. cffi may give you some shortcuts for some definitions, but nothing you can't just copy&paste. The only trivial difference is how to pack the output data, and then of course whether you're interested in building something on top of it or not (not my case, so the whole thing is ~300 lines).

I understand some peoples like to work with spice netlists.

I see two problems with using functions to instantiate components (which is why I don't). The first one is there's very little gain coding other than cosmetically, and even that is arguable for unit definitions. For example compare for

'R1 A B 50k'

using the function

instantiate_resistor('1', 'A', 'B', 50@u_kOhm)

with simple string formatting

'R%s %s %s %s' % ('1', 'A', 'B', '50k') # or even just %e' % (..., 50e3)

Using a function or class method is marginally clearer and if for some reason the user needs to use raw spice lines anyway they'll have to get acquainted with both input methods. It may be convenient to keep an abstraction layer when there are several simulators to choose from, when one can manipulate networks before instantiating them (not the case -yet?-), or in a broader context as part of a CAD GUI where objects have electrical, graphical or even mechanical properties, but when writing custom netlists as in my case it just adds unnecessary complexity.

But it's not just a matter of preference. The other problem is it must support all components to be usable, which is in general the drawback of front-ends that also applies to wrapping output data. It's great if it does what you need, but it's a showstopper if it doesn't.

So I improved the situation and I believe now PySpice is nearly usable as just a wrapper,

That's what I did at first; I just modified it to enable the use of raw spice code and stored all outputs in a dictionary (instead of just voltages and currents). But once I did that, I realised I didn't need everything else, so I just kept it simple.

A high level library has some obvious advantages, but if it doesn't add anything you need there's no point in the overhead, and a limited implementation can be counterproductive. To me it's very clear there's a need for both approaches, and it would be great if one was built on top of the other, but that's currently not the case for PySpice so a different implementation is needed in quite a few cases.

Which isn't to say PySpice's goal isn't worth pursuing by itself!

*edit: One thing I forgot to mention is the license. There are legitimate reasons for going for all sorts of licenses, but GPL3 forces users to go in one particular direction which not everyone wants (myself included).