FPGAの開発フロー [後編]

図1に一般的なFPGAの開発フローを示します。
“配置配線” から “実機動作検証” までの各ステップを見ていきましょう。

図1. 一般的なFPGAの開発フロー

配置配線

Place & Route (PnR) と表記することもあり、タイミング制約・物理制約に基づいて自動的にロジックブロックの配置および、それらを接続するための配線経路を決定します（図2）。

図2. 配線配線結果のイメージ

ここで、FPGA開発ソフトウェアの配置配線の機能には、いくつかの実行オプションが用意されていることがあります。例えば以下のようなオプションがあります。

• スピード重視：
  タイミング制約を満たす、ベストな動作周波数が出るように配置配線を実行します。
  （デフォルトとして設定されていることが多く、使用するリソースが増える場合があります）
• エリア重視：
  タイミング制約の範囲で、リソース使用数を減らすように配置配線を実行します。
  （タイミング要求が厳しいと、あまり効果がでない可能性があります）
• 消費電力重視：
  タイミング制約の範囲で、消費電力が最小になるように配置配線を実行します。
  （タイミング要求が厳しいと、あまり効果がでない可能性があります）

その他、どのようなオプションがあり、どういう効果があるのか、開発ソフトウェアのユーザーガイド等を確認し、回路の仕様に適したオプションを選択するのがよいでしょう。

タイミング検証

タイミング検証では、配置配線された結果が、指定したタイミング制約を満たしているかどうかを確認します。これは静的タイミング解析：Static Timing Analysis (STA) とも呼ばれます。
では、具体的に何をどのように解析するのでしょうか？

• セットアップ(Setup)時間 と ホールド(Hold) 時間
  まず、タイミング検証において最も基本的なパラメータである、 セットアップ時間 と ホールド時間についてご説明します。
  フリップフロップがクロックエッジによって正しくデータを受け取り、出力させるには、セットアップ時間とホールド時間を規定通り確保する必要があります。図3 にフリップフロップのセットアップ時間(t_SU)とホールド時間(t_HD)の概念を示します。

図3.フリップフロップ(FF)のセットアップ時間(t_SU)とホールド時間(t_HD)の概念

セットアップ時間(t_SU)は、データ入力(D)をクロック(CLK)の立ち上がりエッジの前に安定させておくべき最小時間です。一方、ホールド時間(t_HD)は、データ入力(D)がクロック(CLK)の立ち上がりエッジ後に安定して保持すべき最小時間となります。この期間内にデータの変化点が入ってくると、セットアップ時間・ホールド時間を確保することができず、フリップフロップが正しく動作しない場合があります。また、t_COは Clock to Out と言い、クロックの立ち上がり基準で、入力されたデータDが出力Qに出てくるまでの時間です。これらのパラメータは、FPGA内部のフリップフロップ固有の仕様であり、使用するFPGAによって異なります。

• Required Time と Arrival Time と Slack
  Required Time は、あるポイントからあるポイントまでに要求される時間制約で、これがタイミング制約の指標の1つになります。例えば、入力クロック100MHzで動作させる回路では、1/100MHz = 10ns がその指標になり、FPGA開発ソフトウェアはすべてのフリップフロップ間の遅延を10ns以内に収めるように配置配線を行ないます。
  Arrival Time は、配置配線の結果を用いた、あるポイントからあるポイントまでの到達時間です。それはロジックブロックや配線の遅延を合計した時間であり、先にご説明したセットアップ時間やClock to Out時間も含まれます。
  タイミング解析では、このRequired Time（期待値）とArrival Time（実際の値）を比較します。
  期待値から実際の値を引いた結果を、Slack(スラック：“弛み/ゆるみ”の意味)と呼び、この値がマイナスになると、その回路は期待通りに動かないことになります。

  [Required Time(期待値)] － [Arrival Time(実際の値)] = Slack(スラック)

  ここで、 Arrival Time の計算では、ロジックブロックや配線の遅延などのタイミングパラメータが使用されますが、そのパラメータは環境条件である「プロセスのばらつき：P」、「電源電圧レベル：V」、「周囲温度：T」、すなわちPVTによって異なります。通常、タイミング解析では全てのワースト条件と、ベスト条件でのパラメータを使用しますが、様々な環境条件の組み合わせで解析することを推奨されているケースもあります。

  開発ソフトウェアはタイミング検証を実行すると、そのレポートを作成します。マイナスのSlackがあった場合、どこの回路が該当するのか、何が原因なのかを調査し、回路修正や論理合成・配置配線オプションの変更、タイミング制約の見直しなどの作業を行うことになります。

コンフィギュレーションデータ生成とプログラミング

コンフィギュレーションデータは開発ソフトウェアのデータ生成ボタンをクリックすることで簡単に生成することができます。
コンフィギュレーションデータのプログラミングのために、各FPGAメーカーではJTAGやSPIインターフェイスを備えた独自のハードウェアを用意しています。通称、「プログラミング・ケーブル」や、「JTAGケーブル」のように呼ばれ、図4 のようにパソコンのUSBポートとFPGAが実装された基板間を接続し、FPGA開発ソフトウェアに含まれるプログラミング・ソフトウェアを実行してプログラミングします。

図4. パソコンからのプログラミング構成の例

さて、「FPGAの種類」で説明したとおり、コンフィグレーションデータはFPGAによって格納する(保存しておく）場所が異なりました。以下でおさらいしてみましょう。

SRAMベースFPGA：
図5 のように、外部ROMにプログラムして格納します。

図5. SRAMベースFPGAのコンフィギュレーションデータ格納

エンベデッドFlash型 SRAMベースFPGA：
図6 のように、エンベデッドされたFlashメモリにプログラムして格納します。

図6. エンベデッドFlash型 SRAMベースFPGAのコンフィギュレーションデータ格納

FlashベースFPGA：
図7 のようにFlashコンフィギュレーションメモリに直接プログラムします。

図7. FlashベースFPGAのコンフィギュレーションデータ格納

これら以外にも様々なコンフィギュレーション手法が用意されており、その手法ごとに生成するコンフィギュレーションデータのフォーマットが異なる場合があります。また、生成するコンフィギュレーションデータを暗号化することもできますので、各メーカーのプログラミングやコンフィギュレーションに関するドキュメントを参照してください。

実機動作検証

ここでは文字通り、FPGAを実際に動かして検証を行います。FPGAに実際のデータを入力し、出力が正しいかを確認します。もし、出力に問題があった場合はどうしたらよいでしょうか？そうです、FPGAの中の回路のデバッグをしなくてはいけません。

FPGA開発ソウトウェアには、オンチップ・デバッガという機能を持っている場合があります。
これを使用することで、FPGA内部の動きをロジック・アナライザのようにPC上で確認することが可能になります。図8 にその構成の例を示します。

図8. オンチップ・デバッグの構成例

オンチップ・デバッグを行う際の前提条件として、設計者はあらかじめ回路の中にオンチップ・デバッグモジュールを組み込んでおく必要があります（その機能や手法はメーカー毎に異なります）。そのモジュールを組み込む際に、モニターする信号や、どれくらいのバッファを持たせるかを決めておきます。オンチップ・デバッグモジュールを組み込んだコンフィギュレーションデータをプログラムすることで、設計者はそのFPGA内部の信号を、JTAGを介してPC上で確認することができます。問題を発見した場合は、適切なフローまで戻ってデザインを見直す必要があります。
オンチップ・デバッグモジュールはFPGAのロジックやメモリを使用しますのでリソースに余裕があることが前提となります。また、モニターする信号を変更するなど条件を変更すると、再度、配置配線を実行する必要があります。デバッグが完了したら、そのデバッグモジュールを削除したほうがよいでしょう。

FPGAの開発は決して簡単なものではありません。実は、最後のコンフィギュレーションデータのプログラミングを除けば、やっていることはASICの開発フローとあまり変わりません。しかしながら、各FPGAメーカーはそれをできるだけシンプルかつ柔軟に使用できるよう開発ソフトウェアを進化させており、デザイン制約まで完了していればワンクリックでコンフィギュレーションデータまで生成することも可能になる等、年々開発のハードルは低くなってきています。
マニュアルやユーザーガイド、ソフトウェアのHelpなども充実していますので、必要に応じて確認しながらFPGA開発をマスターしていきましょう。