プロトコル UVC (UVM 検証コンポーネント) を拡張してカスタム拡張機能を追加し、適切なカプセル化を維持する方法は?
典型的なプロトコル (およびその UVC) には、状態またはモード (さまざまな状況での動作の制御) およびフェーズまたはイベント (プロトコルに従って転送の実行中に区切られた領域または関心のあるポイント) などの概念があります。「バニラ」UVC は、刺激データと観測された DUT フィードバックの組み合わせに基づいて、内部状態/モード/フェーズを維持します。プロトコル UVC を拡張してカスタム シグナリングを追加するには、通常、同じ状態/モード/フェーズまたはイベントにアクセスする必要があります。
プロトコルを変更する必要はなく、非破壊的な方法で追加するだけだと思います。
クラス レベルで (これは既にご存じでしょう):
- 確保/追加することにより、ベース UVC 内にカスタム拡張機能の基盤を作成します。
- 拡張されたクラスがそれらにアクセスできるように、主要なプロトコル状態またはモードの accessors()
- 拡張クラスがそれらにサブスクライブできるように、主要なプロトコル フェーズのイベント/コールバック
- 個別の構成値ではなく、ベース UVC 構成の構成オブジェクトを優先します
- シーケンス アイテム (およびシーケンス ライブラリ*) を拡張して、拡張に関する刺激の意図を伝える
- ここでランダムな制約を使用して、カスタム拡張機能のルールを適用することを検討してください
- UVC 基本クラスを拡張してカスタム拡張を作成し、追加します。
- ローカルで使用する刺激の拡張部分を抽出し、アイテムをベース UVC に渡す拡張シーケンス アイテムのシーケンサー
- カスタム拡張によって監視された追加情報を報告できる分析ポート
- カスタム拡張機能のドライバー/モニター。ベース UVC ドライバー/モニターのイベント/コールバックによってトリガーされます。
- 構成オブジェクト/フックアップおよび通常の UVM メカニズムのパススルー。
信号レベル:
- 「インターフェース内のインターフェース」アプローチを検討する
- 以下を含む完全な信号バンドルを表す物理インターフェイスを作成します。
- 元の「バニラ」プロトコル インターフェイスのインスタンス
- 「サイドシグナル」を表す新しいインターフェースのインスタンス
- 外部インターフェイスまたは内部インターフェイスのいずれかを、テスト環境および拡張 UVC クラス内の適切な場所で (通常の UVM メカニズムを介して) 仮想インターフェイス ハンドルに割り当てます。
- 可能であれば、このインターフェイス内でアサーションを使用して、拡張機能の動作を法的な wrt ベース プロトコルの動作に保つことを検討してください。
拡張機能を分離しておくことで、ベース UVC で適切なフックと API を公開できる場合、保守が困難な状況 (「標準」を意図したプロトコルのカスタマイズ) でコードの保守性を最大限に高めることができます。 .
*シーケンス ライブラリ全体を拡張することは常に可能であるとは限りません。その場合、「拡張」を制御するために、モデルまたは構成オブジェクトへのハンドルなど、「サイド」の構成にアクセスする必要がある場合があります。そのための通常の UVM メカニズムを使用します。その一例は、低レベルの実装がプロトコルに影響を与えるが、高レベルの制御がプロトコルに依存しない、電源管理に関連する拡張です。