vivado design suite - xilinx...vivado design suite ユーザーガイド...

Vivado Design Suite ユーザーガイド

デザイン解析およびクロージャテクニック

UG906 (v2015.4) 2015 年 11 月 18 日

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

デザイン解析およびクロージャテクニック japan.xilinx.com 2UG906 (v2015.4) 2015 年 11 月 18 日

改訂履歴

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

日付バージョン改訂内容

2015 年 11 月 18 日 2015.4 Vivado® Design Suite 2015.4 リリースに併せてアップデート。

次のように変更 :• 付録 A 「タイミング DRC」を追加

• 45 ページの「パルス幅レポート」をわかりやすく書き換え

• 169 ページの「ファンアウトの大きいネットドライバーの特定」をわかりやすく書き換え

2015 年 9 月 30 日 2015.3 Vivado Design Suite 2015.3 リリースに併せてアップデート。

次のように変更 :• このバージョンでのツールの変更に併せて図をアップデート第 3 章• 「デザイン解析レポート」セクションを移動し、大幅に変更 (以前のバージョンではこ

のセクションは第 4 章に含まれる )第 4 章• 「I/O レポート」のリストをアップデート

• 「消費電力レポート」で set_default_switching_activity コマンドを set_switching_activity コマンドに変更

2015 年 5 月 26 日 2015.1 Vivado Design Suite 2015.1 リリースに併せてアップデート。

次のように変更 :• 62 ページの「クロック乗せ換えレポート」を追加

• 92 ページの「デザイン解析レポート」を追加

• 第 7 章「デザイン解析テクニック」を追加

http://japan.xilinx.com

http://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG906&Title=Vivado%20Design%20Suite%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B%20%3A%20%26%2312487%3B%26%2312470%3B%26%2312452%3B%26%2312531%3B%26%2335299%3B%26%2326512%3B%26%2312362%3B%26%2312424%3B%26%2312403%3B%26%2312463%3B%26%2312525%3B%26%2312540%3B%26%2312472%3B%26%2312515%3B%20%26%2312486%3B%26%2312463%3B%26%2312491%3B%26%2312483%3B%26%2312463%3B%20%28UG906%29&releaseVersion=2015.4&docPage=2


目次

第 1章 : IDE を使用したロジック解析IDE を使用したデザイン解析. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

ロジック解析機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

[Netlist] ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

[Hierarchy] ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

[Schematic] ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

[Find] ダイアログボックスを使用したオブジェクトの検索 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

デバイス使用率統計の解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

DRC レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

設計手法 DRC の検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

第 2章 : タイミング解析機能タイミングサマリレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

クロックネットワークレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

クロック関連性レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

パルス幅レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

タイミングレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

データシートレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

例外レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

クロック乗せ換えレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

第 3章 : インプリメンテーション結果の解析機能[Design Runs] ウィンドウの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

配置解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

配線解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

デザイン解析レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

第 4章 : レポートおよびメッセージ概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

IDE でのメッセージの表示および管理. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Vivado で生成されるレポートおよびメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

デザインに関するレポートの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

第 5章 : タイミング解析の実行タイミング解析の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

タイミング解析の基礎の理解 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

タイミングサインオフの確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

タイミングパスレポートの解釈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

第 6章 : デザインクロージャテクニック制約およびソースのチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145




ツールのエフォートレベルの増加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

フロアプラン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

配線の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

第 7章 : デザイン解析テクニックreport_design_analysis コマンドの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

エラボレート済みビューを使用した RTL の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

デザインの長ロジック遅延パスを特定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

ファンアウトの大きいネットドライバーの特定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

ホールド違反の修正がデザインに悪影響を及ぼすかの判断 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

タイミングが満たされていないパスすべてをすばやく解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

付録 A : タイミング DRCTIMING-1:Invalid Clock Waveform on Clock Modifying Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

TIMING-2:Invalid Primary Clock on Internal Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

TIMING-3:Invalid Primary Clock on Clock Modifying Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

TIMING-4:Invalid Primary Clock Redefinition on a Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

TIMING-5:Invalid Waveform Redefinition on a Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

TIMING-6:No Common Primary Clock Between Related Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

TIMING-7:No Common Node Between Related Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

TIMING-8:No Common Period Between Related Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

TIMING-9:Unknown CDC Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

TIMING-10:Missing Property on Synchronizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

TIMING-11:Inappropriate Max Delay with Datapath Only Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

TIMING-12:Clock Reconvergence Pessimism Removal Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

TIMING-13:Timing Paths Ignored Due to Path Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

TIMING-14:LUT on the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

TIMING-15:Large Hold Violation on Inter-Clock Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

TIMING-16:Large Setup Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

TIMING-17:Non-Clocked Sequential Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

TIMING-18:Missing Input or Output Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

TIMING-19:Inverted Generated Clock Waveform on ODDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

TIMING-20:Non-Clocked Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

TIMING-21:Invalid COMPENSATION Property on MMCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

TIMING-22:Missing External Delay on MMCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

TIMING-23:Combinatorial Loop Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

TIMING-24:Overridden Max Delay Datapath Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

TIMING-25:Invalid Clock Waveform on Gigabit Transceiver (GT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

TIMING-26:Missing Clock on Gigabit Transceiver (GT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

TIMING-27:Invalid Primary Clock on Hierarchical Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

TIMING-28:Auto-Derived Clock Referenced by a Timing Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

TIMING-29:Inconsistent Pair of Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

TIMING-30:Sub-Optimal Master Source Pin Selection for Generated Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

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

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

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

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

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




第 1章

IDE を使用したロジック解析

IDE を使用したデザイン解析次の章では、ザイリンクス Vivado® 統合設計環境 (IDE) でのデザイン解析の概要を説明します。

• 「IDE を使用したロジック解析」 (この章)

• 第 2 章「タイミング解析機能」

• 第 3 章「インプリメンテーション結果の解析機能」

ロジック解析機能この章では、次のロジック解析機能について説明します。

• 「[Netlist] ウィンドウ」

• 「[Hierarchy] ウィンドウ」

• 「[Schematic] ウィンドウ」

• 「[Find] ダイアログボックスを使用したオブジェクトの検索」

• 「デバイス使用率統計の解析」

• 「DRC レポート」

• 「設計手法 DRC の検証」




第 1 章 : IDE を使用したロジック解析

[Netlist] ウィンドウ[Netlist] ウィンドウには、合成ツールで処理されたネットリストでのデザイン階層が表示されます。

合成設定によって、ネットリストの階層が元の RTL と 100% 同じであったり、階層がなかったりします。一般的には、合成ツールはデフォルトではほとんどのユーザー階層を保持しながらロジックを適化し、小型で高速のネットリストを作成します。

合成ツールのデフォルトを使用すると、ネットリストの階層は認識されますが、階層へのインターフェイスが変更される場合があります。一部のピンや階層レベルがない場合もあります。

階層の各レベルは、その階層ツリーを示します。各レベルに、次のものが表示されます。

• そのレベルのすべてのネットを含む [Nets] フォルダー

• そのレベルにハードウェアプリミティブインスタンスがある場合は [Leaf Cells] フォルダー

• そのレベルにインスタンシエートされている階層

ツリーをたどると、すべてのブランチを表示できます。セルの横に表示されているアイコンは、デザインの状態を示します。

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

階層の各レベルの [Instance Properties] ウィンドウの [Statistics] ビューには、次のようなリソース使用率統計が表示されます。

• その階層ブランチ全体のプリミティブの使用状況

• 階層の境界を横切るネットの数

• 階層で使用されるクロック

X-Ref Target - Figure 1-1

図 1‐1 : [Netlist] ウィンドウ

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xUsingTheNetlistWindow





デザインをフロアプランする場合、 Pblock に対して同様のプロパティが表示されます。


図 1‐2 : [Instance Properties] ウィンドウ





[Hierarchy] ウィンドウこのウィンドウでは、階層のリソースの使用量を理解できます。 [Hierarchy] ウィンドウを開くには、 [Tools] → [ShowHierarchy] をクリックするか、 [Netlist] ウィンドウで F6 キーを押します。

[Hierarchy] ウィンドウには、次の図に示すように、ネットリストの階層ツリーが表示されます。各行は、ネットリスト内の階層レベルを示します。下に行くほど、ネットリストの下位階層になります。各階層レベルは、そのレベルのほかの階層に相対したサイズで表示されます。

図 1-3 では、 cpuEngine、 usbEngine0、および usbEngine1 がデザインの大部分のロジックを占めており、おおよそ同じ数のリソースを使用していることが示されています。

使用率レポートは、デザインをリソースタイプごとに表示します。各リソースタイプ別に階層レベルごとの使用率を表示します。

リソース使用率レポートを表示するには、[Tools] → [Report] → [Report Utilization] をクリックします。9 ページの図 1-4に、リソース使用率レポートを示します。


図 1‐3 : [Hierarchy] ウィンドウ





このデザインでは、2 つの usbEngine ブロックにより RAMB36 および FIFO36 ブロックの大半が消費されています。プラス記号 (+) をクリックすると、下位階層でのリソース使用率を表示できます。

[Schematic] ウィンドウ回路図は、ネットリストのグラフィカル表示です。回路図を表示すると、次を実行できます。

• ネットリストをグラフィカルに表示します。

• ゲート、階層、および接続を確認します。

• ロジックコーンをたどったり展開したりします。

• デザインを解析します。

• デザインの内部をより理解しやすくなります。

エラボレート済みデザインの RTL レベルでは、ツールでコードがどのように解釈されたかを確認できます。合成済みデザインおよびインプリメント済みデザインでは、合成ツールで生成されたゲートを確認できます。


図 1‐4 : リソース使用率レポート





回路図を表示するには、 [Tools] → [Schematic] をクリックします。オブジェクトを選択していない場合は、デザインの上位のゲート、階層、および接続が表示されます (図 1-5)。

回路図の拡大/縮小および移動方法の詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 1] のこのセクションを参照してください。

ヒント : 1 つの階層レベルを選択すると、回路図がシンプルになります。選択したエレメントが青色でハイライトされ、 1 つの階層のポートが表示されます。


図 1‐5 : 上位回路図

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xUsingTheSchematicWindow





回路図では、次の操作を実行できます。

• 階層の左上にある [+] をクリックしてゲートを表示します。

• ポートまたはエレメントをダブルクリックして展開します。

• ポップアップメニューを使用します。

回路図の詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 1] のこのセクションを参照してください。

• 前の表示に戻ったり次の表示に進んだりするには、ツールバーの [Previous] (←) および [Next] (→) ボタンをクリックします。

• ツールバーの [Expand All] ボタンをクリックして、ロジックおよび接続をより詳細に表示します。

• ツールバーの [Collapse All] をクリックして、回路図を簡略化します。

インプリメンテーション後にタイミングパスのゲートを視覚的に確認するには、回路図がも簡単な方法です。パスを選択して回路図を開くと、そのパスのゲートとネットが表示されます。


図 1‐6 : 1 つの階層を選択した場合の回路図

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xUsingTheSchematicWindow





回路図で関連のある階層レベルを特定するには、右クリックして [Select Leaf Cell Parents] をクリックします。

[Highlight] および [Mark] コマンドを使用すると、関連のゲートが見やすくなります。 [Highlight] および [Mark] コマンドを使用してプリミティブを色分け表示すると、どのロジックが元のパスにあるか、どのロジックが追加されたかなどがわかりやすくなります。


図 1‐7 : タイミングパスの回路図


図 1‐8 : タイミングパスの回路図でプリミティブの親を選択






図 1‐9 :回路図でタイミングパスをマーク





[Find] ダイアログボックスを使用したオブジェクトの検索Vivado IDE には、優れた検索機能が含まれています。検索機能を使用するには、 [Edit] → [Find] をクリックします。次の図に示す [Find] ダイアログボックスが表示されます。

注記 : Ctrl+F キーを押しても [Find] ダイアログボックスを開くことができます。


図 1‐10 : [Find] ダイアログボックス





検索条件

[Find] ダイアログボックスを使用すると、さまざまな条件およびプロパティを設定してネットリストを検索できます。


図 1‐11 : [Find] ダイアログボックスでの検索条件の指定





検索例

[Edit] → [Find] を使用すると、たとえば次のものを検索できます。

• 未配置の I/O すべて

• ツールで配置されたグローバルクロック

• ファンアウトが 10,000 以上のネット

• PREG エンベデッドレジスタを使用する DSP

複数の条件を使用した検索

複数の条件を指定して検索を実行するには、次の手順に従います。

1. 初の検索条件を指定します。

2. [Properties] セクションの各行の右側にある [+] をクリックします。

3. 検索条件を追加します。

4. 検索条件の演算子 (AND または OR) を選択します。


図 1‐12 : [Find] ダイアログボックスでのプロパティオプションの指定





Tcl での検索

[Tcl Console] ウィンドウまたはスクリプトで実行している場合、検索には get_* コマンド (get_cells など) を使用します。

ヒント : Vivado IDE の下部に [Tcl Console] ウィンドウがあり、 GUI で実行された操作の Tcl コマンドが示されます。[Tcl Console] ウィンドウに Tcl コマンドを入力して実行できます。

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

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

デバイス使用率統計の解析インプリメンテーション問題のよくある原因は、ピン配置によるロジックおよびデバイスのレイアウトが考慮されていないことです。ほとんどのデバイスではスライスロジックは均一ですが、次のような特殊リソースがロジックの配置に影響します。

• I/O

• HP (High Performance) バンク

• HR (High Range) バンク

• MGT

• DSP48

• ブロック RAM

• MMCM

• BUFG

• BUFR

特定の特殊リソースを多数消費するブロックは、デバイス全体に分散する必要がある場合があります。デザインのほかの部分とのインターフェイスを設計する際、このことを考慮してください。次を組み合わせてブロックリソースを確認します。

• report_utilization

• ネットリストプロパティ

• Pblock プロパティ





DRC レポートデザインルールチェック (DRC) はデザインをチェックし、一般的な問題をレポートします。 DRC を実行するには、report_drc コマンドを使用します。インプリメンテーションでは、ツールで DRC が実行されます。配置配線後には、より完全で包括的な DRC が実行されます。

推奨 : DRC のクリティカル警告およびエラーをフローの初期段階で確認し、フローの後の方で問題が発生しないようにしてください。

合成済みデザインで [Report DRC] を実行すると、制約の適用されていない I/O に対してクリティカル警告が表示されます。配線済みデザインでも、クリティカル警告がレポートされます。レポートを確認してください。ビットストリーム生成の段階では、同じ DRC でエラーがレポートされます。 DRC レポートを早めに確認し、デザインで変更が必要な部分を特定するようにしてください。

設計手法 DRC の検証設計手法の重要性を考慮し、 Vivado ツールでは設計手法に従っているかどうかをチェックするデザインルールチェック (DRC) のセットが提供されています。デザインプロセスの段階によって、異なる DRC があります。 RTL リントスタイルチェックはエラボレート済み RTL デザインに対して実行され、ネットリストベースのロジックおよび制約チェックは合成済みデザインに対して実行され、インプリメンテーションおよびタイミングチェックはインプリメント済みデザインに対して実行されます。

Tcl プロンプトでこれらのチェックを実行するには、検証するデザインを開いて次の Tcl コマンドを入力します。

report_drc -ruledeck methodology_checks


図 1‐13 : DRC によるクリティカル警告およびエラー





IDE からこれらのチェックを実行するには、検証するデザインを開いて [Report DRC] コマンドを実行します。 [ReportDRC] ダイアログボックスが表示されたら、図 1-14 に示すように、[Rule decks] で [methodology_checks] を選択します。


図 1‐14 : [Report DRC] ダイアログボックス





違反が検出された場合は、次の図に示す [DRC] ウィンドウに表示されます。

設計手法 DRC の実行に関する詳細は、『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895)[参照 4] のこのセクションと『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949) [参照 5] のこのセクションを参照してください。


図 1‐15 : DRC 違反

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

http://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_ug949-vivado-design-methodology.pdf;a=xRunningMethodologyDRCs




第 2章

タイミング解析機能

タイミングサマリレポートタイミング解析は、合成後であればどの時点でも実行できます。合成およびインプリメンテーション run で自動的に生成されるタイミングサマリレポートを確認できます。

合成済みデザインまたはインプリメント済みデザインをメモリに読み込むと、次の方法でインタラクティブなタイミングサマリレポートを生成できます。

• Flow Navigator の [Synthesis] → [Synthesized Design] → [Report Timing Summary] をクリック

• Flow Navigator の [Implementation] → [Implemented Design] → [Report Timing Summary] をクリック

• [Tools] → [Timing] → [Report Timing Summary] をクリック

同等 Tcl コマンド : report_timing_summary

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

合成済みデザインでは、接続およびファンアウトに基づいてネット遅延が予測されます。セルがユーザーにより配置されていると、その間のネット遅延はより正確なものとなります。 I/O や GT などの一部のセルが事前に配置されているパスでは、クロックスキューが大きい可能性があります。

インプリメント済みデザインでは、ネット遅延は実際の配線情報に基づきます。タイミングサインオフには、完全に配線されたデザインを使用してください。デザインが完全に配線されているかどうかは、配線ステータスレポートで確認できます。

[Report Timing Summary] ダイアログボックス

[Report Timing Summary] ダイアログボックスには、次のタブがあります。

• 「[Options] タブ」

• 「[Advanced] タブ」

• 「[Timer Settings] タブ」

[Results name] は、 [Timing] ウィンドウに表示される結果のグラフィカルレポートの名前を指定します。グラフィカルレポートには、レポートのネットおよびセルから [Device] および [Schematic] ウィンドウ、デザインソースファイルにクロスプローブできるリンクがあります。

[Results name] に名前を入力しない場合、レポートは Tcl コンソールに表示され、グラフィカルレポートは表示されません。

同等 Tcl オプション : -name


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

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



第 2 章 : タイミング解析機能

[Options] タブ

[Report Timing Summary] ダイアログボックスの [Options] タブには、次のセクションがあります。

[Report] セクション

[Options] タブの [Report] セクションには、次のオプションがあります。

• [Path delay type]

実行する解析のタイプを設定します。合成済みデザインの場合、デフォルトでは大遅延解析 (セットアップ/ リカバリ ) のみが実行されます。インプリメント済みデザインの場合、デフォルトでは小/ 大遅延解析 (セットアップ/ホールド、リカバリ / リムーバル) の両方が実行されます。小遅延解析 (ホールドおよびリムーバル) のみを実行する場合は、 [min] を選択します。

同等 Tcl オプション : -delay_type


図 2‐1 : [Report Timing Summary] ダイアログボックス : [Options] タブ





• [Report unconstrained paths]

タイミング要件のないパスに関する情報を生成します。このオプションは、 Vivado IDE ではデフォルトでオンになっていますが、同等の Tcl コマンド report_timing_summary ではデフォルトでは使用されません。

同等 Tcl オプション : -report_unconstrained

• [Report datasheet]

51 ページの「データシートレポート」で説明されているデザインデータシートを生成します。

同等 Tcl オプション : -datasheet

[Path Limits] セクション

[Options] タブの [Path Limits] セクションには、次のオプションがあります。

• [Maximum number of paths per clock or path group] : クロックペアまたはパスグループごとにレポートするパスの大数を指定します。

同等 Tcl オプション : -max_paths

• [Maximum number of worst paths per endpoint] : パスの終点ごとにレポートするワーストパスの大数を指定します。これは、クロックペアまたはパスグループごとのパスの大数によって制限されます。そのため、レポートされるパスの総数は -max_paths で指定した数により制限されます。

同等 Tcl オプション : -nworst

[Path Display] セクション

[Options] タブの [Path Display] セクションには、次のオプションがあります。

• [Display paths with slack less than] : スラックが指定した値未満のパスをレポートします。このオプションは、サマリ表には影響しません。

同等 Tcl オプション : -slack_lesser_than

• [Significant digits] : レポートに表示される値の精度を指定します。

同等 Tcl オプション : -significant_digits

[Report Timing Summary] ダイアログボックスのすべてのタブに共通のセクション

次のオプションは、 [Report Timing Summary] ダイアログボックスのすべてのタブに共通です。

• [Command] : [Report Timing Summary] ダイアログボックスで指定されているオプションと同等の Tcl コマンドラインを表示します。

• [Open in a new tab] : 結果を新しいビューに表示するか、後に開いたビューを上書きするかを指定します。

• [Open in Timing Analysis layout] : [Timing Analysis] レイアウトを開きます。

このレイアウトの詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 1] のこのセクションを参照してください。

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xLayoutSelector

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xLayoutSelector





[Advanced] タブ

[Report Timing Summary] ダイアログボックスの [Advanced] タブには、次のセクションがあります。


図 2‐2 : [Report Timing Summary] ダイアログボックス : [Advanced] タブ





[Report] セクション

• [Report from cell] : デザインの特定のセルのタイミングのみをレポートします。指定したセルで開始または終了するパス、およびセルに完全に含まれるパスのみがレポートされます。

同等 Tcl コマンド : -cell

• [Show input pins in path] : パスに使用されるセルの入力ピンを表示します。

同等 Tcl オプション : -input_pins

推奨 : パスで使用されるすべてのピンに関してより詳細な情報を得るため、このオプションはオンにしてください。

• [Report unique pins] : ピンの各固有のセットに対して 1 つのタイミングパスのみを表示します。

同等 Tcl コマンド : -unique_pins

[File Output] セクション

• [Write results to file] : 結果を指定したファイルに書き込みます。デフォルトでは、レポートは Vivado IDE の[Timing] ウィンドウに表示されます。

同等 Tcl オプション : -file

• [Overwrite]/[Append] : レポートをファイルに記述する場合に、指定のファイルを上書きするか、新しい情報を既存のレポートの後に追加するかを指定します。

同等 Tcl オプション : -append

[Miscellaneous] セクション

• [Ignore command errors] : コマンドエラーを表示しません。コマンドをメッセージを表示せずに実行します。コマンドラインエラーは無視され、エラーメッセージは表示されません。実行中にエラーが発生してもしなくても、TCL_OK が返されます。

同等 Tcl オプション : -quiet

• プログラム実行中メッセージの制限を解除し、すべてのメッセージを表示します。メッセージの制限を一時的に解除し、コマンドからのすべての出力を返します。

同等 Tcl オプション : -verbose





[Timer Settings] タブ

タイマー設定を指定するには、 Vivado IDE のタイミング解析ダイアログボックス、またはこのセクションにリストされている Tcl コマンドのいずれかを使用します。これらの設定は、同じ Vivado IDE セッションで実行する合成およびインプリメンテーション以外のタイミング関連のコマンドに影響します。

タイマー設定はツールプリファレンスとしては保存されず、新しいセッションごとにデフォルト値に戻ります。デフォルト値を変更しないでください。デフォルト値では、も正確な遅延値が使用され、タイミング解析の適用範囲が大限になります。

[Report Timing Summary] ダイアログボックスの [Timer Settings] タブには、次のセクションがあります。


図 2‐3 : [Report Timing Summary] ダイアログボックス : [Timer Settings] タブ





[Interconnect Setting]

ネット遅延を下位セルピン間の予測配線距離に基づいて算出するか、実際に配線されたネットを使用して算出するか、またはタイミング解析から除外するかを指定します。

デフォルトでは、合成済みデザインの解析では [estimated] に、インプリメント済みデザインの解析では[actual] に設定されます。

° [estimated] : 未配置のセルの場合、ネット遅延値はドライバーおよびロード、ファンアウトの特性に基づく適な配置での遅延値になります。未配線の下位セルピン間のネットは、タイミングパスレポートでは「unplaced」と示されます。

配置済みセルの場合、ネット遅延はドライバーとロード間の距離およびファンアウトにより決まります。このネットは、タイミングパスレポートでは「estimated」と示されます。

° [actual] : 配線済みネットの場合、ネット遅延は配線されたインターコネクトの実際のハードウェア遅延になります。このネットは、タイミングパスレポートでは「routed」と示されます。

° [none] : タイミングレポートでインターコネクト遅延は考慮されず、ネット遅延は 0 になります。

同等 Tcl コマンド : set_delay_model

[Speed grade]

デバイスのスピードグレードを設定します。デフォルトでは、プロジェクトを作成する際やデザインチェックポイントを開く際に選択したデバイスに基づいて設定されます。

このオプションを使用すると、インプリメンテーションフローをすべて再実行しなくても、別のスピードグレードで同じデザインデータベースのタイミングをレポートできます。

同等 Tcl コマンド : set_speed_grade

[Multi‐Corner Configuration]

指定したタイミングコーナーを解析するパス遅延のタイプを指定します。有効な値は [none]、 [max]、 [min]、および [min_max] です。 [none] に設定すると、そのコーナーのタイミング解析は実行されません。

推奨 : 両方のコーナーでセットアップ ( 大) およびホールド ( 小) 解析の両方を実行してください。

同等 Tcl コマンド : config_timing_corners

• [Disable flight delays]

I/O 遅延の算出にパッケージ遅延を追加しません。

同等 Tcl コマンド : config_timing_analysis





タイミングサマリレポートの詳細

タイミングサマリレポートには、次のセクションが含まれます。

• 「[General Information] セクション」

• 「[Timer Settings] セクション」

• 「[Design Timing Summary] セクション」

• 「[Clock Summary] セクション」

• 「[Check Timing] セクション」

• 「[Intra-Clock Paths] セクション」

• 「[Inter-Clock Paths] セクション」

• 「[Path Groups] セクション」

• 「[User-Ignored Paths] セクション」

• 「[Unconstrained Paths] セクション」

タイミングサマリレポートには、 Vivado IDE で生成可能な複数のレポート ([Report Clock Interaction]、 [Report PulseWidth]、 [Report Timing]、 [Check Timing]) の情報、および report_clocks などの Tcl のみで生成可能なレポートと同様の情報が含まれますが、

制約の適用されていないパス (Unconstrained Paths) など、このレポートにしか含まれない情報もあります。

[General Information] セクション

タイミングサマリレポートの [General Information] セクションには、次の情報が含まれます。

• デザイン名

• 選択されたデバイス、パッケージ、スピードグレード (スピードファイルバージョン)

• Vivado Design Suite のバージョン

• 日付

• レポートを生成するために実行された同等の Tcl コマンド





[Timer Settings] セクション

レポートのタイミング情報を生成するのに使用された Vivado IDE タイミング解析エンジン設定の詳細を示します。図 2-4 に、 [Timer Settings] セクションのデフォルトオプションを示します。

• [Enable Multi-Corner Analysis] : マルチコーナー解析がイネーブルかどうかを示します。各コーナーの解析でどの解析が実行されたかは、 [Multi-Corner Configuration] に示されます。

• [Enable Pessimism Removal] および [Pessimism Removal Resolution] : 各パスのソースクロックおよびデスティネーションクロックで共通ノードでのスキューが削除されているかどうかを示します。

注記 : これらの設定は、常にイネーブルにする必要があります。

• [Enable Input Delay Default Clock] : ユーザー制約のない入力ポートにデフォルトのヌル入力遅延制約を作成しているかどうかを示します。このオプションは、デフォルトではオフになっています。

• [Enable Preset / Clear Arcs] : 非同期ピンを介したタイミングパスの伝搬がイネーブルかどうかを示します。リカバリ / リムーバルチェックには影響しません。デフォルトではオフになっています。

• [Disable Flight Delays] : I/O 遅延の算出でパッケージ遅延がディスエーブルかどうかを示します。

[Timer Settings] セクションのデフォルト設定とその変更方法は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] のこのセクションの「config_timing_analysis」を参照してください。


図 2‐4 : タイミングサマリレポート： [Timer Settings] セクション

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xconfig_timing_analysis





[Design Timing Summary] セクション

タイミングサマリレポートの [Design Timing Summary] セクション (図 2-5) は、デザインのタイミングのサマリを示します。ほかのセクションの結果が統合されています。

推奨 : [Design Timing Summary] セクションで、配線後にすべてのタイミング制約が満たされたか、デザインの現在のステータスを確認します。

[Design Timing Summary] セクションには、次のセクションがあります。

• 「[Setup] ( 大遅延解析)」

• 「[Hold] ( 小遅延解析)」

• 「[Pulse Width] (ピンスイッチ制限)」

[Setup] ( 大遅延解析)

大遅延解析 (セットアップ、リカバリ、およびデータチェック ) の結果を示します。

• [Worst Negative Slack (WNS)] : 大遅延解析におけるすべてのタイミングパスの悪のスラックを示します。この値は、正の場合と負の場合があります。

• [Total Negative Slack (TNS)] : 各タイミングパスの終点における悪の違反を考慮した場合の、 WNS 違反の合計を示します。この値は、次のようになります。

° 大遅延解析ですべてのタイミング制約が満たされている場合は 0ns になります。

° 違反がある場合は負の値になります。

• [Number of Failing Endpoints] : 違反が発生している (WNS < 0ns) 終点の総数を示します。 Translation Note: Included in the previous segment.

• [Total Number of Endpoints] : 解析された終点の総数を示します。

[Hold] ( 小遅延解析)

小遅延解析 (ホールド、リムーバル、およびデータチェック ) の結果を示します。

• [Worst Hold Slack (WHS)] : 小遅延解析におけるすべてのタイミングパスの悪のスラックを示します。この値は、正の場合と負の場合があります。

• [Total Hold Slack (THS)] : 各タイミングパスの終点における悪の違反を考慮した場合の、 WHS 違反の合計を示します。この値は、次のようになります。

° 小遅延解析ですべてのタイミング制約が満たされている場合は 0ns になります。


• [Number of Failing Endpoints] : 違反が発生している (WHS < 0ns) 終点の総数を示します。



図 2‐5 : タイミングサマリレポート : [Design Timing Summary] セクション





[Pulse Width] (ピンスイッチ制限)

ピンのスイッチ制限に関する次のチェックの結果を示します。

• 小 Low パルス幅

• 小 High パルス幅

• 小周期

• 大周期

• 大スキュー (PCIE や GT (UltraScale™ デバイスのみ) などの同じ下位セルの 2 つのクロックピン間)

次の値がレポートされます。

• [Worst Pulse Width Slack (WPWS)] : 小遅延および大遅延を使用した上記のすべてのチェックにおける悪のパルス幅スラックを示します。

• [Total Pulse Width Slack (TPWS)] : 各タイミングパスの終点における悪の違反を考慮した場合の、WPWS 違反の合計を示します。この値は、次のようになります。

° すべてのタイミング制約が満たされている場合は 0ns になります。


• [Number of Failing Endpoints] : 違反が発生している (WPWS < 0ns) 終点の総数を示します。


[Clock Summary] セクション

report_clocks コマンドを実行した場合と同様の情報が含まれます。

• create_clock コマンド、 create_generated_clock コマンド、またはツールで自動的に生成されたクロックすべてが表示されます。

• 名前、周期、波形、周波数要件などの各クロックのプロパティも示されます。

ヒント : 名前のインデントは、マスタークロックと生成クロックの関係を表します。

[Check Timing] セクション

不足しているタイミング制約や、制約に問題のあるパスに関する情報を示します。タイミングサインオフには、すべてのパスの終点に制約が設定されている必要があります。


図 2‐6 : タイミングサマリレポート： [Clock Summary] セクション





[Check Timing] セクションをスタンドアロンのレポートとして生成するには、次のいずれかを実行します。

• [Tools] → [Timing] → [Check Timing] をクリックします。

• Tcl の check_timing コマンドを実行します。

デフォルトで実行されるチェックは、次のとおりです (図 2-7)。

• no_input_delay : 入力遅延制約が設定されていない入力ポートをレポートします。

• no_output_delay : 出力遅延制約が設定されていない出力ポートをレポートします。

• unconstrained_internal_endpoints : 出力ポートを除く、タイミング要件がないパスの終点をレポートします。これは、 no_clock チェックでもレポートされる不足しているクロック定義にも直接関係しています。

• no_clock : 定義されたタイミングクロックが供給されていないクロックピンをレポートします。定数クロックピンもレポートされます。

• multiple_clock : 複数のタイミングクロックが到達するクロックピンをレポートします。この状況は、クロックツリーにクロックマルチプレクサーがある場合に発生します。

• generated_clocks : 同じクロックツリーにないマスタークロックソースを基準とする生成クロックをレポートします。

• loops : デザインで検出された組み合わせループをレポートします。ループは、タイミングをレポートするため Vivado IDE タイミングエンジンにより自動的に分離されます。

• partial_input_delay : 小入力遅延制約または大入力遅延制約のどちらかしか設定されていない入力ポートをレポートします。これらのポートは、セットアップ解析とホールド解析の両方にはレポートされません。

• partial_output_delay : 小出力遅延制約または大出力遅延制約のどちらかしか設定されていない出力ポートをレポートします。これらのポートは、セットアップ解析とホールド解析の両方にはレポートされません。

• latch_loops : デザインにシーケンシャルフィードバックループがあるかどうかをチェックします。

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


図 2‐7 : タイミングサマリレポート： [Check Timing] セクション





[Intra‐Clock Paths] セクション

ソースクロックとデスティネーションクロックが同じパスのタイミング値 (ワーストスラックおよび合計違反) を示します。

詳細情報を表示するには、左側のペインで [Intra-Clock Paths] の下の名前をクリックします。各クロックのスラックおよび違反のサマリ、および [Setup]、 [Hold]、 [Pulse Width] をクリックしてセットアップ、ホールド、パルス幅チェックの N 個のワーストパスに関する詳細を表示できます。 N の値は、コマンドラインで -max_paths オプションを使用するか、 GUI の [Maximum number of paths per clock or path group] で指定します。

ワーストスラック値およびレポートされたパスの数は、各解析タイプの右に表示されます (次の図を参照)。


図 2‐8 : タイミングサマリレポート： [Intra‐Clock Paths] セクション


図 2‐9 : タイミングサマリレポート： [Intra‐Clock Paths] セクションの詳細





[Inter‐Clock Paths] セクション

ソースクロックとデスティネーションクロックが異なるパスのタイミング値 (ワーストスラックおよび合計違反) を示します。

詳細情報を表示するには、左側のペインで [Inter-Clock Paths] の下の名前をクリックします。各クロックのスラックおよび違反のサマリ、および [Setup]、 [Hold]、 [Pulse Width] をクリックしてセットアップ、ホールド、パルス幅チェックの N 個のワーストパスに関する詳細を表示できます。 N の値は、コマンドラインで -max_paths オプションを使用するか、 GUI の [Maximum number of paths per clock or path group] で指定します。

[Path Groups] セクション

デフォルトのパスグループおよびユーザー定義のパスグループを表示します。次の図に、 [Path Groups] セクションのサマリ表の例を示します。この表を表示するには、左側のペインで [Path Groups] をクリックします。

ヒント : **async_default** は、 Vivado IDE タイミングエンジンで自動的に作成されたパスグループで、リカバリ / リムーバルのような非同期タイミングチェックで終わるすべてのパスが含まれます。これらのチェックは、 [Setup] (大遅延解析) および [Hold] ( 小遅延解析) に個別にレポートされます。 group_paths コマンドで作成したグループもすべてこのセクションに表示されます。ソースクロックおよびデスティネーションクロックはどの組み合わせでも、パスグループを構成できます。

[User‐Ignored Paths] セクション

set_clock_groups および set_false_path 制約により、タイミング解析で無視されたパスを表示します。レポートされるスラックは無限大です。


図 2‐10 : タイミングサマリレポート : [Inter‐Clock Paths] セクションの詳細


図 2‐11 : タイミングサマリレポート： [Path Groups] セクション





[Unconstrained Paths] セクション

制約がないために、タイミングが適用されていない論理パスを示します。これらのパスは、ソースおよびデスティネーションクロックペアごとに分類されます。パスの開始点または終点に関連付けられているクロックがない場合、クロック名情報は空 (NONE) になります。

タイミングパスの詳細の確認

ほとんどのセクションは、展開してクロックペアごとのパスの情報を表示できます。 [Setup]、 [Hold]、 [Pulse Width]サブセクションには、N 個のワーストパスが表示されます。これらのパスのいずれかを選択すると、その詳細が [PathProperties] ウィンドウの [Report] ビューに表示されます。

パスをダブルクリックすると、同じ詳細情報が新しいウィンドウに表示されます。

タイミングパスの詳細は、第 5 章「タイミング解析の実行」を参照してください。


図 2‐12 : タイミングサマリレポート： [User‐Ignored Paths] セクション


図 2‐13 : タイミングサマリレポート : [Unconstrained Paths] セクション





各パスをさらに解析するには、次の手順に従います。

1. 右側のペインでパスを右クリックします。

2. ポップアップメニューから次のいずれかをクリックします。

° [Schematic] : パスの回路図を表示します。

° [Report Timing on Source to Destination] : パスのタイミング解析を再実行します。

° [Highlight] : [Device] および [Schematic] ウィンドウでパスをハイライトします。

違反のあるパスのみを表示

タイミングが満たされていないパスのスラック値は、レポートで赤で表示されます。ツールバーの [Show only failingpaths] ボタンをクリックしてオンにすると、これらの違反のみを表示できます。

次の図に、タイミング違反のあるパスのみを表示したタイミングサマリレポートの例を示します。

クロックネットワークレポート[Report Clock Network] コマンドは、次の方法で実行できます。

• Vivado IDE の Flow Navigator から

• 次の Tcl コマンドを実行

report_clock_networks -name {network_1}

[Report Clock Networks] を実行すると、デザインのクロックがツリー表示で示されます (図 2-15)。各クロックツリーにはソースから終点までのクロックネットワークが示され、終点のタイプごと並べられます。


図 2‐14 : タイミングサマリレポート：違反のあるパスのみを表示





クロックツリーには、次の特徴があります。

• ユーザー定義またはツールで自動的に生成されたクロックを表示

• I/O ポートからロードまでのクロックをレポート

注記 :完全なツリーの詳細は GUI のレポートでのみ表示されます。このレポートのテキスト版には、クロックルートの名前のみが表示されます。

• BUFG を駆動する BUFG の検索に使用可能

• クロックでないロードを駆動するクロックを表示

デザインで定義されている各プライマリクロックおよび生成クロックを含むフォルダーが表示されます。制約が適用されていないクロックルートは、別のフォルダーに表示されます。

ツールバーの [Filter Ports]、 [Filter Net]、 [Filter Cell]、 [Filter Input Pins]、 [Filter Output Pins] ボタンを使用して、クロックツリーに表示される情報を限定できます。


図 2‐15 : クロックネットワークレポート





クロックパスの回路図を表示するには、次の手順に従います。

1. ツリーでオブジェクトを右クリックします。

2. [Trace to Source] をクリックします。

クロック関連性レポートクロック関連性レポートを表示するには、次のいずれかをクリックします。

• メインメニューから [Tools] → [Timing] → [Report Clock Interaction]

• Flow Navigator の [Synthesis] → [Synthesized Design] → [Report Clock Interaction]

• Flow Navigator の [Implementation] → [Implemented Design] → [Report Clock Interaction]

同等 Tcl コマンド : report_clock_interaction -name clocks_1

[Report Clock Interaction] ダイアログボックス

[Report Clock Interaction] ダイアログボックスには、次のフィールド、チェックボックス、およびタブがあります。

• 「[Results name] フィールド」

• 「[Command] フィールド」

• 「[Open in a new tab] チェックボックス」

• 「[Options] タブ」

• 「[Timer Settings] タブ」

[Results name] フィールド

グラフィカルレポートの名前を指定します。


[Command] フィールド

[Report Clock Interaction] ダイアログボックスで指定されているオプションと同等の Tcl コマンドラインを表示します。

[Open in a new tab] チェックボックス

結果を新しいビューに表示するか、後に開いたビューを上書きするかを指定します。





[Options] タブ

[Report Clock Interaction] ダイアログボックスの [Options] タブには、次のフィールドがあります。

• 「[Delay type]」

• 「[Significant digits]」

• 「[File Output] セクション」

[Delay type]

実行する解析のタイプを設定します。

• 合成済みデザインの場合、デフォルトでは大遅延解析 (セットアップ/ リカバリ ) のみが実行されます。

• インプリメント済みデザインの場合、デフォルトでは小/ 大遅延解析 (セットアップ/ホールド、リカバリ / リムーバル) の両方が実行されます。

小遅延解析 (ホールドおよびリムーバル) のみを実行する場合は、 [min] を選択します。

同等 Tcl オプション : -delay_type

[Significant digits]

レポートされる値の有効桁数を指定します。デフォルト値は 3 です。



図 2‐16 : [Report Clock Interaction] ダイアログボックス : [Options] タブ






[File Output] セクションには、次のオプションがあります。

• [Write results to file] : 結果を指定したファイルに書き込みます。 Vivado IDE では、レポートは [Clock Interaction]ウィンドウに表示されます。





このタブの詳細は、 26 ページの「[Timer Settings] タブ」を参照してください。

クロック関連性レポートの詳細

クロック関連性レポートは、あるクロックドメイン (ソースクロック ) から別のクロックドメイン (デスティネーションクロック ) へのタイミングパスを解析します。データ損失やメタステーブル状態などの問題を特定するのに役立ちます。

[Report Clock Interaction] コマンドを実行すると、結果が [Clock Interaction] ウィンドウに表示されます。クロック関連性レポートには、次の図に示すように、信号のソースクロックドメインを縦軸、デスティネーションクロックドメインを横軸に、クロックドメインのマトリックスが表示されます。





マトリックスセルの色分け

マトリックスのセルは、色分け表示されます。セルの色は、 [Tools] → [Options] をクリックして表示される [VivadoOptions] ダイアログボックスの [Colors] ページの [Graphical Editors] の下で指定されている背景色によって異なります。詳細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 1] のこのセクションを参照してください。色の凡例を非表示にするには、 [Clock Interaction] ウィンドウのツールバーで [Show/Hide Legend] (?) をクリックします。

• No Path (黒) : ソースクロックからデスティネーションクロックまでにドメインをまたがるタイミングパスが存在しないことを示します。クロックに関連性はなく、何もレポートされません。

• Timed (緑) : ソースクロックとデスティネーションクロックに同期関係があり、タイミング制約が正しく設定されていることを示します。この状態は、 2 つのクロックのプライマリクロックが共通しており、クロック周期が単純な比である場合に、タイミングエンジンにより判断されます。

• User Ignored Paths (紺色) : ソースクロックからデスティネーションクロックまでのドメインをまたがるパスすべてにユーザー定義の false_path またはクロックグループ制約が適用されていることを示します。


図 2‐17 : クロック関連性レポート

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xSpecifyingColors





• Partial False Path (水色) : ソースクロックからデスティネーションクロックまでのドメインをまたがるパスの一部にユーザー定義の false_path が適用されており、ソースクロックとデスティネーションクロックに同期関係があることを示します。

• Timed (Unsafe) (赤) : ソースクロックとデスティネーションクロックが非同期であることを示します。プライマリクロックが共通でないか、周期の公倍数を見つけることができません。非同期クロックおよび周期の公倍数がないクロックの詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] のこのセクションを参照してください。

• Partial False Path (Unsafe) (オレンジ色) : [Timed (Unsafe)] と同じですが、ソースクロックからデスティネーションクロックへの少なくとも 1 つのパスがフォルスパス例外のため無視されていることを示します。

• Max Delay Datapath Only (グレー) : ソースクロックからデスティネーションクロックまでのドメインをまたがるパスすべてに set_max_delay -datapath_only が適用されていることを示します。

重要 : マトリックスのセルの色は、クロックドメイン間の制約の状態を表しており、クロックドメイン間のタイミングパスのワーストスラックの状態を表すものではありません。緑色のセルはタイミングが満たされていることを示しているのではなく、クロックドメイン間のタイミングパスに正しく制約が適用されており、クロック間に既知の位相関係があることを示します。

表示されるクロックの選択

[Clock Interaction] ウィンドウに表示されるクロックを選択するには、次の手順に従います。

1. ツールバーの [Clock Interaction Options] をクリックします。

2. 表示するクロックをオンにします。

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug903-vivado-using-constraints.pdf;a=xAsynchronousClockGroups





これにより、表示されるクロック数は減りますが、マトリックスの下の表にレポートされるクロック関連性の数は減りません。また、ツールバーの [Hide unused clocks] ボタンをクリックすると、デザインの論理パスに直接供給されないクロックの表示/非表示を切り替えることができます。これらのクロックは WNS/TNS/WHS/THS の算出には使用されないので、デフォルトでは非表示になっています。

クロックペアのスラックを示す表

マトリックスの下の表には、ソース /デスティネーションクロックペアに対するセットアップ/ リカバリまたはホールド / リムーバルのタイミングスラックの概要が示されます。ワーストパスのパス要件、共通プライマリクロック、および制約の状態に関する有益な情報も表示されます。41 ページの図 2-17を参照してください。この表には、マトリックスには示されない詳細な情報が表示されます。

データの並べ替え

表のデータは、列ヘッダーを 1 回クリックすると昇順に、もう 1 回クリックすると降順に並べ替えられます。

セルおよび行の選択

マトリックスでセルを選択すると、下の表で対応する行が選択されます。

表で行を選択すると、上のマトリックスで対応するセルがハイライトされます。

表の列

表には、次の列があります。

• [Id] : 表示されているソース /デスティネーションクロックペアの識別番号を示します。

• [Source Clock] : パスが開始するクロックドメインを示します。


図 2‐18 : [Clock Interaction] ウィンドウに表示されるクロックの選択





• [Destination Clock] : パスが終了するクロックドメインを示します。

• [Edges (WNS)] : 大遅延解析 (セットアップ/ リカバリ ) のワーストネガティブスラックの算出に使用されたクロックエッジを示します。

• [WNS] : クロックドメイン間のさまざまなパスのワーストケースのスラックを表示します。負のスラック値は、パスでセットアップまたはリカバリタイム違反が発生していることを示します。

• [TNS] : クロックドメイン間のパスに属するすべての終点におけるワーストスラック違反の合計を示します。

• [Failing Endpoints (TNS)] : クロックドメイン間のパスのタイミングが満たされていない終点の数を示します。違反の合計は、 TNS に対応します。

• [Total Endpoints (TNS)] : クロックドメイン間のパスの終点の総数を示します。

• [Path Req (WNS)] : [WNS] 列にレポートされているパスのタイミングパス要件を示します。 2 つのクロックの少なくともどちらかで立ち上がりエッジおよび立下りエッジの両方がアクティブである場合はクロックペア間に複数のパス要件がある可能性があり、また 2 つのクロック間のパスにタイミング例外が適用されている場合もあります。この列にレポートされる値が、も厳しい要件であるとは限りません。

詳細は、 131 ページの「パス要件」を参照してください。

• [Common Primary Clock] : タイミングパスのソースクロックとデスティネーションクロックが共通のプライマリクロックで定義されているかどうかを示します。タイミングパスのソースクロックまたはデスティネーションクロックのいずれかが仮想クロックを基準にしている場合、 [Common Primary Clock] フィールドに「Virtual」と表示されます。

• [Inter-Clock Constraints] : ソースクロックとデスティネーションクロック間のすべてのパスの制約サマリを示します。可能な値は、 41 ページの「マトリックスセルの色分け」にリストされています。次は、これらの制約の定義例です。

set_clock_groups -async -group wbClk -group usbClkset_false_path -from [get_clocks wbClk] -to [get_clocks cpuClk]

小遅延解析も選択されている場合 (ホールド / リムーバル)、次の列も表示されます。

• [Edges (WHS)] : ワーストホールドスラックの算出に使用されたクロックエッジを示します。

• [WHS] : クロックドメイン間のさまざまなパスのワーストケースのスラックを表示します。負のスラック値は、パスでホールドまたはリムーバルタイム違反が発生していることを示します。

• [THS] : 小遅延解析 (ホールド / リムーバル) 用に、クロックドメイン間のパスに属するすべての終点におけるワーストスラック違反の合計を示します。

• [Failing Endpoints (THS)] : クロックドメイン間のパスのタイミングが満たされていない終点の数を示します。違反の合計は、 THS に対応します。

• [Total Endpoints (THS)] : 小遅延解析 (ホールド / リムーバル) 用に、クロックドメイン間のパスの終点の総数を示します。

• [Path Req (WHS)] : [WHS] 列にレポートされているパスのタイミングパス要件を示します。 WNS と同様、 2 つのクロック間の小遅延解析用に複数のパス要件がある場合があり、この列にレポートされる値がも厳しい要件であるとは限りません。

詳細は、第 5 章「タイミング解析の実行」を参照してください。

表で 1 つまたは複数のクロックペアを選択できます。選択したソース /デスティネーションクロックペアを右クリックすると、 [Report Timing] を実行できます。

表のエクスポート

[Export to Spreadsheet] を実行すると、表を XLS ファイルに出力し、スプレッドシートで使用できます。





パルス幅レポート[Report Pulse Width] コマンドは、各インスタンスクロックピンで小周期、大周期、 High パルス時間、 Low パルス時間の要件が満たされているかどうかをチェックします。また、 PCIe® クロックなど、インプリメント済みデザインの同じインスタンスの 2 つのクロックピン間で大スキュー要件が満たされているかもチェックします。パルス幅のスラック式には、ジッターまたはクロックのばらつきは含まれません。

同等 Tcl コマンド : report_pulse_width

注記 : ISE® では、このチェックはコンポーネントスイッチ制限と呼ばれています。interaction

タイミングレポート[Report Timing] を使用すると、合成後の任意の段階で、特定のタイミングパスを解析できます。タイミングサマリレポートでレポートされたタイミング問題を調査する場合や、特定のタイミング制約の有効性および適用範囲を確認する場合に使用できます。 [Report Timing] にはパルス幅レポートは含まれません。

[Report Timing] の実行

デザインがメモリに読み込まれていれば、メニュー、クロック関連性レポート、タイミングレポート、またはタイミングサマリレポートのパスリストから [Report Timing] を実行できます。

メニューからの [Report Timing] の実行

メニューから [Report Timing] を実行するには、 [Tools] → [Timing] → [Report Timing] をクリックします。

クロック関連性レポートからの [Report Timing] の実行

クロック関連性レポートから [Report Timing] を実行するには、次の手順に従います。

1. ソースクロックとデスティネーションクロックのペアを選択します。

2. 右クリックして [Report Timing] をクリックし、選択したクロック間のレポートを生成します。


図 2‐19 :パルス幅レポート





パスリストからの [Report Timing] の実行

パスリストから [Report Timing] を実行するには、次の手順に従います。

1. パスを選択します。

2. 右クリックして [Report Timing] をクリックし、選択したパスのレポートを生成します。

同等 Tcl コマンド : report_timing

[Report Timing] ダイアログボックスでオプションを設定すると、次の場所に同等の report_timing コマンド構文が表示されます。

• [Report Timing] ダイアログボックスの [Command] フィールド

• 実行後に [Tcl Console] ウィンドウ

次のセクションで、ダイアログボックスの各オプションについて説明し、同等の report_timing コマンドのオプションを示します。

[Report Timing] ダイアログボックスのオプションは、[Report Timing Summary] ダイアログボックスのオプションとほぼ同じですが、追加のフィルターオプションがいくつかあります。





[Report Timing] ダイアログボックス

[Targets] タブ


図 2‐20 : [Report Timing] ダイアログボックス : [Targets] タブ





特定のパスまたはパスのグループのレポートを生成するため、いくつかのフィルターオプションがあります。これらのフィルターは、タイミングパスの構造に基づきます。

• [Start Points] ([From]) : シーケンシャルセルクロックピン、シーケンシャルセル、入力ポート、双方向ポート、ソースクロックなど、開始点をリストします。

複数の開始点をリストした場合、それらのネットリストオブジェクトのいずれかから開始するすべてのパスがレポートされます。

[Transition] では、特定のソースクロックエッジ (立ち上がり /立ち下がり ) を選択します。

同等 Tcl オプション : -from、 -rise_from、 -fall_from

• [Through Point Groups] ([Through]) : パスが通過するピン、ポート、組み合わせセル、またはネットのリストを指定します。

複数のネットリストオブジェクトをリストすると、そのいずれかを通過するパスがレポートされます。

[+] ボタンをクリックして複数の [Through] オプションを指定すると、それらすべての通過点を指定した順に通過するパスをレポートできます。

[Transition] では、特定のデータエッジ (立ち上がり /立ち下がり ) を選択します。

推奨 : [Transition] はデフォルトのままにします。

同等 Tcl オプション :-through、 -rise_through、 -fall_through

• [End Points] ([To]) : シーケンシャルセルの入力データピン、シーケンシャルセル、出力ポート、双方向ポート、デスティネーションクロックなど、終点をリストします。

複数の終点をリストした場合、それらのネットリストオブジェクトのいずれかで終了するすべてのパスがレポートされます。

[Transition] では、通常特定のデータエッジ (立ち上がり /立ち下がり ) を選択しますが、デスティネーションクロックを指定した場合は、特定のクロックエッジを選択します。

同等 Tcl オプション : -to、 -rise_to、 -fall_to

[Report Timing] ダイアログボックスの [Targets] タブ (47 ページの図 2-20) では、 usbClk の立ち上がりクロックエッジから、 cpuEngine/or1200_cpu/sprs_dataout[*] ネットのいずれかを通過し、 cpuClk または sysClk のいずれかのエッジで終了するパスを指定しています。

[Options] タブ

[Options] タブには、次のオプションがあります。

• 「[Report]」

• 「[Path Limits]」

• 「[Path Display]」

[Report]

• [Path delay type] : 22 ページの「[Path delay type]」を参照してください。

• [Do not report unconstrained paths] : デフォルトでは、 [Targets] タブで指定されたパスに制約されているものがない場合、制約されていないパスがレポートされます。制約されていないパスをレポートに含めないようにする場合は、このオプションをオンにします。

同等 Tcl オプション : -no_report_unconstrained





[Path Limits]

• [Number of paths per group] : 21 ページの「タイミングサマリレポート」を参照してください。

• [Number of paths per endpoint] : 21 ページの「タイミングサマリレポート」を参照してください。

• [Limit paths to group] : [Targets] タブで指定した条件に一致するパスで、指定したタイミングパスグループに属するもののみをレポートします。各クロックは、グループに関連付けられています。 Vivado IDE タイミングエンジンでは、デフォルトでグループが作成されます。たとえば、 **async_default** はリカバリまたはリムーバルタイミングチェックで終了するすべてのパスのグループです。

同等 Tcl オプション : -group

[Path Display]

• [Display paths with slack greater than] : スラックが指定した値より大きいパスをレポートします。

同等 Tcl オプション :-slack_greater_than

• [Display paths with slack less than] : 21 ページの「タイミングサマリレポート」を参照してください。

• [Number of significant digits] : 21 ページの「タイミングサマリレポート」を参照してください。

• [Sort paths by] : レポートされたパスをグループごとに表示するか (デフォルト )、スラック順に表示するかを選択します。 [group] を選択すると、各グループおよび各解析タイプ (-delay_type min/max/min_max) に対してN 個のワーストパスがレポートされます。

グループは、ワーストパス順に並べられ、違反が悪のグループがリストの一番上に表示されます。 [slack] を選択すると、各解析タイプに対して N 個のワーストパスがレポートされ (すべてのグループを統合)、スラック順に並べられます。

同等 Tcl オプション : -sort_by

[Advanced] タブ

[Advanced] タブには 21 ページの「タイミングサマリレポート」と同じオプションがあります。


[Timer Settings] タブには 21 ページの「タイミングサマリレポート」と同じオプションがあります。

タイミングパスの詳細の確認

[OK] をクリックするとコマンドが実行され、 [Timing] ウィンドウの新しいビューに結果が表示されます。選択した各解析 (min/max/min_max) に対して N 個のワーストパスがレポートされます。

次の図に、大遅延解析および小遅延解析の両方 (SETUP および HOLD) を選択し、 N = 4 に設定した場合のタイミングレポートを示します。





これらのパスのいずれかを選択すると、その詳細が [Path Properties] ウィンドウの [Report] ビューに表示されます。


図 2‐21 : タイミングレポートのパスリスト


図 2‐22 : [Path Properties] ウィンドウ





パスをダブルクリックすると、同じ詳細情報が新しいウィンドウに表示されます。

タイミングパスの詳細は、第 5 章「タイミング解析の実行」を参照してください。

パスを右クリックして次のコマンドをクリックすると、パスの解析に有益です。

• [Schematic] : タイミングパスを回路図で表示します。

• [Report Timing on Source to Destination] : パスのタイミング解析を再実行します。

• [Highlight] : [Device] および [Schematic] ウィンドウでパスをハイライトします。

違反のあるパスのみを表示

タイミングが満たされていないパスのスラック値は、レポートで赤で表示されます。ツールバーの [Show only failingpaths] をクリックしてオンにすると、これらの違反のみを表示できます。

データシートレポート[Report Datasheet] コマンドを使用すると、システムレベルの統合で使用する FPGA デバイスの動作パラメーターがレポートされます。

[Report Datasheet] ダイアログボックス

Vivado IDE で、[Tools] → [Timing] → [Report Datasheet] をクリックし、[Report Datasheet] ダイアログボックス (図 2-23)を開きます。





[Report Datasheet] ダイアログボックス : [Options] タブ


図 2‐23 : [Report Datasheet] ダイアログボックス : [Options] タブ





[Report Datasheet] ダイアログボックスの [Options] タブには、次のオプションがあります。

• [Results name] : 表示される結果の名前を指定します。レポートは、 [Timing] ウィンドウに指定の名前で表示されます。


• [Sort by] : 結果をポート名またはクロック名順に並べ替えます。

同等 Tcl オプション : -sort_by

• [Report all process corners separately] : 現在のデザインで定義されているすべてのプロセスコーナーのデータをレポートします。

同等 Tcl オプション : -show_all_corners

• [Significant digits] : レポートされる値の有効桁数を指定します。デフォルト値は 3 です。


• [Write results to file] : 結果を指定したファイルに書き込みます。デフォルトでは、レポートは Vivado IDE の[Timing] ウィンドウに表示されます。




• [Ignore command errors] : コマンドをメッセージを表示せずに実行します。コマンドラインエラーは無視され、エラーメッセージは表示されません。実行中にエラーが発生してもしなくても、 TCL_OK が返されます。


• [Suspend message limits during command execution] : メッセージの制限を一時的に解除し、コマンドからのすべての出力を返します。


• [Command] : [Report Datasheet] ダイアログボックスで指定されているオプションと同等の Tcl コマンドラインを表示します。

• [Open in a new tab] : 結果を新しいビューに表示するか、後に開いたビューを上書きするかを指定します。

• [Open in Timing Analysis layout] : [Timing Analysis] レイアウトを開きます。





[Report Datasheet] ダイアログボックス : [Groups] タブ

[Report Datasheet] ダイアログボックスの [Groups] タブでは、基準ポートおよびレポートする追加のポートを指定することにより、解析用にポートをグループ化できます。グループを指定しない場合は、ソースクロックに基づいて出力ポートのグループが自動的に検出され、そのクロックに基づくスキューがレポートされます。

[Report Datasheet] ダイアログボックスの [Groups] タブには、次のオプションがあります。

• [Reference] : スキュー算出用の基準ポートを指定します。ほとんどの場合、これはソース同期出力インターフェイスのクロックポートです。

同等 Tcl オプション : -group

• [Ports] : レポートする追加のポートを指定します。

° [Ports] フィールドの右側に、 [+] および [-] ボタンがあります。

- [+] : それぞれ基準クロックポートを持つ複数のグループを指定し、新しい基準ポートを含む新しいグループを定義できます。

- [-] : ポートのグループを削除します。

[Report Datasheet] ダイアログボックス :[Timer Settings] タブ

このタブの詳細は、 26 ページの「[Timer Settings] タブ」を参照してください。


図 2‐24 : [Report Datasheet] ダイアログボックス : [Groups] タブ





データシートレポートの詳細

[General Information]

デザインおよびザイリンクスデバイスの詳細、レポート生成時のツール環境を示します。

• Design : デザイン名

• Part : ターゲットザイリンクスパーツとスピードファイル情報

• [Version] :レポートの生成に使用された Vivado ツールのバージョン

• Date:レポートが生成された日時

• [Command] :レポートの生成に使用されたコマンドラインオプション

[Input Ports Setup/Hold]

各入力ポートの基準クロックに対するワーストケースのセットアップおよびホールド要件を示します。入力データのキャプチャに使用された内部クロックもレポートされます。

[Max/Min Delays for Output Ports]

各出力ポートの基準クロックに対するワーストケースの大および小遅延を示します。出力データの送信に使用された内部クロックもレポートされます。

[Setup between Clocks]

各クロックペアに対し、クロックエッジのすべての組み合わせのワーストケースのセットアップ要件を示します。

[Setup/Hold for Input Buses]

自動的に推論された入力バスのワーストケースのセットアップおよびホールド要件を示します。バス全体のワーストケースデータウィンドウは、大のセットアップおよびホールド値の合計です。入力ポートが制約されている場合は、スラックもレポートされます。

IDELAY が定義されている入力クロックに対しては、適なタップポイントがレポートされます。適なタップポイントは、バランスのとれたセットアップおよびホールドスラックを得るために IDELAY を設定するのに使用できます。

ソースオフセットは、 2 つのウィンドウの差です。初のウィンドウは、入力ポートのクロックに対すセットアップおよびホールドタイムで定義されます。 2 つ目のウィンドウは、入力遅延およびクロック周期から算出されます。入力クロックがこの値でオフセットされると、ウィンドウの中央になります。

次の図に、DDR 入力バス dq[0-7] を含み、ワーストケースのデータウィンドウが 8.150ns であるデザインのレポートを示します。理想的なクロックオフセットは 0.179 ns です。 IDELAY の適なタップポイントは 13 です。適なタップポイントは、次の Tcl コマンドを使用して適用できます。

set_property IDELAY_VALUE 13 [get_cells idelay_clk]





[Max/Min Delays for Output Buses]

自動的に推論された出力バスのワーストケースの大および小遅延を示します。バススキューもレポートされます。バススキューの算出では、1 ビットを基準とし、そのビットに対してほかのビットのオフセットが算出されます。ワーストオフセットがバス全体のスキューとなります。

[Max/Min Delays for Groups]

ソース同期出力インターフェイスでは、出力スキューはフォワードクロックに対して必要です。カスタムグループレポートは、基準ポートをフォワードクロックポートとして指定すると生成できます。この表は [Max/Min Delays forOutput Buses] セクションと似ていますが、ソースオフセットおよびバスキューの算出に基準ポートが基準ビットとして使用されます。

注記 : このセクションは、空の場合は非表示になっていることがあります。

たとえば、 DDR 出力スキューの算出では、複数のビット (rldii_a[0-19]、 rldii_ba[0-3]、 rldii_ref_n、rldii_we_n) をフォワードクロックポート (rldii_ck_n[0]) に対してグループ化する場合、次のコマンドを使用します。

report_datasheet -group [get_ports {rldii_ck_n[0] rldii_a[*] rldii_ba[*] rldii_ref_n rldii_we_n}] -name timing_1

グループリストの初のポートが基準ピンです。

これらすべてのセクションで、ワーストケースのデータはマルチコーナー解析から算出されます。-show_all_corners を使用すると、ワーストケースのデータは各コーナーに対して個別にレポートされます。

次の図に、この例のデータシートレポートを示します。


図 2‐25 :データシートレポートの [Setup/Hold for Input Buses] セクション





例外レポート例外レポートは、合成後のフローのどの段階でも生成できます。例外レポートには、次の情報が含まれます。

• デザインで設定され、タイミング解析に影響するタイミング例外すべて

• デザインで設定されているが、ほかのタイミング例外が優先されるために無視されるタイミング例外すべて

例外レポートの生成時に解析されるタイミング例外は、次のとおりです (優先度の高い順にリスト )。

• フォルスパス

• 大/ 小遅延

• マルチサイクルパス

例外レポートは、タイミング例外に関する問題をデバッグするのに役立ちます。デザインによっては、複雑なタイミング例外を使用したタイミング制約を含むものがあります。タイミング例外の優先度は異なるので、どのタイミング例外がほかの例外のために一部または完全に無視されるのかを理解するのは困難です。例外レポートには、一部が無


図 2‐26 :データシートレポートの大/ 小遅延の例





視されるタイミング例外および完全に無視されるタイミング例外がレポートされます。また、優先される制約に関するヒントも表示されます。

クロックグループ制約 (set_clock_groups) は厳密にはタイミング例外ではないので、デザインに影響するタイミング例外のサマリ表には含まれませんが、あるタイミング例外がクロックグループ制約のために無視される場合は、優先されるクロックグループ制約が表の [Status] 列にレポートされます。

例外レポートは、 Tcl コマンドラインで report_exceptions コマンドを使用してのみ生成可能です。

report_exceptions のコマンドラインオプションの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] のこのセクションを参照してください。タイミング例外の優先順位に関する詳細は、『VivadoDesign Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] のこのセクションを参照してください。

report_exception コマンドには、次の 3 つの操作モードがあります。

• タイミング解析に影響するタイミング例外のレポート

• 無視されるタイミング例外のレポート

• タイミング例外の適用範囲のレポート

例 : タイミング解析に影響するタイミング例外のレポート

この例では、次の図に示すデザインにタイミング例外を適用する方法を示します。デザインには、完全に制約されています (clk と入力/出力遅延を clk に対して設定)。


図 2‐27 : タイミング例外の例で使用する完全に制約されたデザイン

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xreport_exceptions

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug903-vivado-using-constraints.pdf;a=xXDCPrecedence





report_exception コマンドの 1 つ目の操作モードは、「report_exception」です。

1. [Window] → [Timing Constraints] をクリックします。

2. [Timing Constraints] ウィンドウで次のタイミング例外をデザインに追加します。

set_multicycle_path 3 -from [get_cell int10_reg] -to [get_cell int20_reg]set_multicycle_path 4 -to [get_cell int20_reg]set_false_path -from [get_ports in6] -to [get_cell int20_reg]set_false_path -to [get_ports out5] set_false_path -to [get_cell int21_reg]set_false_path -from [get_ports in6] -to [get_ports out6]set_max_delay 5 -to [get_ports out6]set_min_delay 3 -from [get_cells int10_reg] -to [get_cell int20_reg]

[Timing Constraints] ウィンドウに、デザインに適用されたタイミング制約が表示されます。

実際の例外レポート (report_exception) を次の図に示します。

例外レポートには、次の情報が表示されます。

• [Position] 列 : 制約の位置番号を示します。これは、 [Timing Constraint] ウィンドウでレポートされるのと同じ番号です (59 ページの図 2-28)。

• [From]、 [Through]、 [To] 列 : -*from/-*through/-*to コマンドラインオプションで指定したパターンまたはオブジェクトを示します (これらのオプションの rise/fall バージョンもすべて含む)。関連するオプションが指定されていない場合は、アスタリスク (*) が表示されます。


図 2‐28 : タイミング制約の変更を表示する [Timing Constraints] ウィンドウ


図 2‐29 :例外レポート





• [Setup]、[Hold] 列 : 制約がセットアップチェックまたはホールドチェックのいずれかまたは両方に適用されるかどうかを示します。 [Setup]、 [Hold] 列の命名規則は、次のとおりです。

• [Status] 列 : 制約が別のタイミング例外により一部無視されている場合にメッセージを表示します。 [Status] 列の命名規則は、次のとおりです。

注記 : クロックグループは、 report_timing -ignored コマンドを実行したときに、クロックグループに制約により別のタイミング例外が無視される場合に [Status] 列にレポートされます。

この例では、一部無視される制約に関するメッセージが 2 つ表示されます。

• タイミング制約位置番号 5 ([Timing Constraints] ウィンドウの set_multicycle_path 4 -to [get_cellint20_reg]) は、マルチサイクル制約位置番号 4 (set_multicycle_path 3 -from [get_cellint10_reg] -to [get_cell int20_reg]) とフォルスパス制約位置番号 6 (set_false_path -from[get_ports in6] -to [get_cell int20_reg]) により一部が無視されます。

• タイミング制約位置番号 10 (set_max_delay 5 -to [get_ports out6]) は、フォルスパス位置番号 9(set_false_path -from [get_ports in6] -to [get_ports out6]) により一部が無視されます。

無視されるタイミング例外のレポート

report_exception コマンドの 2 つ目の操作モードは、「report_exception -ignored」です。

これを示すため、次のタイミング例外を前の例外の上に追加してみます。

set_max_delay 5 -to [get_ports out5]set_multicycle_path 1 -hold -to [get_cell int21_reg]set_multicycle_path 2 -setup -to [get_ports out6]set_false_path -from [get_cell int11_reg] -to [get_cell int20_reg]

これらすべての例外は、前のセクションからのタイミング例外が既に適用されているか、存在しないパスをターゲットにしています (レジスタ int11_reg と int20_reg の間には物理的な接続なし )。

これらの 4 つの制約を追加すると、 [Timing Constraints] ウィンドウは図 2-30 のようになります。

表 2‐1 : [Setup]/[Hold] 列の命名規則

省略名タイミング例外

cycles= set_multicycle_path

false set_false_path

max= set_max_delay

max_dpo= set_max_delay -datapath_only

min= set_min_delay

表 2‐2 : [Status] 列の命名規則

省略名タイミング例外

MCP マルチサイクルパス

FP フォルスパス

MXD 大遅延

MND 小遅延

CG クロックグループ





例外レポート (report_exception -ignored) は次のようになります。

注記 : [Status] 列に、タイミング例外が無視された理由が説明されます。

タイミング例外の適用範囲のレポート

Vivado ツールでは、デザインに適用された有効な各タイミング例外の詳細な適用範囲を生成できます。完全に無効になっているもの、始点と終点の間にパスがないものを含め、すべてのタイミング例外がレポートされます。適用範囲レポートは、タイミング例外およびデザインの複雑性によって、サイズが大きくなる可能性があります。

適用範囲レポートを生成するには、 -coverage コマンドラインを使用します。 report_exceptions -coverage

レポートには、有効な各タイミング例外に対して、次の情報が含まれます。

• 制約の位置番号

• -from、 -through、 -to コマンドラインオプションで選択されたオブジェクトの数

• タイミング例外に関連するすべてのクロックドメインと、各終点クロックドメインの終点の数

• 始点および終点に関連するセルのサマリリスト

次に、異なるデザインからの適用範囲レポートからの抜粋を示します。

Exception: set_false_path -from [get_pins {SW_FPGA_CORE/U_RST/st_asrst[0]/C}]+ Position: 74+ Objects: -from: 1 pins+ Clock Domains Details: +Domain : CLK_OUT2_PLL3 -> CLK_OUT1_PLL3 -Source Clock: CLK_OUT2_PLL3


図 2‐30 : [Timing Constraints] ウィンドウ


図 2‐31 :例外レポート





-Destination Clock: CLK_OUT1_PLL3 -Endpoints: 154277 +Domain : CLK_OUT2_PLL3 -> CLK_OUT2_PLL3 -Source Clock: CLK_OUT2_PLL3 -Destination Clock: CLK_OUT2_PLL3 -Endpoints: 9933 +Domain : CLK_OUT2_PLL3 -> CLK_OUT4_PLL3 -Source Clock: CLK_OUT2_PLL3 -Destination Clock: CLK_OUT4_PLL3 -Endpoints: 434 +Domain : CLK_OUT2_PLL3 -> clk_pll_i -Source Clock: CLK_OUT2_PLL3 -Destination Clock: clk_pll_i -Endpoints: 7193+ Startpoint Details: FDPE/C=1 + Endpoint Details: FDCE/CLR=169792 FDCE/D=7 FDPE/PRE=2038

タイミング例外の始点と終点の間にパスがない場合は、適用範囲レポートのフィールドは空になります。次に例を示します。

Exception: set_false_path -from [get_cells int11_reg] -to [get_cells int20_reg]+ Position:15+ Objects: -from:1 cells -to:1 cells+ Clock Domains Details:+ Startpoint Details: + Endpoint Details:

適用範囲レポートは、タイミング例外をより効率的に記述するために使用できます。

次に、 set_multicycle_path 制約の適用範囲レポートの別の例を示します。

Exception: set_multicycle_path -start -from [get_pins {sr_b*_rd_dat[*]/C}] -to [get_pins {ar_b*_rd_dat[*]/D}] 4+ Position:75+ Objects: -from:486 pins -to:486 pins+ Clock Domains Details: +Domain :CLK_OUT1_PLL3 -> CLK_OUT2_PLL3 -Source Clock:CLK_OUT1_PLL3 -Destination Clock:CLK_OUT2_PLL3 -Endpoints:24+ Startpoint Details:FDCE/C=4 + Endpoint Details:FDCE/D=24

上記の例では、 -from および -to コマンドラインオプションでのピンの指定に get_pins コマンドを使用しており、それぞれ 486 ピンが指定されていますが、 4 つの始点と 24 個の終点の間のパスのみに制約が適用されています。これは、ほかの始点と終点の組み合わせの間には、物理的なパスがないということです。

クロック乗せ換えレポートクロック乗せ換え (CDC) レポートは、デザインのクロック乗せ換えの構造解析を実行します。この情報を使用して、メタステーブル状態またはデータコヒーレンシの問題が発生する可能性のある危険な CDC を特定できます。CDC レ





ポートはクロック関連性レポートと似ていますが、構造および関連するタイミング制約に焦点が置かれ、タイミングスラックに関する情報は示されません。

概要

CDC レポートを生成する前に、デザインが適切に制約され、不足しているクロック定義がないことを確認してください。 CDC レポートでは、ソースクロックとデスティネーションクロックの両方が定義されたパスのみが解析およびレポートされます。 CDC レポートは、次のものの構造解析を実行します。

• 非同期クロック間のすべてのパス

• 次のタイミング例外が設定されている同期クロック間のパス

° クロックグループ

° フォルスパス

° データパス遅延制約 (Max Delay Datapath Only)

これらのタイミング例外が設定されていない同期クロックパスは、タイミング制約が適切に設定されていると想定され、 CDC エンジンで解析されません。 CDC レポートでは、ネット遅延またはセル遅延は考慮されません。

クロック乗せ換えレポートの実行

Vivado IDE から CDC レポートを実行すると、デフォルトで指定されたクロック間の CDC パスの詳細がすべて表示されます。 [Tcl Console] ウィンドウから CDC レポートを実行すると、クロックペアごとのサマリの表のみが表示されます。 GUI モードと同様の詳細をすべてレポートするには、 -details オプションを使用する必要があります。詳細をレポートすると、非常に長いファイルが作成されることがあります。

Vivado IDE から CDC レポートを実行するには、 [Tools] → [Timing] → [Report CDC] をクリックします。

同等 Tcl コマンド : report_cdc -name cdc_1

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

• 「[Results name] フィールド」

• 「[Clocks] セクション ([From]/[To])」

• 「[File Output] セクション」

• 「[Options] セクション」






レポートのグラフィカルウィンドウの名前を指定します。

同等 Tcl オプション : -name <windowName>

[Clocks] セクション ([From]/[To])

CDC 解析を実行するソースクロックまたはデスティネーションクロックを指定します (オプション)。CDC 解析を特定のクロックのみに限定し、レポートを解読しやすくするために使用できます。

参照ボタンクリックすると検索ダイアログボックスが表示され、クロックオブジェクトを検索できます。

同等 Tcl オプション : -from <clockNames> -to <clockNames>


結果を書き込むファイルを指定します (オプション)。既存のファイルに上書きするか、または追加できます。

同等 Tcl オプション : -file <fileName> -append


図 2‐32 : [Report CDC] ダイアログボックス





[Options] セクション

[Options] セクションでは、次を指定します。

• [Suspend message limits during command execution] : メッセージの制限を一時的に解除し、コマンドからのすべての出力を返します。


• [Ignore command errors] : コマンドエラーを表示しません。


クロック乗せ換えレポートのルールの理解

CDC レポートでは、各 CDC パスを既知の CDC トポロジに一致させようとします。各 CDC トポロジは、表 2-3 に示す 1 つまたは複数の CDC ルールに関連付けられています。これらのルールの重要度は、 DRC およびメッセージのように変更することはできません。 CDC トポロジの回路図と説明は、 70 ページの「CDC トポロジの回路図」に示されています。

表 2‐3 : CDC ルールおよび説明

CDC トポロジ CDC ルール重要度説明

1 ビット CDC CDCH-1 クリティカル同期されていないまたは不明の CDC 回路を含む 1 ビット CDC パス

CDCH-2 警告 2 段以上のシンクロナイザーで同期化されているが、ASYNC_REG プロパティがすべてまたは一部のシンクロナイザーフリップフロップに設定されていない 1 ビット CDC パス

CDCH-3 情報 2 段以上のシンクロナイザーで同期化されており、ASYNC_REG プロパティが設定されている 1 ビットCDC パス

複数ビット CDC CDCH-4 クリティカル同期されていないまたは不明の CDC 回路を含む複数ビットバス CDC パス

CDCH-5 警告 2 段以上のシンクロナイザーで同期化されているが、ASYNC_REG プロパティがすべてまたは一部のシンクロナイザーフリップフロップに設定されていない複数ビットバス CDC パス

CDCH-6 情報 2 段以上のシンクロナイザーで同期化されており、ASYNC_REG プロパティが設定されている複数ビットバス CDC パス

非同期リセット CDCH-7 クリティカル同期されていないまたは不明の CDC 回路を含む非同期信号 (クリアまたはプリセット )

CDCH-8 警告同期化されているが、 ASYNC_REG プロパティがすべてまたは一部のシンクロナイザーフリップフロップに設定されていない非同期信号 (クリアまたはプリセット )

CDCH-9 情報同期化されており、 ASYNC_REG プロパティが設定されている非同期信号 (クリアまたはプリセット )

組み合わせロジック CDCH-10 クリティカル同期回路のファンインで組み合わせロジックが検出された

ファンアウト CDCH-11 クリティカル同期回路のファンアウトで組み合わせロジックが検出された





クロック乗せ換えレポートのセクションの確認

GUI モードでは、デフォルトで次の 3 つのセクションが生成されます。

• 「[Summary (by clock pair)] セクション」

• 「[Summary (by type)] セクション」

• 「[CDC Details] セクション」

サマリセクションは、デザインで見直し、場合によっては変更が必要な問題の概要を示します。これらのセクションから、も重要度の高い違反に関する追加情報を表示する詳細レポートセクションにナビゲートできます。

注記 : レポートをテキストモードで実行した場合、デフォルトではクロックペアごとのサマリのみが生成されます。

[Summary (by clock pair)] セクション

[Summary (by clock pair)] セクションには、 2 つのクロック間の CDC パスの数、それらのパスで検出されたもクリティカルな問題に関する有益な情報が示されます。この表には、次の列があります。

• [Severity] : 示されているソースクロックからデスティネーションクロックまでのすべての CDC パスの中でも高い重要度を示します。重要度は [Info]、 [Warning]、または [Critical] のいずれかです。

• [Source Clock] : CDC ソースクロックの名前を示します。

• [Destination Clock] : CDC デスティネーションクロックの名前を示します。

• [CDC Type] : 2 つのクロックの関係と、主なタイミング例外を示します。次の CDC タイプがあります。

° [Safely Timed] : クロック同士が同期しているのですべての DCD パスにタイミング制約が適切に設定されており、タイミング例外は設定されていません。

° [User Ignored] : すべての CDC パスに set_false_path または set_clock_groups が設定されています。

° [No Common Primary Clock] : CDC クロックは非同期ですが、共通のプライマリクロックを持たない 2 つのクロック間の少なくとも 1 つの CDC パスに通常どおりタイミング制約が設定されます。

° [No Common Period] : CDC クロックは非同期ですが、共通周期を持たない 2 つのクロック間の少なくとも 1つの CDC パスに通常どおりタイミング制約が設定されます。共通乗数を見つけることができないクロックの定義は、 128 ページの「タイミング解析の基礎の理解」を参照してください。

複数クロックのファンイン CDCH-12 クリティカル非同期回路のファンインで複数クロックからのデータが検出された

FD 以外のプリミティブ CDCH-13 クリティカル FD 以外のプリミティブで CDC が検出された

CE 制御の CDC CDCM-1 警告クロックイネーブルで制御された CDC

マルチプレクサー制御のCDC

CDCM-2 警告マルチプレクサーで制御された CDC

マルチプレクサーデータホールド CDC

CDCM-3 警告マルチプレクサーデータホールド CDC

HARD_SYNC プリミティブ CDCH-18 情報信号は HARD_SYNC プリミティブに同期されています。

表 2‐3 : CDC ルールおよび説明 (続き)

CDC トポロジ CDC ルール重要度説明





• [Exceptions] : CDC に適用されているタイミング例外を示します。可能な値は次のとおりです。

° [none] : CDC パスにタイミング例外は存在しません。

° [Asynch Clock Groups] : CDC クロックに set_clock_groups -asynchronous 例外が適用されています。

° [Exclusive Clock Groups] : CDC クロックに set_clock_groups -exclusive 例外が適用されています。

° [False Path] : ソース /デスティネーション CDC クロックまたはすべての CDC パスに set_false_path 例外が適用されています。

° [Max Delay Datapath Only] : すべての CDC パスに set_max_delay -datapath_only 例外が適用されています。[Max Delay Datapath Only] は、少なくとも 1 つの CDC パスに set_max_delay -datapath_only が適用されており、ほかのすべての CDC パスが set_false_path 制約のために無視される場合にレポートされます。

° [Partial Exceptions] : 一部の CDC パスに set_false_path および set_max_delay -datapath_only 制約が設定されており、少なくとも 1 つの CDC パスに通常どおりタイミング制約が適用されています。

• [Endpoints] : CDC パスの終点の総数。安全な終点、危険な終点、および不明な終点の合計です。この場合の終点とは、シーケンシャルセルの入力データピンです。 D、 CE、および SET/RESET/CLEAR/PRESET の接続によっては、 FD セルは複数回カウントされます。一部の CDC トポロジでは 1 つの終点のみがカウントされますが、CDC 構造に到達するのにクロックドメインの境界をまたぐパスは実際には複数あります。たとえば非同期リセットシンクロナイザーでは、複数の CLEAR ピンがクロックドメインをまたぐネットに接続されていますが、シンクロナイザーチェーンの初のピンのみがカウントされます。

• [Safe] : 安全な CDC パスの終点の数。安全な終点とは、次のように特定された CDC パスの終点です。

° 既知の安全な CDC 構造を持つ非同期クロック

° 例外および既知の安全な CDC 構造を持つ同期クロック

° CDC 構造にかかわらず安全にタイミング制約が適用される例外なしの同期クロック

° CDC は HARD_SYNC マクロに同期されている

• [Unsafe] : 危険な構造を持つと特定された CDC パスの終点の数。危険な終点は CDCH-10、 CDCH-11、 CDCH-12、および CDCH-13 です。

° 組み合わせロジックトポロジ

° ファンアウトトポロジ

° 複数クロックのファンイントポロジ

° FD 以外のプリミティブのトポロジ

• [Unknown] : 不明な CDC パスの終点の数。これらの終点に一致する安全な CDC 構造がないか、不明な CDC 回路が検出されています (CDCH1、 CDCH4、および CDCH-7)。

• [No ASYNC_REG] : チェーンの初 2 つの FD セルの少なくとも 1 つに ASYNC_REG プロパティが設定されていないシンクロナイザーの数。

次の図に、 [Summary (by clock pair)] セクションの例を示します。





[Summary (by type)] セクション

[Summary (by type)] セクションの表には、現在のレポートに含まれる CDC 構造の特性をすばやく確認するのに便利です。図 2-34 に例を示します。

[Summary (by type)] セクションの表には、次の列があります。

• [Severity] : CDC ルールの重要度を示します。可能な値は [Info] (情報)、 [Warning] (警告)、または [Critical] (クリティカル) です。

• [ID] : 表 2-3 にリストされている CDC ルールの ID 番号を示します。

• [Count] : レポート全体での CDC ルールの出現回数を示します。

• [Description] : CDC ルールの簡単な説明を示します。

サマリ表を解析する際は、重要度の高いものから開始するのが重要です。重要度は次のとおりです。

• [Critical] : 不明または危険な CDC 構造を持つ CDC パスに対する重要です。これらの各パスを見直し、 RTL を変更して構造を修正するか、問題が除外されるようにする必要があります。パスの詳細は、 Vivado IDE を使用する


図 2‐33 : [Summary (by clock pair)] セクション


図 2‐34 : [Summary (by type)] セクション





場合はデフォルトで生成され、コマンドラインで report_cdc を使用する場合は -details オプションを使用すると生成されます。

° クロックドメインの境界をまたぐネットに組み合わせロジックがあるか、クロックドメインの境界をまたぐネットのファンインに複数のソースクロックがある。これにより、平均故障間隔 (MTBF) 特性が悪化する可能性があります。

° クロックドメインの境界をまたぐネットに同じデスティネーションクロックドメインへのファンアウトがある。これにより、データコヒーレンシの問題が発生する可能性があります。

• [Warning] : 安全な既知の CDC 構造ですが、次のいずれかの理由のために理想的とはいえない CDC パスに対する重要度です。

° 初 2 つのシンクロナイザーフリップフロップの少なくとも 1 つで ASYNC_REG プロパティが 1 (またはtrue) に設定されていない。

° CDC 構造に CDC エンジンで検証できない機能の正確さが必要。これらの構造には、クロックイネーブル制御、マルチプレクサーデータホールド制御のトポロジがあります。

• [Info] : CDC 構造が安全で適切に制約されていることを示します。

[CDC Details] セクション

CDC レポートの詳細は、 [CDC Details] セクションに示されます。このセクションから、選択したパスの回路図を表示したり (F4 キーを押す)、パスを右クリックしてタイミングレポートを表示または新しいタイミングレポートを生成できます。

タイミングレポートと回路図を使用して、デザインの予期しない CDC パスを確認したり、不正または不足しているタイミング例外を特定したり、 ASYNC_REG プロパティが足りない部分を見つけることができます。次の図に、 [CDCDetails] セクションの例を示します。

[Clock to Clock Details] セクションの表には、次の列があります。

• [Severity] : CDC ルールの重要度を示します。可能な値は [Info] (情報)、 [Warning] (警告)、または [Critical] (クリティカル) です。

• [ID] : 65 ページの表 2-3 にリストされている CDC ルールの ID 番号を示します。

• [Description] : CDC ルールの簡単な説明を示します。

• [Depth] : シンクロナイザーの段数を示します (シンクロナイザートポロジのみ)。

• [Exception] : CDC パスに適用されているタイミング例外を示します。

• [Source (From)] : CDC タイミングパスの始点を示します。

• [Destination (To)] : CDC タイミングパスの終点を示します。

• [Category] : [Safe]、 [Unsafe]、 [Unknown] など、 CDC のカテゴリを示します。

• [Source Clock (From)] : ソースクロックの名前。


図 2‐35 : [CDC Details] セクション





注記 : この列は、 [CDC Details] (左側のタイミングレポート CDC ウィンドウ) をクリックした場合にのみ表示されます。

• [Destination Clock (To)] : デスティネーションクロックの名前。

注記 : この列は、 [CDC Details] (左側のタイミングレポート CDC ウィンドウ) をクリックした場合にのみ表示されます。

重要 : CDC レポートに一部のザイリンクス IP 内の問題が示されることがありますが、これは CDC エンジンで可能なすべての CDC トポロジを認識できず、ビルトインの除外メカニズムがないからです。詳細は、各ザイリンクス IP 製品ガイドを参照してください。

CDC トポロジの回路図

次に、 CDC トポロジの簡略化された回路図とその簡単な説明を示します。すべての回路図で、ソースクロックネット (通常は clk_a) は青色でハイライトされ、デスティネーションクロックネット (通常は clk_b) はオレンジ色でハイライトされています。

1 ビットシンクロナイザー

図 2-36 に、 1 ビットシンクロナイザーのトポロジを示します。同期チェーンの少なくとも初の 2 つのフリップフロップに ASYNC_REG プロパティを設定する必要があります。シンクロナイザーの段数は、制御信号を共有するチェーン接続されているフリップフロップの数です。

フリップフロップの CLEAR または PRESET ピンも非同期ソースに接続されている場合は、シンクロナイザーは 1ビットシンクロナイザーとしてのみレポートされ、非同期リセットシンクロナイザーとしてはレポートされません。


図 2‐36 : 1 ビットシンクロナイザーのトポロジ





複数ビットシンクロナイザー

複数ビットシンクロナイザーは、始点/終点の名前および一致する CDC ルールに基づいてグループ化された複数の 1ビットシンクロナイザーと同等です。この場合、バスはネット名ではなく始点と終点のセル名で定義されます。バス名のフォーマットは baseName[index] です。また、始点と終点のインデックスも一致している必要があります。次の図に、 2 ビット幅の複数ビットシンクロナイザーの例を示します。

CDC バスのすべてのビットが同じ CDC ルールに一致しない場合は、バスは 1 ビットまたは CDC ルールが一致している連続インデックスのバスセグメントとしてレポートされます。

非同期リセットシンクロナイザー

図 2-38 にクリアベース同期の非同期リセットシンクロナイザー、図 2-39 にプリセットベース同期の非同期リセットシンクロナイザーを示します。 FF1 セルはそれぞれ同期されたクリアまたはプリセット信号に接続されており、これらの信号のディアサートには clk_a に対して安全にタイミング制約が適用されます。


図 2‐37 : ビット幅の複数ビットシンクロナイザー






図 2‐38 : クリアベースの非同期リセットシンクロナイザー


図 2‐39 : プリセットベースの非同期リセットシンクロナイザー





CLEAR および PRESET を持つフリップフロップを 1 つの非同期リセットシンクロナイザー内に混合することはできません。

組み合わせロジック

次の図に示す組み合わせロジックの例では、 LUT3 で示されるロジックファンクションが clk_a からの CDC とclk_b シンクロナイザーの間に配置されています。

この構造は、組み合わせロジックの出力でグリッチが発生する可能性があり、このグリッチはシンクロナイザーに取り込まれてデザインの残りの部分に伝搬されるので、通常推奨されません。


図 2‐40 :組み合わせロジックの例





ファンアウト

次の図に示すファンアウトの例では、ソースフリップフロップで駆動されるネットが赤でハイライトされているclk_b ドメインで 3 回同期化されています。この構造は、シンクロナイザーを介するレイテンシは限定されますがサイクル精度ではなく、デスティネーションクロックドメインでデータコヒーレンシの問題が発生することがあるため、お勧めしません。

注記 : N 個の異なるクロックドメインへの N ファンアウトは CDC 問題ではなく、 CDCH-11 違反とはなりません。


図 2‐41 : ファンアウトの例





複数クロックのファンイン

次の図に示す複数クロックのファンインの例では、clk_a と clk_x の両方がデータを組み合わせロジック (LUT2) を介して clk_b ドメインのシンクロナイザー回路に転送しています。 clk_a と clk_x からのソースデータをグルーロジックを介して結合する前に、個別に同期することをお勧めします。これにより CDC 構造全体の MTBF 特性が向上し、グリッチがデスティネーションクロックドメインに伝搬されるのが回避されます。


図 2‐42 :複数クロックのファンインの例





FD 以外のプリミティブ

次の図に示す FD 以外のプリミティブの例では、CDC は FDRE と RAMB の間で発生しており、RAMB プリミティブ内に同期ロジックは存在しません。clk_b に接続されている 1 段のフリップフロップを RAMB の前に挿入しても、FDREセルと RAMB セルの配線距離のため十分なシンクロナイザーとはいえません。

注記 : この規則には HARD_SYNC マクロは含まれません。 HARD_SYNC マクロは CDCH-18 で検出されます。


図 2‐43 : FD 以外のプリミティブの例





CE 制御の CDC

次の図に示す CE 制御の CDC では、クロックイネーブル信号はクロック乗せ換えフリップフロップを制御するために使用される前に、デスティネーション clk_b ドメインで同期されます。

CDC エンジンでは、FF3/CE に接続されている信号のソースクロックが clk_b であることのみがチェックされます。クロックイネーブル信号が別に安全な CDC パスとしてレポートされていれば、その同期方法に制限はありません。また、 clk_a ドメインから FF3 へのレイテンシはユーザーが制約する必要があり、これには通常 set_max_delay-datapath_only 制約を使用します。


図 2‐44 : CE 制御の CDC の例





マルチプレクサー制御の CDC

次の図に示すマルチプレクサー制御の CDC の例では、マルチプレクサーセレクト信号はデスティネーションクロックドメイン clk_b に同期されています。

CE 制御の CDC と同様に、セレクト信号が別に安全とレポートされていれば、その同期方法に制限はありません。また、 FF2_c 上のクロック乗せ換え遅延はユーザーが制約する必要があります。


図 2‐45 : マルチプレクサー制御の CDC の例





マルチプレクサーデータホールド CDC

次の図に示すマルチプレクサーデータホールド CDC の例では、マルチプレクサーセレクト信号はデスティネーションクロックドメイン clk_b に同期されており、 data_out がマルチプレクサーにフィードバックされています。

CE 制御の CDC と同様に、マルチプレクサーのセレクト信号が別に安全とレポートされていれば、その同期方法に制限はありません。また、 FF2_c 上のクロック乗せ換え遅延はユーザーが制約する必要があります。


図 2‐46 : マルチプレクサーデータホールド CDC の例




第 3章

インプリメンテーション結果の解析機能

[Design Runs] ウィンドウの使用[Design Runs] ウィンドウには、 run の状態が表示されます。

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

run が終了すると、 [Design Runs] ウィンドウがに run が問題なく完了したか、エラーが発生したかが示されます。

ヒント : run が新でない場合は、ポップアップメニューから [Force Up-to-Date] をクリックして、ステータスを強制的に新の状態にすることができます。

[Design Runs] ウィンドウには、次の情報が表示されます。

• [Name] : run の名前

• [Part] : ターゲットデバイス

• [Constraints] : run に関連付けられている制約セット

• [Strategy] : run のストラテジ

• [Status] : run で後に完了した段階のステータス

• [Progress] : run の進捗状況

• [Start] : run の開始時間

• [Elapsed] : 実行中の run に対しては経過時間、完了している run に対しては終的な実行時間

• [WNS]、 [TNS]、 [WHS]、 [THS]、 [TPWS] : run のタイミング値 (第 2 章の「タイミングサマリレポート」を参照)これらの値から、 run がタイミングを満たしているかどうかをすばやく判断できます。タイミングが満たされていない場合は、タイミングサマリレポートを使用して解析する必要があります。

• [Failed Nets] : 配線できなかったネットの数

• [Description] : run ストラテジの簡単な説明


図 3‐1 : [Design Runs] ウィンドウ


http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf;a=xUsingTheDesignRunsWindow



第 3 章 : インプリメンテーション結果の解析機能

Vivado IDE プロジェクトフローを使用している場合は、[Messages] ウィンドウでアクティブなインプリメンテーションの結果を確認します。メッセージは、フローの段階別にグループ化されています。 run のログファイルに保存される情報およびメインの Vivado セッションのログファイルの情報は、すべてこのウィンドウに表示されます。

メッセージによっては、ファイル名をクリックすることにより、ソースファイルまたはメッセージに関係するデザインオブジェクトにクロスプローブできるものもあります。メッセージからオブジェクトにクロスプローブするには、解析しているフローの段階によって、合成済みデザインまたはインプリメント済みデザインを開いておく必要があります。


図 3‐2 :段階ごとにグループ化されたメッセージ





配置解析このセクションでは、配置解析について説明します。次の内容が含まれます。

• 「配置のハイライト」

• 「接続の表示」

• 「メトリクスの表示」

配置のハイライト

デザインの配置を確認する別の方法として、セル配置の解析があります。この解析には、 [Highlight Leaf Cells] コマンドを使用します。

1. [Netlist] ウィンドウで解析する階層レベルを選択します。

2. 右クリックして [Highlight Leaf Cells] をクリックし、色を選択します。

3. 複数の階層レベルを選択している場合は、 [Cycle Colors] をクリックします。

[Device] ウィンドウで階層セルを構成する下位セルが色表示されます。


図 3‐3 :階層のハイライト





色分け表示により、 UsbEngine0 (黄色) が次のようであることがわかります。

• ブロック RAM および DSP48 セルを使用しています。

• DSP 以外は、チップの上部のクロック領域内にあります。

• デザインのその他のロジック (セル) とそれほど混じり合っていません。

fftEngine (赤色) と cpuEngine (茶色) が混じり合っているのがわかります。この 2 つのブロックは、主に異なるリソースを使用します (一方は DSP48、もう一方はスライス)。これらが混じり合っていることで、デバイスが適に使用されます。

接続の表示

接続に基づいてデザインを解析すると有益な場合があります。ある入力、ブロック RAM、または DSP のバンクで駆動されるすべてのロジックの配置を確認するには、 [Show Connectivity] を実行します。

このコマンドは、複数のセルまたはネットをシードとして、別のタイプのオブジェクトを選択します。

ヒント : この機能を使用して、デザイン内のロジックのコーンを表示できます。

図 3-4 では、デバイス内の OBUF を含むロジックを駆動するブロック RAM が表示されています。合成プラグマにより、メモリの推論でブロック RAM 内に出力フリップフロップが配置されないようになっています。





固定および未固定のロジック

Vivado には、次の 2 種類の配置があります。

• ユーザーが配置したエレメント (オレンジ色) は固定されます。

° 固定ロジックは、 XDC に保存されます。

° 固定ロジックには、通常 LOC 制約が設定されています。 BEL 制約が設定されている場合もあります。

• ツールで配置されたエレメント (青色) は固定されません。

図 3-5 では、 I/O およびブロック RAM の配置が固定されています。スライスロジックは固定されていません。


図 3‐4 :接続の表示





クロスプローブ

Vivado 合成を使用して合成されたデザインでは、ネットリストデザインがメモリに読み込まれていればソースファイルにクロスプローブできます。

クロスプローブするには、次の手順に従います。

1. ゲートを選択します。

2. 右クリックして [Go To Source] をクリックします。


図 3‐5 :固定および未固定のロジック





クロスプローブ機能を使用して、ネットリストゲートに関連するソースを特定します。合成での変換により、デザインのすべてのゲートをソースにクロスプローブできるとは限りません。

メトリクスの表示

インプリメンテーションが終了したら、デザインがデバイスでどのように動作するかを確認できます。 Vivado IDE では、デバイス内のロジックおよび配線リソースの使用状況を調べるためのメトリクスが複数あります。メトリクスは、[Device] ウィンドウに指定した規則に従って色分け表示されます。メトリクスを表示するには、 [Device] ウィンドウを右クリックして [Metric] をクリックし、表示するメトリクスを選択します (次の図を参照)。


図 3‐6 : ソースへのクロスプローブ






図 3‐7 : メトリクス





配置済みデザインが必要なメトリクス

次の 4 つのメトリクスには、配置済みデザインが必要です。完全に配線されたデザインは必要ありません。

• [LUT Utilization per CLB] (CLB ごとの LUT の使用率) : 配置された LUT の使用率に基づいて、スライスを色分け表示します。

• [FF Utilization per CLB] (CLB ごとのフリップフロップの使用率) : 配置されたフリップフロップの使用率に基づいて、スライスを色分け表示します。

• [Vertical routing congestion per CLB] (CLB ごとの垂直方向の配線の密集度) : 垂直方向の配線の使用状況をベストケースで予測した結果に基づいて、ファブリックを色分け表示します。

• [Horizontal routing congestion per CLB] (CLB ごとの水平方向の配線の密集度) : 水平方向の配線の使用状況をベストケースで予測した結果に基づいて、ファブリックを色分け表示します。

配置のないネットリストデザインでのメトリクス

次の 2 つのメトリクスは、 Pblock に関係しています。これらは配置に依存しません。

• [LUT Utilization per Pblock] (Pblock ごとの LUT の使用率) : Pblock に含まれる LUT のスライスへの配置予測に基づいて、 Pblock を色分け表示します。

• [FF Utilization per Pblock] (Pblock ごとのフリップフロップの使用率) : Pblock に含まれるフリップフロップのスライスへの配置予測に基づいて、 Pblock を色分け表示します。

図 3-7 に示すように、同時に複数のルールを使用できます。この図では、 CLB ごとの LUT 使用率と CLB ごとのフリップフロップの使用率がオンになっています。

ヒント : デザインに使用率の高い部分や配線の密集度が高くなることが予測される部分がある場合は、 RTL または配置制約を変更して、その部分でのロジックおよび配線の使用率を削減してください。





配線解析[Device] ウィンドウのツールバーの [Routing Resources] ボタンをオンにすると、配線リソースが表示されます。

配線配置の表示

配置配線は、ズームレベルによって表示が異なります。

• 縮小表示した場合

• 拡大表示した場合

ヒント : 2 種類の表示を使用することにより、ランタイムとメモリの使用量を小限に抑えながら、すべてのサイズでデザインの詳細が表示されるようになっています。

縮小した場合の配線配置の表示

縮小すると、表示は簡略化されたものになります。この表示には、次のような特徴があります。

• 配線が凝縮されたものになります。

• 特定の領域を通過する配線の数によって線の太さが変わります。

配置も同様に、各タイルを表すブロックに、配置されているロジックが表示されます。タイルに含まれるロジックが多いほど、タイルを表すブロックが大きくなります。


図 3‐8 :配線の表示





拡大した場合の配線配置の表示

拡大すると、実際のロジックセルおよび配線が表示されます。

表示オプション

[Device] ウィンドウをカスタマイズして、デバイスおよびデザインをさまざまな方法で表示できます。これらは、ツールバーの [Device Options] をクリックして設定します。


図 3‐9 :簡略表示


図 3‐10 :詳細表示





デザインおよびデバイスの異なるリソースの表示/非表示を切り替えたり、表示色を変更したりできます。

[Device] ウィンドウのナビゲーション

[Device] ウィンドウは、次の機能を使用してナビゲートできます。

• ズーム操作 : 標準的な拡大 ([Zoom In])、縮小 ([Zoom Out])、および全体表示 ([Zoom Fit])


図 3‐11 : [Device Options] の [Layers] ビュー


図 3‐12 : [Device] ウィンドウのナビゲーション





• [Auto-fit Selection] : [Device] 以外のウィンドウで選択されたオブジェクトを自動的に拡大表示します。クロスプローブに便利です。

• [World] ビュー : [Device] ウィンドウに現在表示されている部分がデバイス全体のどこかを表示します。 [World]ビューに表示される黄色のボックスをドラッグまたはサイズ変更すると、 [Device] ウィンドウの表示を移動したりサイズ変更したりできます。

• Ctrl キー : Ctrl キーを押しながらドラッグすると、表示箇所を移動できます。

デザイン解析レポートデザイン解析レポートには、タイミングパスの特性、デザインのインターコネクトの複雑性、および密集に関する情報が示されます。この情報を使用してデザインおよび制約を変更することにより、 QoR (結果の品質) を向上し、配線の密集を軽減できます。

デザイン解析レポートの生成

デザイン解析レポートは、 [Tcl Console] コンソールまたは Vivado IDE から生成できます。次の 3 つのカテゴリのレポートを生成できます。

• タイミング : タイミングパスのタイミングおよび物理的な特性をレポートします。

• 複雑性 : デザインの配線の複雑性および LUT の分布を解析します。

• 密集度 : デザインの配線の密集度を解析します。

Vivado IDE からデザイン解析レポートを実行するには、 [Tools] → [Report] → [Report Design Analysis] をクリックします。

同等 Tcl コマンド : report_design_analysis -name design_analysis_1.

Vivado IDE の [Report Design Analysis] ダイアログボックス (図 3-13) には、次のフィールドおよびタブがあります。

• [Results name] フィールド

• [Options] タブ

• [Advanced] タブ

• [Timer Settings] タブ






レポートのグラフィカルウィンドウの名前を指定します。

同等 Tcl オプション : -name <windowName>

[Options] タブ

[Options] タブ (図 3-13) には、次のセクションがあります。

• [Timing]

• [Complexity]

• [Congestion]


図 3‐13 : [Report Design Analysis] ダイアログボックス





[Timing]

タイミングパスのタイミングおよび物理的な特性をレポートするよう設定します。

同等 Tcl オプション : -timing

すべてのパスのレポートを生成するか、特定のタイミングパスのレポートを生成するかを選択できます。 [All Paths]をオンにした場合は、[Path delay type] (パス遅延タイプ) をセットアップに対しては [max]、ホールドに対しては [min]、セットアップおよびホールドの両方に対しては [min_max] に設定できます。

同等 Tcl オプション : -setup/-hold

また、 [Maximum number of paths per clock group] (クロックグループごとのパスの大数) も指定できます。

同等 Tcl オプション : -max_paths <arg>

[Specific Paths] をオンにした場合、解析は指定したパスオブジェクトに対して実行されます。フィールドの右側にある参照ボタンをクリックすると [Find Timing Paths] ダイアログボックスが表示され、パスオブジェクトを検索できます。 get_timing_paths コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] のこのセクションを参照してください。

同等 Tcl オプション : -of_timing_paths <args>

[Extend analysis] をオンにすると、指定した各パスに対して拡張解析が実行され、始点へのワーストパスおよび終点からのワーストパスもレポートされます。

同等 Tcl オプション : -extend

注記 : [Extend analysis] オプション (Tcl オプション -extend) は、現在のところセットアップパス解析のみで設定可能です。ホールドパス解析は、 Vivado の今後のバージョンでサポートされるようになる予定です。

[Include logic level distribution] をオンにすると、[Number of paths] で指定した数のパスのロジックレベル分布がデザイン解析レポートに含まれます。 [All paths] をオンにしている場合は、ここで指定したパスの数が [Maximum number ofpaths per clock group] の代わりに使用されます。 [Specific paths] をオンにしている場合は、特定のパスのみに対してロジックレベル分布が生成されます。

同等 Tcl オプション : -logic_level_distribution <arg>

[Complexity]

デザインネットリストの複雑性をレポートするよう設定します。

同等 Tcl オプション : -complexity

[Cells to analyze] をオンにすると、複雑性の解析に使用する階層セルを指定できます。フィールドの右側にある参照ボタンをクリックすると [Specify Top level Cell] ダイアログボックスが表示され、セルオブジェクトを検索できます。

同等 Tcl オプション : -cells <args>

[Hierarchical depths] をオンにすると、上位 (デフォルト ) または -cells オプションで指定したセルで解析するレベル数を指定できます。

同等 Tcl オプション : -hierarchical_depth <arg>

[Advanced] タブ

[Advanced] タブ (図 3-14) には、次のセクションがあります。

• [File Output]

• [Miscellaneous]

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xget_timing_paths






[Write results to file] をオンにし、その右側のフィールドでファイル名を指定することにより、結果を GUI に表示するだけでなく、ファイルに保存できます。ファイル名を指定するフィールドの右側にある参照ボタンをクリックすると、異なるディレクトリを指定できます。

同等 Tcl オプション : -file <arg>

[Overwrite] をオンにすると、既存のファイルが上書きされます。 [Append] をオンにすると、新しい結果がファイルの後に追加されます。


[Miscellaneous]

[Ignore command errors (quiet mode)] をオンにするとコマンドエラーは非表示になり、 [Suspend message limits duringcommand execution] をオンにするとプログラム実行中メッセージの制限が解除され、すべてのメッセージが表示されます。

同等 Tcl オプション : -quiet -verbose






[Timer Settings] タブ (図 3-15) には、次のオプションおよびセクションがあります。

• [Interconnect]

• [Speed grade]

• [Multi-Corner Configuration]

• [Disable flight delays]

[Interconnect]

タイミングパスの解析に使用するインターコネクトモデルを選択します。


図 3‐14 : [Report Design Analysis] ダイアログボックス : [Advanced] タブ





• [actual] : 配線済みデザインのも正確な遅延が含まれます。

• [estimated] : インプリメンテーション前のデバイス上のデザインの配置および接続に基づく予測インターコネクト遅延が含まれます。デザインが完全に配線されていても、予測遅延を指定できます。

• [none] : タイミング解析にインターコネクト遅延は含まれず、ロジック遅延のみが含まれます。

同等 Tcl コマンド :set_delay_model -interconnect <arg>

set_delay_model コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] を参照してください。

[Speed grade]

解析用のスピードグレードを指定します。

同等 Tcl コマンド :set_speed_grade <arg>

set_speed_grade コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] を参照してください。

[Multi‐Corner Configuration]

実行するコーナー解析を指定します。デフォルトでは、 4 コーナー解析が実行されます。

同等 Tcl コマンド :config_timing_corners -corner <arg> -delay_type <arg>

config_timing_corners コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] を参照してください。

[Disable flight delays]

I/O タイミングの算出にパッケージ遅延が含まれないようにします。

同等 Tcl コマンド :config_timing_analysis -disable_flight_delays <arg>

config_timing_analysis コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] を参照してください。





タイミングパス特性レポート

次の図に、デザイン解析レポートを、タイミングモードで、デザインの 10 個のワーストセットアップパス特性がレポートされるように指定して生成した例を示します。このレポートは、 GUI で [Tools] → [Report] → [Report DesignAnalysis] をクリックするか、次の Tcl コマンドを使用して生成できます。

report_design_analysis -name <arg>

ヒント : ホールドパス特性をレポートするには、[Report Design Analysis] ダイアログボックスの [Options] タブで [Pathdelay type] を [min] に設定します。Tcl コマンド構文の詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』(UG835) [参照 3] を参照してください。


図 3‐15 : [Report Design Analysis] ダイアログボックス : [Timer Settings] タブ





デザイン解析レポートには、ワーストタイミングパスのロジックレベル分布 (Logic Level Distribution) の表を含めることもできます。ロジックレベル分布用に解析されるパスのデフォルト数は 1,000 ですが、この数は [Report DesignAnalysis] ダイアログボックスで変更できます。ロジックレベル分布の表はデフォルトでは生成されません。生成するには、 [Report Design Analysis] ダイアログボックスの [Options] タブで [Include logic level distribution] をオンにします。次の図に、ロジックレベル分布の表の例を示します。

特定のパスの解析

図 3-18 に、特定のパスを指定してタイミングモードで生成したデザイン解析レポートの例を示します。

この場合、特定のパスのみに対してパス特性およびロジックレベル分布の表 (選択されている場合) が生成されます。パスを指定するには、 [Report Design Analysis] ダイアログボックスの [Specific paths] をオンにし、フィールドの右側にある参照ボタンをクリックします。図 3-19 に示す [Find Timing Paths] ダイアログボックスが表示されます。


図 3‐16 : セットアップパス特性レポートの例


図 3‐17 : ロジックレベル分布の表の例


図 3‐18 :特定のタイミングパスのデザイン解析レポート例





ワーストパスとその前後のパスの解析

次の図に、 [Extend analysis] をオンにしてタイミングモードで生成したデザイン解析レポートの例を示します。

注記 : [Extend analysis] オプションは、現在のところセットアップパス解析のみで設定可能です。

ワーストセットアップパスに加え、始点セルへのワーストセットアップパス (PrePath) および終点セルからのワーストセットアップパス (PostPath) のパス特性がレポートされます。 -extend オプションを使用すると、レポートされるパスのすべての特性を収集するためタイミング解析を複数回実行する必要があるので、実行時間が長くなります。

同等 Tcl コマンド : report_design_analysis -extend


図 3‐19 : [Find Timing Paths] ダイアログボックス





タイミングパス特性レポートの解読および解釈

パス特性は、主にタイミング、ロジック、物理、およびプロパティの 4 つのカテゴリに分類されます。各特性の定義は、次のコマンドで report_design_analysis コマンドのヘルプ情報を参照してください。

Tcl コマンド : report_design_analysis -help

同じ情報は『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] でも参照できます。

カテゴリ 1 : タイミング

• タイミング解析 : [Path Type] はタイミング解析タイプ ([SETUP] (セットアップ) または [HOLD] (ホールド ))、[Requirement] はタイミングパス要件を示します。 [Slack] は、タイミング制約によるタイミング解析に基づいてタイミングパス要件が満たされているかどうかを示します。 [Timing Exception] は、マルチサイクルパスや大遅延などのタイミング例外がタイミングパスに適用されているかを示します。

パス要件のチェックは通常、不足しているタイミング制約や不正なタイミング制約をデバッグする際の初の手順です。

° セットアップ要件が 4ns 未満のパスは、特にクロック乗せ換えパスの場合は、デザインでそれが正しいかどうかを確認する必要があります。

° セットアップ要件が 2ns 未満のパスは要件を満たすことが困難であり、特に従来のアーキテクチャでは回避する必要があります。

° 通常セットアップ要件が小さい場合、タイミング例外制約が不足していないかどうか、およびソースおよびデスティネーションクロックエッジを確認してください。タイミング解析では、タイミング例外制約が設定されていない場合は、ソースクロックエッジとデスティネーションクロックエッジの正の小差が使用されます。

° 正のホールドパス要件は一般的でなく満たすことが難しいので、見直す必要があります。正のホールドパス要件がある場合、マルチサイクルパス制約がセットアップ解析用にのみ設定されており、ホールド解析用のマルチサイクルパス制約が不足していないかどうかを確認してください。また、ソースクロックとデスティネーションクロックの関係が正しいことも確認してください。

• データパス : [Path Delay] はデータパス遅延の合計、 [Logic Delay] はロジックセル遅延、 [Net Delay] はネット遅延を示します。

° [Logic Delay] が合計データパス遅延に占める割合が高い場合は (50% 以上など)、データパスロジックのレベル数およびロジックパス上のセルのタイプを確認し、 RTL または合成オプションを変更してパスのロジックレベル数を削減するか遅延の小さいセルを使用することをお勧めします。

° [Requirement] が妥当であるセットアップパスで [Net Delay] の合計パス遅延に占める割合が高い場合は、このセクションにリストされているパスの物理特性およびプロパティ特性を解析することをお勧めします。[High Fanout] および [Cumulative Fanout] 特性を見ると、パスの一部のネットのファンアウトが大きいために配置の問題が発生している可能性があるかを確認できます。 [Hold Fix Detour] 特性を見ると、パスに対してホールド違反の修正が実行されているかを確認できます。この特性は、 report_design_analysis コマ


図 3‐20 : ワーストセットアップパスの拡張パス特性レポートの例





ンドを route_design コマンドと同じセッションで実行した場合にのみアップデートされ、配線後のチェックポイントを読み込んだ後にはアップデートされません。

重要 : LUT 入力ピンは、異なる遅延特性を持ちます。インデックス番号の大きい物理ピン (サイトピン) の方が、インデックス番号が小さい物理ピンよりも高速です。7 シリーズデバイスと UltraScale™ デバイスの LUT 遅延のレポートは異なるので注意してください。 7 シリーズデバイスでは、 LUT 遅延の変数部分は LUT 前のネット遅延の一部としてレポートされます。 UltraScale デバイスでは、 LUT 遅延の変数部分はロジック遅延としてレポートされます。そのため、 7 シリーズデバイスの [Net Delay]/[Logic Delay] の比は UltraScale デバイスの比よりも大きくなります。

• クロック : [Start Point Clock]、 [End Point Clock]、 [Clock Relationship]、および [Clock Skew] は、タイミングパスクロックに関する情報を示します。 [Start Point Clock] はタイミングパスのソースクロック、 [Endpoint Clock] はデスティネーションクロックを示します。

° [Clock Relationship] が正しく予測されるものであるかを確認してください。クロック内パスまたは同期クロック乗せ換えパスに対しては、「Safely Timed」 (安全にタイミング制約が適用される ) と示されます。[Requirement] および [Clock Skew] が妥当なものであることを確認する必要があります。非同期クロックに対しては、「No Common Primary Clock」 (プライマリクロックが共通していない) または「No Common Period」 (周期の共通乗数がみつからない) と示されます。非同期クロック乗せ換えパスには、タイミング例外を適用する必要があります ([Timing Exception] の値を確認)。

° [Clock Skew] が妥当であることを確認します。クロックスキューを解析する際は、カスケード接続されたクロックバッファーのクロックツリー構造を確認します。 7 シリーズデバイスでは、ソースクロックおよびデスティネーションクロックの異なるクロックバッファータイプを確認します。 UltraScale デバイスでは、クロックネットの配置および配線はロジックロードの配置によって異なるので、クロックネットの配置および配線を調べる必要がある場合があります。クロック領域の境界または I/O 列をまたぐと、クロックスキューが大きくなることがありますが、これは予測されることです。

report_design_analysis コマンドで生成されるタイミング特性のほとんどは、タイミングレポートに示されます。

カテゴリ 2 : ロジック

• パス : [Start Point Pin Primitive]、 [End Point Pin Primitive]、 [Start Point Pin]、 [End Point Pin]、 [Logic Levels]、 [LogicalPath]、および [Comb DSP] ロジック特性は、タイミングパスの基本的な情報を示します。

° [Start Point Pin Primitive] はタイミングパスの始点、[End Point Pin Primitive] は終点を示します。[Start Point PinPrimitive] と [End Point Pin Primitive] が予測されるタイミングパスの始点および終点であることを確認します。 [Start Point Pin] および [End Point Pin] は、典型的なタイミングレポートのヘッダーに示される実際のタイミングパスピンの始点と終点を示します。

CLR、 PRE、 RST、 CE などの終点ピンは、非同期リセットやクロックイネーブル信号などの制御信号のファンアウトの大きいネットの一部である可能性があるので、確認します。また、ブロック RAM や DSP などの一部のプリミティブは Clock-to-Q 遅延およびセットアップ/ホールド要件がほかのセルよりも大きいので、セルのタイプも確認してください。これらがパスに存在すると、パスタイミングバジェットのかなりの部分が消費される可能性があります。

° [Logic Levels] はロジックレベル数、 [Logical Path] はデータパスに含まれるプリミティブのタイプを示します。この情報を使用すると、ロジックレベル数が大きい原因が LUT であるのか、 LUT/CARRY/MUXF セルの組み合わせであるのかをすばやく確認できます。通常 CARRY および MUXF セルは遅延がゼロまたは非常に小さい専用配線を使用するネットに接続されますが、LUT 入力は常にファブリックを介して配線する必要があります。

パスに含まれるのがほとんど LUT である場合は、そのサイズを確認することも重要です。小型の LUT (LUT6以外) が複数チェーン接続されている理由と、合成でロジックレベル数を削減可能な LUT6 が使用されるのを阻止する要因を理解するようにしてください。 KEEP、 DONT_TOUCH、 MARK_DEBUG などのプロパティが使用されていたり、マップ効率に影響するパスにファンアウトが中から大のネットがある可能性があります。

解析の結果に基づいて、 RTL ソースを変更するか、 RTL の属性を追加または変更するか、異なる合成設定を使用して、パス上の LUT の数を削減します。また、 opt_design コマンドの -remap オプションを使用すると、 LUT を再度適化して小型の LUT の一部を削除できる可能性があります。





° [COMB DSP] は、データパスの一部である組み合わせロジックとして使用されている DSP の数を示します。

• セル : DOA_REG、 DOB_REG、 MREG、 PREG は、ブロック RAM および DSP のオプションのレジスタプロパティを示します。 RAMB または DSP からのパスに出力レジスタがなく、数ロジックレベルの場合、タイミングを満たすのが困難になります。これらのパスのタイミング要件を満たすのが困難な場合は、デザインを変更してRAMB または DSP の出力レジスタを使用することを考慮してください。

カテゴリ 3 : 物理

• アーキテクチャ境界をまたぐ : [BRAM Crossings]、 [DSP Crossings]、 [IO Crossings]、 [CONFIG Crossings]、および[SLR Crossings] は、パスが BRAM 列、DSP 列、 I/O 列、CONFIG ブロック列、および SLR アーキテクチャリソースの境界をまたぐかどうかを示します。

多数のアーキテクチャ列をまたぐ場合でも、必ずしも問題が発生するわけではありません。多数のアーキテクチャ列をまたいでいて、さらにネット遅延またはスキューが大きいかどうかを確認します。特定のモジュールの複数のインプリメンテーション run で多数のアーキテクチャ列をまたいでいることがタイミング問題の原因である場合は、 Pblock を使用して小限のフロアプランを実行し、アーキテクチャ列または SLR 境界をまたぐ状況を削減します。

• パス配置制限 : Pblock - 過剰なフロアプランにより、ツールで適な結果を達成できないことがあります。複数の Pblock をまたぐパスでは、タイミング問題が発生することがあります。

° パスが複数の Pblock をまたぐ場合は、 Pblock の位置とタイミングパスの配置に与える影響を調べます。

° Pblock が隣接している場合は、それらの Pblock を含む 1 つの Pblock を作成することを考慮します。これにより、配置の制限が緩和され、タイミングが向上する可能性があります。

物理要件により Pblock が離れている場合は、タイミング要件が満たすため Pblock 間をパイプライン処理することを考慮します。

• 配置ボックス : [Bounding Box Size]、 [Clock Region Distance]、 [Combined LUT Pairs]

° タイミングパスの [Combined LUT Pairs] または [Clock Region Distance] が大きすぎる場合は、place_design コマンドの -directive オプションを使用してみます。UltraScale デバイスでは、 [Clock RegionDistance] とタイミングパスの [Clock Skew] への影響に特に注意してください。

• ネットのファンアウトおよび迂回 :

° [High Fanout] はデータパスのすべてのネットで大のファンアウトを示し、 [Cumulative Fanout] はデータパスネットすべてのファンアウトの合計を示します。

[High Fanout] および [Cumulative Fanout] が大きい場合は、タイミング違反はファンアウトが配線およびネット遅延に影響しているためだと考えられます。

物理適化を実行してもファンアウトが削減されない場合は、 MARK_DEBUG および DONT_TOUCH 制約により複製が阻止されているかどうかを確認します。

インプリメンテーションの前にネットを複製が必要な場合は、 RTL または XDC ファイル内で合成にMAX_FANOUT 制約を使用します。ファンアウトの大きいネットで良いタイミングを得ることができるかどうかは配置に依存するので、合成で複製を実行するのは通常はお勧めしません。配置後の物理適化(phys_opt_design) で複製を実行することをお勧めします。 -directive オプションを Explore、AggressiveExplore、 AggressiveFanoutOpt などに設定すると、正のスラックが小さいパスも適化できます。

インプリメンテーション中に特定のネットでファンアウトの削減が必要な場合は、次のコマンドを使用して複製を強制できます。phy_opt_design -force_replication_on_nets <netName>

° [Hold Fix Detour] が 1 の場合、パスホールドタイム要件を満たすためデータパス上の配線が遅延されています。パスのセットアップ要件が満たされていない場合は、ソースクロックとデスティネーションクロックの間に過剰なスキューがないかどうかを確認します。ホールドパス要件が正の場合は、ソースクロックとデスティネーションクロックの間に適切なタイミング制約が設定されているかどうかも確認します。ホールドパス要件は、ほとんどの場合 0 または負です。





[Hold Fix Detour] は、配線が同じセッションで実行されている場合にのみレポートされます。それ以外の場合は、 [Hold Fix Detour] は常に 0 と示されます。

カテゴリ 4 : プロパティ

• LUT の組み合わせ : [Combined LUT Pairs] は、パスに組み合わされた LUT ペアが存在するかどうかを示します。LUT ペアの組み合わせによりロジックの使用率が低減される可能性はありますが、配置ソリューションを制限する結果となることもあり、ピンの集積度が高いために密集が発生することがあります。LUT の組み合わせがデザインで問題となっていると思われる場合は、合成で -no_lc オプションを使用して LUT の組み合わせをディスエーブルにしてみてください。

• 適化の阻止 : MARK_DEBUG および DONT_TOUCH は、パスにツールで適化できないネットまたはセルがあるかどうかを特定します。

° MARK_DEBUG を設定すると、デフォルトでは DONT_TOUCH も設定されます。 DONT_TOUCH を FALSE に設定し、適化が実行されるようにします。

° DONT_TOUCH を設定すると、セルまたはネットの複製などの適化がディスエーブルになります。DONT_TOUCH 制約が必要であるかを評価し、可能であれば削除します。階層セルに入力するネットに DONT_TOUCH が設定されていると、階層セル内のネットの一部を複製できません。ロジックが適化で削除されないようにするため DONT_TOUCH を使用している場合は、デザインが正しいことを確認します。出力が接続されていないためにロジックが削除されるのが 1 つの例です。

• 配置配線の固定 : [Fixed Loc] および [Fixed Route] は、タイミングパスのスラックに影響する可能性のある固定配置制約または固定配線制約があるかどうかを示します。

° セルロケーション制約を使用すると、困難なデザインで QoR を一貫したものにするのに役立ちます。デザインを変更した後にタイミングが満たされなくなった場合は、配置制約を削除してより柔軟に配置されるようにしてみてください。

° 配線を固定すると、タイミングを満たすためにネット遅延が適化されなくなります。配線が固定されたタイミングパスは通常、この制約の悪影響を受けるほかのパスとネットを共有しています。配線の固定は、必要でほかのパスに影響しない場合にのみ使用します。

° Pblock などのほかの物理制約に変更を加えた場合、固定されたセルロケーションまたは固定された配線もアップデートが必要な場合もあることに注意してください。

複雑性レポート

複雑性レポートには、 Rent 指数、平均ファンアウト、上位デザインの下位セルタイプの分布、 1000 以上の下位セルを含む階層セルが示されます。 Rent 指数は、小カットアルゴリズムを使用してデザインを再帰的に分割した場合のネットリストパーティションのポート数とセル数の関係を示します。グローバル配置中に配置プログラムにより使用されるアルゴリズムと同様のアルゴリズムにより算出されます。そのため、デザインの階層がグローバル配置中に検出される物理パーティションとよく一致している場合に特に、配置の課題を示す指標として使用できます。

Rent 指数は、 Rent の規則により定義されます。

ports = constant x cellsRent

log(ports) = Rent x log(cells) + constant

Rent 指数が大きいデザインは、蜜に接続されたロジックのグループがほかのグループとも蜜に接続されていることを示します。これは、グローバル配線リソースの使用率が高く、配線の複雑性が高いことを意味します。このレポートに示される Rent 指数は、未配置および未配線のネットリストに対して算出されます。

配置後には Rent 指数は論理パーティションではなく物理パーティションに基づくので、同じデザインでも配置後のRent 指数は異なる場合があります。配置後の Rent 指数は report_design_analysis コマンドではレポートされないので、デザインが配置された後に密集を解析することをお勧めします。

次のオプションを使用すると、デザイン解析レポートは複雑性モードで生成されます。

• [Report Design Analysis] ダイアログボックスの [Options] タブで [Complexity] をオンにする。





• report_design_analysis Tcl コマンドを次の表に示すオプションを使用して実行する。

上位でのデザイン複雑性の解析

次の図に、デザイン解析レポートを複雑性モードで実行し、上位モジュールから 1 階層レベルの解析をレポートした場合の例を示します。

Tcl コマンド :

report_design_analysis -complexity -hierarchical_depth 1

複雑性レポートの解読と解釈

上記の例の Complexity Characteristics (複雑性特性) の表には、上位の下の各階層レベルに対して Rent 指数および平均ファンアウトが示されています。これらのメトリクスの典型的な範囲を次に示します。

• Rent 指数 (Rent) :

° 0.0 ～ 0.65 : 複雑性は低から通常で、問題が発生することは予測されません。

° 0.65 ～ 0.85 : 複雑性は高いと考慮されます (特に合計インスタンス数が 25,000 個を超える場合)。

° 0.85 以上 : 複雑性は非常に高く、インスタンス数も多い場合は、インプリメンテーションでデザインにエラーが発生する可能性があります。

• 平均ファンアウト (Average Fanout) :

° 4 未満 : 通常であると考えられます。

° 4 ～ 5 : 密集を発生させずにデザインを配置することは困難です。SSI デバイスでインスタンス数の合計が 10個を超える場合は、1 つの SLR に収まる配置ソリューションまたは 2 つの SLR にまたがる配置ソリューションを見つけるのが困難意なります。

° 6 以上 : インプリメンテーション中にデザインでエラーが発生する可能性があります。

大型で重要度の高いモジュールで Rent 指数または平均ファンアウトが大きい場合は、対処が必要です。小型のモジュール、特に合計インスタンス数が 1 満未満のモジュールの場合は、Rent 指数および平均ファンアウトが大きくて

表 3‐1 :デザイン解析レポートを複雑性モードで生成するオプション

Tcl オプション説明

-complexity デザイン解析レポートを複雑性モードで生成する場合に指定する必要があります。

-cells <arg> 複雑性を解析する際に使用する階層セルを指定します。

-hierarchical_depth <arg> 上位 (デフォルト ) または -cells オプションで指定したセルで解析する階層レベル数を指定します。


図 3‐21 : 上位で階層レベル数 1 の複雑性解析





も問題なく配置配線できます。そのため、 Rent 指数および平均ファンアウトと共に [Total Instances] 列も確認する必要があります。

複雑性の特性から常に配線の密集を予測できるわけではありません。I/O ロケーション制約、フロアプラン、ターゲットデバイスでのマクロプリミティブの位置などの要因により、配置ソリューションが制限されて密集が発生する可能性があります。これらの制約の影響の解析には、配置後の密集レポートを使用するのが適しています。

Complexity Characteristics の表を解釈する際には、次の項目にも注意します。

• モジュールの LUT6 の割合が大きいと、通常平均ファンアウトが大きくなり、 Rent 指数が大きくなる可能性もあります。

• RAMB および DSP の数が多いと、これらのプリミティブは接続量が多いので、 Rent 指数が大きくなる可能性があります。

• Rent 指数または平均ファンアウトが大きい階層インスタンスが必ずしも問題を引き起こすとは限りません。配置はフラットネットリストに対して実行され、これらのインスタンスが配置しやすいロジックグループに分割されます。このレポートは、あるモジュールが明らかに際立っている場合にネットリストの問題が存在する可能性のある場所を示します。

大型のモジュールの Rent 指数または平均ファンアウトが大きくそれが原因で密集およびタイミング問題が発生している場合は、次を実行することを考慮します。

° モジュールの接続を削減します。階層を保持して合成での境界をまたぐ適化が実行されないようにすると、 LUT6 の使用量が削減され、ネットリストの集積度も削減されます。

° 合成での LUT の組み合わせをディスエーブルにしてみます。

° インプリメンテーション中に密集ストラテジを使用するか、配置の -directive オプションに SpreadLogic モードを使用して、密集を緩和します。デザインが SSI デバイスをターゲットとしている場合は、配置で異なるSSI モードを試してみます。

° SSI デバイスでは SLR レベルで単純なフロアプランを使用するか、一般的にはクロック領域レベルで単純なフロアプランを使用して、密集したロジックのグループを別々にしするか、以前の実行で得られた良い配置に類似したソリューションが得られるようグローバル配置をガイドします。

密集レポート

密集レポートは、デバイスの密集したエリアとそれらのエリアにあるデザインモジュールの名前を示します。クリティカルパスが密集したエリアの中または近くにある場合、タイミングクロージャの問題が発生する可能性があります。

デザインの密集の解析

デザイン解析レポートを密集モードで生成するには、[Report Design Analysis] ダイアログボックスの [Options] タブで[Congestion] をオンにします。デザインが配置または配線されていることが必要です。未配置のデザインに対してデザイン解析レポートを密集モードで実行しても、何もレポートされません。

重要 : Routed Maximum Level Congestion Reporting (配置後の大レベル密集レポート ) を生成するには、route_design コマンドを実行したのと同じ Vivado セッションで実行する必要があります。配線済みのチェックポイントを読み込んだ場合、この情報はレポートされません。

密集モードのデザイン解析レポートには、次の 5 つの表が含まれます。

1. Placed Maximum Level Congestion Reporting (配置後の大レベル密集レポート )

次の図に、 Placed Maximum Level Congestion Reporting の表の例を示します。このレポートを使用すると、[Congestion] ダイアログボックスにより定義されたデバイスのエリアとそのダイアログボックス内にあるモジュールを調べることができます。リソース使用率から密集エリアに配置されているリソースのタイプがわかります。





この表には、特定の方向で見られる大密集レベル (Window Size) と同じすべてのウィンドウがレポートされます。次の列があります。

° [Direction] : 密集した配線リソースの方向 (North、 South、 West、または East) を示します。

° [Size] : CLB タイルの密集のウィンドウサイズを示します。

° [Congestion] : 定義されたウィンドウでの配線リソースの予測使用率を示します。この値は 100% 以上になることがあります。

° [Congestion Window] : 特定された方向の密集が存在する境界 CLB タイルを示します。CLB 座標は、ウィンドウの左下と右上に対応します。

ヒント : [Congestion Window] 列は、テキストレポートのみに含まれます。 GUI レポートでは、密集ウィンドウを選択すると、 [Device] ウィンドウで密集エリアがハイライトされます。

° [Cell Names] : 密集ウィンドウに関連する階層セルを含む親インスタンスを、割合の大きいものから 3 つまで示します。

ヒント : GUI レポートでは、ハイパーリンクになっているセル名をクリックすると、密集ウィンドウの対応する再開セルがハイライトされます。

° [LUT Usage] : ウィンドウ内での LUT の使用率を示します。

° [Flop Usage] : ウィンドウ内での FD (LD を含む) の使用率を示します。

° [Mux Usage] : ウィンドウ内での MUXF の使用率を示します。

° [RAMB18 Usage] : ウィンドウ内での RAMB18 の使用率を示します。


° [DSP Usage] : ウィンドウ内での DSP の使用率を示します。

Placed Maximum Level Congestion Reporting の表でデザインの密集およびタイミング QoR を解析する際は、次を確認します。

° LUT の使用率が高い場合は、複雑性レポートで LUT6 の割合が大きいインスタンスを調べます。

° 密集エリアで RAMB または DSP の使用率が高い場合は、 Pblock 制約により該当するモジュールの配置エリアが制限されていないかを確認します。配置の -directive オプションで BlockPlacement や SpreadLogic などのモード指定して、密集を緩和します。密集が低く良いタイミング QoR が得られた以前の実行からの RAMBまたは DSPの配置を再利用すると有益な場合があります。

2. SLR Net Crossing Reporting (SLR をまたぐネットのレポート )

SLR Net Crossing Reporting は SSI デバイスに対してのみ生成され、 SLR の境界をまたぐモジュールに含まれるネットの数をレポートします。各モジュールに対し、ネットがまたぐ SLR の詳細情報が示されます。次の図に、SLR Net Crossing Reporting の表の例を示します。


図 3‐22 : Placed Maximum Level Congestion Reporting の表の例





SLR Net Crossing Reporting の表でデザインの密集およびタイミング QoR を解析する際は、次を確認します。

° SSI デバイスを使用している場合は、配置の -directive オプションで SSI 用のモードを使用すると、タイミングおよび密集に両方において有益です。

° 配置の -directive オプションのさまざまなモードを使用した複数のインプリメンテーション run で SLR をまたぐ特定のモジュールに対してタイミング問題が発生する場合は、単純な Pblock を作成してモジュールを 1つの SLR に制約してみてください。

3. および 4. Placed Tile Based Congestion Metric (配置済みタイルベースの密集メトリクス) (Vertical および Horizontal)

Placed Tile Based Congestion Metric は、密集が大のものから 10 個の CLB タイルと、それらの CLB タイルに配置されているセルを含むモジュールを示します。図 3-24 および図 3-25 に、 Placed Tile Based Congestion Metric の垂直 (Vertical) 配線と水平 (Horizontal) 配線の例を示します。このデータは、 [Window] → [Metrics] をクリックして[CLB Metrics] の下にある [Vertical/Horizontal routing congestion per CLB] をクリックしてグラフィカルに表示することもできます。


図 3‐23 : SLR Net Crossing Reporting の表の例


図 3‐24 : Placed Tile Based Congestion Metric (Vertical) の例





° [Tile Name] : 密集が発生している CLB タイルを示します。

° [RPMX/RPMY] : デバイスの CLB の RPM ロケーションを示します。

° [Congestion in Window] : CLB タイルを解する配線リソースの予測使用率を示します。この値は 100% 以上になることがあります。

° [Cell Names] : 密集ウィンドウに関連するセルを含む親インスタンスを、割合の大きいものから 3 つまで示します。

° [Placer Max Overlap?] : タイルが Placed Maximum 領域とオーバーラップしているかを示します。

5. Router Maximum Level Congestion Reporting (配線後の大レベル密集レポート )

Router Maximum Level Congestion Reporting は、配線が同じセッションで実行されている場合にのみ生成され、route_design ログファイルの Congestion Report と似ています。

° [Direction] : 密集の方向を示します。

° [Size] : インターコネクトの密集のウィンドウサイズを示します。 Vivado IDE では、インターコネクトタイルは [Device] ウィンドウで配線リソースを表示した場合にのみ表示されます。


図 3‐25 : Placed Tile Based Congestion Metric (Horizontal) の例


図 3‐26 : Router Maximum Level Congestion Reporting の表の例





° [Congestion] : 定義されたウィンドウで使用されている配線リソースの割合を示します。配線済みデザインでは、この値は 100% 未満である必要があります。

° [Congestion Window (BB)] : 密集ウィンドウの境界インターコネクトを示します。

ヒント : [Congestion Window] 列は、テキストレポートのみに含まれます。 GUI レポートでは、密集ウィンドウを選択すると、 [Device] ウィンドウで密集エリアがハイライトされます。

° [Cell Names] : 密集ウィンドウに関連する階層セルを含む親インスタンスを、割合の大きいものから 3 つまで示します。

ヒント : GUI レポートでは、ハイパーリンクになっているセル名をクリックすると、密集ウィンドウの対応する再開セルがハイライトされます。

° [LUT Usage] : ウィンドウ内での LUT の使用率を示します。

° [Flop Usage] : ウィンドウ内での FD (LD を含む) の使用率を示します。

° [Mux Usage] : ウィンドウ内での MUXF の使用率を示します。



° [DSP Usage] : ウィンドウ内での DSP の使用率を示します。

Router Maximum Level Congestion Reporting の表を解析する際は、次を確認します。

° Window Size が 64x64 を超える場合は、デザインでタイミングが満たされる可能性は低く、配線でエラーが発生することがあります。

° Window Size が 16x16 または 32x32 で、配線でレポートされる密集と配置でレポートされる密集が一致している場合は、 Placed Maximum Level Congestion Reporting の表で密集エリアに配置されているモジュールを特定する必要があります。それらのモジュールに対して密集を緩和する手法を適用するか、配置を -directive オプションで SpreadLogic* などの異なるモードを使用して再実行します。

° Window Size が 8x8 以下の場合は、タイミングバジェットが非常に厳しい場合以外は、密集が問題となることはありません。




第 4章

レポートおよびメッセージ

概要Vivado® 統合設計環境 (IDE) では、さまざまな処理の実行中のデザインまたはデザインプロセスのステートに関する情報がレポートおよびメッセージとして表示されます。レポートは、デザインフローの主要な段階でユーザーまたはツールにより生成され、デザインに関する特定の情報を示します。

メッセージは、デザインプロセスの各段階または多くのユーザー操作に対して、ツールにより自動的に生成されます。

メッセージおよびレポートは、 Vivado IDE の下部の [Messages] ウィンドウおよび [Reports] ウィンドウに表示されます。

次のいずれかのコマンドを実行すると、新しいプロセスが開始します。

• [Run Synthesis]

• [Run Implementation]

• launch_runs (Tcl)


プロセスによりメッセージおよびレポートが生成され、 run をリセットするまでディスクに保持されます。プロジェクトが開いている場合、 run に関連するメッセージが表示されます。 [Messages] ウィンドウには、アクティブ run に関するメッセージのみが表示されます。

レポートは、 Vivado IDE でのさまざまな操作により生成されます。

• デザインを読み込むと、 [Tools] メニューのコマンドを使用して異なるレポートを生成できるようになります。

• 合成またはインプリメンテーションを実行すると、合成レポートまたはインプリメンテーションレポートが生成されます。




第 4 章 : レポートおよびメッセージ

IDE でのメッセージの表示および管理メッセージは、デザインの特定のエレメントに関するステータス情報、またはツール処理中に発生したエラーを示します。

ヒント : メッセージを確認し、デザインに困難な部分や問題が発生している箇所がないかどうかを判断します。

[Reports] ウィンドウの使用

[Reports] ウィンドウには、アクティブな合成またはインプリメンテーション run に関するレポートが表示されます。レポートをダブルクリックすると、テキストエディターで開きます。 [Run Properties] ウィンドウの [Reports] ビューから、 [Design Runs] ウィンドウで選択している run のレポートを表示できます。

[Messages] ウィンドウの使用

メッセージには、次の 2 種類があります。

• ディスクに保存されるメッセージ

• メモリに保存されるメッセージ

[Messages] ウィンドウでは、メッセージが生成された操作ごとにメッセージがグループ化されます。

このウィンドウのツールバーのコマンドボタンを使用して、メッセージ ID またはファイルでメッセージをグループ化できます。

一部のメッセージにはファイルまたはデザインエレメントへのハイパーリンクが含まれており、デバッグに役立ちます。リンクをクリックしてソースを表示します。

ヒント : ポップアップメニューから [Copy Message] をクリックすると、メッセージ全体をコピーして別のウィンドウまたは文書に貼り付けることができます。


図 4‐1 : [Reports] ウィンドウ


図 4‐2 : [Messages] ウィンドウ





各メッセージには、メッセージ ID とメッセージの重要度が付けられています。

• メッセージ ID

メッセージ ID は異なるメッセージを識別するもので、メッセージをグループ化または並べ替えできるようになっています。

• メッセージの重要度

メッセージの重要度は、示されている情報の特性を示します。

デザインをエラボレート、合成、またはインプリメントする前に解決しておく必要があるメッセージもありますが、情報のみのメッセージもあります。情報メッセージは、デザインまたはプロセスの詳細を示しますが、それに対する操作は必要ありません。

表 4‐1 : メッセージの重要度

推奨 : アクティブ合成およびインプリメンテーション run からデザインをメモリに読み込んだときに、すべてのエラーおよびクリティカル警告を確認してください。メッセージには、注意が必要な問題に関する情報が示されます。メッセージには解決策を示す長い説明が含まれているものもあり、メッセージ ID をクリックすると表示できます。

図 4-3 の例を参照してください。この例では、プライマリクロック制約がデザインにないポートを参照しているため( 初の警告) 作成されず ( 初のクリティカル警告)、このクロックを参照する制約も作成されないことを示しています。

アイコン重要度メッセージ

ステータスデザインプロセスに関する一般的なステータスを示します。

情報デザインプロセスに関する一般的なステータスおよびフィードバックを示します。

警告制約または仕様が意図どおりに適用されていないために、適なデザイン結果にならない可能性を示します。

クリティカル警告

ユーザー入力または制約に、適用されなかったり、適切な方法に従っていないものがあり、フローの後の方でエラーが発生する可能性が高いことを示します。ソースおよび制約を確認して、変更を加えることを強くお勧めします。

エラーデザイン結果が使用できない状態になり、ユーザーが対処しないと回避されない問題を示します。デザインフローは停止します。


図 4‐3 : エラーおよびクリティカル警告の確認





メッセージのフィルター処理

メッセージを重要度でフィルターできます。

特定のメッセージタイプを表示または非表示にするには、次の手順に従います。

1. [Messages] ウィンドウに移動します。

2. ウィンドウの上部にあるメッセージの重要度のチェックボックスをオン (表示) またはオフ (非表示) にします。

特定のメッセージ ID の重要度を変更できます。クリティカルでないと思われるメッセージの重要度を下げたり、より注意が必要と思われるメッセージの重要度を上げたりすることができます。

メッセージの重要度を変更するには、 set_msg_config Tcl コマンドを使用します。次に例を示します。

set_msg_config -id "[Common 17-81]" -new_severity "CRITICAL WARNING"

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

Vivado で生成されるレポートおよびメッセージこのセクションでは、 Vivado で生成されるレポートおよびメッセージについて説明します。次の内容が含まれます。

• 「合成のレポートおよびメッセージ」

• 「インプリメンテーションログ」

• 「WebTalk レポート」

合成のレポートおよびメッセージ

Vivado 合成レポートは Vivado 合成の主な出力で、次の情報を含みます。

• 処理されたファイル

° VHDL

° Verilog

° SystemVerilog

° XDC

• セルごとのパラメーター設定

• ドライバーが複数あるネット

• 駆動されていない階層ピン

• 適化情報

• ブラックボックス

• 終的なプリミティブ数

• 階層ごとのセルの使用量

• ランタイムおよびメモリ使用量

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xset_msg_config

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xset_msg_config





重要 : このレポートまたは [Messages] ウィンドウでエラー、クリティカル警告、および警告を確認してください。合成では、フローの後の方で深刻となる可能性のある問題に対して、クリティカル警告または警告が生成されることがあります。

インプリメンテーションログ

Vivado インプリメンテーションログには、次の情報が含まれます。

• 場所、ネットリスト、および使用された制約に関する情報

• ロジック適化タスク。小型で高速なネットリストが生成するため、デフォルトでロジック適化ルーチンが実行されます。

• 配置フェーズおよび配置後のタイミング予測 (WNS および TNS のみ)

• 配線フェーズおよび複数のタイミング予測と配線後の予測タイミングサマリ (WNS、 TNS、 WHS、および THSのみ)

• 各インプリメンテーションコマンドおよびフェーズの経過時間とメモリ

このレポートまたは [Messages] ウィンドウでエラー、クリティカル警告、および警告を確認してください。配置で生成された警告が、フローの後の方でエラーとなる場合があります。個々の段階をそれぞれ実行した場合は、後に実行した段階の結果のみが含まれます。

重要 : タイミングサマリレポートで、パルス幅タイミングサマリおよびタイミング違反や不足している制約に関する情報を確認してください。

WebTalk レポート

WebTalk レポートは、ビットストリーム生成中に生成されます。このレポートは、ユーザーのザイリンクスデバイスの使用に関する情報を収集します。この情報は、ザイリンクスでよりよいツールを提供するために使用させていただきます。機密情報は収集されません。詳細は、次のウェブサイトを参照してください。

http://japan.xilinx.com/webtalk/

デザインに関するレポートの作成このセクションでは、デザインに関するレポートの作成について説明します。次の内容が含まれます。

• 「リソース使用率レポート」

• 「I/O レポート」

• 「クロック使用量レポート」

• 「制御セットレポート」

• 「DRC レポート」

• 「配線ステータスレポート」

• 「ノイズレポート」

• 「消費電力レポート」

リソース使用率レポートリソース使用率レポート (Utilization Report) は、フローのさまざまな段階で report_utilization コマンドを使用して生成できます。この Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参

http://japan.xilinx.com/webtalk/





照 3] を参照してください。 7 シリーズデザインでは、このレポートに run に使用されたデバイスと、次のエレメントの使用率が表示されます (各カテゴリに追加の項目が表示される場合もあり )。

• スライスロジック

° LUT

° MuxFx

° レジスタ

• メモリ

° ブロック RAM

° FIFO

• DSP

• I/O リソース

• クロックリソース

° BUFGCTRL

° BUFR

° BUFHCE

° MMCME2_ADV

° PLLE2_ADV

• 特定のデバイスリソース

° STARTUPE2

° XADC

• 使用数順に並べられたプリミティブタイプの数

• ブラックボックス

• インスタンシエートされたネットリスト

Tcl コンソールから実行する場合、 -cells オプションを使用して特定の階層セルの使用率をレポートできます。Vivado IDE GUI から実行した場合、この情報は表で示されます。

ロジック適化コマンドでネットリストが変更されることがあるので、これらの値はフローの段階によって異なる場合があります。





I/O レポート

I/O レポート (IO Report) は、 ISE® Design Suite の PAD レポートに置き換わるものです。 I/O レポートには、次の情報がリストされます。

• Pin Number : デバイスに含まれるすべてのピンの番号

• Signal Name : ピンに割り当てられたユーザー I/O 名

• Bank Type : I/O が配置されているバンクのタイプ (High Range、 High Performance、 Dedicated など)

• Pin Name : ピンの名前

• Use : I/O の使用タイプ (入力、出力、電源/グランド、未接続など)

• IO Standard : ユーザー I/O の I/O 規格

アスタリスク (*) はデフォルトを示します。これは、 Vivado IDE の [I/O Ports] ウィンドウとは異なります。

• IO Bank : ピンが配置されている I/O バンク

• Drive (mA) : 駆動電流 (mA)

• Slew : バッファーのスルーレート (FAST または SLOW)

• Termination : オンチップおよびオフチップの終端設定

• Voltage : VCCO、 VCCAUX、および関連のピンの値

• Constraint : ピンがユーザーにより制約されている場合は「FIXED」と表示

• Signal Integrity : ピンのシグナルインテグリティ

クロック使用量レポート

クロック使用量レポート (Clock Utilization Report) は、デバイス内のクロックリソースの使用状況を解析するのに役立ちます。クロックの配置問題をデバッグする際に有益です。クロック使用量レポートには、次の情報が含まれます。

• 使用可能、使用済み、および制約されているクロックプリミティブ数

• BUFG ごとのロードおよびスキュー

大遅延およびスキューが大きいネットを確認します。

• MMCM ごとのロードおよびスキュー

ロード数が予測以上、大遅延が大きい、およびスキュー大きいのネットを確認します。

リージョナルクロック

リージョナルクロックネットワークは、グローバルクロックネットワークからは独立しています。グローバルクロックとは異なり、リージョナルクロック信号 (BUFR) の範囲は 1 つのクロック領域内に制限されます。 1 つの I/Oクロック信号が 1 つのバンクを駆動します。

これらのネットワークは、ソース同期インターフェイスデザインで特に有益です。ザイリンクス 7 シリーズ FPGA のI/O バンクのサイズは、クロック領域のサイズと同じです。

ローカルクロック

汎用配線リソースに配線されるクロックネットワークです。

推奨 : ローカルクロックの使用はできる限り避けてください。クロックスキューが大きくなり、 PVT の変動に影響

されやすくなります。インプリメンテーションを実行するたびに、クロックの配線が異なるものになる可能性があり

ます。





クロック使用量レポートの [Locked] 列には、クロックの配置が固定されているか、クロックリソースの配置に制限がないかが示されます。

グローバルクロック数が多すぎる場合、ファンアウトの小さいクロックを BUFH または BUFR などのクロックリソースに移動することを考慮してください。

制御セットレポート

制御セットとは、クロック信号、クロックイネーブル信号、およびセット / リセット信号の組み合わせです。各スライスでは 1 つの制御セットがサポートされ、スライス内のすべてのフリップフロップで使用できます。異なる制御セットのフリップフロップを同じスライスに配置することはできません。

制御セットレポート (Control Sets Report) には、デザインに含まれる固有の制御セット数 (Number of unique control sets)と、デザインの配置に基づく制御セットの配置制限により使用できなくなったレジスタサイトの小数 (MinimumNumber of register sites lost to control set restrictions) が表示されます。

• Clock Signal : 論理クロック信号名

• Enable Signal : 論理クロックイネーブル信号名

• Set/Reset Signal : 論理セット / リセット信号名

• Slice Load Count : 制御セットに接続されているセルに含まれるスライス数

• Bel Load Count : 制御セットに接続されているセルの数

DRC レポート

DRC レポート (DRC Report) は配線により生成されます。配線実行の前に、一般的なデザインの問題がチェックされます。レポートには、 run で使用されたチェックがリストされます。

重要 : クリティカル警告メッセージを確認してください。特定のチェックの重要度が、フローの後の方で上がる可能性があります。

[Report DRC] を使用すると、一般的なデザインの問題およびエラーを確認するデザインルールチェックが実行されます。

エラボレート済みデザイン

I/O、クロック配置、 HDL コードの問題、 XDC 制約に関する DRC が実行されます。 RTL ネットリストには、 I/O バッファー、クロックバッファー、および合成済みデザインには含まれるその他のプリミティブがすべて含まれているわけではありません。エラボレート済みデザインの DRC では、その後の DRC ほど多くのエラーはチェックされません。

合成済みデザインおよびインプリメント済みデザイン

• 合成済みネットリストに関する DRC が実行されます。

• I/O、 BUFG、およびその他の配置がチェックされます。

• MGT、 IODELAY などのプリミティブの配線に関する属性の基本的なチェックが実行されます。

• 同じ DRC が使用可能な配置配線を考慮して実行されます。

• DRC では、情報、警告、クリティカル警告、およびエラーの 4 つの重要度が使用されます。この時点では、クリティカル警告およびエラーでデザインフローが停止することはありません。

インプリメンテーションの段階でも DRC が実行されますが、クリティカルなポイントでフローが停止することがあります。配置配線で配置の妨げとなる問題がチェックされます。特定のメッセージの重要度がフローの段階によって低い場合があります。重要度が低い場合、 opt_design、 place_design、 route_design が停止することはありませんが、ボード上で問題が発生する可能性があります。





たとえば、ユーザーによりすべてのデザインポートのパッケージピンロケーションおよび I/O 規格が手動で指定されているかをチェックする DRC があります。不足している制約がある場合、place_design および route_designではクリティカル警告が表示されますが、これらの DRC 違反は write_bitstream ではエラーとなります。これらの制約がない状態ではデバイスはプログラムできません。

フローの初期段階で重要度を低くしているのは、終的なピン配置が決定される前にデザインをインプリメンテーションまで実行できるようにするためです。包括的な DRC サインオフを実行するには、ビットストリームを生成する必要があります。

図 4-4 に、 DRC レポートを表示する [DRC] ウィンドウを示します。

DRC をクリックすると、 [Violation Properties] ウィンドウにメッセージの詳細が表示されます。 [Detailed] ビューをクリックして詳細を確認してください。多くのメッセージには、ネット、セル、およびポートへのハイパーリンクが含まれています。

DRC レポートは、デザインを変更したときにダイナミックに変化しません。デザインを変更したら、 [Rerpot DRC] を再実行する必要があります。オブジェクトを削除または移動した場合などの操作によりリンクが無効になる場合、ツールでそれが判断されリンクが使用できなくなります。

リンクをクリックするとオブジェクトが選択されますが、 [Properties] ウィンドウは更新されません。オブジェクトのプロパティを表示するには、オブジェクトの選択を一度解除してから選択し直してください。

Tcl で DRC レポートを作成するには、 report_drc コマンドを実行します。


図 4‐4 : DRC レポート


図 4‐5 : [Violation Properties] ウィンドウ





結果をファイルに記述するには、 report_drc -file myDRCs.txt コマンドを実行します。

ヒント : report_drc コマンドの詳細は、「report_drc -help」と入力してください。

配線ステータスレポート

配線ステータスレポート (Route Status Report) は、インプリメンテーション中に生成され、 report_route_statusTcl コマンドを使用して生成できます。

配線ステータスレポートには、デザインのネットに関する次の情報が含まれます。

• デザインに含まれる論理ネットの総数

° 配線リソースが不要なネットの数

- タイル外の配線リソースを使用しないネットの数(CLB、ブロック RAM、 I/O パッドなど)

- ロードのないネットの数

° 配線リソースを不要とする配線可能なネットの数

- 未配線ネットの数

- 完全に配線されたネットの数

° 配線エラーのあるネットの数

- 未配線のピンがあるネットの数

- アンテナ/アイランドがあるネットの数

- リソースの競合があるネットの数

次に、配線済みデザインの配線ステータスレポートの例を示します。

Design Route Status :# nets : ------------------------------------------- :----------- : # of logical nets..........................:6137 : # of nets not needing routing..........:993 : # of internally routed nets........:993 : # of routable nets.....................:5144 : # of fully routed nets.............:5144 : # of nets with routing errors..........:0 : ------------------------------------------- :----------- :





ノイズレポート

[Report Noise] コマンドは、7 シリーズデバイスの同時スイッチノイズ (SSN) 解析を実行します。デフォルトでは、ノイズレポートは Vivado IDE の下部の [Noise] ウィンドウに表示されます。結果は CSV または HTML ファイルにエクスポートできます。

ノイズレポートには、次の 4 つのセクションがあります。

• 「[Summary] セクション」

• 「[Messages] セクション」

• 「[I/O Bank Details] セクション」

• 「[Links] セクション」

[Summary] セクション

次の情報を示します。

• レポートが生成された日時

• 解析されたポート数とその割合

• ステータス (問題が検出されたかどうか)

• クリティカル警告、警告、および情報メッセージの数

[Messages] セクション

レポートの作成中に生成されたメッセージを示します。

[I/O Bank Details] セクション

ピン、 I/O 規格、ノイズマージン値の残りなどの情報を示します。


図 4‐6 : [Report Noise] ダイアログボックス





[Links] セクション

http://japan.xilinx.com/support 上の関連資料へのリンクを示します。

HTML 形式のレポートを生成するには、 [Report Noise] ダイアログボックスでオプションを選択するか、次の Tcl コマンドを使用します。

report_ssn -format html -file myImplementedDesignSSN.html

消費電力レポート

消費電力レポート (Power Report) は配線後に生成され、デバイスの現在の動作条件とデザインのスイッチングレートに基づく消費電力の詳細をレポートします。消費電力解析には、合成済みネットリストまたは配置配線済みデザインが必要です。

• 動作条件を設定するには、 set_operating_conditions コマンドを使用します。

• スイッチングアクティビティを設定するには、 set_switching_activity コマンドを使用します。

[Report Power] コマンドは、合成済みデザインまたはインプリメント済みデザインを開いているときに実行できます。

このレポートでは、次のようなデザイン入力に基づいて消費電力が予測されます。

• ジャンクション温度、周囲温度などの温度値

注記 : set_operating_condition コマンドの -junction_temp オプションを使用すると、ジャンクション温度を設定できます。温度を指定しない場合は、ツールによりデザイン入力に基づいて算出されます。

• ボード層の数、ボードの温度など、選択したボードに関するデータ

• デザインで使用されるエアフローおよびヒートシンクプロファイルのデータ

• 各種電源の FPGA デバイス電流要件のレポート

• 消費電力の分配を詳細に解析することにより、ダイナミック消費電力、温度による消費電力の変動、またはオフチップ消費電力を削減する消費電力節約ストラテジを特定

• シミュレーションアクティビティファイルを使用してより正確な消費電力予測が可能


図 4‐7 : ノイズレポート

http://japan.xilinx.com/support





消費電力レポートの解析

[Report Power] ダイアログボックス (123 ページの図 4-8) を使用し、次のものに基づいて消費電力を解析します。

• 設定

• 消費電力の合計

• 階層

• 電圧レール

• ブロックタイプ


図 4‐8 : [Report Power] ダイアログボックス





消費電力レポートと結果の解析の詳細は、『Vivado Design Suite ユーザーガイド : 消費電力解析と適化』 (UG907) [参照 3] を参照してください。

デフォルトでは、インプリメンテーションプロセスの配線後にテキスト形式の消費電力レポートが生成されます。

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

非プロジェクトモードでは、 link_design または synth_design コマンドを実行した後に report_power コマンドを使用して消費電力レポートを生成できます。使用可能な配置配線情報を使用して、より正確な消費電力予測値が示されます。 Tcl コンソールまたはスクリプトでこのレポートを生成するには、 report_power コマンドを使用します。


図 4‐9 :消費電力レポート




第 5章

タイミング解析の実行

タイミング解析の概要Vivado® 統合設計環境 (IDE) には、レポートを生成するコマンドが複数あり、デザインがタイミング制約を満たしており、アプリケーションボードに読み込む準備ができたかを確認できます。タイミングサマリレポートはタイミングサインオフレポートであり、 ISE® Design Suite の TRCE レポートに相当します。すべてのタイミングチェックの概要が示され、タイミング問題の解析およびデバッグを開始するのに十分な情報が提供されます。詳細は、第 1 章「IDE を使用したロジック解析」を参照してください。

このレポートは、ウィンドウに表示するか、ファイルに保存するか、ログファイルに出力できます。タイミングサマリレポートでタイミングが満たされていない、不足している制約があるなどの結果が示された場合、レポートのさまざまなセクションに示される詳細を確認して、より詳細な解析を実行します。ほかのタイミングレポートでは、特定の状況または特定のロジックに対するより詳細な情報が提供されます。

デザインにタイミング制約を追加する前に、タイミング解析の基本と用語を理解しておく必要があります。この章では、 Vivado 統合設計環境 (IDE) のタイミングエンジンで使用される主要な概念を説明します。

用語

• ソースエッジ : データを送信するソースクロックのアクティブエッジ

• デスティネーションエッジ : データを受信するデスティネーションクロックのアクティブエッジ

• セットアップ要件 : も厳しいセットアップ制約を定義するソースエッジとデスティネーションエッジの関係

• セットアップ関係 : タイミング解析ツールで検証されるセットアップチェック

• ホールド要件 : も厳しいホールド制約を定義するソースエッジとデスティネーションエッジの関係

• ホールド関係 : タイミング解析ツールで検証されるホールドチェック

タイミングパス

タイミングパスは、デザインのインスタンス間の接続に基づいて定義されます。デジタルデザインでは、タイミングパスは同じクロックまたは異なるクロックで制御される順次エレメントのペアで形成されます。

一般的なタイミングパス

デザインに含まれるも一般的なパスは、次のとおりです。

• 「入力ポートから内部シーケンシャルセルまでのパス」

• 「シーケンシャルセル間の内部パス」

• 「内部シーケンシャルセルから出力ポートまでのパス」

• 「入力ポートから出力ポートまでのパス」




第 5 章 : タイミング解析の実行

入力ポートから内部シーケンシャルセルまでのパス

入力ポートから内部シーケンシャルセルまでのパスでは、データが次のように伝搬されます。

• デバイスの外部からボード上のクロックにより入力されます。

• 入力遅延 (SDC 定義) 後にデバイスポートに到達します。

• デバイスの内部ロジックを介して、デスティネーションクロックが供給されるシーケンシャルセルに到達します。

シーケンシャルセル間の内部パス

シーケンシャルセル間の内部パスでは、データが次のように伝搬されます。

• デバイス内でソースクロックが供給されるシーケンシャルセルから駆動されます。

• 内部ロジックを介して、デスティネーションクロックが供給されるシーケンシャルセルに到達します。

内部シーケンシャルセルから出力ポートまでのパス

内部シーケンシャルセルから出力ポートまでのパスでは、データが次のように伝搬されます。

• デバイス内でソースクロックが供給されるシーケンシャルセルから駆動されます。

• 内部ロジックを介して出力ポートに到達します。

• 出力遅延 (SDC 定義) 後にボード上のクロックにより受信されます。

入力ポートから出力ポートまでのパス

入力ポートから出力ポートまでのパスでは、データはデバイス上をラッチされずに伝搬されます。これらのパスは、in-to-out パスとも呼ばれます。入力および出力遅延基準クロックとしては、仮想クロックまたはデザインクロックを使用できます。

タイミングパスの例

図 5-1 に、前述のパスを示します。この例では、デザインクロック CLK0 を DIN および DOUT 遅延制約のボードクロックとして使用できます。


図 5‐1 : タイミングパスの例





タイミングパスのセクション

各タイミングパスは、次の 3 つのセクションから構成されます。

• 「ソースクロックパス」

• 「データパス」

• 「デスティネーションクロックパス」

ソースクロックパス

ソースクロックパスは、ソースクロックがソースポイント (通常は入力ポート ) からソースシーケンシャルセルのクロックピンまで伝搬されるパスです。入力ポートから開始するタイミングパスには、ソースクロックパスはありません。

データパス

データパスは、パスの開始点とパスの終点の間で、データが伝搬されるタイミングパスの部分です。パスの開始点はシーケンシャルセルのクロックピンまたはデータ入力ポートで、パスの終点はシーケンシャルセルのデータ入力ピンまたはデータ出力ポートです。

デスティネーションクロックパス

デスティネーションクロックパスは、デスティネーションクロックがソースポイント (通常は入力ポート ) からデスティネーションシーケンシャルセルのクロックピンまで伝搬されるパスです。出力ポートで終了するタイミングパスには、デスティネーションクロックパスはありません。図 5-2 に、典型的なタイミングパスのこれら 3 つのセクションを示します。

ソースエッジおよびデスティネーションエッジ

データは、シーケンシャルセルまたはポート間を次のように転送されます。

• ソースクロックのエッジの 1 つ (ソースエッジ) で送信されます。

• デスティネーションクロックのエッジの 1 つ (デスティネーションエッジ) で受信されます。

典型的なタイミングパスでは、データは 1 クロック周期の間に 2 つのシーケンシャルセル間を転送されます。その場合、ソースエッジは 0ns、デスティネーションエッジは 1 周期後になります。

次のセクションに、ソースエッジおよびデスティネーションエッジによりタイミング解析用にセットアップ関係とホールド関係を定義する方法を説明します。


図 5‐2 :典型的なタイミングパス





タイミング解析の基礎の理解

大および小遅延解析

タイミング解析は、デザインがハードウェアに読み込まれ、実行されたときのタイミング動作が予測されたものになることをスタティックに検証します。さまざまな製造および環境の変動が考慮され、それらがタイミングコーナーおよびコーナー変動でグループ化された遅延モデルにまとめられています。推奨されるすべてのコーナーに対してタイミングを解析し、各コーナーに対しても見積もりの悪い条件ですべてのチェックを実行すれば十分です。たとえば、ザイリンクス FPGA デバイスをターゲットとするデザインでは、次の 4 つの解析を実行する必要があります。

• スローコーナーでの大遅延解析

• スローコーナーでの小遅延解析

• ファーストコーナーでの大遅延解析

• ファーストコーナーでの小遅延解析

実行したチェックによって、も見積もりの悪い状況を表す遅延が使用されます。この理由から、次のチェックと遅延タイプは常に関連付けられています。

• 「セットアップおよびリカバリチェックと大遅延」

• 「ホールドおよびリムーバルチェックと小遅延」

セットアップおよびリカバリチェックと大遅延

• ソースクロックパスとデータ / リセットパスの累積遅延には、指定のコーナーの低速遅延が使用されます。

• デスティネーションクロックパスの累積遅延には、同じコーナーの高速遅延が使用されます。

ホールドおよびリムーバルチェックと小遅延

• ソースクロックパスとデータ / リセットパスの累積遅延には、指定のコーナーの高速遅延が使用されます。

• デスティネーションクロックパスの累積遅延には、同じコーナーの低速遅延が使用されます。

マップするコーナーによって、これらのチェックは次のものになります。

• 「セットアップ/ リカバリ ( 大遅延解析)」

• 「ホールド / リムーバル ( 小遅延解析)」

セットアップ/リカバリ ( 大遅延解析)

• ソースクロック (Slow_max)、データパス (Slow_max)、デスティネーションクロック (Slow_min)

• ソースクロック (Fast_max)、データパス (Fast_max)、デスティネーションクロック (Fast_min)

ホールド /リムーバル ( 小遅延解析)

• ソースクロック (Slow_min)、データパス (Slow_min)、デスティネーションクロック (Slow_max)

• ソースクロック (Fast_min)、データパス (Fast_min)、デスティネーションクロック (Fast_max)

スラックの算出では、同じパス上で異なるコーナーからの遅延が混合されることはありません。

多くの場合、セットアップまたはリカバリ違反はスローコーナー遅延で発生し、ホールドまたはリムーバル違反はファーストコーナー遅延で発生します。ただし、特に I/O タイミングでは常にこのようになるわけではないので、両方のコーナーで両方の解析を実行することをお勧めします。





セットアップ/リカバリ関係

セットアップチェックは、2 つのクロック間のワーストセットアップ関係に対してのみ実行されます。デフォルトでは、これはソースエッジとデスティネーションエッジの小の正の差に対応します。たとえば、異なるクロックの立ち上がりエッジで動作する 2 つのフリップフロップの間のパスを考えてみます。このパスのソースエッジとデスティネーションエッジは、クロックの立ち上がりエッジのみです。

クロックは次のように定義されます。

• clk0 : 周期 6ns、初の立ち上がりエッジ 0ns、初の立下りエッジ 3ns

• clk1 : 周期 4ns、初の立ち上がりエッジ 0ns、初の立下りエッジ 2ns

図 5-3 に示すように、 2 つのセットアップ関係 Setup(1) と Setup(2) があります。

clk0 から clk1 までの小の正の差は 2ns で、これは Setup(2) に対応します。共通周期は 12ns で、 2 つのクロックの 2 つの同時アライメント間の時間に対応します。

ヒント : クロック関係は、クロックルートからフリップフロップのクロックピンまでの挿入遅延を適用する前の理想的なクロック波形を使用して確立されます。

重要 : 両方のクロックの 1,000 サイクルの間に共通周期が見つからない場合は、これらの 1000 サイクルにおける悪のセットアップ関係がタイミング解析に使用されます。これら 2 つのクロックは、共通周期のないクロックと呼ばれます。解析は、ワースト状況に対応しないと考えられます。これらのクロック間のパスを確認し、その有効性を評価し、非同期パスとして処理できるかどうかを判断する必要があります。

パス要件がわかったら、スラックの算出にパス遅延、クロックのばらつき、およびセットアップタイムが追加されます。一般的なスラックの式は、次のとおりです。

これらの式が示すように、所要時間の前にデータが到着すると、セットアップスラックが正になります。


図 5‐3 : セットアップ関係

データ所要時間 (セットアップ) = デスティネーションエッジ時間

+ デスティネーションクロックパス遅延

- クロックのばらつき

- セットアップタイム

データ到着時間 (セットアップ) = ソースエッジ時間

+ ソースクロックパス遅延

+ データパス遅延

スラック (セットアップ) = データ所要時間 – データ到着時間





リカバリチェックはセットアップチェックと似ていますが、プリセットやクリアなどの非同期ピンに適用されます。関係はセットアップと同様に確立され、スラックの式もセットアップタイムの代わりにリカバリタイムが使用されることを除けば同じです。

ホールド /リムーバル関係

ホールドチェック (ホールド関係) は、セットアップ関係と直接関連しています。セットアップ解析は、も見積もりの悪い条件でもデータが正しく受信されるかどうかを検証しますが、ホールド関係では次を検証します。

• セットアップソースエッジで送信されたデータが、セットアップデスティネーションエッジの前のアクティブエッジでキャプチャされない (図 5-4 「セットアップ関係ごとのホールド関係」で H1a および H2a はセットアップエッジ S1 および S2 に対応)。

• セットアップソースエッジの後の次のアクティブソースクロックエッジで送信されたデータが、セットアップデスティネーションエッジでキャプチャされない (図 5-4 「セットアップ関係ごとのホールド関係」で H2a および H2b はセットアップエッジ S1 および S2 に対応)。

ホールド解析では、 2 つのクロック間のワーストホールド関係のみがレポートされます。ワーストホールド関係が、ワーストセットアップ関係に関連付けられているとは限りません。タイミングエンジンでは、可能なすべてのセットアップ関係とそれに対応するホールド関係を評価し、ワーストホールド関係を特定する必要があります。

たとえば、セットアップ関係の例と同じパスを考えます。 2 つのセットアップ関係があります。

次の図に、セットアップ関係ごとに 2 つのホールド関係があることを示します。

大ホールド要件は 0ns で、ソースクロックとデスティネーションクロック両方の初の立ち上がりエッジに対応します。

パス要件がわかったら、スラックの算出にパス遅延、クロックのばらつき、およびホールドタイムが追加されます。一般的なスラックの式は、次のとおりです。

これらの式が示すように、所要時間の後に新しいデータが到着すると、ホールドスラックが正になります。

リムーバルチェックはホールドチェックと似ていますが、プリセットやクリアなどの非同期ピンに適用されます。関係はホールドと同様に確立され、スラックの式もホールドタイムの代わりにリムーバルタイムが使用されることを除けば同じです。


図 5‐4 : セットアップ関係ごとのホールド関係

データ所要時間 (ホールド ) = デスティネーションエッジ時間

+ デスティネーションクロックパス遅延

- クロックのばらつき

+ ホールドタイム

データ到着時間 (ホールド ) = ソースエッジ時間

+ ソースクロックパス遅延

+ データパス遅延

スラック (ホールド ) = データ到着時間 – データ所要時間





パス要件

パス要件は、タイミングパスのデスティネーションエッジとソースエッジの時間差を表します。

たとえば、前のセクションと同じパスとクロックを考えると、次のパス要件が存在します。

セットアップパス要件 (S1) = 1*T(clk1) - 0*T(clk0) = 4nsセットアップパス要件 (S2) = 2*T(clk1) - 1*T(clk0) = 2ns

対応するホールド関係は次のとおりです。

• セットアップ S1 に対応するホールド関係

ホールドパス要件 (H1a) = (1-1)*T(clk1) - 0*T(clk0) = 0nsホールドパス要件 (H1b) = 1*T(clk1) - (0+1)*T(clk0) = -2ns

• セットアップ S2 に対応するホールド関係

ホールドパス要件 (H2a) = (2-1)*T(clk1) - 1*T(clk0) = -2nsホールドパス要件 (H2b) = 2*T(clk1) - (1+1)*T(clk0) = -4ns

タイミング解析は、 2 つのも見積もりの悪い要件でのみ実行されます。上記の例では、次の 2 つです。

• セットアップ要件 S2

• ホールド要件 H1a

クロックのスキューとばらつき

スキューとばらつきは、どちらもセットアップとホールドの算出およびスラックに影響します。

スキューの定義

クロックスキューは、デザインの共通点から終点および開始点のセルクロックピンまでの、デスティネーションクロックパスとソースクロックパスの挿入遅延の差です。

次の式で、 Tcj および Tci は次のように定義されます。

• Tcj : 共通ノードから終点クロックピンまでの遅延

• Tci : 共通ノードから開始点クロックピンまでの遅延

Tskewi,j = Tci- Tcj





Clock Pessimism Removal (CPR)

一般的なタイミングパスレポートには、ルートからシーケンシャルセルのクロックピンまでの、ソースおよびデスティネーションクロックパスの遅延の詳細が示されます。下に説明するように、ソースおよびデスティネーションクロックは、共通回路上であっても、異なる遅延で解析されます。

共通部分のこの遅延差により、スキュー算出における見積もりがさらに悪くなります。非現実的なスラックが算出されないようにするため、この不必要に悪い見積もり部分が Clock Pessimism Removal (CPR) 値と呼ばれる遅延により補正されます。

Clock Pessimism Removal (CPR) = 共通クロック回路 ( 大遅延 – 小遅延)

CPR は、実行する解析のタイプによって、スキューに加算されるか、スキューから減算されます。

• 大遅延解析 (セットアップ/ リカバリ )

CPR はデスティネーションクロックパス遅延に加算されます。

• 小遅延解析 (ホールド / リムーバル)

CPR はデスティネーションクロックパス遅延から減算されます。

Vivado Design Suite では、各タイミングパスのクロックスキューが次のようにレポートされます (この場合はホールド解析)。

• DCD : デスティネーションクロック遅延

• SCD : ソースクロック遅延

• CPR : Clock Pessimism Removal

Clock Path Skew0.301ns (DCD - SCD - CPR)Destination Clock Delay (DCD): 2.581nsSource Clock Delay (SCD): 2.133nsClock Pessimism Removal (CPR): 0.147ns

多くの場合、 CPR の精度は配線の前後で変わります。たとえば、ソースクロックとデスティネーションクロックが同じで、開始点クロックピンと終点クロックピンが同じクロックバッファーで駆動されるタイミングパスがあるとします。

配線前は、共通点はクロックネットドライバー (クロックバッファーの出力ピン) です。 CPR は、クロックルートからクロックバッファーの出力ピンまでの不必要に悪い見積もり部分のみを補正します。

配線後は、共通点はデバイスアーキテクチャのソースクロックパスとデスティネーションクロックパスで共有される後の配線リソースです。この共通点はネットリストには表されないので、タイミングレポートから共通クロック


図 5‐5 : クロックツリーの共通部分





回路の遅延差を減算することにより対応する CPR を直接求めることはできません。タイミングエンジンは、ユーザーが直接アクセスできないデバイス情報に基づいて CPR 値を算出します。

見積もりの良いスキュー

ザイリンクス FPGA デバイスには、専用クロック配線ツリーやクロック調整ブロック (CMB) などのアドバンスクロックリソースが含まれます。一部の CMB では、位相ロックループ回路 (PLL または MMCM プリミティブに含まれる ) を使用することにより、クロックツリーの挿入遅延を補正できます。補正量は、 PLL のフィードバックループに存在する挿入遅延に基づきます。多くの場合、フィードバックループを含め、同じタイプのバッファーの複数のクロックツリーが PLL (または MMCM) で駆動されます。大型のデバイスでは、すべてのクロックツリー分岐の挿入遅延がフィードバックループ遅延に一致するとは限りません。フィードバックループの遅延がソースまたはデスティネーションクロック遅延よりも大きい場合、PLL で駆動されるクロックが過剰に補正されることになります。この場合、 CPR の符号が変わり、スラック値からスキューの見積もりの良い部分が効果的に削除されます。これは、解析中にタイミングパスクロックの共通ノードに誤ったスキューがないようにするために必要です。

推奨 : タイミング解析では CPR 補正を常に使用し、スラックを正確なものにし、サインオフ用のタイミングのクオリティを保持してください。

クロックのばらつき

クロックのばらつきは、クロックエッジのペア間での時間の変動量の合計です。ばらつきは、算出されるクロックジッター (システム、入力、および個別)、一部のハードウェアプリミティブにより発生する位相エラー、デザイン制約でユーザーにより指定されるクロックのばらつき (set_clock_uncertainty) で構成されます。

プライマリクロックのジッターは、 set_input_jitter および set_system_jitter により定義されます。MMCM や PLL などのクロック生成ブロックに対しては、ソースクロックに指定されたジッターとコンフィギュレーションに基づいて、ジッターが自動的に算出されます。フリップフロップベースのクロック分周器などその他の生成クロックのジッターは、ソースクロックと同じになります。

ユーザーが指定するクロックのばらつきは、 Vivado Design Suite タイミングエンジンで算出されるばらつきに加算されます。ソースクロックにユーザーが指定したばらつきは、 MMCM、 PLL、フリップフロップベースのクロック分周器などを介して生成クロックに伝搬されません。

ジッターおよび位相エラーの定義の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

クロックのばらつきの指定には、次の 2 つ目的があります。

• ハードウェアの機能に影響するクロックのノイズを表すため、スラック値にある程度のマージンを保持します。遅延値およびジッター値は大きめに見積もられるので、通常はハードウェアが正しく機能するようばらつきを追加することはお勧めしません。

• 一部のインプリメンテーション手順でクロックまたはクロックペアに関連するパスの制約を厳しくします。これにより使用可能な QoR マージンが増加し、次の手順でこれらのパスのタイミングクロージャを達成するのに役立ちます。クロックのばらつきを使用することにより、クロック波形およびその関係が変更されることはないので、残りのタイミング制約は正しく適用されます。

パルス幅チェック

パルス幅チェックは、信号がデバイス内で伝搬され、ハードウェアプリミティブに到達したときの波形に対して実行されるルールチェックです。これらは通常、プリミティブ内の回路により決定される機能制限に対応します。たとえば、 DSP クロックピンに対する小周期チェックは、 DSP インスタンスを駆動するクロックが内部 DSP で許容される周波数を超える周波数で動作していないことを確認します。

パルス幅チェックは、合成またはインプリメンテーションには影響しません。これらのチェックは、 Vivado DesignSuite で提供されるその他のデザインルールチェックと同様、ビットストリームの生成前に一度実行する必要があります。





パルス幅違反が発生した場合は、クロック定義が不適切であるか (パルス幅および周期チェック )、大きなスキューを発生させるクロックトポロジ (max_skew チェック ) が原因です。ターゲットデバイスのザイリンクス FPGA データシートを参照して、違反が発生したプリミティブの動作範囲を理解する必要があります。スキュー違反が発生した場合は、クロックツリーを簡略化するか、クロックリソースを違反の発生したピンの近くに配置します。

タイミングサインオフの確認タイミング解析の詳細を説明する前に、デザインがハードウェアで実行する準備ができたことが、タイミングレポートのどの部分に示されるかを知っておくことが重要です。

重要 : デザインが完全に配置配線されたら、タイミングサインオフはインプリメンテーション結果の解析における必須の手順です。

デフォルトでは、 Vivado Design Suite でプロジェクトを使用する場合、テキスト形式のタイミングサマリレポートが自動的に生成されます。このレポートは、インプリメンテーション後にメモリにデザインチェックポイントを読み込んで、インタラクティブなバージョンを生成することもできます。

タイミングサインオフの基準

タイミングサインオフには、次の 2 つの基準があります。

• デザインが完全に制約されている

• デザインのタイミングが満たされている

デザインが完全に制約されている

デザインが完全に制約されているかを確認するには、 [Check Timing] セクションを参照します。次を確認します。

• 定数でないクロックピンに定義されたクロックが供給されている (no_clock チェック )。

• すべての内部パスの終点にタイミングが設定されている (unconstrained_internal_endpoint チェック )。

• 入力ポートおよび出力ポートがすべて制約されている (no_input_delay、 no_output_delay、partial_input_delay、 partial_output_delay チェック )。

次の 2 つのチェックでレポートされた問題は、詳しく検証して解決する必要があります。

• すべての生成クロックに正しくタイミングが設定されていない (generated_clock チェック )。この状況は、生成クロックとマスタークロックの間に論理タイミングパスまたはアクティブタイミングパスがない場合に発生します。これはスキューの算出に影響し、スラック違反が発生する可能性があります。

• デザインに組み合わせループが存在する (loops チェック )。組み合わせループはタイミングエンジンによりランダムな場所で分割されるため、解析の適用範囲が削減されます。

後の 2 つのチェックは情報用であり、通常タイミングが不必要に悪く見積もられた状況を示します。

• ラッチを伝搬される組み合わせループが存在する (latch_loops チェック )。Vivado IDE タイミングエンジンでは latch_loops は分割されませんが、借りることができる大時間を考慮するので、ラッチタイミング解析が不必要に悪く見積もられる可能性があります。

• クロックピンに存在するすべてのクロックが排他的でない (multiple_clocks チェック )。このチェックは、現実的でないタイミングパスにタイミングが適用されている状況を示しており、デザインのほかの部分には適切にタイミングが適用されている場合がほとんどなので、このチェックで問題が報告されないようにする必要は通常ありません。現実的でないタイミングパスにより、インプリメンテーションツールによりタイミングクロージャを達成するのが困難になる場合もあります。





ヒント : 一部の不足制約はそのまま放置できますが、デザインのサインオフの質は下がります。

デザインのタイミングが満たされている

• トータルネガティブスラック (TNS) が 0ns である必要があります。これは、大遅延解析 (セットアップ/ リカバリ ) に対応します。

• トータルホールドスラック (THS) が 0ns である必要があります。これは、小遅延解析 (ホールド / リムーバル) に対応します。

• トータルパルス幅スラック (TPWS) が 0ns である必要があります。これは、 ISE のコンポーネントピンスイッチ制限と同等です。大および小遅延解析の両方で実行されます。

TNS、 THS、および TPWS の合計が、 ISE の終的なタイミングスコアに相当します。

タイミングに問題がないかどうかの確認

次の図に、タイミングに問題のないことを確認するために初にチェックする必要のある情報を緑で囲んで示します。


図 5‐6 : タイミングサマリレポートでのタイミングサインオフ





次の図に、テキスト形式のレポートの [Check Timing] セクションを示します。


図 5‐7 : テキスト形式のタイミングサマリレポートの [Check Timing] セクション





次の図に、テキスト形式のレポートの [Design Timing Summary] セクションを示します。

タイミング違反の調査

Vivado IDE では、スラック違反は赤で表示され、不足している制約は特定の色で表示されます。

タイミング違反を調べるには、まず次のセクションを参照します。

• [Intra-Clock Paths]、[Inter-Clock Paths]、および [Path Groups] (**async_default**) セクションには、セットアップおよびリカバリ違反およびホールドおよびリムーバル違反に関する情報が示されます。

• [Intra-Clock Paths] セクションには、パルス幅チェック違反の詳細が示されます。

[Timing] ウィンドウの詳細は、 21 ページの「タイミングサマリレポート」のを参照してください。

ヒント : 違反のみを表示するには、ツールバーの [Show only failing paths] をクリックします。

デフォルトでは、各解析で各クロックペアに対して N 個のワーストパスの詳細が表示されます。

• GUI のデフォルトは N = 10 です。

• report_timing_summary コマンドのデフォルトは N = 1 です。

パスをダブルクリックすると、そのタイミングパスの詳細情報が新しいウィンドウに表示されます。レポートされているパスの数が十分でない場合は、レポートされるパス数を増加して [Report Timing Summary] を再実行するか (同等の Tcl コマンド : report_timing_summary -max_paths N)、特定のクロックペアまたは特定のタイミングパスに対して [Report Timing] を実行します。


タイミングパスレポートの解釈タイミングサマリレポートでパスをダブルクリックしたときに表示されるタイミングパスレポートには、タイミング違反の原因を理解するのに必要な情報が含まれています。次のセクションで、タイミングパスレポートについて説明します。

タイミングパスに関する重要な情報を示します。タイミングパスの詳細を解析せずに、違反の原因を知ることができます。スラック、パスの要件、データパス遅延、セル遅延、配線遅延、クロックスキュー、およびクロックのばらつきが示されます。セルの配置に関する情報は含まれません。

タイミング制約およびタイミング解析で使用される用語、およびスラックおよびパスの要件の決定方法は、 128 ページの「タイミング解析の基礎の理解」を参照してください。


図 5‐8 : テキスト形式のタイミングサマリレポートの [Design Timing Summary] セクション





タイミングパスサマリのヘッダーの例図 5-9 に、テキスト形式のレポートのタイミングパスサマリヘッダーを示します。

図 5-10 に、 Vivado IDE でのタイミングパスサマリヘッダーを示します。

タイミングパスサマリのヘッダー情報

タイミングパスサマリヘッダーには、次の情報が含まれます。

• Slack

正のスラック値は、パスがタイミング制約から算出されたパスの要件を満たしていることを示します。スラックを求める式は、解析によって異なります。

° 大遅延解析 (セットアップ/ リカバリ )スラック = データ所要時間 – データ到着時間

° 小遅延解析 (ホールド / リムーバル)スラック = データ到着時間 - データ所要時間

データ所要時間とデータ到着時間は、タイミングパスレポートの別のセクションに表示されます。


図 5‐9 : テキスト形式のタイミングパスサマリヘッダー


図 5‐10 : Vivado IDE のタイミングパスサマリヘッダー





• Source

パスの開始点およびデータを送信するソースクロックを示します。開始点は通常、シーケンシャルセルのクロックポートまたは入力ポートです。

2 行目がある場合は、プリミティブおよびクロックピンの認識されるエッジが示されます。クロック名とクロックエッジの定義 (波形および周期) も示されます。

• Destination

パスの終点およびデータを受信するデスティネーションクロックを示します。終点は通常、デスティネーションシーケンシャルセルの入力データピンまたは出力ポートです。2 行目がある場合は、プリミティブおよびクロックピンの認識されるエッジが示されます。クロック名とクロックエッジの定義 (波形および周期) も示されます。

• Path Group

パスの終点が属するタイミンググループを示します。これは通常デスティネーションクロックにより定義されるグループですが、非同期タイミングチェック ( リカバリ / リムーバル) では **async_default** タイミンググループにまとめられます。ユーザー定義のグループもここに表示されます。これらは、レポート生成で便利です。

• Path Type

このパスで実行された解析のタイプを示します。

° Max : データパス遅延の算出に大遅延値が使用されたことを示します。セットアップ解析およびリカバリ解析に対応します。

° Min : データパス遅延の算出に小遅延値が使用されたことを示します。ホールド解析およびリムーバル解析に対応します。

使用されたコーナー (Slow または Fast) も示されます。

• Requirement

タイミングパス要件を示します。開始点と終点が同じクロックで制御されている場合、タイミングパス要件は通常次のようになります。

° セットアップ/ リカバリ解析では 1 クロック周期

° ホールド / リムーバル解析では 0ns

パスが 2 つのクロックの間にある場合、要件はソースクロックエッジとデスティネーションクロックエッジの小の正の差に対応します。この値は、マルチサイクル、大遅延、小遅延などのタイミング例外制約に置き

換えられます。

タイミング制約からタイミングパス要件を求める方法の詳細は、 125 ページの「タイミングパス」を参照してください。

• Data Path Delay

パスのロジックセクション間で累積された遅延を示します。クロックがデータとして使用されている場合を除き、クロック遅延は含まれません。遅延のタイプは、 [Path Type] と同じです。

• Logic Levels

パスのデータセクションに含まれている、開始セルと終了セルを除く各種プリミティブの段数を示します。

• Clock Path Skew

ソースクロックの送信エッジとデスティネーションクロックの受信エッジ間の挿入遅延差およびクロックの不必要に悪い見積もり部分の削除を示します。





• Destination Clock Delay (DCD)

デスティネーションクロックのソースポイントからパスの終点までに累積される遅延を示します。

° 大遅延解析 (セットアップ/ リカバリ ) では小セルおよびネット遅延値が使用されます。

° 小遅延解析 (ホールド / リムーバル) では大遅延値が使用されます。

• Source Clock Delay (SCD)

クロックのソースポイントからパスの開始点までに累積される遅延を示します。

° 大遅延解析 (セットアップ/ リカバリ ) では大セルおよびネット遅延値が使用されます。

° 小遅延解析 (ホールド / リムーバル) では小遅延値が使用されます。

• Clock Pessimism Removal (CPR)

ソースおよびデスティネーションクロックが共通回路上であっても異なる遅延でレポートされることにより発

生する、追加のクロックスキューの絶対値を示します。

この不必要に悪い見積もり部分の削除すると、共通回路上にあるソースクロックとデスティネーションクロッ

クの間にスキューは発生しません。

配線済みのデザインでは、後の共通クロックツリーノードは通常クロックネットで使用される配線リソース

にあり、パスの詳細にはレポートされません。

• Clock Uncertainty

クロックエッジのペア間での時間の変動量の合計を示します。

ばらつきは、算出されるクロックジッター (システムおよび個別)、一部のハードウェアプリミティブにより発

生する位相エラー、デザイン制約でユーザーにより指定されるクロックのばらつき

(set_clock_uncertainty) で構成されます。

ユーザーが指定するクロックのばらつきは、 Vivado IDE タイミングエンジンで算出されるばらつきに加算され

ます。

• Total System Jitter (TSJ)

ソースクロックおよびデスティネーションクロックの両方に適用されるシステムジッターを示します。システ

ムジッターは、 set_system_jitter 制約を使用してグローバルに変更できます。仮想クロックは理想的なク

ロックなので、システムジッターはありません。

• Total Input Jitter (TIJ)

ソースクロックおよびデスティネーションクロックの両方に適用される入力ジッターを示します。

set_input_jitter 制約を使用すると、各プライマリクロックの入力ジッターを個別に指定できます。生成ク

ロックの入力ジッターは、マスタークロックジッターおよび伝搬されるクロックリソースに基づいて VivadoIDE タイミングエンジンで算出されます。デフォルトでは、仮想クロックは理想的なクロックであり、ジッター

はありません。

クロックのばらつきおよびジッターの詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] のこのセクションを参照してください。

• Discrete Jitter (DJ)

MMCM や PLL などのハードウェアプリミティブにより追加されるジッター量を示します。

この値は、これらのセルのコンフィギュレーションに基づいて Vivado IDE タイミングエンジンにより算出されます。

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug903-vivado-using-constraints.pdf;a=xClockLatencyJitterAndUncertainty





• Phase Error (PE)

MMCM や PLL などのハードウェアプリミティブにより追加される、 2 つのクロック信号間の位相の変動量を示します。

この値は、これらのセルのコンフィギュレーションに基づいて Vivado IDE タイミングエンジンにより算出されます。

• User Uncertainty (UU)

set_clock_uncertainty 制約で指定された追加のばらつきを示します。

このコマンドの使用方法の詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] のこのセクションを参照してください。

タイミングパスサマリには、タイミング制約、レポートされるパス、およびターゲットデバイスによって、次の 3つの行が表示されることもあります。

• Inter-SLR Compensation

7 シリーズ SSI デバイスのみで、 SLR の境界をまたがるパスを確実にレポートするために必要な追加マージンを示します。

• Input Delay

set_input_delay 制約により入力ポートに指定された入力遅延値を示します。入力ポートから開始しないパスは含まれません。

• Output Delay

set_output_delay 制約により出力ポートに指定された出力遅延値を示します。出力ポートで終了しないパスは含まれません。

• Timing Exception

パスに適用されるタイミング例外を示します。優先順位のも高い例外のみがタイミングパス要件に影響するので、優先順位のも高い例外のみが示されます。

タイミング例外およびその優先順位の詳細は、 125 ページの「タイミングパス」を参照してください。

タイミングパスの詳細

レポートの後半には、パスが伝搬されるセル、ピン、ポート、およびネットの詳細が表示されます。 3 つのセクションに分かれています。

• Source Clock Path

ソースクロックがソースポイントからデータパスの開始点まで伝搬されるパスを示します。このセクションは、入力ポートから開始するパスには含まれません。

• Data Path

データが開始点から終点まで伝搬されるパスを示します。

• Destination Clock Path

デスティネーションクロックがソースポイントからデータパスの終点のクロックピンまで伝搬されるパスを示します。

[Source Clock Path] および [Data Path] セクションには、これらでは、常に同じタイプの遅延がレポートされます。

• セットアップ/ リカバリ解析では大遅延

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xset_clock_uncertainty

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf;a=xset_clock_uncertainty





• ホールド / リムーバル解析では小遅延

データの送信エッジ時間から開始し、ソースクロックおよびデータパスを介して累積される遅延も同じです。終的な累積遅延値は、データ到着時間と呼ばれます。

デスティネーションクロックパスは、常にソースクロックおよびデータパスと逆の遅延でレポートされます。初期の累積遅延値は、データ受信エッジがデスティネーションクロックのソースポイントから出発した時間です。終的な累積遅延値は、データ所要時間と呼ばれます。

レポートの後の行は、スラックの算出方法を示します。

• 大遅延解析 (セットアップ/ リカバリ )

スラック = データ所要時間 – データ到着時間

• 小遅延解析 (ホールド / リムーバル)

スラック = データ到着時間 - データ所要時間

テキスト形式レポートのタイミングパスの詳細

図 5-11 「テキスト形式レポートのタイミングパスの詳細」に、テキスト形式のレポートのソースクロック、データ、およびデスティネーションクロックパスの部分を示します。パスには 5ns の周期制約が適用されているので、ソースクロックの送信エッジは 0ns で開始し、デスティネーションクロックの受信エッジは 5ns で開始します。


図 5‐11 : テキスト形式レポートのタイミングパスの詳細





Vivado IDE のタイミングパスの詳細

143 ページの図 5-12に、 142 ページの図 5-11のテキスト形式レポートと同じ例の IDE レポートを示します。


図 5‐12 : Vivado IDE のタイミングパスの詳細





パスの情報は、 5 つの列で示されます。

• [Location]

デバイス上でセルまたはポートが配置されている位置を示します。

• [Delay Type]

Unisim プリミティブとパスが通過するタイミングアークを示します。ネットの場合、ファンアウト (fo) およびそのステータスを示します。ネットのステータスは、次のとおりです。

° [Unplaced] : ドライバーおよびロードは配置されていません。

° [Estimated] : ドライバーまたはロード、あるいはその両方が配置されています。部分的に配線されているネットも Estimated と示されます。

° Routed : ドライバーおよびロードの両方が配置され、ネットが完全に配線されています。

• [Incr(ns)] (テキストレポート ) / [Delay] (IDE レポート )

Unisim プリミティブのタイミングアークまたはネットに関連するインクリメンタル遅延値を示します。入力/出力遅延、クロックのばらつきなどの制約を示すこともあります。

• [Path(ns)] (テキストレポート ) / [Cumulative] (IDE レポート )

パスの各セグメントまでの累積遅延を示します。値は、前の行までの累積値と、その行のインクリメント遅延を加算したものです。

• [Netlist Resource(s)] (テキストレポート ) / [Logical Resource] (IDE レポート )

通過したネットリストオブジェクトの名前を示します。

各インクリメンタル遅延は、次のいずれかのエッジに関連付けられています。

• r (立ち上がりエッジ)

• f (立ち下がりエッジ)

初期のエッジは、解析に使用される送信エッジまたは受信エッジにより決定されますが、タイミングアークの特性によって、パス上のセルで反転されることがあります。たとえば、インバーターの入力の立ち上がりエッジは、出力では立ち下がりエッジになります。

必要以上に厳しいタイミングパス要件が、ソースクロックツリーまたはデスティネーションクロックツリーによるクロックエッジの反転によるものである場合があります。




第 6章

デザインクロージャテクニック

制約およびソースのチェックデザインおよびタイミング制約が適切であるかを確認します。

• ネットリストが質のよいものであることを確認します。

Vivado 合成を使用する場合は、合成特定のタイミング制約を XDC ファイルに追加します。合成はタイミングドリブンであり、タイミングを満たすようにロジックが適化されます。

• [Schematic] または [Clock Networks] ウィンドウでクロックツリーを確認します。

クロックツリーが適切なものであることを確認します。 BUFG が別の BUFG や LUT を駆動していると、クロックスキューが大きくなります。追加のクロックスキューにより、セットアップチェックを満たすためのデザインマージンが小さくなるか、なくなることがあり、配線リソースの使用率が増加し、密集度が高くなることがあります。配置 DRC でクロックツリーの問題が警告として表示されることがあります。

• デザインのピン配置およびフロアプランを実行する際、クロックリソースを考慮します。

7 シリーズ FPGA デバイスのクロック領域では、領域ごとに 12 個のグローバルクロックがサポートされます。クロックツリーの配置には、その他の制限もあります。詳細は、『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472) [参照 9] を参照してください。

• クロック周期がデザインで必要なものであるかどうかを確認します。

デザインの制約を厳しくしすぎると、不必要に厳しいタイミング制約を満たすためにランタイムが長くなります。タイミングエラーが発生したり、消費電力が大きくなる原因にもなります。

不必要に厳しい制約が満たされない場合は、実際の制約を試してみてください。 Vivado IDE では、配置配線を変更せずにタイミング制約を変更できます。実際のクロック周期で report_timing_summary を再実行します。

• タイミングを満たしていないパスがマルチサイクルパスまたは機能的にアクティブでないパスでないかを確認します。

Vivado IDE では、タイミング例外を設定していなければ、非同期クロック間のパスも含め、デザインのすべての論理パスにタイミングが適用されます。これは、 ISE® Design Suiteおよび UCF とは異なります。制御ロジックの構造により、アクティブにならないパスもあります。 set_false_path 制約を使用して、スラックの算出においてこれらのパスを無視できます。

ステートマシンで駆動されるクロックイネーブルなどの制御構造では、マルチサイクルパスが生成されます。データがソースからデスティネーションに到達するのに複数のクロック周期が必要な場合、マルチサイクルタイミング制約を設定します。 XDC では、セットアップとホールドのマルチサイクル遅延は個別に入力します。

• インプリメンテーション後に、タイミング制約を変更してタイミングを再実行します。タイミング制約の変更がデザインのタイミングにどのように影響するかを調べるのに、インプリメンテーションを再実行する必要はありません。制約を変更してタイミングを確認し、必要に応じてタイミング制約を調整していきます。




第 6 章 : デザインクロージャテクニック

• タイミング制約を変更してもタイミングが満たされない場合は、インプリメンテーションを再実行します。インプリメンテーションはタイミングドリブンであり、問題のある箇所に焦点が置かれます。配線後のデザインのトータルホールドスラック (THS) が大きかった場合は、インプリメンテーションを再実行する必要があります。

ヒント : 新しい制約を保存するのに [Save Constraints As] を使用し、元の制約を保持しておくと便利です。

• タイミングパスを確認します。

クロックスキューおよびジッターが適切であるかを確認します。

• ロジックを確認します。

周期に対するロジック遅延を確認し、ロジック遅延の周期に占める割合が高い場合は、再合成してロジック遅延を削減する必要があります。

• 配線遅延を確認します。

配線遅延の周期に占める割合が高い場合は、配線遅延を削減します。配線遅延を削減するには、次の 2 つの方法があります。

° RTL を記述し直します。

ファンアウトの大きいネットがある場合は、ドライバーを複製してみてください。ファンアウトの大きいネットのドライバーを複製する場合、配置を考慮してください。各ドライバーがその近くにあるロードと接続されるようにし、ロードが分散しないようにします。

DONT_TOUCH または KEEP などの合成属性を適用して、複製されたレジスタが適化で削除されないようにします。

° フロアプランします。

配線遅延のタイミングパスに占める割合が高い場合は、フロアプランを考慮します。目的は、配線遅延を削減して、クリティカルパスのタイミングを改善することです。フロアプランによりクリティカルパスを構成するロジックは変更されません。フロアプランの際は、デザインのブロック同士の接続を確認してください。

RTL の構造を変更した方がよい場合もあります。合成時には、配置はわかっていません。合成でファンアウトの大きいネットが複製される場合、配置は考慮されません。

手動で複製して配線し直した方が、デザインが向上する場合があります。たとえば、 2 つのメモリインターフェイスがあり、チップの反対側の角に配置される場合、 RTL ソースで制御信号を複製すると有益です。合成属性を使用して、論理的に等価なレジスタが適化で削除されないように設定する必要がある場合もあります。

ツールのエフォートレベルの増加インプリメンテーションツールのエフォートレベルを増加してみます。インプリメンテーションに時間をかけるだけで、デザインのタイミングが満たされる場合があります。

Vivado Implementation Defaults ストラテジでは、実行時間とパフォーマンスのバランスが取られます。実行時間の長いアルゴリズムの一部は使用されません。これらのアルゴリズムおよび物理合成をオンにするには、Performance_Explore ストラテジを使用します。SSI テクノロジを使用する大型デバイスでは、Performance_ExploreSLLsを使用してみます。

ほかにも、実行時間の短いストラテジや、密集を軽減するストラテジなどがあります。名前に SLL 接頭辞が付いているストラテジは、 SSI テクノロジを使用するデバイス用です。

[Flow] → [Create Runs] をクリックして、異なるストラテジを使用した複数の run を作成し、実行してみてください。





インプリメンテーション結果を比較してデザインに適なストラテジを見つけ、その後の実行ではそのストラテジを使用します。

ヒント : 適なストラテジは、デザイン間およびツールリリース間で異なる場合があります。

フロアプランこのセクションでは、フロアプランについて説明します。次の内容が含まれます。

• 「フロアプランについて」

• 「フロアプランの基礎」

• 「Pblock ベースのフロアプラン」

• 「特定のロジックをデバイスサイトに固定」

• 「スタックドシリコンインターコネクト (SSI) デバイスでのフロアプラン」

フロアプランについて

フロアプランがデザインのタイミングを満たすのに役立つ場合があります。タイミングが満たされるときと満たされないときがある場合や、タイミングが満たされたことがない場合にフロアプランを実行することをお勧めします。

フロアプランは、複数の設計者と作業する場合や、一貫性が重要な場合にも有益です。

フロアプランでは、平均配線遅延を削減することにより、セットアップスラック (TNS、 WNS) を向上できます。インプリメンテーションでは、ワーストセットアップ違反およびすべてのホールド違反を解決するように処理されます。フロアプランで向上できるのはセットアップスラックのみです。


図 6‐1 :複数の run





手動フロアプランは、ネットリストが階層がある方が簡単です。合成でネットリスト全体がフラット化されると、デザイン解析に時間がかかります。階層ネットリストが生成されるように、合成オプションを設定します。 Vivado 合成

• synth_design -flatten_hierarchy rebuilt

または

• Vivado Synthesis Defaults ストラテジ

論理パスが複雑な大型の階層ブロックは、解析が困難です。異なる論理構造が別の下位階層に含まれているデザインの方が解析は簡単です。階層モジュールのすべての出力にレジスタを付けることを考慮してください。複数の階層ブロックを通過するパスの配置を解析するのは困難です。

フロアプランの基礎

すべてのデザインでタイミングが満たされるとは限りません。ツールがソリューションを見つけられるよう、指示する必要がある場合があります。フロアプランを使用すると、高レベルの階層レイアウトや詳細なゲート配置を指定できます。

悪の問題またはも一般的な問題を修正すると、も大きく改善します。たとえば、スラックが大幅に悪いパス、またはロジックレベル数が多いパスがある場合、まずそれらのパスを修正します。 [Tools] → [Timing] → [Create SlackHistogram] をクリックすると、スラックの悪いパスを表示できます。また、終点が同じ複数のパスのスラックが負である場合、 1 つのパスを改善すると、同じ終点のその他のパスも改善することがあります。

配線遅延を削減したり、クリティカルでないブロックのロジック集積度を増加するなどしてパフォーマンスを向上するため、フロアプランすることを考慮してみてください。ロジック集積度は、チップ上にロジックがどれだけ密にパックされるかを示します。

フロアプランを実行すると、クロック周波数および結果の一貫性を向上できます。

フロアプランには複数の取り組み方があり、それぞれに利点と欠点があります。

詳細なゲートレベルのフロアプラン

詳細なゲートレベルのフロアプランでは、個々の下位セルをデバイスの特定のサイトに配置します。

詳細なゲートレベルのフロアプランの利点

• ネットを手動で配線します。

• デバイスの大限のパフォーマンスを引き出せる可能性があります。

詳細なゲートレベルのフロアプランの欠点

• 時間がかかります。

• デバイスおよびデザインに関する豊富な知識が必要です。

• ネットリストが変更された場合、フロアプランを実行し直すことが必要な場合があります。

推奨 : 詳細なゲートレベルのフロアプランは、終的な手段としてください。





情報の再利用

タイミングが満たされたデザインの情報を再利用します。この手法は、デザインのタイミングが満たされたり満たされなかったりする場合に使用します。情報を再利用するには、次の手順に従います。

1. 2 つのインプリメンテーション run を開きます。

a. タイミングが満たされている run

b. タイミングが満たされていない run

ヒント : 複数のモニターを使用している場合、[Open Implementation in New Window] コマンドを使用してデザインを別のウィンドウで開きます。

2. 2 つのデザインの違いを見つけます。

a. report_timing_summary で、タイミングが満たされていないパスを特定します。

b. タイミングが満たされているデザインで、 report_timing を min_max モードで使用して、同じパスのタイミング解析を実行します。

3. タイミング結果を比較します。

a. クロックスキュー

b. データパス遅延

c. 配置

d. 配線遅延

4. パスの終点間のロジック遅延に差がある場合は、合成 run に戻ります。

I/O およびセルの配置の確認

デザインのセルの配置を確認します。 2 つの I/O レポートを比較して、 I/O の配置と I/O 規格を確認します。すべてのI/O が配置されていることを確認します。次の図に示すように検索を実行すると、配置が固定されていない I/O を検索できます。





run の間でクロックスキューを変更した場合、タイミングが満たされた run からのクロックプリミティブの配置を再利用することを考慮します。次の図に示すように、クロック使用量レポートにクロックツリードライバーの配置がリストされます。


図 6‐2 :配置が固定されていない I/O の検索


図 6‐3 : クロックのロケーション





LOC 制約は、 XDC 制約ファイルにコピーできます。

多くのデザインでは、ブロック RAM および DSP の配置を再利用することにより、タイミングを満たすことができます。 [Edit] → [Find] を使用して、インスタンスをリストします。

配置制約の追加

XDC に配置制約を追加して、ロジックを固定します。

1. [Find Results] ウィンドウでマクロを選択します。

2. 右クリックして [Fix Cells] をクリックします。


図 6‐4 : ブロック RAM または DSP を検索





推奨 : 配置を固定する前に、階層名に基づいて配置を解析し、ハイライトしてください。

配置の再利用

I/O、グローバルクロックリソース、ブロック RAM マクロ、 DSP マクロの配置を再利用するのは比較的簡単です。

配置を再利用すると、ネットリストのリビジョン間での結果がより一貫したものになります。これらのプリミティブの名前は通常変化しないので、配置を保持するのは簡単です。

ヒント : 汎用スライスロジックの配置を再利用しないでください。デザインの変更する予定の部分は、配置を再利用しないでください。

フロアプランのテクニック

タイミングが満たされておらず、ネットリストまたは制約の変更が好ましくないデザインでは、ゲートレベルのフロアプランを考慮します。

推奨 : ゲートレベルのフロアプランの前に、階層フロアプランを試してみてください。


図 6‐5 :選択したロジックの固定





階層フロアプラン

階層フロアプランでは、デバイス上の領域に階層レベルを配置できます。この領域が配置でのガイドラインとなり、詳細な配置が決定されます。階層フロアプランは、ゲートレベルフロアプランと比較して、次のような利点があります。

• ゲートレベルフロアプランよりも短時間で実行できます。適切なフロアプランにより、タイミングを改善できます。フロアプランは、デザインが変更されても保持されます。

• 階層レベルが、ゲートのコンテナーとなります。通常、ネットリストが変更されても機能します。

階層フロアプランは、次のようになります。

• クリティカルパスを含む下位階層を特定します。

• 上位フロアプランを使用して、どこに配置するかを判断します。

• 個々のセルは、インプリメンテーションにより配置されます。

• セルおよびタイミングパスに関する包括的な知識があります。

• 通常、適切な詳細配置が実行されます。

セルの手動配置

セルの手動配置では、デバイスの大限のパフォーマンスを引き出せる可能性があります。この手法は通常、デザインの小さい部分でのみ使用されます。たとえば、高速 I/O インターフェイス周辺のロジックや、ブロック RAM および DSP を配置する場合などです。手動での配置には時間がかかります。

すべてのフロアプラン手法には、多大なエンジニアリング時間がかかります。作業を繰り返して調整する必要がある場合もあります。セル名が変更された場合、フロアプラン制約もアップデートする必要があります。

フロアプランの際は、終的なピン配置を念頭においてください。 I/O が固定されていると有益です。 I/O はフロアプランを開始する際のアンカーポイントとなります。 I/O に接続されているロジックは、固定されているピンの近くに移動されます。

ヒント : I/O に接続されているブロックは、 I/O の近くに配置してください。ピン配置によりブロックの I/O への接続が分散されてしまっている場合は、ピン配置または RTL を変更することを考慮してください。





図 6-6 のようなフロアプランは、タイミングには有益ではありません。ブロックを分離するか、ソースコードを変更するか、ブロック RAM および DSP のみを制約することを考慮してください。また、外部タイミング要件で許容される場合、 I/O レジスタの配置を解除してみてください。


図 6‐6 : I/O コンポーネントの配置によりブロックの接続が分散されていしまっている例





上記の Pblock は、次の XDC 制約で表されます。

create_pblock Pblock_usbEngineadd_cells_to_pblock [get_pblocks Pblock_usbEngine] [get_cells -quiet [list usbEngine1]] resize_pblock [get_pblocks Pblock_usbEngine] -add {SLICE_X8Y105:SLICE_X23Y149} resize_pblock [get_pblocks Pblock_usbEngine] -add {DSP48_X0Y42:DSP48_X1Y59} resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB18_X0Y42:RAMB18_X1Y59} resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB36_X0Y21:RAMB36_X1Y29}

1 行目で Pblock が作成されます。 2 行目 (add_cells_to_pblock) で Pblock の階層レベルが指定されます。 4 つのリソースタイプ (SLICE、 DSP48、 RAMB18、 RAMB36) があり、それぞれグリッドがあります。グリッドで制約されていないロジックは、デバイスのどこにでも配置できます。階層レベルのブロック RAM のみを制約するには、ほかの Pblock グリッドをディスエーブルにします。

結果の XDC コマンドでは、 Pblock が簡略化されます。

create_pblock Pblock_usbEngineadd_cells_to_pblock [get_pblocks Pblock_usbEngine] [get_cells -quiet [list usbEngine1]] resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB18_X0Y42:RAMB18_X1Y59} resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB36_X0Y21:RAMB36_X1Y29}

ブロック RAM がデバイスに制約されますが、スライスロジックはデバイス上のどこにでも配置できます。


図 6‐7 : Pblock グリッド





ヒント : Pblock を配置する際は、階層を中央の Config ブロックをまたがるように配置しないでください。


図 6‐8 : Config ブロックをまたがるように配置しない





Pblock ベースのフロアプラン

RTL をデザインに統合する際、デバイス内のデザインをグラフィカル表示すると便利です。合成後のブロック間の接続や I/O ピン配置をグラフィカル表示で確認すると、デザインの理解に役立ちます。

インターコネクトを表示するには、階層の上位に Pblock を使用して上位フロアプランを生成します。上位 RTLを Pblock に分割するには、 [Tools] → [Floorplanning] → [Auto Create Pblocks] をクリックします。

Pblock をデバイスに配置するには、 [Tools] → [Floorplanning] → [Place Pblocks] をクリックします。スライス数および使用率に基づいて、 Pblock のサイズが特定されます。

Pblock の使用率は、解析中は 100% を超えていてもかまいませんが、インプリメンテーションでは 100% 以下にする必要があります。 Pblock の使用率を高くすると、デバイス上でのサイズが小さくなります。これは、デザインの上位ブロックの相対的なサイズおよびデバイスの配置を把握するために有効な手法です。


図 6‐9 : [Place Pblocks] ダイアログボックス





上位フロアプラン

上位フロアプランには、ブロックと I/O の接続表示されます (緑色の線)。 2 つの Pblock を接続するネットは、まとめられます。線の太さおよび色は、共有されるネットの数により異なります。図 6-10 および 159 ページの図 6-11 に、2 つの上位フロアプランを示します。

次の図は、デザインの上位ブロック間のデータフローを示しています。各ブロックは、隣接する 2 つのブロックのみに接続されています。緑色の線は、 1 つのブロックのみが I/O に接続されていることを示しています。


図 6‐10 :データパスを示す上位フロアプラン





次の図は、すべてのブロックが中央のブロックと接続されているデザインを示しています。接続は、中央のブロックと右下のブロックの間がも多くなっています。この中央のブロックを分散させて、その他のロードと通信するようにする必要があります。

フロアプランの確認

フロアプランを確認する際は、デバイスリソースを考慮してください。 Pblock のサイズ調整では、次のような特殊なデバイスリソースは考慮されません。

• ブロック RAM

• DSP48

• MGT

• クロックバッファー

ヒント : フロアプランおよびリソース使用量を考慮してブロックを確認してください。


図 6‐11 :制御パスを含むフロアプラン





特定のロジックをデバイスサイトに固定

セルを FPGA デバイスの特定のロケーションに配置できます。たとえば、すべての I/O ポートをザイリンクス 7 シリーズ FPGA デザインに配置するなどです。タイミングクロージャを試みる前に I/O を配置することをお勧めします。

I/O の配置は、FPGA ファブリックでのセルの配置に影響します。ほかのセルをファブリックに手動で配置すると、クロックロジックおよびマクロの配置がより一貫したものになります。

固定および未固定のセル

固定および未固定は、配置されたセルに適用されます。これらは、 Vivado ツールでデザインの配置されたセルがどのように認識されるかを示します。

固定および未固定のセルに関する詳細は、『Vivado Design Suite ユーザーガイド : インプリメンテーション』 (UG904) [参照 7] のこのセクションを参照してください。

推奨 : I/O を配置した後、階層 Pblock のフロアプランをユーザー制御配置の開始点として使用します。手動配置は、Pblock でうまく制御できない場合にのみ使用するようにしてください。

スタックドシリコンインターコネクト (SSI) デバイスでのフロアプラン

スタックドシリコンインターコネクト (SSI) パーツでは、追加の考慮事項があります。SSI パーツは複数の SLR (SuperLogic Region) で構成されており、インターポーザーにより結合されています。インターポーザーの接続は、SLL (SuperLong Line) と呼ばれます。 1 つの SLR から別の SLR への移動には多少の遅延があります。

デザインの設計、ピン配置、フロアプランの際には、 SLR を考慮してください。クリティカルタイミングパスのロジックセルは 1 つの SLR 内に収め、 SLL をまたぐ接続を小限に抑えてください。

表 6‐1 : ロジックの配置に使用する制約

制約使用法注記

LOC ゲートまたはマクロを特定のサイトに配置します。

SLICE サイトには、BEL サイトと呼ばれるサブサイトがあります。

BEL スライスのサブサイトを基本エレメントに使用するよう指定します。

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug904-vivado-implementation.pdf;a=xModifyingPlacement





I/O は、関連する I/O インターフェイス回路と同じ SLR に配置されます。SSI パーツのロジックを配置する場合は、クロックの配置も考慮する必要があります。

推奨 : 分割を実行する前に、ロジックの配置を自動で実行してみてください。自動配置を解析することにより、考慮していなかったフロアプラン方法が見つかることがあります。

配線の変更配線の変更が必要な場合があります。これは多くの場合、デザインに小さなタイミングエラーがいくつかあり、ほかのタイミングクロージャ手法でそれらのエラーを解決できないような状況です。 Vivado Design Suite では、配線を変更し、固定できます。

詳細は、『Vivado Design Suite ユーザーガイド : インプリメンテーション』 (UG904) [参照 7] のこのセクションを参照してください。 `


図 6‐12 : SLL を介する接続を小限に抑える

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug904-vivado-implementation.pdf;a=xModifyingPlacementRoutingAndLogic




第 7章

デザイン解析テクニック

report_design_analysis コマンドの使用タイミングクロージャを達成するのが困難な場合、またはアプリケーションの全体的なパフォーマンスを向上しようとしている場合は、合成の実行後、およびインプリメンテーションフローの各ステップの後に、デザインの特性を確認する必要があります。タイミングサマリの値 (WNS、 TNS、 WHS、 THS) (report_timing_summary) やさまざまなリソース使用率の値 (report_utilization、 report_clock_utilization、 report_high_fanout_nets、および report_control_sets) などの全体的なメトリクスを取得するのは簡単ですが、特定のタイミングパスにデザインのどの部分が影響しており、全体的な QoR (結果の品質) に影響を与えているのかを解析および特定するのは困難です。 QoR 解析では、グローバルおよびローカルの複数の特性を同時に見て、デザインおよび制約に適でないものがあるか、ターゲットデバイスおよびインプリメンテーションツールに適切でないロジック構造があるかを確認します。 report_design_analysis コマンドを実行すると、論理特性、タイミング特性、物理特性が表で示され、 QoR の根本的な原因を簡単に解析できます。

注記 : report_design_analysis コマンドでは、タイミング制約が完全であるか正確であるかはレポートされません。タイミング制約を検証するには、 check_timing および report_exceptions コマンドと、 XDC およびタイミング設計手法 DRC を使用する必要があります。これらのコマンドの実行方法は、該当するセクションを参照してください。

• 21 ページの「タイミングサマリレポート」

• 57 ページの「例外レポート」

よく発生する QoR の問題には、次の 2 つのカテゴリがあります。

• 「タイミング違反」

• 「密集」

タイミング違反

悪のタイミング違反を解析して修正すると通常全体的な QoR が向上しますが、ほかのクリティカルパスもタイミングクロージャの課題となることがよくあるので、ほかのクリティカルパスも解析する必要があります。次のコマンドを使用すると、ワーストセットアップタイミングパスを 50 個レポートできます。

report_design_analysis -max_paths 50 -setup

図 7-1 に、このコマンドで生成される Setup Path Characteristics (セットアップパス特性) の表の例を示します。




第 7 章 : デザイン解析テクニック

この表から、どの特性が各パスにタイミング違反を発生させているのかを特定できます。

• ロジック遅延の割合 (LOGIC_DELAY) が大きい

° ロジックレベル数は多いですか (LOGIC_LEVELS)。

° ロジック適化を妨げる制約または属性が設定されていますか (DONT_TOUCH、 MARK_DEBUG)。

° パスに RAMB や DSP などのロジック遅延の大きいセルが含まれていますか。

° パスの要件が現在のパストポロジには厳しすぎませんか (REQUIREMENT)。

• ネット遅延の割合 (NET_DELAY) が大きい

° パスのファンアウトの大きいネットがありますか (HIGH_FANOUT、 CUMULATIVE_FANOUT)。

° セルが離して配置可能な複数の Pblock に割り当てられていますか (PBLOCKS)。

° セルが離れて配置されていますか (BOUNDING_BOX_SIZE、 CLOCK_REGION_DISTANCE)。

° SSI デバイスで SLR の境界をまたぐネットがありますか (SLR_CROSSINGS)。

° 配置は正しいようなのにもかかわらず、予測よりもかなり大きいネット遅延がありますか。164 ページの「密集」を参照してください。

• RAMB または DSP セルにパイプラインレジスタがない (パスには存在する )

° COMB_DSP、 MREG、 PREG、 DOA_REG、および DOA_REG の値を確認してください。

• スキューが大きい (セットアップで <-0.5ns、ホールドで >0.5ns) (SKEW)

° そのパスはクロック乗せ換えパスですか (STARTPOINT_CLOCK および ENDPOINT_CLOCK)。

° クロックは同期ですか、非同期ですか (CLOCK_RELATIONSHIP)。

° パスは I/O 列をまたいでいますか (IO_CROSSINGS)。

タイミングパスとその配置配線の詳細を Vivado® IDE で表示するには、次のコマンドを使用します。

report_timing -max_paths 50 -setup -input_pins -name worstSetupPaths

パスは、スラック順に Setup Path Characteristics の表 (図 7-1) と同じ順で表示されます。

report_design_analysis コマンドでは、ワーストパス 5000 個の Logic Level Distribution (ロジックレベル分布)の表も生成され、デザインの長いパスを特定するのに使用できます。通常、配置の段階でタイミングを満たすために長のパスが初に適化されるので、短いパスの配置の質が低下する可能性があります。全体的な QoR を向上す

るため、長いパスをなるべくなくすようにしてください。図 7-2 に、1 つのクロックのみを含むデザインの Logic LevelDistribution の例を示します。


図 7‐1 : Setup Path Characteristics の表の例





解析結果に基づいて、 RTL を変更、異なる合成オプションを使用、またはタイミング制約および物理制約を変更してネットリストを向上できます。

密集

report_design_analysis コマンドは、配置および配線アルゴリズムにより特定された密集エリアと予測密集を示す複数の密集に関する表を示します。これらの表を生成するには、配置および配線を実行したのと同じ Vivado ツールセッションで次のコマンドを使用します。

report_design_analysis -congestion

図 7-3 に、 Vivado IDE に表示される CLB メトリクスごとの垂直方向および水平方向の配線密集と同等の予測される密集の表の例を示します。この例では、密集は低くなっています。


図 7‐2 : Logic Level Distribution の表の例


図 7‐3 :予測される密集の表





[Module Names] に示される名前は、レポートされている各タイルにある階層セルに対応しています。完全な名前は、次のコマンドを使用すると取得できます。

get_cells -hier <moduleName>

密集エリアに存在する階層セルを特定したら、密集を緩和する手法を使用してデザインの全体的な密集を削減します。

エラボレート済みビューを使用した RTL の適化インプリメンテーションのいずれかの手順の後に report_timing、 report_timing_summary、または report_design_analysis を使用してタイミング結果を解析する際は、クリティカルパスの構造を確認して、RTL を変更、合成属性を使用、または異なる合成オプションを使用することにより、これらのパスをより効率的にロジックプリミティブにマップできるかどうかを調べます。ロジックレベル数の多いパスは、インプリメンテーションツールに負荷がかかり、全体的なデザインパフォーマンスを制限するので、これは特に重要です。

ロジックレベル数の多いクリティカルパスがある場合は、そのパスの機能にそれほど多くのロジックレベルが必要なのかを見直します。適なロジックレベル数を判断することは、デザインに対する知識と RTL 適化に関する知識によるので、簡単ではありません。合成後の適化済みネットリストを見て問題の原因となっている RTL の部分を特定して向上するのは、複雑なタスクです。

プロジェクトモードでは、 Vivado IDE で提供されている合成済みまたはインプリメント済みデザインとエラボレート済みデザインの間のクロスプローブ機能を使用することで、この解析がやりやすくなります。合成済み/インプリメント済みデザインとエラボレート済みデザインの間でクロスプローブするには、次を実行します。

1. 合成済み/インプリメント済みデザインとエラボレート済みデザインの両方をメモリで開きます。

2. 合成済み/インプリメント済みデザインでタイミングパスを選択し、 F4 キーを押して回路図を表示します。

3. Flow Navigator で [Elaborated Design] をクリックします。タイミングパスに対応する RTL セルが選択されているので、 F4 キーを押して RTL 回路図を開いて、同じパスをエラボレート済みビューで表示し、終点のピンから始点のセルにたどることができます。

4. パス上にある RTL ロジックを、特にその演算子またはベクターのサイズを確認してください。





例

次のように記述されたカウンターがあるとします。

cnt 信号は 0 ～ 16 をカウントするので、エンコードするのに 5 ビットのベクターが必要です。図 7-5 に、配線後のクリティカルパスの回路図を示します。終点は cnt 信号のビット 30 です。


図 7‐4 :単純なカウンターの VHDL 例


図 7‐5 : cnt カウンターの配線後のクリティカルパスの回路図





クリティカルパスの始点セルと終点セルを選択し、選択したセルの回路図を開いて、終点のピンから始点にロジックを展開していくと、エラボレート済みビューで同等のパスを表示できます (図 7-6)。

エラボレート済みビューに示される加算器の入力は 32 ビットですが、これは cnt が整数として宣言されているからです。この例では、合成適化中 32 ビットの演算子が保持されます。エラボレート済みビューは、何が起きているのかを理解するのに役立ちます。これに基づいて次のように RTL を変更し、適化されたネットリストおよびタイミング QoR を向上できます。カウンターは 0 から 16 までインクリメントするので、 cnt 信号の範囲を定義し、加算器の入力を 32 ビット幅ではなく 5 ビット幅に強制できます。

RTL コードに加えた変更は合成適化にも影響します。これは、コンパイルフロー全体を実行せずに、エラボレート済みビューを使用して確認できます。


図 7‐6 : cnt カウンターのエラボレート済みビュー


図 7‐7 :単純なカウンターの整数範囲を設定した VHDL 例





デザインの長ロジック遅延パスを特定タイミングパスは、デザインの論理パスに対応します。パスの遅延は、セル遅延とネット遅延を累積したものです。Vivado 合成およびインプリメンテーションはタイミングドリブンであり、コンパイルフローを通してデザインでタイミング違反が悪のパスを適化するよう実行されます。パスの累積セル遅延がタイミング要件 (パスのクロック周期など) 以上である場合、インプリメンテーション後にデザインでタイミングが満たされる可能性は低くなります。ロジック遅延を解析すると、予測ネット遅延または配線ネット遅延を含む前のワーストパスが示されるので、単にロジックレベルを数えるよりも有益です。この解析の結果には、ネット遅延を含まない配置配線前のワーストタイミングパスがリストされます。

必ずしもロジックレベル数ではなく、タイミングが悪のパスを特定することが重要です。たとえば、レジスタのないブロック RAM の clock-to-out 遅延は非常に大きくなる一方、複数のロジックレベルを持つ一連のキャリーチェーンでは各ロジックレベルの遅延が小さいことがあります。これらのパスをインプリメンテーション前に注意深く解析してください。遅延の大きいパスには、通常次の 3 つがあります。

• 組み込まれている出力レジスタを利用していないブロック RAM

• パイプライン処理されていない DSP48

• 長いロジックパス

これらのパスを特定するには、合成後にタイミングレポートを配線遅延なしで生成するのがも効率的な方法です。これには、 Vivado IDE の [Report Timing] ダイアログボックスの [Timer Settings] タブで [Interconnect] を [none] に設定するか、 [Tcl Console] ビューまたはシェルで次の Tcl コマンドを実行します。

set_delay_model -interconnect none

タイミング結果を確認し、タイミングが満たされていないパスを特定します。配線遅延なしでタイミングを満たしていないパスがある場合、実際の配線遅延を含めたときにタイミングを満たすことは不可能です。これらのパスは、すぐに修正する必要があります。通常、これらのパスは RTL で修正する必要がありますが、タイミングが満たされない原因が合成属性が不足していることや、タイミング制約が不正であることもあります。変更を加えると、図 7-9 に示すようにデザインのスラックが十分になります。


図 7‐8 : RTL 変更後の cnt カウンターのエラボレート済みビュー





ファンアウトの大きいネットドライバーの特定ファンアウトの大きいネットは、インプリメンテーションの問題の原因となることがよくあります。 FPGA ファミリのダイサイズが大きくなると、ファンアウトの問題も増加します。エンドポイントが数千個あるネットでは、特にパス上に追加のロジックがあったり、 LUT や分散 RAM などのシーケンシャルでないセルで駆動される場合、タイミングを満たすことは困難です。

多くの場合、ファンアウトの大きいネットは通常グローバルファンアウト制限または特定ネットに MAX_FANOUT 属性を使用することで、 RTL および合成で修正します。物理適化 (phys_opt_design) を使用すると、スラックおよび配置情報に基づいてファンアウトの大きいネットドライバーが自動的に複製され、通常はタイミングがかなり改善されます。ザイリンクスでは、ファンアウトの大きいネットはファブリックレジスタで駆動することをお勧めしています。これを使用する方が、簡単に物理適化中に複製および移動できます。合成後および物理適化後に、ファンアウトの大きい信号のリストを確認することが重要です。これらのネットを特定するコマンドはreport_high_fanout_nets です。

レポートを生成したら、ファンアウトの大きいネットを介するタイミングおよび対応する回路図を確認できます。このレポートでは、クロックはファンアウトの大きいドライバーとしてリストされません。 [Driver Type] 列に BUFG がリストされている場合は、この BUFG がロジックを駆動します。クロックピンも駆動する可能性があります。

### Report the high fanout netreport_high_fanout_nets -load_types -max_nets 100### Report timing through specific high fanout netreport_timing -through [get_nets I_GLOBAL_RST_N_i] -name high_fanout_1

次に、 phys_opt_design でファンアウトが削減されたデザイン例を示します。

配置後のチェックポイント : report_high_fanout_nets

ヒント : report_high_fanout_nets コマンドで -timing および -load_types オプションを使用すると、ファンアウトの大きいネットの遅延およびさまざまなロードが表示されます。

このネットの物理適化後のタイミングレポートは、次のとおりです。


図 7‐9 :配線遅延なしのタイミングレポート





このネットのファンアウトは 2945 から 464 に削減されていますが、より重要なのは、ファンアウトの削減によりこのパスのタイミングが 1ns 以上向上したということです。

各ネットの FLAT_PIN_COUNT プロパティは、デザイン階層全体でこのネットに接続されている下位セルの数を示します。 FLAT_PIN_COUNT プロパティを確認するには、 get_property コマンドを使用します。

get_property FLAT_PIN_COUNT [get_nets my_hfn]

ヒント : Tcl スクリプトを使用することにより、ファンアウトの大きい特定のネットを介して伝搬されるパスに関する追加レポートを作成できます。

ホールド違反の修正がデザインに悪影響を及ぼすかの判断Vivado 配線では、セットアップよりもホールドの修正が優先されます。これは、セットアップが少しの差で満たされていない場合でも、デザインはラボ環境では機能することがあるからです。クロック周波数を下げることはいつでもできます。ホールド違反があると、通常デザインは機能しません。

ほとんどの場合は配線でセットアップに影響を与えずにホールドタイミングを満たすことができますが、デザインや制約にエラーがあるために、ホールドタイミングを満たすことによりセットアップタイムに大きく影響するがことがあります。 -hold が指定されていない不適切な set_multicycle_path 制約により、不適切なホールドチェックが実行されたり、過剰なクロックスキューによりホールド要件が大きくなることがあります。この場合、該当する回路でクロックアーキテクチャを確認することをお勧めします。詳細は、『UltraFast 設計手法 (Vivado Design Suite 用)』 (UG949) [参照 5] のこのセクションを参照してください。

これは、デザインのセットアップタイミングが配置後には満たされたが、配線後に満たされなかった場合に発生することがあります。

ヒント : 配置後のホールドタイミング予測を解析し、ホールド違反が以上に大きい (500ps 以上) のものを特定します。

ホールド違反の修正がタイミングクロージャに影響していると考えられる場合は、次のいずれかの方法を使用してそうであるかを確認できます。

• 「方法 1 : ホールド違反の修正なしで配線を実行」

• 「方法 2 : タイミングが満たされていない悪のセットアップパスに対して report_timing -min を実行」


図 7‐10 : タイミングレポートの例

http://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_ug949-vivado-design-methodology.pdf;a=xIdentifyingTimingViolationsRootCause





方法 1 : ホールド違反の修正なしで配線を実行

1. Vivado Design Suite で配置後のチェックポイントを開きます。

2. すべてのホールドチェックをディスエーブルにする制約を追加します。

set_false_path -hold -to [all_clocks]

注意 : この制約は、テスト目的でのみ使用してください。製品にするデザインや別の設計者に配布するデザインには使用しないでください。製品デザインの前にこの制約を削除する必要があります。

3. route_design および report_timing_summary を実行します。

ホールドチェックを実行した場合と実行しなかった場合で WNS が大きく異なる場合は、ホールド違反が大きすぎ、セットアップパスが影響を受けていることを示します。

方法 2 : タイミングが満たされていない悪のセットアップパスに対して report_timing ‐min を実行

タイミングが満たされていない悪のセットアップがホールド違反の修正によるものであるかを判断するには、そのパスのホールドタイミングを調べます。Vivado IDE で、パスを右クリックして [Report Timing on Source to Destination]をクリックします。セットアップタイミング解析とは異なり、ホールドタイミングを確認することは重要です。ホールドレポートで、要件を確認し、ホールド要件を満たすためにパスに遅延が追加されていないかどうかを調べてください。


図 7‐11 :特定のパスに対してタイミングレポートを生成





タイミングが満たされていないパスすべてをすばやく解析report_timing_summary コマンドは、すべてのデザインのタイミング情報を確認するのに非常に優れたツールです。タイミングが満たされていないすべてのパスを 1 つのレポートで見るだけでも有益である場合があります。コマンドラインまたは IDE 内で次のコマンドを実行します。

report_timing -max_paths 100 -slack_less_than 0 -name worse_100_setup

ヒント : IDE を使用すると、タイミング結果をスプレッドシートにエクスポートして、タイミングが満たされていないパスを包括的に解析できます。

上記のコマンドは、タイミングが満たされていないパスを悪のものから 100 個レポートします。タイミングが満たされていないパスが 100 個未満の場合は、 –slack_less_than 0 オプションが使用されているので、タイミングが満たされていないパスのみがレポートされます。 1 つのリストでタイミングが満たされていないパスを確認すると、タイミングの満たされていないパス間の違反量の差をすばやく特定できます。

たとえば、 -3ns の WNS が数個のパスに影響していても、その次の WNS が -300ps であるような場合もあります。

デフォルトでは、エンドポイントごとに悪のタイミングパスが 1 つ表示されます。通常、同じエンドポイントに対して同様のパスが多数あります。

1 つのエンドポイントに対してタイミングが満たされていないパスをすべて表示するには、 report_timing コマンドで -nworst オプションを使用します。たとえば、タイミングが満たされていないワーストケースのエンドポイントを通過するすべてのパスを表示するには、次のコマンドを実行します (100 個以下である場合)。

report_timing -max_paths 100 -nworst 100

ワーストパスをすべて取得すると、膨大なデータ量になります。解析するデータ量を小限に抑えるには、report_timing コマンドの –unique_pins オプションを使用してパスの固有の部分のみをレポートできます。このオプションを使用すると、固有のピンの組み合わせそれぞれに対して 1 つのパスがリストされます。次に例を示します。

report_timing -max_paths 100 -nworst 100 -unique_pins




付録 A

タイミング DRC

TIMING‐1:Invalid Clock Waveform on Clock Modifying Block

Invalid clock waveform for clock <CLOCK_NAME> specified at a <CELL_TYPE> output <PIN_NAME> that does not match the Clock Modifying Block (CMB) settings.The waveform of the clock is <VALUE>.The expected waveform is <VALUE>. (調整ブロック (CMB) 設定と一致しない <CELL_TYPE> 出力の <PIN_NAME> で指定されたクロック <CLOCK_NAME> のクロック波形が無効です。クロックの波形は <VALUE>、予測される波形は <VALUE> です)

説明

Vivado® Design Suite では、 CMB (クロック調整ブロック ) 設定と入力マスタークロックの特性に基づいて CMB の出力でクロックが自動的に派生されます。ユーザーが CMB 出力で生成クロックを定義する場合は、 Vivado で同じ定義ポイント (ネットまたはピン) で生成クロックが自動的に派生されることはありません。この DRC 警告は、ユーザー定義の生成クロックが Vivado で自動的に派生される予測クロックと一致しないことを示しています。これにより、デザインのタイミング制約がデバイスで発生するものと一致しないので、ハードウェアエラーになる可能性があります。

回避策

ユーザー定義の生成クロックは必要ありませんので、制約を削除し、自動派生されたクロックを代わりに使用してください。制約が必要な場合は、生成クロック制約が自動派生クロックの波形と一致するか確認するか、 CMB プロパティを予測クロック波形と一致するように変更します。自動派生クロックの名前を使用する必要がある場合は、create_generated_clock 制約に定義済みの -name オプションにそのクロックが定義されたオブジェクト (通常CMB の出力ピン) の名前のみを付けて使用することをお勧めします。生成クロックの作成方法と自動派生クロックの名前変更制約の制限に関する情報は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。




付録 A : タイミング DRC

例

次の図では、 create_generated_clock 制約が MMCM インスタンスピンの CLKOUT0 に定義されていますが、MMCM 属性設定を基に Vivado で生成された自動派生波形とは一致しません。

自動派生クロックの名前を変更するだけの場合は、次の制約を制約ファイルのマスタークロック定義の直後に使用します。

create_generated_clock -name clkName [get_pins clk_gen_i0/clk_core_i0/inst/mmcme3_adv_inst/CLKOUT0]

X-Ref Target - Figure A-1

図 A‐1 : クロック調整ブロックの無効なクロック波形





TIMING‐2:Invalid Primary Clock on Internal Pin

A primary clock <CLOCK_NAME> is created on an inappropriate pin <PIN_NAME>.It is recommended to create a primary clockonly on a proper clock root (input port or primitive output pin with no timing arc). (プライマリクロック <CLOCK_NAME> が不適切なピン <PIN_NAME> に作成されています。プライマリクロックは正しいクロックルート (タイミングアークなしの入力ポートまたはプリミティブの出力ピン) にのみ作成するようにしてください)

説明

プライマリクロックはクロックツリーのソースに定義する必要があります。たとえば、これはデザインの入力ポートであることもあります。プライマリクロックがロジックパスの真ん中で定義される場合、プライマリクロックソースポイントよりも前に挿入遅延が無視されるので、タイミングが正確でなくなる可能性があり、スキューが正しく設定されなくなります。このため、内部ドライバーピンにプライマリクロックを作成すると、ハードウェアでエラーになることがあるので、お勧めしません。

回避策

実際のクロックツリーソースを使用するように create_clock 制約を変更します。

例

次の図では、プライマリクロック定義の create_clock 制約が IBUFCTRL インスタンスの出力ピンに使用されています。 clk_pin_p クロックが入力ポートまたは出力ポートパスにタイミング制約を付けるために使用されている場合、クロックツリー挿入遅延の一部がないため、スラックが正確にはなりません。差動入力バッファーのプライマリクロック定義が上位ポート clk_pin_p に使用される必要があります。


図 A‐2 :内部ピンの無効なプライマリクロック





TIMING‐3:Invalid Primary Clock on Clock Modifying Block

A primary clock <CLOCK_NAME> is created on the output pin or net <PIN/NET_NAME> of a Clock Modifying Block. (プライマリクロック <CLOCK_NAME> がクロック調整ブロック (CMB) の出力ピンまたはネット <PIN/NET_NAME>に作成されています)

説明

Vivado では、 CMB 設定と入力マスタークロックの特性に基づいて CMB の出力でクロックが自動的に派生されます。ユーザーが CMB 出力でプライマリクロックを定義する場合、 Vivado で同じ出力でクロックが派生されることはありません。この DRC 警告は、プライマリクロックが CMB の出力で作成されているので、入力クロックとの関連がなくなり、クロック挿入遅延が正しく計算されないことを示しています。これは、タイミング解析とハードウェアビヘイビアーが正確でなくなる可能性があるので、推奨されません。

回避策

CMB の出力の create_clock 制約を削除します。自動生成クロックの名前を使用する場合は、create_generated_clock 制約に -name オプションと CMB 出力ピンのみを付けることをお勧めします。生成クロックの作成に関する詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

例

次の図では、 create_clock 制約が MMCM インスタンスピン CLKOUT0 に定義されています。これにより、 Vivadoで作成された自動派生クロックが上書きされ、入力クロックとの関連がなくなります。

自動派生クロックの名前を変更するだけの場合は、次の制約を制約ファイルのマスタークロック定義の直後に使用します。

create_generated_clock -name clkName [get_pins clk_gen_i0/clk_core_i0/inst/mmcme3_adv_inst/CLKOUT0]






図 A‐3 : クロック調整ブロックの無効なプライマリクロック





TIMING‐4:Invalid Primary Clock Redefinition on a Clock Tree

Invalid clock redefinition on a clock tree.The primary clock <CLOCK_NAME> is defined downstream of clock <CLOCK_NAME>and overrides its insertion delay and/or waveform definition. (クロックツリーのクロック再定義が無効です。プライマリクロック <CLOCK_NAME> はクロック <CLOCK_NAME>のダウンストリームを定義し、その挿入遅延と波形定義の両方またはいずれかを上書きします)

説明

プライマリクロックはクロックツリーのソースに定義する必要があります。たとえば、これはデザインの入力ポートであることもあります。プライマリクロックが入力クロック定義を上書きするダウンストリームを定義する場合、再定義されたプライマリクロックソースポイントよりも前に挿入遅延が無視されるので、タイミング解析が正確でなる可能性があり、スキューが正しく計算されなくなります。このため、タイミング解析が正しくなくなり、ハードウェアでエラーになる可能性があるので、これは推奨されません。

回避策

ダウンストリームオブジェクトの create_clock 制約を削除して、アップストリームクロックの伝搬ができるようにするか、アップストリームのプライマリクロックを基準とする生成クロックが作成されるようにします。

例

次の図では、プライマリクロックが上位ポートの clk_pin_p に正しく定義されていますが、 IBUFCTRL 出力にプライマリクロックを定義し直すために create_clock 制約が使用されています。この新しいクロックは、IBUFCTRLより前の遅延をすべて無視します。


図 A‐4 : クロックツリーの無効なプライマリクロック再定義





TIMING‐5:Invalid Waveform Redefinition on a Clock Tree

Invalid inverted waveform on a clock tree.The generated clock <CLOCK_NAME> is defined downstream of clock<CLOCK_NAME> and has an inverted waveform definition compare to the incoming clock. (クロックツリーの反転波形は無効です。生成クロック <CLOCK_NAME> はクロック <CLOCK_NAME> のダウンストリームを定義し、入力クロックと比べて反転した波形定義を含みます)

説明

生成クロックは、入力クロックに関連して定義されるべきです。この DRC 警告は、入力クロックと比べて、生成クロックに異なる周期、位相シフト、反転といった無効な定義があることをレポートしています。

回避策

create_generated_clock 制約を、入力クロック定義と一致する正しい波形定義を定義するように変更します。正しい生成クロック制約の作成については、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

例

次の図では、 create_generated_clock が LUT1 インバーターの出力で作成されていますが、 -invert オプションは適用されていません。

TIMING‐6:No Common Primary Clock Between Related Clocks

The clocks <CLOCK_NAME1> and <CLOCK_NAME2> are related (timed together) but they have no common primary clock.The design could fail in hardware even if timing is met.To find a timing path between these clocks, run the following command:report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>]. (クロック <CLOCK_NAME1> および <CLOCK_NAME2> は関連して (一緒にタイミング制約が付いて) いますが、共通のプライマリクロックがありません。デザインはハードウェアでエラーになる可能性があります。これらのクロッ


図 A‐5 : クロックツリーの無効な波形再定義





ク間のタイミングパスを見つけるには、 report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>] を実行します)

説明

レポートされている 2 つのクロックは関連していて、共通のプライマリクロックから派生されておらず、既知の位相関係がない場合でも、デフォルトで同期するようにタイミング制約が付けられます。この DRC 警告は、タイミングエンジンではこれらのクロックが同期することが保証できないことを示しています。

回避策

回避策は、 2 つのクロックドメインが非同期であるか、同期であるかによって異なります。クロックが非同期の場合、2 つのドメイン間のパスにはタイミング例外 (set_max_delay -datapath_only、 set_clock_groups、またはset_false_path など) が使用されているべきです。この DRC 警告は、これらの 2 つのドメイン間のパスすべてに完全に例外が適用されれば表示されなくなります。

例

クロックが同期の場合、両方のクロックが元々同じ波形であれば、クロックソースオブジェクト両方に 1 つのタイミングクロックを定義できます (次の 1 つ目の例を参照)。

例 1 : create_clock -period 10 -name clk1 [get_ports <clock-1-source> <clock-2-source>]

2 つのクロックの波形が異なる場合は、 1 つ目のクロックをプライマリクロックとして、 2 つ目のクロックを生成クロックとして定義します。 1 つ目のクロックはマスタークロックとして指定します (次の例 2 を参照)。

例 2 : create_clock -period 10 -name clk1 [get_ports <clock-1-source>]

クロックが関連していても、クロック周期率 2 の場合は、 1 つのソースにプライマリクロックを作成して、 2 つ目のソースに生成クロックを作成すると問題が回避できます。

create_generated_clock -source [get_ports <clock-1-source>] -name clk2 -divide_by 2[get_ports <clock-2-source>]

TIMING‐7:No Common Node Between Related Clocks

The clocks <CLOCK_NAME1> and <CLOCK_NAME2> are related (timed together) but they have no common node.The design could fail in hardware.To find a timing path between these clocks, run the following command:report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>]. (クロック <CLOCK_NAME1> および <CLOCK_NAME2> は関連して (一緒にタイミング制約が付いて) いますが、共通のプライマリクロックがありません。デザインはハードウェアでエラーになる可能性があります。これらのクロック間のタイミングパスを見つけるには、 report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>] を実行します)

説明

レポートされている 2 つのクロックは関連していて、デフォルトで同期になるようにタイミング制約が付けられています。この DRC 警告は、 2 つのクロックツリー間で共通のノードが決定できないために、タイミングエンジンでこれらのクロックがハードウェアで同期になることが保証されないことを示しています。





回避策

回避策は、 2 つのクロックドメインが非同期であるか、同期であるかによって異なります。クロックが非同期の場合、2 つのドメイン間のパスにはタイミング例外 (set_max_delay -datapath_only、 set_clock_groups、またはset_false_path など) が使用されているべきです。

クロックが同期の場合は、この DRC 警告は表示されません。

例

次の図では、同期クロック乗せ換え (CDC) が clk1 および clk2 ドメイン間にあります。 clk1 および clk2 は両方ともデフォルトで Vivado で同期になるように決定されますが、clk1 および clk2 が入力ポートなので、2 つのクロック間に共通のノード関係はありません。この場合、 Vivado では 2 つのクロックが同期であることが保証できません。

TIMING‐8:No Common Period Between Related Clocks

The clocks <CLOCK_NAME1> and <CLOCK_NAME2> are found related (timed together) but have no common (expandable)period. （クロック <CLOCK_NAME1> および <CLOCK_NAME2> は関連して (一緒にタイミング制約が付いて) いますが、共通の (展開可能な) 周期がありません)

説明

レポートされている 2 つのクロックは関連していて、デフォルトで同期になるようにタイミング制約が付けられています。ただし、タイミングエンジンでは、 1000 サイクルを超える両方のクロックの波形を展開した後、共通の周期を決定できませんでした。このような場合、これらの 1000 サイクルを超えるワーストセットアップ関係がタイミング解析に使用されますが、タイミングエンジンではこれがもっとも不必要に悪い見積もり部分であることが保証できません。これは、通常奇数の小数点周期率のクロックで発生します。

回避策

波形ではこの 2 つのクロック間で安全なタイミング解析ができないので、これらのクロックは非同期として処理することをお勧めします。このため、2 つのドメイン間のパスにはタイミング例外 (set_max_delay -datapath_only、set_false_path、または set_clock_groups など) を使用する必要があります。


図 A‐6 :関連クロック間に共有ノードなし





TIMING‐9:Unknown CDC Logic

An asynchronous Clock Domain Crossing has been detected between clock <CLOCK_NAME1> and clock <CLOCK_NAME2>through a set_false_path or a set_clock_groups or a set_max_delay -datapath_only constraint but no safeCDC logic has been identified (crossing pin <PIN_NAME>). <CLOCK_NAME1> および <CLOCK_NAME2> クロック間には set_false_path、 set_clock_groups、または set_max_delay-datapath_only 制約を介して非同期のクロック乗せ換え (CDC) が検出されていますが、安全な CDC ロジックが認識されていません (乗せ換えピン <PIN_NAME>)。

説明

DRC の目的は、タイミング例外制約の付いたクロックドメイン同士が安全な非同期クロック乗せ換え回路を使用して設計されるようにすることにあります。認識されている安全なトポロジの詳細は、 62 ページの「クロック乗せ換えレポート」を参照してください。

回避策

クロックパス間が適切な同期になるようにしてください。これには、低でもダブルレジスタロジックシンクロナイザーを追加する必要があります。FIFO またはよりハイレベルなプロトコルが既にパスに定義されている場合、このDRC は安全に無視できます。

例

次の図では、 clk1 と clk2 ドメイン間に非同期クロック乗せ換え (CDC) がありますが、 clk2 キャプチャドメインにデータを同期するためのダブルレジスタロジックシンクロナイザーが含まれません。


図 A‐7 : シンクロナイザーが存在しない





TIMING‐10:Missing Property on Synchronizer

A logic synchronizer with <CELL_NAME1> and <CELL_NAME2> has been detected between clock <CLOCK_NAME1> and clock<CLOCK_NAME2> but the synchronizer does not have the property ASYNC_REG=TRUE on both registers. (<CELL_NAME1> および <CELL_NAME2> を使用したロジックシンクロナイザーが <CLOCK_NAME1> および<CLOCK_NAME2> クロック間に検出されたのに、シンクロナイザーの両方のレジスタに ASYNC_REG=TRUE プロパティがありません)

説明

シンクロナイザーレジスタでは ASYNC_REG プロパティが TRUE に設定されていないと、合成およびインプリメンテーション中のロジック適化でセルが保持されず、適な平均故障間隔 (MTBF) 統計になるように配置が適化されません。

回避策

この問題は、ロジックシンクロナイザーの各ステージに ASYNC_REG 制約を追加すると回避できます。 ASYNC_REG制約の詳細については、『Vivado Design Suite プロパティリファレンスガイド』 (UG912) [参照 10] を参照してください。

例

次の図では、 clk1 および clk2 間に非同期クロックドメインがあり、ダブルレジスタロジックシンクロナイザーを使用して正しく同期されていますが、タイミングスラックを増加して MTBF を小さくするためには、シンクロナイザーの各レジスタに ASYNC_REG プロパティを適用する必要があります。


図 A‐8 : シンクロナイザーにプロパティが付いていない





TIMING‐11:Inappropriate Max Delay with Datapath Only Option

A max delay constraint with -datapath_only has been applied between <PIN_NAME> and <PIN_NAME>.The startpoint(s)and endpoint(s) either belong to the same clock domain or belong to two clock domains that can safely be timed together.It is onlyrecommended to use the -datapath_only option on paths between clocks that do not have a known phase relationship.ThisDRC is waived when a synchronizer is found on the path endpoint. (<PIN_NAME> および <PIN_NAME> 間に -datapath_only を使用した大遅延制約が適用されています。始点と終点のいずれかが同じクロックドメインにあるか、安全にタイミング制約で一緒にできる 2 つのクロックドメインにあります。 -datapath_only オプションは、既知の位相関係のないクロック間のパスにのみ使用することをお勧めします。このDRC は、シンクロナイザーがパスの終点にある場合は表示されません)

説明

セットアップスラック計算からクロックスキューを削除して、ホールドタイミングを無視するために、set_max_delay に -datapath_only オプションを付けて使用されています。set_max_delay -datapath_onlyコマンドは、クロック関係がないのに大遅延が必要な非同期信号のタイミングパスに制約を付けるために使用されます。この制約を同期パスに使用することはお勧めしません。

回避策

この問題は、同期タイミングパスに適用されないように set_max_delay -datapath_only 制約を変更すると回避できます。メッセージにリストされる始点セルと終点セルから、該当する set_max_delay 制約を見つけてください。

TIMING‐12:Clock Reconvergence Pessimism Removal Disabled

説明

CRPR (Clock Reconvergence Pessimism Removal) モードがディスエーブルになっています。クロックツリー遅延に不必要に悪い見積もり部分があると、タイミングクロージャが不可能になる可能性があるので、このモードでタイミング解析を実行することはお勧めできません。

CRPR 機能は、大および小遅延をクロックネットワークの共通部分と一緒に使用することで人工的に誘発される不必要に悪い見積もり部分を削除するために使用されます。 CRPR がディスエーブルになっていると、タイミングクロージャが困難になることがあります。

回避策

CRPR 解析をイネーブルにして、デザインのタイミング情報が正しくなるようにしてください。CPRP 解析をイネーブルにする Tcl コマンドは config_timing_pessimism -enable です。





TIMING‐13:Timing Paths Ignored Due to Path Segmentation

Some timing paths are not reported due to path segmentation on pin(s) <PIN_NAME>.To prevent path segmentation, all the Minand Max delay constraints should be defined with a list of valid startpoints and endpoints. (<PIN_NAME> ピンのパスセグメンテーションが原因で、レポートされないタイミングパスがあります。パスセグメンテーションが実行されないようにするには、有効な始点および終点のリストを使用して小および大遅延制約すべてを定義する必要があります)

説明

パスセグメンテーションは、タイミングパスがタイミング制約を付けるためにより小さなパスに分割される際に発生します。大および小遅延制約が無効な始点 (または終点) のピンに定義されると、タイミングエンジンでそのノードを通るタイミングアークが分割されて、ノードが有効な始点 (または終点) になるようにされます。パスセグメンテーションは、思ったような結果にならないので、使用しないようにしてください。使用すると、タイミング解析が正しくなくなり、ハードウェアエラーになる可能性があります。

回避策

set_max_delay および set_min_delay 制約で有効な始点と終点を選択して、できるだけパスセグメンテーションを使用しないようにします。パスセグメンテーションの詳細と小/ 大遅延制約の使用方法については、『VivadoDesign Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

TIMING‐14:LUT on the Clock Tree

The LUT <CELL_NAME> has been found on the clock tree.It is not recommended to have LUT cells on the clock path. (クロックツリーに <CELL_NAME> があります。クロックパスに LUT セルを含めるのは推奨されません)

説明

クロックパスに LUT があると、クロックがファブリックを介して汎用配線リソースに配線される必要があり、余分なスキューが発生してしまうことがあります。また、余分なスキューだけでなく、これらのパスは PVT 違反の影響をより受けやすくなります。ローカルクロックはできるだけ避けることをお勧めします。

回避策

クロックツリーの LUT は削除するようにデザインを変更します。合成では、クロックゲーティングおよび反転など、多くの場合にこの状況が作成されることがあります。たとえば、 LUT1 セルが反転する場合、 LUT は opt_design 後にダウンストリームの SLICE に吸収される可能性があります。 opt_design が終了したら、この状況が有効なままであることを確認してください。





例

次の図では、クロックイネーブル信号の付いたクロックのゲートに LUT が使用されています。パスに LUT があるため、余分なスキューが発生する可能性があります。

TIMING‐15:Large Hold Violation on Inter‐Clock Path

There is a large inter-clock skew of <VALUE> ns between <CELL_NAME> (clocked by <CLOCK_NAME>) and <CELL_NAME>(clocked by <CLOCK_NAME>) that results in large hold timing violation(s) of <VALUE> ns.Fixing large hold violations duringrouting might impact setup slack and result in more difficult timing closure. (<CELL_NAME> (<CLOCK_NAME> クロック付き ) および <CELL_NAME> (<CLOCK_NAME> クロック付き ) 間に<VALUE> ns の大きなクロック間スキューがあるために、<VALUE> ns の大きなホールドタイミング違反になります。配線中に大きなホールド違反を修正すると、セットアップおよびスラックに影響し、タイミングクロージャがさらに困難になります)

説明

この DRC 警告は、クロック間のスキューが原因の大きなホールド違反があると、インプリメンテーション中のタイミングクロージャが困難になる可能性が高いことを示しています。正しい制約またはデザイントポロジにするためには、 1.0 を超える大きなクロック間スキューは検証することをお勧めします。

回避策

タイミングパスの大きなクロック間スキューにタイミング制約を付けるか、適ではないタイミング制約に関連付けるかを検証します。大きなスキューが制約の付いていない CDC パスのために発生している場合は、必要なタイミング例外を追加してください。違反がクロックツリーに関連するロジックのために発生している場合は、パスのトポロジを検証して、さらにタイミングクロージャが簡単になるよう改善できないかどうかを検証してください。


図 A‐9 : クロックツリーの LUT





TIMING‐16:Large Setup Violation

There is a large setup violation of <VALUE> ns between <CELL_NAME> (clocked by <CLOCK_NAME>) and <CELL_NAME>(clocked by <CLOCK_NAME>).Large setup violations at the end of those stages might be difficult to fix during the post-placementimplementation flow and could be the result of non-optimal XDC constraints or non-optimal design architecture. (<CELL_NAME> (<CLOCK_NAME> クロック付き ) および <CELL_NAME> (<CLOCK_NAME> クロック付き ) 間に<VALUE> ns の大きなセットアップ違反があります。これらのステージの終わりに大きなセットアップ違反があると、配置後のインプリメンテーションフロー中には修正するのが困難になり、 XDC 制約やデザインアーキテクチャが適でなくなったりします)

説明

この DRC 警告では、インプリメンテーション中にタイミングクロージャが困難になる可能性の高いセットアップ違反がレポートされています。正しい制約またはデザイントポロジにするためには、 1.0 を超える大きなクロック間スキューは検証することをお勧めします。

回避策

大きなセットアップ違反がタイミング制約を付けるべきタイミングパスであるのか、適ではないタイミング制約に関連付けるかを検証します。CDC パスに制約が付いていないためにセットアップ違反が発生している場合は、必要なタイミング例外を追加してください。違反が組み合わせロジックの量が多すぎるために発生している場合は、パスのトポロジを検証して、さらにタイミングクロージャが簡単になるよう改善できないかどうかを検証してください。

TIMING‐17:Non‐Clocked Sequential Cell

The clock pin <PIN_NAME> is not reached by a timing clock. (クロックピン <PIN_NAME> がタイミングクロックで到達していません)

説明

この DRC 警告は、タイミングクロックで制約されていない順次セルのリストをレポートしています。これは、レポートされたセルのタイミング解析結果に影響します。タイミングパスを正確に大限に網羅するためには、すべてのクロックを正しく定義する必要があります。この結果、タイミング解析が含まれないことがあり、ハードウェアエラーになる可能性があります。

回避策

制約の付いていない順次セルを駆動するクロックツリーで、足りないプライマリまたは生成クロックを作成してください。

TIMING‐18:Missing Input or Output Delay

An <INPUT/OUTPUT> delay is missing on <PORT_NAME> relative to clock(s) <CLOCK_NAME>. (<INPUT/OUTPUT> 遅延が <CLOCK_NAME> クロックに関連する <PORT_NAME> にありません)





説明

IO タイミングは、外部デバイスを含むタイミングパスに関連します。入力および出力遅延は、デザインのインターフェイスのクロックエッジに関連するポートのパス遅延を指定します。 FPGA インターフェイスが外部デバイスのタイミングを満たすようにするには、入力/出力遅延制約を追加することをお勧めします。

回避策

必要なボードアプリケーションに合った必要な入力および出力遅延制約を追加してください。

TIMING‐19:Inverted Generated Clock Waveform on ODDR

The waveform of the generated clock <CLOCK_NAME> is inverted compared to the waveform of the incoming clock<CLOCK_NAME>. (生成クロック <CLOCK_NAME> の波形が入力クロック <CLOCK_NAME> の波形と比べて反転しています)

説明

フォワードクロックポートの生成クロックは、入力クロックに関連して定義されるべきです。この DRC 警告は、フォワードクロックポートの生成クロックに、入力ソースクロックと比べて反転など、無効な定義があることをレポートしています。これにより、フォワードクロックに関連するポートのタイミング解析がデバイスで発生するものと一致しないので、ハードウェアエラーになる可能性があります。

回避策

create_generated_clock 制約を、入力クロック定義と一致する正しい波形を定義するように変更します。正しい生成クロック制約の作成については、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

TIMING‐20:Non‐Clocked Latch

The latch <CELL_NAME> cannot be properly analyzed because its control pin <PIN_NAME> is not reached by a timing clock. (ラッチ <CELL_NAME> は、その制御ピン <PIN_NAME> がタイミングクロックで到達しないため、正しく解析できません)

説明

この DRC 警告は、タイミングクロックによる制約が付いていないラッチセルのリストをレポートしています。これは、タイミング解析結果に影響します。タイミングパスを正確に大限に網羅するためには、すべてのクロックを正しく定義する必要があります。この結果、タイミング解析が完全に網羅されず、ハードウェアエラーになる可能性があります。

回避策

ラッチセルで制約の付いていない制御ピンを駆動するクロックツリーのソースにプライマリまたは生成クロックを作成してください。





TIMING‐21:Invalid COMPENSATION Property on MMCM

The MMCM <CELL_NAME> has an invalid COMPENSATION property value relative to the connection of its feedback loop.If thefeedback loop goes outside the FPGA, the property should be set to EXTERNAL.If the feedback loop is internal to the FPGA, theproperty should be set to ZHOLD. (MMCM <CELL_NAME> に、そのフィードバックループの接続に対して無効な COMPENSATION プロパティ値が付いています。フィードバックループが FPGA 外部に行く場合は、このプロパティは EXTERNAL に、内部に行く場合は ZHOLD に設定する必要があります)

説明

MMCM の補償 (COMPENSATION) モードでは、出力クロックの遅延補償に対して MMCM フィードバックをどのようにコンフィギュレーションするかを定義します。 MMCM の使用状況によっては、フィードバックパスが特定のトポロジと一致している必要があります。この DRC 警告は、 MMCM 使用状況のトポロジが COMPENSATION プロパティ値と一致していないことを示しています。これにより、タイミング解析が一致しないので、ハードウェアで思ったとおりのビヘイビアーにならない可能性があります。

回避策

MMCM の COMPENSATION プロパティはデフォルト値の AUTO のままにしておくことをお勧めします。Vivado 統合設計環境 (IDE) では、回路のトポロジに基づいて適な COMPENSATION 値が自動的に選択されます。COMPENSATIONプロパティと入力遅延補償の詳細については、該当するアーキテクチャのクロッキングリソースユーザーガイドを参照してください。

TIMING‐22:Missing External Delay on MMCM

The MMCM <CELL_NAME> has an external feedback loop but no external delay has been specified between FBOUT and FBIN.Itis recommended to specify an external delay with set_external_delay between the two ports connected to the pins FBOUTand FBIN with an external feedback loop. (MMCM の <CELL_NAME> に外部フィードバックループがあるのに、 FBOUT および FBIN 間に外部遅延が指定されていません。外部フィードバックループの付いた FBOUT および FBIN ピンに接続された 2 つのポート間にset_external_delay で外部遅延を指定することをお勧めします)

説明

MMCM は、フィードバックボードトレースが外部コンポーネントへのトレースと一致する外部デスキュー用にコンフィギュレーションできます。外部遅延値は、 MMCM の補償遅延の計算に使用されます。これにより、 MMCM 補償のタイミング解析がデバイスで発生するものと一致しないので、 IO パスで特にハードウェアエラーが発生する可能性があります。

回避策

定義された外部トレース遅延用に、外部フィードバックの入力および出力ポート間に set_external_delay 制約を追加してください。 set_external_delay コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 3] を参照してください。





例

set_external_delay -from <output_port> -to <input_port> <external_delay_value>

TIMING‐23:Combinatorial Loop Found

A timing loop has been detected on a combinational path.A timing arc has been disabled between <CELL_NAME1> and<CELL_NAME2> to break the timing loop. (組み合わせパスにタイミングループが検出されました。タイミングループを分割するため、タイミングアークが<CELL_NAME1> および <CELL_NAME2> 間でディスエーブルになっています)

説明

組み合わせタイミングループは、組み合わせロジックがその入力に送信し戻されて、タイミングループになると作成されます。このループがあると、同じパスを無限に繰り返し、タイミング制約を付けることもできないので、サイクル数が不必要に増えてしまいます。このタイミングループを回避するには、 Vivado IDE でそのループのセルのタイミングアークをディスエーブルにします。

回避策

組み合わせフィードバックループを作成しない場合は、デザインソースファイル (RTL) を修正すると、この問題を回避できます。タイミングループが必要な場合は、 Vivado でランダムにタイミングが分割されるようにしないで、set_disable_timing コマンドを使用してタイミングループを適切な箇所 (通常はフィードバックパス) で分割します。

TIMING‐24:Overridden Max Delay Datapath Only

A set_clock_groups or a set_false path between clocks <CLOCK_NAME1> and <CLOCK_NAME2> overrides aset_max_delay -datapath_only (see constraint position <#> in the Timing Constraints window in the Vivado IDE).It isnot recommended to override a set_max_delay -datapath_only constraint.Replace the set_clock_groups orset_false_path between clocks with point-to-point set_false_path constraints. (クロック <CLOCK_NAME1> および <CLOCK_NAME2> 間の set_clock_groups または set_false path が set_max_delay -datapath_only を上書きしています(Vivado IDE の [Timing Constraints] ウィンドウの制約位置 <#> を参照)。 set_max_delay -datapath_only 制約を上書きするのは、お勧めしません。クロック間の set_clock_groups または set_false_path をポイントツーポイントの set_false_path制約と置き換えてください)

説明

この DRC 警告は、 set_max_delay -datapath_only 制約がクロック間の set_clock_groups またはset_false_path 制約で上書きされる場合にのみ表示されます。ポイントツーポイントの set_false_path がset_max_delay -datapath_only を上書きする場合は、この DRC 警告はレポートされません。

回避策

クロック間の set_clock_groups または set_false_path をポイントツーポイントのフォルスパス制約と置き換えて、 set_max_delay -datapath_only 制約が間違って上書きされてしまわないようにしてください。





TIMING‐25:Invalid Clock Waveform on Gigabit Transceiver (GT)

The waveform of the clock <CLOCK_NAME> defined on the transceiver output pin <PIN_NAME> or on the net connected to that pin is not consistent with the transceiver settings or the reference clock definition is missing.The auto-derived clock period is <PERIOD> and the user-defined clock period is <PERIOD>. ( トランシーバー出力ピン <PIN_NAME> またはそのピンに接続されるネットに定義されたクロック <CLOCK_NAME> の波形がトランシーバー設定と一貫していないか、基準クロックの定義がありません。自動派生のクロック周期は <PERIOD> で、ユーザー定義のクロック周期は <PERIOD> です)

説明

UltraScale™ デバイスの場合、Vivado では GT 設定と入力マスタークロックの特性に基づいて GT の出力でクロックが自動的に派生されます。ユーザーが GT 出力で生成クロックを定義する場合は、 Vivado で同じ定義ポイント (ネットまたはピン) で生成クロックが自動的に派生されることはありません。7 シリーズデバイスの場合、Vivado では GT クロックが自動的に派生されませんが、それでもこの DRC では UltraScale と 7 シリーズデバイスの両方がサポートされます。この DRC 警告は、ユーザー定義の生成クロックが Vivado で自動的に派生される予測クロックと一致しないことを示しています。これにより、デザインのタイミング制約がデバイスで発生するものと一致しないので、ハードウェアエラーになる可能性があります。

回避策

ユーザー定義の生成クロックは必要ありませんので、制約を削除し、自動派生されたクロックを代わりに使用してください。制約が必要な場合は、生成クロック制約が自動派生クロックの波形と一致するか確認するか、GT プロパティを予測クロック波形と一致するように変更します。自動派生クロックの名前を使用する必要がある場合は、create_generated_clock 制約に定義済みの -name オプションとそのクロックが定義されたオブジェクト (通常GT の出力ピン) の名前のみを付けて使用することをお勧めします。生成クロックの作成方法と自動派生クロックの名前変更制約の制限に関する情報は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

TIMING‐26:Missing Clock on Gigabit Transceiver (GT)

The output clock pin <PIN_NAME> does not have clock defined.Create a primary clock on the <PORT_NAME> input port in orderto let Vivado auto-derive the missing GT clocks. (出力クロックピン <PIN_NAME> にクロックが定義されていません。 <PORT_NAME> 入力ポートにプライマリクロックを作成して、 Vivado で足りない GT クロックが自動的に派生されるようにします)

説明

UltraScale デバイスの場合、 Vivado では GT 設定と入力マスタークロックの特性に基づいて GT の出力でクロックが自動的に派生されます。この DRC 警告では、入力ポートにプライマリクロックがないので、 Vivado で GT の出力クロックが自動的に派生できないことを示しています。この結果、 GT 関連クロックに接続されたダウンストリームロジックにタイミング制約が適用されません。

回避策

推奨される GT の入力ポートにプライマリクロックを作成してください。





TIMING‐27:Invalid Primary Clock on Hierarchical Pin

A primary clock <CLOCK_NAME> is created on an inappropriate internal pin <PIN_NAME>.It is not recommended to create aprimary clock on a hierarchical pin when its driver pin has a fanout connected to multiple clock pins. (プライマリクロックの <CLOCK_NAME> が不適切な内部ピン <PIN_NAME> に作成されています。ドライバーピンに複数クロックピンへ接続されるファンアウトがある場合、階層ピンにプライマリクロックを作成するのはお勧めしません)

説明

ドライバーがクロックによって走査され、新しいクロックが階層ピンでダウンストリームを定義する場合に、その階層ピンのダウンストリームのセルのタイミング解析がドライバーピンのファンアウトにあるセルと比較すると、異なりっています。ドライバークロックと階層ピンクロック間に同期パスがある場合は、スキューが正しくなくなり、タイミングサインオフが無効になります。これにより、ハードウェアでエラーになる可能性があります。

回避策

階層ピンからプライマリクロック定義を削除するか、ダウンストリームクロックが絶対に必要な場合は、生成したクロック制約を代わりにマスターとして指定したドライバークロックに使用します。

TIMING‐28:Auto‐Derived Clock Referenced by a Timing Constraint

The auto-derived clock <CLOCK_NAME> is referenced by name inside timing constraint (see constraint position <#> in the TimingConstraint window in the Vivado IDE).It is recommended to reference an auto-derived clock by the pin name attached to the clock:get_clocks -of_objects [get_pins <PIN_NAME>]. (自動生成クロック <CLOCK_NAME> がタイミング制約内で名前で参照されています (Vivado IDE の [TimingConstraint] ウィンドウの制約位置 <#> を参照)。自動派生クロックは、 get_clocks -of_objects [get_pins <PIN_NAME>] のようにクロックに接続されたピン名で参照することをお勧めします)

説明

自動派生クロックは、ソースピンオブジェクトで参照される必要があります。自動派生クロック名は、ネットリストや制約に変更を加えると、開発中に変更されることがあります。自動派生クロックを名前で参照することは、デザインが変更された後の run で制約が無効になってしまうことがあるので、お勧めしません。

回避策

自動派生クロックは、 [get_clocks -of_objects [get_pins <PIN_NAME>]] のようにクロックに接続されたピン名で参照するように、制約を変更します。または、 create_generated_clock 制約を使用して、自動派生クロックの名前を指定します。生成されたクロック制約を使用してクロック名を強制的に指定する方法については、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。





TIMING‐29:Inconsistent Pair of Multicycle Paths

Setup and hold multicycle path constraints should typically reference the same -start pair for SLOW-to-FAST synchronous clocksor -end pair for FAST-to-SLOW synchronous clocks (see constraint positions <#>, <#> in the Timing Constraint window in VivadoIDE).(セットアップおよびホールドマルチサイクルパス制約は、通常 SLOW-to-FAST 同期クロックの同じ -start ペアまたはFAST-to-SLOW 同期クロックの -end ペアを参照する必要があります (Vivado IDE の [Timing Constraints] ウィンドウの制約位置 <#> を参照))。

説明

デフォルトでは、ホールド用のソースクロックまたはセットアップ用のデスティネーションクロックに対してパス要件の乗算器を変更するのに、 set_multicycle_path 制約が使用されます。特定の使用状況では、パス要件は特定のクロックエッジに対して乗算される必要があります。

回避策

セットアップとホールドの両方に対して、 SLOW-to-FAST 同期クロックのデスティネーションクロック (-end) およびFAST-to-SLOW 同期クロックのソースクロック (-start) を参照するように set_multicycle_path 制約を変更します。クロック間のマルチサイクルパスの正しい設定方法の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 6] を参照してください。

TIMING‐30:Sub‐Optimal Master Source Pin Selection for Generated Clock

The generated clock <CLOCK_NAME> has a sub-optimal master source pin selection, timing can be pessimistic. (生成クロック <CLOCK_NAME> に適ではないマスターソースピンの選択があり、タイミングで見積もりが不必要に悪くなります)

説明

生成クロックは、その直接ファンイン内にあるクロックを基準にするべきです。この DRC 警告は、生成クロックが入力マスタークロックよりもより上のアップストリームを定義するマスタークロックに関連付けられていることをレポートしています。この場合、タイミング解析に不必要に悪い見積もり部分がより多く含まれるので、マスタークロックと生成クロック間のパスのクロックのばらつきが増えます。これにより、タイミングクロージャが少し困難になります。生成クロックをそのクロックが派生されるマスタークロックソースピンに関連付けることをお勧めします。

回避策

生成クロックを直接派生するマスタークロックソースピンを参照するように create_generated_clock 制約を変更します。




付録 B

その他のリソースおよび法的通知

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

ソリューションセンターデバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。トピックには、デザインアシスタント、アドバイザリ、トラブルシュートヒントなどが含まれます。

参考資料このガイドの補足情報は、次の資料を参照してください。

1. 『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893)

2. 『Vivado Design Suite ユーザーガイド : Tcl スクリプト機能の使用』 (UG894)

3. 『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)

4. 『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895)

5. 『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949)

6. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903)

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

8. 『Vivado Design Suite ユーザーガイド : 消費電力解析と適化』 (UG907)

9. 『7 シリーズ FPGA クロッキングリソースユーザーガイド』 (UG472 : 英語版、日本語版)

10. 『Vivado Design Suite プロパティリファレンスガイド』 (UG912)

11. Vivado Design Suite のすべての資料


http://japan.xilinx.com/support/

http://japan.xilinx.com/support/solcenters.htm

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug893-vivado-ide.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug894-vivado-tcl-scripting.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug835-vivado-tcl-commands.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug895-vivado-system-level-design-entry.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_ug949-vivado-design-methodology.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug903-vivado-using-constraints.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug904-vivado-implementation.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4.;d=ug907-vivado-power-analysis-optimization.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.4;d=ug912-vivado-properties.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+docs

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug472_7Series_Clocking.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug472_7Series_Clocking.pdf



付録 B : その他のリソースおよび法的通知

トレーニングリソースザイリンクスでは、本書に含まれるコンセプトを説明するさまざまなトレーニングコースおよびビデオチュートリアルを提供しています。次のリンクから関連するトレーニングリソースを参照してください。

• Vivado Design Suite ビデオチュートリアル : タイミングクロージャのための UltraFast Vivado 設計手法

• Vivado Design Suite ビデオチュートリアル : Vivado タイミング制約ウィザードの使用

• Vivado Design Suite ビデオチュートリアル : アドバンスクロック制約と解析

• Vivado Design Suite ビデオチュートリアル : インプリメンテーション結果の解析

• Vivado Design Suite ビデオチュートリアル : Vivado でのデザインルールチェック (DRC) の実行

• Vivado Design Suite ビデオチュートリアル : タイミング解析の制御

• Vivado Design Suite ビデオチュートリアル : Vivado タイミングクロージャテクニック : 物理適化

• Vivado Design Suite ビデオチュートリアル : クロック乗せ換えチェック - CDC 解析

• Vivado Design Suite ビデオチュートリアル : Vivado でのデザイン解析およびフロアプラン

• Vivado Design Suite ビデオチュートリアル

お読みください : 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ )に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供

され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれら

に限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または貴

社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、

直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、

その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であった

り、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれる

いかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事前

の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製品は、

ザイリンクスの限定的保証の諸条件に従うこととなるので、 http://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件

を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件に従うことに

なります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケーションに使用する

ために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を使用する場合のリス

クと責任は、貴殿または貴社が単独で負うものです。 http://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照

してください。

© Copyright 2012-2015 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含ま

れるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、それぞれの保

有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。


http://japan.xilinx.com/training/vivado/ultrafast-vivado-design-methodology-for-timing-closure.htm

http://japan.xilinx.com/training/vivado/using-the-vivado-timing-constraint-wizard.htm

http://japan.xilinx.com/training/vivado/advanced-clock-constraints-and-analysis.htm

http://japan.xilinx.com/training/vivado/analyzing-implementation-results.htm

http://japan.xilinx.com/training/vivado/running-design-rule-checks-in-vivado.htm

http://japan.xilinx.com/training/vivado/timing-analysis-controls.htm

http://japan.xilinx.com/training/vivado/vivado-timing-closure-techniques-physical-optimization.htm

http://japan.xilinx.com/training/vivado/cross-clock-domain-checking-cdc-analysis.htm

http://japan.xilinx.com/training/vivado/design-analysis-and-floorplanning-with-vivado.htm

http://japan.xilinx.com/training/vivado/index.htm

http://japan.xilinx.com/legal.htm#tos

http://japan.xilinx.com/legal.htm#tos

mailto:[email protected]


vivado design suite - xilinx...vivado design suite ユーザー ガイド...

Documents

vivado design suite - xilinx...vivado design suite ユーザーガイド...