Vivadoに Partial Reconfiguration を搭載したRemote Update

これは、 Partial Reconfiguration、または Dynamic Function eXchange (DFX) と Xilinxの Vivadoに関する4 つのシリーズの最後の投稿です。これは主に、 Remote Update シナリオで Partial Reconfiguration を使用したい人を対象としています。この投稿は、前の 3 つを既に読んでいることを前提に書かれています。

序章

Partial Reconfiguration の一般的な説明と、この目的のための Vivadoの通常の手順について説明したこの投稿では、 FPGAの logicの Remote Update にこの手法を使用するための基礎を設定します。

この使用シナリオの主な問題は、 partial bitstream がおそらく何年も前に生成された initial bitstream と互換性がある必要があることです。したがって、元の Parent Implementation は、 reconfigurable logicの implementation の間に使用可能である必要があります。または、まったく同じ結果 (つまり、まったく同じ place and route) を生成するには、元の Parent Implementation を再生成する必要があります。

Parent Implementation の再実行を避けるために、 Vivado プロジェクト全体をそのままにしておくことができる場合があります。この implementation を繰り返せば全く同じ結果が得られるかもしれません。ただし、これら 2 つの方法のいずれかに基づいて、将来 partial bitstreams をリリースする可能性を確保することは困難です。

この問題には信頼できる解決策がありますが、それがどのように機能するかを理解するには、まず DCPs と OOCsに慣れる必要があります。両方のトピックを簡単に紹介します。

Design Checkpoint (DCP)

Vivado は、 synth_1、 impl_1 、および Out-of-Context module runs (OOCs) として分類される追加の runs と呼ばれるいくつかの Design runsのおかげで、 FPGA designの implementation を実行することを思い出してください。

このような各 run は、一時的な「in-memory project」を生成し、 design ファイルをロードし、プロパティと属性を設定し、 synthesis、 placing、 routingを実行する Tcl 関数を呼び出し、 bitstreamsを生成し、その他のタスクを生成する Tcl scriptの実行で構成されます。

この in-memory project はディスク上にファイルを作成せず、 GUIで表示される Vivado プロジェクトとは何の関係もありません。これは、 Tcl コマンドで多くの順次操作を実行できるメモリ内の object です。

implementation が進行するにつれて、 Design CheckPoints (DCP) ファイルがディスクに書き込まれます ( Tclの write_checkpoint コマンドによって)。 DCP ファイルの内容は、 in-memory projectの snapshot です。つまり、ロードされた design ファイルと、ロード後にプロジェクトに対して行われた操作を反映した database です。

たとえば、 synthesis run (通常は synth_1という名前) は、すべての HDL ファイル、 constraint ファイル、および IP ファイルをロードし、 HDL ファイルの synthesis を実行するために synth_design と呼ばれる Tcl コマンドを使用します。その結果、これらすべての sources ( IPsを含む) から 1 つの大きな netlist が作成されます。ただし、 netlist は in-memory projectの一部としてメモリに格納されることに注意してください。したがって、 synthesis runの Tcl script は、 synthesisの製品である DCP ファイルを作成するために、 write_checkpoint に関数呼び出しを行います。これで synth_1 runは終わりです。

実際、 synth_1 によって生成された DCP は、通常 XDC ファイルからの constraints も含まれていますが、 netlist DCP と呼ばれます。

その後に登場する implementation run (通常は impl_1と呼ばれます) は、新しい in-memory project を作成し、この netlist DCP (とりわけ) を次の操作の開始点として読み取ります。この run は、いくつかの DCP ファイルを書き込みます。それぞれが、処理段階後のプロジェクトの snapshot です ( optimize design、 place、 physically optimize、 route など)。

synth_1を含むすべての runsは、 DCPs を in-memory projectにロードできます。これは彼らが通常行うことです。

Out Of Context (OOC) Module Runs

Vivadoでは、 IPs は通常、 GUI ツールによって構成されます。これが完了すると、 script は source files (主に HDL および constraint ファイル) を生成し、これらに対して synthesis を実行します。これにより、 netlist DCPが生成され、メイン プロジェクトの synthesis run および implementation runsにロードされます。これにより、 IPs の sources を再生成し、 synthesis を何度も実行する必要がなくなるため、プロジェクト全体の implementation が完了するまでにかかる時間が短縮されます。

生の製品 ( IPの構成情報、いくつかの HDL ファイル、またはそこにあるもの) を取り、それを netlist DCPに変換する Vivado run は、 Vivadoの用語では Out-Of-Context run と呼ばれます。この用語は Vivadoに関連してのみ使用され、私が知っている他の用途はありません。それは実際にはかなり貧弱な名前の選択です。

この netlist DCP は synthesis run と implementation runsによってロードされ、通常は Tcl コマンド ( read_ip) によってロードされます。これは通常、 OOC runによって生成された DCP をロードすることになります。

Vivado では、メイン プロジェクトで HDL module を選択し、その synthesis を OOC として実行するように要求することもできます ( Project Managerの source tree で source を右クリックし、「Set as Out-of-Context for Synthesis…」を選択します)。

OOCs の欠点は、 synthesizer が design 全体を 1 つのプロジェクトとして取得すると、 modules の境界を越えて特定の最適化を実行できることです。そのため、 OOCs のおかげで個々の synthesis はパフォーマンスを低下させ、リソースを浪費する可能性があります。

OOCs および DCPs と Partial Reconfiguration

reconfigurable moduleの top-level として source ファイルが選択されている場合、 Vivado は、この module とその submodulesの synthesis に対して OOC run を作成します。この run は、関連する implementationで使用する netlist DCP を生成します。これは、 Parent Implementation だけでなく Child Implementationsにも当てはまります。 reconfigurable module は、常に別の DCPで表されます。

ただし、この netlist DCP は、 Parent Implementation と Child Implementationsでは異なる方法で使用されます。 Parent Implementation に割り当てられた netlist DCP は、通常の implementationで IP を使用する場合と同様に、 synth_1 と impl_1によってロードされます。 Partial Reconfiguration が関与しているという事実は、主に floorplanningによって課される placement constraints を通じてこのプロセスに影響を与えます。

一方、 Child Implementationには専用の synthesis フェーズがありません。むしろ、 reconfigurable moduleの netlist DCP を Parent Implementation からの最終的な DCP (つまり、 place and routeの後の DCP ) と混合します。より正確には、 Child Implementation は Parent Implementationの最後の DCPを取り、 reconfigurable logicの部分を削除し、代わりに独自の reconfigurable moduleの netlist DCP を挿入します。ズッキーニの詰め物などを作るために野菜の真ん中の部分を取り除くようなものです.

ここで、これを Tcl コマンドに分解します。

Parent-Child implementationsのナットとボルト

implementation がフードの下でどのように動作するかを探す場所は、プロジェクトの名前 (および .tcl サフィックス) を持つ Tcl ファイルにあります。このファイルは、 implementationのファイルが作成されたディレクトリと同じディレクトリにあります。

特に child implementation の implementation script は面白い。関連するユーザー ガイド UG909の第 3 章 (「Vivado Software Flow」) で、直接言わなくても scriptが示され、説明されているのは偶然ではありません。

先ほど述べたように、 Parentの implementationについては、 reconfigurable moduleの netlist を DPC に依存していることと、 floorplanning constraints が適用されていることを除いて、それほど特別なことはありません。 hierarchical designとほぼ同じです。

しかし、 Parent Implementation は、次のような Tcl コマンドのおかげで、1 つではなく 2 つの bitstreams を書き込みます。

write_bitstream -force -no_partial_bitfile theproject.bit
write_bitstream -force -cell pr_block_ins pr_block_ins_lpf_partial.bit

そして、後で Child Implementationによって使用される DCP を作成します。

update_design -cell pr_block_ins -black_box
lock_design -level routing
write_checkpoint -force theproject_postroute_physopt_bb.dcp

この部分の実行中に、 netlist DCPsのロードで開始され、 place and route および他のすべての最適化を経た in-memory projectがあることを思い出してください。これらの 3 つの Tcl 行は、 bitstreamを書き込んだ後に実行されるため、 in-memory project は本当に最終段階にあります。

これは、穴を開けてズッキーニの詰め物をするのに適した時期です。 update_design コマンドは、 reconfigurable module を black boxに変えます。つまり、そのすべての logic が削除され、他の logic が入る余地が生まれます。

次に、 design の place and route が lock_design コマンドによってロックされます。その後、プロジェクトの snapshot が theproject_postroute_physopt_bb.dcpに書き込まれます。 「bb」はもちろん「Black Box」の略です。

Child Implementationの script の関連部分は次のとおりです。

create_project -in_memory -part xc7k325tffg900-2
set_property design_mode GateLvl [current_fileset]
add_files -quiet .../impl_1/theproject_postroute_physopt_bb.dcp
add_files -quiet .../two_synth_1/pr_block.dcp
set_property SCOPED_TO_CELLS pr_block_ins [get_files .../bpf_synth_1/pr_block.dcp]
link_design -top theproject -part xc7k325tffg900-2 -reconfig_partitions pr_block_ins
opt_design
write_checkpoint -force theproject_opt.dcp
[ ... ]

この時点から、 place and route などに進みます。

上記の implementation script は 2 つのソースのみを消費し、両方とも DCPsであることに注意してください。

• place、 route 、およびロックの後、 static logicであるtheproject_postroute_physopt_bb.dcp。
• reconfigurable moduleの netlist であるpr_block.dcp(つまり、 synthesisのみの後)。

implementation が続行すると、最初の DCP がロックされたという事実により、 static logic が何も動かないことが保証されます。それにもかかわらず、 reconfigurable moduleの place and route は、 netlist DCPに基づいて、通常どおりに行われます。

補足として、 reconfigurable moduleに属する XCI IPs がある場合、上記の 2 つの add_files コマンドの間に、 IPごとに次のような行が追加されます。

read_ip -quiet .../theproject.srcs/sources_1/ip/blkmem/blkmem.xci

ただし、これは Partial Reconfigurationにとって特別なことではありません — どの implementationでもこの方法で行われます。

2 つの bitstreamsを書き込む直前に、 Child Implementation は取得した routed design が Parent Implementationの static logic 、特に place and routeと互換性があることを確認します。

このための Tcl コマンドは次のようなものです。

pr_verify -full_check -initial /path/to/impl_1/theproject_postroute_physopt.dcp -additional /path/to/child_1_impl_1/theproject_routed.dcp -file child_1_impl_1_pr_verify.log

これは、 in-memory projectに関係なく、2 つの DCP ファイルを比較することに注意してください。 Parent Implementationの routed DCP は、 Child Implementationの最終的な DCP と比較されます。この比較の出力は、 *_pr_verify.logという名前のファイルに送られます。

この比較により、 parentの bitstream が FPGAにすでにロードされている場合でも、 partial bitstream がロードできるという意味で互換性があることが保証されます。 static partitionの logic elements だけでなく、 routingも通過します。

非互換性がある場合、pr_verify は失敗ステータスを返します。これが発生すると、 Vivadoの script での bitstreams の作成が妨げられます。カスタム implementation scriptsを作成するときは、この手順を念頭に置いておくことが重要です。

この検証が失敗する理由はありませんが、失敗した場合、 bitstream generation は "ERROR: [Constraints 18-891] HDPRVerify-08: design check point .../impl_1/theproject_postroute_physopt.dcp places instance ... at site SLICE_X118Y125, yet design check point .../impl_2/theproject_routed.dcp does not. Both check point must have the same static placement result" のような多くのエラーで失敗します。

これらのエラー メッセージはおそらく 100の制限に達し、その後沈黙します。

Remote Update シナリオのソリューション

上記の課題は、 reconfigurable logic の implementation が Child Implementationとして実行されるときに、元の Parent Implementation の結果が利用可能でなければならないということであることを思い出してください。

brute-force の解決策は、 Vivado プロジェクト ディレクトリ全体と、それが依存する可能性のあるファイルのコピーを作成することです。新しい partial bitstream を生成する必要が生じた場合は、すべてのファイルを復元し、 Parent Implementation を強制的に最新の状態にして、 Child Implementation 専用の bitstream を作成します。この方法は技術的には問題ありませんが、長期的には煩わしいものになる可能性があります。この方法を選択した場合は、元の Parent Implementationの DCP ファイルに対して pr_verify を手動で実行してください。この方法では、 Parent Implementationの意図しない変更が検出されないためです。

上記で説明したように、 Parent Implementation と Child Implementations が 2 つの DCP ファイルを介してどのように相互作用するかについての知識に基づいた、他に 2 つの代替手段があります。これら 2 つの方法の明らかな利点は、自分が何をしているのかを理解していることです。

両方の代替案の背後にある原則は、 partial bitstream が initial bitstreamと共に生成された 2 つの DCP ファイルに依存することを保証することです。これをGolden DCPsと呼びます。

最初の選択肢は、 partial bitstream の implementation を non-project flowで Tcl script として実行することです。基本的に、 Vivado が Child Implementation用に作成した script を実行することを意味しますが、 Golden DCPsを使用するように変更します。より正確には、 link_design コマンドと pr_verify コマンドの引数を変更して、 Golden DCPsに依存するようにします。

この代替手段の主な欠点は、 non-project flow で Tcl script を実行すると、 Vivadoの GUIとうまく統合されないため、メッセージの処理やレビューのために implemented design を開くことがかなり難しくなることです。

Golden DCPs hack

理想的には、 Vivado によって生成された script を Child Implementation run用に自動的に変更して、 Golden DCPsに関連付けることができたはずです。残念ながら、それを行うための信頼できる方法はないようです。

ただし、 Vivado では、 implementationの特定のステージの前後に Tcl scripts を定義して実行することができます。これらの scripts は implementation runの scriptから実行されるため、 runの script 自体を変更するために使用することはできません。

それにもかかわらず、これはやや醜い方法で開かれます。これは 2 番目の選択肢です。 アイデアは、 Parent Implementation の DCPs を Golden DCPsで上書きすることです。そうすることで、 Child Implementation は正常に動作しますが、 Parent Implementation がたまたま生成したものに関係なく、 Golden DCPsに依存します。

この方法の利点は、 Vivado での通常の作業習慣が変わらないことです。 reconfigurable logicに変更が加えられ、 Vivado は reconfigurable moduleの synthesis のために OOC を再実行し、次に partial bitstreamを生成するために Child Implementation を再実行します。 static logicには変更が加えられていないため、 Vivado は関連する runsを開始する理由がありません。

この Golden DPC コピー方式を実装した Tcl script は、

if { [catch {
    set parentimpldir "[ file normalize "../impl_1"]"
    set goldendir "[ file normalize "/path/to/golden"]"

    file copy -force "[file normalize "$goldendir/theproject_postroute_physopt_bb.dcp"]" "$parentimpldir/"
    file copy -force "[file normalize "$goldendir/theproject_postroute_physopt.dcp"]" "$parentimpldir/"
} errmsg ] } {
    send_msg_id golden-reconfig-1 error "Failed to copy golden parent reconfiguration file(s): $errmsg"
    return -code error
}

この script は、 Parent Implementation が Child Implementation ディレクトリに隣接する「impl_1」ディレクトリに保持されており (おそらくそうです)、2 つの Golden DCPs がこの scriptの 3 行目で定義されているディレクトリに格納されていることを前提としています。

Design Runs タブで child run (たとえば child_0_impl_1) を右クリックし、「Change Run Settings…」を選択し、開いた dialog で Design Initialization (init_design) の tcl.pre を scriptに設定します。または、 Tclで、 script が golden_pr.tclとして保存されている場合:

add_files -fileset utils_1 -norecurse /path/to/golden_pr.tcl
set_property STEPS.INIT_DESIGN.TCL.PRE [ get_files /path/to/golden_pr.tcl -of [get_fileset utils_1] ] [get_runs child_0_impl_1]

この script を使用する際に留意すべき重要なことは、 Parent Implementationに関して Vivado によって提示されるすべての情報、およびその代わりに生成されるファイルを無視することです。 Vivado は Implemented Design GUI を開いてレポートを表示することがありますが、これはまったく無関係である可能性があります。したがって、これは混乱の始まりです。

2 つ目の問題は、プロジェクトの設定や constraints ファイルの変更に応じて、 Vivado が時々 Parent Implementation を実行する可能性があることです。これは、 Design Runs タブで関連する行を右クリックし、「Force Up-to-Date」を選択することで回避できます。このメニューは、 run が Out-of-Date 状態にある場合、つまり完了したが、 Vivado がリフレッシュが必要であると判断した場合にのみ表示されます。関連する Tcl コマンドは、たとえば

set_property needs_refresh false [get_runs synth_1]

Golden DCPsと一緒に保存するファイル

将来的に互換性のある bitstream ファイルを生成する機能を維持するために、 Golden DCPs を安全な場所に保管する必要があることは明らかです。これらに加えて、 Vivado プロジェクト全体を .tar.gz / .zip ファイルに圧縮して、迅速に再開することをお勧めします。代わりに、またはそれに加えて、 project archive は File > Project > Archive… などで生成できます。

archive_project /path/to/theproject.xpr.zip -force -include_local_ip_cache -include_config_settings

ただし、プロジェクト ファイルと Vivado プロジェクト内の他のファイルの両方に absolute pathsが含まれている可能性があるため、プロジェクトを別のディレクトリまたは別のコンピューターに配置すると、期待どおりに動作しない可能性があることに注意してください。これはアーカイブにも当てはまります。

どの Vivado バージョンが使用されているかは、考えられるすべてのレポート ファイルと .xpr プロジェクト ファイルに書かれていますが、それをメモしておくと問題ありません。ソフトウェアのアップグレードが重要な明確な理由がなくても、 Vivadoのそのバージョンの実行可能コピーを保持する可能性があります。ある Vivado バージョンの Golden DCPs と別のバージョンの reconfigurable logicの netlist DCP を混在させると、おそらく問題なく動作します。しかし、これは Vivado が計画していたことではありません。

これをまとめると、最小限のファイル セットは次のとおりです。

• Golden DCPs: theproject_postroute_physopt_bb.dcp および theproject_postroute_physopt.dcp
• initial bitstream ファイル、例えば theproject.bit (これは FPGAをロードするために使用されるため、このファイルを保存することは明らかです)
• Parent Implementationを構築するためのソース。
• Ultrascale FPGAs のみの場合 ( Ultrascale+を除く): initial bitstreamに関連する clearing bitstream 。

Ultrascale FPGAs での clearing bitstream の使用は、すでに FPGAにある logic に関連していることに注意してください。そのため、 initial bitstream に関連する clearing bitstream を保存する必要があります。また、 initial bitstream が何らかの Child Implementationの結果である場合、その implementation の clearing bitstream を保存する必要があることに注意してください。

Parent Implementationの sources の保存に関しては、 static logic と reconfigurable logicの間の接続を決定するため重要です。たとえば、 sources が編集され、 port が reconfigurable logic に追加され、この port が instantiationに表示される場合、 partition pins のセットが変更されます。したがって、 reconfigurable logic の netlist には、元の static designには表示されない外部 pins があります。

このような不一致が発生すると、 child implementation は失敗し、「ERROR: [Netlist 29-77] Could not replace (cell 'pr_block_bb', library 'work_pr_block_ins_pr_block_ins_4', file 'NOFILE') with (cell 'pr_block', library 'work', file 'pr_block.edf') because of a port interface mismatch; in strict mode, no extra ports are allowed. 8 ports are missing on the original cell. 5 of the missing ports are: 'thingy[7]' 'thingy[6]' 'thingy[5]' 'thingy[1]' 'thingy[0]'」のようなエラー メッセージが表示されます。

この場合実際に失敗するのは、 static logic と combinatorial logic を結び付ける link_design コマンド (上記参照) です。

この問題を回避する簡単で明白な方法は、 designの static 部分を変更せず、 reconfigurable logicの port list も変更しないことです。

ただし、プロジェクトの static 部分を変更しても問題ありません。 同じままでなければならないのは、 reconfigurable module の instantiation だけです。 implementation は最後の検証も含めてスムーズに進めば問題ありません。

概要

Partial Reconfigurationを Remote Update で使用するための完全にスムーズな解決策はありませんが、それでもこの目標を達成するためのいくつかの利用可能な戦略があります。

重要な点は、既存のプロジェクトで partial bitstream を構築して検証するには、原則として 2 つの Golden DCPs があれば十分だということです。

ここで提示された戦略がいかに型破りに見えるかもしれませんが、 pr_verify によって実行される検証は、 partial bitstream と既に導入されている static logic との間の互換性を包括的にチェックするものであることを覚えておいてください。この検証に正しい Golden DCP が使用され、テストに合格する限り、他に心配する必要はありません。さらに、 Child Implementation はもちろん timing constraintsを達成しますが、それは designのどの implementation にも当てはまります。