Execution Modes of HLS Designs - 2025.1 English - UG1399

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.

Execution modes of kernels include:

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: Use the ap_ctrl_chain or ap_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 or ap_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) to TLAST (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.

Auto-Restarting

Auto-restart mode lets the HLS design automatically restart the module when it is ready to begin processing additional data. This mode supports both overlapping and sequential execution. Auto-restarting is the approach for data-driven TLP designs, but can also be implemented in control-driven TLP designs as described in Auto-Restarting Mode.