Hi, Augusto! On 2018-02-02 14:11, Augusto Fraga Giachero wrote: > Yes, this idea would only work for small and medium sized ICs, but would > be nice to not depend on external tools besides Kicad and its symbol > libraries to do it.
I fully agree with you. External tools are off course optional. They might be also proprietary (i.e. tools from chip vendors). But the interfaces are IMO not optional. I was trying to emphasize that interfaces to other tools need to be bi-directional and automated and customizable with glue-logic. > Anyway, a tabled based entry might be a good solution. I believe it's mandatory for big designs. The importance of the visual graphical representation as we know it as schematics might become less important, then. > I'm glad to see that this issue is a concern among Kicad devs. I am not really a KiCad developer, but I am building from source, trying to understand some internals, and testing stuff. Mid-term, I am looking forward to integrate KiCad in my "Design-Flow". I would like to migrate my designs and libraries to/from my proprietary tool (+ self written lib-generators + database). Regards, Clemens > > Thanks, > Augusto Fraga Giachero. > > On 30-01-2018 21:37, Clemens Koller wrote: >> 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@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
