Optimize Structures for Performance

C code can contain descriptions that prevent a function or loop from being pipelined with the required performance. This is often implied by the structure of the C code or the default logic structures used to implement the PL logic. In some cases, this might require a code modification, but in most cases these issues can be addressed using additional optimization directives.

The following example shows a case where an optimization directive is used to improve the structure of the implementation and the performance of pipelining. In this initial example, the PIPELINE directive is added to a loop to improve the performance of the loop.

#include "bottleneck.h" dout_t bottleneck(din_t mem[N]) { dout_t sum=0; int i; SUM_LOOP: for(i=3;i


          When the code above is compiled into hardware, the following message appears as output:
          INFO: [SCHED 61] Pipelining loop 'SUM_LOOP'. WARNING: [SCHED 69] Unable to schedule 'load' operation ('mem_load_2', bottleneck.c:62) on array 'mem' due to limited memory ports. INFO: [SCHED 61] Pipelining result: Target II: 1, Final II: 2, Depth: 3. I
          The issue in this example is that arrays are implemented using the efficient block RAM resources in the PL fabric. This results in a small cost-efficient fast design. The disadvantage of block RAM is that, like other memories such as DDR or SRAM, they have a limited number of data ports, typically a maximum of two.
          In the code above, four data values frommemare required to compute the value ofsum. Becausememis an array and implemented in a block RAM that only has two data ports, only two values can be read (or written) in each clock cycle. With this configuration, it is impossible to compute the value ofsumin one clock cycle and thus consume or produce data with an II of 1 (process one data sample per clock).
          The memory port limitation issue can be solved by using the ARRAY_PARTITION directive on thememarray. This directive partitions arrays into smaller arrays, improving the data structure by providing more data ports and allowing a higher performance pipeline.
          With the additional directive shown below, arraymemis partitioned into two dual-port memories so that all four reads can occur in one clock cycle. There are multiple options to partitioning an array. In this case, cyclic partitioning with a factor of two ensures the first partition contains elements 0, 2, 4, etc., from the original array and the second partition contains elements 1, 3, 5, etc. Because the partitioning ensures there are now two dual-port block RAMs (with a total of four data ports), this allows elements 0, 1, 2, and 3 to be read in a single clock cycle.
          
           Note:The ARRAY_PARTITION directive might not be used on arrays which are internal to the function and not function arguments.
          
          #include "bottleneck.h" dout_t bottleneck(din_t mem[N]) { #pragma HLS ARRAY_PARTITION variable=mem cyclic factor=2 dim=1 dout_t sum=0; int i; SUM_LOOP: for(i=3;i

          Other such issues might be encountered when trying to pipeline loops and functions. The following table lists the directives that are likely to address these issues by helping to reduce bottlenecks in data structures.
          
           
            
             Table 1.Optimization Strategy Step 3: Optimize Structures for Performance
            
            
             
             
            
            
             
              Directives and Configurations
              Description
             
            
            
             
              ARRAY_PARTITION
              Partitions large arrays into multiple smaller arrays or into individual registers to improve access to data and remove block RAM bottlenecks.
             
             
              DEPENDENCE
              Provides additional information that can overcome loop-carry dependencies and allow loops to be pipelined (or pipelined with lower intervals).
             
             
              INLINE
              Inlines a function, removing all function hierarchy. Enables logic optimization across function boundaries and improves latency/interval by reducing function call overhead.
             
             
              UNROLL
              Unrolls for-loops to create multiple independent operations rather than a single collection of operations, allowing greater hardware parallelism. This also allows for partial unrolling of loops.
             
             
              Config Array Partition
              This configuration determines how arrays are automatically partitioned, including global arrays, and if the partitioning impacts array ports.
             
             
              Config Compile
              Controls synthesis specific optimizations such as the automatic loop pipelining and floating point math optimizations.
             
             
              Config Schedule
              Determines the effort level to use during the synthesis scheduling phase, the verbosity of the output messages, and to specify if II should be relaxed in pipelined tasks to achieve timing.
             
             
              Config Unroll
              Allows all loops below the specified number of loop iterations to be automatically unrolled.
             
            
           
          
          In addition to the ARRAY_PARTITION directive, the configuration for array partitioning can be used to automatically partition arrays.
          The DEPENDENCE directive might be required to remove implied dependencies when pipelining loops. Such dependencies are reported by message SCHED-68.
          @W [SCHED-68] Target II not met due to carried dependence(s)
          The INLINE directive removes function boundaries. This can be used to bring logic or loops up one level of hierarchy. It might be more efficient to pipeline the logic in a function by including it in the function above it, and merging loops into the function above them where the DATAFLOW optimization can be used to execute all the loops concurrently without the overhead of the intermediate sub-function call. This might lead to a higher performing design.
          The UNROLL directive might be required for cases where a loop cannot be pipelined with the required II. If a loop can only be pipelined with II = 4, it will constrain the other loops and functions in the system to be limited to II = 4. In some cases, it might be worth unrolling or partially unrolling the loop to creating more logic and remove a potential bottleneck. If the loop can only achieve II = 4, unrolling the loop by a factor of 4 creates logic that can process four iterations of the loop in parallel and achieve II = 1.
          The Config commands are used to change the optimization default settings and are only available from within Vivado HLS when using a bottom-up flow. Refer toVivado Design Suite User Guide: High-Level Synthesis(UG902) for more details.
          If optimization directives cannot be used to improve the initiation interval, it might require changes to the code. Examples of this are discussed inVivado Design Suite User Guide: High-Level Synthesis(UG902).

Directives and Configurations	Description
ARRAY_PARTITION	Partitions large arrays into multiple smaller arrays or into individual registers to improve access to data and remove block RAM bottlenecks.
DEPENDENCE	Provides additional information that can overcome loop-carry dependencies and allow loops to be pipelined (or pipelined with lower intervals).
INLINE	Inlines a function, removing all function hierarchy. Enables logic optimization across function boundaries and improves latency/interval by reducing function call overhead.
UNROLL	Unrolls for-loops to create multiple independent operations rather than a single collection of operations, allowing greater hardware parallelism. This also allows for partial unrolling of loops.
Config Array Partition	This configuration determines how arrays are automatically partitioned, including global arrays, and if the partitioning impacts array ports.
Config Compile	Controls synthesis specific optimizations such as the automatic loop pipelining and floating point math optimizations.
Config Schedule	Determines the effort level to use during the synthesis scheduling phase, the verbosity of the output messages, and to specify if II should be relaxed in pipelined tasks to achieve timing.
Config Unroll	Allows all loops below the specified number of loop iterations to be automatically unrolled.