Optimize interface bandwidth by reshaping or partitioning arrays - 2024.1 English - XD261

Vitis Tutorials: Vitis HLS (XD261)

Document ID
XD261
Release Date
2024-06-19
Version
2024.1 English

Before we proceed, now is a good time to create a new component if you want to preserve the state of the existing component. Of course, this is optional.

In the previous section, we learned that 16 loads need to occur in one clock cycle to satisfy the II=1 constraint from the pipeline pragma. We can learn more about this constraint by referring to the code. Locate the read from rx_q[i][k] on line 41 and recall that loop L3 has been unrolled by the PIPELINE pragma on loop L1. This means all addresses of the second dimension of the array k need to be read in one clock cycle.

The solution to this problem is to increase the size of the interface for the variable rx_q. By default, the interface is the size of the datatype of the array, which in this case is a float, or a 32-bit floating point number. The design now requires that multiple floats are read in one clock cycle, and this bandwidth can be provided with either the ARRAY_RESHAPE or ARRAY_PARTITION pragma, which either widen or duplicate the interface, respectively. The choice is mostly a matter of preference. In this case, we’ll use the ARRAY_RESHAPE pragma:

  1. Add the compiler directive #pragma HLS ARRAY_RESHAPE variable=rx_q dim=2 type=complete

By inspection of the code, we can tell that the same optimization will be required for the imaginary portion of rx, contained in rx_i, so we’ll add the corresponding pragma as well:

  1. Add the compiler directives #pragma HLS ARRAY_RESHAPE variable=rx_i dim=2 type=complete

  2. Run C Synthesis once more and open the Synthesis Report to confirm the II Violation is gone, albeit replaced by another, similar II violation:

Synthesis Report showing II Violation on Loop L1

At this point, you should be familiar with the process for investigating and solving this issue. From the synthesis report, right-click the II violation to view the schedule viewer. The schedule viewer shows the load or store which causes the II violation, in this case beamso_i. Referencing the source code shows us a store operation that requires multiple stores due to an unrolled loop.

  1. Add the compiler directives #pragma HLS ARRAY_RESHAPE variable=beamso_i dim=2 type=complete and #pragma HLS ARRAY_RESHAPE variable=beamso_q dim=2 type=complete

  2. Again, run C Synthesis and open the Synthesis Report to confirm the II Violation is gone and that there are no other II violations.