ロジック検証のゴールはどこに？：各種カバレッジ手法の活用で正解に近づく（2/3 ページ）

[Ron Wilson，EDN]

FPGAが進化を促す

　アサーションカバレッジメトリクスを生成するプロセスを進化させた大きな要因の1つが、SystemVerilog環境においてロジック検証向けのFPGAを利用できるようになったことである。新しいツールを使えば、検証エンジニアが制約条件付きのランダムスティミュラスパターンを生成すると、カバレッジポイントをどこまで網羅しているのかを確認することができる。Altera社のFox氏によると、「FPGAを使えば、設計とアサーションを合成して、リアルタイム、もしくはほぼリアルタイムでのテストを実行することができる。FPGAの存在が、このプロセスを著しく進化させた」のだという。FPGAを使う手法では、制約条件付きランダムテストを、既知のコーナーケース（Corner Case：めったに発生しない厄介なケース）のみならず、未知のコーナーケースも含めてより幅広く作成することができる。

　また、FPGAを使用すると、物理的なトランザクションレベルのカバレッジ検証も可能となる。検証エンジニアは、正常に動作することを確認済みの外部デバイスにFPGAを接続し、そのトランザクションを観察するだけで、インターフェースの動作などをチェックすることができる。インターフェースが、ほかのデバイスとともに正常に動作すれば、100％の検証カバレッジを達成できたという判断が行える。

形式的検証ツール

　コードカバレッジ、機能カバレッジ、アサーションカバレッジなどの各種メトリクスにより、検証がどこまで完了したかを示す指標が多く得られることになる。その一方で、100％の回答が得られるメトリクスも存在しない。そこで、シミュレーションベースの手法を補助するものとして、形式的検証（Formal Method）ツールを利用する設計チームが増加している。この種のツールには、それぞれ独自のメトリクスが導入されている。

　Alcatel-Lucent社のSahm氏は、「最も重要なモジュールに対しては、形式的なプロパティ（Property）チェックツールを使用している。この手法では、プロパティカバレッジという概念が用いられる。実際には、われわれが使用しているツールは独自の完全性チェック機能を内蔵しており、プロパティカバレッジや、あるシナリオにおいて各出力の状態が決定しているか否かといったことを測定できる」と語る。

　形式的検証ツールによる検証を終えると、指定した各プロパティに対し、適合していないすべての条件が洗い出される。理屈上は、100％のカバレッジが保証されることになる。ただし、プロパティの集合が設計意図をどの程度カバーしているのかを判断する必要がある。そしてこの判断を下せるのは、スキルを有した設計技術者だけなのである。形式的検証ツールの導入は、その習得が非常に困難であることを考えると、設計技術者の負担をさらに増やすことにもなりかねない。

メトリクスデータの統合

　ここまで述べてきたように、検証カバレッジに関する完全な正解は存在しない。それぞれのツールは、RTLコードのうちのどの程度をたどり終えたのか、設計/検証チームが記述したアサーションをどの程度チェックしたのか、または形式的検証の専門家が定義したプロパティをどの程度証明したのかといったことを示してくれる。しかし、「理解」や「作成」といった人間の判断がかかわるプロセスによって、各メトリクスが設計意図から逸脱してしまう恐れがある。そのため、多くの設計マネジャは、いくつかの手法によって得られた多くのカバレッジメトリクスを統合することにより、検証の進捗状況をできる限り把握しようとしている。

　Mentor社のFoster氏は、「カバレッジデータを1つに統合する方法は、設計チームによりさまざまだ。CPU担当者は、機能カバレッジメトリクスだけを使用することが多いが、彼らにはそれだけでうまく乗り切ることを可能にするリソースがある。逆にリソースがないことが理由で、コードカバレッジのみを使用する設計チームもある」と述べる。

　Foster氏が提案するのは、機能カバレッジメトリクスを最初の目標にする手法である。そして、機能カバレッジが100％に近づいた時点で、完全性を確認するための手段としてコードカバレッジを併用するのである。Altera社のFox氏も指摘するように、この手法では、機能カバレッジにおける“穴”を特定することができる。あるコードブロックが実行されない場合、そのブロックはデッドコード（本質的に不要なコード）なのか（これについては、設計チームが調査すれば本当にそうなのか否かを確認することができる）、一部の機能がテストされていないかのいずれかである。「その時点でダイレクトテストを作成するのだ」（Fox氏）。

　Fox氏は、「異なる手法で得られるデータを収集することが重要だ」と強調する。「例えば、われわれは最近、あるインターフェースIP（Intellectual Property）ブロックの検証を行った。3社から検証用IPを購入し、2つの社内チームを検証プロセスに投入した。それらすべてのデータを突き合わせたところ、それぞれの手法に何らかの見落としがあることが判明した」と述べる。