sds++/sdscc Compiler Commands

Command Synopsis

sdscc/sds++
           [hardware_function_options] [system_options]
           [merge_options] [performance_estimation_options]
           [options_passed_through_to_cross_compiler]
           [-sds-pf platform_name] [-sds-pf-info platform_name]
           [-sds-pf-list] [-sds-sys-config configuration_name]
           [-sds-proc processor_name] [-target-os os_name]
           [-sds-pf-path path] [-sds-image image_name]
           [-sds-clang-filter option_file]
           [-debug-xrf] [-debug-xrf-cc compiler_name]
           [-verbose] [-version] [--help] [files]

Hardware Function Options

[-sds-hw function_name source_file
               [-clkid clock_id_number]
               [-files hls_file_list]
               [-hls-target boolean_value]
               [-hls-target-flags "target_options"]
               [-hls-tcl hls_tcl_directives_file]
               [-shared-aximm]
               -sds-end]*

For detail on these commands, see Hardware Function Options.

Performance Estimation Options

[[-perf-funcs function_name_list -perf-root function_name]
               | [-perf-est data_file] [-perf-est-hw-only]]

For detail on these commands, see SDSCC/SDS++ Performance Estimation Flow Options.

Merge Options

[-merge input_project_directory [input_project_directory]*
           [-o output_project_directory]
           [-emulation <mode>]
           [-disable-ip-cache]
           [-maxjobs number]
           [-maxthreads number]
           [-mno-bitstream]
           [-mno-boot-files]
           [-remote-ip-cache cache_directory]
           [-xp xpvalue]]

For detail on these commands, see SDSCC/SDS++ Performance Estimation Flow Options.

System Options

[[-ac function_name:clock_id_number]* [-apm]
           [-bsp-config-file mss_file] [-bsp-config-merge-file mss_file]
           [-debug-port function:argument]
           [-disable-ip-cache] [-dk chipscope:instance:port]
           [-dm-sharing sharing_level]
           [-dmclkid clock_id_number] [-emulation <mode>]
           [-impl-strategy implementation strategy] [-instrument-stub]
           [-maxjobs number] [-maxthreads <1-8>] [-mno-bitstream]
           [-mno-boot-files] [-rebuild-hardware]
           [-remote-ip-cache cache_directory]
           [-sdcard data_directory]
           [-synth-strategy synthesis_strategy]
           [-trace] [-trace-no-sw] [-trace-buffer]
           [-vpl-ini ini_file] [-xp xpvalue]]

For details on these commands, see System Options.

The sds++ compiler compiles and links C/C++ source files into an application-specific hardware/software system-on-a-chip (SoC) implemented on a Zynq®-7000 SoC or Zynq® UltraScale+™ MPSoC device.

The command usage and options are identical for sdscc and sds++. Options not recognized by sds++ are passed to the Arm® cross-compiler. Compiler options within an -sds-hw ... -sds-end clause are ignored for the -c foo.c option when foo.c is not the file containing the specified hardware function.

When linking the application ELF, sds++ creates and implements the hardware system. It also generates an SD card image containing the ELF and boot files required to initialize the hardware system, configures the programmable logic, and runs the target operating system.

When linking application ELF files for non-Linux targets, for example Standalone or FreeRTOS, default linker scripts found in the folder <install_path>/platforms/<platform_name> are used. If a user-defined linker script is required, it can be specified using the –Wl,-T –Wl,<path_to_linker_script> linker option.

When building a system that has no hardware accelerated functions,sds++ can reduce build time by using pre-built hardware provided by the target platform.

Report and log files are found in the _sds/reports folder.

When running Linux applications that use shared libraries, the libraries must be contained in the root file system or SD card and the path to the libraries added to the LD_LIBRARY_PATH environment variable.

System Options

The sds++ compiler compiles and links C/C++ source files into an application-specific hardware/software system-on-a-chip (SoC) implemented on a Zynq®-7000 SoC or Zynq® UltraScale+™ MPSoC device.

Options not recognized by sds++ are passed to the Arm® cross-compiler. Compiler options within an -sds-hw ... -sds-end clause are ignored for the -c foo.c option when foo.c is not the file containing the specified hardware function.

When linking the application ELF, sds++ creates and implements the hardware system. It also generates an SD card image containing the ELF and boot files required to initialize the hardware system, configures the programmable logic, and runs the target operating system.

When linking application ELF files for non-Linux targets, for example Standalone or FreeRTOS, default linker scripts found in the folder <install_path>/platforms/<platform_name> are used. If a user-defined linker script is required, it can be specified using the –Wl,-T –Wl,<path_to_linker_script> linker option.

When building a system containing no functions marked for hardware implementation, sds++ uses pre-built hardware when available for the target platform.

Report and log files are found in the _sds/reports folder.

When running Linux applications that use shared libraries, the libraries must be contained in the root file system or SD card and the path to the libraries added to the LD_LIBRARY_PATH environment variable.

Optional PL Configuration After Linux Boot

When sds++ creates a bitstream .bin file in the sd_card folder, it can be used to configure the PL after booting Linux and before running the application ELF. The embedded Linux command used is

cat bin_file >
        /dev/xdevcfg

.

General Options

The following command line options are applicable for any sds++ invocation or your display information.

Table 1. General Options
Option	Valid Values	Description
`-sds-pf <platform_name>`	`<platform_name>`	Specifies the target platform that defines the base system hardware and software, including operation system and boot files. The `<platform_name>` can be the name of a platform in the SDSoC environment installation or a file path to a folder containing platform files with the last component of the path matching the platform name. The platform defines the base hardware and software, including operation system and boot files. Use this option when compiling accelerator source files and when linking the ELF file. Use the `–sds-pf-list` option to list available platforms.
`-sds-pf-info <platform_name>`	`<platform_name>`	Displays general information about a platform. Use the `–sds-pf-list` option to list available platforms. The information displayed includes available system configurations that can be specified with the `-sds-sys-config` system_configuration option. `<platform_name>` can be the name of a platform in the SDSoC environment installation or a file path to a folder containing platform files.
`-sds-pf-list`	N/A	Displays a list of available platforms and exit (if no other options are specified). The information displayed includes available system configurations that can be specified with the `-sds-sys-config` system_configuration option.
`-sds-sys-config <configuration_name>`	`<configuration_name>`	Specifies the system configuration that defines the software platform used, which includes the target operating system and other settings. The `-sds-pf-list` and `-sds-pf-info` options can be used to list the available system configurations for a platform. When the `-sds-sys-config` option is used, do not specify the `-target-os` option. If the `-sds-sys-config` option is not specified, the default system configuration is used. `<configuration_name>` can be any of the available system configurations for a platform.
`-sds-proc <processor_name>`	`<processor_name>`	Specifies the processor name to use with the system configuration defined by the `-sds-sys-config` option. A system configuration normally specifies a target CPU and this option is not required. `<processor_name>` specifies the target CPU to use.
`-sds-pf-path <path>`	`<path>`	Specifies a search path for platforms. The specified path can contain one or more sub-folders, each of which is a platform folder. `<path>` is a search path for platforms.
`-sds-image <image_name>`	`<image_name>`	Used with the `-sds-sys-config` option, this specifies the SD card image to use. If this option is not specified, the default image is used. `<image_name>` specifies the SD card image to use.
`-target-os <os_name>`	<`linux` \| `standalone` \| `freertos`>	Specifies the target operating system. The selected OS determines the compiler toolchain used and includes file and library paths added by `sds++`. For a list of valid `os_name` options, use the command `sdscc -sds-pf-info <plat_name>`. If the `-sds-sys-config` system_configuration option is specified, do not specify the `-target-os` option, because a system configuration itself defines a target operating system. If you do not specify the `-sds-sys-config` but do specify the `-target-os` option, SDSoC searches for a system configuration with an OS that matches the one specified by `-target-os`.
`-debug-xrf`	N/A	Creates Vivado® HLS debug cross reference information when compiling functions for hardware, adding the config_debug Tcl command.
`-debug-xrf-cc <compiler>`	`<compiler>`	Specifies the compiler executable used to compile accelerator source files for debug cross reference symbols (defaults to `xcpp` if not specified). If the path to the executable is not defined, use the PATH from the environment. If used, specify `-debug-xrf-cc` for both compile and link command lines.
`-verbose`	N/A	Prints verbose output to STDOUT.
`-version`	N/A	Prints the `sds++` version information to STDOUT.
`--help`	N/A	Prints command line help information. Note that two consecutive hyphen or dash characters `-` are used.

The following command line options are applicable only to sds++ invocations used to compile a source file.

Hardware Function Options

Hardware function options provide a means to consolidate sdscc/sds++ options within a Makefile to simplify command line calls and make minimal modifications to a pre-existing Makefile.

The -sds-hw and -sds-end options are used in pairs:

The -sds-hw option begins the description of a single function being moved into hardware.
-sds-end option terminates the list of configuration details for that function.

For the next function moved into hardware, there is another pair with -sds-hw as the start of the configuration and -sds-end as the terminator.

The Makefile fragment below illustrates the use of –sds-hw blocks to collect all options in the SDSFLAGS Makefile variable and to replace an original definition of CC with sds++ ${SDSFLAGS}. Thus the original Makefile for an application can be converted to an sds++ compiler Makefile with minimal changes.

APPSOURCES = add.cpp main.cpp
EXECUTABLE = add.elf
 
CROSS_COMPILE = arm-xilinx-linux-gnueabi-
AR = ${CROSS_COMPILE}ar
LD = ${CROSS_COMPILE}ld
#CC = ${CROSS_COMPILE}g++
PLATFORM = zc702
SDSFLAGS = -sds-pf ${PLATFORM} \
           -sds-hw add add.cpp -clkid 1 -sds-end \
           -dmclkid 2
CC = sds++ ${SDSFLAGS} 

INCDIRS = -I..
LDDIRS =
LDLIBS =
CFLAGS = -Wall -g -c ${INCDIRS}
LDFLAGS = -g ${LDDIRS} ${LDLIBS}
 
SOURCES := $(patsubst %,../%,$(APPSOURCES))
OBJECTS := $(APPSOURCES:.cpp=.o)
 
.PHONY: all
 
all: ${EXECUTABLE}
 
${EXECUTABLE}: ${OBJECTS}
 ${CC} ${OBJECTS} -o $@ ${LDFLAGS}
 
%.o: ../%.cpp
 ${CC} ${CFLAGS} $<

Table 2. Hardware Function Options
Option	Valid Values	Description
`-sds-hw function_name source_file`	N/A	An `sds++` command line can include zero or more `–sds-hw` blocks. Each block is associated with a top-level hardware function specified as the first argument and its containing source file specified as the second argument. If the file name associated with an `-sds-hw` block matches the source file to be compiled, the options are applied. Options outside of `–sds-hw` blocks are applied where applicable. When using the xfOpenCV library, the `function_name` is the template function instantiation enclosed in double quotes, for example `"xf::Canny<1080,1920,0,0,3,2,1,1,1>"`, and the file is the source file containing the template function instantiation, for example xf_canny_tb.cpp.
`-clkid <n>`	`<n>` has one of the values listed in the Clock ID Values by Platform table.	Sets the accelerator clock ID to `<n>`, where `<n>` has one of the values listed in the Clock ID Values by Platform table. (You can use the command `sds++ –sds-pf-info platform_name` to display the information about a platform.) If the `clkid` option is not specified, the default value for the platform is used. Use the command `sds++ –sds-pf-list` to list available platforms and settings.
`-files file_list`	`file_list` is a list of one or more files required to compile the current top-level function into hardware using Vivado HLS.	Specifies a comma-separated list (without white space) of one or more files required to compile the current top-level function into hardware using Vivado HLS. If any of these files contain source code that is not used by HLS but is required to produce the application executable, they must be compiled separately to create object files (.o), and linked with other object files during the link phase. When using the xfOpenCV library, the `-files` option specifies the path to the source file containing the function template definition, for example au_canny.hpp.
`-hls-target boolean_value`	`boolean_value` is `0\|1`	When set to 1, in Vivado HLS `add_files` commands, insert `-target` and Arm GNU toolchain include options in addition to `-m32` or `-m64` options. When set to 0, insert `-m32` or `-m64` options. Use this option if the default behavior results in target dependent compilation errors. When specified outside of `-sds-hw`/`-sds-end` blocks, the option applies to all hardware functions.
`-hls-target-flags "target_options"`	`"target_options"` are options in the Vivado HLS `add_files` command.	Specifies a list of target options to use in place of automatically inserted options in the Vivado HLS `add_files` command, for example `-m32` or `-m64`. The options must be enclosed in quotes so they will not be interpreted as compiler options.
`-hls-tcl hls_tcl_directives_file`	N/A	When using the Vivado HLS tool to synthesize the hardware accelerator, source the specified Tcl file containing HLS directives. During HLS synthesis, `sds++` creates a run.tcl file used to drive the Vivado HLS tool. In this Tcl file, the following commands are inserted: `# synthesis directives create_clock -period <clock_period> set_clock_uncertainty 27.0% config_rtl -reset_level low source <sdsoc_generated_tcl_directives_file> # end synthesis directives` If the `–hls-tcl` option is used, the user-defined Tcl file is sourced after the synthesis directives generated by the SDSoC environment.
`-shared-aximm`	N/A	Shares AXIMM ports instead of enabling multiple ports.
`-sds-end`	N/A	Specifies the end of the `-sds-hw` options for the specified `function_name`.

Clock ID Values by Platform

For a list of clock ID values by platform, see Clock ID Values by Platform.

SDSCC/SDS++ Performance Estimation Flow Options

A full bitstream compile can take much more time than a software compile, so the sds++/sdscc (referred to as sds++) applications provide performance estimation options to compute the estimated runtime improvement for a set of hardware function calls.

In the Application Project Settings pane, to invoke the estimator, select the Estimate Performance check box. This enables performance estimation for the current build configuration and builds the project.

Estimating the speed-up is a two phase process:

The SDSoC environment compiles the hardware functions and generates the system. Instead of synthesizing the system to bitstream, the sds++ computes an estimate of the performance based on estimated latencies for the hardware functions and data transfer time estimates for the callers of hardware functions.
In the generated Performance Report, to determine a performance baseline and the performance estimate, select Click Here to run an instrumented version of the software on the target.

See the SDSoC Environment Getting Started Tutorial (UG1028) for a tutorial on how to use the Performance Report.

You can also generate a performance estimate from the command line. As a first pass to gather data about software runtime, use the -perf-funcs option to specify functions to profile and -perf-root to specify the root function encompassing calls to the profiled functions.

The sds++ system compiler then automatically instruments these functions to collect runtime data when the application is run on a board. When you run an instrumented application on the target, the program creates a file on the SD card called swdata.xml, which contains the runtime performance data for the run.

Copy the swdata.xml to the host, and run a build that estimates the performance gain on a per hardware function caller basis and for the top-level function specified by the –perf-root function in the first pass run. Use the –perf-est option to specify swdata.xml as input data for this build.

The following table specifies the sds++ system compiler options normally used to build an application.

Table 3. Commonly used sds++ options
Option	Description
`-perf-funcs function_name_list`	Specifies a comma separated list of all functions to be profiled in the instrumented software application.
`-perf-root function_name`	Specifies the root function encompassing all calls to the profiled functions. The default is the function main.
`-perf-est data_file`	Specifies the file containing runtime data generated by the instrumented software application when run on the target. Estimate performance gains for hardware accelerated functions. The default name for this file is swdata.xml.
`-perf-est-hw-only`	Runs the estimation flow without running the first pass to collect software run data. Using this option provides hardware latency and resource estimates without providing a comparison against baseline.

CAUTION:

After running the sd_card image on the board for collecting profile data, type cd /; sync; umount /mnt;. This ensures that the swdata.xml file is written out to the SD card.

Compiler Macros

Predefined macros allow you to guard code with #ifdef and #ifndef preprocessor statements. The macro names begin and end with two underscore characters ‘_’. The __SDSCC__ macro is defined whenever sdscc or sds++ (referred to collectively as sds++) is used to compile source files. It can be used to guard code depending on whether it is compiled by sds++ or another compiler, for example GCC.

When sds++ compiles source files targeted for hardware acceleration using Vivado HLS, the __SDSVHLS__ macro is defined to be used to guard code depending on whether high-level synthesis is run or not.

The code fragment below illustrates the use of the __SDSCC__ macro to use the sds_alloc() and sds_free() functions when compiling source code with sds++, malloc(), and free() when using other compilers.

#ifdef __SDSCC__
#include <stdlib.h>
#include "sds_lib.h"
#define malloc(x) (sds_alloc(x))
#define free(x) (sds_free(x))
#endif

In the example below, the __SDSVHLS__ macro is used to guard code in a function definition that differs depending on whether it is used by Vivado HLS to generate hardware or used in a software implementation.

#ifdef __SDSVHLS__
void mmult(ap_axiu<32,1,1,1> A[A_NROWS*A_NCOLS],
           ap_axiu<32,1,1,1> B[A_NCOLS*B_NCOLS],
           ap_axiu<32,1,1,1> C[A_NROWS*B_NCOLS])
#else
void mmult(float A[A_NROWS*A_NCOLS],
           float B[A_NCOLS*B_NCOLS],
           float C[A_NROWS*B_NCOLS])
#endif

In addition, the macro, HLS_NO_XIL_FPO_LIB, is defined prior to the include option for Vivado HLS headers and is visible to Vivado HLS, SDSoC analysis tools, and target cross-compilers. This macro disables the use of bit-accurate, floating-point simulation models, instead using the faster (although not bit-accurate) implementation from your local system. Bit-accurate simulation models are not provided for Zynq-7000 SoC and Zynq UltraScale+ MPSoC Arm targets.

System Options

Table 4. System Options
Option	Description
`-ac <function_name>:<clock_id_number>`	Uses the specified clock ID number for an RTL accelerator function in a C-Callable IP library instead of the default clock ID.
`-apm`	Inserts an AXIAXI Performance Monitor IP block to monitor all generated hardware/software interfaces. Within the SDSoC development environment, in the Debug perspective, you can activate the APM prior to running your application by clicking the Start button within the Performance Counters View. See the SDSoC Environment Getting Started Tutorial (UG1028) for more information.
`-bsp-config-file <mss_file>`	Specifies the path to a board support package (BSP) configuration file (.mss) to use instead of an automatically-generated file for a bare-metal based target OS, for example Standalone or FreeRTOS. When using this option, also add an include option specifying the path to your BSP header files: `-I</path/to/includes>`
`-bsp-config-merge-file <mss_file>`	Specifies the path to a board support package (BSP) configuration file (.mss) to use for the base platform and merge using hardware information from the final design to create a BSP configuration file contain user settings for the base platform plus settings for hardware added to the base platform; for example, DMA drivers. This merged BSP configuration file is used instead of an automatically generated file for a bare-metal based target OS, for example, Standalone or FreeRTOS. When using this option, add an include option specifying the path to your BSP header files: `-I</path/to/includes>`.
`-debug-port function:argument`	Specifies a function and argument to monitor using a System ILA module. Multiple `-debug-port` options can be specified, instantiating a System ILA as needed. To specify the instance name and port to monitor instead, use the `-dk` option (`sds++` maps `-debug-port` to `-dk` options).
`-disable-ip-cache`	Do not use a cache of pre-synthesized IP cores. The use of IP caching reduces the overall build time by eliminating the synthesis step for static IP cores. If the resources required to implement the hardware system exceeds available resources by a small amount, the `-disable-ip-cache` option forces `sds++` to synthesize all IP cores in the context of the design and might reduce resource usage enough to enable implementation.
`-dmclkid <n>`	Sets the data motion network clock ID to `<n>`, where `<n>` has one of the values listed in Clock ID Values by Platform. You can use the command `sds++ –sds-pf-info platform_name` to display the information about the platform. If the `dmclkid` option is not specified, the default value for the platform is used. Use the command `sds++ –sds-pf-list` to list available platforms and settings.
`-dk chipscope:instance:port`	Specifies an instance name and port to monitor using a System ILA module. Multiple `-dk` options can be specified, instantiating a System ILA as needed. For special cases, use the option `--xp param:compiler.userPostSysLinkTcl=<file>` to specify a Tcl file containing VivadoIP integrator Tcl commands to post-process the System ILA in the block diagram after system linking and before synthesis. Note: `--dk` is also accepted.
`-dk list_ports`	Lists available instance and port names for System ILA insertion. This option can only be specified when linking the design and you can specify `-mno-bitstream` to exit, review `<pwd>/_sds/p0/dk_list_ports.txt`, and update the command line to create the bitstream. Note: `--dk` is also accepted.
`-dm-sharing <n>`	The `–dm-sharing <n>` option enables exploration of data mover sharing capabilities if the initial schedule can be relaxed. The level of sharing defaults to 0 (low) if not specified. Other values are 1 (medium), 2 (high), and 3 (maximum – schedule can be relaxed infinitely). For example, to enable maximum data mover sharing, add the `sds++` `-dm-sharing 3` option.
`-emulation <mode>`	Generates files required to run emulation of the system using QEMU for the processing subsystem and the Vivado Logic Simulator for the programmable logic. This only works on boards that enable this flow (currently Xilinx base platforms only). The `<mode>` specifies the type of simulation models created for the PL, `debug`, or `optimized`. In the same directory that you ran `sds++`, type the `sdsoc_emulator` command to run the emulation in the current shell.
`-impl-strategy <strategy_name>`	Specifies the Vivado implementation strategy name to use instead of the default strategy, for example Performance_Explore. The strategy name can be found in the Vivado Implementation Settings dialog box in the Strategy menu, and the strategies are described in this link in the Vivado Design Suite User Guide: Implementation (UG904). Note: When creating the Tcl file for synthesis and implementation, this command is added: `set_property strategy <strategy_name> [get_runs impl_1]`.
`-instrument-stub`	The `–instrument-stub` option instruments the generated hardware function stubs with calls to the counter function `sds_clock_counter()`. When a hardware function stub is instrumented, the time required to call send and receive functions, as well as the time spent for waits, is displayed for each call to the function.
`-maxjobs <n>`	The `-maxjobs <n>` option specifies the maximum number of jobs used for Vivado synthesis. The default is the number of cores divided by 2.
`-maxthreads <n>`	The `–maxthreads <n>` option specifies the number of threads used in multithreading to speed up certain tasks, including Vivado placement and routing. The number of threads can be an integer from 1 to 8. The default value is 4, but the tools do not use more threads than the number of cores on the machine. Also, a general limit based on the OS applies to all tasks.
`-mno-bitstream`	Do not generate the bitstream for the design used to configure the programmable logic (PL). Normally a bitstream is generated by running the Vivado implementation feature, which can be time-consuming with run times ranging from minutes to hours depending on the size and complexity of the design. This option can be used to disable this step when iterating over flows that do not impact the hardware generation. The application ELF is compiled before bitstream generation.
`-mno-boot-files`	Do not generate the SD card image in the folder sd_card. This folder includes your application ELF and files required to boot the device and bring up the specified OS. This option disables the creation of the sd_card folder in case you would like to preserve an earlier version of this folder.
`-rebuild-hardware`	When building a software-only design with no functions mapped to hardware, `sds++` uses a pre-built bitstream if available within the platform, but use this option to force a full system build.
`-remote-ip-cache <cache_directory>`	Specifies the path to a directory used for IP caching for Vivado synthesis. The use of an IP cache can reduce the amount of time required for logic synthesis for subsequent runs. The option `--remote_ip_cache` is also accepted.
`-sdcard <data_directory>`	Specifies an optional directory containing additional files to include in the SD card image.
`-synth-strategy <strategy_name>`	Specifies the Vivado synthesis strategy name to use instead of the default strategy (for example, Flow_RuntimeOptimized). The strategy name can be found in the Vivado Synthesis Settings dialog box in the Strategy menu and the strategies are described in this link in the Vivado Design Suite User Guide: Synthesis (UG901). When creating the Tcl file for synthesis and implementation, this command is added: `set_property strategy <strategy_name> [get_runs synth_1]`.
`-trace`	The `–trace` option inserts hardware and software infrastructure into the design to enable tracing functionality.
`-trace-buffer <depth>`	The `-trace-buffer` option specifies the trace buffer depth, which must be at least 16 and a power of 2. If this option is not specified, the default value of 1024 is used.
`-trace-no-sw`	The `–trace-no-sw` option inserts hardware trace monitors into the design without instrumenting the software when enabling tracing functionality.
`-vpl-ini <ini_file>`	Specifies an initialization file containing one `-xp <parameter_value>` per line, but do not include the `-xp` option itself. This is equivalent to specify multiple `-xp` options on the command line. Advanced users can use this option to customize the Vivado synthesis and implementation flows.
`-xp <xpvalue>`	Specifies a Vivado synthesis or implementation property or parameter, optionally enclosed in double quotes. The `<parameter_value>` uses one of the following forms to set a Vivado property or parameter, respectively. `"vivado_prop:run.run_name.<prop_name>=<value>" "vivado_param:<param_name>=<value>"` Familiarity with the Vivado tool suite is recommended to make the most use of these parameters. The first two examples set a Vivado property to specify a post-synthesis and post-optimization Tcl script, respectively: `vivado_prop:run.synth_1.STEPS.SYNTH_DESIGN.TCL.POST=/path/to/postsynth.tcl" "vivado_prop:run.impl_1.STEPS.OPT_DESIGN.TCL.POST=/path/to/postopt.tcl"` The following example sets the maximum number of threads used by Vivado and is equivalent to using the `sds++` `-maxthreads` option. It illustrates a method for setting a Vivado parameter: `"vivado_param:general.maxThreads=1"` Advanced users can use the `-xp` option to customize the Vivado synthesis and implementation flows. The `--xp` option is also accepted. Normally, Vivado implementation does not produce a bitstream if there are timing violations. To force `sds++` to skip the timing violation check and continue, allowing you to proceed and correct timing issues later, you can use this parameter: `param:compiler.skipTimingCheckAndFrequencyScaling=1`

Clock ID Values by Platform

For a list of clock ID values by platform, see Clock ID Values by Platform.

Merge Options

The sds++ merge command supports a subset of sds++ linking options.

Table 5. Merge Options
Option	Description
`-merge <input_dir>`	Specify one or more input SDSoC development environment project directories to be merged to create a single design (each contains _sds sub-directory).
`-o <output_dir>`	Specify output directory to create the merged design (if omitted, use the current directory).
`<other_options>`	The following subset of the System Options are supported: -emulation -disable-ip-cache -impl-strategy -maxjobs -maxthreads -mno-boot-files -mno-bitstream -remote-ip-cache -sdcard -synth-strategy -vpl-ini -xp

Compiler Toolchain Support

The SDSoC environment uses the same GNU Arm cross-compiler toolchains included with the Xilinx Software Development Kit (SDK).

The Linaro-based GCC compiler toolchains support the Zynq-7000 SoC and Zynq UltraScale+ MPSoC family devices. This section includes additional information on toolchain usage.

When compiling and linking applications, use only object files and libraries built using the same compiler toolchain and options as those used by the SDSoC environment. All SDSoC provided software libraries and software components (Linux kernel, root filesystem, BSP libraries, and other pre-built libraries) are built with the included toolchains. If you use sdscc/sds++ (referred to as sds++) to compile object files, the tools automatically insert a small number of options. If you invoke the underlying toolchains, you must use the same options.

For example, if you use a different Zynq-7000 SoC floating-point application binary interface (ABI), your binary objects are incompatible and cannot be linked with SDSoC Zynq-7000 binary objects and libraries.

The following table summarizes the sds++ usage of Zynq-7000 SoC toolchains and options. Where options are listed, you need to specify them only if you use the toolchain gcc and g++ commands directly instead of invoking sds++.

Table 6. sds++ Usage with Zynq-7000 SoC
Usage	Description
Zynq-7000 Arm bare-metal compiler and linker options	`-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard`
Zynq-7000 Arm bare-metal linker options	`-Wl,--build-id=none -specs=<specfile>` Where the `<specfile>` contains `*startfile:` `crti%O%s crtbegin%O%s`
Zynq-7000 Arm bare-metal compiler	`${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin` Toolchain prefix: `arm-none-eabi` gcc executable: `arm-none-eabi-gcc` g++ executable: `arm-none-eabi-g++`
Zynq-7000 SDSoC bare-metal software (lib, include)	`${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi`
Zynq-7000 Arm Linux compiler	`${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin` Toolchain prefix: `arm-linux-gnueabihf-` gcc executable: `arm-linux-gnueabihf-gcc` g++ executable: `arm-linux-gnueabihf-g++`
Zynq-7000 SDSoC Linux software (lib, include)	`${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi`

The following table summarizes sds++ usage of Zynq UltraScale+ MPSoC Cortex™-A53 toolchains and options. Where options are listed, you only need to specify them if you use the toolchain gcc and g++ commands directly instead of invoking sds++.

Table 7. sds++ Usage with Zynq UltraScale+ MPSoC Cortex-A53
Usage	Description
Zynq UltraScale+ MPSoC Arm bare-metal compiler and linker options	`-mcpu=cortex-a53 -DARMR5 -mfloat-abi=hard -mfpu=vfpv3-d16`
Zynq UltraScale+ MPSoC Arm bare-metal linker options	`-Wl,--build-id=none`
Zynq UltraScale+ MPSoC Arm bare-metal compiler	`${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-none/bin` Toolchain prefix: `aarch64-none-elf` gcc executable: `aarch64-none-elf-gcc` g++ executable: `aarch64-none-elf-g++`
Zynq UltraScale+ MPSoC SDSoC bare-metal software (lib, include)	`${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-none`
Zynq UltraScale+ MPSoC Arm Linux compiler	`${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-linux/bin` Toolchain prefix: `aarch64-linux-gnu-` gcc executable: `aarch64-linux-gnu-gcc` g++ executable: `aarch64-linux-gnu-g++`
Zynq UltraScale+ MPSoC SDSoC Linux software (lib, include)	`${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-linux`

The following table summarizes the sds++ usage of Zynq UltraScale+ MPSoC Cortex-R5 toolchains and options. Where options are listed, you need to specify them only if you use the toolchain gcc and g++ commands directly instead of invoking sds++.

Table 8. sds++ Usage with Zynq UltraScale+ MPSoC Cortex-R5
Usage	Description
Zynq UltraScale+ MPSoC Arm bare-metal compiler and linker options	`-mcpu=cortex-r5 -DARMR5 -mfloat-abi=hard -mfpu=vfpv3-d16`
Zynq UltraScale+ MPSoC Arm bare-metal linker options	`-Wl,--build-id=none`
Zynq UltraScale+ MPSoC Arm bare-metal compiler	`${SDX_install}/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin` Toolchain prefix: `armr5-none-eabi` gcc executable: `armr5-none-eabi-gcc` g++ executable: `armr5-none-eabi-g++`
Zynq UltraScale+ MPSoC SDSoC bare-metal software (lib, include)	`${SDX_install}/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi`

IMPORTANT: When using sds++ to compile Zynq-7000 source files, be aware that SDSoC tools that are processing and analyzing source files issue errors if they contain NEON instrinsics. If hardware accelerator (or caller) source files contain NEON intrinsics, guard them using the __SDSCC__ and __SDSVHLS__ macros.

For source files that do not contain hardware accelerators or callers but do use NEON intrinsics, you can either compile them directly using the GNU toolchain and link the objects with sds++, or you can add the sds++ command line option -mno-ir for these source files. This option prevents clang-based tools from being invoked to create an intermediate representation (IR) used in analysis. You are programmatically aware that they are not required (such as no accelerators or callers).