kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

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@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
> 
> 
> _______________________________________________
> 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
>