Re: [Kicad-developers] SPICE models and library symbols

[Maciej Sumiński]

Hi Nhat,

There are fields dedicated to Spice model definitions, try to set a
model with the Spice Model editor dialog (in the Component Properties
dialog [1]) and notice that new fields will appear.

Cheers,
Orson

1. http://docs.kicad-pcb.org/5.0.0/en/eeschema.html#_assigning_models

On 08/13/2018 10:31 PM, Nhat Khai wrote:
> Sorry to a long email and my english. But here is my though. I can be
> wrong, so please don't be angry.
> Here is my case of use:
>   I have a lot of SUBCKT models (100+), and modified/customized SUBCKT
> models with parameters. In KiCad4, I using the default value of
> symbol/component to refer to default model. Later on in project, I can
> change that value point to my own SUBCKT model with some parameter
> specified for special case of simulation. It doable in KiCad4, but text in
> component's value some time look long and ugly. So it would be nice to have
> keep it compatible and following:
>   a. KiCad understand SUBCKT parameter and allow user to set these values
> -- Give KiCad a gateway to support ~90% of most simulation needed without
> understand resistor, voltage, current model ... etc.
>   b. KiCad give user option to stick with value (backward compatible) or
> use alternative field (one or more) for specifications the spice model.
>   c. These alternative field can be hide or visible just like any other
> normal field.
>   d. Using fields, all the model parameters can be just be export as BOM.
> Allow user to ensure they don't make mistake. Great visibility over 100+
> model all at one.
>   e. The .cir file allow user option to how to managing their spice library
> that fit there own workflow. (Using normal editor, look at 100+ model all
> at one in one file, source control in the spice language, no need to learn
> another KiCad language to look at the git diff,...etc).
> 
> I think, embedding spice model into symbol is nice but is have issues:
> 1. Visibility of the model is hard to access (one by one). It is trouble
> some to verify 100 spice model all at once.
> 2. User tent to not trust spice model where I don't know about it, or where
> it comes from. (they will refer to download directly form manufacture, or
> their customized version.
> 
> Also, embedding spice model into the component is nice in eeschema, but is
> have similar issue:
> 1. Visibility of the model have is one by one.
> 2. Here is one of my resistor value for simulation: "{2k*0.9026} tc1=4.21m
> tc2=4.427u dtemp=27". Current KiCad5 don't understand this. However, I
> don't expect it understand it like KiCad4 did. But if it understand the
> simple SUBCKT then I can use it and pass in parameters, and help it more
> readable, and my life easier :-).
> 
> KiCad simulation seem to missing a generic mode for the unexpected
> simulation types. Which again, in my case is temperature sweep or can be
> multi-parameter sweeps. It think the effort to have it recognize are
> beautiful. But generic simulation should be the most importance one to
> cover first. Meaning, it don't event need to understand the simulation type
> and still able to plot the result. My case, I use spice directive to
> specify my unusual simulation, and no matter how I specify it, current
> simulation tool should able to plot result after simulation finished (is
> the best I can dream of). Current it is not, if it don't understand what
> type of simulation I'm doing (witch again I think it don't have to).
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Nhat Khai]

Sorry to a long email and my english. But here is my though. I can be
wrong, so please don't be angry.
Here is my case of use:
  I have a lot of SUBCKT models (100+), and modified/customized SUBCKT
models with parameters. In KiCad4, I using the default value of
symbol/component to refer to default model. Later on in project, I can
change that value point to my own SUBCKT model with some parameter
specified for special case of simulation. It doable in KiCad4, but text in
component's value some time look long and ugly. So it would be nice to have
keep it compatible and following:
  a. KiCad understand SUBCKT parameter and allow user to set these values
-- Give KiCad a gateway to support ~90% of most simulation needed without
understand resistor, voltage, current model ... etc.
  b. KiCad give user option to stick with value (backward compatible) or
use alternative field (one or more) for specifications the spice model.
  c. These alternative field can be hide or visible just like any other
normal field.
  d. Using fields, all the model parameters can be just be export as BOM.
Allow user to ensure they don't make mistake. Great visibility over 100+
model all at one.
  e. The .cir file allow user option to how to managing their spice library
that fit there own workflow. (Using normal editor, look at 100+ model all
at one in one file, source control in the spice language, no need to learn
another KiCad language to look at the git diff,...etc).

I think, embedding spice model into symbol is nice but is have issues:
1. Visibility of the model is hard to access (one by one). It is trouble
some to verify 100 spice model all at once.
2. User tent to not trust spice model where I don't know about it, or where
it comes from. (they will refer to download directly form manufacture, or
their customized version.

Also, embedding spice model into the component is nice in eeschema, but is
have similar issue:
1. Visibility of the model have is one by one.
2. Here is one of my resistor value for simulation: "{2k*0.9026} tc1=4.21m
tc2=4.427u dtemp=27". Current KiCad5 don't understand this. However, I
don't expect it understand it like KiCad4 did. But if it understand the
simple SUBCKT then I can use it and pass in parameters, and help it more
readable, and my life easier :-).

KiCad simulation seem to missing a generic mode for the unexpected
simulation types. Which again, in my case is temperature sweep or can be
multi-parameter sweeps. It think the effort to have it recognize are
beautiful. But generic simulation should be the most importance one to
cover first. Meaning, it don't event need to understand the simulation type
and still able to plot the result. My case, I use spice directive to
specify my unusual simulation, and no matter how I specify it, current
simulation tool should able to plot result after simulation finished (is
the best I can dream of). Current it is not, if it don't understand what
type of simulation I'm doing (witch again I think it don't have to).
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Andy Peters]

> On Aug 13, 2018, at 9:59 AM, Nhat Khai  wrote:
> 
> I may be wrong, but I feel embedded spice model with symbol library or .sch 
> file may be a wrong way. Instead treat spice model like footprint (using 
> spice syntax .cir file directly event better) to allow user directly modify 
> parameters passed into SUBCKT from GUI dialog like current Simulation GUI 
> right now. But if it done it right, I think it give user much more 
> flexibility, and more dynamic spice dialog that can covert all type of model 
> without adding more coding for KiCad. For example, read the "SUBCKT", and 
> allow user to change the value of parameters passed in of SUBCKT.


“Treat spice model like footprint.”

And that’s why the model callout _should_ be embedded in the library symbol.

If I place OPA1652AID onto my schematic, I want it to pull in the SOIC-8 
footprint. CvPCB is to be avoided. For the same reason, why should I need to 
specify the SPICE model after placing a generic op-amp symbol on the board, 
when I can place an OPA1652 symbol and have it already know what model to use?

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Nhat Khai]

I may be wrong, but I feel embedded spice model with symbol library or .sch
file may be a wrong way. Instead treat spice model like footprint (using
spice syntax .cir file directly event better) to allow user directly modify
parameters passed into SUBCKT from GUI dialog like current Simulation GUI
right now. But if it done it right, I think it give user much more
flexibility, and more dynamic spice dialog that can covert all type of
model without adding more coding for KiCad. For example, read the "SUBCKT",
and allow user to change the value of parameters passed in of SUBCKT.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Jeff Young]

Hmm, yeah, good point.  I think I’ll leave it out for now.

> On 13 Aug 2018, at 17:28, Wayne Stambaugh  wrote:
> 
> On 8/13/2018 12:19 PM, Jeff Young wrote:
>> Hi JP,
>> 
>> Some of those user-model issues regarding aliases & fields are exactly what 
>> I was trying to address.
>> 
>> From a user’s perspective, aliases *sort of* have two fields: value(name) 
>> and datasheet.  When they place an alias in a schematic, those two fields 
>> are (or at least can be) different than when placing the root.  For this 
>> reason the new UI shows those two fields as “Alias field substitutions”.
>> 
>> But more importantly the new UI removes the very indistinct idea of an alias 
>> being “selected” (while the alias dropdown allows the 3 fields to be edited 
>> in the Description tab of the Symbol Properties, all the other tabs, the 
>> Symbol Fields dialog and the canvas still show the root.
>> 
>> So the alias dropdown is gone.  Instead we show the alias list and the alias 
>> properties/field substitutions on a single page in the Symbol Properties 
>> dialog.  This makes it much more clear that they’re editing the root, but 
>> that they can set these specific properties per alias.
>> 
>> Cheers,
>> Jeff.
> 
> You may be correct about your changes being less confusing but I would
> be willing to bet that some users will get tripped up by the fact the
> spice mode field exists only in the root symbol and not any of the
> aliases.  The new symbol file format will address this issue so it may
> make sense to wait until I get it implemented before making this change.
> 
> Wayne
> 
>> 
>> 
>>> On 13 Aug 2018, at 15:27, jp charras  wrote:
>>> 
>>> Le 13/08/2018 à 15:40, Jeff Young a écrit :
 Cool.  I’ll go ahead and add it for now; it’s only a few lines so it’s
 easy enough to remove if we change our minds.
 
 (Screenshots attached to show the new alias handling, which attempts to
 not show as much of the internal implementation.)
 
 Cheers,
 Jeff.
 
>>> 
>>> I am not sure to understand what you mean by:
>>> "in LibEdit I noticed there’s no Edit Spice Model… button."
>>> In Libedit, it is in Symbol Field dialog.
>>> 
>>> Just keep in mind all fields are fields of the root symbol, and aliases
>>> share these fields, but cannot have specific fields.
>>> 
>>> Only 3 specific strings are related to a given alias:
>>> Description
>>> Keywords
>>> Documentation.
>>> 
>>> So, If you change the symbol settings dialog, try to make very clear the
>>> fact aliases do not have specific fields.
>>> 
 
 
 
 
 
> On 13 Aug 2018, at 13:26, Wayne Stambaugh  > wrote:
> 
> Spice models are a specific type of optional field where in the past the
> symbol library editor has only supported generic optional field editing.
> I'm not sure if spice model field editing needs to be part of the
> symbol library editor but I don't see any harm in it either.
> 
> Cheers,
> 
> Wayne
> 
> On 8/13/2018 7:31 AM, Jeff Young wrote:
>> While overhauling the Symbol Properties dialog for LibEdit I noticed
>> that there’s no Edit Spice Model… button.
>> 
>> There’s no reason to exclude it, is there?  I assume I should go
>> ahead and add one?
>> 
>> Thanks,
>> Jeff.
 
>>> 
>>> 
>>> -- 
>>> Jean-Pierre CHARRAS
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Wayne Stambaugh]

On 8/13/2018 12:19 PM, Jeff Young wrote:
> Hi JP,
> 
> Some of those user-model issues regarding aliases & fields are exactly what I 
> was trying to address.
> 
> From a user’s perspective, aliases *sort of* have two fields: value(name) and 
> datasheet.  When they place an alias in a schematic, those two fields are (or 
> at least can be) different than when placing the root.  For this reason the 
> new UI shows those two fields as “Alias field substitutions”.
> 
> But more importantly the new UI removes the very indistinct idea of an alias 
> being “selected” (while the alias dropdown allows the 3 fields to be edited 
> in the Description tab of the Symbol Properties, all the other tabs, the 
> Symbol Fields dialog and the canvas still show the root.
> 
> So the alias dropdown is gone.  Instead we show the alias list and the alias 
> properties/field substitutions on a single page in the Symbol Properties 
> dialog.  This makes it much more clear that they’re editing the root, but 
> that they can set these specific properties per alias.
> 
> Cheers,
> Jeff.

You may be correct about your changes being less confusing but I would
be willing to bet that some users will get tripped up by the fact the
spice mode field exists only in the root symbol and not any of the
aliases.  The new symbol file format will address this issue so it may
make sense to wait until I get it implemented before making this change.

Wayne

> 
> 
>> On 13 Aug 2018, at 15:27, jp charras  wrote:
>>
>> Le 13/08/2018 à 15:40, Jeff Young a écrit :
>>> Cool.  I’ll go ahead and add it for now; it’s only a few lines so it’s
>>> easy enough to remove if we change our minds.
>>>
>>> (Screenshots attached to show the new alias handling, which attempts to
>>> not show as much of the internal implementation.)
>>>
>>> Cheers,
>>> Jeff.
>>>
>>
>> I am not sure to understand what you mean by:
>> "in LibEdit I noticed there’s no Edit Spice Model… button."
>> In Libedit, it is in Symbol Field dialog.
>>
>> Just keep in mind all fields are fields of the root symbol, and aliases
>> share these fields, but cannot have specific fields.
>>
>> Only 3 specific strings are related to a given alias:
>> Description
>> Keywords
>> Documentation.
>>
>> So, If you change the symbol settings dialog, try to make very clear the
>> fact aliases do not have specific fields.
>>
>>>
>>>
>>>
>>>
>>>
 On 13 Aug 2018, at 13:26, Wayne Stambaugh >>> > wrote:

 Spice models are a specific type of optional field where in the past the
 symbol library editor has only supported generic optional field editing.
 I'm not sure if spice model field editing needs to be part of the
 symbol library editor but I don't see any harm in it either.

 Cheers,

 Wayne

 On 8/13/2018 7:31 AM, Jeff Young wrote:
> While overhauling the Symbol Properties dialog for LibEdit I noticed
> that there’s no Edit Spice Model… button.
>
> There’s no reason to exclude it, is there?  I assume I should go
> ahead and add one?
>
> Thanks,
> Jeff.
>>>
>>
>>
>> -- 
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Jeff Young]

Hi JP,

Some of those user-model issues regarding aliases & fields are exactly what I 
was trying to address.

From a user’s perspective, aliases *sort of* have two fields: value(name) and 
datasheet.  When they place an alias in a schematic, those two fields are (or 
at least can be) different than when placing the root.  For this reason the new 
UI shows those two fields as “Alias field substitutions”.

But more importantly the new UI removes the very indistinct idea of an alias 
being “selected” (while the alias dropdown allows the 3 fields to be edited in 
the Description tab of the Symbol Properties, all the other tabs, the Symbol 
Fields dialog and the canvas still show the root.

So the alias dropdown is gone.  Instead we show the alias list and the alias 
properties/field substitutions on a single page in the Symbol Properties 
dialog.  This makes it much more clear that they’re editing the root, but that 
they can set these specific properties per alias.

Cheers,
Jeff.


> On 13 Aug 2018, at 15:27, jp charras  wrote:
> 
> Le 13/08/2018 à 15:40, Jeff Young a écrit :
>> Cool.  I’ll go ahead and add it for now; it’s only a few lines so it’s
>> easy enough to remove if we change our minds.
>> 
>> (Screenshots attached to show the new alias handling, which attempts to
>> not show as much of the internal implementation.)
>> 
>> Cheers,
>> Jeff.
>> 
> 
> I am not sure to understand what you mean by:
> "in LibEdit I noticed there’s no Edit Spice Model… button."
> In Libedit, it is in Symbol Field dialog.
> 
> Just keep in mind all fields are fields of the root symbol, and aliases
> share these fields, but cannot have specific fields.
> 
> Only 3 specific strings are related to a given alias:
> Description
> Keywords
> Documentation.
> 
> So, If you change the symbol settings dialog, try to make very clear the
> fact aliases do not have specific fields.
> 
>> 
>> 
>> 
>> 
>> 
>>> On 13 Aug 2018, at 13:26, Wayne Stambaugh >> > wrote:
>>> 
>>> Spice models are a specific type of optional field where in the past the
>>> symbol library editor has only supported generic optional field editing.
>>> I'm not sure if spice model field editing needs to be part of the
>>> symbol library editor but I don't see any harm in it either.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 8/13/2018 7:31 AM, Jeff Young wrote:
 While overhauling the Symbol Properties dialog for LibEdit I noticed
 that there’s no Edit Spice Model… button.
 
 There’s no reason to exclude it, is there?  I assume I should go
 ahead and add one?
 
 Thanks,
 Jeff.
>> 
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[jp charras]

Le 13/08/2018 à 15:40, Jeff Young a écrit :
> Cool.  I’ll go ahead and add it for now; it’s only a few lines so it’s
> easy enough to remove if we change our minds.
> 
> (Screenshots attached to show the new alias handling, which attempts to
> not show as much of the internal implementation.)
> 
> Cheers,
> Jeff.
> 

I am not sure to understand what you mean by:
"in LibEdit I noticed there’s no Edit Spice Model… button."
In Libedit, it is in Symbol Field dialog.

Just keep in mind all fields are fields of the root symbol, and aliases
share these fields, but cannot have specific fields.

Only 3 specific strings are related to a given alias:
Description
Keywords
Documentation.

So, If you change the symbol settings dialog, try to make very clear the
fact aliases do not have specific fields.

> 
> 
> 
> 
> 
>> On 13 Aug 2018, at 13:26, Wayne Stambaugh > > wrote:
>>
>> Spice models are a specific type of optional field where in the past the
>> symbol library editor has only supported generic optional field editing.
>> I'm not sure if spice model field editing needs to be part of the
>> symbol library editor but I don't see any harm in it either.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 8/13/2018 7:31 AM, Jeff Young wrote:
>>> While overhauling the Symbol Properties dialog for LibEdit I noticed
>>> that there’s no Edit Spice Model… button.
>>>
>>> There’s no reason to exclude it, is there?  I assume I should go
>>> ahead and add one?
>>>
>>> Thanks,
>>> Jeff.
>


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SPICE models and library symbols

[Wayne Stambaugh]

Spice models are a specific type of optional field where in the past the
symbol library editor has only supported generic optional field editing.
 I'm not sure if spice model field editing needs to be part of the
symbol library editor but I don't see any harm in it either.

Cheers,

Wayne

On 8/13/2018 7:31 AM, Jeff Young wrote:
> While overhauling the Symbol Properties dialog for LibEdit I noticed that 
> there’s no Edit Spice Model… button.
> 
> There’s no reason to exclude it, is there?  I assume I should go ahead and 
> add one?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] SPICE models and library symbols

[Jeff Young]

While overhauling the Symbol Properties dialog for LibEdit I noticed that 
there’s no Edit Spice Model… button.

There’s no reason to exclude it, is there?  I assume I should go ahead and add 
one?

Thanks,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp