Flushing Pipelines - 2022.1 English

Vitis High-Level Synthesis User Guide (UG1399)

Document ID
UG1399
ft:locale
English (United States)
Release Date
2022-04-20
Version
2022.1 English

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 data. Once there is new data available to process, the pipeline will continue operation.

Figure 1. Loop Pipelining with Stall

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.

The default style of pipelining implemented by Vitis HLS is defined by the config_compile -pipeline_style command. You can specify stalling pipelines (stp), or free-running flushing pipelines (frp) to be used throughout the design. You can also define a third type of flushable pipeline (flp) with the PIPELINE pragma or directive, using the enable_flush option. This option applies to the specific scope of the pragma or directive only, and does not change the global default assigned by config_compile.

The three types of pipelines available in the tool are summarized in the following table:
Table 1. Pipeline Types
Name Stalled Pipeline (default) Free-Running/ Flushable Pipeline Flushable Pipeline
Global Setting config_compile -pipeline_style stp (default) config_compile -pipeline_style frp config_compile -pipeline_style flp
Pragma/Directive #pragma HLS pipeline style=stp #pragma HLS pipeline style=frp #pragma HLS pipeline style=flp
Advantages
  • Default pipeline. No usage constraints.
  • Typically the lowest overall resource usage.
  • Better timing due to
    • Less fanout
    • Simpler pipeline control logic
  • Flushable
  • Flushable
Disadvantages
  • Not flushable, hence it can:
    • Cause more deadlocks in dataflow
    • Prevent already computed outputs from being delivered, if the inputs to the next iterations are missing
  • Timing issues due to high fanout on pipeline controls
  • Moderate resource increase due to FIFOs added on outputs
  • Can have larger II
  • Greater resource usage due to less sharing(II>1)
Use cases
  • When there is no timing issue due to high fanout on pipeline control
  • When flushable is not required (such as no performance or deadlock issue due to stall)
  • When you need better timing due to fanout to register enables from pipeline control
  • When flushable is required for better performance or avoiding deadlock
  • When flushable is required for better performance or avoiding deadlock