-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"target-spec.ini" missing "reg/ff"? #33
Comments
Hi @eeriecl I guess that the reason is that the number of LUT (i.e., LUT with 5 input) is the same as the number of FF on Xilinx Ultrascale/+ devices. |
Absolutely not~ |
Hi @eeriecl, currently we only support to estimate the utilization of DSP and BRAM in the QoR estimator. |
so why there's LUT specification/estimation? |
I don't think the QoR estimator is consuming the LUT specification or reporting the LUT utilization. The LUT estimation is still an open topic -- several existing papers have investigated different approaches to improve the accuracy of the LUT estimation of Vivado HLS, but due to the optimization in the synthesis stage of downstream tools, such as Vivado, the estimation is still not quite accurate :( We are also slowly improving the QoR estimator, but if you are interested to add the LUT estimating feature, please let me know what I can help! |
what if feeding scalehls-generated rtl forward to vitis-hls and run high level synthesis, then back-annotate scalehls' report? |
Hi @Oxygen-Chu, this is definitely possible! Actually another paper from our group is triggering Vitis HLS to evaluate discovered design points. The pro of this approach is Vitis HLS is more accurate and comprehensive. However, the con is Vitis HLS takes at least 1-2 minutes to compile each design point (some complicated ones need more) while our estimator only needs like seconds. We stated this in the ScaleHLS paper and made the trade-off here. However, I believe triggering Vitis HLS to guide the design space exploration of ScaleHLS is a valuable topic to investigate (worth a new paper) 😄 |
i've tried scalehls, autosa, autobridge, merlin-compiler and some other polyhedral compilers these month, and found huge space to improve. |
As we stated in the ScaleHLS paper:
Take a GEMM32 kernel as example, ScaleHLS can open a design space containing about 5 thousands design points. 1-2 minutes waiting time means the DSE can only explore less than 60 of them per hour, which can easily lead to incomprehensive DSE or long DSE time. We are having some on-going HLS projects in MLIR, such as CIRCT-HLS, which will help to reduce the compilation time to RTL in the future, making it more feasible to be used in the DSE. |
the dse engine can use multi-core, multi-threading, since each searching-space is absolutely independent. |
@Oxygen-Chu Please see my early post:
We did enable multi-threading in the recent development of that project (has not been open-sourced). As I mentioned, I believe cooperating with Vitis HLS is a valuable direction. Please try this approach if you are interested and I'd love to chat more on this. |
ok, i'd like to try more after solving issues ticketed by eeriecl (actually me :-> ) |
I see the "target-spec.ini" has following configuration. but curiously missing "reg/ff"?
The text was updated successfully, but these errors were encountered: