Difference between internal and external simulation

I tried to simulate some OP-AMPs using the models provided by LT or AD. However, most times I failed with KICAD. To be on the save side I rebuild ngspice according to the tutorial (Version 34+) and used it with KICAD 5.1.10.

For curiosity I did this example: the device AD797 is running properly in internal as well as in external simulation (dc v2 0 7 100m). The ADA4896 fails in internal simulation but runs well in external simulation.

External simulation means: generation of a spice netlist with internal netlist generator, sourcing the file in ngspice and run the dc-analysis. Except for the command for the dc analysis and the save commands in internal spice-netlist the generated spice netlist for external simulation is identical.

For ngspice the compatibility setting in .spiceinit is
“set ngbehavior=ltpsaki”

I checked the proper starting of ngspice for internal simulation, the .spiceinit file is read, but is not effective.
When loading the netlist generated by KICAD the first message in ngspice is:
“Compatibility modes selected: ps lt ki a”
This message is missing in internal KICAD log.
It seems, that the compatibility is reset by KICAD!!!

Why is there this silly behaviour? How can I run all simulations from within KICAD?

All tutorials are failing for this by now.

I can’t duplicate your issue. Where is the .spiceinit file located on your system?

It is in my home directory.
I’m running on Linux (5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux)

/home
or
/home/[username]

?

Did you build both external (standard) and the internal (shared library) ngspice?

This seems to be impossible: Either it is read and effective, or it is not read at all. How did you check that it has been read?

As far as I see Eeschema in 5.1 has no notion of .spiceinit and ngbehavior.

Please explain! What tutorial? What should be improved?

Simulation of ADA4896 is o.k. with ngspice-34+, but fails with ngspice-34.

I kinda didn’t want to jump ahead to all that yet, but if we’re going all in I think it’s a good idea he does a quick check of his KiCad ngspice shared library.

@HOH Can you add a text block onto your schematic with the following information?

.control
version
.endc

Then you should get this little blurb in your simulation log when you run it:

Build with:

…/configure --with-x --enable-xspice --disable-debug --enable-cider --with-readline=yes --enable-openmp --enable-adms --prefix=/usr --with-ngshared CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"

strace:
2872 access(".spiceinit", F_OK) = 0
2872 stat(".spiceinit", {st_mode=S_IFREG|0664, st_size=23, …}) = 0
2872 openat(AT_FDCWD, “.spiceinit”, O_RDONLY) = 17
2872 fstat(17, {st_mode=S_IFREG|0664, st_size=23, …}) = 0
2872 read(17, “set ngbehavior=ltpsaki\n”, 4096) = 23
2872 read(17, “”, 4096) = 0
2872 close(17)
.spiceinit have been read.

My feedback (at the end of the log, after the simulation)


** ngspice-30 : Circuit level simulation program
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Please get your ngspice manual from http://ngspice.sourceforge.net/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
** Creation Date: Wed Feb 27 13:04:52 UTC 2019


This implies that an old library was referred.

This is the configure I would like to suggest:

…/configure --with-ngshared --enable-xspice --enable-cider --enable-openmp --disable-debug --prefix=/usr CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"

–with-x is definitely wrong, --with-readline is unnecessary, if not dangerous, --enable-adms is very special and needs some more preparation. Are you shure that any build was made?

–prefix=/usr for shure depends on where the KiCad package manager has put libngspice.so.

ngspice-30 may read .spiceinit, but it does not understand ngbehavior.

1 Like

Thank you for your suggestions, but the configuration stetting is coming from some tutorials. First of all it looks not to be the critical item.

The main issue is the location of the libngspice.

I’m running Ubuntu 20.04 with the Kicad ppa. This is providing kicad 5.1.10.
Within this LTS-Version the ngspice V31 is provided. When installing kicad, the dependency is resolved and this ngspice version is loaded.
Here the libngspice is located in “/usr/lib/x86_64-linux-gnu”.

Now I did a manual update for the ngspice by downloading and compiling the latest version from git. This gives me ngspice v34+.
Here the libngspice is located in “/usr/lib”.

So two different libraries in two different folders is first of all no critical issue. The problem is arising by the search algorithm in KICAD:
"
27471 openat(AT_FDCWD, “/lib/x86_64-linux-gnu/libngspice.so.0.0.0”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
27471 openat(AT_FDCWD, “/usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
27471 openat(AT_FDCWD, “/lib/libngspice.so.0.0.0”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
27471 openat(AT_FDCWD, “/usr/lib/libngspice.so.0.0.0”, O_RDONLY|O_CLOEXEC) = 17"

The x86-folders are searched first, finding the “old” library. the newer one is completely ignored. I cannot remove the old ngspice-version since kicad depends on it or I have to completely remove kicad.

There are two workarounds for this issue:

  1. remove the libngspice in the x86-folder

or

  1. do an adapted configuration:
    …/configure --with-x --enable-xspice --disable-debug --enable-cider --with-readline=yes --enable-openmp --enable-adms --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --with-ngshared CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"

This would be the best approach for my linux distribution, the correct location for the libdir can be checked with “whereis libngspice”. The directory path shall be put in the configuraition command above. I have tried both, both are working.

By the way, --with-x and --with-readline=yes are explicitely given in the install instructions for linux for version 34+ (see “INSTALL”).

Thanks for your suggestions, it helped to get on the track. This topic can be closed as resolved.

However, will there be someone in charge to update the available tutorials?

Well, I did write the “INSTALL”, so there might be some update required.

Please give a link to the tutorials you are talking about.

1 Like

The most relevant information (including the config-parameters) are coming from here:

http://ngspice.sourceforge.net/ngspice-eeschema.html

Even if it is written there, that you should download and install the newest ngspice, it is not generally working. I would recommend a short note about the importance to replace/overwrite the old versions of the ngspice library.

Other references are more or less outdated.

I’m still confused on what happened here. KiCad 5.1.10 is supposed to ship with ngspice-34. At least mine did, but I’m using Windows. Is there a Linux-specific thing here that I’m not understanding?

Windows is just the system which remains after you prepared your computer, a change of the OS is hardly manageable. Therefore all programs needs to be updated regularly. To my knowledge for far windos has not such a strict dependency management like linux. That means, you can mix programs much easier.
Linux is coming every half year with a major release, bringing some new features and by the way the latest (stable) releases of popular software. For the latest release I believe ngspice V34 will be delivered (I didn’t check).
Even if the upgrade procedure is well established in the meantime, it takes one or two hours to do this, facing some new programs and user interfaces and sometimes significant features.
However, if you are not willing to to this such often you have the possibility to use LST (long term stable) versions of Linux. For me I use one based on the ubuntu archives. There the initial versions of the software are maintained but rarely upgraded. Since these long term versions are maintained up to five years, you can work up to five years in a well known environment until you should upgrade for security reasons.
If you want an earlier update of any program within this LTS branch, you can take it from a PPA (providing precompiled archives with the latest program versions, like I do it for kicad) or you need to compile it by yourself (like for ngspice). And here the trouble begins …

Are you trying to say that…

the ngspice shared library that ships with KiCad for Windows remains isolated at \Program Files\KiCad\bin\libngspice-0.dll

but on KiCad for Linux the ngspice shared library gets installed to some other global folder where other software(s) can subsequently access it and/or can update it and/or can recompile it, etc. ?


If that’s the case, then I think I understand what happened. If not, then I’m totally lost and don’t know how to help people resolve this in the future if it comes up again.

I would not declare this as being too difficult.

The KiCad package of any Linux distribution is made by the package manager for that specific distribution. There seem to be some ‘master’ packages like Debian or Arch Linux, and there may be some differences in the various packages.

First of all I would talk about 64 bit only.

The shared ngspice API has been stable, so interchanging ngspice versions does not create problems.

Then, if you have installed KiCad for whatever Linux distribution, and you want to do an ngspice upgrade, you have to check for the locations of libngspice.so.0.0.0 (the simulator as a shared library) and ngspice/analog cm etc. (the folder with the code models) as supplied by the original installation. Any upgrade has to replace both (the lib and the ngspice folder) at exactly that same location. Always both have to to be up- (or down-)graded at the same time.

So next I would rename the original settings, to be able to revert everything in case of … (e.g. libngspice.so.0.0.0 --> libngspice_orig.so.0.0.0, ngspice --> ngspice_orig). Then one has to copy the new lib libngspice.so.0.0.0 and the new folder ngspice/analog.cm etc to exactly the same place, and that’s it.

For example with my openSUSE Leap 15.3, after KiCad 5.1.10 installation with Yast (SUSE package manager) from the Electronics repository I have /usr/lib64/libngspice.so.0.0.0 and /usr/lib64/ngspice/analog.cm.

When I do an extra install or compile ngspice without prefix, it may go to /usr/local/lib64. Then I have to copy.

When I compile shared ngspice with
../configure --with-ngshared --enable-xspice --enable-cider --enable-openmp --disable-debug --prefix=/usr CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"
then lib and code models will be it the right place immediately (due to --prefix=/usr).

Attached you will find my standard compile script for shared ngspice under Linux.compile_linux_shared.sh (3.4 KB)

1 Like

Nearly correct. I don’t know what is in the windows package for kicad. For me who I use the PPA, only all relevant files for the KICAD suite are provided (I crosschecked the PPA: NGSPICE-KICAD is available for Ubuntu 14.4, 16.4, 18.4 but not 20.4, my LTS version). For the installation the packetmanager sees a dependency for ngspice and tries to resolve it. So with the PPA you install the latest KICAD and the packet manager looks for a solution for the ngspice. Now this solution is dependent on the linux distribution you are using, here you can have all possible revisions in the field (like for me: V31).

1 Like

You are using SUSE, I’m using Mint (Ubuntu based) You can see the faint little differences between these packages.
You are stating default library path as “/usr/local/lib64”, configure is giving me “/usr/local/lib” as default.
For you the path of the library is /usr/lib64" as default path, for Ubuntu packet manager it is “/usr/lib/x64_86_linux_gnu”. I got it at “/usr/lib” without setting the libdir statement when compiling the ngspice package.
So as I said, if you don’t want to copy, you need to tune prefix and most likely also the libdir entry.

Ah, OK. So it sounds to me that if I know that a fresh Windows install of KiCad 5.1.10 ships with ngspice-34, I cannot translate that assumption to Linux because it’s dependent on whoever prepared the specific Linux package for that distro. Therefore, when troubleshooting missing features I should always first ask Linux users to check their version using the .control block discussed above.