Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A lot of changes are necessary to make Multi-FPGA possible happen in VitisBuild. Since the aim is to improve this transformation in general, I'll make these changes on a separate branch so that we can all benefit from it before Multi-FPGA is fully merged.
Currently VitisBuild is a collection of string-concatinations that make certain assumptions of what the dataflow graph looks like. This very much made sense at the time because, as is officially mentioned as well, you usually want to integrate the stitched IP into your own custom design, so this step is not required for many users. However, to make it a viable tool for any user we want to be able to input an ONNX file and get a bitstream out of it. Both for Multi-FPGA and generally more complex dataflow graphs (for example multiple output heads etc.) this current flow won't work.
To fix this, I'll implement a new VitisBuild flow. One class keeps track of the configuration for a design. It can be used via it's method and avoids tedious string concatenation for it's user. The VitisLink transformation itself will be changed too. You start with an empty configuration and add components that are automatically connected via AXI streams. You pass what component you want to add, it will add it and return the new endpoint to attach new components to. This also has the benefit that measurement kernels, network communication kernels, etc. can all be included easily afterwards, without changing the entire build flow.