VMM(オリジナルは、VeraベースのRVM)は基本的にはある程度の規模も機能モジュールを検証するためのフレームワークとして開発されたもの。
その後、CadenceとMentorによるオープンソースにてOVMを公開し、VMMもその後オープンソース化。
これがメソドロジ論争になりましたが、今年(2011)に公開されたUVM 1.0にてメソドロジ論争は終結。
その後、CadenceとMentorによるオープンソースにてOVMを公開し、VMMもその後オープンソース化。
これがメソドロジ論争になりましたが、今年(2011)に公開されたUVM 1.0にてメソドロジ論争は終結。
で、VMMの目的であった機能モジュールの検証については、
UVM 1.0でもできるがシステム全体の検証はどうなるのか?
UVM 1.0でもできるがシステム全体の検証はどうなるのか?
複数のトランザクタを制御するためにはどうするのかを含めて詳しく説明してくれています。
でも、全体を制御するためのプログラムもVMM(RAL)で書いています。
ここが私には、理解できないのです。
ここが私には、理解できないのです。
今回の記事にもダイレクトテストよりもRALでというようなことが書いてありますが、
システムレベルでは、ちょっと。
システムレベルでは、ちょっと。
このことは、以前にもこのブログVMM : Chapter 8、System-Level Verificationにも書きました。
特に、VMM本の後半ではシステムレベルの検証についてありますが、
VMMとの乖離が大きすぎて気持ちはわかるのですが、
本当にそんな方法で検証するかいな?って感じて、そのままなっていました。
特に、VMM本の後半ではシステムレベルの検証についてありますが、
VMMとの乖離が大きすぎて気持ちはわかるのですが、
本当にそんな方法で検証するかいな?って感じて、そのままなっていました。
今回紹介して記事も気持ちはわかりますが、やっぱり、そんなことするかなって感じています。
せっかくシステムレベルで検証したテストプログラムが次に繋がっていません。
そこがまず、納得できない点です。
そこがまず、納得できない点です。
検証って、H/Wだけでなく、S/W、そして、システム全体のことも含めて考えないと、
いけないと思っていますから。。。。。
いけないと思っていますから。。。。。
この辺のお話は、今年、みなさんにお伝えできる機会ができましたので、そのときにでも!
検証、Verification、SystemVerilog、VMM、Verification Methodology Manual