Top-Level Hardware Function Guidelines
Use Standard C99 Data Types for Top-Level Hardware Function Arguments
This section describes coding guidelines to ensure that a Vivado HLS hardware function has a consistent interface with object code generated by the ARM GNU toolchain.
- Avoid using arrays of
bool
. An array ofbool
has different memory layout between ARMGCC
and Vivado® HLS. - Avoid using
ap_int<>, ap_fixed<>, hls::stream
, except with data width of 8, 16, 32 or 64 bits.
Omit HLS Interface Directives for Top-Level Hardware Function Arguments
A top-level hardware function should not contain any
HLS interface
pragmas. In this case, the SDSoC environment generates appropriate HLS interface directives. There are two SDSoC environment pragmas you can specify for a top-level hardware function to guide the SDSoC environment to generate the desired HLS interface directives.
#pragma SDS data zero_copy()
can be used to generate a shared memory interface implemented as an AXI master interface in hardware.#pragma SDS data access_pattern(argument:SEQUENTIAL)
can be used to generate a streaming interface implemented as a FIFO interface in hardware.
Important:If you specify the interface using
#pragma HLS interface
for a top-level function argument, the SDSoC environment does not generate a HLS interface directive for that argument, and it is your responsibility to ensure that the generated hardware interface is consistent with all other function argument hardware interfaces. Because a function with incompatible HLS interface types can result in cryptic
sdscc
error messages, it is strongly recommended (though not absolutely mandatory) that you omit
HLS interface
pragmas.