kicad-developers team mailing list archive

[Ajith N <ajith@xxxxxxxxxxxx>]

Hi, 



Thanks, Wayne, for the response in which you pointed to the v6 Symbol Format Document.



Thanks to others who contributed as well.



Wayne, you also mentioned information scattered in this mailing list (which I have

explored a fair bit, later and after the fact, but with mixed results).



Btw, the v6 Symbol Format had already been pointed out to me (In fact I used v6 syntax

to illustrate a point in my proposal).



On the whole, I feel there is more to it than the symbol file format. Approaching it from a

User perspective, I think it is the semantic aspects of the data model

that attracts a lot of interest from users -- much more than the file format itself.



Understandably so, since the data model underlying the tool addresses some key points,

e.g. as to what the main data entities are, and how they are related. Particularly,

the is-a and has-a relationships, the cardinalities of relationships, constraints etc

all of which would have the greatest impact on the user.



(Other finer aspects including rules and policies governing object ownership /

referencing / containment / lifecycle etc would be more dear to developers but normally,

users care little about those).



>From searching this mailing list, I could find no definitive statements on the

semantic aspects of the data model which would help me conclude whether or not KiCad v6 would

allow a logical pin name to map to a list of pad numbers, or that symbols with unmapped pins

could be created (to be used for purposes they are fit for).

(That is, a one-to-n mapping where range of n == I, i.e., zero included).



Perhaps these matters are clear in the minds of developers but have not been published

(or I couldn't find them).



As regards Atomic Parts and the "generic workflow" (for want of a better term), 

I am in agreement that KiCad should support both types of usages fairly. I think

software maintenance would be easier if both are handled in a unified manner. I think 

having pin mapping as a third asset, distinct from symbols and footprints, yet with the possibility

of being implicitly bound to symbols when required (for supporting the atomic part use-case)

will be a good thing in that direction. (In a nutshell, that motivates my proposal).



I think the philosophy of XESSCorp's KiPart tool [https://github.com/xesscorp/kipart]

reinforces the point, as also some other EDA tools which allow pin mapping to be

separate(d) from the symbol itself.



As far as I can gather from the User Forum, most users would be happy to have the

facility to import pin maps (preferably in a CSV kind of text format), and apply the

mapping to get the symbols they want -- when faced with a situation where no

matching symbol is readily available.



For FETS, BJTs, Opamps and the like, KiPart is not a very happy solution since most

people prefer to see the familiar graphic symbol (than rectangular boxes). It could 

well be the EE equivalent of "Literate Programming", or that a picture is worth

a thousand words...



For more complex functional blocks (e.g in a processor or FPGA), boxy graphic symbols

are fine enough (e.g. as drawn by KiPart).



Another thing about KiPart is that it works outside of KiCad. I think a similar facility

within KiCad, supporting the combining of existing or generated graphic symbols with 

user-definable pin mappings, will be a good addition to KiCad.



Depending on whether the graphic symbol is a familiar symbol (e.g FETs)

or a boxy symbol which is auto-generated, some differences could arise.

But in  both cases, a facility to import/export pin mappings in CSV format

would be useful, in my view.



Having a CSV (or other simple text format) defined will allow easy conversions from typical

 established formats to the appropriate KiCad CSV format. Some of those 

"standard formats" are, taking FPGA use cases, Quartus "*.pin" format,

Xilinx UCF/"*.pad" format etc. These could be handled by matching plugins / scripts.



I think KiCad users would like to know and influence the direction v6 will take on matters

such as these. More communication between developers and users would be beneficial (subject

to time constraints, of course. That bit, I do totally understand!).



Thanks to everyone who offered their inputs here as well.... and thanks for listening!



Cheers,

--Ajith



---



On Thu, 12 Sep 2019 05:44:04 -0700 Wayne Stambaugh  wrote:




Hello Ajith,

In the future, please search the developers mailing list before spending
time writing a proposal.  You would have saved yourself a lot of time
since almost everything in your proposal has already been discussed.
Pin remapping support is already part of the new symbol file format
which has been documented[1].  As for the rest of your proposal, this is
primarily library organization which is a personal preference.  There is
nothing currently stopping you from creating atomic (fully defined)
symbol/footprint/3D model assemblies but that is not something the KiCad
project is interested in providing other than possibly a high level
format that encapsulates these entities for portability (which has also
been discussed).

Cheers,

Wayne

[1]:
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit

On 9/12/19 12:36 AM, Ajith N wrote:
> Sorry the URL was mangled, here it is:
>   https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf
> 
> 
> ---- On Thu, 12 Sep 2019 12:30:26 +0800  ----
> 
>     Hi Developers,
> 
>     Requesting your attention to a proposal and discussion in the KiCad
>     User Forum. The topic is symbols and pin mapping (for v6) as they
>     relate to the data model.
> 
>     I took up a suggestion (by Rene Poeschl) to detail my proposal with
>     diagrams, and have prepared some slides, which is at:
> 
>         https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf    ; (PDF
>     format)
> 
>     The background references are at the end.
> 
>     (I feared being unable to respond in a timely manner to potential
>     questions which may arise in the course of discussions in the
>     developers' list. Therefore, I have chosen to put more detail into
>     the slides wherever possible. Hopefully that helps. The detail may
>     be excessive for some readers though. If so please bear with me).
> 
>     I hope KiCad developers find this worth looking at for v6.
> 
>     Thanks for all the great work!
> 
>     P.S.
>     I have been a happy user of KiCad for barely over a year now. KiCad
>     to me is a very nice and open tool with nice features, has no
>     lock-in, has an active community of users and is progressing in a
>     good direction.
> 
> 
> 























---- On Thu, 12 Sep 2019 12:36:12 +0800 Ajith N <mailto:ajith@xxxxxxxxxxxx> wrote ----




Sorry the URL was mangled, here it is:

  https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf






---- On Thu, 12 Sep 2019 12:30:26 +0800  ----













Hi Developers,



Requesting your attention to a proposal and discussion in the KiCad User Forum. The topic is symbols and pin mapping (for v6) as they relate to the data model.



I took up a suggestion (by Rene Poeschl) to detail my proposal with diagrams, and have prepared some slides, which is at:



    https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf    ; (PDF format)



The background references are at the end.



(I feared being unable to respond in a timely manner to potential questions which may arise in the course of discussions in the developers' list. Therefore, I have chosen to put more detail into the slides wherever possible. Hopefully that helps. The detail may be excessive for some readers though. If so please bear with me).



I hope KiCad developers find this worth looking at for v6.



Thanks for all the great work!



P.S.

I have been a happy user of KiCad for barely over a year now. KiCad to me is a very nice and open tool with nice features, has no lock-in, has an active community of users and is progressing in a good direction.