SPICE MODELS - MOS x VDMOS

[PKTKS]

RESULT…

Paul

[holger]

All my tests with WinGUI and Windows console ngspice are o.k.

So next question: Do you have a .spiceinit file in your home directory in addition to spinit, with a ‘set ngbehavior=all’ ? spinit is read first, then .spiceinit, which may override entries to spinit.

Another possibility: Did you make standard ngspice first, and then ngspice from PSPICEComp3 branch?

Then it might be necessary to add a ‘make clean’.
.configure …
make clean
make
If not cleaned explicitely, old object files may mix up with the new ones, sometimes resulting in unpredictable behavior.

[PKTKS]

Let’s go by parts:
** SYSTEM **

• I am a NIX veteran … from the 80s HPUX/AIX/SCO…
• i survived them all until BSD… and linux.
• MS stuff i ditched for good by mid 90s
• enough to say: when they crapped Borland and WATCOM…
• I can’t provide you with kinda “distribution”
• My system is crafted for my needs
• Compare *NIX with MS is pointless - they crapped even HTML

** PROFILE **

• I just use the GLOBAL spinit - NO LOCAL .spiceinit
• It can be seen by the test that it loads fine
• my guess is a buffer copy/overwrite problem

** COMPILER issues **

• All things are vanilla source and thoroughly matched
• The source code downloaded and compiled pristine
• Obvious first top list culprit may be GLIBC
• It seems that the variable is being seen but either one
• OR it is not properly copied to internal buffer
• OR it is overwritten lately by some call
• or else some other issue - not taken into account

It looks just that simple
question is to find the proper code call where the buffer
is either NOT FILLED or OVERWRITTEN.

My guess.
Paul

[PKTKS]

Furthermore…

Based on my very simplistic guess, i’ve made an equally
simple search to find any buffer related issue.

The core environ logic decision is:

COMPATMODE_T
ngspice_compat_mode(void)
{
    char behaviour[80];

    if (cp_getvar("ngbehavior", CP_STRING, behaviour)) {
        if (strcasecmp(behaviour, "all") == 0)
            return COMPATMODE_ALL;
        if (strcasecmp(behaviour, "hs") == 0)
            return COMPATMODE_HS;
        if (strcasecmp(behaviour, "ps") == 0)
            return COMPATMODE_PS;
        if (strcasecmp(behaviour, "spice3") == 0)
            return COMPATMODE_SPICE3;
    }

    return COMPATMODE_ALL;
}

But is always tricky handle BOOL in C.
Thus I went to that call

bool
cp_getvar(char *n, enum cp_types type, void *r)
{
    return (FALSE);
}

Which for my surprise returns a TOTAL useless FALSE always
If that is FALSE the code above WILL NEVER EXECUTE.

I may be wrong if that is so simple as that…
Paul

[holger]

I have activated my LINUX box (recent OpenSuse), made ngspice and run the examples.

set ngbehavior=ps

is clearly recognized, the examples are o.k. (and not o.k. when the command is commented out).

Where did you find the code snippet on cp_getvar you have cited in your last post?

[PKTKS]

directly from the “snapshot” on sourceforge.

I have checked that and is duplicated “as is” on the vdmos
branch as well … at least from what I have downloaded

https://sourceforge.net/p/ngspice/ngspice/ci/vdmos/tree/

I have browsed the code there and is really that …
something may be wrong upon synch on the branch

browse the URL go to <NGHELP.C> you should have this
(note that this is a shot taken just now…)

[holger]

What are your ./configure options?
You should do

./configure --with-x --enable-xspice --enable-cider --enable-openmp --disable-debug --with-readline=yes

Anything else is risky.

nghelp.c is outdated. It generates an independent help executable. cp_getvar there is just a dummy function.

The “good” cp_getvar is defined in src/frontend/variable.c

[PKTKS]

Options are plane minimum sane

• —enable-xspice
• —enable-cider
• —disable-debug
• —enable-xgraph
• —with-readline=yes

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

[PKTKS]

• I have commented OUT that lost piece of code…
• Recompiled the source from PSPICE branch ALL EQUAL
• With some TEST POINTS inserted like

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:

• VARIABLE IS BEING OVERWRITTEN ELSEWHERE

Still looking some clue where it may be falling back to “all”
even though initialized with “ps” and already RID from that call

Paul

[PKTKS]

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

[PKTKS]

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:

[PKTKS]

… 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

[hermit]

@PKTKS

Hello, now that ngspice is integrated within EESCHEMA several issues will arise and become common among users.

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.

Update on the use of ngspice from EEschema

I thought it was time to post updates to the things I have noticed while testing the ngspice simulation called directly from within EEschema. I have posted about this before, but I am updating my notes as I find new quirks. Spice assumes pins in its models to be: MOSFET: m[name] [drain] [gate] [source] [substrate] JFET: j[name] [drain] [gate] [source] [model] BJT: q[name] [collector] [base] [emitter] [model] DIODE: d[name] [anode] [cathode] MESFET: ZXXXXXXX ND NG NS N.B. Many models in …

[mifi]

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

[PKTKS]

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

[PKTKS]

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

[holger]

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

[PKTKS]

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

[holger]

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

[PKTKS]

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…