リントとデザイン・スタイル・チェック

 

リント機能は、環境及び状況に依存しない一般的に適用されるチェック機能を意味します。一方、デザイン・スタイル・チェックは、設計手法、環境、設計条件等に依存するチェック機能を意味します。前者はチェック条件を必要としませんが、後者はチェック条件を必要とします。リント機能とデザイン・スタイル・チェック機能を併用する事により、SystemVerilog記述上の隠れた落とし穴を早期に解消する事が出来ます。

 

デザイン・スタイル・チェックとUVM

 

デザイン・スタイル・チェック（DSC）にUVM検証コードを確認する機能を追加しました。この機能を利用する事により、基本的で、且つ、見落とし易い問題を早期に解決する事が出来ます。UVMには、守るべきルールが幾つか存在しますが、それらの多くに気が付かないのが現状です。

例えば、メソドロジー・クラスuvm_driverを利用してドライバーを定義する時、`uvm_component_utilsマクロを忘れる事があります。忘れても、SystemVerilogコンパイラーではエラーとなりませんが、その後、ファクトリを使用してドライバーのインスタンスを作成するとエラーが発生します。この時点でのエラーの原因究明は複雑になります。マクロが引き起こした問題である為、エラー・メッセージの内容は、一般的には、意味不明で解決に時間を要します。

別の例を挙げます。ドライバーを定義するとvirtual interfaceの宣言が必要です。宣言を忘れても、SystemVerilogコンパイラーではエラーとなりません。然し、後（例えば、シミュレーション時）にエラーが判明します。更に、話を複雑にするのは`uvm_field_マクロです。宣言したvirtual interfaceに対して`uvm_field_マクロを定義すると、今度はSystemVerilogコンパイラーがエラーを発行します。interfaceはクラスではない為、`uvm_field_マクロを使用するのは間違いです。然し、一般に、UVMに関する深い知識が無いとエラーを解析する事は難しいです。これらの例が示す様に、UVMを簡単に使用する事は出来ません。技術者にはフラストレーションが溜るばかりです。

DSCはこの様な潜在的な問題を未然に防ぎ、技術者は冷静さを保つ事が出来ます。UVM検証コードを記述したら、DSCを実行して下さい。DSCは基本的なルール・チェックを施工します。例えば、以下の様なルール・チェックを行います。

① データ・オブジェクトにはコンストラクタが定義されている事。
② コンポーネントのコンストラクタには標準値が設定されていない事。
③ コンポーネントの作成にはファクトリが使用されている事。
④ ドライバーにはvirtual interfaceが宣言されている事。
⑤ `uvm_object_utils、及び、`uvm_component_utilsマクロが必ず使用されている事。
⑥ クラスのプロパーティに対して、必ず、`uvm_field_マクロを定義している事。
⑦ uvm_agentのサブクラスでは、必ず、is_activeの`uvm_fieldマクロを定義している事。
⑧ シミュレーション・フェーズ（build_phase、run_phase等）を定義している事。
⑨ 何れかのコンポーネントのrun_phaseで、raise_objection()、及び、drop_objection()が、少なくとも一回、呼ばれている事。
⑩ テストベンチでrun_test()が呼ばれている事。
⑪ run_test()には引数が設定されていない事。
⑫ コンストラクタでは、必ず、super.new()が呼ばれている事。
⑬ build_phase()では、super.build_phase()が呼ばれている事。
⑭ end_of_elaboration_phase ()では、super. end_of_elaboration_phase ()が呼ばれている事。
⑮ コンストラクタ、及び、アブストラクト・メソッド以外のメソッドの記述をクラス外で行う事。
⑯ programをテストベンチに使用しない事。

⑰ その他（agent、env、sequence、sequencer等々）

今後もDSCにはルール・チェックの機能が追加されます。上記の機能は一例です。
DSCの実行例に関しては、ダウンロード・ページから製品紹介資料を取得して下さい。