FPGA compilers read a PCF file in order to assign signal names to physical pins. Example:
set_io LED0 B5
set_io LED1 B4
set_io LED2 A2
set_io LED3 A1
set_io LED4 C5
set_io LED5 C4
set_io LED6 B3
set_io LED7 C3
set_io clk J3
It would be nice if librePCB could also read this same file to map signal names for a symbol variant to component names rather than have to select each and every one of them.
You mean the pinout in the device editor (not in the component editor), right?
Maybe something like that:
But I have a question about the PCF files. Here I see that it might contain array notation like pad_fpga_io[4] but LibrePCB doesn’t accept [] for now. How do you handle that? Should the PCF import threat it as pad_fpga_io4 instead?
I mean the component editor. The component signal names on FPGAs are all rather useless (IOP_34,IOR_10 etc). I want to be able to create symbols with the actual names from the design source and then create a symbol variant to replace the FPGA symbol with these variants. You need to enter in every signal one by one and map it to the component signal name on the FPGA. You will need to support whatever vector notation that the FPGA tool supports.
There is a open source FPGA compiler tool called IceStorm that would make a great companion to LibrePCB. We should make it easy to use them together.
Hm, now I’m totally confused. Aren’t the names B5, B4, A2 etc you mentioned above representing pad names? If yes, why are they relevant in the component editor (pad assignment is only in the device editor)? If no, what do they represent?
A real-world example (e.g. screenshots of symbols, components and devices) might help me to understand the use-case exactly. I’m sorry but I’m not familiar with FPGA at all, and I can’t implement a feature without understanding the use-case exactly 
There are actually two levels of mapping going on here.The fpga die has a signal name that identifies each pad on its data sheet. These are the component signal names. Each pad is connected to a package pin and this varies based on the package.
There are also a set of signal names created by the user.
The PCF file maps the user names to the package pins. The symbol for the fpga only lists the the names from the fpga data sheet which are useless on a schematic so the user needs to create their own symbols using the names that they understand. They need to use this symbol instead of the data sheet symbol so it needs to be a symbol variant and you need a second pcf file to map the user names to the data sheet names.
My request is that the number of pins are large enough that you need to be able to read in a text file rather than have to assign them one at a time.
Okay so if I understand correctly, importing a PCF file also makes sense in the device editor for the mapping from pads to component signals. This is actually my main question because I’m working on #679 at the moment which is tightly related.
I could implement the PCF import there by interpreting the file content this way:
set_io <signal> <pad>
to connect the corresponding pads to signals. Hope this interpretation of the PCF file is correct, if not (or if this feature makes no sense in the device editor) please let me know.
The device editor only knows about the component signal names from the data sheet. The only way to link to the users signal names is to map those to the data sheet names in the component editor
I’m sorry but I really don’t understand. I don’t know how FPGA datasheets look. I don’t know how FPGA symbol pins are named. I don’t know how FPGA pads are named. I don’t know how FPGA designers name their signals and how to export them to PCF files.
If you ever want such a feature to be implemented, please explain in detail (with screenshots, links to datasheets etc.) how an FPGA design looks (symbols/components/devices/packages) and how the corresponding PCF files look (real data corresponding to the screenshots). Otherwise I really cannot help here. So for now I won’t implement anything with PCF files, sorry.
Load these two repos and look in the symbol variant section
https://codeload.github.com/ouabache/LibrePCB_FPGA_Lattice_iCE40.lplib/zip/refs/heads/master
https://codeload.github.com/ouabache/FPGA_Icestorm_Test.lplib/zip/refs/heads/main