kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 11/11/2015 11:26, xarx@xxxxxx a écrit :
>>> Hopefully, if Mark Roszko implements
>>> a general netlist generator he announced, the problem might
>>> get resolved.
>>
>> I don't think Mark's changes help in this situation.  Plugin or no
>> plugin, you still need a way to export spice netlists.
> 
> I meant this post: https://lists.launchpad.net/kicad-developers/msg21148.html
> If I understand him correctly, Mark wants to replace the current netlist and
> BOM generators with plugins coded in scripting languages. In that case I could
> create my own plugin and generate netlists my way.
> 
>> As long as it's an option in the spice field, I'm fine with that.  I
>> don't want it performing this translation by default. 
> 
> My patch has an option in the netlist dialogue. So it's not a property of
> component definitions.
> 
>>  I just looked at the Eeschema documentation and none of this is documented
> ...
>> please consider
>> updating the eeschema documentation so that users will know how to
>> define a spice field and what the options will allow them to do.
>> Otherwise, the only people who will know this even exists are you and
>> the few folks who followed this thread.
> 
> I agree that everything like this should be documented in the eeschema
> documentation. But actually, the user fields are not (and haven't been)
> completely undocumented. When you open the generated netlist, you'll see the
> documentation there.
> 
> 
> Anyway, it seems to me that your position is that KiCad should be for PCB
> creation only. If anyone wants to use KiCad for circuit simulation, that's his
> own fight, and you're not going to provide support in KiCad for this, Though
> you are able to tolerate some, like the "spice" user field we were talking
> about. I don't mean it as an attack against you, but it would be fine to
> clarify your position about this. Can you confirm that or explain your view of
> possible KiCad - Spice integration? Because every other your answer in this
> area depends on your general view of this integration. (When answering, please
> completely ignore my particular patch, for the moment.)
> 
> If I'm right, that would explain:
> * why you are so strongly against any modification in standard libraries
> (changes that are not connected to PCB)
> * why you prefer that people used their own libraries for simulations (the
> KiCad ones being reserved for PCB creation only)
> * why you prefer that people used separate libraries for simulations and PCB
> creation (currently there's no other option, so they have no choice)
> * why there's no standard way in KiCad for integration with Spice (and
> everyone does that his own way; that's why you may be right when saying "You
> may be the first person
> other then the dev(s) that committed these changes to even use this.")
> * why there is still space for eSim (though it adds so little value)
> 
> Again, please do not take that personally. But I feel that further discussion
> would lead nowhere until you clarify your general position.
> 
> To be constructive, my idea is different (than that I've described above). I'd
> like:
> * to have "agnostic" component libraries that  could be used both for PCB
> creation and simulations
> * to have the integration between KiCad and Spice standardised at the KiCad
> level (so that new KiCad users can start simulations immediately, without a
> need to prepare their own libraries and post-processing scripts)
> 
> I imagine that when one is creating an el. schema, he can copy a part of it,
> simulate it, correct it and copy it back. (The functionality that allows to
> copy a selection in a schema and paste it elsewhere is missing in KiCad, yet.)
> That would allow KiCad to be used during the whole circuit life-cycle, without
> a need to switch to another application.
> 
> Thanks,
>         Martin.
> 

Again, we are thinking a good and strong support for simulation in
Eeschema is a good thing.

I 100% agree with Wayne said about changes in Eeschema relative to spice
support.
Spice support is also not an easy task.

Here are a few responses to your proposals (at least here is my opinion):

* Having "agnostic" component libraries that could be used both for PCB
creation and simulations is an utopia (excepted for basic cases).
For instance when you are using diodes like BAV99 (or any diode array)
or transistors like IRF7606PBF (and any transistor array), and more
generally speaking any multi-part per package components.

* Having the integration between KiCad and Spice standardized at the
KiCad level (so that new KiCad users can start simulations immediately,
without a need to prepare their own libraries and post-processing
scripts) is also (excepted for basic cases) an utopia ( considering the
words "without a need" ) : Using spice for simulations needs a good
knowledge of psice:
Just think about to simulate a transformer, or 2 coupled inductors.

* you also need to include simulation files info for complex components
(obviously op amps)

* you also need to include many other info (I and V generators, probes ...)

I certainly forgot many other reasons, but I am not a spice specialist.
Each time I had a sub schematic to simulate, I used LTspice, which works
fine, and does very well what it is designed to do.

First of all, you should write a list of all spice info which is needed
for spice simulation support (at least a minimal list of features)
Because the schematic files format should be redesigned, this is important


FYI, copying a selection in a schema and paste it elsewhere is an
especially tricky feature: just think about libraries which can differ
between 2 schematic projects, and the reference (designator) management,
especially with multi-part per package components.

A schematic editor is not a word processing editor.

Besides, running spice on a schematic is just a step.
How do you display the simulation info?

-- 
Jean-Pierre CHARRAS