Ngspice-28 for KiCad

holger · June 2, 2018, 5:07pm

ngspice-28 is available. Inportant new features are:
A generic VDMOS model for power MOS devices has been added. Simulating devices as provided by http://ltwiki.org/index.php?title=Standard.mos is now possible.

Ngspice-28 reads PSPICE device libs. These are often provided by the semiconductor device manufacturers for design support. Internally ngspice translates the PSPICE syntax to ngspice before simulating. No more manual tweaking of the library description is required (hopefully).

How to make use of ngspice-28 in KiCad (instead of ngspice-27 delivered with the nightly)?

If you are on MS Windows, do the following:
Install a KiCad nightly from http://downloads.kicad.org/windows/nightly/
Download the ngspice dll in ngspice-28_dll_64.zip from https://sourceforge.net/projects/ngspice/files/ng-spice-rework/28/ .
Copy msys-ngspice-0.dll from folder Spice64_dll\dll-mingw\ of the zip file into Programs\KiCad\bin. Within the bin folder remane libngspice-0.dll to libngspice-0-orig.dll. Now rename msys-ngspice-0.dll to libngspice-0.dll.
Put a text file named .spiceinit into your user directory (C:\users<your name>). Add the three lines

* user provided init file
set ngbehavior=ps

to .spiceinit. And that’s it.

If you are using LINUX, you may need to download ngspice-28.tar.gz and compile the shared library with

./configure --with-ngshared --enable-xspice --enable-cider --enable-openmp --disable-debug CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"
make -j8
make install

Put a text file named .spiceinit into your home/username directory. In admin mode, it may be the root directory. Add the three lines as noted above to the file. I am not on Linux, so I have to guess that now everyting is o.k. . If not, it might be necessary to add a different installation path to the configure command. Please let me know!

PKTKS · June 3, 2018, 11:22am

Great news… This version is a huge improvement over the previous.

A suggestion on any *NIX station to avoid messing root or creating any other account is to use the environ as provided by SPICE itself

# the most basic ones
export SPICE_LIB_DIR=/usr/share/ngspice
export SPICE_EXEC_DIR=/usr/local/bin

# export SPICE_HOST		## default: none
# export SPICE_BUGADDR		## ngspice URI
# export SPICE_EDITOR		## dafault vi - spinit initialize this
# export SPICE_ASCIIRAWFILE	## default 0 - Format of the rawfile. 0 for binary, and 1 for ascii
# export SPICE_MFBCAP		## default $SPICE_LIB_DIR/mfbcap
# export SPICE_HELP_DIR		## default $SPICE_LIB_DIR/helpdir
# export SPICE_SCRIPTS		## default $SPICE_LIB_DIR/scripts - spinit file location

# some very interesting ones
export SPICE_PATH=$SPICE_LIB_DIR		## default $SPICE_EXEC_DIR/ngspice
export SPICE_NO_DATASEG_CHECK=true		## show proc status
export NGSPICE_MEAS_PRECISION=5			## default: 5 precision digits in measure commands
export NGSPICE_INPUT_DIR=$SPICE_LIB_DIR/models

Should work fine including a GLOBAL spinit file on the specified path

Working fine in my station

Paul

akshay · June 12, 2018, 8:38am

Can you please tell the procedure on how to merge ngspice-28 with kicad 5

PKTKS · June 12, 2018, 4:24pm

Download a proper libngspice to your system
(or compile it yourself from sources)

Put that library into a PATH available to KiCAD v5
It will be loaded as a shared library upon initialization.

The stand alone ngspice command line is also very helpful

Paul

michal777 · July 6, 2018, 5:19pm

Hi. I tried to use ngspice-28 with kicad but it’s not working.
I tried to compile ngspice and replace old: libngspice.la, libngspice.so, libngspice.so.0, libngspice.so.0.0.0 (installed as dependency of kicad from ppa) with new, from ngspice-28. In kicad I got and error: “/usr/lib/x86_64-linux-gnu/libngspice.so: undefined symbol: MIFiSize”
Please help! My os: mint 19. Kicad 5 rc3.

PKTKS · July 6, 2018, 5:28pm

It sounds likely you have a broken lib

MIF is part of xspice which in general is not enabled by default

to have MIF symbols you need to properly add the xspice
upon compilation

TRY:
–enable-xspice
–enable-cider
–disable-debug
–enable-xgraph
–with-readline=yes

That request xspice upon building

but YOU MUST also request a shared library build
–with-ngshared

hope helps
because MATCHING SYMBOLS is not a trivial task
in particular on x64 and mixed binaries and src code.

not trivial at all.
you need proper understanding of several things

Paul

PKTKS · July 6, 2018, 5:35pm

and be careful once you have compiled the correct lib
to remove any OLD left and place the new in the proper place

that is particularly important if you have a mixed x32/x64 system

Paul

michal777 · July 6, 2018, 7:37pm

Thanks! I don’t know what exactly I messed up before but I’ve made fresh build with:
…/configure --enable-xspice --enable-cider --disable-debug --enable-xgraph --with-readline=yes --with-ngshared
and now it works. The old libngspice that installs as dependency of kicad can be removed from /usr/lib/x86_64-linux-gnu and it looks like kicad is happy with the new one that goes to /usr/local/lib after make install.

holger · July 6, 2018, 8:43pm

With shared ngspice probably there is no need for xgraph (a venerable plotting tool) and readline (history for the command line interface). OpenMP will speed up some simulations (mostly for VLSI using BSIM3 or BSIM4 transistor models) by using multiple cores of the CPU.

So
./configure --enable-xspice --enable-cider --enable-openmp --disable-debug --with-ngshared
would be better.

hermit · July 6, 2018, 8:58pm

I’d caution that it may be advantageous to keep the command line stuff included. Yes this area is specific to KiCad integration but I’ve never met a GUI that was always the preferred way to go.

holger · July 6, 2018, 9:13pm

At least shared ngspice does not use readline. It does not have a command line interface, it is a shared library. I do not know if there would be any side effects if readline is compiled in. I did not test it.

PKTKS · July 7, 2018, 12:56pm

Probably no side effects.

But as a long term user of automake tools
I would keep the same profile used when building CLI
as used when building lib.so

So you have the proper automake macros do their magic tricks
upon including the headers and all required (matched) symbols

Both should be fine. So we better keep profiles (e.g. symbols)
as close as possible from both builds

it seems wiser, IMHO
Paul

holger · July 7, 2018, 2:35pm

The ngspice manual says:

32.1.5 ngspice as a shared library
With the GNU build process and the options selected:
$ ./autogen.sh
$ ./configure --with-ngshared --enable-xspice --enable-cider
–enable-openmp --disable-debug
$ make
$ sudo make install
you will get the ngspice shared library. A file ngspice.pc for pkg-config is generated.

(Well, I wrote the manual.)

Anything else is at the user’s risk.

PKTKS · July 7, 2018, 3:03pm

THIS COMMENT MAY HELP OTHER FOLKS WITH
BROKEN LIB PROBLEMS… If a simple recompilation
fails or you still have MISSING or MISMATCHED symbols

READON…

That autogen.sh part is very critical

Running autogen forces to update by libtoolize
and aclocal macros. Several systems uses rather old distros
with previous versions of libtool and automake (macros)

When you ask to “re-do” all stuff you may change things
(headers and even the libtool version used in tree)
(that will end up being part of configure)

Roughly if the tree already contains a sane start
is enough to run just autoreconf

That usually makes the best compromise between the
local version of libtool and automake macros with the
system compiler and all headers (which may be old )
including updating only necessary headers and macros
in configure

e.g. instead of doing ALL again it may be enough just
issue a forced autoreconf -f - if you have a decent populated
start tree.

Several times I had to replace libtool with an older one
by using autogen while just autoreconf would do a safer
and good local “configure”

It may help people with systems still using previous versions
of GCC and GLIB and the automake macros or using mixed
systems where the build have missing or mismatched symbols

2 cents of several issues w/this automake stuff

BTW autoreconf is a more elaborated PERL parser which
can handle a considerable amount of things when using “-f”

Paul

PKTKS · July 7, 2018, 5:49pm

@holger

Please clarify some doubts for me.

So far I have avoided to include openmp due to
compiler issues they raise on their site

Formerly they only assure that some versions are compatible
with some APIs

From GCC 4.2.0, OpenMP 2.5 is fully supported for C/C++/Fortran. 
From GCC 4.4.0, OpenMP 3.0 is fully supported for C/C++/Fortran. 
From GCC 4.7.0, OpenMP 3.1 is fully supported for C/C++/Fortran. 
In GCC 4.9.0, OpenMP 4.0 is supported for C and C++, but not Fortran. From GCC 4.9.1, OpenMP 4.0 is fully supported for C/C++/Fortran. 
From GCC 6.1, OpenMP 4.5 is fully supported for C and C++. 

Compile with -fopenmp to enable OpenMP

It looks that some old compilers are restricted
while the NEW compilers are complete non-supported
while only a range from 4.9 to 6.1 uses a recent API

So I avoided that to prevent problems

In what extent can i use that in the build?
.e.g which API x compiler version is expected to be safe

Do I need to include -fopenmp in my ENVIRON FLAGS?
or automake does that just fine ?

or even including that I will still need native updated thread safe
GLIBC to match that API…

too many things i just have no clue about…
so I have kept that option out… so far.

Any help really welcome
Paul

holger · July 8, 2018, 6:36am

What is your problem?

OpenMP is supported by gcc for many years now (and by MSVS as well).

ngspice uses OpenMP to run device equation evaluations in parallel (see manual 16.10 Ngspice on multi-core processors using OpenMP) for may years now on various compiler and OS versions.

I use for example gcc 7.3.0 on Windows.

PKTKS · July 8, 2018, 12:05pm

No problems. I have not used this option
to avoid the API restrictions as I reuse the
compiled binary in quite different systems

Even on a VIA C7 small desktop which is x86 compatible
but it is NOT the kind of multicore CPU we have from Intel and AMD.

By having a safe binary like this it works safely
and rather very fast even on the C7 CPU. Simple options
and rather old GLIBC and thread support

But I will follow your advice and try a openmp compiled
binary to see it is is portable enough from a multicore
x86 system recent GCC to a more old system with
VIA C7 CPU, a quite usable but limited environment.

I will see if it runs into any sort of problems on such CPU
Any strange thing I will drop a note here

Paul

PKTKS · July 8, 2018, 2:41pm

FOR THE RECORD

Following @holger advice I recompiled with OpenMP enabled
in a fairly recent distro with AMD 64 MULTICORE CPU
and recent GCC/GLIBC

then i packaged and installed this binary in 2 other systems

one system an embed VIA C7 CPU which is only register
compatible with 486 - it is not compatible with 586 register level
but emulates x86 perfectly
other system is a more older AMD CPU but running exclusive
in x32 space with rather stable GCC/GLIB (kinda 4.8 series)

Here are the answers for my questions:

First question is that AUTOMAKE will handle all the flags
it magically adds and exports the correct flag to CFLAGS environment
no need to mess your CFLAGS LDFLAGS ENVIRONMENT VARS
Second question is that IT REALLY relies on POSIX threads
there is no way to implement OpenMP without POSIX threads
the result is that two new bindings are REQUIRED

        libgomp.so => /lib/libgomp.so.1
        libpthread.so => /lib/libpthread.so.0

that lead to the other answers - if the system contains the proper GCC gomp library correctly binded to POSIX threads … IT RUNS PERFECTLY

a VIA C7 (or even a 486 CPU) will run openMP parallel processors emulated as POSIX threads. NATIVELY. no problems whatsoever.

Thanks @holger for you help and advice
OpenMP is now safely included in option set build

BTW WITHOUT openmp the binary IS NOT BINDED to POSIX threads it is smaller and safer but just a bit slower and independent of the compiler compiler native gomp library.

Paul

mifi · July 14, 2018, 7:48pm

FOR THE RECORD (on Linux)

I first installed the nightly binaries from the Ubuntu ppa by js-reynaud.
Then I downloaded ngspice-28.tar.gz and compiled according to the instructions by holger:

mkdir release
cd release
…/configure --with-ngshared --enable-xspice --enable-cider --enable-openmp --disable-debug CFLAGS="-m64 -O2" LDFLAGS="-m64 -s"
make -j6
sudo make install

Then I changed the pointers to libngspice from the location created by reynaud’s repo to the default installation location from the sources:

cd /usr/lib/x86_64-linux-gnu
sudo mv libngspice.so OLD.libngspice.so
sudo mv libngspice.so.0 OLD.libngspice.so.0
sudo ln -s /usr/local/lib/libngspice.so.0.0.0 libngspice.so
sudo ln -s /usr/local/lib/libngspice.so.0.0.0 libngspice.so.0

This worked on my Ubuntu-16.04 system.
I will have to see if the links are oke after an update from the repo, but I expect them to be.

EDIT: One of the links libngspice.so.0 is broken after the next update via the repo. That is a pity because the ppa is handy to update the libraries. I guess I will have to install everything myself from git, but I will postpone that a bit until I feel like it. In the mean time I will keep patching the symbolic link, I guess.

Thanks for your help holger.

m

mifi · July 15, 2018, 9:47am

By the way, to clarify exactly when the Pspice syntax is used,

set ngbehaviour=ps

in .spiceinit will result in all files read via .include will be interpreted in Pspice syntax (section 16.13.5 of the ngspice-28 manual).

Does this imply that only files that have been read via the .include are interpreted as Pspice files?
So spice statements that are included in text fields withing the schematic itself will not be interpreted according to the Pspice syntax?

m