The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
May 3rd, 2024, 6:11pm
Pages: 1
Send Topic Print
Gmin settings in transient simulation (Read 110 times)
petitidiot
New Member
*
Offline



Posts: 8

Gmin settings in transient simulation
Oct 10th, 2014, 1:25am
 
I have run a transient simulation on a chopping instrumentation amplifier. With the default settings, and accuracy defaults set as conservative, everything is ok: input is a sine wave and output is an amplified sine wave.
However, when I tuned gmin from 1e-12 to 1e-24, the transient output showed oscillation with the chopping frequency. The output.log said it tried "homotopu = gmin" "homotopy = source" "homptopy = dptran" to get the initial conditions. Then which settings I should trust? A smaller gmin is always more accurate and reflects the real situation?
Attached is part of the output.log file. Please help!Thanks!

Circuit inventory:
             nodes 146
           bsim3v3 217  
         bsource_1 14    
         capacitor 16    
           isource 3    
           vsource 30    


Notice from spectre.
   77 warnings suppressed.


Time for parsing: CPU = 6.999 ms, elapsed = 9.06682 ms.
Time accumulated: CPU = 313.952 ms, elapsed = 308.797 ms.
Peak resident memory used = 32.3 Mbytes.

Entering remote command mode using MPSC service (spectre, ipi, v0.0, spectre32_8384_94, ).

Warning from spectre.
   WARNING (SPECTRE-16707): Only tran supports psfxl format, result of other analyses will be in psfbin format.


************************************************
Transient Analysis `tran': time = (0 s -> 20 ms)
************************************************
Trying `homotopy = gmin' for initial conditions.
Trying `homotopy = source' for initial conditions.
Trying `homotopy = dptran' for initial conditions..
Important parameter values:
   start = 0 s
   outputstart = 0 s
   stop = 20 ms
   step = 20 us
   maxstep = 200 us
   ic = all
   useprevic = no
   skipdc = no
   reltol = 100e-06
   abstol(V) = 1 uV
   abstol(I) = 1 pA
   temp = 27 C
   tnom = 27 C
   tempeffects = all
   errpreset = conservative
   method = gear2only
   lteratio = 10
   relref = alllocal
   cmin = 0 F
   gmin = 1e-24 S

   tran: time = 500 us       (2.5 %), step = 130.6 ns     (653 u%)
   tran: time = 1.5 ms       (7.5 %), step = 91.65 ns     (458 u%)
   tran: time = 2.5 ms      (12.5 %), step = 99.63 ns     (498 u%)
   tran: time = 3.5 ms      (17.5 %), step = 166.7 ns     (833 u%)
   tran: time = 4.5 ms      (22.5 %), step = 115.6 ns     (578 u%)
   tran: time = 5.5 ms      (27.5 %), step = 85.65 ns     (428 u%)
   tran: time = 6.5 ms      (32.5 %), step = 948.9 ps    (4.74 u%)
   tran: time = 7.5 ms      (37.5 %), step = 66.76 ns     (334 u%)
   tran: time = 8.5 ms      (42.5 %), step = 103.9 ns     (519 u%)
   tran: time = 9.5 ms      (47.5 %), step = 133.4 ns     (667 u%)
   tran: time = 10.5 ms     (52.5 %), step = 106.5 ns     (533 u%)
   tran: time = 11.5 ms     (57.5 %), step = 66.69 ns     (333 u%)
   tran: time = 12.5 ms     (62.5 %), step = 111 ns       (555 u%)
   tran: time = 13.5 ms     (67.5 %), step = 1.243 ns    (6.21 u%)
   tran: time = 14.5 ms     (72.5 %), step = 172.4 ns     (862 u%)
   tran: time = 15.5 ms     (77.5 %), step = 120.3 ns     (602 u%)
   tran: time = 16.5 ms     (82.5 %), step = 1.017 ns    (5.08 u%)
   tran: time = 17.5 ms     (87.5 %), step = 1.124 ns    (5.62 u%)
   tran: time = 18.5 ms     (92.5 %), step = 139.2 ns     (696 u%)
   tran: time = 19.5 ms     (97.5 %), step = 132.1 ns     (660 u%)
Number of accepted tran steps =             72140
Initial condition solution time: CPU = 1.36779 s, elapsed = 1.36807 s.
Intrinsic tran analysis time:    CPU = 112.155 s, elapsed = 112.182 s.
Total time required for tran analysis `tran': CPU = 113.529 s (1m  53.5s), elapsed = 113.561 s (1m  53.6s).
Time accumulated: CPU = 115.155 s (1m  55.2s), elapsed = 117.525 s (1m  57.5s).
Peak resident memory used = 249 Mbytes.

finalTimeOP: writing operating point information to rawfile.

******************
DC Analysis `dcOp'
******************
Important parameter values:
   reltol = 1e-03
   abstol(V) = 1 uV
   abstol(I) = 1 pA
   temp = 27 C
   tnom = 27 C
   tempeffects = all
   gmindc = 1e-24 S
Trying `homotopy = gmin'.
Convergence achieved in 65 iterations.
Total time required for dc analysis `dcOp': CPU = 73.989 ms, elapsed = 78.5849 ms.
Time accumulated: CPU = 115.254 s (1m  55.3s), elapsed = 117.635 s (1m  57.6s).
Peak resident memory used = 249 Mbytes.

dcOpInfo: writing operating point information to rawfile.
modelParameter: writing model parameter values to rawfile.
element: writing instance parameter values to rawfile.
outputParameter: writing output parameter values to rawfile.
designParamVals: writing netlist parameters to rawfile.
primitives: writing primitives to rawfile.
subckts: writing subcircuits to rawfile.
Back to top
 
 
View Profile   IP Logged
boe
Community Fellow
*****
Offline



Posts: 615

Re: Gmin settings in transient simulation
Reply #1 - Oct 13th, 2014, 3:25am
 
petitidiot wrote on Oct 10th, 2014, 1:25am:
I have run a transient simulation on a chopping instrumentation amplifier. With the default settings, and accuracy defaults set as conservative, everything is ok: input is a sine wave and output is an amplified sine wave.
However, when I tuned gmin from 1e-12 to 1e-24, the transient output showed oscillation with the chopping frequency. The output.log said it tried "homotopu = gmin" "homotopy = source" "homptopy = dptran" to get the initial conditions. Then which settings I should trust? A smaller gmin is always more accurate and reflects the real situation?
Attached is part of the output.log file. Please help!Thanks!
A gmin of 1e-24 is equivalent to 1 electron per day at 2 Volts. So good an insulation is very hard to achieve... And so small a gmin is bad for convergence.
If gmin=1e-12 and gmin=1e-13 give similar results, gmin=1e-12 is most likely to be enough.
- B O E
Back to top
 
 
View Profile   IP Logged
petitidiot
New Member
*
Offline



Posts: 8

Re: Gmin settings in transient simulation
Reply #2 - Oct 16th, 2014, 7:26am
 
BOE,
Thanks for the reply. I wonder if it is difficult for the simulator to converge, is it possible that the simulation completes but the result is not trustworthy?
Back to top
 
 
View Profile   IP Logged
boe
Community Fellow
*****
Offline



Posts: 615

Re: Gmin settings in transient simulation
Reply #3 - Oct 17th, 2014, 3:44am
 
petitidiot wrote on Oct 16th, 2014, 7:26am:
BOE,
Thanks for the reply. I wonder if it is difficult for the simulator to converge, is it possible that the simulation completes but the result is not trustworthy?
Yes, that is possible, the result can e.g. be dominated by numerical errors.
- B O E
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: Gmin settings in transient simulation
Reply #4 - Oct 19th, 2014, 12:12am
 
Designer's are crazy.

I am convinced that a large fraction of the trouble designers have with simulators are self inflicted. They often run with absurdly tight settings and suffer through needlessly slow simulations and wonder why simulators are not robust. Oddly, they often don't even try default tolerances. They just assume the worst and crank down the tolerances.

You are already running with conservative settings. And gmin by default is already 1TΩ. What on earth made you think that it needed to be 1012 times tighter? And if you were going to tighten it that much, why didn't you just make it zero? And why, when you got wacky results did you not think, well when you do something crazy you have to expect crazy results?

Having said that, it does not seem like making gmin that small should cause the problem you are seeing. But it is hard to know because you have given very little useful information. It would have been better if you actually showed us the oscillation. That certainly would have been more useful than a seemingly normal output summary.

My recommendation is for you to relax. Accept a good result when you get it and stop looking for trouble.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.