Spice Diode Modeling of Forward Overshoot & Reverse Recovery

Does that make you a weenie weenie? ;)

Cheers

Phil Hobbs

-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics

hobbs at electrooptical dot net

I do not have to "prove" anything to you. You are not an expert at Spice behavioral modeling. I am.

I work on the basis that my customers are happy with the models I provide, not on any basis that requires your approval.

Using terminology that you and Larkin are fond of invoking... do you think your uninformed outbursts on this topic are helping your public image ?>:-}

End of discussion. ...Jim Thompson

Sure. I care about the truth, though, and am prepared to back up what I say with actual arguments. If I'm right, some folks might learn some things, and if I'm wrong, I learn some things too. So it's a win either way.

Cheers

Phil Hobbs

All models are, by definition, incomplete representations. A key point about any modelling is being able to understand the *limits* of the model.

Encryption defeats that.

That seems so obvious to me that I'm always surprised when other people don't see things that way.

Are you primarily selling models as an end product, or IC designs, in which you use your models to be confidant of the result?

Right now my business is about 10/40/50 discrete/chip design/behavioral modeling.

The behavioral models are for customer's chip designs that they wish to keep the innards proprietary.

So they provide me with schematics and device-level netlists.

I exercise (exorcise sometimes ;-) them is PSpice and then simplify the models to behavioral components that inhibit reverse engineering.

In particular my COSH(TANH(...)) OpAmp core model is virtually a dead-on match to the device-level netlist, but totally useless to anyone attempting to reverse engineer.

I'm cultivating the behavioral modeling end of my business because it's fun (almost a puzzle-solving game ;-)... chip design, with my 55+ years of experience, has become pretty much a boring turn-the-crank exercise... I've done it all before. ...Jim Thompson

Only insecure people keep boasting about themselves. You are sounding like Obama, lots of "I"s.

And what happened to "end of discussion" ?

Why don't you mind your own business? I was responding to Win's questions? And you stuck your butt into the conversation uninvited.

As for "I"... I am the greatest >:-}

I don't know why I ever un-blacklisted you... back you go... your contributions and comments are worthless. ...Jim Thompson

I left out, in my previous answer...

I do, often, use behavioral modeling to mock up a system (SOC) and check out the desired function before converting it to device-level.

Allowed me to catch, for a recent example, a video DC restorer that clamped the sync tip to ground with a switch is NOT the way to go.

What a switch does is drops the input impedance, requiring a very low source impedance to drag the clamped signal back positive... otherwise video distortion.

The proper way is an active loop that uses a current pull-up to stop the sync tip at the desired level. ...Jim Thompson

Sigh. What a shame. For a minute there I thought you two were finally going to get along.

Phil,

Do you have any example data that illustrates the necessity of solving the transport equation exactly?

Tim

Well, JL's Grekhov diode pulser is a good one, as are normal SRDs. Even the lowly 1N914 will get charge density waves set up in it if you hit it with a fast ringy pulse, and the details of the response will depend on carrier diffusion.

If I wanted to really model photodetection accurately, I'd need to take int o account the 2-1/2 D (i.e. cylindrically symmetric) diffusion problem of c arrier transport and light absorption vs depth and wavelength. If the PD ha d only a single contact rather than a ring, it would be a full 3D problem. This matters a lot, because delay and bandwidth are functions of position, charge distribution, and lateral voltage drops.

And it all depends on the amount of reverse bias.

I've measured all those effects, but not in nearly adequate detail for mode lling.

Of course if you know the analytic solution to enough special cases, you mi ght possibly be able to cobble up something acceptably general for typical use cases. Optics and radar folks use the Geometric or Physical Theory of D iffraction (GTD/PTD), which works sort of like that. (Stealth technology is based on it, which is why the F-117A is all made of flat facets--you could simulate that on a 1970s computer.)

However, being a transport problem, carrier dynamics is way more complicate d than vanilla electromagnetics--it's more like plasma physics. It's simple r because the ions can't move, but more complicated because of traps and de fects and stuff. So doing the GTD thing would be hard.

Cheers

Phil Hobbs

Sorry, that would be a lot of work, and I'd need a sub-ns highish voltage pulse generator, which I don't have. The 1N914 isn't very interesting, and I'd never use it in a nanosecond or picosecond application.

Heck, we rarely use 1N914s at all!

Maybe I can kluge a resistor and a 1N914 onto the flipflop test rig that I have set up. It can make a 3.3 or maybe 5 volt step, apparently very fast. Barely possible.

Sure, when the pulse risetime is much slower than the recombination time, the recovery things vanish, and then LT Spice becomes accurate.

I don't think it has to be that slow--in Si carriers can diffuse a long way before recombining.

Cheers

Phil Hobbs

Particularly given the ability, in Spice, of creating a voltage-and-current-and-charge variable capacitor ?>:-}

Then Spice can solve the so-called "transport equation". ...Jim Thompson

I thought you didn't want to talk about it any more.

But you're entirely wrong once again. Any sort of capacitor--nonlinear, time varying, whatever you like--still obeys an ODE. Transport doesn't.

Cheers

Phil Hobbs

Please explain _why_ you think Spice can't solve it. Stop thinking explicit solutions... Spice is a numeric machine. ...Jim Thompson

A particular kind of numeric machine, but not a universal one, however clever a modeller you may be.

SPICE is a pretty capable solver for sparse systems of nonlinear, coupled, ordinary differential equations, and suffices for most circuit purposes as well as a large class of other problems that can be reduced to such a system.

A general system of N variables leads to an NxN matrix that has to be solved on each time step. The effort required goes as N**3, which gets old fast.

Sparse systems have many fewer nonzero elements, typically just a few near the main diagonal. For instance, FDTD codes such as my EM simulator lead to a heptadiagonal matrix (seven entries per row, corresponding to the current volume element and six nearest neighbours. That kind is pretty simple to solve, in theory, taking a few times N operations per time step. (FDTD is a bit slower because you have to shrink the time step as you refine the mesh, so it goes like N**(4/3).)

However, circuits aren't that regular, leading to sparse systems whose nonzero entries can be anywhere, but which typically have no more than five or so connections per node, which helps a lot.

Like all (or nearly all) solvers for systems like that, SPICE uses iterative methods that take more steps but avoid filling in the zero entries. These methods aren't guaranteed to converge unless the system is numerically stable and the initial guess is sufficiently close, which is why SPICE needs all that help with convergence.

It's a good tool all round, but it can only solve ODE systems unless the code is hacked up to add features (such as transmission lines).

Transport problems such as gas motion are not in general expressible as systems of ODEs. Classical nonequilibrium gas transport is governed by the Boltzmann equation (see e.g. ) which is an irreducible integrodifferential equation.

Carrier motion is more complicated because there are two kinds of carriers that move and recombine according to quantum rules, and because electric and magnetic fields are coupled to the phase space density, but it's still a set of coupled integrodifferential equations, and so can't be solved by SPICE.

The difference is basically that integrodifferential equations have a lot of internal state that ODEs don't, and they can be nonlocal in time, i.e. the result of the next step doesn't depend merely on the observables from the previous step.

For instance, a transmission line in SPICE is also an integral equation, because what comes out one end is a delayed replica of what went in the other end. You can't express that as a differential equation, because it has internal state that isn't visible at the terminals. You have to express it as a convolution integral with a shifted Dirac delta function (perhaps with a high frequency cutoff).

ODE systems have a very rich set of possible responses, so (as you know better than I) it's possible to dream up ways to mimic the behaviour of many IDEs with SPICE models in restricted situations. For instance, if you know that the transmission line will only have pulses going into it, you can use a delayed source to mimic that.

However, because these models don't correctly represent the internal state of the solutions of the transport equation, a change in conditions is very likely to make the mimicry fail. Sending charge density waves into a 1N914 by hitting it with a step with a big 2-GHz ring is an example. A model based only on the response to a clean step is unlikely to get that right, because it has no way of expressing the wave behaviour, which will have excursions in both density and momentum.

Transmission lines are sufficiently important that it's worth hacking up the solver to handle them as a special case, which fortunately is quite simple. Transport is another kettle of fish entirely.

Cheers

Phil Hobbs