[Draft] runtime: Add initial Xilinx Runtime Library (XRT) support

[xerpi]

To be used in the future when a path to generate xclbin files (Xilinx FPGA bitstream format) from Halide kernels exists.
A possible start to this future path is MR #7587, which adds MLIR generation.
After generating MLIR code, CIRCT could be used to generate RTL code.

[antonysigma]

@xerpi I am not the reviewer, but I like the CIRCT/XRT idea. As a former Xilinx-accelerated algorithm developer, the pain is to develop a custom linux kernel driver in the programmable system (PS) that talks to the programmable logic (PL).

One example is the spinoff Halide-HLS project, which requires a complete userspace/kernelspace software stack to function: https://github.com/stevenbell/ultrazynqbuilder

Could you please elaborate more on the target use case? Is it for cloud FPGA (e.g. AWS F1), or for embedded FPGA (e.g. Zynq or Versal with Yocto). They have a different architecture.

[xerpi]

@xerpi I am not the reviewer, but I like the CIRCT/XRT idea. As a former Xilinx-accelerated algorithm developer, the pain is to develop a custom linux kernel driver in the programmable system (PS) that talks to the programmable logic (PL).

One example is the spinoff Halide-HLS project, which requires a complete userspace/kernelspace software stack to function: https://github.com/stevenbell/ultrazynqbuilder

Could you please elaborate more on the target use case? Is it for cloud FPGA (e.g. AWS F1), or for embedded FPGA (e.g. Zynq or Versal with Yocto). They have a different architecture.

Thanks for the feedback!
Indeed, XRT is a very nice too since it provides not only a way to launch kernel in the variety of Xilinx devices but also to manage them in a common way.

XRT can target both PCIe and embedded FPGA devices, therefore both targets are supported. In my particular case I was using an embedded Zynq device.

[steven-johnson]

Looks good so far, with some style nits and some details about error handling. How will this be tested?

[xerpi]

Looks good so far, with some style nits and some details about error handling. How will this be tested?

Thanks for the code review!

Currently, there's no way to test it (also that's why it's a Draft).
This is one end of the flow that needs to be implemented to execute Halide kernels on (Xilinx) FPGAs.
The opposite end of such a flow would be to generate MLIR from Halide IR (#7587), which in turn can be converted to RTL by using CIRCT and/or Calyx, or to HLS by using projects such as https://github.com/hanchenye/scalehls.
Check calyxir/calyx#1585 for more information.

[steven-johnson]

OK, so it's pending on (at least) #7587, but I'm not sure what that one is pending -- left a comment there.