sds++/sdscc Compiler Commands
This section describes theSDSoC™sds++
compiler commands and options.
sds++/sdscc
compilers are 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] [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, 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.
Merge Options
[-merge input_project_directory [input_project_directory]* [-o output_project_directory] [-emulation ] [-disable-ip-cache] [-maxjobs number] [-maxthreads number] [-mno-bitstream] [-mno-boot-files] [-remote-ip-cache cache_directory] [-xp xpvalue]]
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] [-debug-port function:argument] [-disable-ip-cache] [-dk chipscope:instance:port] [-dm-sharing sharing_level] [-dmclkid clock_id_number] [-emulation ] [-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, 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 forsdscc
andsds++
. Options not recognized bysds++
are passed to theArm®cross-compiler. Compiler options within an-sds-hw ... -sds-end
clause are ignored for the-c foo.c
option whenfoo.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–Wl,-T –Wl,
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/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.
System 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.
Options not recognized bysds++
are passed to theArm®cross-compiler. Compiler options within an-sds-hw ... -sds-end
clause are ignored for the-c foo.c
option whenfoo.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–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
Whensds++
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.
Option | Valid Values | Description |
---|---|---|
-sds-pf |
|
Specifies the target platform that defines the base system hardware and software, including operation system and boot files. The can 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-info |
|
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.
|
-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 |
|
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-proc |
|
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.
|
-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.
|
-sds-image |
|
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.
|
-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_name options, use the commandsdscc -sds-pf-info .If the If you do not specify the |
-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 toxcpp 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 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.
-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.
-sds-hw
as the start of the configuration and
-sds-end
as the terminator.
–sds-hw
blocks to collect all options in the
SDSFLAGS
Makefilevariable and to replace an original definition of
CC
with
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} $<
Option | Valid Values | Description |
---|---|---|
-sds-hw function_name source_file |
N/A | Ansds++ 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 |
-clkid |
has one of the values listed in theClock ID Values by Platformtable. |
Sets the accelerator clock ID to |
-files file_list |
file_list is 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 |
-hls-target boolean_value |
boolean_value is0|1 |
When set to 1, inVivadoHLSadd_files commands, insert-target andArmGNU toolchain include options in addition to-m32 or-m64 options.When set to 0, insert Use this option if the default behavior results in target dependent compilation errors. When specified outside of |
-hls-target-flags "target_options" |
"target_options" are options in theVivadoHLSadd_files command. |
Specifies a list of target options to use in place of automatically inserted options in theVivadoHLSadd_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 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:
If the |
-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 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 thesds++/sdscc
(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:
- TheSDSoCenvironment 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, 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-funcs
option to specify functions to profile and-perf-root
to 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-root
function in the first pass run. Use the–perf-est
option to specifyswdata.xmlas input data for this build.
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. |
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#ifdef
and#ifndef
preprocessor statements. The macro names begin and end with two underscore characters ‘_’. The__SDSCC__
macro is defined wheneversdscc
orsds++
(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.
__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
__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
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 |
-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 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 , where has one of the values listed inClock ID Values by Platform. You can use the commandsds++ –sds-pf-info platform_name to display the information about the platform. If thedmclkid option is not specified, the default value for the platform is used. Use the commandsds++ –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= 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:
--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 , and update the command line to create the bitstream.
Note:
--dk is 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 3 option. |
-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). The specifies the type of simulation models created for the PL,debug , oroptimized . In the same directory that you ransds++ , type thesdsoc_emulator command 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 .
|
-instrument-stub |
The–instrument-stub option 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_cache is 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 . |
-trace |
The–trace option inserts hardware and software infrastructure into the design to enable tracing functionality. |
-trace-buffer |
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 |
Specifies an initialization file containing one-xp 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 theVivadosynthesis and implementation flows. |
-xp |
Specifies aVivadosynthesis or implementation property or parameter, optionally enclosed in double quotes. The uses one of the following forms to set aVivadoproperty or parameter, respectively.
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:
The following example sets the maximum number of threads used byVivadoand is equivalent to using the
Advanced users can use the Normally,Vivadoimplementation does not produce a bitstream if there are timing violations. To force
|
Clock ID Values by Platform
For a list of clock ID values by platform, seeClock ID Values by Platform.
Merge Options
The sds++ merge command supports a subset of sds++ linking 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:
|
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 toolchaingcc
andg++
commands directly instead of invokingsds++
.
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 the
|
Zynq-7000Armbare-metal compiler | ${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin Toolchain prefix: gcc executable: g++ executable: |
Zynq-7000SDSoCbare-metal software (lib, include) | ${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi |
Zynq-7000ArmLinux compiler | ${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin Toolchain prefix: gcc executable: g++ executable: |
Zynq-7000SDSoCLinux software (lib, include) | ${SDX_install}/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi |
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 toolchaingcc
andg++
commands directly instead of invokingsds++
.
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 | ${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-none/bin Toolchain prefix: gcc executable: g++ executable: |
Zynq UltraScale+ MPSoCSDSoCbare-metal software (lib, include) | ${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-none |
Zynq UltraScale+ MPSoCArmLinux compiler | ${SDX_install}/SDK/2019.1/gnu/aarch64/lin/aarch64-linux/bin Toolchain prefix: gcc executable: g++ executable: |
Zynq UltraScale+ MPSoCSDSoCLinux software (lib, include) | ${SDX_install}/SDK/2019.1/gnu/aarch64/lin/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 toolchaingcc
andg++
commands directly instead of invokingsds++
.
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 | ${SDX_install}/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin Toolchain prefix: gcc executable: g++ executable: |
Zynq UltraScale+ MPSoCSDSoCbare-metal software (lib, include) | ${SDX_install}/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi |
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-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).