kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I have no intention of embedding spice models in KiCad symbol files.
The current method of assigning spice information to symbols using
fields works very well so I don't see any reason to change it.

Cheers,

Wayne

On 1/2/2019 5:32 AM, kristoffer Ödmark wrote:
> 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.
> 
> - Kristoffer
> 
> On 2019-01-02 11:27, Thomas Pointhuber wrote:
>> 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.
>>>
>>
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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