インプリメンテーション デザイン フロー - 2022.1 日本語

Vivado Design Suite チュートリアル: Dynamic Function eXchange (UG947)

Document ID
UG947
Release Date
2022-05-31
Version
2022.1 日本語

この演習では、Nested DFX デザインの各コンフィギュレーションのインプリメントに使用されるコマンドを順を追って実行する Tcl スクリプトのセットを使用します。実行する前に、各スクリプトのそれぞれの動作を確認してください。ほとんどのコマンド (link_design、route_design、pr_verify、write_bitstream など) はこれまでと同じですが、pr_subdivide や pr_recombine は新しいものです。後のスクリプトが前のスクリプトに依存するため、重要なのは実行される順序です。

スクリプトが完了したら、チェックポイント (例: top_route_design.dcp または top_count_up_up_route_design.dcp) を開いて結果を確認し、それらの作成に使用された DFX 属性とコマンドの影響を確認します。

最初のインプリメンテーション デザインの実行では、スタティック デザインと一次リコンフィギャラブル パーティションが構築されます。この段階では、フローは標準的な DFX デザインフローと異なりません。inst_RP はデザイン内で唯一の RP であり、そのレベルよりの下に存在するシフター モジュールはその inst_RP ロジックの残りを使用してインプリメントされます。二次リコンフィギャラブル パーティションはまだ存在しません。

  1. 実行スクリプトを読み込んで、親コンフィギュレーションをインプリメントします。
    source implement_parent_config.tcl -notrace

    作成されるチェックポイント (top_route_design.dcp) は、単一の RP を含む完全なデザイン イメージです。この時点では、RP をブラック ボックスにしたり、スタティック デザインをロックしたりするなどの追加の DFX ステップは実行されていません。このチェックポイントは、ロックされたスタティック デザイン イメージを作成するためにのみ使用され、以降のすべてのデザイン イテレーションで共通のものになります。

    図 1. 一次インプリメンテーション

    implement/top_static フォルダーに書き込まれた top_route_design.dcp を開き、これが標準の DFX であることを確認します。inst_RP には、HD.RECONFIGURABLE プロパティと、そのリコンフィギャラブル パーティションの関連 Pblock が含まれます。
    図 2. 一次インプリメンテーション後にリコンフィギャラブル パーティションは inst_RP のみ

  2. このスクリプトを読み込んで、二次リコンフィギャラブル パーティションを作成します。
    source subdivide_shifters.tcl

    このスクリプトは、inst_rp モジュールを二次リコンフィギャラブル パーティションに分割します。pr_subdivide コマンドは、inst_RP から HD.RECONFIGURABLE プロパティを削除し、inst_shift_upper と inst_shift_lower の両方に適用します。この後、inst_RP に HD.RECONFIGURABLE_CONTAINER プロパティがタグ付けされ、これがかつて RP であったことが示されます。これは、top_static_shifters.dcp チェックポイントを見るとわかります。

    図 3. シフター ファンクションの pr_subdivide 後のデザイン

    図 4. HD.RECONFIGURABLE_CONTAINER プロパティの付いた inst_RP

  3. 二次リコンフィギャラブル パーティションにシフター サブモジュールをインプリメントします。
    source implement_sub_shifters.tcl -notrace

    これで、二次 RP に shift_right および shift_left ファンクションを配置配線する 2 つインプリメンテーション フローが実行されます。ここで使用されるコマンドは、最初のコンフィギュレーションの開始点にロックされた最上位スタティック デザインが含まれるという点を除き、標準 DFX フローと同じです。インプリメンテーションでは、inst_RP レベル (reconfig_shifters) の論理デザインがスタティックとして扱われます。これは、最初のコンフィギュレーション完了後に lock_design -level routing コマンドでロックされる階層レベルです。

    図 5. shift_right をインプリメントしてから shift_left を 2 つの RP にインプリメントする 2 つの二次 run

    このスクリプトは、pr_recombine の呼び出しで終了し、shift_right と shift_right の組み合わせの配線済みデザイン チェックポイントを作成し、HD.RECONFIGURABLE プロパティを inst_RP レベルに戻します。top_shift_right_right_recombined.dcp の階層を見てみると、このプロパティが inst_RP インスタンスに返されたことがわかります。

    図 6. 再結合されたシフター コンフィギュレーションのデザイン階層とプロパティ

  4. このスクリプトを読み込む、もう 1 つの二次リコンフィギャラブル パーティションを作成します。
    source subdivide_counters.tcl

    最初の分割スクリプトと同様、これは初期コンフィギュレーション (top_route_design.dcp) から開始し、inst_RP レベルを分割しますが、今回は 2 つのカウンター ファンクションに分割します。このデザイン バージョンの最上位スタティックは、シフターに使用されるバージョンと同じです。

    図 7. カウンター ファンクションの pr_subdivide 後のデザイン

  5. 二次リコンフィギャラブル パーティションにカウンター サブモジュールをインプリメントします。
    source implement_sub_counters.tcl -notrace

    シフター パスの場合と同様、標準 DFX フローを使用して、二次リコンフィギャラブル パーティションごとに 2 つのカウンター モジュール (count_up、count_down) を処理します。また、シフターと同様、再結合されたデザイン チェックポイントは、二次フローを通過する最初のパスから作成されます。

    2 つの二次インプリメンテーション スクリプト (およびそれより前の分割スクリプト) は、2 つの固有の Vivado セッションで並行して実行できます。どちらも同じロック済みの最上位スタティック デザインに依存しますが、inst_RP レベル以下は固有になります。このバージョンのフロアプランは二次 RP のものとは若干異なりますが、数も異なる場合があります。

    図 8. count_up をインプリメントしてから count_down を 2 つの RP にインプリメントする 2 つの二次 run