本稿は、Xilinx の Vivado における部分再構成(Partial Reconfiguration)、別名 Dynamic Function eXchange(DFX)についての全 4 回の連載の 3 番目の記事です。前の 2 つは FPGA デザインのセットアップ方法を説明しましたが、今回は、リコンフィギャラブルロジックが消えたり再び現れたりするときに、スタティックロジックがどう対処するかを考察します。
概要
部分ビットストリーム(partial bitstream)をロードする処理は、物理ハードウェアのホットスワップに似ています。ある部品が突然取り外され、別の部品と交換されて、電源が入れ直されるのです。本稿では、この移行をスムーズかつ確実に行うために必要な手段について説明します。
本稿では、部分再構成が FPGA 上のスタティックロジック自身によって実行されることを前提とします。スムーズな動作を確保するには、次の段階を踏んで実行する必要があります(説明は後述)。
- リコンフィギャラブルロジックを安全な状態にします。リセットを掛けたときに、その出力の影響を受ける側が混乱しないようにするためです。
- リコンフィギャラブルロジックのリセット信号を有効にします。
- デカップリング(decoupling)を開始します。
- 部分ビットストリームを ICAP にロードします。
- コンフィギュレーションの STARTUP シーケンスが終了するのを待ちます。
- デカップリングを無効にします。
- リコンフィギャラブルロジックのリセット信号を無効にします。
デカップリングの必要性
部分ビットストリームをロードしている間、スタティックロジックとリコンフィギャラブルロジックの間の接続は予測できない状態になります。その結果、リコンフィギャラブルモジュールの出力ポートがランダムなパターンや不正な値を生成する可能性があります。これは必ずしも常にすべての出力ポートで発生するわけではありませんが、何らかの異常な挙動が見られる可能性は高いです。
スタティックロジックは、部分ビットストリームのロード中も動作し続けるため、悪影響を避けるには、リコンフィギャラブルモジュールから届く可能性のある予測不能な信号を無視する必要があります。Xilinx のユーザーガイド、UG909 は、このことをデカップリングと呼んでいます。
デカップリングを実装する方法は、リコンフィギャラブルモジュールの出力ポートの性質に依存します。各ポートがスタティックロジックに与える影響を分析し、必要に応じて予防措置を取るべきです。たとえば、再構成中に出力ポートをニュートラルな値にマルチプレクサで切り替える、応答すべきでないロジックにクロックイネーブル(clock enable)を追加する、スタティックロジックの一部をリセット状態に保持する、といった方法があります。
リコンフィギャラブルロジックが I/O パッドに直接接続されている場合は、これらをハイインピーダンス(high-Z)モードにするか、I/O ロジックのクロックイネーブルを無効にする(その I/O ロジックに出力レジスタが含まれている場合)必要があるかもしれません。また、リコンフィギャラブルロジックが外部コンポーネントに接続されている場合は、再構成の前にこれらのコンポーネントを安全な状態にする必要があるかもしれません。
AXI 接続をデカップリングするための Partial Reconfiguration Decoupler IP が、Vivado の IP カタログに用意されています。
リコンフィギャラブルモジュールの入力ポートにはそのような処理は不要です。スタティックロジックは、自分が駆動する信号が消費されなくても気にしません。
UltraScale デバイスについては、リコンフィギャラブルロジックをシャットダウンするクリアリングビットストリーム(clearing bitstream)をロードする前に、デカップリングが必要です。
STARTUP シーケンスについての補足
ビットストリーム(フルも部分も)において重要な部分の 1 つは START コンフィギュレーションコマンドです。これにより STARTUP シーケンスが開始されます。このシーケンスには、ロジックを一貫して立ち上げるためのいくつかのメカニズムが含まれています。
最初のメカニズムは、コンフィギュレーションの終了時に同期要素が既定値に設定されることです。これは UltraScale FPGA 以降では常に当てはまります。7 シリーズ FPGA では、フルコンフィギュレーション(つまり初期ビットストリームによるコンフィギュレーション)の場合、および部分再構成で RESET_AFTER_RECONFIG が有効な場合に当てはまります。
2 つ目は GWE(Global Write Enable。同期要素のイネーブル入力やライトイネーブル入力と混同しないでください)です。この信号により、フリップフロップと RAM が値を変更できるようになります。GWE はフルコンフィギュレーション中は FPGA 全体で Low に保持され、コンフィギュレーションの STARTUP シーケンスのどこかの段階で High に変化します。部分ビットストリームをロードするときは、再構成されたロジックだけが影響を受けます。
当然ながら、GWE の変化は、アプリケーションロジックが供給する任意のクロックに対して非同期です。したがって、この変化と最初の実効クロックとの間のタイミングは、どの同期要素についても予測できません。
部分再構成のシナリオでも、フルコンフィギュレーションと同様に、処理が完了した直後にはすべての同期要素が初期値を持つことになります(UltraScale 以降の場合、または RESET_AFTER_RECONFIG が設定されている場合)。しかし、一部の同期要素はアプリケーションロジックの最初のクロックサイクルに反応し、他の要素は反応しないというランダムな可能性があります。このランダムな挙動は、GWE が High に変化するタイミングに対して、最初のクロックがいつ到着するかに依存します。したがって、このような不確実性に影響を受けるすべてのロジックに、適切にリセットを適用することが重要です。
部分ビットストリームをロードした後にリコンフィギャラブルロジックをリセットする必要性は、FPGA のフルコンフィギュレーション後と同じです。ただし、フルコンフィギュレーションの場合は、リセットが必要であることがより直感的に理解できます。特に、リセットは何らかのロジック要素が安定するまで(たとえば MMCM や PLL がロックするまで、外部ハードウェアの準備ができるまでなど)アクティブに保持されることが多いからです。
まとめると、リコンフィギャラブルロジックにリセットを掛けるべきかどうか、また、そのどの部分に掛けるべきかについて、単一の答えはありません。フルコンフィギュレーションと同様に、同期要素には既定値が与えられ、クロックに反応し始めます。これで十分な状況もありますが、リセットが必要なシナリオもあります。
STARTUP の終了を検出する
前述の段階のうち、アプリケーションロジックの制御が及ばない唯一の部分は STARTUP シーケンスです。それでも、それがいつ終了したかを知ることは重要です。
各 FPGA ファミリの Configuration Guide には STARTUP シーケンスの説明がありますが、要するに、このシーケンスにかかる時間はビットストリームのオプションに大きく依存します。たとえば、MMCM がロックするのを待つように、または DCI がインピーダンス整合を完了するのを待つようにシーケンスを構成できます。
FPGA は End Of Startup(EOS)という信号を提供します。これは STARTUP シーケンスの最終段階(つまりシーケンスが終了したとき)に High に変化します。リセットを開始し、出力ポートの再結合(recoupling)を開始するという形で、いつリコンフィギャラブルロジックを復帰させるかを知るには、EOS を使うのが正式に正しい方法です。
EOS 信号を利用できるのはロジックファブリックの内側からのみであり、STARTUPE2 プリミティブ(primitive)のインスタンシエーション(instantiation)が必要です。たとえば次のようになります。
wire eos;
STARTUPE2 #(.PROG_USR("FALSE")) startup_ins
(
.CLK(1'b0),
.GSR(1'b0),
.GTS(1'b0),
.KEYCLEARB(1'b1),
.PACK(1'b0),
.USRCCLKO(1'b0),
.USRCCLKTS(1'b0),
.USRDONEO(1'b1),
.USRDONETS(1'b1),
.CFGCLK(),
.CFGMCLK(),
.EOS(eos),
.PREQ());
つまり、ビットストリームの ICAP へのロードが完了したら、EOS が High になるのを待ち、それからリセットと再結合を開始します。
UltraScale FPGA には代わりに STARTUPE3 プリミティブがありますが、Vivado はこれらの FPGA でも STARTUPE2 プリミティブを受け付け、STARTUPE3 に正しく変換します。したがって、上記のコード例はすべての FPGA ファミリをカバーします。
私は、ビットストリームの START コマンドが ICAP に届いてから EOS が High に変化するまでの時間を測定する、非公式なテストをいくつか行いました。
Kintex-7 では、ビットストリームの既定設定で、これに 26 クロックサイクルかかりました(100 MHz の場合、約 260 ns)。ビットストリームには NOP などの追加データも含まれていたので、EOS はビットストリームの最後のワードが ICAP に送られた直後に High に変化した可能性が非常に高いです。
しかし、Kintex UltraScale FPGA で同じテストを行うと、まったく異なる結果になりました。START コマンドの後、EOS が High に変化するまで、ランダムに 0.8 ms から 4.5 ms の間かかりました。
上記のように STARTUPE2 プリミティブを使うのは非常に簡単ですが、ビットストリームのロードが完了してから固定時間後に再結合を開始する方法もあります。たとえば、STARTUP シーケンスが 100 ms もかかるとは考えにくいですが、その程度の遅延は人間には実質的に気になりません。とはいえ、上記の 2 つのテスト結果を考慮すると、STARTUPE2 プリミティブを使うのが安全な方法だと思われます。
UltraScale FPGA に関しては、クリアリングビットストリームをロードした後の EOS の挙動は、どうやら文書化されていません。しかし、ある非公式なテストでは、クリアリングビットストリームをロードした後は Low のままで、その後ロードした部分ビットストリームの後に High に変化しました。
以上で第 3 回を終わります。最終回では、Vivado が OOC と DCP によってスタティックロジックとリコンフィギャラブルロジックの関係をどのように扱っているのか、その舞台裏と、それを理解することでリモートアップデート(Remote Update)のシナリオ向けに部分ビットストリームを確実に生成する道がどう開けるのかを説明します。