-
Notifications
You must be signed in to change notification settings - Fork 478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XRT won't configure PL on *_base platforms? #2747
Comments
I tried to run examples from the Vitis_Accel_Examples, on a platform based on official embedded platforms, unsuccesfully. The issue appears to be similar with the one that @FenrisTC mentions. I would like also to mention that similar issues came up using the pre-built platform (zcu102_base). I was unable to run the examples. Furthermore, i used Vivado to manually create the hardware components for a custom platform, based on the UG1416, and the results were the same. The PL seems to be unresponsive, and the kernel stalls. Using : |
I've found a reasonably ugly workaround that gives me a running PL design. First, build a new XSA by following the steps in section IX of UG1393 (here). Don't add the AXI Interrupt Controller, it has to be initialized after each configuration which the workaround won't do. Then get the fpgautil source code (linked here) and build it for your target platform. Extract the pure bitstream from your xclbin files with Boot your fresh platform and copy the fpgautil binary, the bitstream, your host-executable and the xclbin onto your board. Before running your host code, manually configure the FPGA with I'm fairly certain, that the zocl driver in it's released and current form never loads a full bitstream; at least not on a platform that has no support for PR. |
I confirm that this workaround seems to work. I tried it for 3 examples from Vitis_Accel_Examples and for a custom kernel of my own. All run properly with correct results. Looking at kernel messages we can see:
I do not know what other side effects might exist. @FenrisTC Thanks for your help. |
Maybe not very helpful in solving your problem, but I have ran both the Vitis Hello World example and a kernel of my own using the Vitis 2019.2 flow and the official zcu104_base platform out of the box. The only possible difference in my flow which I can think is that I used |
As an update to my previous post, I think I am now encountering the same problem as the everyone else in this thread. Essentially, with the existing base platform for ZCU104, execution of code compiled with Vitis works only if the BOOT.BIN used for booting the board has the exact same FPGA bitsream as the one that is supposed to be used by the host code. If the BOOT.BIN contains a different bitstream, the OpenCL run-time will claim the FPGA has been reconfigured successfully, but then the host code either hangs or produces incorrect output in this case. |
Based on the information I have gathered so far, standard base platforms for MPSoC boards do not support run-time reconfiguration and only "dfx" platforms such as the one here do. Hence, the issue we are all facing here with the base platform for ZCU104 is not actually an issue with XRT or the base platform and things are in fact working as they should. Though of course it would be nice if XRT correctly fails to reprogram the FPGA at run-time for non-dfx platforms on MPSoC so that users do not end up running in circles trying to figure out why run-time reconfiguration doesn't actually work even though XRT claims it has been successful. |
@zohourih I confirm that. Only DFX platform can be reconfigured at runtime, and it was not a problem with XRT. I think the issue can be closed. |
Is there some mention of this in any official documentation? I couldn't find any mention that only DFX platforms are supported for acceleration on embedded platforms and there were incomplete code-paths in the zocl driver for 2019.2 that handled full bitstream programming (up to a the point I mentioned in the Issue). And from the looks of it, the current master zocl driver seems to handle full bitstreams as well, but I didn't try 2020.1 yet. |
@FenrisTC I apologize for the delay. We can see this in Vitis 2020.1 documentation section:
The situation that we observed is exactly what is mentioned in this documentation section. The PL was never programmed and only the metadata was loaded. |
Oh ok, I completely missed that, thanks for the Info! |
Hi SchuellerSe,
Hi I am trying to get this working. I want to build the hardware but I dont see anything mentioned about hardware design in the Section IX of ug1393. The link you shared doesnt work so I downloaded ug1393 from here. https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug1393-vitis-application-acceleration.pdf. Please guide. 2020.2 run: 2021.2 run: Thanks, |
I'm trying to run the hello world example from the Vitis_Accel_Examples on a custom platform based on the zcu104_base platform form the official embedded platforms.
Running
./init.sh
on the the board results in the following output:The host process never terminates and has to be terminated with .
Here is the dmesg output snippet that is produced when
./init.sh
is executed (printk loglevel is set to debug):The process seems to be stuck waiting for an interrupt that never arrives:
I think the PL never gets configured at all. Looking into zocl, the only code that
handles FPGA programming is in
zocl_fpga_mgr_load
inzocl_ioctl.c
here: https://github.com/Xilinx/XRT/blob/2019.2_RC1/src/runtime_src/core/edge/drm/zocl/zocl_ioctl.c#L193According to that procedure there should be some kernel logging happening.
If I understand the code correctly, XRT is calling the
DRM_ZOCL_READ_AXLF
ioctl when creating an OpenCL Program. The corresponding kernel procedurezocl_read_axlf_ioctl
then checks whether the platform support PR by checking if there is azdev->pr_isolation_addr
(for reference: https://github.com/Xilinx/XRT/blob/2019.2_RC1/src/runtime_src/core/edge/drm/zocl/zocl_ioctl.c#L577 ).According to the comment directly above the check the pr_isolation_addr should be configured in the device tree. I can't find it in any *.dts(i) files of the *_base platforms. It's only configured for the
zcu102_base_dfx
platform.Given that the _base platforms aren't build for PR, is there a way to use them with XRT?
The text was updated successfully, but these errors were encountered: