Hello, I have a problem. My simulation in xschem is taking too much time. I ran it for a week, but the simulation didn't even start. I have approximately 10,000 transistors, and I believe that's too many. Do you have any ideas on how to simplify the model I'm using for these transistors ? thanks for your help.

are you using a single N and a single P transistor type? 1.8V?

If you pardon my curiosity: what brought the project to use many transistors? • so many because a lot are put in parallel/series to handle a larger current/voltage? -> would a more complex model of the whole aggregated component allow to take the gate count lower? • so many because the analog circuit became rather complex, with many submodules -> simulating the modules separately? • so many replicated modules that multiply the number of transistors in total -> simulating only a single module? • simulating a digital logic in an analog simulator -> validating the analog part with a few gates, and run a digital simulation separately? • the project is mixing a digital and analog part, and you'd wish to validate the analog part as driven by the digital part? -> some mixed simulation with the digital part having a digital simulation, and analog part an analog one?

@Charly Meyer My advise to do the following to simulate such a circuit: • Enable threading in NG-Spice to make the simulation faster. • Use RAW output without

.control

statements make NG-spice run in RAW mode. This will remove a lot of the limit on RAM requirement. • If this is a large digital design. I would rather use a digital simulation and do abstractions at different sections of the design.

Thank you for your interest. Yes, I need to explan more. My goal is to design a digital circuit at the transistor level. The reason for that is to reduce power consumption, and I am using 0.68V instead of 1.8V. The VHDL and Verilog circuits have been created and successfully simulated. I am utilizing the SkyWater technology in the 130nm process.

Sounds like you're not getting past DC operating point which isn't surprising given the number of transistors in digital gates. You could try skipping calculating DC operating point by adding 'uic' to the tran command. You could also consider ramping the supply too

@yrrapt Good point.

Also make sure you’re spice engine is configured correctly for the PDK. That can make a huge difference. I.e. https://ngspice.sourceforge.io/applic.html

If it is a 1-time computation rather than something to do regularly, it could also be worth considering lending some very RAM-ful server.

Thank you @yrrapt*.* I tried to launch the simulation without OP. I had already tried to do that, but I forgot to include "uic". The simulation was launched approximately 40 minutes after the initialization. The simulation takes a lot of time, about 1 hour for each clock tick.

This problem has come up for several designers. Based on painful past experience this is usually caused when GMINDC is similar between N and PMOS and the simulator struggles to converge on bistable (latchs, flops, sram etc) elements. 1 hour per clock tick would imply that maybe your design is paging in simulation or your simulation timestep is set very small versus your clock tick. What is your clock frequency and what is the timestep in the sim?

@Charly Meyer If your supply is only 0.68V, your PMOS devices are operating in the sub-threshold region (Vgs < Vth), assuming you’re using standard 1.8V PMOS devices from SKY130. The simulator/model has harder time converging because of this, based on what I’ve seen. Have you tried to raise the supply to 1.8V as a sanity check? It should simulate faster. I know it’s not a solution but if it does simulate faster at 1.8V, you know what the issue is.

@Eric Smith, How do you simulate the netlist containing 15,000 transistors? Do you make any changes? I attempted to directly run this netlist on NGspice (compiled with KLU) on Windows, but it takes a significant amount of time, more than just a couple of minutes. Could you please provide some guidance or suggestions on how to improve the simulation efficiency? Thank you.

Indeed this circuit would be an interesting test case for ngspice. Could you make the ngspice netlist available (here or per private email)?

@Charly Meyer I ran exactly Holger Vogt’s ISCAS85 benchmark which is on the link I gave you with only one modification, to change the path of sky130.lib.spice I run the ARM version of iic-osic-tools on a 16" M1 MacBook Pro base config. My version of iic-osic includes ngspice-38. The final output of the ISCAS85 deck is:

Circuit Inventory

BSIM4v5: 14942
Capacitor: 48376
Resistor: 33847
Vsource: 208

ngspice 1 -> exit
ngspice-38 done

real	10m1.436s
user	8m37.347s
sys	0m4.227s

But to be fair to the M1, I was also doing other work at the same time…

@Holger Vogt How to get NGSpice to use KLU as a solver?

ngspice with KLU is still experimental and under test.

Thanks @Holger Vogt Are you seeing good improvement in speed using KLU? Are you using klu implementation from the Sparse Suite library?

For the example cited above by Eric I see a simulation speed enhancement by a factor of three.

I launched on Windows the benchmark and changed only the .lib. After 4 hours, I quit Ngspice. I'm trying to install Ngspice with KLU on Linux, but I don't know how to do that. Where can I find documentation to install it?

As KLU is still experimental, there is no 'ready to install' solution.

@Holger Vogt I have followed the same steps and encountered this error when executing ./compile_linux_klu.sh