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.
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.
1 Like
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. 
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.
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
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.
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
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
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.
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
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
1 Like
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
2 Likes
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
Yes, exactly. The idea was that we are not PSPICE, but ngspice. But we want to read PSPICE model files.
However I never thought about adding an .include statement to the text field!
1 Like
That could be done even before this nice spicey gui was added. When I generated netlists for spice via the netlist button in version 4, it was good to keep the schematic self-contained and completely documented without the need to manually add stuff afterwards to the generated file. One had to be careful to not end up with a very messy schematic, but at least it contained everything needed to be able to pick up the schematic again after 6 months or so.
Today’s solution is much neater, because the model is directly coupled to the part. That is much much better.
I would like to suggest to add a phrase containing the word “only” to section 16.13.5 of the user manual and make the behaviour explicit. Perhaps I am more thinking in terms of a reference manual than a users manual, but I think it might be better to be clear, than it is to leave the matter open to interpretation in a multi language and multicultural environment.
m
On windows 10, I cannot seem to create a file as .spiceinit. It demands a “valid filename”. I looked throughout the ngspice_dll_64.zip and found a global init file called spinit. Should the init file in the C:\users<your name> be spinit or spiceinit without the leading period.
Use the alternative name
spice.rc
Application: kicad
Version: 5.0.0-fee4fd1~66~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-30-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.3.0 with C++ ABI 1011
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
To get the .spiceinit to be read, I had to put it into /usr/share/kicad on Linux Mint 19 (Ubuntu 18.04). I added the “set ngdebug” line to .spiceinit to be sure that I could tell it was being read. I had followed mifi’s “FOR THE RECORD (on Linux)” above. By the way, before moving the .spiceinit to where it was actually being read, I noticed that KiCAD worked fine with VDMOS models (except that the GUI does not put them in the pulldown menu, as others have noted). It appears that “set ngbehavior=ps” is not required for just reading VDMOS models, only PSPICE? Upgrading KiCAD to NGspice 28 is a major step forward, as I use a lot of VDMOS models (often from LTspice). Thanks to all who have made this possible.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.