Vivado Design Suite - XilinxTcl API を使用すると、すべてのデザイン...

Vivado Design Suite ユーザーガイド

インプリメンテーション

UG904 (v2017.3) 2017 年 10 月 27 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

UG904 (v2017.4) 2017 年 12 月 20 日

インプリメンテーション 2UG904 (v2017.3) 2017 年 10 月 27 日 japan.xilinx.com

改訂履歴

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

日付バージョン改訂内容

2017 年 10 月 27 日 2017.3 第 2 章:

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

• 「synth_design の構文」、「link_design の構文」、「opt_design の構文」、「phys_opt_design の構文」、および「iphys_opt_design」をアップデート。

• 「キャリー適化」をアップデート。

• 「シフトレジスタの適化 (デフォルト )」に新しい適化を追加。

• 表 2-6 および「使用可能な物理適化」に「立ち下がりエッジレジスタの挿入」の情報を追加。

• 「-directive オプションの使用」を RuntimeOptimized の情報でアップデート。

• 「インクリメンタルコンパイル」に Quick 指示子の情報を追加。

• 「report_incremental_reuse コマンドの使用」をアップデート。

付録 C:

• 新しいセクション「特定リリースのストラテジの表示」を追加。

2017 年 10 月 10 日 2017.1 第 2 章: 翻訳のエラーを修正。

2017 年 5 月 9 日 2017.1 Vivado IDE の新しいルックアンドフィールに基づいてアップデート。

第 2 章:

• 「非プロジェクトモードでのインプリメンテーションの実行」に関連の Tcl コマンドを追加。

• 「非プロジェクトモードのサンプルスクリプトでの主要な手順」に link_design のオプションに関する情報を追加。

• 「キャリー適化」、「等価ドライバーの統合」、「シフトレジスタの適化 (デフォルト )」を追加。表 2-3 および表 2-4 を関連情報でアップデート。

• 「-debug_log および -verbose オプションの使用」をアップデート。

• 「-fanout_opt オプションの使用」および「-no_bufg_opt オプションの使用」を追加。

• 「SLR をまたぐパスの適化」を追加し、表 2-6 を関連情報でアップデート。

• 「phys_opt_design の構文」をアップデート。

• 「高再利用モードと低再利用モード」を追加。

• 「インクリメンタル配置配線の実行」をアップデートし、「report_incremental_reuse コマンドの使用」を追加。

• 「Pblock 競合の例」を追加。

• 「タイミングレポート」のレポートをアップデート。

第 3 章:

• 「未固定セル」で制約をアップデート。

• 「使用例 3: タイミングを向上するためのパイプライン段の追加」で Tcl スクリプトをアップデート。

付録 C:

• 表 C-2、表 C-3、および表 C-4 に新しいストラテジ Performance_EarlyBlockPlacement を追加。

• 「特定リリースの -directive 値の表示」を追加。

UG904 (v2017.4) 2017 年 12 月 20 日

2017/12/20: Vivado® Design Suite 2017.4 リリース。2017.3 リリースから内容の変更なし。

https://japan.xilinx.com

https://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%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=2017.4&docPage=2

目次

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

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

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

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

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

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

第 2 章 : デザインのインプリメンテーション非プロジェクトモードでのインプリメンテーションの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

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

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

インプリメンテーション run の実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

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

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

インプリメンテーションコマンドについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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

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

ロジック適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

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

配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

物理適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

配線 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

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

第 3 章 : インプリメンテーション結果の解析と表示インプリメンテーション run の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

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

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

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

インプリメンテーション結果の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Vivado ECO フロー. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

付録 A : リモートホストおよび LSF の使用リモート Linux ホストでの run の実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

SSH の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

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

インプリメンテーション 3UG904 (v2017.3) 2017 年 10 月 27 日 japan.xilinx.comUG904 (v2017.4) 2017 年 12 月 20 日



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

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

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

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

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

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

Documentation Navigator およびデザインハブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

トレーニングリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

お読みください: 重要な法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171




第 1 章

インプリメンテーションの準備

Vivado インプリメンテーションプロセスについて

ザイリンクス Vivado® Design Suite では、次のようなさまざまなデザインソースから UltraScale™ FPGA およびザイリ

ンクス 7 シリーズ FPGA デザインをインプリメンテーションできます。

• RTL デザイン

• ネットリストデザイン

• IP 中心のデザインフロー

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

Vivado インプリメンテーションは、デザインの論理制約、物理制約、タイミング制約を満たしながらネットリスト

をデバイスリソースに配置配線するためのすべての段階を含みます。

Vivado ツールでサポートされるデザインフローの詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの

概要』 (UG892) [参照 1] を参照してください。




第 1 章: インプリメンテーションの準備

SDC および XDC 制約のサポート

Vivado インプリメンテーションは、タイミングドリブンフローです。デザインの要件および制限を指定するのに、

業界標準の Synopsys デザイン制約 (SDC) とザイリンクスデザイン制約 (XDC) がサポートされます。

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

Vivado Design Suite のインプリメンテーションプロセスでは、論理ネットリストおよび制約が配置配線済みデザイン

に変換され、ビットストリームを生成できるようにします。インプリメンテーションプロセスには、次のサブプロ

セスがあります。

1. デザインの適化:

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

2. デザインの消費電力適化 (オプション):

ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを適化します。

3. デザインの配置:

デザインをターゲットザイリンクスデバイスに配置します。

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

配置後に消費電力を削減するよう追加の適化を実行します。

5. 配置後のデザインの物理適化 (オプション):

配置に基づく見積もりタイミングを使用してロジックおよび配置を適化します。ファンアウトの大きいドラ

イバーの複製も含まれます。

6. デザインの配線:

デザインをターゲットザイリンクスデバイスに配線します。

X-Ref Target - Figure 1-1

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





7. 配線後のデザインの物理適化 (オプション):

配線後の実際の遅延を使用して、ロジック、配置、および配線を適化します。

8. ビットストリームの生成:

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

ションの後にビットストリームを生成します。

ビットストリーム生成の詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参

照 12] のこのセクションを参照してください。

注記: Vivado Design Suite では、デザインの一部をインプリメントしてパフォーマンスを見積もるモジュール解析が

サポートされています。このフローでは、 I/O が過剰に使用されないようにするため、 I/O バッファーは挿入されま

せん。詳細は、『Vivado Design Suite ユーザーガイド : 階層デザイン』 (UG905) [参照 2] を参照してください。

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

マルチプロセッサシステムでは、 DRC レポート、スタティックタイミング解析、配置、配線などのプロセスを高速

化するため、マルチスレッドが使用されます。同時に使用される大スレッド数は、プロセッサの数、タスクに

よって異なります。タスクによって使用される大スレッド数は、次のとおりです。

• DRC レポート : 8

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

• 配置: 8

• 配線: 8

• 物理適化: 8

同時に実行可能なスレッドのデフォルト大数は、 OS によって異なります。 Windows システムでは 2 で、 Linux シ

ステムではデフォルトは 8 です。この値は、 general.maxThreads というパラメーターを使用して変更できます。

制限を変更するには、次の Tcl コマンドを使用します。

Vivado% set_param general.maxThreads <new limit>

<new limit> に有効な値は、 1 ～ 8 の整数値です。

Windows システムでの Tcl 例:

Vivado% set_param general.maxThreads 2

この場合、プロセッサ数または実行されるタスクにかかわらず、すべてのタスクで使用されるスレッドの大数は 2

です。システムに 8 個以上のプロセッサがある場合、タスクで使用される大スレッド数を 8 に設定できます。

Vivado% set_param general.maxThreads 8

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

• プロセッサの大数

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

• 一般制限スレッド数



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug908-vivado-programming-debugging.pdf;a=xGeneratingTheBitstream



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

Vivado Design Suite には、 Tcl API が含まれています。 Tcl API を使用すると、すべてのデザインフローをスクリプト

で実行でき、デザインフローを要件に合わせてカスタマイズできます。

注記: Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 18] を参照する

か、「<command> -help」と入力してください。

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

Vivado Design Suite ではさまざまなデザインフローがあり、多種のデザインソースがサポートされています。ザイリ

ンクスデバイスにダウンロード可能なビットストリームを生成するには、インプリメンテーションを実行する必要

があります。

インプリメンテーションは、論理ネットリストをターゲットザイリンクスデバイスの物理的なアレイにマップする

ための一連の手順を指します。具体的には次が実行されます。

• ロジック適化

• ライブラリセルの配置

• セル間の接続の配線

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

Vivado Design Suite では、インプリメンテーションをプロジェクトファイルを使用して (プロジェクトモード )、また

はプロジェクトファイルを使用せずに (非プロジェクトモード ) 実行できます。

プロジェクトモード

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

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

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

• デザインフロー全体を通したプロジェクトステータスの監視。

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

プロジェクトモードでは、ディスク上にディレクトリ構造が作成され、それを利用してデザインソース、 run の結

果およびレポート、プロジェクトステータスが管理されます。

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

れるプロジェクトインフラストラクチャが必要です。

また、プロジェクトモードでは、デザインフローの主要な段階のチェックポイントファイルが、自動的にローカル

プロジェクトディレクトリに保存されます。

プロジェクトモードでインプリメンテーションを実行するには、 IDE で [Run Implementation] をクリックするか、 Tcl

コマンドで launch_runs を使用します。 Vivado Design Suite でのプロジェクトの使用に関する詳細は、『Vivado

Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 1] のこのセクションを参照してください。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug892-vivado-design-flows-overview.pdf;a=xUsingProjectMode



Flow Navigator

Vivado 統合設計環境 (IDE) を使用すると、完全なデザインフローを実行できます。 Vivado IDE には、 Flow Navigator

というフローを制御するインターフェイスがあります。

Flow Navigator は Vivado Design Suite のメインウィンドウの左側に表示され、ここからデザインおよび IP を作成、イ

ンプリメント、および検証できます。デザインフローを簡略化するため、インプリメンテーションプロセス全体を

コマンドをクリックするだけで実行できます。図 1-2 に、 Flow Navigator の [Implementation] セクションを示します。

重要: このガイドでは、インプリメンテーション以外の Vivado IDE の詳細は説明しません。デザインフロー全体に

関連する Vivado IDE の詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] を参照し

てください。

非プロジェクトモード

プロジェクトファイルおよびローカルディレクトリを作成せずに、メモリ内のデザインで作業することも可能で

す。プロジェクトファイルを使用しないコンパイル形式のフローは、非プロジェクトモードと呼ばれます。ソース

ファイルおよびデザイン制約は、現在の場所からメモリに読み込みます。インメモリデザインでデザインフローを

実行する際、中間ファイルが記述されることはありません。

非プロジェクトモードでは、各インプリメンテーション Tcl コマンドを適切なオプションと共に使用し、各段階を

個別に実行する必要があります。

変更を保存したり段階を再実行したりする必要なく、デザインに変更を加え、デザインフローを進めていくことが

できます。デザインフローのどの段階でも、レポートを生成したり、デザインチェックポイント (.dcp) を保存し

たりできます。

重要: 非プロジェクトモードでは、 Vivado デザインツールを終了すると、インメモリデザインは失われます。その

ため、合成、配置、配線などの主な段階が終了したら、デザインチェックポイントを保存することをお勧めします。


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





デザインチェックポイントは、プロジェクトモードおよび非プロジェクトモード両方で保存できます。デザイン

チェックポイントを開くことができるのは、非プロジェクトモードのみです。

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

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

IDE および Tcl API は、プロジェクトモードおよび非プロジェクトモード両方で使用できます。

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

できない機能を示します。

• Flow Navigator

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

• IP カタログ

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

• [Design Runs] ウィンドウ

• [Messages] ウィンドウ

• [Reports] ウィンドウ

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

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

• opt_design

• power_opt_design (オプション)

• place_design

• phys_opt_design (オプション)

• route_design

• phys_opt_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 コマンドを使用してデザインを読み込みます。

非プロジェクトモードでは、デザインチェックポイント (.dcp) を使用することもできます。チェックポイントを

開くと、デザインが読み込まれてそのチェックポイントの状態が復元されます。配置および配線データが含まれる

場合もあります。これにより、配線済みデザインを読み込んで配線を変更したり、配置済みデザインを読み込んで、

異なるオプションを使用して配線を複数回実行するなど、再配線インプリメンテーションフローを実行できます。

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

Vivado Design Suite では、ネットリストデザインがサポートされており、ザイリンクスツールまたはサードパーティ

ツールで合成済みのネットリストをインポートできます。サポートされるネットリストフォーマットは、次のとお

りです。

• 構造 Verilog

• 構造 SystemVerilog

• EDIF

• ザイリンクス NGC

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

×

重要: Vivado Design Suite では、 UltraScale デバイスに対して NGC フォーマットのファイルはサポートされていません。

Vivado Design Suite で IP を再生成し、ネイティブ出力ファイルを使用することをお勧めします。または、 NGC2EDIF

コマンドを使用して NGC ファイルを EDIF に変換し、インポートすることもできます。今後は XST で生成された

NGC フォーマットではなくネイティブ Vivado IP を使用することをお勧めします。





重要: プロジェクトモードまたは非プロジェクトモードで 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 Run] をクリックし

ます。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug896-vivado-ip.pdf;a=xAddingExistingIPToAProject



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

合成前にデザインに IP をインポートする方法の詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』


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

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

タイミング制約の 2 種類があります。

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

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

• パッケージピンの配置。

• ブロック RAM、 DSP、 LUT、フリップフロップなど、セルの絶対または相対配置。

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

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

タイミング制約

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

タイミング制約を設定しない場合、デザインがワイヤの長さおよび配線の密集度にのみ基づいて適化され、デザ

インパフォーマンスが評価されたり向上したりすることはありません。

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

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

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




https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug896-vivado-ip.pdf;a=xCreatingAnIPCustomization

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug911-vivado-migration.pdf;a=xMigratingUCFConstraintsToXDC



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

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

は Tcl ファイルに記述されたデザイン制約が含まれます。

制約セットの構造

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

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

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

• マスター制約ファイル

• 制約の変更を含める新しい制約ファイル

• 複数の制約セット

ヒント : 制約を機能に応じて別の制約ファイルに分けておくと、制約ストラテジ全体がわかりやすくなり、タイミン

グおよびインプリメンテーションを変更しやすくなります。

複数の制約セット

プロジェクトに複数の制約セットを作成できます。複数の制約セットを作成すると、さまざまなインプリメンテー

ション run で制約を試行できます。

たとえば、合成とインプリメンテーションにそれぞれ別の制約セットを指定できます。この 2 つの制約セットを使

用して、合成、シミュレーション、インプリメンテーションで異なる制約を試行できます。

デザイン制約を複数の制約セットに含めておくと、次のような利点があります。

• 同じプロジェクトで別のザイリンクスデバイスをターゲットとして設定できます。別のターゲットデバイスを

使用する場合は、別の物理制約およびタイミング制約が必要になる場合があります。

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

制約を厳しくしたりできます。

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

ます。

ヒント : タイミング制約を検証するには、合成済みデザインで report_timing_summary コマンドを実行します。インプ

リメンテーションの前に、問題のある制約を修正してください。

配置配線に影響する制約の定義および制約での作業の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』




https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug903-vivado-using-constraints.pdf;a=xPhysicalConstraints



制約を 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) [参照 19] を参照して

ください。

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

Vivado Design Suite では、物理デザインデータベースに配置配線情報が保存されます。デザインチェックポイント

ファイル (.dcp) を使用すると、デザインフローの主要な段階でこの物理データベースを保存および復元できます。

チェックポイントは、フローの特定の地点におけるデザインのスナップショットです。

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

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

• デザイン制約

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

チェックポイントデザインに対しては、 Tcl コマンドを使用してデザインフローの残りの段階を実行できます。新

しいデザインソースを使用して変更することはできません。

重要: プロジェクトモードでは、デザインフローの進行に応じて、 Vivado デザインツールにより自動的にチェック

ポイントが保存および復元されます。非プロジェクトモードでは、デザインフローの適切な段階でユーザーが

チェックポイントを保存する必要があります。保存しないと、メモリ内のデザインは失われます。

チェックポイントファイルの保存フローの任意の段階におけるデザインデータベースのスナップショットを保存するには、 [File] → [Write Checkpoint]

をクリックします。これにより、拡張子が .dcp のファイルが作成されます。

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



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug903-vivado-using-constraints.pdf;a=xDefiningRelativelyPlacedMacros

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug903-vivado-using-constraints.pdf;a=xDefiningRelativelyPlacedMacros



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

デザインチェックポイントが別のインメモリデザインとして開きます。

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




第 2 章

デザインのインプリメンテーション

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

非プロジェクトモードで合成済みデザインまたはネットリストをターゲットのザイリンクスデバイスにインプリメ

ントするには、インプリメンテーションのサブプロセスに対応する 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) [参


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

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

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

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

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





第 2 章: デザインのインプリメンテーション

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

次に、非プロジェクトモードでインプリメンテーションを実行するスクリプト例を示します。スクリプト名が

run.tcl である場合、 Tcl シェルに「source run.tcl」と入力してスクリプトを呼び出します。

注記: read_xdc ステップでは、 XDC ファイルから XDC 制約が読み出され、制約がデザインオブジェクトに適用さ

れます。このため、 XDC 制約が目的のデザインオブジェクトに必ず適用されるようにするには、 read_xdc の前

に、すべてのネットリストファイルを Vivado に読み込んで link_design を実行しておく必要があります。

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 using the default directive 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_design -directive Defaultwrite_checkpoint post_place.dcp

# Step 6: Route the design with the AdvancedSkewModeling directive. For more information # on router directives type 'route_design -help' in the Vivado Tcl Console route_design -directive AdvancedSkewModeling

# 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





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

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

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

• 「手順 2: インメモリデザインの構築」

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

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

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

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

• 「手順 7: 必須レポートの生成」

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

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

read_edif コマンドを使用して EDIF ネットリストデザインソースを読み込みます。非プロジェクトモードでは、

RTL デザインフローもサポートされています。その場合、ソースファイルを読み込んでインプリメンテーションの

前に合成を実行します。

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

ます。

read_* Tcl コマンドは非プロジェクトモードで使用するコマンドで、ディスク上のファイルを読み込んでインメモ

リデザインを構築します。ファイルがコピーされたり、ファイルの依存関係が作成されることはありません。

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

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

ます。

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

link_design コマンドを使用してデザインのインメモリ表示を構築します。このコマンドは、ツールに読み込ま

れたネットリストベースのソースファイルをザイリンクスのデバイス情報と結合して、メモリ内にデザインデータ

ベースを作成します。

link_design には、 2 つの重要なオプションがあります。

• -part: ターゲットデバイスを指定します。

• -top: インプリメンテーション用の上位デザインを指定します。上位ネットリストが EDIF で、 -top オプ

ションを指定しない場合は、 EDIF ネットリストに含まれる上位デザインが使用されます。上位ネットリス

トが EDIF ではなく構造 Verilog である場合は、 -top オプションは必須です。 -top オプションは、パフォーマ

ンスと使用率を見積もるためにモジュール解析フローを実行する場合など、サブモジュールを上位として指

定するために使用することもできます。

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





Vivado ツールをバッチモードで実行している場合でも、 Tcl シェルモードで対話的に Tcl コマンドを実行している場

合でも、グラフィカルモードでデザインデータを Vivado IDE で表示している場合でも、インメモリデザインは

Vivado ツール内に存在します。

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

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

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

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

ヒント : プロジェクトモードでは、異なる目的で複数の制約ファイルを含む制約セットを定義できますが、非プロ

ジェクトモードでは、同じ操作を実行するのに複数の read_xdc コマンドを使用します。

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

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

前にロジックデザインが簡略化されます。

Vivado のネットリスト適化では、デザイン要件を満たすため、さまざまな適化機能が提供されています。詳細

は、 46 ページの「ロジック適化」を参照してください。

手順 5: デザインの配置

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

置後、 write_checkpoint コマンドを使用してデザインチェックポイントファイルを保存します。

手順 6: デザインの配線

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

手順 7: 必須レポートの生成

report_timing_summary コマンドは、タイミング解析を実行し、タイミング違反の詳細を含むタイミングレ

ポートを生成します。 report_utilization コマンドは、使用されているデバイスリソースの割合と、その他の

使用率統計のサマリを生成します。非プロジェクトモードでは、各レポートを Tcl コマンドを使用して生成する必

要があります。各レポートコマンドでは -file オプションがサポートされており、レポートをファイルに保存でき

ます。

report_timing_summary コマンドの詳細は『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参

照 18] のこのセクション、 report_utilization コマンドの詳細はこのセクションを参照してください。

レポートはファイルに出力するか、 Vivado IDE に表示して確認できます。詳細は、 108 ページの「インプリメンテー

ションレポートの表示」を参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_timing_summary

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_utilization




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

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

ます。

• 論理ネットリスト

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

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

• 配置配線情報

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

析したり変更したりできます。

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

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

プロジェクトモードでは、次が可能です。

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

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

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

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

重要: 非プロジェクトモードでは、定義済みのインプリメンテーション run およびストラテジはサポートされませ

ん。 Tcl コマンドを使用して、インプリメンテーションプロセスの各段階を手動で実行する必要があります。詳細

は、「非プロジェクトモードでのインプリメンテーションの実行」を参照してください。

インプリメンテーション 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. 図 2-1 に示す [Configure Implementation Runs] ページが表示されます。図の下の説明に従って run を設定します。

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

b. [Synth Name] 列で、インプリメンテーションに使用する合成済みネットリストを生成する合成 run を選択し

ます。デフォルトは、 [Design Runs] ウィンドウで現在アクティブな run です。詳細は、付録 C 「インプリ

メンテーションのカテゴリ、ストラテジの説明、および -directive の値」を参照してください。

注記: ネットリストプロジェクトの場合は、 [Create Runs] コマンドに合成 run の名前は必要ありません。

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

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

c. [Constraints Set] 列でインプリメンテーションに適用する制約セットを選択します。適化、配置、および

配線は、指定された制約セットの物理制約およびタイミング制約に基づいて実行されます。

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

さい。

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

デフォルトでは、制約セットおよびターゲットパーツは、 [Create New Runs] コマンド実行したときのプロ

ジェクト設定に基づいて定義されます。

プロジェクト設定の詳細は、『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895)

[参照 6] のこのセクションを参照してください。

ヒント : 異なる制約セットまたはターゲットパーツを使用する run を作成するには、 [Create New Runs] コマンドを使

用します。既存の run のこれらの値は、 [Design Runs] ウィンドウで run を選択し、 [Run Properties] ウィンドウで変更

できます。

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


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


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug895-vivado-system-level-design-entry.pdf;a=xConfiguringProjectSettings




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

ストラテジとは、インプリメンテーション結果を制御する Vivado インプリメンテーション機能オプション

を定義した設定のことです。 Vivado Design Suite では、定義済みのストラテジが提供されています。また、

独自のインプリメンテーションストラテジを作成することも可能です。

付録 C 「インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の値」に示すストラテ

ジのいずれかを選択します。ストラテジは、その目的に応じてカテゴリ別に分類されており、カテゴリ名

が接頭辞となっています。カテゴリは、付録 Cを参照してください。

詳細は、 32 ページの「インプリメンテーションストラテジの定義」を参照してください。

ヒント : 適化ストラテジは、デザイン間、ソフトウェアリリース間で変更できます。

パフォーマンスストラテジは、デザインパフォーマンスの向上を目的としており、実行時間は長くなりま

す。パフォーマンスストラテジを選択する前に、まずインプリメンテーションのデフォルトを使用してタ

イミング要件を満たすようにしてください。このようにすると、デザインの変更によるタイミングクロー

ジャの影響を吸収するのに十分なマージンが得られます。ただし、デザイン要件が満たされない場合、実

行時間が長くなることが許容されるのであれば、 Performance_Explore はすべてのタイプのデザインを

網羅しているので、初に選ぶストラテジとして適しています。

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

ヒント : run を実行する前に、インプリメンテーションプロセスの各段階の設定を、選択したストラテジのデフォル

ト設定から変更できます。変更した設定を新しいストラテジとしても保存できます。詳細は、 26 ページの「インプ

リメンテーション run 設定の変更」を参照してください。

f. [More] をクリックし、追加の run を定義します。デフォルトでは、シーケンスの次のストラテジが自動的に

選択されます。追加 run の名前とストラテジを指定します (図 2-1)。

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

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





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

注記: 図 2-2 に示されている [Launch runs on remote hosts] および [Launch runs using LSF] は 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 スクリプトは実行または作成しません。


図 2-2: [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] ビュー (図 2-3) が表示されていない場合は、 [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 の開始時間と経過時間が表示されます。


図 2-3: [Design Runs] ウィンドウ


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf;a=xUsingDataTableWindows




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 の現在の設定が表示されます

(図 2-4)。

[Run Properties] ウィンドウでは、次のオプションを変更できます。

• [Name]: run の名前

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

• [Description]: run の説明

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

[Run Properties] ウィンドウの詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3] のこ

のセクションを参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf;a=xUsingTheRunPropertiesWindow

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf;a=xUsingTheRunPropertiesWindow




デザイン run の設定

デザイン run の設定を変更するには、 [Design Run Settings] ダイアログボックス (図 2-5) を使用します。 [Design Run

Settings] ダイアログボックスを開くには、次の手順に従います。


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

(図 2-5) を開きます。

ヒント : 設定の変更は、 run のステータスが「Not started」の場合にのみ可能です。 run を右クリックして [Reset Runs]

をクリックすると、 run のステータスを「Not started」に戻すことができます。詳細は、 30 ページの「run のリセッ

ト」を参照してください。


図 2-4: [Implementation Run Properties] ウィンドウ





[Design Run Settings] ダイアログボックスには、次のものが表示されます。

• run で現在採用されているインプリメンテーションストラテジ。

• インプリメンテーションプロセスの各ステップのストラテジに関連付けられているコマンドオプション。次

に、 3 つのコマンドオプションについて説明します。

[Strategy]

インプリメンテーション run に適用するストラテジを選択します。 Vivado Design Suite では、定義済みのストラテジ

が提供されています。また、独自のインプリメンテーションストラテジを作成することも可能です。

詳細は、 32 ページの「インプリメンテーションストラテジの定義」を参照してください。

[Description]

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


図 2-5: [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 スクリプト機能の使用』


ヒント : tcl.pre および tcl.post スクリプト内の相対パスは、プロジェクトの run ディレクトリを基準にしてい

ます。 <project>/<project.runs>/<run_name>


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug894-vivado-tcl-scripting.pdf;a=xDefiningTclHookScripts




現在のプロジェクトまたは現在の 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] ウィンドウに表示されます (図 2-3)。

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

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

されてから、 run が再開されます。

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

するメッセージが表示されます。

run のリセット

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

1. [Design Runs] ウィンドウで run の 1 つを右クリックします。

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

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

図 2-6 に示すように、 run のリセットを確認するメッセージと、 run ディレクトリから生成されたファイルを削除す

るオプションが表示されます。

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

オプションをオフにします。


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





run の削除

[Design Runs] ウィンドウから run を削除するには、次の手順に従います。

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

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

図 2-7 に示すように、 run の削除を確認するメッセージと、 run ディレクトリから生成されたファイルを削除するオ

プションが表示されます。

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

オプションをオフにします。

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

新しいインプリメンテーション run を定義すると、デフォルトのインプリメンテーション設定が使用されます。これ

らの設定は変更できます。

図 2-8 に、 [Settings] ダイアログボックスの [Implementation] ページを示します。このダイアログボックスは、メイン

メニューから [Tools] → [Settings] をクリックすると開きます。

ヒント : 非プロジェクトモードを使用している場合は、 [Settings] コマンドは使用できません。インプリメンテーショ

ンストラテジをバッチモードで使用可能な Tcl スクリプトとして定義して保存するか、 Vivado IDE で対話的に定義

します。

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

アクティブなインプリメンテーション run のインプリメンテーション設定は、 Flow Navigator で [Settings] をクリック

し、 [Implementation] をクリックしても開くことができます。

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

• [Default constraint set]:

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

• [Incremental compile]:

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


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





• [Strategy]:

インプリメンテーション run に適用するストラテジを選択します。 Vivado Design Suite では、定義済みのストラ

テジが提供されています。独自のインプリメンテーションストラテジを作成し、新しいストラテジとして保存

することも可能です。詳細は、「インプリメンテーションストラテジの定義」を参照してください。

• [Description]:

選択したインプリメンテーションストラテジの説明を表示します。ユーザー定義のストラテジの説明は、新し

い説明を入力して変更できます。 Vivado ツールの標準インプリメンテーションストラテジの説明は変更できま

せん。

インプリメンテーションストラテジの定義

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

れたソリューションです。

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

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

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


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





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

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

ジをコピーして変更し、カスタムストラテジとして保存できます。

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

定義済み run ストラテジにアクセスするには、メインメニューから [Tools] → [Settings] をクリックます。


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





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

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

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

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

3. [Run Strategies] をクリックし、確認する run ストラテジを選択して確認、コピー、または変更します。

[Strategies] → [Run Strategies] ページ (図 2-9) に、各ツールとリリースバージョン用にあらかじめ定義された run

ストラテジがリストされています。

注記: レポートストラテジの確認、コピー、変更については、『Vivado Design Suite ユーザーガイド : デザイン解

析およびクロージャテクニック』 (UG906) [参照 10] のこのセクションを参照してください。

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

トラテジが表示されます。

5. 新しいストラテジを作成するか、既存のストラテジをコピーします。

° 新しいストラテジを作成するには、ツールバーまたは右クリックメニューから [Create Strategy] をク

リックします。

° 既存のストラテジをコピーするには、ツールバーまたは右クリックメニューから [Copy Strategy] をクリッ

クします。次の操作が実行されます。

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

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

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

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

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

° [Type]: [Synthesis] または [Implementation] を選択します。

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

° [Description]: ストラテジの説明を入力します。ここで入力した説明が [Design Runs] ウィンドウの結果の表

に表示されます。

7. [Options] で各インプリメンテーション段階のオプションを変更します。

° デザインの適化 (opt_design)

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

° デザインの配置 (place_design)

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

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

° デザインの配線 (route_design)

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

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

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


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug906-vivado-design-analysis.pdf;a=M6.9.24790.Heading1.Configurable.Report.Strategies




各インプリメンテーション段階の詳細と設定可能なオプションは、第 2 章「デザインのインプリメンテーショ

ン」を参照してください。

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

次の操作を実行します。

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

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

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

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

° フックスクリプトと呼ばれるカスタム 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]


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


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug894-vivado-tcl-scripting.pdf;a=xDefiningTclHookScripts




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

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

存されます。

• Linux OS

$HOME/.Xilinx/Vivado/strategies

• Windows 7

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

run ストラテジの共有

作成したストラテジを複数のユーザーで共有するには、ユーザー定義のストラテジを

<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] ダイアログボックス (図 2-11) が開きます。

注記: [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 ツールの環境外で後で実行できます。


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





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

Vivado IDE で合成またはインプリメンテーションを実行するプロセスが生成されると、まず実行の準備としてデザ

インファイルと制約ファイルが読み込まれます。 [Starting Run] ダイアログボックス (図 2-12) が表示され、このプロ

セスをバックグラウンドに移動するオプションが示されます。

このプロセスをバックグラウンドに移動すると、バックグラウンドタスクを実行させたまま、 Vivado IDE でほかの

操作を実行できます。たとえば、レポートを表示したり、デザインファイルを開いたりできます。この間、前の run

の結果を確認したり、レポートを表示したりして、時間を効率的に活用できます。

注意: このプロセスをバックグランドに移動しても、 [Tcl Console] はブロックされるので、 Tcl コマンドを使用した

り、開いている別のデザインに切り替えるなどの Tcl コマンドを必要とするタスクは実行できません。

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

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

• デザインの適化 (opt_design)

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

• デザインの配置 (place_design)

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

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

• デザインの配線 (route_design)

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

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

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

です。


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





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

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

1. [Design Runs] ウィンドウで run を右クリックし、図 2-13 に示すポップアップメニューから [Launch Next Step:

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

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

ン run で有効な段階は、次のとおりです。

° opt_design (デザインの適化):

ザイリンクスデバイスにフィットするよう論理デザインを適化します。

° power_opt_design (デザインの消費電力適化):

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

° place_design (デザインの配置):


° 配置後の power_opt_design (デザインの消費電力適化):


° 配置後の phys_opt_design (デザインの物理適化):

デザインの負のスラックパスに対してタイミングドリブンの適化を実行します。

° route_design (デザインの配線):


° 配線後の phys_opt_design (デザインの物理適化):


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

ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。ビットストリーム生成

は、厳密にはインプリメンテーション run の一部ではありませんが、次の段階として実行可能です。

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

3. 完了している段階を前の段階に戻すには、 [Design Runs] ウィンドウで run を右クリックして [Reset to Previous

Step: <Step>] をクリックします。

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

と、次が可能になります。

° run を元に戻します。

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

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


図 2-13: [Design Runs] ウィンドウのポップアップメニュー





インプリメンテーションコマンドについて

ザイリンクス Vivado® Design Suite には、プロジェクトベースのデザインでインプリメンテーションプロセスを管理

し、簡略化する多数の機能が含まれています。インプリメンテーションプロセスを段階ごとに手動で実行する機能

も含まれます。

詳細は、 21 ページの「プロジェクトモードでのインプリメンテーションの実行」を参照してください。

非プロジェクトモードでは、 Tcl コマンドを使用してインプリメンテーションプロセスの各段階を手動で実行する

必要があります。



詳細は、 17 ページの「非プロジェクトモードでのインプリメンテーションの実行」を参照してください。

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

プロジェクトモードでは、インプリメンテーションコマンドは決まった順序で実行されます。非プロジェクトモー

ドでは、コマンドは同様の順序で実行できますが、繰り返し実行したり、プロジェクトモードとは異なる順序で実

行することもできます。

重要: インプリメンテーションコマンドは、再配線モードで実行されます。

インプリメンテーションコマンドは、再配線モードで実行されます。これは、インプリメンテーションコマンドを

非プロジェクトモードで実行すると、デザインがメモリに読み込まれ、タスクが実行され、結果のデザインがメモ

リに書き込まれることを意味します。これにより、非プロジェクトモードでの実行がより柔軟なものになります。

次に例を示します。

• opt_design コマンドの後に opt_design -remap を実行

リマップは opt_design コマンドの結果に対して実行されます。

• 一部のセルが配置されたデザインに対して place_design コマンドを実行

既存のセル配置が place_design コマンドの開始点として使用されます。

• 一部が配線されたデザインに対して route_design コマンドを実行

既存の配線が route_design コマンドの開始点として使用されます。

• セルが配置されていないデザインに対して route_design コマンドを実行

セルが配置されている必要があるので、エラーが発生します。

• 完全に配置配線されていないデザインに対して opt_design コマンドを実行

ロジック適化で論理ネットリストが適化され、配置されていない新しいセルおよび配線されていない新し

いネットが作成される場合があります。インプリメンテーションを完了するため配置配線を再実行する必要が

ある場合があります。

プロジェクトモードおよび非プロジェクトモードのどちらでも、 Vivado インプリメンテーションプロセスはいくつ

かのサブプロセスで構成されています。





• 合成済みデザインを開く :

ネットリスト、デザイン制約、ターゲットデバイスデータを統合し、インプリメンテーションを実行するイン

メモリデザインを構築します。

• デザインの適化:

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

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

ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを適化します。

• デザインの配置:


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


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

配置に基づく見積もりタイミングを使用してロジックおよび配置を適化します。ファンアウトの大きいドラ

イバーの複製も含まれます。

• デザインの配線:


• 配線後のデザインの物理適化:


• ビットストリームの生成:

ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します。

注記: ビットストリーム生成は、厳密にはインプリメンテーション run の一部ではありませんが、別の段階とし

て実行可能です。

この章では、インプリメンテーションプロセスの各段階と関連する Tcl コマンドの詳細を説明します。次の表に、

サブプロセスと関連の Tcl コマンドをリストします。

Tcl レポートコマンドおよびそのオプションの詳細な説明は、『Vivado Design Suite Tcl コマンドリファレンスガイ

ド』 (UG835) [参照 18] を参照してください。

表 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


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xsynth_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xopen_checkpoint

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xopen_run

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xlink_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xopt_design

http://japaninx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xpower_opt_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xplace_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xphys_opt_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xroute_design

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xwrite_bitstream




合成済みデザインを開く

インプリメンテーションでは、まず合成済みデザインからのネットリストをメモリに読み込み、デザイン制約を適

用します。合成済みのデザインは、使用されるデザインフローによってさまざまな方法で開くことができます。

インメモリデザインの構築

Vivado Design Suite では、インメモリデザインを構築するため、次のプロセスを使用してネットリストファイル、制

約ファイル、およびターゲットデバイスの情報が統合されます。

1. ネットリストを統合します。

必要であれば、複数のソースからのネットリストを統合します。デザインには、構造 Verilog、 EDIF、 Vivado IP

を含めることができます。

重要: Vivado Design Suite では、UltraScale™ デバイスに対して NGC フォーマットのファイルはサポートされていませ

ん。 Vivado Design Suite で IP を再生成し、ネイティブ出力ファイルを使用することをお勧めします。または、

NGC2EDIF コマンドを使用して NGC ファイルを EDIF に変換し、インポートすることもできます。今後は XST で生

成された NGC フォーマットではなくネイティブ Vivado IP を使用することをお勧めします。

2. 従来のネットリストプリミティブを現在サポートされる Unisim プリミティブに変換します。

ヒント : report_transformed_primitives を使用すると、変換されたセルのリストを生成できます。

3. XDC ファイルから制約を処理します。

これらの制約には、タイミング制約と、パッケージピン割り当てやフロアプラン用の Pblock などの物理制約が

含まれます。

重要: 制約が満たされていないことを示すクリティカル警告を確認します。制約が適化で削除されたデザインオブ

ジェクトに設定されていることがあります。 Tcl コマンド write_xdc -constraints INVALID を使用しても、無効な XDC

制約を取得できます。

4. 配置マクロを作成します。

Vivado ツールでは、接続または配置制約に基づいてセルの配置マクロが作成され、配置が簡略化されます。

配置マクロには、次のものがあります。

° XDC ベースのマクロ。

° 相対配置マクロ (RPM)。

注記: RPM は、個別のセルではなくグループとして配置されます。

° 複数の CLB に配置する必要のある長いキャリーチェーン。

注記: キャリーチェーンを構成するプリミティブは 1 つのマクロに含め、縦方向に並ぶ複数のスライスに配

置されるようにする必要があります。





Tcl コマンド

合成済みデザインをメモリに読み込むには、デザインのソースファイルおよびデザインのステートに応じて、

表 2-2 に示す Tcl コマンドを使用します。

synth_design

synth_design コマンドは、プロジェクトモードおよび非プロジェクトモード両方で使用できます。このコマンド

は、 RTL ソースに対して指定したオプションで Vivado 合成を実行し、合成後にデザインをメモリに読み込みます。

synth_design の構文

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>] [-rtl_skip_ip] [-rtl_skip_constraints] [-keep_equivalent_registers] [-resource_sharing <arg>] [-cascade_dsp <arg>] [-control_set_opt_threshold <arg>]

[-max_bram <arg>] [-max_uram <arg>] [-max_dsp <arg>] [-max_bram_cascade_height <arg>] [-max_uram_cascade_height <arg>] [-retiming] [-no_srlextract] [-assert] [-no_timing_driven] [-sfcu] [-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) [参照 20] および『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] を参照してください。

この synth_design サンプルスクリプトでは、 VHDL および Verilog ファイルが読み込まれ、指定したデバイスで

デザインが合成されます。 synth_design コマンドが完了すると、デザインが開き、メモリに読み込まれます。合

成が完了すると、デザインチェックポイントが保存されます。

表 2-2: Tcl コマンドを使用可能なモード

コマンドプロジェクトモード非プロジェクトモード

synth_design X X

open_checkpoint X

open_run X

link_design X X





synth_design Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 18] の

このセクションを参照してください。このガイドでは、すべての Tcl コマンドおよびそのオプションが詳細に説明さ

れています。

open_checkpoint

open_checkpoint コマンドを使用すると、デザインチェックポイントファイル (DCP) が開き、新しいインメモリ

プロジェクトが作成されて、新しいプロジェクトがチェックポイントの内容で初期化されます。このコマンドでは、

上位デザインチェックポイントまたは独立階層 (OOC) モジュールに対して作成されたチェックポイントを開くこ

とができます。

注記: これまでのリリースでは、チェックポイントデザインを読み込んで初期化するのに read_checkpoint コマ

ンドを使用しました。バージョン 2014.1 からは、これに open_checkpoint コマンドを使用します。

read_checkpoint コマンドの動作は変更されており、チェックポイントファイルがソースファイルのリストに追加さ

れるだけです。この動作は、 read_verilog、 read_vhdl、 read_xdc などのほかの read コマンドと同じです。

read_checkpoint コマンドを使用した場合、デザインを初期化し、メモリに読み込むために link_design コマ

ンドも実行する必要があります。

チェックポイントを開く場合、あらかじめプロジェクトを作成する必要はありません。 open_checkpoint コマン

ドは、デザインデータをメモリに読み込み、デザインを非プロジェクトモードで開きます。プロジェクトモードお

よび非プロジェクトモードの詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参


重要: インクリメンタルコンパイルフローでは、これまでと同様に 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_checkpoint サンプルスクリプトは、合成済みデザインチェックポイントファイルを開きます。

open_run

合成済みまたはインプリメント済み run を開き、メモリに読み込みます。

重要: open_run コマンドは、プロジェクトモードでのみ使用できます。デザイン run は非プロジェクトモードでは

サポートされません。

open_run コマンドをインプリメンテーション前の RTL デザインに使用し、完了した Vivado 合成 run を開いて、合

成済みネットリストをメモリに読み込みます。

ヒント : インメモリデザインは自動的にアップデートされるので、 synth_design の後 open_run を使用する必要は

ありません。 open_run コマンドは、以前のデザインセッションで完了した合成 run を開く場合にのみ使用します。




https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug892-vivado-design-flows-overview.pdf;a=xUnderstandingProjectModeAndNonProjectMode




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

この open_run サンプルプロジェクトは、 synth_1 というデザインを開き、 synth_1 という完了した合成 run を

メモリに読み込みます。

デザインがメモリにある場合に open_run コマンドを実行すると、新しいデザインを開く前に、現在のデザインへ

の変更を保存するかどうかを尋ねるメッセージが表示されます。

link_design

サードパーティ合成ツールなどで生成されたネットリストソースからインメモリデザインを作成し、ネットリスト

と合成制約をターゲットデバイスにリンクします。

ヒント : link_design コマンドは、プロジェクトモードおよび非プロジェクトモードの両方でネットリストデザ

インを作成する場合にサポートされます。ネットリストを読み込まずに link_design -part <arg> を使用する

と、デバイス探索用の空のデザインが開きます。

link_design の構文

link_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>] [-mode <arg>] [-pr_config <arg>] [-reconfig_partitions <args>] [-partitions <args>] [-quiet] [-verbose]

link_design のスクリプト例

# Open named design from netlist sources.link_design -name netDriven -constrset constrs_1 -part xc7k325tfbg900-1

デザインがメモリにある場合に link_design コマンドを実行すると、新しいデザインを開く前に、現在のデザイ

ンへの変更を保存するかどうかを尋ねるメッセージが表示されます。

推奨: メモリに合成済みデザインを作成した後、エラーおよびクリティカル警告を調べて、不足している制約や無効

な制約がないかどうかを確認してください。デザインが問題なく作成されたら、解析、レポート生成、制約の適用、

またはインプリメンテーションを実行できます。

注記: link_design のパーシャルリコンフィギュレーションオプションの詳細は、『Vivado Design Suite ユーザーガ

イド : パーシャルリコンフィギュレーション』 (UG909) [参照 15] のこのセクションを参照してください。

メモリに合成済みデザインを開いたら、 report_timing_summary コマンドを実行してタイミング制約をチェッ

クし、デザインの目標が適切であるかどうかを確認してください。 report_timing_summary コマンドの詳細は、

『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 18] のこのセクションを参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug909-vivado-partial-reconfiguration.pdf;a=xReadingDesignModules

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_timing_summary




BUFG 最適化

link design の初に実行される必須ロジック適化 (MLO) では、グローバルクロックバッファーを挿入するた

めに CLOCK_BUFFER_TYPE プロパティを使用できます。設定可能な値は、 7 シリーズの場合は BUFG、 UltraScale

の場合は BUFG および BUFGCE です。 NONE はすべてのアーキテクチャで設定でき、 MLO および opt_design による

グローバルクロックバッファーの挿入が実行されなくなります。 BUFG および BUFGCE に設定すると、ロジック

適化で指定のネットを駆動するため該当するバッファータイプが挿入されます。

CLOCK_BUFFER_TYPE を使用すると、 XDC 制約を使用してバッファー挿入を制御できるので、デザインソースや

ネットリストを修正する必要がありません。 CLOCK_BUFFER_TYPE を使用して挿入されるバッファー数には制限

がないため、デザインに含まれるグローバルクロックが多くなりすぎ、配置エラーの原因となることがあるので、

使用には注意が必要です。詳細は、『Vivado Design Suite プロパティリファレンスガイド』 (UG912) [参照 14] を参照

してください。

ロジック最適化

ロジック適化は、配置の前に効率的なロジックデザインを得るために実行します。ロジック適化では、ネット

リスト接続性チェックが実行され、複数のドライバーを持つネットや駆動されていない入力などの発生する可能性

のあるデザイン問題に対して警告メッセージが表示されます。ブロック RAM の消費電力適化も実行されます。

デザインの接続エラーはロジック適化段階に伝搬されることが多く、そこでエラーが発生します。インプリメン

テーションを実行する前に、 DRC レポートを使用して接続が有効であることを確認することが重要です。

ロジック適化では、 DONT_TOUCH プロパティの値が TRUE に設定されているセルおよびネットの適化は実行さ

れません。

ロジック適化を実行する Tcl コマンドは opt_design です。

よくあるデザインエラー

ロジック適化がエラーになる場合、駆動されていない LUT 入力 (入力が LUT ロジック論理式で使用されている ) が

原因であることがよくあります。これにより、次のようなエラーメッセージが表示されます。

ERROR: [Opt 31-67] Problem: A LUT6 cell in the design is missing a connection on input

pin I0, which is used by the LUT equation.

このエラーは、複数のソースからロジックを統合する際に接続が見逃された場合によく発生します。ロジック適

化では、ソース定義にトレースするため、セル名とピンの両方が認識されます。

使用可能なロジック最適化

Vivado ツールでは、ロジック適化はインメモリデザインに対して実行されます。

重要: 特定のロジック適化に対応するコマンドオプションを指定すると、その適化のみが実行されます。ほかの

適化は、通常デフォルトで実行されるものも、ディスエーブルになります。

次の表に、複数のオプションを選択している場合に実行される適化の順序を示します。この順序によりも効果

的な適化が確実に実行されます。





リターゲット (デフォルト )

デザインのターゲットデバイスをあるデバイスファミリから別のデバイスファミリに変更する際、ブロックタイ

プを別のブロックタイプに変更します。たとえば、インスタンシエートされた MUXCY または XORCY コンポーネ

ントを CARRY4 ブロックに、 DCM を MMCM に変更します。また、インバーターのような単純なセルはダウンスト

リームロジックに吸収されます。

定数伝搬 (デフォルト )

定数値をロジックに伝搬することで、ロジックは次のようになります。

• 削除:

定数 0 が入力される AND など。

• 縮小:

定数 1 が入力される 3 入力 AND を 2 入力 AND に縮小するなど。

• 冗長:

0 が入力される 2 入力 OR を 1 本のワイヤに削減するなど。

スイープ (デフォルト )

ロードのないセルを削除します。

表 2-3: 複数のオプションが選択されている場合の最適化の順序

フェーズ名前オプションデフォルト

1 リターゲット -retarget X

2 定数伝搬 -propconst X

3 スイープ -sweep X

4 マルチプレクサー適化 -muxf_remap

5 キャリー適化 -carry_remap

6 セットマージの制御 -control_set_merge

7 等価ドライバーの統合 -merge_equivalent_drivers

8 BUFG 適化 -bufg_opt X

9 シフトレジスタの適化 -shift_register_opt X

10 モジュールベースのファンアウト

適化

-hier_fanout_limit <arg>

11 リマップ -remap

12 エリアモードでの再合成 -resynth_area

13 順序エリアの再合成 -resynth_seq_area

14 ブロック RAM 消費電力適化 -bram_power_opt X





マルチプレクサー最適化

配線しやすくするため、 MUXF7、 MUXF8、 MUXF9 プリミティブを LUT3 にマップし直します。 -muxf_remap オ

プションの代わりに MUXF_REMAP セルプロパティを使用して、この適化の適用範囲を制限できます。個別の

MUXF プリミティブまたは MUXF プリミティブを含む階層セルの MUXF_REMAP プロパティを TRUE に設定します。

ヒント : マルチプレクサー適化実行後にネットリストをさらに適化するには、マルチプレクサー適化とリマッ

プを組み合わせて使用します (opt_design -muxf_remap -remap)。

キャリー最適化

配線しやすくするため、キャリーチェーンの CARRY4 および CARRY8 プリミティブを LUT にマップし直します。

-carry_remap オプションを使用した場合、 1 段キャリーチェーンのみが LUT に変換されます。 CARRY_REMAP セ

ルプロパティを使用すると、任意の長さのキャリーチェーンの変換を個別に制御できます。 CARRY_REMAP プロパ

ティには、 LUT にマップするキャリーチェーンの大長を整数で指定します。 CARRY_REMAP プロパティは

CARRY4 および CARRY8 プリミティブに適用され、キャリーチェーンを LUT に変換するには、 1 つのチェーンに含

まれるすべての CARRY プリミティブで同じ値に設定する必要があります。サポートされる小値は 2 です。

例: デザインに CARRY8 プリミティブを 1 つ、 2 つ、 3 つ、および 4 つ含む複数のキャリーチェーンが含まれている

とします。

次のコマンドを使用すると、すべての CARRY8 プリミティブに CARRY_REMAP プロパティが設定されます。

Vivado% set_property CARRY_REMAP 2 [get_cells -hier -filter {ref_name == CARRY8}]

opt_design を実行すると、CARRY8 プリミティブが 3 つ以上含まれるキャリーチェーンのみが CARRY8 にマップ

されたままになり、 1 つおよび 2 つ含まれるキャリーチェーンは LUT にマップされます。

ヒント : 長いキャリーチェーンを LUT にマップし直すと、リマップオプションを追加してさらに適化しても、遅

延が大幅に増加する可能性があります。リマップは、 1 つまたは 2 つの CARRY プリミティブがカスケード接続され

た短いキャリーチェーンにのみ適用することをお勧めします。

制御セットの統合

論理的に等価の制御信号のドライバーを 1 つのドライバーにまとめます。これは、ファンアウト複製の逆のような

操作で、ネットがモジュールベース複製により適したものになります。

等価ドライバーの統合

論理的に等価の信号のドライバーを 1 つのドライバーにまとめます。これは制御セットの統合に似ていますが、制

御信号だけでなく、すべての信号に適用されます。

BUFG 最適化 (デフォルト )

ロジック適化では、クロックネットおよびデバイス全体のリセットなどのクロック以外のネットにグローバルク

ロックバッファーが挿入されます。

7 シリーズデザインでは、グローバルクロックバッファーの合計が 12 個を超えていない限りクロックバッファー

が挿入されます。





UltraScale デザインでは、クロックネットに挿入できるクロックバッファー数に上限はありません。

クロック以外のネットの場合:

• グローバルクロックバッファーは、 BUFG_GT バッファーを除いた合計が 24 個を超えていない限り挿入され

ます。

• ファンアウトは 25,000 より大きくする必要があります。

ファブリックドリブンのクロックネットでは 30 以上のファンアウトが必要です。

注記: ネットで BUFG 適化が実行されないようにするには、そのネットの CLOCK_BUFFER_TYPE プロパティの値

を NONE に設定します。デザインを有効なものにするために必要な一部のクロックバッファー挿入は、必須ロジッ

ク適化でも実行されます。

シフトレジスタの最適化 (デフォルト )

シフトレジスタの適化では、複数の変換が実行されます。

• SRL ファンアウト適化: SRL (LUT ベースシフトレジスタ ) プリミティブのファンアウトが 100 以上の場合に、

SRL チェーンの末尾からレジスタ 1 段を取り出し、レジスタプリミティブに変換します。これにより、ネット

がタイミングクリティカルになった場合にダウンストリームの複製がより柔軟に実行できるようになります。

通常、ファンアウトの大きい SRL ドライバーを複製するよりも、ファンアウトの大きいレジスタドライバーを

複製する方が簡単です。

• SRL とレジスタプリミティブ間の変換:

° SRL プリミティブは、 SRL_TO_REG プロパティの値を true に設定することにより、論理的に等価のレジス

タプリミティブチェーンに変換できます。この変換は通常、デバイス内で信号が長距離を移動できるよう

にするため、分散できるパイプラインレジスタの段数を増加させるために使用されます。レジスタの段数

が増加すると、クロック周波数が上がりますが、レイテンシは長くなります。

° レジスタプリミティブのチェーンは、 REG_TO_SRL プロパティの値を true に設定することにより、論理的

に等価の SRL プリミティブに変換できます。この変換は通常、デバイス内で信号が長距離を移動するのに

使用されるパイプラインレジスタの段数を削減するために使用されます。レジスタの段数が多すぎると、

密集などの配置問題が発生する可能性があります。

• SRL とレジスタチェーン間のパイプライン段の選択移動: この変換は、 SRL とレジスタプリミティブを含むパ

イプラインレジスタチェーンに使用できます。 SRL 入力または SRL 出力で、レジスタ段を SRL から取り出し

たり、 SRL に挿入したりできます。これにより、パイプラインレジスタ構造をより詳細に制御でき、パイプラ

インが多いまたは少ない問題に対処できます。

° パイプラインが少ない: SRL の入力からレジスタを 1 つ取り出すには、 SRL プロパティ

SRL_STAGES_TO_REG_INPUT の値を 1 に設定します。 SRL の出力からレジスタを 1 つ取り出すには、

SRL_STAGES_TO_REG_OUTPUT プロパティの値を 1 に設定します。

° パイプラインが多い: SRL の入力にレジスタを 1 つ挿入するには、 SRL プロパティ

SRL_STAGES_TO_REG_INPUT の値を -1 に設定します。 SRL の出力にレジスタを 1 つ挿入するには、

SRL_STAGES_TO_REG_OUTPUT プロパティの値を -1 に設定します。

注記: レジスタから SRL への変換は、制御セットに互換性がある場合にのみ可能です。





モジュールベースのファンアウト最適化

ファンアウトがこのオプションで指定した上限を超えているネットドライバーは、論理階層に基づいて複製されます。

ファンアウトの大きいネットで駆動される各階層インスタンスでファンアウトが指定の上限を超えている場合、階

層内のネットは複製されたドライバーで駆動されます。

重要: 各ロジック適化はインメモリデザインに適用され、元の合成済みデザインには適用されません。

リマップ

複数の LUT を 1 つの LUT にまとめてロジックの深さを削減します。

注記: Vivado Design Suite 2017.3 リリースから、異なる論理階層に含まれる LUT を 1 つの LUT にまとめてロジックレ

ベル数を削減することが可能になりました。リマップされたロジックは、ロジックコーンのもダウンストリーム

の LUT に統合されます。

エリアモードでの再合成

エリアモードで合成を再実行し、 LUT の数を削減します。

順序エリアの再合成

組み合わせロジックおよび順序ロジックを削減するよう再合成を実行します。エリアモードでの再合成の適化の

スーパーセットを実行します。

ブロック RAM 消費電力最適化 (デフォルト )

ブロック RAM セルに対して消費電力の適化をイネーブルにします。次を実行します。

• 完全なデュアルポート RAM の読み出されないポートの WRITE_MODE を NO_CHANGE に変更。

• ブロック RAM の出力にクロックゲーティングを適用。





opt_design

ロジック適化を実行します。

opt_design の構文

opt_design [-retarget] [-propconst] [-sweep] [-bram_power_opt] [-remap] [-resynth_area] [-resynth_seq_area] [-directive <arg>] [-muxf_remap] [-hier_fanout_limit <arg>] [-bufg_opt] [-shift_register_opt] [-control_set_merge] [-merge_equivalent_drivers] [-carry_remap] [-debug_log] [-quiet] [-verbose]

opt_design のスクリプト例

# Run logic optimization with the remap optimization enabled, save results in a checkpoint, report timing estimatesopt_design -directive AddRemapwrite_checkpoint -force $outputDir/post_optreport_timing_summary -file $outputDir/post_opt_timing_summary.rpt

この opt_design サンプルスクリプトでは、インメモリデザインにロジック適化を実行し、メモリに書き込み

ます。適化後にデザインチェックポイントを保存し、タイミングサマリレポートを生成して指定のファイルに記

述します。

最適化タイプの制限

適化タイプを制限するには、コマンドラインオプションを使用します。次に、デフォルトのブロック RAM 適

化を実行しないようにする別の方法を示します。

opt_design -retarget -propconst -sweep -bufg_opt -shift_register_opt

-directive オプションの使用

-directive オプションで指示子を指定すると、 opt_design コマンドを異なるモードで実行できます。一度に指

定できる指示子は 1 つのみです。 -directive オプションは、ほかのオプションと共に使用することはできません。

次の指示子があります。

• Explore:

適化を複数回実行します。

• ExploreArea:

組み合わせロジックを縮小することを優先して適化を複数回実行します。

• AddRemap:

デフォルトのロジック適化フローを実行し、 LUT 再マップを含めてロジックレベルを削減します。

• ExploreSequentialArea:

レジスタおよび関連の組み合わせロジックを縮小することを優先して適化を複数回実行します。

• RuntimeOptimized:

反復回数を少なくし、デザインパフォーマンスよりも実行時間を短縮することを優先します。

• NoBramPowerOpt:

opt_design コマンドの RAM 消費電力適化以外のデフォルト適化をすべて実行します。





• ExploreWithRemap:

Explore に加えてリマップ適化を実行します。

• Default:

opt_design をデフォルト設定で実行します。

表 2-4 に、 -directive オプションの異なる指示子で実行される適化フェーズを示します。





イ 53UG

表

フ a NoBramPowerOpt RuntimeOptimized:

1 リターゲットリターゲット

2 定数伝搬定数伝搬

3 スイープスイープ

4 BUFG 適化 BUFG 適化

5 タシフトレジスタの

適化

シフトレジスタの

適化

6

7

8 で

9

10

化

a.

ンプリメンテーション904 (v2017.3) 2017 年 10 月 27 日 japan.xilinx.com

2-4: -directive オプションの異なる指示子で実行される最適化フェーズ

ェーズ Default Explore ExploreWithRemap ExploreArea AddRemap ExploreSequentialAre

リターゲットリターゲットリターゲットリターゲットリターゲットリターゲット

定数伝搬定数伝搬定数伝搬定数伝搬定数伝搬定数伝搬

スイープスイープスイープスイープスイープスイープ

BUFG 適化 BUFG 適化 BUFG 適化 BUFG 適化 BUFG 適化 BUFG 適化

シフトレジスタ

の適化


の適化

シフトレジスタの

適化


の適化


の適化

シフトレジス

の適化

ブロック RAM

消費電力適化

定数伝搬定数伝搬定数伝搬リマップ定数伝搬

スイープスイープスイープブロック RAM

消費電力適化

スイープ

ブロック RAM

消費電力適化a

リマップエリアモードで

の再合成

エリアモード

の再合成

ブロック RAM

消費電力適化a

ブロック RAM

消費電力適化

順序エリアの

再合成

ブロック RAM

消費電力適

UltraScale/UltraScale+ デザインでは実行されない。



-debug_log および -verbose オプションの使用

適化結果を解析するには、 -debug_log オプションを使用し、 opt_design の適化の影響を受けたロジックの

詳細を確認します。このログには、定数値のため削減されたロジックおよびロードがないために削除されたロジッ

クに関する追加メッセージが表示されます。

opt_design で実行されたすべてのロジック適化の詳細を表示するには、 -verbose オプションを使用してくだ

さい。 -verbose オプションを使用すると大量のメッセージが表示されるので、デフォルトではオフになっていま

す。 -verbose オプションは、有益だと思われる場合に使用してください。

推奨: 大型デザインでツールの実行時間を短縮するには、 -verbose オプションはシェルモードまたはバッチモー

ドでのみ使用し、 GUI モードでは使用しないでください。

重要: opt_design コマンドは、インメモリデザインに対して実行されます。複数回実行した場合、前回の run の結

果が適化されます。そのため、 -debug_log または -verbose オプションを追加する前に合成済みデザインを読

み込み直す必要があります。

ロジック最適化制約

ロジック適化中、 DONT_TOUCH プロパティが認識され、このプロパティが設定されているネットまたはセルは削

除されません。詳細は、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 8] のこのセクションを参照してく

ださい。

DONT_TOUCH は通常、下位セルに設定し、適化で削除されないようにします。階層セルに DONT_TOUCH を設定

するとセルの境界は保持されますが、セル内では適化が実行される可能性はあり、制約がその境界を超えて伝搬

される可能性はあります。階層ネットを保持するには、 get_nets の -segments オプションを使用して、すべて

のネットセグメントに DONT_TOUCH プロパティを適用します。

MARK_DEBUG プロパティの値が TRUE であるネットには、 DONT_TOUCH プロパティの値が自動的に TRUE に設定さ

れます。これにより、インプリメンテーションフロー中にネットは変更されなくなり、どのデザイン段階でもネッ

トをプローブできます。 MARK_DEBUG は、このように使用することをお勧めします。ただし、 DONT_TOUCH は制限

的すぎ、定数の伝搬、スイープ、リマップなどの適化が実行されなくなり、タイミングクロージャを達成するの

が困難になることがまれにあります。その場合は、 MARK_DEBUG を TRUE に設定したまま、 DONT_TOUCH の値

FALSE に設定できます。ただし、 MARK_DEBUG を設定したネットが適化で削除され、プローブされなくなる可能

性があります。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug901-vivado-synthesis.pdf;a=xSynthesisAttributes




消費電力の最適化

クロックゲーティングを使用して、ダイナミック消費電力を適化します (オプション)。消費電力の適化は、プ

ロジェクトモードおよび非プロジェクトモード両方で使用でき、ロジック適化後または配置後に実行してデザイ

ンの消費電力を適化できます。消費電力の適化には、クロックやロジックを変更せずにデザインのダイナミッ

ク消費電力を削減するクロックゲーティングソリューションが含まれます。

詳細は、『Vivado Design Suite ユーザーガイド : 消費電力解析および適化』 (UG907) [参照 11] を参照してください。

Vivado 消費電力解析

Vivado ツールでは、レガシ IP ブロックおよびサードパーティ IP ブロックを含む、デザイン全体が解析され、各ク

ロックサイクルでの結果に影響しないレジスタからの出力ロジックが特定されます。

クロックイネーブル (CE) の使用

Vivado 消費電力適化では、ザイリンクス 7 シリーズデバイスのロジックに多数含まれるクロックイネーブル (CE)

が利用されます。細粒度クロックゲーティングまたはロジックゲーティング信号が作成され、余分なスイッチイン

グアクティビティが除去されます。

また、フリップフロップレベルでは、 CE はフリップフロップの D 入力とフィードバック Q 出力のいずれかを選択

するのではなく、クロックをゲーティングしているので、 CE 入力のパフォーマンスが向上するだけではなく、ク

ロックの消費電力も削減されます。

クロックゲーティング

シンプルデュアルポートと完全なデュアルポートモードのいずれの場合でも専用ブロック RAM の消費電力が削減

されます (図 2-15)。


図 2-14: クロックゲーティング





これらのブロックには、次のイネーブルが含まれます。

• アレイイネーブル

• ライトイネーブル

• 出力レジスタのクロックイネーブル

節約される消費電力のほとんどはアレイイネーブルの使用によるもので、データが書き込まれず、出力が使用され

ないときに、消費電力を削減する機能がインプリメントされます。

power_opt_design

power_opt_design コマンドは、デザインを解析して適化します。デフォルトでは、デザイン全体が解析およ

び適化されます。クロックゲーティングも実行され、消費電力が適化されます。

power_opt_design の構文

power_opt_design [-quiet] [-verbose]

デザイン全体を解析および適化しない場合は、 set_power_opt を使用して適化を設定します。このコマンド

を使用すると、適化にセルタイプまたは階層を含めるか、除外するかなどを設定できます。 set_power_opt コ

マンドを使用して、 opt_design コマンドで適化を実行するブロック RAM セルを指定できます。

set_power_opt コマンドの構文は、次のとおりです。

set_power_opt [-include_cells <args>] [-exclude_cells <args>] [-clocks <args>][-cell_types <args>] [-quiet] [-verbose]

注記: opt_design を使用した場合、ブロック RAM の消費電力適化は実行されません。

推奨: opt_design コマンドで特定のブロック RAM に対してブロック RAM 消費電力適化が実行されないように

するには、 set_power_opt -exclude_cells [get_cells <bram_insts>] を使用します。


図 2-15: ブロック RAM イネーブルの利用

Before

address

data in

data out

After

address

data in data out

ce





配置

Vivado Design Suite 配置によりネットリストのセルがターゲットデバイスの特定サイトに配置されます。ほかのイン

プリメンテーションコマンドと同様、インメモリデザインに対して処理が実行されます。

デザイン配置の最適化

Vivado の配置では、次を適化するよう配置が実行されます。

• タイミングスラック : タイミングクリティカルなパスのセルの配置は、負のスラックが小限になるよう選択

されます。

• ワイヤの長さ : 配線長を小限に抑えるように、全体的な配置が実行されます。

• 密集度: ピンの密集度が監視され、配線の密集を削減するためセルが分散されます。

デザインルールチェック

配置を開始する前に、デザインルールチェック (DRC) (report_drc で選択された DRC およびビルトインの内部

DRC) が実行されます。内部 DRC では、 LOC 制約が設定されていないメモリ IP セル、競合する IOSTANDARD が設

定された I/O バンクなど、無効な配置がレポートされます。

クロックおよび I/O 配置

DRC の実行後、クロックおよび I/O セルが配置されてからその他のロジックセルが配置されます。クロックと I/O

セルは、選択したザイリンクスデバイスに特定の複雑な配置規則によって関連していることがよくあるので、同時

に配置されます。 UltraScale デバイスでは、配置によりクロックトラックの割り当ておよびクロックの事前配線も実

行されます。 IOB プロパティが設定されたレジスタセルは、 IOB 値が TRUE のどのレジスタを I/O ロジックサイト

にマップするかを決定するためにこの段階で処理されます。配置で IOB プロパティの TRUE を適用できない場合は、

クリティカル警告が表示されます。

配置のターゲット

この時点では、次が配置のターゲットとなります。

• I/O ポートおよび関連ロジック

• グローバルおよびローカルクロックバッファー

• クロックマネージメントタイル (MMCM および PLL)

• ギガビットトランシーバー (GT) セル





固定されていないロジックの配置

配置のこの段階では、固定されていないロジックを配置する際 LOC プロパティや Pblock 割り当てなどの物理制約に

従います。既存の LOC 制約は、ネットリストの接続およびデバイスサイトに対して有効かどうかがチェックされま

す。メモリ IP や GT のような一部の IP は、デバイス専用の配置制約を使用して生成されます。

重要: デバイスの I/O アーキテクチャのために、 LOC プロパティで LOC が適用されていないセルが制約されること

がよくあります。入力ポートに LOC 制約が設定されている場合、関連する I/O バッファー、 IDELAY、 ILOGIC の位

置も固定されます。競合する LOC 制約は、入力パスの個々のセルには適用できません。出力および GT 関連のセル

の場合も同様です。

クロックリソースの配置規則

クロックリソースの配置は、『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472) [参照 16] および

『UltraScale アーキテクチャクロッキングリソースユーザーガイド』 (UG572) [参照 17] に示す配置規則に従う必要が

あります。たとえば、グローバルクロックバッファーを駆動する入力はクロック兼用 I/O サイトに配置する必要が

あり、 7 シリーズデバイスではデバイスの上半分または下半分の同じ側、 UltraScale デバイスでは同じクロック領域

に配置する必要があります。これらのクロック配置規則も、論理ネットリストの接続およびデバイスサイトに対し

て有効かどうかがチェックされます。

クロックおよび I/O を配置できない場合

クロックおよび I/O の適切な配置が見つからなかった場合は、違反のあった配置規則と、影響を受けたセルの簡単な

説明が表示されます。

配置できない理由には、次のようなものがあります。

• 競合する制約によりクロックツリーの問題が発生している。

• 複雑すぎて配置ツールで解決できないクロックツリーの問題がある。

• RAM および DSP ブロックの配置が Pblock などのほかの制約と競合している。

• リソースの使用しすぎ

• I/O バンクの要件および規則

まずサイトにセルが暫定的に配置され、その後配置問題を解決するために別のセルが配置されることがあります。

暫定的な配置により、クロックおよび I/O 配置のエラーの原因がわかることがよくあります。暫定的な配置でエラー

になったセルを手動で配置すると、配置が改善することがあります。

ヒント : place_ports コマンドを実行してクロックおよび I/O を配置してから、 place_design コマンドを実行し

ます。ポート配置でエラーが発生した場合、配置はメモリに保存され、エラーを解析できます。詳細は、 Vivado Tcl

プロンプトから place_ports -help を実行してください。

UltraScale のクロックツリーの配置および配線については、『UltraFast 設計手法ガイド (Vivado Design Suite 用)』

(UG949) [参照 13] を参照してください。





グローバル配置、詳細配置、パッキングおよび有効化

クロックと I/O の配置の後は、グローバル配置、詳細配置、パッキングおよび有効化などの残りの配置を実行します。

推奨: 配置後に report_timing_summary を実行し、クリティカルパスをチェックしてください。負のセットアッ

プスラックが大きいパスは、タイミングクロージャを達成するため、手動配置、制約の変更、またはロジックの再

構築が必要な場合があります。

place_design

デザインを配置します。ほかのインプリメンテーションコマンドと同様、 place_design コマンドはインクリメン

タルに実行されます。部分的に配置されているデザインに対しては、始めから配置し直すのではなく、既存の配置

が開始点として使用されます。

place_design の構文

place_design [-directive <arg>] [-no_timing_driven] [-timing_summary] [-unplace] [-post_place_opt] [-fanout_opt] [-no_bufg_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 オプション

配置は通常デザインの全体的なパフォーマンスにも影響するので、 -directive オプションの指示子が多数あり

ます。表 2-5 に、どの指示子がどのようなデザインに効果的かを示します。

表 2-5: -directive オプションのガイドライン

指示子効果が得られるデザイン

BlockPlacement ブロック RAM または DSP ブロック、あるいはその両方を多数含むデザイン

ExtraNetDelay 遠距離のネット接続を含むデザインおよび多数の異なるモジュールにファンアウ

トするネットを含むデザイン

SpreadLogic 接続が多数ある密集が発生しやすいデザイン

ExtraPostPlacementOpt すべてのタイプのデザイン

SSI 密集を緩和したりタイミングを向上するため、異なる分割方法が有益である可能

性のある SSI デザイン。





-directive オプションで指定可能な指示子

• Explore:

詳細配置および配置後の適化のエフォートを増加します。

• WLDrivenBlockPlacement:

RAM および DSP ブロックをワイヤ長に基づいて配置します。タイミングドリブンの配置を無効にし、ブロッ

クとの接続距離を短にするよう配置します。 RAM および DSP ブロックへのパスおよびこれらのブロックか

らのパスのタイミングを向上できます。

• EarlyBlockPlacement:

RAM および DSP ブロックをタイミングドリブンに配置します。 RAM および DSP ブロックの位置は、配置プ

ロセスの早い段階で固められ、残りのロジックを配置するためのアンカーとして使用されます。

• ExtraNetDelay_high:

ファンアウトが大きく距離の長いネットの見積もり遅延を増加します。 place_design コマンドの後にはタイ

ミングが満たされていたが、過剰に良く見積もられた遅延のために route_design コマンドの後タイミングが

満たされなくなったクリティカルパスのタイミングを向上できます。 high および low の 2 つのレベルがサポー

トされます。 ExtraNetDelay_high では増加量がも大きくなります。

• ExtraNetDelay_low:

ファンアウトが大きく距離の長いネットの見積もり遅延を増加します。 place_design コマンドの後にはタイ

ミングが満たされていたが、過剰に良く見積もられた遅延のために route_design コマンドの後タイミングが

満たされなくなったクリティカルパスのタイミングを向上できます。 high および low の 2 つのレベルがサポー

トされます。 ExtraNetDelay_low では増加量がも小さくなります。

• SSI_SpreadLogic_high:

密集した領域が作成されないように、ロジックを SSI デバイス全体に分散します。 high および low レベルがサ

ポートされます。 SpreadLogic_high では分散度がも高くなります。

• SSI_SpreadLogic_low:

密集した領域が作成されないように、ロジックを SSI デバイス全体に分散します。 high および low レベルがサ

ポートされます。 SpreadLogic_low では分散度がも低くなります。

• AltSpreadLogic_high:

密集した領域が作成されないように、ロジックをデバイス全体に分散します。 high、 medium、 low の 3 つのレベ

ルがサポートされます。 AltSpreadLogic_high では分散度がも高くなります。

• AltSpreadLogic_medium:


ルがサポートされます。 AltSpreadLogic_medium では分散度が中程度になります。

• AltSpreadLogic_low:


ルがサポートされます。 AltSpreadLogic_low では分散度がも低くなります。

• ExtraPostPlacementOpt:

配置後の適化のエフォートを増加します。

• ExtraTimingOpt:

後のステージ中、タイミングドリブンの配置に代わりのアルゴリズムセットを使用します。

• SSI_SpreadSLLs:

SLR 間で分割を実行し、接続の多い領域に追加のエリアを割り当てます。

• SSI_BalanceSLLs:

SLR 間で SLL のバランスが取られるように SLR 間で分割を実行します。





• SSI_BalanceSLRs:

SLR 間でセルの数のバランスが取られるように SLR 間で分割を実行します。

• SSI_HighUtilSLRs:

各 SLR でロジックを近くに配置するよう指定します。



• Quick:

有効なデザインを得るために、も高速な、タイミングドリブンでない、低限の配置を実行します。

• Default:

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 オプションの使用

配置結果をより詳細に解析するには、 -verbose オプションを使用して、 place_design コマンドによるセルおよ

び I/O 配置の詳細を確認します。

-verbose オプションを使用すると大量のメッセージが表示されるので、デフォルトではオフになっています。

-verbose オプションは、有益な場合にのみ使用します。





-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





-fanout_opt オプションの使用

オプションのファンアウト適化フェーズでは、ファンアウトの大きいネット (ファンアウト > 1000、スラック < 2.0

ns) を駆動するレジスタ、または離れて配置された (スラック < 0.5 ns) 専用ブロックロード (ブロック RAM、 FIFO、

UltraRAM、 DSP) に接続されたネットを駆動するレジスタが複製されます。実際のファンアウトが MAX_FANOUT プ

ロパティ値よりも大きいネットもファンアウト適化フェーズに追加されます。このフェーズは配置フローの初期

のグローバル配置中に実行され、詳細な配置の前にこれらのパスのタイミングクリティカル度を軽減するのに有益

です。複製は、 MAX_FANOUT 属性を使用した合成中に実行するよりも、配置中に実行する方が望ましいことがほと

んどです。 place_design 前に実行される複製とは異なり、配置がわかっているので、複製されたドライバーを

ロードと同時に配置することが可能なので、配置がわからずに複製する場合に発生する可能性のある密集を軽減で

きます。配置のファンアウト適化フェーズでの物理合成は、 -fanout_opt オプションを使用するとイネーブル

になります。このフェーズの後に、物理合成適化のサマリを示す表が表示されます。

Summary of Physical Synthesis Optimizations============================================-----------------------------------------------------------------------------------------------------| Optimization | Added Cells | Removed Cells | Optimized Cells/Nets | Dont Touch | Iterations | Elapsed|-----------------------------------------------------------------------------------------------------| Very High Fanout | 594 | 0 | 65 | 0 | 1 | 00:08:25 || Fanout | 26 | 0 | 3 | 0 | 1 | 00:00:27 || Critical Cell | 2 | 0 | 2 | 0 | 1 | 00:00:05 || Critical Cell | 0 | 0 | 0 | 0 | 1 | 00:00:00 || Total | 622 | 0 | 70 | 0 | 4 | 00:08:57 |-----------------------------------------------------------------------------------------------------

図 2-15: 配置の物理合成サマリの例

-no_bufg_opt オプションの使用

配置では、ファンアウトの大きいネットをグローバル配線を使用して配線し、ファブリックの配線リソースを解放

できます。制御信号を駆動し、ファンアウトが大きく (ファンアウト > 1000) スラックが 1.0 ns を超えるネットが、こ

の適化で考慮されます。ロードは、クリティカルロードと正の値が大きいスラックのロードに分けられます。正

の値が大きいスラックのロードは、元のドライバーにも近い使用可能なサイトに配置されている BUFGCE を介し

て駆動され、クリティカルロードは元のドライバーに接続されたままになります。この適化は、タイミングが悪

化しない場合にのみ実行されます。このフェーズは、配置が比較的安定した配置フローの後の方で実行されます。

ディスエーブルにするには、 -no_bufg_opt オプションを使用します。





物理最適化

物理適化では、デザインの負のスラックパスに対してタイミングドリブンの適化が実行されます。物理適化

には、配置後と配線後の 2 つのモードがあります。

配置後モードでは、セル配置からのタイミング見積もりに基づいて適化が実行されます。物理適化では、ロ

ジック適化によるネットリストの変更が自動的に組み込まれ、必要に応じてセルが配置されます。

配線後モードでは、実際の配線遅延に基づいて適化が実行されます。ロジックの変更に応じた自動的なネットリ

ストのアップデートおよびセルの配置に加え、必要に応じて配線もアップデートされます。

重要: 配線後の物理適化は、タイミングが満たされないパスを多少含むデザインで使用するとも効果的です。

WNS が -0.200 ns 未満であるか、タイミングを満たすことのできないエンドポイントが 200 を超えるようなデザイン

で配線後の物理適化を使用すると、 QOR (結果の品質) への改善はほとんど見られないのに、実行時間が長くなる

ことがあります。

全体的な物理適化は、適化が多く実行される配置後モードで大に実行されます。配線後モードでは、タイミ

ングクロージャが達成された配線に影響しないように、物理適化は控えめに実行されます。物理適化を実行す

る前にデザインの配線ステータスがチェックされ、配置後または配線後のどちらのモードを使用するかが判断され

ます。

デザインのスラックが負でなく、タイミングベースの適化オプションで物理適化を指定した場合、適化は実

行されずにコマンドが終了します。物理適化では、実行時間とデザインパフォーマンスのバランスを取るため、

タイミングが満たされていないパスすべてが適化されるわけではなく、タイミング違反が大きい方から数パーセ

ントのみが適化されます。このため、物理適化を連続して実行すると、デザインでタイミングが満たされてい

ないパスの数が徐々に少なくなる可能性があります。

使用可能な物理最適化

Vivado ツールでは、インメモリデザインに対して次の表に示すように物理適化が実行されます。

重要: 特定の物理適化に対応するコマンドオプションを指定すると、その適化のみが実行されます。ほかの適

化は、通常デフォルトで実行されるものも、ディスエーブルになります。

表 2-6: 配置後および配線後の物理最適化

オプション名配置後配線後

実行可能デフォルト実行可能デフォルト

ファンアウトの大きいネットの適化 ○ ○ × なし

配置の適化 ○ ○ ○ ○

配線の適化 × なし ○ ○

リワイヤ ○ ○ ○ ○

クリティカルセルの適化 ○ ○ ○ ○

DSP レジスタの適化 ○ ○ × なし

ブロック RAM レジスタの適化 ○ ○ × なし

UltraRAM レジスタの適化 ○ × × なし





ファンアウトの大きいネットの最適化

ファンアウトの大きいネットの適化は、次のように実行されます。

1. 負のスラックが WNS のある割合以内であるファンアウトの大きいネットは、複製が考慮されます。

2. ロードはその配置によりクラスター化され、各ロードクラスターに対してドライバーが複製および配置されます。

タイミングが再解析され、タイミングが改善した場合はロジックの変更が確定されます。

ヒント : 複製されたオブジェクトの名前は、元のオブジェクト名に _replica と複製されたオブジェクトカウント

が付いたものになります。

配置ベースの最適化

クリティカルパスのすべてのセルをワイヤ遅延を削減するように配置し直します。

配線の最適化

クリティカルパスのネットおよびピンを遅延を小さくするよう配線し直します。

リワイヤ

LUT の接続をスワップしてクリティカル信号のロジックレベル数を削減することにより、クリティカルパスを適

化します。 LUT 論理式を変更してデザインの機能を保持します。

クリティカルセルの最適化

タイミングが満たされないパスのセルを複製します。特定のセルのロードどうしが離れている場合、セルが複製さ

れ、新しいドライバーがロードクラスターの近くに配置されます。この適化は、パスがワーストネガティブス

ラックのある割合以内でタイミングを満たしていなければ、ファンアウトが大きくなくても実行されます。

シフトレジスタの適化 ○ ○ × なし

クリティカルピンの適化 ○ ○ × なし

ブロック RAM イネーブルの適化 ○ ○ × なし

ホールド違反の修正 ○ × × なし

立ち下がりエッジ FF の挿入 ○ × × なし

リタイミング ○ × ○ ×

ネットの強制的な複製 ○ × × なし

SLR をまたぐパスの適化 × なし ○ ○

クロックの適化 × なし ○ ○

表 2-6: 配置後および配線後の物理最適化 (続き)

オプション名配置後配線後

実行可能デフォルト実行可能デフォルト





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-16)。





シフトレジスタの適化後、タイミングを向上するため、シフトレジスタの終段が SRL16E から取り出されてロ

ジックファブリックに配置されました (図 2-17)。

srl_inste の SRL16E アドレスは、内部レジスタ段が 1 つ少なくなったことを反映して減少されます。 srlopt レ

ジスタがダウンストリームセルの近くに配置され、 FDRE セルの clock-to-output 遅延は比較的短いので、元のクリ

ティカルパスは短くなります。

クリティカルピンの最適化

論理 LUT 入力ピンを高速の物理ピンに再マップし、クリティカルパスのタイミングを向上します。 A1 や A2 などの

低速の物理ピンにマップされているクリティカルパス上の論理ピンが、タイミングが向上する場合に A6 や A5 など

の高速の物理ピンに割り当て直されます。 LOCK_PINS プロパティが設定されているセルはスキップされ、

LOCK_PINS で指定されているピンマップが保持されます。論理ピンと物理ピンのマップを取得するには、

get_site_pins コマンドを使用します。


図 2-16: シフトレジスタ srl_inste から開始するクリティカルパス


図 2-17: シフトレジスタ最適化後のクリティカルパス





ブロック RAM イネーブルの最適化

ブロック RAM イネーブルを適化すると、消費電力適化されたブロック RAM に関連するクリティカルパスのタ

イミングを向上できます。

配置前のブロック RAM 消費電力適化では、ダイナミック消費電力を削減するために、ブロック RAM の読み出し

および書き込みイネーブル入力を駆動するロジックが再構築されます。配置後、再構築されたロジックがタイミン

グクリティカルになる可能性があります。ブロック RAM イネーブルの適化を実行すると、イネーブルロジック

の適化が元に戻され、クリティカルなイネーブルロジックパスのスラックが向上します。

ホールド違反の修正

ホールドクリティカルパスの遅延を増加することにより、ホールド違反の大きいパスのスラックを向上します。

ヒント : ホールド違反の修正では、特定のしきい値を超えるホールドタイムのみが修正されます。これは、配線でそ

のしきい値よりも低いホールドスラック違反が修正されるはずだからです。

立ち下がりエッジレジスタの挿入

立ち下がりエッジで動作するレジスタを挿入し、困難なホールド違反を修正します。レジスタを挿入すると、ホー

ルドクリティカルタイミングパスが 2 つの 1/2 周期パスに分割され、ホールド要件を満たしやすくなります。立ち

下がりエッジで動作するレジスタの挿入のみがサポートされ、 2 つの立ち上がりエッジで動作するシーケンシャル

セル間のホールド違反が修正されます。

リタイミング

レジスタを組み合わせロジックの前後に移動することにより、クリティカルパスの遅延を向上します。

ネットの強制的な複製

タイミングスラックにかかわらず、ネットのドライバーを強制的に複製します。複製はロードの配置に基づいて実

行され、複製が十分かどうかを解析する必要があります。さらに複製が必要な場合は、コマンドを複数回実行する

ことによりネットを繰り返し複製できます。タイミングは無視されますが、複製を実行するには、ネットがタイミ

ング制約の設定されたパスに含まれている必要があります。

SLR をまたぐパスの最適化

SLR 間の接続のパス遅延を削減するため、配線後の適化を実行します。この適化では、複製の後に SLR をまた

ぐ部分のドライバー、ロード、またはその両方の位置を調整します。これは、 UltraScale および UltraScale+ デバイス

のみに適用されます。

クロックの最適化

グローバルバッファーを挿入し、クリティカルパスの始点と終点の間にスキューを挿入します。セットアップタイ

ミングを向上するため、デスティネーションクロックを遅延するバッファーが挿入されます。

配線の最適化

遅延を削減するためタイミングクリティカルネットに対して配線適化を実行します。





パスグループの最適化

指定されたパスグループだけを適化します。

ヒント : group_path という Tcl コマンドを使用して、適化の対象となるパスグループを設定します。

物理最適化のメッセージ

ヒント : 物理適化では、適化で処理された各ネットと、実行された適化のサマリがレポートされます。

次の図に示すように、物理適化の後にサマリが表示され、各適化段階の統計やデザインパフォーマンスへの

影響などがレポートされます。このレポートを見ると、 WNS を改善するのにも効果的な適化のタイプがわかり

ます。

phys_opt_design

デザインに対して物理適化を実行します。配置後に配置後モードで、またはデザインを完全に配線した後に配線

後モードで実行できます。

phys_opt_design の構文

phys_opt_design [-fanout_opt] [-placement_opt] [-routing_opt] [-slr_crossing_opt] [-rewire] [-insert_negative_edge_ffs] [-critical_cell_opt] [-dsp_register_opt] [-bram_register_opt] [-uram_register_opt] [-bram_enable_opt] [-shift_register_opt] [-hold_fix] [-retime] [-force_replication_on_nets <args>] [-directive <arg>] [-critical_pin_opt] [-clock_opt] [-path_groups <args>] [-quiet] [-verbose]


図 2-18: 物理合成最適化のサマリ





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 が実行され、結果が保存されます。配置後および配線後の物理適化の両方で、同じ

phys_opt_design コマンドが使用されます。モードを指定するためにオプションを使用する必要はありません。


-directive オプションで指示子を指定すると、 phys_opt_design コマンドを異なるモードで実行できます。一

度に指定できる指示子は 1 つのみです。 -directive オプションは、ほかのオプションと共に使用することはでき

ません。次に設定可能な指示子を示します。

• Explore:

かなりファンアウトの大きいネットの複製、およびクリティカルパス適化 (物理適化のサブセットがス

ラックに関係なくすべての終点クロックの上位クリティカルパスで実行) と呼ばれる終段階など、複数の

適化パスで異なるアルゴリズムを実行します。

• ExploreWithHoldFix:

適化を複数回実行し、ホールド違反の修正およびファンアウトの大きいネットの複製を含め、異なるアルゴ

リズムを実行します。

ヒント : ホールド違反の修正では、特定のしきい値を超えるホールドタイムのみが修正されます。これは、配線でそ

のしきい値よりも低いホールドスラック違反が修正されるはずだからです。

• AggressiveExplore:

Explore と似ていますが、異なる適化アルゴリズムを使用し、より厳しい目標を設定します。

• AlternateReplication:

クリティカルセルの複製に異なるアルゴリズムを使用します。

• AggressiveFanoutOpt:

ファンアウトに関連する適化に異なるアルゴリズムを使用し、より厳しい目標を設定します。

• AddRetime:

デフォルトの phys_opt_design フローを実行し、レジスタのリタイミングを追加します。





• AlternateFlowWithRetiming:

複製と DSP およびブロック RAM の適化をより積極的に実行し、レジスタのリタイミングをイネーブルにし

ます。

• Default:

phys_opt_design をデフォルト設定で実行します。



ヒント : -directive オプションのすべての指示子は、配置後および配線後の phys_opt_design で共通です。

-verbose オプションの使用

物理適化の結果を解析するには、 -verbose オプションを使用し、 phys_opt_design で実行された適化の詳

細を確認します。

-verbose オプションを使用すると大量のメッセージが表示されるので、デフォルトではオフになっています。

-verbose オプションは、有益だと思われる場合に使用してください。

重要: phys_opt_design コマンドは、インメモリデザインに対して実行されます。 2 回実行した場合、 1 回目の

run の結果が適化されます。

物理最適化制約

物理適化中、 DONT_TOUCH プロパティが認識され、これらのプロパティが設定されているネットまたはセルには

適化は実行されません。また、 Pblock の割り当てに従い、複製されたロジックでも元のロジックの Pblock 割り当

てが適用されます。タイミング例外も、元のセルから複製セルにコピーされます。

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

DONT_TOUCH は下位セルに設定します。階層セルに DONT_TOUCH を設定するとセルの境界は保持されますが、セ

ル内では適化が実行される可能性はあります。

MARK_DEBUG プロパティの値が TRUE であるネットには、 DONT_TOUCH プロパティの値が自動的に TRUE に設定さ

れます。これにより、インプリメンテーションフロー中にネットは変更されなくなり、どのデザイン段階でもネッ

トをプローブできます。 MARK_DEBUG は、このように使用することをお勧めします。ただし、 DONT_TOUCH は制限

的すぎ、複製やリタイミングなどの適化が実行されなくなり、タイミングクロージャを達成するのが困難になる

ことがまれにあります。その場合は、 MARK_DEBUG を TRUE に設定したまま、 DONT_TOUCH の値 FALSE に設定でき

ます。ただし、 MARK_DEBUG を設定したネットが適化で削除され、プローブされなくなる可能性があります。

MARK_DEBUG ネットを複製すると、元のネットのみに MARK_DEBUG が保持され、複製されたネットには保持されま

せん。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug901-vivado-synthesis.pdf;a=xSynthesisAttributes




物理最適化レポート

Tcl レポートコマンド report_phys_opt を実行すると、 phys_opt_design で実行された各適化のレポートが

かなり詳細なレベルで表示されるようになります。これは、適化履歴がメモリ内に残っている、

phys_opt_design を実行したのと同じ Vivado セッションで実行する必要があります。このため、レポートが必要

な場合は、 Tcl スクリプトの後の phys_opt_design コマンドの直後に report_phys_opt コマンドを含めてお

くことをお勧めします。

レポートには、配置後の phys_opt_design 適化でのみ使用できます。レポートは、 phys_opt_design の複数

の run も含め、すべての phys_opt_design 適化を反映して蓄積されていきます。

次のレポート例は、 pipeline_en というレジスタを含むファンアウトの適化を示しています。次の詳細がレ

ポートには表示されています。

1. 元のドライバー pipeline_en は 816 のロードを駆動しています。このファンアウトの大きいネットを含むパ

スの WNS は -1.057 ns で、タイミングを満たしていません。

2. ドライバー pipeline_en が新しいセル pipeline_en_replica を作成するために複製されています。

3. 816 のロードが 386 ロードの pipeline_en_replica と残りの 430 ロードの元のドライバー pipeline_en に

分割されています。

4. pipeline_en_replica の複製と配置後は、 pipeline_en_replica パスの WNS が +0.464 ns になり、

pipeline_en パスの WNS が 0 に削減されています。

5. 元のドライバー pipeline_en の配置が変更され、削減されたロードのセットの位置に基づいて WNS が改善さ

れています。

インタラクティブ物理最適化

2015.3 リリースから、インタラクティブ Tcl コマンド iphys_opt_design を使用して適化を再実行する機能が物

理適化に追加されています。 iphys_opt_design コマンドでは、クリティカルセルの複製やブロック RAM から

のレジスタの取り出しなど、実行された特定の適化が記述されています。このコマンドには、ネットリストおよ

び適化に必要な配置の変更を再実行するために必要な情報がすべて含まれています。

インタラクティブ物理適化は、次の 2 つの方法で使用できます。

• 全体的な配置結果とデザインパフォーマンスを向上するため、配置前のネットリストに配置後の物理適化を

適用する。

• 物理適化を必要に応じて繰り返すことができるように Tcl スクリプトに保存する。


図 2-19: ファンアウト最適化レポート





phys_opt_design によるネットリスト変更を配置前に組み込む

次の図に、物理適化の変更を配置前のネットリストに組み込むデザインフローを示します。

2 つの run があり、元の run (Original Run) では、 place_design の後に phys_opt_design を実行します。再実行

run (Replay Run) では、配置の前に phys_opt_design を実行します。

元の run の後、 Tcl コマンド write_iphys_opt_tcl を使用して、 phys_opt_design の適化を Tcl スクリプト

ファイルに保存します。このスクリプトには一連の iphys_opt_design Tcl コマンドが含まれており、元の run で

phys_opt_design により実行されたデザインの変更を再実行します。適化はメモリ内の現在のデザインから保

存するか、 phys_opt_design で適化が実行されたインプリメント済みデザインまたはチェックポイントを開い

て保存できます。

再実行 run にも、同じデザインと制約を使用します。 place_design を実行する前に、 read_iphys_opt_tcl コ

マンドで iphys_opt_design コマンドスクリプトを実行し、元の run からのネットリストの変更を適用します。

このネットリストの変更により、再実行 run のデザインが元の run よりもより配置に適したものになる可能性があり

ます。複製によるファンアウトの大きいネットの削減、ブロック RAM 出力からの長いパスの削減など、

phys_opt_design 適化を配置前に組み込むことができます。

phys_opt_design コマンドと同様に、 read_iphys_opt_tcl コマンドにも、ファンアウト適化、ブロック

RAM レジスタの適化、リワイヤなど、再実行する適化のタイプを指定するオプションがあります。


図 2-20: 物理最適化の変更を配置前のネットリストに組み込むデザインフロー





phys_opt_design のデザイン変更を繰り返す

次の図に、 phys_opt_design のデザイン変更を繰り返すデザインフローを示します。

このフローは、適化による変更を配置前に組み込むフローとは次の 2 つの点が異なります。

• iphys_opt_design の変更は place_design の後に組み込まれます。

• 配置の変更およびネットリストの変更は、 iphys_opt_design Tcl スクリプトに記述されます。

このフローは通常、配置後の phys_opt_design の実行をより詳細に制御するために使用します。適化の繰り返

しおよび新しい適化の組み合わせからカスタム処理が作成され、デザインクロージャを達成するためのさまざま

な方法を試すことができます。

write_iphys_opt_tcl および read_iphys_opt_tcl コマンドには、 phys_opt_design による配置の変更を

再実行する -place オプションがあります。このフローでは、このオプションを使用して phys_opt_design を配

置後に繰り返します。


図 2-21: phys_opt_design の変更を繰り返すデザインフロー





インタラクティブ物理最適化コマンドの説明

次に、インタラクティブ物理適化コマンドとそのオプションの説明を示します。

write_iphys_opt_tcl

現在のデザインで実行した物理適化を記述した一連の iphys_opt_design Tcl コマンドを含むファイルを出力し

ます。

構文:

write_iphys_opt_tcl [-place] [-quiet] [-verbose] <output file>

-place オプションを使用すると、 iphys_opt_tcl コマンドに配置情報が含まれます。 iphys_opt_design コマ

ンドの実行中にネットリストの変更に配置を適用する場合に使用します。

write_iphys_opt_tcl コマンドは、 phys_opt_design を実行した後であればいつでも使用できます。

read_iphys_opt_tcl

前の run で実行した物理適化を記述した iphys_opt_design Tcl コマンドを含むファイルを読み出します。

構文:

read_iphys_opt_tcl [-fanout_opt] [-critical_cell_opt] [-placement_opt] [-rewire] [-dsp_register_opt] [-bram_register_opt] [-shift_register_opt] [-critical_pin_opt] [-clock_opt] [-include_skipped_optimizations] [-place] [-quiet] [-verbose] <input file>

read_iphys_opt_design コマンドには phys_opt_design と同じオプションが多数あり、再実行する適化を

指定できます。オプションには、 -fanout_opt、 -critical_cell_opt、 -placement_opt、 -rewire、

-dsp_register_opt、 -bram_register_opt、 -shift_register_opt、 -critical_pin_opt、および

-clock_opt があります。

入力 Tcl スクリプトで定義されているスキップされた適化と、標準適化を適用します。これらは、

phys_opt_design により適化されたロジックに適切な場所が見つからなかったためにスキップされた適化で

す。このオプションを指定した場合、 iphys_opt_design コマンドは配置前のネットリストにスキップされた

適化を適用しようとします。





iphys_opt_design

iphys_opt_design コマンドは、物理適化を実行する下位の Tcl コマンドです。 phys_opt_design のデフォル

トの適化をすべて iphys_opt_design で実行できます。 iphys_opt_design コマンドを変更したり、初から

作成することは可能ですが、通常はスクリプトに含めて別の run で再実行します。

推奨: iphys_opt_design コマンドのスクリプトを source Tcl コマンドを使用して実行しないでください。コマンド

を効率的に短時間で実行するには、 read_iphys_opt_tcl コマンドを使用してください。

構文:

iphys_opt_design [-fanout_opt] [-critical_cell_opt] [-placement_opt] [-rewire] [-net <arg>] -cluster <args> -place_cell <args> [-place] [-dsp_register_opt] [-bram_register_opt] [-uram_register_opt] [-shift_register_opt] [-cell <arg>] [-packing] [-unpacking] [-port <arg>] [-critical_pin_opt] [-skipped_optimization] [-insert_negative_edge_ffs] [-quiet] [-verbose]

配線

Vivado 配線では、配置済みデザインに配線を実行し、ホールドタイム違反を解決するように配線済みデザインが

適化されます。

配置済みデザインから開始し、すべてのネットの配線を試みます。まだ配線されていないか、部分的に配線されて

いるか、完全に配線されている配置済みデザインから開始できます。

部分的に配線されているデザインでは、始めから配線し直さず、既存の配線が開始点として使用されます。完全に

配線済みのデザインでは、タイミング違反がチェックされ、タイミングを満たすためにクリティカル部分が配線し

直されます。

注記: 再配線プロセスでは、既存の配線が破棄されて配線し直されます。

配線では、デザイン全体を配線するオプションと、ネットおよびピンを個別に配線するオプションがあります。

デザイン全体を配線する場合、フローはタイミングドリブンであり、タイミング制約に基づく自動タイミングバ

ジェットが使用されます。

個別のネットおよびピンの配線は、次の 2 つのモードを使用して実行できます。

• インタラクティブ配線モード

• 自動遅延モード

インタラクティブ配線モードでは、インタラクティブセッションの応答をよくするため、高速で軽量のタイミング

モデルが使用されます。一部の遅延精度が犠牲となり、不必要に悪い見積もり遅延が使用されます。このモードで

はタイミング制約は無視されますが、配線の実行方法を選択できます。

• リソースベースの配線 (デフォルト ): 使用可能な配線リソースから選択され、配線の実行時間は短になります。

• 小遅延 (-delay オプション): 使用可能な配線リソースから、遅延が小になるように選択されます。

• 遅延ドリブン (-max_delay および -min_delay オプション): 大遅延、小遅延、またはその両方を基に、

タイミング要件を指定します。指定の要件を満たす遅延のネットが配線されます。





自動遅延モードでは、タイミング制約に基づく自動タイミングバジェットを使用するタイミングドリブンのフロー

が実行されますが、デフォルトフローとは異なり、指定のネットまたはピンのみが配線されます。このモードは、

デザイン全体を配線する前にクリティカルネットおよびピンを配線するために使用します。これには、セットアッ

プクリティカル、ホールドクリティカル、またはその両方であるネットおよびピンが含まれます。自動遅延モード

は、多量の配線が含まれるデザインのネットを個別に配線するためのものではありません。インタラクティブ配線

を使用してください。

多数のネットおよびピンを配線する際に高の結果を得るには、優先順に配線します。これにより、配線リソース

の競合を回避できます。

配線では、ネットおよびピンの配線を修正する場合でも、初期化のため、初の実行時間は長くなります。初期化

時間は、デザインのサイズおよびデバイスのサイズが大きくなると長くなります。 1 回初期化されると、デザインを

閉じて開き直さない限り、再度初期化は実行されません。

デザインルールチェック配線を開始する前に、次のデザインルールチェック (DRC) が実行されます。

• report_drc コマンドを使用してユーザーが選択した DRC

• Vivado 配線エンジンに含まれるビルトインの DRC

配線の優先順位

Vivado Design Suite では、クロック、リセット、その他の専用リソースなどのグローバルリソースが初に配線され

ます。

このデフォルトの優先順位は Vivado 配線にビルトインされています。その後、タイミングのクリティカル度合いに

基づいて、データ信号に優先順位が付けられます。

正しく設定されていないタイミング制約の影響

配線後のタイミング違反は、タイミングが制約が正しく設定されていないために発生していることがあります。配

線設定を変更してみる前に、制約が正しく設定されていることを確認してください。配線の前の配置済みデザイン

のタイミングレポートを参照して、タイミングと制約を確認します。

次に、よくある正しく設定されていないタイミング制約の例を示します。

• クロックドメインをまたがるパスや、正のホールドタイム要件により配線遅延が追加される複数サイクルパス

• 密集しているエリア。これは RTL 合成のファンアウト適化や物理適化により解決できます。

推奨: 複数の配線オプションを試す前に、タイミング制約を確認して正しくない制約を修正するか、または RTL を変

更することを考慮してください。詳細は、『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949) [参照 13] のこ

のセクションを参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug949-vivado-design-methodology.pdf;a=xCheckingThatYourDesignIsProperlyConstrained

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug949-vivado-design-methodology.pdf;a=xCheckingThatYourDesignIsProperlyConstrained




配線タイミングサマリ

配線プロセスの後に、実際の配線遅延を使用して算出されたタイミングサマリ (見積もり ) がレポートされます。

タイミングサマリの算出には、実行時間を短縮するため、完全なタイミング計算を実行するのではなく、インクリ

メンタルタイミングアップデートが使用されます。そのため、見積もられた WNS が実際のタイミングよりも数ピ

コ秒ほど悪いものになる可能性があります。そのため、実際の WNS は正であるのに、配線でレポートされる WNS

が負となることがあります。配線でレポートされる見積もられた WNS が負の場合、メッセージはクリティカル警告

ではなく警告となります。

ヒント : route_design -directive Explore を実行する場合は、配線タイミングサマリはサインオフタイミング

に基づきます。

重要: report_timing_summary を実行するか、 route_design を -timing_summary オプションを使用して実

行し、実際のサインオフタイミングを確認してください。

route_design

デザインを配線します。

route_design の構文

route_design [-unroute] [-release_memory] [-nets <args>] [-physical_nets] [-pins <arg>] [-directive <arg>] [-tns_cleanup] [-no_timing_driven] [-preserve] [-delay] [-auto_delay] -max_delay <arg> -min_delay <arg> [-timing_summary] [-finalize] [-quiet] [-verbose]


デザイン全体を配線する際に -directive オプションで指示子を指定すると、 route_design コマンドを異なる

モードで実行できます。一度に指定できる指示子は 1 つのみです。 -directive オプションは、適化の競合を回

避するため、ほかのほとんどのオプションとは共に使用することができません。次の指示子があります。

• Explore:

初期配線の後、異なるクリティカルパス配線を試します。

• NoTimingRelaxation:

配線を完了するためにタイミングを緩和しないようにします。配線でタイミング満たすのが困難である場合、

元のタイミング制約を満たすため実行時間が長くなります。

• MoreGlobalIterations:

終段階だけでなく、すべての段階で詳細なタイミング解析を使用し、タイミングの向上が少しであってもグ

ローバル反復を実行します。

• HigherDelayCost:

配線の内部コスト関数を調整して反復実行で遅延に焦点を置き、実行時間が長くなる代わりにパフォーマンス

を向上します。







• AlternateCLBRouting:

実行時間は長いが配線の密集を緩和する代替配線アルゴリズムを選択します。

• Quick:

有効なデザインを得るために、も高速な、タイミングドリブンでない、低限の配置を実行します。

• Default:

route_design をデフォルト設定で実行します。

よりよい配線結果を得るために実行時間を長くする

-directive オプションの次の指示子を使用すると、実行時間は長くなりますが、よりよい配線結果が得られる可

能性があります。

• NoTimingRelaxation

• MoreGlobalIterations

• HigherDelayCost

• AdvancedSkewModeling

route_design コマンドのその他のオプションの使用

次に、 route_design コマンドのその他のオプションの詳細と値を示します。

• -nets

指定したネットのリストにのみ処理を実行します。ネットオブジェクトの Tcl リストを引数として指定します。

ネットは、ネット名の文字列値で指定するのではなく、 get_nets コマンドを使用してネットオブジェクトと

して指定する必要があります。

• -pins

指定したピンにのみ処理を実行します。ピンオブジェクトの Tcl リストを引数として指定します。ピンは、ピ

ン名の文字列値で指定するのではなく、 get_pins コマンドを使用してピンオブジェクトとして指定する必要

があります。

• -delay

デフォルトでは、タイミングクリティカルかどうかにかかわらず、各ネットおよびピンが使用可能なリソース

を使用して短の実行時間で配線されます。 -delay オプションを使用すると、遅延が小になるように配線され

ます。

• -min_delay および -max_delay

これらのオプションは -pin オプションを使用している場合にのみ使用可能で、ターゲット遅延をピコ秒で指定

します。 -max_delay オプションは、指定のピンの配線に使用する大 slow-max コーナー遅延を指定します。

同様に、 -min_delay オプションは小 fast-min コーナー遅延を指定します。両方のオプションを使用して、

遅延の範囲を指定できます。

• -auto_delay

-nets または -pins オプションと共に使用し、タイミング制約ドリブンモードで配線します。タイミングバ

ジェットはタイミング制約から自動的に算出されるので、 -min_delay、 -max_delay、または -delay と共に

使用することはできません。





• -preserve

既存の配線を保持してデザイン全体を配線します。 -preserve オプションを使用しない場合、クリティカル

パスのタイミングを向上するため、既存の配線が解除され、配線し直されることがあります。このオプション

は、クリティカルネットを事前に配線し、配線リソースに優先的にアクセスできるようにする場合によく使用

されます。これらの配線が完了したら、 -preserve オプションを使用して、デザインの残りの部分が配線され

るときに完了した配線が変更されないようにします。このオプションは、 FIXED_ROUTE および

IS_ROUTE_FIXED ネットプロパティとは無関係で、使用した route_design コマンドの実行でのみ配線が保

持されます。 -preserve オプションは -directive オプションと共に使用できますが、 -directive

Explore オプションは配置を変更し、その結果配線も変更するので、 -preserve オプションと共に使用する

ことはできません。

• -unroute

デザイン全体、あるいは -nets または -pin オプションを使用している場合はネットおよびピンの配線を解除しま

す。 FIXED_ROUTE プロパティが設定されているネットの配線は解除されません。 FIXED_ROUTE プロパティが

設定されているネットの配線を解除するには、まずプロパティを削除する必要があります。

• -timing_summary

デフォルトでは、内部見積もりタイミングに基づいたタイミングサマリが出力されますが、遅延の見積もりが

不必要に悪いため、実際の配線後のタイミングとは異なる場合があります。 -timing_summary オプションを

使用すると、 Vivado スタティックタイミング解析機能が呼び出され、実際の配線遅延に基づくタイミングサマ

リがレポートされます。スタティックタイミング解析のため、実行時間は長くなります。 -directive

Explore オプションを使用する場合、 -timing_summary オプションは無視されます。

-directive Explore オプションを使用すると、 -timing_summary オプションを使用するかどうかにかか

わらず、も正確なタイミングアップデートを得るため Vivado スタティックタイミング解析機能が呼び出され

ます。

• -tns_cleanup

実行時間を短にするため、配線ではトータルネガティブスラック (TNS) を削減することではなくワーストネ

ガティブスラック (WNS) パスを向上することに焦点が置かれます。 -tns_cleanup オプションを使用すると、

配線の後に追加のフェーズが実行され、タイミングが満たされていないすべてのパスを修正して TNS を削減

するよう試みられます。そのため、 TNS は削減される可能性がありますが、実行時間が長くなることがあり、

WNS には影響しない場合があります。配線の後に配線後の物理適化を実行する場合は、配線に

-tns_cleanup オプションを使用してください。このオプションを使用すると、物理適化で WNS パスに焦

点が置かれ、配線で修正可能なクリティカルでないパスに無駄なエフォートが費やされるのを防ぐことができ

ます。既に配線済みのデザインで route_design -tns_cleanup を実行すると、配線の TNS クリーンアップ

段階のみが実行され、 WNS には影響しません (TNS クリーンアップは再配線で実行)。このオプションは、

-directive オプションと共に使用できます。

• -physical_nets

論理 0 および論理 1 の配線のみに処理を実行します。デザインのすべての定数値に適用されます。 -unroute

オプションと共に使用できます。定数 0 および 1 を接続すると、物理デバイスに対応する論理ネットがないの

で、これらのネットは -nets および -pins オプションを使用して確実に配線または配線解除できません。





• -release_memory

配線初期化の後、適なパフォーマンスのため、配線データはメモリに保持されます。このオプションを使用

すると、データがメモリから削除され、メモリがオペレーティングシステムに返されます。ほとんどの場合、

このオプションを使用する必要はありません。非常に大型のデザインを処理する場合など、配線のメモリ使用

量を手動で制御する必要がある場合に使用します。

• -finalize

配線をインタラクティブに実行している場合、 route_design -finalize を指定して部分的に配線された接

続を完了できます。

UltraScale+ デザインの場合、レジスタの配置配線が ECO タスクの一部として変更されている場合は、このス

テップは必要です。

• -no_timing_driven

タイミングドリブン配線をオフにします。主にデザインの配線性をテストするために使用します。

ヒント : UltraScale デザインでクロックネットが配線されていない場合、そのクロックネットを配線し直す前に

place_design を実行する必要があります。これにより、クロックネットの配線が有効なものになります。この制

限は、今後のリリースで削除される予定です。

配線のサンプルスクリプト 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

route_design サンプルスクリプトでは、次の手順が実行されます。

1. デザインを配線します。

2. 配線が完了したら、デザインチェックポイントを保存します。

3. タイミングサマリレポートを生成します。

4. レポートを指定したファイルに記述します。

配線は、インプリメンテーション run の一部として、または Tcl スクリプトの一部として place_design の後に

route_design コマンドを使用して実行します。

配線ログに、現在のフェーズ (初期化、グローバル配線反復、タイミングアップデート ) などの進捗状況を示す情報

が示されます。グローバル配線の後には、配線により適切なデザインを達成するために試行している間、現在

オーバーラップしているネットの数が定期的にアップデートされます。次に例を示します。

Phase 4.1 Global Iteration 0 Number of Nodes with overlaps = 435 Number of Nodes with overlaps = 3 Number of Nodes with overlaps = 1 Number of Nodes with overlaps = 0

フロー中タイミングアップデートが示され、タイミングクロージャの進捗状況がわかります。





タイミングサマリ

[Route 35-57] Estimated Timing Summary | WNS=0.105 | TNS=0 | WHS=0.051 | THS=0

説明:

° WNS: ワーストネガティブスラック

° TNS: トータルネガティブスラック

° WHS: ワーストホールドスラック

° THS: トータルホールドスラック

注記: 中間の配線フェーズでは、ホールドタイム解析がスキップされる場合があります。ホールドタイム解析が実

行される場合、 WHS および THS に対して「N/A」という値が示されます。

配線が完了すると、配線リソースの使用率サマリと終的なタイミングサマリ (見積もり ) がレポートされます。次

に、配線リソース使用率サマリの例を示します。

配線リソース使用率サマリ

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


# 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 コマンドでは、配線機能が初期化されてから、クロックなどの重要なネットが配線されます。






# get nets of the top 10 setup-critical pathsset preRoutes [get_nets -of [get_timing_paths -max_paths 10]]

# get nets of the top 10 hold-critical pathslappend preRoutes [get_nets -of [get_timing_paths -hold -max_paths 10]]

# route $preRoutes based on timing constraintsroute_design -nets [get_nets $preRoutes] -auto_delay

# preserve the routing for $preRoutes and continue with the rest of the designroute_design -preserve

このサンプルスクリプトでは、サンプルスクリプト 2 と同様に、まずいくつかのクリティカルネットを配線してそ

の後デザイン全体を配線していますが、 -delay オプションではなく -auto_delay オプションを使用している点が

異なります。クリティカルネットのタイミングドリブン配線が実行され、精度は上がりますが実行時間が長くなり

ます。これは、ネットがセットアップクリティカルパスとホールドクリティカルパスの両方に関連しており、セッ

トアップとホールドの両方の要件を満たすために配線を特定の遅延範囲内にする必要がある場合に特に有益です。


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-7 に、例のコマンドをまとめます。

配線メッセージ

配線では、密集やホールド違反の修正が多すぎるためにタイミング目標を満たすのが難しい場合は、メッセージが

表示されるようになっています。このようなメッセージが表示されるのは、通常次のような場合です。

• イテレーションごとの実行時間が数時間になる場合

• レポートされるオーバーラップが多すぎる (数百または数千の) 場合

• 見積もりタイミングサマリでセットアップおよびホールドスラックが徐々に悪化している場合

配線では、次のいずれかが発生すると、警告メッセージがさらに表示されることがあります。

• 密集のために、タイミングクロージャに悪影響があると判断される場合 (通常は密集レベルが 5 以上の場合)。

レベル 5 は、密集領域が 32x32 (2^5 = 32) と測定されることを意味します。

• 全体的な配線のホールド修正エフォートがかなり高くなると予測される場合 (全体的なセットアップ用件を満た

す機能に影響)。

• 特定の終点ピンがセットアップクリティカルとホールドクリティカルの両方になり、どちらも満たすことが不

可能な場合。メッセージには、デザイン解析用にピン名が高 10 個まで表示されます。





• 特定の CLB のピン使用率または配線リソースの使用率が高い場合 (ローカル密集になる )。メッセージには、

も密集している CLB の名前が大 10 個まで表示されます。

• 深刻な密集があるような極端なケースでは、密集によりすべてのネットが配線できないことを示す警告メッ

セージが表示され、タイミング適化を使用して、ネットの配線が問題なく完了したものが優先されます。

UltraScale デバイスをターゲットにする場合は、密集がタイミングクロージャに影響する可能性のある場合、初に

見積もられた密集を示す表が生成されます。この表には、特定の領域は示されませんが、全体的な検証からのさま

ざまなタイプの密集が表示されます。密集は、 Global (デザイン全体)、 Long (複数の CLB にまたがる密集)、 Short に

分類されます。さまざまな run の表を比較することで、密集の悪影響を受けることなく、パフォーマンス目標を満た

しやすい run がどれかを決定できるようになっています。

INFO: [Route 35-449] Initial Estimated Congestion ________________________________________________________________________| | Global Congestion | Long Congestion | Short Congestion || |___________________|___________________|___________________|| Direction | Size | % Tiles | Size | % Tiles | Size | % Tiles ||___________|________|__________|________|__________|________|__________|| NORTH| 8x8| 0.13| 4x4| 0.11| 32x32| 1.14||___________|________|__________|________|__________|________|__________|| SOUTH| 8x8| 0.21| 4x4| 0.35| 16x16| 1.03||___________|________|__________|________|__________|________|__________|| EAST| 2x2| 0.05| 2x2| 0.15| 8x8| 0.97||___________|________|__________|________|__________|________|__________|| WEST| 2x2| 0.03| 2x2| 0.17| 8x8| 0.83||___________|________|__________|________|__________|________|__________|

[Report Design Analysis] では複雑さおよび密集度の解析が実行されるので、密集の原因と可能性のある回避策がわか

りやすくなることがあります。密集レポートには、平均初期配線密集 (Average Initial Routing Congestion) も含まれま

す。これは、配線でレポートされる密集とまったく同じではありませんが、配線前のデザインに対して解析を実行

して、どの領域が問題の原因となっているのかが判別するために使用できます。 [Report Design Analysis] に関する詳

細は、『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906) [参照 10] を参照し

てください。

中間配線結果

配線を完了できない場合でも、配線処理は続行し、デバッグに使用できるようにできるだけ完成に近いデザインが

生成されます。配線が完了しない場合、手動の変更が必要な場合があります。

report_route_status コマンドを使用すると、配線エラーのあるネットがレポートされます。詳細は、

『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949) [参照 13] のこのセクションを参照してください。

配線では、終段階で配線の密集がレポートされます。密集のも多い領域が方向 (北、東、南、西) 別にリストさ

れ、各領域ごとに、配線タイルの寸法、配線使用率 (Max Cong)、および境界ボックスの座標 (左下から右上) が表示

されます。 INT_xxx の数値は、 [Device] ウィンドウで [Routing Resources] をオンにしたときに表示されるインターコ

ネクト配線タイルの座標です。

表 2-7: 配線中のデザイン解析で使用されるコマンド

コマンド機能

report_route_status ネットの配線ステータスをレポートします。

report_timing パスの終点解析を実行します。

report_design_analysis 密集エリアに関する情報をレポートします。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_route_status

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_timing

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_design_analysis

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug949-vivado-design-methodology.pdf;a=xRouting






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

インクリメンタルコンパイルは、次のようなデザインフローです。

• 基準デザインからの配置配線が再利用され、 QoR (結果の品質) の予測性が保持されます。

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

次の図は、インクリメンタルコンパイルデザインフローを示しています。

注記: 通常の配置配線およびインクリメンタル配置配線のいずれにも、物理適化が含まれる場合があります。


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





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

インクリメンタルコンパイルフロー (図 2-22) では、基準デザインとインクリメンタルデザインの 2 つのデザインを

使用します。再利用のレベルによって、高再利用モードと低再利用モードが切り替えられます。

基準デザイン

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

配置、配線、またはその両方がどれだけ含まれたチェックポイントでも使用可能です。基準デザインには、タイミ

ングクロージャを達成するためにコード変更、フロアプラン、制約変更した際のデザインの実行結果であるデザイ

ンチェックポイント (DCP) を使用できます。

重要: インクリメンタルフローを適切に機能させるためには、基準デザインチェックポイント (DCP) のデバイスお

よびスピードグレードが現在のデザインのデバイスおよびスピードグレードに一致している必要があります。

インクリメンタルデザイン

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

• RTL の変更

• ネットリストの変更

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

高再利用モードと低再利用モード

再利用のレベルおよび place_design と route_design の -directive オプションの指示子によって、フローの

実行は異なります。

低再利用モードで実行されている場合、 place_design が開始した後、ログファイルに次のメッセージが表示され

ます。

INFO: [Vivado_Tcl 4-956] Incremental Compile is being run with low cell reuse. The directive Explore will be applied.

高再利用モードで実行されている場合は、それに関するメッセージは表示されません。

高再利用

高再利用モードでは、既存の配置配線情報ができる限り再利用されるよう配置配線アルゴリズムが適化されます。

この場合、place_design および route_design で -directive オプションの次の 3 つの指示子を使用できます。

• Default: できる限り再利用し、基準 run にできるだけ近い結果が得られるようにします。基準デザインの WNS

をターゲットとします。このモードでは、典型的な使用ケースで実行時間が短になります。

• Explore: タイミングをできる限り向上し、可能であればタイミングクロージャを達成できるようにします。

WNS 0.00 ns をターゲットとします。このモードでは、実行時間が長くなります。

• Quick: 配置配線をタイミングエンジンを呼び出さずに実行します。この指示子では実行時間が短となり、再

利用率が > 99.5% で周波数要件が低い一部のデザインでは QoR に影響しません。これは主に ASIC プロトタイ

プまたはエミュレーションデザイン用です。





高再利用モードは、基準チェックポイントでタイミングクロージャが達成されており、 95% 以上のセルが再利用さ

れるデザインでも効果的です。使用例は次のとおりです。

• 基準デザインと現在のデザインの間の変更が少ない。

• デザインにデバッグコアを追加する。

低再利用

低再利用モードは通常、次の場合に使用されます。

• 基準チェックポイントからデザインが大きく変更されている。

• ユーザーが基準チェックポイントからの一部のセルのみを使用することを指定している。これを指定するには、

read_checkpoint コマンドの --only_reuse、 -dont_reuse、および --reuse_regions オプションを使

用します。

低再利用モードでは、 place_design および route_design の -directive オプションのすべての指示子がサ

ポートされ、 WNS 0.00 ns をターゲットとして実行されます。

注記: 物理適化は実行されないので、結果はデフォルトフローと異なります。

低再利用モードは、特定のエリアの配置配線が困難なデザインでも効果的です。使用例は次のとおりです。

• 成功した run からのブロックメモリまたは DSP の配置を再利用し、配置配線が成功する確率を上げる。

• タイミングクロージャが達成される場合と達成されない場合のある階層レベルを再利用する。

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

Vivado に基準チェックポイントが読み込まれると、次が実行されます。

• インクリメンタルデザインで基準 run と一致する物理適化が自動的に実行されます。

• インクリメンタルデザインのネットリストが基準デザインと比較され、一致するセルおよびネットが検出され

ます。

• 基準デザインチェックポイントからの配置を使用して、インクリメンタルデザインの一致するセルが配置され

ます。

• 基準デザインチェックポイントからの配線は、一致ネットを配線するためにロードピンごとに再利用されま

す。ネットリストの変更によりロードピンがなくなった場合、その配線は破棄されるので、配線の一部のみが

再利用されることもあります。

インクリメンタル配置およびインクリメンタル配線では、ネットリストの配線性が向上する場合、または基準デザ

インと同等のパフォーマンスが保持される場合、セルの配置およびネットの配線が再利用される代わりに破棄され

ることがあります。

基準デザインと現在のデザインの間で一致しないデザインオブジェクトは、インクリメンタル配置が完了した後に

配置され、配線が完了した後に配線されます。

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

Vivado 配線では、複数のファンアウトがあるネットに対しては詳細な一致比較が実行され、各配線セグメントを適

切に再利用または廃棄できます。





2015.2 以前の基準チェックポイントの使用

基準チェックポイントが 2015.3 より前の Vivado ツールを使用して作成されており、 phys_opt_design で実行され

た適化が含まれる場合は、インクリメンタル run でも phys_opt_design を使用してください。このようにする

と、基準デザインで phys_opt_design により実行された配置の適化が取り込まれ、関連の配線が再利用されま

す。 phys_opt_design には place_design および route_design のようにインクリメンタルモードはありませ

んが、変更されたデザインで基準デザインと同様のロジック変換が実行されます。

配線後の基準デザインとインクリメンタルデザインのネットリストの類似性を確認します。ネットリストの一致

パーセントが低い場合、 phys_opt_design オプションでロジック適化で多量の適化が実行されたためである

可能性があります。そのため、配線後のチェックポイントよりも配置後のチェックポイントの方が基準デザインと

して適していることもあります。

read_checkpoint -incremental を使用したインクリメンタルフローの開始

現在のデザインを読み込んだら、 read_checkpoint -incremental <dcp> コマンドを使用して基準デザイン

チェックポイントを読み込みます。 -incremental オプションを使用して基準デザインチェックポイントを読み込

むと、次の配置配線でインクリメンタルコンパイルデザインフローがイネーブルになります。

インクリメンタルコンパイルの制御

-incremental 以外のコマンドオプションが指定されていない場合、基準チェックポイントの情報ができる限り再

利用されます。 read_checkpoint -incremental コマンドにオプションを追加すると、再利用するものとしな

いものをユーザーが制御できます。

-only_reuse オプション

-only_reuse <cell objects>

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

定できます。

-dont_reuse オプション

-dont_reuse <cell objects>

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

指定できます。

-fix_reuse オプション

-fix_reuse オプションは、 -only_reuse または -dont_reuse オプションと共に使用し、再利用されたセルの

配置を固定します。





例

次に、これらの使用例を示します。

• ブロックメモリの配置のみを再利用:

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

• DSP の配置のみを再利用:

read_checkpoint -incremental routed.dcp \-only_reuse [get_cells -hier -filter {PRIMITIVE_TYPE =~ MULT.dsp.* }] -fix_reuse

• ブロックメモリと DSP の配置を再利用:

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

• 指定の階層レベル以下のすべてのセルを再利用し、ツールがクリティカルエリアの変更に多少柔軟に対処でき

るようにする :

read_checkpoint -incremental routed.dcp \-only_reuse [get_cells <cell_name>] -fix_reuse

report_incremental_reuse コマンドの使用

report_incremental_reuse コマンドは、 read_checkpoint -incremental を実行した後であればどの段階

でも使用できます。このレポートは、基準デザイン run と現在のデザイン run で次を比較します。

• 現在の run のセル、ネット、 I/O、およびピンの再利用

• 実行時間

• フローの各段階でのタイミング WNS

• ツールオプション

• ツールバージョン

• 現在の run のターゲット WNS

セルの再利用および上記の事項を確認することにより、インクリメンタルフローの効果を判断できます。インクリ

メンタルフローが効果的でない場合は、チェックポイントをデザインのより新しいバージョンにアップデートする

か、ツールフローを調整します。





このレポートには、次の 4 つのセクションがあります。

1. Reuse Summary (再利用サマリ )

° 再利用されたセル、ネット、ピン、およびポートの概要を示します。


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

+------+----------------------+--------------------+--------------------+---------+| Type | Matched % (of Total) | Reuse % (of Total) | Fixed % (of Total) | Total |+------+----------------------+--------------------+--------------------+---------+| Cells| 100.00 | 99.82 | 0.38 | 688982 || Nets | 99.98 | 99.72 | 0.00 | 795869 || Pins | - | 99.11 | - | 2823905 || Ports| 100.00 | 100.00 | 100.00 | 667 |+------+----------------------+--------------------+--------------------+---------+

2. Reference Checkpoint Information (基準チェックポイント情報)

° 基準チェックポイントに関する情報を示します。次を確認できます。

- 生成された Vivado バージョン

- インプリメンテーションの段階

- 記録された WNS および WHS

- 現在の run のターゲット WNS

- 基準 run とインクリメンタル run 両方のスピードファイルのバージョン情報


2. Reference Checkpoint Information-----------------------------------

+----------------+--------------------------------------+| DCP Location: | /IncrementalTests/Test11/routed2.dcp |+----------------+--------------------------------------+

+--------------------------------+-----------------------------------+| DCP Information | Value |+--------------------------------+-----------------------------------+| Vivado Version | v2017.1 || DCP State | POST_ROUTE || Recorded WNS* | -0.112 || Recorded WHS | -0.066 || Reference Speed File Version | ADVANCE 08-01-2017 | | Incremental Speed File Version | ADVANCE 08-01-2017 | +--------------------------------+-----------------------------------+* Incremental Flow Target WNS = -0.112





3. Comparison with Reference Run (基準 run との比較)

° 基準 run との比較情報を示します。次を比較できます。

- 実行時間

- フローの各段階での WNS

- フローの各段階で使用されたツールオプション


3. Comparison with Reference Run--------------------------------

+----------------+----------------------+------------------------+-----------------------+| | WNS(ns) | Runtime(elapsed)(hh:mm)| Runtime(cpu)(hh:mm) |+----------------+---------+------------+-----------+------------+----------+------------+| Stage |Reference| Incremental| Reference | Incremental| Reference| Incremental|+----------------+---------+------------+-----------+------------+----------+------------+| read_checkpoint| | | | 00:11 | | 00:13 || place_design | -0.21 | -1.006 | 01:39 | 00:16 | | 00:37 || physopt_design | -0.14 | | 00:24 | | | || route_design | -0.14 | -1.084 | 02:05 | 02:40 | | 04:33 |+----------------+---------+------------+-----------+------------+----------+------------+

4. Non Reuse Information (再利用されていないものの情報)

° 再使用されなかったものとその理由を示します。


4. Non Reuse Information------------------------

+------------------------------------------------------+------+| Type | % |+------------------------------------------------------+------+| Non-Reused Cells | 0.17 || Discarded illegal placement due to netlist changes | 0.17 || Discarded to improve timing | 0.01 || Partially reused nets | 0.00 || Non-Reused nets | 0.27 || Non-Reused Ports | 0.00 |+------------------------------------------------------+------+

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

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

• タイミングクリティカルエリアの変更量。クリティカルパスの配置配線を再利用できない場合、タイミングを

保持するための労力が増します。また、デザインの小さな変更により基準デザインに存在しないタイミング問

題が発生した場合、労力が増えて実行時間が長くなる可能性があり、デザインのタイミングが満たされないこ

ともあります。

• 配置配線の初期化時間。配置配線時間が短い場合、 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

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

プロジェクトモードでは、インクリメンタルコンパイルオプションを [Design Runs] ウィンドウおよび [Settings] ダ

イアログボックスの [Implementation] ページで設定できます。[Design Runs] ウィンドウでインクリメンタルコンパイ

ルオプションを設定するには、次の手順に従います。


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

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

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

重要: デザイン run からチェックポイントを選択した場合、その run がリセットされると削除されます。デザイン run

からチェックポイントを選択する場合は、基準チェックポイントとして選択する前に、別のディレクトリにコピー






[Settings] ダイアログボックスでインクリメンタルコンパイルオプションを設定するには、次の手順に従います。

1. Flow Navigator で [Project Manager] の下の [Settings] をクリックします。

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

3. [Incremental Compile] で、基準デザインチェックポイントを指定します (図 2-23)。

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

注記: 高再利用モードでは、 -directive オプションの Default、 Explore、および Quick 指示子のみがサポートされ

ます。

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

1. [Set Incremental Compile] ダイアログボックスで [Use checkpoint] フィールドを空にするか、または

[Implementation Run Properties] ウィンドウの [Properties] ビューで [INCREMENTAL_CHECKPOINT] フィールドを

空にします。

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

reset_property INCREMENTAL_CHECKPOINT [current_run]

注記: プロジェクトモードでは、低再利用モードはサポートされていません。低再利用モードを使用するには、

read_checkpoint -incremental コマンドで opt_design 後の Tcl スクリプトを使用します。


図 2-23: インクリメンタルコンパイルの設定





余った配線セグメント

セルが現在のデザインから削除されていたり、配置時に移動されたため、基準デザインの配線セグメントに余るも

のが出てしまうことがあります。 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

制約の競合

変更したデザインの制約が基準チェックポイントの物理データと競合することがあります。競合が発生した場合は、

使用される制約によって処理は異なります。これを次の例に示します。

LOC 制約競合の例

セル 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 がなく、現在の run に Pblock が追加されているとします。競合がある場合は、基準

チェックポイントからの配置データが使用されます。





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

Vivado ツールでは、詳細に再利用が解析できるようにレポート、タイミングラベル、およびオブジェクトプロパ

ティが提供されています。

再利用レポート

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

ます。

-cells <list of cells>

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

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

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

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

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

+-------+----------------------+--------------------+--------------------+-------+| Type | Matched % (of Total) | Reuse % (of Total) | Fixed % (of Total) | Total |+-------+----------------------+--------------------+--------------------+-------+| Cells | 96.68 | 95.78 | 1.94 | 3650 || Nets | 97.06 | 91.35 | 0.00 | 5229 || Pins | - | 85.06 | - | 19650 || Ports | 100.00 | 100.00 | 100.00 | 71 |+-------+----------------------+--------------------+--------------------+-------+

2. Reference Checkpoint Information-----------------------------------

+----------------+-------------------------------------------------------+| DCP Location: | /projects/incr/ref.dcp |+----------------+-------------------------------------------------------+

+-----------------+------------+| DCP Information | Value |+-----------------+------------+| Vivado Version | v2017.1.0 || DCP State | POST_ROUTE || Recorded WNS* | 1.445 || Recorded WHS | 0.061 |+-----------------+------------+* Incremental Flow Target WNS = 0.000

3. Comparison with Reference Run--------------------------------





+----------------+---------------------+-----------------------+---------------------+| | WNS(ns) |Runtime(elapsed)(hh:mm)| Runtime(cpu)(hh:mm) |+----------------+---------+-----------+-----------+-----------+-----------+---------+| Stage |Reference|Incremental| Reference |Incremental|Reference|Incremental|+----------------+---------+-----------+-----------+-----------+---------+-----------+| synth_design | | | 00:01 | 00:01 | | || opt_design | | | < 1 min | < 1 min | | < 1 min || read_checkpoint| | | | < 1 min | | < 1 min || place_design | 2.10 | 1.448 | < 1 min | < 1 min | | < 1 min || route_design | 1.44 | 1.445 | < 1 min | < 1 min | | < 1 min |+----------------+---------+-----------+-----------+-----------+---------+-----------+

4. Non Reuse Information------------------------

+------------------------------------------------------+------+| Type | % |+------------------------------------------------------+------+| Non-Reused Cells | 4.21 || New | 3.12 || Discarded illegal placement due to netlist changes | 0.82 || Discarded to improve timing | 0.27 || Partially reused nets | 0.00 || Non-Reused nets | 8.64 || Non-Reused Ports | 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 で、再利用されたセルは合計 3,607 個、新規セルは 9 個あります。 bft がかっこで囲

まれた行は、 bft に含まれ、そのサブモジュールに含まれていないセルの再利用ステータスを示します。 3,607 個の

セルのうち、 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 |+--------------------------------+---------------+--------+-----+---------------------+





タイミングレポート

インクリメンタル配置配線が完了したら、タイミングとセルおよびネットの再利用に関する詳細を解析できます。

タイミングレポートのオブジェクトに、物理データがどのように再利用されたかが示されます。これにより、デザ

インのアップデートがクリティカルパスに影響しているかどうかを判断できます。

次に、このレポートで使用される用語の意味を説明します。

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

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

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

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


--------------------------------------------------------------------------------- --------------Routing SLICE_X65Y175 FDRE(Prop_EFF_SLICEL_C_Q)

0.114 -0.446 r base_mb_i/microblaze_0/Q net (fo=637, routed) 0.752 0.306 base_mb_i/microblaze_0/reset_bool_for_rst

Routing SLICE_X73Y171 FDRE r base_mb_i/microblaze_0/command_reg_clear_reg/R------------------------------------------------------------------------------ -------------------

上記のレポートは、 Vivado IDE では次のように表示されます。

タイミングレポートからラベルを削除するには、report_timing -no_reused_label オプションを使用します。

オブジェクトプロパティ

read_checkpoint -incremental コマンドを使用すると次の 2 つのセルプロパティが設定され、スクリプトま

たは Tcl コマンドを使用してインクリメンタルフロー結果を解析する際に有益です。

• IS_REUSED: セル、ポート、ネット、およびピンオブジェクトのブール値プロパティで、次のインクリメンタ

ルデータが再利用された場合に TRUE に設定されます。

° セル配置

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

° ネットの配線部分

° ピンへの配線


図 2-24: Vivado でのインクリメンタル再利用サマリ





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

示します。

セルの値は、次のいずれかです。

° New (新規)

° Reused (再利用)

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

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

ネットの値は、次のいずれかです。

° REUSED

° NON_REUSED

° PARTIALLY_REUSED

ヒント : ザイリンクス Tcl Store の Incremental Compile パッケージに、いくつかのアプリケーションがパブリッシュさ

れています。これらのアプリケーションには、クリティカルパスを解析する際の配置配線再利用の表示およびその

他のデザインビューが含まれています。また、インクリメンタルデザイン run の基準チェックポイントを自動的に

管理する、プロジェクトフロー用の自動インクリメンタルコンパイルのアプリケーションも含まれます。

ヒント : インクリメンタルコンパイルの効果的な使用方法は、『UltraFast 設計手法ガイド (Vivado Design Suite 用)』



https://japan.xilinx.com/products/design-tools/vivado/Tcl-store.html

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug949-vivado-design-methodology.pdf;a=xIncrementalFlows



第 3 章

インプリメンテーション結果の解析と表示

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

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

• コンパイル情報を読む。

• [Messages] ウィンドウで警告およびエラーを確認。

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

• [Design Runs] ウィンドウを開く。

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

run ステータス表示

進行中の run のステータスは、 2 つの方法で表示されます。これらのステータス表示には、 run が進行中であること

が示されるほか、ここから必要に応じてキャンセルできます。

• Vivado® IDE の右上に、プロジェクトステータスバーに表示される run ステータスインジケーターがあります

(図 3-1 を参照)。 run が進行中であることが動くバーで示されます。 [Cancel] をクリックすると、 run を停止でき

ます。

• run ステータスインジケーターは、 [Design Runs] ウィンドウ (図 3-2) にも表示されます。 run 名の横に、 run が進

行中であることを示す円形の矢印が表示されます (図の赤丸)。 run を右クリックしてポップアップメニューから

[Reset Run] をクリックすると、 run をキャンセルできます。


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


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




第 3 章: インプリメンテーション結果の解析と表示

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

進行中の run を [Cancel] ボタンまたは [Reset Run] コマンドでキャンセルすると、キャンセルした run 用に作成された

run ファイルをすべて削除するかどうか確認するメッセージ (図 3-3) が表示されます。

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

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

お勧めします。

[Log] ウィンドウのログ情報の表示

run を実行すると、 [Log] ウィンドウが開き、標準出力メッセージが表示されます。 [Log] ウィンドウには、

place_design や route_design などの各インプリメンテーションプロセスの進行状況も表示されます。

[Log] ウィンドウ (図 3-4) でメッセージがどこから表示されているかを確認し、インプリメンテーション run のデ

バッグに役立てることができます。

出力の停止

[Log] ウィンドウで [Pause output] ボタンをクリックすると、出力を停止できます。出力を停止すると、インプ

リメンテーションの実行中にログ情報を読むことができます。


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


図 3-4: [Log] ウィンドウ





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

Vivado IDE では、プロジェクトステータスと次に実行する段階が複数の方法で示されます。プロジェクトステータ

スには、主なデザインタスクの結果のみがレポートされます。

プロジェクトステータスは [Project Summary] とステータスバーに表示され、プロジェクトを開いたとき、デザイン

フローコマンドを実行中に、プロジェクトのステータスをすばやく判断できます。次のステータスが示されます。

• RTL エラボレーション

• 合成

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

• ビットストリーム生成

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

プロジェクトステータスは、 Vivado IDE の右上のプロジェクトステータス

バーに表示されます。

合成、インプリメント、ビットストリームの生成を実行すると、プロジェクト

ステータスバーにその結果が示されます。プロセスでエラーが発生した場合

は、赤色の文字で表示されます。

Out-of-Date ステータス

合成またはインプリメンテーションを完了した状態でソースファイルまたはデザイン制約を変更すると、プロジェ

クトステータスが図 3-5 に示すように「Out-of-Date」と表示されます。

これは、プロジェクトが新でなく、更新が必要であることを示します。デザインのどの部分が新ではないのか

を確認するには、 [more info] リンクをクリックします。インプリメンテーションのみの再実行が必要な場合や、合成

およびインプリメンテーションの両方を再実行する必要がある場合があります。

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

[Force-up-to-date] リンクをクリックすると、インプリメンテーション run または合成 run のステータスを強制的に

新の状態にすることができます。この機能は、デザインまたは制約を変更したが、現在の run の結果を解析する場合

などに使用します。

ヒント : [Force-up-to-date] コマンドは、 [Design Runs] ウィンドウで新でない run を右クリックしたときに表示される

ポップアップメニューにもあります。


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





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

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

インプリメンテーションの結果によります。

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

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

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

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

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

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 が完了すると、図 3-6 に示すダイアログボックスが表示さ

れ、次の操作を選択できます。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug906-vivado-design-analysis.pdf;a=xDesignAnalysisWithinTheIDE



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

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

° [Open Implemented Design]

ネットリスト、デザイン制約、ターゲットパーツ、配置配線の結果を Vivado IDE に読み込み、必要に応じ

てデザインを解析できるようにします。

° [Generate Bitstream]

[Generate Bitstream] ダイアログボックスを開きます。詳細は、『Vivado Design Suite ユーザーガイド : プログ

ラムおよびデバッグ』 (UG908) [参照 12] のこのセクションを参照してください。

° [View Reports]

Vivado ツールでインプリメンテーション中に生成されたレポートファイルを選択して表示できる [Reports]

ウィンドウを開きます。詳細は、 108 ページの「インプリメンテーションレポートの表示」を参照してく

ださい。

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


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






メッセージの表示

重要: すべてのメッセージを確認してください。メッセージには、デザインのパフォーマンス、消費電力、エリア、

配線を向上するための推奨事項が記載される場合があります。クリティカル警告メッセージにも、解決すべきタイ

ミング制約の問題が表示されることがあります。

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

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

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

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

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

報が得られることがあります。

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

プロジェクトモードでは、 [Messages] ウィンドウ (図 3-7) に [Log] ウィンドウの内容がフィルターされたものが表示

され、主なメッセージ、警告、およびエラーのみが含まれます。 [Messages] ウィンドウは機能ごとに分類されてお

り、フィルターを適用するツールバーオプションを使用して、特定のタイプのメッセージのみを表示できます。

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

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

• [Messages] ウィンドウの上部にあるチェックボックスのオン/オフを切り替え、エラー、クリティカル

警告、警告、情報メッセージを表示/非表示にします。

• [Messages] ウィンドウでリンクを含むメッセージをクリックすると、ソースファイルが開き、該当する行がハ

イライトされます。

• メッセージを右クリックして [Search for Answer Record] をクリックすると、ザイリンクスウェブサイトでその

メッセージに関連するアンサーデータベースを検索できます。


図 3-7: [Messages] ウィンドウ





インクリメンタルコンパイルのメッセージ Vivado ツールのログファイルには、インクリメンタルコンパイルからのインクリメンタル配置および配線のサマリ

結果がレポートされます。

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

次のインクリメンタル配置サマリの例には、セル配置の再利用およびランタイム統計の終的な評価が含まれます。

+-------------------------------------------------------------------------------+|Incremental Placement Summary |+-------------------------------------------------------------------------------+| Type | Count | Percentage |+-------------------------------------------------------------------------------+| Total instances | 33406 | 100.00 || Reused instances | 32390 | 96.96 || Non-reused instances | 1016 | 3.04 || New | 937 | 2.80 || Discarded illegal placement due to netlist changes | 16 | 0.05 || Discarded to improve timing | 63 | 0.19 |+-------------------------------------------------------------------------------+|Incremental Placement Runtime Summary |+-------------------------------------------------------------------------------+| Initialization time(elapsed secs) | 79.99 || Incremental Placer time(elapsed secs) | 31.19 |+-------------------------------------------------------------------------------+

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

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

カテゴリは、次のとおりです。

• Fully Reused

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

• Partially Reused

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

たことにより、一部のセグメントは再配線されています。

• New/Unmatched

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

---------------------------------------------------------|Incremental Routing Reuse Summary |---------------------------------------------------------|Type | Count | Percentage |---------------------------------------------------------|Fully reused nets | 30393| 96.73 ||Partially reused nets | 0| 0.00 ||Non-reused nets | 1028| 3.27 |---------------------------------------------------------





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

Vivado Design Suite では、次の情報を含むさまざまなレポートを生成できます。

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

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

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

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

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

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

• 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 に表示します。

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

ヒント : レポートを保存するディレクトリは、レポートの生成する前に存在している必要があります。ディレクトリ

がないとファイルは保存されず、エラーメッセージが表示されます。

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

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





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

Vivado IDE または Tcl コマンドプロンプトで help Tcl コマンドを使用すると、 Tcl レポートコマンドとそのオプショ

ンに関する情報を表示できます。



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

プロジェクトモードでは、多くのレポートが自動的に生成されます。これらのレポートは、 [Reports] ウィンドウ

(図 3-8) にリストされます。

[Reports] ウィンドウは、合成またはインプリメントコマンドを実行すると自動的に開きます。開いていない場合は、

次のいずれかの方法で開くことができます。

• [Project Summary] ウィンドウで [Reports] リンクをクリックします。

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

ヒント : インプリメンテーション run の tcl.pre および tcl.post オプションを使用すると、プロセスの各段階でカスタム

レポートを出力できます。これらのカスタムレポートは [Reports] ウィンドウには表示されませんが、ニーズに合わ

せてカスタマイズできます。詳細は、 26 ページの「インプリメンテーション run 設定の変更」を参照してください。


図 3-8: [Reports] ウィンドウの例





[Reports] ウィンドウから表示されるレポートには、 run に関する情報が含まれます。レポートは、図 3-9 に示すように Vivado IDE でテキスト形式で開きます。

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

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

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

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

たとえば、 [Reports] ウィンドウには [Route Design] の下にテキスト形式のタイミングサマリレポートが含まれてい

ます (図 3-8)。

タイミングを解析する際は、クリティカルパスの配置および配線リソースなどのデザインデータを [Device] ウィン

ドウに表示すると有益です。

Vivado IDE で [Tools] → [Timing] → [Report Timing Summary] をクリックすると、タイミングサマリレポートが再生成

され、表示されたレポートからデザインの異なるウィンドウにクロスプローブできます。


図 3-9: 制御セットレポート





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

図 3-10 に、タイミングサマリレポートと [Device] ウィンドウのクロスプローブの例を示します。この非プロジェク

トモードの例では、次の手順が実行されています。

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

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

• [Device] ウィンドウで [Routing Resources] をオンにします。

• タイミングサマリレポートでタイミングパスを選択し、 [Device] ウィンドウのパスにクロスプローブします

(図 3-10)。

レポートの解析およびデザインクロージャのストラテジの詳細は、『Vivado Design Suite ユーザーガイド : デザイン解

析およびクロージャテクニック』 (UG906) [参照 10] を参照してください。


図 3-10: タイミングレポートと [Device] ウィンドウのクロスプローブ





インプリメンテーション結果の変更

このセクションでは、デザインの配置、配線、およびロジックの変更方法を説明します。

配置の変更

Vivado ツールでは、配置セルが固定されているか (Fixed)、固定されていないか (Unfixed) が検出され、デザインの配

置されたセルをどのように処理するかが判断されます。

固定セル

固定されたセルは、ユーザーが配置したか、 XDC ファイルからインポートされたセルのロケーション制約です。

• Vivado Design Suite では、このように配置されたセルは固定 (Fixed) として処理されます。

• 固定セルは、指示がない限り移動されません。

• 図 3-11 ではフリップフロップがオレンジ色 (デフォルト ) で表示されており、固定されていることがわかります。

未固定セル

固定されていないセルは、 Vivado インプリメンテーションで place_design コマンドまたは適化コマンドの 1 つ

により配置されたものです。

• Vivado Design Suite では、このように配置されたセルは未固定 (Unfixed) または配置は確定していないとして処

理されます。

• これらのセルは、必要に応じて移動されます。

• 図 3-11 では LUT が青色 (デフォルト ) で表示されており、未固定であることがわかります。





LOC および BEL のどちらも固定できます。上図の配置では、次の制約が生成されます。

set_property is_bel_fixed true [get_cells [list {usbEngine0/u4/u6/csr0_reg[6]}]]set_property is_loc_fixed true [get_cells [list {usbEngine0/u4/u6/csr0_reg[6]}]]

LUT には配置制約は設定されていません。 LUT の配置は未固定であり、配置は XDC に含めるべきでないことを示

しています。

配置機能で配置されたロジックの固定

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) [参照 18] を参照するか、

「<command> -help」と入力してください。


図 3-11: スライスに配置されたロジック





ロジックの手動での配置および移動

ロジックを手動で配置および移動できます。

• セルが既に配置されている場合、ドラッグして新しいロケーションにドロップします。

• セルが配置されていない場合は、次の手順に従います。

a. [Device] ウィンドウでツールバーの [Cell Drag & Drop Modes] ボタンをクリックし、 [Create BEL Constraint

Mode] をオンにします。

b. [Netlist] ウィンドウまたは [Timing] ウィンドウからロジックを [Device] ウィンドウにドラッグします。

ロジックは、有効なロケーションに配置されます。

ヒント : [Device] ウィンドウにロジックをドラッグする場合、有効なロケーションにのみドロップできます。ロケー

ションが無効な場合 (スライス FF での制御セットの制限のためなど)、 [Device] ウィンドウのそのロケーションには

ドロップできず、ロジックは配置されません。

手動でのロジックの配置には時間がかるので、特定の状況でのみ使用してください。制約にセル名が使用されるの

で、制約はデザインの変更の影響を受けやすくなります。

Tcl コマンドを使用したロジックの配置

ターゲットパーツのデバイスリソースにロジックを配置するには、 place_cell Tcl コマンドを使用できます。セ

ルは、特定の BEL サイト (SLICE_X49Y60/A6LUT など) または使用可能なサイト (SLICE_X49Y60 など) に配置できま

す。サイトを指定して BEL を指定しない場合、ツールにより指定されたスライス内の適切な BEL が選択されます。

place_cell コマンドは、セルを配置する場合、またはセルをデバイス上のあるサイトから別のサイトに移動する

場合に使用できます。配置されていないセルを配置する構文も、配置されている移動する構文も同じです。

ヒント : スライス FF での制御セットの制限のなどの理由で、ロジックを無効なロケーションに配置しようとすると、

[Tcl Console] ウィンドウにエラーメッセージが表示され、その配置は無視されます。

place_cell Tcl コマンドを使用して配置されたセルは、 Vivado ツールにより固定されたセルとみなされます。





配線の変更

デザインの配線は、 [Device] ウィンドウで変更できます。個々のネットで配線の解除、配線、配線の固定を実行でき

ます。

個々のネットで配線の解除、配線、配線の固定を実行するには、次の手順に従います。

1. [Device] ウィンドウを開きます。

2. ネットを選択します。

° 未配線のネットは、赤色のフライラインで表示されます。

° 部分的に配線されたネットは、黄色で表示されます。

° 配線が固定されているネットは、点線で示されます。

3. 右クリックして [Unroute]、 [Route]、または [Fix Routing] をクリックします。

• [Unroute] および [Route]: 配線を再配線モードで起動し、ネットで操作を実行します。詳細は、第 2 章の

「route_design」を参照してください。

• [Fix Routing]: 配線し、配線データベースで固定とマークし、ネットのドライバーおよびロードの LOC および

BEL を固定します。ネットを手動で配線する配線割り当てモードも使用できます。詳細は、「手動配線」を参照


ヒント : ネット関連のコマンドはすべて、ネットのポップアップメニューから実行できます。


図 3-12: 配線の変更





手動配線

手動配線を使用すると、ネットに特定の配線リソースを選択できます。これにより、信号の配線パスを完全に制御で

きます。手動配線では、 route_design は実行されません。配線は配線データベースで直接アップデートされます。

手動配線は、ネットの遅延を厳密に制御する場合に使用します。たとえば、ソース同期インターフェイスで、デバ

イスの受信レジスタまでの配線遅延の変動を小限に抑える場合、レジスタおよび I/O に LOC および BEL 制約を設

定し、ネットを手動配線することで IOB からレジスタまでの配線遅延を制御します。

手動配線を実行するには、デバイスのインターコネクトアーキテクチャに関する詳細な知識が必要です。手動配線

を実行する信号数を制限し、短い接続にのみ使用することをお勧めします。

手動配線での規則

手動配線では、次の規則に従います。

• ドライバーおよびロードに LOC 制約と BEL 制約が必要です。

• 手動配線では分岐は使用できませんが、分岐点から新しい手動配線を開始することで分岐をインプリメントで

きます。

• LUT ロードのピンを固定する必要があります。

• ドライバーに接続されていないロードに配線する必要があります。

• 完全な接続のみが許容されます。アンテナは許容されません。

• 既存の固定されていない配線済みネットとオーバーラップさせることができます。手動配線が完了した後

route_design を実行し、ネットのオーバーラップによる競合を解決しまｓ。

配線割り当てモードの開始

配線割り当てモードを開始するには、次の手順に従います。


2. [Routing Resources] がオンになっていることを確認します。

3. ツールバーの [Options] ボタンをクリックし、 [Device Options] の [Layers] タブで [Unrouted Net] および [Partially

Routed Net] をオンにします (図 3-13)。





,

4. 配線が必要なネットを選択します。

° 未配線のネットは、赤色のフライラインで表示されます。

° 部分的に配線されたネットは、黄色で表示されます。

5. 右クリックして [Enter Assign Routing Mode] をクリックします。

[Assign Routing: Target Load Cell Pin] ダイアログボックスが開きます。

6. 配線先のロードセルピンを選択します (オプション)。



図 3-13: [Device Options] の [Layers] ビュー





注記: [Device] ウィンドウに部分的に配線されたネットまたは未配線のネットを表示するには、 [Device Options] メ

ニューで対応するレイヤーをオンにする必要があります (図 3-14)。

手動配線モードになりました。 [Device] ウィンドウの横に [Routing Assignment] ウィンドウが表示されます (図 3-15)。


図 3-14: [Device Options] プルアウトメニュー





[Routing Assignment] ウィンドウ

[Routing Assignment] ウィンドウには、 [Options]、 [Assigned Nodes]、 [Neighbor Nodes] の 3 つのセクションがあります。

• [Options] セクション (図 3-16) では、 [Routing Assignment] ウィンドウの設定を制御します。

,


図 3-15: [Routing Assignment] ウィンドウ


図 3-16: [Routing Assignment] ウィンドウの [Options] セクション





° [Number of hops]: 近隣ノードの配線ホップ数を指定します。この設定は、 [Neighbor Nodes] セクションに表

示されるノードに影響します。 1 より大きい値に設定すると、 [Neighbor Nodes] セクションに配線の後の

ノードのみが表示されます。

° [Maximum number of neighbors]: [Neighbor Nodes] セクションに表示される近隣ノードの大数を指定します。

配線の後のノードのみが表示されます。

° [Allow overlap with unfixed nets]: 割り当てる配線が固定されていない既存の配線とオーバーラップするのを

許容します。固定配線の割り当て後、 route_design コマンドを実行してすべてのオーバーラップを解決

する必要があります。

[Options] セクションはデフォルトでは非表示になっています。 [Options] セクションを表示するには、 [Show] を

クリックします。

• [Assigned Nodes] セクションは、既に配線が割り当てられているモードを示します。割り当済みの各ノードが 1

行に表示されます。

割り当て済みの配線は、 [Device] ウィンドウでオレンジ色で示されます。割り当て済みノードの間のギャップ

は、 [Assigned Nodes] セクションに GAP 行として表示されます。ギャップを自動配線するには、次の手順に従い

ます。

a. [Assigned Nodes] セクションでネットギャップを右クリックします。

b. [Auto-route] をクリックします。

次の配線セグメントを割り当てるには、ギャップの前または後の割り当て済みノードを選択するか、 [Assigned

Nodes] セクションの後のノードを選択します。

• [Neighbor Nodes] セクションは、選択したノードの近隣にある使用可能なノードを表示します。 [Device] ウィン

ドウでは、図 3-17 に示すように、選択されているノードが白の実線で示されされ、使用可能な近隣のノードが

白の点線で示されます。





,

配線ノードの割り当て

次の配線セグメントに割り当てるノードを決定したら、次のいずれかを実行します。

• [Neighbor Nodes] セクションでノードを右クリックし、 [Assign Node] をクリックします。

• [Neighbor Nodes] セクションでノードをダブルクリックします。

• [Device] ウィンドウでノードをクリックします。

配線をノードに割り当てると、そのノードが [Assigned Nodes] セクションに表示され、 [Device] ウィンドウでオレン

ジ色でハイライトされます。

ロードに到達するまで、またはギャップを含む配線を割り当てる準備ができるまで、ノードの割り当てを継続します。


図 3-17: 配線セグメントの割り当て





配線ノードの割り当て解除

ノードの割り当てを解除するには、次の手順に従います。

1. [Routing Assignment] ウィンドウの [Assigned Nodes] セクションに移動します。

2. 割り当てを解除するノードを選択します。

3. 右クリックして [Remove] をクリックします。

ノードが割り当てから削除されます。

配線割り当ての確定および終了

配線の割り当てを終了して配線割り当てモードを終了するには、 [Assign Routing] ダイアログボックスで [Assign

Routing] ボタンをクリックします。

[Assign Routing] ダイアログボックス (図 3-18) が表示されます。このダイアログボックスで、割り当てられたノード

を確認します。

配線割り当てのキャンセル

配線割り当てを確定できない場合は、次のいずれかの方法を使用して配線割り当てをキャンセルできます。

• [Routing Assignment] ウィンドウで [Exit Mode] をクリックします。

• [Device] ウィンドウを右クリックして [Exit Assign Routing Mode] をクリックします。

配線を確定すると、ドライバーおよびロードの BEL および LOC も固定されます。


図 3-18: [Assign Routing] ダイアログボックス





割り当て済みの配線の確認

• 割り当て済みの配線は、 [Device] ウィンドウで緑色の点線で示されます。

• 部分的に割り当てられた配線は、 [Device] ウィンドウで黄色の点線で示されます。

図 3-19 に、割り当て済み配線と部分的に割り当てられた配線の例を示します。

分岐

複数のロードを持つネットを配線する場合は、次の手順に従ってネットを配線します。

1. 116 ページの「配線割り当てモードの開始」の手順に従って 1 つのロードへの配線を割り当てます。

2. ネットのすべての分岐への配線を割り当てます。


図 3-19: 割り当て済みの配線および部分的に割り当てられた配線





図 3-20 に、 1 つのロードへの配線が割り当てられており、さらに 2 つのロードへの配線が必要なネットを示します。

分岐への配線の割り当て

分岐に配線を割り当てるには、次の手順に従います。

1. [Device] ウィンドウを表示します。

2. 配線するネットノードを選択します。

3. 右クリックして [Enter Assign Routing Mode] をクリックします。

[Target Load Cell Pin] ダイアログボックスが開き、すべてのロードが表示されます。

注記: 配線が割り当てられているロードには、 [Routed] 列にチェックマークが示されています。


図 3-20: 分岐配線の割り当て





4. 配線するロードを選択します。

5. [OK] をクリックします。図 3-22 に示す [Branch Start] ダイアログボックスが開きます。

6. 選択したロードの配線を分岐するノードを選択します。


8. 121 ページの「配線ノードの割り当て」の手順に従います。


図 3-21: [Target Load Cell Pin] ダイアログボックス (複数ロード )


図 3-22: [Branch Start] ダイアログボックス





LUT ロードのセル入力の固定

配線しようとしている LUT ロードの入力が、ほかの入力とスワップされていないことを確認する必要があります。

これには、次の手順に従って LUT ロードのセル入力を固定します。


2. ロード LUT を選択します。

3. 右クリックして [Lock Cell Input Pins] をクリックします。

これと同等の Tcl コマンドは、次のとおりです。

set_property LOCK_PINS {NAME:BEL_PIN} <cell object>

固定配線および複数の LUT ロードがあるネットに対しては、次の Tcl スクリプトを使用してすべての LUT ロードの

セル入力を固定できます。

set fixed_nets [get_nets -hierarchical -filter IS_ROUTE_FIXED]foreach LUT_load_pin [get_pins -leaf -of [get_nets $fixed_nets] \-filter DIRECTION==IN&&REF_NAME=~LUT*] {set pin [get_property REF_PIN_NAME $LUT_load_pin]set BEL_pin [file tail [get_bel_pins -of [get_pins $LUT_load_pin]]]set LUT_name [get_property PARENT_CELL $LUT_load_pin]# need to handle condition when LOCK_pins property already exists on LUTset existing_LOCK_PIN [get_property LOCK_PINS [get_cells $LUT_name]]if { $existing_LOCK_PIN ne "" } {

reset_property LOCK_PINS [get_cells $LUT_name]}set_property LOCK_PINS \[lsort -unique [concat $existing_LOCK_PIN $pin:$BEL_pin]] [get_cells $LUT_name]

}

指定配線制約

固定された配線割り当ては、配線データベースに指定配線文字列として保存されます。指定配線文字列では、分岐

はネストされた中かっこ ({ }) で示されます。

たとえば、図 3-23 に示すような配線があるとします。この配線では、さまざまなエレメントが次の表に示すように

示されています。

表 3-1: 指定配線制約

エレメント表示方法

ドライバーとロードオレンジ色の矩形

ノード赤い線

スイッチボックス青い矩形





この配線の簡略化された指定配線文字列は、次のようになります。

{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 です。

find_routing_path コマンドを使用した指定配線制約の作成

find_routing_path Tcl コマンドを使用して指定配線制約を作成できます。作成した制約をネットの

FIXED_ROUTE プロパティに割り当て、配線を固定できます。

部分的に配線されたネットでは、ネットへの直接の関連性を使用してノードを検索できます。これらのオブジェク

トの関係の詳細は、『Vivado Design Suite プロパティリファレンスガイド』 (UG912) [参照 14] を参照してください。

find_routing_path コマンドは、次のいずれかを返します。

• 始点から終点までにある配線パスを表すノードのリスト

• コマンドが実行されたが結果がない場合は「no path found」

• コマンドが正しく実行されなかった場合はエラー


図 3-23: 分岐配線の例

D

L1

L2

L4

L3

A B

E T

I M N

QPO

G

H

F

D

C

R

JK L S





ロジックの変更

読み取り専用でない論理オブジェクトのプロパティは、インプリメンテーション後に Vivado IDE または Tcl で変更

できます。



[Device] ウィンドウでオブジェクトのプロパティを変更するには、次の手順に従います。

1. オブジェクトを選択します。

2. [Properties] ウィンドウの [Properties] ビューでオブジェクトのプロパティを変更します。

変更可能なプロパティには、ブロック RAM の INIT、 MMCM のクロックを変更するプロパティなどがあります。

LUT オブジェクトの INIT を変更するためのダイアログボックスもあり、 LUT 論理式を指定して適切な INIT 値が

ツールにより設定されるようにすることができます。


図 3-24: プロパティの変更





変更の保存

メモリ内でデザインに対して加えた変更を保存するには、デザインのチェックポイントを保存します。

割り当てはデザインにバックアノテートされないので、次回の実行で適用されるようにするには、割り当てを XDC

に追加する必要があります。

プロジェクトモードで制約を制約ファイルに保存するには、 [File] → [Save Constraints] をクリックします。


図 3-25: LUT 論理式の指定





ネットリストの変更

機能的なロジックのバグを修正、タイミングクロージャを達成、またはデバッグロジックを挿入するため、ネット

リストの変更が必要な場合があります。合成後、配置後、および配線後に Tcl コマンドを使用して、既存のネットリ

ストを変更できます。

ネットリスト変更コマンド

次に、既存のネットリストを変更するコマンドを示します。

• create_port

• remove_port

• create_cell

• remove_cell

• create_pin

• remove_pin

• create_net

• remove_net

• connect_net

• disconnect_net

注記: これらの Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 18] を参

照するか、「<command> -help」と入力してください。

ネットリスト変更コマンドは、合成後、配置後、および配線後のネットリストに対して実行します。ネットリスト

を変更する前に、メモリに読み込んでおく必要があります。ネットリストをメモリに読み込んだら、ネットリスト

変更コマンドを使用して論理的な変更を加えることができます。変更を保存するには、 write_checkpoint コマ

ンドを使用します。

ヒント : ネットリスト変更コマンドを使用すると、ネットリストに無条件に変更を加えることができますが、論理的

な変更により物理的なインプリメンテーションが無効になる場合があります。物理的なインプリメンテーションに

論理的な変更を加えるプロセスの一部として、 DRC が実行されます。これらの DRC により、無効なネットリストの

変更や、物理的なインプリメンテーションの前に対処しておくべき物理的な制限がレポートされます。

ネットリスト変更コマンドを実行するとすぐに、論理的な変更が回路図に反映されます。図 3-26 に、 LUT1 を基準

セルとして使用して作成されたセルの例を示します。



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xcreate_port

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xremove_port

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xcreate_cell

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xremove_cell

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xcreate_pin

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xremove_pin

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xcreate_net

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xremove_net

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xconnect_net

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf;a=xdisconnect_net



LUT1 の出力を OBUF に接続すると、この変更が回路図に反映され、 ECO_INV/O の出力ピンが「n/c」 (未接続) ではな

くなります。図 3-27 に、変更が反映された回路図を示します。


図 3-26: LUT1 を基準セルとして使用して作成されたセル


図 3-27: LUT1 を OBUF に接続した後の [Schematic] ウィンドウ





使用例

次に、も一般的なネットリストの変更例を示します。各例に対して、元の論理ネットリストの回路図、使用する

ネットリスト変更コマンドのリスト、変更後のネットリストの回路図を示します。

使用例 1: ネットの論理値の反転

ネットの論理値を反転するには、 LUTx プリミティブの既存の LUT 論理式を変更するだけでよい場合もありますが、

入力からの出力を反転するために LUT1 を挿入する必要がある場合もあります。図 3-28 に、 OBUF を介して出力ポー

ト wbOutputData[0] を駆動する FDRE プリミティブの回路図を示します。

次の Tcl コマンドは、 FDRE の出力と OBUF の間にインバーターを追加します。

create_cell -reference LUT1 ECO_INVset_property INIT 2'h1 [get_cells ECO_INV]disconnect_net -net {n_0_SuspendM_pad_0_o_reg} -objects \[get_pins {SuspendM_pad_0_o_reg/Q}]

connect_net -net {n_0_SuspendM_pad_0_o_reg} -objects [get_pins {ECO_INV/O}]create_net ECO_INV_inconnect_net -net ECO_INV_in -objects [get_pins {SuspendM_pad_0_o_reg/Q ECO_INV/I0}]

このスクリプト例は、まず LUT1 セル ECO_INV を作成し、 INIT 値が反転をインプリメントする 2'h1 に設定しま

す。その後 FDRE と OBUF の間のネットを FDRE の Q 出力ピンから接続解除し、反転 LUT1 セル ECO_INV の出力を

OBUF の I 入力ピンに接続します。後に、ネットを作成して FDRE の Q 出力ピンと反転 LUT1 セルの I0 入力を接

続します。

図 3-29 に、論理ネットリストの変更が反映された回路図を示します。


図 3-28: OBUF を介して出力ポートを駆動する FDRE プリミティブ





ネットリストを変更したら、論理的な変更をインプリメントする必要があります。 LUT1 セルを配置し、セルに入出

力されるネットを配置する必要があります。これは、デザインの変更されていない部分の配置配線を変更せずに実

行する必要があります。変更したネットリストの対して place_design を実行すると、 Vivado インプリメンテー

ションコマンドは自動的にインクリメンタルモードで実行され、ログファイルに「Incremental Placement Summary」

(インクリメンタル配置サマリ ) セクションが含まれます。

+-------------------------------------------------------------------------------+|Incremental Placement Summary |+-------------------------------------------------------------------------------+| Type | Count | Percentage |+-------------------------------------------------------------------------------+| Total instances | 3834 | 100.00 || Reused instances | 3833 | 99.97 || Non-reused instances | 1 | 0.03 || New | 1 | 0.03 |+-------------------------------------------------------------------------------+

既存の配線を保持して変更されたネットのみを配線するには、 route_design コマンドを使用します。これによ

り、変更のみがインクリメンタルに配線され、ログファイルに「Incremental Routing Reuse Summary」 (インクリメン

タル配線再利用サマリ ) セクションが含まれます。

--------------------------------------------------------|Incremental Routing Reuse Summary |--------------------------------------------------------|Type | Count | Percentage |--------------------------------------------------------|Fully reused nets | 6401| 99.97 ||Partially reused nets | 0| 0.00 ||Non-reused nets | 2| 0.03 |--------------------------------------------------------

インクリメンタル place_design および route_design コマンドを使用して変更したネットリストを自動的に配

置配線する代わりに、手動配置および配線制約を使用して論理的な変更を確定できます。詳細は、この章の「配置

の変更」および「配線の変更」を参照してください。


図 3-29: 反転が追加されたネットリストを示す回路図





使用例 2: デバッグポートの追加

ネットリストを変更することにより、内部信号を簡単にデバッグポートに配線できます。この例では、次の回路図

に示す demuxState_reg/Q ピンを、デバイスの外部ポートで監視できるようにします。

次の Tcl スクリプトは、既存のデザインにポートを追加し、内部信号を追加したポートに配線します。

create_port -direction out debug_port_outset_property PACKAGE_PIN AB20 [get_ports {debug_port_out}]set_property IOSTANDARD LVCMOS18 [get_ports [list debug_port_out]]create_cell -reference [get_lib_cells [get_libs]/OBUF] ECO_OBUF1create_net ECO_OBUF1_outconnect_net -net ECO_OBUF1_out -objects ECO_OBUF1/Oconnect_net -net ECO_OBUF1_out -objects [get_ports debug_port_out]connect_net -net [get_nets -of [get_pins demuxState_reg/Q]] -objects ECO_OBUF1/I

上記の Tcl スクリプト例は、次を実行します。

• デバッグポートを作成します。

° 作成したデバッグポートをパッケージピン AB20 に割り当てます。

° I/O 規格 LVCMOS18 を割り当てます。

• ECO_OBUF1_out ネットを介してデバッグポートを駆動する OBUF を作成します。

• demuxState_reg レジスタの出力を OBUF の入力に接続するネットを作成します。


図 3-30: demuxState_reg を示す回路図





図 3-31 に、論理ネットリストの変更が反映された回路図を示します。

ネットリストを変更したら、論理的な変更をインプリメントする必要があります。ポートはパッケージピンに割り

当てられるので、ポートを駆動する OBUF が自動的に正しい場所に配置されます。そのため、 route_design の後

に place_design を実行すると、配置するものがないと判断され、インクリメンタルコンパイルは適用されませ

ん。内部信号を OBUF 入力に接続する新しく追加されたネットを配線するには、 route_design -nets コマンドを

使用するかネットを手動で配線して、 route_design がフルで実行されてほかのネットの配線が変更されるのを回

避してください。または、既存の配線を保持する route_design -preserve を使用します。詳細は、 79 ページの

「route_design コマンドのその他のオプションの使用」を参照してください。

使用例 3: タイミングを向上するためのパイプライン段の追加

パスにレジスタを追加して組み合わせロジックを複数のサイクルに分割することを「パイプライン処理」と呼びま

す。パイプライン処理すると、パイプラインパスにレイテンシが追加されるので、レジスタ間のパフォーマンスが

向上します。パイプライン処理が機能するかどうかは、デザインのレイテンシ許容度によります。図 3-32 に、

RAMB36E1 から 2 つの LUT6 セルを介して FF に到達するクリティカルパスの回路図を示します。パイプライン段を

追加すると、このクリティカルパスのタイミングを向上できます。これは、ネットリストを変更することにより達

成できます。


図 3-31: デバッグポートを追加/配線した後の回路図





次の Tcl スクリプトは、 2 つの LUT6 セルの間にパイプラインレジスタを追加します。このレジスタは、ロードレジ

スタと同じ制御信号を付けてインプリメントされます。

create_cell -reference [get_lib_cells -of [get_cells {wbOutputData_reg[29]}]] ECO_pipe_stage[29]foreach control_pin {C CE R} {connect_net -net [get_nets -of [get_pins wbOutputData_reg[29]/${control_pin}]] \-objects [get_pins ECO_pipe_stage[29]/${control_pin}]

}disconnect_net -objects \ {egressLoop[4].egressFifo/buffer_fifo/infer_fifo.block_ram_performance.fifo_ram_reg/DOBDO[29]}create_net {egressLoop[4].egressFifo/buffer_fifo/ECO_pipe_stage[29]_in}connect_net -hierarchical -net {egressLoop[4].egressFifo/buffer_fifo/ECO_pipe_stage[29]_in} -objects \ [list \ {ECO_pipe_stage[29]/D} \ {egressLoop[4].egressFifo/buffer_fifo/infer_fifo.block_ram_performance.fifo_ram_reg/DOBDO[29]}]

connect_net -hierarchical -net {egressLoop[4].egressFifo/buffer_fifo/dout2_in[29]} -objects [list \ {ECO_pipe_stage[29]/Q}]


図 3-32: パイプラインレジスタを追加する前の回路図





次の図に、論理ネットリストの変更が反映された回路図を示します。

ネットリストを変更したら、論理的な変更を確定する必要があります。これには、 place_design および

route_design コマンドを使用します。


図 3-33: パイプラインレジスタを追加した後の回路図





Vivado ECO フロー

重要: ECO は、デザインチェックポイントにのみ使用できます。 ECO レイアウトは、デザインチェックポイントを

Vivado IDE で開いた後にのみ使用できます。

エンジニアリングチェンジオーダー (ECO) とは、インプリメンテーション後のネットリストへの変更のことで、元

のデザインへの影響を低限に抑えて変更をインプリメントするために使用します。 Vivado の ECO フローを使用す

ると、デザインチェックポイントを変更してその変更をインプリメントし、変更されたネットリストのレポートを

出力して、プログラムファイルを生成できます。

ECO フローは、次のような場合に使用します。

• ILA または VIO コアのデバッグプローブを変更する場合

• 内部ネットを外部プローブのパッケージピンに配線する場合

• what-if シナリオ (タイミングの改善、ロジックバグの修正など) を評価する場合

ECO フローを使用すると、 Vivado のインクリメンタルな配置配線機能の利点を活かしながら、ターンアラウンドタ

イムを短縮できます。

Vivado IDE には、 ECO フローをサポートする定義済みのレイアウトが含まれています。

[ECO] レイアウトを表示するには、 [Layout] → [ECO] をクリックします。

ECO Navigator

ECO Navigator からは、 ECO を実行するのに必要なコマンドにアクセスできます。





[Scratch Pad] ウィンドウ

[Scratch Pad] ウィンドウには、ネットリストの変更記録と、セル、ピン、ポート、およびネットの配置配線ステータ

スが示されます。


図 3-34: Vivado の [ECO] レイアウト





ECO フローチャート

次の図に、典型的な ECO フローを示します。インプリメント済みデザインを開きます。ネットリストを変更した

後、デザインが完全に配置されていない場合は、インクリメンタル配置を実行します。完全に配置されている場合

は、インクリメンタル配線に進みます。新しいチェックポイントへの変更を保存して新しいプログラムおよびデ

バッグプローブファイルを生成したら、ハードウェアマネージャーを開いてデバイスをプログラムします。変更に

問題がなければ、元のデザインにその変更を反映します。問題がある場合は、デザインが問題なく機能するように

なるまで ECO フローを初から繰り返します。

ヒント : インプリメンテーションをプロジェクトモードで再実行する場合、前の run ディレクトリの結果は削除され

ます。 ECO チェックポイントを新しいディレクトリに保存して、そのコンパイル用に新しいインプリメンテーショ

ン run を作成すると、 ECO チェックポイントへの変更を保持できます。


図 3-35: ECO フローチャート





ECO Navigator の使用方法

ECO Navigator からは、 ECO を実行するのに必要なすべてのコマンドにアクセスできます。 ECO Navigator には、

[Edit]、 [Run]、 [Report]、 [Program] の 4 つのセクションがあります。

[Edit] セクション

ECO Navigator の [Edit] セクション (次の図) からは、ネットリストを変更するのに必要なコマンドすべてにアクセス

できます。

[Create Net]: 現在読み込まれているデザインで新しいネットを作成する [Create Net] ダイアログボックスを開きます。

ネットはデザインの上位に作成するか、階層ネット名を指定して任意の階層レベルに作成できます。バスネット

は、増分または減分バスインデックスで作成できます。バスネットを作成するには、 [Create bus] をオンにし、開始

および終了インデックス値を指定します。ピンまたはポートを選択した場合、 [Connect selected pins and ports] をオン

にすると、新しく作成したネットが自動的にピンおよびポートに接続されます。


図 3-36: ECO Navigator の [Edit] セクション


図 3-37: [Create Net] ダイアログボックス





[Create Cell]: 現在読み込まれているデザインのネットリストにセルを追加できる [Create Cell] ダイアログボックスを

開きます。新しいセルインスタンスは、デザインの上位、またはデザインのモジュール内の階層に追加できます。

インスタンスは、ライブラリまたはデザインソースファイルから既存のセルを参照するか、作成されていないセル

を参照するブラックボックスインスタンスを追加することもできます。 LUT セルが作成される場合は、 [Specify

LUT Equation] ダイアログボックスで LUT 式を指定できます。


図 3-38: [Create Cell] ダイアログボックス


図 3-39: [Specify LUT Equation] ダイアログボックス





[Create Port]: [Create Port] ダイアログボックスが開き、ポートを作成して、方向、幅、シングルエンドまたは差動な

どのパラメーターを指定できます。新しいポートは、デザイン階層の上位に追加されます。バスポートを作成す

るには、 [Create bus] をオンにし、開始および終了インデックス値を指定します。 I/O 規格、プルアップ/プルダウン

抵抗、 ODT タイプも指定できます。 [Location] でディレクトリを指定すると、ポートがパッケージピンに割り当て

られます。

[Create Pin]: 現在読み込まれているデザインに単一ピンまたはバスピンを追加できる [Create Pin] ダイアログボック

スを開きます。ピン名だけでなく、方向やバス幅などの属性も指定できます。バスピンを作成するには、 [Create

bus] をオンにし、開始および終了インデックス値を指定します。ピンは、既存のセルインスタンスに作成するか、

create_port コマンドを使用して上位ピンとして作成する必要があります。セルのインスタンス名が指定され

ていない場合、ピンは作成できません。


図 3-40: [Create Port] ダイアログボックス


図 3-41: [Create Pin] ダイアログボックス





[Connect Net]: 選択したピンまたはポートが選択したネットに接続されます。ネットが選択されていない場合、

[Connect Net] ダイアログボックスが開き、選択したピンまたはポートに接続するネットを指定できます。ウィンド

ウには、現在選択しているレベルの階層のネットのリストが表示され、検索ボックスでネット名を入力すると、ダ

イナミックにフィルターできます。選択したネットは、デザインの階層レベルをまたがって接続されます。この際、

必要に応じてピンおよび階層ネットが追加されます。

[Disconnect Net]: 現在のデザインのネットから選択したネット、ピン、ポートまたはセルの接続を解除します。セル

を選択すると、そのセルに接続されたすべてのネットの接続が解除されます。

[Replace Debug Probes]: デバッグコアが挿入されている場合は、 [Replace Debug Probes] ダイアログボックスを開きま

す。 [Replace Debug Probes] ダイアログボックスには、 ILA および VIO コアを使用してプローブされるデザインの

ネットに関する情報が表示されます。 [Probe] 列のネット名の横のアイコンをクリックすると、デバッグプローブに

接続されたネットを変更できます。 [Choose Nets] ダイアログボックスが開き、デバッグプローブに接続する新しい

ネットを選択できます。


図 3-42: [Connect Net] ダイアログボックス






図 3-43: [Replace Debug Probes] ダイアログボックス





[Place Cell]: 選択したデバイスリソースに選択したセルを配置します。

[Unplace Cell]: 選択したセルの配置を現在の配置サイトから解除します。

[Run] セクション

ECO Navigator の [Run] セクション (次の図に表示) からは、現在の変更をインプリメントするのに必要なコマンドす

べてにアクセスできます。

[Check ECO]: 現在のデザインで ECO チェックルールデックを実行します。

ヒント : ECO コマンドを使用すると、ネットリストに無条件に変更を加えることができますが、論理的な変更により

物理的なインプリメンテーションが無効になる場合があります。 [Check ECO] を実行すると、物理的なインプリメン

テーションの前に対処しておく必要のある無効なネットリストの変更や物理的な制限がレポートされます。


図 3-44: [Choose Nets] ダイアログボックス


図 3-45: ECO Navigator の [Run] コマンド





[Optimize Logical Design]: ネットリストを適化するのに、変更したデザインで opt_design を実行する必要のある

こともあります。このコマンドは、 [Optimize Logical Design] ダイアログボックスを開き、 opt_design コマンドの

オプションを指定できます。このダイアログボックスに入力したオプションは、入力した順に opt_design の後に

追加されます。たとえば、 opt_design -sweep を実行するには、 [Options] の下に「-sweep」と入力します。

[Place Design]: 配置の 75% 以上が再利用可能であれば、変更したネットリストでインクリメンタルな

place_design を実行します。 place_design の後のインクリメンタル配置サマリ (Incremental Placement

Summary) には、インクリメンタルな再利用に関する統計が表示されます。このコマンドをクリックすると、

[PlaceDesign] ダイアログボックスが開き、 place_design コマンドのオプションを指定できます。このダイアロ

グボックスに入力したオプションはすべて入力した順に place_design の後に追加されます。

インクリメンタルな配置配線のその他の情報については、 85 ページの「インクリメンタルコンパイル」を参照して

ください。


図 3-46: [Optimize Logical Design] ダイアログボックス


図 3-47: [Place Design] ダイアログボックス





[Optimize Physical Design]: ネットリストを物理適化するのに、変更したデザインで phys_opt_design を実行す

る必要があることもあります。このコマンドでは、 [Optimize Physical Design] ダイアログボックスを開いて、

phys_opt_design コマンドのオプションを指定できます。このダイアログボックスに入力したオプションは、

入力した順に phys_opt_design の後に追加されます。たとえば、 phys_opt_design -fanout_opt を実行

するには、 [Options] の下に「-fanout_opt」と入力します。

[Route Design]: このコマンドをクリックすると、 [Route Design] ダイアログボックスが開きます。このダイアログ

ボックスでは、デザインの変更のインクリメンタル配線、選択したピンの配線、選択したネットの配線のいずれを

実行するかを選択します。変更したネットリストで再利用されるネットが 75% 未満である場合、インクリメンタル

配線を選択すると、インクリメンタルではない route_design に戻されます。

インクリメンタルな配置配線のその他の情報については、 85 ページの「インクリメンタルコンパイル」を参照して

ください。

ECO 変更を配線するには、次の 4 つのオプションがあります。

• [Incremental Route]: デフォルト設定。

• [Route selected pin]: 選択したピンのみ配線します。

• [Route selected non-Power nets]: 選択した信号ネットのみ配線します。

• [Route selected Power nets]: 選択した VCC/GND のみ配線します。


図 3-48: [Optimize Physical Design] ダイアログボックス


図 3-49: [Route Design] ダイアログボックス





[Report] セクション

ECO Navigator の [Report] セクション (次の図に表示) からは、変更したデザインに対してレポートを生成するために

必要なコマンドすべてにアクセスできます。

これらのコマンドの詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 3]を参照してく

ださい。

[Program] セクション

ECO Navigator の [Program] セクション (次の図に表示) からは、変更の保存、プログラム用の新しい BIT ファイルおよび

デバッグプローブ用の新しい LTX ファイルの生成、デバイスのプログラムを実行するコマンドにアクセスできます。


図 3-50: ECO Navigator の [Report] コマンド


図 3-51: ECO Navigator の [Program] コマンド





[Save Checkpoint As]: 変更を新しいチェックポイントに保存します。

[Generate Bitstream]: プログラム用の新しい .bit ファイルを生成します。

[Write Debug Probes]: デバッグプローブ用の新しい LTX ファイルを生成します。 [Replace Debug Probes] コマンドを使

用してデバッグプローブに変更を加えた場合、その更新した情報を新しいデバッグプローブファイル (LTX) に保存

して、 Vivado ハードウェアマネージャーに変更を反映させる必要があります。


図 3-52: [Save Checkpoint As] ダイアログボックス


図 3-53: [Generate Bitstream] ダイアログボックス





[Scratch Pad] ウィンドウ

[Scratch Pad] ウィンドウは、読み込んだチェックポイントに変更を加えると更新されます。次の図を参照してくださ

い。 [Object Name] 列には、セル、ネット、ポート、ピンの階層名が表示されます。 [Con] 列にはオブジェクトの接

続、 [PnR] 列にはオブジェクトの配置配線ステータスが示されます。次の図に示す [Scratch Pad] ウィンドウでは、

[Con] および [PnR] 列のチェックマークで、接続と配置配線ステータスが示されています。この図からは、次のこと

がわかります。

• ingressFifoWrWn_debug ポートが追加され、パッケージピンに割り当てられています。

• ingressFifoWrEn ネットは新しく作成したポートに接続されていますが、この接続はまだポートまで配線さ

れていません。


図 3-54: [Write Debug Probes] ダイアログボックス


図 3-55: [Scratch Pad] ウィンドウ





[Scratch Pad] ウィンドウのツールバーコマンド

[Scratch Pad] ウィンドウのツールバーには、次のコマンドがあります。

• [Search]: [Scratch Pad] ウィンドウでオブジェクトを名前で検索します。

• [Collapse All]: オブジェクトをグループ別に表示し、グループの個別のメンバーは表示しません。

• [Expand All]: グループのメンバーを展開してすべて表示します。

• [Group by Type]: オブジェクトをタイプ別または追加した順番に表示します。

• [Add selected objects]: 選択したオブジェクトを [Scratch Pad] ウィンドウに追加します。

• [Remove selected objects]: 選択したオブジェクトを [Scratch Pad] ウィンドウから削除します。

[Scratch Pad] ウィンドウのポップアップメニュー

[Scratch Pad] ウィンドウを右クリックすると、次のポップアップメニューコマンドが表示されます。

• [Clear Scratch Pad]: [Scratch Pad] ウィンドウの内容を削除します。

• [Add Objects to Scratch Pad]: 未接続、未配置、未配線のオブジェクトを [Scratch Pad] ウィンドウに追加します。

• [Select Array Elements]: 1 つのエレメントが選択されている場合に、配列内のすべてのエレメントを選択します。

• [Clone]: 選択したオブジェクトのコピーを作成します。

• [Connect Net to Output Port]: [Connect Net to Output Port] ダイアログボックスを開き、選択したネットを外部ポー

トに接続できるようにします。詳細は、図 3-56 を参照してください。

• [Elide Setting]: [Object Name] 列に収まらない長いオブジェクト名のどの部分を切り捨てるか指定します。 [Left] (

左)、 [Middle] (中央)、 [Right] (右) のいずれかを選択します。

• [Object Properties]: [Object Properties] ダイアログボックスを開きます。

• [Report Net Route Status]: 選択したネットの配線ステータスをレポートします。

• [Select Driver Pin]: 選択したネットのドライバーピンを選択します。

• [Unplace]: 選択した I/O ポートの配置を解除します。

• [Configure I/O Ports]: 選択した I/O ポートのプロパティを指定します。

• [Split Diff Pair]: 選択したポートから差動ペアの関連付けを削除します。

• [Auto-place I/O Ports]: Autoplace I/O Ports ウィザードを使用して I/O ポートを配置します。

• [Place I/O Ports in Area]: 現在選択されているポートを指定したエリアのピンに割り当てます。

• [Place I/O Ports Sequentially]: 現在選択されているポートをそれぞれパッケージピンに割り当てます。

• [Fix Ports]: 選択した配置済み I/O ポートを固定します。

• [Unfix Ports]: 選択した配置済み I/O ポートの固定を解除します。

• [Floorplanning]: 選択したセルを Pblock に割り当てます。

• [Highlight Leaf Cells]: 選択したセルのプリミティブロジックをハイライトします。

• [Unhighlight Leaf Cells]: 選択したセルのプリミティブロジックのハイライトを解除します。

• [Delete]: 選択したオブジェクトを削除します。

• [Highlight]: 選択したオブジェクトをハイライトします。

• [Unhighlight]: 選択したオブジェクトのハイライトを解除します。





• [Mark]: 選択したオブジェクトをマークします。

• [Unmark]: 選択したオブジェクトのマークを削除します。

• [Schematic]: 選択したオブジェクトから回路図を作成します。

• [Show Connectivity]: 選択したオブジェクトの接続を表示します。

• [Find]: [Find] ダイアログボックスが開き、 Tcl プロパティおよびオブジェクトに基づくフィルターを使用して作

業中のデザインまたはデバイスに含まれるオブジェクトを検索できます。

• [Export to Spreadsheet]: [Scratch Pad] ウィンドウの内容を Microsoft Excel スプレッドシートに書き出します。X-Ref Target - Figure 3-56

図 3-56: [Connect Net to Output Port] ダイアログボックス





[Schematic] ウィンドウ

ネットリストが変更されるとすぐに、論理的な変更が回路図に反映されます。次の図は、図 3-56 に示すネットリス

トの変更に基づいてアップデートされた回路図です。

ヒント : [Mark Objects] および [Highlights Objects] コマンドを使用すると、ネットリストに加えた変更を回路図のオブ

ジェクトで確認できます。


図 3-57: [Schematic] ウィンドウ




付録 A

リモートホストおよび LSF の使用

リモート Linux ホストでの run の実行

概要

ザイリンクス Vivado® IDE では、複数の Linux ホストで同時に合成およびインプリメンテーション run を実行できま

す。これには、 LSF (Load Sharing Facility) を使用するか、手動でホストを設定します。

LSF を使用したリモートホストの設定方法は、 157 ページの「LSF を使用したリモートホストの設定」を参照して

ください。

リモートホストを手動で設定する方法は、 159 ページの「リモートホストの手動設定」を参照してください。

LSF について

LSF は、クラスターの複数の計算サーバー間でバッチジョブを投入、スケジュール、実行、監視、ワークロード制

御するためのサブシステムです。 LSF を介して Vivado Design Suite で合成 run およびインプリメンテーションを実行

するには、 bsub コマンドを使用します。

Linux およびリモートホストのサポート

Microsoft Windows システムにはリモートシェル機能がなく、 Linux の方がセキュリティ機能が優れているというこ

とから、リモートホストは Linux でのみサポートされます。

ジョブ投入アルゴリズムと SSH

ジョブ投入アルゴリズムは、 Linux OS のサービスであるセキュアシェル (SSH) 内の Tcl パイプを使用したラウンド

ロビン形式でインプリメントされています。

推奨: Vivado IDE で手動で設定して複数の Linux ホストで run を実行する前に、リモート run を実行するたびにパス

ワードを入力しなくて済むように SSH を設定する必要があります。

SSH の設定方法は、 161 ページの「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] → [Settings] をクリックし、左側のペインで [Remote Hosts] をクリックします。

° [Launch Runs] ダイアログボックスで [Configure LSF] をクリックします。

° Create New Runs ウィザードの [Launch Options] ページで [Configure LSF] をクリックします。

図 A-1 に、 Create New Runs ウィザードの [Launch Options] ページで LSF を使用するため [Launch runs using LSF] オプ

ションをオンにしたところを示します。

X-Ref Target - Figure A-1

図 A-1: Create New Runs ウィザードの [Launch Options] ページでの LSF の設定





2. [Settings] ダイアログボックスの [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: [Settings] ダイアログボックスの [Remote Hosts] ページ





リモートホストの手動設定

リモート Linux ホストで合成またはインプリメンテーションを実行できるように Vivado IDE を設定するには、次の手

順に従います。

1. 次のいずれかを実行します。

° メインメニューから [Tools] → [Settings] をクリックし、左側のペインで [Remote Hosts] をクリックします。

° [Launch Runs] ダイアログボックスで [Configure Hosts] をクリックします。

° Create New Runs ウィザードの [Launch Options] ページで [Configure Hosts] をクリックします。

図 A-3 に、[Launch Runs] ダイアログボックスで [Launch runs on remote hosts] オプションをオンにしたところを示

します。


図 A-3: [Launch Selected Runs] ダイアログボックスでのリモートホストの設定





2. [Settings] ダイアログボックスの [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 つまたは複数のホストを選択し、 [Test] をクリックします。

サーバーが使用可能かどうか、設定が正しいかどうかが確認されます。

推奨: ホストで run を実行する前に、各ホストをテストして正しく設定されていることを確認してください。

リモートホストの削除

リモートホストを削除するには、右クリックして [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

これで、どのリモートマシンでもパスワードを入力せずに使用できます。新しいマシンに初めてアクセスする場合

は、パスワードを入力するよう求められますが、次回からは入力する必要はありません。

ヒント : 毎回パスワードの入力を求められる場合は、システム管理者に連絡してください。




インプリメンテーション 162UG904 (v2017.3) 2017 年 10 月 27 日 japan.xilinx.com

付録 B

ISE コマンドと Vivado コマンドの対照表

Tcl コマンドとオプション

Vivado® インプリメンテーションには、 ISE® ツールコマンドに対応するコマンドラインオプションがいくつかあり

ます。

表 B-1 に、 ISE ツールコマンドラインオプションと、同等の Vivado Design Suite Tcl コマンドおよび Tcl コマンドオ

プションを示します。 Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参

照 18] を参照するか、「<command> -help」と入力してください。

表 B-1: ISE コマンドと Vivado コマンドの対照表

ISE コマンド Vivado Tcl コマンドとオプション

ngdbuild -p partname link_design -part partname

ngdbuild -a (パッドを挿入) synth_design -mode out_of_context (バッファーを挿入

しない)

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

UG904 (v2017.4) 2017 年 12 月 20 日



付録 C

インプリメンテーションのカテゴリ、ストラテジの説明、および -directive の値

インプリメンテーションのカテゴリI

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

表 C-1: インプリメンテーションのカテゴリ

カテゴリ目的

Performance (パフォーマンス) デザインパフォーマンスを向上します。

Area (エリア) LUT 数を削減します。

Power (消費電力) 消費電力適化を実行します。

Flow (フロー ) フロー手順を変更します。

Congestion (密集) 密集および関連の問題を低減します。

表 C-2: インプリメンテーションストラテジの説明

インプリメンテーションストラテジ名説明

Vivado® Implementation Defaults 適度な実行時間でタイミングクロージャが満たされるようにします。

Performance_Explore 結果を向上するため、適化、配置、配線に複数のアルゴリズムを使用します。

Performance_

ExplorePostRoutePhysOptPeformance_Explore と同様ですが、さらに改善できるように配線後に物理適

化 (phys_opt_design) を追加します。

Performance_WLBlockPlacement ブロック RAM および DSP の配置の際にタイミング制約を無視してワイヤ長を

代わりに使用します。

Performance_

WLBlockPlacementFanoutOptブロック RAM および DSP を配置する際にタイミング制約を無視してワイヤ長

を使用し、ファンアウトの大きいドライバーの複製を積極的に実行します。

Performance_EarlyBlockPlacement グローバル配置の初期段階でブロック RAM および DSP の配置を確定します。

Performance_NetDelay_high 良く見積もられた遅延を補正するため、距離の長いファンアウトの大きい接続

の遅延コストを増加します。 Performance_NetDelay_high では増加量が大にな

ります。

Performance_NetDelay_low 良く見積もられた遅延を補正するため、距離の長いファンアウトの大きい接続

の遅延コストを増加します。 Performance_NetDelay_low では増加量が小にな

ります。




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

Performance_Retiming phys_opt_design のリタイミングに加えて、追加の配置適化を実行し、配

線遅延コストを大きくします。

Performance_ExtraTimingOpt タイミングドリブンの適化を追加で実行し、全体的なタイミングスラックを

改善する可能性を広げます。

Performance_RefinePlacement 配置後の適化のエフォートを増加し、配線でのタイミングの緩和をディス

エーブルにします。

Performance_SpreadSSL SSI デバイスの配置バリエーション (SLR をまたぐ部分を横方向に分散する傾向

あり )。

Performance_BalanceSSL SSI デバイスの配置バリエーション (SLR 境界をまたぐ場合が多くなる )。

Congestion_SpreadLogic_high デバイス全体にロジックを分散し、密集した領域が作成されないようにします。

high 設定では、分散度が高になります。

Congestion_SpreadLogic_

mediumデバイス全体にロジックを分散し、密集した領域が作成されないようにします。

medium 設定では、分散度が中程度になります。

Congestion_SpreadLogic_low デバイス全体にロジックを分散し、密集した領域が作成されないようにします。

low 設定では、分散度が低になります。

Congestion_SpreadLogic_

ExploreCongestion_SpreadLogic_high と同様ですが、配線の -directive オプ

ションに Explore を使用します。

Congestion_SSI_SpreadLogic_high SSI デバイス用のストラテジで、デバイス全体にロジックを分散し、密集した

領域が作成されないようにします。 high 設定では、分散度が高になります。

Congestion_SSI_SpreadLogic_low SSI デバイス用のストラテジで、デバイス全体にロジックを分散し、密集した

領域が作成されないようにします。 low 設定では、分散度が低になります。

Congestion_SSI_SpreadLogic_

ExploreCongestion_SSI_SpreadLogic_high と同様ですが、配線のために

-directive オプションに Explore を使用します。

Area_Explore LUT 数を削減するため、複数の適化アルゴリズムを使用します。

Area_ExploreSequential Area_Explore と同様ですが、シーケンシャルセルに適化を追加します。

Area_ExploreWithRemap Area_Explore と同様ですが、リマップ適化を追加してロジックレベルを

圧縮します。

Power_DefaultOpt 消費電力を削減するため、消費電力適化 (power_opt_design) を実行します。

Power_ExploreArea シーケンシャルエリア適化と消費電力適化 (power_opt_design) を組み

合わせ、消費電力を削減します。

Flow_RunPhysOpt Vivado Implementation Defaults と同様ですが、物理適化 (phys_opt_design)

を実行します。

Flow_RunPostRoutePhysOpt Flow_RunPhysOpt と同様ですが、配線後の物理適化段階を -directive

Explore オプションで実行します。

Flow_RuntimeOptimized 各インプリメンテーション段階で、デザインパフォーマンスよりも実行時間を

短縮することを優先します。物理適化 (phys_opt_design) はディスエーブ

ルになります。

Flow_Quick 実行時間をできるだけ短くします。タイミングドリブンの処理はすべてディス

エーブルになります。使用率を見積もる際に有益です。

表 C-2: インプリメンテーションストラテジの説明 (続き)

インプリメンテーションストラテジ名説明





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

表 C-3: インプリメンテーションストラテジで使用される opt_design および place_design の -directive の値

ストラテジ opt_design -directive place_design -directive

Performance_Explore Explore Explore

Performance_ExplorePostRoutePhysOpt Explore Explore

Performance_WLBlockPlacement Default WLDrivenBlockPlacement

Performance_WLBlockPlacementFanoutOpt Default WLDrivenBlockPlacement

Performance_EarlyBlockPlacement Default EarlyBlockPlacement

Performance_NetDelay_high Default ExtraNetDelay_high

Performance_NetDelay_low Default ExtraNetDelay_low

Performance_Retiming Default ExtraPostPlacementOpt

Performance_ExtraTimingOpt Default ExtraTimingOpt

Performance_RefinePlacement Default ExtraPostPlacementOpt

Performance_SpreadSLLs Default SSI_SpreadSLLs

Performance_BalanceSLLs Default SSI_BalanceSLLs

Congestion_SpreadLogic_high Default AltSpreadLogic_high

Congestion_SpreadLogic_medium Default AltSpreadLogic_medium

Congestion_SpreadLogic_low Default AltSpreadLogic_low

Congestion_SpreadLogic_Explore Default AltSpreadLogic_high

Congestion_SSI_Spreadlogic_high Default SSI_SpreadLogic_high

Congestion_SSI_Spreadlogic_low Default SSI_SpreadLogic_low

Congestion_SSI_Spreadlogic_Explore Default SSI_SpreadLogic_high

Area_Explore ExploreArea Default

Area_ExploreSequential ExploreSequentialArea Default

Area_ExploreWithRemap ExploreWithRemap Default

Power_DefaultOpts Default Default

Power_ExploreArea ExploreSequentialArea Default

Flow_RunPhysOpt Default Default

Flow_RunPostRoutePhysOpt Default Default

Flow_RuntimeOptimized RuntimeOptimized RuntimeOptimized

Flow_Quick RuntimeOptimized Quick





インプリメンテーションストラテジで使用される 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 Explore

Performance_WLBlockPlacement AlternateReplication Explore

Performance_WLBlockPlacementFanoutOpt AggressiveFanoutOpt Explore

Performance_EarlyBlockPlacement Explore Explore

Performance_NetDelay_high AggressiveExplore Explore

Performance_NetDelay_low AggressiveExplore Explore

Performance_Retiming AlternateFlowWithRetiming Explore

Performance_ExtraTimingOpt Explore Explore

Performance_RefinePlacement Default NoTimingRelaxation

Performance_SpreadSLLs Explore Explore

Performance_BalanceSLLs Explore Explore

Congestion_SpreadLogic_high AggressiveExplore AlternateCLBRouting

Congestion_SpreadLogic_medium Explore AlternateCLBRouting

Congestion_SpreadLogic_low Explore AlternateCLBRouting

Congestion_SpreadLogic_Explore AggressiveExplore Explore

Congestion_SSI_SpreadLogic_high AggressiveExplore AlternateCLBRouting

Congestion_SSI_SpreadLogic_low Explore AlternateCLBRouting

Congestion_SSI_SpreadLogic_Explore AggressiveExplore Explore

Area_Explore ディスエーブル Default

Area_ExploreSequential ディスエーブル Default

Area_ExploreWithRemap ディスエーブル Default

Power_DefaultOpts ディスエーブル Default

Power_ExploreArea ディスエーブル Default

Flow_RunPhysOpt Explore Default

Flow_RunPostRoutePhysOpt Explorea Default

Flow_RuntimeOptimized ディスエーブル RuntimeOptimized

Flow_Quick ディスエーブル Quick

a. Explore は配置後および配線後の phys_opt_design 両方に適用されます。





特定リリースのストラテジの表示

開いている Vivado プロジェクトで list_property_value コマンドを使用すると、特定のリリースの合成および

インプリメンテーションストラテジをリストできます。次は、合成 run synth_1 とインプリメンテーション run

impl_1 を含む Vivado バージョン 2017.3 プロジェクトを使用した例です。

Vivado% join [list_property_value strategy [get_runs synth_1] ] \nVivado Synthesis DefaultsFlow_AreaOptimized_highFlow_AreaOptimized_mediumFlow_AreaMultThresholdDSPFlow_AlternateRoutabilityFlow_PerfOptimized_highFlow_PerfThresholdCarryFlow_RuntimeOptimized

Vivado% join [list_property_value strategy [get_runs impl_1] ] \nVivado Implementation DefaultsPerformance_ExplorePerformance_ExplorePostRoutePhysOptPerformance_WLBlockPlacementPerformance_WLBlockPlacementFanoutOptPerformance_EarlyBlockPlacementPerformance_NetDelay_highPerformance_NetDelay_lowPerformance_RetimingPerformance_ExtraTimingOptPerformance_RefinePlacementPerformance_SpreadSLLsPerformance_BalanceSLLsCongestion_SpreadLogic_highCongestion_SpreadLogic_mediumCongestion_SpreadLogic_lowCongestion_SpreadLogic_ExploreCongestion_SSI_SpreadLogic_highCongestion_SSI_SpreadLogic_lowCongestion_SSI_SpreadLogic_ExploreArea_ExploreArea_ExploreSequentialArea_ExploreWithRemapPower_DefaultOptPower_ExploreAreaFlow_RunPhysOptFlow_RunPostRoutePhysOptFlow_RuntimeOptimizedFlow_Quick

ストラテジのリストには、ユーザー定義のストラテジも含まれます。





特定リリースの -directive 値の表示

特定のリリースで使用可能なコマンドの -directive の値をリストできます。これには、 Tcl を使用して run のプロ

パティをリストします。各デザイン run には、デザイン run の各段階に対応するプロパティが含まれています。

STEPS.<STEP>_DESIGN.ARGS.DIRECTIVE

<STEP> には、 SYNTH、 OPT、 PLACE、 PHYS_OPT、または ROUTE のいずれかを指定します。このプロパティは列

挙型であり、 list_property_value を使用してサポートされるすべての値を返すことができます。次に例を示

します。

Vivado% list_property_value STEPS.SYNTH_DESIGN.ARGS.DIRECTIVE [get_runs synth_1]RuntimeOptimizedAreaOptimized_highAreaOptimized_mediumAlternateRoutabilityAreaMapLargeShiftRegToBRAMAreaMultThresholdDSPFewerCarryChainsDefault

次の Tcl では、一時的な空のプロジェクトを使用して、合成およびインプリメンテーションコマンドの

-directive のモードをリストする方法を示します。

create_project p1 -force -part xcku035-fbva900-2-e

#get synth_design directivesset steps [list synth]set run [get_runs synth_1]foreach s $steps {puts "${s}_design Directives:"set dirs [list_property_value STEPS.${s}_DESIGN.ARGS.DIRECTIVE $run]set dirs [regsub -all {\s} $dirs \n]puts "$dirs\n"

}

#get impl directivesset steps [list opt place phys_opt route]set run [get_runs impl_1]foreach s $steps {puts "${s}_design Directives:"set dirs [list_property_value STEPS.${s}_DESIGN.ARGS.DIRECTIVE $run]set dirs [regsub -all {\s} $dirs \n]puts "$dirs\n"

}close_project -delete




付録 D

その他のリソースおよび法的通知

ザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照して

ください。

ソリューションセンター

デバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。デザイ

ンアシスタント、デザインアドバイザリ、トラブルシューティングのヒントなどが含まれます。

Documentation Navigator およびデザインハブ

Xilinx Documentation Navigator (DocNav) を使用するとザイリンクスの資料、ビデオ、およびサポートリソースにアク

セスして情報をフィルター、検索できます。 Xilinx Documentation Navigator を開くには、次のいずれかを実行します。

• Vivado IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux コマンドプロンプトに「docnav」と入力します。

ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられてお

り、これらを参照することでキーコンセプトを学び、よくある質問を解決できます。デザインハブにアクセスする

には、次のいずれかを実行します。

• Xilinx Documentation Navigator で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: Documentation Navigator の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してく

ださい。

注意: Xilinx Documentation Navigator からは日本語版は参照できません。ウェブサイトのデザインハブページの一部

は翻訳されており、日本語版が提供されている場合はそのリンクも追加されています。



https://japan.xilinx.com/support

https://japan.xilinx.com/support/solcenters.htm

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav


付録 D: その他のリソースおよび法的通知

参考資料

注記: 日本語版のバージョンは、英語版より古い場合があります。

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)

13. 『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949)

14. 『Vivado Design Suite プロパティリファレンスガイド』 (UG912)

15. 『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909)

その他の Vivado Design Suite 関連の資料

16. 『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472: 英語版、日本語版)

17. 『UltraScale™ アーキテクチャクロッキングリソースユーザーガイド』 (UG572: 英語版、日本語版)

18. 『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)

19. 『ISE から Vivado Design Suite への移行手法ガイド』 (UG911)

20. 『Vivado Design Suite チュートリアル: デザインフローの概要』 (UG888)

Vivado Design Suite の資料サイト

21. Vivado Design Suite の資料


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug472_7Series_Clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug472_7Series_Clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug572-ultrascale-clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug572-ultrascale-clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug892-vivado-design-flows-overview.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug905-vivado-hierarchical-design.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug896-vivado-ip.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug894-vivado-tcl-scripting.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug895-vivado-system-level-design-entry.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug994-vivado-ip-subsystems.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug901-vivado-synthesis.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug903-vivado-using-constraints.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug906-vivado-design-analysis.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug907-vivado-power-analysis-optimization.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug908-vivado-programming-debugging.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug949-vivado-design-methodology.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug912-vivado-properties.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug909-vivado-partial-reconfiguration.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug911-vivado-migration.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug888-vivado-design-flows-overview-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;t=vivado+docs



付録 D: その他のリソースおよび法的通知

トレーニングリソース

ザイリンクスでは、この資料に含まれるコンセプトを説明するさまざまなトレーニングコースおよび QuickTake ビデ

オを提供しています。次のリンクから関連するトレーニングリソースを参照してください。

1. トレーニングコース : Vivado Design Suite を使用した FPGA の設計 1




お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供

され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれ

らに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または

貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わな

い (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害に

は、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の

損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能で

あったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に

含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いま

せん。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一

定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件

に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケー

ションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を

使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2012-2017 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含

まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、それぞれ

の保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。


mailto:[email protected]

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=designing-fpgas-vivado-design-suite-1.html




https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos



Date post:	05-Oct-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Vivado Design Suite - XilinxTcl API を使用すると、すべてのデザイン...

Documents