機能検証世界の著名人であるHarry Foster氏(米Mentor Graphics Corp., Design Verification Technology Division, Chief Verification Scientist)に話を聞いた。同氏はメンター・グラフィックス・ジャパンが大阪と東京で催したプライベート・セミナ「検証プロセスのパフォーマンスを上げる戦略と戦術」などのために,今回,来日した。

問:LSI開発の中で機能検証が最も工数がかかるという話を聞くようになってから久しい。MentorをはじめとしたEDAベンダーが各種の機能検証向けツールを市場に投入しているにもかかわらず,なぜ,機能検証はいまでも「最も工数のかかる工程」のままなのか。

Harry Foster氏 Tech\-On!が撮影。Intelligent Testbench Automation(ITA)のポイントを説明中。
Harry Foster氏
Tech-On!が撮影。Intelligent Testbench Automation(ITA)のポイントを説明中。
[画像のクリックで拡大表示]
図1●Verification Academyのトップページ Mentorのデータ。
図1●Verification Academyのトップページ
Mentorのデータ。
[画像のクリックで拡大表示]
図2●Intelligent Testbench Automation(ITA)を使って,シミュレーション・パターン数を最小化してから論理シミュレーションを実施 Mentorのデータ。
図2●Intelligent Testbench Automation(ITA)を使って,シミュレーション・パターン数を最小化してから論理シミュレーションを実施
Mentorのデータ。
[画像のクリックで拡大表示]

 複数の理由がある。まず,いわゆるMooreの法則に沿って,半導体の微細化は順調に進み,チップ上に集積できる素子(トランジスタ)数は2~3年で2倍になっていることが挙げられる。設計に関してはIPコアの採用によって,工数はそれほど増えないが,検証の工数は素子が増えると,最悪の場合は指数関数的に増える。

 この検証対象が大規模で複雑になることに加えて,エンジニア全体が保守的という課題もある。指摘されたように,EDAベンダーは新しい検証手法を提案してきた。具体的にはアサーション・ベースの検証手法,フォーマル・ベリファイア,制約付きランダム・シミュレーション・パターン生成+カバレッジ・ドリブン検証手法などである。しかし,残念ながら,機能検証手法としては,未だに「人手で作ったシミュレーション・パターンと論理シミュレータを使う」のが主流のままだ。

 2007年に行われたある調査によれば,RTLの論理シミュレーションを採用している比率は67%あったが,機能カバレッジは40%,アサーションは37%にとどまっている。こうした新しい検証手法は,「人手で作ったシミュレーション・パターンと論理シミュレータを使う」伝統的な手法に比べて難しいという課題もある。例えば,制約付きランダム・パターンをうまく発生させるのはそれほど簡単ではない。

 新しい検証手法の取得を支援しようと,1年ほど前に「Verification Academy」というWEBサイトを立ち上げた(当時の日本語版ニュース・リリース)。このサイトでは,24時間いつでも新しい検証手法についてビデオなどで学べるようになっている(図1)。メンター・グラフィックス・ジャパンでは,コンテンツの日本語化を進めているので,日本の方にも容易に利用してもらえると考えている。

同じ検証を繰り返さない

問:アサーション・ベースの手法や,フォーマル・ベリファイア,制約付きランダム・シミュレーション・パターン生成+カバレッジ・ドリブンの手法をVerification Academyで取得できれば,機能検証の問題をクリアできるのか?

 先ほど述べたように,Mooreの法則はまだまだ続く,アサーション,フォーマル・ベリファイア,制約付きランダム,カバレッジなどは必須だが,それだけでは十分ではない。そこで,われわれが提案するのが,今回のセミナーのタイトルになっている「検証プロセスのパフォーマンスを上げる」ことである。検証プロセスのパフォーマンスを上げるとは,検証の効率を高めることを意味する。それには三つの技術が重要になる。すなわち,(1)Intelligent Testbench Automation(ITA),(2)フォーマル・ベリファイア,(3)TLM(transaction level modeling)である。

 特にITAが重要だ。この技術の目的は,同じ検証を2度行なわないことで,検証の効率を高めることである。具体的には,ダブりの少ないテスト・シーケンスを定義する(図2)。そのためのツールとして,我々は「inFact」を提供している(Tech-On!関連記事1)。inFactでは,ユーザーはテストベンチの基本情報(シナリオ)をC言語などで定義する。inFactがこのシナリオをグラフ(グラフ理論のグラフ)に変換し,グラフ上の全ノードをカバーする最小のパスのセットを見つける。各パスがテスト・シーケンスに相当する。

 この最小のテスト・シーケンスからシミュレーション・パターンを生成することで,最小数のシミュレーション・パターンで検証を実行できる。ある例では,通常の手法で生成したシミュレーション・パターン数の1/4に削減できた上にカバレッジも上昇した。別の例では,シミュレーション・パターン数が1/5に,シミュレーション・パターンの開発期間が1/6に,それでいてバグ発見数は4倍になった。