SPICE MODELS - MOS x VDMOS


#42

No problem reading the LTSPICE <standard.mos>
directly on console… runs perfectly…

can choose ANY VDMOS or MOS defined device…

works great!!!

Paul


#43

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


#44

A bug fix is uploaded to the ngspice master branch

Holger


#45

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


#46

For the sake of organizing the results …

  • What version should I keep my tests with?
  • pre-master9 ? master ? or else …

Paul


#47

Please move on with the ‘master’ branch.

Holger


#48

OK some more test results…

Here is a thing:

  • regarding latest changes in <src/frontend/inpcom.c>
  • traced a segfault that boils down to MODEL VSWITCH
  • Just that part - all other changes are fine
  • Note the detail - IT IS NOT a recursive .include directive
  • SEGFAULT when finding a VSWITCH model included from other source

Explained:

  • MASTER <*cir> file (eg analysis) includes a SLAVE <*cir>
  • SLAVE <*cir> defines models and sources (including VSWITCH)
  • RESULT SEGFAULTS

Now single file does not include any file w/VSWITCH

  • MASTER <*cir> file (eg analysis) is single includes all sources
  • but STILL INCLUDES OTHERS WITHOUT VSWITCH models
  • RESULT WORKS PERFECT even including VSWITCH model - perfect

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


#49

Some fancy shots may help

This is a typical BOOST where multiple analysis are run from a single
definition source. The source includes a VSWITCH model

Modes vary wide in params to cover from BCM to DCM/CCM modes
as well as various thermal loop and feedback stability control runs

here the shot

Paul


#50

Do you have a (simplified) input file for me that seg-faults?

Holger


#51

To find this problem I have spent last 3 days combining several of the master sources to figure out WHY

  • a simple single source file IS PERFECT
  • while a source with multiple included files some are fine some not

Reason being is that - the latest change to correct VSWITCH in
pspice_compat is affected - but just that bottom part of the function

When you include VSWITCH in another source

  • which will be included - you got the fault.

The simple shots I have posted are the result of 3 days
of trial and error to find that.

Inclusion of VSWITCH model outwards a source file

If you include the VSWITCH model right in the master source
the PATCH you have made is WORKING PERFECT.

SAME FILE COMBINATIONS 100% equal
just by including the VSWITCH model
from outside the master source is causing this
and whatever I have tried…

it boils down to this fact on pspice_compat function latest fix of VSWITCH.

As you said - it is not trivial to consider that much level of handles
in that function

You may try this very simple approach for example
a real part of the far more complex sources I have passed…

* MASTER

V1 Vin GND DC 5
V2 Vsw GND DC 0 PULSE(0 5 0 0 0  97.22u 166.7u)

.include 'SLAVE.cir'

.control
	run
.endc
.end
* SLAVE

.include '/share/spice/whatever...'

.model relaysw SW(Ron=10m Roff=1G) ; Vt=threshold Vh=hysteresis

It should be able to reproduce a traceable guide to this fault

Paul


#52

Paul,
if I type your files as they are, nothing happens…

Basically the ngspice option is made to include device libraries with PSPICE syntax.

In these device libraries all .model lines (e.g. .model myswitch vswitch(…) ) and the corresponding instance lines (e.g. smyswitch 1 2 3 4 myswitch) have to be contained in a single file that is then loaded by .include. It is not intended that one .include contains the .model line of the vswitch (we are not talkng about the sw switch!) and the other .include contains the corresponding instance s…, it is also not possible to have the .model line on the top level and the instance s… in the .include.

Still it should not seg-fault, whatever you try. So could you add some lines to make your example complete (immediately runnable)?

Holger


#53

I may try but obviously results may not be the same

This thing is complicated.
I have a bunch of scripts that will run inside the control loop
compute deviations and mostly stuff to FFT as I am interested
in harmonics and drift.

I have cut almost 90% of the stuff…
BUT STILL SEGFAULTS with just those silly lines…

* MASTER

V1 Vin GND DC 5
V2 Vsw GND DC 0 PULSE(0 5 0 0 0  97.22u 166.7u)

.include 'SLAVE.cir'

.options method=gear reltol=1m NOPAGE NOACCT NOINIT
.tran 10n 15m 0 uic 
.control
	run
	plot  v(Vout) v(Vsw) l1#branch 
.endc
.end

* SLAVE

.include '/share/spice/cmp/MINE/MINE.dio'
.include '/share/spice/cmp/MINE/MINE.bjt'

.model relaysw SW(Ron=10m Roff=1G)
S1 Q1c  GND Vsw GND relaysw
L1 Vin  Q1c  23.85u
D1 Q1c  Vout 1N4007
C1 Vout GND  231u
Rx Vout GND   2.4

I can not change my included files I have no option to those.
But my guess is that it won’t matter

** IF IT DOES MATTER**
tell me so I can pass again other combinations

it requires just this to segfault.

Paul


#54

And BTW running that same crappy MASTER/SLAVE
above under the “REGULAR” SPICE3F ONLY

version (aka the ngspice - version27)

the thing is fine

should produce something like this


Paul


#55

To form a complete panorama

I managed to have the 3 versions running on my Workstation

  • regular ngspice27
  • premaster9
  • master

This is the result of pre-master9 running the same crappy
MASTER/SLAVE …

It is obviously WRONG but at least the fault is not there.
with this included model

Paul


#56

Bug is identified, a fix is under way to master.

Done!


#57

Great…

I forgot to put available the diode model used in this draft
but my guess is that it won’t matter for this case

.model 1N4007	D (
+ IS=7.02767e-09 N=1.80803 RS=0.0341512
+ EG=1.05743 XTI=5 
+ CJO=1e-11 VJ=0.7 M=0.5 FC=0.5 
+ TT=1e-07 BV=1000 IBV=5e-08 KF=0 AF=1)

Paul


#58

Paul,

any bugs left?

If not, I will start preparing the new ngspice release.

Holger


#59

too soon to have that sure

But IMHO things are pretty close to consider a MAJOR release
It has nothing to do with the old one.
Any bug found will be a MINOR fix.

Every run in my system is very time consuming
and space as well. Data is dump in several files to post process.

That simple BOOST when closed loop will produce a roughly 2G
of data to plot after several minutes tweaking data.

Front end result looks like this

so eventually one of the runs may find some issue not seen so far.

If the last one BUG is closed
i think it is good to go.

Paul


#60

and by the way…

THE SHOT ABOVE WAS MADE USING THE LATEST FIX

using that very same included master/slave sources
but this time complete with all gizmos

got to the filled FFT vectors to the point WITHOUT a GLITCH

so far so good
Paul


#61

The following patch will allow proper recognition of VDMOS
as a VALID MODEL TYPE in spice dialog list

Very simple fix needed
Working fine so far against this week latest GIT synch

--- ./eeschema/dialogs/dialog_spice_model.cpp.orig	2018-06-17 08:27:37.000000000 +0000
+++ ./eeschema/dialogs/dialog_spice_model.cpp	2018-06-17 08:19:59.000000000 +0000
@@ -786,7 +786,7 @@ DIALOG_SPICE_MODEL::MODEL::TYPE DIALOG_S
 
     if( val.StartsWith( "npn" ) || val.StartsWith( "pnp" ) )
         return BJT;
-    else if( val.StartsWith( "nmos" ) || val.StartsWith( "pmos" ) )
+    else if( val.StartsWith( "nmos" ) || val.StartsWith( "pmos" ) || val.StartsWith( "vdmos" ) )
         return MOSFET;
     else if( val[0] == 'd' )
         return DIODE;

kicad_dialog_spice_model.patch.gz (296 Bytes)

Paul