FPGA設計の消費電力を見積もる（2/3 ページ）
FPGAを最終製品へ搭載する例が増加している。その場合、FPGAの利点を生かして設計期間を短縮するには、論理設計と並行して回路基板の設計を行う必要がある。このとき重要になるのが、設計初期段階におけるFPGAの消費電力の見積もりである。本稿では、この見積もりをより正確に行うための手法について解説する。
見積もりの精度改善
アルゴリズム開発からブロック定義、そして初期実装へと設計が進むと、信号やそのトグルレート、ブロック構造に関するより具体的な条件が明らかになってくる。だが、この時点では、RTL（Register Transfer Level）コードが確定するのはまだまだ先のことである。このころから、設計チームはFPGAベンダーが提供する電力評価ツールを使用し始め、自分たちの電力見積もりの精度を改善しようと試みることになる。
■スプレッドシートの活用
Kothandaraman氏によれば、「FPGAベンダーが提供する電力評価ツールの役割が重要になる。そうしたツールは通常、Excelのスプレッドシートとして提供される」という。
この種のツールには、設計に関する膨大な量の情報を取り込むことができる。例えば、米Altera社の技術スタッフであるIan Milton氏によると、「当社の『Early Power Estimator』には、レジスタのアクティビティレベルやクロック周波数、イネーブル端子と読み出し/書き込みのデューティサイクル、ブロックRAMの構成、入力信号の統計的特性、ブロック内の論理素子数の見積もりなどを入力することができる」という。
この種のスプレッドシートを利用する場合、設計チームは初期段階でアーキテクチャに関する情報を入力する。それ以外の多くの入力項目はデフォルト設定にしたままで、消費電力を大まかに見積もることができる。そして、設計に関するより詳細な情報が得られるようになったら、デフォルト値を実際の設計データに置き換える。それにより、電力見積もりの精度を改善することができる。
Milton氏は、「初期段階ではデフォルト設定を使用することを推奨している」と述べる。デフォルト値を推奨する理由は、FPGAベンダーは多数の回路の実際の計測値から、これらのデフォルト設定にインテリジェントな仕組みを組み込んでいるからである。例えばAltera社のツールでは、設計の中にクリティカルなタイミングを持つネットがいくつ存在するか、タイミングに余裕があるネットはいくつあるのかという見積もりを行い、その見積もりを用いて、それぞれの論理セルに、高性能版と低リーク版のどちらを適用するのかを決定する。
■ツールを生かすのは経験
上述したような高度なデフォルト設定の仕組みが用意されていたとしても、最良の見積もりを行うには、設計チームが回路の動作について深く理解している必要がある。この点について、eInfochips社のShah氏は以下のように指摘する。
「われわれは、まず入力データのパターンに着目する。次にクロックツリーの電力に注目する。そして、入力データがデータパスと制御パスのどちらに流れるのかと考えて、そこから内部のアクティビティレベルに関する理解を得ようする。これらの情報を得るための定義済みの計算式などは存在しない。それまでの経験と既存の方法論に頼るしかない。テンプレートやプロセスを作成することにより、新しい回路を設計するたびに得られる情報の体系化を図っていくのだ。残念ながら、FPGAベンダーは電力を意識した設計を行うための明確な方法論をまだ確立していない。そのため、世界中のすべての設計チームが独自の方法でこの作業を行っている」。
Wipro社のKothandaraman氏も、初期見積もり用のスプレッドシートを使用する際に、最も役立つものの1つが経験であるという点に同意する。「例えば、われわれは同じアプリケーション分野における以前の設計を基にI/O動作を予測している。その情報が、最終的な消費電力の見積もりに非常に役に立つ」と同氏は語る。
■初期見積もりでの落とし穴
初期段階における見積もりの精度は、どの程度のものになるのだろうか。これについて、Kothandaraman氏は「見積もり用のスプレッドシートツールは、かなり進化した。数年前までは、ツールが算出する結果には多くの問題があった。しかし、今日では、初期段階の見積もりと最終的な消費電力の誤差は20〜30％以内であることが期待できる」と述べる。Shah氏もこれに同意し、「ベンダーは、電力の問題をますます重要視している。より正確なモデルを提供するとともに、ツールの使用方法に関するウェビナー（ウェブベースのセミナー）も提供している」と説明する。
しかし、Kothandaraman氏は「設計が進むに連れて、設計初期に行った電力の見積もりが不正確になっていくこともある」と警告する。「設計を進める過程で、ロジックを追加していくというのはよくあることだ。それによって、最初の電力見積もりが無意味なものになっている場合があるのだ」と同氏は指摘する。
ツールが進化していく一方で、問題はさらに複雑になっていく。例えば、最新のFPGAは、プロセッサコアや、I/O、アナログなどの専用配線と複数の電源配線を備えた複雑な構造のデバイスへと進化している。米Lattice Semiconductor社でアプリケーションエンジニアを務めるJatinder Singh氏によると、「そうしたすべての配線が、電力解析を行う上では重要な意味を持つ」という。各種配線がそれぞれ異なる電圧領域に属し、I/O電圧が複数存在する場合もある。さらに、それぞれ独立して遮断することができる別々の電源配線を備え、それぞれが異なるアクティビティに対応しているかもしれない。
そのため、初期見積もりのスプレッドシートでは、論理ファブリックにおけるアクティビティをI/Oアクティビティと分離するといったことや、SERDES（Serializer/Deserializer）アクティビティは別の問題として区分するといったことをあらかじめ明確にしておく必要がある。
また、最新のFPGAがさまざまな回路ブロックを搭載するようになってきていることも、問題をさらに複雑にしている。例えば、DSPブロックについては見積もりに含め、内部RAMは見積もりから除外するといったことを行う必要がある。
最終見積もり
設計チームがRTLコードを作成する段階になると、スプレッドシートベースの評価ツールへの入力値はより正確なものとなる。しかし、シミュレーションが実施できるほどにロジックの量が増えてきたら、今度は別の種類のツールが必要になる。すなわち、電力アナライザだ。
電力アナライザでは、スプレッドシートベースの評価ツールとは異なる方法で見積もりが行われる。Altera社のMilton氏は、「RTLコードが完成すれば、合成とマッピングの実施が可能になる。そしてシミュレーションを実行すれば、VCD（Value Change Dump）を抽出することができる。このステップで、ブロック内のすべてのノードにおける実際のトグルレートが得られる」と説明する。電力アナライザはこのデータを読み込み、実際のLUT（Look Up Table）と各ノードの配線、セグメントの構成を示すマッピングファイルを統合し、消費電力を算出するのである。この電力アナライザについて、Milton氏は以下のように語っている。
「マッピングツールが2つの論理素子を接続するために使用する実際の配線領域など、マッピングファイルには顧客が知り得ないような情報が入っている。また、電力アナライザは、FPGAとASICの違いを“認識”している。例えばASICでは、あるANDゲートの1つの入力がローである場合、そのゲートには意味のあるアクティビティは生じず、出力はローとなる。一方、FPGAでは、出力バッファはローのままでも、LUT内部で多大な電力を消費するアクティビティが生じる。アクティブな入力が変化するたびに、小さなRAMに対する読み出しサイクルが生じる」。
■ツールが問題なのではない
電力アナライザを使えば、FPGAに実装する回路の最終的な消費電力の見積もりが確定するはずだ。しかし、いくら精度が高くても、誤ったデータを入力すれば、結果も誤ったものとなる。eInfochips社のShah氏によると、「早い段階で正確すぎるツールを使用することは、消費電力を見積もる際の問題の1つになる」という。「不完全なRTLコードによって電力見積もりを更新するのは避けるべきだ。コードのわずか数％に相当する残りの部分が、電力の30％を消費するという可能性もある」と同氏は指摘する。
また、Shah氏は、RTLコードに加えたほんの少しの変更によって、消費電力が大きく変わる場合があると警告する。「FPGAのマッピングは、ASICのレイアウトほど固定的なものではない。配線は、デバイスにおける残りのリソースに依存する。FPGAに回路を配置していくうちに、互いに接続しているLUT間の距離が長くなると、LUT間を行き来する信号の各トグルにおいて消費する電力が大きく増加する」（同氏）ことがある。
Wipro社のKothandaraman氏も、以下のように注意を促している。
「電力アナライザによって、回路の消費電力に関して常に把握できているとは限らない。このような欠点が生じる理由の1つは、われわれが設計の終盤に差しかかるまでロジックを追加し続けるためだ。また、電力アナライザによる見積もり値は、シミュレーションのシナリオに依存するが、使用しているシミュレーションダンプが電力解析に最も適しているものであるとは限らない。さらに、FPGAの設計には多数の動作モードが存在することに加え、ワーストケースのトグルレートを実現するベクトルを生成するのは非常に困難だ」。
この最後に挙げたポイントについて、Kothandaraman氏は、「電力見積もりのためのベクトル生成に関する経験を把握するために、Wipro社は、設計チーム内にフィードバック体制を確立しようとしている」と説明する。しかし、その作業はまだ完了していないという。
同社は、ワーストケースのトラフィックパターンがどのようなものであるかを経験から知っている。例えば、ネットワーク機器におけるメモリーアクティビティ情報を得るのに、どのようなシミュレーションが適しているかを把握しているという。しかし、例えばFPGAをメディアプロセッサとして用いる場合に、処理の対象としてワーストケースとなるビデオクリップを特定するには、何種類ものシミュレーションを実施しなければならない。Kothandaraman氏は、「論理ファブリックのアクティビティのみでなく、FPGAのほかの部分の動作も調査することが重要だ」と指摘する。つまり、メディア処理とネットワーク処理のいずれのアプリケーションにおいても、メモリーブロックとSERDESのほうが、論理ファブリックよりも消費電力に対する影響が大きいかもしれないのだ。
また、ますます重要性を増している要素として、多くのFPGAにマイクロプロセッサコアが組み込まれていることが挙げられる。つまり、消費電力の見積もりには、RTLによるロジックやマッピング、ベクトルだけでなく、プロセッサ上で動作するファームウエアが大きく影響を与えることになるのだ。ハードウエア設計チームがRTLで記述したロジックを確定し、消費電力に関するデータを確定しようとしているまさにそのとき、ソフトウエアチームがファームウエアを最も頻繁に変更する段階にあって、消費電力に大きな影響を及ぼしているかもしれないのである。
Kothandaraman氏は、以上のようなことを踏まえて、「電力アナライザは慎重に使用する必要がある。初期段階におけるスプレッドシートベースの評価ツールを用いた見積もり結果のほうが、電力アナライザを用いた結果よりも正確である可能性もある」と警告する。
Copyright © ITmedia, Inc. All Rights Reserved.