开云体育

What are some good magazines or journals to watch for info on circuit
simulation, modeling, and SPICE? I can't find any publication that
seems to concentrate on these topics. For example, the IEEE Journal
of Solid State Circuits published Boyle's paper on opamp
macromodeling, but hasn't had a lot of info on the topic in recent
years. What should I be reading to keep up?

Thanks for your suggestions
Dale

On Wed, 30 Apr 2003 19:41:15 -0000, you wrote:

I tried my own math to get a new formula, because I couldn't believe
that your formula is correct.

As I said, it seemed a little strange to me, too.

Assume that your period is very long compared to the time Ton.

No need for assumptions. Let's just do the math. Back to the
example, with slightly changed names (taken from my sheet of
notes):

,-- V
|
|
/
\ R1
/
|
Rp |
PWM >---/\/\/---x
[0..Vp] |
| C
-----
-----
|
|
gnd

Some definitions are in order:

V: Arbitrary DC voltage supply
Vp: Arbitrary PWM high-side voltage (low-side assumed gnd)
toff: PWM time within cycle, at gnd
ton: PWM time within cycle, at Vp

tcyc = ton + toff
Va = (V * Rp + Vp * R1) / (R1 + Rp)
Vb = V * Rp / (R1 + Rp)
R = R1 * Rp / (R1 + Rp)
k = 1 / (R*C)

Vb - Va*e^(-k*tcyc) + (Va-Vb)*e^(-k*toff)
VnodeLO = -----------------------------------------
1 - e^(-k*tcyc)

Va - Vb*e^(-k*tcyc) + (Vb-Va)*e^(-k*ton)
VnodeHI = ----------------------------------------
1 - e^(-k*tcyc)

I think we are agreed already, up to this point. If not, let me
know.

Okay, now I want to compute the ripple (dI/I) in R1 in the above
circuit. Right?

Given:

VnodeMEAN = (VnodeHI + VnodeLO) / 2

InodeLO = (V - VnodeLO) / R1

InodeHI = (V - VnodeHI) / R1

InodeMEAN = (V - VnodeMEAN) / R1

Then:

dI/I = (InodeLO - InodeHI) / InodeMEAN

(V - VnodeLO) / R1 - (V - VnodeHI) / R1
dI/I = ---------------------------------------
(V - (VnodeHI+VnodeLO)/2) / R1

(V - VnodeLO) - (V - VnodeHI)
dI/I = -----------------------------
V - (VnodeHI+VnodeLO)/2

VnodeHI - VnodeLO
dI/I = -----------------------
V - (VnodeHI+VnodeLO)/2

2 * (VnodeHI - VnodeLO)
dI/I = -------------------------
2 * V - VnodeHI - VnodeLO

Okay, that's my definition for dI/I. Now, what I'd like to do
is to insist that this dI/I be under some threshold, as in:

dI/I <= RIPPLE

So, since I have exact expressions for VnodeHI and VnodeLO,
let's substitute those exact expressions and solve. I'll
proceed quickly, so I won't show all the work (too much typing,
frankly.) But if you disagree with any, just yell at me:

dV(R1) = VnodeHI - VnodeLO

1 + e^(-k*tcyc) - e^(-k*ton) - e^(-k*toff)
= (Va - Vb) * ------------------------------------------
1 - e^(-k*tcyc)

Also,

2*Vmean = VnodeHI + VnodeLO

(Va+Vb)*(1-e^(-k*tcyc))+(Va-Vb)*(e^(-k*toff)-e^(-k*ton))
= --------------------------------------------------------
1 - e^(-k*tcyc)

Before getting back to the dI/I equation, some short-hand might
help keep this smaller:

k0 = e^(-k*tcyc)
k1 = e^(-k*ton)
k2 = e^(-k*toff)

and since tcyc = ton + toff:

k2 = k0 / k1

So, substituting the above pieces:

1 + k0 - k1 - k0/k1
2 * (Va - Vb) * -------------------
1 - k0
dI/I = -----------------------------------------------------
(Va + Vb)*(1 - k0) + (Va - Vb)*(k0/k1 - k1)
2 * V - -------------------------------------------
1 - k0


2 * (Va - Vb) * (1 + k0 - k1 - k0/k1)
dI/I = -------------------------------------------------
(2*V - Va - Vb)*(1 - k0) - (Va - Vb)*(k0/k1 - k1)

Here's where the new twist comes in, which I didn't mention in
my earlier post. It's simply that my V is set to the same value
as my Vp. In this case, then, V = Vp = Va.

So, we have:

2 * (Va - Vb) * (1 + k0 - k1 - k0/k1)
dI/I = --------------------------------------------------
(2*Va - Va - Vb)*(1 - k0) - (Va - Vb)*(k0/k1 - k1)


2 * (Va - Vb) * (1 + k0 - k1 - k0/k1)
dI/I = -------------------------------------------
(Va - Vb)*(1 - k0) - (Va - Vb)*(k0/k1 - k1)


2 * (Va - Vb) * (1 + k0 - k1 - k0/k1)
dI/I = -------------------------------------
(Va - Vb) * (1 - k0 - k0/k1 + k1)


2 * (1 + k0 - k1 - k0/k1)
dI/I = -------------------------
(1 - k0 - k0/k1 + k1)


2 * (k1 + k0*k1 - k1^2 - k0)
dI/I = ----------------------------
k1 - k0*k1 - k0 + k1^2


2 * (k1 - 1) * (k0 - k1)
dI/I = ------------------------
(-k1 - 1) * (k0 - k1)


2 * (1 - k1)
dI/I = ------------
1 + k1

That little assumption removes a lot from here. There's no k0!!
It's gone! The solution for k1 is then this obvious result:

2 - dI/I
k1 = --------
2 + dI/I

Of course, we can now substitute for k1, again:

2 - dI/I
e^(-k*ton) = --------
2 + dI/I

Or,

ton = -(1/k) * ln((2-dI/I)/(2+dI/I))

Or...

ton = -R*C*ln((2-dI/I)/(2+dI/I))

Which was my original assertion. The PWM cycle time just
disappears.

Of course, all this assumes that V = Vp. A not-uncommon
situation.

Interesting?

Jon

On Wed, 30 Apr 2003 19:41:15 -0000, you wrote:

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

On Sun, 27 Apr 2003 00:50:31 -0000, Helmut wrote:

Hello Jon,
sorry that I forgot to tell you that I assumed 50% duty cycle. The
absolute voltage ripple is at maximum for the 50% and thus it is a
good formula for the worst case ripple estimation.

My Vp' has been your (Va-Vb).

Hi. I've played around with this on paper for a bit, this
morning. What came out is interesting, I think. Here's that
circuit, again:

,-- V
|
|
/
&#92; R1
/
|
R2 | [Vnode]
PWM >---/&#92;/&#92;/---x
|
| C1
-----
-----
|
|
gnd

I'm actually looking at the ripple across R1 as a percentage of
that voltage, ((VnodeHI-VnodeLO)/(V-VnodeMEAN)). What's
important to me isn't (VnodeHI-VnodeLO)/VnodeMEAN or the
absolute magnitude of (VnodeHI-VnodeLO).

This is because I'm playing with a design for a PWM-driven
two-quadrant current source/sink for a pin-driver. The
important element is the current through R1 and I need to
control the current noise below some arbitrary limit I set.
Things get better for me as Vnode gets closer to ground. What's
worrisome to me is what happens as I let Vnode get close to V,
since although the ripple voltage is declining some as V is
approached, the (V-VnodeMEAN) is also declining rapidly, as
well.

Your equation, which simplifies itself using the worst case
situation for dV, could be used to estimate the largest ON time
for the PWM. But it's overly aggressive for my use. It turns
out that the exact solution, using full exponentials without
approximations, yields a surprisingly simple resulting equation
which is exact, as well as simple.

If you remember, the exact form, before simplifying to yours is:

1+e^(-tcyc/(R*C))-e^(-ton/(R*C))-e^(-toff/(R*C))
dV = (Va-Vb) * ------------------------------------------------
1 - e^(-tcyc/(R*C))

If I specify a maximum RIPPLE in (dV/V) [or (dI/I), I suppose],
what I'd like to do is find the largest "ton" time, where:

RIPPLE >= dV / (V - VnodeMEAN)

It turns out that it is:

ton <= -R*C*ln((2-RIPPLE)/(2+RIPPLE))

Quite a bizarre result, when I first saw it:

It suggests that the on-time for my use is independent of the
PWM cycle time!

Hello Jon,
I tried my own math to get a new formula, because I couldn't believe
that your formula is correct.

It's remained true in my explorations. I'll send you some BASIC
code, if you'd like, which doesn't rely on my development but
uses numerical methods applied to basic principles. Neat.

I think it's a matter of talking at cross-purposes, though. I
don't have time, right now, to document my steps. But they are
on paper and I can translate them, later on today. I'll also
get a chance then to more carefully read your post and reply.
This is just a quick one to say that I've seen what you've
written.

By the way, while the ton time remains set by the unitless
ripple error and the RC time constant, independent of PWM cycle
time, the minimum current allowed is still a function of both of
these. I didn't mean to imply that.

Thanks very much for your considerations in all this and I will
get my calcs out, for you.

Until later on (perhaps three or four hours from now),
Jon

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

On Sun, 27 Apr 2003 00:50:31 -0000, Helmut wrote:

Hello Jon,
sorry that I forgot to tell you that I assumed 50% duty cycle. The
absolute voltage ripple is at maximum for the 50% and thus it is a
good formula for the worst case ripple estimation.

My Vp' has been your (Va-Vb).

Hi. I've played around with this on paper for a bit, this
morning. What came out is interesting, I think. Here's that
circuit, again:

,-- V
|
|
/
&#92; R1
/
|
R2 | [Vnode]
PWM >---/&#92;/&#92;/---x
|
| C1
-----
-----
|
|
gnd

I'm actually looking at the ripple across R1 as a percentage of
that voltage, ((VnodeHI-VnodeLO)/(V-VnodeMEAN)). What's
important to me isn't (VnodeHI-VnodeLO)/VnodeMEAN or the
absolute magnitude of (VnodeHI-VnodeLO).

This is because I'm playing with a design for a PWM-driven
two-quadrant current source/sink for a pin-driver. The
important element is the current through R1 and I need to
control the current noise below some arbitrary limit I set.
Things get better for me as Vnode gets closer to ground. What's
worrisome to me is what happens as I let Vnode get close to V,
since although the ripple voltage is declining some as V is
approached, the (V-VnodeMEAN) is also declining rapidly, as
well.

Your equation, which simplifies itself using the worst case
situation for dV, could be used to estimate the largest ON time
for the PWM. But it's overly aggressive for my use. It turns
out that the exact solution, using full exponentials without
approximations, yields a surprisingly simple resulting equation
which is exact, as well as simple.

If you remember, the exact form, before simplifying to yours is:

1+e^(-tcyc/(R*C))-e^(-ton/(R*C))-e^(-toff/(R*C))
dV = (Va-Vb) * ------------------------------------------------
1 - e^(-tcyc/(R*C))

If I specify a maximum RIPPLE in (dV/V) [or (dI/I), I suppose],
what I'd like to do is find the largest "ton" time, where:

RIPPLE >= dV / (V - VnodeMEAN)

It turns out that it is:

ton <= -R*C*ln((2-RIPPLE)/(2+RIPPLE))

Quite a bizarre result, when I first saw it:

It suggests that the on-time for my use is independent of the
PWM cycle time!

Hello Jon,
I tried my own math to get a new formula, because I couldn't believe
that your formula is correct.

Assume that your period is very long compared to the time Ton.
The capacitor will be charged to a voltage of
dV=Ton*Vp*(R1/(R1+R2)/(R1*R2/(R1+R2)*C) = Ton*Vp/(R2*C). Now assume a
very long period so that the capacitor will be discharged totally.
I believe this is the worst case.
The voltage dV is then the total ripple voltage too. Let's further
assume the mean voltage drop V1 on R1: V1 = V*R1/(R1+R2).
This is because I assumed a Ton/Tcyc << 1 is worst case.

So we get:
RIPPLE = dv/V1 = Ton*Vp/(R2*C) / (V*R1/(R1+R2))

RIPPLE = Vp/V * Ton/(R*C)

Ton = R*C * RIPPLE * V/Vp
-------------------------
or
Ton <= R*C * RIPPLE * V/Vp as the upper limit

Example: R*C=1ms Ripple=0.01 Vp=14, V=5
Ton < 0.001*0.01*5/14 = 3.6us


Some comment to your formula:
Ton = 1ms*0.01 = 10us

My simulation shows that my 3.6us are correct. So your formula
seems to be wrong.

Anyway it was a nice exercise for me and still a surprising result.
I always check formulas with simulations/numerical calculations.

Best Regards
Helmut

On Sun, 27 Apr 2003 00:50:31 -0000, Helmut wrote:

Hello Jon,
sorry that I forgot to tell you that I assumed 50% duty cycle. The
absolute voltage ripple is at maximum for the 50% and thus it is a
good formula for the worst case ripple estimation.

My Vp' has been your (Va-Vb).

Hi. I've played around with this on paper for a bit, this
morning. What came out is interesting, I think. Here's that
circuit, again:

,-- V
|
|
/
&#92; R1
/
|
R2 | [Vnode]
PWM >---/&#92;/&#92;/---x
|
| C1
-----
-----
|
|
gnd

I'm actually looking at the ripple across R1 as a percentage of
that voltage, ((VnodeHI-VnodeLO)/(V-VnodeMEAN)). What's
important to me isn't (VnodeHI-VnodeLO)/VnodeMEAN or the
absolute magnitude of (VnodeHI-VnodeLO).

This is because I'm playing with a design for a PWM-driven
two-quadrant current source/sink for a pin-driver. The
important element is the current through R1 and I need to
control the current noise below some arbitrary limit I set.
Things get better for me as Vnode gets closer to ground. What's
worrisome to me is what happens as I let Vnode get close to V,
since although the ripple voltage is declining some as V is
approached, the (V-VnodeMEAN) is also declining rapidly, as
well.

Your equation, which simplifies itself using the worst case
situation for dV, could be used to estimate the largest ON time
for the PWM. But it's overly aggressive for my use. It turns
out that the exact solution, using full exponentials without
approximations, yields a surprisingly simple resulting equation
which is exact, as well as simple.

If you remember, the exact form, before simplifying to yours is:

1+e^(-tcyc/(R*C))-e^(-ton/(R*C))-e^(-toff/(R*C))
dV = (Va-Vb) * ------------------------------------------------
1 - e^(-tcyc/(R*C))

If I specify a maximum RIPPLE in (dV/V) [or (dI/I), I suppose],
what I'd like to do is find the largest "ton" time, where:

RIPPLE >= dV / (V - VnodeMEAN)

It turns out that it is:

ton <= -R*C*ln((2-RIPPLE)/(2+RIPPLE))

Quite a bizarre result, when I first saw it:

It suggests that the on-time for my use is independent of the
PWM cycle time!

What?? Yes! For my needs, my limit on ripple amounts to
specifying the longest possible on-time for the PWM, whatever
the PWM period might be. This is true, as calculations appear
to bear out. A shorter PWM period simply means that my ripple
requirement will always be met, no matter the duty cycle. A
longer PWM period means I need to be careful not to exceed this
on-time. Frankly, I have to admit that my intuition didn't tell
me this result, beforehand.

Anyway, there it is. If you want to, see if you can derive this
same result or else tell me why it should have been obvious to
me without the math involved. I'd be happy to learn new
intuitive viewpoints -- I'm still working this through my mind,
this morning, and I expect at some point I'll see the "Ah, so
that's why." But I wouldn't mind getting that point sooner, if
you can point out the obvious path for me. (I'll also show my
math work, if you'd like.)

Jon

The "Edit Simulation Command" dialog box says:

"Maximun Timestep:"

where it should say:

"Maximum Timestep:"

Jon

Thanks for the help on the Table format. It is nice to get this kind
of help and support.

On Sun, 27 Apr 2003 00:50:31 -0000, you wrote:

sorry that I forgot to tell you that I assumed 50% duty cycle. The
absolute voltage ripple is at maximum for the 50% and thus it is a
good formula for the worst case ripple estimation.

My Vp' has been your (Va-Vb).

Well, it all makes sense and it feels nice when everything goes
together neatly and well. Probably all of this should go onto a
web page or two, somewhere, with all the supporting work shown
for those who are interested in the derivations.

Jon

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

On Sat, 26 Apr 2003 22:18:02 -0000, you wrote:

....
Since Tau=R*C and tcyc=Tpwm, this turns into:

dV = (1/4) * (Va - Vb) * Tpwm / Tau

Which looks a heck of a lot like your:

Vpp = 0.25 * Vp' * Tpwm / Tau

However, this makes explicit and clear that there is one more
assumption playing into this, than just Tau >> Tpwm; namely,
that it also assumes that ton=toff and thus that the PWM duty
cycle is 50%. Which is an "average assumption."

Hello Jon,
sorry that I forgot to tell you that I assumed 50% duty cycle. The
absolute voltage ripple is at maximum for the 50% and thus it is a
good formula for the worst case ripple estimation.

My Vp' has been your (Va-Vb).

Best Reagrds
Helmut

On Sat, 26 Apr 2003 22:18:02 -0000, you wrote:

I have tried your 1ps too. It's really wrong with
.tran 0.1 for example.

It is simulated correctly, if you specify a minimum step size like
.tran 0 0.1 0 1u .

Yes, I see. Thanks. So it's just a matter of "being too dumb"
about what's been specified. It's up to me to tinker a little.
Small price to pay.

------------------------------------------------------------------
By the way, I have a nice approximation formula for the PWM ripple
voltage:

Vpp = 0.25 * Vp' * Tpwm / Tau

Vp' = Voltage pulse at the output without capacitor(C=0) and with
zero bias voltage(V=0V). Vp' = Vp * R1/(R1+R2)
Tau = C * (R1*R2)/(R1+R2)
Tpwm = period of the PWM

My RC is your tau and my tcyc is your Tpwm. I'm not quite sure
what your Vp' is, though. Is it my Va or my Vb or something
else?

But here's my derivation. Let's see...

1+e^(-tcyc/(R*C))-e^(-ton/(R*C))-e^(-toff/(R*C))
dV = (Va-Vb) * ------------------------------------------------
1 - e^(-tcyc/(R*C))

Using Taylor's for a first-order estimate, it comes out to:

dV = (Va - Vb) * 0

Which definitely isn't right, so taking it out to the next order
of Taylor's yields:

tcyc^2 - ton^2 - toff^2
dV = (Va - Vb) * -----------------------
tcyc * (tcyc + 2*R*C)

Which seems pretty darned close to right.

Ah!! Now it dawns on me! Your Vp' is my (Va - Vb)! Here's
why:

Looking at the above 2nd-order Taylor's estimate, the
denominator has the factor, (tcyc + 2*R*C). But since we are
assuming that RC >> tcyc, which should be true if we are doing
our job in filtering, then (tcyc + 2*R*C) is about 2*R*C. No
point bothering to add in a disappearing tcyc, so just drop it.
That leaves us with:

tcyc^2 - ton^2 - toff^2
dV = (Va - Vb) * -----------------------
tcyc * 2*R*C

so,

| tcyc ton ton toff toff |
dV = (Va - Vb) * | ---- - ---- * --- - ---- * ---- |
| 2RC tcyc 2RC tcyc 2RC |

Still a little messy, but let's assume that ton is about 1/2 of
tcyc (and so is toff, then.) In this case, it becomes:

| tcyc 1 1/2*tcyc 1 1/2*tcyc |
dV = (Va - Vb) * | ---- - --- * -------- - --- * -------- |
| 2RC 2 2RC 2 2RC |

so,

| tcyc 1 tcyc |
dV = (Va - Vb) * | ---- - --- * ---- |
| 2RC 2 2RC |

or,

| 1 tcyc | 1 tcyc
dV = (Va - Vb) * | --- * ---- | = --- * (Va - Vb) * ----
| 2 2RC | 4 R*C

or,

dV = (Va - Vb) * tcyc / (4*R*C)

Since Tau=R*C and tcyc=Tpwm, this turns into:

dV = (1/4) * (Va - Vb) * Tpwm / Tau

Which looks a heck of a lot like your:

Vpp = 0.25 * Vp' * Tpwm / Tau

However, this makes explicit and clear that there is one more
assumption playing into this, than just Tau >> Tpwm; namely,
that it also assumes that ton=toff and thus that the PWM duty
cycle is 50%. Which is an "average assumption."

Thanks, again!

Jon

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

On Sat, 26 Apr 2003 21:18:05 -0000, you wrote:

Hello Jon,
please take a look(pobe) at your pulse source in LTSPICE.
If you specify tr=0 and tf=0, then LTSPICE takes a guess about
the rise and fall time of 10% or something like that.

10%!! Egads. Okay. I see it! Thanks.

The effective duty cycle in SPICE is always
d = ((trise+tfall)/2 + twidth)/Tperiod
You assumed only twidth/Tperiod .
Now it's obvious that the average voltage is different, because of
the definitions.

Okay. I can see the issues much more clearly, now.

1. Approach:
If you specify a very small tr and tf of 1ns, then the difference
between both definitions will be very small.

Interesting. I used 1ns and it's much better. Thanks, again.

I also tried dropping in 1ps, 10ps, and 100ps. What a disaster!
The simulation made a total mess of the pulse voltage. I can't
even explain it, but it is definitely wrong. 1ns works. But
that's about it. Is there some threshold here?

Anyway, with 1ns, it leave me within a margin of error I can
tolerate: 1.751mV p-p vs a calculated 1.750mV p-p, which is
fine. It's shifted off by a DC error of 140uV, but that's
probably due to the remaining rise and fall times. ... Ah, yes.
Using t_on of (25us-1ns) and a period of 50us puts it right on
the mark.

Okay. I think I've got the picture, now.

I've got to keep all these details in mind.

2. Approach:
The other possibility is to use a new width value of
T_width_spice = T_width - (t_tise + t_fall)/2

Width specification in SPICE:
____________
/ &#92;
/ &#92;
______/ &#92;________

| |<-- Tw----->| |
Tr Tf
|<---- Tper ---->|


My advice for LTSPICE:
Never specify 0 for tr and tf in LTSPICE. At least use something

very

low compared to your width if you want to neglect it.

Yes. That's what I did and it looks pretty good.

I still wonder about why 1-100ps causes it to go crazy. But
whatever the reason, that must be why LT Spice doesn't accept
true square edges being applied. I need to read more about the
details of the calculations used.

Hello John,
I have tried your 1ps too. It's really wrong with
.tran 0.1 for example.

It is simulated correctly, if you specify a minimum step size like
.tran 0 0.1 0 1u .


------------------------------------------------------------------
By the way, I have a nice approximation formula for the PWM ripple
voltage:

Vpp = 0.25 * Vp' * Tpwm / Tau

Vp' = Voltage pulse at the output without capacitor(C=0) and with
zero bias voltage(V=0V). Vp' = Vp * R1/(R1+R2)
Tau = C * (R1*R2)/(R1+R2)
Tpwm = period of the PWM

Best Regards
Helmut

On Sat, 26 Apr 2003 21:18:05 -0000, you wrote:

Hello Jon,
please take a look(pobe) at your pulse source in LTSPICE.
If you specify tr=0 and tf=0, then LTSPICE takes a guess about
the rise and fall time of 10% or something like that.

10%!! Egads. Okay. I see it! Thanks.

The effective duty cycle in SPICE is always
d = ((trise+tfall)/2 + twidth)/Tperiod
You assumed only twidth/Tperiod .
Now it's obvious that the average voltage is different, because of
the definitions.

Okay. I can see the issues much more clearly, now.

1. Approach:
If you specify a very small tr and tf of 1ns, then the difference
between both definitions will be very small.

Interesting. I used 1ns and it's much better. Thanks, again.

I also tried dropping in 1ps, 10ps, and 100ps. What a disaster!
The simulation made a total mess of the pulse voltage. I can't
even explain it, but it is definitely wrong. 1ns works. But
that's about it. Is there some threshold here?

Anyway, with 1ns, it leave me within a margin of error I can
tolerate: 1.751mV p-p vs a calculated 1.750mV p-p, which is
fine. It's shifted off by a DC error of 140uV, but that's
probably due to the remaining rise and fall times. ... Ah, yes.
Using t_on of (25us-1ns) and a period of 50us puts it right on
the mark.

Okay. I think I've got the picture, now.

I've got to keep all these details in mind.

2. Approach:
The other possibility is to use a new width value of
T_width_spice = T_width - (t_tise + t_fall)/2

Width specification in SPICE:
____________
/ &#92;
/ &#92;
______/ &#92;________

| |<-- Tw----->| |
Tr Tf
|<---- Tper ---->|


My advice for LTSPICE:
Never specify 0 for tr and tf in LTSPICE. At least use something very
low compared to your width if you want to neglect it.

Yes. That's what I did and it looks pretty good.

I still wonder about why 1-100ps causes it to go crazy. But
whatever the reason, that must be why LT Spice doesn't accept
true square edges being applied. I need to read more about the
details of the calculations used.

Much thanks to you!!!

Jon

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

I've been just a little pensive about LT Spice accuracy. So
today I sat down with some paper and a relatively simple problem
and worked through some derivations to test LT Spice.

....

So I decided to try this out with a very simple circuit, setting
R1 and R2 to 10k and C1 to 10uF. I selected V=5V and Vp=14V.
This simply means a 5V rail with a PWM which oscillates between
0 and 14V. ton=25us and toff=25us should make this very easy to
estimate. The resulting two cases look like this:

,-- 5 ,-- 5
| |
| |
/ R1 / R1
&#92; 10k &#92; 10k
/ /
| |
R2 | [Vnode] | [Vnode]
14V >---/&#92;/&#92;/---x ,----x
10k | | |
| C1 | | C1
----- / -----
----- R2 &#92; -----
| 10uF 10k / | 10uF
| | |
gnd gnd gnd

CASE 1 CASE 2



I ran this circuit for 1 second and examined the simulation
output for the voltage node. I get a sawtooth, as expected, but
the peak and valleys are at approximately:

VnodeLO = 6.3492
VnodeHI = 6.3508

With an average of 6.35V.

This is 350mV above where I calculate it should be. Can anyone
give me a clue about why so much a difference, here??

Hello Jon,
please take a look(pobe) at your pulse source in LTSPICE.
If you specify tr=0 and tf=0, then LTSPICE takes a guess about
the rise and fall time of 10% or something like that.
The effective duty cycle in SPICE is always
d = ((trise+tfall)/2 + twidth)/Tperiod
You assumed only twidth/Tperiod .
Now it's obvious that the average voltage is different, because of
the definitions.

1. Approach:
If you specify a very small tr and tf of 1ns, then the difference
between both definitions will be very small.

2. Approach:
The other possibility is to use a new width value of
T_width_spice = T_width - (t_tise + t_fall)/2

Width specification in SPICE:
____________
/ &#92;
/ &#92;
______/ &#92;________

| |<-- Tw----->| |
Tr Tf
|<---- Tper ---->|


My advice for LTSPICE:
Never specify 0 for tr and tf in LTSPICE. At least use something very
low compared to your width if you want to neglect it.

Best Regards
Helmut

I've been just a little pensive about LT Spice accuracy. So
today I sat down with some paper and a relatively simple problem
and worked through some derivations to test LT Spice.

Assume the following circuit (I'm including a short LT Spice
.ASC file at the end of this post, if desired.):

,-- V
|
|
/
&#92; R1
/
|
R2 | [Vnode]
PWM >---/&#92;/&#92;/---x
|
| C1
-----
-----
|
|
gnd


The PWM input is a square wave with given period, duty time, and
voltage. The voltage of this PWM swings from 0V to some other,
specified voltage (not necessarily the same as V on the
diagram.)

Given sufficient time, the voltage at Vnode should establish
itself as some stable point, where the rise and fall in voltage
are equal to each other. If you were to look at Vnode with an
oscilliscope (with the right component values, of course), you
should see a small-swing sawtooth, roughly, resting on a stable
bias voltage. I was interested in solving that and seeing if LT
Spice would hit it, dead on.

----------------
MATH DEVELOPMENT
----------------

Skip this, if you want to just get to the point. But I wanted
to develop the mathematics here, in case there was any question
about it.

First off, modeling this breaks down into two states for the
circuit:

,-- V ,-- V
| |
| |
/ /
&#92; R1 &#92; R1
/ /
| |
R2 | [Vnode] | [Vnode]
Vp >---/&#92;/&#92;/---x ,----x
| | |
| C1 | | C1
----- / -----
----- R2 &#92; -----
| / |
| | |
gnd gnd gnd

CASE 1 CASE 2

In case 1, the Thevenin voltage and resistance is:

Va = (V * R2 + Vp * R1) / (R1 + R2)
Ra = R1 * R2 / (R1 + R2)

In case 2, the Thevenin voltage and resistance is:

Vb = V * R2 / (R1 + R2)
Rb = R1 * R2 / (R1 + R2)

Note that Ra is always equal to Rb, so let's just call them R,
instead.

R = Ra = Rb

and for convenience,

C = C1

Both cases are analyzed similarly. There is a voltage at Vnode
at the start of the time period, which decays away, and the
Thevenin voltage towards which the node rises, also on an
exponential. Intuitively, this is the sum of two exponentials,
but the derivation is worth doing, as a verification of
intuition.

I(C) = -I(R) = (V - Vnode) / R = C * dVnode / dt

Solving this, yields:

Vnode = V * (1 + k * e^(-t/RC))

where k is a constant of integration. We know that at t=0, that
Vnode is equal to the initial capacitor voltage, which I'll call
Vstart. Knowing this, we can solve for k, as:

k = (Vstart / V) - 1

Putting k back in, gives:

Vnode = V * (1 - e^(-t/RC)) + Vstart * e^(-t/RC)

This is exactly as expected. The sum of two exponentials, one
describing the disappearing Vstart and the other describing the
rise towards the new V. Eventually, all memory of Vstart is
lost and V is fully memorized, so to speak.

Okay, this gives us a tiny picture of the change for some small
value of t, and for either case 1 or case 2. However, I need to
put all this together in order to find out when the sum of those
two exponentials in case 1 balances with the sum of those two in
case 2. That's when the voltage goes up exactly the same amount
as it later goes down (or the reverse view, if you like.)

Anyway, here's how I approached that. Let's look at the two
time periods of the square wave:
_____ _____ .... Vp
| | | |
_____| |__________| |_________.... 0

^ ^ ^
: : :
: ton : toff :

We'll also set:

tcyc = ton + toff

During toff, the voltage at Vnode follows this:

Vend = Vb*(1 - e^(-toff/(R*C)) + Vstart1*e^(-toff/(R*C))

But to get Vstart1, we need to examine what happens during ton,
so:

Vstart1 = Va*(1 - e^(-ton/(R*C)) + Vstart*e^(-ton/(R*C))

Now, in the static case:

Vend = Vstart

So solving the above pair of equations with that equality for
Vstart, yields:

Vb - Va*e^(-tcyc/(R*C)) + (Va-Vb)*e^(-toff/(R*C))
Vstart = -------------------------------------------------
1 - e^(-tcyc/(R*C))

I just call Vstart here, VnodeLO. That differentiates the term
from VnodeHI, which is the peak reached at the end of ton.

So here are the two equations which describe these two voltages:

Vb - Va*e^(-tcyc/(R*C)) + (Va-Vb)*e^(-toff/(R*C))
VnodeLO = -------------------------------------------------
1 - e^(-tcyc/(R*C))

and

Va - Vb*e^(-tcyc/(R*C)) + (Vb-Va)*e^(-ton/(R*C))
VnodeHI = ------------------------------------------------
1 - e^(-tcyc/(R*C))

Or, if you already know VnodeLO, VnodeHI can be computed as:

VnodeHI = Va*(1 - e^(-ton/(R*C))) + VnodeLO*e^(-ton/(R*C))

Okay, so much for the mathematical treatments...

--------------------
END MATH DEVELOPMENT
--------------------

Given these definitions:

V: Arbitrary DC voltage supply
Vp: Arbitrary PWM high-side voltage (low-side assumed gnd)
toff: PWM time within cycle, at gnd
ton: PWM time within cycle, at Vp

And these useful defined quantities:

tcyc = ton + toff
Va = (V * R2 + Vp * R1) / (R1 + R2)
Vb = V * R2 / (R1 + R2)
Ra = R1 * R2 / (R1 + R2)
Rb = R1 * R2 / (R1 + R2)
R = Ra = Rb
C = C1

I can compute these quantities:

Vb - Va*e^(-tcyc/(R*C)) + (Va-Vb)*e^(-toff/(R*C))
VnodeLO = -------------------------------------------------
1 - e^(-tcyc/(R*C))

Va - Vb*e^(-tcyc/(R*C)) + (Vb-Va)*e^(-ton/(R*C))
VnodeHI = ------------------------------------------------
1 - e^(-tcyc/(R*C))

That should give me exact values, once the circuit settles down.

...

So I decided to try this out with a very simple circuit, setting
R1 and R2 to 10k and C1 to 10uF. I selected V=5V and Vp=14V.
This simply means a 5V rail with a PWM which oscillates between
0 and 14V. ton=25us and toff=25us should make this very easy to
estimate. The resulting two cases look like this:

,-- 5 ,-- 5
| |
| |
/ R1 / R1
&#92; 10k &#92; 10k
/ /
| |
R2 | [Vnode] | [Vnode]
14V >---/&#92;/&#92;/---x ,----x
10k | | |
| C1 | | C1
----- / -----
----- R2 &#92; -----
| 10uF 10k / | 10uF
| | |
gnd gnd gnd

CASE 1 CASE 2


The Thevenin equivalents are:

||
Case 1: +9.5V ----/&#92;/&#92;/-----||-------- 0V
5k || 10uF

and

||
Case 2: +2.5V ----/&#92;/&#92;/-----||-------- 0V
5k || 10uF

In other words, toggling between 2.5V and 9.5V for equal times
through equal Thevenin resistances, to the same capacitance.
I'd guess that the resulting voltage should be (9.5+2.5)/2 or 6V
exactly. I'd guess that, without much math, at all.

So let's do all that hard, complex, exponential math I developed
and see where it takes us:

V = 5V
Vp = 14V
toff = 25us
ton = 25us
tcyc = ton + toff = 50us
Va = (V * R2 + Vp * R1) / (R1 + R2) = 9.5V
Vb = V * R2 / (R1 + R2) = 2.5V
Ra = R1 * R2 / (R1 + R2) = 5k ohm
Rb = R1 * R2 / (R1 + R2) = 5k ohm
R = Ra = Rb = 5k ohm
C = C1 = 10uF
R*C = 50 ms


2.5 - 9.5*e^(-50us/50ms) + (9.5-2.5)*e^(-25us/50ms)
VnodeLO = ---------------------------------------------------
1 - e^(-50us/50ms)

= 5.999125003


9.5 - 2.5*e^(-50us/50ms) + (2.5-9.5)*e^(-25us/50ms)
VnodeHI = ---------------------------------------------------
1 - e^(-50us/50ms)

= 6.000874997

The average of these is exactly 6V. What a surprise!!! This
also suggests, of course, that the ripple will have a peak to
peak of 1.75mV.

Okay. Sounds good. Theory seems to all hang together. I
haven't built this, but I decided to see what LT Spice would
tell me about it. (Circuit's .ASC is given at the end of this
post.)

I ran this circuit for 1 second and examined the simulation
output for the voltage node. I get a sawtooth, as expected, but
the peak and valleys are at approximately:

VnodeLO = 6.3492
VnodeHI = 6.3508

With an average of 6.35V.

This is 350mV above where I calculate it should be. Can anyone
give me a clue about why so much a difference, here??

It's bugging me, a lot.

Jon


----------EXAMPLE CIRCUIT---------
Version 4
SHEET 1 1328 680
WIRE 288 288 112 288
WIRE 112 288 112 224
WIRE 112 288 112 384
WIRE 112 448 112 544
WIRE -224 416 -224 512
WIRE 544 528 544 448
WIRE 368 288 544 288
WIRE 544 288 544 368
WIRE -224 336 -224 240
WIRE 112 144 112 32
FLAG 112 544 0
FLAG 544 528 0
FLAG -224 512 0
FLAG -224 240 Vcc
FLAG 112 32 Vcc
SYMBOL res 96 128 R0
SYMATTR InstName R1
SYMATTR Value 10k
SYMBOL res 384 272 R90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R2
SYMATTR Value 10k
SYMBOL cap 96 384 R0
SYMATTR InstName C1
SYMATTR Value 10?
SYMATTR SpiceLine Rser=0 Lser=0 Rpar=0 Cpar=0
SYMBOL voltage 544 352 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value PULSE(0 {Vp} 100u 0 0 {tcyc-toff} {tcyc})
SYMBOL voltage -224 320 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V2
SYMATTR Value {V}
TEXT -258 568 Left 0 !.tran 1
TEXT 240 -88 Left 0 !.param V=5
TEXT 240 -56 Left 0 !.param Vp = 14
TEXT 240 -24 Left 0 !.param tcyc = 50u
TEXT 240 8 Left 0 !.param toff = 25u
-----------END----------------

--- In LTspice@..., "Steve Kunkle" <stevekunkle@y...>
wrote:

I am trying to use the TABLE form to define an Arbitrary Current
Source (B). I have done it in other Spices but just can't seem to
get the syntax right in LTSpice. Does anyone have the correct
syntax or an example for using TABLE with an arbitrary source in
LTSpice?

Hello Steve,
I have tested two examples for you.

Bv-source:

V=1+Table(V(x)-2, -2, 4, -1.5, 2.25, -1, 1, -0.5, 0.25, 0,0, 0.5,
0.25, 1, 1, 1.5, 2.25, 2, 4)

Bi-source:

I=1+Table(-I(B0)-2, -2, 4, -1.5, 2.25, -1, 1, -0.5, 0.25, 0,0, 0.5,
0.25, 1, 1, 1.5, 2.25, 2, 4)


Syntax:
V = Table(x_axis, x0,y0, x1,y1, x2,y2, ...xn,yn)


Have fun.

Best Regards
Helmut



The test file:
Please repair the lines crippled by the Yahoo e-mail program.

Version 4
SHEET 1 1216 680
WIRE -192 208 -192 240
WIRE 144 208 144 256
WIRE -192 128 -192 96
WIRE -192 96 -48 96
WIRE 144 128 144 96
WIRE 144 96 208 96
WIRE -48 128 -48 96
WIRE -48 208 -48 240
WIRE -48 240 -192 240
WIRE -192 240 -192 256
WIRE 144 384 144 352
WIRE 144 352 16 352
WIRE 16 352 16 384
WIRE 16 464 16 512
WIRE 16 512 144 512
WIRE 144 512 144 464
WIRE 16 544 16 512
FLAG 144 256 0
FLAG -192 256 0
FLAG 208 96 y
FLAG -192 96 x
FLAG 16 544 0
FLAG 144 352 z
SYMBOL bv 144 112 R0
SYMATTR InstName B1
SYMATTR Value V=1+Table(V(x)-2, -2, 4, -1.5, 2.25, -1, 1, -0.5, 0.25,
0,0, 0.5, 0.25, 1, 1, 1.5, 2.25, 2, 4)
SYMBOL bv -192 112 R0
SYMATTR InstName B0
SYMATTR Value V=time
SYMBOL res -64 112 R0
SYMATTR InstName R1
SYMATTR Value 1
SYMBOL bi 144 384 R0
SYMATTR InstName B2
SYMATTR Value I=1+Table(-I(B0)-2, -2, 4, -1.5, 2.25, -1, 1, -0.5,
0.25, 0,0, 0.5, 0.25, 1, 1, 1.5, 2.25, 2, 4)
SYMBOL res 0 368 R0
SYMATTR InstName R2
SYMATTR Value 1
TEXT -192 32 Left 0 !.tran 4
TEXT -184 -32 Left 0 ;B source and table syntax.

Steve,

I am trying to use the TABLE form to define an Arbitrary Current
Source (B). I have done it in other Spices but just can't seem to
get the syntax right in LTSpice. Does anyone have the correct
syntax or an example for using TABLE with an arbitrary source in
LTSpice?

Look-up tables can also be used in B-sources,
G-sources, and I-sources in addition to being
able to follow the usual syntax of PSpice.

Attached is and example circuit.

--Mike

--- table.asc ---

Version 4
SHEET 1 1160 680
WIRE -144 304 -144 272
WIRE -144 192 -144 144
WIRE -144 144 -272 144
WIRE -272 144 -272 192
WIRE -272 272 -272 304
WIRE 384 144 384 176
WIRE 384 256 384 304
WIRE 816 240 816 208
WIRE 816 128 816 96
WIRE 816 96 992 96
WIRE 992 96 992 128
WIRE 752 192 768 192
WIRE 768 144 384 144
WIRE 992 208 992 240
WIRE 176 304 176 256
WIRE 176 176 176 144
WIRE 176 144 384 144
FLAG -272 304 0
FLAG -144 304 0
FLAG 384 304 0
FLAG 384 144 X
FLAG 992 240 0
FLAG 816 240 0
FLAG 752 192 0
FLAG 176 304 0
SYMBOL bi2 -144 192 R0
SYMATTR InstName B1
SYMATTR Value I=table(V(x),0,0,1,1)
SYMBOL res -288 176 R0
SYMATTR InstName R1
SYMATTR Value 1
SYMBOL voltage 384 160 R0
SYMATTR InstName V1
SYMATTR Value pulse(-2 2 0 .5m .5m 0 1m)
SYMBOL g 816 112 R0
WINDOW 0 11 6 Left 0
WINDOW 3 8 102 Left 0
SYMATTR InstName G1
SYMATTR Value table(0,0,1,1)
SYMBOL res 976 112 R0
SYMATTR InstName R2
SYMATTR Value 1
SYMBOL current 176 176 R0
SYMATTR InstName I1
SYMATTR Value table(0,0,1,1)
TEXT 120 456 Left 0 !.tran 3m

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo

On Thu, 24 Apr 2003 20:43:51 -0000, you wrote:

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

I just happened upon a Greek site which had what appears to be a
complete set of PSPICE .LIB files for a 1998 version of ORCAD.
These appear to be in a compatible format for LT Spice. For
example:

.model Q2N2222 NPN(Is=14.34f Xti=3 Eg=1.11 Vaf=74.03 Bf=255.9
+ Ne=1.307 Ise=14.34f Ikf=.2847 Xtb=1.5 Br=6.092 Nc=2 Isc=0
+ Ikr=0 Rc=1 Cjc=7.306p Mjc=.3416 Vjc=.75 Fc=.5 Cje=22.01p
+ Mje=.377 Vje=.75 Tr=46.91n Tf=411.1p Itf=.6 Vtf=1.7 Xtf=3
+ Rb=10)
* National pid=19 case=TO18
* 88-09-07 bam creation

Are there any caveats for me to consider in simply importing the
bipolar and jbipolar libs, lock-stock-and-barrel, into
standard.bjt, for example? (Other than the fact that LT Spice
updates may replace some on the next update, if the names match
up.)

There are several thousand BJT models, alone. So, for example,
what will happen to LT Spice's BJT model list when I try and
designate an NPN or PNP on a schematic? Will the sheer number
(approx 1000 each) of these overwhelm memory in the dialog box?

Hello Jon,
there is a very easy way to use parts from any library file.
Just add a line like .include bipolar.lib to your schematic.

Yes, I've done that before. But I enjoy having a nice list to
examine when I right-click on a PNP or NPN, for example. I
don't get that with a .include. Instead, I have to keep a
separated print out of the .LIB somewhere and examine it or else
call up a separate editor and look at the file, when I'm curious
about making a selection.

Now you can edit/use any of the transistor models from this file
within your schematic.

Yes.

After you have placed the generic NPN transistor, you have to
change the value NPN of this transistor to the type you want,
e.g. Q2N1613.

Right. But when I'm not sure of which I want and would like to
examine some factors such as comparing Br and Bf, for example,
and make a choice based on what I see... well, it's just not
there if I use .include. On the other hand, if they are in
standard.bjt, then LT Spice compiles the list for me and
presents it for my perusal. I like operating that way, though
I'd like to sort on things like Bf, for example.

The library file has to be either in the directory of the
schematic or in the folder SWCADIII&#92;lib&#92;sub .

Yes, I've been dumping my .LIBs in .&#92;sub.

It is very convenient to manage the usage of libraries this way.

It is, though sometimes I'm not sure who's library is who's,
that way. Would be nice to have an editable LIB path.

If you extend the .include name.lib to let's say
.include Private&#92;name.lib you have to store the library file in
the directory SWCADIII&#92;lib&#92;sub&#92;Private .

Yes, I've tried that and have decided to start organizing the
.LIBs I have that way. Still, would be nice to have a LIB=
path.

Thanks,
Jon

--- In LTspice@..., Jonathan Kirwan <jkirwan@e...> wrote:

I just happened upon a Greek site which had what appears to be a
complete set of PSPICE .LIB files for a 1998 version of ORCAD.
These appear to be in a compatible format for LT Spice. For
example:

.model Q2N2222 NPN(Is=14.34f Xti=3 Eg=1.11 Vaf=74.03 Bf=255.9
+ Ne=1.307 Ise=14.34f Ikf=.2847 Xtb=1.5 Br=6.092 Nc=2 Isc=0
+ Ikr=0 Rc=1 Cjc=7.306p Mjc=.3416 Vjc=.75 Fc=.5 Cje=22.01p
+ Mje=.377 Vje=.75 Tr=46.91n Tf=411.1p Itf=.6 Vtf=1.7 Xtf=3
+ Rb=10)
* National pid=19 case=TO18
* 88-09-07 bam creation

Are there any caveats for me to consider in simply importing the
bipolar and jbipolar libs, lock-stock-and-barrel, into
standard.bjt, for example? (Other than the fact that LT Spice
updates may replace some on the next update, if the names match
up.)

There are several thousand BJT models, alone. So, for example,
what will happen to LT Spice's BJT model list when I try and
designate an NPN or PNP on a schematic? Will the sheer number
(approx 1000 each) of these overwhelm memory in the dialog box?

Hello Jon,
there is a very easy way to use parts from any library file.
Just add a line like .include bipolar.lib to your schematic.
Now you can edit/use any of the transistor models from this file
within your schematic. After you have placed the generic NPN
transistor, you have to change the value NPN of this transistor to
the type you want, e.g. Q2N1613. The library file has to be either in
the directory of the schematic or in the folder SWCADIII&#92;lib&#92;sub .
It is very convenient to manage the usage of libraries this way.
If you extend the .include name.lib to let's say
.include Private&#92;name.lib you have to store the library file in
the directory SWCADIII&#92;lib&#92;sub&#92;Private .

Best Regards
Helmut

On Thu, 24 Apr 2003 19:09:46 +0200, Mathias wrote:

No idea whether LTspice can handle this.

It's almost as though there may need to be a sub-folder
structure to allow some user-determined organization to the
"pick/select new transistor" dialog box. In other words, not a
flat list, but one which allows folders as well which can be
opened, as desired.

I personally think about importing models once I need these.

Yes, it's just a nifty resource at this point, where I can pull
what I need when I need it. On the other hand, if there is some
nice way to organize so many, I'd be happier to have them all at
my fingertips without having to exit, edit, save, and re-enter
LT Spice.

There's currently no folder structure possible for models in LTspice and
therefore I'm concerned that I might loose the overview scrolling through
thousands of files.

Yes. Hehe. But LT Spice does allow re-sorting on certain
criteria, though sadly not on the detailed spice parameters.

Can you be so kind to forward this link to me?

The one I found is:




Jon

I am trying to use the TABLE form to define an Arbitrary Current
Source (B). I have done it in other Spices but just can't seem to
get the syntax right in LTSpice. Does anyone have the correct
syntax or an example for using TABLE with an arbitrary source in
LTSpice?