OVM ： 富士通研究所の事例

Verification Engineerの戯言

日経の小島さんが記事にするまで待とうと思いましたが、どうやら、その気配がない。

メンターのセミナー(DA Tech Forum 2009)の

    OVMを用いた検証の生産性と品質向上 by (株)富士通研究所 高山浩一郎氏

では、富士通が開発したCedarと呼ばれる仕様書起点の検証手法により設計の高品質化を実現してきました。
一方、OVMは検証の効率を上げる方法です。CedarとOVMを組み合わせることにより、Cedarで実現した高品質に加え、
高効率により早期に品質の立ち上げるための道が、このセッションの内容です。

Cedarは「何を検証するのか」のためであり、OVMは「どうやって検証するのか」になり、
2つの結合が高品質・高効率な検証を実現する、これが「新しい検証メソドロジ」となっていく！

OVMの採用は2007年後半の1.0を、2008年後半には2.0を。
OVM 1.0の採用では、従来のスタイル部分として、「ドライバ、モニタ」はそのままモジュール(module)として使っています。
検証環境のアーキテクチャはOVM 1.0ベース(ovm_envベース)とし、SystemVerilogのinterfaceをうまく使い、
DUTとテストベンチ間のインターフェース接続をコンパクトに記述しています。
interfaceを使うことで、OVM 1.0ベースにうまくモジュールベースのモデル(ドライバおよびモニタ)を取り込んでいます。
OVM 2.0の採用では、シーケンス関連を導入。これにより制約付きランダム検証ができるようになります。
シーケンサの階層的な使い方による複数のモデル間の関係をうまく表現しています。
今後の「ファクトリ」を適応予定となっていますが、どんなことがやりたいので「ファクトリ」を適応したいのか、知りたがったか。。。

さて、Cedar+OVMでは、Cedar(仕様モデル)からシナリオを生成し、これをOVMのテストケースとします。
Cedarから生成する検証プランから各シナリオに対するパラメータも生成し、OVMのテストケースに渡します。
こうすることで、CedarとOVMの世界が繋がっていきます。絵に描くとすごーくキレイですね！

ここまでの内容で1つの事例の説明になりますが、シミュレーションではなく、エミュレーションに繋げています。
(エミュレーションに繋げるために、ドライバとモニタはモジュールのまま、残しておいたのでしょうか?)

シミュレータとエミュレータ間の接続によるオーバーヘッドを少なくするためのtlm_fifoを
SCEMI 2.0 pipeを使ったxl_tlm_fifoに置き換えるだけで、
シミュレーションでの検証環境をエミュレーションとのCo-Simulationにも利用できる。

すばらしい。

今回のOVM導入により、検証エンジニアはモチベーションを高め、本来集中すべきこと(検証)に集中できます。
OVMはそのためのツールですから、

検証エンジニアに求められるスキルのスライドでは、。。
なんか、私も九州で話したようなことが、、まーいっか。

とにかく、検証エンジニアのためでいっても過言でないOVMを検証エンジニアが使う。まさに「検証の王道」です。
OVMは、SystemVerilogのクラスを使いまくっています。このクラスは「オブジェクト指向」をベースにしています。

最近の学生は、いきなり、JavaやRuby、Pythonなどの「オブジェクト指向」を使っています。
ですから、けして難しいモノではなく、じっくり勉強すれば、できます。まずは、やってみましょう！

何しろ、ModelSim AE(Altera Edition)やXE(Xilinx Edition)は
扱えるコード規模やシミュレーション速度の制約はありますが、無料でWindowsマシンで動きます。
お金をかける必要が全くありません。必要なのは時間だけです。

今年は、時間がたっぷりある非常に希な年です。
ですから、そのたっぷりの時間をSystemVerilogのクラスの理解と実務への利用のために使いましょう！

なお、ModelSim　AEに関しては、ModelSim AE & MINGW32/MSYSを参照してください。

検証、Verification、SystemVerilog、OVM、Open Verification Methodology