Cannot run test suite in CentOS Linux 7.4

[clavin-xlnx]

My current OS environment is:

cat /etc/centos-release
CentOS Linux release 7.4.1708 (Core) 
$ uname --kernel-name --kernel-release --machine
Linux 3.10.0-693.el7.x86_64 x86_64

I cannot use Docker nor can I use sudo/root to install any packages.

When trying to run the directions from README.md, I get stuck while building the Python wheel for rapidyaml (log attached).
rapidyaml-failure.txt

I was able to get past that issue by replacing the line in requirements.txt:

git+https://github.com/litghost/rapidyaml.git@fixup_python_packaging#egg=rapidyaml

with

pyyaml

However, now I get an different error after invoking make all-tests:

/home/clavin/tools/lnx64/python-3.8.3_rdi/bin/python3: Error while finding module specification for 'fpga_interchange.patch' (ModuleNotFoundError: No module named 'fpga_interchange')
make[4]: *** [devices/xc7a35t/CMakeFiles/constraints-xc7a35t-device.dir/build.make:81: devices/xc7a35t/xc7a35t_constraints.device] Error 1
make[4]: Leaving directory '/home/clavin/fpga-interchange-tests/build'
make[3]: *** [CMakeFiles/Makefile2:3589: devices/xc7a35t/CMakeFiles/constraints-xc7a35t-device.dir/all] Error 2
make[3]: Leaving directory '/home/clavin/fpga-interchange-tests/build'
make[2]: *** [CMakeFiles/Makefile2:2597: CMakeFiles/all-tests.dir/rule] Error 2

(see full log for entire context: make-all-tests-failure.txt)

[clavin-xlnx]

After the recent instruction updates I am able to get everything to run upto make all-tests. However, shortly after running it, I get another error:

[  0%] Built target xc7-mmcm_ext_fb-basys3-output-dir
[  0%] Built target rapidwright-xc7a35t-device
[  0%] Built target constraints-xc7a35t-device
[  0%] Built target constraints-luts-xc7a35t-device
[  0%] Built target timing-xc7a35t-device
[  0%] Built target chipdb-xc7a35t-bba
[  0%] Built target chipdb-xc7a35t-bin
[  0%] Built target xc7-mmcm_ext_fb-basys3-json
[  0%] Built target xc7-mmcm_ext_fb-basys3-netlist
[  0%] Built target xc7-mmcm_ext_fb-basys3-phys
[  0%] Built target xc7-mmcm_ext_fb-basys3-fasm
[  0%] Built target xc7-counter-arty35t-output-dir
[  0%] Built target xc7-counter-arty35t-json
[  0%] Built target xc7-counter-arty35t-netlist
[  0%] Built target xc7-counter-arty35t-phys
[  0%] Built target xc7-counter-arty35t-fasm
[  0%] Generating arty35t/counter.bit
[Errno 9] Bad file descriptor: /home/clavin/fpga-interchange-tests/env/conda/envs/fpga-interchange/share/symbiflow/prjxray-db/artix7/mapping/parts.yaml
make[3]: *** [tests/designs/counter/CMakeFiles/xc7-counter-arty35t-bit.dir/build.make:80: tests/designs/counter/arty35t/counter.bit] Error 1
make[2]: *** [CMakeFiles/Makefile2:10072: tests/designs/counter/CMakeFiles/xc7-counter-arty35t-bit.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:2597: CMakeFiles/all-tests.dir/rule] Error 2
make: *** [Makefile:209: all-tests] Error 2

When I look at the file:

/home/clavin/fpga-interchange-tests/env/conda/envs/fpga-interchange/share/symbiflow/prjxray-db/artix7/mapping/parts.yaml

It seems normal:

ls -l /home/clavin/fpga-interchange-tests/env/conda/envs/fpga-interchange/share/symbiflow/prjxray-db/artix7/mapping/parts.yaml
-rw-rw-r-- 2 clavin users 6360 May 12 02:56 /home/clavin/fpga-interchange-tests/env/conda/envs/fpga-interchange/share/symbiflow/prjxray-db/artix7/mapping/parts.yaml

I've uploaded the file: parts.zip

FYI - @mithro

[acomodi]

@clavin-xlnx We have added centOS 7 to CI with this PR: https://github.com/chipsalliance/fpga-interchange-tests/pull/118.

This was done to verify whether everything is actually running correctly for multiple OS and it seems the case, also running on a docker image with CentOS 7.4.1708 is not causing any error, at least for the Xilinx devices.

I have tested also the nexus ones but there is a problem with glibc that needs to be at least 2.18 while centOS 7 is shipped with 2.17, so the make all-tests will fail when trying to build the nexus devices.

I suggest to run the following to build all the tests of a specific family:

make all-<device>-tests

Where device can be for instance xc7a35t or xc7a100t. You may see a list of supported devices in here.

On an additional note, what I ran on a local docker image with centOS 7 is the following:

cd fpga-interchange-tests
source .github/scripts/centos-setup.sh # This is to install all the required packages in the system (it also updates the GNU make version to 4.2.1 from the shipped 3.8 to allow --output-sync to be used, manly for CI purposes)
make env
source env/conda/bin/activate fpga-interchange
make build
make update
cd build
make all-xc7a35t-tests -j$(nproc)

[clavin-xlnx]

Thanks @acomodi - I tried the device specific calls, both xc7a35t and xc7a100t but both return with the same problem. It appears to be something to do with loading the YAML file itself (the error is emanating from a class called OpenSafeFile, but I can't really dig too much farther. Is there a way to simply disable bitstream generation?

[clavin-xlnx]

Thanks @acomodi - I tried the device specific calls, both xc7a35t and xc7a100t but both return with the same problem. It appears to be something to do with loading the YAML file itself (the error is emanating from a class called OpenSafeFile, but I can't really dig too much farther. Is there a way to simply disable bitstream generation?

Perhaps this is a side effect of dropping rapidyaml for pyyaml?

[acomodi]

Perhaps this is a side effect of dropping rapidyaml for pyyaml?

@clavin-xlnx This could be a cause. I suggest to rebase from the current main and try everything once again from a clean build.

The rapidyaml package is now taken from upstream and is now correctly installing in the conda environment in centOS 7.4 (at least in the docker image as well as in CI).

Is there a way to simply disable bitstream generation?

I have opened this PR which adds a target to run all the DCP+bitstream generation test which basically can skip the bitstream generation from the FASM file, and directly uses the DCP from RapidWright.

[clavin-xlnx]

I think the latest changes have allowed me to run what I needed to. Closing this issue for now.