kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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