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.

  1. Avoid using arrays of bool. An array of bool has different memory layout between ARM GCC and Vivado® HLS.
  2. 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.