01signal.com

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の準備

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に割り当てる領域を決定することです。手順は次のとおりです。

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

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

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

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

この段階でプロジェクトの 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 タスクに十分にセットアップされています。

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

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

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 は次のようになります。

すべての 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 in Vivado's 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 の交換が確実かつスムーズに行われるようにする方法.

このページは英語から自動翻訳されています。 不明な点は元のページを参照してください。
Copyright © 2021-2024. All rights reserved. (c3c02857)