SDAccel Profiling and Optimization Features

This report is automatically generated during the hardware emulation flow. There is one report generated for each kernel and a top report for the complete binary container. It is easy to access the reports from the Assistant window in the Emulation-HW folder.

The following figure shows the Assistant window with a System Estimate report for the binary_container_1 and the kernel with the name run.

Figure: System Estimate Report in the Assistant Window

The following command generates the system performance estimate report system_estimate.xtxt for all kernels in kernel.cl:

xocc -c -t hw_emu --platform xilinx:adm-pcie-7v3:1ddr:3.0 --report estimate kernel.cl

The performance estimate report generated by the xocc -report estimate option provides information on every binary container in the application, as well as every compute unit in the design. The report is structured as follows:

• Target device information
• Summary of every kernel in the application
• Detailed information on every binary container in the solution

The following example report file represents the information generated for the estimate report:

---------------------------------------------------------------------
Design Name:             _xocc_compile_kernel_bin.dir
Target Device:           xilinx:adm-pcie-ku3:2ddr-xpr:3.3
Target Clock:            200MHz
Total number of kernels: 1
---------------------------------------------------------------------

Kernel Summary
Kernel Name    Type  Target              OpenCL Library  Compute Units
-------------  ----  ------------------  --------------  -------------
smithwaterman  clc   fpga0:OCL_REGION_0  xcl_xocc        1


----------------------------------------------------------------------
OpenCL Binary:     xcl_xocc
Kernels mapped to: clc_region

Timing Information (MHz)
Compute Unit     Kernel Name    Module Name    Target Frequency  
---------------  -------------  -------------  ----------------  
smithwaterman_1  smithwaterman  smithwaterman  200               

Estimated Frequency
-------------------
202.020203

Latency Information (clock cycles)
Compute Unit     Kernel Name    Module Name    Start Interval  
---------------  -------------  -------------  --------------  
smithwaterman_1  smithwaterman  smithwaterman  29468           

Best Case  Avg Case  Worst Case
---------  --------  ----------
29467      29467     29467

Area Information
Compute Unit     Kernel Name    Module Name    FF    LUT   DSP  BRAM
---------------  -------------  -------------  ----  ----  ---  ----
smithwaterman_1  smithwaterman  smithwaterman  2925  4304  1    10
---------------------------------------------------------------------

After compiling a kernel using the SDx environment GUI, you can view the HLS Report in the Assistant window. The report is under the Emulation-HW or System build configuration, and has the <binary container> name, and the <kernel> name. This is illustrated in the following Assistant window:

Figure: Assistant Window

The HLS Report is designed to be viewed by the SDAccel environment GUI. However, for command line users, a textual representation of this report is also published. This report can be found inside the report directory situated under the kernel synthesis directory in the Vivado High-Level Synthesis (HLS) tool solution directory.

Because the xocc command generates several additional levels of hierarchy above this synthesis directory, it is best to simply locate the file by name:

find . -name <module>_csynth.rpt

Where <module> is the name of the kernel.

find . -name "*_csynth.rpt"

The left pane of the HLS Report shows the module hierarchy. Each module generated as part of the high level synthesis run is represented in this hierarchy. You can select any of these modules to present the synthesis details of the module in the right side of the Synthesis Report window.

Figure: HLS Report Window

The Synthesis Report is separated into several sections, namely:

• General Information
• Performance Estimates (timing and latency)
• Utilization Estimates
• Interface Information

If this information is part of a hierarchical block, it will sum up the information of the blocks contained in the hierarchy. Due to this fact, the hierarchy can also be navigated from within the report, when it is clear which instance contributes what to the overall design.

When you compile and execute an application from SDAccel environment, the profile summary is automatically generated.

To control the generation of profile information, simply edit the run configuration through the context menu of the build configuration, and select Run > Run Configurations.

After the configuration is run, the Assistant window enables easy access to the report from below the Run Configuration item. After the run configuration has executed, modifying the configuration can now be initiated directly through the context menu of the run configuration item in the Assistant window.

Figure: Profile Summary access in SDAccel GUI Flow

Double-click the report to open it.

Command Line users execute standalone applications outside the SDAccel environment. To generate the profile summary data, you can compile your design without any additional options. However, linking the bitstream file (xclbin) requires the --profile_kernel option.

The argument provided through the --profile_kernel option can be used to limit data collection, which might be required in large systems. The general syntax for the profile_kernel option with respect to the profile summary report is:

--profile_kernel <[data]:<[kernel_name|all]:[compute_unit_name|all]:[interface_name|all]:[counters|all]>

Three fields, kernel_name, compute_unit_name, and interface_name can be specified to determine the interface which the performance monitor is applied to. However, you can also specify the keyword all to apply the monitoring to all existing kernels, compute units, and interfaces with a single option. The last option, <counters|all> allows you to restrict the information gathering to just counters for large designs, while all (default) will include the collection of actual trace information.

Executing the program creates an sdaccel_profile_summary.csv file, if profile = true is specified in the sdaccel.ini file.

[Debug]
profile = true

The .csv file needs to be manually converted to Google Protocol Buffer format (.xprf) before the profiling result can be viewed in the integrated Profile Summary Viewer. The following command line example generates an .xprf file from the .csv input file:

sdx_analyze profile sdaccel_profile_summary.csv

The following figure shows the Application Timeline window that displays host and device events on a common timeline. This information helps you to understand details of application execution and identify potential areas for improvements.

Figure: Application Timeline Window

Application timeline trace has two main sections, Host and Device. The host section shows the trace of all the activity originating from the host side. The device section shows the activity of the compute-units on the FPGA.

Under the host different activities are categorized as OpenCL™ API calls, Data Transfer, and the Kernels.

The following image shows the Waveform view:

Figure: Waveform View

The waveform view is organized hierarchically for easy navigation.

The hierarchy tree and descriptions are:

Device “name”

Target device name

Binary Container “name”

Binary container name.

Memory Data Transfers

For each DDR Bank, this shows the trace of all the read and write request transactions arriving at the bank from the host.

Kernel “name” 1:1:1

For each kernel and for each compute unit of that kernel, this section breaks down the activities originating from the compute unit.

Compute Unit: “name”

Compute unit name.

CU Stalls (%)

Stall signals are provided by the HLS tool to inform you when a portion of their circuit is stalling because of external memory accesses, internal streams (i.e., dataflow), or external streams (i.e., OpenCL pipes). The stall bus, shown in detailed kernel trace, compiles all of the lowest level stall signals and reports the percentage that are stalling at any point in time. This provides a factor of how much of the kernel is stalling at any point in the simulation.

For example: If there are 100 lowest level stall signals, and 10 are active on a given clock cycle, then the CU Stall percentage is 10%. If one goes inactive, then it would be 9%.

Data Transfers

This shows the read/write data transfer accesses originating from each Master AXI port of the compute unit to the DDR.

User Functions

This information is available for the HLS tool kernels and shows the user functions.

Function: <name>

Function Stalls

Shows the different type stalls experienced by the process. It contains External Memory and Internal-Kernel Pipe stalls. The number of rows is dynamically incremented to accommodate the visualization of any concurrent execution.

Intra-Kernel Dataflow

FIFO activity internal to the kernel.

Function I/O

Actual interface signals.

The following figure shows the live waveform viewer while running hardware emulation.

The Guidance view is automatically populated and displayed in the lower central tab view. After running hardware emulation, the Guidance view might look like the following:

Figure: Guidance View

To simplify visualizing the guidance information, the GUI flow allows you to search, and filter the Guidance view to locate specific guidance rule entries. It is also possible to collapse or expand the tree view or even suppress the hierarchical tree representation and visualize a condensed representation of the guidance rules. Finally, it is possible to select what is shown in the Guidance view. You can enable or disable the visualization of warnings, as well as met rules, and restrict the specific content based on the source of the messages such as build and emulation.

By default, the Guidance view shows all guidance information for the project selected in the drop down.

To restrict the content to an individual build or run step, do the following:

1. Use the command Window > Preferences
2. Select the category Xilinx Sdx > Guidance.
3. Deselect Group guidance rule checks by project.

The Guidance data is best analyzed through the GUI, which consolidates all guidance information for the flow. Nevertheless, the tool automatically generates HTML files containing the guidance information. As guidance information is generated throughout the tool flow, several guidance files are generated. The simplest way to locate the guidance reports is to search for the guidance.html files.

find . -name "*guidance.html" -print

This command lists all guidance files generated, which can be opened with any web-browser.

The Guidance view places each entry in a separate row. Each row might contain the name of the guidance rule, threshold value, actual value, and a brief but specific description of the rule. The last field provides a link to reference material intended to assist in understanding and resolving any of the rule violations.

In the GUI Guidance view, guidance rules are grouped by categories and unique IDs in the Name column and annotated with symbols representing the severity. These are listed individually in the HTML report. In addition, as the HTML report does not show tooltips, a full Name column is included in the HTML report as well.

The following list describes all fields and their purpose as included in the HTML guidance reports.

Id

Each guidance rule is assigned a unique id. Use this id to uniquely identify a specific message from the guidance report.

Name

The Name column displays a mnemonic name uniquely identifying the guidance rule. These names are designed to assist in memorizing specific guidance rules in the view.

Severity

The Severity column allows the easy identification of the importance of a guidance rule.

Full Name

The Full Name provides a less cryptic name compared to the mnemonic name in the Name column.

Categories

Most messages are grouped within different categories. This allows the GUI to display groups of messages within logical categories under common tree nodes in the Guidance view.

Threshold

The Threshold column displays an expected threshold value, which determines whether or not a rule is met. The threshold values are determined from many applications that follow good design and coding practices.

Actual

The Actual column displays the values actually encountered on the specific design. This value is compared against the expected value to see if the rule is met.

Details

The Details column provides a brief but specific message describing the specifics of the current rule.

Resolution

The Resolution column provides a pointer to common ways the model source code or tool transformations can be modified to meet the current rule. Clicking the link brings up a pop-up window or the documentation with tips and code snippets that you can apply to the specific issue.

All kernel optimizations using OpenCL or C/C++ can be performed from within the SDAccel environment. The primary performance optimizations, such as those discussed in this chapter (pipelining function and loops, applying dataflow to enable greater concurrency between functions and loops, unrolling loops, etc.), are performed by the Xilinx® FPGA design tool, Vivado® High-Level Synthesis (HLS) tool.

The SDAccel environment automatically calls the HLS tool. However, to use the GUI analysis capabilities, you must launch the HLS tool directly from within the SDAccel environment. Using the HLS tool in standalone mode enables the following enhancements to the optimization methodology:

• Focusing solely on the kernel optimization, there is no requirement to execute emulation.
• The ability to create multiple solutions, compare their results, and explore the solution space to find the most optimum design.
• The ability to use the interactive Analysis Perspective to analyze the design performance.

To open the HLS tool in standalone mode, from the Assistant window, right-click the hardware function object, and select Open HLS Project, as shown in the following figure.

Figure: Open HLS Project

SDx development environment provides a smooth flow from an OpenCL/C/C++ model all the way to an FPGA accelerated implementation. In most cases, this flow completely abstracts away the underlying fact that the programmable region in the FPGA is configured to implement the kernel functionality. This fully isolates the developer from typical hardware constraints such as routing delays and kernel placement. However, in some cases these concerns will have to be looked at especially when large designs are to be implemented. Towards this end, SDx development environment allows you to fully control the Vivado Design Suite backend tool.

The SDAccel environment calls the Vivado Design Suite to automatically run RTL synthesis and implementation. You also have the option of launching the design suite directly from within the SDAccel environment. When invoking the Vivado Integrated Design Environment (IDE) in standalone mode in the SDAccel environment, you can open the Vivado synthesis project or the Vivado implementation project to edit, manage, and control the project.

The Vivado project can be opened in the SDAccel environment after the build targeting the System configuration has completed.

To open Vivado IDE in standalone mode, from the Xilinx drop-down menu, select Vivado Integration and Open Vivado Project. Choose between the Vivado synthesis and implementation projects, and click OK.

Using the Vivado IDE in standalone mode enables the exploration of various synthesis and implementation options for further optimizing the kernel for performance and area. Familiarity with the design suite is recommended to make the most use of these features.

 --xp "vivado_prop:run.impl_1.{STEPS.PLACE_DESIGN.ARGS.TCL.POST}={<File and path>}"

This optimization flow is supported in the command line flow by calling xocc –interactive to bring up the Vivado IDE, on the current project. In the IDE, generate a DCP, which can be saved and reused during linking with xocc. The specific options are:

• --interactive allows the Vivado IDE to be launched from within the xocc environment, with the right project loaded.
• --reuse_synth allows a pre-synthesized Vivado Design Suite tool design checkpoint (.dcp) file to be brought in and used directly in SDx environment flow to complete implementation and xclbin generation.
• --reuse_impl allows a pre-implemented and timing closed Vivado tool design checkpoint (.dcp) file to be brought in and used directly in SDx environment flow for xclbin generation.