[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap
From: |
Ruben Undheim |
Subject: |
Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap |
Date: |
Sat, 17 Nov 2018 09:53:16 +0100 |
Hi!
> > I get thousands of messages like this:
> > parameter # not specified, using default
> > parameter # not specified, using default
>
> Is # supposed to introduce a comment?
> Your file may have some tail-comments ..
Actually the character "#" is not present at all in my input file.
> .model noo nmos fffr=3344 fgt=94 # tail comment
> + more=3e4
>
> Try editing the file to remove them.
>
> Whole line comments introduced by # should work, but sometimes the
> mid-line # doesn't.
>
> There are a lot of variants of spice syntax. Keeping track of them all
> can be crazy.
That is understandable :)
> Gnucap uses a single pass that sometimes misses the
> # as a comment in the middle of a line.
>
> > and some like this:
> > parameter ad not specified, using default
> > parameter ad value is "NOT_INPUT"
>
> This could also be related to the single pass parsing. Look for a #
> somewhere that might have turned the parameter ad into a comment.
>
> > and then thousands of these:
> > parameter # recursion too deep
> > parameter # recursion too deep
>
> Parameter recursion is supported, but with a limit to block infinite
> self-recursion. You might try setting option recursion higher. The
> default value is 20. But really, I think something happened in parsing
> that turned something into infinite recursion.
I tried increasing the recursion default value, but then even worse
problems appear (some memory corruption or similar).
> > At last, it crashes with:
> > gnucap: /usr/include/gnucap/spice-wrapper.cc:1074: virtual void
> > DEV_SPICE::precalc_last(): Assertion `_maxEqNum == ckt()->CKTmaxEqNum'
> > failed.
>
> Something went wrong between the line :
> _maxEqNum == ckt()->CKTmaxEqNum;
> and the line
> assert(_maxEqNum == ckt()->CKTmaxEqNum);
> ?????
>
>
> If you send a file that demonstrates the problem I can look at it. All
> that stuff is probably due to one detail in file parsing.
I have not been able to narrow down a test file yet. I cannot send the
file I have because I have it via an NDA unfortunately.
I will see if I can demonstrate the problem in a custom file.
> The optional plugins are not tested to the same high standard used for
> gnucap core. I can't keep up with them all.
>
> "spice-wrapper.cc" was really quite a challenge, mapping the
> incompatible interfaces, so gnucap can use the spice models from
> Berkeley, and 4 different variants of Spice that are incompatible with
> each other, without changes other than two small config files. It's
> time to add a fifth spice variant (a new NGspice), but working with
> spice code is not a pleasant experience.
It is quite impressive actually.
My input file contains this structure (from top to bottom):
* load modules (in the top)
* "spice"
* Multiple global ".param"
* Then some ".param"-s which use other params:
- .param blabla = '5*another_param'
* ".subckt mynch n1 n2 n3 n4 l=length w=width scale='some_param*3' ........"
* Multiple ".param" within .subckt
* a "main" device in the .subckt: "main n1 n2 n3 n4 nch w=w l=l
ad=ad as=as .."
* More ".param"s within .subckt
* ".model nch.1 nmos (level = 54 lmin = '0', lmax = '0.1'
cjd='cjn_ms*5' ........ )"
* ".model nch.2 nmos (level = 54 lmin = '0.1', lmax = '0.2'
cjd='cjn_ms*5' ........ )"
* . ....
* ".model nch.25 nmos (level = 54 lmin = '1.2', lmax = '1.3'
cjd='cjn_ms*5' ....... )"
* ".ends mynch"
* Then the netlist using "mynch"
* And in the bottom (my own lines not under NDA):
R1 1 3 10000
V2 2 0 dc 0
X1 3 2 0 0 mynch l=70n w=280.0n m=1 nf=1 sd=220.0n ad=5.46e-14
as=5.46e-14 pd=9.5e-07 ps=9.5e-07 nrd=0.393 nrs=0.393 sa=195.00n
sb=195.00n sca=4.23662 scb=0.000258052 scc=2.17139e-08
V1 1 0 dc 1.3
.PRINT DC V(VCC) V(1) V(3) i(ig)
.DC V2 0 1.3 0.01 > dcsweep.out
.control
.END
Best regards
Ruben