kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Augusto!

Your ideas regarding multiplexed I/Os are good, but might only be sufficient for small to medium-complex CPUs/FPGAs/modules/circuits. If you follow the latest developments, you will notice that there are even bigger things coming up and it will get more and more difficult to visually represent the huge amount of varying I/Os and to solve dependencies and restraints. So, in the long term, I suggest to have a look at some even more flexible methods as i.e. (database-) tabled based design entry.

This means that a design tool (here KiCad) IMO needs to polish it's interfaces to the outside world to import/export pin lists and netlists on request.
Some tools can work with lists/.CSVs, but seem to lack automation (forward/backward annotation). I am working a lot with databases and use my own glue (sql-scripts) to import/export generated pin lists to/from the Pin-Multiplexing software and to/from the design. Version managment is also mandatory.

You might have a look at i.e. the Altera Pin Planner, Xilinx IO Planning or the Pins Tool from NXP to get an idea where we are heading to:
https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX

Regards,

Clemens



On 2018-01-30 16:01, Augusto Fraga Giachero wrote:
> Hi,
> 
> I've been designing schematics with some stm32 parts using the standard 
> Kicad libraries, and a lot of these microcontrollers has 10+ functions 
> multiplexed in each I/O pin. In the standard library the symbols 
> displays all possible configurations available to each pin, I understand 
> the motivation of this choice (not having to refer to the datasheet 
> every time you want choose an I/O for some specific functionality), but 
> this results in very large symbols occupying the page.
> 
> I've come with a idea (which probably isn't new) to deal with this problem:
> * You can select what functions you will use from a list for each pin 
> and only that will be displayed in the schematic;
> * You can then resize the symbol accordingly directly in the schematic;
> * While this wouldn't require any modification to the library symbol 
> file format as the description string of each pin already carries all 
> the necessary information, the .sch file format would probably be 
> changed and would not have backwards compatibility.
> 
> This may not be easy to implement as with the way eeschema handles 
> symbols today and the issues I've cited above, I would like hear about 
> your suggestions.
> 
> Thanks,
> Augusto Fraga Giachero.
> 
> 
> _______________________________________________
> 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
>