|
Andy wrote:
“Remember to never set Trise or Tfall to 0.? That signals SPICE (and LTspice) to substitute non-zero default values, and they won't be anywhere near 0.? It's a SPICE thing.”
?
Indeed! I tried this a while back.
1ns yielded 1ns Tr and Tf
0 yielded 100us Tr and Tf
1p was too fast to zoom into, but jumping to marked data points, I got … 1ps
?
?
Dave
?
|
SPICE used "0" to tell it to apply a default value.? It is most apparent with Trise and Tfall, but it works in a number of other places too.? Typing 0 can even mean "infinity" in a couple of places, where that is the default.
If you use 0 for Trise or Tfall, SPICE calculates default rise and fall times as a function of other things, including the Stop Time of the simulation.? The default rise or fall time usually looks "small enough" when looking at the entire waveform, but not when you zoom in.
Andy
|
I dug out the test case, and tried down into femtoseconds.
Best I could get was 100fs for a setting of 100fs
?
Dave
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of
Bell, Dave (US)
Sent: Friday, July 14, 2023 1:06 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] ISL70444SEH declaration issue?
?
Andy wrote:
“Remember to never set Trise or Tfall to 0.? That signals SPICE (and LTspice) to substitute non-zero default values, and they won't be anywhere near 0.? It's a SPICE thing.”
?
Indeed! I tried this a while back.
1ns yielded 1ns Tr and Tf
0 yielded 100us Tr and Tf
1p was too fast to zoom into, but jumping to marked data points, I got … 1ps
?
?
Dave
?
|
Dave,
If you're talking about risetime, it can be quite a lot smaller than 100 fs.? I would say arbitrarily small, but eventually you reach the limits of double precision math.? Remember not to let LTspice's waveform compression get in the way.? And there are limits of how far you can zoom in, but even that can be overcome if you know how.? And if you don't, there's waveform cursors.
Andy
|
I have uploaded a test
schematic that measures the actual rise and fall times of a
pulse source with default rise and fall times, i.e. both set to
zero.
The measurements show that the algorithm is:
For Ton ≤ Per/2: Trise = Tfall = Ton/10
For Ton > Per/2: the law is mirrored
I have verified this for Ton = Per/1000 to 999*Per/1000.
As a consequence of:
Toff = Per - Ton - Trise - Tfall
.. the measured duty cycle (at the 50% points) is a non-linear
function or Ton/Per, being 0.55 at Ton/Per=0.5.
This is the reason why to set a 50% actual duty cycle:
Ton = (Per - Trise - Tfall)/2
--
Regards,
Tony
On 14/07/2023 23:32, Bell, Dave wrote:
toggle quoted message
Show quoted text
I dug out the test case, and tried down into
femtoseconds.
Best I could get was 100fs for a setting of
100fs
?
Dave
?
?
Andy wrote:
“Remember to never set Trise or Tfall to
0.? That signals SPICE (and LTspice) to substitute non-zero
default values, and they won't be anywhere near 0.? It's a
SPICE thing.”
?
Indeed! I tried this a while back.
1ns yielded 1ns Tr and Tf
0 yielded 100us Tr and Tf
1p was too fast to zoom into, but jumping
to marked data points, I got … 1ps
?
?
Dave
|
Good, but what does 'the law is
mirrored' mean?
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-15 13:52, Tony Casey wrote:
toggle quoted message
Show quoted text
I have uploaded a test
schematic that measures the actual rise and fall times of a
pulse source with default rise and fall times, i.e. both set to
zero.
The measurements show that the algorithm is:
For Ton ≤ Per/2: Trise = Tfall = Ton/10
For Ton > Per/2: the law is mirrored
I have verified this for Ton = Per/1000 to 999*Per/1000.
As a consequence of:
Toff = Per - Ton - Trise - Tfall
.. the measured duty cycle (at the 50% points) is a non-linear
function or Ton/Per, being 0.55 at Ton/Per=0.5.
This is the reason why to set a 50% actual duty cycle:
Ton = (Per - Trise - Tfall)/2
--
Regards,
Tony
On 14/07/2023 23:32, Bell, Dave
wrote:
I dug out the test case, and tried down
into femtoseconds.
Best I could get was 100fs for a setting of
100fs
?
Dave
?
?
Andy wrote:
“Remember to never set Trise or Tfall to
0.? That signals SPICE (and LTspice) to substitute non-zero
default values, and they won't be anywhere near 0.? It's a
SPICE thing.”
?
Indeed! I tried this a while back.
1ns yielded 1ns Tr and Tf
0 yielded 100us Tr and Tf
1p was too fast to zoom into, but jumping
to marked data points, I got … 1ps
?
?
Dave
|
Trise = Tfall = min(Ton/10, (Per-Ton)/10)
.. would be a more succinct way to express it. Thanks for dragging
it out of me. ?
--
Regards,
Tony
On 15/07/2023 14:57, John Woodgate
wrote:
toggle quoted message
Show quoted text
Good, but what does 'the law is
mirrored' mean?
|
Thanks, Tony.? Per-Ton =
Toff+Trise+Tfall.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-15 14:04, Tony Casey wrote:
toggle quoted message
Show quoted text
Trise = Tfall = min(Ton/10, (Per-Ton)/10)
.. would be a more succinct way to express it. Thanks for dragging
it out of me. ?
--
Regards,
Tony
On 15/07/2023 14:57, John Woodgate
wrote:
Good, but what does 'the law is
mirrored' mean?
|
Tony wrote:
.. the measured duty cycle (at the 50% points) is a non-linear function or Ton/Per, being 0.55 at Ton/Per=0.5.
This is the reason why to set a 50% actual duty cycle:
Ton = (Per - Trise - Tfall)/2
Well, not really, this is not the reason why.? You should always use Ton = (Per - Trise - Tfall)/2 if you want a 50% duty cycle, no matter whether you use your own (non-zero) rise and fall times, or if you let LTspice choose its own defaults.? As long as the actual Trise and Tfall are not zero -- which by definition they must be -- then you must account for them when choosing Ton to get any desired duty cycle. The mistake people make is thinking that "Ton" means the time that the signal is above the mid voltage.? It is not.? Ton is the time that the signal is fully at 100%, at Von.? The pulsewidth is always greater than that, because of Trise/2 and Tfall/2.? Everyone forgets that. Andy
|
Under lTspice 17.0.36, I found an effective lowest limit in defining Tr and Tf, of >10ps.
?
Very simple model, only one V source:
?
;PULSE(0 1 4m {Trf} {Trf} 1m 2m)
.step param Trf list 1f 10f 11f 20f 50f 100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.meas Td param T1-T0
?
Log:
?
.step trf=1e-015
.step trf=1e-014
.step trf=1.1e-014
.step trf=2e-014
.step trf=5e-014
.step trf=1e-013
.step trf=1e-012
?
?
Measurement: t0
? step???????????? v(a)=0.01
???? 1???????????? 0.00400001
???? 2???????????? 0.00400001
???? 3???????????? 0.004
???? 4???????????? 0.004
???? 5???????????? 0.004
???? 6???????????? 0.004
???? 7???????????? 0.004
?
Measurement: t1
? step???????????? v(a)=0.99
???? 1???????????? 0.00400056
???? 2???????????? 0.00400056
???? 3???????????? 0.004
???? 4???????????? 0.004
???? 5???????????? 0.004
???? 6???????????? 0.004
???? 7???????????? 0.004
?
Measurement: td
? step???????????? t1-t0
???? 1???????????? 5.537e-007
???? 2???????????? 5.537e-007
???? 3???????????? 1.07796e-014
???? 4???????????? 1.95989e-014
???? 5???????????? 4.90007e-014
???? 6???????????? 9.79997e-014
???? 7???????????? 9.8e-013
?
Anything 10ps or shorter results in 554ns, but 11ps works within 3%
?
Dave
?
|
I think you might need to mind
your p's and f's.?
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-16 18:43, Bell, Dave wrote:
toggle quoted message
Show quoted text
Under lTspice 17.0.36, I found an
effective lowest limit in defining Tr and Tf, of >10ps.
?
Very simple model, only one V source:
?
;PULSE(0 1 4m {Trf} {Trf} 1m 2m)
.step param Trf list 1f 10f 11f 20f 50f
100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.meas Td param T1-T0
?
Log:
?
.step trf=1e-015
.step trf=1e-014
.step trf=1.1e-014
.step trf=2e-014
.step trf=5e-014
.step trf=1e-013
.step trf=1e-012
?
?
Measurement: t0
? step???????????? v(a)=0.01
???? 1???????????? 0.00400001
???? 2???????????? 0.00400001
???? 3???????????? 0.004
???? 4???????????? 0.004
???? 5???????????? 0.004
???? 6???????????? 0.004
???? 7???????????? 0.004
?
Measurement: t1
? step???????????? v(a)=0.99
???? 1???????????? 0.00400056
???? 2???????????? 0.00400056
???? 3???????????? 0.004
???? 4???????????? 0.004
???? 5???????????? 0.004
???? 6???????????? 0.004
???? 7???????????? 0.004
?
Measurement: td
? step???????????? t1-t0
???? 1???????????? 5.537e-007
???? 2???????????? 5.537e-007
???? 3???????????? 1.07796e-014
???? 4???????????? 1.95989e-014
???? 5???????????? 4.90007e-014
???? 6???????????? 9.79997e-014
???? 7???????????? 9.8e-013
?
Anything 10ps or shorter results in
554ns, but 11ps works within 3%
?
Dave
?
|
Dave wrote, "... I found an effective lowest limit in defining Tr and Tf, of >10ps." I think you meant 10fs. But try this:
V1 A 0 PULSE(0 1 1m {Trf} {Trf} 1m 2m)
.step param Trf list 1f 10f 11f 20f 50f 100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.meas Td param T1-T0
.tran 3m
.options plotwinsize=0
Measurement: td
? step t1-t0
? ? ?1 1.0388e-007
? ? ?2 9.8001e-015? <-- 9.8fs
? ? ?3 1.07802e-014? <-- 10.8fs
? ? ?4 1.96002e-014
? ? ?5 4.89999e-014
? ? ?6 9.8e-014
? ? ?7 9.8e-013 And then this:
V1 A 0 PULSE(0 1 1p {Trf} {Trf} 1p 2p)
.step param Trf list 0.000001f 0.001f 0.01f 0.1f 1f
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.meas Td param T1-T0
.tran 0 3p
.options plotwinsize=0
Measurement: td
? step t1-t0
? ? ?1 9.8e-022? <-- 0.00000098fs
? ? ?2 9.8e-019? <-- 0.00098fs
? ? ?3 9.8e-018? <-- 0.0098fs
? ? ?4 9.8e-017? <-- 0.098fs
? ? ?5 9.8e-016? <-- 0.98fs
Your experiment differs (fails) because you didn't control LTspice's internal timestep.? What you measured in the fastest edges was LTspice's relaxed internal timestep, which plowed right past the requested 1fs and 10fs risetimes.? The pulse would have had the faster risetimes you requested, but the timestep was too large to reveal it.? Even my first case above misses the 1fs case because its internal timestep is too slow.
If you use Mark Data Points, you can see that your fastest edges produced no datapoints along the edges.? The other (slower) edges had multiple data points along each edge.
Man-handling SPICE/LTspice to control its internal timestep is a science all its own.? Sometimes it's simple; sometimes not.
For SPICE or LTspice to throttle its own internal timestep, it has to determine that a point it just simulated had failed because its error estimate was too great.? But if the point it simulated (after the rising edge) matches the requested waveform 100%, it has no reason to back up and try a smaller internal timestep.? Therein lies part of the problem.
Andy
|
For grins, here is another one to try.? It shows one way to control SPICE's internal timestep while not imposing a harshly small Maximum Timestep across the whole simulation (which would make it crawl):
V1 A 0 PULSE(0 1 4m {Trf} {Trf} 1m 2m)
V2 B 0 SIN (0 1 1000T 4m 0 0 1000)
.step param Trf list 1f 10f 11f 20f 50f 100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.meas Td param T1-T0
.tran 0 10m
.options plotwinsize=0
Measurement: td
? step t1-t0
? ? ?1 1.01915e-015? <-- 1.02 fs
? ? ?2 9.80032e-015? <-- 9.8 fs
? ? ?3 1.07796e-014? <-- 10.8 fs
? ? ?4 1.95998e-014? <-- 19.6 fs
? ? ?5 4.90007e-014? <-- 49.0 fs
? ? ?6 9.79997e-014? <-- 98.0 fs
? ? ?7 9.8e-013? <-- 0.98 ps
Andy
|
Andy, your model here does work all the way down to 1fs.
But:
- It’s much slower as-is, so
- I deleted the SIN source, V2/B
Now, it runs as fast as before, as far as I could sense (didn’t compare runtime in the logs), but no longer works below 10ps!
?
Dave
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of
Andy I
Sent: Sunday, July 16, 2023 12:58 PM
To: [email protected]
Subject: EXTERNAL: Re: : Re: [LTspice] PULSE default rise and fall times (Trise=0 Tfall=0) (was: ISL70444SEH declaration issue?)
?
For grins, here is another one to try.? It shows one way to control SPICE's internal timestep while not imposing a harshly small Maximum Timestep across the whole simulation (which would make it crawl):
V1 A 0 PULSE(0 1 4m {Trf} {Trf} 1m 2m)
V2 B 0 SIN (0 1 1000T 4m 0 0 1000)
.step param Trf list 1f 10f 11f 20f 50f 100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.options plotwinsize=0
? ? ?1 1.01915e-015? <-- 1.02 fs
? ? ?2 9.80032e-015? <-- 9.8 fs
? ? ?3 1.07796e-014? <-- 10.8 fs
? ? ?4 1.95998e-014? <-- 19.6 fs
? ? ?5 4.90007e-014? <-- 49.0 fs
? ? ?6 9.79997e-014? <-- 98.0 fs
? ? ?7 9.8e-013? <-- 0.98 ps
Andy
|
That's the whole point of V2:
it forces LTspice to have a very small timestep indeed.
Obviously it takes time to plot lots of cycles of 1 petahertz.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-16 22:53, Bell, Dave wrote:
toggle quoted message
Show quoted text
Andy, your model here does work all the way
down to 1fs.
But:
- It’s much
slower as-is, so
- I deleted
the SIN source, V2/B
Now, it runs as fast as before, as far as I
could sense (didn’t compare runtime in the logs), but no
longer works below 10ps!
?
Dave
?
?
For grins,
here is another one to try.? It shows one way to control
SPICE's internal timestep while not imposing a harshly small
Maximum Timestep across the whole simulation (which would make
it crawl):
V1 A 0 PULSE(0 1 4m {Trf} {Trf} 1m 2m)
V2 B 0 SIN (0 1 1000T 4m 0 0 1000)
.step param Trf list 1f 10f 11f 20f 50f
100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.options
plotwinsize=0
? ? ?1 1.01915e-015? <-- 1.02 fs
? ? ?2 9.80032e-015? <-- 9.8 fs
? ? ?3 1.07796e-014? <-- 10.8 fs
? ? ?4 1.95998e-014? <-- 19.6 fs
? ? ?5 4.90007e-014? <-- 49.0 fs
? ? ?6 9.79997e-014? <-- 98.0 fs
? ? ?7
9.8e-013? <-- 0.98 ps
Andy
|
Well, that’s true!? My mind didn’t conceive of a PHz burst!
Certainly slowed down the entire .TRAN period, though.
I would have guessed PSICE would only slow down for the 1000 cycles of the burst.
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John Woodgate
Sent: Sunday, July 16, 2023 3:08 PM
To: [email protected]
Subject: EXTERNAL: Re: : Re: : Re: [LTspice] PULSE default rise and fall times (Trise=0 Tfall=0) (was: ISL70444SEH declaration issue?)
?
That's the whole point of V2: it forces LTspice to have a very small timestep indeed. Obviously it takes time to plot lots of cycles of 1 petahertz.
======================================================================================
Best wishes John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget. I see, and I remember. I do, and I understand. Xunzi (340 - 245 BC)
On 2023-07-16 22:53, Bell, Dave wrote:
Andy, your model here does work all the way down to 1fs.
But:
- It’s much slower as-is, so
- I deleted the SIN source, V2/B
Now, it runs as fast as before, as far as I could sense (didn’t compare runtime in the logs), but no longer works below 10ps!
?
Dave
?
?
For grins, here is another one to try.? It shows one way to control SPICE's internal timestep while not imposing a harshly small Maximum Timestep across the whole simulation (which would make it crawl):
V1 A 0 PULSE(0 1 4m {Trf} {Trf} 1m 2m)
V2 B 0 SIN (0 1 1000T 4m 0 0 1000)
.step param Trf list 1f 10f 11f 20f 50f 100f 1p
.meas T0 WHEN V(A)=0.01 rise=1
.meas T1 WHEN V(A)=0.99 rise=1
.options plotwinsize=0
? ? ?1 1.01915e-015? <-- 1.02 fs
? ? ?2 9.80032e-015? <-- 9.8 fs
? ? ?3 1.07796e-014? <-- 10.8 fs
? ? ?4 1.95998e-014? <-- 19.6 fs
? ? ?5 4.90007e-014? <-- 49.0 fs
? ? ?6 9.79997e-014? <-- 98.0 fs
? ? ?7 9.8e-013? <-- 0.98 ps
Andy
|
Dave wrote, "Certainly slowed down the entire .TRAN period, though."
That should not have happened.? It should slow it down over only 1 ps of the 10 ms simulation -- so about 0.00000001% of it.
LTspice says it took about 0.4 seconds longer to simulate.? What did it do on your computer?
I wonder if we have run across another bug??? If you plot V(B), what do you see?
Anyway, just to clarify, when you wrote "but no longer works below 10ps!"? That's not quite true.? Your PULSE voltage source does have wicked fast rise and fall times down to 1 femtosecond or faster if you ask for them, but the internal Timestep isn't able to show it.? THAT is the issue, not the PULSE source.
Andy
|
I suspect it was a large data file that slowed mine down.
My run times were between 12 and 14 seconds, up from ~200 ms
?
V(B) was what I expected, once I realized what the SIN parameters did!
One big spike at 4ms.
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of
Andy I
Sent: Sunday, July 16, 2023 5:38 PM
To: [email protected]
Subject: EXTERNAL: Re: : Re: : Re: [LTspice] PULSE default rise and fall times (Trise=0 Tfall=0) (was: ISL70444SEH declaration issue?)
?
Dave wrote, "Certainly slowed down the entire .TRAN period, though."
That should not have happened.? It should slow it down over only 1 ps of the 10 ms simulation -- so about 0.00000001% of it.
LTspice says it took about 0.4 seconds longer to simulate.? What did it do on your computer?
I wonder if we have run across another bug??? If you plot V(B), what do you see?
Anyway, just to clarify, when you wrote "but no longer works below 10ps!"? That's not quite true.? Your PULSE voltage source does have wicked fast rise and fall times down to
1 femtosecond or faster if you ask for them, but the internal Timestep isn't able to show it.? THAT is the issue, not the PULSE source.
Andy
|
Bell, Dave
Tony Casey
John Woodgate