Open makslevental opened 2 years ago
FWIW rewinding to https://github.com/hanchenye/scalehls/commit/d6ffcd0c5b2fa67c624a500365a3cc95942d91c0 and running with -scalehls-pytorch-pipeline="top-func=forward dataflow-gran=0 opt-level=2"
(i.e., completely disabling dataflow) does fix the issue and the synthesis goes all the way through.
This is an error that I've never seen. But it seems Vivado has recognized all the dataflow stages, which is a good sign :) Thanks for providing the artifacts, will have a try on them.
It would be good to capture this for the vitis hls folks: if you have the source code and TCL that fails?
It would be good to capture this for the vitis hls folks: if you have the source code and TCL that fails?
@stephenneuendorffer I think all of the artifacts should be enough for repro but I can provide whatever else is needed.
Does this mean scaleHLS is guaranteed to work with Vivado, but not with Vitis?
Does this mean scaleHLS is guaranteed to work with Vivado, but not with Vitis?
Same question. I found the test_gemm_dse.cpp
in the README also could not pass the vitis_hls compilation, since it tried to partition the input array with interface specification. My vitis_hls version is v2019.2.1.
I found the test_gemm_dse.cpp in the README also could not pass the vitis_hls compilation, since it tried to partition the input array with interface specification. My vitis_hls version is v2019.2.1.
I have also observed this issue. From a specific version, Vitis has renamed the "resource" directive to "bind_op" and "bind_storage" directives. Meanwhile, "bind_storage" is no longer allowed to be applied on interface arrays. Instead, the "storage_impl" and "storage_type" options are merged into the "interface" directive.
A temporary solution to adapt Vitis HLS is updating the emission logic here: https://github.com/hanchenye/scalehls/blob/4acb8795839dd2ba291733a521f2646db756edd2/lib/Translation/EmitHLSCpp.cpp#L1751-L1754
Ultimately, I'd think to have a target triple for the C++ emitter to specify the vendor tool and version of emission.
Ultimately, I'd think to have a target triple for the C++ emitter to specify the vendor tool and version of emission.
probably ultimately @stephenneuendorffer and Xilinx should just buy ScaleHLS 😉
Description
Tried to ScaleHLS+Vitis a simple model using the instructions in the README, namely
and got this on Vitis v2021.2:
with stack dump:
Dropping
#pragma HLS dataflow
both in forward and inforward_node19
doesn't fix but produces a different segfault:with different stack dump:
Let me know if there's anything I can do to help debug.
Artifacts