Hi there, I am a new to the scene FPGA developer working on the Kria KV260, my first time interfacing with the board and the first time using vivado. I was following the composable overlay tutorial (Create Composable Overlays (hw) — PYNQ Composable Overlays 1.0.2 documentation) to get myself familiar with creating overlays and exporting them to the board. But under the Default Path section I am confused at what the task is:
Where/what do I have to do with the block of code. Also what information am i saving to a file with the same name as overlay? As when I put the tcl code in under the following section (Get composable overlay files), It returns the error statement:
D:\Xilinx_Unified_2022.2_1014_8888\Vivado\2022.2\gnuwin\bin\cp.exe: target `fir.bit’ is not a directory
You need to create a file with the name fir_paths.json with the content shown in the image, this file must be placed next to the .bit and .hwh on the board so it can be consumed properly.
I’ll have to investigate the problem with cp on Windows further. But, you can copy these files manually.
Hi mario,
Thanks for your reply! Turns out error was prompted by a naming issue with the file (accidentally had a space between characters).
I have continued following the composable overlay example and have progressed to the SW section. With the .JSON,.bit and .hwh file uploaded via drag and drop into the jupyter terminal I got to block 3 of input code which gets returned with the KeyError:
The overlay from the bit file has definitely been uploaded as I can call to other parts of the overlay (e.g. axi_intc) but not to the filter.
.bit and .hwh files: fir.hwh (580.3 KB) fir.bit (7.4 MB)
Do you have an idea what is causing the KeyError?
still PYNQ 3.0.1 and ubuntu 22.04
The tutorial was written for PYNQ 2.7 and composable 1.0.0.
However, in the Kria you have PYNQ 3.0.1 and composable 1.1.0-dev. The documentation is not yet updated, the nomenclature changed, you can find the correct json file here
Having a bit more issue with outdated files in the git repository I think. I have been playing about on the Kv260 with the files that come pre-loaded on the PYNQ 3.0.1 image in Jupyter, under the “custom_pipeline” folder, within the “pynq_composable”. Some of these files use a composable overlay with the bitstream “cv_dfx_3_pr.bit”, which I would like to view within vivado to see the block design.
On the git repository, this is the most up-to-date .tcl file i can find with the same name:
However, when i open the file in my Vivado (v2022.02) it is outdated slightly (v2022.1).
Is there an available .tcl file for the 2022.2 version or can I update it myself online somewhere?
v2022.1 tcl file: cv_dfx_3_pr.tcl (128.7 KB)
The v1.1.0-dev is the latest branch which is associated to PYNQ 3.0.1 and in turn to Vivado 2022.1.
Unfortunately, there is no newer tcl file for Vivado 2022.2
Thanks for the clarification, that’s understandable. I tried loading that .tcl file into vivado 2022.2 (via Tools->Run Tcl script) however I get greeted with the following error:
Not really. You can try commenting the line where the file is added in the tcl file, and add the file manually to the project before you execute the tcl script.
Out of interest. If I installed vivado 2022.2 on a linux pc and ran the makefile from the git repository, would it then be able generate the block design and present it. Is it to do with the individual file grabbing to my windows os vivado?
I finally got access to a linux pc ( a remote cluster of HPC with FPGAs, hence I am accessing it through a virtual desktop client software from my laptop) with vivado installed (all possible versions from 2015 -2022.2). My plan was to run the makefile stated above but in vivado 2022.2, as this is what I had installed in my laptop to make editing the tcl file a lot easier once extracted from the remote computers.
My main query is the processes required before running the makefile. Currently I have:
Am I correct in saying it has completed the synthesis stage, but has failed at the implementation stage?
I have the ability to run the Vivado GUI, would it be worth loading in the files and running it with the GUI open to provide a bit more insight?
Within the readme folder you detail that the bitstream will be produced in the ‘Overlay’ folder, where will this be found? Should it be in the KV260 folder?
I understand that the v1.1.0-dev.2022.2 isn’t heavily tested, so I might try my luck with the 2022.1 version now.
This is likely the server running out of memory (RAM). You can try to reduce the number of jobs Vivado launches
Within the readme folder you detail that the bitstream will be produced in the ‘Overlay’ folder, where will this be found? Should it be in the KV260 folder?
Yes, if the generation is successful you will see an overlay folder within KV260. Since, you original project failed you should run make distclean to remove the project.
Ah ok that makes sense, what can I do to reduce the number of jobs vivado launches. Can I just comment out section from “launch_runs impl_1…” line 446 down to line 463?
It failed again at 8 jobs so I reduced it further to 4. Now it has been going for an hour and a half, with the last line reading:
Waiting for impl_1 to finish...
Just wondering while I wait if there’s anyway to generate a progress bar in the code, like you get with the Vivado GUI. As It would be good to see whether it is worth reducing the jobs even further if it is hanging.
On that note, what is the purpose of the ‘jobs’ and does the number completed affect the block design/bitstream generation?
Also Just wondering, If i run a ‘make zip’ command in the KV260 once the overlay file is created will it package all the essential parts of the design so that I can transfer it to open the block design on a different pc with the same vivado version installed?
jobs is the number of cores (threads) that Vivado will use for synthesis and implementation. The more jobs, the faster the generation should be. With 16 cores the process takes over an hour, so with 4 it should be at least two hours.
Just wondering while I wait if there’s anyway to generate a progress bar in the code, like you get with the Vivado GUI. As It would be good to see whether it is worth reducing the jobs even further if it is hanging.
There should be a log file with the progress, but not in the form of progress bar. You should be able to open the project from another terminal and look at the progress.
make zip only packs the output results, what you import on the board. Not the project.
Ah I see, it might be failing at the same stage then at later times as I change the cores as it has failed again in the 4 job trial with the same error code but has progressed in terms of new information printed to the screen:
Is your thinking that running the implementation with less cores help stabilise the procedure, at the cost of slowing it down?
Attempting to run it again with 2 cores but could be an all day job.
