The code region in which #pragma HLS dataflow resides is referred to as
the "dataflow region." It includes all statements (assignments, conditionals, loops,
function calls, …) within the enclosing loop or function body.
This section explains both:
- a coding style for a dataflow region that allows Vitis HLS to unambiguously infer the network of parallel processes and channels, and ensure “what you see is what you get” (a.k.a. WYSIWYG coding style).
- more advanced dataflow coding styles that require checking the synthesis results in the Vitis GUI to ensure that the desired dataflow structure has been achieved.
The diamond function in the previous section is an example that follows the coding style, also known as the “canonical form.” The following example uses “non-canonical” form due to the use of code other than function calls in the dataflow region:
void noncanonical(int Input0, int Input1[], int &Output0, int Output1[]) {
#pragma HLS dataflow
int C0, C1[N], C2;
C0 = Input0 * 3;
for (int i = 0; i < N; i++) {
C1[i] = Input1[0] + 2;
}
func2(C0, C1, C2);
func3(C2, Output0, Output1);
}The canonical coding style results in a dataflow network that directly matches the function calls given in the source code, it is thus more predictable for the user, in terms of both performance and structure. The non-canonical example requires Vitis HLS to create the network by analyzing loops, function calls, control, grouping them into function calls following dataflow rules. It is therefore less direct for the user. Regardless of the form that is used, it is recommended that you use the Vitis IDE HLS Dataflow Viewer and Cosimulation Timeline Trace to check your implementation and its performance.
Vitis HLS also emits some messages for
non-canonical dataflow syntax. By default, messages can be warnings but can be changed
to errors or be disabled via the syn.dataflow.strict_mode configuration option as described in Dataflow Configuration.