01signal: Vivado で部分再構成を使うための How-To

はじめに

これは Xilinx の Vivado における部分再構成(Partial Reconfiguration)、別名 Dynamic Function eXchange(DFX)についての全 4 回の連載の 2 番目の記事です。この記事では、FPGA デザインで部分再構成を有効にするための手順を詳しく解説します。まだお読みでない方は、これらの手順の背後にある概念を説明している前回の記事をお読みになることをお勧めします。

Xilinx は 2020 年に部分再構成を "Dynamic Function eXchange"(DFX)と改名しました。DFX は Vivado のメニューや情報メモで使われる表現です。とはいえ、本稿では技術用語である部分再構成(Partial Reconfiguration)を使用します。

簡単のため、本稿ではプロジェクトにリコンフィギャラブルパーティション(reconfigurable partition)が 1 つだけあることを前提とします。複数のパーティションへの拡張は比較的簡単です。

本稿で説明する手順は、プロジェクトが部分再構成に対応する前から始まります。大まかに分けると、手順は次のとおりです。

フロアプランニングのためのプロジェクト準備
部分再構成用の初期プロジェクト設定
フロアプランニング
デザインを実装してフロアプランニングを確認・修正
2 つ目(または複数)のリコンフィギャラブルモジュールを追加
ビットストリームファイルを取得するための実装を実行
プロジェクトのレビュー

フロアプランニングの準備

何よりも、フロアプランニングは頭を使う作業です。FPGA ロジックの領域を無駄にしないことと、スタティックパーティションとリコンフィギャラブルパーティションの両方が、配置配線(place and route)中に大きな障害を抱えないようにすることの間で、微妙なバランスを取る必要があります。

そのため、本稿の大部分はこのテーマに割かれています。

遠い昔、フロアプランニングはタイミングクロージャ(timing closure)を達成するために使われる手法でした。ロジックを合理的に配置するようツールを支援していたのです。FPGA 設計ツールは時代とともに向上したため、フロアプランニングがタイミング制約の達成に役立ったのを最後に見てから、もう何年も経ちます。今日では、タイミング制約を達成するための最善の戦略は、ほとんどの場合ツールに判断させることです。

部分再構成ではフロアプランニングが必須なので、目標は状況を悪化させないことです。これは通常、試行錯誤の問題です。とはいえ、良い結果を得る最も簡単な方法は、フロアプランニングなしでデザインを実装し、ロジックが自然に配置された状態から始めることです。次のステップとして、その初期配置を指針に、部分再構成と整合するように領域を整理してみます。

プラグイン用途(plugin usage)のシナリオでは、プロジェクトの進化に応じてフロアプランニングを更新できます。しかし、リモートアップデート(Remote Update)のシナリオ、つまり部分再構成をリリース済みデザインのバージョン更新手段として使う場合はそうではありません。リモートアップデートでは、すべての部分ビットストリームが初期ビットストリームと一致しなければなりません。したがって、初期ビットストリームがリリースされた時点で、デザインのスタティックロジック部分は凍結されます。これは、フロアプランニングも同じままにしなければならないことを意味します。

したがって、部分再構成を始める前であっても、最初の作業は FPGA 内でスタティックロジックに適切な領域を見つけることです。これに時間をかけすぎる意味はありません。プロジェクトが 2 つに分割された後に進めるための出発点を得るだけです。

誤解しないでください。この最初のステップの目的はフロアプランニング自体ではなく、制約なしで Vivado がロジックをどのように配置するかを確認し、それに基づいてスタティックロジックに割り当てる領域を決めることです。手順は次のとおりです。

通常どおりデザインを実装します。実装後デザインを開き、デバイスビューを確認します。スタティックデザインがどの程度のロジックリソースを消費するか、また Vivado がそれらをどのように配置したがるかの感触をつかんでください。
リコンフィギャラブルロジックとして想定している部分を一時的にプロジェクトから外すと、この作業が楽になるかもしれません(ただし、ロジック最適化によってスタティックロジックまで消えないように注意してください)。
デバイスビューでロジック要素が選択されていないことを確認し、ビュー上のどこかを右クリックして "Draw Pblock" を選びます。スタティックロジックを収めるのに適していそうな領域を描画します。必ずしも Vivado が行った配置をまねる必要はなく、ロジックの配置やタイミング制約の達成を妨げずに最小の領域を割り当てられる形状を探すようにしてください。
Vivado は "Create a new Pblock" ダイアログを開いて応答します。クロック領域で Pblock を定義するよう提案されるかもしれませんが、その場合は提案に従わないでください。スライス、DSP、場合によっては他のロジック要素に基づいて Pblock を指定します。
UltraScale FPGA では、ダイアログが Pblock に IOB を含めるよう提案することもあります。提案された場合はそのオプションの選択を外してください。さもないと、後で Pblock を保存またはサイズ変更するときに Vivado が固まる可能性があります(Vivado のバグです)。
Pblock の形状、特にスライスの範囲に注意してください。この情報は Vivado の GUI の Pblock プロパティペイン("General" タブ)か、Tcl コンソールで取得できます。次のような内容が表示されます。
```
startgroup
create_pblock pblock_1
resize_pblock pblock_1 -add {SLICE_X108Y148:SLICE_X149Y249 DSP48_X4Y60:DSP48_X5Y99 RAMB18_X4Y60:RAMB18_X6Y99 RAMB36_X4Y30:RAMB36_X6Y49}
endgroup
```
Tcl コンソールにワーニングが出ても無視して構いません。
実装後デザインを閉じるとき、Vivado は保存するかどうか尋ねます。今作成した Pblock には用途がないので、"No" を選択します。

部分再構成用のプロジェクト設定

Xilinx の UG909 は、部分再構成の作業手順として次の 2 つを推奨しています。

非プロジェクトフロー(第 3 章)。Tcl スクリプト(script)を明示的に書いて実行することで実装を行う方法です。
プロジェクトフロー(第 4 章)。Vivado の GUI と、それが自動生成するスクリプトを使う方法です。

本稿ではプロジェクトフローを採用します。プロジェクトフローにはいくつかの制限があり、その一部はリコンフィギャラブルモジュール内のソースの種類(特にブロックデザインの使用)に関係します。とはいえ、プロジェクトフローから始めるのが良いでしょう。実装用に生成されるスクリプトは、必要になった場合の非プロジェクトフローの良い土台になるからです。

既存プロジェクトで部分再構成サポートを有効にする手順は次のとおりです。

Tools > Enable Dynamic Function eXchange… を選択し、"Convert" をクリックします。プロジェクトを部分再構成フローに変換することは元に戻せない、という注意が GUI に表示されるので、同意します。実際に実行される Tcl コマンドは次のとおりです。
```
set_property PR_FLOW 1 [current_project]
```
リコンフィギャラブルパーティションのトップレベルモジュールを決め、Vivado の Project Manager の Sources ペインでそのソースファイルを右クリックし、"Create Partition Definition…" を選択します。このオプションは DFX を有効にした後でのみ利用可能です。いま有効にしたばかりですね。
"Create Partition Definition" ダイアログが開き、2 つの項目を尋ねられます。1 つ目は Partition Definition(パーティション定義)の名前です。これはロジック内の階層を指すために使われます。この名前は、後で様々なリコンフィギャラブルモジュールを挿入できる階層上の場所を指します。適切な名前としては "pr" などが考えられます。2 つ目は Reconfigurable Module Name(リコンフィギャラブルモジュール名)で、どのロジックをパーティションに入れるかを示します。たとえば、部分再構成を使ってオーディオフィルタを置き換える場合、Reconfigurable Module Name には "lpf"、"bpf"、"hpf" など、どのフィルタを適用するかが分かる名前を付けるとよいでしょう。トップレベルモジュールの名前がその役割を表しているなら、それをそのまま使っても構いません。
Sources リストで選択したモジュールの行には黄色いひし形が付き、モジュール名とインスタンス名(Verilog/VHDL ファイルで定義された "pr_block" と "pr_block_ins" など)が表示されます。これらの名前はパーティションに挿入されるロジックの内容を示すものではなく、HDL での名前を反映しているにすぎません。パーティション定義とリコンフィギャラブルモジュールは、同じ Sources ペインの "Partition Definitions" タブで確認できます。
リコンフィギャラブルモジュール内に IP(たとえば FIFO)のインスタンシエーション(instantiation)がある場合、メインプロジェクトのソース("Hierarchy" ペイン内)で該当 IP の行を右クリックし、"Move to configurable module…" を選択して追加できます。これに相当する Tcl は次のようなものです。
```
move_files -of_objects [get_reconfig_modules lpf] [get_files /path/to/blkmem.xci]
```
これにより、IP が "Partition Definitions" タブに移動します。
さらに、この "Partition Definitions" タブは、各リコンフィギャラブルモジュールのソース階層のコレクションとして機能します。たとえば、リコンフィギャラブルモジュールが必要とする HDL ファイルを追加するには、このタブの下にある "+" をクリックします。
リコンフィギャラブルモジュールのセットアップが済んだら、ペアレント実装(Parent Implementation)を定義します(ペアレント実装、チャイルド実装、ウィザードについては前回の記事を参照)。
- Tools > Dynamic Function eXchange Wizard を選択します。
- ようこそページ、およびリコンフィギャラブルモジュールを編集するページで Next をクリックします。
- "Edit Configurations" ページで "+" をクリックしてコンフィギュレーションを追加します。既定の config_1 という名前で問題ありません。名前はあまり重要ではないからです。既定では Vivado が config_1 用にリコンフィギャラブルモジュールを正しく選択します。今はそれが唯一のモジュールなので当然です。
- 次の画面はコンフィギュレーションラン(configuration runs)を追加するための画面です。(今は)追加しないでください。
- ウィザードを完了します。

この時点でプロジェクトの実装を試みると、おそらく次のようなエラーで失敗します。「[DRC HDPR-30] Missing PBLOCK On Reconfigurable Cell: HD.RECONFIGURABLE cell 'pr_block_ins' must have PBLOCK assigned to itself or its descendant cells」。簡単に言えば、フロアプランニングが必要だという意味です。

フロアプランニング

この段階で、プロジェクトはフロアプランニング作業を行うのに必要なだけ設定されています。

この作業を細かいステップに分解する前に、留意すべき点をいくつか挙げておきます。

FPGA 上のスタティックロジック用領域は、可能な限り小さくする必要があります。ただし、配置配線を困難にするような小ささは避けます。その形状のおおよその見積もりは、先ほど(上記の「フロアプランニングの準備」参照)得られているはずです。
スタティックロジックとリコンフィギャラブルロジックの両方の形状は、できるだけ単純にします。理想的には、単純な矩形や、配線に困難を生じさせない形状にします。
スタティックロジックの配線はリコンフィギャラブルロジックの領域を横切ることがありますが、その逆はほとんどの場合成立しません。
今回のフロアプランニング作業では、リコンフィギャラブルロジックの形状を描画します。先ほどの 2 つの点から、この形状を単純に保つことが重要です。
お使いの FPGA 固有のフロアプランニングの可能性と制限について、UG909 の第 6 章から第 8 章に詳しく記載されているので確認してください。たとえば 7 シリーズ FPGA を使う場合は、領域の境界をクロック領域の境界に合わせるのがおそらく最善です。

それでは、ステップに分解します。

プロジェクトの合成を開始します(synth_1 ランを開始)。リコンフィギャラブルモジュールの合成は、Out-of-Context(OOC)ラン(たとえば lpf_synth_1)として自動的に行われます。OOC については最終回で詳しく説明します。
ランが完了したら、合成後デザインを開きます(この時点では実装は不可能です。リコンフィギャラブルモジュールに対応する Pblock がないためです)。
リコンフィギャラブルロジック用の Pblock を描画します。準備段階とは異なり、リコンフィギャラブルロジックに関連付ける必要があります。左上のペインが Netlist タブになっていることを確認し、リコンフィギャラブルパーティションに入るトップレベルのセル(たとえば "pr_block_ins")を右クリックします。Floorplanning > Draw Pblock を選択し、FPGA 上に領域を描画します。行う GUI 操作は、前述(「フロアプランニングの準備」)のとおりです。つまり、スライスなどのロジック要素に基づいて選択します。
繰り返しますが、Pblock に IOB を含めるよう提案されたら受け入れないでください。後で Vivado が処理中に固まる可能性があります。
ここで頑張りすぎないでください。Vivado に文句を言われて修正が必要になる可能性が高いからです。繰り返しますが、Pblock はリコンフィギャラブルロジック用に描画し、スタティックロジックは残りの領域を使います。
次に Pblock Properties ペインを開きます。このペインを表示するには、デバイスビューで Pblock を右クリックし、Pblock Properties… を選択する必要があるかもしれません。
(Pblock Properties ペインで)Properties タブを選択します。
7 シリーズ FPGA(つまり UltraScale 以降以外)の場合:部分ビットストリームをロードした後にロジックへ FPGA の内部リセットを掛けたいなら、Pblock Properties ペインで RESET_AFTER_RECONFIG を設定することをお勧めします(リコンフィギャラブルモジュールのリセットについては次回で詳しく説明します)。これにより、次のような XDC 制約が作成されます。
```
set_property RESET_AFTER_RECONFIG true [get_pblocks pblock_pr_block_ins]
```
この制約は、とりわけフリップフロップを既定値に戻します。ただし、これは HDL などで定義されたリセットとは無関係であることに注意してください。また、7 シリーズ FPGA では、この機能を使うには Pblock の垂直方向の境界がクロック領域に揃っている必要があります。
UltraScale FPGA 以降では、このリセットは常に有効です。
SNAPPING_MODE プロパティもあります。これは 7 シリーズ FPGA では既定では未定義です(OFF と同等)。FPGA によっては、これを ROUTING または ON(UltraScale では既定値)に設定する必要が出てくるでしょう。これについては後で触れます。

次に CTRL-S を押して制約を保存します(または上部バーのフロッピーディスクアイコンをクリック)。これにより XDC ファイルに次のような行が追加されます。

create_pblock pblock_pr_block_ins
add_cells_to_pblock [get_pblocks pblock_pr_block_ins] [get_cells -quiet [list pr_block_ins]]
resize_pblock [get_pblocks pblock_pr_block_ins] -add {SLICE_X40Y100:SLICE_X79Y149}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {DSP48_X2Y40:DSP48_X2Y59}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {RAMB18_X2Y40:RAMB18_X2Y59}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {RAMB36_X2Y20:RAMB36_X2Y29}

合成後デザインを閉じます。
synth_1 ランをリセットします。
ビットストリームの生成を試みます("Generate Bitstream" をクリック)。この実装の目的は、フロアプランニングに欠陥がないか確認することです。言い換えれば、Vivado が欠陥に対してクリティカルワーニング(critical warning)を出すかどうかを確認します。設計の検証方法としては専門的でないように聞こえるかもしれませんが、簡単で信頼性があります。

フロアプランニングの修正

おそらく部分再構成の中で最も気が進まない部分が、フロアプランニングを適切に仕上げることです。リモートアップデート用途で行っている場合は、この段階が特に重要です。このフロアプランニングはプロジェクトの寿命の間ずっと維持されるからです。

フロアプランニングの修正が必要になる主な理由は 2 つあります。クリティカルワーニングへの対応と、FPGA の利用を最適化するためです。目標は、リソースの無駄を減らしつつ、配置配線の障害を生まないことです。

修正は難しくありません。Pblock の境界をドラッグするだけでよいからです。Pblock に矩形を追加して拡張するのも簡単です。Pblock を右クリックして "Add Pblock Rectangle" を選択します。

クリティカルワーニングは必要な修正を示してくれることが多いですが、それでも、お使いの FPGA のフロアプランニング制限について、Xilinx のユーザーガイド UG909 の該当章(第 6、7 または 8 章)を読んでおいてください。

このセクションの残りでは、7 シリーズ FPGA で起こり得る問題を説明します。UltraScale FPGA のほうがはるかに扱いやすいです。

7 シリーズ FPGA でよくあるエラーは、インタコネクトタイルの列を分割してしまうことです。たとえば次のようなものです。

[Constraints 18-993] The Pblock pblock_pr_block_ins has defined an area that causes the splitting of interconnect tile columns. Dynamic Function eXchange requires that the left and right paired interconnect tile columns cannot be split by a reconfigurable boundary.  This is caused by either the left or right edge of a Pblock boundary, or by the Pblock spanning over logic types not included in the Pblock ranges.  To avoid an unroutable situation, placement will be prohibited from both of these columns. To avoid placement restrictions, modify the Pblock to avoid splitting the two columns.
The column of the split contains interconnect tile INT_L_X48Y299  (SLICE_X79Y299 SLICE_X78Y299).
Please refer to the Xilinx document on Dynamic Function eXchange.
Resolution: Set the Pblock property SNAPPING_MODE to value of ON, or modify the column/X specification of the pblock to avoid this edge.

および

[Constraints 18-996] The split between the left and right columns occurs between a reconfigurable Pblock and Static logic. The static sites are not reconfigurable. The Pblock should be adjusted to remove the column from the Pblock, unless the excluded reconfigurable and static sites are not needed for the design. Note that adjusting the Pblock will prevent prohibits and improve placement of the design, but may reduce the routability if the removed sites were needed to span across the static logic. Failure to modify the Pblock may lead to an unplaceable design if these prohibited sites are required by the design. Resolution: Set the Pblock property SNAPPING_MODE to value of ON, or modify the column/X specification of the pblock to avoid this edge. and

これを修正するには、最初のワーニングで提案されているとおり、Pblock の SNAPPING_MODE プロパティを ROUTING または ON に設定します(おそらく ROUTING では不十分なので ON を選んでください)。これを行うと、XDC ファイルに次のような多数の制約が追加されることになるでしょう。

set_property PROHIBIT true [get_sites SLICE_X79Y349]
set_property PROHIBIT true [get_sites SLICE_X78Y349]
[ ... ]
set_property PROHIBIT true [get_sites SLICE_X79Y191]
set_property PROHIBIT true [get_sites SLICE_X78Y191]
set_property PROHIBIT true [get_sites PMV_X0Y2]
set_property PROHIBIT true [get_sites SLICE_X36Y190]
set_property PROHIBIT true [get_sites SLICE_X37Y190]
[ ... ]
set_property PROHIBIT true [get_sites SLICE_X79Y176]
set_property PROHIBIT true [get_sites SLICE_X78Y176]
set_property PROHIBIT true [get_sites T14]
set_property PROHIBIT true [get_sites R15]
set_property PROHIBIT true [get_sites XADC_X0Y0]
set_property PROHIBIT true [get_sites SLICE_X36Y175]
set_property PROHIBIT true [get_sites SLICE_X37Y175]
[ ... ]

そして、これが延々と続きます。

スライスサイトに対する PROHIBIT 設定は、先ほどのクリティカルワーニングを抑止するためのものです。その他の PROHIBIT は、幾何学的領域には含まれるが、その FPGA の部分再構成では許可されないロジックサイトに対して追加されます。UltraScale FPGA 以降では、PROHIBIT の行は(あるとしても)はるかに少なくなります。

クリティカルワーニングを抑止するだけなら、PROHIBIT の行をすべて削除し、スライスだけを 1 行で指定してもおそらく問題ありません。Vivado が SNAPPING_MODE の変更に応じて追加したスライスの範囲を、次のように 1 行にまとめます。

set_property PROHIBIT true [get_sites -range {SLICE_X79Y0 SLICE_X79Y349}]

このような行は、ファイルを巨大にせずにインタコネクト分割の問題を解決できる可能性があります。

いずれにせよ、次のような行も XDC ファイルに現れることがあります。この行を削除しても問題ないようです。

set_property HD.PLATFORM_WRAPPER true [get_cells pr_block_ins]

XDC ファイルをクリティカルワーニングが消える最小限の行にまで減らすのは、表面的な対処に見えるかもしれません。しかし、代わりに巨大な制約ファイルを残すと、後で混乱の元になります。私の経験では、この種のワーニングが出ないことは、デザインのフロアプランが問題ないという承認として受け取って構いません。

おそらく、XDC をどう変更しても、SNAPPING_MODE を OFF に戻すと再び問題が発生するでしょう。

リコンフィギャラブルモジュールの追加

ここまでの実装は、いくつかの追加制約があるものの、実質的には階層設計と同じことを実現しています。部分ビットストリームは生成されますが、ロードしても同じデザインが維持されるだけなので、ほとんど役に立ちません。

そこで、別のリコンフィギャラブルモジュールに基づく別の部分ビットストリームを作成することが目標になります。これにはチャイルド実装(Child Implementation)の追加が必要です。

以下の説明を読み進める前に、前回の記事、特にペアレント実装とチャイルド実装、Dynamic Function eXchange Wizard の部分をよく頭に入れておいてください。また、前述のとおり、"Partition Definitions" タブには現在定義されているリコンフィギャラブルモジュールとそのソースが含まれています。

Tools メニューから Dynamic Function eXchange Wizard を開き、ようこそウィンドウで Next をクリックします。

Edit Reconfigurable Modules ウィンドウで "+" をクリックします。リコンフィギャラブルモジュールを追加するダイアログが開きます。このダイアログで重要なのは Reconfigurable Module Name だけです。これは、前述のとおり、リコンフィギャラブルロジックを識別するために使われる名前です。

ダイアログでは、このモジュールをパーティション定義の名前に関連付けることも求められますが、いずれにせよ(本稿ではパーティションが 1 つだけという前提なので)候補は 1 つしかありません。

続行するには、少なくとも 1 つの Verilog/VHDL ソースファイルを追加する必要があります。追加のファイルは後で "Partition Definitions" タブから追加できます。このリコンフィギャラブルモジュールのトップレベルモジュール名も入力しておいて損はありません。特に、ソースファイルだけからは役割が分かりにくい場合に有効です。

ウィザードに戻り、もう一度 Next をクリックして Edit Configurations ウィンドウへ進みます。ここで "+" をクリックし、コンフィギュレーション名を入力します。この名前は Design Runs ウィンドウに表示されるだけなので、config_2 などで問題ありません。

コンフィギュレーションのリストに新しい行が現れます。パーティションの列にあるリコンフィギャラブルモジュールを変更し、各コンフィギュレーションが異なるモジュールを持つようにします。

最後のウィンドウは Edit Configuration Runs で、コンフィギュレーションにランを割り当てます。簡単な方法は、このウィンドウにリストされているラン(あれば)をすべて削除し、"automatically create configuration runs" をクリックすることです。これにより、手動で行うであろう作業が自動的に行われます。ペアレントランを作成して "impl_1" と名付け、次にチャイルドランを作成してお好みの名前を付け、それらを "impl_1" の子にします。

ウィザードは各ランにコンフィギュレーションを自動選択しますが、これは簡単に変更できます。重要なのは、ペアレントランにどのコンフィギュレーションを関連付けるかだけです。

ところで、ウィザードでランをすべて削除すると、チャイルドランはすべて消えますが、impl_1 は残ります。

いよいよ:デザインの実装

ビットストリームを生成するには、いつもどおり Vivado で "Generate Bitstreams" をクリックするだけです。前回の記事で述べたように、部分再構成プロジェクトでは、各コンフィギュレーションにつき 2 つまたは 3 つのビットストリームが作成されます。

たとえば UltraScale FPGA の場合、ビットファイルは次のようになります。

theproject.bit:スタティックロジックと、現在のコンフィギュレーションに対応するリコンフィギャラブルロジックを含む初期ビットストリームファイル。
pr_block_ins_lpf_partial.bit:現在のコンフィギュレーションに対応するリコンフィギャラブルロジックをロードする部分ビットストリーム。
UltraScale でのみ、pr_block_ins_lpf_partial_clear.bit もあります。これは、FPGA 内に現在のコンフィギュレーションがすでに存在する場合に、部分ビットストリームをロードする前にロードするビットストリームです。

すべての実装で同じ数のビットストリームファイルが作成されることに注意してください。つまり、チャイルド実装でも初期ビットストリームファイルが作成されるので、チャイルド実装の初期ビットストリームで FPGA をロードし、そこから続行することが十分可能です。

部分ビットストリームを PCIe または USB 3.x 経由でロードする簡単な方法については、こちらのページを参照してください。

今回の実装では、Pblock やフロアプランニング全般に関する不具合でクリティカルワーニングが出たり、失敗したりすることはないはずです。そうした問題は先に解決済みのはずだからです。それでも発生した場合は、前述のようにフロアプランニングを修正する必要があります。

ときどき、チャイルド実装にしか変更を加えていないのに "Generate Bitstream" をクリックすると、Vivado が「ビットストリーム生成はすでに完了しており最新です。それでも再実行しますか?」と尋ねることがあります。少し混乱しますが、"Yes" をクリックすればチャイルド実装はきちんと実行されます。チャイルド実装の仕組みは Vivado への後付け的な機能であり、そのため実装中のステータス行に "write_bitstream complete. Child running" のような表示が出ます。

結果の確認

部分再構成は配置の話題が多いので、実装後デザインを確認するのは良い考えです。特定の実装を開くには、右クリックメニューの "Open Implemented Design" を選択し、表示されるサブメニューの "Open Implemented Design"(再び)にカーソルを合わせてから、リストから開きたい実装を選択します。リストに実装がない場合は、おそらくすでに開いています。

実装後デザインビューの Netlist ペインで、リコンフィギャラブルロジックの最上位行を右クリックし、"Highlight Leaf cells" を選択してみてください。次にスタティックロジックにも別の色で同じことを行います。

同じ右クリックメニューには "Show Connectivity" もあります。これは接続されたロジック要素間に真っ直ぐな白線を描画します。FPGA 上の実際の配線経路はもちろん異なるので、これらの線がどのフロアプランニング領域を横切るかに意味はありません。それでも、接続を見ることで、フロアプランの全体的な構成が原因でツールが苦労している箇所を発見できることがあります。

一見スタティックロジックに属するセルがリコンフィギャラブル領域の内側に配置されたり、その逆があったりするのは、ごく普通で問題ありません。注意すべきは、どこかに混雑があるように見える場合です。ロジックが全体的に、または特定の領域で詰め込まれすぎているように見えたら、可能であればフロアプランニングの変更が緩和に役立ちます。

もう 1 つ確認したいのは、パーティションピン(partition pins)の位置です。パーティションピンはデバイスビューで白い水平バーとして表示されます(画像をクリックすると拡大します)。

前回の記事で述べたように、パーティションピンはリコンフィギャラブルパーティション内のどこにでも置かれ得ます。しかし、パーティションピンがパーティションの端から離れた場所にある場合は、ペアレント実装中に配線処理がタイミング面で苦労したことを示している可能性があります。

次の Tcl コマンドで、パーティションピンの座標のテキストリストを取得することもできます(pr_block_ins は実際のリコンフィギャラブルロジックセルの名前に置き換えてください)。

foreach s [get_pins -of [get_cells pr_block_ins]] { set partpin [get_pplocs -quiet -pins [get_pins $s]] ; puts "$s => $partpin"; }

パーティションピンの座標は CLB のグリッドに対応しています(スライスのグリッドではありません)。表示される図では、これらのピンは "Cell pins" と呼ばれます。

セルのピンの中には、パーティションピンが割り当てられないものもあります。これは、リコンフィギャラブルモジュールのポートリスト(および/またはベクタの幅)と、スタティックロジックモジュールによるインスタンシエーションとの間に不一致がある場合に発生します。このような不一致は(Verilog では)完全に合法ですが、結果が望ましくないことがあります。上記の Tcl コマンドを実行すると、到達不能なポートを検出できます。特に意図しない不一致の場合に役立ちます。

以上で Vivado プロジェクトをセットアップする技術的な部分は終わりです。ただし、次回では FPGA デザインの重要な側面について説明します:ロジックの置き換えを確実かつスムーズに行う方法です。