Re: [Help-gnucap] Time step control

[al davis]

On Tuesday 19 February 2008, a r wrote:
> I have different experiences - a realistic circuit model
> usually makes the simulation easier. This is especially
> visible in extracted simulations. It's not that I am so big
> fan of LTE. If you can come up with something better - that's
> great. But for the time being LTE seems to be the only choice
> of running transient simulations with time step control in
> Gnucap.

Did you try putting switches at the critical points like I 
suggested? Even if the threshold is never crossed, they help 
step control by anticpiating a crossing.

Clearly, voltage based step control is needed for you type of 
circuit.

> > Spectre is strictly voltage based.  I think HSpice is now
> > too, but it may have old spice truncation error based code
> > still there.  Most of the "fast-spice" simulators are
> > voltage based only, and use Euler's method.
>
> I didn't know. BTW, Spectre "doesn't like" small series
> resistors (which are very important for modeling
> interconnections). Do you think it can be caused by this
> voltage sensing? 

No.  It has to do with finite precision of numbers.  All 
simulators do that to some extent.  It also is related to 
details of the matrix solver.

> If so, how about using current sensing as 
> well?

Spectre time step control is strictly node voltage based, as far 
as I know.  Given that, I suppose if a voltage difference 
between two nodes is critical, and there is a high common-mode 
component, spectre could miss it.  There are lots of tradeoffs 
here.

I plan to implement it in gnucap, soon.  Then you can try it.  
It has been on the to-do list for a long time.

> > In the development snapshot, e_storag.cc, line 250.  Make
> > it always false.  Perhaps there should be an "option" to
> > turn it back on, but it worked so badly that I decided it
> > was better always off.  While it worked so badly, I did
> > prove that it was correct.
>
> I tried it. It actually works pretty well for my circuit.
> With relaxed accuracy settings it gives equivalent results to
> the trap method (without ringing, of course). There is one
> problem, though, which looks like an implementation issue:
> When I enable time step control in the euler method (by
> modifying source code) all the strays fall into time step
> control as well. When I try to simulate with the _trap_
> method the number of iterations is about twice as big as
> before modification. Also, warning messages that come from
> "deactivating" time step control for stays are now printed
> all the time.

That warning really should only show when you ask for it.  In 
lines 307 and 309 of e_storag.cc, change "bDANGER" to "bPICKY".

Sometimes in development versions, I want to show when something 
is triggered.  It is working as intended and no longer needs to 
say so.

> > Years ago, I did try to implement Gear's method, and ran
> > into problems with automatic step control.  Gear's method
> > is easy when step size is uniform.  It is manageable when
> > step size is non-drastic and global.  It is harder when
> > step control is drastic and local, so I didn't go any
> > farther.  I started to do a mixed approach like Spectre
> > does, so the framework for it is in place, but other things
> > had higher priority.
>
> That's one more great thing to have. It's long since I used
> anything else than Gear's method at work.

Looking again ......

Spectre usually substitutes Euler for Gear when Gear gets into 
trouble.  That is probably the way to do it.  It still misses 
the high-Q Gear problem.

so much to do.....