I'm Ali Elshorbagy and I'm working at Mabrains, I made a small testcase to document a weird behaviour that i found when using loops inside ngspice. I'm simply doing dc sweep on sky130 nfet transistor on different widths and lengths. I just change the device parameters inside while loop inside control statement. I found an unexpected behaviour. Initial value for width and length affect solution values.  Normal behaviour during simulation is initial values will be replaced by values given inside the loop but surprisingly i found that initial values affect the results. In this git repo i have 2 netlists (netlist1.net and netlist2.net) exactly the same but initial value for width and length are different. When i invoke ngspice to run those two netlists i have a completely different results https://github.com/mabrains/xyce_sky130/tree/main/testcases/ngspice_loops_behaviour I found a similar behaviour whe i used .data inside Xyce and can be found here: https://github.com/mabrains/xyce_sky130/tree/main/testcases/Xyce_data_behaviour @User @User

@mkk @jeffdi @Tim Edwards We need your support on this.

This can be troublesome, because the PDK has a scale factor 1e-6 somewhere, so the values while creating the instance can be in set in meters, but in the loop, they should be in microns. This is just a guess.

@Luis Henrique Rodovalho We are aware of the scaling. But I think the idea that came to our mind that it should take the scaling factor even in loops?

I've tried to simulate the same netlist in my own PC using ngspice. I think I know what the problem is. When the models are loaded, they load just one of the bins, for that specific transistor dimensions. The loop won't reload the models and use different bins for each simulation.

@Luis Henrique Rodovalho: That is most likely caused by the recommended setting

set ng_nomodcheck

in the .spiceinit file, which reduces the startup time. If not set, all bins of all models are processed. This would solve the issue at the expense of taking over half an hour to start up.

The best solution for this case should be using an interpreter to run a different netlist for each transistor dimension. Sooner or later, the same transistor characterization should be done with other corners.

That was just conjecture based on what I understood about the setting, which was probably a misunderstanding.