e (検証言語)

e は、非常に柔軟で再利用可能な検証テストベンチを実装するためにカスタマイズされたハードウェア検証言語(HVL)です。

1992年にイスラエルのYoav HollanderがSpecmanソフトウェア用に初めて開発しました。1995年に彼はソフトウェアを商品化するためにInSpec （後にVerisityに改名）という会社を設立しました。この製品は1996年のデザインオートメーションカンファレンスで発表されました。^{[1]その後、Verisityは}Cadence Design Systemsに買収されました。

eの主な機能は次のとおりです。

• ランダムおよび制約付きランダム刺激生成
• 機能カバレッジメトリックの定義と収集
• アサーションを書くために使用できる時間言語
• リフレクション機能を備えたアスペクト指向プログラミング言語
• 言語は DUT に依存しないため、単一のeテストベンチを使用して、SystemC/C++ モデル、RTL モデル、ゲート レベル モデル、さらにはハードウェア アクセラレーション ボックス内にある DUT (UVM Acceleration for e方法論を使用)を検証できます。
• 特にテストベンチがユニバーサル検証方法論（UVM） に従って記述されている場合、再利用性の高いコードを作成できます。
  • 以前はe再利用方法論（e RM）と呼ばれていました
  • UVM eライブラリとドキュメントはここからダウンロードできます: UVM World

e言語は、アスペクト指向プログラミング(AOP) アプローチを使用します。これは、オブジェクト指向プログラミングアプローチの拡張であり、機能検証に必要なニーズに特に対応しています。AOP は、ユーザーが既存のコードに非侵入的な方法で追加機能を簡単に追加できるようにする重要な機能です。これにより、再利用とコードのメンテナンスが容易になり、プロジェクトのライフサイクル全体にわたって市場の需要を満たすために設計が継続的に調整されるハードウェアの世界では大きなメリットになります。AOP は、ユーザーが特定の構造体の特定のインスタンスまたはすべてのインスタンスを拡張して機能を追加できるようにすることで、横断的な問題 (コードのさまざまなセクションにまたがる機能) にも簡単に対処します。ユーザーは、複数の構造体を拡張して特定の機能に関連する機能を追加し、必要に応じて拡張機能を 1 つのファイルにバンドルして、より整理されたファイル パーティションを実現できます。

実行可能なeコードは、コード セグメント マーカー <' と '> で囲まれます。

マーカーの外側にあるものはすべてコメントです
<'
システムを拡張する {
  // これはVerilogスタイルのコメントです
  -- これはVHDLスタイルのコメントです
  post_generate() も {
    out("...マーカー内のその他すべては実行可能コードです。");
  };
};
'>

e には 2 種類のクラスもあります。

• 動的クラスには、キーワード「struct」のラベルが付けられます。構造体は、一時的にのみ存在し、ガベージ コレクターによって消去される可能性のあるデータを作成するために使用されます。
• 静的クラスには、キーワード「unit」のラベルが付けられます。ユニットは、永続的なテストベンチ構造を作成するために使用されます。

クラスには、フィールド、メソッド、ポート、制約を含めることができます。フィールドの型は、整数、実数、列挙、文字列、さらには複合オブジェクトにすることができます。コード セグメントは、e ルート 'sys' 内でインスタンス化される 'environment_u' というユニットを示しています。この environment_u クラスには、5 つの packet_s オブジェクトのリストが含まれており、この packet_s クラスには 2 つのフィールドと 1 つのメソッドが含まれています。

<'
// これは2つのフィールドを持つ動的クラスです
構造体パケット_s {
  field0: uint (ビット: 32); // このフィールドは「field0」と呼ばれ、
                            // 32 ビット幅の符号なし整数。
  field1: byte; // このフィールドは 'field1' と呼ばれ、バイトです。
  
  // このメソッドは、packet_s オブジェクトが生成されると呼び出されます
  post_generate() も {
    out(field0); // 'field0' の値を出力
  };
};

// これは5つのパケット構造体のリストを持つ静的クラスです
ユニット環境_u {
  my_pkt[5]: packet_sのリスト;
};

// sysはすべてのe環境のルートであり、'test_env'オブジェクトをインスタンス化します
システムを拡張する {
  test_env: environment_u はインスタンスです。
};
'>

eでは、各フィールドはデフォルトでランダム化されます。フィールドのランダム化は、ハード制約、ソフト制約によって制御することも、完全にオフにすることもできます。ソフト制約はデフォルトの制約として使用され、競合が発生した場合はテスト レイヤーによって自動的に上書きされる場合があります。それ以外の場合は、通常の制約のように動作します。

<'
構造体my_pkt_s{
  destination_address: uint (ビット: 48); // このフィールドはランダム化されており、制約はありません。
  data_payload: バイトのリスト;     
  !parity_field : uint (ビット: 32); // '!' は parity_field がランダム化されるのを防ぎます。
  
  keep soft data_payload.size() in [64..1500]; // デフォルトのランダム化を提供するために使用されるソフト制約
  data_payload.size() を [128..256] 内に収めない // これは厳しい制約です
};
'>

e は、時間式によるアサーションをサポートします。時間式は、フィールドやメソッドと同じ構文レベルで使用され、本質的に宣言的です。時間式は、時間指定の動作を記述します。

<'
単位 temporal_example_u {
  event a; // イベント 'a' を宣言する
  event b; // イベント 'b' を宣言する
  event c; // イベント 'c' を宣言する
  
  // このアサーションは、イベントaの後の次のサイクルが
  // イベント b の後にイベント c が発生したことが検出されました。
  @a => {@b;@c} を期待する
};
'>

e は、サンプリングされたイベントに従ってグループ化されたカバレッジをサポートし、それらのグループは内部的に項目で構成されます。項目は、単純な項目、または交差項目や遷移項目などの複雑な項目にすることができます。

ユニットカバレッジ例_u {
  event cov_event_e; // カバレッジの収集はこのイベントに関連付けられます

  カバーcov_event_eは{
    item a: uint (ビット: 4); // このアイテムには 0 から 15 までの 16 個のバケットがあります
    item b: bool; // このアイテムには TRUE と FALSE の 2 つのバケットがあります
    cross a, b; // この項目には a と b のクロス乗算行列が含まれています
    trans b; // このアイテムはアイテム b から派生しており、4 つのバケットがあります
                              // 各TRUE - FALSEの組み合わせを遷移する
  };
};

e内でのメッセージングは​​さまざまな方法で行うことができます。

ユニットメッセージ例_u {
  example_message_method() は {
    out("これは無条件のフォーマットされていない出力メッセージです。");
    outf("これは、HEX %x で表示される無条件のフォーマットされた出力メッセージです",15);
    print "これは無条件メッセージです。";
    message( LOW, "これは条件付きメッセージであり、通常はメッセージ ロガーに関連付けられています。 ",
                  「このように文字列を連結したり、",me, のようなオブジェクトを追加したりすることもできます。
                  " この出力では。" );
    messagef( LOW, "この条件付き出力は %x でフォーマットされています。",15 );
  };
};

eテストベンチは、 RTL またはより高レベルのモデルで実行される可能性があります。これを念頭に置くと、e はVHDL 、 Verilog 、 C 、 C ++、SystemVerilogとインターフェイスできます。

// このコードは Verilog ファイル tb_top.v にあります
module testbench_top ; reg a_clk ; always # 5 a_clk = ~ a_clk ; initial begin a_clk = 0 ; end endmodule 
      
      
   
      
  

このコードはsignal_map.eファイルにあります
<'
ユニットシグナルマップu {
  // 'a_clk_p' という名前のポートを定義します
  a_clk_p: simple_port のビットはインスタンスです。
  // ポートの hdl_path プロパティをトップレベルテストベンチの 'a_clk' 信号を指すように設定します
  a_clk_p.hdl_path() == "~/testbench_top/a_clk" を維持します。
};
'>

機能検証のプロセスでは、テスト対象設計 (DUT) の抽象化レベルを RTL レベル以上に上げる必要があります。この必要性から、データとモデルをカプセル化できる言語が必要となり、これはオブジェクト指向言語で容易に利用できます。この必要性に対応するために、e はオブジェクト指向言語として設計され、さらにアスペクト指向メカニズムが拡張されました。これにより、非常に柔軟で再利用可能なテストベンチの作成が容易になるだけでなく、既存のコード ベースを書き直したり変更したりすることなく、発見された RTL バグを修正できるため、検証エンジニアも役立ちます。e
のアスペクト指向プログラミングにより、検証エンジニアはテストベンチをアスペクトで構造化できます。したがって、オブジェクトはすべてのアスペクトの合計であり、複数のファイルに分散されている場合があります。次のセクションでは、 eの基本的なアスペクト指向メカニズムについて説明します。

サブタイピングは、アスペクト指向機能のないオブジェクト指向言語では実現できないことの代表的な例です。サブタイピングにより、検証エンジニアは、基本クラスから派生することなく、既に定義/実装されているクラスに機能を追加できます。次のコードは、基本クラスの元の実装とその拡張方法を示しています。拡張が行われると、すべての基本クラス オブジェクトにも拡張が含まれます。2 つの異なるサブタイプで指定された制約は通常、矛盾を引き起こしますが、両方のサブタイプは個別に処理されるため、各サブタイプで異なる制約計算が行われます。

サブタイピングの例.e
<'
// この列挙型定義はサブタイプODDとEVENを宣言するために使用されます
タイプ ctrl_field_type_t: [ODD, EVEN];
単位 base_ex_u {
  // subtype_field は計算が適用される決定フィールドです
  サブタイプフィールド: ctrl_field_type_t;
  data_word : uint (ビット: 32);
  parity_bit: ビット;
  
  // ODD 型のサブタイプ化
  ODD'subtype_field base_ex_u {の場合
    // これは、data_wordのインデックスビット0をXORし、その値を増分する単純な制約です。
    parity_bit == (data_word[0:0] ^ data_word[0:0] + 1) を維持します。
  };

  // EVEN 型のサブタイプ化
  EVEN'subtype_field base_ex_u {の場合
    // この制約は上記と同じですが、増分は行われません
    parity_bit == (data_word[0:0] ^ data_word[0:0]) を維持します。
  };
};
'>

元のユニット定義は、file1.e に示されています。この例で使用されているアスペクト指向メカニズムは、すでに実装されているメソッドの前後にコードを実行する方法を示しています。

このコードはfile1.eにあります
<'
ユニット aop_example_u {
  meth_ext() は {
    out("これは元のメソッドの実装です。");
  };
};
'>

このコードはfile2.eにあります
<'
aop_example_u を拡張します {
  meth_ext() は最初に {
    out("このメソッド拡張は、元のメソッド実装の前に実行されます。");
  };

  meth_ext() も {
    out("このメソッド拡張は、元のメソッド実装後に実行されます。");
  };
};
'>

• e ハードウェア検証言語、Sasan Iman および Sunita Joshi、Springer、2004 年 5 月 28 日
• e 検証言語によるアスペクト指向プログラミング、David Robinson、2007 年

• e 言語ブログ (Team Specman)
• http://www.deepchip.com/items/0488-05.html (e 言語の使用経験に関するユーザーからの良好なフィードバック)
• http://www.cadence.com/products/function_ver/specman_elite/index.aspx
• http://www.us.design-reuse.com/articles/article5646.html
• Janick Bergeron: Writing Testbenches: Functional Verification of HDL Models、第 2 版、Kluwer Academic Publishers、2003 年、ISBN 1-4020-7401-8 
• https://web.archive.org/web/20070405162901/http://amiq.ro/eparser.html
• http://www.thinkverification.com/
• http://www.dvteclipse.com/help.html?documentation/e/index.html