Well, here is how it works: With char, every MUL should take half a DSP, but the compiler calculates DSP usage internally using int which requires 2 DSPs per MUL. Hence, it thinks DSPs are over-utilized as soon as you hit the 25% mark (which would be equal to 100% DSP utilization if you were actually using int) and maps everything else to logic. With your new method, again each MUL is using half a DSP but the internal calculation is using one MUL per DSP and hence, over-utilization is detected internally at 50% DSP usage. Now, if you do place and route the design and the mapper does its job correctly, you will get 25% or 50% DSP utilization in the end but the extra operations which were mapped to logic by the OpenCL compiler will not be remapped to DSPs... Essentially, because of this bug, I don't think it is possible to fully use the DSPs with low-precision data types in OpenCL...
If you want, you can use as many PEs as would fit in the 50% DSP utilization limit with your current data type and just place and route it; that would give you the same OP/s as using a larger data type that would use one DSP per MUL. But of course the whole point of using lower precision is to be able to achieve higher OP/s; yet, that does not seem to be possible with the current versions of the compiler. And I don't think think bug has ever been fixed, nor do I understand how is it that the whole world is not reporting this bug to Intel considering the number of people who are doing low-precision AI/DL on FPGAs these days.
P.S. You can also experiment with bit masking but no guarantees it would change anything. I remember I had a long discussion with someone else on the forum on this topic for which I also did some coding and experimentation and reported the results, but I do not seem to be able to find the thread anymore. Using HDL libraries could bypass the issue altogether, though, if you are willing to go through the trouble of implementing it.
