kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Tim!

I agree that in the near future, the demand for (I'd call it) "Table Based Design Entry" will rise tremendously,
when we reach pincounts in the high hundreds and thousands.

It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs in some schematic when pins can have 8 different functions which might change during product development. A current example: i.MX8 [1] with i.e. 625 pins.
So, it might not even be sufficient to be able to import (and export) .CSVs. It might be a good idea to prepare for some automatism to be able to update and version control pin multiplexing changes!

Regards, Clemens

[1] https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQIEC.pdf

On 15/09/2019 15.29, Tim Hawkins wrote:
> What about shunting the problem aside and have the ability to load a fixed format csv file with the details of the pin map. The file could then be bundled with the project.  Ie define a dynamic component, that has a physical form, but its schematic forms are dynamic, and depend on the contents of the csv (speadsheet),  each row is one physical pin, with bus groups, lables and other elements defined in the ss. 
> 
> On Sun, Sep 15, 2019, 9:18 PM Strontium, <strntydog@xxxxxxxxx <mailto:strntydog@xxxxxxxxx>> wrote:
> 
>     Hello Ajith,
> 
>     I admit i skimmed your proposal, but i think it looks like it has merit, and that work can be done to improve symbols and pin mapping.
> 
>     I always struggle with multi use pins like on MCUs.  Its tedious to keep drawing boxes with pins, just to support a layout of pins that suits the pinmuxing your using, and the a decent layout of the schematic.
> 
>     I think a complex component like an MCU or FPGA could work like a sub-sheet.  It doesn't have a shape or symbol, per-se.  Its JUST a list of pins.  You then drop one of that component (which is a resizeable box like a sub-sheet), and like a sub-sheet import pins from it and place wherever you want in the box boundary.  Want to break your MCU into functional units, just drop another box with the same reference, import the pins you want into there.  It would be a lot easier to manage, i think.  And would reduce redundancy in part definitions for complex MCUs, and make those parts a lot easier to define in the process.  But I also think its probably a lot of work to do, and I don't know how it would break the file formats. 
> 
>     However this would also allow one to choose the mux function/s which could set the appropriate pin attribute for that pin, input/output/open drain, etc.  Making DRC sane again.  The schematic would be neater and would also tell you more about what is intended than:
> 
>     I2C2_CLK/SPI1_MISO/ADC3_CH6/CLK_OUT/UART3_TX/UART2_TX/TIMER2_A/SCLK | 10 -----
> 
>     Does.  Which is how a lot of MCU's end up getting defined.  Instead the designer says, this pin is the I2C2_CLK and the pin then looks like this in the schematic:
> 
>     I2C2_CLK | 10 -----
> 
>     doesn't suit layout, right click on pin and change it to the I2C2_CLK on pin 239:
> 
>     I2C2_CLK | 239 -----
> 
>     Don't have to copy the component, move pins around, reimport the changed symbol, etc etc.
> 
>     For simple components, like diodes, transistors, buffers, LDOs, opamps, etc etc.  Then a symbolic representation is definitely the way to go.  And your proposal would make that even nicer.  I like the list of pins example you gave for the transistor.  Much clearer from a schematic perspective.
> 
>     Steven
> 
>     On 12/9/19 11: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.
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     Mailing list: https://launchpad.net/~kicad-developers
>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     Unsubscribe : https://launchpad.net/~kicad-developers
>>     More help   : https://help.launchpad.net/ListHelp
> 
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> 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
>