Incorrect export of Spice net-list from EESchema

[xarx]

EESchema incorrectly exports transistors (and probably also other components) into Spice net-lists.

In Spice, the pin order must be CBE, but EESchema seems to export the pins in the order of their pin numbers. The pin numbers change with the transistor physical package (TO126, TO220,...), but the pin order in the Spice net-list must not. It seems to me that currently I have to choose an el. component symbol according to what I'm planning to do with the schema - different pin-out for simulations, and different pin-out for PCB.

Originally discussed here: https://forum.kicad.info/t/incorrect-net-list-export-for-spice/1605

[xarx (xarx-w)]

The current situation in KiCad is as follows:

By default, the pins are generated in the order of their numbers. But this can be changed by using the user field named "Spice_Node_Sequence". However, this is impractical, as either one has to use modified libraries that have this field set, or he must not forget to set this field manually for each component. The same situation is with the reference prefix - the prefixes used by KiCad differ from those required by Spice (e.g. "Q" in KiCad should be "Q", "M", "J" or "Z" in Spice). So, one is forced to name component references according to the needs of Spice, if he is planning to use the schema for simulations. And there is currently no user field analogical to "Spice_Node_Sequence" concerning the prefixes.

The KiCad -> Spice netlist export has also other problems, for instance is doesn't convert values properly (or rather at all), forcing the use of Spice syntax in KiCad schemas. (E.g. 1k5 or 1M resistor - the first one would be syntactically incorrect for Spice, the second one would be interpreted as 1 milli Ohm, as Spice is case insensitive.

[xarx (xarx-w)]

I'm going to fix that. There are several areas that need to be fixed:

1. Support for user field "Spice_Element_Prefix", in analogy to the already supported field "Spice_Node_Sequence".
2. Extending the existing KiCad libraries by (both) these user fields, so that one doesn't need to think on that when creating a schema.
3. Creating a heuristic algorithm that guesses the correct Spice prefix and correct pin order. Something like this:

    - For R, C, L, keep the prefix
    - For D, keep the prefix, and the pin order is A-K
    - For Q that has pins B, C and E, the prefix stays Q and the correct pin order is C-B-E
    - For Q that has pins D, S, G, the prefix is M and the pin order is G-S-D
    etc.
    - By default, the reference should be prefixed with X

4. Convert values (e.g. 1k5, 1M) for R, C, L and voltage and current sources.

[jean-pierre charras (jp-charras)]

The golden rule is to use suitable libraries and schematics for a given purpose.
Bad libraries or bad schematics means bad result.

All "issues" you are talking about are info entered by users: they are not in Kicad code.
Therefore it is *not* a Kicad issue.
We can fix errors in code, not errors in schematics.

Do you really think Kicad can know what 1M means, if spice does not knows that ?

[xarx (xarx-w)]

Jean-Pierre, you are rejecting statements that I have never stated. I have never said that KiCad should know what 1M means, nor I am talking about errors in schematics. In my opinion it *is* a problem of KiCad code, though not of KiCad itself, but of its netlist export module.

Nevertheless, I would like to re-try to explain the problem to you, if it is unclear from the issue description. Probably it should be discussed elsewhere than here in the bug-tracker. Please suggest a place to discuss it. A user forum? Or a developer forum (I'm not a KiCad developer).

Anyway, I am glad that I haven't started any work on that because this is exactly what I wanted to prevent - to spend time by developing something, which would be rejected then. Exactly for this reason I tried to explain first what I was going to do.

[jean-pierre charras (jp-charras)]

The right place is the developer list:
see:
https://launchpad.net/~kicad-developers
and
http://lists.launchpad.net/kicad-developers

Especially if you plan to add features in Eeschema.
This is mandatory not only to add features, but also to know what is existing, and what is planned.
(your problem is not a netlist bug, it is a lack of feature to support spice simulation in Eeschema, which is very different)

FYI, I am thinking "Spice_Node_Sequence" is just a bug, This is a very poorly designed feature.
Eeschema needs a *good* spice support.

[xarx (xarx-w)]

I completely agree that "Spice_Node_Sequence" is a "very poorly designed feature", but that's all I can do with that. Spice support would need at least something like CvPcb (not that this program is ideal either). But I don't have time to develop anything this big. So at least I wanted to make the existing functionality usable, and to modify it along the same lines it is already designed. This way it cannot get worse, only better.

If someone creates a full-featured module for Spice simulations, I will invite that, but I don't believe this happens in the nearest several years. So I'm suggesting to make the feature usable now, not to wait for several years for a "good solution". If the "good solution" occurs, this hack can be thrown away, it's just a single .cpp file (plus a dialog).

[xarx (xarx-w)]

This is the bug-report that introduced the "Spice_Node_Sequence" user field: #706558 (year 2011)
The reasons that led to its formation are similar to mine.

[Wayne Stambaugh (stambaughw)]

You may want to look at what the oscad team is doing. Search the
mailing list for "oscad" for more information.

On 11/3/2015 8:31 AM, xarx wrote:
> I completely agree that "Spice_Node_Sequence" is a "very poorly designed
> feature", but that's all I can do with that. Spice support would need at
> least something like CvPcb (not that this program is ideal either). But
> I don't have time to develop anything this big. So at least I wanted to
> make the existing functionality usable, and to modify it along the same
> lines it is already designed. This way it cannot get worse, only better.
>
> If someone creates a full-featured module for Spice simulations, I will
> invite that, but I don't believe this happens in the nearest several
> years. So I'm suggesting to make the feature usable now, not to wait for
> several years for a "good solution". If the "good solution" occurs, this
> hack can be thrown away, it's just a single .cpp file (plus a dialog).
>

[jean-pierre charras (jp-charras)]

Oscad is now renamed ESIM. See
http://esim.fossee.in/home

And please, switch to dev mailing list, if you want to work on netlist generator

[xarx (xarx-w)]

And #743027 is the other hack that found its way to get to the KiCad build. My patch wouldn't be any worse.

[xarx (xarx-w)]

Actually I'm using eSim, and that's why I came here. Because there is very little valuable code that eSim adds to KiCad. And I feel that most of it could be avoided if KiCad netlist export was fixed. The rest could be converted into a small stand-alone application, or a post-processor could be used. eSim is very buggy.

[xarx (xarx-w)]

I'm attaching a patch for points 1 and 4 above (see comment #2).

What does this patch do:

1a. User field "Spice_Reference_Prefix" prepends a prefix to the component reference.
Spice uses different prefixes for different types of transistor. This user field allows to distinguish these transistors even though in schema they all have a reference starting with letter "Q". This determination can't be done in netlist post-processing as the necessary information is already missing there.

1b. User field "Spice_Node_Sequence" now accepts pin names too, not only pin numbers as before.
This simplifies modification of component libraries where each component has a different pinout. Also, this allows a replacement of a component chip in a schema (EESchema -> Edit -> Select) without corruption of Spice pin order (which would occur when pin numbers were used).

1c. Error handling added so that one can see in the exported file what was wrong.

2a. A new check button "Convert R, C, L values to Spice format" on the Spice netlist export tab added.
This is in order to keep backward compatibility.

2b. Convert values (e.g. 1k5, 1M) for R, C, L into the Spice format (1.5k, 1Meg).
Only when the checkbox in 2a. is checked.

[xarx (xarx-w)]

I'm attaching a patch for KiCad component libraries.

!!! This patch does not alter the current behaviour/properties of the library components in any way. !!!

This patch implements point 2. of the TODO list in comment #2.

Up to now, different component libraries (of transistors, diodes) had to be used for Pcb creation, and for Spice simulation. This patch allows one to use the same components for both purposes. Also, it makes life of a newbie easier, because he is usually not aware of the necessity to use different components for Spice simulation that those offered by KiCad.

What this patch does:

This patch modifies several KiCad component libraries so that the components can be used directly in Spice simulations. It does so purely by adding the correct Spice pinout and correct Spice reference prefixes to the component definitions. This amendment has no influence on the visual appearance and/or usability of the components, the new information is not shown in the schemas. It is visible only in the Library Browser.

[xarx (xarx-w)]

I decided not to implement point 3. of the comment #2 for now, because the heuristic algorithm is not so simple. And if Mark Roszko implements a new netlist generator as he announced, all the work would be in vain. The above patches reduce the necessity of this heuristics to a minimum.

[Wayne Stambaugh (stambaughw)]

My preference is the same as JP's suggestion. Create a spice symbol
library specifically for spice simulations (spice.lib?) rather than
tweak the standard libraries to rearrange the spice node ordering. If
you want to use these symbols to create a netlist for laying out a
board, create the appropriate footprints rather than then the changes
you suggested. As far as the values go, user's who know how create
spice models know that 1M is not the same as 1MEG in spice. IMO, this
layer of obfuscation doesn't really do the user any favors. Spice model
schematics are not the same thing a schematic for laying out a pcb.
Connectors have no meaning to spice, and source symbols have no meaning
when laying out a pcb.

The new schematic and symbol library file formats are going to be
introduced during the next development cycle so we can discuss adding
simulation support into the new symbol library file format at that time.
 I will insist that any change to support spice modeling is a complete
well designed implementation. Even if it is just to support exporting
spice netlists and not the actual modeling itself. I want to avoid a
series of quick hacks to solve each individual users problems.

For future reference, when a lead developer sets the bug report status
to "Wont Fix", that means that it doesn't fit into the current
development plans. You should have discussed your ideas on the
developer's mailing before you made your changes.

On 11/9/2015 10:30 AM, xarx wrote:
> I decided not to implement point 3. of the comment #2 for now, because
> the heuristic algorithm is not so simple. And if Mark Roszko implements
> a new netlist generator as he announced, all the work would be in vain.
> The above patches reduce the necessity of this heuristics to a minimum.
>
> ** Changed in: kicad
> Status: Won't Fix => New
>

[xarx (xarx-w)]

A simple schema for testing various aspects of the patch above. One must look at the generated netlist file to see whether the netlist export works correctly.

[xarx (xarx-w)]

Wayne, I tried to discuss that in the mailing list, but none of you reacted. Neither Jean-Pierre who asked me do that, nor you who are asking me now, nor anyone else. I asked explicitly for any objections. None came, so I took it that way that you don't have any.

I apologise for changing the bug status, but I did that in the view of what I explained above.

I'd like to react to what you've written, but I'd like to move that discussion to the forum. If you'll answer.

[Wayne Stambaugh (stambaughw)]

We can discuss it. The reason I did not reply to you mailing list
message is because JP listed his objections when he changed the status
to wont fix and I've been busy working on the stable release. I have so
much time I'm willing to spend working on KiCad. Things that are low
priority for will fall through the cracks. I will continue to
prioritize my time in a manner that is in the best interests of the
project. Your priorities may not align with mine. I will reply to your
email post and give you my input (some of which I already have) if you
are interested in seeing this through to completion. We are in feature
freeze for the stable release so any changes to the behavior (which your
changed are) of the spice netlister will not be part of the stable release.

On 11/9/2015 2:09 PM, xarx wrote:
> Wayne, I tried to discuss that in the mailing list, but none of you
> reacted. Neither Jean-Pierre who asked me do that, nor you who are
> asking me now, nor anyone else. I asked explicitly for any objections.
> None came, so I took it that way that you don't have any.
>
> I apologise for changing the bug status, but I did that in the view of
> what I explained above.
>
> I'd like to react to what you've written, but I'd like to move that
> discussion to the forum. If you'll answer.
>

[xarx (xarx-w)]

I don't want to to take your time, but I am "interested in seeing this through to completion". So I would appreciate if we can discuss this. Not a long discussion. https://lists.launchpad.net/kicad-developers/msg21206.html

[xarx (xarx-w)]

I'm attaching a new patch for this issue, changed in the way we've agreed a long time ago (in November).
That is:

* The Spice exporter now uses a single user field "spice" in order to modify the netlist export.
    spice: node_seq=C,B,E model=NPN

* The following attributes are currently recognised: enabled, prefix, node_seq, model.

* Those spice attributes that are not interpreted by the exporter, are written to the netlist as comments. Then, they can be used for optional post-processing of the generated netlist by a script.

* Most of the postprocessing performed directly by the exporter can be disabled in the netlist generator dialog, if all postprocessing is done by an external script.

* Outdated code/functionality was removed from the spice netlist generator, as was agreed then.

When/if this patch is accepted, I will write down the documentation.
Please, let me know if there is anything else needed for the patch to be accepted.

[xarx (xarx-w)]

I'm attaching a simple demonstration of how the code change above can be used for integration of KiCad with LTspiceIV and Ngspice.

Place the .cmd/.sh files into the <KiCad> installation directory. Modify the SPICE and LIBDIR variables inside the scripts according to real paths to the corresponding Spice programs. The .cmd scripts were tested with LTspiceIV v4.23h and ngspice v26, on Windows 7. The .sh scripts were not tested with KiCad, as I don't have a POSTIX system with KiCad.

Unpack the sample project, and open it from KiCad. Open eeschema, press Netlist Generation. Choose the Spice tab, and check "Perform simple netlist postprocessing". Into the Simulation Command text field, enter the name of the chosen script, e.g. "ltspice.cmd". Press Run Simulation, LTspiceIV should open, the top window will be black. Press Ctrl-A and choose e.g. "I(C1)". An oscillation curve should appear.

This is just a simple demonstration. My idea is that these simple scripts can be replaced by more sophisticated scripts that would perform a more complex netlist post-processing, and could present basic simulation parameters in a dialog. In the way it is done e.g. by eSim.

[xarx (xarx-w)]

I'm also attaching a patch for the modification of the default KiCad component libraries.
Please, consider this as a demo of the use of the "spice" user fields.

[PCB Wiz (1-pcb-wiz)]

This looks great, Which version of KiCad/eeschema does this need to run ?
If not in the release yet, any ideas in when it can be included ?

[Jeff Young (jeyjey)]

So now that we have Spice integration, is this any longer an issue?

[Wayne Stambaugh (stambaughw)]

The build in spice simulation allows for remapping symbol pin outs to match the spice model. I don't know if we export this information with the old spice netlist generator. @Orson, do you know if this was fixed?

[Maciej Suminski (orsonmmz)]

Yes, the old netlist generator is the base for the ngspice importer and takes into account custom node order when specified in "Spice_Node_Sequence" field.

[Wayne Stambaugh (stambaughw)]

I'm assuming that pin remapping will also be applied when exporting a spice netlist so this bug has been fixed.