Vivado Design Suite ユーザーガイド - Xilinx...インプリメンテーション...

Vivado Design Suite ユーザーガイド

インプリメンテーション

UG904 (v2014.1) 2014 年 4 月 2 日

インプリメンテーション japan.xilinx.com 2UG904 (v2014.1) 2014 年 4 月 2 日

改訂履歴

次の表に、この文書の改訂履歴を示します。

日付バージョン改訂内容

2014 年 4 月 2 日 2014.1 第 1 章 :• Vivado デザインフローの図 (6 ページの図 1-1) をアップデート

• 7 ページの「Vivado ツールでのマルチスレッド」セクションで配置および配線の大スレッド数を変更

• 8 ページの「インプリメンテーションの制御」、プロジェクトおよび非プロジェクトモードの説明をアップデート

• 15 ページの「制約を attribute 文として追加」をアップデート

• 15 ページの「デザインチェックポイントを使用したデザインのスナップショットの保存および復元」をアップデート

• 16 ページの「非プロジェクトモードでのインプリメンテーションの実行」および19 ページの「プロジェクトモードでのインプリメンテーションの実行」をアップデート

• 29 ページの「インプリメンテーションストラテジのカスタマイズ」をアップデート

• 35 ページの「インプリメンテーション run の起動」をアップデート

• 37 ページの「インプリメンテーションの段階ごとの実行」をアップデート

• 39 ページの「インプリメンテーション run の監視」をアップデート

• 42 ページの「インクリメンタルコンパイル」をアップデート

• 59 ページの「インプリメンテーションレポートの表示」をアップデート

第 2 章 :• 64 ページの「インプリメンテーションのサブプロセス」をアップデート

• サブプロセスと関連の Tcl コマンドをリストする表 2-1 を追加

• 66 ページの「合成済みデザインを開く」をアップデート (コード例の変更を含む)• 70 ページの「ロジック適化」をアップデート

• 75 ページ以降の「配置」、「物理適化」、および「配線」をアップデート

108 ページの付録 A 「リモートホストおよび LSF の使用」 : LSF (Load Sharing Facility) を使用したリモート Linux ホストの使用に関する情報を追加

全体で次を変更 :• インプリメンテーションプロセスおよびサブプロセスの説明をアップデート配線後のphys_opt_design コマンドおよびその他のインプリメンテーションコマンドオプションを追加 (例 : 第 1 章 6 ページの「Vivado インプリメンテーションのサブプロセス」)

• 関連の箇所に LSF に関する情報を追加

• 必要に応じて UltraScale™ デバイスサポートに関する記述を追加

• 技術内容を向上するためのアップデート

http://japan.xilinx.com

http://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG904&Title=Vivado%20Design%20Suite%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B%20%3A%20%26%2312452%3B%26%2312531%3B%26%2312503%3B%26%2312522%3B%26%2312513%3B%26%2312531%3B%26%2312486%3B%26%2312540%3B%26%2312471%3B%26%2312519%3B%26%2312531%3B&releaseVersion=2014.1&docPage=2

目次

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 1 章 : Vivado インプリメンテーションプロセスVivado インプリメンテーションプロセスについて. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

インプリメンテーションの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

IP の設定、インプリメント、および検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

インプリメンテーションでのデザイン制約の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

デザインチェックポイントを使用したデザインのスナップショットの保存および復元 . . . . . . . . . . . . . . . . . . . . . 15

非プロジェクトモードでのインプリメンテーションの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

プロジェクトモードでのインプリメンテーションの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

インプリメンテーションストラテジのカスタマイズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

インプリメンテーション run の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

プロセスのバックグラウンドへの移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

インプリメンテーションの段階ごとの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

インプリメンテーション run の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

インクリメンタルコンパイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

インプリメンテーション完了後の次の操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

メッセージの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

インプリメンテーションレポートの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

第 2 章 : インプリメンテーションコマンドインプリメンテーションコマンドについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

インプリメンテーションのサブプロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

合成済みデザインを開く . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

ロジック適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

消費電力の適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

物理適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

配線 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

第 3 章 : 配置、配線、およびロジックの変更配置、配線、およびロジックの変更について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

配置の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

配線の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

ロジックの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

付録 A : リモートホストおよび LSF の使用リモート Linux ホストでの run の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

SSH の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113




付録 B : ISE コマンドと Vivado コマンドの対照表Tcl コマンドとオプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

付録 C : インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定インプリメンテーションのカテゴリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

インプリメンテーションストラテジの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

インプリメンテーションストラテジで使用される opt_design および place_design の -directive の設定 . . . . . . . . 117

インプリメンテーションストラテジで使用される phys_opt_design および route_design の -directive の設定 . . . 118

付録 D : その他のリソースおよび法的通知ザイリンクスリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

ソリューションセンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120




第 1 章

Vivado インプリメンテーションプロセス

Vivado インプリメンテーションプロセスについてザイリンクス Vivado® Design Suite では、次のようなさまざまなデザインソースから UltraScale™ FPGA およびザイリンクス 7 シリーズ FPGA デザインをインプリメンテーションできます。

• RTL デザイン

• ネットリストデザイン

• IP 中心のデザイン

図 1-1 に Vivado ツールフローを示します。

Vivado インプリメンテーションは、デザインの論理制約、物理制約、タイミング制約を満たしながらネットリストをFPGA デバイスリソースに配置配線するためのすべての手順を含みます。

Vivado ツールでサポートされるデザインフローの詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 1] を参照してください。




第 1 章 : Vivado インプリメンテーションプロセス

Vivado インプリメンテーションでの SDC および XDC 制約のサポート

Vivado インプリメンテーションは、タイミングドリブンフローです。デザインの要件および制限を指定するのに、業界標準の Synopsys デザイン制約 (SDC) とザイリンクスデザイン制約 (XDC) がサポートされます。

Vivado インプリメンテーションのサブプロセス

Vivado Design Suite のインプリメンテーションプロセスでは、論理ネットリストおよび制約が配置配線済みデザインに変換され、ビットストリームを生成できるようにします。インプリメンテーションプロセスには、次のサブプロセスがあります。

• opt_design (デザインの適化) : ターゲットのザイリンクスデバイスにフィットしやすいように論理デザインを適化します。

• power_opt_design (デザインの消費電力適化) (オプション) : ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを適化します。

• place_design (デザインの配置) : デザインをターゲットザイリンクスデバイスに配置します。

• 配置後の power_opt_design (オプション) : 配置後に消費電力を削減するするよう追加の適化を実行します。

• 配置後の phys_opt_design (デザインの物理適化) (オプション) : 配置に基づく予測タイミングを使用してロジックおよび配置を適化します。ファンアウトの大きいドライバーの複製も含まれます。

• route_design (デザインの配線) : デザインをターゲットザイリンクスデバイスに配線します。

• 配線後の phys_opt_design (オプション) : 配線後の実際の遅延を使用して、ロジック、配置、および配線を適化します。

X-Ref Target - Figure 1-1

図 1-1 : Vivado Design Suite のデザインフロー





• write_bitstream (ビットストリームの生成) : ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。通常、インプリメンテーションの後にビットストリームを生成します。

ビットストリーム生成の詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参照 12] を参照してください。

注記 : Vivado Design Suite では、デザインの一部をインプリメントしてパフォーマンスを予測するモジュール解析がサポートされています。このフローでは、 I/O が過剰に使用されないようにするため、 I/O バッファーは挿入されません。詳細は、『Vivado Design Suite ユーザーガイド : 階層デザイン』 (UG905) [参照 2] を参照してください。

Vivado ツールでのマルチスレッド

マルチプロセッサシステムでは、 DRC レポート、スタティックタイミング解析、配置、配線などのプロセスを高速化するため、マルチスレッドが使用されます。同時に使用される大スレッド数は、 OS、プロセッサの数、タスクによって異なります。タスクによって使用される大スレッド数は、次のとおりです。

• DRC レポート : 8

• スタティックタイミング解析 : 8

• 配置 : 8

• 配線 : 8

すべてのタスクに適用される一般的な制限もあり、 OS によって異なります。 Windows システムではこの制限は 2 で、Linux システムでは 8 です。この制限は、 general.maxThreads というパラメーターを使用して変更できます。制限を変更するには、次のコマンドを使用します。

Vivado% set_param general.maxThreads <new limit>

<new limit> に有効な値は、 1 ～ 8 の整数値です。次に、 Windows システムでの例を示します。

Vivado% get_param general.maxThreads 2

この場合、プロセッサ数または実行されるタスクにかかわらず、すべてのタスクで使用されるスレッドの大数は 2です。システムに 8 個以上のプロセッサがある場合、タスクで使用される大スレッド数を 8 に設定できます。

Vivado% set_param general.maxThreads 8

同時に使用可能なスレッド数は、次の小の値になります。

• プロセッサの大数

• タスクの制限スレッド数

• 一般制限スレッド数

Tcl API によるスクリプトのサポート

Vivado Design Suite には、 Tcl API が含まれています。 Tcl API を使用すると、すべてのデザインフローをスクリプトで実行でき、デザインフローを要件に合わせてカスタマイズできます。

注記 : Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 15] を参照するか、「<command> -help」と入力してください。





インプリメンテーションの制御Vivado Design Suite ではさまざまなデザインフローが提供されており、多種のデザインソースがサポートされています。 FPGA デバイスにダウンロード可能なビットストリームを生成するには、インプリメンテーションを実行する必要があります。

インプリメンテーションは、論理ネットリストをターゲットザイリンクスデバイスの物理的なアレイにマップするための一連の手順を指します。次の手順が含まれます。

• ロジック適化

• ライブラリセルの配置

• セル間の接続の配線

プロジェクトモードと非プロジェクトモード

Vivado Design Suite では、インプリメンテーションをプロジェクトファイルを使用して (プロジェクトモード )、またはプロジェクトファイルを使用せずに (非プロジェクトモード ) 実行できます。

プロジェクトモード

プロジェクトファイル (.xpr) とそのディレクトリ構造を作成すると、次が可能になります。

• デザインソースファイルの管理

• 合成 run およびインプリメンテーション run の結果の保存

• デザインフローを通してプロジェクトステータスを監視

プロジェクトモードでの作業

プロジェクトモードでは、ディスク上にディレクトリ構造が作成され、それを利用してデザインソース、 run の結果およびレポート、プロジェクトステータスが管理されます。

デザインデータ、プロセス、およびステータスを自動管理するには、 Vivado プロジェクトファイル (.xpr) に保存されるプロジェクトインフラストラクチャが必要です。

また、デザインフローの主要な段階のチェックポイントファイルが、自動的にローカルプロジェクトディレクトリに保存されます。

プロジェクトモードでインプリメンテーションを実行するには、 IDE で [Run Implementation] をクリックしてインプリメンテーション run を実行するか、 Tcl コマンドで launch_runs を使用するだけです。 Vivado でのプロジェクトの使用に関する詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 1] を参照してください。





Flow Navigator

Vivado 統合設計環境 (IDE) を使用すると、完全なデザインフローを実行できます。 Vivado IDE には、 Flow Navigatorというフローを制御するインターフェイスがあります。

Flow Navigator は Vivado Design Suite のメインウィンドウの左側に表示され、ここからデザインおよび IP を作成、インプリメント、および検証できます。デザインフローを簡略化するため、インプリメンテーションプロセス全体をコマンドをクリックするだけで実行できます。次の図に、 Flow Navigator の [Implementation] セクションを示します。

重要 : このガイドでは、インプリメンテーション以外の Vivado IDE の詳細は説明しません。FPGA デザインフロー全体に関連する Vivado IDE の詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] を参照してください。

非プロジェクトモード

プロジェクトファイルおよびローカルディレクトリを作成せずに、メモリ内のデザインで作業することも可能です。プロジェクトファイルを使用しないコンパイル形式のフローは、非プロジェクトモードと呼ばれます。ソースファイルおよびデザイン制約は、現在の場所からメモリに読み込みます。メモリ内のデザインでデザインフローを実行する際、中間ファイルが記述されることはありません。

非プロジェクトモードでは、各インプリメンテーション Tcl コマンドを適切なオプションと共に使用し、各手順を個別に実行する必要があります。

変更を保存したり手順を再実行したりする必要なく、デザインに変更を加え、デザインフローを続行できます。デザインフローのどの段階でも、レポートを生成したり、デザインチェックポイント (.dcp) を保存したりできます。

重要 : 非プロジェクトモードでは、 Vivado デザインツールを終了すると、メモリ内のデザインは失われます。そのため、合成、配置、配線などの主な手順が終了したら、デザインチェックポイントを保存することをお勧めします。

デザインチェックポイントは、プロジェクトモードおよび非プロジェクトモード両方で保存できます。デザインチェックポイントを開くことができるのは、非プロジェクトモードのみです。


図 1-2 : Flow Navigator : [Implemention] セクション





プロジェクトモードと非プロジェクトモードの違い

Vivado インプリメンテーションは、プロジェクトモードおよび非プロジェクトモード両方で実行できます。 VivadoIDE および Tcl API は、プロジェクトモードおよび非プロジェクトモード両方で使用できます。

プロジェクトモードと非プロジェクトモードには、多くの違いがあります。次に、非プロジェクトモードでは使用できない機能を示します。

• Flow Navigator

• デザインステータスインジケーター

• IP カタログ

• インプリメンテーション run および run ストラテジ

• [Design Runs] ビュー

• [Messages] ビュー

• [Reports] ビュー

注記 : このリストには、非プロジェクトモードでサポートされない機能がすべて含まれているわけではありません。

非プロジェクトベースのデザインをインプリメントするには、次の Tcl コマンドを個別に実行する必要があります。

• opt_design

• power_opt_design (オプション)

• place_design

• phys_opt_design (オプション)

• route_design

• write_bitstream

インプリメンテーションの各段階は、 Tcl コンソールから対話的に実行するか、 Vivado IDE で実行するか、カスタムTcl スクリプトを使用して実行できます。デザインフローは、必要に応じてレポートコマンドや適化を追加してカスタマイズできます。詳細は、「非プロジェクトモードでのインプリメンテーションの実行」を参照してください。

このガイドでは、プロジェクトモードおよび非プロジェクトモードでのインプリメンテーションの実行について詳細に説明します。

プロジェクトモードまたは非プロジェクトモードを使用した Vivado Design Suite の実行に関する詳細は、次の資料を参照してください。

• 『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 1]

• 『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3]

インプリメンテーションフローの開始

インプリメンテーションフローは通常、メモリに合成済みデザインを読み込むことにより開始します。その後、インプリメンテーションフローを実行するか、デザインを解析してデザインと制約を調整し、アップデート後に再読み込みできます。

合成済みデザインでインプリメンテーションフローを開始するには、次の 2 つの方法があります。

• Vivado 合成を実行します。プロジェクトモードでは、合成 run に合成結果が含まれ、これらの結果が自動的にインプリメンテーション run の入力として使用されます。非プロジェクトモードでは、 synth_design コマンドが完了した後、合成結果はメモリ内にあるので、そこからインプリメンテーションに進むことができます。

• 合成済みネットリストを読み込みます。合成にサードパーティツールを使用した場合などは、合成済みネットリストを入力デザインソースとして使用できます。





インプリメンテーションを開始するには、次の手順に従います。

• プロジェクトモードでは、インプリメンテーション run を実行します。

• 非プロジェクトモードでは、スクリプトを実行するか、コマンドを対話的に実行します。

デザインを解析して制約を調整するには、インプリメンテーションを実行せずに合成済みデザインを読み込みます。

• プロジェクトモードでは、Flow Navigator の [Open Synthesized Design] をクリックして、合成 run の結果である合成済みデザインを開きます。

• 非プロジェクトモードでは、 link_design コマンドを使用してデザインを読み込みます。

非プロジェクトモードでは、デザインチェックポイントを使用することもできます。チェックポイントを開くと、デザインが読み込まれてそのチェックポイントの状態が復元されます。配置および配線データが含まれる場合もあります。これにより、配線済みデザインを読み込んで配線を変更したり、配置済みデザインを読み込んで異なるオプションを使用して配線を複数回実行するなど、再配線インプリメンテーションフローを実行できます。

合成済みネットリストのインポート

Vivado Design Suite では、ネットリストデザインがサポートされており、ザイリンクスツールまたはサードパーティツールで合成済みのネットリストをインポートできます。サポートされるネットリストフォーマットは、次のとおりです。

• Structural Verilog

• Structural SystemVerilog

• EDIF

• ザイリンクス NGC

• 合成済みデザインチェックポイント (DCP)

重要 : プロジェクトモードまたは非プロジェクトモードで IP を使用する場合は、DCP ファイルではなく XCI ファイルを使用してください。これにより、デザインフローのすべての段階で IP 出力ファイルが一貫して使用されます。IP が独立モジュールとして合成されており、関連する DCP ファイルが既にある場合は、その DCP ファイルが自動的に使用され、 IP は再合成されません。詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 4] を参照してください。

Vivado Design Suite でサポートされるソースファイルおよびプロジェクトタイプの詳細は、『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895) [参照 6] を参照してください。

RTL ソースから開始

Vivado インプリメンテーションを実行するには、合成済みネットリストが必要です。デザインは合成済みネットリストから、または RTL ソースファイルから開始できます。

重要 : RTL ソースから開始する場合は、インプリメンテーションの前に Vivado 合成を実行する必要があります。Vivado IDE では、これが自動的に管理されます。合成されていないデザインをインプリメントしようとすると、まず合成を実行するかどうかを選択するオプションが表示されます。

Vivado 合成の詳細は、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。





非プロジェクトモードで合成済みデザインを作成して開く

非プロジェクトモードでは、 Tcl コマンド synth_design を使用して合成を実行し、合成済みデザインを作成して開く必要があります。サポートされている入力フォーマットの合成済みネットリストを開くには、 Tcl コマンドlink_design も使用できます。合成済みデザインチェックポイントを開くには、 open_checkpoint コマンドを使用します。

詳細は、第 2 章「インプリメンテーションコマンド」の「合成済みデザインを開く」を参照してください。

プロジェクトモードでインプリメンテーション前にデザインネットリストを読み込む

プロジェクトモードでは、 RTL デザインの合成後、またはネットリストベースプロジェクトを開いて、インプリメンテーション前のデザインネットリストを読み込むことができます。

合成済みデザインを開くには、次のいずれかを実行します。

• メインメニューから [Flow] → [Open Synthesized Design] をクリックします。

• Flow Navigator で [Synthesis] → [Open Synthesized Design] をクリックします。

• [Design Runs] ビューで合成 run を右クリックし、 [Open Synthesized Design] をクリックします。

IP の設定、インプリメント、および検証合成前にデザインに IP をインポートする方法の詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』(UG896) [参照 4] を参照してください。





インプリメンテーションでのデザイン制約の使用

推奨 : インプリメンテーションを実行する際は、デザイン制約を設定してください。

デザイン制約には、物理制約とタイミング制約の 2 種類があります。これらの制約を、次に説明します。

物理制約物理制約は、次のような論理デザインオブジェクトとデバイスリソースの関係を定義します。

• パッケージピンの配置

• 次のようなセルの絶対または相対配置

° ブロック RAM

° DSP

° LUT

° フリップフロップ

• セルをデバイスの汎用領域に割り当てるフロアプラン制約

• デバイスコンフィギュレーション設定

タイミング制約

タイミング制約は業界標準の SDC で記述され、デザインの周波数要件を定義します。

タイミング制約を設定しない場合、デザインがワイヤの長さおよび配線の密集度にのみ基づいて適化され、デザインパフォーマンスが評価されたり向上したりすることはありません。

UCF タイミング制約はサポートされない

重要 : Vivado Design Suite では、 UCF フォーマットはサポートされません。

UCF 制約を XDC コマンドに変換する方法については、『ISE から Vivado Design Suite への移行ガイド』 (UG911) [参照 16] を参照してください。





制約セットにより複数の制約ファイルをデザインに適用

制約セットは、プロジェクトモードのデザインに適用する制約ファイルのリストです。制約セットには、 XDC ファイルに記述されたデザイン制約が含まれます。

制約セットの構造

次の制約セットの構造がサポートされます。

• 複数の制約ファイルを含む制約セット

• 個別の物理制約ファイルおよびタイミング制約ファイルを含む制約セット

• マスター制約ファイル

• 新しい制約ファイルに制約の変更を保存

• 複数の制約セット

ヒント : 制約を機能に応じて別の制約ファイルに分けておくと、制約ストラテジ全体がわかりやすくなり、タイミングおよびインプリメンテーションを変更しやすくなります。

複数の制約セット

プロジェクトに複数の制約セットを作成できます。複数の制約セットを作成すると、異なるインプリメンテーションrun で異なる制約を試すことができます。

たとえば、合成とインプリメンテーションに異なる制約セットを指定できます。合成、シミュレーション、インプリメンテーションで異なる制約を適用して試すことができます。

デザイン制約を複数の制約セットを使用して整理すると、次のような利点があります。

• 同じプロジェクトで異なるザイリンクス FPGA デバイスをターゲットとして設定できます。ターゲットデバイスが異なると、物理制約およびタイミング制約も異なるものにする必要がある場合があります。

• さまざまな条件でデザインを実行できます。制約セットを使用して、異なるフロアプランを適用したり、デザインの制約を厳しくしたりできます。

• 制約の変更を管理しやくすなります。マスター制約の代わりに、別の制約ファイルに保存した制約を使用できます。

ヒント : タイミング制約を検証するには、合成済みデザインで report_timing_summary コマンドを実行します。インプリメンテーションの前に、問題のある制約を修正してください。

配置配線に影響する制約の定義および制約での作業の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』(UG903) [参照 9] を参照してください。





制約を attribute 文として追加

制約は、 HDL ソースに attribute 文として追加できます。属性は、 Verilog および VHDL ソースの両方に追加でき、Vivado 合成または Vivado インプリメンテーションに渡すことができます。

HDL 属性としてのみ設定可能で、 XDC では設定できない制約もあります。この場合、制約を HDL ソースファイルで属性として指定する必要があります。たとえば、相対配置マクロ (RPM) は HDL 属性として定義する必要があります。 RPM とは、複数のロジックエレメント (FF、 LUT、 DSP、 RAM など) の相対的な配置を指定したものです。

U_SET および HU_SET 属性を使用して RPM を定義し、相対ロケーション属性を使用して相対配置を定義できます。

相対ロケーション制約の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 9] を参照してください。

XDC でサポートされない制約の詳細は、『ISE から Vivado Design Suite への移行ガイド』 (UG911) [参照 16] を参照してください。

デザインチェックポイントを使用したデザインのスナップショットの保存および復元Vivado Design Suite では、物理デザインデータベースを使用して配置配線情報を格納します。デザインチェックポイントファイル (.dcp) を使用すると、デザインフローの主要な段階でこの物理データベースを保存および復元できます。チェックポイントは、フローの特定の地点におけるデザインのスナップショットです。

デザインチェックポイントファイルには、次のものが含まれます。

• インプリメンテーション中に適用された適化を含む現在のネットリスト

• デザイン制約

• インプリメンテーション結果

チェックポイントデザインに対しては、 Tcl コマンドを使用してデザインフローの残りの段階を実行できます。新しいデザインソースを使用して変更することはできません。

重要 : プロジェクトモードでは、デザインフローの進行に応じて、 Vivado デザインツールにより自動的にチェックポイントが保存および復元されます。非プロジェクトモードでは、デザインフローの適切な段階でユーザーがチェックポイントを保存する必要があります。そうしないと、メモリ内のデザインは失われます。

チェックポイントファイルの保存フローの任意の段階におけるデザインデータベースのスナップショットを保存するには、 [File] → [Write Checkpoint]をクリックします。これにより、拡張子が .dcp のファイルが作成されます。

これに相当する Tcl コマンドは write_checkpoint です。

チェックポイントファイルの読み込み Vivado Design Suite でチェックポイントを開くには、 [File] → [Open Checkpoint] をクリックします。

デザインチェックポイントが別のプロジェクトとして開きます。

これに相当する Tcl コマンドは open_checkpoint です。





非プロジェクトモードでのインプリメンテーションの実行非プロジェクトモードで合成済みデザインまたはネットリストをターゲットのザイリンクス FPGA デバイスにインプリメントするには、インプリメンテーションのサブプロセスに対応する Tcl コマンドを実行する必要があります。

• opt_design (デザインの適化) : ターゲットのザイリンクスデバイスにフィットしやすいように論理デザインを適化します。

• power_opt_design (デザインの消費電力適化) (オプション) : ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを適化します。

• place_design (デザインの配置) : デザインをターゲットザイリンクスデバイスに配置します。

• 配置後の power_opt_design (オプション) : 配置後に消費電力を削減するするよう追加の適化を実行します。

• 配置後の phys_opt_design (デザインの物理適化) (オプション) : 配置に基づく予測タイミングを使用してロジックおよび配置を適化します。ファンアウトの大きいドライバーの複製も含まれます。

• route_design (デザインの配線) : デザインをターゲットザイリンクスデバイスに配線します。

• 配線後の phys_opt_design (オプション) : 配線後の実際の遅延を使用して、ロジック、配置、および配線を適化します。

• write_bitstream (ビットストリームの生成) : ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。通常、インプリメンテーションの後にビットストリームを生成します。ビットストリーム生成の詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参照 12] を参照してください。

これらのプロセスは、まとめて「インプリメンテーション」と呼ばれます。

コマンドは、次のいずれかの方法で実行します。

• Vivado IDE の Tcl コンソールから

• Vivado Design Suite Tcl シェルの Tcl プロンプトから

• インプリメンテーションコマンドを含む Tcl スクリプトを使用し、 Vivado Design Suite でそのスクリプトを実行





非プロジェクトモードのサンプルスクリプト

次に、非プロジェクトモードでインプリメンテーションを実行するスクリプト例を示します。スクリプト名がrun.tcl であるとしたら、 Tcl シェルに「source run.tcl」と入力してスクリプトを呼び出します。

# Step 1: Read in top-level EDIF netlist from synthesis toolread_edif c:/top.edf # Read in lower level IP core netlistsread_edif c:/core1.edfread_edif c:/core2.edf

# Step 2: Specify target device and link the netlists# Merge lower level cores with top level into single designlink_design -part xc7k325tfbg900-1 -top top

# Step 3: Read XDC constraints to specify timing requirementsread_xdc c:/top_timing.xdc # Read XDC constraints that specify physical constraints such as pin locationsread_xdc c:/top_physical.xdc

# Step 4: Optimize the design with default settingsopt_design

# Step 5: Place the design and save a checkpoint# It is recommended to save progress at certain intermediate steps# The placed checkpoint can also be routed in multiple runs using different optionsplace_designwrite_checkpoint post_place.dcp

# Step 6: Route the design route_design

# Step 7: Run Timing Summary Report to see timing resultsreport_timing_summary -file post_route_timing.rpt # Run Utilization Report for device resource utilizationreport_utilization -file post_route_utilization.rpt

# Step 8: Write checkpoint to capture the design database; # The checkpoint can be used for design analysis in Vivado IDE or TCL APIwrite_checkpoint post_route.dcp

非プロジェクトモードのサンプルスクリプトでの主要な手順

17 ページの「非プロジェクトモードのサンプルスクリプト」では、次の手順が実行されます。

• 手順 1 : デザインソースファイルの読み込み

• 手順 2 : メモリ内へのデザインの構築

• 手順 3 : デザイン制約の読み込み

• 手順 4 : ロジック適化の実行

• 手順 5 : デザインの配置

• 手順 6 : デザインの配線

• 手順 7 : レポートの生成

• 手順 8 : デザインチェックポイントの保存





手順 1 : デザインソースファイルの読み込み

read_edif コマンドを使用して EDIF ネットリストデザインソースを読み込みます。非プロジェクトモードでは、RTL デザインフローもサポートされています。その場合、ソースファイルを読み込んでインプリメンテーションの前に合成を実行します。

合成済みデザインチェックポイントファイルをソースとして追加するには、 read_checkpoint コマンドを使用します。

read_* Tcl コマンドは非プロジェクトモードで使用するコマンドで、ディスク上のファイルを読み込んでメモリ内にデザインを構築します。ファイルがコピーされたり、ファイルの依存関係が作成されることはありません。

そのため、非プロジェクトモードは非常に柔軟です。

重要 : ユーザーがソースデザインファイルの変更を管理し、それに応じてデザインをアップデートする必要があります。

手順 2 : メモリ内へのデザインの構築

link_design コマンドを使用してデザインのメモリ内表示を構築します。このコマンドは、ツールに読み込まれたネットリストベースのソースファイルをザイリンクスのデバイス情報と結合して、メモリ内にデザインデータベースを作成します。

非プロジェクトモードでのすべての操作は、 Vivado ツール内のインメモリデータベースに対して実行されます。

Vivado ツールをバッチモードで実行している場合でも、 Tcl シェルモードで対話的に Tcl コマンドを実行している場合でも、グラフィカルモードでデザインデータを Vivado IDE で表示している場合でも、メモリ内のデザインは Vivadoツール内に存在します。

手順 3 : デザイン制約の読み込み

Vivado Design Suite では、デザイン制約を使用してデザインの物理特性およびタイミング特性を定義します。

詳細は、 13 ページの「インプリメンテーションでのデザイン制約の使用」を参照してください。

read_xdc コマンドは、 XDC 制約ファイルを読み込み、メモリ内のデザインに適用します。

ヒント : プロジェクトモードでは、異なる目的で複数の制約ファイルを含む制約セットを定義できますが、非プロジェクトモードでは、同じ操作を実行するのに複数の read_xdc コマンドを使用します。

手順 4 : ロジック最適化の実行

配置配線の準備としてロジック適化を実行します。適化では、ターゲットデバイスの物理リソースに配置する前にロジックデザインが簡略化されます。

Vivado のネットリスト適化では、デザイン要件を満たすため、さまざまな適化機能が提供されています。詳細は、 70 ページの「ロジック適化」を参照してください。

手順 5 : デザインの配置

place_design コマンドを使用してデザインを配置します。詳細は、 75 ページの「配置」を参照してください。配置後、 write_checkpoint コマンドを使用してデザインチェックポイントファイルを保存します。





手順 6 : デザインの配線

route_design コマンドを使用してデザインを配線します。詳細は、 87 ページの「配線」を参照してください。

手順 7 : レポートの生成

report_timing_summary コマンドは、タイミング解析を実行し、タイミング違反の詳細を含むタイミングレポートを生成します。 report_utilization コマンドは、使用されているデバイスリソースの割合と、その他の使用率統計のサマリを生成します。非プロジェクトモードでは、各レポートを Tcl コマンドを使用して生成する必要があります。各レポートコマンドでは -file オプションがサポートされており、レポートをファイルに保存できます。レポートコマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 15] を参照してください。

レポートはファイルに出力するか、 Vivado IDE に表示して確認できます。詳細は、 59 ページの「インプリメンテーションレポートの表示」を参照してください。

手順 8 : デザインチェックポイントの保存

メモリ内のデザインをデザインチェックポイントに保存します。保存されたチェックポイントデザインには、次が含まれます。

• 論理ネットリスト

• 物理制約およびタイミング制約

• ザイリンクスパーツ情報

• 配置配線情報

非プロジェクトモードでは、デザインチェックポイントファイルを保存することで、後でデザインを読み込んで解析したり変更したりできます。

詳細は、 15 ページの「デザインチェックポイントを使用したデザインのスナップショットの保存および復元」を参照してください。

プロジェクトモードでのインプリメンテーションの実行プロジェクトモードでは、次が可能です。

• 特定の合成結果およびデザイン制約を使用するインプリメンテーション run を定義

• 1 つのデザインに対して複数のストラテジを実行

• デザイン要件を満たすためインプリメンテーションストラテジをカスタマイズ

• カスタマイズしたインプリメンテーションストラテジをほかのデザインで使用するため保存

重要 : 非プロジェクトモードでは、定義済みのインプリメンテーション run およびストラテジはサポートされません。Tcl コマンドを使用して、インプリメンテーションプロセスの各段階を手動で実行する必要があります。詳細は、16 ページの「非プロジェクトモードでのインプリメンテーションの実行」を参照してください。





インプリメンテーション run の作成

新しいインプリメンテーション run を作成して起動し、適な結果が得られるようさまざまなオプションを試すことができます。各 run は順次起動するか、複数のローカル CPU で同時に起動できます。

Linux システムでは、リモートサーバーで run を実行することも可能です。詳細は、付録 A 「リモートホストおよびLSF の使用」を参照してください。

インプリメンテーション run の定義

インプリメンテーション run を定義するには、次の手順に従います。

1. メインメニューから [Flow] → [Create Runs] をクリックします。

または、 Flow Navigator で [Implementation] を右クリックして [Create Implementation Runs] をクリックするか、[Design Runs] ビューを右クリックして [Create Runs] をクリックします。

Create New Runs ウィザードが開きます。

2. Create New Runs ウィザードの初のページで [Implementation] をオンにし、 [Next] をクリックします。

3. 次の図に示す [Configure Implementation Runs] ページが表示されます。図の下の説明に従って run を設定します。

a. [Name] 列に run の名前を入力するか、デフォルトのままにします。

b. [Synth Name] 列で、インプリメンテーションに使用する合成済みネットリストを生成する合成 run を選択します。ネットリストプロジェクトの場合は、 [Create Runs] コマンドに合成 run の名前は必要ありません。

サードパーティ合成ツールからプロジェクトにインポートされた合成済みネットリストも選択できます。

詳細は、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。

デフォルトは、 [Design Runs] ビューで現在アクティブな run です。詳細は、付録 C 「インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定」を参照してください。


図 1-3 : Create New Runs ウィザード : [Configure Implementation Runs] ページ





c. [Constraints Set] 列でインプリメンテーションに適用する制約セットを選択します。適化、配置、および配線は、指定された制約セットの物理制約およびタイミング制約に基づいて実行されます。

制約セットの詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 9] を参照してください。

d. [Part] 列でターゲットパーツを選択します。

デフォルトでは、制約セットおよびターゲットパーツは、 [Create New Runs] コマンド実行したときのプロジェクト設定に基づいて定義されます。

プロジェクト設定の詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] を参照してください。

ヒント : 異なる制約セットまたはターゲットパーツを使用する run を作成するには、 [Create New Runs] コマンドを使用します。既存の run のこれらの値は、 [Design Runs] ビューで run を選択し、 [Run Properties] ビューで変更できます。

詳細は、 25 ページの「インプリメンテーション run 設定の変更」を参照してください。

e. [Strategy] 列でストラテジを選択します。

ストラテジとは、インプリメンテーション結果を制御する Vivado インプリメンテーション機能オプションを定義した設定のことです。Vivado Design Suite では、定義済みのストラテジが提供されています。また、独自のインプリメンテーションストラテジを作成することも可能です。

付録 C 「インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定」に示すストラテジのいずれかを選択します。

ストラテジは、その目的に応じてカテゴリ別に分類されており、カテゴリ名が接頭辞となっています。カテゴリは、付録 C 「インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定」を参照してください。

詳細は、 31 ページの「ストラテジの定義」を参照してください。

パフォーマンスストラテジは、デザインパフォーマンスを向上することを目的としており、実行時間は長くなります。パフォーマンスストラテジを選択する前に、まずインプリメンテーションのデフォルトを使用してタイミング要件を満たすようにしてください。このようにすると、デザインの変更によるタイミングクロージャの影響を吸収するのに十分なマージンが得られます。ただし、デザイン要件が満たされない場合、実行時間が長くなることが許容されるのであれば、 Performance_Explore はすべてのタイプのデザインを網羅しているので、初に選ぶストラテジとして適しています。

重要 : 名前に SLL または SLR が含まれるストラテジは、 SSI デバイスでのみ使用可能です。

ヒント : run を実行する前に、インプリメンテーションプロセスの各段階の設定を、選択したストラテジのデフォルト設定から変更できます。変更した設定を新しいストラテジとしても保存できます。詳細は、 25 ページの「インプリメンテーション run 設定の変更」を参照してください。

f. [More] をクリックし、追加の run を定義します。デフォルトでは、シーケンスの次のストラテジが自動的に選択されます。追加 run の名前とストラテジを指定します (図 1-3)。

g. [Make Active] チェックボックスを使用して、実行する run を選択します。

h. [Next] をクリックします。





4. 次の図に示す [Launch Options] ページが表示されます。図の下の説明に従ってオプションを設定します。

注記 : 上図に示されている [Launch runs on remote hosts] は Linux でのみ表示されます。 Windows では表示されません。

a. [Launch directory] でインプリメンテーション run データを作成し、保存する場所を指定します。

デフォルトのディレクトリは、ローカルのプロジェクトディレクトリ構造に含まれます。デフォルトでは、インプリメンテーション run のファイルは次のディレクトリに保存されます。

<project_name>/<project_name>.runs/<run_name>

ヒント : プロジェクトファイルには絶対パスが記述されるので、プロジェクトディレクトリ外の場所を指定すると、プロジェクトを移動しにくくなります。

b. ラジオボタンおよびドロップダウンリストを使用して、プロジェクトに適切な設定を指定します。次のいずれかを選択します。

- [Launch runs on local host] : ローカルマシンで run を実行します。

- [Number of jobs] : 複数の run を同時実行する際に使用するローカルプロセッサの数を指定します。

- [Launch runs on remote hosts] (Linux のみ) : ジョブを起動するのにリモートホストを使用します。

- [Configure Hosts] : リモートホストを設定します。詳細は、付録 A 「リモートホストおよび LSF の使用」を参照してください。

- [Launch runs using LSF] (Linux のみ) : LSF (Load Sharing Facility) の bsub コマンドを使用してジョブを起動します。 bsub コマンドオプションを設定して LSF 接続をテストするには、 [Configure LSF] ボタンをクリックします。

ヒント : LSF は、クラスターの複数の計算サーバー間でバッチジョブを送信、スケジュール、実行、監視、ワークロード制御するためのサブシステムです。

- [Generate scripts only] : run ディレクトリおよび run スクリプトをエクスポートおよび作成しますが、 runは起動しません。スクリプトは、 Vivado IDE ツールの環境外で後で実行できます。

- [Do not launch now] : 新しい run を保存しますが、 run スクリプトは実行または作成しません。


図 1-4 : [Launch Options] ページ





5. [Next] をクリックし、 [Create New Runs Summary] ページを確認します。

6. [Finish] をクリックします。定義した run が作成され、指定の実行オプションが実行されます。

新しい run が [Design Runs] ビューに追加されます。詳細は、「[Design Runs] ビューの使用」を参照してください。

[Design Runs] ビューの使用

[Design Runs] ビューには、プロジェクトで作成された合成 run とインプリメンテーション run のすべてが表示され、それらを設定、管理、実行するためのコマンドを実行できます。

[Design Runs] ビューを開く

[Design Runs] ビューが表示されていない場合は、 [Window] → [Design Runs] をクリックして表示します。

[Design Runs] ビューの機能

• インプリメンテーション run は、合成 run の下の階層にインデントされて表示されます。

• 1 つの合成 run に、複数のインプリメンテーション run を含めることができます。プラス記号 (+) やマイナス記号(-) をクリックすると、合成 run のツリー表示を展開したり、閉じたりできます。

• [Design Runs] ビューは、ツリー形式の表で示されます。

このビューのデータを列を使用して並べ替える方法は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』(UG893) [参照 3] を参照してください。

run のステータス

[Design Runs] ビューには、 run のステータスが表示されます。次のステータスがあります。

• 実行されていない

• 実行中

• 完了

• 新の状態でない

[Design Runs] ビューには、 run の開始時間と経過時間が表示されます。

実行時間

[Design Runs] ビューには、 run の開始時間と経過時間が表示されます。


図 1-5 : [Design Runs] ビュー





run のタイミング結果

[Design Runs] ビューには、インプリメンテーション run のタイミング結果 (WNS、 TNS、 WHS、 THS、 TPWS) が表示されます。

最新の状態でない run

ソースファイル、制約、またはプロジェクト設定を変更すると、 run は新の状態ではなくなります。 [Design Runs]ビューでは、 run をリセットしたり、古い run のデータを削除したりできます。

アクティブ run

Vivado IDE のすべてのビューには、アクティブな run の情報が表示されます。 [Log] ビュー、 [Reports] ビュー、ステータスバー、 [Project Summary] ビューには、アクティブな run の情報が表示されます。 [Project Summary] ビューには、アクティブな run のコンパイル、リソース、およびサマリ情報が表示されます。

ヒント : Vivado IDE でアクティブにできるのは、 1 つの合成 run と 1 つのインプリメンテーション run のみです。

アクティブな run は、 [Design Runs] ビューに太字で示されます。

run をアクティブにするには、次の手順に従います。

1. [Design Runs] ビューで 1 つの run を右クリックします。

2. [Make Active] をクリックします。





インプリメンテーション run 設定の変更

[Design Runs] ビューで run を選択すると、 [Run Properties] ビューにその run の現在の設定が表示されます (図 1-6)。

[Run Properties] ビューでは、次のオプションを変更できます。

• [Name] : run の名前

• [Part] : ターゲットパーツ

• [Description] : run の説明

• [Constraints] : インプリメンテーションで使用し、新しい制約を保存する制約セット

[Run Properties] ビューの詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] を参照してください。


図 1-6 : [Implementation Run Properties] ビュー





デザイン run の設定

デザイン run の設定を変更するには、[Design Run Settings] ダイアログボックスを使用します。[Design Run Settings] ダイアログボックスを開くには、次の手順に従います。


2. ポップアップメニューから [Change Run Settings] をクリックし、[Design Run Settings] ダイアログボックスを開きます。

ヒント : 設定の変更は、 run のステータスが「Not started」の場合にのみ可能です。 run を右クリックして [Reset Runs]をクリックすると、 run のステータスを「Not started」に戻すことができます。詳細は、 28 ページの「run のリセット」を参照してください。

[Design Run Settings] ダイアログボックスには、 run に適用されているインプリメンテーションストラテジ、インプリメンテーションプロセスの各段階でそのストラテジに関連するコマンドオプションが表示されます。次に、3 つのコマンドオプションについて説明します。

[Strategy]

インプリメンテーション run に適用するストラテジを選択します。 Vivado Design Suite では、定義済みのストラテジが提供されています。また、独自のインプリメンテーションストラテジを作成することも可能です。

詳細は、 31 ページの「ストラテジの定義」を参照してください。

[Description]

選択したインプリメンテーションストラテジの説明を表示します。


図 1-7 : [Design Run Settings] ダイアログボックス





[Options]

Vivado インプリメンテーションプロセスの各段階のコマンドラインオプションを表示します。次のコマンドのオプションが表形式で表示されます。

• opt_design (デザインの適化)

• power_opt_design (デザインの消費電力適化) (オプション)

• place_design (デザインの配置)

• 配置後の power_opt_design (デザインの消費電力適化) (オプション)

• 配置後の phys_opt_design (デザインの物理適化) (オプション)

• route_design (デザインの配線)

• 配線後の phys_opt_design (デザインの物理適化) (オプション)

• write_bitstream (ビットストリームの生成)

コマンドオプションをクリックすると、その説明がダイアログボックスの下部に表示されます。

各インプリメンテーション段階の詳細と設定可能なオプションは、第 2 章「インプリメンテーションコマンド」を参照してください。

コマンドオプションの変更

コマンドオプションを変更するには、そのコマンドオプションの右側の列をクリックします。次の操作を実行します。

• 定義済みの値から選択するオプションは、ドロップダウンリストから選択します。

• イネーブル/ディスエーブルにするオプションは、チェックボックスのオン/オフを切り替えます。

注記 : 各インプリメンテーションコマンドでよく使用されるコマンドオプションは、チェックボックスで選択できます。その他のオプションは、 [More Options] フィールドに入力します。オプション名の前にハイフンを付け、複数のオプションはスペースで区切ります。

• ユーザー定義の値を指定できるオプションは、値を入力します。

• ファイル名およびパスを指定するオプションは、ファイルを選択するダイアログボックスが開き、ファイルを選択できます。

• フックスクリプトと呼ばれるカスタム Tcl スクリプトをインプリメンテーションの各段階の前 (tcl.pre) と後(tcl.post) に挿入します。

フックスクリプトを挿入すると、インプリメンテーションの各段階の前後に特定のタスクを実行できます。たとえば、デザインの配置前後にタイミングレポートを生成して、タイミング結果を比較できます。

Tcl フックスクリプトの定義方法の詳細は、『Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用』(UG894) [参照 5] を参照してください。

ヒント : tcl.pre および tcl.post スクリプト内のパスは、プロジェクトの関連する run ディレクトリ<project>/<project.runs>/<run_name> を基準とします。

現在のプロジェクトまたは現在の run の DIRECTORY プロパティを使用して、 Tcl スクリプト内の相対パスを定義できます。

get_property DIRECTORY [current_project]get_property DIRECTORY [current_run]





[Save Design As]

[Strategy] フィールドの右側にある [Save Design As] ボタンをクリックすると、今後使用できるように、ストラテジへの変更を新しいストラテジとして保存できます。

注意 : [Save Design As] を使用しない場合、変更は現在のインプリメンテーション run には保存されますが、今後使用することはできません。

run ステータスの確認

Vivado IDE では、 run のステータスによって、 run を処理してインプリメンテーションを開始します。ステータスは、[Design Runs] ビューに表示されます (図 1-5)。

• run のステータスが「Not Started」の場合、 run はすぐに開始されます。

• run のステータスが「Error」になっている場合は、まず run がリセットされ、終了していない run データが削除されてから、 run が再開されます。

• run のステータスが「Complete」または「Out-of-Date」になっている場合は、 run をリセットするかどうか確認するメッセージが表示されます。

run のリセット

run をリセットするには、次の手順に従います。


2. [Reset Runs] をクリックします。

インプリメンテーション run をリセットすると、インプリメンテーションの初の段階 (opt_design) に戻ります。

run のリセットを確認するメッセージと、 run ディレクトリから生成されたファイルを削除するオプションが表示されます (図 1-8)。

ヒント : デフォルトでは、生成されたファイルは削除されます。生成された run ファイルを削除しない場合は、このオプションをオフにします。


図 1-8 : [Reset Runs] ダイアログボックス





run の削除

[Design Runs] ビューから run を削除するには、次の手順に従います。

1. run を右クリックします。

2. [Delete] をクリックします。

run のリセットを確認するメッセージと、 run ディレクトリから生成されたファイルを削除するオプションが表示されます (図 1-9)。

ヒント : デフォルトでは、生成されたファイルは削除されます。生成された run ファイルを削除しない場合は、このオプションをオフにします。

インプリメンテーションストラテジのカスタマイズ新しいインプリメンテーション run を定義すると、デフォルトのインプリメンテーション設定が使用されます。これらの設定は変更できます。

図 1-10 に、 [Project Settings] ダイアログボックスの [Implementation] ページを示します。このダイアログボックスは、メインメニューから [Tools] → [Project Settings] をクリックすると開きます。

ヒント : 非プロジェクトモードを使用している場合は、 [Project Settings] コマンドは使用できません。インプリメンテーションストラテジをバッチモードで使用可能な Tcl スクリプトとして定義して保存するか、 Vivado IDE で対話的に定義します。


図 1-9 : [Delete Runs] ダイアログボックス





Flow Navigator からアクティブなインプリメンテーション run のインプリメンテーション設定にアクセス

アクティブなインプリメンテーション run のインプリメンテーション設定は、Flow Navigator で [Implemented Settings] をクリックしても開くことができます。

開いた [Project Settings] ダイアログボックスの [Implementation] ページ (図 1-10)には、次のフィールドがあります。

• [Default constraint set] :インプリメンテーション run でデフォルトで使用する制約セットを選択します。

• [Incremental compile] :インクリメンタルコンパイルチェックポイントを指定します (オプション)。

• [Strategy] :インプリメンテーション run に適用するストラテジを選択します。 Vivado Design Suite では、定義済みのストラテジが提供されています。独自のインプリメンテーションストラテジを作成し、新しいストラテジとして保存することも可能です。詳細は、「ストラテジの定義」を参照してください。

• [Description] :選択したインプリメンテーションストラテジの説明を表示します。ユーザー定義のストラテジの説明は、新しい説明を入力して変更できます。 Vivado ツールの標準インプリメンテーションストラテジの説明は変更できません。





ストラテジの定義

ストラテジは、デザインの合成またはインプリメンテーションで適な結果が得られるようにするために定義されたソリューションです。

• Vivado インプリメンテーション機能のあらかじめ設定されたオプションにより定義されます。

• ストラテジは、ツールおよびバージョン特定です。

• Vivado Design Suite の各メジャーリリースには、バージョン特定のストラテジが含まれます。


図 1-10 : [Project Settings] ダイアログボックスの [Implementation] ページ





Vivado インプリメンテーションには、内部ベンチマークでテストされた一般的なストラテジが複数含まれています。

ヒント : 定義済みのインプリメンテーションストラテジに変更を保存することはできませんが、定義済みのストラテジをコピーして変更し、カスタムストラテジとして保存できます。


図 1-11 : デフォルトのインプリメンテーションストラテジ





定義済みストラテジへのアクセス

定義済みストラテジにアクセスするには、メインメニューから [Tools] → [Options] をクリックし、左側のペインで[Strategies] をクリックします。

ストラテジの確認、コピー、変更

ストラテジを確認、コピー、変更するには、次の手順に従います。

1. [Tools] → [Options] をクリックします。

2. 左側のペインで [Strategies] をクリックします。

[Vivado Options] ダイアログボックスの [Strategies] ページ (図 1-11) に、各ツールとリリースバージョン用にあらかじめ定義されたストラテジがリストされます。

3. [Flow] ドロップダウンリストから、適切なバージョンの [Vivado Implementation] を選択します。含まれているストラテジが表示されます。

4. 新しいストラテジを作成するには、ツールバーまたはポップアップメニューから [Create New Strategy] をクリックします。

5. 既存のストラテジをコピーするには、ツールバーまたはポップアップメニューから [Create a Copy of thisStrategy] をクリックします。次の操作が実行されます。

a. 選択しているストラテジのコピーが作成されます。

b. [User Defined Strategies] リストに追加されます。

c. ダイアログボックスの右側にストラテジのオプションが表示され、変更できるようになります。

6. 新しいストラテジに対して次の情報を入力します。

° [Name]ストラテジの名前を入力します。

° [Type][Synthesize] または [Implement] を選択します。

° [Tool version]ツールバージョンを指定します。

° [Description]ストラテジの説明を入力します。ここで入力した説明が [Design Run] ビューの結果の表に表示されます。

7. 次のインプリメンテーション手順のオプションを変更します。

° opt_design (デザインの適化)

° power_opt_design (デザインの消費電力適化) (オプション)

° place_design (デザインの配置)

° 配置後の power_opt_design (デザインの消費電力適化) (オプション)

° 配置後の phys_opt_design (デザインの物理適化) (オプション)

° route_design (デザインの配線)

° 配線後の phys_opt_design (デザインの物理適化) (オプション)

° write_bitstream (ビットストリームの生成)

ヒント : 特定のコマンドオプションを選択すると、その説明がダイアログボックスの下部に表示されます。

各インプリメンテーション段階の詳細と設定可能なオプションは、第 2 章「インプリメンテーションコマンド」を参照してください。





8. コマンドオプションの右側をクリックして、コマンドオプションを変更します (図 1-12)。

次の操作を実行します。

° 定義済みの値から選択するオプションは、ドロップダウンリストから選択します。

° イネーブル/ディスエーブルにするオプションは、チェックボックスのオン/オフを切り替えます。

° テキスト入力フィールドのオプションは、値を入力します。

° ファイル名およびパスを指定するオプションは、ダイアログボックスでファイルを選択します。

° フックスクリプトと呼ばれるカスタム Tcl スクリプトをインプリメンテーションの各段階の前 (tcl.pre)と後 (tcl.post) に挿入します。フックスクリプトを挿入すると、インプリメンテーションの各段階の前後に特定のタスクを実行できます。たとえば、デザインの配置前後にタイミングレポートを生成して、タイミング結果を比較できます。

Tcl フックスクリプトの定義方法の詳細は、『Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用』 (UG894) [参照 5] を参照してください。

注記 : tcl.pre および tcl.post スクリプト内のパスは、プロジェクトの関連する run ディレクトリ<project>/<project.runs>/<run_name> を基準とします。

現在のプロジェクトまたは現在の run の DIRECTORY プロパティを使用して、スクリプト内の相対パスを定義できます。

get_property DIRECTORY [current_project]get_property DIRECTORY [current_run]

9. [OK] をクリックして新しいストラテジを保存します。

新しいストラテジは、 [User Defined Strategies] の下にリストされます。ユーザー定義のストラテジは、次の場所に保存されます。

• Linux OS

$HOME/.Xilinx/Vivado/strategies

• Windows 7

C:\Users\<username>\AppData\Roaming\Xilinx\Vivado\strategies

• Windows XP

C:\Documents and Settings\username\Application Data\Xilinx\Vivado\strategies


図 1-12 : インプリメンテーションオプションの変更





ストラテジの共有

作成したストラテジを複数のユーザーで共有するには、ユーザー定義のストラテジを <InstallDir>/Vivado/<version>/strategies ディレクトリにコピーします。

説明 :

• <InstallDir> : ザイリンクスソフトウェアのインストールディレクトリ

• <version> : リリースバージョン番号

インプリメンテーション run の起動アクティブインプリメンテーション run を実行するには、次のいずれかを実行します。

• Flow Navigator で [Run Implementation] をクリックします。

• [Flow] → [Run Implementation] をクリックします。

• ツールバーの [Run Implementation] ボタンをクリックします。

• [Design Runs] ビューで run を右クリックし、ポップアップメニューから [Launch Runs] をクリックします。

1 つのインプリメンテーション run を実行すると、そのインプリメンテーションに別のプロセスが生成されます。

ヒント : [Design Runs] ビューからは、アクティブでない run を選択して実行できます。 [Design Runs] ビューで複数のrun を選択すると、複数の run を同時に実行できます。

1. 複数の run を選択するには、 Shift キーまたは Ctrl キーを押しながらクリックします。

注記 : [Design Runs] ビューで複数 run を選択する際、合成 run とインプリメンテーション run の両方を選択できます。 Vivado IDE では、 run の依存性が管理され、 run が正しい順序で実行されます。

2. [Launch Runs] をクリックすると、 [Launch Selected Runs] ダイアログボックスが開きます (図 1-13)。

注記 : [Launch Selected Runs] ダイアログボックスは、 run を右クリックして [Launch Runs] をクリックするか、[Design Runs] ビューのツールバーの [Launch Selected Runs] ボタンをクリックすると開きます。





3. [Launch Directory] を選択します。

デフォルトの実行ディレクトリは、ローカルのプロジェクトディレクトリ構造に含まれます。インプリメンテーション run のファイルは、次のディレクトリに保存されます。

<project_name>/<project_name>.runs/<run_name>

ヒント : プロジェクトファイルには絶対パスが記述されるので、プロジェクトディレクトリ外の場所を指定すると、プロジェクトを移動しにくくなります。

4. 次のオプションを設定します。

° [Launch runs on local host] : ローカルマシンで run を実行します。

° [Number of jobs] : 複数の run を同時実行する際に使用するローカルプロセッサの数を指定します。

° [Launch runs on remote hosts] (Linux のみ) : ジョブを起動するのにリモートホストを使用します。

° [Configure Hosts] : リモートホストを設定します。詳細は、付録 A 「リモートホストおよび LSF の使用」を参照してください。

° [Launch runs using LSF] (Linux のみ) : LSF (Load Sharing Facility) の bsub コマンドを使用してジョブを起動します。 bsub コマンドオプションを設定して LSF 接続をテストするには、 [Configure LSF] ボタンをクリックします。

ヒント : LSF は、クラスターの複数の計算サーバー間でバッチジョブを投入、スケジュール、実行、監視、ワークロード制御するためのサブシステムです。

° [Generate scripts only] : run ディレクトリおよび run スクリプトをエクスポートおよび作成しますが、 run は起動しません。スクリプトは、 Vivado IDE ツールの環境外で後で実行できます。

° [Do not launch now] : 新しい run を保存しますが、 run スクリプトは実行または作成しません。


図 1-13 : [Launch Selected Runs] ダイアログボックス





プロセスのバックグラウンドへの移動Vivado IDE で合成またはインプリメンテーションを実行するプロセスが生成されると、まず実行の準備としてデザインファイルと制約ファイルが読み込まれます。 [Starting Run] ダイアログボックス (図 1-14) が表示され、このプロセスをバックグラウンドに移動するオプションが示されます。

このプロセスをバックグラウンドに移動すると、バックグラウンドタスクを実行させたまま、 Vivado IDE でレポートを表示したり、デザインファイルを開いたりといった別の操作を実行できます。この間、前の run の結果を確認したり、レポートを表示したりして、時間を効率的に活用できます。

注意 : このプロセスをバックグランドに移動しても、[Tcl Console] はブロックされるので、Tcl コマンドを使用したり、開いている別のデザインに切り替えるなどの Tcl コマンドを必要とするタスクは実行できません。

インプリメンテーションの段階ごとの実行Vivado インプリメンテーションは、次のプロセスで構成されます。

• ロジック適化

• 配置

• 配線

Vivado ツールでは、インプリメンテーションを 1 つのプロセスとしてではなく、1 つずつ順に実行することも可能です。

インプリメンテーションの段階ごとに実行する方法

インプリメンテーションの段階ごとに実行するには、次の手順に従います。


2. [Launch Next Step: <Step>] または [Launch Step To] をクリックします。

<Step> に有効な値は、 run 設定でイネーブルになっているプロセスによって異なります。インプリメンテーション run で有効な手順は、次のとおりです。

° opt_design (デザインの適化) : ザイリンクス FPGA デバイスにフィットするよう論理デザインを適化します。

° power_opt_design (デザインの消費電力適化) :インプリメント済み FPGA デバイスの消費電力を削減するため、デザインエレメントを適化します。

° place_design (デザインの配置) :デザインをターゲットザイリンクスデバイスに配置します。

° 配置後の power_opt_design (デザインの消費電力適化) :配置後に消費電力を削減するするよう追加の適化を実行します。


図 1-14 : [Starting Run] ダイアログボックス





° 配置後の phys_opt_design (デザインの物理適化) :デザインの負のスラックパスに対してタイミングドリブンの適化を実行します。

° route_design (デザインの配線) : デザインをターゲットザイリンクスデバイスに配線します。

° 配線後の phys_opt_design (デザインの物理適化) :配線後の実際の遅延を使用して、ロジック、配置、および配線を適化します。

° write_bitstream (ビットストリームの生成) :ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。ビットストリーム生成は、厳密にはインプリメンテーション run の一部ではありませんが、次の段階として実行可能です。

3. [Launch Next Step: <Step>] または [Launch Step To] を繰り返し、インプリメンテーションの段階を進めていきます。

インプリメンテーション段階の間で必要に応じてレポート生成または解析を実行し、デザインオプションの結果を確認できます。

4. 完了している段階を前の段階に戻すには、 [Design Runs] ビューで run を右クリックして [Reset to Previous Step:<Step>] をクリックします。

選択した run を直前の段階にリセットするには、 [Reset to Previous Step] を使用します。このコマンドを使用すると、次が可能になります。

° run を元に戻します。

° 必要な変更を加えます。

° 再び段階を進め、 run をインクリメンタルに完了します。





インプリメンテーション run の監視インプリメンテーション run は、次のように監視できます。

• コンパイル情報を読む

• [Messages] ビューで警告およびエラーを確認

• プロジェクトサマリを表示

• [Design Runs] ビューを開く

合成 run およびインプリメンテーション run のステータスは、 [Log] ビューで確認します。

run ステータス表示

進行中の run のステータスは、 2 つの方法で表示されます。これらのステータス表示には、 run が進行中であることが示されるほか、ここから必要に応じてキャンセルできます。

• Vivado IDE の右上に、プロジェクトステータスバーに表示される run ステータスインジケーターがあります (図 1-15)。run が進行中であることが動くバーで示されます。[Cancel] ボタンをクリックすると、run を停止できます。

• run ステータスインジケーターは、 [Design Runs] ビューにも表示されます (図 1-16)。 run 名の横に、 run が進行中であることを示す円形の矢印が表示されます (図 1-16 の赤丸)。 run を右クリックしてポップアップメニューから[Reset Run] をクリックすると、 run をキャンセルできます。

run のキャンセル/リセット

進行中の run を [Cancel] ボタンまたは [Reset Run] コマンドでキャンセルすると、キャンセルした run 用に作成されたrun ファイルをすべて削除するかどうか確認するメッセージが表示されます (図 1-17)。


図 1-15 : run ステータスインジケーター


図 1-16 : インプリメンテーション run のステータス表示


図 1-17 : [Cancel Implementation] ダイアログボックス





[Delete Generated Files] をオンにすると、ローカルのプロジェクトディレクトリから run データが削除されます。

推奨 : キャンセルした run で作成されたデータはすべて削除して、今後の run で競合が発生しないようにすることをお勧めします。

[Log] ビューのログ情報の表示

run を実行すると、 [Log] ビューが開き、標準出力メッセージが表示されます。 [Log] ビューには、 place_design やroute_design などの各インプリメンテーションプロセスの進行状況も表示されます。

異なるメッセージがどこから表示されているかを確認し、インプリメンテーション run のデバッグに役立てることができます。

出力の停止

[Log] ビューで [Pause output] ボタンをクリックすると、出力を停止できます。出力を停止すると、インプリメンテーションの実行中にログ情報を読むことができます。

プロジェクトステータスの表示

Vivado IDE では、プロジェクトステータスと次の手順が複数の方法で示されます。プロジェクトステータスには、主なデザインタスクの結果のみがレポートされます。

プロジェクトステータスは [Project Summary] ビューとステータスバーに表示され、プロジェクトを開いたとき、デザインフローコマンドを実行中に、プロジェクトのステータスをすばやく判断できます。次のステータスが示されます。

• RTL エラボレーション

• 合成

• インプリメンテーション

• ビットストリーム生成

プロジェクトステータスバー

プロジェクトステータスは、 Vivado IDE の右上のプロジェクトステータスバーに表示されます。

合成、インプリメント、ビットストリームの生成を実行すると、プロジェクトステータスバーにその結果が示されます。プロセスでエラーが発生した場合は、赤色の文字で表示されます。


図 1-18 : [Log] ビュー





Out-of-Date ステータス

合成またはインプリメンテーションを完了した状態でソースファイルまたはデザイン制約を変更すると、プロジェクトステータスが図 1-19 に示すように「Out-of-Date」と表示されます。

これは、プロジェクトが新でなく、更新が必要であることを示します。デザインのどの部分が新ではないのかを確認するには、 [more info] リンクをクリックします。インプリメンテーションのみの再実行が必要な場合や、合成およびインプリメンテーションの両方を再実行する必要がある場合があります。

run のステータスを強制的に最新の状態に設定

[Force-up-to-date] リンクをクリックすると、インプリメンテーション run または合成 run のステータスを強制的に新の状態にすることができます。この機能は、デザインまたは制約を変更したが、現在の run の結果を解析する場合などに使用します。

ヒント : [Force-up-to-date] コマンドは、[Design Runs] ビューで新でない run を右クリックしたときに表示されるポップアップメニューにもあります。

詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] を参照してください。


図 1-19 : インプリメンテーションが最新でない





インクリメンタルコンパイルインクリメンタルコンパイルは、完成に近づいており、小さな変更が必要なデザインに適したアドバンスフローです。少しの変更を加えて再合成する場合にこのフローを使用すると、次のような利点があります。

• 配置配線の実行時間が短縮されます。

• 基準デザインからの配置配線が再利用され、 QoR (結果の品質) の予測性が保持されます。このフローは、変更されたデザインと基準デザインが 95% 以上類似している場合にも効果的です。

図 1-20 に、インクリメンタルコンパイルデザインフローを示します。


図 1-20 : インクリメンタルコンパイルデザインフロー





インクリメンタルコンパイルフローのデザイン

インクリメンタルコンパイルフロー (図 1-20) では、基準デザインと現在のデザインの 2 つのデザインを使用します。

基準デザイン

基準デザインは、通常はデザインの合成、配置、配線が完了した以前のバージョンです。

配置、配線、またはその両方がどれだけ含まれたチェックポイントでも使用可能です。基準デザインには、タイミングクロージャを達成するためにコード変更、フロアプラン、制約変更した際のデザインの実行結果であるデザインチェックポイント (DCP) を使用できます。

現在のデザインを読み込んだら、 read_checkpoint -incremental <dcp> コマンドを使用して基準デザインチェックポイントを読み込みます。 -incremental オプションを使用して基準デザインチェックポイントを読み込むと、次の配置配線でインクリメンタルコンパイルデザインフローがイネーブルになります。詳細は、 44 ページの「基準デザインと現在のデザインの類似性の確認」を参照してください。

現在のデザイン

現在のデザインは、基準デザインに少しだけ変更を加えたものです。次のような変更が含まれます。

• RTL の変更

• ネットリストの変更

• RTL の変更とネットリストの変更の両方

インクリメンタル配置配線の実行

変更された現在のデザインを初にメモリに読み込み、その後基準デザインチェックポイントを読み込みます。

インクリメンタルコンパイルプロセスの重要な要素は、インクリメンタル配置配線です。基準デザインチェックポイントは、ネットリスト、制約、配置配線を含む物理データで構成されます。

• 現在のデザインのネットリストは基準デザインと比較され、一致するセルおよびネットが検出されます。

• 基準デザインチェックポイントからの配置は、現在のデザインの一致セルを配置するために再利用されます。

• 基準デザインチェックポイントからの配線は、一致ネットを配線するためにロードピンごとに再利用されます。ネットリストの変更によりロードピンがなくなった場合、その配線は破棄されるので、配線の一部のみが再利用されることもあります。

インクリメンタル配置およびインクリメンタル配線では、ネットリストの配線性が向上する場合、または基準デザインと同等のパフォーマンスが保持される場合、セルの配置およびネットの配線が再利用される代わりに破棄されることがあります。

基準デザインと現在のデザインの間で一致しないデザインオブジェクトは、インクリメンタル配置が完了した後に配置され、既存の配線が再利用された後に配線されます。

複数のファンアウトがあるネット

Vivado 配線では、複数のファンアウトがあるネットに対しては詳細な一致比較が実行され、各配線セグメントを適切に再利用または廃棄できます。





配置配線の効率的な再利用

基準デザインからの配置配線が効果的に再利用できるかどうかは、 2 つのデザインの差異によります。小さな変更によって、デザインが大幅に変わってしまう場合もあります。

RTL の小さな変更による影響

合成はネットリスト名ができるだけ変更されないように実行されますが、次のような RTL の小さな変更によって合成済みネットリストが大幅に変わってしまう場合があります。

• HDL コードの定数値を変更する。

• 推論されるメモリのサイズを大きくする。

• 内部バスの幅を広くする。

制約および合成オプションの変更による影響

同様に、次のような制約および合成オプションの変更が、インクリメンタル配置配線の実行時間に大きく影響することがあります。

• タイミング制約の変更および再合成

• 論理階層の保持または解除

• レジスタのリタイミングのイネーブル

phys_opt_design の使用

基準チェックポイントを phys_opt_design を使用して作成した場合は、インクリメンタル run でも phys_opt_designを使用してください。このようにすると、基準デザインで phys_opt_design により実行された配置の適化がキャプチャされ、関連の配線が再利用されます。 phys_opt_design には place_design および route_design のようにインクリメンタルモードはありませんが、変更されたデザインで基準デザインと同様のロジック変換が実行されます。

配線後の基準デザインと現在のデザインのネットリスト類似性を記録します。ネットリストの一致パーセントが低い場合、 phys_opt_design オプションでロジック適化で多量の適化が実行されたためである可能性があります。そのため、配線後のチェックポイントよりも配置後のチェックポイントの方が基準デザインとして適していることもあります。

基準デザインと現在のデザインの類似性の確認

report_incremental_reuse コマンドを使用すると、基準デザインチェックポイントと現在のデザインの類似性をレポートできます。このコマンドは、基準デザインチェックポイントからのネットリストをメモリ内の現在のデザインと比較し、セル、ネット、ポートの一致量をパーセントでレポートします。

デザイン間の差異が少ないほど、基準デザインからの配置配線の再利用が効率的に実行されます。基準デザインと現在のデザインの一致パーセントが高い方が、配置配線が再利用される確率が高くなります。

インクリメンタル再利用サマリ

再利用リポートには、Netlist Similarity Summary (ネットリストの類似性サマリ ) と Implementation Reuse Summary (インプリメンテーション再利用サマリ ) の 2 つのセクションがあります。 Netlist Similarity Summary は、現在のデザインに含まれる論理オブジェクトで基準デザインのオブジェクトに一致するものの数を示します。これは、デザインに変更を加えてアップデートした後に、論理的にどれだけ類似しているかを示します。

Implementation Reuse Summary は、一致している論理オブジェクトの物理データの再利用を示し、セル、ポート、ネットの再利用率、基準デザインからの配置および配線情報が含まれます。再利用されなかったセルに対しては、ネットリストに含まれる新規セル (基準デザインに存在しないセル) およびデザインの変更により配置が不正になったため配置が破棄されたセルが示されます。ネットに対しては、完全に再利用された配線、一部が再利用された配線、新規ネット (基準デザインに存在しないネット ) が示されます。





次に、再利用レポートの例を示します。

1. Netlist Similarity Summary-----------------------------

+---------------+-------+-------+------------+| Type | Count | Total | Percentage |+---------------+-------+-------+------------+| Matched Cells | 3609 | 3618 | 99.75 || Matched Ports | 71 | 71 | 100.00 || Matched Nets | 6154 | 6171 | 99.72 |+---------------+-------+-------+------------+

2. Implementation Reuse Summary-------------------------------

+------------------------------------------------------+-------+-------+------------+| Type | Count | Total | Percentage |+------------------------------------------------------+-------+-------+------------+| Reused Cells | 3607 | 3618 | 99.69 || Reused Ports | 71 | 71 | 100.00 || Reused Nets | 5135 | 5155 | 99.61 || | | | || Non-Reused Cells | 11 | 3618 | 0.30 || New | 9 | 3618 | 0.24 || Discarded illegal placement due to netlist changes | 2 | 3618 | 0.05 || Fully Reused nets | 4776 | 5155 | 92.64 || Partially reused nets | 359 | 5155 | 6.96 || Non-Reused nets | 20 | 5155 | 0.38 |+------------------------------------------------------+-------+-------+------------+

通常、一致パーセントが高いほど、配置配線が多く再利用され、配置配線の実行が高速になります。

インクリメンタル配置配線メトリック

基準デザインと現在のデザインの 95% のセルが一致している場合、通常の配置配線と比較して実行時間が半分になり、インクリメンタル配置配線の使用により QoR の予測性を保持できます。

基準デザインと現在のデザインの間の一致パーセントが低くなると実行時間の短縮度および QoR の予測性も低くなります。

85% 未満になると、インクリメンタル配置配線を使用する利点はそれほどなくなるか、まったくなくなる可能性があります。

セルの再利用率が低く、インクリメンタルコンパイルフローの使用による実行時間および QoR 予測性の利点が得られない場合は、デフォルトの配置配線が実行されます。この場合、次のようなクリティカル警告が表示されます。

CRITICAL WARNING: [Vivado_Tcl 4-208] Running default Place and Route flow, as design objects reuse percentage is too low.Clearing placement and routing information, reused from last 'read_checkpoint -incremental' command.





実行時間の短縮に影響する要素

次の要素が実行時間の短縮に影響します。

• タイミングクリティカルエリアの変更量。クリティカルパスの配置配線を再利用できない場合、タイミングを保持するのにエフォートがより必要となります。また、デザインの小さな変更により基準デザインに存在しないタイミング問題が発生した場合、エフォートがさらに必要となって実行時間が長くなる可能性があり、デザインのタイミングが満たされないこともあります。

• 配置配線の初期化時間。配置配線時間が短い場合、Vivado 配置配線の初期化のオーバーヘッドによりインクリメンタル配置配線プロセスの効果が相殺されてしまう可能性があります。実行時間が長いデザインでは、実行時間占める初期化時間の割合は小さくなります。

インクリメンタルコンパイルの使用

プロジェクトモードと非プロジェクトモードのどちらでも、read_checkpoint -incremental <dcp_file> コマンド (<dcp_file> は基準デザインチェックポイントのパスとファイル名) を使用して基準デザインチェックポイントを読み込むと、インクリメンタル配置配線モードになります。 -incremental オプションを使用して基準デザインチェックポイントを読み込むと、次の配置配線でインクリメンタルコンパイルデザインフローがイネーブルになります。非プロジェクトモードでは、 read_checkpoint -incremental は opt_design の後および place_design の前に実行します。

非プロジェクトモードでのインクリメンタルコンパイルの使用

非プロジェクトモードで基準デザインとして使用するデザインチェックポイントファイル (DCP) を指定してインクリメンタル配置を実行するには、次の手順に従います。

1. 現在のデザインを読み込みます。

2. opt_design を実行します。

3. read_checkpoint -incremental <dcp_file> を実行します。

4. place_design を実行します。

5. phys_opt_design を実行します (オプション)。基準デザインで phys_opt_design が使用されている場合に実行します。

6. route_design を実行します。

link_design; # to load the current designopt_designread_checkpoint -incremental <dcp_file>place_design phys_opt_design; #if used in reference designroute_design

インクリメンタル配置は、基準デザインのデザインオブジェクトと現在のデザインのデザインオブジェクトを比較する Vivado ツールの機能を利用します。ただし、次の opt_design コマンドオプションを使用した場合、基準デザインと現在のデザインの間でセル名の一致が低くなり、配置配線データの一致も低くなります。

• -resynth_area

• -resynth_seq_area

• -directive ExploreArea

• -directive ExploreAreaSequential

推奨 : インクリメンタルコンパイルフローを実行する際は、上記 4 つの opt_design コマンドオプションを使用しないようにしてください。





プロジェクトモードでのインクリメンタルコンパイルの使用

プロジェクトモードでは、 [Design Runs] ビューでインクリメンタルコンパイルオプションを設定できます。

インクリメンタルコンパイルモードを設定するには、次の手順に従います。


2. [Set Incremental Compile] をクリックします。

3. [Set Incremental Compile] ダイアログボックスで、基準デザインチェックポイントを選択します。

run でインクリメンタルコンパイルモードがイネーブルになります。

重要 : デザイン run からチェックポイントを選択した場合、その run がリセットされると削除されます。デザイン runからチェックポイントを選択する場合は、基準チェックポイントとして選択する前に、別のディレクトリにコピーしてください。

図 1-21 に、 [Project Settings] ダイアログボックスの [Implementation] ページで [Incremental compile] を設定している例を示します。





インクリメンタル配置配置配線が完了したら、 Vivado ツールで生成されたメッセージを確認できます。

注記 : インクリメンタルコンパイルフローを実行している場合、インプリメンテーションコマンドの -directiveオプションおよびストラテジは、目的が異なるため無視されます。

現在の run でインクリメンタルコンパイルをディスエーブルにするには、次の手順に従います。

1. [Set Incremental Compile] ダイアログボックスで [Use checkpoint] フィールドを空にするか、または [ImplementationRun Properties] ビューの [Properties] タブで [INCREMENTAL_CHECKPOINT] フィールドを空にします。

2. Tcl コンソールで次のコマンドを実行します。

reset_property INCREMENTAL_CHECKPOINT [current_run]


図 1-21 : インクリメンタルコンパイルの設定





余った配線セグメント

現在のデザインから削除されていたり、配置時に移動されているセルのため、基準デザインからの配線セグメントに余るものが出てしまうことがあります。 Vivado IDE で実行している場合、問題が発生する可能性のあるネットが見られることがありますが、これらの余った配線セグメントや不適切に接続された配線セグメントは、Vivado 配線のインクリメンタル配線時にクリーンアップされます。

配置中に、次のような情報メッセージが表示されます。

INFO: [Place 46-2] During incremental compilation, routing data from the original checkpoint is applied during place_design. As a result, dangling route segments and route conflicts may appear in the post place_design implementation due to changes between the original and incremental netlists. These routes can be ignored as they will be subsequently resolved by route_design. This issue will be cleaned up automatically in place_design in a future software release.

Synplify コンパイルポイントの使用

インクリメンタルコンパイルフローは、基準デザインと変更されたデザインがほとんど同じである (理想的にはセルが 95% 以上一致している ) 場合にも効果的です。 Synplify コンパイルポイントなどの合成フローは、 RTL の変更によるネットリストの変更量を小限に抑えます。コンパイルポイントは論理的な境界で、この境界を越える適化は実行されません。これがデザインパフォーマンスに影響する可能性はありますが、インクリメンタルコンパイルと共に使用すると、より実行時間が短縮され、予測性が向上します。

Synplify では、自動と手動の 2 つのコンパイルポイントフローを使用できます。自動コンパイルポイントモードでは、既存の階層および使用率予測に基づいて、合成によりコンパイルポイントが自動的に選択されます。これはプッシュボタンモードです。フローをイネーブルにする以外は、ユーザーの操作は必要ありません。このフローをイネーブルにするには、GUI で [Auto Compile Point] チェックボックスをオンにするか、Synplify プロジェクトで次を設定します。

set_option -automatic_compile_point 1

手動コンパイルポイントフローは、柔軟性がありますが、ユーザーがコンパイルポイントを選択する必要があります。デザインをコンパイルした後、SCOPE エディターの [Compile Points] タブを使用するか、define_compile_point設定を使用します。コンパイルポイントフローの詳細は、 Synplify のオンラインヘルプを参照してください。

インクリメンタルフローでのチェックポイントの保存

read_checkpoint -incremental で現在のデザインに基準チェックポイントを適用すると、インクリメンタル再利用データがフローを通して保持されます。チェックポイントを保存し、同じ Vivado Design Suite セッションまたは異なる Vivado Design Suite セッションに読み込み直すと、インクリメンタルコンパイルモードが保持されます。次のようなコマンドシーケンスを実行するとします。

opt_design; # optimize the current designread_checkpoint -incremental reference.dcp; # apply reference data to current designwrite_checkpoint incr.dcp; # save a snapshot of the current designread_checkpoint incr.dcpplace_designwrite_checkpoint top_placed.dcp; # save incremental placement resultroute_design

read_checkpoint incr.dcp を実行すると、Vivado ツールでインクリメンタルデータが存在することが検出され、その後の place_design および route_design コマンドはインクリメンタルモードで実行されます。





次のコマンドシーケンスでは、Vivado Design Suite を終了して再起動しても、route_design コマンドは基準チェックポイント reference.dcp を使用してインクリメントモードで実行されます。

read_checkpoint top_placed.dcpphys_opt_designroute_design

制約の競合

変更したデザインの制約が基準チェックポイントの物理データと競合することがあります。競合が発生した場合、変更したデザインの制約が優先されます。この例を次に示します。

制約競合の例

セル cell_A を固定ロケーション RAMB36_X0Y0 に割り当てる制約があるとします。基準チェックポイントreference.dcp では、 cell_A は RAMB36_X0Y1 に配置されており、 RAMB36_X0Y0 には別のセル cell_B が配置されています。

read_checkpoint -incremental reference.dcp を実行すると、cell_A が RAMB36_X0Y0 に配置され、cell_Bの配置は解除されます。セル cell_B は、インクリメンタル配置で配置されます。

重要 : インクリメンタルコンパイルを使用する場合、 Pblock は使用できません。 Pblock を使用すると、処理不可能な配置の競合が発生する可能性があります。

インクリメンタルコンパイルのアドバンス制御

read_checkpoint コマンドには、基準チェックポイントからのセル配置の再利用を制御する 3 つのオプションがあります。これらのオプションは read_checkpoint -incremental オプションと共に使用する必要があります。

-only_reuse オプション

-only_reuse <cell objects>

-only_reuse オプションは、セル配置の再利用を指定のセルのみに制限します。下位セルまたは階層セルを指定できます。次に例を示します。

• routed.dcp の上位インスタンス mem_ctrl_inst からの配置のみを再利用する場合 :

read_checkpoint -incremental routed.dcp -only_reuse [get_cells mem_ctrl_inst]

• routed.dcp 内のブロック RAM の配置のみを再利用する場合 :

read_checkpoint -incremental routed.dcp -only_reuse [get_cells -hier -filter { PRIMITIVE_TYPE =~ BMEM.bram.* } ]





-dont_reuse オプション

-dont_reuse <cell objects>

-dont_reuse オプションは、指定のセル以外のセルすべての配置を再利用します。下位セルまたは階層セルを指定できます。次に例を示します。

• routed.dcp に含まれる上位インスタンス mem_ctrl_inst 以外のすべてのセルの配置を再利用する場合 :

read_checkpoint -incremental routed.dcp -dont_reuse [get_cells mem_ctrl_inst]

• routed.dcp に含まれるブロック RAM 以外のすべての配置を再利用する場合 :

read_checkpoint -incremental routed.dcp -dont_reuse [get_cells -hier -filter { PRIMITIVE_TYPE =~ BMEM.bram.* } ]

-fix_reuse オプション

-fix_reuse オプションは、-only_reuse または -dont_reuse オプションと共に使用し、再利用されたセルの配置を固定します。次に例を示します。

• routed.dcp 内のブロック RAM の配置のみを再利用し、再利用されたセルの配置を固定する場合 :

read_checkpoint -incremental routed.dcp -only_reuse [get_cells -hier -filter { PRIMITIVE_TYPE =~ BMEM.bram.* } ] -fix_reuse

通常、再利用された配置および配線は変更可能です。変更されないようにする場合に、 -fix_reuse を指定します。

RAM セルのロケーションが適用された後、セルの IS_LOC_FIXED プロパティが TRUE に設定されます。

インクリメンタルコンパイル後のアドバンス解析

再利用のアドバンス解析用に、レポート、タイミングラベル、およびオブジェクトプロパティを使用できます。

再利用レポート

report_incremental_reuse コマンドには、詳細な解析用に report_utilization と同様のオプションがあります。

-cells <list of cells>

-cells オプションを使用すると、デザイン全体の再利用ではなく、指定のセルのみの再利用がレポートされます。

例 : ブロック RAM のみの再利用をレポートする場合

report_incremental_reuse -cells [get_cells -hierarchical -filter { PRIMITIVE_TYPE =~ BMEM.bram.* } ]





インクリメンタル再利用サマリ

1. Netlist Similarity Summary-----------------------------+---------------+-------+-------+------------+| Type | Count | Total | Percentage |+---------------+-------+-------+------------+| Matched Cells | 16 | 16 | 100.00 || Matched Ports | 71 | 71 | 100.00 || Matched Nets | 6154 | 6171 | 99.72 |+---------------+-------+-------+------------+

2. Implementation Reuse Summary-------------------------------

+------------------+-------+-------+------------+| Type | Count | Total | Percentage |+------------------+-------+-------+------------+| Reused Cells | 16 | 16 | 100.00 || Non-Reused Cells | 0 | 16 | 0.00 |+------------------+-------+-------+------------+

-hierarchical オプションを使用すると、各階層レベルでのセルの再利用が表示されます。次に、 report_incremental_reuse -hierarchical の例を示します。

注記 : このレポート例は、ページに収めるため、切り詰められています。

階層インプリメンテーション再利用サマリ

1. Summary----------

+--------------------------+------------------+--------+-----+---------------------+| Instance | Module | Reused | New | Discarded(Illegal)* | ...+--------------------------+------------------+--------+-----+---------------------+| bft | (top) | 3607 | 9 | 2 || (bft) | (top) | 210 | 9 | 2 || arnd1 | round_1 | 256 | 0 | 0 || transformLoop[0].ct | coreTransform_43 | 32 | 0 | 0 || transformLoop[1].ct | coreTransform_38 | 32 | 0 | 0 || transformLoop[2].ct | coreTransform_42 | 32 | 0 | 0 || transformLoop[3].ct | coreTransform_40 | 32 | 0 | 0 || transformLoop[4].ct | coreTransform_45 | 32 | 0 | 0 |

...

+--------------------------+------------------+--------+-----+---------------------+* Discarded illegal placement due to netlist changes** Discarded to improve timing*** Discarded placement by user**** Discarded due to its control set source is unguided***** Discarded due to its connectivity has Loc Fixed Insts

上位階層から各セルの再利用ステータスがレポートされ、その後各階層レベルがレポートされます。初のサブモジュールに含まれる下位階層に到達すると、次のサブモジュールに進みます。





この例では、上位セルは bft で、再利用されたセルは合計 3607 個、新規セルは 9 個あります。 bft がかっこで囲まれた行は、 bft に含まれ、そのサブモジュールに含まれていないセルの再利用ステータスを示します。 3607 個のセルのうち、 210 個が bft に含まれ、その他はサブモジュールに含まれます。新規セル 9 個は、すべて bft 内にあります。 bft 内では、サブモジュール arnd1 で 256 個のセルが再利用されていますが、 arnd1 自体には再利用されたセルは含まれず、サブモジュール transformLoop[0].ct、 transformLoop[1].ct などのみに含まれます。

各レベルでのセルの再利用ステータスを示す 5 つの列がありますが、上記の例には [Discarded(Illegal)] のみが示されています。これらの列に対しては注記があり、配置が破棄された理由が示されます。

* Discarded illegal placement due to netlist changes (ネットリスト変更により不正になった配置を破棄)

** Discarded to improve timing (タイミングを向上するため破棄)

*** Discarded placement by user (ユーザーの指定により配置を破棄)

**** Discarded due to its control set source is unguided (制御セットソースがガイドされてないため破棄)

***** Discarded due to its connectivity has Loc Fixed Insts (接続にロケーションが固定されたインスタンスがあるため破棄)

-hierarchical_depth オプションを使用すると、レポートするサブモジュールのレベル数を制限できます。次に、先ほどの例で -hierarchical_depth を 1 に設定した場合に得られるレポートの例を示します。

report_incremental_reuse -hierarchical -hierarchical_depth 1

1. Summary----------

+----------+--------+--------+-----+---------------------+| Instance | Module | Reused | New | Discarded(Illegal)* | ...+----------+--------+--------+-----+---------------------+| bft | (top) | 3607 | 9 | 2 |+----------+--------+--------+-----+---------------------+

この場合、レポートされるのは上位 bft のみになります。 -hierarchical_depth を 2 に設定すると、 bft とbft に含まれる階層のみがレポートされ、それより下の階層セルはレポートされません。

階層インプリメンテーション再利用サマリ

1.Summary----------

+--------------------------------+---------------+--------+-----+---------------------+| Instance | Module | Reused | New | Discarded(Illegal)* |+--------------------------------+---------------+--------+-----+---------------------+| bft | (top) | 3607 | 9 | 2 || (bft) | (top) | 210 | 9 | 2 || arnd1 | round_1 | 256 | 0 | 0 || arnd2 | round_2 | 256 | 0 | 0 || arnd3 | round_3 | 256 | 0 | 0 || arnd4 | round_4 | 256 | 0 | 0 || egressLoop[0].egressFifo | FifoBuffer_6 | 173 | 0 | 0 |...





タイミングレポート

インクリメンタル配置配線が完了したら、タイミングとセルおよびネットの再利用に関する詳細を解析できます。タイミングレポートのオブジェクトに、物理データがどのように再利用されたかが示されます。これにより、デザインのアップデートがクリティカルパスに影響しているかどうかを判断できます。

タイミングレポートにインクリメンタルフローの詳細を表示するには、 report_timing -label_reused オプションを使用します。このオプションを使用すると、入力ピンおよび出力ピンに再利用ラベルが表示され、ピンのセルおよびネットに再利用された物理データの量が示されます。次に、タイミングレポートに含まれるラベルの説明を示します。

• (R) : セル配置とネット配線の両方が再利用されています。

• (NR) : セル配置とピン配線のどちらも再利用されていません。

• (PNR) : セル配置は再利用されていますが、ピンへの配線は再利用されていません。

• (N) :ピン、セル、またはネットは新しいデザインオブジェクトで、基準デザインには含まれません。

次に例を示します。

------------------------------------------------------- -------------------(NR)SLICE_X46Y42 FDRE (Prop_fdre_C_Q) 0.259 -1.862 r fftI/fifoSel_reg[5]/Q net (fo=8, estimated) 0.479 -1.383 fftI/n_fifoSel_reg[5](R)SLICE_X46Y43 r fftI/wbDOut_reg[31]i5/I1(R)SLICE_X46Y43 LUT4 (Prop_lut4_I1_O) 0.043 -1.340 r fftI/wbDOut_reg[31]i5/O net (fo=32, routed) 1.325 -0.014 fftI/wbDOut_reg[31]i5(R)SLICE_X44Y39 r fftI/wbcI/wbDOut_reg[0]i1/S(PNR)SLICE_X44Y39 MUXF7 (Prop_muxf7_S_O) 0.154 0.140 r fftI/wbcI/wbDOut_reg[0]i1/O net (fo=1, routed) 0.000 0.140 fftI/wbcI/wbDOut_reg[0]i1(PNR)SLICE_X44Y39 r fftI/wbDout_reg[0]/D------------------------------------------------------- -------------------

オブジェクトプロパティ

read_checkpoint -incremental コマンドを使用すると次の 2 つのセルプロパティが設定され、スクリプトまたは Tcl コマンドを使用してインクリメンタルフロー結果を解析する際に有益です。

• IS_REUSED : セル、ポート、ネット、およびピンオブジェクトのブール値プロパティで、次のインクリメンタルデータが再利用された場合に TRUE に設定されます。

° セル配置

° ポートのパッケージピン割り当て

° ネットの配線部分

° ピンへの配線

• REUSE_STATUS : セルおよびネットの文字列プロパティで、インクリメンタル配置配線後の再利用ステータスを示します。

セルに可能な値は次のとおりです。

° New (新規)

° Reused (再利用)

° Discarded placement to improve timing (タイミングを向上するため配置を破棄)

° Discarded illegal placement due to netlist changes (ネットリストの変更による不正な配置を破棄)





ネットに可能な値は次のとおりです。

• REUSED

• NON_REUSED

• PARTIALLY_REUSED

インプリメンテーション完了後の次の操作プロジェクトモードおよび非プロジェクトモードのどちらでも、インプリメンテーションが完了した後の操作は、インプリメンテーションの結果によります。

• デザインが完全に配置配線されたか、解決が必要な問題があるか。

• タイミング制約およびデザイン要件が満たされたか、デザインを完了するのに変更が必要か。

• ザイリンクスパーツ用のビットストリームを生成できる状態であるか。

インプリメンテーション後に推奨される手順

インプリメンテーション後は、次の手順を実行することをお勧めします。

1. インプリメンテーションメッセージを確認します。

2. インプリメンテーションレポートを表示し、次の事項を確認します。

° タイミング制約が満たされている (report_timing_summary)。

° リソース使用率が予測どおりである (report_utilization)。

° 消費電力が予測どおりである (report_power)。

3. ビットストリームファイルを生成します。

ビットストリームファイルの生成には、デザインがハードウェアのルールに違反していないことを確認する終DRC も含まれます。

4. 満たされていないデザイン要件がある場合は、次を実行します。

a. プロジェクトモードでは、インプリメント済みデザインを開いて解析します。

b. 非プロジェクトモードでは、インプリメンテーション後のデザインチェックポイントを開きます。

インプリメント済みデザインの解析の詳細は、『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906) [参照 10] を参照してください。

非プロジェクトモードでのインプリメンテーション後の次の操作

非プロジェクトモードでは、デザインセッションで生成されたメッセージは Vivado ログファイル (vivado.log) に保存されます。このログファイルおよびデザインデータからのレポートを参照し、プロジェクトの状況を正確に評価します。





プロジェクトモードでのインプリメンテーション後の次の操作

プロジェクトモードでは、 Vivado Design Suite で次が実行されます。

• [Messages] ビューにログファイルからのメッセージが表示されます。

• さまざまなレポートが自動的に生成されます。

プロジェクトモードでは、インプリメンテーション run が完了すると、図 1-22 に示すダイアログボックスが表示され、次の操作を選択できます。

[Implementation Completed] ダイアログボックスで、次を実行します。

1. 次のいずれかのオプションをオンにします。

° [Open Implemented Design]ネットリスト、デザイン制約、ターゲットパーツ、配置配線の結果を Vivado IDE に読み込み、必要に応じてデザインを解析できるようにします。

° [Generate Bitstream][Generate Bitstream] ダイアログボックスを開きます。詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参照 12] を参照してください。

° [View Reports]Vivado ツールでインプリメンテーション中に生成されたレポートファイルを選択して表示できる [Reports]ビューを開きます。詳細は、 59 ページの「インプリメンテーションレポートの表示」を参照してください。

2. [OK] をクリックします。


図 1-22 : プロジェクトモード : [Implementation Completed] ダイアログボックス





メッセージの表示

重要 : すべてのメッセージを確認してください。メッセージには、デザインのパフォーマンス、消費電力、エリア、配線を向上するための推奨事項が記載される場合があります。クリティカル警告メッセージにも、解決すべきタイミング制約の問題が表示されることがあります。

非プロジェクトモードでのメッセージの表示

非プロジェクトモードでは、 Vivado ログファイル (vivado.log) で次を確認します。

• 1 つのデザインセッションで使用したコマンド

• コマンドからの結果およびメッセージ

推奨 : Vivado テキストエディターでログファイルを開き、すべてのコマンドの結果を確認してください。有益な情報が得られることがあります。

プロジェクトモードでのメッセージの表示

プロジェクトモードでは、 [Messages] ビューに [Log] ビューの内容がフィルターされたものが表示され、主なメッセージ、警告、およびエラーのみが含まれます (図 1-23)。 [Messages] ビューは機能ごとに分類されており、フィルターを適用するツールバーオプションを使用して、特定のタイプのメッセージのみを表示できます。

プロジェクトモードでメッセージを表示する際は、次の機能を使用できます。

• 横にあるプラス記号 (+) をクリックして展開し、各メッセージを表示します。

• [Messages] ビューの上部にあるチェックボックスのオン/オフを切り替え、エラー、クリティカル警告、警告、情報メッセージを表示/非表示にします。

• [Messages] ビューでリンクを含むメッセージをクリックすると、ソースファイルが開き、該当する行がハイライトされます。

• メッセージを右クリックして [Search for Answer Record] をクリックすると、ザイリンクスウェブサイトでそのメッセージに関連するアンサーデータベースを検索できます。


図 1-23 : [Messages] ビュー





インクリメンタルコンパイルのメッセージ Vivado ツールのログファイルには、インクリメンタルコンパイルからのインクリメンタル配置および配線のサマリ結果がレポートされます。

インクリメンタル配置サマリ

次に、インクリメンタル配置サマリの例を示します。次の情報が含まれます。

• セル配置の再利用の終的な評価

• 実行時間の統計

+-----------------------------------------------------------------+|Incremental Placement Summary |+-----------------------------------------------------------------+| Reused instances | 40336|| Non-reused instances | 1158|| %similarity | 97.21|+-----------------------------------------------------------------+|Incremental Placement Runtime Summary |+-----------------------------------------------------------------+| Initialization time(elapsed secs) | 87.54|| Incremental Placer time(elapsed secs) | 50.42|+-----------------------------------------------------------------+

インクリメンタル配線サマリ

インクリメンタル配線サマリには、デザインのすべてのネットに対する再利用統計が示されます。レポートされるカテゴリは、次のとおりです。

• Fully Reused

ネットの配線全体が基準デザインから再利用されています。

• Partially Reused

ネットの配線の一部が基準デザインから再利用されています。セル、セルの配置、またはその両方が変更されたことにより、一部のセグメントは再配線されています。

• New/Unmatched

現在のデザインに含まれるネットが基準デザインのものと一致していません。

----------------------------------------------------------------------|Incremental Routing Reuse Summary |----------------------------------------------------------------------|Type | Count | Total | Percentage |----------------------------------------------------------------------|Fully reused nets | 13468| 13654| 98.64 ||Partially reused nets | 82| 13654| 0.60 ||Non Reused nets | 104| 13654| 0.76 |----------------------------------------------------------------------





インプリメンテーションレポートの表示Vivado Design Suite では、次の情報を含むさまざまなレポートを生成できます。

• タイミング、タイミングの密集度、タイミングサマリ

• クロック、クロックネットワーク、クロック使用率

• 消費電力、スイッチングアクティビティ、ノイズ解析

レポートを表示すると、次を実行できます。

• スクロールバーを使用してレポートファイルを参照

• [Find] または [Find in Files] ボタンをクリックし、特定テキストを検索

• [Go to the Beginning] をクリックしてファイルの冒頭に移動

• [Go to the End] をクリックしてファイルの後に移動

非プロジェクトモードでのレポート生成

非プロジェクトモードでは、レポートを手動で生成する必要があります

• Tcl コマンドを使用して個々のレポートを生成

• Tcl スクリプトを使用して複数のレポートを生成

Tcl スクリプトの例

次の Tcl スクリプト例では、複数のレポートを生成し、 Reports フォルダーに保存しています。

# Report the control sets sorted by clk, clkEnreport_control_sets -verbose -sort_by {clk clkEn} -file C:/Report/cntrl_sets.rpt# Run Timing Summary Report for post implementation timing report_timing_summary -file C:/Reports/post_route_timing.rpt -name time1# Run Utilization Report for device resource utilization report_utilization -file C:/Reports/post_route_utilization.rpt





Vivado IDE でレポートを開く

これらのレポートは、Vivado IDE で開くことができます。上記の Tcl スクリプト例では、report_timing_summaryコマンドで次のオプションを使用しています。

• -file オプション : レポートをファイルに保存します。

• -name オプション : レポートを Vivado IDE に表示します。

図 1-25 に、 Vivado IDE でレポートを開いた例を示します。

ヒント : レポートを保存するディレクトリは、レポートの生成を実行する前に存在している必要があります。ディレクトリがないとファイルは保存されず、エラーメッセージが表示されます。

インプリメンテーションレポートコマンドに関する情報

Vivado IDE または Tcl コマンドプロンプトで help Tcl コマンドを使用すると、 Tcl レポートコマンドとそのオプションに関する情報を表示できます。

Tcl レポートコマンドおよびそのオプションの詳細な説明は、『Vivado Design Suite Tcl コマンドリファレンスガイド』(UG835) [参照 15] を参照してください。





プロジェクトモードでのレポート生成

プロジェクトモードでは、多くのレポートが自動的に生成されます。これらのレポートは、 [Reports] ビュー (図 1-24)にリストされます。

[Reports] ビューは、合成またはインプリメントコマンドを実行すると自動的に開きます。開いていない場合は、次のいずれかの方法で開くことができます。

• [Project Summary] ビューで [Reports] リンクをクリックします。

• [Window] → [Reports] をクリックします。

ヒント : インプリメンテーション run の tcl.pre および tcl.post オプションを使用すると、プロセスの各段階でカスタムレポートを出力できます。これらのカスタムレポートは [Reports] ビューには表示されませんが、ニーズに合わせてカスタマイズできます。詳細は、「インプリメンテーション run 設定の変更」を参照してください。


図 1-24 : [Reports] ビューの例





[Reports] ビューから表示されるレポートには、 run に関する情報が含まれます。レポートは、 Vivado IDE でテキスト形式で開きます (図 1-25)。

レポートからのクロスプローブ

プロジェクトモードおよび非プロジェクトモードの両方で、レポートと [Device] ビューなどのビューに表示される関連デザインデータのクロスプローブがサポートされています。

• メニューコマンドまたは Tcl コマンドを使用してレポートを生成する必要があります。

• テキスト形式のレポートではクロスプローブはサポートされていません。

たとえば、 [Reports] ビューには [Route Design] の下にテキスト形式のタイミングサマリレポートが含まれています (図 1-24)。

タイミングを解析する際は、クリティカルパスの配置および配線リソースなどのデザインデータを [Device] ビューに表示すると有益です。

Vivado IDE で [Tools] → [Timing] → [Report Timing Summary] をクリックすると、タイミングサマリレポートが再生成され、表示されたレポートからデザインの異なるビューにクロスプローブできます。


図 1-25 : 制御セットレポート





タイミングレポートと [Device] ビューのクロスプローブの例

図 1-26 に、タイミングサマリレポートと [Device] ビューのクロスプローブの例を示します。この非プロジェクトモードの例では、次の手順が実行されています。

• 配線後のデザインチェックポイントを Vivado IDE で開きます。

• report_timing_summary -name を使用して、デザインサマリレポートを生成して開きます。

• [Device] ビューでは [Routing Resources] がオンになっています。

• タイミングサマリレポートでタイミングパスを選択すると、 [Device] ビューでも選択されます (図 1-26)。

レポートの解析およびデザインクロージャのストラテジの詳細は、『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906) [参照 10] を参照してください。


図 1-26 : タイミングレポートと [Device] ビューのクロスプローブ




第 2 章

インプリメンテーションコマンド

インプリメンテーションコマンドについてザイリンクス Vivado® Design Suite には、プロジェクトベースのデザインでインプリメンテーションプロセスを管理し、簡略化する多数の機能が含まれています。インプリメンテーションプロセスを段階ごとに手動で実行する機能も含まれます。

詳細は、第 1 章の 19 ページの「プロジェクトモードでのインプリメンテーションの実行」を参照してください。

非プロジェクトモードでは、Tcl コマンドを使用してインプリメンテーションプロセスの各段階を手動で実行する必要があります。


詳細は、第 1 章の 16 ページの「非プロジェクトモードでのインプリメンテーションの実行」を参照してください。

インプリメンテーションのサブプロセスプロジェクトモードでは、インプリメンテーションコマンドは決まった順序で実行されます。非プロジェクトモードでは、コマンドは同様の順序で実行できますが、繰り返し実行したり、プロジェクトモードとは異なる順序で実行することもできます。

重要 : インプリメンテーションコマンドは、再配線モードで実行されます。

インプリメンテーションコマンドは、再配線モードで実行されます。これは、インプリメンテーションコマンドを非プロジェクトモードで実行すると、デザインがメモリに読み込まれ、タスクが実行され、結果のデザインがメモリに書き込まれることを意味します。これにより、非プロジェクトモードでの実行がより柔軟なものになります。次に例を示します。

• opt_design コマンドの後に opt_design -remap を実行リマップは opt_design コマンドの結果に対して実行されます。

• 一部のセルが配置されたデザインに対して place_design コマンドを実行既存のセル配置が place_design コマンドの開始点として使用されます。

• 一部が配線されたデザインに対して route_design コマンドを実行既存の配線が route_design コマンドの開始点として使用されます。

• セルが配置されていないデザインに対して route_design コマンドを実行セルが配置されている必要があるので、エラーが発生します。




第 2 章 : インプリメンテーションコマンド

• 完全に配置配線されていないデザインに対して opt_design コマンドを実行ロジック適化で論理ネットリストが適化され、配置されていない新しいセルおよび配線されていない新しいネットが作成される場合があります。インプリメンテーションを完了するため配置配線を再実行する必要がある場合があります。

プロジェクトモードおよび非プロジェクトモードのどちらでも、 Vivado インプリメンテーションプロセスはいくつかのサブプロセスで構成されています。

• 合成済みデザインを開くネットリスト、デザイン制約、ターゲットデバイスデータを統合し、インプリメンテーションを実行するデザインをメモリ内に構築します。

• opt_design (デザインの適化)ターゲットのザイリンクスデバイスにフィットしやすいように論理デザインを適化します。

• power_opt_design (デザインの消費電力適化) (オプション)ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを適化します。

• place_design (デザインの配置)デザインをターゲットザイリンクスデバイスに配置します。

• 配置後の power_opt_design (オプション)配置後に消費電力を削減するするよう追加の適化を実行します。

• 配置後の phys_opt_design (デザインの物理適化) (オプション)配置に基づく予測タイミングを使用してロジックおよび配置を適化します。ファンアウトの大きいドライバーの複製も含まれます。

• route_design (デザインの配線)デザインをターゲットザイリンクスデバイスに配線します。

• 配線後の phys_opt_design (デザインの物理適化) (オプション)配線後の実際の遅延を使用して、ロジック、配置、および配線を適化します。

• write_bitstream (ビットストリームの生成)ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。

注記 : ビットストリーム生成は、厳密にはインプリメンテーション run の一部ではありませんが、別の段階として実行可能です。

この章では、インプリメンテーションプロセスの各段階と関連する Tcl コマンドの詳細を説明します。

次の表に、サブプロセスと関連の Tcl コマンドをリストします。


表 2-1 : インプリメンテーションのサブプロセスと関連の Tcl コマンド

サブプロセス Tcl コマンド

合成済みデザインを開く synth_design

open_checkpoint

open_run

link_design

デザインの適化 opt_design

デザインの消費電力適化 power_opt_design

デザインの配置 place_design

デザインの物理適化 phys_opt_design

デザインの配線 route_design

ビットストリームの生成 write_bitstream





合成済みデザインを開くインプリメンテーションでは、まず初に合成済みデザインからのネットリストをメモリに読み込み、デザイン制約を適用します。合成済みのデザインは、使用されるデザインフローによってさまざまな方法で開くことができます。

メモリ内でのデザインの構築

メモリ内にデザインを構築するため、次のプロセスでネットリストファイル、制約ファイル、およびターゲットデバイスの情報が統合されます。

1. ネットリストを統合します。

必要であれば、複数のソースからのネットリストを統合します。デザインには、構造 Verilog、 EDIF、 NGC を含めることができます。

2. 従来のネットリストプリミティブを現在サポートされる Unisim プリミティブに変換します。

ヒント : report_transformed_primitives を使用すると、変換されたセルのリストを生成できます。

3. 配置マクロを作成します。

• Vivado ツールでは、接続または配置制約に基づいてセルの配置マクロが作成され、配置が簡略化されます。

• 配置マクロには、次のものがあります。

° XDC ベースのマクロ

° 相対配置マクロ (RPM)

注記 : RPM は、個別のセルではなくグループとして配置されます。

° 複数の CLB に配置する必要のある長いキャリーチェーン

注記 : キャリーチェーンを構成するプリミティブは 1 つのマクロに含め、縦方向に並ぶ複数のスライスに配置されるようにする必要があります。

Tcl コマンド

合成済みデザインをメモリに読み込むには、デザインのソースファイルおよびデザインのステートに応じて、次の表に示す Tcl コマンドを使用します。

表 2-2 : Tcl コマンドを使用可能なモード

コマンドプロジェクトモード非プロジェクトモード

synth_design X X

open_checkpoint X

open_run X

link_design X X





synth_design

synth_design コマンドは、プロジェクトモードおよび非プロジェクトモード両方で使用できます。このコマンドは、 RTL ソースに対して指定したオプションで Vivado 合成を実行し、合成後にデザインをメモリに読み込みます。

synth_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>] [-include_dirs <args>] [-generic <args>] [-verilog_define <args>] [-flatten_hierarchy <arg>] [-gated_clock_conversion <arg>] [-directive <arg>] [-rtl] [-bufg <arg>] [-no_lc] [-fanout_limit <arg>] [-shreg_min_size <arg>] [-mode <arg>] [-fsm_extraction <arg>] [-keep_equivalent_registers] [-resource_sharing <arg>] [-control_set_opt_threshold <arg>] [-max_bram <arg>] [-max_dsp <arg>] [-quiet] [-verbose]

synth_design のスクリプト例

次のコードは、 Vivado ツールのインストールディレクトリの examples/Vivado_Tutorials ディレクトリに含まれる create_bft_batch.tcl スクリプトからの抜粋です。

# Setup design sources and constraintsread_vhdl -library bftLib [ glob ./Sources/hdl/bftLib/*.vhdl ] read_vhdl ./Sources/hdl/bft.vhdlread_verilog [ glob ./Sources/hdl/*.v ] read_xdc ./Sources/bft_full.xdc

# Run synthesis, report utilization and timing estimates, write design checkpointsynth_design -top bft -part xc7k70tfbg484-2 -flatten rebuilt write_checkpoint -force $outputDir/post_synth

synth_design サンプルスクリプトの使用に関する詳細は、『Vivado Design Suite チュートリアル : デザインフローの概要』 (UG888) [参照 17] および『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。

このサンプルスクリプトでは、 VHDL および Verilog ファイルが読み込まれ、指定したデバイスでデザインが合成されます。 synth_design コマンドが完了すると、デザインが開き、メモリに読み込まれます。合成が完了すると、デザインチェックポイントが保存されます。

Tcl コマンドおよびそのオプションの詳細な説明は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)[参照 15] を参照してください。

open_checkpoint

これまでのリリースでは、チェックポイントデザインを読み込んで初期化するのに read_checkpoint コマンドを使用しました。バージョン 2014.1 からは、これに open_checkpoint コマンドを使用します。read_checkpoint コマンドの動作は変更されており、チェックポイントファイルがソースファイルのリストに追加されるだけです。この動作は、read_verilog、read_vhdl、read_xdc などのほかの read コマンドと一貫しています。read_checkpointコマンドを使用した場合、デザインを初期化し、メモリに読み込むために link_design コマンドも実行する必要があります。

open_checkpoint コマンドを使用すると、デザインチェックポイントファイル (DCP) が開き、新しいインメモリプロジェクトが作成されて、新しいプロジェクトがチェックポイントの内容で初期化されます。このコマンドでは、上位デザインチェックポイントまたは独立階層 (OOC) モジュールに対して作成されたチェックポイントを開くこ

とができます。

チェックポイントを開く場合、あらかじめプロジェクトを作成する必要はありません。open_checkpoint コマンドは、デザインデータをメモリに読み込み、デザインを非プロジェクトモードで開きます。プロジェクトモードおよび非プロジェクトモードの詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 17]を参照してください。





重要 : インクリメンタルコンパイルフローでは、これまでと同様に read_checkpoint コマンドを使用して基準デザインチェックポイントを指定します。

open_checkpoint の構文

open_checkpoint [-part <arg>] [-quiet] [-verbose] <file>

open_checkpoint のスクリプト例

# Read the specified design checkpoint and create an in-memory design.open_checkpoint C:/Data/post_synth.dcp

このサンプルスクリプトでは、合成済みデザインチェックポイントファイルが開きます。

open_run

合成済みまたはインプリメント済み run を開き、メモリに読み込みます。

重要 : open_run コマンドは、プロジェクトモードでのみ使用できます。デザイン run は非プロジェクトモードではサポートされません。

open_run コマンドをインプリメンテーション前の RTL デザインに使用し、完了した Vivado 合成 run を開いて、合成済みネットリストをメモリに読み込みます。

ヒント : メモリ内のデザインは自動的にアップデートされるので、 synth_design の後 open_run を使用する必要はありません。open_run コマンドは、以前のデザインセッションで完了した合成 run を開く場合にのみ使用します。

open_run コマンドは、RTL デザイン用です。ネットリストベースのデザインを開くには、 link_design コマンドを使用します。

open_run の構文

open_run [-name <arg>] [-quiet] [-verbose] <run>

open_run のスクリプト例

# Open named design from completed synthesis runopen_run -name synth_1 synth_1

このサンプルプロジェクトは、 synth_1 というデザインを開き、 synth_1 という完了した合成 run をメモリに読み込みます。

デザインがメモリにある場合に open_run コマンドを実行すると、新しいデザインを開く前に、現在のデザインへの変更を保存するかどうかを尋ねるメッセージが表示されます。





link_design

サードパーティ合成ツールなどで生成されたネットリストソースからメモリにデザインを作成し、ネットリストと合成制約をターゲットデバイスにリンクします。

ヒント : link_design コマンドは、プロジェクトモードおよび非プロジェクトモードの両方でネットリストデザインを作成する場合にサポートされます。

link_design の構文

link_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>] [-mode <arg>] [-quiet] [-verbose]

link_design のスクリプト例

# Open named design from netlist sources.link_design -name netDriven -constrset constrs_1 -part xc7k325tfbg900-1

デザインがメモリにある場合に link_design コマンドを実行すると、新しいデザインを開く前に、現在のデザインへの変更を保存するかどうかを尋ねるメッセージが表示されます。

推奨 : メモリに合成済みデザインを作成した後、エラーおよびクリティカル警告を調べて、不足している制約や不正な制約がないかどうかを確認してください。デザインが問題なく作成されたら、解析、レポート生成、制約の適用、またはインプリメンテーションを実行できます。

メモリに合成済みデザインを開いたら、 report_timing_summary コマンドを実行してタイミング制約をチェックし、デザインの目標が適切であるかどうかを確認してください。 Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 15] を参照してください。





ロジック最適化ロジック適化は、配置の前に効率的なロジックデザインを得るために実行します。ロジック適化では、ネットリスト接続性チェックが実行され、複数のドライバーを持つネットや駆動されていない入力などの発生する可能性のあるデザイン問題に対して警告メッセージが表示されます。ブロック RAM の消費電力適化も実行されます。

デザインの接続エラーはロジック適化段階に伝搬されることが多く、そこでエラーが発生します。インプリメンテーションを実行する前に、 DRC レポートを使用して接続が有効であることを確認することが重要です。

ロジック適化では、 DONT_TOUCH プロパティの値が TRUE に設定されているセルおよびネットの適化は実行されません。

ロジック適化を実行する Tcl コマンドは opt_design です。

使用可能なロジック最適化

Vivado ツールでは、ロジック適化はメモリ内のデザインに対して実行されます。

重要 : 特定のロジック適化に対応するコマンドオプションを指定すると、その適化のみが実行されます。ほかの適化は、通常デフォルトで実行されるものも、ディスエーブルになります。

リターゲット (デフォルト )

適化がしやすくなるように、セルタイプを別のセルタイプに置換します。たとえば、 MUXF7 はほかの LUT と統合できるように LUT3 に置換されます。また、インバーターのような単純なセルはダウンストリームロジックに吸収されます。

定数伝搬 (デフォルト )

定数値をロジックに伝搬することで、ロジックは次のようになります。

• 削除 :例 : 定数 0 が入力される AND

• 縮小 :例 : 定数 1 が入力される 3 入力 AND を 2 入力 AND に縮小

• 冗長 :例 : 0 が入力される 2 入力 OR を 1 本のワイヤに削減

スイープ (デフォルト )

ロードのないセルを削除します。

ブロック RAM の消費電力最適化 (デフォルト )

ブロック RAM セルに対して消費電力の適化をイネーブルにします。次を実行します。

• 完全なデュアルポート RAM の読み出されないポートの WRITE_MODE を NO_CHANGE に変更

• ブロック RAM の出力にクロックゲーティングを適用





リマップ

複数の LUT を 1 つの LUT にまとめてロジックの深さを削減します。

エリアモードでの再合成

エリアモードで合成を再実行し、 LUT の数を削減します。

順序エリアの再合成

組み合わせロジックおよび順序ロジックを削減するよう再合成を実行します。エリアモードでの再合成適化のスーパーセットを実行します。

重要 : 各ロジック適化はメモリ内のデザインに適用され、元の合成済みデザインには適用されません。

opt_design

ロジック適化を実行します。

opt_design の構文

opt_design [-retarget] [-propconst] [-sweep] [-bram_power_opt] [-remap] [-resynth_area] [-resynth_seq_area] [-directive <arg>] [-quiet] [-verbose]

opt_design のスクリプト例

# Run logic optimization with block RAM Power Optimization disabled, save results in a checkpoint, report timing estimatesopt_design -directive NoBramPowerOptwrite_checkpoint -force $outputDir/post_optreport_timing_summary -file $outputDir/post_opt_timing_summary.rpt

このサンプルスクリプトでは、メモリ内のデザインにロジック適化を実行し、メモリに書き込みます。適化後にデザインチェックポイントを保存し、タイミングサマリレポートを生成して指定のファイルに記述します。

最適化タイプの制限

適化タイプを制限するには、コマンドラインオプションを使用します。次に、デフォルトのブロック RAM 適化を実行しないようにする別の方法を示します。

opt_design -retarget -propconst -sweep

-directive オプションの使用

-directive オプションを使用すると、 opt_design コマンドを異なるモードで実行できます。一度に指定できるモードは 1 つのみです。 -directive オプションは、ほかのオプションと共に使用することはできません。

次のモードがあります。

• Explore

適化を複数回実行します。

• ExploreArea

組み合わせロジックを縮小することを優先して適化を複数回実行します。

• AddRemap

デフォルトのロジック適化フローを実行し、 LUT 再マップを含めてロジックレベルを削減します。





• ExploreSequentialArea

レジスタおよび関連の組み合わせロジックを縮小することを優先して適化を複数回実行します。

• RuntimeOptimized

反復回数を少なくし、デザインパフォーマンスよりも実行時間を短縮することを優先します。

• NoBramPowerOpt

opt_design コマンドの RAM 消費電力適化以外のデフォルト適化をすべて実行します。

-verbose オプションの使用

適化結果を解析するには、 -verbose オプションを使用し、 opt_design の適化の影響を受けたロジックの詳細を確認します。

-verbose オプションを使用すると大量のメッセージが表示されるので、デフォルトではオフになっています。-verbose オプションは、有益だと思われる場合に使用してください。

推奨 : 大型デザインでツールの実行時間を短縮するには、 -verbose オプションはシェルモードまたはバッチモードでのみ使用し、 GUI モードでは使用しないでください。

重要 : opt_design コマンドは、メモリ内のデザインに対して実行されます。複数回実行した場合、前回の run の結果が適化されます。そのため、 -verbose オプションを追加する前にインプリメント済みデザインを読み込み直す必要がある場合があります。

ロジック最適化制約

ロジック適化中、 DONT_TOUCH プロパティが認識され、このプロパティが設定されているネットは削除されません。詳細は、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。

DONT_TOUCH は下位セルに設定します。階層セルに DONT_TOUCH を設定するとセルの境界は保持されますが、セル内では適化が実行される可能性はあります。

グローバルクロックバッファーの挿入

ロジック適化では、ファンアウトの大きいリセットおよびクロックネットへのグローバルクロックバッファーの挿入は、デザインに含まれるグローバルクロックバッファーの総数が 12 を超えないように実行されます。リセットネットではファンアウトが 50,000 より大きく、クロックネットではファンアウトが 30 以上であることが必要です。

自動クロックバッファー挿入は、ボトムアップフローで有益です。グローバルクロックバッファーの挿入は、通常下位モジュールでは実行されません。これは、下位モジュールは独立階層モジュール (OOC) であり、ブラックボックスであるためにモジュールに含まれるクロックが認識されないからです。





消費電力の最適化クロックゲーティングを使用して、ダイナミック消費電力を適化します (オプション)。消費電力の適化は、プロジェクトモードおよび非プロジェクトモード両方で使用でき、ロジック適化後または配置後に実行してデザインの消費電力を適化できます。消費電力の適化には、クロックやロジックを変更せずに FPGA デザインのダイナミック消費電力を削減するクロックゲーティングソリューションが含まれます。

詳細は、『Vivado Design Suite ユーザーガイド : 消費電力解析および適化』 (UG907) [参照 11] を参照してください。

Vivado 消費電力解析

Vivado ツールでは、レガシ IP ブロックおよびサードパーティ IP ブロックを含む、デザイン全体が解析され、各クロックサイクルでの結果に影響しないレジスタからの出力ロジックが特定されます。

クロックイネーブル (CE) の使用

Vivado 消費電力適化では、ザイリンクス 7 シリーズ FPGA デバイスのロジックに多数含まれるクロックイネーブル (CE) が利用されます。細粒度クロックゲーティングまたはロジックゲーティング信号が作成され、余分なスイッチイングアクティビティが除去されます。

また、フリップフロップレベルでは、CE はフリップフロップの D 入力とフィードバック Q 出力のいずれかを選択するのではなく、クロックをゲーティングしているので、 CE 入力のパフォーマンスが向上するだけではなく、クロックの消費電力も削減されます。

クロックゲーティング

クロックゲーティングでは、シンプルデュアルポートまたは真のデュアルポートモード両方の専用ブロック RAMの消費電力も削減されます (図 2-2）。

これらのブロックには、次のイネーブルが含まれます。

• アレイイネーブル

• ライトイネーブル

• 出力レジスタのクロックイネーブル

節約される消費電力のほとんどはアレイイネーブルの使用によるもので、データが書き込まれず、出力が使用されないときに、消費電力を削減する機能がインプリメントされます。


図 2-1 : クロックゲーティング





power_opt_designpower_opt_design コマンドは、デザインを解析して適化します。デフォルトでは、デザイン全体が解析および

適化されます。クロックゲーティングも実行され、消費電力が適化されます。

power_opt_design の構文

power_opt_design [-quiet] [-verbose]

デザイン全体を解析および適化しない場合は、 set_power_opt を使用して適化を設定します。このコマンドを使用すると、適化にセルタイプまたは階層を含めるか、除外するかなどを設定できます。

set_power_opt コマンドの構文は、次のとおりです。

set_power_opt [-include_cells <args>] [-exclude_cells <args>] [-clocks <args>][-cell_types <args>] [-quiet] [-verbose]

注記 : opt_design を使用した場合、ブロック RAM の消費電力適化は実行されません。


図 2-2 : ブロック RAM イネーブルの利用





配置Vivado Design Suite 配置によりネットリストのセルがターゲットデバイスの特定サイトに配置されます。ほかのインプリメンテーションコマンドと同様、メモリ内のデザインに対して処理が実行されます。

デザイン配置の最適化

Vivado の配置では、次を適化するよう配置が実行されます。

• タイミングスラック : タイミングクリティカルなパスのセルの配置は、負のスラックが小限になるよう選択されます。

• 配線長 : 配線長を小限に抑えるように、全体的な配置が実行されます。

• 密集 : ピンの密集度が監視され、配線の密集を削減するためセルが分散されます。

デザインルールチェック

配置を開始する前に、デザインルールチェック (DRC) (report_drc で選択された DRC およびビルトインの内部DRC) が実行されます。内部 DRC では、LOC 制約の設定されていない Memory Interface Generator (MIG) セル、競合する IOSTANDARD が設定された I/O バンクなどの不正な配置がレポートされます。

クロックおよび I/O 配置

DRC の実行後、クロックおよび I/O セルが配置されてからその他のロジックセルが配置されます。クロックと I/O セルは、選択したザイリンクスデバイスに特定の複雑な配置規則によって関連していることがよくあるので、同時に配置されます。 IOB プロパティが設定されたレジスタセルは、 IOB 値が TRUE のどのレジスタを I/O ロジックサイトにマップするかを決定するためにこの段階で処理されます。配置で IOB プロパティの TRUE を適用できない場合は、クリティカル警告が表示されます。

配置のターゲット

この時点では、次が配置のターゲットとなります。

• I/O ポートおよび関連ロジック

• グローバルおよびローカルクロックバッファー

• クロックマネージメントタイル (MMCM および PLL)

• ギガビットトランシーバー (GT) セル

固定されていないロジックの配置

配置のこの段階では、固定されていないロジックを配置する際 LOC プロパティや Pblock 割り当てなどの物理制約に従います。既存の LOC 制約は、ネットリストの接続およびデバイスサイトに対して有効かどうかがチェックされます。 MIG や GT のような一部の IP は、デバイス専用の配置制約を使用して生成されます。

重要 : デバイスの I/O アーキテクチャのために、 LOC プロパティで LOC が適用されていないセルが制約されることがよくあります。入力ポートに LOC 制約が設定されている場合、関連する I/O バッファー、 IDELAY、 ILOGIC の位置も固定されます。競合する LOC 制約は、入力パスの個々のセルには適用できません。出力および GT 関連のセルの場合も同様です。





クロックリソースの配置規則

クロックリソースの配置は、『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472) [参照 13] および『UltraScale アーキテクチャクロッキングリソースユーザーガイド』 (UG572) [参照 14] に示す配置規則に従う必要があります。たとえば、グローバルクロックバッファーを駆動する入力はクロック兼用 I/O サイトに配置する必要があり、デバイスの上半分または下半分のどちらか同じ側に配置する必要があります。これらのクロック配置規則も、論理ネットリストの接続およびデバイスサイトに対して有効かどうかがチェックされます。

クロックおよび I/O を配置できない場合

クロックおよび I/O の適切な配置が見つからなかった場合は、違反のあった配置規則と、影響を受けたセルの簡単な説明が表示されます。まずサイトにセルが暫定的に配置され、その後配置問題を解決するために別のセルが配置されることがあります。暫定的な配置により、クロックおよび I/O 配置のエラーの原因がわかることがよくあります。暫定的な配置でエラーになったセルを手動で配置すると、配置が改善することがあります。

ヒント : place_ports コマンドを実行してクロックおよび I/O を配置してから、 place_design コマンドを実行します。ポート配置でエラーが発生した場合、配置はメモリに保存され、エラーを解析できます。詳細は、 Vivado Tclプロンプトから place_ports -help を実行してください。

グローバル配置、詳細配置、パッキングおよび有効化

クロックおよび I/O を配置した後、次の配置プロセスが実行されます。

• グローバル配置

• 詳細配置

• パッキングおおよび有効化

推奨 : 配置後に report_timing を実行し、クリティカルパスをチェックしてください。ネガティブスラックが大きいパスは、タイミングクロージャを達成するため、手動配置、制約の変更、またはロジックの再構築が必要な場合があります。

place_designデザインを配置します。ほかのインプリメンテーションコマンドと同様、 place_design コマンドはインクリメンタルに実行されます。部分的に配置されているデザインに対しては、始めから配置し直すのではなく、既存の配置が開始点として使用されます。

place_design の構文

place_design [-directive <arg>] [-no_timing_driven] [-timing_summary] [-unplace] [-post_place_opt] [-quiet] [-verbose]

place_design のスクリプト例

# Run placement, save results to checkpoint, report timing estimatesplace_designwrite_checkpoint -force $outputDir/post_placereport_timing_summary -file $outputDir/post_place_timing_summary.rpt

このサンプルスクリプトは、メモリ内のデザインを配置して、配置後にデザインチェックポイントを保存し、タイミングサマリレポートを生成して指定のファイルに記述します。






-directive オプションを使用すると、 place_design コマンドを異なるモードで実行できます。一度に指定できるモードは 1 つのみです。 -directive オプションは、ほかのオプションと共に使用することはできません。

配置は、どのタイプのデザインにどのモードを使用するかが全体的なデザインパフォーマンスにも大きく影響するので、 -directive のモード設定がもっとも多数あります。

• 名前に BlockPlacement が含まれるモードは、ブロック RAM または DSP ブロック、あるいはその両方を多数含むデザインに適しています。

• 名前に NetDelay が含まれるモードは、遠距離のネット接続を含むデザインおよび多数の異なるモジュールにファンアウトするネットを含むデザインに適しています。

• 名前に SpreadLogic が含まれるモードは、接続が多数ある密集が発生しやすいデザインに適しています。

• ExtraPostPlacementOpt は、すべてのタイプのデザインに適しています。

• 名前に SSI が含まれるモードは、密集を緩和したりタイミングを向上するため、異なる分割方法が有益である可能性のある SSI デザインに適しています。

配置の -directive オプションで指定可能なモード

重要 : 配置の -directive オプションは現在のところ UltraScale™ デバイスアーキテクチャではサポートされていません。配置で -directive オプションを指定しても無視され、デフォルト設定で配置が続行されます。

配置は通常デザインの全体的なパフォーマンスにも影響するので、-directive オプションで指定可能なモードが多数あります。表 2-3 に、どのモードがどのようなデザインに効果的かを示します。

-directive オプションで指定可能なモード

• Explore

詳細配置および配置後の適化のエフォートを増加します。

• WLDrivenBlockPlacement

RAM および DSP ブロックをワイヤ長に基づいて配置します。タイミングドリブンの配置を無効にし、ブロックとの接続距離を短にするよう配置します。 RAM および DSP ブロックへのパスおよびこれらのブロックからのパスのタイミングを向上できます。

• LateBlockPlacement

RAMB および DSP ブロックの詳細配置を、配置の終段階で実行します。通常、ブロックは配置プロセスの初期段階で有効なサイトに割り当てられます。その代わり、まず大まかなブロック配置を実行し (適切な列に揃っていない可能性もあり )、詳細配置中にブロックを有効なサイトに配置します。

表 2-3 : -directive オプションのガイドライン

モード効果が得られるデザイン

BlockPlacement ブロック RAM または DSP ブロック、あるいはその両方を多数含むデザイン

ExtraNetDelay 遠距離のネット接続を含むデザインおよび多数の異なるモジュールにファンアウトするネットを含むデザイン

SpreadLogic 接続が多数ある密集が発生しやすいデザイン

ExtraPostPlacementOpt すべてのタイプのデザイン

SSI 密集を緩和したりタイミングを向上するため、異なる分割方法が有益である可能性のある SSI デザイン





• ExtraNetDelay_high

ファンアウトが大きく距離の長いネットの予測遅延を増加します。 place_design コマンドの後にはタイミングが満たされていたが、過剰に良く見積もられた遅延のために route_design コマンドの後タイミングが満たされなくなったクリティカルパスのタイミングを向上できます。high、medium、low の 3 つのレベルがサポートされます。 ExtraNetDelay_high では増加量がも大きくなります。

• ExtraNetDelay_medium

ファンアウトが大きく距離の長いネットの予測遅延を増加します。 place_design コマンドの後にはタイミングが満たされていたが、過剰に良く見積もられた遅延のために route_design コマンドの後タイミングが満たされなくなったクリティカルパスのタイミングを向上できます。high、medium、low の 3 つのレベルがサポートされます。 ExtraNetDelay_medium はデフォルトレベルの増加量を適用します。

• ExtraNetDelay_low

ファンアウトが大きく距離の長いネットの予測遅延を増加します。 place_design コマンドの後にはタイミングが満たされていたが、過剰に良く見積もられた遅延のために route_design コマンドの後タイミングが満たされなくなったクリティカルパスのタイミングを向上できます。high、medium、low の 3 つのレベルがサポートされます。 ExtraNetDelay_low では増加量がも小さくなります。

• SpreadLogic_high

密集した領域が作成されないように、ロジックをデバイス全体に分散します。 high、 medium、 low の 3 つのレベルがサポートされます。 SpreadLogic_high では分散度がも高くなります。

• SpreadLogic_medium

密集した領域が作成されないように、ロジックをデバイス全体に分散します。 high、 medium、 low の 3 つのレベルがサポートされます。 SpreadLogic_medium では分散度が中程度になります。

• SpreadLogic_low

密集した領域が作成されないように、ロジックをデバイス全体に分散します。 high、 medium、 low の 3 つのレベルがサポートされます。 SpreadLogic_low では分散度がも低くなります。

• ExtraPostPlacementOpt

配置後の適化のエフォートを増加します。

• SSI_ExtraTimingOpt

SLR 間でのタイミングドリブンの分割に代替アルゴリズムを使用します。

• SSI_SpreadSLLs

SLR 間で分割を実行し、接続の多い領域に追加のエリアを割り当てます。

• SSI_BalanceSLLs

SLR 間で SLL のバランスが取られるように SLR 間で分割を実行します。

• SSI_BalanceSLRs

SLR 間でセルの数のバランスが取られるように SLR 間で分割を実行します。

• SSI_HighUtilSLRs

各 SRL でロジックを近くに配置するよう指定します。



• Quick

も高速な、タイミングドリブンでない、有効なデザインを得るために低限の配置を実行します。

• Defaults

place_design をデフォルト設定で実行します。

ヒント : -directive オプションを使用して、デザインの異なる配置オプションを試してみてください。

-unplace オプションの使用

-unplace オプションは、デザイン内で固定されたロケーションを持たないセルおよびポートの配置を解除します。固定されたロケーションを持つオブジェクトでは、 IS_LOC_FIXED プロパティが TRUE に設定されています。





-no_timing_driven オプションの使用

-no_timing_driven オプションは、デフォルトのタイミングドリブン配置アルゴリズムをディスエーブルにします。このオプションを使用するとワイヤの長さに基づいて高速な配置が実行されますが、タイミング制約は無視されます。

-timing_summary オプションの使用

配置後、タイミングサマリ (概算) がログファイルに出力されます。デフォルトでは、数値は配置の内部予測に基づきます。次に例を示します。

INFO: [Place 30-746] Post Placement Timing Summary WNS=0.022. For the most accurate timing information please run report_timing.

実行時間が多少長くなるがより正確な結果を得るには、-timing_summary オプションを使用すると、スタティックタイミングエンジンからの結果に基づくタイミングサマリがレポートされます。

INFO: [Place 30-100] Post Placement Timing Summary | WNS=0.236 | TNS=0.000 |

説明 :

° WNS : ワーストネガティブスラック

° TNS : トータルネガティブスラック


配置結果をより詳細に解析するには、 -verbose オプションを使用して、 place_design コマンドによるセルおよび I/O 配置の詳細を確認します。


-post_place_opt オプションの使用

配置後に適化を実行すると、クリティカルパスのタイミングが向上される可能性がありますが、配置配線の実行時間が増加します。この適化は、完全に配置されたタイミング違反を含むデザインで実行します。違反の大きいいくつかのクリティカルパスに対して、クリティカルセルを移動し、予測遅延が向上されたら新しいセル配置を確定します。実行時間が長く、クリティカルパスが比較的多いデザインでは、これらの配置の変更によりタイミングがさらに向上する場合があります。

この適化は配置後のどの段階でも実行でき、配線済みデザインで実行すると特に有益です。配線済みデザインでこの適化を実行する場合、次の点に注意する必要があります。

• タイミングデータは実際の配線遅延に基づいているので、適化で悪のクリティカルパスが確実に考慮されます。

• 適化中のセルの移動の評価では、セル配置に基づいて遅延が予測されます。実際の配線遅延は使用されません。

• 新しいセル配置が確定されると、関連のネットの配線が解除されるので、これらのネットを配線する必要があります。





次に例を示します。

1. 配置後に配置後の適化を実行します。

place_designplace_design -post_place_opt

2. 配線後に配置後の適化を実行します。

place_designphys_opt_designroute_designplace_design -post_place_optroute_design

3. 配線後に配置後の適化をループで複数回実行します。簡単に実行できるようにするため、インプリメンテーションコマンドを runPPO という Tcl プロシージャにまとめ、引数で実行回数と各実行で phys_opt_designをイネーブルにするかどうかを指定します。

proc runPPO { {numIters 1} {enablePhysOpt 1} } { for {set i 0} {$i < $numIters} {incr i} { place_design -post_place_opt if {$enablePhysOpt != 0} { phys_opt_design } route_design if {[get_property SLACK [get_timing_paths ]] >= 0} {break}; #stop if timing is met }}

...place_designphys_opt_designroute_designrunPPO 4 1 ; # run 4 post-route iterations and enable phys_opt_design

物理最適化物理適化では、デザインの負のスラックパスに対してタイミングドリブンの適化が実行されます。物理適化には、配置後と配線後の 2 つのモードがあります。

配線後モードでは、セル配置からのタイミング予測に基づいて適化が実行されます。物理適化では、ロジック適化によるネットリストの変更が自動的に組み込まれ、必要に応じてセルが配置されます。

配線後モードでは、実際の配線遅延に基づいて適化が実行されます。ロジックの変更に応じた自動的なネットリストのアップデートおよびセルの配置に加え、必要に応じて配線もアップデートされます。

全体的な物理適化は配置後モードでの方がより積極的に実行されるので、ロジックが適化される機会が多くなります。配線後モードでは、タイミングクロージャが達成された配線に影響を与えないように、物理適化は控えめに実行されます。物理適化を実行する前にデザインの配線ステータスがチェックされ、配置後または配線後のどちらのモードを使用するかが判断されます。

デザインのスラックが負でなく、タイミングベースの適化オプションを含む物理適化が指定された場合、適化は実行されずにコマンドが終了します。





使用可能な物理最適化

Vivado ツールでは、物理適化はメモリ内のデザインに対して実行されます。

重要 : 特定の物理適化に対応するコマンドオプションを指定すると、その適化のみが実行されます。ほかの適化は、通常デフォルトで実行されるものも、ディスエーブルになります。

ファンアウトの大きいネットの最適化

ファンアウトの大きいネットの適化は、次のように実行されます。

1. 負のスラックが WNS のある割合以内であるファンアウトの大きいネットは、複製が考慮されます。

2. ロードはその配置によりクラスター化され、各ロードクラスターに対してドライバーが複製および配置されます。

3. タイミングが再解析され、タイミングが改善した場合はロジックの変更が確定されます。

4. 複製後、複製が必要なファンアウトの大きいネットがあるかどうか、デザインが再びチェックされます。ファンアウトの大きいネットがまだある場合、なくなるまで複製プロセスが続行されます。

配置ベースの最適化

クリティカルパスのすべてのセルをワイヤ遅延を削減するように配置し直します。

配線の最適化

クリティカルパスのネットおよびピンを遅延を小さくするよう配線し直します。

表 2-4 : 配置後および配線後の物理最適化

オプション名配置後配線後

実行可能デフォルト実行可能デフォルト

ファンアウトの大きいネットの適化 ○ ○ × なし

配置の適化 ○ ○ ○ ○

配線の適化 × なし ○ ○

リワイヤ ○ ○ ○ ○

クリティカルセルの適化 ○ ○ ○ ○

DSP レジスタの適化 ○ ○ × なし

ブロック RAM レジスタの適化 ○ ○ × なし

シフトレジスタの適化 ○ ○ × なし

クリティカルピンの適化 ○ ○ × なし

ブロック RAM イネーブルの適化 ○ ○ × なし

ホールド違反の修正 ○ × × なし

リタイミング ○ × ○ ×

ネットの強制的な複製 ○ × × なし

クロックの適化 × なし ○ ○





リワイヤ

LUT の接続をスワップしてクリティカル信号のロジックレベル数を削減することにより、クリティカルパスを適化します。 LUT 論理式を変更してデザインの機能を保持します。

クリティカルセルの最適化

タイミングが満たされないパスのセルを複製します。特定のセルのロード同士が離れている場合、セルが複製され、新しいドライバーがロードクラスターの近くに配置されます。この適化は、パスがワーストネガティブスラックのある割合以内でタイミングを満たしていなければ、ファンアウトが大きくなくても実行されます。

DSP レジスタの最適化

DSP セルのレジスタをロジックアレイに移動したり、ロジックアレイから DSP セルに移動したりすることにより、クリティカルパスの遅延を削減します。

ブロック RAM レジスタの最適化

ブロック RAM セルのレジスタをロジックアレイに移動したり、ロジックアレイからブロック RAM セルに移動したりすることにより、クリティカルパスの遅延を削減します。

シフトレジスタの最適化

シフトレジスタの適化を実行すると、シフトレジスタセル (SRL) とほかのロジックセル間の負のスラックパスのタイミングが向上します。

シフトレジスタセル (SRL16E または SRLC32E) に入出力するパスにタイミング違反がある場合、この適化で SRLレジスタチェーンの初または後を抽出してロジックファブリックに配置することにより、タイミングを向上します。この適化により、元のクリティカルパスのワイヤ長が短くなります。

この適化では、レジスタがシフトレジスタからロジックファブリック移動されるだけで、ロジックファブリックからシフトレジスタに移動されることはありません。ロジックファブリックからシフトレジスタにレジスタを移動しても、タイミングは向上しません。

この適化が実行されるための必要条件は、次のとおりです。

• SRL アドレスが 1 以上で、 SRL 外に移動できるレジスタ段がある。

• SRL アドレスが一定値である (論理 1 または 0 で駆動)。

• SRL セルで開始または終了するタイミング違反が悪のクリティカルパスの 1 つである。

次のような一部の回路トポロジは適化されません。

• 大型シフトレジスタを構成するためチェーン接続された SRLC32E

• Q31 出力ピンを使用する SRLC32E

• O5 および O6 出力の両方を使用して 1 つの LUT に組み合わせられた SRL16E

SRL からロジックファブリックに移動されるレジスタは FDRE セルです。 FDRE および SRL INIT プロパティ、 SRLアドレスは、それに応じて調整されます。次に例を示します。





クリティカルパスがシフトレジスタ (SRL16E) srl_inste から開始するとします (図 2-3)。

シフトレジスタの適化後、タイミングを向上するため、シフトレジスタの終段が SRL16E から取り出されてロジックファブリックに配置されました (図 2-4)。

srl_inste の SRL16E アドレスは、内部レジスタ段が 1 つ少なくなったことを反映して減少されます。 srlopt レジスタがダウンストリームセルの近くに配置され、FDRE セルの clock-to-output 遅延は比較的短いので、元のクリティカルパスは短くなります。


図 2-3 : シフトレジスタ srl_inste から開始するクリティカルパス


図 2-4 : シフトレジスタ最適化後のクリティカルパス





クリティカルピンの最適化

論理 LUT 入力ピンを高速の物理ピンに再マップし、クリティカルパスのタイミングを向上します。 A1 や A2 などの低速の物理ピンにマップされているクリティカルパス上の論理ピンが、タイミングが向上する場合に A6 や A5 などの高速の物理ピンに割り当て直されます。 LOCK_PINS プロパティが設定されているセルはスキップされ、LOCK_PINS で指定されているピンマップが保持されます。論理ピンと物理ピンのマップを取得するには、get_site_pins コマンドを使用します。

ブロック RAM イネーブルの最適化

ブロック RAM イネーブルを適化すると、消費電力適化されたブロック RAM に関連するクリティカルパスのタイミングを向上できます。

配置前のブロック RAM 消費電力適化では、ダイナミック消費電力を削減するために、ブロック RAM の読み出しおよび書き込みイネーブル入力を駆動するロジックが再構築されます。配置後、再構築されたロジックがタイミングクリティカルになる可能性があります。ブロック RAM イネーブルの適化を実行すると、イネーブルロジックの適化が元に戻され、クリティカルなイネーブルロジックパスのスラックが向上します。

ホールド違反の修正

ホールドクリティカルパスの遅延を増加することにより、ホールド違反の大きいパスのスラックを向上します。

リタイミング

レジスタを組み合わせロジックの前後に移動することにより、クリティカルパスの遅延を向上します。

ネットの強制的な複製

タイミングスラックにかかわらず、ネットのドライバーを強制的に複製します。複製はロードの配置に基づいて実行され、複製が十分かどうかを解析する必要があります。さらに複製が必要な場合は、コマンドを複数回実行することによりネットを繰り返し複製できます。タイミングは無視されますが、複製を実行するには、ネットがタイミング制約の設定されたパスに含まれている必要があります。

クロックの最適化

グローバルバッファーを挿入し、クリティカルパスの開始点と終点の間に有益なスキューを作成します。セットアップタイミングを向上するため、デスティネーションクロックを遅延するバッファーが挿入されます。

配線の最適化

遅延を削減するためタイミングクリティカルネットに対して配線適化を実行します。

物理最適化レポート

物理適化では、適化で処理された各ネットと、実行された適化のサマリがレポートされます。

ヒント : 複製されたオブジェクトの名前は、元のオブジェクト名に _replica と複製されたオブジェクトカウントが付いたものになります。





phys_opt_designデザインに対して物理適化を実行します。配置後に配置後モードで、またはデザインを完全に配置した後に配線後モードで実行できます。

phys_opt_design の構文

phys_opt_design [-fanout_opt] [-placement_opt] [-routing_opt] [-rewire] [-critical_cell_opt] [-dsp_register_opt] [-bram_register_opt] [-bram_enable_opt] [-shift_register_opt] [-hold_fix] [-retime] [-force_replication_on_nets <args>] [-directive <arg>] [-critical_pin_opt] [-clock_opt] [-quiet] [-verbose]

phys_opt_design のスクリプト例

open_checkpoint top_placed.dcp

# Run post-place phys_opt_design and save resultsphys_opt_designwrite_checkpoint -force $outputDir/top_placed_phys_opt.dcpreport_timing_summary -file $outputDir/top_placed_phys_opt_timing.rpt

# Route the design and save resultsroute_designwrite_checkpoint -force $outputDir/top_routed.dcpreport_timing_summary -file $outputDir/top_routed_timing.rpt

# Run post-route phys_opt_design and save resultsphys_opt_designwrite_checkpoint -force $outputDir/top_routed_phys_opt.dcpreport_timing_summary -file $outputDir/top_routed_phys_opt_timing.rpt

上記の例では、配置後および配線後の両方で物理適化が実行されます。まず、配置済みデザインがチェックポイントから読み込まれ、配置後の phys_opt_design が実行されます。チェックポイントおよびタイミングの結果が保存されます。次にデザインが配線され、保存されます。その後、配線後の phys_opt_design が実行され、結果が保存されます。配置後および配線後の物理適化の両方で、同じ phys_opt_design コマンドが使用されます。モードを指定するためにオプションを使用する必要はありません。


-directive オプションを使用すると、 phys_opt_design コマンドを異なるモードで実行できます。一度に指定できるモードは 1 つのみです。-directive オプションは、ほかのオプションと共に使用することはできません。次に -directive オプションに設定可能な値を示し、表 2-5 に配置後および配線後のサポートをまとめています。

• Explore

適化を複数回実行し、ファンアウトの大きいネットの複製を含め、異なるアルゴリズムを実行します。

• ExploreWithHoldFix

適化を複数回実行し、ホールド違反の修正およびファンアウトの大きいネットの複製を含め、異なるアルゴリズムを実行します。

• AggressiveExplore

Explore と似ていますが、異なる適化アルゴリズムを使用し、より厳しい目標を設定します。

• AlternateReplication

クリティカルセルの複製に異なるアルゴリズムを使用します。

• AggressiveFanoutOpt

ファンアウトに関連する適化に異なるアルゴリズムを使用し、より厳しい目標を設定します。





• AlternateDelayModeling

ネット遅延の予測に代替アルゴリズムを使用して、すべての適化を実行します。

• AddRetime

デフォルトの phys_opt_design フローを実行し、レジスタのリタイミングを追加します。

• AlternateFlowWithRetiming

複製と DSP およびブロック RAM の適化をより積極的に実行し、レジスタのリタイミングをイネーブルにします。

• Defaults

phys_opt_design をデフォルト設定で実行します。


物理適化の結果を解析するには、 -verbose オプションを使用し、 phys_opt_design で実行された適化の詳細を確認します。


重要 : phys_opt_design コマンドは、メモリ内のデザインに対して実行されます。 2 回実行した場合、 1 回目の runの結果が適化されます。

物理最適化制約

物理適化中、DONT_TOUCH プロパティが認識され、これらのプロパティが設定されているネットまたはセルには適化は実行されません。また、 Pblock の割り当てに従い、複製されたロジックでも元のロジックの Pblock 割り当てが適用されます。タイミング例外も、元のセルから複製セルにコピーされます。

詳細は、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。

DONT_TOUCH は下位セルに設定します。階層セルに DONT_TOUCH を設定するとセルの境界は保持されますが、セル内では適化が実行される可能性はあります。

表 2-5 : phys_opt_design コマンドの -directive オプションのサポート

-directive オプションの値配置後配線後

Defaults ○ ○

Explore ○ ○

ExploreWithHoldFix ○ ×

AggressiveExplore ○ ○

AlternateReplication ○ ×

AggressiveFanoutOpt ○ ×

AlternateDelayModeling ○ ○

AddRetime ○ ○

AlternateFlowWithRetiming ○ ×





配線Vivado 配線は、配置済みデザインに対して配置を実行し、ホールドタイム違反を解決するため配線済みデザインの適化を実行します。

配置済みデザインから開始し、すべてのネットの配線を試みます。配置済みの次のいずれかのデザインから開始します。

• 未配線

• 一部配線済み

• 完全に配線済み

部分的に配線されているデザインに対しては、始めから配線し直すのではなく、既存の配線が開始点として使用されます。完全に配線済みのデザインでは、タイミング違反がチェックされ、タイミングを満たすためにクリティカル部分が配線し直されます。

注記 : 再配線プロセスでは、既存の配線が破棄されて配線し直されます。

配線では、デザイン全体を配線するオプションと、個々のネットおよびピンの配線を修正するオプションがあります。デザイン全体を配線する場合、フローはタイミングドリブンであり、タイミング制約に基づくタイミングバジェット全体が使用されます。ネットおよびピンの配線を修正する場合、反復セッションの反応をよくするため、高速で軽量のタイミングモデルが使用されます。

推奨 : 実行時間を短縮するためにパフォーマンスが低下するのを回避するため、 report_timing コマンドを実行するか、または配線を修正した後にデザイン全体を配線し、タイミング制約が満たされるようにするのが良です。

配線では、ネットおよびピンの配線を修正する場合でも、初期化のため、初の実行時間は長くなります。初期化時間は、デザインのサイズおよびデバイスのサイズが大きくなると長くなります。 1 回初期化されると、デザインを閉じて開き直さない限り、再度初期化は実行されません。

デザインルールチェック配線を開始する前に、次のデザインルールチェック (DRC) が実行されます。

• report_drc コマンドを使用してユーザーが選択した DRC

• Vivado 配線エンジンに含まれるビルトインの DRC

配線の優先順位

Vivado 配線では、まず次のようなグローバルリソースが配線されます。

• クロック

• リセット

• I/O

• その他の専用リソース

このデフォルトの優先順位は Vivado 配線にビルトインされています。その後、タイミングがどれだけクリティカルかに基づいて、データ信号に優先順位が付けられます。





不適切なタイミング制約の影響

配線後のタイミング違反は、タイミングが制約が不正なために発生していることがあります。配線設定を変更してみる前に、制約が適切であるかどうかを確認してください。配線の前の配置済みデザインのタイミングレポートを参照して、タイミングと制約を確認します。

次に、よくある不適切なタイミング制約の例を示します。

• クロックドメインをまたがるパスや、ホールドタイミングにより配線遅延が追加される複数サイクルパス

• 密集しているエリア。これは RTL 合成のファンアウト適化や物理適化により解決できます。

推奨 : 複数の配線オプションを試す前に、タイミング制約を確認して不正なものを修正するか、または RTL を変更することを考慮してください。

route_designデザインを配線します。

route_design の構文

route_design [-unroute] [-release_memory] [-nets <args>] [-physical_nets] [-pin <arg>] [-directive <arg>] [-tns_cleanup] [-no_timing_driven] [-preserve] [-delay] -max_delay <arg> -min_delay <arg> [-timing_summary] [-quiet] [-verbose]


デザイン全体を配線する際、 -directive オプションを使用すると、 route_design コマンドを異なるモードで実行できます。一度に指定できるモードは 1 つのみです。-directive オプションは、競合する適化が実行されるのを回避するため、ほかのほとんどのオプションとは共に使用できません。次のモードがあります。

• Explore

初期配線の後、異なるクリティカルパス配線を試します。

• NoTimingRelaxation

配線を完了するためにタイミングを緩和しないようにします。配線でタイミング満たすのが困難である場合、元のタイミング制約を満たすため実行時間が長くなります。

• MoreGlobalIterations

終段階だけでなく、すべての段階で詳細なタイミング解析を使用し、タイミングの向上が少しであってもグローバル反復を実行します。

• HigherDelayCost

配線の内部コスト関数を調整して反復実行で遅延に焦点を置き、実行時間が長くなる代わりにパフォーマンスを向上します。

• AdvancedSkewModeling

配線のすべての段階でより正確なスキューモデルを使用します。スキューの大きいクロックネットワークでデザインのパフォーマンスが向上する場合があります。



• Quickも高速な、タイミングドリブンでない、有効なデザインを得るために低限の配置を実行します。

• Defaultsroute_design をデフォルト設定で実行します。





よりよい配線結果を得るために実行時間を長くする

次の -directive 設定を使用すると、実行時間が長くなる代わりによりよい配線結果が得られる可能性があります。

• NoTimingRelaxation

• MoreGlobalIterations

• HigherDelayCost

• AdvancedSkewModeling

route_design コマンドのその他のオプションの使用

次に、 route_design コマンドのその他のオプションの詳細と値を示します。

• -nets

指定したネットのリストに対してのみ処理を実行します。ネットオブジェクトの Tcl リストを引数として指定します。ネットは、ネット名の文字列値で指定するのではなく、 get_nets コマンドを使用してネットオブジェクトとして指定する必要があります。

• -pin

指定したピンに対してのみ処理を実行します。ピンオブジェクトを引数として指定します。ピンは、ピン名の文字列値で指定するのではなく、get_pins コマンドを使用してピンオブジェクトとして指定する必要があります。

• -delay

デフォルトでは、個々のネットおよびピンは、タイミングクリティカルかどうかにかかわらず、使用可能なリソースを使用して短の実行時間で配線されます。 -delay オプションを使用すると、遅延が小になるように配線されます。

• -min_delay および -max_delayこれらのオプションは -pin オプションを使用している場合にのみ使用可能で、ターゲット遅延をピコ秒で指定します。 -max_delay オプションは、指定のピンの配線に使用する大 slow-max コーナー遅延を指定します。同様に、 -min_delay オプションは小 fast-min コーナー遅延を指定します。両方のオプションを使用して、遅延の範囲を指定できます。

• -preserve

既存の配線を保持してデザイン全体を配線します。 -preserve オプションを使用しない場合、クリティカルパスのタイミングを向上するため、既存の配線が解除され、配線し直されることがあります。このオプションは、クリティカルネットを事前に配線し、配線リソースに優先的にアクセスできるようにする場合によく使用されます。これらの配線が完了したら、 -preserve オプションを使用して、デザインの残りの部分が配線されるときに完了した配線が変更されないようにします。このオプションは、FIXED_ROUTE および IS_ROUTE_FIXED ネットプロパティとは無関係で、使用した route_design コマンドの実行でのみ配線が保持されます。

• -unroute

デザイン全体、あるいは -nets または -pin オプションを使用している場合はネットおよびピンの配線を解除します。FIXED_ROUTE プロパティが設定されているネットの配線は解除されません。FIXED_ROUTE プロパティが設定されているネットの配線を解除するには、まずプロパティを削除する必要があります。

• -timing_summary

デフォルトでは、内部予測タイミングに基づいたタイミングサマリが出力されますが、見積もりの悪い遅延のため、実際の配線後のタイミングとは異なる場合があります。-timing_summary オプションを使用すると、Vivadoスタティックタイミング解析機能が呼び出され、実際の配線遅延に基づくタイミングサマリがレポートされます。スタティックタイミング解析のため、実行時間は長くなります。

• -tns_cleanup

実行時間を短にするため、配線ではトータルネガティブスラック (TNS) ではなくワーストネガティブスラック (WNS) パスに焦点が置かれます。 -tns_cleanup オプションを使用すると、配線の後に追加のフェーズが実行され、 WNS パス以外にタイミングが満たされていない TNS パスの修正が試みられます。 TNS は削減される可能性がありますが、実行時間が長くなることがあります。 WNS には影響しません。配線後の物理適化を実行する場合は、配線で修正可能な TNS パスに無駄な絵フォーとを費やさず、 WNS パスに焦点が置かれるようにするため、 -tns_cleanup オプションを使用することをお勧めします。このオプションは、 -directive オプションと共に使用できます。





• -physical_nets

論理 0 および論理 1 の配線のみに処理を実行します。デザインのすべての定数値に適用されます。 -unroute オプションと共に使用できます。定数 0 および 1 を接続すると、物理デバイスに対応する論理ネットがないので、これらのネットは -nets および -pin オプションを使用して確実に配線または配線解除できません。

• -release_memory

配線初期化の後、適なパフォーマンスのため、配線データはメモリに保持されます。このオプションを使用すると、データがメモリから削除され、メモリがオペレーティングシステムに返されます。ほとんどの場合、このオプションを使用する必要はありません。非常に大型のデザインを処理する場合など、配線のメモリ使用量を手動で制御する必要がある場合に使用します。

• -no_timing_driven

タイミングドリブン配線をオフにします。主にデザインの配線性をテストするために使用します。

配線のサンプルスクリプト 1

# Route design, save results to checkpoint, report timing estimates route_designwrite_checkpoint -force $outputDir/post_routereport_timing_summary -file $outputDir/post_route_timing_summary.rpt

このサンプルスクリプトでは、次の処理を実行しています。

• デザインを配線します。

• 配線が完了したら、デザインチェックポイントを保存します。

• タイミングサマリレポートを生成します。

• レポートを指定したファイルに記述します。

配線は、インプリメンテーション run の一部として、または Tcl スクリプトの一部として place_design の後にroute_design コマンドを使用して実行します。

配線が完了すると、配線リソースの使用率サマリと予測タイミングサマリがレポートされます。次に、これらのレポートの例を示します。

配線リソース使用率サマリ

Global Vertical Routing Utilization = 15.3424 % Global Horizontal Routing Utilization = 16.3981 % Routable Net Status* *Does not include unroutable nets such as driverless and loadless. Run report_route_status for detailed report. Number of Failed Nets = 0 Number of Unrouted Nets = 0 Number of Partially Routed Nets = 0 Number of Node Overlaps = 0

タイミングサマリ

[Route 35-57] Estimated Timing Summary | WNS=0.105 | TNS=0 | WHS=0.051 | THS=0

説明 :

° WNS : ワーストネガティブスラック

° TNS : トータルネガティブスラック

° WHS : ワーストホールドスラック

° THS : トータルホールドスラック






# Get the nets in the top 10 critical paths, assign to $preRoutesset preRoutes [get_nets -of [get_timing_paths -max_paths 10]]

# route $preRoutes first with the smallest possible delayroute_design -nets [get_nets $preRoutes] -delay

# preserve the routing for $preRoutes and continue with the rest of the designroute_design -preserve

このサンプルスクリプトでは、まずいくつかのクリティカルネットを配線し、その後デザイン全体を配線しています。個々のネットおよびピン (この場合はネット ) を配線する例を示しています。これは通常、次のような場合など、特定の配線問題を修正するために実行します。

• 完全に配線する前に、クリティカルネットおよびロックダウンリソースを事前に配線

• クリティカルではないネットの配線を手動で解除して、クリティカルネットにより多くの配線リソースを使用できるようにする

初の route_design コマンドでは、配線機能が初期化されてから、クロックなどの重要なネットが配線されます。


route_design# Unroute all the nets in u0/u1, and route the critical nets firstroute_design -unroute [get_nets u0/u1/*] route_design -delay -nets [get_nets $myCritNets]route_design -preserve

このサンプルスクリプトでは、密集によるタイミングエラーを解決する方法の 1 つを示しています。 $myCritNetsで表されたクリティカルネットには、インスタンス u0/u1 のネットと同じデバイス領域の配線リソースが必要です。u0/u1 のネットはタイミングクリティカルではないので配線を解除し、クリティカルネット $myCritNets が初に小の遅延で配線されるようにしています。その後、 route_design -preserve コマンドを使用してデザイン全体を配線しています。 -preserve オプションにより、 $myCritNets の配線が保持され、配線解除された u0/u1ネットは配線し直されます。


表 2-6 : 配線中のデザイン解析で使用されるコマンド

コマンド機能

report_route_status ネットの配線ステータスをレポートします。

report_timing パスエンドポイント解析を実行します。




第 3 章

配置、配線、およびロジックの変更

配置、配線、およびロジックの変更についてザイリンクス Vivado® Design Suite では、インプリメンテーションフローで配置、配線、およびロジックを変更するのにいくつかの方法があります。これらの方法を使用すると、配置、配線、および遅延を厳密に制御でき、ロジックをすばやく変更できます。

配置の変更Vivado ツールでは、配置セルが固定されているか (Fixed)、固定されていないか (Unfixed) が検出され、デザインの配置されたセルをどのように処理するかが判断されます。

固定セル

固定されたセルは、設計者が配置したか、制約ファイルからインポートされています。

• Vivado Design Suite では、このように配置されたセルは固定 (Fixed) として処理されます。

• 固定セルは、指示がない限り移動されません。

• 図 3-1 ではフリップフロップがオレンジ色 (デフォルト ) で表示されており、固定されていることがわかります。




第 3 章 : 配置、配線、およびロジックの変更

未固定セル

固定されていないセルは、 Vivado インプリメンテーションで place_design コマンドまたは適化コマンドの 1 つにより配置されたものです。

• Vivado Design Suite では、このように配置されたセルは未固定 (Unfixed) または配置は確定していないとして処理されます。

• これらのセルは、必要に応じて移動されます。

• 図 3-1 では LUT が青色 (デフォルト ) で表示されており、未固定であることがわかります。

LOC および BEL のどちらも固定できます。上図の配置では、次の制約が生成されます。

set_property BEL BFF [get_cells {fftEngine/control_reg_reg[1]}]set_property LOC SLICE_X1Y199 [get_cells {fftEngine/control_reg_reg[1]}]

LUT には配置制約は設定されていません。 LUT の配置は未固定であり、配置は XDC に含めるべきでないことを示しています。


図 3-1 : スライスに配置されたロジック





配置機能で配置されたロジックの固定

Vivado IDE の Vivado 配置で配置されたセルを固定するには、次の手順に従います。

1. セルを選択します。

2. 右クリックして [Fix Cells] をクリックします。

Tcl でセルの配置を固定するには、次のコマンドを使用します。

set_property is_bel_fixed TRUE [get_cells [list {fftEngine/control_reg_reg[1]_i_1}]]set_property is_loc_fixed TRUE [get_cells [list {fftEngine/control_reg_reg[1]_i_1}]]

Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 9] を参照するか、「<command> -help」と入力してください。

ロジックの手動での配置および移動

ロジックを手動で配置および移動できます。

• セルが既に配置されている場合、ドラッグして新しいロケーションにドロップします。

• セルが配置されていない場合は、次の手順に従います。

a. [Device] ビューでツールバーの [Cell Drag & Drop Modes] ボタンをクリックし、 [Create BEL Constraint Mode]をオンにします。

b. [Netlist] ビューまたは [Timing] ビューからロジックを [Device] ビューにドラッグします。

ロジックは、有効なロケーションに配置されます。

手動でのロジックの配置には時間がかかります。制約にセル名が使用されるので、制約はデザインの変更の影響を受けやすくなります。

配線の変更デザインの配線を変更は、 [Device] ビューから実行できます。個々のネットに対して配線の解除、配線、配線の固定を実行できます。

ネットに対して配線の解除、配線、配線の固定を実行するには、次の手順に従います。

1. [Device] ビューを開きます。

2. ネットを選択します。

° 未配線のネットは、赤色のフライラインで表示されます。

° 部分的に配線されたネットは、黄色で表示されます。

3. 右クリックして [Unroute]、 [Route]、または [Fix Routing] をクリックします。

• [Unroute] (配線の解除) および [Route] (配線) : 配線を再配線モードで起動し、ネットに対して操作を実行します。詳細は、第 2 章の 88 ページの「route_design」を参照してください。

• [Fix Routing] (配線の固定) : 配線し、配線データベースで固定とマークし、ネットのドライバーおよびロードのLOC および BEL を固定します。ネットを手動で配線する配線割り当てモードも使用できます。詳細は、「手動配線」を参照してください。

ヒント : ネット関連のコマンドはすべて、ネットのポップアップメニューから実行できます。





手動配線

手動配線を使用すると、ネットに特定の配線リソースを選択できます。これにより、信号の配線パスを完全に制御できます。手動配線では、 route_design は実行されません。配線は配線データベースで直接アップデートされます。

手動配線は、ネットの遅延を厳密に制御する場合に使用します。たとえば、ソース同期インターフェイスで、デバイスの受信レジスタまでの配線遅延の変動を小限に抑える場合などです。これには、レジスタおよび I/O に LOC および BEL 制約を設定し、ネットを手動配線することにより IOB からレジスタまでの配線遅延を制御します。

手動配線を実行するには、デバイスのインターコネクトアーキテクチャに関する詳細な知識が必要です。手動配線を実行する信号数を制限し、短い接続にのみ使用することをお勧めします。

手動配線での規則

手動配線では、次の規則に従ってください。

• ドライバーおよびロードに LOC 制約と BEL 制約が必要です。

• 手動配線では分岐は使用できませんが、分岐点から新しい手動配線を開始することにより分岐をインプリメントできます。

• LUT ロードのピンを固定する必要があります。

• ドライバーに接続されていないロードに配線する必要があります。

• 完全な接続のみが許容されます。アンテナは許容されません。

• 既存の固定されていない配線済みネットとオーバーラップさせることができます。手動配線が完了した後route_design を実行し、ネットのオーバーラップによる競合を解決してください。


図 3-2 : 配線の変更





配線割り当てモードの開始

配線割り当てモードを開始するには、次の手順に従います。


2. [Routing Resources] がオンになっていることを確認します。

3. ツールバーの [Options] ボタンをクリックし、 [Device Options] の [Layers] タブで [Unrouted Net] および [PartiallyRouted Net] をオンにします (図 3-3)。

,

4. 配線が必要なネットを選択します。

° 未配線のネットは、赤色のフライラインで表示されます。

° 部分的に配線されたネットは、黄色で表示されます。

5. 右クリックして [Enter Assign Routing Mode] をクリックします。

[Assign Routing: Target Load Cell Pin] ダイアログボックスが開きます。

6. 配線先のロードセルピンを選択します (オプション)。



図 3-3 : [Device Options] の [Layers] タブ





注記 : [Device] ビューに部分的に配線されたネットまたは未配線のネットを表示するには、 [Device Options] メニューで対応するレイヤーをオンにする必要があります (図 3-4)。

手動配線モードになりました。 [Device] ビューの横に [Routing Assignment] ウィンドウが表示されます (図 3-5)。


図 3-4 : [Device Options] プルアウトメニュー





[Routing Assignment] ウィンドウには、次の 3 つのセクションがあります。

[Options] セクション

[Options] セクション (図 3-6) では、 [Routing Assignment] ウィンドウの設定を制御します。

,

• [Number of hops] : 近隣ノードの配線ホップ数を指定します。この設定は、 [Neighbor Nodes] セクションに表示されるノードに影響します。1 より大きい値に設定すると、 [Neighbor Nodes] セクションに配線の後のノードのみが表示されます。

• [Maximum number of neighbors] : [Neighbor Nodes] セクションに表示される近隣ノードの大数を指定します。配線の後のノードのみが表示されます。

• [Allow overlap with unfixed nets] : 割り当て済み配線と既存の未固定配線のオーバーラップを許容するかどうかを指定します。固定配線の割り当て後、 route_design コマンドを実行してすべてのオーバーラップを解決する必要があります。

[Options] セクションはデフォルトでは非表示になっています。[Options] セクションを表示するには、[Show] をクリックします。


図 3-5 : [Routing Assignment] ウィンドウ


図 3-6 : [Routing Assignment] ウィンドウの [Options] セクション





[Assigned Nodes] セクション

[Assigned Nodes] には、既に配線が割り当てられているモードを示します。割り当済みの各ノードが 1 行に表示されます。

割り当て済みの配線は、[Device] ビューでオレンジ色で示されます。割り当て済みノードの間のギャップは、[AssignedNodes] セクションに GAP 行として表示されます。ギャップを自動配線するには、次の手順に従います。

1. [Assigned Nodes] セクションでネットギャップを右クリックします。

2. [Auto-route] をクリックします。

次の配線セグメントを割り当てるには、ギャップの前または後の割り当て済みノードを選択するか、 [Assigned Nodes]セクションの後のノードを選択します。

[Neighbor Nodes] セクション

選択したノードの近隣にある使用可能なノードを表示します。 [Device] ビューでは、選択されているノードが白で示されされ、使用可能な近隣のノードが白の点線で示されます (図 3-7)。

,X-Ref Target - Figure 3-7

図 3-7 : 配線セグメントの割り当て





配線ノードの割り当て

次の配線セグメントに割り当てるノードを決定したら、次のいずれかを実行します。

• [Neighbor Nodes] セクションでノードを右クリックし、 [Assign Node] をクリックします。

• [Neighbor Nodes] セクションでノードをダブルクリックします。

• [Device] ビューでノードをクリックします。

配線をノードに割り当てると、そのノードが [Assigned Nodes] セクションに表示され、 [Device] ビューでオレンジ色でハイライトされます。

ロードに到達するまで、またはギャップを含む配線を割り当てる準備ができるまで、ノードの割り当てを継続します。

配線ノードの割り当て解除

ノードの割り当てを解除するには、次の手順に従います。

1. [Routing Assignment] ウィンドウの [Assigned Nodes] セクションに移動します。

2. 割り当てを解除するノードを選択します。

3. 右クリックして [Remove] をクリックします。

ノードが割り当てから削除されます。

配線割り当ての確定

配線の割り当てを確定して配線割り当てモードを終了するには、次の操作を実行します。

[Routing Assignment] ウィンドウで [Assign Routing] ボタンをクリックします。

[Assign Routing] ダイアログボックス (図 3-8) が表示されます。このダイアログボックスで、割り当てられたノードを確認します。


図 3-8 : [Assign Routing] ダイアログボックス





配線割り当てのキャンセル

配線割り当てを確定できない場合は、次のいずれかの方法を使用して配線割り当てをキャンセルできます。

• [Routing Assignment] ウィンドウで [Exit Mode] をクリックします。

• [Device] ビューを右クリックして [Exit Assign Routing Mode] をクリックします。

配線を確定すると、ドライバーおよびロードの BEL および LOC も固定されます。

割り当て済みの配線の確認

• 割り当て済みの配線は、 [Device] で緑色の点線で示されます。

• 部分的に割り当てられた配線は、 [Device] で黄色の点線で示されます。

図 3-9 に、割り当て済み配線と部分的に割り当てられた配線の例を示します。


図 3-9 : 割り当て済みの配線および部分的に割り当てられた配線





LUT ロードのセル入力の固定

配線しようとしている LUT ロードの入力が、ほかの入力とスワップされていないことを確認する必要があります。これには、次の手順に従って LUT ロードのセル入力を固定します。


2. ロード LUT を選択します。

3. 右クリックして [Lock Cell Input Pins] をクリックします。

これに相当する Tcl コマンドは、次のとおりです。

set_property LOCK_PINS {NAME:BEL_PIN} <cell object>

分岐複数のロードを持つネットを配線する場合は、次の手順に従ってネットを配線します。

1. 96 ページの「配線割り当てモードの開始」の手順に従って 1 つのロードへの配線を割り当てます。

2. ネットのすべての分岐への配線を割り当てます。

図 3-10 に、 1 つのロードへの配線が割り当てられ、さらに 2 つのロードへの配線が必要なネットを示します。


図 3-10 : 分岐配線の割り当て





分岐への配線の割り当て

分岐に配線を割り当てるには、次の手順に従います。

1. [Device] ビューを表示します。

2. 配線するネットノードを選択します。

3. 右クリックして [Enter Assign Routing Mode] をクリックします。

[Target Load Cell Pin] ダイアログボックスが開き、すべてのロードが表示されます。

注記 : 配線が割り当てられているロードには、 [Routed] 列にチェックマークが示されています。

4. 配線するロードを選択します。


図 3-11 : [Target Load Cell Pin] ダイアログボックス (複数ロード )





5. [OK] をクリックします。 [Branch Start] ダイアログボックス (図 3-12) が開きます。

6. 選択したロードの配線を分岐するノードを選択します。


8. 100 ページの「配線ノードの割り当て」の手順に従います。

指定配線制約

固定された配線割り当ては、配線データベースに指定配線文字列として保存されます。指定配線文字列では、分岐はネストされた中かっこ ({ }) で示されます。

たとえば、図 3-13 に示すような配線があるとします。この配線では、さまざまなエレメントが次の表に示すように示されています。

この配線の簡略化された指定配線文字列は、次のようになります。

{A B { D E T } C { F G H I M N } {O P Q} R J K L S }

配線は B と C で分岐します。メインの配線は A B C R J K L S です。


図 3-12 : [Branch Start] ダイアログボックス

表 3-1 : 指定配線制約

エレメント表示方法

ドライバーとロードオレンジ色の矩形

ノード赤い線

スイッチボックス青い矩形






図 3-13 : 分岐配線の例





ロジックの変更読み取り専用でない論理オブジェクトのプロパティは、インプリメンテーション後に Vivado IDE または Tcl で変更できます。


[Device] ビューでオブジェクトのプロパティを変更するには、次の手順に従います。

1. オブジェクトを選択します。

2. [Properties] ビューの [Properties] タブでオブジェクトのプロパティを変更します。

変更可能なプロパティには、ブロック RAM の INIT、MMCM のクロックを変更するプロパティなどがあります。LUTオブジェクトの INIT を変更するためのダイアログボックスもあり、 LUT 論理式を指定して適切な INIT 値がツールにより設定されるようにすることができます。


図 3-14 : プロパティの変更





変更の保存

メモリ内でデザインに対して加えた変更を保存するには、デザインのチェックポイントを保存します。

割り当てはデザインにバックアノテートされないので、次回の実行で適用されるようにするには、割り当てを XDCに追加する必要があります。

プロジェクトモードで制約を制約ファイルに保存するには、 [File] → [Save Constraints] をクリックします。


図 3-15 : LUT 論理式の指定




付録 A

リモートホストおよび LSF の使用

リモート Linux ホストでの run の起動

概要

ザイリンクス Vivado® IDE では、複数の Linux ホストで同時に合成およびインプリメンテーション run を実行できます。これには、 LSF (Load Sharing Facility) を使用するか、手動でホストを設定します。

LSF を使用したリモートホストの設定方法は、 109 ページの「LSF を使用したリモートホストの設定」を参照してください。

リモートホストを手動で設定する方法は、 111 ページの「リモートホストの手動設定」を参照してください。

LSF について

LSF は、クラスターの複数の計算サーバー間でバッチジョブを投入、スケジュール、実行、監視、ワークロード制御するためのサブシステムです。 LSF を介して Vivado Design Suite で合成 run およびインプリメンテーションを実行するには、 bsub コマンドを使用します。

Linux およびリモートホストのサポート

リモートホストは、次の理由から Linux でのみサポートされます。

• Linux の方がセキュリティが優れている。

• Microsoft Windows システムにリモートシェル機能がない。

ジョブ投入アルゴリズムと SSH

ジョブ投入アルゴリズムは、Linux OS のサービスであるセキュアシェル (SSH) 内の Tcl パイプを使用したラウンドロビン形式でインプリメントされています。

推奨 : 複数の Linux ホストを手動で設定して Vivado IDE で run を起動する前に、リモート run を起動するたびにパスワードを入力しなくて済むように SSH を設定する必要があります。

SSH の設定方法は、 113 ページの「SSH の設定」を参照してください。




付録 A : リモートホストおよび LSF の使用

リモートホストの実行要件

リモート Linux ホストで合成およびインプリメンテーション run を実行する際の要件は、次のとおりです。

• Vivado ツールのインストールがログインシェルから使用できると想定されるので、 $XILINX_VIVADO および$PATH 環境変数を .cshrc/.bashrc セットアップスクリプトで正しく設定する必要があります。

手動設定では、ログイン時に .cshrc または .bashrc で Vivado が設定されていない場合、 [Run pre-launch script] を使用して、環境設定スクリプトをすべてのジョブ前に実行できます。

• Vivado IDE のインストールがリモートマシンの割り当てられたネットワークから表示できるようにする必要があります。 Vivado IDE がマシンのローカルディスクにインストールされている場合は、リモートマシンからは表示できない可能性があります。

• Vivado IDE のプロジェクトファイル (.xpr) およびディレクトリ (.dita および .runs) が、リモートマシンの割り当てられたネットワークから表示できるようにする必要があります。デザインデータがローカルディスクに保存されていると、リモートマシンからは表示できない可能性があります。

LSF を使用したリモートホストの設定

LSF 設定を使用してリモート Linux ホストで合成またはインプリメンテーションを実行できるように Vivado IDE を設定するには、次の手順に従います。

1. 次のいずれかを実行します。

° メインメニューから [Tools] → [Options] をクリックし、左側のペインで [Remote Hosts] をクリックします。

° [Launch Selected Runs] ダイアログボックスで [Configure LSF] をクリックします。

° [Create New Runs] ダイアログボックスの [Launch Options] ページで [Configure LSF] をクリックします。

次の図に、 [Launch Selected Runs] ダイアログボックスで LSF を使用する [Launch runs using LSF] オプションをオンにしたところを示します。

X-Ref Target - Figure A-1

図 A-1 : [Launch Selected Runs] ダイアログボックスでの LSF の設定





2. [Vivado Options] ダイアログボックスの [Remote Hosts] ページが開きます (図 A-2)。 [LSF Configuration] タブをクリックします。

3. (オプション) [Command line] で bsub コマンドのオプションを変更します。

デフォルトコマンドは次のとおりです。

bsub -R select[type=X86_64] -N -q medium

4. (オプション) [Test Connection] をクリックして LSF への接続をテストします。

これにより、特別な bsub プロシージャが実行され、次が確認されます。

- Vivado が LSF を介してジョブを投入できる。

- リモートホストが runs ディレクトリにアクセスできる。

注記 : run をキャンセルすると、通常は Vivado ツールから bkill コマンドがジョブ ID と共に送信されます。これが実行されない場合は、コマンドラインから手動で run をキャンセルできます。「bkill <jobID>」と入力します。


図 A-2 : [Vivado Options] ダイアログボックスの [Remote Hosts] ページ





リモートホストの手動設定

リモート Linux ホストで合成またはインプリメンテーションを実行できるように Vivado IDE を設定するには、次の手順に従います。

1. 次のいずれかを実行します。

° メインメニューから [Tools] → [Options] をクリックし、左側のペインで [Remote Hosts] をクリックします。

° [Launch Selected Runs] ダイアログボックスで [Configure Hosts] をクリックします。

° [Create New Runs] ダイアログボックスの [Launch Options] ページで [Configure Hosts] をクリックします。

次の図に、 [Launch Selected Runs] ダイアログボックスでリモートホストで run を実行する [Launch runs on remotehosts] オプションをオンにしたところを示します。


図 A-3 : [Launch Selected Runs] ダイアログボックスでのリモートホストの設定





2. [Vivado Options] ダイアログボックスの [Remote Hosts] ページが開きます (図 A-4)。 [Manual Configuration] タブをクリックし、現在定義されているリモート Linux ホストを表示します。

3. [Add] ボタンをクリックし、リモートサーバー名を入力します。

4. [Jobs] 列で、リモートマシンで同時実行に使用できるプロセッサの数を指定します。各 run は個別のプロセッサで実行されます。

5. [Enabled] チェックボックスをオン/オフにして、サーバーを使用するかどうかを指定します。このチェックボックスで、選択した run にどのサーバーを使用するかを指定できます。

6. (オプション) [Launch jobs with] で run を実行する際に使用するリモートアクセスコマンドを変更します。デフォルトコマンドは次のとおりです。

ssh -q -o BatchMode=yes

重要 : このフィールドを変更する場合は、細心の注意を払ってください。たとえば、 BatchMode =yes を削除すると、セキュアシェルでパスワードのプロンプトが表示されるため、プロセスが停止していまいます。

7. (オプション) [Run pre-launch script] をオンにて、 run の起動前に実行するスクリプトを定義します。ログイン時に Vivado IDE が設定されていない場合に、このオプションを使用してホスト環境を設定するスクリプトを実行します。


図 A-4 : リモートホストの設定





8. (オプション) [Run post-completion script] をオンにして、結果を移動またはコピーするなど、 run の完了後に実行するカスタムスクリプトを定義します。

9. (オプション) [Send email to] をオンにし、 run の完了時に電子メールが送信されるようにします。各ジョブの後に通知を送信するか ([After each Job])、すべてのジョブの完了後に通知を送信するか ([After all jobs]) を選択できます。

10. 設定が終了したら、 [OK] をクリックします。

11. 1 つまたは複数のホストを選択します。

12. [Test] をクリックします。

サーバーが使用可能かどうか、コンフィギュレーションが正しく設定されているかが確認されます。

推奨 : ホストで run を実行する前に、各ホストをテストして正しく設定されていることを確認してください。

リモートホストの削除

リモートホストを削除するには、次の手順に従います。

1. リモートホストを選択します。

2. [Remove] をクリックします。

SSH の設定SSH は、 Linux ターミナルまたはシェルで次のコマンドを入力して設定します。

注記 : これは一度設定しておけば、繰り返し設定する必要はありません。

1. Linux ターミナルまたはシェルで次のコマンドを実行し、プライマリコンピューターでパブリックキーを生成します。必須ではありませんが、セキュリティ保護のため、プライベートキーを入力し、記憶しておくことをお勧めします。

ssh -keygen -t rsa

2. パブリックキーをリモートマシンの authorized_keys ファイルに追加します。 remote_server をホスト名に変更します。

cat ~/.ssh/id_rsa.pub | ssh remote_server “cat - >> ~/.ssh/authorized_keys”

3. 次のコマンドを実行して、プライベートキーのパスフレーズの入力をプロンプトし、キー転送を有効にします。

ssh -add

これで、どのリモートマシンでもパスワードを入力せずに使用できます。新しいマシンに初めてアクセスする場合は、パスワードを入力するよう求められますが、次回からは入力する必要はありません。

ヒント : 毎回パスワードの入力を求められる場合は、システム管理者に連絡してください。





付録 B

ISE コマンドと Vivado コマンドの対照表

Tcl コマンドとオプションVivado® インプリメンテーションには、ISE® ツールコマンドと 1 対 1 で対応するコマンドラインオプションがいくつかあります。

表 B-1 に、 ISE ツールコマンドラインオプションと、同等の Vivado Design Suite Tcl コマンドおよび Tcl コマンドオプションを示します。


表 B-1 : ISE コマンドと Vivado コマンドの対照表

ISE コマンド Vivado Tcl コマンドとオプション

ngdbuild -p partname link_design -part partname

ngdbuild -a (パッドを挿入) synth_design -no_iobuf (バッファーを挿入しない)

ngdbuild -u (未展開のブロックを許可) デフォルトでイネーブル、クリティカル警告メッセージを表示

ngdbuild -quiet link_design -quiet

map -detail opt_design -verbose

map -lc auto place_design でデフォルトでイネーブル

map -logic_opt opt_design および phys_opt_design

map -mt place_design を自動的にマルチスレッドで実行 (7 ページの「Vivado ツールでのマルチスレッド」を参照)

map -ntd place_design -non_timing_driven

map -power power_opt_design

map -u link_design -mode out_of_context、opt_design -retarget (定数の伝搬をスキップしてスイープ)

par -mt route_design を自動的にマルチスレッドで実行 (7 ページの「Vivado ツールでのマルチスレッド」を参照)

par -k route_design を常に再配線モードで実行

par -nopad Vivado ツールでは -nopad の動作がデフォルト (PAR で生成されていた PAD ファイルを取得するには report_io コマンドを使用)

par -ntd route_design -no_timing_driven



付録 C

インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定

インプリメンテーションのカテゴリI

インプリメンテーションストラテジの説明

表 C-1 : インプリメンテーションのカテゴリ

カテゴリ目的

Performance (パフォーマンス) デザインパフォーマンスを向上します。

Area (エリア) LUT 数を削減します。

Power (消費電力) 消費電力適化を実行します。

Flow (フロー ) フロー手順を変更します。

Congestion (密集) 密集および関連の問題を低減します。

表 C-2 : インプリメンテーションストラテジの説明

インプリメンテーションストラテジ名 [Description]

Vivado Implementation Defaults 適度な実行時間でタイミングクロージャが満たされるようにします。

Performance_Explore 結果を向上するため、適化、配置、配線に複数のアルゴリズムを使用します。

Performance_ExplorePostRoutePhysOpt Peformance_Explore と同様ですが、配線後に物理適化 (phys_opt_design) を -directive を Explorer に設定して実行します。

Performance_RefinePlacement 配置後の適化のエフォートを増加し、配線でのタイミングの緩和をディスエーブルにします。

Performance_WLBlockPlacement ブロック RAM および DSP を配置する際にタイミング制約を無視し、ワイヤ長を使用します。

Performance_WLBlockPlacementFanoutOpt ブロック RAM および DSP を配置する際にタイミング制約を無視してワイヤ長を使用し、ファンアウトの大きいドライバーの複製を積極的に実行します。

Performance_LateBlockPlacement 終的な配置段階まで、ブロック RAM と DSP におおよその配置を使用します。全体的な配置が向上することがあります。




付録 C : インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の設定

Performance_NetDelay_high 遅延を少なめに予測する代わりに、距離の長いファンアウトの大きい接続の遅延コストを増加します。 Performance_NetDelay_high では増加量がも大きくなります。

Performance_NetDelay_medium 遅延を少なめに予測する代わりに、距離の長いファンアウトの大きい接続の遅延コストを増加します。 Performance_NetDelay_mediumでは増加量が中程度になります。

Performance_NetDelay_low 遅延を少なめに予測する代わりに、距離の長いファンアウトの大きい接続の遅延コストを増加します。Performance_NetDelay_low では増加量がも小さくなります。

Performance_ExploreSLLs 全体的なタイミングスラックを向上するため、 SLR の再割り当てを試行します。

Performance_Retiming phys_opt_design のリタイミングに加えて、追加の配置適化を実行し、配線遅延コストを大きくします。

Area_Explore LUT 数を削減するため、複数の適化アルゴリズムを使用します。

Power_DefaultOpt 消費電力を削減するため、消費電力適化 (power_opt_design) を実行します。

Flow_RunPhysOpt Vivado Implementation Defaults に物理適化 (phys_opt_design) を実行します。

Flow_RunPostRoutePhysOpt Vivado Implementation Defaults と同様ですが、配線の前後に物理適化(phys_opt_design) を -directive を Explorer に設定して実行します。

Flow_RuntimeOptimized 各インプリメンテーション段階で、デザインパフォーマンスよりも実行時間を短縮することを優先します。物理適化 (phys_opt_design)はディスエーブルになります。

Flow_Quick すべての適化およびタイミングドリブンの処理をディスエーブルにし、配置配線のみを実行します。使用率を予測する際に有益です。

Congestion_SpreadLogic_high 密集した領域が作成されないように、ロジックをデバイス全体に分散します。 Congestion_SpreadLogic_high では分散度がも高くなります。

Congestion_SpreadLogic_medium 密集した領域が作成されないように、ロジックをデバイス全体に分散します。 Congestion_SpreadLogic_medium では分散度が中程度になります。

Congestion_SpreadLogic_low 密集した領域が作成されないように、ロジックをデバイス全体に分散します。Congestion_SpreadLogic_low では分散度がも低くなります。

Congestion_SpreadLogicSLLs ロジックが SLR すべてに分散され、 SLR 内で密集した領域が作成されないように SLL を割り当てます。

Congestion_BalanceSLLs 2 つの SLR で偏って多数の SLL が必要とならないように SLL を割り当て、 SLR での密集を低減します。

Congestion_BalanceSLRs 各 SLR のエリアが同等になるように分割し、 SLR 内で密集した領域が作成されないようにします。

Congestion_CompressSLRs SLR の使用率が高くなるように分割し、全体的な SLL 数を削減します。

表 C-2 : インプリメンテーションストラテジの説明 (続き)

インプリメンテーションストラテジ名 [Description]





インプリメンテーションストラテジで使用される opt_design および place_design の -directive の設定

重要 : 配置の -directive オプションは現在のところ UltraScale™ デバイスアーキテクチャではサポートされていません。配置で -directive オプションを指定しても無視され、デフォルト設定で配置が続行されます。

表 C-3 : インプリメンテーションストラテジで使用される opt_design および place_design の -directive の設定

ストラテジ opt_design -directive place_design -directive

Performance_Explore Explore Explore

Performance_ExplorePostRoutePhysOpt Explore Explore

Performance_RefinePlacement デフォルト ExtraPostPlacementOpt

Performance_WLBlockPlacement デフォルト WLDrivenBlockPlacement

Performance_WLBlockPlacementFanoutOpt デフォルト WLDrivenBlockPlacement

Performance_LateBlockPlacement デフォルト LateBlockPlacement

Performance_NetDelay_high デフォルト ExtraNetDelay_high

Performance_NetDelay_medium デフォルト ExtraNetDelay_medium

Performance_NetDelay_low デフォルト ExtraNetDelay_low

Performance_ExploreSLLs デフォルト SSI_ExtraTimingOpt

Performance_Retiming デフォルト ExtraPostPlacementOpt

Area_Explore ExploreArea デフォルト

Power_DefaultOpts デフォルトデフォルト

Flow_RunPhysOpt デフォルトデフォルト

Flow_RunPostRoutePhysOpt デフォルトデフォルト

Flow_RuntimeOptimized RuntimeOptimized RuntimeOptimized

Flow_Quick デフォルト Quick

Congestion_SpreadLogic_high デフォルト SpreadLogic_high

Congestion_SpreadLogic_medium デフォルト SpreadLogic_medium

Congestion_SpreadLogic_low デフォルト SpreadLogic_low

Congestion_SpreadLogicSLLs デフォルト SSI_SpreadSLLs

Congestion_BalanceSLLs デフォルト SSI_BalanceSLLs

Congestion_BalanceSLRs デフォルト SSI_BalanceSLRs

Congestion_CompressSLR デフォルト SSI_HighUtilSLRs





インプリメンテーションストラテジで使用される phys_opt_design および route_design の -directive の設定表 C-4 : インプリメンテーションストラテジで使用される phys_opt_design および route_design の -directive の設定

ストラテジ phys_opt_design -directive route_design -directive

Performance_Explore Explore Explore

Performance_ExplorePostRoutePhysOpt Explorea

a. Explore は配置後および配線後の phys_opt_design 両方に適用されます。

Explore

Performance_RefinePlacement デフォルト NoTimingRelaxation

Performance_WLBlockPlacement AlternateReplication MoreGlobalIterations

Performance_WLBlockPlacementFanoutOpt AggressiveFanoutOpt HigherDelayCost

Performance_LateBlockPlacement AlternateReplication HigherDelayCost

Performance_NetDelay_high デフォルト AdvancedSkewModeling

Performance_NetDelay_medium デフォルト AdvancedSkewModeling

Performance_NetDelay_low デフォルト AdvancedSkewModeling

Performance_ExploreSLLs デフォルト NoTimingRelaxation

Performance_Retiming AlternateFlowWithRetiming route_design

HigherDelayCost

Area_Explore デフォルトデフォルト

Power_DefaultOpts デフォルトデフォルト

Flow_RunPhysOpt Explore デフォルト

Flow_RuntimeOptimized ディスエーブル RuntimeOptimized

Flow_RunPostRoutePhysOpt Exploreb

b. Explore は配置後および配線後の phys_opt_design 両方に適用されます。

デフォルト

Flow_Quick ディスエーブル Quick

Congestion_SpreadLogic_high AggressiveFanoutOpt MoreGlobalIterations

Congestion_SpreadLogic_medium AggressiveFanoutOpt HigherDelayCost

Congestion_SpreadLogic_low デフォルト NoTimingRelaxation

Congestion_SpreadLogicSLLs デフォルト NoTimingRelaxation

Congestion_BalanceSLLs デフォルト NoTimingRelaxation

Congestion_BalanceSLRs デフォルトデフォルト

Congestion_CompressSLR デフォルトデフォルト




付録 D

その他のリソースおよび法的通知

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

ソリューションセンターデバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。デザインアシスタント、アドバイザリ、トラブルシューティングのヒントなどが含まれます。

参考資料

Vivado® Design Suite ユーザーガイド

1. 『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892)

2. 『Vivado Design Suite ユーザーガイド : 階層デザイン』 (UG905)

3. 『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893)

4. 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896)

5. 『Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用』 (UG894)

6. 『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895)

7. 『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994)

8. 『Vivado Design Suite ユーザーガイド : 合成』 (UG901)

9. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903)

10. 『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906)

11. 『Vivado Design Suite ユーザーガイド : 消費電力の解析および適化』 (UG907)

12. 『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908)


http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug905-vivado-hierarchical-design.pdf


http://japan.xilinx.com/support/solcenters.htm

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug892-vivado-design-flows-overview.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug893-vivado-ide.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug894-vivado-tcl-scripting.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug895-vivado-system-level-design-entry.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug994-vivado-ip-subsystems.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug901-vivado-synthesis.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug903-vivado-using-constraints.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug906-vivado-design-analysis.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug907-vivado-power-analysis-optimization.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug908-vivado-programming-debugging.pdf

http://japan.xilinx.com/support/

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2013.4;d=ug894-vivado-tcl-scripting.pdf


付録 D : その他のリソースおよび法的通知

その他の Vivado Design Suite 関連の資料

13. 『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472)

14. 『UltraScale アーキテクチャクロッキングリソースユーザーガイド』 (UG572)

15. 『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)

16. 『ISE から Vivado Design Suite への移行ガイド』 (UG911)

17. 『Vivado Design Suite チュートリアル : デザインフローの概要』 (UG888)

Vivado Design Suite の資料サイト

18. Vivado Design Suite 資料ページ

Vivado Design Suite ビデオチュートリアル

19. Vivado Design Suite ビデオチュートリアルページ

法的通知The information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products. To the maximum extentpermitted by applicable law: (1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES ANDCONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY,NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort,including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connectionwith, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage(including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if suchdamage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct anyerrors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute,or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of Xilinx’s limited warranty,please refer to Xilinx’s Terms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and supportterms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any applicationrequiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx’sTerms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos.

© Copyright 2012-2014 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brandsincluded herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners.

本資料は英語版 (v2014.1) を翻訳したもので、内容に相違が生じる場合には原文を優先します。

資料によっては英語版の更新に対応していないものがあります。

日本語版は参考用としてご使用の上、新情報につきましては、必ず新英語版をご参照ください。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] までお知らせください。

いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりま

せん。あらかじめご了承ください。



http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug835-vivado-tcl-commands.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?v=UltraScale;t=user+guide

http://www.xilinx.com/legal.htm#tos

http://japan.xilinx.com/cgi-bin/docs/ndoc?v=7%20Series;t=user+guide

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug911-vivado-migration.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;d=ug888-vivado-design-flows-overview-tutorial.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.1;t=vivado+docs

http://japan.xilinx.com/cgi-bin/docs/ndoc?v=7%20Series;t=user+guide

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=vivado+videos

http://www.xilinx.com/legal.htm#tos

mailto:[email protected]

mailto:[email protected]


Vivado Design Suite ユー ザー ガイド - Xilinx...インプリメンテーション...

Documents

Transcript of Vivado Design Suite ユー ザー ガイド - Xilinx...インプリメンテーション...

Vivado Design Suite ユーザーガイド - Xilinx...インプリメンテーション...

Transcript of Vivado Design Suite ユーザーガイド - Xilinx...インプリメンテーション...