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

[Ron Wilson，EDN]

最適な検証方法

　FPGAベンダー/ユーザーとの議論から、シミュレーションにエミュレータを組み合わせた検証フローに関する一致した意見がうかがえる。図1（c）の検証手法では、ブロックレベルのシミュレーションから開始する。ここで行われるのは、ASICの場合のような徹底的で完璧を求めるシミュレーションではなく、“リアリティチェック”のようなものだ。ブロックが機能していることや各端子における動作がほぼ正しいこと、実験環境においてFPGAのタイミングを満たすことなどを検証するのがその目的である。

図1　FPGAの検証手法　シミュレーションとインサーキット検証を組み合わせた代表的な3つの手法を示した。（a）は従来のFPGAユーザーによる手法、（b）は従来のASIC設計者による手法、（c）はそれらを組み合わせた手法である。今日採用されている検証フローには、さまざまな種類が存在することがわかる。

　この時点で多くのチームはブロックをFPGAへと実装し、より徹底的なインサーキット検証を開始する。特に、ビデオコーデックのように正しく機能していることを検証するために長い高速データストリームが必要となるブロックや、高速I/O機能を含むブロックである場合にこの方法がとられる。そのほかのケースでは、FPGAに実装できる状態になるまでブロックレベルのシミュレーション作業が続けられる。

　ブロックの統合を開始する際、つまりテストシステムを構築する際には、FPGAがその威力を発揮する。この段階では、論理回路は高速シミュレーションの対象とするには大きすぎるかもしれない。あるいは、ブロックが正しく動作していることが既知であるため、シミュレータ上ではなく、FPGA上で統合に関する問題を調査するほうが生産的な状態になっているかもしれない。

　シミュレーションからインサーキット/エミュレータ検証への移行は、可逆的なステップではないというのも一致した意見だ。シミュレーションとソフトウエア開発が並行して実施されるのと同様に、エミュレーション中にもシミュレーションによる検証は続けられる。また、ほとんどの場合、インサーキット/エミュレータ検証によってバグを検出/特定したら、それをシミュレーションへと戻して分析してもらうことになる。なぜなら、FPGA上で詳細な分析を行うのは非常に困難だからである。

　以上が今日の検証手法の概要だが、いくつか、この手法の深刻な問題点がうかがえるはずだ。1つは、テストベンチのデータを異なる環境間でやりとりするのが困難だということである。テストデータを作成するためのシミュレーションのコマンドを、FPGAに自動的に対応付ける方法は存在しないようだ。

　もう1つは、すべての主要なFPGAベンダーが提供する組み込みプロセッサコアは、ほとんど活用されていないようだということである。そうしたプロセッサコアを用いれば、データを管理してテストを制御することが可能だが、シミュレーションのテストベンチからは切り離されている。ただし、原理的には、シミュレーションチームはテストベンチを、FPGA用のRTLコードではなく、組み込みプロセッサコア向けのCコードへと移行することができるはずだ。

　もう1つの問題点は、インサーキット検証で収集したデータをシミュレーションベンチへと戻すための簡単なパスが存在しないことである。さらに、シミュレーションにおいてアサーションベースの検証が広まるに連れ、インサーキット検証で利用可能な類似のアサーションベースのツールを提供することも課題となっている。

　FPGAベースのエミュレータを販売するベンダーは、こうした問題に対処しようとしている。逆に言えば、そのことから、上述した事柄が問題となっているのは明らかである（別掲記事『2つの検証手法の利点を併せ持つシステム』を参照）。ベンダーによる対処策である製品の例としては、EVE社のシステムや、米GateRocket社が提供するシミュレーションアクセラレータ、米Cadence Design Systems社の大規模なエミュレーションボックス「Palladium」などがある。これらのシステムが、FPGAの検証におけるボードレベルのエミュレータとして一般化するのか、それとも高価なシミュレーションアクセラレータの派生版にとどまるのかということについては、今後の動向を見守る必要がある。

2つの検証手法の利点を併せ持つシステム

　FPGAを用いたエミュレータの処理速度は魅力的なものである。しかし、検証に必要となるセットアップ時間の長さや、制御/観測が困難であることが問題になる。そのため、面倒で時間のかかるテストはシミュレーション環境で実施せざるを得ない場合が多い。

　FPGAの動作速度を生かしつつ、シミュレーションのようにセットアップと制御/観測が容易な検証プラットフォームが構築できれば理想的である。実は、このことを目指した製品を開発しているベンダーが存在する。

　最初に開発されたのは、初期のASICの時代に登場した大規模なロジックエミュレーションシステムである。特殊なメインフレームコンピュータとも言えるような装置であり、カスタムのマイクロプロセッサかカスタムのプログラマブルロジックデバイスが、論理回路の動作をそれぞれシミュレーション/エミュレーションするというものであった。この種のシステムの代表的なものが、Cadence社のPalladiumである。「シミュレーションの何倍もの実行速度を実現し、少なくともテストの対象とする論理回路に対しては容易なアクセス手段を提供できる」とベンダーらは主張していた。しかし、実際にはその能力に限界があり、シミュレーションでも対応可能な程度のゲート数しか扱うことができなかった。もちろん、莫大な予算を投入できるというのなら話は別である。実際には、これらのシステムを導入すること自体、かなり大きな設備投資であり、最終製品にFPGAを組み込もうと考えている設計チームにとっては予算の範囲を超えていた。

　そうした中、この数年間のうちに市販のFPGAを用いてロジックエミュレーションを実行可能な簡素なシステムがいくつか市場に登場してきた。EVE社などが、そうした製品を提供する代表的なベンダーである。この種のシステムは、小型メインフレームのようなものから、デバッグ用ソフトウエアによってサポートされたFPGA用評価ボードのようなものまで多種多様である。ただ、いずれの製品も、大規模なエミュレーションシステムよりオーバーヘッドの小さい実行環境を提供することを目的としている。実際、いずれのシステムも、メインフレームベースのエミュレーションシステムより数桁高速に実行できるように工夫されている。しかし、一般的に、動作速度が高速になるほど利便性は低下する。また、デバッグ用のロジックを含めた回路が、単一のFPGAに実装できないほど大きい場合、限界に突き当たる。回路の分割という作業は複雑だし、FPGA間の信号の多重化が必要となる場合が多く、動作周波数が低下してしまうからだ。

　しかしながら、そうした最新のエミュレーションシステムでは、テストベンチ/データをFPGAを用いたエミュレーション環境とシミュレーション環境との間でやり取りできるよう、ソフトウエアによるサポートが提供されている。例えばEVE社は、同社のエミュレーション環境にアサーションをインポートする方法の開発に取り組んでいると報告している。こうした利点は、過去にはなかったものだ。

　GateRocket社のシステムは、この分野において特に興味深いものである。同社のシステムは、シミュレーションアクセラレータであると位置付けることができる。ユーザーのシミュレーション環境に容易に統合可能で、その環境の機能に影響を与えることがなく、RTLで記述したロジックにおいてシミュレーション時間のかかる部分の加速化を図ることができるという。これによって、従来は現実的には不可能であった、シミュレーション検証の先のステップでも、シミュレーション環境を使用し続けることができるであろう。さらに、GateRocket社は、このシステムでアサーションをサポートすることも表明している。