Vitis HLS Debugging Tips

Article by Akshay Kamath. Last updated on February 26, 2022.

If you've worked with Vitis HLS, you probably already know how Vitis HLS can at times be, for the lack of a better word, quirky. If you're new to this tool, well, here's a heads up - Vitis doesn't always behave the way you expect it to. You need to write your HLS code in a way that Vitis HLS wants you to.

So, in this article, we list down a few tips that may be useful to you in your journey with Vitis HLS. These tips are in no way exhaustive and are simply based on the collective experiences of Sharc Lab members who've spent quite some time playing around with this tool.

Tip 0: Functionality first

Never EVER EVER EVER EVER run synthesis without ensuring functional correctness!

Imagine this. You make some innocent-looking change to your code (say changing += to just = somewhere) which you feel is functionally correct, run HLS and see a too-good-to-be-true latency or resource estimate only to realise later that the simulation fails. For this, you can't blame Vitis.

So please, even though this tip sounds like common sense, please be conscious of it whenever you make any changes to your code.

Tip 1: Floating-point for Quicker Simulation

Fixed-point is simulated in CPU but CPU is not optimized for fixed-point simulation. This makes fixed-point simulation slow.

Use ifdefs in your code to run simulation with floating-point and synthesis with fixed-point.

Tip 2: Label your Loops

Allows you to analyze synthesis reports better.

Tip 3: Use Low-precision Data-types

Synthesis with 32-bit fixed-point is slower than synthesis on the same code with 16-bit fixed-point data type. Resource utilization is also lower.

Tip 4: Loop Order Matters

If your code doesn't behave the way you expect it to, try changing the loop order and check again!