Adding Alveo V80 support by adding Slash/V80++ as a new build target

[JOOpdenhoevel]

This PR adds support for the Alveo V80 accelerators by adding Slash, more precisely V80++, as a new build target or backend.

The necessary steps to build accelerators with Slash are generally similar to Vitis. I've therefore turned the previous VitisBuild transformation into a PrepareLinking transformation that does all the floor-planning and IP stitching, but not the actual linking. This then has to be done separately with the VitisLink or SlashLink transformations. Similarly, I've also split the test_build step in the end-to-end BNN test into the steps test_prepare_for_linking, test_linking, and test_annotate_resources to test these transformations individually. I've also ported the XRT-based C++ driver application to VRT as a proof of concept (Link to ported driver) and modified the MakeCPPDriver transformation to use it.

The V80++ toolchain is installed in the docker container from a .deb package, which is assumed to reside in deps/v80++_0.1_all.deb during container setup. During runtime, the SlashLink only creates a temporary directory for the connectivity configuration, the build directory for the v80++ linker, and the final VBIN container file. This is an improvement over cloning the entire SLASH repository, building the entire reference design and service region, and only then building the user region, but it poses a new and still-open challenge: How should we deliver the Debian package to the users? As far as I understand it, we are not able to publish binary packages for SLASH since they would include parts of AVED. Building the package from source during container setup also appears infeasible to me since it takes multiple hours.

Also, I have changed some naming conventions in the code base. Previously, both the terms "Alveo" and "Vitis" would relate to the Vitis-based flow targeting UltraScale-based Alveo accelerators, but this doesn't fit anymore since the V80 is also marketed as an Alveo card. Now, "Alveo" should relate to the line of datacenter cards in contrast to the embedded Zynq devices, and "Vitis/XRT" relates to the toolchain of Vitis and XRT to target UltraScale-based Alveo cards in contrast to "Alveo/VRT" for Versal-based Alveo cards. However, I'm not 100% sure that this is already applied everywhere consistently, and this difference should also be present in the documentation.

Lastly, I haven't verified the correctness with hardware since Slash is not quite there yet. However, the example networks in the VRT driver work exactly as expected in simulation.

To reiterate, the currently open to-dos are:

• Update documentation, especially regarding the terms "Alveo", "Vitis/XRT", and "Slash/VRT"
• Find a way to provide the v80++ .deb package
• Verify correctness in hardware

[JOOpdenhoevel]

I was able to get a FINN accelerator running on a V80 at Paderborn Center for Parallel Computing, but the outputs where all zeroes. To eliminate any intermediate bugs in FINN that have been fixed since the last pull from dev, I've updated this branch to dev, made some small fixes the SlashLink transformation, and tried to build the example models identity_net and single-layer-linear from the FINN VRT driver application, using the ./run-docker.sh build_custom command.

However, FINN now fails at the "set FIFO depths" step, which was not an issue before. In particular, it fails at stitching IP cores for simulation with the error message:

Starting static elaboration
Pass Through NonSizing Optimizer
ERROR: [VRFC 10-2063] Module <ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1_ip> not found while processing module instance <ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1_ip_u> [${FINN_TEMP_FILES}/vivado_stitch_proj_a4af949b/finn_vivado_stitch_proj.gen/sources_1/bd/finn_design/ipshared/7835/hdl/verilog/ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1.v:29]
ERROR: [VRFC 10-2063] Module <ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1_ip> not found while processing module instance <ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1_ip_u> [${FINN_TEMP_FILES}/vivado_stitch_proj_a4af949b/finn_vivado_stitch_proj.gen/sources_1/bd/finn_design/ipshared/7835/hdl/verilog/ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1.v:30]
ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design unit(s) in library work failed.

The configured sanity BNN integration test for the V80 runs just fine, including the "set FIFO depths" step.

Is this a known issue or is someone available to debug this issue?

[auphelia]

I was able to get a FINN accelerator running on a V80 at Paderborn Center for Parallel Computing, but the outputs where all zeroes. To eliminate any intermediate bugs in FINN that have been fixed since the last pull from dev, I've updated this branch to dev, made some small fixes the SlashLink transformation, and tried to build the example models identity_net and single-layer-linear from the FINN VRT driver application, using the ./run-docker.sh build_custom command.

However, FINN now fails at the "set FIFO depths" step, which was not an issue before. In particular, it fails at stitching IP cores for simulation with the error message:

Starting static elaboration
Pass Through NonSizing Optimizer
ERROR: [VRFC 10-2063] Module <ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1_ip> not found while processing module instance <ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1_ip_u> [${FINN_TEMP_FILES}/vivado_stitch_proj_a4af949b/finn_vivado_stitch_proj.gen/sources_1/bd/finn_design/ipshared/7835/hdl/verilog/ElementwiseMul_hls_0_fmul_32ns_32ns_32_1_primitive_dsp_1.v:29]
ERROR: [VRFC 10-2063] Module <ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1_ip> not found while processing module instance <ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1_ip_u> [${FINN_TEMP_FILES}/vivado_stitch_proj_a4af949b/finn_vivado_stitch_proj.gen/sources_1/bd/finn_design/ipshared/7835/hdl/verilog/ElementwiseMul_hls_0_sitofp_32s_32_3_no_dsp_1.v:30]
ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design unit(s) in library work failed.

The configured sanity BNN integration test for the V80 runs just fine, including the "set FIFO depths" step.

Is this a known issue or is someone available to debug this issue?

Yes, that looks like a version issue. Which Vivado version are you trying to use?

[JOOpdenhoevel]

I am using 2025.1, since this is the only version that SLASH currently supports.

[JOOpdenhoevel]

Good news! When merged with the current changes in #1528, building and running the identity_net example with my C++ driver fork works in hardware!

The only thing that's not as expected is that FINN exports the input and output data types as Finn::DatatypeFloat<32>, although this type isn't a templated type either in my version of the driver, or in the main or dev versions of the VRT-based C++ driver. Truncating the template arguments and just using Finn::DatatypeFloat however works just fine. Is this an issue that should be fixed in FINN or in the driver application?

[auphelia]

The only thing that's not as expected is that FINN exports the input and output data types as Finn::DatatypeFloat<32>, although this type isn't a templated type either in my version of the driver, or in the main or dev versions of the VRT-based C++ driver. Truncating the template arguments and just using Finn::DatatypeFloat however works just fine. Is this an issue that should be fixed in FINN or in the driver application?

I am not sure where this value gets set, I will have a look. @LinusJungemann or @bwintermann, do you have an idea?

[bwintermann]

Since the bitwidth for DatatypeFloat is fixed to 32 in the driver, I'd assume that the FINN side of things is out of sync with the driver and it was never meant to be templated. But @LinusJungemann will know more since he wrote the whole Datatype section.

[LinusJungemann]

It looks like this is a bug in MakeCppDriver. This should just be Finn::DatatypeFloat. I think changing this should fix it. If not, I can look into it more after the end of my vacation next week.

[JOOpdenhoevel]

I've fixed the type exports in MakeCPPDriver. The full stack works now.

[auphelia]

Hi @JOOpdenhoevel,
Thanks for this! It looks good to me, I also like how you solved the naming conflicts with alveo, I think it's more consistent this way. It's a really cool feature to be able to target V80 now directly with FINN networks!