検証環境構築のための社内教典(0から環境構築を始める)

1. 環境構築の4要素

テスト シーケンスを送信する前に、まず構造化された環境を作成し、環境構築の中核要素を分解する必要があります。環境構築は次の 4 つの部分に分割できます。

  • ユニットコンポーネントの自己閉鎖特性
  • 回帰の作成
  • 通信ポート接続
  • 最上位の構成


2. ユニットコンポーネントの自動閉鎖

自己終了とは、ユニット コンポーネント (uvm_agent や uvm_env など) が独立した動作になり、他の並列コンポーネントに依存しないことを意味します。例えば、ドライバーとシーケンサーの間では、ドライバーはシーケンサーのトランザクション項目を取得する必要があるものの、独自にインスタンス化することができ、両者間の通信もTLMエンドツーエンド接続で実現されます。このユニット コンポーネントの自己閉鎖的な性質は、その後のコンポーネントの再利用のための優れた基盤を提供し、追加の通信接続を必要とせずに、各サブ環境をトップレベルの環境に独立して統合することもできます。

3. 回帰の作成

この回帰作成方法では、上位コンポーネントが自身をインスタンス化(new() 関数の実行)した後、各フェーズのステージを実行します。build_phase を通じてさらにサブコンポーネントを作成することができ、これらのサブコンポーネントも作成されます同じプロセスを経て、次のレベルのコンポーネントが作成されます。

回帰作成が実現できる理由は、トップダウンの実行順序のbuild_phaseに依存します。build_phase の構造化された実行シーケンスにより、子コンポーネントの前に親コンポーネントを作成する必要があり、作成プロセスには次のものも含まれます。

  • メンバー変数を定義するときにデフォルト値を割り当てるか、new() 関数で初期値を割り当てます。
  • 構造構成変数は、コンポーネントの条件付き生成を決定するために使用されます。たとえば、uvm_agent は、is_active 変数に依存して、uvm_sequencer と uvm_driver をインスタンス化する必要があるかどうかを決定します。
  • モード構成変数は、各サブコンポーネントの動作モードを決定するために使用されます。
  • サブコンポーネントは、上から下、前から後ろに順番に生成されます。


4. 通信ポートの接続

環境全体が作成された後、各コンポーネントは通信ポートの接続を介してデータ通信を実行します。一般的なポート通信の用途は次のとおりです。

  • ドライバのポートはシーケンサに接続されており、シーケンサに対するブロッキングプルの形でトランザクションアイテムが取得されます。
  • モニターのポートはスコアボード内の分析 FIFO に接続され、モニターされたデータがそこに書き込まれます。

5. トップレベルの構成

形式的には、ユニット コンポーネントの自己終了特性により、UVM 構造では、サブ環境ハンドルを参照してから、トップレベル設定のより深い変数にインデックスを付けることは推奨されません。これにより、トップレベル環境とサブ環境の粘着性が向上します。 、より良い分離を達成することはできません。

したがって、より良い方法は、構成オブジェクトをトップレベルの環境にバインドされた部分としてサブ環境に渡すことであり、サブ環境の各コンポーネントは構造化された構成オブジェクトから独自の構成パラメーターを取得して、build_phase を行うことができます。 、connect_phase および run_phase を使用して、その構造と動作モードを決定します。

トップレベル構成オブジェクトは、サブ環境がインスタンス化されない場合に、サブ環境よりも前にトップレベル構成オブジェクトが生成されることを考慮せずに、将来作成されるサブ環境に構成できます。は、UVM 検証構造の安全な構成方法を提供します。

  • 使用する構成レイヤーに関係なく、構成が完了していることを確認するために、サブコンポーネントを作成する前にすべての構成を配置するようにしてください。
  • 構成の範囲は現在のレベル以下にのみ焦点を当て、上位のレベルは含まないようにします。
  • 構成オブジェクトの構造はできる限り独立している必要があり、環境構造と同様にツリー構造を形成することが望ましいです。このような独立した構成オブジェクトは独立したサブ環境に対応し、独立した構成をツリー状の最上位構成構造にマージすると、最上位構成オブジェクトの使用と保守が容易になります。
  • config_db の構成特性により、上位レベルの構成は基礎となる構成をカバーし、uvm_test レベルで作成された構成で全体の構造とモードを制御することもできます。

トップレベルの構成ブロック図


6. 環境要素の分類

 uvm_test レイヤーにはサブ環境に渡されるいくつかの構成部分があるため、uvm_test レイヤーを uvm_env よりも高いレベルとして描画します。環境を構成するコンポーネント uvm_component を含め、環境要素は次の部分に分割できます。

  • メンバー変数: 一般変数、構造変数、パターン変数。
  • サブコンポーネント: 固定コンポーネント、条件付きコンポーネント、参照コンポーネント。
  • 子オブジェクト: 自己生成オブジェクト、複製オブジェクト、および参照オブジェクト。

メンバー変数

  • 一般変数は、オブジェクト内の操作、または外部アクセスの状態値を提供するために使用されます。
  • 構造変数は、内部サブコンポーネントを作成して接続する必要があるかどうかを決定するために使用されます。たとえば、トップレベルの is_active 変数はこの目的に使用されます。
  • モード変数は、コンポーネントの動作を制御するために使用されます。たとえば、ドライバー変数をモードで構成して、run_phase で異なるインセンティブ動作を行うことができます。
  • 構造体変数とモード変数の場合、通常は int 型または enum 型で定義され、uvm_config_db の構成メソッドを使用して uvm_test レイヤーに直接設定するか、構造化構成オブジェクトを使用してシステム構成を実行できます。複雑な認証環境の場合、構成オブジェクトの操作と保守が簡単になります。

サブアセンブリ

  • 環境内に作成する必要があるコンポーネントを固定コンポーネントといい、例えばエージェント内のモニターはアクティブモード、パッシブモードに関係なく作成する必要があります、あるいは最上位環境のスコアボードも作成する必要があります。データを比較します。
  • 条件付きコンポーネントは、構造体変数の構成によって作成する必要があるかどうかが決まります。たとえば、シーケンサーとドライバーはアクティブ モードでのみ作成できます。
  • 参照コンポーネントは内部で型ハンドルを宣言し、それをトップダウン ハンドルを通じて渡し、ハンドルが外部オブジェクトを指すことができるようにします。たとえば、uvm_test 層では、最初にレジスタ モデル rgm (固定コンポーネント) がインスタンス化され、次にモデルのハンドルが設定を通じて reg_env 層の rgm ハンドル (参照コンポーネント) に渡されます。コンポーネントを参照する方法を使用すると、必要に応じて環境のすべてのレベルでコンポーネントを共有できます。

子オブジェクト

  • オブジェクトは最初に特定のレイヤーに作成されます。これは自己生成オブジェクトと呼ぶことができます。
  • オブジェクトの転送中に、オブジェクトが複製されて、同じメンバー値を持つオブジェクトが生成されます。これを「複製オブジェクト」と呼びます。
  • オブジェクトがポートを通って他のコンポーネントに到達し、そのコンポーネントがクローンを作成せずに直接そのコンポーネントを操作することをオブジェクトを参照する操作と呼びます。たとえば、仮想シーケンスでは、reg_master_agent と reg_slave_agent に送信されるトランザクション アイテム (それぞれ mst_t と slv_t) が生成され、継続的に送信される mst_t と slv_t は、uvm_sequencer を経由して、最終的に uvm_driver に到達します。uvm_driver がこれらのトランザクション オブジェクトを取得した後、まずそれらを複製し、次に複製されたデータ オブジェクトをインセンティブとして使用する方法です。uvm_driver は、データ オブジェクトを複製せずにこれらのオブジェクト (参照オブジェクト) を直接操作することもできます。
     

おすすめ

転載: blog.csdn.net/Arvin_ing/article/details/127676326