ultrascale devices gen3 integrated block for pci …...ultrascale devices gen3 integrated block for...

UltraScale Devices Gen3 Integrated Block for PCI Express v4.4

LogiCORE IP 製品ガイド

Vivado Design Suite

PG156 2017 年 10 月 4 日

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

UltraScale Devices Gen3 Block for PCIe v4.4 2

PG156 2017 年 10 月 4 日 japan.xilinx.com

目次

IP の概要

第 1章: 概要機能概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

サポートされていない機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ライセンスおよび注文情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

第 2章: 製品仕様準拠する規格 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

リソースの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

デバイスの低要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

利用可能な PCI Express 用統合ブロック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

GT のロケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ポートの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

属性の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

コンフィギュレーション空間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

第 3章: コアを使用するデザイン共有ロジック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Tandem コンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

クロッキング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

リセット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

AXI4-Stream インターフェイスの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

パワーマネージメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

割り込みリクエストの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

受信メッセージインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

コンフィギュレーションマネージメントインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

リンクトレーニング: 2 レーン、 4 レーン、および 8 レーンコンポーネント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

レーン反転 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

第 4章: デザインフローの手順コアのカスタマイズおよび生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

コアへの制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

シミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

合成およびインプリメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

第 5章: サンプルデザインサンプルデザインの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

コンフィギュレーターサンプルデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

コアの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

サンプルデザインのシミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

サンプルデザインの合成およびインプリメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=Product_Guide&docId=PG156&Title=UltraScale%20Devices%20Gen3%20Integrated%20Block%20for%20PCI%20Express%20v4.4%20LogiCORE%20IP%20%26%2335069%3B%26%2321697%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=4.4&docPage=2



第 6章: テストベンチエンドポイント用ルートポートモデルテストベンチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

ルートポート用のエンドポイントモデルテストベンチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

付録 A: アップグレードVivado Design Suite でのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

7 シリーズ Gen2 コアから UltraScale デバイス Gen3 コアへの移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

UltraScale デバイスの PCI Express デザインのパッケージ移行. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

付録 B: GT のロケーションKintex UltraScale デバイスの GT ロケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Virtex UltraScale デバイスの GT ロケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

付録 C: 受信されるコンプリーションに対する受信バッファー空間の管理一般的な注意事項と概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

コンプリーション空間の管理方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

付録 D: デバッグザイリンクスウェブサイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

ハードウェアデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

付録 E: Xilinx Virtual Cable (XVC) を使用したデバッグはじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

ホスト PC 上の XVC-Server アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Host PC 上の XVC-over-PCIe ドライバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

XVC-over-PCIe に対応した FPGA デザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

PCIe-XVC-VSEC サンプルデザインの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

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

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

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

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




PG156 2017 年 10 月 4 日 japan.xilinx.com Production 製品仕様

はじめに

ザイリンクスの UltraScale Devices Gen3 Integrated Block for PCIe ソリューション IP コアは、 UltraScale™ デバイスで使用する、高帯域かつスケーラブルで信頼性の高いシリアルインターコネクト構築ブロックソリューションです。このコアは、 1 レーン、 2 レーン、 4 レーン、および 8 レーンのエンドポイントコンフィギュレーションをサポートし、 Gen1 (2.5GT/s)、 Gen2 (5.0GT/s)、および Gen3 (8GT/s) スピードに対応します。『PCI Express Base Specification, rev. 3.0』 [参照 2] に準拠しています。このソリューションは、カスタマーユーザーインターフェイス用の AXI4-Stream インターフェイスをサポートしています。

機能

• 高性能、高い柔軟性、スケーラブル、高い信頼性の汎用 I/O コア

• リクエスターとコンプリーターのインターフェイスが分離されており、デザインの簡素化と性能の向上が可能

• エンドポイントまたはルートポートコンフィギュレーション

• エンドポイントコンフィギュレーションでマルチファンクションおよびシングルルート I/O 仮想化 (SR-IOV)

• PCI および PCI Express のパワーマネージメント機能に準拠

• オプションの Tag Management (タグ管理) 機能

• 大ペイロードサイズ (MPS): 1024 バイト

• ECRC (エンドツーエンド巡回冗長検査)

• AER (Advanced Error Reporting)

• 大 32 ベクターのマルチベクター MSI

• MSI-X

• アトミック操作および TPH (TLP Processing Hint)

機能の一覧は、「機能概要」を参照してください。

IP の概要

この LogiCORE™IP について

コアの概要

サポートされる

デバイスファミリ (1)

UltraScale デバイス

サポートされる

ユーザーインターフェイス

AXI4-Stream

リソースPerformance and Resource Utilization

(ウェブページ)

コアに含まれるもの

デザインファイル Verilog

サンプルデザイン Verilog

テストベンチ Verilog

制約ファイル XDC

シミュレーションモデル

Verilog

サポートされるソフトウェアドライバー

N/A

テスト済みデザインフロー (2)

デザイン入力 Vivado® Design Suite

シミュレーション

サポートされるシミュレータについては、

『Vivado Design Suite ユーザーガイド :リリースノート、インストールおよび

ライセンス』を参照

合成 Vivado 合成

サポート

ザイリンクスサポートウェブページで提供

注記:1. サポートされているデバイスの一覧は、 Vivado IP カタログを参

照してください。

2. サポートされているツールのバージョンは、『Vivado Design Suite ユーザーガイド : リリースノート、インストールおよび

ライセンス』を参照してください。

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=ip+ru;d=pcie3-ultrascale.html


https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+release+notes



https://japan.xilinx.com/support











第 1章

概要UltraScale Devices Gen3 Integrated Block for PCIe®コアは、 UltraScale™ デバイスで使用する高帯域かつスケーラブルで信頼性の高いシリアルインターコネクト構築ブロックソリューションで、 UltraScale デバイス内の統合ブロックをインスタンシエートします。

重要: UltraScale+ デバイスにデザインをインプリメントする場合は、『UltraScale+ Devices Integrated Block for PCI Express LogiCORE IP 製品ガイド』 (PG213) [参照 3] を参照してください。

図 1-1 に、このコアのインターフェイスを示します。





第 1 章:概要

X-Ref Target - Figure 1-1

図 1‐1: コアのインターフェイス

Integrated Block for PCI Express User Application

AX

I4-S

tream

Enh

ance

d In

terfa

ce

CompleterCompletion

Interface

CompleterreQuesterInterface

Requester Completion

Interface

RequesterreQuesterInterface

PCIeCompleterInterface

m_axis_cq_*

s_axis_cc_*

s_axis_rq_*

pcie_tag_av[1:0]

m_axis_rc_*

Configuration Management Interface

cfg_mgmt_*

cfg_mgmt_read_datacfg_mgmt_read_write_done

Configuration Status Interface

cfg_msg_received*

cfg_msg_transmit_done

cfg_msg_transmit_*

Configuration FC interfacecfg_fc_*

cfg_fc_sel

cfg_*

Configuration Control Interface cfg_*

cfg_interrupt_*

cfg_interrupt_msi_*

cfg_interrupt_msix_*

Configuration Extended Interface cfg_ext_read_datacfg_ext_read_data_valid

cfg_ext_*

Clock and Reset Interface

user_clkuser_reset

sys_reset

PCI Expresspci_exp

sys_clk

PCIe Requester Interface

Configuration Received Message Interface

Configuration Transmit Message Interface

Configuration Interrupt Controller Interface

AXI4-StreamSlave

AXI4-StreamMaster

AXI4-StreamSlave

AXI4-StreamSlave

AXI4-StreamMaster

AXI4-StreamMaster

AXI4-StreamSlave

AXI4-StreamMaster

TagAvaiability

Status

X16318-030217





第 1 章:概要

機能概要

Integrated Block for PCI Express (PCIe®) ソリューションの GTH トランシーバーは、 1 レーン、 2 レーン、 4 レーン、および 8 レーン動作をサポートし、ラインレートは 2.5GT/s (Gen1)、 5.0GT/s (Gen2)、および 8.0GT/s (Gen3) に対応しています。またエンドポイントコンフィギュレーションがサポートされています。

カスタマーユーザーインターフェイスは、 AMBA® AXI4-Stream インターフェイスに準拠しています。このインターフェイスでは、リクエスターインターフェイス、コンプリーションインターフェイス、およびメッセージインターフェイスを個別にサポートします。これによって、データアライメントとパリティチェックに柔軟性が備わります。データのフロー制御は、受信および送信方向でサポートされています。さらに送信方向では、進行中トランザクションの中断がサポートされています。オプションの連続トランザクションでは、ストラドルを使用してより高いリンク帯域幅を提供します。

このコアの特長は次のとおりです。

• 高性能、高い柔軟性、スケーラブル、高い信頼性の汎用 I/O コア

° 『PCI Express Base Specification, rev. 3.0』に準拠 [参照 2]

° 既存の PCI ソフトウェアモデルと互換性がある

• GTH トランシーバー

° 2.5GT/s、 5.0GT/s、および 8.0GT/s ラインレート

° 1 レーン、 2 レーン、 4 レーン、および 8 レーンの動作

• エンドポイントまたはルートポートコンフィギュレーション

• エンドポイントコンフィギュレーションでマルチファンクションおよびシングルルート I/O 仮想化 (SR-IOV)

° 大 2 つの Physical Function (PF)

° 大 6 つの Virtual Function (VF)

• 標準化されたユーザーインターフェイス

° AXI4-Stream に準拠

° リクエスターインターフェイス、コンプリーションインターフェイス、およびメッセージインターフェイスを個別にサポート

° 柔軟なデータアライメント

° AXI4-Stream インターフェイスでパリティ生成とパリティチェック

° 使用が容易なパケットベースのプロトコル

° 全二重通信

° より高いリンク帯域幅を可能にするオプションの連続トランザクション

° 送信方向において、データのフロー制御および進行中のトランザクション中断をサポート

° 受信方向において、データのフロー制御をサポート

• PCI および PCI Express のパワーマネージメント機能に準拠

• オプションの Tag Management (タグ管理) 機能

• 大トランザクションペイロード : 1024 バイト

• ECRC (エンドツーエンド巡回冗長検査)

• AER (Advanced Error Reporting)

• 大 32 ベクターのマルチベクター MSI および MSI-X

• アトミック操作および TPH (Transaction Layer Packets (TLP) Processing Hint)





第 1 章:概要

アプリケーション

このコアのアーキテクチャは、性能、コスト、スケーラビリティ、機能の拡張性、および絶対的な信頼性を重視し、コンピューティングや通信をターゲットとする多様なアプリケーションを可能にします。代表的なアプリケーションは次のとおりです。

• データ通信ネットワーク

• 電気通信ネットワーク

• ブロードバンドアプリケーション (有線/無線)

• ネットワークインターフェイスカード

• チップ間およびバックプレーンインターフェイスカード

• 多様なアプリケーションに対応するためのサーバーアドインカード

サポートされていない機能

PCI Express Base 仕様 3.1 には数多くのオプション機能があります。サポートされないこれら機能の一部を次に示します。

• アドレス変換サービスは実装されませんが、外部のソフトロジックに実装することは可能です。

• スイッチポート

• Resizable BAR (RBAR) の拡張機能

• 変換リクエストの NW (No Write) フラグ

• GTY トランシーバーには非対応

ライセンスおよび注文情報

UltraScale Devices Gen3 Integrated Block for PCIe コアは、ザイリンクスエンドユーザーライセンス規約のもと Vivado Design Suite を使用して追加コストなしで提供されています。この IP およびその他のザイリンクス LogiCORE™ IP に関する情報は、ザイリンクス IP コアページから入手できます。その他のザイリンクス LogiCORE IP モジュールおよびツールの価格や提供状況については、お近くのザイリンクス販売代理店にお問い合わせください。

このコアの詳細は、 UltraScale Gen3 Integrated Block for PCIe Express の製品ページを参照してください。


https://japan.xilinx.com/cgi-bin/docs/rdoc?t=eula

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

https://japan.xilinx.com/about/contact.html

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




第 2章

製品仕様

準拠する規格

UltraScale Devices Gen3 Integrated Block for PCIe ソリューションは、PCI Express® Card Electromechanical (CEM) v3.0 や PCI™ Industrial Computer Manufacturers Group (PICMG) v3.4 仕様 [参照 2] などの業界標準のアプリケーションフォームファクターと互換性があります。

リソースの使用

性能およびリソース使用状況の詳細は、 Performance and Resource Utilization (ウェブページ) をご覧ください。

デバイスの最低要件

このコアを使用するデバイスの低要件は次のとおりです。

表 2‐1:デバイスの最低要件

可能なリンクスピード可能なリンク幅サポートされるスピードグレード

Gen1 x1、 x2、 x4、 x8 -3、 -2、 -1、 -1L、 -1LV、 -1H、 -1HV

Gen2 x1、 x2、 x4、 x8 -3、 -2、 -1、 -1L、 -1LV、 -1H、 -1HV

Gen3 x1、 x2、 x4 -3、 -2、 -1、 -1L、 -1LV、 -1H、 -1HV(1)

Gen3 x8 -3、 -2、 -1、 -1H、 -1HV(2)(4)

注記:1. -1LV および -1L スピードグレードでは、 [Core Clock Frequency] を 250MHz に設定する必要があります。

[Core Clock Frequency] を 500MHz に設定できるのは -3 および -2 スピードグレードの場合のみです。

2. ユーザーデザインによっては、スピードグレード -1、 -1H および -1HV で Gen3x8 が可能ですが、タイミングクロージャの

工数が増えることがあります。 -1L および -1LV (0.9V および 0.95V) スピードグレードでは、 Gen3x8 はサポートされません。

3. エンジニアリングサンプル (ES) には、これ以外にも制約が存在することがあります。詳細は、該当するエラッタ文書を参照

してください。

4. -1L および -1LV スピードグレードがサポートされるのは Kintex UltraScale デバイスのみです。 -1H および -1HV スピードグレードがサポートされるのは Virtex UltraScale デバイスのみです。






第 2 章:製品仕様

利用可能な PCI Express 用統合ブロック

表 2-2 に、複数の統合ブロックを含んでいる FPGA で利用可能な PCI Express 用統合ブロックを一覧表示しています。場合によっては、統合ブロックに隣接してボンディングされた GTH トランシーバーサイトが不足するため、すべての統合ブロックが使用可能とは限りません。

表 2‐2:利用可能な PCI Express 用統合ブロック

デバイスの選択 PCI Express ブロックの場所

デバイスパッケージ X0Y0 X0Y1 X0Y2 X0Y3 X0Y4 X0Y5

XCKU025 FFVA1156 可

XCKU035(1)

FBVA676 可可可(2)


FFVA1156 可可可(2)

SFVA784 可

XCKU040



FFVA1156 可可可

SFVA784 可

XQKU040RBA676 可可可(2)

RFA1156 可可可

XCKU060FFVA1156 可可可

FFVA1517 可可可

XQKU060 RFA1156 可可可

XCKU085

FLVA1517 可可可可可

FLVB1760 可可可可可

FLVF1924 可可可可可

XCKU095

FFVB1760 可可可可


FFVA1156 可可可

FFVC1517 可可可可(2)

XQKU095 RFA1156 可可可

XCKU115

FLVA1517 可可可可可可(2)

FLVB1760 可可可可可可

FLVF1924 可可可可可可

FLVD1924 可可可(2) 可可可

FLVD1517 可可可可可可

FLVA2104 可可可可可可

FLVB2104 可可可可可可






XQKU115RLD1517 可可可可可可

RLF1924 可可可可可可

XCVU065 FFVC1517 可可

XCVU080

FFVA2104 可可可可




FFVD1517 可可可可

XCVU095

FFVA2104 可可可可



FFVC2104 可可可可


FFVD1517 可可可可

XCVU125

FLVB1760 可可可可

FLVB2104 可可可可

FLVC2104 可可可可

FLVA2104 可可可可

FLVD1517 可可可可

XCVU160FLGB2104 可可可可

FLGC2104(1) 可可可可可

XCVU190

FLGB2104 可可可可

FLGC2104 可可可可可可

FLGA2577 可可可可可可

XCVU440FLGA2892 可可可可可可

FLGB2377 可可可可可可

注記:1. ソフトウェアでサポートされる PCIe ブロックは、 XCKU035 デバイス (SFVA784 パッケージ以外) で 2 つ、 XCKU085 デバイス

で 4 つ、 XCVU160/FLGC2104 デバイスで 4 つのみです。

2. デバイス /パッケージの移行オプション [Enable GT Quad selection] が選択されている場合のみ利用可能です。「UltraScale デバイ

スの PCI Express デザインのパッケージ移行」を参照してください。

表 2‐2:利用可能な PCI Express 用統合ブロック (続き)

デバイスの選択 PCI Express ブロックの場所

デバイスパッケージ X0Y0 X0Y1 X0Y2 X0Y3 X0Y4 X0Y5






GT のロケーション

有効なデバイスとパッケージの組み合わせにおいて推奨される GT のロケーションは、付録 B 「GT のロケーション」を参照してください。パッケージピンは、付録 B に示す GT の X-Y ロケーションから直接得られます。表の内容と一致する選択したデバイスとパッケージの組み合わせに対して、 Vivado Design Suite が XDC を生成します。

推奨される GT ロケーションは、次を参照してください。

• Kintex UltraScale デバイスの GT ロケーション

• Virtex UltraScale デバイスの GT ロケーション

ポートの説明

このセクションでは、次のインターフェイスのポートについて説明します。

• AXI4-Stream コアインターフェイス

• その他のコアインターフェイス

AXI4‐Stream コアインターフェイス

64/128/256 ビットインターフェイス

ステータスインターフェイスと制御インターフェイスのほかに、このコアにはトランザクションの送信/受信に使用する AXI4-Stream インターフェイスが 4 つ必要です。このセクションでは、これらのインターフェイスについて説明します。

コンプリーターリクエストインターフェイス

コンプリーターリクエスト (CQ) インターフェイスを介して、リンクからのすべてのリクエストがユーザーアプリケーションに送信されます。表 2-3 では、コアの CQ インターフェイスのポートについて説明します。「幅」の列にある DW は、設定したデータバス幅 (64、 128、または 256 ビット ) を示します。

表 2‐3: コンプリーターリクエストインターフェイスのポートの説明

ポート方向幅説明

m_axis_cq_tdata 出力 DW

コンプリーターリクエストインターフェイス (CQ) からの送信データです。

インターフェイス幅が 128 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 64 ビットのみ使用されます。

コアは、インターフェイス幅が 128 ビットの場合、ビット [255:128] を 0 に固定し、インターフェイス幅が 64 ビットの場合、ビット [255:64] を 0 に固定します。

m_axis_cq_tuser 出力 85

CQ のユーザーデータです。

この信号セットには、送信される TLP のサイドバンド情報が含まれます。これらの信号は、 m_axis_cq_tvalid が High のときに有効になります。

このセットの各信号については、 14 ページの表 2-4 を参照してください。






m_axis_cq_tlast 出力 1

CQ データ用の TLAST を示す信号です。

コアは、パケットの後のビートでこの信号をアサートして、パケットの後を示します。シングルビートで TLP が送信される場合、コアは送信

の初のビートでこの信号をセットします。

m_axis_cq_tkeep 出力 DW/32

CQ データ用の TKEEP を示す信号です。

送信中にこのバスのビット i がアサートされると、 m_axis_cq_tdata バスの Dword i に有効なデータが含まれていることをユーザーアプリケーションに示します。コアは、ディスクリプターの初の Dword からペイロードの後の Dword まですべての Dword に対して、このビットを継続的に 1 にセットします。したがって、パケットのすべてのビートで、m_axis_cq_tdata が 1 にセットされます。ただし、パケットの合計サイズがデータバス幅の倍数値でない場合の後のビートは例外です (いずれも Dword 単位)。これは、ペイロード送信が Dword アライメントかつアドレスアライメントの場合に適用されます。


m_axis_cq_tvalid 出力 1

CQ のデータが有効であることを示します。

m_axis_cq_tdata バス上に有効なデータがある場合、コアはこの出力をアサートします。パケット送信中、この Valid 信号はアサートされた状態を保持します。ユーザーアプリケーションは、 m_axis_cq_tready 信号を使用してデータ送信を制御できます。

m_axis_cq_tready 入力 1

CQ のデータ Ready 信号です。

ユーザーロジックでこの信号を High にアサートすると、ユーザーアプリケーションがデータを受信する準備が整っていることをコアに示します。同じサイクルで m_axis_cq_tvalid と m_axis_cq_tready が両方ともアサートされると、インターフェイスを介してデータが送信されます。

m_axis_cq_tvalid が High のときにユーザーアプリケーションが Ready 信号をディアサートした場合、 Ready 信号がアサートされるまで、コアはバス上のデータを保持し、また Valid 信号をアサートした状態で保持します。

表 2‐3: コンプリーターリクエストインターフェイスのポートの説明 (続き)







表 2‐4: m_axis_cq_tuser のサイドバンド信号の説明

ビットインデックス

名称幅説明

3:0 first_be[3:0] 4

ペイロードの初の Dword 用のバイトイネーブル信号です。

このフィールドは、 TLP のトランザクション層ヘッダーの First_BE ビットの設定を反映しています。メモリ読み出しおよび I/O 読み出しの場合、これらの 4 ビットは初の Dword に読み出される有効なバイトを示します。メモリ書き込みおよび I/O 書き込みの場合、これらのビットはペイロードの初の Dword にある有効なバイトを示します。アトミック操作やペイロードを含むメッセージの場合、これらのビットはすべて 1 にセットされます。

このフィールドは、パケットの初のビートで有効になります。つまり、 sop と m_axis_cq_tvalid は両方とも High になります。

7:4 last_be[3:0] 4

後の Dword 用のバイトイネーブル信号です。

このフィールドは、 TLP のトランザクション層ヘッダーの Last_BE ビットの設定を反映しています。メモリ読み出しの場合、これらの 4 ビットは、データブロックの

後の Dword に読み出される有効なバイトを示します。メモリ書き込みの場合、これらのビットはペイロードの後の Dword にある有効なバイトを示します。アトミック操作やペイロードを含むメッセージの場合、これらのビットはすべて 1 にセットされます。

このフィールドは、パケットの初のビートで有効になります。つまり、 sop と m_axis_cq_tvalid は両方とも High になります。

39:8 byte_en[31:0] 32

ユーザーロジックは、オプションでこれらのバイトイネーブル信号を使用して、送信されるパケットのペイロード内で有効なバイトを判断できます。送信中にこのバスのビット i がアサートされると、 m_axis_cq_tdata バスのバイト i に有効なペイロードバイトが含まれていることを示します。このビットは、ディスクリプターバイトに対してアサートされません。

バイトイネーブル信号は、リクエストディスクリプター内の情報 (アドレスおよび長さ ) や first_be および last_be 信号の設定からユーザーロジックが生成できますが、ほかのインターフェイス信号から生成する代わりに、直接使用することも可能です。

ペイロードサイズが 2 Dword (8 バイト ) より大きい場合は、ペイロード用のこのバス上の 1 ビットは常に連続します。ペイロードサイズが 2 Dword またはそれより小さい場合は、 1 ビットは不連続になる場合があります。

特殊な例として、 PCI Express の仕様で定義されている長さ 0 のメモリ書き込みトランザクションでは、関連する 1 DW ペイロードが送信される間は byte_en ビットがすべて 0 となります。


40 sop 1パケットの開始を示します。

コアは、パケットの初のビートでこの信号をアサートして、パケットの開始を示します。この信号の使用はオプションです。

41 discontinue 1

内部 FIFO メモリから TLP ペイロードを読み出している間に訂正不可能なエラーを検出した場合に、コアは TLP の後のビートでこの信号をアサートします。このようなエラーがコアによって検出された場合、ユーザーアプリケーションはすべての TLP を破棄する必要があります。

TLP にペイロードがない場合に、この信号がアサートされることはありません。m_axis_cq_tlast が High になっているサイクルでのみアサートされます。

コアがエンドポイントとしてコンフィギュレーションされている場合、 Advanced Error Reporting (AER) 機能を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。






コンプリーターコンプリーションインターフェイス

コンプリーターコンプリーション (CC) インターフェイスを介して、ユーザーアプリケーションが生成したコンプリーションがコンプリーターリクエストに対応して送信されます。すべてのノンポステッドトランザクションをスプリットトランザクションとして処理できます。つまり、 CC インターフェイスは 1 つのリクエストに対してコンプリーションを送信しながら、リクエスターコンプリーションインターフェイスで新しいリクエストを連続して受信できます。表 2-5 では、コアの CC インターフェイスのポートについて説明します。「幅」の列にある DW は、設定したデータバス幅 (64、 128、または 256 ビット ) を示します。

42 tph_present 1このビットは、インターフェイスを介して送信されるリクエスト TLP の中に Transaction Processing Hint (TPH) があることを示します。このビットは、 sop と m_axis_cq_tvalid の両方が High のときに有効になります。

44:43 tph_type[1:0] 2TPH がリクエスト TLP 内にある場合、これらの 2 ビットがヒントと関連する PH[1:0] フィールドの値を提供します。これらのビットは、 sop と m_axis_cq_tvalid の両方が High のときに有効になります。

52:45 tph_st_tag[7:0] 8TPH がリクエスト TLP 内にある場合、この出力がヒントと関連する 8 ビットのステアリングタグを提供します。これらのビットは、 sop と m_axis_cq_tvalid の両方が High のときに有効になります。

84:53 parity 32

256 ビットの送信データ用の奇数パリティです。

ビット i は、 m_axis_cq_tdata のバイト i について計算された奇数パリティを提供します。インターフェイス幅が 128 ビットの場合は下位 16 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 8 ビットのみ使用されます。コアは、インターフェイス幅が 16 ビットの場合、ビット [31:128] を 0 に固定し、インターフェイス幅が 8 ビットの場合、ビット [31:64] を 0 に固定します。

表 2‐4: m_axis_cq_tuser のサイドバンド信号の説明 (続き)


名称幅説明

表 2‐5: コンプリーターコンプリーションインターフェイスのポートの説明


s_axis_cc_tdata 入力 DW

コンプリーターコンプリーションのデータバスです。

ユーザーアプリケーションからコアへ送信されるコンプリーションデータです。インターフェイス幅が 128 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 64 ビットのみ使用されます。

s_axis_cc_tuser 入力 33

コンプリーターコンプリーションのユーザーデータです。

この信号セットには、送信される TLP のサイドバンド情報が含まれます。これらの信号は、 s_axis_cc_tvalid が High のときに有効になります。


s_axis_cc_tlast 入力 1

コンプリーターコンプリーションデータ用の TLAST を示す信号です。

ユーザーアプリケーションは、パケットの後を示すためにパケットの後のサイクルでこの信号をアサートする必要があります。シングルビートで TLP が送信される場合、ユーザーアプリケーションは送信の初のサイクルでこの信号をセットする必要があります。






s_axis_cc_tkeep 入力 DW/32

コンプリーターコンプリーションデータ用の TKEEP を示す信号です。

送信中にこのバスのビット i がアサートされると、 s_axis_cc_tdata バスの Dword i に有効なデータが含まれていることをコアに示します。ディスクリプターの初の Dword からペイロードの後の Dword まですべての Dword に対して、このビットを継続的に 1 にセットします。したがって、パケットのすべてのビートで、 s_axis_cc_tdata が 1 にセットされます。ただし、パケットの合計サイズがデータバス幅の倍数値でない場合の後のビートは例外です (いずれも Dword 単位)。これは、ペイロード送信が Dword アライメントかつアドレスアライメントの場合に適用されます。

インターフェイス幅が 128 ビットの場合、ビット [7:4] はコアで使用されず、インターフェイス幅が 64 ビットの場合、ビット [7:2] はコアで使用されません。

s_axis_cc_tvalid 入力 1

コンプリーターコンプリーションデータの Valid 信号です。

s_axis_cc_tdata バス上に有効なデータがある場合、ユーザーアプリケーションはこの出力をアサートする必要があります。パケット送信中、この Valid 信号をアサートした状態で保持する必要があります。コアは、 s_axis_cc_tready 信号を使用してデータ送信を制御できます。

s_axis_cc_tready 出力 4

コンプリーターコンプリーションデータの Ready 信号です。

コアがこの信号をアサートすると、データの受信準備が整っていることを示します。同じサイクルで s_axis_cc_tvalid と s_axis_cc_tready が両方ともアサートされると、インターフェイスを介してデータが送信されます。

Valid 信号が High のときにコアが Ready 信号をディアサートした場合、 Ready 信号がアサートされるまで、ユーザーアプリケーションはバス上のデータを保持し、 Valid 信号をアサートした状態で保持する必要があります。

表 2‐5: コンプリーターコンプリーションインターフェイスのポートの説明 (続き)


表 2‐6: s_axis_cc_tuser のサイドバンド信号の説明


名称幅説明

0 discontinue 1

送信されているデータ内にエラー (メモリからペイロードを読み出している間に訂正不可能な ECC エラーなど) を検出した場合、ユーザーアプリケーションはこの信号をアサートしてパケットの送信を中断する必要があります。コアは、リンク上の対応する TLP を無効にしてデータ破損を回避します。

ユーザーアプリケーションは、送信中の任意のサイクルでこの信号をアサートできます。エラーが示された場所より前のサイクルでパケットを中断、またはペイロードのすべてのバイトがコアへ送信されるまで継続できます。後者の場合、ユーザーアプリケーションがパケットの終了より前に discontinue 信号をディアサートしても、パケットのその後のサイクルではコアはこのエラーをスティッキーエラーとして処理します。

discontinue 信号は、 s_axis_cc_tvalid が High の場合のみアサートされます。コアは、s_axis_cc_tready 信号が High の場合のみこの信号をサンプルします。したがって、この信号がアサートされた場合は、 s_axis_cc_tready が High になるまでディアサートしないでください。

コアがエンドポイントとしてコンフィギュレーションされている場合、 AER 機能を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。






リクエスターリクエストインターフェイス

リクエスターリクエスト (RQ) インターフェイスのポートを介して、ユーザーアプリケーションがリモートの PCIe® デバイスへリクエストを生成します。表 2-7 では、コアの RQ インターフェイスのポートについて説明します。「幅」の列にある DW は、設定したデータバス幅 (64、 128、または 256 ビット ) を示します。

32:1 parity 32

256 ビットデータ用の奇数パリティです。

コアでパリティチェックが有効の場合、ユーザーロジックはこのバスのビット i を s_axis_cc_tdata のバイト i について計算された奇数パリティに設定する必要があります。インターフェイス幅が 16 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 8 ビットの場合は下位 64 ビットのみ使用されます。

インターフェイスパリティエラーが検出された場合、これは訂正不可能な内部エラーとして記録され、そのパケットは破棄されます。 PCI Express Base Specification (6.2.9) には、次のように記述されています。「訂正不可能な内部エラーとは、コンポーネント内に生じるエラーであり、コンポーネントの不正動作を招きます。訂正不可能な内部エラーから回復する唯一の方法は、リセットまたはハードウェアの交換となります。」

コアでパリティチェックが有効に設定されていない場合は、パリティビットが永続的に 0 になります。

表 2‐6: s_axis_cc_tuser のサイドバンド信号の説明 (続き)


名称幅説明

表 2‐7: リクエスターリクエストインターフェイスのポートの説明


s_axis_rq_tdata 入力 DW

リクエスターリクエストのデータバスです。

この入力には、ユーザーアプリケーションからコアへのリクエスター側のリクエストデータが含まれます。インターフェイス幅が 128 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 64 ビットのみ使用されます。

s_axis_rq_tuser 入力 60

リクエスターリクエストのユーザーデータです。

この信号セットには、送信される TLP のサイドバンド情報が含まれます。これらの信号は、 s_axis_rq_tvalid が High のときに有効になります。


s_axis_rq_tlast 入力 1

リクエスターリクエストデータ用の TLAST を示す信号です。

ユーザーアプリケーションは、パケットの後を示すために TLP の後のサイクルでこの信号をアサートする必要があります。シングルビートで TLP が送信される場合、ユーザーアプリケーションは送信の初のサイクルでこの信号をセットする必要があります。

s_axis_rq_tkeep 入力 DW/32

リクエスターリクエストデータ用の TKEEP を示す信号です。

送信中にこのバスのビット i がアサートされると、 s_axis_rq_tdata バスの Dword i に有効なデータが含まれていることをコアに示します。ユーザーアプリケーションは、ディスクリプターの初の Dword からペイロードの後の Dword まですべての Dword に対して、このビットを継続的に 1 に

セットする必要があります。したがって、パケットのすべてのビートで、s_axis_rq_tdata が 1 にセットされます。ただし、パケットの合計サイズがデータバス幅の倍数値でない場合の後のビートは例外です (いずれも Dword 単位)。これは、ペイロード送信が Dword アライメントかつアドレスアライメントの場合に適用されます。

インターフェイス幅が 128 ビットの場合、ビット [7:4] はコアで使用されず、インターフェイス幅が 64 ビットの場合、ビット [7:2] はコアで使用されません。






s_axis_rq_tvalid 入力 1

リクエスターリクエストデータの Valid 信号です。

s_axis_rq_tdata バス上に有効なデータがある場合、ユーザーアプリケーションはこの出力をアサートする必要があります。パケット送信中、この Valid 信号をアサートした状態で保持する必要があります。コアは、s_axis_rq_tready 信号を使用してデータ送信を制御できます。

s_axis_rq_tready 出力 4

リクエスターリクエストデータの Ready 信号です。

コアがこの信号をアサートすると、データの受信準備が整っていることを示します。同じサイクルで s_axis_rq_tvalid と s_axis_rq_tready が両方ともアサートされると、インターフェイスを介してデータが送信されます。

Valid 信号が High のときにコアが Ready 信号をディアサートした場合、Ready 信号がアサートされるまで、ユーザーアプリケーションはバス上のデータを保持し、 Valid 信号をアサートした状態で保持する必要があります。

ユーザーは、4 つすべてのビットを 1 または 0 に割り当てることができます。

pcie_rq_seq_num 出力 4

リクエスターリクエスト TLP の送信シーケンス番号を示します。

オプションでこの出力を使用すると、コアの送信パイプライン内におけるリクエストの進捗状況を追跡できます。この機能を使用する場合は、seq_num[3:0] バスの各リクエストに対してシーケンス番号を与えます。ユーザーアプリケーションからコンプリーション TLP を送信できなくなるパイプライン内の地点にリクエスト TLP が到達すると、コアは、pcie_rq_seq_num[3:0] 出力にこのシーケンス番号を出力します。このメカニズムによって、コアの CC インターフェイスへ送信されるコンプリーションとリクエスターリクエストインターフェイスに送信されるポステッドリクエストの順序を管理できます。 pcie_rq_seq_num[3:0] 出力のデータは、 pcie_rq_seq_num_vld が High の場合に有効になります。

pcie_rq_seq_num_vld 出力 1リクエスターリクエスト TLP の送信シーケンス番号の Valid 信号です。

pcie_rq_seq_num[3:0] に有効なデータが配置されると、コアがこの出力を 1 サイクル間アサートします。

pcie_rq_tag 出力 6

リクエスターリクエストのノンポステッドタグです。

コアでノンポステッドリクエストのタグ管理が実行される場合 (AXISTEN_IF_ENABLE_CLIENT_TAG が 0 の場合)、コアはこの出力を使用し、受信した各ノンポステッドリクエストに対して割り当てられたタグを伝えます。このバスのタグ値は、 pcie_rq_tag_vld が High になる 1 サイクル間有効です。ユーザーは、このタグをコピーして使用し、コンプリーションデータとペンディングリクエストを結び付けることができます。

リクエストに対して割り当てられたタグを与えるため、s_axis_rq_tdata バス上にリクエストが送信されてからコアが pcie_rq_tag_vld をアサートするまでの間には数サイクルの遅延が生じます。この間、ユーザーアプリケーションは新しいリクエストを継続して送信できます。各リクエストのタグは、このバスを使用して FIFO 順序で伝達されるため、ユーザーアプリケーションは送信されたリクエストとタグの値を簡単に関連付けることができます。

pcie_rq_tag_vld 出力 1

リクエスターリクエストのノンポステッドタグの Valid 信号です。

リクエスターリクエストインターフェイスから入力されるノンポステッドリクエストにタグを割り当てて、 pcie_rq_tag 出力にそれが示されると、コアはこの出力を 1 サイクル間アサートします。

表 2‐7: リクエスターリクエストインターフェイスのポートの説明 (続き)







表 2‐8: s_axis_rq_tuser のサイドバンド信号の説明


名称幅説明

3:0 first_be[3:0] 4

初の Dword 用のバイトイネーブル信号です。

このフィールドは、リクエスト TLP のトランザクション層ヘッダーの First_BE ビットの設定に基づいて設定されます。メモリ読み出し、 I/O 読み出し、およびコンフィギュレーション読み出しの場合、これらの 4 ビットは初の Dword に読み出される有効なバイトを示します。メモリ書き込み、 I/O 書き込み、およびコンフィギュレーション書き込みの場合、これらのビットはペイロードの初の Dword にある有効なバイトを示します。

s_axis_rq_tvalid と s_axis_rq_tready が両方とも High になると、コアはパケットの初のサイクルでこのフィールドをサンプルします。

7:4 last_be[3:0] 4

後の Dword 用のバイトイネーブル信号です。

このフィールドは、 TLP のトランザクション層ヘッダーの Last_BE ビットの設定に基づいて設定されます。 2 Dword またはそれ以上のメモリ読み出しの場合、これらの 4 ビットは、データブロックの後の Dword に読み出される有効なバイトを示します。 2 Dword またはそれ以上のメモリ書き込みの場合、これらのビットはペイロードの後の Dword にある有効なバイトを示します。


10:8 addr_offset[2:0] 3

このインターフェイスでアドレスアライメントモードを利用している場合、ユーザーアプリケーションはペイロードデータが開始するデータバス上のバイトレーン番号を提供する必要があります (このサイドバンドバスのモジュロ 4)。これによって、コアは送信されるデータブロックのアライメントを判断できます。


リクエスターリクエストインターフェイスが Dword アライメントモードでコンフィギュレーションされている場合、このフィールドは常に 0 にセットされている必要があります。

ルートポートコンフィギュレーションでは、コンフィギュレーションパケットは常に DW0 にアラインされてなければならないため、このパケットタイプに対しては、このフィールドをどちらのアライメントモードでも 0 にセットする必要があります。

11 discontinue 1

送信されているデータ内にエラーを検出した場合、ユーザーアプリケーションは送信中にこの信号をアサートしてパケット送信を中断する必要があります。コアは、リンク上の対応する TLP を無効にしてデータ破損を回避します。

送信中の任意のサイクルでこの信号をアサートできます。エラーが示された場所より前のサイクルでパケットを中断、またはペイロードのすべてのバイトがコアへ送信されるまで継続できます。後者の場合、ユーザーアプリケーションがパケットの終了より前に discontinue 信号をディアサートしても、パケットのその後のサイクルではコアはこのエラーをスティッキーエラーとして処理します。

discontinue 信号は、 s_axis_rq_tvalid が High の場合のみアサートされます。コアは、 s_axis_rq_tready 信号が High の場合のみこの信号をサンプルします。したがって、この信号がアサートされた場合は、 s_axis_rq_tready が High になるまでディアサートしないでください。 discontinue 信号は、ノンポステッド TLP に対しては有効ではありません。送信中、ユーザーロジックは、初のサイクル以外の任意のサイクルでこの信号をアサートできます。

コアがエンドポイントとしてコンフィギュレーションされている場合、Advanced Error Reporting (AER) を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。






12 tph_present 1

このビットは、インターフェイスを介して送信されるリクエスト TLP の中に Transaction Processing Hint (TPH) があることを示します。 s_axis_rq_tvalid と s_axis_rq_tready が両方とも High になると、コアはパケットの初のサイクルでこのフィールドをサンプルします。

TPH 機能を使用しない場合、このビットは常に 0 にセットされる必要があります。

14:13 tph_type[1:0] 2

TPH がリクエスト TLP 内にある場合、これらの 2 ビットがヒントと関連する PH[1:0] フィールドの値を提供します。 s_axis_rq_tvalid と s_axis_rq_tready が両方とも High になると、コアはパケットの初のサイクルでこのフィールドをサンプルします。

tph_present が 0 にセットされている場合、これらのビットは任意の値に設定できます。

15 tph_indirect_tag_en 1

このビットが 1 の場合、コアはステアリングタグテーブルへのインデックスとして tph_st_tag[7:0] の下位ビットを使用し、送信されるリクエスト TLP にこのロケーションからのタグを挿入します。

このビットが 0 の場合、コアはステアリングタグとして tph_st_tag[7:0] の値を直接使用します。

s_axis_rq_tvalid と s_axis_rq_tready が両方とも High になると、コアはパケットの初のサイクルでこのビットをサンプルします。

tph_present が 0 にセットされている場合、このビットは任意の値に設定できます。

23:16 tph_st_tag[7:0] 8

TPH がリクエスト TLP 内にある場合、この出力がヒントと関連する 8 ビットのステアリングタグを提供します。 s_axis_rq_tvalid と s_axis_rq_tready が両方とも High になると、コアはパケットの初のサイクルでこのフィールドをサンプルします。

tph_present が 0 にセットされている場合、これらのビットは任意の値に設定できます。

27:24 seq_num[3:0] 4

オプションで、このフィールドに 4 ビットのシーケンス番号を提供すると、コアの送信パイプライン内におけるリクエストの進捗状況を追跡できます。リクエスト TLP がパイプラインを進み、コンプリーション TLP が越えることのできないステージに達すると、コアはこのシーケンス番号を pcie_rq_seq_num[3:0] に出力します。


ユーザーアプリケーションが、コアの pcie_rq_seq_num[3:0] 出力をモニタリングしていない場合には、この入力を 0 にハード接続できます。

表 2‐8: s_axis_rq_tuser のサイドバンド信号の説明 (続き)


名称幅説明






リクエスターコンプリーションインターフェイス

リクエスターコンプリーション (RC) インターフェイスを介して、リクエストに対応してリンクから受け取ったコンプリーションがユーザーアプリケーションに送信されます。表 2-9 では、コアの RC インターフェイスのポートについて説明します。「幅」の列にある DW は、設定したデータバス幅 (64、 128、または 256 ビット ) を示します。

59:28 parity 32

256 ビットデータ用の奇数パリティです。

コアでパリティチェックが有効の場合、ユーザーロジックはこのバスのビット i を s_axis_rq_tdata のバイト i について計算された奇数パリティに設定する必要があります。インターフェイス幅が 128 ビットの場合は下位 16 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 8 ビットのみ使用されます。

インターフェイスパリティエラーが検出された場合、これは訂正不可能な内部エラーとして記録され、そのパケットは破棄されます。 PCI Express Base Specification (6.2.9) には、次のように記述されています。「訂正不可能な内部エラーとは、コンポーネント内に生じるエラーであり、コンポーネントの不正動作を招きます。訂正不可能な内部エラーから回復する唯一の方法は、リセットまたはハードウェアの交換となります。」

コアでパリティチェックが有効に設定されていない場合は、パリティビットが永続的に 0 になります。

表 2‐8: s_axis_rq_tuser のサイドバンド信号の説明 (続き)


名称幅説明

表 2‐9: リクエスターコンプリーションインターフェイスのポートの説明


m_axis_rc_tdata 出力 DW

リクエスターコンプリーションのデータバスです。

コアのリクエスターコンプリーションインターフェイスからユーザーアプリケーションへデータを送信します。インターフェイス幅が 128 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 64 ビットの場合は下位 64 ビットのみ使用されます。


m_axis_rc_tuser 出力 75

リクエスターコンプリーションのユーザーデータです。

この信号セットには、送信される TLP のサイドバンド情報が含まれます。これらの信号は、 m_axis_rc_tvalid が High のときに有効になります。


m_axis_rc_tlast 出力 1

リクエスターコンプリーションデータ用の TLAST を示す信号です。

コアは、パケットの後のビートでこの信号をアサートして、パケットの後を示します。シングルビートで TLP が送信される場合、コアは送信の初のビートでこのビットをセットします。この出力は、ストラドルオプションが無効に設定されている場合のみ使用されます。ストラドルオプションが有効に設定されている場合 (256 ビットインターフェイスの場合)、常にコアはこの出力を 0 にセットします。






m_axis_rc_tkeep 出力 DW/32

リクエスターコンプリーションデータ用の TKEEP を示す信号です。

送信中にこのバスのビット i がアサートされると、 m_axis_rc_tdata バスの Dword i に有効なデータが含まれていることをコアに示します。コアは、ディスクリプターの初の Dword からペイロードの後の Dword まですべての Dword に対して、このビットを継続的に 1 にセットします。したがって、パケットのすべてのビートで、 m_axis_rc_tkeep が 1 にセットされます。ただし、パケットの合計サイズがデータバス幅の倍数値でない場合の後のビートは例外です (いずれも Dword 単位)。これは、ペイロード送信が Dword アライメントかつアドレスアライメントの場合に適用されます。


これらの出力は、インターフェイス幅が 256 ビットでストラドルオプションが有効に設定されている場合にすべて 1 となります。インターフェイスを介して送信されたコンプリーション TLP の開始および終了を判断する場合、ユーザーロジックは m_axis_rc_tuser のこの信号を使用する必要があります。

m_axis_rc_tvalid 出力 1

リクエスターコンプリーションデータの Valid 信号です。

m_axis_rc_tdata バス上に有効なデータがある場合、コアはこの出力をアサートします。パケット送信中、この Valid 信号はアサートされた状態を保持します。ユーザーアプリケーションは、 m_axis_rc_tready 信号を使用してデータ送信を制御できます。

m_axis_rc_tready 入力 1

リクエスターコンプリーションデータの Ready 信号です。

ユーザーロジックでこの信号を High にアサートすると、ユーザーアプリケーションがデータを受信する準備が整っていることをコアに示します。同じサイクルで m_axis_rc_tvalid と m_axis_rc_tready が両方ともアサートされると、インターフェイスを介してデータが送信されます。

Valid が High のときにユーザーアプリケーションが Ready 信号をディアサートした場合、 Ready 信号がアサートされるまで、コアはバス上のデータを保持し、また Valid 信号をアサートした状態で保持します。

表 2‐9: リクエスターコンプリーションインターフェイスのポートの説明 (続き)


表 2‐10: m_axis_rc_tuser のサイドバンド信号の説明


名称幅説明

31:0 byte_en 32

ユーザーロジックは、オプションでこれらのバイトイネーブル信号を使用して、送信されるパケットのペイロード内で有効なバイトを判断できます。送信中にこのバスのビット i がアサートされると、 m_axis_rc_tdata バスのバイト i に有効なペイロードバイトが含まれていることを示します。このビットは、ディスクリプターバイトに対してアサートされません。

バイトイネーブル信号は、リクエストディスクリプター内の情報 (アドレスおよび長さ ) からユーザーロジックが生成できますが、ほかのインターフェイス信号から生成する代わりに、直接使用することも可能です。 TLP のペイロードに対するこのバスの 1 ビットは常に連続します。

コアは、インターフェイス幅が 128 ビットの場合、ビット [31:16] を 0 に固定し、インターフェイス幅が 64 ビットの場合、ビット [31:8] を 0 に固定します。バイトイネーブルビットは、長さ 0 のメモリ読み出しリクエストに応答して受信されたコンプリーションでも設定されます。






32 is_sof_0 1

初のコンプリーション TLP の開始を示します。

64 ビットと 128 ビットインターフェイス、およびストラドルが無効に設定されている 256 ビットインターフェイスの場合、 TLP の開始を示すためにパケットの初のビートでコアが is_sof_0 をアサートします。これらのインターフェイスでは、 1 データビートで 1 TLP のみ開始可能であり、 is_sof_1 は常に 0 にセットされます。この信号の使用は、ストラドルオプションが無効の場合のみ有効です。

インターフェイス幅が 256 ビットでストラドルオプションが有効な場合、コアは同じビート内で 2 つのコンプリーション TLP をストラドルできます。この場合、コンプリーション TLP は AXI4-Stream パケットとしてフォーマットされません。 is_sof_0 のアサートは、ビート内におけるコンプリーション TLP の開始を示します。以前の TLP が現ビートよりも前に終了している場合、現コンプリーション TLP の初のバイトはバイトレーン 0 に含まれ、また以前の TLP が現ビートで継続している場合、コンプリーション TLP の初のバイトはバイトレーン 16 に含まれます。

33 is_sof_1 1

2 つ目のコンプリーション TLP の開始を示します。

インターフェイス幅が 256 ビットでストラドルオプションが有効な場合にこの信号が使用され、コアは同じビート内で 2 つのコンプリーション TLP をストラドルできます。その他の場合、この出力は常に 0 になります。

is_sof_1 のアサートは、ビート内における 2 つ目のコンプリーション TLP の開始を示します。このとき、初のバイトはバイトレーン 16 に含まれます。以前の TLP が同じビートの 0 ～ 15 のいずれかのバイト位置で終了している場合のみ、コアはバイト位置 16 で 2 つ目の TLP を開始します。つまり、同じビートで is_eof_0[0] もセットされている場合に限られます。

37:34 is_eof_0[3:0] 4

初のコンプリーション TLP の終了と後の Dword のオフセットを示します。

これらの出力は、インターフェイス幅が 256 ビットでストラドルオプションが有効に設定されている場合のみ使用されます。

ビット is_eof_0[0] のアサートは、現ビートにおける初のコンプリーション TLP の終了を示します。このビットがセットされると、 is_eof_0[3:1] がこの TLP の後の Dword のオフセットを提示します。

41:38 is_eof_1[3:0] 4

2 つ目のコンプリーション TLP の終了と後の Dword のオフセットを示します。

これらの出力は、インターフェイス幅が 256 ビットでストラドルオプションが有効に設定されている場合のみ使用されます。コアは、同じビート内で 2 つのコンプリーション TLP をストラドルできます。その他の場合、これらの出力は予約されています。

is_eof_1[0] のアサートは、同じビートにおける 2 つ目の TLP の終了を示します。is_eof_1 のビット 0 がセットされると、ビット [3:1] は現ビートで終了する TLP の後の Dword のオフセットを示します。2 つ目の TLP は、バイト位置 27 ～ 31 の間でのみ終了可能なため、 is_eof_1[3:1] は 2 つの値 (6 または 7) のいずれかとなります。

2 つ目の TLP の後のバイトのオフセットは、 TLP の開始アドレスと長さ、あるいはバイトイネーブル信号 byte_en[31:0] から判断できます。

is_eof_1[0] が High の場合、 is_eof_0[0] 信号と is_sof_1 信号も同じビート内で High になります。

表 2‐10: m_axis_rc_tuser のサイドバンド信号の説明 (続き)


名称幅説明






その他のコアインターフェイス

このセクションでは、その他のコアインターフェイスについて説明します。

コンフィギュレーションマネージメントインターフェイス

コンフィギュレーションマネージメントインターフェイスは、コンフィギュレーション空間レジスタに対して書き込みや読み出しを実行する際に使用します。表 2-11 では、コアのコンフィギュレーションマネージメントインターフェイスのポートについて説明します。

42 discontinue 1

内部 FIFO メモリから TLP ペイロードを読み出している間に訂正不可能なエラーを検出した場合に、コアは TLP の後のビートでこの信号をアサートします。このようなエラーがコアによって検出された場合、ユーザーアプリケーションはすべての TLP を破棄する必要があります。

TLP にペイロードがない場合に、この信号がアサートされることはありません。この信号は、ペイロード送信の後のビートでのみアサートされます (つまり、is_eof_0[0] が High の場合)。

ストラドルオプションが有効の場合、コアが discontinue 信号をアサートしていると 2 つ目の TLP が開始されません。

コアがエンドポイントとしてコンフィギュレーションされている場合、 Advanced Error Reporting (AER) 機能を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。

74:43 parity 32

256 ビットの送信データ用の奇数パリティです。

ビット i は、 m_axis_rc_tdata のバイト i について計算された奇数パリティを提供します。インターフェイス幅が 16 ビットの場合は下位 128 ビットのみ使用され、インターフェイス幅が 8 ビットの場合は下位 64 ビットのみ使用されます。コアは、インターフェイス幅が 16 ビットの場合、ビット [31:128] を 0 に固定し、インターフェイス幅が 8 ビットの場合、ビット [31:64] を 0 に固定します。

表 2‐10: m_axis_rc_tuser のサイドバンド信号の説明 (続き)


名称幅説明

表 2‐11: コンフィギュレーションマネージメントインターフェイスのポートの説明


cfg_mgmt_addr 入力 19

読み出し /書き込みアドレス

このアドレスは、コンフィギュレーションおよびマネージメントレジスタ空間内のアドレスであり、 Dword に揃っています。ローカルマネージメントバスからアクセスする場合: アドレスビット cfg_mgmt_addr[17:10] には、コンフィギュレーションレジスタと関係がある PCI ファンクションを選択します。ビット cfg_mgmt_addr[9:0] には、ファンクション内のレジスタを選択します。 PCI または PCI Express コンフィギュレーションレジスタへアクセスする場合は、アドレスビット cfg_mgmt_addr[18] が 0 にセットされ、ローカルマネジメントレジスタへアクセスする場合は、 1 にセットされる必要があります。

cfg_mgmt_write 入力 1書き込みイネーブル

書き込み動作に使用されます。アクティブ High。

cfg_mgmt_write_data 入力 32書き込みデータ

この書き込みデータを使用して、コンフィギュレーションおよびマネージメントレジスタを設定します。






コンフィギュレーションステータスインターフェイス

コンフィギュレーションステータスインターフェイスは、コアのコンフィギュレーション状況を示す情報 (ネゴシエートされたリンク幅やスピード、コアの電力ステート、コンフィギュレーションエラー ) を提供します。表 2-12 では、コアのコンフィギュレーションステータスインターフェイスのポートについて説明します。

cfg_mgmt_byte_enable 入力 4

バイトイネーブル

書き込みデータ用のバイトイネーブル信号であり、cfg_mgmt_byte_enable[0] は cfg_mgmt_write_data[7:0] に対応します。

cfg_mgmt_read 入力 1読み出しイネーブル

読み出し動作に使用されます。アクティブ High。

cfg_mgmt_read_data 出力 32読み出しデータの出力

この読み出しデータを使用して、コンフィギュレーションおよびマネージメントレジスタを設定します。

cfg_mgmt_read_write_done 出力 1読み出し /書き込み動作の完了

動作が完了すると、 1 サイクル間アサートされます。アクティブ High。

cfg_mgmt_type1_cfg_reg_access 入力 1

タイプ 1 RO、書き込み

コアがルートポートモードでコンフィギュレーションされている場合、タイプ 1 の PCI™ コンフィギュレーションレジスタへの書き込み動作中にこの入力をアサートすると、コンフィギュレーションレジスタ特定の読み出し専用フィールドへの書き込みを強制します (RC モードコンフィギュレーションレジスタの説明を参照)。コアがエンドポイントモードの場合、またはタイプ 1 コンフィギュレーションレジスタ以外への書き込み動作の場合、この入力は無効となります。

表 2‐11: コンフィギュレーションマネージメントインターフェイスのポートの説明 (続き)


表 2‐12: コンフィギュレーションステータスインターフェイスのポートの説明


cfg_phy_link_down 出力 1

コンフィギュレーションリンクのダウン状態

物理層 LTSSM に基づく PCI Express リンクのステータスです。

• 1b: リンクはダウン状態 (LinkUp ステートの変数は 0b)

• 0b: リンクはアップ状態 (LinkUp ステートの変数は 1b)

注記: 『PCI Express Base Specification (rev. 3.0)』 [参照 2] によると、 LinkUp は、

Recovery、 L0、 L0s、 L1、および L2 cfg_ltssm ステートの場合に 1b になりま

す。コンフィギュレーションステートの場合には 0b または 1b のいずれかに

なります。 [Detect] → [Polling] → [Configuration] からコンフィギュレーションステートへ遷移する場合は、常に 0b になります。その他のステート遷移を

経てコンフィギュレーションステートへ到達すると、 LinkUp は 1b になりま

す。

注記: リセット信号がアサートされた場合は、リリースされるまでこの信号の

出力は 0b を保持します。






cfg_phy_link_status 出力 2

コンフィギュレーションリンクのステータス

PCI Express リンクのステータスです。

• 00b: レシーバーの検出なし

• 01b: リンクトレーニング中

• 10b: リンクアップ状態。 DL 初期化実行中

• 11b: リンクアップ状態。 DL 初期化完了

cfg_negotiated_width 出力 4

コンフィギュレーションリンクのステータスを示します。

Negotiated Link Width: PCI Express のリンクステータスレジスタの Negotiated Link Width フィールドです。このフィールドの出力は、指定された PCI Express リンクのネゴシエートされた幅を示し、cfg_phy_link_status[1:0] == 11b (DL 初期化完了) の場合に有効になります。

ネゴシエートされたリンク幅の値:

• 0001b = x1

• 0010b = x2

• 0100b = x4

• 1000b = x8

その他の値は予約されています。

cfg_current_speed 出力 3

現在のリンクスピード

この信号は、リンクステータスレジスタのビット (1-0) から現在のリンクスピードを出力します。このフィールドでは、指定した PCI Express リンクのネゴシエートされたスピードを示します。

• 001b: 2.5GT/s PCI Express リンク




cfg_max_payload 出力 3

大ペイロードサイズ

この信号は、デバイス制御レジスタのビット (7-5) からの大ペイロードサイズを出力します。このフィールドでは、大の TLP ペイロードサイズを設定します。レシーバーとして、ロジックは設定値と同じ規模の TLP に対応する必要があります。ロジックは、トランスミッターとして、設定値を超える TLP を生成できません。

• 000b: 128 バイトの大ペイロードサイズ







表 2‐12: コンフィギュレーションステータスインターフェイスのポートの説明 (続き)







cfg_max_read_req 出力 3

大読み出しリクエストサイズ

この信号は、デバイス制御レジスタのビット (14-12) からの大読み出しリクエストサイズを出力し、このフィールドでは、リクエスターとして機能するロジックの大読み出しリクエストサイズを設定します。ロジックは、設定値を超えるサイズの読み出しリクエストを生成できません。

• 000b: 128 バイトの大読み出しリクエストサイズ







cfg_function_status 出力 16

コンフィギュレーションファンクションステータス

これらの出力は、各ファンクションの PCI コンフィギュレーション空間にあるコマンドレジスタビットのステートを示します。これらの出力を使用して、ホストロジックからのリクエストやコンプリーションを有効化します。これらのビットの割り当ては次のとおりです。

• ビット 0: ファンクション 0 の I/O 空間は有効

• ビット 1: ファンクション 0 のメモリ空間は有効

• ビット 2: ファンクション 0 のバスマスターは有効

• ビット 3: ファンクション 0 の INTx は無効

• ビット 4: ファンクション 1 の I/O 空間は有効

• ビット 5: ファンクション 1 のメモリ空間は有効

• ビット 6: ファンクション 1 のバスマスターは有効

• ビット 7: ファンクション 1 の INTx は無効

• ビット [15:8] は予約されています。

cfg_vf_status 出力 16

コンフィギュレーション Virtual Function ステータス

これらの出力は、 Virtual Function のステータスを 1 つの Virtual Function に対して 2 ビットで出力します。

• ビット 0: Virtual Function 0: ソフトウェアでコンフィギュレーション/有効化

• ビット 1: Virtual Function 0: PCI コマンドレジスタ、バスマスターイネーブル

• ビット [15:12] は予約されています。

cfg_function_power_state 出力 12

コンフィギュレーションファンクションの電力ステート

これらの出力は、 Physical Function の現在の電力ステートを示します。ビット [2:0] は、ファンクション 0 の電力ステートをキャプチャし、ビット [5:3] はファンクション 1 の電力ステートをキャプチャします。ビット [11:6] は予約されています。電力ステートの定義は次のとおりです。

• 000: D0_uninitialized

• 001: D0_active

• 010: D1

• 100: D3_hot








cfg_vf_power_state 出力 24

コンフィギュレーション Virtual Function の電力ステート

これらの出力は、 Virtual Function の現在の電力ステートを示します。ビット [2:0] は、 Virtual Function 0 の電力ステートをキャプチャし、ビット [5:3] は Virtual Function 1 の電力ステートをキャプチャします。ビット [23:18] は予約されています。電力ステートの定義は次のとおりです。

• 000: D0_uninitialized

• 001: D0_active

• 010: D1

• 100: D3_hot

cfg_link_power_state 出力 2

PCI Express リンクの現在の電力ステートを示します。

• 00: L0

• 01: L0s

• 10: L1

• 11: L2/予約済み

cfg_err_cor_out 出力 1

訂正可能なエラーを検出した

エンドポイントモードの場合、訂正可能なエラーを検出し、レポートがマスクされていない場合に、コアはこの出力を 1 サイクル間アサートします。マルチファンクションエンドポイントの場合は、すべてのファンクションのデバイスステータスレジスタにある訂正可能なエラーのステータスビットの論理 OR となります。

ルートポートモードの場合、ローカルに訂正可能なエラーを検出し、そのレポートがマスクされていない場合に、この出力がアサートされます。この出力は、リモートデバイスが PCI Express エラーメッセージを使用して示したエラー信号に対して応答しません。これらのエラーメッセージは、メッセージインターフェイスを介して提供されます。

注記: このステータス出力はリンク /スピードの設定によっては不正確なこと

があります。

cfg_err_nonfatal_out 出力 1

非致命的エラーを検出した

エンドポイントモードの場合、非致命的エラーを検出し、レポートがマスクされていない場合に、コアはこの出力を 1 サイクル間アサートします。マルチファンクションエンドポイントの場合は、すべてのファンクションのデバイスステータスレジスタにある非致命的エラーのステータスビットの論理 OR となります。

ルートポートモードの場合、特定場所に非致命的エラーを検出し、そのレポートがマスクされていない場合に、この出力がアサートされます。この出力は、リモートデバイスが PCI Express エラーメッセージを使用して示したエラー信号に対して応答しません。これらのエラーメッセージは、メッセージインターフェイスを介して提供されます。


があります。








cfg_err_fatal_out 出力 1

致命的エラーを検出した

エンドポイントモードの場合、致命的エラーを検出し、そのレポートがマスクされていない場合に、コアはこの出力を 1 サイクル間アサートします。マルチファンクションエンドポイントの場合は、すべてのファンクションのデバイスステータスレジスタにある致命的エラーのステータスビットの論理 OR となります。

ルートポートモードの場合、特定場所に致命的エラーを検出し、そのレポートがマスクされていない場合に、この出力がアサートされます。この出力は、リモートデバイスが PCI Express エラーメッセージを使用して示したエラー信号に対して応答しません。これらのエラーメッセージは、メッセージインターフェイスを介して提供されます。


があります。

cfg_ltr_enable 出力 1

LTR (Latency Tolerance Reporting) 機能のイネーブル信号です。

この出力ステートは、 Physical Function 0 のデバイス制御 2 レジスタにある LRT メカニズムのイネーブルビットの設定を示します。コアがエンドポイントとしてコンフィギュレーションされている場合、ロジックはこの出力を使用して LTR メッセージの生成を有効にします。コアがルートポートとしてコンフィギュレーションされている場合、この出力は使用されません。

pcie_rq_tag_av 出力 2 利用可能な送信フロー制御タグ。 1 つ以上のタグが利用可能な場合は 1。

pcie_tfc_nph_av 出力 2

送信フロー制御の利用可能なノンポステッドヘッダークレジットを示します。

00 - 利用可能なクレジットが 0 以下01 - 1 つのクレジットが利用可能10 - 2 つのクレジットが利用可能11 - 3 つ以上のクレジットが利用可能








cfg_ltssm_state 出力 6

LTSSM ステート。現在の LTSSM の状態を示します。

00: Detect.Quiet01: Detect.Active02: Polling.Active03: Polling.Compliance04: Polling.Configuration05: Configuration.Linkwidth.Start06: Configuration.Linkwidth.Accept07: Configuration.Lanenum.Accept08: Configuration.Lanenum.Wait09: Configuration.Complete0A: Configuration.Idle0B: Recovery.RcvrLock0C: Recovery.Speed0D: Recovery.RcvrCfg0E: Recovery.Idle10: L011: Rx_L0s.Entry

12: Rx_L0s.Idle

13: Rx_L0s.FTS

14: Tx_L0s.Entry

15: Tx_L0s.Idle

16: Tx_L0s.FTS

17: L1.Entry

18: L1.Idle

19: L2.Idle

1A: L2.TransmitWake

20: 無効

21: Loopback_Entry_Master

22: Loopback_Active_Master

23: Loopback_Exit_Master

24: Loopback_Entry_Slave

25: Loopback_Active_Slave

26: Loopback_Exit_Slave

27: Hot_Reset

28: Recovery_Equalization_Phase0

29: Recovery_Equalization_Phase1

2a: Recovery_Equalization_Phase2

2b: Recovery_Equalization_Phase3

cfg_rcb_status 出力 4

RCB ステータス信号です。

各 Physical Function のリンクコンロトールレジスタにある RCB (Read Completion Boundary) ビットの設定を示します。エンドポイントモードの場合、ビット 0 は Physical Function 0 (PF 0) の RCB を、ビット 1 は PF1 の RCB を示します (以降同様)。RC モードの場合、ビット 0 は RP のリンク制御レジスタの RCB の設定を示し、ビット 1 は予約されています。

各ビットで、0 は 64 バイトの RCB を示し、1 は 128 バイトを示します。








cfg_pl_status_change 出力 1

ルートポートモードのコアで使用される出力で、次のいずれかのリンクトレーニング関連のイベントを示します。

(a) リンク幅や動作スピードが変更された結果としてリンク帯域幅が変更され、その変更はリンクパートナーによってではなく、ローカルで行われ、リンクは無効になっていません。この割り込み信号は、リンク制御レジスタの Link Bandwidth Management Interrupt Enable ビットによって有効化されます。この割り込み信号のステータスは、リンク制御レジスタの Link Bandwidth Management Status ビットから読み出すことが可能です。

(b) リンク幅や動作スピードが変更された結果としてリンク帯域幅が自動的に変更され、その変更はリモートのノードによって実行されています。この割り込み信号は、リンク制御レジスタの Link Autonomous Bandwidth Interrupt Enable ビットによって有効化されます。この割り込み信号のステータスは、リンクステータスレジスタの Link Autonomous Bandwidth Status ビットから読み出すことが可能です。

(c) リモートノードからリンクイコライゼーションリクエストを受信したため、ハードウェアによってリンクステータス 2 レジスタの Link Equalization Request ビットがセットされました。この割り込み信号は、リンク制御 3 レジスタの Link Equalization Interrupt Enable ビットによって有効化されます。この割り込み信号のステータスは、リンクステータス 2 レジスタの Link Equalization Request ビットから読み出すことが可能です。

コアがエンドポイントとしてコンフィギュレーションされている場合、 pl_interrupt 出力は非アクティブとなります。

cfg_tph_requester_enable 出力 4

この出力のビット 0 は、 Physical Function 0 の TPH リクエスターの機能構造体にある TPH リクエスター制御レジスタの TPH Requester Enable ビット [8] の設定を示します。ビット 1 は、 Physical Function 1 に対応します。ほかの Physical Function についても同様ですビット [3:2] は予約されています。

cfg_tph_st_mode 出力 12

この出力のビット [2:0] は、Physical Function 0 の TPH リクエスター制御レジスタにある ST Mode Select ビットの設定を示します。ビット [5:3] は、 PF 1 の同レジスタフィールドの設定を示します。ほかの Physical Function についても同様ですビット [11:6] は予約されています。

cfg_vf_tph_requester_enable 出力 8

この出力の各ビットは、対応する Virtual Function の TPH リクエスター機能構造体にある TPH リクエスター制御レジスタの TPH Requester Enable ビット 8 の設定を示します。ビット [7:6] は予約されています。

cfg_vf_tph_st_mode 出力 24

この出力のビット [2:0] は、 Virtual Function 0 の TPH リクエスター制御レジスタにある ST Mode Select ビットの設定を示します。ビット [5:3] は、 VF 1 の同レジスタフィールドの設定を示します。ビット [23:18] は予約されています。








pcie_cq_np_req 入力 1

CQ のノンポステッドリクエストを示します。

この入力は、ユーザーアプリケーションがノンポステッドリクエストの送信を要求する際に使用されます。コアは、クレジットベースのフロー制御メカニズムを実装して、ポステッド TLP のブロッキングを行わずにインターフェイス上でノンポステッドリクエストの送信を制御します。

この入力信号は、内部のクレジット数を制御します。クレジット数は、 pcie_cq_np_req が High になる場合の各クロックサイクルでインクリメントされ、インターフェイスで各ノンポステッドリクエストが送信されるとデクリメントされます。クレジット数が 0 になると、コアは一時的にユーザーアプリケーションへのノンポステッドリクエストの送信を停止します。ノンポステッドリクエストの送信が一時停止した場合でも、リンクから受信したポステッド TLP を継続的に送信します。

ユーザーアプリケーションは、ノンポステッドリクエストを受信できる状態になるたびに pcie_cq_np_req に 1 サイクルのパルスを提供するか、ノンポステッドリクエストに対する選択的なバックプレッシャーを実行する必要がない場合は永久的にアサートされた状態を保持できます。

pcie_cq_np_req 信号のアサートおよびディアサートは、コンプリーターリクエストインターフェイス上のパケット送信と揃う必要はありません。 m_axis_rc_tuser にコンプリーションが現れ、コンプリーションで返されたタグを再利用するには少なくとも user_clk の 5 サイクル分必要です。

pcie_cq_np_req_count 出力 6

CQ のノンポステッドリクエスト数を示します。

この出力は、ユーザーアプリケーションへのノンポステッドリクエストの送信に関して、コアが管理するクレジットカウント値を提供します。コアは、このクレジットカウント値が 0 以外の場合のみ、コンプリーターリクエストインターフェイスを介してノンポステッドリクエストを送信します。このカウンターは 32 が大値です。

内部パイプラインの遅延が原因となり、コアが pcie_cq_np_req 入力でのパルスを受信してから pcie_cq_np_req_count 出力をアップデートするまでの間には数サイクルの遅延が生じます。

このカウントは、 user_reset および user_lnk_up のディアサートによってリセットされます。








コンフィギュレーション受信メッセージインターフェイス

コンフィギュレーション受信メッセージインターフェイスは、リンクからのデコード可能なメッセージ、データに関連するパラメーター、メッセージタイプをロジックに提示します。表 2-13 では、コアのコンフィギュレーション受信メッセージインターフェイスのポートについて説明します。

pcie_tfc_nph_av 出力 2

この出力は、コアの送信側においてノンポステッド TLP 用に現在有効なヘッダークレジットを示します。ユーザーロジックは、リクエスターリクエストインターフェイスでノンポステッドリクエストを送信する前にこの出力をチェックして、クレジットが利用できない場合のインターフェイスのブロッキングを回避できます。エンコードは次のとおりです。

• 00: 使用可能なクレジットはない

• 01: 1 クレジットが使用可能


• 11: 3 以上のクレジットが使用可能

パイプライン遅延により、この出力の値には、後の 2 サイクル以内のノンポステッドリクエストで使用されたクレジットを含めることができません。ユーザーロジックは、前のクロックサイクルでノンポステッドリクエストを送信した場合、そこで使用されたクレジットを考慮してこの出力の値を調整する必要があります。

pcie_tfc_npd_av 出力 2

この出力は、コアの送信側においてノンポステッド TLP 用に現在有効なペイロードクレジットを示します。ユーザーロジックは、リクエスターリクエストインターフェイスでノンポステッドリクエストを送信する前にこの出力をチェックして、クレジットが利用できない場合のインターフェイスのブロッキングを回避します。エンコードは次のとおりです。

• 00: 使用可能なクレジットはない



• 11: 3 以上のクレジットが使用可能

パイプライン遅延により、この出力の値には、後の 2 クロックサイクル以内にユーザーロジックによって送信されたノンポステッドリクエストで使用されたクレジットは含まれません。ユーザーロジックは、前のクロックサイクルでノンポステッドリクエストを送信した場合、そこで使用されたクレジットを考慮してこの出力の値を調整する必要があります。








コンフィギュレーション送信メッセージインターフェイス

コンフィギュレーション送信メッセージインターフェイスは、ユーザーアプリケーションがコアへメッセージを送信するために使用します。ユーザーアプリケーションが送信メッセージタイプとデータ情報をコアへ提供し、コアが Done 信号で応答します。表 2-14 では、コアのコンフィギュレーション送信メッセージインターフェイスのポートについて説明します。

表 2‐13: コンフィギュレーション受信メッセージインターフェイスのポートの説明


cfg_msg_received 出力 1

デコード可能なメッセージの受信を示します。

リンクからデコード可能なメッセージを受信すると、コアはこの出力を 1 サイクルまたは複数サイクル連続してアサートします。アサートされるサイクル数は、メッセージタイプによって異なります。コアは、 cfg_msg_received が High を保持する 1 サイクルまたは複数サイクルの間に、 cfg_msg_data[7:0] 出力のメッセージに関するパラメーターを送信します。表 3-18 では、各メッセージタイプにおける cfg_msg_received 信号のアサートサイクル数、および各サイクルで cfg_msg_data[7:0] に送信されるパラメーターについて説明しています。

cfg_msg_received インターフェイスが有効の場合、コアはこのインターフェイスを介して送信する 2 つの連続メッセージの間に少なくとも 1 サイクルの間隔を挿入します。

コンフィギュレーション受信メッセージインターフェイスは、Vivado IDE でコアをコンフィギュレーションする間、有効になる必要があります。

cfg_msg_received_data 出力 8このバスは、受信したメッセージに関連するパラメーターを送信する場合に使用します。各サイクルで伝搬されるメッセージタイプ別の情報については、表 3-18 を参照してください。

cfg_msg_received_type 出力 5

受信したメッセージのタイプを示します。

cfg_msg_received が High の場合、これらの 5 つのビットは、コアが送信するメッセージタイプを示します。メッセージタイプの一覧は、表 3-17 を参照してください。

表 2‐14: コンフィギュレーション送信メッセージインターフェイスのポートの説明


cfg_msg_transmit 入力 1

コンフィギュレーション送信におけるエンコードされたメッセージを示します。

この信号は、 cfg_msg_transmit_type と共にアサートされ、エンコードされたメッセージタイプと cfg_msg_transmit_data を提供します。また、応答信号の cfg_msg_transmit_done がアサートされるまで、メッセージに関連する任意の情報を提供します。

cfg_msg_transmit_type 入力 3

コンフィギュレーション送信におけるエンコードされたメッセージタイプを示します。

送信される PCI Express メッセージのタイプを示します。サポートされるエンコードは次のとおりです。

• 000b: LTR (Latency Tolerance Reporting)

• 001b: OBFF (Optimized Buffer Flush/Fill)

• 010b: SSPL (Set Slot Power Limit)

• 011b: PM PME (Power Management)

• 100b ～ 111b: 予約






コンフィギュレーションフロー制御インターフェイス

表 2-15 では、コアのコンフィギュレーションフロー制御インターフェイスのポートについて説明します。

cfg_msg_transmit_data 入力 32

コンフィギュレーション送信におけるエンコードされたメッセージデータを示します。

特定のメッセージタイプに関連するメッセージデータを示します。

• 000b: LTR - cfg_msg_transmit_data[31] < Snoop Latency の要件cfg_msg_transmit_data[28:26] < Snoop Latency の大きさ、cfg_msg_transmit_data[25:16] < Snoop Latency の値、cfg_msg_transmit_data[15] < No-Snoop Latency の要件、cfg_msg_transmit_data[12:10] < No-Snoop Latency の大きさ、 cfg_msg_transmit_data[9:0] < No-Snoop Latency の値

• 001b: OBFF - cfg_msg_transmit_data[3:0] < OBFF コード

• 010b: SSPL - cfg_msg_transmit_data[9:0] < {Slot Power Limit の大きさ、Slot Power Limit の値}

• 011b: PM_PME - cfg_msg_transmit_data[1:0] < PF1、 PF0。cfg_msg_transmit_data[9:4] < VF5、 VF4、 VF3、 VF2、 VF1、 VF0 (1 またはそれ以上の PF もしくは VF が同時に PM_PME 信号をパルス可能)

• 100b ～ 111b: 予約

cfg_msg_transmit_done 出力 1

コンフィギュレーション送信におけるエンコードされたメッセージの完了を示します。

cfg_mg_transmit のアサートに応答し、リクエスト完了後に 1 サイクル間アサートされます。

表 2‐14: コンフィギュレーション送信メッセージインターフェイスのポートの説明 (続き)


表 2‐15: コンフィギュレーションフロー制御インターフェイスのポートの説明


cfg_fc_ph 出力 8

ポステッドヘッダーフロー制御クレジットを示します。

この出力は、ポステッドヘッダーフロー制御クレジットの数を示します。この多重化された出力を使用して、コアによって維持されているポステッドヘッダークレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、 cfg_fc_sel[2:0] 入力で選択されます。

cfg_fc_pd 出力 12

ポステッドデータフロー制御クレジットを示します。

この出力は、ポステッドデータフロー制御クレジットの数を示します。この多重化された出力を使用して、コアによって維持されているポステッドデータクレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、 cfg_fc_sel[2:0] 入力で選択されます。

cfg_fc_nph 出力 8

ノンポステッドヘッダーフロー制御クレジットを示します。

この出力は、ノンポステッドヘッダーフロー制御クレジットの数を示します。この多重化された出力を使用して、コアによって維持されているノンポステッドヘッダークレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、 cfg_fc_sel[2:0] 入力で選択されます。






各ファンクションステータスインターフェイス

ファンクションステータスインターフェイスは、選択したファンクションを介してユーザーアプリケーションからのリクエストを受けて、ステータスデータを提供します。表 2-16 および表 2-17 では、コアのファンクションステータスインターフェイスのポートについて説明します。

cfg_fc_npd 出力 12

ノンポステッドデータフロー制御クレジットを示します。

この出力は、ノンポステッドデータフロー制御クレジットの数を示します。この多重化された出力を使用して、コアによって維持されているノンポステッドデータクレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、 cfg_fc_sel[2:0] 入力で選択されます。

cfg_fc_cplh 出力 8

コンプリーションヘッダーフロー制御クレジットを示します。

この出力は、コンプリーションヘッダーフロー制御クレジット数を示します。この多重化された出力を使用して、コアによって維持されているコンプリーションヘッダークレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、cfg_fc_sel[2:0] 入力で選択されます。

cfg_fc_cpld 出力 12

コンプリーションデータフロー制御クレジットを示します。

この出力は、コンプリーションデータフロー制御クレジットの数を示します。この多重化された出力を使用して、コアによって維持されているコンプリーションデータクレジットに関連するさまざまなフロー制御パラメーターおよび変数を引き出すことができます。このコアに使用するフロー制御情報は、 cfg_fc_sel[2:0] 入力で選択されます。

cfg_fc_sel 入力 3

フロー制御情報を選択します。

これらの入力でフロー制御のタイプを選択して、コアの cfg_fc_* 出力に示します。これらの入力の設定のためにアクセス可能なさまざまなフロー制御パラメーターおよび変数は、次のとおりです。

• 000: リンクパートナーが現在利用できる受信クレジット

• 001: 受信クレジットの制限

• 010: 使用した受信クレジット

• 011: 受信バッファー内の使用可能な空間

• 100: 使用可能な送信クレジット

• 101: 受信クレジットの制限

• 110: 使用した送信クレジット

• 111: 予約

この値は、受信 FIFO の未使用クレジットを示します。この値は、初に示したクレジット制限値に対して、受信 FIFO がどの程度フル状態 (¼ フル、 ½ フル、 ¾ フル、フル) であるかを示すための大まかな指標としてのみ使用することを推奨します。

注記:使用可能な送信クレジットの無限クレジット (cfg_fc_sel == 3'b100) は、ヘッダークレ

ジットとデータクレジットにそれぞれ 8'h80、 12'h800 として示されます。その他すべての cfg_fc_sel 選択では、無限クレジットはヘッダークレジットとデータクレジットにそれぞれ 8'h00、 12'h000 として示されます。

表 2‐15: コンフィギュレーションフロー制御インターフェイスのポートの説明 (続き)







表 2‐16: ファンクションステータスインターフェイスのポートの概要


cfg_per_func_status_control 入力 3

コンフィギュレーションの各ファンクション制御を示します。

複数ファンクションの出力 cfg_per_func_status_data に提供される情報を制御します。サポートされるエンコードは、 000b、 001b、010b、 011b、 100b、および 101b です。その他すべてのエンコードは予約されています。

cfg_per_func_status_data 出力 16

コンフィギュレーションの各ファンクションステータスデータを示します。

選択したファンクションに対して 16 ビットのステータス出力を提供します。cfg_per_func_status_control および cfg_per_function_number の値に基づいて情報が提供されます。

表 2‐17: ファンクションステータスインターフェイスのポートの説明

cfg_per_func_status_control

[ビット ]

cfg_per_func_status_data

[ビット /スライス]ステータス出力幅説明

0 0cfg_command_io_enable

1

コンフィギュレーションコマンド - I/O Space Enable: Command[0]

エンドポイント : 1 の場合、デバイスは I/O 空間へのアクセスリクエストを受けることができます。それ以外の場合、コアはこれらをフィルタリングし、 UR (サポートされないリクエスト ) として処理します。

ルート /スイッチ: コアは、この設定に基づいて動作するわけではありません。 0 の場合、ロジックは TLP ダウンストリームを生成できません。

0 1cfg_command_mem_enable

1

コンフィギュレーションコマンド - Memory Space Enable:

Command[1]

エンドポイント : 1 の場合、デバイスはメモリ空間へのアクセスリクエストを受けることができます。それ以外の場合、コアはこれらをフィルタリングし、 UR (サポートされないリクエスト ) として処理します。

ルート /スイッチ: コアは、この設定に基づいて動作するわけではありません。 0 の場合、ロジックは TLP ダウンストリームを生成できません。

0 2cfg_command_bus_master_enable

1

コンフィギュレーションコマンド - Bus Master Enable: Command[2]

コアは、この設定に基づいて動作するわけではありません。ロジックはこれに対応する必要があります。

エンドポイント : アサートされている間、ロジックはメモリまたは I/O リクエスト (MSI/X 割り込みなど) を発行できます。アサートされていない場合、これらのリクエストを発行しないでください。

ルート /スイッチ: アサートされている間、受信したメモリまたは I/O リクエストはアップストリームへ転送されます。アサートされていない場合、これらは UR (サポートされないリクエスト ) として処理され、ノンポステッドリクエストの場合には UR コンプリーションステータスを示すコンプリーションが返されます。






0 3cfg_command_interrupt_disable

1

コンフィギュレーションコマンド - Interrupt Disable:

Command[10]

アサートされた場合、コアは INTx 割り込みをアサートできません。

0 4cfg_command_serr_en

1

コンフィギュレーションコマンド - SERR Enable: Command[8]

アサートされていると、このビットによって非致命的/致命的エラーのレポート機能が有効になります。このビットで、あるいはデバイス制御レジスタの PCI Express 特定ビットで有効化されている場合のみ、エラーがレポートされることに留意してください。また、ルートコンプレックスやスイッチの場合、このビットは、セカンダリインターフェイスから転送された ERR_NONFATAL および ERR_FATAL エラーメッセージのプライマリインターフェイスによる転送を制御します。

0 5 cfg_bridge_serr_en 1

コンフィギュレーションブリッジ制御 - SERR Enable: Bridge Ctrl[1]

アサートされた場合、このビットによって訂正可能なエラー、非致命的エラー、および致命的エラー (ユーザーが強制する必要がある ) の転送が可能になります。

0 6cfg_aer_ecrc_check_en

1

コンフィギュレーション AER - ECRC Check Enable: AER_Cap_and_Ctl[8]

アサートされた場合、このビットは、ホストによって ECRC チェック機能が有効化されたことを示します。

0 7cfg_aer_ecrc_gen_en

1

コンフィギュレーション AER - ECRC Generation Enable: AER_Cap_and_Ctl[6]

アサートされた場合、このビットは、ホストによって ECRC 生成機能が有効化されたことを示します。

0 15:8 0 8 予約

1 0cfg_dev_status_corr_err_detected

1

コンフィギュレーションデバイスステータス - Correctable Error Detected: Device_Status[0]

検出された訂正可能なエラーのステータスを示します。このレジスタには、デバイス制御レジスタにあるエラーレポート機能の有効/無効とは関係なく、エラーが記録されます。

1 1cfg_dev_status_non_fatal_err_detected

1

コンフィギュレーションデバイスステータス - Non-Fatal Error Detected: Device_Status[1]

検出された非致命的エラーのステータスを示します。このレジスタには、デバイス制御レジスタにあるエラーレポート機能の有効/無効とは関係なく、エラーが記録されます。

表 2‐17: ファンクションステータスインターフェイスのポートの説明 (続き)


[ビット ]








1 2cfg_dev_status_fatal_err_detected

1

コンフィギュレーションデバイスステータス - Fatal Error Detected: Device_Status[2]

検出された致命的エラーのステータスを示します。このレジスタには、デバイス制御レジスタにあるエラーレポート機能の有効/無効とは関係なく、エラーが記録されます。

1 3cfg_dev_status_ur_detected

1

コンフィギュレーションデバイスステータス - Unsupported Request Detected: Device_Status[3]

コアが UR (サポートされないリクエスト ) を受信したことを示します。このレジスタには、デバイス制御レジスタにあるエラーレポート機能の有効/無効とは関係なく、エラーが記録されます。

1 4cfg_dev_control_corr_err_reporting_en

1

コンフィギュレーションデバイス制御 - Correctable Error Reporting Enable: Device_Ctrl[0]

このビットは、ほかのビットと組み合わせて使用することによって、 ERR_COR メッセージの送信を制御します。ルートポートの場合、訂正可能なエラーのレポートは、ルート内部で行われ、外部に ERR_COR メッセージは生成されません。

1 5cfg_dev_control_non_fatal_reporting_en

1

コンフィギュレーションデバイス制御 - Non-Fatal Error Reporting Enable: Device_Ctrl[1]

このビットは、ほかのビットと組み合わせて使用して、ERR_NONFATAL メッセージの送信を制御します。ルートポートの場合、訂正可能なエラーのレポートは、ルート内部で行われ、外部に ERR_NONFATAL メッセージは生成されません。

1 6cfg_dev_control_fatal_err_reporting_en

1

コンフィギュレーションデバイス制御 - Fatal Error Reporting Enable: Device_Ctrl[2]

このビットは、ほかのビットと組み合わせて使用して、ERR_FATAL メッセージの送信を制御します。ルートポートの場合、訂正可能なエラーのレポートは、ルート内部で行われ、外部に ERR_FATAL メッセージは生成されません。

1 7cfg_dev_control_ur_err_reporting_en

1

コンフィギュレーションデバイス制御 - UR Reporting Enable: Device_Ctrl[3]

このビットは、ほかのビットと組み合わせて使用して、エラーメッセージを送信することによって、 UR (サポートされないリクエスト ) のシグナルを制御します。



[ビット ]








1 10:8cfg_dev_control_max_payload

3

コンフィギュレーションデバイス制御 - Max_Payload_Size: Device_Ctrl[7:5]

このフィールドでは、大の TLP ペイロードサイズを設定します。レシーバーとして、ロジックは設定値と同じ規模の TLP に対応する必要があります。ロジックは、トランスミッターとして、設定値を超える TLP を生成できません。

• 000b = 128 バイトの大ペイロードサイズ






1 11cfg_dev_control_enable_ro

1

コンフィギュレーションデバイス制御 - Enable Relaxed Ordering: Device_Ctrl[4]

アサートされた場合、ロジックは厳しい書き込み順序が必要ないトランザクションの属性フィールドにこの Relaxed Ordering (緩和型順序付け) ビットをセットできます。

1 12cfg_dev_control_ext_tag_en

1

コンフィギュレーションデバイス制御 - Tag Field Enable: Device_Ctrl[8]

アサートされた場合、ロジックはリクエスターとして 8 ビットのタグフィールドを使用できます。ディアサートされると、ロジックは 5 ビットのタグフィールドに制限されます。コアは、送信するリクエスト TLP と受信するコンプリーションのいずれにおいても、使用するタグビット数を強制しません。

1 13cfg_dev_control_no_snoop_en

1

コンフィギュレーションデバイス制御 - Enable No Snoop: Device_Ctrl[11]

アサートされると、ロジックは、ハードウェアキャッシュコヒーレンシを必要としない場合に、自身が開始する TLP の No Snoop ビットをセットできます。

1 15:14 0 2 予約

2 2:0cfg_dev_control_max_read_req

3

コンフィギュレーションデバイス制御 - Max_Read_Request_Size: Device_Ctrl[14:12]

このフィールドでは、リクエスターとして機能するロジックの大読み出しリクエストサイズを設定します。ロジックは、設定値を超えるサイズの読み出しリクエストを生成できません。

• 000b = 128 バイトの大読み出しリクエストサイズ








[ビット ]








2 3cfg_link_status_link_training

1

コンフィギュレーションリンクステータス - Link Training: Link_Status[11]

物理層 LTSSM がコンフィギュレーションまたはリカバリステートであることを示しているか、あるいは Retrain Link ビットに 1b が書き込まれているが、まだリンクトレーニングが開始されていない状態であることを示します。 LTSSM がコンフィギュレーション/ リカバリステートから別のステートへ遷移すると、コアはこのビットをクリアします。

2 6:4cfg_link_status_current_speed

3

コンフィギュレーションリンクステータス - Current Link Speed: Link_Status[1:0]

このフィールドでは、指定した PCI Express リンクのネゴシエートされたスピードを示します。

• 001b = 2.5GT/s PCI Express リンク



2 10:7cfg_link_status_negotiated_width

4

コンフィギュレーションリンクステータス - Negotiated Link Width: Link_Status[7:4]

このフィールドは、指定した PCI Express リンクのネゴシエートされた幅を示します ( 大 x8 までのリンク幅のみ表示)。

• 0001b = x1

• 0010b = x2

• 0100b = x4

• 1000b = x8

2 11cfg_link_status_bandwidth_status

1

コンフィギュレーションリンクステータス - Link Bandwidth Management Status: Link_Status[14]

ポートが DL_Down ステータスに遷移せずに、次のいずれかが生じた事を示します。

• 1b を Retrain Link ビットへ書き込んだ後にリンクリトレーニングが完了しました。

注記: このビットは、 Retrain Link ビットへ 1b を書き込んだ後にセットされます。また、何らかの理由でリンクがリトレーニングを実行中の場合も含みます。

• 信頼性の高くないリンク動作を修正するために、ハードウェアが LTSSM タイムアウトまたは高いレベルのプロセスを用いて、リンクスピードまたはリンク幅を変更しました。自発的な変更ではなく、下位コンポーネントによってスピードまたは幅が変更されたことを物理層がレポートするかどうかをこのビットで設定します。



[ビット ]








2 12cfg_link_status_auto_bandwidth_status

1

コンフィギュレーションリンクステータス - Link Autonomous Bandwidth Status: Link_Status[15]

信頼性の高くないリンク動作を修正する以外の理由で、ポートが DL_Down ステータスに遷移せずに、コアがリンクスピードまたはリンク幅を独自に変更したことを示します。自発的な変更で、下位コンポーネントによってスピードまたは幅が変更されたことを物理層がレポートするかどうかをこのビットで設定します。

2 15:13 0 3 予約

3 1:0cfg_link_control_aspm_control

2

コンフィギュレーションリンク制御 - ASPM Control: Link_Ctrl[1:0]

サポートされる ASPM のレベルを示します。詳細は次のとおりです。

• 00b = 無効

• 01b = L0s への遷移が有効

• 10b = L1 への遷移が有効

• 11b = L0s および L1 への遷移が有効

3 2cfg_link_control_rcb

1

コンフィギュレーションリンク制御 - RCB: Link_Ctrl[3]

読み出しコンプリーション境界の値を示します。

• 0=64B

• 1=128B

3 3cfg_link_control_link_disable

1

コンフィギュレーションリンク制御 - Link Disable: Link_Ctrl[4]

アサートされた場合、リンクが無効であることを示し、LTSSM を無効ステートに遷移させます。

3 4cfg_link_control_core_clock

1

コンフィギュレーションリンク制御 - Common Clock Configuration: Link_Ctrl[6]

アサートされた場合、このコンポーネントとこのリンクの反対側にあるコンポーネントが、分配された共通の基準クロックを使用して動作していることを示します。ディアサートされた場合、これらは非同期の基準クロックで動作していることを示します。

3 5cfg_link_control_extendedness

1

コンフィギュレーションリンク制御 - Extended Sync: Link_Ctrl[7]

アサートされると、 L0s ステートから遷移するとき、およびリカバリステートにいるときにさらなる順序セットの転送を強制的に実行します。

3 6cfg_link_control_clock_pm_en

1

コンフィギュレーションリンク制御 - Enable Clock Power Management: Link_Ctrl[8]

CLKREQ# 機能をサポートするアップストリームポートでは、次のように示します。

• 0b = クロックのパワーマネージメントは無効

• 1b = デバイスは CLKREQ# を使用できる

この設定に基づいたコア側のアクションはありませんが、外部ロジックがこの機能を実行する必要があります。



[ビット ]








3 7cfg_link_control_hw_auto_width_dis

1

コンフィギュレーションリンク制御 - Hardware Autonomous Width Disable: Link_Ctrl[9]

アサートされた場合、コアはリンク幅を減少させて信頼性の高くないリンク動作を修正する目的以外の理由で、リンク幅を変更できません。

3 8cfg_link_control_bandwidth_int_en

1

コンフィギュレーションリンク制御 - Link Bandwidth Management Interrupt Enable: Link_Ctrl[10]

アサートされると、 Link Bandwidth Management Status ビットがセットされたことを示す割り込み信号の生成が可能になります。この設定に基づいたコア側のアクションはありませんが、ロジックが割り込みを生成する必要があります。

3 9cfg_link_control_auto_bandwidth_int_en

1

コンフィギュレーションリンク制御 - Link Autonomous Bandwidth Interrupt Enable: Link_Ctrl[11]

アサートされると、 Link Autonomous Bandwidth Status ビットがセットされたことを示すために割り込み信号の生成を有効にします。この設定に基づいたコア側のアクションはありませんが、ロジックが割り込みを生成する必要があります。

3 10cfg_tph_requester_enable

1

TPH Requester Enable: ファンクションの TPH リクエスター機能構造にある THP リクエスター制御レジスタのビット [8] です。

これらのビットは、エンドポイントモードの場合のみ有効であり、ソフトウェアによって、デバイスが関連するファンクションから TPH ヒントを含むリクエストを生成できる状態になったことを示します。

3 13:11cfg_tph_steering_tag_mode

3

TPH ステアリングタグモードです。

TPH リクエスター制御レジスタの ST Mode Select ビットの設定を示します。これらのビットは、エンドポイントモードの場合のみ有効であり、対応するファンクションに従って TPH ヒントの生成に有効なモードを示します。

3 15:14 0 2 予約



[ビット ]








4 3:0cfg_dev_control2_cpl_timeout_val

4

コンフィギュレーションデバイス制御 2 - Completion Timeout Value: Device_Ctrl2[3:0]

コンプリーションタイムアウトとしてリクエストがコンプリーションを保留する時間の範囲を示します。コアは、この設定に基づいて動作するわけではありません。

• 0000b = 50μs ～ 50ms (デフォルト )

• 0001b = 50μs ～ 100μs

• 0010b = 1ms ～ 10ms

• 0101b = 16ms ～ 55ms

• 0110b = 65ms ～ 210ms

• 1001b = 260ms ～ 900ms

• 1010b = 1s ～ 3.5s

• 1101b = 4s ～ 13s

• 1110b = 17s ～ 64s

4 4cfg_dev_control2_cpl_timeout_dis

1

コンフィギュレーションデバイス制御 2 - Completion Timeout Disable: Device_Ctrl2[4]

コンプリーションタイムアウトのカウンターを無効にします。

4 5cfg_dev_control2_atomic_requester_en

1

コンフィギュレーションデバイス制御 2 - Atomic Requester Enable: Device_Ctrl2[6]

エンドポイントおよびルートポートにのみ適用可能であり、その他のファンクションタイプの場合は 0b にハード接続する必要があります。コマンドレジスタのこのビットと Bus Master Enable ビットが両方ともセットされた場合のみ、ファンクションは AtomicOp Request (アトミック操作リクエスト ) を開始できます。エンドポイントまたはルートポートが AtomicOp Request をサポートしている場合、このビットは RW になる必要があります。サポートしていない場合は 0b にハード接続してもかまいません。このビットは、機能ビットとして使用しません。エンドポイントまたはルートポートで AtomicOp Request 機能がサポートされていない場合であっても、このビットを RW にできます。

このビットのデフォルト値は 0b です。 32nm

4 6cfg_dev_control2_ido_req_en

1

コンフィギュレーションデバイス制御 2 - IDO Request Enable: Device_Ctrl2[8]

このビットがセットされると、ファンクションは、開始するリクエストの ID-Based Ordering (IDO) ビット (Attribute[2]) を設定できます (セクション 2.2.6.3 およびセクション 2.4 を参照)。エンドポイント (RC インテグレイテッドエンドポイントを含む) およびルートポートは、この機能をインプリメントできます。リクエストに IDO 属性を設定したことがないファンクションは、このビットを 0b にハード接続できます。このビットのデフォルト値は 0b です。 32nm



[ビット ]








4 7cfg_dev_control2_ido_cpl_en

1

コンフィギュレーションデバイス制御 2 - IDO Completion Enable: Device_Ctrl2[9]

このビットがセットされると、ファンクションは、返すコンプリーションの ID-Based Ordering (IDO) ビット (Attribute[2]) を設定できます (セクション 2.2.6.3 およびセクション 2.4 を参照)。エンドポイント (RC インテグレイテッドエンドポイントを含む) およびルートポートは、この機能をインプリメントできます。リクエストに IDO 属性を設定したことがないファンクションは、このビットを 0b にハード接続できます。このビットのデフォルト値は 0b です。 32nm

4 8cfg_dev_control2_ltr_en

1

コンフィギュレーションデバイス制御 2 - LTR Mechanism Enable: Device_Ctrl2[10]

このビットがセットされると、ファンクションは、返すコンプリーションの ID-Based Ordering (IDO) ビット (Attribute[2]) を設定できます (セクション 2.2.6.3 およびセクション 2.4 を参照)。エンドポイント (RC インテグレイテッドエンドポイントを含む) およびルートポートは、この機能をインプリメントできます。リクエストに IDO 属性を設定したことがないファンクションは、このビットを 0b にハード接続できます。このビットのデフォルト値は 0b です。 32nm

4 13:9 cfg_dpa_substate 5Dynamic Power Allocation Substate: DPA 制御レジスタの Dynamic Power Allocation Substate フィールドの設定を示します。

4 15:14 0 1 予約

5 0cfg_root_control_syserr_corr_err_en

1

コンフィギュレーションルート制御 - System Error on Correctable Error Enable: Root_Control[0]

このビットは、レポートされた訂正可能なエラーに対して、ロジックがシステムエラーを生成できるようにします。

5 1cfg_root_control_syserr_non_fatal_err_en

1

コンフィギュレーションルート制御 - System Error on Non-Fatal Error Enable: Root_Control[1]

このビットは、レポートされた非致命的エラーに対して、ロジックがシステムエラーを生成できるようにします。

5 2cfg_root_control_syserr_fatal_err_en

1

コンフィギュレーションルート制御 - System Error on Fatal Error Enable: Root_Control[2]

このビットは、レポートされた致命的エラーに対して、ロジックがシステムエラーを生成できるようにします。

5 3cfg_root_control_pme_int_en

1

コンフィギュレーションルート制御 - PME Interrupt Enable: Root_Control[3]

このビットは、受信した PME メッセージに対して、ロジックが割り込みを生成できるようにします。



[ビット ]








コンフィギュレーション制御インターフェイス

コンフィギュレーション制御インターフェイスは、ユーザーアプリケーションとコア間でさまざまなデータ通信を可能にします。ユーザーアプリケーションはこのインターフェイスを使用して次を行います。

• コンフィギュレーション空間の設定

• 訂正可能/訂正不可能なエラーの有無

• デバイスのシリアル番号の設定

• ダウンストリームバス、デバイス、およびファンクション番号の設定

• ファンクションごとのコンフィギュレーション情報の受信

また、このインターフェイスは、電力ステートが変更されたり、ファンクションレベルのリセットが生じた場合に、ユーザーアプリケーションとコア間のハンドシェイクを実行します。

5 4cfg_aer_rooterr_corr_err_reporting_en

1

コンフィギュレーション AER - Correctable Error Reporting Enable: AER_Root_Error_Command[0]

このビットは、レポートされた訂正可能なエラーに対して、ロジックが割り込みを生成できるようにします。

5 5cfg_aer_rooterr_non_fatal_err_reporting_en

1

コンフィギュレーション AER - Non-Fatal Error Reporting Enable: AER_Root_Error_Command[1]

このビットは、レポートされた非致命的エラーに対して、ロジックが割り込みを生成できるようにします。

5 6cfg_aer_rooterr_fatal_err_reporting_en

1

コンフィギュレーション AER - Fatal Error Reporting Enable: AER_Root_Error_Command[2]

このビットは、レポートされた致命的エラーに対して、ロジックが割り込みを生成できるようにします。

5 7cfg_aer_rooterr_corr_err_received

1コンフィギュレーション AER - Correctable Error Messages Received: AER_Root_Error_Status[0]

ERR_COR メッセージが受信されたことを示します。

5 8cfg_aer_rooterr_non_fatal_err_received

1コンフィギュレーション AER - Non-Fatal Error Messages Received: AER_Root_Error_Status[5]

ERR_NFE メッセージが受信されたことを示します。

5 9cfg_aer_rooterr_fatal_err_received

1コンフィギュレーション AER - Fatal Error Messages Received: AER_Root_Error_Status[6]

ERR_FATAL メッセージが受信されたことを示します。

5 15:10 0 6 予約



[ビット ]








表 2-18 では、コアのコンフィギュレーション制御インターフェイスのポートについて説明します。

表 2‐18: コンフィギュレーション制御インターフェイスのポートの説明


cfg_hot_reset_in 入力 1コンフィギュレーションのホットリセット入力

RP モードの場合、 High にアサートされると、 LTSSM がホットリセットステートへ遷移します。

cfg_hot_reset_out 出力 1コンフィギュレーションのホットリセット出力

EP モードの場合、 High にアサートされると、 EP がホットリセットステートへ遷移したことを示します。

cfg_config_space_enable 入力 1

コンフィギュレーション空間イネーブル

エンドポイントモードでこの入力が 0 の場合、コンフィギュレーションリクエストに対してコアは CRS コンプリーションを生成します。属性の変更のため、 DRP を介してコアコンフィギュレーションレジスタの値がロードされる場合、このポートはアサートされた状態を保持する必要があります。これによって、すべてのレジスタの値がロードされるまで、コアはコンフィギュレーションリクエストに対して応答しなくなります。コンフィギュレーション空間のエニュメレーション前にコンフィギュレーションレジスタのパワーオンデフォルト値を変更する必要がない場合、この入力を High に接続します。ルートポートモードの場合、この入力は適用されません。

cfg_per_function_update_done 出力 1コンフィギュレーションファンクションごとの更新完了

cfg_per_function_output_request のアサートに応答し、リクエスト完了後に 1 サイクル間アサートされます。

cfg_per_function_number 入力 4

コンフィギュレーションファンクションごとのターゲットファンクション番号

ユーザーがファンクション番号 (0 ～ 7。 0 ～ 1 は PF0 ～ 1 に対応し、 2 ～ 7 は VF0 ～ 5 に対応) を入力し、cfg_per_function_output_request をアサートすると、そのファンクションの出力値が得られます。これ以外の値はすべて予約されています。

cfg_per_function_output_request 入力 1

コンフィギュレーションファンクションごとの出力リクエスト

cfg_per_function_number にファンクション番号の値を入力してこのポートをアサートすると、コアは各ファンクションのコンフィギュレーション出力ピンに情報の提供を開始し、完了すると cfg_update_done をアサートします。

cfg_dsn 入力 64

コンフィギュレーションデバイスシリアル番号

PF0 のデバイスシリアル番号機能レジスタに反映される値を示します。ビット [31:0] は、初の (下位) Dword (機能レジスタのバイトオフセット 0x4h)、ビット [63:32] は 2 つ目の (上位) Dword (機能レジスタのバイトオフセット 0x8h) に転送されます。この値が静的に割り当てられない場合、ユーザーアプリケーションは安定した後に user_cfg_input_update をパルスする必要があります。






cfg_ds_bus_number 入力 8

コンフィギュレーションダウンストリームバス番号

• ダウンストリームポート : ダウンストリームポートのリクエスター ID (RID) のバス番号部分を提供します。これは、コア内で生成される UR コンプリーションやパワーマネージメントメッセージなどの TLP で使用されます。 AXI インターフェイスに現れる TLP には影響を与えません。

• アップストリームポート : 役割なし

cfg_ds_port_number 入力 8コンフィギュレーションダウンストリームポート番号

リンク機能レジスタのポート番号フィールドを提供します。

cfg_ds_device_number 入力 5

コンフィギュレーションダウンストリームデバイス番号

• ダウンストリームポート : ダウンストリームポートの RID のデバイス番号部分を提供します。これは、コア内で生成される UR コンプリーションやパワーマネージメントメッセージなどの TLP で使用されます。 TRN インターフェイスに現れる TLP には影響を与えません。


cfg_ds_function_number 入力 3

コンフィギュレーションダウンストリームファンクション番号

• ダウンストリームポート : ダウンストリームポートの RID のファンクション番号部分を提供します。これは、コア内で生成される UR コンプリーションやパワーマネージメントメッセージなどの TLP で使用されます。 TRN インターフェイスに現れる TLP には影響を与えません。


cfg_power_state_change_ack 入力 1

コンフィギュレーション電力ステート応答

コンフィギュレーション書き込みリクエストを受けて低電力ステートへの遷移の準備が整っている場合、cfg_power_state_change_interrupt のアサートに応答して、コアに対してこの入力を 1 サイクル間アサートする必要があります。コンフィギュレーション書き込みトランザクションのコンプリーション応答を遅延させる必要がない場合、ユーザーアプリケーションはこの入力を永久的に High に保持して、電力ステートを変更できます。

表 2‐18: コンフィギュレーション制御インターフェイスのポートの説明 (続き)







cfg_power_state_change_interrupt 出力 1

電力ステート変更の割り込み

パワーマネージメント制御レジスタへの書き込みによって、Physical Function または Virtual Function の電力ステートが D1 または D3 ステートへ変更される場合、コアはこの出力をアサートします。ユーザーアプリケーションが cfg_power_state_change_ack 入力をアサートするまで、コアはこの出力を High に保持します。cfg_power_state_change_interrupt が High に保持されている間、コアは受信した保留されているすべてのコンフィギュレーション読み出し /書き込みトランザクションに対してコンプリーションを返しません。この目的は、ユーザーアプリケーションが低電力ステートへ遷移する準備が整うまで、ステート変更をもたらしたコンフィギュレーション書き込みトランザクションのコンプリーションを遅延させることです。cfg_power_state_change_interrupt がアサートされると、コンフィギュレーション書き込みトランザクションに関連するファンクション番号が cfg_ext_function_number[7:0] 出力に提供されます。ユーザーアプリケーションが cfg_power_state_change_ack をアサートすると、ステート変更を受けたファンクションの新しいステートがコアの cfg_function_power_state (PF の場合)、または cfg_vf_power_state (VF の場合) 出力に反映されます。

cfg_subsys_id 入力 16コンフィギュレーションサブシステム ID

PF0 のタイプ 0 PCI 機能構造体サブシステム ID フィールドに反映される値を示します。

cfg_err_cor_in 入力 1

訂正可能なエラーを検出した

ユーザーロジック内で訂正可能なエラーが検出され、内部エラーとして PCI Express Advanced Error Reporting メカニズムを使用してレポートする必要がある場合、ユーザーアプリケーションはこの入力を 1 サイクル間アサートします。これに対応して、コアはすべての有効なファンクションの AER 訂正可能エラーステータスレジスタの Corrected Internal Error Status ビットをセットし、また可能な場合にはエラーメッセージを送信します。このエラーは、ファンクションに固有のものではありません。

cfg_err_uncor_in 入力 1

訂正不可能なエラーを検出した

ユーザーロジック内で訂正不可能なエラーが検出され、内部エラーとして PCI Express Advanced Error Reporting メカニズムを使用してレポートする必要がある場合、ユーザーアプリケーションはこの入力を 1 サイクル間アサートします。これに対応して、コアはすべての有効なファンクションの AER 訂正不可能エラーステータスレジスタの Uncorrected Internal Error Status ビットをセットし、また可能な場合にはエラーメッセージを送信します。このエラーは、ファンクションに固有のものではありません。

cfg_flr_done 入力 4

ファンクションレベルのリセット完了

ユーザーアプリケーションは、Virtual Function のリセット動作が完了したら、この入力をアサートする必要があります。これによって、コアは Physical Function i の cfg_flr_in_process をディアサートして、その Physical Function へのコンフィギュレーションアクセスを再度有効にします。ビット [3:2] は予約されています。








cfg_vf_flr_done 入力 8

Virtual Function のファンクションレベルのリセット完了

ユーザーアプリケーションは、Virtual Function のリセット動作が完了したら、この入力をアサートする必要があります。これによって、コアは Virtual Function i の cfg_vf_flr_in_process をディアサートして、その Virtual Function へのコンフィギュレーションアクセスを再度有効にします。ビット [7:6] は予約されています。

cfg_flr_in_process 出力 4

ファンクションレベルのリセットが実行中

ホストがコンフィギュレーション空間の FLR ビットを介して、Physical Function i のリセットを開始した場合、コアはこのバスのビット i をアサートします。コアは、ユーザーが対応する Physical Function の cfg_flr_done 入力をセットしてリセット動作の完了を示すまで、この出力を High のまま保持します。ビット [3:2] は予約されています。

cfg_vf_flr_in_process 出力 8

Virtual Function のファンクションレベルのリセットが実行中

ホストがコンフィギュレーション空間の FLR ビットを介して、Virtual Function i のリセットを開始した場合、コアはこのバスのビット i をアサートします。コアは、ユーザーが対応するファンクションの対応する cfg_vf_flr_done 入力をセットしてリセット動作の完了を示すまで、この出力を High のままホールドします。

cfg_req_pm_transition_l23_ready 入力 1

コアがエンドポイントとしてコンフィギュレーションされている場合、ユーザーアプリケーションはこの入力をアサートして、コアのパワーマネージメントステートを L23_READY に遷移します (パワーマネージメントの詳細は、『PCI Express 仕様』の第 5 章を参照)。これは、コア内の PCI ファンクションが D3 ステートに遷移し、ユーザーアプリケーションがルートコンプレックスからの PME_Turn_Off メッセージに対して ACK を送信した後に実行されます。この入力をアサートすると、リンクが L3 ステートへ遷移します。動作を再開するには、ハードリセットが必要です。リンクを L3 ステートへ遷移させる必要がない場合は、この入力を 0 にハード接続できます。ルートコンプレックスモードの場合、この入力は使用しません。

cfg_link_training_enable 入力 1

リンクを確立するために Link Training Status State Machine (LTSSM) を有効にする場合は、この入力を 1 にセットする必要があります。 0 にセットすると、 LTSSM は強制的に Detect.Quiet ステートへ遷移します。








コンフィギュレーション割り込みコントローラーインターフェイス

コンフィギュレーション割り込みコントローラーインターフェイスでは、ユーザーアプリケーションがレガシ PCIe 割り込み、 MSI 割り込み、または MSI-X 割り込みをセットできます。コアは、送信されるコンフィギュレーション割り込みに割り込みステータスおよびエラー信号を提供します。表 2-19 コアのコンフィギュレーション割り込みコントローラーインターフェイスのポートについて説明します。

cfg_local_error 出力 1

ローカルエラー条件

ローカルエラーステータスレジスタのいずれかのローカルエラー条件が発生すると、出力がロジック High になります。ローカル割り込みマスクレジスタの対応するビットをセットすると、これらの条件を個別にマスクできます。次に示す連続するブロック内部イベント (マスクされていない場合) が大 8 つまでレポートされます。

1) tx_replay_buffer_ram_uncorrectable_parity_error

2) rx_request_fifo_ram_uncorrectable_parity_error

3) rx_completion_fifo_ram_uncorrectable_parity_error

4) rx_receive_fifo_overflow

5) rx_completion_receive_fifo_overflow

6) link_replay_timeout

7) link_replay_num_rollover

8) phy_error_detected

9) malformed_tlp_received_reg

10) unexpected_completion_received

11) flow_control_protocol_error_detected

12) completion_timeout

注記: この信号は、 PCIe リンク幅/スピードの設定によっては動作しな

いことがあります。この信号だけに頼ってエラーの発生を知ることは

避けてください。



表 2‐19: コンフィギュレーション割り込みコントローラーインターフェイスのポートの説明


cfg_interrupt_int 入力 4

コンフィギュレーション INTx ベクター

コアが EP としてコンフィギュレーションされている場合、ユーザーアプリケーションはこれらの 4 つの入力を使用し、PCI Express の Legacy PCI Express Interrupt Delivery メカニズムを使用して、任意の PCI ファンクションから RC へ割り込み信号を送信します。これらの 4 つの入力は、それぞれ INTA、INTB、 INTC、および INTD に対応します。これらの信号のいずれかをアサートすると、コアは Assert_INTx メッセージを送信します。ディアサートするとコアは Deassert_INTx メッセージを送信します。

cfg_interrupt_sent 出力 1

コンフィギュレーション INTx の送信

この出力信号は、 cfg_interrupt_int 入力のいずれかのステートが変更されたことに応答して、コアが Assert_INTx メッセージまたは Deassert_INTx メッセージを送信したことを示します。






cfg_interrupt_pending 入力 4

コンフィギュレーション INTx 割り込みペンディング (アクティブ High)

ファンクションごとの保留中割り込みを示します。cfg_interrupt_pending[0] が PF0 に対応します (その他同様)。ビット [3:2] は予約されています。

cfg_interrupt_msi_enable 出力 4

コンフィギュレーション割り込みの MSI ファンクションのイネーブル

各ファンクションに対して、 Message Signaling Interrupt (MSI) メッセージが有効であることを示します。ビット [3:2] は予約されています。

cfg_interrupt_msi_vf_enable 出力 8VF のコンフィギュレーション割り込み MSI 有効

各 Virtual Function の MSI メッセージが有効であることを示します。ビット [7:6] は予約されています。

cfg_interrupt_msi_int 入力 32

コンフィギュレーション割り込みの MSI ベクター

コアがエンドポイントとしてコンフィギュレーションされ、MSI 割り込みをサポートする場合、これらの入力を使用して、ユーザーロジックからコアへ PCI ファンクション (Physical/Virtual) に関連する 32 の異なる割り込み条件を示します。ファンクション番号を cfg_interrupt_msi_function_number 入力に指定する必要があります。cfg_interrupt_msi_function_number 入力にファンクション番号を指定した後、ユーザーロジックはこれらの信号のいずれか 1 つを 1 サイクル間アクティブにして割り込みを送信する必要があります。ユーザーロジックは、同じサイクル内で複数 (32 の割り込み入力のうち) の信号をアクティブにはできません。コアは、cfg_interrupt_msi_int のあらゆるビットの 0 から 1 への遷移における割り込み条件を内部レジスタに格納します。ユーザーロジックは、割り込みを 1 つアサートした後、次に割り込みをアサートする前にコアから cfg_interrupt_msi_sent または cfg_interrupt_msi_fail 信号が送信されるまで待機する必要があります。

cfg_interrupt_msi_sent 出力 1

コンフィギュレーション割り込みの MSI 割り込みの送信

コアは、この出力に 1 サイクル間パルスを生成し、リンク上に MISI 割り込みメッセージが送信されたことを示します。ユーザーロジックは、コアへ別の割り込み条件を送信する前に、このパルスが生成されるまで待機する必要があります。

cfg_interrupt_msi_fail 出力 1

コンフィギュレーション割り込みの MSI 割り込み動作エラー

この出力に 1 サイクル間のパルスが生成されると、 MSI 割り込みメッセージがリンク上に送信される前に停止されたことを示します。この場合、ユーザーアプリケーションは MSI 割り込みを再度送信する必要があります。

表 2‐19: コンフィギュレーション割り込みコントローラーインターフェイスのポートの説明 (続き)







cfg_interrupt_msi_mmenable 出力 12

コンフィギュレーション割り込みの MSI ファンクションの Multiple Message Enable ビット

コアがエンドポイントモードとしてコンフィギュレーションされ、 MISI 割り込みをサポートする場合、これらの出力は、Physical Function に関連する MSI 制御レジスタの Multiple Message Enable ビットで駆動されます。これらのビットは、対応するファンクションに対して割り当てられた MSI 割り込みベクター番号をエンコードします。ビット [2:0] は Physical Function 0 に対応し、ビット [5:4] は Physical Function 1 に対応します。ビット [12:6] は予約されています。

cfg_interrupt_msi_pending_status 入力 32

コンフィギュレーション割り込みの MSI ペンディングステータス

これらの入力は、Physical Function の MSI ペンディング割り込みステータスを示します。これらのピンの設定が、対応する PF の MSI ペンディングビットレジスタから読み出される値を決定します。 MSI ペンディングビットレジスタには、 MSI 割り込みの Pending (保留) ビットが含まれます。このロケーションを読み出すと、コアの MSI マスク入力のステートが返ってきます。これは、 MSI マスク入力のデフォルト値を含む 32 ビット幅の RO レジスタです。cfg_interrupt_msi_pending_status および cfg_interrupt_msi_pending_status_function_num の各値と共にこの信号をアサートして、対応するファンクションの MSI ペンディングビットをアップデートします。

cfg_interrupt_msi_mask_update 出力 1

コンフィギュレーション割り込みの MSI ファンクションマスクの変更

MSI マスクレジスタ内のいずれかの有効なファンクションが値を変更すると、 1 サイクル間アサートされます。 MSI マスクレジスタには、 MSI 割り込みのマスクビットが含まれます。 MSI 制御レジスタの Multiple Message Capable フィールドが、そのファンクションに対する確実な割り込み数を示し、これによって有効なマスクビットの数が決定します。これは、 32 ビット幅の RW レジスタで、デフォルト値は 0 となります。

cfg_interrupt_msi_select 入力 4

コンフィギュレーション割り込みの MSI セレクト

値 0000b ～ 0001b で PF0 ～ 1 を選択し、値 0010b ～ 0111b で VF0 ～ 5 を選択します。 cfg_interrupt_msi_data[31:0] には、選択したファンクションの MSI マスクレジスタの値が現れます。この入力が 1111b に駆動された場合、cfg_interrupt_msi_data[17:0] にはすべての VF に関連する MSI 制御レジスタの Multiple Message Enable ビットが現れます。これらのビットは、対応するファンクションに割り当てられた MSI 割り込みベクターの数をエンコードします。たとえば、 cfg_interrupt_msi_data[2:0] は VF0 に対応します。

cfg_interrupt_msi_data 出力 32コンフィギュレーション割り込みの MSI データ

この出力に現れる値は、cfg_interrupt_msi_select に依存します。

cfg_interrupt_msi_pending_status_function_num 入力 4

コンフィギュレーション割り込みの MSI ペンデングターゲットファンクション番号

0 ～ 11 のファンクション番号を入力します。値は、 0 ～ 3 が PF0 ～ 3 に対応し、 4 ～ 11 が VF0 ～ 7 に対応します。








cfg_interrupt_msi_pending_status_data_enable 入力 1

コンフィギュレーション割り込みの MSI ペンディングデータ有効

cfg_interrupt_msi_pending_status および cfg_interrupt_msi_pending_status_function_num の各値と共にこの信号をアサートして、対応するファンクションの MSI ペンディングビットをアップデートします。

cfg_interrupt_msix_enable 出力 2

コンフィギュレーション割り込みの MSI-X ファンクションのイネーブル

アサートされると、各ファンクションに対して、 Message Signaling Interrupt (MSI-X) メッセージが有効であることを示します。

cfg_interrupt_msix_mask 出力 2

コンフィギュレーション割り込みの MSI-X ファンクションのマスク

ファンクションごとに、 MSI-X Message Control フィールドの Function Mask ビットのステータスを示します。

cfg_interrupt_msix_vf_enable 出力 6

VF のコンフィギュレーション割り込み MSI 有効

アサートされると、各ファンクションに対して、 Message Signaling Interrupt (MSI-X) メッセージが有効であることを示します。

cfg_interrupt_msix_vf_mask 出力 6コンフィギュレーション割り込みの MSI-X VF マスク

ファンクションごとに、 MSI-X Message Control フィールドの Function Mask ビットのステータスを示します。

cfg_interrupt_msix_address 入力 64

コンフィギュレーション割り込みの MSI-X アドレス

コアが MSI-X 割り込みをサポートする場合、ユーザーロジックはこのバスを使用して、 MSI-X メッセージで使用するアドレス情報を伝えます。

cfg_interrupt_msix_data 入力 32

コンフィギュレーション割り込みの MSI-X データ

コアが MSI-X 割り込みをサポートする場合、ユーザーロジックはこのバスを使用して、 MSI-X メッセージで使用するデータを伝えます。

cfg_interrupt_msix_int 入力 1

コンフィギュレーション割り込みの MSI-X データ有効

この信号は、 cfg_interrupt_msix_address[63:0] および cfg_interrupt_msix_data[31:0] バス上に有効な情報が含まれており、送信元となるファンクションの番号が cfg_interrupt_msi_function_number[3:0] に含まれていることを示します。コアは、この Valid 信号の 0 から 1 への遷移において、関連する cfg_interrupt_msix_address および cfg_interrupt_msix_data からのアドレス情報とデータを内部レジスタに格納します。 cfg_interrupt_msix_int をアサートする前に、使用しているファンクションに対応する cfg_interrupt_msix_enable ビットがセットされていることをユーザーアプリケーションで確認する必要があります。ユーザーロジックは、割り込みを 1 つアサートした後、次に割り込みをアサートする前にコアから cfg_interrupt_msix_sent または cfg_interrupt_msix_fail 信号が送信されるまで待機する必要があります。








cfg_interrupt_msix_sent 出力 1

コンフィギュレーション割り込みの MSI-X 割り込み送信

コアは、 cfg_interrupt_msix_address[63:0] および cfg_interrupt_msix_data[31:0] バスに配置された情報を受信し、MSI-X 割り込みメッセージがリンク上に送信されたことを示すため、この出力に 1 サイクル間パルスを生成します。ユーザーアプリケーションは、コアへ別の割り込み条件を送信する前に、このパルスが生成されるまで待機する必要があります。

cfg_interrupt_msix_fail 出力 1

コンフィギュレーション割り込みの MSI-X 割り込み動作エラー

この出力に 1 サイクル間パルスが生成されると、割り込みコントローラーがリンク上に MSI-X 割り込みを送信できなかったことを示します。この場合、ユーザーアプリケーションは MSI-X 割り込みを再度送信する必要があります。

cfg_interrupt_msi_attr 入力 3

コンフィギュレーション割り込みの MSI/MSI-X TLP 属性

これらのビットは、 MSI/MSI-X 割り込みリクエストに使用される Attribute (属性) ビットの設定を示します。ビット 0 は No Snoop ビットで、ビット 1 は Relaxed Ordering ビットです。ビット 2 は、 ID-Based Ordering ビットです。コアは、cfg_interrupt_msi_int または cfg_interrupt_msix_int が 0 から 1 への遷移する際にこれらのビットをサンプルします。

cfg_interrupt_msi_tph_present 入力 1

コンフィギュレーション割り込みの MSI/MSI-X TPH 存在

MSI/MSI-X 割り込みリクエストに Transaction Processing Hint (TPH) が存在することを示します。 MSI または MSI-X トランザクションに TPH が含まれている場合、ユーザーアプリケーションは cfg_interrupt_msi_int または cfg_interrupt_msix_int がアサートされている間に、このビットをセットする必要があります。

cfg_interrupt_msi_tph_type 入力 2

コンフィギュレーション割り込みの MSI/MSI-X TPH タイプ

cfg_interrupt_msi_tph_present が 1'b1 のときに、これらの 2 つのビットがヒントに関連する 2 ビットのタイプを提供します。コアは、 cfg_interrupt_msi_int または cfg_interrupt_msix_int が 0 から 1 への遷移する際にこれらのビットをサンプルします。

cfg_interrupt_msi_tph_st_tag 入力 9

コンフィギュレーション割り込みの MSI/MSI-X TPH ステアリングタグ

cfg_interrupt_msi_tph_present が 1'b1 のとき、ヒントに関連するステアリングタグが cfg_interrupt_msi_tph_st_tag[7:0] に配置されている必要があります。 cfg_interrupt_msi_tph_st_tag[8] を 1b に設定すると、間接タグモードがアクティブになります。間接タグモードの場合、コアは TPH Capability Structure のステアリングタグテーブル (STT) へのインデックス (STT は各ファンクションで大 64 エントリに制限されている ) として cfg_interrupt_msi_tph_st_tag のビット [5:0] を使用し、このロケーションのタグを送信されたリクエスト MSI/X TLP に挿入します。 cfg_interrupt_msi_tph_st_tag[8] を 0b に設定すると、直接タグモードがアクティブになります。直接タグモードの場合、コアは送信された MSI/X TLP にタグとして cfg_interrupt_msi_tph_st_tag[7:0] を直接挿入します。コアは、cfg_interrupt_msi_int ビットまたは cfg_interrupt_msix_int が 0 から 1 への遷移する際にこれらのビットをサンプルします。








コンフィギュレーション拡張インターフェイス

外部にコンフィギュレーションレジスタが実装されている場合、コンフィギュレーション拡張インターフェイスを使用することによって、コアがコンフィギュレーション情報をユーザーアプリケーションへ送信できるようになります。表 2-20 では、コアのコンフィギュレーション拡張インターフェイスのポートについて説明します。

cfg_interrupt_msi_function_number 入力 4

コンフィギュレーションの MSI/MSI-X 開始ファンクション

MSI または MSI-X トランザクションを開始するエンドポイントファンクション番号を示します。

• 0: PF0

• 1: PF1

• 2: 使用しない

• 3: 使用しない

• 4: VF0

• 5: VF1

• 6: VF2

• 7: VF3

• 8: VF4

• 9: VF5



表 2‐20: コンフィギュレーション拡張インターフェイスのポートの説明


cfg_ext_read_received 出力 1

コンフィギュレーション拡張インターフェイスの読み出しリクエストの受信

• リンクからコンフィギュレーション読み出しリクエストを受信すると、コアがこの出力をアサートします。ユーザーが実装したレガシコンフィギュレーション空間および拡張コンフィギュレーション空間のどちらも有効でない場合、コンフィギュレーション読み出しリクエストを受信すると、有効な cfg_ext_register_number と cfg_ext_function_number を伴ってこの信号が 1 サイクル間アサートされます。ユーザーが実装したレガシコンフィギュレーション空間、拡張コンフィギュレーション空間、あるいは両方が有効の場合、cfg_ext_register_number の範囲はそれぞれ 0x10-0x1f または 0x120-0x3ff となり、ユーザーロジックが cfg_ext_read_data および cfg_ext_read_data_valid を送信するまでこの信号はアサートされます。 cfg_ext_register_number が 0x10-0x1f または 0x120-0x3ff の範囲外である場合、コンフィギュレーション読み出しリクエストを受信すると、常にこの信号が 1 サイクル間アサートされます。 --

cfg_ext_write_received 出力 1

コンフィギュレーション拡張インターフェイスの書き込みリクエスト受信

• リンクからコンフィギュレーション書き込みリクエストを受信すると、コアがこの出力に 1 サイクルのパルスを生成します。






cfg_ext_register_number 出力 10

コンフィギュレーション拡張インターフェイスのレジスタ番号

読み出しまたは書き込みが行われるコンフィギュレーションレジスタの 10 ビットアドレスです。 cfg_ext_read_received または cfg_ext_write_received が High のとき、データは有効です。

cfg_ext_function_number 出力 8

コンフィギュレーション拡張インターフェイスのファンクション番号

コンフィギュレーション読み出しまたは書き込みリクエストに対応する 8 ビットのファンクション番号です。cfg_ext_read_received または cfg_ext_write_received が High のとき、データは有効です。

cfg_ext_write_data 出力 32

コンフィギュレーション拡張インターフェイスの書き込みデータ

コンフィギュレーションレジスタに書き込まれるデータです。この出力は、 cfg_ext_write_received が High の場合に有効です。

cfg_ext_write_byte_enable 出力 4

コンフィギュレーション拡張インターフェイスの書き込みバイトイネーブル

コンフィギュレーション書き込みトランザクション用のバイトイネーブル信号です。

cfg_ext_read_data 入力 32

コンフィギュレーション拡張インターフェイスの読み出しデータ

このバスを使用して、外部に実装したコンフィギュレーションレジスタからコアへデータを供給できます。cfg_ext_read_data_valid がセットされている場合は、cfg_ext_read_received を High に設定した後に、コアはクロックの次の立ち上がりエッジでこのデータをサンプルします。

cfg_ext_read_data_valid 入力 1

コンフィギュレーション拡張インターフェイスの読み出しデータ有効

ユーザーアプリケーションは、コアに対してこの入力をアサートして、外部に実装したコンフィギュレーションレジスタからデータを供給します。コアは、 cfg_ext_read_received を High に設定した後、クロックの次の立ち上がりエッジで、この入力データをサンプルします。

注記: cfg_ext_read_received 信号がアサートされない場合、コアは user_clk の 40000h (218) クロックサイクル後に読み出しリクエストをタ

イムアウトにします。

表 2‐20: コンフィギュレーション拡張インターフェイスのポートの説明 (続き)







クロックおよびリセットインターフェイス

コアの動作に不可欠なクロックおよびリセットインターフェイスは、コア用のシステムレベルのクロック / リセット信号、およびユーザーアプリケーション用のクロック / リセット信号を提供します。表 2-21 では、コアのクロックおよびリセットインターフェイスのポートについて説明します。

表 2‐21: クロックおよびリセットインターフェイスのポートの説明


user_clk 出力 1ユーザークロック出力 (62.5、 125、または 250MHz)

このクロックは、固定された周波数であり、 Vivado® IDE (統合設計環境) で設定されます。

user_reset 出力 1 この信号は user_clk に同期してディアサートされます。 sys_reset のアサートに非同期でディアサート /アサートされます。

sys_clk 入力 1基準クロック。

このクロックの周波数は、100MHz、125MHz、または 250MHz から選択できます。

sys_clk_gt 入力 1GT の PCIe 基準クロック。このクロックは IBUFDS_GTE3 (sys_clk と同じ定義および周波数) から直接駆動される必要があります。このクロックは、 sys_clk と同様に 100MHz、 125MHz、または 250MHz から選択できます。

sys_reset 入力 1

コア用の基本リセット入力 (非同期)

この入力は、 PCIe エッジコネクタのリセット極性と一致するように、デフォルトではアクティブ Low です。 Vivado IDE のオプションを使用して、アクティブ High に設定できますが、この場合、 PCIe エッジコネクタとの互換性が失われます。

FPGA の PERSTN0 パッケージピンと PCIe 統合ブロックの間は、デフォルトで専用配線が有効になります (可能な場合のみ)。 PCIe サイトとそれぞれに対応する専用 sys_reset IOB ロケーションは、表 3-2 を参照してください。これ以外の PCIe 統合ブロックロケーションには専用の sys_reset 接続はありません。利用可能な場合は、専用配線および関連する IOB を使用してください。別の sys_reset ピンロケーションを使用するには、 Vivado IDE で [Use the dedicated PERST routing resources] をオフにする必要があります。また、表 3-2 に記載されていない PCIe サイトの場合、エンドポイントコンフィギュレーションの sys_reset ロケーションには PERSTN1 パッケージピンを使用してください。

pcie_perstn0_out 出力 1

表 3-2 に記載された PCIe サイトの sys_reset 入力ポートを介す、 PERSTN0 パッケージピンからの直接パススルー出力です。このポートは、 [Use the dedicated PERST routing resources] をオン (デフォルト ) にして専用配線を有効にし、sys_reset を PERSTN0 パッケージピンで駆動する場合のみ利用できます。その他のコンフィギュレーションおよび PCIe ロケーションの場合、このポートは接続する必要がありません。

pcie_perstn1_in 入力 1

PERSTN1 パッケージピンから pcie_perstn1_out 出力への専用配線の入力です。この入力は PERSTN1 パッケージピンによってのみ駆動でき、 [Use the dedicated PERST routing resources] をオン (デフォルト ) にして専用配線を有効にした場合のみ使用できます。専用のリセット配線をサポートしていない PCIe ロケーションの場合、このポートは定数ゼロ (1'b0) に接続してください。

pcie_perstn1_out 出力 1

専用配線をサポートした PCIe 統合ブロックの pcie_perstn1_in 入力ポートを介す、 PERSTN1 パッケージピンからの直接パススルー出力です。このポートは、[Use the dedicated PERST routing resources] をオンにして専用リセット配線を有効にし、 pcie_perstn1_in を PERSTN1 パッケージピンで駆動している場合のみ使用できます。その他の設定の場合、このポートは接続しないでください。専用のリセット配線をサポートしていない PCIe エンドポイントコンフィギュレーションでは、オプションで PERSTN1 パッケージピンを使用して sys_reset 入力ポートを駆動することもできます。






専用の PCIe リセット配線には、 PERSTN0/PERSTN1 および表 2-21 に示したリセット入力ポートを使用します。これらは PERSTN から PCIe 統合ブロックロケーションへの専用ポートです。 Tandem コンフィギュレーションのサポートが必要な場合は、表 2-21 の説明に従ってこれらのピンを使用してください。 PERSTN0 および PERSTN1 ピンを使用する際の一般的なガイドラインを次に示します。

• ルートポートコンフィギュレーションでは、任意のピンを使用してエッジコネクタリセットを駆動できます。

• エンドポイントコンフィギュレーションで専用配線を利用できる場合は、 PCIe エッジコネクタリセット入力ピンとして常に PERSTN0 を使用する必要があります。

• エンドポイントコンフィギュレーションで専用リセット配線を利用できない場合は任意のピンを PCIe エッジコネクタリセット入力ピンとして使用できますが、 PERSTN1 の使用を推奨します。

PCI Express インターフェイス

PCI Express (PCI_EXP) インターフェイスは、複数レーン内で組織化された差動の送信/受信ペアで構成されています。1 つの PCI Express レーンは、 1 組の送信差動信号 (pci_exp_txp、 pci_exp_txn) および 1 組の受信差動信号 (pci_exp_rxp、 pci_exp_rxn) で構成されています。 1 レーンコアはレーン 0 のみをサポートし、 2 レーンコアはレーン 0 ～ 1、 4 レーンコアはレーン 0 ～ 3、そして 8 レーンコアはレーン 0 ～ 7 をサポートします。 PCI_EXP インターフェイスの送信信号および受信信号の説明は、表 2-22 を参照してください。

表 2‐22: PCI Express インターフェイス信号 (1、 2、 4、および 8 レーンコアの場合)

レーン番号

名称方向説明

1 レーンコア

0

pci_exp_txp0 出力 PCI Express は正の値を送信: シリアル差動出力 0 (+)

pci_exp_txn0 出力 PCI Express は負の値を送信: シリアル差動出力 0 (–)

pci_exp_rxp0 入力 PCI Express は正の値を受信: シリアル差動入力 0 (+)

pci_exp_rxn0 入力 PCI Express は負の値を受信: シリアル差動入力 0 (–)

2 レーンコア

0





1





4 レーンコア

0










1





2





3





8 レーンコア

0





1





2





3





4





表 2‐22: PCI Express インターフェイス信号 (1、 2、 4、および 8 レーンコアの場合) (続き)

レーン番号

名称方向説明






5





6





7





16 レーンコア

0





1





2





3





4






レーン番号

名称方向説明






5





6





7





8





9





10





11





12






レーン番号

名称方向説明






属性の説明

ユーザーインターフェイス

表 2-23 に、コアのユーザーインターフェイスの動作を制御するコンフィギュレーション属性を示します。

13





14





15






レーン番号

名称方向説明

表 2‐23:統合ブロックのユーザーインターフェイスのコンフィギュレーション属性

属性名タイプ説明

USER_CLK2_FREQ 整数

• 2: 62.50MHz (デフォルト )

• 3: 125.00MHz

• 4: 250.00MHz

PL_LINK_CAP_MAX_LINK_SPEED[2:0] ビットベクター

PCIe リンクの大スピードを定義します。

• 001: 2.5GT/s

• 010: 5.0GT/s

• 100: 8.0GT/s

その他すべてのエンコードは予約されています。

PL_LINK_CAP_MAX_LINK_WIDTH[3:0] ビットベクター

大リンク幅有効な設定は次のとおりです。

• 0001b: x1

• 0010b: x2

• 0100b: x4

• 1000b: x8

その他すべてのエンコードは予約されています。この設定は、コア内のすべての層に伝搬されます。






C_DATA_WIDTH 整数

AXI4-Stream インターフェイスの幅を指定します。

• 64 ビットインターフェイス



AXISTEN_IF_CQ_ALIGNMENT_MODE 文字列

コンプリーターリクエストインターフェイスにデータアライメントモードを定義します。

• FALSE: Dword アライメントモード

• TRUE: アドレスアライメントモード

AXISTEN_IF_CC_ALIGNMENT_MODE 文字列

コンプリーターコンプリーションインターフェイスにデータアライメントモードを定義します。



AXISTEN_IF_RQ_ALIGNMENT_MODE 文字列

リクエスターリクエストインターフェイスにデータアライメントモードを定義します。



AXISTEN_IF_RC_ALIGNMENT_MODE 文字列

リクエスターコンプリーションインターフェイスにデータアライメントモードを定義します。



AXISTEN_IF_RC_STRADDLE 文字列

この属性は、リクエスターコンプリーションインターフェイスのストラドルオプションを有効にします。

• FALSE: ストラドルオプションは無効

• TRUE: ストラドルオプションは有効

AXISTEN_IF_RQ_PARITY_CHECK 文字列

この属性は、リクエスターリクエストインターフェイスのパリティチェックを有効にします。

• FALSE: パリティチェックは無効

• TRUE: パリティチェックは有効

AXISTEN_IF_CC_PARITY_CHECK 文字列

この属性は、コンプリーターコンプリーションインターフェイスのパリティチェックを有効にします。

• FALSE: パリティチェックは無効

• TRUE: パリティチェックは有効

表 2‐23:統合ブロックのユーザーインターフェイスのコンフィギュレーション属性 (続き)







AXISTEN_IF_ENABLE_RX_MSG_INTFC 文字列

この属性は、コアがリンクから受信したメッセージを送信する方法を管理します。

FALSE に設定されている場合、コアは AXI4-Stream プロトコルを使用してコンプリーターリクエストインターフェイスに受信したメッセージ TLP を送信します。このモードでは、AXISTEN_IF_ENABLE_MSG_ROUTE 属性を使用して受信するメッセージタイプを選択できます。また、受信メッセージインターフェイスは非アクティブになります。

この属性が TRUE に設定されている場合、コアはリンクから受信したメッセージを内部でデコードし、受信メッセージインターフェイス上で cfg_msg_received 信号を High 駆動してユーザーアプリケーションへ知らせます。コアは、コンプリーターリクエストインターフェイス上にいかなるメッセージ TLP も送信しません。このモードでは、AXISTEN_ENABLE_MSG_ROUTE 属性の設定は、受信メッセージインターフェイスの動作に影響を与えません。

AXISTEN_IF_ENABLE_MSG_ROUTE[17:0] ビットベクター

AXISTEN_IF_ENABLE_RX_MSG_INTFC 属性が 0 にセットされている場合、これらの属性を使用して、コンプリーターリクエストインターフェイスで受信するメッセージのタイプを選択できます。 1 にセットされている場合、インターフェイスで対応するメッセージタイプの送信が可能になり、 0 にセットされている場合、コアがメッセージをフィルタリングします。

表 2-24 に、この属性のビットと対応するさまざまなメッセージタイプを示します。

AXISTEN_IF_ENABLE_CLIENT_TAG 文字列

FALSE に設定されている場合、リクエスターリクエストインターフェイスから送信されたノンポステッドトランザクションのタグ管理が統合ブロックによって実行されます。つまり、コアが各ノンポステッドリクエストに対してトランザクション用のタグを割り当てて、それをユーザーインターフェイスへ送信します。

TRUE に設定されている場合、内部タグ管理機能は無効となり、ユーザーロジックが各リクエストで使用されるタグを供給できます。 PF0_DEV_CAP_EXT_TAG_SUPPORTED が FALSE に設定されている場合、ユーザーロジックはリクエストディスクリプターヘッダーの 0–31 の範囲にタグフィールドを表示し、 PF0_DEV_CAP_EXT_TAG_SUPPORTED が TRUE に設定されている場合には、 0–63 の範囲にタグフィールドを表示できます。

表 2‐23:統合ブロックのユーザーインターフェイスのコンフィギュレーション属性 (続き)


表 2‐24: AXISTEN_IF_ENABLE_MSG_ROUTE 属性ビットの説明

ビットインデックスメッセージタイプ

0 ERR_COR

1 ERR_NONFATAL

2 ERR_FATAL

3 Assert_INTA および Deassert_INTA

4 Assert_INTB および Deassert_INTB

5 Assert_INTC および Deassert_INTC

6 Assert_INTD および Deassert_INTD






コンフィギュレーション空間

表 2-25 に示すように、 PCI コンフィギュレーション空間は主に 3 つの要素で構成されています。これには次のものが含まれます。

• レガシ PCI v3.0 タイプ 0/1 コンフィギュレーション空間ヘッダー

° エンドポイントアプリケーションで使用するタイプ 0 コンフィギュレーション空間ヘッダー (表 2-26 参照)

° ルートポートアプリケーションで使用するタイプ 1 コンフィギュレーション空間ヘッダー (表 2-27 参照)

• レガシ拡張機能項目

° PCIe 機能項目

° パワーマネージメント機能項目

° Message Signal Interrupt (MSI) 機能項目

° MSI-X 機能項目 (オプション)

• PCIe 機能

° Advanced Error Reporting (AER) 拡張機能構造体

° Alternate Requester ID (ARI) (オプション)

° Device Serial Number 機能構造体 (DSN) (オプション)

° 電力バジェット機能の強化

° Capability Header (PB) (オプション)

° Resizable BAR (RBAR) (オプション)

° Latency Tolerance Reporting (LTR) (オプション)

° Dynamic Power Allocation (DPA) (オプション)

° Single Root I/O Virtualization (SR-IOV) (オプション)

° Transaction Processing Hints (TPH) (オプション)

° Virtual Channel (VC) 拡張機能構造体 (オプション)

7 PM_PME

8 PME_TO_Ack

9 PME_Turn_Off

10 PM_Active_State_Nak

11 Set_Slot_Power_Limit

12 LTR (Latency Tolerance Reporting)

13 OBFF (Optimized Buffer Flush/Fill)

14 アンロック

15 Vendor_Defined タイプ 0


17 無効なリクエスト、無効なコンプリーション、無効な PRG 応答

表 2‐24: AXISTEN_IF_ENABLE_MSG_ROUTE 属性ビットの説明 (続き)

ビットインデックスメッセージタイプ






• PCIe 拡張機能

° Device Serial Number 拡張機能構造体 (オプション)

° Virtual Channel 拡張機能構造体 (オプション)

° Advanced Error Reporting (AER) 拡張機能構造体 (オプション)

° Medica Configuration Access Port (MCAP) 拡張機能構造体 (オプション)

コアは、レガシ拡張機能項目を大 4 つまで実装できます。

この機能の有効化に関する詳細は、第 4 章の「コアのカスタマイズおよび生成」を参照してください。

コアは、 PCI Express 拡張機能を大 10 まで実装できます。残りの PCI Express 拡張機能空間は、ユーザーが定義できます。ユーザーが利用できるこの空間の開始アドレスは、 480h となります。この空間にレジスタを実装する場合は、この空間の開始アドレスを選択でき、この空間をユーザーアプリケーションに実装する必要があります。

この機能の有効化に関する詳細は、第 4 章の「[Extended Capabilities 1] および [Extended Capabilities 2]」を参照してください。

表 2‐25:共通の PCI コンフィギュレーション空間ヘッダー

31 16 15 0

Device ID Vendor ID 000h

Status Command 004h

Class Code Rev ID 008h

BIST Header Lat Timer Cache Ln 00Ch

Header Type Specific

(表 2-26 および表 2-27 を参照)

010h

014h

018h

01Ch

020h

024h

028h

02Ch

030h

CapPtr 034h

038h

Intr Pin Intr Line 03Ch

予約040h-07Ch






PM Capability NxtCap PM Cap 080h

Data 予約 PMCSR 084h

予約088h-08Ch

カスタマイズ可能(1) MSI Control NxtCap MSI Cap 090h

Message Address (Lower) 094h

Message Address (Upper) 098h

予約 Message Data 09Ch

Mask Bits 0A0h

Pending Bits 0A4h

予約0A8h-0ACh

オプション(3) MSl-X Control NxtCap MSl-X Cap 0B0h

Table Offset Table BIR 0B4h

PBA Offset PBA BIR 0B8h

予約 0BCh

PE Capability NxtCap PE Cap 0C0h

PCI Express Device Capabilities 0C4h

Device Status Device Control 0C8h

PCI Express Link Capabilities 0CCh

Link Status Link Control 0D0h

ルートポートのみ(2) Slot Capabilities 0D4h

Slot Status Slot Control 0D8h

Root Capabilities Root Control 0DCh

Root Status 0E0h

PCI Express Device Capabilities 2 0E4h

Device Status 2 Device Control 2 0E8h

PCI Express Link Capabilities 2 0ECh

Link Status 2 Link Control 2 0F0h

未実装のコンフィギュレーション空間 (0x00000000 を返す)

0F4h-0FCh

表 2‐25:共通の PCI コンフィギュレーション空間ヘッダー (続き)

31 16 15 0






常に有効 Next Cap Cap.Ver. PCI Express Extended Cap.ID (AER) 100h

Uncorrectable Error Status Register 104h

Uncorrectable Error Mask Register 108h

Uncorrectable Error Severity Register 10Ch

Correctable Error Status Register 110h

Correctable Error Mask Register 114h

Advanced Error Cap. and Control Register 118h

Header Log Register 1 11Ch

Header Log Register 2 120h



予約 12Ch

オプション、

ルートポートのみ(3)Root Error Command Register 130h

Root Error Status Register 134h

Error Source ID Register 138h

予約 13Ch

オプション(3)(4)Next Cap Cap.Ver.

PCI Express Extended Capability - Alternate Requester ID (ARI)

140h

Control Next Function Function Groups 144h

予約148h-14Ch

オプション(3) Next Cap Cap.Ver. PCI Express Extended Capability - DSN 150h

PCI Express Device Serial Number (1st) 154h

PCI Express Device Serial Number (2nd) 158h

予約 15Ch

オプション(3)Next Cap Cap.Ver.

PCI Express Extended Capability - Power Budgeting Enhanced Capability Header

160h

予約 DS 164h

予約 Power Budget Data - State D0, D1, D3, ... 168h

Power Budget Capability 16Ch

予約 170h-1B4h


PCI Express Extended Capability ID - Latency Tolerance Reporting (LTR)

1B8h

No-Snoop Snoop 1BCh


31 16 15 0







PCI Express Extended Capability ID - Dynamic Power Allocation

1C0h

Capability Register 1C4h

Latency Indicator 1C8h

Control Status 1CCh

Power Allocation Array Register 0 1D0h

Power Allocation Array Register 1 1D4h

予約1D8h-1FCh


PCI Express Extended Capability ID - Single Root I/O Virtualization (SR-IOV)

200h

Capability Register 204h

SR-IOV Status (サポート対象外) Control 208h

Total VFs Initial VFs 20Ch

Function Dependency Link Number VFs 210h

VF Stride First VF Offset 214h

VF Device ID 予約 218h

Supported Page Sizes 21Ch

System Page Size 220h

VF Base Address Register 0 224h


VF Base Address Register 2 22Ch




予約 23Ch

予約240h-270h

オプション(3) Next Cap Cap.Ver. PCI Express Extended Capability ID - Transaction Processing Hints (TPH)

274h


Requester Control Register 27Ch

予約 Steering Tag Upper Steering Tag Lower 280h

予約284h- 2FCh


31 16 15 0






オプション(3) Next Cap Cap.Ver. PCI Express Extended Capability ID - Secondary PCIe Extended Capability

300h

Lane Control (サポート対象外) 304h

予約 Lane Error Status 308h

Lane Equalization Control Register 0 30Ch

Lane Equalization Control Register 1 310h



予約31Ch-33Ch

オプション(3)(5) Next Cap Cap.Ver. PCI Express Extended Capability ID - MCAP 340h


FPGA JTAG ID 348h

FPGA Bitstream Version 34Ch

Status Register 350h

Control Register 354h

Data Write Register 358h

Read Data 0 Register 35Ch

Read Data 1 Register 360h



予約36Ch-3BCh

オプション(3) Next Cap Cap.Ver. PCI Express Extended Capability - VC 3C0h

Port VC Capability Register 1 3C4h

Port VC Capability Register 2 3C8h

Port VC Status Port VC Control 3CCh

VC Resource Capability Register 0 3D0h

VC Resource Control Register 0 3D4h

VC Resource Status Register 0 3D8h

予約400h-FFFh

注記:1. MSI 機能構造体は、 Vivado IDE 内での選択内容によって異なります。

2. エンドポイントコンフィギュレーション用に予約されています (0x00000000 を返す)。

3. PCI Express 拡張コンフィギュレーション空間のレイアウト (100h-FFFh) は、有効化されたオプション機能によって変わりま

す。この表は、オプションのすべての拡張機能構造体 (RBAR) が有効な場合での拡張コンフィギュレーション空間レイアウト

を示しています。

4. SR-IOV オプションが有効に設定されている場合、デフォルトで有効となります。

5. MCAP レジスタおよびその使用法の詳細は、 AR 64761 を参照してください。


31 16 15 0

https://japan.xilinx.com/support/answers/64761.html






表 2‐26: タイプ 0 PCI コンフィギュレーション空間ヘッダー

31 16 15 0


Status Command 04h



Base Address Register 0 10h



Base Address Register 3 1Ch



Cardbus CIS Pointer 28h

Subsystem ID Subsystem Vendor ID 2Ch

Expansion ROM Base Address 30h

予約 CapPtr 34h

予約 38h

Max Lat Min Gnt Intr Pin Intr Line 3Ch

表 2‐27: タイプ 1 PCI コンフィギュレーション空間ヘッダー

31 16 15 0


Status Command 04h





Second Lat Timer Sub Bus Number Second Bus Number Primary Bus Number 18h

Secondary Status I/O Limit I/O Base 1Ch

Memory Limit Memory Base 20h

Prefetchable Memory Limit Prefetchable Memory Base 24h

Prefetchable Base Upper 32 Bits 28h

Prefetchable Limit Upper 32 Bits 2Ch

I/O Limit Upper 16 Bits I/O Base Upper 16 Bits 30h

予約 CapPtr 34h

Expansion ROM Base Address 38h

Bridge Control Intr Pin Intr Line 3Ch





第 3章

コアを使用するデザインこの章では、コアを使用した設計をより容易にするためのガイドラインおよび追加情報を紹介します。

共有ロジック

この機能には、 2 種類の共有方法があります。

• GT COMMON をコアまたはサンプルデザインに含める方法

• GT Wizard をコアまたはサンプルデザインに含める方法

GT COMMON を使用する方法

この機能により、 PCIe® ブロックの複数のインスタンス間で共通ロジックを共有したり、または制限事項はありますがほかのコアと共通ロジックを共有することができます。この共有ロジックにより、デザインの上位モジュールに共有するロジックを配置するのに必要な HDL の変更を小限に抑えることができ、また上位モジュールの追加ポートを有効にし、共有を可能にすることができます。共有ロジックはエンドポイントモードとルートポートモードのどちらでも利用できます。

Vivado® Design Suite ではコアをカスタマイズするときの [Shared Logic] ページでこのオプションを設定することができます。

ロジック共有には 2 つのタイプがあります。

• コアに含まれた共有ロジック

• サンプルデザインに含まれた共有ロジック

これらの両ケースで GT_COMMON ブロックが共有されます。

重要: [Include Shared Logic in Example Design] オプションをオンにして該当するモジュールがサポートディレクトリに生成されるようにする場合、出力ファイルの生成後に [Open IP Example Design] を実行する必要があります。[Include Shared Logic in Core] (デフォルト ) オプションをオンにすると、これらのモジュールがソースディレクトリに生成されます。

重要: [Shared Logic] ページは、 Gen1 以外のリンクスピードを選択した場合のみ表示されます。共有ロジック機能で使用できるのは QPLL1 ブロックのみです。 - Gen1 スピードの場合、デザインは CPLL を使用します。 CPLL は共有できないため、共有ロジック機能は無効となります。 - Gen2 スピードの場合、 QPLL1 または CPLL を選択できます。 [GT Settings] ページの [PLL Type] で CPLL を選択した場合、 [Shared Logic] ページは表示されません。





第 3 章: コアを使用するデザイン

コアに含まれた共有ロジック

この機能を使用すると、 GT_COMMON ブロックをサポートラッパーに置かずに、コア内部で共有できます。この機能を有効にするには、 [Shared Logic] ページで [Include Shared Logic in Core] をオンにします (デフォルトでオン)。


図 3‐1: コアに含まれた共有ロジック






共有 GT_COMMON

GT_COMMON のクワッド位相ロックループ (QPLL) は GT_CHANNEL インスタンスのクワッドに使用できます。PCIe コアが X1 または X2 としてコンフィギュレーションされていて QPLL を使用している場合、残りの GT_CHANNEL インスタンスは、同じ QPLL および GT_COMMON を共有することで、ほかのコアで使用できます。

共有 GT_COMMON インスタンスを使用するには、 [Shared Logic] タブにある [Include Shared Logic in example design] をオンにします。この機能が選択されていると、 GT_COMMON インスタンスがパイプラッパーからサンプルデザインのサポートラッパーに移動します。また、 GT_COMMON の共有を容易にするため上位にポートを追加することができます。

GT_COMMON の共有ロジックを使用することにより、 FPGA リソースを節約でき、また 1 つの GT クワッド内の専用クロック配線を抑えることができます。

GTH で GT_COMMON を共有するケース

制限

• PCIe がレートを Gen3 に変更すると、 GTH パイプラッパーは QPLL をリセットします。共有コアはこのような状況に対処する必要があります。

• パイプラッパーは通常、 Gen1 または Gen2 の場合は PCIe チャネル位相ロックループ (CPLL) を、 Gen3 の場合は QPLL を使用します。 Gen3 PCIe が低速で動作可能な場合、パイプラッパーには QPLL が不要となることがあります。

• GT_COMMON の設定は PCIe コア用に適化されているため、変更することはできません。

表 3‐1:共有 GT_COMMON の使用ケース

GT – PCIe 最大リンクスピードデバイス – 最大リンクスピード共有 GT_COMMON

GTH Kintex UltraScale (040) – PCIe Gen3

PCIe パイプラッパーは、 Gen3 の場合は QPLL を、 Gen1/Gen2 の場合は CPLL を使用します。 PCIe が Gen3 対応であるにもかかわらず低速で動作している場合、ほかの IP でこれを使用できます。







図 3‐2:サンプルデザインに含まれた共有ロジック






GT Wizard を使用する方法

[include GT Wizard in example design] をオンにすると、GT Wizard IP がサンプルデザイン領域に取り込まれます。さらにテストする目的でリコンフィギュレーションもできます。 GT Wizard IP はデフォルトで階層 IP として PCIe IP コアに含まれており、リカスタマイズできません。信号の説明およびその他の詳細は、『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576) [参照 11] または『UltraScale アーキテクチャ GTY トランシーバーユーザーガイド』 (UG578) [参照 12] を参照してください。

\

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

PCI Express はプラグアンドプレイプロトコルであるため、電源投入時に PCIe ホストによってシステムへのエニュメレーションが実行されます。このプロセスでは、ホストが各デバイスから要求されたアドレスサイズを読み出し、そのデバイスにベースアドレスを割り当てます。そのため、 PCIe インターフェイスはホストからの問い合わせに対応できる状態になっている必要があり、そうでなければベースアドレスが割り当てられません。 PCI Express 仕様では、システムが電源安定 (power good) 状態になってから 100ms 後に PERST# がディアサートされ、 PERST# がディアサートされてから 20ms 以内に PCI Express でリンクトレーニングが確立するよう定められています。これは、一般的に「100ms ブートタイム要件」と呼ばれています。

Tandem コンフィギュレーションでは 2 段階の手法が用いられ、これにより IP は PCI Express 仕様に示されているコンフィギュレーション時間の要件を満たすことができます。複数の使用ケースがこのテクノロジでサポートされています。

• Tandem PROM: フラッシュから 1 つの 2 段階ビットストリームをロードします。

• Tandem PCIe: フラッシュから第 1 段階のビットストリームをロードし、 PCIe リンクを介して第 2 段階のビットストリームを MCAP に提供します。

• フィールドアップデートを伴う Tandem: Tandem PROM または Tandem PCIe の初期コンフィギュレーションが完了したら、 PCIe リンクがアクティブの間にユーザーデザイン全体をアップデートします。アップデート領域 (フロアプラン) とデザイン構造はあらかじめ定義されており、 Tcl スクリプトは提供されます。

• Tandem およびパーシャルリコンフィギュレーション: これは Tandem コンフィギュレーションのより一般的なケースで、 Tandem 後にあらゆるサイズ/数の PR 領域のパーシャルリコンフィギュレーションが続きます。

• PCIe を介するパーシャルリコンフィギュレーション: これは PR が後に続く標準的なコンフィギュレーションで、パーシャルビットストリームの送信パスとして PCIe/MCAP を使用します。


図 3‐3: GT Wizard の共有ロジック






これらの機能のいずれかを有効にするには、コアのカスタマイズ時に適切なオプションを選択します。 [Basic] タブで次を実行します。

1. [Mode] を [Advanced] に変更します。

2. [Tandem Configuration or Partial Reconfiguration] を特定のケースに従って変更します。

° Tandem PROM、 Tandem PCIe または Tandem およびパーシャルリコンフィギュレーションの使用ケースの場合は、 [Tandem] を選択します。

° あらかじめ定義されているフィールドアップデートに対してのみ、 [Tandem with Field Updates] を選択します。

注記:現在のリリースの Vivado Design Suite では、このソリューションは一部のデバイスに対してのみベータとして提供されています。ベータのため、インプリメンテーションはすべてのユーザーが利用できますが、ビットストリーム生成はパラメーターによってゲーティングされます。ビットストリームの生成と管理は、 Vivado Design Suite の今後のリリースで強化されます。

° [PR over PCIe] は、 Tandem コンフィギュレーションを有効にしないでパーシャルリコンフィギュレーション用に MCAP リンクを有効にするために選択します。

AXI DMA/Bridge Subsystem for PCI Express は、 UltraScale デバイスに対して Tandem コンフィギュレーションおよびパーシャルリコンフィギュレーションの機能 (フィールドアップデートを伴う Tandem を含む) をサポートしています。サポートされるデバイスの詳細は、『DMA/Bridge Subsystem for PCI Express 製品ガイド』 (PG195) [参照 5] に記載していますが、 Tandem インプリメンテーションの詳細を説明しているのはこのセクションのみです。

サポートされるデバイス

UltraScale Devices Gen3 Integrated Block for PCIe コアおよび Vivado ツールフローは、ザイリンクスのリファレンスボードと特定のデバイス /パッケージの組み合わせをターゲットにしたインプリメンテーションをサポートしています。

Vivado Design Suite 2017.3 リリースでは、 Tandem コンフィギュレーションはすべての UltraScale プロダクションデバイスに対するプロダクションソリューションとして利用できます。ビットストリーム生成は、すべての ES シリコンに対してデフォルトで無効に設定されています。 Tandem コンフィギュレーションは、表 3-2 にあるコンフィギュレーションをサポートしています。


図 3‐4: [Tandem Configuration or Partial Reconfiguration] オプション






Tandem ツールフローの概要

Tandem PROM および Tandem PCIe ソリューションは、 Vivado Design Suite でのみサポートされています。これらのソリューションのツールフローは、次のとおりです。

1. コアのカスタマイズ: サポートされるデバイスを表 3-2 から選択し、[Mode] でコンフィギュレーションモードを [Advanced] に設定し、 [Tandem Configuration or Partial Reconfiguration] で [Tandem] を選択します。

2. コアを生成します。

3. サンプルプロジェクトを開いて、サンプルデザインをインプリメントします。

4. ユーザープロジェクトで、サンプルプロジェクトからの IP や XDC を使用して、コアをインスタンシエートします。

5. ユーザーデザインを合成してインプリメントします。

6. ビットファイルを生成し、次に prom ファイルを生成します。

Tandem フローの一環として、 PCIe コアロジックの外部にある特定エレメントも第 1 段階ビットストリームに含める必要があります。 Vivado デザインルールチェック (DRC) は、これらの状況を認識し、問題を解決する方法を指示します。通常、デザインの制約を変更したり、追加して問題を解決します。

表 3‐2: Tandem PROM/PCIe がサポートするコンフィギュレーション

HDL Verilog のみ

PCIe コンフィギュレーションすべてのコンフィギュレーション ( 大: X8Gen3)

ザイリンクスリファレンスボードのサポート

KCU105 評価ボード (Kintex UltraScale FPGA 用)

VCU108 評価ボード (Virtex UltraScale FPGA 用)

デバイスサポートデバイス(1) PCIe ブロックのロケーション

PCIe リセットのロケーション

Tandem

コンフィギュレーション

フィールドアップデートを伴う

Tandem

Kintex UltraScale

XCKU025 PCIE_3_1_X0Y0 IOB_X1Y103 プロダクションプロダクション







Virtex UltraScale

XCVU065 PCIE_3_1_X0Y0 IOB_X1Y103 プロダクションプロダクション







注記:1. Production シリコンのみが正式にサポートされています。ビットストリーム生成は、すべてのエンジニアリングサンプルシリコン (ES2)

デバイスに対して無効に設定されています。






サンプルデザインが作成される場合には、特定の制約を含むサンプルの XDC ファイルが生成され、これはユーザーが指定するプロジェクトの XDC ファイルへコピーされる必要があります。具体的な制約内容は、サンプルデザインの XDC ファイルに記載されています。また、このサンプルデザイン XDC ファイルには、 BPI や SPI などのフラッシュメモリデバイス用のオプションの設定方法の例も含まれています。

実際に PCIe IP を生成すると、Tandem PROM と Tandem PCIe には違いがないことがわかります。どちらの方法でも生成される IP コアは同じです。このため、 Vivado IDE ではどちらも [Tandem] を選択します。違いがあるのは write_bitstream の実行時で、必要な BIT ファイルが 1 つ (Tandem PROM) なのか 2 つ (Tandem PCIe) なのかをプロパティ (HD.TANDEM_BITSTREAMS) で定義します。コアおよび対応するインプリメンテーションの結果はまったく同一です。

Tandem PROM

Tandem PROM ソリューションは、ビットストリームを 2 つに分割していますが、これらは共にオンボードのローカルコンフィギュレーションメモリ (通常は PROM またはフラッシュメモリデバイス) からロードされます。初のビットストリームは、デザインの PCI Express 部分をコンフィギュレーションし、2 つ目のビットストリームは FPGA の残りの部分をコンフィギュレーションします。図 3-5 に示すように、デザインは 2 段階に分けられていますが、生成される BIT ファイルは 1 つだけであり、第 1 段階と第 2 段階を共に含みます。

Tandem PROM VCU108 サンプルツールフロー

このセクションでは、 VCU108 リファレンスボードをターゲットにした場合の Vivado ツールフローを初から後まで説明します。このフローを説明する上で表示されるパスおよびポインター名には、デフォルトのコンポーネント名「pcie3_ultrascale_0」を使用しています。

1. 新しい Vivado プロジェクトを作成して、表 3-2 にあるデバイス /パッケージの組み合わせを選択します。

2. Vivado IP カタログで、 [Standard Bus Interfaces] → [PCI Express] を展開表示し、 [UltraScale FPGA Gen3 Integrated Block for PCI Express] をダブルクリックして [Customize IP] ダイアログボックスを開きます。


図 3‐5: Tandem PROM ビットストリームのロード手順

X12490

Tandem PROM

First Stage

Second Stage

Stage 1 – PCIe

Stage 2 – UserApplication

UserApplication

Inte

grat

ed B

lock

For P

CIe






3. [Customize IP] ダイアログボックスの [Basic] タブで、次のようにオプションが選択されていることを確認します。

° [Mode]: Advanced

° [PCIe Block Location]: X0Y0

注記: ターゲットデバイスに必要な PCIe ブロックロケーションを、表 3-2 に示すリストから選択して使用します。

° [Tandem Configuration or Partial Reconfiguration]: Tandem


図 3‐6: Vivado IP カタログ






4. その他に必要な PCIe カスタマイズを実行し、 [OK] をクリックしてコアを生成します。

5. どの出力ファイルを生成するかをたずねる画面が表示されたら、 [Generate] をクリックします。

6. [Sources] ウィンドウでコアを右クリックし、 [Open IP Example Design] をクリックします。

Vivado の新しいインスタンスが開き、サンプルデザインが自動的に Vivado IDE にロードされます。

7. 合成およびインプリメンテーションを実行します。

Flow Navigator で [Run Implementation] をクリックします。合成を先に実行するには、 [OK] をクリックします。完全ツールフローによってデザインが実行され、 Tandem PROM をサポートする完全に配線されたデザインが作成されます。


図 3‐7: Tandem PROM






8. PROM またはフラッシュを設定します。

PROM またはフラッシュメモリデバイスのビットストリームを生成するため、適切な設定を行います。 PCIe コア制約ファイル (xilinx_pcie3_uscale_ep_x8g3.xdc など) で、次のように処理します。

° コンフィギュレーションの設定を定義する制約をアンコメントし、カスタマイズします。

° 必要な制約は CONFIG_MODE です。次に例を示します。 set_property CONFIG_MODE BPI16 [current_design] などのようにします。

詳細は、 101 ページの「デバイスのプログラム」を参照してください。

9. ビットストリームを生成します。

合成およびインプリメンテーション完了後、 Flow Navigator で [Generate Bitstream] をクリックします。 Tandem コンフィギュレーションをサポートするビットストリームが runs ディレクトリに生成されます。例: ./pcie_ultrascale_0_example.runs/impl/xilinx_pcie3_uscale_ep.bit

注記:第 1 段階と第 2 段階のビットストリームを個別に生成するオプションがあります。このフローでは、テスト用の JTAG インターフェイスを使用して、各段階のビットストリームロードを制御できます。これらのビットストリームは、 JTAG を使用してロードした場合、 Tandem PCIe ソリューションで使用したものと同じです。ハードウェアでフラッシュメモリから第 1 段階ビットストリームのみをロードしようとしても、HD.OVERRIDE_PERSIST 設定が Tandem PCIe デザインで使用されているものと異なるためうまくいきません。

set_property HD.TANDEM_BITSTREAMS SEPARATE [current_design]

xilinx_pcie3_uscale_ep_tandem1.bit および xilinx_pcie3_uscale_ep_tandem2.bit という名前の BIT ファイルが生成されます。

10. PROM ファイルを生成します。

Vivado の Tcl コンソールで次のコマンドを実行して、VCU108 開発ボードでサポートされる PROM ファイルを作成します。

write_cfgmem -format mcs -interface BPI -size 256 -loadbit “up 0x0 xilinx_pcie3_uscale_ep.bit” xilinx_pcie3_uscale_ep.mcs

Tandem PROM のまとめ

Tandem PROM を使用することにより、 UltraScale デバイスデザインの PCIe 部分をコンフィギュレーションするのに必要な時間を大幅に短縮できます。UltraScale Devices Gen3 Integrated Block for PCIe コアがデザインの詳細の多くを管理するため、設計者はユーザーアプリケーションに集中できます。






Tandem PCIe

Tandem PCIe は、 Tandem PROM と類似しています。第 1 段階ビットストリームでは、 PCI Express 動作に必要なコンフィギュレーションメモリセルのみが PROM からロードされます。第 1 段階のビットストリームがロードされた後、 PCI Express ポートは、エニュメレーショントラフィックに応答します。これに続いて、第 2 段階ビットストリームが PCI Express リンクを介して送信されます。

ビデオ: 「KCU105 用 Tandem PCIe デザインの作成」で KCU105 評価キットをターゲットにしたデザインの作成方法を説明しています。

図 3-8 に、ビットストリームのロードのフローを示します。

Tandem PCIe は、ツールフローおよびビットストリーム生成の点で現在使用されている標準モデルと同様です。ビットストリーム生成を実行すると、 2 つのビットストリームが作成されます。第 1 段階を表す BIT ファイルが PROM にダウンロードされる間、ユーザーアプリケーション (第 2 段階) を表すもう一つの BIT ファイルが Media Configuration Access Port (MCAP) を使用して FPGA の残りの部分をコンフィギュレーションします。

Tandem PCIe VCU108 サンプルツールフロー

このセクションでは、 VCU108 リファレンスボードをターゲットにした場合の Vivado ツールフローを初から後まで説明します。このフローを説明する上で表示されるパスおよびポインター名には、デフォルトのコンポーネント名「pcie3_ultrascale_0」を使用しています。

1. 新しい Vivado プロジェクトを作成する場合、表 3-2 にあるデバイス /パッケージの組み合わせを選択します。

2. Vivado IP カタログで、 [Standard Bus Interfaces] → [PCI Express] を展開表示し、 [UltraScale FPGA Gen3 Integrated Block for PCI Express] をダブルクリックして [Customize IP] ダイアログボックスを開きます。


図 3‐8: Tandem PCIe ビットストリームのロード手順

User Application

X12937

Initial PCIeInterface

FPGA Startup

PROM

CFG

PO

RT

PCIe link


https://japan.xilinx.com/video/hardware/create-tandem-pcie-design-for-kcu105.html





3. [Customize IP] ダイアログボックスの [Basic] タブで、次のようにオプションが選択されていることを確認します。

° [Mode]: Advanced

° [PCIe Block Location]: X0Y0

注記: ターゲットデバイスに必要な PCIe ブロックロケーションを、表 3-2 に示すリストから選択して使用します。

° [Tandem Configuration or Partial Reconfiguration]: Tandem


図 3‐9: Vivado IP カタログ






4. サンプルデザインのソフトウェアは、ベンダー ID およびデバイス ID を使用してデバイスに接続します。ベンダー ID は 16'h10EE、デバイス ID は 16'h8038 となります。 [PF0 IDs] タブで、次のように設定します。

° [Vendor ID]: 10EE

° [Device ID]: 8038

注記:別のソリューションの場合は、ベンダー ID およびデバイス ID を変更し、ソフトウェアをアップデートして新しい値と一致させます。


図 3‐10: Tandem PCIe






5. その他に必要な PCIe カスタマイズを実行し、 [OK] をクリックしてコアを生成します。

コアが生成されると、 Vivado IDE の [Source] ウィンドウにコアの階層が表示されます。

6. [Sources] ウィンドウでコアを右クリックし、 [Open IP Example Design] をクリックします。

Vivado の新しいインスタンスが開き、サンプルデザインプロジェクトが自動的に Vivado IDE にロードされます。

7. 合成およびインプリメンテーションを実行します。

Flow Navigator で [Run Implementation] をクリックします。合成を先に実行するには、 [OK] をクリックします。完全ツールフローによってデザインが実行され、 Tandem PCIe をサポートする完全に配線されたデザインが作成されます。


図 3‐11: [PFO IDs] タブ






8. PROM または Flash を設定し、 2 つの明示的なビットファイルを要求します。

PROM またはフラッシュメモリデバイスのビットストリームを生成するため、次の方法で適切な設定を行います。

° PCIe IP 制約ファイル (pcie3_ultrascale_0_tandem など) で制約を変更します。

° サンプルデザイン制約ファイルに示すとおり、次のプロパティを設定して 2 つの明示的なビットストリームを要求します。

set_property HD.OVERRIDE_PERSIST FALSE [current_design]set_property HD.TANDEM_BITSTREAMS Separate [current_design]

HD.TANDEM_BITSTREAMS のその他の設定値は、 Tandem PROM ソリューションで使用される Combined (デフォルト ) と、デバイス全体の標準の第 1 段ビットストリームを生成する None です。詳細は、 101 ページの「デバイスのプログラム」を参照してください。

9. ビットストリームを生成します。

合成およびインプリメンテーション完了後、 Flow Navigator で [Generate Bitstream] をクリックします。次の 2 つのファイルが作成されて、 runs ディレクトリに保存されます。

xilinx_pcie3_uscale_ep_tandem1.bit|xilinx_pcie3_uscale_ep_tandem2.bit

10. 第 1 段階用の PROM ファイルを生成します。

Vivado の Tcl コンソールで次のコマンドを実行して、VCU108 開発ボードでサポートされる PROM ファイルを作成します。

write_cfgmem -format mcs -interface BPI -size 256 -loadbit “up 0x0 xilinx_pcie3_uscale_ep_tandem1.bit” xilinx_pcie3_uscale_ep_tandem1.mcs

PCI Express を用いた第 2 段階ビットストリームのロード

サンプルカーネルモードドライバーとユーザー空間アプリケーションは、 IP と共に提供されます。関連するソフトウェアおよび資料の詳細は、 AR 64761 を参照してください。

Tandem PCIe のまとめ

Tandem PCIe を使用することにより、 UltraScale デバイスデザインの PCIe 部分をコンフィギュレーションするのに必要な時間を大幅に短縮でき、またビットストリームフラッシュメモリストレージの要件も軽減できます。UltraScale Devices Gen3 Integrated Block for PCIe コアがデザインの詳細の多くを管理するため、設計者はユーザーアプリケーションに集中できます。

フィールドアップデートを伴う Tandem

フィールドアップデートを伴う Tandem は UltraScale デバイス向けのソリューションで、 PCIe リンクを無効にすることなくこのリンクを介して新しいビットストリームをロードできるため、高速コンフィギュレーションの要件を満たし、ユーザーアプリケーションを動的に変更できます。このソリューションは、電源投入時にまず Tandem コンフィギュレーションを使用してデバイスをコンフィギュレーションした後、 FPGA 内の事前に定義された領域に対してパーシャルリコンフィギュレーション (PR) を実行します。これにより、第 1 段階ビットストリームをフラッシュにロックしておくことができ、このイメージに対する更新は UltraScale Devices Gen3 Integrated Block for PCIe コアの特性またはコンフィギュレーションバンク (バンク 65) にある I/O またはクロック管理ブロックを変更する場合のみに抑えられます。フィールドアップデートを伴う Tandem を使用すると、新しい機能が必要になったときにユーザーアプリケーション (基本的に、この IP を除くデザインすべて) を動的に再ロードできます。


https://japan.xilinx.com/support/answers/64761.htm





フィールドアップデートを伴う Tandem はパーシャルリコンフィギュレーションを使用しますが、 IP と一緒に生成したサンプルのデザイン構造とフロアプランを変更しなければ、 PR ライセンスは不要です。フィールドアップデートを伴う Tandem は、汎用的な Tandem + PR ソリューションの特定のユースケースを事前に定義したものです。これら 2 つのソリューション (Tandem と PR) は同じデザインで汎用的にサポートされるため、ユーザーアプリケーション内の複数の小さな領域に対して PR を実行できます。このように汎用的な用途の場合は PR ライセンスが必要です。

UltraScale Devices Gen3 Integrated Block for PCIe コアを生成後、サンプルデザインを作成し、これをフィールドアップデートを伴う Tandem のデザイン構造のテンプレートとして使用できます。このデザインは必要な構造、フロアプラン、プロパティ、およびスクリプトを示しており、これを実際のデザインに合わせて変更して使用できます。このサンプルに従って実際のデザインを 2 つのセクションに分割し、これらを 2 段階のビットストリームにマップします。なお、フィールドアップデートを伴う Tandem はパーシャルリコンフィギュレーションフローを使用しており、このリリースでは非プロジェクトモードでしかサポートされないため、スクリプトが必要となります。

Tandem コンフィギュレーションとの違い

標準的な Tandem コンフィギュレーションとフィールドアップデートを伴う Tandem には、主にデザインレイアウトとデザイン構造の 2 つの違いがあります。

デザインレイアウト

まず、標準的な Tandem コンフィギュレーションとフィールドアップデートを伴う Tandem のどちらの場合も、フロアプランは IP 作成の一部として決定され、変更できません。ただし、フィールドアップデートを伴う Tandem では Pblock が 1 セットでなく 2 セット生成されます。第 1 段階ロジック用の Pblocks に HD.TANDEM のタグが付けられるのは同じですが、もう 1 セットは HD.RECONFIGURABLE のタグが付けられた非常にサイズの大きいユーザーアプリケーション用の Pblock が生成されます。前者には、第 1 段階ビットストリームの生成に関して標準的な Tandem コンフィギュレーションソリューションと同じ規則が適用されます。後者にはパーシャルリコンフィギュレーションに関するすべての規則が適用されます。たとえば代表的なものとして、ユーザーアプリケーションのインプリメンテーション全体がパーシャルビットストリームに含まれるように配線の閉じ込めに関する規則があります。

図 3-12 に、フィールドアップデートを伴う Tandem の KU040 サンプルデザイン用に生成されたフロアプランを示します。ピンクで示した領域は、 UltraScale Devices Gen3 Integrated Block for PCIe コア用に予約されています。この領域には、この IP をインプリメントするための PCIe ハードブロック、 CLB、ブロック RAM およびトランシーバーサイト、そして物理リセットピンを有効にするための I/O バンクが 1 つ含まれます。黄色の領域はピンクの領域を反転したもので、ユーザーアプリケーション用のパーシャルリコンフィギュレーション (PR) を表しています。この領域には、 PCIe IP でカバーされないすべてのクロック、トランシーバー、 I/O およびロジックを含む、残りのリソースが含まれます。

注記: update_region の名前で示した RP の右下隅には、 PIO サンプルデザインロジック、およびデザインの 2 つのセクションを接続する多数のパーティションピンがあります。

パーティションピンまたはパーシャルリコンフィギュレーションソリューションに関するその他の内容に関する詳細は、『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909) [参照 18] を参照してください。






デザイン構造

もう 1 つの違いは、デザイン構造にあります。ユーザーアプリケーションをあるバージョンから別のバージョンへ差し替えるには、ユーザーアプリケーションがそれ自身の階層レベルで自己完結している必要があります。このインスタンシエーションのインターフェイスは変更できません。これは、変更してしまうと上位のスタティックデザインをコンパイルし直す必要があるためです。 UltraScale Devices Gen3 Integrated Block for PCIe コア以外のすべて ( 上位より下の専用の階層レベル)、およびバンク 65 に配置されているすべての I/O ロジック (バッファー、MMCM、 PLL、 XiPhy など) は、この階層 (および下) のレベルにあります。つまり、その他すべてのバンクの I/O ロジックは上位に推論するのではなく、すべてここに配置する必要があります。このため、 I/O バッファーのインスタンシエーションが必要です。

ヒント : このデザイン構造の簡単な例を見るには、 KCU105 デモボードをターゲットにしてサンプルデザインを生成してください。

デザイン構造に関するもう 1 つの要件として、コンフィギュレーションフレームに配置する必要のあるエレメントはすべてこの上位デザイン (または PCIe IP およびユーザーアプリケーションとは別の階層レベル) にも含める必要があります。これらのエレメントとしては、 BSCAN、 ICAP、 STARTUP、 FRAME_ECC および関連コンポーネントなどがあります (その他のエレメントは、『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909) [参照 18] を参照)。これらは動的にリコンフィギュレーションできないため、別の階層に隔離しておく必要があります。このため、これらのエレメントを必要とする IP コア、たとえば BSCAN を使用する Vivado Debug Hub や Memory Interface Generator (MIG) などを安全にインプリメントするには特別な対策が必要です。詳細は、「フィールドアップデートを伴う Tandem デザインのデバッグ」を参照してください。

これ以外の Tandem コンフィギュレーションに関する注意事項はすべて、フィールドアップデートを伴う Tandem にも適用されます。たとえば、 Tandem PROM には PERSIST を使用する必要があり、第 1 段階ビットストリームは同じインプリメンテーションによる第 2 段階ビットストリームとリンクしたままにする必要があります。


図 3‐12: フィールドアップデートを伴う Tandem のフロアプラン (KU040)






フィールドアップデートを伴う Tandem コンフィギュレーションのソフトウェアフロー

Tandem IP をビルドしてサンプルデザインをコンパイルするには、次の手順を実行します。 Vivado Design Suite で IP のカスタマイズからビットストリーム生成までデザインを処理し、 2 種類のデザインコンフィギュレーションを得ます。

1. [Customize IP] ダイアログボックスを開き、 UltraScale Devices Gen3 Integrated Block for PCIe コアをカスタマイズします。

注記: このソリューションは、バージョン 4.2 以降の IP でのみサポートされます。サポートされるのは UltraScale デバイスのみです。

2. PCIe IP コアのカスタマイズで、 [Tandem with Field Updates] を選択します。このオプションは、 [Advanced] モードを選択した場合のみ表示されます。デバッグ機能が必要な場合、 [Use an external STARTUP primitive] をオンにします (デバッグ機能はほとんどのデザインで必要です)。

3. 合成オプションで [Out of context per IP] をオンにして出力ファイルを生成します (デフォルトはオン)。これで IP を合成すると、フルデザインに挿入可能なチェックポイントが生成されます。

4. [Design Sources] ウィンドウで IP を右クリックし、 [Open IP Example Design] をクリックします。

重要: このサンプルデザインは、プロジェクトモードの Vivado IDE ではインプリメントしないでください。プロジェクトモードでも非プロジェクトモードでもコンパイル可能なサンプルデザインは、今後のバージョンの Vivado で提供予定です。

サンプルデザインには、非プロジェクトモードの Tcl フローで使用するスクリプトが付属します。このサンプルスクリプトは field_update_scripts フォルダーにありますが、これらはすべてサンプルデザインフォルダーにあるマスタースクリプトによって参照されます。

5. Vivado Tcl シェルで source コマンドを実行し、プロジェクトディレクトリにある design_field_updates.tcl を実行します。このファイルにより、 2 つのバージョンのサンプルデザインがコンパイルされます。

° デフォルト設定では、 Ver1 が初のデザインです。初のブート時にはこのデザインを使用するため、Tandem ビットストリームが生成されます。

° Ver2 は Ver1 のアップデートに使用するため、パーシャルビットストリームのみが生成されます。

サンプルデザインの詳細

フィールドアップデートを伴う Tandem に必要なデザイン構造を表したシンプルな PIO デザインが、 IP と一緒に生成されます。上位デザインファイル (xilinx_pcie_uscale_ep.v) で上位のピンリストを宣言し、pcie3_ultrascale_0 (この IP) と pcie_app_uscale (この IP 以外すべて) をインスタンシエートします。これら 2 つのサブモジュールにはそれぞれ HD.TANDEM と HD.RECONFIGURABLE のプロパティがタグ付けされます。これにより、配置配線時にインプリメンテーションツールに対して両方の規則に従うよう指示します。

図 3-13 に、フィールドアップデートを伴う Tandem デザインの基本的な階層を示します。第 1 段階ビットストリームはピンク色で示したモジュールのみを含み、第 2 段階ビットストリームは黄色と白色で示したモジュールで構成されます。パーシャルビットストリームは黄色で示したモジュールのみで構成されます。サンプルデザインの階層インスタンスの名前は、図に示したとおりです。






デザインの大半はリコンフィギャラブルパーティションに配置する必要があります。したがって、これらは pcie_app_uscale 階層ツリーに置く必要があります。これには、バンク 65 に配置されているすべての I/O および I/O ロジックならびに PCIe IP の PERSTN ピン以外のすべてが含まれます。新しいバージョンができたら入れ替えができるように、すべてのユーザー I/O バッファーおよびロジック、クロック、 GT など、上記以外すべてのものをこの階層レベルに置く必要があります。この要件があるため、エンベデッド I/O をバンク 65 に配置する必要のある IP を使用したデザインでは、フィールドアップデートを伴う Tandem の使用は推奨しません。これら I/O を人手で抽出する必要があり、その作業は困難であるためです。

デザインの 3 つのパーティション ( 上位、 PCIe IP、およびユーザーアプリケーション) はすべて別々に合成され、2 つのサブモジュールは「アウトオブコンテキスト」とマークされます。これにより、別々のブロックが境界を越えて適化され、インプリメンテーション時にブロックの入れ替えができなくなるのを防ぎます。合成ツールは、自動 I/O 挿入を無効にすれば任意のものを使用できます。 Vivado 合成で自動 I/O 挿入を無効にするには、 -mode out_of_context オプションを選択します。各バージョンのインプリメンテーションはデザイン全体のコンテキスト内で実行されます。 2 番目のバージョンからは、 PCIe IP および小限の上位ロジックの配置配線結果がロックされるため、変更はできません。

デザインスクリプトの詳細

design_field_updates.tcl スクリプトがマスターで、 field_update_scripts フォルダーにあるほかのスクリプトを呼び出します。このマスタースクリプトで変数を設定して初のバージョン (Ver1) または 2 番目のバージョン (Ver2) のみを合成およびインプリメントし、それ以降のバージョンが必要な場合はこれをテンプレートとして使用します。基本的に、このフローはパーシャルリコンフィギュレーション (PR) フローです。 PR の詳細は、『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909) [参照 18] を参照してください。サンプルスクリプトは、『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 21] で提供しています。

次に、スクリプトに関するいくつかの注意点を示します。

• スクリプト内では、ある決まったディレクトリ構造が定義されています。このため、サンプルで作成および使用されるディレクトリ構造に従うことを推奨します。

• 行番号 99 ～ 109 にフラグを設定すると、どのコンフィギュレーションをコンパイルするかを判定できます。

° 初のデザインバージョンしか存在しない場合は、比較するものが何もないためすべてのバージョン 2 フラグおよび PR_verify を 0 に設定します。

° 同様に、バージョン 1 の手順が完了後にバージョン 2 をコンパイルする場合は、すべてのフラグを反転するとバージョン 2 のコンフィギュレーションと PR_verify の手順が実行されます。


図 3‐13: フィールドアップデートを伴う Tandem に必要なデザイン階層

Topxilinx_pcie3_uscale_ep

User Applicationpcie_app_uscale

PCIe IPpcie3_ultrascale_0

X15985-030217






• スクリプトは、初回コンフィギュレーション用 (ver1) と 1 回のフィールドアップデート用 (ver2) に作成されます。それ以降のフィールドアップデートを作成するには、 ver2 に該当する部分をすべてコピーして ver3 以降を作成してください。または、 ver2 を ver3 でグローバル置換してフラグを設定し、上記の 2 番目の方法を実行することもできます。 ver1 と ver2 の手順が完了している場合、これらはもう不要です。

• ユーザーアプリケーションモジュールのアウトオブコンテキスト合成は、 update_verX_synth.tcl スクリプト (X はバージョン番号) で実行されます。ソース、制約およびオプションはこれらのファイルで宣言されます。

• 各バージョンのコンテキスト内インプリメンテーションは、 update_verX_impl.tcl スクリプトで実行されます。各バージョンに対してオプションを変更、制約ファイルを追加、またはレポートを生成するには、これらのスクリプトを編集します。

ビットストリームの生成

提供されるスクリプトを使用すると、リクエストに応じて任意のバージョンを生成できます。set runUpdateVerXBitstreams 1 フラグ (X はバージョン番号) はスクリプトの後の方にあるビットストリーム生成ルーチンを呼び出します。行番号 159 を見るとわかるように、必要に応じて異なる値を与えることにより、異なるタイプのビットストリームを生成できます。次に、それぞれの値で生成されるビットストリームを示します (ここでは例として ver1 の場合を示しています)。

• TandemPCIe: 次に示すビットストリームと、後述する PR ビットストリームが生成されます。

° ver1_tpcie_tandem1 – Tandem PCIe に使用する第 1 段階ビットストリーム (フラッシュに格納)

° ver1_tpcie_tandem2 – Tandem PCIe に使用する第 2 段階ビットストリーム (PCIe リンク経由で供給)

• TandemPROM: 次に示すビットストリームと、後述する PR ビットストリームが生成されます。

° ver1_tprom – 2 段階の Tandem PROM ビットストリーム (フラッシュに格納)

• PR: 次に示す PR ビットストリームのみが生成されます (t* は「tpcie」または「tprom」 )。

° ver1_t*_update_region_partial_clear – ver1 から別のバージョンへのリコンフィギュレーションを実行するユーザーアップデート領域を準備するためのクリアビットストリーム

° ver1_t*_update_region_partial – ver1 の機能部分にロードするパーシャルビットストリーム

generate_bitstreams.tcl の要求に従い、デフォルトでは複数のフォーマット (.bit、 .bin、 .mcs、 .prm) のビットストリームが生成されます。生成するファイルの種類を調整する場合や、ビットストリーム生成設定を変更する場合は、この Tcl ファイルを編集します。

ver1 は必ずしもフラッシュからブートするバージョンでなくてもかまいません。デザインのすべてのバージョンの中でも難易度の高いものを ver1 とすることを推奨します。 ver1 の配置配線結果によってパーティションピンのロケーションが決まり、これによって PCIe コアとユーザーアプリケーション間のインターフェイスの配線がロックされます。したがって、複数のデザインバージョンを同時にコンパイルする場合は、バージョン番号にかかわらず初のコンフィギュレーションとしてフラッシュに格納するバージョンに [TandemPCIe] または [TandemPROM] を選択し、それ以外のバージョンには [PR] を選択してください。

ハードウェア動作の詳細

デバイスの初のコンフィギュレーションは、通常の Tandem コンフィギュレーションと変わりません。デバイスの初のコンフィギュレーションは 2 段階で構成されます。これを Tandem PROM の場合はフラッシュからの 1 つの

ビットストリームで実行し、 Tandem PCIe の場合は 2 つの異なるビットストリーム (1 つはフラッシュから、もう 1 つは PCIe 経由でロード ) で実行します。これら 2 つのアプローチで生成される IP コアはまったく同じため、これらはいずれもフィールドアップデートを伴う Tandem でサポートされます。第 1 段階をロードした時点では PCIe IP のみが動作しますが、それ以外のデザインはまだ存在していないため、 PCIe IP の機能は限られます。リンクトレーニングの実行、およびシステム内のルートポートからの認識は可能です。第 2 段階ビットストリームのロードが完了すると、デバイスは通常の動作モードになります。






それ以降の動的アップデートは、 UltraScale デバイスのパーシャルリコンフィギュレーションに関する基本規則に従います。そのような規則の 1 つに、クリアビットストリームの利用があります。新しいパーシャルビットストリームを送信する前に、現在のアプリケーションをクリアするビットストリームをロードする必要があります。たとえば電源投入時にデザインの「ver1」バージョンをコンフィギュレーションした場合、 ver2_partial.bin (またはその他の新規パーシャルイメージバージョン) のユーザーアプリケーションを準備するために ver1_partial_clear.bin を送信する必要があります。その次の FPGA アップデートでは、 ver3 (またはその他の新規イメージ、あるいは ver 1 への復帰) の領域を準備するために ver2_partial_clear.bin を送信します。

たとえば Tandem PCIe デザインのビットストリーム名とサンプルスクリプトを使用した場合、次のようなシーケンスとなります。

1. FPGA に電源を投入します。 ver1_tpcie_tandem1.mcs がローカルフラッシュから送信されます。

° この時点で PCIe エンドポイントが動作し、エニュメレーションを実行できます。

° PCIe コアは、その他の未コンフィギュレーションデバイスから隔離されています。

2. PCIe リンク経由で ver1_tpcie_tandem2.bin を送信します。

° これでデバイスが完全にプログラムされ、 PCIe とその他のデザインの間で通信が確立され、デザインは自動的に完全な使用モードに切り替わります。

3. FPGA を任意の期間動作させます。

4. アップデートのリクエストを受信したら、 PCIe リンク経由で ver1_tpcie_update_region_partial_clear.bin を送信します。

° これでユーザーアプリケーション領域の準備が完了します。ただしこの領域へのクロックは停止しているため、この時点でユーザーアプリケーションは動作しません。

° ソフトウェアドライバーの命令の一部として、 PCIe コアはユーザーアプリケーションから隔離されます。

5. PCIe 経由で ver2_tpcie_update_region_partial.bin を送信し、新しいユーザーアプリケーションをロードします。

° これで、デバイス全体が新しい機能で動作を再開します。

° PCIe が隔離された状態から完全動作状態への切り替えは自動的に行われます。

6. 手順 4 と手順 5 を繰り返し、次のバージョンに進みます (ver1 に戻ることもできます)。次のバージョンに進むには、まず ver2_tpcie_update_region_partial_clear.bin を送信します。この後、次のバージョンのユーザーアプリケーションをロードするか、 ver1 に戻る手順を実行します。

フィールドアップデートを伴う Tandem デザインのデバッグ

フィールドアップデートを伴う Tandem デザインは、パーシャルリコンフィギュレーションフローを使用するデザインです。アップデート領域はリコンフィギャラブルパーティションで、このパーティションに挿入される各ユーザーアプリケーションはリコンフィギャラブルモジュールです。現在はリコンフィギャラブルモジュール内の一般的なデバッグがサポートされており、フィールドアップデートを伴う Tandem IP インスタンスにはデバッグ回路を含むサンプルデザインを生成できます。リコンフィギャラブルパーティションの上位 (pci_app_uscale) には、デバッグハブの自動挿入に必要なバウンダリスキャンポートが含まれており、各リコンフィギャラブルモジュール内にデバッグコアをインスタンシエートできます。バウンダリスキャンポートは S_BSCAN ポートです。このピン名は変更しないでください。詳細は、『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909) [参照 18] の第 8 章を参照してください。






重要な注意事項

ここでは、ターゲットデバイスを安全かつ確実に動作させる上で重要な注意事項を示します。

• Tandem PCIe を使用する場合、第 1 および第 2 段階ビットストリームをリンクしたままにする必要があります。第 2 段階ビットストリームは、フラッシュから供給される第 1 段階ビットストリームと一緒に生成する必要があります。第 1 段階ビットストリームの後にパーシャルビットストリームまたはクリアビットストリームを使用することや、デザインの別のインプリメンテーション結果から生成した第 2 段階ビットストリームを使用することはできません。

• パーシャルおよびクリアビットストリームをロードする前に、これらが FPGA 内の現在のスタティックデザインと互換であることを必ず確認してください。 PR_Verify はパーシャルリコンフィギュレーションソリューションの基盤となる部分であるため、フィールドアップデートを伴う Tandem でも使用する必要があります。PR_Verify は、複数のデザインコンフィギュレーション (すなわちバージョン) の間に互換性があり、ハードウェア内で安全にオーバーレイできることを確認します。

• デバイスの初の Tandem コンフィギュレーションは、フィールドアップデートを伴う Tandem フロー内のバージョンとしてコンパイルしたビットストリームセットを使用して実行する必要があります。初のビットストリームを標準的な Tandem ビットストリームセットでロードした場合、その後のフィールドアップデートのクリアビットストリームまたはパーシャルビットストリームとの互換性がありません。このため、競合が発生してデバイスが損傷する可能性があります。

既知の制限事項

• Tandem PROM では、プログラミングに使用するために persist をセットして多目的 I/O を維持する必要があります。このため、 Tandem PROM コンフィギュレーション完了後はユーザーデザインからコンフィギュレーションフラッシュにアクセスできません。 FPGA のユーザーデザインからコンフィギュレーションフラッシュをアップデートする必要がある場合は、 Tandem PCIe を使用してください。

• フィールドアップデートを伴う Tandem は現在、 UltraScale および UltraScale+ デバイスでのみ利用できます (UltraScale+ のサポートはベータ )。 7 シリーズデバイスは、今後もこのソリューションでサポートされることはありません。 7 シリーズでこの種のアプローチを利用するには、一般的なパーシャルリコンフィギュレーションソリューションを検討してください。

• 一般的な Tandem + パーシャルリコンフィギュレーションもすべての UltraScale デバイスでサポートされます。これを実行するには、 PCIe IP コア生成時のオプションで標準の [Tandem] を選択し、コアを PR デザインに追加して非プロジェクトモードでコンパイルします。非プロジェクトモードでのコンパイルの詳細は、「非プロジェクトフロー」および『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909) [参照 18] を参照してください。このフローでコンパイルを実行するには、パーシャルリコンフィギュレーションライセンスが必要です。

• デザインのアップデート領域に挿入する IP は、生成時のオプションで [Out of Context per IP] ではなく [Global] をオンにする必要があります。アップデート領域の各バージョンの合成が完了すると、デザインの階層がフラット化され、 1 つのデザインチェックポイントで上位デザインに接続します。

• Tandem コンフィギュレーションソリューションではビットストリーム圧縮がデフォルトで有効ですが、ビットストリーム圧縮はパーシャルリコンフィギュレーションの機能であるフレームごとの CRC と互換性がありません。いずれかの「アップデート」パーシャルビットストリームでフレームごとの CRC チェックが必要な場合は、この機能を有効にし、ビットストリーム圧縮を無効にしてビットストリームを生成し直してください。write_bitstream -cell オプションを使用すると、各デザインイメージに必要なパーシャルビットストリームとクリアビットストリームのみを生成できます。






ユーザーハードウェアデザインでの Tandem の使用

ユーザーデザインに Tandem フローを適用するには 2 つの方法があります。 1 番目はコアと共に配布されるサンプルデザインを使用する方法です。 2 番目は、既存デザインに PCIe IP をインポートして、必要に応じてデザインの階層を変更する方法です。

いずれの方法でも、 Tandem ソリューションに必要なサンプルのクロック供給構造、タイミング制約、および物理ブロック (Pblock) 制約を得るために PCIe サンプルデザインを作成する必要があります。

方法 1 ‐ 既存 PCI Express サンプルデザインの使用

PCI Express コアで必要な作業という観点から見ると、これがも簡単な方法ですが、すべてのユーザーにとって実現可能というわけではありません。このアプローチがデザイン構造上のニーズに見合う場合は、次の手順に従ってください。

1. サンプルデザインを作成します。

「Tandem PROM VCU108 サンプルツールフロー」および「Tandem PCIe VCU108 サンプルツールフロー」で説明されているとおりにサンプルデザインを生成します。

2. ユーザーアプリケーションを挿入します。

PIO サンプルデザインをユーザーデザインに置き換えます。 I/O やグローバルクロックなどのグローバルおよび上位エレメントは上位デザインに挿入することを推奨します。

3. ボードデザインの要件に応じて、 SPI または BPI フラッシュメモリプログラミングの設定をアンコメントまたは変更します。

4. 通常どおりにデザインをインプリメントします。

方法 2 ‐ PCIe デザインを新規 Vivado プロジェクトに移行

方法 1 を利用できない場合は、次の手順に従って PCIe コアおよび目的の Tandem フロー (PROM または PCIe) を新しいプロジェクトで使用します。サンプルデザインにはユーザーデザインに移行する必要のある RTL およびスクリプトが数多くあります。

1. サンプルデザインを作成します。

「Tandem PROM VCU108 サンプルツールフロー」および「Tandem PCIe VCU108 サンプルツールフロー」で説明されているとおりにサンプルデザインを生成します。

2. クロックモジュールを移行します。

コア生成時に [Shared Logic] タブの [Include Shared Logic (Clocking) in the example design] オプションがオンになっている場合、 pipe_clock_i クロックモジュールはサンプルデザインの上位にインスタンシエートされます。必要な PCIe クロックを供給するため、このクロックモジュールをユーザーデザインへ移行する必要があります。

注記: これらのクロックは必要であればユーザーデザインのほかの箇所に使用できます。

3. 上位制約を移行します。

サンプルのザイリンクスデザイン制約 (XDC) ファイルには、 PCIe コア用のタイミング制約、ロケーション制約、および Pblock 制約が含まれています。これらの制約はすべて (I/O ロケーションおよび I/O 規格制約を除く ) ユーザーデザインに移行させる必要があります。制約の中には、デザインの階層がサンプルデザインのものとは異なる場合にアップデートしなければならない階層参照を含むものがあります。






4. 上位 Pblock 制約を移行します。

次の制約は除外されやすいため、この手順で特筆しています。 Pblock 制約は PCIe コアの上位にポイントしている必要があります。

add_cells_to_pblock [get_pblocks main_pblock_boot] [get_cells -quiet [<path>]]

重要: 制約はデバイスに依存しているため、 XDC ファイルで定義されている物理制約を変更しないでください。

5. Vivado プロジェクトに Tandem PCIe IP を追加します。

Flow Navigator で [Add Sources] をクリックします。 [Add Source] ウィザードで [Add Existing IP] をクリックして、Tandem PCIe サンプルデザインの作成に使用した XCI ファイルを参照します。

6. サンプルデザインの XDC ファイルから適切な SPI または BPI フラッシュメモリの設定をコピーして、ユーザーデザインの XDC ファイルに貼り付けます。

7. 通常どおりにデザインをインプリメントします。

Tandem コンフィギュレーションの RTL デザイン

Tandem コンフィギュレーションの場合、 Tandem 以外の PCI Express 製品から若干の変更が必要になります。このセクションでは、コア内に統合されている追加ロジックと、 Tandem PROM ソリューションをインプリメントするために追加されるユーザーアプリケーションの役割について説明します。

クリティカルな入力の多重化 (MUX)

コアへの一部の入力ポートは、第 2 段階のコンフィギュレーションプロセスで無効になるように、多重化 (MUX) されます。これらの MUX は、 mcap_design_switch 信号で制御されます。

これらの入力は、第 2 段階のビットストリームがロードされている間ディアサート状態に保たれます。これで、第 2 段階のロジックがないために発生する不要なグリッチを防ぎ、 PCIe コアは有効な状態に保たれます。mcap_design_switch がアサートされると、 MUX は切り替わり、すべてのインターフェイス信号はこの文書の記載どおりの動作をとります。

TLP リクエスト

コンフィギュレーションリクエストパケットを受信するほか、 PCI Express エンドポイントは、 PCI Express ハードブロック内で処理されない TLP リクエストを受信する場合があります。通常、受信する TLP リクエストは、ベンダー定義メッセージや読み出しリクエストとなります。第 2 段階のビットストリームがロードされる前、 TLP リクエストは UR (サポートされないリクエスト ) を返します。第 2 段階のロードが完了すると、 mcap_design_switch 出力がアサートされて、 TLP リクエストはユーザーデザインで定義されたとおりに機能します






Tandem コンフィギュレーションのロジック

コアおよびサンプルデザインには、 Tandem コンフィギュレーションに特化したポート (信号) が含まれています。これらの信号は第 1 段階 (コア) と第 2 段階 (ユーザーロジック ) 間にハンドシェイクを提供します。ハンドシェイクはコアとユーザーロジック間の通信に必要なものです。表 3-3 には、コアのハンドシェイクポートが定義されています。

これらの信号は、「Tandem コンフィギュレーションの詳細」に説明されている出力トライステートバッファーのリリースなど、ユーザーアプリケーションでのイベントを調整します。これらの信号に関する追加情報は次のとおりです。

• mcap_design_switch は、第 2 段階がロードされた後にアサートされます。第 2 段階のロード後、この出力はルートポートシステムによって制御されます。この信号がディアサートされると必ず、 PCIe ソリューション IP がユーザーデザインの残りの部分から切り離され、 TLP BAR アクセスでは UR (サポートされないリクエスト ) が返されます。

• mcap_eos_out は、 STARTUP プリミティブからの EOS 信号のパススルー出力です。この出力は、第 1 段階がロードされるまでディアサート状態となり、第 1 と第 2 の間でアサートされ、第 2 段階の終わりで再びアサートされます。 FPGA DONE ピンも Tandem ビットストリームをロードする際に同様の動作を示します。

表 3‐3: ポートのハンドシェイク

名称方向極性説明

mcap_design_switch 出力アクティブ High

第 2 段階のユーザーロジックへの切り換えが完了したことを示します。

0: 第 2 段階のロードは完了していない。

1: 第 2 段階のロードが完了している。

mcap_eos_out 出力アクティブ HighSTARTUP プリミティブの End of Startup (EOS) ピンからのパススルー出力です。

cap_req 出力アクティブ High

コンフィギュレーションアクセスポートのアービトレーションリクエスト信号です。この信号を用いて、ユーザーが実装した複数のコンフィギュレーションインターフェイス間での FPGA コンフィギュレーションロジックの使用を調整します。 Media Configuration Access Port (MCAP) が唯一使用されているユーザー実装コンフィギュレーションインターフェイスである場合、この信号は未接続にする必要があります。

cap_rel 入力アクティブ High

コンフィギュレーションアクセスポートのアービトレーションリクエストのリリース信号です。この信号を用いて、ユーザーが実装した複数のコンフィギュレーションインターフェイス間での FPGA コンフィギュレーションロジックの使用を調整します。 MCAP が唯一使用されているユーザー実装コンフィギュレーションインターフェイスである場合、この信号は Low (1'b0) に接続する必要があります。これにより、必要に応じて、 FPGA コンフィギュレーションロジックへの MCAP アクセスが可能になります。

cap_gnt 入力アクティブ High

コンフィギュレーションアクセスポートのアービトレーションの許可信号です。この信号を用いて、ユーザーが実装した複数のコンフィギュレーションインターフェイス間での FPGA コンフィギュレーションロジックの使用を調整します。 MCAP が唯一使用されているユーザー実装コンフィギュレーションインターフェイスである場合、この信号は High (1'b1) に接続します。これにより、必要に応じて、 FPGA コンフィギュレーションロジックへの MCAP アクセスが許可されます。

user_reset 出力アクティブ HighPCIe がリセットされるときに、 PCIe インターフェイスロジックをリセットするために使用できます。 user_clock と同期します。

user_clk 出力 N/A PCIe インターフェイスロジックで使用されるクロックです。

user_lnk_up 出力アクティブ High PCI Express コアがホストデバイスとリンクアップしたことを示します。






• cap_req、 cap_rel、および cap_gnt 信号を用いて、内部コンフィギュレーションアクセスポート (ICAP) など複数のコンフィギュレーションインターフェイス間における FPGA コンフィギュレーションロジックの使用を調整する必要があります。 ICAP は、ほかの IP コアの一部として使用したり、ユーザーデザインに直接インスタンシエートすることができます。 MCAP と ICAP アービトレーション間での調整において、ユーザーデザインに従って各インターフェイスへアクセスできるように、ロジックが作成されて cap_* 信号を使用する必要があります。第 2 段階が完全にロードされるまで、 MCAP には常に排他的アクセスが許可される必要があります。これは、 mcap_design_switch 出力のアサートによって認識されます。初の第 2 段階デザインがロードされると、 MCAP インターフェイスがシステムレベルデザインで使用できます。ルートポート接続によってコンフィギュレーションロジックへのアクセスが要求されると、 cap_req アサートされます。ユーザーデザインは、これに応じて cap_gnt をアサートしてアクセスを許可できます。それに続き、ユーザーデザインは cap_rel をアサートして MCAP がコンフィギュレーションロジックの制御をリリースするよう要求できます。 cap_req のディアサートによりルートポート接続は制御をリリースします。ユーザーロジックが cap_gnt をアサートしない場合、 MCAP へはアクセスできません。同様に、アクセスが MCAP インターフェイスに対して許可されている間、ほかのコンフィギュレーションインターフェイスがコンフィギュレーションロジックにアクセスしないようにする必要があります。

• user_reset も同様に、コア自体がリセットされるときに、コアと通信する任意のロジックをリセットするために使用できます。

• user_clk は、 PCIe IP コアで使用されるメインの内部クロックにすぎません。このクロックを使用して、コアと直接通信するユーザーロジックと同期化させます。

• user_lnk_up は、名前が示すとおり、確立されたリンク上で PCIe コアが現在動作していることを示します。

ユーザーアプリケーションハンドシェイク

Tandem ソリューションが PCI Express ブロックのコア制御とユーザーアプリケーションとの間で切り換えを行うには、 FPGA 内に内部コンプリーションイベントが存在する必要があります。この切り換えメカニズムが必要な理由については、「クリティカルな入力の多重化 (MUX)」で説明しています。 Tandem ソリューションは、 STARTUP ブロックと専用の EOS (End Of Startup) 信号を使用して第 2 段階のプログラミングが完了したことを検出し、その後 PCI Express ブロックの制御をユーザーアプリケーションに切り替えます。この切り換えが生じると、mcap_design_switch がアサートされます。

デザイン内の別の機能で STARTUP ブロックが必要な場合は、IP の外側に STARTUP プリミティブを含むように IP を生成し、デザイン内の IP mcap_eos_in 入力に EOS 出力を接続してください。 IP の外側に STARTUP プリミティブを生成するには、 Vivado IDE でコアをカスタマイズする際に [Use an external STARTUP primitive] オプションをオンにします。

Tandem コンフィギュレーションの詳細

I/O の動作

Tandem コンフィギュレーションデザインの第 1 段階に必要な各 I/O については、その I/O が存在するバンク全体を第 1 段階のビットストリームでコンフィギュレーションする必要があります。このバンクのほかに、コンフィギュレーションバンク (65) も有効となり、これら 2 つのバンク (ただし、リセットピンがコンフィギュレーションバンクの中にある場合は 1 つ) に次の詳細が適用されます。 PCI Express の場合、第 1 段階デザインで必要な信号は sys_reset 入力ポートのみです。したがって、 sys_reset ポートと同じバンクにある第 2 段階のすべての I/O が、第 1 段階でコンフィギュレーションされます。 sys_reset と同じ I/O バンクにあるピンは内部接続されないので、この内部接続が 2 番目のコンフィギュレーションで完了するまで、出力ピンの動作は予期しないものになります。第 2 段階の機能用に初期化が必要なコンポーネントは、第 2 段階のプログラム後にデザインでリセットするのでなければ、これらの I/O バンクに配置しないでください。

出力ピンは、 sys_reset ピンと同じバンクに配置する必要があり、それらの値を第 2 段階のコンプリーションの前にフローティング状態にできない場合は、次の方法で対処できます。第 1 段階のコンプリーション (出力がアクティブになるとき ) から第 2 段階のコンプリーション (ドライバーロジックがアクティブになるとき ) までの間、トライステート状態に保持される OBUFT を使用します。イネーブルピンの制御には mcap_design_switch 信号を使用でき、ハンドシェイクイベントが完了するときにその出力をリリースします。






ヒント : 上位デザインで OBUFT を自動推論またはインスタンシエートしてください。 mcap_design_switch でイネーブル (ポート名は T) を制御しますが、このとき極性に注意してください。

OBUFT test_out_obuf (.O(test_out), .I(test_internal), .T(!mcap_design_switch));

次の構文を例として使用し、リセットピンロケーションをを格納する Pblock を作成します。この Pblock には、バンク全体の I/O のほかに、関連する XiPhy およびクロッキングプリミティブが含まれています。パーシャルコンフィギュレーションの境界と揃うように、 FPGA スライスリソースの初の列も、この Pblock に含まれる必要があります。この領域に配置されるべきすべてのロジックは、 Pblock に追加する必要があり、 HD.TANDEM プロパティを使用して第 1 段階ロジックと特定されます。このロジックは、第 1 段階がロードされた後にアクティブになりますが、第 2 段階がロードされるまでロジックの駆動はアクティブになりません。このことを踏まえた上で、システムデザインを構築する必要があります。これらは、 Pblock 内でグループ化しておくことを推奨します。出力ポート「test_out_obuf」の例を次に示します。

# Create a new Pblock create_pblock IO_pblock

set_property HD.TANDEM 1 [get_cells <my_cell>]

# Range the Pblock to include the entire IO Bank and the associate XiPhy and clocking primitives. resize_pblock [get_pblocks IO_pblock] -add { \ IOB_X1Y52:IOB_X1Y103 \ SLICE_X86Y60:SLICE_X86Y119 \ MMCME3_ADV_X1Y1 \ PLLE3_ADV_X1Y2:PLLE3_ADV_X1Y3 \ PLL_SELECT_SITE_X1Y8:PLL_SELECT_SITE_X1Y15 \ BITSLICE_CONTROL_X1Y8:BITSLICE_CONTROL_X1Y15 \ BITSLICE_TX_X1Y8:BITSLICE_TX_X1Y15 \ BITSLICE_RX_TX_X1Y52:BITSLICE_RX_TX_X1Y103 \ XIPHY_FEEDTHROUGH_X4Y1:XIPHY_FEEDTHROUGH_X7Y1 \ RIU_OR_X1Y4:RIU_OR_X1Y7 \}

# Add components and routes to stage 1 external Pblock# This constraint should be repeated for each primitive within this pblock region

add_cells_to_pblock [get_pblocks IO_pblock] [get_cells test_out_obuf]

# Identify the logic within this pblock as stage1 logic by applying the HD.TANDEM property.# This constraint should be repeated for each primitive within this pblock region set_property HD.TANDEM 1 [get_cells test_out_obuf]

第 2 段階のコンフィギュレーション中、デザイン内の残りのユーザー I/O は、デフォルトでアクティブ High にプルアップされます。アクティブ High に保持されている間、 PUDC_B ピンを使用すると、上述の 3 つを超えるバンク内のすべての I/O がトライステートになります。 Tandem PCIe の場合、第 1 段階と第 2 段階の間には相当な時間が生じ、その時点でこれらのピンはコンフィギュレーションされていないため、各 I/O の内部の弱いプルダウンによって Low に接続されます。

コンフィギュレーションピンの動作

DONE ピンは標準アプローチでのコンフィギュレーションの完了を示します。このピンは Tandem コンフィギュレーションにも使用されますが、その動作は少し異なります。 DONE は、スタートアップシーケンスが実行されるとき、第 1 段階のコンフィギュレーションの後で High になり、第 2 段階のロードが開始すると、 Low に戻ります。Tandem PROM の場合、第 2 段階が同じビットファイルにあるので、この動作がすぐに開始します。 Tandem PCIe の場合、第 2 段階のビットストリームが PCIe MCAP に転送されるときにこの動作が発生します。 DONE ピンは第 2 段階のコンフィギュレーションの後に High になりその状態を維持します。






コンフィギュレーションパーシスト (Tandem PROM の場合のみ)

UltraScale デバイスで Tandem PROM コンフィギュレーションを使用する場合は、コンフィギュレーションパーシスト (Persist) が必要です。第 1 段階および第 2 段階コンフィギュレーションで使用された多目的 I/O は、第 2 段階コンフィギュレーションが完了した後ユーザー I/O として使用できません。このため、 Tandem PROM コンフィギュレーション完了後はユーザーデザインからコンフィギュレーションフラッシュにアクセスできません。 FPGA のユーザーデザインからコンフィギュレーションフラッシュをアップデートする必要がある場合は、 Tandem PCIe を使用してください。

使用するコンフィギュレーションモードに対して PERSIST オプションが適切に設定されていても、必要な多目的 I/O がユーザー I/O として使用されている場合には、write_bitstream 中に各インスタンスに対して次のエラーが出力されます。

ERROR: [Designutils 12-1767] Cannot add persist programming for site IOB_X0Y151.ERROR: [Designutils 12-1767] Cannot add persist programming for site IOB_X0Y152.

Tandem PROM を使用するには、これらのサイトを使用しているユーザー I/O の位置を変更する必要があります。

PROM の選択

Tandem コンフィギュレーションでは、コンフィギュレーション PROM に対する特定要件はありませんが、 100ms の仕様を満たすには、次の 3 つの条件を満たす PROM を選択する必要があります。

1. ザイリンクスコンフィギュレーションでサポートされていること。

2. 第 1 段階と第 2 段階の両方のコンフィギュレーションに合ったサイズであること。つまり、ビットストリーム全体が入るだけのサイズの PROM であること。

° Tandem PROM の場合、第 1 段階と第 2 段階の両方のビットストリームがここに格納されます。このビットストリームは標準ビットストリームよりも若干サイズが大きくなります (4 ～ 5% 大きい)。

° Tandem PCIe の場合、ビットストリームのサイズは約 1MB ですが、デザインのインプリメンテーション結果、デバイス選択、および圧縮効果によって多少変わります。

3. 第 1 段階ビットストリームのサイズおよび計算されたビットストリームのロード時間に基づいて PCI Express のコンフィギュレーション時間の要件を満たしていること。詳細は、「Tandem コンフィギュレーションのビットストリームロード時間の計算」を参照してください。

サポートされている PROM およびデバイスビットストリームサイズのリストは、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 7] を参照してください。

デバイスのプログラム

PROM へのプログラムに関して Tandem ビットストリームと標準のビットストリーム間では違いはありません。Tandem ビットストリームのプログラムには、 JTAG、スレーブおよびマスター SelectMAP、 SPI、 BPI などすべての標準のフラッシュメモリプログラミング方法を使用できます。使用するプログラミング方法に関係なく、第 1 段階のロードが完了すると DONE ピンがアサートされて、動作が開始します。

注記: JTAG 専用モードでは、モードピンを 101 に設定しないでください。これにより、この ICAP 機能が制限されるため、第 2 段階の正しいロードが実行されなくなります。

SPI または BPI のフラッシュメモリプログラミングの準備を整えるには、ビットストリーム生成の前に適切な設定を有効にしておく必要があります。これは、次に示すようにデザインの XDC ファイルに特定フラッシュメモリデバイスの設定を追加することで完了します。例は、 PCI Express サンプルデザインを使用して生成した制約ファイルの中にあります。使用しているボードおよびフラッシュメモリプログラミング要件を満たすよう、既存のオプション (コメントされている ) をコピーします。






Tandem PROM の例を次に示します。

# BPI Flash Programmingset_property CONFIG_MODE BPI16 [current_design]set_property BITSTREAM.CONFIG.BPI_SYNC_MODE Type1 [current_design]set_property BITSTREAM.CONFIG.CONFIGRATE 33 [current_design]set_property CONFIG_VOLTAGE 1.8 [current_design]set_property CFGBVS GND [current_design]

内部生成された CCLK と外部から供給される EMCCLK の両方が、 SPI および BPI プログラミングでサポートされています。 EMCCLK を使用した場合、コンフィギュレーションクロックに対する許容誤差がより厳しくなるため、コンフィギュレーションレートがより高速になります。 Vivado Design Suite での EMCCLK の使用に関する詳細は、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 7] を参照してください。

Vivado Design Suite でのコンフィギュレーションの詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参照 20] を参照してください。

ビットストリーム暗号化

ビットストリームの暗号化は、 Tandem PROM および Tandem PCIe の両アプローチに対して Tandem コンフィギュレーションでサポートされています。 MCAP では暗号化された初のロードの完了後に (ICAP とは異なり ) 暗号化されていないビットストリームを受信できないため、 Tandem PCIe の場合、第 2 段階ビットストリームは第 1 段階ビットストリームと同じキーを使用して暗号化された状態にしておく必要があります。

Tandem PROM/PCIe のリソース制限

PCIe IP は、第 2 段階のビットストリームの FPGA へのロードが完了した直後に発生するグローバルチップリセット (GSR) からは切り離しておく必要があります。このため、第 1 段階と第 2 段階のロジックは同じコンフィギュレーションフレームに配置できません。 PCIe IP で使用されるコンフィギュレーションフレームは、シリアルトランシーバー、 I/O、 FPGA ロジック、ブロック RAM、またはクロッキングから構成されていて、 1 つのクロック領域を垂直方向に占拠します。リソース制限は次のとおりです。

• 1 つの GT クワッドには、 4 つのシリアルトランシーバーが含まれています。 X1 または X2 デザインでは GT クワッド全体が使用されるため、ユーザーアプリケーションで利用できる未使用のシリアルトランシーバーはありません。使用される GT クワッドの数は、 Vivado IDE でコアをカスタマイズする際に選択した GT クワッドにより異なります。

• 第 1 段階の I/O バンクと第 2 段階の I/O バンク間の DCI カスケード接続はサポートされていません。

• DCI の Match_Cycle オプションをウェイトなしに設定して、第 1 段階のコンフィギュレーション時間を小にします。

set_property BITSTREAM.STARTUP.MATCH_CYCLE NoWait [current_design]

PCIe リセットピンの移動

一般に、第 1 段階ビットストリームのサイズを小化するには、専用のリセット配線と専用の PCIe リセットパッケージピン (PERSTN0) を使用する必要があります。これらの選択は、適用可能な場合にはデフォルトで有効になっています。この専用リセットを使用できないシステムデザインの場合、 Vivado IDE で専用 PERST 配線リソースの使用を無効にする必要があります。リセットピンに新しいロケーションを選択する場合、第 1 段階でコンフィギュレーションされる I/O ロケーションすべてを検討する必要があります。物理的にコアから離して配置される I/O は、第 1 段階に余分なコンフィギュレーションフレームが含まれる原因となります。これは、 I/O を第 1 段階に含めるために必要な配線リソースが追加されるためです。

リセットピンのロケーションに関係なく、バンク 65 は第 1 段階に保持する必要があります。 QSPI などのコンフィギュレーションモードを使用したとしても、可能な高速のコンフィギュレーションには EMCCLK が必要となり、デュアルモードピンはバンク 65 に配置されます。






非プロジェクトフロー

非プロジェクト環境では、プロジェクト環境と同じ基本アプローチが取られます。まず、「Tandem PCIe VCU108 サンプルツールフロー」に示すように IP カタログを使用して IP を作成します。コア生成後の出力ファイルの一つに、コアの詳細をすべて示す .xci ファイルがあります。このファイルを使用して、必要なデザインソースをすべて再生成できます。

非プロジェクト環境でのサンプルフローは次のとおりです。

1. サンプルデザインまたはユーザーデザインのデザインソースをロードします。

read_verilog <verilog_sources>read_vhdl <vhdl_sources>read_xdc <xdc_sources>

2. ターゲットデバイスを定義します。

set_property PART <part> [current_project]

注記: これは非プロジェクトフローですが、バックグラウンドにプロジェクトがあります。 IP をロードする前にデバイスを明示的に指定するために、この作業が必要です。

3. PCIe IP をロードします。

read_ip pcie_ip_0.xci

4. デザインを合成します。このステップで .xci から IP ソースが生成されます。

synth_design -top <top_level>

注記:独立した (out of context) 合成を実行する場合は、制約ファイルを使用して、インプリメンテーション中にのみ使用される Pblock 制約を適用する必要があるかもしれません。これは、一部の制約は、結合されているデザイン全体に依存して制約を適用するためです。

5. Persist ピンを設定するためのコンフィギュレーションモードの確認など、デザインに対するすべてのカスタマイズは、デザインの XDC ファイル内で行われていることを確認します。

6. デザインをインプリメントします。

opt_designplace_designroute_design

7. ビットファイルを生成します。 Tandem PCIe には -bin_file オプションを使用してください。 BIN ファイルは 32 ビットの境界に揃えられ、 PCIe を介した第 2 段階ビットストリームのソフトウェアロードを容易にします。

write_bitstream -bin_file <file>.bit

Tandem IP コアのシミュレーション

Tandem PROM または Tandm PCIe コアの機能は STARTUP モジュールに依存しているため、シミュレーション中にこの点を考慮する必要があります。

PCI Express コアは、第 2 段階のビットストリームがデバイスにいつロードされたかを認識するため、 EOS 出力信号のアサートに STARTUP ブロックを利用します。第 2 段階のロジックと機能させるために PCIe コアをリリースするには、この STARTUP ブロックをシミュレーションする必要があります。これは、階層参照を使用して EOS 信号を STARTUP ブロックに強制して実行します。その理由は、階層参照をサポートしない結果シミュレータは、 Tandem デザインのシミュレーションに使用できないためです。次のコード例はその方法を示したものです。

// Initialize EOS at time 0force board.EP.pcie_ip_support_i.pcie_ip_i.inst.startup_i.EOS = 1'b1;

<delay until after PCIe reset is released>






// Deassert EOS to simulate the starting of the 2nd stage bitstream loadingforce board.EP.pcie_ip_support_i.pcie_ip_i.inst.startup_i.EOS = 1'b0;

<delay a minimum of 4 user_clk cycles>

// Reassert EOS to simulate that 2nd stage bitstream completed loadingforce board.EP.pcie_ip_support_i.pcie_ip_i.inst.startup_i.EOS = 1'b1;// Simulate as normal from this point on.

上記の行の PCIe コアへの階層は、ユーザーデザインのものと一致させるため変更する必要があります。この行はコアと共に配布されているサンプルシミュレーションの board.v というファイルにもあります。

Tandem コンフィギュレーションのビットストリームロード時間の計算

コンフィギュレーションのロード時間は、コンフィギュレーションクロック周波数と精度、コンフィギュレーションインターフェイスのデータ幅、およびビットストリームサイズによって変わります。この計算は次の 3 つの手順で行われます。

1. 標準クロック周波数に基づいて小クロック周波数を計算し、標準値からの変動値を差し引きます。

小クロック周波数 = 標準クロック - クロック変動分

2. 小 PROM 帯域幅を計算します。これはデータバス幅、クロック周波数、 PROM タイプによって変わります。この PROM 帯域幅は、小クロック周波数をバス幅で乗じた値です。

PROM 帯域幅 = 小クロック周波数 × バス幅

3. 第 1 段階のビットストリームのロード時間を計算します。これは手順 2 からの小 PROM 帯域幅を write_bitstream でレポートされる第 1 段階のビットストリームサイズで割った値です。

第 1 段階のロード時間 = (第 1 段階ビットストリームサイズ) / (PROM 帯域幅)

write_bitstream でレポートされる第 1 段階のビットストリームサイズは、ターミナルからまたはログファイルから直接読み出すことができます。

次に示すのは write_bitstream ログからの抜粋で、 VU095 デバイスにおける第 1 段階ビットストリームのサイズを表しています。

Creating bitstream...Tandem stage1 bitstream contains 9175424 bits.Tandem stage2 bitstream contains 277708576 bits.Writing bitstream ./xilinx_pcie_ip.bit...

これらの値は、 2 つに分かれた (1 または 2) ビットストリーム段階のサイズを明示しています。ビットストリームの圧縮効果はこれらの値に反映されています。

例 1

例 1 のコンフィギュレーションは次のとおりです。

• Quad SPI フラッシュ (x4) 、 66MHz ± 200ppm で動作

• 第 1 段階のサイズ = 9175424 ビット = 8.75Mb

コンフィギュレーションのロード時間の計算手順は次のとおりです。

1. 小クロック周波数を計算します。

66MHz × (1 - 0.0002) = 65.98MHz






2. 小 PROM 帯域幅を計算します。

4 ビット × 65.98MHz = 263.92Mb/s

3. 第 1 段階のビットストリームのロード時間を計算します。

8.75Mb / 263.92Mb/s = ~0.0332 すなわち 33.2ms

例 2

例 2 のコンフィギュレーションは次のとおりです。

• BPI (x16) 同期モード、 50MHz ± 100ppm で動作

• 第 1 段階のサイズ = 9175424 ビット = 8.75Mb

コンフィギュレーションのロード時間の計算手順は次のとおりです。

1. 小クロック周波数を計算します。

50MHz × (1 - 0.0001) = 49.995MHz

2. 小 PROM 帯域幅を計算します。

16 ビット × 49.995MHz = 799.92Mb/s

3. 第 1 段階のビットストリームのロード時間を計算します。

8.75Mb / 799.92Mb/s = ~0.0109s すなわち 10.9ms

ビットストリーム圧縮の使用

第 1 段階のビットストリームのサイズを小限に抑えることが Tandem コンフィギュレーションの終目的であるため、ビットストリーム圧縮は非常に有効です。このオプションでは、マルチフレーム書き込みテクニックを利用してビットストリームのサイズを縮小するため、その結果コンフィギュレーション時間を短縮できます。圧縮量は各デザインで異なります。 Tandem が選択されている場合、 IP レベルの制約で圧縮機能が有効になります。これは、必要に応じてユーザーデザイン制約に上書きできます。次のコマンドを使用して、ビットストリーム圧縮を有効化/無効化できます。

set_property BITSTREAM.GENERAL.COMPRESS <TRUE|FALSE> [current_design]

ビットストリームのロード時間に関するその他の注意事項

ビットストリームコンフィギュレーション時間は、次の要素によっても影響を受けます。

• 電源の立ち上がり時間 (レギュレータによる遅延など)

• TPOR (パワーオンリセット )

電源の立ち上がり時間はデザインによって異なります。立ち上がり時間の長いデザインや遅延の多いデザインは避けてください。 FPGA コンフィギュレーションを開始するために必要な FPGA 電源については、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 7] を参照してください。

通常、 FPGA の電源はシステム電源と同時またはその少し前に立ち上がります。このような場合、システム電源が安定するまで 100ms はカウントされないため、タイミングマージンを得ることができます。しかしこれもまたデザインによって異なります。 FPGA 電源とシステム電源との関係を理解するには、システムを特性評価する必要があります。

TPOR は、標準電源立ち上がりレートの場合は 57ms、 UltraScale デバイスの高速立ち上がりレートの場合は 20ms です。詳細は『Kintex UltraScale FPGA データシート : DC 特性および AC スイッチ特性』 (DS892) [参照 8]、および『Virtex UltraScale FPGA データシート : DC 特性および AC スイッチ特性』 (DS893) [参照 9] を参照してください。






「Tandem コンフィギュレーションのビットストリームロード時間の計算」の例 1 (Quad SPI フラッシュ [x4]、 66MHz ± 200ppm で動作) で、 2 つのケースを考えてみます。

• ケース 1: ATX 供給がない場合

• ケース 2: ATX 供給がある場合

3.3V および 12V のシステム電源の後、FPGA 電源は安定レベル (2ms) に達するするものと仮定します。この時間差は TFPGA_PWR と呼ばれます。この場合、システム電源の後に FPGA 電源が立ち上がるため、電源の立ち上がり時間は 100ms のマージンを縮めることになります。

テストする式は次のようになります。

TPOR + ビットストリームロード時間 + TFPGA_PWR < 100ms (ATX がない場合)

TPOR + ビットストリームロード時間 + TFPGA_PWR - 100ms < 100ms (ATX がある場合)

ケース 1: ATX 供給がない場合

ATX 供給がないため、3.3V および 12V のシステム電源が公称電圧の 9% および 8% 内にそれぞれ達すると、100ms がカウントされ始めます (詳細は、『PCI Express Card Electromechanical Specification』を参照)。

50ms (TPOR) + 33.2ms (ビットストリーム時間) + 2ms (立ち上がり時間) = 85.2ms

85.2ms < 100ms PCIe 標準 (okay)

このケースではマージンは 14.8ms になります。

ケース 2: ATX 供給がある場合

ATX 供給は、システム電源が安定しているときを示す PWR_OK 信号を供給します。この信号は実際の電源が安定してから低 100ms 後にアサートされます。つまり、タイミングマージンにこの 100ms が追加される可能性があるということです。

50ms (TPOR) + 33.2ms (ビットストリーム時間) + 2ms (立ち上がり時間) - 100ms = -14.8ms

-14.8ms < 100ms PCIe 標準 (okay)

このケースではマージンは 114.8ms になります。

サンプルビットストリームサイズ

第 1 段階のビットストリームの終的なサイズは次に示すさまざまな要素の影響を受けて変わります。

• IP: 第 1 段階の Pblock のサイズおよび形状が、第 1 段階に必要なフレーム数を決定します。

• デバイス : デバイスの幅が広いほど、 IP をクロッキングリソースに接続するのに必要な配線フレーム数が多くなります。

• デザイン: リセットピンの位置は、ユーザーアプリケーションの追加によってもたらされる多くの要素のうちの 1 つです。

• GT のロケーション: 使用する GT クワッドの選択によって、第 1 段階ビットストリームのサイズが変わります。も効率的にリソースを使用するには、 PCI Express ハードブロックに隣接する GT クワッドを使用します。

• 圧縮: デバイス使用率が高くなると、圧縮の効果は低くなります。






ベースラインとして、 PCIe IP と共に生成されるサンプル (PIO) デザインのビットストリームサイズおよびコンフィギュレーション時間の例をいくつか示します。

Tandem PCIe 手法を使用して第 2 段階のビットストリームをロードするのにかかる時間は、次の 3 つの追加要因によって異なります。

• PCI Express リンクの幅と速度。

• MCAP をプログラムするのに使用されたクロック周波数。

• ルートポートホストがエンドポイント FPGA デザインへビットストリームを供給できる効率性。ほとんどのデザインでは、これらが制限要因です。

これら 3 つの要因のも低い帯域幅によって、第 2 段階のビットストリームがロードされる速度が決定します。

クロッキング

UltraScale Devices Gen3 Integrated Block for PCIe コアが使用する基準クロックは、 100MHz、 125MHz、または 250MHz に設定できます。これには次の条件が適用されます。

• 基準クロックは同期または非同期クロックを使用でき、大 ±300PPM (ワーストケースで 600PPM) とする必要があります。スペクトラム拡散クロック (SSC) を有効にした場合は、同期リンクとする必要があります。

• PIPE インターフェイスのプライマリクロックは PCLK です。

• PCLK 以外に、このコアをサポートするには CORECLK と USERCLK の 2 つのクロックが必要です。

• これらクロックの生成には BUFG_GT を使用します。これらのクロックはすべて TXOUTCLK ピンから駆動されます。これは GTREFCLK0 から CPLL を経由した派生クロックです。 QPLL を使用するアプリケーションでは、QPLL は GT PCS/PMA ブロックにのみ供給され、 TXOUTCLK は CPLL から生成されます。

• UltraScale GTH 基準クロックのソースは IBUFDS_GTE3 から直接供給する必要があります。

• FPGA 汎用インターコネクトに基準クロックを使用するには、もう 1 つの BUFG_GT を使用する必要があります。

図 3-14 に、 x2 PCIe のクロッキングアーキテクチャの例を示します。

表 3‐4: ビットストリームサイズおよびコンフィギュレーション時間の例(1)

デバイスフルビットストリームフル: BPI16 (50MHz) Tandem 第 1 段階(2) Tandem: BPI16

(50MHz)

KU040 122.1Mb 152.7ms 7.6Mb 9.5ms

VU095 273.5Mb 341.8ms 8.8Mb 10.9ms

VU190 577.1Mb 721.4ms 11.2Mb 14.1ms

注記:1. ここに示すコンフィギュレーション時間には TPOR は含まれていません。

2. PIO デザインは非常に小さいため、ビットストリームサイズを小さくするのに圧縮は非常に効果的です。これらの数値は、フ

ルデザインを使用した場合により正確な見積もりができるように、圧縮なしで得たものです。これらの値は、 Vivado Design Suite 2015.1 で PCIe Gen3x8 コンフィギュレーションを使用して生成されました。






詳細は、ザイリンクス PCI Express ソリューションセンターの各アンサーを参照してください。

一般的な PCI Express ソリューションでは、 PCI Express 基準クロックはスペクトラム拡散クロック (SSC) で、100MHz で供給されます。ほとんどのコマーシャル用の PCI Express システムでは、 SSC を無効にできません。 SSC および PCI Express の詳細は、『PCI Express Base Specification Revision 3.0』 [参照 2] のセクション 4.3.7.1.1 を参照してください。

重要: すべてのアドインカードデザインは、供給される基準クロックの特性のため、同期クロック供給を使用する必要があります。スロットクロックを使用しているデバイスの場合、リンクステータスレジスタのスロットクロックコンフィギュレーションを Vivado® IP カタログで有効にする必要があります。

各リンクパートナーデバイスは同じクロックソースを共有します。図 3-15 および図 3-16 は、 100MHz の基準クロックを使用するシステムを示しています。デバイスがエンベデッドシステムの一部であったとしても、システムがコマーシャル版の PCI Express ルートコンプレックスまたはスイッチを一般的なマザーボードクロック供給で使用する場合は、同期クロック供給をやはり使用する必要があります。

注記:図 3-15 および図 3-16 では、ボードレイアウトを示しています。ボードレイアウト時には、カップリング、終端などが適切に使用されていることを確認してください。『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576) [参照 11] の「ボードデザインのガイドライン」を参照してください。


図 3‐14: クロッキング

IBUFDS_GTE3

IBUFG_GT

GT Lane 0 GT Lane 1

Clock Module

BUFG_GT BUFG_GT BUFG_GT

TXOUTCLK

BUFGT*

CORECLK

USERCLK PCLK

GTREFCLK0

GTREFCLK0

REFCLK for FPGA Fabric

CLKP

CLKN REFCLK for GT

FPGA Fabric

[TX/RX]USRCLK2 [TX/RX]USRCLK2

[TX/RX]USRCLK [TX/RX]USRCLK

PROG Div







バージョン 2017.1 以降の PCIe コアは、クロックを有効にする前に GT の電源が安定していることを確認します。

• この結果、 IBUFDS_GTE4 (PCIe 基準クロック ) によって駆動される BUFG_GT の CE は、 VCC ではなくロジックによって駆動されます。

• 以前の CE は VCC によって駆動されており、もう 1 つの BUFG_GT が IBUFDS_GTE4 に並列に接続されている場合、 opt_design/MLO によって挿入される BUFG_GT_SYNC で両方の BUFG_GT を駆動できていました。

• PCIe BUFG_GT クロックと同じ CE を共有していない並列 BUFG_GT がある場合、 2 つの BUFG_GT_SYNC が opt_design/MLO によって挿入されます。

• IBUFDS_GTE4 で駆動される BUFG_GT には BUFG_GT_SYNC を 1 つしか持つことができないため、ルーターはもう 1 つの BUFG_GT_SYNC の配線方法がわからず、 IBUFDS_GTE4/ODIV2 で駆動されるクロックネットは配線されません。

• IBUFDS_GTE4 によって駆動される複数の BUFG_GT が同じ CE/CLR ピンを共有していることを確認する必要があります。


図 3‐15: 100MHz の基準クロックを使用したエンベデッドシステム


図 3‐16: 100MHz の基準クロックを使用したオープンシステムアドインカード

DeviceEndpoint

X12208

PCI Express Switch or Root

Complex Device

PCI Express Clock Oscillator

100 MHz

GTH Transceivers

100 MHz

Embedded System Board

PCIe Link

PCIe Link

PC

Ie L

ink

PCI Express Connector

Device Endpoint

GTHTransceivers

100 MHz with SSCPCI Express Clock

PCI Express Add-In Card

+ _P

CIe

Lin

k

PC

Ie L

ink

PC

Ie L

ink






リセット

このコアは、 PCI Express 基本リセット中にアサートされた非同期でアクティブ Low のリセット信号である sys_reset を使用してシステムをリセットします。この信号をアサートすると、 GTH トランシーバーを含むコア全体がハードリセットになります。このリセットをリリースした後、コアはリンクトレインを試み、また通常操作を再開しようとします。アドインカードなど一般的なエンドポイントアプリケーションにはサイドバンドリセット信号があり、これを sys_reset に接続する必要があります。サイドバンド・システムリセット信号がないエンドポイントアプリケーションの場合は、初期ハードウェアリセットをローカルに生成する必要があります。 PCI Express では 4 つのリセットイベントがあります。

• コールドリセット : 電源を投入すると実行される基本的なリセットです。 sys_reset 信号をアサートするとコアがコールドリセットになります。

• ウォームリセット : 電源を切って再投入せずにハードウェアにより実行される基本的なリセットです。sys_reset 信号をアサートするとコアがウォームリセットになります。

• ホットリセット : プロトコルを介して PCI Express リンク上のバンド内で実行するリセットで、エンドポイントデバイス全体をリセットします。この場合は sys_reset は使用されません。ホットリセットの場合は、リセットのソースを示すため cfg_hot_reset_out 信号がアサートされます。

• ファンクションレベルリセット : プロトコルを介して PCI Express リンク上のバンド内で実行するリセットで、特定機能のみをリセットします。この場合、コアはリセットされる機能に対応する cfg_flr_in_process および/または cfg_vf_flr_in_process のいずれかのビットをアサートします。リセットされる機能に関連するロジックは、リセットプロセスが完了したことを示すため、 cfg_flr_done または cfg_vf_flr_done の対応するビットをアサートする必要があります。

FLR が開始される前に、ソフトウェアは、特定の機能をターゲットにしたトラフィックを一時的に無効にします。 FLR が開始されると、エラーログやエラー通知なしでリクエストおよびコンプリーションが破棄されます。

Initiate Function Level Reset ビットに 1b を書き込んで FLR が開始された後、この機能は 100ms 以内に FLR およびその他機能固有の初期化を完了する必要があります。

コアのユーザーアプリケーションには user_reset 出力信号があります。この信号は user_clk に同期してディアサートされます。 user_reset 信号は次のコンディションが発生するとアサートされます。

• 基本リセット : sys_reset アサートされると発生します (コールドまたはウォーム)。

• コアラッパーのある PLL: ロックが失われると、クロック入力の安定性に問題があることを示します。

• トランシーバー PLL ロックの損失: トランシーバーがロックを失うと、 PCI Express リンクに問題があることを示します。

記載されているすべてのコンディションが解決した後、 user_reset 信号が user_clk と同期してディアサートされ、コアがトレインを試み、平常操作が開始されます。

AXI4‐Stream インターフェイスの説明

ここでは、コアのユーザーインターフェイスに関連する機能、パラメーター、および信号の詳細について説明します。

機能の概要

図 3-17 に、コアのユーザーインターフェイスを示します。






このインターフェイスは、 PCIe リンクとユーザーアプリケーション間でのデータ転送を可能にする 4 つの個別のインターフェイスとして構成されています。

• PCIe のコンプリーターリクエスト (CQ) インターフェイスを介して、リンクからのリクエストがユーザーアプリケーションに送信されます。


図 3‐17:統合ブロックのユーザーインターフェイスの図

PCIeRequesterInterface

Completer Request Interface

Client

CompleterInterface

PCIe RequesterInterface

PCIe CompleterInterface

AXI4Master

Completer Completion Interface

AXI4Slave

Requester RequestInterface

Requester CompletionInterface

RX MessageInterface

Tag AvailabilityStatus

Flow ControlStatus

m_axis_cq_*

cfg_msg_*

s_axis_cc_*

s_axis_rq_*

pcie_tag_av[1:0]

m_axis_rc_*

X12207

Integrated Block for PCIe

AXI4Slave

AXI4Master

AXI4Slave

AXI4Master

pcie_tfc_*,cfg_fc_*

AXI4Master

AXI4Slave






• PCIe のコンプリーターコンプリーション (CC) インターフェイスを介して、ユーザーアプリケーションが CQ に応答を送り返すことができます。ユーザーアプリケーションはすべてのノンポステッドトランザクションをスプリットトランザクションとして処理できません。つまり、リクエストのコンプリーションを送信すると同時に新しいリクエストを CQ インターフェイスで受信し続けることができます。

• PCIe のリクエスターリクエスト (RQ) インターフェイスを介して、ユーザーアプリケーションがリンクに接続された遠隔の PCIe デバイスにリクエストを生成できます。

• PCIe のリクエスターコンプリーション (RC) インターフェイスを介して、統合ブロックがリンクから受け取ったコンプリーションを (PCIe リクエスターとしてユーザーアプリケーションリクエストに応えて) ユーザーアプリケーションに返します。

4 つの各インターフェイスは、『AMBA4® AXI4-Stream プロトコル仕様』 [参照 1] に基づいています。選択したレーンの数と PCIe の世代に応じて、これらインターフェイスの幅を 64、 128、または 256 バイトに設定可能で、ユーザークロック周波数は 62.5、 125、または 250MHz から選択できます。

表 3-5 に、統合ブロックでサポートされるリンク幅とリンクスピードが異なる場合のインターフェイス幅とユーザークロック周波数の有効な組み合わせを示します。 4 つの AXI4-Stream インターフェイスはすべて、いかなる場合においても同じ幅に設定されます。

さらに、統合ブロックには次のインターフェイスが含まれ、これらのインターフェイスを介してステータス情報がユーザーアプリケーションの PCIe のマスター側に通知されます。

• 現在使用可能な送信クレジットに関する情報を提供するリクエスターリクエスト (RQ) インターフェイスに接続されたフロー制御ステータスインターフェイス。これにより、ユーザーアプリケーションは使用可能なクレジットに基づいてリクエストをスケジューリングでき、リンクパートナーからのクレジット不足によってコントローラーの内部パイプラインがブロックされないようにします。

• ノンポステッドリクエストへの割り当てに使用可能なタグ数の情報を提供するリクエスターリクエスト (RQ) インターフェイスに接続されたタグ利用可能ステータスインターフェイス。これにより、クライアントは、PCIe IP にあるタグ管理ユニットがノンポステッドリクエストの送信に使用可能なタグをすべて使い切った場合にブロックされないようリクエストをスケジューリングできます。

• リンクから受信したメッセージ TLP の送信に使用するコンプリーターリクエスト (CQ) インターフェイスに接続された受信メッセージインターフェイス。ユーザーロジックに対して (AXI4 インターフェイスを介してユーザーアプリケーションにメッセージ全体を転送する代わりに) リンクからメッセージを受信したことをオプションで示すことができます。

表 3‐5:ユーザーインターフェイスのデータ幅とクロック周波数の設定

PCI Express 世代/最大リンクスピード

可能な最大リンク幅AXI4‐Stream

インターフェイス幅ユーザークロック

周波数 (MHz)

Gen1 (2.5GT/s)

x1 64 ビット 62.5、 125、または 250

x2 64 ビット 62.5、 125、または 250

x4 64 ビット 125 または 250

x864 ビット 250

128 ビット 125

Gen2 (5.0GT/s)

x1 64 ビット 62.5、 125、または 250

x2 64 ビット 125 または 250

x464 ビット 250

128 ビット 125

x8128 ビット 250

256 ビット 125






データアライメントオプション

トランザクション層パケット (TLP) は、ディスクリプターとして各 AXI4-Stream インターフェイスを介して転送され、その後 (TLP にペイロードがある場合は) ペイロードデータが続きます。ディスクリプターには、リクエストインターフェイスに 16 バイト幅に固定されたものと、コンプリーションインターフェイスに 12 バイト幅に固定されたものがあります。送信側 ( リンク方向へ) では、統合ブロックは、ユーザーアプリケーションによって提供されたパラメーターからの TLP ヘッダーをディスクリプターで構築します。受信側 (ユーザーインターフェイス方向へ) では、統合ブロックは受信した TOP のヘッダーからパラメーターを抽出し、ユーザーアプリケーションへ送信するためにディスクリプターを構成します。各 TLP は、 AXI4-Stream インターフェイスプロトコルの定義に従ってパケットとして転送されます。

ペイロードが現れる場合、各データパスのペイロードの初のバイトに揃えるために、2 つのオプションがあります。

1. Dword アライメントモード : このモードでは、ペイロードが存在する場合は必ずディスクリプターバイトの後に次の Dword 位置にあるペイロードバイトが続きます。

2. アドレスアライメントモード : このモードでは、ペイロードはデータパス上の任意のバイト位置で開始できます。統合ブロックからユーザーアプリケーションへデータが転送される場合、初のバイト位置は次のように判断されます。

n = A mod w

A は、ディスクリプターに指定されたメモリまたは I/O アドレス (メッセージおよびコンフィギュレーションリクエストの場合、このアドレスは 0 として見なされる ) となり、 w は、コンフィギュレーションされたデータバス幅 (バイト ) となります。ディスクリプターの終わりとペイロードの初のバイトの開始との間にギャップがある場合、 NULL バイトで埋められます。

統合ブロックからユーザーアプリケーションへのデータ転送の場合、データブロックが送信されるユーザーメモリ内の開始アドレスに基づいてデータアライメントが判断されます。ユーザーアプリケーションから統合ブロックに転送されるデータについては、アドレスアライメントモードを使用するとき、ユーザーアプリケーションは明示的に tuser サイドバンド信号を用いて統合ブロックに初のバイトの位置を通知する必要があります。

アドレスアライメントモードの場合、ペイロードとディスクリプターは重複できません。つまり、トランスミッターはディスクリプターを転送した後ペイロードの転送に着手するため新しいビートを開始します。トランスミッターは、ディスクリプターの後のバイトとペイロードの初のバイト間にあるギャップを NULL バイトで埋めます。

Vivado IP カタログは、 4 つのインターフェイスすべてに対してデータアライメントオプションをグローバルに適用します。ただし、上級ユーザーは 4 つの AXI4-Stream インターフェイスそれぞれに対してアライメントモードを個別に選択できます。これは、対応するアライメントモードパラメーターを設定することで可能です。アドレスアライメントの詳細と図の例は、「コンプリーターインターフェイス」を参照してください。

Gen3 (8.0GT/s)

x1 64 ビット 125 または 250

x264 ビット 250

128 ビット 125

x4128 ビット 250

256 ビット 125

x8 256 ビット 250

注記:1. -1LV スピードグレードで AXI4-Stream インターフェイス幅を 64 ビットに選択した場合、 x8 以外の設定ではユーザークロック

周波数 250MHz はサポートされません。

表 3‐5:ユーザーインターフェイスのデータ幅とクロック周波数の設定 (続き)

PCI Express 世代/最大リンクスピード

可能な最大リンク幅AXI4‐Stream

インターフェイス幅ユーザークロック

周波数 (MHz)






CQ、 CC、および RQ インターフェイスのストラドルオプション

CQ、 CC および RQ インターフェイスにはストラドルオプションが備わっているため、インターフェイスを介して大 2 つの TLP を同じビートで転送できます。これにより、 TLP がビートの前半で終了する場合と同様に、小規模

な TLP についてもスループットが改善します。ストラドルは、 Vivado IDE でコアコンフィギュレーションで各インターフェイスに対して個別に有効にできます。ストラドルオプションは、 Dword アライメントモードとの併用でのみ使用できます。

RC インターフェイスのストラドルオプション

RC インターフェイスは、インターフェイスを介して大 4 つの TLP を同じビートで転送可能にするストラドルオプションをサポートしています。このオプションは、 Vivado IDE でコアコンフィギュレーション中に有効にできます。有効の場合、コアは 0、 16、 32、または 48 バイトレーンで新しいコンプリーション TLP を開始できます。したがって、このオプションが有効の場合、コアは AXI バス上の同じビートで 4 つのコンプリーション TLP を送信できます。ただし、いずれも 1 Dword またはそれ以下のペイロードしかないことが条件です。ストラドルオプションは、RC インターフェイスが Dword アライメントモードでコンフィギュレーションされている場合にのみ使用できます。

リクエスターコンプリーション (RC) インターフェイスを 256 ビット幅に設定した場合で、インターフェイスのビートごとに開始できるまたは終了できる TLP の数が大で 1 つの場合、 TLP のタイプおよびペイロードサイズによってはインターフェイスの利用効率が著しく低下することがあります。 RC インターフェイスの利用効率が低いと、Infinite Receiver Credits がアドバタイズされた場合にコンプリーション FIFO がオーバーフローすることがあります。次に示すいずれかの措置を行う必要があります。

• 受信した合計コンプリーションを 64 未満に抑え、指定した FIFO サイズ内に抑えるために、未処理のノンポステッドリクエストの数を制限します。

• RC インターフェイスストラドルオプションを使用します。このオプションを使用した場合の波形は、図 3-70 を参照してください。

ストラドルオプションは、 256 ビット幅の RC インターフェイスでのみ利用可能で、 Vivado IP カタログで有効にします。 IP カタログでこのオプションを有効にする手順は、第 4 章「デザインフローの手順」を参照してください。このオプションを有効にした場合、統合ブロックは同じビートのバイトレーン 15 (またはそれ以前のバイトレーン) で前の TLP が終了すると、バイトレーン 16 で新しいコンプリーション TLP を開始できます。したがって、このオプションが有効の場合、統合ブロックは RC インターフェイスでは同じビートで複数のコンプリーション TLP を送信できます。ただし、いずれも 2 Dword 以上のペイロードがないことが条件です。

ストラドルオプションは、インターフェイス幅が 256 ビットに設定されており、 RC インターフェイスが Dword アライメントモードに設定されている場合のみ利用可能です。

表 3-6 に、インターフェイス幅、アドレッシングモードおよびストラドルオプションの有効な組み合わせを示します。

表 3‐6: インターフェイス幅、アライメントモードおよびストラドルオプションの有効な組み合わせ

インターフェイス幅アライメントモードストラドルオプション

説明

64 ビット Dword アライメント N/A 64 ビット、 Dword アライメント

64 ビットアドレスアライメント N/A 64 ビット、アドレスアライメント

128 ビット Dword アライメント N/A 128 ビット、 Dword アライメント


256 ビット Dword アライメント無効256 ビット、 Dword アライメント、ストラドル無効

256 ビット Dword アライメント有効256 ビット、 Dword アライメント、ストラドル有効 ( リクエスターコンプリーションインターフェイスでのみ可)







受信トランザクションの順序

コアの受信側には、リンクから受信してコンプリーターリクエストインターフェイスとリクエスターコンプリーションインターフェイスに送信される TLP が PCI Express トランザクション順序の制約に違反しないようにするロジックが含まれています。統合ブロックによる順序付けは、次の重要な規則に基づいています。

• ポステッドリクエストはコンプリーターリクエスト (CQ) インターフェイスでノンポステッドリクエストを追い越すことが求められます。この機能を有効にするために、統合ブロックはフロー制御メカニズムを CQ インターフェイスにインプリメントします。このインターフェイスを介して、ユーザーロジックはポステッドリクエストに影響を及ぼすことなくノンポステッドリクエストのフローを制御できます。ノンポステッドリクエストを受信するためのバッファーに空きがあると、ユーザーロジックは、 pcie_cq_np_req[0] 信号をアサートします。

利用可能なクレジットが 0 ではない場合にのみ、統合ブロックはノンポステッドリクエストをユーザーアプリケーションに送信します。クレジット数が不足しているためノンポステッドリクエストの送信が中断されている間、統合ブロックはポステッドリクエストを送信し続けます。ノンポステッドリクエストの送信に対してクレジットメカニズムによってバックプレッシャーが適用されない場合、統合ブロックはリンクから受信した同じ順序でポステッドリクエストおよびノンポステッドリクエストを送信します。ノンポステッドリクエストのフロー制御については、 133 ページの「ノンポステッドリクエストの選択的フロー制御」を参照してください。

• PCIe の順序付けでは、次のケースを除き、コンプリーション TLP はポステッドリクエストを越えて送信できないことが要件となっています。

° 緩和型順序付け (Relaxed Ordering) 属性ビットセットを使用するコンプリーション TLP は、ポステッドリクエストを追い越すことができる。

° コンプリーター ID がポステッドリクエスター ID と異なる場合、 ID ベースの順序付けビットセットを使用するコンプリーション TLP はポステッドリクエストを追い越すことができる。

上記の 2 つのルールのうち 1 つが適用されない限り、前に到着したすべてのポステッド TLP の転送が完全に完了するまで、統合ブロックはリクエスターコンプリーション (RC) インターフェイスでリンクから受信したコンプリーション TLP の転送を開始しません。

TLP が完全にユーザーインターフェイスに転送されたら、ユーザーアプリケーションは順序の制約を必要に応じて強化する必要があります。

表 3‐7:受信順序の規則

行パスポステッドノンポステッドコンプリーション

ポステッドなしありあり

ノンポステッドなしなしあり

コンプリーション

a) なし

b) あり (緩和されている順序付け)

c) あり (ID ベースの順序付け)

ありなし






送信トランザクションの順序

送信側では、統合ブロックはリクエスターリクエスト (RQ) インターフェイスとコンプリーターコンプリーション (CC) インターフェイスで TLP を受信します。統合ブロックは、これらの各インターフェイスから受信したトランザクションの順序を変更しません。リクエスター側のリクエストとコンプリーター側のコンプリーションが 1 つのトラフィックストリームに多重化された後、統合ブロックの転送パイプラインでこれらがどのように順序付けされるのか予測するのは難しくなります。コンプリーション TLP がリクエストに対して順序付けを維持しなければならない場合、ユーザーロジックは、 CC インターフェイスから送信されるコンプリーションに対して厳密な順序付けを維持する必要があるリクエストに 4 ビットのシーケンス番号を提供できます。これには、 s_axis_rq_tuser バス内の seq_num[3:0] 入力を使用します。ユーザーアプリケーションから新しいコンプリーション TLP を渡すことができなくなる送信パイプライン内の地点にリクエスト TLP が到達すると、統合ブロックはシーケンス番号を pcie_rq_seq_num[3:0] 出力に提供し、 pcie_rq_seq_num_vld をアサートします。このメカニズムを次の状況で使用すると、 TLP 順序を維持できます。

• ユーザーロジックでは、リクエスト TLP とその後に続くコンプリーション TLP 間の順序付けを維持することが求められます。この場合、ターゲットのコンプリーションインターフェイスでコンプリーション TLP の転送を開始する前に、ユーザーロジックは pcie_rq_seq_num[3:0] 出力にリクエスターリクエストのシーケンス番号が現れるのを待機する必要があります。

• ユーザーロジックでは、リクエスト TLP と、 MSI メッセージインターフェイスを介して提示される MSI/MSI-X TLP 間で順序付けを維持することが求められます。この場合、 MSI メッセージインターフェイスで MSI または MSI-X を提示する前に、ユーザーロジックは pcie_rq_seq_num[3:0] 出力にリクエスターリクエストのシーケンス番号が現れるのを待機する必要があります。

コンプリーターインターフェイス

このインターフェイスは、 AXI4-Stream プロトコルに基づいて、 PCIe リンクから受信したトランザクション (メモリ、 I/O の読み出し /書き込み、メッセージ、アトミック操作) をコンプリーターリクエスト (CQ) インターフェイスのトランザクションにマップします。コンプリーターインターフェイスは、各方向のデータ転送にそれぞれが用いられる 2 つの個別のインターフェイスで構成されます。各インターフェイスは AXI4-Stream プロトコルに基づき、64、 128、または 256 ビット幅に設定できます。 CQ インターフェイスは、 (関連するペイロードデータを含む) リクエストをユーザーアプリケーションに転送するために用いられ、コンプリーターコンプリーション (CC) インターフェイスはコンプリーションデータ (ノンポステッドリクエスト向け) をユーザーアプリケーションに送信してからリンクに転送するために用いられます。これら 2 つのインターフェイスは独立して動作します。つまり、統合ブロックは、前回のリクエストのコンプリーションを受信すると同時に CQ インターフェイスを介して新しいリクエストを転送できます。

コンプリーターリクエストインターフェイスの動作

図 3-18 に、コアのコンプリーターリクエストインターフェイスに関連する信号を示します。コアは、このインターフェイスを介して各 TLP を AXI4-Stream パケットとして送信します。このパケットは 128 ビットディスクリプターから始まり、 TLP にペイロードが含まれる場合はその後をデータが続きます。






コンプリーターリクエストインターフェイスは、 2 つのデータアライメントモードをサポートします。 Dword アライメントモードでは、有効なデータの初のバイトが n = (16 + A mod 4) mod w から求められるレーンに現れます。この数式の説明を次に示します。

• A は、転送されるデータブロックのバイト単位の開始アドレスです。

• w は、インターフェイスのバイト幅です。

アドレスアライメントモードでは、データは必ず、ディスクリプターが終了してから新しいビートで開始します。その初の有効なバイトは n = A mod w から求められるレーンにあります (w はインターフェイスのバイト幅)。メモリ、 I/O、およびアトミック操作の各リクエストでは、アドレス A はリクエストに含まれるアドレスです。メッセージの場合、ペイロードのアライメントを判断する目的でアドレスは常に 0 を取ります。


図 3‐18: コンプリーターリクエストインターフェイスの信号

Integrated Block for PCIe Client Application

PCIe CompleterRequest Interface

AXI4-StreamSlave

PCIeCompleter-Side

Interface

m_axis_cq_tdata[255:0]m_axis_cq_valid

m_axis_cq_tready

m_axis_cq_tkeep[7:0]

m_axis_cq_tlast

pcie_cq_np_req[0]

pcie_cq_np_req_count[5:0]

AXI4-StreamMaster

sop

first_be[3:0]

last_be[3:0]

byte_en[31:0]

discontinue

tph_present

tph_type[1:0]

tph_st_tag[7:0]

m_axis_cq_tuser[84:0]

parity[31:0]






コンプリーターリクエストディスクリプターのフォーマット

統合ブロックは、 CQ インターフェイスを介してリンクから受信した各リクエスト TLP を独立した AXI4-Stream パケットとして転送します。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 16 バイト長となり、リクエストパケットの初の 16 バイトで送信されます。ディスクリプターは、 64 ビットインターフェイスでは初の 2 サイクル間で送信され、 128 ビットまたは 256 ビットの場合は初のサイクルで送信されます。

図 3-19、図 3-20、図 3-21、および図 3-22 に、ディスクリプターのフォーマットをリクエストタイプ別に示しています。図 3-19 に示すフォーマットは、転送されているリクエスト TLP がメモリ読み出し /書き込みリクエスト、 I/O 読み出し /書き込みリクエスト、またはアトミック操作リクエストのときに適用されます。図 3-20 に示すフォーマットは、ベンダー定義メッセージ (タイプ 0 またはタイプ 1) 専用です。図 3-21 に示すフォーマットは、すべての ATS メッセージ (Invalid Request、 Invalid Completion、 Page Request、 PRG Response) に使用されます。その他のメッセージのディクスリプターについては、図 3-22 に示すフォーマットとなります。


図 3‐19: メモリリクエスト、 I/O リクエスト、アトミック操作リクエストのコンプリーターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

Address [63:2]

Address Type (AT)

01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

Dword Count01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

TagTC01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 3

Attr

Req Type

96 64

32

BAR Aperture

Bus Device/Function

Requester IDTarget Function

127

63 0

X12217

R R

BAR ID


図 3‐20:ベンダー定義メッセージのコンプリーターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 396 64

Msg Code

Vendor - Defined Header BytesDestination ID

Bus Device/FunctionVendor ID

TL HeaderByte 15

R Dword CountTag

MessageRouting

TCAttr R

Req Type

Bus Device/FunctionRequester ID

03263

127

TL HeaderByte 14

TL HeaderByte 13

TL HeaderByte 12

X12219

R R






表 3-8 に、コンプリーターリクエストディスクリプターの個別フィールドを示します。


図 3‐21: ATS メッセージのコンプリーターリクエストディスクリプタフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 3

96 64

32

Msg Code

TL Header Bytes 8-15

TL HeaderByte 15

R Dword CountTag

MessageRouting

TCAttr R

Req Type


127

63 0

TL HeaderByte 14

TL HeaderByte 13

TL HeaderByte 12

TL HeaderByte 11

TL HeaderByte 10

TL HeaderByte 9

TL HeaderByte 8

X12216

RR


図 3‐22: その他メッセージのコンプリーターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

01234567

+4

01234567

+5

01234567

+6

01234567

+7

Dword Count01234567

+8

01234567

+9

01234567

+10

01234567

+11

Tag01234567

+12

01234567

+13

01234567

+14

01234567

+15

Req Type

96 64

32

RMsg CodeMessageRouting

TCAttr R

OBFF Code (for OBFF message); Reserved (for others)

No-Snoop Latency (for LTR message);

Reserved (for others)

Snoop Latency (for LTR message);


R

R Bus Device/FunctionRequester ID

0

127

63

DW + 0DW + 1

DW + 2DW + 3

X12218

表 3‐8: コンプリーターリクエストディスクリプターのフィールド

ビットインデックスフィールド名説明

1:0Address Type

(アドレスタイプ)

このフィールドは、メモリトランザクションおよびアトミック操作専用に定義されます。リクエストの TL ヘッダーから抽出された AT ビットが含まれます。

00: リクエスト内のアドレスは変換されない

01: トランザクションは変換リクエスト

10: リクエスト内のアドレスは変換される

11: 予約






63:2 Address (アドレス)

このフィールドは、メモリ、 I/O、およびアトミック操作の各リクエストに適用されます。 TLP ヘッダーからのアドレスを提供します。リクエストで指定された初の Dword のアドレスです。m_axis_cq_tuser からの First_BE ビットを使用してバイト単位のアドレスを判断する必要があります。

トランザクションが 32 ビットアドレスを指定する場合、このフィールドのビット [63:32] は 0 になります。

74:64Dword Count

(Dword カウント )

これらの 11 ビットは、読み出しまたは書き込みの対象となっているブロックのサイズ (メッセージの場合は、メッセージペイロードのサイズ) を示します (Dword 単位)。範囲は 0 ～ 256 Dword です。I/O アクセスの場合、 Dword カウントは常に 1 です。

メモリの読み出し /書き込みリクエストの長さが 0 の場合、Dword カウントは 1 になり、 First_BE ビットはすべて 0 にセットされます。

78:75Request Type

( リクエストタイプ)トランザクションタイプを特定します。トランザクションタイプとそれらのエンコードの詳細は、表 3-9 に示します。

95:80Requester ID

( リクエスター ID)

リクエストに関連する PCI リクエスター ID です。 RID のこれまでの解釈で、これらの 16 ビットは 8 ビットのバス番号 [95:88]、 5 ビットのデバイス番号 [87:83]、および 3 ビットのファンクション番号 [82:80] に分割されます。 ARI が有効のとき、ビット [95:88] は 8 ビットのバス番号を伝搬し、 [87:80] はファンクション番号を提供します。

リクエストがノンポステッドトランザクションの場合、ユーザーコンプリーターアプリケーションはこのフィールドを格納し、元の統合ブロックへコンプリーションデータを供給する必要があります。

103:96 Tag (タグ)

リクエストに関連する PCIe タグです。リクエストがノンポステッドトランザクションの場合、ユーザーロジックはこのフィールドを格納し、元の統合ブロックへコンプリーションデータを供給する必要があります。メモリの書き込みおよびメッセージの場合、このフィールドを無視しても問題ありません。

111:104Target Function (ターゲット

ファンクション)

このフィールドは、メモリ、 I/O、およびアトミック操作の各リクエスト専用に定義されます。リクエストがターゲットとしているファンクション番号を提供し、 BAR チェックで指定されます。ARI を使用する場合、このフィールドのすべての 8 ビットが有効です。使用しない場合は、ビット [106:104] のみが有効です。

PF/VF マップに対するターゲットファンクションの値を次に示します。

• 0: PF0

• 1: PF1

• 64: VF0

• 65: VF1

• 66: VF2

• 67: VF3

• 68: VF4

• 69: VF5

表 3‐8: コンプリーターリクエストディスクリプターのフィールド (続き)







114:112 BAR ID

このフィールドは、メモリ、 I/O、およびアトミック操作の各リクエスト専用に定義されます。リクエスト内のアドレス向けに一致した BAR 番号を提供します。

• 000: BAR 0 (VF の場合 VF-BAR 0)






• 110: 拡張 ROM アクセス

• 111: BAR チェックなし (ルートポートでのみ有効)

64 ビットトランザクションの場合、一致する 1 組の BAR の下位アドレスとして BAR 番号が提供されます (つまり 0、 2、または 4)。

120:115 BAR アパーチャ (空き部分)

この 6 ビットのフィールドは、メモリ、 I/O、およびアトミック操作の各リクエスト専用に定義されます。リクエストと一致する BAR のアパーチャ設定を提供します。この情報は、メモリまたは I/O 空間のアドレス指定で使用するビットを決定する際に有用です。たとえば、 12 という値は、一致する BAR のアパーチャが 4K であることを示します。したがって、ユーザーアプリケーションはアドレスのビット [63:12] を無視できます。

VF BAR の場合、この出力で提供される値は、 BAR で記録されている 1 つの VF が使用するメモリ空間に基づきます。

123:121 Transaction Class (TC)

リクエストに関連する PCIe トランザクションクラス (TC) です。リクエストがノンポステッドトランザクションの場合、ユーザーコンプリーターアプリケーションはこのフィールドを格納し、元の統合ブロックへコンプリーションデータを供給する必要があります。

126:124 Attributes (属性)

これらのビットは、リクエストに関連する Attribute ビットの設定を提供します。ビット 124 は No Snoop ビットで、ビット 125 は Relaxed Ordering ビットです。ビット 126 は ID-Based Ordering ビットで、メモリリクエストとメッセージ専用にセットできます。

リクエストがノンポステッドトランザクションの場合、ユーザーコンプリーターアプリケーションはこのフィールドを格納し、元の統合ブロックへコンプリーションデータを供給する必要があります。

15:0Snoop Latency

(スヌープレイテンシ)

このフィールドは LTR メッセージ専用に定義されます。メッセージの TLP ヘッダーにある 16 ビットの Snoop Latency フィールドの値を提供します。

31:16No-Snoop Latency (ノースヌープレイテンシ)

このフィールドは LTR メッセージ専用に定義されます。メッセージの TLP ヘッダーにある 16 ビットの No-Snoop Latency フィールドの値を提供します。








35:32 OBFF コード

このフィールドは OBFF メッセージ専用に定義されます。 OBFF コードフィールドは、さまざまな OBFF ケースを識別するために使用されます。

• 1111b: CPU アクティブ – バスマスタリングや割り込みなど、すべてのデバイスアクションに対してシステムが完全にアクティブである

• 0001b: OBFF – デバイスメモリの読み出し /書き込みバスマスターの動作で利用可能なシステムメモリパス

• 0000b: アイドル – システムがアイドル状態で、低電力ステート

その他すべてのコードは予約されています。

111:104 メッセージコード

このフィールドはすべてのメッセージ用に定義されます。TLP ヘッダーから抽出された 8 ビットのメッセージコードが含まれます。

サポート対象のメッセージコードの一覧は、『PCI Express Base Specification、rev. 3.0』 [参照 2] の「Appendix F」を参照してください。

114:112Message Routing

(メッセージルーティング)

このフィールドはすべてのメッセージ用に定義されます。これらのビットは、 TLP ヘッダーからの 3 ビットの配線フィールド r[2:0] を提供します。

15:0Destination ID

(デスティネーション ID)

このフィールドはベンダー定義メッセージにのみ適用されます。メッセージが ID によって配線される場合 (つまり、メッセージ配線フィールドが 010 バイナリ )、このフィールドはメッセージの Destination ID を提供します。

63:32

Vendor-Defined Header

(ベンダー定義のヘッダー )

このフィールドはベンダー定義メッセージにのみ適用されます。TLP ヘッダーの Dword 3 から抽出されたバイトが含まれます。

63:0ATS Header

(ATS ヘッダー )このフィールドは ATS メッセージにのみ適用可能です。 TLP ヘッダーの Dword 2 と Dword 3 から抽出されたバイトが含まれます。

表 3‐9: トランザクションタイプ

リクエストタイプ (バイナリ )

説明

0000 メモリ読み出しリクエスト

0001 メモリ書き込みリクエスト

0010 I/O 読み出しリクエスト

0011 I/O 書き込みリクエスト

0100 メモリのフェッチおよび追加リクエスト

0101 メモリの無条件スワップリクエスト

0110 メモリの比較およびスワップリクエスト

0111 読み出しリクエストのロック (レガシデバイスでのみ可能)

1000 タイプ 0 のコンフィギュレーション読み出しリクエスト ( リクエスター側のみ)

1001 タイプ 1 のコンフィギュレーション読み出しリクエスト ( リクエスター側のみ)

1010 タイプ 0 のコンフィギュレーション書き込みリクエスト ( リクエスター側のみ)

1011 タイプ 1 のコンフィギュレーション書き込みリクエスト ( リクエスター側のみ)

1100 ATS およびベンダー定義メッセージを除くすべてのメッセージ








コンプリーターを介すメモリ書き込み動作

図 3-23、図 3-24、および図 3-25 のタイミング図は、コンプリーターリクエスト (CQ) インターフェイスを介してリンクから受信したメモリ書き込み TLP の Dword アライメント転送を 64、 128、および 256 ビット別に示しています。図示する目的で、メモリに書き込まれるデータの開始 Dword アドレスは、 (m * 32 + 1) と仮定し、整数 m > 0 となります。サイズは n Dword と仮定し、 n = k * 32 + 29 (k > 0) となります。

Dword アライメントモードおよびアドレスアライメントの両モードでは、転送は 16 ディスクリプターバイトから始まり、その直後にペイロードバイトが続きます。 m_axis_cq_tvalid 信号は、パケットが送信される間アサートされたままになります。 m_axis_cq_tready をディアサートしてビートを適時延ばすことができます。AXI4-Stream インターフェイス信号 m_axis_cq_tkeep (各 Dword 位置に 1 つ) は、ディスクリプター、およびディスクリプターとペイロード間に挿入される NULL バイトを含む、パケットの有効な Dword を示します。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、 tkeep ビットは継続的に 1 にセットされます。パケットの転送中、インターフェイスの幅全体がパケットで埋められないときは、パケットの後のビートに限り tkeep ビットを 0 にできます。 m_axis_cq_tlast 信号は必ずパケットの後のビートでアサートされます。

CQ インターフェイスでは、 m_axis_cq_tuser バスに First Byte Enable ビットと Last Enable ビットも含まれます。これらのビットはパケットの初のビートで有効になり、ペイロードの初と後の Dword の有効バイトを指定します。

m_axi_cq_tuser バスは、ユーザーインターフェイスに関連するロジックを簡潔なものにするため、または追加の機能をサポートするために利用可能な情報信号をいくつか提供します。ディスクリプターがこのバス上にある場合、各パケットの初のビートで sop 信号がアサートされます。バイトイネーブル出力 byte_en[31:0] (各バイトレーンに 1 つ) はペイロードの有効バイトを示します。 byte_en のビットは有効なペイロードバイトが対応するレーンに存在する場合にのみアサートされます (つまり、ディスクリプターおよびパディングバイトに関してはディスクリプターとペイロード間にアサートされない)。ペイロードサイズが 2 Dword 以下の場合を除き、アサートされたバイトイネーブルビットはペイロードの開始から常に連続します。 1 Dword や 2 Dword の書き込みでは、バイトイネーブルは非連続にできます。その他の特殊なケースとして、 byte_en ビットがすべて 0 にセットされて統合ブロックが 1 Dword のペイロードを転送するときの、長さ 0 のメモリ書き込みが挙げられます。つまり、あらゆるケースでユーザーロジックは byte_en 信号を直接使用して、関連するバイトをメモリへ書き込むことができます。

Dword アライメントモードでは、ペイロードの初の有効バイトのアドレスに基づいてディスクリプターの後と初のペイロードバイト間に 0、 1、 2、または 3 バイト位置分のギャップが存在することがあります。ペイロード

にある初の有効バイトの実際の位置は、 m_axis_cq_tuser バスの first_be[3:0] または byte_en[31:0] のいずれかを用いて判断できます。

受信した TLB に Transaction Processing Hint が含まれる場合、統合ブロックは、 m_axis_cq_tuser バスの信号でヒント (TPH ステアリングタグおよびステアリングタグタイプ) に関連するパラメーターを転送します。

1101 ベンダー定義メッセージ

1110 ATS メッセージ

1111 予約

表 3‐9: トランザクションタイプ (続き)

リクエストタイプ (バイナリ )

説明







図 3‐23: コンプリーターリクエストインターフェイスでのメモリ書き込みトランザクション (Dword アライメントモード、 64 ビットインターフェイス)

user_clk

m_axis_cq_tdata[31:0]


m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast

(first_be) m_axis_cq_tuser[3:0]

(last_be) m_axis_cq_tuser[7:4]

(byte_en[3:0]) m_axis_cq_tuser[11:8]


(sop) m_axis_cq_tuser[40]

(discontinue) m_axis_cq_tuser[41]

DESC 0 DESC 2 DW 0 DW 0 DW 2 DW n-1

DESC 1 DESC 3 DW 1 DW 1 DW 3

0x3 0x3 0x3 0x1

FIRST BE

LAST BE

0 FIRST_BE FIRST_BE 0xF 0xF LAST_BE

0 0xF 0xF 0xF

X12358



user_clk





m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast









DESC 0 DW 0 DW 0 DW n-1

DESC 1 DW 1 DW 1

DESC 2 DW 2 DW 2

DESC 3 DW 3 DW 3

0xF 0xF 0xF 0x1

FIRST BE

LAST BE

0 FIRST_BE 0xF 0xF LAST_BE

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0








user_clk









m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast








(byte_en[23:20) m_axis_cq_tuser[31:28]






DESC 1 DW 5 DW 5

DESC 2 DW 6 DW 6

DESC 3 DW 7 DW 7

DW 0 DW 8 DW 8

DW 1 DW 9 DW 9

DW 2 DW 10 DW 10

DW 3 DW 11 DW 11

0xFF 0xFF 0xFF 0x01

FIRST BE

LAST BE

0 0xF 0xF 0xF LAST_BE

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

FIRST BE 0xF 0xF 0xF 0

0xF 0xF 0xF 0xF 0

0xF 0xF 0xF 0xF 0

0xF 0xF 0xF 0xF 0

X12360






図 3-26、図 3-27、および図 3-28 のタイミング図は、 CQ インターフェイスを介してリンクから受信したメモリ書き込み TLP のアドレスアライメント転送を 64、 128、および 256 ビット別に示しています。図示する目的で、メモリに書き込まれるデータの開始 Dword アドレスは、整数 m > 0 のとき (m × 32 + 1) と仮定しています。サイズは n Dword と仮定し、 n = k * 32 + 29 (k > 0) となります。

アドレスアライメントモードでは、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。ペイロードの初の有効バイトのアドレスに基づいて、ペイロードの初のバイトはどのバイトレーンにも出力できます。ディスクリプターとペイロード間のギャップにおいて keep 出力の m_axis_cq_tkeep はアクティブ High に保持されます。ペイロードにある初の有効バイトの実際の位置は、ディスクリプターにあるアドレスの LSB ( 下位ビット ) または m_axis_cq_tuser バスのバイトイネーブルビット byte_en[31:0] のいずれかを用いて判断できます。

2 Dword 以下の書き込みの場合、 byte_en にセットされている 1 はペイロードの開始から連続したものにできません。長さ 0 のメモリ書き込みの場合、ペイロードバイトに対して byte_en ビットがすべて 0 にセットされて統合ブロックが 1 Dword のペイロードを転送します。


図 3‐26: コンプリーターリクエストインターフェイスでのメモリ書き込みトランザクション (アドレスアライメントモード、 64 ビットインターフェイス)

user_clk



m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast







DESC 0 DESC 2 DW 1 DW n-2


0x3

FIRST BE

LAST BE

0xF 0xF


0 0

X12355








user_clk





m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast









DESC 0 DW 3 DW n-2

DESC 1 DW 0 DW 0 DW 4 DW n-1

DESC 2 DW 1 DW 1 DW 5


0xF 0xF 0xF 0x3

FIRST BE

LAST BE

0xF 0xF


0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0

X12356








user_clk









m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast








(byte_en[23:20) m_axis_cq_tuser[31:28]









DW 3 DW 11 DW 11 DW n-2

DW 4 DW 12 DW 12 DW n-1

DW 5 DW 13 DW 13

DW 6 DW 14 DW 14

0xFF 0xFF 0xFF 0x3F

FIRST BE

LAST BE

0xF 0xF 0xF

0 FIRST BE 0xF 0xF 0xF

0 0xF 0xF 0xF

0 0xF 0xF 0xF

0 0xF 0xF 0xF

0 0xF 0xF 0xF LAST BE

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0

X12357






コンプリーターメモリ読み出し

AXI4-Stream パケットに 16 バイトディスクリプターしか含まれない場合を除いて、メモリ読み出しリクエストはメモリ書き込みリクエストと同様にコンプリーターリクエストインターフェイス全体で転送されます。図 3-29、図 3-30、および図 3-31 のタイミング図は、コンプリーターリクエスト (CQ) インターフェイスを介してリンクから受信したメモリ読み出し TLP の転送を 64、 128、および 256 ビット別に示しています。パケットは、 64 ビットインターフェイスでは連続する 2 ビートを使用して転送されますが、128 ビットまたは 256 ビットインターフェイスでは 1 ビートで転送されます。 m_axis_cq_tvalid 信号は、パケットが送信される間アサートされたままになります。m_axis_cq_tready をディアサートしてビートを適時延ばすことができます。 m_axis_cq_tuser バスの sop 信号は、初のディスクリプターバイトがバスに存在する場合アサートされます。


図 3‐29: コンプリーターリクエストインターフェイスでのメモリ読み出しトランザクション (64 ビットインターフェイス)

user_clk



m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast






DESC 0 DESC 0 DESC 2


0x3 0x3

FIRST BE FIRST BE

LAST BE LAST BE

00








user_clk





m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast






DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

DESC 3 DESC 3

0xF 0xF

FIRST BE FIRST BE

LAST BE LAST BE

0






初の Dword と後の Dword の読み出しリクエストに関連するバイトイネーブルビットは、 m_axis_cq_tuser サイドバンドバスの統合ブロックで提供されます。これらのビットは初のディスクリプターバイトの転送中に有効になり、リクエストに関連するバイト単位の開始アドレスとバイトカウントを判断する目的で使用する必要があります。 1 Dword や 2 Dword の読み出しといった特殊なケースでは、バイトイネーブルは非連続にできます。それ以外では、バイトイネーブルは連続しています。 Dword カウントフィールドが 1 にセットされ、初のバイトイネーブルと後のバイトイネーブルが 0 にセットされた状態で、長さ 0 のメモリ読み出しが CQ インターフェイスで送信されます。

ユーザーアプリケーションは、コンプリーションを用いて各メモリ読み出しリクエストに応答する必要があります。読み出しによって要求されたデータは、 1 つのコンプリーションまたは複数のスプリットコンプリーションとして送信できます。これらのコンプリーションは統合ブロックのコンプリーターコンプリーション (CC) インターフェイスを介して送信する必要があります。 2 つの異なるリクエストに対応するコンプリーションは順序を問わず送信できますが、同じリクエストに対応するスプリットコンプリーションについては順序を追って送信する必要があります。CC インターフェイスの動作は、 134 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。



user_clk






m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast






DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

DESC 3 DESC 3

0x0F 0x0F

FIRST BE FIRST BE

LAST BE LAST BE

0 0

X12354






I/O 書き込み

CQ インターフェイスにおける I/O 書き込みリクエストの転送は、 1 Dword ペイロードでのメモリ書き込みリクエストと同様です。転送は 128 ビットディスクリプターから始まり、その後 1 Dword ペイロードが続きます。 Dword アライメントモードを使用する場合、ディスクリプターの直後に Dword ペイロードが続きます。アドレスアライメントモードを使用する場合、ディスクリプターの後に Dword ペイロードが新しいビートで供給され、データパスにおけるそのアライメントはディスクリプターのアドレスに基づきます。 m_axis_cq_tuser 内の First Byte Enable ビットはペイロードにおける有効なバイトを示します。バイトイネーブルビット byte_en もこの情報を提供します。

I/O 書き込みはノンポステッドトランザクションであるため、ユーザーロジックはこれに対してデータペイロードを含まないコンプリーションを用いて応答する必要があります。 I/O リクエストに対するコンプリーションは順序を問わず送信できます。 I/O 書き込みトランザクションに関連するエラーが発生した場合、コンプリーションディスクリプターにあるコンプリーションステータスフィールドに CA (コンプリーターの中断) または UR (サポートされないリクエスト ) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 134 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

I/O 読み出し

CQ インターフェイスにおける I/O 読み出しリクエストの転送はメモリ読み出しリクエストと同様で、そこにはディスクリプターしか含まれません。要求されたデータの長さは常に 1 Dword となり、 m_axis_cq_tuser 内の First Byte Enable ビットは読み出し対象の有効バイトを示します。

ユーザーロジックは、 1 Dword のコンプリーション (またはエラーの場合はデータを含まないコンプリーション) で I/O 読み出しリクエストに応答する必要があります。 2 つの異なる I/O 読み出しリクエストに対応するコンプリーションは順序を問わず送信できます。 I/O 読み出しトランザクションに関連するエラーが発生した場合、コンプリーションディスクリプターにあるコンプリーションステータスフィールドに CA (コンプリーターの中断) または UR (サポートされないリクエスト ) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 134 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

コンプリーターリクエストインターフェイスでのアトミック操作

コンプリーターリクエストインターフェイスにおけるアトミック操作リクエストの転送は、メモリ書き込みリクエストと同様です。アトミック操作のペイロードの範囲は、 1 Dword から 8 Dword までで、開始アドレスは必ず Dword 境界に揃えられます。転送は 128 ビットディスクリプターから始まり、その後ペイロードが続きます。 Dword アライメントモードを使用する場合、ディスクリプターの直後に初の Dword ペイロードが続きます。アドレスアライメントモードを使用する場合、ディスクリプターの後にペイロードが新しいビートで開始し、そのアライメントはディスクリプターのアドレスに基づきます。 m_axis_cq_tkeep 出力は、ペイロードの終わりを示します。また、m_axis_cq_tuser 内の byte_en 信号は、ペイロード内の有効バイトを示します。 m_axis_cq_tuser 内の First Byte Enable と Last Byte Enable ビットはアトミック操作に使用できません。

アトミック操作はノンポステッドトランザクションであるため、ユーザーロジックはこれに対して操作結果を含むコンプリーションを用いて応答する必要があります。操作に関連するエラーが発生した場合、コンプリーションディスクリプターにあるコンプリーションステータスフィールドにコンプリーターの中断 (CA) またはサポートされないリクエスト (UR) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 134 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

コンプリーターリクエストインターフェイスでのメッセージリクエスト

ペイロードが常に存在するわけではないことを除いて、 CQ インターフェイスにおけるメッセージの転送はメモリ書き込みリクエストと同様です。転送は 128 ビットディスクリプターから始まり、ペイロードがある場合はその後ペイロードが続きます。 Dword アライメントモードを使用する場合、ディスクリプターの直後にペイロードが続きます。アドレスアライメントモードを使用する場合、ディスクリプターの後にペイロードの初の Dword が新しいビートで供給され、バイトレーン 0 で必ず開始します。 m_axis_cq_tlast および m_axis_cq_tkeep 信号のステートからペイロードの終わりを判断できます。また、 m_axis_cq_tuser 内の byte_en 信号は、ペイロード内の有効バイトを示します。 m_axis_cq_tuser 内の First Byte Enable と Last Byte Enable ビットはメッセージトランザクションに使用できません。






転送の中断

関連するペイロードを含むリクエストの場合、転送されたペイロードにエラーがあると、統合ブロックは m_axis_cq_tuser バスの discontinue 信号をパケットの後のビートで (m_axis_cq_tlast と共に) アサートしてこのエラーを通知できます。これは、内部メモリからデータを読み出す間に統合ブロックが訂正不可能なエラーを検出したときに発生します。パケットの後のビートで discontinue 信号がアサートされたことを検出した場合、ユーザーアプリケーションはパケット全体を破棄する必要があります。これは、統合ブロックでは致命的エラーと認識されます。

ノンポステッドリクエストの選択的フロー制御

『PCI Express Base Specification』 [参照 2] では、ユーザーアプリケーションがノンポステッドトランザクションを受信できなくても、コンプリーターリクエストインターフェイスはこのトランザクションを提供し続けることが規定されています。この機能を有効にするために、統合ブロックはクレジットベースのフロー制御メカニズムを CQ インターフェイスにインプリメントします。このインターフェイスを介して、ユーザーロジックはポステッドリクエストに影響を及ぼすことなくノンポステッドリクエストのフローを制御できます。ノンポステッドリクエストを受信するためのバッファーに空きがあると、ユーザーロジックは、 pcie_cq_np_req[0] 信号をアサートします。利用可能なクレジットが 0 ではない場合にのみ、コアはノンポステッドリクエストを送信します。クレジット数が不足しているためノンポステッドリクエストの送信が中断されている間、統合ブロックはポステッドリクエストを送信し続けます。ノンポステッドリクエストの送信に対してクレジットメカニズムによってバックプレッシャーが適用されない場合、統合ブロックはリンクから受信した同じ順序でポステッドリクエストおよびノンポステッドリクエストを送信します。

統合ブロックは、コンプリーターリクエストインターフェイスでノンポステッドリクエストに利用可能なクレジットを追跡するための内部クレジットカウンターを備えています。次のアルゴリズムを使用して利用可能なクレジットの追跡を維持します。

• リセットでは、カウンターは 0 にセットされます。

• 統合ブロックのリセットが解除されたら、クロックサイクルごとにカウンターは次のような動作となります。

° pcie_cq_np_req[0] がアクティブ High で、ノンポステッドリクエストがこのサイクルで送信されない場合、クレジットカウントが 32 の飽和限界に達していなければ、 1 つずつインクリメントされます。

° pcie_cq_np_req[0] が Low で、ノンポステッドリクエストがこのサイクルで送信される場合、クレジットカウントがまだ 0 になっていなければ、 1 つずつデクリメントされます。

° 上記に該当しない場合、クレジットカウントの値は変わりません。

• クレジットカウントが 1 以上の場合、統合ブロックはノンポステッド TLP の送信を開始します。

ユーザーアプリケーションは、ノンポステッドリクエストを受信できる状態になるたびに pcie_cq_np_req[0] に 1 サイクルのパルスを送信するか、ノンポステッドリクエストに対する選択的なバックプレッシャーを実行する必要がない場合は永久的にアサートされた状態に維持します。クレジットカウントが常に 0 以外の場合、統合ブロックはリンクから受信した同じ順序でポステッドリクエストおよびノンポステッドリクエストを送信します。カウントが一定時間 0 の状態が続くと、ノンポステッドリクエストは統合ブロック FIFO に保管できます。その後、クレジットカウントが 0 以外になると、統合ブロックは既に送信されたポステッドリクエストよりも前に到達して保管していたノンポステッドリクエストを先に送信し、その後リンクから受信した順にリクエストを送信します。

pcie_cq_np_req[0] 信号のアサートおよびディアサートは、コンプリーターリクエストインターフェイス上のパケット送信と揃う必要はありません。

出力 (pcie_cq_np_req_count[5:0]) で現在のクレジットカウント値をモニタリングできます。カウンターは 32 が大です。内部パイプラインの遅延により、コアが pcie_cq_np_req[0] 入力でパルスを受信してから pcie_cq_np_req_count[5:0] 出力を更新するまでの間には数サイクルの遅延が生じます。このため、ユーザーアプリケーションにある程度のバッファー空間がある場合は、あらかじめクレジットを提供しておくと、クレジット不足でコアがノンポステッドリクエストを保持することがなくなります。






コンプリーターコンプリーションインターフェイスの動作

図 3-32 に、コアのコンプリーターコンプリーションインターフェイスに関連する信号を示します。コアは、このインターフェイスを介して各 TLP を AXI4-Stream パケットとして送信します。

コアは、コンプリーターコンプリーション (CC) インターフェイスを介して各 TLP を AXI4-Stream パケットとして送信します。パケットは 96 ビットディスクリプターから始まり、コンプリーションにペイロードが含まれる場合はその後をデータが続きます。

CC インターフェイスは、 2 つのデータアライメントモードをサポートします。 Dword アライメントモードの場合、有効なデータの初のバイトは、レーン n = (12 + A mod 4) mod w に現れる必要があります。この場合の A は、送信されるデータブロックのバイト単位の開始アドレス (ディスクリプターの下位アドレスフィールドで伝搬) で、 w は、インターフェイス幅 (8、 16、または 32) です。アドレスアライメントモードの場合、データはディスクリプターが終了した後の新規ビートで常に開始します。メモリまたは I/O の読み出しリクエストに対してコンプリーションペイロードを送信する場合、その初の有効バイトは、レーン n = A mod w に現れます。その他すべてのコンプリーションの場合、ペイロードはバイトレーン 0 に揃えられます。

コンプリーターコンプリーションディスクリプターのフォーマット

ユーザーアプリケーションは、統合ブロックの CC インターフェイスに独立した AXI4-Stream パケットとしてコンプリーターリクエストに対するコンプリーションデータを送信します。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 12 バイト長となり、コンプリーションパケットの初の 12 バイトで送信されます。ディスクリプターは、 64 ビットインターフェイスでは初の 2 サイクル間で送信され、 128 ビットまたは 256 ビットの場合は初のサイクルで送信されます。ユーザーアプリケーションが 1 つのリクエストのコンプリーションデータを複数のスプリットコンプリーションに分割する場合は、個別にディスクリプターを備えた AXI4-Stream パケットとして各スプリットコンプリーションを送信する必要があります。

コンプリーターコンプリーションディスクリプターのフォーマットは、図 3-33 を参照してください。コンプリーターリクエストディスクリプターの各フィールドの詳細は、表 3-10 で説明しています。


図 3‐32: コンプリーターコンプリーションインターフェイスの信号

Integrated Block for PCIe ClientApplication

PCIe CompleterCompletion Interface AXI4-Stream

Master

s_axis_cc_tdata[255:0]

s_axis_cc_tvalid

s_axis_cc_tready

s_axis_cc_tlast

parity[31:0]

s_axis_cc_tuser

AXI4-StreamSlave

PCIe Completer-Side

Interface

discontinue







図 3‐33: コンプリーターコンプリーションディスクリプターのフォーマット

R01234567

+001234567

+101234567

+201234567

+3

DW + 0

Byte CountDword Count01234567

+401234567

+501234567

+601234567

+7

DW + 1

TagTC01234567

+801234567

+901234567

+1001234567

+11

DW + 2

Device/FunctionAttr

Poisoned Completion

64

32

Address [6:0]

Completion Status

Bus

Completer ID

Completer ID EnableForce ECRC

RBus Device/FunctionRequester ID

95

63 0

Locked ReadCompletion

R RAT

X12215

表 3‐10: コンプリーターコンプリーションディスクリプターのフィールド


フィールド名説明

6:0Lower Address

(下位アドレス)

メモリ読み出しのコンプリーションの場合、このフィールドは、送信されるメモリブロックのバイト単位の開始アドレスの下位 7 ビットに設定される必要があります。初の (または唯一の) コンプリーションの場合、コンプリーターは、次に示すようにリクエストの初の Dword に対応するバイトイネーブルで構成される、バイト単位のアドレスの 2 ビットに連結されたリクエストのアドレスの下位 5 ビットからこのフィールドを生成できます。

後続のコンプリーションの場合、下位アドレスフィールドは、 64 バイトの RCB (Read Completion Boundary) 値を用いてルートコンプレックスによって生成されたコンプリーションを除いて、常に 0 になります。この場合、下位アドレスフィールドの下位 6 ビットが必ず 0 になり、下位アドレスフィールドの上位ビットが 64 バイトデータペイロードのアライメントに応じてトグルします。

その他のコンプリーションの場合、この下位アドレスはすべて 0 にセットされる必要があります。

9:8Address Type


このフィールドは、メモリトランザクションおよびアトミック操作のコンプリーション用に定義されます。これらのコンプリーションの場合、対応するリクエストのディスクリプターの AT ビットをユーザーがこのフィールドへコピーする必要があります。その他のコンプリーションの場合、このフィールドは 0 にセットされる必要があります。

first_be[3:0] 下位アドレス [1:0]

4'b0000 2'b00

4'bxxx1 2'b00

4'bxx10 2'b01

4'bx100 2'b10

4'b1000 2'b11






28:16Byte Count

(バイトカウント )

これらの 13 ビットには、0 ～ 4,096 バイトの範囲の値が含まれます。シングルコンプリーションを使用してメモリ読み出しリクエストが完了する場合、このバイトカウント値がペイロードサイズをバイト単位で示します。 I/O の読み出しコンプリーションや I/O の書き込みコンプリーションの場合、このフィールドは 4 にセットされる必要があります。長さ 0 のメモリ読み出しに対するコンプリーションを送信している間、バイトカウント値は 1 にセットされる必要があり、ダミーのペイロードとして 1 Dword がディスクリプターの後に送信される必要があります。

各メモリ読み出しコンプリーションでは、このバイトカウントフィールドがリクエストを完了するのに必要となる残りのバイト数を示します (コンプリーションで返ってきたバイト数を含む)。

複数のコンプリーションを使用してメモリ読み出しリクエストが完了する場合、各コンプリーションのこのバイトカウント値は、先行するコンプリーションが示す値から先行するコンプリーションで返ってきたバイト数を引いた値となります。メモリ読み出しリクエストを完了するのに必要な合計バイト数の計算式は、138 ページの表 3-11 を参照してください。

29

Locked Read Completion

(ロックされた読み出しコンプリーション)

コンプリーションが Locked Read (ロックされた読み出し ) リクエストに応答する場合、このビットをセットする必要があります。その他のコンプリーションの場合、このフィールドは 0 にセットされる必要があります。

42:32Dword Count


これらの 11 ビットは、現在のパケットのペイロードサイズを示します (Dword)。範囲は 0 ～ 1000 Dword です。このフィールドは、 I/O 読み出しのコンプリーションには 1 にセットされ、 I/O 書き込みのコンプリーションには 1 にセットされる必要があります。長さ 0 のメモリ読み出しに対してコンプリーションを送信している間、この Dword カウントフィールドは 1 にセットされている必要があります。 UR または CA コンプリーションを送信している間、この Dword カウントフィールドは 0 にセットされている必要があります。その他の場合、この Dword カウントは、その時点のパケットのペイロードの実際の Dword 数に対応する必要があります。

45:43

Completion Status (コンプリーションステータス)

これらのビットは、送信されるコンプリーションのタイプに基づいてセットされる必要があります。有効な設定は次のとおりです。

• 000: トランザクションが正常に完了

• 001: サポートされないリクエスト (UR)

• 100: コンプリーターの中断 (CA)

46

Poisoned Completion

(ポイズンコンプリーション)

このビットは、送信されるコンプリーション TLP にポイズニングを適用する場合に使用できます。ユーザーアプリケーションがディスクリプターの後に続くデータブロック内にエラーを検出し、 PCI Express のデータポイズニング機能を使用してこのエラー情報を伝える場合以外は、このビットはすべてのコンプリーションで 0 にセットする必要があります。

63:48Requester ID

( リクエスター ID)

リクエストに関連する PCI リクエスター ID です ( リクエストからコピー )。

71:64 Tag (タグ) リクエストに関連する PCIe タグです ( リクエストからコピー )。

表 3‐10: コンプリーターコンプリーションディスクリプターのフィールド (続き)








79:72

Target Function/Device Number

(ターゲットファンクション/デバイス番号)

コンプリーターファンクションのファンクション/デバイス番号です。

エンドポイントモード :

• ARI が有効な場合:

° ビット [87:80] をコンプリーターファンクション番号に設定する必要があります。

• ARI が無効な場合:


° ビット [87:83] は使用しません。

スイッチで使用する場合のアップストリームポート (IP 内でエンドポイントモードを選択):





° コンプリーションの送信元がスイッチ自身の場合、ビット [87:83] は使用しません。スイッチがコンプリーションを中継している場合 (すなわちコンプリーターがスイッチ外部にある場合)、これらのビットは、コンプリーション送信元のコンプリーターデバイス番号に設定する必要があります。ディスクリプターの Completer ID Enable ビットと組み合わせて使用します。

ルートポートモード (ダウンストリームポート ):





° ビット [87:83] をコンプリーターデバイス番号に設定する必要があります。ディスクリプターの Completer ID Enable ビットと組み合わせて使用します。

87:80

Completer Bus Number

(コンプリーターバス番号)

コンプリーターファンクションに関連するバス番号です。


• 使用しない


• コンプリーションの送信元がスイッチ自身の場合、使用しません。スイッチがコンプリーションを中継している場合 (すなわちコンプリーターがスイッチ外部にある場合)、これらのビットは、コンプリーション送信元のコンプリーターバス番号に設定する必要があります。ディスクリプターの Completer ID Enable ビットと組み合わせて使用します。


• コンプリーターバス番号に設定する必要があります。ディスクリプターの Completer ID Enable ビットと組み合わせて使用します。









88

Completer ID Enable

(コンプリーター ID イネーブル)

1’b1: クライアントがディスクリプターで指定したバス番号、デバイス番号、およびファンクション番号を TLP ヘッダーのコンプリーター ID フィールドに格納します。

1’b0: IP は受信したコンフィギュレーションリクエストから取り込んだバス番号とデバイス番号、およびクライアントがディスクリプターで指定したファンクション番号を TLP ヘッダーのコンプリーター ID フィールドに格納します。


• 必ず 1’b0 に設定します。


• コンプリーションの送信元がスイッチ自身の場合、 1’b0 に設定します。

• スイッチがコンプリーションを中継している場合 (すなわちコンプリーターがスイッチ外部にある場合)、 1’b1 に設定します。 ARI が無効な場合は、コンプリーターバス番号ビット [95:88] およびコンプリーターファンクション/デバイス番号ビット [87:83] と組み合わせて使用します。

ルートポートモード :

• 必ず 1’b1 に設定します。 ARI が無効な場合は、コンプリーターバス番号ビット [95:88] およびコンプリーターファンクション/デバイス番号ビット [87:83] と組み合わせて使用します。

91:89Transaction Class (TC)

リクエストに関連する PCIe トランザクションクラス (TC) です。ユーザーアプリケーションは、関連するリクエストのディスクリプターの TC フィールドからこの値をコピーする必要があります。

94:92 Attributes (属性)リクエストに関連する PCIe 属性です ( リクエストからコピー )。ビット 92 は No Snoop ビット、ビット 93 は Relaxed Ordering ビット、ビット 94 は ID-Based Ordering ビットです。

95 Force ECRC強制的に ECRC を挿入します。このビットを 1 にセットすると、コンプリーションを送信するファンクションで ECRC 機能が有効に設定されていない場合でも、統合ブロックがコンプリーション TLP に ECRC を含む TLP Digest を追加します。

表 3‐11: first_be[3:0]、 last_be[3:0]、および Dword Count[10:0] からのバイトカウント計算

first_be[3:0] last_be[3:0] 合計バイトカウント

1xx1 0 4

01x1 0 3

1x10 0 3

0011 0 2

0110 0 2

1100 0 2

0001 0 1

0010 0 1

0100 0 1

1000 0 1

0000 0 1

xxx1 1xxx Dword_count × 4









Successful Completion (SC: 正常な完了) ステータスのコンプリーション転送

ユーザーアプリケーションは、コンプリーターリクエストインターフェイスから受信したすべてのノンポステッドリクエストに対して、コアの CC インターフェイスにコンプリーションを返す必要があります。リクエストがエラーなしで完了すると、ユーザーアプリケーションは Successful Completion (SC) ステータスのコンプリーションを返します。これらのコンプリーションには、リクエストタイプによってペイロードが含まれる場合と含まれない場合があります。さらに、データブロックのサイズが設定した大ペイロードサイズを超える場合は、リクエストに対応するデータが複数のスプリットコンプリーションに分割されます。これは、必要に応じてユーザーロジックがデータブロックを複数のスプリットコンプリーションに分割します。ユーザーアプリケーションは、コンプリーターコンプリーションインターフィエスを介して各スプリットコンプリーションを 12 バイトのディスクリプターを含む AXI4-Stream パケットとして送信する必要があります。

このセクションのサンプルタイミングでは、送信されるデータブロックの開始 Dword (ディスクリプターの下位アドレスのビット [6:2] で伝搬) は (m * 8 + 1) と仮定されています (整数 m)。データブロックのサイズは n Dword と仮定し、 n = k * 32 + 28 (k > 0) となります。

CC インターフェイスは、 2 つのデータアライメントモード (Dword アライメントモード、アドレスアライメントモード ) をサポートします。図 3-34、図 3-35、および図 3-36 のタイミング図は、 CC インターフェイスを介すユーザーアプリケーションからの Dword アライメント転送を、インターフェイス幅 64、 128、および 256 ビット別に示しています。この場合、ペイロードの初の Dword がディスクリプターの直後で開始しています。データブロックが 4 バイトの倍数でない場合、またはペイロードの開始が Dword の境界に揃っていない場合は、ペイロードの開始が Dword の境界に揃うように、またペイロードが Dword の倍数値となるように、ユーザーアプリケーションは NULL を追加する必要があります。たとえば、データブロックがバイトアドレス 7 から開始し、サイズが 3 バイトの場合は、初のバイトの前に NULL バイトを 3 つ追加し、 2 Dword の長さにするためにブロックの終わりに NULL バイトを 2 つ追加する必要があります。また、不連続な読み出しの場合は、データブロック内のすべてのバイトが有効として返されるとは限りません。このような場合は、必要に応じて有効バイトの間にある隙間に NULL バイトを追加して、正しい位置にある有効なバイトを返す必要があります。インターフェイスには、ペイロード内の有効なバイトを示す信号がありません。これは、リクエスターがリクエスト内のバイトイネーブルを追跡してコンプリーションから無効なバイトを破棄する役割を果たすため、必要ありません。

xxx1 01xx (Dword_count × 4) -1

xxx1 001x (Dword_count × 4) -2

xxx1 0001 (Dword_count × 4) -3

xx10 1xxx (Dword_count × 4) -1

xx10 01xx (Dword_count × 4) -2

xx10 001x (Dword_count × 4) -3

xx10 0001 (Dword_count × 4) -4

x100 1xxx (Dword_count × 4) -2

x100 01xx (Dword_count × 4) -3

x100 001x (Dword_count × 4) -4

x100 0001 (Dword_count × 4) -5

1000 1xxx (Dword_count × 4) -3

1000 01xx (Dword_count × 4) -4

1000 001x (Dword_count × 4) -5

1000 0001 (Dword_count × 4) -6

表 3‐11: first_be[3:0]、 last_be[3:0]、および Dword Count[10:0] からのバイトカウント計算 (続き)

first_be[3:0] last_be[3:0] 合計バイトカウント






Dword アライメントモードでは、転送は 12 ディスクリプターバイトから始まり、その直後にペイロードバイトが続きます。ユーザーアプリケーションは、パケットが送信される間、 s_axis_cc_tvalid 信号をアサートしたままに保持する必要があります。パケット送信中に s_axis_cc_tvalid がディアサートされると、統合ブロックはこれをエラーとして処理し、リンク上の対応するコンプリーション TLP を無効にしてデータ破損を回避します。

またユーザーアプリケーションは、パケットの後のビートで s_axis_cc_tlast をアサートします。統合ブロックは、データの受信準備が整っていない場合に、任意のサイクルで s_axis_cc_tready をディアサートできます。統合ブロックが s_axis_cc_tready をディアサートしたクロックサイクル内では、ユーザーアプリケーションは CC インターフェイス上の値を変更できません。


図 3‐34: コンプリーターコンプリーションインターフェイスでの一般的なコンプリーションの転送 (Dword アライメントモード、 64 ビットインターフェイス)

user_clk



s_axis_cc_tvalid

s_axis_cc_tready

s_axis_cc_tkeep[1:0]

s_axis_cc_tlast

(discontinue) s_axis_cc_tuser[0]

DESC 0 DESC 2 DW 1 DW 1 DW n-1


0x3 0x3 0x3 0x1

X12349



user_clk





s_axis_cc_tvalid

s_axis_cc_tready


s_axis_cc_tlast





DW 0 DW 4 DW 8 DW 8

0xF 0xF 0xF 0x7

X12350






アドレスアライメントモードでは、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。メモリ読み出しのコンプリーションの場合、ペイロードの初の有効バイトのアドレスに基づいて、ペイロードの初のバイトはどのバイトレーンにも出力できます。その他すべてのコンプリーションの場合、ペイロードはバイトレーン 0 で開始する必要があります。

図 3-37、図 3-38、および図 3-39 のタイミング図は、コンプリーターコンプリーションインターフェイスを介すメモリ読み出しコンプリーションのアドレスアライメント転送を 64、 128、および 256 ビット別に示しています。図示することを目的として、送信されるデータブロックの開始 Dword アドレス (ディスクリプターの下位アドレスフィールドのビット [6:2] で伝搬) は (m × 8 +1 ) と仮定されています (整数 m)。データブロックのサイズは、 n Dword と仮定され、 n = k × 32 + 28 (k > 0) となります。



user_clk









s_axis_cc_tvalid

s_axis_cc_tready


s_axis_cc_tlast





DW 0 DW 8 DW 8 DW n-4


DW 2 DW 10 DW 10 DW n-2

DW 3 DW 11 DW 11 DW n-1

DW 4 DW 12 DW 12

0xFF 0xFF 0xFF 0x7F

X12351







図 3‐37: コンプリーターコンプリーションインターフェイスでの一般的なコンプリーションの転送 (アドレスアライメントモード、 64 ビットインターフェイス)

user_clk



s_axis_cc_tvalid

s_axis_cc_tready


s_axis_cc_tlast




0x3 0x3 0x3 0x1

X12346



user_clk





s_axis_cc_tvalid

s_axis_cc_tready


s_axis_cc_tlast





DW 2 DW 6 DW 6

0xF 0xF 0xF 0x1

X12347






コンプリーションの転送中断

ユーザーアプリケーションは、 s_axis_cc_tuser バスで discontinue 信号をアサートすることによって、ペイロード転送中にいつでもコンプリーターコンプリーションインターフェイス上のコンプリーショントランザクション転送を中断できます。統合ブロックがリンク上の対応する TLP を無効にしてデータ破損を回避します。

ユーザーアプリケーションは、転送されているコンプリーションに関連するペイロードが含まれている場合に、転送中の任意のタイミングでこの信号をアサートできます。また、エラーが示されたサイクルでパケットを早期に中断する (s_axis_cc_tlast をアサート )、またはペイロードのすべてのバイトが統合ブロックへ送信されるまで継続してから中断するのいずれかを選択できます。後者の場合、ユーザーアプリケーションがパケットの終了より前に discontinue 信号をディアサートした場合でも、統合ブロックはパケットのその後のサイクルでエラーをスティッキーとして処理します。

discontinue 信号は、 s_axis_cc_tvalid がアクティブ High の場合のみアサートされます。統合ブロックは、s_axis_cc_tvalid と s_axis_cc_tready が両方ともアサートされている場合にこの信号をサンプルします。したがって、 discontinue 信号がアサートされると、 s_axis_cc_tready がアサートされるまでディアサートできません。

統合ブロックがエンドポイントとしてコンフィギュレーションされる場合、 Advanced Error Reporting (AER) 機能を使用して訂正不可能な内部エラーとして、接続される先のルートコンプレックスに対して統合ブロックがエラーをレポートします。

エラーステータス (UA および CA) のコンプリーション

コンプリーターリクエストインターフェイスで受信したリクエストに対して UR (サポートされないリクエスト ) または CA (コンプリーション中断) で応答する場合、ユーザーアプリケーションは、図 3-33 に示すフォーマットで 3 Dword のコンプリーションディスクリプターを送信し、その後にコンプリーションを生成したリクエストの情報を含む 5 Dword を送信する必要があります。これらの 5 Dword は、統合ブロックが AER ヘッダーログレジスタにリクエストに関する情報を記録するのに不可欠です。



user_clk









s_axis_cc_tvalid

s_axis_cc_tready


s_axis_cc_tlast





DW 2 DW 10 DW 10 DW n-2

DW 3 DW 11 DW 11 DW n-1

DW 4 DW 12 DW 12

DW 5 DW 13 DW 13

DW 6 DW 14 DW 14

0xFF 0xFF 0xFF 0x1F

X12348






図 3-40 に、 UR または CA ステータスのコンプリーションを送信する際に転送される情報のシーケンスを示します。この情報は、合計 8 Dword の AXI4-Stream パケットとしてフォーマットされ、次のように組織化されます。

• 初の 3 Dword には、図 3-33 の形式のコンプリーションディスクリプターが含まれます。

• 4 番目の Dword には、リクエストからコピーされた m_axis_cq_tuser 内の次に示す信号のステータスが含まれます。

° m_axis_cq_tuser の First Byte Enable ビット (first_be[3:0])

° m_axis_cq_tuser の Last Byte Enable ビット (last_be[3:0])

° Transaction Processing Hint の情報を伝搬する信号: m_axis_cq_tuser の tph_present、tph_type[1:0]、および tph_st_tag[7:0]

• 統合ブロックから受信した 4 Dword のリクエストディスクリプター

パケット全体を送信するには、 64 ビットインターフェイスの場合は 4 サイクル、 128 ビットインターフェイスの場合は 2 サイクル、 256 ビットインターフェイスの場合は 1 サイクル必要です。パケットの転送方法は、 Dword アライメントモードとアドレスアライメントモードのいずれの場合も同じで、 Dword を 1 つにまとめて送信します。ユーザーアプリケーションは、パケットが送信される間、 s_axis_cc_tvalid 信号をアサートしたままに保持する必要があります。また、パケットの後のビートでは s_axis_cc_tlast をアサートする必要があります。統合ブロックは、データの受信準備が整っていない場合に、任意のサイクルで s_axis_cc_tready をディアサートできます。統合ブロックが s_axis_cc_tready をディアサートしたクロックサイクル内では、ユーザーアプリケーションは CC インターフェイス上の値を変更できません。


図 3‐40: UR/CA コンプリーションの AXI4‐Stream パケットの構成

701234567+4

01234567+5

01234567+6

01234567+7

DW 3

tph_present

32

first _betph_st_tag

63

R

DW 0 DW 1

Completion Descriptor DW 1 Completion Descriptor DW 0

DW 2

Completion Descriptor DW 2

DW 4 DW 5

DW DW 7

last_be

tph_type[1:0]

R

Request Descriptor, DW 3 Request Descriptor, DW 2

Request Descriptor, DW 1 Request Descriptor, DW 0

X12245






リクエスターインターフェイス

リクエスターインターフェイスは、ユーザーエンドポイントアプリケーションがバスマスターとして PCIe リンクからホストメモリへの PCI トランザクションを開始できるようにします。ルートコンプレックスの場合も、このインターフェイスを使用して I/O およびコンフィギュレーションリクエストを開始します。このインターフェイスは、PCIe リンク上でメッセージを送信するために、エンドポイントとルートコンプレックスの両方で使用できます。このインターフェイスでのトランザクションは、コンプリーターインターフェイスでのトランザクションと同じですが、コアとユーザーアプリケーションの役割が逆になります。ポステッドトランザクションは、分割できない単一動作として処理されますが、ノンポステッドトランザクションはスプリットトランザクションとして処理されます。

リクエスターインターフェイスは、各方向のデータ転送にそれぞれが用いられる 2 つの個別のインターフェイスで構成されます。各インターフェイスは AXI4-Stream プロトコルに基づき、 64、 128、または 256 ビット幅に設定できます。リクエスターリクエスト (RQ) インターフェイスはユーザーアプリケーションから統合ブロックへリクエスト (関連するペイロードデータを含む) を転送するために使用され、リクエスターコンプリーション (RC) インターフェイスは、統合ブロックがリンクから受信したコンプリーション (ノンポステッドリクエスト ) をユーザーアプリケーションへ送信するために使用されます。これら 2 つのインターフェイスは独立して動作します。つまり、統合ブロックが前回のリクエストのコンプリーションを受信する間に、ユーザーアプリケーションが RQ インターフェイスを介して新しいリクエストを転送できます。

リクエスターリクエストインターフェイスの動作

RQ インターフェイスでは、ユーザーアプリケーションが各 TLP を AXI4-Stream パケットとして送信します。このパケットは 128 ビットディスクリプターから始まり、 TLP にペイロードが含まれる場合はその後をデータが続きます。図 3-41 に、リクエスターリクエストインターフェイスで使用される信号を示します。






RQ インターフェイスでは、ペイロードの転送において 2 つのデータアライメントモードをサポートします。Dword アライメントモードの場合、ユーザーロジックはディスクリプターの後の Dword の直後にペイロードの初の Dword を提供する必要があります。また、初の Dword の有効なバイトを示すために first_be[3:0] のビットがセットされ、ペイロードの後の Dword の有効なバイトを示すために last_be[3:0] (バス s_axis_rq_tuser の両部分) のビットがセットされる必要があります。アドレスアライメントモードの場合、ユーザーアプリケーションは、ディスクリプターの後の Dword の次のビートでペイロードを転送開始する必要があり、その初の Dword は、データパス上の任意の Dword 位置に設定できます。ユーザーアプリケーションは、 s_axis_rq_tuser の addr_offset[2:0] 信号を使用してデータパス上の初の Dword のオフセットを示します。 Dword アライメントモードの場合と同様に、初の Dword の有効バイトを示すために first_be[3:0] のビットをセットし、ペイロードの後の Dword の有効バイトを示すために last_be[3:0] のビットをセットする必要もあります。


図 3‐41: リクエスターリクエストインターフェイス

UltraScale FPGA Gen3 Integrated Block for PCIe

Client Application

PCIe RequesterRequest Interface

AXI4-StreamMaster

PCIe Requester Interface

s_axis_rq_tdata[255:0]

s_axis_rq_valid

s_axis_rq_tready

s_axis_rq_tlast

s_axis_rq_tkeep[7:0]

first_be[3:0]

last_be[3:0]

addr_offset[2:0]

discontinue

tph_present

tph_type[1:0]

tph_st_tag[7:0]

tph_indirect_tag_en

seq_num[3:0]

s_axis_rq_tuser[59:0]

pcie_rq_tag[5:0]

pcie_rq_tag_vld

pcie_tfc_nph[1:0]

pcie_tfc_npd[1:0]

pcie_rq_seq_num[3:0]pcie_rq_seq_num_vld

AXI4-StreamSlave

parity[31:0]






統合ブロックで Transaction Processing Hint 機能が有効に設定されている場合、ユーザーアプリケーションは s_axis_rq_tuser バスに含まれる tph_* 信号を使用して、任意のメモリトランザクションにオプションでヒントを提供できます。リクエストにヒントを提供する場合、ユーザーロジックはパケットの初のビートで tph_present をアサートし、 tph_st_tag[7:0] および tph_st_type[1:0] にそれぞれ TPH ステアリングタグおよびステアリングタグタイプを提供する必要があります。使用するステアリングタグの値を提供する代わりに、ユーザーアプリケーションには間接的にステアリングタグを提供するオプションがあります。このオプションを実行するには、 tph_present がアサートされているときに、 tph_indirect_tag_en 信号を 1 にセットし、tph_st_tag[7:0] にインデックスを設置します。これで、統合ブロックは、インデックスが指すオフセットのリクエスターファンクションと関連付けられているステアリングタグテーブルに格納されたタグを読み出し、リクエスト TLP に挿入します。

リクエスターリクエストディスクリプターのフォーマット

ユーザーアプリケーションは、リンク上に送信される各リクエストを個別の AXI4-Stream パケットとして、統合ブロックの RQ インターフェイスへ送信する必要があります。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 16 バイト長となり、リクエストパケットの初の 16 バイトで送信されます。ディスクリプターは、 64 ビットインターフェイスでは初の 2 サイクル間で送信され、 128 ビットまたは 256 ビットの場合は初のサイクルで送信されます。

図 3-42 ～図 3-46 に、ディスクリプターのフォーマットをリクエストタイプ別に示します。図 3-42 に示すフォーマットは、転送されているリクエスト TLP がメモリ読み出し /書き込みリクエスト、 I/O 読み出し /書き込みリクエスト、またはアトミック操作リクエストのときに適用されます。図 3-43 に示すフォーマットは、コンフィギュレーションリクエストに使用されます。図 3-44 に示すフォーマットは、ベンダー定義メッセージ (タイプ 0 またはタイプ 1) 専用です。図 3-45 に示すフォーマットは、すべての ATS メッセージ (無効なリクエスト、無効なコンプリーション、ページリクエスト、 PRG 応答) に使用されます。その他のメッセージのディクスリプターについては、図 3-46 に示すフォーマットとなります。


図 3‐42: メモリリクエスト、 I/O リクエスト、アトミック操作リクエストのリクエスターリクエストディスクリプターフォーマット

01234567+0

01234567+1

01234567+2

01234567+3

DW + 0

Address [63:2]

Address Type (AT)

01234567+4

01234567+5

01234567+6

01234567+7

DW + 1

Dword Count01234567

+801234567

+901234567

+1001234567

+11

DW + 2

TagTC01234567

+1201234567

+1301234567

+1401234567

+15

DW + 3

Attr

Req Type

96 64

32

Poisoned Request

BusCompleter ID

Requester ID EnableForce ECRC

Bus Device/Function

Requester IDDevice/Function

127

63 0

X12212







図 3‐43: コンフィギュレーションリクエストのリクエスターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

Reserved01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

Dword count01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

TagTC01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 3

Attr

Req Type

96 64

32

Poisoned Request

Bus

Completer ID



Device/Function

127

63 0

Reserved

Reg NumberExt. Reg Number

{Bus Number[7:0], Device Number[4:0],

Function Number[2:0]} X12631


図 3‐44:ベンダー定義メッセージのリクエスターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 396 64

Msg Code

Vendor - Defined Header BytesDestination ID

Bus Device/FunctionVendor ID

TL HeaderByte 15

R Dword CountTag

MessageRouting

TCAttr R

Req TypePoisoned Request



03263

127

TL HeaderByte 14

TL HeaderByte 13

TL HeaderByte 12

X12214







図 3‐45: ATS メッセージのリクエスターリクエストディスクリプターフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

01234567

+12

01234567

+13

01234567

+14

01234567

+15

DW + 3

96 64

32

Msg Code

TL Header Bytes 8-15

TL HeaderByte 15

R Dword CountTag

MessageRouting

TCAttr R

Req Type

Poisoned Request

Bus Device/Function

Requester ID


127

63 0

TL HeaderByte 14

TL HeaderByte 13

TL HeaderByte 12

TL HeaderByte 11

TL HeaderByte 10

TL HeaderByte 9

TL HeaderByte 8

X12211


図 3‐46: その他メッセージのリクエスターリクエストディスクリプターフォーマット

01234567+0

01234567+1

01234567+2

01234567+3

01234567+4

01234567+5

01234567+6

01234567+7

Dword Count01234567

+801234567

+901234567

+1001234567

+11

Tag01234567

+1201234567

+1301234567

+1401234567

+15

Req Type

96 64

32

Msg CodeMessageRouting

TCAttr R

OBFF Code (for OBFF message); Reserved (for others)

No-Snoop Latency (for LTR message);


Snoop Latency (for LTR message);


R

Bus Device/Function

Requester ID

0

127

63

DW + 0DW + 1

DW + 2DW + 3

X12213

Poisoned RequestForce ECRC

Requester ID Enable






表 3-12 に、コンプリーターリクエストディスクリプターの個別フィールドを示します。

表 3‐12: リクエスターリクエストディスクリプターのフィールド



1:0Address Type


このフィールドは、メモリトランザクションおよびアトミック操作専用に定義されます。統合ブロックは、このフィールドをリクエスト TLP の TL ヘッダーの AT へコピーします。

• 00: リクエスト内のアドレスは変換されない

• 01: トランザクションは変換リクエスト

• 10: リクエスト内のアドレスは変換される

• 11: 予約

63:2 Address (アドレス)

このフィールドは、メモリ、 I/O、およびアトミック操作の各リクエストに適用されます。リクエストで指定された初の Dword のアドレスです。ユーザーアプリケーションは、初と後の Dword の有効バイトを示すために、 s_axis_rq_tuser の First_BE および Last_BE ビットをそれぞれ設定する必要もあります。

トランザクションが 32 ビットアドレスを指定する場合、このフィールドのビット [63:32] は 0 になります。

74:64Dword Count


これらの 11 ビットは、読み出しまたは書き込みの対象となっているブロックのサイズ (メッセージの場合は、メッセージペイロードのサイズ) を示します (Dword 単位)。メモリ書き込みリクエスト用の有効な範囲は、 0 ～ 256 Dword です。メモリ読み出しリクエストには、 1 ～ 1024 Dword の有効な範囲があります。 I/O アクセスの場合、 Dword カウントは常に 1 です。

メモリの読み出し /書き込みリクエストの長さが 0 の場合、Dword カウントは 1 になり、 First_BE ビットはすべて 0 にセットされる必要があります。

統合ブロックは、供給されるペイロード (ペイロードを含むリクエスト ) の実際の長さ、また統合ブロックの大ペイロードサイズや読み出しリクエストサイズの設定に対してこのフィールドを照合してチェックするわけではありません。

78:75Request Type

( リクエストタイプ)トランザクションタイプを特定します。トランザクションタイプとそれらのエンコードの詳細は、表 3-9 に示します。

79Poisoned Request

(ポイズンリクエスト )

このビットは、送信されるリクエスト TLP にポイズニングを適用する場合に使用できます。この機能は、タイプ 0 およびタイプ 1 のコンフィギュレーション書き込みリクエスト以外のすべてのリクエストでサポートされています。ユーザーアプリケーションがディスクリプターの後に続くデータブロック内にエラーを検出し、 PCI Express のデータポイズニング機能を使用してこのエラー情報を伝える場合以外は、このビットはすべてのリクエストで 0 にセットする必要があります。

この機能は、タイプ 0 およびタイプ 1 のコンフィギュレーション書き込みリクエスト以外のすべてのリクエストでサポートされています。






87:80

Requester Function/Device Number ( リクエスター

ファンクション番号/デバイス番号)

リクエスターファンクションのファンクション/デバイス番号です。



° ビット [87:80] をリクエスターファンクション番号に設定する必要があります。



° ビット [87:83] は使用しません。






° リクエストの送信元がスイッチ自身の場合、ビット [87:83] は使用しません。スイッチがリクエストを中継している場合 (すなわちリクエスターがスイッチ外部にある場合)、これらのビットは、リクエスト送信元のリクエスターデバイス番号に設定する必要があります。ディスクリプターの Requester ID Enable ビットと組み合わせて使用します。






° ビット [87:83] をリクエスターデバイス番号に設定する必要があります。ディスクリプターの Requester ID Enable ビットと組み合わせて使用します。

95:88Requester Bus Number

( リクエスターバス番号)

リクエスターファンクションに関連するバス番号です。


• 使用しない


• リクエストの送信元がスイッチ自身の場合、使用しません。スイッチがリクエストを中継している場合 (すなわちリクエスターがスイッチ外部にある場合)、これらのビットは、リクエスト送信元のリクエスターバス番号に設定する必要があります。ディスクリプターの Requester ID Enable ビットと組み合わせて使用します。


• リクエスターバス番号に設定する必要があります。ディスクリプターの Requester ID Enable ビットと組み合わせて使用します。

表 3‐12: リクエスターリクエストディスクリプターのフィールド (続き)








103:96 Tag (タグ)

リクエストに関連する PCIe タグです。

ノンポステッドトランザクションの場合、統合ブロックは AXISTEN_IF_ENABLE_CLIENT_TAG パラメーターが設定されている場合 (つまり、ユーザーアプリケーションでタグ管理が実行されている場合) にこのフィールドの値を使用します。ビット [101:96] はタグとして使用されます。ビット [103:102] は予約されています。このパラメーターが設定されていない場合は、統合ブロック内のタグ管理ロジックがタグを生成し、ディスクリプターのタグフィールドは使用されません。

119:104Completer ID

(コンプリーター ID)

このフィールドは、 ID を使用して送信されコンフィギュレーションリクエストやメッセージにのみ適用されます。これらのリクエストでは、このフィールドが各リクエストに関連する PCI コンプリーター ID を示します (これらの 16 ビットは、レガシインタープリテーションモードでは 8 ビットのバス番号、 5 ビットのデバイス番号、 3 ビットのファンクション番号に分けられる )。 ARI モードの場合、これらの 16 ビットは 8 ビットのバス番号と 8 ビットのファンクション番号として扱われます。

120Requester ID Enable ( リクエスター ID

イネーブル)

1’b1: クライアントがディスクリプターで指定したバス番号、デバイス番号、およびファンクション番号を TLP ヘッダーのリクエスター ID フィールドに格納します。

1’b0: IP は受信したコンフィギュレーションリクエストから取り込んだバス番号とデバイス番号、およびクライアントがディスクリプターで指定したファンクション番号を TLP ヘッダーのリクエスター ID フィールドに格納します。


• 必ず 1’b0 に設定します。


• リクエストの送信元がスイッチ自身の場合、 1’b0 に設定します。

• スイッチがリクエストを中継している場合 (すなわちリクエスターがスイッチ外部にある場合)、 1’b1 に設定します。 ARI が無効な場合は、リクエスターバス番号ビット [95:88] およびリクエスターファンクション/デバイス番号ビット [87:83] と組み合わせて使用します。

ルートポートモード :

• 必ず 1’b1 に設定します。 ARI が無効な場合は、リクエスターバス番号ビット [95:88] およびリクエスターファンクション/デバイス番号ビット [87:83] と組み合わせて使用します。

123:121 Transaction Class (TC) リクエストに関連する PCIe トランザクションクラス (TC) です。

126:124 Attributes (属性)

これらのビットは、リクエストに関連する Attribute ビットの設定を提供します。ビット 124 は No Snoop ビットで、ビット 125 は Relaxed Ordering ビットです。ビット 126 は ID-Based Ordering ビットで、メモリリクエストとメッセージ専用にセットできます。

ファンクションの PCI Express デバイス制御レジスタで対応する属性が有効に設定されていない場合、統合ブロックはリンク上に送信されるリクエストの属性ビットを強制的に 0 にします。

127 Force ECRC

強制的に ECRC を挿入します。このビットを 1 にセットすると、リクエストを送信するファンクションで ECRC 機能が有効に設定されていない場合でも、統合ブロックがリクエスト TLP に ECRC を含む TLP Digest を追加します。









リクエスターメモリ書き込み動作

Dword アライメントモードでは、転送は 16 ディスクリプターバイトから始まり、その直後にペイロードバイトが続きます。ユーザーアプリケーションは、パケットが送信される間、 s_axis_rq_tvalid 信号をアサートしたままに保持する必要があります。パケット送信中に s_axis_rq_tvalid がディアサートされると、統合ブロックはこれをエラーとして処理し、リンク上の対応するリクエスト TLP を無効にしてデータ破損を回避します。

またユーザーアプリケーションは、パケットの後のビートで s_axis_rq_tlast をアサートします。統合ブロックは、データの受信準備が整っていない場合に、任意のサイクルで s_axis_rq_tready をディアサートできます。統合ブロックが s_axis_rq_tready をディアサートしたクロックサイクル内では、ユーザーアプリケーションは RQ インターフェイス上の値を変更しないでください。ディスクリプターおよびディスクリプターとペイロードの間に挿入される NULL バイトを含むパケット内の Dword が有効であることを示すには、 AXI4-Stream インターフェイス信号 m_axis_rq_tkeep (各 Dword 位置に 1 つ) をセットする必要があります。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、 tkeep ビットは継続的に 1 にセットされる必要があります。パケットの転送中、インターフェイスの幅全体がパケットで埋められないときは、パケットの後のビートに限り tkeep ビットを 0 にできます。

リクエスターリクエストインターフェイスでは、 s_axis_rq_tuser バスに First Byte Enable ビットと Last Enable ビットも含まれます。これらのビットはパケットの初のビートでセットされ、ペイロードの初と後の Dword にある有効なバイト情報を提供します。

15:0Snoop Latency

(スヌープレイテンシ)このフィールドは LTR メッセージ専用に定義されます。メッセージの TLPヘッダーにある 16 ビットの Snoop Latency フィールドの値を提供します。

31:16No-Snoop Latency (ノースヌープレイテンシ)

このフィールドは LTR メッセージ専用に定義されます。メッセージの TLP ヘッダーにある 16 ビットの No-Snoop Latency フィールドの値を提供します。

35:32 OBFF コード

OBFF コードフィールドは、さまざまな OBFF ケースを識別するために使用されます。

• 1111b: CPU アクティブ – バスマスタリングや割り込みなど、すべてのデバイスアクションに対してシステムが完全にアクティブである

• 0001b: OBFF – デバイスメモリの読み出し /書き込みバスマスターの動作で利用可能なシステムメモリパス

• 0000b: アイドル – システムがアイドル状態で、低電力ステート

その他すべてのコードは予約されています。

111:104 メッセージコード

このフィールドはすべてのメッセージ用に定義されます。 TLP ヘッダーに設定される 8 ビットのメッセージコードが含まれます。

サポート対象のメッセージコードの一覧は、『PCI Express Base Specification、 rev. 3.0』 [参照 2] の「Appendix F」を参照してください。

114:112Message Routing

(メッセージルーティング)

このフィールドはすべてのメッセージ用に定義されます。統合ブロックは、これらのビットをリクエスト TLP の TLP ヘッダーにある 3 ビットの Routing フィールド r[2:0] へコピーします。

15:0Destination ID

(デスティネーション ID)

このフィールドはベンダー定義メッセージにのみ適用されます。メッセージが ID を使用して送信される場合 (つまり、 Message Routing フィールドが 010 バイナリの場合)、このフィールドはメッセージの Destination ID を提供します。

63:32Vendor-Defined Header

(ベンダー定義のヘッダー )

このフィールドはベンダー定義メッセージにのみ適用されます。 TLP ヘッダーの Dword 3 へコピーされます。

63:0ATS Header

(ATS ヘッダー )このフィールドは ATS メッセージにのみ適用可能です。統合ブロックが TLP ヘッダーの Dword 2 と Dword 3 へコピーするバイトが含まれます。









ユーザーアプリケーションは、 1 つのリクエストで転送されるペイロードのサイズを、統合ブロックで設定した大ペイロードサイズまでに制限し、ペイロードが 4k バイトの境界を超えないようにする必要があります。 2 Dword またはそれ以下のメモリ書き込みの場合、 first_be および last_be で 1 が連続しない場合があります。長さ 0 のメモリ書き込みリクエストなど特殊な場合は、 first_be と last_be が両方ともすべて 0 にセットされた状態でユーザーアプリケーションがダミーの 1 Dword ペイロードを提供する必要があります。その他の場合、 first_be および last_be では 1 が連続する必要があります。

図 3-47、図 3-48、および図 3-49 のタイミング図は、リクエスターリクエストインターフェイスを介すユーザーアプリケーションからのメモリ書き込みリクエストの Dword アライメント転送を、インターフェイス幅 64、 128、および 256 ビット別に示しています。説明用として、ユーザーアプリケーションメモリに書き込まれるデータブロックのサイズは n Dword と仮定し、 n = k × 32 + 29 (k > 0) となります。


図 3‐47: リクエスターリクエストインターフェイスでのメモリ書き込みトランザクション (Dword アライメントモード、 64 ビットインターフェイス)

user_clk



s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast

(first_be) s_axis_rq_tuser[3:0]

(last_be) s_axis_rq_tuser[7:4]

(discontinue) s_axis_rq_tuser[11]


DESC 1 DESC 3 DW 1 DW 1 DW 3

0x3 0x3 0x3 0x1

FIRST BE

LAST BE

X12336








user_clk





s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast





DESC 1 DW 1 DW 1

DESC 2 DW 2 DW 2

DESC 3 DW 3 DW 3

0xF 0xF 0xF 0x1

FIRST BE

LAST BE

X12337






図 3-50、図 3-51、および図 3-52 のタイミング図は、 RQ インターフェイスを介すユーザーアプリケーションからのメモリ書き込みリクエストのアドレスアライメント転送を、インターフェイス幅 64、 128、および 256 ビット別に示しています。図示する目的で、ユーザーアプリケーションメモリに書き込まれるデータブロックの開始 Dword オフセットは、整数 m > 0 のとき (m × 32 + 1) と仮定しています。サイズは n Dword と仮定し、 n = k × 32 + 29 (k > 0) となります。

アドレスアライメントモードでは、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。ペイロードの初の Dword は、任意の Dword 位置で現れることができます。ユーザーアプリケーションは、 s_axis_rq_tuser の addr_offset[2:0] 信号を使用して、データパス上にあるペイロードの初の Dword のオフセットを示す必要があります。また、初の Dword の有効バイトを示すために first_be[3:0] のビットをセットし、ペイロードの後の Dword の有効バイトを示すために last_be[3:0] のビットをセットする必要もあります。



user_clk









s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast





DESC 1 DW 5 DW 5

DESC 2 DW 6 DW 6

DESC 3 DW 7 DW 7

DW 0 DW 8 DW 8

DW 1 DW 9 DW 9

DW 2 DW 10 DW 10

DW 3 DW 11 DW 11

0xFF 0xFF 0xFF 0x01

FIRST BE

LAST BE

X12338







図 3‐50: リクエスターリクエストインターフェイスでのメモリ書き込みトランザクション (アドレスアライメントモード、 64 ビットインターフェイス)

user_clk



s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast



(add_offset[2:0]) s_axis_rq_tuser[10:8]




0x3

FIRST BE

LAST BE

1

X12333



user_clk





s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast





DESC 0 DW 3 DW n-2




0xF 0xF 0xF 0x3

FIRST BE

LAST BE

1

X12334






ペイロードを含まないノンポステッドトランザクション

ペイロードを含まないノンポステッドトランザクション (メモリ書き込みリクエスト、 I/O 読み出しリクエスト、コンフィギュレーション読み出しリクエスト ) は、メモリ書き込みリクエストと同様に RQ インターフェイスを介して送信されますが、このトランザクションでは AXI4-Stream パケット 7 に 16 バイトのディスクリプターのみ含まれます。図 3-53、図 3-54、および図 3-55 のタイミング図は、 RQ インターフェイスを介すメモリ読み出しリクエストの転送を 64、 128、および 256 ビット別に示しています。パケットは、 64 ビットインターフェイスでは連続する 2 ビートを使用して転送されますが、 128 ビットまたは 256 ビットインターフェイスでは 1 ビートで転送されます。s_axis_rq_tvalid 信号は、パケットが送信される間アサートされた状態を維持する必要があります。統合ブロックは、このビートを延長させるために s_axis_rq_tready をディアサートできます。 s_axis_rq_tlast 信号は、パケットの後のビートでセットされ、 s_axis_rq_tkeep[7:0] のビットは、ディスクリプターが現れるすべての Dword 位置でセットされる必要があります。

読み出されるデータブロックの初と後の Dword の有効バイトは、 first_be[3:0] および last_be[3:0] をそれぞれ使用して示される必要があります。長さ 0 のメモリ読み出しリクエストなど特殊な場合は、first_be[3:0] と last_be[3:0] が両方ともすべて 0 にセットされた状態で、リクエストの長さは 1 Dword に設定される必要があります。さらに、アドレスアライメントモードの場合は、 s_axis_rq_tuser の addr_offset[2:0] がリクエスターコンプリーションインターフェイス上に返されるデータの任意の開始アライメントを指定します。アライメントは、リクエストのアドレスと相関性を持つ必要はありません。



user_clk









s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast









DW 3 DW 11 DW 11 DW n-2

DW 4 DW 12 DW 12 DW n-1

DW 5 DW 13 DW 13

DW 6 DW 14 DW 14

0xFF 0xFF 0xFF 0x3F

FIRST BE

LAST BE

1

X12335







図 3‐53: リクエスターリクエストインターフェイスでのメモリ書き込みトランザクション (64 ビットインターフェイス)



user_clk



s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast






0x3 0x3

FIRST BE FIRST BE

LAST BE LAST BE

user_clk





s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast




DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

DESC 3 DESC 3

0xF 0xF

FIRST BE FIRST BE

LAST BE LAST BE






ペイロードを含むノンポステッドトランザクション

ペイロードを含むノンポステッドリクエスト (I/O 書き込みリクエスト、コンフィギュレーション書き込みリクエスト、またはアトミック操作リクエスト ) の転送は、メモリリクエストの転送と類似していますが、ペイロードをデータパス上で揃える方法において次の点が異なります。

• Dword アライメントモードの場合、ペイロードの初の Dword はディスクリプターの後の Dword の後に転送され、この 2 つの Dword 間にギャップは生じません。

• アドレスアライメントモードの場合、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。ペイロードはデータパス上の任意の Dword 位置で開始できます。初の Dword のオフセットは、 addr_offset[2:0] 信号を使用して指定される必要があります。

I/O およびコンフィギュレーション書き込みリクエストの場合、 1 Dword ペイロードの有効バイトは、first_be[3:0] 信号を使用して指定されます。アトミック操作リクエストの場合、初と後の Dword のすべてのバイトを有効と見なします。



user_clk






s_axis_rq_tvalid

s_axis_rq_tready


s_axis_rq_tlast




DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

DESC 3 DESC 3

0x0F 0x0F

FIRST BE FIRST BE

LAST BE LAST BE

X12332






リクエスターインターフェイスでのメッセージリクエスト

RQ インターフェイスにおけるメッセージの転送はメモリ書き込みリクエストと同様ですが、ペイロードが常に存在するわけではない点のみ異なります。転送は 128 ビットディスクリプターから始まり、ペイロードがある場合はその後ペイロードが続きます。 Dword アライメントモードを使用する場合、ディスクリプターの直後にペイロードの初の Dword が続きます。アドレスアライメントモードを使用する場合、ペイロードはディスクリプターの後の

ビートで開始する必要があり、またバイトレーン 0 に揃う必要があります。アドレスアライメントモードが使用される場合、メッセージに対して、統合ブロックへの addr_offset 入力が 0 にセットされている必要があります。統合ブロックは、 s_axis_rq_tlast および s_axis_rq_tkeep 信号からペイロードの終わりを判断します。メッセージリクエストの場合、 First Byte Enable ビットおよび Last Byte Enable ビット (first_be および last_be) は使用されません。

転送の中断

関連するペイロードを含むすべてのリクエストの転送では、ユーザーアプリケーションが s_axis_rq_tuser バスで discontinue 信号をアサートすることによって、ペイロード転送中にいつでもリクエストを中断できます。統合ブロックはリンク上の対応する TLP を無効にしてデータ破損を回避します。

ユーザーアプリケーションは、転送されているリクエストが関連するペイロードを含んでいる場合に、転送中の任意のタイミングでこの信号をアサートできます。また、エラーが示されたサイクルでパケットを早期に中断する (s_axis_rq_tlast をアサート )、またはペイロードのすべてのバイトが統合ブロックへ送信されるまで継続してから中断するのいずれかを選択できます。後者の場合、ユーザーアプリケーションがパケットの終了より前に discontinue 信号をディアサートした場合でも、統合ブロックはパケットのその後のサイクルでエラーをスティッキーとして処理します。

discontinue 信号は、 s_axis_rq_tvalid がアクティブ High の場合のみアサートされます。統合ブロックは、s_axis_rq_tvalid と s_axis_rq_tready が両方ともアクティブ High にアサートされている場合にこの信号をサンプルします。したがって、 discontinue 信号がアサートされると、 s_axis_rq_tready がアクティブ High にアサートされるまでディアサートできません。

統合ブロックがエンドポイントとしてコンフィギュレーションされる場合、 Advanced Error Reporting (AER) 機能を使用して訂正不可能な内部エラーとして、接続される先のルートコンプレックスに対して統合ブロックがエラーをレポートします。

ノンポステッド転送のタグ管理

統合ブロックのリクエスター側が、ユーザーアプリケーションによって開始されたすべての保留されているノンポステッドトランザクション (メモリ読み出し、 I/O 読み出しおよび書き込み、コンフィギュレーション読み出しおよび書き込み、アトミック操作) のステータスを維持し、これによってターゲットから返されるコンプリーションが対応するリクエストと一致することが可能になります。未処理トランザクションの各ステートは、インターフェイスのリクエスター側にあるスプリットコンプリーションテーブルで管理されます。このテーブルでは 64 のノンポステッドトランザクションを管理できます。コンプリーションが返されると、 6 ビットのタグを使用して保留中のリクエストとの一致を確認します。これらのタグ管理には、次の 2 つのオプションがあります。

• Internal Tag Management (内部タグ管理): このモードは、 Vivado IDE で [Enable Client Tag] をオンにすると選択されます (デフォルトはオン)。リクエスター側から開始された各ノンポステッドリクエストに対して、統合ブロック内のロジックがタグの割り当てを実行します。統合ブロックは、フリータグのリストを管理し、ユーザーアプリケーションがノンポステッドトランザクションを開始する際に各リクエストにこれらのいずれかを割り当て、その後 pcie_rq_tag[5:0] 出力を介して割り当てたタグ値をユーザーアプリケーションに伝達します。このバスの値は、統合ブロックが pcie_rq_tag_vld をアサートすると有効になります。リクエストに応答して統合ブロックから送信されたすべてのコンプリーションがリクエストと一致するように、ユーザーロジックはこのタグをコピーする必要があります。

このモードでは、統合ブロック内のロジックがスプリットコンプリーションテーブルの全条件をチェックし、現在未処理状態のノンポステッドリクエストの合計数が大値 (64) に到達すると、ユーザーアプリケーションからのノンポステッドリクエストにバックプレッシャーを用いて (s_axis_rq_tready を使用) 送信を制御します。






• External Tag Management (外部タグ管理): このモードの場合、リクエスター側から開始された各ノンポステッドリクエストに対して、ユーザーロジックがタグの割り当てを実行します。ユーザーロジックは、その時点で処理されていないその他すべてのノンポステッドトランザクションのタグと競合しないようにタグ値を選択し、その選択したタグ値をリクエスターディスクリプターを介して統合ブロックへ伝達する必要があります。さらに統合ブロックは、スプリットコンプリーションテーブル内で未処理のリクエストを管理し、受信するコンプリーションをリクエストと一致させます。ただし、タグの異常やスプリットコンプリーションテーブルの全条件チェックは実行しません。

内部タグ管理オプションを使用する場合、統合ブロックは、 pcie_rq_tag[5:0] に割り当てたタグ値を出力した後、各ノンポステッドリクエストに対して 1 サイクル間 pcie_rq_tag_vld をアサートします。 RQ インターフェイスにリクエストが転送されてから、そのリクエストに対して割り当てたタグ値を提供するために統合ブロックが pcie_rq_tag_vld をアサートするまでには、数サイクルの遅延が生じる可能性があります。この間、ユーザーアプリケーションは新しいリクエストを継続して送信できます。各リクエストのタグは、 pcie_rq_tag バスを使用して FIFO 順序で伝達されるため、送信されたリクエストとタグの値を簡単に関連付けることができます。スプリットコンプリーションの後のコンプリーションの EOF (end-of-frame) がユーザーアプリケーションで受信されるときに、タグは再び使用されます。

ポステッドリクエストの HOL (Head‐of‐Line) ブロッキングの回避

統合ブロックは、送信クレジットまたは有効なタグが不足した場合に、 RQ インターフェイスで受信したノンポステッドリクエストを保持できます。この際、ポステッドトランザクションで HOL (Head-of-Line) ブロッキングが生じる可能性があります。統合ブロックは、この状況を回避するために次の信号を用いたメカニズムをユーザーロジックに提供します。

• pcie_tfc_nph_av[1:0]: これらの出力は、ノンポステッドリクエストで現在利用できるヘッダークレジット数を示します。

° 00 = 使用可能なクレジットはない

° 01 = 1 クレジット

° 10 = 2 クレジット

° 11 = 3 以上のクレジット

• pcie_tfc_npd_av[1:0]: これらの出力は、ノンポステッドリクエストで現在利用できるデータクレジット数を示します。

° 00 = 使用可能なクレジットはない

° 01 = 1 クレジット

° 10 = 2 クレジット

° 11 = 3 以上のクレジット

ユーザーロジックは、ノンポステッドリクエストを送信する前にオプションでこれらの出力を確認できます。内部パイプライン遅延が原因で、これらの出力情報は、 RQ インターフェイスにディスクリプターの後のバイトが送信されたサイクルより、 2 ユーザークロックサイクル分遅れます。したがって、ユーザーロジックは、 2 つ前のクロックサイクルで送信されたノンポステッドリクエストを考慮して正しい値を取得する必要があります。図 3-56 に、 256 ビットインターフェイスでのこれらの信号の動作を示しています。この例では、初に統合ブロックには 3 つのノンポステッドヘッダークレジットと 2 つのノンポステッドデータクレジット、そして有効な 3 つのフリータグがあります。ユーザーアプリケーションからのリクエスト 1 (Req 1) は、 1 Dword ペイロードを含んでいるため、ヘッダークレジットとデータクレジットを 1 つずつ使用し、タグも 1 つ使用します。次のサイクルでリクエスト 2 (Req 2) が 1 ヘッダークレジットを使用しますが、データクレジットは使用していません。次のクロックサイクルでユーザーアプリケーションがリクエスト 3 (Req 3) を示すとき、リクエスト 1 とリクエスト 2 を考慮し、利用可能なクレジット数とタグ数を調整する必要があります。リクエスト 3 が 1 ヘッダークレジットと 1 データクレジットを使用すると、 2 サイクル後に使用できる両方のクレジット数が 0 となり、タグ数も 0 となります。

図 3-57 および図 3-58 は、同じ例のクレジットとタグのタイミングを、インターフェイス幅 128 ビットおよび 64 ビット別に示しています。







図 3‐56: リクエスターリクエストインターフェイスでの利用可能なクレジット数およびタグ数を示す信号 (256 ビットインターフェイス)



user_clk

s_axis_rq_data[255:0]

s_axis_rq_data_tvalid

s_axis_rq_data_ready

s_axis_rq_data_tlast

pcie_tfc_nph[1:0]

pcie_tfc_npd[1:0]

pcie_rq_tag_av[1:0]

NP Req 1 NP Req 2 NP Req 3

0x3 0x2 0x1 0x0

0x2 0x1 0x0

0x3 0x2 0x1 0x0

X12339

user_clk





pcie_tfc_nph[1:0]

pcie_tfc_npd[1:0]

pcie_rq_tag_av[1:0]


0x3 0x2 0x1 0x0

0x2 0x1 0x0

0x3 0x2 0x1 0x0

X12341






トランザクション順序の維持

統合ブロックは、リクエスターインターフェイスでユーザーアプリケーションから受信したリクエストをリンクに送信する際に順序を変更しません。ユーザーアプリケーションが RQ インターフェイスおよび CC インターフェイスに送信されるトランザクション順序を正確に制御する必要がある場合 (通常、順序設定で STRICT を使用する場合に、コンプリーションがポステッドリクエストを飛び越えないようにするため)、統合ブロックはパイプラインをとおるポステッドトランザクションの進捗をユーザーアプリケーションがモニタリングできるメカニズムを提供します。これによって、リクエスターリクエストインターフェイスから送信された特定のポステッドリクエストを飛び越えるリスクを冒すことなく、コンプリーターコンプリーションインターフェイス上にコンプリーションを送信するタイミングを判断できます。

リクエスターリクエストインターフェイスを介してポステッドリクエスト (メモリ書き込みトランザクションまたはメッセージ) を転送する場合、ユーザーアプリケーションは s_axis_rq_tuser の seq_num[3:0] 入力で 4 ビットのシーケンス番号を統合ブロックへオプションで提供できます。このシーケンス番号は、パケットの初のビートで有効になります。ユーザーアプリケーションは、コアの pcie_rq_seq_num[3:0] 出力をモニタリングして、このシーケンス番号が現れるのを確認できます。トランザクションが統合ブロックの内部送信パイプラインを進み、コンプリーションが越えることのできないステージに達すると、統合ブロックは pcie_rq_seq_num_valid を 1 サイクル間アサートして、 pcie_rq_seq_num[3:0] 出力にポステッドリクエストのシーケンス番号を提供します。シーケンス番号が pcie_rq_seq_num[3:0] に現れた後に統合ブロックから送信されたコンプリーションが、内部送信パイプライン内のポステッドリクエストを飛び越えることはありません。



user_clk





pcie_tfc_nph[1:0]

pcie_tfc_npd[1:0]

pcie_rq_tag_av[1:0]


0x3 0x2 0x1 0x0

0x2 0x1 0x0

0x3 0x2 0x1 0x0

X12340






リクエスターコンプリーションインターフェイスの動作

ユーザーロジックで生成されたリクエストに対するコンプリーションは、統合ブロックのリクエスターコンプリーション (RC) インターフェイスに現れます。図 3-59 に、リクエストコンプリーションインターフェイスに現れる信号を示しています。ストラドルが無効に設定されている場合、統合ブロックはこのインターフェイスを使用して各 TLP を AXI4-Stream パケットとして送信します。パケットは 96 ビットディスクリプターから始まり、コンプリーションにペイロードが含まれる場合はその後をデータが続きます。

RC インターフェイスでは、ペイロードの転送において 2 つのデータアライメントモードをサポートします。Dword アライメントモードの場合、統合ブロックはディスクリプターの後の Dword の直後にコンプリーションペイロードの初の Dword を送信する必要があります。アドレスアライメントモードの場合、統合ブロックはディスクリプターの後の Dword に続いて発生するビートでペイロードの送信を開始し、その初の Dword はデータパス上の任意の Dword 位置で開始できます。ペイロードの初の Dword のアライメントは、ユーザーアプリケーションが統合ブロックにリクエストを送信したときに提供されるアドレスオフセット (つまり、 RQ インターフェイスの addr_offset[2:0] 入力の設定) で決定します。したがって、アドレスアライメントモードは、 RQ インターフェイスで使用できるように設定されている場合のみ、 RC インターフェイスで使用できます。


図 3‐59: リクエスターコンプリーションインターフェイス

Integrated Block for PCIeClient Application

PCIe Requester Completion

Interface

AXI4-StreamSlave

PCIe RequesterInterface

m_axis_rc_tdata[255:0]

m_axis_rc_tvalid

m_axis_rc_tready

m_axis_rc_tkeep[7:0]

m_axis_rc_tlast

byte_en[31:0]

is_sof_0

is_sof_1

is_eof_0[3:0]

is_eof_1[3:0]

m_asix_rc_tuser[74:0]

AXI4-StreamMaster

discontinue

parity[31:0]






リクエスターコンプリーションディスクリプターのフォーマット

統合ブロックの RC インターフェイスは、リンクから受信したコンプリーションデータをユーザーアプリケーションへ AXI4-Stream パケットとして送信します。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 12 バイト長となり、コンプリーションパケットの初の 12 バイトで送信されます。ディスクリプターは、 64 ビットインターフェイスでは初の 2 サイクル間で送信され、 128 ビットまたは 256 ビットの場合は初のサイクルで送信されます。コンプリーションデータが複数のスプリットコンプリーションに分割される場合は、統合ブロックが各スプリットコンプリーションを個別にディスクリプターを備えた AXI4-Stream パケットとして送信します。

リクエスターコンプリーションディスクリプターのフォーマットは、図 3-60 を参照してください。 RC ディスクリプターの各フィールドの詳細は、表 3-13 で説明しています。


図 3‐60: リクエスターコンプリーションディスクリプターのフォーマット

01234567

+0

01234567

+1

01234567

+2

01234567

+3

DW + 0

Byte CountDword count01234567

+4

01234567

+5

01234567

+6

01234567

+7

DW + 1

TagTC01234567

+8

01234567

+9

01234567

+10

01234567

+11

DW + 2

Device / FunctionAttr

Poisoned Completion

63 32

Address [11:0]

Completion Status

Bus

Completer ID


R R

Error CodeRequest Completed

Bus Device /Function

Requester IDR

0

6495

X12210

表 3‐13: リクエスターコンプリーションディスクリプターのフィールド



11:0Lower Address

(下位アドレス)

このフィールドでは、リクエストによって参照される初のバイトの下位 12 ビットを提供します。統合ブロックは、スプリットコンプリーションテーブルからこのアドレスを返します。このテーブルには、リクエスター側の保留されているすべてのノンポステッドリクエストのアドレスとその他のパラメーターが格納されています。

送信されたコンプリーションにエラーがあると、このアドレスのビット [6:0] のみ有効として見なされます。

これはバイト単位のアドレスです。






15:12Error Code

(エラーコード )

コンプリーションのエラーコードです。

これらの 3 ビットは、統合ブロックが受信したコンプリーションに対して実行したエラーチェックで検出されたエラー状況をエンコードしたものです。エンコードは次のとおりです。

• 0000: 正常終了 (すべてのデータを受信)。

• 0001: コンプリーション TLP にポイズニングが適用されている。

• 0010: リクエストは UR、 CA、または CRD ステータスを含むコンプリーションで終了している。

• 0011: データを含まないコンプリーションでリクエストが終了、またはそのコンプリーションのバイトカウントがそのリクエストに対して予測されている合計バイト数を超えている。

• 0100: 送信されている現在のコンプリーションには、未処理リクエストと同じタグがあるが、その Requester ID、 TC、または Attribute フィールドが未処理リクエストのパラメーターと一致していない。

• 0101: 開始アドレスのエラー。コンプリーション TLP ヘッダーの下位アドレスが、そのリクエストの次に予想されるバイトの開始アドレスと一致していない。

• 0110: 無効なタグ。このコンプリーションは、未処理リクエストのどのタグとも一致していない。

• 1001: コンプリーションタイムアウトでリクエストが終了した。この場合、ディスクリプターはコンプリーション TLP に対応しないため、ビット [30]、リクエスターファンクション [55:48]、およびタグフィールド [71:64] を除くディスクリプターのその他のフィールドは無効となる。

• 1000: リクエストを生成したファンクションをターゲットとする Function-Level Reset (FLR) によってリクエストが終了した。この場合、ディスクリプターはコンプリーション TLP に対応しないため、ビット [30]、リクエスターファンクション [55:48]、およびタグフィールド [71:64] を除くディスクリプターのその他のフィールドは無効となる。

28:16Byte Count

(バイトカウント )

これらの 13 ビットには、 0 ～ 4,096 バイトの範囲の値が含まれます。シングルコンプリーションを使用してメモリ読み出しリクエストが完了する場合、このバイトカウント値がペイロードサイズをバイト単位で示します。 I/O の読み出しコンプリーションや I/O の書き込みコンプリーションの場合、このフィールドは 4 にセットされる必要があります。長さ 0 のメモリ読み出しに対するコンプリーションを送信している間、バイトカウント値は 1 にセットされる必要があり、ダミーのペイロードとして 1 Dword がディスクリプターの後に送信される必要があります。

各メモリ読み出しコンプリーションでは、このバイトカウントフィールドがリクエストを完了するのに必要となる残りのバイト数を示します (コンプリーションで返ってきたバイト数を含む)。

複数のコンプリーションを使用してメモリ読み出しリクエストが完了する場合、各コンプリーションのこのバイトカウント値は、先行するコンプリーションが示す値から先行するコンプリーションで返ってきたバイト数を引いた値となります。

29


(ロックされた読み出しコンプリーション)

Locked Read (ロックされた読み出し ) リクエストに対してコンプリーション応答する場合、このビットを 1 にセットします。その他のコンプリーション応答の場合、このフィールドは 0 にセットする必要があります。

表 3‐13: リクエスターコンプリーションディスクリプターのフィールド (続き)








データを含まないコンプリーションの転送

図 3-61、図 3-62、および図 3-63 のタイミング図は、 RC インターフェイスを介して、リンクから受信したペイロードを含まないコンプリーション TLP の転送を 64、 128、および 256 ビット別に示しています。このセクションのタイミング図では、 256 ビットインターフェイスでコンプリーションがストラドルされないことを仮定しています。ストラドル機能の詳細は、 176 ページの「256 ビットインターフェイスのストラドルオプション」を参照してください。

30Request Completed

( リクエストの完了)

統合ブロックは、リクエストに対する後のコンプリーションのディスクリプターのこのビットをアサートします。このビットをアサートすることで、リクエストの正常終了 (すべてのデータを受信)、またはエラーによる異常終了を示すことができます。ユーザーロジックは、この表示を利用して、処理されていないリクエストのステータスをクリアできます。

タグが割り当てられている場合、タグフィールドが一致し、 Request Completed ビットが 1 にセットされているコンプリーションディスクリプターを統合ブロックから受信するまで、ユーザーロジックはリクエストに割り当てられているタグを再度指定できません。

42:32Dword Count


これらの 11 ビットは、現在のパケットのペイロードサイズを示します (Dword)。範囲は 0 ～ 1000 Dword です。このフィールドは、 I/O 読み出しのコンプリーションについては 1 にセットされ、 I/O 書き込みのコンプリーションについては 1 にセットされます。また、長さ 0 のメモリ読み出しに対してコンプリーションを送信している間も 1 にセットされている必要があります。その他の場合、この Dword カウントは、その時点のパケットのペイロードの実際の Dword 数に相当します。

45:43Completion Status

(コンプリーションステータス)

これらのビットは、受信したコンプリーション TLP のコンプリーションステータスフィールドの設定を示します。有効な設定は次のとおりです。

• 000: トランザクションが正常に完了

• 001: サポートされないリクエスト (UR)

• 010: コンフィギュレーションリクエストのリトライステータス (CRS)

• 100: コンプリーターの中断 (CA)

46Poisoned Completion

(ポイズンコンプリーション)

このビットのセットにより、コンプリーション TLP の Poison ビットがセットされていることを示します。パケット内のデータが破損していると考えることができます。

63:48Requester ID

( リクエスター ID)コンプリーションに関連する PCI リクエスター ID です。

71:64 Tag (タグ) コンプリーションに関連する PCIe タグです。

87:72Completer ID

(コンプリーター ID)

コンプリーション TLP で受信されるコンプリーター ID です。 (これらの 16 ビットは、レガシインタープリテーションモードでは 8 ビットのバス番号、5 ビットのデバイス番号、 3 ビットのファンクション番号にわけられる。ARI モードの場合、これらの 16 ビットは 8 ビットのバス番号と 8 ビットのファンクション番号として扱われる。 )

91:89 Transaction Class (TC) コンプリーションに関連する PCIe トランザクションクラス (TC) です。

94:92 Attributes (属性)コンプリーションに関連する PCIe 属性です。ビット 92 は No Snoop ビット、ビット 93 は Relaxed Ordering ビット、ビット 94 は ID-Based Ordering ビットです。

表 3‐13: リクエスターコンプリーションディスクリプターのフィールド (続き)









図 3‐61: リクエスターコンプリーションインターフェイスでのデータを含まないコンプリーションの転送 (64 ビットインターフェイス)

user_clk



m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast

(byte_en[7:0]) m_axis_rc_tuser[7:0]

(is_sof_0) m_axis_rc_tuser[32]

(discontinue) m_axis_rc_tuser[42]


DESC 1

0x3 0x1 0x1

0 0



user_clk





m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast




DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

0x7 0x7

0 0






コンプリーション TLP をすべて転送するには、 256 ビットおよび 128 ビットインターフェイスの場合はシングルビート、 64 ビットインターフェイスの場合は 2 ビート必要です。統合ブロックは、パケットが送信される間、m_axis_rc_tvalid 信号をアサートしたままに保持する必要があります。ユーザーアプリケーションは、m_axis_rc_tready をディアサートしてビートを適時延ばすことができます。 AXI4-Stream インターフェイスの信号 m_axis_rc_tkeep (各 Dword 位置に 1 つ) がパケット内の有効なディスクリプター Dword を示します。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、 tkeep ビットは継続的に 1 にセットされます。パケット転送中、 tkeep ビットはパケットの後のビートでのみ 0 になることができます。 m_axis_rc_tlast 信号は必ずパケットの後のビートでアサートされます。

m_axi_rc_tuser バスには is_sof_0 信号も含まれており、すべてのパケットの初のビートでアサートされます。ユーザーアプリケーションは、オプションでこの信号を使用して、インターフェイス上のディスクリプターの開始を示すことができます。ストラドルオプションを使用しない場合、 m_axi_rc_tuser バス内のその他の信号は、データを含まないコンプリーションの転送に関連しません。

データを含むコンプリーションの転送

図 3-64、図 3-65、および図 3-66 のタイミング図は、 RC インターフェイスを介して、リンクから受信したペイロードを含むコンプリーション TLP の Dword アライメント転送を 64、 128、および 256 ビット別に示しています。説明用として、ユーザーアプリケーションメモリに書き込まれるデータブロックのサイズは n Dword と仮定し、n = k × 32 + 28 (k > 0) となります。このセクションのタイミング図では、 256 ビットインターフェイスでコンプリーションがストラドルされないことを仮定しています。ストラドル機能の詳細は、 176 ページの「256 ビットインターフェイスのストラドルオプション」を参照してください。



user_clk






m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast




DESC 0 DESC 0

DESC 1 DESC 1

DESC 2 DESC 2

0x07

0 0

0x07






Dword アライメントモードでは、転送は 3 ディスクリプター Dword から始まり、その直後にペイロード Dword が続きます。ディスクリプターとペイロードを含むすべての TLP は、 1 つの AXI4-Stream パケットとして転送されます。ペイロードの長さが 2 Dword を超える場合、ペイロード内のデータは常に連続するバイトストリームとなります。ペイロードの初の Dword 内の初の有効バイトと後の Dword 内の後の有効バイトの位置は、リクエスターコンプリーションディスクリプターの Lower Address フィールドと Byte Count フィールドから判断できます。ペイロードサイズが 2 Dword 以下の場合、ペイロード内の有効なバイトは連続しません。このような場合、ユーザーアプリケーションは RQ インターフェイスを介して送信される各リクエストに関連する First Byte Enable フィールドと Last Byte Enable フィールドを格納し、これらを使用してコンプリーションペイロード内の有効バイトを判断する必要があります。連続および非連続のペイロードの場合に、ユーザーアプリケーションはオプションで m_axi_rc_tuser バス内にあるバイトイネーブル出力 byte_en[31:0] を使用し、ペイロード内の有効バイトを判断できます。

統合ブロックは、パケットが送信される間、 m_axis_rc_tvalid 信号をアサートしたままに保持する必要があります。ユーザーアプリケーションは、 m_axis_rc_tready をディアサートしてビートを適時延ばすことができます。 AXI4-Stream インターフェイス信号 m_axis_rc_tkeep (各 Dword 位置に 1 つ) は、ディスクリプター、およびディスクリプターとペイロード間に挿入される NULL バイトを含む、パケットの有効な Dword を示します。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、 tkeep ビットは継続的に 1 にセットされます。パケットの転送中、インターフェイスの幅全体がパケットで埋められないときは、パケットの後のビートに限り tkeep ビットを 0 にできます。 m_axis_rc_tlast 信号は必ずパケットの後のビートでアサートされます。

m_axi_rc_tuser バスは、インターフェイスのユーザーアプリケーション側に関連するロジックを簡潔なものにするため、または追加の機能をサポートするために利用可能な情報信号をいくつか提供します。ディスクリプターがこのバス上にある場合、各パケットの初のビートで is_sof_0 信号がアサートされます。バイトイネーブル出力 byte_en[31:0] (各バイトレーンに 1 つ) はペイロードの有効バイトを示します。これらの信号は、有効なペイロードバイトが対応するレーンに存在する場合にのみアサートされます (ディスクリプターや NULL バイトに対してはアサートされない)。ペイロードサイズが 2 Dword 以下の場合を除き、アサートされたバイトイネーブルビットはペイロードの開始から常に連続します。 2 Dword 以下のコンプリーションペイロードの場合、 byte_en の 1 は連続しない場合があります。その他の特殊なケースとして、 byte_en ビットがすべて 0 にセットされて統合ブロックが 1 Dword のペイロードを転送するときの、長さ 0 のメモリ読み出しが挙げられます。つまり、あらゆるケースでユーザーロジックは byte_en 信号を直接使用することで、関連するバイトをメモリに書き込むことができます。

64 ビット /128 ビットインターフェイスおよびストラドルオプションが無効になっている 256 ビットインターフェイスでは、 m_axis_rc_tuser バス内の is_sof_1、 is_eof_0[3:0]、および is_eof_1[3:0] 信号は使用されません。


図 3‐64: リクエスターコンプリーションインターフェイスでのデータを含むコンプリーションの転送 (Dword アライメントモード、 64 ビットインターフェイス)

user_clk



m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast





DESC 0 DESC 2 DW 1 DW 1 DW n-1


0x3 0x3 0x3 0x1

0xF 0xF 0xF LAST BE

0 FIRST BE 0xF 0xF 0xF 0

0 0

X12223








user_clk





m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast










DW 0 DW 4 DW 8 DW 8

0xF 0xF 0xF 0x7

0 0xF 0xF 0xF

0 0xF 0xF 0xF


FIRST BE 0xF 0xF 0xF 0

X12224






図 3-67、図 3-68、および図 3-69 のタイミング図は、 RC インターフェイスを介して、リンクから受信したペイロードを含むコンプリーション TLP のアドレスアライメント転送を 64、 128、および 256 ビット別に示しています。サンプルタイミングの図では、送信されるデータブロックの開始 Dword (ディスクリプターの下位アドレスのビット [6:2] で伝搬) は (m × 8 + 1) と仮定されています (整数 m)。データブロックのサイズは n Dword と仮定し、n = k × 32 + 28 (k > 0) となります。アドレスアライメント転送では、ストラドルオプションが無効なため、このタイミング図は、 256 ビットインターフェイスでコンプリーションがストラドルされないことを仮定しています。

アドレスアライメントモードでは、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。ペイロードの初の有効バイトのアドレスに基づいて、ペイロードの初のバイトはどのバイトレーンにも出力できます。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、 tkeep ビットは継続的に 1 にセットされます。データバス上の初の Dword のアライメントは、ユーザーアプリケーションが統合ブロックへリクエストを送信したときのリクエスターリクエストインターフェイスの addr_offset[2:0] 入力の設定によって判断されます。ユーザーアプリケーションは、オプションでバイトイネーブル出力 byte_en[31:0] を使用してペイロード内の有効バイトを判断できます。



user_cl









m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast
















DW 2 DW 10 DW 10 DW n-2

DW 3 DW 11 DW 11 DW n-1

DW 4 DW 12 DW 12

0xFF 0xFF 0xFF 0x7F

0 0xFF 0xFF 0xFF

0 0xFF 0xFF 0xFF

0 0xFF 0xFF 0xFF

FIRST BE 0xFF 0xFF 0xFF

0xFF 0xFF 0xFF

0xFF 0xFF 0xFF

0xFF 0xFF 0xFF LAST BE

0xFF 0xFF 0xFF 0

X12225







図 3‐67: リクエスターコンプリーションインターフェイスでのデータを含むコンプリーションの転送 (アドレスアライメントモード、 64 ビットインターフェイス)



user_clk



m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast







0x3 0x3 0x3 0x1


0 FIRST BE FIRST BE 0xF 0xF 0

X12220

user_clk





m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast










DW 2 DW 6 DW 6

0xF 0xF 0xF 0x1


0 FIRST BE 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

X12221-061317








user_clk









m_axis_rc_tvalid

m_axis_rc_tready


m_axis_rc_tlast














DW 2 DW 10 DW 10 DW n-2

DW 3 DW 11 DW 11 DW n-1

DW 4 DW 12 DW 12

DW 5 DW 13 DW 13

DW 6 DW 14 DW 14

0xFF 0xFF 0xFF 0x1F

0 0xF 0xF 0xF

0 FIRST BE 0xF 0xF 0xF

0 0xF 0xF 0xF

0 0xF 0xF 0xF


0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

0 0xF 0xF 0xF 0

X12222






256 ビットインターフェイスのストラドルオプション

インターフェイス幅が 256 ビットにコンフィギュレーションされている場合は、前のコンプリーション終了時と同じビート、またはデータバス上の Dword 位置 3 の前で統合ブロックが RC インターフェイス上に新しいコンプリーションの転送を開始できます。ストラドルオプションは、 Dword アライメントモードの場合にのみ使用できます。

ストラドルオプションが有効に設定されている場合、コンプリーション TLP はパケット境界のない連続するストリームとして RC インターフェイスを介して転送されます (AXI4-Stream の観点から )。したがって、m_axis_rc_tkeep および m_axis_rc_tlast 信号は、このインターフェイスを介して送信されるコンプリーション TLP の境界を判断するのに有効ではありません (ストラドルオプションが使用されている場合、統合ブロックは m_axis_rc_tkeep をすべて 1、 m_axis_rc_tlast をすべて 0 にセットする )。その代わりに、m_axis_rc_tuser バス内の次の信号を使用して、 TLP のデリニエーション (輪郭を決定する ) が実行されます。

• is_sof_0: あるビートで開始するコンプリーション TLP が 1 つ以上ある場合、統合ブロックは、そのビートでこの出力をアクティブ High に駆動します。このコンプリーション TLP の初のバイトの位置は、次のように決定されます。

° 前のコンプリーション TLP が、現ビートの前で終了する場合、このコンプリーション TLP の初のバイトはバイトレーン 0 にあります。

° 前のコンプリーション TLP が、現ビートで継続している場合、このコンプリーション TLP の初のバイトはバイトレーン 16 にあります。この条件は、以前の TLP が現ビートで終了、つまり is_eof_0[0] もセットされている場合にのみ適用されます。

• is_sof_1: あるビートで開始するコンプリーション TLP が 2 つある場合、統合ブロックは、そのビートでこの出力を High に駆動します。初の TLP は常にバイト位置 0 で開始し、 2 つ目の TLP はバイト位置 16 で開始します。同じビート内でバイト位置 16 より前に以前の TLP が終了した場合 (同じビートで is_eof_0[0] がセットされている場合) のみ、統合ブロックは 2 番目の TLP をバイト位置 16 で開始します。

• is_eof_0[3:0]: これらの出力を使用して、コンプリーション TLP の終了とデータバス上における後の Dword 位置を示します。 is_eof_0[0] ビットのアサーションは、このビートで終了するコンプリーション TLP が 1 つ以上あることを示します。 is_eof_0 のビット 0 がセットされると、ビット [3:1] は現ビートで終了する TLP の後の Dword のオフセットを示します。後のバイトのオフセットは、 TLP の開始アドレスと長さ、あるいはバイトイネーブル信号 byte_en[31:0] から判断できます。あるビートで 2 つのコンプリーション TLP が終了する場合、 is_eof_0[3:1] の設定が初のコンプリーション TLP の後の Dword のオフセットとなります (この場合の範囲は 0 ～ 3)。

• is_eof_1[3:0]: is_eof_1[0] のアサートは、同じビートにおける 2 つ目の TLP の終了を示します。is_eof_1 のビット 0 がセットされると、ビット [3:1] は現ビートで終了する 2 番目の TLP の後の Dword のオフセットを示します。 2 番目の TLP は、バイトレーン 16 でのみ開始可能なため、範囲が 27 ～ 31 のバイトレーンでのみ終了できます。したがって、オフセット is_eof_1[3:1] は 2 つの値 (6 または 7) のいずれかとなります。 is_sof_1[0] がアクティブ High の場合、 is_eof_0[0] 信号と is_sof_0 信号も同じビート内でアクティブ High になります。 is_sof_1 がアクティブ High の場合、 is_sof_0 もアクティブ High になります。is_eof_1 がアクティブ High の場合、 is_eof_0 もアクティブ High になります。

図 3-70 に、ストラドルオプションが有効に設定された 256 ビット RC インターフェイスでの 4 つのコンプリーション TLP の転送を示します。初のコンプリーション TLP (COMPL 1) は、 BEAT 1 の Dword 位置 0 で開始し、 BEAT 3 の Dword 位置 0 で終了しています。 2 番目の TLP (COMPL 2) は、同じビートの Dword 位置 4 で開始しています。この 2 番目の TLP には 1 Dword ペイロードしか含まれていないため、これも同じビート内で終了します。コンプリーション 3 には 1 Dword ペイロードしか含まれておらず、コンプリーション 4 にはペイロードが含まれていないため、 3 番目と 4 番目のコンプリーション TLP は BEAT 4 ですべての転送が完了しています。







図 3‐70: ストラドルオプションが有効に設定されたリクエスターコンプリーションインターフェイスでのコンプリーション TLP の転送

user_clk









m_axis_rc_tvalid

m_axis_rc_tready



(is_eof_0[3:0]) m_axis_rc_tuser[37:34]

(is_eof_1[3:0]) m_axis_rc_tuser[41:38]










COMPL 1 COMPL 1 COMPL 1 COMPL 1 COMPL 3

COMPL 1 COMPL 1 COMPL 1 COMPL 3







00 0x1 0x7

00 0xF 0xD

0 0xF 0xF LAST BE 0

0 0xF 0xF 0

0 0xF 0xF 0

FIRST BE 0xF 0xF FIRST BE

0xF 0xF

0xF 0xF

0xF 0xF

0xF 0xF FIRST BE 0

00

00

00

BEAT 1 BEAT 2 BEAT 3 BEAT 4

X12229






コンプリーションの転送中断

関連するペイロードを含むリクエストの場合、転送されたペイロードにエラーがあると、統合ブロックは m_axis_rc_tuser バスの discontinue 信号をパケットの後のビートでアサートしてこのエラーを通知できます。これは、内部メモリからデータを読み出す間に統合ブロックが訂正不可能なエラーを検出したときに発生します。パケットの後のビートで discontinue 信号がアサートされたことを検出した場合、ユーザーアプリケーションはパケット全体を破棄する必要があります。これは、統合ブロックでは致命的エラーと認識されます。

ストラドルオプションが使用されている場合、統合ブロックは discontinue 信号をアサートしたビートで 2 番目のコンプリーション TLP を開始せず、そのビートで終了するコンプリーション TLP の転送を中断します。

コンプリーションエラーの対応

統合ブロックは、リンクからコンプリーション TLP を受信すると、対応するリクエストを判断するためにスプリットコンプリーションテーブル内の未処理リクエストと一致させ、それらのヘッダー内のフィールドと予想値を照らし合わせてあらゆるエラーを検出します。その後、統合ブロックはコンプリーションディスクリプターの一部としてユーザーアプリケーションへ送信する 4 ビットのエラーコードでエラー状況を通知します。また、統合ブロックは、ディスクリプターの Request Completed ビット (ビット 30) をセットして、特定リクエストの後のコンプリーションを示します。表 3-14 に、さまざまなエラーコードが示すエラー状況について説明しています。

表 3‐14: エラーコードのエンコード

エラーコード説明

0000 エラーは検出されていないことを示します。

0001

リンクから受信したコンプリーション TLP にエラーがあることを示します。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。さらに、ディスクリプターの Request Completed ビットがセットされていない場合は、 Request Completed ビットがセットされたコンプリーションディスクリプターを受信するまで、このタグの後続コンプリーションに対応するデータを破棄し続ける必要があります。 Request Completed ビットがセットされたコンプリーションディスクリプターを受信すると、ユーザーアプリケーションは対応するリクエストのすべてのステートを削除できます。

0010

リクエストは UR、 CA、または CRD ステータスを含むコンプリーション TLP で終了しています。この場合、コンプリーションに関連するデータはなく、コンプリーションディスクリプターの Request Completed がセットされています。そのようなコンプリーションを統合ブロックから受信すると、ユーザーアプリケーションは対応するリクエストを破棄できます。

0011

読み出しリクエストが不正なバイトカウントのコンプリーション TLP で終了しています。バイトカウントが予想値と一致しないコンプリーション TLP が受信されると、このエラーコードが通知されます。コンプリーションディスクリプターの Request Completed ビットはセットされています。そのようなコンプリーションを統合ブロックから受信すると、ユーザーアプリケーションは対応するリクエストを破棄できます。

0100

このコードは、送信されている現在のコンプリーションには、未処理リクエストと同じタグがあるが、その Requester ID、 TC、または Attribute フィールドが未処理リクエストのパラメーターと一致していないことを示します。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。さらに、ディスクリプターの Request Completed ビットがセットされていない場合は、 Request Completed ビットがセットされたコンプリーションディスクリプターを受信するまで、このタグの後続コンプリーションに対応するデータを破棄し続ける必要があります。 Request Completed ビットがセットされたコンプリーションディスクリプターを受信すると、ユーザーアプリケーションは対応するリクエストのすべてのステートを削除できます。






タグが統合ブロックの内部で管理される場合、統合ブロック内のロジックによって、そのリクエストのすべてのコンプリーションが受信されるまで、あるいはリクエストがタイムアウトするまで、ペンディングリクエストに割り当てられたタグが再び使用されることはありません。

ただし、タグがユーザーアプリケーションで管理される場合は、ユーザーアプリケーションがコンプリーションディスクリプターの Request Completed ビットをセットして、統合ブロックがリクエストの終了を示すまで、そのリクエストに割り当てられたタグが再び使用されないようにする必要があります。ユーザーアプリケーションは、0 以外のエラーコードを含むコンプリーションを受信した場合にペンディングリクエストを終了できますが、コンプリーションディスクリプターの Request Completed ビットがセットされていない限り、関連するタグをリリースできません。あるリクエストが複数のスプリットコンプリーションを受信し、それらのいずれかにエラーが検出された場合にこのような状況が適用されます。この場合、統合ブロックは、エラーが検出された後であってもペンディングリクエストに対するコンプリーション TLP を継続して受信できますが、タグが早期に再度割り当てられると、これらのコンプリーションが別のリクエストと不正に一致してしまいます。場合によっては、エラーを含むスプリットコンプリーションが受信された場合でもタグの再使用が可能になるまで、統合ブロックはリクエストがタイムアウトするまで待機する必要があります。

0101

開始アドレスのエラー。コンプリーション TLP ヘッダーの下位アドレスが、そのリクエストの次に予想されるバイトの開始アドレスと一致していない。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。さらに、ディスクリプターの Request Completed ビットがセットされていない場合は、 Request Completed ビットがセットされたコンプリーションディスクリプターを受信するまで、このタグの後続コンプリーションに対応するデータを破棄し続ける必要があります。 Request Completed ビットがセットされたコンプリーションディスクリプターを受信すると、ユーザーアプリケーションは対応するリクエストのすべてのステートを破棄できます。

0110無効なタグ。このエラーコードは、コンプリーション TLP のタグが未処理リクエストのタグと一致していないことを示します。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。

0111

バイトカウントが無効であることを示します。コンプリーションのバイトカウントがそのリクエストに対して予測されている合計バイト数を超えています。このとき、コンプリーションディスクリプターの Request Completed ビットもセットされています。そのようなコンプリーションを統合ブロックから受信すると、ユーザーアプリケーションは対応するリクエストを破棄できます。

1001

コンプリーションタイムアウトでリクエストが終了した。リンクからコンプリーションを受信せずに未処理リクエストがタイムアウトした場合に、このエラーコードが使用されます。統合ブロックは、各未処理リクエストに対してコンプリーションタイマーを保持し、リクエスターコンプリーションインターフェイスを介してユーザーアプリケーションにダミーのコンプリーションディスクリプターを送信することによって、コンプリーションのタイムアウトに対応します。このため、ユーザーアプリケーションはペンディングリクエストを終了したり、リクエストを再送信できます。このディスクリプターは、リンクから受信したコンプリーション TLP に対応しないため、 Request Completed ビット (ビット 30)、タグフィールド (ビット [71:64])、およびリクエスターファンクションフィールド (ビット [55:48]) のみがこのディスクリプターで有効となります。

1000

リクエストを生成したファンクションをターゲットとする Function-Level Reset (FLR) によってリクエストが終了したことを示します。この場合、統合ブロックはリクエスターコンプリーションインターフェイスを介してユーザーアプリケーションへダミーのコンプリーションディスクリプターを送信するため、ユーザーアプリケーションはペンディングリクエストを終了できます。このディスクリプターは、リンクから受信したコンプリーション TLP に対応しないため、Request Completed ビット (ビット 30)、タグフィールド (ビット [71:64])、リクエスターファンクションフィールド (ビット [55:48]) のみがこのディスクリプターで有効となります。

表 3‐14: エラーコードのエンコード (続き)

エラーコード説明






パワーマネージメント

コアは、次のパワーマネージメントモードをサポートします。

• Active State Power Management (ASPM)

• Programmed Power Management (PPM)

PCI Express デザインの一部としてこれらのパワーマネージメント機能をインプリメントすると、 PCI Express の階層でシステム電力節約のためパワーマネージメントに関するメッセージがスムーズに交信できるようになります。パワーマネージメントメッセージ ID 機能がすべてインプリメントされています。次のセクションでは、上記のパワーマネージメントモードをサポートするためのユーザーロジックの定義について説明します。

ASPM および PPM インプリメンテーションの詳細は、『PCI Express Base Specification』 [参照 2] を参照してください。

Active State Power Management (ASPM)

コアは、 L0s ステートから遷移するときに N_FTS 値を 255 として示し、確実なアライメントを行います。 N_FTS 値が変更される場合は、適切なアライメントを行うために十分な FTS シーケンスを受信して、リカバリステートへ遷移しないようにする必要があります。

Active State Power Management (ASPM) は、ユーザーロジック機能から見ると、自律型のトランスペアレントな機能です。コアは ASPM に必要なコンディションをサポートしており、統合ブロックは ASPM L0s および ASPM L1 をサポートしています。 L0s と L1 を同時に有効にはできません。

注記: APSM は、非同期クロッキングモードではサポートされていません。

注記: L0s は、 Gen3 対応デザインではサポートされていません。 Gen1 および Gen2 用に生成されたデザインでのみサポートされています。

Programmed Power Management (PPM)

PCI Express の階層で大幅に電力を節約するために、コアは Programmed Power Management (PPM) の次のリンクステートをサポートしています。

• L0: アクティブステート (データ交信ステート )

• L1: レイテンシが高く、低電力のスタンバイステート

• L3: リンクオフステート

PPM プロトコルは、ダウンストリームコンポーネント /アップストリームポートによって開始されます。

PPM L0 ステート

L0 ステートは通常動作を表し、ユーザーロジックに対しトランスペアレントです。初期化され、プロトコルに基づいた PCI Express リンクのトレーニング完了後、コアは L0 (アクティブステート ) に到達します。






PPM L1 ステート

コアから PPM L1 ステートへの遷移は次の順序で発生します。

1. 低電力の PPM L1 ステートへの遷移は、PCI Express デバイスの電力ステートを D3-hot (または D1 および D2 がサポートされている場合は、これらのいずれか) にプログラムすることで、常にアップストリームデバイスによって開始されます。

2. デバイスの電力ステートは、 cfg_function_power_state 出力を使用して、ユーザーロジックへ伝達されます。

3. この後、コアは s_axis_rq_tready をディアサートし、ユーザーロジックがユーザーインターフェイスで新たなトランザクションを開始しないように、ユーザーロジックをスロットル/中断させます。しかし、ユーザーインターフェイスでのペンディングトランザクションは完全に受信され、後で完了することができます。

この場合、例外が 2 つあります。

° コアがエンドポイントとしてコンフィギュレーションされていて、ユーザーコンフィギュレーション空間がイネーブルになっている場合。このとき、 cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエスト TLP を送信できませんが、ユーザーコンフィギュレーション空間をターゲットにしたコンフィギュレーショントランザクションに対してはコンプリーションを返すことができます。

° コアがルートポートとしてコンフィギュレーションされている場合。この状況で準拠を保つには、cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエストを送信すべきではありません。

4. コアは、パワーマネージメント用の適切な DLLP をリンクパートナーに対して送受信して、リンクを低電力 PPM L1 ステートへ遷移させます。これはユーザーロジックにはトランスペアレントです。

5. 手順 3 で説明されている例外を除き、デバイスの電力ステートが D0 以外になっている間は、すべてのユーザートランザクションが中断されます。

PPM L3 ステート

PCI Express のエンドポイントから PPM L3 ステートへの遷移は次の順序で発生します。

1. アップストリームのリンクパートナーから PME_Turn_Off メッセージを受信すると、コアは L23 Ready (準備完了) リンクステートへの遷移を開始します。

2. PME_Turn_Off メッセージを受信すると、コアは cfg_power_state_change_interrupt を介してユーザーロジックとのハンドシェイク (表 3-15 を参照) を開始し、ユーザーロジックから cfg_power_state_change_ack の応答を待機します。

3. ハンドシェイクが成功すると、パワーマネージメントをオフにする承認メッセージ (PME-turnoff_ack) がコアからアップストリームリンクパートナーへ送信されます。

4. コアはインターフェイスをすべて閉じ、物理層/データリンク層/ トランザクション層を無効にして、コアに対するパワーオフの準備を整えます。

この場合、例外が 2 つあります。

° コアがエンドポイントとしてコンフィギュレーションされていて、ユーザーコンフィギュレーション空間がイネーブルになっている場合。このとき、 cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエスト TLP を送信できませんが、ユーザーコンフィギュレーション空間をターゲットにしたコンフィギュレーショントランザクションに対してはコンプリーションを返すことができます。

° コアがルートポートとしてコンフィギュレーションされている場合。この状況で準拠を保つには、cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエストを送信すべきではありません。






パワーダウン交渉は、次の手順で行われます。

1. 電源とクロックがオフになる前に、ダウンストリームスイッチのルートコンプレックスまたはホットプラグコントローラーが PME_Turn_Off ブロードキャストメッセージを出力します。

2. コアがこの TLP を受信すると、ユーザーアプリケーションに cfg_power_state_change_interrupt をアサートし、 cfg_power_state_change_ack 入力をポーリングします。

3. ユーザーアプリケーションは、 cfg_to_turnoff のアサートを検出すると、処理中のパケットをすべて完了し、新しいパケットの生成を停止する必要があります。ユーザーアプリケーションがオフになる準備が整った後、コアに対して cfg_power_state_change_ack をアサートします。 cfg_power_state_change_ack のアサート後、ユーザーアプリケーションのオフが確約されます。

4. コアは cfg_power_state_change_ack のアサートを検出すると、 PME_TO_Ack メッセージを送信します。

表 3‐15:パワーマネージメントのハンドシェイク信号

ポート名方向説明

cfg_power_state_change_interrupt 出力

アップストリームデバイスからパワーダウンリクエスト TLP を受信した場合にアサートされます。その後、ユーザーアプリケーションが cfg_power_state_change_ack をアサートするまで、cfg_power_state_change_interrupt はアサート状態を保持する必要があります。

cfg_power_state_change_ack 入力安全にパワーダウンできる場合に、ユーザーアプリケーションによってアサートされます。


図 3‐71:パワーマネージメントのハンドシェイク : 64 ビット

user_clk_out

rx_data[63:0]*

cfg_to_turnoff

cfg_turnoff_ok

tx_data[63:0]*

PME_Turn_Off

PME_TO_ACK

* Internal signal not appearing on User Interface

X12465






割り込みリクエストの生成

51 ページの表 2-19 に示す cfg_interrupt_msi* および cfg_interrupt_msix_* の説明を参照してください。

注記: このセクションは UltraScale Devices Gen3 Integrated Block for PCIe コアのエンドポイントコンフィギュレーションのみを対象にしています。

統合ブロックは、割り込みリクエストをレガシ、メッセージ MSI、または MSI-X 割り込みとして送信できます。動作モードは、 MSI Capability Structure (MSI 機能構造体) にあるメッセージ制御レジスタの MSI イネーブルビットおよび MSI-X Capability Structure (MSI-X 機能構造体) にある MSI-X メッセージ制御レジスタの MSI-X イネーブルビットを使用してプログラムされます。 MSI 機能構造体および MSI-X 機能構造体の詳細は、『PCI Local Base Specification v3.0』のセクション 6.8 を参照してください。

MSI Enable および MSI-X Enabled ビットのステートは、 cfg_interrupt_msi_enable 出力および cfg_interrupt_msix_enable 出力により、ぞれぞれ反映されます。表 3-16 は、コアの cfg_interrupt_msi_enable 出力および cfg_interrupt_msix_enable 出力に基づいてプログラムされている割り込みモードについて説明しています。

MSI 制御レジスタの MSI イネーブルビット、MSI-X 制御レジスタの MSI-X イネーブルビット、PCI コマンドレジスタの Interrupt Disable ビットは、ルートコンプレックスによってプログラムされます。ユーザーアプリケーションでは、これらのビットを直接制御しません。

コアの内部割込みコントローラーは、レガシ割り込みと MSI 割り込みのみ生成します。 MSI-X 割り込みは、ユーザーアプリケーションで生成され、送信 AXI4-Stream インターフェイスに現れる必要があります。cfg_interrupt_msi_enable のステータスが内部割込みコントローラーで生成される割り込みタイプを決定します。

MSI イネーブルビットが 1 の場合は、コアがメモリ書き込み TLP を送信して MIS リクエストを生成します。 MSI イネーブルビットが 0 の場合は、 PCI コマンドレジスタの Interrupt Disable ビットが 0 にセットされている限り、コアはレガシ割り込みメッセージを生成します。

• cfg_interrupt_msi_enable = 0: レガシ割り込み

• cfg_interrupt_msi_enable = 1: MSI

• コマンドレジスタのビット 10 = 0: INTx 割り込みが有効

• コマンドレジスタのビット 10 = 1: INTx 割り込みは無効 ( リクエストはコアによってブロックされる )

ユーザーアプリケーションは cfg_function_status をモニタリングして、 INTx 割り込みが有効または無効であるかを確認できます。詳細は、表 2-12 を参照してください。

ユーザーアプリケーションは 2 つの方法で割り込みを要求します。これらの方法は次のセクションで説明します。

表 3‐16:割り込みモード

cfg_interrupt_msixenable=0 cfg_interrupt_msixenable=1

cfg_interrupt_msi_enable=0

レガシ割り込み (INTx) モード。

cfg_interrupt インターフェイスは INTx メッセージのみ送信します。

MSI-X モード。

cfg_interrupt インターフェイスを使用して MSI-X 割り込みを生成できます。

cfg_interrupt_msi_enable=1

MSI モード。 cfg_interrupt インターフェイスは MSI 割り込み (MWr TLP) のみ送信します。

未定義。

このモードは、システムソフトウェアでサポートされていません。ただし、 cfg_interrupt インターフェイスをアクティブにして MSI 割り込み (MWr TLP) を送信できます (任意で選択)。






レガシ割り込みモード

• ユーザーアプリケーションは、割り込み信号をアサートするために、まず cfg_interrupt_int および cfg_interrupt_pending をアサートします。

• その後、コアが cfg_interrupt_sent をアサートして、割り込みが受信されたことを示します。 PCI コマンドレジスタの Interrupt Disable ビットが 0 にセットされている場合は、コアがアサート割り込みメッセージ (Assert_INTA) を送信します。次のクロックサイクルでユーザーアプリケーションは cfg_interrupt_int をディアサートします。

• ユーザーアプリケーションが cfg_interrupt_int をディアサートした後、コアはディアサート割り込みメッセージ (Deassert_INTA) を送信します。これは、 cfg_interrupt_sent の 2 回目のアサートで示されます。

ユーザーアプリケーションがアサート割り込みメッセージ (Assert_INTA) の確認信号を受信するまで cfg_interrupt_int をアサートする必要があります。この確認は cfg_interrupt_sent のアサートによって示され、割り込みはルートの割り込みサービスルーチン (ISR) によって処理/クリアされています。cfg_interrupt_int をディアサートすると、コアはディアサート割り込みメッセージ (Deassert_INTA) を送信します。 cfg_interrupt_pending は cfg_interrupt_int 信号のアサートと同時にアサートし、割り込みが処理されるまでアサートしておく必要があります。そうでなければ、ステータスレジスタの割り込みステータスビットが正しく更新されません。アサート割り込みメッセージの受信時、ソフトウェア/ルートの ISR はこの割り込みステータスを読み出してこの機能に対する割り込みペンディングが存在するかどうかを判断します。

MSI モード

図 3-72 に示すとおり、ユーザーアプリケーションは cfg_interrupt_msi_int の値を初にアサートします。コアは、 cfg_interrupt_msi_sent をアサートして割り込みが受け入れられたことを示し、 MSI メモリ書き込み TLP を送信します。


図 3‐72: レガシ割り込みの信号

cfg_interrupt_msi_enable

cfg_interrupt_int[3:0]

cfg_interrupt_pending[1:0]

cfg_interrupt_sent

4'h01 4'h0 4'h01

2'b01 2'b00

X13127


図 3‐73: MSI モード






MSI リクエストは、32 ビットのアドレス指定可能なメモリ書き込み TLP または 64 ビットのアドレス指定可能なメモリ書き込み TLP のいずれかです。アドレス値は、 MSI 機能構造体の Message Address フィールドと Message Upper Address フィールドから取得し、ペイロードは Message Data フィールドから取得します。これらの値は、 MSI 機能構造体へのコンフィギュレーション書き込みによってシステムソフトウェアでプログラムされます。コアがマルチベクター MSI 用にコンフィギュレーションされている場合、 Multiple Message Enable フィールドに 0 以外の値をプログラムすることで、システムソフトウェアはマルチベクター MSI メッセージを許可することができます。

送信される MSI TLP のタイプ (32 ビットまたは 64 ビットのアドレス指定可能なもの) は、 MSI 機能構造体の Upper Address フィールドの値によって変わります。デフォルトでは MSI メッセージは 32 ビットのアドレス指定可能なメモリ書き込み TLP として送信されます。上位アドレスレジスタに 0 以外の値がシステムソフトウェアによってプログラムされている場合のみ、 MSI メッセージは 64 ビットのアドレス指定可能なメモリ書き込み TLP を使用します。

マルチベクター MSI メッセージが有効場合、アップストリームに送信されたさまざまな MSI メッセージを区別するため、送信された MSI TLP の各 Message Data フィールドの 1 つまたは複数の下位ビットをユーザーアプリケーションが上書きできます。 Message Data フィールドにあるユーザーアプリケーションで使用可能な下位ビット数は、 IP カタログで設定されている Multiple Message Capable フィールドの値、システムソフトウェアで設定されている Multiple Message Enable フィールドの値、および cfg_interrupt_msi_mmenable[2:0] コア出力で使用できる値の中でも小さい値によって決定されます。コアは cfg_interrupt_msi_select 内のビットをマスクしますが、これらはシステムソフトウェアで Multiple Message Enable を使用して設定されません。

必要なプロセスを示したサンプルコードは次のとおりです。

// Value MSI_Vector_Num must be in range: 0 MSI_Vector_Num (2^cfg_interrupt_mmenable)-1

if (cfg_interrupt_msienable) { // MSI Enabledif (cfg_interrupt_mmenable > 0) { // Multi-Vector MSI Enabled

cfg_interrupt_msi_int[MSI_Vector_Num] = 1;} else { // Single-Vector MSI Enabledcfg_interrupt_msi_int[MSI_Vector_Num] = 0;

}} else {

// Legacy Interrupts Enabled}

例:

1. cfg_interrupt_mmenable[2:0] == 000b、つまり 1 つの MSI ベクターが有効の場合、 cfg_interrupt_msi_int = 01h となります。

2. cfg_interrupt_mmenable[2:0] == 101b、つまり 32 の MSI ベクターが有効の場合、 cfg_interrupt_msi_int = {32'b1 << {MSI_Vector#}} となります。

MSI_Vector# が 5 ビット値ならば、 00000b MSI_Vector# 11111b となることが可能です。

ベクターごとのマスキング (Per-Vector Masking) が有効になっている場合は、送信されているべクターがマスクレジスタでマスクされていないことをまず確認する必要があります。コンフィギュレーションインターフェイスでこのレジスタを読み出すことでこの確認はできます (コアはマスクレジスタを確認しない)。






MSI‐X モード

UltraScale Devices Gen3 Integrated Block for PCIe コアは、図 3-74 に示す MSI-X 割り込みとそのシグナリングをオプションでサポートします。 MSI-X ベクターテーブルと MSI-X Pending Bit Array は、ロジックの一部として BAR のアパーチャを利用してインプリメントする必要があります。

受信メッセージインターフェイス

ユーザーアプリケーションは、コアが提供する独立した受信メッセージインターフェイスを使用して、リンクから受信したメッセージ情報を受け取ることができます。受信メッセージインターフェイスが有効に設定されている場合、統合ブロックは、メッセージタイプ (表 3-17) を示す cfg_msg_received_type[4:0] 出力を設定して cfg_msg_received 信号を 1 サイクルまたは複数サイクル間パルスし、リンクからメッセージが到達したことを伝達します。 cfg_msg_received のアサートサイクル数は、受信するメッセージタイプによって異なります (表 3-18 を参照)。 cfg_msg_received がアクティブ High のとき、統合パラメーターは、cfg_msg_received_data バス上にメッセージに関する任意のパラメーターを 1 回につき 8 ビットで転送します。表 3-18 では、 cfg_msg_received がアサートされる各サイクルで、このバスに転送されるパラメーターをメッセージタイプ別に示しています。ベンダーが指定するメッセージの場合、統合ブロックはこのインターフェイスを介して関連するペイロードの初の Dword のみ転送します。さらに大規模なペイロードが使用される場合は、メッセージの転送にコンプリーターリクエストインターフェイスを使用する必要があります。


図 3‐74: MSI‐X モード

cfg_interrupt_msix_enable

cfg_interrupt_msix_address[63:0]

cfg_interrupt_msix_data[31:0]

cfg_interrupt_msix_int

cfg_interrupt_msix_sent

cfg_interrupt_msix_function_number[2:0]

X14336

表 3‐17:受信メッセージインターフェイスのメッセージタイプエンコード

cfg_msg_received_type[4:0] メッセージタイプ

0 ERR_COR

1 ERR_NONFATAL

2 ERR_FATAL

3 Assert_INTA

4 Deassert_ INTA

5 Assert_INTB

6 Deassert_ INTB

7 Assert_INTC

8 Deassert_ INTC

9 Assert_INTD

10 Deassert_ INTD






11 PM_PME

12 PME_TO_Ack

13 PME_Turn_Off

14 PM_Active_State_Nak

15 Set_Slot_Power_Limit

16 LTR (Latency Tolerance Reporting)

17 OBFF (Optimized Buffer Flush/Fill)

18 アンロック



21 ATS 無効なリクエスト

22 ATS 無効なコンプリーション

23 ATS ページリクエスト

24 ATS PRG 応答

25 ～ 31 予約

表 3‐18:受信メッセージインターフェイスのメッセージパラメーター

メッセージタイプcfg_msg_received のアサートサイクル数

cfg_msg_received_data[7:0] で転送されるパラメーター

ERR_COR、 ERR_NONFATAL、ERR_FATAL

2サイクル 1: リクエスター ID、バス番号

サイクル 2: リクエスター ID、デバイス/ファンクション番号

Assert_INTx、 Deassert_INTx 2サイクル 1: リクエスター ID、バス番号


PM_PME、 PME_TO_Ack、PME_Turn_off、

PM_Active_State_Nak2

サイクル 1: リクエスター ID、バス番号


Set_Slot_Power_Limit 6



サイクル 3: ペイロードのビット [7:0]




LTR (Latency Tolerance Reporting)

6



サイクル 3: スヌープレイテンシのビット [7:0]

サイクル 4: スヌープレイテンシのビット [15:8]

サイクル 5: ノースヌープレイテンシのビット [7:0]

サイクル 6: ノースヌープレイテンシのビット [15:8]

表 3‐17:受信メッセージインターフェイスのメッセージタイプエンコード (続き)

cfg_msg_received_type[4:0] メッセージタイプ






図 3-75 に、受信メッセージインターフェイスでの Set_Slot_Power_Limit メッセージ例を示すタイミング図を示します。このメッセージには、関連する 1 Dword ペイロードが含まれています。このメッセージでは、連続する 6 サイクル間でパラメーターが送信されます。各サイクルで cfg_msg_received_data バスに次の情報が現れます。

• サイクル 1: リクエスター ID のバス番号

• サイクル 2: リクエスター ID のデバイス番号/ファンクション番号

• サイクル 3: ペイロード Dword のビット [7:0]




OBFF (Optimized Buffer Flush/Fill)

3



サイクル 3: OBFF コード

アンロック 2サイクル 1: リクエスター ID、バス番号


Vendor_Defined タイプ 0

データがない場合は 4 サイクル、

データがある場合は 8 サイクル



サイクル 3: ベンダー ID[7:0]






Vendor_Defined タイプ 1

データがない場合は4 サイクル、

データがある場合は 8 サイクル









ATS 無効なリクエスト 2サイクル 1: リクエスター ID、バス番号


ATS 無効なコンプリーション 2サイクル 1: リクエスター ID、バス番号


ATS ページリクエスト 2サイクル 1: リクエスター ID、バス番号


ATS PRG 応答 2サイクル 1: リクエスター ID、バス番号


表 3‐18:受信メッセージインターフェイスのメッセージパラメーター (続き)

メッセージタイプcfg_msg_received のアサートサイクル数

cfg_msg_received_data[7:0] で転送されるパラメーター






統合ブロックは、 cfg_msg_received 出力の有効なパルス間に 1 サイクル以上のギャップを挿入します。受信メッセージインターフェイスを介して送信されるメッセージ表示にはバックプレッシャーを適用するメカニズムがありません。このインターフェイスを使用する場合、ユーザーロジックは常にメッセージ表示を受信する準備が整っている必要があります。

コンフィギュレーションマネージメントインターフェイス

コンフィギュレーションレジスタで使用されるポートについては、 25 ページの表 2-12 で説明しています。ルートポートは、コンフィギュレーション空間を構築するためにコンフィギュレーションポートを使用する必要があります。エンドポイントもコンフィギュレーションポートを使用して、読み出し /書き込みを実行できます。ただし、システムに悪影響を及ぼす原因を回避するよう注意が必要です。

ユーザーは、バイトアドレスではなく Dword アドレスとしてアドレスを提供する必要があります。

ヒント : バイトアドレスを 4 で割ると、レジスタ用の Dword アドレスを算出できます。

例:

PCI コンフィギュレーション空間ヘッダーのコマンド /ステータスレジスタ :

• Dword アドレスは 01h

注記:バイトアドレスは 04h

BAR0:

• Dword アドレスは 04h

注記:バイトアドレスは 10h

コンフィギュレーション空間のレジスタ値を読み出すため、ユーザーアプリケーションは cfg_mgmt_addr[9:0] にレジスタ Dword アドレスを駆動します。 cfg_mgmt_addr[17:10] では、そのコンフィギュレーションレジスタに関連する PCI ファンクションを選択します。コアは、アドレス指定したレジスタの内容を cfg_mgmt_read_data[31:0] に駆動します。 cfg_mgmt_read_data[31:0] の値は、cfg_mgmt_read_write_done のアサート信号で受信されたことを確認できます。図 3-76 に、コンフィギュレーション空間の読み出し動作の信号を例示します。


図 3‐75: [Receive Message Interface]

user_clk

cfg_msg_received

cfg_msg_received_type[4:0]

cfg_msg_received_data[7:0]

0xF

Bus Dev/Fn PL[7:0] PL[15:8] PL[31:24]PL[23:16]

X12344






コンフィギュレーション空間のレジスタに書き込みを実行するには、ユーザーロジックが cfg_mgmt_addr バスにアドレス、 cfg_mgmt_write_data に書き込みデータ、 cfg_mgmt_byte_enable [3:0] にバイトイネーブルを駆動し、 cfg_mgmt_write 信号をアサートします。それに対応して、書き込み動作が完了すると、コアが cfg_mgmt_read_write_done 信号をアサートします (数サイクル必要)。ユーザーロジックは、cfg_mgmt_read_write_done がアサートされるまで、 cfg_mgmt_addr、 cfg_mgmt_write_data、cfg_mgmt_byte_enable および cfg_mgmt_write を安定に維持する必要があります。また、コアが cfg_mgmt_read_write_done 信号をアサートした次のサイクルでユーザーロジックは cfg_mgmt_write をディアサートする必要があります。

コアをルートポートモードでコンフィギュレーションしている場合、 Type-1 PCI™ コンフィギュレーションレジスタへの書き込み中に cfg_mgmt_type1_cfg_reg_access 入力をアサートすると、このレジスタの特定の読み出し専用フィールドへの書き込みが強制されます。


図 3‐76: cfg_mgmt_read_type0_type1


図 3‐77: cfg_mgmt_write_type0

user_clk

cfg_mgmt_addr

cfg_mgmt_write

cfg_mgmt_write_data

cfg_mgmt_byte_enable

cfg_mgmt_read_write_done

cfg_mgmt_read

cfg_mgmt_read_data

cfg_mgmt_type1_cfg_reg_access

X14333

user_clk

cfg_mgmt_addr

cfg_mgmt_write

cfg_mgmt_write_data

cfg_mgmt_byte_enable

cfg_mgmt_read_write_done

cfg_mgmt_read

cfg_mgmt_read_data

cfg_mgmt_type1_cfg_reg_access






リンクトレーニング: 2 レーン、 4 レーン、および 8 レーンコンポーネント

2 レーン、 4 レーン、 8 レーンのコアは、『PCI Express Base Specification』 [参照 2] で規定されている大レーン幅未満で動作可能です。次のサブセクションで定義されているように、指定されている大レーン幅未満でコアが動作するケースは 2 つあります。

リンクパートナーが少ないレーン数をサポートする場合

2 レーンコアが 1 レーンのみをインプリメントするデバイスに接続されている場合、このコアはレーン 0 を使用して 1 レーンデバイスとしてリンクを確立して動作します。

4 レーンコアが 1 レーンのみをインプリメントするデバイスに接続されている場合、図 3-79 に示すようにこのコアはレーン 0 を使用して、 1 レーンデバイスとしてリンクを確立して動作します。同様に、 4 レーンコアが 2 レーンデバイスに接続されている場合、このコアはレーン 0 および 1 を使用して 2 レーンデバイスとしてリンクを確立して動作します。

8 レーンコアが 4 レーンのみをインプリメントするデバイスに接続されている場合、このコアはレーン 0 から 3 を使用して、 4 レーンデバイスとしてリンクを確立して動作します。また、接続されているデバイスが 1 または 2 レーンのみをインプリメントする場合、この 8 レーンコアは 1 レーンまたは 2 レーンデバイスとしてリンクを確立して動作します。


図 3‐78: cfg_mgmt_debug_access






レーンにエラーが発生した場合

コアおよびリンクパートナーデバイスでサポートされている大レーン幅にリンクトレーニングを行った後にリンクにエラーが発生すると、コアは回復を試み、可能であれば小さいレーン幅でリンクトレーニングを実行します。レーン 0 にエラーが発生した場合、リンクは回復不可能となり失われます。レーン 1 から 7 のいずれか、またはすべてにエラーが発生した場合、リンクは回復モードに遷移し、まだ動作しているレーンを使用して回復可能な大レーンを回復しようとします。

たとえば、 8 レーンコアを使用する場合、レーン 1 が損失すると回復措置が取られレーン 0 で 1 レーン動作になりますが、レーン 6 が損失するとレーン 0 から 3 で 4 レーン動作になります。回復措置後、エラーの発生したレーンが再び動作可能な状態になっても、コアは大きいリンク幅へと回復措置を取ろうとはしません。値の大きいほうのリンク幅へ回復措置が取られるのは、リンクがダウンし初からリンクトレーニングを行う場合のみです。

user_clk クロック出力は IP カタログで設定された固定周波数になります。リンクの回復またはリンクトレーニングのダウンが発生しても user_clk の周波数は変更されません。


図 3‐79: 4 レーンエンドポイントブロックの動作 (4 レーンから 1 レーン)

Lane 0 Lane 3Lane 2Lane 1

4-lane Downstream Port



1-lane Downstream Port


4-lane Integrated Block 4-lane Integrated Block

Upstream DeviceUpstream Device

X12470






レーン反転

統合ブロックは、限定的なレーン反転機能をサポートし、リンクパートナーに対して柔軟なボードデザインを提供します。リンクパートナーは反転されたレーン番号でボードをレイアウトするよう選択でき、統合ブロックはリンクトレインを継続し、通常どおりに動作します。レーン反転をサポートするコンフィギュレーションは x8 および x4 です (ダウンシフトモードを除く )。ダウンシフトとは、各リンクパートナーがそれぞれ異なるリンク幅機能を持つ場合に発生するリンク幅交渉プロセスを指します。リンク幅交渉の結果、リンクパートナーはレーン幅のうち値の小さいほうに交渉を成立させます。表 3-19 には、ダウンシフトモードを含むさまざまな組み合わせ、およびレーン反転サポートの有無がまとめられています。

表 3‐19: レーン反転サポート

統合ブロックの可能なレーン幅

交渉されるレーン幅

レーン番号のマッピング(エンドポイントリンクパートナー ) レーン反転

サポートエンドポイントリンクパートナー

x8 x8 レーン 0...レーン 7 レーン 7...レーン 0 あり

x8 x4 レーン 0...レーン 3 レーン 7...レーン 4 なし (1)





x2 x1 レーン 0...レーン 1 レーン 1 なし (1)

注記:1. レーンがボードレイアウトで反転され、ダウンシフトアダプターカードがエンドポイントとリンクパートナーの間に挿入さ

れている場合、リンクパートナーのレーン 0 は接続されないままとなり (この表のレーンマッピングを参照)、リンクは確立さ

れません。





第 4章

デザインフローの手順この章では、コアのカスタマイズと生成、制約、およびシミュレーション/合成/インプリメンテーションの手順について説明します。一般的な Vivado® デザインフローおよび IP インテグレーターの詳細は、次の Vivado Design Suite ユーザーガイドを参照してください。

• 『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994) [参照 14]

• 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 13]

• 『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参照 15]

• 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 17]

コアのカスタマイズおよび生成

ここでは、ザイリンクスツールを使用し、 Vivado Design Suite でコアをカスタマイズおよび生成する方法について説明します。

重要: Vivado IP インテグレーターでコアをカスタマイズおよび生成する場合は、『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994) [参照 14] を参照してください。 IP インテグレーターは、デザインの検証または生成時に一部のコンフィギュレーション値を自動的に計算する場合があります。値が変わるかどうかを確認するには、この章のパラメーターの説明を参照してください。パラメーター値を確認するには、 Tcl コンソールから validate_bd_design コマンドを実行してください。

コアはユーザーデザインに合わせてカスタマイズできます。それには、 IP コアに関連する各種パラメーターの値を次の手順に従って指定します。

1. Vivado IP カタログから IP を選択します。

2. 選択した IP をダブルクリックするか、ツールバーまたは右クリックメニューから [Customize IP] コマンドをクリックします。

詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 13] および『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参照 15] を参照してください。

注記: この章の図には Vivado 統合設計環境 (IDE) のスクリーンショットが使用されていますが、現在のバージョンとはレイアウトが異なる場合があります。

UltraScale Devices Gen3 Integrated Block for PCIe コア用の [Customize IP] ダイアログボックスには、 2 つのモード ( 「Basic モードのパラメーター」、「Advanced モードのパラメーター」 ) があります。モード選択には、 [Customize IP] ダイアログボックスの初のページにある [Mode] ドロップダウンリストを使用します。以降のセクションでは、各モードで利用可能なパラメーターについて説明します。





第 4 章:デザインフローの手順

Basic モードのパラメーター

このセクションは、 Basic モードのパラメーターについて説明します。

[Basic] タブ

初のカスタマイズページでは、コアの基本パラメーター (コンポーネント名、基準クロックの周波数、シリコンタイプ) を定義します。

[Component Name]

このコアに対して生成される出力ファイルの基本名です。初の 1 文字は必ず小文字アルファベットとし、 2 文字目以降は a ～ z、 0 ～ 9、アンダースコア (_) を自由に組み合わせることができます。

[Mode]

コアのコンフィギュレーションモードとして [Basic] または [Advanced] のいずれかを選択できます。

[PCIe Device/Port Type]

PCI Express のロジックデバイスタイプを指定します。

[PCIe Block Location]

ロケーション別の制約ファイルおよびピン配置を生成するよう、対象となる統合ブロックの中から選択します。この選択は、デフォルトのサンプルデザインスクリプトで使用されます。

ザイリンクス開発ボードが選択されている場合は、このオプションは利用できません。

[Number of Lanes]

コアには初期レーン幅を選択する必要があります。表 4-1 に、選択可能なレーン幅とそれに対応したコアを定義しています。レーン幅の広いコアがそれよりも狭いレーン幅のデバイスに接続されている場合は、狭いほうのレーン幅にトレーニングダウンできます。詳細は、「リンクトレーニング: 2 レーン、 4 レーン、および 8 レーンコンポーネント」を参照してください。

[Maximum Link Speed]

デバイスでサポートされている大リンクスピードを選択できます。表 4-2 では、デバイスでサポートされているレーン幅およびリンクスピードを定義しています。高速なリンクスピードのコアがそれより低いリンクスピードのデバイスに接続されている場合、低いほうのリンクスピードにトレーニングできます。

表 4‐1: レーン幅および生成されるコア

レーン幅生成されるコア

x8 8 レーン UltraScale FPGA Gen3 Integrated Block for PCI Express コア

表 4‐2: レーン幅およびリンクスピード

レーン幅リンクスピード

x8 8Gb/s






AXI‐ST インターフェイス幅

表 4-3 のように、インターフェイス幅を選択できます。 [Customize IP] ダイアログボックスに設定されているデフォルトのインターフェイス幅は、も狭いインターフェイス幅となります。

[AXI‐ST Interface Frequency]

周波数は 250MHz に設定されています。

[AXI‐ST Alignment Mode]

ペイロードが現れる場合、各データパスのペイロードの初のバイトに揃えるために、 2 つのオプションがあります。 113 ページの「データアライメントオプション」を参照してください。

[AXI‐ST Frame Straddle] の有効化

インターフェイス幅が 256 ビットの場合、コアはリクエスターコンプリーションインターフェイス上でパケットをストラドルするオプションを利用できます。詳細は、 176 ページの「256 ビットインターフェイスのストラドルオプション」を参照してください。

[Enable Client Tag]

クライアントタグの利用を可能にします。

[Reference Clock Frequency]

sys_clk に供給される基準クロックの周波数を選択します。コアのクロック供給の詳細は、「クロッキング」を参照してください。

[Xilinx Development Board]

ザイリンクス開発ボードに特化した制約ファイルを生成する場合、このオプションを選択します。

[Enable External PIPE Interface]

このオプションをオンにした場合、外部のサードパーティバスファンクショナルモデル (BFM) を PCIe 統合ブロックの PIPE インターフェイスへ接続できます。詳細は、エンドポイントコンフィギュレーションで Gen2 および Gen3 コアを使用するリファレンスデザインについて説明した、 XAPP1184 [参照 25] を参照してください。 UltraScale™ デバイスコアの外部 PIPE インターフェイスポートをサードパーティ BFM に接続する場合は、これらのデザインが参考になります。

[Additional Transceiver Control and Status Ports]

このチェックボックスをオンにすると、トランシーバーのデバッグおよびステータスポートがコアの境界レベルに引き出されます。

表 4‐3: レーン幅、リンクスピード、およびインターフェイス幅

レーン幅リンクスピード (Gb/s) インターフェイス幅 (Bits)

x8 8.0 256






[Capabilities] タブ

このセクションでは、 [Capabilities] タブの設定について説明します。

[Enable Physical Function 0]

追加の Physical Function (PF) をインプリメントします。

統合ブロックは、 PF0 に関連する大 6 個までの Virtual Function をインプリメントします (有効な場合)。

[PF0 Legacy Interrupt PIN]

割り込みピンを INTA、 INTB、 INTC および INTD から選択します。デフォルト値は INTA です。

[MPS]

このフィールドは、デバイスまたはファンクションが TLP 用にサポートできる大ペイロードサイズを示します。デバイス機能レジスタ (Device Capabilities Register) を介してシステムに伝達される値です。

[Extended Tag]

リクエスターとしてサポートされているタグフィールドの大サイズを示します。使用可能なオプションは次のとおりです。

• オンにした場合は、 6 ビットのタグフィールド (64 タグ) がサポートされる

• オンにしていない場合は、 5 ビットのタグフィールド (32 タグ) がサポートされる

[Slot Clock Configuration]

リンクステータスレジスタの Slot Clock Configuration ビットを有効にします。このオプションをオンにした場合、リンクに同期クロックが供給されます。クロッキングオプションの詳細は、「クロッキング」を参照してください。

「ID 設定 ([PF0 IDs]、 [PF1 IDs])」タブ

このオプション設定では、 IP の初期値、クラスコード、および Cardbus CIS ポインター情報をカスタマイズします。Physical Function 1 (PF1) のページは、 PF1 が有効の場合のみ表示されます。

PF0 ID の初期値

• [Vendor ID]: デバイスまたはアプリケーションの製造者 ID です。各 ID の重複を避けるため PCI Special Interest Group によって有効な ID が割り当てられています。デフォルト値「10EEh」はザイリンクスのベンダー ID です。ここにベンダー ID を入力します。「FFFFh」は予約されています。

• [Device ID]: アプリケーションの ID です。デフォルト値は選択されているコンフィギュレーションにより異なりますが、「70<link speed><link width>h」となります。このフィールドには任意の値を入力できます。アプリケーションに合わせて変更してください。

このパラメーターは、次に基づいて評価されます。

° デバイスファミリ (UltraScale+™ の場合は 9、 UltraScale の場合は 8、 7 シリーズデバイスの場合は 7)

° EP または RP モード

° リンク幅

° リンクスピード

上記の値のいずれかが変更された場合、[Device ID] の値が再評価され、現在設定されている値に上書きされます。






推奨: リンク幅、リンクスピード、デバイスポートタイプを初に変更してから [Device ID] の値を変更することを推奨します。 IP を生成する前に、 [Device ID] の値が正しく設定されていることを確認してください。

• [Revision ID]: デバイスまたはアプリケーションのリビジョンを指し、デバイス ID に付随するものです。デフォルト値は「00h」です。アプリケーションに合った値を入力してください。

• [Subsystem Vendor ID]: デバイスまたはアプリケーションの製造者をさらに細分化させるための ID です。ここにサブシステムベンダー ID を入力します。デフォル値は「10EEh」です。通常、この値はベンダー ID と同じです。この値を「0000h」に設定すると準拠テスト問題が発生します。

• [Subsystem ID]: デバイスまたはアプリケーションの製造者をさらに細分化させるための ID です。この値は通常デバイス ID と同じです。デフォルト値は選択されているレーン幅およびリンクスピードにより異なります。この値を「0000h」に設定すると準拠テスト問題が発生します。

[Class Code]

クラスコードは、デバイスの一般的な機能を識別するもので、 3 つのバイトサイズフィールドに分かれています。

• [Base Class]: デバイスにより実行される機能のタイプを広義に識別します。

• [Sub-Class]: デバイス機能をさらに細かく識別します。

• [Interface]: デバイスに依存したソフトウェアがデバイスとインターフェイスできるようにするレジスタレベルのプログラミングインターフェイスを定義します。

クラスコードのエンコードについては、 PCI SIG ウェブサイトを参照してください。

[Use Classcode Lookup Assistant]

選択されているデバイスの一般機能に対して、ベースクラス、サブクラス、およびインターフェイスの値を提供します。この検索ツールは、選択されている機能に対し 3 つの値を表示するだけです。デバイス設定に変換するには、ユーザー自身が [Class Code] にこれらの値を入力する必要があります。

ベースアドレスレジスタ ([PF0 BAR] および [PF1 BAR]) タブ

Base Address Registers (BAR) のページでは、エンドポイントコンフィギュレーションのベースアドレスレジスタ空間を設定します。各 BAR (0 ～ 5) には、 Physical Function の BAR Aperture Size および Control の属性が指定されます。

BAR (Base Address Register) の概要

エンドポイントコンフィギュレーションのコアでは、大 6 つの 32 ビット BAR または 3 つの 64 ビット BAR、および拡張 ROM (read-only memory) BAR がサポートされます。ルートポートコンフィギュレーションのコアでは、大 2 つの 32 ビット BAR または 1 つの 64 ビット BAR、および拡張 ROM (read-only memory) BAR がサポートされます。

BAR は次のいずれかのサイズに設定できます。

• 32 ビットの BAR: アドレス空間は 128 バイトから 2 ギガバイトまでです。メモリまたは I/O に使用します。

• 64 ビットの BAR: アドレス空間は 128 バイトから 256 ギガバイトまでです。メモリのみに使用します。

すべての BAR レジスタに次のオプションがあります。

• チェックボックス: BAR を有効にするにはチェックボックスをオンします。 BAR を無効にするにはこのチェックボックスをオフにします。

• [Type]: BAR は I/O または Memory のいずれかにできます。

° [I/O]: I/O BAR は 32 ビットのみです。 I/O BAR はプリフェッチ対応ではありません。 I/O BAR はレガシ PCI Express エンドポイントコアに対してのみ使用できます。

° [Memory]: Memory BAR は 64 ビットまたは 32 ビットに設定でき、プリフェッチ可能です。 BAR が 64 ビットに設定されている場合、拡張アドレス空間用に次の BAR が使用され、その BAR にはアクセスできなくなります。


http://www.pcisig.com/





• [Size]: 使用可能なサイズ範囲は、 [PCIe Device/Port Type] および [Type of BAR] の設定によって異なります。表 4-4 に、 BAR サイズの範囲を示します。

• [Prefetchable]: メモリ空間をプリフェッチ可能にするかどうかを設定します。

• [Value]: 現在の選択内容に基づいて BAR に値が割り当てられます。

ベースアドレスレジスタの設定の管理については、「ベースアドレスレジスタの設定の管理」を参照してください。

[Expansion ROM Base Address Register]

このオプションが選択されている場合、拡張 ROM がアクティベートされ、 2KB から 4GB までの値を指定できます。『PCI 3.0 Local Bus Specification』 [参照 2] によると、拡張 ROM BAR のサイズは 16MB 以下に抑える必要があります。16MB よりも大きなアドレス空間を選択すると、コアが規格に準拠しなくなる可能性があります。

ベースアドレスレジスタの設定の管理

任意のベースアドレスレジスタに対して適切な値を入力することで、 [Memory]、 [I/O]、 [Type]、および [Prefetchable] の設定を管理します。

[Memory] または [I/O] の設定値を確認すると、そのアドレス空間がメモリまたは I/O として定義されていることがわかります。ベースアドレスレジスタはそのアドレス空間にアクセスするコマンドのみに応答します。一般的には、4KB 未満のメモリ空間は避けてください。 I/O 空間の小値は 16 バイトであるため、 I/O 空間の使用は新しいデザインでは避けてください。

プリフェッチのオプションは、メモリ空間をプリフェッチ可能にするかどうかを指定します。読み出しに影響がない場合 (つまり RAM からの読み出しのように、読み出しによってデータが破損するなどの影響がない場合)、メモリ空間はプリフェッチ可能です。また、複数のバイト書き込み操作を 1 つのダブルワード書き込みにまとめることもできます。

PCIe (レガシでないもの) に対しコアをエンドポイントとしてコンフィギュレーションする場合、プリフェッチ可能ビットが設定されているすべての BAR (BAR5 を除く ) に対し、 64 ビットアドレス指定がサポートされている必要があります。プリフェッチ可能ビットが設定されていない BAR すべてに対して、 32 ビットアドレス指定は可能です。プリフェッチビットに関連した要件はレガシエンドポイントには適用されません。 BAR でサポートされている小メモリアドレスは、PCI Express エンドポイントの場合は 128 バイトで、レガシ PCI Express エンドポイントの場合は 16 バイトです。

未使用リソースの無効化

良の結果を得るには、未使用のベースアドレスレジスタを無効にしてシステムリソースを節約します。[Customize IP] ダイアログボックスで未使用 BAR のチェックボックスをオフにすると、その BAR は無効になります。

表 4‐4:デバイスコンフィギュレーション別の BAR サイズ範囲

PCIe デバイス/ポートタイプ BAR タイプ BAR サイズ範囲

PCI Express エンドポイント32 ビットメモリ 128 バイト (B) ～ 2 ギガバイト (GB)

64 ビットメモリ 128B ～ 256GB

レガシ PCI Express エンドポイント



I/O 16B ～ 2GB

PCI Express ルートコンプレックスのルートポート



I/O 16B ～ 2GB






[Legacy/MSI Capabilities] タブ

このページでは、該当するすべての Physical Function および Virtual Function に対して [Legacy Interrupt Settings] および [MSI Capabilities] を設定できます。

[Legacy Interrupt Settings]

• [Enable MSI Per Vector Masking]: 有効になっている Physical Function すべての MSI のベクターごとのマスキング機能を有効にします。

注記: このオプションは、各 Physical Function に対して有効に設定できません。

• [PF0/PF1 Interrupt PIN]: レガシ割り込みメッセージのマッピングを示します。 [None] は、レガシ割り込みが使用されていないことを示します。

[MSI Capabilities]

• [PF0/PF1 Enable MSI Capability Structure]: MSI 機能構造体を有効にします。

注記: MSI または MSI-X を有効にしないことも可能ですが、その場合、コアが規格に準拠しなくなる可能性があります。『PCI Express Base Specification』 [参照 2] では、 MSI または MSI-X のいずれかまたは両方が有効になることが条件として定義されています。

• [Multiple Message Capable]: ルートコンプレックスから要求する MSI ベクターの数を選択します。

Advanced モードのパラメーター

[Basic] タブの [Mode] で [Advanced] が選択されている場合、次のパラメーターが IP カタログのさまざまなページに表示されます。

[Basic] タブ

Advanced モード用の [Basic] ページには、いくつかの追加設定があります。 [Advanced] モードを選択した場合に [Basic] ページで指定できるパラメーターは次のとおりです。

[Enable Parity]

オンにすると、 UltraScale IP のパリティ機能が有効になります。 2 つのモデルパラメーター AXISTEN_IF_CC_PARITY_CHK と AXISTEN_IF_RQ_PARITY_CHK が TRUE に設定されます。このパラメーターのデフォルト値は FALSE です。

[Use the dedicated PERST routing resources]

該当する PCIe ロケーションに対する sys_rst 専用配線を有効にします (表 2-2 参照)。

[System reset polarity]

sys_rst の極性 (ACTIVE_HIGH または ACTIVE_LOW) を設定します。

[PCIe DRP Ports]

オンにすると、 PCIe DRP インターフェイスが有効になります。






[PCIe DRP Ports] をオンにした場合に利用できる信号を、表 4-5 に示します。

[GT Channel DRP]

オンにすると、 GT チャネル DRP インターフェイスが有効になります。

[GT Channel DRP] をオンにした場合に利用できる信号を、表 4-6 に示します。

[Enable RX Message INTFC]

オンにすると、メッセージは受信メッセージインターフェイスの cfg_msg_received 信号に転送されます。オフにすると、メッセージは CQ インターフェイスに転送されます。

[Enable GT Quad Selection]

デバイス /パケージの移行を可能にします。「UltraScale デバイスの PCI Express デザインのパッケージ移行」を参照してください。

[GT Quad]

ドロップダウンメニューを使用して任意の GTH クワッドを選択します。このオプションは、 [Enable GT Quad Selection] がオンになっている場合のみ有効です。各デバイスで利用可能な GT クワッドの詳細は、付録 B の「利用可能な GT クワッド」を参照してください。

表 4‐5: PCIe DRP ポート

名称方向幅説明

drp_addr I 10 ビット PCIe DRP アドレス

drp_en I 1 ビット PCIe DRP イネーブル

drp_di I 16 ビット PCIe DRP データイン

drp_do O 16 ビット PCIe DRP データアウト

drp_rdy O 1 ビット PCIe DRP レディ

drp_we I 1 ビット PCIe DRP 書き込み/読み出し

表 4‐6: GT DRP ポート

名称方向幅説明

ext_ch_gt_drpaddr I レーンの数 x 10 GT Wizard DRP アドレス

ext_ch_gt_drpen I レーンの数 x 1 GT Wizard DRP イネーブル

ext_ch_gt_drpdi I レーンの数 x 16 GT Wizard DRP データイン

ext_ch_gt_drpdo O レーンの数 x 16 GT Wizard DRP データアウト

ext_ch_gt_drprdy O レーンの数 x 1 GT Wizard DRP レディ

ext_ch_gt_drpwe I レーンの数 x 1 GT Wizard DRP 書き込み/読み出し






[CORE CLOCK Frequency]

このパラメーターで、コアのクロック周波数を選択できます。

Gen3 リンクスピード :

• スピードグレード -1、 -2、 -3、 -1H、 -1HV でリンク幅が x8 以外の場合は、 250MHz と 500MHz を選択できます。この構成では、 [Advanced] モードを選択した場合にこのパラメーターを設定できます。

• スピードグレード -1、 -2、 -3、 -1H、 -1HV でリンク幅が x8 の場合、このパラメーターはデフォルトの 500MHz から変更できません。

• スピードグレード -1L または -1LV でリンク幅が x8 以外の場合は、このパラメーターはデフォルトの 250MHz から変更できません。

Gen1 および Gen2 リンクスピード :

• このパラメーターはデフォルトの 250MHz から変更できません。

注記: スピードグレード -1L または -1LV を選択し、プロダクションデバイスでない XCVU440 (ES2)、 XCKU060 (ES2) または XCKU115 (ES2) を選択した場合、このパラメーターはデフォルトの 250MHz から変更できません。

[Capabilities] タブ

Advanced モード用の [Capabilities] 設定には、 Basic モードの設定にさらに 3 つのパラメーターが追加されています。詳細は次のとおりです。

[SRIOV Capabilities]

SR-IOV (Single Root Port I/O Virtualization) 機能を有効にします。統合ブロックが拡張型の Single Root Port I/O Virtualization PCIe をインプリメントします。オンにすると、 PF0 と PF1 の両方 (選択されている場合) に SR-IOV がインプリメントされます。

[Function Level Reset]

ファンクションレベルのリセット機能が有効であることを示します。ユーザーが特定のデバイス機能をリセットできます。このオプションは、エンドポイントコンフィギュレーションにのみ適用可能です。

[Device Capabilities Registers 2]

AtomicOps および TPH コンプリーターをサポートするためのオプションを指定します。詳細は、『PCI Express Base Specification』 [参照 2] の第 7 章にある「Device Capability Register 2」を参照してください。これらの設定は、 PF1 が有効な場合に両方の Physical Functoin に適用されます。

[PF0 ID] および [PF1 ID] タブ

[Identity] の設定 (PF0 および PF1 の Initial ID) は、 Basic モードと Advanced モードで同じです。

[PF0 BAR] および [PF1 BAR] タブ

[PF0 BAR] および [PF1 BAR] の設定は、 Basic モードと Advanced モードで同じです。






[SRIOV Config](PF0 および PF1) タブ

[SRIOV Capability Version]

Physical Function 用の 4 ビットの SR-IOV Capability バージョンを示します。

[SRIOV Function Select]

Physical Function と関連する Virtual Function の数を示します。 PF0 および PF1 には、合計 6 個の Virtual Function を指定できます。

[SRIOV Functional Dependency Link]

Physical Function 用の SR-IOV Functional Dependency Link を示します。デバイスのプログラミングモデルには、ファンクション間にベンダー指定の相互依存性を持たせることができます。この Function Dependency Link フィールドを使用して、これらの相互依存性を定義します。

[SRIOV First VF Offset]

Physical Function (PF) の初の Virtual Function (VF) のオフセットを示します。PF0 は常にオフセット 0、PF1 は常にオフセット 1 に存在します。 Gen3 Integrated Block for PCIe コアでは、 6 つの Virtual Function を利用でき、 Function 番号は 64 ～ 69 の範囲になります。

PF0 を親とし、 PF に属する関係で VF が連続的にマッピングされます。たとえば、 PF0 に 2 つの Virtual Function があり、 PF1 には 3 つの Virtual Function がある場合、次のようなマッピングとなります。

Virtual Function の初のオフセットから Physical Function のオフセットを引くことで、 PFx_FIRST_VF_OFFSET が計算されます。

PFx_FIRST_VF_OFFSET = (PFx first VF offset - PFx offset)

上記の例では、次のオフセットが使用されます。

PF0_FIRST_VF_OFFSET = (64 - 0) = 64PF1_FIRST_VF_OFFSET = (66 - 1) = 65

PF0 は常に 64 で、 PH0 には 1 つ以上の Virtual Function があることが前提となります。 PF1 の初のオフセットは、 PF0 に接続されている VF 数のファンクションとなり、次のようなコード例で定義されます。

PF1_FIRST_VF_OFFSET = 63 + NUM_PF0_VFS

[SRIOV VF Device ID]

Physical Function に関連するすべての Virtual Function 用の 16 ビット Device ID を示します。

[SRIOV Supported Page Size]

Physical Function でサポートされるページサイズを示します。32 レジスタのビット n がセットされている場合、この Physical Function は 2n+12 のページサイズをサポートします。






[PF0 SRIOV BARs] および [PF1 SRIVO BARs] タブ

SRIOV ベースアドレスレジスタ (BARs) では、エンドポイントコンフィギュレーション用のベースアドレスレジスタ空間を設定します。各 BAR (0 ～ 5) には、 SRIOV BAR のアパーチャサイズと SRIOV の制御属性が指定されます。

SRIOV BAR (ベースアドレスレジスタ ) の概要

エンドポイントコンフィギュレーションのコアでは、大 6 つの 32 ビット BAR または 3 つの 64 ビット BAR がサポートされます。ルートポートコンフィギュレーションのコアでは、大 2 つの 32 ビット BAR または 1 つの 64 ビット BAR がサポートされます。 SRIOV BAR は次のいずれかのサイズに設定できます。

• 32 ビットの BAR: アドレス空間は 16 バイトから 2 ギガバイトまでです。メモリまたは I/O に使用します。

• 64 ビットの BAR: アドレス空間は 128 バイトから 256GB までです。メモリのみに使用します。

すべての SRIOV BAR レジスタに次のオプションがあります。

• チェックボックス : BAR を有効にするにはチェックボックスをオンします。 BAR を無効にするにはこのチェックボックスをオフにします。

• [Type]: SRIOV BAR は I/O または Memory のいずれかにできます。

° [I/O]: I/O BAR は 32 ビットのみです。 I/O BAR はプリフェッチ対応ではありません。 I/O BAR はレガシ PCI Express エンドポイントコアに対してのみ使用できます。

° [Memory]: Memory BAR は 64 ビットまたは 32 ビットに設定でき、プリフェッチ可能です。 BAR が 64 ビットに設定されている場合、拡張アドレス空間用に次の BAR が使用され、その BAR にはアクセスできなくなります。

• [Size]: 使用可能なサイズ範囲は、[PCIe Device/Port Type] および [Type of BAR] の設定によって異なります。表 4-8 に、 BAR サイズの範囲を示します。

• [Prefetchable]: メモリ空間をプリフェッチ可能にするかどうかを設定します。

• [Value]: 現在の選択内容に基づいて BAR に値が割り当てられます。

SRIOV ベースアドレスレジスタの設定の管理については、「ベースアドレスレジスタの設定の管理」を参照してください。

表 4‐7: Virtual Function のマッピング例

Physical Function Virtual Function ファンクション番号の範囲

PF0 VF0 64

PF0 VF1 65

PF1 VF0 66

PF1 VF1 67

PF1 VF1 68

表 4‐8:デバイスコンフィギュレーション別の SRIOV BAR サイズ範囲

PCIe デバイス/ポートタイプ BAR タイプ BAR サイズ範囲

PCI Express エンドポイント32 ビットメモリ 128B ～ 2GB


レガシ PCI Express エンドポイント



I/O 16B ～ 2GB






SRIOV ベースアドレスレジスタの設定の管理

[Customize IP] ダイアログボックスで任意のベースアドレスレジスタに対して適切な値を入力することで、[Memory]、 [I/O]、 [Type]、および [Prefetchable] の設定を管理します。

[Memory] または [I/O] の設定値を確認すると、そのアドレス空間がメモリまたは I/O として定義されていることがわかります。ベースアドレスレジスタはそのアドレス空間にアクセスするコマンドのみに応答します。一般的には、4KB 未満のメモリ空間は避けてください。 I/O 空間の小値は 16 バイトであるため、 I/O 空間の使用は新しいデザインでは避けてください。

読み出しに影響がない場合 (つまり RAM からの読み出しのように、読み出しによってデータが破損するなどの影響がない場合)、メモリ空間はプリフェッチ可能です。また、複数のバイト書き込み操作を 1 つのダブルワード書き込みにまとめることもできます。

PCIe (レガシでないもの) に対しコアをエンドポイントとしてコンフィギュレーションする場合、プリフェッチ可能ビットが設定されているすべての SRIOV BAR (BAR5 を除く ) に対し、64 ビットアドレス指定がサポートされている必要があります。プリフェッチ可能ビットが設定されていない SRIOV BAR すべてに対して、 32 ビットアドレス指定は可能です。プリフェッチビットに関連した要件はレガシエンドポイントには適用されません。 BAR でサポートされている小メモリアドレスは、 PCI Express エンドポイントの場合は 128 バイトで、レガシ PCI Express エンドポイントの場合は 16 バイトです。

未使用リソースの無効化

良の結果を得るには、未使用のベースアドレスレジスタを無効にしてシステムリソースを節約します。[Customize IP] ダイアログボックスで未使用 BAR のチェックボックスをオフにすると、その BAR は無効になります。

[Legacy/MSI Capabilities] タブ

このページは、 Basic モードと同じです。

[MSI‐X Capabilities] タブ

[MSI-X Capabilities] のパラメーターは Advanced モードでのみ利用できます。

[Enable MSIx Capability Structure]

MSI-X Capability が有効になっていることを示します。

注記: Capability Structure (機能構造体) では、少なくとも 1 つのメモリ BAR を設定する必要があります。ユーザーは、アプリケーションの MSI-X テーブルおよびペンディングビットアレイの設定を管理する必要があります。

[MSIx Table Settings]:

MSI-X テーブルの構造を定義します。

• [Table Size]: MSI-X テーブルのサイズを指定します。予想される割り込みの数から 1 を引いた値を設定します (0x0F に設定するとテーブルサイズは 16)。

• [Table Offset]: MSI-X テーブルのベースを指し示す、ベースアドレスレジスタからのオフセット値を指定します。

• [BAR Indicator]: MSI-X テーブルのファンクションをメモリ空間へマップするために使用されるコンフィギュレーション空間のベースアドレスレジスタを示します。 64 ビットのベースアドレスレジスタの場合、これは下位 DWORD を指します。






[MSIx Pending Bit Array (PBA) Settings]

MSI-X PBA (ペンディングビットアレイ ) の構造を定義します。

• [PBA Offset]: MSI-X PBA のベースを指し示す、ベースアドレスレジスタからのオフセット値を指定します。

• [PBA BAR Indicator]: MSI-X PBA のファンクションをメモリ空間へマップするために使用されるコンフィギュレーション空間のベースアドレスレジスタを示します。

[Power Management] タブ

[Power Management] ページでは、パワーマネージメントレジスタ、電力消費、および電力損失に関する設定を行います。これらの設定は、 PF1 が有効の場合に両方の Physical Function に対して適用されます。

• [D1 Support]: ファンクションで D1 Power Management State がサポートされていることを示します。詳細は、『PCI Bus Power Management Interface Specification Revision 1.2』 [参照 2] を参照してください。

• [PME Support From]: ファンクションが cfg_pm_wake をアサートできる電力ステートを示します。詳細は、『PCI Bus Power Management Interface Specification Revision 1.2』 [参照 2] を参照してください。

• [BRAM Configuration Options]: ソリューションに使用される受信ブロック RAM の数を指定します。表で各パケットタイプで利用可能なレシーバークレジットの数を示しています。

[Extended Capabilities 1] および [Extended Capabilities 2]

[PCIe Extended Capabilities] では、 PCI Express 拡張機能を有効にできます。 [Advanced Error Reporting Capability (offset 0x100h)] は常に有効に設定されています。 [Customize IP] ダイアログボックスでは、有効な機能に基づいたリンクの一覧を表示しています。有効化した後、ユーザーは「出力の生成」に定義されたコアの上位に適切な属性を指定して、機能を設定する必要があります。

• [Device Serial Number Capability]: 固有のデバイスシリアル番号 (DSN) を含むオプションの PCIe Extended Capability (拡張機能) です。この機能がオンになっている場合、 DSN はポートの Device Serial Number 入力ピンに出力される必要があります。また、 [Virtual Channel Capabilities] および [Vendor Specific Capabilities] を有効にするにはこの機能をオンにする必要があります。

• [Virtual Channel Capability]: ユーザーアプリケーションを TCn/VC0 モードで実行可能にするオプションの PCIe Extended Capability (PCIe 拡張機能) です。これをオンにすると、トラフィッククラスフィルター機能がサポートされます。この機能は、 Physical Function 0 にのみ利用可能です。

• [Reject Snoop Transactions] (ルートポートコンフィギュレーションのみ): このオプションがオンの場合、 No Snoop 属性が適用されているが TLP ヘッダーでは設定されていないトランザクションは、サポートされないリクエスト (UR) として拒否される可能性があります。

• [Enable AER Capability]: Advanced Error Reporting 機能をサポートするオプションの PCIe 拡張機能です。この機能は常に有効となります。

° [ECRC check capable]: [ECRC check capable] をオンにすると、コアは ECRC エラーのある TLP をユーザーロジックに送信せず、破棄します。

その他のオプション機能

• [Enable ARI]: Alternate Requester ID を有効にします。この機能は自動的に有効化され、 SRIOV が有効の場合には無効に設定しないでください。

• [Enable PB]: Power Budgeting Enhanced 機能ヘッダーをインプリメントします。

• [Enable RBAR]: Resizable BAR 機能をインプリメントします。

• [Enable LTR]: Latency Tolerance Reporting 機能をインプリメントします。

• [Enable DPA]: Dynamic Power Allocation 機能をインプリメントします。

• [Enable TPH]: Transaction Processing Hints 機能をインプリメントします。






[GT Settings] タブ

このページでは、通常変更できない特定トランシーバーの設定をカスタマイズできます。

PLL 選択

リンクスピードを Gen2 に設定した場合のみ、クロックソースとして [QPLL1] または [CPLL] を選択できます。この機能は、 Gen2 リンクスピードの場合に同じ GT クワッドで別のプロトコルを使用する場合に役立ちます。 Gen3 スピードには QPLL1 が必要で、 Gen1 スピードでは常に CPLL を使用します。

重要: これ以外の設定は、ザイリンクスによる指示がない限り変更しないでください。

表 4-9 に、各ラインスピードで選択可能なオプションとデフォルトを示します。

[Enable Auto RxEq]

このパラメーターを [True] に設定すると、レシーバー等化 (LPM または DFE) モードが自動的に選択されます。

[Form Factor Driven Insertion Loss Adjustment]

ナイキスト周波数でのトランスミッターからレシーバーの挿入ロスをフォームファクターの選択に従って示します。次の 3 つのオプションがあります。

1. [Chip-to-Chip]: 値は 5dB です (LPM)。

2. [Add-in Card]: 値は 15dB で、これがデフォルトです (DFE)。

3. [Backplane]: 値は 20dB です (DFE)。

これらの挿入ロス値は、 GT Wizard サブコアに適用されます。


図 4‐1: [GT Settings] タブ

表 4‐9: PLL タイプ

リンクスピード PLL タイプ説明

2.5_GT/s CPLL デフォルトは CPLL。この設定は変更できません。

5.0_GT/s QPLL1、 CPLL デフォルトは QPLL1。この設定は変更できます。

8.0_GT/s QPLL1 デフォルトは QPLL1。この設定は変更できません。

表 4‐10: レシーバー等化 (LPM または DFE) モードの決定方法

[Auto RxEQ] 動作

True デフォルトは DFE で、チャネル特性に応じて LPM に変化します。

False デフォルトは DFE で、 [Form Factor Driven Insertion Loss Adjustment] の設定によりモードを変更できます。






[Link Partner TX Preset]

デフォルト値の 4 から変更することは推奨しません。システムによってはプリセット値の 5 の方が良いこともあります。このパラメーターは [GT Settings] タブにあります。

[Receiver Detect]

レシーバー検出のタイプを [Default] または [Falling Edge] から選択します。このパラメーターは、 Advanced モードを選択した場合の [GT Settings] タブにあります。このパラメーターは、プロダクションデバイスの場合のみ利用できます。 [Falling Edge] を選択した場合、 Advanced モードの [Basic] タブにある [GT Channel DRP] はオフになります。詳細は、『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576) [参照 11] を参照してください。

[Shared Logic] タブ

このページで 1 つまたは複数のオプションを選択して、複数のインスタンシエーション間で共通のブロックを共有できるようにします。詳細は、第 3 章の「共有ロジック」を参照してください。

[Core Interface Parameters]

コアインターフェイスのパラメーターを選択できます。デフォルトで、すべてのポートが選択されているため、使用しないインターフェイスを無効にできます。無効になると、コアの上位からそのインターフェイス (ポート ) が削除されます。

推奨: 通常の使用では、インターフェイスを無効にしないでください。特別な場合のみポートを無効にしてください。






[Tansmit FC Interface]

コアが提供するフロー制御情報を要求できます。このオプションをオフにすると、次のポートが削除されます。

• pcie_tfc_nph_av

• pcie_tfc_npd_av

[Config FC Interface]

コアのコンフィギュレーションフロー制御を制御できます。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_fc_ph

• cfg_fc_pd

• cfg_fc_nph

• cfg_fc_npd

• cfg_fc_cplh

• cfg_fc_cpld

• cfg_fc_sel


図 4‐2: [Core Interface Parameters]






[Config External Interface]

外部にコンフィギュレーションレジスタが実装されている場合、コアがコンフィギュレーション情報をユーザーアプリケーションへ送信することが可能になります。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_ext_read_received

• cfg_ext_write_received

• cfg_ext_register_number

• cfg_ext_function_number

• cfg_ext_write_data

• cfg_ext_write_byte_enable

• cfg_ext_read_data

• cfg_ext_read_data_valid

[Config Status Interface]

コアのコンフィギュレーションステータス情報を提供します。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_phy_link_down

• cfg_phy_link_status

• cfg_negotiated_width

• cfg_current_speed

• cfg_max_payload

• cfg_max_read_req

• cfg_function_status

• cfg_vf_status

• cfg_function_power_state

• cfg_vf_power_state

• cfg_link_power_state

• cfg_err_cor_out

• cfg_err_nonfatal_out

• cfg_err_fatal_out

• cfg_ltr_enable

• cfg_ltssm_state

• cfg_rcb_status

• cfg_dpa_substate_change

• cfg_obff_enable

• cfg_pl_status_change

• cfg_tph_requester_enable

• cfg_tph_st_mode

• cfg_vf_tph_requester_enable

• cfg_vf_tph_st_mode

• pcie_rq_seq_num






• pcie_rq_seq_num_vld

• pcie_cq_np_req_count

• pcie_rq_tag

• pcie_rq_tag_vld

• pcie_cq_np_req

[Per Function Status Interface]

選択したファンクションを介してユーザーアプリケーションからのリクエストを受けて、ステータスデータを提供します。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_per_func_status_control

• cfg_per_func_status_data

[Config Management Interface]

コンフィギュレーション空間レジスタの読み出しおよび書き込みに使用します。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_mgmt_addr

• cfg_mgmt_write

• cfg_mgmt_write_data

• cfg_mgmt_byte_enable

• cfg_mgmt_read

• cfg_mgmt_read_data

• cfg_mgmt_read_write_done

• cfg_mgmt_type1_cfg_reg_access

[Receive Message Interface]

リンクからのデコード可能なメッセージ、データに関連するパラメーター、受信されたメッセージのタイプをロジックに提示します。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_msg_received

• cfg_msg_received_data

• cfg_msg_received_type

[Config Transmit Message Interface]

ユーザーアプリケーションが PCIe Gen3 コアへメッセージを送信する場合に使用されます。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_msg_transmit

• cfg_msg_transmit_type

• cfg_msg_transmit_data

• cfg_msg_transmit_done






[Physical Layer Interface]

Physical Layer (PL) Interface パラメーターは、デフォルトで False (オフ) に設定されているため、これらのポートはコアの境界に表示されません。これらのポートを有効にするには、このパラメーターをオンに設定してください。

• pl_eq_in_progress

• pl_eq_phase

• pl_eq_reset_eieos_count

• pl_gen2_upstream_prefer_deemph

[Config Interface]

このパラメーターは、デフォルトで False (オフ) に設定されているため、これらのポートはコアの境界に表示されません。これらのポートを有効にするには、このパラメーターをオンに設定してください。

• conf_req_data

• conf_req_ready

• conf_req_reg_num

• conf_req_type

• conf_req_valid

• conf_resp_rdata

• conf_resp_valid

[Config Control Interface]

ユーザーアプリケーションとコア間でさまざまな情報を送受信可能にします。このオプションをオフにすると、次のポートが削除されます。

• cfg_hot_reset_in

• cfg_hot_reset_out

• cfg_config_space_enable

• cfg_per_function_update_done

• cfg_per_function_number

• cfg_per_function_output_request

• cfg_dsn

• cfg_ds_port_number

• cfg_ds_bus_number

• cfg_ds_device_number

• cfg_ds_function_number

• cfg_power_state_change_ack

• cfg_power_state_change_interrupt

• cfg_err_cor_in

• cfg_err_uncor_in

• cfg_flr_done

• cfg_vf_flr_done

• cfg_flr_in_process

• cfg_vf_flr_in_process






• cfg_req_pm_transition_l23_ready

• cfg_link_training_enable

[Add.Debug Options]

デバッグ目的で、追加のデバッグ箇所を選択できます。次にパラメーターを示します。ポートレベルの説明は、付録 D の「ハードウェアデバッグ」を参照してください。

[Enable In System IBERT]

このデバッグオプションは、目的のリンクスピードにおけるシリアルリンクのアイダイアグラムをチェックおよび確認するために使用します。 In-System IBERT の詳細は、『In-System IBERT LogiCORE IP 製品ガイド』 (PG246) [参照 23] を参照してください。

重要: このオプションは、主にハードウェアデバッグの目的に使用します。このオプションをオンにした場合、シミュレーションはサポートされません。

アイダイアグラムのチェック手順を次に示します。

1. 該当するザイリンクスリファレンスボードを選択します。

2. 次の設定でコアをコンフィギュレーションします。

° 任意のリンク幅で Gen3、 Gen2、または Gen1 リンクスピードを選択します。

° [Add. Debug Options] ページで [Enable In System IBERT] をオンにします。

3. サンプルデザインを開きます。

4. .bit ファイルおよび .ltx ファイルを生成します。

5. FPGA をプログラムする前に、 Tcl コンソールで次のコマンドを source コマンドで実行します。

- set_param xicom.enable_isi_pcie_fix 1

6. ハードウェアマネージャー (HM) を開き、生成された .bit ファイルおよび .ltx ファイルを使用して FPGA をコンフィギュレーションします。

7. エニュメレーションプロセスをリスキャンして再度実行するために、マシンを再起動します。

8. HM の下部にある [Serial I/O Links] タブを選択して、スキャンウィンドウ用にリンクを作成します。

9. [Serial I/O Links] タブのリンクを 1 つ選択し、右クリックしてスキャンリンクオプションを選択します。

10. より優れた結果を得るには、 [Horizontal and Vertical Increment] にデフォルト値ではなく 2 を設定して試してください。

11. アイスキャンを選択すると、アイダイアグラムが描画されます。

重要: [Enable In System IBERT] は、 [GT Settings] タブの [Falling Edge Receiver Detect] オプションと併用できません。


図 4‐3: [Add. Debug Options]


https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=in_system_ibert;v=latest;d=pg246-in-system-ibert.pdf





[Enable Descrambler for Gen3 Mode]

このデバッグオプションは、 PCIe コア内部にある暗号化されたデスクランブラーモジュールを統合します。これは、 Gen3 リンクスピードモードの PCIe 統合ブロックから /への PIPE データを逆スクランブルするために使用します。これにより、ボードでのデバッグを目的としたハードウェア専用サポートが提供されます。

[Enable JTAG Debugger]

この機能を使用すると、次の理由でデバッグの負担が軽減されます。

• LTSSM ステートの遷移: リンクアップからのすべての LTSSM ステート遷移を示します。

• PHY リセット FSM の遷移: PHY リセット FSM (PCIe ソリューション IP で使用される内部ステートマシン) を示します。

• レシーバー検出: 問題なくレシーバー検出が完了したすべてのレーンを示します。

手順は次のとおりです。

1. 新しい Vivado を開き、ボードに接続します。

2. [hw_axi_1] が表示されるはずです。

3. Vivado Tcl コンソールに「source test_rd.tcl」と入力します。

4. 後処理のため、次をダブルクリックします。

° draw_ltssm.tcl (Windows) または wish draw_ltssm.tcl

° draw_reset.tcl (Windows) または wish draw_reset.tcl

° draw_rxdet.tcl (Windows) または wish draw_rxdet.tcl

これにより、 LTSSM ステート遷移が図示されます。

出力の生成

詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 13] を参照してください。







コアへの制約

ここでは、 Vivado® Design Suite でコアに制約を指定する方法について説明します。

必須の制約

UltraScale Devices Gen3 Integrated Block for PCIe ソリューションでは、 PCI Express® 用の特定性能要件を満たすために、タイミングおよびその他の物理的なインプリメンテーション制約を指定する必要があります。これらの制約は、エンドポイントおよびルートポートソリューションで、ザイリンクスデザイン制約 (XDC) ファイルを用いて適用されます。生成される XDC ファイルにあるピン配置および階層名は、配布されているサンプルデザインのものと一致しています。

重要: サンプルデザインの上位ファイルを使用しない場合、基準クロック用に IBUFDS_GTE3 インスタンスを、sys_rst 用に IBUF インスタンスを、そしてこれらに関連するタイミング制約もローカルデザインの上位にコピーします。

一貫したインプリメンテーション結果を得るには、ザイリンクスツールでデザインを実行するときに、変更されていない元の制約を含んだ XDC ファイルを使用する必要があります。 XDC または特定の制約の定義および使用方法についての詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 16] を参照してください。

統合ブロックソリューションで提供されている制約は、ハードウェア上でテスト済みで、一貫した結果を提供します。制約は変更可能ですが、各制約をよく理解した上で変更してください。また、提供されている制約を規定から逸脱した形で使用したデザインに対してはサポートを提供しておりません。

デバイス、パッケージ、スピードグレードの選択

XDC のデバイス選択セクションには、ターゲットにするパーツ、パッケージ、スピードグレードが記述されており、この情報がインプリメンテーションツールに渡されます。

重要: UltraScale Devices Gen3 Integrated Block for PCIe コアは特定のパーツとパッケージの組み合わせに対して設計されているため、このセクションは変更しないでください。

このセクションには常にパーツを選択する行が含まれていますが、パーツまたはパッケージ別のオプションも含まれている場合があります。たとえば、次のようになります。

CONFIG PART = XCKU040-ffva1156-3-e-es1

クロック周波数

クロック要件の詳細は、第 3 章「コアを使用するデザイン」を参照してください。

クロック管理


クロック配置







バンク設定

このセクションは、この IP コアには適用されません。

トランシーバーの配置


I/O 規格と配置


統合ブロックコアの再配置

IP コアレベルの制約により、ブロック RAM、トランシーバー、および PCIe ブロックが推奨ロケーションにデフォルトでロックされています。ブロックを再配置するには、 XDC 制約ファイルでこれらブロックの制約をオーバーライドする必要があります。これを実行するには、次の手順に従います。

1. コアレベルの XDC 制約ファイルから上書きする必要があるブロックの制約をコピーします。

2. それらの制約をユーザー XDC 制約ファイルに置きます。

3. 制約を新しいロケーションでアップデートします。

ユーザー XDC 制約ファイルは一般にデザインの上位にスコープされるため、制約によって参照されるセルがコピーおよびペースト後も変わらず有効であることを確認する必要があります。通常はモジュールパスを完全な階層名でアップデートする必要があります。

注記: スワップしなければならないロケーションが存在する場合 (つまり、別のモジュールが新しいロケーションを使用している )、次の 2 つの方法でこれを実行します。

• 利用可能な一時的なロケーションがある場合は、初のモジュールを新しい一時的なロケーションに移動します。その後、 2 つ目のモジュールを初のモジュールが使用していたロケーションに移動します。次に、初のモジュールを 2 つ目のモジュールのロケーションに移動します。上記の手順は、 XDC 制約ファイルで実行できます。

• 一時的なロケーションとして利用可能なほかのロケーションがない場合は、 2 つ目のモジュールをこのロケーションに再配置する前に、初のモジュールについて Tcl コマンドウィンドウから reset_property コマンドを使用します。 reset_property コマンドは XDC 制約ファイルで実行できないため、 Tcl コマンドファイルから呼び出すか、 Tcl コンソールに直接入力します。






シミュレーション

Vivado シミュレーションコンポーネントについて、またサポートされているサードパーティツールについては、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 17] を参照してください。

サンプルデザインのシミュレーション方法は、第 5 章の「サンプルデザインのシミュレーション」を参照してください。

PIPE モードシミュレーション

UltraScale Devices Gen3 Integrated Block for PCIe コアは、コアの PIPE インターフェイスがリンクパートナーの PIPE インターフェイスへ接続される PIPE モードシミュレーションをサポートします。このモードを選択すると、シミュレーションスピードが加速します。

現在の Vivado Design Suite ソリューションのサンプルデザイン (エンドポイントモードまたはルートポートモードのいずれか) で PIPE モードシミュレーションを有効にするには、 [Customize IP] ダイアログボックスの [Basic] タブで [Enable External PIPE Interface] オプションを使用します。コアの境界で External PIPE Interface 信号が生成され、外部デバイスへのアクセスが可能になります。この機能を有効にすると、サンプルデザインで提供されるルートポートモデルの代わりにサードパーティの PCI Express VIP/BFM を使用するために必要な接続も提供されます。

ヒント : PIPE モードは、シミュレーション専用です。インプリメンテーションはサポートされていません。

詳細は、 196 ページの「[Enable External PIPE Interface]」を参照してください。

表 4-11 および表 4-12 に、コアの上位に含まれる PIPE バス信号と、 EP コア (pcie_top) PIPE 信号のマッピングを示します。

重要: 新しいファイルの xil_sig2pipe.v がシミュレーションに直接取り込まれ、 phy_sig_gen.v の置き換えとなります。 BFM/VIP は、 board.v の xil_sig2pipe インスタンスと接続する必要があります。

表 4‐11:共通の入力/出力コマンドとエンドポイント PIPE 信号のマッピング

入力コマンドエンドポイント PIPE 信号の

マッピング出力コマンド

エンドポイント PIPE 信号のマッピング

common_commands_in[25:0] 使用しない common_commands_out[0] pipe_clk(1)

common_commands_out[2:1] pipe_tx_rate_gt(2)

common_commands_out[3] pipe_tx_rcvr_det_gt

common_commands_out[6:4] pipe_tx_margin_gt

common_commands_out[7] pipe_tx_swing_gt

common_commands_out[8] pipe_tx_reset_gt

common_commands_out[9] pipe_tx_deemph_gt

common_commands_out[16:10] 使用しない(3)

注記:1. pipe_clk は、コアコンフィギュレーションに基づく出力クロックです。 Gen1 レートの場合 125MHz です。 Gen2 および Gen3 の場合は

250MHz です。

2. pipe_tx_rate_gt は、パイプレート (2’b00-Gen1、 2’b01-Gen2 および 2’b10-Gen3) を示します。

3. このポートの機能は廃止されており、未接続のままでかまいません。






合成後/インプリメンテーション後のネットリストシミュレーション

UltraScale Devices Gen3 Integrated Block for PCIe コアは、合成後/インプリメンテーション後のネットリスト論理シミュレーションをサポートしています。ただしこのリリースでは、構成によってはこの機能がサポートされません。各コンフィギュレーションでネットリストの論理シミュレーションがサポートされるかどうかは、表 4-13 を参照してください。

注記: このリリースでは、すべての構成において合成/インプリメンテーション後のネットリストタイミングシミュレーションはサポートされません。

合成後のネットリスト論理シミュレーション

合成後のネットリスト論理シミュレーションを実行するには、次の手順を実行します。

1. 必要に応じてコアを設定し、生成します。

2. サンプルデザインを開き、合成を実行します。

3. 合成が完了したら、 Flow Navigator で [Run Simulation] を右クリックし、 [Run Post-Synthesis Functional Simulation] をクリックします。

表 4‐12:入力/出力バスとエンドポイント PIPE 信号のマッピング

入力バスエンドポイント PIPE 信号の

マッピング出力バス

エンドポイント PIPE 信号のマッピング

pipe_rx_0_sigs[31:0] pipe_rx0_data_gt pipe_tx_0_sigs[31:0] pipe_tx0_data_gt

pipe_rx_0_sigs[33:32] pipe_rx0_char_is_k_gt pipe_tx_0_sigs[33:32] pipe_tx0_char_is_k_gt

pipe_rx_0_sigs[34] pipe_rx0_elec_idle_gt pipe_tx_0_sigs[34] pipe_tx0_elec_idle_gt

pipe_rx_0_sigs[35] pipe_rx0_data_valid_gt pipe_tx_0_sigs[35] pipe_tx0_data_valid_gt

pipe_rx_0_sigs[36] pipe_rx0_start_block_gt pipe_tx_0_sigs[36] pipe_tx0_start_block_gt

pipe_rx_0_sigs[38:37] pipe_rx0_syncheader_gt pipe_tx_0_sigs[38:37] pipe_tx0_syncheader_gt

pipe_rx_0_sigs[83:39] 使用しない pipe_tx_0_sigs[39] pipe_tx0_polarity_gt

pipe_tx_0_sigs[41:40] pipe_tx0_powerdown_gt

pipe_tx_0_sigs[69:42] 使用しない(1)

注記:1. このポートの機能は廃止されており、未接続のままでかまいません。

表 4‐13:各コンフィギュレーションによる論理シミュレーションのサポート

コンフィギュレーション

Verilog VHDL 外部 PIPE

インターフェイスモード

共有ロジックをコアに含む

共有ロジックをサンプルデザイン

に含む

エンドポイントサポート

サポート (Tandem モードで [Use an external STARTUP primitive] をオンにした

場合を除く )

サポートしないサポートサポート

ルートポートこのリリースではサポートしない






インプリメンテーション後のネットリスト論理シミュレーション

インプリメンテーション後のネットリスト論理シミュレーションを実行するには、次の手順を実行します。

1. 上述の「合成後のネットリスト論理シミュレーション」の手順を実行します。

2. 生成したサンプルデザインに対してインプリメンテーションを実行します。

3. インプリメンテーションが完了したら、 Flow Navigator で [Run Simulation] を右クリックし、 [Run Post-Implementation Functional Simulation] をクリックします。

合成およびインプリメンテーション

合成およびインプリメンテーションの詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 13] を参照してください。

サンプルデザインの合成およびインプリメンテーションに関する詳細は、第 5 章の「サンプルデザインの合成およびインプリメンテーション」を参照してください。





第 5章

サンプルデザインこの章では、 Vivado® Design Suite で提供されているサンプルデザインについて説明します。

サンプルデザインの概要

このセクションでは、 UltraScale Devices Gen3 Integrated Block for PCIe のサンプルデザインについて説明します。

統合ブロックのエンドポイントコンフィギュレーションの概要

統合ブロックのエンドポイントコンフィギュレーションのサンプルシミュレーションデザインは、 2 つの完全に独立した部分で構成されています。

• ルートポートモデル: PCI Express® のバストラフィックを生成、使用、チェックするテストベンチです。

• PIO (Programmed Input/Output) サンプルデザイン: PCI Express のコンプリーターアプリケーションです。 PIO サンプルデザインは、そのメモリ空間への読み出しおよび書き込みリクエストに応答し、ハードウェアでのテスト用に合成できます。





第 5 章:サンプルデザイン

シミュレーションデザインの概要

シミュレーションデザインの場合、トランザクションはルートポートモデルから (エンドポイントとしてコンフィギュレーションされた) コアに送信され、 PIO サンプルデザインによって処理されます。図 5-1 は、コアで提供されているシミュレーションデザインについて説明しています。ルートポートモデルの詳細は、 240 ページの「エンドポイント用ルートポートモデルテストベンチ」を参照してください。

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

図 5-2 にあるように、インプリメンテーションデザインは、読み出しおよび書き込みトランザクションを受理してリクエストに応答できる、簡単な PIO サンプルデザインで構成されています。このサンプルのソースコードはコアと共に提供されています。 PIO サンプルデザインのシミュレーションについては、 222 ページの「PIO (Programmed Input/Output): エンドポイントのサンプルデザイン」を参照してください。


図 5‐1: シミュレーションサンプルデザインのブロック図

Test Program

Endpoint DUT for PCI Express

PCI Express Fabric

Endpoint Core for PCI Express

PIO Design

dsport

usrapp_tx

usrapp_com

usrapp_rx

Output Logs

Root Port Model TPI for

Express

X12471






サンプルデザインのエレメント

PIO サンプルデザインには、次のエレメントがあります。

• コアラッパー

• サンプルの Verilog HDL ラッパー (コアおよびサンプルデザインをインスタンシエートする )

• サンプルデザインをシミュレーションするためのカスタマイズ可能なデモ用テストベンチ

このサンプルデザインは、次のシミュレータを使用して Vivado Design Suite でテストおよび検証されています。

• Vivado シミュレータ

• Mentor Graphics 社 QuestaSim

• Cadence 社 Incisive Enterprise Simulator (IES)

• Synopsys 社 Verilog Compiler Simularor (VCS)

サポートされているツールのバージョンは、『Vivado Design Suite ユーザーガイド : リリースノート、インストールおよびライセンス』 (2) を参照してください。

PIO (Programmed Input/Output): エンドポイントのサンプルデザイン

通常、 PIO (Programmed Input/Output) トランザクションは PCI Express システムのホスト CPU が PCI Express ロジック内の MMIO (Memory Mapped Input Output) および CMIO (Configuration Mapped Input Output) アドレスにアクセスするために使用します。 PCI Express のエンドポイントは、メモリおよび I/O 書き込みトランザクションを受理し、またメモリおよび I/O 読み出しトランザクションに対してはデータ付きのコンプリーションで応答します。

PIO サンプルデザイン (PIO デザイン) は、 Vivado IP カタログによって生成されるエンドポイントコンフィギュレーションのコアに含まれています。ユーザーは検証済みの実際のデザインである PIO デザインを使用して、システムボードを起動し、ボードのリンクおよび機能を検証できます。

PIO デザインポートモデルは、コア (Endpoint Block Plus for PCI Express および Endpoint PIPE for PCI Express ソリューション) で共有されます。このセクションでは、総称的に Endpoint for PCI Express (または Endpoint for PCIe™) の名前を使用してすべてのソリューションを表しています。


図 5‐2: インプリメンテーションサンプルデザインのブロック図

X12459

UltraScale FPGA Gen3 Integrated Block for PCI Express (Configured as an Endpoint)

EP_TX EP_RX

PIO_TO_CTRLep_io_mem

ep_mem32

ep_mem64

ep_mem_erom

EP_MEM

PIO_EP

PIO

PIO_INTR_CTRL






システムの概要

PIO デザインは、シンプルなターゲット専用のアプリケーションで、 PCIe コア用エンドポイントのトランザクション (AXI4-Stream) インターフェイスと接続され、これを手掛かりにして独自デザインを構築できるように提供されています。次の機能が含まれています。

• 内部 FPGA ブロック RAM を使用するトランザクションごとの 2KB ターゲット領域が 4 つ (ターゲット空間の合計は 8,192 バイト )。

• コンプリーション TLP をサポートする 32 ビット /64 ビットのアドレスメモリ空間および I/O 空間への、1 Dword ペイロードの読み出しおよび書き込み PCI Express トランザクションをサポート。

• TLP デスティネーションのベースアドレスレジスタをそれぞれ区別するため、コアの BAR ID[2:0] および Completer Request Descriptor[114:112] を使用。

• 64 ビット、 128 ビット、および 256 ビットの AXI4-Stream インターフェイス用に個別に適化されたインプリメンテーションを提供

図 5-3 は、ルートコンプレックス、 PCI Express スイッチデバイス、 PCIe 用エンドポイントから成る PCI Express システムアーキテクチャコンポーネントを示しています。 PIO 操作は、ルートコンプレックス (CPU レジスタ ) からエンドポイントへと下方向 (ダウンストリーム) にデータを移動、またエンドポイントからルートコンプレックス (CPU レジスタ ) へと上方向 (アップストリーム) にデータを移動させます。どちらの場合も、データを移動させる PCI Express プロトコルリクエストは、ホスト CPU が開始します。


図 5‐3: システムの概要

PCIe RootComplex

Memory Controller

Device

MainMemory

CPU

PCI Port

PCIeEndpoint

PCIeSwitch

PCI_BUS_X

PCI_BUS_1

PCI_BUS_0

X12472






CPU が MMIO アドレスコマンドに格納レジスタを出力すると、データはダウンストリームに移動します。ルートコンプレックスは通常、適切な MMIO ロケーションアドレス、バイトイネーブル、およびレジスタの内容を含むメモリ書き込み TLP を生成します。エンドポイントがこのメモリ書き込み TLP を受信し、対応するローカルレジスタをアップデートすると、トランザクションは終了します。

CPU が MMIO アドレスコマンドからロードレジスタを出力すると、データはアップストリームに移動します。ルートコンプレックスは通常、適切な MMIO ロケーションアドレスおよびバイトイネーブルのあるメモリ読み出し TLP を生成します。エンドポイントはこのメモリ読み出し TLP を受信した後に、データ TLP と共にコンプリーションを生成します。このコンプリーションはルートコンプレックスに送信され、ペイロードがターゲットレジスタにロードされると、トランザクションは完了します。

PIO ハードウェア

PIO デザインは、 PCIe 用エンドポイントの背後にある FPGA ブロック RAM に 8,192 バイトのターゲット空間をインプリメントします。この 32 ビットのターゲット空間は 1 DWORD の I/O 読み出し、 I/O 書き込み、メモリ読み出し 64、メモリ書き込み 64、メモリ読み出し 32、およびメモリ書き込み 32 の TLP を介してアクセス可能です。

PIO デザインは、有効なメモリ読み出し 32 TLP、メモリ読み出し 64 TLP、またはコアにより出力された I/O 読み出しリクエストに応答して、ペイロードが 1 Dword のコンプリーションを生成します。さらに、 PIO デザインは、 I/O 書き込み TLP リクエストがうまくいったことを示すステータスと共に、データなしのコンプリーションを返します。

PIO デザインは次の動作を開始できます。

• 受信した書き込みアドレスが 11'hEA8 および書き込みデータが 32'hAAAA_BBBB で BAR0 をターゲットとする場合のメモリ読み出しトランザクション。

• 受信した書き込みアドレスが 11'hEEC および書き込みデータが 32'hCCCC_DDDD で BAR0 をターゲットとする場合のレガシ割り込み。

• 受信した書き込みアドレスが 11'hEEC および書き込みデータが 32'hEEEE_FFFF で BAR0 をターゲットとする場合の MSI。

• 受信した書き込みアドレスが 11'hEEC および書き込みデータが 32'hDEAD_BEEF で BAR0 をターゲットとする場合の MSIx。

PIO デザインは、FPGA ブロック RAM 空間のターゲットアドレスへペイロードをアップデートすることで、1 Dwordペイロードを含むメモリまたは I/O 書き込み TLP を処理します。

ベースアドレスレジスタのサポート

PIO デザインでは 4 つのターゲット空間がサポートされており、これらの各空間はそれぞれ別の基本アドレスレジスタ (BAR) で表されている 2KB のメモリブロックから構成されています。デフォルトのパラメーターを使用し、このセクションで定義する次の PIO デザインと機能するようにコンフィギュレーションされたコアが Vivado IP カタログによって生成されます。

• 64 ビットのアドレス指定可能なメモリ空間 BAR 1 つ

• 32 ビットのアドレス指定可能なメモリ空間 BAR 1 つ

PIO デザインで使用されるデフォルトのパラメーター値を変更可能ですが、場合によっては、使用されているシステム次第で、ユーザーアプリケーションを変更しなければならない可能性もあります。 Vivado Design Suite IP のデフォルトパラメーターの変更およびその PIO デザインへの影響については、「IP カタログのデフォルト BAR 設定の変更」を参照してください。

BAR で表されているこの 4 つの 2KB のアドレス空間はそれぞれ、 PIO デザインの 4 つの 2KB のアドレス領域の 1 つに対応しています。 2KB の各領域は、 2KB のデュアルポートブロック RAM を使用してインプリメントされます。コアがトランザクションを受信すると、アドレスを解読し、 4 つの領域のうちどれがターゲットになっているのかを判別します。コアは TLP を PIO デザインに出力し、表 5-1 に定義されているように、 Completer Request Descriptor[114:112] の該当ビット (BAR ID[2:0]) をアサートします。






IP カタログのデフォルト BAR 設定の変更

選択されている BAR 設定に一致するようにカスタマイズされた Verilog ソースを作成するため、 Vivado IP カタログのパラメーターを変更して PIO デザインを使用し続けることができます。しかし、 PIO デザインのパラメーターは、コアのパラメーターよりも限られているため、デフォルトの IP カタログのパラメーターを変更する場合は、次のサンプルデザインの制限事項を考慮してください。

• サンプルデザインでは、 I/O 空間 BAR が 1 つ、 32 ビットのメモリ空間が 1 つ (拡張 ROM 空間には使用できない)、64 ビットのメモリ空間が 1 つサポートされています。この制限数を超えると、指定したタイプの初の空間だけがアクティブになり、残りの空間にアクセスがあっても完了しません。

• 各空間は 2KB のメモリでインプリメントされます。対応する BAR がより幅の広いアパーチャにコンフィギュレーションされると、この 2KB 制限を超えたアクセスはラップアラウンドし、この 2KB メモリ空間はオーバーラップします。

• PIO デザインでは、 I/O 空間 BAR が 1 つサポートされています。これはデフォルトでは無効になっていますが、必要に応じて変更できます。

PIO デザインには制限事項がありますが、ユーザーのニーズに合わせてサンプルデザインを変更できるよう、Verilog のソースコードが提供されています。

TLP データフロー

このセクションでは、 PIO デザインで処理される TLP のデータフローについて説明します。

PIO デザインは、ペイロードが 1 DWORD のメモリ読み出しおよび書き込み TLP、 I/O 読み出しおよび書き込み TLP を処理します。 1 DWORD よりも長いメモリ読み出しまたはメモリ書き込み TLP は PIO デザインでは正しく処理されませんが、コアがこれらの TLP を受理し、 PIO デザインに渡します。 PIO デザインがコアから 1 Dword よりも長い TLP を受信する場合は、受信を完了しますがそれらを破棄します。また、それに対応するコンプリーションは生成されません。

メモリおよび I/O 書き込み TLP の処理

PCIe 用エンドポイントがメモリまたは I/O の書き込み TLP を受信すると、 TLP デスティネーションアドレスおよびトランザクションタイプが、コアの BAR の値と比較されます。 TLP がこの比較チェックをパスすると、コアが PIO デザインの受信 AXI4-Stream インターフェイスへ TLP を渡します。 PIO デザインは、メモリ書き込みと I/O TLP 書き込みを異なる方法で処理します。 I/O 書き込みには、データなしのコンプリーション (clp) を生成して PIO デザインは応答します。これは PCI Express 仕様で規定されています。

また、パケットの開始、パケットの終了、および準備完了のハンドシェイク信号と共に、コンプリーターリクエスター AXI4-Stream インターフェイスは、入力される TLP と一致したデスティネーション BAR を PIO デザインに知らせるため、コンプリーターリクエストの Descriptor[114:112] 信号の適切なビット (BAR ID[2:0]) をアサートします。それが受信されると、 PIO デザインの RX ステートマシンが、入力される書き込み TLP を処理し、また TLP データと関連アドレスフィールドを抽出して、 PIO デザインの内部ブロック RAM の書き込みリクエストコントローラーへ、これを渡すことができるようにします。

表 5‐1: TLP トラフィックタイプ

ブロック RAM TLP トランザクションタイプデフォルト BAR BAR ID[2:0]

ep_io_mem I/O TLP トランザクション無効無効

ep_mem32 32 ビットアドレスメモリ TLP トランザクション 2 000b

ep_mem64 64 ビットアドレスメモリ TLP トランザクション 0-1 001b

ep_mem_erom EROM 向けの 32 ビットアドレスメモリ TLP トランザクション

拡張 ROM 110b






アサートされた特定の BAR ID[2:0] 信号に基づいて、 RX ステートマシンは、書き込みイネーブルリクエストをアサートする前に使用する 2KB ブロック RAM を内部書き込みコントローラーに知らせます。たとえば、 BAR0 をターゲットにするコアが I/O 書き込みリクエストを受信した場合、コアはその TLP を PIO デザインに渡して BAR ID[2:0] を 000b に設定します。RX ステートマシンは、 I/O 書き込み TLP から下位アドレスビットとデータフィールドを抽出し、内部メモリ書き込みコントローラーに対し、ブロック RAM への書き込み操作を開始するよう指示します。

この例では、 BAR ID[2:0] が 000b に設定されているため、 PIO のメモリ書き込みコントローラーが ep_mem0 (デフォルトでは 2KB の I/O 空間を表す) にアクセスします。書き込みが FPGA のブロック RAM に対して実行されている間、 PIO デザインの RX ステートマシンは m_axis_cq_tready をディアサートするため、内部メモリ書き込みコントローラーがブロック RAM への書き込み操作を完了させるまで、受信 AXI4-Stream インターフェイスが TLP の受信を停止します。この方法で m_axis_cq_tready をディアサートすることは、コアを使用したデザインすべてに対し必須というわけではありません。 PIO デザインでは RX ステートマシンの制御ロジックを簡略化するために、この方法が採用されています。

メモリおよび I/O 読み出し TLP の処理

PCIe 用エンドポイントがメモリまたは I/O の読み出し TLP を受信すると、 TLP デスティネーションアドレスおよびトランザクションタイプが、コアの BAR にプログラムされた値と比較されます。 TLP がこの比較チェックをパスすると、コアが PIO デザインの受信 AXI4-Stream インターフェイスへ TLP を渡します。

また、パケットの開始、パケットの終了、および準備完了のハンドシェイク信号と共に、コンプリーターリクエスター AXI4-Stream インターフェイスは、入力される TLP と一致したデスティネーション BAR を PIO デザインに知らせるため、適切な BAR ID[2:0] 信号をアサートします。それが受信されると、 PIO デザインのステートマシンは入力される読み出し TLP を処理し、関連する TLP 情報を抽出して、 PIO デザインの内部ブロック RAM の読み出しリクエストコントローラーへこれを渡します。

アサートされた特定の BAR ID[2:0] 信号に基づいて、 RX ステートマシンは、読み出しイネーブルリクエストをアサートする前に使用する 2KB ブロック RAM を、内部読み出しコントローラーに知らせます。たとえば、デフォルトの Mem32 BAR2 をターゲットにするコアがメモリ読み出し 32 リクエスト TLP を受信した場合、コアはその TLP を PIO デザインに渡して BAR ID[2:0] を 010b に設定します。 RX ステートマシンは、メモリ 32 読み出し TLP から下位アドレスビットを抽出し、内部メモリ読み出しリクエストコントローラーに対し読み出し操作を開始するよう指示します。

この例では、 BAR ID[2:0] が 010b に設定されているため、 PIO のメモリ読み出しコントローラーが Mem32 (デフォルトでは 2KB の I/O 空間を表す) にアクセスします。メモリ書き込み TLP とメモリ読み出し TLP の処理における大きな違いは、メモリまたは I/O 読み出しリクエストがあった場合に、受信デバイスがデータのあるコンプリーション TLP を返す必要があるという点です。

読み出し動作が実行されている間、 PIO デザインの RX ステートマシンは m_axis_cq_tready をディアサートするので、内部メモリ読み出しコントローラーがブロック RAM からの読み出し操作を完了させてコンプリーションを生成するまで、受信 AXI4-Stream インターフェイスが TLP の受信を停止します。コアを使用するすべてのデザインでは、このように m_axis_cq_tready をディアサートする必要はありません。 PIO デザインでは、 RX ステートマシンの制御ロジックを簡略化するためにこの方法が採用されています。

PIO ファイルの構造

表 5-2 は、 PIO デザインファイルの構造を定義しています。 Vivado IP カタログで配布されるすべてのファイルが必要というわけではなく、どのコアがターゲットになっているかによりますが、配布されないファイルもあります。PCIe 用エンドポイントソリューションには、 32 ビットのユーザーデータパスを使用するものと、 64 ビットのデータパスを使用するものがありますが、 PIO デザインではどちらでも使用できます。データパスの幅は、ターゲットになっているコアによって異なります。

表 5‐2: PIO ファイルの構造

ファイル説明

PIO.v 上位デザインのラッパー

PIO_INTR_CTRL.v PIO 割り込みコントローラー

PIO_EP.v PIO アプリケーションモジュール






PIO デザインのコンフィギュレーションには、 PIO_64、 PIO_128、および PIO_256 (それぞれ 64、 128、 256 ビットの AXI4-Stream インターフェイス) の 3 種類があります。生成される PIO コンフィギュレーションは、選択されているエンドポイントタイプ (つまり UltraScale™ デバイスの統合ブロック、 PIPE、 PCI Express および Block Plus)、および選択されている PCI Express のレーン数、インターフェイス幅によります。表 5-3 には、ユーザーの選択に基づいて生成される PIO コンフィギュレーションがまとめられています。

図 5-4 は、 PIO デザインのさまざまなコンポーネントを示しています。 PIO デザインは、 TX エンジン、 RX エンジン、メモリアクセスコントローラー、パワーマネージメントターンオフコントローラーという 4 つの主な部分に分かれています。

PIO_TO_CTRL.v PIO ターンオフコントローラーモジュール

PIO_RX_ENGINE.v 32 ビットの受信エンジン

PIO_TX_ENGINE.v 32 ビットの送信エンジン

PIO_EP_MEM_ACCESS.v エンドポイントメモリアクセスモジュール

PIO_EP_MEM.v エンドポイントメモリ

表 5‐3: PIO コンフィギュレーション

コア X1 x2 x4 x8

PCIe 用統合ブロック PIO_64 PIO_64、PIO_128

PIO_64、PIO_128、PIO_256

PIO_64、PIO_128(1)、

PIO_256

注記:1. コアは、 128 ビット x8 8.0Gb/s コンフィギュレーションおよび 500MHz ユーザークロック周波数をサポートしていません。


図 5‐4: PIO デザインのコンポーネント

表 5‐2: PIO ファイルの構造 (続き)

ファイル説明

X12455

UltraScale FPGA Gen3 Integrated Block for PCI Express (Configured as an Endpoint)

EP_TX EP_RX

PIO_TO_CTRLep_io_mem

ep_mem32

ep_mem64

ep_mem_erom

EP_MEM

PIO_EP

PIO

PIO_INTR_CTRL






PIO の動作

PIO 読み出しトランザクション

図 5-5 は、 PIO デザインへの連続するメモリ読み出しリクエストを表しています。受信エンジンは、初の TLP が完全に受信されるとすぐに、 m_axis_rx_tready をディアサートします。次の読み出しトランザクションは、送信エンジンが compl_done_o をアサートし、初のリクエストが完全に送信されたことを示すコンプリーションが生成された後にのみ受け入れられます。


図 5‐5:連続する読み出しトランザクション

user_clk


m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast





compl_done

m_axis_cc_tdata[63:0]

m_axis_cc_tvalid

m_axis_cc_tready

m_axis_cc_tkeep[1:0]

m_axis_cc_tlast

DS1DS0 DS3DS2 DS1DS0 DS3DS2

0x3

FIRST_BE FIRST_BE

LAST_BE LAST_BE

0

DS1DS0 DW0 DS2 - - DW1

0x3 0x1






PIO 書き込みトランザクション

図 5-6 は、 PIO デザインへの連続するメモリ書き込みリクエストを表しています。次の書き込みトランザクションは、メモリアクセスユニットが wr_busy_o をディアサートし、初のリクエストに関連するデータがメモリアパーチャへすべて書き込まれたことを示した後にのみ受け入れられます。

デバイス使用率

表 5-4 に、 PIO デザインの FPGA リソース使用量を示します。


図 5‐6:連続する書き込みトランザクション

user_clk


m_axis_cq_tvalid

m_axis_cq_tready


m_axis_cq_tlast







wr_busy

compl_done

DS1DS0 DS3DS2 DW1DW0 DS1DS0 DS3DS2 DW1DW0

0x3

FIRST_BE FIRST_BE

LAST_BE LAST_BE

FIRST_BE FIRST_BE

0

0

0xF 0xF

X12522

表 5‐4: PIO デザインの FPGA リソース使用率

リソース使用されているリソース数

LUT 300

フリップフロップ 500

ブロック RAM 4






コンフィギュレーターサンプルデザイン

Vivado IDE で生成したルートポートコンフィギュレーションの UltraScale Devices Gen3 Integrated Block for PCIe® には、コンフィギュレーターサンプルデザインが含まれます。これは、ルートポートの統合ブロックがエンドポイントとの間でアプリケーションレベルトランザクションを開始するのに小限必要なセットアップを示した合成可能な軽量デザインです。

システムの概要

電源投入後、システム内のデバイスが互いにアプリケーション固有の通信を開始する前に PCI Express デバイスはセットアップを実行する必要があります。通信を開始するには、 PCI Express リンクで接続された少なくとも 2 つのデバイスがそれぞれのコンフィギュレーション空間を初期化し、エニュメレーションを実行する必要があります。

PCI Express のエニュメレーションとコンフィギュレーションを容易にするため、ルートポートはコンフィギュレーション読み出し (CfgRd) および書き込み (CfgWr) TLP をエンドポイントやスイッチなどのダウンストリームデバイスに送信し、これらデバイスのコンフィギュレーション空間をセットアップします。このプロセスが完了すると、メモリ読み出し (MemRd TLP) および書き込み (MemWr TLP) など高次の通信を PCI Express システム内で実行できます。

ここで説明するコンフィギュレーターサンプルデザインは、接続された 1 つの PCI Express エンドポイントのコンフィギュレーション空間のエニュメレーションとコンフィギュレーションに必要なコンフィギュレーショントランザクションを実行し、アプリケーション固有の通信を実行できるようにします。

コンフィギュレーターサンプルデザインのハードウェア

コンフィギュレーターサンプルデザインは、次に示す 4 つの上位ブロックで構成されます。

• ルートポート : ルートポートとしてコンフィギュレーションした UltraScale Devices Gen3 Integrated Block for PCIe コア。

• コンフィギュレーターブロック : ルートポートに接続された PCI Express エンドポイントのコンフィギュレーション空間と通信する論理ブロック。

• コンフィギュレーター ROM: コンフィギュレーショントランザクションをコンフィギュレーターブロックに供給する読み出し専用メモリ。

• PIO マスター : データパケットを交換し、受信データが有効かどうかをチェックすることによってエンドポイントに接続されたユーザーロジックと通信する論理ブロック。データパケットは 1 DWORD に制限され、 CPU によって生成されるトラフィックのタイプを表します。

注記: RTL コードでは、コンフィギュレーターブロック、コンフィギュレーター ROM、およびルートポートはコンフィギュレーターラッパーと呼ばれる 1 つのラッパーファイルに論理的にグループ化されます。

提供されるコンフィギュレーターサンプルデザインは、ザイリンクス Endpoint コアに含まれる PIO スレーブサンプルと組み合わせて使用するように設計されています (第 6 章「テストベンチ」参照)。 PIO マスターはコンフィギュレーションラッパーとの通信の方法を例として示したもので、これを使用するとブリングアップとデバッグが簡単に行えます。コンフィギュレーターサンプルデザインを一部修正すると、ほかのエンドポイントと組み合わせて使用できます。






図 5-7 に、コンフィギュレーターサンプルデザインの各コンポーネントを示します。


図 5‐7: コンフィギュレーターサンプルデザインのコンポーネント

PIO Master Configurator

Gen3Integrated BlockFor PCI Express(Configured as

Root Port)

Data Checker

Controller

PacketGenerator

Controller

CompletionDecoder

PacketGenerator

TX Mux

X14683






図 5-8 に、システム全体でブロックがどのように接続されているかを示します。

コンフィギュレーターブロック

コンフィギュレーターブロックは CfgRd および CfgWr TLP を生成し、これらをルートポートコンフィギュレーションの統合ブロックの AXI4-Stream インターフェイスに送信します。コンフィギュレーターブロックがどの TLP を生成するかは、コンフィギュレーター ROM の内容によって決まります。

どのコンフィギュレーショントラフィックを生成するかは、個々のシステム要件に応じてユーザーが事前に決定します。コンフィギュレーショントラフィックは、コンフィギュレーターの一部として合成されるメモリ初期化ファイル (コンフィギュレーター ROM) にエンコードされます。コンフィギュレーターブロックとこれに接続されたコンフィギュレーター ROM は、実際のエンベデッドデザインの一部として使用できるように設計されています。

コンフィギュレーターブロックはコンフィギュレーション ROM ファイルを 1 行ずつ読み出し、そこに指定されている TLP を送信します。サポートされる TLP タイプはメッセージ、データ付きメッセージ、コンフィギュレーション書き込み (タイプ 0)、およびコンフィギュレーション読み出し (タイプ 0) です。コンフィギュレーションパケットの場合、コンフィギュレーターブロックはコンプリーションが返されてから次の TLP を送信します。コンプリーション TLP の各フィールドが期待値と一致しない場合、 PCI Express コンフィギュレーションエラーとなります。ただしコンプリーション TLP のデータフィールドはチェック対象には含まれず、無視されます。

注記: コンフィギュレーターブロックにはコンプリーションタイムアウトのメカニズムがないため、コンプリーションが返されない場合、コンフィギュレーターブロックはいつまでも待機します。


図 5‐8: コンフィギュレーターサンプルデザイン

Configurator Example Design

Integrated Root Port

Configurator Wrapper

ConfiguratorBlock

ConfiguratorROM

AXI4-Stream Interface

AXI4-Stream Interface Pass-Through

PIO Master

IntegratedEndpoint Model

PIO SlaveEndpoint Design

Root PortDUT forPCI Express

PCI Express Fabric

X14684






コンフィギュレーターブロックには次のパラメーターがあり、これらはユーザーが変更できます。

• TCQ: デザインのすべてのレジスタによってモデル化される clock-to-out 遅延。

• EXTRA_PIPELINE: タイミングの目的で受信 AXI4-Stream インターフェイスに追加するパイプラインステージの挿入を制御します。

• ROM_FILE: 実行するコンフィギュレーション手順を格納したファイルの名前。

• ROM_SIZE: データを格納した ROM_FILE の行数 (= 送信 TLP の数/2)。

• REQUESTER_ID: 送信される TLP のリクエスター ID フィールドの値。

コンフィギュレーターブロックデザインを使用する場合、すべての TLP トラフィックがコンフィギュレーターブロックを通過する必要があります。コンフィギュレーションプロセスを開始するには、コアが user_lnk_up をアサートした後にユーザーデザインが start_config 入力を 1 クロックサイクルの間アサートする必要があります。start_config の後、コンフィギュレーターブロックはコンフィギュレーション ROM に指定されたコンフィギュレーション手順を実行します。コンフィギュレーションの間、コアの AXI4-Stream インターフェイスはコンフィギュレーターブロックが制御します。コンフィギュレーションの後、すべての AXI4-Stream トラフィックはユーザーアプリケーション (このサンプルデザインでは PIO マスター ) を経由します。コンフィギュレーションが終了すると、 finished_config がアサートされます。何らかの理由によりコンフィギュレーションが正しく完了しなかった場合、 failed_config もアサートされます。

PCIe® v2.2 5.0Gb/s リンクをサポートしたシステムで使用する場合、コンフィギュレーターブロックはプロセスの開始時に 2.5Gb/s から 5.0Gb/s へのリンクアップトレーニングを試みます。この機能は、コンフィギュレーターラッパーの LINK_CAP_MAX_LINK_SPEED パラメーターで有効にします。

このコンフィギュレーターでは、ユーザーは受信 AXI4-Stream インターフェイスに対して受信データスロットリングを実行できません。このため、スロットリング制御用のルートポート入力はコンフィギュレーターラッパーには含まれません (m_axis_rx_tready と rx_np_ok)。これはコンフィギュレーターサンプルデザインの制限であり、ルートポートコンフィギュレーションのコア自体にはこの制限はありません。したがって、コンフィギュレーターサンプルデザインと接続するユーザーデザインは、受信データをラインレートで受け入れる必要があります。

コンフィギュレーター ROM

コンフィギュレーター ROM には、 PCI Express エンドポイントをコンフィギュレーションするために必要なコンフィギュレーショントランザクションが格納されます。この ROM はコンフィギュレーターブロックと接続し、これらのトランザクションを PCI Express リンク経由で送信します。

このデザインに付属のサンプル ROM ファイルは、 UltraScale Devices Gen3 Integrated Block for PCIe および PIO サンプルデザインのコンフィギュレーションに必要な動作を示しています。

コンフィギュレーター ROM は、ほかのエンドポイントおよび PCI Express システムトポロジに合わせてカスタマイズできます。必要なコンフィギュレーショントランザクションは、ルートポートと通信するエンドポイントによって異なります。詳細は、エンドポイントのマニュアルを参照してください。

ROM ファイルは、Verilog 仕様 (IEEE 1364-2001) セクション 17.2.8 ($readmemb 関数を使用してデータを RAM または ROM にプリロードする方法について説明したセクション) で定義されたフォーマットに準拠しています。 Verilog スタイルのコメントを使用できます。

シミュレータまたは合成ツールはこのファイルを読み出し、見つかった各メモリ値をメモリ内の 1 つの位置として使用します。数値を見やすくするためにアンダースコア (_) で区切ることができます。この場合、新しいメモリ位置とは見なされません。

指定された各コンフィギュレーショントランザクションは、 2 つの隣接するメモリロケーションを使用します。

• 初のロケーションはヘッダーフィールドを指定します。ヘッダーフィールドは偶数アドレスにあります。

• 2 つ目のロケーションは 32 ビットデータペイロードを指定します。 CfgRd TLP とデータなしメッセージはロケーションを使用しませんが、ロケーション自体は存在します。データペイロードは奇数アドレスにあります。






ヘッダーについては、メッセージと CfgRd/CfgWr TLP は異なるフィールドを使用します。すべての TLP については、2 ビットで TLP タイプを指定します。メッセージについては、メッセージルーティングとメッセージコードを指定します。 CfgRd/CfgWr TLP については、ファンクション番号、レジスタ番号、および初の DWORD のバイトイネーブルを指定します。具体的なビットレイアウトは、サンプル ROM ファイルを参照してください。

PIO マスター

PIO マスターは、ユーザーアプリケーションデザインがコンフィギュレーターブロックと通信する方法を示します。 PIO マスターはコンフィギュレーターブロックに対して適切なタイミングでリンクパートナーをブリングアップするように指示し、ブリングアップが正しく完了した後、バストラフィックを生成および消費します。また、エンドポイントコアから PCI Express リンクを経由して PIO スレーブサンプルデザインに対して書き込みと読み出しを実行し、リンクおよびエンドポイントの基本動作を確認します。

PIO マスターは、ルートポートによって user_lnk_up がアサートされるまで待機します。次にアサートされると、コンフィギュレーターブロックに対して start_config をアサートします。コンフィギュレーターブロックが finished_config をアサートすると、 PIO マスターは PIO スレーブデザインの各 BAR に対して書き込みと読み出しを実行します。書き込んだデータと読み出したデータが一致していると、 PIO マスターは pio_test_finished 出力をアサートします。データが一致しない場合、またはコンフィギュレーターブロックがエンドポイントを正しくコンフィギュレーションできなかった場合、 PIO マスターは pio_test_failed 出力をアサートします。pio_test_restart 入力を 1 クロックサイクルの間アサートすると、 PIO マスターは動作を再開します。

コンフィギュレーターファイルの構造

表 5-5 は、コンフィギュレーターサンプルデザインファイルの構造を説明しています。

表 5‐5:サンプルデザインファイルの構造

ファイル説明

xilinx_pcie_uscale_rp.v コンフィギュレーターサンプルデザインの上位ラッパーファイル

cgator_wrapper.v コンフィギュレーターおよびルートポートのラッパー

cgator.v コンフィギュレーターサブブロックのラッパー

cgator_cpl_decoder.v コンプリーションデコーダー

cgator_pkt_generator.v コンフィギュレーション TLP ジェネレーター

cgator_tx_mux.v 送信 AXI4-Stream 多重化 (MUX) ロジック

cgator_gen2_enabler.v 5.0Gb/s への速度変更モジュール

cgator_controller.v コンフィギュレーター送信エンジン

cgator_cfg_rom.data コンフィギュレーター ROM ファイル

pio_master.v PIO マスターのラッパー

pio_master_controller.v PIO マスターの TX および RX エンジン

pio_master_checker.v 入力されるユーザーアプリケーションのコンプリーション TLP のチェック

pio_master_pkt_generator.v ユーザーアプリケーションの TLP の生成






コンフィギュレーションサンプルデザインの階層は次のとおりです。

xilinx_pcie_uscale_rp.v

• cgator_wrapper

° pcie_uscale_core_top (ソースディレクトリ内)このディレクトリには、ルートポートコンフィギュレーションのコアのソースファイルがすべて含まれます。

° cgator

- cgator_cpl_decoder

- cgator_pkt_generator

- cgator_tx_mux

- cgator_gen2_enabler

- cgator_controller

このディレクトリには、 <cgator_cfg_rom.data> (ROM_FILE で指定) が含まれます。

• pio_master

° pio_master_controller

° pio_master_checker

° pio_master_pkt_generator

注記: cgator_cfg_rom.data は、 ROM データファイルのデフォルト名です。これは、 ROM_FILE パラメーターの値を変更してオーバーライドできます。

まとめ

コンフィギュレーターサンプルデザインは、ルートポートとしてコンフィギュレーションした場合の UltraScale Devices Gen3 Integrated Block for PCIe の機能をデモンストレーションとして示した合成可能デザインです。 Vivado IDE によって提供されるこのサンプルは、 PCI Express エニュメレーションおよびコンフィギュレーションのターゲットとしてエンドポイント PIO サンプルを使用します。このデザインは、 ROM ファイルの内容を変更するとほかのエンドポイントをターゲットにできます。






コアの生成

Vivado IDE でデフォルト値を使用してコアを生成するには、次の手順に従います。

1. Vivado IP カタログを起動します。

2. [File] → [New Project] をクリックします。

3. プロジェクト名とロケーションを入力して [Next] をクリックします。この例では、 project_name.cpg および project_dir を使用します。

4. New Project ウィザードのページでは、ソース、既存の IP、または制約を追加しないでください。

5. [Part] タブ (図 5-9) で、次のようにオプションを選択します。

° [Family]: Kintex® UltraScale

° [Device]: xcku040

° [Package]: ffva1156

° [Speed Grade]: -3

注記:サポートされないシリコンデバイスを選択すると、コアリストのコアが淡色表示 (利用できない) されます。

6. 後に表示されるプロジェクトサマリページで、 [OK] をクリックします。

7. Vivado IP カタログで、 [Standard Bus Interfaces] → [PCI Express] を展開表示し、 [UltraScale Devices Gen3 Integrated Block for PCIe] コアをダブルクリックして [Customize IP] ダイアログボックスを表示します。

8. [Component Name] にコアの名前を入力します。

注記: この例では、 <component_name> を使用します。


図 5‐9:デバイスの選択






9. [Device/Port Type] ドロップダウンメニューから、コアの適切なデバイス /ポートタイプ (エンドポイントまたはルートポート ) を選択します。

10. [OK] をクリックし、デフォルトのパラメーターを使用してコアを生成します。

11. デザインの [Sources] ウィンドウで、 XCI ファイルを右クリックして [Generate] をクリックします。

12. [All] をクリックして、デフォルトのパラメーターでコアを生成します。


図 5‐10: コンフィギュレーションパラメーター






サンプルデザインのシミュレーション

サンプルデザインを使用すると、 Vivado Design Suite で生成した PCI Express エンドポイントおよびルートポート用コアのサンプルデザインプロジェクトのビヘイビアーを簡単にシミュレーションして確認できます。

現在サポートされているシミュレータは次のとおりです。

• Vivado シミュレータ (デフォルト )

• Mentor Graphics 社 QuestaSim

• Cadence 社 Incisive Enterprise Simulator (IES)

• Synopsys 社 Verilog Compiler Simularor (VCS)

シミュレータでは、両方のデザインコンフィギュレーションのサンプルデザインと共に提供されているサンプルデザインのテストベンチおよびテストケースを使用します。

すべてのプロジェクト (PCI Express コア) で、デフォルトの Vivado シミュレータを使用するシミュレーションは、次の方法で実行できます。

1. [Sources] ウィンドウでサンプルプロジェクトファイル (.xci) を右クリックし、 [Open IP Example Design] をクリックします。

サンプルプロジェクトが作成されます。

2. 画面左側にある Flow Navigator の [Simulation] の下にある [Run Simulation] を右クリックし、 [Run Behavioral Simulation] をクリックします。

重要: 合成後およびインプリメンテーション後のシミュレーションオプションは、 PCI Express ブロックではサポートされていません。

[Run Behavioral Simulation] を実行した後、 [Tcl Console] ビューおよび [Log] ビューの [Simulation] タブで、コンパイルおよびエラボレーション段階を確認できます。

3. Tcl コンソールで、「run all」と入力し、 Enter キーを押します。これで、サンプルデザインのテストベンチで提供されているテストケースに従ってシミュレーションが実行されます。

シミュレーションが完了したら、結果は Tcl コンソールビューで確認できます。

Vivado IDE で、シミュレーションの設定を変更する場合は、次の手順に従います。

1. Flow Navigator の [Simulation] の下にある [Simulation Settings] をクリックします。

2. [Target simulator] を [QuestaSim/ModelSim Simulator]、 [Incisive Enterprise Simulator (IES)] または [Verilog Compiler Simulator] のいずれかに設定します。

3. [Simulator] タブで、 [Run Simulation] → [Run Behavioral Simulation] をクリックします。

4. プロンプトが表示されたら、変更するため [Yes] をクリックし、シミュレータを実行します。






エンドポイントコンフィギュレーション

エンドポイントコンフィギュレーションの UltraScale Devices Gen3 Integrated Block for PCIe コアで提供されているシミュレーション環境では、 PIO サンプルデザインに対して簡単なメモリアクセステストが実行されます。トランザクションはルートポートモデルにより生成され、 PIO サンプルデザインがそれに応答します。

• PCI Express TLP ( トランザクション層パケット ) はテストベンチの送信ユーザーアプリケーション (pci_exp_usrapp_tx) によって生成されます。これが TLP を送信すると、ログファイル (tx.dat) も生成されます。

• PCI Express TLP はテストベンチの受信ユーザーアプリケーション (pci_exp_usrapp_rx) によって受信されます。ユーザーアプリケーションが TLP を受信すると、ログファイル (rx.dat) も生成されます。

テストベンチの詳細は、 240 ページの「エンドポイント用ルートポートモデルテストベンチ」を参照してください。

サンプルデザインの合成およびインプリメンテーション

サンプルデザインの合成とインプリメンテーションを行うには、 Vivado Design Suite で次の手順を実行します。

1. XCI ファイルを右クリックして、 [Open IP Example Design] をクリックします。

新しい Vivado ツールのウィンドウに、プロジェクトディレクトリにある example_project という名前のプロジェクトが開きます。

2. Flow Navigator で [Run Synthesis] または [Run Implementation] をクリックします。

ヒント : 合成とインプリメンテーションの両方を実行する場合は、 [Run Implementation] を先にクリックします。合成、インプリメンテーション、ビットストリーム生成を実行するには、 [Generate Bitstream] をクリックします。





第 6章

テストベンチこの章では、 Vivado® Design Suite で提供されているテストベンチについて説明します。

エンドポイント用ルートポートモデルテストベンチ

PCI Express のルートポートモデルは、提供されている PIO (Programmed Input/Output) デザインまたはユーザーデザインで使用できるテストプログラムインターフェイスを提供するテストベンチ環境です。ルートポートモデルは、カスタマーデザインをシミュレーションするため、ダウンストリームの PCI Express TLP トラフィックを生成するソースを提供し、また、シミュレーション環境でカスタマーデザインからアップストリームの PCI Express TLP トラフィックを受信するデスティネーションを提供します。

テストベンチを簡単に作成できるよう、ルートポートモデルのソースコードが含まれています。コンフィギュレーション空間の初期化、 TLP トランザクションの作成、 TLP ログの生成、テストの作成・検証のためのインターフェイスの提供といった大きな作業はすべて完了していて、エンドポイントコアのテストベンチのインフラストラクチャの開発に時間を費やすのではなく、デザインの機能が正しいことを検証することに時間が割けるようになっています。

ルートポートモデルの構成は次のとおりです。

• テストプログラミングインターフェイス (TPI)。 PCI Express 用のエンドポイントデバイスをシミュレーションできます。

• テストプログラム TPI の使用方法を確認できるサンプルテスト。

• すべてのルートポートモデルコンポーネントに対する Verilog ソースコード。テストベンチをカスタマイズできます。





第 6 章: テストベンチ

図 6-1 は PIO デザインと併用したルートポートモデルを説明しています。

アーキテクチャ

ルートポートモデルは、図 6-1 で説明されているように、次のブロックから構成されています。

• dsport (ルートポート )

• usrapp_tx

• usrapp_rx

• usrapp_com (Verilog のみ)

usrapp_tx および usrapp_rx ブロックは、エンドポイント DUT (Design Under Test) への TLP の送受信のため dsport ブロックとインターフェイスします。このエンドポイント DUT は、 PCIe 用エンドポイントと PIO デザイン (表示)、またはカスタマーデザインから構成されています。

usrapp_tx ブロックは、PCI Express リンクからエンドポイント DUT までの伝送のため dsport ブロックに TLP を送信します。これを受けて、エンドポイント DUT デバイスは、 PCI Express リンクから dsport ブロックまで TLP を送信します。これらの TLP はこの後 usrapp_rx ブロックに送信されます。 PCI Express ロジック上で交信する場合、 dsport およびコアはデータリンク層および物理リンク層の処理を行います。 usrapp_tx と usrapp_rx の両方が、 TLP 処理やログファイルの出力などの共有ファンクションのため usrapp_com ブロックを使用します。トランザクションシーケンスまたはテストプログラムは usrapp_tx ブロックによって開始され、エンドポイントデバイスのファブリックインターフェイスをスティミュレートします。エンドポイントデバイスからの TLP 応答は、 usrapp_rx ブロックが受信します。 usrapp_tx と usrapp_rx 間の通信により、 usrapp_rx ブロックがエンドポイントデバイスからの TLP を受信すると、 usrapp_tx ブロックは正しいビヘイビアーを検証し、適宜処理することができるようになります。


図 6‐1:ルートポートモデルおよび最上位エンドポイント

Test Program

Endpoint DUT for PCI Express

PCI Express Fabric

Endpoint Core for PCI Express

PIO Design

dsport

usrapp_tx

usrapp_com

usrapp_rx

Output Logs

Root Port Model TPI for

Express

X12468






シミュレーションタイムアウトの設定

このコアのシミュレーションモデルは、シミュレーション中に妥当な時間内でリンクが確立されるよう、タイムアウトを設定できます。『PCI Express Specification, rev. 2.1』 [参照 2] によると、Link Training Status State Machine (LTSSM) のステートに関連付けられたさまざまなタイムアウトがあります。コアは、タイムアウトを設定できない Recovery Speed_1 LTSSM ステートを除いて、シミュレーションで 256 の係数でこれらのタイムアウトを設定します。

テストの選択

表 6-1 ではルートポートモデルで提供されているテストについて説明し、その後のセクションでは Verilog テストについて詳しく説明します。

Verilog テストの選択

ルートポートモデルで使用される Verilog テストモデルでは、実行されるテスト名をコマンドラインパラメーターとしてシミュレータに指定できます。

実行されるテストを変更する場合は、テストファイル sample_tests1.v および pio_tests.v に定義されている TESTNAME の値を変更します。このメカニズムは、 Mentor Graphics QuestaSim で使用されています。 Vivado シミュレータは、 -testplusarg オプションを使用して TESTNAME を指定します。たとえば次のようになります。

demo_tb.exe -gui -view wave.wcfg -wdb wave_isim -tclbatch isim_cmd.tcl -testplusarg TESTNAME=sample_smoke_test0.

波形ダンピング

シミュレータ波形のダンピングの詳細は、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 17] を参照してください。

Verilog フロー

ルートポートモデルは、 +dump_all コマンドラインパラメーターをシミュレータに指定して、保管するシミュレーション波形を出力するためのメカニズムを提供します。

表 6‐1:ルートポートモデルで提供されるテスト

テスト名 Verilog でテスト説明

sample_smoke_test0 VerilogPCI タイプ 0 コンフィギュレーション読み出し TLP を出力し、コンプリーション TLP を待ちます。その後、返された値とデバイス /ベンダー ID を比較します。

sample_smoke_test1 Verilog

sample_smoke_test0 と同じ操作を実行しますが、予期タスクを使用します。このテストでは 2 つのテストプログラムスレッドが用いられます。 1 つは PCI タイプ 0 コンフィギュレーション読み出し TLP を出力し、もう 1 つはデータ TLP 予期タスクのあるコンプリーションを出力します。このテストは予期タスクを利用するパラレルテストです。ユーザーデザインからの TLP の受信を確認できます。また、 TLP の順序が重要出ない場合の TLP の受信確認用にも使用できます。






出力のログ

サンプルデザインまたはカスタマーデザインでテストエラーが発生した場合にそれらをデバッグします。通常は、シミュレーション用の波形ファイルをチェックして、標準出力に対し表示されているメッセージとこれを相互比較します。しかし、このアプローチは非常に時間がかかるため、ルートポートモデルには、エラーの発生しているテストケースのデバッグプロセスをスピードアップさせるための出力ログ機能が含まれています。

ルートポートモデルは、各シミュレーションの実行で 3 つのファイル (tx.dat、 rx.dat、および error.dat) を生成します。ログファイルの rx.dat および tx.dat には、ルートポートモデルで送信および受信されたすべての TLP が各ファイルに詳細に記録されています。

ヒント : 特定テストケースで予想される TLP 伝送を理解していれば、エラーを隔離しやすくなります。

ログファイル error.dat は、予期タスクと併用して使用します。予期タスクを利用するテストプログラムは、標準出力に一般的なエラーメッセージを生成します。予期エラーが原因で発生した比較エラーについての詳細は、error.dat に記述されています。

パラレルテストプログラム

ルートポートモデルでサポートされているテストには 2 つのタイプがあります。

• シーケンシャルテスト : 1 つのプロセス内に複数のテストが含まれ、シーケンシャルプログラムと類似した動作をします。 244 ページの「テストプログラム: pio_writeReadBack_test0」で説明されているテストがシーケンシャルテストの例です。シーケンシャルテストは、イベントの順序がわかっている場合の動作を検証するのに非常に便利です。

• パラレルテスト : 2 つ以上のプロセススレッドのあるテストです。 sample_smoke_test1 テストはプロセススレッドが 2 つあるパラレルテストの例です。パラレルテストは、イベントの順序が不明の、まとまったイベントを検証するのに非常に便利です。

一般的なパラレルテストには、コマンドスレッドが 1 つ、予期スレッドが 1 つ以上あります。これらのスレッドはともに機能して、デバイス機能を検証します。コマンドスレッドの役割は、デバイスが TLP を受信および生成できるように必要な TLP トランザクションを作成することです。予期スレッドの役割は、予期 TLP の受信を検証します。ルートポートモデルの TPI には、パラレルテストと併用する予期タスクがすべて揃っています。

サンプルデザインはターゲット専用デバイスであるため、 PIO デザインを使用している間はパラレルテストプログラムはコンプリーション TLP のみを期待します。しかし、カスタマーデザインで使用する場合は、どの TLP タイプも期待できる予期タスクの完全ライブラリを使用することができます (バスマスター機能も含めることが可能)。

テストの説明

ルートポートモデルにはテストプログラムインターフェイス (TPI) があります。 TPI を使用することにより、一連の Verilog タスクを起動することでテストを作成できます。すべてのルートポートモデルテストは、次の 6 つの手順に従う必要があります。

1. 各テスト名に対し条件付比較を実行します。

2. シミュレーションが停止した場合のマスタータイムアウトを設定します。

3. リセットおよびリンクアップを待ちます。

4. エンドポイントのコンフィギュレーション空間を初期化します。

5. ルートポートモデルとエンドポイント DUT 間で TLP を送受信します。

6. テストが問題なく完了したことを確認します。






テストプログラム: pio_writeReadBack_test0

ルートポートモデルの拡張

ルートポートモデルは PIO デザインと共に機能するよう作成されており、 PIO デザインの制限事項に基づいて特定チェックを実行し、警告を出力するように設計されています。ルートポートモデルが Vivado IP カタログで生成された場合、これらのチェックおよび警告はデフォルトで有効になっています。しかし、これを無効化して、デザインに反映させないことも可能です。

PIO デザインは、 I/O BAR を 1 つ、 Mem64 BAR を 1 つ、 Mem32 BAR を 2 つ (そのうち 1 つは EROM 空間である必要がある) サポートするよう作成されているため、デフォルトでは、コアがこの要件を満たすようコンフィギュレーションされていることを確認するデバイスコンフィギュレーション中に、ルートポートモデルがチェックを実行するようになっています。このチェックで違反が検出されると、警告メッセージが表示され、エラーのある BAR がテストベンチで無効になります。このチェックは、 pci_exp_usrapp_tx.v ファイルで pio_check_design 変数をゼロに設定すると無効になります。

1. else if(testname == "pio_writeReadBack_test1"2. begin3. // This test performs a 32 bit write to a 32 bit Memory space and performs a read back4. TSK_SIMULATION_TIMEOUT(10050);5. TSK_SYSTEM_INITIALIZATION;6. TSK_BAR_INIT;7. for (ii = 0; ii <= 6; ii = ii + 1) begin 8. if (BAR_INIT_P_BAR_ENABLED[ii] > 2'b00) // bar is enabled 9. case(BAR_INIT_P_BAR_ENABLED[ii])10. 2'b01 : // IO SPACE11. begin 12. $display("[%t] : NOTHING: to IO 32 Space BAR %x", $realtime, ii);13. end 14. 2'b10 : // MEM 32 SPACE15. begin 16. $display("[%t] : Transmitting TLPs to Memory 32 Space BAR %x",17. $realtime, ii);18. //------------------------------------------------------------------------19. // Event : Memory Write 32 bit TLP20. //------------------------------------------------------------------------21. DATA_STORE[0] = 8'h04;22. DATA_STORE[1] = 8'h03;23. DATA_STORE[2] = 8'h02;24. DATA_STORE[3] = 8'h01;25. P_READ_DATA = 32'hffff_ffff; // make sure P_READ_DATA has known initial value 26. TSK_TX_MEMORY_WRITE_32(DEFAULT_TAG, DEFAULT_TC, 10'd1, BAR_INIT_P_BAR[ii][31:0] , 4'hF,

4'hF, 1'b0);27. TSK_TX_CLK_EAT(10);28. DEFAULT_TAG = DEFAULT_TAG + 1;29. //------------------------------------------------------------------------30. // Event : Memory Read 32 bit TLP31. //------------------------------------------------------------------------32. TSK_TX_MEMORY_READ_32(DEFAULT_TAG, DEFAULT_TC, 10'd1, BAR_INIT_P_BAR[ii][31:0], 4'hF,

4'hF);33. TSK_WAIT_FOR_READ_DATA;34. if (P_READ_DATA != {DATA_STORE[3], DATA_STORE[2], DATA_STORE[1], DATA_STORE[0] }) 35. begin36. $display("[%t] : Test FAILED --- Data Error Mismatch, Write Data %x != Read Data %x",

$realtime,{DATA_STORE[3], DATA_STORE[2], DATA_STORE[1], DATA_STORE[0]}, P_READ_DATA);37. end38. else39. begin40. $display("[%t] : Test PASSED --- Write Data: %x successfully received", $realtime,

P_READ_DATA);41. end






ルートポートモデルの TPI タスクリスト

ルートポートモデルの TPI タスクを次に示し、その後に続く各表で詳しく説明します。

• 表 6-2、「テストセットアップタスク」

• 表 6-3、「TLP タスク」

• 表 6-4、「BAR 初期化タスク」

• 表 6-5、「サンプル PIO デザインタスク」

• 表 6-6、「予期タスク」

表 6‐2: テストセットアップタスク

名称入力説明

TSK_SYSTEM_INITIALIZATION なし

トランザクションインターフェイスのリセット、およびルートポートモデルとエンドポイント DUT 間のリンクアップを待ちます。

このタスクはエンドポイントコア初期化前に起動する必要があります。

TSK_USR_DATA_SETUP_SEQ なしグローバルの 4096 バイトの DATA_STORE アレイエントリを 0 から 4095 までの順次値に初期化します。

TSK_TX_CLK_EAT クロックカウント

31:30 clock_count トランザクションインターフェイスクロックを待ちます。

TSK_SIMULATION_TIMEOUT タイムアウト 31:0

トランザクションインターフェイスクロックの単位でマスターシミュレーションタイムアウト値を設定します。このタスクは、すべての DUT テストが完了していることを確認するのに使用します。

表 6‐3: TLP タスク

名称入力説明

TSK_TX_TYPE0_CONFIGURATION_READ

tag_

reg_addr_

first_dw_be_

7:0

11:0

3:0

ルートポートモデルからのタイプ 0 PCI Express コンフィギュレーション読み出し TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr に送信します。

エンドポイント DUT から返された CplD は、コンプリーター ID としてグローバル EP_BUS_DEV_FNS の内容を使用します。

TSK_TX_TYPE1_CONFIGURATION_READ

tag_

reg_addr_

first_dw_be_

7:0

11:0

3:0

ルートポートモデルからのタイプ 1 PCI Express コンフィギュレーション読み出し TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。


TSK_TX_TYPE0_CONFIGURATION_WRITE

tag_

reg_addr_

reg_data_

first_dw_be_

7:0

11:0

31:0

3:0

ルートポートモデルからのタイプ 0 PCI Express コンフィギュレーション書き込み TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。







TSK_TX_TYPE1_CONFIGURATION_WRITE

tag_

reg_addr_

reg_data_

first_dw_be_

7:0

11:0

31:0

3:0

ルートポートモデルからのタイプ 1 PCI Express コンフィギュレーション書き込み TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。


TSK_TX_MEMORY_READ_32

tag_

tc_

len_

addr_

last_dw_be_

first_dw_be_

7:0

2:0

10:0

31:0

3:0

3:0

ルートポートモデルからの PCI Express メモリ読み出し TLP を、エンドポイント DUT の 32 ビットメモリアドレス addr_ に送信します。

リクエストは、リクエスター ID としてグローバル RP_BUS_DEV_FNS の内容を使用します。

TSK_TX_MEMORY_READ_64

tag_

tc_

len_

addr_

last_dw_be_

first_dw_be_

7:0

2:0

10:0

63:0

3:0

3:0

ルートポートモデルからの PCI Express メモリ読み出し TLP を、エンドポイント DUT の 64 ビットメモリアドレス addr_ に送信します。


TSK_TX_MEMORY_WRITE_32

tag_

tc_

len_

addr_

last_dw_be_

first_dw_be_

ep_

7:0

2:0

10:0

31:0

3:0

3:0

–

ルートポートモデルからの PCI Express メモリ書き込み TLP を、エンドポイント DUT の 32 ビットメモリアドレス addr_ に送信します。


グローバル DATA_STORE バイトアレイは、書き込みデータをタスクに渡すために使用されます。

TSK_TX_MEMORY_WRITE_64

tag_

tc_

len_

addr_

last_dw_be_

first_dw_be_

ep_

7:0

2:0

10:0

63:0

3:0

3:0

–

ルートポートモデルからの PCI Express メモリ書き込み TLP を、エンドポイント DUT の 64 ビットメモリアドレス addr_ に送信します。


グローバル DATA_STORE バイトアレイは、書き込みデータをタスクに渡すために使用されます。

表 6‐3: TLP タスク (続き)

名称入力説明






TSK_TX_COMPLETION

req_id_

tag_

tc_

len_

comp_status_

15:0

7:0

2:0

10:0

6:0

グローバル RP_BUS_DEV_FNS をコンプリーター ID として、 req_id_ input をリクエスター ID として使用し、 PCI Express コンプリーション TLP をルートポートモデルからエンドポイント DUT に送信します。

comp_status_ input は、次のいずれかに設定できます。

3'b000 = トランザクションが正常に完了

3'b001 = サポートされないリクエスト

3'b010 = コンフィギュレーションリクエストのリトライステータス

3'b100 = コンプリーターの中断

TSK_TX_COMPLETION_DATA

req_id_

tag_

tc_

len_

byte_count_

lower_addr_

comp_status_

ep_

15:0

7:0

2:0

10:0

11:0

6:0

2:0

–

グローバル RP_BUS_DEV_FNS をコンプリーター ID として、 req_id_ input をリクエスター ID として使用し、 PCI Express のデータ付きコンプリーション TLP をルートポートモデルからエンドポイント DUT に送信します。

TSK_TX_MESSAGE

tag_

tc_

len_

data_

message_rtg_

message_code_

7:0

2:0

10:0

63:0

2:0

7:0

PCI Express メッセージ TLP をルートポートモデルからエンドポイント DUT 送信します。


TSK_TX_MESSAGE_DATA

tag_

tc_

len_

data_

message_rtg_

message_code_

7:0

2:0

10:0

63:0

2:0

7:0

PCI Express のデータ付きメッセージ TLP をルートポートモデルからエンドポイント DUT に送信します。

グローバル DATA_STORE バイトアレイは、メッセージデータをタスクに渡すために使用されます。


TSK_TX_IO_READ

tag_

addr_

first_dw_be_

7:0

31:0

3:0

PCI Express I/O 読み出し TLP を、ルートポートモデルからエンドポイント DUT の I/O アドレス addr_[31:2] に送信します。


TSK_TX_IO_WRITE

tag_

addr_

first_dw_be_

data

7:0

31:0

3:0

31:0

PCI Express I/O 書き込み TLP を、ルートポートモデルからエンドポイント DUT の I/O アドレス addr_[31:2] に送信します。



名称入力説明






TSK_TX_BAR_READ

bar_index

byte_offset

tag_

tc_

2:0

31:0

7:0

2:0

PCI Express の 1 Dword のメモリ 32、メモリ 64、または I/O 読み出し TLP をルートポートモデルから、エンドポイント DUT の BAR bar_index からの byte_offset に対応するターゲットアドレスに送信します。このタスクは、 BAR bar_index が初期化中にどのようにコンフィギュレーションされているかに基づいて、該当する読み出し TLP を送信します。このタスクは、 TSK_BAR_INIT が完了した後にのみ呼び出すことができます。


TSK_TX_BAR_WRITE

bar_index

byte_offset

tag_

tc_

data_

2:0

31:0

7:0

2:0

31:0

PCI Express の 1 Dword のメモリ 32、メモリ 64、または I/O 読み出し TLP をルートポートから、エンドポイント DUT の BAR bar_index からの byte_offset に対応するターゲットアドレスに送信します。

このタスクは、 BAR bar_index が初期化中にどのようにコンフィギュレーションされているかに基づいて、該当する書き込み TLP を送信します。このタスクは、 TSK_BAR_INIT が完了した後にのみ呼び出すことができます。

TSK_WAIT_FOR_READ_DATA なし

エンドポイント DUT が送信したデータ付きの次のコンプリーション TLP を待ちます。完了すると、 CpID からのデータの初の Dword がグローバル P_READ_DATA に格納されます。このタスクは、レースコンディションを避けるため、データ付きのコンプリーションを要求する TPI での任意の読み出しタスクの直後に呼び出す必要があります。

デフォルトでは、このタスクはローカルにタイムアウトし、トランザクションインターフェイスクロックが 1000 サイクルした後にシミュレーションを終了させます。ローカルタイムアウトが呼び出し中のテストの実行に戻り、シミュレーションタイムアウトにならないように、グローバル cpld_to_finish を 0 にセットすることができます。グローバル cpld_to が 1 にセットされている場合は、このタスクがタイムアウトになっており、P_READ_DATA の内容が無効であることを示すので、このケースのテストプログラムはグローバル cpld_to をチェックする必要があります。


名称入力説明






TSK_TX_SYNCHRONIZE

first_

active_

last_call_

tready_sw_

-

-

-

-

AXI4-Stream リクエスターリクエストまたはコンプリーターコンプリーションインターフェイスの Ready 信号のアサートを待機し、ログファイルの出力を現在アクティブの各トランザクションに同期させます。

first_ input はパケットの開始を示します。

active_ input は、トランザクションが現在処理中であることを示します。

last_call_ input はパケットの終了を示します。

tready_sw input は、リクエスターリクエストまたはコンプリーターコンプリーションインターフェイスの Ready 信号を選択します。

TSK_BUILD_RC_TO_PCIE_PKT

rc_data_QW0

rc_data_QW1

m_axis_rc_tkeep

m_axis_rc_tlast

63:0

63:0

KEEP_WIDTH-1:0

-

ログ作成のため、リクエスターコンプリーションインターフェイスの AXI4-Stream パケットをディスクリプターパケットフォーマットから PCIe TLP パケットフォーマットに変換します。

TSK_BUILD_CQ_TO_PCIE_PKTcq_datacq_bem_axis_cq_tdata

63:07:063:0

ログ作成のため、コンプリーターリクエストインターフェイスの AXI4-Stream パケットをディスクリプターパケットフォーマットから PCIe TLP パケットフォーマットに変換します。

TSK_BUILD_CPLD_PKT

cq_addr

cq_be

m_axis_cq_tdata

63:0

7:0

63:0

エンドポイント DUT から受信したメモリ読み出しに対してコンプリーションまたはデータ付きのコンプリーションを返します。


名称入力説明

表 6‐4: BAR 初期化タスク

名称入力説明

TSK_BAR_INIT なし

PCI Express ファブリックを使用したエンドポイントデバイスへのベースアドレスレジスタ初期化タスクの標準シーケンスを実行します。エンドポイント PCI BAR 範囲要件のスキャンを実行し、必要なメモリおよび I/O 空間マッピングの計算を実行し、後に、アクセス準備可能になるようにエンドポイントをプロ

グラムします。

完了後、テストプログラムはデバイスへのメモリおよび I/O トランザクションを開始できます。このファンクションは、このエンドポイントがどのように初期化されたかを示すメモリおよび I/O テーブルを標準出力に表示します。このタスクは、ルートポートモデル内のテストプログラムで使用可能なグローバル変数も初期化します。このタスクは、TSK_SYSTEM_INITIALIZATION の後にのみ呼び出されます。

TSK_BAR_SCAN なし

エンドポイントに対するメモリおよび I/O 要件を判断するため、PCI Express ロジックを使用し、 PCI タイプ 0 コンフィギュレーション書き込みおよびコンフィギュレーション読み出しのシーケンスを実行します。

このタスクはこの情報を BAR_INIT_P_BAR_RANGE[] というグローバルアレイに保存します。このタスクは、TSK_SYSTEM_INITIALIZATION の後にのみ呼び出されます。






TSK_BUILD_PCIE_MAP なし

メモリおよび I/O マッピングアルゴリズムを実行し、エンドポイント要件に基づいて、メモリ 32、メモリ 64、および I/O 空間を割り当てます。

このタスクは PIO デザインの制限事項に合わせて機能するようにカスタマイズされており、 TSK_BAR_SCAN が完了した後にのみ呼び出されます。

TSK_DISPLAY_PCIE_MAP なし

エンドポイントコアの PCI ベースアドレスレジスタのメモリマッピング情報を表示します。各 BAR に対し、 BAR 値、 BAR 範囲、 BAR タイプが指定されています。このタスクは、TSK_BUILD_PCIE_MAP の完了後にのみ呼び出されます。

表 6‐4: BAR 初期化タスク (続き)

名称入力説明

表 6‐5:サンプル PIO デザインタスク

名称入力説明

TSK_TX_READBACK_CONFIG なし

PCI Express ロジックを使用して、エンドポイントデバイスのベースアドレスレジスタ、 PCI コマンドレジスタ、および PCIe デバイス制御レジスタへの PCI タイプ 0 コンフィギュレーション読み出しを連続して実行します。

このタスクは、 TSK_SYSTEM_INITIALIZATION の後にのみ呼び出されます。

TSK_MEM_TEST_DATA_BUS bar_index 2:0

入力 bar_index がポイントしている I/O またはメモリアドレスに対し 32 ビットのデータテストを実行して、PIO デザインの FPGA ブロック RAM データバスインターフェイスが正しく接続されているかどうかをテストします。

しっかりとテストを実行するには、 PIO デザインで使用されている各ブロック RAM に対し 1 回ずつ、このタスクを 4 回呼び出します。

TSK_MEM_TEST_ADDR_BUSbar_index

nBytes

2:0

31:0

入力 bar_index がポイントしている I/O またはメモリアドレスで開始するアドレステストを実行して、 PIO デザインの FPGA ブロック RAM アドレスバスインターフェイスが正しく接続されているかどうかをテストします。

しっかりとテストを実行するには、 PIO デザインで使用されている各ブロック RAM に対し 1 回ずつ、このタスクを 4 回呼び出します。さらに、 nBytes 入力で個々のブロック RAM の全体的なサイズを指定する必要があります。

TSK_MEM_TEST_DEVICEbar_index

nBytes

2:0

31:0

入力 nBytes で指定された範囲で、入力 bar_index によりポイントされているブロック RAM で始まるすべてのビットに対し、インクリメント /デクリメントテストを実行することによって、PIO デザインの FPGA ブロック RAM の各ビットの整合性をテストします。

しっかりとテストを実行するには、 PIO デザインで使用されている各ブロック RAM に対し 1 回ずつ、このタスクを 4 回呼び出します。さらに、 nBytes 入力で個々のブロック RAM の全体的なサイズを指定する必要があります。






TSK_RESET リセット 0

PERSTn を開始します。 PERSTn 信号にリセット信号をアサートさせます。リセット信号のアサートには TSK_RESET (1’b1) を使用し、リセット信号のリリースには TSK_RESET (1’b0) を使用します。

TSK_MALFORMED malformed_bits

7:0

不正に構成された TLP を生成するための制御ビットです。

0001: このタスクが呼び出された直後の I/O リクエストおよびコンフィギュレーションリクエストに対して不正に構成された TLP を生成する

0010: ルートポートで受信したメモリ読み出しリクエストに対して不正に構成されたコンプリーション TLP を生成する

表 6‐5:サンプル PIO デザインタスク (続き)

名称入力説明

表 6‐6:予期タスク

名称入力出力説明

TSK_EXPECT_CPLD

traffic_class

td

ep

attr

length

completer_id

completer_status

bcm

byte_count

requester_id

tag

address_low

2:0

-

-

1:0

10:0

15:0

2:0

-

11:0

15:0

7:0

6:0

予想ステータス

traffic_class、 td、 ep、 attr、 length、 payload が一致するデータ付きのコンプリーション TLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。

TSK_EXPECT_CPL

traffic_class

td

ep

attr

completer_id

completer_status

bcm

byte_count

requester_id

tag

address_low

2:0

-

-

1:0

15:0

2:0

-

11:0

15:0

7:0

6:0


traffic_class、 td、 ep、 attr、 length が一致するデータなしのコンプリーション TLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。






TSK_EXPECT_MEMRD

traffic_class

td

ep

attr

length

requester_id

tag

last_dw_be

first_dw_be

address

2:0

-

-

1:0

10:0

15:0

7:0

3:0

3:0

29:0


ヘッダーフィールドが一致する 32 ビットのアドレスメモリ読み出し TLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。このタスクは、バスマスターデザインと併用する場合にのみ使用できます。

TSK_EXPECT_MEMRD64

traffic_class

td

ep

attr

length

requester_id

tag

last_dw_be

first_dw_be

address

2:0

-

-

1:0

10:0

15:0

7:0

3:0

3:0

61:0


ヘッダーフィールドが一致する 64 ビットのアドレスメモリ読み出し TLP を待ちます。正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。

このタスクは、バスマスターデザインと併用する場合にのみ使用できます。

TSK_EXPECT_MEMWR

traffic_class

td

ep

attr

length

requester_id

tag

last_dw_be

first_dw_be

address

2:0

-

-

1:0

10:0

15:0

7:0

3:0

3:0

29:0


ヘッダーフィールドが一致する 32 ビットのアドレスメモリ書き込み TLP を待ちます。正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。


TSK_EXPECT_MEMWR64

traffic_class

td

ep

attr

length

requester_id

tag

last_dw_be

first_dw_be

address

2:0

-

-

1:0

10:0

15:0

7:0

3:0

3:0

61:0


ヘッダーフィールドが一致する 64 ビットのアドレスメモリ書き込み TLP を待ちます。正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。


表 6‐6:予期タスク (続き)







ルートポート用のエンドポイントモデルテストベンチ

ルートポートコンフィギュレーションのコアのエンドポイントモデルテストベンチは、簡単なサンプルテストベンチで、コンフィギュレーターデザインと PCI Express エンドポイントモデルを接続して、物理的なシステムに対する 2 つのデバイスであるかのように操作できます。自己初期化し、バストラフィックを生成および使用するロジックからコンフィギュレーターサンプルデザインは構成されているため、システム動作をモニタリングしシミュレーションを終了させるロジックをこのサンプルテストベンチはインプリメントするだけです。

このエンドポイントモデルテストベンチは次のものから構成されています。

• すべてのエンドポイントモデルコンポーネントに対する Verilog または VHDL のソースコード

• PIO スレーブデザイン

図 6-1 は、コンフィギュレーターサンプルデザインと接続しているエンドポイントモデルを説明しています。

アーキテクチャ

エンドポイントモデルは次のブロックから構成されています

• PCI Express エンドポイント (エンドポイントコンフィギュレーションのコア) モデル

• 次のものから構成されている PIO スレーブデザイン

° PIO_RX_ENGINE

° PIO_TX_ENGINE

° PIO_EP_MEM

° PIO_TO_CTRL

PIO_RX_ENGINE および PIO_TX_ENGINE ブロックは、ルートポート DUT (Design Under Test) への TLP の送受信のため ep ブロックとインターフェイスします。ルートポート DUT は、ルートポートとしてコンフィギュレーションされているコア、およびコンフィギュレーターサンプルデザイン (コンフィギュレーターブロックと PIO マスターデザインまたはカスタマーデザインから成る ) から構成されています。

PIO スレーブデザインについては、「PIO (Programmed Input/Output): エンドポイントのサンプルデザイン」を参照してください。

TSK_EXPECT_IOWR

td

ep

requester_id

tag

first_dw_be

address

data

-

-

15:0

7:0

3:0

31:0

31:0


ヘッダーフィールドが一致する I/O 書き込み TLP を待ちます。正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。


表 6‐6:予期タスク (続き)







デザインのシミュレーション

Mentor Graphics QuestaSim Simulator を使用するシミュレーションをサポートするために、シミュレーションスクリプト (simulate_mti.do) がモデルと共に提供されています。

サンプルのシミュレーションスクリプトは、次のディレクトリ内に含まれています。

<project_dir>/<component_name>/simulation/functional

エンドポイントモデルを使用するコンフィギュレーターサンプルデザインのシミュレーション手順は、第 4 章の「シミュレーション」を参照してください。

注記: Cadence IES の場合、次の作業コンストラクトを手動で cds.lib ファイルに挿入する必要があります。

DEFINE WORK WORK

シミュレーションタイムアウトの設定

このコアのシミュレーションモデルは、シミュレーション中に妥当な時間内でリンクが確立されるよう、タイムアウトを設定できます。『PCI Express Specification, rev. 2.1』 [参照 2] によると、Link Training Status State Machine (LTSSM) のステートに関連付けられたさまざまなタイムアウトがあります。コアは、タイムアウトを設定できない Recovery Speed_1 LTSSM ステートを除いて、シミュレーションで 256 の係数でこれらのタイムアウトを設定します。

波形ダンピング

シミュレータ波形のダンピングの詳細は、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 17] を参照してください。

出力のログ

テストベンチはメッセージを出力し、シミュレーションログに記録されます。このログには次のものが発生した時間が記録されています。

• user_reset がディアサートされた時間

• user_lnk_up がアサートされた時間

• cfg_done がコンフィギュレーターによりアサートされた時間

• pio_test_finished が PIO マスターによりアサートされた時間

• シミュレーションタイムアウト (pio_test_finished または pio_test_failed がアサートされなかった場合)





付録 A

アップグレードこの付録では、新版 IP コアへのアップグレードについて説明します。

Vivado Design Suite でのアップグレード

このセクションでは、 Vivado® Design Suite でこの IP コアの新版にアップグレードする際の、ユーザーロジックおよびポートの変更について説明します。

パラメーターの変更点

表 A-1 に、新版コアのパラメーターの変更点をまとめています。

ポートの変更点

[Shared Logic] ページで [Include GT Wizard in core] をオンにした場合、表 A-2 に示すポートが追加されます。

表 A‐1:パラメーターの変更点

ユーザーパラメーター名表示名新規/変更/削除詳細デフォルト

値

ext_xvc_vsec_enableAdd the PCIe XVC-VSEC to the Example Design 新規

オンにすると、 PCIe XVC-VSEC がサンプルデザインに追加されます。オンにする場合は、 PCIe 拡張コンフィギュレーション空間を有効にする必要があります。

False

表 A‐2: GT Wizard をコアに含めた場合に追加されるポート

名称方向幅 (選択したリンク幅による)

rxdfeagchold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxdfecfokhold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxdfelfhold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxdfekhhold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxdfetap2hold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH









付録 A: アップグレード

MSI-X を有効にすると、表 A-3 に示すポートがコア境界に追加されます。










rxdfeuthold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxdfevphold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxoshold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxlpmgchold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxlpmhfhold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxlpmlfhold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

rxlpmoshold_in 出力 PL_LINK_CAP_MAX_LINK_WIDTH

表 A‐3: MSI‐X を有効にした場合に追加されるポート


cfg_interrupt_msi_function_number 入力 4 ビット

表 A‐2: GT Wizard をコアに含めた場合に追加されるポート (続き)







7 シリーズ Gen2 コアから UltraScale デバイス Gen3 コアへの移行

このセクションでは、 7 シリーズ Gen2 コアから UltraScale™ デバイス Gen3 コアへの移行に必要な情報を示します。

注記: 7 シリーズ Gen3 コアのインターフェイスは、 UltraScale デバイス Gen3 コアのインターフェイスと同じです。

7 シリーズ Gen2 コアでは、ユーザーアプリケーション側で PCIe パケットを構成するため、 AXI4-Stream (および TRN) ペイロードのバイト順序は PCIe バスのバイト順序と一致します。ただし UltraScale デバイス Gen3 v3.1 コアでは、ディスクリプター後のペイロードのバイト順序は AXI4-Stream プロトコルに準拠したエンディアンとなります。

AXI4-Stream TX および RX インターフェイスは、「概要」の図 1-1 を参照してください。

PCIe 3.1 AXI4 ST 強化型インターフェイス

コンプリーターリクエスト (CQ) インターフェイス

m_axis_rx_tstrb (64 ビットインターフェイス専用)

表 A-5 に、 m_axis_rx_tstrb 信号バスの生成に使用される CR インターフェイス信号を示します。

表 A‐4: AXI‐4 ST の基本的な受信インターフェイスと AXI4‐ST の強化型 CQ インターフェイスの信号マッピング

AXI4‐Stream (基本) 受信インターフェイス名

AXI4‐Stream (強化型) CQ インターフェイス名

異なる点

m_axis_rx_tlast m_axis_cq_tlast なし

m_axis_rx_tdada

(64/128)

m_axis_cq_tdata

(64/128/256)

なし

m_axis_rx_tvalid m_axis_cq_tvalid なし

m_axis_rx_tready m_axis_cq_tready なし

m_axis_rx_tstrb m_axis_cq_tkeep および

m_axis_cq_tuser

「m_axis_rx_tstrb (64 ビットインターフェイス専用)」参照

m_axis_rx_tuser m_axis_cq_tuser および

m_axis_cq_tdata (ディスクリプター )

「m_axis_rx_tuser」参照

rx_np_ok 同等信号なし N/A

rx_np_req pcie_cq_np_req なし

同等信号なし pcie_cq_np_req_count N/A

表 A‐5: m_axis_rx_tstrb の CR インターフェイス信号

AXI4‐Stream (強化型) CQ インターフェイス名ニーモニック

m_axis_cq_tkeep (データ幅/32)

m_axis_cq_tuser[3:0] first_be [3:0]

m_axis_cq_tuser[7:4] last_be [3:0]

m_axis_cq_tuser[39:8] byte_en [31:0]






m_axis_rx_tuser

表 A-6 に、 m_axis_rx_tuser 信号バスの生成に使用される CR インターフェイス信号を示します。

AXI4‐Stream リクエスターコンプリーション (RC) インターフェイス

ユーザーロジックで生成されたリクエストに対するコンプリーションは、リクエストコンプリーション (RC) インターフェイスに現れます。

表 A‐6: m_axis_rx_tuser の CR インターフェイス信号


ニーモニックAXI4‐Stream (強化型)

CQ インターフェイス名ニーモニック注記

m_axis_rx_tuser[0] rx_ecrc_err m_axis_cq_tuser[41] Discontinue まったく同等とは言えない

m_axis_rx_tuser[1] rx_err_fwd 同等信号なし N/A N/A

m_axis_rx_tuser[9:2] rx_bar_hit[7:0] m_axis_cq_tdata[114:112]


Bar ID [2:0]

Request Type [3:0]

• 128/256 ビットインターフェイスとして仮定

• データバス上にディスクリプターが存在する場合のみ有効 (sop = 1)

m_axis_rx_tuser[14:10]

(128 ビットのみ)

rx_is_sof[4:0] m_axis_cq_tuser[40] sop m_axis_rx_tuser[13:10] はすべて 0 に接続可能


(128 ビットのみ)

rx_is_eof [4:0] m_axis_cq_tlast

m_axis_cq_tuser[39:8]

byte_en[31:0]

同等信号なし m_axis_cq_tuser[10:8] addr_offset[2:0]

同等信号なし m_axis_cq_tuser[12] tph_present

同等信号なし m_axis_cq_tuser[14:13] tph_type[1:0]

同等信号なし m_axis_cq_tuser[15] tph_indirect_tag_en

同等信号なし m_axis_cq_tuser[23:16] tph_st_tag[7:0]

同等信号なし m_axis_cq_tuser[27:24] seq_num[3:0]

同等信号なし m_axis_cq_tuser[59:28] parity

表 A‐7: AXI4‐Stream RC インターフェイス信号のマッピング


AXI4‐Stream (強化型) RC インターフェイス名

異なる点

m_axis_rx_tlast m_axis_rc_tlast なし

m_axis_rx_tdada

(64/128)

m_axis_rc_tdata

(64/128/256)

なし

m_axis_rx_tvalid m_axis_rc_tvalid なし

m_axis_rx_tready m_axis_rc_tready なし

m_axis_rx_tstrbm_axis_rc_tkeep および

m_axis_rc_tuser

「m_axis_rx_tstrb (64 ビットインターフェイス専用)」参照






m_axis_rx_tstrb (64 ビットインターフェイス専用)

表 A-8 に、 m_axis_rx_tstrb 信号バスの生成に使用されるリクエスターコンプリーションインターフェイス信号を示します。

m_axis_rx_tuser

表 A-9 に、 m_axis_rx_tuser 信号バスの生成に使用されるリクエスターコンプリーションインターフェイス信号を示します。

m_axis_rx_tuserm_axis_rc_tuser および

m_axis_rc_tdata (ディスクリプター )

「m_axis_rx_tuser」参照

rx_np_ok 同等信号なし N/A

rx_np_req 同等信号なしcq_np_req および cq_np_req_count が NP FC で使用される

表 A‐8: m_axis_rx_tstrb の RC インターフェイス信号

AXI4‐Stream (強化型) RC インターフェイス名ニーモニック

m_axis_rc_tkeep (データ幅/32)

m_axis_rc_tuser[31:0] byte_en [31:0]

表 A‐9: m_axis_rx_tuser の RC インターフェイス信号

AXI4‐Stream 受信インターフェイス名

ニーモニックAXI4‐Stream コンプリーター

リクエストインターフェイス名ニーモニック注記

m_axis_rx_tuser[0] rx_ecrc_err m_axis_rc_tuser[41] Discontinue まったく同等とは言えない

m_axis_rx_tuser[1] rx_err_fwd m_axis_rx_tdata[46]Poisonedcompletion

データバス上にディスクリプターが存在する場合のみ有効 (is_sof0/is_sof1=1)

m_axis_rx_tuser[9:2] rx_bar_hit[7:0] N/A (CQ インターフェイスを参照)

N/A N/A


(128 ビットのみ)rx_is_sof[4:0]

m_axis_rc_tuser[32]

m_axis_rc_tuser[33]

(256 ビットでストラドルが有効な場合のみ)

is_sof_0

is_sof_1

256 ビット RC インターフェイスにはストラドルオプションがあります。このオプションを有効にすると、コアは、同じビート内に 2 つのコンプリーション TLP をストラドルできます。

is_sof_1 は、 256 ビットインターフェイスでストラドルオプションが有効な場合のみ使用されます。

表 A‐7: AXI4‐Stream RC インターフェイス信号のマッピング (続き)


AXI4‐Stream (強化型) RC インターフェイス名

異なる点






AXI4‐Stream (強化型) コンプリーターコンプリーションインターフェイス

s_axis_tx_tstrb

Byte Count Descriptor (s_axis_cc_tdata[28:16]) と s_axis_cc_tkeep を併用し、ペイロードの後の Dword に対してバイトイネーブルを示します。

表 A-11 に、 tlast がアサートされない場合のコンプリーターコンプリーションインターフェイスからの s_axis_cc_tkeep と AXI4-Stream (基本) 送信インターフェイスからの s_axis_tx_tstrb 信号バスのマッピングを示します。


(128 ビットのみ)rx_is_eof [4:0]

m_axis_rc_tuser[37:34]


(256 ビットでストラドルが有効な場合のみ)

Is_eof_0[3:0]

Is_eof_1[3:0]

is_eof_1 は、 256 ビットインターフェイスでストラドルオプションが有効な場合のみ使用されます。

同等信号なし m_axis_rc_tuser[74:43] Parity

表 A‐10: AXI‐4 Stream (基本) の送信インターフェイスと AXI4‐Stream (強化型) のコンプリーターコンプリーションインターフェイスの信号マッピング

AXI4‐Stream (基本) 送信インターフェイス名

AXI4‐Stream (強化型) コンプリーターコンプリーション

インターフェイス名異なる点

s_axis_tx_tlast s_axis_cc_tlast なし

s_axis_tx_tdada (64/128) s_axis_cc_tdata (64/128/256) なし

s_axis_tx_tvalid s_axis_cc_tvalid なし

s_axis_tx_tready s_axis_cc_tready なし

s_axis_tx_tstrbs_axis_cc_tkeep


「s_axis_tx_tstrb」参照

s_axis_tx_tuser s_axis_cc_tuser 「s_axis_tx_tuser」参照

tx_buf_av[5:0]

tx_terr_drop

tx_cfg_req N/A なし

tx_cfg_gnt N/A なし

表 A‐11: s_axis_cc_tkeep と s_axis_tx_tstrb のマッピング

インターフェイス幅 s_axis_tx_tstrb s_axis_cc_tkeep

640x0F 0x1

0xFF 0x3

128

0x0F 0x1

0xFF 0x3

0xFFF 0x7

0xFFFF 0xF

表 A‐9: m_axis_rx_tuser の RC インターフェイス信号 (続き)

AXI4‐Stream 受信インターフェイス名

ニーモニックAXI4‐Stream コンプリーター

リクエストインターフェイス名ニーモニック注記






s_axis_tx_tuser

表 A-12 に、コンプリーターコンプリーションインターフェイスからの s_axis_cc_tuser と AXI4-Stream (基本) 送信インターフェイスからの s_axis_tx_tuser 信号バスのマッピングを示します。

AXI4‐Stream リクエスターリクエストインターフェイス

s_axis_tx_tstrb

表 A-14 に、 s_axis_tx_tstrb 信号バスの生成に使用されるリクエスターリクエストインターフェイス信号を示します。




コンプリーターリクエストインターフェイス名

ニーモニック注記

s_axis_tx_tuser[0] tx_ecrc_gen s_axis_cc_tdata[95] Force ECRC 同等機能

s_axis_tx_tuser[1] tx_err_fwd s_axis_cc_tdata[46] Poisoned completion

同等機能

s_axis_tx_tuser[2] tx_str N/A N/A 同等信号なし

s_axis_tx_tuser[2] t_src_dsc s_axis_cc_tuser[0] Discontinue 同等機能

表 A‐13: AXI‐4 Stream リクエスターリクエストインターフェイス信号のマッピング

AXI4‐Stream (基本) 送信インターフェイス名

AXI4‐Stream (強化型) リクエスターリクエストインターフェイス名

異なる点

s_axis_tx_tlast s_axis_rq_tlast なし

s_axis_tx_tdada

(64/128)

s_axis_rq_tdata

(64/128/256)なし

s_axis_tx_tvalid s_axis_rq_tvalid なし

s_axis_tx_tready s_axis_rq_tready なし

s_axis_tx_tstrb s_axis_rq_tkeep 「s_axis_tx_tstrb」参照

s_axis_tx_tuser s_axis_rq_tuser 「s_axis_tx_tuser」参照

tx_buf_av[5:0]

pcie_tfc_nph_av /

pcie_tfc_npd_av/

pcie_rq_tag_av

「tx_buf_av」参照

tx_terr_drop

tx_cfg_req N/A この機能は存在しない

tx_cfg_gnt N/A この機能は存在しない

表 A‐14: m_axis_rx_tuser のリクエスターリクエストインターフェイス信号

AXI4‐Stream (強化型) リクエスターリクエストインターフェイス名ニーモニック

s_axis_rq_tkeep

s_axis_rq_tuser[3:0] first_be [3:0]

s_axis_rq_tuser[7:4] last_be [3:0]






表 A-15 に、 tlast がアサートされない場合のコンプリーターコンプリーションインターフェイスからの s_axis_cc_tkeep と AXI4-Stream (基本) 送信インターフェイスからの s_axis_tx_tstrb 信号バスのマッピングを示します。

s_axis_tx_tuser

表 A-16 に、リクエスターリクエストインターフェイスからの s_axis_rq_tuser と AXI4-Stream (基本) 送信インターフェイスからの s_axis_tx_tuser 信号バスのマッピングを示します。

tx_buf_av

バッファーの利用可否は、 AXI4-Stream (強化型) リクエスターリクエストインターフェイス用の 3 つの個別信号に分かれています。

• pcie_tfc_nph_av は、コアの送信側においてノンポステッド TLP 用に現在有効なヘッダークレジットを示します。

• pcie_tfc_npd_av は、コアの送信側においてノンポステッド TLP 用に現在有効なペイロードクレジットを示します。

• pcie_rq_tag_av は、コアの送信側においてノンポステッド TLP 用に現在有効なヘッダークレジットを示します。


インターフェイス幅 s_axis_tx_tstrb s_axis_rq_tkeep

640x0F 0x1

0xFF 0x3

128

0x0F 0x1

0xFF 0x3

0xFFF 0x7

0xFFFF 0xF

表 A‐16: s_axis_rq_tuser と s_axis_tx_tuser のマッピング



リクエスターリクエストインターフェイス名

ニーモニック注釈

s_axis_tx_tuser[0] tx_ecrc_gen s_axis_rq_tdata[127] Force ECRC 同等機能

s_axis_tx_tuser[1] tx_err_fwd s_axis_rq_tdata[79]Poisoned Request

同等

機能

s_axis_tx_tuser[2] tx_str N/A N/A 同等信号なし

s_axis_tx_tuser[2] t_src_dsc s_axis_rq_tuser[11] discontinue同等

機能






その他のインターフェイス

表 A-17 では、コアが提供するその他のインターフェイスについて説明しています。

表 A‐17: コアが提供するその他のインターフェイス

インターフェイス説明注記

送信フロー制御コアが提供するフロー制御情報を要求するためにユーザーアプリケーションが使用します。

コアへのフロー制御入力の設定に基づいて、このインターフェイスはユーザーアプリケーションに次を提供します。

• ポステッド /ノンポステッドヘッダーフロー制御クレジット

• ポステッド /ノンポステッドデータフロー制御クレジット

• コンプリーションヘッダーフロー制御クレジット

• コンプリーションデータフロー制御クレジット

類似機能

コンフィギュレーションマネージメント

コンフィギュレーション空間レジスタの読み出しおよび書き込みに使用します。

類似機能

コンフィギュレーションステータス

コアのコンフィギュレーション状況を示す情報 (ネゴシエートされたリンク幅やスピード、コアの電力ステート、コンフィギュレーションエラー ) を提供します。

コンフィギュレーション専用レジスタのポートと類似機能

コンフィギュレーション受信メッセージ

リンクからのデコード可能なメッセージ、データに関連するパラメーター、受信されたメッセージタイプのロジックを示します。

受信メッセージ TLP のステータスポートと類似機能

コンフィギュレーション送信メッセージ

ユーザーアプリケーションがコアへメッセージを送信する場合に使用されます。ユーザーアプリケーションが送信メッセージタイプとデータ情報をコアへ提供し、それに対して Done 信号で応えます。

ファンクションごとのステータス

選択したファンクションを介して、ユーザーアプリケーションからのリクエストを受けてステータスデータを提供します。

エラーレポーティングポートと類似機能

コンフィギュレーション制御

ユーザーアプリケーションとコア間でさまざまな情報を送受信可能にします。ユーザーアプリケーションはこのインターフェイスを使用して次を行います。

• コンフィギュレーション空間の設定

• 修正可能/修正不可能なエラーの有無

• デバイスのシリアル番号の設定

• ダウンストリームバス、デバイス、およびファンクション番号の設定

• ファンクションごとのコンフィギュレーション情報の受信

また、このインターフェイスは、電力ステートが変更されたり、ファンクションレベルのリセットが生じた場合に、ユーザーアプリケーションとコア間のハンドシェイクを実行します。

パワーマネージメントポートと類似機能

コンフィギュレーション割り込みコントローラー

ユーザーアプリケーションがレガシ PCIe 割り込み、 MSI 割り込み、または MSI-X 割り込みをセットできます。コアは、送信されるコンフィギュレーション割り込みに割り込みステータスおよびエラー信号を提供します。

割り込みの生成およびステータスポートと類似機能

コンフィギュレーション拡張

外部にコンフィギュレーションレジスタが実装されている場合、コアがコンフィギュレーション情報をユーザーアプリケーションへ送信することが可能になります。

Received Configuration TLP のステータスポートと類似機能






UltraScale デバイスの PCI Express デザインのパッケージ移行

UltraScale ポートフォリオは、同じパッケージフットプリントを共有する多くのデバイスを提供しています。この移行パスによって、デバイス間でのデザインの移行が簡単に行えるため、デザインサイズの変更が可能になり、またより多くの DSP ブロックが必要になる場合は Virtex® から Kintex® へ移行するなど、特定の機能を充実させることが可能になります。

ほとんどの PCI Express コンフィギュレーションは 1 つのパッケージで簡単に移行できますが、特定 PCI Express インプリメンテーションの移行が不可能なデザインおよび設定もあります。このセクションでは、デバイス間で自由に移行できる PCI Express デザインの作成方法を説明すると同時に、移行できないピンの割り当てについても説明します、

UltraScale ファミリ全体のピン移行の詳細は、『UltraScale アーキテクチャ PCB デザインユーザーガイド』 (UG583) [参照 10] を参照してください。

配置規則

Vivado IP カタログから提供される UltraScale Devices Gen3 Integrated Block for PCIe ソリューションには、タイミングクロージャを達成させるためにいくつかの配置制約があります。 PCI Express ソリューションをパッケージ間で移行する際には、次の 2 つの規則があります。

• 規則 #1 – PCIe インターフェイスのレーン 0 は、 PCI Express ハードブロックより 1 クロック領域上、同じクロック領域、または 1 クロック領域下の GTH クワッドに制限されます。 8 レーンの PCI Express が使用される場合は、 GTH クワッドを隣接するクワッドに配置する必要があります。

• 規則 #2 – 相互接続されている PCIe 統合ブロックと GTH トランシーバーは、同じ SLR (Super Logic Region) 内に配置する必要があります。

これらの 2 つの規則については、次のセクションで詳しく説明します。

GTH の位置

Vivado IDE で生成した PCI Express コアを使用する場合、ザイリンクスは特定の PCI Express ブロックに対して GTH の位置を推奨しています。 GTH の位置は変更できますが、その場合、タイミングクロージャの達成を保証できません。

Vivado 2014.3 ツールのリリース以降、デザインで使用する GT の位置をより柔軟に選択できるようになりました。ユーザーは次を選択できます。

• レーン 0 を配置する PCIe ブロックおよび GTH クワッドの位置

• GT クワッドの位置 (PCIe ブロックより 1 クロック領域上、同じ領域、または 1 クロック領域下)

クワッドの位置を選択すると、残りの GTH の位置は選択したリンク幅に基づいて制約されます。利用可能な GTH は、 SLR の境界や結合されていない GT の影響を受けます。 x8 リンク幅が選択されている場合、使用する 2 つの GTH は隣接配置する必要があります。






図 A-1 では、 x8 PCIe リンク幅の場合に、それぞれの初の GTH クワッドの位置にどのようにレーンが配置されているかを示しています。

スタックドシリコンインターコネクト (SSI) デバイス

SSI デバイスを使用する場合、 PCI Express ハードブロックおよびこのブロックに接続された GTH クワッドは、同じ SRL (Super Logic Region) に配置する必要があります。

図 A-2 に、A2377 パッケージの XCVU125 デバイスを示します。ロケーション Y2 の PCIe 統合ブロックがバンク 228 の GTH を選択することは、 SLR 境界を超えてしまうため不可能です。

X-Ref Target - Figure A-1

図 A‐1: GTH クワッドの位置

PCIe Yx

GT

3

0

1

2

C

7

4

5

6

PCIe Yx

GT

3

0

1

2

C

7

4

5

6

PCIe Yx

GT

3

0

1

2

C

7

4

5

6

GTC

GT GT

X14330







図 A‐2: A2377 パッケージの XCVU125 デバイス

XCVU125 A2377

PCIe Y0

PCIe Y1

PCIe Y2

GT35-32232

GT39-36233

PCIe Y3

GT3-0224

GT7-4225

GT11-8226

GT15-12227

GT19-16228

GT23-20229

GT27-24230

GT31-28231

224

225

226

227

228

229

230

231

232

2

X14329

233






PCI Express 用移行プランの作成

配置規則を考慮した上で、次のように PCI Express のパッケージ移行プランを立てることができます。

1. 図 A-3 の例で示すように D1517 パッケージのデバイスなど、移行するデバイスとパッケージを選択します。

2. 任意の PCI Express のリンク幅を選択します。

3. その PCI Express ロケーションに対して GTH ロケーションをどのように移行すべきかを検証します。

4. SLR 境界を超える問題や結合されていないトランシーバーの問題を認識します。

たとえば、 8 レーン幅で、バンク 229 に GTH が配置されている XCVU095 の PCIe ロケーション Y2 は、XCVU125 へ移行できません。これは、 SLR 境界を超え、規則に違反するためです。図 A-3 を参照してください。

たとえば、 x8 デザインの場合は Y2 にある PCIe 統合ブロックより 1 クロック領域上の GT クワッドであれば、2 つのデバイス間で移行できます。






5. 場合によっては、新しいロケーション制約を生成するために、 IP をコンパイルし直す必要があります。その場合は、 Vivado IDE を使用して、 IP の設定で PCI Express のロケーションをアップデートし、その後、コアを生成します。


図 A‐3:移行の例

X14331

XCVU095D1517

GT3-0224

PCIe Y0

Tan.

GT7-4225

GT11-8226

GT15-12227

GT19-16228

PCIe Y1

PCIe Y2

GT23-20229

GT27-24230

GT31-28231

PCIe Y3

XCVU125 D1517

PCIe Y0

Tan.

PCIe Y1

PCIe Y2

GT35-32232

GT39-36233

PCIe Y3

GT3-0224

GT7-4225

GT11-8226

GT15-12227

GT19-16228

GT23-20229

GT27-24230

GT31-28231

224

225

226

227

228

229

230

231

224

225

226

227

228

229

230

231

232

X8 X8






Tandem コンフィギュレーションの移行

同じパッケージの異なるデバイス間で Tandem コンフィギュレーションデザインを移行する手順は非常にシンプルです。 Tandem PCIe をサポートする PCI Express ブロックが選択されていることを確認してください。

重要: Tandem PCIe は、各デバイスで 1 PCIe ハードブロックに対してのみサポートされます。

Tandem をサポートする PCI Express ブロックのロケーションおよび専用リセットピンの一覧は、表 3-2 を参照してください。





付録 B

GT のロケーションこの付録では、この IP コアの推奨される GT ロケーション一覧を提供します。

FPGA パッケージピンは、表 B-1 と表 B-21 に示す GT ロケーションから直接得られます。このガイドでは、デバイスパッケージ間で異なる特定のパッケージピンについては言及していません。 Vivado [Device] ビューから、次のコマンドを使用して FPGA パッケージピンとそれらに関連する特定 GT ロケーションのファンクションをプリントアウトします。

foreach pin [get_package_pins -of_objects [get_sites GTHE3_CHANNEL_<location>]] {puts "Pin $pin: function [get_property PIN_FUNC $pin]"}

その他に選択可能なロケーションについては、付録 A の「UltraScale デバイスの PCI Express デザインのパッケージ移行」を参照してください。

Kintex UltraScale デバイスの GT ロケーション

表 B-1 ～ B-20 に、 Kintex® UltraScale™ デバイスの推奨される GT ロケーションを示します。

注記:静的な GT ロケーションを使用する場合、 x8 リンク幅はサポートされません。ただし、 Advanced モードの [Enable GT Quad Selection] で GT 選択モードを有効にすると、これらの PCIe ブロックに対して x8 リンク幅を選択できます。詳細は、「UltraScale デバイスの PCI Express デザインのパッケージ移行」を参照してください。

表 B‐1: Kintex UltraScale デバイスの GT ロケーション – FFVA1156

パッケージデバイス PCIe ブロックレーン X1 x2 x4 x8

FFVA1156 XCKU025 X0Y0

レーン 0 X0Y7 X0Y7 X0Y7 X0Y7

レーン 1 X0Y6 X0Y6 X0Y6

レーン 2 X0Y5 X0Y5


レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0





付録 B: GT のロケーション

表 B‐2: Kintex UltraScale デバイスの GT ロケーション – FBVA676 および FBVA900


FBVA676

FBVA900

XCKU035

XCKU040

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

表 B‐3: Kintex UltraScale デバイスの GT ロケーション – RBA676


RBA676 XQKU040

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8






表 B‐4: Kintex UltraScale デバイスの GT ロケーション – SFVA784


SFVA784XCKU035

XCKU040X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0








FFVA1156

XCKU035

XCKU040

XCKU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

XCKU035

XCKU040

XCKU095

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

XCKU060

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

XCKU040

XCKU095

X0Y2

レーン 0 X0Y19 X0Y19 X0Y19

サポートされないレーン 1 X0Y18 X0Y18

レーン 2 X0Y17

レーン 3 X0Y16

XCKU060

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16






表 B‐6: Kintex UltraScale デバイスの GT ロケーション – RFA1156


RFA1156

XQKU040

XQKU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

XQKU060

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

XQKU040

XQKU095

X0Y2

レーン 0 X0Y19 X0Y19 X0Y19


レーン 2 X0Y17

レーン 3 X0Y16

XQKU060

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16








FFVA1517 XCKU060

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16






表 B‐8: Kintex UltraScale デバイスの GT ロケーション – FLVA1517


FLVA1517XCKU085

XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28






表 B‐9: Kintex UltraScale デバイスの GT ロケーション – FLVB1760


FLVB1760 XCKU085

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y31 X1Y31 X1Y31 X1Y31

レーン 1 X1Y30 X1Y30 X1Y30



レーン 4 X1Y27

レーン 5 X1Y26

レーン 6 X1Y25

レーン 7 X1Y24

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35


レーン 2 X1Y33

レーン 3 X1Y32






表 B‐10: Kintex UltraScale デバイスの GT ロケーション – FLVF1924 (XCKU085)


FLVF1924 XCKU085

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28






表 B‐11: Kintex UltraScale デバイスの GT ロケーション – FLVD1924


FLVD1924 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y3

レーン 0 X1Y31 X1Y31 X1Y31


レーン 2 X1Y29

レーン 3 X1Y28

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35


レーン 2 X1Y33

レーン 3 X1Y32

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






表 B‐12: Kintex UltraScale デバイスの GT ロケーション – FLVF1924 (XCKU115)


FLVF1924 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






表 B‐13: Kintex UltraScale デバイスの GT ロケーション – FLVD1517


FLVD1517 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36








FLVB1760 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y31 X1Y31 X1Y31 X1Y31

レーン 1 X1Y30 X1Y30 X1Y30



レーン 4 X1Y27

レーン 5 X1Y26

レーン 6 X1Y25

レーン 7 X1Y24

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35


レーン 2 X1Y33

レーン 3 X1Y32

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






表 B‐15: Kintex UltraScale デバイスの GT ロケーション – FLVA2104


FLVA2104 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y3

レーン 0 X1Y31 X1Y31 X1Y31


レーン 2 X1Y29

レーン 3 X1Y28

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35


レーン 2 X1Y33

レーン 3 X1Y32

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36








FLVB2104 XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






表 B‐17: Kintex UltraScale デバイスの GT ロケーション – FFVB1760 および FFVB2104


FFVB1760

FFVB2104XCKU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y3

レーン 0 X0Y31 X0Y31 X0Y31 X0Y31

レーン 1 X0Y30 X0Y30 X0Y30



レーン 4 X0Y27

レーン 5 X0Y26

レーン 6 X0Y25

レーン 7 X0Y24






表 B‐18: Kintex UltraScale デバイスの GT ロケーション – FFVC1517


FFVC1517 XCKU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y19 X0Y19 X0Y19


レーン 2 X0Y17

レーン 3 X0Y16






表 B‐19: Kintex UltraScale デバイスの GT ロケーション – RLD1517


RLD1517 XQKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






表 B‐20: Kintex UltraScale デバイスの GT ロケーション – RLF1924


RLF1924 XQKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y27 X1Y27 X1Y27 X1Y27

レーン 1 X1Y26 X1Y26 X1Y26



レーン 4 X1Y23

レーン 5 X1Y22

レーン 6 X1Y21

レーン 7 X1Y20

X0Y4

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

X0Y5

レーン 0 X1Y39 X1Y39 X1Y39


レーン 2 X1Y37

レーン 3 X1Y36






Virtex UltraScale デバイスの GT ロケーション

表 B-21 ～ B-34 に、 Virtex® UltraScale デバイスの推奨される GT ロケーションを示します。

注記:静的な GT ロケーションを使用する場合、 x8 リンク幅はサポートされません。ただし、 Advanced モードの [Enable GT Quad Selection] で GT 選択モードを有効にすると、これらの PCIe ブロックに対して x8 リンク幅を選択できます。詳細は、「UltraScale デバイスの PCI Express デザインのパッケージ移行」を参照してください。

表 B‐21: Virtex UltraScale デバイスの GT ロケーション – FFVC1517


FFVC1517

XCVU065

XCVU080

XCVU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

XCVU080

XCVU095X0Y2

レーン 0 X0Y19 X0Y19 X0Y19


レーン 2 X0Y17

レーン 3 X0Y16






表 B‐22: Virtex UltraScale デバイスの GT ロケーション – FFVA2104


FFVA2104XCVU080

XCVU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y3

レーン 0 X0Y27 X0Y27 X0Y27


レーン 2 X0Y25

レーン 3 X0Y24






表 B‐23: Virtex UltraScale デバイスの GT ロケーション – FFVB2104/FFVB1760/FFVD1517


FFVB2104

FFVB1760

FFVD1517

XCVU080

XCVU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y3

レーン 0 X0Y31 X0Y31 X0Y31 X0Y31

レーン 1 X0Y30 X0Y30 X0Y30



レーン 4 X0Y27

レーン 5 X0Y26

レーン 6 X0Y25

レーン 7 X0Y24






表 B‐24: Virtex UltraScale デバイスの GT ロケーション – FFVC2104


FFVC2104 XCVU095

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y3

レーン 0 X0Y31 X0Y31 X0Y31 X0Y31

レーン 1 X0Y30 X0Y30 X0Y30



レーン 4 X0Y27

レーン 5 X0Y26

レーン 6 X0Y25

レーン 7 X0Y24






表 B‐25: Virtex UltraScale デバイスの GT ロケーション – FLVB1760


FLVB1760 XCVU125

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y31 X0Y31 X0Y31 X0Y31

レーン 1 X0Y30 X0Y30 X0Y30



レーン 4 X0Y27

レーン 5 X0Y26

レーン 6 X0Y25

レーン 7 X0Y24

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38



レーン 4 X0Y35

レーン 5 X0Y34

レーン 6 X0Y33

レーン 7 X0Y32






表 B‐26: Virtex UltraScale デバイスの GT ロケーション – FLVA2104


FLVA2104 XCVU125

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y35 X0Y35 X0Y35 X0Y35

レーン 1 X0Y34 X0Y34 X0Y34



レーン 4 X0Y31

レーン 5 X0Y30

レーン 6 X0Y29

レーン 7 X0Y28

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39


レーン 2 X0Y37

レーン 3 X0Y36






表 B‐27: Virtex UltraScale デバイスの GT ロケーション – FLVB2104/FLVC2104/FLVD1517


FLVB2104

FLVC2104

FLVD1517

XCVU125

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y19 X0Y19 X0Y19 X0Y19

レーン 1 X0Y18 X0Y18 X0Y18



レーン 4 X0Y15

レーン 5 X0Y14

レーン 6 X0Y13

レーン 7 X0Y12

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38



レーン 4 X0Y35

レーン 5 X0Y34

レーン 6 X0Y33

レーン 7 X0Y32






表 B‐28: Virtex UltraScale デバイスの GT ロケーション – FLGA2577


FLGA2577 XCVU190

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y19 X0Y19 X0Y19 X0Y19

レーン 1 X0Y18 X0Y18 X0Y18



レーン 4 X0Y15

レーン 5 X0Y14

レーン 6 X0Y13

レーン 7 X0Y12

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38



レーン 4 X0Y35

レーン 5 X0Y34

レーン 6 X0Y33

レーン 7 X0Y32

X0Y4

レーン 0 X0Y47 X0Y47 X0Y47 X0Y47

レーン 1 X0Y46 X0Y46 X0Y46



レーン 4 X0Y43

レーン 5 X0Y42

レーン 6 X0Y41

レーン 7 X0Y40






FLGA2577(続き )

XCVU190(続き )

X0Y5

レーン 0 X0Y59 X0Y59 X0Y59 X0Y59

レーン 1 X0Y58 X0Y58 X0Y58



レーン 4 X0Y55

レーン 5 X0Y54

レーン 6 X0Y53

レーン 7 X0Y52

表 B‐28: Virtex UltraScale デバイスの GT ロケーション – FLGA2577 (続き)







表 B‐29: Virtex UltraScale デバイスの GT ロケーション – FLGB2104 (XCVU160)


FLGB2104 XCVU160

X0Y1

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y2

レーン 0 X0Y35 X0Y35 X0Y35 X0Y35

レーン 1 X0Y34 X0Y34 X0Y34



レーン 4 X0Y31

レーン 5 X0Y30

レーン 6 X0Y29

レーン 7 X0Y28

X0Y3

レーン 0 X0Y43 X0Y43 X0Y43 X0Y43

レーン 1 X0Y42 X0Y42 X0Y42



レーン 4 X0Y39

レーン 5 X0Y38

レーン 6 X0Y37

レーン 7 X0Y36

X0Y4

レーン 0 X0Y55 X0Y55 X0Y55 X0Y55

レーン 1 X0Y54 X0Y54 X0Y54



レーン 4 X0Y51

レーン 5 X0Y50

レーン 6 X0Y49

レーン 7 X0Y48






表 B‐30: Virtex UltraScale デバイスの GT ロケーション – FLGB2104 (XCVU190)


FLGB2104 XCVU190

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38



レーン 4 X0Y35

レーン 5 X0Y34

レーン 6 X0Y33

レーン 7 X0Y32

X0Y4

レーン 0 X0Y47 X0Y47 X0Y47 X0Y47

レーン 1 X0Y46 X0Y46 X0Y46



レーン 4 X0Y43

レーン 5 X0Y42

レーン 6 X0Y41

レーン 7 X0Y40

X0Y5

レーン 0 X0Y59 X0Y59 X0Y59 X0Y59

レーン 1 X0Y58 X0Y58 X0Y58



レーン 4 X0Y55

レーン 5 X0Y54

レーン 6 X0Y53

レーン 7 X0Y52






表 B‐31: Virtex UltraScale デバイスの GT ロケーション – FLGC2104 (XCVU160)


FLGC2104 XCVU160

X0Y0

レーン 0 X0Y11 X0Y11 X0Y11 X0Y11

レーン 1 X0Y10 X0Y10 X0Y10



レーン 4 X0Y7

レーン 5 X0Y6

レーン 6 X0Y5

レーン 7 X0Y4

X0Y1

レーン 0 X0Y23 X0Y23 X0Y23 X0Y23

レーン 1 X0Y22 X0Y22 X0Y22



レーン 4 X0Y19

レーン 5 X0Y18

レーン 6 X0Y17

レーン 7 X0Y16

X0Y2

レーン 0 X0Y35 X0Y35 X0Y35 X0Y35

レーン 1 X0Y34 X0Y34 X0Y34



レーン 4 X0Y31

レーン 5 X0Y30

レーン 6 X0Y29

レーン 7 X0Y28

X0Y3

レーン 0 X0Y43 X0Y43 X0Y43 X0Y43

レーン 1 X0Y42 X0Y42 X0Y42



レーン 4 X0Y39

レーン 5 X0Y38

レーン 6 X0Y37

レーン 7 X0Y36

X0Y4

レーン 0 X0Y55 X0Y55 X0Y55 X0Y55

レーン 1 X0Y54 X0Y54 X0Y54



レーン 4 X0Y51

レーン 5 X0Y50

レーン 6 X0Y49

レーン 7 X0Y48






表 B‐32: Virtex UltraScale デバイスの GT ロケーション – FLGC2104 (XCVU190)


FLGC2104 XCVU190

X0Y0

レーン 0 X0Y11 X0Y11 X0Y11 X0Y11

レーン 1 X0Y10 X0Y10 X0Y10



レーン 4 X0Y7

レーン 5 X0Y6

レーン 6 X0Y5

レーン 7 X0Y4

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15


レーン 2 X0Y13

レーン 3 X0Y12

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38



レーン 4 X0Y35

レーン 5 X0Y34

レーン 6 X0Y33

レーン 7 X0Y32

X0Y4

レーン 0 X0Y47 X0Y47 X0Y47 X0Y47

レーン 1 X0Y46 X0Y46 X0Y46



レーン 4 X0Y43

レーン 5 X0Y42

レーン 6 X0Y41

レーン 7 X0Y40






FLGC2104 (続き )

XCVU190 (続き )

X0Y5

レーン 0 X0Y59 X0Y59 X0Y59 X0Y59

レーン 1 X0Y58 X0Y58 X0Y58



レーン 4 X0Y55

レーン 5 X0Y54

レーン 6 X0Y53

レーン 7 X0Y52

表 B‐32: Virtex UltraScale デバイスの GT ロケーション – FLGC2104 (XCVU190) (続き)







表 B‐33: Virtex UltraScale デバイスの GT ロケーション – FLGB2377


FLGB2377 XCVU440

X0Y0

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y1

レーン 0 X0Y19 X0Y19 X0Y19


レーン 2 X0Y17

レーン 3 X0Y16

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20

X0Y3

レーン 0 X0Y31 X0Y31 X0Y31


レーン 2 X0Y29

レーン 3 X0Y28

X0Y4

レーン 0 X0Y55 X0Y55 X0Y55 X0Y55

レーン 1 X0Y54 X0Y54 X0Y54



レーン 4 X0Y51

レーン 5 X0Y50

レーン 6 X0Y49

レーン 7 X0Y48

X0Y5

レーン 0 X0Y59 X0Y59 X0Y59


レーン 2 X0Y57

レーン 3 X0Y56






表 B‐34: Virtex UltraScale デバイスの GT ロケーション – FLGA2892


FLGA2892 XCVU440

X0Y0





レーン 4 X0Y3

レーン 5 X0Y2

レーン 6 X0Y1

レーン 7 X0Y0

X0Y1

レーン 0 X0Y15 X0Y15 X0Y15 X0Y15

レーン 1 X0Y14 X0Y14 X0Y14



レーン 4 X0Y11

レーン 5 X0Y10

レーン 6 X0Y9

レーン 7 X0Y8

X0Y2

レーン 0 X0Y27 X0Y27 X0Y27 X0Y27

レーン 1 X0Y26 X0Y26 X0Y26



レーン 4 X0Y23

レーン 5 X0Y22

レーン 6 X0Y21

レーン 7 X0Y20






FLGA2892(続き )

XCVU440(続き )

X0Y3

レーン 0 X0Y35 X0Y35 X0Y35 X0Y35

レーン 1 X0Y34 X0Y34 X0Y34



レーン 4 X0Y31

レーン 5 X0Y30

レーン 6 X0Y29

レーン 7 X0Y28

X0Y4

レーン 0 X0Y47 X0Y47 X0Y47 X0Y47

レーン 1 X0Y46 X0Y46 X0Y46



レーン 4 X0Y43

レーン 5 X0Y42

レーン 6 X0Y41

レーン 7 X0Y40

X0Y5

レーン 0 X0Y55 X0Y55 X0Y55 X0Y55

レーン 1 X0Y54 X0Y54 X0Y54



レーン 4 X0Y51

レーン 5 X0Y50

レーン 6 X0Y49

レーン 7 X0Y48

表 B‐34: Virtex UltraScale デバイスの GT ロケーション – FLGA2892 (続き)






付録 C

受信されるコンプリーションに対する受信バッファー空間の管理

『PCI Express® Base Specification』 [参照 2] では、すべてのエンドポイントは受信したコンプリーションに対して無限のフロー制御クレジットをリンクパートナーに出力することが規定されています。これは、エンドポイントがコンプリーション応答を受け入れるスペースがある場合にのみ、ノンポステッドリクエストを送信する、ということです。ここでは、この要件を満たすために、ユーザーアプリケーションで UltraScale Devices Gen3 Integrated Block for PCIe コアの受信バッファー空間を管理する方法について説明します。

一般的な注意事項と概念

コンプリーション空間

表 C-1 では、コアによって予約されている受信バッファーのコンプリーション空間が定義されています。これらの値は、コアの Capability Max Payload Size (機能大のペイロードサイズ) の設定と選択されたパフォーマンスレベルによって異なります。値はクレジット数で、 10 進数で表記されます。

表 C‐1:受信バッファーのコンプリーション空間

Capability Max Payload Size

(バイト )

パフォーマンスレベル: Extreme

CPH CPD

128 64 15,872B

256 64 15,872B

512 64 15,872B

1024 64 15,872B





付録 C:受信されるコンプリーションに対する受信バッファー空間の管理

最大リクエストサイズ

メモリ読み出しは、 Max_Request_Size で指定された値を超える値は要求できません。これは、表 C-2 で定義されるように、コンフィギュレーションビット cfg_dcommand[14:12] で指定されます。ユーザーアプリケーションが Max_Request_Size 値を読み出さない場合は、デフォルト値の 128 バイトが使用されます。

読み出しコンプリーションの境界

1 回のメモリ読み出しには複数のコンプリーションで応答できます。これらをまとめると、要求されたデータがすべて返されます。パケットヘッダーオーバーヘッドに余裕を持たせるため、ユーザーアプリケーションは、返される可能性のあるコンプリーションの大数分、スペースを用意しておく必要があります。

このプロセスを簡単にするため、『PCI Express Base Specification』ではすべてのコンプリーションパケットの長さを量子化し、すべてのコンプリーションが自然なアライメントの読み出しコンプリーション境界 (RCB) で開始および終了するようにしています (元のリクエストの開始/終了アドレスを提供する場合を除く )。 RCB バイトの整数倍でのアドレス境界を超えるリクエストは、複数のコンプリーションを使用して完了できますが、返されるデータは分断されるべきではありません。それ以外は、次のアドレス境界に従う必要があります。

• 初のコンプリーションは、リクエストで指定されたアドレスで開始し、次のいずれかで終了する必要があります。

° リクエストで指定されたアドレスで、リクエストで指定された長さ (例: リクエスト全体)

° リクエストの開始と終了のアドレス境界 (RCB バイトの整数倍)。

• 後のコンプリーションは、リクエストで指定したアドレスで終了し、リクエストで指定した長さになる必要があります。

• すべてのコンプリーション ( 初と後を含まない) は、 RCB バイトの整数倍の長さになる必要があります。

RCB のプログラム値は、 cfg_rcb_status[1:0] に出力されます。この場合、 cfg_rcb_status[0] および cfg_rcb_status[1] は、Physical Function 0 および 1 にそれぞれ関連付けられています (Per Function Link Control レジスタ [3])。ユーザーアプリケーションが RCB 値を読み出さない場合は、デフォルト値の 64 バイトを使用する必要があります。

表 C‐2: Max_Request_Size の設定

cfg_dcommand[14:12]Max_Request_Size

バイト DW QW クレジット

000b 128 32 16 8

001b 256 64 32 16

010b 512 128 64 32

011b 1024 256 128 64

100b 2048 512 256 128

101b 4096 1024 512 256

110b–111b 予約

表 C‐3:読み出しコンプリーションの境界設定

cfg_rcb_status[0] またはcfg_rcb_status[1]

読み出しコンプリーションの境界

バイト DW QW クレジット

0 64 16 8 4

1 128 32 16 8






ノンポステッドリクエストに必要なコンプリーションクレジット数を計算する際は、コンプリーション応答が必要になる可能性のある、 RCB で分けられたブロック数を決定します。これは、必要なコンプリーションヘッダークレジットの数と同じです。

高性能アプリケーションの重要事項

1 つのリクエストに応答するコンプリーションの大数をユーザーアプリケーションが計算することによって、プログラムされた RCB 値を使用できますが、高性能メモリコントローラーには、大規模な読み出しリクエストの応答に際して、 RCB サイズのブロックを組み合わせてそのリンクの Max_Payload_Size 値またはそれに近いサイズのコンプリーションにできるオプション機能があります。ホスト CPU のメモリコントローラーでこの機能がサポートされている場合は、使用を推奨しています。 RCB 値の整数倍 (>1) でのコンプリーション応答をベースとするデータ送受信の場合、 PCI Express インターフェイスの使用効率とペイロードの効率が非常に高くなり、またエンドポイントレシーバーのコンプリーション空間の使用効率も高くなります。

コンプリーション空間の管理方法

ユーザーアプリケーションには、表 C-4 に示す、受信バッファーのコンプリーション空間を管理する 5 つの方法の中から 1 つを選択できます。ここでは、これらの方法を便宜上 LIMIT_FC、 PACKET_FC、 RCB_FC、および DATA_FC と呼ぶことにします。これらの方法にはそれぞれメリットとデメリットがあり、ユーザーアプリケーションを開発する際に考慮する必要があります。

表 C‐4:受信コンプリーション空間の管理方法

方法説明メリットデメリット

LIMIT_FC 未処理のノンポステッド (NP) リクエストの合計数を制限します。

ユーザーロジックでインプリメントするも単純な方法です。

多くのコンプリーション空間が未使用となります。

PACKET_FC 未処理の CplH および CplD クレジットの数を追跡し、各パケットごとにそれを振り分けたり、振り分けを取り消したりします。

比較的シンプルなユーザーロジックで、LIMIT_FC よりもより細やかに振り分けが行われるため、無駄な未使用空間が減少します。

LIMIT_FC と同様、ノンポステッド (NP) リクエストのクレジットはリクエストが完全に満たされるまで拘束されます。

RCB_FC 未処理の CplH および CplD クレジットの数を追跡し、各 RCB ごとにそれを振り分けたり、振り分けを取り消したりします。

クレジットの拘束時間は PACKET_FC よりも短くなります。

LIMIT_FC や PACKET_FC よりも複雑なユーザーロジックになります。

DATA_FC 未処理の CplH および CplD クレジットの数を追跡し、各 RCB ごとにそれを振り分けたり、振り分けを取り消したりします。

空間をも無駄なく使用できます。

LIMIT_FC、 PACKET_FC、RCB_FC よりも複雑なユーザーロジックになります。






LIMIT_FC

LIMIT_FC は、インプリメントがも簡単な方法です。 1 度に処理可能なノンポステッド (NP) リクエストの大数である MAX_NP をユーザーアプリケーションが見積もります。この値を計算するには、次の手順に従います。

1. Max_Request_Size パケットで要求される CplH クレジット数を決定します。

Max_Header_Count = ceiling(Max_Request_Size / RCB)

2. CplD クレジットプールでサポートされる大サイズのコンプリーションの大数を決定します。

Max_Packet_Count_CplD = floor(CplD / Max_Request_Size)

3. CplH クレジットプールでサポートされる大サイズのコンプリーションの大数を決定します。

Max_Packet_Count_CplH = floor(CplH / Max_Header_Count)

4. 未処理のノンポステッドリクエストの大数を決定するため、手順 2 と 3 で得た 2 つの値のうち小さい方を使用します。

MAX_NP = min(Max_Packet_Count_CplH, Max_Packet_Count_CplD)

MAX_NP がわかっていれば、ユーザーアプリケーションは NP_PENDING レジスタにリセットで 0 を読み込んで、0 ～ MAX_NP の範囲に常に留まるようにできます。ノンポステッドリクエストが送信されると、 NP_PENDING が 1 ずつデクリメントします。未処理のノンポステッドリクエストに対するコンプリーションがすべて受信されると、NP_PENDING が 1 ずつインクリメントします。

例:

• Max_Request_Size = 128B

• RCB = 64B

• CplH = 64

• CplD = 15,872B

• Max_Header_Count = 2

• Max_Packet_Count_CplD = 124

• Max_Packet_Count_CplH = 32

• MAX_NP = 32

この方法はインプリメントがも簡単ですが、実際のリクエストサイズに関係なくコンプリーションクレジットの Max_Request_Size ブロック全体が各ノンポステッドリクエストに割り当てられるので、レシーバーのスペースの無駄がも多くなります。ユーザーアプリケーションが短いメモリ読み出し (1 つの DWORD 命令)、 I/O 読み出し、および I/O 書き込みリクエストを大量に発行すると、さらに無駄が多くなります。






PACKET_FC

PACKET_FC は、 LIMIT_FC よりもクレジットブロックをさらに細やかに割り当て、ユーザーロジックで受信コンプリーション空間を少し増やし、それをもっと効率よく使用できるようにする方法です。

CPLH_PENDING および CPLD_PENDING の 2 つのレジスタ ( リセットで 0 をロード ) を開始し、次の手順に従います。

1. ユーザーアプリケーションがノンポステッド (NP) リクエストを送信する必要がある場合は、必要だと思われる CplH および CplD クレジットの数を決定します。

NP_CplH = ceiling[((Start_Address mod RCB) + Request_Size) / RCB]

NP_CplD = ceiling[((Start_Address mod 16 bytes) + Request_Size) /16 bytes](0 データを返す I/O 書き込みを除く ) [(req_size + 15)/16]

モジュロ (mod) および ceiling ファンクションを使用すると、小数点の RCB またはクレジットブロックが丸められます。たとえば、メモリ読み出しがアドレス 7Ch から 8 バイトのデータを要求すると、戻されるデータは 2 つのコンプリーションパケットとして返される可能性があります (7Ch-7Fh に続いて 80h-83h)。これには、2 つの RCB ブロックと 2 つのデータクレジットが必要になります。

2. 次を確認してください。

CPLH_PENDING + NP_CplH Total_CplH

CPLD_PENDING + NP_CplD Total_CplD

3. どちらの不等号式も真である場合、ノンポステッド (NP) リクエストを送信し、 CPLH_PENDING を NP_CplH 分、 CPLD_PENDING を NP_CplD 分増やします。送信される NP リクエストそれぞれに対し、 NP_CplH および NP_CplD を後で使用するために残しておきます。

4. NP リクエストに対しすべてのコンプリーションデータが戻されたら、 CPLH_PENDING および CPLD_PENDING をそれぞれデクリメントします。

この方法の場合は LIMIT_FC よりも無駄が少なくなりますが、 NP リクエストのコンプリーション空間はリクエスト全体が満たされるまで使用できません。 RCB_FC および DATA_FC を使用すると、ロジックがさらに必要になりますが、さらに細かく振り分け可能です。

RCB_FC

RCB_FC では、 RCB ごとにクレジットのブロックを振り分けることができます。クレジットは RCB ごとに解放されます。

PACKET_FC と同様、 CPLH_PENDING および CPLD_PENDING の 2 つのレジスタ ( リセットで 0 をロード ) で開始します。

1. RCB ごとのデータクレジット数を計算します。

CplD_PER_RCB = RCB / 16 バイト

2. ユーザーアプリケーションが NP リクエストを送信する必要がある場合は、必要だと思われる CplH クレジットの数を決定します。これを使用して、 RCB ごとに CplD クレジットを割り当てます。


NP_CplD = NP_CplH × CplD_PER_RCB









4. どちらの不等号式も真である場合、ノンポステッド (NP) リクエストを送信し、 CPLH_PENDING を NP_CplH 分、 CPLD_PENDING を NP_CplD 分増やします。

5. 入ってくる各コンプリーションの始め、またはコンプリーションが RCB で開始あるいはその RCB で終わらずに RCB をまたぐとき、 CPLH_PENDING を 1 デクリメント、 CPLD_PENDING を CplD_PER_RCB 分デクリメントします。どのコンプリーションも複数の RCB をまたぐことができます。この RCB をまたぐ数は、次のように計算できます。

RCB_CROSSED = ceiling[((Lower_Address mod RCB) + Length) / RCB]

Lower_Address および Length は、コンプリーションヘッダーから解析可能なフィールドです。また、入ってくる各コンプリーションの始めで CUR_ADDR レジスタへ Lower_Address をロードし、必要に応じて DW または QW ごとにインクリメントし、 CUR_ADDR が繰り越すたびに RCB をカウントすることもできます。

この方法だと PACKET_FC よりも無駄が少なくなりますが、振り分ける単位はやはり RCB です。ユーザーアプリケーションが I/O リクエストを送信する場合は、ユーザーアプリケーションは、各 I/O 読み出しで 1 CplD クレジット、各 I/O 書き込みで 0 CplD クレジットのみを割り当てることが可能です。ユーザーアプリケーションは、入ってくる各コンプリーションのタグを元の NP リクエストのタイプ (メモリ書き込み、 I/O 読み出し、 I/O 書き込み) と一致させる必要があります。

DATA_FC

DATA_FC の方法では、使用するロジックは増えますが、も細かく割り当てができます。

PACKET_FC および RCB_FC と同様、 CPLH_PENDING および CPLD_PENDING の 2 つのレジスタ ( リセットで 0 をロード ) で開始します。

1. ユーザーアプリケーションがノンポステッド (NP) リクエストを送信する必要がある場合は、必要だと思われる CplH および CplD クレジットの数を決定します。


NP_CplD = ceiling[((Start_Address mod 16 bytes) + Request_Size) / 16 バイト ] (0 データを返す I/O 書き込みを除く )




3. どちらの不等号式も真である場合、ノンポステッド (NP) リクエストを送信し、 CPLH_PENDING を NP_CplH 分、 CPLD_PENDING を NP_CplD 分増やします。

4. 入ってくる各コンプリーションの始め、またはコンプリーションが RCB で開始またはその RCB で終わらずに RCB をまたぐとき、 CPLH_PENDING を 1 デクリメントします。この RCB をまたぐ数は、次のように計算できます。

RCB_CROSSED = ceiling[((Lower_Address mod RCB) + Length) / RCB]

Lower_Address および Length は、コンプリーションヘッダーから解析可能なフィールドです。また、入ってくる各コンプリーションの始めで CUR_ADDR レジスタへ Lower_Address をロードし、必要に応じて DW または QW ごとにインクリメントし、 CUR_ADDR が繰り越すたびに RCB をカウントすることもできます。






5. 入ってくる各コンプリーションの始め、または自然に揃えられたクレジット境界でコンプリーションが開始あるいはその境界をまたぐ場合、 CPLD_PENDING を 1 デクリメントします。クレジット境界を越える数は、次のように計算できます。

DATA_CROSSED = ceiling[((Lower_Address mod 16 B) + Length) / 16 B]

または、入ってくるコンプリーションの始めで CUR_ADDR レジスタに Lower_Address をロードし、必要に応じて DW または QW ごとにインクリメントし、CUR_ADDR が 16 バイトアドレスの境界を繰り越すたびに RCB をカウントすることもできます。

この方法ではも無駄が少なくなりますが、ユーザーロジックをも多く必要とします。さらに細かな割り当てが求められる場合は、コンプリーション QWORD または DWORD の数を得るのに Total_CplD 値を係数 2 または 4 で計算し、それに合わせてデータ計算を調節します。





付録 D

デバッグこの付録では、ザイリンクスサポートウェブサイトより入手可能なリソースおよびデバッグツールについて説明します。

ザイリンクスウェブサイト

UltraScale Devices Gen3 Integrated Block for PCIe を使用した設計およびデバッグでヘルプが必要な場合は、ザイリンクスサポートウェブページから製品の資料、リリースノート、アンサーなどを参照するか、テクニカルサポートでサービスリクエストを作成してください。

資料

この製品ガイドは UltraScale Devices Gen3 Integrated Block for PCIe に関する主要資料です。このガイド、並びに設計プロセスで使用する各製品の関連資料はすべて、ザイリンクスサポートウェブページ (https://japan.xilinx.com/support) または Xilinx Documentation Navigator から入手できます。

Xilinx Documentation Navigator は、ダウンロードページからダウンロードできます。このツールの詳細および機能は、インストール後にオンラインヘルプを参照してください。

アンサー

アンサーには、よく発生する問題についてその解決方法、およびザイリンクス製品に関する既知の問題などの情報が記載されています。アンサーは、ユーザーが該当製品の新情報にアクセスできるよう作成および管理されています。

このコアに関するアンサーの検索には、ザイリンクスサポートウェブページにある検索ボックスを使用します。より的確な検索結果を得るには、次のようなキーワードを使用してください。

• 製品名

• ツールで表示されるメッセージ

• 問題の概要

検索結果は、フィルター機能を使用してさらに絞り込むことができます。

UltraScale Devices Gen3 Integrated Block for PCIe に関するマスターアンサー

AR: 57945






https://japan.xilinx.com/support/download.html






付録 D:デバッグ

テクニカルサポート

ザイリンクスは、製品資料の説明に従って使用されている LogiCORE™ IP 製品に対するテクニカルサポートをザイリンクスサポートウェブページで提供しています。ただし、次のいずれかに該当する場合、タイミング、機能、サポートは保証されません。

• 資料で定義されていないデバイスにソリューションをインプリメントした場合。

• 資料で定義されている許容範囲を超えてカスタマイズした場合。

• 「DO NOT MODIFY」とされているデザインセクションに変更を加えた場合。

ザイリンクステクニカルサポートへのお問い合わせは、ザイリンクスサポートウェブページを参照してください。

ハードウェアデバッグ

トランシーバー制御およびステータスポート

表 D-1 に、トランシーバーに関連する問題のデバッグに使用するポートを示します。

重要: トランシーバー制御およびステータスインターフェイスのポート駆動方法は、使用する GT のユーザーガイドを参照してください。表 D-1 に示した入力信号をユーザーガイドに従わずに使用すると、 IP コアの動作が予測不能になることがあります。

表 D‐1: トランシーバーのデバッグに使用するポート


gt_pcieuserratedone I 1 トランシーバーチャネルプリミティブの CIEUSERRATEDONE へ接続されます。

gt_loopback I 3 トランシーバーチャネルプリミティブの LOOPBACK へ接続されます。

gt_txprbsforceerr I 1 トランシーバーチャネルプリミティブの TXPRBSFORCEERR へ接続されます。

gt_txinhibit I 1 トランシーバーチャネルプリミティブの TXINHIBIT へ接続されます。

gt_txprbssel I 4 PRBS 入力

gt_rxprbssel I 4 PRBS 入力

gt_rxprbscntreset I 1 トランシーバーチャネルプリミティブの RXPRBSCNTRESET へ接続されます。

gt_txelecidle O 1 トランシーバーチャネルプリミティブの TXELECIDLE へ接続されます。

gt_txresetdone O 1 トランシーバーチャネルプリミティブの TXRESETDONE へ接続されます。

gt_rxresetdone O 1 トランシーバーチャネルプリミティブの RXRECCLKOUT へ接続されます。

gt_rxpmaresetdone O 1 トランシーバーチャネルプリミティブの TXPMARESETDONE へ接続されます。

gt_txphaligndone O 1 トランシーバーチャネルプリミティブの TXPHALIGNDONE へ接続されます。

gt_txphinitdone O 1 トランシーバーチャネルプリミティブの TXPHINITDONE へ接続されます。

gt_txdlysresetdone O 1 トランシーバーチャネルプリミティブの TXDLYSRESETDONE へ接続されます。








付録 D:デバッグ

gt_rxphaligndone O 1 トランシーバーチャネルプリミティブの RXPHALIGNDONE へ接続されます。

gt_rxdlysresetdone O 1 トランシーバーチャネルプリミティブの RXDLYSRESETDONE へ接続されます。

gt_rxsyncdone O 1 トランシーバーチャネルプリミティブの RXSYNCDONE へ接続されます。

gt_eyescandataerror O 1 トランシーバーチャネルプリミティブの EYESCANDATAERROR へ接続されます。

gt_rxprbserr O 1 トランシーバーチャネルプリミティブの RXPRBSERR へ接続されます。

gt_dmonitorout O 16 トランシーバーチャネルプリミティブの DMONITOROUT へ接続されます。

gt_rxcommadet O 1 トランシーバーチャネルプリミティブの RXCOMMADETEN へ接続されます。

gt_phystatus O 1 トランシーバーチャネルプリミティブの PHYSTATUS へ接続されます。

gt_rxvalid O 1 トランシーバーチャネルプリミティブの RXVALID へ接続されます。

gt_rxcdrlock O 1 トランシーバーチャネルプリミティブの RXCDRLOCK へ接続されます。

gt_pcierateidle O 1 トランシーバーチャネルプリミティブの PCIERATEIDLE へ接続されます。

gt_pcieuserratestart O 1 トランシーバーチャネルプリミティブの PCIEUSERRATESTART へ接続されます。

gt_gtpowergood O 1 トランシーバーチャネルプリミティブの GTPOWERGOOD へ接続されます。

gt_cplllock O 1 トランシーバーチャネルプリミティブの CPLLLOCK へ接続されます。

gt_rxoutclk O 1 トランシーバーチャネルプリミティブの RXOUTCLK へ接続されます。

gt_rxrecclkout O 1 トランシーバーチャネルプリミティブの RXRECCLKOUT へ接続されます。

gt_qpll1lock O 1 トランシーバーコモンプリミティブの QPLL1LOCK へ接続されます。

gt_rxstatus O 3 トランシーバーチャネルプリミティブの RXSTATUS へ接続されます。

gt_rxbufstatus O 3 トランシーバーチャネルプリミティブの RXBUFSTATUS へ接続されます。

gt_bufgtdiv O 9 トランシーバーチャネルプリミティブの BUFGTDIV へ接続されます。

phy_txeq_ctrl O 2 PHY TX イコライゼーション制御ビット

phy_txeq_preset O 4 PHY TX イコライゼーションプリセットビット

phy_rst_fsm O 4 PHY RST FSM ステートビット

phy_txeq_fsm O 3 PHY RX イコライゼーション FSM ステートビット (Gen3)

phy_rxeq_fsm O 3 PHY TX イコライゼーション FSM ステートビット (Gen3)

phy_rst_idle O 1 PHY は IDLE ステートにいます。

phy_rrst_n O 1 sys_clk によって同期されるリセット生成

phy_prst_n O 1 pipe_clk によって同期されるリセット生成

表 D‐1: トランシーバーのデバッグに使用するポート (続き)






付録 E

Xilinx Virtual Cable (XVC) を使用したデバッグ

はじめに

Xilinx® Virtual Cable (ザイリンクス仮想ケーブル、 XVC) を使用すると、 Vivado® Design Suite から JTAG 以外のインターフェイスで FPGA デバッグコアに接続できます。 Vivado Design Suite の標準デバッグ機能は、 JTAG を使用して物理ハードウェア FPGA リソースに接続し、 Vivado を介してデバッグを実行します。このセクションでは、標準の JTAG デバッグインターフェイスではなく、 XVC を使用して PCIe リンク経由でデバッグを実行する方法について説明します。これは XVC-over-PCIe と呼ばれ、 PCIe リンクを通信チャネルとして使用して Vivado ILA による波形キャプチャ、 VIO によるデバッグ制御、およびほかのザイリンクスデバッグコアとの通信をサポートします。

XVC-over-PCIe は、 JTAG デバッグが利用できない場合に Vivado Design Suite のデバッグ機能を使用してリモートから FPGA をデバッグするのに使用します。通常は、 FPGA が PCIe ホストシステム以外のハードウェアデバイスに接続されていないデータセンターアプリケーションで使用します。

XVC を使用してデバッグを実行するには、ソフトウェア、ドライバー、および FPGA ハードウェアデザインコンポーネントが必要です。 XVC-over-PCIe では FPGA ハードウェアデザインがコンポーネントとして必要なため、XVC-over-PCIe をインプリメントした FPGA ハードウェアデザインが FPGA にロードされ、ホスト PC との間で PCIe リンクが確立されるまでデバッグを実行できません。これは通常、 XVC-over-PCIe 対応デザインをボード上のコンフィギュレーションフラッシュにロードしてから、カードをデータセンターのロケーションに挿入するという方法で行われます。 XVC-over-PCIe によるデバッグは PCIe 通信チャネルを使用して実行するため、 PCIe リンクに関連する不具合のデバッグには使用できません。

重要: XVC は、 FPGA 内のデバッグコアへの接続にのみ使用します。デバイスをプログラムする機能や、デバイスの JTAG およびコンフィギュレーションレジスタにアクセスする機能は XVC にはありません。これらの機能は、ほかの標準ザイリンクスインターフェイスまたは PCIe MCAP VSEC や HWICAP IP などのペリフェラルを使用して実行します。





付録 E: Xilinx Virtual Cable (XVC) を使用したデバッグ

概要

XVC-over-PCIe デバッグの実行には、主に次のコンポーネントが必要です。

• ホスト PC 上の XVC-Server アプリケーション

• ホスト PC 上の PCIe-XVC ドライバー

• XVC-over-PCIe に対応した FPGA デザイン

これらのコンポーネントは、ザイリンクス FPGA デザインに対する XVC 接続の確立方法を示すリファレンスとして提供されています。図 E-1 に示すように、これら 3 つのコンポーネントは TCP/IP ソケットを介して Vivado Design Suite のデバッグ機能に接続します。

ホスト PC 上の XVC‐Server アプリケーション

デバッグ機能を使用する場合、 Vivado Design Suite は hw_server アプリケーションを起動します。 Vivado IDE を介して hw_server をローカルまたはリモート FPGA ターゲットに接続できます。ローカルまたはリモート PCIe-XVC ターゲットに接続する場合も、これと同じインターフェイスを使用します。ホスト上の PCIe XVC-Server アプリケーションは TCP/IP ソケットを使用してザイリンクス hw_server に接続します。このため、 hw_server を使用する Vivado と XVC-Server アプリケーションは同じ PC 上で動作させることも、イーサネットで接続された別々の PC 上で動作させることもできます。 XVC-Server アプリケーションは、 FPGA ハードウェアリソースに直接接続した PC 上で動作させる必要があります。このシナリオでは、 FPGA ハードウェアは PCIe 経由でホスト PC に接続されます。XVC-Server アプリケーションは、同じホスト PC 上で動作する PCIe-XVC ドライバーを介して FPGA ハードウェアデバイスに接続します。

Host PC 上の XVC‐over‐PCIe ドライバー

XVC-over-PCIe ドライバーは、ホスト PC に接続された PCIe 対応 FPGA ハードウェアリソースへの接続に使用します。このため、このドライバーは PCIe ハードウェアデバイスにアクセスする Linux カーネルモードのドライバーとして提供されています。このドライバーの必要なコンポーネントを、特定の FPGA プラットフォーム用に作成したドライバーに追加する必要があります。このドライバーは、 XVC-Server アプリケーションが PCIe 経由で FPGA と通信するのに必要な基本機能を実装します。

X-Ref Target - Figure E-1

図 E‐1: XVC‐over‐PCIe のソフトウェアおよびハードウェアコンポーネント

Vivado Design Suite Debug

Feature

TCP/IPXVC-Server PCIe-XVC

DriverXVC-over-PCIeFPGA Design

PCIe

Running on local or remote Host

Running on Host PC connected to Xilinx FPGA card Running on Xilinx FPGA






XVC‐over‐PCIe に対応した FPGA デザイン

Vivado を使用した従来のデバッグは、 JTAG を使用します。デフォルトでは、 Vivado デバッグオートメーションはザイリンクスデバッグコアを FPGA 内の JTAG BSCAN リソースに接続してデバッグを実行します。 XVC-over-PCIe デバッグを実行するには、この情報を JTAG ケーブルインターフェイスではなく PCIe リンクで送信する必要があります。ザイリンクス Debug Bridge IP を使用すると、 PCIe 拡張コンフィギュレーションインターフェイス (PCIe-XVC-VSEC) または AXI4-Lite メモリマップドインターフェイス経由の PCIe BAR (AXI-XVC) を利用してデバッグネットワークを PCIe に接続できます。

Debug Bridge IP を [From PCIe to BSCAN] または [From AXI to BSCAN] に設定すると、PCIe 拡張機能または AXI4-Lite インターフェイスから Debug Bridge IP を経由してザイリンクスデバッグネットワークに接続できます。 Vivado ツールオートメーションは、この Debug Bridge のインスタンスを JTAG BSCAN インターフェイスではなくデザイン内のザイリンクスデバッグコアに接続します。Debug Bridge IP を PCIe 拡張コンフィギュレーション空間に接続する場合と AXI4-Lite に接続する場合では設計上のトレードオフがあります。次のセクションでは、これら 2 つの実装方法における注意事項とレジスタマップについて説明します。

PCIe 拡張コンフィギュレーション空間を使用した XVC‐over‐PCIe (PCIe‐XVC‐VSEC)

PCIe-XVC-VSEC では、Debug Bridge IP は PCIe Vendor Specific Extended Capability (VSEC) を使用して PCIe から Debug Bridge IP への接続を実装します。 PCIe 拡張コンフィギュレーション空間は、ホスト PC から検出可能な拡張機能の連結リストとしてセットアップされます。これは、デザインの 1 つのバージョンが PCIe-XVC-VSEC を実装し、もう 1 つのバージョンは実装していないようなプラットフォームで特に役立ちます。連結リストを使用すると、PCIe-XVC-VSEC が存在するかどうかを検出し、それに応じた応答が可能になります。

PCIe 拡張コンフィギュレーションインターフェイスは PCIe メモリ BAR トランザクションではなく PCIe コンフィギュレーショントランザクションを使用します。 PCIe コンフィギュレーショントランザクションの方が動作はかなり低速ですが、 PCIe IP 境界で PCIe メモリ BAR トランザクションに干渉しません。このため、 FPGA 内でデータ用とデバッグ用の通信パスを分離できます。これは、特にデータパスをデバッグする場合に適しています。データパスが破損または停止しても、 PCIe 拡張コンフィギュレーションインターフェイスはデバッグの実行を継続できます。図 E-2 に、 PCIe IP と Debug Bridge IP を接続して PCIe-XVC-VSEC を実装する方法を示します。

注記:図 E-2 には Ultrascale+ Integrated Block for PCIe IP を示していますが、代わりにほかの PCIe IP (UltraScale Integrated Block for PCIe、 AXI Bridge for PCIe、または PCIe DMA IP) を使用することもできます。


図 E‐2: PCIe 拡張機能インターフェイスを使用した XVC‐over‐PCIe






AXI を使用した XVC‐over‐PCIe (AXI‐XVC)

AXI-XVC では、 Debug Bridge IP は AXI Interconnect IP を介して PCIe IP に接続します。 Debug Bridge IP はほかの AXI4-Lite スレーブ IP と同じように AXI Interconnect に接続し、同じように特定のアドレス範囲の割り当てを要求します。伝統的に、この構成の debug_bridge IP はシステムデータパスネットワークではなく制御パスネットワークに接続されます。図 E-3 に、この実装方法における DMA Subsystem for PCIe IP と Debug Bridge IP の接続を示します。

注記:図 E-3 には PCIe DMA IP を示していますが、代わりに AXI に対応した任意の PCIe IP を使用できます。

AXI-XVC の実装では、より高速なトランザクションが可能です。ただし、 XVC デバッグトラフィックがその他の PCIe 制御パストラフィックと同じ PCIe ポートおよびインターコネクトを通過するため、このパスのトランザクションをデバッグするのは困難です。このため、 AXI-XVC デバッグは AXI-XVC デバッグ通信パスと重なるデータパスのデバッグに使用するのではなく、特定のペリフェラルまたは別の AXI ネットワークのデバッグに使用することを推奨します。

XVC‐over‐PCIe のレジスタマップ

PCIe-XVC-VSEC と AXI-XVC のレジスタマップは一部異なります。 XVC ドライバーおよびソフトウェアを設計する際は、この点を考慮する必要があります。表 E-1 と表 E-2 のレジスタマップは、ベースアドレスからのバイトオフセットを示しています。

• PCIe-XVC-VSEC のベースアドレスは、 PCIe 拡張コンフィギュレーション空間の有効な範囲内にある必要があります。これは Debug Bridge IP のコンフィギュレーションオプションで指定します。

• AXI-XVC Debug Bridge のベースアドレスは、 Vivado アドレスエディターで指定した Debug Bridge IP ペリフェラルのオフセットです。

表 E-1 と表 E-2 に、 Debug Bridge IP のレジスタマップを示します。レジスタオフセット欄には、 [From PCIe-Ext to BSCAN] または [From AXI to BSCAN] モードに設定した場合のベースアドレスからのオフセットを示しています。


図 E‐3: AXI4‐Lite インターフェイスを使用した XVC‐over‐PCIe

表 E‐1: XVC‐PCIe‐VSEC の場合の Debug Bridge のレジスタマップ

レジスタオフセットレジスタ名説明レジスタタイプ

0x00 PCIe 拡張機能ヘッダーVSEC で使用するために PCIe で定義されたフィールド

読み出し専用

0x04 PCIe VSEC ヘッダーVSEC で使用するために PCIe で定義されたフィールド

読み出し専用

0x08 XVC バージョンレジスタ IP バージョンおよび機能の情報読み出し専用

0x0C XVC シフト長レジスタシフト長読み出し /書き込み






PCIe 拡張機能ヘッダー (PCIe‐XVC‐VSEC のみ)

PCIe デザインに追加された PCIe-XVC-VSEC を識別するために使用します。 PCIe 拡張機能ヘッダーのフィールドと値は PCI-SIG によって定義されており、拡張機能のフォーマット識別、および次の拡張機能がある場合はその機能へのポインターとして使用します。 PCIe-XVC-VSEC として使用する場合、解釈する前に適切な PCIe ID フィールドを評価する必要があります。これには、 PCIe Vendor ID、 PCIe Device ID、 PCIe Revision ID、 Subsystem Vendor ID、および Subsystem ID フィールドがあります。たとえば、提供されるドライバーは PCIe Vendor ID が「Xilinx」 (0x10EE) と一致することを確認してからこのレジスタを解釈します。表 E-3 に、このレジスタの各フィールドの説明を示します。

0x10 XVC TMS レジスタ TMS データ読み出し /書き込み

0x14 XVC TDIO レジスタ TDO/TDI データ読み出し /書き込み

0x18 XVC 制御レジスタ一般制御レジスタ読み出し /書き込み

0x1C XVC ステータスレジスタ一般ステータスレジスタ読み出し専用

表 E‐1: XVC‐PCIe‐VSEC の場合の Debug Bridge のレジスタマップ (続き)


表 E‐2: AXI‐XVC の場合の Debug Bridge のレジスタマップ


0x00 XVC シフト長レジスタシフト長読み出し /書き込み

0x04 XVC TMS レジスタ TMS データ読み出し /書き込み

0x08 XVC TDI レジスタ TDI データ読み出し /書き込み

0x0C XVC TDO レジスタ TDO データ読み出し専用

0x10 XVC 制御レジスタ一般制御レジスタ読み出し /書き込み

0x14 XVC ステータスレジスタ一般ステータスレジスタ読み出し専用

0x18 XVC バージョンレジスタ IP バージョンおよび機能の情報読み出し専用

表 E‐3: PCIe 拡張機能ヘッダーレジスタの説明

ビット位置

説明初期値タイプ

15:0 PCIe Extended Capability ID: このフィールドは PCI-SIG によって定義された ID 番号で、拡張機能の性質とフォーマットを示します。 VSEC の ID は 0x000B です。

0x000B 読み出し専用

19:16 Capability Version: このフィールドは PCI-SIG によって定義されたバージョン番号で、機能構造体のバージョンを示します。この仕様バージョンでは 0x1 とする必要があります。

0x1 読み出し専用

31:20

Next Capability Offset: このフィールドはユーザーから渡され、次の PCI Express 機能構造体へのオフセット (機能連結リストにほかの項目がない場合は 0x000) を格納します。PCIe 拡張コンフィギュレーション空間に実装した拡張機能の場合、この値は常に PCIe 拡張コンフィギュレーション空間の有効な範囲内にある必要があります。







PCIe VSEC ヘッダー (PCIe‐XVC‐VSEC のみ)

このレジスタは、 Debug Bridge IP がこのモードの場合に PCIe-XVC-VSEC を識別するのに使用します。このフィールドは PCI-SIG によって定義されていますが、値は Vendor ID ( 「Xilinx」の場合 0x10EE) に固有です。このレジスタを解釈する前に、 PCIe 拡張機能ヘッダーレジスタの値を評価する必要があります。

XVC バージョンレジスタ (PCIe‐XVC‐VSEC のみ)

このレジスタの値はザイリンクスツールによって書き込まれます。これらの値を使用して、 Vivado Design Suite はハードウェアデザインにインプリメントされた Debug Bridge IP の機能を特定します。

XVC シフト長レジスタ

デバッグスキャンチェーン内のスキャンチェーンシフト長を設定するのに使用します。

XVC TMS レジスタ

デバッグスキャンチェーン内の TMS データを設定するのに使用します。

XVC TDO/TDI データレジスタ

TDO/TDI データアクセスに使用します。 PCIe-XVC-VSEC を使用する場合、これら 2 つのレジスタは 1 つのフィールドに結合されます。 AXI-XVC を使用する場合、これらは 2 つの別々のレジスタとして実装されます。

XVC 制御レジスタ

XVC 制御データに使用します。

XVC ステータスレジスタ

XVC ステータス情報に使用します。

表 E‐4: PCIe XVC VSEC ヘッダーレジスタの説明

ビット位置説明初期値タイプ

15:0 VSEC ID: PCIe-XVC-VSEC を識別するための ID 値で、 Vendor ID ( 「Xilinx」の場合 0x10EE) に固有です。


19:16 VSEC Rev: PCIe-XVC-VSEC バージョンを識別するためのリビジョン ID 値です。 0x0 読み出し専用

31:20 VSEC Length: PCIe 拡張機能ヘッダーおよび PCIe VSEC ヘッダーレジスタを含む PCIe-XVC-VSEC 構造体全体のバイト数を示します。







XVC ドライバーおよびソフトウェア

Vivado Design Suite をインストールすると、 XVC ドライバーおよびソフトウェアのサンプルが <Vivado_Installation_Path/data/xicom/driver/pcie/xvc_pcie.zip として生成されます。これは、XVC の機能をザイリンクス FPGA プラットフォームデザインのドライバーおよびソフトウェアに統合する際のリファレンスとして使用してください。サンプルとして提供される Linux カーネルモードドライバーおよびソフトウェアは、 PCIe-XVC-VSEC と AXI-XVC の両方の Debug Bridge 実装方法による XVC-over-PCIe デバッグを実装しています。

PCIe-XVC-VSEC モードで動作する場合、ドライバーは FPGA デバッグネットワークと接続するための PCIe コンフィギュレーショントランザクションを開始します。 AXI-XVC モードで動作する場合、ドライバーは FPGA デバッグネットワークと接続するための 32 ビット PCIe メモリ BAR トランザクションを開始します。デフォルトでは、ドライバーは PCIe-XVC-VSEC の検出を試み、 PCIe コンフィギュレーション拡張機能連結リストに PCIe-XVC-VSEC が見つからない場合は AXI-XVC を使用します。

ドライバーは、 Vivado をインストールしたディレクトリにあるデータディレクトリに .zip ファイルとして提供されます。この .zip ファイルをザイリンクス FPGA に PCIe 経由で接続されたホスト PC にコピーし、解凍して使用します。 XVC ドライバーおよびソフトウェアのインストールおよび実行方法は、付属の README.txt ファイルを参照してください。

Tandem またはパーシャルリコンフィギュレーションデザインの場合の注意事項

Tandem およびパーシャルリコンフィギュレーション (PR) デザインでは、物理リソースが複数の領域に分割されるため、いくつかの注意事項があります。 VIO、 ILA、 MDM、および MIG-IP などのデバッグ IP をデザインに追加する際は、これらの物理パーティションを考慮する必要があります。 [From PCIe-ext to BSCAN] または [From AXI to BSCAN] に設定した Debug Bridge IP は、デザインのスタティックパーティションにのみ配置してください。デバッグ IP を PR または Tandem フィールドアップデート領域内で使用する場合は、デバッグ BSCAN インターフェイスをもう 1 つ PR 領域モジュール定義に追加し、 PR 領域モジュールインスタンシエーションで未接続のままにする必要があります。

BSCAN インターフェイスを PR モジュール定義に追加するには、適切なポートおよびポート属性を PR モジュール定義に追加します。次に、 BSCAN インターフェイスをポート宣言に追加する際にテンプレートとして使用できる Verilog サンプルを示します。

...// BSCAN interface definition and attributes.// This interface should be added to the PR module definition// and left unconnected in the PR module instantiation.(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN drck" *)(* DEBUG="true" *)input S_BSCAN_drck,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN shift" *)(* DEBUG="true" *)input S_BSCAN_shift,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tdi" *)(* DEBUG="true" *)input S_BSCAN_tdi,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN update" *)(* DEBUG="true" *)input S_BSCAN_update,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN sel" *)(* DEBUG="true" *)input S_BSCAN_sel,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tdo" *)(* DEBUG="true" *)output S_BSCAN_tdo,






(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tms" *)(* DEBUG="true" *)input S_BSCAN_tms,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN tck" *)(* DEBUG="true" *)input S_BSCAN_tck,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN runtest" *)(* DEBUG="true" *)input S_BSCAN_runtest,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN reset" *)(* DEBUG="true" *)input S_BSCAN_reset,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN capture" *)(* DEBUG="true" *)input S_BSCAN_capture,(* X_INTERFACE_INFO = "xilinx.com:interface:bscan:1.0 S_BSCAN bscanid_en" *)(* DEBUG="true" *)input S_BSCAN_bscanid_en,....

link_design を実行すると、外部に引き出されたポートがツールオートメーションによってデバッグネットワークのスタティック領域に接続されます。デザインで必要な場合は ILA もデバッグネットワークに接続されます。デザインの上位に dbg_hub セルがもう 1 つ追加されることもあります。フィールドアップデートを伴う Tandem デザインの場合、 dbg_hub およびツールによって挿入されるクロックバッファーは適切なデザインパーティションに追加する必要があります。次に、 opt_design の後に実行して dbg_hub プリミティブを適切なデザインパーティションに関連付ける Tcl コマンドの例を示します。

# Add the inserted dbg_hub cell to the appropriate design partition.set_property HD.TANDEM_IP_PBLOCK Stage1_Main [get_cells dbg_hub]# Add the clock buffer to the appropriate design partition.set_property HD.TANDEM_IP_PBLOCK Stage1_Config_IO [get_cells dma_pcie_0_support_i/pcie_ext_cap_i/vsec_xvc_inst/vsec_xvc_dbg_bridge_inst/inst/bsip/inst/USE_SOFTBSCAN.U_TAP_TCKBUFG]

PCIe‐XVC‐VSEC サンプルデザインの使用

PCIe-XVC-VSEC は、 Ultrascale+ PCIe Integrated Block IP の [Advanced] 設定の一部として PCIe サンプルデザインに統合されています。このセクションでは、 PCIe-XVC-VSEC を使用した PCIe サンプルデザインを生成し、提供される XVC ドライバーおよびソフトウェアを使用して PCIe 経由で FPGA をデバッグする方法について説明します。このサンプルデザインは、 XVC をカスタマーアプリケーションで使用する場合のものです。 FPGA デザイン、ドライバー、およびソフトウェアの各要素をカスタマーデザインに統合する必要があります。

PCIe‐XVC‐VSEC サンプルデザインの生成

PCIe-XVC-VSEC を Ultrascale+™ PCIe サンプルデザインに追加するには、次のオプションを選択します。

1. 目的に応じてコアのコンフィギュレーションオプションを設定します。

2. [Basic] タブで [Advanced] をクリックして Advanced モードを選択します。

3. [Adv. Options-3] タブをクリックして、次のように設定します。

a. [PCI Express Extended Configuration Space Enable] をオンにして、 PCI Express 拡張コンフィギュレーションインターフェイスを有効にします。 PCI Express コアに対する拡張機能はここに追加されます。

b. [Add the PCIe-XVC-VSEC to the Example Design] をオンにして、サンプルデザイン生成時に PCIe-XVC-VSEC を有効にします。






4. PCIe IP のその他のコンフィギュレーションオプション設定を確認します。実際のハードウェアインプリメンテーションに合わせてドライバーを設定するには、次の設定が必要です。

° PCIe Vendor ID ( 「Xilinx」の場合 0x10EE)

° PCIe Device ID (ユーザーの選択により異なる )

5. [OK] をクリックして設定を終了し、 IP を生成します。

6. アプリケーションでの必要に応じて IP の出力ファイルを生成します。

7. [Sources] ウィンドウで IP を右クリックし、 [Open IP Example Design] をクリックします。

8. サンプルデザインを生成するディレクトリを選択し、 [OK] をクリックします。

生成されたサンプルデザインを見ると、次のことがわかります。

° PCIe IP がサポートラッパー内の xvc_vsec に接続されています。

° デザインのユーザーアプリケーション領域に ILA IP が追加されています。

FPGA デザインのハードウェア部分に必要な接続は、次に示すとおりです。必要に応じて、その他のデバッグコアもユーザーアプリケーションに追加できます。

注記:図 E-4 には UltraScale+ Integrated Block for PCIe IP を示していますが、サンプルデザインの階層はその他の PCIe IP も同じです。

9. xvc_vsec と表示された Debug Bridge IP をダブルクリックして、この IP のコンフィギュレーションオプションを表示します。次のコンフィギュレーションパラメーターを確認してください。これらはドライバーの設定に使用します。

° PCIe XVC VSEC ID (デフォルトは 0x0008)

° PCIe XVC VSEC Rev ID (デフォルトは 0x0)

重要: Vendor ID 「Xilinx」またはサンプルとして提供される XVC ドライバーおよびソフトウェアを使用する場合は、これらのパラメーター値は変更しないでください。これらの値は、 XVC 拡張機能の検出に使用します。詳細は PCIe 仕様を参照してください。

10. Flow Navigator で [Generate Bitstream] をクリックし、サンプルデザインプロジェクトのビットストリームを生成します。このビットストリームを FPGA ボードにロードすると、PCIe 経由での XVC デバッグが可能になります。


図 E‐4:サンプルデザインの階層






XVC-over-PCIe ハードウェアデザインが完成したら、適切な XVC 対応 PCIe ドライバーおよび関連する XVC-Server ソフトウェアアプリケーションを使用して、 Vivado Design Suite を PCIe で接続された FPGA に接続できます。Vivado は同じローカルマシンで動作している XVC-Server アプリケーションに接続することも、別のリモートマシンで動作する XVC-Server アプリケーションに TCP/IP ソケットを使用して接続することもできます。

システムのブリングアップ

まず、ホストシステムが PCIe リンクを検出できるように FPGA をプログラムしてシステムに電源を投入します。これは、次のいずれかの方法で実行できます。

• デザインファイルを FPGA ボード上のフラッシュにプログラムする。

• JTAG 経由でデバイスを直接プログラムする。

カードの電源がホスト PC から供給されている場合、 JTAG によるプログラムを実行するには電源を投入する必要があります。その後、再起動すると PCIe リンクがエニュメレートできます。システムが起動したら、 Linux の lspci ユーティリティを使用して FPGA ベースの PCIe デバイスの詳細をリスト表示できます。

ドライバーのコンパイルとロード

提供される PCIe ドライバーおよびソフトウェアは、実際に使用するプラットフォームに合わせてカスタマイズする必要があります。通常は、 PCIe-XVC-VSEC や AXI-XVC などのデバイス拡張機能やペリフェラルへのアクセスを試みる前に、ドライバーとソフトウェアが Vendor ID、 Device ID、 Revision ID、 Subsystem Vendor ID、および Subsystem ID をチェックするようにカスタマイズします。提供されるドライバーは汎用に設計されているため、PCIe-XVC-VSEC または AXI-XVC ペリフェラルの識別を開始する前に Vendor ID と Device ID の互換性しかチェックしません。

XVC ドライバーおよびソフトウェアは、 Vivado Design Suite をインストールすると ZIP ファイルとして付属します。

1. この ZIP ファイルを Vivado のインストールディレクトリから FPGA の接続されたホスト PC にコピーして解凍 (unzip) します。このファイルは、 Vivado インストールディレクトリの次の場所にあります。

XVC Driver and SW Path: …/data/xicom/driver/pcie/xvc_pcie.zip

XVC ドライバーおよびソフトウェアのコンパイル、インストール、および実行の方法は、 driver_* および xvcserver ディレクトリにある README.txt ファイルに記載されています。ここでは、その内容を手順としてまとめます。ドライバーおよびソフトウェアのファイルをホスト PC にコピーし、 root 権限を持つユーザーとしてログインした後、次の手順を実行してください。

2. driver_*/xvc_pcie_user_config.h ファイル内の変数を実際のハードウェアデザインおよび IP 設定に合わせて編集します。編集が必要なのは主に次の変数です。

° PCIE_VENDOR_ID: PCIe IP のカスタマイズ時に定義した PCIe Vendor ID です。

° PCIE_DEVICE_ID: PCIe IP のカスタマイズ時に定義した PCIe Device ID です。

° Config_space: PCIe-XVC-VSEC と AXI-XVC ペリフェラルのどちらを使用するかを選択します。デフォルト値の AUTO では、まず PCIe-XVC-VSEC の検出を試みた後、 PCIe-XVC-VSEC が見つからない場合は AXI-XVC ペリフェラルへの接続を試みます。 PCIe-XVC-VSEC と AXI-XVC の実装を明示的に選択する場合は、 CONFIG または BAR を使用します。

° config_vsec_id: [Bridge Type] で [From PCIE to BSCAN] を選択した場合に Debug Bridge IP で定義される PCIe XVC VSEC ID (デフォルト値は 0x0008) です。この値は、 PCIe-XVC-VSEC の検出にのみ使用します。

° config_vsec_rev: [Bridge Type] で [From PCIe to BSCAN] を選択した場合に Debug Bridge IP で定義される PCIe XVC VSEC Rev ID (デフォルト値は 0x0) です。この値は、 PCIe-XVC-VSEC の検出にのみ使用します。

° bar_index: [Bridge Type] で [From AXI to BSCAN] を選択した場合に Debug Bridge IP にアクセスするために使用する PCIe BAR インデックスです。この BAR インデックスは、 PCIe IP のカスタマイズとシステムデザイン内でアドレス指定可能な AXI ペリフェラルの組み合わせとして指定します。この値は、 PAXI-XVC ペリフェラルの検出にのみ使用します。






° bar_offset: [Bridge Type] で [From AXI to BSCAN] を選択した場合に Debug Bridge IP にアクセスするために使用する PCIe BAR オフセットです。この BAR オフセットは、 PCIe IP のカスタマイズとシステムデザイン内でアドレス指定可能な AXI ペリフェラルの組み合わせとして指定します。この値は、 PAXI-XVC ペリフェラルの検出にのみ使用します。

3. ソースファイルを任意のディレクトリに移動します。例:

/home/username/xil_xvc or /usr/local/src/xil_xvc

4. root 権限があることを確認して、ドライバーファイルのあるディレクトリに移動します。

# cd /driver_*/

5. ドライバーモジュールをコンパイルします。

# make install

カーネルモジュールのオブジェクトファイルが次のようにインストールされます。

/lib/modules/[KERNEL_VERSION]/kernel/drivers/pci/pcie/Xilinx/xil_xvc_driver.ko

6. depmod を実行して、新規にインストールしたカーネルモジュールを見つけます。

# depmod -a

7. 古いバージョンのドライバーがロードされていないことを確認します。

# modprobe -r xil_xvc_driver

8. モジュールをロードします。

# modprobe xil_xvc_driver

dmesg コマンドを実行すると、少なくとも次のメッセージが表示されます。

kernel: xil_xvc_driver: Starting…

注記: カーネルオブジェクトファイルに対して insmod を実行してモジュールをロードすることもできます。

# insmod xil_xvc_driver.ko

ただし、この方法は古いカーネルとの互換性のために必要な場合を除き、推奨しません。

9. 生成されるキャラクターファイル /dev/xil_xvc/cfg_ioc0 の所有者/所有グループは root ユーザーと root グループで、パーミッション 660 とする必要があります。アプリケーションとドライバーが通信するために、このファイルのパーミッションを正しく設定する必要があります。

# chmod 660 /dev/xil_xvc/cfg_ioc0

10. ドライバー用のシンプルなテストプログラムをビルドします。

# make test

11. テストプログラムを実行します。

# ./driver_test/verify_xil_xvc_driver

長さの異なるいくつかのテストが正常に完了すると、後に次のメッセージが表示されます。

"XVC PCIE Driver Verified Successfully!"






XVC‐Server アプリケーションのコンパイルと起動

XVC-Server アプリケーションは、 Vivado の hw_server と XVC 対応 PCIe デバイスドライバーを接続します。 Vivado Design Suite は TCP/IP を使用して XVC-Server に接続します。使用するポート番号には、ネットワークのファイアウォール外部から正しくアクセスできるようにしておく必要があります。 XVC ソフトウェアアプリケーションをコンパイルして起動するには、次の手順を実行します。ポート番号はデフォルトの 10200 を使用します。

1. Vivado Design Suite への接続に使用するポートに外部からアクセスできるように、システムでファイアウォールを設定します。ポート 10200 を使用します。

2. ホスト名または IP アドレスを確認します。Vivado を xvcserver アプリケーションに接続するにはホスト名とポート番号が必要です。各 OS のファイアウォールポート設定の詳細は、 OS のヘルプページを参照してください。

3. ソースファイルを任意のディレクトリに移動します。例:

/home/username/xil_xvc or /usr/local/src/xil_xvc

4. アプリケーションソースファイルがあるディレクトリに移動します。

# cd ./xvcserver/

5. アプリケーションをコンパイルします。

# make

6. XVC-Server アプリケーションを起動します。

# ./bin/xvc_pcie -s TCP::10200

Vivado Design Suite が XVC-Server アプリケーションに接続すると、 XVC-Server から次のメッセージが表示されます。

Enable verbose by setting VERBOSE evn var.Opening /dev/xil_xvc/cfg_ioc0

Vivado Design Suite から XVC‐Server アプリケーションへの接続

Vivado Design Suite は、 XVC-Server アプリケーションが動作するコンピューター上で実行することも、イーサネットネットワーク経由で接続された別のリモートコンピューター上で実行することもできます。ただし Vivado が動作しているマシンからポートにアクセスできる必要があります。 Vivado を XVC-Server アプリケーションに接続するには、次の手順を実行します。ここでは、デフォルトのポート番号を使用しています。

1. Vivado Design Suite を起動します。

2. [Open HW Manager] をクリックします。

3. ハードウェアマネージャーで、 [Open Target] → [Open New Target] をクリックします。

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

5. [Local server] を選択し、 [Next] をクリックします。

これで、 xvcserver アプリケーションに接続するための hw_server がローカルマシン上で起動します。

6. [Add Xilinx Virtual Cable (XVC)] をクリックします。

7. [Add Virtual Cable] ダイアログボックスで、 xvcserver アプリケーションへの接続に必要な情報 (ホスト名または IP アドレス、およびポート番号) を正しく入力します。 [OK] をクリックします。






8. 新規に追加した XVC ターゲットを [Hardware Targets] の一覧から選択し、 [Next] をクリックします。


図 E‐5: [Add Virtual Cable] ダイアログボックス






9. [Finish] をクリックします。

10. [Hardware Device Properties] ウィンドウでデバッグブリッジターゲットを選択し、適切なプローブファイル (.ltx) を割り当てます。


図 E‐6: XVC ターゲット


図 E‐7: [Hardware Device Properties] ウィンドウ






これでデバッグコアおよびデバッグ信号が Vivado から認識され、 Vivado ハードウェアツールインターフェイス経由で標準のデバッグアプローチを使用してデザインをデバッグできます。

これにより、 JTAG ではなく PCIe リンク経由で Xilinx Virtual Cable テクノロジを使用してザイリンクス FPGA デザインをデバッグできます。接続を終了するには、 Vivado の右クリックメニューを使用してハードウェアサーバーを終了します。 PCIe 接続が失われた場合、または XVC-Server アプリケーションの動作が停止した場合は、 FPGA および関連するデバッグコアへの接続も失われます。

実行時の注意事項

デバイスのプログラム中は Vivado から XVC-Server アプリケーションには接続しないでください。デバイスのプログラムが完了し、ハードウェア PCIe インターフェイスが動作を開始してから XVC-Server アプリケーションを起動し、Vivado との接続を開始してください。

PR デザインの場合、 RP 動作中は接続を終了することが重要です。 PR 動作中はデバッグコアが PR 領域内にあるため、デバッグツリーの一部が再プログラムされることが予想されます。 PR 動作中は、 Vivado デバッグツールが XVC を介して FGPA と通信しないようにしてください。





付録 F

その他のリソースおよび法的通知

ザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

Documentation Navigator およびデザインハブ

Xilinx Documentation Navigator (DocNav) を使用するとザイリンクスの資料、ビデオ、およびサポートリソースにアクセスして情報をフィルター、検索できます。 Xilinx Documentation Navigator を開くには、次のいずれかを実行します。

• Vivado IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux コマンドプロンプトに「docnav」と入力します。

ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられており、これらを参照することでキーコンセプトを学び、よくある質問を解決できます。デザインハブにアクセスするには、次のいずれかを実行します。

• Xilinx Documentation Navigator で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: Documentation Navigator の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。

注意: Xilinx Documentation Navigator からは、日本語版は参照できません。ウェブサイトのデザインハブページの一部は翻訳されており、日本語版が提供されている場合はそのリンクも追加されています。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav




付録 F: その他のリソースおよび法的通知

参考資料

次の資料は、この製品ガイドの補足資料として役立ちます。日本語版のバージョンは、英語版より古い場合があります。

注記:日本語版のバージョンは、英語版より古い場合があります。

1. 『AMBA AXI4-Stream Protocol Specification』

2. PCI-SIG 仕様 (www.pcisig.com/specifications)

3. 『UltraScale+ Device Integrated Block for PCI Express LogiCORE IP 製品ガイド』 (PG213: 英語版、日本語版)

4. 『AXI Bridge for PCI Express Gen3 Subsystem v2.1 製品ガイド』 (PG194)

5. 『DMA/Bridge Subsystem for PCI Express 製品ガイド』 (PG195)

6. 『Virtex-7 FPGA Gen3 Integrated Block for PCI Express LogiCORE IP 製品ガイド』 (PG023)

7. 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570: 英語版、日本語版)

8. 『Kintex UltraScale FPGA データシート : DC 特性および AC スイッチ特性』 (DS892: 英語版、日本語版)

9. 『Virtex UltraScale FPGA データシート : DC 特性および AC スイッチ特性』 (DS893: 英語版、日本語版)

10. 『UltraScale アーキテクチャ PCB デザインユーザーガイド』 (UG583: 英語版、日本語版)

11. 『UltraScale アーキテクチャ GTH トランシーバーユーザーガイド』 (UG576: 英語版、日本語版)

12. 『UltraScale アーキテクチャ GTY トランシーバーユーザーガイド』 (UG578: 英語版、日本語版)

13. 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896: 英語版、日本語版)

14. 『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994: 英語版、日本語版)

15. 『Vivado Design Suite ユーザーガイド : 入門』 (UG910: 英語版、日本語版)

16. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903: 英語版、日本語版)

17. 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900: 英語版、日本語版)

18. 『Vivado Design Suite ユーザーガイド : パーシャルリコンフィギュレーション』 (UG909: 英語版、日本語版

19. 『ISE から Vivado Design Suite への移行ガイド』 (UG911: 英語版、日本語版)

20. 『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908: 英語版、日本語版)

21. 『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947)

22. 『UltraScale Devices Debug Bridge LogiCORE IP 製品ガイド』 (PG245)

23. 『In-System IBERT LogiCORE IP 製品ガイド』 (PG246)

24. 『ATX Power Supply Design Guide』

25. 『Gen2 x8 コンフィギュレーションの Integrated PCI Express Endpoint Block を使用する PIPE モードシミュレーション』 (XAPP1184: 英語版、日本語版)


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0051a/index.html

http://www.pcisig.com/specifications

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/ipdoc?c=pcie4_uscale_plus;v=latest;d=j_pg213-pcie4-ultrascale-plus.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/ipdoc?c=xdma;v=latest;d=pg195-pcie-dma.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/ndoc?t=user_guides;d=ug570-ultrascale-configuration.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=data_sheets;d=ds892-kintex-ultrascale-data-sheet.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=j_ds892-kintex-ultrascale-data-sheet.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds893-virtex-ultrascale-data-sheet.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=j_ds893-virtex-ultrascale-data-sheet.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug583-ultrascale-pcb-design.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug583-ultrascale-pcb-design.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=j_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/ndoc?t=user_guides;d=j_ug578-ultrascale-gty-transceivers.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

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

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug994-vivado-ip-subsystems.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug994-vivado-ip-subsystems.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug903-vivado-using-constraints.pdf

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

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug909-vivado-partial-reconfiguration.pdf

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

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug911-vivado-migration.pdf

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

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf

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

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug947-vivado-partial-reconfiguration-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=debug_bridge;v=latest;d=pg245-debug-bridge.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=in_system_ibert;v=latest;d=pg246-in-system-ibert.pdf

http://www.formfactors.org/developer/specs/ATX12V_PSDG_2_2_public_br2.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1184-PIPE-mode-PCIe.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1184-PIPE-mode-PCIe.pdf





改訂履歴

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

日付バージョン内容

2017 年 10 月 4 日 4.4 第 1 章「概要」 :

• 表 2-1 「利用可能な PCI Express 用統合ブロック」を更新。

第 2 章「製品仕様」 :

• cfg_mgmt_addr の幅の説明を更新。

• cfg_current_speed、 cfg_max_payload、 cfg_max_read_req、 cfg_err_cor_out、cfg_err_nonfatal_out、 cfg_err_fatal_out、 cfg_local_error の説明を一部更新。

• cfg_interrupt_msi_function_number、 cfg_ext_read_data_valid の説明を大幅に更新。

第 3 章「コアを使用するデザイン」 :

• 「Tandem コンフィギュレーション」の項を更新。

• 「コンプリーターコンプリーションディスクリプターのフィールド」のビットインデックス 79:72、 87:80、および 88 の説明を大幅に更新。

• 「リクエスターリクエストディスクリプターのフィールド」のビットインデックス 87:80、 95:88、および 120 の説明を大幅に更新。

第 4 章「デザインフローの手順」 :

• Vivado IP カタログの次のオプションについて詳細を追加。

° 「PF0 ID の初期値」 → 「デバイス ID」の値 ([PF0 IDs] および [PF1 IDs] タブ)。

° [MSIx Table Settings] → [Table Size] ([MSI-X Capabilities] タブ)。

付録 A 「アップグレード」 :

• 新のコアバージョンに合わせてポートおよびパラメーターの変更を更新。

付録 D 「Xilinx Virtual Cable (XVC) を使用したデバッグ」を追加。

2017 年 6 月 7 日 4.3 • 「Tandem コンフィギュレーション」の項を一部更新。

• cfg_interrupt_msi_pending_status のポートの説明を更新。

• 「MSI モード」の図を更新。

2017 年 4 月 5 日 4.3 第 3 章「コアを使用するデザイン」 :

• 「共有ロジック」の項に「GT Wizard を使用する方法」を追加。


第 4 章「デザインフローの手順」 :

• 「PCIe DRP ポート」と「GT DRP ポート」の表を追加。

• [Enable In System IBERT] に Gen1 および Gen2 スピードリンクのサポートを追加。

2016 年 12 月 19 日 4.2 • 第 4 章「デザインフローの手順」で、 [Enable In System IBERT] をハードウェアデバッグのみに使用するように説明を明確化 (このオプションをオンにして生成したコアではシミュレーションがサポートされない)。

2016 年 11 月 30 日 4.2 Vivado IP カタログのコアオプションを変更。

• [Extended Capabilities 1] および [Extended Capabilities 2] タブの [Enable AER Capability] オプションに [ECRC check capable] サブオプションを追加。

• [GT Settings] タブの [Enable Auto RxEq] 設定が LPM または DFE に与える影響を明確化。

2016 年 10 月 19 日 4.2 • 第 2 章「製品仕様」の編集を更新。






2016 年 10 月 5 日 4.2 • 性能およびリソース使用量に関するデータをウェブに移動。


• 第 4 章「デザインフローの手順」で「デバイスコンフィギュレーション別の BAR サイズ範囲」の表を更新。

• 第 4 章「デザインフローの手順」で Advanced モードの [Basic] タブに [Enable Parity] オプション、 [GT Settings] タブに [Enable Auto RxEq] オプション、および新しい [Add. Debug Options] タブに [Enable In System IBERT]、 [Enable Descrambler for Gen3 Mode]、 [Enable JTAG Debugger] パラメーターを追加。

• 付録「移行およびアップグレード」で「パラメーターの変更点」および「ポートの変更点」の表を更新。

2016 年 6 月 8 日 4.2 • 「Tandem コンフィギュレーション」の項を更新。

• 「割り込みリクエストの生成」を更新。

• 新しいデバイスの GT ロケーションを追加。

2016 年 4 月 6 日 4.2 • 「Tandem コンフィギュレーション」の項:

° 「Tandem PROM/PCIe がサポートするコンフィギュレーション」の表を更新。

° 「フィールドアップデートを伴う Tandem」の項を追加。

° 「フィールドアップデートを伴う Tandem デザインのデバッグ」の項を追加。

• 付録「移行およびアップグレード」で「パラメーターの変更点」および「ポートの変更点」の表を追加。

• 「Kintex UltraScale デバイスの GT ロケーション」の表を更新。

2016 年 1 月 29 日 4.1 • 表 2-2 「利用可能な PCI Express 用統合ブロック」を更新。

2015 年 11 月 20 日 4.1 • 表 2-3 「デバイスの低要件」の Gen3 の詳細を更新。

2015 年 11 月 18 日 4.1 • 第 2 章の表「利用可能な PCI Express 用統合ブロック」および付録 B の表「Kintex® UltraScale™ デバイスの GT ロケーション」の XCKU095 デバイスに FFVA1156 パッケージを追加。

• 「サポートされるスピードグレード」を更新。

• 次のポートの幅を更新: cfg_function_status、 cfg_vf_status、cfg_function_power_state、 cfg_vf_power_state、 cfg_rcb_status、cfg_dpa_substate_change、 cfg_tph_requester_enable、 cfg_tph_st_mode、cfg_vf_tph_requester_enable、 cfg_vf_tph_st_mode、 cfg_vf_flr_in_process、cfg_per_function_number、 cfg_flr_done、 cfg_flr_in_process、cfg_interrupt_pending、 cfg_interrupt_msi_enable、 cfg_interrupt_msi_vf_enable、および cfg_interrupt_msi_mmenable。

• cfg_negotiated_width の利用可能なネゴシエートされたリンク幅の値を追加。

• 表「Tandem PROM/PCIe がサポートするコンフィギュレーション」のステータス (サポート対象外、ベータ、プロダクション) を更新。

• Vivado IDE の [Message Signal Interrupt] オプションを削除。

• Vivado IDE の [Enable RX Message INTFC] オプションを追加。

2015 年 9 月 30 日 4.1 • 「利用可能な PCI Express 用統合ブロック」を更新。


• PIPE 信号のマッピングに関する表「共通の入力/出力コマンドとエンドポイント PIPE 信号のマッピング」および「入力/出力バスと Endpoint PIPE 信号のマッピング」を更新。

• 推奨される Virtex® UltraScale デバイスおよび Kintex UltraScale デバイスの GT ロケーションを更新。

2015 年 7 月 2 日 4.0 • リソース使用量のデータを訂正。







2015 年 6 月 24 日 4.0 • 「利用可能な PCI Express 用統合ブロック」を更新。

• 「デバイスの低要件」の表を追加。

• m_axis_cq_tdata 信号の幅の説明を更新。

• addr_offset[2:0] 信号の説明を更新。

• sys_clk_gt 信号を追加。

• 「共通の PCI コンフィギュレーション空間ヘッダー」の表を更新。

• USER_CLK2_FREQ の属性値を更新。

• 共有ロジックが利用可能な場合に関する重要な注釈を追加。


• 「受信トランザクションの順序」の項で「受信順序の規則」の表を追加。

• 「統合ブロックコアの再配置」の項を追加。

• GT のロケーション:

° 全体的に GT ロケーションへのコアピン配置の名前を変更。

° ある GT ロケーションに対するパッケージピンを印刷するコマンドを追加。

° 「推奨される Virtex UltraScale GT ロケーション」の表を更新。

2015 年 5 月 7 日 4.0 • 「Tandem コンフィギュレーション」の項を更新。

2015 年 4 月 1 日 4.0 • 「クロックおよびリセットインターフェイスのポートの説明」で sys_reset、pcie_perstn0_out、 pcie_perstn1_in、および pcie_perstn1_out を更新。

• コアのピン配置情報を更新。

• Tandem コンフィギュレーションに関する情報を更新。

• コアのパラメーター [Additional Transceiver Control and Status Ports]、 [CORE CLOCK Frequency]、 [PLL Selection]、および [Link Partner TX Preset] を追加。

• パラメーター [Legacy Interrupt Settings]、および [MSI Capabilities] を更新。

• 既存のパラメーター [PPM Offset between receiver and transmitter]、 [Spread spectrum clocking]、および [Insertion loss at Nyquist] を新しい [GT Settings] ページへ移動。

• エンドポイントコンフィギュレーションで合成/インプリメンテーション後のネットリストシミュレーションのサポートを追加。

• PIPE モードインプリメンテーションのサポートを追加。

• コンフィギュレーターサンプルデザインの詳細を追加。

2015 年 2 月 23 日 3.1 • デバイスの選択および PCIe 統合ブロックのロケーションに関する情報を更新。

• デバイスコアのピン配置を更新。

• PIPE モードシミュレーションに関する情報を明確化。

• Base Address Register Overview パラメーター (Vivado IDE) の 32 ビット BAR の大数と 64 ビット BAR の大数を修正

2014 年 11 月 19 日 3.1 • 「コンフィギュレーション空間」セクションに Media Configuration Access Port (MCAP) Extended Capability Structure に関する説明を追加。


• Cadence Incisive Enterprise Simulator (IES) および Synopsys Verilog Compiler Simulator (VCS) のサポートを追加。

• デバイスコアのピン配置を更新。

2014 年 10 月 1 日 3.1 • コア v3.1 に合わせて更新。


• UltraScale デバイスデザインのパッケージ移行情報を追加。

2014 年 6 月 4 日 3.0 • デバイス情報を更新。







お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提

供され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこ

れらに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿ま

たは貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負

わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損

害には、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信

用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可

能であったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情

報に含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負

いません。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりませ

ん。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 https://japan.xilinx.com/legal.htm#tos で見られるザ

イリンクスの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補

助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプ

リケーションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの

製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。 https://japan.xilinx.com/legal.htm#tos で見られるザ

イリンクスの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2013-2017 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含

まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、それぞれ

の保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページ

の右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語

で入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは

受け付けておりません。あらかじめご了承ください。

2014 年 4 月 2 日 3.0 • ブロックセレクションを更新。

• コアのピン配置情報を更新。

• 共有ロジックの情報を更新。

2013 年 12 月 18 日 2.0 初版



https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos

mailto:[email protected]


ultrascale devices gen3 integrated block for pci …...ultrascale devices gen3 integrated block for...

Documents