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 will explain the coding style for a dataflow region that allows Vitis HLS to unambiguously infer the network of parallel processes and channels ensure “what you see is what you get” (also known as WYSIWYG).
The above diamond function 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; // first process
for (int i = 0; i < N; i++) { // first process or second process?
C1[i] = Input1[0] + 2;
}
func2(C0, C1, C2); // second process or third process?
func3(C2, Output0, Output1); // third process or fourth process?
}The canonical example produces a resulting dataflow network that is more predictable, in terms of both performance and structure. The non-canonical example is less predictable because there the designer may not know the network implemented by Vitis HLS. For any non-canonical code Vitis HLS does its best to implement the resulting network (or errors out if the violations are fatal, for example when the consumer of an array occurs before the producer in the source code).
Regardless of the form that is used, it is recommended that you use the Vitis Unified IDE HLS Co-Simulation Dataflow Viewer and Timeline Trace to check your implementation and performance.
Vitis HLS will also emit some messages for
non-canonical dataflow syntax. By default messages will be warnings but can be changed
to errors or be disabled via the syn.dataflow.strict_mode configuration
option as described in Dataflow Configuration.