There is no standard or version in Spice currently maintained in public. All known implementations (both free and non-free) use their own dialects and are mutually incompatible.

Gnucap Spice support was originally implemented during Spice2 times. More features, mainly behavioural modelling were added, with goals similar to Spice3, but using a more regular syntax. As a consequence, Gnucap is not compatible with any Spice3 derivative out there.

Gnucap is based on plugins, including command plugins and “language” plugins. The lang_spice plugin provides Spice compatibility, to some extent. So, mostly we can use Spice netlist. By “mostly”, we acknowledge that there are some features that might be in one and not the other.

Since Gnucap has moved to plugins around 2010, the parsing is essentially separate from the core library.

The use of plugins gives Gnucap the flexibility to meet several incompatible ways to do it. Having a compatibility mode could make it easy for users to try it, then to discover what we have and they don't.

The plugin apps/lang_spice.cc works well for what it was meant to do (including some compatibility kludges with ancient commercial Spices). It can be thought of as an example or template for more specialized and higher levels of compatibility, if so required.

This concept is also demonstrated in Gnucsator, a (partial) drop in replacement for Qucsator, the default simulator used by the Qucs project.

Spice language plugins could be used as a basis for a translation from Spice to Verilog, possibly in combination with modelgen-verilog. There is an outline here.

Gnucap provides the data structures to support the most relevant parts of any Spice. The last known real blocker, the “global” directive has been sorted during the node rework. There are known issues with case sensitivity, but these won't show up in a purely case insensitive run.

When it comes to Spice compatibility, the following questions may arise and have been discussed ad-nauseam here and in other places.

- Which Spice? Is it worth providing, say, ngSpice or Xyce input compatibility?

We think so. And we will definitely offer help.

- Spice lacks essential modelling features in modern applications. Why bother?

Verilog-AMS “includes” Spice as a subset (the chosen dialect is left as an implementation detail), and the use of spice “models” in a Verilog-AMS context is well defined. The idea here is to streamline the transition. Much like git can clone subversion repos, and compiled fortran code retains the use in a C program.

- Most user defined Spice devices come as subcircuit macros, can't we just translate those to Verilog-A?

This might solve all our problems, since Verilog-A is unambiguous. We need to support Verilog-A anyway.

- What about devices hardwired into some Spice simulator?

Most of the behavioural modelling, such as controlled sources have been in Gnucap for a long time. Other simulators use a different syntax for them. Devices with a more regular interface, such as semiconductor models can be used without modification. This saves time on the reimplementation of the model itself, but does not guarantee syntactic equivalence in the simulator.

- Where do I start?

Compile a list of things that need doing. A one mile walk starts with a single step. See the TODO list below.

In order to obtain compatibilty with a Spice implementation, the following may be useful. The preferred implementation only involves plugin changes.

- a scale option (seen in ngspice)

- raw file output

- B sources (?)