I achieved a significant speed up with xyce-parallel 1 core vs 6 cores for the simulation of a 7-bit DAC at 175s vs 273s total simulation time using default settings. I have not tested ngspice or hspice yet. However, when I move to 8-bit DAC and higher (each time doubling transistor count, resistor count and simulation time) I suddenly get 24 Singleton problems (see log). I am not sure if related, but the simulation time balloons when they are found. Worse, when going to even higher bit-sizes, the DC operating point cannot be computed, failing after two 'Step size reached minimum step size bound' messages. Any ideas how to analyze and solve the DC operating point problem for my circuit?

@Steven Bos in some cases it is better (expecially for large circuits) to avoid calculating the DC operating point. Instead you start from an all-0 conndition. All nodes are assumed to be 0V at the very beginning. Set your voltage sources with pwl functions so that everything is 0 at time 0. Then ramp up the vcc supply keeping asserted reset signals if any (ramp them up if asserted high at the same rate as vcc). When vcc is stable deassert reset signals. This will ensure a sane state of the circuit. Avoid latches or flops without reset signal for this reason (and this is not only for helping the simulator, believe me, avoid flops without async reset in any design). You start transient analysis with something like: .

tran 0.1u 500u uic

. The

uic

parameters tells spice to avoid calculating the operating point, using the initial state (all-0) of the circuit instead. You can use a

.ic

coommand to force initial state for some nodes that are in high impedance, do this only in case of problems.

Excellent advice, Xyce is now immediately going to the Transient Calculation phase, skipping calculating the OP and finishing under 175 sec. The 7-bit DAC is working fine with this method, but the 8-bit DAC still complains about having found Singletons, reporting using hypergraph load balancing and then computing for hours until reporting the first data point after hours of computation (1% with 9 days remaining). I was expecting a 4x in total simulation time (ie. ~700 sec) compared to 7-bit DAC based on the previous total simulation time data points. Has the circuit become too big and partitioning of the matrix is now an issue?

This is probably a question for the xyce developers. On your side just check that there no errors in the circuit (unconnected nodes, swapped node labels on subcircuits, ...). Also, before creating the netlist open the ERC window (View -> SHow ERC window), then create the netlist. ERC window reports warnings, go thru them and see if everything is OK.

The Xyce serial version is computing the 8-bit DAC without any reported issues in 691 seconds (see log).

This is a universal problem of parallel simulators and also mixed mode simulators that partition the circuit into pieces (for example digital vs analog).In some cases synchronization of the various blocks requires timesteps re-evaluation and in some cases it can lead to deadlocks or slow simulations. I remember in my company we had a hierarchical mixed mode simulator that was able to recognize the digital parts and partition the circuit accordingly, using event driven simulation for these parts. The overal simulation time was huge and simulating ALL the circuit at transistor level was faster.

Thanks for all these insights @Stefan Schippers. Now I saw first hand that circuit parallelization is hard. I hope that @Eric Keiter or @Joshua Smith can provide some insight how to approach this partitioning problem so that I can learn about parallel circuit simulation a bit. For now I will stick to the serial version.

@Steven Bos sync reset is ok in system where you always have a running clock. If not then it is better to use async reset, so flop states are set to a known value immediately (assuming there is a reset pulse).

Great, good to know. Then I need to change my design a bit because I am clock gating the flops and expect the user to initizialize the flops with a single pulse before use

Some designers use flops without reset, because they say "*_ok the output might be 1 or 0, but my circuit doesn't use these outputs before loading some data into them, so who cares_"*. This is a terrible assumption. If you have a chip with high current consumption and you want to investigate, if you have flops with no reset every time you power on the chip you might have different values in the flop that might cause different Icc values. This makes your debugging in the lab a nightmare. Never do that.

Ah yes that makes perfect sense for debugging!

Yes in many cases random data is no problem since you initialize before use. However if something is not working as expected these random patterns make debugging extremely hard. Always initialize all stateful objects to a known state even if you don't depend on this.

https://avlsi.csl.yale.edu/chips.php ASYNC