Kudos to the

ngspice

developers: During the last days we ran quite substantial mixed-mode simulations (using XSPICE) in SKY130 on our 100-core compute servers: Running very nicely, no crashes, quite good speed; plus the capability of doing result processing inside the control deck (in our case we grabbed a digital result out of a bunch of transient signals and dumped just the digital result in a text file, and this is done over a temperature sweep). Thanks for all the effort! Plus thanks to @Stefan Schippers for

xschem

to build the mixed-mode testbench, plus @Tim Edwards for all the scripts to get a gate netlist into XSPICE! Of course, we used our dockerized solution for all of this :-)

@Harald Pretl Could you share? Interested to see the work.

We will soon, this is our submission to the ISSCC Code-a-chip contest.

I would like some development to that spice-to-xspice script to create individual rise and fall time and capacitive load parameters for each gate so that the timing will correspond closely to the physical design and not just have boilerplate numbers that apply to every gate.

@Tim Edwards That would be awesome!

@Tim Edwards Could you please share this script?

@Amro Tork: The script is in qflow; see https://github.com/RTimothyEdwards/qflow/blob/master/scripts/spi2xspice.py.in (the

.in

on the end means it's a template file, but the only thing that gets changed during installation is the 1st line pointing to the python3 executable).

Thanks @Tim Edwards

Someone should point out to Eric Keiter how useful/efficient the digital simulation is in ngspice. Xyce has a similar digital simulation capability (implemented differently) but is missing the general-purpose LUT gate that I contributed to ngspice that can be mapped to any combinatorial logic gate and therefore allows me to map any standard cell library to xspice primitives. It would be interesting to see a direct comparison of mixed-mode simulation between Xyce and ngspice using this method. Although Xyce can also run iverilog as a co-simulator, which in theory should be much more efficient. There's an application note on the Sandia website for Xyce on how to run a verilog co-simulation. Ngspice has an obscure development branch that I contributed (based on somebody else's development work) that does iverilog co-simulation. The co-simulation environment is hard to set up, though, and is most useful for having verilog code drive a complicated digital stimulus, rather than directly simulating digital blocks inside of a mixed-signal system.