o The __SDSCC__ macro is defined and passed as a -D option to sub-tools
whenever sdscc or sds++ is used to compile source files, and can be used to guard code dependent on
whether it is compiled by sdscc/sds++ or by another compiler, for example a GNU host compiler.
o When sdscc or sds++ compiles source files targeted for hardware acceleration using Vivado HLS,
the __SDSVHLS__ macro is defined and passed as a -D option, and can be used to guard code dependent
on whether high-level synthesis is run or not.
o In 2017.2 running on the Windows operating system, you will typically have to use these macros
to guard code that will be synthesized within SDx with type long long (which should be 64 bits).
o Vivado HLS employs some 32-bit libraries irrespective of the host machine. Furthermore, the tool
does not provide a true cross-compilation.
All object code for the ARM CPUs is generated with the GNU toolchains, but the sdscc (and sds++) compiler,
built upon Clang/LLVM frameworks, is generally less forgiving of C/C++ language violations than the GNU
compilers. As a result, you might find that some libraries needed for your application cause front-end compiler
errors when using sdscc. In such cases, compile the source files directly through the GNU toolchain rather than
through sdscc, either in your makefiles or by setting the compiler to arm-linux-gnueabihf-g++ by right-clicking on
the file (or folder) in the Project Explorer and selecting C/C++ Build > Settings > SDSCC/SDS++ Compiler.
3.4 Hardware Function Argument Types
The SDSoC™ environment sdscc/sds++ system compilers support hardware function arguments with types
that resolve to a single or array of C99 basic arithmetic type (scalar), a struct or classwhose members flatten to
a single or array of C99 basic arithmetic type (hierarchical structs are supported), an array of struct whose
members flatten to a single C99 basic arithmetic type. Scalar arguments must fit in a 1024-bit container. The
SDSoC™ environment automatically infers hardware interface types for each hardware function argument based
on the argument type and the following pragmas:
#pragma SDS data copy|zero_copy
#pragma SDS data access_pattern
To avoid interface incompatibilities, you should only incorporate Vivado® HLS interface type directives and
pragmas in your source code whensdscc/sds++ fails to generate a suitable hardware interface directive.
Vivado® HLS provides arbitrary precision types ap_fixed<int>, ap_int<int>, and an hls::stream class.
In the SDSoC environment, ap_fixed<int> types must be specified as having widths greater than 7 but
less than 1025 (7 < width < 1025). The hls::stream data type is not supported as the function argument
to any hardware function.
By default, an array argument to a hardware function is transferred by copying the data, that is, it is
equivalent to using #pragma SDS data copy. As a consequence, an array argument must be either used as
an input or produced as an output, but not both. For an array that is both read and written by the hardware
function, you must use #pragma SDS data zero_copy to tell the compiler that the array should be kept in the
shared memory and not copied.
To ensure alignment across the hardware/software interface, do not use hardware function arguments
that are an array of bool.
Important: Pointer arguments for a hardware function require special consideration. Hardware functions
operate on physical addresses, which typically are not available to userspace programs, so pointers cannot be
embedded in data structures passed to hardware functions.
Important:
By default, in the absence of any pragmas, a pointer argument is taken to be a scalar parameter, even
though in C/C++ it might denote a one-dimensional array type. The following are the permitted pragmas.
This pragma provides pointer semantics using shared memory.
#pragma SDS data zero_copy