Hi!
This would also enable fully automated PDN analysis (e.g. a voltage regulator
could have property "V_OUT" with value "5.0" on the output pin. An IC connected
to this net would have the property "I_IN" with value "0.2" and property
"V_IN_MIN" with value "4.5". When PCB would be done then
On 04/01/19 15:10, Wayne Stambaugh wrote:
Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a
With the amount of data that KiCad handles performance of particular parser
has minuscule impact. File IO delays would thwart any processing time.
What Simon talked about is as he said a separate discussion and is
orthogonal to the decision of how to define data model and what file format
to use.
My ERC Proposal was more like a: we should at least think about it a bit
instead of writing the pin type near style and number/name. We can
specify ERC hints in a future-proof way without extending the current
implementation. Like:
(erc_hints (pin_type power_in))
This would allow us to specify
ot of this work is already done. This
is a discussion after v6.
Cheers,
Wayne
>
>
> From: Kicad-developers
> on behalf of
> Wayne Stambaugh
> Sent: 04 January 2019 14:03
> To: kicad-developers@lists.launchpad.net
> Subject:
On 1/3/19 11:24 PM, Simon Richter wrote:
> Hi,
>
> On 03.01.19 19:06, José Ignacio wrote:
>
>> I
>> think useful comments to the proposed format should see beyond the
>> actual low level representation of the data and talk about the overall
>> model being used to store it.
>
> tl;dr: That's a
Something else that i remembered now.
Would it be a good idea to prepare for alternative function handling for
pins?
Meaning an alternative pin name connected to an alternative type (or a
number of these)
That would allow better symbols for micro controllers.
I do not expect this to be
On 04/01/19 15:10, Wayne Stambaugh wrote:
Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a
Simon,
On 1/2/19 8:39 PM, Simon Richter wrote:
> Hi Wayne,
>
> On 02.01.19 23:20, Wayne Stambaugh wrote:
>
>>> This would be an artificial unit for the file format, not necessarily
>>> the true internal unit (which I want to unify across the entire program
>>> as soon as feasible, but that
I'm willing to add properties which are already defined to pins. There
has been talk about adding about adding electrical constraints for
advance ERC testing to symbols but that will not be part of the v6
implementation of the new file format. It's going to be a lot of work
to implement the
I'm willing to add properties which are already defined to pins. There
has been talk about adding about adding electrical constraints for
advance ERC testing to symbols but that will not be part of the v6
implementation of the new file format. It's going to be a lot of work
to implement the
of
Wayne Stambaugh
Sent: 04 January 2019 14:03
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] [RFC] Symbol library file format
On 1/2/2019 2:55 PM, Vesa Solonen wrote:
> kristoffer Ödmark kirjoitti 2.1.2019 klo 12.32:
>
>> I would rather have a new atomic file-format
Yes you are right Wayne,
Its just that i believe an IDF like protobuf would ease the development
of such a feature/file-format, the tools around such a feature and allow
for a better overall iteration of such a feature/fileformat.
That is why i even mentioned it here, because since we are
Hi Kristoffer,
On 1/4/2019 10:24 AM, Kristoffer wrote:
> On 2019-01-04 15:03, Wayne Stambaugh wrote:
>
>> I can somewhat see the utility in this but it really doesn't make a lot
>> of sense to me. Lets assume for a second that it would be useful to
>> create a separate atomic part for every
On 2019-01-04 15:03, Wayne Stambaugh wrote:
I can somewhat see the utility in this but it really doesn't make a lot
of sense to me. Lets assume for a second that it would be useful to
create a separate atomic part for every 0603 resistor part number
currently available. Given that the 0603
On 1/2/2019 8:24 PM, Rene Pöschl wrote:
> I have a few questions regarding multi part (or multi unit) symbols. (I
> do not really see a clear indication for these features in your document.)
>
> Is there a definition for having only some units exchangeable?
This is provided by the extends
On 1/2/2019 2:55 PM, Vesa Solonen wrote:
> kristoffer Ödmark kirjoitti 2.1.2019 klo 12.32:
>
>> I would rather have a new atomic file-format or storage format, so one
>> could actually send a complete part in an easy way, that would include
>> 3D-Files, SPICE data, symbol and footprints, and it
Hi,
On 03.01.19 19:06, José Ignacio wrote:
> I
> think useful comments to the proposed format should see beyond the
> actual low level representation of the data and talk about the overall
> model being used to store it.
tl;dr: That's a separate discussion.
There are two schools of thought
> The important thing is what is in the file. If nothing else, S-exp is a
concise way to express this concept during development. Exact format
representation in disk is, right now, bikeshedding.
The important thing is a clean data model and formal IDL like proto helps
with that immensely. If you
I agree. The important thing is what is in the file. If nothing else, S-exp is
a concise way to express this concept during development. Exact format
representation in disk is, right now, bikeshedding.
When we get to that stage, all that is required is that the format is VCS
friendly and human
2019 um 19:06 Uhr
Von: "José Ignacio"
An: anlutse...@gmail.com
Cc: "KiCad Developers"
Betreff: Re: [Kicad-developers] [RFC] Symbol library file format
I think all this babble about data representations to be pointless and counterproductive. the S _expression_ parser is
I think all this babble about data representations to be pointless and
counterproductive. the S expression parser is already implemented and it
works fine, it is trivial to convert s-expressions to any other data
representation you like, be it, xml, json or whatever comes up next week in
NPM. The
Hi Martijn,
My guess is that most of the complexity is in switching to new data model
in eeschema, which is going to happen anyway. Since with protobufs you
don't concern yourself with parsing data the only tricky thing would be to
seamlessly integrate proto codegen into build process on all
> On 3 Jan 2019, at 04:17, Andrew Lutsenko wrote:
>
> Wayne,
>
> > There are some interesting and practical concepts with protobuf but it's
> functionally a binary storage method which I am opposed to.
>
> That is a somewhat common misconception because protobufs are frequently used
> for
Wayne,
> There are some interesting and practical concepts with protobuf but it's
functionally a binary storage method which I am opposed to.
That is a somewhat common misconception because protobufs are frequently
used for efficient storage/transfer in binary format. But it's not tied to
that
Hi Wayne,
On 02.01.19 23:20, Wayne Stambaugh wrote:
>> This would be an artificial unit for the file format, not necessarily
>> the true internal unit (which I want to unify across the entire program
>> as soon as feasible, but that should be independent from the file formats).
> I'm not sure
I have a few questions regarding multi part (or multi unit) symbols. (I
do not really see a clear indication for these features in your document.)
Is there a definition for having only some units exchangeable?
Is there a way to define a unit as "must be placed" or "optional"?
Is there a way to
Hey Simon,
On 1/1/2019 5:03 PM, Simon Richter wrote:
> Hi Wayne,
>
> On 01.01.19 20:59, Wayne Stambaugh wrote:
>
>> I have updated and published the symbol file format[1] for comment.
>> Hopefully there isn't too much to change. The only thing to really
>> finalize is the internal units.
>
>
kristoffer Ödmark kirjoitti 2.1.2019 klo 12.32:
> I would rather have a new atomic file-format or storage format, so one
> could actually send a complete part in an easy way, that would include
> 3D-Files, SPICE data, symbol and footprints, and it would also mean that
> one could do the mapping
On 1/2/2019 5:24 AM, kristoffer Ödmark wrote:
> I like the idea of using something as Protobuf and I agree fully with
> the benefits, especially since one can add/remove fields with minimal
> impact.
There are some interesting and practical concepts with protobuf but it's
functionally a binary
I have no intention of embedding spice models in KiCad symbol files.
The current method of assigning spice information to symbols using
fields works very well so I don't see any reason to change it.
Cheers,
Wayne
On 1/2/2019 5:32 AM, kristoffer Ödmark wrote:
> I agree with Carsten Here,
>
>
I agree with Carsten Here,
The same way the footprints are not part of the symbol, the same way
SPICE models should be defined separate.
I would rather have a new atomic file-format or storage format, so one
could actually send a complete part in an easy way, that would include
3D-Files,
Hi Carsten,
Unfortunate, I don't think the reality works like that. While my
experience with SPICE is quite sparse (especially inside KiCad), I do
NOT think in this case about open and free spice model for IC's. Not
everyone uses the KiCad supplied libraries but their own, and simple
spice stuff
I like the idea of using something as Protobuf and I agree fully with
the benefits, especially since one can add/remove fields with minimal
impact.
Basically the S-expression system used now is looking very much like a
reinvented XML to me anyway, and storing protobuf-defined stuff as XML
or
Hello Thomas,
Am 02.01.19 um 10:39 schrieb Thomas Pointhuber:
> * I do not see anything related to SPICE in this document. I would vote
> to add it including the possibility to embedded spice models
> (BASE64-encoded) into the symbol itself.
I disagree on that.
Please do not mix two different
Hi,
nice to see that the new file format is shaping up now. Some comments
from my side:
* I do not see anything related to SPICE in this document. I would vote
to add it including the possibility to embedded spice models
(BASE64-encoded) into the symbol itself.
* pin type as it is currently
Hi Wayne,
I would like to take this opportunity to do an elevator pitch for idea of
using one of IDL languages widely accepted in the industry like Apache
Thrift or Google Protobufs to define formats in KiCad.
There are few large benefits in favor of using such languages:
1. They are self
Hi Wayne,
On 01.01.19 20:59, Wayne Stambaugh wrote:
> I have updated and published the symbol file format[1] for comment.
> Hopefully there isn't too much to change. The only thing to really
> finalize is the internal units.
This would be an artificial unit for the file format, not necessarily
I have updated and published the symbol file format[1] for comment.
Hopefully there isn't too much to change. The only thing to really
finalize is the internal units. The initial concept was unitless but
the more I think about it and discuss with other developers, it makes
more sense to use
39 matches
Mail list logo
