Options are plane minimum sane
But whatever options used this is “C” not C++
and overloading will not work
If this source is being included in compilation chances are
that this one is prevailing whatever the other.
No matter the options or the cause the code should
not have this call anymore. Just the plain updated correct one.
Paul
COMPATMODE_T
ngspice_compat_mode(void)
{
char behaviour[80] = "ps";
if (cp_getvar("ngbehavior", CP_STRING, behaviour)) {
printf("TEST POINT 0: %s\n",behaviour);
if ( strcasecmp(behaviour, "all" ) == 0) { printf("TEST POINT 1: %s\n",behaviour); return COMPATMODE_ALL; }
if ( strcasecmp(behaviour, "hs" ) == 0) { printf("TEST POINT 2: %s\n",behaviour); return COMPATMODE_HS; }
if ( strcasecmp(behaviour, "ps" ) == 0) { printf("TEST POINT 3: %s\n",behaviour); return COMPATMODE_PS; }
if ( strcasecmp(behaviour, "spice3") == 0) { printf("TEST POINT 4: %s\n",behaviour); return COMPATMODE_SPICE3; }
}
printf("TEST POINT 5: %s\n",behaviour);
return COMPATMODE_ALL;
}
RESULT INDICATE THAT:
Still looking some clue where it may be falling back to “all”
even though initialized with “ps” and already RID from that call
Paul
Problem solved.
After removing the lost call and recompiling with conservative
debugging options the va_struct_list arguments matched
Should be fine without that lost call using -O2
Paul
Now that things are working smooth…
Some new bits to tune in the DIAC PSPICE lib…
UNRECOGNIZED PARAMS which may be mapped or implemented
in the DIAC models are:
… and BTW … if you are wondering if that is working in KiCAD
YES. With that proper initialization and compile time parameters
the library is perfect in PSPICE mode as well
TYPO the missing parameter is indeed tbv1
Paul
Now that things seem to be worked out, we do have a thread in the FAQ about using ngspice. You might consider making a summary post there. It would be OK to point to this thread also to save some work on that. It may be better to start a new thread. I’m not sure.
I am so glad you guys are figuring all this out, because, boy did I have problems lately with ngspice. I now understand from the thread that the development of the internals of the different spice’s have diverged in more ways than I knew.
I hope you can figure it out, but I am afraid there is little I can offer to help.
Thanks for getting some order in all this.
m
I am not sure either.
From my start issue this single post managed to converge
several already ongoing other issues.
They are indeed converging…
Question is - how to integrate these 2 ngspice branches
into a new solid release where PSPICE and LTSPICE (vdmos)
are already supported by default
The topic root is another issue that seems to be
more properly attached to “SYMBOLS”
as from this simple panorama of convergence of things…
Paul
indeed pins vary widely from one manufac. to another
even for the same device type
that’s where the pin order entry comes in…
just reorder where necessary.
Another question that will certainly arise soon or later
is the LOCATION of these models. And the proper LICENSE(s).
Paul
ngspice-28 will contain both VDMOS and PSPICE compatible loading of device libraries.
There is a ngspice branch with both items available just for testing (branch pre-master+5 at https://sourceforge.net/p/ngspice/ngspice/ci/pre-master+5/tree/)
Holger
EXCELLENT.
I had few spare time to test extensively …
But the tests I have made with my circuits ALL 100% OK
Prior of having this PSPICE compat I was using
.include “myFUNCTIONS”
Removed that and ALL PSPICE seems fine.
Some parameters still not recognized here and there
but mostly part of specific models.
Please don’t forget to GET RID of that lost duplicated call in <nghelp.c>
bool
cp_getvar(char *n, enum cp_types type, void *r)
{
return (FALSE);
}
There is no point of having this call any more.
I will find some time to pass this release …
Looking forward to it
Paul
ngspice with VDMOS model and PSPICE device library support is coming closer.
Info is availabe at https://sourceforge.net/p/ngspice/discussion/ngspice-tips/thread/7838169b/
Windows 64 bit executables (including dll), drawn from the master branch sources, are available from http://ngspice.sourceforge.net/download.html.
Holger
I think is almost there already …
This BOOSTER runs perfectly BUT
i have to manually define the VDMOS model in KiCAD
The SPICE MODEL dialog is missing the logic to
recognize the VDMOS entries in the source file
Apart that … it runs perfectly
latest CVS downloaded today as pre9
compiled fine and runs perfectly…
No problem reading the LTSPICE <standard.mos>
directly on console… runs perfectly…
can choose ANY VDMOS or MOS defined device…
works great!!!
Paul
I have the first issue with a standard SPICE3 draft.
This examples runs fine WITHOUT PSPICE compat.
But WITH compat ennabled it generates the following error:
Error on line 308 :
as1 %vd(vsw 0 ) %gd(q1c 0 ) arelaysw
MIF-ERROR - unable to find definition of model arelaysw
From spice source
Paul
A bug fix is uploaded to the ngspice master branch
Holger
Another update to the ngspice master branch (and the MS Windows executables for download):
things became too complex, so there is now a re-write of the vswitch transformation code, dealing with multiple models within subcircuits and top level, and instances calling the models, in a mix of standard ngspice switches and PSPICE vswitches.
Holger
For the sake of organizing the results …
Paul
Please move on with the ‘master’ branch.
Holger
OK some more test results…
Here is a thing:
Explained:
Now single file does not include any file w/VSWITCH
Could not figure out a PATCH without removing the bottom part
of function pspice_compat
Reverting that part to the lastest pre9 works fine
but that previous error is still there.
Paul
