vivado design suite - xilinx...vivado design suite ユーザーガイドパーシャル...

Vivado Design Suite ユーザーガイド

パーシャルリコンフィギュレーション

UG909 (v2018.1) 2018 年 4 月 27 日

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

パーシャルリコンフィギュレーション 2UG909 (v2018.1) 2018 年 4 月 27 日 japan.xilinx.com

改訂履歴

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

セクション改訂内容

2018 年 4 月 27 日バージョン 2018.1

全体的なアップデートメニューコマンドをアップデート。

「概要」サポートされる UltraScale+™ パーツをアップデート。

「パーティションピン」 -net および -pins オプションに関する情報を追加。

「パーシャルリコンフィギュレーション IP」使用可能なパーシャルリコンフィギュレーション IP の詳細

を説明する新規セクション。

「FPGA をコンフィギュレーションするシステムデザイン」パーシャルリコンフィギュレーションポートとフォーマッ

トの規則を追加。

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG909&Title=Vivado%20Design%20Suite%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B%3A%20%26%2312497%3B%26%2312540%3B%26%2312471%3B%26%2312515%3B%26%2312523%3B%20%26%2312522%3B%26%2312467%3B%26%2312531%3B%26%2312501%3B%26%2312451%3B%26%2312462%3B%26%2312517%3B%26%2312524%3B%26%2312540%3B%26%2312471%3B%26%2312519%3B%26%2312531%3B&releaseVersion=2018.1&docPage=2

目次

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

第 1 章: 入門概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

パーシャルリコンフィギュレーションについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

設計に関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

パーシャルリコンフィギュレーションのライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

第 2 章: 一般的なアプリケーション概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ネットワーク接続された複数のインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

標準バスインターフェイスを使用したコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ダイナミックリコンフィギュレーション可能なパケットプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

非対称キー暗号化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

第 3 章: Vivado ツールフロー概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

パーシャルリコンフィギュレーションコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

パーシャルリコンフィギュレーションの制約とプロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

リコンフィギュレーション後にリセットを適用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

ツールフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Tcl スクリプト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

第 4 章: Vivado プロジェクトフロー概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

フローの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

パーシャルリコンフィギュレーションプロジェクトの作成および使用手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

サポートされる機能とサポートされない機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

第 5 章: すべてのザイリンクスデバイスでの設計に関する考慮事項とガイドライン概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

パーシャルリコンフィギュレーション IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

デザイン階層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

パーティションピンの配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

アクティブ Low のリセットとクロックイネーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

デカップリング機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ブラックボックス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

インプリメンテーションでの効果的な方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

コンフィギュレーション解析レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73




PR デザインの制約の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

リコンフィギャラブルパーティション境界の定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

デッドロック状態の回避 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

デザインリビジョンチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

シミュレーションおよび検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

第 6 章: 7 シリーズおよび Zynq デバイスでの設計に関する考慮事項とガイドライン概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

リコンフィギャラブルモジュール内のデザインエレメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

グローバルクロックの規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7 シリーズデバイスでの Pblock の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

高速トランシーバーの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

パーシャルリコンフィギュレーションデザインチェックリスト (7 シリーズデバイス) . . . . . . . . . . . . . . . . . . . . 91

第 7 章: UltraScale および UltraScale+ デバイスでの設計に関する考慮事項とガイドライン概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

リコンフィギャラブルモジュール内のデザインエレメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

UltraScale および UltraScale+ デバイスでの Pblock の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

グローバルクロックの規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

I/O 規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

高速トランシーバーの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

UltraScale および UltraScale+ デバイスデザインでのパーシャルリコンフィギュレーションチェックリスト . 105

第 8 章: デバイスのコンフィギュレーション概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

コンフィギュレーションモード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

ビットストリームタイプの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

ICAP を介したパーシャルリコンフィギュレーション (Zynq デバイス) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Tandem コンフィギュレーションおよびパーシャルリコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

内部コンフィギュレーションポートに配布するための BIN ファイルのフォーマット . . . . . . . . . . . . . . . . . . . . . 120

UltraScale デバイスでの BIT ファイルのサマリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

FPGA をコンフィギュレーションするシステムデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

パーシャル BIT ファイルの整合性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

コンフィギュレーションフレーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

コンフィギュレーション時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

コンフィギュレーションデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Vivado デバッグコアの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

第 9 章: 既知の問題および制限既知の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

既知の制限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

付録 A: 階層デザインフロー概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

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

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

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

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

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




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




第 1 章

入門

概要

パーシャルリコンフィギュレーションは、アクティブなデザイン内でモジュールを動的に変更することを可能にし

ます。このフローでは、複数のコンフィギュレーションのインプリメンテーション (各コンフィギュレーションのフ

ルビットストリーム) と、各リコンフィギャラブルモジュールのパーシャルビットストリームが必要です。

必要なコンフィギュレーションの数はインプリメントする必要のあるモジュールの数によって異なりますが、すべ

てのコンフィギュレーションで同じ上位 (スタティック ) の配置配線結果が使用されます。これらのスタティック

の結果は初期コンフィギュレーションからエクスポートされ、その後のすべてのコンフィギュレーションにチェッ

クポイントを使用してインポートされます。

このガイドは、次のように記述されています。

• Vivado® Design Suite でインプリメントされるパーシャルリコンフィギュレーションについて説明します。

• FPGA 設計ソフトウェア、特にザイリンクス Vivado Design Suite の使用に慣れていることを前提としています。

• Vivado Design Suite 2018.1 用に記述されています。このリリースでは、次の製品のパーシャルリコンフィギュ

レーションがサポートされます。

° 7 シリーズデバイス : ほぼすべての Virtex®-7、 Kintex®-7、 Artix®-7、および Zynq®-7000 SoC デバイス。

- Spartan®-7 デバイスはサポートされません。

- Artix-7 7A12T および 7A25T はサポートされません。

- シングルコアプロセッサの Zynq-7000 デバイス (Z-7007S、 Z-7012S、 Z-7014S) はサポートされません。

° UltraScale™ デバイス :

- VU440 以外のプロダクションデバイスで配置配線およびビットストリーム生成をイネーブル。このデ

バイスへのアクセスが必要な場合は、ご請求ください。

- ES2 デバイスではビットストリーム生成はデフォルトでディスエーブルですが、配置配線は実行可能

です。

° UltraScale+™ デバイス :

- すべての Zynq UltraScale+ RFSoC デバイスを含むプロダクションデバイスすべてで配置配線および

ビットストリーム生成をイネーブル。

- Virtex UltraScale+ VU37P で配置配線をイネーブル。このデバイスは ES1 のみが入手可能なので、ビッ

トストリーム生成はディスエーブルになっています。

- UltraScale+ デバイスの多くのエンジニアリングシリコン (ES1、 ES2) で配置配線をイネーブル。これら

のデバイスでは、ビットストリーム生成はデフォルトでディスエーブルになっています。




第 1 章: 入門

ビデオ: 7 シリーズデバイスでの Vivado パーシャルリコンフィギュレーションソリューションの概要は、

Vivado Design Suite QuickTake ビデオ: Vivado でのパーシャルリコンフィギュレーションを参照してください。

UltraScale デバイスでの Vivado パーシャルリコンフィギュレーションソリューションの概要は、

Vivado Design Suite QuickTake ビデオ: UltraScale でのパーシャルリコンフィギュレーションを参照してください。

パーシャルリコンフィギュレーションについて

FPGA テクノロジには、変更したデザインで再製造することなく、オンサイトでプログラムおよび再プログラムでき

る柔軟性があります。パーシャルリコンフィギュレーション (PR) はこの柔軟性をさらに一歩進め、動作中の FPGA

デザインをパーシャルコンフィギュレーションファイル (パーシャル BIT ファイル) を読み込むことにより変更でき

るようにします。フル BIT ファイルで FPGA をコンフィギュレーションした後、パーシャル BIT ファイルをダウン

ロードして FPGA のリコンフィギャラブル領域を変更します。この際、リコンフィギュレーションされない領域で

実行されているアプリケーションが影響を受けることはありません。

図 1-1 に、パーシャルリコンフィギュレーションの基本的な概念を示します。

この図に示すように、 Reconfig Block A にインプリメントされたファンクションは、 A1.bit、 A2.bit、 A3.bit、

または A4.bit のいずれかのパーシャル BIT ファイルをダウンロードすることにより変更できます。FPGA デザイン

のロジックは、リコンフィギャラブルロジックとスタティックロジックの 2 種類に分類できます。 FPGA ブロック

の灰色の部分はスタティックロジックを表し、 Reconfig Block "A" と示された部分はリコンフィギャラブルロジック

を表します。スタティックロジックは動作し続け、パーシャル BIT ファイルの読み込みの影響は受けません。リコ

ンフィギャラブルロジックは、パーシャル BIT ファイルの内容に置き換えられます。

1 つの FPGA でハードウェアを動的に時分割できる機能には、多数の利点があります。その一部を次に示します。

• 特定のファンクションをインプリメントするのに必要な FPGA のサイズを削減して、コストおよび消費電力を

削減

• アプリケーションで使用可能なアルゴリズムまたはプロトコルの選択肢が広がる

• デザインセキュリティの新しい技術を使用可能

• FPGA のフォールトトレランスを向上

• 再構成可能コンピューティングを促進

パーシャルリコンフィギュレーションは、サイズ、重量、消費電力、コストを削減するのに加え、新しいタイプの

FPGA デザインを可能にします。

X-Ref Target - Figure 1-1

図 1-1: パーシャルリコンフィギュレーションの基本的な概念

FPGA

ReconfigBlock “A”

A4.bitA3.bit

A2.bitA1.bit

X12001


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=partial-reconfiguration-in-vivado.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=partial-reconfiguration-for-ultrascale.html



第 1 章: 入門

用語

次の用語はパーシャルリコンフィギュレーション機能に特有の用語であり、このガイドで使用されます。

ボトムアップ合成

1 つまたは複数のプロジェクトで、デザインをモジュールごとに合成する手法。 Vivado では、ボトムアップ合成は

アウトオブコンテキスト (OOC) 合成と呼ばれます。 OOC 合成では OOC モジュールごとに個別のネットリスト (ま

たは DCP) が作成されます。パーシャルリコンフィギュレーションでは、モジュールの境界を越えて適化が実行

されないようにするため、 OOC 合成が必要です。 OOC 合成では、上位 (またはスタティック ) ロジックは各 OOC

モジュールのブラックボックスモジュール定義と共に合成されます。

コンフィギュレーション

各リコンフィギャラブルパーティションに対して 1 つのリコンフィギャラブルモジュールを含む完全なデザイン。

パーシャルリコンフィギュレーション FPGA プロジェクトには、複数のコンフィギュレーションがあります。各コ

ンフィギュレーションに対して、フル BIT ファイル 1 つと、各リコンフィギャラブルモジュール (RM) にパーシャル

BIT ファイルが 1 つずつ生成されます。

コンフィギュレーションフレーム

FPGA コンフィギュレーションメモリ空間のアドレス指定可能な小セグメント。リコンフィギャラブルフレーム

は、下位エレメントから構成されます。ザイリンクスデバイスでは、基本リコンフィギャラブルフレームは幅が

1 エレメント (CLB、ブロック RAM、 DSP)、高さが 1 クロック領域です。フレームに含まれるリソース数は、デバイ

スファミリによって異なります。

内部コンフィギュレーションアクセスポート (ICAP)内部コンフィギュレーションアクセスポート (ICAP) は、 SelectMAP インターフェイスの内部バージョン。詳細は、

『7 シリーズ FPGA コンフィギュレーションユーザーガイド』 (UG470) [参照 7] および『UltraScale アーキテクチャコ

ンフィギュレーションユーザーガイド』 (UG570) [参照 8] を参照してください。

メディアコンフィギュレーションアクセスポート (MCAP)各 UltraScale デバイスに含まれる特定の PCIe® ブロックから ICAP への専用リンク。このエントリポイントは、ザイ

リンクス PCIe IP をコンフィギュレーションするときに有効にできます。

パーシャルリコンフィギュレーション (PR)パーシャルビットストリームをダウンロードすることにより動作中の FPGA デザインのロジックのサブセットを変

更すること。




第 1 章: 入門

パーティション

デザインの再利用のために階層境界で定義されたデザインの論理セクション。新しくインプリメントするか、以前

のインプリメンテーションを保持します。保持されたパーティションは、機能が同一であるだけでなく、インプリ

メンテーションも同一です。

パーティション定義 (PD)これはプロジェクトフローのみで使用される用語です。パーティション定義は、モジュールインスタンス (または

リコンフィギャラブルパーティション) に関連付けられているリコンフィギャラブルモジュールセットを定義しま

す。 PD はモジュールのすべてのインスタンスに適用され、モジュールインスタンスのサブセットに関連付けること

はできません。

パーティションピン

スタティックロジックとリコンフィギャラブルロジックの間の論理および物理接続。パーティションピンは、ツー

ルで自動的に接続、配置、および管理されます。

プロセッサコンフィギュレーションアクセスポート (PCAP)プロセッサコンフィギュレーションアクセスポート (PCAP) は、内部コンフィギュレーションアクセスポート

(ICAP) と類似した、 Zynq-7000 SoC デバイスをコンフィギュレーションする場合に使用されるプライマリポート。

詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 9] を参照してください。

プログラマブルユニット (PU)UltraScale アーキテクチャで、リコンフィギュレーションに低限必要なリソース。 PU のサイズはリソースのタイ

プによって異なります。 UltraScale アーキテクチャでは隣接のサイトと配線リソース (インターコネクトタイル) が共

有されるので、 PU はペアで定義されます。

リコンフィギャラブルフレーム

FPGA 内でリコンフィギュレーション可能な小領域。リコンフィギャラブルフレームのビットストリームサイズ

は、フレームに含まれるロジックのタイプによって異なります。

リコンフィギャラブルロジック

リコンフィギャラブルモジュールの一部である論理エレメント。パーシャル BIT ファイルを読み込むと、これらの

論理エレメントが変更されます。 LUT、フリップフロップ、ブロック RAM、 DSP ブロックなど、さまざまなタイプ

の論理コンポーネントをリコンフィギュレーションできます。

リコンフィギャラブルモジュール (RM)リコンフィギャラブルパーティションにインプリメントされるネットリストまたは HDL 記述。 1 つのリコンフィ

ギャラブルパーティションには複数の RM が含まれます。




第 1 章: 入門

リコンフィギャラブルパーティション (RP)インスタンスをリコンフィギャラブルと定義する属性セット。異なるリコンフィギャラブルモジュールがインプリ

メントされる階層レベルです。 opt_design、 place_design、 route_design などの Tcl コマンドでは、インス

タンスに設定されている HD.RECONFIGURABLE プロパティが検出され、正しく処理されます。

スタティックロジック

リコンフィギャラブルパーティションに含まれない論理エレメント。スタティックロジックは、リコンフィギュ

レーションされることはなく、リコンフィギャラブルパーティションがリコンフィギュレーションされている間も

常にアクティブです。上位ロジックとも呼ばれます。

スタティックデザイン

パーシャルリコンフィギュレーション中に変更されないデザイン部分。上位モジュールと、リコンフィギャラブ

ルと定義されていないすべてのモジュールを含みます。スタティックデザインは、スタティックロジックとスタ

ティック配線で構成されます。

設計に関する考慮事項

パーシャルリコンフィギュレーション (PR) は、 Vivado Design Suite のアドバンスフローです。 PR プロジェクトを開

始する前に、次の要件およびガイドラインを理解しておく必要があります。

パーシャルリコンフィギュレーションの要件とガイドライン

• パーシャルリコンフィギュレーションには、 Vivado 2013.3 以降を使用する必要があります。

° パーシャルリコンフィギュレーションは ISE Design Suite でもサポートされています。 Virtex-6、 Virtex-5、

Virtex-4 デバイスを使用したパーシャルリコンフィギュレーションでのみ、 ISE Design Suite を使用してく

ださい。詳細は、『パーシャルリコンフィギュレーションユーザーガイド』 (UG702) [参照 10] を参照して

ください。

• リコンフィギャラブル領域を定義するには、エレメントタイプごとにフロアプランが必要です。

° 7 シリーズデバイスでは、 Pblock の高さをフレーム/クロック領域の境界に揃える必要があります。これに

より高の QoR を達成でき、 RESET_AFTER_RECONFIG をイネーブルにできます。

° UltraScale では、フロアプランにより柔軟性があります。 Pblock をフレーム/クロック領域の境界の手前で止

め、配線を拡張できるようにすることをお勧めします。このようにすると、配線性および QoR が大幅に向

上することがあります。

° 幅に関する規則もあります。詳細は、第 3 章の「リコンフィギャラブル領域のフロアプランを作成」を参

照してください。

• ボトムアップ/OOC 合成 (複数のネットリスト /DCP ファイルを作成) およびリコンフィギャラブルモジュール

ネットリストファイルの管理は、ユーザーの責任で行ってください。

° サードパーティ合成ツールを使用する場合は、 I/O の挿入をディスエーブルにする必要があります。

° Vivado OOC 合成では、 out_of_context モードにすると I/O の挿入は自動的にディスエーブルになります。

• 標準のタイミング制約がサポートされ、必要に応じて追加のタイミングバジェット機能も使用できます。




第 1 章: 入門

• デザインを完成させるために便利な専用のデザインルールチェック (DRC) が用意されています。

• PR デザインでは、パーシャルリコンフィギュレーションの開始だけでなく、 FPGA 内またはシステムデザイン

の一部としてパーシャル BIT ファイルを配布することも考慮する必要があります。

• Vivado Design Suite では、 Partial Reconfiguration Controller IP がサポートされています。このカスタマイズ可能な

IP は、ザイリンクスデバイスでのパーシャルリコンフィギュレーションのコアタスクを管理します。ハード

ウェアまたはソフトウェアからのトリガーの受信、ハンドシェークおよび分離タスクの管理、メモリロケー

ションからのパーシャルビットストリームの取得、 ICAP へのパーシャルビットストリームの配布を実行しま

す。 Partial Reconfiguration Controller IP の詳細は、ザイリンクスウェブサイトを参照してください。

• リコンフィギャラブルパーティションには、そのパーティションにインプリメントされるさまざまなリコン

フィギャラブルモジュールで使用されるすべてのピンを含める必要があります。リコンフィギャラブルモ

ジュールで、ほかのリコンフィギャラブルモジュールとは異なる入力または出力が使用される場合、結果のリ

コンフィギャラブルモジュールの入力または出力がそのリコンフィギャラブルモジュール内で接続されなくな

る可能性があります。この状況がある場合、ツールでリコンフィギャラブルモジュール内の未使用の入力また

は出力すべてに対して LUT1 バッファーが挿入されます。出力 LUT1 は定数値に接続されます。この定数値は、

未使用の出力ピンの HD.PARTPIN_TIEOFF プロパティにより制御できます。このプロパティの詳細は、第 5 章

の「ブラックボックス」を参照してください。

• ビットストリームの生成でブラックボックスがサポートされます。ポートを定数値に固定する方法の詳細は、

第 5 章の「ブラックボックス」を参照してください。

• ユーザーリセット信号では、 RM 内のロジックがレベルを認識するのかエッジを認識するのかを決定してくだ

さい。リセット回路がレベルを認識する場合 (FIFO などの一部 IP の場合など)、リコンフィギュレーションが完

了するまで RM リセットは適用しないでください。

デザインパフォーマンス

パフォーマンスの評価基準はデザインによって異なり、付録 A 「階層デザインフロー」の階層デザイン設計手法に

従うことにより、結果を向上できます。この資料は ISE Design Suite 用に作成されたものですが、その設計手法は

Vivado Design Suite にも適用できます。設計に関する追加の推奨事項は、『UltraFast 設計手法ガイド (Vivado Design

Suite 用)』 (UG949) [参照 11] を参照してください。

ただし、シリコンの分離に必要な追加の制限事項があり、これがほとんどのデザインに影響します。配線の格納、

排他配置、リコンフィギャラブルモジュールの境界を越えた適化を実行しないなどのパーシャルリコンフィギュ

レーション規則を適用すると、 PR デザインの全体的な集積度およびパフォーマンスは同等のフラットデザインより

低くなります。 PR デザインの全体的なデザインパフォーマンスは、リコンフィギャラブルパーティションの数、

これらのパーティションへのインターフェイスピンの数、 Pblock のサイズおよび形状などの要素に左右されます。

パーシャルリコンフィギュレーションをソリューションとして考慮するには、デザインに追加のタイミングスラッ

クおよびリソースオーバーヘッドが必要です。デザインを PR に使用できるかを評価する際の詳細は、 71 ページの

「インプリメンテーション要件の作成」を参照してください。


https://japan.xilinx.com/products/intellectual-property/prc.html



第 1 章: 入門

PR デザインの条件

• コンポーネントタイプによって、リコンフィギュレーション可能なものとそうでないものがあります。

7 シリーズデバイスでは、コンポーネントの規則は次のとおりです。

° リコンフィギュレーション可能なリソースには、 CLB、ブロック RAM、 DSP コンポーネント、配線リソー

スなどがあります。

° 次のクロックおよびクロック調整ロジックはリコンフィギュレーション不可能なので、スタティック領域

に配置する必要があります。

- BUFG、 BUFR、 MMCM、 PLL などのコンポーネント

° 次のコンポーネントはリコンフィギュレーション不可能なので、スタティック領域に配置する必要があり

ます。

- I/O および I/O 関連のコンポーネント (ISERDES、 OSERDES、 IDELAYCTRL)

- シリアルトランシーバー (MGT) および関連のコンポーネント

- アーキテクチャ機能コンポーネント (BSCAN、 STARTUP、 ICAP、 XADC など)

UltraScale および UltraScale+ デバイスでは、より多くのコンポーネントタイプをリコンフィギュレーション可

能です。

° CLB、ブロック RAM、 DSP コンポーネント、配線リソース

° クロックおよびクロック調整ロジック (BUFG、 MMCM、 PLL などのコンポーネント )

° I/O および I/O 関連のコンポーネント (ISERDES、 OSERDES、 IDELAYCTRL)

注記: I/O コンポーネントの変更タイプは制限されます。詳細は、第 7 章の「I/O 規則」を参照してくだ

さい。

° シリアルトランシーバー (MGT) および関連のコンポーネント

° PCIe、 CMAC、 Interlaken、および SYSMON ブロック

° これらの新しいコンポーネントは、特定の規則に従う必要があります。たとえば、 I/O のパーシャルリコ

ンフィギュレーションでは、バンク全体とそのフレームに含まれるすべてのクロックリソースを一緒にリ

コンフィギュレーションする必要があります。

° BSCAN、 STARTUP、 ICAP、 FRAME_ECC などのコンフィギュレーションコンポーネントのみをデザイン

のスタティック部分に配置する必要があります。

• リコンフィギャラブルパーティションへのグローバルクロックリソースの配置は、デバイスおよびこれらのリ

コンフィギャラブルパーティションで使用されるクロック領域によって制限されます。

• IP をインプリメントするのに使用されるコンポーネントまたは IP で必要な接続によって、 IP の制限が発生する

場合があります。次に例を示します。

° Vivado デバッグコア (RM 内でのデバッグコアの使用については「Vivado デバッグコアの使用」を参照)

° エンベデッドグローバルバッファーまたは I/O を含む IP モジュール (7 シリーズのみ)

° メモリ IP コントローラー (MMCM および BSCAN)

• リコンフィギャラブルモジュールは、リコンフィギュレーション後に既知の状態から開始するよう初期化する

必要があります。 7 シリーズを除くすべてのデバイスでは、 PR が完了すると GSR が自動的に適用されます。 7

シリーズデバイスでは、 Pblock 要件が満たされていれば、 RESET_AFTER_RECONFIG プロパティを使用して

GSR をオンにできます。




第 1 章: 入門

• パーシャルリコンフィギュレーション中にリコンフィギャラブル領域とスタティック部分の接続を解除するに

は、デカップリングロジックをお勧めします。

° GSR イベントが発生すると、コンフィギュレーションが完了するまで RM 内のすべてのロジックがリセッ

トに保持されます。ただし、 RM 出力はランダムになるので、すべてのダウンストリームロジックを分離

する必要があります。 7 シリーズで RESET_AFTER_RECONFIG を使用しない場合、リコンフィギュレー

ション中に誤ったデータがキャプチャされないようにするため (メモリへの誤った書き込みなど)、クロッ

クおよび入力の追加の分離が必要な場合があります。

° Vivado Design Suite には、 Partial Reconfiguration Decoupler IP が含まれます。この IP を使用すると、 MUX を

挿入して AXI4-Lite、 AXI4-Stream、およびカスタムインターフェイスを効率的に分離できます。 Partial

Reconfiguration Decoupler IP の詳細は、ザイリンクスウェブサイトを参照してください。

• リコンフィギャラブルパーティションは Pblock を使用してフロアプランする必要があるので、モジュールは物

理的に隔離でき、タイミングを満たすことができるブロックである必要があります。モジュールが完成したら、

このデザインを PR でない通常のフローで実行し、配置、配線、およびタイミング結果の初期評価を実行するこ

とをお勧めします。通常のフローで問題が発生する場合は、 PR フローに移行する前に解決しておく必要があり

ます。

• RP のインターフェイスをできるだけ適化します。 RP のインターフェイスピンの数が多すぎると、タイミン

グおよび配線の問題が発生することがあります。これは、パーティションピンが密集して配置されている場合

に特に問題となります。これは、次の 2 つの理由で発生します。

a. パーティションピンの数に対して RP Pblock が小さい。

b. スタティック接続のため、すべてのパーティションピンが小さなエリアに配置されている。

PR を設計およびフロアプランする際は、 RP インターフェイスを考慮してください。

• Virtex-7 SSI デバイス (7V2000T、 7VX1140T、 7VH870T、 7VH580T) には、次の 2 つの基本的な要件があります。

° リコンフィギャラブル領域は、完全に 1 つの SLR に含まれている必要があります。これにより、グローバ

ルリセットイベントがリコンフィギャラブルモジュール内のすべてのエレメントで正しく同期するように

なり、すべての SLL (Super Long Line) がデザインのスタティック部分に含まれます。 SLL はパーシャルリ

コンフィギュレーションできません。

° 7 シリーズ SSI デバイスの初期コンフィギュレーションを SPIx1 インターフェイスを介して実行する場合

は、リコンフィギャラブルモジュールのある SLR の ICAP か、 JTAG などの外部ポートに、パーシャル

ビットストリームを配布する必要があります。初期コンフィギュレーションをほかのコンフィギュレー

ションポートを介して実行した場合は、マスター ICAP をパーシャルビットストリームの配布ポートとし

て使用できます。

• UltraScale デバイスには、パーシャルリコンフィギュレーションイベントに関して新たな要件があります。新

しいリコンフィギャラブルモジュールのパーシャルビットストリームを読み込む前に、現在のリコンフィギャ

ラブルモジュールをクリアして、リコンフィギュレーションの準備をする必要があります。 UltraScale+ デバイ

スにはこの制限はありません。詳細は、第 8 章の「UltraScale デバイスでの BIT ファイルのサマリ」を参照して

ください。

• パーシャルビットストリームの専用暗号化は、ネイティブでサポートされています。 UltraScale デバイスでサ

ポートされていないユースケースは、 134 ページの「既知の制限」を参照してください。

• デバイスでフレームごとの CRC チェック機構を write_bitstream を使用してイネーブルにでき、各フレー

ムを読み込む前に検証できます。


https://japan.xilinx.com/products/intellectual-property/pr-decoupler.html




第 1 章: 入門

• PR の境界を越える適化は、インプリメンテーションツールで禁止されています。 PR デザインの WNS パス

は、 RP の境界をまたぐファンアウトの大きい制御/ リセット信号であることがよくあります。 RP の境界をまた

ぐファンアウトの大きい信号は、ドライバーを複製できないので避けてください。ツールで適化/複製が柔軟

に実行されるようにするため、次を考慮してください。

° RP の入力では、 RP の境界をまたぐ信号をシングルファンアウトネットにし、ファンアウトの前に RM 内

で信号にレジスタを付けます。これは、 RM 内で必要に応じて複製するか、グローバルリソースに配置で

きます。

° 出力でも同様に、 PR の境界をまたぐ信号をシングルファンアウトネットにします。複製/ 適化のため、

ファンアウトの前にスタティックで信号にレジスタを付けます。

• 複数の RP を含むデザインでは、 2 つの RP 間を直接接続しないようにすることをお勧めします。これには、非

同期のスタティックロジック (スタティックでレジスタが付いていない) を通過する接続も含まれます。 2 つの

RP 間に直接接続がある場合は、スタティックタイミング解析で可能なすべてのコンフィギュレーションを検証

し、これらのインターフェイスでタイミングが満たされることを確実にする必要があります。これを 1 人の

ユーザーが所持して管理する閉じたシステムで実行することは可能ですが、異なる RM を複数のユーザーで開

発するデザインで検証することは不可能な場合があります。スタティック部分に同期エンドポイントを追加す

ることにより、 RM がインプリメントされたコンフィギュレーションでタイミングが満たされれば、どのコン

フィギュレーションでもタイミングが満たされるようになります。

パーシャルリコンフィギュレーションはザイリンクスデバイスの高度な機能であり、シリコンおよびツールの性能

を理解しておくことが成功の鍵となります。開発プロセスでは、トレードオフを理解および考慮する必要がありま

すが、終的には FPGA デザインのより柔軟性なインプリメンテーションを達成できます。

パーシャルリコンフィギュレーションのライセンス

パーシャルリコンフィギュレーションは、 Vivado Design Suite にオプションで追加可能なライセンス製品です。価格

および注文情報は、販売代理店までお問い合わせください。パーシャルリコンフィギュレーションのライセンスは、

System Edition および Design Edition に含まれており、 WebPACK Edition では購入可能です。

パーシャルリコンフィギュレーションライセンスは、 HD.RECONFIGURABLE プロパティを含むデザインで個別の

インプリメンテーションコマンド (opt_design、 place_design、 route_design、 write_bitstream) が実行

されたときにチェックされます。パーシャルリコンフィギュレーションデザインをインプリメント (配置および配

線) し、パーシャルビットストリームを生成するには、ライセンスが必要です。 Vivado IDE 内で固有のチェックは実

行されず、ライセンス機能は保持されません。


https://japan.xilinx.com/company/contact/index.htm



第 2 章

一般的なアプリケーション

概要

パーシャルリコンフィギュレーションの基本的な前提は、マイクロプロセッサでタスクを切り替えることができる

のと同様に、デバイスハードウェアリソースを時分割できるということです。デバイスでハードウェアのタスクが

切り替えられるので、ソフトウェアインプリメンテーションの柔軟性とハードウェアインプリメンテーションのパ

フォーマンスの両方において利点があります。このテクノロジの利点を、いくつかのシナリオを示しながら説明し

ます。

ネットワーク接続された複数のインターフェイス

パーシャルリコンフィギュレーションは、サイズ、重量、消費電力、コストを削減しながら、従来の FPGA アプリ

ケーションを適化します。時間に依存しない機能を特定して分離し、リコンフィギャラブルモジュールとしてイ

ンプリメントすることにより、 1 つのデバイス内で必要に応じて機能を入れ替えます。 40G OTN マックスポンダー

アプリケーションがその典型的な例です。マックスポンダーのクライアント側のポートは、複数のインターフェイ

スプロトコルをサポートできますが、 FPGA がコンフィギュレーションされるまで、どのプロトコルが使用される

かシステムで予測することは不可能です。 FPGA をリコンフィギュレーションする必要がないようにし、すべての

ポートがディスエーブルにならないようにするには、 16 ページの図 2-1 に示すように、すべてのインターフェイス

プロトコルをすべてのポートにインプリメントする必要があります。




第 2 章: 一般的なアプリケーション

各ポートで使用できるのは 1 つの規格のみなので、このデザインは非効率的です。パーシャルリコンフィギュレー

ションを使用すると、図 2-2 に示すように各ポートインターフェイスをリコンフィギャラブルモジュールにするこ

とにより、より効率的なデザインを作成できます。複数のプロトコルエンジンを 1 つのポートに接続するために必

要だった MUX エレメントも不要になります。

この基本的な概念をさまざまなデザインで利用できます。ソフトウェア無線 (SDR) は、相互に排他的な機能を持ち、

この機能を時分割することで柔軟性およびリソース使用率が大幅に向上する多数のアプリケーションの 1 つです。


図 2-1: パーシャルリコンフィギュレーションを使用しない場合のネットワークの切り替え


図 2-2: パーシャルリコンフィギュレーションを使用した場合のネットワークの切り替え

FPGA

Config Memory Storage

10GigE tx/rx

OC192 tx/rx

OTU2 tx/rx

SwitchFabric

10GigE tx/rx

OC192 tx/rx

OTU2 tx/rx

OC192 tx/rx

Port 1

Port 2

Port 3

Port 4

X12003





パーシャルリコンフィギュレーションデザインには、効率性以外にも利点があります。 16 ページの図 2-2 の例で

は、スタティックロジック (Switch Fabric) に影響を与えることなく、新しいプロトコルをいつでもサポートできま

す。 1 つのポートに新しい規格を読み込んでも、ほかの既存ポートには影響はありません。追加の規格を作成してコ

ンフィギュレーションメモリライブラリに追加できるので、デザイン全体を再設計する必要はありません。これに

より、 Switch Fabric およびポートのダウンタイムを削減でき、柔軟性および信頼性が向上します。デバッグモ

ジュールを作成することもでき、ポートでエラーが発生した場合に未使用のポートを解析/修正ロジックと共に読み

込んで、リアルタイムに問題を対処できます。

16 ページの図 2-2 の例では、各プロトコルのターゲットとなる各物理ロケーションに対し、パーシャル BIT ファイ

ルを生成する必要があります。パーシャル BIT ファイルは、デバイス上の物理的な領域に関連付けられます。この

例では、 4 つのロケーションでそれぞれ 4 つのプロトコルに対応するため、 16 個のパーシャル BIT ファイルがあり

ます。

標準バスインターフェイスを使用したコンフィギュレーション

パーシャルリコンフィギュレーションは、システムアーキテクチャとより互換性のあるインターフェイス規格を使

用して、新しいコンフィギュレーションポートを作成できます。たとえば、 FPGA を PCIe バスのペリフェラルと

し、システムホストで PCIe® 接続を介して FPGA をコンフィギュレーションできます。パワーオンリセットの後、

FPGA はフル BIT ファイルでコンフィギュレーションする必要がありますが、フル BIT ファイルには PCIe インター

フェイスと内部コンフィギュレーションアクセスポート (ICAP) への接続のみが含まれている場合があります。

ビットストリームを圧縮するとサイズが削減され、この初期デバイス読み込みのコンフィギュレーション時間も短

縮されるので、 FPGA コンフィギュレーションで PCIe のエニュメレーション仕様を満たすことができるようになり

ます。

その後、図 2-3 に示すように、システムホストで PCIe ポートを介してパーシャル BIT ファイルをダウンロードする

と、 FPGA の大部分の機能をコンフィギュレーションできます。


図 2-3: PCIe インターフェイスを使用したコンフィギュレーション

ICAP

PCle

Static

Full Bit File

PartialBit File





PCIe 規格では、要求をサービスできない場合にも要求に応答するため、ペリフェラル (この例の場合は FPGA) が必

要です。 FPGA 全体をリコンフィギュレーションすると、この要件に違反します。 PCIe インターフェイスはスタ

ティックロジックの一部なので、パーシャルリコンフィギュレーションのプロセス中も常にアクティブであり、

FPGA はリコンフィギュレーション中でも PCIe コマンドに応答できます。

Tandem コンフィギュレーションは関連したソリューションであり、一見ここに示す例と同じであるように見えます

が、パーシャルリコンフィギュレーションを使用したソリューションは、 Tandem コンフィギュレーションとは次の

2 つの点が異なります。

• PR でのコンフィギュレーションプロセスは圧縮により小型化および高速化されたフルデバイスコンフィギュ

レーションであり、その後パーシャルビットストリームによりブラックボックス領域が上書きされてコンフィ

ギュレーションが完了します。 Tandem コンフィギュレーションは 2 段階のコンフィギュレーションで、各コン

フィギュレーションフレームがプログラムされるのは 1 回だけです。

• 7 シリーズデバイスの Tandem コンフィギュレーションでは、ユーザーアプリケーションのダイナミックリコ

ンフィギュレーションはできません。パーシャルリコンフィギュレーションを使用すると、ダイナミック領域

に異なるユーザーアプリケーションまたはフィールドアップデートを読み込み直すことができます。UltraScale

デバイスの Tandem コンフィギュレーションでは、フィールドアップデートが可能であり、パーシャルリコン

フィギュレーションと互換性があります。全体的なフローは、 Tandem コンフィギュレーションで 2 段階の初期

読み込みを実行した後、ユーザーアプリケーションをダイナミックに修正するパーシャルリコンフィギュレー

ションを実行します。

Tandem コンフィギュレーションは、エニュメレーション要件を満たすため、 PCIe エンドポイントを高速コンフィ

ギュレーションするソリューションとして設計されています。詳細は、次の資料を参照してください。

• 『7 Series FPGAs Integrated Block for PCI Express 製品ガイド』 (PG054) [参照 12]

• 『Virtex-7 FPGA Gen3 PCIe Integrated Block for PCI Express 製品ガイド』 (PG023) [参照 13]

• 『LogiCORE IP UltraScale FPGAs Gen3 Integrated Block for PCI Express 製品ガイド』 (PG156) [参照 14]





ダイナミックリコンフィギュレーション可能なパケットプロセッサ

パケットプロセッサでパーシャルリコンフィギュレーションを使用すると、受信したパケットタイプに基づいてす

ばやくプロセッシング機能を変更できます。図 2-4 では、パケットにパーシャル BIT ファイルを含むヘッダー、ま

たはパーシャル BIT ファイルを含む特殊パケットがあります。パーシャル BIT ファイルは、処理された後、 FPGA の

コプロセッサをリコンフィギュレーションするために使用されます。この例では、パーシャル BIT ファイルの定義

済みライブラリに依存せずに、受信データパケットに基づいて FPGA 自体をリコンフィギュレーションしています。


図 2-4: ダイナミックリコンフィギュレーション可能なパケットプロセッサ

FPGA

ICAP

Packet Processor

PartiallyReconfigurableCo-processor

Data

Data PBF HData PBF H

PBF: Partial Bit File

1 2

2 1X12005





非対称キー暗号化

パーシャルリコンフィギュレーションなしでは不可能な新しいアプリケーションがあります。パーシャルリコン

フィギュレーションと非対称暗号化を組み合わせると、 FPGA コンフィギュレーションファイルをより確実に保護

できるようになります。非対称暗号化の詳細は、ウィキペディアの「公開鍵暗号」トピックを参照してください。

図 2-5 では、グレーで示された部分の機能を FPGA の物理パッケージ内にインプリメントできます。 cleartext の情報

および秘密キーが保護されたコンテナーの外に漏洩することはありません。

このデザインの実際のインプリメンテーションでは、初期 BIT ファイルは暗号化されていないデザインで、機密情

報は含まれていません。初期デザインには、公開キーと秘密キーのペアを生成するアルゴリズムと、ホスト、

FPGA、および ICAP を接続するインターフェイスのみが含まれます。

初期 BIT ファイルが読み込まれた後、 FPGA で公開キーと秘密キーのペアが生成されます。公開キーはホストに送信

され、ホストはこれを使用してパーシャル BIT ファイルを暗号化します。暗号化されたパーシャル BIT ファイルは

FPGA にダウンロードされ、その FPGA 内で復号化され、 ICAP に送信されて、 FPGA がパーシャルリコンフィギュ

レーションされます (21 ページの図 2-6)。


図 2-5: 非対称キー暗号化

Public Key

Private Key

f

cleartext

ciphertext

f cleartext

Key Co-generation

X12022



http://ja.wikipedia.org/wiki/%E5%85%AC%E9%96%8B%E9%8D%B5%E6%9A%97%E5%8F%B7



パーシャル BIT ファイルが FPGA デザインの大部分を占め、スタティックデザインのロジックは FPGA リソースの

ほんの一部しか使用しない場合があります。

これには、次のような利点があります。

• 公開キーと秘密キーのペアをいつでも再生成できます。ホストから新しいコンフィギュレーションがダウン

ロードされたときに、別の公開キーで暗号化できます。パワーオンリセットの後など FPGA が同じパーシャル

BIT ファイルでコンフィギュレーションされる場合でも、別の公開キーが使用されます。

• 秘密キーは SRAM に格納されます。 FPGA の電源が切れると、秘密キーも失われます。

• システムが盗難に遭い、 FPGA の電源がオンのままでも、秘密キーは汎用 FPGA プログラマブルロジックに格

納されているので、そのキーを発見するのは非常に困難です。特殊レジスタには格納されません。秘密キーを

格納する各レジスタビットを、物理的にリモートで無関係の領域に配置できます。

まとめ

パーシャルリコンフィギュレーションは、サイズ、重量、消費電力、コストを削減するだけでなく、新しいタイプ

の FPGA デザインを可能にします。


図 2-6: 暗号化されたパーシャル BIT ファイルの読み込み

Host

Bit File Library

Config 1

Config 2

Config 3

Encrypt Algorithm

Public

FPGA

Generate Key Pair

Public Private

External Interface

Decrypt Algorithm ICAP

X12023




第 3 章

Vivado ツールフロー

概要

Vivado® パーシャルリコンフィギュレーション (PR) フローには、標準デザインフローとは異なる点がいくつかありま

す。下位レベルの詳細はシリコンの要件を満たすためにインプリメンテーションツールで自動管理されますが、デザ

インの構造とフロアプランはユーザーが定義する必要があります。 PR デザインの処理手順は、次のとおりです。

1. スタティックモジュールとリコンフィギャラブルモジュールを別々に合成します。

2. 物理制約 (Pblock) を作成してリコンフィギャラブル領域を定義します。

3. 各リコンフィギャラブルパーティションに HD.RECONFIGURABLE プロパティを設定します。

4. 完全なデザイン (スタティックモジュールと、リコンフィギャラブルパーティションごとに 1 つのリコンフィ

ギャラブルモジュール) をコンテキストでインプリメントします。

5. 完全に配線済みのデザインのデザインチェックポイントを保存します。

6. このデザインからリコンフィギャラブルモジュールを削除し、スタティック部分のみのデザインチェックポイ

ントを保存します。

7. スタティック部分の配置と配線を固定します。

8. スタティックデザインに新しいリコンフィギャラブルモジュールを追加し、新しいコンフィギュレーションを

インプリメントして、配線済みデザイン全体のチェックポイントを保存します。

9. すべてのリコンフィギャラブルモジュールがインプリメントされるまで手順 8 を繰り返します。

10. すべてのコンフィギュレーションに対して検証ユーティリティ (pr_verify) を実行します。

11. 各コンフィギュレーションのビットストリームを作成します。




第 3 章: Vivado ツールフロー

パーシャルリコンフィギュレーションコマンド

PR フローは、非プロジェクトバッチモード /Tcl インターフェイス (非プロジェクトベースのコマンド ) および RTL

ベースのプロジェクトフローでサポートされています。非プロジェクトフローのスクリプト例およびフローの設定

手順は、『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 1] を参照してく

ださい。詳細は、このチュートリアルを参照してください。

次のセクションでは、 PR フローに必要な特定のコマンドおよびオプションについて説明します。 PR フローを実行

するためのコマンドの使用例も示します。個別のコマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンス

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

合成

パーシャルリコンフィギュレーション可能なデザインを合成するのに特別なコマンドは必要ありませんが、ボトム

アップ合成を実行する必要があります。現在のところ、合成、適化、またはインプリメンテーションでサポート

されないコマンドはありません。

次の合成ツールがサポートされています。

• XST (7 シリーズデバイスのみサポート )

• Synplify

• Vivado 合成

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

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

は NGC2EDIF コマンドで EDIF に変換してインポートすることもできますが、今後は XST で生成された NGC フォー

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

重要: ボトムアップ合成は、各モジュールにそれぞれ合成プロジェクトがある合成フローです。通常は、下位モ

ジュールの自動 I/O バッファー挿入をオフにします。

この資料では、 Vivado 合成フローのみについて説明します。

上位モジュールの合成

各リコンフィギャラブルパーティション (RP) のブラックボックスを含む上位ネットリストが必要です。これに

は、上位合成にパーティションインスタンスのモジュールまたはエンティティ宣言を含め、ロジックが含まれな

いよう (モジュールは空) にする必要があります。

上位合成は、通常すべての上位ポートで I/O バッファーを推論またはインスタンシエートします。バッファー挿

入の制御については、『Vivado Design Suite ユーザーガイド : 合成』 (UG901) [参照 16] のこのセクションを参照してく

ださい。

synth_design -flatten_hierarchy rebuilt -top <top_module_name> -part <part>


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug901-vivado-synthesis.pdf;a=xSettingABottomUpFlowUsingTheOutOfContextFlow




リコンフィギャラブルモジュールの合成

各リコンフィギャラブルモジュールをスタティックデザインの同じブラックボックスにインスタンシエートする必

要があるので、それらのモジュールのインターフェイスが同一である必要があります。ブロックの名前も各インス

タンスですべて同じにし、インターフェイスのプロパティもすべて同一にする必要があります。デザインの各コン

フィギュレーションは、フラットデザインのようにアセンブルされます。

リコンフィギャラブルモジュールを合成するには、すべてのバッファー挿入をオフにする必要があります。これに

は、 synth_design コマンドを -mode out_of_context オプションを使用して実行します。

synth_design -mode out_of_context -flatten_hierarchy rebuilt -top <reconfig_module_name> -part <part>

synth_design コマンドは、デザインを合成して、その結果をメモリに格納します。結果をファイルに書き出すに

は、次のコマンドを使用します。

write_checkpoint <file_name>.dcp

合成後にメモリ内のデザインを閉じ、インプリメンテーションを合成とは別に実行することをお勧めします。

デザインモジュールの読み込み

デザインがメモリに読み込まれていない場合は、デザインを読み込む必要があります。スタティックデザインもリ

コンフィギャラブルモジュールも、さまざまな方法で読み込むことができます。コンフィギュレーションをインプ

リメントした後は、チェックポイントを使用して配置配線済みモジュールデータベースを読み込みます。

方法 1: ファイルの追加およびリンク

すべてのデザインソースを読み込んでリンクするには、この方法がも明確で詳細なので、推奨されます。次の手

順を実行すると、必要なデザインソースがすべて読み込まれ、リコンフィギャラブルパーティションの境界が定義

されます。

1. メモリ内に新しいプロジェクトを作成します。ターゲットデバイスは選択できますが、プロジェクトは保存さ

れません。

create_project -part <part> -in_memory

2. すべてのデザインソースを追加します。これには、スタティックまたはリコンフィギャラブルロジックの複数のチェックポイント、下位 RM ソースが含まれます。

add_files <top>.dcpadd_files <rp1_rmA_top>.dcpadd_files <rp1_rmA_lower>.dcpadd_files <rp2_rmA_top>.dcp

表 3-1: synth_design コマンドのオプション

コマンドオプション説明

-mode out_of_context 合成およびダウンストリームツールの I/O 挿入がオフになります。

out_of_context モードは、 write_checkpoint を実行したとき

にチェックポイントに保存されます。

-flatten_hierarchy rebuilt -flatten_hierarchy に使用できる値は複数ありますが、 PR フ

ローでは rebuilt が推奨されます。

-top 合成されるモジュールのモジュール/エンティティ名を指定します。

-part ターゲットにするザイリンクスパーツ (例: xc7k325tffg900-3) を

指定します。





3. SCOPED_TO_CELLS プロパティを使用して、階層レベル間の関係を定義します。

set_property SCOPED_TO_CELLS <RP1_module_instance> [get_files <rp1_rmA_top>.dcp]set_property SCOPED_TO_CELLS <RP1_lower_module_instance> [get_files <rp1_rmA_lower>.dcp]set_property SCOPED_TO_CELLS <RP2_module_instance> [get_files <rp2_rmA_top>.dcp]

4. デザインをリンクし、すべてのリコンフィギャラブルパーティションを定義します。

link_design -top <top> -part <part> -reconfig_partitions <RP1_module_instance> <RP2_module_instance>

方法 2: ネットリストデザインの読み込み

この方法は、 Vivado 合成以外のツールでモジュールを合成している場合に使用します。

read_edif <top>.edf/edn/ngc

read_edif <rp1_a>.edf/edn/ngc

read_edif <rp2_a>.edf/edn/ngc

link_design -top <top_module_name> -part <part>

方法 3: チェックポイントを開く /読み出し

スタティック ( 上位) デザインの合成またはインプリメンテーション結果がチェックポイントとして保存されてい

る場合は、 open_checkpoint コマンドを使用して読み込むことができます。このコマンドはスタティックデザイ

ンチェックポイントを読み込み、アクティブメモリで開きます。

open_checkpoint <file>

チェックポイントがスタティックのものではなくリコンフィギャラブルモジュールの完全なネットリストのもので

ある場合、インスタンス名を read_checkpoint -cell を使用して指定できます。チェックポイントがインプリ

メンテーション後のチェックポイントである場合は、 -strict オプションも使用する必要があります。このオプ

ションを合成後のチェックポイントで使用して、ポートが確実に一致するようにすることもできます。リコンフィ

ギャラブルモジュールのチェックポイントを読み込むには、指定のセルのブラックボックスが含まれている上位

デザインが開いている必要があります。その後、次のコマンドを実行します。

read_checkpoint -cell <cellname> <file> [-strict]

表 3-2: link_design コマンドのオプション


-part ターゲットにするザイリンクスパーツ (例: xc7k325tffg900-3) を

指定します。

-top インプリメントされるモジュールのモジュール/エンティティ名を指

定します。 link_design の前に set_property -top

<top_module_name> [current_fileset] を実行した場合は、こ

のオプションを使用する必要はありません。

-reconfig_partitions <args> デザインを開くときに読み込むリコンフィギャラブルパーティショ

ンを指定します。指定したリコンフィギャラブルパーティションに、

デザインで正しく処理されるように HD.RECONFIGURABLE プロパ

ティが設定されます。

-pr_config <arg> プロジェクトベースのデザインフローでのみ使用可能です。デザイ

ンを開くときに適用する PR コンフィギュレーションを指定します。





注意: 合成済みチェックポイントに含まれていない下位モジュールがある場合は、この方法は使用しないでくださ

い。 read_checkpoint -cell では、入れ子はサポートされません。「方法 1: ファイルの追加およびリンク」に説

明する link_design を使用した方法を使用してください。

方法 4: チェックポイントを開く /デザインをアップデート

この方法は、合成結果がネットリスト形式 (EDF または EDN) であり、スタティック部分が既にインプリメントされ

ている場合に便利です。次の例に、この状況が発生する 2 番目のコンフィギュレーションのコマンドを示します。

open_checkpoint <top>.dcp lock_design -level routingupdate_design -cells <rp1> -from_file <rp1_b>.edf/ednupdate_design -cells <rp2> -from_file <rp2_b>.edf/edn

複数のサブモジュールネットリストが含まれるリコンフィギャラブルモジュールの追加

リコンフィギャラブルモジュールに複数のサブモジュールネットリストが含まれていると、 Vivado ツールでサブモ

ジュールネットリストを処理するのが困難になることがあります。これは、 PR フローでは RM ネットリストがメモ

リで既に開いているデザインに追加されるからです。この場合、 update_design -cells コマンドを使用する必

要があり、は各 EDIF ファイルのセル名が必要ですが、セル名を取得するのが難しいことがあります。

Vivado Design Suite で RM サブモジュールネットリストを読み込みやすくするには、次の 2 つの方法があります。

方法 1: 1 つの RM チェックポイント (DCP) を作成

すべてのネットリストを含む RM チェックリスト (DCP) を作成します。この場合、 add_files コマンドを使用して

すべての EDIF (または NGC) ファイルを追加し、 link_design コマンドを使用して EDIF ファイルからそれぞれの

セルへの対応を解決します。次に、このプロセスに使用するコマンド例を示します。

add_files [list rm.edf ip_1.edf … ip_n.edf]# Run if RM XDC existsadd_files rm.xdclink_design -top <rm_module> -part <part>write_checkpoint rm_v#.dcpclose_project

重要: 1 つまたは複数の NGC ソースファイルも含む RM の処理には、この方法を使用してネットリストを DCP に結

合または変換することをお勧めします。

表 3-3: read_checkpoint オプション

オプション名説明

-cell リコンフィギャラブルモジュールの完全な階層名を指定します。

-strict セルを置き換えるためにポートが完全に一致している必要があり、

パーツ、パッケージ、スピードグレード値が同一であることを確認

します。インプリメンテーションデータを復元する際には使用する

必要があります。

<file> 読み込むチェックポイント (DCP) の完全パスまたは相対パスを指定し

ます。





その後、この新しく作成した RM チェックポイントを PR フローで使用します。次のコマンド例では、多数の

update_design -cell コマンドを 1 つの read_checkpoint -cell コマンドで置き換えています。

add_files static.dcplink_design -top <top> part <part>lock_design -level routingread_checkpoint -cell <rm_inst> rm_v#.dcp

方法 2: サブモジュールネットリストを RM の上位ネットリストと同じディレクトリに配置

update_design -cell コマンドを使用して PR デザインに上位 RM ネットリストを読み込むときに、すべての

サブモジュールネットリストを RM の上位ネットリストと同じディレクトリに配置しておきます。この場合、下

位ネットリストを指定する必要はなく、 update_design -cells コマンドで自動的に読み込まれます。この方法

は方法 1 ほど明示的ではありませんが、手順は少なくてすみます。この場合に RM ネットリストを読み込むコマン

ドは、次のようになります。

add_files static.dcplink_design -top <top> part <part>lock_design -level routingupdate_design -cells <rm_inst> -from_file rm_v#.edf

下位ネットリストが rm_v#.edf と同じディレクトリにあれば、後のコマンド (update_design) により自動的に

読み込まれます。

デザイン制約の読み込み

デザインフローのさまざまな段階で、各コンフィギュレーションに新しい制約を適用できます。 RM を DCP として

読み込むと、 DCP に保存されている制約が自動的に適用されます。さらに、 read_xdc コマンドを使用して、上

位または -cell オプションで指定したセルに制約を適用できます。制約が RM に直接または間接的に影響する場合

は、新しい制約を読み込む前に、 RM をブラックボックスとして残しておくのではなく、解決しておく必要があり

ます。そうしないと、制約が適用されなかったり、制約システムに正しく伝搬されない可能性があります。スタ

ティック部分は初期コンフィギュレーションでのみ配置配線されるので、スタティック部分が固定されているその

後のコンフィギュレーションのすべての制約は、インプリメントされる RP 領域にのみ適用されるようにする必要が

あります。

インプリメンテーション

PR フローでは、ハードウェアにさまざまなコンフィギュレーションを使用できるので、複数のインプリメンテー

ション run が必要です。 PR デザインの各インプリメンテーションはコンフィギュレーションと呼ばれます。デザイン

の各モジュール (スタティックまたはリコンフィギャラブルモジュール) は、インプリメントするか、既にインプリメ

ントされている場合はインポートします。デザインは 1 つのコンフィギュレーションでインプリメントし、後のコン

フィギュレーションでインポートされるように、スタティックデザインのインプリメンテーション結果は各コンフィ

ギュレーションで一貫している必要があります。追加のコンフィギュレーションは、スタティック部分をインポート

し、各リコンフィギャラブルモジュールをインプリメントまたはインポートすることにより作成できます。





PR でのインプリメンテーションコマンドおよびオプションのサポートに制限はありませんが、パーシャルリコン

フィギュレーションの基本要件に従っていないと、一部の適化およびサブルーチンが実行されないことがありま

す。 link_design または open_checkpoint コマンドを使用して論理デザインを読み込むと、次のコマンドを実

行できるようになります。

# Run if all constraints are not already loadedread_xdc

# Optional commandopt_design

place_design

# Optional commandphys_opt_design

route_design

インプリメンテーションデータの保持

PR フローでは、初のコンフィギュレーションからのスタティックロジックの配置配線結果を、その後のコンフィ

ギュレーション用に固定する必要があります。初のコンフィギュレーションのスタティックインプリメンテー

ションは、チェックポイントとして保存します。その後のコンフィギュレーションでチェックポイントを読み込む

際、配置配線を固定して、異なるコンフィギュレーション間でスタティックデザインが完全に同一になるようにし

ます。インポートしたチェックポイント (スタティックまたはリコンフィギャラブル) の配置配線を固定するには、

lock_design コマンドを使用します。

lock_design -level [logical|placement|routing] [cell_name]

上記のコマンドを使用してスタティックロジックを固定する場合は、 [cell_name] の指定はオプションです。

lock_design -level routing

インポートされた RM の結果を固定するには、インプリメンテーション後のチェックポイント内で完全な階層名を

指定する必要があります。

lock_design -level routing u0_RM_instance

パーシャルリコンフィギュレーションでは、サポートされる保持レベルは routing のみです。このコマンドには

ほかの保持レベルもありますが、ほかの階層デザインフローでのみ使用するようにしてください。





パーシャルリコンフィギュレーションの制約とプロパティ

パーシャルリコンフィギュレーションフロー特定のプロパティと制約があります。これらは PR 特定のインプリメ

ンテーションプロセスを開始し、パーシャルビットストリームに具体的な特性を適用します。パーシャルリコン

フィギュレーション用には、次の 4 種類の制約およびプロパティがあります。

モジュールをリコンフィギャラブルと定義

PR デザインをインプリメントするには、各リコンフィギャラブルモジュールをリコンフィギャラブルとして指定す

る必要があります。これには、リコンフィギュレーションする各階層セルの上位にプロパティを設定します。た

とえば、 inst_count という名前のリコンフィギャラブルパーティションがあり、このパーティションに 2 つのリ

コンフィギャラブルモジュール count_up および count_down があるデザインがあるとします。初のコンフィ

ギュレーションをインプリメントする前に次のコマンドを実行する必要があります。

set_property HD.RECONFIGURABLE TRUE [get_cells inst_count]

これにより、 PR デザインを正しくインプリメントするために必要なツールのパーシャルリコンフィギュレーション

機能がアクティブになります。 HD.RECONFIGURABLE プロパティにより、いくつかの制約およびタスクが適用され

ます。

• 指定のセルおよびインターフェイスネットに DONT_TOUCH を設定します。これにより、モジュールの境界を越

えた適化は実行されなくなります。

• セルの Pblock に EXCLUDE_PLACEMENT を設定します。これにより、スタティックロジックがリコンフィギャ

ラブル領域に配置されるのを防ぎます。

• セルの Pblock に CONTAIN_ROUTING を設定します。これにより、リコンフィギャラブルモジュールのすべて

の配線が境界内に収められます。

• DRC、クロック配線などで特別のコードをイネーブルにします。

制約およびプロパティ必須/オプション

モジュールをリコンフィギャラブルと定義必須

リコンフィギャラブル領域のフロアプランを作成必須

リコンフィギュレーション後にリセットを適用オプション (強く推奨)

表示スクリプトをオンオプション





リコンフィギャラブル領域のフロアプランを作成

各リコンフィギャラブルパーティションには、リコンフィギャラブルモジュールに使用可能な物理リソースを定義

するため Pblock が必要です。この Pblock はリコンフィギャラブルパーティションに設定するので、次の制限および

要件が適用されます。

• Pblock には、有効なリコンフィギャラブルエレメントタイプのみを含めます。領域がほかのサイトタイプと重

なる可能性もありますが、これらのほかのサイトは resize_pblock コマンドに含めないようにする必要があ

ります。

• 各コンポーネントタイプの複数の Pblock 矩形を使用してリコンフィギャラブルパーティション領域を作成でき

ますが、配線性が高くなるよう、これらの矩形は連続している必要があります。リコンフィギャラブルでない

リソース用のギャップを含めることは可能ですが、一般的には、全体の形をシンプルにした方がデザインを配

置配線しやすくなります。

• 7 シリーズデバイスで RESET_AFTER_RECONFIG プロパティを使用する場合は、 Pblock の高さをクロック領域の

境界に揃える必要があります。詳細は、「リコンフィギュレーション後にリセットを適用」を参照してください。

• 7 シリーズデバイスでは、 Pblock の幅および構成ためにインターコネクト列が分割されないようにする必要が

あります。詳細は、第 6 章の「7 シリーズデバイスでの Pblock の作成」を参照してください。

• 一部のパーツで Pblock を定義する際は、大の RM のリソース使用量を考慮する必要があります。大の RM

で使用されるリソース数がターゲットデバイスの資料に記載されている大リソース数を超えている場合は、

write_bitstream コマンドでエラーが生成されます。

• Pblock がデザインのほかの Pblock と重ならないようにする必要があります。

• リコンフィギャラブルパーティションのネスト (コンフィギャラブルパーティション内に別のリコンフィギャ

ラブルパーティションを含める ) は現在のところサポートされていません。リコンフィギャラブルパーティ

ション内のフロアプランロジックの標準 Pblock およびネストされた Pblock はサポートされています。





次に、リコンフィギャラブルパーティションの制約例を示します。

#define a new pblockcreate_pblock pblock_count

#add a hierarchical module to the pblockadd_cells_to_pblock [get_pblocks pblock_count] [get_cells [list inst_count]]

#define the size and components within the pblockresize_pblock [get_pblocks pblock_count] -add SLICE_X136Y50:SLICE_X145Y99resize_pblock [get_pblocks pblock_count] -add RAMB18_X6Y20:RAMB18_X6Y39resize_pblock [get_pblocks pblock_count] -add RAMB36_X6Y10:RAMB36_X6Y19

表 3-4: Pblock のコマンドとプロパティ

コマンド /プロパティ名説明

create_pblock 各リコンフィギャラブルパーティションインスタンスの初期 Pblock を

作成します。

add_cells_to_pblock Pblock に含まれるインスタンスを指定します。通常、ボトムアップ合

成で定義される階層レベルを指定します。

resize_pblock Pblock のサイトタイプ (SLICE、 RAMB36 など) とサイト位置を定義し

ます。

RESET_AFTER_RECONFIG リコンフィギャラブル領域での専用 GSR イベントの使用を制御する

Pblock プロパティです。このプロパティを使用することを強くお勧め

します。ただし、 7 シリーズおよび Zynq デバイスの場合は、 Pblock の

高さがクロック領域の境界に揃えられている必要があります。

CONTAIN_ROUTING Pblock に含まれない配線リソースが使用されないようにする Pblock プ

ロパティです。このプロパティは PR では必須で、リコンフィギャラブ

ルパーティションに対して自動的に TRUE に設定されます。スタ

ティック配線に Pblock 内のリソースを使用することは可能です。

EXCLUDE_PLACEMENT 定義された Pblock 範囲内に Pblock に含まれないロジックが配置されな

いようにする Pblock プロパティです。このプロパティは PR では必須

で、リコンフィギャラブルパーティションに対して自動的に TRUE に

設定されます。 RESET_AFTER_RECONFIG が使用されない場合は、

LOC プロパティを使用してスタティックロジックをリコンフィギャラ

ブルパーティション内に配置できます。

PARTPIN_SPREADING INT タイルごとの PartPin の大数を制御します。デフォルトは 5 です。

値を小さくすると (3 など)、パーティションピンの配置が分散されま

す。これにより PartPin が多く配置されているエリアの配線密集を緩和

できますが、 RP インターフェイスのタイミングに悪影響を与える可能

性があります。





Vivado IDE でのフロアプラン

Vivado IDE は、プランニングおよび表示タスクに使用できます。 [Device] ウィンドウを使用して、フロアプラン用に

Pblock 制約を作成および変更するのが、そのよい例です。

1. 合成済みスタティックデザインと大のリコンフィギャラブルモジュールを開きます。次に、『Vivado Design

Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 1] のチュートリアルデザインを使

用したコマンド例を示します。

open_checkpoint synth/Static/top_synth.dcpset_property HD.RECONFIGURABLE true [get_cells inst_count]read_checkpoint -cell [get_cells inst_count] synth/count_up/count_synth.dcpset_property HD.RECONFIGURABLE true [get_cells inst_shift]read_checkpoint -cell [get_cells inst_shift] synth/shift_right/shift_synth.dcp

これでフルコンフィギュレーションがメモリに読み込まれ、リコンフィギャラブルパーティションが定義され

ます。

2. リコンフィギャラブルパーティション用の Pblock 制約を作成するには、 [Netlist] ウィンドウでインスタンス (こ

の場合は inst_count または inst_shift) を右クリックし、 [Draw Pblock] をクリックします。 [Device] ウィンドウで矩

形を作成し、このリコンフィギャラブルパーティションのリソースを選択します。

3. この Pblock を選択すると、 [Properties] ウィンドウに使用可能なリソース数と必要なリソース数が表示されます。

必要な数は現在読み込まれているリコンフィギャラブルモジュールによって異なり、ほかのモジュールの要件

は異なる場合があることに注意してください。適切な形状 (L 字型など) を作成するために矩形を追加する必要

がある場合は、 [Device] ウィンドウで Pblock を右クリックし、 [Add Pblock Rectangle] をクリックします。

4. デザインルールチェック (DRC) を実行して、メモリ内のコンフィギュレーションでフロアプランおよびその他

の項目を検証します。 DRC を実行するには、 [Reports] → [Report DRC] をクリックし、 [Partial Reconfiguration] が

オンになっていることを確認します (33 ページの図 3-1)。 Pblock に HD.RECONFIGURABLE が設定されていない

場合、 1 つの DRC のみが実行可能で、次の図に示されているようにすべては表示されません。






図 3-1: Vivado IDE でのパーシャルリコンフィギュレーション DRC





これらの DRC は、 Tcl コンソールまたはスクリプトで report_drc コマンドを使用して実行します。パーシャルリ

コンフィギュレーション用のチェックのみを実行する場合は、次のコマンドを使用します。

report_drc -checks [get_drc_checks HDPR*]

デザインプロセスの特定の段階に対するチェックを実行するには、 -ruledeck オプションを使用できます。たと

えば、配置配線済みのデザインに対して次のコマンドを実行できます。

report_drc -ruledeck bitstream_checks

フロアプラン制約を保存するには、 [Tcl Console] ウィンドウに次のコマンドを入力します。

write_xdc top_fplan.xdc

この制約ファイルに保存された Pblock 制約は、直接使用するか、別の上位デザイン制約ファイルにコピーして使

用できます。この XDC ファイルには、新しく追加した制約だけでなく、メモリに読み込まれている現在のデザイン

の制約すべてが含まれます。

注意: Vivado IDE の [File] → [Checkpoint] → [Save] または同等のボタンを使用してデザイン全体を保存しないでくださ

い。読み込まれているデザインをこの方法で保存すると、合成済みスタティックデザインチェックポイントがリコ

ンフィギャラブルモジュールと追加制約を含む新しいバージョンで上書きされます。

タイミング制約

パーシャルリコンフィギュレーションデザインのタイミング制約は、従来のフラットデザインのタイミング制約と

似ています。プライマリクロックと I/O には、対応する制約を設定する必要があります。これらの制約については、

『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 17] のこのセクションおよびこのセクションを参照

してください。

デザインに正しい制約を適用したら、スタティックタイミング解析を実行してデザインのパフォーマンスを検証し

ます。この検証は、各リコンフィギャラブルモジュールに対してデザイン全体のコンテキストで実行する必要があ

ります。デザインの解析方法は、『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』

(UG906) [参照 18] を参照してください。

Vivado Design Suite には、セルレベルのタイミングレポートを実行する機能があります。特定のフィコンフィギャラ

ブルモジュールでタイミング解析を実行するには、 report_timing または report_timing_summary で -cell

オプションを使用します。これは、以前のコンフィギュレーションからインポートされ固定されているスタティッ

クデザインのコンフィギュレーションで特に便利です。

Vivado 2017.1 から、 report_timing および report_timing_summary で生成されるタイミングレポートに

[Partition] 列が追加されており、タイミングを満たしていないパスがスタティック内か RM 内か、 RP の境界をまたぐ

かを特定するのに役立ちます。これら両方のコマンドには新しい -no_pr_attribute オプションがあり、この新

しい機能をオフにできます。このオプションは、スクリプトでタイミングレポートを解析しており、この新しい列

が悪影響を及ぼす場合に便利です。


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

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




パーティションピン

リコンフィギャラブルパーティションに定義された Pblock 領域内には、パーティションピンと呼ばれるインター

フェイスポイントが自動的に作成されます。これらの仮想 I/O はインターコネクトタイル内にアンカーポイントと

して作成され、モジュール間で一定に保たれます。これらのアンカーポイントを作成するのに、 LUT やフリップフ

ロップなどの物理リソースは不要で、遅延が追加されることもありません。

ツールによりソース、ロード、およびタイミング要件に基づいて位置が選択されますが、ユーザーがこれらの位置

を指定することもできます。次の制約を適用すると、パーティションピンの配置を制御できます。

注記: 31 ページの表 3-4 の PARTPIN_SPREADING プロパティを使用してパーティションピンに影響を与えることは

できますが、これは Pblock レベルで適用されます。

パーティションピンの配置を制御するプロパティの例

• set_property HD.PARTPIN_LOCS INT_R_X4Y153 [get_ports <port_name>]

• set_property HD.PARTPIN_RANGE SLICE_X4Y153:SLICE_X5Y157 [get_ports <port_name>]

インターコネクトタイルサイトのインスタンス名は、 [Device] ウィンドウで [Routing Resources] をイネーブルにする

と表示できます。

注記: ユーザー定義値がない場合、 HD.PARTPIN_RANGE は place_design の実行中に自動的に設定されます。値

が設定されたら、インタラクティブ配置配線中 (RP Pblock の試行のための変更、 place_design -unplace の実行

など) にはリセットされません。 Pblock を変更した場合は、 HD.PARTPIN_RANGE および HD.PARTPIN_LOCS を手動

でリセットする必要があります。これらのプロパティは、ほかのほとんどのプロパティと同様にリセットできます。

表 3-5: パーティションピンの配置を制御するプロパティ

コマンド /プロパティ名説明

HD.PARTPIN_LOCS 配線される指定ポートにインターコネクトタイル (INT) を指定します。

HD.PARTPIN_RANGE よりも優先されます。このプロパティは、リコン

フィギャラブルパーティションの境界の両側にあるロジックの配置およ

び配線に影響します。

クロックポートには使用しないでください。クロックポートに使用す

ると、クロックにローカル配線が使用されます。

このプロパティを専用接続には使用しないでください。

HD.PARTPIN_RANGE 指定したポートを配線するために使用可能なコンポーネントサイト

(SLICE、 DSP、ブロック RAM) またはインターコネクトタイル (INT) の

範囲を定義します。

ユーザー定義の HD.PARTPIN_RANGE 値が存在しない場合は、 Pblock の

範囲に基づいて値が自動的に算出されます。





次の Tcl プロシージャは、 PR デザインにこのようなインタラクティブフロアプランを実行する場合に便利です。

################################################## Proc to unroute, uplace, and reset HD.PARTPIN_* #################################################proc pr_unplace route_design -unrouteplace_design -unplaceset cells [get_cells -quiet -hier -filter HD.RECONFIGURABLE]foreach cell $cells reset_property HD.PARTPIN_LOCS [get_pins $cell/*]reset_property HD.PARTPIN_RANGE [get_pins $cell/*]

配置済みまたは配線済みデザインからのパーティションピンの情報は、 get_pplocs コマンドを使用して取得でき

ます。 -nets または -pins オプションを使用すると、特定のリコンフィギャラブルパーティションまたはイン

ターフェイスピンの情報を取得できます。

get_pplocs -nets <args> -pins <args> [-count] [-unlocked] [-locked] [-level <arg>] [-quiet] [-verbose]

次にその例を示します。

get_pplocs -pins [get_pins u_count/*]

表 3-6: get_pplocs コマンドのオプション

名前説明

-nets PPLOC をレポートするネットを 1 つ以上指定します。

-pins PPLOC をレポートするピンを 1 つ以上指定します。

[-count] PPLOC の数をレポートし、 PPLOC またはノードの名前はレポートしません。

[-unlocked] 固定されていない PPLOC のみをレポートします。

[-locked] 固定されている PPLOC のみをレポートします。 -level オプションを使用し

て固定レベルを指定してください。

[-level] 固定レベルを指定します。

[-quiet] コマンドエラーを表示しません。

[-verbose] メッセージの非表示設定を解除し、すべてのメッセージを表示します。





リコンフィギュレーション後にリセットを適用

リコンフィギュレーション後にリセットを適用する機能を使用すると、パーシャルリコンフィギュレーション中に

リコンフィギュレーションされる領域が一定した状態に保持され、新しいリコンフィギャラブルモジュールのすべ

てのロジックが開始値に初期化されます。パーシャルリコンフィギュレーション中、スタティック配線は影響を受

けずにその領域を通過でき、デバイスのほかの部分にあるスタティックロジック (およびほかの PR 領域) は通常ど

おり動作し続けます。この機能を使用するパーシャルリコンフィギュレーションは、 FPGA の初期コンフィギュ

レーションと同様に動作し、同期エレメントが既知の初期ステートになります。

重要: GSR (グローバルセット / リセット ) や GWE (グローバルライトイネーブル) などのグローバル信号の解放は、

チップ全体で同期するとは限りません。モジュール内の機能が初期化された順次エレメントの開始が同期している

ことに依存している場合は、そのモジュール内のロジックを駆動するクロックまたはそれらのエレメントのクロッ

クイネーブルをリコンフィギュレーション中ディスエーブルにし、リコンフィギュレーションの完了後に再びイ

ネーブルにします。詳細は、「スタートアップ後にフリップフロップおよび SRL を正しく同期化させるためのデザイ

ンアドバイザリ」 (ザイリンクスアンサー 44174) [参照 37] を参照してください。

次に、 RESET_AFTER_RECONFIG プロパティの構文を示します。

set_property RESET_AFTER_RECONFIG true [get_pblocks <reconfig_pblock_name>]

7 シリーズの XADC コンポーネントの DRP インターフェイスがデザインで使用される場合、

RESET_AFTER_RECONFIG がイネーブルのとき、パーシャルリコンフィギュレーション中にこのインターフェイス

はブロックされます ( リセットに保持される )。インターフェイスは応答せず (ビジー状態)、このパーシャルリコン

フィギュレーション中はアクセスがない状態になります。パーシャルリコンフィギュレーションが完了すると、イ

ンターフェイスは再びアクセス可能になります。

7 シリーズおよび Zynq-7000 SoC デバイスでリコンフィギュレーション後にリセットを適用する機能を使用するに

は、 Pblock 制約がリコンフィギュレーションフレームに揃えられている必要があります。 GSR は領域内のすべての

同期エレメントに影響するので、リコンフィギャラブルフレームのみを使用する必要があります。これらのリコン

フィギャラブルフレーム内でにはスタティックロジックは配置できません (スタティック配線は可能)。 Pblock の高

さは、リコンフィギャラブルフレームの基本領域に合わせるため、クロック領域の境界に揃える必要があります。

RESET_AFTER_RECONFIG を使用する場合、 Pblock の幅に関する要件はありません。

UltraScale™ デバイスにはこのクロック領域を揃える要件はなく、 GSR の適用を詳細に制御できます。そのため、

UltraScale アーキテクチャでは RESET_AFTER_RECONFIG がすべてのリコンフィギャラブルパーティションに自動

的に適用されます。

図 3-2 では、左側の Pblock (pblock_shift) は Pblock の上辺と下辺がクロック領域 X1Y3 の高さに揃っているので、

フレームに揃っています。右側の Pblock (pblock_count) はフレームに揃っていません。

° 7 シリーズデバイス : モジュールがパーシャルリコンフィギュレーションされた後、 Pblock とその上のク

ロック領域境界の間に配置されているスタティックロジックが GSR の影響を受けるので、フレームに揃え

られていない Pblock (図の pblock_count など) には RESET_AFTER_RECONFIG を設定できません。

° UltraScale デバイス : GSR 制御が改善されているので、両方の Pblock に自動的に RESET_AFTER_RECONFIG

が使用されます。

SNAPPING_MODE 制約を使用すると、有効なリコンフィギャラブル Pblock が自動的に作成されます。詳細は、

第 6 章の「リコンフィギャラブルパーティションの自動調整」 (7 シリーズデバイス) または第 7 章の「Pblock の PU

の自動調整」 (UltraScale デバイス) を参照してください。





GSR の機能はパーシャルビットストリーム内に組み込まれているので、リコンフィギュレーション中にこの機能を

含めるための操作は必要ありません。ただし、このプロセスは SHUTDOWN シーケンス ( リコンフィギュレーションす

る領域のみにマスク ) を使用するので、リコンフィギュレーションを開始したときに外部 DONE ピンを Low にし、正

しく完了したら High にする必要があります。ボードをセットアップする際に、この動作を考慮する必要がありま

す。 STARTUP ブロックはシャットダウン中ディスエーブルになるので、このブロックの DONEO を DONE ピンのス

テートが変化しないようにするために使用することはできません。また、 RESET_AFTER_RECONFIG を使用してい

る場合、 STARTUP をパーシャルリコンフィギュレーションのコンフィギュレーションクロックを生成するなどの

ほかの目的で使用することはできません。

別のアプローチとして、このプロパティを使用せず、リコンフィギュレーションされたロジックで正しく機能させ

るために初期化が必要なものにローカルリセットを適用する方法があります。この方法では、 Pblock の高さをク

ロック領域の境界に揃える必要はありません。 GSR またはローカルリセットを使用しない場合、リコンフィギャラ

ブルモジュール内の同期エレメントが初期の開始値にならない可能性があります。


図 3-2: RESET_AFTER_RECONFIG を使用可能な Pblock (左) と使用不可能な Pblock (右)





表示スクリプトをオン

パーシャルビットストリームの一部であるコンフィギュレーションタイルを、 Vivado IDE の [Device] ウィンドウに

表示できます。

パーシャルリコンフィギュレーションの場合、すべてのパーシャルリコンフィギュレーション Pblock に対するスク

リプトが hd_visual ディレクトリ (run スクリプトを起動するとディレクトリ内に作成) に自動的に作成されます。

これらのスクリプトを使用するには、 Vivado IDE に配線済みデザインチェックポイントを読み込み、スクリプトの

いずれかを実行します。これらのデザイン特定のスクリプトでは、ユーザーが定義したコンフィギュレーションタ

イルをハイライト、パーシャル BIT ファイルを作成するのに使用されたコンフィギュレーションフレームを表示、

PR フロアプランから除外されたサイトを示します。モジュール解析や Tandem コンフィギュレーションなどのほか

のフロー用にもスクリプトが作成されますが、これらは PR では使用されません。

ツールフロー

このセクションでは基本フローを説明し、このフローを実行するためのコマンド例を示します。

合成

スタティックモジュールを含む各モジュールは、それぞれにネットリストまたはチェックポイントが作成されるよ

うに、ボトムアップ合成する必要があります。

1. 上位モジュールを合成します。

read_verilog top.v (および、リコンフィギャラブルモジュールのブラックボックスモジュールの定義な

ど、スタティックデザインに関連付けられたその他の HDL)

この後次を実行します。

read_xdc top_synth.xdcsynth_design -top top -part xc7k70tfbg676-2write_checkpoint top_synth.dcp

2. リコンフィギャラブルモジュールを合成します。

read_verilog rp1_a.vsynth_design -top rp1 -part xc7k70tfbg676-2 -mode out_of_contextwrite_checkpoint rp1_a_synth.dcp

3. 残りの各リコンフィギャラブルモジュールを合成します。

read_verilog rp1_b.vsynth_design -top rp1 -part xc7k70tfbg676-2 -mode out_of_contextwrite_checkpoint rp1_b_synth.dcp





インプリメンテーション

すべてのリコンフィギャラブルモジュールを少なくとも 1 回インプリメントするのに必要な数のコンフィギュレー

ションを作成します。初のコンフィギュレーションで、上位と初のリコンフィギャラブルモジュールの合成

結果を読み込みます。モジュールをリコンフィギャラブルとマークし、インプリメンテーションを実行します。完

全な配線済みコンフィギュレーションのチェックポイントを保存し、リコンフィギャラブルモジュールを必要に応

じて再利用できるようにリコンフィギャラブルモジュールのチェックポイントを保存します。後に、デザインか

らリコンフィギャラブルモジュールを削除し (update_design -cell -black_box)、スタティックデザインの

みのチェックポイントを保存します。

コンフィギュレーション 1:

open_checkpoint top_synth.dcpread_xdc top_impl.xdcset_property HD.RECONFIGURABLE true [get_cells rp1]read_checkpoint -cell rp1 rp1_a_synth.dcpopt_designplace_designroute_designwrite_checkpoint config1_routed.dcpwrite_checkpoint -cell rp1 rp1_a_route_design.dcpupdate_design -cell rp1 -black_boxlock_design -level routingwrite_checkpoint static_routed.dcp

2 番目のコンフィギュレーションでは、リコンフィギャラブルモジュールがブラックボックスとして含まれている

スタティック部分の配置配線済みチェックポイントを読み込みます (閉じている場合)。その後 2 番目のリコンフィ

ギャラブルモジュールの合成結果を読み込み、デザインをインプリメントします。後に、リコンフィギャラブル

モジュールの 2 番目のバージョンのインプリメンテーションチェックポイントを保存します。

コンフィギュレーション 2:

open_checkpoint static_routed.dcpread_checkpoint -cell rp1 rp1_b_synth.dcpopt_designplace_designroute_designwrite_checkpoint config2_routed.dcpwrite_checkpoint -cell rp1 rp1_b_route_design.dcp

ヒント : 各コンフィギュレーションを別のフォルダーに分け、すべての中間チェックポイント、ログおよびレポート

ファイル、 BIT ファイル、その他のデザイン出力が個別に保存されるようにします。

複数のリコンフィギャラブルパーティションがある場合は、ほかのコンフィギュレーションも必要です。追加のコ

ンフィギュレーションは、以前にインプリメント済みのリコンフィギャラブルモジュールをインポートして、ハー

ドウェアに読み込むフルデザインを作成することにより、作成することも可能です。これは、電源投入用の適切な

組み合わせのフルビットストリームを作成する場合や、スタティックタイミング解析、消費電力解析、シミュレー

ションを実行する場合に便利です。





各リコンフィギャラブルモジュールチェックポイントの完全な配置配線結果が保持されるので、新しいコンフィ

ギュレーションは、配線済みチェックポイントのコレクションを読み込むだけで簡単に作成できます。ただし、こ

のフローを使用する場合には制限もあることに注意してください。リコンフィギャラブルモジュールのインプリメ

ンテーションを保存するのに write_checkpoint -cell を使用した場合、このモジュールに対してローカルの制

約は保持されません。内部クロック制約、または RM 内で開始または終了する (または開始して終了する ) タイミン

グ例外を含むリコンフィギャラブルモジュールの場合、新しいコンフィギュレーションを作成した後、これらの制

約をタイミング解析用に適用し直す必要があります。ザイリンクス IP またはサードパーティ IP を含むリコンフィ

ギャラブルモジュールは、この制限を示す良いモジュール例です。

レポート

インプリメンテーションフローの各段階では、パーシャルリコンフィギュレーション特定のデザインルール

チェック (DRC) が実行されます。インプリメンテーションで表示されるメッセージに注意し、クリティカル警告が

発生していないかを確認します。これらのメッセージは、モジュールインターフェイス、フロアプランなど、 PR デ

ザインの重要な部分を適化するのに役立ちます。

生成されるほとんどのレポートには、 PR 特定のセクションはありませんが、有益な情報が含まれています。たとえ

ば、 report_utilization コマンドで -pblocks オプションを使用すると、リソース使用率を取得できます。こ

のコマンドを実行すると、指定したリコンフィギャラブルモジュール内で使用可能なリソース数と使用されている

リソース数が示されます。次に、『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』

(UG947) [参照 1] からのデザインを使用した例を示します。

report_utilization -pblocks [get_pblocks pblock_count]

report_clock_utilization では、パーシャルリコンフィギュレーションインプリメンテーションで反転され

るクロックが示されます。

コンフィギュレーションの検証

すべてのコンフィギュレーションを完全に配置配線したら、 pr_verify を使用して終検証チェックを実行し、コ

ンフィギュレーション間の一貫性を確認できます。このコマンドでは、複数の配線済みチェックポイント (DCP) を

引数として指定し、それらのチェックポイント間でのスタティックインプリメンテーションとパーティションピン

配置の違いをレポートできます。この比較では、 RM 内の配置配線は無視されます。

2 つのコンフィギュレーションのみを比較する場合は、 2 つの配線済みチェックリストを <file1> および <file2>

としてリストします。 pr_verify コマンドにより両方がメモリに読み込まれ、比較されます。

3 つ以上のコンフィギュレーションを比較する場合は、 -initial オプションを使用してマスターコンフィギュ

レーションを指定してから、 -additional オプションを使用して複数のコンフィギュレーションを中かっこで

囲んでリストします。マスターコンフィギュレーションがメモリに保持され、残りのコンフィギュレーションがそ

れと比較されます。 PR 検証チェックで問題が検出されたコンフィギュレーションがある場合は、どのコンフィギュ

レーションに対してもビットストリームを生成しないでください。

pr_verify [-full_check] [-file <arg>] [-initial <arg>] [-additional <arg>] [-quiet] [-verbose] [<file1>] [<file2>]





次に、 2 つのコンフィギュレーションを比較するコマンドライン例を示します。

pr_verify -full_check config1_routed.dcp config2_routed.dcp -file pr_verify_c1_c2.log

次に、 3 つのコンフィギュレーションを検証する例を示します。

pr_verify -full_check -initial config1.dcp -additional config2.dcp config3.dcp -file three_config.log

『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 1] で提供されるスクリプ

トには、 verify_configs という Tcl プロシージャが含まれており、存在するすべてのコンフィギュレーションに

対して pr_verify が実行され、 DCP が一貫しているかがレポートされます。

ビットストリーム生成

ビットストリームを生成するには、フラットフローと同様、 write_bitstream コマンドを使用します。各デザイ

ンコンフィギュレーションに対して write_bitstream を実行し、フル標準コンフィギュレーションファイルと、

そのコンフィギュレーション内の各リコンフィギャラブルモジュールに対してパーシャル BIT ファイルを 1 つずつ

作成します。

write_bitstream コマンドの -file オプションでコンフィギュレーション名とリコンフィギャラブルモジュー

ル名を指定することをお勧めします。ベース BIT ファイル名のみが変更可能なので、各コンフィギュレーションに

どのリコンフィギャラブルモジュールを選択しているかを記録しておくことが重要です。

次に、上記のデザインを使用して、配線済みチェックポイント (コンフィギュレーション) を読み込み、すべてのイ

ンプリメント済みリコンフィギャラブルモジュールのビットストリームを作成する例を示します。

open_checkpoint config1_routed.dcpwrite_bitstream config1

表 3-7: pr_verify コマンドのオプション


-full_check デフォルトでは、初の差異のみがレポートされます。このオプション

を選択すると、 pr_verify により配置または配線の差異がすべてレポー

トされます。

-file 結果を保存するファイルの名前を指定します。このオプションを使用し

ない場合、出力はコンソールに表示されます。

-initial すべてのチェックポイントの比較基準となる 1 つの配線済みデザイン

チェックポイントを指定します。

-additional -initial で指定したチェックポイントと比較する配線済みデザイン

チェックポイントを 1 つまたは複数指定します。複数のチェックポイン

トをリストする場合は、次のように中かっこで囲みます。

config2.dcp config3.dcp config4.dcp

-quiet コマンドエラーを表示しません。

-verbose メッセージの非表示設定を解除し、すべてのメッセージを表示します。





このコマンドでは、この特定のコンフィギュレーションに対して可能性のあるすべてのビットストリームが生成さ

れ、 config1.bit というフルデザインビットストリームが作成されます。電源を投入したときに、このビットス

トリームを使用してデバイスをプログラムします。このビットストリームには、リコンフィギャラブルモジュール

の機能も含まれています。このコマンドは、 FPGA の動作中にこれらのモジュールをリコンフィギュレーションする

パーシャル BIT ファイル config1_pblock_rp1_partial.bit および config1_pblock_rp2_partial.bit も

作成します。 UltraScale デバイスの場合、各パーシャルビットストリームとペアになったクリアビットストリーム

が作成されるので、次のパーシャルイメージ用のパーティションが準備できるようになります。各コンフィギュ

レーションに対してこれらの手順を繰り返します。

ヒント : 各パーシャル BIT ファイルの名前をリコンフィギャラブルモジュールインスタンスと一致するように変更

し、モジュールを識別できるようにします。現在のソリューションでは、コンフィギュレーションのベース名およ

び Pblock 名に基づいて、パーシャル BIT ファイルに <base_name>_<pblock_name>_partial.bit という名前が

付けられます。

各パーシャルビットストリームのサイズは、 write_bitstream コマンドからの出力にレポートされます。このコ

マンドを実行すると、各パーシャルビットストリームファイルおよびクリアビットストリームファイルに対して

次のメッセージがレポートされます。

Creating bitmap...Creating bitstream...Partial bitstream contains 3441952 bits.Writing bitstream ./Bitstreams/right_up_pblock_inst_shift_partial.bit...

ビットストリームの圧縮、暗号化、その他のアドバンス機能も使用できます。 UltraScale デバイスでサポートされて

いないユースケースは、 134 ページの「既知の制限」を参照してください。

パーシャルビットストリームのみの生成

完全なデザインコンフィギュレーションファイルが不要な場合は、 1 つのパーシャルビットストリームのみを作成

できます。完全なデザインコンフィギュレーションチェックポイントをメモリに読み込んでいる場合は、 -cell オ

プションを使用してパーシャルビットストリームが必要なインスタンスを指定します。このパーシャルビットスト

リームの名前は、 Pblock 名から自動的に作成されないので、指定できます。

write_bitstream -cell rp1 RM_count_down_partial.bit

これにより、指定したリコンフィギャラブルパーティションのパーシャルビットストリームのみが作成されます。

注意: リコンフィギャラブルモジュールチェックポイントに対して直接 write_bitstream コマンドを実行しない

でください。デザイン全体のチェックポイントのみを使用してください。リコンフィギャラブルモジュールチェッ

クポイントは配置配線済みのサブモジュールであり、上位デザインのインプリメンテーション情報は含まれてい

ないので、適切なパーシャル BIT ファイルが作成されません。





フルコンフィギュレーションビットストリームのみの生成

パワーオンデザインのビットストリームのみが必要な場合は、 -no_partial_bitfile オプションを使用して

パーシャルビットストリームの作成をバイパスできます。

write_bitstream -no_partial_bitfile config3

このオプションを使用すると、パーシャルビットストリームおよびクリアビットストリームを作成する段階は実行

されません。パーシャルリコンフィギュレーションなしでフルデザインのみをテストする場合やパーシャルビット

ストリームが既に存在している場合などに、 write_bitstream の実行時間を短縮できます。

スタティック部分のみのビットストリームの生成

スタティックデザインのみのパワーオンコンフィギュレーションが必要な場合は、update_design -black_box

および update_design -buffer_ports を実行後、空のリコンフィギャラブルパーティションを含むチェックポ

イントに対して write_bitstream コマンドを実行します。このグレーボックスコンフィギュレーションを圧縮

し、 BIT ファイルのサイズおよびコンフィギュレーション時間を削減できます。

Tcl スクリプト

このフローを実行するためのスクリプトは、『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレー

ション』 (UG947) [参照 1] を参照してください。これらのサンプルスクリプトの詳細は、チュートリアルおよびサン

プルデザイン ZIP ファイルに含まれている readme.txt を参照してください。




第 4 章

Vivado プロジェクトフロー

概要

ザイリンクス FPGA および SoC におけるパーシャルリコンフィギュレーション (PR) には、従来のソリューションに

はない新しいデザイン要件があります。ボトムアップ合成および複数インプリメンテーションの両方が必要になる

ため、ソースおよび run の管理に新しい要件が設けられています。これらの要件は、 Vivado PR プロジェクトフロー

で満たされます。

フローの概要

パーシャルリコンフィギュレーションのプロジェクトフローには、既存の Vivado プロジェクトソリューションに

パーシャルリコンフィギュレーションの主な要件が追加されており、 Vivado IDE と Tcl コマンドの両方からアクセ

スできます。主な要件には、次のものがあります。

• デザイン階層内でリコンフィギャラブルパーティションを定義

• 各リコンフィギャラブルパーティションにリコンフィギャラブルモジュールのセットを配置

• 上位およびモジュールレベルの合成 run のセットを作成

• 関連インプリメンテーション run のセットを作成

• ソース、制約、オプションの変更に応じて依存関係を管理

• ルールおよび結果をチェック

• コンフィギュレーションを検証

• フルビットストリームとパーシャルビットストリームの互換性のあるセットを生成

これらの基本機能がこのリリースに導入されており、 IP を含む RTL ベースデザインのインプリメンテーション全体

がサポートされています。

このフローでは、すべてのソース (少なくとも上位 RTL とサブモジュールの合成後のネットリスト ) は 1 つの PR

プロジェクト内で管理されます。プロジェクトを分割したりエクスポートしたりすることはできません。そうする

と、 Vivado で run とソースの間の関係を管理できなくなります。




第 4 章: Vivado プロジェクトフロー

Tcl コマンド

パーシャルリコンフィギュレーションの機能およびタスクは、 Vivado IDE 環境のほかの機能およびタスクと同様に、

バックグランドで Tcl コマンドを使用して実行されます。 PR プロジェクトサポートの主な目標の 1 つは、同じプロ

ジェクトで GUI、スクリプト、コマンドラインを切り替えて使用しても、スムーズに作業できるようにすることで

す。実際に実行された Tcl コマンドを確認するには、プロジェクトの Vivado ジャーナルファイルを開きます。 [File]

→ [Project] → [Open Journal File] をクリックすると、このファイルを開くことができます。これらの Tcl コマンドに関

しては、このユーザーガイドでは説明されていません。プロジェクト全体を現在の状態まで作成するために使用さ

れるコマンドのリストは、 [File] → [Project] → [Write Tcl] をクリックすると作成できます。各コマンドの詳細は、コ

マンドの -help オプションを使用してください。

パーシャルリコンフィギュレーションプロジェクトの作成および使用手順

このセクションでは、パーシャルリコンフィギュレーションデザインフローの一般的なフローと、 Vivado IDE 内で

の機能について説明します。ザイリンクス評価プラットフォームをターゲットにしたデザインを使用したチュート

リアルは、『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 1] の演習 3 を

参照してください。

パーシャルリコンフィギュレーションプロジェクトの作成

PR プロジェクト作成の初期段階は、標準デザインフローと同じです。 New Project ウィザードを使用して、ターゲッ

トデバイス、デザインソースおよび制約ファイルを選択し、プロジェクトの詳細を設定します。新規プロジェクト

を作成する際、デザインのスタティック部分のソースファイルおよび制約をすべて追加する必要があります。各リ

コンフィギャラブルパーティションの初のリコンフィギャラブルモジュールの RTL および IP デザインソースを

含めることもできますが、とりあえずブラックボックスとして残すこともできます。

注記: 初にプロジェクトを作成するときは、 1 つの RM のソースのみを追加してください。プロジェクトにさらに

RM を追加するには、 Partial Reconfiguration ウィザードを使用します。この詳細は、この章の後の方で説明します。

プロジェクトを作成したら、それをパーシャルリコンフィギュレーションプロジェクトとして定義します。これに

は、 [Tools] → [Enable Partial Reconfiguration] をクリックします。これでプロジェクトが PR デザインフロー用になり

ます。この設定は、いったん定義すると元に戻すことはできません。このオプションを選択する前に、プロジェク

トをアーカイブすることをお勧めします。このオプションが表示されない場合は、有効なパーシャルリコンフィ

ギュレーションライセンスが Vivado ツールで認識されていることを確認してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug947-vivado-partial-reconfiguration-tutorial.pdf;a=xPartialReconfigurationProjectFlow




ダイアログボックスが開き、この設定を元に戻すことができないことを示すメッセージが表示されます。 [Convert]

をクリックすると、プロジェクトに PR 用のメニューオプションおよびウィンドウが追加されます。その一部を次

に示します。

• Flow Navigator に Partial Reconfiguration ウィザードへのリンク

• [Sources] ウィンドウに [Partition Definitions] ビュー

• [Configurations] ウィンドウ

リコンフィギャラブルパーティションの定義

プロジェクトを PR プロジェクトに設定すると、 RTL ソース階層内でリコンフィギャラブルパーティションを定義

できるようになります。デザイン階層内の次のようなインスタンスが、リコンフィギャラブルパーティションに適

しています。

• RTL、 DCP、または EDIF ソースで定義されている。

• 上位の階層にパラメーターおよびジェネリックを渡さない。パラメーターおよびジェネリックをリコンフィ

ギャラブルパーティションの境界に配置することは可能ですが、パーティションを作成する前にローカルで評

価する必要があります。

• 基になる RTL にアウトオブコンテキスト (IP 以外) または EDIF モジュールが含まれていない。

• IP が上位として含まれていない。

• ブロック図 (.bd) ソースが含まれていない。

1. モジュールを右クリックして [Create Partition Definition] をクリックし、リコンフィギャラブルパーティション

を作成します。デザインソースがまだない場合は、このモジュールをブラックボックスにしておくことができ

ます。


図 4-1: パーシャルリコンフィギュレーションのイネーブル





2. この後表示されるダイアログボックスで、このパーティション定義の名前を指定します。初のリコンフィ

ギャラブルモジュール (RM) の名前も指定します。この RM は、同じ階層にある RTL またはネットリストソー

スから作成されます。フローの後の段階でさらに RM を追加および作成できます。

重要: 選択したモジュールのインスタンスはすべてリコンフィギャラブルパーティションになります。 1 つのインス

タンスをリコンフィギャラブル、もう 1 つのインスタンスをスタティックにするには、これら 2 つのインスタンス

に別の名前を付けます。


図 4-2: リコンフィギャラブルパーティションの作成


図 4-3: リコンフィギャラブルパーティションおよび初のリコンフィギャラブルモジュールの定義





3. [OK] をクリックすると、 Vivado IDE でのこのモジュールの表示は異なるものになります。 [Hierarchy] ビューで、

リコンフィギャラブルパーティションのモジュールのインスタンスに菱形マークが付き、デザインソースが

[Partition Definitions] ビューに移動されて別に管理されます。デザイン内のリコンフィギャラブルパーティショ

ンすべてに対し、この手順を繰り返します。

パーシャルリコンフィギュレーションプロジェクト構造を完成

リコンフィギャラブルパーティションを定義したら、プロジェクトの詳細を入力します。これには、各リコンフィ

ギャラブルパーティションへのリコンフィギャラブルモジュール (RM) の追加、 RM とスタティックデザインを組

み合わせたコンフィギュレーションのフルセットの定義、すべてのコンフィギュレーションをインプリメントする

ための run のセットの設定などがあります。これらの設定は、すべて Partial Reconfiguration ウィザードで実行しま

す。後で変更や追加が必要な場合は、このウィザードに戻って設定し直します。

ヒント : Partial Reconfiguration ウィザードでの変更は、 [Finish] ボタンをクリックするまで反映されません。すべて設

定し終えるまで、ウィザードの前のページに戻ったり先に進んだりすることができ、変更をキャンセルすることも

できます。

Flow navigator または [Tools] メニューから [Partial Reconfiguration Wizard] をクリックし、 Partial Reconfiguration ウィ

ザードを開きます。

Partial Reconfiguration ウィザードが開いたら、各ページで PR プロジェクトを設定していきます。


図 4-4: [Sources] ウィンドウに表示される [Partition Definitions] ビュー


図 4-5: Flow Navigator の [Partial Reconfiguration Wizard]





[Edit Reconfigurable Modules] ページ

1. [Next] をクリックすると、定義されたパーティション定義 (PD) に対して新しいリコンフィギャラブルモジュー

ルを定義するページが表示されます。 PD を作成したときに RTL/ネットリストソースを追加した場合、各 PD の

初の RM がここに含まれています。 + アイコンをクリックして新しい RM を作成し、名前を付けます。デザイ

ンに複数の PD がある場合は、正しいものを選択します。ネットリストソースが選択されている場合は、

[Sources are already synthesized] チェックボックスをオンにし、ネットリストの上位モジュールを指定します。


図 4-6: リコンフィギャラブルモジュールの新規作成





2. 各パーティション定義の既存の RM すべてに対して、この作業を繰り返します。グレーボックスモジュールの

場合は、設定は必要ありません。 RM は、鉛筆アイコンをクリックすると編集でき、赤色の - アイコンをクリッ

クすると削除できます。すべての RM を設定したら、 [Next] をクリックします。


図 4-7: リコンフィギャラブルモジュールのセットを定義





[Edit Configurations] ページ

リコンフィギャラブルモジュールのセットを定義したら、コンフィギュレーションを宣言します。各コンフィギュ

レーションは、スタティックロジックと、 RP ごとに 1 つの RM を組み合わせたもので、フルデザインイメージです。

各コンフィギュレーションは手動で作成できますが、低限のコンフィギュレーションセットを Vivado で自動的に

作成するのが簡単です。次の図に示すページの中央にある [automatically create configurations] リンクをクリックする

と、自動的に作成されます。このリンクをクリックすると、すべての RM が少なくとも 1 回含まれるよう、コン

フィギュレーションが必要な数だけ作成されます。このオプションは、コンフィギュレーションがまだ定義されて

いない場合にのみ使用できます。

あるパーティション定義にほかのパーティション定義よりも多くの RM が含まれている場合、すべての RM が前の

コンフィギュレーションで定義されている RP に対し、グレーボックス RM が自動的に使用されます。これらのデ

フォルトコンフィギュレーションは、その内容および名前を変更でき、必要に応じて追加のコンフィギュレーショ

ンを作成することもできます。

ヒント : グレーボックスモジュールは完全に空ではないので、ブラックボックスモジュールとは異なります。グ

レーボックス RM には、 RM がなくても有効なデザイン接続を完全なものにするために LUT が含まれており、動作

中に出力が未接続にならないようにします。 Vivado では、選択したモジュールに update_design

-buffer_ports を実行することにより、これらが作成されます。


図 4-8: コンフィギュレーションを作成する前の [Edit Configurations] ページ





1 つの RM が複数のコンフィギュレーションで使用されている場合、配置配線は毎回実行されるため、インプリメン

テーション結果が異なることがありますが、これは初に RM が子 run でインプリメントされている場合のみです。

親コンフィギュレーションで実行されている場合は、 RM インプリメンテーション結果は再利用されます。これによ

り、 Vivado プロジェクトで親と子の間の依存関係が管理されます。


図 4-9: コンフィギュレーションを自動生成した後の [Edit Configurations] ページ





[Edit Configuration Runs] ページ

すべてのコンフィギュレーションを定義したら、コンフィギュレーションに関連付けられているコンフィギュレー

ション run を管理します。コンフィギュレーションと同様、コンフィギュレーション run のセットも Vivado で自動的

に作成できます。リストの初のコンフィギュレーションは親コンフィギュレーションとして定義され、その他の

コンフィギュレーションはすべてその親に対する子として設定されます。

この構造は、初のコンフィギュレーションがもクリティカルで困難なものであると想定しています。この親子

関係は、 [Parent] 列の値を設定することにより変更できます。合成 run の親 (この例では synth_1) は、コンフィギュ

レーション (特にスタティック部分) が合成済みネットリストからインプリメントされることを示しており、インプ

リメンテーション run の親 (この例では impl_1) は、親のロックされたスタティックインプリメンテーション結果が

開始点として再利用されることを示しています。

PR デザインでさまざまな配置配線オプション、タイミングクロージャテクニックを試しながら、複数の独立した

親 run を試すことができます。複数の親 run を並行して実行し、親 run が完了したら子 run を実行できます。配線済

みの親 run のスタティックのみのチェックポイントなど、中間チェックポイントの作成や保存に関するすべての PR

設定が Vivado プロジェクト管理機能で処理されます。終的には、すべてのコンフィギュレーションのベースとな

るスタティックインプリメンテーション結果を確立するため、親 run を 1 つ選択しする必要があります。

重要: シリコンでの安全な動作環境を確実にするため、ロックされたスタティックイメージがすべてのコンフィギュ

レーションで一貫したものになるようにし、ビットストリーム生成で互換性のあるフルおよびパーシャルビットス

トリームが生成されるようにする必要があります。これは、 Vivado PR プロジェクトフローで関連しているコンフィ

ギュレーションの親子関係を確立させることにより管理されます。

緑色の + アイコンをクリックして、新しいコンフィギュレーション run を追加します。コンフィギュレーション run

をすべて作成したら、 [Next] をクリックします。終ページに新しいエレメントの数が表示されます。 [Finish] をク

リックすると、プロジェクトへの変更がすべて実行されます。


図 4-10: 自動生成されたコンフィギュレーション run





[Design Runs] ウィンドウに、各リコンフィギャラブルモジュールのアウトオブコンテキスト合成 run が作成され、

コンフィギュレーション run がすべて生成されます。親子関係は、インデントのレベルにより示されます。

[Configurations] ウィンドウにも、プロジェクトで使用可能な各コンフィギュレーションの構成の詳細が表示されます。


図 4-11: 合成およびインプリメンテーションのデザイン run


図 4-12: プロジェクトで使用可能なコンフィギュレーション





リコンフィギャラブルモジュールまたはコンフィギュレーションの追加および変更

Partial Reconfiguration ウィザードは、リコンフィギャラブルモジュールおよびコンフィギュレーションを変更するた

めのツールです。新しい RM の追加、 RM のソースリストの変更、新しいコンフィギュレーションまたは run の作成

および削除を実行できます。このウィザード内で作業しているとき、 [Finish] ボタンをクリックするまでは変更は保

存も反映もされないので、ページを前後に自由に移動して、必要に応じて設定を変更できます。

RTL ソース自体を変更する必要がある場合は、 [Sources] ウィンドウの [Partition Definitions] ビューから開くことがで

きます。このビューには各リコンフィギャラブルモジュールが [Hierarchy] ビューのフルデザインと同じように表示

されますが、その RM の階層とその下位階層のみが表示されます。各 RM に関連付けられているソースおよび制約

すべてが表示されます。

IP ソースの作成および追加

リコンフィギャラブルモジュールに IP を含めることができます。 IP を RM の上位とすることはできませんが、そ

の下であればどのレベルにでも含めることができます。ソースをリコンフィギャラブルモジュールに追加するとき

に、 RTL と共に .xci または .xcix ファイルを含めます。

Vivado 2017.3 から、リコンフィギャラブルモジュール内の IP をグローバルまたはアウトオブコンテキストで合成

できるようになっています。次の図に示す [Synthesis Options] のどちらのオプションも使用できます。


図 4-13: [Partition Definitions] ビューに表示されるソース






図 4-14: 出力ファイル生成時に合成オプションを [Global] に設定


図 4-15: 出力ファイル生成時に合成オプションを [Out of context per IP] に設定





IP は、 PR プロジェクト内で IP カタログから作成できます。 IP 生成フローでは IP がどの RM 用なのかを認識できな

いので、 IP を作成したらデザインのプライマリブロックセットに追加します。 IP を特定の RM に割り当てるには、

[Sources] ウィンドウで IP を右クリックして [Move to Reconfigurable Module] をクリックします。適切な RM を選択

し、 [OK] をクリックします。

もう 1 つの要件として、 IP はリコンフィギャラブルモジュールごとに固有なものである必要があります。同じ IP

ファンクションが 2 つの異なる RM に含まれる場合、 2 つのインスタンスを作成する必要があります。これには、 1

つの IP を複製して新しい同一の IP を作成するのがベストです。既存の IP を右クリックし、 [Copy IP] をクリックし

ます。コピーを作成したら、前述のようにこの IP をターゲットのリコンフィギャラブルモジュールに移動する必要

があります。

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

必要なコンフィギュレーション run をすべて定義したら、デザインを合成およびインプリメントできます。 Flow

Navigator を使用し、合成、配置配線、ビットストリーム生成を実行できます。 Flow Navigator は、標準フローの場合

と同様、アクティブ run に対して実行されますが、アクティブな親 run だけでなく子 run もすべて実行されます。

パーシャルリコンフィギュレーションデザインには、各リコンフィギャラブルパーティションに Pblock が 1 つ必要

です。 Pblock が定義されていないと、 place_design で次のようなエラーメッセージが表示されます。

ERROR: [DRC 23-20] Rule violation (HDPR-30) Missing PBLOCK On Reconfigurable Cell

この必要な Pblock が上位デザイン制約ファイルに含まれる場合は、合成からビットストリーム生成までを実行で

きます。 Pblock が含まれない場合は、上位合成の後にデザインを開いて作成するのが簡単です。ネットリストの

階層ビューでリコンフィギャラブルパーティションに対応するモジュールを右クリックし、 [Floorplanning] → [Draw

Pblock] をクリックします。


図 4-16: IP をリコンフィギャラブルモジュールに移動


図 4-17: IP のコピー





リコンフィギャラブルパーティションの Pblock を描画し終えると、そのプロパティが [Pblock Properties] ウィンドウ

の [Properties] ビューに表示されます。リコンフィギャラブルパーティション用の RESET_AFTER_RECONFIG (7 シ

リーズのみ) および SNAPPING_MODE という 2 つのオプションがあります。 [Statistics] ビューには、現在読み込まれ

ているリコンフィギャラブルパーティションに使用可能なリソースおよび使用されているリソースがレポートされ

ます。ほかの RM のニーズを考慮することも重要です。

各リコンフィギャラブルパーティションの Pblock を作成したら、各コンフィギュレーションをインプリメントでき

ます。 Flow Navigator で [Run Implementation] ボタンをクリックすると、まずアクティブな親 run に対して配置配線が

実行されます。それが完了すると、親 run のスタティックデザイン結果を使用して、すべての子 run が並行して実行

されます。

PR ソリューションの詳細は、 Vivado プロジェクトで管理されます。データベース管理は詳細の 1 つです。親 run が

完了すると、デザイン全体の配線済みデータベースと、各リコンフィギャラブルモジュールのセルレベルのチェッ

クポイントが保存されます。この後、 update_design -black_box が実行されて各 RM がブラックボックスに変

更され、すべての子 run のベースとなるスタティック部分のみのデザインチェックポイントが作成されます。子イ

ンプリメンテーション run が実行されると、スタティック部分のみの配線済み親チェックポイントと、各リコンフィ

ギャラブルモジュールの合成後チェックポイントがコンフィギュレーションに統合されます。この時点では、親 run

の配線済みモジュールチェックポイントのみが子コンフィギュレーションで再利用できます。複数の子 run で 1 つ

の RP に対して同じ RM が選択されている場合、結果は異なります。


図 4-18: Pblock のパーシャルリコンフィギュレーションプロパティ (7 シリーズ)





標準プロジェクトの場合と同様に、 Vivado で run の間の依存関係が管理されます。デザインソース、制約、オプ

ションまたは設定を変更すると、依存関係のある合成またはインプリメンテーション run が新でなくなったことが

マークされます。たとえば、ある RM の RTL デザインソースをアップデートすると、アウトオブコンテキストモ

ジュール run が新でなくなり、その RM を含むコンフィギュレーション run も新ではなくなります。また、親コ

ンフィギュレーション run のインプリメンテーションオプションを変更すると、その run とすべての子 run が新で

なくなります。

アクティブに設定できるのは親コンフィギュレーション run のみです。 Flow Navigator はアクティブ run に対して実

行されますが、 PR フローでは、すべての操作は子 run に対しても実行されます。 run の完了やエラーを示すポップ

アップメッセージは、複数の run に関連している場合がありますが、デフォルトでは親 run に対して表示されます。

プルダウンリストから、必要なインプリメンテーション run を選択してください。

各ウィンドウ (図 4-19) に表示される内容は、アクティブな親 run に関連しています。子インプリメンテーション run

の詳細を確認するには、その run を選択し、[Implementation Run Properties] ウィンドウで選択した run のすべての入力

(プロパティ、オプション) および出力 (ログ、レポート、メッセージ) を確認できます。


図 4-19: 複数のコンフィギュレーションを並行してインプリメント


図 4-20: [Implementation Completed] ダイアログボックス





ビットストリームの生成

必要なコンフィギュレーションをすべて配置配線したら、ビットストリームを生成できます。インプリメンテー

ションと同じように、 Flow Navigator の [Generate Bitstream] ボタンを使用できます。このボタンをクリックすると、

アクティブな親と子 run すべてに対して write_bitstream が実行されます。コンフィギュレーションを右クリッ

クして、 write_bitstream を実行することもできます。

各子コンフィギュレーション run に対して write_bitstream を実行する前に、pr_verify というユーティリティ

が自動的に実行されます。このユーティリティは配線済みデータベースと親データベースを比較し、すべての PR 規

則に従っていることを確認します。このチェックの結果は、 run ディレクトリに <impl_name>_pr_verify.log

という名前で保存されます。

デフォルトでは、すべての配線済みコンフィギュレーションに対して、フルデザインビットストリームとすべての

パーシャルビットストリーム (および UltraScale の場合はクリアビットストリーム) が生成されます。

write_bitstreams のオプションを使用して、特定のビットストリームのみを生成することも可能です。

[Implementation Run Properties] ウィンドウの [Options] タブで、[Write Bitstream (write_bitstream)] カテゴリにある [More

Options] フィールドに次のいずれかのオプションを入力します。

• -no_partial_bitfile: フルコンフィギュレーションファイルのみを生成し、パーシャルビットストリーム

は生成しません。

• -cell <cell>: 指定したセルのパーシャルビットストリームのみを生成します。


図 4-21: 子 run の [Implementation Run Properties] ウィンドウ





サポートされる機能とサポートされない機能

これは PR プロジェクトソリューションの初期リリースであり、すべての機能が含まれているわけではありません。

このセクションでは、 PR プロジェクトで現在サポートされている機能とサポートされていない機能を示します。

サポートされる機能

• デバイスサポート : すべての 7 シリーズ、 Zynq、 UltraScale および UltraScale+ デバイスでパーシャルリコンフィ

ギュレーションフローがサポートされています。

• インプリメンテーションツールの実行には、パーシャルリコンフィギュレーションライセンスが必要です。

• リコンフィギャラブルモジュールのソースタイプ: RTL、 DCP、 EDIF、 XDC、 XCI、 XCIX。

° XCI または XCIX (ザイリンクス IP) を上位にすることはできません。

° EDIF をサブモジュールにすることはできません。

• モジュールレベルの制約は、その階層インスタンスに適用する必要があります。

• グレーボックス (LUT 接続を含むブラックボックス) インプリメンテーションが可能です。

• プロジェクト環境から広範なデザインルールチェックを実行できます。

• すべての合成およびインプリメンテーションデザインオプションを使用できます。

• すべての子コンフィギュレーションに対して、ビットストリーム生成前に PR 検証が自動的に実行されます。

サポートされない機能

次の機能は現時点では使用できません。

• IP インテグレーターはサポートされていません。ブロック図を RM として、または RM 内に含めることはでき

ません。ブロック図内のモジュールを RM として設定することはできません。

• プロジェクト内でのシミュレーションはサポートされていません。

既知の制限

• パーティションは一度定義すると、元に戻すことはできません。 PR ではないプロジェクトに戻すには、新しい

プロジェクトを作成するのが唯一の方法です。

• 子 run からインプリメントされたリコンフィギャラブルモジュールの再利用はサポートされていません。親 run

からの RM のインプリメンテーション結果のみを子 run で再利用できます。

• 子インプリメンテーション run はアクティブに設定できません。 Flow Navigator での操作は、操作の種類によっ

て、親 run に対してのみ、または親 run とそのすべての子 run に対してのみ実行されます。




第 5 章

すべてのザイリンクスデバイスでの設計に関する考慮事項とガイドライン

概要

この章では、パーシャルリコンフィギュレーション特定のデザイン要件と、ザイリンクスデザインツールの PR 機

能について説明します。

ザイリンクス FPGA のパーシャルリコンフィギュレーション機能を使用するには、デザイン仕様を注意深く解析し、

PR デザインの要件、特性、制限を考慮する必要があります。これにより、設計およびデバッグプロセスが単純にな

り、デザインが誤動作するリスクを回避できます。

この章では、すべてのザイリンクス 7 シリーズおよび UltraScale™ デバイスに適用されるデザイン要件を示します。

個々の FPGA および SoC アーキテクチャに特定のデザイン要件は、次の章を参照してください。

• 第 6 章「7 シリーズおよび Zynq デバイスでの設計に関する考慮事項とガイドライン」

• 第 7 章「UltraScale および UltraScale+ デバイスでの設計に関する考慮事項とガイドライン」

パーシャルリコンフィギュレーション IPザイリンクスでは、パーシャルリコンフィギュレーションデザインで使用するための 4 つの IP を提供しています。

これらの IP にも PR デザインにも追加の料金はかかりません。これらの IP は、リコンフィギャラブルデザインの主

要な機能を簡単にすばやくインプリメントできるようにするために提供されています。 IP カタログの [Partial

Reconfiguration] フォルダー内にリストされており、ザイリンクスウェブサイトに製品ページと詳細な製品ガイドが

あります。

これら 4 つのパーシャルリコンフィギュレーション IP は Vivado 2018.1 に含まれており、パーシャルリコンフィ

ギュレーションをサポートするすべてのザイリンクスデバイスで使用できます。

• Partial Reconfiguration Controller: パーシャルリコンフィギュレーションデザインを制御するための管理機能

を提供します。これは、すべてのリコンフィギャラブルモジュール (RM) がコントローラーに既知である閉じ

たシステムで使用することを意図しています。オプションの AXI4-Lite レジスタインターフェイスを使用する

と、コアをランタイムでリコンフィギュレーションできるので、 RM がフィールドで変更されるシステムにも

使用できます。多数の仮想ソケット、仮想ソケットごとに多数の RM、さまざまな操作およびインターフェイ

ス用にカスタマイズできます。

• Partial Reconfiguration Decoupler: パーシャルリコンフィギュレーション中のスタティックロジックとリコン

フィギャラブルパーティションに安全で管理された境界を提供します。多数のインターフェイス、さまざまな

インターフェイス、デカップリング機能、ステータスおよび制御用にカスタマイズできます。





第 5 章: すべてのザイリンクスデバイスでの設計に関する考慮事項とガイドライン

• Partial Reconfiguration AXI Shutdown Manager: パーシャルリコンフィギュレーション中にリコンフィギャラ

ブルパーティションとスタティックロジックの間の AXI インターフェイスを安全にするため、 1 つまたは複数

使用できます。アクティブの場合、 RM に送信された AXI トランザクションおよび RM から送信された AXI ト

ランザクションは、 RM で完了できない可能性があるため、停止されます。完了できない場合、システムが

デットロック状態になる可能性があります。アクティブでない場合は、トランザクションは変更されずに渡さ

れます。

• Partial Reconfiguration Bitstream Monitor: デザインフローの実行中にパーシャルビットストリームを特定しま

す。この情報は、デバッグまたはブロッキングビットストリームロードなどのシステムアプリケーションに使

用できます。パーシャルビットストリームの主要な場所に埋め込まれている識別子がこのコアにより抽出され、

レポートされます。この情報は、どのパーシャルビットストリームがフェッチされたか、その全体がフェッチ

されたか、データパスのどこまで到達したかを判断するために、 ILA コアを使用して Vivado ハードウェアデ

バッガーに渡すことができます。

デザイン階層

適切な階層デザインを作成しておくと、パーシャルリコンフィギュレーション可能な FPGA デザインをインプリメ

ントするときに複雑になったり、困難になったりするのを回避できます。デザインインスタンス階層を明確に定義

しておくと、物理制約およびタイミング制約をシンプルにすることができ、スタティックロジックとリコンフィ

ギャラブルロジックの境界の信号にレジスタを付けると、タイミングクロージャを達成しやすくなります。同じ階

層レベルに配置するロジックをグループ化することも必要です。

これらはよく知られている設計プラクティスですが、一般的な FPGA デザインでは、これらのガイドラインに従っ

ていないことがあります。パーシャルリコンフィギュレーションデザインでは、こうしたデザイン規則に厳密に従

う必要はありませんが、従わないと悪影響が出る可能性があります。パーシャルリコンフィギュレーションの利点

は大きいですが、デザインがより複雑になるので、特にハードウェアでのデバッグが困難になることがあります。

デザイン階層の詳細は、付録 A 「階層デザインフロー」を参照してください。

DRP を使用したダイナミックリコンフィギュレーション

スタティック領域にあり、パーシャルリコンフィギュレーションされないロジックも、ダイナミックリコンフィ

ギュレーションポート (DRP) を使用して動的にリコンフィギュレーションできます。 DRP は、 MMCM、 PLL、シリ

アルトランシーバー (MGT) などのロジックエレメントをコンフィギュレーションするのに使用できます。

特定のデザインリソースに対する DRP の使用方法を含む DRP およびダイナミックリコンフィギュレーションの詳

細は、次の資料を参照してください。

• 『7 シリーズ FPGA コンフィギュレーションユーザーガイド』 (UG470) [参照 7]

• 『7 シリーズ FPGA GTX/GTH トランシーバーユーザーガイド』 (UG476) [参照 19]

• 『7 シリーズ FPGA GTP トランシーバーユーザーガイド』 (UG482) [参照 20]

• 『MMCM および PLL のダイナミックリコンフィギュレーション』 (XAPP888) [参照 21]

• 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 8]

• 『UltraScale アーキテクチャクロッキングリソースユーザーガイド』 (UG572) [参照 22]

• 『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576) [参照 23]

• 『UltraScale アーキテクチャ GTY トランシーバーユーザーガイド』 (UG578) [参照 24]





ロジックのパック

同じ階層レベルにパックする必要のあるロジックは、それがスタティックであるかリコンフィギャラブルであるかに

かかわらず、同じグループに配置する必要があります。たとえば、 LUT とフリップフロップを同じスライスに配置す

るには、同じパーティションに含める必要があります。パーティションの境界を越える適化は実行されません。

I/O、クロック、および GT リソースを含むリコンフィギャラブルパーティションでは、ツールで自動的に推論され

る I/O バッファーをその RP レベル内にインスタンシエートすることが必要な場合があります。たとえば、

GT_COMMON が RP に含まれている場合、 IBUFDS_GTE をインスタンシエートする必要があります。関連付けられて

いる I/O バッファーが上位/スタティック部分にある場合は、パックすることはできません。

デザインインスタンスの階層

リコンフィギャラブルパーティションを上位にインスタンシエートするのがも簡単な方法ですが、必ずそうし

なければならないわけではなく、リコンフィギャラブルパーティションはどの階層レベルにも配置できます。各リ

コンフィギャラブルパーティションは 1 つのインスタンスに対応している必要があります。 1 つの RP に複数の上

位を指定することはできません。インスタンシエーションには、関連モジュールが複数含まれます。

デザイン階層を変更して、複数のモジュールおよび下位セルを RP 階層レベルに統合したり、 RP 階層レベルから

分離できます。これを実行するのには、いくつかの理由があります。

• PR 領域とスタティック領域間のデバイスリソースのバランスを取り、デザインをより効率的なものにするた

め。たとえば、ターゲット RP がデバイスのほとんどの部分を占めており、スタティック領域にブロック RAM

を多数必要とするモジュールがあり、スタティック領域に十分な数のブロック RAM がない場合、このモジュー

ルを PR 領域に移動できます。

• セルをデバイスの同じ物理エリアに配置する必要があるが、これらのセルが異なるデザイン階層に含まれる場

合。たとえば、 GT_CHANNELS を同じ UltraScale クロック領域に配置する必要があるが、デザインにはスタ

ティック領域と RP 領域の両方に GT がある場合です。

• IBUFDS_GT から GT_COMMON など、専用の接続を同じ領域に配置するため。

リコンフィギャラブルパーティションのインターフェイス

パーシャルリコンフィギュレーション可能なデザインの基本要件の 1 つに、リコンフィギャラブルモジュール (RM)

間の一貫性があります。 1 つのモジュールを別のモジュールに置き換えるので、スタティックデザインとリコン

フィギャラブルモジュールの間の接続が、論理的および物理的に同一である必要があります。この一貫性を得るた

め、パーティション境界を越える適化および境界そのものの適化は実行できません。

推奨: RM ポートに接続されているインターフェイスロジックをすべての RM で一貫したものにしてください。初期

デザインのロジックレベル数が 1 で次の RM のロジックレベル数が 5 など、 RM 間でロジックレベル数を変更しな

いでください。また、初期 RM でフリップフロップを使用し、次の RM でブロック RAM を使用するなど、ドライ

バータイプを変更しないでください。初期コンフィギュレーション後スタティック部分のインターフェイスは固定

されるので、ツールは後のコンフィギュレーションでのこのような変更に対応することはできません。 RM のすべて

の入力および出力にレジスタを付けることをお勧めします。





効率をできる限り高めるため、リコンフィギャラブルパーティションのすべてのポートがスタティックデザイン側

でアクティブに使用されるようにします。たとえば、リコンフィギャラブルパーティションのスタティックドライ

バーが定数 (0 または 1) で駆動される場合、 LUT インスタンスを作成し、ローカルで定数ドライバーに接続してイン

プリメントし、適化で削除されないようにします。同様に、未接続の出力がリコンフィギャラブルパーティショ

ンの出力にあると、デザイン全体に無駄が出ます。これらの方法はインプリメンテーションツールで適用されるよ

うにし、デザインアセンブリの段階ですべてのリコンフィギャラブルモジュールが同じポートを持つようにする必

要があります。

推奨: 合成後にすべてのリコンフィギャラブルパーティションのインターフェイスを確認し、定数ポートまたは未接

続のポートの数をできるだけ少なくしてください。無駄なロジックをなくすことにより、リソース使用率が下がり、

配線密集やタイミングクロージャの問題に対処しやすくなります。

パーティションインターフェイスを使用する場合、次の 6 つの状況が考えられます。

1. スタティック側とリコンフィギャラブルモジュール側の両方がアクティブロジック (パーティションの入力ま

たは出力)

これが適な状況です。パーティションピンが挿入されます。

推奨: パーティション入力が VCC または GND で駆動される場合は、これらの制約をリコンフィギャラブルモジュー

ルに設定してください。これにより LUT の使用数が削減され、インプリメンテーションツールによりこれらの定数

を RM ロジックと共に適化できるようになります。

2. スタティック側にはアクティブドライバーがあるが、リコンフィギャラブルモジュールにはアクティブロード

がない (パーティションの入力)

すべてのリコンフィギャラブルモジュールの I/O 要件が同じであるとは限らないので、この状況が認められま

す。パーティションピンが挿入され、未使用の入力ポートは未接続のままになります。

たとえば、 1 つのモジュールで CLK_A が必要で、 2 番目のモジュールで CLK_B が必要な場合、クロックスパイ

ンはリコンフィギャラブルパーティションのクロック領域にあらかじめ配線されますが、モジュールは必要な

クロックソースのみを使用します。ただし、パーティション入力がリコンフィギャラブルモジュールで使用さ

れない場合は、パーティションインスタンシエーションから削除する必要があります。

3. スタティック側にはアクティブロードがあるが、リコンフィギャラブルモジュールにはアクティブドライバー

がない (パーティションの出力)

これは先ほどの状況と似ており、認められます。パーティションピンが挿入され、リコンフィギャラブルモ

ジュール内でグランド (論理 0) により駆動されます。

4. スタティック側にはアクティブドライバーがないが、リコンフィギャラブルモジュールにはアクティブロード

がある (パーティションの入力)

この状況ではエラーが発生するので、パーティションインターフェイスを変更して解決する必要があります。

次に、表示されるエラーメッセージの例を示します。

ERROR: [Opt 31-65] LUT input is undriven either due to a missing connection from a design error, or a connection removed during opt_design.

このエラーメッセージの後に、リコンフィギャラブルモジュール内の LUT インスタンスが続きます。





5. リコンフィギャラブルモジュールにはアクティブドライバーがあるが、スタティック側にはアクティブロード

がない (パーティションの出力)

この状況ではエラーは発生しませんが、リコンフィギャラブルモジュールロジックが残るので、適ではあり

ません。パーティションピンは挿入されません。これらのパーティション出力は削除する必要があります。

6. スタティック側とリコンフィギャラブルモジュール側のどちらにもパーティションポート用のドライバーまた

はロードがない (パーティションの入力または出力)

何も挿入されず、使用されないので、インプリメンテーションが非効率になることはありませんが、インスタ

ンシエーションポートリストの面では不要です。

パーティションピンの配置

RP の各ピンにはパーティションピン (PartPin) があります。デフォルトでは、これらの PartPin はツールにより自動

的に RP Pblock 範囲内に配置されます (必須)。多くの場合、この自動配置で十分ですが、タイミングクリティカルな

インターフェイス信号や密集度の高いデザインでは、 PartPin の配置を制御する必要がある場合があります。次に、

これを実行する例を示します。

• ピンの一部またはすべての HD.PARTPIN_RANGE 制約を定義します。

set_property HD.PARTPIN_RANGE SLICE_Xx0Yx0:SLICE_Xx1Yy1 SLICE_XxNYyN:SLICE_XxMYyM [get_pins <rp_cell_name>/*]

デフォルトでは、 HD.PARTPIN_RANGE は Pblock 範囲全体に設定されます。ユーザー範囲を定義することによ

り、 PartPin が指定のエリアに配置され、タイミングを向上したり、密集を緩和したりできます。

重要: PartPin の配置を調べる際は、境界沿い、特に Pblock の角では、配線リソースに制限があるので注意してくだ

さい。 PartPin の配置では、パーティションピンが分散され、境界沿いではインターコネクトごとのパーティション

ピンの数が小限になり、 Pblock の中央に向かって PartPin の密集度が増加するよう配置されます。カスタム

HD.PARTPIN_RANGE 制約を定義する際は、分散させるのに十分な範囲を指定してください。そうしないと、 PartPin

の周辺で配線が密集します。





アクティブ Low のリセットとクロックイネーブル

ザイリンクス 7 シリーズ FPGA には、制御信号 ( リセットまたはクロックイネーブル) にローカルインバーターはあ

りません。次はリセットを例とした説明ですが、同じ説明はクロックイネーブルにも適用されます。

デザインがアクティブ Low リセットを使用する場合、 LUT を使用して信号を反転する必要があります。すべてのリ

セットがアクティブ Low の PR 以外のデザインでは、複数の LUT が推論されますが、1 つの LUT に組み合わせて I/O

エレメントに挿入できます (LUT はなくなる )。アクティブ High とアクティブ Low のリセットが使用される PR 以外

のデザインでは、 LUT インバーターを 1 つの LUT に組み合わせることができ、その LUT がデザインに残りますが、

リセットネットの配線およびタイミングにはほとんど影響ありません (LUT の出力はグローバルリソースに配置さ

れる )。パーティションにアクティブ Low リセットが使用されるデザインでは、パーティション内でインバーターを

推論させることが可能ですが、取り出して組み合わせることはできません。そのため、リセットをグローバルリ

ソースに配置できなくなり、リセットのタイミングも悪くなり、デザインの配線が既に密集している場合は配線の

問題が発生する可能性があります。

この状況を回避するには、アクティブ Low の制御信号を使用しないようにします。ただし、 AXI インターフェイス

を含む IP コアを使用する場合など、これが不可能な場合もあります。その場合、アクティブ Low のリセットを上

位の信号に割り当て、その信号をデザイン全体で使用します。

次に例を示します。

reset_n <= !reset;

すべてに reset_n 信号を使用し、 !reset を信号またはポートに割り当てないでください。

これにより、デザイン全体のリセットネットにのみ LUT が推論され、デザインパフォーマンスへの影響が小限に

抑えられます。





デカップリング機能

リコンフィギャラブルロジックはデバイスが動作中に変更されるので、パーシャルリコンフィギュレーション中

は、リコンフィギャラブルモジュールの出力に接続されているスタティックロジックでリコンフィギャラブルモ

ジュールからのデータを無視する必要があります。パーシャルリコンフィギュレーションが完了し、リコンフィ

ギュレーションされたロジックがリセットされるまで、リコンフィギャラブルモジュールは有効なデータを出力し

ません。リコンフィギャラブルモジュールの機能を予測またはシミュレーションする方法はありません。

デカップリングストラテジの解決方法を決めておく必要があります。この問題を回避するも一般的な方法は、リ

コンフィギャラブルモジュールからのすべての出力信号 (インターフェイスのスタティック側) にレジスタを付ける

ことです。リコンフィギュレーションが完了するまでロジックを分離するには、イネーブル信号を使用できます。

ほかに、各出力ポートに単純な 2:1 マルチプレクサーを付ける方法、高度なバスコントローラーファンクションを

使用する方法などがあります。

スタティックデザインには、データおよびインターフェイスの管理に必要なロジックを含める必要があります。ハ

ンドシェークやインターフェイスのディスエーブル (バス構造で無効なトランザクションを回避するために必要な場

合あり ) などのメカニズムを利用できます。また、 PR モジュールのダウンタイムパフォーマンスの影響 ( リコンフィ

ギュレーション中またはリコンフィギュレーション後に PR モジュールに含まれる共有リソースが使用できない) を

考慮するのも良いでしょう。

Partial Reconfiguration Decoupler IP を使用すると、 MUX を挿入して AXI4-Lite、 AXI4-Stream、およびカスタムイン

ターフェイスを効率よく分離できます。 Partial Reconfiguration Decoupler IP の詳細は、ザイリンクスウェブサイトを

参照してください。






ブラックボックス

RP は擬似ブラックボックスとしてインプリメントできます。この擬似ブラックボックスは、 Vivado ではグレー

ボックスと呼ばれます。これには、 RP をスタティックデザインでブラックボックスとする必要があります (ボトム

アップ合成結果または update_design -black_box の実行から )。ブラックボックス RP セルに対して

update_design -buffer_ports コマンドを使用して、ブラックボックスのすべての入力および出力に LUT1

バッファーを配置できます。

update_design -cell <rp_cellName> -buffer_ports

これで、このデザインをインプリメントして LUT1 バッファー (および既に配置配線されていない場合はスタティッ

クロジック ) を配置配線できます。

挿入されたすべての LUT1 出力バッファーは、 0 (グランド ) に接続されます。 RP 出力で 1 (VCC) に駆動する必要があ

る場合は、 HD.PARTPIN_TIEOFF という RP ピンプロパティで制御できます。このプロパティは

write_bitstream の前までのすべての段階で設定でき、指定のポートに接続されている LUT1 バッファーの LUT

論理式を制御します。デフォルト値は 0 で、 LUT がルートスルー (出力 0) としてコンフィギュレーションされます。

このプロパティを 1 に設定すると、 LUT はインバーター (出力 1) としてコンフィギュレーションされます。デザイ

ンによっては、出力値の変更が必要な場合があります。

set_property HD.PARTPIN_TIEOFF 1 [get_pins <RP_cellName>/<output_pinName>]

グレーボックスにはユーザーロジックは含まれず、ツールで挿入された LUT1 バッファーのみが含まれます。グ

レーボックスビットストリームにはこれらの LUT の情報と、 RP フレーム内のリソースを使用するスタティックロ

ジック /配線の情報が含まれます。その領域を通過するスタティック配線 (パーティションピンノードまでのイン

ターフェイスネットを含む) は、この領域に存在します。これらの信号のプログラム情報は、ブラックボックスの

プログラムビットストリームに含まれます。

グレーボックスを使用するのは、フルコンフィギュレーション BIT ファイルのサイズ削減およびコンフィギュレー

ション時間の短縮に効果的な方法です。圧縮オプションをオンすると、 BIT ファイルのサイズも削減できる可能性

があります。このオプションでは、コンフィギュレーションフレーム構造の繰り返しを検索し、 BIT ファイルに保

存する必要のあるコンフィギュレーションデータの量を削減します。圧縮により、コンフィギュレーション時間お

よびリコンフィギュレーション時間が短縮されます。圧縮オプションを配線済み PR デザインに適用すると、フル

BIT ファイルおよびパーシャル BIT ファイルすべてが圧縮 BIT ファイルとして作成されます。圧縮をオンにするに

は、 write_bitstream を実行する前に次のプロパティを設定します。

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]





インプリメンテーションでの効果的な方法

FPGA デザインの適化には、常にトレードオフがあります。パーシャルリコンフィギュレーションも例外ではあ

りません。パーティションを越える適化は実行されず、リコンフィギャラブルフレームには特定のレイアウト制

約が必要です。これらは、リコンフィギュレーションデザインを構築する際の追加のコストです。タイミングおよ

びエリアの追加のオーバーヘッドは、デザインによって異なります。影響を小限に抑えるには、このガイドに示

されているデザインガイドラインに従います。

リコンフィギャラブルデザインのコンフィギュレーションを構築する際、初にも困難なコンフィギュレーショ

ンをインプリメントするようにします。選択した物理領域に、各リコンフィギャラブルパーティションの各リコン

フィギャラブルモジュール用に十分なリソース (特にブロック RAM、 DSP48 など) があることを確認し、各 RP でタ

イミングまたはエリアに関しても困難な RM を選択します。その後のコンフィギュレーションの RM がすべて

初の RM より小型または低速であれば、要件を満たすのが楽になります。タイミングは、すべてのリコンフィギャ

ラブルモジュールの要件が満たされるように設定する必要があります。

どのリコンフィギャラブルモジュールがも困難かが判断しにくい場合は、各モジュールをスタティックと共にイ

ンプリメントし、それぞれに対してスタティックを配置配線します。リソース使用率統計およびタイミングレポー

トを確認し、どのコンフィギュレーションがデザイン要件をも簡単に満たしているか、許容誤差がも厳しいの

はどれか、も大きいマージンでタイミングを満たしていないのはどれかを調べます。

重要: 要件との差がも大きいコンフィギュレーションに集中し、要件が満たされるまでデザインソース、制約、お

よびストラテジを反復実行します。ある時点で、 1 つのコンフィギュレーションをスタティックデザインに使用す

る結果と決定する必要があります。スタティックロジックのそのインプリメンテーションをほかのコンフィギュ

レーションすべてで使用します。

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

パーシャルリコンフィギュレーションのインプリメンテーションでは、基本的な規則に従う必要があります。これ

らの規則は、パーシャルビットストリームを正しく作成し、アクティブデバイスに安全に読み込むことができるよ

うにするためのものです。これらの規則では、次を前提としています。

• リコンフィギャラブルパーティションの論理および物理インターフェイスは、各リコンフィギャラブルモ

ジュールをインプリメントしたときに一貫している必要があります。

• リコンフィギャラブルモジュールのロジックおよび配線は、物理領域内に完全に含まれている必要があり、こ

れがパーシャルビットストリームに変換されます。

• 専用初期化機能を使用する場合は、スタティックデザインのロジックはリコンフィギャラブル領域に含めない

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





これらの要件には、適化、配置、および配線において特定のインプリメンテーション規則が必要になります。こ

れらの規則を適用することにより、タイミングクロージャを含むデザイン要件を満たすのが困難になる場合があり

ます。これらの要件を 1 つずつ設定し、各ステップで結果を解析するようにしてください。も困難なコンフィ

ギュレーションとタイミング制約のフルセットから始め、デザインのインプリメンテーションを配置配線まで実行

して結果を解析し、次のステップに進むための十分なタイミングスラックとリソースがあることを確認します。

1. デザインを Pblock なしでインプリメントします。ボトムアップ合成を使用して、境界にレジスタを付ける、

ベースライン結果を達成するなど、通常の階層デザインの推奨事項に従います。

2. 後でリコンフィギャラブルとして指定するデザインパーティションに Pblock を追加します。このフロアプラン

は、手順 1 のボトムアップ合成の結果に基づいて指定できます。リコンフィギャラブルモジュールからのロ

ジックは Pblock に配置する必要がありますが、スタティックロジックも Pbock に配置できます。

これらの Pblock を作成する際、 PR 特定のデザインルールチェックを実行するため、 HD.RECONFIGURABLE プ

ロパティ (およびオプションで RESET_AFTER_RECONFIG プロパティ ) を一時的に追加できます。これにより、

作成したフロアプランが PR のサイズおよびアライメント要件を満たしているかを確認できます。

3. フロアプランを作成したら、 Pblock に EXCLUDE_PLACEMENT プロパティを追加してスタティックデザインリ

ソースの配置をリコンフィギャラブルリソースから分離します。これにより、スタティックロジックが確実に

Pblock 外に配置されます。

4. Pblock に CONTAIN_ROUTING プロパティを適用して、リコンフィギャラブルモジュールの配線が Pblock 内に制

限されるようにします。このステップと前のステップのプロパティを設定したら、残りの規則は境界の適化

と PR 特定のデザインルールチェックに関連するもののみです。

5. 後に、リコンフィギャラブルパーティション Pblock に HD.RECONFIGURABLE を設定してリコンフィギャラ

ブルに指定します。 EXCLUDE_PLACEMENT および CONTAIN_ROUTING プロパティは重複となるので、削除でき

ます。

これらのいずれかのステップでデザイン要件が満たされない場合は、新たに適用したインプリメンテーション条件

でデザイン構造と制約を見直す必要があります。





コンフィギュレーション解析レポート

パーシャルリコンフィギュレーションデザインフローでは、配置配線でインプリメントする必要のあるデザイン

バージョンが複数使用されます。これらの異なるコンフィギュレーションでは共通のスタティックデザイン結果が

使用されますが、各リコンフィギャラブルパーティション内のモジュールは異なります。動的に置き換えられるこ

れらの異なるモジュールを考慮して、タイミング制約およびフロアプランを設定する必要があります。

PR コンフィギュレーション解析レポートは、選択した各リコンフィギャラブルモジュールを比較し、 PR デザイン

に関する情報を提供します。リソース使用量、フロアプラン、クロッキング、タイミングメトリクスが解析される

ので、 PR デザイン全体を管理するのに役立ちます。

PR コンフィギュレーション解析レポートは、現在のところ [Tcl Console] ウィンドウまたは Tcl スクリプトで実行可

能です。このコマンドを実行するには、上位デザインを開いておく必要があります。

report_pr_configuration_analysis -cells <RP_name> -dcps <list_of_RM_checkpoints>

1 つのセル (RP) と、そのセルに挿入可能な複数の DCP (それぞれが 1 つの RM を表す) を選択してその RP の包括的な

解析を実行するか、後続の DCP がない複数のセルを選択してスタティックデザインと各 RP へのインターフェイス

の上位解析を実行します。

デフォルトでは、 PR デザインに対して 3 つの解析が実行されます。これらのオプションを 1 つまたは複数選択し、

実行する解析を指定できます。

• -complexity オプション: RP に必要な各リソースタイプの大数など、リソース使用量をレポートします。

• -clocking オプション: 各 RP のクロック使用率およびロードに関する情報をレポートします。デザインの全

体的なに必要なクロック分配をプランニングするのに役立ちます。

• -timing オプション: 境界インターフェイスのタイミングの詳細をレポートします。 RM の入出力でのボトル

ネックを解析するのに役立ちます。

さらに、 -rent オプションを使用すると、複雑性レポートに Rent メトリクスが追加されます。 Rent 指数は配線の複

雑性を示すもので、どれだけ密集があるかを示す指標として使用できます。 Rent 指数の詳細は、『Vivado Design Suite

ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906) [参照 18] のこのセクションを参照してくださ

い。このオプションを指定すると、大型デザインで実行時間が長くなることがあります。

この解析を実行すると、各 RM が指定したチェックポイントの情報に基づいて解析されます。合成後のチェックポ

イントを指定することもできますが、 RM にアウトオブコンテキストで合成された IP が含まれている場合や、デ

バッグコアが挿入されている場合、チェックポイントにそれらの情報は含まれません。も完全な情報は、リンク

および拡張がすべて終了した opt_design の後にならないと入手できません。 opt_design の後に各コンフィギュ

レーションに対して write_checkpoint -cell を実行して RM チェックポイントを完全に統合してから、これら

のファイルを使用してコンフィギュレーション解析レポートを実行することをお勧めします。

次に、 3 つのリコンフィギャラブルモジュールがあるリコンフィギャラブルパーティションを 1 つ含むデザインの

レポートからの例を示します。


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug906-vivado-design-analysis.pdf;a=xComplexityReport




複雑性

次に、 -complexity オプションでレポートされるリソース使用率の表を示します。

+------------------------+---------+------------+------------+------------+------------+------------+| Categories |Grid Type| Current | RM1 | RM2 | RM3 | Max |+------------------------+---------+------------+------------+------------+------------+------------+|Slice Logic | | | | | | || Slice LUTs | SLICE | 936(23.40%)| 936(23.40%)| 927(23.17%)|1091(27.28%)|1091(27.28%)|| LUT as Logic | SLICE | 836(20.90%)| 836(20.90%)| 827(20.67%)| 977(24.43%)| 977(24.43%)|| LUT as Memory | SLICE | 100(5.00%)| 100(5.00%)| 100(5.00%)| 114(5.70%)| 114(5.70%)|| LUT as Distributed RAM| SLICE | 32(1.60%)| 32(1.60%)| 32(1.60%)| 42(2.10%)| 42(2.10%)|| LUT as Shift Register | SLICE | 68(3.40%)| 68(3.40%)| 68(3.40%)| 72(3.60%)| 72(3.60%)|| Slice Registers | SLICE |1775(22.19%)|1775(22.19%)|1613(20.16%)|1654(20.68%)|1775(22.19%)|| Register as Flip Flop | SLICE |1775(22.19%)|1775(22.19%)|1613(20.16%)|1654(20.68%)|1775(22.19%)|| CARRY8 | SLICE | 14(2.80%)| 14(2.80%)| 16(3.20%)| 16(3.20%)| 16(3.20%)|| F7 Muxes | SLICE | 6(0.30%)| 6(0.30%)| 6(0.30%)| 6(0.30%)| 6(0.30%)|| Unique Control Sets | SLICE | 105(21.00%)| 105(21.00%)| 100(20.00%)| 102(20.40%)| 105(21.00%)||Memory | | | | | | || RAMB18 | RAMB18 | 1(5.00%)| 1(5.00%)| 3(15.00%)| 2(10.00%)| 3(15.00%)|| PPLOCs (INT Tile Ratio)| - | 28(0.09)| 28(0.09)| 28(0.09)| 28(0.09)| 28(0.09)|+------------------------+---------+------------+------------+------------+------------+------------+

スライスレジスタリソースは RM1、ブロック RAM は RM2、スライス LUT は RM3 でも多く使用されているのが

わかります。各リソースタイプの大値は、 [Max] 列に示されます。この列のデータを Pblock リソースサイズのプ

ランニングに使用します。追加のオーバーヘッドを含めることをお勧めします。リコンフィギャラブルパーティ

ションの集積度は、完成したデザインと同様です。

クロッキング

-clocking オプションを使用すると、デザインで使用されるすべてのクロックのサマリと、各リコンフィギャラブ

ルモジュールのクロックロードごとの情報が示されます。各クロック領域の RM クロックロード数もレポートされ

ます。

Static Clock Summary+------------------------------------------------------------------------+------------+-------------+| Clock Name |Static Loads|RP1 Max Loads|+------------------------------------------------------------------------+------------+-------------+|mb_prc_wrapper/mb_prc_i/ddr4/inst/u_ddr4_infrastructure/dbg_clk | 2889 | 0 ||mb_prc_wrapper/mb_prc_i/ddr4/inst/u_ddr4_infrastructure/CLK | 1639 | 0 ||dbg_hub/inst/BSCANID.u_xsdbm_id/itck_i | 496 | 365 ||mb_prc_wrapper/mb_prc_i/ddr4/inst/u_ddr4_infrastructure/addn_clkout1 | 8534 | 1403 ||mb_prc_wrapper/mb_prc_i/ddr4/inst/u_ddr4_infrastructure/c0_ddr4_ui_clk | 15098 | 0 ||mb_prc_wrapper/mb_prc_i/ddr4/inst/u_ddr4_infrastructure/addn_ui_clkout2 | 11791 | 0 |+------------------------------------------------------------------------+------------+-------------+Reconfigurable Module Clocking RP1+---------------------------------------------------+-------+---------+---------+---------+---------+| Clock Name |Current|RM1 Loads|RM2 Loads|RM3 Loads|Max Loads|+---------------------------------------------------+-------+---------+---------+---------+---------+|Static Clocks | | | | | || dbg_hub/inst/BSCANID.u_xsdbm_id/itck_i | 365 | 365 | 360 | 350 | 365 || mb_prc_wrapper/mb_prc_i/ddr4/inst/ | | | | | || u_ddr4_infrastructure/addn_clkout1 | 1403 | 1403 | 1385 | 1344 | 1403 |+---------------------------------------------------+-------+---------+---------+---------+---------+





タイミング

-timing オプションは、 RP 境界のワーストインターフェイスパスのロジックレベル数をレポートします。デフォ

ルトでは 10 個のワーストパスが解析されますが、この数は -nworst オプションを使用して変更できます。 [Logic

Path] フィールドに、ロジックレベル数と、各レベルがスタティック領域 (S) にあるかリコンフィギャラブルパー

ティション (RM) にあるかが示されます。次に、 1 つの境界パスの例を示します。

Reconfigurable Module Boundary Timing RP1+-----------------------+---------------------------------------------------------------------------+| Characteristics | Paths |+-----------------------+---------------------------------------------------------------------------+| Path #1 | ------- || RP Boundary Pin | S_BSCAN_shift || RM With Worst Path | RP1 1st Configuration || Static Logic Levels | 3 || RM Logic Levels | 2 || Logic Path | FDRE(S) LUT3(S) LUT6(S) LUT3(S) LUT4(RM) LUT6(RM) FDRE(RM) || Start Point Clock | itck_i || End Point Clock | itck_i || High Fanout | 45 || Boundary Fanout | 1 |+-----------------------+---------------------------------------------------------------------------+

この情報は、境界パスを適化するのに役立ちます。パイプラインレジスタを挿入すると、これらのタイミング問題

を分割し、リコンフィギャラブルロジックとスタティックロジックの間にデカップリングポイントを作成できます。

まとめ

report_pr_configuration_analysis コマンドを、各リコンフィギャラブルモジュールのロジックを確立した

後、デザインのフロアプランを確定する前の、デザインフロー早期に実行してください。このレポートを使用する

と、デザインのリコンフィギャラブルパーティションの各 Pblock を適化するのに役立ち、デザイン全体のクロッ

ク使用率に関するガイダンスが与えられ、プロジェクト全体の各コンフィギュレーションのタイミングクロージャ

を達成するために有益な情報を得ることができます。

PR デザインの制約の管理

パーシャルリコンフィギュレーションでもその他のデザインと同様の制約が必要ですが、さらに追加の物理制約

(Pblock) が必要であり、 RM のセットで定義されるさまざまなコンフィギュレーションを定義する制約が必要な場合

があります。制約は、グローバルにまたは特定の範囲内に定義します。

• グローバル: デザイン全体に適用する制約で、すべてのオブジェクト参照 (セル/ピン/ネット /ポート ) はデザイン

階層全体に対するものになります。

• 範囲内: 上位モジュール以外のモジュールに対して記述された制約で、そのモジュールの 1 つまたはすべての

インスタンスに適用されます。この後のパーシャルリコンフィギュレーションに関する内容では、範囲内の制

約はリコンフィギャラブルモジュールの 1 つまたは複数のインスタンスに適用されると想定します。 XDC の適

用範囲の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 17] のこのセクションを参照

してください。


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




制約の作成

制約は、制約のタイプによって複数のファイルに分割する必要があります。パーシャルリコンフィギュレーション

では、デザイン制約を次の 3 つのタイプに分割することをお勧めします。

• スタティック : スタティックオブジェクト (セル、ピン、ネット、ポート ) のみを参照する物理またはタイミン

グ制約で、 RP 内のオブジェクトは参照しません。これらはグローバル制約で、スタティック合成にまたは初期

コンフィギュレーションのインプリメンテーションで適用されます。スタティック部分がインポートされる 2

つ目以降のコンフィギュレーションにこれらの制約を再適用することはお勧めしません。これらの制約はスタ

ティック DCP に既に存在しており、再適用すると意図しない制約の相互作用が発生する可能性があります。

• 境界: スタティック部分および RP の両方の参照オブジェクトを参照するタイミング制約 (set_false_path な

ど)。これらの制約は RP ピンオブジェクトを参照して記述し、 RM 内のオブジェクトは参照しないでください。

たとえば、次のような 2 つの制約があるとします。

set_false_path -from [get_pins static_reset/C] -through [get_pins rp_inst/rst]set_false_path -from [get_pins static_reset/C] -to [get_pins rp_inst/*foo*/D]

初の制約は、初期コンフィギュレーション後に RM がブラックボックスに変換されたときに失われることは

ないので、こちらの制約が推奨されます。 RM が削除された後も RP インターフェイスはスタティックデザイン

に存在し、制約で参照される rp_inst/rst ピンもデザインに存在します。 2 番目の制約のように制約が RM 内

のオブジェクトを使用して定義されている場合、制約は無効となり、 RM が削除された後デザインから破棄され

ます。この構文を使用する場合、これらの制約を各コンフィギュレーションで適用し直す必要があります。

• RM: RM ロジックのみを参照する物理またはタイミング制約。これらの制約はすべて範囲が RM に限定される

べきですが、どのように適用されるかは制約のタイプによって異なります。

° 汎用 RM 制約: RM の各インスタンスに適用されます。フォルスパス、マルチサイクル例外、ローカル RM

クロックの create_clock などのタイミング制約がその例です。これらの制約は、その物理的なロケー

ションにかかわらず、すべての RM に適用されます。

° RP 特定の RM 制約: RM がインプリメントされるロケーション (Pblock) に特定の制約。特定のブロック

RAM の配置、エンベデッド I/O の PACKAGE_PIN 制約などの物理制約がその例です。

重要: RP にエンベデッド I/O が含まれる場合、 I/O ピンがすべての RM で同一である場合でも、各コンフィギュレー

ションで I/O 制約 (PACKAGE_PIN、 IOSTANDARD、方向) を適用し直す必要があります。 Vivado データベースでは

ポートは上位オブジェクトですが、ポートに関連付けられている I/O バッファーが RP の一部である場合は、 RM

が削除されるときにそのポートの I/O 制約情報も削除されます。

また、物理制約 (Pblock、 LOC、 PACKAGE_PIN など) とタイミング制約を別の XDC ファイルに分けることをお勧め

します。このようにすると、制約をいつ適用するか (合成またはインプリメンテーション) を制御しやすくなり、制

約の変更が必要な場合に制約ファイルの管理が簡単になります。





制約の適用

制約を分割すると、制約をいつ、どのように適用するかを管理しやすくなります。

• スタティックタイミング制約: スタティック合成で適用し、スタティック合成 DCP に渡されるように合成およ

びインプリメンテーションで使用されるようマークします。これらの制約が適切に適用され、合成後の DCP に

存在していれば、インプリメンテーション時に再適用する必要はありません。

• スタティック物理制約: 初期コンフィギュレーションのインプリメンテーションで適用します。これらの制約は

スタティックタイミング制約と共に配線後のスタティック DCP に含まれるので、これらの制約はその後のコン

フィギュレーションで適用し直す必要はありません。

• 境界タイミング制約: 初期コンフィギュレーションのインプリメンテーションで適用します。制約で RM 内部の

オブジェクトを参照していなければ、これらの制約をその後のコンフィギュレーションで適用し直す必要はあ

りません。

• 汎用 RM 制約: スタティック合成で適用し、合成およびインプリメンテーションで使用されるようマークしま

す。これらの制約は RM DCP に存在し、 DCP がフルデザインにリンクされるときに適用されます。

重要: OOC 合成のみに使用される OOC 特定のタイミング制約 (モジュールポートの create_clock など) がある場

合は、これらの制約がデザイン全体に適用されないように out_of_context で使用するようマークします。この

ようにしないと、上位制約が適用されたときにこれらの下位 OOC 制約と競合し、意図しない制約の相互作用が発

生することがあります。

• RP 特定の RM 制約: 特定の RP ロケーションの特定の RM が含まれるコンフィギュレーションのインプリメン

テーションで適用します。 IOB を含む RM 内のすべての物理制約は RM が削除されるときに削除されるので、

適用し直す必要があります。

配線後の RM DCP が再利用される場合は、物理情報 (ブロック RAM、 IOB など) はすべて RM DCP に含まれるので、

適用し直す必要はありません。ただし、 write_checkpoint -cell を使用して作成された RM DCP には RM 特定

のタイミング制約は含まれないので、汎用 RM 制約と RM オブジェクトを参照する境界タイミング制約を適用する






リコンフィギャラブルパーティション境界の定義

パーシャルリコンフィギュレーションは、フレームごとに実行されます。そのため、作成されたパーシャル BIT

ファイルは、複数のコンフィギュレーションフレームで構築されます。パーシャル BIT ファイルのサイズは、含ま

れるフレームの数およびタイプによります。サイズは、 write_bitstream -rawbitfile コマンドで作成された

ロービットファイル (.rbt) のヘッダーで確認できます。

パーティションの境界はリコンフィギャラブルフレームの境界に揃っている必要はありませんが、揃っていると、

も効果的な配置配線結果が得られます。次の両方の条件が満たされていれば、リコンフィギュレーションされる

フレームにスタティックロジックを含めることができます。

• スタティックロジックが Pblock で定義されたエリアグループの外にある。

• スタティックロジックにブロック RAM、分散 (LUT) RAM、 SRL などのダイナミックエレメントが含まれてい

ない (7 シリーズデバイスのみ)。

スタティックロジックをリコンフィギャラブルフレームに配置する場合、スタティックロジックの機能が正確に再

書き込みされ、グリッチは発生しません。

T 形や L 形などの形状のパーティションも使用できますが、できるだけ使用しないでください。配線リソースを完

全にこれらの領域に収める必要があるので、配置配線が困難になる可能性があります。パーティションの境界を接

触させることはできますが、これらのパーティションはスタティックデザインに接続されるので、多少間が空いて

いるほうが配線制限を回避できます。リコンフィギャラブルパーティションをネストさせたり ( リコンフィギャラブ

ルパーティション内に別のリコンフィギャラブルパーティションを含める )、重ねたりすることはできません。デザ

インルールチェック ([Reports] → [Report DRC]) により、 PR デザインのパーティションおよび設定が確認されます。

物理的なリコンフィギャラブルフレームごとに存在させることができるリコンフィギャラブルパーティションは 1

つだけです。

リコンフィギャラブルフレームは、リコンフィギュレーション可能な小の物理領域で、その高さはクロック領域

または I/O バンクの境界に揃っています。リコンフィギャラブルフレームに複数のリコンフィギャラブルパーティ

ションからのロジックを含めることはできません。複数のリコンフィギャラブルパーティションからのロジックを

含めると、間違ったリコンフィギャラブルモジュールからの情報で領域がリコンフィギュレーションされてしまう

可能性があり、競合が発生する原因となります。ツールは、このようなリスクの高い状況を回避するように設計さ

れています。

デッドロック状態の回避

RM 境界を越えるトランザクションには、完了までに複数サイクルかかるものがあります。トランザクションが開始

し、完了する前に RM を削除するとシステムがデッドロック状態になります。たとえば、トランザクションを開始

したマスターが削除されたスレーブからの応答を待機する場合などです。

また、 RM 自体がデッドロック状態を発生させることがあります。たとえば、ソフトウェアが RM レジスタの特定の

値をポーリングしているとします。 RM を削除すると、ソフトウェアが待機し続けるため、停止する可能性がありま

す。大型のブロック転送が完了するのを待機している間に停止することもあります。

パーシャルリコンフィギュレーションデザインには何らかのハンドシェーク機構を組み込み、リコンフィギャラブ

ルモジュールの削除が安全なときにのみ実行されるようにする必要があります。この要求/肯定応答のペアはユー

ザーデザインの一部とし、どのような方法でも組み込むことができます。





デザインリビジョンチェック

第 8 章「デバイスのコンフィギュレーション」で説明するように、パーシャルビットストリームにはプログラム情

報以外のものはほとんど含まれません。 BIT ファイルの一部であるアドレス指定によりダイの位置が決まるので

ビットストリームのターゲット位置を特定する必要はありませんが、パーシャルビットストリームが現在動作中の

デザインと互換性があるかどうかをチェックする機能はハードウェアにはありません。パーシャルビットストリー

ムをそのリコンフィギャラブルモジュールのリビジョンと共にインプリメントされていないスタティックデザイン

に読み込むと、予期しない動作が発生することがあります。

パーシャルビットストリームにデザイン、リビジョン、モジュールを識別する接頭辞を付けることをお勧めします。

コンフィギュレーションコントローラーでこの識別子を読み取り、パーシャルビットストリームが動作中のデザイ

ンと互換性があることを確認できます。不一致が検出されると、コンフィギュレーションメモリに読み込まれる前

に互換性のないビットストリームが却下されます。この機能をデザインの一部として含める必要があり、

『PRC/EPRC: パーシャルリコンフィギュレーションのデータインテグリティおよびセキュリティコントローラー』

(XAPP887) [参照 34] に説明されている暗号化または CRC チェックと同様のものか、それらと組み合わせたものにで

きます。

ビットストリーム機能は、デザインリビジョンにタグを付けるのに単純なメカニズムを提供します。

BITSTREAM.CONFIG.USR_ACCESS プロパティを使用すると、リビジョン ID を直接ビットストリームに入力でき

ます。この ID は USR_ACCESS レジスタに配置され、 FPGA ロジックから同じ名前のライブラリプリミティブを使

用してアクセスできます。パーシャルリコンフィギュレーションデザインでこの値を読み出し、パーシャルビット

ストリームのヘッダーにユーザーが追加できる情報と比較して、デザインのリビジョンが一致していることを確認

できます。このオプションの詳細は、『 Vivado Design Suite を使用した USER_ACCESS によるビットストリーム識

別』 (XAPP1232) [参照 35] を参照してください。

注意: TIMESTAMP 機能は使用しないでください。この値は write_bitstream の各実行で一貫していません。

write_bitstream のすべての実行で、一貫した明示的な ID のみを使用してください。

シミュレーションおよび検証

パーシャルリコンフィギュレーションデザインのコンフィギュレーションは、それ自体で完全なデザインです。す

べての標準シミュレーション、タイミング解析、および検証手法が PR デザインでサポートされています。パーシャ

ルリコンフィギュレーションのみをシミュレーションすることはできません。具体的には、パーシャルビットスト

リームを ICAP のようなコンフィギュレーションポートに転送し、リコンフィギャラブルパーティションでの変更

結果 (中間状態を含む) を確認することはできません。




第 6 章

7 シリーズおよび Zynq デバイスでの設計に関する考慮事項とガイドライン

概要

この章では、 7 シリーズおよび Zynq®-7000 SoC デバイスに特定のパーシャルリコンフィギュレーションデザイン要

件について説明します。

ザイリンクスデバイスのパーシャルリコンフィギュレーション機能を使用するには、デザイン仕様を注意深く解析

し、 PR デザインの要件、特性、制限を考慮する必要があります。これにより、設計およびデバッグプロセスが単純

になり、デザインが誤動作するリスクを回避できます。

リコンフィギャラブルモジュール内のデザインエレメント

すべてのロジックがリコンフィギュレーション可能なわけではありません。グローバルロジックおよびクロックリ

ソースは、リコンフィギュレーション中も動作するようにし、フルデバイスコンフィギュレーション後の初期化

シーケンスが適用されるようにするため、スタティック領域に配置する必要があります。

リコンフィギャラブルモジュールには、次のロジックを配置できます。

• デバイスの CLB スライスにマップされているすべてのロジックコンポーネント : LUT (ルックアップテーブル)、

FF (フリップフロップ)、 SRL (シフトレジスタ)、 RAM、 ROM など。

• ブロック RAM および FIFO:

° RAMB18E1、 RAMB36E1、 BRAM_SDP_MACRO、 BRAM_SINGLE_MACRO、 BRAM_TDP_MACRO

° FIFO18E1、 FIFO36E1、 FIFO_DUALCLOCK_MACRO、 FIFO_SYNC_MACRO

注記: IN_FIFO および OUT_FIFO デザインエレメントは RM には配置できません。これらのデザインエレメン

トは、スタティックロジックに配置する必要があります。

• DSP ブロック : DSP48E1

• PCIe® (PCI Express): PCIe IP を使用して入力。




第 6 章: 7 シリーズおよび Zynq デバイスでの設計に関する考慮事項とガイドライン

次を含むその他のロジックはスタティックロジックに配置し、 RM には配置しないでください。

• クロックおよびクロック調整ロジック : BUFG、 BUFR、 MMCM、 PLL などのコンポーネント

• I/O および I/O 関連のコンポーネント : ISERDES、 OSERDES、 IDELAYCTRL など

• シリアルトランシーバー (MGT) および関連のコンポーネント

• アーキテクチャ機能コンポーネント : BSCAN、 STARTUP、 XADC など

グローバルクロックの規則

特定のリコンフィギャラブルパーティションの各リコンフィギャラブルモジュールのクロック情報は初のインプ

リメンテーションの時点では不明なので、その RP 上のパーティションピンを駆動する各 BUFG 出力が Pblock に含

まれるすべてのクロック領域にあらかじめ配線されます。これはつまり、その領域で RP にロードがあるかどうかに

かかわらず、それらのクロック領域のクロックスパインをスタティックロジックが使用できない可能性があるとい

うことです。

7 シリーズデバイスでは、大 12 個までのクロックスパインを各クロック領域への事前配線に使用できます。スタ

ティックロジックおよびリコンフィギャラブルロジックの両方で、この制限数を考慮する必要があります。たとえ

ば、スタティックロジック用にクロック領域に 3 つのグローバルクロックが配線される場合、これらの 3 つの上

位クロックに加え、そのクロック領域を含む RP で 9 個のグローバルクロックを使用できるということです。

82 ページの図 6-1 に示す例では、 icap_clk が配置前にクロック領域 X0Y1、 X0Y2、および X0Y3 に配線され、ス

タティックロジックでその領域のその他のクロックスパインを使用できます。





推奨: RP を駆動するグローバルクロックの数が多い場合は、クロック領域を完全に含むエリアグループを作成し、

スタティックロジックを配置および配線しやすくするようにすることをお勧めします。ロードの数が少ないか、要

件がそれほど厳しくないグローバルクロックは、リージョナルクロック (BUFR、 BUFH など) に変更できます。ク

ロックをグローバルリソースからローカルリソースに変更すると、 RP で固有のクロックが多数必要な場合に、さ

らに柔軟なフロアプランが可能になります。


図 6-1: グローバルクロックからリコンフィギャラブルパーティションへの事前配線





7 シリーズデバイスでの Pblock の作成

第 3 章の「リコンフィギュレーション後にリセットを適用」で説明したように、 RESET_AFTER_RECONFIG を使用

する場合は、リコンフィギャラブルパーティションの高さがクロック領域の境界に揃っていることが必要です。

RESET_AFTER_RECONFIG を使用しない場合は、リコンフィギャラブルパーティション Pblock の高さは任意の値

に選択できます。

リコンフィギャラブルパーティションの幅も、インターコネクトおよびクロックリソースを効率的に使用できるよ

うに適切に設定する必要があります。 Pblock の長方形の左辺および右辺は、インターコネクト列 (INT-INT) の間では

なく、 2 つのリソース列 (CLB-CLB、 CLB-ブロック RAM、 CLB-DSP など) の間に配置する必要があります。これに

より、配置配線ツールでスタティックロジックおよびリコンフィギャラブルロジックの両方にすべてのリソースが

活用されます。この手法に従っていない場合、インプリメンテーション DRC によりガイダンスが提供されます。

リコンフィギャラブルパーティションの自動調整

Pblock に SNAPPING_MODE プロパティを設定すると、 7 シリーズデザインで隣接違反が発生しないようにするため、

Pblock のサイズが自動的に調整されます。 SNAPPING_MODE の値を ON または ROUTING に設定すると、 Pblock の範

囲のセットが新しく作成され、インプリメンテーションで使用されます。これらの範囲はメモリに格納され、 XDC

には記述されません。 SNAPPING_MODE プロパティのみが、通常の Pblock 制約と共に記述されます。

7 シリーズデバイスでは、インターコネクトタイルと呼ばれる配線リソースが、近くにまたは隣接して配置されま

す。パーシャルコンフィギュレーション用にフロアプランを実行するときは、隣接した境界がどこに存在するのか

を理解しておくことが重要です。 Pblock がこのようなペアになって並んでいるインターコネクトタイルを分割する

場合、隣接違反と呼ばれます。隣接するインターコネクトの詳細は、 86 ページの「リコンフィギャラブルパーティ

ション Pblock の手動作成」を参照してください。

SNAPPING_MODE を使用した場合、元の Pblock の長方形は変更されませんが、サイズが変更され、移動され、追加

の長方形で拡張されることがあります。元の Pblock の長方形が変更されると、それから作成された範囲も自動的に

再計算されます。 SNAPPING_MODE プロパティはバッチモードでサポートされるので、 SNAPPING_MODE を設定す

るのに Vivado® IDE で現在の Pblock を開く必要はありませんが、 83 ページの図 6-2 に示すように、インタラクティ

ブフロアプランを実行するときにこのオプションを設定できます。


図 6-2: Vivado IDE での SNAPPING_MODE プロパティの設定





次の構文を使用するか、上記のように Pblock プロパティを選択して SNAPPING_MODE プロパティを設定すると、イ

ンプリメンテーションで自動的に修正された Pblock 範囲が認識されます。

set_property SNAPPING_MODE ON [get_pblocks <pblock_name>]

次の表に、 7 シリーズデバイス用の SNAPPING_MODE プロパティ値を示します。

SNAPPING_MODE プロパティは、 RESET_AFTER_RECONFIG と共に使用することもできます。

RESET_AFTER_RECONFIG を使用するには、 Pblock の高さがフレーム (またはクロック領域) に揃っている必要があ

ります。 SNAPPING_MODE を ON または ROUTING に設定し、 RESET_AFTER_RECONFIG を TRUE に設定すると、生

成された領域にこの要件を満たすのに必要なすべてのサイトが自動的に含まれます。

表 6-1: SNAPPING_MODE プロパティ値 (7 シリーズデバイス)

プロパティ値説明

SNAPPING_MODE OFF 7 シリーズの場合のデフォルトです。調整は実行されず、

DERIVED_RANGES == GRID_RANGES です。

ON すべての隣接違反を修正します。

ROUTING 次の例外を除き、 ON の場合と同じです。

• 配線を改善するため中央クロック列をまたぐ隣接違反は修正されません。

• 配線を改善するため、 RP Pblock 内または隣接するボンディングされていない I/O および GT サイトを使用します。これらのリソースは、サイトがボンディングされておらず、列全体 (クロック領域の高さ ) が Pblock の長方形に含まれている場合にのみ PR 配線に使用可能です。

これは、 7 シリーズおよび Zynq デバイスに推奨される値です。





図 6-3 に、ユーザーが作成した元の Pblock を紫色で示します。 RESET_AFTER_RECONFIG がイネーブルになってお

り、左辺と右辺の両方がインターコネクト列を分離しています。 SNAPPING_MODE を適用すると、調整された

Pblock (黄色) は INT-INT 境界を回避するため幅が細くなり、クロック領域の高さに揃うように縦に長くなります。


図 6-3: 元の Pblock と SNAPPING_MODE により調整された Pblock





リコンフィギャラブルパーティション Pblock の手動作成

隣接問題を修正するリコンフィギャラブルパーティション Pblock の自動調整が望ましくない場合は、 Pblock 範囲を

手動で作成する必要があります。これは、コンフィギュレーションブロックやクロックバッファーリソースを含む

中央列などのリコンフィギャラブル不可能なサイトにまたがる Pblock を厳密に制御するのに役立ちます。

図 6-4 に示す白でハイライトされた Pblock では、左辺と右辺が CLB 列の間に描かれています。インターコネクトタ

イルを表示するには、 [Device] ウィンドウでボタンをクリックして [Routing Resurces] をオンにします。

リコンフィギャラブルパーティション Pblock には、描画した形状の中にすべてのリコンフィギャラブルエレメント

タイプを含める必要があります。つまり、選択した長方形に CLB (スライス)、ブロック RAM、および DSP エレメン

トが含まれる場合、 3 つのタイプすべてが Pblock に含まれている必要があります。 1 つでも欠けていると、 DRC に

より分割されたインターコネクトが検出されたことを示すアラートが表示されます。

リコンフィギャラブルパーティションが、中央列のクロックリソースやコンフィギュレーションコンポーネント

(ICAP、 BSCAN) などのリコンフィギュレーション不可能なサイトを含む場合や、 I/O などのリコンフィギュレー

ション不可能なコンポーネントに隣接している場合は、ほかにも考慮すべき事項があります。 Pblock のいずれかの

辺が異なるリソースタイプのインターコネクト列を分割する場合、インプリメンテーションツールによりこのレイ

アウトは許容されますが、境界の各辺の列への配置が制限されます。 ICAP や BSCAN など、デザインでこの禁止サ

イトが必要な場合は、 Pblock を複数の長方形に分割し、リコンフィギャラブルロジックのリソース使用を明確に定

義するか、 SNAPPING_MODE を使用する必要があります。


図 6-4: リコンフィギャラブルパーティション Pblock の左辺と右辺の両方が CLB 列の間にある (適切な配置)





インプリメンテーションツールでは、 PROHIBIT 制約を作成することにより、隣接するインターコネクトサイトの

両側への配置が自動的に回避されます。隣接違反のために禁止されたサイトがデザインで不要な場合は、デザイン

で隣接違反をそのままにしておくことも許容されます。そのようにすると、 PR 領域に配線タイルの追加の列が含ま

れ、リコンフィギャラブル不可能なサイトにまたがる PR 領域の密集を防ぐことができます。この場合、 DRC によ

りクリティカル警告が表示されますが、配置と配線リソースのトレードオフを理解している場合はこの警告は無視

しても問題ありません。

この動作の唯一の例外は、クロック列の周囲です。クロック列の境界で違反が発生した場合は、違反のある RM 側

に PROHIBIT 制約が生成されますが (通常は SLICE 禁止)、クロッキングリソースには PROHIBIT 制約は生成され

ず、スタティックロジックで使用できます。 SNAPPING_MODE の値を ROUTING にするのは、この例外の利点を活

かすためです。たとえば、図 6-5 に示す初期フロアプランには、クロックバッファーリソース

(BUFHCE/BUFGCTRL) を含む中央列が含まれています。これらのリソースは、図 6-5 でハイライトされておらず、

Pblock ブロックに含まれていません。このクロック列をまたぐと違反は発生しますが、それでもリソースはスタ

ティックロジックで使用できます。


図 6-5: リコンフィギャラブル不可能なサイトを含む Pblock





禁止サイトは、図 6-6 に示すように、配置済みまたは配線済みチェックポイントで斜線の付いた赤丸で示されます。

この自動禁止機能により、 CLB 自体は使用されませんが、コンフィギャラブルサイト (CLB) に関連付けられた配線

インターコネクトはリコンフィギャラブルモジュールに使用できます。図 6-6 では、左側の INT 列は RM に使用可

能ですが、右側の INT 列はクロックタイルの一部であり、 7 シリーズデバイスではリコンフィギュレーション不可

能なので、スタティックロジックのみで使用可能です。

隣接違反によりデザインに必要なサイト (ICAP や BSCAN) が禁止される場合は、デバイスに使用可能なサイトが十

分ないことを示す配置エラーが表示されます。

ERROR: [Common 17-69] Command failed: Placer could not place all instances

この制限を回避するには、図 6-7 に示すように複数の Pblock の長方形を作成してインターコネクト列が分割されな

いようするか、 Pblock に SNAPPING_MODE プロパティを使用します。

推奨: 通常は、リコンフィギャラブルではないサイトタイプ (IOB、コンフィギュレーション、クロック列など) をま

たぐことは、できる限り避けてください。 Pblock がこれらのサイトのいずれかをまたぐ必要がある場合、もリス

クが低いのはクロック列です (その理由は先に説明)。境界をできる限り効率よくまたぐようにするには、

SNAPPING_MODE ROUTING を使用してください。


図 6-6: チェックポイントの禁止サイト






図 6-7: リコンフィギャラブル不可能なリソースを含めないように複数の Pblock の長方形を作成





図 6-8 に分割部分を拡大し、スライス (CLB) とインターコネクト (INT) リソースタイプを示します。 2 つの Pblock 長

方形間のギャップにより、 BUFHCE コンポーネントに完全にアクセスでき、スタティックリソースを使用して完全

に配線できます。また、 CLB の 1 つの列をスタティックデザインで使用できます。これらのギャップをまたぐこと

ができる配線リソースはありますが、そうすると全体的な配線能力が大幅に低下します。このアプローチは難点が

多いため、可能であれば回避してください。 IOB やコンフィギュレーションタイルなどのほかのスタティック境界

をまたぐ場合は、 PR 領域の配線ギャップが 2 つの INT リソースになり、配線が困難になります。

T 形や L 形などの形状のパーティションも使用できますが、全体的な形状はできるだけシンプルにすることをお勧

めします。配線リソースを完全にこれらの領域に収める必要があるので、配置配線が困難になる可能性があります。

パーティションの境界を接触させることはできますが、多少間が空いている方が配線制限が原因で問題が発生する

可能性を回避できます。リコンフィギャラブルパーティションをネストさせたり ( リコンフィギャラブルパーティ

ション内に別のリコンフィギャラブルパーティションを含める )、重ねたりすることはできません。

後に、物理的なリコンフィギャラブルフレームごとに存在させることができるリコンフィギャラブルパーティ

ションは 1 つだけです。リコンフィギャラブルフレームは、リコンフィギュレーション可能な小の物理領域で、

クロック領域の境界に揃えられています。リコンフィギャラブルフレームに複数のリコンフィギャラブルパーティ

ションからのロジックを含めることはできません。複数のリコンフィギャラブルパーティションからのロジックを

含めると、間違ったリコンフィギャラブルモジュールからの情報で領域がリコンフィギュレーションされてしまう

可能性があり、競合が発生する原因となります。 Vivado ツールは、このようなリスクのある状況を回避するように

設計されています。


図 6-8: クロック配線用に予約された列





高速トランシーバーの使用

ザイリンクス高速トランシーバー (GTP、 GTX、 GTH、 GTZ) は 7 シリーズデバイスではリコンフィギュレーション

不可能であり、スタティックロジックに配置する必要があります。ただし、トランシーバーの設定は動作中に DRP

ポートを使用してアップデートできます。トランシーバー設定および DRP アクセスの詳細は、『7 シリーズ FPGA

GTX/GTH トランシーバーユーザーガイド』 (UG476) [参照 19] および『7 シリーズ FPGA GTP トランシーバーユー

ザーガイド』 (UG482) [参照 20] を参照してください。

パーシャルリコンフィギュレーションデザインチェックリスト (7 シリーズデバイス)パーシャルリコンフィギュレーションを使用する 7 シリーズ FPGA デザインでは、次の事項が推奨されます。

クロッキングネットワーク

グローバルクロックバッファー、リージョナルクロックバッファー、またはクロック調整ブロック (MMCM、 PLL)

を使用していますか。

これらのブロックは、スタティックロジックに配置する必要があります。

詳細は、「リコンフィギャラブルモジュール内のデザインエレメント」を参照してください。グローバルク

ロックのインプリメンテーションの詳細は、「グローバルクロックの規則」を参照してください。

コンフィギュレーション機能ブロック

デバイス機能ブロック (BSCAN、 CAPTURE、 DCIRESET、 FRAME_ECC、 ICAP、 STARTUP、 USR_ACCESS) を使用

していますか。

これらの機能ブロックは、スタティックロジックに配置する必要があります。

詳細は、「リコンフィギャラブルモジュール内のデザインエレメント」を参照してください。

高速トランシーバーブロック

デザインに高速トランシーバーが含まれていますか。

高速トランシーバーは、スタティックロジックに配置する必要があります。

特定の要件は、「高速トランシーバーの使用」を参照してください。

System Generator DSP コア、 HLS コア、または IP インテグレーターブロック図

パーシャルリコンフィギュレーションデザインで System Generator DSP コア、 HLS コア、または IP インテグレー

ターブロック図を使用していますか。

パーシャルリコンフィギュレーションの基本的な要件を満たしていれば、どのタイプのソースでも使用できま

す。 System Generator、 HLS、 Vivado IP インテグレーターなどのツールで処理されたコードは終的に合成され

ます。結果のデザインチェックポイントまたはネットリストを RP に含めることができるようにするには、リ

コンフィギャラブルエレメント (CLB、ブロック RAM、 DSP) のみで構成されるようにする必要があります。





I/O のリコンフィギャラブルパーティションへの配置

リコンフィギャラブルパーティションに I/O が含まれていますか。

I/O はすべて、スタティックロジックに配置する必要があります。


ロジックのリコンフィギャラブルパーティションへの配置

一緒に配置する必要のあるロジックが同じリコンフィギャラブルパーティションに配置されていますか。

一緒に配置する必要のあるロジックは、同じ RP および RM に配置する必要があります。

詳細は、「ロジックのパック」を参照してください。

クリティカルパスのリコンフィギャラブルパーティションへの配置

クリティカルパスが同じパーティション内に制約されていますか。

リコンフィギャラブルパーティションの境界では適化およびパックに制限があるので、クリティカルパスは

同じパーティション内に制約する必要があります。


フロアプラン

リコンフィギャラブルパーティションを効率的にフロアプランできますか。

詳細は、「7 シリーズデバイスでの Pblock の作成」を参照してください。

デカップリングロジックの使用 (推奨)

RM の出力にデカップリングロジックを作成しましたか。

リコンフィギュレーション中、 RP の出力は不定の状態になるので、スタティックデータが破損するのを回避す

るためデカップリングロジックを使用する必要があります。

詳細は、「デカップリング機能」を参照してください。

リコンフィギュレーション後にリセットを適用 (推奨)

リコンフィギュレーション後に RAM のロジックをリセットしていますか。

リコンフィギュレーション後、新しいロジックが初期値で開始しない場合があります。

RESET_AFTER_RECONFIG プロパティを使用しない場合は、ローカルリセットを使用して、デカップリングを

解放したときにロジックが予測される状態で開始するようにする必要があります。リコンフィギュレーション

中は、初期化問題を回避するため、リコンフィギャラブルパーティションへのクロックおよびその他の入力も

ディスエーブルになります。 RESET_AFTER_RECONFIG プロパティを設定することも可能です。このオプショ

ンは、リコンフィギュレーション中、内部信号を一定に保持し、リコンフィギュレーションされたロジックに

マスク付きのグローバルリセットを適用します。

詳細は、「リコンフィギュレーション後にリセットを適用」を参照してください。





ロジック解析ブロックを使用したデバッグ

パーシャルリコンフィギュレーションで Vivado ロジック解析を使用していますか。

Vivado ロジック解析 (ILA/VIO デバッグコア) はパーシャルリコンフィギュレーションデザインで使用できます

が、これらのコアをデバッグハブに接続する際には注意が必要です。「Vivado デバッグコアの使用」に説明す

る自動推論ソリューションを使用してください。

効率的なリコンフィギャラブルパーティション Pblock

デザインに対して効率的なリコンフィギャラブルパーティション Pblock を作成していますか。

RESET_AFTER_RECONFIG プロパティを使用する場合、リコンフィギャラブルパーティション Pblock の高さは

クロック領域境界の上辺および下辺に揃える必要があります。 RESET_AFTER_RECONFIG を使用しない場合

は、リコンフィギャラブルパーティション Pblock の高さは任意に選択できます。

詳細は、「7 シリーズデバイスでの Pblock の作成」を参照してください。


コンフィギュレーション間の一貫性はどのように検証しますか。

pr_verify コマンドを使用して、すべてのコンフィギュレーションのインポートされるリソースに一致してい

ることを確認できます。

詳細は、「コンフィギュレーションの検証」を参照してください。

コンフィギュレーションの要件

デザインおよびデバイスにおけるパーシャルリコンフィギュレーションに特定のコンフィギュレーション要件があ

ることを理解していますか。

各デバイスファミリに特定のコンフィギュレーション要件および考慮事項があります。

詳細は、「デバイスのコンフィギュレーション」を参照してください。

効率的な Pblock に関する推奨事項

RP Pblock がデバイスの中央のクロック列またはコンフィギュレーション列をまたいでいますか。

7 シリーズデバイスの隣接 INIT タイル要件と CONTAIN_ROUTING 要件のため、Pblock がデバイス上のこれらの

特別ブロックにまたがると、配線が非常に困難になるか、配線不可能になります。できる限り、 RP Pblock がこ

れらのエリアにまたがらないようにしてください。

隣接要件の詳細は、「リコンフィギャラブルパーティションの自動調整」および「リコンフィギャラブルパー

ティション Pblock の手動作成」を参照してください。




第 7 章

UltraScale および UltraScale+ デバイスでの設計に関する考慮事項とガイドライン

概要

この章では、 UltraScale™ および UltraScale+™ デバイスに特定のパーシャルリコンフィギュレーションデザイン要

件について説明します。

ザイリンクスデバイスのパーシャルリコンフィギュレーション機能を使用するには、デザイン仕様を注意深く解析

し、 PR デザインの要件、特性、制限を考慮する必要があります。これにより、設計およびデバッグプロセスが単純

になり、デザインが誤動作するリスクを回避できます。

リコンフィギャラブルモジュール内のデザインエレメント

UltraScale および UltraScale+ デバイスでは、ほぼすべてのコンポーネントタイプをパーシャルリコンフィギュレー

ション可能です。

リコンフィギャラブルモジュールには、次のロジックを配置できます。

• FPGA の CLB スライスにマップされているすべてのロジックコンポーネント : LUT (ルックアップテーブル)、

FF (フリップフロップ)、 SRL (シフトレジスタ )、 RAM、 ROM など。

• ブロック RAM および FIFO: RAMB18E2、 RAMB36E2、 FIFO18E2、 FIFO36E2

• DSP ブロック : DSP48E2

• PCIe® (PCI Express)、 CMAC (100G MAC)、および ILKN (Interlaken MAC) ブロック

• SYSMON (XADC およびシステムモニター )

• クロックおよびクロック調整ロジック : BUFG、 BUFGCE、 BUFGMUX、 MMCM、 PLL などのコンポーネント

• I/O および I/O 関連のコンポーネント : ISERDES、 OSERDES、 IDELAYCTRL など

• シリアルトランシーバー (MGT) および関連のコンポーネント




第 7 章: UltraScale および UltraScale+ デバイスでの設計に関する考慮事項とガイドライン

コンフィギュレーションコンポーネントのみをデザインのスタティック部分に配置する必要があります。それらの

コンポーネントは、次のとおりです。

• BSCAN

• CFG_IO_ACCESS

• DCIRESET

• DNA_PORT

• EFUSE_USR

• FRAME_ECC

• ICAP

• MASTER_JTAG

• STARTUP

• USR_ACCESS

UltraScale および UltraScale+ デバイスでの Pblock の作成

UltraScale アーキテクチャでは、リコンフィギュレーション可能な小ユニットが以前のアーキテクチャよりも小さ

くなっています。リコンフィギュレーションに必要な小リソースはリソースタイプによって異なり、プログラマ

ブルユニット (PU) と呼ばれます。UltraScale アーキテクチャでは隣接のサイトと配線リソース (インターコネクトタ

イル) が共有されるので、 PU はペアで定義されます。

サイトタイプに基づくリコンフィギュレーション可能な小 PU の例を示します。

• CLB PU: 隣接する 2 つの CLB、および共有インターコネクト

• ブロック RAM PU: 1 つのブロック RAM/FIFO、隣接する 5 つの CLB、および共有インターコネクト

• DSP PU: 1 つの DSP、隣接する 5 つの CLB、および共有インターコネクト

• IOB PU: クロック領域の全高さと同じ I/O で、 BITSLICE_CONTROL、 BITSLICE_RX_TX、 BITSLICE_TX、

BUFGCE、 BUFGCE_DIV、 BUFGCTRL、 IOB、 MMCME3_ADV、 PLLE3_ADV、 PLL_SELECT_SITE、 RIU_OR

などが含まれます。近接の CLB は 60 個で、インターコネクトが共有されています。





Pblock の PU の自動調整

UltraScale および UltraScale+ デバイスでは、 RESET_AFTER_RECONFIG オプションはありません。パーシャルリコ

ンフィギュレーションの後に常に GSR が発行され、 7 シリーズデバイスのようにこの機能を有効にするための

Pblock のサイズ/形状に関する要件はありません。ただし、 Pblock が小 PU サイズの規則に違反しないようにする

ため、 SNAPPING_MODE プロパティも常にオンになっており、 Pblock が PR に有効なものになるよう自動的に調整さ

れます。

図 7-1 および図 7-2 に、 SNAPPING_MODE により Pblock が PU に合わせてどのように調整されるかを示します。

図 7-1 では、元の矩形は大きいですが、選択されたタイルのみが RP Pblock に含まれます。上のブロック RAM およ

び DSP サイトは、 Pblock に完全に含まれていないので、含まれません。関連の CLB サイトも、 PU の規則に基づき、

含まれません。左辺と右辺のどちらの Pblock に含まれない CLB サイトがありますが、これは隣接する CLB が元の

矩形に含まれないからです。


図 7-1: SNAPPING_MODE の例 - UltraScale





SNAPPING_MODE により上記の Pblock が RP に有効なものになりますが、これらのサイトすべてを含めるつもりで

ある場合もあります。元の Pblock 矩形を少し調整することにより、 SNAPPING_MODE で PR 領域に含める予定のサ

イトが除外されないようにすることができます。図 7-2 では、 Pblock が左、右、上方向に 1 CLB 分ずつ拡張されて

います。 RP Pblock に含まれるハイライトされているタイルは、元の矩形に一致します。

注記: 図 7-1 および図 7-2 は、リコンフィギャラブルパーティションの Pblock に対して Vivado Design Suite ツールで

自動的に作成されるハイライトスクリプトを使用して作成されています。デバッグまたは検証用にこれらの図を再

現するには、次の手順に従います。

1. リコンフィギャラブルパーティションを作成し、調整します。 Pblock には、 HD.RECONFIGURABLE プロパティ

を設定する必要があります。

2. source コマンドを使用して Vivado で生成されたハイライトスクリプトを実行します。

source ./hd_visual/<pblock_name>_AllTiles.tcl

注記: hd_visual ディレクトリのスクリプトは、 Pblock 制約が処理されるときに更新されます。つまり、 Pblock を

含むデザインを開いたり、開いているデザインで Pblock を作成または修正するときなどに、更新されます。


図 7-2: PU に揃えられた Pblock





RP とスタティックロジックでのコンフィギュレーションフレームの共有

UltraScale および UltraScale+ デバイスの Pblock ではフレーム (クロック領域の高さ ) に揃える必要はありませんが、

パーシャルリコンフィギュレーションではコンフィギュレーションフレーム全体がプログラムされます。つまり、

RP 外にあるロジックが上書きされるということです。これにより PR で問題が発生することはありませんが、以前

のアーキテクチャではリコンフィギャラブルロジックと同じフレームに配置できるスタティックロジックのタイプ

に制限がありました。

UltraScale および UltraScale+ デバイスでは、どのスタティックロジックでも、 RP Pblock に含まれないサイトであれ

ば、 RM と同じコンフィギュレーションフレームに配置できます。これには、ブロック RAM、 DSP、および LUT

RAM が含まれます。ただし、コンフィギュレーションフレームごとに 1 つの RP しか含めることができないという

制限があります。つまり、同じクロック領域に 2 つの RP を縦に並べることはできません。

CONTAIN_ROUTING エリアの拡張

UltraScale および UltraScale+ デバイスの RP Pblock の配線要件は、配線およびタイミング結果を改善できるように緩

和されています。配線を Pblock 内のリソースに厳密に限定する代わりに、配線フットプリントが拡張されています。

このフットプリントには、 Pblock に属するとは限らない Pblock の境界内のリソースと Pblock 矩形外のリソースが含

まれます。これは、 Pblock の境界外に RM ネットおよびパーティションピンがある可能性があることを意味します。

ただし、それらのパーティションピンまたは含まれるネットは、拡張された配線フットプリント内にあります。

拡張配線フットプリントは、 hd_visual Tcl スクリプトの 1 つを実行すると可視化できます。これらのスクリプトは、

パーシャルリコンフィギュレーションフロー中に自動的に生成され、現在の作業ディレクトリの ./hd_visual サ

ブディレクトリにあります。拡張配線フットプリントを表示させる可視化スクリプトは、

./hd_visual/<pblock_name>_Routing_AllTiles.tcl という名前です。拡張配線フットプリントは、実際に

は配線中に決定されるので、このファイルは route_design が完了するまで使用できません。拡張配線フットプリント

を表示させるには、配線済みデザインを開いた後に、 Tcl コンソールからこのファイルを実行します。配線に使用で

きるタイルがすべて選択され、必要に応じてハイライトまたはマークできます。次の図では、ユーザー定義の

Pblock の配置を青、拡張配線ゾーンを黄色で示しています。

source ./hd_visual/pblock_inst_shift_low_Routing_AllTiles.tcl





r

RM で使用されるフレームはすべてパーシャルビットファイルに含めておく必要があるため、配線フットプリント

を拡張すると、パーシャルビットファイルが大きくなります。サイズの拡大は、元の Pblock のサイズと形によりま

す。既に矩形である Pblock は拡大できますが、クロック領域の境界を越えて垂直方向に拡大することはできません。

右側または左側の新しいクロック領域に拡張することは可能です。 Pblock の境界を内部クロック領域のエッジの手

前で止めると、 RP が配線しやすくなることがあります。デバイスのエッジ (左または下のエッジなど) に揃っている

Pblock エッジは、配線を拡張するためだけに内側に移動しないでください。スタティック領域でエッジ沿いのリ

ソースにアクセスできるようになると、配置の問題が発生する可能性があります。この配線拡張機能をオンにして

おくことをお勧めしますが、パーシャルビットストリームのサイズがデザインのパフォーマンスよりも重要な場合

は、次のパラメーターを設定してこの機能をオフにできます。

set_param hd.routingContainmentAreaExpansion false

I

重要: 拡張配線フットプリントは、 7 シリーズデバイスではサポートされていません。


図 7-3: ハイライトされた Pblock および拡張配線フットプリント





RP 内のクロックのフロアプラン規則

UltraScale および UltraScale+ デバイスでは、 BUFG_*、 PLL、および MMCM など、 RP 内のクロッキングリソースが

サポートされます。この機能を使用するデザインは、「グローバルクロックの規則」で説明される一般的なデザイン

制限と次のフロアプラン規則に従う必要があります。これらの規則は、 RP 内のクロックが RP Pblock に属するフ

レーム内の必要な配線リソースに到達するようにするため必要です。

1. できるだけ長方形の Pblock を作成します。 Pblock が複数の長方形で形成される場合、 Pblock の一番高い列が

clock_region に揃えられている必要があります。

2. 内部 RM クロックの CLOCK_ROOT プロパティは、 Pblock の一番高い列の 1 つとして設定する必要があります。

ツールは CLOCK_ROOT に対して正しい列を選択しようと試みますが、選択できない場合もあります。

a. CLOCK_ROOT は、クロックネットに USER_CLOCK_ROOT プロパティが存在する場合は自動的に選択さ

れません。 USER_CLOCK_ROOT プロパティが Pblock の完全な高さでない列に設定されている場合、配線

できない接続が出る可能性があります。

b. BUFG_GT の構成によっては、 CLOCK_ROOT が BUFG_GT と同じ領域に存在することが必須条件であるこ

とがあります。 USER_CLOCK_ROOT プロパティが Pblock の一番高い列以外の列に設定されている場合、

配線できない接続が出る可能性があります。これを回避するには、そのクロックネットを 2 つの

BUFG_GT (1 つはユーザーロジック用、もう 1 つはダイレクト GT 接続用) に分割してみると、各クロック

に独自の CLOCK_ROOT ができます。

図 7-4 に示すように、 CLOCK_ROOT が X2Y2 (Pblock の左上) 領域に定義されていると、クロックで X2Y1 領域

を使用できないため、 X3Y1 (Pblock の右下) 領域のロードに配線できません。その反対に、 CLOCK_ROOT が

X3Y2 または X3Y1 のいずれかに定義される場合は、クロック配線の制限は何も適用されません。


図 7-4: L 型 Pblock の CLOCK_ROOT 制限





3. CLOCK_ROOT が一番高い列に設定できない場合、 RP 領域内の入れ子になった Pblock を使用して、そのクロッ

クのロードをクロックによりアクセス可能な領域に含めることができます。入れ子になった Pblock があると、

不規則な形の Pblock になるので、クロックでアクセスできない領域にロードが配置されなくなります。

4. 図 7-5 に示すように、 clock_region 全体にまたがる大きなギャップが作成されるような U 型または H 型の

Pblock は作成しないでください。

図 7-6 に示すように、 PR Pblock の行に IOB 1 列分などの小さなギャップがあるのはかまいませんが、こうした

ギャップはできるだけ避けてください。 RM 配線がこれらのギャップを越える必要があるため、配線の密集の原

因となります。


図 7-5: clock_region にギャップが作成される Pblock (サポートなし )


図 7-6: 小さいギャップがある Pblock (サポートあり )





図 7-7 に示すような小さな階段型の Pblock が必要になることもあります。このようなう Pblock はサポートされ

ますが、角の周辺で配線が密集する可能性があります。

5. クロッキングリソースを含む PR Pblock は、その他の RP とクロック領域の一部を共有することはできません。

スタティックロジックを含むクロック領域は共有できます。これは、これらのクロックリソースにより駆動さ

れるロジックが RP の内側または外側のどこにあるかにかかわらず同じです。

グローバルクロックの規則

UltraScale より前のアーキテクチャと同様に、リコンフィギャラブルパーティションを駆動するすべてのクロック

は、サイトが RP に含まれる各クロック領域にあらかじめ配線されます。これは、リコンフィギャラブルパーティ

ションのサイズにかかわらず、リコンフィギャラブルパーティションを駆動するグローバルクロックの総数は大

24 であるということです。クロックソースが RM 内にある場合は、これらのクロックソースを各クロック領域にあ

らかじめ配線する必要はないので、クロック使用率を高めることができます。そのため、 RP の Pblock のサイズおよ

び形状に注意することが重要です。 7 シリーズデバイスではクロック領域ごとに使用可能なグローバルクロックは

12 個でしたが、 UltraScale アーキテクチャでは 24 個です。

注記: BUFGCTRL コンポーネントの場合は、 RESET_AFTER_RECONFIG がイネーブルになっていても、パーシャル

リコンフィギュレーション中に PRESELECT_I0 および PRESELECT_I1 プロパティが無視されます。選択したク

ロックソースは、 BUFGCTRL インスタンスのセレクトおよびクロックイネーブル入力のみに左右されます。

Vivado 2017.4 から、リコンフィギャラブルモジュール内のクロックソースで、ロジックをスタティックデザインま

たはほかのリコンフィギャラブルモジュールに駆動できるようになりました。一貫したクロックスパインの使用な

ど、下位レベルの詳細の多くは Vivado で処理されます。デザインルールチェックにより、基本的な規則が適用され

ていることが確認されます。ただし、いくつかの考慮事項があります。


図 7-7: 階段型 Pblock (サポートあり )





• 1 つの RP では、 RM 間でクロックリソースを一貫したものにする必要があります。 MMCM パラメーターなど

のクロックの特性を変更することはできますが、クロックドライバーのタイプ (BUFG など) は同じにし、固定

したスタティックデザインで配線リソースが一貫したものになるようにする必要があります。

• リコンフィギュレーション中はクロックの動作が不確定になるので、デカップリングすることを考慮してくだ

さい。クロックにはファンアウトの大きい配線リソースが使用されるので、標準インターフェイスとは異なり、

2:1 マルチプレクサーやレジスタは適していません。その代わりに BUFGMUX を使用してリコンフィギュレー

ション中のクロックソースを遮断できます。別の方法として、クロックソースのリコンフィギュレーション

中、スタティック領域またはほかの RM 内の同期エレメントをディスエーブルにするか、リセットに保持する

こともできます。

I/O 規則

UltraScale および UltraScale+ デバイスでは、 I/O ロジックとバッファーを RP に含めることができます。 I/O は 1 つの

RM から別の RM に変更できますが、いくつかの規則に従う必要があります。

I/O サイトを使用するすべてのコンフィギュレーション間で、次のチェックが実行されます。 I/O サイトが使用から

未使用にまたは未使用から使用に変更された場合、これらのチェックはそれらのコンフィギュレーションに対して

は実行されません。 I/O が使用されないコンフィギュレーションがある場合は、これらのポートに PULLTYPE 属性

を使用して適切なプロパティを設定してください。 PULLTYPE の設定に関する詳細は、『Vivado Design Suite プロパ

ティリファレンスガイド』 (UG912) [参照 31] のこのセクションを参照してください。

• I/O が使用されるときは常に、 I/O の方向および規格は、すべての RM で同じにする必要があります。

• DCI_CASCADE では、 RM 間のメンバーバンクの割り当てをオーバーラップさせることはできません。

° 有効な例: コンフィギュレーション 1 では DCI_CASCADE にバンク 12、 13 が含まれ、コンフィギュレー

ション 2 では DCI_CASCADE にバンク 14、 15 および 16 が含まれる場合。この場合、オーバーラップする

バンクはありません。

° 有効な例: コンフィギュレーション 1 では DCI_CASCADE にバンク 12 および 13 が含まれ、コンフィギュ

レーション 2 では DCI_CASCADE にバンク 13、 14、 15 および 16 が含まれる場合。この場合、バンク 13 が

オーバーラップしています。

• DCI_CASCADE では、メンバーバンクをリコンフィギャラブル領域に完全に制約する必要があります。同じ

DCI_CASCADE のすべてのメンバーバンクを同じ RP Pblock または完全にスタティック領域に配置する必要があ

ります。 DCI_CASCADE の使用は、リコンフィギャラブルモジュール間で一貫したものにする必要があります。

1 つのコンフィギュレーションから別のコンフィギュレーションでの IOB の変更は、上記の規則に制限されます。

これは、次の I/O 特性がパーシャルリコンフィギュレーションで変更される可能性を示しています。

• 使用状況 (I/O ごとの使用済み vs 未使用)

• 駆動電流 (12 mA、 8 mA など)

• ドライバー出力インピーダンス (40Ω、 48Ω など)

• ドライバー入力インピーダンス (40Ω、 48Ω など)

• ドライバースルーレート (slow、 fast など)

• ODT 終端 (40、 60 など)



https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug912-vivado-properties.pdf;a=xPULLTYPE



ただし、 I/O サイトを RP に追加する場合、 PU 全体 (I/O バンク、 BITSLICE、 MMCM、 PLL、および CLB の 1 つの列

と共通のインターコネクトを含む) を含める必要があります。この基本的な領域のすべてのコンポーネントはリコン

フィギュレーションおよび再初期化されるので、これらのほかのサイトタイプをリコンフィギャラブル領域に含め

ると便利です。その理由は次のとおりです。

• I/O サイトを追加すると、その I/O の配線リソースを使用できるようになり、密集を緩和できます。 I/O サイト

がスタティック領域に配置されていると、密集が悪化し、リコンフィギャラブル領域にギャップができる可能

性があります。

• MMCM や PLL などのほかのクロックリソースのリコンフィギュレーションが可能になります。

• BITSLICE や BITSLICE_CONTROL などのほかの I/O ロジックサイトのリコンフィギュレーションが可能になり

ます。

リコンフィギュレーション中に I/O の使用や特性が変更されてもされなくても、バンク全体がリコンフィギュレー

ションされます。リコンフィギュレーション中は RP Pblock により定義されるバンクに含まれるすべての I/O が専用

グローバルトライステート (GTS) 信号により保持されます。この信号は、リコンフィギュレーションの後に解放

されます。

リコンフィギャラブルモジュールに MMCM または PLL コンポーネントが含まれている場合、これらのコンポーネ

ントのロックサイクルが待機なしの状態に設定されると、パーシャルビットストリームのサイズが小になりま

す。同様に、 IO と DCI の一致要件は、ロックサイクルが待機なしに設定されると、小のビットストリームサイズ

になります。これらのオプションは次のコマンドを使用して設定します。

set_property BITSTREAM.STARTUP.LCK_CYCLE NoWait [current_design] set_property BITSTREAM.STARTUP.MATCH_CYCLE NoWait [current_design]

パーシャルリコンフィギュレーションフロー中、 RM は update_design -black_box を使用すると区分けされ

ます。このコマンドでは、 PACKAGE_PIN および IOSTANDARD などのエンベデッド IO バッファーおよびそれに関連

する制約がすべて削除されます。ブラックボックス RP に新しい RM が配置されたら、これらの IOB 制約をデザイ

ンに適用し直す必要があります。

高速トランシーバーの使用

ザイリンクス高速トランシーバー (GTH、 GTY) は、リコンフィギャラブルパーティション内でサポートされます。

ほかのリコンフィギャラブルサイトタイプと同様に、 PU 全体を含める必要があります。 UltraScale GT トランシー

バーの PU には、次のものが含まれます。

• 4 つの GT_CHANNEL サイト (GT クワッド )

• 関連の GT_COMMON サイト

• 関連の BUFG_GT_SYNC サイト

• 関連の BUFG_GT サイト

• 関連のインターコネクトおよび CLB サイト

必要な GT PU は、クロック領域の高さ全体です。以前のアーキテクチャと同様に、 GT コンポーネントをスタティッ

クロジックに配置し、その機能を DPR を使用して変更することも可能です。 UltraScale および UltraScale+ トラン

シーバーの使用に関する詳細は、『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576) [参

照 23] および『UltraScale アーキテクチャ GTY トランシーバーユーザーガイド』 (UG578) [参照 24] のを参照してくだ

さい。





UltraScale および UltraScale+ デバイスデザインでのパーシャルリコンフィギュレーションチェックリスト

パーシャルリコンフィギュレーションを使用する UltraScale および UltraScale+ デバイスデザインでは、次の事項が

推奨されます。

クロッキングネットワーク

グローバルクロックバッファーまたはクロック調整ブロック (MMCM、 PLL) を使用していますか。

これらのブロックはリコンフィギュレーション可能ですが、このフレームタイプのすべてのエレメントをリコ

ンフィギュレーションする必要があります。これには、 I/O バンク全体、その共有領域のすべてのクロックエレ

メント、およびインターコネクトを共有する CLB の 1 つの列が含まれます。

詳細は、「リコンフィギャラブルモジュール内のデザインエレメント」を参照してください。グローバルク

ロックのインプリメンテーションの詳細は、「グローバルクロックの規則」を参照してください。

さらに、現在のところ、 Vivado Design Suite の DRC により次の制限が適用されます。 BUFGCTRL、 BUFG_CE、

BUFG_GT のクロッキングリソースの使用はサポートされていますが、次の制限があります。

° 長方形の Pblock を使用することをお勧めします。クロックロジックを含む RP では長方形以外の形状もサ

ポートされますが、 Pblock のも高い列がクロック領域の高さおよび幅に揃っていることが条件です。ま

た、 RP Pblock の一番高い列が IOB を含み、この範囲に RP Pblock を定義する長方形すべての高さが含まれ

ていることも必須条件です (図 7-8 を参照)。つまり、 IOB 範囲の縦の列が Pblock のすべての行にアクセス

できることが必要だということです。横にした L 型の Pblock は、形状の縦の部分に IOB 範囲が含まれる場

合を除き、サポートされません。


図 7-8: Pblock のも高い列がクロック領域に揃っている例





° ギャップは、範囲に含まれているサイトが両側にある範囲に含まれていないサイトタイプとして定義され

ます。次のギャップは許容されません。

- IOB/XIPHY 範囲内のギャップ (図 7-9 に示す IOB 列のギャップなど)。

- DSP 範囲のギャップ。

° 次の場合、 2 つの RP Pblock でクロック領域の形状を指定することはできません。

- 少なくともいずれかの Pblock にグローバルクロックソースが含まれる。

- もう 1 つの Pblock がグローバルクロックソースの範囲を指定する。

コンフィギュレーション機能ブロック

デバイス機能ブロック (BSCAN、 DCIRESET、 FRAME_ECC、 ICAP、 STARTUP、 USR_ACCESS) を使用しています

か。

これらの機能ブロックは、スタティックロジックに配置する必要があります。


Pblock 境界

Pblock 境界は設定しましたか。

UltraScale および UltraScale+ デバイスの場合、 PR 領域の X 軸境界を CLB、ブロック RAM、 DSP などを含む PU

で設定できます。 Pblock は有効な配置になるように Vivado で自動的に調整されます。 PR 領域の Y 軸境界は、

クロック領域および I/O バンクにすることができますが、 BUFGCTRL/BUFG_CE/BUFG_GT が RP で使用される

場合は、フルクロック領域を使用する必要があります。


図 7-9: サポートされない IOB 列内のギャップ





SSI テクノロジ

Pblock は SSI デバイスの SLR をまたぎますか。

SSI デバイスを使用している場合は、 PR 領域を 1 つの SLR 内に収めることを推奨します。ただし、 UltraScale お

よび UltraScale+ デバイスでは、 PR Pblock が 1 つの SLR をまたぐ必要がある場合、この境界を越えて配線できる

よう必要な Laguna サイトを含める必要があります。これには、 SLR 境界の両側の PR 領域に、少なくとも 1 つ

のクロック領域全体が含まれている必要があります。

SSI テクノロジデバイスおよび Laguna の詳細は、『UltraScale アーキテクチャコンフィギャラブルロジックブ

ロックユーザーガイド』 (UG574) [参照 27] の「スタックドシリコンインターコネクト (SSI) テクノロジを使用

するデバイス」セクションを参照してください。

高速トランシーバーブロック

デザインに高速トランシーバーが含まれていますか。

高速トランシーバーはリコンフィギュレーション可能です。すべてのコンポーネントタイプ (GT_CHANNEL、

GT_COMMON、 BUFG_GT) を含むクワッド全体をリコンフィギュレーションする必要があります。

特定の要件は、「高速トランシーバーの使用」を参照してください。

System Generator DSP コア、 HLS コア、または IP インテグレーターブロック図

パーシャルリコンフィギュレーションデザインで System Generator DSP コア、 HLS コア、または IP インテグレー

ターブロック図を使用していますか。

パーシャルリコンフィギュレーションの基本的な要件を満たしていれば、どのタイプのソースでも使用できま

す。 System Generator、 HLS、 IP インテグレーターなどのツールで処理されたコードは終的に合成されます。

結果のデザインチェックポイントまたはネットリストを RP に含めることができるようにするには、リコン

フィギャラブルエレメントのみで構成されるようにする必要があります。

I/O のリコンフィギャラブルパーティションへの配置

リコンフィギャラブルパーティションに I/O が含まれていますか。

I/O をパーシャルリコンフィギュレーションできます。 I/O バンク全体を、すべての I/O ロジック (XiPhy) および

クロックリソースと共にリコンフィギュレーションする必要があります。 IOSTANDARD および方向は変更で

きず、 DCI カスケード規則に従う必要がありますが、その他の IO 特性は RM から次の RM に変更できます。


ロジックのリコンフィギャラブルパーティションへの配置

一緒に配置する必要のあるロジックが同じリコンフィギャラブルパーティションに配置されていますか。

一緒に配置する必要のあるロジックは、同じ RP および RM に配置する必要があります。






クリティカルパスのリコンフィギャラブルパーティションへの配置

クリティカルパスが同じパーティション内に制約されていますか。

リコンフィギャラブルパーティションの境界では適化およびパックに制限があるので、クリティカルパスは

同じパーティション内に制約する必要があります。


フロアプラン

リコンフィギャラブルパーティションを効率的にフロアプランできますか。

詳細は、「UltraScale および UltraScale+ デバイスでの Pblock の作成」を参照してください。

デカップリングロジックの使用 (推奨)

RM の出力にデカップリングロジックを作成しましたか。

リコンフィギュレーション中、 RP の出力は不定の状態になるので、スタティックデータが破損するのを回避す

るためデカップリングロジックを使用する必要があります。

詳細は、「デカップリング機能」を参照してください。

リコンフィギュレーション後にリセットを適用 (推奨)

リコンフィギュレーション後に RAM のロジックをリセットしていますか。

リコンフィギュレーション後にリセットは、 UltraScale および UltraScale+ デバイスでは常にイネーブルになって

います。

詳細は、「リコンフィギュレーション後にリセットを適用」を参照してください。

ロジック解析ブロックを使用したデバッグ

パーシャルリコンフィギュレーションで Vivado ロジック解析を使用していますか。

Vivado ロジック解析 (ILA/VIO デバッグコア) はパーシャルリコンフィギュレーションデザインで使用できます

が、これらのコアをデバッグハブに接続する際には注意が必要です。「Vivado デバッグコアの使用」に説明す

る自動推論ソリューションを使用してください。

効率的なリコンフィギャラブルパーティション Pblock

デザインに対して効率的なリコンフィギャラブルパーティション Pblock を作成していますか。

リコンフィギャラブルパーティション Pblock の高さに制限はありませんが、複数のリコンフィギャラブルパー

ティションを 1 つのクロック領域内で縦に並べることはできません。

詳細は、「UltraScale および UltraScale+ デバイスでの Pblock の作成」を参照してください。






コンフィギュレーション間の一貫性はどのように検証しますか。

pr_verify コマンドを使用して、すべてのコンフィギュレーションのインポートされるリソースに一致してい

ることを確認できます。

詳細は、「コンフィギュレーションの検証」を参照してください。

コンフィギュレーションの要件

デザインおよびデバイスにおけるパーシャルリコンフィギュレーションに特定のコンフィギュレーション要件があ

ることを理解していますか。

各デバイスファミリに特定のコンフィギュレーション要件および考慮事項があります。

詳細は、「デバイスのコンフィギュレーション」を参照してください。




第 8 章

デバイスのコンフィギュレーション

概要

この章では、デバイスをパーシャル BIT ファイルでコンフィギュレーションする際のシステムデザインに関する考

慮事項と、パーシャルリコンフィギュレーションに便利な FPGA のアーキテクチャ機能について説明します。パー

シャルリコンフィギュレーションはほとんどの点で標準のコンフィギュレーションと同じなので、このセクション

では PR 特定の詳細についてのみ説明します。

コンフィギュレーションモード

パーシャルリコンフィギュレーションでは、次のコンフィギュレーションモードがサポートされています。

• ICAP: ユーザーコンフィギュレーションソリューションに適したモードです。 ICAP コントローラーと ICAP イ

ンターフェイスを作成する必要があります。

• MCAP: (UltraScale™ および UltraScale+™ デバイスのみ) デバイスに含まれる特定の 1 つの PCIe® ブロックから

ICAP に専用接続を提供します。

• PCAP: Zynq-7000 SoC および Zynq UltraScale+ デザインの主なコンフィギュレーション方法です。

• JTAG: テストまたはデバッグを実行するのに適したインターフェイスです。 Vivado ロジック解析で駆動可能です。

• スレーブ SelectMAP またはスレーブシリアル: 同じインターフェイスでフルコンフィギュレーションおよび

パーシャルリコンフィギュレーションを実行するのに適したモードです。

マスターモードは、 IPROG によりコンフィギュレーションメモリがクリアされるので、直接サポートされていま

せん。




第 8 章: デバイスのコンフィギュレーション

パーシャル BIT ファイルを読み込むのに JTAG 以外の外部コンフィギュレーションモード使用するには、これらの

ピンを初期デバイスコンフィギュレーション後に使用できるよう予約する必要があります。これには

BITSTREAM.CONFIG.PERSIST プロパティを使用して多目的 I/O をコンフィギュレーションで使用するよう保持

し、コンフィギュレーション幅を設定します。詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデ

バッグ』 (UG908) [参照 25] のこのセクションを参照してください。このプロパティを設定する Tcl コマンドは次のよ

うになります。

set_property BITSTREAM.CONFIG.PERSIST <value> [current_design]

<value> には、 No または Yes を入力します。

注記: コンフィギュレーションピンが保持される場合は、 ICAP はディスエーブルになります。この 2 つの機能を同

時に使用することはできません。 ICAP の詳細は、ご使用のデバイスによって『7 シリーズ FPGA コンフィギュレー

ションユーザーガイド』 (UG470) [参照 7] または『UltraScale アーキテクチャコンフィギュレーションユーザーガイ

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

パーシャルビットストリームには、パーシャルリコンフィギュレーションに必要なコンフィギュレーションコマン

ドおよびデータがすべて含まれています。パーシャルビットストリームにコンフィギュレーションフレームのアド

レス指定情報が含まれているので、パーシャルビットストリームを FPGA に読み込む際に RM の物理位置を指定す

る必要はありません。有効なパーシャルビットストリームが FPGA の間違った場所に送信されることはありません。

パーシャルリコンフィギュレーションコントローラーによりメモリからパーシャルビットストリームが取り出さ

れ、コンフィギュレーションポートに配布されます。パーシャルリコンフィギュレーション制御ロジックは、外部

デバイス (プロセッサなど) またはリコンフィギュレーションする FPGA のプログラマブルロジックに配置できます。

ユーザーが設計した内部 PR コントローラーにより、 ICAP インターフェイスを介してパーシャルビットストリーム

が読み込まれます。スタティックデザインのほかのロジックと同様、内部パーシャルリコンフィギュレーション制

御回路は、パーシャルリコンフィギュレーションプロセス中、割り込みなしで動作します。

内部コンフィギュレーションには、カスタムステートマシンまたは MicroBlaze™ などのエンベデッドプロセッサを

含めることができます。 Zynq-7000 AP および MPSoC では、プロセッササブシステム (PS) を使用してパーシャルリ

コンフィギュレーションイベントを制御できます。

表 8-1: サポートされるコンフィギュレーションポート


7 シリーズ Zynq UltraScale UltraScale+ Zynq UltraScale+ MPSoC

JTAG ありありありありあり

ICAP ありありありありあり

PCAP 該当なしあり該当なし該当なしあり

MCAP 該当なし該当なしありありあり

スレーブシリアルあり該当なしありあり該当なし

スレーブ SelectMap あり該当なしありあり該当なし

SPI (任意の幅)*

*. パーシャルビットストリームの格納には SPI および BPI フラッシュを使用できますが、 UltraScale+ より前のデバイスではパー

シャルビットストリームをコンフィギュレーションエンジンに送信するために STARTUP プリミティブは使用できません。ス

タティックデザインの場合は、ユーザー IO を介してフラッシュに接続する必要があり、コントローラーを使用すると、ビット

ストリームをフェッチして、 ICAP に送信できます。

なし該当なしなしあり該当なし

BPI sync モード * なし該当なしなしあり該当なし

BPI async モードあり該当なしありあり該当なし

マスターモードなし該当なしなしなし該当なし


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




注記: Zynq-7000 SoC デバイスでは、プログラマブルロジック (PL) はパーシャルリコンフィギュレーションできます

が、プロセッシングシステムはできません。

パーシャルリコンフィギュレーションデザインおよび PR 制御ロジックをデバッグするため、 Vivado® ロジック解

析を使用して、 JTAG ポートを介してフルビットストリームまたはパーシャルビットストリームを FPGA に読み込

むことができます。

ビットストリームをコンフィギュレーションポートに読み込む方法の詳細は、次の資料の「コンフィギュレーショ

ンインターフェイス」の章を参照してください。

• 『7 シリーズ FPGA コンフィギュレーションユーザーガイド』 (UG470) [参照 7]

• 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 8]

• 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 9]

ビットストリームタイプの定義

ザイリンクスデバイスでパーシャルリコンフィギュレーション用にデバイスをコンパイルする場合、異なるタイプ

のビットストリームが作成されます。このセクションでは、 7 シリーズおよび UltraScale デバイス用のビットスト

リームの各タイプを詳しく説明し、その用語を定義します。ビットストリームのタイプには次のものがあります。

• 「フルコンフィギュレーションビットストリーム」

• 「パーシャルビットストリーム」

• 「ブランキングビットストリーム」

• 「クリアビットストリーム」

フルコンフィギュレーションビットストリーム

PR デザインはすべて、フルコンフィギュレーションビットストリームを使用して、フルデバイスの標準コンフィ

ギュレーションから始めます。フォーマットおよび構造はフラットデザインソリューションと同じで、 FPGA の初

期プログラムにこのビットストリームをどのように使用できるかにおいても違いはありません。ただし、フルプロ

グラムが実行された後、デバイスのパーシャルリコンフィギュレーションの準備のため、デザイン自体が処理され

る点に注意してください。暗号化や圧縮などの標準機能はサポートされます。

ブラックボックスとして設定されているリコンフィギャラブルパーティション (RP) がサポートされているため、機

能のないリコンフィギャラブルモジュール (RM) を初回コンフィギュレーションの一部として配布できます。これ

は後で必要な RM に置き換えることができます。ビットストリーム圧縮はこの場合効果的で、ビットストリームの

サイズおよび初回コンフィギュレーションにかかる時間を削減できます。





フル BIT ファイルのダウンロード

デジタルシステムの FPGA は、パワーオンリセット後に、直接 PROM から、またはマイクロプロセッサにより汎用

メモリ空間からフル BIT ファイルをダウンロードすることによりコンフィギュレーションします。フル BIT ファイ

ルには、 FPGA をリセットし、完全なデザインでコンフィギュレーションし、 BIT ファイルが破損していないことを

検証するのに必要な情報がすべて含まれています。次の図はこのプロセスを説明しています。

初期コンフィギュレーションが完了し、検証されたら、 FPGA はユーザーモードになり、ダウンロードされたデザ

インが動作し始めます。 BIT ファイルが破損していることが検出された場合は、 DONE 信号はアサートされず、

FPGA はユーザーモードになることはないので、破損したデザインが動作し始めることはありません。

パーシャルビットストリームパーシャルビットストリームは、あらかじめ定義されているデバイス領域の機能を置き換えるため、標準デバイス

操作中に配布されます。これらのビットストリームの構造はフルビットストリームのものと同じですが、デバイス

の特定エリアをプログラムするため特定アドレスセットに限定されています。フレームごとの CRC チェック (ビッ

トストリームインテグリティのため) や自動初期化 (領域が既知のステートで始まるようにするため) などの専用 PR

機能が利用でき、また暗号化や圧縮などのフルビットストリーム機能も利用できます。

パーシャルビットストリームのサイズは、リコンフィギュレーションする領域のサイズに直接比例しています。た

とえば、リコンフィギャラブルパーティションがデバイスリソースの 20% を占めている場合、パーシャルビット

ストリームはフルビットストリームの約 20% になります。

パーシャルビットストリームは完全自己完結型であるため、適切なコンフィギュレーションポートに配布されま

す。フルコンフィギュレーションビットストリームの場合と同じように、アドレス指定、ヘッダー、フッターのす

べての詳細がこれらのビットストリームに含まれています。パーシャルビットストリームは、 JTAG やスレーブシ

リアル、スレーブ SelectMap などの外部非コンフィギュレーションモードで FPGA に配布されます。初回コンフィ

ギュレーションアクセスには、 ICAP (すべてのデバイス)、 PCAP (Zynq-7000 SoC デバイス)、および MCAP (PCIe を

介した UltraScale および UltraScale+ デバイス) が含まれます。

パーシャルビットストリームは、 write_bitstream が PR コンフィギュレーションで実行されると、自動的に作成

されます。各パーシャルビットストリームのファイル名は、上位デザイン名にリコンフィギャラブルパーティ

ションの Pblock 名と _partial が追加されたものになります。たとえば、フルデザイン BIT ファイル

top_first.bit の場合、パーシャル BIT ファイルの名前は top_first_pblock_red_partial.bit になります。


図 8-1: フル BIT ファイルでのコンフィギュレーション





推奨: Pblock インスタンス内に含まれている RM に関係なく Pblock インスタンスは常に同じなので、わかりやすい基

本コンフィギュレーション名を使用するか、またはどのモジュールなのかを明確にするためパーシャル BIT ファイ

ルの名前を変更することを推奨します。

パーシャル BIT ファイルのダウンロード

パーシャルリコンフィギュレーションされる FPGA は、パーシャル BIT ファイルの読み込み中、ユーザーモードで

す。これにより、リコンフィギャラブル部分が変更されている間、 FPGA ロジックのリコンフィギュレーションされ

ない部分は動作し続けることができます。図 8-2 にこのプロセスを示します。

パーシャル BIT ファイルには簡略化されたヘッダーが含まれており、 FPGA をユーザーモードにするスタートアッ

プシーケンスはありません。 BIT ファイルには、デフォルト設定ではフレームアドレスとコンフィギュレーション

データ、および終チェックサム値がのみが含まれます。必要に応じて、ビットストリームのインテグリティ

チェック用に追加の CRC チェックを挿入できます。

リコンフィギュレーション後にリセットを適用する機能を使用している場合、リコンフィギュレーションが開始し

たときに DONE ピンが Low になり、パーシャルリコンフィギュレーションが正しく完了すると High になります。

パーシャルビットストリームは、内部で監視することもできます。

注記: UltraScale デバイスの場合は、 2 つのビットストリームによりパーシャルリコンフィギュレーションシーケン

スが構成されるので、クリアビットストリームの始めに DONE ピンが Low になり、パーシャルビットストリーム

の後まで Low のままになります。 DONE ピンはクリアビットストリームの後に High には戻りません。

リコンフィギュレーション後にリセットを適用する機能を使用していない場合、コンフィギュレーションがいつ完

了したかを知るためデータを監視する必要があります。パーシャル BIT ファイルの後には DESYNCH ワード

(0000000D) があり、コンフィギュレーションエンジンに BIT ファイルの送信が完了したことを示します。このワー

ドは、一連のパディング NO OP コマンドの後に挿入されており、 DESYNCH に到達したときにはすべてのコンフィ

ギュレーションデータがデバイス全体のターゲットフレームに既に送信されていることになります。パーシャル

BIT ファイル全体がコンフィギュレーションポートに送信されたら、リコンフィギュレーションされた領域をアク

ティブにできます。


図 8-2: パーシャル BIT ファイルでのコンフィギュレーション





ブランキングビットストリーム

ブランキングビットストリームは、特定タイプのパーシャルビットストリームで、論理ブラックボックスを表しま

す。これは完全に空ではないので、 Vivado ではグレーボックスと呼ばれます。これは既存のリコンフィギャラブル

モジュールの機能を新しい機能に置き換えたもので、すべての該当モジュール I/O の接続した LUT から構成された

単純なものです。

グレーボックスのリコンフィギャラブルモジュールを作成するには、完全に配置配線されたデザインコンフィギュ

レーションの論理および物理記述を削除して、接続された LUT に置き換えます。使用しているメモリにある配線済

みコンフィギュレーション (スタティックデザインがロックされている状態) で、次のステップを実行します。

update_design -cell <foo> -black_box update_design -cell <foo> -buffer_portsplace_designroute_design

デザインに挿入されている LUT をインプリメントするには、デザインを配置配線する必要があります。グレーボッ

クス RM の出力はデフォルトでグランドに接続されていますが、ポートに HD.PARTPIN_TIEOFF を設定することに

より Vcc に設定できます。

圧縮を使用すると、ブランキングビットストリームのサイズを大幅に削減できます。これらのビットストリームに

は、接続された LUT だけでなく、 FPGA のこの領域を通過するスタティック配線も含まれています。グレーボック

スバージョンは別のコンフィギュレーションチェックポイントとして保存され、ブランキングビットストリームは

標準パーシャルビットストリームと同じ方法で生成されて名前が付けられます。

Vivado ソフトウェアの以前のバージョンでは、グリッチが発生する可能性を回避するため、 7 シリーズと Zynq デバ

イスにブランキングビットストリームを使用することが推奨されていました。 Vivado 2016.1 からは、各パーシャル

ビットストリームに特定のブランキングイベントを挿入することで、このようなまれなグリッチ状況は自動的に回

避されるようになっています。ブランキングビットストリームは、リコンフィギャラブルパーティションからロ

ジックを削除するためには使用できますが、グリッチイベントを回避するために使用する必要はありません。ブラ

ンキングイベントを自動的に組み込むとパーシャル BIT ファイルのサイズが増加します。圧縮を使用してこの増加

を抑えることができます。

クリアビットストリーム

前述のビットストリームタイプとは異なり、このタイプは UltraScale デバイス専用です。 UltraScale+ にはこの要件

はありません。このアーキテクチャには、新しいモジュールを読み込む前に既存モジュールを消去しなければなら

ないという要件が新しく追加されています。クリアビットストリームは、リコンフィギュレーションする領域のグ

ローバル信号マスクを確立することにより、リコンフィギャラブルパーティションの次のパーシャルビットスト

リームを配布できるようにします。正確には既存のモジュールが削除されるわけではありませんが (論理モジュール

は残っている )、そう考えると理解しやすいです。クリアビットストリームが配布されない場合、次のリコンフィ

ギャラブルモジュールは初期化されません。

クリアビットストリームはパーシャルビットストリームではありません。このビットストリームは、ターゲット領

域のフレームの 10% 未満しか占めず、対応するパーシャルビットストリームのサイズの 10% 未満です。機能は変更

しませんが、領域のロジックを駆動するクロックをシャットダウンします。クリアビットストリームは、パーシャ

ルビットストリームの間に配布する必要があり、できるだけ間を置かずに次のパーシャルビットストリームを配布

する必要があります。





各クリアビットストリームは、特定のリコンフィギャラブルモジュール用に作成されており、そのモジュールが使

用された後に適用する必要があり、次のパーシャルビットストリームが配布される直前にコンフィギュレーション

エンジンに送信する必要があります。たとえば、モジュール A からモジュール B に変更するには、 A のクリアビッ

トストリームを、 B のパーシャルビットストリームが配布される直前に配布する必要があります。モジュール B か

らモジュール A に戻すには、 B のクリアビットストリームを A のパーシャルビットストリームが配布される直前に

配布する必要があります。パーシャルビットストリームがブランキングビットストリームであっても、この規則に

従います。

クリアビットストリームは自動的に生成され、名前はパーシャルビットストリームの名前に _clear が付いたもの

になります。上記の例の場合、 UltraScale デバイスデザインが top_first であるとすると、クリア BIT ファイル名

は top_first_pblock_red_partial_clear.bit になります。

ICAP を介したパーシャルリコンフィギュレーション (Zynq デバイス)Zynq-7000 および Zynq MPSoC デバイスのプログラマブルロジック (PL) の主なコンフィギュレーションメカニズム

は、プロセッシングシステム (PS) を介したもので、 PCAP にビットストリームが配布されます。これが、パーシャ

ルリコンフィギュレーションのも一般的なメカニズムです。 PR Controller IP またはカスタムデザインのコント

ローラーモジュールを介してパーシャルリコンフィギュレーションを PL 内で完全に管理するため、FPGA デバイス

の場合と同様に、パーシャルビットストリームも ICAP に配布できます。

PCAP と ICAP を同時に使用することはできません。 ICAP と PCAP を切り替えることは可能ですが、インターフェイ

スを変更する前に、コマンドまたはデータが送信または受信中でないことを確認する必要があります。この確認を

怠ると、予期せぬ動作が発生する可能性があります。

Zynq-7000 デバイスで ICAP をイネーブルにするには、制御レジスタ (devc.CTRL) のビット 27 (PCAP_PR) を設定し

ます。このビットは、PL リコンフィギュレーションに対して ICAP または PCAP を選択します。デフォルトは PCAP

(1) ですが、このコンフィギュレーションポートをイネーブルにするため、 ICAP (0) に変更できます。ビット 28

(PCAP_MODE) も 1 に設定する必要があります (1 がデフォルト値)。詳細は、『Zynq-7000 SoC テクニカルリファレン

スマニュアル』 (UG585) [参照 9] を参照してください。

Zynq MPSoC デバイスで ICAP をイネーブルにするには、 pcap_ctrl (CSU) レジスタの PCAP_PR フィールドを設定

します。このビットは、 PL リコンフィギュレーションに対して ICAP (または MCAP) あるいは PCAP を選択します。

デフォルトは PCAP (1) ですが、このコンフィギュレーションポートをイネーブルにするため、 ICAP/MCAP (0)

に変更できます。詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 32] および

『Zynq UltraScale+ MPSoC レジスタリファレンス』 (UG1087) [参照 33] を参照してください。





Tandem コンフィギュレーションおよびパーシャルリコンフィギュレーション

UltraScale デバイスには、デバイス上にある特定の 1 つの PCIe ブロックからコンフィギュレーションエンジンへの

専用接続である MCAP が導入されており、パーシャルビットストリームを効率的に配布できます。 PCIe ブロックを

コンフィギュレーションエンジンに接続するのに明示的な配線は必要なく、リソースを大幅に節約できます。

MCAP は、パーシャルリコンフィギュレーションまたは Tandem コンフィギュレーション機能を使用してザイリン

クス PCIe IP をカスタマイズするとイネーブルになります。これらの機能は、 PCI Express をサポートする次の 3 つの

IP コアで使用できます。

• 『UltraScale Architecture Gen3 Integrated Block for PCI Express 製品ガイド』 (PG156) [参照 14]

注記: この資料には、主な Tandem および PR ソリューションが含まれます。

• 『AXI Bridge for PCI Express Gen3 Subsystem 製品ガイド』 (PG194) [参照 26]

• 『DMA/Bridge Subsystem for PCI Express 製品ガイド』 (PG195) [参照 29]

• 『UltraScale+ Devices Integrated Block for PCI Express 製品ガイド』 (PG213) [参照 30]

Tandem コンフィギュレーションでは、 IP をイネーブルにする 2 段階の手法を使用して、 PCI Express 仕様で示される

コンフィギュレーション時間の要件が満たされます。次のユースケースでは、この手法がサポートされています。

• Tandem PROM: フラッシュから 1 つの 2 段階ビットストリームを読み込みます。

• Tandem PCIe: フラッシュから 1 段階目のビットストリームを読み込んで、 2 段階目のビットストリームを PCIe

リンクを介して MCAP へ送信します。

• フィールドアップデートを使用した Tandem: Tandem PROM (UltraScale のみ) または Tandem PCIe (UltraScale ま

たは UltraScale+) 初期コンフィギュレーションの後、 PCIe リンクはアクティブのまま、ユーザーデザイン全体

をアップデートします。アップデート領域 (フロアプラン) およびデザイン構造は前もって定義されています。

Tcl スクリプトは提供されています。

• Tandem + パーシャルリコンフィギュレーション: これはより一般的な例で、 Tandem コンフィギュレーションの

後にパーシャルリコンフィギュレーション (PR) (あらゆるサイズまたは数の PR 領域) を実行します。

• PCIe を使用したパーシャルリコンフィギュレーション: PCIe/MCAP をパーシャルビットストリームの配信パス

として使用して、標準コンフィギュレーションの後 PR を実行します。

Tandem とパーシャルリコンフィギュレーションのソリューションには、その他の要件があります。このアプローチ

には、 HD.TANDEM_IP_PBLOCK の Pblock とデザインの HD.RECONFIGURABLE 部分が重ならないようにする必要が

あります。標準 PR デザインなど、それ以外の場合、どの数またはサイズのリコンフィギュレーションパーティ

ションでも定義できます。





これらの機能をイネーブルにするには、コアをカスタマイズする際に適切なオプションを選択してください。

[Basic] タブで次を実行します。

1. [Mode] を [Advanced] に変更します。

2. UltraScale の場合、 [Tandem Configuration or Partial Reconfiguration] オプションを次のいずれかに変更します。

° [Tandem]: Tandem PROM、 Tandem PCIe、または Tandem + パーシャルリコンフィギュレーションの場合

° [Tandem with Field Updates]: 定義済みフィールドアップデートの場合

° [PR over PCIe]: Tandem コンフィギュレーションをイネーブルにせず、パーシャルコンフィギュレーション

用に MCAP リンクをイネーブルにする場合

3. UltraScale+ の場合、 [Tandem Configuration or Partial Reconfiguration] オプションを次のいずれかに変更します。

° [Tandem PROM]: Tandem PROM または Tandem + パーシャルリコンフィギュレーションの場合

° [Tandem PCIe]: Tandem PCIe または Tandem + パーシャルリコンフィギュレーションの場合

° [Tandem PCIe with Field Updates]: 定義済みフィールドアップデートの場合のみ。 Tandem PROM では

UltraScale+ のフィールドアップデートはサポートされません。

° [PR over PCIe]: Tandem コンフィギュレーションをイネーブルにせず、パーシャルコンフィギュレーション

用に MCAP リンクをイネーブルにする場合


ほとんどの場合、選択する必要のある PCIe ブロックはデバイスの下位インスタンスですが、 3 つの SLR (Super

Logic Region) を持つ SSI デバイスでは中央の SLR の下位 PCIe インスタンスです。次の表 8-2 は、各デバイスでサ

ポートされているブロックを示しています。その他の PCIe ブロックには、専用 MCAP 機能はありません。

必要な PCIe ブロックロケーション、デザインフロー例、要件、制限事項、推奨事項などの Tandem コンフィギュ

レーションの詳細は、 UltraScale デバイスの場合は『UltraScale Architecture Gen3 Integrated Block for PCI Express』

(PG156) [参照 14] のこのセクションを、 UltraScale+ デバイスの場合は『UltraScale+ Devices Integrated Block for PCI

Express 製品ガイド』 (PG213) [参照 30] を参照してください。

.


図 8-4: [Basic] タブでのコアのカスタマイズ

表 8-2: UltraScale: デバイス別の PR をサポートする PCIe ブロックおよびリセットロケーション

デバイスパッケージ PCIe ブロックPCIe リセットロケー

ションステータス

Kintex® UltraScale

XCKU025 PCIE_3_1_X0Y0 IOB_X1Y103 プロダクション




https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie3_ultrascale;v=latest;d=pg156-ultrascale-pcie-gen3.pdf;a=xTandemConfiguration








Virtex® UltraScale

XCVU065 PCIE_3_1_X0Y0 IOB_X1Y103 プロダクション







表 8-3: UltraScale+: デバイス別の PR をサポートする PCIe ブロックロケーション

デバイスパッケージ PCIe ブロックステータス*

*. フィールドアップデートのない AXI ストリーミング用。このコアでは、すべてのデバイスでフィールドアップデートがベー

タでサポートされます。このコアの DMA バージョンでは、 VU13P、 VU9P、 VU7P、 VU3P、 KU15P、 ZU19EG デバイスがサ

ポートされます。

Kintex® UltraScale+

KU3P PCIE40E4_X0Y0 プロダクション




Virtex® UltraScale+

VU3P PCIE40E4_X1Y0 プロダクション






Zynq MPSoC

ZU4EV/EG/CC PCIE40E4_X0Y1 プロダクション



ZU11EG PCIE40E4_X1Y0 プロダクション



表 8-2: UltraScale: デバイス別の PR をサポートする PCIe ブロックおよびリセットロケーション (続き)

デバイスパッケージ PCIe ブロックPCIe リセットロケー

ションステータス





注記: この表にリストされていないデバイスのプログラマブルロジック部分には PCIe サイトはありません。

UltraScale とは異なり、 UltraScale+ には PCIe リセットピンへの専用接続はありませんが、バンク 65 のピンを使用す

ることを推奨します。

MCAP は、 32 ビットデータパスで 200 MHz で動作できます。通常、ビットストリームはホスト PC から PCI Express

コンフィギュレーションパケットを介して MCAP に読み込まれます。これらのシステムでは、ホスト PC およびホ

スト PC ソフトウェアが MCAP パフォーマンスおよびビットストリームのスループットを制限する主な要因です。

特定のホスト PC およびホスト PC ソフトウェアの PCIe パフォーマンスはシステムによって大きく異なるので、全体

的な MCAP パフォーマンススループットも大きく異なる可能性があります。

詳細およびサンプルドライバーは、アンサーレコードの「UltraScale デバイスにおける Tandem PCIe およびパーシャ

ルリコンフィギュレーションを使用した PCI Express リンクでのビートストリームの読み込み」 (ザイリンクスアン

サー 64761) [参照 5] を参照してください。

内部コンフィギュレーションポートに配布するための BIN ファイルのフォーマット

パーシャル BIT ファイルの基本フォーマットはフル BIT ファイルのものと同じですが、パーシャル BIT ファイルは

ターゲット領域のコンフィギュレーションフレームセットに縮小されており、アクティブデバイスのイベント

セットに制限されています。パーシャル BIT ファイルでは次のことが可能です。

• JTAG やスレーブコンフィギュレーションポートなどの外部インターフェイスに配布可能。

• 内部コンフィギュレーションポート ICAP (7 シリーズまたは UltraScale デバイス)、 PCAP (Zynq デバイスのみ)

または MCAP (UltraScale デバイスのみ) に配布するため BIN ファイルにリフォーマット可能。

BIN ファイルは write_cfgmem ユーティリティを使用して生成します。次の 3 つの重要なオプションがあります。

• このファイルタイプを生成するには、 -format を BIN に設定します。

• SelectMap 幅を選択するには -interface を使用し、 PCAP には SMAPx32、 UltraScale ICAP には MCAP を使用

します。

° SMAPx16 および SMAPx8 (デフォルト ) は、 7 シリーズ ICAP にも使用できます。

° SMAPx8 は 7 シリーズの暗号化されたパーシャルビットストリームに必要です。

• PCAP または MCAP をターゲットにするには、 -disablebitswap を使用する必要があります。

例

ICAP (7 シリーズデバイス)

write_cfgmem -format BIN -interface SMAPx8 -loadbit "up 0x0 <partial_bitfile>”

ICAP (UltraScale デバイス)

write_cfgmem -format BIN -interface SMAPx32 -loadbit "up 0x0 <partial_bitfile>”





PCAP (Zynq-7000 SoC デバイス) または MCAP (UltraScale デバイスごとに 1 つの PCIe ブロックを使用する場合)

write_cfgmem -format BIN -interface SMAPx32 -disablebitswap -loadbit "up 0x0 <partial_bitfile>”

UltraScale デバイスでの BIT ファイルのサマリ

このセクションは UltraScale デバイスにのみ該当し、 7 シリーズ、 UltraScale+、 Zynq、 Zynq MPSoC デバイスは対象

外です。グローバル信号 (GSR) の適用を詳細に制御でき、新しいエレメントタイプをリコンフィギュレーションで

きるので、新しいコンフィギュレーションプロセスが必要です。新しいリコンフィギャラブルモジュールのパー

シャルビットストリームを読み込む前に、既存のリコンフィギャラブルモジュールをクリアする必要があります。

クリアビットストリームは、リコンフィギュレーションする領域のグローバル信号マスクを確立することにより、

リコンフィギャラブルパーティションの次のパーシャルビットストリームを配布できるようにします。正確には既

存のモジュールが削除されるわけではありませんが、そう考えると理解しやすいです。

リコンフィギャラブルパーティションを含むデザインコンフィギュレーションで write_bitstream コマンドを

実行すると、 RP ごとにクリア BIT ファイルが作成されます。たとえば、 2 つのリコンフィギャラブルパーティショ

ン (RP1 および RP2) にそれぞれ 2 つずつリコンフィギャラブルモジュール (RP1 用に A1 と B1、 RP2 用に A2 と B2)

があるデザインを考えてみます。 2 つのコンフィギュレーション (configA および configB) を配置配線まで実行し、

pr_verify での検証も完了しており、問題は検出されていません。ビットストリームを生成すると、各コンフィ

ギュレーションに対して 5 つのビットストリームが生成されます。 configA に対しては、次のようなビットストリー

ムファイルが生成されます。

• configA.bit: 電源投入時にデバイスのコンフィギュレーションに使用される完全なデザインビットストリー

ム。スタティックデザインとファンクション A1 および A2 が含まれます。

• configA_RP1_A1_partial.bit: ファンクション A1 用の BIT ファイル。このリコンフィギャラブルパー

ティションから RM がクリアされた後に読み込まれます。

• configA_RP1_A1_partial_clear.bit: ファンクション A1 用のクリア BIT ファイル。ファンクション A1

の後、 RP1 にほかのパーシャル BIT ファイルを読み込む前にこのファイルを読み込む必要があります。

• configA_RP2_A2_partial.bit: ファンクション A2 用の BIT ファイル。このリコンフィギャラブルパー


• configA_RP2_A2_partial_clear.bit: ファンクション A2 用のクリア BIT ファイル。ファンクション A2


同様に、 configB に対しても 5 つのビットストリームが生成されます。

• configB.bit: 電源投入時にデバイスのコンフィギュレーションに使用される完全なデザインビットストリー

ム。スタティックデザインとファンクション B1 および B2 が含まれます。

• configB_RP1_B1_partial.bit: ファンクション B1 用の BIT ファイル。このリコンフィギャラブルパー


• configB_RP1_B1_partial_clear.bit: ファンクション B1 用のクリア BIT ファイル。ファンクション B1


• configB_RP2_B2_partial.bit: ファンクション B2 用の BIT ファイル。このリコンフィギャラブルパー






• configB_RP2_B2_partial_clear.bit: ファンクション B2 用のクリア BIT ファイル。ファンクション B2


リコンフィギュレーションのシーケンスは、まず現在のリコンフィギャラブルモジュールにクリア BIT ファイルを

読み込み、その直後に新しいリコンフィギャラブルモジュールを読み込みます。たとえば、リコンフィギャラブル

パーティション RP1 をファンクション A1 からファンクション B1 に変更するには、まずクリア BIT ファイル

configA_RP1_A1_partial_clear.bit を読み込み、その後 configB_RP1_B1_partial.bit を読み込みま

す。初のビットストリームはマスクを開いて領域を準備し、 2 番目のビットストリームは新しいファンクションを

読み込んでその領域のみを初期化し、マスクを閉じます。

クリア BIT ファイルを読み込まないと、初期化ルーチン (GSR) で何も実行されません。異なるリコンフィギャラブ

ルパーティションのクリア BIT ファイルが読み込まれると、リコンフィギュレーションされたパーティションでは

なくその RP が初期化されます。正しい RP に間違ったクリア BIT ファイルが使用されると、次のパーシャル BIT

ファイルが読み込まれるまで、現在の RM またはスタティックデザインが変更される可能性があります。

FPGA をコンフィギュレーションするシステムデザイン

パーシャル BIT ファイルは、フル BIT ファイルと同様に FPGA にダウンロードできます。外部マイクロプロセッサ

により、どのパーシャル BIT ファイルをダウンロードすべきか、その BIT ファイルが外部メモリ空間のどこにある

かが判断され、パーシャル BIT ファイルが JTAG、 Select MAP、シリアルインターフェイスなどの標準 FPGA コン

フィギュレーションポートに送信されます。 FPGA は、パーシャル BIT ファイルを受信しているという特別な指示

なしで、パーシャル BIT ファイルを正しく処理します。

フル BIT ファイルをダウンロードする前には、通常 FPGA コンフィギュレーションインターフェイスの INIT または

PROG 信号をアサートします。パーシャル BIT ファイルをダウンロードする前に、これを実行しないでください。

INIT または PROG 信号をアサートすると、パーシャル BIT ファイルでなくフル BIT ファイルが送信されます。

動作中のデザインにパーシャル BIT ファイルが送信されることを示す (イネーブル信号を保持、クロックをディス

エーブルにするなど) には、専用 FPGA コンフィギュレーションピンを使用するのではなく、デザイン内で実行する

必要があります。図 8-5 に、マイクロプロセッサを介したコンフィギュレーションプロセスを示します。





パーシャルリコンフィギュレーションでは、標準コンフィギュレーションインターフェイスに加え、内部コンフィ

ギュレーションアクセスポート (ICAP) によるコンフィギュレーションがサポートされています。 ICAP プロトコル

は SelectMAP と同じで、ターゲットデバイスのコンフィギュレーションユーザーガイドに説明されています。

FPGA デザインの HDL 記述に ICAP ライブラリプリミティブをインスタンシエートし、パーシャル BIT ファイルを

コンフィギュレーションポートに送信する前に解析および制御できます。パーシャル BIT ファイルは、汎用 I/O ま

たはギガビットトランシーバーを介して FPGA にダウンロードし、その後 FPGA プログラマブルロジックの ICAP

に転送できます。

PR ポートとフォーマットの規則:

• 暗号化されたパーシャルビットストリームは、初期コンフィギュレーションも暗号化されている場合にのみ、

どのポートにも送信できます。すべてのビットストリームに同じキーを使用する必要があります。

• デバイスの初期ビットストリームが暗号化されている場合、暗号化されていないパーシャルビットストリーム

は ICAP にのみ送信できます。

• パーシャルビットストリームの認証は、 Virtex および Kintex デバイスではサポートされておらず、 Zynq デバイ

スでのみサポートされます。

• 暗号化 7 シリーズ BIT ファイルのパーシャルリコンフィギュレーションでは、 8 ビットバスのみの ICAP を使

用する必要があります。

• ビットストリームリードバックセキュリティがレベル 2 に設定されていなければ、外部コンフィギュレーショ

ンポートを介したリコンフィギュレーションが可能です。


図 8-5: マイクロプロセッサを介したコンフィギュレーション

X12033

Self-reconfiguringFPGA

ICAP uP

uP

RP A

JTAGport

RP A

FPGA

fullconfiguration

RM A1config.

RM A2config.

RM A3config.

Off-chip memory or System ACE





パーシャル BIT ファイルの整合性

パーシャル BIT ファイルのエラー検出と回復には、完全な BIT ファイルを読み込むのと比較して、独自の要件があ

ります。フル BIT ファイルが FPGA に読み込まれるときにエラーが検出されると、 FPGA はユーザーモードになり

ません。エラーは破損したデザインがコンフィギュレーションメモリに読み込まれた後に検出され、対応する信号

がアサートされてエラー状態が示されます。 FPGA はユーザーモードにならないので、破損したデザインがアク

ティブになることはありません。コンフィギュレーションエラーから回復するためのシステムの動作は、異なる

BIT ファイルをダウンロードするなど、ユーザーが決める必要があります。

パーシャル BIT ファイルをダウンロードをする場合、エラーの検出と回復にこの方法は使用できません。パーシャ

ル BIT ファイルを読み込むときには、 FPGA は既にユーザーモードで動作しています。コンフィギュレーション回

路では BIT ファイルを読み込んだ後にのみエラー検出がサポートされるので、破損したパーシャル BIT ファイルが

アクティブになってしまい、その状態で動作を続けると FPGA が破損する可能性があります。

パーシャルリコンフィギュレーション中に CRC エラーが検出されると、 FPGA の INIT_B ピンがアサートされます

(INIT_B が Low になると CRC エラー )。 UltraScale デバイスでは、これが ICAP の PRERROR 出力ピンに反映されま

す。初期コンフィギュレーション中にシステムで INIT_B を使用して CRC エラーを監視する場合、パーシャルリコ

ンフィギュレーション中の CRC エラーでも同じ応答が発生する可能性があります。 FPGA の内部から CRC エラーを

検出するには、 CRC ステータスを ICAP ブロックを介して監視できます。ステータスレジスタ (STAT) で

CRC_ERROR フラグ (ビット 0) がアサートされ、パーシャル BIT ファイルに CRC エラーがあることが示されます。

パーシャル BIT ファイルのエラーでは、データエラーとアドレスエラーを考慮する必要があります。パーシャル

BIT ファイルには、基本的にアドレス情報とデータ情報が含まれます。スタティック配線がリコンフィギャラブル

領域を通過することができるので、まれではありますが、どちらのエラーもスタティックデザインを破損する可能

性があります。完全に安全に回復する唯一の方法は完全な BIT ファイルをダウンロードすることで、そうするとス

タティックロジックのステートが確実なものになりますが、 FPGA 全体をリセットする必要があります。

多くのシステムでは、 FPGA 全体をリセットすることは重要ではないか、パーシャル BIT ファイルがローカルに格納

されているので、複雑な回復メカニズムは必要ありません。パーシャル BIT ファイルがローカルに格納されている

場合、 BIT ファイルが破損する可能性はほとんどありません。無線リンクを介してパーシャル BIT ファイルを送信

するなど BIT ファイルが破損する可能性のあるシステムでは、問題を回避するため専用のシリコン機能を使用する


7 シリーズ FPGA、 UltraScale FPGA、および Zynq-7000 SoC のコンフィギュレーションエンジンにはフレームごとの

CRC チェックを実行する機能があり、 CRC チェックでエラーが検出された場合はフレームはコンフィギュレーショ

ンメモリに読み込まれません。エラーが検出されると INIT_B ピンが Low になり、パーシャル BIT ファイルを再試

行するか、ゴールデンパーシャル BIT ファイルを使用するかなど、次の処理を決定できます。部分的に読み込まれ

たリコンフィギュレーション領域には有効なプログラムはありませんが、システムがエラーから回復する間、 CRC

チェックによりデバイスの残りの部分 (スタティック領域およびほかのリコンフィギャラブルモジュール) は動作を

続けます。

これらのデバイスでこの機能を有効にするには、 write_bitstream を実行する前に PerFrameCRC プロパティを

設定します。このプロパティのデフォルト値は No で、 Yes に設定すると追加の CRC チェックが挿入されます。これ

により、圧縮されていない BIT ファイルのサイズが 4 ～ 5% 増加します。この機能は、ビットストリーム圧縮とは互

換性がありません。このプロパティを設定するのに特別に考慮すべき点はほかにありませんが、 INIT_B ピンにより

エラーが示された場合の処理を選択するため、パーシャルリコンフィギュレーションコントローラーソリューショ

ンを設計する必要があります。





PerFrameCRC プロパティを設定する構文は、次のとおりです。

set_property bitstream.general.perFrameCRC yes [current_design]

フレームごとの CRC チェックの使用/不使用にかかわらず、パーシャル BIT ファイルが読み込まれると、デバイスの

コンフィギュレーション全体が変わります。 SEU を軽減するための POST_CRC 機能がイネーブルになっている場

合、パーシャルビットストリームが読み込まれ、コンフィギュレーションインターフェイスが非同期化された後、

SEU 軽減エンジンによりエンベデッド SEU CRC 値が自動的に再算出されます。CRC 再キャリブレーションが完了す

ると、 FRAME_ECCE2 の FRAME_VALID 出力がトグルし、 SEU 検出が再開したことが示されます。

コンフィギュレーションフレーム

ザイリンクス FPGA および SoC デバイスのすべてのユーザープログラマブル機能は、電源投入時にコンフィギュ

レーションする必要のある揮発性メモリセルにより制御されます。これらのメモリセルは、まとめて「コンフィ

ギュレーションメモリ」と呼ばれます。コンフィギュレーションメモリは、 LUT 論理式、信号配線、 IOB 電圧規

格、およびデザインのすべての特性を定義します。

ザイリンクス FPGA および SoC アーキテクチャでは、コンフィギュレーションメモリはデバイス周囲にフレームと

してタイル状に並べられています。これらのフレームはデバイスコンフィギュレーションメモリ空間のアドレス指

定可能な小セグメントなので、すべての操作をコンフィギュレーションフレーム全体に実行する必要があります。

リコンフィギャラブルフレームは、これらのコンフィギュレーションフレーム上に構築され、パーシャルリコン

フィギュレーションを実行する際の小の構築ブロックです。

• 7 シリーズ FPGA の基本領域:

° CLB: 高さ 50 x 幅 1

° DSP48: 高さ 10 x 幅 1

° ブロック RAM: 高さ 10 x 幅 1

• UltraScale および UltraScale+ FPGA の基本領域:

° CLB: 高さ 60 x 幅 1

° DSP48: 高さ 24 x 幅 1

° ブロック RAM: 高さ 12 x 幅 1

° I/O およびクロッキング: 52 個の I/O (1 つのバンク ) と、関連の XiPhy、 MMCM、および PLL リソース

° ギガビットトランシーバー : 高さ 4 (1 つのクワッドと関連のクロックリソース)





コンフィギュレーション時間

コンフィギュレーションの速度は、パーシャル BIT ファイルのサイズおよびコンフィギュレーションポートの帯域

幅に直接関係しています。表 8-4 に、 7 シリーズの異なるコンフィギュレーションポートの大帯域幅を示します。

ビットストリームの正確な長さは、 write_bitstream コマンドで -raw_bitfile オプションを使用して作成され

た .rbt ファイルに含まれます。この数値と帯域幅から、コンフィギュレーションの総時間を算出します。次に、

ロービットファイルのヘッダーの例を示します。

Xilinx ASCII BitstreamCreated by Bitstream 2015.1Design name: led_shift_count;UserID=0XFFFFFFFFArchitecture:kintex7Part: 7k325tffg900Date: Mon Mar 16 16:42:05 2015Bits: 121107211111111111111111111111111111111

表 8-4: 7 シリーズアーキテクチャのコンフィギュレーションポートの大帯域幅


大クロックレートデータ幅大帯域幅

ICAP 100 MHz 32 ビット 3.2 Gb/s

SelectMAP 100 MHz 32 ビット 3.2 Gb/s

シリアルモード 100 MHz 1 ビット 100 Mb/s

JTAG 66 MHz 1 ビット 66 Mb/s





コンフィギュレーションデバッグ

ICAP インターフェイスは、ビットストリームを配信するためのポートとして使用される場合に、コンフィギュレー

ションプロセスを監視するために使用できます。 ICAP ブロックの O ポートは 32 ビットバスですが、下位バイト

のみが使用されます。次の表に、下位バイトの各ビットの説明を示します。

このバイトの上位 4 ビットがステータスを示します。これらのステータスビットは、同期ワードが受信されたか、

コンフィギュレーションエラーが発生したかを示します。次の表に、これらの状態の値を示します。

表 8-5: ICAP の O ポートビット

ICAP の O ポートビットステータスビット説明

O[7] CFGERR_B コンフィギュレーションエラー (アクティブ Low)

0: コンフィギュレーションエラーが発生。

1: コンフィギュレーションエラーなし。

O[6] DALIGN 同期ワードの受信 (アクティブ High)

0: 同期ワードは受信されていない。

1: インターフェイスロジックから同期ワードを受信。

O[5] RIP リードバック (アクティブ High)

0: リードバックは実行されていない。

1: リードバックを実行中。

O[4] IN_ABORT_B アボート (アクティブ Low)

0: アボートを実行中。

1: アボートは実行されていない。

O[3:0] 1 予約済み

表 8-6: ICAP の同期ビット

O[7:0] 同期ワードの有無コンフィギュレーション

エラーの有無

9F なしなし

DF ありなし

5F ありあり

1F なしあり





図 8-6 に、完了したフルコンフィギュレーション、その後に CRC エラーを含むパーシャルリコンフィギュレーショ

ン、後に正常に完了したパーシャルリコンフィギュレーションを示します。上記の表とこの後の説明から、どの

ように ICAP の O ポートを使用してコンフィギュレーションプロセスを監視するかがわかります。 CRC エラーが発

生したら、これらの信号をコンフィギュレーションステートマシンで使用してエラーから回復できます。これらの

信号は Vivado ロジック解析でデバッグ用にコンフィギュレーションエラーをキャプチャするのにも使用できます。

この情報を使用して、 Vivado ロジック解析をパーシャルリコンフィギュレーションのさまざまなポイントをキャプ

チャするのに使用できます。

Vivado ロジック解析画面のマーカーは、次をものを示します。

• 1st_done

初期フルビットストリームコンフィギュレーションの完了を示します。DONE ピン (図の波形の done_pad) が

High になります。

• cfgerr

パーシャルビットストリームの読み込み中に CRC エラーが検出されたことを示します。ステータスは O[31:0] (

図の波形の icap_o_top[31:0]) で確認できます。

° Icap_o_top[31:0] は 0x9F から開始します。

° SYNC ワードが受信されると、 Icap_o_top[31:0] が 0xDF になります。

° CRC エラーが受信されると、 Icap_o_top[31:0] が 1 サイクル間 0x5F になり、その後 0x1F になります。

° INIT_B が Low になります (図の波形の init_pad)。


図 8-6: パーシャルリコンフィギュレーション用の Vivado ロジック解析の画面





• RCRC

パーシャルビットストリームが再び読み込まれたことを示します。 RCRC コマンドは cfgerr ステータスをリ

セットし、 INIT_B ピンを High にします (図の波形の init_pad)。

° SYNC ワードが受信されると Icap_o_top[31:0] は 0x1F から 0x5F に変わります。

° RCRC コマンドが受信されると Icap_o_top[31:0] は 0x5F から 0xDF に変わります。

• pr_done

パーシャルビットストリームが正しく完了したことを示します。

° DESYNC コマンドが受信され、コンフィギュレーションエラーが検出されなかった場合、

Icap_o_top[31:0] は 0xDF から 0x9F に変わります。

上記の手法に加え、 UltraScale アーキテクチャには ICAP 上にパーシャルリコンフィギュレーションで使用可能な 2

つの専用ポートがあります。

• PRDONE ピンは、外部 DONE ピンのステートを反映するよう設計されていますが、特に SSI デバイスでは動作

が一貫していないので、これらのデバイスでは使用しないでください。パーシャルリコンフィギュレーション

の完了を検知するには、マスター SLR にある STARTUP ブロックの EOS ピンを使用してください。

• PRERROR ピン: 外部 INIT_B ピンのステートを反映します。 BIT ファイルの後の標準完全 CRC 値またはフ

レームごとの CRC 値で CRC エラーが発生すると Low になります。

Vivado デバッグコアの使用

Vivado デバッグコア (ILA、 VIO など) は、リコンフィギャラブルモジュール内も含め、パーシャルリコンフィギュ

レーションデザインのどこにでも配置できます。デザイン全体の通信のために中央デバッグハブにこれらのコアを

接続するには、特定の設計手法が必要です。

スタティック領域の中央デバッグハブ間の接続は自動的に設定でき、リコンフィギャラブルパーティションのポー

ト名に特定の命名規則を使用することによりトリガーできます。これらの 12 本のピンは必須で、命名規則に従って

いればハブが推論されます。次に、 Verilog および VHDL の例を示します。

スタティックデザインの Verilog インスタンシエーション:

my_count counter_inst (.clk(my_clk),.dout(dout),.S_BSCAN_drck(),.S_BSCAN_shift(),.S_BSCAN_tdi(),.S_BSCAN_update(),.S_BSCAN_sel(),.S_BSCAN_tdo(),.S_BSCAN_tms(),.S_BSCAN_tck(),.S_BSCAN_runtest(),.S_BSCAN_reset(),.S_BSCAN_capture(),.S_BSCAN_bscanid_en()

);





スタティックデザインの VHDL コンポーネント宣言およびインスタンシエーション:

component my_count isPort ( clk : in STD_LOGIC;dout : out STD_LOGIC;S_BSCAN_drck: IN std_logic := '0';S_BSCAN_shift: IN std_logic := '0';S_BSCAN_tdi: IN std_logic := '0';S_BSCAN_update: IN std_logic := '0';S_BSCAN_sel: IN std_logic := '0'; S_BSCAN_tdo: OUT std_logic;S_BSCAN_tms: IN std_logic := '0';S_BSCAN_tck: IN std_logic := '0';S_BSCAN_runtest: IN std_logic := '0';S_BSCAN_reset: IN std_logic := '0';S_BSCAN_capture: IN std_logic := '0';S_BSCAN_bscanid_en: IN std_logic := '0'

);end component;…counter_inst: my_countport map (clk => my_clk,dout => dout,S_BSCAN_drck => open, S_BSCAN_shift => open, S_BSCAN_tdi => open, S_BSCAN_update => open, S_BSCAN_sel => open, S_BSCAN_tdo => open, S_BSCAN_tms => open, S_BSCAN_tck => open, S_BSCAN_runtest => open, S_BSCAN_reset => open, S_BSCAN_capture => open, S_BSCAN_bscanid_en => open

);

注記: open キーワードを使用するには、これらの入力ポートで初期値を受信する必要があり、初期値は 0 である必

要があります。 1 に接続されているポートは、ローカルデバッグハブには接続されません。

リコンフィギャラブルモジュールの上位 RTL 内では、これらの 12 本のポートは未接続のままにします。合成時

に、デバッグハブはスタティック領域に 1 つ、各リコンフィギャラブルモジュールに 1 つずつ、ブラックボックス

として挿入されます。これらの挿入された IP は、 opt_design 中に展開されます。これは、 RM (グレーボックス

RM を含む) 内にデバッグコアがない場合でも、各 RM に対して実行されます。

複数の BSCAN インスタンスに接続する必要がある場合など、これらのポートに命名規則に従った名前を使用しない

場合、属性を使用してデバッグハブを挿入できます。デバッグポートを割り当てるには、次の構文でポート名以外

のものを変更しないでください。これらの属性は、すべての RM 上位ソースファイルで使用されます。





RM 上位の Verilog 属性:

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN drck" *) (* DEBUG="true" *) input my_drck; (* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN shift" *) (* DEBUG="true" *) input my_shift; (* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tdi" *) (* DEBUG="true" *) input my_tdi; (* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN update" *) (* DEBUG="true" *) input my_update;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN sel" *) (* DEBUG="true" *) input my_sel;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tdo" *) (* DEBUG="true" *) output my_tdo;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tms" *) (* DEBUG="true" *) input my_tms;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tck" *) (* DEBUG="true" *) input my_tck;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN runtest" *) (* DEBUG="true" *) input my_runtest; (* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN reset" *) (* DEBUG="true" *) input my_reset; (* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN capture" *) (* DEBUG="true" *) input my_capture;

(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN bscanid_en" *) (* DEBUG="true" *) input my_bscanid_en;





RM 上位の VHDL 属性:

attribute X_INTERFACE_INFO : string; attribute DEBUG : string; attribute X_INTERFACE_INFO of my_drck: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN drck"; attribute DEBUG of my_drck: signal is "true"; attribute X_INTERFACE_INFO of my_shift: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN shift"; attribute DEBUG of my_shift: signal is "true"; attribute X_INTERFACE_INFO of my_tdi: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN tdi"; attribute DEBUG of my_tdi: signal is "true"; attribute X_INTERFACE_INFO of my_update: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN update"; attribute DEBUG of my_update: signal is "true"; attribute X_INTERFACE_INFO of my_sel: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN sel"; attribute DEBUG of my_sel: signal is "true"; attribute X_INTERFACE_INFO of my_tdo: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN tdo"; attribute DEBUG of my_tdo: signal is "true"; attribute X_INTERFACE_INFO of my_tms: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN tms"; attribute DEBUG of my_tms: signal is "true"; attribute X_INTERFACE_INFO of my_tck: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN tck"; attribute DEBUG of my_tck: signal is "true"; attribute X_INTERFACE_INFO of my_runtest: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN runtest";

attribute DEBUG of my_runtest: signal is "true"; attribute X_INTERFACE_INFO of my_reset: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN reset"; attribute DEBUG of my_reset: signal is "true"; attribute X_INTERFACE_INFO of my_capture: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN capture";

attribute DEBUG of my_capture: signal is "true"; attribute X_INTERFACE_INFO of my_bscanid_en: signal is "xilinx.com:interface:bscan:1.0 S_BSCAN bscanid_en"; attribute DEBUG of my_bscanid_en: signal is "true";

このソリューションの現時点での 1 つの制限は、リコンフィギャラブルモジュール内のすべてのデバッグコアをイ

ンスタンシエートする必要があるということです。 MARK_DEBUG 挿入フローはサポートされていません。

このコアの挿入例および Vivado ハードウェアマネージャー内の機能については、『Vivado Design Suite チュートリア

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


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug947-vivado-partial-reconfiguration-tutorial.pdf;a=xVivadoDebugAndThePRProjectFlow



第 9 章

既知の問題および制限

既知の問題

現在の Vivado® Design Suite リリースでパーシャルリコンフィギュレーションを使用する場合、直面する可能性のあ

る既知の問題がいくつかあります。これらの問題が発生した場合、またはほかの問題が発生した場合は、ザイリン

クスサポートに連絡し、問題が発生したサンプルデザインをご送付ください。これらのテストケースは、ソリュー

ションを向上するために活用させていただきます。

致命的なエラー、内部エラー、不完全な配線 (部分的なアンテナ)、配置配線、 pr_verify、および

write_bitstream を阻害するその他の規則違反が発生した場合は、ザイリンクスにご連絡ください。適切に解析

し、修正を適用する上で、エラーが発生したデザインを含めていただくことが重要となります。

• 7 シリーズ SSI デバイス (7V2000T、 7VX1140T) の初回コンフィギュレーションを SPI インターフェイスを介し

て実行する場合は、パーシャルビットストリームをマスター (またはその他の) ICAP に送信することはできま

せん。 JTAG などの外部ポートに送信する必要があります。初期コンフィギュレーションをほかのコンフィギュ

レーションポートを介して実行した場合は、マスター ICAP をパーシャルビットストリームの配布ポートとし

て使用できます。回避策については、ザイリンクスサポートにご連絡ください。

• 1 つのリコンフィギャラブルモジュールの複数の出力を同じソースで駆動しないでください。 RM の各出力に

は、それぞれドライバーが必要です。

• UltraScale または UltraScale+ デバイスのエンジニアリングシリコン (ES) は、公式にはパーシャルリコンフィ

ギュレーションをサポートしていません。 ES デバイスでの PR 機能の詳細は、ザイリンクスサポートまでご連

絡ください。




第 9 章: 既知の問題および制限

既知の制限

現在のリリースではまだ開発されていない、またはサポートされていない機能があります。これらの機能は、今後

のリリースで追加される可能性があります。その一部を次に示します。

• Zynq UltraScale+ MPSoC Xilfpga ライブラリでは、パーシャル BIT ファイルの配布はまだサポートされていませ

ん。ユーザーが独自のソフトウェア管理ソリューションを記述する必要があります。この制限は、今後のリリー

スで削除される予定です。詳細は、 Xilfpga Wiki ページ http://www.wiki.xilinx.com/xilfpga を参照してください。

• Pblock の範囲を選択してリコンフィギャラブルパーティションのサイズおよび形状を定義する際、 7 シリーズ

または Zynq-7000 デバイスの場合は、 CLOCKREGION リソースタイプを使用しないでください。 Pblock の範囲

には、 SLICE、 RAMB18、 RAMB36、および DSP48 リソースタイプのみを含めます。

• リコンフィギャラブルパーティション内で Vivado デバッグコアの挿入機能を使用しないでください。このフ

ローでは、 BSCAN プリミティブを含むデバッグハブが挿入されますが、これはリコンフィギャラブルビット

ストリーム内では許容されません。 Vivado Debug コアをインスタンシエートするか IP 内に含めると、「Vivado

デバッグコアの使用」に説明するようにデバッグコアを推論できるようになります。

• UpdateMEM では、パーシャルまたは Tandem ビットストリームはサポートされません。メモリファイルを PR

デザインに関連付けるには、 ELF 関連付けフローを適用する必要があります。詳細は、『Vivado Design Suite

ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994) [参照 28] のこのセクション

を参照してください。

• Soft Error Mitigation (SEM) IP コアは、モノリシックデバイスでの PR と共にサポートされます。 UltraScale デバ

イスでは、 SSI デバイスにパーシャルリコンフィギュレーションを使用する場合は SEM IP コアはサポートされ

ません。 UltraScale +デバイスでは、 SSI デバイスに PR を使用する場合に SEM IP コアがサポートされます。 PR

デザインでの SEM IP の使用に関する詳細は、『モノリシックデバイスでの Soft Error Mitigation IP およびパー

シャルリコンフィギュレーションのデモ』 (XAPP1261) [参照 4] を参照してください。

• 7 シリーズおよび UltraScale デバイスでは、 STARTUP プリミティブでパーシャルリコンフィギュレーションの

読み込みはサポートされません。 AXI SPI IP や AXI EMC IP などの IP は、外部フラッシュからクロック供給し

たり、パーシャルビットストリームを配布する目的で、 STARTUP プリミティブを使用するよう設定しないでく

ださい。

• 暗号化に関する 2 つのユースケースは、 UltraScale および UltraScale+ デバイスの新しい機能を使用する場合は

サポートされません。

a. 初期コンフィギュレーションに RSA 認証を選択した場合は、暗号化パーシャルリコンフィギュレーション

はサポートされません。 FPGA では、パーシャルビットストリームの RSA 認証はサポートされません。

b. 初期コンフィギュレーションビットストリームで eFUSE または BBRAM に格納されている難読化 AES-256

キーを使用する場合は、暗号化パーシャルビットストリームでも同じ難読化キーを使用する必要がありま

す。初期化ビットストリームと異なるキーを使用する暗号化 PR ビットストリームはサポートされません。

これらどちらの場合でも、暗号化されていないパーシャルビットストリームを ICAP に転送してデバイスを

パーシャルリコンフィギュレーションできます。

• ビットストリーム圧縮およびフレームごとの CRC チェックは、パーシャルビットストリームでは同時にイネー

ブルにはできません。



http://www.wiki.xilinx.com/xilfpga

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug994-vivado-ip-subsystems.pdf;a=xAddingAndAssociatingAnElfFileToAnEmbeddedDesign



付録 A

階層デザインフロー

概要

パーシャルリコンフィギュレーションは、理想的な階層デザインツールです。デザインのスタティック部分をイン

プリメントし、タイミングを満たし、その結果を再利用できる機能は、ほかの階層デザイン (HD) フローのニーズを

満たします。ほかの HD ユースケースの問題を解決するためにパーシャルリコンフィギュレーションを使用する障

害となっていたのが、PR ライセンス料でした。現在では PR 機能のライセンスは Vivado Design Edition および System

Edition に含まれており、通常の PR ユースケースだけでなく、プラットフォーム再利用 HD フローにも、広く PR

ツールスイートを活用できます。

プラットフォーム再利用では、上位 (プラットフォーム) と下位パーティションを分離できるツールの機能を利用

します。プラットフォーム再利用は、次を例とするさまざまな状況で使用できます。

• デザインサイクルおよびタイミングクロージャの削減。上位でタイミングクロージャを達成することによ

り、インターフェイスロジック (メモリコントローラー、ネットワーク IP、高速インターコネクトなど) が変更

されたときに、パーティションロジックを開発しているプラットフォームの配置配線結果を固定して再利用で

きます。

• プラットフォームをエンドユーザーに配布。この場合、プラットフォームを 1 人のユーザーが開発し、完全に

配置配線し、 DCP (パーティションのブラックボックスを含む) を固定して、別のユーザーがカスタマーパー

ティションロジックを開発するために使用できるよう配布できます。

これらのフローでは、パーシャルリコンフィギュレーションフローを使用して、初期デザインをインプリメント

し、パーティションを削除して、スタティック /プラットフォームロジックを固定します。グレーボックスサポー

トなどのパーシャルリコンフィギュレーションのすべての機能を使用でき、 PR フローのすべての要件に従う必要が

あります。ツールの視点から見ると、フロー間に違いはなく、すべての PR DRC が適用されます。

このフローではパーシャル BIT ファイルは不要なので、 write_bitstream コマンドの -no_partial_bitfile

オプションを使用してパーシャルビットストリームを生成しないようにすることをお勧めします。



付録 B

その他のリソースおよび法的通知

ザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照して

ください。

ソリューションセンター

デバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。デザイ

ンアシスタント、デザインアドバイザリ、トラブルシューティングのヒントなどが含まれます。

Xilinx Documentation Navigator およびデザインハブ

Xilinx Documentation Navigator (DocNav) では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特

定の情報を取得するためにフィルター機能や検索機能を利用できます。 DocNav を開くには、次のいずれかを実行し

ます。

• Vivado IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux コマンドプロンプトに「docnav」と入力します。

ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられてお

り、これらを参照することでキーコンセプトを学び、よくある質問 (FAQ) を参考に問題を解決できます。デザイン

ハブにアクセスするには、次のいずれかを実行します。

• DocNav で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: DocNav の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。

注意: DocNav からは、日本語版は参照できません。ウェブサイトのデザインハブページをご利用ください。


https://japan.xilinx.com/support

https://japan.xilinx.com/support/solcenters.htm

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav



付録 B: その他のリソースおよび法的通知

参考資料

注記: 日本語版のバージョンは、英語版より古い場合があります。

1. 『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947)

2. 『Partial Reconfiguration Controller LogiCORE IP 製品ガイド』 (PG193: 英語版、日本語版)

3. 『Partial Reconfiguration Decoupler LogiCORE IP 製品ガイド』 (PG227)

4. 『モノリシックデバイスでの Soft Error Mitigation IP およびパーシャルリコンフィギュレーションのデモ』 (XAPP1261: 英語版、日本語版)

5. UltraScale デバイスにおける Tandem PCIe およびパーシャルリコンフィギュレーションでの PCI Express リンクを介したビートストリームの読み込み (ザイリンクスアンサー 64761)

6. 『Zynq-7000 SoC プロセッサにおける Vivado Design Suite を使用したハードウェアアクセラレータのパーシャルリコンフィギュレーション』 (XAPP1231: 英語版、日本語版)

7. 『7 シリーズ FPGA コンフィギュレーションユーザーガイド』 (UG470: 英語版、日本語版)

8. 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570: 英語版、日本語版)

9. 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版)

10. 『パーシャルリコンフィギュレーションユーザーガイド』 (UG702) - ISE デザインツール用

11. 『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949)

12. 『7 Series FPGAs Integrated Block for PCI Express LogiCORE IP 製品ガイド』 (PG054: 英語版、日本語版)

13. 『Virtex-7 FPGA Gen3 PCIe Integrated Block for PCI Express 製品ガイド』 (PG023)

14. 『UltraScale FPGAs Gen3 Integrated Block for PCI Express LogiCORE IP 製品ガイド』 (PG156: 英語版、日本語版)

15. 『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)

16. 『Vivado Design Suite ユーザーガイド : 合成』 (UG901)

17. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903)

18. 『Vivado Design Suite ユーザーガイド : デザイン解析およびクロージャテクニック』 (UG906)

19. 『7 シリーズ FPGA GTX/GTH トランシーバーユーザーガイド』 (UG476: 英語版、日本語版)

20. 『7 シリーズ FPGA GTP トランシーバーユーザーガイド』 (UG482: 英語版、日本語版)

21. 『MMCM および PLL のダイナミックリコンフィギュレーション』 (XAPP888: 英語版、日本語版)

22. 『UltraScale アーキテクチャクロッキングリソースユーザーガイド』 (UG572: 英語版、日本語版)

23. 『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576: 英語版、日本語版)

24. 『UltraScale アーキテクチャ GTY トランシーバーユーザーガイド』 (UG578: 英語版、日本語版)

25. 『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908)

26. 『AXI Bridge for PCI Express Gen3 Subsystem 製品ガイド』 (PG194)

27. 『UltraScale アーキテクチャコンフィギャラブルロジックブロックユーザーガイド』 (UG574: 英語版、日本語版)

28. 『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994)

29. 『DMA/Bridge Subsystem for PCI Express 製品ガイド』 (PG195)

30. 『UltraScale+ Devices Integrated Block for PCI Express v1.2 製品ガイド』 (PG213: 英語版、日本語版)

31. 『Vivado Design Suite プロパティリファレンスガイド』 (UG912)

32. 『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

33. 『Zynq UltraScale+ MPSoC レジスタリファレンス』 (UG1087)


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug947-vivado-partial-reconfiguration-tutorial.pdf


https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pr_decoupler;v=latest;d=pg227-pr-decoupler.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=answers;d=64761.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1231-partial-reconfig-hw-accelerator-vivado.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug470_7Series_Config.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=14.7;d=ug702.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug949-vivado-design-methodology.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie_7x;v=latest;d=pg054-7series-pcie.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie3_7x;v=latest;d=pg023_v7_pcie_gen3.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie3_ultrascale;v=latest;d=pg156-ultrascale-pcie-gen3.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?l=ja;v=2018.1;d=ug835-vivado-tcl-commands.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug901-vivado-synthesis.pdf

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

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug906-vivado-design-analysis.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug476_7Series_Transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug482_7Series_GTP_Transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp888_7Series_DynamicRecon.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug572-ultrascale-clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug576-ultrascale-gth-transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug578-ultrascale-gty-transceivers.pdf

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

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=axi_pcie3;v=latest;d=pg194-axi-bridge-pcie-gen3.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug574-ultrascale-clb.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug994-vivado-ip-subsystems.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=xdma;v=latest;d=pg195-pcie-dma.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie4_uscale_plus;v=latest;d=pg213-pcie4-ultrascale-plus.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.1;d=ug912-vivado-properties.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1261-demo-sem-pr.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=prc;v=latest;d=pg193-partial-reconfiguration-controller.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=prc;v=latest;d=j_pg193-partial-reconfiguration-controller.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1261-demo-sem-pr.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1231-partial-reconfig-hw-accelerator-vivado.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug470_7Series_Config.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie_7x;v=latest;d=j_pg054-7series-pcie.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie3_ultrascale;v=latest;d=j_pg156-ultrascale-pcie-gen3.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug476_7Series_Transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug482_7Series_GTP_Transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp888_7Series_DynamicRecon.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug572-ultrascale-clocking.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug576-ultrascale-gth-transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug578-ultrascale-gty-transceivers.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug574-ultrascale-clb.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie4_uscale_plus;v=latest;d=j_pg213-pcie4-ultrascale-plus.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf



34. 『PRC/EPRC: パーシャルリコンフィギュレーションのデータインテグリティおよびセキュリティコントローラー』 (XAPP887)

35. 『Vivado Design Suite を使用した USER_ACCESS によるビットストリーム識別』 (XAPP1232: 英語版、日本語版)

36. 『3D IC 用のエンベデッドプロセッシングを使用したローカルパーシャルリコンフィギュレーション』 (XAPP1099: 英語版、日本語版)

37. スタートアップ後にフリップフロップおよび SRL を正しく同期化させるためのデザインアドバイザリ (ザイリンクスアンサー 44174)

38. Vivado Design Suite の資料

トレーニングリソース

ザイリンクスでは、この資料に含まれるコンセプトを説明するさまざまなトレーニングコースおよび QuickTake ビデ

オを提供しています。次のリンクから関連するトレーニングリソースを参照してください。

1. Vivado Design Suite QuickTake ビデオチュートリアル

2. Vivado Design Suite QuickTake ビデオ: Vivado でのパーシャルリコンフィギュレーション

3. Vivado Design Suite QuickTake ビデオ: UltraScale でのパーシャルリコンフィギュレーション

4. Vivado Design Suite QuickTake ビデオ: UltraScale+ でのパーシャルリコンフィギュレーション

5. トレーニングコース : Vivado を使用した Zynq でのパーシャルリコンフィギュレーションフロー

6. トレーニングコース : ザイリンクスパーシャルリコンフィギュレーションのツールおよびテクニック



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp887_PRC_EPRC.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1232-bitstream-id-with-usr_access.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1099-7series-partial-reconfiguration-ssi-embedded.pdf



https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+docs

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=vivado+videos

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=partial-reconfiguration-in-vivado.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=partial-reconfiguration-for-ultrascale.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=hardware/partial-reconfiguration-for-ultrascale-plus.html

https://japan.xilinx.com/support/university/vivado/vivado-workshops/Vivado-partial-reconfiguration-flow-zynq.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=partial-reconfiguration-tools-and-techniques.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1232-bitstream-id-with-usr_access.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1099-7series-partial-reconfiguration-ssi-embedded.pdf



お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供

され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれ

らに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または

貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わな

い (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害に

は、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の

損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能で

あったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に

含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いま

せん。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一

定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件

に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケー

ションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を

使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2012-2018 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含

まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。 PCI、 PCIe、および PCI Express は PCI-SIG の商標であり、ライセンスに基づいて使用されています。すべてのその他の商標は、それぞれの保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。



https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos

mailto:[email protected]


vivado design suite - xilinx...vivado design suite ユーザー ガイド パーシャル...

Documents

vivado design suite - xilinx...vivado design suite ユーザーガイドパーシャル...