System Options

-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. For more information on the SDSoC IDE, see Introduction.

-disable-ip-cache

Do not use a cache of pre-synthesized IP cores. The use of IP caching for synthesis 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 SDSoC to synthesize all IP cores in the context of the design and may reduce resource usage enough to enable implementation.

-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 sdscc -dm-sharing 3 option.

-dmclkid <n>

Set the data motion network clock ID to <n>, where <n> has one of the values listed in the table below. (You can use the command sdscc –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 sdscc –sds-pf-list to list available platforms and settings.

Platform Value of <n>
zc702 0 – 166 MHz
1 – 142 MHz
2 – 100 MHz
3 – 200 MHz
zc706 0 – 166 MHz
1 – 142 MHz
2 – 100 MHz
3 – 200 MHz
zed and microzed 0 – 166 MHz
1 – 142 MHz
2 – 100 MHz
3 – 200 MHz
zybo 0 – 25 MHz
1 – 100 MHz
2 – 125 MHz
3 – 50 MHz
zcu102_es1 0 – 100 MHz
1 – 150 MHz
2 – 200 MHz
3 – 300 MHz
zcu102_es2 0 – 100 MHz
1 – 150 MHz
2 – 200 MHz
3 – 300 MHz

-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. 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 command sdsoc_emulator 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 in the Strategy menu, and the strategies are described in Vivado Design Suite User Guide: Implementation (UG904). When creating the Tcl file for synthesis and implementation, this command is added: set_property strategy <strategy_name> [get_runs impl_1].

-impl-tcl tcl_file

Specify a Vivado Tcl file containing synthesis and implementation commands to use instead of the commands normally generated by sdscc/sds++. The code block below is an example of an sdscc/sds++ Tcl file generated to run Vivado synthesis and implementation for the user design (for example <working_directory>/_sds/p0/ipi/top.impl.tcl):
# ***************************************************
# Open the Vivado Project
# ***************************************************
open_project /home/user/test/_sds/p0/ipi/zc702.xpr
# ***************************************************
# Run synthesis and implementation
# ***************************************************
set_property STEPS.OPT_DESIGN.IS_ENABLED true [get_runs impl_1]
set_property STEPS.OPT_DESIGN.ARGS.DIRECTIVE Default [get_runs impl_1]
reset_run synth_1
launch_runs synth_1 -jobs 16
wait_on_run synth_1
set synth_ok 0
set synth_status [get_property STATUS [get_runs synth_1]]
set synth_progress [get_property PROGRESS [get_runs synth_1]]
if {$synth_status == "synth_design Complete!" && $synth_progress == "100%"} {
  set synth_ok 1
}
if {$synth_ok == 0} {
  puts "ERROR: \[SDSoC 0-0\]: Synthesis failed : status $synth_status : progress
 $synth_progress"
  exit 1
}
launch_runs impl_1 -to_step write_bitstream
wait_on_run impl_1
# ***************************************************
# Save bitstream for SD card creation
# ***************************************************
set bitstream [get_property top [current_fileset]].bit
set directory [get_property directory [current_run]]
file copy -force [file join $directory $bitstream] [file join $directory bitstre
am.bit]
If the -impl-tcl option is specified, the synthesis and implementation commands are replaced with a command to source the specified Tcl file. At a minimum, the Tcl file must include the commands listed in the comments (launch_runs, reset_run, wait_on_run) and use the run names synth_1 and impl_1:
# ***************************************************
# Open the Vivado Project
# ***************************************************
open_project /home/user/test/_sds/p0/ipi/zc702.xpr
# ***************************************************
# Run synthesis and implementation
# ***************************************************
# User synthesis and implementation TCL was specified.
# It must include these commands and run names : 
#   launch_runs synth_1 -jobs 16
#   reset_run   synth_1
#   wait_on_run synth_1
#   set synth_ok 0
#   set synth_status [get_property STATUS [get_runs synth_1]]
#   set synth_progress [get_property PROGRESS [get_runs synth_1]]
#   if {$synth_status == "synth_design Complete!" && $synth_progress == "100%"} {
#     set synth_ok 1
#   }
#   if {$synth_ok == 0} {
#     puts "ERROR: \[SDSoC 0-0\]: Synthesis failed : status $synth_status : progre
ss $synth_progress"
#     exit 1
#   }
#   launch_runs impl_1  -to_step write_bitstream
#   wait_on_run impl_1
# ***************************************************
source /home/user/test/impl.tcl
# End user implementation TCL
# ***************************************************
# Save bitstream for SD card creation
# ***************************************************
set bitstream [get_property top [current_fileset]].bit
set directory [get_property directory [current_run]]
file copy -force [file join $directory $bitstream] [file join $directory bitstre
am.bit]
The sample impl.tcl Tcl file below uses opt_design and phys_opt_design optimization commands with the Explore directive:
set_property STEPS.OPT_DESIGN.IS_ENABLED true [get_runs impl_1]
set_property STEPS.OPT_DESIGN.ARGS.DIRECTIVE Explore [get_runs impl_1]
set_property STEPS.PHYS_OPT_DESIGN.IS_ENABLED true [get_runs impl_1]
set_property STEPS.PHYS_OPT_DESIGN.ARGS.DIRECTIVE Explore [get_runs impl_1]
reset_run synth_1
launch_runs synth_1 -jobs 16
wait_on_run synth_1
set synth_ok 0
set synth_status [get_property STATUS [get_runs synth_1]]
set synth_progress [get_property PROGRESS [get_runs synth_1]]
if {$synth_status == "synth_design Complete!" && $synth_progress == "100%"} {
  set synth_ok 1
}
if {$synth_ok == 0} {
  puts "ERROR: \[SDSoC 0-0\]: Synthesis failed : status $synth_status : progress
 $synth_progress"
  exit 1
}
launch_runs impl_1 -to_step write_bitstream
wait_on_run 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 will 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.

-poll-mode <0|1>

The –poll-mode <0|1> option enables DMA polling mode when set to 1 or interrupt mode when set to 0 (default). For example, to specify DMA polling mode, add the sdscc -poll-mode 1 option.

-rebuild-hardware

When building a software-only design with no functions mapped to hardware, sdscc uses a pre-built bitstream if available within the platform, but use this option to force a full system build.

-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 in the Strategy menu, and the strategies are described in 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-no-sw

The –trace-no-sw option inserts hardware trace monitors into the design without instrumenting the software when enabling tracing functionality.