Forum Discussion
New ContributorHow does AOC compiler map fixed point MAC operations to DSP ip blocks?
With 16.1.2, whether DTYPE is short or int, as long as partial_sum is int, I get 1024 DSPs for j=512.
Based on what you are saying, it seems the OpenCL compiler (v17+) does not correctly instantiate the IPs and infers 32-bit MULs instead of 16-bit ones (while the estimation in the report is based on 16-bit MULs), and for j > 759, since it thinks DSPs are fully utilized, it instantiates the logic-based IP instead of the DSP-based one . For cases where j <= 759, it seems the mapper is smart enough to pack the operations properly and reduce DSP usage, but for j > 759, since the compiler has instantiated logic-based IP, the mapper does not convert the logic-based IP to DSP-based and you get high logic usage but low DSP utilization.
I tested all the way to v18.1. With DTYPE=short and partial_sum defined as int, the DSP usage gets capped at 379 (379.5 actually!!!) for j > 759 and the rest of the operations are mapped to logic. However, with both defined as short, 17.0+ seems to correctly map two MULs per DSP but DSP usage gets capped at 50% this time. It seems there is still some code somewhere in the compiler (probably the linker) that has not been updated correctly with the new way DSP mapping happens, and is still using the old codes (pre-17.0) of two DSPs per MUL for DTYPE=short and partial_sum=int, and one DSP per MUL for DTYPE=short and partial_sum=short.
It is certainly possible to use all the DSPs on Arria 10 with 16-bit arithmetic. For example, you can look at the paper from Altera which claims to do so in OpenCL and another one which does so using an HDL library wrapped in OpenCL (both linked in the other thread). The behavior you are observing here seems to be a bug in the OpenCL compiler.
Frequent ContributorAs I also mentioned in the other thread (though the usernames have not been carried over after the forum was moved from Altera to Intel), you CANNOT do two MACs per DSP on Arria 10, regardless of bit width, since each DSP has only one adder. You can, however, do two 18-bit (or smaller) MULs per DSP.
In your case, since your reduction variable (partial_sum) is int, all the computation is treated as int regardless of DTYPE. The integer additions are mapped to logic, while each integer multiplication uses 2 DSPs. Hence, j = 512 uses 1024 DSPs in reality, and j > 759 will fully utilize the DSPs with all the extra MULs mapped to logic. This is also exactly what the report from v16.1.2 shows. The report in 17+ seems to be broken when it comes to estimating the DSP usage in such cases (add this to the huge list of things that were broken in the transition from 16.1 to 17). I tried to see if I can get the DSP usage down by bit masking but in my quick test, it did not seem to work. The only thing that seemed to work was defining partial_sum as short. In that case, I got one MUL per DSP (but not two).
At the end of the day, the numbers in the report are estimations. The mapper might actually be able to correctly pack the operations and reduce the number of DSPs that are used. You should try place and routing the design to see what happens. You might have better luck using the new Arbitrary Precision Integers (Programming Guide, Section 5.6) extension.
