I’ve written a tool to generate an eeschema symbol library from the Quartus Prime Pin assignments.
When you run the Quartus fitter it will produce a .pin file in output_files/ in your Quartus Project directory.
Running ‘./qpin2lib.py my_proj/output_files/my_proj.pin >my_proj.lib’ will produce a symbol broken down into sub-symbols for each IOBANK, JTAG, Power, and Unknown (the stuff I haven’t categorised yet). The subsymbol is sized to contain the
number of nets in the subsymbol and the length of the longest net name, and annotated with the pin assignments for each net.
It’s still not as great as the FPGA integration in some of the commercial Schematic/Layout packages, but it’s a huge improvement over trying to manually create symbols for your FPGA (mine has 672 pins!)
Good idea! Now we need a Xilinx pin file processor as well.
One thing you might want to do is look at the list of 3rd-party tools for KiCad. Not only should you add your tool to that list so others can find it, but there are several symbol generation tools already available that you might modify/augment to do your task. For example, I wrote KiPart so that it could support readers for various types of files and generate symbols for them. It might be easy to port your Quartus .pin file code into a reader and then let KiPart apply all the detailed symbol construction details.
Integrating with KiPart does look like the way forward.
Quartus has a CSV export, but as far as I could tell, there is no way to get the non-signal permanent pins like GND, VCC, JTAG etc to appear in the output.
It looks like KiPart has most/all of the sorting, grouping and filtering I was planning to add. I’ll try and add my reader to KiPart in the next few days and send a PR.
I have no current interest in Xilinx parts, you’ll have to wait for someone else to do that.
I think parsing the .pin file is the way forward for you since most of that work is done and you’re getting all the detailed info you need from it.
I’ll take a look at it. Xilinx uses .pad files for this. It would be nice if there was a common file format for the FPGA<->schematic tool interchange, but probably not.