gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] PSS analysis


From: henrik johansson
Subject: Re: [Gnucap-devel] PSS analysis
Date: Thu, 11 Jun 2009 22:12:13 +0200

2009/6/9 al davis <address@hidden>:
> On Tuesday 09 June 2009, henrik johansson wrote:
>> 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.
>
> That's correct.
>
> So, how to get the derivative?  I don't see any way for that
> derivative to be calculated analytically, so that means to
> calculate a finite difference.
The Jacobian of Phi can be calculated from the transient Jacobian
J_tran and the transcapacitance matrix, the details are described in
the Steady-State book by Kundert.
For backward-euler the jacobian of Phi is:
J_Phi = dx_K/dx_0 = J_tran_k^(-1) * C_(k-1) * dx_k/dx_(k-1)

where x_k is the state vector for time instant t_k where k goes from 0
to K, C_k is the transcapacitance matrix.

So J_Phi can be calculated by repeated application of the about
equation from k=0 to K
dx_0 / dx_0 is the identity matrix


>> 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.
>
> No .. a hidden state is a state that is not stored between time
> instants.
>
> Think of a capacitor ....  Q=CV  ... then find i=dq/dt, for the
> right side.  Q is the state variable.
>
> You could, alternatively, calculate i=C dv/dt , and not store Q.
> Now, Q is a "hidden state".
>
> Hidden states exist in some models, and are usually not
> dependent on the simulator.  In this case, all the simulator
> sees is that "i" is a function of "v".  The fact that it depends
> on history is forgotten.  If the capacitor is linear, you can
> calculate it again, but for nonlinear capacitors, the results
> can be inconsistent.
>
> Some of the Spice models have hidden states.  As I recall, BSIM3
> does, because it gave me grief when I was working on the
> modelgen version of it (d_mos8.model). ...  That model has the
> dreaded "hidden state bug", because modelgen subcircuit based
> models don't support hidden state.  I think level-2 also has the
> hidden state bug.
>
I think we are talking about different kind of hidden states. The
guide "http://www.designers-guide.org/Analysis/hidden-state.pdf ",
gives a much clearer explanation of what I was trying to say.

>> 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.
>
> It's a problem .. Look at the "Meyer" capacitance model used
> with the older simple MOSFET models.  If you don't store charge
> you cannot get a consistent result.
I don't agree that the model has to store the charge as a local state
variable to be charge-conserving. Isn't the problem when the
capacitance is described as a function of the terminal voltages. So if
the state variables are the terminal-voltages and the charges are
calculated as a function of the terminal-voltages and these charges
are used to build

>> 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.
>
> That means to do the whole model evaluation, with lost history.
But if you always start with an euler step which only needs the
current state to calculate the next it could be possible.

> If you assume that the states can be determined from the voltage
> vector, that implies that for this purpose they are not needed.

I think many models have internal states that could have been
calculated from node voltages and branch currents. And if they cannot
they could be made explicit as an internal node instead so that they
will become visible in the Jacobian.

And it will be less redundant states. Take for example a model of a
capacitor where its charge is saved as an internal state. Now if you
have 100 instances of these in parallel the state vector will have 100
states instead of just the voltage across them.

> So why not base the shooting on just what you have available?
The problem is as you said the derivative, there are no rows in the
transient jacobian for the "hidden" states.

>> 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.
>
> It is possible to have all of the states available, as if all in
> a vector.
>
>> 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.
>
> We are stuck with Spice models.
>
> The problem occurs when a model writer explicitly codes
> something that could be done automatically.
>
Yes exactly, but there are many models already available as verilog-a
like bsim3 and psp

/Henrik




reply via email to

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