Add new simulation symbol lib

[evanshultz]

The first step in fixing #805.

As mentioned at #805, there are the many useful SPICE elements which are missing. The existing SPICE library's symbols are, frankly, just plain old butt ugly. Using the list of primitives at http://ngspice.sourceforge.net/docs/ngspice-manual.pdf, I have created a new set of symbols. This PR is only for voltage and current sources.

While KiCad doesn't currently have GUI control for all sources, I elected to created them all as they work if the SPICE parameters are entered manually. I have not implemented the external source since that may be platform dependent and would just all-around be better with a GUI.

Schematic for testing (also attached):

new_spice_models.zip

Load this schematic and add the library in this PR as a new library named spice. You can see the sources are working by noticing changes in the random sources on each run.

And the resulting waveforms from voltage sources:

And current ones:

Questions:

1. The library is named spice.lib. Some of the libs have a lowercase name but most are uppercase. Which should this be?
2. The default parameters for the sources are selected to make them show up nice in the simulation above. If these symbols are OK, let me know and I'll push some typical default source settings (like 1kHz 1V for the sine voltage source and 1A for the DC current source, for example).
3. I've removed all extraneous symbols from pspice.lib. Since the existing transistor symbols simulate fine I don't see a reason to have them again, especially when they're big and ugly compared with the same symbols in our "main" libraries.
4. The diode symbol here is flipped (cathode to the right) relative to the old simulation lib and also relative to the normal library symbols. OK?

I'm marking this for 5.1 since I'd really like to make these available at that time. Not necessarily for RC1, but the final 5.1 release.

Edit: All Travis errors are OK with the belief that putting the source info on the schematic is good for simulation symbols. This is common in other simulation software. And it sure is helpful!

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
  • A new fitting footprint must be submitted if the library does not yet contain one.
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

[poeschlr]

You mention that you removed something from the pspice lib but this pull request does not include that. Did you forget to push that or have i misunderstood you?

Regarding name: Only the pspice and power lib use lowercase naming. The former because we did not touch it at all in the transfer, the later because some versions of kicad depended on that name.

[evanshultz]

To make this library I removed parts from the existing pspice.lib that I don't believe are needed. The previous conversation (linked above) indicated that when this was merged and ready, the old lib could be removed from sym-lib-table so only the new one remains. For that reason, I'm letting everybody know that I didn't bring over symbols which are duplicated elsewhere in our library and work fine.

I would prefer to capitalize the library name then. And instead of Spice.lib, which could be OK since the engine currently used is ngspice, I suppose we could also consider something more generic like Simulation.lib?

[poeschlr]

I am still not certain what you mean with the removal comment. There are only two changed files listed by github. the pspice.lib and pspice.dcm are not changed by this pull request. Is this as it should be?

(Nothing could have been removed by this pull request from that lib as it is not touched by this pull request. Meaning for your comment making any sense the removal must have already happened in a past pull request. Or you forgot to add or push these changes. The later option is why i ask as it something that can easily happen.)

[evanshultz]

I didn't change pspice.lib. When I created this new lib, I copied pspice.lib, renamed it to spice.lib and removed parts that were elsewhere in the library. So only two new files were added, and the removing was done to the copy (the files submitted here). Yes, it does sound confusing. And yes, "something" can easily happen. But this is as I intended. Sorry if I haven't described it well.

[poeschlr]

Ok i get it now.

Regarding name: I am not so sure if a more generic name is a good idea as these symbols kind of rely on the spice syntax.
Assuming this syntax is even portable between different spice dialects. If not then we might want to really name it Ngspice (or ngspice)

Another possibility is to allow for future addition of symbols with other dialects. then we could include the prefix Simulation to the symbol name followed by the used dialect. In this case Simulation_spice or Simulation_ngspice.

[evanshultz]

The sources, at least, use a general spice syntax. Other simulation tools copied this syntax for their sources since it was common. I'm sure there are cases where that isn't true, but I've used a number of simulators and they all specify sources this way.

For more specialized symbols it's not all common, but for now I think let's stick with the basics and provide a nicer alternative to the existing pspice lib. We can expand on this later and I like your idea.

[poeschlr]

Ok in that case lets go with Simulation_spice for the sources and if we later add something that is specialized to ngspice we can still create a Simulation_ngspice lib.
Make sure the sym lib table comment makes it clear that the symbols are compatible with ngspice (and other spice simulators)

[poeschlr]

Additionally: don't forget to add the library to the sym lib table.

[poeschlr]

@evanshultz i would really like to see this in 5.1. Only thing required for merging is renaming the library and adding it to the sym-lib-table.

[evanshultz]

Alright. Renamed the lib and added the entry in the symbol table. I also changed the default source parameters to something generic (instead of the special ones I used to make the simulation above look nice).

Is there a way to link to http://ngspice.sourceforge.net/docs/ngspice-manual.pdf that would be helpful and convenient? Maybe in sym-lib-table? If users want to use these sources but need help they will find there.

[poeschlr]

Hm so does this mean the sources are pre setup for a specific usecase?
am(1 0 100k 1k 1n) looks to me as if this is indeed the case. might it be better to have them in the lib with "named fields" that the user can replace without needing to read the manual? (and getting an error message if they do not replace it.

Or can the models read from normal kicad symbol fields? (In that case one could pre fill the field with sensible values)

Edit: I would also be ok to merge them as they are now. At least if the model field is set to visible. (The user should then be able to notice that there is something given in the symbol.)

[evanshultz]

They are set up with some generic parameters. The text you show above is visible on the schematic canvas so the user can plop it down and then go right to work adjusting the source for their circuit without having to dive into any dialogs.

[evanshultz]

This is exactly what you get when placing symbols from the latest commit:

[fauxpark]

@evanshultz just a small thing, since SPICE is an acronym it should be capitalised in the library name :)

[evanshultz]

@fauxpark
Yep, you are right. Thanks for catching that. Fixed now.

[poeschlr]

Thanks for your work. This will make simulation much easier for our users.