Step size reached minimum step size bound

[Sai Charan]

When I run the simulation, I don't get any parsing errors ( but a bunch of BSIM warnings ) however the simulation ends with this message `Step size reached minimum step size bound`. Can you help with the understanding of this error please?

My spice file has a tran simulations with .meas with trig and targ. 

Regards

Sai

[xyce-users]

When you get this sort of error it means that Xyce has had convergence problems. 

Like most circuit simulators, Xyce uses a variable-order, variable stepsize time integration method.  Both are adjusted throughout the simulation.  If the nonlinear solver fails, then the stepsize is cut and the step is re-attempted with the smaller time step.   Xyce also performs local truncation error (LTE) analysis, and based on this may do the same thing.

If a time step is rejected over and over again, eventually the stepsize will shrink so much that it approaches machine precision.  If this happens, Xyce can no longer resolve the time, and it will quit the simulation.

So, this is generally what is happening with your simulation.   You are getting enough time step failures that Xyce cannot proceed.

How, exactly to fix it is problem-dependent.  Sometimes this problem goes away if you make the rise/fall times less abrupt.  It can also go away if you add a little more capacitance to the circuit.

thanks,
Eric

[xyce-users]

In addition to the time stepping issue Eric refers to, Xyce also performs a nonlinear solve at the DC operating point using Newton's method.  If that simple Newton's method solve fails, it attempts "GMIN stepping" using a continuation method that ties every node in the circuit to ground using an enormous conductance (which makes the problem much easier) and performs Newton's method on that, then step by step reduces those conductances to zero, repeatedly trying to solve the resulting system with Newton's method using the previous step's solution as a guess.  At the end of this process, it should be solving the original problem you wanted it to solve.  *That* process also uses a variable step size for how much it changes the conductances each time.  And if it gets to the point where it has reduced its gmin step size too small, it gives up.

The specific error you're reporting ("Step size reached minimum step size bound") is in fact very specific to that continuation method , meaning that Xyce could not even solve the DC operating point using this GMIN stepping technique.  GMIN stepping is only performed for the DC operating point nonlinear solves, not in transient.  So your circuit isn't even getting to the point where Xyce can simulate the transient --- it's failing to get an operating point.

So what Eric suggests (e.g. changing rise and fall times in transient) won't help there.  Neither will adding capacitance, since capacitors are open circuits in DC anyway.  You'll need to work out why your circuit can't even find an operating point.

[Sai Charan]

Thanks for the explanation, I confirm the same "gmin stepping" error with ngspice from the simulations I just ran. I think we might have a clue behind why the simulation is failing.

An observation from one of the simulations might be interesting for your group I guess... Ngspice actually says that it completed the transient op (not sure how it is related) and stays in the "run" for a long time. The highest amount of time before I gave up is around 6 hours. However xyce doesn't do any such thing and just quits the simulation.Below is the log file for that particular run. Not sure if you can help in understanding what it is actually trying to do and what xyce gave up doing... is this a feature in ngspice that is not present in xyce or is this a bug in ngspice which was caught by xyce by not staying in infinite loop mode like ngspice?

-------------------------------------------------------------------------------------

Note: No compatibility mode selected!


Circuit:

Warning: option lvltim is currently unsupported.
Doing analysis at TEMP = -20.000000 and TNOM = 27.000000

Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_37/a and xi1.sky130_fd_sc_hd__inv_1_37/a

Note: Starting dynamic gmin stepping
Trying gmin =   1.0000E-03 Note: One successful gmin step
Trying gmin =   1.0000E-04 Note: One successful gmin step
Trying gmin =   1.0000E-05 Note: One successful gmin step
Trying gmin =   1.0000E-06 Note: One successful gmin step
Trying gmin =   1.0000E-07 Note: One successful gmin step
Trying gmin =   1.0000E-08 Note: One successful gmin step
Trying gmin =   1.0000E-09 Note: One successful gmin step
Trying gmin =   1.0000E-10 Note: One successful gmin step
Trying gmin =   1.0000E-11 Note: One successful gmin step
Trying gmin =   1.0000E-12 Note: One successful gmin step
Trying gmin =   1.0000E-13 Note: One successful gmin step
Trying gmin =   1.0000E-14 Note: One successful gmin step
Trying gmin =   1.0000E-15 Note: One successful gmin step
Trying gmin =   1.0000E-16 Note: One successful gmin step
Trying gmin =   1.0000E-17 Note: One successful gmin step
Trying gmin =   1.0000E-18 Note: One successful gmin step
Trying gmin =   1.0000E-19 Note: One successful gmin step
Trying gmin =   1.0000E-20 Note: One successful gmin step
Trying gmin =   1.0000E-21 Note: One successful gmin step
Trying gmin =   1.0000E-22 Note: One successful gmin step
Trying gmin =   1.0000E-23 Note: One successful gmin step
Trying gmin =   1.0000E-24 Note: One successful gmin step
Trying gmin =   1.0000E-25 Note: One successful gmin step
Trying gmin =   1.0000E-25 Note: One successful gmin step
Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a

Warning: Dynamic gmin stepping failed
Note: Starting true gmin stepping
Trying gmin =   1.0000E-03 Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a

Warning: Further gmin increment
Trying gmin =   5.6234E-03 Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a

Warning: Further gmin increment
Trying gmin =   8.6596E-03 Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a

Warning: Further gmin increment
Trying gmin =   9.6466E-03 Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a

Warning: Further gmin increment
Trying gmin =   9.9105E-03 Warning: Further gmin increment
Trying gmin =   9.9775E-03 Warning: Further gmin increment
Trying gmin =   9.9944E-03 Warning: Further gmin increment
Trying gmin =   9.9986E-03 Warning: Further gmin increment
Trying gmin =   9.9996E-03 Warning: Last gmin step failed
Warning: True gmin stepping failed
Note: Starting source stepping
Supplies reduced to   0.0000%
Trying gmin =   1.0000E-15 Note: One successful gmin step
Trying gmin =   1.0000E-16 Note: One successful gmin step
Trying gmin =   1.0000E-17 Note: One successful gmin step
Trying gmin =   1.0000E-18 Note: One successful gmin step
Trying gmin =   1.0000E-19 Note: One successful gmin step
Trying gmin =   1.0000E-20 Note: One successful gmin step
Trying gmin =   1.0000E-21 Note: One successful gmin step
Trying gmin =   1.0000E-22 Note: One successful gmin step
Trying gmin =   1.0000E-23 Note: One successful gmin step
Trying gmin =   1.0000E-24 Note: One successful gmin step
Trying gmin =   1.0000E-25 Note: One successful gmin step
Note: One successful source step
Supplies reduced to   0.1000% Supplies reduced to   0.0000% Warning: source stepping failed
Note: Transient op started
Note: Transient op finished successfully

Initial Transient Solution
..........

.......

....

-------------------------------------------------------------------------------------

-Sai

[xyce-users]

I stand corrected.  Yes, that Xyce error message is coming from the DCOP solve.

I haven't checked to verify this, but my guess is that ngspice's "transient op" is probably a pseudo-transient algorithm, which it (apparently) attempts after straight Newton, gmin stepping and source stepping have all failed.

Eric

[Sai Charan]

Interesting. 

[xyce-users]

It is not likely that ngspice is in an infinite loop, but rather is taking extraordinarily small time steps, probably for the same reason that the DC op failed most of the normal techniques --- your circuit clearly has some issues that are leading to singular matrices, and even when it's gone through great effort to come up with a starting point for transient using what it calls "transient op", it's probably not a very good one.  I'd go out on a limb and say that it's probable that the nonlinear solver failures are continuing into transient and causing really poor timestepping behavior.

ngspice is warning you about the problem in your circuit's nonlinear system and giving you a hint about where it might be found:  "Warning: singular matrix:  check nodes xi1.sky130_fd_sc_hd__inv_1_36/a and xi1.sky130_fd_sc_hd__inv_1_36/a"

That doesn't make a whole lot of sense in isolation given that both of the nodes it names have the same name, but there it is.  Perhaps something in your circuit's connectivity is problematic somewhere near that node.

[Marcel Hendrix]

There are circuits where NGSPICE can't find the DC OP, but a .TRAN starts up fine with the UIC option and all IC=.. statements 

kept at 0 or at their intended values.

[Sai Charan]

An update on this - ngspice is able to run the simulations where Xyce is giving up with the "Step size reached minimum step size bound" message. For a set of netlists where ngspice is taking a good amount of time to give the result, Xyce is failing to find it. So, probably faulty netlist might not be the reason behind the failure of simulations? Can anyone help me understand the mismatch here please? I can share the netlists and the log files of Xyce and Ngspice if needed. 

-Sai

[xyce-users]

If you are willing to share the netlist(s), that would make it a lot easier for us to diagnose the issue.

BTW, the UIC option mentioned above also works in Xyce.  If you use UIC, Xyce will just skip the DCOP calculation.  (this feature is common to most circuit simulators).  Sometimes that is all you need to do.

thanks!

Eric

[Sai Charan]

Hi Eric,

Sorry for the delay in response, I am sharing the following information with you - 

1. netlists from Xyce (I tried to use the noop for trans because someone recommended me but it just crashes) and Ngspice

2. log files from both the simulators (xyce gave up and ngspice took about 30 mins to give the result)

3. sky130a.lib.spice

4. version info for xyce (serial) and ngspice 

Below is the organization inside the tar file

.
├── ngspice
│   ├── sky130.lib.spice
│   ├── tempsenseInst_error_sim_0.log
│   ├── tempsenseInst_error_sim_0.sp
│   └── tempsenseInst_error.spice
├── versions.txt
└── xyce
    ├── sky130.lib.spice
    ├── tempsenseInst_error_sim_0_noop.log
    ├── tempsenseInst_error_sim_0_reg.log
    ├── tempsenseInst_error_sim_0.sp
    └── tempsenseInst_error.spice

Let me know if you need anything else. 

Thanks,

Sai

[xyce-users]

Thanks for sending this test case.  We will take a look at it.

Eric

[xyce-users]

Hi Sai,

Sorry about my late reply.  I finally took a look at this today.

The reason Xyce is failing this circuit is that it is getting singular matrices.  From the log files you sent, it appears that ngpsice also gets singular matrices, but it manages to recover using a method it calls "transient op".

I did a little bit of work to try to find the source of this singularity.    Sometimes when a circuit matrix is singular, it is for structural reasons, such as two voltage sources attached to the same pair of nodes.  Something like that fundamentally isn't solvable, no matter what parameter values you assign to the sources.

Other times, the problem is not structural, but the problem produces a numerically singular matrix.  For example, there may be lots of tiny values, and this can lead to sets of matrix rows that are nearly the same once you take into account round off error.

It looks like this circuit is producing the second case.   For one thing, if I attempt gmin stepping in Xyce, the initial matrices are non-singular, and they wouldn't be if the problem was structural.  Eventually as the gmin resistors are swept to smaller and smaller conductance values, the singularity comes back.

The circuit is comprised of 9 voltage sources, 181 MOSFETs (BSIM4) and 2297 capacitors.  I also noticed that a lot of the capacitors had a pretty small value.  So, as an experiment, I commented out all the capacitors.  Once I did this, the circuit ran in Xyce.  Removing the capacitors only reduced the number of unknowns from 698 to 659, so the problem size was similar.  Without capacitors, it took about 5 minutes to run in Xyce in serial on my (old) laptop.  I have no idea if the answer is "correct,", even accounting for the missing capacitors, but it ran.

I notice in the ngspice log file that the method that finally works in ngspice is a method they call "transient op", which is probably a pseudo-transient method.  Sometimes when circuit codes use methods like this they add artificial capacitance, and my guess is that ngspice did something like that (although I have not checked).

Anyway, that is what I know for now.   I have to do some other work today but I'll revisit this later.

thanks,

Eric

[Sai Charan]

Hi Eric,

Thanks for checking the testcase I shared. I think I understood the difference between Ngspice and Xyce approaches in this simulation here. The removal of capacitors case is interesting. But I am a bit confused on the artificial caps by ngspice. These artificial caps are added to avoid the singular matrix generation? If so, how different are these artificial caps from that of the original caps you had to remove for Xyce to complete the simulation successfully without any fatal errors?

Also if you still have the logs, can you share them for the case where simulations worked at your end, please?

Thanks,

Sai

[xyce-users]

Hi Sai,

Sorry, I guess my comments might sound like they were contradictory.  I don't actually know (yet) what ngspice is doing for their "transient op" method.    But just from the name, it sounds a lot like a pseudo transient method.

This led me to think about the Spectre implementation of pseudo-transient, as described (briefly) in Ken Kundert's book.  At least in that variant, Spectre adds artificial capacitors to the circuit.  In theory, those artificial capacitors should matter less and less as the algorithm progresses, and ultimately should go away once it converges.  Adding them helps smooth the problem (which solvers like) and also can make the matrix better conditioned.   

Regarding my experiment of removing the existing capacitors from the circuit;  I mainly did that b/c I was wondering if (given that many of them are very small) they were the source of the poor matrix conditioning.    Based on my experiment I think they might have been.  So, another experiment (which I haven't done yet) would be to see if leaving them there, but increasing their values to something less tiny would help.   

When I removed the capacitors from the circuit, about 40 unknowns disappeared from the problem, which suggests that some (all?) of those  removed nodes only had capacitors attached to them.  If those nodes only had very small capacitors attached, then I could imagine the numerical matrix singularity coming from one or more of those nodes and its associated matrix row(s).  I have not checked to see if this is the case yet.

Anyway I plan to dig into this a bit more.  I'll let you know when/if I figure something out.  I can't post my Xyce log at the moment b/c I'm at the wrong computer, BTW.    I think it probably produced a wrong answer however, as the measure commands failed.  It was more of a numerical experiment anyway.

thanks,

Eric

[Sai Charan]

I see. I think I understand what you are trying to say. I will wait for your updates. Thanks for your support, Eric. I appreciate it.

-Sai