Exploring the Underused Potential of Ngspice/XSpice Code Models: An Alternative to QSpice?

Greetings, fellow forum members,

Recently, QSpice was released, significantly reducing the effort required to co-simulate SPICE with models coded in C or C++. This is arguably QSpice’s killer feature. However, there’s a significant drawback: it is not open source and lacks Linux support.

For some time now, I’ve been aware that it’s possible to write your own models in C (and possibly C++) for Ngspice. This functionality is provided through XSpice, which is integrated into Ngspice. The team at Isotel has demonstrated their know-how and showcased the potential of this approach:

https://www.isotel.eu/mixedsim/index.html

There seems to be not so many individuals writing their own models in C for Ngspice on the internet, and there is almost no information on how to proceed with it.

With this post, I aim to initiate a discussion on the following points:

  • Are people unaware of Ngspice/XSpice code models?
  • How can we make these features as accessible as, or even more accessible than, QSpice?

Best regards,
2nOrderEDO

More information on using C or C++ code in ngspice is available at Ngspice, the open source Spice circuit simulator - Special features.

You may write your own code model (C plus Macros, analog or digital), link to external C processes (with digital models) or load compiled Verilog digital code into ngspice.

Outside of KiCad there is a community active on IC design at https://open-source-silicon.dev/ and its very busy Slack discussion groups, which may have used the external interfaces.

The KiCad simulation idea stems from a different perspective. Circuit design with KiCad denotes assembling discrete devices (resistors, capacitors, transistors), simple integrated circuits (logic, opamps, others), and complex digital ICs (memory, micros etc.) on their PCB. The former two categories are amenable to ngspice simulation. The user expects ready to use simulation models for their devices. Code models may have become part of these device models, but are typically not used explicitely.

I do see at least two application areas for explicit code model use in KiCad.

If you want to simulate a circuit design, you always will need a stimulus, an input. This of course may be a simple sine wave, but it could for example be a sine, rectangle or triangle swept through a given frequency range. Or you want to input stimulus data from a table located in a file (digital or analog). Code models distributed with ngspice may exactly do this.

Another area is system simulation. Can I design a basic half-bridge power driver for a dc-dc converter, which includes an error amplifier, a pulse-width modulator, high-side and low-side drivers, including dead-time control, e.g. for simulation testing my new power output stage? Yes, I can, using code models.

Code models have been available in ngspice since 2002. Currently 68 code models (analog, digital, and hybrid) are offered (see ngspice-42 manual in chapter 12). What is needed to do to make them available for the use in KiCad? You will need a symbol, to put it into the circuit on the Eeschema canvas. Typically then you need to put the associated code model (the A line and its .model line) into a subcircuit, to allow easy attaching to the symbol. For sure some experience in ngspice usage and netlists is required. I am to prepare in a video an example for creating a VCO using the “Controlled sine-wave oscillator” code model.

Ideally a new symbol library, e.g. named Simulation_CM, would have been defined, including symbols for the relevant code models and their subcircuit models. This would immediately relieve the underusage of the already existing models. Is anybody out there raising his or her hands to bear this challenge?

4 Likes

Another thing which would be interesting to try out, is getting micro-controllers simulated inside KiCad, e.g. by using GitHub - mcusim/MCUSim: MCUSim is an XSPICE library with microcontrollers.

Especially for those more complex models, it may be useful to add a Rust abstraction for XSPICE in the future. As everything is its own library and it is based on a C API this should be quite doable and self-contained without affecting ngspice.

1 Like