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.

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 

In some cases, you might want to decouple your testbench development from your component development. For example, you might want to change your testbench code without recompiling your HLS component.

<quartus_installdir>/hls/examples/tutorials/usability/compiler_interoperability

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 non-void 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 and global variables (including global streams) that your component accesses.

Alternatively, by declaring your component as an hls_avalon_agent_component component, your component can have signals registered in the component agent memory map instead. In an hls_avalon_agent_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_agent_component.

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

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

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

Using external memory to move data in and out of static-object libraries or task functions 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. You can use pipes in a component or to allow tasks to communicate with each other, but pipes support only ready/valid and data signals, while streams support additional sideband signals such as startofpacket and endofpacket.

Unlike streams, you can declare 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 task functions in running functions in a static-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"
#include <iostream>

#include “task_system.h”

unsigned constexpr ID = 42; // can be any unique value
unsigned constexpr CAPACITY = 100;
using MySystem = TaskSystem<ID, int, CAPACITY>;

int main() {
  ihc::launch<MySystem::first_task>(CAPACITY);
  ihc::launch<MySystem::second_task>(CAPACITY);

  for(int i = 0; i < CAPACITY; ++i) {
    std::cout << "input: " << i << "\n";
    MySystem::input_pipe::write(i);
  }

  for(int i = 0; i < CAPACITY; ++i) {
    int data = MySystem::output_pipe::read();
    std::cout << "output: " << data << "\n";
  }

  return 0;
}

#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);
}

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

ihc::mm_host<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 Host 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) Host 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 Host interfaces and pipelined LSUs for fixed-latency MM Host 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 Host 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 System 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 System Viewer

#include "HLS/hls.h"

component void
burst_coalesced(ihc::mm_host<int, ihc::dwidth<64>, ihc::awidth<32>,
                             ihc::aspace<1>, ihc::latency<0>> &in,
                ihc::mm_host<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_host<State, ihc::dwidth<128>, ihc::awidth<32>,
                               ihc::aspace<1>, ihc::latency<0>> &in,
                  ihc::mm_host<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_host<int, ihc::dwidth<64>, ihc::awidth<32>,
                            ihc::aspace<1>, ihc::latency<2>> &in,
          ihc::mm_host<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_host<int, ihc::dwidth<128>, ihc::awidth<32>,
                             ihc::aspace<1>, ihc::latency<0>> &in,
          ihc::mm_host<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 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 operation. A similar coalescing is done for the four store operations. Coalescing the load and store operations reduces the number of required accesses to the Avalon MM Host interfaces by 4.

#include "HLS/hls.h"

component void
static_coalescing(ihc::mm_host<int, ihc::dwidth<128>, ihc::awidth<32>,
                               ihc::aspace<1>, ihc::latency<0>> &in,
                  ihc::mm_host<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 System 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. System Viewer Showing Coalesced Memory Accesses

component int alignedRead(AHost &A, unsigned int i)
{
    hls_register int memory_line[PARALLEL_WORDS] = {};

    int word_base = PARALLEL_WORDS * (i / PARALLEL_WORDS);

#pragma unroll
    for (int j = 0; j < PARALLEL_WORDS; j++)
    {
        int idx_base = PARALLEL_WORDS * ((i + j) / PARALLEL_WORDS);
        bool doesntWrap = idx_base == word_base;

        if (doesntWrap)
        {
            memory_line[j] = A[i + j];
        }
    }
    ...
}

The compiler infers a nonaligned LSU because the compiler cannot determine that all values of j are read from the same word of memory A. Although the range of j matches exactly one word of memory, the accesses might wrap to another word. More than 1 read might be required. If you code your access with a base that aligns with the word width, the compiler can guarantee no wrapping occurs and so the compiler gives you an aligned LSU.

Example code of a component with a CSR agent:

#include "HLS/hls.h"

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

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

Generated C header file for the component mycomp_xyz:

/* This header file describes the CSR Agent 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 agent 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.

Agent memories differ from component memories because they can be accessed from an Avalon^® MM Host 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 agent memories by applying memory arguments to agent memory variable declarations.

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

You can apply component memory attributes to agent memories in your component to customize the memory architecture and lower the FPGA area utilization of your component. For details, refer to Component Memory Attributes.

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

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

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

component void 
foo(hls_avalon_agent_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) Host interface, like a pointer parameter.

If you access more than one global variable, each global variable uses the same Avalon^® MM Host 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 Host interface.

In addition to the Avalon^® MM Host 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 Host 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  }

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

Example code:

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

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 when the number of loop iterations is known at compile time.

hls_register float data[N];

#pragma unroll 3
for (int i = 0; i < N; i++)
{
    data[i] = function(i, a);
}

hls_register float data[N];

for (int i = 0; i < N; i += 3)
{
    data[i + 0] = function(i + 0, a);
    if (i + 1 < N)
    {
        data[i + 1] = function(i + 1, a);
    }
    if (i + 2 < N)
    {
        data[i + 2] = function(i + 2, a);
    }
}

You can find the unroll status of each loop in the high level design report (report.html).

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).

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.

<quartus_installdir>/hls/examples/tutorials/loop_controls\speculated_iterations
<quartus_installdir>/hls/examples/tutorials/loop_controls\small_speculated_iterations

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).

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 (j = 0; j < 300; j++)
    a[j] = a[j] + 3;
for (k = 0; k < 300; k++)
    b[k] = b[k] + 4;

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

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

for (jk = 0; jk < 600; jk++)
{
    if (jk < 300)
    { 
        int j = jk;
        a[j] = a[j] + 3;
    } else 
    {
        int k = jk - 300;
        b[k] = b[k] + 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
{
	for (int i = 0; i < N; i++) {
  		// Loop Body 1
	}
	for (int j = 0; j < M; j++) {
  		// Loop Body 2
	}
}

for (int f = 0; f < max(M,N); f++) {
  if (f < N) {
    // Loop Body 1
  }
  if (f < M) {
    // Loop Body 2
  }
}

#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(...) {}
      }
    }
  }
}

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

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];
}

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

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
}

The optimizations caused by using this attribute might cause component memory configuration changes to meet the set concurrency requirements. Use memory attributes to control the geometry of your component memory configuration.

The hls_max_concurrency attribute can also accept a value of 0. When this attribute is set to 0, the component should be able to accept new invocations as soon as the downstream datapath frees up. Use this value only when you see loop initiation interval (II) issues in your component because using this attribute can increase the component area. You can find loop II issues by examining the Loop Viewer in the High-Level Design Reports or looking for extra bubbles that are visible in a simulation waveform.

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 loop in your component with the disable_loop_pipelining pragma. For more information about this pragma see Loop Pipelining Control (disable_loop_pipelining Pragma).

Review the Loop Analysis report in the High-Level Design Reports (report.html) to see component invocations and loops with pipelining disabled:

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 has a large number of API calls that are documented in Mentor Graphics Algorithmic C (AC) Datatypes , which is available In your Intel^® HLS Compiler installation as the following file: <quartus_installdir>/hls/include/ref/ac_datatypes_ref.pdf. For more information on AC datatypes, refer to

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 the rules of integer promotion for 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 System 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 System 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 System 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
}

When you use the ac_fixed datatype to declare literals in your component, the compiler expands the literal, regardless of the size you set for the ac_fixed literal. To keep the compiler from expanding the literal, cast the literal to an ac_fixed data type.

Using Fixed12 = ac_fixed<12, 6, true>;

component Fixed12 threshold_vanilla(Fixed12 a){
    if (a < 12.7) {
        return a;
    } else {
        return 12.7;
    }
}

In this code snippet, the 12-bit ac_fixed value is compared with 12.7. The literal 12.7 is treated as a double, with value 12.699999…. This literal is converted to a fixed-point to be compared with a, but because the literal is unconstrained, the compiler chooses a large fixed-point value and this can result in a large comparison:

Using Fixed12 = ac_fixed<12, 6, true>;

component Fixed12 threshold_cast(Fixed12 a){
    if (a < (Fixed12)12.7) {
        return a;
    } else {
        return 12.7;
    }
}

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

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 in the ihc namespace 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.

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 21. 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 22. 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 23. 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.

For math functions performed on certain data types, you can control whether the function is implemented in hardware using DSP blocks or soft logic (ALMs).

You can review the math function hardware implementation by reviewing the details of the instruction nodes for the math function in System Viewer of the High-Level Design Reports (report.html).

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

Use the --dsp_mode option of the i++ command to control the hardware implementation for supported data types and math functions for your entire compilation. For local-scope control, use ihc::math_dsp_control function.

i++ --dsp-mode=[prefer-dsp | prefer-softlogic | default]

Use the ihc::math_dsp_control function to control the hardware implementation for supported data types and math functions at a local-scope.

The ihc::math_dsp_control function is defined in the HLS/math_dsp_control.h header file. Include this header file in your component or task code to use the function.

ihc::math_dsp_control<HW_impl_pref, lambda_expr_propagation>

component float test_lib(float a, float b) {
  ihc::math_dsp_control<ihc::Preference::Softlogic>([&]{ 
    a += 7.89f; // Soft-logic
    a += b;     // Soft-logic 
  }); 
  return a;
}

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