Vitis カーネルまたは Vivado IP の実行モードは、ブロック レベルの制御プロトコルと HLS デザイン内の下位関数の構造によって定義されます。制御駆動型 TLP では、ap_ctrl_chain
および ap_ctrl_hs
プロトコルがシーケンシャル実行とパイプライン実行の両方をサポートします。データ駆動型 TLP の場合、ap_ctrl_none
は必須の制御プロトコルです。
Vitis カーネル フローのデフォルトは、ap_ctrl_chain
制御プロトコルです (Vitis カーネル フローのインターフェイス を参照)。Vivado IP フローのデフォルトは ap_ctrl_hs
ブロック レベル制御プロトコルです (Vivado IP フローのインターフェイス を参照)。ただし、HLS デザインを連結する場合は、ap_ctrl_chain
を使用すると、パイプライン処理の実行がさらにサポートされるようになります。
ap_return
出力ポートを作成します。s_axilite
) として指定される場合、制御プロトコルのポートがすべて s_axilite
インターフェイスにまとめられます。これは、アプリケーションやソフトウェア ドライバーがブロックの動作の開始および停止を設定および制御するのに使用される場合に、ソフトウェア制御可能なカーネルや IP によく使用される方法です。これは、XRT および Vitis カーネルフローの要件です。ap_ctrl_chain
次の図に、順次実行デザインの ap_ctrl_chain
制御プロトコルで作成されるブロック レベルのハンドシェイク信号の動作を示します。次の図では、ap_done
が High で ap_continue
が High なので、HLS デザインの最初のトランザクションの終了直後に、2 つ目のトランザクションが開始しますが、ap_continue
が High にアサートされなければ、2 つ目のトランザクションが終了すると停止します。
-
ap_start
が High になるとブロックが操作を開始します。 -
ap_idle
出力は即座に Low になり、デザインがアイドル状態でなくなったことを示します。 -
ap_start
信号はap_ready
が High になるまで High のままである必要があります。ap_ready
が High になると、次のようになります。-
ap_start
が High のままの場合、次のトランザクションを開始します。 -
ap_start
が Low になると、現在のトランザクションが完了して、操作を停止します。
-
- 入力ポートからデータを読み出せるようになります。
- 出力ポートにデータを書き込めるようになります。注記: 入力ポートおよび出力ポートでは、制御プロトコルからは独立したポート レベルの I/O プロトコルも指定できます。詳細は、Vivado IP フローのポート レベルのプロトコルを参照してください。
- ブロックの操作が完了すると、
ap_done
出力が High になります。注記:ap_return
ポートがある場合、このポートの値はap_done
が High なると有効になります。つまり、ap_done
信号はap_return
出力のデータが有効であることも示します。 -
ap_ctrl_chain
制御プロトコルがアクティブ High のap_continue
信号を提供すると、出力データを使用するダウンストリーム ブロックが新しいデータ入力を読み出す準備ができたことを示します。これにより、ダウンストリーム ブロックがバック プレッシャーを提供できるようになり、データのフローが発生しないようにできます。-
ap_done
が High のときにap_continue
が High の場合、デザインは動作を継続します。 - ダウンストリーム ブロックで新しいデータ入力を消費できない場合は、
ap_continue
が Low になります。ap_done
が High の時にap_continue
の信号が Low になると、デザインは動作を停止し、ap_done
信号は High のままap_continue
が High になるのを待ちます。
-
- デザインが新しい入力を受信可能な状態になると、
ap_ready
信号が 1 クロック サイクル間 High になります。ダウンストリーム ブロックのap_ready
ポートはap_continue
ポートを直接駆動できます。次に、ap_ready
信号に関する追加情報を示します。-
ap_ready
信号はデザインが動作を始めるまで非アクティブ (Low) です。 - パイプライン処理されていないデザインでは、
ap_ready
信号はap_done
と同時にアサートされます。 - パイプライン処理されたデザインでは、
ap_start
が High になった後のどのサイクルでもap_ready
信号が High になる可能性があります。これは、デザインがどのようにパイプライン処理されたかによって異なります。 -
ap_ready
が High になった後、ap_start
が High のままであれば、次のトランザクションが即座に開始されます。 -
ap_ready
が High になった直後にap_start
が Low になった場合、デザインはap_done
が High になるまで実行し続け、その間にap_start
が再び High になって新しいトランザクションが開始されない限り、動作を停止します。
-
-
ap_idle
は、デザインがアイドル状態で動作していないことを示します。次に、ap_idle
信号に関する追加情報を示します。-
ap_ready
が High のときにap_start
が Low になると、デザインは動作を停止し、ap_idle
はap_done
の 1 サイクル後に High になります。 -
ap_ready
が High のときにap_start
が High になると、デザインは動作を継続し、ap_idle
は Low のままになります。
-
ap_ctrl_hs
ap_ctrl_hs
制御プロトコルは、ap_ctrl_chain
と同じ信号を持ちますが、ap_continue
信号を 1 に設定し、High の状態を維持します。この制御プロトコルは、シーケンシャルおよびパイプライン実行モードをサポートしますが、データのフローを制御するためのダウンストリーム デザイン モジュールからのバック プレッシャーは提供しません。
ap_ctrl_none
ap_ctrl_none
も ap_ctrl_chain
と同じ信号を持ちますが、ハンドシェイク信号ポート (ap_start
、ap_idle
、ap_ready
、および ap_done
) は High に設定され、最適化されて削除されます。
ap_ctrl_none
領域、または 1 つ以上の hls::tasks
は、次の 2 つの方法のいずれかでインスタンシエートできます。
- 最上位自体も含めて、最上位まで
ap_ctrl_none
領域だけ使用してインスタンシエート。たとえば、コーディング ミスによるものであっても、それより上位のどこにもシーケンシャル FSM やap_ctrl_none
以外のデータフローは使用されません。 - もしくは、次のようなデータフロー領域内にインスタンシエート
- その入力ストリームが、その前に呼び出される 1 つまたは複数の
ap_ctrl_none
以外のプロセスまたは領域によって生成される - その出力ストリームが、その後に呼び出される 1 つまたは複数の
ap_ctrl_none
以外のプロセスまたは領域によって消費される
- その入力ストリームが、その前に呼び出される 1 つまたは複数の
前者の場合、ap_start
/ap_ready
/ap_done
/ap_continue
ハンドシェイクを最上位まですべて削除できます。後者の場合、前述のデータフロー領域に対する ap_start
/ap_ready
ハンドシェイクを先行プロセスまたは領域が生成し、ap_done
/ap_continue
ハンドシェイクを後続プロセスまたは領域が生成できます。
ap_ctrl_none
制御プロトコルを使用する場合は、RTL デザインを検証するため、インターフェイス合成用の協調シミュレーション要件 に説明されている C/RTL 協調シミュレーションの条件の少なくとも 1 つを満たす必要があります。これらの条件の少なくとも 1 つでも満たされない場合、次のメッセージが表示されて C/RTL 協調シミュレーションが停止します。@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 ***