kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

I am coming late in the discussion as I didn’t see the point at first.
Having delt with the professional Electronic Engineering world for the past 40 years, I heard
many sides of the same story.
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.

One easy way to interface is to provide a new field in the Part Library that could be named
“Spice_Name”, and would be part of the nettles export.
That way, everybody would be happy as the link to the spice library would be there for the 
people who needs it.

That would provide a one-to-one relationship between a part (Part Number) and a Spice symbol
(Spice_Name) for the Spice library.

I do that in my own KiCAD library by using a custom field named “Spice_Name” as I use LTSpice
and Tina TI since I left the for profit world.

my $0.02,
Jean-Paul
AC9GH


> On Nov 11, 2015, at 10:39 AM, jp charras <jp.charras@xxxxxxxxxx> wrote:
> 
> Le 11/11/2015 14:35, xarx@xxxxxx a écrit :
>> Sorry, Jean-Pierre, but your answer is too vague for me. I'm just a EE
>> hobbyist, so I'm surely less experienced than you EE professionals. But at the
>> level I want to use KiCad, I don't think your  points are valid. See my
>> comments below.
> 
> First of all, a change in Kicad is not made just for you.
> 
>> 
>>> 
>>> 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.
>> 
>> I'm not saying it's easy. User friendly Spice support would mean a lot of work
>> (considering the current state). But as a first step, you have to be
>> determined that you want it, which you nor Wayne currently seem to be.
>> 
>> What in particular do you have in mind of what Wayne said?
> 
> The 3 points in his last mail:
> 1) Create a custom spice library with the appropriate symbols
> especially:
> 2) Do not attempt to convert schematic values to spice values
> which does not work in many cases: what about 1M-5% or 1n/50V.
> 3) Rather than use a specific field like "Spice_Node_Sequence" to set a
> single spice parameter, use a generic field name like "spice" with
> key/value pairs
> 
> Remember:
> The previous change "which worked like a charm" (the
> Spice_Node_Sequence) was not well designed, and now must be replaced by
> other changes.
> 
>> 
>>> 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.
>> 
>> Again, what problem in particular do you mean? I don't see any. Simply, you
>> would need to have a Spice sub-circuit in order to be able to simulate such a
>> component.
>> 
>>> * 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.
>> 
>> Again, you need to have a prepared Spice sub-circuit for that. If you need
>> parametrisation, that sub-circuit could be generated dynamically. Where's a
>> problem?
>> 
>>> * you also need to include simulation files info for complex components
>>> (obviously op amps)
>> 
>> Yes, of course. No problem.
>> 
>>> * you also need to include many other info (I and V generators, probes ...)
>> 
>> Not exactly. When you run LTSpiceIV on a netlist, you can perform simulations
>> even without probes.
> 
> Yes, but probes are easy to use and very common in asimulation work flow.
> 
>> Concerning the current and voltage sources, in many cases they can be
>> generated dynamically based on power connectors used in the circuit. They
>> don't need be a part of the circuit. I'm doing that like this now. In the rest
>> of cases, there can be presented a dialogue that can help to determine
>> parameters e.g. of an input signal.
>> 
>>> 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.
>> 
>> Yes, you can redraw the simulated part of the schema into LTSpice, but why do
>> you do that? I assume that's only because you cannot use KiCad for that.
> 
> No. I used LTSpice to simulate and test only small parts of a large
> designs: a filter, or the first stage of low noise amplifiers.
> 
> Most of time I had to redraw (on LTSpice) an equivalent schematic,
> mainly because the actual schematic (made with Eeschema) was no usable
> (many specific components, for instance digital potentiometers) or
> because I had to simulate only a small part of a large schematic.
> 
>> 
>>> 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
>> 
>> Do you want me to do that, or was that just a rhetoric remark?
> 
> If "that" is a basic list, yes I am asking you to do "that" before
> writing a new code for Kicad
> 
> If "that" is about the schematic files, redesign of the schematic files
> format is on the top of Wayne's todo list
> A lot of work was already done about this topic.
> 
>> 
>>> 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.
>> 
>> The same problem you have e.g. in any programming language where the used
>> libraries may be missing at the target location. For instance Eclipse IDE for
>> Java handles this problem in a very elegant way - it just copies the code
>> including the library imports.
> 
> It is not applicable to a schematic.
> And Eclipse does not manage component references ans subparts.
> 
>> 
>>> 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?
>> 
>> What do you mean by the simulation info? Do you mean the graphs?
> 
> Mainly, yes.
> 
> I use LTSpice
>> or NgSpice for displaying that.
>> 
>> Best regards,
>>         Martin.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> _______________________________________________
> 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