Hi, Just a thought. This feature could also be very useful to import/export of FPGA physical constrain files (PCF). This would allow us to keep the pin naming in sync between the schematic and HDL. Maybe even simplify pin swapping?
Cheers, Piotr > On May 9, 2019, at 7:55 AM, Johannes Wågen <johan...@wagen.no> wrote: > > Hi > > The open source FPGA tools also have this. It might be worth to take a look > at[1]. It is written in JavaScript, but it does perhaps give some indication > of what such a tool could be capable of. > > [1] https://github.com/nturley/netlistsvg > > > -Johannes Wågen > > Den 09.05.2019 14:32, skrev Reece R. Pollack: >> You might want to take a look at how Xilinx ISE and similar products handle >> this. Their tools take in Verilog or VHDL and can produce a graphical >> representation of the resulting logic. It's not as readable as a hand-drawn >> schematic but it exists and enough people find it useful that Xilinx >> maintains it. >> >> -Reece >> >> On 5/3/19 6:38 PM, Russell Oliver wrote: >>> I have no doubt about the difficulty of plumbing something like this >>> feature into KiCad. Most things are easier said than done. >>> >>> A few thoughts in response >>> >>> 1. My initial thought was to skip generating a graphical schematic, >>> and to simply join in essence two or more netlists while avoiding name >>> conflicts. It seems convoluted to start with essentially a >>> connectivity graph, only to create a graphical representation for it >>> be be evaluated to create a connectivity graph. It begs the questions >>> then, should/could there be a text based representation of the >>> connectivity graph created by eeschema with the information needed to >>> perform ERC? >>> >>> No ERC would be performed between the eeshema Netlist and the Skidl >>> netlist. This would be left as a design task. The only ERC check would >>> be on the hierarchical pins which would be predefined by the user as >>> the interface to the SKIDL generated netlist. Users could be warned >>> that ERC information doesn't exist for some components. >>> >>> 2. Thinking about it further the task of generating a graphical >>> schematic shouldn't be too difficult using the SKIDL library. I >>> suspect Dave would be disappointed in me for being addicted to >>> schematics. A simple grid based layout with plenty of room between >>> symbols and using straight line between pins to create connections >>> would be possible. This would easiest once Eeschema has python support >>> and the new file format. >>> >>> 2. Editing SKIDL scripts as subsheets I envisage would either be >>> through a user defined text editor, or a basic one implemented into >>> KiCad. Once the edit has been done, the file would be evaluated >>> through the python runtime with the Skidl library (or for a more >>> generic solution a user specified command line, with the output >>> captured back as a netlist or schematic). >>> >>> 3. Editing of the resulting components through the edit symbol fields >>> dialog I think would be possible but only as a one way operation once >>> the generated netlist/schematic has been added. In that sense it would >>> be up to the user to maintain that information in the script so that >>> it is generated each time. >>> >>> Kind Regards >>> Russell >>> >> >> >> _______________________________________________ >> 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