Re: [Help-gnucap] Time step control

[a r]

On Feb 19, 2008 2:09 PM, al davis <address@hidden> wrote:
>
> With noncritical circuits, a lot of things work, even if it is
> round-about.  Unless you are doing critical analog work, where
> noise, distortion, and accurate timing are all important,
> truncation error is a round-about method.

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.

> 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? If so, how about using
current sensing as well?

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

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

-r.