PYNQ 2.5.2 => how to disable synthesis for undesired boards? (to save time and licences)

Support
1

For a PYNQ 2.5 build from scratch the build fails. Even if a single board is configured in the Make invocation the build fails, likely on a missing HDMI license as also mentioned on:

(log with last info before stopping included below)

Still I disagree with the solution of getting a HDMI license for a board that I do not have, and lose a lot of time during the build process of the PYNQ 2.5 image. Even deleting the unused board files in the boards dir, before starting the build process (Pynq-Z1 Pynq-Z2 ZCU104) does not help, since later in the build flow they seem to be reloaded using git)

To make matters worse deleting the boards that cause problems and letting the build complete is not a valid work around, since the built PYNQ 2.5 image seems to be corrupt, losing the root dir content after a few minutes of using the image (eg with a find in the root dir). And seeing some configuration files for jupiter instead in root partition, so that a reboot does not succeed. Copying another image to the SD card works again with a find in root system running stable, so this does not seem a SD card problem.

Therefore I would like to do a feature request to make it possible to only use Vivado for configured boards as provided to the sdbuild makefile. Is this already possible, if so how can it be done???

Details below,
Kind regards,
HCAP

build environment: pynq 2.5.2 running on an Ubuntu 18.04.04 virtual machine on a windows10 host.

sbuild makefile invocation: make BOARDDIR=/home/xilinx/PYNQ/boards BOARDS=ZED
deleted board files Pynq-Z1 Pynq-Z2 ZCU104 in the boards dir,

before running
make BOARDDIR=/home/xilinx/PYNQ/boards BOARDS=ZED

Still Vivado 2019-1 hardware compilation for a ZCU104 board is started at a late point in the build flow, and failing.
Leaving directory ‘/home/xilinx/PYNQ/sdbuild/build/PYNQ/boards/ZCU104/base’
(likely this boards dir was dowloaded by git, instead of using files in the PYNQ/boards dir)

INFO: [Memdata 28-167] Found XPM memory block base_i/iop_pmod1/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.RX_FIFO_II/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst with a P_MEMORY_PRIMITIVE property set to auto. A value of block is required. You will not be able to use the updatemem program to update the bitstream with new data for the base_i/iop_pmod1/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.RX_FIFO_II/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst block.
INFO: [Memdata 28-167] Found XPM memory block base_i/iop_pmod0/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.TX_FIFO_II/xpm_fifo_instance.xpm_fifo_async_inst/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst with a P_MEMORY_PRIMITIVE property set to auto. A value of block is required. You will not be able to use the updatemem program to update the bitstream with new data for the base_i/iop_pmod0/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.TX_FIFO_II/xpm_fifo_instance.xpm_fifo_async_inst/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst block.
INFO: [Memdata 28-167] Found XPM memory block base_i/iop_pmod0/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.RX_FIFO_II/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst with a P_MEMORY_PRIMITIVE property set to auto. A value of block is required. You will not be able to use the updatemem program to update the bitstream with new data for the base_i/iop_pmod0/spi/U0/NO_DUAL_QUAD_MODE.QSPI_NORMAL/QSPI_LEGACY_MD_GEN.QSPI_CORE_INTERFACE_I/FIFO_EXISTS.RX_FIFO_II/gnuram_async_fifo.xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst block.
Command: write_bitstream -force base_wrapper.bit
Attempting to get a license for feature ‘Implementation’ and/or device ‘xczu7ev’
INFO: [Common 17-349] Got license for feature ‘Implementation’ and/or device ‘xczu7ev’
INFO: [Common 17-83] Releasing license: Implementation
344 Infos, 181 Warnings, 9 Critical Warnings and 1 Errors encountered.
write_bitstream failed
ERROR: [Common 17-69] Command failed: This design contains one or more cells for which bitstream generation is not permitted:
base_i/video/hdmi_out/frontend/inst/v_hdmi_tx/inst ()
base_i/video/hdmi_in/frontend/inst/v_hdmi_rx/inst ()
If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.
INFO: [Common 17-206] Exiting Vivado at Wed Jun 3 17:29:16 2020…
[Wed Jun 3 17:29:17 2020] impl_1 finished
wait_on_run: Time (s): cpu = 02:33:06 ; elapsed = 01:21:44 . Memory (MB): peak = 4494.426 ; gain = 0.000 ; free physical = 489 ; free virtual = 4980
error copying “./base/base.runs/impl_1/base_wrapper.bit”: no such file or directory
while executing
“file copy -force ./${overlay_name}/${overlay_name}.runs/impl_1/${design_name}_wrapper.bit ${overlay_name}.bit”
(file “build_bitstream.tcl” line 25)
INFO: [Common 17-206] Exiting Vivado at Wed Jun 3 17:29:18 2020…
makefile:16: recipe for target ‘bitstream’ failed
make[1]: *** [bitstream] Error 1
make[1]: Leaving directory ‘/home/xilinx/PYNQ/sdbuild/build/PYNQ/boards/ZCU104/base’

  • unmount_special
  • for fs in $fss
  • sudo umount -l /home/xilinx/PYNQ/sdbuild/build/bionic.arm/proc
  • for fs in $fss
  • sudo umount -l /home/xilinx/PYNQ/sdbuild/build/bionic.arm/run
  • for fs in $fss
  • sudo umount -l /home/xilinx/PYNQ/sdbuild/build/bionic.arm/dev
  • sudo umount -l /home/xilinx/PYNQ/sdbuild/build/bionic.arm/ccache
  • rmdir /home/xilinx/PYNQ/sdbuild/build/bionic.arm/ccache
    Makefile:325: recipe for target ‘/home/xilinx/PYNQ/sdbuild/output/bionic.arm.2.5.img’ failed
2

The easiest approach is use the PYNQ_SDIST argument to make to pass the existing sdist file and avoid rebuilding any of the bitstreams. The sdist can be downloaded from PyPI. This is what we do internally for our build processes.

The sdbuild process will install from the most recent git commit ignoring any uncommitted changes so if you want to build without the ZCU104 you can remove the directory from the boards folder and then create a new git commit.

The Pynq-Z2 is the only board required to be built as we use its HDF file to generate the code for the Microblaze subsystem but both the Pynq-Z1 and ZCU104 can be removed.

If a build fails during a time when the image is mounted the image isn’t removed. This is to allow for diagnosis and properly unmounting of the image file. A side effect is that the next run of make doesn’t know that the step failed and tried to continue resulting in indeterminate results.

We’re currently looking at ways of trying to reduce the pain of rebuilding the image from scratch without having to add large and easily out-of-sync bitstreams back into the repository.

Peter

3

Thanks for the suggestions Peter!
I did a local git rm/commit of unwanted boards, and doing so resulted in a build speedup and avoided the hdmi license conflict in doing a new build from stage2 onward with Pynq 2.5.2. And the make runs till completion. This advice helped a lot, and solves the main question!!

The build ran til completion and network services run when I use it.
Still there is a problem.
If for example I do a find / -name “base.bit” command then I get a lot of EXT4 errors, and the root “disappears”

The generated image looks OK, and a kpartx shows:
sudo kpartx -av ZED-2.5.img
add map loop20p1 (253:2): 0 204800 linear 7:20 2048
add map loop20p2 (253:3): 0 11158256 linear 7:20 206848

Still I see following dir at / after doing the find command in the root
at.hpp
foldl1.hpp
reverse_apply
split_at.hpp
drop_into.hpp
foldr1.hpp
reverse_apply.hpp
take.hpp

Strangely I can still access /bin /home/xilinx …
After this the init cannot be done anymore, and PYNQ does not boot again.
I did two tries, and once I could boot again after a e2fsck cleanup.
=> after cleanup the jupyter server and network were active, but no user login anymore
=> could get to dbus init and kept hanging there, periodically doeing a number of previous actions and get stuck at dbus again.

For the zedboard I did initially a number of experiments with an existing PYNQ 2.5.1 image, before deciding if PYNQ was worth using. I was impressed with the quality and nice integration with python. Also the filesystem is running stable - never saw an issue. If I reflash the SD card with this image then the ext4 images are not present, and I cannot trigger them with a simple find command.
I wonder if something went wrong in the build, strangely it runs till completion.
Is there somehting I can do tho diagnose this?

I only see that the initial (evaluation) image I used programs the FPGA during startup, and the generated build does not. No .bit files are present in the jupyter tree, I could not check this in depth since I tried the find command as one of the first stept.
During build of my ZED image I did not commit the ZED board files to local git repo in the boards directory.

Kind regards,
HCAP

4

Found the error on my filesystem errors. Was using a Vivado 2016.2 board file. Using a Vivado 2019.1 board file solves the issue, so the problem is solved.

  1. using PYNQ_SDIST or local git remove of unwanted boards prevents license issues and saves time
  2. using Vivado 2019.1 hardware files to generate pynq solves the ext4 issues I experionced.
    Kind regards,
    HCAP