ASIC/SoC開発において、現場の設計者や検証エンジニアの誰しもがお気楽ではいられない難題が、「一体どこまで検証を行えばバグが出尽くしたと言えるのか」「いつになれば確信を持ってテープアウト（試作提出）できるのか」という、終わりの見えない検証の泥沼です。

LSI開発における全工数の「7割」を占めると言われる検証工程ですが、世の中の多くの現場では、明確な完了基準もないまま「ただ祈るようにシミュレーションを回し続ける」という非効率な作業や、否応なく迫りくる逃れられないタイムリミットという理不尽が今なお繰り返されています。

SystemVerilogの標準化以降、業界にはVMM（Verification Methodology Manual）やAVM（Advanced Verification Methodology）、さらにはOVM（Open Verification Methodology）、そして今日のUVM（Universal Verification Methodology）に至るまで、数々の「検証メソドロジー」と呼ばれる技術が流入してきました。

しかし、これらの最新ツールやライブラリを導入したからといって、現場の検証がお気楽になったでしょうか？

PVMを提唱して以来、大手海外IT/EDA企業との共同開発でも圧倒的な成果を上げてきた検証メソドロジー「 PVM（Proclaimed Verification Methodology） 」 について、お話ししたいと思います。

「VMAT」の衝撃と、PVM誕生の裏舞台

2000年代半ば、SystemVerilogの普及とともに、大手EDAベンダーからVMMやAVMといった検証メソドロジーが相次いで発表されました。ランダム検証やアサーション、機能カバレッジといった目新しい概念に、当時の先進的なエンジニアたちは飛びついたものです。

しかし、その中身を紐解いてみれば、それらは「検証の考え方（メソドロジー）」などではなく、単にSystemVerilogのテクニックをオブジェクト指向のクラスライブラリとしてまとめ上げた「実装ツール」にすぎませんでした。

C++の複雑なクラスライブラリと同様、難解なオブジェクト指向のお作法を理解しなければ使いこなせず、当時は分かりやすい解説本すら存在しない状態でした。その結果、現場では「クラスライブラリの理解やDUTへの適応作業」に膨大な工数を奪われ、肝心の「回路の中身をどう検証すべきか」という本質がおざなりになるという、本末転倒の事態まで起きていたのです。

「世間の検証エンジニアたちは、本当に検証の本質を理解して作業しているのだろうか？」

そう疑問を抱いた私は2007年4月、自社で検証業務を委託するパートナー企業を選定するための実技試験として、「 VMAT（Verification Management Ability Test） 」 と名付けた独自の選考課題（全５問）を作成し、検証専業を謳うプロフェッショナル企業約10社に受験していただきました。

そのVMATの中で、私が最も配点ウェイトを高く設定したのが、以下の本質的な設問でした。

> 問3：以下2つの問いかけを意識し、成果物とその考え方を説明してください。

> a) DUT（検証対象回路）の動作は、これで本当に正しいと言えるのか？

> b) あなたが行っている検証作業は、一体いつ終了するのか？

試験の結果は、私にとっても衝撃的なものでした。「当社は検証のプロです」と豪語して臨んできた会社ですら、この問3に対する回答は、目も当てられないほど・・な回答だったのです。

「ツールがカバレッジ100%と言っているから」「ランダムテストを100万サイクル回してエラーが出なかったから」といった、ツールの出力結果に依存した表面的な答えに終始し「何をどこまで検証空間として定義し、どのような根拠を持って終了とみなすのか」という、肝心な検証思想（戦略）が完全に欠落していたのです。

「VMMやAVMといったクラスライブラリの呪縛に縛られている限り、現場は永遠に検証の泥沼から抜け出せない」

そう痛感した私は、既存のベンダーお仕着せ手法を一蹴し、開発のスタート時に自らが「検証の終わり」を高らかに宣言する検証思想 「 PVM（Proclaimed Verification Methodology）」 を構築・提唱するに至ったのです。

PVMの本質：最初に「検証仕様」を宣言せよ

PVM（Proclaimed Verification Methodology）の根本思想は極めてシンプルです。「Proclaimed」という単語が示す通り、「 開発の初期段階（設計スタート時）において、『検証の終わり（ゴール）』を明確に宣言し、その宣言通りに検証空間を塗り潰していくメソドロジー 」 です。

誤解のないように言っておきますが、私はSystemVerilogやUVMといった技術やクラスライブラリそのものを否定しているわけではありません。それらはテストベンチを効率よく構築するための「便利なドライバー（工具）」としては非常に優秀です。

定型通りにUVMのサンプル事例があてはまる回路なら、見た目もカッコいいテストベンチは非常に有用ですが、私はランダム検証でさえもDPI-Cのフル活用をお勧めしています。SystemVerilogで標準化されたアサーションとカバレッジさえあれば、誰かが作り込んだ複雑なお作法の塊であるクラスライブラリを使いこなさなければならない呪縛から解放されエンジニアの自由な発想だけで検証ベンチを構築できるからです。

しかし、どれほど高級な工具を買い揃えたところで、「どんな家を建てるのか」という設計図（建築仕様書）がなければ家は建ちません。検証における設計図こそが 「 検証仕様書 」 であり、VMMやUVMが教えてくれないのは、まさにこの「検証仕様をいかに合理的に策定するか」という一番肝心な思考プロセスなのです。

PVMでは、コードを書き始める前に、まず人（設計者および検証者）の頭で検証空間を整理し、後述する「3つの要求仕様項目（PVM1, PVM2, PVM3）」として宣言します。

そして、テストベンチの実装とシミュレーション実行を通じて、宣言した内容が100%完了したことを数値（機能カバレッジ等）で「見える化」します。あらかじめ自ら宣言したゴールに到達した瞬間こそが、一切の迷いも祈りも必要としない、自信に満ちた「検証の終わり＝テープアウトの瞬間」となるのです。

なぜ「検証」ではなく「開発」のスタート時なのか？

タイトルにもある通り、PVMは「検証」のスタート時ではなく、あくまで「開発」のスタート時に適用することに極めて重大な意味と狙いがあります。

第一に、「ブラックボックス検証 vs ホワイトボックス検証」のバランス問題です。DUTの内部構造を知り尽くしたホワイトボックス検証は、検証空間を極限まで絞り込めるという絶大なメリットがあります。しかし、実際の開発現場ではリソースの制約上、設計者と検証者を完全に分離できないケースも少なくありません。設計者自身が検証を兼任した場合、ホワイトボックスの悪癖として「自分が完璧に設計したと思い込んでいる箇所」のバグを無意識にスルーしてしまうという致命的な見落とし（バイアス）が発生するリスクがあります。

第二に、私の設計ポリシーの根幹でもある「そもそも検証する必要がない（検証空間が極めて小さい）設計こそが理想である」という設計思想です。

頭の切れる優秀なエンジニアほど、一見すると見事なスパゲッティ状の複雑なRTL回路を組んでしまい、結果として検証空間を天文学的に爆発させて泥沼にハマる事例を数多く見てきました。真に優れたアプローチとは、検証空間が自然と小さくなるような「単純でシンプルな機能ブロック」の組み合わせで複雑な機能を実現することです。複雑な動的制御や組み合わせ処理は、回路のオマケとして忍ばせた自作CPU（MyCPU）等のソフトウェア側に委ねてしまえば（CPUライク設計）、ハードウェアとして検証すべき空間（PVM3）が爆発することなど最初から起こり得ないのです。

だからこそ、RTLコードを書き始める前の「開発スタート時（最初の設計構想レビューの段階）」において、ホワイトボックス検証の利点を活かしながら、設計者と検証者の間でPVM1（検証スコープと割り切り事項）の合意形成を完璧に行うことが絶対に不可欠なのです。

PVM要求仕様書作成における3大ピラー（PVM1, PVM2, PVM3）

PVMを現場に導入するにあたり、私たちは検証要求仕様書の中に以下の「3つの宣言項目」を定義します。

① PVM1：検証スコープ（検証空間）の定義

PVM1では、対象とするIPやDUTの検証戦略を、「 10項目以内 」 の簡潔な箇条書きで要約・宣言します。だらだらと長文の仕様書を書くのではなく、ポイントを極限まで絞り込むことで、検証空間の全体像（スコープ）を明確に定義するのです。

PVM1において特に重要となるのが、以下の要素の整理と宣言です。

  • RTL考察と検証範囲
    • RTLの構造を検証視点から冷静に分析し、エラー系や不正規プロトコル、網羅検証が絶対に必須となる重要箇所を洗い出します。
  • アサーションおよびテストベンチ実装方針
    • RTL内部やインターフェース部に埋め込むプロパティ（SVA）の指針、およびリファレンスモデル（C言語等）を用いる場合の「そのモデルの正しさ」を担保する方針を定めます。
  • 割り切り事項（境界条件）の明示：
    • これがPVM1における最大のキモです。「今回の検証では、物理的に実現不可能な組み合わせや、システム上発生し得ないコーナーケースはあらかじめ検証対象から除外する」という 「割り切り事項 」 予め明示的に宣言します。

「何もかも完璧に検証する」などという幻想を捨て、責任を持って割り切り事項を宣言するからこそ、無限のカバレッジ追及という泥沼から脱出できるのです。

② PVM2：検証Feature（構成要素）の抽出

PVM2では、PVM1で定義した検証空間を構成する具象的な要素 —— 「 検証Feature（機能要素） 」 を抽出します。検証Featureとは、検証項目の最小単位であり、多くの場合、動的なパラメータ（値の範囲）を伴います。

PVM2では、検証Featureを以下の「4つの観点」から漏れなく重複なく（MECEに）分類・抽出します。

  • Input Feature（$FI$）：入力スティミュラスや対向モデルなど、DUTの外側から印加される検証要素。
  • Target Feature（$FT$）：DUTの内部状態（ステートマシンの状態や内部バッファの閾値など）に関する検証要素。
  • Corner Feature（$FC$）：異常系やプロトコル違反、バッファフル時のアクセスといったコーナーケース（設計者の知見に基づくホワイトボックス検証要素）。
  • Expect Feature（$EX$）：DUTが出力すべき期待値やチェックプロパティ。

抽出したFeatureに対して、そのパラメータ範囲を明確にし、SystemVerilogの `covergroup` や `property` と1対1で対応するように定義していきます。

また、実装コードに合わせてbinsやProperty記述も追加するように設計を進めれば、パラメータ範囲の変更時にも瞬時に追従できるようになります。

③ PVM3：検証Functionの作成とカバレッジによる「見える化」

PVM3では、PVM2で抽出した検証Featureを組み合わせ、DUTが提供すべき具体的な機能のリスト —— 「 検証Function 」 を作成します。

理想を言えば、すべての検証Featureの組み合わせ（クロス積）を100%検証できれば完璧です。しかし、モジュールの規模が大きくなればなるほど、Featureの組み合わせ爆発が起き、愚直な網羅検証は物理的に不可能な時間領域へと突入します。

そこでPVM3では、PVM1の戦略に基づき、「 システムとして合理的に意味のあるFeatureの組み合わせ 」 を厳選して検証Functionとして定義・宣言します。

この検証Functionごとに `coverpoint` や `cross` カバレッジを割り当て、シミュレーションの実行とともに進捗率（%）を数値化します。宣言した検証Functionのカバレッジが100%に達したとき、それがすなわち「PVMで宣言された検証空間の完全制覇」を意味し、客観的・数値的に検証完了が証明されるのです。

まとめ：検証をお気楽にして「一発完動」を手に入れよう！

あらかじめ「検証の終わり」を定義・宣言し、ゴールを手元に引き寄せてから走り出すPVM（Proclaimed Verification Methodology）の思想。

かつて私が構築したこのPVMの手法は、当時関わっていた超有名海外企業にも検証委託プロジェクトを通じて輸出されました。今も私の知らないところで、形を変えながら現代の最先端検証現場において脈々と継承され、進化し続けているはずです。

LSI開発の工数の7割を占める検証作業だからこそ、終わりの見えない恐怖におびえながら祈るように作業するのではなく、理詰めの戦略と数値管理によって、最高に「お気楽」でスマートなプロセスへと変革しなければなりません。30年のキャリアの中で「私のコード」にバグを寄せ付けない圧倒的な品質の裏には、こうした明確な設計・検証思想とそのカラクリが存在していたのです。

検証戦略にお悩みの設計者・検証リーダーの皆様。Myoken Researchでは、PVMの生みの親である私自身が直接、貴社のプロジェクトに合わせた「お気楽PVM検証環境」の構築をサポートさせていただきます。VMATやPVMのサンプル記述など、詳細な技術情報に関しましては、以下のリンク先からどうぞお気軽にお問い合わせ・リクエストをお寄せください。お気楽で、強くて、確信に満ちたASIC検証の未来を、一緒に切り拓きましょう！

参考文献・リンク