Open Verification Methodology ユーザ・ガイド プロダクト・バージョン 2.0 2008 年 9 月

1

目次

はじめに..........................................................................7

この本の使い方.......................................................................................7

OVM とは何か ........................................................................................8

OVM をインストールする ....................................................................10

この本の用語 ........................................................................................10

このマニュアルの表記法.......................................................................12

OVM 概要 ....................................................................14

OVM 入門 .............................................................................................14

OVM とカバレッジ・ドリブン検証(CDV) ...........................................................14 OVM テストベンチと環境....................................................................................15

OVC の概要 ..........................................................................................16

データ・アイテム（トランザクション） .............................................................17 ドライバ（BFM） ...............................................................................................17 シーケンサ ...........................................................................................................17 モニタ ..................................................................................................................18 エージェント........................................................................................................19 環境......................................................................................................................19

SystemVerilog OVM Class Library .....................................................20 その他の OVM の便利さ ......................................................................................22

トランザクション・レベル・モデリング（TLM） .....24

トランザクション・レベル・モデリングの概要 ...................................24

TLM の基本 ..........................................................................................25

2

トランザクション.................................................................................................25 トランザクション・レベル・コミュニケーション ...............................................26 基本の TLM コミュニケーション.........................................................................26 プロセス間のコミュニケーション ........................................................................28 ブロッキング対ノンブロッキング ........................................................................29 トランザクション・レベル・コンポーネントの接続............................................30 ピア・ツー・ピア 接続........................................................................................30 ポート／エクスポートの互換性 ...........................................................................31

カプセル化と階層 .................................................................................31

階層的接続 ...........................................................................................................31

アナリシスコミュニケーション ............................................................33

アナリシスポート.................................................................................................34 アナリシエクススポート ......................................................................................35

再利用可能な OPEN VERIFICATION COMPONENT

(OVC)の開発 .................................................................37

生成のためのデータ・アイテムのモデル化 ..........................................37

継承と制約のレイヤ化 .........................................................................................40 コントロール・フィールド（“ノブ（Knob）”）の定義 .....................................40

トランザクション・レベル・コンポーネント.......................................41

ドライバの生成.....................................................................................44

シーケンサの生成 .................................................................................45

ドライバとシーケンサの接続 ...............................................................................46 連続したランダム化されたアイテムの取り込み...................................................48 処理されたデータをシーケンサに戻す .................................................................49 TLM ベースのドライバを使って..........................................................................49

モニタの作成 ........................................................................................50

コンポーネントのインスタンシエーション ..........................................52

3

エージェントの作成..............................................................................54

環境の作成 ............................................................................................57

環境クラス ...........................................................................................................57 OVM のコンフィギュレーションの仕組み ...........................................................58

シナリオの生成を可能とする ...............................................................60

ユーザ定義のシーケンスの宣言 ...........................................................................61 シーケンスとシーケンス・アイテムでスティミュラスの生成..............................62 あらかじめ定義されたシーケンス ........................................................................66 シーケンサのデフォルトのシーケンスを再構成...................................................68 シーケンス・アイテムとシーケンスの上書き ......................................................68 再利用可能なシーケンス・ライブラリの構築 ......................................................69

チェックとカバレッジの実装 ...............................................................70

クラスでチェックとカバレッジの実装 .................................................................71 インタフェースでチェックとカバレッジの実装...................................................73 チェックとカバレッジのコントロール .................................................................74

OVC を使って ...............................................................75

OVC を使って.......................................................................................76

テスト・クラス ....................................................................................................76 テストベンチのクラス .........................................................................................77

OVC のインスタンシエーション ..........................................................78

OVC コンフィギュレーション ..............................................................81

OVC の再構成可能なパラメータ..........................................................................81 OVC のコンフィギュレーションの仕組み............................................................82 コンフィギュレーション・クラスを使って..........................................................82

ユーザ定義のテスト生成と選択 ............................................................83

ベース・テストの作成 .........................................................................................83 テスト・ファミリーのベース・クラスからテストの生成.....................................84

4

テスト選択 ...........................................................................................................85

意味のあるテストの作成.......................................................................86

データ・アイテムの制約 ......................................................................................87 シーケンスの使用.................................................................................................90

バーチャル・シーケンス.......................................................................97

バーチャル・シーケンサの生成 ...........................................................................99 バーチャル・シーケンスの作成 .........................................................................101 ほかのシーケンサのコントロール ......................................................................102 バーチャル・シーケンサをサブシーケンサに接続 .............................................103

DUT の正しさへのチェック ...............................................................104

スコアボード......................................................................................................104

カバレッジ・モデルの実装 .................................................................109

カバレッジ・メソッドの選択 .............................................................................109 ファンクショナル・カバレッジ・モデルの実装.................................................109

より高度なトピック.................................................... 111

ovm_component ベース・クラス........................................................ 111

シミュレーション・フェーズ・メソッド............................................ 111

build() ................................................................................................................ 112 connect() ............................................................................................................ 113 end_of_elaboration().......................................................................................... 113 start_of_simulation()......................................................................................... 113 run()................................................................................................................... 113 extract() ............................................................................................................. 114 check() ............................................................................................................... 115 report() .............................................................................................................. 115 ユーザ定義のフェーズの追加 ............................................................................. 115

組み込みのファクトリとオーバーライド............................................ 116

ファクトリについて ........................................................................................... 117

5

ファクトリへの登録 ........................................................................................... 117 コンポーネントのオーバーライド ...................................................................... 118

高度なシーケンス・コントロール ......................................................122

複雑なシナリオの実装 .......................................................................................122 複数シーケンスの並列実行 ................................................................................122 プロトコルのレイヤ化 .......................................................................................128 シーケンスの生成に関連した高度なアスペクト.................................................138

XBUS OVC の例.........................................................143

XBus デモ...........................................................................................144

XBus デモ・アーキテクチャ .............................................................147

XBus トップ・モジュール .................................................................148

テスト .................................................................................................149

テストベンチ環境 ...............................................................................152

XBus 環境 ..........................................................................................155

XBus エージェント............................................................................156

XBus シーケンサ ...............................................................................158

XBus ドライバ...................................................................................159

XBus エージェント・モニタ .............................................................160

XBus バス・モニタ.............................................................................161

バスからのトランスファーの収集 ......................................................................161 トランスファーの数 ...........................................................................................162 XBus バス・モニタによって出されるノーティファイヤ（notifier）................162 チェックとカバレッジ .......................................................................................163

6

XBus インタフェース ........................................................................163

XBUS の仕様 ..............................................................165

始めに .................................................................................................165

仕様開発のきっかけ ...........................................................................................165 バスの概要 .........................................................................................................165

バスの記述 ..........................................................................................165

バスの信号 .........................................................................................................166 クロック.............................................................................................................167 リセット.............................................................................................................167

アービトレーション・フェーズ ..........................................................168

アドレス・フェーズ............................................................................169

NOP サイクル ....................................................................................................169 通常のアドレス・フェーズ ................................................................................170

データ・フェーズ ...............................................................................170

Write トランスファー .......................................................................................170 Read トランスファー ........................................................................................171

何が何をいつドライブするか .............................................................171

オプションのパイプライン・スキーム ...............................................173

パイプライン化されたアービトレーション・フェーズ ......................................173 パイプライン化されたアドレス・フェーズ........................................................174 パイプライン化されたデータ・フェーズ ...........................................................174

タイミング・ダイアグラムの例 ..........................................................174

7

はじめに この本は OVM Class Library を用いた Open Verification Methodology(OVM)の使い方を説明し

ています。この本は： • このマニュアルがどのように構成されているか、検証の作業にこれをどのように使用する

かを述べます。 • 簡単に次の項目を記述します。

• OVM の特徴 • OVM のインストールの方法（もし必要ならば） • OVM の用語

• OVM の考え方と検証の役割について概要を述べます • 環境の開発者に再利用可能な検証コンポーネントの作成の方法を示します。 • テスト環境ユーザに対しコンポーネントを環境に組み込み、検証のゴールをみたすテスト

を生成する方法を示します。 • XBus のデザイン例を用いて OVM 環境の例を提供します。 OVM は SystemVerilog OVM Class Library を使用しており、これは SystemVerilog OVM Class Reference に文書化されていますが、どちらも www.ovmworld.org から入手できます。 この章は次のセクションを含んでいます： • この本の使い方 7 ページ • OVM とは何か 8 ページ • OVM をインストールする 10 ページ • この本の用語 10 ページ • このマニュアルの表記法 12 ページ

この本の使い方 典型的な検証チームは異なるスキル・セットと責任を持った複数のメンバより構成されます。開

発者と環境のユーザという異なる役割で、検証の知識に関し異なる深さが要求されます。このマ

ニュアルの構成は典型的な検証チームがその責任を分割している方法に基づいています。 • 環境の開発者は再利用可能なテストベンチのインフラストラクチャを作ります。 • 環境のユーザ（もしくはインテグレータ）はプロジェクトの検証のゴールをみたすために、

開発者によって作成されたテストベンチのインフラストラクチャを再構成しテストを作成

8

します。 OVM の完全な理解を得るために、個々の役割にかかわらず、OVM マニュアルを全て読むことが

勧められます。しかし、このマニュアルは環境のユーザがマニュアル全てを読んで理解しなくて

も、知る必要のあることをすばやく学べるようになっています。このマニュアルは次のような構

成になっています。 章 説明 はじめに この章 OVM 概要 OVM の考え方と検証の役割について概要を記

述します。この章は検証チームの全てのメンバ

が読む必要があります。 トランザクション・レベル・モデリング

（TLM） OVM におけるトランザクション・レベル・コミ

ュニケーションの基本要素を議論し、トランザ

クション・レベルのコンポーネントを検証環境

に組み込む仕組みを例示します。 再 利 用 可 能 な Open Verification Component(OVC)の開発を行う

OVC/環境の開発者に対し再利用可能な検証コ

ンポーネント (OVC)の作成の仕方を説明しま

す。環境のユーザも OVC の開発についてより深

く理解するためにこの章を読みたいと思うかも

しれません。 OVC を使って 環境ユーザ／インテグレータに特定の検証プロ

ジェクトに OVC をどのように再構成するか、検

証のゴールをみたすためにテストとシナリオを

どのように作成するか説明します。 高度なトピック それまでの章のいくつかのトピックを非常に詳

細に議論します。 XBus OVC の例 XBus の仕様と OVM に基づいて OVC の例を一

通りユーザに体験してもらいます。 XBus の仕様 XBus の仕様

OVM とは何か OVM は完全な検証手法で、大規模ゲートや、IP ベースの SoC をターゲットとした検証環境開発

のベストプラクティスを体系化しています。検証の生産性は、すばやく個々の検証コンポーネン

トを開発し、再利用性の高い検証コンポーネントに組み込み、さまざまなコンフィギュレーショ

ンや異なる抽象レベルで再利用する能力によってもたらされます。OVM はブロック・レベルの

9

コンポーネントと環境を、システムを構築していくことができるブロックとしてカプセル化し、

再利用を可能とすることにより“ボトムアップ”の再利用をサポートします。“トップダウン”の

再利用はトランザクション・レベルの検証環境をデザインのシステムレベル・モデルとアセンブ

ルし、デザインが RTL まで詳細化されていく過程で再利用されることを可能とします。 OVM はコンポーネント間のモジュール化されたコミュニケーションに、標準 TLM インタフェー

スの SystemVerilog 実装を使用します。検証コンポーネントの実証された再利用アーキテクチャ

とあいまって、OVM は共通のオブジェクト指向の使用モデルを提供し、すべての OVM 準拠の

OVC は作成元や実装言語の種類によらず相互に動作することを確かなものとします。OVM の主

要な機能には次のものがあります： • データの設計 ―プロパティ変数を設定、読み込み、（テキストや GUI に）プリントするユ

ーザ・コードを抽象化し簡単化するクラス・プロパティのインフラストラクチャ。 • スティミュラス生成 ― モジュールおよびシステム・レベルのスティミュラス生成のため

に、シーケンシャルなデータ・ストリームの微細なコントロールを可能とするクラスとイ

ンフラストラクチャ。ユーザは DUT のステート、インタフェース、またはあらかじめ生成

されたデータを含め、環境の現在の状態に基づきランダム化することができます。ユーザ

にはすぐに利用可能なスティミュラス生成が提供され、ユーザ定義の階層的なトランザク

ションやトランザクション・ストリームを含むようにカスタマイズすることができます。 • 検証環境の構築と実行 ― いろいろなプロトコル、インタフェース、プロセッサを含む SoC

の完全な検証環境を生成することはますます難しくなっています。検証環境の各ファンク

ショナル・アスペクトのために、ベース・クラスが SystemVerilog OVM Library に提供さ

れます。ライブラリはユーザ定義のタイプを検証環境に統合するのをスムースに流すため

の便宜を提供します。トポロジ・ビルドのインフラストラクチャやメソドロジは必要とな

るテストベンチの構造を定義するときに柔軟性を発揮します。共通のコンフィギュレーシ

ョン・インタフェースは実行時の動作やトポロジをカスタマイズするためにユーザがフィ

ールドを調べ設定できるようにします。 • カバレッジ・モデル・デザイン ― グローバルおよび微細なコントロールのデザインを含

め、再利用可能な OVC に、カバレッジを組み込むための もよく知られている手法。 • 組み込みのチェック・サポート ―グローバルおよび微細なコントロールのデザインを含め、

フィジカルおよびファンクショナル・レイヤのチェックを、再利用可能なOVCに組み込む、

もよく知られた実施。 • ユーザ例 ― XBus をもとにしたゴールデンの例が提供されます。例はテスト、シーケンス、

テストベンチ構造、そしてメソドロジとベース・クラスを用いている派生した OVC を含ん

でいます。

10

OVM をインストールする OVM キットのインストールの手順については、リリース・キットのトップレベル・ディレクト

リにある README ファイルを参照してください。

この本の用語 用語 定義 エージェント（Agent） HDL 信号をドライブしたり（ドライバ）、ドライバにスティミ

ュラスを供給したり（シーケンサ）、カバレッジのチェックや

テーブル化を実施するとともにデータ・アイテムの収集を行う

(モニタ)ために必要な標準コンポーネントを含むデバイス。エ

ージェントは独立したオペレーションも可能。 バス・モニタ バス・レベルで信号情報を抽出し、それをイベントやデータ、

そしてステータス情報に変換する責任を持つ検証コンポーネ

ント。 チェックとカバレッジ ファンクションおよびビヘイビアの解析で、カバレッジ、カバ

ーグループ、プロシージャ・コード、または OVM クラス・ベ

ースのモニタもしくはSystemVerilogインタフェースのアサー

ションを使用して行います。 コンポーネント OVC の各エレメントを生成するために用いられる基本的なビ

ルディング・ブロック。各コンポーネント（例えば、ドライバ、

エージェント、など）は ovm_component ベース・クラスを

継承しています。 データ・アイテム 検証環境でスティミュラスとして生成されたトランザクショ

ン・オブジェクト。 ドライバ 検証のコンポーネントで DUT にピン・レベルのインタフェー

スで接続します。これは一つまたはそれ以上のトランザクショ

ン・レベルのインタフェースを持ち検証環境の中の他のトラン

ザクション・レベルのコンポーネントとコミュニケーションを

行います。 DUT Device Under Test 検証されるデザイン（ブロック、サブ

システム、またはシステム）で、ハードウエアとソフトウエア

の組み合わせのときもあります。 ENV 環境もしくは”env”は OVC のトップレベルのコンポーネント

11

で、一つ以上のエージェントを含み、同様にバス・モニタのよ

うなトップレベルのコンポーネントを含みます。環境は再利用

ができるようにするために再構成が可能です。例えば検証環境

がシステム検証で再利用されるときに、能動的なエージェント

を受動的なものに変えることができます。 網羅的シーケンス シーケンサで利用可能なシーケンスをランダムに選択し一回

実行します。 インタフェース OVC PCI、TCP/IP、イーサネットなどの特定のプロトコルに焦点を

合わせた再利用可能な検証コンポーネント。 遅延ランダム化 DUT に渡されるときまでデータの生成とランダム化を遅らせ

ます。 レイヤード・シーケンサ プロトコルの与えられたレイヤでドライバの代わりに使われ

るシーケンサ。レイヤード・シーケンサはデータ・アイテムを

プロトコルの低位レイヤの一つ以上のトランザクションに変

換するシーケンスを実行します。低位レイヤ・アイテムの追加

のストリーム生成を行うほかのシーケンスを並列に実行する

こともあります。 モニタ 信号レベルの動作をモニタし、検証環境のほかのコンポーネン

トにトランザクションをコミュニケーションする検証コンポ

ーネントです。モニタは必要に応じて特定のチェックやファン

クシナル・カバレッジの収集も実行します。 OVC OVM の検証コンポーネントです。OVC はインタフェース・プ

ロトコル、デザインのサブモジュール、またはシステム全体の

ためのカプセル化され、再利用可能で再構成可能な検証コンポ

ーネントです。 パブリック・インタフェ

ース パブリックと宣言されたアプリケーション・プログラミング・

インタフェース（API）です。 ランダム・シーケンス 特定のシーケンサに利用可能なシーケンスの一つをランダム

に選びそれを実行するシーケンスです。 シーケンス シーケンサに関連する基本コンストラクトです。シーケンスは

データ・アイテムや他のシーケンス（サブシーケンス）を生成

し一つ以上のトランザクションを OVC のドライバを通して

DUT にドライブします。このコンストラクトはドライバ・シ

ーケンスとも呼ばれます。 シーケンス・アイテム シーケンスによって生成されたデータ・アイテム（すなわちト

ランザクション）です。このアイテムは通常シーケンサによっ

12

てドライバに提供されます。スティミュラスのレイヤ化のため

に各レイヤに異なるデータ・アイテムを定義できます。低位レ

イヤのオブジェクトが上位レイヤのオブジェクトからアイテ

ムを提供されることもあります。 シーケンス・ライブラリ シーケンサによって使用されるシーケンスの集まりです。 シーケンサ シーケンスとドライバの間でデータの生成とフローの仲立ち

をする検証コンポーネントです。シーケンサはシーケンス・ラ

イブラリと呼ばれる、それに関連したシーケンスの集まりを持

っています。このタイプのコンポーネントはドライバ・シーケ

ンサとも呼ばれます。 シンプル・シーケンス 単一のランダムデータ・アイテムを生成するシーケンスです。

サブシーケンサ バーチャル・シーケンサのバーチャル・シーケンスからアクセ

スされるシーケンサです。 テスト テスト作成者からのテスト特有の指示をカプセル化するクラ

ス テストベンチ（Env） 再利用可能な検証環境が構築されるトップレベルのコンテナ TLM トランザクション・レベル・モデリングです。TLM インタフ

ェースはコンポーネントに対し信号の代わりにトランザクシ

ョンでやり取りする手法を提供します。コンポーネントはその

TLM インタフェースによって特徴付けられ、互換性のあるイ

ンタフェースを持つほかのコンポーネントとだけ接続される

ようにできます。 バーチャル・シーケンス 一つ以上のシーケンサにおいて、ほかのシーケンスのアクティ

ビティを調整するシーケンスのことをバーチャル・シーケンス

と呼びます。バーチャル・シーケンスは多重インタフェースの

データ・フローの集中管理を可能にします。

このマニュアルの表記法 書体 表示 Courierフォント コードを意味します。例えば

class simple_item extends ovm_sequence_item;

Courier太字フォント コードの重要な部分を強調するのに使います。例えば

set_type_override("uart_frame",

"short_delay_frame");

またユーザ入力を表すのにも使われます。次の例はユーザが

13

runコマンドを入力し、それに対応してシステムがコマンドの

結果を表示しています。

sim-prompt> run

SVSEED default: 1

OVM_INFO @ 0 [RNTST] Running test ...

斜体 斜体のフォントは定義しなければならない変数を表していま

す。例えば次の文は、count は変数で値を代入しなければなら

ないことを表しています。

実行されるシーケンスの数はシーケンサの count フィール

ドによります。 Sim-prompt> 実行しているシミュレータのプロンプトを表しています。例え

ば sim-prompt> run

＞ サードパーティのシミュレータのプロンプトを表します。 ％ UNIX のプロンプトを表します。

14

OVM 概要 この章は次の内容を記述します。

• SystemVerilog テストベンチを作成するための Open verification Methodology(OVM)の使

い方。

• OVM Verification Component(OVC)の推奨アーキテクチャ。 この章は次のセクションを含んでいます。 • OVM 入門 14 ページ • OVC 概要 16 ページ • SystemVerilog OVM Class Library 20 ページ

OVM 入門

OVM とカバレッジ・ドリブン検証(CDV)

OVM はカバレッジ・ドリブン検証(CDV)を達成するための 適なフレームワークを提供します。

CDV は自動テスト生成、自己チェック・テストベンチ、カバレッジの数値指標を組み合わせ、デ

ザインを検証するために使われる時間を大幅に削減します。CDV の目的は次のようになります： • 数百ものテストを生成するための時間と労力をなくします。 • あらかじめゴール設定することにより完全な検証を確かなものとします。 • 早期にエラーの通知を受け、実行時のチェックやエラー解析を展開することによりデバッグ

を簡単化します。 CDV フローは従来のダイレクト･テスト・フローとは異なります。CDV ではまず体系づけられた

プランニング・プロセスを用いて検証のゴールを設定することから始まります。次に高性能のテ

ストベンチを開発し適切なスティミュラスを生成しそれを DUT に送ります。カバレッジ・モニ

タが環境に加えられ進捗状況を測定し、まだ試されていない機能を特定します。チェッカーが加

えられ好ましくない DUT の動作を特定します。カバレッジ・モデルとテストベンチがインプリ

メントされた後、シミュレーションが実行されます。これで検証が達成されます。 CDV を使って、テストベンチのパラメータを変えたり、乱数のシードを変えたりしながらデザイ

15

ンを完全に検証することができます。高性能のインフラストラクチャにテストの制約条件を加え、

シミュレーションを調整し検証のゴールをより早くみたすようにすることができます。ランキン

グのテクノロジは検証のゴールに貢献するテストやシードを特定し、冗長なテストをテスト・ス

イートのリグレッションから取り除くことができます。 CDV の環境はダイレクト・テスト法と、制約付ランダム・テスト法の両方をサポートします。し

かし、望ましいアプローチは制約付ランダム・テスト法で大部分の作業をさせ、ランダムな方法

では到達が困難な特定のシナリオに到達するよう、時間のかかるあらかじめダイレクト・テスト

を書くことに努めることです。 適切なプランニングにより大幅な効率と検証プロセスの可視性が達成できます。具体的な数値指

標をもった実行可能なプランを作成することは設計と検証のプロジェクト全体を通して進捗状況

と完全性を正確に測定できるようになります。この手法を用いることによりカバレッジのソース

をプランし、観測し、ランク付けを行い、機能レベルでレポートすることができます。抽象化さ

れた、機能ベースの（そして実装の詳細には依存しない）アプローチにより、より読み易く、ス

ケーラブルで再利用可能な検証プランを作成することが可能となります。

OVM テストベンチと環境

OVM テストベンチは OVM 検証コンポーネント（OVC）と呼ばれる再利用可能な検証環境より

構成されています。OVC はカプセル化され、すぐに使える、再構成可能な検証環境で、インタフ

ェース・プロトコル、デザインのサブモジュールもしくはシステム全体に適用されます。各 OVCは一貫性のあるアーキテクチャに従っており、特定のプロトコルやデザインのシミュレーション、

チェック、カバレッジ情報の収集のためのエレメントの完全なセットより構成されています。

OVC はテスト下のデバイス（DUT）に適用され、プロトコルやデザインのアーキテクチャの実

装を検証します。OVC は DUT のための効率的なテストベンチの生成を促進し、どのハードウエ

ア記述言語（HDL）でも Verilog、VHDL、e、SystemVerilog、SystemC を含むどのハイレベル

検証言語（HVL）でも動作するように構成されています。 ページ16の図2－1は3つのインタフェースOVCを持つ検証環境を示しています。これらのOVCは全社のリポジトリに格納し複数の検証環境で再利用できるかもしれません。インタフェース

OVC は望む動作モードのためにインスタンシエートし再構成されます。検証環境はまた多重チャ

ネル・シーケンスの仕組み（すなわちバーチャル・シーケンサ）を含んでおり、異なるインタフ

ェース間のデータやタイミングの同期をとり、特定のテストのためのテスト環境を詳細にコント

ロールできるようにします。

16

図 2－1 検証環境例

OVC の概要 次のサブセクションは OVC のコンポーネントについて説明します。 • データ・アイテム（トランザクション） 17 ページ • ドライバ（BFM） 17 ページ • シーケンサ 17 ページ

17

• モニタ 18 ページ • エージェント 19 ページ • 環境 19 ページ

データ・アイテム（トランザクション）

データ・アイテムは DUT への入力を表します。例としてはネットワークのパケット、バス・ト

ランザクション、インストラクションなどがあります。データ・アイテムのフィールドや属性は

データ・アイテムの仕様から継承されます。例えばイーサネット・プロトコルの仕様はイーサネ

ット・データ・パケットの有効な値や属性を定義しています。典型的なテストでは多くのデータ・

アイテムが生成され DUT に送られます。SystemVerilog の制約を使って巧妙にデータ・アイテ

ム・フィールドをランダム化することにより、多くの意味のあるテストを作り出すことができカ

バレッジを 大化することができます。

ドライバ（BFM）

ドライバはアクティブな実体で DUT をドライブするロジックをエミュレーションします。典型

的なドライバは DUT の信号をサンプリングしドライブすることにより、繰り返しデータ・アイ

テムを受信しこれを DUT にドライブします。（もし過去に検証環境を作成したことがあるならば、

たぶんドライバの機能をインプリメントしたと思われます。）例えば、ドライバは read/write 信

号、アドレス・バス、データ・バスを数クロック・サイクルの間コントロールし write 転送を実

行します。

シーケンサ

シーケンサは高度なスティミュラス生成器であり、実行のためにドライバに供給されるアイテム

をコントロールします。デフォルトで、シーケンサはシンプル・スティミュラス・ジェネレータ

と同様の動作をし、ドライバからのリクエストによりランダムデータ・アイテムを返します。こ

のデフォルトの動作はランダム化された値の分布をコントロールするためにデータ・アイテム・

クラスに制約を加えることを可能とします。トランザクションの配列や、一度に一つのトランザ

クションをランダム化する生成器と異なり、シーケンサは直ちに重要なランダム化の要求を捉え

ます。シーケンサの組み込み機能の部分的なリストは次のようになります： • 生成される全てのデータ・アイテムのために DUT の現在の状態に反応する機能。

18

• ユーザ定義のシーケンスにおけるデータ・アイテム間の順序を捉えます。これはより構造化

された意味のあるスティミュラス・パターンを構成。 • 再利用可能なシナリオで時間のモデリングを可能とする。 • 同じシナリオに対し宣言型と手続き型の制約をサポート。 • 多重インタフェースに対しシステム・レベルの同期化とコントロールが可能。 シーケンサの生成と使用に関しより詳しい情報が必要ならば、SystemVerilog OVM Class Reference とこのマニュアルの次のセクションを参照してください。 • “シナリオ生成を可能とする” ページ 60 • “シーケンサの使用” ページ 91 • “バーチャル・シーケンスの生成” ページ 102 プロトコルのレイヤ化をモデル化するために、シーケンサをお互いの上に積み重ねることができ

ます。さらに詳しくはページ 136 の“レイヤ化されたシーケンサの使用”を参照してください。

モニタ

モニタは受動（passive）の実体で、DUT 信号をサンプリングしますがドライブはしません。モ

ニタはカバレッジの情報を収集しチェックを実行します。再利用可能なドライバとシーケンサは

バスのトラフィックをドライブしますが、これらはカバレッジやチェックには使われません。モ

ニタがその代わりに使われます。モニタは次のことを行います。 • トランザクション（データ・アイテム）の収集。モニタはバスから信号情報を抽出しトラン

ザクションの情報に変換し、ほかのコンポーネントやテストの作成者が利用できるようにし

ます。 • イベントの抽出。モニタは情報（トランザクションのような）の利用可能性を検出し、デー

タを構造化し、ほかのコンポーネントにトランザクションの利用可能性を伝えるためにイベ

ントを出します。モニタはまたステータス情報を捉え、これをほかのコンポーネントやテス

ト開発者が利用できるようにします。 • チェックとカバレッジの実行

• チェックは通常プロトコルとデータのチェッカーよりなり、DUT の出力がプロトコル

の仕様にあうかを検証します。 • カバレッジもモニタで収集されます。

• オプションでトレース情報をプリントします。 バス・モニタはバスの全ての信号とトランザクションを取り扱い、一方エージェント・モニタは

19

特定のエージェントに関係する信号とトランザクションのみ取り扱います。 通常ドライバとモニタは別々の実体として構築され（同じ信号を使用するかもしれませんが）、お

互いに独立に作業をすることができます。しかしドライバとモニタの間で共通なコードを再利用

し開発時間の節約をすることができます。 注意：モニタが情報のためにドライバに依存しないようにし、モニタだけが存在するときにエー

ジェントが受動的に動作できるようにしてください。

エージェント

シーケンサ、ドライバ、そしてモニタは独立して再利用することができますが、これは環境イン

テグレータがこれらおのおのの実体の名前、役割、コンフィギュレーション、そして結びつきを

習得する必要があります。この作業量を減らし、テスト作成者に必要とされる知識を減らすため

に、OVM は環境開発者がエージェントと呼ばれる、より抽象的なコンテナを作成するよう勧め

ています。エージェントは DUT デバイスをエミュレートし検証することができます。エージェ

ントはドライバ、シーケンサ、そしてモニタをカプセル化します。OVC は一つ以上のエージェン

トを含むことができます。あるエージェント（例えばマスタもしくはトランスミット・エージェ

ント）は DUT へのトランザクションを開始することができる一方、ほかのエージェント（スレ

ーブもしくはレシーブ・エージェント）はトランザクションのリクエストに応答します。エージ

ェントは再構成可能で、能動的(active)にも受動的にもなることができるようにしなければなりま

せん。能動的なエージェントはデバイスをエミュレーションしテストの指示に従ってトランザク

ションをドライブします。受動的なエージェントは DUT 活動のモニタだけを行います。

環境

環境（env）は OVC のトップレベルのコンポーネントです。これはバス・モニタのようなほかの

コンポーネントと同様、一つもしくは複数のエージェントを含んでいます。env はコンフィギュ

レーション・プロパティを含みトポロジと動作をカスタマイズして再利用可能とすることができ

ます。例えば能動的なエージェントを、検証環境がシステム検証に再利用されるときに受動的な

エージェントに変えることができます。20 ページの図 2－2 は再利用可能な検証環境の構造を図

示しています。OVC が環境レベルのモニタを含むことができることに注意してください。バス・

レベルのモニタは必ずしも単一のエージェントに関連していないアクティビティ・チェックやカ

バレッジを実行します。エージェントのモニタはグローバル・モニタによって収集されたデータ

20

やイベントを強化することができます。 環境クラス（ovm＿env）は柔軟で、再利用可能で拡張可能な検証コンポーネントを提供するよう

にアーキテクチャが構成されています。環境クラスの主要な機能は制約付のランダム・トラフィ

ックを生成し、DUT の応答をモニタし、プロトコルのアクティビティの有効性をチェックし、カ

バレッジを収集することにより動作をモデル化することです。 今あるクラスをそれらの特定のプロトコルに特化するために派生物（derivation）を使うことが

できます。このマニュアルは今あるコンポーネントの動作を IP 特有の動作に置き換えるために

OVM が提供するプロセスとインフラストラクチャを記述しています。 図 2－2 典型的な OVC 環境

SystemVerilog OVM Class Library SystemVerilog OVM Class Library は十分に構成され、再利用可能な検証コンポーネントとテス

ト環境をすばやく開発するのに必要なすべてのビルディング・ブロックを提供します（21 ページ

の図 2－3 を参照）。このライブラリはベース・クラス、ユーティリティ、そしてマクロより構成

されています。コンポーネントはカプセル化され階層的にインスタンシエートされ、初期化、実

行、そして各テストを終了するために拡張可能なフェーズのセットを通してコントロールされま

す。これらのフェーズはベース・クラス・ライブラリに定義されていますが、特定のプロジェク

21

トの必要性をみたすために拡張することができます。より詳しくは SystemVerilog OVM Class Reference を参照してください。 図 2－3 （部分的な）OVM Class 階層構造

SystemVerilog OVM Class Library の使用の利点は次のようになります。 • 確立された組み込み機能 ― SystemVerilog OVM Class Library はプリント、コピー、テス

ト・フェーズ、ファクトリ・メソッドやその他の完全な実装を含め検証に必要な多くの機能

を提供します。 • 正しくインプリメントされたOVMの考え方 ― 20ページの図2－2のブロック図にある各コ

ンポーネントは対応する SystemVerilog OVM Class Library コンポーネントから継承されて

います。ページ 21 の図 2－4 は同じダイアグラムを、派生した SystemVerilog OVM Class Library ベース・クラスを使って示されています。これらのベース・クラスのエレメントの使

用は、各コンポーネントの役割がその親のクラスによってあらかじめ定められているためコ

ードの読み易さを高めます。 図 2－4 OVMLibrary Class を用いた典型的な OVM 環境

22

その他の OVM の便利さ

SystemVerilog OVM Class Library はまたさまざまなユーティリティを提供し検証環境の開発と

使用を簡単化します。これらのユーティリティはユーザがコントロールできるメッセージ・ユー

ティリティを提供することによりデバッグのサポートを行います。ユーティリティは検証コンポ

ーネント間の標準的なコミュニケーション・インフラストラクチャ(TLM)や柔軟な検証環境コン

ストラクションを提供することにより開発のサポートを行います。 SystemVerilog OVM Class Library は失敗のレポートや一般的なレポートの目的で使用すること

ができるグローバル・メッセージング・ファシリティを提供します。メッセージとレポートの両

方ともに使い易さの重要な側面です。 このセクションは次のものを含んでいます。 • “OVM ファクトリ” ページ 22 • “トランザクション・レベル・モデリング” ページ 23 OVM ファクトリ このファクトリ・メソッドは古典的なソフトウエア開発のパターンで、生成されるオブジェクト

の正確な仕様をランタイムまで先送りしながら一般的なコードを生成するのに用いられます。機

23

能検証では、クラスのバリエーションが頻繁に必要とされます。例えば、多くのテストで一般的

なデータ・アイテム定義から継承しそれにさらに制約やフィールドを加えたいか、もしくは新し

く派生したクラスを環境全体か、もしくは単一のインタフェースで使いたいかも知れず、もしく

は新しいドライバを導いてデータが DUT に送られる方法を修正しなければならないかもしれま

せん。ファクトリは検証コンポーネントを置き換えるのに、親のコンポーネントの派生バージョ

ンを提供する必要なしにできるようにします。 SystemVerilog OVM Class Library は次のことを可能とする組込みのセントラル・ファクトリを

提供します。 • 環境全体で、もしくは特定のオブジェクトに対しオブジェクトの割付をコントロール • インフラストラクチャ・コンポーネント（例えば、ドライバ）と同様に、スティミュラスの

データ・アイテムを変更 OVM の組み込みファクトリは高度なファクトリを生成したり、クラス定義にファクトリ・メソ

ッドをインプリメントする労力を削減します。これはエンド・ユーザの環境にあるあらかじめ定

義された検証 IP の再利用や調整を促進します。ファクトリの も大きな利点の一つはテスト作成

者にはこの存在が意識されないことであり、開発者とユーザの両方に要求されるオブジェクト指

向の専門知識を削減します。 トランザクション・レベル・モデリング OVM コンポーネントは標準 TLM を通してコミュニケーションを行いますが、これは再利用を促

進します。OVM における TLM の SystemVerilog 実装を使って、コンポーネントはそのインタフ

ェースを通して、そのインタフェースを実装しているほかの全てのコンポーネントとコミュニケ

ーションすることができます。各 TLM インタフェースはデータ転送に使われる一つ以上のメソ

ッドより構成されます。TLM は各メソッドの必要な振る舞い（セマンティック）は指定しますが

実装については定めません。TLM インタフェースを継承するクラスは指定されたセマンティック

をみたす実装を提供しなければなりません。このようにして、一つのコンポーネントは複数レベ

ルの抽象度でインプリメントされたほかのものとトランザクション・レベルで接続することがで

きます。共通の TLM コミュニケーションのセマンティックは環境のほかに影響を与えずにコン

ポーネントを入れ替えることができるようにします。

24

トランザクション・レベル・モデリング

（TLM）

トランザクション・レベル・モデリングの概要 検証の生産性のキーの一つに意味のある抽象レベルで問題を捉えるということがあります。相互

に流れるパケットを取り扱ったり、インストラクションを処理したり、その他の機能を実行する

テスト下のデバイス（DUT）を検証するとき、適切な抽象レベルをサポートする検証環境を作成

しなければなりません。DUT への実際のインタフェースは 終的には信号レベルの動作ですが、

スティミュラスの生成やカバレッジ・データの収集のような検証の作業の大部分は、経験上トラ

ンザクション・レベルで管理する必要があることが示されており、エンジニアがシステムの動作

を考えるときの自然な方法にもなっています。 OVM はトランザクション・レベル・コミュニケーションのインタフェースとチャネルのセット

を提供し、トランザクション・レベルでコンポーネントを接続できるようにします。TLM インタ

フェースは環境全体を通してコンポーネントをほかのコンポーネントの変化から分離します。

OVM の段階的で柔軟な構築物のインフラストラクチャと一緒になって、TLM は同じインタフェ

ースを持つ限りどのコンポーネントもほかのものと入れ替えられることを可能とし、再利用を促

進します。この考え方は DUT のトランザクション・レベル・モデルで環境を構成し、この環境

をデザインが RTL に詳細化されていく間に再利用することを可能とします。必要とされることは

トランザクション・レベル・モデルを互換性のあるコンポーネントのわずかなレイヤで置き換え

トランザクション・レベルのアクティビティと DUT におけるピン・レベルのアクティビティの

間の変換を行わせるだけです。 コンポーネント間の十分に定義された TLM インタフェースのセマンティクスは混在した言語の

検証環境を実現する理想的なプラットフォームも提供します。TLM はコンポーネントを OVM 検

証コンポーネント（OVC）と呼ばれる再利用可能なコンポーネントにカプセル化するインフラス

トラクチャを提供し、再利用を 大化し検証環境を構築するのに必要な時間と労力を 小化しま

す。 この章は OVM におけるトランザクション・レベル・コミュニケーションの基本的なエレメント

を議論し、トランザクション・レベル・コンポーネントを検証環境に組み立てる方法の手順を例

25

示します。このドキュメントの後半で検証のより広い課題に取り組むためにさらに問題を議論し

ます。今はまず 初に基本的な考え方を理解することが重要です。

TLM の基本 トランザクション・レベルで検証をモデル化する方法を完全に理解する前にトランザクションが

何かについて理解しなければなりません。

トランザクション

OVM でトランザクションはクラス・オブジェクト、ovm_transaction（ovm_objectの拡張）

で、2 つのコンポーネントのコミュニケーションの単位をモデル化するのに必要などんな情報も

含んでいます。 も基本的な例では、簡単なバス・プロトコルのトランザクションが次のように

モデル化されます：

class simple_trans extends ovm_transaction;

rand data_t data; rand addr_t addr; rand enum {WRITE,READ} kind;

constraint c1 { addr < 16’h2000; }

... endclass

トランザクション・オブジェクトはトランザクション上で生成し動作するのに必要な変数、制約、

そしてほかのフィールドやメソッドを含んでいます。明らかにバス・トランザクションを完全に

定義するためにはこれ以上の情報がしばしば必要となります。トランザクションの中にカプセル

化された情報の量と詳細度がモデルの抽象度レベルを表しています。例えば上の simple_trans

トランザクションで、挿入される wait 状態の数、転送のサイズやほかの任意のプロパティのよう

な更なる情報を含むように拡張することができます。トランザクションはまた追加の制約を含む

ように拡張することができます。またいくつかの低位レベルのトランザクションを含む高位レベ

ルのトランザクションを定義することもできます。トランザクションはこのようにして構成し、

分解し、拡張し、レイヤ化し、そうでなければ操作して、任意の抽象度で必要とされるどんなコ

ミュニケーションもモデル化できます。

26

トランザクション・レベル・コミュニケーション

トランザクション・レベルのインタフェースはトランザクション・オブジェクトを引数として使

うメソッドの集まりを定義します。TLM port は特定の接続に用いられるメソッド（API）の集合

を定義し、一方 TLM export はこれらのメソッドの実装を供給します。port を export に接続する

ことで port メソッドがコールされたときこの実装が実行されます。

基本の TLM コミュニケーション

図 3－1 簡単なプロデューサ/コンシューマ

も基本的なトランザクション・レベルのオペレーションは一つのコンポーネントがトランザク

ションをほかに put できるようにすることです。26 ページの図 3－1 を考えます。 プロデューサについている正方形は port を意味し、コンシューマについている丸は export を意

味します。プロデューサはトランザクションを生成し、put_port からそれらを送信します。

class producer extends ovm_component;

ovm_blocking_put_port #(simple_trans) put_port; // 1 parameter

function new( string name, ovm_component parent); put_port = new(“put_port”, this);

...

endfunction

virtual task run(); simple_trans t; for(int i = 0; i < N; i++) begin // Generate t. put_port.put(t); end endtask

注意：ovm_*_portはコミュニケートされるトランザクション・タイプによってパラメータ化さ

れています。これは直接指定されるか、親のコンポーネントのパラメーのいずれかです。

27

put ()コールの実際の実装はコンシューマによって提供されます。

class consumer extends ovm_component;

ovm_blocking_put_imp #(simple_trans, consumer) put_export; // 2 parameters

...

task put(simple_trans t); case(t.kind) READ: // Do read. WRITE: // Do write. endcase endtask endclass

注意：ovm_*_imp はトランザクションのタイプと、メソッドの実装を宣言するオブジェクトのタ

イプの 2 つのパラメータを取ります。 注意：put オペレーションのセマンティックスは TLM によって定義されます。このケースで、プ

ロデューサの put()コールはコンシューマの put実装が終わるまでブロックします。それ以外は

producer のオペレーションは put の実装(ovm_put_imp)から完全に独立しています。実際

consumerは putをインプリメントしているほかのコンポーネントで置き換えることができ、プ

ロデューサは全く同じ方法で動作を続けます。TLM によって提供されるモジュール構造はインタ

フェースが十分に定義されているためコンポーネントが容易に再利用される環境を育てます。 図 3－2 コンシューマがプロデューサから get

put と逆のオペレーションが get です。ページ 27 の図 3－2 を考えます。 このケースで、コンシューマは get_port を通してプロデューサからトランザクションを要求しま

す。

class get_consumer extends ovm_component;

ovm_blocking_get_port #(simple_trans) get_port;

28

function new( string name, ovm_component parent); get_port = new(“get_port”, this);

...

endfunction

virtual task run(); simple_trans t; for(int i = 0; i < N; i++) begin // Generate t. get_port.get(t); end endtask

get()実装がプロデューサによって供給されます。

class get_producer extends ovm_component;

ovm_blocking_get_imp #(simple_trans, get_producer) get_export;

...

task get(output simple_trans t); simple_trans tmp = new(); // Assign values to tmp.

t = tmp; endtask endclass

上の put()のように、get_consumerの get()コールは get_producerのメソッドが終了する

までブロックします。TLM の用語では、put()と get()はブロックするメソッドです。 注意：これら両方の例で、一つのプロセスが実行されており、コントロールが port から exportに渡されふたたびもどされます。データの流れの向き（プロデューサからコンシューマ）は両方

の例で同じです。

プロセス間のコミュニケーション

上の put の基本的な例で、コンシューマは put()メソッドがコールされたときのみアクティブに

なります。多くのケースで、コンポーネントが独立に動作することが必要で、ここではプロデュ

ーサは一つのプロセスでトランザクションを生成し、一方コンシューマは別のプロセスでこれら

のトランザクションで動作する必要があります。OVM はそのようなコミュニケーションを促進

するために tlm_fifoチャネルを提供します。tlm_fifoはすべての TLM インタフェース・メ

ソッドをインプリメントし、29 ページの図 3－3 に示されるようにプロデューサはトランザクシ

ョンを tlm_fifoに入れ、一方コンシューマは独立に fifo からトランザクションを取り出します。

29

図 3－3 tlm_fifo を使って

プロデューサが fifo にトランザクションを入れるとき、fifo が一杯ならばブロックし、そうでな

ければ fifo にオブジェクトを入れ直ちに戻ります。 get オペレーションはトランザクションが利

用可能であれば直ちに戻り（そしてそれは fifo から取り除かれます）、そうでなければトランザク

ションが利用可能となるまでブロックします。このようにして 2 つの連続した get()コールはコ

ンシューマに対し異なるトランザクションを作り出します。関連する peek()メソッドは利用可

能なトランザクションを取り除かずにそのコピーを返します。2 つの連続した peek()コールは同

じトランザクションのコピーを返します。

ブロッキング対ノンブロッキング

今までに見てきたインタフェースはブロッキングです。これはタスクがその終了まで実行をブロ

ックすることを意味します。このタスクは失敗することを許されません。どんなブロッキング・

コールでも異常終了をしたりそうでなければコントロールの流れを変えたりする仕組みはありま

せん。リクエストがみたされるまでただ待つだけです。時間が測られているシステムでは、これ

はコールに起動がかかった時刻からコールが戻ってくるまでの間、時間が経過することを意味し

ます。 これと対照的にノンブロッキングのコールは直ちに戻ってきます。ノンブロッキングのセマンテ

ィクスはコールが、それが出されたときと同じデルタ・サイクルで、すなわち時間を消費せずに、

１デルタ・サイクルも消費せずに戻ってくることを保証します。OVM ではノンブロッキング・

コールはファンクションとしてモデル化されます。

class consumer extends ovm_component;

ovm_get_port #(simple_trans) get_port;

task run; ... for(int i=0; i<10; i++) if(get_port.try_get(t)) //Do something with t.

30

... endtask

endclass

もしトランザクションが存在すると、それは引数に返され、ファンクション・コールそのものは

TRUE を返します。もしトランザクションが存在しないと、ファンクションは FALSE を返しま

す。try_peek()も同様です。try_put()メソッドはもしトランザクションが送られると TRUEを返します。

トランザクション・レベル・コンポーネントの接続

トランザクション・レベル・コンポーネントに定義されたポートとエクスポートを使って、それ

らの間の実際の接続が親（コンポーネントか env）の connect()メソッドを通し達成され、接続

されるオブジェクト（ポートもしくはエクスポート）が引数になります。検証環境で、ポートと

エクスポートの間の一連の connect()コールはピア・ツー・ピアや階層的接続のネットリストを

確立し、 終的には合意したインタフェースの実装で終ります。これらの接続の解決はネットリ

ストの折り畳みを引き起こし、イニシエータのポートがターゲットの実装にアサインされる結果

になります。そのため、コンポーネントが次をコールすると put_port.put(t);

接続はこれが実際は次をコールすることを意味し target.put_export.put(t);

ここで targetは接続されるコンポーネントです。

ピア・ツー・ピア 接続

コンポーネントを階層の同じレベルで接続するとき、ポートは常にエクスポートに接続されます。

コンポーネント間の全ての connect()コールは親の connect()メソッドで行われます。

class my_env extends ovm_env;

...

virtual function void connect();

31

// component.port.connect(target.export);

producer.blocking_put_port.connect(fifo.put_export);

get_consumer.get_port.connect(fifo.get_export);

... endfunction

endclass

ポート／エクスポートの互換性

OVM の TLM コミュニケーションのもう一つの利点はすべての TLM 接続はテスト実行の前に互

換性がチェックされるということです。接続が有効であるためには、エクスポートは少なくとも

ポートで定義されているメソッドのセットの実装を提供し、2 つのトランザクション・タイプの

パ ラ メ ー タ は 同 じ で な け れ ば な り ま せ ん 。 例 え ば 、 put()の 実 装 を 必 要 と す る

blocking_put_portは blocking_put_exportか put_exportに接続することができます。

どちらも put()の実装を供給しますが、put_export はさらに try_put()と can_put()の実

装も提供します。

カプセル化と階層 TLM インタフェースの使用は検証環境の各コンポーネントをほかから分離します。環境はコンポ

ーネントをインスタンシエートし、そのポート／エクスポートを特定の実装のさらに詳しい知識

にかかわらず、その近傍と接続します。比較的小さいコンポーネントは階層的にグループ化され

より大きなコンポーネントを構成します（ページ 37 の“再利用可能な Open Verification Component (OVC)”を参照）。子のコンポーネントへのアクセスは親のレベルでそのインタフェ

ースが見られるようにすることで達成されます。このレベルでは、親は内部の実装にかかわらず、

単にそのインタフェースのセットを持つ単一のコンポーネントのように見えます。

階層的接続

階層の境界をまたがって接続を作ることはこのセクションで議論されるようにさらなる課題をも

たらします。ページ 32 の図 3－4 に示される階層設計を考えます。 図 3－4 TLM の階層

32

このデザインの階層は producer と consumer の２つのコンポーネントを含んでいます。

producerは gen、 fifo、 convの 3 つのコンポーネントを含み、consumerは fifo、 driver

の 2 つのコンポーネントを含んでいます。トップからの観点では、ページ 26 の図 3－1 のものと

同じように見え、ここでプロデューサの put_port がコンシューマの put_export に接続され

ています。２つの FIFO はどちらも同じ tlm_fifoコンポーネントのユニークなインスタンスで

す。 32 ページの図 3－4 で、A,B, D,F の接続は上で議論した標準のピア・ツー・ピア接続です。例と

して接続 A はプロデューサの connect()メソッドの中で次のようにコーディングされます。 get.put_port.connect(fifo.put_export);

C と E の接続は今までに示されたものとは異なる種類のものです。接続 C はポート・ツー・ポー

ト接続で、接続 E はエクスポート・ツー・エクスポート接続です。これら 2 種類の接続は階層構

造の接続を完成させるために必要です。接続 C は外側のコンポーネントから内側のコンポーネン

トにポートを import します。接続 E はエクスポートを内側のコンポーネントから外側のものに

階層を上位方向に export します。 終的には全てのトランザクション・レベルの接続はポートが

エクスポートに接続されるように解決されなければなりません。しかし、ポートとエクスポート

端子は階層で同じレベルにある必要はありません。ポート・ツー・ポートとエクスポート・ツー・

エクスポート接続を使いコネクタを階層の境界まで持ってきて階層の次の上位レベルからアクセ

スするようにします。 接続 E は、実装は fifo にあり、コンシューマのインタフェースまでエクスポートされます。親の

コンポーネントの全てのエクスポート・ツー・エクスポート接続は次の形を取ります。 export.connect(subcomponent.export)

そのため接続 E は次のようにコーディングされます。

33

class consumer extends ovm_component; ovm_put_export #(trans) put_export; tlm_fifo #(trans) fifo; ...

function void connect(); put_export.connect(fifo.put_export); // E bfm.get_port.connect(fifo.get_export); // F endfunction

... endclass

逆にポート・ツー・ポート接続は次の形を取ります。 subcomponent.port.connect(port);

そのため、接続 C は 次のようにコーディングされます。

class producer extends ovm_component; ovm_put_port #(trans) put_port; conv c; ...

function void connect(); c.put_port.connect(put_port); ... endfunction

次のテーブルは接続のタイプとエラボレーション・ファンクションをまとめています。 接続タイプ Connect()フォーム

ポート・ツー・エクスポート Comp1.port.connect(comp2.export);

ポート・ツー・ポート Subcomponent.port.connect(port);

エクスポート・ツー・エクスポート Export.connect(subcomponent.export);

注意：port.connect()メソッドの引数はエクスポートかポートのいずれかで接続の性質により

ます（すなわちピア・ツー・ピアまたは階層的）。export.connect()の引数は常に子のコンポ

ーネントのエクスポートです。

アナリシスコミュニケーション 上で述べられた put/get コミュニケーションはシステムの“動作的な”振る舞いをモデル化する

34

検証コンポーネントを作り出せるようにします。各コンポーネントは TLM インタフェースを通

してシステムのほかのコンポーネントとコミュニケーションを行い DUT のアクティビティに起

動をかけたりその動作に応答したりする役割を持っています。十分に複雑な環境で、特にランダ

ム化が適用されている場合、収集されたトランザクションは隅々までチェックしたり（スコアボ

ード）、更なるカバレッジ収集のために環境のほかのところへ分配されなければなりません。 2 つのタイプの TLM コミュニケーションのキーとなる違いは put/get ポートは通常実装を供給す

る、対応するエクスポートを必要とします。アナリシスには、しかしながら、重点はモニタのよ

うな特定のコンポーネントで、トランザクションのストリームを生成できるかであり、それに実

際接続されているターゲットがあるかどうかには関係ありません。モジュール化されたアナリシ

スコンポーネントは analysis_port に接続され、それらおのおのは特定の方法でトランザクショ

ンのストリームを処理します。

アナリシスポート

ovm_analysis_port（35 ページ図 3－5 のモニタにあるダイアモンドのマークで表されている）

は特別な TLM ポートで、そのインタフェースは一つのファンクション write()から成り立って

います。アナリシスポートはそれに接続されている analysis_exports のリストを含んでいま

す。コンポーネントが analysis_port.write()をコールすると、analysis_port はリスト

を循環的に調べおのおの接続されているエクスポートの write()メソッドをコールします。もし

何も接続されていないと、write()のコールは単に帰ってくるだけです。このようにしてアナリ

シスポートは 0、1 つ、または多くのアナリシエクススポートに接続できますが、アナリシスポー

トに書き込むコンポーネントのオペレーションは接続されているエクスポートの数には依存しま

せん。write()は void ファンクションであるため、コールは常に同じデルタ・サイクル内で完了

し、接続されているコンポーネント（例えばスコアボード、カバレッジ・コレクタ、など）の数

には依存しません。 図 3－5 アナリシスコミュニケーション

35

class get_ap_consumer extends get_consumer; ovm_analysis_port #(my_trans) ap; function new(...); super.new() ap = new(“analysis_port”, this); ... endfunction

task run; ... for(int i=0; i<10; i++) if(get_port.try_get(t)) begin //Do something with t. ap.write(t); // Write transaction. ... end endtask

親の環境で、アナリシスポートは希望するコンポーネント、例えばカバレッジ・コレクタやスコ

アボードなど、のアナリシスエクスポートに接続がつけられます。

アナリシエクススポート

ほかの TLM 接続については、write()の実装を、analysis_export を通して提供することは、ア

ナリシスポートに接続されている各コンポーネントによります。OVM はこのオペレーションを

簡単にするため ovm_subscriber ベース・コンポーネントを提供し、そのため通常の解析コン

ポーネントは次のように ovm_subscriberを拡張します。

class sub1 #(type T = simple_trans) extends ovm_subscriber #(T); ... function void write(T t); // Record coverage information of t. endfunction

endclass

上に述べられた put()と get()に関しては、アナリシスポートとエクスポート間の TLM 接続が、

write()の実装を export が供給できるようにします。もし複数のエクスポートがアナリシスポー

トに接続されているならば、ポートは各エクスポートの write()を順にコールします。全ての

write()の実装はファンクションでなければならないため、アナリシスポートの write()ファン

クションは直ちに終了し、それにいくつのエクスポートが接続されているかにはよりません。

class my_env extends ovm_env; get_ap_component g;

36

sub1 s1; sub2 s2;

...

function void connect(); g.ap.connect(s1.analysis_export); g.ap.connect(s2.analysis_export); ... endfunction

endclass

複数のサブスクライバが analysis_port に接続されているとき、おのおのは write()コールの引

数の、同じトランザクション・オブジェクトへのポインタを渡されます。各 write()実装は同じ

ポインタを受け取ったほかのサブスクライバのトランザクションの内容を壊さないように、トラ

ンザクションのローカル・コピーを作りそのコピーで作業するようにしなければなりません。 OVM はまた analysis_fifo を含んでいますが、これは tlm_fifo で、アナリシエクススポートも含

み、ブロッキング・コンポーネントが解析のトランザクション・ストリームにアクセスできるよ

うにします。analysis_fifo は制限がなく、モニタの write()コールは直ちに成功することが保障

されています。アナリシスコンポーネントは都合の良いときに analysis_fifo からトランザクショ

ンを取り出します。

37

再 利 用 可 能 な Open Verification Component (OVC)の開発 この章は典型的な検証環境を作り上げる基本的な考え方とコンポーネントについて説明します。

さらにこれらのコンポーネントを実証された階層構造を使って結合し、再利用可能な OVC を作

成する方法についても示しています。この章のセクションは OVC を開発するにあたってたどる

手順と同じ順序に従っています。 • “生成のためのデータ・アイテムのモデル化” 37 ページ • “トランザクション・レベルのコンポーネント” 41 ページ • “ドライバの生成” 44 ページ • “シーケンサの生成” 45 ページ • “モニタの作成” 50 ページ • “コンポーネントのインスタンシエーション” 53 ページ • “エージェントの作成” 54 ページ • “環境の作成 ” 57 ページ • “シナリオの生成を可能とする ” 60 ページ • “チェックとカバレッジの実装” 70 ページ 注意：この章は 14 ページの“OVM 概要”と 24 ページの“トランザクション・レベル・モデリ

ング（TLM）”に述べられた考え方をもとに構築されています。

生成のためのデータ・アイテムのモデル化 データ・アイテムは： • テスト下のデバイス（DUT）へのスティミュラスとして使われるトランザクション・オブジ

ェクトです。 • 検証環境で処理されるトランザクションを表現します。 • ユーザの定義するクラス（“user-defined”クラス）です。 • トランザクション・レベルのカバレッジとチェックを捉えて測定します。 注意：SystemVerilog OVM Class Library は ovm_sequence_itemベース・クラスを提供しま

38

す。全てのユーザ定義のデータ・アイテムはこのベース・クラスを直接または間接的に継承しな

ければなりません。 ユーザ定義のデータ・アイテムの作成のために：

1. DUT のトランザクション仕様をレビューし応用分野特有のプロパティ、制約、タスク、

ファンクションを特定します。 2. ovm_sequence_itemベース・クラス（もしくはその派生物）からデータ・アイテム・

クラスを求めます。 3. データ・アイテムのコンストラクタを定義します。 4. ステップ 1 で特定されたアイテムにコントロール・フィールド（“ノブ”）を加えテスト

の作成を容易にします。 5. プリント、コピー、比較などが可能となるように OVM のフィールド・マクロを使いま

す。

OVM はデータ・アイテムが必要とする多くのサービス・ルーチンのための組み込みのオートメ

ーションを持っています。例えば、次のものが使えます。 • データ・アイテムをプリントするための print() • データ・アイテムの内容をコピーするための copy() • 2 つの同様なオブジェクトを比較するための compare() OVM により各フィールドに必要なオートメーションを指定することができ、組み込みで、使い

込まれた、一貫性のあるこれらのルーチンの実装を使うことができるようになります。 トランザクションのデバッグとトラッキングをサポートするために ovm_transaction ベー

ス・クラスは m_transaction_idフィールドを含んでいます。さらに、ovm_sequence_item

ベース・クラス（ovm_transactionから拡張されています）はまた m_sequence_idフィール

ドを含んでおり、シーケンス・アイテムを、それを 初に生成したシーケンスに関連付けられる

ようにします。これは双方向のプロトコルにおいてシーケンサが応答のトランザクションを正し

いシーケンスに戻せるようにするため必要です。 この例の simple_item クラスはいくつかのランダムの変数とクラスの制約を定義しています。

OVM マクロがコピー、比較、プリントなどのこのクラスに作用するいろいろなユーティリティ

を実現しています。特に`ovm_object_utilsマクロはクラス・タイプを共通のファクトリに登

録します。

39

1 class simple_item extends ovm_sequence_item;

2 rand int unsigned addr;

3 rand int unsigned data;

4 rand int unsigned delay;

5 constraint c1 { addr < 16'h2000; }

6 constraint c2 { data < 16'h1000; }

7 // OVM automation macros for general objects

8 `ovm_object_utils_begin(simple_item)

9 `ovm_field_int(addr, OVM_ALL_ON)

10 `ovm_field_int(data, OVM_ALL_ON)

11 `ovm_field_int(delay, OVM_ALL_ON)

12 `ovm_object_utils_end

13 // Constructor

14 function new (string name = "simple_item");

15 super.new(name);

16 endfunction : new

17 endclass : simple_item 1 行目 ovm_sequence_itemからデータ・アイテムを継承し、プロシージャ・シーケンスで生

成されるようにします。詳しくは 62 ページの“シーケンスとシーケンス・アイテムを使ってステ

ィミュラスの生成”を参照してください。 5－6 行目 以下のためにデータ・アイテム定義に制約を加えます。 • 仕様のルールを反映させるため。この例ではアドレスは16’h2000以下でなければなりません。 • トラフィックを生成するためにデフォルトの分布を指定するため。例えば、通常のテストで

はほとんどのトランザクションは正常のはずです。 7－12 行目 OVM マクロを使って copy()、compare()、print()、pack()などのファンクシ

ョ ン を 自 動 的 に イ ン プ リ メ ン ト し て い ま す 。 `ovm_object_utils_begin 、

`ovm_object_utils_end 、 `ovm_field_* や そ れ ら に 付 随 す る マ ク ロ の 情 報 は

SystemVerilog OVM Class Reference の OVM Macro を参照してください。 注意：OVM は検証環境の開発を簡単化するための組み込みマクロを提供します。マクロは

copy()、compare()、print()、pack()などのベース・クラスに定義されているファンクシ

ョンの実装を自動化し、これによって多くの行のコードを節約します。これらのマクロの使用は

オプションですが推奨しています。

40

継承と制約のレイヤ化

検証のゴールに達するため、OVC ユーザはクラス定義にさらに制約を加えてデータ・アイテム生

成を調節する必要があるかもしれません。SystemVerilog では、これは継承を用いて行います 次の例は word_aligned_item という派生したデータ・アイテムを示しており、これはワード単位

に整列するアドレスを選択するように追加の制約が加えられています。

class word_aligned_item extends simple_item; constraint word_aligned_addr { addr[1:0] == 2'b00; } `ovm_object_utils(word_aligned_item) // Constructor function new (string name = "word_aligned_item"); super.new(name); endfunction : new endclass : word_aligned_item

このタイプの拡張性を有効にするために： • データ・アイテム（この章では simple_item）のベース・クラスは派生したクラスが機能を上

書きできるようバーチャル・メソッドを使うべきです。 • 制約のブロックが大きなブロックを書き直す必要なしに、ランダム変数の制約を上書きする

か、無効にできるように構成されていることを確認します。 • ユーザによって制約されるかもしれないプロパティへのアクセスを制限するために、

protected もしくは local のキーワードを使わないようにします。これはそれらのプロパ

ティを直列の制約で制約をかける機能を制限します。

コントロール・フィールド（“ノブ（Knob）”）の定義

入力空間の全ての値を生成することは多くのケース不可能でまた通常必要ありません。しかし、

値のレンジもしくはカテゴリからいくつかのサンプルを生成できるようにすることは重要です。

上のページ 37 の“生成のためのデータ・アイテムのモデリング”にある simple_item の例で

は delay のプロパティはゼロと符号なしの 大整数の間でランダム化することができるかもしれ

ません。有効な値の空間全体をカバーすることは必要ではありません（実用的でもありません）

が、連続のアイテムに対しその間で短い、中程度、大きな遅延とこれらの全ての組み合わせを試

すのは重要です。これを行うために、コントロール・フィールドを定義し（しばしば“ノブ（knob）”と呼ばれます）テスト作成者がこれらの変数をコントロールできるようにします。これらの同じ

コントロール・ノブはカバレッジの収集にも使うことができます。読み易さのために事前列挙タ

イプ(enumerate type)を、いろいろ生成されたカテゴリを表現するために使います。

41

ノブの例

typedef enum {ZERO, SHORT, MEDIUM, LARGE, MAX} simple_item_delay_e;

class simple_item extends ovm_sequence_item; rand int unsigned addr; rand int unsigned data; rand int unsigned delay; rand simple_item_delay_e delay_kind; // Control field // OVM automation macros for general objects `ovm_object_utils_begin(simple_item) `ovm_field_int(addr, OVM_ALL_ON) `ovm_field_enum(delay_kind, simple_item_delay_e, OVM_ALL_ON) `ovm_object_utils_end

constraint delay_order_c { solve delay_kind before delay; } constraint delay_c { (delay_kind == ZERO) -> delay == 0; (delay_kind == SHORT) -> delay inside { [1:10] } (delay_kind == MEDIUM) -> delay inside { [11:99] } (delay_kind == LONG) -> delay inside { [100:999] } (delay_kind == MAX ) -> delay == 1000; delay >=0; delay <= 1000; }

endclass : simple_item

これらの手法を使うことにより、より抽象度の高いテストを作成できるようになります。例えば

次のような分布を指定することができます。

constraint delay_kind_d {delay_kind dist {ZERO:=2, SHORT:=1, MEDIUM:=1, LONG:=1, MAX:=2};}

データ・アイテムを作成しているとき、どの値のレンジがよく使われるか、どのカテゴリがその

データ・アイテムにとって興味があるかいつも気に留めておくようにしてください。そしてノブ

をデータ・アイテムに追加し、データ・アイテム・カテゴリーのコントロールとカバレッジを簡

単化します。

トランザクション・レベル・コンポーネント ページ 25 の“トランザクション・レベルのモデリング”で議論したように、OVM の TLM イン

タフェースは、コンポーネント間でトランザクションを送信したり受信する、一貫性のあるコミ

ュニケーション手法のセットを提供します。コンポーネント自体はテストベンチでインスタンシ

42

エートされて接続され、デザインを検証するために必要ないろいろなオペレーションを行うよう

になっています。簡単化されたテストベンチがページ 42 の図 4－1 に示されています。 図 4－1 簡単化されたトランザクション・レベルのテストベンチ

簡単なトランザクション・レベルの検証環境で、基本コンポーネントは次のようになります。

１）DUT にトランザクション・レベルのトラフィックを生成するためのスティミュラス・ジ

ェネレータ（シーケンサ） ２）DUT インタフェースでこれらのトランザクションを信号レベルのスティミュラスに変

換するドライバ ３）DUT インタフェースで信号レベルのアクティビティを認識しトランザクションに変換

するモニタ ４）トランザクションを解析するためにカバレッジ・コレクタまたはスコアボードのような

解析コンポーネント 今まで見てきたように、OVM での TLM インタフェースの一貫性とモジュール構造により、ある

コンポーネントはほかのコンポーネントが置き換えられたり、カプセル化されても再利用が可能

となります。全てのコンポーネントは内部の実装にはかかわらずそのインタフェースで特徴付け

43

られています。この章はさらに再利用を促進するために、コンポーネントのこれらのタイプをど

のように実証されたアーキテクチャ、すなわち OVC、にカプセル化するかを議論します。 図 4－2 高度に再利用可能な OVC エージェント

ページ 43 の図 4－2 は、個々のコンポーネントを再利用可能なインタフェース・レベル OVC エ

ージェントにまとめる、推奨するグループ化を示しています。個々に低位レベルのクラスを再利

用する代わりに、開発者は一貫した方法でサブクラスをカプセル化するコンポーネントを生成し

ます。一貫性のあるアーキテクチャを推進することはこれらのコンポーネントを習得し、採用し、

44

再構成することをより容易にします。

ドライバの生成 ドライバの役割はインタフェース・プロトコルに続きデータ・アイテムをバスにドライブするこ

とです。ドライバは実行のためにデータ・アイテムをシーケンサから受け取ります。SystemVerilog OVC Class Library は ovm_driverベース・クラスを提供し、これからすべてのドライバ・クラ

スは直接または間接的に拡張されます。ドライバは run()メソッドを持ちこれはその動作を定義

すると同様にシーケンサとコミュニケーションをとるための TLM ポートを定義します。（以下の

例参照） ドライバを生成するために： 1． ovm_driverベース・クラスからドライバを継承します。 2． もし望むならば、クラス・プロパティに OVM インフラストラクチャ・マクロを加えプリン

ト、コピー、比較などのユーティリティをインプリメントします。 3． シーケンサから次のデータ・アイテムを受け取り、上で概観したように実行します。 4． ドライバでバーチャル・インタフェースを宣言しドライバを DUT と接続します。 シーケンサ、ドライバ、そしてシーケンスがどのようにお互いに同期を取って制約付のランダム

データを生成するかはページ 60 の“シーケンスとシーケンス・アイテムでスティミュラスの生成”

を参照してください。 下の例のクラス simple_driver はドライバ・クラスを定義しています。この例は

simple_driveを ovm_driver（simple_itemトランザクション・タイプを使うためにパラメ

ータ化されています）から継承し、シーケンサとコミュニケーションするために seq_item_port

オ ブ ジ ェ ク ト の メ ソ ッ ド を 使 っ て い ま す 。 い つ も の よ う に コ ン ス ト ラ ク タ と

`ovm_component_utilsマクロを含み、ドライバ・タイプを共通ファクトリに登録します。

1 class simple_driver extends ovm_driver #(simple_item);

2 simple_item s_item;

3 virtual dut_if vif;

4 // OVM automation macros for general components

5 `ovm_component_utils(simple_driver)

6 // Constructor

7 function new (string name = "simple_driver", ovm_component parent);

8 super.new(name, parent);

45

9 endfunction : new

10 task run();

11 forever begin

12 // Get the next data item from sequencer (may block).

13 seq_item_port.get_next_item(s_item);

14 // Execute the item.

15 drive_item(s_item);

16 seq_item_port.item_done(); // Consume the request.

17 end

18 endtask : run

19

20 task drive_item (input simple_item item);

21 ... // Add your logic here.

22 endtask : drive_item

23 endclass : simple_driver 1 行目 ドライバを継承します。 5 行目 OVM インフラストラクチャ・マクロを追加します。 13 行目 get_next_item()をコールし実行のためにシーケンサから次のデータ・アイテムを入

手します。 16 行目 現在のデータ・アイテムの実行が終了したことをシーケンサに知らせます。 21 行目 特定用途向けのロジックをここで加え、データ・アイテムを実行します。 更なる柔軟性がドライバとシーケンサの間の接続にあり、これは 47 ページの“ドライバとシーケ

ンサの接続”を参照してください。

シーケンサの生成 シーケンサはスティミュラス・データを生成しそれを実行のためにドライバに送ります。

SystemVerilog OVMClass Libraryはovm_sequencerベース・クラスを提供し、これはrequest

と responseアイテム・タイプによってパラメータ化されています。全てのシーケンサ・クラス

はこのクラスから直接もしくは間接的に継承しなければなりません。 シーケンサを作成するために： 1． ovm_sequencerベース・クラスからシーケンサを継承し、requestと responseのタイ

プ・パラメータを指定します。 2． `ovm_sequencer_utils と`ovm_update_sequence_lib_and_item を使い、生成さ

46

れたデータ・アイテムのタイプと望むオートメーションを選びます。 これが基本的なシーケンサの振る舞いを定義する全てです。シーケンサ、ドライバそしてシーケ

ンスがお互いにどのように同期を取り、制約付のランダムデータを生成するかは、60 ページの“シ

ーケンスとシーケンス・アイテムを使ったスティミュラスの生成”を参照してください。 下の例の simple_sequencer クラスはシーケンサ・クラスを定義しています。例はこれを

ovm_sequencerから求め、simple_itemタイプを使うためにパラメータ化しています。

class simple_sequencer extends ovm_sequencer #(simple_item); // OVM automation macro for sequencers `ovm_sequencer_utils(simple_sequencer) // Constructor function new (string name="simple_sequencer", ovm_component parent); super.new(name, parent); `ovm_update_sequence_lib_and_item(simple_item) endfunction : new endclass : simple_sequencer

注意： • クラスの定義ではデフォルトで response タイプと request タイプは同じになっています。も

し異なる response タイプがほしいならば ovm_sequencer ベース・タイプにオプションの 2番目のパラメータを指定しなければなりません。

class simple_sequencer extends ovm_sequencer #(simple_item, simple_rsp);

• `ovm_component_utils マクロはここで使うべきではありません。その機能は

`ovm_sequencer_utilsに組み込まれているからです。`ovm_component_utilsを使う

代わりに`ovm_sequencer_utils を使い、このマクロがシーケンサ特有のインフラストラ

クチャに提供する通常の一般的なマクロも同様です。さらに詳しくは SystemVerilog OVM Class Reference の OVM マクロを参照してください。

• シーケンサ・クラスのコンストラクタから`ovm_update_sequence_lib_and_item マク

ロをコールします。このマクロは現在のシーケンサに関連する全てのシーケンス・タイプを

登録し、シーケンサの生成されたトランザクション・タイプをパラメータと指示します。さ

らに詳しくは SystemVerilog OVMClass Reference の中の OVM マクロを参照してください。

ドライバとシーケンサの接続

47

ドライバとシーケンサは TLM を通して接続され、ドライバの seq_item_port がシーケンサの

seq_item_export に接続されます（下の 47 ページの図 4－3 を参照）。シーケンサはデータ・

アイテムを生成し export を通して提供します。ドライバは seq_item_port を通してデータ・

アイテムを使い、オプションで response を返します。ドライバとシーケンサのインスタンスを含

むコンポーネントがそれらの間の接続を作ります。下の 54 ページの“エージェントの生成“を参

照してください。 図 4－3 シーケンサとドライバのやり取り

ovm_driverの seq_item_portが、ドライバがシーケンスの次のアイテムを取り込むために使

うメソッドのセットを定義します。このやり取りの中の重要な部分はバスとの同期化と、データ・

アイテムを生成するために適切なタイミングでシーケンサとやり取りをするドライバの能力です。

シーケンサはメソッドのセットをインプリメントし、ドライバとシーケンサの間の柔軟でモジュ

ール化したやり取りを可能とします。 基本的なシーケンサとドライバのやり取り ドライバとシーケンサの間の基本的なやり取りは get_next_item() と item_done()のタス

クを使って行われます。ページ 44 の“ドライバの生成”の例で例示されたように、ドライバは送

られるランダム化された次のアイテムを取り込むのに get_next_item()を使います。それを

DUT に送った後、ドライバはシーケンサに対し item_done()を使ってアイテムが処理されたこ

とを知らせます。一般にドライバの中のループは次の疑似コードに似ています。

get_next_item(req);

// Send item following the protocol.

48

item_done();

注意：get_next_item()はブロッキングです。 ランダム化されたアイテムの問い合わせ get_next_item()タスクに加え ovm_seq_item_pull_port クラスはもう一つのタスク

try_next_item()を提供します。このタスクは実行のためのデータ・アイテムが利用可能でな

ければ同じシミュレーション・ステップで戻ります。DUT がシミュレーションされなければなら

ず、一方意味のあるデータを送ることができないときに、ドライバにアイドルのトランザクショ

ンを実行させるのにこのタスクを使うことができます。次の例は前の例（ページ 44 の“ドライバ

の生成”の中）の run()タスクの修正版を示しており、今度は実行すべき実際のデータがない間

アイドルのトランザクションをドライブするために try_next_item()を使っています。

task run(); forever begin // Try the next data item from sequencer (does not block). seq_item_port.try_next_item(s_item); if (s_item == null) begin // No data item to execute, send an idle transaction. ... end else begin // Got a valid item from the sequencer, execute it. ... // Signal the sequencer; we are done. seq_item_port.item_done(); end end endtask: run

連続したランダム化されたアイテムの取り込み

パイプライン・プロトコルのようなプロトコルでは、ドライバは 初のアイテムが完全に処理さ

れる前にパイプラインをみたすためにいくつかの生成されたアイテムを取り込みます。そのよう

なケースでは、ドライバはシーケンサに応答せずに item_done()をコールします。このような

シナリオではドライバの論理は次の疑似コードのように見えると思われます。

while the pipeline is not empty{ get_next_item(req); fork; logic that sends item to the pipeline

49

join_none; item_done(); for each completed process call{ ... } }

処理されたデータをシーケンサに戻す

あるシーケンスでは、生成される値が前に生成されたデータに対する応答に依存します。デフォ

ルトでドライバとシーケンサの間のデータ・アイテムは参照によってコピーされますが、これは

ドライバがデータ・アイテムに行った変更はシーケンサの内部から見えることを意味します。ド

ライバとシーケンサの間のデータ・アイテムが、値のコピーがされたケースでは、ドライバは処

理された応答をシーケンサに返す必要があります。これを item_done()のオプションの引数を

使って実行するか item_done(rsp);

または ovm_driverにある組み込みのアナリシスポートを使います。 rsp_port.write(rsp);

注意：応答を提供する前に、応答のシーケンスとトランザクションの id を、リクエスト・トラン

ザクションに対応するために、rsp.set_id_info(req)を使ってセットしなければなりません。 上で概要が述べられたドライバとシーケンサ間のコミュニケーションの基本機能より、ドライバ

を作成するために必要なステップが明らかになります。

TLM ベースのドライバを使って

seq_item_portは ovm_driverに組み込まれていますが双方向のポートです。これはまたシー

ケンサからアイテムを要求するための標準の TLM メソッドの get()と peek()と、応答を提供

するための put()も含んでいます。そのため、必ずしも ovm_driver から継承されていないほ

かのコンポーネントがシーケンサと接続しコミュニケーションすることができます。

seq_item_portに関しては、使用するメソッドは望むインタラクションに依存します。

50

// Pause sequencer operation while the driver operates on the transaction. peek(req);

// Process req operation. get(req);

注意：

• peek()はブロッキング・メソッドで、そのためドライバは戻されるアイテムを待

ってブロックするかもしれません。 • get()オペレーションはシーケンサに次のトランザクションに進むよう知らせま

す。これは peek()と同じトランザクションを返すため、トランザクションが無

視されることがあります。

// Allow sequencer to proceed immediately upon driver receiving transaction. get(req);

// Process req operation.

blocking_slave_portを使って応答を提供するためにはドライバは次をコールします。 seq_item_port.put(rsp);

応答は同様に analysis_portを使っても送り返されます。

モニタの作成 モニタはバスから信号情報を抽出しそれをイベントや、struct そしてステータス情報に解釈する

責任を持ちます。この情報は標準の TLM インタフェースやチャネルを通してほかのコンポーネ

ントやテスト開発者に利用可能になります。モニタはドライバのようなほかのコンポーネントに

よって収集されたステート情報に依存するべきではありませんが、モニタはシーケンスやトラン

ザクション id 情報を適切に応答にセットするために、リクエスト特有の id 情報に依存する必要

があるかもしれません。 モニタの機能は、常に必要とされる基本的なモニタリングに限るべきです。これにはプロトコル・

チェック―これは有効にしたり、無効にしたり再構成可能であるべきですが―それにカバレッジ

収集を含めることができます。さらに、スコアボードのようなハイレベルの機能がモニタに加え

て別途インプリメントされるべきです。 もし抽象的なモデルを検証したり、ピン・レベルの機能を加速したいならば、信号レベルの抽出、

51

カバレッジ、チェックと、トランザクション・レベルのアクティビティを分離しなければなりま

せん。アナリシスポートはサブモニタ・コンポーネント間のコミュニケーションを可能としなけ

ればなりません（SystemVerilog OVM Class Reference の”組み込み TLM チャネル“を参照）。 モニタの例 次の例は以下の機能を持つ簡単なモニタを示しています。 • モニタはバーチャル・インタフェース（xmi）を通してバスの情報を収集します。 • 収集されたデータはカバレッジの収集とチェックに用いられます。 • 収集されたデータはアナリシスポート（item_collected_port）にエクスポートされます。 収集の実際のコードはこの例に示されていません。完全な例は xbus_master_monitor.sv の XBusの例にあります。

class master_monitor extends ovm_monitor; virtual bus_if xmi; // SystemVerilog virtual interface bit checks_enable = 1; // Control checking in monitor and interface. bit coverage_enable = 1; // Control coverage in monitor and interface.

ovm_analysis_port #(simple_item) item_collected_port; event cov_transaction; // Events needed to trigger covergroups

protected simple_item trans_collected;

`ovm_component_utils_begin(master_monitor) `ovm_field_int(checks_enable, OVM_ALL_ON) `ovm_field_int(coverage_enable, OVM_ALL_ON) `ovm_component_utils_end

function new (string name, ovm_component parent); super.new(name, parent); cov_trans = new(); cov_trans.set_inst_name({get_full_name(), ".cov_trans"}); trans_collected = new(); item_collected_port = new("item_collected_port", this); endfunction : new

virtual task run(); fork collect_transactions(); // Spawn collector task. join endtask : run

covergroup cov_trans @cov_transaction; option.per_instance = 1; ... // Coverage bins definition endgroup : cov_trans

virtual protected task collect_transactions(); forever begin

52

@(posedge xmi.sig_clock); ...// Collect the data from the bus into trans_collected. if (checks_enable) perform_transfer_checks(); if (coverage_enable) perform_transfer_coverage(); item_collected_port.write(trans_collected); end endtask : collect_transactions

virtual protected function void perform_transfer_coverage(); -> cov_transaction; endfunction : perform_transfer_coverage

virtual protected function void perform_transfer_checks(); ... // Perform data checks on trans_collected. endfunction : perform_transfer_checks

endclass : master_monitor

収集は run()フェーズの 初で起動をかけられるタスク（collect_transaction）で行われま

す。このタスクは無限ループで実行され、バス上にデータが利用可能になったと信号が指示する

とすぐにデータを収集します。 データが利用可能になるとすぐ、その情報を待っているほかのコンポーネントのためにアナリシ

スポート(item_collected_port)に送られます。 カバレッジ収集とチェックはシミュレーション実行時間の性能に影響を与えることがあるため条

件付です。必要のないとき、これらはコンフィギュレーションの仕組みを使い、

coverage_enable もしくは check_enable を 0 にセットして消すことができます。例えば次

のようになります。

set_config_int(“master0.monitor”, “checks_enable”, 0);

もしチェックが有効であれば、タスクは perform_transfer_checksファンクションをコール

し、これは収集されたデータ（trans_collected）に必要なチェックを実行します。もしカバ

レッジ収集が有効ならば、タスクはカバレッジ・サンプリング・イベント(cov_transaction)を出し、これは結果として現在の値の収集を行います。 注意：SystemVerilog はクラスでコンカレント・アサーションを許さないため、プロトコル・チ

ェックを SystemVerilog インタフェースでアサーションを使って行うこともできます。

コンポーネントのインスタンシエーション

53

オブジェクト指向の実施で提供される分離とコンポーネント間の TLM インタフェースは、OVMにおける再利用を促進し、環境を構築するとき非常に大きな柔軟性を可能にします。各コンポー

ネントはほかと独立であるため、与えられたコンポーネントは親の connect()メソッドを変える

必要なしに同じインタフェースを持つ新しいコンポーネントと置き換えることができます。この

柔軟性は OVM のファクトリの使用を通して達成されます。 OVM でコンポーネントをインスタンシエートするとき、そのコンストラクタ（下の太字）をコ

ールするよりはむしろ、

class my_component extends ovm_component; my_driver driver; ...

function build(); driver = new(“driver”,this); ... endfunction

endclass

コンポーネントは create()メソッドを使ってインスタンシエートされます。

class my_component extends ovm_component; my_driver driver; ...

function build(); driver = my_driver::type_id::create("driver",this); ... endfunction

endclass

ファクトリのオペレーションは 117 ページの“組み込みのファクトリとオーバーライド”に説明

されています。type_id::create()メソッドはタイプ特有のスタティック・メソッドでファク

トリから求めるタイプ（このケースでは my_driver）のインスタンスを返します。create()へ

の引数は標準のコンストラクタと同じで、ストリング名と親のコンポーネントです。ファクトリ

の使用は開発者に対し、my_driverから拡張された新しいクラスを派生することを可能とし、フ

ァクトリが my_driver の代わりに拡張されたタイプを返すようにします。このようにして、親

のコンポーネントは親のクラスを変更せずに新しいタイプを使うことができます。 たとえば、ある特定のテストに対し、検証環境のユーザはドライバを変えたいかもしれません。

54

特定のテストに対しドライバを変更するために： 1． ベース・コンポーネントから拡張された新しいドライバを宣言し、求める機能を追加した

り変更を行います。

class new_driver extends my_driver;

... // Add more functionality here.

endclass: new_driver

2． テスト、環境、もしくはテストベンチでファクトリから返されるタイプを上書きします。

virtual function build(); set_type_override_by_type(my_driver::get_type(), new_driver::get_type()); endfunction

ファクトリは特定のインスタンスの生成のためにも同様に新しいタイプが返されることを可能と

します。どちらのケースも、new_driverは my_driverの拡張であり、TLM インタフェースは

同じため、親で定義された接続はそのままです。

エージェントの作成 エージェント（54 ページの図 4－4）は前のセクションで記述されたようにドライバ、モニタ、

そしてシーケンサをインスタンシエートし TLM 接続で接続します。大きな柔軟性をもたらすた

めにエージェントはまたコンフィギュレーションの情報やほかのパラメータの情報を含んでいま

す。29 ページの“エージェント”で議論されたように、OVM は OVC 開発者がデバイスに対し

プロトコル特有のスティミュラスの生成、チェック、そしてカバレッジを提供するエージェント

を作成するように勧めています。バス・ベースの環境でエージェントはマスタもしくはスレーブ

のコンポーネントのモデル化を行います。エージェントは 2 つの基本オペレーション・モードを

持ちます。 • アクティブ・モード ― エージェントはデバイスをシステムの中でエミュレーションし、DUT

信号をドライブします。このモードではエージェントがドライバとシーケンサをインスタン

シエートすることが必要です。モニタもチェックとカバレッジのためにインスタンシエート

されます。 • パッシブ・モード ― エージェントはドライバもシーケンサもインスタンシエートせず受動

的に動作します。モニタだけがインスタンシエートされ再構成されます。このモードはチェ

55

ックとカバレッジ収集だけが求められているときに使います。 図 4－4 エージェント

下の例でクラス simple_agent は推奨された方法でシーケンサ、ドライバそして、モニタをイ

ンスタンシエートしています。コンストラクタを使わずに、OVM build()フェーズがエージェ

ントのサブコンポーネントを再構成し構築するために使われています。コンストラクタと異なり、

バーチャル・ファンクションは制限なしに上書きすることができます。また、コードとしてアロ

ケーションを直接書かずに、create_component()がサブコンポーネントをインスタンシエー

トするために使われます。54 ページの“特定のテストにドライバを変更”の例は extends を用

いて今ある動作をどのように上書きするか例示しています。

1 class simple_agent extends ovm_agent;

2 ovm_active_passive_enum is_active;

3 ... // Constructor and OVM automation macros

4 simple_sequencer sequencer;

5 simple_driver driver;

6 simple_monitor monitor;

7 // Use build() phase to create agents's subcomponents.

8 virtual function void build();

9 super.build()

10 monitor = simple_monitor::type_id::create("monitor",this);

11 if (is_active == OVM_ACTIVE) begin

12 // Build the sequencer and driver.

56

13 sequencer = simple_sequencer::type_id::create("sequencer",this);

14 driver = simple_driver::type_id::create("driver",this);

15 end

16 endfunction : build

17 virtual function void connect();

18 if(is_active == OVM_ACTIVE) begin

19 driver.seq_item_port.connect(sequencer.seq_item_export);

20 end

21 endfunction : connect

22 endclass : simple_agent 注意：与えられたコンポーネントのコンフィギュレーションの上書きをアップデートするために

常に super.build()（9 行目を参照）をコールしなければなりません。これはこのコンポーネ

ントを内部に持つしている上位コンポーネントに対し、このコンポーネントのインスタンス設定

を上書きできる機能を提供するために非常に重要です。 10 行目 モニタが create()を用いて生成されます。 11－25 行目 if 条件が is_active プロパティをテストし、ドライバとシーケンサをこのエー

ジ ェ ン ト で 生 成 す る か ど う か を 決 定 し ま す 。 も し エ ー ジ ェ ン ト が ア ク テ ィ ブ

（is_active=OVM_ACTIVE）に設定されているならば、ドライバとシーケンサが更なる

create()コールを使って生成されます。 シーケンサとドライバはモニタと同じ生成のパターンに従います。 この例は is_active フラグがエージェントのコンフィギュレーション・プロパティとして示さ

れています。コンポーネントのトポロジを決めるどんなコントロール・フラグも定義できます。

環境レベルでこれは num_masters インテジャ、 num_slaves インテジャ、または

has_bus_monitorフラグになるでしょう。それまでに述べられた全てのコントロール・フィー

ルドを使う完全なインタフェースの OVC 例のためにページ 144 の“XBus OVC の例”を参照し

てください。 注意：多重階層のコンポーネントを作成するには build()メソッドから create()をコールする

のが勧められる方法です。 18－20 行目 if 条件が、エージェントがアクティブかどうか見るためにチェックされなければ

ならず、もしそうならばシーケンサとドライバの間の接続は connect()を用いて行われます。

57

コンポーネントの接続に connect()の使用 build が終了した後発生する connect()フェーズがエージェントの内部のコンポーネントを接続

するために使われなければなりません。上の例の 18－20 行目を参照してください。

環境の作成 上で典型的な環境でトランザクション・レベルの検証コンポーネントの基本的なオペレーション

をカバーしたので、このセクションはこれらのコンポーネントを組み合わせて再利用可能な環境

（57 ページの図 4－5）を構築する方法を説明します。このガイドラインに従うことにより、環

境がアーキテクチャ上正しく、ほかの OVC と一貫性があり、再利用可能であることを確認する

ことができます。次に続くセクションは環境のサブコンポーネントをどのように作成し接続する

かを記述します。 図 4－5 典型的な OVM の環境アーキテクチャ

環境クラス

環境クラスが再利用可能なコンポーネントの 上位のコンテナになります。これはその全てのサ

ブコンポーネントをインスタンシエートし再構成しています。ほとんどの検証再利用は環境レベ

ルで行われ、ここでユーザは環境クラスをインスタンシエートしそれとそのエージェントを特定

の検証タスクに再構成します。例えば、ユーザは下に示されているように新しい環境でマスタと

58

スレーブの数を変更する必要があるかもしれません。

class ahb_env extends ovm_env; int num_masters; ahb_master_agent masters[];

`ovm_component_utils_begin(ahb_env) `ovm_field_int(num_masters, OVM_ALL_ON) `ovm_component_utils_end virtual function void build(); string inst_name; super.build(); masters = new[num_masters]; for(int i = 0; i < num_masters; i++) begin $sformat(inst_name, "masters[%0d]", i); masters[i] = xbus_master_agent::type_id::create(inst_name,this); end // Build slaves and other components. endfunction

function void assign_vi(virtual interface ahb_bus ahb_all); // Based on the configuration, assign master, slave, decoder and // arbiter signals. endfunction

function new(string name, ovm_component parent); super.new(name, parent); endfunction : new

endclass

注意：エージェントと同様に、create は環境サブコンポーネントをアロケートするために使わ

れます。これはあとでサブコンポーネントの派生クラスを導入することを可能とします。 ユーザは build()を明示的にコールする必要はありません。SystemVerilog OVM Class Libraryがこれを全ての生成されたコンポーネントに対して行います。全てのコンポーネントの build()

ファンクションが終了すると、ライブラリは各コンポーネントの connect()ファンクションをコ

ールします。子コンポーネント間の全ての接続は親コンポーネントの connect()ファンクション

で行われなければなりません。

OVM のコンフィギュレーションの仕組み

OVC は汎用的にプロトコル検証で用いるために、プロトコル毎に作成されます。OVC は特定の

プロジェクトで必要とされないいろいろな機能や動作モードをサポートするかもしれません。

OVM は標準のコンフィギュレーションの仕組みを提供し、現在のプロジェクトの要求に合わせ

て OVC のコンフィギュレーションを定義することができるようにします。OVC はコンフィギュ

59

レーションを実行中でもビルド・プロセスでも受け取ることができます。ビルドの間にこれを行

うことにより複数のクラスに触らずに環境オブジェクト構造を変更することができるようになり

ます。 ovm_field_*マクロを使って OVM フィールドとして登録されたプロパティは、コンポーネント

の Super.build()メソッドによって自動的にアップデートされます。これらのプロパティは次

にコンポーネントのための build()実行を決定するために使うことができます。 生成されたコンポーネントの build()ファンクションをコールする必要はありません。

SystemVerilog OVM Class Library がユーザによって明示的に build()ファンクションがコー

ルされなかった全てのコンポーネントに対しこれを代わりに行います。しかしもしユーザが必要

とするならば、コンポーネントの build()ファンクションを明示的にコールすることも可能です。 生成されたコンポーネント間の接続はコンポーネントの connect()ファンクションで行われま

す。connect()は build()の後に起こるため、ユーザは環境のトポロジは完全に作成されてい

るとみなすことができます。完全なトポロジで、ユーザは必要な接続を作ることができます。 OVC を再利用可能とする 開発者として、開発している OVC がどのような文脈で使用されるかが分かるときがあります。

そのようなケースのとき、OVC のプロトコルの要求とプロジェクトの要求とを区別するのに注意

を払わなければなりません。OVC の開発に当たってインタフェース・プロトコルのドキュメンテ

ーションのみ使うことが強く勧められます。後で、プロジェクトのドキュメンテーションで実装

をすると役に立つ一般的な機能がないかどうかを調べることができます。例えば、スレーブのデ

バイスをアドレス空間の中でいろいろな場所にあるように再構成することができるはずです。 別の例として、もしプロトコルのフレームでいくつかのビットが予備として定義されているとき、

OVC の中でも予備のままにしなければなりません。これらのビットを特定の実装がどのように使

うか理解する検証のロジックはグローバルな一般コードの外側に定義されるべきです。 開発者として、これらの一般的なパラメータを特定し環境のユーザのためにドキュメント化する

のは非常に重要です。 再構成可能なアトリビュートの作成の方法 アトリビュートを再構成可能とするのは SystemVerilog OVC Class Library が提供する組み込み

60

オートメーションの一部です。copy()、print()、compare()などのためのオートメーション・

マクロを使用することで、これらのアトリビュートをコンフィギュレーションの仕組みに導入し

ます。ページ 57 の“環境クラス”の例で、num_master はコンフィギュレーション・パラメー

タで必要に応じてマスタ・エージェントの数を変更することを可能とします。`ovm_field_int

宣言は既に printing に提供されているため、それを再構成するに当たってさらに何かする必要は

ありません。 例えば、3 つのマスタ・エージェントを得るために次のように指定します。 set_config_int(“my_env”,”num_masters”,3);

これはテストベンチの中のプロシージャ・コードで行うことができます。さらに詳しくは 82 ペー

ジの“OVC コンフィギュレーション”を参照してください。 注意： • パラメータの値は super.build()フェーズで自動的にアップデートされます。これらの値

をアクセスする前に super.build()を確実にコールするようにしてください。 • もしオートメーション・マクロを使いたくないならば、get_config_int()を使ってパラメ

ータのコンフィギュレーション値を取り出すことができます。もし num_masters フィール

ドが上書きされたかに関心があり、オリジナルのコンフィギュレーション値を再度取り出し

たいときにも、これを行うことができます。 • より大きな環境は小さなものを統合することができ、親の環境の必要性にあわせてそれらの

パラメータを再構成することができます。このケースで、もし矛盾するコンフィギュレーシ

ョンの指示があったとき、親の環境からの 初の set_configディレクティブが優先します。

シナリオの生成を可能とする 環境のユーザは与えられた DUT を検証するために多くのテスト・シナリオを生成する必要があ

ります。OVC の開発者は通常 DUT のプロトコルに、より通じているので、開発者は次のことを

行うことによってテスト作成（OVC のユーザによって行われる）を簡略化すべきです。 • データ・アイテム・クラスにノブを置いて宣言型のテスト・コントロールを簡単化します。 • 興味ある再利用可能なシーケンスのライブラリを作成します。 注意：検証環境のユーザはそのシーケンサを再構成することにより環境で生成されたパターンを

コントロールします。

61

• シーケンサにトランザクションのシーケンスを追加します。 • 特定のシーケンスをほかよりも頻繁に使われるようシーケンサを変更します。 • シーケンサのメイン・ループを上書きし、代わりにユーザが定義したシーケンスで開始する

ようにします。 このセクションでは、再利用可能なシーケンスのライブラリを作成する方法とその使用について

記述します。環境のコントロールの方法のさらに詳しい情報は、87 ページの“意味のあるテスト

の作成”を参照してください。

ユーザ定義のシーケンスの宣言

シーケンスはいくつかのデータ・アイテムより作られており、これらシーケンスが一緒になって

興味あるシナリオやデータのパターンを構成します。検証コンポーネントは基本のシーケンスの

ライブラリ（単一データアイテムの代わりに）を含むことができ、これはテスト作成者が起動を

かけられます。このアプローチは共通のスティミュラス・パターンの再利用を高めテストの長さ

を削減します。さらにあるシーケンスはほかのシーケンスを使うことができより複雑なシナリオ

を生成できます。 注意：SystemVerilog OVM Class Library は ovm_sequenceベース・クラスを提供します。全

てのシーケンス・クラスは直接または間接的にこのクラスから継承されなければなりません。 ユーザ定義のシーケンスの作成のために： 1． シーケンスを ovm_sequenceベース・クラスから継承し、request と response のアイテム・

タイプ・パラメータを定義します。下の例で、リクエスト・タイプだけが simple_item

と指定されています。これはレスポンス・タイプも simple_item になるという結果にな

ります。 2． `ovm_sequence_utilsマクロを使いシーケンスを関連するシーケンサ・タイプに関連付

け、いろいろなオートメーション・ユーティリティを宣言します。このマクロはまた

p_sequencer変数を提供し、これはマクロの 2 番目の引数で指定されるタイプのものです。

これは派生したタイプ特有のシーケンサ・プロパティをアクセスできるようにします。 3． シーケンスが実行してほしい特定のシナリオでシーケンスの body タスクをインプリメン

トします。body のタスクで、63 ページの ovm_do と ovm_do_with を使ってデータ・ア

イテムやほかのシーケンスを実行することができます。

62

例 次の例のクラス simple_seq_doは簡単なシーケンスを定義しています。これは ovm_sequence

から継承され`ovm_sequence_utils マクロを使ってこのシーケンスを simple_sequencer

に関連付け、`ovm_object_utilsが提供するいろいろなユーティリティを宣言しています。

class simple_seq_do extends ovm_sequence #(simple_item); rand int count; constraint c1 { count >0; count <50; } // Constructor function new(string name="simple_seq_do"); super.new(name); endfunction // OVM automation macros for sequences `ovm_sequence_utils(simple_seq_do, simple_sequencer) // The body() task is the actual logic of the sequence. virtual task body(); repeat(count) `ovm_do(req) endtask : body endclass : simple_seq_do

シーケンスを定義すると、それはそのシーケンサの内部に登録されシーケンサのデフォルトの生

成ループによって生成されます。̀ovm_sequence_utilsマクロは必要なインフラストラクチャ

を作りこのシーケンスを関連するシーケンス・タイプと結びつけ、いろいろなオートメーション・

ユーティリティを宣言します。このマクロは`ovm_object_utilsマクロ（とその派生物）と似

ていますが 2 番目の引数を取ることが違い、その引数はこのシーケンスが関連付けられるシーケ

ンサのタイプ名です。 注意：` ovm_sequence_utils マクロを使っているとき`ovm_object_util マクロは使えま

せん。`ovm_object_utilの機能は`ovm_sequence_utilsに含まれます。

シーケンスとシーケンス・アイテムでスティミュラスの生成

シーケンスは次のものを定義できるようにします。 • DUT に送られるデータ・アイテムのストリーム • DUT インタフェース上で実行されるアクションのストリーム さらにシーケンスを使って DUT インタフェースと接続のないデータ・アイテムのスタティック

63

なリストを生成するシーケンスを使うことができます。 シーケンスを使って開始 前のセクションは SystemVerilog OVM Class Library を使ってシーケンスとシーケンス・アイテ

ムの生成の基礎を議論しました。このセクションはシーケンスとクラス・ライブラリに提供され

るシーケンス・アイテム・マクロを使ってどのようにスティミュラスを生成するか議論します。 63 ページの図 4－6 と 64 ページの図 4－7 はシーケンス・アイテムとシーケンスが ovm_doマク

ロと一緒に使われたときの完全なフローを示しています。全体のフローは登録されたタイプに対

するファクトリの設定をもとにオブジェクトの割付を含んでおり、登録されたタイプはこのセク

ションでは“creation”と参照されています。生成の後、クラス・プロパティの初期化が来ます。

オブジェクトの処理のバランスはオブジェクトがシーケンスかシーケンス・アイテムかに依存し

ますが、親のシーケンスのコールバックである pre_do()、mid_do()、post_do()とオブジェ

クトのランダム化もコールされますが、図に示されるように各オブジェクト・タイプごとに処理

の異なる点でコールされます。 注意：どのマクロも SystemVerilog のループのコンストラクトの中で使えます。 図 4－6 プル・モードのシーケンス・アイテム・フロー

64

`ovm_doマクロと関連するマクロはシーケンスのトランザクション・アイテムを生成、ランダム

化、そして送信するための便利なコールのセットを提供します。`ovm_doマクロはアイテムのラ

ンダム化を、ドライバがその受信の準備ができたことを知らせ、pre_do メソッドが実行される

まで遅らせます。ほかのマクロ派生物は制約がランダム化（ovm_do_with）に適用されることが

できるようにするか、もしくはランダム化を全くバイパスできるようにします。63 ページの図 4－6 の`ovm_doで包まれた個々のメソッドは機能を失うことなく個々にコールすることができま

す。 １） ファクトリを使ってアイテムの作成 ２） wait_for_gran()をコール ３） pre_do()かまたはほかの機能をコール ４） オプションで itemのランダム化 ５） もし望むならば mid_do()もしくは何かほかの機能をコール ６） send_request()をコール ７） wait_for_item_done()をコール ８） オプションで post_do()またはほかの機能をコール ９） オプションで get_response()をコール 図 4－7 サブシーケンスのフロー

シーケンスとシーケンス・アイテムのマクロ このセクションはシーケンスとシーケンス・アイテムのマクロ、`ovm_doと`ovm_do_with、を

65

記述します。 `ovm_do このマクロはタイプが ovm_sequenceか ovm_sequence_itemの変数のいずれかを引数として

取ります。オブジェクトがファクトリの設定を使って作成され、指定された変数に代入されます。

63 ページの図 4－6 にあるプロセスに基づいて、ドライバがシーケンサからアイテムを要求する

と、アイテムがランダム化されドライバに提供されます。 ページ 61 の“ユーザ定義のシーケンスの宣言”の例の simple_seq_do シーケンス宣言がここ

で繰り返されます。シーケンスの本体は`ovm_doマクロを使ってタイプ simple_itemのアイテ

ムに起動をかけます。

class simple_seq_do extends ovm_sequence #(simple_item); ... // Constructor and OVM automation macros // See “Creating and Adding a New Sequence” virtual task body(); `ovm_do(req) endtask : body endclass : simple_seq_do

同様に、シーケンス変数が提供され、ページ 64 の図 4－7 に示されるように処理されます。次の

例は別のシーケンス（simple_seq_sub_seqs）を宣言し、これは前に定義されたタイプ

simple_seq_doのシーケンスを`ovm_doを使って実行します。

class simple_seq_sub_seqs extends ovm_sequence #(simple_item); ... // Constructor and OVM automation macros // See “Creating and Adding a New Sequence” simple_seq_do seq_do; virtual task body(); `ovm_do(seq_do) endtask : body endclass : simple_seq_sub_seqs

`ovm_do_with このマクロは 65 ページの“ovm_do”と似ています。 初の引数はアイテムやシーケンスを含む

ovm_sequence_item か ら 派 生 し た タ イ プ の 変 数 で す 。 2 番 目 の 引 数 は も し

arg1.randomize() with で使われたときに、正当な任意の有効な直列の制約です。これはい

ろいろなインライン制約を加えることを可能とし、一方同じアイテムもしくはシーケンス変数を

使い続けることができます。

66

例 このシーケンスは addと dataの値に特別な制約を持った 2 つのデータ・アイテムを作り出しま

す。

class simple_seq_do_with extends ovm_sequence #(simple_item); ... // Constructor and OVM automation macros // See “Creating and Adding a New Sequence” virtual task body(); `ovm_do_with(req, { addr == 16'h0120; data == 16'h0444; } ) `ovm_do_with(req, { addr == 16'h0124; data == 16'h0666; } ) endtask : body endclass : simple_seq_do_with

あらかじめ定義されたシーケンス

3 つ の 組 み 込 み シ ー ケ ン ス が あ り 、 そ れ ら は ovm_random_sequence 、

ovm_exhaustive_sequence、 ovm_simple_sequence です。ユーザ定義のシーケンスはシ

ミュレーション実行フェーズの前にシーケンサのシーケンス・キューにロードされます。実行フ

ェーズに入ると、シーケンサはその再構成可能なプロパティである default_sequence で指定

されたシーケンスを開始しトランザクションが流れ始めます。default_sequence のデフォル

ト値は ovm_random_sequenceです。 ovm_random_sequence このシーケンスは組み込みのシーケンスで、あらかじめシーケンサにロードされています。この

シ ー ケ ン ス は シ ー ケ ン サ の ラ イ ブ ラ リ （ ovm_random_sequence と

ovm_exhaustive_sequence は除きます）からランダムにシーケンスを選択し実行します。実

行されるシーケンス数はシーケンサの count フィールドによります。もし count が－１に設定

されていると、ランダム・シーケンスは 0 と ovm_sequence::max_random_countの間の数を

ランダムに選びます。もし count が－ 1 でないと、その count 数のシーケンスが

ovm_random_sequenceによって実行されます。 次のタスクは default_sequence アトリビュートを違う値に再構成しない限り全てのシーケン

サが実行するデフォルトのシーケンスです。

67

task ovm_random_sequence::body(); if (m_sequencer.count == -1) begin assert(randomize(l_count) with { l_count > 0 && l_count < m_sequencer.max_random_count; }); m_sequencer.count = l_count; end else l_count = m_sequencer.count; ... repeat (l_count) begin assert(randomize(l_kind) with { l_kind > l_exhaustive_seq_kind &&l_kind < max_kind; }); do_sequence_kind(l_kind); end endtask

ovm_exhaustive_sequence このシーケンスは組み込みのシーケンスであらかじめシーケンサにロードされています。このシ

ーケンスは現在のシーケンサに対しユーザの定義した全てのシーケンスを網羅的に実行します。

あらかじめ定義された ovm_simple_sequence もまた実行されますがほかの 2 つのあらかじめ

定義されたシーケンス・タイプ（ovm_random_sequence と ovm_exhaustive_sequence）

は実行されません。シーケンスはちょうど一回だけランダムな順で実行されます。l_kind 変数

は置き換えなしにランダム化するために randc と宣言されています。

task ovm_exhaustive_sequence::body(); l_count = m_sequencer.sequences.size() - 2; max_kind = m_sequencer.sequences.size(); l_exhaustive_seq_kind = m_sequencer.get_seq_kind("ovm_exhaustive_sequence"); repeat (l_count) begin assert(randomize(l_kind) with { l_kind > l_exhaustive_seq_kind &&l_kind < max_kind; }); // l_kind is randc. do_sequence_kind(l_kind); end endtask

ovm_simple_sequence このシーケンスは組み込みのシーケンスであらかじめシーケンサにロードされています。このシ

ーケンスは`ovm_do(item)をコールします。itemは ovm_sequenceのプロパティです。この

シーケンスはユーザ定義のシーケンスなしに OVC のデフォルトの実行を可能とするように提供

されています。

68

task ovm_simple_sequence::body(); `ovm_do(item) endtask

シーケンサのデフォルトのシーケンスを再構成

シーケンサはデフォルトで ovm_random_sequence オブジェクトを実行します。シーケンサは

"default_sequence"という名前のストリング・プロパティを持っており、これはユーザ定義のシ

ーケンス・タイプ名にセットすることができます。このシーケンスはシーケンサのインスタンス

のデフォルト・シーケンスとして使われます。 デフォルト・シーケンスの上書きをするために： 1． 適切なベース・シーケンス・クラスから派生したユーザ定義のシーケンス・クラスを宣言

します。

61 ページの“ユーザ定義のシーケンスの宣言”の例は simple_seq_doという名前のシー

ケンスの宣言例を提供しています。

2． 特定のシーケンサもしくはシーケンサのグループのために default_sequence プロパティを

再構成します。通常これは関連するシーケンスを含むコンポーネントを生成する前にテス

ト・クラスの中でおこなわれます。たとえば、

set_config_string("*.master0.sequencer","default_sequence", "simple_seq_do");

初の引数はワイルドカードの仕組みを利用しています。ここで".master0.sequencer"を含

む任意のインスタンス名はその default_sequence プロパティ（もし存在するならば）は

simple_seq_doという値にセットされます。

シーケンス・アイテムとシーケンスの上書き

たとえば base_test_xbus_demo（84 ページの“ベース・テストの作成”で議論されている）

のようなユーザ定義の ovm_testで、共通ファクトリを使ってシーケンスとシーケンス・アイテ

ム・クラスを作成し、今あるシーケンスやシーケンス・アイテムの変更バージョンを使用するシ

ミュレーション環境を再構成できます。さらに詳しくは 117 ページの“組み込みのファクトリと

上書き”を参照してください。

69

特定のシーケンスかシーケンス・アイテム・タイプへの参照を上書きするために： 1． 適切なベース・クラスから派生したユーザ定義のシーケンスもしくはシーケンス・アイテ

ム・クラスを宣言します。次の例が simple_item タイプのベース・シーケンス・アイテ

ムと、タイプ word_aligned_itemの派生アイテムの宣言を示しています。 2． グローバルかインスタンスへの上書きかに従って、適切な ovm_factory のオーバーライ

ド・メソッドを起動します。例えば、 simple_seq_do シーケンスがタイプ

simple_sequencerによって実行されていると仮定します（どちらも 61 ページの“ユー

ザ定義のシーケンスの宣言”で定義されています）。すべての simple_itemタイプの処理

を word_aligned_itemタイプで置き換えるように選択することができます。これはファ

クトリから simple_item タイプへの全てのリクエストでも、特定の simple_item のイ

ンスタンスに対するリクエストでも選択することができます。OVM コンポーネントの内部

からユーザは次のことを実行できます。

// Affect all factory requests for type simple_item. set_type_override_by_type(simple_item::get_type(), word_aligned_item::get_type()); // Affect requests for type simple_item only on a given sequencer. set_inst_override_by_type("env0.agent0.sequencer.*", simple_item::get_type(), world_aligned_item::get_type()); // Alternatively, affect requests for type simple_item for all // sequencers of a specific env. set_inst_override_by_type("env0.*.sequencer.*", simple_item::get_type(), word_aligned_item::get_type());

3． 例えば`ovm_do_macro のような、オブジェクトを割り付ける任意のシーケンス・マクロ

（65 ページの“シーケンスおよびシーケンス・アイテム・マクロ”に定義されているよう

に）を使います。 シーケンス・マクロはデータ・アイテム・オブジェクトを生成するために共通ファクトリをコー

ルするので、今存在するオーバーライドのリクエストは有効となり simple_item の代わりに

word_aligned_itemが生成されます。

再利用可能なシーケンス・ライブラリの構築

再利用可能なシーケンス・ライブラリはユーザ定義のシーケンスのセットです。OVC の再利用可

能シーケンス・ライブラリの作成は、再利用を促進する効果的な方法です。環境の開発者はテス

ト作成者によって強化される、意味のあるシーケンスのセットを作成することができます。その

70

ようなシーケンス・ライブラリはテストにおけるコードの重複を避け、より保守がしやすく、読

み易い簡潔なものにします。 助言 • 多くのテスト作成者が使えるような興味あるプロトコル・シナリオを考えるようにします。 • あるユーザは再利用可能なシーケンス・ライブラリを使いたくないかもしれないため（シー

ケンスがユーザのデザイン要求に合わないかもしれないため）、再利用可能なシーケンス・ラ

イブラリを OVC ファイルの中で`include しないようにします。それらを使うかどうかはユー

ザに決定を任せます。

チェックとカバレッジの実装 チェックとカバレッジはカバレッジ・ドリブンの検証フローにとって大変重要です。

SystemVerilog はカバー、カバーグループ、アサートのコンストラクトに対し 71 ページのテーブ

ル 4－1 に示されている項目が使用可能です。 注意：この概要はコンカレント・アサーションのためのものです。イミーディエイト・アサーシ

ョンはどのプロシージャ文でも使えます。さらに詳しくは SystemVerilog LRM を参照してくだ

さい。 テーブル 4－1 SystemVerilog のチェックとカバレッジのコンストラクトの使用概要

class interface package module initial always generate program

assert no yes no yes yes yes yes yes

cover no yes yes yes yes yes yes yes

covergroup yes yes yes yes no no yes yes

OVC では、チェックとカバレッジは解析される機能のカテゴリによって複数個所で定義されてい

ます。79 ページの図 5－2 ではチェックとカバレッジは ovm_monitor とインタフェースに描か

71

れています。次のセクションはカバー、カバーグループ、アサートのコンストラクトが OVM XBus OVC の例でどのように使われているかを記述します。

クラスでチェックとカバレッジの実装

クラス・チェックとカバレッジは ovm_monitor から派生されるクラスでインプリメントされな

ければなりません。ovm_monitor の派生したクラスは常にエージェントにあり、そのため常に

必要なチェックとカバレッジを含んでいます。バス・モニタは env で、デフォルトで生成され、

チェックとカバレッジ収集が有効になっているとバス・モニタはこれらのファンクションを実行

します。このセクションの残りはクラス・チェックとカバレッジの実装の方法の例としてマスタ・

モニタを使いますが、バス・モニタにも同様に適用されます。 クラス・チェックをプロシージャ・コードもしくは SystemVerilog のイミーディエイト・アサー

ションとして記述することができます。 助言：数行のコードで書けるような簡単なチェックにイミーディエイト・アサーションを使い、

多くの行のコードを必要とする複雑なチェックにはファンクションを使います。理由はチェック

が複雑になるにつれそのチェックのデバッグも複雑になるからです。 注意：コンカレント・アサーションは IEEE1800LRM により SystemVerilog クラスでは許され

ていません。 次はアサーション・チェックの簡単な例です。このアサーションは転送のサイズのフィールドが

1，2，4、もしくは 8 のいずれかであることを検証します。そうでなければアサーションは失敗

します。

function void xbus_master_monitor::check_transfer_size(); check_transfer_size : assert(trans_collected.size == 1 || trans_collected.size == 2 || trans_collected.size == 4 || trans_collected.size == 8) else begin // Call DUT error: Invalid transfer size! end endfunction : check_transfer_size

次はファンクション・チェックの簡単な例です。このファンクションはサイズ・フィールドの値

がデータ・ダイナミック・アレイのサイズと一致するかを検証します。この例は複雑ではありま

せんが、チェックのプロシージャ・コードの例を示しています。

72

function void xbus_master_monitor::check_transfer_data_size(); if (trans_collected.size != trans_collected.data.size()) // Call DUT error: Transfer size field / data size mismatch. endfunction : check_transfer_data_size

これらのチェックを実行する適切な時刻は実装に依存します。上に示されているチェック・ファ

ンクションにコールをいつかけるか決めなければなりません。上の例で、両方のチェックともに

モニタによってトランスファーが収集された後に実行されるべきです。これらのチェックは時刻

の同じインスタンスで起こるため一つだけコールがされるようラッパー・ファンクションを作る

ことができます。このラッパー・ファンクションは次のようになります。

function void xbus_master_monitor::perform_transfer_checks(); check_transfer_size(); check_transfer_data_size(); endfunction : perform_transfer_checks

アイテムがモニタによって収集された後 perform_transfer_checks()ファンクションが、手

続き的にコールされます。 ファンクション・カバレッジは SystemVerilog のカバーグループを使ってインプリメントされま

す。カバレッジグループの詳細（すなわち、何をカバーポイントにするか、いつカバレッジをサ

ンプリングするか、何のビンを作るか）は実装が始まる前に計画し決めておかなければなりませ

ん。 次がカバーグループの簡単な例です。

// Transfer collected beat covergroup. covergroup cov_trans_beat @cov_transaction_beat; option.per_instance = 1; beat_addr : coverpoint addr { option.auto_bin_max = 16; } beat_dir : coverpoint trans_collected.read_write; beat_data : coverpoint data { option.auto_bin_max = 8; } beat_wait : coverpoint wait_state { bins waits[] = { [0:9] }; bins others = { [10:$] }; } beat_addrXdir : cross beat_addr, beat_dir; beat_addrXdata : cross beat_addr, beat_data; endgroup : cov_trans_beat

この組み込まれたカバーグループは ovm_monitor から派生したクラス内で定義され、そしてイ

ベント cov_transaction_beat をサンプリングのトリガー として使います。上のカバレッジ

73

グループのためにファンクションでカバーポイントとして働くローカル変数をアサインしなけれ

ばならず、次にサンプリングをトリガーするイベントを出さなければなりません。これは転送の

各トランザクション・データ・ビートがカバーされるように行われます。このファンクションは

次の例で示されます。

// perform_transfer_coverage virtual protected function void perform_transfer_coverage(); -> cov_transaction; for (int unsigned i = 0; i < trans_collected.size; i++) begin addr = trans_collected.addr + i; data = trans_collected.data[i]; wait_state = trans_collected.wait_state[i]; -> cov_transaction_beat; end endfunction : perform_transfer_coverage

このファンクションはトランスファーとダイナミック・アレイ・データの各エレメントのいくつ

かのプロパティをカバーしています。SystemVerilog はダイナミック・アレイをカバーする機能

は提供しません。もし必要であれば、個々のエレメントを個別にアクセスしその値をカバーしな

け れ ば な り ま せ ん 。 perform_transfer_coverage() フ ァ ン ク シ ョ ン は 、

perform_transfer_check()ファンクションと同じように、アイテムがモニタによって収集さ

れた後、手続き的にコールされます。

インタフェースでチェックとカバレッジの実装

インタフェース・チェックはアサーションとしてインプリメントされます。アサーションがプロ

トコルのための信号のアクティビティをチェックするために追加されます。フィジカルなインタ

フェースに関係するアサーションは env のインタフェースに置かれます。例えば、アサーション

はアドレスが有効なトランスファーの間は決して Xまたは Yにならないことをチェックするかも

しれません。これらのインタフェース・チェックを表現するために、プロパティを仮定すると同

様にアサートを使います。 プロパティがテスト下のデバイスの動作を表現するときアサート・ディレクティブが使われます。

プロパティが DUT へのスティミュラスを生成する環境の動作を表現しているときは assume デ

ィレクティブが使われます。 アサーションを使って実行されるフィジカル・チェックを有効にしたり、無効にしたりする仕組

みが 74 ページの“チェックとカバレッジのコントロール”で議論されています。

74

チェックとカバレッジのコントロール

チェックが実施されカバレッジが収集されるかどうかコントロールする手段を提供しなければな

りません。この目的のために OVM ビット・フィールドを使うことができます。このフィールド

は ovm_componentset_config*インタフェースを使ってコントロールできます。さらに詳しく

は SystemVerilog OVM Class Reference の ovm_threaded_component を参照してください。次

のものはチェックをコントロールするために checks_enableビットを使う例です。

if (checks_enable) perform_transfer_checks();

もし checks_enableが 0 にセットされているならば、チェックを行うファンクションはコール

されず、このようにしてチェックを無効にします。次の例がどのようにして master0.monitor のチェックを止めるかを示しています。

set_config_int("masters[0].monitor", "checks_enable", 0);

同じ機能が XBus エージェント・モニタとバス・モニタの coverage_enableフィールドにも存

在します。

75

OVC を使って この章は再利用可能な Open Verification Component (OVC)のセットからテストベンチを構築す

るのに必要なステップをカバーしています。OVM は開発プロセスを加速し再利用を促進します。

OVM ユーザはより少ない接続とコンフィギュレーションのステップですみ、再利用可能なシー

ケンスのライブラリを活用し、検証のゴールを効率的に達成することができます。 この章では環境のインテグレータと、検証についてはそれほどの知識はなく OVM をテスト生成

に使いたいというテスト作成者の間に区別を設けます。テスト作成者はコンフィギュレーション

のセクションは読み飛ばし、テスト生成のセクションに直接進むことができます。 OVC からテストベンチを構築するために実行すべきステップは次のようになります： １） 再利用可能な OVC の コンフィギュレーション・パラメータをレビューします。 ２） 再利用可能な OVC をインスタンシエートし再構成します。 ３） インタフェース OVC のために再利用可能なシーケンスを生成します（オプション）。 ４） バーチャル・シーケンサを加えます（オプション）。 ５） チェックとファンクショナル・カバレッジの拡張を加えます。 ６） カバレッジ・ゴールを達成するテストを作成します。 この章を読む前にこのマニュアルの“OVM 概要”の章を読んでください。また“再利用可能な

OpenVerification Components（OVC）”を OVC の、より深い理解を得るために読むことをお勧

めします（必須ではありません）。 この章は次のセクションを含んでいます。 • “OVC を使って” 76 ページ • “OVC のインスタンシエーション” 79 ページ • “OVC のコンフィギュレーション” 82 ページ • “ユーザ定義のテストの生成と選択” 84 ページ • “意味のあるテストの作成” 87 ページ • “バーチャル・シーケンス” 99 ページ • “DUT の正しさのチェック” 105 ページ

76

• “カバレッジ・モデルの実装” 110 ページ

OVC を使って 77 ページの図 5－1 に例示されているように、環境インテグレータは再利用可能なコンポーネン

トをインスタンシエートし、再構成し求めるテストベンチを構築します。インテグレータはまた

系統立てた方法で検証プランに従う複数のテストを書きます。 図 5－1 検証環境例

テスト・クラス

ovm_testクラスは、テストで指定されたテストベンチのためにテスト・シナリオを定義します。

テスト・クラスはコマンドラインのテスト選択のユーティリティと同様、テストベンチと環境の

77

クラスのコンフィギュレーションを可能とします。IP 開発者はトポロジと実行時のコンフィギュ

レーション・プロパティの値を提供しますが、もしコンフィギュレーションのカスタマイズが必

要ならば、SystemVerilog OVM Class Library によって提供されるコンフィギュレーションの上

書きを使います。ユーザ定義のシーケンスをファイルかパッケージで提供することができ、これ

はテスト・クラスによってインクルードされるかまたはインポートされます。テストはデータと

シーケンスの生成とインライン制約を提供します。テスト・ファイルは通常一つのコンフィギュ

レーションに関連付けられます。 テスト・クラスの使用例には 84 ページの“ユーザ定義のテストの生成と選択”を参照してくださ

い。 OVM のテストは ovm_test クラスから派生したクラスです。クラスの使用はテストの継承と再

利用を可能にします。

テストベンチのクラス

テストベンチはテストベンチのトポロジを定義するコンテナ・オブジェクトです。テストベンチ

は再利用可能な検証 IP をインスタンシエートしアプリケーションによって要求されるようにそ

の IP のコンフィギュレーションを定義します。 再利用可能な環境を直接テストの内部にインスタンシエートすることはいくつかの欠点がありま

す。 • テスト作成者は環境をどのように再構成するか知らなければなりません。 • トポロジへの変更は複数のテスト・ファイルのアップデートを必要とし、これは大きな作

業になります。 • テストは特定の環境の構造に依存するため、再利用可能ではありません。

これらの理由で、OVM はテストベンチ・クラスを使うことを勧めます。テストベンチ・クラス

は ovm_env クラスから継承されます。テストベンチは再利用可能なコンポーネントを求める検

証タスクのためにインスタンシエートし再構成します。複数のテストがそのテストベンチ・クラ

スをインスタンシエートでき、選ばれたコンフィギュレーションのために生成し送信するトラフ

ィックの性質を決定します。 ページ 79 の図 5－2 はテストベンチ・クラスを含んだテスト・クラスを含む典型的な検証環境を

78

示しています。ほかの環境（OVC）はテストベンチ・クラスの内部に含まれています。 図 5－2 OVC 検証環境クラスのダイアグラム

OVC のインスタンシエーション このセクションは複数のテストに再利用できるテストベンチを作成するためにどのように OVCが使えるかを記述しています。次の例はページ 144 の“XBus OVC の例”の検証 IP を使います。

このインタフェース OVC はその再構成可能性によって多くの環境で使うことができますが、こ

79

のシナリオではこれは一つのマスタと一つのスレーブからなる簡単なコンフィギュレーションで

使われます。テストベンチは適用可能なトポロジの上書きをセットします。 注意： • set_configコールの例は build()ファンクションの中にあります。 • set_config は、もしそれがテストベンチのトポロジに影響を与えるならば build()の

前にコールされなければなりません。

class xbus_demo_tb extends ovm_env; // Provide implementations of virtual methods such as get_type_name(). `ovm_component_utils(xbus_demo_tb)

// XBus reusable environment xbus_env xbus0;

// Scoreboard to check the memory operation of the slave xbus_demo_scoreboard scoreboard0;

// new() function new(string name, ovm_component parent); super.new(name, parent); endfunction : new

// build() virtual function void build(); super.build(); // Configure before creating the subcomponents. set_config_int("xbus0", "num_masters", 1); set_config_int("xbus0", "num_slaves", 1); xbus0 = xbus_env::type_id::create("xbus0", this); scoreboard0 = xbus_demo_scoreboard::type_id::create("scoreboard0", this);; endfunction : build

virtual function connect(); // Connect slave0 monitor to scoreboard. xbus0.slaves[0].monitor.item_collected_port.connect( scoreboard0.item_collected_export); // Assign interface for xbus0. xbus0.assign_vi(xbus_tb_top.xi0); endfunction : connect

virtual function void end_of_elaboration(); // Set up slave address map for xbus0 (basic default). xbus0.set_slave_address_map("slaves[0]", 0, 16'hffff); endfunction : end_of_elaboration

endclass : xbus_demo_tb

ほかのコンフィギュレーションの例は次のものを含みます： • masters[0]のエージェントをアクティブにセットします。

set_config_int("xbus0.masters[0]", “is_active", OVM_ACTIVE);

80

• masters[0]エージェントのためのカバレッジを収集しないようにします。

set_config_int("xbus0.masters[0].monitor", “coverage_enable", 0);

• 全てのスレーブ（ワイルドカードを使って）をパッシブとセットします。

set_config_int("xbus0.slaves*", “is_active", OVM_PASSIVE);

多くのテスト・クラスが上のテストベンチ・クラスをインスタンシエートするかもしれないため、

テスト作成者はそれがどのように生成され再構成されているかの全ての詳細を理解する必要はあ

りません。 xbus_demo_tb の new()コンストラクタはテストベンチ・サブコンポーネントを生成するため

に使われません。SystemVerilog のようなオブジェクト指向の言語では new()の上書きに制限が

あるからです。その代わり、バーチャルな build()ファンクションを使いますが、これは組み込

みの OVM フェーズです。 set_config_int のコールはマスタとスレーブの数が両方ともに 1 であるべきと指定します。

これらのコンフィギュレーション設定は xbus0 build()の間 xbus0環境によって使用されます。

これは xbus_demo_tbの子の xbus0環境のトポロジを定義します。 ある特定のテストでは、ユーザが xbus_envを拡張しそれから新しいクラスを継承したいかもし

れません。create()がサブコンポーネント（new()コンストラクタの代わりに）をインスタン

シエートするために使われ、xbus_env かスコアボード・クラスを、テストベンチ・ファイルを

変えずに、派生したクラスで置き換えることができます。さらに詳しくは 119 ページの“コンポ

ーネントのオーバーライド”を参照してください。 必要に応じて、super.build()が xbus_demo_tb の build()ファンクションの 初の行とし

てコールされます。これは xbus_demo_tb のコンフィギュレーション・フィールドをアップデ

ートします。 connect()はスレーブ・モニタとスコアボードの間の接続を作るために使われます。スレーブ・

モニタは TLM アナリシスポートを含み、これはスコアボードの TLM アナリシエクススポートに

接続されます。XBus 環境のバーチャル・インタフェース変数もまたアサインされ、環境のトポ

ロジがトップレベルの Verilog モジュールとコミュニケーションできます。connect()は組み込

みの OVM フェーズです。 build()と connect()ファンクションが終了した後、環境が完全にエラボレーションされてい

る（すなわち、生成および接続されている）ため、ランタイム・プロパティに調整をかけること

81

ができます。end_of_elaboration()ファンクションがスレーブのエージェントが応答しなけ

ればならないアドレス範囲を、環境に分かるようにします。 xbus_demo_tb は xbus のデモのテストに必要なトポロジを定義します。このオブジェクトはそ

のままの形で使うか、必要に応じてテスト・レベルから上書きもできます。

OVC コンフィギュレーション

OVC の再構成可能なパラメータ

デバイスで使われるプロトコルをもとに、インテグレータは必要とされる環境クラスをインスタ

ンシエートし、求めるオペレーション・モードにそれらを再構成します。いくつかの標準パラメ

ータが共通の検証の必要性に対処するために勧められます。ほかのパラメータはプロトコルそし

て実装に特有です。 標準のコンフィギュレーション・パラメータの例は： • エージェントがアクティブもしくはパッシブ・モードに再構成されることができます。ア

クティブ・モードではエージェントが DUT にトラフィックをドライブします。パッシブ・

モードでは、エージェントが受動的にデバイスのカバレッジをチェックし収集します。従

ったほうがよい経験法則に、エミュレートされる必要のあるデバイスごとに一つのアクテ

ィブ・エージェントを使い、検証される必要のある全ての RTL デバイスにパッシブなエ

ージェントを使うことがあります。 • モニタはデフォルトで DUT インタフェースをチェックしカバレッジを収集します。ユー

ザはこれらのアクティビティを標準の checks_enableと coverage_enableパラメータによ

り無効にすることができます。 ユーザ定義のパラメータの例は： • AHB OVC のマスタとスレーブのエージェントの数 • オペレーション・モードもしくはバスのスピード

OVM OVC は標準のコンフィギュレーション・パラメータと、必要なときはユーザ定義のコンフ

ィギュレーション・パラメータをサポートしなければなりません。ユーザ定義のパラメータに関

82

する情報についてはその OVC のドキュメントを参照してください。

OVC のコンフィギュレーションの仕組み

OVM はコンフィギュレーションの仕組み（以下の 83 ページの図 5－3 参照）を提供し、インテ

グレータが OVC の実装やフック・アップのスキームを知る必要なしに環境を再構成できるよう

にします。 次がいくつかの例になります。

set_config_int("xbus0", "num_masters", 1); set_config_int("xbus0", "num_slaves", 1); set_config_int("xbus0.masters[0]", “is_active", 1); set_config_int("xbus0.slaves*", “is_active", 0); set_config_int("xbus0.masters[0].monitor", “coverage_enable", 0);

図 5－3 標準のコンフィギュレーション・フィールドとロケーション

コンフィギュレーション・クラスを使って

ある OVC はコンフィギュレーション・クラスの内部のコンフィギュレーション・アトリビュー

トをランダム化します。これらのアトリビュートの依存関係はコンフィギュレーション・オブジ

83

ェクトの中の制約を使って捉えられます。そのようなケースでは、ユーザはコンフィギュレーシ

ョン・クラスを拡張し、新しい制約を加えたり、直列の制約を使ってクラスに追加の制約を重ね

ることができます。コンフィギュレーションがランダム化されると、テスト作成者は

set_config_object()を使いテストベンチの中の一つ以上の環境にコンフィギュレーショ

ン・オブジェクトをアサインすることができます。 set_config_int()と同様に、

set_config_object()はテストベンチの複数の環境に、ロケーションにかかわらずコンフィギ

ュレーションをセットすることができるようにし、テストベンチのビルド・プロセスに影響を与

えることができるようにします。

ユーザ定義のテスト生成と選択 OVM では、テストはクラスで、テスト作成者によって書かれたテスト特有のインストラクショ

ンをカプセル化します。このセクションではテストの生成と選択の方法を記述します。またトポ

ロジ・コンフィギュレーションを検証するためのテスト・ファミリーのベース・クラスの作成方

法についても記述します。このセクションは次の内容を含みます。 • “ベース・テストの作成” 84 ページ • “テスト・ファミリーのベース・クラスからテストの作成” 85 ページ • “テスト選択” 86 ページ

ベース・テストの作成

次の例はベース・テストを示しており、79 ページの“OVC のインスタンシエーション”に定義

されている xbus_demo_tbを使っています。このベース・テストは xbus_demo_tbを使う全て

の派生テストのスタート地点になります。完全なテスト・クラスがここに示されています：

class xbus_demo_base_test extends ovm_test; `ovm_component_utils(xbus_demo_base_test) xbus_demo_tb xbus_demo_tb0; // The test’s constructor function new (string name = "xbus_demo_base_test", ovm_component parent = null); super.new(name, parent); endfunction

// Update this component's properties and create the xbus_demo_tb component. virtual function build(); // Create the testbench. super.build();

84

xbus_demo_tb0 = xbus_demo_tb::type_id::create("xbus_demo_tb0", this); endfunction

// Define a default run-time behavior. virtual task run(); #2000 // User-activated end of simulation global_stop_request(); // Terminate the simulation. endtask

endclass

ベース・テストのbuild()ファンクションはxbus_demo_tbを生成します。SystemVerilog OVM Class Library は、コンポーネントのシミュレーション・フェーズを順に実行するときに、

xbus_demo_base_test の build()ファンクションをユーザのために実行します。これは各サ

ブコンポーネントがコンポーネントを作成し、そのコンポーネントが build()ファンクションで

さらにコンポーネントを作成するため、テストベンチの環境を生成します。 ベース・テストの run()タスクはトポロジをプリントし、2000 タイムユニット待ち、その時点

でテストが global_stop_request()インタフェースを使ってシミュレーションを止めます。 ベース・テストの全ての定義は xbus_demo_base_test から派生した全てのテストによって継

承されます。これは全ての派生したテストが、もし super.build()をコールしているならば、

テストベンチを構築する必要はないことを意味します。同様に、run()タスクの動作も継承され

ることができます。もし現在の実装が必要性に合わないならば、build()と run()メソッドのど

ちらもそれらがバーチャルであるため再定義することができます。

テスト・ファミリーのベース・クラスからテストの生成

同じトポロジを再利用するテストを生成するために 84 ページの“ベース・テストの生成”に定義

されているベース・テストから導くことができます。テストベンチはベース・テストの build()

ファンクションで生成され、run()タスクが実行フェーズを定義しているため、派生テストは小

規模の調整をすることができます（例えば、環境でエージェントにより実行されるデフォルト・

シーケンスの変更）。以下は xbus_demo_base_testから継承した簡単なテストの例です。

class test_read_modify_write extends xbus_demo_base_test;

`ovm_component_utils(test_read_modify_write)

// The test’s constructor function new (string name = "test_read_modify_write", ovm_component parent = null);

85

super.new(name, parent); endfunction

// Register configurations to control which // sequence is executed by the sequencers. virtual function void build(); // Substitute the default sequence. set_config_string("xbus_demo_tb0.xbus0.masters[0].sequencer", "default_sequence", "read_modify_write_seq"); set_config_string("xbus_demo_tb0.xbus0.slaves[0].sequencer", "default_sequence", "slave_memory_seq"); super.build(); endfunction

endclass

このテストは masters[0]エージェントと slaves[0]エージェントによって実行されるデフォ

ルト・シーケンスを変更します。default_sequence の設定がテストベンチを作成する

super.build()をコールする前にセットされていることが重要です。super.build()がコール

されると、xbus_demo_tb0と全てのそのサブコンポーネントが生成されます。 このテストは run()フェーズの xbus_demo_base_test実装に依存しています。

テスト選択

ユーザ定義のテスト（85 ページの“テスト・ファミリーのベース・クラスからテストの生成”に

記述されている）を宣言した後、トップレベルのモジュールでグローバルな OVM run_test()タスクに起動をかけシミュレーションされるテストを選択します。そのプロトタイプは次のよう

になります： task run_test(string test_name=””);

run_test()タスクにテスト名が与えられると、ファクトリがコールされテストのインスタンス

がそのタイプ名で生成されます。シミュレーションが次にスタートしシミュレーション・フェー

ズを回ります。 次の例がどのようにテスト・タイプ名 test_read_modify_write（85 ページの“テスト・フ

ァミリーのベース・クラスからテストの生成”に定義されている）が run_test()タスクに与え

られるかを示しています。 テスト名が run_test()タスクにシミュレーションのコマンドラインの引数を通して供給されま

す 。 も し ト ッ プ ・ モ ジ ュ ー ル が 引 数 な し で run_test() を コ ー ル す る と 、

+OVM_TESTNAME=test_name のシミュレータ・コマンドラインの引数がチェックされます。も

86

しあれば、run_test()は test_name を使います。シミュレータのコマンドラインの引数を使

うのは run_test()タスクにテスト名を固定的に記述することを防ぎます。例えば、トップレベ

ル・モジュールで次のように run_test()をコールします：

module tb_top; // DUT, interfaces, and all non-testbench code initial run_test(); endmodule

シミュレータのコマンドライン・オプションを使って、タイプ test_read_modify_write（85ページの“テスト・ファミリーのベース・クラスからテストの生成”に記述されている）のテス

トを選択するには、次のコマンドを使います。

% simulator-command other-options +OVM_TESTNAME=test_read_modify_write

もし run_test()に供給されるテスト名が存在しないならば、シミュレーションは$fatal のコ

ールを通して直ちに終了します。もしこれが起こるならば、おそらく名前が間違ってタイプされ

たか`ovm_component_utilsマクロが使われなかったと考えられます。 このメソッドを使い+OVM_TESTNAME の引数を変えるだけで、デザインもしくはテストベンチを

再コンパイルもしくは再エラボレーションをしなくても複数のテストを実行することができます。

意味のあるテストの作成 前のセクションはどのようにテスト・クラスが組み立てられるかを示しています。この時点でラ

ンダムなトラフィックが生成され DUT に送られます。ユーザはランダム化のシードを変更し新

しいテスト・パターンを作り上げることができます。体系的な方法で検証ゴールを達成するため

に、特定のエリアをカバーするためのテスト生成のコントロールが必要になります。 ユーザはテスト生成を次の手法を使ってコントロールできます： • 個々のデータ・アイテムをコントロールするために制約の追加をします。この手法は基本

的な機能を提供します。88 ページの“データ・アイテムを制約”に記述されています。 • OVM シーケンスを使って複数データ・アイテムの順序をコントロールします。この手法

はより多くの柔軟性とコントロールをもたらします。91 ページの“シーケンスの使用”

で述べられています。

87

データ・アイテムの制約

デフォルトで、シーケンスは繰り返しランダムデータ・アイテムを生成します。このレベルで、

テスト作成者は生成されるデータ・アイテムの数をコントロールし、データ・アイテムに制約を

加え生成された値をコントロールすることができます。 データ・アイテムを制約するために： １） データ・アイテム・クラスとその OVC で生成されたフィールドを特定します。 ２） デフォルトの制約を加えたり上書きするデータ・アイテム・クラスの派生物を生成します。 ３） テストで、新しく定義されたデータ・アイテムを使うために環境（もしくはそのサブセッ

ト）を調整します。 ４） コマンドライン・オプションを使いテスト名を指定しシミュレーションを実行します。 データ・アイテムの例

typedef enum bit {BAD_PARITY, GOOD_PARITY} parity_e;

class uart_frame extends ovm_sequence_item; rand int unsigned transmit_delay; rand bit start_bit; rand bit [7:0] payload; rand bit [1:0] stop_bits; rand bit [3:0] error_bits; bit parity; // Control fields rand parity_e parity_type;

function new(input string name); super.new(name); endfunction

// Optional field declarations and automation flags `ovm_object_utils_begin(uart_frame) `ovm_field_int(start_bit, OVM_ALL_ON) `ovm_field_int(payload, OVM_ALL_ON) `ovm_field_int(parity, OVM_ALL_ON) `ovm_field_enum(parity_e, parity_type, OVM_ALL_ON + OVM_NOCOMPARE) `ovm_field_int(xmit_delay, OVM_ALL_ON + OVM_DEC + OVM_NOCOMPARE) `ovm_object_utils_end

// Specification section 1.2: the error bits value should be // different than zero. constraint error_bits_c {error_bits != 4'h0;}

// Default distribution constraints constraint default_parity_type {parity_type dist { GOOD_PARITY:=90, BAD_PARITY:=10};}

88

// Utility functions extern function bit calc_parity ( ); ... endfunction

endclass: uart_frame

uart_frameは uart の環境開発者によって生成されます。 派生したクラスのいくつかのフィールドはデバイスの仕様から来ます。例えば、フレームは DUTに送られるペイロードを持っていなければなりません。ほかのフィールドはテスト作成者が生成

をコントロールするのを助けるためにあります。例えば、フィールドの parity_type は DUTには送られませんが、パリティの分布を容易に指定しコントロールすることが出来るようにしま

す。そのようなコントロールのフィールドを”ノブ”と呼びます。OVC のドキュメンテーションは

データ・アイテムのノブ、その役割、そして有効な範囲をリストしているはずです。 データ・アイテムは仕様の制約があります。これらの制約は有効なデータ・アイテムを生成する

ために DUT の仕様からきます。例えば、正当なフレームは error_bits_cが 0 と等しくないよ

うにしなければなりません。データ・アイテムの異なる制約のタイプはトラフィックの生成に制

約をかけます。例えば、制約ブロックの default_parity_type（上の例）で、パリティ・ビッ

トは 90 パーセントが正当（正しいパリティ）で 10 パーセントが不当（誤ったパリティ）と制約

がかけられています。 テスト特有のフレームの生成 テストで、ユーザはデータ・アイテムの生成の方法を変えたいと思うかもしれません。例えば、

テスト作成者は短いディレーを持ちたいと思うかもしれません。これは新しいデータ・アイテム・

クラスを派生させ、必要に応じて制約を加えるかもしくはほかのクラスメンバを加えることによ

り達成できます。

// A derived data item example // Test code class short_delay_frame extends uart_frame; // This constraint further limits the delay values. constraint test1_txmit_delay {transmit_delay < 10;}

`ovm_object_utils(short_delay_frame)

function new(input string name="short_delay_frame"); super.new(name); endfunction

endclass: short_delay_frame

89

新しいクラスを派生するのは求める効果を得るのには十分ではありません。環境が OVC フレー

ムではなく新しいクラス（short_delay_frame）を使うようにする必要があります。

SystemVerilog OVM Class Library は派生したクラスを環境に導入できるようにする仕組みを提

供します。

class short_delay_test extends ovm_test; `ovm_component_utils(short_delay_test) uart_tb uart_tb0; function new (string name = "short_delay_test",ovm_component parent = null); super.new(name, parent); endfunction

virtual function build(); super.build(); // Use short_delay_frame throughout the environment. factory.set_type_override_by_type(uart_frame::get_type(), short_delay_frame::get_type()); uart_tb0 = uart_tb::type_id::create("uart_tb0", this); endfunction

task run(); ovm_top.print_topology(); #2000; // User-activated end of simulation global_stop_request(); endtask

endclass

ファクトリ・ファンクションの set_type_override_by_type()（上で太字のもの）のコール

は環境に short_delay のフレームを使うように指示します。 時々、ユーザは特別のトラフィックを一つのインタフェースに送り、通常のトラフィックをほか

のインタフェースに送り続けたいと思うかもしれません。これは OVM コンポーネントの内部で

set_inst_override_by_type()を使うことによって達成されます。

set_inst_override_by_type("uart_env0.master.sequencer.*", uart_frame::get_type(), short_delay_frame::get_type());

またいくつかのコンポーネントのインスタンシエーションを上書きするのにワイルドカードを使

うこともできます。

set_isnt_override_by_type("uart_env*.msater.sequencer.*", uart_frame::get_type(), short_delay_frame::get_type());

90

シーケンスの使用

制約のレイヤ化は DUT のバグを見つけ出す有効な方法です。制約のソルバがランダムに値を選

択させることは正当な入力空間の偏らないサンプリングを確かなものとします。しかし制約のレ

イヤ化は連続したデータ・アイテム間の順序をコントロールすることはできません。多くのハイ

レベル・シナリオは順序付けられたトランザクションのストリームを使ってのみ捉えられます。

例えば、単にバス・トランザクションをランダム化するのはおそらくデバイスの有効なシナリオ

を作り出すとは思えません。OVM シーケンスはライブラリ・ベースのクラスで意味のある順序

付けられたシナリオを作り出すことができるようにします。このセクションは OVM シーケンサ

とシーケンスを記述します。 重要なランダム化の考えとシーケンスの要求 前のセクションではシーケンサはデータ・アイテムをループの中で生成できるジェネレータとし

て記述しています。これがデフォルトの動作である一方、シーケンサは実際シーケンスを生成し

ます。ユーザ定義のシーケンスを、シーケンサのシーケンス・ライブラリに加えランダムに実行

することができます。もしユーザ定義のシーケンスが加えられないと、実行されるシーケンスは

一つのデータ・アイテムを実行する“simple_sequence”と呼ばれる組み込みシーケンスのみに

なります。 91 ページの“ovm_random_sequence で生成されるシーケンスの数のコントロール”はシーケン

スによって生成されるパターンの数を調節するために、どのようにして count を変更するコンフ

ィギュレーションの仕組みを使うことができるかを述べています。このセクションは以下のもの

を含め、シーケンサをコントロールするそのほかの高度な方法を紹介します。 • 実行される新しいシーケンスの生成と追加 • 実行されるシーケンスの分布を変更 • あらかじめ定義されたランダム・シーケンス以外のシーケンスから開始するようにシーケ

ンサを調節

ovm_random_sequence によって生成されるシーケンス数のコントロール 生成されるシーケンスのデフォルト値は0からovm_sequence::max_random_countの間の乱

数です。ユーザは生成されるシーケンス数（count）を変更することができます。count の値を

変更するコンフィギュレーションの仕組みを使います。例えば、10 シーケンスを生成し送信する

91

ならば次を使います。

set_config_int("*.cpu_seqr", "count", 10);

count を 0 に設定することによりシーケンサをシーケンスの生成から無効にすることができます。

set_config_int("*.cpu_seqr", "count", 0);

注意：count よりも多いデータ・アイテムを持つことは必ずしもバグと言う訳ではありません。

シーケンサは直接データ・アイテムを生成しません。デフォルトでシンプル・シーケンスの count

数を生成しそれがアイテムの count 数に変換されていきます。シーケンサはさらに組み込みの機

能を持っていますが、それは次のセクションで述べられます。 新しいシーケンスの生成と追加 ユーザ定義のシーケンスを生成するために １） ovm_sequenceベース・クラスからシーケンスを派生します。 ２） `ovm_sequence_utilsマクロを使いシーケンスを関連するシーケンサ・タイプに結び付

け、いろいろなオートメーション・ユーティリティを宣言します。このマクロは

`ovm_object_utilsマクロ（とその派生物）と似ていますが、このシーケンスが関連付

けられるシーケンサ・タイプ名のもう一つの引数を持つことが異なります。このマクロは

またこの 2 番目の引数で指定されたタイプを持つ p_sequence変数を提供します。これは

派生したタイプ特有のシーケンサのプロパティをアクセスできるようにします。 ３） シーケンスに実行してもらいたい特定のシナリオを持つシーケンスの本体のタスクをイン

プリメントします。本体では 65 ページの“`ovm_do”と 66 ページの“`ovm_do_with”

を使ってデータ・アイテムやほかのシーケンスを実行することができます。 例 下の例にある retry_seqクラスは新しいシーケンスを定義します。これは ovm_sequenceから

継承され、そして`ovm_sequence_utilsマクロを使いこのシーケンスを uart_tx_sequence

と関連付け`ovm_object_utilsが提供するいろいろなユーティリティを宣言しています。

// Send one BAD_PARITY frame followed by a GOOD_PARITY // frame with the same payload.

class retry_seq extends ovm_sequence #(uart_frame); rand bit [7:0] pload; // Randomizable sequence parameter ...

// OVM automation for sequences ‘ovm_sequence_utils_begin(retry_seq, uart_tx_sequencer) ‘ovm_field_object(frame, OVM_ALL_ON)

92

‘ovm_field_int(pload, OVM_ALL_ON) ‘ovm_sequence_utils_end

// Constructor function new(string name="retry_seq"); super.new(name); endfunction

task body ( ); // Sequence behavior ‘ovm_do_with(req, {payload == pload; parity == BAD_PARITY;} ) ‘ovm_do_with(req, {payload == pload; parity == GOOD_PARITY;} ) endtask : body

endclass: retry_seq

シーケンスはランダム化できるパラメータ（例えば、この例では pload）を持つことができます。

これらのパラメータのランダム化をコントロールするのに制約を使います。次に body()タスク

の中のランダム化されたパラメータを使いシーケンサの振る舞いをガイドします。 bodyタスクはシーケンスの主要な動作を定義します。これはタスクであるため、どの手続き型コ

ード、ループ、フォークとジョイン、イベントの wait なども使うことができます。 `ovm_do_with マクロは直列の制約でアイテムをランダム化し実行します。`ovm_do_with は

またデータ・アイテムをドライバに送り、ドライバは DUT にそれを送ります。bodyタスクの実

行はドライバがアイテムを DUT に送るまでブロックされます。`ovm_doマクロを直列の制約な

しにアイテムをランダム化するために使います。 上の例でリトライ・シーケンスが実行されると、ペイロードをランダム化し、生成されたペイロ

ードで不当なパリティを持つフレームを送信し、続いて同様のペイロードで今度は正当なパリテ

ィを持ったフレームを送信します。 シーケンサ・タイプが`ovm_sequence_utils マクロの 2 番目のパラメータとして提供されま

すが、これはこのシーケンスがシーケンス・プールに加えられデフォルトのランダム・シーケン

スによって実行できることを意味します。シーケンス・タイプが提供されているので、

p_sequence変数を適当なタイプと宣言でき初期化できます。 ネスティングされたシーケンスの記述 今あるシーケンスを用いてさらに抽象的なシーケンスを定義することができます。そうすること

はさらに再利用を高めテスト・スイートを保守することがより容易になります。例えば、ブロッ

ク・レベルのテストベンチで、デバイス単位でコンフィギュレーション・シーケンスを定義した

後で、ユーザは既に定義されたシーケンスの組み合わせのシステム・レベルのコンフィギュレー

93

ション・シーケンスを定義できます。 シーケンスを実行すること（行うこと）はデータ・アイテムを行うことと似ています。例えば：

// Call retry sequence wrapped with random frames.

class rand_retry_seq extends ovm_sequence #(uart_frame); // Constructor, and so on

... `ovm_sequence_utils(rand_retry_rand_seq, uart_tx_sequencer) retry_seq retry_sequence; // Variable of a previously declared sequence

task body (); // Sequence behavior `ovm_do (req) `ovm_do_with(retry_sequence, {pload inside {[0:31]};}) `ovm_do(req) endtask

endclass

rand_retry_seqは retry_sequenceと呼ばれるフィールドを持っています。retry_seqは

ユーザによってあらかじめ定義されたシーケンスです。 body()タスクはこのシーケンスを doしており上から直列の制約を重ねています。この上からの

レイヤ化は OVM シーケンスが持つ多くの利点の一つです。 シーケンサの調整 シーケンサは"default_sequence”と名づけられたストリング・プロパティを持っており、これは

ユーザ定義のシーケンス・タイプにセットできます。このシーケンス・タイプはシーケンサの（94ページの図 5－4）現在のインスタンスでデフォルトのシーケンスとして使われます。 図 5－4 シーケンス・ライブラリを持つシーケンサ

94

デフォルト・シーケンスを上書きするために： １） 適切なベース・シーケンス・クラスから派生したユーザ定義のシーケンス・クラスを宣言

します。 ２） default_sequence プロパティを特定のシーケンサかもしくはシーケンサのグループに対し

再構成します。これは通常関連するシーケンスを含むコンポーネントを生成する前にテス

ト・クラスの内部で行われます。例えば、

set_config_string("*.master0.sequencer", "default_sequence","retry_seq");

初の引数は".master0.sequencer"を含む全てのインスタンス名にマッチさせるためワイ

ルドカードを使い、default_sequence プロパティ（もし存在するならば）を値”retry_seq”にセットします。

シーケンス・ライブラリと再利用 シーケンスの使用は OVC 再利用の重要な部分です。OVC プロトコルの使用を知っており理解し

95

ている環境開発者は興味あるパラメータ化された再利用可能なシーケンスを生成することができ

ます。このシーケンス・ライブラリは環境ユーザが、カバレッジ・ゴールをより早く達成する所

望のシナリオを構築することができるようにします。OVC のシーケンサがシーケンスのライブラ

リを伴うかどうかをチェックしてください。下の例は sequence.print()コマンドのプリント

アウトを示しています。

----------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------

sequencer uart_tx_sequencer- @1011

default_sequence string 19 ovm_random_sequence

sequences da(string) 4 -

[0] string 19 ovm_random_sequence

[1] string 23 ovm_exhaustive_sequence

[2] string 19 ovm_simple_sequence

[3] string 9 retry_seq

[4] string 14 rand_retry_seq

count integral 32 -1

max_random_count integral 32 'd10

max_random_depth integral 32 'd4

このシーケンサのデフォルト・シーケンスは ovm_random_sequenceで、これはデフォルトで、

シーケンスがループの中でランダムに生成されることを意味します。 このシーケンサはそれに関連する 5 つのシーケンスを持っています。3 つのシーケンスは組み込

み の シ ー ケ ン ス （ ovm_random_sequence 、 ovm_exhaustive_sequence 、

ovm_simple_sequence）で 2 つはユーザ定義（retry_sequence と rand_retry_seq）で

す。 組み込みの網羅的（exhaustive）シーケンスはランダム・シーケンスと同様です。これは、ラン

ダムにシーケンスを実行するために選びますが、ほかの全てのシーケンスが生成されるまでは同

じシーケンスを繰り返しません。これはまたシーケンサの count プロパティを使わず、

ovm_random_sequence と ovm_exhaustive_sequence をとめて、シーケンス・ライブラリ

96

から各シーケンスを一度だけ実行します。 このシーケンサの count の値は -1 で、これは生成されるシーケンスの数は 0 と

max_random_count（この例ではデフォルト値は 10 です）の間になります。 シーケンスに関しさらに詳しくは 123 ページの“高度なシーケンス・コントロール”を参照して

ください。 ダイレクティド・テストのインタフェース 91 ページの“シーケンスの使用”で議論されたシーケンス・スタイルは、テストを生成する勧め

られる方法です。焦点はスティミュラス・シナリオを直接テストの内部におく代わりに、多くの

テストにわたって使うことができる再利用可能なシーケンスを作成することに置かれています。

各シーケンサは、実行時に生成され DUT に送られるデフォルトのトラフィックとともにあらか

じめロードされています。テストの内部で、テスト作成者は変更される必要のあるシーケンサだ

け触ればすみます。 あるテスト作成者は、しかしながら、ダイレクティド・テストを書くのに慣れているかもしれま

せん。ダイレクティド・テストでは手続き型のコードを書き、そこで明示的に各インタフェース

にアイテムを生成し送信することをリクエストします。テスト生成スタイルとしてダイレクト・

テストは勧められませんが、OVM はこの手法をシーケンサの execute_item()タスクを使って

サポートしています。ダイレクト・テストを使う前に OVM が勧めるテスト生成手法と比べたそ

の欠点を考えてください。 • ダイレクト・テストは記述も保守もより多くのコードを必要とします。これはシステム・

レベルの環境では大きな問題になります。 • ダイレクト・テストでは、コードの高レベルの意図が読むのも理解するのも分かりにくく、

易しくありません。勧められる手法では、コードはテスト特有のニーズに焦点を当ててお

り、ほかのシステムに関するアスペクトはデフォルトで存在します。たとえば、リクエス

トにサービスするスレーブのアービトレーション・ロジックは、全てのテストにコーディ

ングする必要はありません。 • ダイレクトは特定の再利用できない情報を含んでいるため再利用しにくくなります。 • 勧められる方法では、テストはデフォルトでランダムです。全ての宣言されたシーケンス

はデフォルトで実行の候補になります。シーケンスを実行から除くためには、明示的に除

かなければなりません。これは失われたシーケンスの問題を防ぎ、予期されないバグを見

つけ出すランダム・パターンをより多く作り出します。 • 多くのプロトコルのための勧められる手法では、ハイレベルのシーケンスを触る必要は決

97

してありません。これはある順序で実行されるほかのサブシーケンスのテンプレートの役

割を果たします。 次のコードがダイレクティド・テストの例です。 注意： • execute_item()タスクはデータ・アイテムかシーケンスを実行できます。これはアイ

テムかシーケンスがシーケンサによって実行されるまでブロックします。fork/join のよう

な通常の SystemVerilog コンストラクトを使って並列性をモデル化することができます。 • シーケンサのデフォルト・アクティビティは全てのシーケンサの count パラメータを 0 に

設定して無効にされます。execute_item()タスクがトラフィックを決まった方法で送

ります。 • デフォルトのランダム・アクティビティを使うことは良い実践です。これは明白で、よい

投資です。execute_item()の使用は 小にすべきであり特定のシナリオに限るべきで

す。

class directed_test extends xbus_demo_base_test; `ovm_component_utils(directed_test)

xbus_demo_tb xbus_demo_tb0; function new (string name = "directed_test", ovm_component parent = null); super.new(name, parent); endfunction

virtual function void build(); super.build(); set_config_int("*.sequencer", "count", 0); // Create the testbench. xbus_demo_tb0 = xbus_demo_tb::type_id::create("xbus_demo_tb0", this); endfunction

virtual task run(); bit success; simple_item item; #10; item = new(); success = item.randomize(); tb.ahb.masters[1].sequencer.execute_item(item); success = item.randomize() with { addr < 32'h0123; } ; tb.ahb.masters[1].sequencer.execute_item(item); endtask

endclass

バーチャル・シーケンス

98

87 ページの“意味のあるテストの作成””は単一インタフェースの生成パターンを効率的にコン

トロールする方法を記述しています。しかし、システム・レベルの環境では複数のコンポーネン

トが並列にスティミュラスを生成しています。ユーザは複数のチャネルの間でタイミングとデー

タを調整したいと思うかもしれません。また、ユーザは再利用可能なシステム・レベルのシナリ

オを定義したいと思うかもしれません。バーチャル・シーケンスはバーチャル・シーケンサに関

連付けられており、テストベンチの階層でスティミュラス生成の調整を行うために使われます。

一般にバーチャル・シーケンサはそのサブシーケンサへの参照を含んでいますが、それはすなわ

ちドライバ・シーケンサかほかのバーチャル・シーケンサで、そこでシーケンスに起動をかけま

す。バーチャル・シーケンスは、各サブシーケンサのシーケンスと同様、そのシーケンサと関連

を持つほかのバーチャル・シーケンスに起動をかけることができます。しかし、バーチャル・シ

ーケンサは自分自身のデータ・アイテムを持たないため、自分自身の上でデータ・アイテムを実

行しません。バーチャル・シーケンスはアイテムを実行できるほかのシーケンサでアイテムを実

行することができます。 バーチャル・シーケンスは DUT のいろいろなインタフェースに接続された複数の検証コンポー

ネントのアクティビティを集中管理ができるようにします。バーチャル・シーケンスを生成する

ことにより、元になっているインタフェース・コンポーネントの現在存在するシーケンス・ライ

ブラリとブロック・レベルの環境を容易に再利用でき、調整されたシステム・レベルのシナリオ

を生成できます。 99 ページの下の図 5－5 でバーチャル・シーケンサはイーサネットと cpu OVC のコンフィギュレ

ーション・シーケンスに起動をかけます。コンフィギュレーション・シーケンスはブロック・レ

ベルのテストの間に開発されます。 図 5－5 バーチャル・シーケンス

99

バーチャル・シーケンサがそのサブシーケンサと 3 つの方法でやり取りができます。 • サブシーケンサを有効にする － バーチャル・サブシーケンサとサブシーケンサは同時

にトランザクションを送ります。 • サブシーケンサを無効にする － バーチャル・シーケンサが唯一ドライブします。 • grab()と ungran()の使用 － バーチャル・シーケンサはある限られた時間、制御下

にあるドライバのコントロール権を取ります。 バーチャル・シーケンスを使うとき、ほとんどのユーザはサブシーケンサを無効にし、バーチャ

ル・シーケンスからのみシーケンスに起動をかけます。さらに詳しくは 103 ページの“ほかのシ

ーケンサのコントロール”を参照してください。 シーケンスに起動をかけるのに次のいずれかで行います。 • 適当な do マクロを使う。 • シーケンスの start()メソッドを使う。

バーチャル・シーケンサの生成

一つのシーケンサから複数のシーケンサをハイレベルでコントロールするには、ドライバに付い

ていないシーケンサを使いアイテムそのものを処理しないようにします。この役割で動いている

シーケンサをバーチャル・シーケンサと呼びます。

100

いくつかのサブシーケンサをコントロールするバーチャル・シーケンサを作るために： １） ovm_sequenceクラスからバーチャル・シーケンサ・クラスを継承します。 ２） バーチャル・シーケンスがアクティビティを協働するシーケンサにリファレンスを加え

ます。これらのリファレンスはより高いレベルのコンポーネント（通常テストベンチ）によ

ってアサインされます。 次の例は 2 つのサブシーケンサを持つバーチャル・シーケンサを宣言します。”eth”と”cpu“と

呼ばれる 2 つのインタフェースが buildファンクションに作成され、これは実際のサブシーケン

サにつなげられます。

class simple_virtual_sequencer extends ovm_sequencer; eth_sequencer eth_seqr; cpu_sequencer cpu_seqr;

// Constructor function new(input string name="simple_virtual_sequencer", input ovm_component parent=null); super.new(name, parent); // Automation macro for virtual sequencer (no data item) `ovm_update_sequence_lib endfunction

// OVM automation macros for sequencers 'ovm_sequencer_utils(simple_virtual_sequencer)

endclass: simple_virtual_sequencer

注意：バーチャル・シーケンサを定義するとき、'ovm_update_sequence_libマクロがコンス

トラクタで用いられます。これは（バーチャルでない）ドライバ・シーケンサと異なります。こ

れらは関連するデータ・アイテム・タイプを持ちます。このマクロが使用されると、

ovm_simple_sequence はシーケンサのシーケンス・ライブラリに加えられません。simple sequence だけがアイテムを実行し、そしてバーチャル・シーケンサはアイテムを処理することが

できるドライバに接続されていないため、これは重要です。ドライバ・シーケンサのために、

'ovm_update_sequence_lib_and_itemマクロを使います。さらに詳しくは 45 ページの“シ

ーケンサの生成”を参照してください。 サブシーケンサは、ドライバ・シーケンサかほかのバーチャル・シーケンサでもありえます。リ

ファレンスを通した実際のサブシーケンサ・インスタンスの接続は 104 ページの“バーチャル・

シーケンサをサブシーケンサに接続”で示されるように、後で行われます。

101

バーチャル・シーケンスの作成

バーチャル・シーケンスの作成は次の違いを除いて、ドライバ・シーケンスの作成と同様です。 • バーチャル・シーケンスは'ovm_do_onもしくは'ovm_do_on_withを使い、現在のバー

チャル・シーケンサに接続されている任意のサブシーケンサでシーケンスを実行します。 • バーチャル・シーケンスは、このシーケンサのほかのバーチャル・シーケンスを実行する

ために'ovm_doもしくは'ovm_do_withを使います。バーチャル・シーケンスはアイテム

を実行するのに'ovm_doもしくは'ovm_do_withは使えません。バーチャル・シーケンサ

はそれに付随するアイテムを持っておらず、シーケンスだけです。 バーチャル・シーケンスを作成するために： 1. ドライバ・シーケンスとちょうど同じように、ovm_sequenceからシーケンス・クラスを継

承しそれを宣言します。 2. シーケンスの求める論理をインプリメントする body()メソッドを定義します。 3. 基底になるサブシーケンサのシーケンスに起動をかけるために 'ovm_do_on（もしくは

'ovm_do_on_with）マクロを使います。 4. 現在のバーチャル・シーケンサのほかのバーチャル・シーケンスに起動をかけるために

'ovm_do（もしくは'ovm_do_with）マクロを使います。 次の例は簡単なバーチャル・シーケンスが cpu シーケンサと ethernet シーケンサの 2 つをコント

ロールしているところを示しています。cpu シーケンサはそのライブラリに cpu_config_seq

シーケンスを持ち、ethernet シーケンサはそのライブラリの eth_large_payload_seqシーケ

ンスを提供すると仮定します。次のシーケンス例はこれら 2 つのシーケンサに次々に起動をかけ

ます。

class simple_virt_seq extends ovm_sequence; ... // Constructor and OVM automation macros // See ”Creating and Adding a New Sequence” on page 86 // A sequence from the cpu sequencer library cpu_config_seq conf_seq; // A sequence from the ethernet subsequencer library eth_large_payload_seq frame_seq; // A virtual sequence from this sequencer's library random_traffic_virt_seq rand_virt_seq;

virtual task body(); // Invoke a sequence in the cpu subsequencer. 'ovm_do_on(conf_seq, p_sequencer.cpu_seqr) // Invoke a sequence in the ethernet subsequencer.

102

'ovm_do_on(frame_seq, p_sequencer.eth_seqr) // Invoke another virtual sequence in this sequencer. 'ovm_do(rand_virt_seq) endtask : body

endclass : simple_virt_seq

ほかのシーケンサのコントロール

バーチャル・シーケンサを使用するとき、定義されるバーチャル・シーケンスの動作に関連して

サブシーケンスがどのように動作してほしいかを考慮する必要があります。3 つの基本的な可能

性があります。 • サブシーケンサを有効にする － オリジナルのサブシーケンサの組み込みの機能を使って、

バーチャル・シーケンサとサブシーケンサに同時にトラフィックを生成してもらいたいと思

う場合です。サブシーケンサのデフォルトの動作から結果として出てくるデータ・アイテム

は、バーチャル・シーケンサによって起動をかけられたシーケンスによって注入されたもの

と一緒に、混ぜ合わされドライバの任意の順序で実行されます。これはデフォルトの動作の

ため、これを達成するために何もする必要はありません。 • サブシーケンサを無効にする － set_configルーチンを使って、サブシーケンサの count

プロパティを 0 に設定し、デフォルトの動作を無効にすることができます。デフォルトでシ

ーケンサは ovm_random_sequenceをスタートさせ、これはシーケンサの count プロパティ

を使いいくつのシーケンスを実行するか決めることを思い出してください。

次の部分的なコードは 104 ページの下の“バーチャル・シーケンサをサブシーケンサに

接続”の例のサブシーケンサを無効にしています。

// Configuration: Disable subsequencer sequences. set_config_int("*.cpu_seqr", "count", 0); set_config_int("*.eth_seqr", "count", 0);

• grab()と ungrab()の使用 － grab()と ungrab()を使って、バーチャル・シーケンス

はある限られた時間、サブシーケンサの完全なコントロール権を取得（グラブ）し、そして

もとのシーケンスが作業を継続できるようにします。 注意：（バーチャルでない）ドライバ・シーケンサだけをグラブできます。そのため、与えられた

サブシーケンサがバーチャル・シーケンサでないかどうかそれをグラブしようとする前に確かめ

なければなりません。次の例はシーケンス・コンシューマ・インタフェースでgrab()とungrab()

ファンクションの使用を例示しています。

103

virtual task body(); // Grab the cpu sequencer if not virtual. if (p_sequencer.cpu_seqr != null) p_sequencer.cpu_seqr.grab(this); // Execute a sequence. 'ovm_do_on(conf_seq, p_sequencer.cpu_seqr) // Ungrab. if (p_sequencer.cpu_seqr != null) p_sequencer.cpu_seqr.ungrab(this); endtask

注意：いくつかのシーケンサをグラブするとき、デッドロックを避ける何か手法を使うようにし

ます。例えば、常に標準の順序でグラブします。

バーチャル・シーケンサをサブシーケンサに接続

バーチャル・シーケンサをそのサブシーケンサに接続するために： 1. バーチャル・シーケンサに定義されたシーケンサ・リファレンスをシーケンサのインスタン

スにアサインします。これは簡単なリファレンスのアサインで全てのコンポーネントが生成

された後にのみ実行されます。

v_sequencer.cpu_seqr = cpu_seqr;

v_sequencer.eth_seqr = eth_seqr;

2. 検証階層の適当なロケーションで、検証環境の connect()フェーズでアサインを実行します。 次のより完全な例はトップレベルのテストベンチを示しており、このテストベンチはイーサネッ

トと cpu のコンポーネントとそれら 2 つをコントロールするバーチャル・シーケンサをインスタ

ンシエートしています。テストベンチ・レベルでは、いろいろなコンポーネントの内部のシーケ

ンサへのパスは知られており、そのパスがコンポーネントへのハンドルを得て、それらをバーチ

ャル・シーケンサに接続するために使われます。

class simple_tb extends ovm_env; cpu_env_c cpu0; // Reuse a cpu verification component. eth_env_c eth0; // Reuse an ethernet verification component. simple_virtual_sequencer v_sequencer; ... // Constructor and OVM automation macros virtual function void build(); super.build(); // Configuration: Disable subsequencer sequences. set_config_int("*.cpu_seqr", "count", 0); set_config_int("*.eth_seqr", "count", 0); // Configuration: Set the default sequence for the virtual sequencer.

104

set_config_string("v_sequencer", "default_sequence", simple_virt_seq"); // Build envs with subsequencers. cpu0 = cpu_env_c::type_id::create("cpu0", this); eth0 = eth_env_c::type_id::create("eth0", this); // Build the virtual sequencer. v_sequencer = simple_virtual_sequencer::type_id::create("v_sequencer", this); endfunction : build

// Connect virtual sequencer to subsequencers. function void connect(); v_sequencer.cpu_seqr = cpu0.master[0].sequencer; v_sequencer.eth_seqr = eth0.tx_rx_agent.sequencer; endfunction : connect

endclass: simple_tb

DUT の正しさへのチェック デバイスを求める状態にするのは検証の重要な部分です。環境は機能が検証されたと宣言する前

に DUT からの有効な応答を検証しなければなりません。2 つのタイプの自動チェックの仕組みが

使えます。

• アサーション － 仕様からもしくは実装から継承され正しいタイミングの動作を確認し

ます。アサーションは通常信号レベルのアクティビティに焦点を合わせます。

• データ・チェッカ － 全体のデバイスの正しさを確認します。 18 ページの“モニタ”で触れられたように、チェックとカバレッジはドライブするロジックにか

かわらず、モニタで行われるべきです。再利用可能なアサーションは再利用可能なコンポーネン

トの部分です。さらに詳しくは 37 ページの“再利用可能な Open Verification Component (OVC)の開発”を参照してください。設計者はまたアサーションを DUT RTL におくこともできます。

さらに詳しくは ABV ドキュメンテーションを参照してください。 このセクションはデータ・チェッカに焦点を合わせます。

スコアボード

自己チェックの環境の重要なエレメントはスコアボードです。通常スコアボードはデザインの適

切な動作をファンクション・レベルで検証します。スコアボードの責任は実装によって大幅に変

105

わります。このセクションは与えられた XBus のスレーブのインタフェースが簡単なメモリとし

て動作することを検証するスコアボードの例を示しています。メモリの動作は XBus のデモンス

トレーション環境に重要ですが、環境でスコアボードを作成し使用するのに必要なステップに焦

点を当て、これらのステップが任意のスコアボードの応用に繰り返せるようにしてください。 XBus のスコアボード例 XBus デモ環境で、スコアボードはスレーブ・エージェントが簡単なメモリとして動作している

ことを検証するのに必要です。あるアドレスに書き込まれたデータはそのアドレスが読まれると

戻ってきます。求めるトポロジは 106 ページの図 5－6 に示されています。 この例では、一つのアクティブ・マスタ・エージェントと一つのアクティブ・スレーブ・エージ

ェントのバス・モニタを含むひとつの XBus 環境を含んでいるテストベンチをユーザが作成して

います。XBus 環境の全てのコンポーネントは IP 開発者によって定義された build()メソッド

を使い作成されています。 図 5－6 XBus デモ環境

スコアボードの作成 スコアボードが xbus_demo_tb に加えられる前に、スコアボードのコンポーネントが定義され

なければなりません。 スコアボードを定義するために：

106

１） 環境の monitor()とコミュニケーションするのに必要な TLM を加えます。 ２） TLM エクスポートに必要とされているファンクションとタスクの実装を行います。 ３） エクスポートがコールされたときに取られるアクションを定義します。 ovm_scoreboard にエクスポートを追加 106ページの図5－6に示されている例でスコアボードは環境とコミュニケーションを行うために

一つのポートだけを必要とします。環境内のモニタはアナリシスポートの write()のインタフェ

ースを TLM ovm_analysis_por を通して提供しているため、スコアボードは TLM ovm_analysis_impを提供します。 xbus_demo_scoreboard コンポーネントは ovm_scoreboard から継承され analysis_imp

を宣言しインスタンシエートします。TLM インタフェースに関する詳しい情報は SystemVerilog OVM Class Reference の“TLM インタフェース”を参照してください。宣言と生成はコンスト

ラクタの中で行われます。

1 class xbus_demo_scoreboard extends ovm_scoreboard;

2 ovm_analysis_imp #(xbus_transfer, xbus_demo_scoreboard)

3 item_collected_export;

4 ...

5 function new (string name, ovm_component parent);

6 super.new(name, parent);

7 item_collected_export = new("item_collected_export", this);

8 endfunction : new

9 ...

2 行目は ovm_analysis_export を宣言します。 初のパラメータの xbus_transfer はこの

TLM インタフェースを通してコミュニケーションされる ovm_object を定義します。2 番目の

パラメータこの実装の親のタイプを定義します。これは親の write()メソッドがエクスポートに

よってコールできるようにするため必要です。 7 行目は実装・インスタンスを生成します。コンストラクタの引数はこの実装のインスタンスの

名前とその親を定義します。 TLM 実装の要求 スコアボードは ovm_analysis_imp を提供するため、スコアボードはエクスポートによって要

107

求される全てのインタフェースをインプリメントしなければなりません。これは write バーチャ

ル ・ フ ァ ン ク シ ョ ン の 実 装 を 定 義 し な け れ ば な ら な い こ と を 意 味 し ま す 。

xbus_demo_scoreboardのために、write()は次のように定義されています。

virtual function void write(xbus_transfer trans); if (!disable_scoreboard) memory_verify(trans); endfunction : write

write()実装はこのインタフェースにデータが供給されると何が起こるかを定義します。このケ

ースでは、もし disable_scoreboardが 0 ならば、memory_verify()ファンクションはトラ

ンザクションを引数としてコールされます。 取られるアクションを定義 write port が write()を通してコールされると、実装の親の write()実装がコールされます。

さらに詳しくは SystemVerilog OVM Class Reference の“TLM インタフェース”を参照してく

ださい。前のセクションで見たように write()ファンクションは、もし disable_scoreboard

が 0 にセットされていると、memory_verify()ファンクションをコールするように定義されま

す。 memory_verify()ファンクションはメモリの動作を検証するために適当なコールと比較を行い

ます。このファンクションはスコアボードと環境のほかの部分とのコミュニケーションにおいて

それほど重要ではありません。xbus_demo_scoreboard.sv ファイルがその実装を示しています。 環境にスコアボードを追加する

スコアボードが定義されると、スコアボードをXBus デモ・テストベンチに加えることができま

す。 初に、xbus_demo_tb クラスの内部でxbus_demo_scoreboard を宣言します。

xbus_demo_scoreboard scoreboard0;

スコアボードが宣言された後、build()フェーズの内部にスコアボードを構築することができま

す。

function xbus_demo_tb::build(); ... scoreboard0 = xbus_demo_scoreboard::type_id::create("scoreboard0", this); ... endfunction

108

ここでタイプがxbus_demo_scoreboard の scoreboard0 がcreate()ファンクションを使

って生成され“scoreboard0”という名前をつけられます。それは次にxbus_demo_tb がその親とし

てアサインされます。

スコアボードが生成された後、xbus_demo_tb はXBus 環境のslaves[0]モニタのポートをス

コアボードのエクスポートに接続することができます。

function xbus_demo_tb::connect(); ... xbus0.slaves[0].monitor.item_collected_port.connect( scoreboard0.item_collected_export); ... endfunction

このxbus_demo_tbのconnect() ファンクション・コードは、TLM ポートのconnect()イン

タフェースを使って、xbus0 環境の内部のslaves[0] エージェントのモニタのポートと

scoreboard0 と呼ばれるxbus_demo_scoreboard 実装の間の接続を作ることができます。

TLM ポートのバインディングに関するさらに詳しい情報はSystemVerilog OVM Class

Reference.の“TLMインタフェース”を参照してください。

まとめ

このセクションのスコアボード追加のプロセスは、環境のコミュニケーションという点でほかの

スコアボードの応用にも適用できます。まとめると：

1. スコアボード・コンポーネントを生成します。

• 必要なエクスポートを加えます。

• 必要とされるファンクションとタスクをインプリメントします。

• 実装に特有の機能を実行するために必要なファンクションを生成します。

2. スコアボードを環境に追加

• スコアボード・コンポーネントを宣言しインスタンシエートします。

• スコアボードの実装を興味ある環境のポートに接続します。

XBus デモは完全なスコアボードの例を含んでいます。さらに詳しくは144ページの“XBus OVC

の例”を参照してください。

109

カバレッジ・モデルの実装 完全な検証を確かなものとするため、検証のゴールを示すオブザーバが必要になります。

SystemVerilog は豊富なファンクショナル・カバレッジの機能を提供します。

カバレッジ・メソッドの選択

単一のカバレッジ指標だけでは完全性は得られません。カバレッジ・メソッドには２つあります。 • 明示的カバレッジ － これはユーザ定義のカバレッジです。ユーザがカバレッジ・ゴール、

必要な値、そして収集の時間を指定します。そのため、これらのゴールを解析するのは用意

です。全てのカバレッジ・ゴールを終了することは検証ゴールを 100％達成し、検証が終了

したことを意味します。そのようなメトリックの例は SystemVerilog のファンクショナル・

カバレッジです。そのようなメトリックの欠点は見失ったゴールは考慮されないことです。 • 暗黙的カバレッジ － これは RTL もしくはコードに既に存在するほかのメトリックから

ドライブされる自動メトリックにより行われます。通常暗黙のカバレッジ・レポートを作成

することは明らかで多くの手間はかかりません。例えば、コード・カバレッジ、イクスプレ

ッション・カバレッジ、そして FSM（有限ステート・マシン）カバレッジは暗黙的カバレ

ッジのタイプです。暗黙的カバレッジの欠点はカバレッジの要求を検証のゴールにマッピン

グするのが難しいことです。またカバレッジの穴を実行されていないハイレベルの機能にマ

ッピングするのも難しくなります。さらに、暗黙的カバレッジはハイレベルの抽象度のイベ

ントを考慮に入れず、パラレル・スレッド間（すなわち、2 つ以上のイベントが同時に起こ

ります）の関連付けを行わないため完全ではありません。 明示的カバレッジからスタートすることを勧めます。ハイレベルの検証ゴールを表すカバレッ

ジ・モデルを構築すべきです。その後、暗黙的カバレッジを“セーフティ・ネット”として使い

明示的カバレッジのチェックとバランスを行います。 注意：非常に低いコード・カバレッジで 100％のファンクショナル・カバレッジ到達したことは、

ファンクショナル・カバレッジはさらに詳細化し高める必要があることを意味します。

ファンクショナル・カバレッジ・モデルの実装

OVC はプロトコルに特有のファンクショナル・カバレッジ・モデルを伴わなければなりません。

110

ユーザとして、重要でもなく検証する必要のない、あるカバレッジ・アスペクトを無効にしたい

かもしれません。例えば、システムの全てのタイプのバス・トランザクションをテストする必要

がなかったり、全てのタイプのトランザクションをゴールとして指定するカバレッジのロジック

からそのゴールを取り除きたいと思うかもしれません。またファンクショナル・カバレッジ・モ

デルを拡張し、OVC カバレッジとシステムのほかのアトリビュートやもしくはほかのインタフェ

ース OVC と関連付けたりしたいかもしれません。例えば、全てのタイプのトランザクションが

送られシステムの FIFO がフルになったとき適切な動作を確実にしたいかもしれません。これは

FIFO のステータス変数でトランザクション・タイプを横断することと変換されます。このセク

ションはこのタイプのファンクショナル・カバレッジ・モデルをどのように実現するか記述して

います。 カバレッジを有効にしたり無効にする 検証 IP の開発者はカバレッジの興味あるアスペクト（74 ページの“チェックとカバレッジのコ

ントロール”を参照）をコントロールすることができるコンフィギュレーション・プロパティを

提供しなければなりません。VIP ドキュメンテーションはカバレッジに影響を及ぼすためにどの

プロパティを送ることができるかを述べています。コントロールの も基本はカバレッジが収集

されるかどうかを決めることです。XBusモニタはこのレベルのコントロールを例示しています。

もし環境が作成される前にカバレッジを無効にしたいときは、set_config_int()インタフェー

スを使います。

set_config_int("xbus0.masters[0].monitor", "coverage_enable", 0);

環境が生成されると、このプロパティを直接セットできます。

xbus0.masters[0].monitor.coverage_enable = 0;

これは簡単なクラス・プロパティの（または変数）への Verilog の代入です。

111

より高度なトピック この章は今までの章でカバーされた基本的な内容を越えた OVM のトピックと SystemVerilog OVM Class Library の機能について議論します。より詳しい情報が必要ならば、必要に応じてこ

の章を参照してください。この章は次の内容を議論します。 • “ovm_component ベース・クラス” 112 ページ • “シミュレーション・フェーズ・メソッド” 112 ページ • “組み込みのファクトリとオーバーライド” 117 ページ • “高度なシーケンス・コントロール” 123 ページ

ovm_component ベース・クラス 環境やテストを含め OVM 検証環境のすべてのインフラストラクチャ・コンポーネントは直接か

間接的かのいずれかで ovm_componentクラスから継承されています。このクラスから由来した

ユーザ定義のクラスは組み込みのオートメーションを継承しています。通常クラスをメソドロ

ジ・クラスから継承しますが、このクラスそのものも ovm_componentの拡張です。しかしメソ

ドロジ・クラスが提供するファシリティの多くが ovm_componentから派生されるため、このク

ラスを理解することは重要です。 注意：ovm_threaded_component クラスは OVM2.0 でそれほど重要でないものとみなされ今

は単に ovm_componentの typedef です。 次のセクションは ovm_componentのベース・クラスによって提供されるいくつかの機能とそれ

らの使い方を述べています。ovm_component ベース・クラスによって提供される機能の主要な

部分は次のようなものがあります： • フェージングと実行のコントロール • コンフィギュレーション・メソッド • ファクトリ・メソッド • 階層的レポートコントロール

シミュレーション・フェーズ・メソッド

112

SystemVerilog OVM Class Library は組み込みのシミュレーション・フェーズ・メソッドを提供

します。これらのフェーズは時間のクリティカルなポイントで実行されるロジックを含めるよう

にするためのフックです。例えばシミュレーションの 後で実行されるチェックのロジックが必

要ならば、check()フェーズを拡張しその中に手続き型のコードを組み込むことができます。こ

のコードはシミュレーションの 後で実行されます。組み込みのフェーズの使用に関するさらに

詳しい情報は SystemVerilog OVM Class Reference の ovm_phase を参照してください。 高位レベルから見た、今存在するシミュレーション・フェーズ（シミュレーションの順序に）は： • build() 113 ページ • connect() 114 ページ • end_of_elaboration() 114 ページ • end_of_simulation() 114 ページ • run() 114 ページ • extract() 115 ページ • check() 116 ページ • report() 116 ページ

build() OVM フェーズ・メカニズムの 初のフェーズは build()フェーズで、これは自動的に全てのコ

ンポーネントでトップダウンにコールされます。build()メソッドはそのコンポーネントの子コ

ンポーネントを生成しオプションでそれらを再構成します。build()はトップダウンにコールさ

れるため、親のコンフィギュレーション・コールは子の build()メソッドがコールされる前に終

了します。勧められませんが親のコンポーネントは明示的にその子の build()を parent.build()の一部としてコールすることができます 。 buildフェーズはファンクションで、時間 0 で実行します。

class my_comp extends ovm_component; ...

virtual void function build(); super.build(); // Get configuration information. // Create child components. // configure child components endfunction

...

endclass

113

connect() connect()フェーズは build()の後に実行されます。環境はコンポーネントの build()の間に

トップダウンの方法で作成されるため、ユーザは階層的なテスト／環境／コンポーネントのトポ

ロジは connect()がコールされるとき完全に生成されているとみなすことができます。 このフェーズはファンクションで、時間 0 で実行します。

class my_comp extends ovm_component; ...

virtual void function connect(); if(is_active == OVM_ACTIVE) driver.seq_item_port.connect(sequencer.seq_item_export); for(int i = 0; i<num_subscribers; i++) monitor.analysis_port.connect(subscr[i].analysis_export); ... endfunction

...

endclass

end_of_elaboration() end_of_elaboration()フェーズは環境が構築され接続された後、 終的な調整をすることが

できるようにします。ユーザはこのメソッドがコールされる前に環境が完全に生成され接続され

ていると仮定することができます。このフェーズはファンクションで、時間 0 で実行します。

start_of_simulation() start_of_simulation フェーズはバナーの表示や 終的なテストベンチのトポロジやコンフ

ィギュレーションの情報のプリントのような pre_run()アクティビティを実行する便利な場所

を提供します。このフェーズはファンクションで、時間 0 で実行します。

run() run()フェーズは唯一のあらかじめ定義された、時刻を進めるフェーズで、コンポーネントの主要

な実行時の実装を定義します。タスクとしてインプリメントされているので、ほかのプロセスを

フォーク（fork）することができます。

114

コンポーネントがその実行から戻ると、その実行フェーズの終了を知らせません。フォークした

全てのプロセスは実行し続けます。実行フェーズは 3 つの方法のいずれかで終了します。 • stop － コ ン ポ ー ネ ン ト の enable_stop_interrupt ビ ッ ト が セ ッ ト さ れ

global_stop_request がコールされると、コンポーネントの stopタスクがコールされ

ます。コンポーネントは stopを実行中のトランザクションを終了させ、キューをなくして

しまうなどのことをインプリメントできます。全ての有効なコンポーネントの stopからの

戻りで、killが出されます。 • kill － コールされると、全てのコンポーネントの runプロセスは直ちに強制終了されま

す。killを直接コールすることができる一方、コンポーネントは終了の仕組みを使用する

ことが薦められます。この方がより順序だった安全なシャットダウンができます。 • timeout － もしタイムアウトがセットされているならば、stop や kill が起こる前に

フェーズの時間がなくなるとそれは終了します。 次はドライバとシーケンサ・コンポーネントの run()フェーズのタスクを記述しています。 • シーケンサ － シーケンサはスティミュラス・データを生成し、それを実行のためにドラ

イバに渡し、そしてデフォルト・シーケンスを開始します。シーケンサは指定された制約で

データ・アイテムを生成し、ランダム化しそれをドライバに渡します。このアクティビティ

は自動的に SystemVerilog OVM Class Library によって取り扱われます。 • ドライバ － リセットのアサーションがはずされると、ドライバはシーケンサから次に実

行されるアイテムを得て、プロトコルごとに HDL 信号をドライブします。現在のアイテム

が終了すると、ドライバは“アイテム終了”指示を出します。プロアクティブなエージェン

ト（マスタ）のドライバはテストの指示によってバス上の転送を開始します。リアクティブ

なエージェント(スレーブ)のドライバはアクションを開始するというよりはむしろバス上

のトランスファに応答します。このアクティビティはユーザによって指定されます。

extract() このフェーズは次のフェーズでチェックする前に、シミュレーション結果を抽出するために使わ

れます。通常これはシミュレーション結果を処理するようなユーザ定義のアクティビティのため

に使われます。次がこのフェーズで何ができるかの例です。 • アサーションエラーのカウントの収集 • カバレッジ情報の抽出 • DUT の内部の信号やレジスタの値の抽出 • コンポーネントから内部変数の値を抽出 • コンポーネントから統計情報やほかの情報の抽出

115

このフェーズはファンクションで 0 の時間で実行されます。これはボトムアップの順にコールさ

れます。

check() 前のフェーズで必要なシミュレーション結果を抽出したあと、checkフェーズを使ってそのよう

なデータを検証し全体のシミュレーション結果を決定します。このフェーズはファンクションで、

時間 0 で実行します。これはボトムアップの順でコールされます。

report() このフェーズは 後に実行され、結果をファイルとスクリーンの両方かいずれかに出力するのに

使われます。このフェーズはファンクションで、時間 0 で実行します。これはボトムアップの順

でコールされます。

ユーザ定義のフェーズの追加

上にリストされたあらかじめ定義されたフェーズに加え、OVM はリストのどこでも自身のフェ

ーズを加えることができるようにする ovm_phaseベース・クラスを提供します。 新しいフェーズの定義をするために： 1） ovm_phaseのサブクラスを継承し、新しいフェーズが時間を進める（タスク）かそうでない

か（ファンクション）によって call_task()か call_function()メソッドをインプリメ

ントします。

1 class my_comp extends ovm_component;

2 ...

3 virtual my_task(); return; endtask // make virtual

4 ...

5 endclass

6

7 class my_task_phase extends ovm_phase;

8 function new();

9 super.new("my_task",1,1);

116

10 endfunction

11 task call_task(ovm_component parent);

12 my_comp_type my_comp;

13 if ($cast(my_comp,parent))

14 my_comp.my_task_phase()

15 endtask

16 virtual function string get_type_name ();

17 return "my_task";

18 endfunction

19 endclass

9行目 super.new()をコールしているとき新しいサブクラスは3つの引数を供給しなければな

りません： • フェーズ名、これは通常コールバック・メソッドの名前 • メソッドがトップダウンでコールされるか（1）、ボトムアップでコールされるか（0）を指示

するビット • メソッドがタスクか（1）もしくはファンクションか（0）を指示するビット 注意：OVM は新しいフェーズの定義を簡単化するためにいくつかのマクロを含んでいます。

‘define ovm_phase_task_decl(NAME,TOP_DOWN)

‘define ovm_phase_func_topdown_decl(NAME) ‘ovm_phase_func_decl(NAME,1)

‘define ovm_phase_func_bottomup_decl(NAME) ‘ovm_phase_func_decl(NAME,0)

‘define ovm_phase_task_topdown_decl(NAME) ‘ovm_phase_task_decl(NAME,1)

‘define ovm_phase_task_bottomup_decl(NAME) ‘ovm_phase_task_decl(NAME,0)

2） 新しいフェーズのオブジェクトのインスタンスを宣言します。

my_task_phase my_task_ph = new();

3） OVM のフェーズ・コントローラ、ovm_top、を使ってフェーズを登録します。

ovm_top.insert_phase(my_task_ph, run_ph);

2 番目の引数、run_ph、はその後ろに新しいフェーズが挿入されるフェーズです。フェーズをリ

ストの 初に挿入したいならば、この引数は NULL でなければなりません。

組み込みのファクトリとオーバーライド

117

ファクトリについて

OVM は組み込みのファクトリを提供し、生成されるオブジェクトの正確なクラスを指定せずに

コンポーネントがオブジェクトを生成できるようにします。ファクトリはこの機能を、組み込み

の newファンクションの代わりにスタティックなアロケーション・ファンクションを使って提供

します。

type_name::type_id::create(string name, ovm_component parent)

create()メソッドは自動的にタイプ・スペシフィックであるため、コンポーネントやオブジェ

クトを生成するために使うことができます。オブジェクトを生成するとき、2 番目の引数、parent、

はオプションです。 ファクトリを使ってデータ・オブジェクトを生成するコンポーネントは次のようなコードを実行

します。

task mycomponent::run(); mytype data; // Data must be mytype or derivative. data = mytype::type_id::create("data");

$display("type of object is: %0s", data.get_type_name()); ... endtask

上のコードで、コンポーネントはファクトリからインスタンス名が“data”でタイプが“mytypeであるオブジェクトをリクエストしています。 ファクトリがこのオブジェクトを生成すると、このオブジェクトのインスタンス名と完全に一致

するインスタンス・オーバーライドを探します。もしインスタンス・スペシフィックなオーバー

ライドが見つからないと、ファクトリはタイプ“mytype”のタイプワイドのオーバーライドを探

します。もし、どのタイプ・オーバーライドも見つからなければ、生成されたタイプはタイプ

“mytype”になります。

ファクトリへの登録

ファクトリに対し特定のタイプのオブジェクトを生成する方法を言わなければなりません。OVMでは、このアロケーションを行うのにいくつかの方法があります。 • `ovm_object_utils(T) も し く は `ovm_component_utils(T) マ ク ロ を そ れ ぞ れ

118

ovm_objectもしくは ovm_componentの派生クラスで使います。これらのマクロは与えら

れたタイプをファクトリに登録するコードを拡張します。引数の T はパラメータ化されたタ

イプが可能です。

`ovm_object_utils(packet)

‘ovm_component_utils(my_driver)

• ̀ ovm_object_registry(T,S)か'ovm_component_registry(T,S)のいずれかの登録

マクロを使います。これらのマクロはTのクラス宣言スペースのどこにでもあることができ、

ストリング S をオブジェクト・タイプ T に関連付けます。これらのマクロは対応する

ovm_*_utilsマクロによってコールされるため、ovm_*_utilsマクロを使わないときだけ

それらを使うことになります。

コンポーネントのオーバーライド

グローバル・ファクトリがあらかじめ定義されたコンポーネント・タイプをニーズに特化したほ

かのコンポーネント・タイプに置き換えることができるように提供され、コンテナ・タイプを導

く必要はありません。ファクトリはコンポーネントの階層の中で階層のほかのコンポーネントを

変えることなしにコンポーネント・タイプを置き換えることができます。 グローバル・ファクトリはこの目的のため利用可能です。ファクトリの使い方を知る必要があり

ますが、ファクトリがどのように動作するかは知る必要はありません。 注意：全てのタイプ・オーバーライドのコードは子（達）を構築する前に、親の中で実行されな

ければなりません。これは環境のオーバーライドはテストの中で指定されなければならないこと

を意味します。 2 つのインタフェースの set_type_override_by_type と set_inst_override_by_type

はデフォルト・コンポーネントを置き換えるためにあります。これらのインタフェースは一度に

一つ調べられます。 デフォルト・コンポーネントをオーバーライドするために： 1） 適切な OVM ベース・クラスから派生したクラスを定義します。 2） オーバーライドを実行します（次のセクションで記述されています）。 3） 環境を構築します。 タイプのオーバーライド

119

初のコンポーネント・オーバーライドは指定されたタイプの全てのコンポーネントを新しい指

定されたタイプで置き換えます。プロトタイプは次のようになります。

set_type_override_by_type(orig_type, override_type, bit replace = 1);

初の引数(orig_type)はタイプ(orig_type::get_type())のスタティックな get_type()

メ ソ ッ ド を コ ー ル す る こ と に よ り 得 ら れ ま す 。 そ の タ イ プ は 2 番 目 の 引 数

(override_type::get_type())によってオーバーライドされます。3 番目の引数、replace、は今あるオーバーライド（replace=1）を置き換えるかどうか決定します。もしこのビットが 0で与えられたタイプのオーバーライドが存在しないならば、オーバーライドはファクトリに登録

されます。もしこのビットが 0 で与えられたタイプのオーバーライドが存在するならば、オーバ

ーライドは無視されます。 もしオーバーライドが指定されていないならば、環境はデフォルト・タイプを使って構築されま

す。例えば、環境は xbus_master_agent.build()の中の xbus_master_driverタイプ・コ

ンポーネントを使って生成されます。set_type_override_by_type インタフェースにより、

xbus_master_driver の全てのインスタンスに対し xbus_new_master_driver を持たせる

ようにこの動作をオーバーライドすることができます。

set_type_override_by_type(xbus_master_driver::get_type(), xbus_new_master_driver::get_type);

こ れ は デ フ ォ ル ト タ イ プ の （ xbus_master_driver ） を 新 し い タ イ プ の

（ xbus_new_master_driver） に オ ー バー ラ イ ドし ま す 。こ の ケ ース で は 環境が

xbus_master_driver を作成すべきときに生成されたタイプをオーバーライドしています。完

全な階層は 120 ページの図 6－1 に示されているように構築されています。 注意：この例では一つだけ xbus_master_driver のインスタンスが置き換えられていますが、

どんな全ての xbus_master_driverインスタンスも複数の xbus_master_driversを含む環

境で置き換えることができます。 図 6－1 set_type_override()を適用されて作成された階層

120

インスタンス・オーバーライド

2番目のコンポーネントのオーバーライドは新しく定義されたタイプでマッチングするイン

スタンス・パスのターゲット・コンポーネントを置き換えます。ovm_componentのプロト

タイプは次のようになります。

set_inst_override_by_type(string inst_path, orig_type, override_type);

初の引数の inst_path はインスタンス・オーバーライドの相対的なコンポーネント名です。

それはオーバーライドの”ターゲット”と考えることができます。2 番目の引数 org_type はオ

ーバーライドされるタイプ (orig_type::get_type()で指定されます)で、 後の引数

override_type（override_type：：get_type（）も使っています）で指定されたタイプに

よって置き換えられます。 xbus_new_slave_monitor が既に定義されていると仮定します。次のコードが実行されると、

環境は新しいタイプ xbus_new_slave_monitor をインスタンス・パスにマッチする全てのイ

ンスタンスに対し作成します。

set_inst_override_by_type(“slaves[0].monitor”, xbus_slave_monitor::get_type(), xbus_new_slave_monitor::get_type());

このケースでは、オーバーライドのインスタンス・パスに一致した slaves[0].monitor イン

スタンスにだけ環境が xbus_slave_monitorを生成したとき、生成されたタイプをオーバーラ

121

イドします。完全な階層は 122 ページの図 6－2 に示されているように構築されます。 例示の目的で、この階層は両方のオーバーライドが実行されたと仮定しています。 図 6－2 両方のオーバーライドが適用され手生成された階層

注意：インスタンス・オーバーライドは 初に一致の順で使われます。各コンポーネントに、

初の適用可能なインスタンス・オーバーライドが、環境が構築されたときに使われます。もしど

のインスタンス・オーバーライドも見つからなければ、適用できるタイプ・オーバーライドにタ

イプ・オーバーライドが探されます。インスタンスのオーバーライドの適用はコードのインスタ

ンス・オーバーライドの順序に影響されます。 初に、より特別なインスタンス・オーバーライ

ドを実行します。例えば：

set_inst_override_by_type("a.b.*", mytype::get_type(), newtype::get_type());

set_inst_override_by_Type("a.b.c", mytype::get_type(), different_type::get_type());

これは different_typeで a.b.cを生成します。mytypeの a.bの下のほかのすべてのオブジ

ェクトは newtype を使って生成されます。もしインスタンス・オーバーライド・コールの順序

を入れ替えるならば、a.bの下の全てのオブジェクトは”newtype”になり、インスタンス・オ

122

ーバーライド a.b.cは無視されます。

set_inst_override_by_type("a.b.c", mytype::get_type(), different_type::get_type());

set_inst_override_by_type("a.b.*", mytype::get_type(), newtype::get_type());

高度なシーケンス・コントロール このセクションはシーケンス・コントロールの高度なテクニックを議論します。次のようなサブ

セクションを含んでいます。 • “複雑なシナリオの実装” 123 ページ • “プロトコルのレイヤ化” 129 ページ • “シーケンスの生成に関する高度なアスペクト” 139 ページ

複雑なシナリオの実装

このセクションは次のようなサブセクションを含んでいます。 • 複数シーケンスの並列実行 123 ページ • 割り込みシーケンス 125 ページ • アイテムのスケジューリングのコントロール 127 ページ • シーケンスに関連する実行時のコントロール 128 ページ 複数シーケンスの並列実行 並列実行のシーケンスを作成する 2 つの方法があります。 • フォーク／ジョイン（fork/join）で ovm_do マクロを使用 • start()メソッドを使って並列にいくつかのシーケンスを開始 次のセクションが各メソッドの例を示しています。 フォーク／ジョイン（fork/join）で ovm_do マクロを使用 この例では、シーケンスはフォーク／ジョイン（fork/join）で実行されます。シミュレータはど

のシーケンスがシーケンサとのやり取りをリクエストしているかスケジュールします。シーケン

123

サはどのアイテムがドライバに提供されるか、実行のためにアイテムを提供しようとするシーケ

ンス間のアービトレーションを行い、一度に一つ選択しスケジュールを行います。a と b のシー

ケンスは fork_join_sequenceのサブシーケンスです。

class fork_join_sequence extends ovm_sequence #(simple_item); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” a_seq a; b_seq b;

virtual task body(); fork `ovm_do(a) `ovm_do(b) join endtask : body endclass : fork_join_sequence

並列にいくつかのシーケンスを開始 この例では、concurrent_sequence が 2 つのシーケンスを並列に起動をかけます。これはシ

ーケンスの終了を待ちません。その代わり、シーケンスに起動をかけるとすぐに終了します。ま

た aと bはルート・シーケンスとして開始されます。

class concurrent_seq extends ovm_sequence #(simple_item); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” a_seq a; b_seq b;

virtual task body(); // Initialize the sequence variables with the factory. `ovm_create(a) `ovm_create(b) // Start each subsequence as a new thread. fork a.start(p_sequencer); b.start(p_sequencer); join endtask : body endclass : concurrent_seq

注意：sequence.start()メソッドはシーケンスがどのシーケンサ上でも開始されることを可能

とします。 さらに詳しくは Systemverilog OVM Class Reference の ovm_create を参照してください。

124

pre_body()と post_body()コールバックの使用 Systemverilog OVM Class Library はさらに２つのコールバック・タスク pre_body()と

post_body()を提供し、これらはシーケンスの body()タスクの前と後にそれぞれ起動がかけら

れます。これらのコールバックはシーケンスがそのシーケンサの start_sequence()タスクか

シーケンスの start()タスクによって開始されたときのみ起動がかけられます。 pre_body()と post_body()コールバックの使用例には次のものがあります。 • body()タスクが始まる前にあるイベントに同期させる • body()タスクが終了したときクリーンアップ・タスクをコールする 次の例は新しいシーケンス・タイプを宣言し、そのコールバック・タスクをインプリメントしま

す。

class revised_seq extends fork_join_sequence; ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence”

task pre_body(); super.pre_body(); // Wait until initialization is done. @p_sequencer.initialization_done; endtask : pre_body

task post_body(); super.post_body(); do_cleanup(); endtask : post_body endclass : revised_seq

pre_body()と post_body()コールバックは`ovm_doマクロの一つによって実行されるシーケ

ンスでは起動をかけられません。 注意：シーケンサに宣言されている initialization_doneイベントは p_sequencer 変数を使

って直接アクセスできます。p_sequencer 変数は`ovm_sequence_utilsマクロが使われたため

利用可能です。これは適当なタイプを宣言し$castを使ってその初期化を行う必要性を防ぎます。 割り込みシーケンス DUT は割り込みのオプションを持っているかもしれません。通常、割り込みはエージェントのあ

る応答とセットになっていなければなりません。割り込みのサービスが始まると、割り込みの前

のアクティビティはそれが割り込まれたところから再開しなければなりません。検証環境はシー

125

ケンスを使って割り込みをサポートできます。 シーケンスを使った割り込みを取り扱うために： 1） 次のことを行う割り込みハンドラ・シーケンスを定義します。

a) 割り込みのイベントが起こるのを待ちます。 b) 排他的なアクセスのためにシーケンサをグラブします。 c) 適当なアイテムとシーケンスを使って割り込みサービスのオペレーションを実行します。 d) シーケンサをアングラブします。

2） シーケンサもしくはデフォルト・シーケンスで割り込みハンドラ・シーケンスを開始します。

（シミュレーションが始まるとき、デフォルト・シーケンスを実行するようにシーケンサを

再構成することができます。） 例 1） 割り込みハンドラのシーケンス定義を行います。

// Upon an interrupt, grab the sequencer, and execute a // read_status_seq sequence. class interrupt_handler_seq extends ovm_sequence #(bus_transfer); ... // Constructor and OVM automation macros here // See “Creating and Adding a New Sequence”

read_status_seq interrupt_clear_seq; virtual task body(); forever begin // Initialize the sequence variables with the factory. @p_sequencer.interrupt; grab(p_sequencer); `ovm_do(interrupt_clear_seq) ungrab(p_sequencer); end endtask : body endclass : interrupt_handler_seq

2） シーケンサで割り込みハンドラ・シーケンスを開始します。下の例はこれを実行フェーズで、

シーケンサ自身で行います。

class my_sequncer extends ovm_sequencer; ... // Constructor and OVM automation macros here // See “Creating and Adding a New Sequence”

interrupt_handler_seq interrupt_seq;

virtual task run(); interrupt_seq = interrupt_handler_seq::type_id::create("interrupt_seq");

126

interrupt_seq.start(this); super.run(); endtask : run endclass : my_sequncer

注意：どの`ovm＿do マクロもシーケンスでしか使えないため、このステップでは使えません。

その代わり、シーケンサ自身のユーティリティファンクションを使い、共通ファクトリを通して

割り込みハンドラ・シーケンスのインスタンスを生成します。 アイテムのスケジューリングのコントロール アイテムを並列に実行するいくつかのシーケンスがあるかもしれません。しかし、ドライバは一

度にひとつしか取り扱えません。そのため、シーケンサは do アクションのキューを管理します。

ドライバがアイテムを要求すると、シーケンサはキューで待っている do アクションから実行す

べき一つの do アクションを選択します。そのため、シーケンスがアイテムを実行しているとき、

do アクションはシーケンサがそれを選択する準備ができるまでまたされます。 スケジューリングのアルゴリズムは 初に来たものが 初にサービスを受ける方法です。このア

ルゴリズムに grab()、ungrab()、is_relevant()を使って影響を与えることができます。 もしシーケンスがシーケンサをグラブしていると、シーケンサは次の条件をみたす 初の do アク

ションを選択します。 • それが、グラブしているシーケンスかその子や子孫となるシーケンスで実行されている • それを実行しているシーケンスの is_relevant()メソッドが 1 を返す。 もし選択すべき do アクションがないならば、get_next_item()はブロックされます。シーケン

サは次のいずれかが起こると再び選択しようと試みます（すなわち、スケジューリング・アルゴ

リズムに再起動がかけられます） • 別の do アクションがキューに加えられる。 • 新しいシーケンスがシーケンサをグラブするか、現在グラブしているものがシーケンサをア

ングラブする。 • ブロックされているシーケンスの wait_for_relevant()タスクのいずれかが戻ってくる。

さらに詳しくは 128 ページの“シーケンス関連の実行時のコントロール”を参照してくださ

い。 try_next_item() を コ ー ル す る と き 、 も し シ ー ケ ン サ が

ovm_driver::wait_for_sequences()で指定された時間を過ぎても do アクションを選択で

きなかった場合、ovm_driver::try_next_time()は NULL とともに戻ります。

127

シーケンス関連の実行時のコントロール あるアプリケーションでは、ほかのシーケンスと並列にシーケンスに起動をかけある条件でそれ

らにアイテムを実行させます。そのようなシーケンスはそのため、現在の状態、これは DUT の

状態を含むか、検証環境のほかのコンポーネントの状態を含むか、もしくは両方か、にしたがっ

て検証環境で関連もしくは非関連になります。これをインプリメントするには、シーケンス

is_relevant()のファンクションを使うことができます。スケジューリングにおけるその効果

は 127 ページの“アイテムのスケジューリングのコントロール”に議論されています。 もし is_relevant()を使っているならば、ある条件でシーケンサがハングアップするのを防ぐ

ため、wait_for_relevant()タスクをインプリメントしなければなりません。次の例が両方の

使用を例示しています。

class flow_control_seq extends ovm_sequence #(bus_transfer); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence”

bit relevant_flag; function bit is_relevant(); return(relevant_flag); endfunction

// This task is started by the sequencer if none of the running // sequences is relevant. The task must return when the sequence // becomes relevant again. task wait_for_relevant(); while(!is_relevant()) @(relevant_flag); // Use the appropriate sensitivity list. endtask

task monitor_credits(); ... // Logic goes here to monitor available credits, setting // relevant_flag to 1 if enough credits exist to send // count frames, 0 otherwise. endtask : monitor_credits

task send_frames(); my_frame frame; repeat (count) `ovm_do(frame) endtask : send_frames

virtual task body(); fork monitor_credits(); send_frames(); join_any endtask : body endclass : flow_control_seq

128

プロトコルのレイヤ化

このセクションはプロトコルのレイヤ化とそのシーケンスを使ったインプリメントの方法を議論

します。 このセクションは次のものを含みます。 • “レイヤ化入門” 129 ページ • “レイヤ化のスタイル” 132 ページ • “レイヤ化されたシーケンサの使用” 136 ページ レイヤ化入門 ある検証環境は異なるプロトコルのデータ・アイテムのレイヤ化を必要とします。例として IP 上

の TCP や Sonet 上の ATM があります。、レイヤ化されたプロトコルの実装を生成するためにシ

ーケンサが構成される 2 つの方法に、シーケンスのレイヤ化とバーチャル・シーケンスがありま

す。 プロトコルのレイヤ化 プロトコルのレイヤ化の古典的な例はプロトコルの汎用のより高位もしくはより低位レベル（も

しくはレイヤ）によって記述されます。バイトの配列は低位レベル・プロトコルでは意味がない

かもしれませんが、一方高位のプロトコルの文脈では配列はコントロールと適切に処理されるべ

きデータ・メッセージを提供します。 例えば、2 つのシーケンスがあると仮定します。低位レイヤ・シーケンサは次のように定義され

る lower_layer_itemsをドライブします。

class lower_layer_item extends ovm_sequence_item; ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” bit[`MAX_PL:0][`DATA_SIZE-1:0] payload;

endclass : lower_layer_item

低位レベル・シーケンスのベース・クラスは次のように定義されます。

class lower_layer_seq_base extends ovm_sequence #(lower_layer_item); ... // Constructor and OVM automation macros go here.

129

// See “Using Sequences” lower_layer_item item; virtual task body(); ... endtask : body endclass : lower_layer_seq_base

あるケースで、ランダムデータで lower_layer_items を送りたいかもしれません。別のケー

スでは、データが高位のレイヤのデータ・プロトコルから来てほしいかもしれません。この例の

高位のレイヤのプロトコルは higher_layer_items をドライブし、これは一つ以上の

lower_layer_itemsにマップされます。そのため、高位レベル・シーケンスのベース・クラス

は次のように定義されます。

class higher_layer_seq_base extends ovm_sequence #(higher_layer_item); ... // Constructor and OVM automation macros // See “Using Sequences” higher_layer_item item; virtual task body(); ... endtask : body endclass : higher_layer_seq_base

レイヤ化とシーケンス レイヤ化はシーケンスで もよくインプリメントできます。シーケンスを使ったレイヤ化の方法

は 2 つあります： • ページ 130 の“一つのシーケンサの内部にレイヤ化”は簡単なケースのときだけ適用されま

す。 • ページ 136 の“レイヤ化されたシーケンスの使用”は全てのレイヤ化に適用されます。 一つのシーケンサの内部にレイヤ化 簡単なケースでは、低位のレイヤ・シーケンスの中で高位のレイヤのデータ・アイテムを生成す

ることによって一つのシーケンサの内部にレイヤ化することができます。低位のシーケンサにも

う一つのシーケンス・カインドを生成することによりこれを行います。例えば：

class use_higher_level_item_seq extends lower_layer_base_seq; ... // Constructor and OVM automation macros go here. // See “Using Sequences”

higher_layer_item hli; lower_layer_item lli;

130

task body(); // Create a higher-level item. `ovm_create(hli) ... // Randomize it here. send_higher_level_item(hli); endtask : body

task send_higher_level_item(higher_layer_item hli); for(int i = 0 ; i< hli.length; i++) begin // Convert the higher-level item to lower-level items and send. `ovm_create(lli); ... // Slice and dice hli to form property values of lli. `ovm_send(lli) end endtask : send_higher_level_item endclass: use_higher_level_item_seq

use_higher_level_item_seq シーケンスは一つの higher_layer_item を生成し、それを

一塊で一つ以上の lower_layer_itemsに、higher_layer_itemのデータがなくなるまで送

ります。さらに詳しくは SystemVerilog OVM Class Reference の ovm_create を参照してくださ

い。 いくつかのシーケンサのレイヤ化 いくつかのシーケンサのレイヤ化の一般的なアプローチは下の 131 ページの図 6－3 に示される

ように複数のシーケンサを使います。 図 6－3 レイヤ化のアーキテクチャ

131

higher_layer_itemと lower_layer_itemの例をとると、低位のレイヤのシーケンスと高位

のレイヤのシーケンス（それらのシーケンサで完全です）があります。低位のレイヤのシーケン

スは高位のレイヤのシーケンサ（もしくは高位のドライバ）からデータをプルします。 各シーケンサは OVC でカプセル化し、レイヤ化が OVC を接続することによってできるようにし

ます。 レイヤ化のスタイル このセクションは次のセクションを含んでいます： • “基本レイヤ化” 133 ページ • “一対一、一対多数、多数対一、多数対多数” 133 ページ • “実行前生成と実行中で異なるコンフィギュレーション” 134 ページ • “タイミング・コントロール” 134 ページ • “データ・コントロール” 135 ページ • “複数シーケンサでシーケンスのコントロール” 135 ページ

132

基本のレイヤ化 も簡単な基本レイヤ化の一般シナリオは次のものから構成されます：

• ドライバがレイヤ 1 のアイテムを受け取る。 • レイヤ 1 のアイテムはある方法でレイヤ２のアイテムから構築される。レイヤ２のアイテム

は今度は、レイヤ３のアイテムから構築され以下同じです。 • 全てのレイヤ N とレイヤ N+１は、レイヤ N+1 のアイテムをとりそれらをレイヤ N のアイテ

ムに変換する仕組みがあります。 複数の種類のレイヤ１とレイヤ２のアイテムを持つことができます。異なるコンフィギュレーシ

ョンでは、任意の種類のレイヤ２のアイテムを任意の種類のレイヤ１のアイテムに重ねたいかも

しれません。 このセクションの残りは、特定のプロトコルか、求めるテスト作成の柔軟性による変化や複雑化

について記述します。 図６－４ プロトコルのレイヤ化

一対一、一対多数、多数対一、多数対多数 変換の仕組みは次のような状態に対処できる必要があります（134 ページの図６－５参照）。 • 一対一 － 一つの高位のレイヤ・アイテムが一つの低位のレイヤに変換されなければなら

ない。 • 一対多数 － 一つの大きな高位のレイヤ・アイテムが多くの低位のレイヤ・アイテムに分

解されなければならない。 • 多数対一 － 多くの高位のレイヤ・アイテムが一つの大きな低位のレイヤ・アイテムに結

合されなければならない（例えば Sonet でのように）。 • 多数対多数 － 複数の高位のレイヤ・アイテムが取り込まれ複数の低位のレイヤ・アイテ

ムに変換されなければならない。例えば、高位レイヤ・パケットが 10 バイトで、低位レイヤ・

パケットは 3 から 35 バイトです。このケースのとき余りが出ることがあります。

133

図 6－5 レイヤ・マッピング

実行前生成と実行中で異なるコンフィギュレーション システムはトポロジ、データ・タイプ、またはほかのアプリケーション特有の要求によって定義

されるいろいろな動作モードをサポートする必要があるかもしれません。例えば、ある環境では、

レイヤ 1 のアイテムだけしか持たないかもしれません。別の環境では、レイヤ 1 のアイテムはレ

イヤ 2 のアイテムから指示を受けるかもしれません。またレイヤをさらに分解して、レイヤ 2 の

アイテムが、レイヤ 1 のアイテムかレイヤ 1 のセル（または別のインタフェース）もしくは両方

のいずれかをドライブできるようにしたいかもしれません。 時には実行時に複数のソースから入力のミックスを受けるかもしれません。例えば、一つの低位

のレイヤのシーケンサに、いくつかの高位のレイヤのシーケンサから来たアイテムを送信させた

いかもしれません。 タイミング・コントロール あるコンフィギュレーションでは、高位レイヤ・アイテムが完全にタイミングをドライブします。

高位レイヤ・アイテムが作成されると、それらは直ちに低位レイヤ・アイテムに変換されます。 ほかのコンフィギュレーションでは、低位レイヤのシーケンスはオペレーションのペースを決め

ます。低位のレイヤの do マクロが実行されると対応する高位のレイヤのアイテムが 0 の時間で現

れなければなりません。 後に、アイテムが DUT に低位のレイヤのシーケンスのタイミングに従ってドライブされ、し

かし高位のレイヤのシーケンスは 0 の時刻で反応しないケースがあります。もし高位のレイヤか

134

らデータが利用可能でない場合、代わりにあるデフォルト値（例えば 0 が充たされたもの）が使

われます。ovm_driver::try_next_item()がこのケースの場合低位のレベルのドライバで使

われます。 データ・コントロール あるコンフィギュレーションでは、高位レイヤ・アイテムがどの低位レイヤ・アイテムが DUTに届くかを完全に指示します。低位レイヤは単にスレーブとして動作します。 しばしば、しかし、両方のレイヤが、なにが DUT に届くか影響を及ぼすことがあります。例え

ば、高位レイヤが DUT に届くアイテムのペイロードのデータに影響を及ぼし、一方低位のレイ

ヤがほかのアトリビュートに影響することがあります。これらのケースで、両方のレイヤのため

のシーケンスを選択することが、意味があります。 複数のシーケンサ上のシーケンスのコントロール

も一般的なケースで、いくつかのシーケンサで構成されたグラフがあり、いくつかはほかのシ

ーケンサでのシーケンスの実行をコントロールし、あるものは直接アイテムを生成するかもしれ

ません。ある低位レイヤの“ドライバ・シーケンス”は DUT に接続され、ある高位のレイヤの

ドライバ・シーケンスはそれらの上に重ねられ、ある上のシーケンサが下の全てのドライバ・シ

ーケンサに供給します。 ページ 135 の図 6－6 に示されている例題のコンフィギュレーションで、低位レイヤのシーケン

サ（L1B）は、コントロールしているシーケンサからと同様、複数の高位のレイヤ・シーケンサ

（2 つの L2A のインスタンス）から入力を得ます。 図 6－6 バーチャル・シーケンスを使った も一般的なケース

135

レイヤ化されたシーケンサの使用 レイヤ化されたシーケンサは次のように働きます。 • より高位のレイヤ・シーケンサは通常通り動作し、より上位のレイヤのデータ・アイテムを

生成し、そしてそれらを、seq_item_pull_export を通して送信します。ほとんどのケー

スで、レイヤ化されたアプリケーションにおいて、上位のレイヤ・シーケンサやシーケンス

を変更する必要はありません。 • 低位のレイヤ・シーケンサは高位のレイヤ・シーケンサにつながり、そこから情報を取り出

さなければなりません。取り出された情報は（高位のレイヤ・アイテムは）シーケンスのプ

ロパティに置かれ次に低位のレイヤ・アイテムのいろいろなプロパティを制約するために使

われます。レイヤ間の実際の接続はシーケンサとドライバ間の接続と同じようになされます。

高位のレイヤのシーケンサに接続するには、低位のレイヤのシーケンサに対応する

ovm_seq_item_pull_portを宣言しなければなりません（137 ページの例 6－1 参照）。接

続そのものは含んでいるオブジェクトの connect()メソッドが起動されたときに実行され

ます。 • 低位のレイヤのシーケンサは、DUT のフィジカル・インタフェースとやり取りする低位のレ

136

イヤのドライバに情報を送ります。 既に上位レイヤと下位レイヤのシーケンサを生成している（または再利用している）ならば、下

のステップに従いレイヤ化を行ってください。 シーケンサをレイヤ化するために：

1） 次のことを行う低位レイヤのシーケンスを生成します。

• 上位のレイヤ・シーケンサから繰り返し上位のレイヤのアイテムを引き出します。

• それらを下位レイヤのアイテムに変換します。

• それらを下位レイヤのドライバに送ります。 上位レイヤ・アイテムの生成を遅らせることを保つために、上位レイヤ・アイテムを下位

シーケンスの pre_do()タスクの中から引き出します。これは低位のレイヤのドライバが

マッチングした低位のレイヤのアイテムの処理を開始する準備ができたときだけ、上位レ

イヤのアイテムがランダム化されることを確かなものにします。 2） 低位のレイヤのシーケンサを、ドライバをシーケンサに接続するときと同じテクニッ

クを使って高位のレイヤのシーケンサに接続します。 3） 低位のレイヤのシーケンサのデフォルト・シーケンスを上のステップ 1 で生成したシ

ーケンスに再構成します。 例 6－1 レイヤ・シーケンサの例 前に生成されたコンポーネントから上位と下位レイヤ・クラスを再利用していると仮定します。

下位レイヤのコンポーネントはインタフェース・プロトコルをモデリングしているエージェント

の中にカプセル化されているものと思われます。この例はコードをコンパクトに保つために勧め

られている再利用の構造を導入せずにレイヤ化を達成する方法を示しています。

// Upper-layer classes class upper_item extends ovm_sequence_item; ... endclass : upper_item

class upper_sequencer extends ovm_sequencer #(upper_item); ... endclass : upper_sequencer

// Lower-layer classes class lower_item extends ovm_sequence_item; ... endclass : lower_item

class lower_sequencer extends ovm_sequencer #(lower_item); ovm_seq_item_pull_port #(upper_item) upper_seq_item_port;

137

... function new (string name, ovm_component parent); super.new(name, parent); upper_seq_item_port = new(“upper_seq_item_port”,this); `ovm_update_sequence_lib_and_item(...) endfunction : new ... endclass : lower_sequencer

class lower_driver extends ovm_driver #(lower_item); ... endclass : lower_driver

これから、上位レイヤ・アイテムを引き出す下位レイヤ・シーケンスは上位レイヤ・アイテムを

引き出し、それらを下位レイヤ・アイテムに変換します。

class higher_to_lower_seq extends ovm_sequence #(lower_item); ... // Constructor and OVM automation macros go here. // See “Using Sequences” upper_item u_item; lower_item l_item;

virtual task body(); forever begin `ovm_do_with(l_item, { ... }) // Constraints based on u_item end endtask : body

// In the pre_do task, pull an upper item from upper sequencer. virtual task pre_do(bit is_item); p_sequencer.upper_seq_item_port.get_next_item(u_item); endtask : pre_do

// In the post_do task, signal the upper sequencer we are done. // And, if desired, update the upper-item properties for the // upper-sequencer to use. virtual function void post_do(ovm_sequence_item this_item); p_sequencer.upper_seq_item_port.item_done(this_item); endfunction : post_do

endclass : higher_to_lower_seq

次の例は低位のレイヤ・シーケンサと上位レイヤ・シーケンサの接続を例示しています。 注意：低位のレイヤのシーケンサはインタフェース OVC の中にカプセル化されていることが多

いと考えられ、そのためこれは env とエージェントでカプセル化されます。これによりレイヤ化

のスキームは変わりませんが、シーケンサ間の接続は tb ファイルで変更することになります。

低位のシーケンサからそのドライバへの接続がエージェントの connect()フェーズで行われるの

に対し、上位のシーケンサから低位のシーケンサへの接続は通常 tb env で行われます。

138

// This code resides in an env class.

lower_driver l_driver0; lower_sequencer l_sequencer0; upper_sequencer u_sequencer0;

function void build(); super.build(); // Make lower sequencer execute upper-to-lower translation sequence. set_config_string("l_sequencer0", "default_sequence", "higher_to_lower_seq"); // Build the components. l_driver0 = lower_driver::type_id::create(“l_driver0”, this); l_sequencer0 = lower_sequencer::type_id::create((“l_sequencer0”, this); u_sequencer0 = upper_sequencer::type_id::create((“u_sequencer0”, this);

endfunction : build

// Connect the components. function void connect(); // Connect the upper and lower sequencers. l_sequencer0.upper_seq_item_port.connect(u_sequencer0.seq_item_export); // Connect the lower sequencer and driver. l_driver0.seq_item_port.connect(l_sequencer0.seq_item_export); endfunction : connect

シーケンスの生成に関連した高度なアスペクト

このセクションは次のサブセクションを含みます：

• 生成されたシーケンスのカインドのランダム化 139ページ

• あらかじめアイテムまたはシーケンスの生成 141ページ

• ほかのシーケンサでシーケンスとアイテムの実行 143ページ

生成されたシーケンスのカインドのランダム化 あるケースでは、あるシーケンスを生成し、それがランダムにほかのシーケンス・タイプを選択

しそして実行することができるようにするのは役に立ちます。次の例はこれを達成するいくつか

の方法を示しています。 `ovm_sequence_utilsはシーケンス・タイプを特定のシーケンサのシーケンス・ライブラリに

登録します。seq_kind プロパティはシーケンス・ライブラリで、シーケンス・タイプによって

特定のタイプを識別するのに使われます。例えば、get_seq_kind(“simple_seq_do”)はシーケ

ンス・タイプ simple_seq_doを識別するのに使われる整数を返します。

139

注意：与えられたシーケンス・タイプの seq_kindの整数値はシミュレーションごとに変えるこ

とができるため、タイプと seq_kind 値の間の正しいマッピングを保証するために

get_seq_kind()ファンクションを使うべきです。 例 6－2 分散したシーケンス生成 次の例はあるシーケンスを 10 回実行します。毎回シーケンスのタイプ（seq_kind）が分散の制

約を使ってランダム化されます。

class distribution_sequence extends ovm_sequence #(bus_transfer); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence”

virtual task body(); repeat(10) begin assert( this.randomize(seq_kind) with { seq_kind dist { get_seq_kind("a_seq") := 1, get_seq_kind("b_seq") := 2, get_seq_kind("c_seq") := 5} ; } ); // Invoke a sequence of the selected seq_kind. do_sequence_kind(seq_kind); end endtask : body endclass : distribution_sequence

ランダムな選択 次の例はあるシーケンサを示しておりこれは、取り除きたいものを除いてこのシーケンサに登録

されている任意のシーケンス・タイプからランダムに選択します。これは将来追加したいと思う

どのユーザ定義のシーケンスからも選択でき、役に立つアプローチです。下のコード例でシーケ

ンス・タイプの a_seqだけが選択されないようになっています。

class infinity_minus_sequence extends ovm_sequence #(bus_transfer); ...// Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence”

function new(string name="infinity_minus_sequence"); super.new(name); endfunction

`ovm_sequence_utils(infinity_minus_sequence, xbus_master_sequencer)

virtual task body(); // Run any sequence in the sequence library except a_seq. for (int i=0; i<p_sequencer.count; i++) begin

140

assert( this.randomize(seq_kind) with { seq_kind != get_seq_kind("ovm_simple_sequence"); } ); // Invoke a sequence of the selected kind. do_sequence_kind(seq_kind); end endtask : body endclass

あらかじめアイテムまたはシーケンスの生成 いろいろな`ovm_do*マクロは、オブジェクトの割付（シーケンスまたはシーケンス・アイテム）、

ドライバとの同期化（もし必要ならば）、ランダム化、ドライバへの送信などを含めいくつかのス

テップを順次に実行します。SystemVerilog OVM Class Library はこれらのいろいろなステップ

をより詳細にコントロールできるようにする追加のマクロを提供します。このセクションはこれ

らのマクロを説明します。 `ovm_create このマクロは共通ファクトリを使ってオブジェクトを割付けそのプロパティを初期化します。そ

の引数はタイプ ovm_sequence_item もしくは ovm_sequence の変数です。このマクロを

SystemVerilog の constraint_mode()と rand_mode()ファンクションと一緒に使うことがで

き、それに続くシーケンスかシーケンス・アイテムのランダム化をコントロールします。 次の例では、my_seq は今までに議論されてきたシーケンスと同様です。主要な違いは

`ovm_create(item0)コールを使用することです。このマクロ・コールの後、rand_mode()と

constraint_mode()ファンクションの使用があり、item0のプロパティへのいくつかの直接代

入があります。item0の操作は、それにメモリが割り付けられているため可能ですが、ランダム

化はまだ起こっていません。これに続くセクションはこのあらかじめ生成されたアイテムをドラ

イバに送る可能なオプションをレビューします。

class my_seq extends ovm_sequence #(my_item); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” virtual task body(); `ovm_create(req) req.addr.rand_mode(0); // Disables randomization of addr req.dc1.constraint_mode(0); // Disables constraint dc1 req.addr = 27; ... endtask : body endclass: my_seq

141

シーケンス変数を`ovm_createの引数として使うこともできます。 注意：コンフリクトを防ぐため制約を無効にする必要があるかもしれません。 `ovm_send このマクロは 63 ページの図 4－6 や 64 ページの図 4－7 に示されるように、割付やランダム化な

しに ovm_sequence_itemもしくは ovm_sequenceのクラス・ハンドル引数を処理します。シ

ーケンス・アイテムはシーケンサのキューに置かれ処理を待ちますが、一方サブシーケンスは直

ちに処理されます。親の pre_do()、mid_do()、そして post_do()コールバックは示されるよ

うにまだ起こります。 次の例では、ページ 63 の図 4－6 に示されるように割付やランダム化なしにシーケンス・アイテ

ムを処理する`ovm_send と一緒にシーケンス・アイテムを事前割付するための ovm_create()

の使用を示しています。

class my_seq2 extends ovm_sequence #(my_item); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” virtual task body(); `ovm_create(req) req.addr = 27; req.data = 4; // No randomization. Use a purely pre-generated item. `ovm_send(req) endtask : body endclass: my_seq2

同様に、シーケンス変数を上の`ovm_createと`ovm_sendコールに供給でき、その場合シーケ

ンスは 64 ページの図 4－7 で示される方法で割付やランダム化なしに処理されます。 ‘ovm_rand_send、'ovm_rand?send_with これらのマクロは 132 ページの ovm_sendと、処理の前に与えられたクラス・ハンドルをランダ

ム化するという一つの違いを除いて同一です。これはクラス制約を遅いランダム化にまだ使用し

ている間、すなわち、ドライバがアイテムを要求しているサイクルでのランダム化の間に、必要

に応じてオブジェクトを調整することを可能とします。̀ ovm_rand_send()はオブジェクト・ハ

ンドルだけを取ります。̀ ovm_rand_send_with()はもう一つの引数をとり、これはランダム化

のために使われるいかなる有効なインライン制約でもかまいません。

142

次の例は`ovm_create の使用を示しており、61 ページの図 4－6 示されるように割付なしにシ

ーケンス・アイテムを処理する`ovm_rand_send*マクロと一緒にシーケンス・アイテムを事前

に割り付けます。rand_mode()と constraint_mode()コンストラクトがオブジェクトのラン

ダム化の詳細なコントロールを示すために使われています。

class my_seq3 extends ovm_sequence #(my_item); ... // Constructor and OVM automation macros go here. // See “Creating and Adding a New Sequence” virtual task body(); `ovm_create(req) req.addr.rand_mode(0); req.dc1.constraint_mode(0); req.addr = 27; // Randomize and process the item. `ovm_rand_send(req)

// Randomize and process again, this time with inline constraints. `ovm_rand_send_with(req, {data < 1000;}) endtask : body endclass: my_seq3

ほかのシーケンサでシーケンスとアイテムの実行 今までのセクションでは、全ての ovm_do マクロ（とその派生物）は指定されたアイテムもしく

はシーケンスを現在の p_sequencer 上で実行します。シーケンスがアイテムやほかのシーケン

スを指定されたシーケンサで実行できるようにするため、求めるシーケンサの詳細指定を可能と

する追加のマクロ派生物が含まれています。 ``ovm_do_on, `ovm_do_on_with, `ovm_do_on_pri, `ovm_do_on_pri_with これら全てのマクロは、これら全てが一つ追加の引数（常に 2 番目の引数）をとり、これは指定

されたシーケンサのリファレンスであるという点を除いて、ルートのバージョンと全く同じです。

‘ovm_do_on(s_seq, that_sequencer);

‘ovm_do_on_with(s_seq, that_sequencer, {s_seq.foo == 32’h3;})

143

Xbus OVC の例 この章は XBus OVC の基本アーキテクチャを紹介します。またシミュレーションで実行し体験で

きるように、実行可能なデモについても議論します。OVC アーキテクチャを理解するための更な

る手助けとして XBus ソースコードが提供されます。自身のシミュレーション環境を開発すると

き、XBus のプロトコルは参考にならなくても、OVC としての構造には従うべきです。 全ての XBus OVC サブコンポーネントは SystemVerilog Class Library のあるベース・クラスか

ら継承しているので、この章を読むときは SystemVerilog OVM Class Reference が参照できるよ

うにしておいてください。ほとんど追加のコードなしに、直ちに得られる豊富な機能を完全に評

価するためにこれらのベース・クラスの機能を知り、理解し、使用することは重要です。もしま

だそれをしていないならば、10 ページの“OVM のインストール”に記述されているように

SystemVerilog OVM Class Library がインストールされているか確認してください。 また XBus 仕様の章で XBus の仕様に慣れている必要があります。必須ではありませんが、XBusプロトコルの理解は XBus プロトコル特有の機能をプロトコルに依存しない OVC のアーキテク

チャから識別する手助けになります。 この章は次のセクションを含んでいます。 • “XBus デモ” 145 ページ • “XBus デモ・アーキテクチャ” 148 ページ • “XBus トップ・モジュール” 149 ページ • “テスト” 150 ページ • “テストベンチ環境” 154 ページ • “XBus 環境 ” 156 ページ • “XBus エージェント” 158 ページ • “XBus シーケンサ” 159 ページ • “XBus ドライバ” 160 ページ • “XBus エージェント・モニタ” 161 ページ • “XBus バス・モニタ ” 162 ページ • “XBus インタフェース” 164 ページ

144

XBus デモ XBus デモはひとつのマスタとひとつのスレーブよりなる検証環境を構築します。デフォルトの

テストでは、XBus スレーブは slave_memoryシーケンスを使ってコミュニケーションを行いま

す。XBus マスタの read_modify_writeシーケンスは XBus スレーブのメモリ・デバイスの動

作を検証します。

XBus の例の実行の指示はOVM キットのexamples/xbus/examples ディレクトリのreadme.txtファ

イルにあります。

下のシミュレーションの出力は環境を含むXBus テストベンチのトポロジを示しています。環境

は一つのアクティブ・マスタと一つのアクティブ・スレーブ・エージェントを含んでいます。

テストはread_modify_write シーケンスを実行し、これはread byte シーケンスとそれに続く

write byte シーケンスを起動し、もう一つの read byte シーケンスが続きます。アサーションが2

番目のread byte シーケンスで読まれたデータが、write byte シーケンスで書かれたデータと同一

かを検証します。テストが OVM_VERBOSITY = OVM_LOWでシミュレーションされると、次の出

力が生成されます。

[0] hier=__global__: Running test test_read_modify_write...

[0] hier=ovm_test_top: Printing the test topology:

----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------

ovm_test_top test_read_modify_w+ - @719

xbus_demo_tb0 xbus_demo_tb - @716

scoreboard0 xbus_demo_scoreboa+ - @710

item_collected_ex+ ovm_connector_base - @1068

disable_scoreboard integral 1 'h0

num_writes integral 32 'd0

num_init_reads integral 32 'd0

num_uninit_reads integral 32 'd0

recording_detail ovm_verbosity 32 OVM_FULL

xbus0 xbus_env - @713

bus_monitor xbus_bus_monitor - @874

masters[0] xbus_master_agent - @998

145

slaves[0] xbus_slave_agent - @939

has_bus_monitor integral 1 'h1

num_masters integral 32 'h1

num_slaves integral 32 'h1

intf_checks_enable integral 1 'h1

intf_coverage_ena+ integral 1 'h1

recording_detail ovm_verbosity 32 OVM_FULL

recording_detail ovm_verbosity 32 OVM_FULL

----------------------------------------------------------------------

[190] hier=ovm_test_top.xbus_demo_tb0.scoreboard0: READ to empty address...Updating address : 7f4e with data : 15

[190] hier=ovm_test_top.xbus_demo_tb0.xbus0.bus_monitor: Transfer collected :

----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------

xbus_transfer_inst xbus_transfer - @1394

addr integral 16 'h7f4e

read_write xbus_read_write_en+ 32 READ

size integral 32 'h1

data da(integral) 1 -

[0] integral 8 'h15

wait_state da(integral) 0 -

error_pos integral 32 'h0

transmit_delay integral 32 'h0

master string 10 masters[0]

slave string 9 slaves[0]

begin_time time 64 150

end_time time 64 190

----------------------------------------------------------------------

[320] hier=ovm_test_top.xbus_demo_tb0.scoreboard0: WRITE to existing address...Updating address : 7f4e with data : 16

[320] hier=ovm_test_top.xbus_demo_tb0.xbus0.bus_monitor: Transfer collected :

----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------

xbus_transfer_inst xbus_transfer - @1394

addr integral 16 'h7f4e

read_write xbus_read_write_en+ 32 WRITE

146

size integral 32 'h1

data da(integral) 1 -

[0] integral 8 'h16

wait_state da(integral) 0 -

error_pos integral 32 'h0

transmit_delay integral 32 'h0

master string 10 masters[0]

slave string 9 slaves[0]

begin_time time 64 300

end_time time 64 320

----------------------------------------------------------------------

[410] hier=ovm_test_top.xbus_demo_tb0.scoreboard0: READ to existing address...Checking address : 7f4e with data : 16

[410] hier=ovm_test_top.xbus_demo_tb0.xbus0.bus_monitor: Transfer collected :

----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------

xbus_transfer_inst xbus_transfer - @1394

addr integral 16 'h7f4e

read_write xbus_read_write_en+ 32 READ

size integral 32 'h1

data da(integral) 1 -

[0] integral 8 'h16

wait_state da(integral) 0 -

error_pos integral 32 'h0

transmit_delay integral 32 'h0

master string 10 masters[0]

slave string 9 slaves[0]

begin_time time 64 370

end_time time 64 410

----------------------------------------------------------------------

[2000] hier=ovm_test_top: Calling global_stop_request() to end the run phase

[2000] hier=ovm_test_top.xbus_demo_tb0.scoreboard0: Reporting scoreboard information...

----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------

147

scoreboard0 xbus_demo_scoreboa+ - @710

item_collected_export ovm_connector_base - @1068

recording_detail ovm_verbosity 32 OVM_FULL

disable_scoreboard integral 1 'h0

num_writes integral 32 'd1

num_init_reads integral 32 'd1

num_uninit_reads integral 32 'd1

recording_detail ovm_verbosity 32 OVM_FULL

----------------------------------------------------------------------

--- OVM Report Summary ---

** Report counts by severity

OVM_INFO : 10

OVM_WARNING : 0

OVM_ERROR : 0

OVM_FATAL : 0

** Report counts by id

[DEBUG] 9

[RNTST] 1

Simulation complete via $finish(1) at time 2 US + 7

XBus デモ・アーキテクチャ

148ページの図7－1はこのリリースで配布されるXBus デモの例の中のXBusシミュレーション環

境のテストベンチ・トポロジを示しています。

図7－1 XBusデモ・アーキテクチャ

148

XBus トップ・モジュール

XBusテストベンチはトップレベル・モジュールでインスタンシエートされ、クラス・ベースのシ

ミュレーション環境を生成します。下の例はXBus特有の内容を持つ例題のDUTを使用します。例

は意識的に簡単なものにし、注意をXBus OVC 環境に向けるようにしてあります。

トップ・モジュールは典型的なHDL コンストラクトとSystemVerilogインタフェースを含んでいま

す。このインタフェースはクラス・ベースのテストベンチと DUTを接続するために使われます。

テストベンチ内部の XBus 環境はSystemVerilog インタフェースを参照するのにバーチャル・イ

ンタフェース変数を使います。次の例はXBusインタフェース(xi0) と例題のDUT が一緒に接続

されているのを示しています。DUTとテストベンチをシミュレーションするのに使われる

run_test() コマンドは次のセクションでカバーされます。

Example 7-1 xbus_tb_top.sv

1 module xbus_tb_top; 2

3 `include "xbus.svh"

149

4 `include "test_lib.sv"

5

6 xbus_if xi0(); // SystemVerilog interface to the DUT

7

8 dut_dummy dut(

9 xi0.sig_request[0],

10 ...

11 xi0.sig_error

12 );

13

14 initial begin

15 run_test();

16 end

17

18 initial begin

19 xi0.sig_reset <= 1'b1;

20 xi0.sig_clock <= 1'b1;

21 #51 xi0.sig_reset = 1'b0;

22 end

23

24 //Generate clock.

25 always

26 #5 xi0.sig_clock = ~xi0.sig_clock;

27

28 endmodule

XBus SystemVerilog インタフェースはトップレベルのテストベンチ・モジュールでインスタンシ

エートされています。インタフェースは信号に一般に受け入れられた命名法を使い、XBus プロ

トコルのほかの実装で用いられている命名法と簡単にマッピングができるようにしています。

DUTピンはインタフェース・インスタンスの内部の信号に直接接続しています。現在、信号は単

純な方向性を持たない変数で、DUT かまたはバーチャル・インタフェースを通したクラス・ベー

スのテストベンチ環境のいずれかでドライブされます。XBus インタフェースはフィジカル・チ

ェックを行うためにコンカレント・アサーションを含んでいます。さらに詳しくは105ページの

“DUTの正しさのチェック”と164ページの“XBusインタフェース”.を参照してください。

テスト

150

OVMでは、テストは別のクラスのtest_read_modify_writeで定義されます。これは

xbus_demo_base_test から継承され、これはこんどはovm_testから継承されます。

xbus_demo_base_test テストはxbus_demo_tb オブジェクトを構築し、テストのrun()フェ

ーズを管理します。test_read_modify_writeのような引き続き派生されるテストは下の例で

示されるようにこの機能を強化します。

`ovm_component_utils マクロを使う全てのクラスは共通ファクトリの ovm_factory に登

録されます。トップ・モジュールが. run_test(test_name)をコールすると、ファクトリにタ

イプ test_nameでテストのインスタンスを作成するよう要求があり、次にシミュレーションが

開始します。run_test が引数なしでコールされたときは、+OVM_TESTNAME=test_name コ

マンドラインのオプションがチェックされ、もしあれば、そのタイプ名を持ったテストが生成さ

れ実行されます。もしどちらも見つからなければ、全ての構築されたコンポーネントがシミュレ

ーション・サイクルを回ります。さらに詳しくは、84ページの“ユーザ定義のテストの生成と選

択”を参照してください。

Example 7-2 test_lib.sv

1 `include "xbus_demo_tb.sv"

2

3 class xbus_demo_base_test extends ovm_test;

4

5 `ovm_component_utils(xbus_demo_base_test)

6

7 xbus_demo_tb xbus_demo_tb0; // XBus verification environment

8 ovm_table_printer printer;

9

10 function new(string name = "xbus_demo_base_test",

11 ovm_component parent=null);

12 super.new(name, parent);

13 endfunction

14 // OVM build() phase

15 virtual function void build();

16 super.build();

17 // Enable transaction recording.

18 set_config_int("*", "recording_detail", OVM_FULL);

19 // Create the testbench.

20 xbus_demo_tb0 = xbus_demo_tb::type_id::create("xbus_demo_tb0", this);

21 // Create a specific-depth printer for printing the topology.

151

22 printer = new();

23 printer.knobs.depth = 3;

24 endfunction

25 // Built-in OVM phase

26 function void end_of_elaboration();

27 // Set verbosity for the bus monitor.

28 xbus_demo_tb0.xbus0.bus_monitor.set_report_verbosity_level(OVM_FULL);

29 // Print the test topology.

30 this.print(printer);

31 endfunction : end_of_elaboration();

32 // OVM run() phase

33 task run();

34 #2000;

35 // Call global_stop_request() to end the run phase.

36 global_stop_request();

37 endtask

38 endclass

1行目はテストに必要なファイルをインクルードします。この例で使われているテストベンチは

xbus_demo_tb で、デフォルトでバス・モニタ、一つのマスタ、一つのスレーブを含んでいま

す。154ページの“テストベンチ環境”を参照してください。

3－5行目 全てのテストはovm_test クラスから継承されなければならず、

`ovm_component_utils かまたは

`ovm_component_utils_begin/`ovm_component_utils_end マクロを使わなければなり

ません。さらに詳しくは SystemVerilog OVM Class Reference を参照してください。

7行目 テストベンチを宣言します。これはテストのbuild()ファンクションによって構築され

ます。

8行目 ovm_table_printerタイプのプリンタを宣言し、これは後でトポロジのプリントに使

われます。これはオプションの機能です。コンフィギュレーションに定義されているトポロジと

シミュレーションのために生成されたテストベンチの関係を見るのは役に立ちます。利用可能な

異なるタイプのプリンタはSystemVerilog OVM Class Reference を参照してください。

15－24行目はベース・テストのために build() ファンクションを指定します。必要に応じて、

buildはオーバーライドされた全てのフィールドをアップデートするように、 初に

super.build()ファンクションをコールします。次にxbus_demo_tbがcreate()ファンクシ

ョンを使って生成されます。xbus_demo_tb のbuild()ファンクションがbuild()の間 OVM

152

ライブラリのフェーズの仕組みによって実行されます。ユーザは明示的に

xbus_demo_tb0.build()をコールする必要はありません。

26－31行目はベース・テストのために end_of_elaboration() ファンクションを指定します。

このファンクションは全てのコンポーネントのbuild() とconnect()フェーズが実行されてか

らコールされます。この時点で、テストは完全なテストベンチ階層が生成され全てのテストベン

チの接続がなされているとみなすことができます。テストのトポロジがプリントされます。

33－37行目はテストベンチに run() タスクを指定します。このケースでは、シミュレーション

は2000 タイムユニット実行します。 後に、シミュレーションはglobal_stop_request()

ファンクションを使って停止されます。

ベース・テストが定義されたため、派生したテストが調べられます。次のコードがtest_lib.sv

ファイルの続きです。

class test_read_modify_write extends xbus_demo_base_test; `ovm_component_utils(test_read_modify_write) function new(string name = "test_read_modify_write", ovm_component parent=null); super.new(name,parent); endfunction

virtual function void build(); // Set the default sequence for the master and slave. set_config_string("xbus_demo_tb0.xbus0.masters[0].sequencer", "default_sequence", "read_modify_write_seq"); set_config_string("xbus_demo_tb0.xbus0.slaves[0].sequencer", "default_sequence", "slave_memory_seq"); // Create the testbench. super.build(); endfunction

endclass

派生したテスト、test_read_modify_write、のbuild() ファンクションを考えます。この

build() ファンクションはread_modify_write_seq のオーバーライドをマスタ・エージェ

ントのシーケンス・シーケンサに登録し、またslave_memory_seqのオーバーライドをスレー

ブ・エージェントのシーケンス・シーケンサに登録します。これらのオーバーライドが実行され

ると、super.build()がコールされ、これはxbus_demo_tb0をxbus_demo_base_test ビル

ド・ファンクションに指定されたように生成します。

run()タスク・実装はtest_read_modify_write によって継承されますが、これはこのテス

トがxbus_demo_base_testから継承されているからです。その実装はこのテストに十分なため、

何もする必要はありません。これは大幅にテストを簡単化します。

テストベンチ環境

153

このセクションはページ151の“test_lib.sv”に生成されたテストベンチを議論します。

xbus_demo_tb を生成するコードがここで繰り返されています。

xbus_demo_tb0 = xbus_demo_tb::type_id::create("xbus_demo_tb0", this);

図7－2 ovm_envから派生したテストベンチ

一般に、テストベンチは任意のタイプ（xbus, pci, ahb, ethernetなどの）の任意の数のenvs (OVCs) を

含むことができます。XBus デモは一つのマスタ・エージェントと、一つのスレーブ・エージェ

ントと一つのバス・モニタ（153ページの図7－2を参照）を持った、単一のXBus(OVC)環境で構成

される簡単なテストベンチを生成します。次のコードはこのコンフィギュレーションを指定する

クラスを定義します。テストはこのクラスのインスタンスを生成します。

Example 7-3 xbus_demo_tb.sv

1 function void xbus_demo_tb::build();

2 super.build();

3 set_config_int("xbus0", "num_masters", 1);

4 set_config_int("xbus0", "num_slaves", 1);

5 xbus0 = xbus_env::type_id::create("xbus0", this);

6 scoreboard0 = xbus_demo_scoreboard::type_id::create("scoreboard0", this);

7 endfunction : build

8

9 function void xbus_demo_tb::connect();

10 // Connect the slave0 monitor to scoreboard.

11 xbus0.slaves[0].monitor.item_collected_port.connect(

12 scoreboard0.item_collected_export);

13 // Assign interface for xbus0.

154

14 xbus0.assign_vi(xbus_tb_top.xi0);

15 endfunction : connect

16

17 function void end_of_elaboration();

18 // Set up slave address map for xbus0 (basic default).

19 xbus0.set_slave_address_map("slaves[0]", 0, 16'hffff);

20 endfunction : end_of_elaborationct

1行目 build()ファンクションを宣言します。

2行目 全てのオーバーライド・フィールドをアップデートするためにsuper.build()をコール

します。これは重要で、テストベンチを生成するテストがテストベンチにオーバーライドを登録

するかもしれないからです。super.build() をコールすることはこれらのオーバーライドがア

ップデートされることを確かなものにします。

3－4行目 set_config_int コールはxbus_env のnum_masters とnum_slaves コンフィ

ギュレーション・フィールドを調節します。この場合、xbus_envの xbus0インスタンスが操作

されます。3行目はxbus_envの xbus0インスタンスにひとつのマスタ・エージェントを含むよ

うに指示します。xbus_env のnum_masters プロパティはいくつのマスタ・エージェントが作

られるべきか指定します。num_slavesも同様です。

5行目 xbus0と名づけられた xbus_env インスタンスを生成します。create() コールはタイ

プ xbus_env がインスタンス名 xbus0で生成されるよう指定します。

6行目 xbus0に関しては、スコアボードが生成されます。

9行目 connect()ファンクションを宣言します。

10－14行目 xbus0 環境とscoreboard0の間の必要な接続を作ります。2つの接続が作られま

す：

• xbus0.slaves[0].monitor のアナリシスポートとscoreboard0インスタンスのアナリ

シエクススポートの間のTLM接続

• XBusトップ・モジュールでインスタンシエートされた SystemVerilog インタフェースへのア

サインメント、もしくは“接続”。このアサインメントによりテストベンチはDUTとコミュ

ニケーションできるようになります。

17行目 Declare the OVM フェーズに組み込まれたend_of_elaboration()を宣言します。

155

19行目 slaves[0]にスレーブ・アドレス・マップをアサインします。これは.

end_of_elaboration()が完全なテストベンチが生成され接続されていると期待しているため、

build()と connect()ファンクションが終了してから行えます。

XBus 環境

xbus_env コンポーネントは任意の数のXBus マスタとスレーブのエージェントを含んでいます。

このデモでは、xbus_env (156ページの図7－3に示されています)は一つのマスタと一つのスレー

ブ・エージェントだけを含むように再構成されています。

注意：バス・モニタはデフォルトで生成されています。

図7－3 bus_envのインスタンス

xbus_envのbuild() ファンクションはマスタ・エージェント、スレーブ・エージェント、そし

てバス・モニタを生成します。3つのプロパティが、これらが生成されるかどうかをコントロール

します。ソースコードがここに示されています。

1 function void xbus_env::build();

2 string inst_name;

3 super.build();

4 if(has_bus_monitor == 1) begin

5 bus_monitor = xbus_bus_monitor::type_id::create("bus_monitor", this);

6 end

7 masters = new[num_masters];

8 for(int i = 0; i < num_masters; i++) begin

9 $sformat(inst_name, "masters[%0d]", i);

156

10 masters[i] = xbus_master_agent::type_id::create(inst_name, this);

11 set_config_int({inst_name, "*"}, "master_id", i);

12 end

13 slaves = new[num_slaves];

14 for(int i = 0; i < num_slaves; i++) begin

15 $sformat(inst_name, "slaves[%0d]", i);

16 slaves[i] = xbus_slave_agent::type_id::create("xbus_slave_agent",

17 this);

18 inst_name));

19 end

20 endfunction: build

1行目 build() ファンクションを宣言します。

3行目 super.build()をコールします。これは任意のオーバーライドごとに、コンフィギュレ

ーション・フィールド (num_masters、num_slaves、has_bus_monitor) がアップデートさ

れることを保証します。

4－6行目 has_bus_monitor コントロール・フィールドが1にセットされているならば、バス・

モニタを生成します。create ファンクションが生成に使われます。

7－12行目 マスタのダイナミックな配列はnum_masters コントロール・フィールドによってサ

イズが決められます。これはfor loop がnum_masters コントロール・フィールドに従ってダイ

ナミックな配列の中を埋めることを可能とします。マスタ・エージェントのインスタンスに使わ

れるインスタンス名は$sformatを使って構築され、インスタンス名が完全にダイナミック配列

の識別子と一致するようにします。for loop の繰り返しも使われ、マスタ・エージェントの

master_id プロパティと全てのその子（アステリスクの使用を通して）に対するコンフィギュ

レーション・オーバーライドを登録するのに使われます。これはどのリクエスト－許可のペアが

マスタ・エージェントによってドライブされるか定義します。

13－19行目 上のマスタ・エージェント生成コードにあるように、このコードはnum_slaves を

使ってスレーブ・エージェントを生成し、コンフィギュレーション・オーバーライドを必要とし

ません。

XBus エージェント

157

xbus_master_agent (ページ157の図7－4に示されているように) とxbus_slave_agent は

同じように構成されていますが、唯一つの違いはそのサブコンポーネントのプロトコル特有のフ

ァンクションの違いです。

XBus マスタ・エージェントはシーケンサ、ドライバ、モニタの3つのサブコンポーネントまで含

みます。デフォルトで、3つ全てが生成されます。しかし、コンフィギュレーションはエージェン

トがパッシブ(is_active=OVM_PASSIVE) と指定でき、これは, シーケンサとドライバの生成を

無効にします。xbus_master_agent はovm_agentから継承されます。

図7－4 xbus_master_agentインスタンス

xbus_master_agentのbuild() ファンクションはドライバ、シーケンサ、モニタを生成する

よう指定されます。is_active プロパティはドライバとシーケンサが生成されるかどうかをコ

ントロールします。

1 function void xbus_master_agent::build();

2 super.build();

3 monitor = xbus_master_monitor::type_id::create("monitor", this);

4 if (is_active == OVM_ACTIVE) begin

5 sequencer = xbus_master_sequencer::type_id::create("sequencer", this);

6 driver = xbus_master_driver::type_id::create("driver", this);

7 end

8 endfunction : build

9

10 function void xbus_master_agent::connect();

11 if (is_active == OVM_ACTIVE) begin

12 driver.seq_item_port.connect(sequencer0.seq_item_export);

13 end

14 endfunction

1行目 build() ファンクションを宣言します。

158

2行目 super.build()をコールします。これは任意のオーバーライドごとにコンフィギュレー

ション・フィールド(is_active) がアップデートされることを保証します。

3行目 モニタを生成します。モニタは常に生成されます。生成はコントロール・フィールドの条

件にはよりません。

4－7行目 is_active コントロール・フィールドがOVM_ACTIVEにセットされているならば、

シーケンサとドライバを生成します。create_component ファンクションが生成に使われます。

10行目 connect()ファンクションを生成します。

11－13行目 ドライバはシーケンサからトランザクションを期待するため、両方のコンポーネン

トのインタフェースはconnect() ファンクションを使って接続されなければなりません。エー

ジェント（モニタ、シーケンサ、ドライバを生成する）はその子のインタフェース同士を接続す

る責任があります。

XBus シーケンサ

このコンポーネントはドライバへのシーケンス・アイテムの流れ（159ページの図7－5を参照）を

コントロールします。シーケンサはどのシーケンス・アイテムがドライバに供給されるかをコン

トロールします。ovm_sequencer ベース・クラスは3つの組み込みシーケンス

ovm_random_sequence、 ovm_exhaustive_sequence、 ovm_simple_sequence を含ん

でいます。さらに詳しくは66ページの“あらかじめ定義されたシーケンス”を参照してください。

default_sequence プロパティは開始するシーケンスを選択します。デフォルトで、タイプ

ovm_random_sequence のシーケンスが開始します。

図7－5 xbus_master_sequencerインスタンス

159

ユーザ定義のシーケンサがオプションのバーチャル・インタフェースを提供し、シーケンスがプ

ロトコルのフィジカル信号と同期が取れるようにします。xmi 変数はフィジカルSystemVerilogイ

ンタフェースにアサインされる簡単なSystemVerilog バーチャル・インタフェース・リファレンス

です。XBus環境が構築された後、xmi 変数はまだ定義されていません。この変数をシミュレーシ

ョンを開始する前にセットしなければならず、直接代入かIP開発者によって提供された

assign_vi() という便利なメソッドを使っておこないます。このXBus の例は環境で

assign_vi() と呼ばれるファンクションを提供し、これはエージェントの子のバーチャル・イ

ンタフェースをアサインします。この使用はXBus デモ・データベースで見ることができます。

シーケンサのコンストラクタは必要とされる super.new()コールで始まり、

`ovm_update_seqeunce_lib_and_item マクロが続きます。このマクロは静的に登録された

全てのシーケンスを、このシーケンサで実行できる全てのシーケンスを含むシーケンサのローカ

ル・ライブラリにコピーするファンクション・コールに発展します。利用可能なほかのシーケン

スやシナリオの中からランダムに選択するシーケンスを容易に生成することができます。

XBus ドライバ

このコンポーネントはxmi バーチャル・インタフェース・プロパティ(下の160ページの図7－6参

照)を使ってXBus 信号のインタフェースをドライブします。xbus_master_driver は

xbus_transfer トランザクションをシーケンサから取り、フィジカル・プロトコルの定義にも

とづいて処理します。XBus の例では、 seq_item_portメソッドの get_next_item() と

item_done() がシーケンサからトランザクションを取り出すためにアクセスされます。

図7－6 xbus_master_driverインスタンス

ドライバの主要な役割は信号レベルのプロトコルに従ってXBus にドライブ（マスタのとき）か

応答（スレーブのとき）することです。これはrun()タスクでおこなわれ、OVMの組み込みフェ

ージング（112ページの“シミュレーション・フェーズ・メソッド”で議論されています）の一部

160

として自動的に起動されます。マスタ・ドライバでは、コア・ルーチンは次のように要約できま

す：

task xbus_master_driver::run(); ... @(negedge xmi.sig_reset);

forever begin // Repeat the following forever. @(posedge xmi.sig_clock); seq_item_port.get_next_item(item); // Pull item from sequencer. ... drive_transfer(item); // Drive item onto signal-level bus. ... seq_item_port.item_done(); // Indicate we are done. end

endtask

sig_reset 信号のアサーションがはずされると、ドライバのrunタスクは

global_stop_request()タスクを使って止められるまで永遠に走り続けます。XBus プロトコ

ルに特有の実装のより深い理解を得るためにXBus ドライバのソースコードを調べることが勧め

られます。

XBus エージェント・モニタ

XBus モニタはXBus 信号レベルのインタフェース (161ページの図7－7参照)に見られる

xbus_transfers を収集します。もしチェックとカバレッジがあれば、これらに対応するファ

ンクションも同様に実行されます。

図7－7 Instance of xbus_master_monitorのインスタンス

XBusマスタ・モニタの主要な役割はXBus 上のマスタ・インタフェースのアクティビティをサン

プリングし、親のマスタ・エージェントにのみ属するxbus_transfer トランザクションを収集

します。収集されるトランザクションはTLMアナリシスポートを通して外部の世界に提供されま

す。モニタはシミュレーション・フェージングの一部として自動的に起動をかけられる実行タス

161

クでこの義務を果たします。実行タスクはその義務を実行しているときにほかのタスクをフォー

クしたり、ほかのファンクションやタスクをコールすることができます。正確な実装はプロトコ

ルやプログラマに依存していますが、しかしエントリ・ポイントの実行タスクは、全てのコンポ

ーネントで同じです。シミュレーション・フェーズについてさらに詳しくは112ページの“シミュ

レーション・フェーズ・メソッド”を参照してください。

モニタの機能はrun() タスクを使って定義されている無限ループに含まれています。

global_stop_request() はデフォルトによりrun() タスクの終了を引き起こし、ほかのシミ

ュレーション・フェーズが完了しシミュレーションが終了することを可能とします。

チェックはプロトコル特有のチェックを行わせ、カバレッジは収集された xbus_transfersか

らファンクショナル・カバレッジを収集する責任があります。

XBus バス・モニタ

XBus バス・モニタはXBus の信号レベルのインタフェースに見られたxbus_transfersを収集

し、ステート・トランザクションを通してステータスのアップデートを発信しバス上に異なるア

クティビティがあることを指示します。XBus バス・モニタにはクラスchecksがあり、もしチェッ

クとカバレッジ収集が有効にされていると、カバレッジを収集します。XBus バス・モニタはXBus

環境の中でインスタンシエートされます。

xbus_env build() ファンクションにはhas_bus_monitorと呼ばれるコントロール・フィー

ルドがあり、これはxbus_bus_monitorが生成されるかどうかを決定します。このバス・モニタ

は、このフィールドのデフォルト値が1であるため、デフォルトで生成されます。

set_config_int インタフェースを使いこの値を上書きできます。

set_config_int("xbus0", "has_bus_monitor", 0);

ここでxbus_envのxbus0 インスタンスはそのhas_bus_monitor コントロール・フィールド

が0に上書きされます。そのため、xbus0のxbus_bus_monitor は存在しません。

has_bus_monitor コントロール・フィールドを使う xbus_env の build()ファンクション

は156ページの“XBus環境”にあります。

バスからのトランスファーの収集

XBus バス・モニタはどのマスタとスレーブがバス上でトランスファーをしているかを示すマス

タとスレーブを含め、xbus_transferのフィールドを埋めます。これらのフィールドはスレー

162

ブがマスタによって開始されたとき適切なアドレスの範囲に応答することを確実にするため必要

です。

XBus プロトコルでは、バス上の各マスタはマスタ・エージェントのIDによって定義された専用

のリクエスト信号と専用の許可信号があります。どのマスタがバス上でトランスファーを行うか

決めるために、XBus バス・モニタはどの許可ラインがアサートされているかチェックします。

XBusバス・モニタの例を簡単に保つため、n 番目のマスタは n 番目のリクエストと許可のライ

ンに接続されると仮定しています。たとえば、master[0] はgrant0に接続され、master[1]

は grant1に接続されるなどのように、です。そのため、XBus バス・モニタが、grant0 がア

サートされていると見ると、master[0] はバス上でトランスファーを行っていると仮定します。

どのスレーブがバス上のトランスファーに応答するかを決めるため、XBus バス・モニタは環境

の各スレーブによってサポートされるアドレスの範囲を知る必要があります。環境開発者はユー

ザ・インタフェースAPIである、xbus_env::set_slave_address_map()、をバス・モニタと

同様スレーブにアドレス・マップをセットするために、作成しています。このファンクションの

プロトタイプは次のようになります。

set_slave_address_map(string slave_name, int min_addr, int max_addr);

各スレーブに、スレーブが応答すべき 小と 大のアドレス値でset_slave_address_map()

をコールします。このファンクションはスレーブにアドレス・マップをセットし、バス・モニタ

に各スレーブとそのアドレス・マップの情報を提供します。

各スレーブのアドレス・マップバスから収集されたアドレスの情報から、バス・モニタはどのス

レーブがトランスファーに応答したかを決定します。

トランスファーの数

バス・モニタにはプロテクトされたフィールド・プロパティであるnum_transactions があり、

これはバス上でモニタされたトランスファーの数を保持しています。

XBus バス・モニタによって出されるノーティファイヤ（notifier）

XBus バス・モニタは2つのアナリシスポートを含んでおり、XBus の信号レベルのインタフェー

スで起こっているアクティビティのいろいろなタイプに関する情報を提供します。それらは：

• state_port—このポートはxbus_status オブジェクトを提供し、数え上げられた

bus_state プロパティを含んでいます。bus_state プロパティはバスの状態の変化を反

163

映します。例えば、バスがリセットに入ると、bus_state プロパティはRST_START にセ

ットされ xbus_status オブジェクトがアナリシスポートに書き込まれます。

• item_collected_port—このポートはXBusトランスファーを提供し、これはトランスフ

ァーが終了した後、信号インタフェースから収集されます。 この収集されたトランスファ

ーはitem_collected_port アナリシスポートに書き込まれます。

注意：適切な TLM インタフェースによって提供されたどのコンポーネントも、これらのTLM ポ

ートにアタッチでき提供される情報を聞くことができます。

チェックとカバレッジ

The XBus バス・モニタはクラス・チェックを使ってプロトコル特有のチェックを行い、収集され

た xbus_transfersからファンクショナル・カバレッジを収集します。

OVM フィールドの coverage_enable and checks_enable はカバレッジとチェックがそれ

ぞれ実行されるのかそうでないかコントロールするために使われます。さらに詳しくは110ページ

の“カバレッジ・モデルの実装”を参照してください。

XBus インタフェース

XBus インタフェースは名前のつけられたネットや変数のバンドルで、マスタ・エージェント、

スレーブ・エージェント、そしてバス・モニタがその中の信号をドライブしたり、モニタできま

す。実行される全てのフィジカル・チェックはインタフェースにおかれます。110ページの“カバ

レッジ・モデルの実装”を参照してください。

フィジカル・チェックを実行するためにアサーションが加えられます。xbus_env のフィールド

であるintf_checks_enableが、これらのチェックが実行されるかどうかをコントロールしま

す。さらに詳しくは、110ページの“カバレッジ・モデルの実装”を参照してください。

下のコードは XBus インタフェースのフィジカル・チェックの例で、正常なアドレス・フェーズ

で有効なアドレスがドライブされているかのチェックを行います。コンカレント・アサーション

がインタフェースに加えられ、チェックを実行し、assertAddrUnknownとラベルがつけられま

す。このアサーションはchecks_enable が真ならば、sig_clockの全てのポジティブ・エッ

ジで評価されます。checks_enable ビットは intf_checks_enable フィールドによってコ

ントロールされます。もしアドレスのいずれかのビットが正常なアドレス・フェーズで不定値と

分かると、エラー・メッセージが出されます。

always @(posedge sig_clock) begin assertAddrUnknown:assert property (

164

disable iff(!checks_enable) (sig_grant |-> ! $isunknown(sig_addr))) else $error("ERR_ADDR_XZ¥n Address went to X or Z during Address Phase"); end

165

Xbus の仕様

始めに

仕様開発のきっかけ

XBus 仕様のきっかけは簡単なバス標準の例を提供し、デモンストレーションの目的と、バス・

ベースの OVC に必要な手法を例示することにあります。そのため、XBus 仕様は複雑さを 小限

に抑えながら 近の典型的なバス標準の重要な機能を例示するように設計されています。

バスの概要

XBus は単純でマルチプレクスされておらず、パイプラインのない（単純なドライバであるよう

にするため）同期式のバスです。アドレス・バスは 16 ビット幅でデータ・バスはバイト幅（アラ

インメントの問題を避けるため）です。簡単なバースト転送が許され、スレーブは待ち状態を挿

入することによりデータ・レートを調節できます。 バスは任意の長さのマスタとスレーブを持つことができます（マスタの数はアービトレーション

の実装によってのみ制約されます。）マスタとスレーブはまとめて“バス・エージェント”として

知られています。 データ転送は 3 つのフェーズに分割されます。アービトレーション・フェーズ、アドレス・フェ

ーズ、そしてデータ・フェーズです。パイプラインが許されていないため、データの各バースト

でこれらのフェーズは順に発生します。アービトレーションとアドレス・フェーズはちょうど 1クロック・サイクル取ります。データ・フェーズは 1 クロック・サイクル以上取ることがありま

す。

バスの記述

166

バスの信号

バス信号のリストは（アービトレーション信号を含んでいません）はページ 167 のテーブル 8－1 に示されています。すべてのコントロール信号はアクティブ・ハイになっています。

テーブル8－1 バスの信号OVM2 01日本語版V1 2_rsato090119.doc

Signal Name

幅（ビット） ドライブさ

れる 目的

clock 1 n/a バスのマスタ・クロック

reset 1 n/a バスのリセット

start 1 アービタ アービトレーション・フェーズの間この信号は

ハイで、アドレスとデータ・フェーズではロー

です。

addr 16 マスタ トランスファーの 初のバイトのアドレス

size 2 マスタ 何バイトトランスファーされるかを示します：

n 00 => 1 バイト

n 01 => 2 バイト

n 10 => 4 バイト

n 11 => 8 バイト

read 1 マスタ この信号はread トランスファーのときハイ

（writeはロー)です。

167

write 1 マスタ この信号はwriteトランスファーでハイ（readはロー)です.

bip 1 マスタ バースト進行中(Burst In Progress）—マスタによ

ってデータ・フェーズの間バーストの 後のバ

イトを除いて全てのバイトに対しハイにセット

されます。この信号は、wait とerrorの信号と組

み合わされて、アービタによって次のクロッ

ク・サイクルでバスが新しいトランスファーを

開始するかどうか決定するために使われます。,

data 8 マスタ/ スレーブ

read やwrite のデータ

wait 1 スレーブ スレーブがマスタにトランスファーの終了を待

ってもらいたいときにハイ。

error 1 スレーブ スレーブのエラー状況がこのトランスファーに

適用されるならばハイ。

クロック

全てのバス・エージェントは clock 信号の立ち上がりのエッジに同期して動作しますが、gnt 信号

（ページ 169 の“アービトレーション・フェーズ”参照）が例外です。

リセット

アクティブ・ハイの reset 信号はクロックの立ち上がりのエッジに同期しています。reset は電源

オンのときにアサートされ、電源がオンになってクロックが安定したあと、少なくとも 5 つのク

ロックの立ち上がりのエッジの間アサートされ続けなければなりません。そのため、reset はクロ

ックの立ち上がりに同期して解除しなければなりません。 reset はオペレーションの間いつでもアサートすることができます。そのようなケースでは resetは少なくとも 3 クロック・サイクルの間アサートされなければならず、アサート、解除ともにク

168

ロックの立ち上がりエッジに同期しなければなりません。reset のアサーションは reset がアサー

トされた 初のクロックの立ち上がりエッジで全ての待ち状態の転送をキャンセルします。resetのアサーションの前に転送された全てのバイトは転送が成功したとみなされます。reset が 初に

アサートされてクロックの立ち上がりのエッジで転送に成功したとされる全てのバイトは転送が

失敗したとみなされます。 reset がアサートされている間、すべてのエージェントは全てのバスとアービトレーションの信号

を無視します。reset がアサートされている間、アービタは start と gnt の信号をローにドライブ

します。クロックのアサーションが解かれている時のクロックの 初の立ち上がりエッジで、ア

ービタは start をハイにドライブします。そのため通常のバス・オペレーションが起こることに

なります。

アービトレーション・フェーズ XBus おのおのは単一の、アービトレーションとある種のほかの中央のコントロール機能を実行

する中央のアービタを持ちます。 アービトレーション・フェーズは常に 1 クロック・サイクルの間続きます。アービトレーション・

フェーズの間アービタは start 信号をハイにドライブします。ほかの全ての時間は start 信号をロ

ーにドライブします。start 信号はそのためスレーブが各転送の 初にスレーブ自身を同期させる

ことに使うことができます。アービタは各データ・フェーズの 後のサイクルに続くサイクルも

しくは NOP アドレス・フェーズに続くサイクルで start を常にハイにドライブします。データ・

フェーズの 後のサイクルはデータ・フェーズ・サイクルと定義され、そこでは error 信号がハ

イか、もしくは bip と wait 信号がローのいずれかになります。 バスの各マスタは専用のreq信号と専用のgnt信号を持ちます。アービタは全てのreq信号をstartがアサートされているときのクロックの各立ち下がりのエッジでサンプリングし、優先度の指定

されていないシステムに基づいて単一の gnt 信号をアサートします。start がアサートされていな

いときのクロックのすべての立ち下がりのエッジで、アービタはすべての gnt 信号をローにドラ

イブします。このようにしてマスタはその gnt 信号のアサーションを、バスの使用を許可された

という指示だけではなくアドレス・フェーズをスタートさせなければならない指示とみなすこと

もできます。マスタにとってアドレス・フェーズをスタートさせる前に start 信号をチェックす

る必要はありません。

169

マスタはバスの使用が認められるとバスに直ちにトランザクションをドライブしなければなりま

せん。現在のマスタがそのトランザクションを終了するまでほかのマスタはバスをドライブする

ことは許されません。 注意：アービタだけが NOP 転送をドライブすることが許されます。これは、マスタはバスの使

用を認められたならば実際のトランスファーをドライブしなければならないことを意味します。

そのため、マスタは実際のトランスファーの準備ができると保証できるまでバスのリクエストを

すべきではありません。 アービトレーションの信号はアクティブ・ハイで信号名の 初の部分はルートの信号名（リクエ

スト信号には"req_”、グラントの信号には”gnt_”）をつけ 2 番目の部分には論理名かマスタの番号

をつける表記法に従って信号名がつけられています。アービトレーションの信号は XBus 仕様の

一部ですが、バスの全てのエージェントに接続されていないため”バス”の信号とはみなされて

いません。 適当なアービトレーション・システムを決定することはここの実装によります。アービタはおの

おののマスタに異なる優先度を割り当てることもでき、また同じ優先度を持つマスタをランダム

に選ぶこともできます。

アドレス・フェーズ アドレス・フェーズは単一クロック・サイクルの間続き、常にアービトレーション・フェーズの

直後に来ます。

NOP サイクル

どのマスタもバスを要求しておらず、クロックの立下りでstart 信号がアサートされておらず、ア

ドレス・フェーズのはじめでどの gnt 信号もアサートされていないと、アービタ自身は“no

operation” (NOP) 状態をドライブする責任があります。アービタは addr と size 信号を全てゼロ

にドライブし、read と write信号をローにドライブすることで実現します。NOP アドレス・フェ

ーズには関連するデータ・フェーズはなく、アービタは次のクロック・サイクルでstart 信号をア

サートします。

170

注意：これはアービタが、アービトレーション信号に加えあるバス信号に接続されており、“デ

フォルト・マスタ”として振舞うことを意味します。

通常のアドレス・フェーズ

クロックの立ち上がりで、もしマスタがその gnt 信号がアサートされているのを見ると、次のサ

イクルで有効なアドレス・フェーズをドライブしなければなりません。マスタはもしトランスフ

ァーを持たない場合は、このクロックのエッジで req 信号のアサートをはずさなければなりませ

ん。

アドレス・フェーズの間、許可されたマスタは addr と size 信号を有効な値にドライブし、read

か write (両方ではなく) のいずれかをハイにドライブします。addr にドライブされるアドレス

はバースト・トランスファーの 初のバイトのアドレスを表しています。バースト・トランスフ

ァーの間、それに続くアドレスを生成するかはスレーブに依存します。

マスタはアドレス・フェーズの間 addr、 size、 read とwrite 信号だけをドライブします。それ

に続くデータ・フェーズの間、マスタはこれらの信号をドライブしません。

データ・フェーズ

データ・フェーズは一つもしくはそれ以上のクロック・サイクル続くかもしれません。データ・

フェーズはアドレス・フェーズに直ちに続きます（データ・フェーズの後に直ちにアービトレー

ション・フェーズが続きます）。

Write トランスファー

アドレス・フェーズをドライブした後1クロック・サイクルで、マスタはデータの 初のバイトを

バス上にドライブします。もしこのクロックの 後で、スレーブがwait 信号をアサートしている

と、マスタは更なるクロック・サイクルで同じデータ・バイトをドライブし続けます。data 信号

はwait がアサートされていないときに、サイクルの 後で変化します。このようにして、スレー

ブは必要なだけwait ステートを挿入することができます。マスタはデータ・フェーズの間中、ト

ランスファーの 後のバイトがバスにドライブされるまで bip 信号をハイにドライブし、その時

点でローにドライブされます。

トランスファーの 後で（bip と wait の両方がローのサイクルの 後で)マスタは全てのバス信

号のドライブをやめます。

171

Write トランスファーの間のエラー

スレーブはデータ・フェーズの間中 error をドライブします。もしスレーブがwrite トランスファ

ーのデータ・フェーズの間のどこかでエラー状態に会うと、これを error 信号をアサートして知

らせます。エラー状態を知らせるために、スレーブは error 信号をハイに、一方 wait 信号をロ

ーにドライブしなければなりません。これはマスタに、トランスファーに関連したバイトが失敗

したこと、すなわちバーストのそれまでのバイトは成功し、バーストのそれに続くバイトは捨て

られることを知らせます。error のアサーションはbip が同時にアサートされていても常にデー

タ・フェーズを終了させます。

Read トランスファー

マスタが read アドレス・フェーズをドライブした後のクロック・サイクルで、スレーブは2つの

うちの一つのアクションを取ります。マスタはwait 信号をローにしてデータの 初のバイトをバ

スにドライブするか、wait 信号をハイにドライブしてデータをドライブする準備ができていない

ことを知らせるかのいずれかです。データの各バイトは wait がローの間サイクルの 後でマス

タによってのみラッチされ、このようにしてスレーブは必要なだけ wait ステートを挿入できま

す。マスタはデータ・フェーズの間中、マスタがトランスファーの 後のバイトを受信する用意

ができるまでbip 信号をハイにドライブし、この時点でローにドライブします。

トランスファーの 後で(bip と wait 両方がいずれもローのサイクルの 後で) 、マスタは全ての

バス信号のドライブを停止します。

Read トランスファーの間のエラー

スレーブはデータ・フェーズの間 error をドライブします。もしスレーブがread トランスファー

の間にどこかでエラー状態に出会うならば、error 信号をアサートすることによって知らせます。

エラー状態を知らせるためには、スレーブはerror 信号をハイにドライブし、一方 wait 信号をロ

ーにドライブしなければなりません。これはマスタに、関連するトランスファーが失敗したこと、

すなわちバーストのそれまでのバイトは成功し、これに続くバーストのバイトは捨てられること

を、知らせます。 error のアサーションはbip が同時にアサートされていても、常にデータ・フ

ェーズを終了させます。

何が何をいつドライブするか

テーブル8－2 何が何をいつドライブするかOVM2 01日本語版V1 2_rsato090119.doc

172

信号名 アービトレーショ

ン・フェーズ アドレス・フェーズ データ・フェーズ

start アービタによって1

にドライブされる

アービタによって0 にドライ

ブされる

アービタによって0 にドライ

ブされる

addr ドライブされない マスタによってドライブされ

る（またはNOPに対しアービタ

で0にドライブされる)

ドライブされない

size ドライブされない マスタによってドライブされ

る（またはNOPに対しアービタ

で0にドライブされる)

ドライブされない

read ドライブされない マスタによってドライブされ

る（またはNOPに対しアービタ

で0にドライブされる)

ドライブされない

write ドライブされない マスタによってドライブされ

る（またはNOPに対しアービタ

で0にドライブされる)

ドライブされない

bip ドライブされない ドライブされない トランスファーの 後のバイ

トを除いて全てのバイトでマ

スタによって1 にドライブさ

れる

data ドライブされない ドライブされない writeの間マスタによってドラ

イブされる。wait がローのサイ

クルのreadの間スレーブによっ

てドライブされ、そうでなけれ

ばドント・ケア（不定値にドラ

173

イブされるか全くドライブさ

れない）

wait ドライブされない ドライブされない ドライブされない

error ドライブされない ドライブされない ドライブされない

オプションのパイプライン・スキーム

前に述べたように、XBus 標準は通常パイプラインをサポートしません。 しかし、パイプライン

はオプションでインプリメントすることができます。

注意：全てのバス上のエージェント（アービトレーションも含め）はパイプラインを行うか、パ

イプラインを行わないかのいずれかに合意する必要があります。同じバス上でパイプラインとパ

イプラインでないものの混在したエージェントはサポートされません。

パイプラインはアービトレーション、アドレス、そしてデータ・フェーズとオーバーラップして

いるので、2レベルのパイプラインが提供されます。すなわち、ある任意の時点で、進行中の合計

3つのトランスファーがあります。

注意：パイプラインは結果として異なるバス・エージェントが同じ信号を連続したクロック・サ

イクルでドライブすることになります。そうなので、シーケンサの変化の一部として信号がドラ

イブされていない時間間隔はありません。この結果、バスのコンテンションが起こらないことを

確かなものとするようにバスのフィジカル設計に注意が必要です。マルチプレックス化されたア

プローチが必要です（リングかまたはスターの形で）。

パイプライン化されたアービトレーション・フェーズ

パイプライン化されたシステムでは、アービトレーション・フェーズはアドレスとデータ・フェ

ーズと並列に実行されます。アービトレーションはそれが必要か否かにかかわらず毎クロック・

サイクル実行されます。これはアービタが次のクロック・サイクルが新しいアドレス・フェーズ

の始まりを示しているか予測できないからです。

174

アービタはパイプライン・システムではないとき、各データ・フェーズの終了後のクロック・サ

イクルで、start 信号をアサートします。しかしこのstart 信号は3つ全てのフェーズがパラレルに

スタートすることを示します。

データ・フェーズの 後は error のアサーションか bip とwait.の両方のアサーションをはずす

かのいずれかで認識されます。

パイプライン化されたアドレス・フェーズ

データ・フェーズが終了し、クロックのエッジでその gnt 信号がアサートされているマスタが、

バスのアドレス・フェーズを許されます。マスタは直ちにアドレス・フェーズのドライブを開始

しなければなりません。アドレス・フェーズが単一のクロック・サイクル続く、パイプライン化

されていないバスと違い、パイプライン化されたバスは次のデータ・フェーズの 後まで続きま

す。

どのマスタもバスを要求しておらず、そのためどのマスタもバスを許可されていないところでは、

アービタが次のデータ・フェーズの終わりまでNOPをドライブする責任があります。

パイプライン化されたデータ・フェーズ

パイプライン化されたバスのデータ・フェーズはパイプライン化されていないバスのそれと同様

です。アービタが前のアドレス・フェーズにNOPをドライブしているところでは、マスタはデー

タ・フェーズの間（このケースでは単一クロック・サイクル続きます）error、 bip と wait をロ

ーにドライブしなければなりません。

タイミング・ダイアグラムの例

図8－1 Write 波形の例

175

176

図8－2 Read 波形の例