kicad-developers team mailing list archive

[Thomas Pointhuber <thomas.pointhuber@xxxxxx>]

Hi Carsten,

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.

Regards,
Thomas

Am 02.01.19 um 11:05 schrieb Carsten Schoenert:
> Hello Thomas,
> 
> 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.
>

Attachment: signature.asc
Description: OpenPGP digital signature