手順 3: DFX デザイン run の設定 - 2023.2 日本語

1. design_1.bd を開いてアクティブにした状態で、Flow Navigator で Generate Block Design をクリックします。Out of context per IP をオンにし、Generate をクリックします。
   
   

   これにより、すべての IP と RTL 出力が作成され、RM 内のスタティック デザインのすべてのコンポーネントと IP の合成が開始されます。リコンフィギャラブル モジュールの最上位の生成と合成は、別々のブロック デザインであるため、後で実行されます。

   合成が完了すると、Flow Navigator に DFX ウィザードが表示されます。

2. Flow Navigator で Dynamic Function eXchange Wizard をクリックします。

   このウィザードを使用すると、デザインのスタティック部分とダイナミック部分を組み合わせた完全なデザインの「コンフィギュレーション」を作成できます。このデザインは、リコンフィギャラブル パーティションを 1 つだけ使用した、最もシンプルなユース ケースを示しています。

3. Next を 2 回クリックして、DFX ウィザードを Edit Configurations ページまで進めます。automatically create configurations リンクをクリックします。これにより、デザイン内の 3 つのリコンフィギャラブル モジュールをカバーする 3 つのコンフィギュレーションが作成されます。
4. 鉛筆のアイコンを使用すると、それぞれの「コンフィギュレーション」の名前を変更できます。それぞれに次のように名前を付けます。
   • config_up_ila
   • config_down_vio
   • config_2count_ila
   
   
   
5. もう一度 Next をクリックします。

   Edit Configuration Runs ページでは、コンフィギュレーションを手動で作成して、2 つのフローのオプションを検討します。ただし、自動的に作成された標準 DFX や抽象化シェルの run のすべてのコンポーネントを含めるオプションもあります。

   • 標準 DFX を選択すると、前ページで宣言したように、コンフィギュレーションごとに 1 つの run が作成されます。リストの 1 つ目のコンフィギュレーションが親 run になり、残りのコンフィギュレーションはその親の子 run になります。
   • 抽象化シェルを選択すると、リコンフィギャラブル モジュールごとに 1 つの親 run が、その後に 1 つの子 run が作成されます。このデザインの場合、合計 3 つの run が作成されますが、複数の RP を含むデザインの場合、その数は多くなる可能性があります。
   
   
   

   親 run は、いずれか一方のタイプの子 run しか許可しないため、run タイプの「混合」セットを作成するオプションはありません。この演習では、これら両方のアプローチ用のフルセット run を作成します。つまり、2 つのフローに対応するために、2 つの親 run を作成する必要があります。

6. 左上の + アイコンを合計 6 回クリックして、6 つの run を作成します。各 run を次のように設定します。

   標準 DFX を使用した親 run

   • [Run]: impl_std
   • [Parent]: synth_1
   • [DFX Mode]: STANDARD
   • [Configuration]: config_up_ila
   • [Auto Create Child Runs option]: オフ

   1 つ目の標準子 run

   • [Run]: impl_std_child_1
   • [Parent]: impl_std
   • [Configuration]: config_down_vio

   2 つ目の標準子 run

   • [Run]: impl_std_child_2
   • [Parent]: impl_std
   • [Configuration]: config_2count_ila

   抽象化シェルを使用した親 run

   • [Run]: impl_abs
   • [Parent]: synth_1
   • [DFX Mode]: ABSTRACT SHELL
   • [Configuration]: config_up_ila
   • [Auto Create Child Runs option]: オフ

   1 つ目の抽象化子 run

   • [Run]: impl_abs_child_1
   • [Parent]: impl_abs
   • [RM Instance]: design_1_i/rp1:rp1_rm2_inst_0

   2 つ目の抽象化子 run

   • [Run]: impl_abs_child_2
   • [Parent]: impl_abs
   • [RM Instance]: design_1_i/rp1:rp1_rm3_inst_0

   この段階では、DFX ウィザードは次のようになります。

   
   
   
7. Next をクリックし、Finish をクリックして、デザイン run を作成します。[Design Runs] タブには、ウィザードで定義したとおり、次の選択結果が表示されます。
   
   
   注記: Impl_1 は常に作成されるデフォルトの run ですが、この場合、DFX ウィザードでそのプロパティは定義しませんでした。この run を削除するには、まず impl_std または impl_abs をアクティブ run に設定し (ほかの親 run を右クリックし、Make Active をクリック)、次に impl_1 を削除します (impl_1 を右クリックし、Delete をクリック)。
8. Flow Navigator で Run Synthesis をクリックします。これにより、最上位デザインと同様、各 RM の最上位レイヤーの合成が実行されます。合成が完了したら、その合成済みのデザインを開きます。

   [Netlist] ビューには、デバッグ ハブの黒いボックスが表示されます。これらは、後で opt_design の時に挿入されます。

   
   
   
9. [Design Runs] ウィンドウですべてのインプリメンテーション run を Shift キーを押して選択します。このエリアで右クリックして Launch Runs をクリックします。

   これにより、必要な順番で run が開始されます。各親 run は互いに依存しないため、並列で実行されます。各親 run が完了したら、親 run の下の各子 run が並列で実行されます。

   デバッグ ハブの挿入とデバッグ コアへの接続は、インプリメンテーション段階の opt_design で実行されます。各インプリメンテーションが実行されるたびに、ログ ファイルに次のようなコード行が記録されます。デザインのスタティックな部分に対するデバッグ ハブの挿入は、親インプリメンテーション中にのみ実行されます。子インプリメンテーションの場合、親インプリメンテーションから派生したロックされたスタティック デザイン (標準または抽象化) のコンテキスト内で実行されます。

   Phase 2 Generate And Synthesize Debug Cores
   INFO: [Chipscope 16-329] Generating Script for core instance : design_1_i/rp1/axi_dbg_hub_0 
   INFO: [IP_Flow 19-3806] Processing IP xilinx.com:ip:axi_dbg_hub:2.0 for cell rp1rm1_inst_0_axi_dbg_hub_0_0_bb.
   INFO: [Chipscope 16-329] Generating Script for core instance : design_1_i/static_region/axi_dbg_hub_0 
   INFO: [IP_Flow 19-3806] Processing IP xilinx.com:ip:axi_dbg_hub:2.0 for cell design_1_axi_dbg_hub_0_0_bb.
   INFO: [Chipscope 16-324] Core: design_1_i/rp1/axi_dbg_hub_0 UUID: 2ba56efa-44aa-5cff-b4f7-161e160672ee 
   INFO: [Chipscope 16-324] Core: design_1_i/static_region/axi_dbg_hub_0 UUID: a46ff48e-6629-59e0-a9fe-ed94bf289898
   

結果を比較すると、次のようになります。

• 親 run の結果は、同じ結果 (タイミング スコア、クリティカル警告など) となります。
  • これらの run は同じソースとオプションを使用するため、結果の配置済みチェックポイントと配線済みチェックポイントは同じになります。
• 抽象化シェルの親 run (impl_abs) のコンパイル時間は、標準 DFX の親 run (impl_std) より全体的に若干長くなります。これらのフローの分岐点は、完全に配線済みのデザイン チェックポイントが書き込まれた後です。
  • 標準 DFX では、RP を取り出し (update_design -black_box を使用)、残りのスタティック部分をロックして (lock_design -level routing を使用)、スタティック部分のみのチェックポイント (design_1_wrapper_routed_bb.dcp) を作成します。
  • 抽象化シェルの run では、この 2 つのステップを write_abstract_shell に含めて、さらに RP の取り出しと関連するチェックを実行して、スタティック デザインの大部分を削除します。この処理には時間がかかります。処理後は、抽象化シェルのファイル (abs_shell_design_1_i_rp1.dcp) が生成されます。
  • design_1_wrapper_routed_bb.dcp と abs_shell_design_1_i_rp1.dcp のファイル サイズを比較してください。このデザインの場合、フル シェルは抽象化シェルの 3 倍以上のサイズになります。
• 標準 DFX フローを使用した場合、子 run のコンパイル時間は、抽象化シェル フローを使用した場合より長くなります。
  • 抽象化シェル フローを使用する利点は、このような場合にあります。これらの run では、開くチェックポイントが小さく、処理する情報が少ないため、全体的なコンパイル時間が短縮されます。

最終的な [Design Runs] ウィンドウには、次のような数字が表示されます。

このマシンでは、抽象シェルの子プロセスが標準 DFX の子プロセスの半分以下の時間で実行されました。大規模なデザイン、特に複数の比較的小さなリコンフィギャラブル パーティションを含むデザインの場合、さらに大きな節約になります。

• 演習のハードウェア部分に進む場合は、run を選択して右クリックし、Generate Device Image をクリックします。run を選択します。
  • ハードウェアでデザインを実行するだけの場合、1 つ親 run とその子 run の両方を選択します。これにより、プログラムに最小限のファイル セットが提供され、その後、ターゲットを部分的にリコンフィギュレーションして ChipScope™ デバッグ機能を確認できるようになります。
  • PDI 生成による標準シェルと抽象化シェルのフローを比較する場合は、6 つの run をすべて選択して、すべてのデバイス イメージを生成してください。