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 <[email protected] >> <mailto:[email protected]>> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
