kicad-developers team mailing list archive

[<xarx@xxxxxx>]

Thank you, Wayne, for your long answer, I'm completely satisfied with it.
Nevertheless, I'd like to have a few more questions.

> We hope some day that we can support simulation directly. For the time
> being, we can do our best to support exporting spice netlists for
> simulation in external tools.

Does that mean that you plan to develop your own simulation engine?

>
http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_road-map.html#simulation

Or to develop your own front-end for an existing simulation engine?
And do you plan to perform that as a big bang, or by an incremental evolution?

Given the size of KiCad, the number of developers that are actively developing
it (not counting the bug-fixers), and the number of tasks in your road-map, it
may happen easily that the simulation support will be prepared not earlier
than in five years. In this case, wouldn't it be better to start with a basic
simulation support and then to incrementally improve it, instead? Even when
that would mean that a backward incompatibility would have to be introduced at
some point?

> I'm not sure what you mean by better.  If you have something better in
> mind than my suggestions, let us know what that is.  Your original
> proposal was not a workable solution in the long term.  My counter
> proposal is a more maintainable solution that doesn't violate our policy
> of generic symbol libraries.  It is more work up front but in the long
> run it is a better solution until the new schematic file format is
> implemented.  At that time, we can discuss a more complete solution for
> support for simulations in symbol libraries.

I have no problem with your suggested solution - in comparison to my patch.
But to me, this still feels like a replacement of an old hack with a new one
(mine or yours), even though the new hack solves "my immediate problems" (as
JP calls it :-) ). In order it ceased to be a mere hack, it would have to be
integrated with the rest of the KiCad application. And this is what I meant by
"something better". In particular, this must include also official modified
libraries, but that's surely still not enough.

> You made no counter argument.  You merely tried to convince me
> that your original patch was the way to go. 

Nope :-). That was probably a misunderstanding.

> If you have something different in mind above and beyond
> my recommendations to your original patch, then
> let us know what you are proposing.

I'd like to have a usable support for simulations in KiCad in a SHORT future,
and not have to wait for several years in order to get it. On the other hand,
I would be completely satisfied with using e.g. LTSpice for that (yes, even
without the probes), I feel no need in having to wait for KiCad's own
front-end for that. (Of course, these are my preferences, other people -
especially those focused on PCB creation - may have different priorities.) So
I would appreciate a simple (but complete) implementation at first, and only
then to gradually improve it. If these are also your plans, the better. But
some of the points in the road-map suggest that they're not.

In my opinion, a solution similar to how eSim does that, would be completely
sufficient for start. As I've already mentioned for several times, that's not
much code, so it could be implemented relatively quickly. (But using eSim for
that is not a solution, because eSim cannot fulfil the task without changes in
KiCad itself. And especially it cannot provide standardisation.) 

A bunch of other suggestions, some of which I've already mentioned in my
previous e-mails:

* The libraries should be "agnostic". (Creation of separate libraries for
simulations is actually one of the points in your "simulations" road-map that
I don't like.) Including usage of the same component libraries both for PCB
and simulations, and including usage of the same value and naming conventions.
The specifics that would allow a library to be used for simulations should be
hidden.

* Models or sub-circuits could be generated dynamically for some schema
components. That concerns e.g. current/voltage sources, but also e.g.
transformers and other similar complex components. However, this would require
a tight coupling between the component definitions and the netlist generators.
So another reason for changing the libraries together with the changes in the
code.

* There's no need for having to explicitly place voltage sources into the
schema for the purposes of simulations, the way how LTSpice or eSim do that.
If the netlist generator sees e.g. a "+12V" connector/net, it could generate
the 12V voltage source for that automatically.

* The reason why I don't like neither of the three patches (the old
one/mine/yours) is that they specify only a few of the attributes needed for
simulations. For example such components like a transformer would need other
attributes defined as well, at the library level. Also, I think that it would
be much better to specify Spice attributes in a section similar to $FPLIST,
because there's no reason why attributes like "pin order" or "reference
prefix" should be editable by a user.

* I've also mentioned that the inability of KiCad to copy a part of a schema
into another schema for simulation purposes is rather limiting.

* And surely, it would help if there could be several schemas in the project,
not just one. Still a single PCB, but several simulations of various parts of
the circuit.

* etc.

It seems to me that some of my proposals are not in a complete alignment with
your simulations road-map. Your road-map looks to me fit for a maximalistic
solution, but I'd prefer starting with a minimalistic one.

         Martin.


----- Původní zpráva -----
Odesílatel: Wayne Stambaugh <stambaughw@xxxxxxxxx>
Příjemce: kicad-developers@xxxxxxxxxxxxxxxxxxx
Datum: Fri, 13 Nov 2015 15:49:53 -0500
Předmět: Re: [Kicad-developers] Bug #1511552 - export of Spice net-list from
EESchema


> On 11/12/2015 11:31 AM, xarx@xxxxxx wrote:
> > First of all, sorry for my late answer, and that I'm going to put all my
> > answers into a sigle e-mail. Because the public mail service I'm using had
a
> > breakdown, was unavailable for the whole day, and the latest messages were
> > lost.
> > 
> >> I agree with Wayne and JP, KiCAD is not designed to be a simulator, but
> > could be a nice
> >> interface to the few good Existing Spice Simulators (LTspice and Tina TI
> > come to mind for
> >> stand-alone products) while expensive commercial ECAD products have their
> > own
> >> simulation tools.
> > 
> > Exactly. KiCad is not a simulator, but it could be used as a "nice
interface"
> > for one.
> 
> We hope some day that we can support simulation directly.  For the time
> being, we can do our best to support exporting spice netlists for
> simulation in external tools.
> 
> > 
> >> If you are not interested in making these changes, just say so and that's
> >> the end of it.
> > 
> > If we won't be able to agree on anything better, I'll do that the way you
> > suggest it. I thought that was clear, so I'm surprised that you're still
> > bringing this topic back.
> 
> I'm not sure what you mean by better.  If you have something better in
> mind than my suggestions, let us know what that is.  Your original
> proposal was not a workable solution in the long term.  My counter
> proposal is a more maintainable solution that doesn't violate our policy
> of generic symbol libraries.  It is more work up front but in the long
> run it is a better solution until the new schematic file format is
> implemented.  At that time, we can discuss a more complete solution for
> support for simulations in symbol libraries.
> 
> > Nevertheless, I'd like to have a full-featured AND officially supported
KiCad
> > integration with Spice or other good simulation software. This was also
> > suggested a few days ago by someone else in another thread.
> 
> KiCad would be more than happy to have official support for simulation.
>  It's been discussed many times before.  Irregardless of what level of
> support we provide, my expectation is that it will be well designed and
> maintainable.  This means that the low level code should be flexible
> enough to handle any simulation we desire.  I will not accept a bunch of
> unrelated hacks just to support simulation.  This takes a lot of careful
> planning and good design practices to implement properly.  I will also
> expect a high level of stability before I allow any simulation code in
> the KiCad code base.
> 
> > But you (and JP) are repeating that that's an utopia, that's too much
> > maintenance, that everyone does it his own way anyway etc. And if I try to
> > suggest something, or present a counter-argument, then you answer with
that
> > you are the project leader. 
> 
> You made no counter argument.  You merely tried to convince me that your
> original patch was the way to go.  If you have something different in
> mind above and beyond my recommendations to your original patch, then
> let us know what you are proposing.  I just gave you the minimum
> requirements that I will accept before I commit your patch.  That does
> not mean that KiCad is not interested in providing simulation nor should
> you interpret it as such.
> 
> > Well, you are. That's why I asked you to present your plans concerning
KiCad
> > and Spice (or any other simulation software) integration. 
> > 
> >>> 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.
> > 
> > Can you - please - explain what lever of integration is acceptable for
you,
> > whether you have any prepared plans and what they are, whether any work or
> > analysis has been done already, what is the expected time-frame etc.? And
if
> > your plans cover nothing more than the suggested "spice" user field, can
you
> > present some arguments why don't you want a better integration? If this
> > information is already available somewhere, could you please point me
there
> so
> > that you don't need to repeat it and I can read it?
> 
> There is no unacceptable level of simulation integration for the project
> that can think of.  Only unacceptable implementations of said simulation
> integration.  We have an initial circuit simulation section in the KiCad
> road map[1].  If want to change or add more detail to this road map,
> propose any changes for discussion and once we have a consensus, I will
> update it and add it to the next development cycle road map.
> 
>
[1]:http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_road-map.html#simulation
> 
> > 
> > I'm not going to comment on the rest of the e-mails.
> > 
> > Thank you,
> >            Martin.
> > 
> > ______________________________________________________________________
> > Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz,
> @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz
> > COMDOM Antispam - www.comdomsoft.com
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> 
> 


--  
 
______________________________________________________________________
Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz
COMDOM Antispam - www.comdomsoft.com