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

Re: Modeling and simulation



Original poster: "Jim Lux" <jimlux-at-earthlink-dot-net> 

I suppose I'll weigh in here too, since my life basically consists of
endless modeling, simulation, validation, verification, etc.


 > Original poster: Mark Broker <mbroker-at-thegeekgroup-dot-org>
 > >Original poster: "Antonio Carlos M. de Queiroz" <acmq-at-compuland-dot-com.br>
 > >Some people try to optimize circuits using simulators, instead of
 > >designing them correctly from the start. This may work, but will not
 > >teach anything, and most probably will waste a lot of time.
 > >The site mentioned says that it's frequent to see a Spice simulation
 > >that works correctly, but an actual implementation that oscillates
 > >furiously. This is indeed a common problem, because it's difficult
 > >to include in the models (specially if the user has to do it) all
 > >the parasitic elements, and something that Spice does not consider,
 > >irradiation. Other than this, there is nothing wrong with the models
 > >used in Spice, that model the physical reality quite well.


 > My views regarding circuit simulation are the same as those regarding
 > CAD/CAM and FEA: they are indeed a highly useful tool an engineer or
<snip>
 > That said, I don't recall seeing a Spice simulation of a coil that didn't
 > correlate to measurements made on the actual system....  I also feel that
 > the popular PSpice models (like the ones buried in Terry's site) are
 > generally quite accurate if proper values are used.

 > Most the active components' spice models are woefully inadequate.  I wish
I
 > could cite specifics, but I really cannot since I really don't have any
 > clue as to the internals of a SPICE model and really am just reciting what
 > I've heard from scores of far more experienced SPICE users.

Any model has limitations and assumptions; be it Ohm's law, or something a
*bit* more advanced, like SPICE and it's ilk, or HFSS,Touchstone, etc., and
their ilk.
The key is understanding the limitations and how they work in YOUR
particular situation.
SPICE, when you get right down to it, is basically Ohm's law (and the two Ki
rchoff laws).. it solves a mostly linear set of equations to determine node
voltages and loop currents. And that is the basic problem: it assumes the
circuit is linear (in the "superposition is valid" sense)!... Yes, it does
work with nonlinear components, etc. but in sort of a funny way.
For transient analysis (what most TC'ers use spice for), it essentially
simulates your circuit, using linear circuit theory, at a series of time
intervals. It's a bit fancier, because the admittance matrix can have
nonlinear terms, and it can use a fancy differential equation solver to do
the iteration, but, highly discontinuous functions, or ones that don't lend
themselves to a "nice" mathematical representation, don't work so well.
Usual practice is to run the sim at various conditions (convergence limits,
step sizes, etc.) and see if the model outputs are internally consistent
(and then check against the breadboard!)
For DC analysis, SPICE is perfect...no kidding, that's what it started as
(ECAP)
For AC analysis (where you sweep through frequencies), you're back to the
linear system model.  The various components are represented as complex
admittances/impedances, and the program solves the network equations
(linear!).. Modern versions of spice can also do some nonlinear analysis,
but at the heart, it's all linear network theory.

If you have a nonlinear device in the system (like a mixer, or a diode),
programs like spice don't work so well... The diode can be modeled as a
"switch" and a resistor for the DC and transient case. It can be modeled as
appropriate parasitic C and L and R for the AC case. It can even be modeled
as a (relatively smooth) nonlinear function of inputs in the transient case
(and the AC/DC cases, where the solver goes through multiple iterations of
the network equations until everything settles down to a steadystate
equilibrium)..

If you had infinite computational resources, you could conceivably do SPICE
like transient simulations with sufficiently fancy solvers in the time
domain to model almost anything, IF and ONLY IF, you had sufficiently
accurate models, which, in practice, do NOT exist for most RF components (or
for components of great interest to TC'ers, like spark gaps and
leaders/streamers/sparks).  We're talking about models that adequately
represent the behavior on a sub nanosecond time scale. (FDTD is starting to
get there, but is computationally intensive)

Hard core RF systems get designed with products that use so called "harmonic
balance" techniques, which explicitly account for the intermodulation and
non-linear effects, BUT, they're hardly a continuous or transient
simulation. For instance, you might model a mixer with a table that defines
the levels of all the output mixing products, relative to the input levels,
and that table might actually use some functions, or real test data.
Likewise, an amplifier model would do the same.

The problem, and it's a huge one, is that for many modern systems, neither
the SPICEish or harmonic balance techniques are sufficiently representative
for problems that need to be solved, like designing mixed mode ASICs, or
self adjusting RF amplifiers. As IC speeds increase, the simple models used
by most ASIC design codes (i.e. RC time delays between gates) just don't
hack it, and this is responsible for lots of those "oopsie" $1M respins when
the part doesn't work quite like you expected.  (Imagine what trying to
create a simple SPICE model for an original Pentium would be like.. a
million transistors, several million transmission lines, several million
capacitors and resistors, and you'd have to simulate at a time step of
something like 1-10 picoseconds)

This is a HUGE problem and literally millions of dollars are being spent by
commercial and government (DARPA is heavily into this...) to find solutions.
And, unfortunately, it's not a problem that has an easy or simple solution.


So, what do you do... you choose models that you KNOW are not totally
realistic, but that will tell you something useful. You build a breadboard,
you test it, compare the data against what the model told you, and try to
understand why it's different. Then you go back and either build a new or
different model, or you fiddle with the breadboard, and repeat...

Hey, for TCing, the simple Medhurst type approximations get you more than
close enough to build the coil, and then you can tune for effect... So
there, the simple coupled LC model is more than sufficient.

But, if you want to understand where the losses are, or why the sparks move
in a particular direction, etc... you'll need a different model.

Or, if you want to understand how a magnifier really works, and come up with
a new way to build/specify/optimize one, then the coupled oscillator models
Antonio developed are the hot ticket.

Ultimately, though, those models need to be validated, and that's why this
mailing list is full of folks who actually build the coils, rather than just
talk about it....