kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Stromtium!

Thank you for your heads-up!
I fully agree here and can't resist to "think big" and motivate when we are planning to support some future design entry methodologies in the long term.

Today, we already have:
  400++ configurable Pins of a FPGA
+ 300++ muxable Pins of a CPU
+ 300+ Pins I/O Connector
+ RAM
+ lots of other stuff
----------
= Ridiculous to draw and manage single pins in schematic symbols spread over 30 pages.

Solution: 
- Table based entry with import/export functionality. I mean SQL here and _not_ (only) spreadsheets. There will be demand for a *Synchronize*-button at some point in time.

- "Schematic symbols" are generated dynamically. (Similar to these Pin Mux Tools which are generating C-code for CPU initialization / device trees). These symbols might look completely different than rectangular boxes with feathers on the sides, placed on a page.

- Grouping +folding/unfolding and zooming/scaling of symbols could come in handy.

The I/Os and their properties of a component might get grouped by i.e. POWER, USB, ETH, DDR2, SPI, ...
Then they can be dynamically arranged / ordered by group,pinno or group,pinname, ...
Putting this table/view in a frame to place it on a schematic sheet is then a nice goodie, but not even necessary.
Search & replace capability and the import/export functionality is a must.

This might affect the file formats of library components as well as the schematics.

Regards,

Clemens

On 2017-02-14 10:54, Strontium wrote:
> Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of configurable pins, drawing an actual component is tedious and somewhat pointless as its just a box (or multiple boxes, one for each subunit) with pins. 
> 
> Some CPU's have so many functional units and pins that fitting it all on one giant box is also pointless as it may not even fit on a a3 page, so you end up with multiple parts in a component for various functional divisions and then multiple versions of the same component to account for different GPIO multiplexing arrangements, which change and evolve as the design evolves.  It quickly becomes a maintenance problem. 
> 
> For example, you decide GPIO 7 is good for a LED, but later, oh no GPIO 7 is the last SPI chip select, oh ok, swap it with GPIO 184, but no, its not that easy now you have to edit the component to reflect it, and now every design you have that uses the same CPU ends up with a unique version of the component to match its GPIO muxing.
> 
> I believe it would be far preferable for these types of components simply to define the functions of each pin in a table, and then when placing the part, its just an empty box (like a nested sheet).  You then right click on the part select "Add pin" and then select from the list of unplaced pins the one you want, and its function.  You then drop the pin on one of the 4 sides of the box.
> 
> Basically like the nested sheet/sheet pin in concept, except you can select which pin to import from the list of pins not yet utilised.
> 
> This way one only need to define a single component, and editing it is just a matter of editing a table of pins, which is very easy compared to drawing a component with 100's of pins.  You then "draw" the part uniquely for your design on your schematic, as you use each pin, but you only ever have one part defined in your library.
> 
> Schematic DRC would then have an Error/Warning for pins not used.  This would make it much easier with complex parts, for example, you have a USB page, you only need the pins from the cpu chip for USB sub unit, and if you decide to change the OTG ID pin to a different GPIO, you don't need to redraw your part, or have multiple "versions" of your part, you just delete the old ID GPIO pin, and add the new one.
> 
> This would be in addition to the current graphical parts, which are preferable for basic components and standard building blocks.
> 
> Steven
> 
> On 13/02/17 18:32, Oliver Walters wrote:
>> Here is a good example of where such a feature would be very well received: https://forum.kicad.info/t/component-occupies-entire-page-newbie/5272/22
>>
>> On Thu, Jan 5, 2017 at 12:10 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx <mailto:pavlina.chris@xxxxxxxxx>> wrote:
>>
>>     I second this suggestion. Numerous people have been proposing this for
>>     quite a long time in IRC, it's a popular idea. A large number of parts
>>     are configurable, and forcing the pins to be non-configurable makes ERC
>>     pretty weak.
>>
>>     On Wed, Jan 04, 2017 at 07:22:37PM +1100, Oliver Walters wrote:
>>     > As far as I am aware, this (
>>     > https://lists.launchpad.net/kicad-developers/msg23302.html <https://lists.launchpad.net/kicad-developers/msg23302.html>) is the latest
>>     > proposal for the new symbol format.
>>     >
>>     > Is this the case?
>>     >
>>     > Reading through this I have an idea that I think will be very useful.
>>     >
>>     > Currently each PIN can only have one TYPE (INPUT, OUTPUT, OPEN-COLLECTOR,
>>     > etc) which means that for parts with multiple alternate-functions on a pin,
>>     > ERC is essentially useless if the pin can be used as an INPUT or an OUTPUT
>>     > (or something else).
>>     >
>>     > Further, labelling all the possible alternate functions on a pin means that
>>     > either the symbol grows exceedingly wide, or many functions are missed.
>>     >
>>     > I suggest that the pin type should have facility for alternate functions to
>>     > be specified which would solve both of these problems. Once a symbol is
>>     > placed in the schematic, any multi-function pins are set to "default"
>>     > values (e.g. GPIO for a micro) but the other functions can be selected.
>>     >
>>     > See proposed "addition" to format here:
>>     >
>>     > http://i.imgur.com/5m38eTT.png
>>     >
>>     > Cheers,
>>     > Oliver
>>
>>
>>
>>
>> _______________________________________________
>> 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
>