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

[Ron Wilson，EDN]

設計マネジャが抱く3つの疑問

　「現在、多くの設計マネジャは、3つの重要な疑問に対する答えを得るために、検証カバレッジ（Verification Coverage）のメトリクス（Metrics：定義された検証法から導き出される尺度）を利用している」──米Mentor Graphics社の主席検証サイエンティストを務めるHarry Foster氏の言葉である。ここでいう3つの疑問とは、最終的な開発目標に対して、「どこまで進んでいるのか」、「今はどこに向かっているのか」、「いつゴールに到達するのか」というものである。

　ICに実装するロジック設計が完了したら、正しく設計が行われていることを検証する必要がある。しかし、多種多様な検証ツールからさまざまなカバレッジに関するメトリクスが得られる上に、それぞれが異なる意味を持つなど、メトリクスに関する情報は氾濫している状態にある。このため、設計マネジャは、それらのメトリクスが示す本当の意味を理解するとともに、複数のメトリクスを、Foster氏が挙げる3つの疑問に対する答えが得られるよう1つに統合する必要がある。

　「いつゴールに到達するのか」という疑問は、「いつになったら検証を終了してもよいのか」という問いかけに言い換えることができる。最も重要なのは、これに対する正しい答えを得ることである。この判断を下すためには、メトリクスを統合する以外に、アーキテクチャ設計が最初に行われたころから存在し、それ以降、設計技術の進化とともに拡大/確立されてきた詳細な検証プランが必要となる。

コードカバレッジの欠点

　現在、回路設計に携わる技術者は、ソフトウエアを検証する際に用いられる「コードカバレッジ」の手法をそのまま拝借している。この概念は、単純明快なものだ。まず、RTL（レジスタ転送レベル）シミュレーションを実行する際に、RTLソースの各コード行に対応する1ビット幅のテーブルを用意しておく。そして、シミュレーションを開始するときに、テーブルのビットをすべて0に初期化する。その上で、各行が最初に実行されたときに、その行に対応するテーブルのビットを1にする。シミュレーションを終えたときには、すべてのコードのうちどの行が実行され、どの行が実行されなかったのかがわかるという仕組みだ。基本的には、実行されていない行は検証が済んでいないと見なすことになる。

　専門家は、コードカバレッジの考え方を一般化し、RTLビューに基づくほかの多くのカバレッジ測定手法へと展開を図っている。この手法を利用すれば、RTLコード中の式や分岐の検証、あるいはレジスタのトグルのカバレッジをレポートするツールを開発することができる。また、そうしたレポートのほとんどは、市販のシミュレーションツールを使って、特別なモニタリングを行うことなく得ることができる。

　コードカバレッジメトリクスは、何年も前に登場し、簡単に使用できることもあって広く普及した。「当社の調査によれば、設計チームの約半数が、検証フローのどこかでコードカバレッジメトリクスを使用している」とFoster氏は語る。

　しかし、コードカバレッジには重大な問題が存在する。米Synopsys社フェローのJanick Bergeron氏によると、最大の問題は「カバレッジメトリクスは確かに有効だが、どこまで検証をカバーできているのかを判断するには十分ではない」ことだという。すなわち、RTLコードのある行を実行したからといって、意図したとおりに動作したとは限らないのである。

　より正確に言うと、問題になるのは、観測可能性と完全性に関することである。コード行を実行したとき、その結果はそのシミュレーション実行時に実際に観測していたノードへと引き渡されているのだろうか。もし、引き渡されていないとすれば、コードが意図したとおりに動作したかどうかを判断できない。これが観測可能性の問題である。Foster氏は「行カバレッジが100％でも、シミュレーション中に実際に動作を確認できたのは行全体のわずか70％だ

ったというケースもある」と例を挙げる。

　一方の完全性は、これとはまた別の問題である。先述したテーブル上でコード行を実行したという結果が得られたとしよう。しかし、この手法では、そのコード行が実行される可能性があるすべてのケースに対して実行されたかどうかは確認できない。何らかの問題が発生するケースが1つも存在しないということまでは確認できないのである。

機能カバレッジにも課題あり

　コードカバレッジには欠点があることから、機能カバレッジを用いる設計チームが多い。機能カバレッジは、設計した機能のうち、いくつの機能が意図したとおりの動作を行ったのかを確認して示すというものだ。この手法は、設計マネジャらが、回路検証のために用いた最初の手段であり、現在でも多くの設計チームにとって心のよりどころとなっている。

　フランスAlcatel-Lucent社の光部門でハードウエア研究開発担当技術マネジャを務めるHans Sahm氏は、自社で採用している機能カバレッジメトリクスの最新の手法について、以下のように説明した。

　「まず、要件（requirements）仕様書を基に、社内で開発したスクリプトを用いて検証プランのスプレッドシートを作成する。そのスプレッドシートには、自然言語（英語）で記述された機能要件と、各要件を検証するために検証チームが選択したテストケースが列挙される。なお、このスプレッドシートは、検証チームがシミュレーションの進行に応じて完了したテストケースに印を付けていくための単一のドキュメントとなる。また、検証の進捗を機能ごとに示したチャートとしても利用する」。

　この概念は、すべての形式における機能カバレッジメトリクスの中枢となるものだが、大きな課題をいくつか抱えている。Sahm氏は、「機能要件とそれを検証するために必要となるテストケースは、自動的に関連付けられるものではない」と指摘する。要件を理解し、その要件を適切にカバーするテストケースを用意できるかどうかは、検証エンジニアのスキルと経験に依存するのだ。このことについて、Mentor社のFoster氏は「思考を自動化することなどできない」と語る。

　米Altera社の主席検証アーキテクトであるJeff Fox氏は、「要件仕様書を解釈する際には必ず問題が生じる。同じドキュメントを読んでも、エンジニアによって機能の動作に対する理解がまったく異なる場合があるのだ。そのため、われわれは、要件仕様書をできる限り実行可能コードに近いものとして記述している。もちろん、その記述は正確なものでなければならない」と語る。Synopsys社のBergeron氏もこれに同意する。その上で、「ある機能を検証するために、手作業で作成したテスト（ダイレクトテスト）を使うことがある。ここに1つの課題がある。すなわち、テストの結果からは、テスト自体にバグが存在しないことを証明することはできないということだ」（同氏）と語った。

アサーションで人為的ミスを回避

　上述したような人為的ミスを避けるための最も一般的な方法は、アサーション（Assertion：プログラムの形式検証における成立条件）と制約条件付きランダム（乱数）テストを使用することであった。この手法はもともと、2005年に米Cadence Design Systems社が傘下に収めたVerisity社が採用していたものである。Mentor社の調査データによると、制約条件付きランダムテストを使用しているのは検証チームの約40％ほどだという。つまり、機能カバレッジメトリクスを使用している設計チームの比率も約40％だということになる。初期のころから、アサーションを記述するための専用言語はいくつもあったが、最近ではハードウエア記述言語とハードウエア検証言語を統合した「SystemVerilog」に収束しつつあるようだ。結果として、現在では次のような新しい設計/検証手法が使われるようになってきている。つまり、SystemVerilogによってアサーションを記述し、制約条件付きランダムテストによってアサーションをテストし、アサーションのカバレッジによって検証メトリクスを表現するという手法である。

　多くの設計チームが、徐々にこのプロセスへと移行している。インドWipro Technologies社の半導体およびソリューションビジネス部門のゼネラルマネジャを務めるGiri Raju氏は、同氏の設計チームが採用している方法について、以下のように説明する。

　「以前は、相互参照テーブルを手作業で追跡することにより得られたコードカバレッジメトリクスだけを使用して、検証作業を管理していた。当時のわれわれの目標は、単純にコードカバレッジで100％を達成することであった。徐々に機能カバレッジ検証ツールを使う方向に移行したが、検証の進捗状況については、引き続きテーブルを使って手作業で確認していた。現在は、SystemVerilogと検証メソドロジのOVM（Open Verification Methodology）を利用する方向に移行中だ」。

　Raju氏は、「このような対策を進めてはいるものの、検証エンジニアには、習得しなければならないエンジニアリングスキルがまだかなりあるだろう」と語る。「検証エンジニアは、検証用のカバレッジポイントを特定し、それらを設計エンジニアとともにレビューして確認する。このプロセスの80〜90％を自動化できると信じているが、人手で実施しなければならない部分が必ず存在する。しかし、この問題については、アサーションを利用することで有効な対処が可能になる。現在では、当社の設計エンジニアにとっては、コードへのアサーションの挿入が習慣になっている」（同氏）という。