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
> 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 +
> 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
>> 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
>> 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:
>> On 2018-01-30 16:01, Augusto Fraga Giachero wrote:
>>> 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.
>>> Augusto Fraga Giachero.
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : email@example.com
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : firstname.lastname@example.org
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : email@example.com
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~kicad-developers
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp