Description
This directive performs all operations sequentially in a C/C++
description. In the absence of any directives that limit resources (such as set_directive_allocation), Vitis HLS seeks to minimize latency and improve concurrency. Data
dependencies can limit this. For example, functions or loops that access arrays must
finish all read/write accesses to the arrays before they complete. This prevents the
next function or loop that consumes the data from starting operation.
However, it is possible for the operations in a function or loop to
start operation before the previous function or loop completes all its operations.
syn.directive.dataflow specifies that dataflow
optimization be performed on the functions or loops, improving the concurrency of
the RTL implementation. When syn.directive.dataflow
is specified, the HLS tool analyzes the dataflow between sequential functions or
loops and creates channels. The channels are based on ping-pong RAMs or FIFOs that
allow consumer functions or loops to start operation before the producer functions
or loops complete. Functions or loops can operate in parallel, decreasing latency
and improving the throughput of the RTL.
syn.dataflow.xxx command specifies the default memory
channel and FIFO depth used by syn.directive.dataflow as explained
in Dataflow Configuration.For the DATAFLOW optimization to work, the data must flow through the design from task to task. One should pay special attention to the following situations. Refer to Limitations of Control-Driven Task-Level Parallelism and Dataflow Region Coding Style for more details.
- Single-producer-consumer violations
- Feedback between tasks
- Conditional execution of tasks
- Loops with multiple exit conditions
Finally, the DATAFLOW optimization is not hierarchical by default. If a sub-function or loop contains additional tasks that might benefit from the DATAFLOW optimization, apply optimization to the loop and the sub-function. You can also inline the sub-function.
Syntax
syn.directive.dataflow=<location> disable_start_propagation-
<location>is the location (in the formatfunction[/label]) at which dataflow optimization is to be performed. -
disable_start_propagationdisables the creation of a start FIFO used to propagate a start token to an internal process. Such FIFOs can sometimes be a bottleneck for performance.
Examples
Specifies DATAFLOW optimization within function foo.
syn.directive.dataflow=foo