You can use the same testbench to verify your design both when it is compiled to x86-64 instructions or to RTL.

The Intel^® HLS Compiler Pro Edition is command-line compatible with g++, and supports most of the g++ compiler flags. See the Intel^® High Level Synthesis Compiler Reference Manual for a full list of compiler flags.

The Intel^® HLS Compiler Pro Edition recognizes the same file name extensions as g++, namely .c, .C, .cc, .cpp, .CPP, .c++, .cp, and .cxx. The compiler treats all of these file types as C++. The compiler does not explicitly support C, other than as a subset of C++.

To specify the name of the compiler output, include the -o <result> option in your i++ command, where <result> is the name of the executable. This command creates a project directory called <result>.prj.

Running the executable file runs your testbench. When you target the compilation to an x86-64 architecture, the output executable runs your design on the CPU like a regular C++ program. The output executable runs very quickly compared to running a simulation of your component RTL. When you target the compilation to an FPGA architecture, the output executable simulates your component RTL. This simulation can take a long time to run.

Verify the functionality of your design by compiling your component and testbench to an x86-64 executable that you can debug with a native C++ debugger.

Compiling your design to an x86-64 executable is faster than compiling your component to hardware or a hardware simulation. This faster compilation time lets you debug and refine your component algorithms quickly before you move on to see how your component is implemented in hardware.

Ensure that you set your compiler command to include debug information. The i++ command generates debug information by default.

On Linux systems, you can use GDB to debug your component and testbench, even if you used the i++ command to compile your code for functional verification.

On Windows systems, you can use Microsoft Visual Studio to debug your component and testbench, even if you used the i++ command to compile your code for functional verification.

Using the g++ command or Microsoft Visual Studio might require additional configuration to compile your Intel^® HLS Compiler Pro Edition code. For details, see Compiler Interoperability in the Intel^® High Level Synthesis Compiler Pro Edition Reference Manual.

You can automate the process by using a makefile or batch script. Use the makefiles and scripts provided in the Intel^® HLS Compiler Pro Edition example designs and tutorials as guides for creating your own makefiles or batch scripts.

After you have verified the functionality of your component and testbench, you can compile your component to RTL and review the High-Level Design Reports to further optimize and refine your component design. The High-Level Design Reports show estimates of various aspects of how your component will be implemented in hardware.

i++ -march="<FPGA_family_or_part_number>" --simulator none

<result>.prj/reports/report.html

The High-Level Design Reports are a group of reports and viewers that you can use to help optimize your design by reviewing the statistics and visualizations that the reports provide.

Access the High-Level Design Reports by using a web browser to open the report.html file found in the <name>.prj/reports folder created when you compile your component to RTL.

Use the tutorials provided with the Intel^® HLS Compiler to view examples of the reports and learn how to use the reports and viewers to help optimize and refine your component design.

For details about using the reports to help optimize your design, review Reviewing the High-Level Design Reports (report.html).

In some cases, information in the reports and viewers are estimates and might not match the results from compiling your design with Intel^® Quartus^® Prime software. However, Compiling your component using the Intel^® Quartus^® Prime software might take several hours. In contrast, the Intel^® HLS Compiler can generate the High Level Design Report in minutes for most designs.

Figure 2 illustrates the waveform of the signals for the component dut. The testbench does not include any enqueue function calls.

#include "HLS/hls.h"
#include <stdio.h>
      
component int dut(int a, int b) {
      return a*b;
}
      
int main (void) {
      
      int x1, x2, x3;
      x1 = dut(1, 2);
      x2 = dut(3, 4);
      x3 = dut(5, 6);
      
      printf("x1 = %d, x2 = %d, x3 = %d\n", x1, x2, x3);
      
      return 0;
}

Figure 2. Waveform Diagram of the Signals for Component dut Without Enqueue Function Calls

#include "HLS/hls.h"
#include <stdio.h>
      
component int dut(int a, int b) {
      return a*b;
}
   
int main (void) {
      
      int x1, x2, x3;
      ihc_hls_enqueue(&x1, &dut, 1, 2);
      ihc_hls_enqueue(&x2, &dut, 3, 4);
      ihc_hls_enqueue(&x3, &dut, 5, 6);
      
      ihc_hls_component_run_all(&dut);
      
      printf("x1 = %d, x2 = %d, x3 = %d\n", x1, x2, x3);
      
      return 0;
}

Figure 3. Waveform Diagram of the Signals for Component dut With Enqueue Function Calls

The Summary Report gives you a quick overview of the results of compiling your design including a summary of each component in your design and a summary of the estimated resources that each component in your design uses.

The following example verification statistics report is for a component dut that has been run once as a simple function call and 100 times as an enqueued invocation:

For components that use explicit streams, such as ihc::stream_in<> or ihc::stream_out<>, the verification statistics report also provides the throughput for each individual stream, as shown in the details pane:

View the simulation waveform by following the instructions in Debugging during Verification.

The Graph Viewer is an interactive view of your system as a hierarchy of block diagrams of how the compiler constructed your component. These diagrams can help you understand how data flows through your component.

Access system-, function-, block-, and cluster-level views of your component by selecting System Viewers > Graph Viewer in the High Level Design Reports menu.

The Graph Viewer represents your component and tasks as a system of functions. Each function is divided into a a set of blocks. Inside each block is a set of non-branching instructions that covers your code and the compiler loop orchestration optimization. The connections between blocks show the execution flow of your component.

There is an initialization block, called the runOnce block. When a function contains loops, cycles of blocks form, depending on the loop structure. Loops often impose initiation interval (II) bottlenecks and are a main optimization focus when you optimize your component.

To save the amount of control handshaking infrastructure needed when synthesizing your design, the Intel^® HLS Compiler Pro Edition groups instructions within a block into groups called clusters.

A branch node indicates the next block to go to and the condition required to go to that block.

The Graph Viewer is divided into two main panes: Graph List and Graph View. Clicking on different entries in the Graph List shows you different views of your component.

Hovering over elements in the Graph View pane typically displays a tooltip with details about the element and highlights connections to and from the element.

Clicking on an element displays details about the element in the Details pane below Graph List and Graph Viewer panes and highlights connections to and from the element.

You can control the zoom of the diagram in the Graph Viewer pane using your mouse scroll wheel or equivalent touchpad gesture.

Use the System View in the Graph Viewer report to view of the various components in your system as well as the tasks. Additionally, this view displays the connectivity between a component and its tasks.

Click the system in the Graph List pane to see the system in the Graph View pane.

The System View of the Graph Viewer shows ihc::launch and ihc::collect calls that are the synchronization points from component/task to the task function. They are represented as write nodes (labeled WR) and read nodes (labeled RD) that connect to the call.task_name and return.task_name nodes of the corresponding task.

This report also shows explicit streaming interfaces between tasks with the name of the stream displayed as a rectangular node in the connection between the tasks connected by the streaming interface.

Some parameters in your component can be marked as being stable. A parameter can be marked as stable if its argument does not change while your component executes, but the argument might change between component executions. In the Function View, a stable argument does not have any edge connection.

Default (Conduit) Interfaces

Conduit interfaces are implemented for any function parameter whose arguments are passed by value. The Function View of the Graph Viewer report connects the conduit interface to the corresponding stream read (RD) node. The read is synchronize with the start/busy signals on the component invocation interface.

#include "HLS/hls.h"
#include "stdio.h"

struct coordinate_t {
	int x;
	int y;
};

component int default_comp(int b, coordinate_t p) {
	return b + p.x;
}

For each default interface argument node, you can view details about the node when you hover over the node:

Avalon^® MM Master Interfaces

Pointer arguments, pass-by-reference arguments, ihc::mm_master<> argument, and global variables all correspond to addresses to memory outside of your component. They result in at least one Avalon^® MM Master interface in your component. Similarly to conduit interface arguments, these nodes connect to the corresponding stream read (RD) node for your component.

#include "HLS/hls.h"
#include "stdio.h"

component int master_comp(
  int *pointer_d,
  ihc::mm_master<int, ihc::aspace<3>, ihc::awidth<4>, ihc::dwidth<32>,ihc::latency<1>, ihc::align<4> > &master_i,
  int &result
  )
 {
  result = *pointer_d + *master_i;
  return result;
}

The Function View of the Graph Viewer shows the following details for these interface arguments:

Stable

Describes whether the interface argument is stable. That is, whether the hls_stable_argument attribute was applied.

Data width

The width of the memory-mapped data bus in bits.

Address width

The width of the memory-mapped address bus in bits.

Latency

The guaranteed latency from when the read command exits the component to when the external memory returns valid read data. The latency is measured in clock cycles.

Maximum burst

The maximum number of data transfers that can associate with a read or write transaction. For fixed latency interfaces, this value is set to 1.

Alignment

The byte alignment of the base pointer address. The Intel^® HLS Compiler uses this information to determine the amount of coalescing that is possible for loads and stores to this pointer.

The Function View of the Graph Viewer shows the following details for Avalon^® MM Master interfaces:

Memory address space number

The memory address space number for Avalon^® MM Master interface.

Number of banks

The number of memory banks contained in the memory.

Argument Name:

The names of arguments that access the Avalon^® MM Master interface.

#include "HLS/hls.h"
#include "stdio.h"

component int slavereg_comp(
  int hls_avalon_slave_register_argument slave_scalar_f,
  int* hls_avalon_slave_register_argument slave_pointer_g
  ) {
  return slave_scalar_f + *slave_pointer_g;
}

#include "HLS/hls.h"
#include "stdio.h"

hls_avalon_slave_component
component int slavereg_comp(
  int hls_avalon_slave_register_argument slave_scalar_f,
  int* hls_avalon_slave_register_argument slave_pointer_g
  ) {
  return slave_scalar_f + *slave_pointer_g;
}

#include "HLS/hls.h"
#include "stdio.h"

hls_avalon_slave_component
component int slavemem_comp(
  hls_avalon_slave_memory_argument(4096) int* slave_mem_h,
  int index,
  int hls_avalon_slave_register_argument slave_scalar_f
  ) {
  return slave_mem_h[index] * slave_scalar_f;
}

#include "HLS/hls.h"
#include "stdio.h"
component int stream_comp(
  ihc::stream_in<int> &stream_in_c,
  ihc::stream_out<int> &stream_out_e,
  int scalar_b
  ) {

  stream_out_e.write(scalar_b + 1);
  return  stream_in_c.read() + scalar_b * 2;
} 

Use the Block Views in the Graph Viewer report to inspect the datapath of your design. The report shows the datapath within and between input nodes, clusters, and instructions that cannot be grouped into clusters.

If your design has loops, the compiler encapsulates the loop control logics into loop orchestration nodes (labeled as Loop Orch) and the initial conditions of the loops to loop input nodes.

Click a block in the Graph List pane to see the block in the Graph View pane.

Within a block, the report shows connections between instruction nodes and cluster nodes.

Click the different nodes and look at the Details panel to see the information about the node.

For instruction nodes, you can find the type of instruction with specific details. For example, on a stream RD or WR node, you can see the width, depth, name, scheduling info, stall-free attributes of a stream in the Details panel. For stallable nodes, the latency value provided is an estimate.

For cluster nodes, you can find the type of the cluster and other cluster attributes.

Use the Cluster Views in the Graph Viewer report to examine the data path of computations within a cluster. The Intel^® HLS Compiler Pro Edition groups instructions into clusters to reduce the amount of handshaking logic required when synthesizing your component.

A cluster starts with an entry node and ends with an exit node. These nodes perform handshaking with logic outside of the cluster.

For a stall-free cluster, the exit node of the cluster has a FIFO with a depth greater than or equal to the latency of the cluster. This FIFO stores any in-flight data that needs to be passed outside of the cluster. To see the size of the cluster exit FIFO, click the exit node and see the information in the Details pane.

If your design contains loops, you see loop orchestration nodes (labeled as Loop Orch) and variable nodes as well as computation nodes. The loop orchestration nodes and variable nodes are shown along with their Feedback nodes.

The compiler generates the loop orchestration nodes to pipeline your loop to increase the performance.

A variable node corresponds to a variable that has a loop-carried dependency in your design. A variable node goes through various computation logic and finally feeds to a feedback node that connects back to the variable node. This connection shows that the new value of the variable is passed to the next iteration.

Look for loop-carried variables that have a long latency to the feedback nodes as they can be the initiation interval (II) bottlenecks. See the Loop Analysis report to reflect the II bottleneck.

The feedback node has a FIFO to store in-flight values of the variable in different iterations of the loop and has a size equal to the dependency distance multiplied by the II. The dependency distance is the number of iterations between successive load/store operations that depend on each other.

In a Cluster View, you can find the size of the cluster exit FIFO by clicking the exit node and looking at the Details pane. You can also find the size of the cluster exit FIFO in a Block View by clicking the exit node and looking at the Details pane.

Click a cluster in the Graph List pane to see that cluster in the Graph View pane.

Click nodes in the Cluster View pane to see details about that node as well as highlight the connections for the node inputs and outputs. For stallable nodes, the latency value provided in the details is an estimate. For more accurate latency values, run simulation on your component.

Data movement is often a bottleneck in many algorithms. The Function Memory Viewer in the High Level Design Reports (report.html) shows you the memory system that the Intel^® HLS Compiler Pro Edition generated for your component. Use the Function Memory Viewer to help you identify data movement bottlenecks in your component design.

Some patterns in memory accesses can cause undesired arbitration in the load-store units (LSUs), which can affect the throughput performance of your component. Use the Function Memory Viewer to find where you might have unwanted arbitration in the LSUs.

Access the Function Memory Viewer by clicking System Viewers > Function Memory Viewer.

The following figure shows the layout of the Function Memory Viewer:

1. Function Memory List pane

   The Function Memory List pane lists all of the memories in your design. Click a memory name to see its graphical representation in the Function Memory Viewer pane.

2. Function Memory Viewer pane

   The Function Memory Viewer pane shows a graphical representation of the memory system or memory bank selected in the Function Memory List pane.

3. Code view pane

   The code view pane shows the source code files for which the reports are generated.

4. Details pane

   The Details pane shows the details of the memory system or memory bank selected in the Function Memory List pane.

Function Memory List

The Memory List pane shows you a hierarchy of component and task functions, with memories that are synthesized (RAMs, ROMs, and registers) and are optimized away in that component or task.

	Icon or Label	Name	Description
1		Component or task name	The list of memories in your component or task can be expanded or collapsed. Memories that do not belong to any component or task are shown under (Other).
2		RAM	A RAM is a memory that has at least one write to it. The name of the RAM memory is the same as its name in your design. Clicking the memory name displays a logical representation of the RAM in the Function Memory Viewer pane. By default, only the first bank of the memory system is displayed. To select which banks to display, expand the memory name. Clear the memory name check box to collapse all memory banks in the view. Select the memory name check box to show all memory banks in the view.
3		ROM	A ROM is a memory that is only read from. The name of the ROM memory is the same as its name in your design. Clicking the memory name displays a logical representation of the ROM in the Function Memory Viewer pane. By default, only the first bank of the memory system is displayed. To select which banks to display, expand the memory name. Clear the memory name check box to collapse all memory banks in the view. Select the memory name check box to show all memory banks in the view.
4	Bank #num	Bank	A memory bank is always associated with a RAM or a ROM. Each bank is named as Bank #num , where #num is the ID of the memory bank starting from 0. Clicking the bank name shows the bank view in the Function Memory Viewer pane: a graphical representation of the bank, with all of its replicates and private copies. This view can help you to focus on specific memory banks when you view a complex memory design. Clear the memory bank name check box to collapse the bank in the logical representation of the memory. Select the memory bank name check box to show the bank in the logical representation of the memory.
5		Register	A register is a component variable that is carried through the pipeline in registers rather than being stored in a RAM or ROM. The name of the register is the same as its name in your design. A register variable can be implemented either exclusively in flip-flops (FFs), or in a mix of FFs and RAM-based FIFOs.
6	text label	Optimized Away	A component variable might be optimized away because it is unused in your design or compiler optimizations have transformed all uses of the variable such that it is unnecessary. The name of the optimized away variable is the same as its name in your design.
7		Filter	Use the Function Memory List filter to selectively view the list of RAMs, ROMs, registers and optimized away variables in your design. Clearing the check box associated with a item in the filter hides all occurrences of that kind of item in the Function Memory List. Filter your Function Memory List to help you focus on a specific type of memory in your design.

Function Memory Viewer

The Function Memory Viewer pane shows you connections between loads and stores to specific logical ports on the banks in a memory system. It also shows you the number of replicates and private copies created per bank for your memory system. The following types of nodes might be shown in the Function Memory Viewer pane, depending on the component memory system and what you have selected in the Function Memory List pane:

• Memory node: The memory system for a given variable in your design.
• Bank node: A bank in the memory system. A memory system contains at least one memory bank. A memory bank can have one or more port nodes. Only banks selected in the Function Memory List pane are shown.
• Replication node: A replication node shows memory bank replicates that are created to efficiently support multiple accesses to a local memory. A bank contains at least one replicate. You can view replicate nodes only when you view a memory bank by clicking its name in the Function Memory List pane.
• Private-copy node: A private-copy node shows private copies within a replicate that are created to allow concurrent execution of multiple loop iterations. A replicate contains at least one private copy. You can view private-copy nodes only when you view a memory bank by clicking its name in the Function Memory List pane
• Port node: Each read or write access to a local memory is mapped to a port. There are three types of port:
  • R: A read-only port
  • W: A write-only port
  • RW: A read and write port
• LSU node: A store (ST) or load (LD) node connected to the memory through port nodes.
• Arbitration node: An arbitration (ARB) node shows that LSUs compete for access to a shared port node, which can lead to stalls.
• Port-sharing node: A port-sharing node (SHARE) shows that LSUs have mutually exclusive access to a shared port node, so the load-store units are free from stalls.

Hover over any node to view the attributes of that node.

Hover over an LSU node to highlight the path from the LSU node to all of the ports that the LSU connects to.

Hover over a port node to highlight the path from the port node to all of the LSUs that read or write to the port node.

Click a node to select it and have the node attributes displayed in the Details pane.

The following figures show examples of what you can see in the Function Memory Viewer:

Logical representation of a memory in the Function Memory Viewer pane

Bank view of a memory bank in the Function Memory Viewer pane

Use the Schedule Viewer to identify latency bottlenecks in your design. The Schedule Viewer shows the estimated start and ending clock cycle for functions, blocks, clusters, and individual instructions in your design.

Click an item in the Schedule List to focus the Schedule View at the selected level. You cannot click the system level of the component hierarchy in the Schedule List.

Click the schedule bar for an item in the Schedule View updates the Details pane with the information available about that item. The information can include a description of the item, start cycle, and latency.

Click an item in the Schedule View to show a popup menu for the item. For instructions, the popup menu includes a link that takes you to your C++ code that resulted in that instruction.

The JSON files containing the data are available in the <result>.prj/reports/lib/json directory. The directory provides the following .json files:

You can read the following .json files without a special parser:

• area.json
• area_src.json
• loops.json
• quartus.json
• summary.json

For example, if you want to identify all of the values and bottlenecks for the initiation interval (II) of a loop, you can find the information in the children section in the loops.json file, as shown below:

“name”:”<block name|Component: component name>  # Find the loops which does not begin with “Component:”
      
      “data”:[<Yes|No>, <#|n/a>, <II|n/a>]      # The data field corresponds to “Pipelined”, “II”, “Bottleneck”