[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnucap] Time step control
From: |
al davis |
Subject: |
Re: [Help-gnucap] Time step control |
Date: |
Mon, 3 Dec 2007 15:59:49 -0500 |
User-agent: |
KMail/1.9.7 |
It's not as bad as it looks.
In a development snapshot, sometimes there are warnings for
things that would be suppressed later.
I do not have your models, so I am guessing here.
On Monday 03 December 2007, a r wrote:
> Now, how to use the models?
>
> I have attached the bsim330.so and got a message:
>
> M: already installed, replacing
> stashing as M:0
That is telling you that the attachment is hiding an internal
model. That's what you want, isn't it?
> When I use MOSIS models (level=49) directly I get error:
>
> Mp.xi1: model cmosp is not a bsim330,bsim3
>
> When I change level from 49 to 8 the simulation _works_ but I
> get some errors/warnings:
Expected .... That model installs as level 8. I suppose it
should also work as 49. That's easy.
>
> LEVEL = 8 VERSION
> ^ ? bad parameter, ignored
That is probably a bug. I need to see the ".model".
>
> and then bunch of warnings:
>
> Warning: This model is BSIM3v3.3.0; you specified a wrong
> version number.
What version did you specify? Maybe you don't want 330 ..
There is probably something like "version = xxxxx" in the .model
statement. What does it say? You should use the model that
matches. The handling of this not quite correct now. It will
get better. This is one of the reasons it is still
a "development" version.
> Warning: Pd = 0 is less than W.
> Warning: Ps = 0 is less than W.
You didn't specify pd, ps. Spice would give you the same
warning. This is printed by the BSIM code. It probably should
not be printed this way, but I didn't write it. It is a bad
idea to leave "printf" statements inside of model evaluation
code.
I don't know what to do about it, other than modifying code in
violation of a policy not to modify. All I can think of is a
header that #defines printf to nothing.
Recall... the Spice model code is used without any
modifications.
> [...]
> initial step rejected:Mp.xi1
> new=1.87716e-12 old=1e-11 required=5e-12
This is telling you that the stepping you requested is too
large, enough too large that you should know about it. Even if
the simulation is correct, you are not seeing all that is
happening.
> storage element step control error:Mp.xi1 6.11037e-17
> using Euler, disabling time step control
There is a tiny capacitor that probably can be ignored. Gnucap
has decided to use "euler" for that one.
The message should be reworded ... Time step control and Euler
only apply to that element. The rest of the circuit is still
using full step control and the method you requested.
It is probably working correctly, just letting you know that you
are missing something.
On these last two .... some other simulators take similar
action and don't tell you. It is my opinion that the worst
thing a simulator can do is to hide when it believes the
answers might be off, leading you to trust data that you
shouldn't. The worst of that is when the wrong results are
believable.
You say it works .... No trap ringing???
It looks like it found where the trap ringing is coming from.
The print resolution you asked for is too coarse to show the
effect of it, so it switched to Euler and assumed you don't
care to see the effect of that part of the circuit accurately.
Consider this RC network ...
v1 1 0 pulse (....)
r1 1 2 1
c1 2 0 1f
r2 2 3 100k
c2 3 0 .001
The time constant r1 c1 is 1 femtosecond.
The time constant r2 c2 is 100 seconds.
If you do r1 c1 with trap, it will ring badly, or do really tiny
steps. Solution: use Euler, ignore step control.
That lets the other (r2 c2) control the stepping, and hopefully
you get the results you want.
If you specify time stepping appropriate for r1 c1, The step
control will catch it, and give you correct results for that.
You may think this is a bogus situation, but it isn't. In a
real circuit, the fast TC probably comes from strays, like the
internal capacitance of a device. The slow TC is probably what
you want to build, some kind of filter. You might want one or
the other. It can tell by the stepping and range you ask for.
My circuit design experience includes wideband amplifiers, where
this matters. You see it in audio. You see it more in video.
- [Help-gnucap] Time step control, a r, 2007/12/01
- [Help-gnucap] Re: Time step control, a r, 2007/12/01
- Re: [Help-gnucap] Time step control, al davis, 2007/12/01
- Re: [Help-gnucap] Time step control, a r, 2007/12/01
- Re: [Help-gnucap] Time step control, al davis, 2007/12/01
- Re: [Help-gnucap] Time step control, al davis, 2007/12/03
- Re: [Help-gnucap] Time step control, a r, 2007/12/03
- Re: [Help-gnucap] Time step control, a r, 2007/12/03
- Re: [Help-gnucap] Time step control, al davis, 2007/12/03
- Re: [Help-gnucap] Time step control, a r, 2007/12/03
- Re: [Help-gnucap] Time step control,
al davis <=
- Re: [Help-gnucap] Time step control, a r, 2007/12/03
- Re: [Help-gnucap] Time step control, al davis, 2007/12/03
- Re: [Help-gnucap] Time step control, a r, 2007/12/03
- Re: [Help-gnucap] Time step control, al davis, 2007/12/03
- Re: [Help-gnucap] Time step control, al davis, 2007/12/03
- Re: [Help-gnucap] Time step control, a r, 2007/12/03