2000年には、Verisityデザイン（現ケイデンス・デザイン・システムズ社）は、自動アライメント戦略、カバレッジモデルを生成するインセンティブを含め、電子言語を使用して検証顧問（vAdvisor）を導入しました。E言語は、業界がテストプラットフォームを作成するために、オブジェクト指向言語を使用し始めたあるオブジェクト指向言語です。
2002年には、Verisityは、再利用可能な検証メソドロジ（ERM）--e最初のライブラリを発表しました。
2003年には、シノプシスは、再利用可能なライブラリーの検証メソドロジ（RVM）を発表し、方法論は、シノプシスのベラ言語を採用しました。
2006年には、メンター・グラフィックスは、ハイレベルの検証メソドロジ（AVM）を発表しました。この方法は、主に二つの言語SystemCとSystemVerilogの実装である抽象法（TLM）規格のOSCIのSystemCトランザクション・レベルを使用しています。
2006年には、シノプシスは、（VMM）マニュアルの検証手法を導入し、この方法は、学校にオーバーベラSystemVerilogの言語からRVMです。
同様に促進する工場モデル、構成機構を置き換える、TLMインターフェースを添加しながら、2007年に、ケイデンスは、主に、ERMの方法からE言語のSystemVerilogから学校の上に、一般的な再利用可能な検証手法（URM）を導入しました。
2008年には、ケイデンスとメンター・グラフィックスは共同でOVMを発売しました
2010年に、Accelleraのは、OVMの基礎として採用され、UVMは、検証方法を開始しました。コールバックVMMのいくつかの概念を導入しながら。試作品の業界の統一方法論として。
2010年に、シノプシスはVMM1.2を導入し、工場を、基本的にOVM TLM通信メカニズムに従い、TLM2.0（OSCI最新の標準）を使用して、さらに絞り込むことがあろう暗黙相OVMおよび検証プロセスの使用を提案しモード交換メカニズム、クラス階層（親ビルド関係）の設立。そして、これに基づいて、vmm_timelineのコンセプトは、増加または削除フェーズの各フェーズ、相間のジャンプの実現を容易にします。増加rtl_configの概念。シノプシス社は、すぐにVCSの最新バージョンは、UVMをサポートして発表しました。
UVMとVMM1.2の現在の観点から。最終的には勝つ何に関係なく、我々はトレンドになりまし業界で実証済みの方法論を参照することができます：
1は、システムのモデリングは、主流の業界標準のSystemC言語とESLモデルを使用することで、それは、その特性を評価することができます。標準インタフェースを使用して、TLMは、SystemCのシームレスモデル検証プラットフォーム、基準モデルにインターフェースすることができます。
図2は、各検証コンポーネント確立親関係をので制御がより便利であると、導電環境が自動的に個々のコンポーネントの自動上部相を呼び出します。こうした親関係の確立、だけでなく、部品の工場出荷時の設定やトランザクションモードを交換するのに役立ちます。
3、（UVMエージェント方法を使用して、VMM1.2就業sub_envの方法）特定の機能のために異なる環境のサブコンポーネントの確立は、環境のサブコンポーネントの各々は、開閉するように構成することができます。
4、コンパイル時に、工場出荷時のモードの選択肢を使用して、環境設定、トランザクション、および他のシーン。
5、APIが提供され、あなたは（UVMは、基本クラスで、VMM1.2はvmm_optsで提供）動作フェーズにおける環境のパラメータを変更することができます。
6、トランザクション処理環境、様々な構成要素、実施形態におけるコールバックの使用、エラー注入または収集カバレッジ。
図7は、レジスタは、スクリプトを介して、レジスタの自動生成は、読み出しおよび書き込みベリファイアセンブリスキャン、抽象化層を提供します。（VMMは、RALを提供し、後で記載適切な機構UVMを提供するであろう）。
図8に示すように、プロセスは、そのような位相で検証プロセスを追加または削除などの環境を制御することができ、制御は各相間ジャンプ（VMMはvmm_timelineを提供し、UVMを主張した後、適切なメカニズムを提供するであろう）
傾向は、上述した実績のある方法論は、ケイデンスとメンターに1-5で、OVMを提案しました。6-7及び8 VMM1.2プロパティを追加したのに対し、VMM1.1シノプシス社に記載されています。VMM1.2は、OVMの利点を継承した後、既にそれはこれらの特徴の全てを有するが、UVM UVMの将来の増加同様のRALとvmm_timeline機能を提案しました。
今、比較の観点UVMとVMM1.2、主に以下の分野での長所と短所：
1、UVMは、検証メソドロジの統一基準の後に、フレームワークOVMの使用のための主要なフレームワークは、今ではない正式版の外に立ち上げaccellra組織です。OVMの利点を継承、継承のVMMの利点は十分ではありません。そしてVMM1.2継承OVMの利点を後にし、改善・強化し、その機能はUVMに一時的に優れていることだろうされています。
新基準の導入に伴う2は、そのため、互換性の問題を考慮していない、アーキテクチャがより明確になり、UVMの検証メソドロジです。、ソースコードの可読性が比較的強くなる、とVMM1.2はVMM1.1との互換性を考慮する必要があるが、また、新しい機能を検討し、VMM1.1とVMM1.2も2つの完全に異なるプロセスのように見えますその厄介なアーキテクチャを見て、コードの可読性が悪いです。
3、UVMの方法論は、どのようにシステム検証でどのように再利用可能な具体的な方法やアイデアを計画してくださいどのように設定するには、コンフィギュレーション、への詳細については検証プラットフォームを提案しました。VMMの方法論は、その上で何か間違っ注入とをやるべきすべての段階で、よりモジュールレベルの検証分割検証プロセスを提案しました。これらの方法やアイデアは、図書館とUVMのVMMライブラリに使用する方が便利なことができます。検証プラットフォームは、良いガイドを持って構築します。
この記事は、ネットワークから再生されます
