チップ検証分割のために、彼は、タスクに直面する可能性があり（モジュールレベルであってもよいmodule level）レベルサブシステム（subsystem level）またはシステム・レベル（chip level検証）の。しかし、行くと言って、「すべての道はローマに通ず、」彼らは同じように、現在一般的に使用される業界使用したsystemverilogDUTを検証し、UVM。
UVMがされてsystemverilog検証手法（ライブラリ）のC ++で開発されたいくつかのアイデアを吸収しながら基づき、それは単に自分の要約に基づいて前の仕事のルーチン検査で、私たちが使用し、単純にこのメカニズムのさまざまな部分で異なるコンテンツは、DUTの検証を完了することで埋めます。
チップの検証のために作曲、世界で最も簡単な認証プラットフォームは、我々はしなければならないDUT出力が正常な機能の設計を満たしていることを確認している、裸のDUTのために、我々は彼らの入力を必要とするいくつかのデータは、その入力タイミングのニーズを満たすために要件は、それが通常の出力データとなります。再生FPGAの学生は経験のビジュアルタイミングが設計要件を満たしている持っていたはずです。しかし、タイミング信号の数千万人のために、出力をチェックする必要が正しいです。
検証の世界では、私たちが持つDUT出力、受け入れるために特にドライバとの完全な、そしてどのように、DUT灌漑データの事を持ってmontior達成し、DUTの出力データを完了するためにタスクと比較さを、我々は持つシステムが必要DUTのものと同じ機能が、この事は、参照モデル（参照モデル）に特別な名前を持っている、monitor受信したデータとreference modelの比較が成功した場合、比較のための出力データは、あなたが考えるのに対し、DUTは、デザイン機能を完了させるために言いますそれは？そして、も呼ばれる特別な名前があるものよりもタスク完了しますscoreboard（スコアボード）を。一般的に、我々は入れてdriver、monitor、reference model環境（と呼ばれ、一緒になってenvironment、もちろん、これはより多くの環境はますますになるものの導入の背後にあるとして、最も簡単な環境の一つです、）。図は、次のパターン（UVM実数）で表されます。
仮定しDUT、次のコードを：
run_phase操作機構
module dut(clk,
rst_n,
rxd,
rx_dv,
txd,
tx_en);
input clk;
input rst_n;
input[7:0] rxd;
input rx_dv;
output [7:0] txd;
output tx_en;
reg[7:0] txd;
reg tx_en;
always @(posedge clk) begin
if(!rst_n) begin
txd <= 8'b0;
tx_en <= 1'b0;
end
else begin
txd <= rxd;
tx_en <= rx_dv;
end
end
endmodule さて、上記の実装に必要なDUT認証を、最高のは考えることができる白いdriverおそらく、次のようになります。
run_phase操作機構
module top_tb;
reg clk;
reg rst_n;
reg[7:0] rxd;
reg rx_dv;
wire[7:0] txd;
wire tx_en;
dut my_dut(.clk(clk),
.rst_n(rst_n),
.rxd(rxd),
.rx_dv(rx_dv),
.txd(txd),
.tx_en(tx_en)
);
initial begin
rxd <= 8'b0;
rx_dv <= 1'b0;
while(!rst_n)
@(posedge clk);
for(int i = 0; i < 256; i++)begin
@(posedge clk);
rxd <= $urandom_range(0, 255);
rx_dv <= 1'b1;
end
@(posedge top_tb.clk);
rx_dv <= 1'b0;
//finish
$finish();
end
initial begin
clk = 0;
forever begin
#100 clk = ~clk;
end
end
initial begin
rst_n = 1'b0;
#1000;
rst_n = 1'b1;
end
endmodule ドライバの検証における役割は、ピストルと同様とすることができる、の検証DUT機能ポイントは信号が生成された場合、私たちの目標であるが、駆動タイミング（駆動プロトコル）を入れたdriver実装、など、多くの問題をもたらします
ドライバコード部分があまりにも複雑で、継続的なメンテナンスおよび再利用コードトラブルの積層の欠如、
駆動信号プロトコルは同じであってもよいが、必要に応じて異なる機能検証ポイント、信号、又は信号の組み合わせ
UVMこのクラスのDUTが、異なる機能コンポーネントにドライバ部分分割することによって達成されるために一般的に使用される、クラスが実装する（生成された信号があることを確認sequence）、（信号伝送のタイプsequencer）とクラス（駆動信号driver）;これらの事とてもフレンドリーではないスターター、のために、あなたは、クラスの特定の機能として理解されている時間を完了することができますが、我々は唯一の特定の名前にそれらを取りました。今、心はこのようにする必要があり、sequenceそれはクリップ、あるsequencer春、driverピストル。一見非常に重要なことを忘れて、どのように銃の弾丸が、これはとUVMと呼ばれていない可能性がseqence_itemDUTの検証生成およびプロセス駆動型の駆動タイミングを達成するために、何かの完全な、四つの部分。
再び我々の理解、短いクリップを装着したピストルのさらなる拡大のために上記のメタファー銃、ワンショット7弾（一見）ことができますが、私は長い間、一回のインストール50から少しクリップを回帰した場合弾丸、クリップは、タスクを完了するために、ピストル射撃をプラグインすることができます限り。私たちはさまざまな機能のポイントを確認し、このアナロジーは理解できるが、彼らは同じプロトコルドライバに従いますが、構成が異なる、我々はちょうど再拡張または再定義する必要がsequence弾丸が同じであるため、缶、我々はバレルを変更する必要はありません（）sequencerとピストル（driver）;関数より迷惑時々を検証するためのポイントは、同じDUTのために、それは異なるプロトコルを満たす必要があり、この時間は私たちが祝福やランチャーと引き換えにピストルを配置する必要があり、四つの成分の再に、すなわち必要性契約に基づき実装を定義します。一般的にmontiorDUTの検出出力およびドライバは、果実がなければならないと言って、強いと関連しています。
今まで前記我々検証コードフレームワークは、この下に成長されるべきであるmy_transactionクラスは、データ変数の数を定義my_sequence達成されるtransaction組織およびパッケージングをmy_driver達成することであるmy_transactionDUTに特定のプロトコルドライバをインストールしたデータを、そして最後my_sequencerISそれがあるmy_sequenceとmy_driver接点のリンク（接続）は、実際には、my_sequencer真の目的があり、それは乗客の真ん中ではなく、また違いを生みます。これらは続くsequence話題の慎重な説明を。図は慎重に我々は、彼らが継承されることを見つけるとなりuvm_*、その上でこの種のもの、何かを定義するために私たちを助けているルーチン、以前の概要、我々は直接使用することができます。ああ、はい、次のチャートは、どの、説明しなければならないほとんどないsequence/sequencer/driver小さな尾がある#（ my_transaction ）あなたはこのようなものを書いていない場合はテンプレートクラス（とも呼ばれるパラメータクラス）と呼ばれ、スタッフは、私たちのパラメータを必要なsequence / sequencer / driver内部を「弾丸」を発行し、デフォルトになりますuvm_sequence_itemタイプ。私は「銃」として、それは弾丸が、我々はまだクリアしなければならない、またはいくつかの不要なトラブルのコンパイルにつながるかもしれないものだと思います。
同様のmonitorコードスタイルから継承された図に似ていますuvm_montior。