01signal: Vivadoを使用した Partial Reconfiguration のハウツー

序章

これは、 Partial Reconfiguration (または Dynamic Function eXchange、 DFX) と Xilinxの Vivadoに関する4 回のシリーズの2 回目の投稿です。この投稿の目的は、 FPGA designで Partial Reconfiguration を有効にする手順を順を追って説明することです。これらの手順の背後にある概念について説明しているため、まだ読んでいない場合は最初の投稿を読むことをお勧めします。

Xilinx は、 2020で Partial Reconfiguration を "Dynamic Function eXchange" (DFX) にブランド変更しました。 DFX は、 Vivadoのメニューおよび情報ノートで使用される表現です。それにもかかわらず、ここでは「Partial Reconfiguration」という専門用語が使用されています。

簡単にするために、この投稿では、プロジェクト内に reconfigurable partition が 1 つだけあると想定しています。これを複数の partitions に拡張するのはかなり簡単です。

この投稿で説明されている手順は、プロジェクトが Partial Reconfigurationで有効になる前に開始されます。大まかに分けると、手順は次のとおりです。

floorplanning用のプロジェクトを準備する
Partial Reconfigurationの初期 project setup を作成する
Floorplanning
designの implementation で floorplanning を確認して修正します。
2 番目の reconfigurable module (またはいくつかの modules) を追加します。
bitstream ファイルを取得するために implementation を実行します。
プロジェクトを確認する

floorplanningの準備

floorplanning は、他のどのタスクよりも頭脳を必要とするタスクです。 FPGA logic の領域を無駄にしないことと、 static partition と reconfigurable partitions の両方が place and routeの間に大きな障害を持たないようにすることとの間の微妙なバランスです。

したがって、この投稿の大部分はこのトピックについて説明しています。

遠い昔、 floorplanning は timing closureに使用された技術でした。ツールが logic を適切な方法で配置するのに役立ちました。 FPGA design のツールは時間の経過とともに改善されてきたので、 floorplanning が timing constraintsの実現に役立ったのを最後に見たのは何年も前のことです。今日、 timing constraints を達成するための最善の戦略は、ほとんどの場合、ツールに決定を任せることです。

Partial Reconfigurationでは floorplanning が必須なので、事態を悪化させないことが目標です。これを行うには、通常、試行錯誤が必要です。ただし、良い結果を得る最も簡単な方法は、 design の implementation を floorplanningなしで実行し、 logic を自然に配置する方法から開始することです。次のステップは、 logic の初期配置をガイドラインとして使用して、 Partial Reconfigurationで意味のある方法で領域を整理することです。

plugin の使用シナリオでは、 floorplanning は、プロジェクトが時間とともに進化するにつれて更新できます。ただし、これは Remote Update シナリオ、つまりリリースされた design のバージョン更新を行う手段として Partial Reconfiguration が使用される場合には当てはまりません。 Remote Updateでは、すべての partial bitstreams が initial bitstreamと一致する必要があります。したがって、 design の static logic 部分は、 initial bitstream がリリースされるとすぐに凍結されます。これは、とりわけ、 floorplanning が同じままでなければならないことを意味します。

したがって、 Partial Reconfigurationを開始する前であっても、最初のタスクは、 static logic用に FPGA で適切な領域を見つけることです。これに時間をかけすぎても意味がありません。プロジェクトが 2 つの部分に分割された後に開始点を取得するだけです。

混乱しないでください: この最初のステップの目的は、 floorplanning 自体ではありませんが、 Vivado が logic を制限なしでどのように配置するかを確認し、そこから static logicに割り当てる領域を決定することです。手順は次のとおりです。

通常どおり design の implementation を実行します。 implemented design を開き、 device viewを見てください。 static design が消費する logic リソースの量と、 Vivado がそれらをどのように配置することを好むかについて考えてみてください。
reconfigurable logic として意図されている部分がプロジェクトから一時的に削除されている場合は、これを行う方が簡単かもしれません (ただし、 logic optimizationが原因で static logic も削除されない方法で)。
Device viewで logic element が選択されていないことを確認し、その上で Right-click を実行し、「Draw Pblock」を選択します。 static logicを収容するのに適していると思われる領域を描画します。必ずしも Vivado の配置を真似するのではなく、 logic の配置に支障をきたさず最小限の面積を割り当てる形状を模索し、 timing constraintsを実現。
Vivado は、「Create a new Pblock」というダイアログボックスを開いて応答します。 Pblock を clock regionsで定義することを提案する場合がありますが、その場合は実行しないでください。 slices、 DSPs 、およびその他の logic elementsに基づいて Pblock をリクエストします。
Ultrascale FPGAsでは、 Pblock ダイアログボックスで IOBsを含めることも提案される場合があります。そうしないと、 Pblock の保存またはサイズ変更中に Vivado がスタックする可能性があります ( Vivadoのバグが原因です)。
Pblockの形状、特に slicesのレンジに注目。この情報は、 Vivadoの GUI の Pblock properties pane (「General」タブの下) または Tcl Consoleから取得できます。
```
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 Consoleに warnings がある場合は無視します。
implemented designを閉じると、 Vivado は保存するかどうか尋ねてきます。作成したばかりの Pblock は使い物にならないので、「No」を選択します。

Partial Reconfigurationのプロジェクトのセットアップ

XilinxのUG909 は、 Partial Reconfigurationの 2 つの作業手順を提案しています。

non-project flow (その第 3 章)。つまり、 implementation は、 Tcl scripts を明示的に記述して実行することによって実行されます。
project flow (第 4 章) は、 Vivadoの GUI とそれによって自動的に生成される scripts を使用することに対応します。

ここでは project flow を使用しますが、いくつかの制限があり、そのうちのいくつかは reconfigurable module の sources のタイプに関連しています (特に block designsの使用に関して)。いずれにせよ、 implementation 用に生成される scripts は、必要に応じて non-project flowの優れた基盤となるため、 project flowから始めることをお勧めします。

既存のプロジェクトで Partial Reconfiguration サポートを有効にする手順は次のとおりです。

Tools > Enable Dynamic Function eXchange… を選択して「Convert」をクリック。 GUI は、プロジェクトを Partial Reconfigurable flow に変換すると元に戻すことができないことを確実に認識してくれるので、それに同意してください。実際に実行される Tcl コマンドは
```
set_property PR_FLOW 1 [current_project]
```
reconfigurable partitionの top level module を決定し、 Vivadoの Project Managerの Sources pane の下にあるその source file を右クリックします。「Create Partition Definition…」を選択。このオプションは、 DFXを有効にした後にのみ使用できますが、それを行ったばかりです。
"Create Partition Definition" ダイアログウィンドウが表示され、次の 2 つのことを尋ねられます。 logicの階層を参照するために使用される Partition Definitionの名前。この名前は、異なる reconfigurable modules を挿入できる階層内の場所を参照します。適切な名前は「pr」です。 2 番目の Reconfigurable Module Nameは、どの logic が partitionに入るかを示します。たとえば、 Partial Configuration を使用して audio filterを置き換える場合、 Reconfigurable Module Name の賢明な選択は「lpf」、「bpf」、「hpf」であり、それぞれの名前は適用されるフィルターを示します。 top-level moduleの機能を理解するのに役立つ場合は、 top-level moduleの名前にすることができます。
Sources list 内の選択された module の行は、 Verilog / VHDL ファイルで定義されているように、 module および instance name の名前 (「pr_block」および「pr_block_ins」など) とともに黄色のひし形で表示されます。これらの名前は、どの logic が partitionに挿入されるかについては何も述べていませんが、 HDLでの名前を反映しています。 partition と reconfigurable module は、同じ Sources paneの「Partition Definitions」タブにあります。
IP の instantiations (たとえば、 reconfigurable moduleに FIFO) がある場合、 IP は、メインプロジェクトの sources ("Hierarchy" ペインの下) でその行を右クリックし、"Move to configurable module…" を選択することで追加できます。 Tcl の同等物は何かのようなもの：
```
move_files -of_objects [get_reconfig_modules lpf] [get_files /path/to/blkmem.xci]
```
これを行うと、 IP が「Partition Definitions」タブに移動します。
これだけでなく、「Partition Definitions」タブは、 reconfigurable moduleごとに source hierarchies のコレクションのように機能します。たとえば、 reconfigurable moduleで必要な HDL ファイルを追加するには、このタブの下にある [+] をクリックします。
reconfigurable module がセットアップされたら、 Parent Implementation を定義します ( Parent implementations、 Child implementations 、および Wizardに関する以前の記事を参照してください)。
- Tools > Dynamic Function eXchange Wizardを選択します。
- ようこそページと reconfigurable modulesを編集するページで Next をクリックします。
- 「Edit Configurations」ページで、「+」をクリックして configurationを追加します。デフォルトの config_1 名は問題ないため、問題ありません。デフォルトでは、 Vivado は config_1に対して reconfigurable module を正しく選択しますが、これは今のところ唯一のものであるため、驚くことではありません。
- 次の画面は、 configuration runsを追加するためのものです。これをしないでください（今のところ）。
- Wizardを仕上げます。

この段階でプロジェクトの implementation を実行しようとすると、「[DRC HDPR-30] Missing PBLOCK On Reconfigurable Cell: HD.RECONFIGURABLE cell 'pr_block_ins' must have PBLOCK assigned to itself or its descendant cells」のようなエラーで失敗する可能性が高くなります。つまり、簡単に言えば、 floorplanning が必要ということです。

Floorplanning

この段階で、プロジェクトは floorplanning タスクに十分にセットアップされています。

このタスクを小さなステップに分割する前に、覚えておくべきいくつかの点に言及する価値があります。

static logic 用の FPGA の領域は、できるだけ小さくする必要がありますが、 place and routeではそれが難しくならないようにしてください。その形状の大まかな推定は以前に取得されているはずです (上記の「Preparation for floorplanning」を参照)。
static logic と reconfigurable logic の両方の形状は、できるだけ単純にする必要があります。できれば、単純な長方形または routingで問題を生じさせないその他の形状にする必要があります。
static logicの routing は reconfigurable logicの領域を横切ることがありますが、その逆はほとんどの場合当てはまりません。
この floorplanning セッションでは、 reconfigurable logic の形状が描画されます。最後の 2 つのコメントがあるため、これはシンプルに保つための形状です。
UG909の章 6-8 で説明されているように、特定の FPGAの floorplanning に関する可能性と制限に注意してください。たとえば、 series-7 FPGA を使用する場合、領域の境界を clock regionsの境界に合わせるのがおそらく最善です。

今それをステップに分解します：

プロジェクトの synthesis を開始します (つまり、 synth_1 runを開始します)。 reconfigurable module の synthesis は、 Out-of-Context run (OOC) として自動的に実行されます (例: lpf_synth_1)。 OOCs については、前回の投稿で詳しく説明しています。
runs が完了したら、 synthesized design を開きます ( reconfigurable moduleに関連付けられた Pblock がないため、この時点ではimplementation は使用できません)。
reconfigurable logicの Pblock を描画します。準備段階とは異なり、 reconfigurable logicに関連付ける必要があるため、次のようになります。左上の pane が Netlist tabで開いていることを確認し、 reconfigurable partition に入る toplevel cell (例: "pr_block_ins") を右クリックします。 Floorplanning > Draw Pblockを選択し、 FPGAに領域を描画します。実行する GUI 操作は、上記 (「Preparation for floorplanning」) で説明したとおりです。つまり、選択は slices と他の logic elementsに基づいています。
繰り返しになりますが、 IOBs を Pblockに含めるように提案された場合、この提案を受け入れないでください。そうしないと、 Vivado が後で処理に行き詰まる可能性があります。
Vivadoの苦情のために修正しなければならない可能性が高いため、これにあまり力を入れないでください。繰り返しますが、 Pblock は reconfigurable logic用に描画され、 static logic は残りの領域を取ることに注意してください。
Pblock Properties paneへ。 device viewで Pblock を右クリックし、これを表示するには Pblock Properties… を選択する必要がある場合があります。
Properties tab を選択します ( Pblock Properties pane内)。
series-7 FPGAs の場合 (つまり、 Ultrascale 以降ではない): Pblock Properties paneでは、 partial bitstream のロード後に logic に FPGAの内部 reset を取得させたい場合は、 RESET_AFTER_RECONFIG を設定することをお勧めします ( reconfigurable moduleのリセットの詳細については、次の投稿を参照してください)。これにより、次のような XDC constraint が作成されます。
```
set_property RESET_AFTER_RECONFIG true [get_pblocks pblock_pr_block_ins]
```
とりわけ、この constraint は flip-flops をデフォルト値に戻します。ただし、これは HDL または logicで定義されている resets とは関係がないことに注意してください。また、 series-7 FPGAsでは、この機能を使用するには、 Pblockの垂直方向の境界が clock regionsに揃えられている必要があることに注意してください。
Ultrascale FPGAs 以降では、この reset は常に有効になっています。
series-7 FPGAs のデフォルトでは定義されていない SNAPPING_MODE プロパティもあります (これは OFFと同等です)。一部の FPGAsでは、おそらく ROUTING または ON ( Ultrascaleのデフォルト) に設定する必要があります。それについては後で説明します。

次に、 CTRL-S を押して constraints を保存します (または上部バーのディスケットアイコンをクリックします)。これにより、次のように 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}

Synthesized Designを閉じる
synth_1 runをリセットします。
bitstreamの生成を試みます(「Generate Bitstream」をクリックして)。この implementation の目的は、 floorplanningに欠陥があるかどうかを確認することです。つまり、 Vivado がそのような欠陥に対応して Critical Warnings を発行した場合。 designを検証するのは専門外の方法のように聞こえるかもしれませんが、それでも簡単で信頼性があります。

floorplanningの修正

これはおそらく、 Partial Reconfigurationの最も不快な部分です。 floorplanning を正しく取得するには。 Remote Update のユースケースでこれを行っている場合、この floorplanning はプロジェクトの存続期間全体にわたって残るため、このフェーズは非常に重要です。

floorplanning の修正が必要な主な理由は 2 つあります。 Critical Warningsへの対応として、および FPGAの使用を最適化するための後の段階で: 目標は、リソースの浪費を減らすと同時に、 place and routeの障害を作成しないようにすることです。

Pblockの境界をドラッグするのは簡単なので、変更を加えるのは難しくありません。長方形を追加して Pblock を拡張することも簡単です。 Pblock を右クリックし、「Add Pblock Rectangle」を選択します。

Critical Warnings は、どのような修正が必要かをよく言いますが、特定の FPGAの floorplanning の制限に関して、 Xilinxのユーザーガイド UG909 の関連する章 (6、7、または 8) を必ず読んでください。

このセクションの残りの部分では、 series-7 FPGAで発生する可能性のある問題について説明します。 Ultrascale FPGAs の方がはるかに簡単に操作できます。

series-7 FPGA でよくあるエラーの 1 つは、 interconnect tile columnsの分割です。たとえば、次のようになります。

[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

これを修正するには、最初の warningで提案されているように、 Pblockの SNAPPING_MODE プロパティを ROUTING または ON に設定します (おそらく ROUTING では不十分なので、 ONを選択します)。これを行うと、おそらく次のような XDC ファイルに大量の constraints が追加されます。

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]
[ ... ]

そしてそれは続きます。

slice サイトの PROHIBIT 設定は、前述の Critical Warningを無音にする設定です。他の PROHIBIT 割り当ては、幾何学的領域に含まれる logic のサイトに追加されますが、使用される FPGA 上の Partial Reconfiguration には許可されません。 Ultrascale FPGAs 以降では、 PROHIBITで生成される行があったとしても、大幅に少なくなります。

Critical Warningを黙らせるだけの目的で、 PROHIBITを含むすべての行を削除し、 slices のみに 1 つの行を残すことはおそらく問題ありません。これは、 SNAPPING_MODEの変更に対応して Vivado が追加した slices の範囲をカバーすることによって行われます。したがって、この範囲を次のように変更します。

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

これは、ファイルを巨大にすることなく interconnect splitting の問題を解決できる XDC ファイルの行の種類です。

とにかく、この種の行は XDC ファイルにも表示される場合があります。この行を削除しても問題ないようです:

set_property HD.PLATFORM_WRAPPER true [get_cells pr_block_ins]

XDC ファイルを最小限に減らして Critical Warnings を無音にすることは、やや表面的に見えるかもしれませんが、別の方法は巨大な constraints ファイルであり、後で混乱を招きます。私の経験では、この種の warnings がないことは、 designの floorplan が問題ないという承認と見なすことができます。

SNAPPING_MODE プロパティを OFF に戻すと、 XDCへの変更に関係なく、再び問題が発生する可能性があります。

reconfigurable moduleの追加

これまでのところ、 implementation は実質的に hierarchical designと同じことを達成していますが、いくつかの追加の制限があります。 partial bitstream が生成されても、ロードすると同じ designが保持されるため、まったく役に立ちません。

したがって、目標は、別の configurable moduleに基づく別の partial bitstreamを作成することです。これには、 Child Implementationを追加する必要があります。

これを読む前に、特に Parent Implementations と Child Implementations、および Dynamic Function eXchange Wizardの部分について、前の投稿を頭の中に入れておいてください。また、この投稿の上記で説明したように、「Partition Definitions」タブには、現在定義されている reconfigurable modules とその sourcesが含まれていることを思い出してください。

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

Edit Reconfigurable Modules ウィンドウで、「+」をクリックします。これにより、 reconfigurable moduleを追加するための dialog box が開きます。この dialog box の唯一の興味深い点は、 Reconfigurable Module Nameです。これは、すでに上で説明したように、 reconfigurable logic を識別するために使用される名前です。

このダイアログボックスでは、この module を partition definitionの名前に関連付ける必要もありますが、そのようなものは 1 つしかありません (この投稿では、 partition が 1 つだけ定義されていると想定しているため)。

続行するには、少なくとも 1 つの Verilog / VHDL source file を追加する必要があります。後で「Partition Definitions」タブからさらに追加できます。この reconfigurable module の toplevel module の名前を追加しても、特に source ファイル自体から明らかでない場合は問題ありません。

Wizardに戻り、 Next をもう一度クリックして、 Edit Configurations ウィンドウに移動します。「+」をクリックし、 configuration 名を入力します。この名前の唯一の重要性は、 Design Runs ウィンドウに表示されることです。 config_2 くらいの名前でいいです。

configurationsのリストに新しい行が表示されます。 partitionの列の configurable module を変更して、各 configuration が異なる configurable moduleを持つようにします。

最後のウィンドウは、 runs を configurationsに割り当てるための Edit Configuration Runsです。簡単な方法は、このウィンドウにリストされているすべての runs (存在する場合) を削除し、[automatically create configuration runs] をクリックすることです。とにかく手動で行うことを行います： parent runを作成し、それを "impl_1" と呼び、次に child runsを作成し、好きな名前を付けて "impl_1" の children にします。

Wizard は runごとに configuration を選択しますが、これは簡単に変更できます。唯一重要なことは、どの configuration が parent runに関連付けられているかです。

ところで、 Wizard内の runs をすべて削除すると、 child runs はすべてなくなりますが、 impl_1 は残ります。

ついに： designの Implementation

bitstreamsを生成するには、通常どおり Vivado の「Generate Bitstreams」をクリックします。以前の投稿で既に述べたように、 Partial Reconfiguration プロジェクトの configuration ごとに 2 つまたは 3 つの bitstreams が作成されます。

たとえば、 Ultrascale FPGA では、 bitfiles は次のようになります。

theproject.bit: 現在の configurationに関連する static logic および configurable logic を含む initial bitstream ファイル。
pr_block_ins_lpf_partial.bit: 現在の configurationに関連する reconfigurable logic をロードする partial bitstream 。
Ultrascaleのみ、 pr_block_ins_lpf_partial_clear.bitもあります。現在の configuration が FPGAに既に存在する場合、 partial bitstreamをロードする前に bitstream をロードします。

すべての implementationsに対して同じ数の bitstream ファイルが作成されることに注意してください。つまり、 initial bitstream ファイルは Child Implementations 用にも作成されるため、 FPGA に Child Implementationsの initial bitstreamのいずれかをロードして、そこから続行することは完全に可能です。

PCIe または USB 3.xを介して partial bitstreams をロードする簡単な方法については、このページを参照してください。

implementations には、 Pblock と floorplanning に関する一般的な苦情が原因で Critical Warnings や障害が発生することはありません。このような問題は既に解決されているはずです。このような問題が引き続き発生する場合は、 floorplanning を上記の説明に従って修正する必要があります。

「Generate Bitstream」をクリックすると、 child implementationsのみに変更が加えられた場合、 Vivado が「Bitstream generation has already completed and is up-to-date. Re-run anyway?」と応答することがあります。これはやや紛らわしいですが、「Yes」をクリックすると、 child implementations が正しく実行されます。 Child Implementation に関するこの全体は、 Vivadoへのアドオンのようなものです。これが、 implementation 中の status 行が "write_bitstream complete. Child running" のようなことを言う理由でもあります。

結果のレビュー

Partial Reconfiguration は配置が重要なので、 implemented designsを検討することをお勧めします。「Open Implemented Design」を右クリックして特定の implementation を開くことができます。次に、「Open Implemented Design」というメニュー項目にカーソルを合わせます (再び)。次に、開く implementation をリストから選択します。 implementation がリストにない場合は、すでに開いている可能性があります。

Implemented Design ビューの Netlist pane で reconfigurable logic の一番上の行を右クリックして、「Highlight Leaf cells」を選択してみてください。次に、別の色を使用して、 static logicで同じことを行います。

同じ右クリックで「Show Connectivity」もあり、接続された logic elements の間に真っ白な線を引きます。もちろん、 FPGA 上の実際の routing paths は異なるため、これらの線が交差する floorplanning の領域は重要ではありません。それにもかかわらず、接続性を見ると、 floorplan の全体的な構成がツールを苦労させる時期を特定するのに役立ちます。

static logic に属しているように見える cells が reconfigurable area の内部に配置されていること、およびその逆であることは、ごく普通のことであり、問題ありません。注意すべきことは、どこかで混雑しているように見える場合です。 logic が一般的に、または特定の地域でぎっしり詰まっているように見える場合です。可能であれば、 floorplanning の変更はそれを軽減するのに役立ちます。

もう 1 つ注目すべき点は、 partition pinsの位置です。 device viewでは、次のように白い水平バーとして表示されます (画像をクリックして拡大)。

以前の投稿で述べたように、 partition pins は reconfigurable partition内のどこにでも配置できます。ただし、 partition pins が partitionの端から離れている場合、 router が Parent Implementationの間に timing と格闘したことを示している可能性があります。

この Tcl コマンドを使用して、 partition pinの座標のテキストリストを取得することもできます ( pr_block_ins を reconfigurable logic cellの名前に変更します)。

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

Partition pins の座標は、 CLBs のグリッドに対応します ( slicesではありません)。表示されている図面では、これらのピンは「Cell pins」と呼ばれています。

cellの pins の一部には、 partition pinが割り当てられていない場合があります。これは、 reconfigurable moduleの port list (および/または vectorsの幅) と static logic moduleによる instantiation の間に不一致がある場合に発生します。このような不一致は ( Verilogでは) 完全に正当ですが、望ましくない結果になる可能性があります。この Tcl コマンドを実行すると、特に意図的でない場合に、到達不能な portsを検出できます。

これで Vivado プロジェクトのセットアップに関する技術的な部分は終了しますが、次の記事では FPGA designの重要な側面について説明します: logic の交換が確実かつスムーズに行われるようにする方法.