検証資産の再利用 – Verification IP（Design and Verification LANDSCAPE　2021-Vol2）

2022/01/25

Design and Verification Landscapeの2021年Vol1 ではアサーションの再利用について解説を行なった。従来から行われてきた波形の目視確認に労力を費やす代わりに、アサーションを記述することで、それ以降の検証では記述済みのアサーションを再利用し、波形を目視確認によって行われてきた検証作業が自動化される。これによってプロジェクトを重ねるごとに検証の生産性が向上することが期待される。
同じようにテストベンチも再利用することができる。ここでいうテストベンチとは、テスト生成を行い、テストカバレッジを測定し、アサーションを活用したチェッカやモニタ、リファレンスモデルなど仕様に近いモデルとの比較機能を持つスコアボードなどを備えた環境を指す。本稿では、再利用可能なテストベンチ環境の考え方や、そのための業界標準などについて解説する。

構造的なテストベンチ

アサーションはブロック間インタフェースやFIFO、アービターなどのように局所的に使用され、それが故に大規模設計の長いシミュレーションであっても、その中から、問題となる箇所がスポット的に提示される。また局所的に記述するために再利用もしやすいとうい点がある。
これに対してテストベンチは、設計によって大きく異なり、また相対的ではなく絶対的なタイミングで記述されている場合には、再利用性が困難になる。テストベンチを再利用するためにまず行わなくてはならないのは、構造化である。テストベンチを、その役割が異なる複数の構成要素に分けて構造的に構築する。構成要素に分ける際には再利用性も考慮することが重要である。構成要素間の接続やデータのやり取りもピンレベルよりも高い抽象度にすることで、さらに再利用性がしやすくなる。図1.に昔から使用されてきた構造的なテストベンチ構成例を示す。

図1. 構造的なテストベンチ例

ここで図1.のテストベンチを構成するそれぞれの構成要素の役割について説明する。

DUV

Design Under Verificationのことで検証対象のデザインを指す。DUT - Design Under Testと呼ぶこともある。

Driver

Generatorが生成したトランザクションの動作をピンレベルに変換し、DUVの振舞いに合わせてスティミュラスをドライブする

Monitor/Checker

ピンレベルの動作をトランザクションレベルに変換し、カバレッジやスコアボードに送る
アサーションを用いてイリーガルなトランザクションをチェックする

Generator

テストシナリオに基づいてトランザクションのスティミュラスを生成する
トランザクションが取り得るデータ（例：アドレスやデータ）をランダム化する

Coverage

トランザクションレベルでのカバレッジを収集する
制約付きランダム生成では何がランダム化の結果何が発生したかを観測し分析する

Scoreboard

Monitorからデータを受け取り、期待値と比較しDUVの振舞いが正しいかどうかを判断する

Test Scenario

DUVを検証するための検証シナリオを設定しGeneratorを制御する

ここでトランザクションというのは、ピンレベルよりも高い抽象度を指す。コマンドレベルと呼ばれることもある。標準的なバスに備わっているburst_writeやword_writeなどのコマンドがこれにあたる。トランザクションと、それに相当するピンレベルの動作の様子を図2.に示す。

図2. トランザクションレベルとピンレベルの比較

構造的なテストベンチの再利用と標準化

構造的なテストベンチの手法が出現したのは1990年代初頭にまでさかのぼる。e言語と呼ばれるテストベンチ専用言語を用いて実現されていた。しかしVHDLやVerilogのような標準言語ではなく、特定の企業が独占的に所有する言語だった。少し遅れてVeraやSuperLogと呼ばれるテストベンチ用言語が登場し、それぞれ独占的な言語が乱立する時代を迎えた。非営利の標準化団体であるAccelleraは、テストベンチを開発するための言語としてHVL（Hardware Verification Language）の標準化を進め、この結果SystemVerilogが誕生した。実際にはSystemVerilogは設計やDPIなどの様々な要素を含むため、のちにHDVL（Hardware Description and Verification Language）と呼ばれるようになった。

しかし言語のみを標準化しても、構造的なテストベンチ資産の再利用にはつながらない。トランザクションを表現するための記述やトランザクションレベルでテストベンチの構成要素どうしが通信できる手段や、構成要素どうしが同期するためのメカニズムなどが必要になる。このメカニズムを実現するための一連のライブラリ群が称して「メソドロジ」と呼ばれるようになった。手段であるメソッドを具現化するという意味合いからそのような言葉が使われるようになった。

SystemVerilog自体は標準化されたが、今度はSystemVerilogによる検証メソドロジが業界に乱立してしまった。Synopsys社はVMMを、Cadence社はURMを、そして当時のMentor社はAVM（Advanced Verification Methodologyを開発しリリースした。この中で異色だったのは、MentorのAVMである。AVMはオープンソースで公開され、Apache 2.0ライセンスで提供された。オープンソースの影響力は大きく、多くのユーザがAVM導入に舵を切ったタイミングでCadence社から検証メソドロジの共同開発を提案され、Mentor社とCadence社が共同でオープンソース公開のOVM（Open Verification Methodology）を開発した。自然な流れで、多くのユーザがOVMを採用するようになり、OVM準拠の検証IPなども流通するようになってきた。前出の標準化団体であるAccelleraは検証メソドロジのワーキンググループを設置し、その標準化のスタートラインとしてOVMを使用することを決定した。このタイミングでSynopsys社がRAL（Register Abstraction Layer）を寄贈し、検証メソドロジの標準化が開始された。

Accelleraはこの標準化活動の結果、2011年にUVM（Universal Verification Methodology）を標準化し、検証コンポーネントを構成するベースクラスライブラリをオープンソースでリリースした。図3に、その歴史的な背景を示す。

図3. 検証メソドロジ標準化の歴史

このように、テストベンチを構成するための検証メソドロジ、およびその土台となる言語の標準化には、業界として膨大な時間と労力が費やされている。しかし業界として１つの検証メソドロジを確立できたことの価値は、その労力の見返りとして余りある。その価値の大きな部分を占めるのが、検証IPの再利用性と、それによる流通である。それ以外にもUVMという検証メソドロジを使用する上で役立つようなEDAツール、あるいは検証IPのコンフィギュレーションツールやUVMテストベンチを自動生成するようなユーティリティも出現している。また機能検証のサービスを提供するコンサルティング企業についても、リソースを集中し、サービスの品質を向上させることができる。このようなエコシステムができることで、業界全体としての労力を最適化することができる。標準化された検証メソドロジの価値は計り知れず、そしてユーザはその多くの恩恵を享受することができる。

UVMは2011年にAccellera標準となり、UVM1.0としてリリースされた。その後は改版を重ねたが、IEEEに寄贈され、現在はIEEE Std. 1800.2-2020がUVMの最新標準となっている。図4.からは、標準化された検証メソドロジが、圧倒的に支持され使用されていることが伺える。

図4. Wilson Research Groupによる機能検証市場調査

出典：Verification Academy　Celebrating 10 years of UVM
https://verificationacademy.com/verification-horizons/march-2021-volume-17-issue-1/celebrating-10-years-of-the-uvm （参照 2021/5/31）

検証I P

検証IPはUSBやAXI、PCIeなど、標準的に規格が定まっているプロトコルの検証に対して使用する。例えばPCIeの場合、その仕様を把握するだけでも月単位の時間を要すると言われている。PCIeには異なる転送スピード、複雑なリンクトレーニングと初期化、トランザクションレイヤ、データリンクレイヤ、物理レイヤごとに異なるエラー検知とその処理方法、パワーマネジメント、下位バージョンへの互換など、膨大な仕様が含まれる。大半のプロジェクトではPCI SIGから仕様をダウンロードして自ら開発することは回避し、VIPベンダやEDAベンダから調達する選択肢を選ぶであろう。

さて検証IPに包含される最も重要な要素は、図1.に示した構造的なテストベンチにおいて、プロトコル特化の観点から切り出したコンポーネント群である。その構成およびインスタンス化の様子を図5.に指す。

図5. 検証IPの構成とインスタンス化

図5.において赤い線で囲まれた部分はプロトコルに特化したコンポーネント群であり、検証IPには欠かせない構成要素である。UVM標準においてはAgentと呼ばれる。Agentには「代理人」という意味があるが、これはテストシナリオやテスト環境から、「プロトコルに関しては任されている」という意味が込められた命名である。

Agentはプロトコルに特化しており、それを複数インスタンス化してテストベンチを構成する。その階層はEnvという環境コンポーネントであるが、通常はDUV１つに対してEnvが1つ存在する。UVM_Testはテストするシナリオを定義する階層であり、そこにはEnvがインスタンス化される。

さて、Agentにはアクティブモードとパッシブモードがある。アクティブモードではシーケンサからコマンドレベルのトランザクションを受け取り、それをピンレベルに落としてDUVへと送出する。パッシブモードではDUVにおいて観測されたピンレベルの動きをMonitorがトランザクションレベルへと変換し、カバレッジ収集やEnvレベルでの解析コンポーネントに送出される。解析コンポーネントとは例えばカバレッジコレクタ、スコアボードである。アクティブモードとパッシブモードの切替えは、検証IPに備わっているコンフィギュレーションのメカニズムによって制御する。

上記は構造的なテストベンチを構成する検証IPとしての基本的機能であるが、検証IPにはそれ以外の価値を付加しているものも多い。以下にはその例として、シーケンスシナリオ、検証プランのサポート、アサーションチェッカについて説明する。

まず検証IPにはAgentに加えて膨大なシーケンスシナリオが提供される事も多い。前出のPCIeの例では、リンクトレーニングの初期化やバス・エニュメレーション、I/Oやコンフィギュレーション、メモリアクセスの初期化、異なるスピードに対するトランザクション送出、トランザクションレイヤ／データリンクレイヤ／物理レイヤごとに異なるエラー挿入シナリオなどである。またコンフィギュレーション用パラメータもデフォルトの状態が提供されることが多く、例えばPCIeの最大ペイロードやリンクトレーニングのタイマ設定など多くのパラメータに対応する。その他、バックドアアクセスのためのAPIが提供されることもあり、より効率の良いテストシナリオの作成に活用することができる。

次に検証IP内に含まれるカバレッジコレクタには、実行されたトランザクションを測定するためにcoverpointやcovergroup、bin、crossなどの記述が含まれる。検証IPベンダ／EDAベンダは検証プランに基づいてカバレッジを記述しており、通常はExcelなどで管理している。検証IPベンダ／EDAベンダによっては、その検証プランも検証IPの一部としてExcelやCSVなどで提供するケースもある。ユーザはテストベンチ全体のカバレッジをExcelなどで管理しながら、検証IPの検証プランの部分を組み入れることで、トータルカバレッジを管理することができる。検証マネジメントツールによっては、さまざまなカバレッジデータをマージし、Excelなどもツールに読み込んで一元管理することもできる。

最後にMonitor /Checkerについて説明する。Monitorの機能はピンレベルの振舞いをトランザクションレベルに引き上げることにあるが、ピンレベルの振舞いに対してアサーション記述によるチェックを行う機能がCheckerである。アサーションはシミュレーションにおいて常に監視をしてくれる。アサーションの記述やチェック項目について言及すると、記述量やチェック項目が多ければ良いという単純な判断はできないまでも、複数の検証IPベンダやEDAベンダからの検証IPを評価する際には、１つの大きな指標となる。実際には異なるコンフィギュレーションでのシミュレーションを実行しながら、活性化されているプロパティの数を比較するといったことが理想的ではあるが、そこまで時間が取れない場合や、あきらかにチェック項目数に違いがある場合には、チェック項目数で判断することも一つの方法である。

まとめ

検証IPはテストベンチ開発や、一部テストシナリオの開発という部分において、明らかに検証エンジニアの労力を省力化してくれる。その背景には長い時間をかけて、最終的にはUVMというメソドロジがAccellera標準を経て、そして最新版としてはIEEE Std. 1800.2-2020としてリリースされたという実績がある。これにより業界にエコシステムが成立するようになり、業界全体としての検証労力の最適化を実現している。検証コンサルティング会社は、さまざまなメソドロジを支援するよりもリソースを集中させることができる。トレーニング会社や書籍の執筆などにおいても同様のことが言える。また近年では北米や欧州の大学ではUVMを授業や研究に取り入れているところもある。ユーザはUVMの恩恵を十分に享受できる状態と言える。

Verification Academyのサイトでは、UVMに関する情報を掲載し更新している。UVM Cookbookは現在でも多くのダウンロード数を誇る業界で標準的な解説書として利用されている。またUVMの導入の敷居を下げるために開発されたUVMF（UVM Framework）もVerification Academyからダウンロードして利用することができるPythonベースのコードジェネレータであり、均質的かつ多くのUVMコードを自動生成させるユーティリティとして利用されている。またUVMの簡易トレーニングの動画なども用意されている。このようなリソースを是非とも活用していただきたい。