FPGAの検証手法はどうあるべきなのか（1/3 ページ）

FPGAに実装する論理回路の検証手法は、大きくシミュレーションとインサーキット検証の2つに分けられる。しかし、求められる機能がより高度になり、FPGAの集積度も格段に高まった現在では、どちらか一方の手法に頼るのは現実的なことではなくなってきた。効率良く、確実に検証を完了するには、どのような手段を用いればよいのだろうか。

[Ron Wilson，EDN]

検証手法に求められる変化

　その昔、FPGAに実装した論理設計の検証は次のような方法で行われていた。まず、論理設計のデータをコンパイルし、それを評価ボードにロードして、リセットボタンを押して開始するといった形だ。だが、米Xilinx社でソフトウエア製品マーケティング担当ディレクタを務めるHitesh Patel氏は、「FPGAに集積される回路の規模が大きくなるに連れ、この『インサーキット検証』は実効性の高いものではなくなってきた」と指摘している。数百万ものゲートから成るロジック回路が、外部端子をモニターするだけでデバッグできるほど完璧に近く仕上がる確率は限りなく低い。従って、設計チームはASICにおいて何年も実施されてきたように、ソフトウエアベースのシミュレーションに頼ることとなる。

　だが、このシミュレーションという手法に対しても疑問が生じている。例えば、FPGA設計におけるシミュレーションの役割は、ASIC設計におけるそれと同じでよいのだろうか。また、検証チームは設計上のある時点で論理回路をFPGAに実装して、実速度でテストを行うべきなのだろうか。もし、そうであるとしたら、ある時点とはいつなのか。

　このような疑問に対して、今日の設計チームがどのように対処しているのかを探るために、FPGAユーザーと最も密接に作業をしている人々に話を聞いてみた。また、検証手法の1つとしてFPGAを利用したプロトタイプを使うASIC設計者にも、その立場からの見解を示してもらった。

それぞれの利点/欠点

　検証フローに関する疑問について議論すると、ほとんどの人が、シミュレーションとインサーキット検証の2つについて、利点と欠点を相対的に評価することから始める。経験豊富な読者にとってはすでにご存じの話題でうんざりされるかもしれないが、本稿でもこの形式に沿って議論を進める。

■シミュレーションの利点

　シミュレーションの大きな利点は、もちろんアクセスのしやすさである。シミュレーションでは、RTL（Register Transfer Level）設計における任意の信号をクロックサイクルの精度で観測することができる。また、必要に応じて任意に回路の状態を制御することも可能だ。観測や制御の可能性を制限するのは、RTLに関する知識やシミュレーション環境に対する作業者のスキルのみである。回路のごく一部に対して対話式に作業を行うことができるし、数日間かかるような大規模な実験も行える。また、シミュレーションの設定は比較的短時間で実施可能なので、多くの項目を迅速に試してみることができる。

　シミュレーションのもう1つの利点は、今日のほとんどのシミュレーション環境でOVL（Open Verification Library）やSystemVerilogなどのアサーション技術を容易に取り込むことができる点である。アサーションによる検証がより一般的になるに従い、これは重要な利点となっている。

　また、シミュレーション環境では、回路への入力/観測を、回路それ自体に影響を与えずに行うことができる。この利点はさほど重要には感じられないかもしれない。しかし、検証作業を通して設計の一貫性を維持する上では、大きな要素となり得る。

■シミュレーションの欠点

　シミュレーションの欠点は、その実行速度が遅く、結果を得るまでに長い時間を要することだ。ハードウエアエミュレータベンダーのフランスEVE社でマーケティング担当バイスプレジデントを務めるLauro Rizzatti氏は、「200万〜300万ゲートのブロックを対象とした検証であれば、シミュレーションが最適だ。しかし、より大きく複雑なマルチブロックの設計を対象にすると、シミュレーションは遅すぎてほとんど役に立たない」と指摘する。

　また、制約となるのは、論理回路の大きさ/複雑さだけではない。米Altera社で技術マーケティング担当シニアマネジャを務めるPhil Simpson氏は、「対象となる論理回路が検証に大量の入力データを必要とするものである場合、ブロックレベルでさえもシミュレーションを行うのは非現実的となる恐れがある」と指摘する。同氏は、15分間のビデオクリップの真ん中でしかバグが出現しないビデオコーデックを例として挙げた。15分間の高解像度ビデオの圧縮解凍をシミュレーションするには、膨大な時間を要してしまうだろう。

■インサーキット検証の利点

　FPGAを用いて、対象とする論理回路を実際に動作させるインサーキット検証の利点と欠点は、シミュレーションの利点と欠点のまったく逆となる。つまり、最も明らかな利点は、高速であることだ。インサーキット検証では、回路を最高速度で動作できる場合が多い。ただし、設計の初期段階では、煩わされたくないタイミングの問題に対処しなければならない場合もある。

　また、シミュレーションとは異なり、FPGAでは設計に含まれるブロック数が増大しても、動作速度が必ずしも低下しない。このことも利点の1つだ。この利点から、個々のブロックではなく、設計全体をテストすることが可能である。検証用にわざわざ作成したテストケースではなく、実際の大規模なデータセットでテストを実施することが可能なのだ。

　さらに、その動作速度の高さとFPGAに実際のI/O端子が存在することから、“インシステム”で論理回路をテストすることもできる。ターゲットとなるシステムに接続したFPGA開発ボードか、ターゲットとなるプリント配線板（以下、基板）がすでに存在するなら、それらを利用してテストを実施できる。この検証方法ならば、「テストケースが、実際の動作環境を本当に反映しているだろうか」という不安を抱き続ける必要がない。加えて、実際の基板でテストを行えば、シグナルインテグリティや通信プロトコルにおける非互換性など、ほかの方法では事実上検出が不可能なI/O関連の問題も検出することができる。そのほか、インサーキット検証の副産物として、ソフトウエアを開発/テストするためのプラットフォームを構築できることも利点となる。

　これらの利点すべてが、システムレベル検証に適したものである。また、Altera社のSimpson氏は、ブロックのデバッグに適したインサーキット検証の興味深い利点も存在すると指摘する。「FPGAに検証したい論理回路ブロックを実装すると、当社の『Nios』のようなFPGA用プロセッサコアによってデバッグ作業の支援が行える。例えば、チップへのテストデータの入出力を行ったり、テストの順序付けを行ったりといったことをプロセッサコアによって実現するのだ。それにより、周辺回路が完成する前に、ブロックを単体でテストすることが可能になる」（同氏）というのだ。

　さらに、同氏は、「当社のIP（Intellectual Property）開発グループは、擬似ランダムテストを生成するために、Niosで動作するトランザクタを開発した。顧客の間でそれが一般的な手法となっているかどうかはわからないが、かなり有用なものになるだろう」と述べた。

　以上のような利点から、新しくコーディングした論理回路をFPGAに実装し、周囲のテスト環境を整えてテストを開始することに何の問題があるのかと感じられるかもしれない。その疑問に対する答えは、次に示す欠点にある。

■インサーキット検証の欠点

　インサーキット検証における最も明白な欠点は、その可視性の低さである。原理的には、FPGA内のすべての論理素子がチップ上のデバッグ用インターフェースから観測可能である。しかし、内部のデバッグポートの能力から考えるとやや意外だが、「実際にデバッグ用インターフェースを合成し、それを検証に用いるFPGAユーザーは、わずか半数ほどだ」とFPGAベンダーらは推測している。Xilinx社のPatel氏は、「FPGAの規模が大きくなるに従い、その割合が増えるだろう」と考えている。そうすると、多くの場合、回路内の信号を観測するには、ロジックアナライザを使用できるように、その信号を外部端子から出力するよう変更する必要がある。その場合、ロジックアナライザの性質から、内部クロックなどほかの信号もいくつか出力する必要があるだろう。つまり、余分な作業が必要となる。また、I/Oブロックの近くにはない高速信号を観測する場合は、FPGAのクロック周波数を下げる必要もあるかもしれない。こうしたことから、検証の計画を立てる際、FPGA内の信号をどの程度観測する必要があるのかを検討しておくことが非常に重要になる。このようにして信号を可視化するために追加の設計作業が必要となることが、インサーキット検証の欠点の1つである。

　さらに、チップ内部のノードに対する観測を行う際に発生する最も重大な問題は、論理回路の設計を変更/再構築/再合成する必要が生じることだ。このことで、設計とテストベンチの問題の切り分けが難しくなる。デバッグ用のコードと本来の設計のコードを慎重に分離し、徹底的なバージョン管理を行わなければ、変更履歴を見失い、患者の体内に手術器具を置き忘れるのと同じような重大な失敗を犯してしまいかねない。

　加えて、検証に対する準備時間の問題もある。大規模な設計における合成時間はばかにならないし、論理回路の変更や計測器の接続に要する時間も無視できない。こうしたことは、いくつかの検証の実施を断念する理由にもなりかねない。インクリメンタル合成ツールを利用することもできるが、2000万ゲート以上の論理回路の構築と合成は、一晩がかりのレベルの作業になる可能性がある。

　そのほかに、テストベンチをシミュレーションの環境からインサーキット検証の環境へと移行する際にも、問題が生じる。シミュレーション環境であればコマンドで行える論理回路への入力には、実際の回路が必要となる。また、ノードの観測には、実際の回路や物理的な計測器が必要だ。さらに、アサーションベースの検証が広まってきているのにもかかわらず、アサーションをシミュレーション環境からインサーキット検証の環境へと移すための体系的な方法は確立されていないようだ。Simpson氏は、「アサーションを自動的にインサーキット検証の環境に移行する手段は存在しない。この手段に対する要求は日々高まっている」と指摘する。

　インサーキット検証のもう1つの欠点は、カバレッジメトリクスに関するものである。シミュレーション向けには、検証カバレッジを測定し、異なる種類のツールの測定値を統合するための高度なツールが開発されている。しかし、FPGAのインサーキット検証には、カバレッジという概念すら存在しないとも言える。そのため、検証カバレッジを測定し、カバレッジクロージャシステムにそのデータを報告するようなツールも確立されていない。