アートグラフィックス

スライドが順に変化しますので暫くお待ち下さい。

プロジェクト・マネージャー（標準機能） プロジェクトで使用するファイルを管理し、 コンパイルからシミュレーションまでの一連の処理を実行 します。ソース・ファイルが変更されると自動的にコンパイラーがシンタックス・チェックを開始します。また、使用中のファイルを外部で変更した場合には使用者に警告を発します。 IDE 左端の制御ボタンを使用するとエクスプローラ、及びコンソールを隠す事が出来ます。テキスト・ウィンドウに十分な大きさを確保して作業がし易くなります。 ファイルの自動バックアップ機能も組み込まれています。各ファイルに対して最大100個のバージョンを保持する事が出来ます。バックアップを圧縮アーカイブとして保存するのでディスク・スペースの使用量を最少限に抑えます。	コード開発と支援機能（標準機能） シンタックス・ハイライト・テキスト・エディタ、ナビゲータ、リント、デザイン・スタイル・チェック（DSC）等の機能から構成されています。 テキスト・エディタは入力ナビゲータ、行の折り畳み、ウィンドウ二分割、ヘッダ・ハイライト、エラー表示等の豊富な機能を備えています。DSCはUVMに関するルール・チェックも施工致します。 更に、テキスト・エディタはFPS（File Positioning System）機能を備え、クリックするだけでファイル内の任意の行に移動する事を可能にします。FPSは最近編集した行、選択した文字列、シンタックス・エラーを持つ行、及び任意行の表示等のナビゲーションを行ないます。スクロール・バーを上下する必要はありません。クリックするだけで所望の箇所を表示する事が出来ます。大きなファイルで作業をしている場合には、入力作業の負担を軽減します。詳細資料の取得には ダウンロード・ページ へお進みください。
ソフトウェア更新機能（標準機能） ユーザは DownloadMgr を使用してソフトウェアを更新する事が出来ます。   ワークベンチ（標準機能） データ構造生成ウィザード、UVM クラス・ウィザード、テストベンチ生成等を含みます。UVM クラス・ウィザードはUVMマクロも生成します。 HTML 文書生成（標準機能） HTML文書生成機能はSystemVerilog記述からインターネット・ブラウザーで表示可能なHTMLファイルを生成します。	UVM サポート（標準機能） UVMは複雑なコンストラクトである為、GUIの使用は不可欠です。特に、IDEが備える行の折り畳み機能は有効に働きます。タスク及びファンクションの細部を隠し、メソッドの仕様だけに着目する事が出来ます。 クイック参照機能（標準機能） コード・スニペット、ブックマーク等の機能を含みます。コード・スニペット機能は備忘録としての役割を果たします。 検証機能（標準機能） シミュレータはSystemVerilogの検証機能（アサーション、ファンクショナル・カバレッジ、制約付き乱数発生機能、DPI）を備えています。

RTL 論理合成は設計の初期段階において、物理設計後の実装状況を正確に見積もる為の機能を提供します。RTL 論理合成機能はユーザ指定のライブラリーを使用してVerilog ネットリストを生成します。RTL 論理合成は業界標準のテクノロジーライブラリーをサポートしています。生成されたネットリストを使用して他のEDAツールにより各種の解析を正確に行なう事が出来ます。

 

論理合成は、一般に、複雑な変換過程を得てネットリストを生成しますが、大きく分けると次の四工程から成ります：

① コンパイル（シンタックスチェック、エラボレーション）
② テクノロジー独立論理合成
③ 論理の最適化
④ マッピング

コンパイルのフェーズは、入力であるRTL記述が言語仕様に遵守しているかを確認する過程です。合成フェーズは、RTL記述をブーリアン論理に変換をする過程です。最適化は冗長な論理を除去する目的を持ちます。マッピングは、最適化された論理をライブラリーセルで表現する過程です。目的に合わせて論理合成を使用する事により物理設計時に遭遇するであろう問題を未然に防ぐ事が出来ます。

SystemVerilog (IEEE Std 1800-2017) 仕様は非常に複雑な言語体系を持ちます。コンパイラー開発は決して容易な作業ではありません。また、各企業が独自にコンパイラーを開発するのは得策ではありません。更に、SystemVerilogを使用する方法が多様化するに伴い、EDAベンダーからのサポートを期待する事が出来ない機能分野が出現して来ます。SystemVerilogソフトウェア・パッケージはこれらの問題・課題・要望へのソリューションを提供致します。

ソフトウェア・パッケージとしてのSystemVerilogコンパイラーはC++クラスとして実装されているので、ユーザのC/C++コードから簡単にコンパイラーを呼び出すことが出来ます。ソフトウェア・パッケージはSystemVerilogに関するあらゆる処理を可能にします。

 

ソフトウェア・パッケージをソース・コード形式、又は、オブジェクト・ライブラリー形式で提供致します。

また、ご指定のプラットフォームに合わせた提供も致します。

 

GUIを使用しないスタンド・アローン形式のシミュレーション機能です。コマンド・プロンプトと一緒に使用してシミュレータを実行します。マウスをクリックするよりもタイピングする方を好むユーザにお勧めします。

 

SystemVerilogコンパイラーがC++ソース・コード、及び、makeファイルを生成します。
ユーザはコンパイルからシミュレーションの過程を自由に進める事が出来ます。
ユーザ固有のツールを使用して検証結果の確認を行って下さい。

HTML 文書生成機能はSystemVerilog 記述をブラウザーで表示する事が出来るHTML ファイルに変換します。

お好みのブラウザーを使用してデザインのレビューを効率良く進める事が出来ます。以下の様な特徴を持ちます。

 

① モジュール、クラス等のヘッダ直前に記述されているコメントから仕様を抽出して文書を生成します。
② コメント部分に記述する仕様にはHTMLタグを使用する事が出来るので見易い文書を作成する事が出来ます。
③ ファイル、及び、ディレクトリ単位に文書を生成する事が出来ます。
④ プロジェクト全体の文書を生成するには、プロジェクトのルート・ディレクトリを指定するだけで全ての文書を作成する事が出来ます。
⑤ コンパイラーを使用せずに文書を作成する為、未定義のモジュール、及び、クラスを参照していてもエラーは発生しません。
⑥ 文書はCSSファイルを使用しています。CSSファイルを編集する事により、ユーザ固有の文書書式を実現する事が出来ます。

 

下図は、生成した文書をGoogle Chromeで表示している例です。

 

 

SystemVerilogは多くの機能から構成されています。しかも、それらの多くが複雑なシンタックスを持っています。全ての機能のシンタックスを完全に記憶する事は困難である為、それらの機能を使用する際にはマニュアルを参照するか既存のコードを参照するか等の努力をします。その様な場合、創造活動が中断されて思考が途切れてしまう事が多々あります。この様な悪影響を最少限にする為のツールがコード・スニペット機能とブックマーク機能です。

 

コード・スニペット機能

 

ツールはスニペットをカテゴリーに分類して管理します。例えば、カバレッジ、制約、アサーション等のカテゴリーに分類する事が出来ます。カテゴリー内では、スニペットを名称で管理します。定義されたスニペットにはサンプル・コードを割り当てる事が出来ます。スニペット機能は備忘録としての役割も果たします。

 

以下はスニペットの定義例です。それぞれの画像をクリックすると拡大して見易くなります。

 

ブックマーク機能

 

コード・スニペットはユーザ指定の名称に対してコードの断片をマップする機能です。それに対して、ブックマーク機能はユーザ指定の名称に対してソース・ファイル内の行番号を割り当てます。ブックマークをダブル・クリックするとファイルが開き、該当する行がテキスト・エディタ内に選択表示されます。

 

以下はブックマークの例です。それぞれの画像をクリックすると拡大して見易くなります。

SystemVerilog IDEには各種のナビゲータ及びウィザードが組み込まれ、コード開発時の生産性向上を促進します。

 

以下はナビゲータ及びウィザードの使用例です。それぞれの画像をクリックすると拡大して見易くなります。

IDEを使用するとコンパイルからシミュレーションの過程は自動的に実行します。コンパイルした結果は実行モジュールとして保存される為、再度実行する事が出来ます。通常は、同じ実行モジュールに対して異なった実行パラメータを指定して各種のテスト・ケースを試します。

 

以下はシミュレーションを行うまでの過程を示す例です。それぞれの画像をクリックすると拡大して見易くなります。

他のアプリケーション、及び、他社ベンダーの検証ツールのフロントエンドとしてSystemVerilog IDE を使用する場合、それらのプログラムを起動するスクリプトを簡単な手順で作成する事が出来ます。

 

通常、引き渡す情報は限られています。例えば、必要な情報はインクルード・ディレクトリのリスト、及び、デザインで使用しているファイルのリストです。その他は、情報を処理する為のコマンド・スクリプトです。SystemVerilog IDE の MakeScript ユーティリティはそれらの情報作成を簡単に遂行する為の機能です。作成したスクリプトは何度も使用される為、丹念に作成する価値があります。

 

以下は MakeScript 機能の使用例です。それぞれの画像をクリックすると拡大して見易くなります。

SVChecker はミニ SystemVerilog IDE です。SVChecker はコード開発用の GUI 環境を持たないユーザの為に開発されました。
設計・検証機能を備えた包括的な SystemVerilog IDE よりも低コストで SystemVerilog 開発環境を使用する事が出来ます。

 

SVCheckerは検証機能、及びコード開発時に必要な全ての機能を提供します。
具体的には、以下の機能を備えています。今後も機能追加が進められSVCheckerは進化し続けます。

 

★　ファイル・マネージャー（プロジェクトで使用するファイルを管理します）

★　コード開発と支援機能（シンタックス・ハイライト・テキスト・エディタ、ナビゲータ、リント、デザイン・スタイル・チェック）

★　クイック参照機能（コード・スニペット、ブックマーク）

★　SystemVerilog コンパイラー

★　SystemVerilog シミュレータ

★　UVM サポート（UVMは複雑なコンストラクトである為、GUIの使用は不可欠です）

★　ワークベンチ（データ構造生成ウィザード、UVM クラス・ウィザード等）

★　検証ビューワー（別アプリとして標準装備されます）

★　HTML文書生成機能

★　ユーティリティ（ファイル分割、ファイル統合等）

★　自動バックアップ機能

★　ソフトウェア更新機能（ユーザは DownloadMgr を使用して適宜ソフトウェアを更新する事が出来ます）

 

SVCheckerは TDI（Tabbed Document Interface）でテキスト・ウィンドウを配置します。
タブを移動するだけでテキスト・ウィンドウの配置変更をする事が出来ます。簡単で直感的な操作は生産性を高めます。

 

SystemVerilog IDEは自動バックアップ機能を備えています。この機能により、ファイルが壊滅状態になってもセッション開始時点のファイルを復元する事が出来ます。バックアップは自動的に行なわれる為、使用者には手間がかかりません。何よりも、バックアップを取る機会を忘れる事はありません。

 

ファイルを開く際、そのファイルの更新時刻が最新のバックアップ・ファイルの更新時刻より新しい場合、新しいバックアップ・ファイルが自動的に作成されます。従って、ファイルを開いた時点では、そのファイルと同じ内容を持つバックアップ・ファイルが存在する事になります。また、バックアップ・ファイルの数は予め設定されている上限を超える事はありません。上限を超えた場合、最も古いバックアップが削除された後、新しいバックアップが登録されます。

 

バックアップはシステム固有の場所に保管されます。バックアップの作成は自動的に行なわれる為、ユーザに求められる特別な操作はありません。ユーザがバックアップ・ファイルを直接操作する為には、BackupMgrを使用します。以下の操作が可能です。

 

バックアップ・ファイルの内容を表示する事

ソース・ファイルとバックアップ・ファイルの差異を調べる事

バックアップ・ファイル同士の比較を行う事

ソース・ファイルをバックアップ・ファイルから復元する事

ソース・ファイルから新しいバックアップを作成する事

不要になったバックアップを削除する事

プロジェクトに使用されているファイルのバックアップを整理する事

バックアップが保管されているディレクトリを知る事

バックアップが使用しているディスク・スペースの大きさを知る事

 

下図はBackupMgrを使用してファイルの比較をしている状態を示しています。ソース・ファイルとバックアップ・ファイルとの差異を知る事により作業履歴を思い出す事が出来ます。バックアップ・ファイルを選択してShow Bk ボタンをクリックすると、バックアップ・ファイルの内容がViewパネルに表示されます。バックアップ・ファイルからファイルを復元する場合は、Get Bk ボタンをクリックするだけで済みます。

 

 

Verilog HDLからSystemVerilogへ移行し、多くのキーワード、シンタックス、文、命令等が追加されました。素朴なシンタックスを持つVerilog HDLと異なり、SystemVerilogの持つ機能を駆使する為には時代に即したツールの使用が不可欠です。ましてや、UVMは更に複雑な構造・機能を持つ為、設計・検証技術者に課される作業負担は想像を絶します。

単にシミュレータを実行するだけであれば、素朴なテキスト・エディタとコンソール・ターミナルがあれば任務を十分遂行する事が出来ます。然し、SystemVerilog 、及び、UVMを使用して検証環境を構築するとなると事情は全く異なります。素朴なテキスト・エディタだけでは生産性は向上しません。特に、UVMには必須の記述が多い事とそれぞれのキーワードが長い事が、利用者に不満を齎す主原因となっています。また、タイプミスは日常茶飯事で生産性向上の妨げになっているのが現状です。

 

下図はUVMを支援する機能の一例を示しています。この例では、

行の折り畳み

クロス・リファレンスとしてのナビゲータ

FPS（File Positioning System）

等の役割を強調しています。行の折り畳みにより、uvm_agentクラスの仕様の閲覧が容易になっています。ナビゲータは、uvm_agentクラスのファイルを開く機能を提供しています。テキスト・エディタ右端の白い領域はFPSで、ファイルの任意の行に移動する制御をします。大きなファイルを開いている場合、スクロール・バーを上下する必要が無い為、生産性が向上します。たとえ些細な便利さでも技術者のフラストレーション緩和に大きな効果を齎します。

 

UVMを支援するテキスト・エディタとナビゲータ

UVMには守るべきルールが沢山ありますが、忘れやすい事は確かです。検証コードを最初に準備する際は、どの様な場合でも殆ど同じです。従って、ウィザードが便宜を図れる恰好の機会です。以下に示す例は、ドライバーのテンプレートをUVMクラス・ウィザードで生成した例です。使用するphaseを選択するだけでコード・テンプレートを作成する事が出来ます。phaseメソッドをクラス内外に生成する制御も備わっています。

 

UVMクラス・ウィザードによるドライバー生成例

テキスト・エディタの詳細は、 こちら を参照して下さい。

DownloadMgrは、ソフトウェアの更新、及び、ライセンスの更新サービスを提供する為のツールです。例えば、ソフトウェアの更新がリリースされているかを調べる事が出来ます。更新が存在する場合、DownloadMgrにより更新をダウンロードしてインストールする事が出来ます。

 

DownloadMgrを起動すると下図の様な画面が表示されます。タブをクリックして機能の選択をして下さい。SystemVeriog IDEからでもソフトウェア更新の有無を確認する事が出来ます。

 

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

 

リント機能は、環境及び状況に依存しない一般的に適用されるチェック機能を意味します。一方、デザイン・スタイル・チェックは、設計手法、環境、設計条件等に依存するチェック機能を意味します。前者はチェック条件を必要としませんが、後者はチェック条件を必要とします。リント機能とデザイン・スタイル・チェック機能を併用する事により、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の実行例に関しては、ダウンロード・ページから製品紹介資料を取得して下さい。

技術資料のページへお進み下さい。