Tight packing

[definelicht]

Support for lower-than-1-byte types to be tightly packed in DataPack implemented by @derpda.

[definelicht]

@derpda This is what I was talking about, just adding a kernel that can is run through HLS to make sure that it synthesizes correctly.

[derpda]

I see, that was simpler than I thought... Thank you!
I didn't find the time to understand the test framework for HLS, but it looks like you have a great system set up here.

In other news, my code now works with the new tight DataPack! I don't quite understand what went wrong, but changing a part (seemingly) unrelated to the DataPack changes made it work again.

Should we add more tests to this regardless?

[definelicht]

It's okay like this unless you found something that could cause the issue in your code that we should check for

[derpda]

I do see the expected (in my case significant) decreases in BRAM and URAM usage, and the code works so that's great.
However one thing I am noticing is that (with the otherwise exact same code) my DSP usage goes way up (almost doubles).
There could probably be many reasons for this, but might there be something in the change we made here that could cause such an increase?

[derpda]

It must have something to do with the to_range and from_range functions, but I don't see how they would be using DSPs.
Could inlining help? I'm a bit out of my depth here I think.

[definelicht]

You can provide the exact minimal example where you see this happening

[definelicht]

Could you provide the code so we can take a look at what's going on?

[derpda]

Sorry, it was a holiday weekend over here!
I am having difficulty reproducing the issue in a minimal code.
Maybe HLS just failed at some optimization for my particular application code, leading to the difference?
Even in my full application I cannot tell for sure if it always causes that problem.
I doubled the size of my central systolic array and the number of DSPs used did not increase (which is strange, that array uses most of my resources).

Either way, you can find the (fairly) minimal example I was tinkering with here:
https://github.com/derpda/tight_pack_minimal
Configuration can be done as follows:
cmake -DTIGHT_PACKING=<ON|OFF> -DPLATFORM=<platform>..
This will switch the git branch used for the download of hlslib.
If you want to try it, make sure to use separate build folders since running cmake again with a changed TIGHT_PACKING doesn't re-download hlslib.

[definelicht]

Sorry, it was a holiday weekend over here!

Of course, no worries.

In the diff I get, the tightly packed version seems to use less LUTs, FFs, and BRAM, and does not change the DSP usage (left is master, right is tight-packing):

diff.txt

To me this looks exactly like what I'd expect. What was your concern?

[definelicht]

By the way, check out the new add_vitis_kernel and add_vitis_program, maybe they're useful to you

[derpda]

Well, like I said I had trouble reproducing the issue.

HLS compilation and linking is kind of an opaque process, so it's hard to say why it caused the increased usage in my code.
I cannot come up with a reason why it would have caused increased usage, but for some reason it did.
However with some recent changes to my code (that should not be related) usage miraculously went back down so I think we are good here.

[derpda]

And thank you for the tip about add_vitis_kernel and add_vitis_program! I'll check it out.