Conversation
|
Does this (Xilinx/finn-hlslib#154) mean we can make this point to Xilinx/finn-hlslib instead of your fork? |
|
I will try this later, probably yes. |
|
Now pointing back to Xilinx/finn-hlslib and got the radioml-transformer build passing so we do not need the fork for this. Could be merged now. We need to remember to add the necessary includes to the code generation though, as soon as we want to make use of the ap_float (and also ap_fixed) support now. But that's not a dependency issue, rather a code generation issue for affected hardware operators. |
|
@iksnagreb in the meantime other things in hlslib changed, at least one of which breaks things (the 8 failing tests): |
|
Hm, there is Xilinx#1202 (this does not really seem ready to be used though...) or maybe some solution Lucas has been working on to make this usable for one of the PG models? Otherwise we could fix this by changing the code generation to generate code for the legacy interface, which actually should not have been removed but just renamed, so we just need to rename it during code generation as well... |
|
Fixed in #40 |
After switching to the recent finn-hlslib version (dev branch), the ap_float header is included by default whenever you are using some operation which requires the flatten function (e.g. attention, elementwise-binary). However, ap_float requires Vitis HLS 2024.2 while we are still stuck on 2022.2... For now this is a workaround, I'd like to properly fix this via some feature test macros conditionally disabling compilation of the float section...