Vivado Design Suite ユーザー ガイド : インプリメンテーション (UG904)

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

Notice of Disclaimer The information disclosed to you hereunder (the Materials ) is provided solely for the selection and use of Xilinx products.to the maximum extent permitted by applicable law:(1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same.xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the Materials or to product specifications.you may not reproduce, modify, distribute, or publicly display the Materials without prior written consent.certain products are subject to the terms and conditions of the Limited Warranties which can be viewed at http://www.xilinx.com/warranty.htm; IP cores may be subject to warranty and support terms contained in a license issued to you by Xilinx.Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in Critical Applications:http://www.xilinx.com/warranty.htm#critapps. Copyright 2012-2013 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the United States and other countries.all other trademarks are the property of their respective owners. 本資料は英語版 (v2013.1) を翻訳したもので 内容に相違が生じる場合には原文を優先します 資料によっては英語版の更新に対応していないものがあります 日本語版は参考用としてご使用の上 最新情報につきましては 必ず最新英語版をご参照ください この資料に関するフィードバックおよびリンクなどの問題につきましては jpn_trans_feedback@xilinx.com までお知らせください いただきましたご意見を参考に早急に対応させていただきます なお このメールアドレスへのお問い合わせは受け付けておりません あらかじめご了承ください 改訂履歴 次の表に この文書の改訂履歴を示します 日付バージョン改訂内容 2013 年 3 月 20 日 2013.1 -no_timing_driven オプションの使用 および -verbose オプションの使用 に関する情報を追加 インプリメンテーションストラテジ を大幅に拡張 手動配線 をアップデート 新しいセクション LUT ロードのセル入力の固定 を追加 新しいセクション -directive オプションの使用 を追加 物理合成 セクションタイトルをコマンド名に合わせて 物理最適化 に変更 物理最適化 に新しい情報を追加 新しいセクション 物理最適化制約 を追加 phys_opt_design のオプションに関する詳細情報を追加 インプリメンテーションコマンド の情報を更新 付録 A リモートホストの使用 を大幅にアップデートおよび変更 Tcl コマンドの用語に合わせて インスタンス を セル に 属性 を プロパティ に変更 (HDL キーワードを除く ) 第 2 章 RPM の定義 を削除 (XDC マクロに関する新しいセクションも含む ) この章は Vivado Design Suite ユーザーガイド : 制約の使用 (UG903) に移動されます 全体的にマイナーな表現およびフォーマットの編集 さまざまな図をアップデート コード例を修正 インプリメンテーション japan.xilinx.com 2

目次 改訂履歴.......................................................................................... 2 第 1 章 : Vivado インプリメンテーションプロセス Vivado インプリメンテーションプロセスについて...................................................... 5 インプリメンテーションの前に...................................................................... 8 IP の設定 インプリメント および検証............................................................. 11 インプリメンテーションでのデザイン制約の使用..................................................... 12 デザインチェックポイントでデザインのスナップショットを保存および復元............................. 14 非プロジェクトモードでのインプリメンテーションの実行............................................. 15 プロジェクトモードでのインプリメンテーションの実行............................................... 18 インプリメンテーションストラテジのカスタマイズ................................................... 28 インプリメンテーション run の起動.................................................................. 33 プロセスのバックグラウンドへの移動............................................................... 35 インプリメンテーションの段階ごとの実行........................................................... 35 インプリメンテーション run の監視.................................................................. 36 インクリメンタルコンパイルを使用した配置配線の実行時間の短縮..................................... 40 インプリメンテーション完了後の次の操作........................................................... 47 メッセージの表示................................................................................. 49 インプリメンテーションレポートの表示............................................................. 51 第 2 章 : インプリメンテーションコマンドインプリメンテーションコマンドについて........................................................... 55 インプリメンテーションのサブプロセス............................................................. 55 合成済みデザインを開く........................................................................... 56 ロジック最適化................................................................................... 59 消費電力の最適化................................................................................. 62 配置............................................................................................. 64 物理最適化....................................................................................... 68 配線............................................................................................. 71 第 3 章 : 配線およびロジックの変更配線およびロジックの変更について................................................................. 75 配線の変更....................................................................................... 75 ロジックの変更................................................................................... 84 付録 A : リモートホストの使用リモート Linux ホストでの run の起動................................................................ 86 SSH の設定....................................................................................... 89 付録 B : ISE コマンドと Vivado コマンドの対照表 Tcl コマンドとオプション.......................................................................... 90 インプリメンテーション japan.xilinx.com 3

付録 C : その他のリソースザイリンクスリソース............................................................................. 91 ソリューションセンター........................................................................... 91 参考資料......................................................................................... 91 インプリメンテーション japan.xilinx.com 4

第 1 章 Vivado インプリメンテーションプロセス Vivado インプリメンテーションプロセスについて ザイリンクス Vivado Design Suite では 次のようなさまざまなデザインソースからザイリンクス 7 シリーズ FPGA デザインをインプリメンテーションできます RTL デザイン ネットリストデザイン IP 中心のデザイン 詳細は 図 1-1 を参照してください Vivado インプリメンテーションは デザインの論理制約 物理制約 タイミング制約を満たしながらネットリストを FPGA デバイスリソースに配置配線するためのすべての手順を含みます Vivado ツールでサポートされるデザインフローの詳細は Vivado Design Suite ユーザーガイド : デザインフローの概要 (UG892) [ 参照 1] を参照してください Vivado インプリメンテーションでの SDC および XDC 制約のサポート Vivado インプリメンテーションは タイミングドリブンフローです デザインの要件および制限を指定するのに 業界標準の Synopsys デザイン制約 (SDC) とザイリンクスデザイン制約 (XDC) がサポートされます インプリメンテーション japan.xilinx.com 5

Vivado インプリメンテーションプロセスについて X-Ref Target - Figure 1-1 Vivado インプリメンテーションのサブプロセス Vivado インプリメンテーションプロセスには デザインの論理変換および物理変換が含まれます インプリメンテーションプロセスには 次のサブプロセスがあります opt_design ( デザインの最適化 ) ターゲットのザイリンクスデバイスにフィットしやすいように論理デザインを最適化します power_opt_design ( デザインの消費電力最適化 ) ターゲットのザイリンクスデバイスの消費電力を削減するようデザインエレメントを最適化します 注記 : この手順はオプションです place_design ( デザインの配置 ) デザインをターゲットザイリンクスデバイスに配置します phys_opt_design ( デザインの物理最適化 ) ファンアウトの大きいネットのドライバーを複製してロードを分散することにより デザインのタイミングを最適化します 注記 : この手順はオプションです route_design ( デザインの配線 ) デザインをターゲットザイリンクスデバイスに配線します write_bitstream ( ビットストリームの生成 ) 図 1-1 : Vivado Design Suite のデザインフロー ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します インプリメンテーション japan.xilinx.com 6

Vivado インプリメンテーションプロセスについて Flow Navigator からデザインを統合 インプリメント 検証 Vivado 統合設計環境 (IDE) を使用すると 完全なデザインフローを実行できます Vivado IDE には Flow Navigator というフローを制御するインターフェイスがあります Flow Navigator から デザインおよび IP を統合 インプリメント および検証できます デザインフローを簡略化するため インプリメンテーションプロセス全体をコマンドをクリックするだけで実行できます 詳細は 図 1-2 を参照してください X-Ref Target - Figure 1-2 図 1-2 : Flow Navigator : [Implemention] セクション 重要 : このガイドでは インプリメンテーション以外の Vivado IDE の詳細は説明しません FPGA デザインフロー全体に関連する Vivado IDE の詳細は Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] を参照してください Tcl API によるスクリプトのサポート Vivado Design Suite には Tcl API が含まれています Tcl API を使用すると すべてのデザインフローをスクリプトで実行でき デザインフローを要件に合わせてカスタマイズできます 注記 : Tcl コマンドの詳細は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) [ 参照 12] を参照するか <command> -help と入力してください インプリメンテーション japan.xilinx.com 7

インプリメンテーションの前に インプリメンテーションの前に Vivado Design Suite ではさまざまなデザインフローが提供されており 多種のデザインソースがサポートされています FPGA デバイスにダウンロード可能なビットストリームを生成するには インプリメンテーションを実行する必要があります インプリメンテーションは 論理ネットリストをターゲットザイリンクスデバイスの物理的なアレイにマップするための一連の手順を指します 次の手順が含まれます ロジック最適化 ライブラリセルの配置 セル間の接続の配線 プロジェクトモードと非プロジェクトモード プロジェクトファイル (.xpr) とそのディレクトリ構造を作成すると 次が可能になります デザインソースファイルの管理 合成 run およびインプリメンテーション run の結果の保存 デザインフローを通してプロジェクトステータスを監視 ヒント : プロジェクトファイルおよびローカルディレクトリを作成せずに すべてメモリ内で作業することも可能です プロジェクトモード プロジェクトモードでは ディスク上にディレクトリ構造が作成され 次が管理されます デザインソース run 結果 プロジェクトステータス デザインデータ プロセス およびステータスを自動管理するには Vivado プロジェクトファイル (.xpr) に保存されるプロジェクトインフラストラクチャが必要です また デザインフローの主要な段階のチェックポイントファイルが 自動的にローカルプロジェクトディレクトリに保存されます インプリメンテーション japan.xilinx.com 8

インプリメンテーションの前に 非プロジェクトモード プロジェクトファイルを使用しないコンパイル形式のフローは 非プロジェクトモードと呼ばれます 非プロジェクトモードでは デザインをメモリ内ですべて操作できます ソースファイルおよびデザイン制約は 現在の場所からメモリに読み込みます メモリ内のデザインでデザインフローを実行する際 中間ファイルが記述されることはありません 非プロジェクトモードでは Tcl コマンドを使用し デザインパラメーターおよびインプリメンテーションオプションを設定して 各手順を個別に実行する必要があります 変更を保存したり手順を再実行したりする必要なく デザインに変更を加え デザインフローを続行できます デザインフローのどの段階でも レポートを生成したり デザインチェックポイント (.dcp) を保存したりできます 重要 : 非プロジェクトモードでは Vivado デザインツールを終了すると メモリ内のデザインは失われます そのため 合成 配置 配線などの主な手順が終了したら デザインチェックポイントを保存することをお勧めします デザインチェックポイントは プロジェクトモードおよび非プロジェクトモード両方で保存できます デザインチェックポイントを読み込むことができるのは 非プロジェクトモードのみです プロジェクトモードと非プロジェクトモードの違い Vivado インプリメンテーションは プロジェクトモードおよび非プロジェクトモード両方で実行できます Vivado IDE および Tcl API は プロジェクトモードおよび非プロジェクトモード両方で使用できます プロジェクトモードと非プロジェクトモードには 違いも多数あります 次に 非プロジェクトモードでは使用できない機能を示します Flow Navigator デザインステータスインジケーター IP カタログ インプリメンテーション run および run ストラテジ [Design Runs] ビュー [Messages] ビュー [Reports] ビュー 注記 : このリストには 非プロジェクトモードでサポートされない機能がすべて含まれているわけではありません 非プロジェクトベースのデザインをインプリメントするには 次の Tcl コマンドを個別に実行する必要があります opt_design place_design route_design インプリメンテーションの各段階は Vivado IDE または Tcl コンソールから対話的に実行するか カスタム Tcl スクリプトを使用して実行できます デザインフローは 必要に応じてレポートコマンドや最適化を追加してカスタマイズできます 詳細は 非プロジェクトモードでのインプリメンテーションの実行 を参照してください このガイドでは プロジェクトモードおよび非プロジェクトモードでのインプリメンテーションの実行について詳細に説明します プロジェクトモードまたは非プロジェクトモードを使用した Vivado Design Suite の実行に関する詳細は 次の資料を参照してください Vivado Design Suite ユーザーガイド : デザインフローの概要 (UG892) [ 参照 1] Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] インプリメンテーション japan.xilinx.com 9

インプリメンテーションの前に RTL および合成済みデザイン Vivado Design Suite を使用して RTL 開発 IP のカスタマイズ 合成 インプリメンテーション デバイスのプログラムおよび検証まで FPGA デザインフロープロセスすべてを管理できます プロジェクトへのオブジェクトの追加 次のオブジェクトをプロジェクトに追加できます Verilog SystemVerilog VHDL ファイルなどの HDL ソースファイル 定義およびコンフィギュレーション済みのザイリンクス IP コア System Generator からの DSP ( デジタル信号処理 ) モジュール Vivado 高位合成 (HLS) からの C ベースの DSP モジュール Xilinx Platform Studio (XPS) からのエンベデッドプロセッサモジュール 合成済みネットリストのインポート Vivado Design Suite では ネットリストデザインがサポートされており ザイリンクスツールまたはサードパーティツールで合成済みのネットリストをインポートできます サポートされるネットリストフォーマットは 次のとおりです Structural Verilog SystemVerilog EDIF ザイリンクス NGC Vivado Design Suite でサポートされるソースファイルおよびプロジェクトタイプの詳細は Vivado Design Suite ユーザーガイド : システムレベルデザイン入力 (UG895) [ 参照 4] を参照してください RTL ソースから開始 Vivado インプリメンテーションを実行するには 合成済みネットリストが必要です デザインは合成済みネットリストから または RTL ソースファイルから開始できます 重要 : RTL ソースから開始する場合は インプリメンテーションの前に Vivado 合成または XST を実行する必要があります Vivado IDE では これが自動的に管理されます 合成されていないデザインをインプリメントしようとすると まず合成を実行するかどうかを選択するオプションが表示されます Vivado 合成の詳細は Vivado Design Suite ユーザーガイド : 合成 (UG901) [ 参照 6] を参照してください 非プロジェクトモードで合成済みデザインを作成して開く 非プロジェクトモードでは Tcl コマンド synth_design を使用して合成を実行し 合成済みデザインを作成して開く必要があります サポートされている入力フォーマットの合成済みネットリストを開くには Tcl コマンド link_design も使用できます 詳細は 第 2 章 インプリメンテーションコマンド の 合成済みデザインを開く を参照してください インプリメンテーション japan.xilinx.com 10

IP の設定 インプリメント および検証 プロジェクトモードでインプリメンテーション前にデザインネットリストを読み込む プロジェクトモードでは RTL デザインの合成後 またはネットリストベースプロジェクトを開いて インプリメンテーション前のデザインネットリストを読み込むことができます 合成済みデザインを開くには 次のいずれかを実行します メインメニューから [Flow] [Open Synthesized Design] をクリックします Flow Navigator で [Synthesis] [Open Synthesized Design] をクリックします [Design Runs] ビューで合成 run を右クリックし [Open Synthesized Design] をクリックします IP の設定 インプリメント および検証 Vivado IP カタログを使用すると IP を設定 インプリメント および検証できます IP は スタンドアロンのモジュールとして またはシステムレベルデザインの一部として設定および検証できます IP カタログの内容 IP カタログには ザイリンクス LogicCORE IP すべてと カタログに追加されたユーザー定義の IP およびサードパーティ IP が表示されます カタログには 次の情報が含まれています IP タイプ バージョン データシート ライセンス情報 RTL デザインへの IP コアの追加 RTL デザインに IP コアを追加するには インスタンシエーションテンプレートをシステムレベルデザインに挿入します IP は ネットリストではなく RTL ソースとして作成されます 合成およびインプリメンテーションを実行すると デザインのほかの部分と共に IP が合成およびインプリメントされます IP は スタンドアロンモジュールとして合成し そのネットリストをネットリストデザインに追加することも可能です 表 1-1 : サポートされる IP ネットリストフォーマット ザイリンクス Verilog EDIF.xco.xci.ngc.v.edf Vivado ツールでサポートされる IP 中心のデザインの詳細は Vivado Design Suite ユーザーガイド : IP を使用した設計 (UG896) [ 参照 5] を参照してください インプリメンテーション japan.xilinx.com 11

インプリメンテーションでのデザイン制約の使用 インプリメンテーションでのデザイン制約の使用 インプリメンテーションを実行する際は デザイン制約を設定しておくことをお勧めします デザイン制約には 物理制約とタイミング制約の 2 種類があります このセクションには 次の内容が含まれます 物理制約 タイミング制約 UCF タイミング制約はサポートされない 制約セットにより複数の制約ファイルをデザインに適用 制約を attribute 文として追加 物理制約 物理制約は 次を定義します ピン配置 次のようなセルの絶対または相対配置 BRAM DSP LUT フリップフロップ デバイスコンフィギュレーション設定 タイミング制約 タイミング制約は業界標準の SDC で記述され デザインの周波数要件を定義します タイミング制約を設定しない場合 デザインがワイヤの長さおよび配線の密集度にのみ基づいて最適化され デザインパフォーマンスが評価されたり向上したりすることはありません UCF タイミング制約はサポートされない 重要 : Vivado Design Suite では UCF フォーマットはサポートされません UCF 制約を XDC コマンドに変換する方法については Vivado Design Suite 移行手法ガイド (UG911) [ 参照 13] を参照してください インプリメンテーション japan.xilinx.com 12

インプリメンテーションでのデザイン制約の使用 制約セットにより複数の制約ファイルをデザインに適用 制約セットは デザインに適用する制約ファイルのリストです 制約セットには XDC ファイルに記述されたデザイン制約が含まれます 制約セットの構造 次の制約セットの構造がサポートされます 複数の制約ファイルを含む制約セット 個別の物理制約ファイルおよびタイミング制約ファイルを含む制約セット マスター制約ファイル 新しい制約ファイルに制約の変更を保存 複数の制約セット ヒント : 制約を機能に応じて別の制約ファイルに分けておくと 制約ストラテジ全体がわかりやすくなり タイミングおよびインプリメンテーションを変更しやすくなります 複数の制約セット プロジェクトに複数の制約セットを作成できます 複数の制約セットを作成すると 異なるインプリメンテーション run で異なる制約を試すことができます たとえば 合成とインプリメンテーションに異なる制約セットを指定できます 合成 シミュレーション インプリメンテーションで異なる制約を適用して試すことができます デザイン制約を複数の制約セットを使用して整理すると 次のような利点があります 同じプロジェクトで異なるザイリンクス FPGA デバイスをターゲットとして設定できます ターゲットパーツが異なると 物理制約およびタイミング制約も異なるものにする必要がある場合があります さまざまな条件でデザインを実行できます 制約セットを使用して 異なるフロアプランを適用したり デザインの制約を厳しくしたりできます 制約の変更を管理しやくすなります マスター制約の代わりに 別の制約ファイルに保存した制約を使用できます ヒント : タイミング制約を検証するには 合成済みデザインで report_timing_summary コマンドを実行します インプリメンテーションの前に 問題のある制約を修正してください 配置配線に影響する制約の定義および制約での作業の詳細は Vivado Design Suite ユーザーガイド : 制約の使用 (UG903) [ 参照 7] を参照してください インプリメンテーション japan.xilinx.com 13

デザインチェックポイントでデザインのスナップショットを保存および復元 制約を attribute 文として追加 制約は HDL ソースに attribute 文として追加できます 属性は Verilog および VHDL ソースの両方に追加でき Vivado 合成または Vivado インプリメンテーションに渡すことができます RTL 属性としてのみ設定可能で XDC では設定できない制約もあります この場合 制約を HDL ソースファイルで属性として指定する必要があります たとえば 相対配置マクロ (RPM) はプロパティとして定義する必要があります RPM とは 複数のロジックエレメント (FF LUT DSP RAM など ) を 1 つのセットにまとめたものです デザインエレメントのセットを U_SET または HU_SET 制約を使用して定義し 相対ロケーション制約 (RLOC) を使用して セットのほかのエレメントに対してそれらのオブジェクトを配置できます 相対ロケーション制約の詳細は Vivado Design Suite ユーザーガイド : 制約の使用 (UG903) [ 参照 7] を参照してください U_SET HU_SET および RLOC 制約は Tcl コマンドを使用して XDC で指定することはできませんが HDL ソースファイルの属性として定義できます XDC でサポートされない制約の詳細は Vivado Design Suite 移行手法ガイド (UG911) [ 参照 13] を参照してください デザインチェックポイントでデザインのスナップショットを保存および復元 Vivado Design Suite では 物理デザインデータベースを使用して配置配線情報を格納します デザインチェックポイントファイル (.dcp) を使用すると デザインフローの主要な段階でこの物理データベースを保存および復元できます チェックポイントは フローの特定の地点におけるデザインのスナップショットです デザインチェックポイントファイルには 次のものが含まれます インプリメンテーション中に適用された最適化を含む現在のネットリスト デザイン制約 インプリメンテーション結果 チェックポイントデザインに対しては Tcl コマンドを使用してデザインフローの残りの段階を実行できます 新しいデザインソースを使用して変更することはできません チェックポイントファイルの保存 フローの任意の段階におけるデザインデータベースのスナップショットを保存するには [File] [Write Checkpoint] をクリックします これにより 拡張子が.dcp のファイルが作成されます これに相当する Tcl コマンドは write_checkpoint です チェックポイントファイルの読み込み Vivado Design Suite でチェックポイントを開くには [File] [Open Checkpoint] をクリックします デザインチェックポイントが別のプロジェクトとして開きます 既存のプロジェクトに読み込むことはできません これに相当する Tcl コマンドは read_checkpoint です インプリメンテーション japan.xilinx.com 14

非プロジェクトモードでのインプリメンテーションの実行 非プロジェクトモードでのインプリメンテーションの実行 合成済みデザインまたはネットリストをターゲットのザイリンクス FPGA デバイスにインプリメントするには ネットリストとデザイン制約に対して次のプロセスを実行する必要があります 最適化 配置 配線 これらのプロセスは まとめて インプリメンテーション と呼ばれます 非プロジェクトモードでは 複数の Tcl コマンドを順に実行するか デザインフローを定義した Tcl スクリプトを使用します Tcl コマンドは Vivado IDE の Tcl コンソールから入力するか Vivado Design Suite Tcl シェルの Tcl プロンプトから入力します 非プロジェクトモードのサンプルスクリプト 次に 非プロジェクトモードでインプリメンテーションを実行するスクリプト例を示します # Step 1: Read in top-level EDIF netlist from synthesis tool read_edif c:/top.edf # Read in lower level IP core netlists read_edif c:/core1.edf read_edif c:/core2.edf # Step 2: Specify target device and link the netlists # Merge lower level cores with top level into single design link_design -part xc7k325tfbg900-1 -top top.edf # Step 3: Read XDC constraints to specify timing requirements read_xdc c:/top_timing.xdc # Read XDC constraints that specify physical constraints such as pin locations read_xdc c:/top_physical.xdc # Step 4: Optimize the design with default settings opt_design # Step 5: Place the design place_design # Step 6:Route the design route_design # Step 7:Run Timing Summary Report to see timing results report_timing_summary -file post_route_timing.rpt # Run Utilization Report for device resource utilization report_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 API write_checkpoint post_route.dcp インプリメンテーション japan.xilinx.com 15

非プロジェクトモードでのインプリメンテーションの実行 非プロジェクトモードのサンプルスクリプトでの主要な手順 非プロジェクトモードのサンプルスクリプト では 次の手順が実行されます 手順 1 : デザインソースファイルの読み込み 手順 2 : メモリ内へのデザインの構築 手順 3 : デザイン制約の読み込み 手順 4 : ロジック最適化の実行 手順 5 : ネットリストエレメントの配置 手順 6 : デザインの配線 手順 7 : レポートの生成 手順 8 : デザインチェックポイントの保存 手順 1 : デザインソースファイルの読み込み 非プロジェクトモードのサンプルスクリプト では デザインソースは EDIF ネットリストファイルです 非プロジェクトモードでは RTL デザインフローもサポートされています その場合 ソースファイルを読み込んでインプリメンテーションの前に合成を実行します read_* Tcl コマンドは非プロジェクトモードで使用するコマンドで ディスク上のファイルを読み込んでメモリ内にデザインを構築します ファイルがコピーされたり ファイルの依存関係が作成されることはありません そのため 非プロジェクトモードは非常に柔軟です 重要 : ユーザーがソースデザインファイルの変更を管理し それに応じてデザインをアップデートする必要があります 手順 2 : メモリ内へのデザインの構築 link_design コマンドを使用してデザインのメモリ内表示を構築します このコマンドは ツールに読み込まれたネットリストベースのソースファイルをザイリンクスのデバイス情報と結合して メモリ内にデザインデータベースを作成します 非プロジェクトモードでのすべての操作は Vivado ツール内のインメモリデータベースに対して実行されます Vivado ツールをバッチモードで実行している場合でも Tcl シェルモードで対話的に Tcl コマンドを実行している場合でも グラフィカルモードでデザインデータを Vivado IDE で表示している場合でも メモリ内のデザインは Vivado ツール内に存在します 手順 3 : デザイン制約の読み込み Vivado Design Suite では デザイン制約を使用してデザインの物理特性およびタイミング特性を定義します 詳細は 12 ページの インプリメンテーションでのデザイン制約の使用 を参照してください read_xdc コマンドは XDC 制約ファイルを読み込み メモリ内のデザインに適用します ヒント : プロジェクトモードでは 異なる目的で複数の制約ファイルを含む制約セットを定義できますが 非プロジェクトモードでは 同じ操作を実行するのに複数の read_xdc コマンドを使用します インプリメンテーション japan.xilinx.com 16

非プロジェクトモードでのインプリメンテーションの実行 手順 4 : ロジック最適化の実行 配置配線の準備としてロジック最適化を実行します 最適化では ターゲットデバイスの物理リソースに配置する前にロジックデザインが簡略化されます Vivado のネットリスト最適化では デザイン要件を満たすため さまざまな最適化機能が提供されています 詳細は 59 ページの ロジック最適化 を参照してください 手順 5 : ネットリストエレメントの配置 デザインの全体的な配置を実行します デザインの階層および配置の困難さによって 配置が複数の段階で実行されることもあります 詳細は 64 ページの 配置 を参照してください 手順 6 : デザインの配線 route_design コマンドはデザインに必要な配線を完成させます Vivado 配線では すべてのデザインタイプでタイミングドリブン配線が実行されます 困難なデザインには 再配線を使用して詳細な制御が可能です 詳細は 71 ページの 配線 を参照してください 手順 7 : レポートの生成 非プロジェクトモードのサンプルスクリプト では Vivado Design Suite で提供される多数のレポートのうち 2 つを生成します 非プロジェクトモードでは 各レポートを Tcl コマンドを使用して生成する必要があります レポートはファイルに出力するか Vivado IDE に表示して確認できます 詳細は 51 ページの インプリメンテーションレポートの表示 を参照してください 手順 8 : デザインチェックポイントの保存 メモリ内のデザインをデザインチェックポイントに保存します 保存されたチェックポイントデザインには 次が含まれます 最適化されたネットリスト 物理制約およびタイミング制約 ザイリンクスパーツ情報 配置配線情報 非プロジェクトモードでは デザインチェックポイントファイルを保存することで 後でデザインを読み込んで解析したり変更したりできます 詳細は 14 ページの デザインチェックポイントでデザインのスナップショットを保存および復元 を参照してください インプリメンテーション japan.xilinx.com 17

プロジェクトモードでのインプリメンテーションの実行 プロジェクトモードでのインプリメンテーションの実行 プロジェクトモードでは 次が可能です 特定の合成結果およびデザイン制約を使用するインプリメンテーション run を定義 1 つのデザインに対して複数のストラテジを実行 デザイン要件を満たすためインプリメンテーションストラテジをカスタマイズ カスタマイズしたインプリメンテーションストラテジをほかのデザインで使用するため保存 重要 : 非プロジェクトモードでは 定義済みのインプリメンテーション run およびストラテジはサポートされません Tcl コマンドを使用して インプリメンテーションプロセスの各段階を手動で実行する必要があります 詳細は 15 ページの 非プロジェクトモードでのインプリメンテーションの実行 を参照してください インプリメンテーション run の作成 新しいインプリメンテーション run を作成して起動し 最適な結果が得られるようさまざまなオプションを試すことができます 各 run は順次起動するか 複数のローカル CPU で同時に起動できます Linux システムでは リモートサーバーで run を実行することも可能です 詳細は 付録 A リモートホストの使用 を参照してください インプリメンテーション run の定義 インプリメンテーション run を定義するには 次の手順に従います 1. 次のいずれかを実行します メインメニューから [Flow] [Create Runs] をクリックします Flow Navigator で [Implementation] を右クリックし [Create Implementation Runs] をクリックします [Design Runs] ビューを右クリックし [Create Runs] をクリックします Create New Runs ウィザードが開きます 最初のページは コマンドのサマリです 2. [Next] をクリックします 注記 : [Flow] [Create Runs] をクリックした場合 Create New Runs ウィザードの最初のページで [Implementation] をオンにします インプリメンテーション japan.xilinx.com 18

プロジェクトモードでのインプリメンテーションの実行 X-Ref Target - Figure 1-3 図 1-3 : Create New Runs ウィザード : [Configure Implementation Runs] ページ 3. [Configure Implementation Runs] ページで [Name] 列に run の名前を入力するか デフォルトのままにします 4. [Synth Name] 列で インプリメンテーションに使用する合成済みネットリストを選択します サードパーティ合成ツールからプロジェクトにインポートされた合成済みネットリストも選択できます 詳細は Vivado Design Suite ユーザーガイド : 合成 (UG901) [ 参照 6] を参照してください デフォルトは [Design Runs] ビューで現在アクティブな run です 詳細は 23 ページの [Design Runs] ビューの使用 を参照してください 5. [Constraints Set] 列で制約セットを選択します [Constraints Set] 列で インプリメンテーションに適用する制約セットを選択します 最適化 配置 および配線は 指定された制約セットの物理制約およびタイミング制約に基づいて実行されます 制約セットの詳細は Vivado Design Suite ユーザーガイド : 制約の使用 (UG903) [ 参照 7] を参照してください 6. [Part] 列でターゲットパーツを選択します デフォルトでは 制約セットおよびターゲットパーツは [Create New Runs] コマンド実行したときのプロジェクト設定に基づいて定義されます プロジェクト設定の詳細は Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] を参照してください 異なる制約セットまたはターゲットパーツを使用する run を作成するには [Create New Runs] コマンドを使用します これらの値は [Design Runs] ビューで run を選択し [Run Properties] ビューで変更できます 詳細は 24 ページの インプリメンテーション run 設定の変更 を参照してください 7. [Strategy] 列でストラテジを選択します ストラテジとは インプリメンテーション結果を制御する Vivado インプリメンテーション機能オプションを定義した設定のことです Vivado Design Suite では 定義済みのストラテジが提供されています また 独自のインプリメンテーションストラテジを作成することも可能です 詳細は 30 ページの ストラテジの定義 を参照してください 次の表に示すストラテジのいずれかを選択します ストラテジは その目的に応じてカテゴリ別に分類されており カテゴリ名が接頭辞となっています カテゴリを表 1-2 に示します インプリメンテーション japan.xilinx.com 19

プロジェクトモードでのインプリメンテーションの実行 パフォーマンスストラテジは デザインパフォーマンスを向上することを目的としており 実行時間は長くなります Performance_Explore ストラテジは すべてのタイプのデザインを網羅しているので 最初に選ぶストラテジとして適しています 重要 : 名前に SLL または SLR が含まれるストラテジは SSI デバイスでのみ使用可能です 表 1-2 : ストラテジのカテゴリ カテゴリ Performance ( パフォーマンス ) Area ( エリア ) Power ( 消費電力 ) Flow ( フロー ) Congestion ( 密集 ) 目的デザインパフォーマンスを向上します LUT 数を削減します 消費電力最適化を実行します フロー手順を変更します 密集および関連の問題を低減します 表 1-3 : インプリメンテーションストラテジ インプリメンテーションストラテジ名 Vivado Implementation Defaults Performance_Explore Performance_RefinePlacement Performance_WLBlockPlacement Performance_WLBlockPlacementFanoutOpt Performance_LateBlockPlacement Performance_NetDelay_high Performance_NetDelay_medium Performance_NetDelay_low Performance_ExploreSLLs Area_Explore Power_DefaultOpt Flow_RunPhysOpt 説明 適度な実行時間でタイミングクロージャが満たされるようにします 結果を向上するため 最適化 配置 配線に複数のアルゴリズムを使用します 配置後の最適化のエフォートを増加し 配線でのタイミングの緩和をディスエーブルにします ブロック RAM および DSP を配置する際にタイミング制約を無視し ワイヤ長を使用します ブロック RAM および DSP を配置する際にタイミング制約を無視してワイヤ長を使用し ファンアウトの大きいドライバーの複製を積極的に実行します 最終的な配置段階まで ブロック RAM と DSP におおよその配置を使用します 全体的な配置が向上することがあります 遅延を少なめに予測する代わりに 距離の長いファンアウトの大きい接続の遅延コストを増加します Performance_NetDelay_high では増加量が最も大きくなります 遅延を少なめに予測する代わりに 距離の長いファンアウトの大きい接続の遅延コストを増加します Performance_NetDelay_medium では増加量が中程度になります 遅延を少なめに予測する代わりに 距離の長いファンアウトの大きい接続の遅延コストを増加します Performance_NetDelay_low では増加量が最も小さくなります 全体的なタイミングスラックを向上するため SLR の再割り当てを試行します LUT 数を削減するため 複数の最適化アルゴリズムを使用します 消費電力を削減するため 消費電力最適化 (power_opt_design) を実行します Vivado Implementation Defaults に物理最適化 (phys_opt_design) を実行します インプリメンテーション japan.xilinx.com 20

プロジェクトモードでのインプリメンテーションの実行 表 1-3 : インプリメンテーションストラテジ ( 続き ) インプリメンテーションストラテジ名 Flow_RuntimeOptimized Flow_Quick Congestion_SpreadLogic_high Congestion_SpreadLogic_medium Congestion_SpreadLogic_low Congestion_SpreadLogicSLLs Congestion_BalanceSLLs Congestion_BalanceSLRs Congestion_CompressSLRs 説明 各インプリメンテーション段階で デザインパフォーマンスよりも実行時間を短縮することを優先します 物理最適化 (phys_opt_design) はディスエーブルになります すべての最適化およびタイミングドリブンの処理をディスエーブルにし 配置配線のみを実行します 使用率を予測する際に有益です 密集した領域が作成されないように ロジックをデバイス全体に分散します Congestion_SpreadLogic_high では分散度が最も高くなります 密集した領域が作成されないように ロジックをデバイス全体に分散します Congestion_SpreadLogic_medium では分散度が中程度になります 密集した領域が作成されないように ロジックをデバイス全体に分散します Congestion_SpreadLogic_low では分散度が最も低くなります ロジックが SLR すべてに分散され SLR 内で密集した領域が作成されないように SLL を割り当てます 2 つの SLR で偏って多数の SLL が必要とならないように SLL を割り当て SLR での密集を低減します 各 SLR のエリアが同等になるように分割し SLR 内で密集した領域が作成されないようにします SLR の使用率が高くなるように分割し 全体的な SLL 数を削減します ヒント : run を実行する前に インプリメンテーションプロセスの各段階の設定を 選択したストラテジのデフォルト設定から変更できます 変更した設定を新しいストラテジとしても保存できます 詳細は 24 ページの インプリメンテーション run 設定の変更 を参照してください 8. [More] をクリックし 追加の run を定義します 追加 run の名前とストラテジを指定します ( 図 1-3) 9. [Next] をクリックします [Launch Options] ページが開きます ( 図 1-4) インプリメンテーション japan.xilinx.com 21

プロジェクトモードでのインプリメンテーションの実行 X-Ref Target - Figure 1-4 10. [Lauch directory] を指定します 図 1-4 : [Launch Options] ページ このディレクトリに インプリメンテーション run のデータを作成して保存します デフォルトのディレクトリは ローカルのプロジェクトディレクトリ構造に含まれます デフォルトでは インプリメンテーション run のファイルは次のディレクトリに保存されます <project_name>/<project_name>.runs/<run_name> ヒント : プロジェクトファイルには絶対パスが記述されるので プロジェクトディレクトリ外の場所を指定すると プロジェクトを移動しにくくなります 11. 実行オプションを指定します [Launch Runs on Local Host] run をローカルマシンで実行します [Number of jobs] 複数の run を同時実行する際に使用するローカルプロセッサの数を指定します [Launch Runs on Remote Hosts] (Linux のみ ) - リモートホストを使用してジョブを実行します - 詳細は 付録 A リモートホストの使用 を参照してください [Configure Hosts] リモートホストを設定します [Generate scripts only] run ディレクトリおよび run スクリプトをエクスポートおよび作成しますが run は実行しません スクリプトは Vivado IDE ツールの環境外で後で実行できます [Do not launch now] 新しい run を保存しますが run を実行または run スクリプトは作成しません インプリメンテーション japan.xilinx.com 22

プロジェクトモードでのインプリメンテーションの実行 12. [Next] をクリックし [Create New Runs Summary] ページを確認します 13. [Finish] をクリックします 定義した run が作成され 指定の実行オプションが実行されます 新しい run が [Design Runs] ビューに追加されます [Design Runs] ビューの使用 [Design Runs] ビューには プロジェクトで作成された合成 run とインプリメンテーション run のすべてが表示され それらを設定 管理 実行するためのコマンドを実行できます [Design Runs] ビューを開く [Design Runs] ビューが表示されていない場合は [Window] [Design Runs] をクリックして表示します ( 図 1-5) [Design Runs] ビューの機能 インプリメンテーション run は 合成 run の下の階層にインデントされて表示されます 1 つの合成 run に 複数のインプリメンテーション run を含めることができます プラス記号 (+) やマイナス記号 (-) をクリックすると 合成 run のツリー表示を展開したり 閉じたりできます [Design Runs] ビューは ツリー形式の表で示されます このビューのデータを列を使用して並べ替える方法は Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] を参照してください X-Ref Target - Figure 1-5 図 1-5 : [Design Runs] ビュー run のステータス [Design Runs] ビューには run のステータスが表示されます 次のステータスがあります 実行されていない 実行中 完了 最新の状態でない run のタイミング結果 [Design Runs] ビューには インプリメンテーション run のタイミング結果 (WNS TNS WHS THS TPWS およびタイミングが満たされていないネット数 ) が表示されます インプリメンテーション japan.xilinx.com 23

プロジェクトモードでのインプリメンテーションの実行 最新の状態でない run ソースファイル 制約 またはプロジェクト設定を変更すると run は最新の状態ではなくなります [Design Runs] ビューでは run をリセットしたり 古い run のデータを削除したりできます アクティブ run Vivado IDE のすべてのビューには アクティブな run の情報が表示されます [Log] ビュー [Reports] ビュー ステータスバー [Project Summary] ビューには アクティブな run の情報が表示されます [Project Summary] ビューには アクティブな run のコンパイル リソース およびサマリ情報が表示されます ヒント : Vivado IDE でアクティブにできるのは 1 つの合成 run と 1 つのインプリメンテーション run のみです アクティブな run は [Design Runs] ビューに太字で示されます run をアクティブにするには 次の手順に従います 1. [Design Runs] ビューで 1 つの run を右クリックします 2. [Make Active] をクリックします インプリメンテーション run 設定の変更 [Design Runs] ビューで run を選択すると [Run Properties] ビューにその run の現在の設定が表示されます ( 図 1-6) [Run Properties] ビューでは 次のオプションを変更できます [Name] : run の名前 [Part] : ターゲットパーツ [Description] : run の説明 [Constraints] : インプリメンテーションで使用し 新しい制約を保存する制約セット [Run Properties] ビューの詳細は Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] を参照してください X-Ref Target - Figure 1-6 図 1-6 : [Implementation Run Properties] ビュー Vivado インプリメンテーション機能で使用されるオプションも変更できます インプリメンテーション japan.xilinx.com 24

プロジェクトモードでのインプリメンテーションの実行 デザイン run の設定 デザイン run の設定を変更するには [Design Run Settings] ダイアログボックスを使用します [Design Run Settings] ダイアログボックスを開くには 次の手順に従います 1. [Design Runs] ビューで 1 つの run を右クリックします 2. [Change Run Settings] をクリックします 図 1-7 を参照してください ヒント : 設定の変更は run のステータスが Not started の場合にのみ可能です run を右クリックして [Reset Runs] をクリックすると run のステータスを Not started に戻すことができます 詳細は 27 ページの run のリセット を参照してください X-Ref Target - Figure 1-7 [Design Run Settings] ダイアログボックスには run に適用されているインプリメンテーションストラテジ インプリメンテーションプロセスの各段階でそのストラテジに関連するコマンドオプションが表示されます 次のオプションがあります [Strategy] [Description] [Options] [Strategy] インプリメンテーション run に適用するストラテジを選択します Vivado Design Suite では 定義済みのストラテジが提供されています また 独自のインプリメンテーションストラテジを作成することも可能です 詳細は 30 ページの ストラテジの定義 を参照してください [Description] 図 1-7 : [Design Run Settings] ダイアログボックス 選択したインプリメンテーションストラテジの説明を表示します インプリメンテーション japan.xilinx.com 25

プロジェクトモードでのインプリメンテーションの実行 [Options] Vivado インプリメンテーションプロセスの各段階のコマンドラインオプションを表示します 次のコマンドのオプションが表形式で表示されます opt_design power_opt_design place_design phys_opt_design route_design write_bitstream 特定のコマンドオプションをクリックすると その説明がダイアログボックスの下部に表示されます 各インプリメンテーション段階の詳細と設定可能なオプションは 第 2 章 インプリメンテーションコマンド を参照してください コマンドオプションの変更 コマンドオプションを変更するには そのコマンドオプションの右側の列をクリックします 次の操作を実行します 定義済みの値から選択するオプションは ドロップダウンリストから選択します イネーブル / ディスエーブルにするオプションは チェックボックスのオン / オフを切り替えます ユーザー定義の値を指定できるオプションは 値を入力します ファイル名およびパスを指定するオプションは ファイルを選択するダイアログボックスが開き ファイルを選択できます フックスクリプトと呼ばれるカスタム Tcl スクリプトをインプリメンテーションの各段階の前 (tcl.pre) と後 (tcl.post) に挿入します フックスクリプトを挿入すると インプリメンテーションの各段階の前後に特定のタスクを実行できます たとえば デザインの配置前後にタイミングレポートを生成して タイミング結果を比較できます Tcl フックスクリプトの定義方法の詳細は Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用 (UG894) [ 参照 3] を参照してください ヒント : tcl.pre および tcl.post スクリプト内のパスは プロジェクトの関連する run ディレクトリ <project>/<project.runs>/<run_name> を基準とします 現在のプロジェクトまたは現在の run の DIRECTORY プロパティを使用して Tcl スクリプト内の相対パスを定義できます get_property DIRECTORY [current_project] get_property DIRECTORY [current_run] [Save Design As] [Strategy] フィールドの右側にある [Save Design As] ボタンをクリックすると 今後使用できるように ストラテジへの変更を新しいストラテジとして保存できます 注意 : [Save Design As] を使用しない場合 変更は現在のインプリメンテーション run には保存されますが 今後使用することはできません インプリメンテーション japan.xilinx.com 26

プロジェクトモードでのインプリメンテーションの実行 run ステータスの確認 Vivado IDE では run のステータスによって run を処理してインプリメンテーションを開始します ステータスは [Design Runs] ビューに表示されます ( 図 1-5) run のステータスが Not Started の場合 run はすぐに開始されます run のステータスが Error になっている場合は まず run がリセットされ 終了していない run データが削除されてから run が再開されます run のステータスが Complete または Out-of-Date になっている場合は run をリセットするかどうか確認するメッセージが表示されます run のリセット run をリセットするには 次の手順に従います 1. [Design Runs] ビューで 1 つの run を右クリックします 2. [Reset Runs] をクリックします インプリメンテーション run をリセットすると インプリメンテーションの最初の段階 (opt_design) に戻ります X-Ref Target - Figure 1-8 図 1-8 : [Reset Runs] ダイアログボックス run のリセットを確認するメッセージと run ディレクトリから生成されたファイルを削除するオプションが表示されます ヒント : デフォルトでは 生成されたファイルは削除されます 生成された run ファイルを削除しない場合は このオプションをオフにします run の削除 [Design Runs] ビューから run を削除するには 次の手順に従います 1. run を右クリックします 2. [Delete] をクリックします run の削除を確認するメッセージと run ディレクトリから生成されたファイルを削除するオプションが表示されます ヒント : デフォルトでは 生成されたファイルは削除されます 生成された run ファイルを削除しない場合は このオプションをオフにします インプリメンテーション japan.xilinx.com 27

インプリメンテーションストラテジのカスタマイズ X-Ref Target - Figure 1-9 図 1-9 : [Delete Runs] ダイアログボックス インプリメンテーションストラテジのカスタマイズ 新しいインプリメンテーション run を定義すると デフォルトのインプリメンテーション設定が使用されます これらの設定は変更できます 図 1-10 に [Project Settings] ダイアログボックスの [Implementation] ページを示します このダイアログボックスは メインメニューから [Tools] [Project Settings] をクリックすると開きます ヒント : 非プロジェクトモードを使用している場合は [Project Settings] コマンドは使用できません インプリメンテーションストラテジをバッチモードで使用可能な Tcl スクリプトとして定義して保存するか Vivado IDE で対話的に定義します Flow Navigator からアクティブなインプリメンテーション run のインプリメンテーション設定にアクセス アクティブなインプリメンテーション run のインプリメンテーション設定は Flow Navigator で [Implemented Settings] をクリックしても開くことができます 次のインプリメンテーション設定を指定できます [Default constraint set] インプリメンテーション run でデフォルトで使用する制約セットを選択します [Strategy] インプリメンテーション run に適用するストラテジを選択します Vivado Design Suite では 定義済みのストラテジが提供されています また 独自のインプリメンテーションストラテジを作成することも可能です 詳細は ストラテジの定義 を参照してください [Save Design As] ストラテジへの変更を今後使用できるように新しいストラテジとして保存します [Description] 選択したインプリメンテーションストラテジの説明を表示します ユーザー定義のストラテジの説明は 新しい説明を入力して変更できます Vivado ツールの標準インプリメンテーションストラテジの説明は変更できません インプリメンテーション japan.xilinx.com 28

インプリメンテーションストラテジのカスタマイズ X-Ref Target - Figure 1-10 図 1-10 : [Project Settings] ダイアログボックスの [Implementation] ページ インプリメンテーション japan.xilinx.com 29

インプリメンテーションストラテジのカスタマイズ ストラテジの定義 ストラテジは デザインの合成またはインプリメンテーションで最適な結果が得られるようにするために定義されたソリューションです Vivado インプリメンテーション機能のあらかじめ設定されたオプションにより定義されます ストラテジは ツールおよびバージョン特定です Vivado Design Suite の各メジャーリリースには バージョン特定のストラテジが含まれます X-Ref Target - Figure 1-11 図 1-11 : デフォルトのインプリメンテーションストラテジ Vivado インプリメンテーションには 内部ベンチマークでテストされた一般的なストラテジが複数含まれています ヒント : 定義済みのインプリメンテーションストラテジに変更を保存することはできませんが 定義済みのストラテジをコピーして変更し カスタムストラテジとして保存できます インプリメンテーション japan.xilinx.com 30

インプリメンテーションストラテジのカスタマイズ 定義済みストラテジへのアクセス 定義済みストラテジにアクセスするには メインメニューから [Tools] [Options] をクリックし 左側のペインで [Strategies] をクリックします 図 1-11 に Vivado ツールに含まれるデフォルトのストラテジを示します ストラテジの確認 コピー 変更 ストラテジを確認 コピー 変更するには 次の手順に従います 1. [Tools] [Options] をクリックします 2. 左側のペインで [Strategies] をクリックします [Vivado Options] ダイアログボックスの [Strategies] ページに 各ツールとリリースバージョン用に定義済みのストラテジがリストされます ( 図 1-11) 3. [Flow] ドロップダウンリストで 適切なバージョンの [Vivado Implementation] を選択します 含まれているスト ラテジが表示されます 4. 新しいストラテジを作成するには ツールバーまたはポップアップメニューから [Create New Strategy] を クリックします 5. 既存のストラテジをコピーするには ツールバーまたはポップアップメニューから [Create a Copy of this Strategy] をクリックします 次の操作が実行されます a. 選択しているストラテジのコピーが作成されます b. [User Defined Strategies] リストに追加されます c. ダイアログボックスの右側にストラテジのオプションが表示され 変更できるようになります 6. 新しいストラテジに対して次の情報を入力します [Name] ストラテジの名前を入力します [Type] [Synthesize] または [Implement] を選択します [Tool version] ツールバージョンを指定します [Description] ストラテジの説明を入力します ここで入力した説明が [Design Run] ビューの結果の表に表示されます X-Ref Target - Figure 1-12 図 1-12 : [New Strategy] ダイアログボックス インプリメンテーション japan.xilinx.com 31

インプリメンテーションストラテジのカスタマイズ 7. 次のインプリメンテーション手順のオプションを変更します opt_design power_opt_design place_design phys_opt_design route_design write_bitstream ヒント : 特定のコマンドオプションを選択すると その説明がダイアログボックスの下部に表示されます 各インプリメンテーション段階の詳細と設定可能なオプションは 第 2 章 インプリメンテーションコマンド を参照してください X-Ref Target - Figure 1-13 8. コマンドオプションの右側をクリックして コマンドオプションを変更します ( 図 1-13) 次の操作を実行します 図 1-13 : インプリメンテーションオプションの変更 定義済みの値から選択するオプションは ドロップダウンリストから選択します イネーブル / ディスエーブルにするオプションは チェックボックスのオン / オフを切り替えます テキスト入力フィールドのオプションは 値を入力します ファイル名およびパスを指定するオプションは ダイアログボックスでファイルを選択します フックスクリプトと呼ばれるカスタム Tcl スクリプトをインプリメンテーションの各段階の前 (tcl.pre) と後 (tcl.post) に挿入します フックスクリプトを挿入すると インプリメンテーションの各段階の前後に特定のタスクを実行できます たとえば デザインの配置前後にタイミングレポートを生成して タイミング結果を比較できます Tcl フックスクリプトの定義方法の詳細は Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用 (UG894) [ 参照 3] を参照してください 注記 : tcl.pre および tcl.post スクリプト内のパスは プロジェクトの関連する run ディレクトリ <project>/<project.runs>/<run_name> を基準とします 現在のプロジェクトまたは現在の run の DIRECTORY プロパティを使用して スクリプト内の相対パスを定義できます get_property DIRECTORY [current_project] get_property DIRECTORY [current_run] インプリメンテーション japan.xilinx.com 32

インプリメンテーション run の起動 9. [OK] をクリックして新しいストラテジを保存します 新しいストラテジは [User Defined Strategies] の下にリストされます ユーザー定義のストラテジは 次の場所に保存されます Linux OS $HOME/.Xilinx/Vivado/strategies Windows 7 C:\Users\<username>\AppData\Roaming\Xilinx\Vivado\strategies Windows XP C:\Documents and Settings\username\Application Data\Xilinx\Vivado\strategies ストラテジの共有 作成したストラテジを複数のユーザーで共有するには ユーザー定義のストラテジを <InstallDir>/Vivado/<version>/strategies ディレクトリにコピーします 説明 : <InstallDir> : ザイリンクスソフトウェアのインストールディレクトリ <version> : リリースバージョン番号 インプリメンテーション run の起動 アクティブインプリメンテーション run を実行するには 次のいずれかを実行します Flow Navigator で [Run Implementation] をクリックします [Flow] [Run Implementation] をクリックします ツールバーの [Run Implementation] ボタンをクリックします [Design Runs] ビューで run を右クリックし ポップアップメニューから [Launch Runs] をクリックします 1 つのインプリメンテーション run を実行すると そのインプリメンテーションに別のプロセスが生成されます ヒント : [Design Runs] ビューからは アクティブでない run を選択して実行できます [Design Runs] ビューで複数の run を選択すると 複数の run を同時に実行できます 1. 複数の run を選択するには Shift キーまたは Ctrl キーを押しながらクリックします 注記 : [Design Runs] ビューで複数 run を選択する際 合成 run とインプリメンテーション run の両方を選択できます Vivado IDE では run の依存性が管理され run が正しい順序で実行されます 2. [Launch Runs] をクリックすると [Launch Selected Runs] ダイアログボックスが開きます ( 図 1-14) 注記 : [Launch Selected Runs] ダイアログボックスは run を右クリックして [Launch Runs] をクリックするか [Design Runs] ビューのツールバーの [Launch Selected Runs] ボタンをクリックすると開きます インプリメンテーション japan.xilinx.com 33

インプリメンテーション run の起動 X-Ref Target - Figure 1-14 3. [Launch Directory] を選択します 図 1-14 : [Launch Selected Runs] ダイアログボックス デフォルトの実行ディレクトリは ローカルのプロジェクトディレクトリ構造に含まれます インプリメンテーション run のファイルは 次のディレクトリに保存されます <project_name>/<project_name>.runs/<run_name> ヒント : プロジェクトファイルには絶対パスが記述されるので プロジェクトディレクトリ外の場所を指定すると プロジェクトを移動しにくくなります 4. 次のオプションを設定します a. [Launch Runs on Local Host] run をローカルマシンで実行します b. [Number of jobs] 複数の run を同時実行する際に使用するローカルプロセッサの数を指定します 各 run が各プロセッサで実行されます c. [Launch Runs on Remote Hosts] (Linux のみ ) リモートホストを使用してジョブを実行します 詳細は 付録 A リモートホストの使用 を参照してください d. [Configure Hosts] リモートホストを設定します e. [Generate scripts only] run ディレクトリおよび run スクリプトをエクスポートおよび作成しますが run は実行しません スクリプトは Vivado ツールの環境外で後で実行できます インプリメンテーション japan.xilinx.com 34

プロセスのバックグラウンドへの移動 プロセスのバックグラウンドへの移動 Vivado IDE で合成またはインプリメンテーションを実行するプロセスが生成されると まず実行の準備としてデザインファイルと制約ファイルが読み込まれます [Starting Run] ダイアログボックス ( 図 1-15) が表示され このプロセスをバックグラウンドに移動するオプションが示されます このプロセスをバックグラウンドに移動すると バックグラウンドタスクを実行させたまま Vivado IDE でレポートを表示したり デザインファイルを開いたりといった別の操作を実行できます この間 前の run の結果を確認したり レポートを表示したりして 時間を効率的に活用できます 注意 : このプロセスをバックグランドに移動しても [Tcl Console] はブロックされるので Tcl コマンドを使用したり 開いている別のデザインに切り替えるなどの Tcl コマンドを必要とするタスクは実行できません X-Ref Target - Figure 1-15 図 1-15 : [Starting Run] ダイアログボックス インプリメンテーションの段階ごとの実行 Vivado インプリメンテーションは 次のような複数のプロセスで構成されます ロジック最適化 配置 配線 Vivado ツールでは インプリメンテーションを 1 つのプロセスとしてではなく 1 つずつ順に実行することも可能です インプリメンテーションの段階ごとに実行する方法 インプリメンテーションの段階ごとに実行するには 次の手順に従います 1. [Design Runs] ビューで 1 つの run を右クリックします 2. [Launch Next Step: <Step>] または [Launch Step To] をクリックします <Step> に有効な値は run 設定でイネーブルになっているプロセスによって異なります インプリメンテーション run で有効な手順は 次のとおりです opt_design ( デザインの最適化 ) ザイリンクス FPGA デバイスにフィットするよう論理デザインを最適化します power_opt_design ( デザインの消費電力最適化 ) インプリメント済み FPGA デバイスの消費電力を削減するため デザインエレメントを最適化します place_design ( デザインの配置 ) デザインをターゲットザイリンクスデバイスに配置します インプリメンテーション japan.xilinx.com 35

インプリメンテーション run の監視 phys_opt_design ( デザインの物理最適化 ) デザインの負のスラックパスに対してタイミングドリブンの最適化を実行します route_design ( デザインの配線 ) デザインをターゲットザイリンクスデバイスに配線します write_bitstream ( ビットストリームの生成 ) ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します ビットストリーム生成は 厳密にはインプリメンテーション run の一部ではありませんが 次の段階として実行可能です 3. [Launch Next Step: <Step>] または [Launch Step To] を繰り返し インプリメンテーションの段階を進めていきます インプリメンテーション段階の間で必要に応じてレポート生成または解析を実行し デザインオプションの結果を確認できます 4. 完了している段階を前の段階に戻すには [Design Runs] ビューで run を右クリックして [Reset to Previous Step: <Step>] をクリックします 選択した run を直前の段階にリセットするには [Reset to Previous Step] を使用します このコマンドを使用すると 次が可能になります run を元に戻します 必要な変更を加えます 再び段階を進め run をインクリメンタルに完了します インプリメンテーション run の監視 インプリメンテーション run は 次のように監視できます コンパイル情報を読む [Messages] ビューで警告およびエラーを確認 プロジェクトサマリを表示 [Design Runs] ビューを開く合成 run およびインプリメンテーション run のステータスは [Log] ビューで確認します インプリメンテーション japan.xilinx.com 36

インプリメンテーション run の監視 run ステータス表示 進行中の run のステータスは 2 つの方法で表示されます これらのステータス表示には run が進行中であることが示されるほか ここから必要に応じてキャンセルできます ( 図 1-16) X-Ref Target - Figure 1-16 Vivado IDE の右上にあるプロジェクトステータスバーに表示される run ステータスインジケーターでは run が進行中であることが動くバーで示されます [Cancel] ボタンをクリックすると run を停止できます [Design Runs] ビューには 図 1-16 に示すように run の横に run が進行中であることを示す円形の矢印が表示されます run を右クリックしてポップアップメニューから [Reset Run] をクリックすると run をキャンセルできます run のキャンセル / リセット 図 1-16 : インプリメンテーション run のステータス表示 進行中の run を [Cancel] ボタンまたは [Reset Run] コマンドでキャンセルすると キャンセルした run 用に作成された run ファイルをすべて削除するかどうか確認するメッセージが表示されます ( 図 1-17) X-Ref Target - Figure 1-17 図 1-17 : [Cancel Implementation] ダイアログボックス [Delete Generated Files] をオンにすると ローカルのプロジェクトディレクトリから run データが削除されます 推奨 : キャンセルした run で作成されたデータはすべて削除して 今後の run で問題が発生しないようにすることをお勧めします インプリメンテーション japan.xilinx.com 37

インプリメンテーション run の監視 [Log] ビューのログ情報の表示 run を実行すると [Log] ビューが開き 標準出力メッセージが表示されます [Log] ビューには place_design や route_design などの各インプリメンテーションプロセスの進行状況も表示されます 異なるメッセージがどこから表示されているかを確認し インプリメンテーション run のデバッグに役立てることができます 図 1-18 に [Log] ビューの例を示します ヒント : [Log] ビューで異なるメッセージがどこから表示されているかを確認し インプリメンテーション run のデバッグに役立てることができます X-Ref Target - Figure 1-18 図 1-18 : [Log] ビュー 出力の停止 [Log] ビューで [Pause output] ボタンをクリックすると 出力を停止できます 出力を停止すると インプリメンテーションの実行中にログ情報を読むことができます プロジェクトステータスの表示 Vivado IDE では プロジェクトステータスと次の手順が複数の方法で示されます プロジェクトステータスには 主なデザインタスクの結果のみがレポートされます プロジェクトステータスは [Project Summary] ビューとステータスバーに表示され プロジェクトを開いたとき デザインフローコマンドを実行中に プロジェクトのステータスをすばやく判断できます 次のステータスが示されます RTL エラボレーション 合成 インプリメンテーション ビットストリーム生成 プロジェクトステータスバー プロジェクトステータスは Vivado IDE の右上のプロジェクトステータスバーに表示されます 合成 インプリメント ビットストリームの生成を実行すると プロジェクトステータスバーにその結果が示されます プロセスでエラーが発生した場合は 赤色の文字で表示されます インプリメンテーション japan.xilinx.com 38

インプリメンテーション run の監視 Out-of-Date ステータス 合成またはインプリメンテーションを完了した状態でソースファイルまたはデザイン制約を変更すると プロジェクトステータスが Out-of-Date となります ( 図 1-19) これは プロジェクトが最新でなく 更新が必要であることを示します デザインのどの部分が最新ではないのかを確認するには [more info] リンクをクリックします インプリメンテーションのみの再実行が必要な場合や 合成およびインプリメンテーションの両方を再実行する必要がある場合があります X-Ref Target - Figure 1-19 図 1-19 : インプリメンテーションが最新でない run のステータスを強制的に最新の状態に設定 [Force-up-to-date] リンクをクリックすると インプリメンテーション run または合成 run のステータスを強制的に最新の状態にすることができます この機能は デザインまたは制約を変更したが 現在の run の結果を解析する場合などに使用します ヒント : [Force-up-to-date] コマンドは [Design Runs] ビューで最新でない run を右クリックしたときに表示されるポップアップメニューにもあります 詳細は Vivado Design Suite ユーザーガイド : Vivado IDE の使用 (UG893) [ 参照 2] を参照してください インプリメンテーション japan.xilinx.com 39

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 インクリメンタルコンパイルは 完成に近づいており タイミングクロージャを達成するために労力が必要なデザインに適したアドバンスフローです 多少の変更を加えて再合成する場合にこのフローを使用すると 基準デザインからの配置配線が再利用され 配置配線の実行時間が短縮され タイミングが保持されます このフローは 変更されたデザインと基準デザインが 95% 以上類似している場合に最も効果的です 注記 : 変更された部分のみが配置配線されます インクリメンタルコンパイルフロー X-Ref Target - Figure 1-20 図 1-20 : インクリメンタルコンパイルフロー インプリメンテーション japan.xilinx.com 40

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 インクリメンタルコンパイルフローのデザイン インクリメンタルコンパイルフローでは 次の 2 つのデザインを使用します 基準デザイン 現在のデザイン 図 1-20 を参照してください 基準デザイン 最初のインクリメンタルコンパイルフローデザインは基準デザインです 基準デザインは 通常はデザインの合成 配置 配線が完了した以前のバージョンです 基準デザインには タイミングクロージャを達成するためにコード変更 フロアプラン 制約変更した際のデザインの反復実行結果であるデザインチェックポイント (DCP) を使用できます 現在のデザインを読み込んだら read_checkpoint -incremental <dcp> コマンドを使用して基準デザインチェックポイントを読み込みます -incremental オプションを使用して基準デザインチェックポイントを読み込むと 次の配置配線でインクリメンタルコンパイルデザインフローがイネーブルになります 詳細は 42 ページの 基準デザインと現在のデザインの類似性の確認 を参照してください 現在のデザイン 2 つ目のインクリメンタルコンパイルフローデザインは現在のデザインです 現在のデザインは 基準デザインに少しだけ変更を加えたものです 次のような変更が含まれます RTL の変更 ネットリストの変更 RTL の変更とネットリストの変更の両方 インクリメンタル配置配線の実行 変更された現在のデザインを最初にメモリに読み込み その後基準デザインチェックポイントを読み込みます インクリメンタルコンパイルプロセスの重要な要素は インクリメンタル配置配線です 基準デザインチェックポイントは ネットリスト 制約 配置配線を含む物理データで構成されます 現在のデザインのネットリストは基準デザインと比較され 一致するセルおよびネットが検出されます 基準デザインチェックポイントからの配置は 現在のデザインの一致セルを配置するために再利用されます 基準デザインチェックポイントからの配線は 一致ネットを配線するために再利用されます 複数のファンアウトがあるネット Vivado 配線では 複数のファンアウトがあるネットに対しては詳細な一致比較が実行され 各配線セグメントを適切に再利用または廃棄できます 基準デザインと現在のデザインの間で一致しないデザインオブジェクトは インクリメンタル配置が完了した後に配置され 既存の配線が再利用された後に配線されます インプリメンテーション japan.xilinx.com 41

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 配置配線の効率的な再利用 基準デザインからの配置配線が効果的に再利用できるかどうかは 2 つのデザインの差異によります 少しの変更によって デザインが大幅に変わってしまう場合もあります 少しの RTL の変更による影響 合成はネットリスト名ができるだけ変更されないように実行されますが 次のような少しの RTL の変更によってデザインが大幅に変わってしまう場合があります 推論されるメモリのサイズを大きくする 内部バスの幅を広くする データ型を符号なしから符号付きに変える 制約および合成オプションの変更による影響 同様に 次のような制約および合成オプションの変更が インクリメンタル配置配線に大きく影響することがあります タイミング制約の変更および再合成 論理階層の保持または解除 レジスタのリタイミングのイネーブル 基準デザインと現在のデザインの類似性の確認 report_incremental_reuse コマンドを使用すると 基準デザインチェックポイントと現在のデザインの類似性をレポートできます このコマンドは 基準デザインチェックポイントからのネットリストをメモリ内の現在のデザインと比較し セル ネット ポートの一致量をパーセントでレポートします 注記 : 以前のバージョンの Vivado に含まれていた report_design_similarity コマンドが 現在のバージョンで report_incremental_reuse コマンドに置き換えられています 新しい report_incremental_reuse コマンドでは report_design_similarity コマンドとは異なり 引数は指定しません その代わり このコマンドを実行する前に read_checkpoint -incremental <dcp> を実行してデザインチェックポイントを指定する必要があります その後であれば いつでも report_incremental_reuse を実行できます メモリ内にあるデザインと read_checkpoint -incremental で読み込まれたデザインチェックポイントが自動的に比較されます デザイン間の差異が少ないほど 基準デザインからの配置配線の再利用が効率的に実行されます 次に メモリ内の合成済みデザインを配線済みデザインチェックポイントと比較した report_incremental_reuse レポートの例を示します +-----------------------+-------+-------+------------+ Type Count Total Percentage +-----------------------+-------+-------+------------+ Reused Cells 3591 3821 93.98 Reused Ports 71 71 100.00 Reused Nets 6142 6564 93.57 Reused Cells 3591 Non-Reused Cells 230 New 230 Fully reused nets 5383 Partially reused nets 759 New nets 422 +-----------------------+-------+-------+------------+ 通常 一致パーセントが高いほど 配置配線が多く再利用され 配置配線の実行が高速になります インプリメンテーション japan.xilinx.com 42

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 推奨 : report_incremental_reuse コマンドは 現在のデザインのインクリメンタル配置配線を実行するのに チェックポイントが基準デザインとして使用するのに適しているかを判断するのに使用します インクリメンタル配置配線メトリック デザイン間でセル ネット ポートが 95% 以上一致していれば Vivado Design Suite のインクリメンタル配置配線により実行時間が平均で通常の配置配線の 1/3 になります 基準デザインと現在のデザインの間の一致パーセントが低くなると実行時間の短縮度も低くなります 80% 未満になると インクリメンタル配置配線を使用する利点はそれほどなくなるか まったくなくなる可能性があります 実行時間の短縮に影響する要素 ほかに 次の要素も実行時間の短縮に影響します タイミングクリティカルエリアの変更量 クリティカルパスの配置配線を再利用できない場合 タイミングを満たすのにエフォートがより必要となります つまり インクリメンタル配置配線を実行する利点が デザインの単純な部分のみに使用されることになります phys_opt_design コマンドはタイミングドリブンのロジック変換を実行しますが インクリメンタルフローと標準フローでは異なる結果を生成することがあります デザインの変更が phys_opt_design の影響を受けるクリティカルタイミングエリアに集中している場合 配線の再利用により予測される効果が得られない可能性があります 配置配線の初期化時間 配置配線時間が短い場合 Vivado 配置配線の初期化のオーバーヘッドによりインクリメンタル配置配線プロセスの効果が相殺されてしまう可能性があります 実行時間が長いデザインでは 実行時間占める初期化時間の割合は小さくなります インクリメンタルコンパイルの使用 プロジェクトモードと非プロジェクトモードのどちらでも read_checkpoint -incremental <dcp_file> コマンド (<dcp_file> は基準デザインチェックポイントのパスとファイル名 ) を使用して基準デザインチェックポイントを読み込むと インクリメンタル配置配線モードになります -incremental オプションを使用して基準デザインチェックポイントを読み込むと 次の配置配線でインクリメンタルコンパイルデザインフローがイネーブルになります 非プロジェクトモードでは read_checkpoint -incremental は opt_design の後 place_design の前に実行します インクリメンタルコンパイルモードを終了するには 次のいずれかを実行します -incremental オプションを使用せずにチェックポイントを読み込みます プロジェクトを使用している場合は インクリメンタルコンパイルチェックポイントの設定を削除します 基準デザインとして使用するデザインチェックポイントファイル (DCP) を指定してインクリメンタル配置を実行するには 次の手順に従います 1. 現在のデザインを読み込みます 2. opt_design を実行します 3. read_checkpoint -incremental <dcp_file> を実行します 4. place_design を実行します link_design; # to load the current design opt_design read_checkpoint -incremental <dcp_file> place_design インプリメンテーション japan.xilinx.com 43

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 インクリメンタル配置は 基準デザインのデザインオブジェクトと現在のデザインのデザインオブジェクトを比較する Vivado ツールの機能を利用します opt_design -resynth_area コマンドオプションを使用した場合 または -directive ExploreArea を使用した場合は 基準デザインと現在のデザインの間でセル名の一致が低くなり 配置配線データとの一致も低くなります 推奨 : そのため インクリメンタルコンパイルフローを実行する際は opt_design -resynth_area コマンドの使用は制限してください read_checkpoint -incremental <dcp_file> コマンドで基準デザインとして使用するデザインチェックポイントファイル (DCP) を指定した後 route_design を実行すると インクリメンタル配線が実行されます インクリメンタルチェックポイントが place_design で既に読み込まれている場合は Vivado はインクリメンタルモードのままであり route_design の前に -incremental は必要ありませんん 配線では チェックポイントが読み込まれると 基準デザインからの配線接続が適用されます 余った配線セグメント 現在のデザインから削除されていたり 配置時に移動されているセルのため 基準デザインからの配線セグメントに余るものが出てしまうことがあります 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. プロジェクトモードでのインクリメンタルコンパイルの使用 プロジェクトモードでは [Design Runs] ビューでインクリメンタルコンパイルオプションを設定できます インクリメンタルコンパイルモードを設定するには 次の手順に従います 1. [Design Runs] ビューで 1 つの run を右クリックします 2. [Set Incremental Compile] をクリックします 3. [Set Incremental Compile] ダイアログボックスで 基準デザインチェックポイントを選択します run でインクリメンタルコンパイルモードがイネーブルになります 重要 : デザイン run からチェックポイントを選択した場合 その run がリセットされると削除されます デザイン run からチェックポイントを選択する場合は 基準チェックポイントとして選択する前に 別のディレクトリにコピーしてください インプリメンテーション japan.xilinx.com 44

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 図 1-21 を参照してください X-Ref Target - Figure 1-21 図 1-21 : デザイン run の [Set Incremental Compile] コマンド run のインクリメンタルコンパイルモードをディスエーブルにするには [Use checkpoint] フィールドを空白にします ( 図 1-22) X-Ref Target - Figure 1-22 図 1-22 : インクリメンタルコンパイルの設定 インクリメンタル配置配置配線が完了したら Vivado ツールで生成されたメッセージを確認できます インプリメンテーション japan.xilinx.com 45

インクリメンタルコンパイルを使用した配置配線の実行時間の短縮 インクリメンタルコンパイル後の解析 インクリメンタル配置配線が完了したら タイミングとセルおよびネットの再利用に関する詳細を解析できます タイミングレポートのオブジェクトに 物理データがどのように再利用されたかが示されます これにより デザインのアップデートがクリティカルパスに影響しているかどうかを判断できます タイミングレポートにインクリメンタルフローの詳細を表示するには report_timing -label_reused オプションを使用します このオプションを使用すると 入力ピンおよび出力ピンに再利用ラベルが表示され ピンのセルおよびネットに再利用された物理データの量が示されます (R) : セル配置とネット配線の両方が再利用されています (NR) : セル配置とネット配線のどちらも再利用されていません (PNR) : セル配置は再利用されていますが ネット配線は再利用されていません (N) : ピン セル またはネットは新しいデザインオブジェクトで 基準デザインには含まれません 次に例を示します ------------------------------------------------------- ------------------- (NR)SLICE_X46Y42 FDRE (Prop_fdre_C_Q) 0.259-1.862 r ffti/fifosel_reg[5]/q net (fo=8, estimated) 0.479-1.383 ffti/n_fifosel_reg[5] (R)SLICE_X46Y43 r ffti/wbdout_reg[31]i5/i1 (R)SLICE_X46Y43 LUT4 (Prop_lut4_I1_O) 0.043-1.340 r ffti/wbdout_reg[31]i5/o net (fo=32, routed) 1.325-0.014 ffti/wbdout_reg[31]i5 (R)SLICE_X44Y39 r ffti/wbci/wbdout_reg[0]i1/s (PNR)SLICE_X44Y39 MUXF7 (Prop_muxf7_S_O) 0.154 0.140 r ffti/wbci/wbdout_reg[0]i1/o net (fo=1, routed) 0.000 0.140 ffti/wbci/wbdout_reg[0]i1 (PNR)SLICE_X44Y39 r ffti/wbdout_reg[0]/d ------------------------------------------------------- ------------------- read_checkpoint -incremental コマンドにより次の 2 つのセルプロパティが設定され スクリプトまたは Tcl コマンドを使用してインクリメンタルフロー結果を解析する際に有益です IS_REUSED : ブール値プロパティで セルの配置が基準デザインから再利用された場合に TRUE に設定されます REUSE_STATUS : 文字列プロパティで インクリメンタル配置配線後のセルの再利用ステータスを示します 可能な値は次のとおりです New ( 新規 ) Reused ( 再利用 ) Discarded to improve timing ( タイミングを向上するため破棄 ) インプリメンテーション japan.xilinx.com 46

インプリメンテーション完了後の次の操作 インプリメンテーション完了後の次の操作 プロジェクトモードおよび非プロジェクトモードのどちらでも インプリメンテーションが完了した後の操作は インプリメンテーションの結果によります デザインが完全に配置配線されたか 解決が必要な問題があるか タイミング制約およびデザイン要件が満たされたか デザインを完了するのに変更が必要か ザイリンクスパーツ用のビットストリームを生成できる状態であるか インプリメンテーション後に推奨される手順 インプリメンテーション後は 次の手順を実行することをお勧めします 1. インプリメンテーションメッセージを確認します 2. インプリメンテーションレポートを表示し 次の事項を確認します タイミング制約が満たされている (report_timing_summary) リソース使用率が予測どおりである (report_utilization) 消費電力が予測どおりである (report_power) 3. ビットストリームファイルを生成します ビットストリームファイルの生成には デザインがハードウェアのルールに違反していないことを確認する最終 DRC も含まれます 4. 満たされていないデザイン要件がある場合は 次を実行します a. プロジェクトモードでは インプリメント済みデザインを開いて解析します b. 非プロジェクトモードでは インプリメンテーション後のデザインチェックポイントを開きます インプリメント済みデザインの解析の詳細は Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック (UG906) [ 参照 8] を参照してください 非プロジェクトモードでのインプリメンテーション後の次の操作 非プロジェクトモードでは デザインセッションで生成されたメッセージは Vivado ログファイル (vivado.log) に保存されます このログファイルおよびデザインデータからのレポートを参照し プロジェクトの状況を正確に評価します プロジェクトモードでのインプリメンテーション後の次の操作 プロジェクトモードでは Vivado Design Suite で次が実行されます [Messages] ビューにログファイルからのメッセージが表示されます さまざまなレポートが自動的に生成されます プロジェクトモードでは インプリメンテーション run が完了すると 図 1-23 に示すダイアログボックスが表示され 次の操作を選択できます インプリメンテーション japan.xilinx.com 47

インプリメンテーション完了後の次の操作 X-Ref Target - Figure 1-23 [Implementation Completed] ダイアログボックスで 次を実行します 1. 次のいずれかのオプションをオンにします [Open Implemented Design] ネットリスト デザイン制約 ターゲットパーツ 配置配線の結果を Vivado IDE に読み込み 必要に応じてデザインを解析できるようにします [Generate Bitstream] 図 1-23 : プロジェクトモード : [Implementation Completed] ダイアログボックス [Generate Bitstream] ダイアログボックスを開きます 詳細は Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ (UG908) [ 参照 10] を参照してください [View Reports] Vivado ツールでインプリメンテーション中に生成されたレポートファイルを選択して表示できる [Reports] ビューを開きます 詳細は 51 ページの インプリメンテーションレポートの表示 を参照してください 2. [OK] をクリックします インプリメンテーション japan.xilinx.com 48

メッセージの表示 メッセージの表示 重要 : すべてのメッセージを確認してください メッセージには デザインのパフォーマンス 消費電力 エリア 配線を向上するための推奨事項が記載される場合があります クリティカル警告メッセージにも 解決すべきタイミング制約の問題が表示されることがあります 非プロジェクトモードでのメッセージの表示 非プロジェクトモードでは Vivado ログファイル (vivado.log) で次を確認します 1 つのデザインセッションで使用したコマンド コマンドからの結果およびメッセージ 推奨 : Vivado テキストエディターでログファイルを開き すべてのコマンドの結果を確認してください 有益な情報が得られることがあります プロジェクトモードでのメッセージの表示 プロジェクトモードでは [Messages] ビューに [Log] ビューの内容がフィルターされたものが表示され主なメッセージ 警告 およびエラーのみが含まれます [Messages] ビューは機能ごとに分類されており フィルターを適用するツールバーオプションを使用して 特定のタイプのメッセージのみを表示できます 図 1-24 に例を示します X-Ref Target - Figure 1-24 図 1-24 : [Messages] ビュー インプリメンテーション japan.xilinx.com 49

メッセージの表示 プロジェクトモードでメッセージを表示する際は 次の機能を使用できます 横にあるプラス記号 (+) をクリックして展開し 各メッセージを表示します [Messages] ビューの上部にあるチェックボックスのオン / オフを切り替え エラー クリティカル警告 警告 情報メッセージを表示 / 非表示にします [Messages] ビューでリンクを含むメッセージをクリックすると ソースファイルが開き 該当する行がハイライトされます メッセージを右クリックして [Search for Answer Record] をクリックすると ザイリンクスウェブサイトでそのメッセージに関連するアンサーデータベースを検索できます インクリメンタルコンパイルのメッセージ Vivado ツールでは インクリメンタルコンパイルからの次のサマリ結果がログファイルにレポートされます インクリメンタル配置サマリ インクリメンタル配線サマリ インクリメンタル配置サマリ 次に インクリメンタル配置サマリの例を示します 次の情報が含まれます セル配置の再利用の最終的な評価 ランタイム統計 +-----------------------------------------------------------------+ Incremental Placement Summary +-----------------------------------------------------------------+ Reused instances 40336 Non-reused instances 1158 %similarity 97.21 +-----------------------------------------------------------------+ Incremental Placement Runtime Summary +-----------------------------------------------------------------+ Initialization time(elapsed secs) 87.54 Incremental Placer time(elapsed secs) 50.42 +-----------------------------------------------------------------+ インクリメンタル配線サマリ インクリメンタル配線サマリには ネットファンアウトの分散に基づく再利用統計が示されます レポートされるカテゴリは 次のとおりです Fully Reused ネットの配線全体が基準デザインから再利用されています Partially Reused ネットの配線の一部が基準デザインから再利用されています セル セルの配置 またはその両方が変更されたことにより 一部のセグメントは再配線されています New/Unmatched 現在のデザインに含まれるネットが基準デザインのものと一致していません インプリメンテーション japan.xilinx.com 50

インプリメンテーションレポートの表示 +----------------------------------------------------------+ Incremental Routing Reuse Summary: +----------+-----------+-----------+-----------+-----------+ # Fully Partially New / # Fanout Reused Reused Unmatched Total +----------+-----------+-----------+-----------+-----------+ == 2 15749 12 387 16136 +----------+-----------+-----------+-----------+-----------+ < 50 16061 31 375 16467 +----------+-----------+-----------+-----------+-----------+ [50,100] 249 3 20 272 +----------+-----------+-----------+-----------+-----------+ [100,500] 32 0 7 39 +----------+-----------+-----------+-----------+-----------+ >= 500 8 1 0 9 +----------+-----------+-----------+-----------+-----------+ Total 32099 47 789 32923 +----------+-----------+-----------+-----------+-----------+ +----------+-----------+-----------+ % Fully Partially Reuse Reused Reused +----------+-----------+-----------+ Net 97.49 0.14 Pin 100.00 0.00 +----------+-----------+-----------+ インプリメンテーションレポートの表示 Vivado Design Suite では 次の情報を含むさまざまなレポートを生成できます タイミング タイミングの密集度 タイミングサマリ クロック クロックネットワーク クロック使用率 消費電力 スイッチングアクティビティ ノイズ解析レポートを表示すると 次を実行できます スクロールバーを使用してレポートファイルを参照 [Find] または [Find in Files] ボタンをクリックし 特定テキストを検索 [Go to the Beginning] をクリックしてファイルの冒頭に移動 [Go to the End] をクリックしてファイルの最後に移動 インプリメンテーション japan.xilinx.com 51

インプリメンテーションレポートの表示 非プロジェクトモードでのレポート生成 非プロジェクトモードでは レポートを手動で生成する必要があります Tcl コマンドを使用して個々のレポートを生成 Tcl スクリプトを使用して複数のレポートを生成 Tcl スクリプトの例 次の Tcl スクリプト例では 複数のレポートを生成し Reports フォルダーに保存しています # Report the control sets sorted by clk, clken report_control_sets -verbose -sort_by {clk clken} -file C:/Report/cntrl_sets.rpt # Run Timing Summary Report for post implementation timing report_timing_summary -file C:/Reports/post_route_timing.rpt -name time1 # Run Utilization Report for device resource utilization report_utilization -file C:/Reports/post_route_utilization.rpt Vivado IDE でレポートを開く これらのレポートは Vivado IDE で開くことができます Tcl スクリプトの例 の例では report_timing_summary コマンドで次のオプションを使用しています -file オプションを使用して レポートをファイルに保存しています -name オプションを使用して レポートを Vivado IDE に表示しています 図 1-26 に Vivado IDE でレポートを開いた例を示します ヒント : レポートを保存するディレクトリは レポートの生成を実行する前に存在している必要があります ディレクトリがないとファイルは保存されず エラーメッセージが表示されます インプリメンテーションレポートコマンドに関する情報 Vivado IDE または Tcl コマンドプロンプトで help Tcl コマンドを使用すると Tcl レポートコマンドとそのオプションに関する情報を表示できます Tcl レポートコマンドおよびそのオプションの詳細な説明は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) [ 参照 12] を参照してください プロジェクトモードでのレポート生成 プロジェクトモードでは 多くのレポートが自動的に生成されます これらのレポートは [Reports] ビュー ( 図 1-25) にリストされます [Reports] ビューは 合成またはインプリメントコマンドを実行すると自動的に開きます 開いていない場合は 次のいずれかの方法で開くことができます [Project Summary] ビューで [Reports] リンクをクリックします [Window] [Reports] をクリックします ヒント : インプリメンテーション run の tcl.pre および tcl.post オプションを使用すると プロセスの各段階でカスタムレポートを出力できます これらのカスタムレポートは [Reports] ビューには表示されませんが ニーズに合わせて インプリメンテーション japan.xilinx.com 52

インプリメンテーションレポートの表示 カスタマイズできます 詳細は インプリメンテーション run 設定の変更 を参照してください X-Ref Target - Figure 1-25 図 1-25 : [Reports] ビュー [Reports] ビューから表示されるレポートには run に関する情報が含まれます レポートは Vivado IDE でテキスト形式で開きます ( 図 1-26) X-Ref Target - Figure 1-26 図 1-26 : 制御セットレポート インプリメンテーション japan.xilinx.com 53

インプリメンテーションレポートの表示 レポートからのクロスプローブ プロジェクトモードおよび非プロジェクトモードの両方で レポートと [Device] ビューなどのビューに表示される関連デザインデータのクロスプローブがサポートされています メニューコマンドまたは Tcl コマンドを使用してレポートを生成する必要があります テキスト形式のレポートではクロスプローブはサポートされていません たとえば [Reports] ビュー ( 図 1-25) には [Route Design] の下にテキスト形式のタイミングサマリレポートが含まれています タイミングを解析する際は クリティカルパスの配置および配線リソースなどのデザインデータを [Device] ビューに表示すると有益です Vivado IDE で [Tools] [Timing] [Report Timing Summary] をクリックすると タイミングサマリレポートが再生成され 表示されたレポートからデザインの異なるビューにクロスプローブできます タイミングレポートと [Device] ビューのクロスプローブの例 図 1-27 に タイミングサマリレポートと [Device] ビューのクロスプローブの例を示します この非プロジェクトモードの例では 次の手順が実行されています 配線後のデザインチェックポイントを Vivado IDE で開きます report_timing_summary -name を使用して デザインサマリレポートを生成して開きます [Device] ビューでは [Routing Resources] がオンになっています タイミングサマリレポートでタイミングパスを選択すると [Device] ビューでも選択されます 次の図を参照してください X-Ref Target - Figure 1-27 図 1-27 : タイミングレポートと [Device] ビューのクロスプローブ レポートの解析およびデザインクロージャのストラテジの詳細は Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック (UG906) [ 参照 8] を参照してください インプリメンテーション japan.xilinx.com 54

第 2 章 インプリメンテーションコマンド インプリメンテーションコマンドについて ザイリンクス Vivado 統合設計環境 (IDE) には プロジェクトベースのデザインでインプリメンテーションプロセスを管理し 簡略化する多数の機能が含まれています インプリメンテーションプロセスを段階ごとに手動で実行する機能も含まれます 詳細は 第 1 章 Vivado インプリメンテーションプロセス の 18 ページの プロジェクトモードでのインプリメンテーションの実行 を参照してください 非プロジェクトモードでは Tcl コマンドを使用してインプリメンテーションプロセスの各段階を手動で実行する必要があります 注記 : Tcl コマンドの詳細は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) [ 参照 12] を参照するか <command> -help と入力してください 詳細は 第 1 章 Vivado インプリメンテーションプロセス の 15 ページの 非プロジェクトモードでのインプリメンテーションの実行 を参照してください インプリメンテーションのサブプロセス プロジェクトモードおよび非プロジェクトモードのどちらでも Vivado インプリメンテーションプロセスはいくつかのサブプロセスで構成されています 合成済みデザインを開く : ネットリスト デザイン制約 ターゲットデバイスデータを統合し インプリメンテーションを実行するデザインをメモリ内に構築します opt_design ( デザインの最適化 ) : ザイリンクス FPGA デバイスにフィットするよう論理デザインを最適化します power_opt_design ( デザインの消費電力最適化 ) : インプリメント済み FPGA デバイスの消費電力を削減するため デザインエレメントを最適化します 注記 : この手順はオプションです place_design ( デザインの配置 ) : デザインをターゲットザイリンクスデバイスに配置します phys_opt_design ( デザインの物理最適化 ) : さまざまな物理最適化手法を使用して デザインのスラックが負のパスのタイミングを最適化します 注記 : この手順はオプションです route_design ( デザインの配線 ) : デザインをターゲットザイリンクスデバイスに配線します write_bitstream ( ビットストリームの生成 ) : ザイリンクスデバイスコンフィギュレーションのビットストリームを生成します 注記 : ビットストリーム生成は 厳密にはインプリメンテーション run の一部ではありませんが 別の段階として実行可能です インプリメンテーション japan.xilinx.com 55

合成済みデザインを開く この章では インプリメンテーションプロセスの各段階と関連する Tcl コマンドの詳細を説明します Tcl レポートコマンドおよびそのオプションの詳細な説明は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) を参照してください 合成済みデザインを開く インプリメンテーションでは まず最初に合成済みデザインからのネットリストをメモリに読み込み デザイン制約を適用します 合成済みのデザインは 使用されるデザインフローによってさまざまな方法で開くことができます メモリ内でのデザインの構築 メモリ内にデザインを構築するため 次のプロセスでネットリストファイル 制約ファイル およびターゲットデバイスの情報が統合されます 1. ネットリストを統合します 必要であれば 複数のソースからのネットリストを統合します デザインには 構造 Verilog EDIF NGC を含めることができます 2. 従来のネットリストプリミティブを現在サポートされる Unisim プリミティブに変換します ヒント : report_transformed_primitives を使用すると 変換されたセルのリストを生成できます 3. セルの形を作成します Vivado ツールでは 接続または配置制約に基づいてセルの非明示的な形が作成され 配置が簡略化されます 非明示的な形の例は 次のとおりです 相対配置マクロ (RPM) 注記 : RPM は 個別のセルではなくグループとして配置されます 複数のスライスに配置する必要のある長いキャリーチェーン注記 : キャリーチェーンを構成する CARRY4 エレメントは 1 つの形に含め 縦方向に並ぶ複数のスライスに配置されるようにする必要があります インプリメンテーション japan.xilinx.com 56

合成済みデザインを開く Tcl コマンド デザインのソースファイルおよびステートに応じて 次の Tcl コマンドを使用して合成済みデザインをメモリに読み込むことができます synth_design read_checkpoint open_run link_design 表 2-1 : Tcl コマンドを使用可能なモード コマンド プロジェクトモード 非プロジェクトモード synth_design X X read_checkpoint open_run synth_design synth_design コマンドは プロジェクトモードおよび非プロジェクトモード両方で使用できます このコマンドは RTL ソースに対して指定したオプションで Vivado 合成を実行し 合成後にデザインをメモリに読み込みます synth_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>] [-include_dirs <args>] [-generic <args>] [-verilog_define <args>] [-flatten_hierarchy <arg>] [-gated_clock_conversion <arg>] [-effort_level <arg>] [-rtl] [-no_iobuf] [-bufg <arg>] [-fanout_limit <arg>] [-mode <arg>] [-fsm_extraction <arg>] [-keep_equivalent_registers] [-quiet] [-verbose] synth_design のスクリプト例 X link_design X X 次のコードは Vivado ツールのインストールディレクトリの examples/vivado_tutorials ディレクトリに含まれる create_bft_batch.tcl スクリプトからの抜粋です # Setup design sources and constraints read_vhdl -library bftlib [ glob./sources/hdl/bftlib/*.vhdl ] read_vhdl./sources/hdl/bft.vhdl read_verilog [ glob./sources/hdl/*.v ] read_xdc./sources/bft_full.xdc X # Run synthesis, report utilization and timing estimates, write design checkpoint synth_design -top bft -part xc7k70tfbg484-2 -flatten rebuilt write_checkpoint -force $outputdir/post_synth synth_design サンプルスクリプト使用の詳細は Vivado Design Suite チュートリアル : デザインフローの概要 (UG888) を参照してください このサンプルスクリプトでは VHDL および Verilog ファイルが読み込まれ 指定したデバイスでデザインが合成されます synth_design コマンドが完了すると デザインが開き メモリに読み込まれます 合成が完了すると デザインチェックポイントが保存されます Tcl コマンドおよびそのオプションの詳細な説明は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) を参照してください インプリメンテーション japan.xilinx.com 57

合成済みデザインを開く read_checkpoint read_checkpoint コマンドは 非プロジェクトモードでのみ使用できます 非プロジェクトモードで合成済みデザインチェックポイントを開きます read_checkpoint の構文 read_checkpoint [-part <arg>] [-quiet] [-verbose] <file> read_checkpoint のスクリプト例 # Read the specified design checkpoint and create an in-memory design. read_checkpoint C:/Data/post_synth.dcp このサンプルスクリプトでは 合成済みデザインチェックポイントファイルが開きます open_run 合成済みまたはインプリメント済み run を開き メモリに読み込みます 重要 : open_run コマンドは プロジェクトモードでのみ使用できます デザイン run は非プロジェクトモードではサポートされません open_run コマンドをインプリメンテーション前の RTL デザインに使用し 完了した Vivado 合成または XST run を開いて 合成済みネットリストをメモリに読み込みます ヒント : メモリ内のデザインは自動的にアップデートされるので synth_design の後 open_run を使用する必要はありません open_run コマンドは 以前のデザインセッションで完了した合成 run を開く場合にのみ使用します open_run コマンドは RTL デザイン用です ネットリストベースのデザインを開くには link_design コマンドを使用します open_run の構文 open_run [-name <arg>] [-quiet] [-verbose] <run> open_run のスクリプト例 # Open named design from completed synthesis run open_run -name synth_1 synth_1 このサンプルプロジェクトは synth_1 というデザインを開き synth_1 という完了した合成 run をメモリに読み込みます デザインがメモリにある場合に open_run コマンドを実行すると 新しいデザインを開く前に 現在のデザインへの変更を保存するかどうかを尋ねるメッセージが表示されます インプリメンテーション japan.xilinx.com 58

ロジック最適化 link_design サードパーティ合成ツールなどで生成されたネットリストソースからメモリにデザインを作成し ネットリストと合成制約をターゲットデバイスにリンクします ヒント : link_design コマンドは プロジェクトモードおよび非プロジェクトモードの両方でネットリストデザインを作成する場合にサポートされます link_design の構文 link_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>] [-mode <arg>] [-quiet] [-verbose] link_design のスクリプト例 # Open named design from netlist sources. link_design -name netdriven -constrset constrs_1 -part xc7k325tfbg900-1 デザインがメモリにある場合に link_design コマンドを実行すると 新しいデザインを開く前に 現在のデザインへの変更を保存するかどうかを尋ねるメッセージが表示されます 推奨 : メモリに合成済みデザインを作成した後 エラーおよびクリティカル警告を調べて 不足している制約や不正な制約がないかどうかを確認してください デザインが問題なく作成されたら 解析 レポート生成 制約の適用 またはインプリメンテーションを実行できます メモリに合成済みデザインを開いたら report_timing_summary コマンドを実行してタイミング制約をチェックし デザインの目標が適切であるかどうかを確認してください ロジック最適化 ロジック最適化は 配置の前に効率的なロジックデザインを得るために実行します ロジック最適化では ネットリスト接続性チェックが実行され 複数のドライバーを持つネットや駆動されていない入力などの潜在的なデザイン問題に対して警告メッセージが表示されます ブロック RAM の消費電力最適化も実行されます 使用可能なロジック最適化 Vivado ツールでは メモリ内のデザインに対して次のロジック最適化を実行できます リターゲット ( デフォルト ) 定数伝搬 ( デフォルト ) スイープ ( デフォルト ) ブロック RAM の消費電力最適化 ( デフォルト ) リマップ エリアモードでの再合成 重要 : 特定の最適化を明示的に指定すると ほかの最適化はディスエーブルになります インプリメンテーション japan.xilinx.com 59

ロジック最適化 リターゲット ( デフォルト ) 最適化がしやすくなるように セルタイプを別のセルタイプに置換します たとえば MUXF7 はほかの LUT と統合できるように LUT3 に置換されます また インバーターのような単純なセルはダウンストリームロジックに吸収されます 定数伝搬 ( デフォルト ) 定数値をロジックに伝搬することで ロジックは次のようになります 削除 例 : 定数 0 が入力される AND 縮小 冗長 例 : 定数 1 が入力される 3 入力 AND を 2 入力 AND に縮小 例 : 0 が入力される 2 入力 OR を 1 本のワイヤに削減 スイープ ( デフォルト ) ロードのないセルを削除します ブロック RAM の消費電力最適化 ( デフォルト ) ブロック RAM セルに対して消費電力の最適化をイネーブルにします 次を実行します 完全なデュアルポート RAM の読み出されないポートの WRITE_MODE を NO_CHANGE に変更 ブロック RAM の出力にクロックゲーティングを適用 リマップ 複数の LUT を 1 つの LUT にまとめてロジックの深さを削減します エリアモードでの再合成 エリアモードで合成を再実行し LUT の数を削減します 重要 : 各ロジック最適化はメモリ内のデザインに適用され 元の合成済みデザインには適用されません インプリメンテーション japan.xilinx.com 60

ロジック最適化 opt_design 現在のネットリストを最適化します メモリ内のデザインを読み込み 最適化して 最適化されたデザインをメモリに戻します opt_design の構文 opt_design [-retarget] [-propconst] [-sweep] [-bram_power_opt] [-remap] [-resynth_area] [-directive <arg>] [-quiet] [-verbose] opt_design のスクリプト例 # Run logic optimization, save results in a checkpoint, report timing estimates opt_design -retarget -propconst -sweep write_checkpoint -force $outputdir/post_opt report_timing_summary -file $outputdir/post_opt_timing_summary.rpt このサンプルスクリプトでは メモリ内のデザインにロジック最適化を実行し メモリに書き込みます 最適化後にデザインチェックポイントを保存し タイミングサマリレポートを生成して指定のファイルに記述します 最適化タイプの制限 最適化タイプを制限するには コマンドラインオプションを使用します たとえば デフォルトのブロック RAM 最適化を実行しないようにするには 次のコマンドを使用します opt_design -retarget -propconst -sweep -directive オプションの使用 -directive オプションを使用すると opt_design コマンドを異なるモードで実行できます 一度に指定できるモードは 1 つのみです -directive オプションは ほかのオプションと共に使用することはできません 次の設定があります Explore : 最適化を複数回実行します ExploreArea : エリアを縮小することを優先して最適化を複数回実行します AddRemap : デフォルトのロジック最適化フローを実行し LUT 再マップを含めてロジックレベルを削減します -verbose オプションの使用 最適化結果を解析するには -verbose オプションを使用し opt_design の最適化の影響を受けたロジックの詳細を確認します -verbose オプションを使用すると大量のメッセージが表示されるので デフォルトではオフになっています -verbose オプションは 有益だと思われる場合に使用してください 重要 : opt_design コマンドは メモリ内のデザインに対して実行されます 複数回実行した場合 前回の run の結果が最適化されます インプリメンテーション japan.xilinx.com 61

消費電力の最適化 ロジック最適化制約 1. ロジック最適化中 DONT_TOUCH および MARK_DEBUG プロパティが認識され これらのプロパティが設定されているネットは削除されません 詳細は Vivado Design Suite ユーザーガイド : 合成 (UG901) を参照してください MARK_DEBUG は Vivado ロジック解析を使用してプローブする予定のネットに設定します MARK_DEBUG の設定されたネットはスライス境界に接続され プローブできる状態になります DONT_TOUCH は最下位セルに設定し 最適化されないようにします 階層セルに DONT_TOUCH を設定するとセルの境界は保持されますが セル内で最適化が実行される可能性はあります 重要 : ISE Design Suite からデザインを移行した場合 KEEP および KEEP_HIERARCHY 制約が自動的に DONT_TOUCH 制約に変換されます 消費電力の最適化 クロックゲーティングを使用して ダイナミック消費電力を最適化します ( オプション ) 消費電力の最適化は プロジェクトモードおよび非プロジェクトモード両方で使用でき ロジック最適化後または配置後に実行してデザインの消費電力を最適化できます 消費電力の最適化には クロックやロジックを変更せずに FPGA デザインのダイナミック消費電力を削減するクロックゲーティングソリューションが含まれます 詳細は Vivado Design Suite ユーザーガイド : 消費電力解析および最適化 (UG907) を参照してください Vivado 消費電力解析 Vivado ツールでは レガシ IP ブロックおよびサードパーティ IP ブロックを含む デザイン全体が解析され 各クロックサイクルでの結果に影響しないレジスタからの出力ロジックが特定されます クロックイネーブル (CE) の使用 Vivado 消費電力最適化では ザイリンクス 7 シリーズ FPGA デバイスのロジックに多数含まれるクロックイネーブル (CE) が利用されます 細粒度クロックゲーティングまたはロジックゲーティング信号が作成され 余分なスイッチイングアクティビティが除去されます また フリップフロップレベルでは CE はフリップフロップの D 入力とフィードバック Q 出力のいずれかを選択するのではなく クロックをゲーティングしているので CE 入力のパフォーマンスが向上するだけではなく クロックの消費電力も削減されます クロックゲーティング X-Ref Target - Figure 2-1 図 2-1 : クロックゲーティング インプリメンテーション japan.xilinx.com 62

消費電力の最適化 クロックゲーティングでは シンプルデュアルポートまたは完全なデュアルポートモード両方の専用ブロック RAM の消費電力も削減されます ( 図 2-2) これらのブロックには 次のイネーブルが含まれます アレイイネーブル ライトイネーブル 出力レジスタのクロックイネーブル 節約される消費電力のほとんどはアレイイネーブルの使用によるもので データが書き込まれず 出力が使用されないときに 消費電力を削減する機能がインプリメントされます X-Ref Target - Figure 2-2 図 2-2 : BRAM イネーブルの利用 power_opt_design power_opt_design コマンドは デザインを解析して最適化します デフォルトでは デザイン全体が解析および最適化されます クロックゲーティングも実行され 消費電力が最適化されます power_opt_design の構文 power_opt_design [-quiet] [-verbose] デザイン全体を解析および最適化しない場合は set_power_opt を使用して最適化を設定します このコマンドを使用すると 最適化にセルタイプまたは階層を含めるか 除外するかなどを設定できます set_power_opt コマンドの構文は 次のとおりです set_power_opt [-include_cells <args>] [-exclude_cells <args>] [-clocks <args>] [-cell_types <args>] [-quiet] [-verbose] 注記 : opt_design を使用した場合 ブロック RAM の消費電力最適化は実行されません インプリメンテーション japan.xilinx.com 63

配置 配置 Vivado 配置エンジンによりネットリストのセルがターゲットデバイスの特定サイトに配置されます ほかのインプリメンテーションコマンドと同様 メモリ内のデザインに対して処理が実行されます デザイン配置の最適化 Vivado の配置エンジンでは 次を最適化するよう配置が実行されます タイミングスラック : タイミングクリティカルなパスのセルの配置は 負のスラックが最小限になるよう選択されます 配線長 : 配線長を最小限に抑えるように 全体的な配置が実行されます 密集 : ピンの密集度が監視され 配線の密集を削減するためセルが分散されます デザインルールチェック 配置を開始する前に デザインルールチェック (DRC) (report_drc で選択された DRC およびビルトインの内部 DRC) が実行されます 内部 DRC では LOC 制約の設定されていない Memory Interface Generator (MIG) セル 競合する IOSTANDARD が設定された I/O バンクなど 多数の問題がレポートされます クロックおよび I/O 配置 DRC の実行後 クロックおよび I/O セルが配置されてからその他のロジックセルが配置されます クロックと I/O セルは 選択したザイリンクスデバイスに特定の複雑な配置規則によって関連していることがよくあるので 同時に配置されます 配置のターゲット この時点では 次が配置のターゲットとなります I/O ポートおよびロジック グローバルおよびローカルクロックバッファー クロックマネージメントタイル (MMCM および PLL) ギガビットトランシーバー (GT) セル 固定されていないロジックの配置 配置のこの段階では 固定されていないロジックを配置する際 LOC プロパティや Pblock 割り当てなどの物理制約に従います 既存の LOC 制約は ネットリストの接続およびデバイスサイトに対して有効かどうかがチェックされます MIG や GT のような一部の IP は デバイス専用の配置制約を使用して生成されます 重要 : デバイスの I/O アーキテクチャのために LOC プロパティで LOC が適用されていないセルが制約されることがよくあります 入力ポートに LOC 制約が設定されている場合 関連する I/O バッファー IDELAY ILOGIC の位置も固定されます 競合する LOC 制約は 入力パスの個々のセルには適用できません 出力および GT 関連のセルの場合も同様です インプリメンテーション japan.xilinx.com 64

配置 クロックリソースの配置規則 クロックリソースの配置は 7 シリーズ FPGA クロックリソースユーザーガイド (UG472) [ 参照 11] に示す配置規則に従う必要があります たとえば グローバルクロックを駆動する入力はクロック兼用 I/O サイトに配置する必要があり デバイスの上半分または下半分のどちらか同じ側に配置する必要があります これらのクロック配置規則も 論理ネットリストの接続およびデバイスサイトに対して有効かどうかがチェックされます クロックおよび I/O を配置できない場合 クロックおよび I/O の適切な配置が見つからなかった場合は 違反のあった配置規則と 影響を受けたセルの簡単な説明が表示されます まずサイトにセルが暫定的に配置され その後配置問題を解決するために別のセルが配置されることがあります 暫定的な配置により クロックおよび I/O 配置のエラーの原因がわかることがよくあります 暫定的な配置でエラーになったセルを手動で配置すると 配置が改善することがあります ヒント : place_ports コマンドを実行してクロックおよび I/O を配置してから place_design コマンドを実行します ポート配置でエラーが発生した場合 配置はメモリに保存され エラーを解析できます 詳細は Vivado Tcl プロンプトから place_ports -help を実行してください グローバル配置 詳細配置 パッキングおよび有効化 クロックおよび I/O を配置した後 次の配置プロセスが実行されます グローバル配置 詳細配置 パッキングおおよび有効化 配置後 タイミングサマリ ( 概算 ) がログファイルに出力されます Phase 12 Placer Reporting INFO: [Place-100] Post Placement Timing Summary WNS=-0.08836 TNS=-1.479 説明 : WNS : ワーストネガティブスラック TNS : トータルネガティブスラック 推奨 : 配置後に report_timing を実行し クリティカルパスをチェックしてください ネガティブスラックが大きいパスは タイミングクロージャを達成するため 手動配置 制約の変更 またはロジックの再構築が必要な場合があります インプリメンテーション japan.xilinx.com 65

配置 place_design place_design コマンドは ポートおよびセルを自動的に配置します ほかのインプリメンテーションコマンドと同様 place_design コマンドはインクリメンタルに実行されます 部分的に配置されているデザインに対しては 始めから配置し直すのではなく 既存の配置が開始点として使用されます place_design の構文 place_design [-directive <arg>] [-no_timing_driven] [-quiet] [-verbose] place_design のスクリプト例 # Run placement, save results to checkpoint, report timing estimates place_design write_checkpoint -force $outputdir/post_place report_timing_summary -file $outputdir/post_place_timing_summary.rpt このサンプルスクリプトは メモリ内のデザインを配置して 配置後にデザインチェックポイントを保存し タイミングサマリレポートを生成して指定のファイルに記述します -directive オプションの使用 -directive オプションを使用すると place_design コマンドを異なるモードで実行できます 一度に指定できるモードは 1 つのみです -directive オプションは ほかのオプションと共に使用することはできません 配置の -directive オプションで指定可能なモード 配置は通常デザインの全体的なパフォーマンスに最も影響するので -directive オプションで指定可能なモードが多数あります 表 2-2 に どのモードがどのようなデザインに効果的かを示します 表 2-2 : -directive オプションのガイドライン モード 効果が得られるデザイン BlockPlacement ブロック RAM または DSP ブロック あるいはその両方を多数含むデザイン NetDelay 遠距離のネット接続を含むデザインおよび多数の異なるモジュールにファンアウトするネット を含むデザイン SpreadLogic 接続が多数ある密集が発生しやすいデザイン ExtraPostPlacementOpt すべてのタイプのデザイン SSI 密集を緩和したりタイミングを向上するため 異なる分割方法が有益である可能性のある SSI デ ザイン インプリメンテーション japan.xilinx.com 66

配置 -directive オプションで指定可能なモード Explore : 詳細配置および配置後の最適化のエフォートを増加します WLDrivenBlockPlacement : RAM および DSP ブロックをワイヤ長に基づいて配置します タイミングドリブンの配置を無効にし ブロックとの接続距離を最短にするよう配置します LateBlockPlacement : RAMB および DSP ブロックの詳細配置を 配置の最終段階で実行します 通常 ブロックは配置プロセスの初期段階で有効なサイトに割り当てられます その代わり まず大まかなブロック配置を実行し ( 適切な列に揃っていない可能性もあり ) 詳細配置中にブロックを有効なサイトに配置します ExtraNetDelay_high : ファンアウトが大きく距離の長いネットの予測遅延を増加します high medium low の 3 つのレベルがサポートされます ExtraNetDelay_high では増加量が最も大きくなります ExtraNetDelay_medium : ファンアウトが大きく距離の長いネットの予測遅延を増加します high medium low の 3 つのレベルがサポートされます ExtraNetDelay_medium はデフォルトレベルの増加量を適用します ExtraNetDelay_low : ファンアウトが大きく距離の長いネットの予測遅延を増加します high medium low の 3 つのレベルがサポートされます ExtraNetDelay_low では増加量が最も小さくなります SpreadLogic_high : ロジックをデバイス全体に分散します high medium low の 3 つのレベルがサポートされます SpreadLogic_high では分散度が最も高くなります SpreadLogic_medium : ロジックをデバイス全体に分散します high medium low の 3 つのレベルがサポートされます SpreadLogic_medium では分散度が中程度になります SpreadLogic_low : ロジックをデバイス全体に分散します high medium low の 3 つのレベルがサポートされます SpreadLogic_low では分散度が最も低くなります ExtraPostPlacementOpt : 配置後の最適化のエフォートを増加します SSI_ExtraTimingOpt : SLR 間でのタイミングドリブンの分割に代替アルゴリズムを使用します SSI_SpreadSLLs : SLR 間で分割を実行し 接続の多い領域に追加のエリアを割り当てます SSI_BalanceSLLs : SLR 間で SLL のバランスが取られるように SLR 間で分割を実行します SSI_BalanceSLRs : SLR 間でセルの数のバランスが取られるように SLR 間で分割を実行します SSI_HighUtilSLRs : 各 SRL でロジックを近くに配置するよう指定します RuntimeOptimized : 反復回数を少なくし デザインパフォーマンスよりも実行時間を短縮することを優先します Quick : 最も高速な タイミングドリブンでない 有効なデザインを得るために最低限の配置を実行します Default : place_design をデフォルト設定で実行します ヒント : -directive オプションを使用して デザインの異なる配置オプションを試してみてください -no_timing_driven オプションの使用 -no_timing_driven オプションは デフォルトのタイミングドリブン配置アルゴリズムをディスエーブルにします このオプションを使用するとワイヤの長さに基づいて高速な配置が実行されますが タイミング制約は無視されます -verbose オプションの使用 配置結果をより詳細に解析するには -verbose オプションを使用して place_design コマンドによるセルおよび I/O 配置の詳細を確認します -verbose オプションを使用すると大量のメッセージが表示されるので デフォルトではオフになっています -verbose オプションは 有益だと思われる場合に使用してください インプリメンテーション japan.xilinx.com 67

物理最適化 物理最適化 物理最適化では デザインの負のスラックパスに対してタイミングドリブンの最適化が実行されます 複製 リタイミング ホールド違反の修正 および配置の向上が実行されます 物理最適化では ネットリストおよび配置の必要な変更が自動的に実行されます 使用可能な物理最適化 Vivado ツールでは メモリ内のデザインに対して次の物理最適化を実行できます ファンアウトの大きいネットの最適化 ( デフォルト ) 配置ベースの最適化 ( デフォルト ) リワイヤ ( デフォルト ) クリティカルセルの最適化 ( デフォルト ) DSP レジスタの最適化 ( デフォルト ) BRAM レジスタの最適化 ( デフォルト ) ホールド違反の修正 リタイミング ネットの強制的な複製 重要 : 特定の最適化を明示的に指定すると ほかの最適化はディスエーブルになります ファンアウトの大きいネットの最適化 ( デフォルト ) ファンアウトの大きいネットの最適化は 次のように実行されます 1. 負のスラックが WNS のある割合以内であるファンアウトの大きいネットは 複製が考慮されます 2. ロードはその配置によりクラスター化され 各ロードクラスターに対してドライバーが複製および配置されます 3. タイミングが再解析され タイミングが改善した場合はロジックの変更が確定されます 4. 複製後 複製が必要なファンアウトの大きいネットがあるかどうか デザインが再びチェックされます ファン アウトの大きいネットがまだある場合 なくなるまで複製プロセスが続行されます 配置ベースの最適化 ( デフォルト ) クリティカルパスのすべてのセルをワイヤ遅延を削減するように配置し直します リワイヤ ( デフォルト ) LUT の接続をスワップしてクリティカル信号のロジックレベル数を削減することにより クリティカルパスを最適化します LUT 論理式を変更してデザインの機能を保持します クリティカルセルの最適化 ( デフォルト ) タイミングが満たされないセルを複製します 特定のセルのロード同士が離れている場合 セルが複製され 新しいドライバーがロードクラスターの近くに配置されます この最適化は パスがワーストネガティブスラックのある割合以内でタイミングを満たしていなければ ファンアウトが大きくなくても実行されます インプリメンテーション japan.xilinx.com 68

物理最適化 DSP レジスタの最適化 ( デフォルト ) DSP セルのレジスタをロジックアレイに移動したり ロジックを DSP セルに移動したりすることにより クリティカルパスの遅延を削減します BRAM レジスタの最適化 ( デフォルト ) BRAM セルのレジスタをロジックアレイに移動したり ロジックを BRAM セルに移動したりすることにより クリティカルパスの遅延を向上します ホールド違反の修正 ホールドクリティカルパスの遅延を増加することにより ホールド違反の大きいパスのスラックを向上します リタイミング レジスタを組み合わせロジックの前後に移動することにより クリティカルパスの遅延を向上します ネットの強制的な複製 タイミングスラックにかかわらず ネットのドライバーを強制的に複製します 複製はロードの配置に基づいて実行され 複製が十分かどうかを解析する必要があります さらに複製が必要な場合は コマンドを複数回実行することによりネットを繰り返し複製できます タイミングは無視されますが 複製を実行するには ネットがタイミング制約の設定されたパスに含まれている必要があります 物理最適化レポート 物理最適化では 最適化で処理された各ネットと 実行された最適化のサマリがレポートされます ヒント : 複製されたオブジェクトの名前は 元のオブジェクト名に _replica と複製されたオブジェクトカウントが付いたものになります phys_opt_design 重要 : ファンアウトの大きいネットのタイミングドリブン複製などの物理最適化を実行し タイミング結果を向上します ( オプション ) 配線済みデザインに対して phys_opt_design を実行することはできません phys_opt_design の構文 phys_opt_design [-fanout_opt] [-placement_opt] [-rewire] [-critical_cell_opt] [-dsp_register_opt] [-bram_register_opt] [-hold_fix] [-retime] [-force_replication_on_nets <args>] [-directive <arg>] [-quiet] [-verbose] phys_opt_design のスクリプト例 # Run physical optimization, save results to checkpoint, report timing estimates phys_opt_design write_checkpoint -force $outputdir/post_phys_opt.dcp report_timing_summary -file $outputdir/post_phys_opt_timing_summary.rpt インプリメンテーション japan.xilinx.com 69

物理最適化 このサンプルスクリプトは メモリ内のデザインに物理最適化を実行し メモリに書き込みます 物理最適化後にデザインチェックポイントを保存し タイミングサマリレポートを生成して指定のファイルに記述します -directive オプションの使用 -directive オプションを使用すると phys_opt_design コマンドを異なるモードで実行できます 一度に指定できるモードは 1 つのみです -directive オプションは ほかのオプションと共に使用することはできません 次の設定があります Explore : 最適化を複数回実行し ホールド違反の修正およびファンアウトの大きいネットの複製を含め 異なるアルゴリズムを実行します AggressiveExplore : Explore と似ていますが 異なる最適化アルゴリズムを使用し より厳しい目標を設定します AlternateReplication : クリティカルセルの複製に異なるアルゴリズムを使用します AggressiveFanoutOpt : ファンアウトに関連する最適化に異なるアルゴリズムを使用し より厳しい目標を設定します AlternateDelayModeling : ネット遅延の予測に代替アルゴリズムを使用して すべての最適化を実行します AddRetime : デフォルトの phys_opt_design フローを実行し レジスタのリタイミングを追加します Default : phys_opt_design をデフォルト設定で実行します -verbose オプションの使用 物理最適化の結果を解析するには -verbose オプションを使用し phys_opt_design で実行された最適化の詳細を確認します -verbose オプションを使用すると大量のメッセージが表示されるので デフォルトではオフになっています -verbose オプションは 有益だと思われる場合に使用してください 重要 : phys_opt_design コマンドは メモリ内のデザインに対して実行されます 2 回実行した場合 1 回目の run の結果が最適化されます 物理最適化制約 物理最適化中 DONT_TOUCH および MARK_DEBUG プロパティが認識され これらのプロパティが設定されているネットまたはセルには最適化は実行されません また Pblock の割り当てに従い 複製されたロジックでも元のロジックの Pblock 割り当てが適用されます タイミング例外も 元のセルから複製セルにコピーされます 詳細は Vivado Design Suite ユーザーガイド : 合成 (UG901) を参照してください MARK_DEBUG は Vivado ロジック解析を使用してプローブする予定のネットに設定します MARK_DEBUG の設定されたネットはスライス境界に接続され プローブできる状態になります DONT_TOUCH は最下位セルに設定し 最適化されないようにします 階層セルに DONT_TOUCH を設定するとセルの境界は保持されますが セル内で最適化が実行される可能性はあります 重要 : ISE Design Suite からデザインを移行した場合 KEEP および KEEP_HIERARCHY 制約が自動的に DONT_TOUCH 制約に変換されます インプリメンテーション japan.xilinx.com 70

配線 配線 Vivado 配線は 配置済みデザインに対して配置を実行し ホールドタイム違反を解決するため配線済みデザインの最適化を実行します デフォルトではタイミングドリブンですが これはディスエーブルにできます 配線モード 配線ツールは 次の 2 つモードで実行できます 通常モード 再配線モード 通常モード これがデフォルトです 配置済みデザインから開始し すべてのネットの配線を試みます 配線済みの次のいずれかのデザインから開始します 未配線 一部配線済み 完全に配線済み route_design コマンドはインクリメンタルに実行され 部分的に配線されているデザインに対しては 始めから配線し直すのではなく 既存の配線が開始点として使用されます 再配線モード ほかのインプリメンテーションコマンドと同様 配線はインクリメンタルに実行され 既存の配線を破棄して最初から配線し直すのではなく 既存の配線を保持して続行します 推奨 : 配線初期化には時間がかかるので 再配線モードは配線を複数回実行する際に使用します 再配線モードを使用しない場合 各配線後に配線機能が終了してメモリがクリアされ 配線を実行するごとに配線機能が初期化されます 配線を複数回実行する場合 これは時間がかかります 再配線モードでは 配線が再び実行されることを考慮して メモリにデータ構造が保持されるので ネットの配線解除および配線などのコマンドをすぐに実行できます デザインルールチェック 配線を開始する前に 次のデザインルールチェック (DRC) が実行されます report_drc で選択された DRC Vivado 配線エンジンに含まれるビルトインの DRC インプリメンテーション japan.xilinx.com 71

配線 配線の優先順位 Vivado 配線では まず次のようなグローバルリソースが配線されます クロック リセット I/O その他の専用リソース このデフォルトの優先順位は Vivado 配線にビルトインされています その後 タイミングがどれだけクリティカルかに基づいて データ信号に優先順位が付けられます 不適切なタイミング制約の影響 配線前のフローや固定配線制約を使用する場合 タイミング制約が適切でないと 一部の信号が最適に配線されないことがあるので 注意が必要です 次に よくある不適切なタイミング制約の例を示します クロックドメインをまたがるパスや ホールドタイミングにより配線遅延が追加される複数サイクルパス 密集しているエリア これは RTL 合成のファンアウト最適化や物理最適化により解決できます 最適に配線されていないネットがある場合 問題は多くの場合間違ったタイミング制約です 配線設定を変更してみる前に 制約が適切であるかどうかを確認してください 配線の前の配置済みデザインのタイミングレポートを参照して タイミングと制約を確認します 推奨 : 単に配線リソースを増やすのではなく 制約をクリーンアップすること または RTL を変更することを考慮してください route_design 現在のデザインに含まれるネットを配線し ターゲットパーツでのロジック接続を完成させます route_design の構文 route_design [-unroute] [-re_entrant <arg>] [-nets <args>] [-physical_nets] [-pin <arg>] [-directive <arg>] [-no_timing_driven][-preserve] [-delay] [-free_resource_mode] -max_delay <arg> -min_delay <arg> [-quiet] [-verbose] -directive オプションの使用 -directive オプションを使用すると route_design コマンドを異なるモードで実行できます 一度に指定できるモードは 1 つのみです -directive オプションは ほかのオプションと共に使用することはできません 次の設定があります Explore : 初期配線の後 異なるクリティカルパス配線を試します NoTimingRelaxation : 配線を完了するためにタイミングを緩和しないようにします 配線でタイミング満たすのが困難である場合 元のタイミング制約を満たすため実行時間が長くなります MoreGlobalIterations : 最終段階だけでなく すべての段階で詳細なタイミング解析を使用し タイミングの向上が少しであってもグローバル反復を実行します インプリメンテーション japan.xilinx.com 72

配線 HigherDelayCost : 配線の内部コスト関数を調整して反復実行で遅延に焦点を置き 実行時間が長くなる代わりにパフォーマンスを向上します AdvancedSkewModeling : 配線のすべての段階でより正確なスキューモデルを使用します スキューの大きいクロックネットワークでデザインのパフォーマンスが向上する場合があります RuntimeOptimized : 反復回数を少なくし デザインパフォーマンスよりも実行時間を短縮することを優先します Quick : 最も高速な タイミングドリブンでない 有効なデザインを得るために最低限の配置を実行します Default : route_design をデフォルト設定で実行します よりよい配線結果を得るために実行時間を長くする 次の -directive 設定を使用すると 実行時間が長くなる代わりによりよい配線結果が得られる可能性があります NoTimingRelaxation MoreGlobalIterations HigherDelayCost AdvancedSkewModeling 通常モード配線のサンプルスクリプト # Route design, save results to checkpoint, report timing estimates route_design write_checkpoint -force $outputdir/post_route report_timing_summary -file $outputdir/post_route_timing_summary.rpt このサンプルスクリプトは メモリ内のデザインを配線し メモリに書き込みます 配置後にデザインチェックポイントを保存し タイミングサマリレポートを生成して指定のファイルに記述します 通常モードの配線は インプリメンテーション run の一部として または Tcl place_design の後に route_design コマンドを使用して実行します スクリプトの一部として 配線が終了すると リソースタイプ別に使用される配線リソースの統計およびタイミングサマリが表示されます [Route-20] Post Routing Timing Summary WNS=0.0585 TNS=0 WHS=0 THS=0 説明 : WNS : ワーストネガティブスラック TNS : トータルネガティブスラック WHS : ワーストホールドスラック THS : トータルホールドスラック 再配線モード配線のサンプルスクリプト 1 # route a few critical nets route_design -delay -nets [get_nets mypreroutes*] # Complete full route route_design -nets または -pin のような再配線オプションを使用すると 再配線モードになります インプリメンテーション japan.xilinx.com 73

配線 再配線モードの配線は通常 次のような特定の配線問題を修正するためにインタラクティブに実行します 完全に配線する前に クリティカルネットおよびロックダウンリソースを事前に配線 クリティカルではないネットの配線を手動で解除して クリティカルネットにより多くの配線リソースを使用できるようにする 最初の再配線コマンドでは 配線機能が初期化されてから クロックなどの重要なネットが配線されます これにより 配線で次が実行できるようになります タイミング解析 タイミングドリブンの配線 ホールド違反の修正 再配線モードがオンになった後は 実行された配線および未配線の結果がメモリに保存されます 再配線モードの終了 再配線モードを終了するには 完全な route_design コマンドを実行するか 次のコマンドを使用してオフにします route_design -re_entrant off 再配線モード配線のサンプルスクリプト 2 # Get the nets in the top 10 critical paths, assign to $preroutes % set preroutes [get_nets -of [get_timing_paths -max_paths 10]] % route_design -nets [get_nets $preroutes] -delay # Unroute all the nets in u0/u1, and route the critical nets first route_design -unroute [get_nets u0/u1/*] % route_design -delay -nets [get_nets $mycritnets] route_design -effort_level high このサンプルスクリプトは 次を実行します get_timing_paths を使用して上位 10 個のクリティカルパスを特定します get_cells -of を使用してそれらのクリティカルパスのネットオブジェクト ($preroutes) を作成します これらのネットを最初に配線します それらのネットの配線が完了した後 セル u0/u1 のすべてのネットの配線を解除して クリティカルネット mycritnets を配線し直し 最後に残りの未配線ネットを配線します 表 2-3 : 配線中のデザイン解析で使用されるコマンド コマンド report_route_status report_timing 機能 ネットの配線ステータスをレポートします パスエンドポイント解析を実行します Tcl レポートコマンドおよびそのオプションの詳細な説明は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) を参照してください インプリメンテーション japan.xilinx.com 74

第 3 章 配線およびロジックの変更 配線およびロジックの変更について ザイリンクス Vivado Design Suite では インプリメンテーションフローで配線およびロジックを変更するのにいくつかの方法があります これらの方法を使用すると 配線および遅延を厳密に制御でき ロジックをすばやく変更できます 配線の変更 ロジックの変更 配線の変更 デザインの配線を変更は [Device] ビューから実行できます 個々のネットに対して配線の解除 配線 配線の固定を実行できます 配線の解除および配線 : 配線を再配線モードで起動し ネットに対して操作を実行します 詳細は 第 2 章 インプリメンテーションコマンド の 72 ページの route_design を参照してください 配線の固定 : 配線し 配線データベースで固定とマークし ネットのドライバーおよびロードの LOC および BEL を固定します ネットを手動で敗戦する配線割り当てモードも使用できます 詳細は 76 ページの 手動配線 を参照してください ヒント : ネット関連のコマンドはすべて ネットのポップアップメニューから実行できます インプリメンテーション japan.xilinx.com 75

配線の変更 X-Ref Target - Figure 3-1 図 3-1 : 配線の変更 手動配線 手動配線を使用すると ネットに特定の配線リソースを選択できます これにより 信号の配線パスを完全に制御できます 手動配線では route_design は実行されません 配線は配線データベースで直接アップデートされます 手動配線は ネットの遅延を厳密に制御する場合に使用します たとえば ソース同期インターフェイスで デバイスの受信レジスタまでの配線遅延の変動を最小限に抑える場合などです これには レジスタおよび I/O に LOC および BEL 制約を設定し ネットを手動配線することにより IOB からレジスタまでの配線遅延を制御します 手動配線を実行するには デバイスのインターコネクトアーキテクチャに関する詳細な知識が必要です 手動配線を実行する信号数を制限し 短い接続にのみ使用することをお勧めします 手動配線での規則 手動配線では 次の規則に従ってください ドライバーおよびロードに LOC 制約と BEL 制約が必要です 手動配線では分岐は使用できませんが 分岐点から新しい手動配線を開始することにより分岐をインプリメントできます LUT ロードのピンを固定する必要があります ドライバーに接続されていないロードに配線する必要があります 完全な接続のみが許容されます アンテナは許容されません 既存の固定されていない配線済みネットとオーバーラップさせることができます 手動配線が完了した後 route_design を実行し ネットのオーバーラップによる競合を解決してください インプリメンテーション japan.xilinx.com 76

配線の変更 配線割り当てモードの開始 配線割り当てモードを開始するには 次の手順に従います 1. [Device] ビューを開きます 2. 配線が必要なネットを選択します 未配線のネットは 赤色のフライラインで表示されます 部分的に配線されたネットは 黄色で表示されます 3. 右クリックして [Enter Assign Routing Mode] をクリックします [Target Load Cell Pin] ダイアログボックスが開きます 4. 配線先のロードセルピンを選択します ( オプション ) 5. [OK] をクリックします 手動配線モードになりました [Device] ビューの横に [Routing Assignment] ウィンドウが表示されます ( 図 3-2) [Routing Assignment] ウィンドウ X-Ref Target - Figure 3-2 [Routing Assignment] ウィンドウには 次の 2 つのセクションがあります [Assigned Nodes] [Neighbor Nodes] 図 3-2 : [Routing Assignment] ウィンドウ [Assigned Nodes] には 既に配線が割り当てられているモードを示します 割り当済みの各ノードが 1 行に表示されます インプリメンテーション japan.xilinx.com 77

配線の変更 割り当て済みの配線は [Device] ビューでオレンジ色で示されます 割り当て済みノードの間のギャップは [Assigned Nodes] セクションに GAP 行として表示されます 次の配線セグメントを割り当てるには ギャップの前または後の割り当て済みノードを選択するか [Assigned Nodes] セクションの最後のノードを選択します ノードを選択すると [Neighbor Nodes] セクションに近くにある可能なノードが表示されます 選択されているノードが白で示されされ 可能なノードが白の点線で示されます ( 図 3-3) X-Ref Target - Figure 3-3 図 3-3 : 配線セグメントの割り当て 配線ノードの割り当て 次の配線セグメントに割り当てるノードを決定したら 次のいずれかを実行します [Neighbor Nodes] セクションでノードを右クリックし [Assign Node] をクリックします [Neighbor Nodes] セクションでノードをダブルクリックします [Device] ビューでノードをクリックします 配線をノードに割り当てると そのノードが [Assigned Nodes] セクションに表示され [Device] ビューでオレンジ色でハイライトされます ロードに到達するまで またはギャップを含む配線を割り当てる準備ができるまで ノードの割り当てを継続します インプリメンテーション japan.xilinx.com 78

配線の変更 配線ノードの割り当て解除 ノードの割り当てを解除するには 次の手順に従います 1. [Routing Assignment] ウィンドウの [Assigned Nodes] セクションに移動します 2. 割り当てを解除するノードを選択します 3. 右クリックして [Remove] をクリックします ノードが割り当てから削除されます 配線割り当ての確定 配線の割り当てを確定して配線割り当てモードを終了するには 次のいずれかを実行します [Routing Assignment] ウィンドウで [Assign Routing] ボタンをクリックします [Device] ビューでネットを右クリックして [Assign Routing] をクリックします [Assign Routing] ダイアログボックス ( 図 3-4) が表示されます このダイアログボックスで 割り当てられたノードを確認します X-Ref Target - Figure 3-4 配線割り当てのキャンセル 図 3-4 : [Assign Routing] ダイアログボックス 配線割り当てを確定できない場合は 次のいずれかの方法を使用して配線割り当てをキャンセルできます [Routing Assignment] ウィンドウで [Exit Mode] をクリックします [Device] ビューを右クリックして [Exit Assign Routing Mode] をクリックします 配線を確定すると ドライバーおよびロードの BEL および LOC も固定されます インプリメンテーション japan.xilinx.com 79

配線の変更 割り当て済みの配線の確認 割り当て済みの配線は [Device] で緑色の点線で示されます 部分的に割り当てられた配線は [Device] で黄色の点線で示されます 次の図に 割り当て済み配線と部分的に割り当てられた配線の例を示します X-Ref Target - Figure 3-5 図 3-5 : 割り当て済みの配線および部分的に割り当てられた配線 LUT ロードのセル入力の固定 配線しようとしている LUT ロードの入力が ほかの入力とスワップされていないことを確認する必要があります これには 次の手順に従って LUT ロードのセル入力を固定します 1. [Device] ビューを開きます 2. ロード LUT を選択します 3. 右クリックして [Lock Cell Input Pins] をクリックします 分岐 複数のロードを持つネットを配線する場合は 次の手順に従ってネットを配線します 1. 77 ページの 配線割り当てモードの開始 の手順に従って 1 つのロードへの配線を割り当てます 2. ネットのすべての分岐への配線を割り当てます 次の図に 1 つのロードへの配線が割り当てられ さらに 2 つのロードへの配線が必要なネットを示します インプリメンテーション japan.xilinx.com 80

配線の変更 X-Ref Target - Figure 3-6 図 3-6 : 分岐配線の割り当て 分岐への配線の割り当て 分岐に配線を割り当てるには 次の手順に従います 1. [Device] ビューを表示します 2. 配線するネットノードを選択します 3. 右クリックします 4. [Enter Assign Routing Mode] をクリックします [Target Load Cell Pin] ダイアログボックスが開き すべてのロードが表示されます インプリメンテーション japan.xilinx.com 81

配線の変更 注記 : 配線が割り当てられているロードには [Routed] 列にチェックマークが示されています X-Ref Target - Figure 3-7 図 3-7 : [Target Load Cell Pin] ダイアログボックス ( 複数ロード ) 5. 配線するロードを選択します 6. [OK] をクリックします [Branch Start] ダイアログボックスが開きます 図 3-8 を参照してください 7. 選択したロードの配線を分岐するノードを選択します 8. [OK] をクリックします 9. 78 ページの 配線ノードの割り当て の手順に従います X-Ref Target - Figure 3-8 図 3-8 : [Branch Start] ダイアログボックス インプリメンテーション japan.xilinx.com 82

配線の変更 指定配線制約 固定された配線割り当ては 配線データベースに指定配線文字列として保存されます 指定配線文字列では 分岐はネストされた中かっこ ({ }) で示されます たとえば 図 3-9 に示すような配線があるとします この配線では さまざまなエレメントが次の表に示すように示されています 表 3-1 : 指定配線制約 エレメントドライバーとロードノードスイッチボックス オレンジ色の矩形 赤い線 青い矩形 表示方法 この配線の簡略化された指定配線文字列は 次のようになります {A B { D E L } 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 です X-Ref Target - Figure 3-9 図 3-9 : 分岐配線の例 インプリメンテーション japan.xilinx.com 83

ロジックの変更 ロジックの変更 読み取り専用でない論理オブジェクトのプロパティは インプリメンテーション後に Vivado IDE GUI または Tcl で変更できます 注記 : Tcl コマンドの詳細は Vivado Design Suite Tcl コマンドリファレンスガイド (UG835) [ 参照 12] を参照するか <command> -help と入力してください [Device] ビューでオブジェクトのプロパティを変更するには 次の手順に従います 1. オブジェクトを選択します 2. [Properties] ビューの [Properties] タブでオブジェクトのプロパティを変更します X-Ref Target - Figure 3-10 図 3-10 : プロパティの変更 変更可能なプロパティには ブロック RAM の INIT MMCM のクロックを変更するプロパティなどがあります LUT オブジェクトの INIT を変更するためのダイアログボックスもあり LUT 論理式を指定して適切な INIT 値がツールにより設定されるようにすることができます インプリメンテーション japan.xilinx.com 84

ロジックの変更 X-Ref Target - Figure 3-11 図 3-11 : LUT 論理式の指定 変更の保存 メモリ内でデザインに対して加えた変更を保存するには デザインのチェックポイントを保存します 割り当てはデザインにバックアノテートされないので 次回の実行で適用されるようにするには 割り当てを XDC に追加する必要があります プロジェクトモードで制約を制約ファイルに保存するには [File] [Save Constraints] をクリックします インプリメンテーション japan.xilinx.com 85

付録 A リモートホストの使用 リモート Linux ホストでの run の起動 ザイリンクス Vivado IDE では 複数の Linux ホストで同時に合成およびインプリメンテーション run を実行できます これは Oracle 社の Grid Engine や IBM 社の Platform LSF などの簡易版を使用した機能です リモートホストは 次の理由から Linux でのみサポートされます Linux の方がセキュリティが優れている Microsoft Windows システムにリモートシェル機能がない ジョブ投入アルゴリズムは Linux OS のサービスであるセキュアシェル (SSH) 内の Tcl パイプを使用したラウンドロビン形式でインプリメントされています 推奨 : Vivado IDE で複数の Linux ホストで run を起動する前に リモート run を起動するたびにパスワードを入力しなくて済むように SSH を設定する必要があります SSH の設定方法は 89 ページの SSH の設定 を参照してください リモートホストの実行要件 リモート Linux ホストで合成およびインプリメンテーション run を実行する際の要件は 次のとおりです Vivado ツールのインストールがログインシェルから使用できると想定されるので $XILINX_VIVADO および $PATH 環境変数が.cshrc/.bashrc セットアップスクリプトで正しく設定されます リモートマシンにログインし ほかのスクリプトをソースとせずに vivado -help と入力できる場合 このフローは機能します ログイン時に.cshrc または.bashrc で Vivado が設定されていない場合 [Run pre-launch script] を使用して 環境設定スクリプトをすべてのジョブ前に実行できます Vivado IDE のインストールがリモートマシンの割り当てられたネットワークから表示できるようにする必要があります Vivado IDE がマシンのローカルディスクにインストールされている場合は リモートマシンからは表示できない可能性があります Vivado IDE のプロジェクトファイル (.xpr) およびディレクトリ (.dita および.runs) が リモートマシンの割り当てられたネットワークから表示できるようにする必要があります デザインデータがローカルディスクに保存されていると リモートマシンからは表示できない可能性があります インプリメンテーション japan.xilinx.com 86

リモート Linux ホストでの run の起動 リモートホストの設定 リモート Linux ホストで合成またはインプリメンテーションを実行できるように Vivado IDE を設定するには 次の手順に従います 1. 次のいずれかを実行します メインメニューから [Tools] [Options] をクリックし 左側のペインで [Remote Hosts] をクリックします Flow Navigator で [Synthesis] を右クリックして [Launch Synthesis Runs] をクリックし [Configure Hosts] をクリックします Flow Navigator で [Implementation] を右クリックして [Launch Implementation Runs] をクリックし [Configure Hosts] をクリックします [Design Runs] ビューでツールバーの [Launch Selected Runs] をクリックし [Configure Hosts] をクリックします 図 A-1 を参照してください X-Ref Target - Figure A-1 図 A-1 : [Launch Selected Runs] ダイアログボックスの [Configure Hosts] ボタン [Vivado Options] ダイアログボックスの [Remote Hosts] ページが開き 定義されているリモート Linux ホストが表示されます ( 図 A-2) 2. [Add] ボタンをクリックし リモートサーバー名を入力します 3. [Jobs] 列で リモートマシンで同時実行に使用できるプロセッサの数を指定します 各 run は個別のプロセッサ で実行されます 4. [Enabled] チェックボックスをオン / オフにして サーバーを使用するかどうかを指定します このチェックボッ クスで 選択した run にどのサーバーを使用するかを指定できます 5. run を実行する際に使用するリモートアクセスコマンドを変更する場合は [Launch jobs with] で指定します 注記 : この手順はオプションです デフォルトコマンドは次のとおりです ssh -q -o -BatchMode=yes 重要 : このフィールドを変更する場合は 細心の注意を払ってください たとえば BatchMode =yes を削除すると セキュアシェルでパスワードのプロンプトが表示されるため プロセスが停止していまいます インプリメンテーション japan.xilinx.com 87

. リモート Linux ホストでの run の起動 6. run の起動前に実行するスクリプトを定義する場合は [Run pre-launch script] をオンにします ログイン時に Vivado IDE が設定されていない場合に このオプションを使用してホスト環境を設定するスクリプトを実行します 7. 結果を移動またはコピーするなど run の完了後に実行するカスタムスクリプトを定義する場合は [Run postcompletion script] をオンにします 8. run の完了時に電子メールが送信されるようにする場合は [Send email to] をオンにします 各ジョブの後に通知を送信するか ([After each Job]) すべてのジョブの完了後に通知を送信するか ([After all jobs] を選択できます 9. 設定が終了したら [OK] をクリックします X-Ref Target - Figure A-2 図 A-2 : リモートホストの設定リモートホストへの接続を確認するには 次の手順に従います 1. 1 つまたは複数のホストを選択します 2. [Test] をクリックします サーバーが使用可能かどうか コンフィギュレーションが正しく設定されているかを確認できます 推奨 : ホストで run を実行する前に 各ホストをテストして正しく設定されていることを確認してください インプリメンテーション japan.xilinx.com 88