Vitis HLS designs can be control-driven modules or data-driven modules, as described in Abstract Parallel Programming Model for HLS. This means that the execution of the HLS design is managed through control signals, and managed by an external software application, or by software drivers, or is driven by the presence of data at the inputs.
Data-driven modules are auto-restarting designs by the mere fact of additional data to be processed. The HLS design finishes execution of one transaction and begins execution of the next transaction when data is available. Execution stalls when no data is present, and restarts when data is present. This section is not concerned with these data-driven designs.
For control-driven modules though, the managing software application or
a connected HLS design must trigger the
signal of the module to begin processing, as described in Block-Level Control Protocols. While these designs are not auto-restarting by default,
they can be implemented using auto-restarting mechanisms as described here. This
auto-restarting mode is useful for control-drivel TLP when the HLS design uses streaming
I/O for data input or output, but also has control signals allowing it to be managed by
a software application. In this case the software application starts the kernel one time
and the kernel runs for a specified number of transactions, or restarts continuously
until it is reset or explicitly stopped by the software application.
This control-driven auto-restarting design is useful for designs with streaming data coming from and going to the I/O pins (Ethernet, SerDes) of the AMD device, or data streamed from or to connected HLS design modules. In other words, the HLS design is primarily data-driven, but not exclusively.