Yes it's a pretty cool feature. I have played around with it a bit already. There is also d_process with some cool application at https://www.isotel.eu/mixedsim/index.html

Indeed the d_process stems originally from Uros Platise at Isotel. Its use is best described at his web site. A short intro is also given in chapter 12.4.24 D_process of the ngspice manual. There is an example available at https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/xspice/d_process/ d_cosim is described in the manual in chapters '12.4.25 d_cosim' and '14.3 Digital devices defined by a Hardware Description Language'. An example is available at https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/xspice/verilator/ . Please note that the KLU option is made available by compiling ngspice with a --enable-klu configure option, and then adding 'option klu' to .spiceinit.

So this allows us to use Verilog to drive a test bench?

@Matt Venn: That's my expectation. When I was working with a different co-simulation method (now relegated to some extinct branch of ngspice), I decided that the best approach was to synthesize all internal synthesizable digital blocks; that would generally leave only the testbench itself as the one piece of verilog code that isn't synthesizable and would need to be simulated by iverilog. Note that the original method I was using and the new

d_cosim

method can only launch one instance of iverilog, which is the main reason for working out a method that only requires one subcircuit to be handled by iverilog within the simulation.

My two cents. Being able to connect verilog blocks to analog simulator is definitely good feature for the analog designer. However, from the systems perspective, even better would be to be able to co-simulate any combination of block in different domains controlled with generic programming language. This project (that I am best aware of, but there may be others similar) aims for that. https://github.com/TheSystemDevelopmentKit So, I think the best case would be to have generic programming language testbenches that can seamlessly control the signal flow between various simulators, RTL or analog. This is matter of defining in which language we wish to control the simulators. I think merging analog simulators to CoCoTb would be a great option too, especially if the testbench will be simulated with iverilog anyway. https://www.cocotb.org/

@Marko Kosunen: That's all very nice, but one step at a time. . . The best case is great, but I'll put up with any case for now so long as it actually works.