kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 11/15/2015 5:02 AM, xarx@xxxxxx wrote:
> 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?

No!

> 
>>
> 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?

My preference would be to start by selecting the simulation tool that
makes the most sense. This selection should be based on the maturity,
stability, and the current development level of the simulation tool.
Whether it is ngspice, qucs, etc. doesn't matter to me personally.  I do
not want KiCad to be the test bed for someone's pet project.  Initially
we should choose the best tool and use that as a starting point.  I will
always lean towards an incremental implementation rather than a big bang
implementation.  I have stated this over and over again.  I would rather
have a single stable, bug free, well designed feature than 50 bug
ridden, unstable, poorly designed features.

> 
> 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?

Yes.  Even if initially this just means improved spice or some other
simulator netlist export.  However, that doesn't mean that initial
support cannot be designed with the future in mind.  A good example of
this would be rather than using file I/O directly, use an abstracter I/O
stream object such as our OUTPUT_FORMATTER and LINE_READER classes.

> 
>> 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.

The reason I suggested using key=value pairs in a single field is that
the new schematic file format will support PROPERTIES in a similar
fashion to the current board file format.  PROPERTIES are key=value
pairs to support adding information for external tools that are not
directly part of the file format.  This allows developers of external
tools to define properties for objects without having to continuously
change the format.  Once the new file format is implemented, it would be
easier to convert the key=value pairs to properties.

> 
>> 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.

I put together the simulation road map based on some of the original
discussions.  It is not set in stone and can be amended at any time.  It
has never been discussed in great detail because it's always been low on
the priority list of the current developers.  Honestly, we've never had
a developer interest in working on this so if you are up to the task and
willing to work with the dev team then you get determine it's priority.

> 
> 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.) 

I cannot comment on eSim.  I've never used it.

> 
> 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.

It's OK if you don't like it.  The decision to provide agnostic symbol
libraries was made a long time ago due to objections from both users and
developers.  The main argument for agnostic symbols was that no one
could agree on what we should provide which meant most users would have
to remove the stuff provided by KiCad and add their own fields which was
more work than just adding their own fields.

> 
> * 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.

This is limited to dc analysis.  What about ac sources for transient and
sweep analysis.  This would require a lot of additional symbols to
represent them.

> 
> * 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.

This is exactly why I want a separate symbol library for simulations.
Properly implemented, this library could support simulation and board
layout.  My guess is most board layout users will never use the
simulator so the spice field(s) would only complicate things.

> 
> * 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.

This is not exactly true.  However, the way to use is not very clear.
Run eeschema directly.  Open the schematic you want to copy from and use
the block copy function to save the block to the clipboard.  Open the
schematic you want to past into and click the paste button and the
contents of the clipboard will be pasted into the schematic.

> 
> * 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.

That would require a complete rewrite of the schematic editor to support
tagging symbols that would not be used when generating the netlist.  I'm
not sure I like that idea.  I would have to think about that one for a
while.

> 
> * 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.

Me too.  KiCad development is a marathon, not a sprint.  It's a series
of continuous improvements that add up over time.

> 
>          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
> 
> 
> 
> 
> 
> _______________________________________________
> 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
>