config.json and design size estimation

[SerenaC94]

As far as I understand, the config.json file has information about the target FPGA (number of DSPs etc) that are used by scaleHLS to optimize kernels. What is the target board? How should I change the config file to target a different one?

I run all steps after HLS on polybench kernels optimized by scaleHLS (logic synthesis/implementation/place&route) targeting a very large board with ~2k DSPs, and on a 16x16 gemm the p&r step fails because the design is too large. Is this because the estimates are based purely on HLS, not considering the actual implementation steps?

[hanchenye]

Hi @SerenaC94, the default config.json is for pynq-z1 board. Typically you should be able to update the resource constraints in it to target different boards.

I run all steps after HLS on polybench kernels optimized by scaleHLS (logic synthesis/implementation/place&route) targeting a very large board with ~2k DSPs, and on a 16x16 gemm the p&r step fails because the design is too large. Is this because the estimates are based purely on HLS, not considering the actual implementation steps?

We are taking Vivado HLS results as ground truth. So similar to Vivado HLS, ScaleHLS is not able to capture some physical-level characteristics for now. But your question brings up an interesting topic that we are beginning to investigate: layout-aware HLS. There're several papers several years ago from our group:

1. FastYield: Variation-Aware, Layout-Driven Simultaneous Binding and Module Selection for Performance Yield Optimization
2. LOPASS: A Low-Power Architectural Synthesis System for FPGAs With Interconnect Estimation and Optimization

Hope these papers are helpful. Since I'm also new to this "area", please let me know if you have any questions or want to discuss.

[makslevental]

layout-aware HLS

If I understand correctly, then another paper/project in this area is https://github.com/Licheng-Guo/AutoBridge. While not exactly targeting the binding/resource budget problem, they are solving problems related to layout/floorplanning

we prevent the Vivado placer to place the logic too densely.

[hanchenye]

If I understand correctly, then another paper/project in this area is https://github.com/Licheng-Guo/AutoBridge. While not exactly targeting the binding/resource budget problem, they are solving problems related to layout/floorplanning

Right, the two papers I mentioned are more along the line of using wire length information and etc from the floorplanning result/estimation to guide the binding of HLS.

[SerenaC94]

Another question about the config.json file: is it possible to constrain/tune loop pipelining? I see there is an option to control the amount of loop unrolling, and the pipelining pragma in vivado also has some tunable options if I remember correctly, so I was wondering if the DSE engine explores those as well.