Hi,

I have been trying to package up SymbiFlow for Gentoo in my Portage overlay for FPGAs, but I am still running into issues with certain parts of this project and need some help figuring them out.

To understand the dependency hierarchy, I have been looking at both the packages in the AUR for ArchLinux as well as the requirements.txt and .gitmodules files for this repository as well as other repositories. The CMakeLists.txt file in this repository is also helpful as it checks whether certain programs are available or not.

1. I am packaging up each dependency, including the Python dependencies, individually, as it discouraged to use something like virtualenv or conda during the build process of an ebuild, especially to install dependencies that are not managed by the package manager. To build symbiflow-arch-defs, I basically have all the packages installed and then run the following:

   mkdir build
   cd build
   cmake .. -DCONDA=FALSE
   

   This successfully generates a Makefile in the build directory, which I can then invoke using make. However, when I do that, the build process fails with the following error (among 719 warnings, which I assume are not relevant to the build failing):

   Error 1: /home/stephan/symbiflow-arch-defs/build/xc/xc7/archs/artix7/devices/xc7a50t-virt/arch.timing.xml:65662 The x_offset and y_offset are both zero, this is a length 0 direct chain connection.
   make[2]: *** [xc/xc7/archs/artix7/devices/CMakeFiles/file_xc_xc7_archs_artix7_devices_rr_graph_xc7a50t_test.rr_graph.virt.bin.dir/build.make:83: xc/xc7/archs/artix7/devices/rr_graph_xc7a50t_test.rr_graph.virt.bin] Error 1
   make[1]: *** [CMakeFiles/Makefile2:59232: xc/xc7/archs/artix7/devices/CMakeFiles/file_xc_xc7_archs_artix7_devices_rr_graph_xc7a50t_test.rr_graph.virt.bin.dir/all] Error 2
   make: *** [Makefile:160: all] Error 2
   

   Looking at xc/xc7/archs/artix7/devices/xc7a50t-virt/arch.timing.xml (line numbers 65662-65677):

       <direct from_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_RXP_PAD" name="GTP_CHANNEL_3.GTPE2_CHANNEL_RXP_PAD_to_GTP_CHANNEL_3.GTPE2_CHANNEL_RXP_dx_0_dy_0_dz_-2" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_RXP" x_offset="0" y_offset="0" z_offset="-2"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_TXP" name="GTP_CHANNEL_3.GTPE2_CHANNEL_TXP_to_GTP_CHANNEL_3.GTPE2_CHANNEL_TXP_PAD_dx_0_dy_0_dz_4" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_TXP_PAD" x_offset="0" y_offset="0" z_offset="4"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_RXN_PAD" name="GTP_CHANNEL_3.GTPE2_CHANNEL_RXN_PAD_to_GTP_CHANNEL_3.GTPE2_CHANNEL_RXN_dx_0_dy_0_dz_-1" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_RXN" x_offset="0" y_offset="0" z_offset="-1"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_TXN" name="GTP_CHANNEL_3.GTPE2_CHANNEL_TXN_to_GTP_CHANNEL_3.GTPE2_CHANNEL_TXN_PAD_dx_0_dy_0_dz_3" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_3.GTPE2_CHANNEL_TXN_PAD" x_offset="0" y_offset="0" z_offset="3"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_TXN" name="GTP_CHANNEL_2.GTPE2_CHANNEL_TXN_to_GTP_CHANNEL_2.GTPE2_CHANNEL_TXN_PAD_dx_0_dy_0_dz_3" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_TXN_PAD" x_offset="0" y_offset="0" z_offset="3"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_RXN_PAD" name="GTP_CHANNEL_2.GTPE2_CHANNEL_RXN_PAD_to_GTP_CHANNEL_2.GTPE2_CHANNEL_RXN_dx_0_dy_0_dz_-1" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_RXN" x_offset="0" y_offset="0" z_offset="-1"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_RXP_PAD" name="GTP_CHANNEL_2.GTPE2_CHANNEL_RXP_PAD_to_GTP_CHANNEL_2.GTPE2_CHANNEL_RXP_dx_0_dy_0_dz_-2" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_RXP" x_offset="0" y_offset="0" z_offset="-2"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_TXP" name="GTP_CHANNEL_2.GTPE2_CHANNEL_TXP_to_GTP_CHANNEL_2.GTPE2_CHANNEL_TXP_PAD_dx_0_dy_0_dz_4" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_2.GTPE2_CHANNEL_TXP_PAD" x_offset="0" y_offset="0" z_offset="4"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_RXN_PAD" name="GTP_CHANNEL_1.GTPE2_CHANNEL_RXN_PAD_to_GTP_CHANNEL_1.GTPE2_CHANNEL_RXN_dx_0_dy_0_dz_-1" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_RXN" x_offset="0" y_offset="0" z_offset="-1"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_TXN" name="GTP_CHANNEL_1.GTPE2_CHANNEL_TXN_to_GTP_CHANNEL_1.GTPE2_CHANNEL_TXN_PAD_dx_0_dy_0_dz_3" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_TXN_PAD" x_offset="0" y_offset="0" z_offset="3"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_TXP" name="GTP_CHANNEL_1.GTPE2_CHANNEL_TXP_to_GTP_CHANNEL_1.GTPE2_CHANNEL_TXP_PAD_dx_0_dy_0_dz_4" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_TXP_PAD" x_offset="0" y_offset="0" z_offset="4"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_RXP_PAD" name="GTP_CHANNEL_1.GTPE2_CHANNEL_RXP_PAD_to_GTP_CHANNEL_1.GTPE2_CHANNEL_RXP_dx_0_dy_0_dz_-2" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_1.GTPE2_CHANNEL_RXP" x_offset="0" y_offset="0" z_offset="-2"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_TXN" name="GTP_CHANNEL_0.GTPE2_CHANNEL_TXN_to_GTP_CHANNEL_0.GTPE2_CHANNEL_TXN_PAD_dx_0_dy_0_dz_3" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_TXN_PAD" x_offset="0" y_offset="0" z_offset="3"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_RXP_PAD" name="GTP_CHANNEL_0.GTPE2_CHANNEL_RXP_PAD_to_GTP_CHANNEL_0.GTPE2_CHANNEL_RXP_dx_0_dy_0_dz_-2" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_RXP" x_offset="0" y_offset="0" z_offset="-2"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_RXN_PAD" name="GTP_CHANNEL_0.GTPE2_CHANNEL_RXN_PAD_to_GTP_CHANNEL_0.GTPE2_CHANNEL_RXN_dx_0_dy_0_dz_-1" switch_name="routing_R0_C0_Tdel1.375e-13" to_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_RXN" x_offset="0" y_offset="0" z_offset="-1"/>
       <direct from_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_TXP" name="GTP_CHANNEL_0.GTPE2_CHANNEL_TXP_to_GTP_CHANNEL_0.GTPE2_CHANNEL_TXP_PAD_dx_0_dy_0_dz_4" switch_name="routing_R0.0_C0.0_Tdel1e-12" to_pin="BLK-TL-GTP_CHANNEL_0.GTPE2_CHANNEL_TXP_PAD" x_offset="0" y_offset="0" z_offset="4"/>
   

   x_offset and y_offset are indeed set to 0, while z_offset is set. However, I don't really have a good understanding of the flow to fix this part, so I need some guidance here.

2. In the hope to get something working instead, I wrote an ebuild to simply use the files provided at https://storage.googleapis.com (as described here). I am still interested in packaging up a non-binary symbiflow-arch-defs ebuild, so I really prefer getting the above to work (I am assuming running make would end up giving me the same files as provided at https://storage.googleapis.com). However, when I run the following from symbiflow-examples/xc7:

   TARGET="arty_100" make -C counter_test/
   

   I get the following output:

   make: Entering directory '/home/stephan/symbiflow-examples/xc7/counter_test'
   cd build/arty_100 && symbiflow_pack -e top.eblif -d xc7a100t_test 2>&1 > /dev/null
   Error 1:
   Type: Routing
   File: /usr/share/symbiflow/arch/xc7a100t_test/rr_graph_xc7a100t_test.rr_graph.real.bin
   Line: -1
   Message: Unknown enum_loc_side
   Error occured at root[0] . getRrNodes[0] . getNode[149] . getLoc[0]
   make: *** [Makefile:53: build/arty_100/top.net] Error 1
   make: *** Deleting file 'build/arty_100/top.net'
   make: Leaving directory '/home/stephan/symbiflow-examples/xc7/counter_test'
   

   My guess would be that SymbiFlow is a fast moving project, which means that, given that the files I am using have been built two months ago, the Git repositories I am relying on for the dependencies may have introduced some breaking changes. However, I haven't been able to find a more recent build of these files, and I would prefer to pin the right commits if possible to not prevent these packages from breaking in the future, lest new breaking changes get introduced.

3. A bit unrelated to the other issues, but some useful information perhaps:

   1. I am using the SymbiFlow yosys fork, because I have ran into issues with using upstream (JSON backend errors).
   2. I am using the SymbiFlow vtr-verilog-to-route fork, rather than upstream. I had to modify the CMakeLists.txt file to have it build against system-wide capnproto, rather than the one it ships. In addition, it no longer installs the capnproto schemas as it violates the Gentoo packaging policy. I also have packages for abc and ezgl, such that the shared object files are available system-wide, but the CMakeLists.txt definitely need some more fixing to build against system-wide libraries.
   3. A number of packages violate the network-sandbox policy, in that they try to fetch files from external sources during the build process: yosys (fetches abc), yosys-symbiflow-plugins (uses wget in a Makefile), and few others. Currently I am just building these with FEATURES="-network-sandbox" to get things to work, but I will address these issues later.
   4. I have an Arty A7 T100 that I am using to test SymbiFlow (once I get there).
   5. I still have to figure out the correct dependencies for some of the packages, but I mostly have to carefully compare my ebuild against the packages provided by the AUR and the Git repositories, for that. Similarly, some packages could benefit from USE-flags once things are in a working state.
   6. I currently have add_subdirectory(soc) commented out in xc/xc7/tests/CMakeLists.txt to avoid depending on too many dependencies (e.g. LiteX and friends as well as Ibex).

I would really appreciate any guidance I can get to make it work. I am also around on IRC if that is quicker. I think this effort is also useful for package maintainers using other distributions, as the problems tend to be similar: cannot rely on conda, there is a need to package up dependencies, including the Python ones, individually, in the long run the packages should rely on releases, etc.

Yes, I do agree that distribution efforts do tend to be/get behind, but they are important to iron out some of the issues with the installation of SymbiFlow.