New Meyer implementation?

[pepijndevos]

Hi,

I'm currently working on implementing the mos1 model, and have reached the Meyer capacitance calculation.
It appears spice uses values from a previous timestep, which seems mathematically unsound, in particular in variable timestep and multistep methods and such. But as you said, some of the quirks that seem weird are actually there for very good reasons.

I was reading the Xyce code a bit, and I see a lot of mentions of "new meyer", along with statements like this

Xyce/src/DeviceModelPKG/OpenModels/N_DEV_MOSFET1.C

Lines 3278 to 3280 in b2cf826

	//1/29/07, KRS: Can't use Meyer back-averaging with MPDE! For MPDE, we
	//don't integrate the current to get a charge and then differentiate it to
	//get the current back; we implement Cdv/dt directly.

Xyce/src/DeviceModelPKG/OpenModels/N_DEV_MOSFET1.C

Lines 2401 to 2411 in b2cf826

	// Special Notes : The "Q" vector is part of a standard DAE formalism in
	// which the system of equations is represented as:
	//
	// f(x) = dQ(x)/dt + F(x) - B(t) = 0
	//
	// This version is different from the original version written by Eric to
	// account for the new way we need to handle Meyer capacitors with MPDE.
	// In most devices, the Q vector contains charges (which are time-
	// differentiated to form currents). Here, the Q vector has the form [0 v]'
	// where the "0" is a block of six zeros, and "v" is a block of voltages
	// (drain, gate, bulk, source, drain', source').

Do you have an insights about this issue? How has Xyce's Meyer implementation evolved over the years, to solve what problems?

I have spent a bit of time reading the ngspice source code, as well as reading "The Meyer Model Revisited: Why is Charge Not
Conserved?" and "MOS Models and Circuit Simulation" and some more questionable internet resources. And to be honest I'm still not sure what is meant with "the meyer capacitance model". It seems to be a set of modeling equations, a set of assumptions, and a specific solving strategy depending how I look at it.

The qmeyer function appears to be a pretty straightforward calculation of overlap capacitors, but then there is this back-averaging business that I'm just not sure what it's doing. One of the more questionable online resources claimed that what Meyer is actually about is that there are stability problems directly integrating charge, and that Meyer is a set of simplifying assumptions to encode charge preservation.

Is this all there is to it?

When I was working on the "textbook" diode, initially I made a nonlinear charge-preserving capacitor that basically did but then found that's not at all what the diode does. So now I'm trying to understand what the mos1 capacitor fundamentally does, and what are useless/important convergence/preservation hacks.

[tvrusso]

So, I don't have time at the moment to give a detailed answer, but here's the best I can do quickly.

Most modern MOSFET models implement their solution dependent capacitors by computing the charge on them directly. Then, the current is just the time derivative of the charge. The capacitance, when needed for whatever reason other than computing the charge, is simply the derivative of the charge with respect to V.

The Meyer model (used in all the early SPICE2 MOSFET models level 1-6) instead computes the capacitance directly and tries to get at the charge from that. Computing charge as C*V at each time step in this way and then getting current from the derivative of charge would be wrong, and there would be charge-conservation violation as capacitance changes. So instead, what they're trying to accomplish is getting at charge by integrating CdV using an approximate method. If you use a basic trapezoid rule integral approximation, you compute the charge by adding in the little trapezoidal slice of the C-V curve between two time steps to the charge so far accumulated. If you work through the math, that involves averaging the last time step's computed Meyer capacitance with the newly computed one for this time step. It was this averaging that led to the early code making reference to "back-averaging" but the underlying purpose is to get at the integral of CdV.

"Meyer back-averaging" is what Xyce developers called what they saw in SPICE's (basically uncommented) code back around 2000-2001, but it isn't what anyone else calls it. What it is is an attempt to implement a charge-conserving solution-dependent capacitance, and it is, as you note, a bit of a hack.

That is all there is to it.

This use of the history in this manner doesn't work with some of Xyce's analyses, such as the undocumented, incomplete MPDE analysis that you see referred to in the comments in our level-1 MOSFET. So there was an effort to try to figure out how to get around this computation of Meyer capacitance and the charges resulting from them in some other way. I do not believe a completely satisfactory alternate formulation was ever found, but the "new meyer" implementation was completely focused on trying to solve the Meyer problem in MPDE analysis and has no applicability outside of that.

When Xyce's solution-dependent capacitor was implemented (which allows the C parameter of a capacitor to be a solution-dependent expression), we had to deal with the same mess, and you'll see that we do the same clumsy approximate integration to conserve charge. Later, we implemented the capacitor's "Q" parameter (which also allows a solution-dependent expression for the charge, and which HSPICE calls their "charge conservation formulation"). We did verify that our old implementation is equivalent to the new if the C expression given for the old formulation is the derivative with respect to V of the Q expression of the new formulation. The Xyce regression suite test "SOLN_DEP_CAP" tests this equivalence.

Most modern MOSFET models have gotten away from doing capacitance the Meyer way, and directly compute the charge on the internal capacitors at each step, and when capacitance is needed just for output purposes, that charge is differentiated with respect to voltage. The "charge conservation" formulation of the capacitor device avoids the problem the same way.

[tvrusso]

I'm a bit puzzled by your statement about charge conservation violation

It's really hard to hand wave this without being in front of a white board and waving hands, but the gist of this is that unless you're being careful about it and treating Q as the area under the CV curve and doing that integral carefully enough, as V increases and then decreases again, you make an error in the charge calculation that causes a net charge loss or gain that is non physical.

So, picture a curve of C vs. V, and imagine how you're approximating the area under it for any particular value of V(t1). Then allow time to advance and V(t2) is now different --- the way you compute the change in charge should be such that if V(t3)=V(t1) some time later, you should get back the same charge you had at t1. Doing this carelessly will result in a different charge, and so charge is not conserved.

Treating Q=CV or doing a clumsy Riemann sum to do the integration will both give very different answers as voltage changes --- with Q=CV being really wrong, and the Riemann sum losing or gaining a little bit of charge as you go back and forth across the C-V curve. Using the trapezoid rule is closer to the mark and the charge conservation error is less. Thing is, when you write it out, it looks like there's an averaging going on, which is where our comments regarding "back-averaging" all came from back in the day.

Perhaps this graph might help with the imagining. Picture computing the change in charge as one goes from time t1 (where the voltage is V(t1)) to t2 (V(t2)), and then at a later time t3 where V(t3)=V(t1). If one used a Riemann sum, which rectangle one uses depends on which direction one is going in --- if you're using C(v(t2))*(V(t2)-v(t1)) for the area (charge increment) you're adding in, then when you go in the opposite direction you use C(v(t1))*(V(t1)-V(t2)) you get a different increment (decrement), and charge conservation is violated.

If, however, you use trapezoid rule, the area of the slice that you use to represent the charge increment or decrement is always the same, (C(V(t1))+C(V(t2)))/2*(V(t2)-V(t1)), but the sign might change depending on which direction you're going in.

That attempt to hand-wave without actually being able to see my hands might not have helped, but I hope it does.

[pepijndevos]

Aha! It all makes sense now, I think? Classic case of taking wikipedia equations for granted.
Rewriting the correct definition it seems you'd get which for constant C indeed reduces to Q=CV.
And if I understand correctly this is exactly the equation spice is approximating.

It's a bit weird that the integration variable is time dependent. Not 100% sure if you can just carry out the integration, or need to do some change of variable or chain rule or something. You mention "integrate" over time, while this appears to be integration over a time-dependent voltage. Just when I thought I had it all figured out I'm puzzled again.

[edit] oh you wrote another message while I was sitting on this reply. Processing...

[tvrusso]

Yes, you're actually integrating over the time-dependent voltage. You're summing the little CdV slivers each time step. Sometimes this adds charge, sometimes it subtracts it.

There should be no need for changing variables --- this integral should be path-independent and give the same result for no matter what V(t) looks like between t1 and t2, but if you do the integral approximations with straight Riemann sums then the approximate charge resulting very much depends on the path --- if V goes up and back down during this time, you can gain or lose charge.

Bypassing the whole mess by computing charges directly and not these partial capacitances gets rid of the problem, but in the case of Meyer capacitances they're computed as partial derivatives of the total gate charge, and then you try to recover the currents due to the separate "capacitors". It is a formulation that has very much fallen from favor for a number of reasons, all of them enumerated in the various bits of literature you've found.

If you look at modern MOSFET models implemented in Verilog-A, you'll see that instead of dealing with a total gate charge and these Meyer capacitances, they go right to computing the components of the gate charge between various other internal nodes and computing the currents as the time derivatives of those charges. The only time the capacitances are used is for outputting what the capacitance is in the collection of "operating point outputs," and then it's done by symbolically differentiating the charge with respect to voltage.

[tvrusso]

If you need a little more mathy reasoning, the Q integral is technically a line integral over V as a function of time, but because C is the derivative of Q w.r.t. V, the line integral works out to be path independent and should just be Q(V(t2))-Q(V(t1)) no matter what V did during the time interval.

If you look at the first section of https://en.wikipedia.org/wiki/Line_integral under "Line integral of a scalar field", "r" corresponds to V, f(r) to c(v), and then you'll see the line integral over the V path reduces to a simple integral over time of C(v(t))*V'(t)dt --- and C(v(t))*v'(t) is exactly the current, so the charge is the integral over time of the current, as it should be.

So long as you sum up the various contributions to the charge (as in, with the trapezoid rule) to get the integral over V right, you get the right result and get charge conservation and it should be equivalent to integrating the current over time. When you try to take shortcuts to avoid saving state, you break charge conservation. We learned this the hard way back in 2001 --- the very first version of Xyce's MOSFET level 1 did it wrong without doing the trapezoid/"Meyer back-average" thing, and did not get the right answers when compared to SPICE.

If you are trying to reproduce the MOSFET level 1-6 models of SPICE, then you're stuck with the Meyer formulation and its kludges.

I believe some other simulators have user-selectable alternate gate capacitance models (I think HSPICE does), but you're left to the open literature to figure out what they're doing --- and you've already seen that relying on the open literature will get you the right theory, but the arcane practice invariably has dirty little secrets under the hood.

[pepijndevos]

Ah! The line integral connection is really helpful. I remember those from Maxwell equations haha

So if I understand it correctly, if you could symbolically integrate the capacitance with respect to the voltage, that would work. But there isn't a systematic way to integrate everything so in general you can't. or can you!

The way out of this is that since a line integral in a scalar field is path independent, integrating along the path of the voltage is equivalent to just integrating over the voltage. But this can be done with numerical methods!

You could then go back and write that in differential form, and put it right in with the rest of your differential equations (if you can have access to the derivative of voltage, which you say is often not the case)

There are a few things where I'm a bit murky here. (note that while I really appreciate your answers, there are math experts at Julia Computing who actually get paid to help with math problems regarding our simulator)

Is the derivative of voltage something you fundamentally cannot have, or it just requires the correct formulation?

Where did the norm go? The normless equation obviously makes sense, just can't rhyme it with the line integral. I assume it shakes out if you do the vector math somehow.

Does this get you clear of the Riemann sum leakage? I assume that if you feed the differential form to your solver, it will adequately evaluate C*v' at the various time steps and weights of whatever integration rule is in use. Only matches ngspice for trapezoidal of course.

Since the current is the derivative of the charge, why bother integrating at all? Hrmmmmm I'm making a mistake somewhere. Obviously if you say I=Q' you get the conventional capacitor equation, without charge preservation. Somewhere along the way I lost it. I reeeeally need to sit down and work out all the math.

For a bit of context, our simulator is built on ModelingToolkit.jl which has quite a high level of abstraction where you write symbolic equations and it compiles and optimizes them. On the one hand it means I literally cannot access a value from a previous time step. On the other hand, I can just write D(v) and hope the solver can get me the time derivative of voltage.

Since it is not possible within the given framework to implement the kludge that spice uses, I have to find the closest thing I can express in symbolic differential equations, and ask the ModelingToolkit.jl people to make it work.

[tvrusso]

One other question: you mention:

When I was working on the "textbook" diode, initially I made a nonlinear charge-preserving capacitor that basically did but then found that's not at all what the diode does.

It's not clear what you mean by "that's not at all what the diode does."

Xyce's diode computes the Qd (capacitance charge) directly, and loads our "Q" vector with it, so it is doing just what you are saying you tried. (In Xyce, per the DAE formulation you quoted earlier, the Q vector is differentiated with respect to time in order to get at certain currents that are not computed directly and placed into "F"). You'll find that Cd is used only where the derivative of charge with respect to voltage is needed, and NOT to compute charge itself.

[pepijndevos]

It's because it was from following the textbook equations for Cd, and not, as we are doing now, following the spice code.

[tcaduser]

It is important to always consider the model from your book snippet that:
Qg(Vg, Vs, Vb, Vd)

and that charge must always be conserved. See from 6.2.1 (and other places):
Computer-Aided Analysis of Nonlinear Microwave Circuits by Paolo J. C. Rodrigues

Rules, like the compatibility condition, apply:
d(d Qgs / d Vg) / d Vd
must be equal to:
d(d Qgs / d Vd) / d Vg

and must be carefully considered in any model.