Re: [Gnucap-devel] PSS analysis

[henrik johansson]

2009/6/8 al davis <address@hidden>:
> I don't know...
>
> I had the impression that the algorithm being presented is
> really the standard transient analysis, unwrapped, with maybe a
> few minor changes, but I have not actually studied it.
>
> Gnucap  has a provision for continuing a transient analysis,
> using the end of the previous run as the starting point for the
> new run.  It seems to me that it should do what you need in this
> case.

> Look at the example:
> http://wiki.gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:phase_shift_oscillator

As I understood it this method is identical to solving the problem
Phi(x0, t0, T) = x0 using fix-point iteration. So the problem is of
course that the convergence rate is not that great. Using newton's
method instead gives quadratic convergence. So for a circuit slow
decaying states this could be very slow.

> Restarting like this is not based only on the voltage vector.
> All devices store their own state.  The device function

Yes they do and it works like that in most simulators.
I can't understand how the problem is solved in commercial simulators
with PSS analyses. The PSS analysis in Spectre doesn't work if the
circuit contains so called hidden states. I think they are defined as
variables that keep their values between time instants. So by that
definition the device states in gnucap/spice etc are hidden states.

Maybe the models for these simulators are written without these
internal states. Which would mean that the BSIM code from Berkeley for
example must be completely re-written for these simulators. Which
seems unlikely.

If these hidden states where all redundant, by that I mean that they
are memory-less function of the global state vector, they will not
cause any problems with convergence.
For example if there is a capacitor model that stores its charge as an
internal state and the voltages at its terminals are global states. In
this case the internal state can easily be calculated from the global
states.

> tr_restore exists to make sure a restart starts from a
> consistent state.  You might want to look at the the
> "tr_restore" functions, particularly for some of the more
> complex devices.
> Since I did that so long ago, I don't remember what is really
> required.  It might be useful to look at the "freeze" and
> "unfreeze" commands.  (and possibly uncover a new bug after all
> these years).  I like to think this works, and has worked for a
> long time, but actually I would not be surprised if you can find
> cases where it does not restore correctly.

Looking in the ELEMENT implementation of tr_restore it restores the y
state variable from an earlier time point.

Maybe if this was changed so that it will restore the state from the
global state in vdc when possible. This way the remaining hidden
states will converge slowly but with some luck they will decay fast.

The problem is in the spice-wrapper. I haven't seen any code in the
spice API that does this. The closest function I have seen is the
initial condition functions that is used to assist DC-analysis
convergence.


> I don't think it is possible, or at least not practical, for the
> voltage vector to capture the complete state, in general.  Just
> thinking of the inductor is a tiny subset of "all models",
> especially considering new models that don't yet work but will
> in the future, or have not been developed yet.
>
> When I say "complete state" .. think of something like a BSIM4
> model.  A quick check tells me that it has 8 internal nodes,
> representing some kind of internal state that is stored in the
> voltage vector.  It also has 29 (if I counted correctly) state
> variables that are not stored in the voltage vector.  I can't
> think of any way to access this reliably in general in a form
> that would be useful in this case.
Hmm, maybe most of these states are reduntant. Anyway, there is still
no function to set these states from global states in the spice API.

Or maybe the spice models cannot be used with PSS. I guess this will
be less of a problem when more models are available as Verilog-AMS
code.

Regards,

Henrik