On the low level, Gnucap is capable of loading component models compiled for other programs, most notably spice3f5, ngspice, jspice and bsim. Some considerable support for generic “verilog-adms” models (some early post-modelgen device representation) exists, and support for systemC or systemCAMS models is also intended. With this it is possible to break the barrier between modern algorithms (development) and old, stable and widely used component models.

On the other end, there are schematic capture and circuit related tools that interface to SPICE simulation engines. Some are known to provide a “Gnucap” option, or some amount of compatibility with Gnucap in terms of a “SPICE flavour”, such as xcircuit, oregano, kicad(?), geda-geschem, electric, asco. However, this approach is limited in many ways, and debugging interprocess communication or SPICE netlists can be very frustrating. In these situations it might be easier to think of Gnucap as a “replacement for (some) spice” and make Gnucap behave accordingly, e.g. using a modified spice, spectre or verilog language plugin.

Unlike other simulators, Gnucap is composed of a small shared library with (plugins). The “gnucap” main executable is a simplistic entry point that loads the library and the plugins. It implements batch processing and command based interactive analysis. From here, writing data into files or piping to other (plot/postprocessing) programs is straightforward. The default printed ascii data output format is supposed to be simplistic, gnuplot or gwave can read it, and it is not difficult to parse from your favourite scripting language. (arbitrary output, such as the usual binary formats or shared memory or anything else will be available soon, c.f. output).

Applications may simply skip or replace the main executable, directly use the shared library, and obtain full control over the simulator. Known existing examples (partly work in progress) are gnucap_Python and gnucap-custom (c.f. projects). An interface to other software may involve extensions that provide functionality required by other software. E.g. gnucsator implements (some of) the components, language support and simulation commands that QUCS provides controls for.