10日目～まとめ

最終日となりました。これまで扱ったものを整理すると

1. モデルの基本的な作り方と、コンポーネントの階層構造の理解
   1. 階層構造
      1. uvm_env
         1. uvm_agent
            1. uvm_driver
            2. uvm_monitor
            3. uvm_sequencer
   2. DUTとの接続は、virtual interfaceを用いる
   3. バスをドライブするのはuvm_driver
   4. バスをモニタリングするのはuvm_monitor
   5. driverへ命令を橋渡しするのはuvm_sequencer
   6. driverへ渡す命令の固まりはuvm_sequence_itemを使う
2. テストの構成の仕方
   1. テストの親玉はuvm_test
      1. default_sequenceの設定で、モデルを動かすテストを決定する
   2. driverへ渡す命令を記述するのはuvm_sequence
   3. uvm_sequenceの中で、uvm_sequence_itemを使って、driverを動かす
   4. uvm_sequenceは部品化でき、それをuvm_sequenceで呼び出すことができる
3. スコアボードを用いた自動比較
   1. analysis_portというコンポーネントを使って、スコアボードとモニタを定義する
   2. スコアボードとモニタは、テストベンチのuvm_envの中で接続する
4. 再利用する方法
   1. クラスのextendsだけでなく、それをextendsしたクラスを、extendsする前のクラスに置き換えて使う手法を使う
      1. set_inst_override
      2. set_type_override

ざっとこんな感じでしょうか？

UVMを使うメリットを完結にまとめると

1. モデル設計時の基本構造が決まっている、テストの書き方が決まっている
   1. → 基本的なアーキテクチャが確定しているため、その部分に検討する時間を割く必要がない
2. 複数モデル間の終了同期方法がはじめから組み込まれている
   1. → オブジェクションメカニズム
3. 複数モデルを１つのsequenceで扱う仕組みができている（virtual_sequence。50.UVMで遊ぼうの中にエントリーあります → まだ書いてませんでした）
4. 入力信号に対する出力信号の期待値比較の自動化手法が思想として組み込まれている

まだいろいろあるとは思いますが、とりあえず思いつくことをツラツラと書いてみました。

雑談になりますが、例えばテレビを作るとしたら、自動車を作るとしたら、どうしますか？革新的なものを作らない限りは、基本形が存在するわけでして、それを基準に構造を築きあげると思います。そう、外枠 は決まっているんです。その意味でUVMは、機能検証を実施する際の「基本形」が定義されているわけでして、これに沿って検証環境を組み上げていかないのは非常にもったいないと思います。しかも、 Cadence、Mentor、Synopsysといった大手ベンダーの優れた技術者たちが考えた基本形です。その大元となっているSpecmanは、IBMが採用していたわけでして、世界中のブレインの知識が集まったものといえま す。これを使わない手はありません。

なお、この10日間のエントリーはひとまずクローズしまして、応用編を自ら学習しながら展開していくつもりです。

余力があるときに、本エントリーを見直しまして、必要に応じて説明を追加していこうと考えています。