System Options

Table 1. System Options
Option Description
-ac <function_name>:<clock_id_number> Use the specified clock ID number for an RTL accelerator function in a C-callable IP library instead of the default clock ID.
-apm Insert an AXI Performance Monitor (APM) IP block to monitor all generated hardware/software interfaces. Within the SDSoC™ IDE, 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 Tutorial: Introduction (UG1028) for more information.
-bsp-config-file <mss_file> Specify 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> Specify 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

Specify 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> Set 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 Specify 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 List 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> Generate 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> Specify 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 runtimes 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> Specify 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> Specify an optional directory containing additional files to include in the SD card image.
-synth-strategy <strategy_name> Specify 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 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> Specify 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 <parameter_value> Specify 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