Synthesis Summary - Synthesis Summary - 2026.1 English - UG1702

Vitis Reference Guide (UG1702)
Document ID
UG1702
Release Date
2026-06-23
Version
2026.1 English

When synthesis completes, the Synthesis Summary report for the top-level function opens in the information pane. The specific sections of the Synthesis Summary are detailed below.

General Information

Figure 1. Synthesis Summary Report Generated by Your Tool

Timing Estimate

Displays a quick estimate of the timing specified by the solution. The estimate includes the Target clock period and the period of Uncertainty. The clock period minus the uncertainty is the Estimated clock period.

Tip: Values in the estimate are estimates of the HLS tool. You can provide more accurate timing estimates Vivado synthesis and implementation. Refer to Running Implementation.

Performance & Resource Estimates

The Performance Estimate columns report the timing slack, latency, and initiation interval for the top-level function and sub-blocks the tool instantiated in the top-level. Sub-functions called at this level in the C/C++ source are instances in the generated RTL block. One exception is when the tool in-lined the sub-function into the top-level function using the INLINE pragma or directive. Another exception is if the tool automatically in-inlined the function.

The Slack column displays any timing issues in the implementation.

The two Latency columns display the number of cycles it takes to produce the output, and display latency in time (ns).

The Iteration Latency is the latency of a single iteration for a loop.

The Initiation Interval is the number of clock cycles before you can apply new inputs. In the absence of any PIPELINE directives, the latency is one cycle less than the initiation interval. Vitis reads the next input after writing the final output.

Tip: When latency is displayed as a "?", it means the number of loop iterations is undetermined. If the latency or throughput of the design depends on a loop with a variable index, the HLS compiler reports the loop latency as unknown. In this case, use the LOOP_TRIPCOUNT pragma or directive to manually specify the number of loop iterations. Vitis only uses LOOP_TRIPCOUNT to ensure the reports show meaningful ranges for latency. The LOOP_TRIPCOUNT also ensures the interval values do not impact the results of synthesis.

The Trip Count column displays the number of iterations a specific loop makes in the implemented hardware. This reflects any unrolling of the loop in hardware.

The resource estimate columns of the report indicates the estimated resources needed to implement the software function in the RTL code. The report provides estimates of the block RAM, DSP, FFs, and LUTs.

HW Interfaces

The HW Interfaces section of the synthesis report has tables for the different hardware interfaces generated during synthesis. The type of hardware interfaces the tool generates depend on INTERFACE pragmas, directives and the flow target the solution specifies. In the following image, the solution targets the Vitis Kernel flow and generates AXI interfaces.

Figure 2. HW Interfaces Generated by Your Tool

Pay attention to the following when reviewing the tables.

  • Vitis provides separate tables for different interfaces.
  • Columns display different properties of the interface. For the M_AXI interface, these include the Data Width and Max Widen Bitwidth columns. These columns indicate whether Automatic Port Width Resizing occurred, and to what extent. In the example above, the port widened to 512 bits from the software specified 16 bits.
  • The Latency column displays the latency of the interface:
    • In an ap_memory interface, the column displays the read latency of the RAM resource driving the interface.
    • For an m_axi interface, the column displays the expected latency of the AXI4 interface. The design can initiate a bus request a number of cycles (latency) before expecting the read or write.
  • The Bundle column displays any specified bundle names from the INTERFACE pragma or directive.
  • Additional columns display burst, read and write properties of the M_AXI interface. See the INTERFACE pragma or directive.
  • The Bit Fields column displays the bits used by registers in an s_axilite interface.

SW I/O Information

Highlights how function arguments from the C/C++ source are associated with the port names in the RTL code. See additional details of the software and hardware ports below. The SW argument expands into multiple HW interfaces. The input argument relates to three HW interfaces, the m_axi for data, and the s_axi_lite for required control signals.

Figure 3. SW I/O Information Generated by Your Tool

M_AXI Burst Information

In the M_AXI Burst Information section, the Burst Summary table reports the successful burst transfers. You can see a link to the associated source code. The reported burst length refers to either max_read_burst_length or max_write_burst_length. The length represents the number of data values read or written during a burst transfer. For example, if the input type is integer (32 bits), and HLS auto-widens the interface to 512 bits, each burst transfers 1024 integers. Because the widened interface can carry 16 integers at a time, the result is 64 beat bursts. The Burst Missed table reports the reason and link to guidance messages for burst failures.

Figure 4. M_AXI Burst Information Generated by Your Tool

Pragma Report

Displays the pragmas in the design: valid, ignored, inferred. This report summarizes issues that can otherwise be found in the log files. You can identify issues with the pragmas in your design to see which ones were not expected. The report lists valid pragmas separately so you can see all pragmas in the design.

Tip: Click the link in the report to view the source code for the pragma.
Figure 5. Pragma Report Generated by Your Tool

Bind Op and Bind Storage Reports

The Bind Op and Bind Storage reports help you understand HLS compiler actions when it maps operations to resources. The Vitis tool maps operations to resources with specific latencies. You can influence this process by using the BIND_OP pragma or directive, and by requesting a particular resource mapping and latency. The Bind Op report displays automatically completed mappings versus those that pragmas enforced. Similarly, the Bind Storage report shows the mappings of arrays to memory resources on the platform like block RAM/LUTRAM/URAM.

The Bind Op report displays the implementation details of the kernel or IP. Details include variables and their HLS pragmas or directives, the defined operation, the implementation that the HLS tool used, and any latency applied. The report is useful for examining the programmable logic implementation details specified by the RTL design.

Figure 6. Synthesis Summary Generated by Your Tool

The Bind Op report highlights important characteristics in your design. Currently, it calls out the number of DSPs the design uses and shows in a hierarchy where these the design uses the DSPs. The table also highlights whether the particular resource allocation completed due to a user-specified pragma: if yes, the Pragma column denotes it. If no entry exists in the Pragma column, it means the tool auto interred the resource. The table also shows the RTL names of the resources allocated for each module in your design.

The report does not show all the inferred resources but instead shows resources of interest such as arithmetic, floating-point, and DSPs. The report also shows:
  • The implementation fabric choice that LUTs or DSPs implement
  • The latency of the resource
These information can help you understand the latency of resources to add pipeline stages if necessary. The information is useful if you need to break a long combinational path when trying to solve timing issues during implementation.

You can right-click on the resource and select the Goto Source option to see the correlation between resources and source code lines. The Bind Op report illustrates global config settings that can also alter the resource allocation algorithm. In the above example, the implementation choice for a dadd (double precision floating point addition) operation is fixed to a fulldsp implementation. Similarly, the latency of a ddiv operation is fixed to 2.

Similar to the BIND_OP pragma, you can use the BIND_STORAGE pragma to select a particular memory type (such as single port or dual port). You can also select a particular memory implementation (such as BRAM/LUTRAM/URAM/SRL, etc) and a latency value. The Bind Storage report highlights the storage mappings in the design. Currently, the tool calls out the number of Block RAMs and URAMs in the design.

The table highlights whether a user‑specified pragma caused the storage allocation and marks "yes" in the Pragma column. If no entry exists in the Pragma column, this means that the tool auto inferred the storage resource. The report displays the storage type, the implementation choice, the variable name, and latency.

With the information from the report, you can review the storage resource allocation in the design. You can make design choices by altering the eventual storage implementation depending upon availability. Finally, a second table in the Bind Storage report shows you if there are global settings that can alter the storage resource allocation algorithm. See Storage Configuration for details.