So far, any good recommendations for speeding up s...
# chipalooza
b
So far, any good recommendations for speeding up spice simulations on C extracted and R-C extracted layouts, while still maintaining accuracy? I am able to get many of my CACE simulations to run with the C extracted netlists, but they chug. I haven't been able to simulate the R-C extracted netlists without ngspice hitting a wall with timestep size.
l
b
Thanks for the thread! Will try
.option klu
. I'm also going to noodle with
optran
instead of
tran
to see if it speeds things up without degrading the results.
t
Note:
.option klu
only works if you have ngspice version 42 and it has been specifically compiled with the KLU option. I did not see much difference in using KLU, but I expect it depends on the type of circuit. I understand it works well with circuits with fast edge rate digital signals.
r
Try to reduce the accuracy tolerance of ngspice. I got mine to run setting the following: .option reltol=1e-3 .option abstol=1e-3
When the tolerance is set to low accuracy, the simulator will sometimes run into the weeds. To overcome that, reduce the time step if running .tran. For example, instead of
.tran 10us 1ms
Change it to
.tran 1us 1ms
b
When trying those tolerances with reduced accuracy, it at least gets ngspice to start some of the simulations. Haven't yet gotten an R-C sim to complete. Some of the DC initial conditions are nonsensical. Ngspice is giving feedback now about which nodes it choked on, which may help me.
r
One thing you could try, which worked for me is to reduce the number of nodes in the circuit by telling Magic not to break up each interconnect into so many smaller pieces. Instead of doing this:
Copy code
extresist tolerance 10
do this:
Copy code
extresist tolerance 0.001
It helped me reduce the number of nodes roughly 30%, ballpark. The total resistance is still the same, just less nodes, easier for the simulator.
b
Any idea how this integrates into the CACE flow? I've been allowing CACE to generate extracted netlists so far.
r
I extract manually in Magic, create a symbol in xschem that represents the extracted netlist, swap it in, and run CACE in schematic mode.
t
By default, CACE checks the last modification timestamps of existing netlist files against the last modification timestamp of the layout or schematic. So if you manually generate a netlist and it's more recent than the layout, then CACE should not attempt to run its own extraction. Eventually I will need to add some options to modify various scripts in CACE. Feedback is valuable.
r
Yes, I’m aware that CACE won’t regen the netlist if I only update the extracted netlist, so what I’ve been doing is re-saving in xschem each time to update the timestamp to get CACE to regen. It wasn’t a problem for me so far (I think) but it’s possible to forget.
b
I was following Robin’s advice from their GitHub README about creating a symbol that refers to an included netlist. But if I understand Tim correctly, I can generate a custom spice netlist for the top-level IP with the extraction parameters I specify, and as long as I name it correctly and don’t change the Xschem schematic for the top-level IP, CACE will black box the symbol in the CACE testbenches and replace it with my custom extraction. I will try that when I get back to my workstation.
r
That's cool. Please let us know if you manage to get it to work.
b
I can confirm this works. The
*.spice
filename has to match what the CACE datasheet expects. Furthermore, in the spice netlist, you have to ensure the subcircuit name matches the spice filename, in case you copied it from a file where you named it something else.
I can also confirm that changing the
extresist tolerance
value didn't change my situation much (still have >3000 resistor nodes), but I have a pretty easy way to try things out now.
r
Awesome! Thanks Brady for letting us know.
b
There were two R-C extracted capacitors with negative values in my netlist. I removed them, and this sped up simulation time dramatically.
t
I thought I had fixed all of the bad bookkeeping that was producing negative capacitances, but apparently not.