Troubleshooting Compile and Link Time Errors
Typical compile/link time errors are indicated by error messages issued when running make. To probe further, look at the log files and rpt files in the _sds/reports subdirectory created by the SDSoC™ environment in the build directory. The most recently generated log file usually indicates the cause of the error, such as a syntax error in the corresponding input file, or an error generated by the tool chain while synthesizing accelerator hardware or the data motion network.
Some tips for dealing with SDSoC environment specific errors follow.
- Tool errors reported by tools in the SDSoC environment
chain.
- Check whether the corresponding code adheres to Coding Guidelines.
- Check the syntax of pragmas.
- Check for typos in pragmas that might prevent them from being applied to the correct function.
- Vivado Design Suite High-Level Synthesis (HLS) cannot
meet timing requirement.
- Select a slower clock frequency for the
accelerator in the SDSoC IDE (or with the
sdscc/sds++
command line parameter). - Modify the code structure to allow HLS to generate a faster implementation. See Improving Hardware Function Parallelism for more information on how to do this.
- Select a slower clock frequency for the
accelerator in the SDSoC IDE (or with the
- Vivado tools cannot meet timing.
- In the SDSoC IDE, select a slower clock
frequency for the data motion network or
accelerator, or both (from the command line, use
sdscc/sds++
command line parameters). - Synthesize the HLS block to a higher clock frequency so that the synthesis/implementation tools have a bigger margin.
- Modify the C/C++ code passed to HLS, or add more HLS directives to make the HLS block go faster.
- Reduce the size of the design in case the resource usage (see the Vivado tools report in _sds/ipi/*.log and other log files in the subdirectories there) exceeds 80% or so. See the next item for ways to reduce the design size.
- In the SDSoC IDE, select a slower clock
frequency for the data motion network or
accelerator, or both (from the command line, use
- Design too large to fit.
- Reduce the number of accelerated functions.
- Change the coding style for an accelerator function to produce a more compact accelerator. You can reduce the amount of parallelism using the mechanisms described in Improving Hardware Function Parallelism.
- Modify pragmas and coding styles (pipelining) that cause multiple instances of accelerators to be created.
- Use pragmas to select smaller data movers such as AXIFIFO instead of AXIDMA_SG.
- Rewrite hardware functions to have fewer input and output parameters/arguments, especially in cases where the inputs/outputs are continuous stream (sequential access array argument) types that prevent sharing of data mover hardware.