The execution mode of the HLS design refers to the way the design works as a block (or module) both with regard to itself and the functions within the block, or in relationship with other blocks modules, or outside software that addresses the block. These modes are determined by block control protocols assigned to the HLS design as described in Block-Level Control Protocols, and by the internal structure of the HLS design as described in Abstract Parallel Programming Model for HLS.
Overlapping Mode
Let the next execution of a new transaction begin before the current transaction is complete. Function pipelined, loop rewind or dataflow execution allows overlapping block runs to begin processing additional data as soon as the design is ready.
-
Control Protocols: Uses
ap_ctrl_chain
orap_ctrl_hs
with backpressure support. Backpressure is a mechanism that allows downstream modules to control the flow of data. If a downstream module is not ready to receive new data, it can assert a signal to stall the upstream modules temporarily. This prevents data loss and ensures synchronization across different stages of the pipeline.
Sequential Mode
Requires the current transaction to complete before a new transaction can be started.
-
Control Protocols: Can be implemented using
ap_ctrl_hs
orap_ctrl_chain
without backpressure support. By eliminating backpressure, the design assumes that data is consumed at a consistent rate, and there is no need for flow control between stages.
Continuously Running Mode
Continuously running kernels run indefinitely until explicitly reset or run for a certain
number of times, making them fundamentally different from classical software
acceleration kernels. In contrast to traditional software kernels that are called,
execute, and return upon completion, continuously running kernel continuously executes,
mimicking a while(1)
loop. These kernels are especially useful in
hardware contexts where data streams in without predefined boundaries or known
completion points.
Continuously running kernel are commonly used in applications where data is continuously fed into the system, and the kernel must process it without interruption. Examples include:
-
Networking: Handling incoming data packets from Ethernet ports without the host system knowing the total number of packets in advance. For instance, a kernel might process packets from
TVALID
(valid data) toTLAST
(last packet), with continuous execution. -
Firewall: A simple rule-based firewall where the rules are written once by the host at reset, and the kernel processes packets continuously. The host can read packet drop counters at any time, but these counters are the result of a single kernel execution.
- Network Routing: A network router that updates its routing table during execution but doesn't stop to process incoming packets continuously.
-
Load Balancing: A load balancer that routes data based on a hash map, updating server lists and IP addresses while continuously handling traffic.
-
Fintech: Financial applications where data packets from Ethernet ports are processed continuously, and the host loosely monitors the execution status without interrupting the ongoing operations.
Control Protocols: Continuously Running mode can be modeled using both the scenarios.
- Control Driven Task-level Parallelism (CDTLP) in auto-restart mode using
ap_ctrl_chain
block level protocol. - Data-driven Task-level Parallelism (DTLP) using
ap_ctrl_none
block level protocol.