Vitis accelerator

[axiotisk]

Description

The Vitis Accelerator Backend builds upon the foundation laid by the Vitis backend and streamlines the generation process for PCIe accelerators using the Vitis Accelerator Flow.
Features:

• This backend inherits from the Vitis backend, ensuring compatibility with existing workflows and projects.
• Converts the input of the top-level design from AXI Stream to memory-mapped and the output from memory-mapped to AXI Stream.
• Automates the generation of host code and the necessary makefile for kernel compilation.
• Please note that the software and hardware emulation features are still a work in progress and will be added in subsequent commits.

Type of change

For a new feature or function, please create an issue first to discuss it
with us before submitting a pull request.

Note: Please delete options that are not relevant.

• Bug fix (non-breaking change that fixes an issue)
• Documentation update
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• A new research paper code implementation
• Other (Specify)

Tests

The backend has been tested with the hls4ml getting started tutorial example.

Test Configuration:
The Vitis version used for the validation is 2022.2.
The functionality of the project was tested on a VCK5000 accelerator board.

Checklist

• I have read the guidelines for contributing.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have installed and run pre-commit on the files I edited or added.
• I have added tests that prove my fix is effective or that my feature works.

[qberthet]

This method has been added to enable performing predictions directly on the FPGA from the Python code. It feels a bit intrusive to add this backend-specific code to the hls4ml core. Another approach could be to modify predict() to allow backend-specific overloading. So, model.hardware_predict(x) could become model.predict(x, target='hw'), but this also requires some modification of the existing core code. Could an hls4ml dev provide advice on the best approach here? (@vloncar, @jmitrevs?). Thanks!

[vloncar]

I would be in favor of naming this somewhat different (predict_hw for example) and moving the exception to backends (in FPGABackend should be enough to cover those that don't/cannot support it).

Some longer term idea here would be that we would have 3 ways of doing preciction: predict_emu (emulation, the current one), predict_sim (simulation via pyverilator) and predict_hw (real deal), with the predict being predict_emu by default with maybe a switch for user to control which one is called if it's just predict(x).