はじめに

UVM Cookbookを眺めてみた、の続きです。今日はTestbenchのEnvの話です。

The Env

Env(Environment)は、サブコンポーネントのブロックを集めたコンテナコンポーネントだよ。

ブロックレベルのUVMテストベンチでは、envはDUTのインタフェースとやりとりするagentをまとめるのに使うよ。
envもagentみたいにSystemVerilogのパッケージにまとめるよ。
envはagentの他にも以下のcomponentsを持つよ。
- Configuration object ･･･ envが持つどのコンポーネントをビルドするかを制御するconfiguration object。 envのconfiguration objectはenvのagentが持つconfiguration objectを制御するハンドルも持つよ。これらはset_config_objectで設定するよ。
- Scoreboards ･･･スコアボードはanalysis componentでDUTの動作が正しいか確認するよ。UVM scoreboardsはagentのモニタからのanalysis transactionを使うよ。たいてい2つのtransactionを比較するよ。
- Predictors ･･･プレディクターは入力に対する期待値を作るよ。たいていスコアボードなんかと一緒に使われるよ。
- Functional Cverage Monitors ･･･機能カバレッジモニタになるanalysis componentはcovergroupsをもって機能カバレッジ（テストで何が発生したかの情報）を集めるよ。たいてい機能カバレッジモニタはDUT毎に異なる作りだよ。
例えば、ブロックレベルのテストベンチはagentとanalysis componentsを持つenvをビルドするテストで構成されるよ。

ブロックを統合してサブシステムを作るには、垂直統合的な再利用、つまり、ブロックレベルのテストベンチで使われるenvをマージして上位レベルのenvの作成、をするよ。
ブロックレベルのenvは各ブロックをテストするのに必要な構成を提供するけど、envを統合するとブロックのつなぎ目のインタフェースはDUT内部になって表に出てこなくなるから、統合するとenvには無駄な部分が出てくるよ。
だから上位レベルで統合したenvはDUT内部の出てこないインタフェースをパッシブにしたり、そんなagenetを読み込まないようにする必要があるよ。
テストでこういうconfigurationをできるようにするために、下位階層の各envはひとつ上位階層のenvのconfiguration objectの内包されて上の階層から制御できる必要があるよ。
こんな風にenvをマルチレイヤー化して作るよ。