Packaging up SymbiFlow for Gentoo

[StephanvanSchaik]

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.

[mithro]

@StephanvanSchaik I would recommend having a play with your Arty board using the examples in the SymbiFlow examples repository to get a feel for how the various parts actually end up being used before trying to package everything. That will also help you understand what to package first.

The team at @antmicro have also recently started looking at packaging for Gentoo (with the ultimate target being ChromeOS). It might be worth talking to @kgugala about this.

As very few people use symbiflow-arch-defs with system dependencies, it is most certainly broken.

It is also unclear to me if symbiflow-arch-defs should actually be packaged or just the data files that it produces. A lot of the project goes away if FPGA vendors start providing the description of their parts using the FPGA interchange format. As well some of the steps in data file production can take many hours even on a hugely beefy machine. Using the data files directly seems like a potential good compromise.