Hspice doesn't obey KCL?!  :o
This's news to me...having raised on a diet of spice in all flavors in school.

I thought spice does indeed solve nodal equations in matrix form [V][G]=[I]

Then, I learnt different simulators used different algorithms/methods to arrive at the solution.

Kindly enlighten if I'm missing some fundamental nevertheless non-trivial stuff

Thanks,
Gau

Dear Geoffrey,

is the situation more dramatic for high impedant nodes or not? I would guess it is...

Kind Regards

Peter

All circuit simulators perform two convergence checks, one on the voltages and one on the currents. Typically, on high impedance nodes the voltage check is more important because small changes in current produce large changes in voltage. On low impedance nodes it is the current check that is more important.

When checking the voltage there is no absolute reference to compare against. That is because the simulator does not know the true solution, it only has its estimate of what it thinks the solution is. So, the simulator performs a check not on V, but on ΔV. It check to see whether the change between the current iteration and previous iteration is small.

The situation is different with currents. There we know that KCL applies, that Σi = 0. This is an absolute reference that we can check against. However, it is my understanding that still, Spectre is the only simulator that actually checks this. All the other simulators check Δi, meaning that they check that the change in current computed between the current iteration and previous iteration is small.

This causes two problems. First, the simulator will generate a solution that violates KCL by an unknown and unbounded amount (with Spectre that amount is bounded by the tolerances). With charge storage circuits this error will tend to accumulate, manifesting itself as a lack of charge conservation. While it is possible to reduce the problem by tightening tolerances, since there is no absolute control of the error, one never knows how tight to make the tolerances.

The second problem is more rare but also more problematic. Spectre uses one absolute check and one delta check. The absolute check is important because it assures that you are close to a solution. SPICE uses two delta checks. The problem is that if something causes the convergence to slow, then both checks can be satisfied even though the simulator is far from the solution. In one case I found that SPICE produced a result that had a regular analog IC dissipating over 300 W. When I tracked down the power, it was all in one transistor stack. SPICE said 10 A was flowing into the top transistor with only a few microamps flowing out. This is more likely to happen if there are bugs in the model, but cannot be ruled out even when the models are perfect.

-Ken

Choose a completely arbitrary set of node voltages for a circuit. This set is not a solution and so when applied to the components of a circuit it will result in currents that do not satisfy KCL. Now assume that the Jacobian is such that the Newton update is very small. Say it is infinitesimal. In this case, the delta checks will pass indicating that this arbitrary set of node voltages is a solution but Spectre's KCL check will fail indicating that it is not a solution.

The bottom line is that the delta check are looking for motion; stop the motion and they pass regardless of whether a solution is found or not. Spectre's KCL check is actually looking for the solution and will only pass when at or near the solution.

In this regard, Spectre's KCL check is clearly better than SPICE's delta check. And from personal experience, I have suffered false convergence with SPICE and I have never seen Spectre exhibit false convergence, even though I am a heavy user of Spectre and only use SPICE very occasionally.

-Ken

The point I have been trying to make is that if the simulator does not check KCL, then false convergence can occur regardless of how tight the tolerances are. And it has nothing to do with scaling issues.

Even if we put aside  the issue of false convergence, if a user has to count on tight tolerances to make up for the error that results from not assuring KCL is satisfied, then their simulations are going to run considerably slower for the same accuracy. This is particularly true if one is counting on LTE controls (which force small time steps) to reduce the error.

Each simulator trades off speed and accuracy. You can always get more accuracy at the cost of running slower, or you can run faster at the cost of less accuracy. However, the figure of merit for a simulator is how much accuracy does it provide at a given speed or how much speed does it provide for a given accuracy. Simulators that do not assure that KCL is satisfied (SPICE) have a significantly lower figure of merit than simulators that do (Spectre) on circuits where charge conservation is important (charge storage circuits).

Personally, the idea of using a simulator that does not assure that KCL is satisfied just seems silly to me.

Currents summing to zero at a point. It's not just a good idea, its the law!

-Ken

byang wrote on Feb 12^th, 2007, 7:29pm:


C*V is not used. The relative tolerance has to be set based on numerical precision: ie, if you add currents of 1e+30 amps and -1e30 amps, you can't expect the sum to be less than abstol; so you take the largest value of current injected into a node and use that to set your relative tolerance.

Gmin is a different topic from KCL, and in general it is a good idea to start a new thread when changing the subject.

But yes, Spectre applies Gmin in a different way than SPICE or HSPICE. The SPICEs connect the Gmin conductor across the substrate junctions (bulk to source and bulk to drain), while Spectre connects it from source to drain.

-Ken