Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison

1 Piero Belforte Marcel Hendrix Francesco Lannutti Robert Larice December 2015
Digital Wave vs. Nodal Analysis for Circuit Simulation:
an experimental comparison
Abstract: This document reports the comparative simulations of selected test circuits carried out using both a
Digital Wave Simulator (DWS) and three different versions of Spice (Ngspice, LTspice and Microcap 11). The
complementary features of Digital Wave processing with respect classical Nodal Analysis (NA) are compared in
terms of accuracy and execution speed using different simulator optional settings. In particular, the effect of DWS
simulation time step and Spice maximum time step are compared for both lumped and Transmission Line (TL)
circuits. The speed advantage of DW processing with respect conventional NA simulation can be exploited to carry
out simulations at very low time step to get very accurate results to be compared with Spice results. Circuit size of
Spice simulators can be extended thanks to DWS linear growth of simulation times vs. circuit complexity.
Several classes of both linear and nonlinear circuits are analyzed and the different behaviors of Spice versions is
also pointed out. The benefits of using both approaches to simulate the same circuit are also evident from the
results of this analysis work.
The content of this document has been directly derived from the content posted by the authors between
September and December 2015 on two discussions of the Ngspice Forum available at the following links:
Transmission Line model issues in Ngspice
Spice - DWS integration
References:
[1] Piero Belforte, Giancarlo Guaschino : DWS 8.5 user manual
https://www.researchgate.net/publication/272576412_DWS_85_USER_MANUAL
[2] Paolo Nenzi, Holger Vogt: Ngspice 26plus user manual
http://ngspice.sourceforge.net/docs/ngspice-manual.pdf
[3] Piero Belforte: VECTOR VS PIECEWISE-LINEAR FITTING FOR SIGNAL AND POWER INTEGRITY
SIMULATION: https://www.researchgate.net/publication/280527160_VECTOR_VS_PIECEWISE-
LINEAR_FITTING_FOR_SIGNAL_AND_POWER_INTEGRITY_SIMULATION
[4] LTSPICE IV User manual: http://ecee.colorado.edu/~mathys/ecen1400/pdf/scad3.pdf
[5] Spectrum Software: Microcap 11 user manual: http://www.spectrum-soft.com/down/ug11.pdf

marcel hendrix
2015-09-15
Piero Belforte writes:
Is there a way to improve the Transmission Line model in ngpsice?
That will not be necessary. Just modify
.TRAN '(50e-9-0e-9)/400' 50e-9 0e-9
to
.TRAN {50n/400} 50e-9 0 {50n/400} uic
I appended a modified .cir file, but most of its modifications are not necessary to let your simulation run.
* Transmission line oscillator
* Author: pierobelforte
* Date: Thu Jan 08 2015
* Desc: The simplest transmission line
* oscillator consisting of a
* precharged tl shorted at
* port1 and open at port2.
* Can be simulated both in
* swan and spice modes.
.options reltol=0.1m method=gear
* CKT START
t0 un_2 0 n_out 0 z0=50 td=.5n ic=1,10m
r1 un_4 0 0
r2 n_out 0 10g
v_in un_2 un_4 0
.temp 27
.tran {5n/400} 5n 0 {5n/400} uic
.print DC V(N_OUT) I(V_IN)
.print AC V(N_OUT) I(V_IN)
.print TRAN V(N_OUT) I(V_IN)
.end
Last edit: marcel hendrix 2015-09-19
oscillator.png

marcel hendrix
2015-09-18
Robert Larice has found that this issue is due to incompatible syntax used to specify the TL's initial conditions.
E.g. the below NGSPICE netlists produce the same results as SpicySWAN. The required SpicySWAN syntax for
the transmission line T0 is shown as a comment (after ";").
* tl_c_oscillator_test3
.options reltol=1m method=gear
t0 n_out1 0 n_out2 0 z0=50 td=.5n ic=0,30m,0.5,0 ; ic=1,10m
r2 n_out2 0 10g
c0 n_out1 0 10p
.temp 27
.tran '2n/5000' 2n 0 '2n/5000' uic
.end
* Transmission line oscillator
* Author: pierobelforte
* Date: Thu Jan 08 2015
* Desc: The simplest transmission line
* oscillator consisting of a
* precharged tl shorted at
* port1 and open at port2.
* Can be simulated both in
* swan and spice modes.
.options reltol=0.1m method=gear
* CKT START
t0 un_2 0 n_out 0 z0=50 td=.5n ic=0,30m,0.5,0; ic=1,10m
r1 un_4 0 1e-3; 0
r2 n_out 0 10g
v_in un_2 un_4 0
.temp 27
.tran {5n/400} 5n 0 {5n/400} uic
.print DC V(N_OUT) I(V_IN)
.print AC V(N_OUT) I(V_IN)
.print TRAN V(N_OUT) I(V_IN)
.end
tl_oscillator_test2.png

tl_oscillator_test3.png
Piero Belforte
2015-09-19
Dear Marcel,
I tried this version of the TL oscillator with capacitive loads in case of symmetrical IC (no current) in SWAN mode using
a 100fs tstep on a 1998-2000ns window (20Megasamples calculated):
https://www.ischematics.com/webspicy/report.py?RCODE=04050551832811274623as#newwin
The comparison with ngspice using your latest suggestions is good up this window using the td/100 setting (what does
this mean?).
If I try to set a td/1000 setting to get more accurate results, ngspice online gives no result and the same happens with
windows located at larger times.
Anyway this result is good and open the possibility of using ngspice in SpicySWAN for this kind of circuits.
I will ask Ed to add the required options.
About IC setting I don't understand the setting you used. To get compatibility among DWS and Spice it is enough to use
for Spice the DWS IC setting (V,I) in this way:(V,I,V,-I). In fact at steady state the TL acts as a short circuit and so the at
itsports V1=V2=V and I1=-I2=I. This was the reason why we decided 30years ago to use the simplified syntax for DWS
instead of the Spice syntax that seems not to have a physical meaning if the previous relationships are not verified.
By default Spice syntax accepts also one couple of values but sets the port2value to zero, and this was the reason of
the results discrepancies with respect DWS.
In SpicySWAN it will possible to correct this issue in order to get the same results both in Spice and SWAN mode (DWS).
I will send you the ZY-TL circuits that had convergence problems.
Last edit: Piero Belforte 2015-11-29
screenshot.19-09-2015 14.01.23.jpg
X
TL_OSCILL_GEN_TEST_report.pdf
X
TL_C_OSCILLATOR_TEST4_report.pdf
X

Robert Larice
2015-09-20
 "marcel hendrix" <mhx...> writes:

 > ...
 >
 > About IC setting I don't understand the setting you used.
 >
 > That's a question for Robert Larice! I also don't
 > understand his mapping.
 >
 > -marcel

 The ic is about initializing the "past" of the
 forward and backward travelling wave
 in the modelled transmission line.

 As the forward wave (travelling from port 1 to port 2)
 evolves from the interaction of the backward wave
 and the circuit attached to port 1
 it is natural to specify the initial forward wave
 in terms of the past voltage and current at port 1
 which yields:
 intial_forward_wave = (v1_past + i1_past * Z0)/2

 and similar

 the backward wave (travelling from port 2 to port 1)
 evolves from the interaction of the forward wave
 and the circuit attached to port 2
 which yields (note the current i2 is *into* the device)
 initial_backward_wave = (v2_past + i2_past * Z0)/2

 Those four values are expressed in the ic condition
 ic = v1_past, i1_past, v2_past, i2_past
 for the spice 3 "tra" model.

 From my paper and pencil simulation, I knew the "past"
 of the voltages and currents at port 1 and port 2
 at time minus 0, just before the first step, to be
 0v, 30mA, 0.5V and 0mA
 (to verify, look at the plots of i1 and u2
 at the end of the fourth step, and note, this is a period circuit,
 the end of step 4 is identical to time minus 0)

 Which means, I've directly used the actual circuit values
 to initialise the tran model.

 But if you look at the above equations,
 each of them have one excess freedom.
 You can insert any other pair v1_past, i1_past
 into the first equation

 initial_forward_wave = (v1_past + i1_past * Z0)/2
 as long as it expresses the same forward wave
 v1_past_alternative = v1_past + c_1
 i1_past_alternative = i1_past - c_1/Z0
 for arbitrary c_1

 similar
 v2_past_alternative = v2_past + c_2
 i2_past_alternative = i2_past - c_2/Z0
 for arbitrary c_2

 Because you have expressed the initial forward and
 backward wave readily with one voltage/current pair
 in your SpicySWAN model
 1V, 10mA
 You can just use this tuple as well for the spice 3 "tra"
 model, but have to take care that i2 is *into* the line,

 Thus you can translate from SWAN
 ic = v_swan, i_swan
 to spice 3 "tra"
 ic = v_swan, i_swan, v_swan, -i_swan

 And, see above, in terms of simulation those two
 ic = 0v, 30mA, 0.5v, 0mA
 and
 ic = 1v, 10mA, 1v, -10mA
 yield exactly the same result. (c_1 = 1, c_2 = 0.5)

 Regards,
 Robert
Francesco Lannutti
2015-09-19
Hi Marcel,
do you mean we have to change the model to insert additional resistors in the circuit matrix ?
marcel hendrix
2015-09-19
No, the TL model is fine. The 'no-dc-path' problem turns up here because the default setting for NGSPICE
is that gmin is off. Piero doesn't have the problem because in SpicySWAN he puts GMIN=1e-12 on the .OPTIONS
line.

Francesco Lannutti
2015-09-19
In fact by default it must be OFF, but then the Dynamic GMIN Stepping Algorithm should start, since the circuit isn't
converging by itself. Is it starting?
Anyway I discovered a strange thing in the SPICE3 code when I worked on the KCL Verification: the implemented
GMIN stepping isn't what we believe it is... I mean it isn't topological, which means it isn't based upon the circuit, so
it doesn't add a GMIN between every node and ground, but it adds a GMIN in the diagonal of the reordered Sparse
Matrix and it doesn't pay attention if a node is Voltage or Current.
So I talked first with Larry and he explained to me that the original GMIN stepping algorithm he invented and put in
SPICE2 is actually topological. So it means that the difference happens only in SPICE3.
So I talked then with Alberto Sangiovanni-Vincentelli and he confirmed that the SPICE3 version of GMIN stepping
algorithm is actually another thing. It just alters the diagonal and it's an homotopy method (like others), but it isn't
a GMIN stepping as we intend.
In my KCL Verification branch I restored the original behavior, by creating a new code for this part (and actually I
made more, but this is another story!.
Last edit: Francesco Lannutti 2015-09-19
marcel hendrix
2015-09-19
but then the Dynamic GMIN Stepping Algorithm should start. Not when we specify UIC , like here.
-marcel
Francesco Lannutti
2015-09-19
Is it correct??? UIC should just specify to use some voltages or currents as starting point, instead of 0. It doesn't
mean fixing a node, like .nodeset does, isn't it?
Fra
marcel hendrix
2015-09-19
Good point! For the circuit under consideration I don't think it is a problem, but in general UIC is only a
suggestion and the simulator may ignore the request. Is it possible to specify impossible initial conditions
with .IC ? (i.e. two caps in parallel with different voltages)
-marcel

Francesco Lannutti
2015-09-19
Well, it depends on how the code is written.
For capacitors, I double checked and 'vcap' is equal to the Initial Condition, if this condition is true:
cond1=
( ( (ckt->CKTmode & MODEDC) &&
(ckt->CKTmode & MODEINITJCT) )
|| ( ( ckt->CKTmode & MODEUIC) &&
( ckt->CKTmode & MODEINITTRAN) ) ) ;
So it seems to set the initial condition just when DC is in INITJCT status (I don't know when it happens) or when TRAN
is at the INIT stage.
But this code is inside 'CAPload.c' so it's referred to just one capacitor, so it means that every Initial Condition is
private and no check is performed, so I would say that it's possible to have 2 caps in parallel with different voltages
and each one generates its private 'qcap' (the charge) in the state vector. The Circuit Matrix should not be affected.
Piero Belforte
2015-09-19
Just for remarking the differences between a nodal analysis simulator like Spice and a Digital wave processor, DWS
doesn't need any additional conductance (GMIN) for grounded caps. GMAX and GMIN can be also set as options in
DWS (not yet in SPICYSWAN) but only to limit the max dynamic range of impedances.
Another important difference regards the time step that in DWS is always fixed, but due the speed of DSP
processing very small time step can be used without incurring in large sim times. The typical DWS throughput is in
the order of MegaSamples/sec while Spice is in the order of 10Ksamples/sec.
Due to quadratic dependence of integration error vs. time step it is very easy to control the DWS error simply
running the same sim at different tsteps. In this way it is very easy to get very accurate results even at very large
TSTOP/tstep (up to several hundreds of Million samples) values as the circuits we are testing here.
For reference:
https://www.researchgate.net/publication/272576412_DWS_8.5_USER_MANUAL
Piero Belforte
2015-09-19
DWS vs. Ngspice comparison of previous test circuit.

TL_OSC_TEST4_COMPARISON.jpg
X
Piero Belforte
2015-09-19
In the posted comparison the differences are probably due to the fact that the DWS sim is obtained using a 100fs tstep
and so should be more accurate than the ngspice result that used a td/100 option where td=500ps and td/100=5ps.
Using lower values like td/1000 doesn't give any results using online ngspice.
TL_OSC_TEST4_COMPARISON.jpg
X
Piero Belforte
2015-09-19
This test ckt seems out of reach of ngspice:
Here the 2ns sim windows is after 20usec from the start. A short time step (<1ps) is required to get enough accurate
results. I tried with td/100 (5ps) on ngspice online but didn't get any result.
X

Piero Belforte
2015-09-19
Marcel,
in this case the TSTART was set to 19998ns and TSTOP to 20us, (2ns window) so there should be not any problem of
data size.
Piero Belforte
2015-09-19
Marcel,
the Spicy SWAN report you used to extract the .TRAN statement is in SWAN MODE and uses the DWS syntax that is
similar but not the same as Spice. You have to translate it as you wrote :.TRAN 1ps 2us 1.9998us 1ps.
Piero Belforte
2015-09-19
Limiting to 2us the delay after the startup, and setting td/100 (5ps) on ngspice, the comparison with DWS (1ps TSTEP)
is good.
TL_OSCILLATOR_TEST5_COMPARISON_AFTER_2us.jpg
X
Piero Belforte
2015-09-19
This is what I got using 2ps max tstep for ngspice and 1ps tstep for DWS. If I decrease max tstep to 1ps on ngspice
online I didn't get any result. Anyway the result is quite good.
This is the netlist I used for ngspice:

* TL_5 transmission line oscillator with charged capacitive loads (opposite charges)
.param td=0.5n
t0 2 0 1 0 z0=50 td={td} ic=0,0m,0,0m ; ic=1,10m
c1 2 0 10p ic=1
r1x 2 0 10G
c2 1 0 10p ic=-1
r2x 1 0 10G
.options reltol=0.1e-3
.temp 27
.TRAN {2e-12} 2000e-9 1998e-9 uic
.end
TL_OSCILLATOR_TEST5_COMPARISON2.jpg
X
Piero Belforte
2015-09-19
I also tried to set TMAX=2ps in .options but it seems not to work as does {2e-12} in the .TRAN statement.
I tried to use TMAX=2ps in the .options instead of {2e-12} in the .TRAN, but it seems not working in the same way.
.options reltol=1e-6 seems the lower limit to get a result from online ngspice , even if there is no apparent effect on
waveform behavior. The max tstep setting seems more important than reltol to get more accuracy.
Piero Belforte
2015-09-19
TL_TL_OSCILLATOR_TEST
https://www.ischematics.com/webspicy/report.py?RCODE=42278830285321785820as#newwin (SWAN MODE).
The comparison is good but ngspice response is still affected, after the first pulse, by short overshoots and undershoots
that don't disappears even using max tstep=.1e-12.
Here the netlist I used:

* TL_5 : transmission line oscillator with 2 TLs
T0 2 0 4 0 Z0=50 TD=.5n IC=1,10m,1,-10m
R1 3 0 0
R2 4 0 10G
T1 3 0 2 0 Z0=100 TD=.5n
.options reltol=1e-6
.temp 27
.TRAN {.1e-12} 10e-9 0e-9 uic
.end
TL_TL_OSCILLATOR_TEST_COMPARISON.jpg
X
TL_TL_OSCILLATOR_TEST_report.pdf
X
Piero Belforte
2015-09-19
Here a detail of ngspice edges. The first 3 pulses don't show this aberration..
ngspice_edge_detail.jpg
X
Piero Belforte
2015-09-19
Here a detail of the same DWS (tstep=1fs) for comparison. In this case the edge total rise time is 1fs (=tstep).

DWS_EDGE_TSTEP=1FS.jpg
X
Piero Belforte
2015-09-19
Tried (.1p), nothing changes (ckt TL_TL_OSCILLATOR_TEST).
.TRAN .1p 9.505e-9 9.495e-9 .1p uic
gives the same result of:
.TRAN .1p 9.505e-9 9.495e-9 uic
Piero Belforte
2015-09-19
This one is not so good:
TL_5_new : transmission line oscillator with 2 TLs
T0 2 0 4 0 Z0=50 TD=.501n IC=1,10m,1,-10m
R1 3 0 0
R2 4 0 10G
T1 3 0 2 0 Z0=100 TD=.503n
.temp 27
.TRAN 1p 9.505e-9 9.495e-9 1p uic
.end
screenshot.19-09-2015 22.36.46.jpg
X

Piero Belforte
2015-09-19
...Trying to get a better result decreasing TMAX (4th param) to .5p.
TL_5_new
* Desc: transmission line oscillator with 2 TLs
T0 2 0 4 0 Z0=50 TD=.501n IC=1,10m,1,-10m
R1 3 0 0
R2 4 0 10G
T1 3 0 2 0 Z0=100 TD=.503n
.temp 27
.TRAN 1p 9.505e-9 9.495e-9 .5p uic
.end
screenshot.19-09-2015 22.50.09.jpg
X
Piero Belforte
2015-09-19
Same as above, enlarged plot window. BOUNCING ON EDGES DUE TO DELAY SKEWS WITH OVERSHOOTS.
.TRAN 1p 10e-9 9e-9 .5p uic
screenshot.19-09-2015 22.54.52.jpg
X

Piero Belforte
2015-09-19
Same as above, DWS (tstep=1fs).
screenshot.19-09-2015 23.01.19.jpg
X
Piero Belforte
2015-09-19
Rough comparison.
screenshot.19-09-2015 23.08.03.jpg
X

Piero Belforte
2015-09-19
More accurate DWS/ngspice comparison. Edge aberrations and a delay error are visible in the ngspice result. The delay
error is due to the 500fs limit in decreasing Max tstep while DWS sim ran at tstep=1fs. EDGE aberrations seem unavoidable
in ngspice.
screenshot.19-09-2015 23.18.29.jpg
X

Piero Belforte
2015-09-19
What happens 1 usec after the startup?
Here the answer (SWAN MODE):
https://www.ischematics.com/webspicy/report.py?RCODE=62188782653511864103as#.Vf3kV0CLTDc
10 Megasamples calculated, 5K plotted. Not able to get the result with ngspice.
TL_TL_OSCILLATOR_TEST2_report.pdf
X
Piero Belforte
2015-09-20
Ed is working to fix the TL IC issue and to add TMAX in SpicySWAN when working in Spice mode. In this way it will be
possible to try directly using SpicySWAN in Spice mode.
In the meantime you can try this netlist I tried on online ngspice with no result.
TLOSCILLATORTEST2
*transmission line
*oscillator with 2 TLs and delay skews
T0 2 0 4 0 Z0=50 TD=.501n IC=1,10m,1,-10m
R1 3 0 0
R2 4 0 10G
T1 3 0 2 0 Z0=100 TD=.503n
.temp 27
.TRAN 1p 1000e-9 999e-9 .5p uic
.end
Piero Belforte
2015-09-20
Here the comparison DWS/ngspice. The result is good even if the ngspice waveform (green) looks more smoothed due to
edge aberrations.

screenshot.20-09-2015 12.36.39.jpg
X
Piero Belforte
2015-09-20
The reference is the waveform obtained with a enough small tstep possibly working at fixed tstep because it easy to
evaluate the error magnitude. In this case there are only TLs so the only cause of error is time delay discretization. At fixed
step delay discretization error can be 0 if you choose a time step that is the MCD of all time delays present in the circuit. In
this case 1ps is small enough because the delays involved are 501ps and 503ps. At 1ps tstep the integration error should be
virtually 0 because no other reactive element is present in the circuit. The only approximation is the rise time of edges that
is theoretically 0 (infinite bandwidth).
At variable tstep this assumption is no longer valid. That is the cause of differences between DWS (reference) and ngspice.
In fact, using Microcap11 at FIXED TSTEP the differences with DWS for this class of circuits (TL only) are virtually 0 (1e-6).
I agree with you that with a 1000X longer time the differences can be not so small. The problem it to verify that due do to
long spice times.
Piero Belforte
2015-09-20
For reference, here the Interactive plot of previous simulation in SWAN mode with a time step of 10fs, 1GIGASamples
calculated (10usec/10femtosec) and 10Ksamples plotted on a 10ns window (1ps step between plotted samples):
https://plot.ly/~piero.belforte/5116.embed
You can zoom in, pan, etc.
I added also the instantaneous power exchanged by the two TLs as calculated by DWS.
screenshot.20-09-2015 11.28.44.jpg
X

marcel hendrix
2015-09-20
Indeed, NGSPICE (even the latest version) shows substantial overshoots on the discontinuous edges of the TL waveform.
The overshoots are related to the maximum timestep: in the flat portions of the waveform the steps increase to TMAX and
then the steep dv/dts take the engine by surprise. The resulting overshoot takes on the order of 10fs, which is quite
good considering the TMAX of 500fs.
Here is a comparison with LTspice, which performs really outstanding here (although 3 times slower than NGSPICE). It
looks like LTspice is tracking the dV/dt of the waveform.
TL OSCILLATOR TEST2
* transmission line oscillator with 2 TLs and delay skews
T0 2 0 4 0 Z0=50 TD=.501n IC=1,10m,1,-10m
R1 3 0 0
R2 4 0 10G
T1 3 0 2 0 Z0=100 TD=.503n
.temp 27
.TRAN 1p 1u 0 .5p uic
.end
test8_lts.png
test8_ngs.png
Piero Belforte
2015-09-20
Yes, looks like Microcap11 at fixed tstep. Microcap11 (not 10 that had issues I pointed out) gives results very similar to
DWS even if 100X slower.
Unfortunately Microcap11 doesn't support IC for TLs.
The ULTIMATE SOLUTION of these problems is to disable the time step control and SIMULATE AT FIXED TIME STEP.

Piero Belforte
2015-09-20
I tried to see what is happening after 1millisecond after the startup (10ns window, 500fs DWS TSTEP, 2 GIGAsamples
calculated). This means after 1 MILLION back and forth signal reflections.
Attached the result. Can you try with ngspice to get the comparison?
screenshot.20-09-2015 12.44.21.jpg
X
marcel hendrix
2015-09-20
I estimate that will take about 26 hours, and the accumulated error will be far out of bounds by then.
So you must be joking :-)
Piero Belforte
2015-09-20
On my 5 year old PC it takes about 10minutes confirming the 2 orders of magnitude speedup of DWS.
Piero Belforte
2015-09-20
Microcap10 vs DWS comparison:
https://www.researchgate.net/publication/272818521_DWS_VS_MICROCAP_10_PERFORMANCE_AND_ACCURACY_COMP
ARISON_FOR_RL-TL_CIRCUIT_SIMULATIONS

Microcap11 vs DWS (video)
https://www.youtube.com/watch?v=zgo3LI5Eevw
More comparison videos are available here: https://www.youtube.com/playlist?list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G
Here a DWS vs. ngspice comparison in frequency domain (open TL):
https://www.researchgate.net/publication/273612257_OPEN_TRANSMISSION_LINE_OUTPUT_VOLTAGE_FREQUENCY_RES
PONSE_NGSPICE_VS_DWS_VVNA_.1-5GHz
Piero Belforte
2015-09-20
Other Spice/DWS benchmarks (no TLs):
https://www.researchgate.net/publication/272790267_DWS_VS_NGSPICE_SIMULATION_ERROR_COMPARISON_50Mhz_L
C_OSCILLATOR?ev=prf_pub
https://www.researchgate.net/publication/272790665_RL-
DIODE_CHAOTIC_BEHAVIOR_DWS_VS_SPICE_%28MICROCAP11%29
https://www.researchgate.net/publication/273061993_SPICE_INTEGRATION_ERROR_OF_A_10-
CELL_LC_CIRCUIT_STEP_RESPONSE_AFTER_1MICROSECOND_%28COMPARISON_TO_EXACT_DWS_SIMULATION%29?ev=pr
f_pub
Piero Belforte
2015-09-20
Other Spice/DWS benchmarks (no TLs):
https://www.researchgate.net/publication/272790267_DWS_VS_NGSPICE_SIMULATION_ERROR_COMPARISON_50Mhz_L
C_OSCILLATOR?ev=prf_pub
https://www.researchgate.net/publication/272790665_RL-
DIODE_CHAOTIC_BEHAVIOR_DWS_VS_SPICE_%28MICROCAP11%29
CELL_LC_CIRCUIT_STEP_RESPONSE_AFTER_1MICROSECOND_%28COMPARISON_TO_EXACT_DWS_SIMULATION%29?ev=pr
f_pub

Piero Belforte
2015-09-20
Example of simple and famous circuit that older Spice version cannot simulate:
https://www.researchgate.net/publication/273096086_CHUA%27S_CIRCUIT_POWER_ORBITS_BY_DWS?ev=prf_pub
Here a complex pcb model netlist (220K scattering elements):
https://www.researchgate.net/publication/274133190_EXAMPLE_OF_COMPLEX_MULTILAYER_PCB_DWS_MODEL_EXTRA
CTED_FROM_MANUFACTURING_FILES_BY_POST-LAYOUT_APPLICATION_PRESTO
Piero Belforte
2015-09-20
In the past pwl resistor were not supported by Spice because of derivative discontinuities. If they are now supported by
ngspice we have to include them in SpicySWAN (Spice mode).
Tried on online ngspice: I get this error message:
ngspice stopped due to error, no simulation run!
ERROR: fatal error in ngspice, exit(1)
Circuit: c1 1 0 3 ic=-0.2281
Error on line 8 : .tran 0 1000 800 10m uic
TSTEP is invalid, must be greater than zero.
It would be interesting to compare ngspice result with DWS. Chaotic circuits are very sensitive to used
simulator/machine/Operating System and it is practically impossible to get the same result when the time evolves.
Here the 3D interactive plot of DWS version (you can change the viewpoint
moving the mouse):
https://plot.ly/122/~piero.belforte/
Attached a first rough comparison, Blue=ngspice, red DWS(should be made using plots vs. time),
CHUA_ngspice_vs_DWS.jpg
X

Piero Belforte
2015-09-20
SpicySWAN ( ngspice + DWS) concepts:
https://www.researchgate.net/publication/272026691_Spicy_SWAN_concepts
Piero Belforte
2015-09-20
Marcel,
I tried this CHUA ngspice version online:
C1 1 0 3 ic=-0.2281
C0 2 0 0.1111111111 ic=0.15264
L0 1 0 0.142857142 ic=0.38127
R0 2 1 1.42857142
B0 2 0 I = pwl(V(2), -2.2,0, -2.1,0, -2,1.3, -1,800m,
+ 1,-800m, 2,-1.3, 2.1,0, 2.2,0)
.tran 1m 500 0 1m uic
.options reltol=0.1m
.end
Attached the comparison (ngspice red/blue)
CHUA_STARTUP_DWS_VS_NGSPICE.jpg
X
Piero Belforte
2015-09-20
Don't worry about the differences, that's normal dealing with chaotic circuits.
In the past we noticed these differences even on the same machine using DWS under different OSs (Windows7/LINUX
Ubuntu).
If you change TMAX you will see a fully different startup.

Piero Belforte
2015-09-20
Yet another comparison:
https://plot.ly/738/~piero.belforte/
Piero Belforte
2015-09-21
CHUA STARTUP DWS/ngspice COMPARISON
Marcel,
I found that ic of C1 you set (ic=-0.2281) a 0 is missing. Setting the correct value (ic=-0.02281) the startup of DWS and
ngspice are more similar than the previous results. Attached here the collage reporting the comparison for two different
DWS tstep settings (1 and 2 ms).Ngspice TMAX is always set to 2ms.
CHUA STARTUP COMPARISON.jpg
X
Piero Belforte
2015-09-21
TL-SWITCH TEST CIRCUIT
Marcel,
here another test circuit involving both ideal TLs and SWITCHES that you should try using ngspice for comparison.
Piero Belforte
2015-09-21
1fs

Piero Belforte
2015-09-21
TL-SWITCH TEST CIRCUIT
Marcel,
here another test circuit involving both ideal TLs and SWITCHES that you should try using ngspice for comparison.
TL_TL_OSCILL_SW_TEST.jpg
X
TL_TL_OSCILL_SW_TEST_report.pdf
X
marcel hendrix
2015-09-21
Total elapsed time: 160.705 seconds.
TL_TL_OSCILLATOR
* transmission line oscillator with 2 TLs
* Desc: switched transmission line
* oscillator: precharged tl with nop switch at port2
* and connected to a tl with nc switch at port2.
T0 6 0 out2 0 Z0=50 TD=.5n IC=1,10m,1,-10m
T1 out1 0 6 0 Z0=100 TD=.5n
S0 out1 0 0 7 switch_nc
.model switch_nc SW(Ron=1u Roff=10G Vt=-0.5 Vh=-0.1)
S1 out2 0 7 0 switch_no
.model switch_no SW(Ron=1u Roff=10G Vt=0.5 Vh=-0.1)
V0 7 0 PULSE(-1 1 10ns 1fs 1fs 10ns 20ns)
.OPTIONS method=gear reltol=0.1m
.TEMP 27
.TRAN 0.1ps 1u 980n 0.1ps uic
.END
.end
tl_tl_oscillator.png

Piero Belforte
2015-09-21
DWS (tstep=100fs) elapsed time: 8sec on my pc ( Intel Quad-Core i7-2630QM 2.00GHz CPU). DWS/ngspice speedup is
only 20X in this case (if the CPU of your machine is comparable to my CPU).
The matching is good except the spikes (see first attachment, detail of DWS 400fs spike).
screenshot.22-09-2015 00.32.21.jpg
X
TL_TL_OSCILL_SW_TEST_DWS_VS_Ngspice.jpg
X
screenshot.21-09-2015 23.59.42.jpg
X
Piero Belforte
2015-09-21
The differences can be due to:
1) the 100fs (one tstep) delay of DWS switches with respect control voltage threshold crossing)
2) Ngspice TL overshoots (could be eliminated disabling the time step control). Notice that not all spikes are
over/undershoots.

Piero Belforte
2015-09-21
Simulated at 10fs tstep, elapsed time=30sec (Strange, I expected 10X8=80sec). The spike duration is 1/10 of 100fs sim,
confirming that can be due to not perfect synchronism of reflections with control voltage (could be compensated by
anticipating the control voltage transitions of one tstep). See attachment.
screenshot.22-09-2015 00.56.12.jpg
X
Piero Belforte
2015-09-21
V0 7 0 PULSE(0 1 9999.7ps 0ns 0ns 10ns 20ns) : 300fs delay compensation on control voltage with tstep=100fs , the spikes
disappear.
screenshot.22-09-2015 01.25.34.jpg
X

Piero Belforte
2015-09-22
Ron is 1microohm (1/GMAX default). Default values for DWS are : GMIN=1e-6 GMAX=1e9 , but can be set as options to
different values (not yet in Spicy SWAN).
Piero Belforte
2015-09-22
Just tried with .OPTIONS GMIN=1E-12 GMAX=1E12 (Ron=1picoohm, Roff=1000Gohm) but obviously I didn't get visible
changes.
Piero Belforte
2015-09-21
Here the skewed delays version:
TL_TL_OSC_SKEW_SW_TEST_report.pdf
X
o
marcel hendrix
2015-09-21
Total elapsed time: 3325.485 seconds.
TL_TL_OSCILLATOR
T0 6 0 out2 0 Z0=50 TD=.503n IC=1,10m,1,-10m
T1 out1 0 6 0 Z0=100 TD=.501n

.OPTIONS method=gear reltol=0.1m
.TEMP 27
.TRAN 0.1ps 1u 980n 0.1ps uic
.END
.end
tl_tl_oscillator_skewed.png
Piero Belforte
2015-09-21
DWS elapsed time (100fs tstep)= 7sec. DWS/NGS SU=475.
Attached the comparison. Overall behavior is similar but not the same.
Ngspice response (lighter color) has spikes with greater amplitude.
screenshot.22-09-2015 01.42.09.jpg
X
TL_TL_OSC_SKEW_SW_TEST_DWS_VS_NGS.jpg
X
Piero Belforte
2015-09-22
DWS detailed views (100ps and 10ps windows attached. Here the related .TRAN:
.TRAN UIC TSTEP=100e-15 TSTOP=995e-9 TSTART=994.9e-9 LIMPTS=10000 V(2) V(3).

The "spikes" due do control voltage delay are visible.
screenshot.22-09-2015 07.32.17.jpg
X
screenshot.22-09-2015 07.29.29.jpg
X
Piero Belforte
2015-09-21
CSV sim outputs for ngspice
Marcel,
I think this comparison activity is very important to pinpoint problems and find solutions. To get better result comparison , I
need sim results in the .csv format . This is already possible in SpicySWAN for both ngspice and DWS, but for the circuits
not yet supported by SpicySWAN (as your CHUA circuit) the csv version of ngspice results is not available. Are you able to
convert the results of your sims in .csv format?
o
marcel hendrix
2015-09-21
o
I fixed the initial value with the extra 0. I can't generate CSV exactly, but I guess two column ASCII with first column time
and second column voltage is OK? Time is interpolated on a
10 ms raster (for this TSTEP is important!)
Not sure what this will prove.
-marcel
Chua's chaotic circuit
C1 1 0 3 ic=-0.02281
C0 2 0 0.1111111111 ic=0.15264
L0 1 0 0.142857142 ic=0.38127
R0 2 1 1.42857142
B0 2 0 I = pwl(V(2), -2.2,0, -2.1,0, -2,1.3, -1,800m, 1,-800m, 2,-1.3,
+ 2.1,0, 2.2,0)

.save all @B0[i]
.tran 10m 1000 0 10m uic
.options reltol=0.1m
.control
listing e
run
linearize v(1) v(2)
wrdata v_n001 v(1)
wrdata v_n002 v(2)
.endc
.end
v_n002.data
v_n001.data
Piero Belforte
2015-09-22
Yes, of course, but the typical model using modal adaptors and Scattering parameters blocks are not supported by ngspice.
I think that for comparison purposes only a cascade of lumped cells of mutually coupled inductors can be used.
Piero Belforte
2015-09-22
Here an example of a coupled line DWS model extracted from TDR measurements:
https://www.ischematics.com/webspicy/report.py?RCODE=54251066138512262121as#.VgES5ECLTDc
OL1_MSTRIP_TDR_P1_report.pdf
X
Piero Belforte
2015-09-22
Here a practical application, unfortunately Spice doesn't support this kind of behavioral models based on time-domain S-
parameters and fast convolution.
https://www.researchgate.net/publication/272833203_DWS_MULTIGIGABIT_MODELING_AND_SIMULATION_OF_LOSSY_
COUPLED_LINES

Using this method (pwl behavioral models and fast convolution supported by DWS), speed up in the order of 1000X-
10000X can be obtained with respect conventional NA simulators.
https://www.researchgate.net/publication/280527160_VECTOR_VS_PIECEWISE-
LINEAR_FITTING_FOR_SIGNAL_AND_POWER_INTEGRITY_SIMULATION
Piero Belforte
2015-09-22
GENERAL CONSIDERATIONS
(based on the comparative tests carried out so far):
1) The aim of this activity is to find ways to improve ngspice performance (accuracy) dealing with transmission lines at the
same level of MICROCAP11 that I have used so far for comparison.
2) We found that bounding ngspice tstep by means of TMAX parameter, a good matching with DWS is obtained even if
this is obtained at the expense of a 20X to 475X slowdown of ngspice/DWS sim elapsed time for simple test circuits.
3) What is missing in ngspice compared to Microcap11 and other sim engines (CST), is the capability of simulating at FIXED
TIME STEP. If this option is added, the issues related to spurious overshoots of TL responses could disappear and even the
sim time can be improved. These overshoots are short compared to TMAX and are due to time step control algorithm, but
compromise the overall simulation look. LTspice (and Microcap11 as well) seems able to avoid these spurious effects even
when working at variable (small) time step.
4) The ngspice choice for TMAX default setting (1/50 of sim window) is not so good for TLs because the edge aberrations
depend on selected window and this looks like a bug of the simulator.
5) Further analysis can be carried out on RLC-TL cellular circuits used to model losses (skin effect, dielectric etc.) and to
effects on nonlinear clamps on TL circuits.
6) SpicySWAN next release will introduce the TMAX setting in spice mode, and will fix the IC syntax compatibility issue for
TLs.
7) CHUA circuit tests have proven a good agreement between DWS and ngspice sim results.
Piero Belforte
2015-09-22
CLAMPED TL TEST CIRCUIT
Here the reports:
Startup 0-20ns tstep=100fs, DWS elapsed time=0.3 sec

Here the related interactive plot (10Ksamples)
After 10us tstep=1ps DWS elapsed time=6.6 sec
https://www.ischematics.com/webspicy/report.py?RCODE=23157302264054063524as#.VgE3R0CLTDc
Interesting to compare to ngspice.
TL_TL_OSCILLATOR_CLAMP1_TEST_CIRCUIT.jpg
X
TL_TL_OSCILLATOR_CLAMP1_report.pdf
X
X
Piero Belforte
2015-09-22
1Kohm .5V clamp:
Here the clamping effect requires more than 100ns (see dissipated power vs. time).
X
Piero Belforte
2015-09-22
LOSSY LINES COMPARISON.
A good first step can be the distributed RC line. Ngspice supports this element (URC). DWS and SpicySWAN supports the
CHAIN of cells (.CELL) so up to 9999 cells can be connected in cascade with a single statement. Defining an elementary unit-
length RC cell, several cells can be connected in cascade in a simple way.
Proposed test circuit:

DWS sim elapsed time (tstep=5ps TSTOP=20ns)= 100 milliseconds
Another example here;https://www.facebook.com/SpicySchematics/photos/pb.185523688163451.-
2207520000.1442932636./440613262654491/?type=3&theater
TDR_RC_LINE2_report.pdf
X
Piero Belforte
2015-09-22
My proposal for URC utilizes only 100 cells.
Can you propose a simple single-line example using LTRA?
Looking at ngspice manual it seems to me that LTRA model based on RLCG matrix is not suitable for modeling skin effect
and dielectric losses. The usual method utilized for these losses is based on Vector Fitting of theoretical expression of
losses. This method produces a ZY-TL per unit length (pul) cell . To simulate this model a good TL model is needed and it is
mandatory to work at subpicsecond time steps. With these constraints Spice becomes very slow as you can imagine.
Here an example of comparison between models for a coaxial cable.
366_RLT_LOSSY_CMP_report.pdf
X
Piero Belforte
2015-09-22
Here an already developed ngspice/DWS test comparison related to skin effect losses of lossy interconnects (the real cell
is much more complex that the cell of this test circuit). TMAX setting was not used for this example. By zooming in you
will notice the differences. The effect of tstep control in ngspice is clearly visible.
Sim report (Spice mode, no TMAX set)
https://www.ischematics.com/webspicy/report.py?RCODE=33438110358552445324a#newwin
Here the SWAN mode version with 2 cell alternatives:
screenshot.22-09-2015 18.01.48.jpg
X

screenshot.22-09-2015 17.51.31.jpg
X
RLTL_10CELL_COMPARE_report.pdf
X
RLTL_10CELL_SPICE_report.pdf
X
Piero Belforte
2015-09-22
And here the DWS (100 attosecond time step) comparison with Microcap11 at fixed time step (1fs)
NO VISIBLE DIFFERENCE except the elapsed time (about 100X).
Sometime after the publication of my report about Microcap10 vs. DWS issues on the web, Spectrum Software corrected
them so they are no longer present in the above plot.
Piero Belforte
2015-09-22
Tried on ngspice online TMAX=10fs (minimum allowed due to sim time) The overshoot disappears. The result comparison
is good (see attached detail, red ngspice, blue DWS).
RLTL TEST
.OPTIONS ABSTOL=1e-12 GMIN=1e-12 PIVREL=1e-3 PIVTOL=1e-13 RELTOL=1e-3 VNTOL=1e-6 CHGTOL=1e-14 TRTOL=7
METHOD=TRAP ITL1=2000 ITL2=1000 ITL3=500 ITL4=200 ITL5=10000 NODE
CKT START
R0 N_VIN UN_3 1
L0 N_VIN UN_3 10p
T0 UN_3 0 UN_4 0 Z0=50 TD=10p
R2 UN_4 UN_5 1
L2 UN_4 UN_5 10p
T2 UN_5 0 UN_6 0 Z0=50 TD=10p
R3 UN_6 UN_7 1
L3 UN_6 UN_7 10p
T3 UN_7 0 UN_8 0 Z0=50 TD=10p
R4 UN_8 UN_9 1
L4 UN_8 UN_9 10p
T4 UN_9 0 UN_10 0 Z0=50 TD=10p
R5 UN_10 UN_11 1
L5 UN_10 UN_11 10p
T5 UN_11 0 UN_12 0 Z0=50 TD=10p
R6 UN_12 UN_13 1
L6 UN_12 UN_13 10p
T6 UN_13 0 UN_14 0 Z0=50 TD=10p

R7 UN_14 UN_15 1
L7 UN_14 UN_15 10p
T7 UN_15 0 UN_16 0 Z0=50 TD=10p
R8 UN_16 UN_17 1
L8 UN_16 UN_17 10p
T8 UN_17 0 UN_18 0 Z0=50 TD=10p
R9 UN_18 UN_19 1
L9 UN_18 UN_19 10p
T9 UN_19 0 UN_20 0 Z0=50 TD=10p
R10 UN_20 UN_21 1
L10 UN_20 UN_21 10p
T10 UN_21 0 N_VOUT 0 Z0=50 TD=10p
R11 N_VIN UN_23 50
R12 N_VOUT 0 50
V0 UN_23 0 PULSE(0 2V 0ps 1ps)
.TEMP 27
.TRAN '(200e-12-0e-9)/1000' 200e-12 0e-12 1e-14
.print DC I(V0) V(N_VIN) V(N_VOUT)
.print AC I(V0) V(N_VIN) V(N_VOUT)
.print TRAN I(V0) V(N_VIN) V(N_VOUT)
10RLT_TEST_DWS_VS_NGS.jpg
X
screenshot.22-09-2015 18.51.45.jpg
X
marcel hendrix
2015-09-22
A fixed-step integration routine is impossible for general non-linear circuits as it cannot guarantee convergence and
bounded errors, especially on a long time scale, and because it would be impossibly slow on circuits with a stiff circuit
matrix. A further problem is that for very small fixed steps the floating-point round-off errors become significant
and put an upper boundary on the minimum timestep. However, for special circuits and special conditions
I can imagine a workaround. Here, as the user sets the fixed timestep, this not only gets rid of the convergence issue, it is
also a hint on the maximum expected bandwidth of the signals. Put another way, the fixed timestep can be seen as a
sampler action, and therefore it would be mandatory to appropriately low-pass filter all signals before further processing
them.
A possible implementation is to add a (hidden) low-pass RC filter before and after each transmission line, switch/diode,

generators etc., with a cut-off depending on the timestep. Or, much easier to implement, to average the signals over the
fixed timestep before plotting them. The last algorithm would turn visually objectionable low-energy spikes into flat-top
pulses with slightly wrong amplitudes. The error could be controlled by RELTOL, as long as the circuit matrix is not too
stiff.
Piero Belforte
2015-09-22
Yes, but why other NA tools already implement the fixed step option without apparently any problem?
I could suggest you to install the Microcap11 free evaluation version and try by yourself.
http://www.spectrum-soft.com/demoform.shtm
examples of NONLINEAR TL circuit simulated by Microcap11 at fixed step:
https://www.youtube.com/watch?v=I27LZRAWhFY&list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G&index=14
https://www.youtube.com/watch?v=FxoyXuoxcGk&index=11&list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G
RL-DIODE CHAOTIC CIRCUIT
https://www.youtube.com/watch?v=9qdr0VhKJtQ&list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G&index=14
Linear LC-TL circuit
https://www.youtube.com/watch?v=JSgwIhcaFpk&list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G&index=19
Piero Belforte
2015-09-23
I don't see the need of adding low pass filters in case of (small) fixed time step. This is not needed in DWS but also in
other NA simulators like Microcap11 and CST.
Piero Belforte
2015-09-23
This is how DWS works: the parameters of time-invariant digital wave blocks are calculated once on the basis of the user
defined tstep at the start. Then the DW processing starts (without solving nodal equations) simply by incrementing the
time of time step multiples (like a digital filter). No iteration is needed even for non-linear elements. In case of spice-like
.models (e.g. junction diodes and bjt), the NR iteration in only local at each time step.
The output results are generated by resampling ( linear interpolation) the calculated samples on the basis of the user
defined .TRAN parameter LIMPTS (number of output samples in the TSTART-TSTOP window ) defined by the user. When
working at very small tsteps as in the previous test circuits the ratio between the calculated samples and LIMPTS can be

very large. Typically of millions samples calculated (up to 2 billions) only several thousand (5K max in Spicy SWAN to limit
transmission time) are saved in the output file.
In Spice, in case of fixed time step, I don't see the need of low-pass filtering of calculated samples. Linear interpolation is
enough to get the out samples (on the basis of the user defined tstep parameter in .TRAN) as DWS does. Stability issues
can rise due to sparse matrix solver within the NR loop involving the whole network. These issues have been evidently
solved in some way within Microcap11 and other NA tools allowing fixed tstep.
Piero Belforte
2015-09-23
o
By the way, I discussed years ago this topic with my friend Paolo Nenzi who knows the DW techniques. The idea was to
create an hybrid NA-DW tool merging ngspice with DWS. Much more simply the choice was to merge them in an hybrid
tool (SpicySWAN) where the two engines share the same schematic editor. This project was carried out in cooperation
with Ed Pataky, founder of Ischematics, who has been a pioneer in cloud-based circuit analysis tool (ngspice based Spicy)
for mobile and web.
Piero Belforte
2015-09-23
Compared here the sim setting windows of SpicySWAN (SWAN mode) and Microcap11 (fixed step) for the same
simulation. The parameters to set look very similar and are basically TSTART and TSTOP of the output window, and the
number of output points (LIMPTS for SpicySWAN). Circuit RL-TL_10CELLS in free oscillation configuration. The results are
practically identical, less than 10uV for the final point, with the usual 100X DWS/MC11 speedup.
SWAN_SIM_SETTING.jpg
X
MC11_SIM_SETTING.jpg
X

Piero Belforte
2015-09-22
A different application of DWS:
https://www.youtube.com/watch?v=7LH4X0xeyhk&list=PLoyVchXc6Iro65tkestKgtiKbTYzgx32G&index=19
Piero Belforte
2015-09-23
Tried to run CHUA (Marcel ngspice version) on MC11 but it doesn't accept the B element
B0 2 0 I = pwl(V(2), -2.2,0, -2.1,0, -2,1.3, -1,800m, 1,-800m, 2,-1.3, 2.1,0, 2.2,0)
Piero Belforte
2015-09-23
Sounds incredible, but the circuit TL_C_OSCILLATOR_TEST5 on Microcap 11 seems to give different results with respect
DWS(see attachment). I also checked the additional 10G resistors connected to capacitors, but this issue is still there.
TL_C_OSCILLATOR_TEST5.jpg
X
Piero Belforte
2015-09-23
Here the netlist used in MC11:
TL_C_OSCILLATOR_TEST5 (Spice version)
T0 2 0 1 0 Z0=50 TD=.5n
C1 2 0 10p IC=1V
C2 1 0 10p IC=-1V
R1 2 0 10G
R2 1 0 10G
.TRAN 4.0008e-010 2000E-9 1998E-9 1E-12 UIC
.TEMP 27

.PLOT TRAN V(1) V(2)
.options reltol=0.1m gmin=1e-12
The problem is already present at the startup
Piero Belforte
2015-09-23
Checked on SpicySWAN both in SWAN mode and Spice mode. Ed has not yet implemented the TMAX setting, so to force
ngspice tstep to a enough low value I set a 2ns window after 2us from the startup (TMAX default= 2000/50=40ps). At the
startup the DWS/ngspice results are practically coincident. At 2us some small difference due to 40ps max tstep of ngspice
see attachment).
It looks like this is a BUG of MC11.
On ngpsice if I set reltol=1e-12 the simulator crashes (please check).
TL_C_OSCILLATOR_TEST5_DWS_VS_NGS.jpg
X
marcel hendrix
2015-09-23
Now it becomes interesting.
With METHOD=TRAP RELTOL=1e-4 STEPMAX=1e-12 the amplitude of the v(1) waveform is 772.543mV at 1.99939us. With
RELTOL=1e-8 (the minimum possible before the timestep to guarantee it is less than 1e-16) that becomes 806.804mV at
again 1.99939us.
With METHOD=GEAR RELTOL=1e-4 I find 937.784mV. With RELTOL=1e-8, the minimum RELTOL for GEAR, it is 948.629mV.
RELTOL=1e-4, STEPMAX=1e-13 gives again 948.941mV, RELTOL=1e-8 STEPMAX=1e-13 give 948.776mV
For MAXSTEP between 1ns and 1p very curious effects are visible, ranging from perfect sine waves with 5V amplitude to
flat-topped things around 800mV.
This is clearly unmanageable. The error neither honors RELTOL nor STEPMAX as one would expect.
I am going to try the other TL models available in NGSPICE to see what is to "blame" here.
TL_C_OSCILLATOR_TEST5 (Spice version)
T0 2 0 1 0 Z0=50 TD=.5n
C1 2 0 10p IC=1V
C2 1 0 10p IC=-1V
R1 2 0 10G
R2 1 0 10G
.TRAN 4.0008e-010 2000E-9 1998E-9 1E-12 UIC
.TEMP 27
.PLOT TRAN V(1) V(2)

.options reltol=0.1m gmin=1e-12
Piero Belforte
2015-09-23
Sounds interesting...That confirms that checking the sim on a fully different tool as happen in SpicySWAN is a reliable way
to verify the simulation accuracy.
In my opinion the root cause of this kind of things is the time step control algorithm. By eliminating it, as happens in DWS,
these problems are eliminated. In case of doubts it is enough to simulate at lower tstep and verify that the result doesn't
change. Due to DWS speed this not a problem.
Attached the DWS simulation at 100fs tstep. .948670V is the peak amplitude at 1.99939us, ... The closest ngspice result
(from previous post):GEAR RELTOL=1e-8 STEPMAX=1e-13 give 948.776mV (error about 100uV). This accuracy is due
mainly to the ngspice STEPMAX= DWS tstep=100fs. The only problem is the long elapsed time required by ngspice at
these time steps.
screenshot.24-09-2015 00.15.16.jpg
X
Francesco Lannutti
2015-09-23
This is not possible in SPICE. I should have a Larry presentation about that.
Basically you cannot decrease or increase the timestep as much as you want to, but you need to calculate the truncation
error. In SPICE, the next timestep is decided by taking the minimum of the timesteps calculated by each instances. Each
instance depends on the model, so the truncation error depends on the model, which basically checks every dynamic
variable (if I remember correctly). There is also a minimum timestep, so that, if the circuit doesn't converge in transient
(actually I have never seen such a thing), the timestep is decreased until the minimum. If the minimum is reached, the
simulation is aborted.
Fra
marcel hendrix
2015-09-24
Dear Fra,
Your explanation matches with my understanding of how SPICE works. However:
Basically you cannot decrease or increase the timestep as much as you want to

Your explanation does NOT explain why we cannot make the timestep smaller than the minimum that SPICE decides with
its truncation error.
In fact we do force it smaller with STEPMAX. Here my assumption is that smaller steps will result in smaller errors, roughly
proportional to h^order, with h=timestep and order the error of the integration routine (between 2 and 6 for
GEAR). For RELTOL, a smaller RELTOL should result in smaller error proportional to its
decrease. Both these relationships do not seem to hold for the T line.
A first experiment could be to check if these relationships actually hold for a non-trivial SPICE circuit without T-Ls.
-marcel
Piero Belforte
2015-09-24
I just re-simulated TL_C_OSCILLATOR_TEST5 with 3 different TSTEP to show how simply the TSTEP choice works on DWS.
In the attached plots the results are shown for TSTEP=10PS,1PS,100FS. At 10PS the error is unacceptable but at 1ps the
result is already practically identical with respect the result at 100FS. The error decreases with the square of time step
while the sim elapsed time grows linearly with 1/TSTEP (and also linearly with the number of elements of the circuit) .Few
seconds are required to run all sims.
DETAIL_TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS.jpg
X
TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS.jpg
X
Francesco Lannutti
2015-09-24
Hi Marcel,
I don't think there is a real mathematical explanation for the minimum, but it could be related to the machine precision.
In NGSPICE you can set it from the .options . It should be 'delmin'. Anyway this number is very low: it's 1e-11 *
CKTmaxStep , by default.
Fra

Piero Belforte
2015-09-23
Here the separate screenshots. The netlist used for MC11 is given in the previous post. The settings of MC11 are
uninfluential on the (wrong) amplitude from the startup.
screenshot.23-09-2015 15.43.33.jpg
X
screenshot.23-09-2015 15.56.59.jpg
X
Piero Belforte
2015-09-23
The problem seems depending on TL time delay. If I decrease TD from 500ps to 20ps the circuit becomes an LC oscillator
and MC11 too gives the right amplitude (2Vpp). Also the phase is good after 2us due to TMAX=1ps setting. See
attachment.
TL_C_OSCILLATOR_TEST6_DWS_vs_MC11_TMAX_1p.jpg
X
X

Piero Belforte
2015-09-23
In this case after 2us ngspice is affected by a phase shift due to a too high TMAX. The comparison in shown in the
attachment-
TL_C_OSCILLATOR_TEST6_DWS_vs_NGS_NO_TMAX.jpg
X
Piero Belforte
2015-09-23
Increasing TD to 2ns the MC11 behavior gets wrong from the startup (too large amplitude) while ngspice matches DWS.
It seems confirmed a MC11 BUG.
On the other hand the initial discharge of caps during the first 2ns seems correct in DWS and ngspice (the TL is initially
discharged), while it is not in the MC11 response where it seems depending in some way on the charge of the opposite
cap (that's clearly impossible. With very short TLs (20ps) this error is no more clearly visible.
TL_C_OSCILLATOR_TEST7_MC11_TD_2NS_TMAX_1PS.jpg
X

marcel hendrix
2015-09-24
Hi Piero,
I did in fact install MC11 now. There is clearly a horrendous bug in its basic implementation because, given the exact
same SPICE input file as NGSPICE and your wave-based simulator, it generates a waveform with approximately (I didn't
check in detail) the same shape but more than twice the peak amplitude.
In order to cut down the forum noise level a little bit I propose that from now on we exclude MC11 from any discussion or
comparison as it is clearly unfit for (our) use.
My goal for the current discussion thread is to find out:
1. Are NGSPICE's transmission line models (not only the basic loss-less T-line but also LTRA and the KSPICE ones) correct
down to a femtosecond real-world time scale?
2. Are NGSPICE's TL models implemented correctly? For this we need a circuit model with a closed solution to compare to.
3. Is it possible to find out how to set STEPMAX and RELTOL so that understandable and predictable time- and frequency-
domain errors result? My first experiment with the T-L say this NOT the case (the error goes down, but not in an expected
manner).
4. Is it possible to substantially increase simulation speed of digital and analog electronic circuits that contain transmission
lines, while still knowing what the time-domain and frequency-domain errors are, preferably without having to do a
simulation multiple times.
-marcel
Piero Belforte
2015-09-24
Marcel,
I'm glad you directly experienced this issue.
I'm not for sure an enthusiast of Microcap , but it was chosen several years by a colleague of mine, Spartaco Caniggia, SI
and EMC expert, for his publications because it has a good TL model. In fact I directly experienced the MC11 (previous
version has a bug) good accuracy dealing with ZY-TL circuits used today to model lossy lines. The comparison I carried out
with DWS for these circuits confirmed a very good match using the same (fixed) tstep.
https://www.researchgate.net/publication/273241411_Comparison_of_time-domain_S-
parameters_of_RG58_cable_computed_by_Theory_CST_SPICE_DWS
Unfortunately I didn't get the same good results using ngspice.
Obviously my preferred tool for this class of problem is still DWS due to its outstanding speed and accuracy.
DWS was created 30 years ago to efficiently solve this class of design problems, on the basis of a previous 10-year
research and application experience of DW simulators,
I agree with your proposed points, I only would add a point about ngspice for ZY-TL circuits that are the most utilized way
to model lossy lines (cables, pcb traces etc.) even within tools like CST and ADS
https://www.researchgate.net/publication/279883333_DWS_vs_CST_CABLE_STUDIO_SIMULATION_SPEEDUP_EVALUATI
ON

Francesco Lannutti
2015-09-23
Hi guys,
I don't know if it's the case here, but remember also that SPICE doesn't verify the KCL, so you could encounter in False
Convergence points.
I have a branch with my work on KCL Verification, but it doesn't support TL.
Fra
Piero Belforte
2015-09-23
Anyway shorting the TL with a 0 ohm resistor the 3 tools give the same answer, an about 0 V steady voltage. Ngspice
shows a strange 150fs transient (attached).
If a higher value resistor is connected between the TL ports, MC11 still gives a wrong answer.
screenshot.23-09-2015 22.19.58.jpg
X
Piero Belforte
2015-09-24
We have to consider that a capacitor calculated according to the TRAP rule acts, even in Spice, as a Tstep/2 long TL (open
stub, Z0=Tstep/2C), .So when two charged caps are connected together thru a 1/Gmax resistor, as happens in this case, the
simulated circuit is equivalent to two short pre-charged TLs connected together. A train of back and forth reflections starts
up until the full energy is dissipated and the voltage reaches 0V. This phenomenon is clearly visible in DWS too (see
attachment). DWS unlike Spice starts from the values determined by the IC and not from 0V.
screenshot.24-09-2015 09.29.04.jpg
X

Piero Belforte
2015-09-24
In Spice the electrical length of this TL is varying according to the current Tstep, while in DWS it is constant during the
whole simulation time.
Sounds strange, but Spice too has to deal with TL even for concentrated constant circuits!
Piero Belforte
2015-09-24
http://digital-library.theiet.org/content/journals/10.1049/ree.1980.0006
The 3D TLM method is used to model Maxwell equations and utilized in commercial field solvers.
https://en.wikipedia.org/wiki/Transmission-line_matrix_method
I used a 2D matrix of lossy TL to model very efficiently metal planes of pcbs.
http://www.slideshare.net/PieroBelforte1/1993-an16-powerplanemodellingpb
TL is a very important circuital element! Unfortunately Spice was not conceived for TL that caused several problems in the
first Spice versions when it was introduced.
Wave digital methods have increasing applications in several scientific fields:
http://www.amazon.com/Wave-Scattering-Methods-Numerical-Simulation/dp/0470870176
The father of Wave Digital Filters:
http://ethw.org/Oral-History:Alfred_Fettweis
https://www.researchgate.net/profile/Alfred_Fettweis
Piero Belforte
2015-09-24
I just simulated TL_C_OSCILLATOR_TEST5 with 3 different TSTEP to show how simply the TSTEP choice works on DWS. In
the attached plots the results are shown for TSTEP=10PS,1PS,100FS. At 10PS the error is unacceptable but at 1ps the result
is already practically identical with respect the result at 100FS. The error decreases with the square of time step while the
sim elapsed time grows linearly with 1/TSTEP (and also linearly with the number of elements of the circuit) .Few seconds
are required to run all sims. That's all, very essential indeed!

DETAIL_TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS (2).jpg
X
DETAIL_TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS.jpg
X
TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS.jpg
X
Piero Belforte
2015-09-24
Dealing with TLs and delayed elements, DWS offers 2 options about delay discretization: Interpolation or rounding. This
applies when the chosen TSTEP is NOT exactly an integer sub multiple of the MCD of all delays in the circuit under analysis
(if it is, no delay error affects the sim result).
Even in this case the overall effect on sim result can be displayed simply by changing TSTEP and see the change of result.
Usually the interpolation option gives the best results.
Piero Belforte
2015-09-24
Marcel,
I just created an interactive plot where you can see the differences at TSTEP=1PS,100FS,10FS of TL_C:OSCILLATOR_TEST5
you tried (see previous page 5) with ngspice at various options:
You can easily zoom in, pan and read the values to compare them with ngspice
.

The 10FS DWS waveform can be considered as the GOLDEN REFERENCE.
DETAIL_TL_C_OSC_TEST5_DWS_AT_VARIOUS_TSTEPS (2).jpg
X
Piero Belforte
2015-09-24
Here the plot of DWS integration error at TSTEP=100FS after 2us from the startup. The estimated error is less than
300uVpp. At the peak of V(1) it is very low. This integration error is due to capacitors only because the TL model has no
error (except numerical) because the tstep is an integer sub multiple of the TL delay (500ps). Actually the ideal TL
oscillators without reactive components added show an exact behavior except edge duration that depends only on tstep.
Obviously, as long as the number of reflections increases, this error increases as well. To keep this error low requires lower
tsteps (or TMAX for Spice) at increasing simulation windows.
As already experienced, Spice sim elapsed times can become soon prohibitively long.
Available here as interactive plot: https://plot.ly/~piero.belforte/5254.embed
TL_C_OSC_TEST5_DWS_ERROR.jpg
X
Piero Belforte
2015-09-24
From Marcel post about ngpsice:
"With METHOD=GEAR RELTOL=1e-4 I find 937.784mV. With RELTOL=1e-8, the minimum RELTOL for GEAR, it is
948.629mV.
RELTOL=1e-4, STEPMAX=1e-13 gives again 948.941mV, RELTOL=1e-8 STEPMAX=1e-13 give 948.776mV"
The reference 10FS DWS value is 948.58820mV.
Taking the latest value of 948.776mV, the ngpsice GEAR RELTOL=1e-8 100FS error at peak is about 188uV while DWS
100FS error is about 4uV. Sounds good.

DWS elapsed time at 100FS is 6 sec. At 10FS is 60sec. Ngspice should be about 100X these values I guess.
ERROR_AT_PEAK.jpg
X
Piero Belforte
2015-09-24
From Marcel post about ngpsice (page 5)
"With METHOD=TRAP RELTOL=1e-4 STEPMAX=1e-12 the amplitude of the v(1) waveform is 772.543mV at 1.99939us.
With RELTOL=1e-8 (the minimum possible before the timestep to guarantee it is less than 1e-16) that becomes
806.804mV at again 1.99939us."
This looks weird because DWS at 1PS shows a much lower error (less than 1mV see attached interactive plots). DWS uses
the TRAP method for capacitors (TLM open stub), so I don't understand why ngspice is so inaccurate (at least 142mV) at
1PS. May be a phase shift error due to TL?
Piero Belforte
2015-09-24
TEST CIRCUIT FOR LOSSY LINES (ngspice version)
This a ZYTL cell modeling a short segment of a coaxial cable. This simple test pinpoints problems at the rising edge of the
voltage waveform.
Here TMAX is the default 200ps/50=4ps. Tried on ngspice online with TMAX=1ps, but this issue is still there.
If I try with reltol=1e-9 ngspice crashes.
This example explain why I had to choose MC11 for DWS comparisons (paper just submitted at IEEE)
Here the comparison with DWS (sorry MC11 too)

TEST_ZYTL_FOP_SPICE_report.pdf
X
screenshot.25-09-2015 00.53.11.jpg
X
screenshot.25-09-2015 00.46.39.jpg
X
screenshot.25-09-2015 00.42.39.jpg
X
Piero Belforte
2015-09-25
Yes also these results confirm the issue at the start of the edge up to about 320 mV. This portion of the edge has a behavior
different with respect DWS and seems not influenced by the losses. As happens for the ideal TL this issue seems due to the
timesteps control algorithm the edge is rising.
Piero Belforte
2015-09-25
As a general consideration working at variable time step is in some way incompatible with the buffering of calculated
samples to implement the TL delay.

marcel hendrix
2015-09-25
Ok, thanks to some experiments with TEST_ZYTL_FOP_SPICE.cir my understanding of the problem is finally improving.
The attached output is based on repeated simulations of TEST_ZYTL_FOP_SPICE with different options.
The basic waveform, with STEPMAX=10fs, RELTOL=1e-8, and VNTOL=1e-8 is v(n_p1) of test_10fs.raw. This is a square wave
with rise and fall times of 10fs going into a 3cm coax cable.
Note the VNTOL is the absolute error of voltage nodes that gets added to RELTOL * max(vx(tn),vx(tn-1)) to form the
total against which a node is tested (ABSTOL test currents).
All other plots are the differences between the above v(n_p1) with STEPMAX=10fs and the same signal with STEPMAX
varied between 10fs and 100ps (green=100p, blue=10p, red=1p, magenta=100f). test_100ps_to_10fs_tolh_trf10p.raw:
shows what happens when RELTOL=1e-3, VNTOL=1e-6. In this case the rise and fall of the square wave are 10picoseconds,
not 10fs (I'll come back to this).
The result is clearly unacceptable for any STEPMAX. test_100ps_to_10fs.raw: shows what happens when RELTOL=1e-6,
VNTOL=2e-6, trise and tfall 10fs, method=GEAR. The result is acceptable for STEPMAX <= 1p. For all steps the error fully
goes to zero after about 60ps. test_100ps_to_10fs_trap.raw: shows what happens when RELTOL=1e-6, VNTOL=2e-6,
trise and tfall 10fs, method=TRAP. This is worse than GEAR, but for STEPMAX <= 1p it's ok.
test_100ps_to_10fs_tol.raw:
shows what happens when RELTOL=1e-8, VNTOL=1e-8, trise and tfall 10fs, method=GEAR. This is clearly very good, but still
has a spike that only starts to become smaller when STEPMAX is 100fs or smaller.
test_100ps_to_10fs_tol_trf1p.raw:
shows what happens when RELTOL=1e-8, VNTOL=1e-8, trise and tfall 1ps, method=GEAR. Limiting the rise and fall times of
the source has a large effect, the error is about 10 times smaller and the spike rapidly becomes smaller.
test_100ps_to_10fs_tol_trf10p.raw:
shows what happens when RELTOL=1e-8, VNTOL=1e-8,trise and tfall 10ps, method=GEAR. Limiting the rise and fall times of
the source to 10ps decimates the error, and even nicer, STEPMAX becomes almost unimportant for the error: we can use
STEPMAX=100p with only a very low-energy spike that lasts a mere 40ps.
Summarizing: For TL work RELTOL and VNTOL should be set really low: 1e-8 where 1e-3 is default. STEPMAX can be set at
100ps, a few times the rise time of the observed output signals (I think/hope).
The results for other circuits can be different, where especially circuits that generate arbitrarily steep steps will be
troublesome.
PS: In order to do these comparisons I use features of NGSPICE that lesser simulators will have trouble duplicating :-)
TEST_ZYTL_FOP_SPICE
* Desc: fop test of a single zytl cell (coax)
* IEEE paper for ngspice/dws comparison
* (c) Piero Belforte
V0 UN_2 0 dc=0 PULSE(0 2V 0ps 10fs) ; 10ps
R0 N_P1 0 50G
X0 N_P1 UN_4 rg58_3cm_spice
R1 UN_5 UN_2 0
V_P2 UN_4 UN_5 0
.subckt rg58_3cm_spice 300 400
* from SPA MOR
* IN=300 OUT=400
L1 5 6 5.4427e-012
L2 6 7 1.1855e-011
L3 7 8 2.9072e-011
L4 8 9 6.7779e-011
L5 9 10 1.4273e-010
L6 10 11 2.7533e-010
L7 11 12 4.6419e-010
L8 12 1 5.0842e-010
L17 14 0 -6.918333333333e-9
L18 15 0 -3.37e-7

L19 16 0 -3.777666666666667e-6
L20 17 0 -3.981333333333333e-5
L21 18 0 -5.240333333333334e-4
L22 19 0 -0.009776666666666666
L23 20 0 -0.3128733333333334
L24 21 0 -26.93266666666667
LOS 3 5 2.7741e-012
R0S 3 300 1.0559e-003
R1 6 5 2.5583e-001
R2 7 6 8.7308e-002
R3 8 7 3.5620e-002
R4 9 8 1.4208e-002
R5 10 9 5.6760e-003
R6 11 10 2.3904e-003
R7 12 11 1.0071e-003
R8 1 12 3.2710e-004
R19 13 0 1188.766666666667
R20 13 14 -1362.366666666667
R21 13 15 -13245.33333333333
R22 13 16 -45546.66666666667
R23 13 17 -141966.6666666667
R24 13 18 -485633.3333333334
R25 13 19 -1942633.333333334
R26 13 20 -9886000
R27 13 21 -75040000
R28 1 13 0
T1 1 0 400 0 Z0=50 TD=1.517608895659e-10
.ends rg58_3cm_spice
.temp 27
.options reltol=1e-8 vntol=2e-8 method=gear
*.options reltol=1e-3 vntol=1e-6 method=gear ; tolh
.control
listing e
TRAN 10fs 10e-9 9.8e-9 100ps ; 1-2
linearize v(n_p1)
TRAN 10fs 10e-9 9.8e-9 10ps ; 3-4
linearize v(n_p1)
TRAN 10fs 10e-9 9.8e-9 1ps ; 5-6
linearize v(n_p1)
TRAN 10fs 10e-9 9.8e-9 100fs ; 7-8
linearize v(n_p1)
TRAN 10fs 10e-9 9.8e-9 10fs ; 9-10
write test_10fs.raw v(n_p1)
linearize v(n_p1)
let difft1 = tran2.v(n_p1) - tran10.v(n_p1)
write test_100ps_to_10fs_tol_trf10p.raw difft1 difft2 difft3 difft4
quit
.endc
.end
Last edit: marcel hendrix 4 days ago

test_overview.png
Piero Belforte
2015-09-25
The input waveform is not a square wave but simply a fast step. The rest of the job is done by the full reflections at the
ports. It is obvious that increasing the step rise time makes the error less visible.
Marcel,
you probably mean STEPMAX 100 fs not 100ps.
Piero Belforte
2015-09-25
Sorry to mention MC11 again, but is you look at the interactive plot I posted yesterday, its error is below 1microvolt with
respect DWS working at FIXED STEP without the need of setting so low tolerances. I still feel that the cause of this kind
of issues is due to variable step.
Moreover, for previous lossless test circuits the major effect is due to TMAX and not to tolerances.
For this reason it becomes very difficult for the user to decide the options to set to get an accurate result.
Piero Belforte
2015-09-26
This looks fine so I suggest to go back to previous tests and verify if it applies also to them. I'm afraid that in case of higher
number of reflections these options cannot be enough to get a right result. If so, the optimal option setting gets practically
unmanageable.
Let's consider also that the tests carried out so far are very simple ones. Real applications often requires tens or hundreds
cells with thousands elements to model a single cable and also these situations must be checked.

marcel hendrix
2015-09-26
Hi Piero,
Progress. I have switched over to NGSPICE's TXL transmission line based on Lin and Ku's recursive convolution
method. This model can do both loss-less and lossy lines. See below for error performance and the spike-less
output wave forms (resampled for a fixed step of 5ps), when changing MAXSTEP between 200ps and
100fs, with GEAR and default RELTOL and VNTOL values.
This seems the way to go. The simulation time for the simulation when MAXSTEP=10ps is 200 msec. A problem is that
the TXL line does not accept IC. I tried with .IC, but I have not yet succeeded to get the same output as with the standard
TLs.
TL_TL_OSCILLATOR
.param z01=50 TD1=0.5n z02=100 TD2=0.5n
Y0 6 0 out2 0 piero1 IC=1,10m,1,-10m
Y1 out1 0 6 0 piero2
.model piero1 TXL r=0 g=0 l=td1*z01 c=td1/z01 length=1
.ic v(out1)=1 v(out2)=1
.model switch_nc SW(Ron=1u Roff=10G Vt=-0.5 Vh=0.1)
V0 7 0 dc=0 PULSE(-1 1 10ns 1fs 1fs 10ns 20ns)
.OPTIONS method=gear reltol=1e-4 vntol=1e-6
.TEMP 27
.END
.control
listing e
TRAN 5p 1u 980n 200ps uic ; 1-2
linearize v(out1)
TRAN 5p 1u 980n 100ps uic ; 3-4
linearize v(out1)
TRAN 5p 1u 980n 10ps uic ; 5-6
linearize v(out1)
TRAN 5p 1u 980n 1ps uic ; 7-8
linearize v(out1)
TRAN 5p 1u 980n 0.1ps uic ; 9-10
write tl_tl_100fs.raw v(out1) v(out2)
linearize v(out1)
let difft1 = tran2.v(out1) - tran10.v(out1)
let org1_100f = tran10.v(out1)
let org2_1p = tran8.v(out1)

write tl_tl_200ps_to_100fs.raw difft1 difft2 difft3 difft4 org1_100f org2_1p org3_10p org4_100p org5_200p
rusage
quit
.endc
.end
tl_tl_txl_output.png
tl_tl_txl_200p_100f.png
Piero Belforte
2015-09-27
Yes, this looks very interesting...It seems also very fast for spice with a DWS speedup of only 3X to be confirmed by other
tests. This should confirm that the default TL model has problems that could be corrected because I don't see the
theoretical advantage of this convolutional method in case of losses lines.
Piero Belforte
2015-09-26
Just tried with reltol and vntol to 1e8 TMAX default window 8NSto 10NS SpicySWAN crashes. I' m travelling so I cannot
perform accurate comparisons because I'm using an Ipad mini.
Robert Larice
2015-09-26
 > PS: There seems to be in a bug in NGSPICE-26 that prevents a TSTEP of
 > 10fs (a multiplication instead of a division resulting in an infinite
 > malloc).
 > Because of this discussion I found and fixed it. Thanks!

 >
 > -marcel

 marcel,
 obviously I'd be interested to see the "diff"

 Regards,
 Robert
Piero Belforte
2015-09-26
Tried on SpicySWAN replacing the step generator with a 10Ghz square wave 10FS EDGES, seems to crash even with default
settings. please try.
Here the SWAN
version https://www.ischematics.com/webspicy/report.py?RCODE=14274611860415351824as#.VgaYiRgqGX9.mailto
Piero Belforte
2015-09-27
I cannot due to crash. Please write the simple netlist (100Ghz square wave generator) manually
Here the report for a limited 0-2ns window:
TEST_ZY_TL_SPICE3_report.pdf
X
marcel hendrix
2015-09-27
Be patient, the wrap-up is near.
I redid the tl_tl_oscillator with skewing, a circuit (previously shown here) that takes 3325.485 seconds to run with the
standard NGSPICE transmission-line model.
With the TXL model the run-time reduces to about 16 seconds. Moreover, the output shows that a STEPMAX of 1ps might
be acceptable too (run-time only 1.7s). I hope this can be compared to Piero's DWS results (which take 8 seconds
to generate on his system). I linearized the output with steps of 0.1ps to make comparison with DWS easier. In NGSPICE
one can look at the original steps for increased
precision. Note that the output could be wrong as I can't set the initial conditions of the TXL model.

TL_TL_OSCILLATOR_SKEWED
.param z01=50 TD1=0.503n z02=100 TD2=0.501n
Y0 6 0 out2 0 piero1 IC=1,10m,1,-10m
Y1 out1 0 6 0 piero2
.ic v(out1)=1 v(out2)=1
.OPTIONS method=gear
.TEMP 27
.control
listing e
TRAN 0.1ps 1u 980n 1ps uic
rusage
linearize v(out1) v(out2)
TRAN 0.1ps 1u 980n 0.1ps uic
linearize v(out1) v(out2)
let org1 = tran2.v(out1)
let diff31 = org3-org1
let diff42 = org4-org2
write tl_tl_oscillator_skewed_diff.raw org1 org2 org3 org4 diff31 diff42
rusage
quit
.endc
* Total elapsed time: 3325.485 seconds. with default T-line model, STEPMAX 100fs
* Total elapsed time: 17.534 seconds with TXL, STEPMAX 100fs
* Piero Belforte: DWS (tstep=100fs) elapsed time: 8sec (Intel Quad-Core i7-2630QM 2.00GHz CPU)
.end
tl_tl_txl_skewed.png

tl_tl_txl_skewed_zoom.png
Piero Belforte
2015-09-27
That is very cool. IT WOULD BE THE FIRST TIME I SEE SPICE SO FAST WITH TLs. The testing has to be continued with other
test circuits like the coaxial cell.
marcel hendrix
2015-09-27
Let's see how far we are...
My goal for the current discussion thread is to find out:
Are NGSPICE's transmission line models (not only the basic loss-less T-line but also LTRA and the KSPICE ones)
correct down to a femtosecond real-world time scale?
There is still no 'golden circuit' to test this. Meanwhile, I found that for the standard Txx transmission line,
simulation with 100fs steps is only possible when the compiler options for NGSPICE are set to /fp:precise. If not, I see the
solution for TL_C_oscillator explode to infinity (probably because of excessive round-off errors).
The TXL model has even worse numerical performance, and I cannot use it for STEPMAX <= 1ps and low (i.e. non-default)
values of RELTOL and VNTOL. However, the outcome even above 1ps is much better than for the Txx line. Still, TXL needs
more care than other models.
Are NGSPICE's TL models implemented correctly? For this we need a circuit model with a closed solution to compare to.
I was too strict, we don't need a golden model, it is sufficient to test against other simulators. I think NGSPICE's Txx and
Oyy models are implemented correctly (I compared them to LTspice).
The TXL model is not available in LTspice and MC11, so it is still an open question. Because of its superior speed it's the only
one I will use.
Is it possible to find out how to set STEPMAX and RELTOL so that understandable and predictable time- and
frequency-domain errors result? My first experiment with the T-L say this NOT the case (the error goes down, but not in
an expected manner).
When decreasing RELTOL to below 1e-5, VNTOL should be decreased also (by default it is 1uV). I didn't do this at first and
it caused confusion. Experiments show that RELTOL and VNTOL do push the error down, but if the signals are faster than
1/STEPMAX it takes many steps to do so for the Txx model (I saw 40ps in experiments).
Limiting the dV/dT of all circuit sources gave nice results for Txx. The TXL errors converge MUCH faster and don't need
dV/dt limiting. In general a small RELTOL and VNTOL should be used instead of a small STEPMAX -- the results are the
same, but the simulation runs much faster when transients are infrequent. However, for transmission lines this rule
seems not to be really true, and STEPMAX must be chosen with care.
Is it possible to substantially increase simulation speed of digital and analog electronic circuits that contain transmission
lines, while still knowing what the time-domain and frequency-domain errors are, preferably without having to do a
simulation multiple times.
Apparently, by using TXL models several orders of magnitude higher speed are possible without giving up any of the SPICE
features. For the time being, take heed of 1) though. The TXL model is not very stable numerically and the timestep
must be chosen carefully.
Last edit: marcel hendrix 4 days ago

Piero Belforte
2015-09-27
Marcel,
your analysis is very important, it's the first time I see something similar. Several points have been clarified from the
beginning of this discussion and our understanding of the issues is far better. Anyway it seems to me that a definitive
solution for the TL model in ngspice is not yet found. Moreover our tests are limited to very simple circuits with one or
two TLs and so it is necessary to see what happens for circuit with hundreds or thousands TLs as those required for
modeling interconnects or pcb planes.
Piero Belforte
2015-09-28
Your netlist is ok.
Retried with SpicySWAN in Spice mode 9.5-10ns default options including TMAX: it crashes.
Here the reference result (DWS tstep 1fs) checked against 10fs result is practically the same.
At tstep=100fs the behavior changes but this can be due to the slowdown of input edges (10ps rise time). Anyway even at
100ps the result is different.
The behavior is TOTALLY DIFFERENT WITH RESPECT PREVIOUS NGSPICE RESULT.
TEST_ZY_TL_FOP_DWS3_report.pdf
X
Piero Belforte
2015-09-28
Yes, I have, as SpicySWAN (DWS) circuits. I have to check them in order to be run both in Spice and SWAN mode.
The best for sharing is to share the SpicySWAN schematic so you could run it directly on SpicySWAN and even on your local
ngspice copying the netlist.

Piero Belforte
2015-09-27
About the golden reference , I think that DWS with the error vs. tstep check can be assumed as reference,
marcel hendrix
2015-09-27
A closed solution from a text book or paper would be much more convincing for users that know neither DWS nor
NGSPICE.
Piero Belforte
2015-09-28
For simple circuits it is easy to find situations where the theoretical result is known and can be used as golden reference.
This is the case for example of a lossless LC oscillator that I already compared to both ngspice and dws with interesting
results.
Another way is to create SELFTEST circuits where the theoretical result of two equivalent configurations MUST BE the
same, otherwise it points out accuracy problems. In the case of TL for example a single TL should have the same response
of a cascade of several TLs with the same Zo and the same overall delay.
When the situation is more complex and no analytical solution can be easily found, the method based on tstep reduction
and result comparison can be applied if applicable. In the case of DWS it is applicable. In the case of Spice this is not
always possible for the issues pointed out by this discussion. It is clear that the rules applicable to Spice for achieving
better accuracy without incurring in numerical or convergence problems can be only EMPIRICAL
https://www.researchgate.net/publication/272790267_DWS_VS_NGSPICE_SIMULATION_ERROR_COMPARISON_50Mhz_
LC_OSCILLATOR?ev=prf_pub
CELL_LC_CIRCUIT_STEP_RESPONSE_AFTER_1MICROSECOND_%28COMPARISON_TO_EXACT_DWS_SIMULATION%29
marcel hendrix
2015-09-28
I found this. Lots of useful plots from HSPICE, plus a closed solution (but approximated)
-marcel
closedformpade.pdf

Piero Belforte
2015-09-28
Yes, this can be also a good way to evaluate errors, but in this case the effect of cell discretization can be much more
significant than simulator error.
Piero Belforte
2015-09-27
.... and why not to write together a technical note/paper on this topic?
marcel hendrix
2015-09-27
Not a paper, surely. What would be the purpose of a TN?
Piero Belforte
2015-09-28
The same of our current discussion: to assess and clarify the accuracy/speed issues using ngspice and dws by means of
selected benchmark circuits The user of the tools should learn how utilize sim options to get an accurate results possibly
in short sim times.
Piero Belforte
2015-09-28
Just to give an idea of ngpice and dws users on the Ipad SpicySWAN free app they are about 20K in the latest 2 years.
They are distributed worldwide. The countries with higher installed and updated apps are US,UK, Italy, Germany,
Australia, and Mexico. Fast growing is China.
This number doesn't include the users of the web app for pcs macs etc.

marcel hendrix
2015-09-28
Retried with SpicySWAN in Spice mode 9.5-10ns default options including TMAX: it crashes.
IIRC, SpicySWAN uses NGSPICE-24. That could be way too old, considering what has been fixed in NGSPICE-26 and the Git
developer version.
The behavior is TOTALLY DIFFERENT WITH RESPECT PREVIOUS NGSPICE RESULT.
I remember seeing something like your plot, I think it was with the standard TL instead of TXL. The TXL did not change
when I went from 100fs to 10fs steps. I guess I'll have to go all the checks again :-)
Piero Belforte
2015-09-28
Tried your netlist on ngspice online with TMAX=100fs and 10fs with no apparent change of result.
The small steps with 1ps width on the waveform looks strange.
Retried with standard TL model on ngspice between 1.95-1.96ns, it runs and looks like DWS. This means that the Y model
gives WRONG results.
Piero Belforte
2015-09-28
Confirmed simulating on ngspice between 4.8ns and 5ns (max allowable window before timeout)TMAX =10fs Result
similar to DWS even if affected by the well known spurious spikes.
This means that the Y model is UNRELIABLE.
SpicySWAN utilizes NGSPICE-25.
May be it's better to wait for an improved TL model in ngspice :).
Piero Belforte
2015-09-28
Tried on ngspice online with TMAX=10fs and 100fs with practically the same result of your sim. It's strange not the see the
effect of losses on the small steps.

Piero Belforte
2015-09-28
Tried your netlist on ngspice online with TMAX=100fs and 10fs with no apparent change of result.
The small steps with 1ps width on the waveform looks strange.
Retried with standard TL model on ngspice between 1.95-1.96ns, it runs and looks like DWS. This means that the Y model
gives WRONG results.
marcel hendrix
2015-09-28
Hi Piero,
Try this with the 3cm coax:
.TRAN 10fs 9.65n 0 100fs; 9.5n 100fs
... i.e. plot the whole sequence instead of a tiny sliver.
There is some logic in the decay.
Try it for both T1 and Y1 and you'll note they start out the same way.
The final result of the T model could be the result of the spurious
spikes it has at the beginning?
-marcel
Piero Belforte
2015-09-29
Compared DWS at 100fs with Y model ngspice, the overall behavior looks similar, but if you resimulate in the window 9.5-
10ns the Y model shows an UNACCEPTABLE waveform smoothing. (see attachments). May be the authors introduced a
smoothing to avoid numerical instability. As you too pointed out, TMAX seems not to have any visible effect on waveform
behavior (tried down to 5ps, the minimum TMAX allowed by timeout of ngspice online ).
Anyway I suggest NOT TO CONTINUE with Y MODEL TRIALS despite its speed because of the issues discovered so far.
Ngspice online is not able to give the result at 100fs.
About the effect of spurious spikes of T model I don't know if they accumulate the effects with reflections.
100FS_DWS.jpg
X

100FS_NGS_YMODEL.jpg
X
Piero Belforte
2015-09-29
Here the comparison of ngspice (T model) at 10fs vs. DWS at 2fs . The yellow area highlights ngspice error (usual edge
aberrations). Horizontal Scale 50fs/div.
TEST_ZY_TL_FOP_DWS3_DWS_2FS_VS_NGS_10FS.jpg
X
Piero Belforte
2015-09-29
The story continues... Here DWS is run at 100 ATTOSECONDS. Attached the comparison, same scales.
TEST_ZY_TL_FOP_DWS3_DWS_.1FS_VS_NGS_10FS.jpg
X

Piero Belforte
2015-09-29
Tried DWS at 50 ATTOSECONDS (50e-18) , no more visible changes. THIS could be THE "EXACT" REFERENCE. 5e-9/50e-18=
1e8 calculated samples (100MEGA).
Piero Belforte
2015-09-29
Decreased ngspice plot step to 1fs to increase resolution, here the FINAL COMPARISON.
TEST_ZY_TL_FOP_DWS3_DWS_50AS_VS_NGS_10FS.jpg
X
marcel hendrix
2015-09-29
You forgot to add a screenshot, but I can imagine what it looks like :-)
For complete ease-of-mind, with this enormous of amount of samples a synthetic benchmark will be needed to find out
how DWS behaves with respect to accumulated round-off errors.
Piero Belforte
2015-09-29
Yes I can plot DWS result superimposed down to 10 ATTOSECOND tstep (or lower). I don't think round off error is so
relevant even at these so low steps...anyway I'll try...running the sim at 10ATTO.
BTW at 5fs TMAX ngpice on line goes to time out.
Launched 100ATTO in parallel, finished in 59sec. 10ATTO will require about 10min. In this case 2CPU are involved in
parallel. The pc fan increases the speed for 1 minute (the time required by 100ATTO) ...When I run CST my pc seems a jet
plane at take off during the whole simulation lasting may be 1hour with 4CPU working simultaneously...

Piero Belforte
2015-09-29
10ATTO finished in 1032 sec (more than expected) .5GIGASAMPLES CALCULATED, 5K PLOTTED,
Here the DWS sim control statements:
.OPTIONS DELAYMETH=INTERPOLATION
.TEMP 27
.TRAN TSTEP=.01FS TSTOP=4.9547NS TSTART=4.9545NS LIMPTS=5000 V(3000001)
Here the interactive plot with the error:
Attached 2 screenshots (one is a zoomed view you can see on the interactive plot). As expected the round off error is not
visible, but the integration error is visible and is about 2mv at the rising edge with peaks at the edge start and stop times.
In the rest is about 3uV.
screenshot.29-09-2015 08.24.18.jpg
X
screenshot.29-09-2015 08.16.08.jpg
X
Piero Belforte
2015-09-29
Why this behavior of sim error?
It is mainly due to TD dicretization error, because at these time steps the lumped ZY cell doesn't contribute anymore to
integration error (DWS utilizes here the trapezoidal rule because the two-port INDUCTORS are modeled with the STUB
model by means of series adaptors connected to a grounded inductor that acts like a shorted stub, the dual of capacitor.
The DWS default model for 2-port inductances is the two-port LINK MODEL equivalent to a TD=T , Z0=L/T TL that is
computationally faster but determines a one tstep delay error that is not convenient in case of several cells connected in
cascade).
This is the statement related to the cell TL as calculated by Spartaco Caniggia:
T1 1 0 400 0 Z0=50 TD=1.517608895659e-10
The theoretical propagation velocity of 3cm of cable is obtained as c/sqrt(epsr) where c is the speed of light in the vacuum
and epsr the relative permittivity of polyethylene (PE).
The theoretical result is TD=151.7608895659 ps = 151760889.5659 attoseconds . When you simulate, TD will be
discretized with the chosen tstep. Even working at 10 attosecond a discretization error will arise. This cell delay error is
minimized by the delay INTERPOLATION option but is not zero. The flat portion of error corresponding to rising edge is

due to this DELAY ERROR difference between tstep= 100 as and 10 as. This error will grow linearly with the number of
back and forth cell reflections (or on the number of cascaded cells in case of cable with lengths in the range of meters).
This delay error will cause a (small) time shift of the simulated 10ps edge that causes the -2.17 mV amplitude error (see
attached plots and interactive plot).
100AS_VS_10AS_ERROR_DETAIL3.jpg
X
100AS_VS_10AS_ERROR_DETAIL2.jpg
X
100AS_VS_10AS_ERROR_DETAIL.jpg
X
Piero Belforte
2015-09-29
Tried DWS with tstep= 5Attosecond. This is the lower limit of tstep I can choose with this TSTOP otherwise I get the
TSTOP/TSTEP TOO LARGE DWS warning. This is not a theoretical limit, it is only due to the maxinteger limitation of this
ratio. It is possible to overcome this limitation including special math routines but it has not done.
Attached here the DWS netlist and related sim report of this test circuit.
5AS_TEST_ZY_TL_FOP_DWS3.txt
X
5AS_TEST_ZY_TL_FOP_DWS3.r
X

marcel hendrix
2015-09-29
As expected the round off error is not visible,
The numeric round-off error is normally not apparent. One way to see round-off error is to make a logarithmic plot of the
error (1) at some strategic time-points vs. the fixed time step. Ideally this will be a straight line (its derivative depends on
the order of the integration routine and should be at least -1 on a log-log scale). At small steps you may see that the
steepness of the line becomes less or even flattens. Actually, this is normal numeric behavior unless you use an arbitrary
precision FP package.
-marcel
(1) For the error, you could normalize the outcomes vs. the outcome at the largest step you think is reasonable (assuming
you don't know the result exactly).
Piero Belforte
2015-09-29
Yes, I agree. I could try using 100, 10, 5 attoseconds results even if, as I wrote previously, this is NOT strictly an integration
error but its DOMINANT portion is the DELAY DISCRETIZATION ERROR that causes a progressive shift of the result and
grows linearly vs. time step and time.
To see the integration error contribution the cell should be modified in order to eliminate the TD error choosing a TD
integer multiple of tstep.
marcel hendrix
2015-09-29
I could try using 100, 10, 5 attoseconds results. A second possibility is to use a lossless unterminated line with initial
conditions and check how many reflections back-and-forth are possible before you see a noticeable increase / decrease in
amplitude or wave shape. This gives a figure-of-merit that is useful for comparison but otherwise is less informative.
Piero Belforte
2015-09-29
Yes I agree, but in this case the amplitude attenuation will be mainly due to GMIN and GMAX settings. The
terminations are not ideal short and open circuits and so at each reflection you lose energy and this should be the
dominant part of visible attenuation.

Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison

Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison

Recommended

Recommended

More Related Content

Similar to Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison

Similar to Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison (20)

More from Piero Belforte

More from Piero Belforte (20)

Recently uploaded

Recently uploaded (20)

Digital Wave vs. Nodal Analysis for Circuit Simulation: an experimental comparison