The Intel^® HLS Compiler Pro Edition Reference Manual provides reference information about the features supported by the Intel^® HLS Compiler Pro Edition. The Intel^® HLS Compiler is sometimes referred to as the i++ compiler, reflecting the name of the compiler command.

To see what versions of GCC and Microsoft Visual Studio the Intel^® HLS Compiler supports, see " Intel^® High Level Synthesis Compiler Prerequisites" in Intel^® High Level Synthesis Compiler Getting Started Guide.

The interoperability between GCC or Microsoft Visual Studio, and the Intel^® HLS Compiler lets you decouple your testbench development from your component development. Decoupling your testbench development can be useful for situations where you want to iterate your testbench quickly with platform-native compilers (GCC/Microsoft Visual Studio), without having to recompile the RTL generated for your component.

To create only your testbench executable with the i++ command, specify the --x86-only option.

You can choose to only generate RTL and simulation support for your component by linking the object file or files for your component with the Intel^® High Level Synthesis Compiler.

To generate only your RTL and simulation support for your component, specify the --fpga-only option.

To use a native compiler (GCC or Microsoft Visual Studio) to compile your Intel^® HLS Compiler code, you must run your native compiler from a terminal session where you initialized the environment for the Intel^® HLS Compiler. The initialization script chooses the correct native compiler for you system.

g++ myFile.cpp -g -I"$(HLS_INSTALL_DIR)/include" 
               -L"$(HLS_INSTALL_DIR)/host/linux64/lib" -lhls_emul 
               -pthread -std=c++17 

cl myFile.cpp /I "%HLS_INSTALL_DIR%\include" /nologo /EHsc /wd4068 /MD 
              /std:c++17 /Zi 
              /link "/libpath:%HLS_INSTALL_DIR%\host\windows64\lib" 
              hls_emul.lib 

The Intel^® HLS Compiler attempts to pipeline functions as much as possible. Different stages of the pipeline might have multiple operations performed in parallel.

The following figure shows an example of the pipeline architecture generated by the Intel^® HLS Compiler. The numbered operations on the right side represent the pipeline implementation of the C++ code on the left side of the figure. Each box in the right side of the figure is an operation in the pipeline.

With a pipelined approach, multiple invocations of the component can be simultaneously active. For example, the earlier figure shows that the first invocation of the component can be returning a result at the same time the fourth invocation of the component is called.

One invocation of a component advances to the its next stage in the pipeline only after all of the operations of its current stage are complete.

Some operations can stall the pipeline. A common example of operations that can stall a pipeline is a variable latency operation like a memory load or store operation. To support pipeline stalls, the Intel^® HLS Compiler propagates ready and valid signals through the pipeline to all operations that have a variable latency.

For operations that have a fixed latency, the Intel^® HLS Compiler can statically schedule the interaction between the operations and ready signals are not needed between the stages with fixed latency operations. In these cases, the compiler optimizes the pipeline to statically schedule the operations, which significantly reduces the logic required to implement the pipeline.

In addition, a component or task function cannot contain an irreducible loop. That is, loops in component and task functions must have only one entry point into the loop.

To overload a component function, define multiple variants of the function.

component int mult (int a, int b) {
  return a * b;
}

component float mult (float a, float b) {
  return a * b;
}

A mapping of the full function declaration to the synthesized function name is provided in the summary page of the High-Level Design Reports (report.html). The synthesized function name is used for all the other reports such as the loops report and area analysis.

The following example shows an example of this table in the report:

The component invocation interface is common to all HLS components and contains the return data (for nonvoid functions) and handshake signals for invoking the component, and for receiving results back when the component finishes executing.

Use the parameter interface to transfer data in and out of your component function. The parameter interface for your component is based on the parameters that you define in your component function signature.

Alternatively, by declaring your component as an hls_avalon_slave_component component, your component can have signals registered in the component slave memory map instead. In an hls_avalon_slave_component component, the start, done, and returndata signals appear in the component control and status registers (CSR) instead of as conduits outside of the component.

For a comparison of the invocation interfaces, see Interface Definition Example: Component Invocation Interface Control Attributes.

For an example of a component interface with scalar and pointer arguments, see Figure 2.

The inputs are read into the component when the external system pulls the start signal high and the component keeps the busy signal low.

If your component has a return value, an output conduit that is synchronized to your component done signal is generated.

For an example of how to specify a scalar parameter and how it is read in by a component, see the a argument in Figure 2 and Figure 3.

This example compares two simple components. One component is implemented with simple conduits as its signal interface, while the other component is implemented as an hls_avalon_slave_component.

component float myComponent(float a, float b) {
     return a+b;
}

This code example results in a component with the following signals:

hls_avalon_slave_component
component float myComponent(
hls_avalon_slave_register_arg float a, 
hls_avalon_slave_register_arg float b) {
     return a+b;
}

To create an mm_master<> object, add the following constructor in your code:

ihc::mm_master<int, … > mm(void* ptr, int size, bool use_socket=false);

where the constructor arguments are as follows:

• ptr is the underlying pointer to the memory in the testbench
• size is the total size of the buffer in bytes
• use_socket is the option you use to override the copying of the memory buffer and have all the memory accesses pass back to the testbench memory

  By default, the Intel^® HLS Compiler copies the memory buffer over to the simulator and then copies it back after the component has run. In some cases, such as pointer-chasing in linked lists, copying the memory buffer back and forth is undesirable. You can override this behavior by setting use_socket to true.

  Note: When you set use_socket to true, only Avalon^® MM Master interfaces with 64-bit wide addresses are supported. In addition, setting this option increases the run time of the simulation.

When your component uses one or more Avalon^® Memory-Mapped (MM) Master interfaces, the Intel^® HLS Compiler inserts load-store units (LSUs) in the datapath between the interface and the rest of your component datapath. The type of LSU inserted depends on the inferred memory access pattern and other memory attributes.

The Intel^® HLS Compiler also tries to minimize the number of LSUs created by coalescing multiple load/store operations into wider load/store operations. Multiple LSUs can share a memory interface.

Typically, the Intel^® HLS Compiler creates burst-coalesced LSUs for variable-latency MM Master interfaces and pipelined LSUs for fixed-latency MM Master interfaces.

For details about the types of the LSUs and when the Intel^® HLS Compiler typically instantiates them, see Load-Store Unit Types and Memory-Access Coalescing and Load-Store Units.

If your design contains one or more variable-latency Avalon^® MM Master interfaces (for example, if you interface with off-chip memory), you can control the LSU type to improve the performance and resource utilization of your design.

Use the high-level design reports to determine what types of LSUs your component has, and then you can apply these LSU controls as needed to achieve the component performance that you want.

The Intel^® HLS Compiler determines the types of load-store units (LSUs) to instantiate and whether to coalesce memory accesses based on from the memory access pattern that the compiler infers.

Click LSUs in the Graph Viewer (in the High-Level Design Reports) to see which types of LSU the compiler instantiated for your component.

Figure 4. Example of LSU Information Provided in the Graph Viewer

#include "HLS/hls.h"

component void
burst_coalesced(ihc::mm_master<int, ihc::dwidth<64>, ihc::awidth<32>,
                               ihc::aspace<1>, ihc::latency<0>> &in,
                ihc::mm_master<int, ihc::dwidth<64>, ihc::awidth<32>,
                               ihc::aspace<2>, ihc::latency<0>> &out,
                int i) {
  int value = in[i / 2]; // Burst-coalesced LSU
  out[i] = value; // Burst-coalesced LSU
}

#include "HLS/hls.h"

struct State {
  int x;
  int y;
  int z;
};

component void
static_coalescing(ihc::mm_master<State, ihc::dwidth<128>, ihc::awidth<32>,
                                 ihc::aspace<1>, ihc::latency<0>> &in,
                  ihc::mm_master<State, ihc::dwidth<128>, ihc::awidth<32>,
                                 ihc::aspace<2>, ihc::latency<0>> &out,
                  int i) {
  out[i] = in[i]; // Two Nonaligned Burst-coalesced LSUs

#include "HLS/hls.h"

component void 
pipelined(ihc::mm_master<int, ihc::dwidth<64>, ihc::awidth<32>,
                              ihc::aspace<1>, ihc::latency<2>> &in,
          ihc::mm_master<int, ihc::dwidth<64>, ihc::awidth<32>,
                              ihc::aspace<1>, ihc::latency<2>> &out,
          int gi, int li) {
  int lmem[1024];

  int res = in[gi]; // Pipelined LSU
  for (int i = 0; i < 4; i++) {
    lmem[li - i] = res; // Pipelined LSU
    res >>= 1;
  }

  res = 0;
  for (int i = 0; i < 4; i++) {
    res ^= lmem[li - i]; // Pipelined LSU
  }

  out[gi] = res; // Pipelined LSU
}

#include "HLS/hls.h"

component void
neverstall(ihc::mm_master<int, ihc::dwidth<128>, ihc::awidth<32>,
                              ihc::aspace<1>, ihc::latency<0>> &in,
          ihc::mm_master<int, ihc::dwidth<128>, ihc::awidth<32>,
                              ihc::aspace<1>, ihc::latency<0>> &out,
          int gi, int li) {
  int lmem[1024];
  for (int i = 0; i < 1024; i++)
    lmem[i] = in[i]; // Pipelined never-stall LSU

  out[gi] = lmem[li] ^ lmem[li + 1]; // Pipelined never-stall LSU
}

The Intel^® HLS Compiler sometimes coalesces multiple memory accesses into a wider memory access to save on the number of LSUs instantiated.

When the compiler coalesces the memory accesses, it is referred to as static coalescing because the coalescing occurs at compile time. This static coalescing contrasts with the dynamic coalescing done by a burst-coalesced LSU.

The compiler typically attempts to static coalescing when it detects multiple memory operations that access consecutive locations in memory. This coalescing is usually beneficial because it reduces the number of LSUs that compete for a shared memory interface.

The compiler coalesces memory accesses only up to the width of the memory interface that is being accessed. For an external memory interface, the maximum width is predetermined by the properties of the external memory that you are accessing. For a component (internal) memory interface, the maximum width can be set by the compiler based on the memory geometry that the compiler creates. For more details about component memories, see Component Memories (Memory Attributes).

For the following code example, the Intel^® HLS Compiler statically coalesces the four 4-byte-wide load operations into one 16-byte-wide load operations. A similar coalescing is done for the the four store operations. Coalescing the load and store operations reduces the number of required accesses to the Avalon MM Master interfaces by 4.

#include "HLS/hls.h"

component void
static_coalescing(ihc::mm_master<int, ihc::dwidth<128>, ihc::awidth<32>,
                                 ihc::aspace<1>, ihc::latency<0>> &in,
                  ihc::mm_master<int, ihc::dwidth<128>, ihc::awidth<32>,
                                 ihc::aspace<2>, ihc::latency<0>> &out,
                  int i) {
  // Four loads statically coalesced into one 16 bytes wide load
  int a1 = in[3 * i + 0];
  int a2 = in[3 * i + 1];
  int a3 = in[3 * i + 2];
  int a4 = in[3 * i + 3];

  // Four stores statically coalesced into one 16 bytes wide store
  out[3 * i + 0] = a4;
  out[3 * i + 1] = a3;
  out[3 * i + 2] = a2;
  out[3 * i + 3] = a1;
}

The Graph Viewer in the High-Level Design Reports for this example show that the design only has one load and one store, each of width 128 bit.

Figure 6. Graph Viewer Showing Coalesced Memory Accesses

Example code of a component with a CSR slave:

#include "HLS/hls.h"

struct MyStruct {
    int f;
    double j;
    short k;
};

hls_avalon_slave_component
component MyStruct mycomp_xyz (hls_avalon_slave_register_argument int y,
                hls_avalon_slave_register_argument MyStruct struct_argument,
                hls_avalon_slave_register_argument unsigned long long mylong,
                hls_avalon_slave_register_argument char char_arg
                           ) { 
    return struct_argument;
}

Generated C header file for the component mycomp_xyz:

/* This header file describes the CSR Slave for the mycomp_xyz component */

#ifndef __MYCOMP_XYZ_CSR_REGS_H__
#define __MYCOMP_XYZ_CSR_REGS_H__



/******************************************************************************/
/* Memory Map Summary                                                         */
/******************************************************************************/

/*
  Register  | Access  |   Register Contents      | Description
  Address   |         |      (64-bits)           | 
------------|---------|--------------------------|-----------------------------
        0x0 |       R |         {reserved[62:0], |     Read the busy status of
            |         |               busy[0:0]} |               the component
            |         |                          |  0 - the component is ready
            |         |                          |       to accept a new start
            |         |                          |    1 - the component cannot
            |         |                          |          accept a new start
------------|---------|--------------------------|-----------------------------
        0x8 |       W |         {reserved[62:0], |  Write 1 to signal start to
            |         |              start[0:0]} |               the component
------------|---------|--------------------------|-----------------------------
       0x10 |     R/W |         {reserved[62:0], |      0 - Disable interrupt,
            |         |   interrupt_enable[0:0]} |        1 - Enable interrupt
------------|---------|--------------------------|-----------------------------
       0x18 |  R/Wclr |         {reserved[61:0], | Signals component completion
            |         |               done[0:0], |       done is read-only and
            |         |   interrupt_status[0:0]} | interrupt_status is write 1
            |         |                          |                    to clear
------------|---------|--------------------------|-----------------------------
       0x20 |       R |       {returndata[63:0]} |        Return data (0 of 3)
------------|---------|--------------------------|-----------------------------
       0x28 |       R |     {returndata[127:64]} |        Return data (1 of 3)
------------|---------|--------------------------|-----------------------------
       0x30 |       R |    {returndata[191:128]} |        Return data (2 of 3)
------------|---------|--------------------------|-----------------------------
       0x38 |     R/W |         {reserved[31:0], |                  Argument y
            |         |                 y[31:0]} |                            
------------|---------|--------------------------|-----------------------------
       0x40 |     R/W |  {struct_argument[63:0]} | Argument struct_argument (0 of 3)
------------|---------|--------------------------|-----------------------------
       0x48 |     R/W | {struct_argument[127:64]} | Argument struct_argument (1 of 3)
------------|---------|--------------------------|-----------------------------
       0x50 |     R/W | {struct_argument[191:128]} | Argument struct_argument (2 of 3)
------------|---------|--------------------------|-----------------------------
       0x58 |     R/W |           {mylong[63:0]} |             Argument mylong
------------|---------|--------------------------|-----------------------------
       0x60 |     R/W |         {reserved[55:0], |           Argument char_arg
            |         |           char_arg[7:0]} |                            

NOTE: Writes to reserved bits will be ignored and reads from reserved
      bits will return undefined values.
*/


/******************************************************************************/
/* Register Address Macros                                                    */
/******************************************************************************/

/* Byte Addresses */
#define MYCOMP_XYZ_CSR_BUSY_REG (0x0)
#define MYCOMP_XYZ_CSR_START_REG (0x8)
#define MYCOMP_XYZ_CSR_INTERRUPT_ENABLE_REG (0x10)
#define MYCOMP_XYZ_CSR_INTERRUPT_STATUS_REG (0x18)
#define MYCOMP_XYZ_CSR_RETURNDATA_0_REG (0x20)
#define MYCOMP_XYZ_CSR_RETURNDATA_1_REG (0x28)
#define MYCOMP_XYZ_CSR_RETURNDATA_2_REG (0x30)
#define MYCOMP_XYZ_CSR_ARG_Y_REG (0x38)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_0_REG (0x40)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_1_REG (0x48)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_2_REG (0x50)
#define MYCOMP_XYZ_CSR_ARG_MYLONG_REG (0x58)
#define MYCOMP_XYZ_CSR_ARG_CHAR_ARG_REG (0x60)

/* Argument Sizes (bytes) */
#define MYCOMP_XYZ_CSR_RETURNDATA_0_SIZE (8)
#define MYCOMP_XYZ_CSR_RETURNDATA_1_SIZE (8)
#define MYCOMP_XYZ_CSR_RETURNDATA_2_SIZE (8)
#define MYCOMP_XYZ_CSR_ARG_Y_SIZE (4)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_0_SIZE (8)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_1_SIZE (8)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_2_SIZE (8)
#define MYCOMP_XYZ_CSR_ARG_MYLONG_SIZE (8)
#define MYCOMP_XYZ_CSR_ARG_CHAR_ARG_SIZE (1)

/* Argument Masks */
#define MYCOMP_XYZ_CSR_RETURNDATA_0_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_RETURNDATA_1_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_RETURNDATA_2_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_ARG_Y_MASK (0xffffffff)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_0_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_1_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_ARG_STRUCT_ARGUMENT_2_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_ARG_MYLONG_MASK (0xffffffffffffffffULL)
#define MYCOMP_XYZ_CSR_ARG_CHAR_ARG_MASK (0xff)

/* Status/Control Masks */
#define MYCOMP_XYZ_CSR_BUSY_MASK   (1<<0)
#define MYCOMP_XYZ_CSR_BUSY_OFFSET (0)

#define MYCOMP_XYZ_CSR_START_MASK   (1<<0)
#define MYCOMP_XYZ_CSR_START_OFFSET (0)

#define MYCOMP_XYZ_CSR_INTERRUPT_ENABLE_MASK   (1<<0)
#define MYCOMP_XYZ_CSR_INTERRUPT_ENABLE_OFFSET (0)

#define MYCOMP_XYZ_CSR_INTERRUPT_STATUS_MASK   (1<<0)
#define MYCOMP_XYZ_CSR_INTERRUPT_STATUS_OFFSET (0)
#define MYCOMP_XYZ_CSR_DONE_MASK   (1<<1)
#define MYCOMP_XYZ_CSR_DONE_OFFSET (1)


#endif /* __MYCOMP_XYZ_CSR_REGS_H__ */

Because a slave memory is internal to the component, the HLS compiler can create a memory architecture that is optimized for the access pattern of the component such as creating banked memories or coalescing memory accesses.

Slave memories differ from component memories because they can be accessed from an Avalon^® MM Master outside of the component. Component memories are by definition restricted to the component and cannot be accessed outside the component.

You can explicitly control the structure of your slave memories by applying memory arguments to slave memory variable declarations.

A component can have many slave memory interfaces. Unlike slave register arguments that are grouped together in the CSR slave interface, each slave memory has a separate interface with separate data buses. The slave memory interface data bus width is determined by the width of the slave type. If the internal accesses to the memory have been coalesced, the slave memory interface data bus width might be a multiple of the width of the slave type.

component float myComponent(​
hls_avalon_slave_memory(64) float *a,
hls_avalon_slave_memory(64) float *b) {​
   return a[0]+b[0];​
}

Reads and writes to slave memories from outside of the component should occur only when your component is not executing, unless you mark the slave memory argument with the volatile keyword. Without the volatile keyword, you might experience undefined component behavior if other Avalon MM Masters access your component slave memory when your component is executing. The undefined behavior can occur even if a slave memory access is to a memory address that the component does not access.

<quartus_installdir>/hls/examples/tutorials/interfaces/mm_slaves_CSR_volatile

component void 
foo(hls_avalon_slave_memory_argument(128*sizeof(int)) 
hls_readwrite_mode(“writeonly”) int *A)

Components can use and update C++ global variables. If you access a global variable in your component function, it is implemented as an Avalon^® Memory-Mapped (MM) Master interface, like a pointer parameter.

If you access more than one global variable, each global variable uses the same Avalon^® MM Master interface, which results in stallable arbitration. If you use pointers and non-constant global memory accesses, then the pointers and global memory accesses all share the same Avalon^® MM Master interface.

In addition to the Avalon^® MM Master interface, each global variable that the component uses has an input conduit that must be supplied with the address of the global variable in system memory. The input conduit arguments that are generated in the RTL are named @<global variable name> . Input conduits generated for pointer arguments omit the @ are named for the corresponding pointer argument.

If your global variable is declared as const, then no Avalon^® MM Master interface and no additional input conduit is generated. Therefore, global variables declared as const use significantly less FPGA area than modifiable global variable.

Review the interface_structs.sv file in your <a.prj>/components/<component_name> folder to see information about the padding and packed-ness of the implementation interfaces for the structs in your component.

The interface_structs.sv file contains the Verilog-style definitions of the structs found on your component interface.

Use Case 1:

If all accesses to memory arrays inside a loop do not cause loop-carried dependencies, add #pragma ivdep before the loop.

1  // no loop-carried dependencies for A and B array accesses
2  #pragma ivdep
3  for(int i = 0; i < N; i++) {
4      A[i] = A[i + N]; 
5      B[i] = B[i + N];
6  }

Use Case 2:

You may specify #pragma ivdep array (array_name) on particular memory arrays instead of all array accesses. This pragma is applicable to arrays, pointers, or pointer members of structs. If the specified array is a pointer, the ivdep pragma applies to all arrays that may alias with the specified pointer.

 1  // No loop-carried dependencies for A array accesses
 2  // Compiler inserts hardware that reinforces dependency constraints for B
 3  #pragma ivdep array(A)
 4  for(int i = 0; i < N; i++) {
 5      A[i] = A[i - X[i]];
 6      B[i] = B[i - Y[i]];
 7  }
 8
 9  // No loop-carried dependencies for array A inside struct
10  #pragma ivdep array(S.A)
11  for(int i = 0; i < N; i++) {
12      S.A[i] = S.A[i - X[i]];
13  }
14
15  // No loop-carried dependencies for array A inside the struct pointed by S
16  #pragma ivdep array(S->X[2][3].A)
17  for(int i = 0; i < N; i++) {
18      S->X[2][3].A[i] = S.A[i - X[i]];
19  }
20
21  // No loop-carried dependencies for A and B because ptr aliases
22  // with both arrays
23  int *ptr = select ? A : B;
24  #pragma ivdep array(ptr)
25  for(int i = 0; i < N; i++) {
26      A[i] = A[i - X[i]];
27      B[i] = B[i - Y[i]];
28  }
29
30  // No loop-carried dependencies for A because ptr only aliases with A
31  int *ptr = &A[10];
32  #pragma ivdep array(ptr)
33  for(int i = 0; i < N; i++) {
34      A[i] = A[i - X[i]];
35      B[i] = B[i - Y[i]];
36  }

Example code:

1  #pragma unroll <N>
2  for (int i = 0; i < M; ++i) {
3      // Some useful work
4  }

In this example, N specifies the unroll factor, that is, the number of copies of the loop that the HLS compiler generates. If you do not specify an unroll factor, the HLS compiler unrolls the loop fully. You can find the unroll status of each loop in the high level design report (report.html).

Typically, the exit condition for a loop iteration must be evaluated before the program determines whether to start the next loop iteration or continue into the rest of the function. This requirement means that the loop initiation interval (II) cannot be lower than the number of cycles required to compute the exit condition. Speculated iterations can help lower the loop II because operations within the loop can occur in the function pipeline at the same time as the exit condition is evaluated.

For any speculated iteration, instructions with side effects outside of the loop (like writing to memory or a stream) are not completed until the loop exit condition for the iteration has been evaluated. For loop iterations that are in flight but incomplete when the loop exit condition is met, side effect data is discarded.

The Intel^® HLS Compiler determines the number of speculated iterations on a per-loop basis. You can see the number of speculated iterations for a loop in the Loop Analysis Report in the High Level Design Report (report.html).

While speculated iterations can improve loop II, they occupy the pipeline until they are completed. A new loop invocation cannot start until all of the speculated iterations have completed. For example, the next iteration of an outer loop cannot start until all the speculated iterations of an inner loop have completed.

For loops where the exit condition calculation is a bottleneck (as shown in the Loop Analysis Report), consider increasing the number of speculated iterations with the speculated_iterations pragma. Increasing the number of speculated iterations might not improve the loop II if other bottlenecks in the loop are found.

For frequently invoked loops with a low latency loop body (for example, an inner loop with a short trip count), you might want to use the speculated_iterations pragma to reduce the number of speculated iterations to reduce the overhead of your design. However, setting the number of speculated iterations too low might increase the loop II because there is not enough time to evaluate the exit condition.

The following example shows how you can change the characteristics of a pipelined loop with the speculated_iterations pragma.

include <HLS/hls.h>

component void unopt_int_cube_root (int *dst, int N) {
  int m = 0;
// The exit condition which has 2 multiplies and a compare is most critical
// in loop feedback path. The compiler choice of 4 speculated iterations 
// results in II=2 because the exit condition takes 7 cycles: each 
// multiplication takes 3 cycles and the comparison takes 1 cycle. Four 
// speculated iterations times two-cycle II gives 8 cycles to cover this 
// evaluation.

  while (m*m*m < N) {
    m += 1;
  }
  dst[0] = m;
}

component void opt_int_cube_root (int *dst, int N) {
  int m = 0;
// Increasing to 7 speculated iterations to cover the 7 cycle exit condition
// calculation allows us to achieve II=1
  #pragma speculated_iterations 7
  while (m*m*m < N) {
    m += 1;
  }
  dst[0] = m;
}

component void unopt2_int_cube_root (int *dst, int N) {
  int m = 0;
// by setting to pragma to 0, user can verify that the II has increased to 7
// which matches the exit condition bottleneck
  #pragma speculated_iterations 0
  while (m*m*m < N) {
    m += 1;
  }
  dst[0] = m;
}

The Loop Analysis Report for these components looks like the following example:

When you click the line with unopt2_int_cube_root.B2 (spec.cpp:31) in the Loop Analysis Report, the Details pane shows the following information:

When the loop iterations effectively execute sequentially due to loop-carried dependencies, use the disable_loop_pipelining pragma to generate a simple sequential datapath and avoid loop resource hardware duplication. The simpler datapath and lack of resource duplication in hardware reduces the FPGA area utilization of your component.

Use the Loop Analysis section of the high-level design reports (report.html) to help determine if you should apply this pragma to your loops.

#pragma disable_loop_pipelining
for (int i = 1; i < N; i++) {
    int j = a[i-1];
    // Memory dependency induces a high-latency loop feedback path
    a[i] = foo(j)
}

You can also disable pipelining the datapath of your entire component with the hls_disable_component_pipelining component attribute. For more information about this attribute, see Component Pipelining Control (hls_disable_component_pipelining Attribute).

A loop iteration is the single execution of a loop body. A loop invocation is the start of pipelined execution of loop iterations.

// Loop j is pipelined with ii=1
for (int j = 0; j < M; j++) {
  int a[N];
  // Loop i is pipelined with ii=2
  for (int i = 1; i < N; i++) {
      a[i] = foo(i)
  }
}

In this example, the inner loop i is pipelined with II=2. Under normal pipelining, this II means that the inner loop hardware only achieves 50% utilization, since one iteration of the i loop is initiated every other cycle. To take advantage of these idle cycles, the compiler interleaves a second invocation of the i loop from the next iteration of the outer j loop.

Because the i loop resides inside the j loop, and the j loop has a trip count of M, the i loop is invoked M times. The j loop is the outermost loop and is invoked once.

The following table shows the difference between normal pipelined execution of the i loop versus interleaved execution for this example for N=5.

This table shows the values (j,i) for each inner loop iteration that is initiated at each cycle. At cycle 0, both modes of execution initiate the (0,0)th iteration of the i loop. Under normal pipelined execution, no i loop iteration is initiated at cycle 1. Under interleaved execution, the (1,0)th iteration of the innermost loop, i.e. the first iteration of the next (j=1) invocation of the i loop, is initiated. By cycle 10, interleaved execution has initiated all of the iterations of both the j=0 invocation of the i loop, and the j=1 invocation of the i loop. This represents twice the efficiency of the normal pipelined execution.

Sometimes you might determine that this interleaving does not give you a performance benefit relative to the additional FPGA area needed to enable interleaving. In these cases, you can limit or restrict the amount of interleaving to reduce FPGA area utilization.

To limit the number of interleaved invocations of an inner loop that can be executed simultaneously, annotate the inner loop with the max_interleaving pragma. The annotated loop must be contained inside another pipelined loop.

The required parameter ( n) specifies an upper bound on the degree of interleaving allowed, That is, how many invocations of the containing loop can execute the annotated loop at a given time.

// Loop j is pipelined with ii=1
for (int j = 0; j < M; j++) {
  int a[N];
  // Loop i is pipelined with ii=2 
  #pragma max_interleaving 1
  for (int i = 1; i < N; i++) {
      a[i] = foo(i)
  }
  …
}

Loop fusion is a compiler transformation in which two adjacent loops are merged into a single loop over the same index range. This transformation is typically applied to reduce loop overhead and improve run-time performance.

for (i = 0; i < 300; i++)
    a[i] = a[i] + 3;
for (i = 0; i < 300; i++)
    b[i] = b[i] + 4;

for (i = 0; i < 300; i++) {
    a[i] = a[i] + 3;
    b[i] = b[i] + 4;
}

Loop control structures represent a significant overhead. By fusing two loops, the number of control structures needed for the loops is reduced from two to one, reducing this overhead. The main goal of reducing the number of control structures is save FPGA area for your design while still maintaining (ideally increasing) component throughput.

Fusing outer loops introduces parallelism where there was previously none. Combining bodies of two adjacent loops (L_j and L_k) forms a single loop (L_f) with a loop body that spans the bodies of L_j and L_k. This combined loop body creates an opportunity for operations that were serialized across a given iteration of L_j and L_k to execute in parallel In effect, the two loops now execute in lockstep as a single loop, which provides latency improvements.

If inner loops are fused, parallelism is already achieved by pipelined execution of the outer loop iteration. In these cases, the parallelism effect of loop fusion is diminished.

Use the loop_fuse pragma to tell the compiler to try to fuse two adjacent loops without affecting the functionality of either loop, overriding the compiler profitability analysis of fusing the loops.

#pragma loop_fuse [depth(N)] [independent]
      {
      ...
      }

#pragma loop_fuse
                // can also be 
                // #pragma loop_fuse depth(1)
                {
                L1: for(...) {}
                L2: for(...) {
                L3: for(...) {}
                L4: for(...) {
                L5: for(...) {}
                L6: for(...) {}
                }
                }
                }

#pragma loop_fuse depth(2)
              {
              L1: for(...) {}
              L2: for(...) {
              L3: for(...) {}
              L4: for(...) {
              L5: for(...) {}
              L6: for(...) {}
              }
              }
              }

#pragma loop_fuse depth(3)
              {
              L1: for(...) {}
              L2: for(...) {
              L3: for(...) {}
              L4: for(...) {
              L5: for(...) {}
              L6: for(...) {}
              }
              }
              }

#pragma loop_fuse
      {
      L1 for(...) {}
      L2 for(...) {
      L3 for(...) {}
      }
      L4 for(...) {}
      }

#pragma loop_fuse depth(2) independent
{
  L1: for(...) {}
  L2: for(...) {
    #pragma loop_fuse depth(2)
    {
      L3: for(...) {}
      L4: for(...) {
        L5: for(...) {}
        L6: for(...) {}
      }
    }
  }
}

You can exempt a loop from being considered for fusing with an adjacent loop by annotating the loop with the nofusion pragma. This pragma prevents the annotated loop from being automatically fused or fused when it is subject to the loop_fuse pragma.

#pragma nofusion
for (...) {
loop body
}

Applying the nofusion pragma to one of the loops in a pair prevents the loops from being fused.

#pragma nofusion
L1: for (int j=0; j < N; ++j){
 data[j] += Q;
}
L2: for (int i = 0; i < N; ++l) {
 output[i] = Q * data[i];
}

L1: for (int j=0; j < N; ++j){
 data[j] += Q;
}
#pragma nofusion
L2: for (int i = 0; i < N; ++l) {
 output[i] = Q * data[i];
}

The Intel^® HLS Compiler provides you with the hls_max_concurrency component attribute to help you control the maximum concurrency of your component.

You can use the hls_max_concurrency component attribute to increase or limit the maximum concurrency of your component. The concurrency of a component is the number of invocations of the component that can be in progress at one time. By default, the Intel^® HLS Compiler tries to maximize concurrency so that the component runs at peak throughput.

You can control the maximum concurrency of your component by adding the hls_max_concurrency component attribute immediately before you declare your component, as shown in the following example:

#include "HLS/hls.h"

hls_max_concurrency(3)
component void foo ( /* arguments */ ){
  // Component code
}

You can also control the concurrency of loops in components with the max_concurrency(N) pragma. For more information about the max_concurrency(N) pragma, see Loop Concurrency (max_concurrency Pragma).

If running concurrent invocations of your component does not improve throughput, or if you do not intend to invoke your component repeatedly, avoid extra FPGA area utilization by using the hls_disable_component_pipelining component attribute.

When you specify the hls_disable_component_pipelining, the Intel^® HLS Compiler generates a simpler, serialized datapath for your component.

#include "HLS/hls.h"

hls_disable_component_pipelining
component void baz ( /* arguments */ ){
  // component code
}

You can also disable pipelining the datapath of a only a loop in your component with the disable_loop_pipelining pragma. For more information about this pragma see Loop Pipelining Control (disable_loop_pipelining Pragma).

Some of these header files are based on the Algorithmic C (AC) data types that Mentor Graphics* provides under the Apache license. For more information about the Algorithmic C data types, refer to Mentor Graphics Algorithmic C (AC) Datatypes, which is available as a part of your Intel^® HLS Compiler installation: <quartus_installdir>/hls/include/ref/ac_datatypes_ref.pdf.

The Intel^® HLS Compiler also supports arbitrary-precision IEEE 754 compliant floating point data types that is not based on the AC data types.

The ac_int datatype automatically increases the size of the result of the operation to guarantee that the intermediate operations never overflow. However, the HLS compiler automatically truncates or extends the result to the size of the specified destination container, so ensure that the storage variable for your computation is large enough.

The HLS compiler installation package includes a number of examples in the tutorials. Refer to the tutorials in <quartus_installdir>/hls/example/tutorials/ac_datatypes for some of the recommended practices.

The rules of integer promotion when you use ac_int data types are different from standard C/C++ rules. Your component design should account for these differing rules.

Data Width of Operations

C++ compilers typically automatically promote narrow integer types such as char and short to 32-bit types (int) for arithmetic operations such as addition, multiplication, division, and bit-shifts. To adhere to the C++ language specification and be consistent with other C++ compilers, the Intel^® HLS Compiler might use larger operations than you might expect when dealing with native types.

If you need better control over the size of arithmetic operations, use the ac_int datatype.

Consider the following example:

component int singlestep_native_signed(char a, char b, char c)
{
   return a * b / c;
}

The Graph Viewer (part of the High-Level Design Reports) shows that the divide operation becomes a 32-bit operation:

Note: The Intel^® HLS Compiler narrows operations automatically whenever it can, depending on the context of the operation. In this case, the compiler automatically narrowed the multiplication operations to 16 bits. To confirm the width of an operation, review your design in the Graph Viewer.

If you use ac_int data types for the parameters and the return data, the Intel^® HLS Compiler makes the divide operation narrower.

#include <HLS/ac_int.h> 
component int32 singlestep_acint_signed(int8 a, int8 b, int8 c)
{
   return a * b / c;
}

With the component variables all defined as ac_int data types, the Graph Viewer now shows that the divide operation is reduced to being 17-bits wide:

ac_int<5, true> ap;
...
if (ap < 4) {
...

uint3 x = 7;
if (x != -1) {
   // FAIL
}

uint3 x = 7;
if (x != (unit3)-1) {
   // SUCCEED
}

The reference version of the Mentor Graphics* Algorithmic C (AC) data types is also provided with the Intel^® HLS Compiler. Do not use these reference header files in your component if you want to compile your component with an FPGA target.

Use the reference header files for AC data types to confirm functional correctness in your component when you are compiling your component with native compilers (g++ or MSVC).

If you use the reference header files and compile your component to an FPGA target, your component can compile successfully but your component QoR will be poor.

All of your code must use the same header files (either the reference header files or the FPGA-optimized header files). For example, your code cannot use the reference header files in your testbench and, at the same time, use the FPGA-optimized header file in your component code.

The Intel^® HLS Compiler hls_float.h header files provides some aliases for some hls_float data types that you can use instead of explicitly declaring an hls_float data type.

For details about the --clock option, see Command Options Affecting Compiling.

For details about the hls_scheduler_target_fmax_mhz component attribute, see hls_scheduler_target_fmax_mhz Component Attribute.

<quartus_installdir>/hls/examples/tutorials/best_practices/set_component_target_fmax

component int test1(){ 
 … 
} 

hls_scheduler_target_fmax_mhz(200) 
component int test2(){ 
 … 
} 

The compiler schedules component test1 at 300 MHz (from the command option) and component test2 at 200 MHz (from the component attribute).

Setting a target II (through hls_component_ii component attribute or #pragma ii loop pragma) and setting a target f_MAX (through the hls_scheduler_target_fmax_mhz component attribute) affects how the scheduler in the Intel^® HLS Compiler determines its efforts.

The following table summarizes the behavior of the scheduler in the Intel^® HLS Compiler.

If you are using an f_MAX target in the command line or a component attribute, specify #pragma ii for performance-critical loops in your design.

The component keyword marks a single function and its subfunctions as a component. Within this component function, directly-called functions are in-lined while functions that use the systems of tasks API calls (ihc::launch and ihc::collect) generate hardware outside the component datapath and behave like an asynchronous call.

The function tagged with the component keyword marks the boundary of a system of tasks. Your external system can interact with all the interfaces that the component exposes.

For an example of using the HLS tasks ihc::stream object as a FIFO, review the tutorial in <quartus_installdir>/hls/examples/tutorials/system_of_tasks/internal_stream.

To help you understand the tutorial better, review the following diagram showing a store-load dependency:

This diagram is simplified from the tutorial. It shows 10 iterations, while the tutorial goes through 32 iterations.

In the diagram, i is the index of the outer loop and j is the index of the inner loop.

Each iteration of the outer loop reads all the values written by the previous loop iteration and writes one less value to the buffer. The internal stream outperforms the array in this design because array must allocate enough space to store written values before the values are read, but an internal stream does not need to allocate this space.

In addition, the trip count of the inner loop decreases by one in each outer loop, so the space claimed by array is never filled after the first iteration, which wastes area.

When you simulate a system of tasks design where the completion of a task function is not synchronized with an ihc::collect call, use the ihc_hls_set_component_wait_cycle testbench API function to allow output from that task function to be returned after the component function finishes running.

By default, the simulation process simulates an additional 100 cycles after a component asserts the done signal to ensure all operations have propagated back to the testbench. This function tells the simulation process for the specified component to continue running for the specified number of cycles in addition to the default wait period of 100 cycles.

If you do not use this function in your testbench, the latency of some task functions might make your simulation output inaccurate or cause your simulation testbench to hang..

For an example of a valid systems of task design where the completion of a task function is not synchronized with an ihc::collect call, see Example 3 of a Valid ihc::launch/ihc::collect Sequence.

With libraries, you can reuse functions without knowing the underlying hardware design or implementation details. Libraries can be created with Intel FPGA high-level design tools including the Intel^® HLS Compiler and the Intel^® FPGA SDK for OpenCL* , either from code initially targeting that tool or from RTL code.

A static-object library is a single platform-specific archive file that contains one or more object files, each of which contains implementations of one or more functions.

The object and library files use the same formats as the operating system that you compile your Intel^® HLS Compiler code on, with additional sections that carry additional library information. On Linux platforms, a library is a .a archive file that contains .o object files. On Windows platforms, a library is a .lib archive file that contains .obj object files.

You can call the functions in the library from your component without needing to know the hardware design or the implementation details of the underlying functions in the library. Add the library to the i++ command line when your compile your component.

You can create a library from object files from your HLS source code. An HLS-based object file contains code for CPU execution (testbench and emulation) and FPGA execution. A library can contain multiple object files.

You can create object files for use with different Intel high-level design tools from the same HLS source code.

Depending on the target high-level design tool, your source code might require adjustments to support tool-specifc data types or constructs.

You can create a library from object files that package register transfer level (RTL) language source files. An RTL-based object file also contains an object manifest file (in XML format) that identifies the functions that are callable in the object file. A library can contain multiple RTL-based objects.

Creating a library from RTL code is a two-step process. First, each object file is created from the RTL source and emulation models as described in the object manifest file with the fpga_crossgen command. Then, one or more object files are collected into an HLS library file with the fpga_libtool command.

To create a library from RTL code, you need to create the following files and components:

The depicted RTL module has a latency of 3 cycles. Since the multiply and add operations have a latency of just one cycle, the compiler inserts buffering to balance the latency of the parallel data paths in the pipeline. A balanced latency allows the invocations of the HLS component to execute without stalling the pipeline.

Specifying the latency of the RTL module in the HLS library object manifest file allows the HLS compiler to balance the pipeline latencies in the HLS component. The pipeline integration protocol uses ready/valid handshaking, so the latency of the RTL module can be variable. However, the variability in the latency should be small to maximize performance. In addition, specify the latency in the HLS library object manifest file for the object in the HLS library so that the RTL module experiences a good approximation of the actual latency in steady state.

For an RTL module to properly interact with other compiler-generated operations, you must support a simple ready/valid handshaking protocol at both the input and the output of an RTL module.

An RTL module must use a single streaming interface. That is, a single pair of ready and valid logic must control all the inputs.

You have the option to provide the necessary streaming ports but declare the RTL module as stall-free. In this case, you do not have to implement proper stall behavior because the Intel^® HLS Compiler creates a wrapper for your module.

You must handle ivalid signals properly if your RTL module has an internal state. For more information, see Stall-Free RTL.

Consider the following interfaces for the RTL module myMod:

In this diagram, myMod interacts with the upstream module through data signals, arg1 and arg2, and control signals, ivalid (input) and oready (output). The ivalid control signal equals 1 (ivalid = 1) if and only if data signal arg1 and data signal arg2 contain valid data. When the control signal oready equals 1 (oready = 1), it indicates that the myMod RTL module can process the data signals arg1 and arg2 if they are valid (that is, ivalid = 1). When ivalid = 1 and oready = 0, the upstream module holds the values of ivalid, arg1, and arg2 in the next clock cycle.

The myMod module interacts with the downstream pipeline logic through the data signal result and the control signals, ovalid (output) and iready (input). The ovalid control signal equals 1 (ovalid = 1) if and only if the data signal result contains valid data. When the iready control signal equals 1 (ivalid = 1), the downstream module can process the data signal result if it is valid. When ovalid = 1 and iready = 0, the myMod RTL module must hold the valid of the ovalid and result signals in the next clock cycle.

The Intel^® HLS Compiler expects the RTL module to support a single interface with readyLatency = 0, at both input and output.

The following figure illustrates the timing diagram for input data transfer with back pressure.

Figure 20. Timing Diagram for Input and Output Data Transfer with Back Pressure

For an RTL module with a fixed latency, the output signals (ovalid and oready) can have constant high values, and the input ready signal (iready) can be ignored.

A stall-free RTL module might receive an invalid input signal (ivalid is low). In this case, the module ignores the input and produces invalid data on the output. For a stall-free RTL module without an internal state, it might be easier to propagate the invalid input through the module. However, for an RTL module with an internal state, you must handle an ivalid = 0 input carefully.

Example Timing Diagram of a Stall-free RTL Component

Consider the following example timing diagram of a stall-free RTL component:

Figure 21. Timing Diagram of a Stall-free RTL Component

For this component, the following ATTRIBUTE elements are set in the object manifest file for the RTL module:

• IS_STALL_FREE value = "yes"
• IS_FIXED_LATENCY value = "yes"
• EXPECTED_LATENCY value = "2"

Example Timing Diagram of a Non-stall-free RTL Component

Consider the following example timing diagram of a non-stall-free RTL component:

Figure 22. Timing Diagram of a Non-stall-free RTL Component

For this component, the following ATTRIBUTE elements are set in the object manifest file for the RTL module:

• IS_STALL_FREE value = "no"
• IS_FIXED_LATENCY value = "no"
• EXPECTED_LATENCY value = "4"

Because of the common clock and reset drivers, an RTL module runs in the same clock domain as the HLS component that is integrating the RTL module. The module reset input is asserted whenever the HLS component is reset.

All supported composite data types are represented by wide input or output signals. Typically, the components of a composite data type are presented with the first-declared value or value of lowest index in the low-order bits of the signal.

For an RTL-based function, write C++ code that serves as an emulation model for that function. This model is used when you run your component in emulation mode.

The emulation model is not used when you simulate your component; simulations use RTL extracted from the library.

Consider a situation where you create and verify your library on a device that does not support Partial Reconfiguration (PR). If you then use the library RTL module inside a PR region, the module might not function correctly after PR.

For complete PR coding guidelines, refer to Creating a Partial Reconfiguration Design in the Partial Reconfiguration User Guide.

If you have an RTL module with a fixed latency that you want integrated into your component pipeline without surrounding stall logic, ensure that you set attributes in the object manifest file (.xml) as follows:

1. Specify a value for the EXPECTED_LATENCY attribute (under the FUNCTION element) so that the latency equals the number of pipeline stages in the module.
   Important: An inaccurate EXPECTED_LATENCY value causes the RTL module to be out of sync with the rest of the pipeline, and can lead to functionally incorrect results.
2. Set the IS_STALL_FREE attribute under the FUNCTION element to "yes".

   This setting instructs the Intel^® HLS Compiler to avoid placing stall logic around the RTL module. This setting also tells the compiler that the RTL module produces a result after the number cycles specified in the EXPECTED_LATENCY attribute after accepting input values. The stall free logic produces a result every cycle but the result is delayed by the number cycles specified in the EXPECTED_LATENCY attribute.

For RTL modules with a fixed latency, the output signals ( ovalid and oready) can have constant high values, and the input ready signal ( iready) can be ignored.

A stall-free RTL module might receive an invalid input signal (ivalid is low). In this case, the module must produce invalid data on the output EXPECTED_LATENCY cycles after the cycle in which the input was invalid. For a stall-free RTL module without an internal state, you might find it convenient to propagate the invalid input through the module. If the module has an internal state, that state should not be affect by data inputs that are not accompanied by ivalid = 1.

Using global memory to move data in and out of object libraries or tasks can constrain the performance of your design. Pipes provide a mechanism for passing data with high efficiency and low latency by using on-device FIFO buffers to communicate.

Pipes are similar to streams, but are simpler. When compared with streams, a pipe supports only ready/valid and data signals. You can use pipes in a component or between tasks.

Unlike streams, you can have an array of pipes and you can iterate over the array to write or read many pipes in a design.

Data written to a pipe remains in the pipe until it is read or until the component is reset.

The memory model of pipes allows you to use them to send and receive data from running functions in an object library or a running task function.

The pipe class exposes static methods for writing a data word to a pipe and reading a data word from a pipe. The reads and writes can be blocking or nonblocking, with the form chosen based on the overload resolution.

template <class name,
          class dataT,
          size_t min_capacity = 0>
class pipe {
public:
  // Blocking
  static dataT read();
  static void write(dataT data);
  // Non-blocking
  static dataT read(bool &success);
  static void write(dataT data, bool &success);
}

#include "HLS/hls.h"

template<unsigned ID, class T, unsigned pipe_capacity> class TaskSystem {
private:
  template<unsigned SystemID> class InputPipeID {};
  template<unsigned SystemID> class TaskPipeID {};
  template<unsigned SystemID> class OutputPipeID {};

public:
  using input_pipe = ihc::pipe<class InputPipeID<ID>, T, pipe_capacity>;
  using output_pipe = ihc::pipe<class OutputPipeID<ID>, T, pipe_capacity>;
  using task_pipe = ihc::pipe<class TaskPipeID<ID>, T, pipe_capacity>;

  static void first_task(unsigned N) {
    T data;
    for(unsigned i=0; i<N; ++i) {
      data = input_pipe::read();
      task_pipe::write(data);
    }
  }

  static void second_task(unsigned N) {
    T data;
    for(unsigned i=0; i<N; ++i) {
      data = task_pipe::read();
      output_pipe::write(data);
    }
  }
};

#include "HLS/hls.h"

// PipeArray

template <class ArrayID, typename T, unsigned pipeCapacity, unsigned arraySize>
class PipeArray {
private:
  template <unsigned idx> struct StructIndex;
  template <unsigned idx> struct VerifyIndex {
    static_assert(idx < arraySize, "Index out of bounds");
    using VerifiedPipe = ihc::pipe<StructIndex<idx>, T, pipeCapacity>;
  };

public:
  template <unsigned idx>
  using pipe_at = typename VerifyIndex<idx>::VerifiedPipe;
  static void write_to_pipes(T *values);
};

// Write Unroller

template <class ArrayID, typename T, unsigned pipeCapacity, unsigned arraySize,
          unsigned idx>
struct WriteUnroller {
  using my_array = PipeArray<ArrayID, T, pipeCapacity, arraySize>;
  static void write_to_pipes_impl(T *values) {
    my_array::template pipe_at<idx>::write(values[idx]);
    WriteUnroller<ArrayID, T, pipeCapacity, arraySize,
                  idx + 1>::write_to_pipes_impl(values);
  }
};

template <class ArrayID, typename T, unsigned pipeCapacity, unsigned arraySize>
struct WriteUnroller<ArrayID, T, pipeCapacity, arraySize, arraySize> {
  static void write_to_pipes_impl(T *values) {}
};

// Write function

template <class ArrayID, typename T, unsigned pipeCapacity, unsigned arraySize>
void PipeArray<ArrayID, T, pipeCapacity, arraySize>::write_to_pipes(T *values) {
  WriteUnroller<ArrayID, T, pipeCapacity, arraySize, 0>::write_to_pipes_impl(
      values);
}

In some cases, explicitly asking the compiler to insert a register stage between the operand and the return value of the function call can help improve the performance of your component. Use the hls_fpga_reg() function to insert at least one register between the operand and return value of the function call.

Typically, you do not need to use this function to achieve the performance from your component that you want.

<quartus_installdir>/hls/examples/tutorials/best_practices/fpga_reg