Running PYNQ on AWS F1

marioruiz · May 31, 2022, 9:03am

Yes, all the sources are available. If you follow the instructions for the lab you will get them.

AlphaApodis · May 31, 2022, 7:35pm

Which lab? I don’t see the source for the intro.xclbin, kernel_opt.xclbin, advanced.xclbin and compression.xclbin that are found in the PYNQ notebooks.

AlphaApodis · May 31, 2022, 10:00pm

It is currently building but it looks like I can recreate the notebooks following this:

The link in the notebook doesn’t work https://github.com/Xilinx/PYNQ-Alveo

I also used the newest AWS F1 shell instead of xilinx_aws-vu9p-f1_dynamic_5_0 to kick off the build.

marioruiz · June 1, 2022, 8:05am

Apologies, I misread.

Yes, that the source code for these designs Alveo-PYNQ/overlays at master · Xilinx/Alveo-PYNQ · GitHub

What notebook has the incorrect link?

Mario

AlphaApodis · June 1, 2022, 1:10pm

The notebook named 1-building-with-vitis.ipynb has this at the end:
https://github.com/Xilinx/PYNQ-Alveo

And this page is 404 for me.

Rebuilding the overlays has this error:

===>The following messages were generated while  performing high-level synthesis for kernel: xilLz77Compress Log file: /home/centos/Alveo-PYNQ/overlays/_xo.hw.xilinx_aws-vu9p-f1_shell-v04261818_201920_3/xilLz77Compress/xilLz77Compress/vitis_hls.log :
ERROR: [v++ 207-3772] use of undeclared identifier 'max_literal_count'; did you mean 'gz_max_literal_count'?: /home/centos/Alveo-PYNQ/overlays/vitis-libries/data_compression/L2/src/zlib_lz77_compress_mm.cpp:137:46
ERROR: [v++ 60-300] Failed to build kernel(ip) xilLz77Compress, see log for details: /home/centos/Alveo-PYNQ/overlays/_xo.hw.xilinx_aws-vu9p-f1_shell-v04261818_201920_3/xilLz77Compress/xilLz77Compress/vitis_hls.log
ERROR: [v++ 60-773] In '/home/centos/Alveo-PYNQ/overlays/_xo.hw.xilinx_aws-vu9p-f1_shell-v04261818_201920_3/xilLz77Compress/xilLz77Compress/vitis_hls.log', caught Tcl error: ERROR: [HLS 207-3772] use of undeclared identifier 'max_literal_count'; did you mean 'gz_max_literal_count'?: /home/centos/Alveo-PYNQ/overlays/vitis-libries/data_compression/L2/src/zlib_lz77_compress_mm.cpp:137:46
ERROR: [v++ 60-599] Kernel compilation failed to complete
ERROR: [v++ 60-592] Failed to finish compilation
INFO: [v++ 60-1653] Closing dispatch client.
make: *** [_xo.hw.xilinx_aws-vu9p-f1_shell-v04261818_201920_3/xilLz77Compress.xo] Error 1

marioruiz · June 1, 2022, 1:39pm

What Vitis version are you using?

This is most likely because of a mismatch between the Vitis Libraries (a submodule in the repo) and the Vitis version you are using.

AlphaApodis · June 1, 2022, 1:42pm

Vitis 2021.1
That is the version included in this AMI.

marioruiz · June 1, 2022, 1:58pm

I updated the submodule version.

Please try with this repository GitHub - mariodruiz/Alveo-PYNQ: Introductory examples for using PYNQ with Alveo branch 2021.1. E.g.

git clone https://github.com/mariodruiz/Alveo-PYNQ.git -b 2021.1 --recursive

If you find more problems, please open an issue in the repository so it easier to keep track of it.

cathalmccabe · June 1, 2022, 2:01pm

The example pulls from this branch (which is prior to the 2019.2 tag). The offending “max_literal_count” is here:

github.com

Xilinx/Vitis_Libraries/blob/b658aa5cd262d080048526ce931d4570cb931a36/data_compression/L2/src/zlib_lz77_compress_mm.cpp#L137


      
              hls::stream<compressd_dt> compressdStream("compressdStream");
              hls::stream<compressd_dt> boosterStream("boosterStream");
              hls::stream<compressd_dt> boosterStream_freq("boosterStream");
              hls::stream<uint8_t> litOut("litOut");
              hls::stream<lz77_compressd_dt> lenOffsetOut("lenOffsetOut");
              hls::stream<ap_uint<32> > lz77Out("lz77Out");
              hls::stream<bool> lz77Out_eos("lz77Out_eos");
          #pragma HLS STREAM variable = inStream depth = c_gmemBurstSize
          #pragma HLS STREAM variable = compressdStream depth = c_gmemBurstSize
          #pragma HLS STREAM variable = boosterStream depth = c_gmemBurstSize
          #pragma HLS STREAM variable = litOut depth = max_literal_count
          #pragma HLS STREAM variable = lenOffsetOut depth = c_gmemBurstSize
          #pragma HLS STREAM variable = lz77Out depth = 1024
          #pragma HLS STREAM variable = lz77Out_eos depth = c_gmemBurstSize
          
          
#pragma HLS RESOURCE variable = inStream core = FIFO_SRL
          #pragma HLS RESOURCE variable = compressdStream core = FIFO_SRL
          #pragma HLS RESOURCE variable = boosterStream core = FIFO_SRL
          #pragma HLS RESOURCE variable = litOut core = FIFO_SRL
          #pragma HLS RESOURCE variable = lenOffsetOut core = FIFO_SRL
          #pragma HLS RESOURCE variable = lz77Out core = FIFO_SRL

I can’t see where it is defined in that branch (which explains the error).
It is a FIFO depth setting, so you could try replace it. I’m not sure what depth you need. I can see “max_lit_count 4096” here:

github.com

Xilinx/Vitis_Libraries/blob/b658aa5cd262d080048526ce931d4570cb931a36/data_compression/L2/include/lz4_compress_mm.hpp#L56


      
          #define MIN_OFFSET 1
          #define MIN_MATCH 4
          #define LZ_MAX_OFFSET_LIMIT 65536
          #define LZ_HASH_BIT 12
          #define LZ_DICT_SIZE (1 << LZ_HASH_BIT)
          #define MAX_MATCH_LEN 255
          #define OFFSET_WINDOW (64 * 1024)
          #define BOOSTER_OFFSET_WINDOW (16 * 1024)
          #define MATCH_LEN 6
          #define MATCH_LEVEL 6
          #define MAX_LIT_COUNT 4096
          #define PARALLEL_BLOCK 8
          
          
// Kernel top functions
          extern "C" {
          /**
           * @brief LZ4 compression kernel takes the raw data as input and compresses the data
           * in block based fashion and writes the output to global memory.
           *
           * @param in input raw data
           * @param out output compressed data

This seems like it could be the right value. You could also try walk through the code to see what FIFO value makes sense, or run a simulation in HLS to see if you get any errors related to this.

I see the compression example has been updated significantly since this version. If the above doesn’t work or if you don’t want to try it, you could try rebuilding the latest version of the code (or the 2021.1 version).

Cathal

AlphaApodis · June 2, 2022, 3:29pm

Using the 2021.1 vitis library worked for everything but the compression examples. zlib_lz77_compress and zlib_huffman_enc are both gone in the newer library.

Rebuilding the xclbins for the other examples is enough because I would like to use FINN. However, FINN requires Vivado 2020.1 which is a different AMI (1.9.X). My cloud support has updated me that AWS F1 AMI 1.9.X is not showing available. This is probably an AWS issue but we don’t have the support tier membership.

Would there be anyway that you are someone at AMD/Xilinx could ask Amazon to look into this? An update to the AWS F1 / Alveo cards would be good I think.

marioruiz · June 2, 2022, 3:45pm

You can check with the FINN team for support for newer Vivado versions. I believe the dev branch should support this Vitis version.

Topic		Replies	Views
Xclbin cannot be downloaded on AWS F1 instance Support	8	770	June 11, 2020
Getting Started with PYNQ - Alveo Edition using AWS F1 Instances Learn	0	2850	March 2, 2020
Pandas installation fails on PYNQ Z2 Support	4	597	June 26, 2022
Xclbin cannot be downloaded Support	3	1443	January 10, 2021
Can't download bitstream Support	5	1089	February 22, 2022

Running PYNQ on AWS F1

Related Topics