|
Hello ,I have the following file which is presenting an error shown below
When I added the following spice command it ran no problem.
Is there a manual an intuition regarding why this spice command solved the problem?
Ltspice file is attached.
Thanks.
spice command solution
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
/g/LTspice/files/Temp/PID_section_united_AC_separate.zip
?
error:
Start Time: Mon Feb 24 15:55:30 2025
solver = Normal
Maximum thread count: 32
tnom = 27
temp = 27
method = trap
Direct Newton iteration for .op point succeeded.
Warning: Simulation tolerance relaxed to achieve convergence from 8.1172440660751147e-08?
Convergence Failure: ?Time step too small; time = 8.11724e-08, timestep = 1.25e-19: trouble with instance "u1:DSC1"
Simulation Failed: Iteration limit reached
Total elapsed time: 1.041 seconds.
|
On Mon, Feb 24, 2025 at 09:03 AM, john23 wrote:
Hello ,I have the following file which is presenting an error shown below
...
Convergence Failure: ?Time step too small; time = 8.11724e-08, timestep = 1.25e-19: trouble with instance "u1:DSC1"
I assume this is the failure you asked about.
?
"Time step too small" errors are unfortunately difficult to deal with.? If this is your first time encountering a "timestep too small" error, "welcome to the club".
?
"Time step too small" errors happen for this reason.? When SPICE can't converge at any timepoint, it backs up to the previous one, sets the time step smaller (I think by a factor of 8), and tries again.? It is more likely to find convergence by not trying to go too far into the future, so a smaller timestep after the last good point is more likely to solve, and then it can move on.
?
But occasionally that doesn't work.? It keeps trying smaller and smaller timesteps, until eventually the timestep gets ridiculously small, and SPICE/LTspice aborts with that error message.
?
The root problem is most likely because there is something in the circuit that behaves badly.? Maybe a component's function or its derivative has a discontinuity.? Both are bad for SPICE and should never happen, but many models have discontinuities and can lead to these problems.? The best remedy is to fix the models.? But often we can't do that.? There are a handful of other things that can sometimes help,?
?
Download the FAQ file.? Open it and read until you find the section about "time step too small" errors, and start reading.? There are a couple dozen suggestions that MIGHT help.? There is no guarantee that you can ever fix a "time step too small" error. ?
When I ran your simulation, I do not (yet) have a "time step too small" error, but it has not found the initial DC solution yet.? Time step too small errors can happen even during the initial DC solution phase, because one of the algorithms is "Pseudo-Tran", which applies the transient solver to finding the DC solution.? Sometimes it can abort in that phase, even though it is not a .TRAN simulation at all.
?
Andy
?
?
|
I agree, of course, but the AD797 is a
(costly) opamp. It should not produce a TSTS error in that .ASC.
Without a lot of digging, it isn't possible to confirm that it
is connected correctly; for example, is node 38 really the
output? The .ASC appears to work with the simple opamp.. It
could hardly refuse.
On 2025-02-24 14:52, Andy I via
groups.io wrote:
On Mon, Feb 24, 2025 at 09:03 AM, john23 wrote:
Hello ,I have the following file which is presenting an
error shown below
...
Convergence Failure: ?Time step too small; time =
8.11724e-08, timestep = 1.25e-19: trouble with instance
"u1:DSC1"
I assume this is the failure you asked about.
?
"Time step too small" errors are unfortunately difficult to
deal with.? If this is your first time encountering a "timestep
too small" error, "welcome to the club".
?
"Time step too small" errors happen for this reason.? When
SPICE can't converge at any timepoint, it backs up to the
previous one, sets the time step smaller (I think by a factor of
8), and tries again.? It is more likely to find convergence by
not trying to go too far into the future, so a smaller timestep
after the last good point is more likely to solve, and then it
can move on.
?
But occasionally that doesn't work.? It keeps trying smaller
and smaller timesteps, until eventually the timestep gets
ridiculously small, and SPICE/LTspice aborts with that error
message.
?
The root problem is most likely because there is something in the
circuit that behaves badly.? Maybe a component's function or its
derivative has a discontinuity.? Both are bad for SPICE and
should never happen, but many models have discontinuities and
can lead to these problems.? The best remedy is to fix the
models.? But often we can't do that.? There are a handful of
other things that can sometimes help,?
?
Download the FAQ file.?
Open it and read until you find the section about "time step too
small" errors, and start reading.? There are a couple dozen
suggestions that MIGHT help.? There is no guarantee that you can
ever fix a "time step too small" error. ?
When I ran your simulation, I do not (yet) have a "time step
too small" error, but it has not found the initial DC solution
yet.? Time step too small errors can happen even during the
initial DC solution phase, because one of the algorithms is
"Pseudo-Tran", which applies the transient solver to finding the
DC solution.? Sometimes it can abort in that phase, even though
it is not a .TRAN simulation at all.
?
Andy
?
?
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
On Mon, Feb 24, 2025 at 11:11 AM, John Woodgate wrote:
I agree, of course, but the AD797 is a (costly) opamp. It should not produce a TSTS error in that .ASC.
Why not?
Does expensive silicon imply an equally expensive SPICE model?? Shouldn't every SPICE model ever made, whether for cheap or expensive silicon, not produce time step too small errors?? And yet they happen.
Without a lot of digging, it isn't possible to confirm that it is connected correctly; for example, is node 38 really the output?
The SPICE model claims that it is.? What is your point with that question?? Are you suggesting that its creator at AAG/PMI did not know what she/he was doing, and mis-labeled the output node?? If that happened, then there would be an awful lot more questions than that one.
?
I think simpler circuits are in order for this simulation.? Realizing that U1 is open-loop might be a good first step.? Since this is a DC simulation, capacitors are open-circuits.? No negative feedback around U1.? U3 seems to run into difficulty right in the vicinity of 0 V output, which is odd.
?
Even when the circuit is made smaller and it runs, it has considerable difficulty at certain operating points.? The SPICE output log is foll of warning messages that suggest it has trouble, and it suggests alternative settings to help.
?
?
|
I don't know what's going on here. U1 isn't
open-loop. Are we looking at the same .ASC,
PID_section_united_AC_separate?? U3 is open-loop at DC. U1 and
U2 have unity gain, U4 has 100 times gain at DC. In such a
circuit, I would not expect a TSTS? error, and I would expect
the model o a costly opamp to be a good one. I meant that I
could not see how to verify node 38 without going back over the
previous many emails.
On 2025-02-24 17:19, Andy I via
groups.io wrote:
On Mon, Feb 24, 2025 at 11:11 AM, John Woodgate wrote:
I agree, of course, but
the AD797 is a (costly) opamp. It should not produce a
TSTS error in that .ASC.
Why not?
Does expensive silicon imply an equally expensive SPICE model??
Shouldn't every SPICE model ever made, whether for cheap or
expensive silicon, not produce time step too small errors?? And
yet they happen.
Without a lot of digging,
it isn't possible to confirm that it is connected
correctly; for example, is node 38 really the output?
The SPICE model claims that it is.? What is your point with
that question?? Are you suggesting that its creator at AAG/PMI
did not know what she/he was doing, and mis-labeled the output
node?? If that happened, then there would be an awful lot more
questions than that one.
?
I think simpler circuits are in order for this simulation.?
Realizing that U1 is open-loop might be a good first step.?
Since this is a DC simulation, capacitors are open-circuits.? No
negative feedback around U1.? U3 seems to run into difficulty
right in the vicinity of 0 V output, which is odd.
?
Even when the circuit is made smaller and it runs, it has
considerable difficulty at certain operating points.? The SPICE
output log is foll of warning messages that suggest it has
trouble, and it suggests alternative settings to help.
?
?
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
?
Thanks.
|
Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
|
10f is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via
groups.io wrote:
Is “10f” a
special case in the parasitics settings?
For a
regular cap, it would mean 10 Farads!
?
?
The following line solved the problem.Is
there some manual or intution regarding why these might
help?
.options
cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
In *this case*, I see that.
Seems like a bit inconsistent…
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 1:36 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small
?
10f is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via groups.io wrote:
Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
|
I think that 10 means 10 farads, 10m means 10
millifarads etc, but, with a space in between, 10 f or 10 F or
10 m means 10 farads and the following letter is disregarded, or
throws an error in some cases. This works in the component
properties pane.
On 2025-02-24 21:52, Bell, Dave via
groups.io wrote:
In *this case*,
I see that.
Seems like a bit
inconsistent…
?
?
10f is
recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via
groups.io wrote:
Is “10f” a
special case in the parasitics settings?
For a
regular cap, it would mean 10 Farads!
?
?
The following line solved the
problem.Is there some manual or intution regarding why
these might help?
.options
cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as we
know - it's science *for certain - it's mathematics
*unquestionably - it's religion
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
Yes, I agree, on all counts. It means Farads, in lower OR upper case.
But in the .options context, it appears to accept 10f as 10 femtofarads.
That’s logical, because who would want a 10F parasitic shunt capacitance?
?
I’m just disturbed that it’s different, between contexts.
Not much different from ^ vs. **, where the carat could mean exponentiation or exclusive OR
?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 2:03 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small
?
I think that 10 means 10 farads, 10m means 10 millifarads etc, but, with a space in between, 10 f or 10 F or 10 m means 10 farads and the following letter is disregarded, or throws an error in some cases. This
works in the component properties pane.
On 2025-02-24 21:52, Bell, Dave via groups.io wrote:
In *this case*, I see that.
Seems like a bit inconsistent…
?
?
10f is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via groups.io wrote:
Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
|
On 2/24/25 3:29 PM, Bell, Dave via groups.io wrote: Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
Farads being the only possible unit for capacitance, there is no need to specify it. -- David Schultz "The cheeper the crook, the gaudier the patter." - Sam Spade
|
I think you have misunderstood. You can put a
10f (femtofarad) cap in an .ASC by writing that value in the
component property pane. Try it: feed a 10f cap via 1meg and the
-3dB point is at 16MHz.
On 2025-02-24 23:00, Bell, Dave via
groups.io wrote:
Yes, I agree, on
all counts. It means Farads, in lower OR upper case.
But in the
.options context, it appears to accept 10f as 10
femtofarads.
That’s logical,
because who would want a 10F parasitic shunt capacitance?
?
I’m just disturbed
that it’s different, between contexts.
Not much different
from ^ vs. **, where the carat could mean exponentiation or
exclusive OR
?
?
?
I
think that 10 means 10 farads, 10m means 10 millifarads etc,
but, with a space in between, 10 f or 10 F or 10 m means 10
farads and the following letter is disregarded, or throws an
error in some cases. This works in the component properties
pane.
On 2025-02-24 21:52, Bell, Dave via
groups.io wrote:
In *this case*,
I see that.
Seems like a bit
inconsistent…
?
?
10f
is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via
groups.io wrote:
Is “10f”
a special case in the parasitics settings?
For a
regular cap, it would mean 10 Farads!
?
?
The following line solved the
problem.Is there some manual or intution regarding why
these might help?
.options
cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as
we know - it's science *for certain - it's mathematics
*unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we
know - it's science *for certain - it's mathematics
*unquestionably - it's religion
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
But, if that's the case, can it possibly mean 10 FARADS in ".options cshunt 10f" ?
All of the other options default to values that make nearly no difference.
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of David Schultz via groups.io Sent: Monday, February 24, 2025 3:11 PM To: [email protected]Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small On 2/24/25 3:29 PM, Bell, Dave via groups.io wrote: Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
Farads being the only possible unit for capacitance, there is no need to specify it. -- David Schultz "The cheeper the crook, the gaudier the patter." - Sam Spade
|
NOT if you type “10f”! That’s the same as “10F”, isn’t it?
For time, resistance, etc.10m = 10M <> 10meg or 10Meg, etc.
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 3:23 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small
?
I think you have misunderstood. You can put a 10f (femtofarad) cap in an .ASC by writing that value in the component property pane. Try it: feed a 10f cap via 1meg and the -3dB point is at 16MHz.
On 2025-02-24 23:00, Bell, Dave via groups.io wrote:
Yes, I agree, on all counts. It means Farads, in lower OR upper case.
But in the .options context, it appears to accept 10f as 10 femtofarads.
That’s logical, because who would want a 10F parasitic shunt capacitance?
?
I’m just disturbed that it’s different, between contexts.
Not much different from ^ vs. **, where the carat could mean exponentiation or exclusive OR
?
?
?
I think that 10 means 10 farads, 10m means 10 millifarads etc, but, with a space in between, 10 f or 10 F or 10 m means 10 farads and the following letter is disregarded, or throws an error in some cases. This
works in the component properties pane.
On 2025-02-24 21:52, Bell, Dave via groups.io wrote:
In *this case*, I see that.
Seems like a bit inconsistent…
?
?
10f is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via groups.io wrote:
Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
|
OK, I tried it, and well, it’s weird and not as I expected.
I stand corrected!
?
Dave
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 3:23 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small
?
I think you have misunderstood. You can put a 10f (femtofarad) cap in an .ASC by writing that value in the component property pane. Try it: feed a 10f cap via 1meg and the -3dB point is at 16MHz.
On 2025-02-24 23:00, Bell, Dave via groups.io wrote:
Yes, I agree, on all counts. It means Farads, in lower OR upper case.
But in the .options context, it appears to accept 10f as 10 femtofarads.
That’s logical, because who would want a 10F parasitic shunt capacitance?
?
I’m just disturbed that it’s different, between contexts.
Not much different from ^ vs. **, where the carat could mean exponentiation or exclusive OR
?
?
?
I think that 10 means 10 farads, 10m means 10 millifarads etc, but, with a space in between, 10 f or 10 F or 10 m means 10 farads and the following letter is disregarded, or throws an error in some cases. This
works in the component properties pane.
On 2025-02-24 21:52, Bell, Dave via groups.io wrote:
In *this case*, I see that.
Seems like a bit inconsistent…
?
?
10f is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via groups.io wrote:
Is “10f” a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion
|
I say try it in a circuit. Yes, SPICE ignores
case, but it doesn't ignore SPACES in this context. It ignores
any character after the space. 10f is 10F is 10 femtofarads: 10
f is 10 F is 10 is 10 farads.
On 2025-02-24 23:32, Bell, Dave via
groups.io wrote:
NOT if you type
“10f”! That’s the same as “10F”, isn’t it?
For time,
resistance, etc.10m = 10M <> 10meg or 10Meg, etc.
?
?
I
think you have misunderstood. You can put a 10f (femtofarad)
cap in an .ASC by writing that value in the component
property pane. Try it: feed a 10f cap via 1meg and the -3dB
point is at 16MHz.
On 2025-02-24 23:00, Bell, Dave via
groups.io wrote:
Yes, I agree, on
all counts. It means Farads, in lower OR upper case.
But in the
.options context, it appears to accept 10f as 10
femtofarads.
That’s logical,
because who would want a 10F parasitic shunt capacitance?
?
I’m just
disturbed that it’s different, between contexts.
Not much
different from ^ vs. **, where the carat could mean
exponentiation or exclusive OR
?
?
?
I
think that 10 means 10 farads, 10m means 10 millifarads
etc, but, with a space in between, 10 f or 10 F or 10 m
means 10 farads and the following letter is disregarded,
or throws an error in some cases. This works in the
component properties pane.
On 2025-02-24 21:52, Bell, Dave via
groups.io wrote:
In *this
case*, I see that.
Seems like a
bit inconsistent…
?
?
10f
is recognized as 10 femtofarads.
On 2025-02-24 21:29, Bell, Dave via
groups.io wrote:
Is
“10f” a special case in the parasitics settings?
For a
regular cap, it would mean 10 Farads!
?
?
The following line solved the
problem.Is there some manual or intution regarding why
these might help?
.options
cshunt =10f gshunt=10n abstol=10n vntol=1m
--
OOO - Own Opinions only If something is true: * as far
as we know - it's science *for certain - it's
mathematics *unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as
we know - it's science *for certain - it's mathematics
*unquestionably - it's religion
--
OOO - Own Opinions only If something is true: * as far as we
know - it's science *for certain - it's mathematics
*unquestionably - it's religion
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
On Mon, Feb 24, 2025 at 12:38 PM, John Woodgate wrote:
I don't know what's going on here. U1 isn't open-loop. Are we looking at the same .ASC, PID_section_united_AC_separate?
We are.
?
U1 is the integrator with C1 in its feedback path.? For DC, C1 is an open circuit so it is open-loop at DC.
?
?U3 is open-loop at DC. U1 and U2 have unity gain, U4 has 100 times gain at DC.
Wow.? You got quite different component markers than I did, from the same schematic!? Since those numbers are embedded within the schemeatic file itself, I don't know how that would have happened.
In such a circuit, I would not expect a TSTS? error
One never expects Timestep Too Small errors.? They only happen when the simulator runs into great difficulty in the right way.
?
Did I also mention that I never saw a Timestep Too Small error when I tried that simulation?? It was something "john23" had in his Error Log listing.? ?In my simulation it just ran very very slowly but did not abort.
?
Andy
?
|
On Mon, Feb 24, 2025 at 04:52 PM, Bell, Dave wrote:
Seems like a bit inconsistent…
There is nothing inconsistent about it.? You have misunderstood.
?
"10f" always ALWAYS means 10 femto.
?
"10F" always ALWAYS means 10 femto.
?
It never ever means 10 Farads.
?
Now, if you were to write "10 f" or "10 F" with a space between the "10" and the "f", then you have listed two things, not one.? In that case, SPICE (and LTspice) always interpret the "10" to mean ten, so you would get 10 Farads -- and then it sees a lonely unattached "F" sitting there, which it might either ignore, or flag as an error.? It would be the same if you wrote "10 X".? The "X" does not belong.? SPICE either makes an error, or quietly ignores it.? SPICE could in some cases - I think intentionally - ignore things that clearly did not belong.
?
Andy
?
|
On Mon, Feb 24, 2025 at 03:28 PM, john23 wrote:
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
Because settings such as those can sometimes help simulations run better.? That is the simple explanation.
?
Cshunt and Gshunt add a bit of capacitance and conductance from every circuit node to ground.? Both of them help when the circuit matrix is near to singular, by adding damping to the circuit.? The more damping there is, the closer it is to a set of linear equations, making it somewhat easier to approach a good solution in a smaller number of? tries.
?
Setting Abstol and Vntol to larger numbers allows the simulator to "solve" the network equations sooner (fewer iterations).? The network equations are nonlinear, which means that LTspice needs to iterate a number of times at each point, until its error estimates are smaller than the *TOL tolerance settings.? By setting those *TOL numbers larger, it is less likely to "get stuck" at any one point, iterating indefinitely and never getting a small enough error estimate.?
?
Larger tolerance settings can cause larger errors and less accuracy.? Larger *shunt values degrade the circuit somewhat by adding conductances or capacitances that were not there (at least, they were not there in the original circuit description).? They both help SPICE's solver think it has found a solution, but that solution MIGHT be less accurate.? With luck, the difference is insignificant.? Remember that every simulation of a nonlinear circuit is an approximation.
?
Andy
?
|
John Woodgate
Bell, Dave