help-gnucap
[Top][All Lists]
Advanced

[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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]