Pipelines continue to execute as long as data is available at the
input of the pipeline. If there is no data available to process, the pipeline will
stall. This is shown in the following figure, where the
Input Data Valid signal goes low to indicate there is no more valid
input data. Once the signal goes high, indicating there is new data available to
process, the pipeline will continue operation.
In some cases, it is desirable to have a pipeline that can be
“emptied” or “flushed.” The
flush option is
provided to perform this. When a pipeline is “flushed” the pipeline stops reading
new inputs when none are available (as determined by a data
valid signal at the start of the pipeline) but continues processing,
shutting down each successive pipeline stage, until the final input has been
processed through to the output of the pipeline.
As described below, Vitis HLS
will automatically select the right pipeline style to use for a given pipelined loop
or function. However, you can override this default behavior by using the
command to specify the
default pipeline style.
You can also specify the pipeline style for functions or loops with
the PIPELINE pragma or directive. This option applies to the specific scope of the
pragma or directive and does not change the global default assigned by
flp types of pipelines use the standard pipeline logic
where the hardware pipeline created use various kinds of blocking signals to stall
the pipeline. These blocking signals often become the driver of a high-fanout net,
especially on pipelines that are deep in the number of physical stages and work on
significant data sizes. Such high fanout nets, when they are created, are the prime
cause of timing closure issues which cannot be fixed in RTL/Logic Synthesis or
during Place-and-Route. To solve this issue, a new type of pipeline implementation
called free-running pipeline (or
frp) was created. The free-running pipeline is the
most efficient architecture for handling a pipeline that operates with blocking
signals. This is because
- It completely eliminates the blocking signal connections to the register enables
- It is a fully flushable pipeline, which allows bubbling invalid transactions
- Unlike the previous architectures which distribute fanouts (across flops), this reduces the fanouts
- It does not rely on the synthesis and/or place and route optimizations such as flop cloning
- This helps PnR by creating a structure where the wire length is reduced along with the reduction of the high fanouts
But there is a cost associated with this fanout reduction:
- the size of the FIFO buffers required for the blocking output ports causes additional resource usage.
- the mux delay at those blocking output ports
- the potential performance hit due to early validation of forward-pressure triggers
frp) can only be called from within a DATAFLOW region. The
frpstyle cannot be applied to a loop that is called in a sequential or a pipelined region.
The three types of pipelines available in the tool are summarized in
the following table. Vitis HLS will
automatically select the right pipeline style to use for a given pipelined loop or
function. If the pipeline is used with
the flushing pipeline (FLP) style is automatically selected to avoid deadlocks. If
the pipeline control requires high fanout, and meets other free-running
requirements, the tool will select the free-running pipeline (FRP) style to limit
the high fanout. Finally, if neither of the above cases apply, then the standard
pipeline (STP) style is selected.
|Name||Stalled Pipeline||Free-Running/ Flushable Pipeline||Flushable Pipeline|
||When flushable is required for better performance or avoiding deadlock.|
flp) are compatible with the rewind option specified in the PIPELINE pragma or directive when the
config_compile -enable_auto_rewindoption is also enabled.