さて、現在ほとんどの場合、内製の検証環境が使われていると思いますので、まずはその場合の作業フローを見てみましょう。検証を一言で言っても、設計と同様に色々な工程があります。通常は詳細設計がある程度進んだ段階から、検証計画を立てて、検証仕様書を作成します。それからできるだけRTLのリリースと同時に、検証環境とある程度のテストケース作成を終わらせて、設計からシームレスに（実際はどうしても遅延はありますが）検証に移行します。基本的な機能やタイミングに対して検証が終わった後、イレギュラーなケースや異常時の動作について確認を行い、最後にカバレッジなどを集計と分析した後、やっと検証が完了となります。これらを図に書くと、下記のような流れになります。

上記検証環境作成にも時間はかかりますが、でもやっと時間をかけて作り上げた検証環境に実は色々と落とし穴があります。まず、回路をテストするための検証環境（テストベンチやモデルなど）は本質的に回路と一緒で、エンジニアによる設計と実装が必要です。人間が設計するものには常にバグがある可能性があり、検証環境もしかり。つまり、内製の検証環境でまだ実績のない状態ですと、それを使って回路のデバッグを行う前に、検証環境自体に対するデバッグが必要になるわけです。この作業が抜ける、或いは十分に行わないと、回路の検証は十分にできるはずがありません。

次に、通常はテストプランに沿って、テストシナリオを書いて検証を行っていきますが、プロトコルに対する理解不足のため、必要なテストが漏れたり、或いは逆にある機能に対して過度にテストをしたりすることも十分に考えられます。さらに、十分な検証と容易なデバッグのために、制約付きランダムやエラー挿入の仕組み、それに豊富なレポート機能が検証環境において、非常に重要な要素になります。しかし、検証環境を内製する場合、どうしても回路を動かすことだけに集中してしまいます。テストベンチとモデルを作り終えると、何となく環境構築が終了したから、さあテストシナリオを実行するぞ、という雰囲気になったりしませんか。

上記で述べた3点、
―検証環境自体のデバッグが必要
―理解不足による検証の過不足発生
―不十分な検証環境
は十分な対策が必要で避けるべきだと誰しもがわかっていることですが、現場ではタイトなスケジュールやマネージメント層の検証に対する認識不足などで、どうしても発生してしまうことでもあります。では、それらのことを一挙に解決できる方法はないでしょうか。

ここで、Avery社のVIPが登場するわけです。

ここで少しAvery社とそのVIP製品について紹介します。同社は1999年にアメリカのマサチューセッツ州で設立され、2003年からVIPの開発と販売を始めました。約60名いる全従業員のうち、55人が技術者で、なんと社長も現役で研究開発に携わっています。技術集団である同社は現在50以上のプロトコルに対応する製品を持ち、世界60社以上で実績があります。特に同社が得意とするPCIe向けVIPやNVMe向けVIPにおいては、北米の殆どのIPベンダーが同社のVIP製品を採用しています。また、日本のユーザーにとってうれしいのは、同社R&Dは台湾にあり、技術サポートはほぼ時差なしで受けることができ、場合によっては出張してオンサイトで対応してもらうことも可能です。

では、Avery社のVIPを使う場合、検証はどうなるのでしょうか。
図で書くと下記になります。

まず、VIPにテストベンチが含まれているので、当然新たな工数をかけて構築する必要はありません。しかも同社VIPは複数の実績があり、検証環境自体のバグによる工数増の心配も殆どありません。

次に、同社コンプライアンステストスイートを使えば、検証担当者の理解度によらず、規格準拠に対する確認を行うことができ、個人の理解度による検証の過不足を避けることができます。同社は各規格団体と密な関係を保ち、新しい規格に対していち早く対応することや、包括的な規格準拠テストを提供することを強みとしています。さらに、同社VIPは完全にSystemVerilogとUVMで構築され、チェッカー、スコアボード、モニタ、カバレッジなどデバッグに必要な仕組みが豊富に用意されています。特筆にすべき点は、同社VIPに制約ランダム検証や様々なレベルでのエラー挿入ができるため、内製の検証環境でなかなかできない「重箱の隅をつつく」ような検証が容易にできることです。また、詳細な実行レポートはもちろん、規格によって性能に関するレポートも含まれます。

最後になりますが、Avery社のVIPを使う場合、ライセンスを購入する必要があります。そのため、どうしても目に付くのはコスト面であり、これが内製の検証環境と比較されるポイントになります。しかし、コストには見えるものと見えないものがあり、VIP購入のコストが見えるコストですが、それに対して、環境構築に必要な工数、検証環境由来のバグ解析の工数、検証不足によるバグ混入のリスク、そのために期限までにテープアウトできない場合の機会損失などなど。これらは見えないコストとして、内製の検証環境を使う場合に存在します。どちらが大きいかは自明ではないでしょうか。目で見える少ないコストをかけて、目に見えないより大きなコストを避けることは賢明な判断ではないでしょうか。

Avery社製品の検証IPが気になる方はこちら⇒Avery Design Systems Inc.