As mentioned in the question, during the trans simulation, I found that the sum of node currents did not meet the KCL law when checking the trans operating point. I don't know why. Some people say it's parasitic diode current? May I ask how to look parasitic diode current? The pipe in the white box above flows through 5.18u, and the pipe in the white box below flows through 8.63u.
I print the transient operating point of five mosfet:M12-M87-M1-M3-M41 below，it seems that there is no leakage current from bulk.
And printed the current flowing into 5 MOS transistors at this node under transient conditions
One possible cause could be that the models are implemented as inline subckts with additional components around the MOSFET. The annotation of operating points (and printing of currents) could just be showing the operating point of the inline device rather than the true drain current (i.e. the current through the pin).
That said, the default behaviour for plotting the terminal current through the device pins is to plot the current through the subckt pin not the device pin (this is controlled by a spectre option, inlinesubcktcurrent, which defaults to subckt rather than device, although I guess it could have been changed in your environment or on the models themselves).
Another possible cause is to have a high conductance set for gmin, but that seems pretty unlikely as the differences are pretty high.
It's pretty unusual for Spectre to suffer from gross KCL errors because meeting KCL is one of the convergence criteria. Debugging this via screenshots (which are hard to read) in the forums without any knowledge of the PDK you're using is going to be pretty difficult, so I would strongly advise you contacting customer support (submit a support case after logging in).
Thank you for your reply. The PDK is tower .18um. Maybe this is a problem from PDK model. The spectre.out didn't seem to have an error. “Found trapezoidal ringing on node netxxx.” is because I give the input a step signal, such a prompt should be normal?
The trapezoidal ringing is not going to have anything to do with this - that's a common challenge with trapezoidal integration methods in all SPICE simulators with high gain circuits. It may not actually cause problems, and tightening the tolerances or switching to method=gear2only can fix that.
As for the PDK, there are a number of different Tower 0.18um technologies, and doing that investigation is something that should be done via customer support (I don't have the bandwidth to get hold of a PDK, build a test case and try it out myself; there would be too much back-and-forth and I answer here in my spare time).
So please contact customer support as I suggested earlier - that's the right way to investigate this.