SDSCC/SDS++ Compiler Commands

This section describes theSDSoC™sds++compiler commands and options.

Note: sdsccand sds++are compilers based on GCC, and therefore support many standard GCC options which are not documented here. For information refer to the GCC Option Index.

Compiler Commands

sdscc – SDSoC C compiler
sds++ - SDSoC C++ compiler

Command Synopsis

sdscc | sds++ [hardware_function_options] [system_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] [-debug-xrf] [-debug-xrf-cc compiler] [-sds-pf-path path] [-sds-image image_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, seeHardware 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, seeSDSCC/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][-disable-ip-cache] [-dm-sharing <0-3>] [-dmclkid clock_id_number] [-emulation mode] [-impl-strategy ] [-instrument-stub] [-maxthreads number] [-mno-bitstream][-mno-boot-files] [-rebuild-hardware] [-remote-ip-cache cache_directory] [-synth-strategy ] [-trace] [-trace-buffer depth] [-trace-no-sw] [-maxjobs ] [-sdcard ][-vpl-ini ini_file] [-xp parameter_value]]

For details on these commands, seeSystem Options.

Thesds++compiler compiles and links C/C++ source files into an application-specific hardware/software system-on-a-chip (SoC) implemented on aZynq®-7000 SoCorZynq® UltraScale+™ MPSoCdevice.

The command usage and options are identical forsdsccandsds++. Options not recognized bysds++are passed to theArm®cross-compiler. Compiler options within an-sds-hw ... -sds-endclause are ignored for the-c foo.coption whenfoo.cis 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/platforms/are used. If a user-defined linker script is required, it can be specified using the–Wl,-T –Wl,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/reportsfolder.

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 theLD_LIBRARY_PATHenvironment variable.

Optional PL Configuration After Linux Boot

When sds++creates a bitstream .binfile in the sd_cardfolder, 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 anysds++invocation or your display information.

Table 1.General Options
Option Valid Values Description
-sds-pf Specifies the target platform that defines the base system hardware and software, including operation system and boot files. Thecan be the name of a platform in theSDSoCenvironment 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-listoption to list available platforms.

-sds-pf-info Displays general information about a platform. Use the–sds-pf-listoption to list available platforms. The information displayed includes available system configurations that can be specified with the-sds-sys-configsystem_configuration option.

can be the name of a platform in theSDSoCenvironment 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-configsystem_configuration option.
-sds-sys-config Specifies the system configuration that defines the software platform used, which includes the target operating system and other settings. The-sds-pf-listand-sds-pf-infooptions can be used to list the available system configurations for a platform.

When the-sds-sys-configoption is used, do not specify the-target-osoption. If the-sds-sys-configoption is not specified, the default system configuration is used.

can be any of the available system configurations for a platform.

-sds-proc Specifies the processor name to use with the system configuration defined by the-sds-sys-configoption. A system configuration normally specifies a target CPU and this option is not required.

specifies the target CPU to use.

-sds-pf-path Specifies a search path for platforms. The specified path can contain one or more sub-folders, each of which is a platform folder.

is a search path for platforms.

-sds-image Used with the-sds-sys-configoption, this specifies the SD card image to use. If this option is not specified, the default image is used.

specifies the SD card image to use.

-target-os <linux|standalone|freertos> Specifies the target operating system. The selected OS determines the compiler toolchain used and includes file and library paths added bysds++. For a list of validos_nameoptions, use the commandsdscc -sds-pf-info .

If the-sds-sys-configsystem_configuration option is specified, do not specify the-target-osoption, because a system configuration itself defines a target operating system.

If you do not specify the-sds-sys-configbut do specify the-target-osoption,SDSoCsearches for a system configuration with an OS that matches the one specified by-target-os.

-debug-xrf N/A CreatesVivado®HLS debug cross reference information when compiling functions for hardware, adding the config_debug Tcl command.
-debug-xrf-cc Specifies the compiler executable used to compile accelerator source files for debug cross reference symbols (defaults toxcppif not specified). If the path to the executable is not defined, use the PATH from the environment. If used, specify-debug-xrf-ccfor both compile and link command lines.
-verbose N/A Prints verbose output to STDOUT.
-version N/A Prints thesds++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 tosds++invocations used to compile a source file.

Hardware Function Options

Hardware function options provide a means to consolidatesdscc/sds++options within aMakefileto simplify command line calls and make minimal modifications to a pre-existingMakefile.

The -sds-hwand -sds-endoptions are used in pairs:
  • The-sds-hwoption begins the description of a single function being moved into hardware.
  • -sds-endoption terminates the list of configuration details for that function.
For the next function moved into hardware, there is another pair with -sds-hwas the start of the configuration and -sds-endas the terminator.
The Makefilefragment below illustrates the use of –sds-hwblocks to collect all options in the SDSFLAGS Makefilevariable and to replace an original definition of CCwith sds++ ${SDSFLAGS}. Thus the original Makefilefor an application can be converted to an sds++compiler Makefilewith 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 Ansds++command line can include zero or more–sds-hwblocks. 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-hwblock matches the source file to be compiled, the options are applied. Options outside of–sds-hwblocks are applied where applicable.

When using the xfOpenCV library, thefunction_nameis the template function instantiation enclosed in double quotes, for example"auCanny<1080,1920,0,0,3,2,1,1,1>", and the file is the source file containing the template function instantiation, for exampleau_canny_tb.cpp.

-clkid has one of the values listed in theClock ID Values by Platformtable.

Sets the accelerator clock ID to, wherehas one of the values listed in theClock ID Values by Platformtable. (You can use the commandsds++ –sds-pf-info platform_nameto display the information about a platform.) If theclkidoption is not specified, the default value for the platform is used. Use the commandsds++ –sds-pf-listto list available platforms and settings.

-files file_list file_listis a list of one or more files required to compile the current top-level function into hardware usingVivadoHLS. Specifies a comma-separated list (without white space) of one or more files required to compile the current top-level function into hardware usingVivadoHLS. 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-filesoption specifies the path to the source file containing the function template definition, for exampleau_canny.hpp.

-hls-target boolean_value boolean_valueis0|1 When set to 1, inVivadoHLSadd_filescommands, insert-targetandArmGNU toolchain include options in addition to-m32or-m64options.

When set to 0, insert-m32or-m64options.

Use this option if the default behavior results in target dependent compilation errors.

When specified outside of-sds-hw/-sds-endblocks, the option applies to all hardware functions.

-hls-target-flags "target_options" "target_options"are options in theVivadoHLSadd_filescommand. Specifies a list of target options to use in place of automatically inserted options in theVivadoHLSadd_filescommand, for example-m32or-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 theVivadoHLS tool to synthesize the hardware accelerator, source the specified Tcl file containing HLS directives. During HLS synthesis,sds++creates arun.tclfile used to drive theVivadoHLS tool. In this Tcl file, the following commands are inserted:
# synthesis directives create_clock -period  set_clock_uncertainty 27.0% config_rtl -reset_level low source  # end synthesis directives

If the–hls-tcloption is used, the user-defined Tcl file is sourced after the synthesis directives generated by theSDSoCenvironment.

-shared-aximm N/A Shares AXIMM ports instead of enabling multiple ports.
-sds-end N/A Specifies the end of the-sds-hwoptions for the specifiedfunction_name.

Clock ID Values by Platform

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

SDSCC/SDS++ Performance Estimation Flow Options

A full bitstream compile can take much more time than a software compile, so thesdscc/sds++(referred to assds++) 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 theEstimate Performancecheck box. This enables performance estimation for the current build configuration and builds the project.

Figure:Setting Estimate Performance in Application Project Settings

Estimating the speed-up is a two phase process:

  1. TheSDSoCenvironment compiles the hardware functions and generates the system. Instead of synthesizing the system to bitstream, thesds++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.
  2. In the generated Performance Report, to determine a performance baseline and the performance estimate, selectClick Hereto run an instrumented version of the software on the target .

See theSDSoC 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-funcsoption to specify functions to profile and-perf-rootto specify the root function encompassing calls to the profiled functions.

Thesds++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 calledswdata.xml, which contains the runtime performance data for the run.

Copy theswdata.xmlto 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-rootfunction in the first pass run. Use the–perf-estoption to specifyswdata.xmlas input data for this build.

Table 3.Commonly used sds++ options. The following table specifies thesds++system compiler options normally used to build an application.
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 isswdata.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_cardimage on the board for collecting profile data, type cd /; sync; umount /mnt;. This ensures that the swdata.xmlfile is written out to the SD card.

Compiler Macros

Predefined macros allow you to guard code with#ifdefand#ifndefpreprocessor statements. The macro names begin and end with two underscore characters ‘_’. The__SDSCC__macro is defined wheneversdsccorsds++(referred to collectively assds++) is used to compile source files. It can be used to guard code depending on whether it is compiled bysds++or another compiler, for exampleGCC.

Whensds++compiles source files targeted for hardware acceleration usingVivadoHLS, 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  #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 VivadoHLS 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 forVivadoHLS headers and is visible toVivadoHLS,SDSoCanalysis 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 forZynq-7000 SoCandZynq UltraScale+ MPSoCArmtargets.

System Options

Table 4.System Options
Option Description
-ac : 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 MonitorIP block to monitor all generated hardware/software interfaces. Within theSDSoCdevelopment environment, in the Debug perspective, you can activate the APM prior to running your application by clicking theStartbutton within the Performance Counters View. See theSDSoC Environment Getting Started Tutorial(UG1028)for more information.
-bsp-config-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
-bsp-config-merge-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.
-debug-port function:argument

Specifies a function and argument to monitor using a System ILA module. Multiple-debug-portoptions can be specified, instantiating a System ILA as needed. To specify the instance name and port to monitor instead, use the-dkoption (sds++maps-debug-portto-dkoptions).

-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-cacheoption forcessds++to synthesize all IP cores in the context of the design and might reduce resource usage enough to enable implementation.
-dmclkid Sets the data motion network clock ID to, wherehas one of the values listed inClock ID Values by Platform. You can use the commandsds++ –sds-pf-info platform_nameto display the information about the platform. If thedmclkidoption is not specified, the default value for the platform is used. Use the commandsds++ –sds-pf-listto list available platforms and settings.
-dk chipscope:instance:port Specifies an instance name and port to monitor using a System ILA module. Multiple-dkoptions can be specified, instantiating a System ILA as needed. For special cases, use the option--xp param:compiler.userPostSysLinkTcl=to specify a Tcl file containingVivadoIP integratorTcl commands to post-process the System ILA in the block diagram after system linking and before synthesis.
Note: --dkis 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-bitstreamto exit, review/_sds/p0/dk_list_ports.txt, and update the command line to create the bitstream.
Note: --dkis also accepted.
-dm-sharing The–dm-sharing 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 thesds++-dm-sharing 3option.
-emulation Generates files required to run emulation of the system using QEMU for the processing subsystem and theVivadoLogic Simulator for the programmable logic. This only works on boards that enable this flow (currentlyXilinxbase platforms only). Thespecifies the type of simulation models created for the PL,debug, oroptimized. In the same directory that you ransds++, type thesdsoc_emulatorcommand to run the emulation in the current shell.
-impl-strategy Specifies theVivadoimplementation strategy name to use instead of the default strategy, for example Performance_Explore. The strategy name can be found in theVivadoImplementation Settings dialog box in the Strategy menu, and the strategies are described inthis linkin theVivado Design Suite User Guide: Implementation(UG904).
Note:When creating the Tcl file for synthesis and implementation, this command is added: set_property strategy [get_runs impl_1].
-instrument-stub The–instrument-stuboption instruments the generated hardware function stubs with calls to the counter functionsds_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 The-maxjobs option specifies the maximum number of jobs used forVivadosynthesis. The default is the number of cores divided by 2.
-maxthreads The–maxthreads option specifies the number of threads used in multithreading to speed up certain tasks, includingVivadoplacement 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 theVivadoimplementation 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 foldersd_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 thesd_cardfolder 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 Specifies the path to a directory used for IP caching forVivadosynthesis. The use of an IP cache can reduce the amount of time required for logic synthesis for subsequent runs. The option--remote_ip_cacheis also accepted.
-sdcard Specifies an optional directory containing additional files to include in the SD card image.
-synth-strategy Specifies theVivadosynthesis strategy name to use instead of the default strategy (for example, Flow_RuntimeOptimized). The strategy name can be found in theVivadoSynthesis Settings dialog box in the Strategy menu and the strategies are described inthis linkin theVivado Design Suite User Guide: Synthesis(UG901). When creating the Tcl file for synthesis and implementation, this command is added:set_property strategy [get_runs synth_1].
-trace The–traceoption inserts hardware and software infrastructure into the design to enable tracing functionality.
-trace-buffer The-trace-bufferoption 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-swoption inserts hardware trace monitors into the design without instrumenting the software when enabling tracing functionality.
-vpl-ini Specifies an initialization file containing one-xp per line, but do not include the-xpoption itself. This is equivalent to specify multiple-xpoptions on the command line. Advanced users can use this option to customize theVivadosynthesis and implementation flows.
-xp Specifies aVivadosynthesis or implementation property or parameter, optionally enclosed in double quotes. Theuses one of the following forms to set aVivadoproperty or parameter, respectively.
"vivado_prop:run.run_name.=" "vivado_param:="

Familiarity with theVivadotool suite is recommended to make the most use of these parameters.

The first two examples set aVivadoproperty 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 byVivadoand is equivalent to using thesds++-maxthreadsoption. It illustrates a method for setting aVivadoparameter:

"vivado_param:general.maxThreads=1"

Advanced users can use the-xpoption to customize theVivadosynthesis and implementation flows. The--xpoption is also accepted.

Normally,Vivadoimplementation does not produce a bitstream if there are timing violations. To forcesds++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, seeClock ID Values by Platform.

Merge Options

Table 5.Merge Options
Option Description
-merge Specify one or more inputSDSoCdevelopment environment project directories to be merged to create a single design (each contains _sds sub-directory).
-o Specify output directory to create the merged design (if omitted, use the current directory).
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

TheSDSoCenvironment uses the same GNUArmcross-compiler toolchains included with theXilinxSoftware Development Kit (SDK).

The Linaro-based GCC compiler toolchains support theZynq-7000 SoCandZynq UltraScale+ MPSoCfamily 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 theSDSoCenvironment. AllSDSoCprovided software libraries and software components (Linux kernel, root filesystem, BSP libraries, and other pre-built libraries) are built with the included toolchains. If you usesdscc/sds++(referred to assds++) 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 differentZynq-7000 SoCfloating-point application binary interface (ABI), your binary objects are incompatible and cannot be linked withSDSoCZynq-7000binary objects and libraries.

The following table summarizes thesds++usage ofZynq-7000 SoCtoolchains and options. Where options are listed, you need to specify them only if you use the toolchaingccandg++commands directly instead of invokingsds++.

Table 6.sds++ Usage withZynq-7000 SoC
Usage Description
Zynq-7000Armbare-metal compiler and linker options -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard
Zynq-7000Armbare-metal linker options -Wl,--build-id=none -specs=

Where thecontains

*startfile:

crti%O%s crtbegin%O%s

Zynq-7000Armbare-metal compiler ${SDSOC_install}/SDK/gnu/aarch32//gcc-arm-none-eabi/bin

Toolchain prefix:arm-none-eabi

gcc executable:arm-none-eabi-gcc

g++ executable:arm-none-eabi-g++

Zynq-7000SDSoCbare-metal software (lib, include) ${SDSOC_install}/aarch32-none
Zynq-7000ArmLinux compiler ${SDSOC_install}/SDK/gnu/aarch32//gcc-arm-linux-gnueabi/bin

Toolchain prefix:arm-linux-gnueabihf-

gcc executable:arm-linux-gnueabihf-gcc

g++ executable:arm-linux-gnueabihf-g++

Zynq-7000SDSoCLinux software (lib, include) ${SDSOC_install}/aarch32-linux

The following table summarizessds++usage ofZynq UltraScale+ MPSoCCortex™-A53 toolchains and options. Where options are listed, you only need to specify them if you use the toolchaingccandg++commands directly instead of invokingsds++.

Table 7.sds++ Usage withZynq UltraScale+ MPSoCCortex-A53
Usage Description
Zynq UltraScale+ MPSoCArmbare-metal compiler and linker options -mcpu=cortex-a53 -DARMR5 -mfloat-abi=hard -mfpu=vfpv3-d16
Zynq UltraScale+ MPSoCArmbare-metal linker options -Wl,--build-id=none
Zynq UltraScale+ MPSoCArmbare-metal compiler ${SDSOC_install}/SDK/gnu/aarch64//aarch64-none/bin

Toolchain prefix:aarch64-none-elf

gcc executable:aarch64-none-elf-gcc

g++ executable:aarch64-none-elf-g++

Zynq UltraScale+ MPSoCSDSoCbare-metal software (lib, include) ${SDSOC_install}/aarch64-none
Zynq UltraScale+ MPSoCArmLinux compiler ${SDSOC_install}/SDK/gnu/aarch64//aarch64-linux/bin

Toolchain prefix:aarch64-linux-gnu-

gcc executable:aarch64-linux-gnu-gcc

g++ executable:aarch64-linux-gnu-g++

Zynq UltraScale+ MPSoCSDSoCLinux software (lib, include) ${SDSOC_install}/aarch64-linux

The following table summarizes thesds++usage ofZynq UltraScale+ MPSoCCortex-R5 toolchains and options. Where options are listed, you need to specify them only if you use the toolchaingccandg++commands directly instead of invokingsds++.

Table 8.sds++ Usage withZynq UltraScale+ MPSoCCortex-R5
Usage Description
Zynq UltraScale+ MPSoCArmbare-metal compiler and linker options -mcpu=cortex-r5 -DARMR5 -mfloat-abi=hard -mfpu=vfpv3-d16
Zynq UltraScale+ MPSoCArmbare-metal linker options -Wl,--build-id=none
Zynq UltraScale+ MPSoCArmbare-metal compiler ${SDSOC_install)/SDK/gnu/armr5//gcc-arm-none-eabi/bin

Toolchain prefix:armr5-none-eabi

gcc executable:armr5-none-eabi-gcc

g++ executable:armr5-none-eabi-g++

Zynq UltraScale+ MPSoCSDSoCbare-metal software (lib, include) ${SDSoC_install}/armr5-none
IMPORTANT:When using sds++to compile Zynq-7000source files, be aware that SDSoCtools 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 withsds++, or you can add thesds++command line option-mno-irfor 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).

For the latter solution, if you are using theSDSoCenvironment, you can apply the option on a per-file basis by right-clicking the source file, selectPropertiesand go to theSettingsdialog box underC/C++ Build Settings>Settings.

Figure:Build Settings