Troubleshooting Compile and Link Time Errors
Typical compile/link time errors are indicated by error messages issued when runningmake. To probe further, look at the log files andrptfiles in the_sds/reportssubdirectory 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 toCoding 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. SeeImproving Hardware Function Parallelismfor 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/*.logand 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 inImproving 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.