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

検証完了の判断基準とは？

　Fox氏の経験からも、どうなったら検証が完了したと判断すればよいのかという疑問が生じる。「検証は決して完了しない」などという皮肉屋もいるだろう。人によっては、開発の予定期間をオーバーしたときが、検証の完了時期だと答えるかもしれない。現実主義者の意見はさらに興味深い。「検証は決して完了することはない。しかし、商業的な成功を収めるために必要な機能に対して、ある一定の自信を得るための検証を完了することならできる。つまりは、リスク管理の問題だ」とSynopsys社のBergeron氏は語る。

　「経験豊富な設計マネジャは、さまざまな手法で得たカバレッジメトリクスを参照する」というのがBergeron氏とFoster氏の共通見解である。そして、この作業を支援するためのツールがいくつも市販されている。そうしたツールは、さまざまなメトリクスを、構造上のブロックまたは機能ごとに整理して、検証エンジニアが、設計のある部分に対するすべてのメトリクスを参照できるようにしてくれる。

　また、メトリクスの統合作業を容易にすることを目的とした活動も行われている（別掲記事『相互運用性を保証するUCIS』を参照）。各種メトリクスの統合で矛盾が検出されたとしたら、検証プランに穴が存在することになり、手作業でダイレクトテストを作成して、その穴をふさぐ必要がある。

　設計マネジャは、バグ報告の頻度にも着目する必要がある。カバレッジメトリクスの値が100％に近づくに連れて、バグ報告の頻度が減少するならば、すべてがうまくいっている。バグ検出の頻度が一定であるか、むしろ増加しているとしたなら、何らかの問題があることになる。

　繰り返しの問いかけになるが、検証はいつ終えればよいのだろうか。これについては、「クリティカルなブロックに対して実質的に確信を得た時点で検証を終えるとよい」という意見に多くのマネジャが同意している。ここで問題になるのは、クリティカルなブロックとはどこなのかということである。これについて、Sahm氏は「まったく新しい機能を含むブロック、ソフトウエアで容易に問題を回避することのできないブロック、設計者が経験を積んでない分野のブロックのことだ」と定義する。

　また、Foster氏は「設計におけるリスクを、後々、容易に修正可能なブロックにとどめるために、カバレッジメトリクスを利用するという考え方がある。この戦略は非常に合理的だ。そのブロックには、ソフトウエアによる明白な回避策が存在する可能性がある。われわれは、かつてIC上に配置するダミーの論理ゲートを『happy gate』と呼んでいたが、これを利用して、金属配線層を少し変更するだけでそのブロックにパッチを当てることができるかもしれない。あるいは、そのブロックに新しいアルゴリズムが実装されていたとして、それが機能しないようオフにするだけで問題を回避できるケースもあり得る」とも語っている。

　同氏の結論は次のようなものだ。「カバレッジメトリクスによって、検証がいつ終了するかを正確に判断することはできない。しかし、カバレッジ曲線を観察することはできる。100％にわずかに足りないところでそれ以上先に進まないならば、戦略を変更すればよい。カバレッジに大きな穴が存在するならば、そこを集中的に検証すればよい。小さな穴が多く存在するならば、戦略を根本的に変更する必要があるかもしれない。その遍在する穴に対しては、形式的検証や特殊なテストベンチを試すとよいかもしれない。その時点での状況とその後の方向性を判断するために、メトリクスは利用されるべきだ」。

相互運用性を保証するUCIS

図A　UCISが提供する相互運用性のイメージ　さまざまなツールから得られるカバレッジデータを、さまざまなクライアントで利用できるようになる。

Harry Foster　Mentor Graphics社

　現在、一般的に用いられている検証フローでは、さまざまな方式のシミュレーションから、形式的検証、そしてエミュレーションに至るまで、多種多様な検証ツールが利用されている。いずれのツールも、それぞれに異なるカバレッジメトリクスを生成する。それらを参照することで、設計の妥当性を評価したり、対応すべき課題を特定したりすることができる。

　今日のフローには、多くの問題点がある。その1つが、検証プロセスにかかわるさまざまなツールが生成するカバレッジメトリクスについて、相互に関連性がなかったり、重複している部分があったりする可能性があることだ。さらに、各ツールはベンダー固有の形式でカバレッジメトリクスのデータを生成する。それらの多種多様なデータを管理/解析する作業は、非常に優秀なプロジェクトチームにとっても悪夢となり得る。

　米国のEDAの標準化団体であるAccelleraは、複数のツールを用いたヘテロジニアスな検証フローにおいて、カバレッジ結果を収集/統合/解釈する場合の相互運用性を保証するために、UCIS（Unified Coverage Interoperability Standard）を策定した（図A）。今後登場するAccelleraのUCIS API（Application Programming Interface）仕様に準拠することにより、複数の検証ツールからUCDB（Unified Coverage Database）上のカバレッジデータにアクセスできるようになる。UCDBは、すべてのカバレッジデータを格納した単一のリポジトリとして機能する。