Block-Level Control Protocols - 2022.2 English

The execution mode of a Vitis kernel or Vivado IP is defined by the block-level control protocol and the structure of sub-functions within the HLS design. For control-driven TLP the ap_ctrl_chain and ap_ctrl_hs protocols support both sequential or pipelined execution. For data-driven TLP ap_ctrl_none is the required control protocol.

The ap_ctrl_chain control protocol is the default for the Vitis kernel flow as explained in Interfaces for Vitis Kernel Flow. The ap_ctrl_hs block-level control protocol is the default for the Vivado IP flow as described in Interfaces for Vivado IP Flow. However, you should use ap_ctrl_chain when chaining HLS designs together to better support pipelined execution.

ap_ctrl_chain

The following figure shows the behavior of the block-level handshake signals created by the ap_ctrl_chain control protocol. In the following figure, the first transaction of the HLS design completes, and the second transaction starts immediately because ap_continue is High when ap_done is High. However, the design halts at the end of the second transaction until ap_continue is asserted High.

Figure 1. Behavior of ap_ctrl_chain Interface

The timing diagram displays the following behavior after reset occurs:

1. The block waits for ap_start to go High before it begins operation.
2. Output ap_idle goes Low immediately to indicate the design is no longer idle.
3. The ap_start signal must remain High until ap_ready goes High. Once ap_ready goes High:
   • If ap_start remains High the design will start the next transaction.
   • If ap_start is taken Low, the design will complete the current transaction and halt operation.
4. Data can be read on the input ports.
5. Data can be written to the output ports.
   Note: The input and output ports can also specify a port-level I/O protocol that is independent of the control protocol. For details, see Port-Level Protocols for Vivado IP Flow.
6. Output ap_done goes High when the block completes operation.
   Note: If there is an ap_return port, the data on this port is valid when ap_done is High. Therefore, the ap_done signal also indicates when the data on output ap_return is valid.
7. The ap_ctrl_chain control protocol provides an active-High ap_continue signal that indicates when the downstream block that consumes the output data is ready for new data inputs. This allows the downstream block to provide back-pressure to prevent the flow of data.
   • If the ap_continue signal is High when ap_done is High, the design continues operating.
   • If the downstream block is not able to consume new data inputs, the ap_continue signal is Low. If the ap_continue signal is Low when ap_done is High, the design stops operating, the ap_done signal remains High waiting for ap_continue to go High.
8. When the design is ready to accept new inputs, the ap_ready signal goes High. The ap_ready port of a downstream block can directly drive the ap_continue port. Following is additional information about the ap_ready signal:
   • The ap_ready signal is inactive until the design starts operation.
   • In non-pipelined designs, the ap_ready signal is asserted at the same time as ap_done.
   • In pipelined designs, the ap_ready signal might go High at any cycle after ap_start is sampled High. This depends on how the design is pipelined.
   • If the ap_start signal is Low when ap_ready is High, the design executes until ap_done is High and then stops operation.
   • If the ap_start signal is High when ap_ready is High, the next transaction starts immediately, and the design continues to operate.
9. The ap_idle signal indicates when the design is idle and not operating. Following is additional information about the ap_idle signal:
   • If the ap_start signal is Low when ap_ready is High, the design stops operation, and the ap_idle signal goes High one cycle after ap_done.
   • If the ap_start signal is High when ap_ready is High, the design continues to operate, and the ap_idle signal remains Low.

@E [SIM-345] Cosim only supports the following 'ap_ctrl_none' designs: (1) 
combinational designs; (2) pipelined design with task interval of 1; (3) designs with 
array streaming or hls_stream ports.
@E [SIM-4] *** C/RTL co-simulation finished: FAIL ***