kicad-developers team mailing list archive
Mailing list archive
Re: [RFC] Symbol library file format
I agree with Carsten Here,
The same way the footprints are not part of the symbol, the same way
SPICE models should be defined separate.
I would rather have a new atomic file-format or storage format, so one
could actually send a complete part in an easy way, that would include
3D-Files, SPICE data, symbol and footprints, and it would also mean that
one could do the mapping to pins in that directory or file instead.
And since the discussion about adding a manufacturer part number to
libraries went nowhere, I cannot see how adding a SPICE model would fit
here, and if SPICE models are added. Well then I suggest we add 3D-Files
and Footprints as well, no use in half-assing it.
On 2019-01-02 11:27, Thomas Pointhuber wrote:
Unfortunate, I don't think the reality works like that. While my
experience with SPICE is quite sparse (especially inside KiCad), I do
NOT think in this case about open and free spice model for IC's. Not
everyone uses the KiCad supplied libraries but their own, and simple
spice stuff like putting some resistors together for an R-Network can be
done in the official as well.
Fully separate spice out of the symbol would not work anyway because
from what I noticed spice pin does not map to symbol pin in many cases.
You need to link that somewhere anyway. I'm heavily in favor of
simplifying handling of simulation for users. Integrating this into one
file would be less error-prone than separating simulation into multiple
additional files. Including external SPICE models would then be an
option, but not necessary.
A modular approach where SPICE is only one of many possibilities is in
my favor, but in a different way than you proposed (integrated in the
symbol). There is for example the topic of digital simulation, which
would require different types of models. We should at least think about
it so it can be integrated later in a nice way.
Am 02.01.19 um 11:05 schrieb Carsten Schoenert:
Am 02.01.19 um 10:39 schrieb Thomas Pointhuber:
* I do not see anything related to SPICE in this document. I would vote
to add it including the possibility to embedded spice models
(BASE64-encoded) into the symbol itself.
I disagree on that.
Please do not mix two different main purposes and add more complexity.
Schematic simulation is a add-on, not a primary key feature of a symbol
format or within Eeeschema.
Including such stuff into a schematic symbol make it harder to maintain
the symbols in along term as you always need to touch the symbol no
matter what peace need a update. But the (new extended) symbol format
can get of course a new field of course for a referenced file to look
at. Like similar done for associated footprints. Add a new environment
variable like SPICE_MODEL_DIR to add a default folder.
Currently it's not clear how a open and free spice working model can
look like, I really suggest to not create a own world for spice models.
Make it modular so work needs to be done more than needed.
I also suggest to get in touch with Holger from the ngspice project
about his thoughts and possible suggestions on this topic.
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp