[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnucap] Time step control

From: a r
Subject: Re: [Help-gnucap] Time step control
Date: Mon, 18 Feb 2008 21:25:55 +0000

On Feb 18, 2008 8:58 PM, al davis <address@hidden> wrote:
> Truncation error step control for Euler always gives very small
> steps, significantly smaller than the steps used for trap.

Sure, truncation errors will be larger (that's Euler after all) but it
is just a matter of relaxing truncation error requirements. What I
need is a variable time step that adapts to the circuit "activity".

> Euler will never give you ringing artifacts.

But without time step control it may give you totally wrong results.
Say we have a synchronous logic circuit - how gnucap is going to
recognize that a clock edge appeared before or after a transition of a
sampled signal? For the simulation both of them may appear to have
happened at the same time step of the transient simulation if the time
step is too large.

There are only two ways to solve this problem:
1. decrease time step to such a value that it will precisely simulate
fastest signals in the design.
2. make time step variable (i.e. use time step control) and depend on
simulator to recognize circuit activity (within a specified precision)
and slow down when necessary.

Solution 1 is only viable for very special case simulations (transient
noise, RF carrier, very high speed logic etc.). People usually want
the simulator to take care of these details.

> I suspect that chgtol is still too large.  1e-15 = 1
> femtocoulomb.  That's 1 volt on a 1 femtofarad capacitor.
> It points out the need for error control that is not based on
> charge.

No difference here.

> > I think the threshold between trap and euler
> > methods for "storage elements" (strays etc.) should be placed
> > slightly higher than dtmin (say 2~3 * dtmin). It looks for me
> > that currently the minimum time step is always a bit too
> > large for those strays that have passed just under dtmin
> > threshold, hence the numerical ringing.
> That is easy to do.  I think I will. There needs to be a
> difference between minimum resolvable time and the stepping
> from truncation error.

I just tried changing this threshold ( and it doesn't
help. However, the current performance is satisfactory for me.


reply via email to

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