[Feature] Update HLS backend/Host Code Emmision to support later versions of Xilinx toolchain

[aross50]

Is your feature request related to a problem? Please describe.
I'm a member of Dr. Pal's lab at UIC. The system we are using Allo on is running a recent version of the Xilinx toolchain (2024.1 for vitis, vitis_hls, vivado, and xrt). Based on the tutorials/backend design, the Zhang group uses the 2019.2.1 versions at least some of these tools.

Vivado_HLS stopped being released after the 2020.1 release.. Instead the entirety of Xilinx's HLS compilation flow is done through Vitis_HLS now, but Allo's hls backend does not support calling/performing some of the features that have migrated to vitis_hls directly. One major example is the generation of csynth reports of hardware designs, which can still be done with vitis_hls using tcl commands.

Similarly, the 2023.1 release of xrt is the last one to support the XCL API. This means that the host.cpp code emitted by Allo is not compatible with the xrt library that we are using nor the corresponding deployment target platform for our board.

Describe the solution you'd like
The ideal solution would be some form of version check in the hls backend that would allow for different users/systems to utilize whatever version of the xilinx (or other external) toolchains they are on, while all still using the same version/distribution of Allo to keep bug tracking/revisions consistent.

Additional context
As noted above, some of the features have simply moved from vivado_hls to vitis_hls. For example I have been able to generate csynth reports with the emitted run.tcl file found in allo built .prj files. For the sake of testing this was done with the HLS code generated from tutorial_02_vhls.py, to ensure that any errors or odd behaviors were due to differences in systems/tools instead of code error from the front end.

Sometimes the tcl needs light modification, specifically to ensure that the set_part {*part-serial*} is actually correct for the target $XDEVICE (it isn't always gathered correctly to this file due to this being a work around method and not a direct call through allo). The only other modification is to ensure that csynth_design is un-commented. The csynth reports can then be generated by calling $vitis_hls -f run.tcl in the command line.

I tried to perform a similar workaround to perform csim of the model, un-commenting csim_design -O instead, but running those resulted in the errors telling me that all of the XCL methods were not defined, which is what lead me to learn that the XCL API is no longer part of the the XRT library.

[chhzh123]

Hi @aross50, thanks for raising the issue. We indeed have the vitis flow as our backend, please checkout systolic array example for doing simulation and building the bitstream with vitis. We'll also provide a detailed document for the vitis backend soon.

We are internally using both Vivado 2019.2 and Vitis 2022.1 toolchains for our designs, and most of the features should be supported by Allo. Could you please tell us what specific features are missing in your context? Also, what kind of changes do we need to make to support 2024.1? Thx!

[aross50]

Hello @chhzh123, thanks for the response! I apologize in my delay for getting back to you.

I suppose I misspoke a bit, as I did see that allo has support for vitis_hls, it just seems that it is not complete support for all of its features. As I was mentioning in my initial post for example, I can't directly call csyn as a valid mode for vitis_hls, as it is excluded in the accepted modes in the backend even though vitis_hls is capable of running csynth as well.

I suppose the more pressing issue though is actually the XCL/XRT incompatibility of the newest XRT versions. Allo currently uses xcl2.hpp/cpp as the shared memory interface/manager for generated host.cpp code. This means that any attempts to simulate or run the code fail, as our versions of vitis/XRT don't provide the necessary include files for the xcl namespace.

It seems the biggest change that would be needed for us is an update to the host.cpp code emitter, so that it can emit code that uses current XRT interface calls instead of the deprecated XCL ones. That said I don't want these needs to break your established toolchains either, so I think it would be great if there was some way of the emitter either checking for XRT versions available and outputting in response to that, or to have some way of flagging which emitter to use.

I hope I was able to clarify some, and please let me know if there's any more information I can provide for you!