ultrascale architecture gen3 integrated block for pci ... · ultrascale architecture gen3...

UltraScale Architecture Gen3 Integrated Block for PCI Express v3.1

LogiCORE IP 製品ガイド

Vivado Design Suite

PG156 2016 年 8 月 18 日

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

Gen3 Integrated Block for PCIe v3.1 japan.xilinx.com 2PG156 2016 年 8 月 18 日

目次

IP の概要

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

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

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

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

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

リソース使用状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

ブロックの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

コアのピン配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

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

属性の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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

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

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

クロッキング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

リセット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

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

クロッキング要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

インターフェイスの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

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

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

コンフィギュレーション空間レジスタとコンフィギュレーションインターフェイスを使用するデザイン . . . . 173

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

レーン反転 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

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

コアへの制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

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

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

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

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

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

http://japan.xilinx.com

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


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

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

付録 A : 移行およびアップグレードVivado Design Suite への移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Vivado Design Suite でのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7 シリーズ Gen2 コアから UltraScale アーキテクチャベースの Gen3 コアへの移行 . . . . . . . . . . . . . . . . . . . . . . . . 226

UltraScale アーキテクチャ PCI Express デザインのパッケージ移行. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

付録 B : コアのピン配置Kintex UltraScale デバイスコアのピン配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Virtex UltraScale デバイスコアのピン配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

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

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

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

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

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275



Gen3 Integrated Block for PCIe v3.1 japan.xilinx.com 4PG156 2016 年 8 月 18 日 Production 製品仕様

はじめに

ザイリンクスの UltraScale Architecture Gen3 Integrated Blockfor PCIe コアは、 UltraScale™ アーキテクチャをベースとするデバイスで使用する、高帯域かつスケーラブルで信頼性の高いシリアルインターコネクトの構築ブロックソリューションです。この Integrated Block for PCI Express (PCIe) ソリューションは、 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 インターフェイスをサポートしています。

PCI Express は、クロックデータリカバリ (CDR) と差動信号を使用することによって、パラレルバスアーキテクチャのさまざまな制約を緩和するシリアルアーキテクチャを提供します。CDR の使用 (ソース同期クロッキングとは対照的) はピン数を削減できるため、周波数の大幅な拡張が可能になり、またデータの同期化が容易になります。次世代 PCI™ としてPCI-SIG® が策定した PCI Express テクノロジは、既存の PCIソフトウェアモデルと下位互換性を備えています。

1 ピンあたり高帯域幅で低オーバーヘッド /低レイテンシ、さらにシグナルインテグリティ問題が小さく、 CDR アーキテクチャを備えたこの統合ブロックは、高性能かつ高効率なPCIe ソリューションの業界標準を確立します。

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

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

IP の概要

この LogiCORE™ IP について

コアの概要

サポートされる

デバイスファミリ (1)

UltraScale アーキテクチャ


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

AXI4-Stream

リソース表 2-1 を参照してください。

コアに含まれるもの

デザインファイル Verilog

サンプルデザイン Verilog

テストベンチ Verilog

制約ファイル XDC

シミュレーションモデル

Verilog


ソフトウェアドライバー (2)

なし

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

デザイン入力 Vivado® Design Suite

シミュレーション

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

『Vivado Design Suite ユーザーガイド : リリー

スノート、インストールおよびライセンス』

を参照

合成 Vivado 合成

サポート

japan.xilinx.com/support で提供

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

照してください。

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

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

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


http://japan.xilinx.com/support







第 1 章

概要UltraScale Architecture Gen3 Integrated Block for PCIe® コアは、 UltraScale™ FPGA で使用する高帯域幅でスケーラブルなシリアルインターコネクトの構築ブロックであり、 UltraScale デバイス内の統合ブロックをインスタンシエートします。

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




第 1 章 : 概要

X-Ref Target - Figure 1-1

図 1-1 : UltraScale Architecture Gen3 Integrated Block for PCIe のインターフェイス




第 1 章 : 概要

機能概要このコアは、高帯域幅、スケーラブル、高柔軟性の汎用 I/O コアであり、ほとんどの UltraScale デバイスで使用できます。 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 (TLP Processing Hint)




第 1 章 : 概要

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

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

• 電気通信ネットワーク

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

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

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

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

サポートされていない機能この統合ブロックには、 Address Translation Service が実装されませんが、外部のソフトロジックに実装することは可能です。

スイッチポートおよび Resizable BAR Extended 機能 (サイズ調整可能 BAR 拡張機能) は、サポートされていません。

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

http://japan.xilinx.com/ise/license/license_agreement.htm

http://japan.xilinx.com/products/intellectual-property/index.htm

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




第 2 章

製品仕様

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

リソース使用状況Kintex® UltraScale™ デバイスの場合に UltraScale Architecture Gen3 Integrated Block for PCIe コアに必要なリソースを見積もりました (表 2-1)。これらは、 Vivado® Design Suite を用いて得られた数値です。表 2-1 に、デフォルトのコアコンフィギュレーションで必要なリソース数を示します。

表 2-1 : 使用されるリソースの概算

レーン GTHE3 フリップフロップ(1) LUT(1) CMPS(2)

RX のコンプリーションバッファーのサイズ (KB)

RX のリクエスト

バッファーのサイズ (KB)

TX の応答バッファーのサイズ (KB)

ブロック RAM の利用

RAMB18 RAMB36

1 1 566 832

128 ～ 1024

16

8 8

8

3

12

2 2 957 1384 168

12

4 4 1740 2500 168

12

8 8 3399 4818 168

12

注記 :

1. 数値はデフォルトのコアコンフィギュレーション用です。実際の LUT および FF の使用数は、コンフィギュレーションにより

異なります。

2. CMPS (Capability Maximum Payload Size) とは、機能大のペイロードサイズです。




第 2 章 : 製品仕様

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

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

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

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

XCKU035

FBVA676 可可可(1)


FFVA1156 可可可(1)

XCKU040



FFVA1156 可可可

XCKU060FFVA1156 可可可

FFVA1517 可可可

XCKU075

FFVA1156 可可可可(1)

FFVA1517 可可可可

FFVB1760 可可可可

XCKU100XCKU115

FLVA1517 可可可可可可(1)

FLVB1760 可可可可可可

FLVD1924 可可可(1) 可可可

FLVF1924 可可可可可可

FLVD1517 可可可可可可

XCKU115FLVA2104 可可可可可可

FLVB2104 可可可可可可

XCVU065 FFVC1517 可可

XCVU080




FFVC1517 可可可可(1)

FFVD1517 可可可可

XCVU095




FFVC2104 可可可可

FFVC1517 可可可可(1)

FFVD1517 可可可可





コアのピン配置有効な UltraScale ベースアーキテクチャ FPGA のデバイスとパッケージの組み合わせにおいて推奨されるコアのピン配置は、付録 B 「コアのピン配置」を参照してください。表の内容と一致する選択したデバイスとパッケージの組み合わせに対して、 Vivado Design Suite が XDC を生成します。

デフォルトのコアのピン配置リストは、次を参照してください。

• 「Kintex UltraScale デバイスコアのピン配置」

• 「Virtex UltraScale デバイスコアのピン配置」

XCVU125

FLVB1760 可可可可

FLVB2104 可可可可

FLVC2104 可可可可

FLVA2104 可可可可

FLVD1517 可可可可

XCVU160FLGB2104 可可可可

FLGC2104 可可可可可可

XCVU190

FLGB2104 可可可可

FLGC2104 可可可可可可

FLGA2577 可可可可可可

XCVU440FLGA2892 可可可可可可

FLGB2377 可可可可可可

注記 :

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

「UltraScale アーキテクチャ PCI Express デザインのパッケージ移行」を参照してください。

2. Gen3 ラインレートは、 x1、 x2、および x4 リンク幅の -1 スピードグレードでサポートされています (このスピードグレード /コンフィギュレーションオプションの場合、 core_clk の周波数は 250MHz です。 x8 Gen3 動作は、 -2 スピードグレードまた

はそれより高速のスピードグレードが必要です。

注記 : すべてのリンク幅での Gen3 動作は、 -1 スピードグレードの UltraScale エンジニアリングサンプル (ES) デバイスでサ

ポートされていません。

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

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

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





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

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

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

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

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

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

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

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

ポート方向幅説明

m_axis_cq_tdata 出力 DW/32

コンプリーターリクエストインターフェイス (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 入力 22

CQ のデータ Ready 信号です。

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

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

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 出力をアップデートするまでの間には数サイクルの遅延が生じます。

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






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

ビットインデックス

名称幅説明

3:0 first_be[3:0] 4

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

このフィールドは、TLP の Transaction-Layer ヘッダーの 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 の Transaction-Layer ヘッダーの 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 ErrorReporting (AER) を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。

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





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

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

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

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


名称幅説明

表 2-5 : CC インターフェイスポートの説明


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 : CC インターフェイスポートの説明 (続き)


表 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 機能を使用することで、コアが接続されているルートコンプレックスに対してエラーがレポートされます。

32:1 parity 32

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

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

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

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





リクエスターリクエスト (RQ) インターフェイス

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

表 2-7 : RQ インターフェイスポートの説明


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_tready 出力 4

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

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

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

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

s_axis_rq_tvalid 入力 1

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

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





pcie_rq_seq_num 出力 4

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

オプションでこの出力を使用すると、コアの送信パイプライン内にあるリクエストの進み具合を追跡できます。この機能を使用する場合は、seq_num[3:0] バスの各リクエストに対してシーケンス番号を与えます。ユーザーアプリケーションからコンプリーション TLP を送信できなくなるパイプライン内の地点にリクエスト TLP が到達すると、コアは、pcie_rq_seq_num[3:0] 出力にこのシーケンス番号を出力します。このメカニズムによって、コアのコンプリーターコンプリーションインターフェイスへ送信されるコンプリーションとリクエスターリクエストインターフェイスに送信されるポステッドリクエストの順序を管理できます。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 : RQ インターフェイスポートの説明 (続き)


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


名称幅説明

3:0 first_be[3:0] 4

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

このフィールドは、リクエスト TLP の Transaction-Layer ヘッダーの 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 の Transaction-Layer ヘッダーの Last_BE ビットの設定に基づいて設定されます。 2 Dword またはそれ以上のメモリ読み出しの場合、これらの 4 ビットは、データブロックの後の Dword に読み出される有効なバイトを示します。 2 Dword またはそれ以上のメモリ書き込みの場合、これらのビットはペイロードの後の Dword にある有効なバイトを示します。


10:8 addr_offset[2:0] 3

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


リクエスターリクエストインターフェイスが Dword アライメントモードでコンフィギュレーションされている場合、このフィールドは常に 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 にセットされている場合、これらのビットは任意の値に設定できます。

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


名称幅説明





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 にハード接続できます。

59:28 parity 32

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

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

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

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

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


名称幅説明





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

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

表 2-9 : RC インターフェイスポートの説明


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 入力 22

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

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

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

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

表 2-9 : RC インターフェイスポートの説明 (続き)


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


名称幅説明

31:0 byte_en 32

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

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


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 になります。

42 Discontinue 1

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

TLP にペイロードがない場合に、この信号がアサートされることはありません。この信号は、ペイロード送信の後のビートでのみアサートされます (つまり、is_eof_0[0] が High の場合)。ストラドルオプションが有効の場合、コアが Discontinue 信号をアサートしていると2 つ目の TLP が開始されません。

コアがエンドポイントとしてコンフィギュレーションされる場合、 Advanced ErrorReporting (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 のサイドバンド信号の説明 (続き)


名称幅説明





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

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

送信フロー制御 (Transmit Flow Control) インターフェイス

送信フロー制御インターフェイスは、ユーザーアプリケーションが使用するインターフェイスで、コアが提供するフロー制御情報を要求するために使用します。このインターフェイスは、コアのフロー制御セレクト入力の設定に基づいて、ポステッド /ノンポステッドヘッダーフロー制御クレジット、コンプリーションヘッダーフロー制御クレジット、およびコンプリーションデータフロー制御クレジットをユーザーアプリケーションへ提供します。

表 2-11 では、コアの送信フロー制御インターフェイスのポートについて説明します。

表 2-11 : 送信フロー制御インターフェイスのポートの説明


pcie_tfc_nph_av 出力 2

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

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

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

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


• 11 : 3 または複数のクレジットが使用可能

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

pcie_tfc_npd_av 出力 2

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

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

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



• 11 : 3 または複数のクレジットが使用可能

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





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

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

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


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書き込みデータです。

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

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-13では、コアのコンフィギュレーションステータスインターフェイスのポートについて説明します。

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


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 初期化完了) の場合に有効になります。

cfg_current_speed 出力 3

現在のリンクスピードを示します。

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

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



cfg_max_payload 出力 3

Max_Payload_Size を示します。

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

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










cfg_max_read_req 出力 3

Max_Read_Request_Size を示します。

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

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






cfg_function_status 出力 8

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

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

• ビット 0 : Function 0 の I/O 空間は有効

• ビット 1 : Function 0 のメモリ空間は有効

• ビット 2 : Function 0 のバスマスターは有効

• ビット 3 : Function 0 の INTx は無効

• ビット 4 : Function 1 の I/O 空間は有効

• ビット 5 : Function 1 のメモリ空間は有効

• ビット 6 : Function 1 のバスマスターは有効

• ビット 7 : Function 1 の INTx は無効

cfg_vf_status 出力 12

コンフィギュレーション Virtual Function ステータスを示します。

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

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

• ビット 1 : Virtual Function 0 : PCI コマンドレジスタ、 Bus Master Enable など

cfg_function_power_state 出力 6

コンフィギュレーションファンクションの電力ステートを示します。

これらの出力は、Physical Function の現在の電力ステートを示します。ビット [2:0] は、 Function 0 の電力ステートをキャプチャし、ビット[5:3] は Function 1 の電力ステートをキャプチャします。電力ステートの定義は次のとおりです。• 000 : D0_uninitialized• 001 : D0_active• 010 : D1• 100 : D3_hot

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






cfg_vf_power_state 出力 18

コンフィギュレーション Virtual Function の電力ステートを示します。

これらの出力は、 Virtual Function の現在の電力ステートを示します。ビット [2:0] は、 Virtual Function 0 の電力ステートをキャプチャし、ビット [5:3] は Virtual Function 1 の電力ステートをキャプチャします。電力ステートの定義は次のとおりです。• 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 メッセージの生成を有効にします。コアがルートポートとしてコンフィギュレーションされている場合、この出力は使用されません。

cfg_ltssm_state 出力 6

この信号は、現在の 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.Entry12 : Rx_L0s.Idle13 : Rx_L0s.FTS14 : Tx_L0s.Entry15 : Tx_L0s.Idle16 : Tx_L0s.FTS17 : L1.Entry18 : L1.Idle19 : L2.Idle1A : L2.TransmitWake20 : DISABLED21 : LOOPBACK_ENTRY_MASTER22 : LOOPBACK_ACTIVE_MASTER23 : LOOPBACK_EXIT_MASTER24 : LOOPBACK_ENTRY_SLAVE25 : LOOPBACK_ACTIVE_SLAVE26 : LOOPBACK_EXIT_SLAVE27 : HOT_RESET28 : RECOVERY_EQUALIZATION_PHASE029 : RECOVERY_EQUALIZATION_PHASE12A : RECOVERY_EQUALIZATION_PHASE22B : RECOVERY_EQUALIZATION_PHASE3







cfg_rcb_status 出力 2

RCB ステータス信号です。

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

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

cfg_dpa_substate_change 出力 2

Dynamic Power Allocation Substrate の変更を示します。

エンドポイントモードの場合、コンフィギュレーション書き込みトランザクションによってダイナミックパワーアロケーション制御レジスタに書き込みが実行され、デバイスの DPA 電力ステートが変更されると、コアはこれらのいずれかの出力で 1 サイクル間パルスします。ビット 0 でのパルスは、PF0 の DPA イベントを示し、ビット 1 はPF1 に対応します。これらの出力は、ルートポートモードでは有効ではありません。

cfg_obff_enable 出力 2

OBFF (zed Buffer Flush Fill) のイネーブル信号です。

この出力は、デバイス制御 2 レジスタの OBFF Enable フィールドの設定を示します。

• 00 : OBFF は無効

• 01 : メッセージシグナルを使用して OBFF が有効化 (バリエーション A)

• 10 : メッセージシグナルを使用して OBFF が有効化 (バリエーション B)

• 11 : WAKE# シグナルを使用して OBFF が有効化

cfg_pl_status_change 出力 1

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

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

(b) リンク幅や動作スピードが変更された結果としてリンク帯域幅が自動的に変更され、その変更はリモートのノードによって実行されています。この割り込み信号は、リンク制御レジスタの Link AutonomousBandwidth 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 出力 2

この出力のビット 0 は、 Physical Function 0 の TPH リクエスターの機能構造体にある TPH リクエスター制御レジスタの TPH RequesterEnable ビット [8] の設定を示します。ビット 1 は、 Physical Function 1に対応します。







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

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

cfg_tph_st_mode 出力 6この出力のビット [2:0] は、Physical Function 0 の TPH リクエスター制御レジスタにある ST Mode Select ビットの設定を示します。ビット[5:3] は、 PF 1 の同レジスタフィールドの設定を示します。

cfg_vf_tph_requester_enable 出力 6この出力のビット 0 は、対応する Virtual Function 0 の TPH リクエスター機能構造体にある TPH リクエスター制御レジスタの TPHRequester Enable ビット 8 の設定を示します。

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



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


cfg_msg_received 出力 1

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

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

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

この出力は、 AXISTEN_IF_ENABLE_RX_MSG_INTFC 属性が設定されている場合のみ有効になります。

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

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

cfg_msg_received_type 出力 5

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

cfg_msg_received が High の場合、これらの 5 つのビットは、コア

が送信するメッセージタイプを示します。メッセージタイプの一覧

は、表 3-11 を参照してください。





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

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

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


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 (パワーマネージメント )• 100b ～ 111b : 予約済み

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(複数の PF または VF が同時に PM_PME 信号をパルス可能)

• 100b - 111b : 予約済み

cfg_msg_transmit_done 出力 1

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

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





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

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

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


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]入力で選択されます。

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] 入力で選択されます。





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

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

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-16 : コンフィギュレーションフロー制御インターフェイスのポートの説明 (続き)


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


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_data および cfg_per_function_number の値に基づいて情報が提供されます。





表 2-18 : Function Status インターフェイスのポートの説明

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]

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

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 ErrorReporting Enable : Device_Ctrl[0]

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

表 2-18 : Function Status インターフェイスのポートの説明 (続き)


[ビット ]







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 バイトの大ペイロードサイズ

• 001b = 256 バイトの大ペイロードサイズ

• 010b = 512 バイトの大ペイロードサイズ • 011b = 1024 バイトの大ペイロードサイズ • 100b = 2048 バイトの大ペイロードサイズ • 101b = 4096 バイトの大ペイロードサイズ

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 がコンフィギュレーションまたはリカバリステートであることを示しているか、あるいは RetrainLink ビットに 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_common_clock

1

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

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

3 5cfg_link_control_extended_sync

1

コンフィギュレーションリンク制御 - Extended Synch :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]

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



[ビット ]







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

コンフィギュレーション制御インターフェイスは、ユーザーアプリケーションとコア間でさまざまなデータ通信を可能にします。ユーザーアプリケーションは、このインターフェイスを使用してコンフィギュレーション空間を設定します（修正可能/修正不可能なエラーの有無。デバイスのシリアル番号の設定。ダウンストリームバス、デバイス、ファンクション番号の設定。ファンクションごとのコンフィギュレーション情報の受信)。また、このインターフェイスは、電力ステートが変更されたり、ファンクションレベルのリセットが生じた場合に、ユーザーアプリケーションとコア間のハンドシェイクを実行します。

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

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-19 : コンフィギュレーション制御インターフェイスのポートの説明


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 入力 3

ファンクションごとのターゲットファンクション番号を示します。

ユーザーがファンクション番号 (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 で使用されます。 TRN インターフェイスに現れる TLP には影響を与えません。

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





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 にホールドして、電力ステートを変更できます。

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_snp_function_number[7:0] 出力に提供されます。ユーザーアプリケーションがcfg_power_state_change_ack をアサートすると、ステート変更を受けたファンクションの新しいステートがコアのcfg_function_power_state (PF の場合)、またはcfg_vf_power_state (VF の場合) 出力に反映されます。

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






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 入力 2

ファンクションレベルのリセット完了を示します。

ファンクション i のリセット動作が完了した場合、このバスのビット i をアサートする必要があります。これによって、コアはファンクション i の cfg_flr_in_process をディアサートして、そのファンクションへのコンフィギュレーションアクセスを再度有効にします。

cfg_vf_flr_done 入力 6

Virtual Function のファンクションレベルのリセット完了を示します。

Virtual Function i のリセット動作が完了した場合、このバスのビット i をアサートする必要があります。これによって、コアはファンクション i の cfg_vf_flr_in_process をディアサートして、その Virtual Function へのコンフィギュレーションアクセスを再度有効にします。

cfg_flr_in_process 出力 2

ファンクションレベルのリセットが実行中であることを示します。

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

cfg_vf_flr_in_process 出力 6

Virtual Function のファンクションレベルのリセットが実行中であることを示します。

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







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

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

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ステートへ遷移します。



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


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 入力 2

コンフィギュレーション INTx 割り込みペンディング (アクティブ-High) を示します。

ファンクションごとのペンディング割り込みを示します。cfg_interrupt_pending[0] は、Function #0 に対応します。

cfg_interrupt_msi_enable 出力 2

コンフィギュレーション割り込み MSI ファンクションのイネーブルを示します。

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





cfg_interrupt_msi_vf_enable 出力 6

VF のコンフィギュレーション割り込み MSI が有効であることを示します。

各 Virtual Function の MSI メッセージが有効であることを示します。

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 割り込みを再度送信する必要があります。

cfg_interrupt_msi_mmenable 出力 6

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

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

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






cfg_interrupt_msi_pending_status 入力 64

コンフィギュレーション割り込みの MSI ペンディングステータスを示します。

これらの入力は、Physical Function の MSI ペンディング割り込みステータスを示します。これらのピンの設定が、対応するPF の MSI ペンディングビットレジスタから読み出される値を決定します。ビット [31:0] は、 PF0 に属し、ビット [63:32]は PF1 に属します。 MSI ペンディングビットレジスタには、MSI 割り込みの Pending (保留) ビットが含まれます。このロケーションを読み出すと、コアの MSI マスク入力のステートが返ってきます。これは、 MSI マスク入力のデフォルト値を含む 32 ビット幅の RO レジスタです。

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]は、すべての Virtual Function に関連する MSI 制御レジスタのMultiple Message Enable ビットを示します。これらのビットは、対応するファンクションに対して割り当てられた MSI 割り込みベクター番号をエンコードします。cfg_interrupt_msi_data[2:0] は、Virtual Function 0 に対応します。

cfg_interrupt_msi_data 出力 32コンフィギュレーション割り込みの MSI データを示します。

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

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 の Configuration Interrupt MSI-X が有効であることを示します。

アサートされると、各ファンクションに対して、 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 からのアドレス情報とデータを内部レジスタに格納します。ユーザーロジックは、割り込みを 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 は NoSnoop ビットで、ビット 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 への遷移する際にこれらのビットをサンプルします。

cfg_interrupt_msi_function_number 入力 3

コンフィギュレーションの MSI/MSI-X 開始ファンクションを示します。

MSI または MSI-X トランザクションを開始するエンドポイントファンクション番号を示します。• 0 : PF0• 1 : PF1• 2 : VF0• 3 : VF1• 4 : VF2

...• 7 : VF5







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

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

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


cfg_ext_read_received 出力 1

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

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

cfg_ext_write_byte_enable 出力 4

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

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





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

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

cfg_ext_read_data 入力 32

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

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

cfg_ext_read_data_valid 入力 1

コンフィギュレーション拡張インターフェイスの読み出しデータが有効であることを示します。

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

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


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


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

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

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

sys_clk 入力 1基準クロックです。

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

sys_reset 入力 1

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

X0Y0 PCIe ロケーションを使用するエンドポイントコンフィギュレーションの場合、 sys_reset は PERSTN0 パッケージピンから直接駆動される必要があります。別のパッケージピンまたはコンフィギュレーションロジックから、 X0Y0 PCIe ブロックの sys_reset を駆動する場合は、 Vivado IDE で配線される専用のリセット信号を無効にします。X0Y0 PCIe ブロックの sys_resetを駆動する場合は、常に PERSTN0 パッケージピンを使用することを推奨します。エンドポイントとしてコンフィギュレーションされたその他の PCIe ブロックの場合は、可能な限り PERSTN1 パッケージピンを使用してsys_reset を駆動してください。





表 2-22 に示す PERSTN0/PERSTN1 パッケージピンおよびポートは、専用の PCIe リセット配線に使用されます。PERSTN これらはパッケージピンから PCIe コア (X0Y0) への専用ポートです。 Tandem コンフィギュレーションのサポートが必要な方は、表 2-22 の説明に従ってこれらのピンを使用してください。 PERSTN0 および PERSTN1 ピンを使用する際の一般的なガイドラインを次に示します。

• PCIe_X0Y* RootPort コンフィギュレーションは、任意のピンを使用してエッジコネクタリセットを駆動できます。

• PCIe_X0Y0 エンドポイントコンフィギュレーションは、 PCIe エッジコネクタリセット入力ピンとして常に PERSTN0 を使用する必要があります。

• PCIe_X0Y (non-zero) エンドポイントコンフィギュレーションは、 PCIe エッジコネクタリセット入力ピンとして PERST1 を優先すべきですが、必要に応じて任意のピンを使用できます。

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-23 を参照してください。

pcie_perstn0_out 出力 1

X0Y0 PCIe ブロックの sys_reset 入力ポートを介す、PERSTN0 パッケージピンからの直接パススルー出力です。このポートは、 X0Y0 PCIe ブロックが選択され、専用配線が有効 (デフォルト ) に設定され、sys_reset が PERSTN0パッケージピンで駆動されている場合にのみ使用されます。その他のコンフィギュレーションおよび PCIe ロケーションの場合、このポートは接続する必要がありません。 X0Y0 PCIe ロケーションを使用するエンドポイントコンフィギュレーションの場合は、PERSTN0 を使用して sys_reset 入力を駆動する必要があります。

pcie_perstn1_in 入力 1

PERSTN1 パッケージピンから PCIe_X0Y0 pcie_perstn1_out 出力への専用配線の入力です。この入力は、PERSTN1 パッケージピンでのみ駆動可能で、X0Y0PCIe ロケーションに対してのみ使用します。その他すべての PCIe ロケーションで、このポートを使用しない場合は、定数 0 (1'b0) に接続してください。

pcie_perstn1_out 出力 1

X0Y0 PCIe ブロックの pcie_perstn1_in 入力ポートを介す、 PERSTN1 パッケージピンからの直接パススルー出力です。このポートは、 X0Y0 PCIe ブロックが選択され、専用配線が有効 (デフォルト ) に設定され、pcie_perstn1_in が PERSTN1 パッケージピンで駆動されている場合にのみ使用されます。その他のコンフィギュレーションおよび PCIe ロケーションの場合、このポートは接続する必要がありません。 X0Y0 PCIe ロケーションに設定されていない PCIe エンドポイントコンフィギュレーションの場合は、 PERSTN1 を使用して sys_reset 入力を駆動する必要があります。

表 2-22 : クロックおよびリセットインターフェイスのポートの説明 (続き)


表 2-23 : PCI Express インターフェイス信号 (1、 2、 3、および 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 レーンコア









4 レーンコア

















8 レーンコア









表 2-23 : PCI Express インターフェイス信号 (1、 2、 3、および 8 レーンコアの場合) (続き)

レーン番号

名称方向説明





























表 2-23 : PCI Express インターフェイス信号 (1、 2、 3、および 8 レーンコアの場合) (続き)

レーン番号

名称方向説明





属性の説明

クライアントインターフェイス

表 2-24 には、コアのクライアントインターフェイスの動作を制御するコンフィギュレーション属性を示します。

表 2-24 : 統合ブロックのクライアントインターフェイスのコンフィギュレーション属性

属性名タイプ説明

USER_CLK2_FREQ 整数

• 0 : ユーザークロックを無効化• 1 : 31.25MHz

• 2 : 62.50MHz (デフォルト )• 3 : 125.00MHz• 4 : 250.00MHz• 5 : 500.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 : パリティチェックは有効

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-25 に、この属性のビットと対応するさまざまなメッセージタイプを示します。

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-24 : 統合ブロックのクライアントインターフェイスのコンフィギュレーション属性 (続き)

属性名タイプ説明





コンフィギュレーション空間PCI コンフィギュレーション空間は、表 2-26 に示すように主に 3 つの要素から構成されています。これらの詳細を次に示します。

• レガシ PCI v3.0 タイプ 0/1 コンフィギュレーション空間ヘッダー

° エンドポイントアプリケーションで使用されるタイプ 0 のコンフィギュレーション空間ヘッダー (表 2-27を参照)

° ルートポートアプリケーションで使用されるタイプ 1 のコンフィギュレーション空間ヘッダー (表 2-28 を参照)

• レガシ拡張機能項目

° PCIe 機能項目

° パワーマネージメント機能項目

° Message Signal Interrupt (MSI) 機能項目

° MSI-X 機能項目 (オプション)

• PCIe 機能

° Advanced Error Reporting (AER) 拡張機能構造体

° Alternate Requester ID (ARI) (オプション)

° Device Serial Number 機能構造体 (DSN) (オプション)

表 2-25 : 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

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 応答





° 電力バジェット機能の強化

° 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) 拡張機能構造体 (オプション)

• PCIe 拡張機能

° Device Serial Number 拡張機能構造体 (オプション)

° Virtual Channel 拡張機能構造体 (オプション)

° Advanced Error Reporting (AER) 拡張機能構造体 (オプション)

° Medica Configuration Access Port (MCAP) 拡張機能構造体 (オプション)

コアは、レガシ拡張機能項目を大 4 つまで実装できます。

この機能の有効化に関する詳細は、第 4 章の「コアのカスタマイズおよび生成」を参照してください。

コアは、 PCI Express 拡張機能を大 10 まで実装できます。残りの PCI Express 拡張機能空間は、ユーザーが定義できます。ユーザーが利用できるこの空間の開始アドレスは、 3DCh となります。この空間にレジスタを実装する場合は、この空間の開始アドレスを選択でき、この空間をユーザーアプリケーションに実装する必要があります。

この機能の有効化に関する詳細は、第 4 章の「[Extended Capabilities 1] および [Extended Capabilities 2]」を参照してください。





表 2-26 : 共通の PCI コンフィギュレーション空間ヘッダー

31 16 15 0

デバイス ID ベンダー ID 000h

ステータスコマンド 004h

クラスコードリビジョン ID 008h

BIST ヘッダーラッチタイマーキャッシュレーン 00Ch

ヘッダータイプ別

(表 2-27 および表 2-28 を参照)

010h

014h

018h

01Ch

020h

024h

028h

02Ch

030h

CapPtr 034h

038h

割り込みピン割り込みライン 03Ch

予約済み040h-07Ch

PM 機能 NxtCap PM Cap 080h

データ予約済み PMCSR 084h


カスタマイズ可能(1) MSI 制御次の Cap MSI Cap 090h

メッセージアドレス (下位) 094h

メッセージアドレス (上位) 098h

予約済みメッセージデータ 09Ch

マスクビット 0A0h

ペンディングビット 0A4h

予約済み0A8h-0ACh





オプション(3) MSl-X 制御 NxtCap MSl-X Cap 0B0h

テーブルオフセットテーブル BIR 0B4h

PBA オフセット PBA BIR 0B8h

予約済み 0BCh

PE 機能 NxtCap PE Cap 0C0h

PCI Express デバイス機能 0C4h

デバイスステータスデバイス制御 0C8h

PCI Express リンク機能 0CCh

リンクステータスリンク制御 0D0h

ルートポートのみ(2) スロット機能 0D4h

スロットステータススロット制御 0D8h

ルート機能ルート制御 0DCh

ルートステータス 0E0h

PCI Express デバイス機能 2 0E4h

デバイスステータス 2 デバイス制御 2 0E8h

PCI Express リンク機能 2 0ECh

リンクステータス 2 リンク制御 2 0F0h

未実装のコンフィギュレーション空間 (0x00000000 を返す)

0F4h-0FCh

常に有効次の Cap Cap.Ver. PCI Express 拡張機能 ID (AER) 100h

修正不可能エラーステータスレジスタ 104h

修正不可能エラーマスクレジスタ 108h

修正不可能エラー重要度レジスタ 10Ch

修正可能エラーステータスレジスタ 110h

修正可能エラーマスクレジスタ 114h

アドバンスエラー機能および制御レジスタ 118h

ヘッダーログレジスタ 1 11Ch

ヘッダーログレジスタ 2 120h



予約済み 12Ch

オプション、ルートポートのみ(3)

ルートエラーコマンドレジスタ 130h

ルートエラーステータスレジスタ 134h

エラーソース ID レジスタ 138h

予約済み 13Ch

オプション(3)(4)次の Cap Cap.Ver. PCI Express 拡張機能 - ARI (Alternate

Requester ID)140h

制御次のファンクションファンクション

グループ

144h

表 2-26 : 共通の PCI コンフィギュレーション空間ヘッダー (続き)

31 16 15 0






オプション(3) 次の Cap Cap.Ver. PCI Express 拡張機能 - DSN 150h

PCI Express デバイスシリアル番号 (1st) 154h

PCI Express デバイスシリアル番号 (2nd) 158h

予約済み 15Ch

オプション(3)次の Cap Cap.Ver. PCI Express 拡張機能 - 電力バジェット

拡張機能ヘッダー

160h

予約済み DS 164h

予約済み電力バジェットデータ - ステート D0、 D1、 D3、 ... 168h

電力バジェット機能 16Ch

予約済み 170h-1B4h

オプション(3)次の Cap Cap.Ver. PCI Express 拡張機能 ID - Latency Tolerance

Reporting (LTR)1B8h

No-Snoop Snoop 1BCh

オプション(3)次の Cap Cap.Ver. PCI Express 拡張機能 ID - ダイナミック

パワーアロケーション (DPA)1C0h

機能レジスタ 1C4h

レイテンシインジケーター 1C8h

制御ステータス 1CCh

パワーアロケーションアレイレジスタ 0 1D0h

パワーアロケーションアレイレジスタ 1 1D4h

予約済み1D8h-1FCh


31 16 15 0





オプション(3)次の Cap Cap.Ver. PCI Express 拡張機能 ID - Single Root I/O

Virtualization (SR-IOV)200h

機能レジスタ 204h

SR-IOV ステータス (サポート対象外) 制御 208h

トータル VF イニシャル VF 20Ch

Function Dependency Link Number VFs 210h

VF ストライド初の VF オフセット 214h

VF デバイス ID 予約済み 218h

サポートされるページサイズ 21Ch

システムページサイズ 220h

VF ベースアドレスレジスタ 0 224h


VF ベースアドレスレジスタ 2 22Ch




予約済み 23Ch

予約済み240h-270h

オプション(3)次の Cap Cap.Ver. PCI Express 拡張機能 ID - TPH (Transaction

Processing Hint)274h


リクエスター制御レジスタ 27Ch

予約済みステアリングタグ (上位)

ステアリングタグ (下位)

280h

予約済み284h - 2FCh

オプション(3) 次の Cap Cap.Ver. PCI Express 拡張機能 ID - セカンダリ PCIe 拡張機能

300h

レーン制御 (サポート対象外) 304h

予約済みレーンエラーステータス

308h

レーンイコライゼーション制御レジスタ 0 30Ch

レーンイコライゼーション制御レジスタ 1 310h



予約済み31Ch-33Ch


31 16 15 0





オプション(3) 次の Cap Cap.Ver. PCI Express 拡張機能 ID - MCAP 340h


FPGA JTAG ID 348h

FPGA ビットストリームバージョン 34Ch

ステータスレジスタ 350h

制御レジスタ 354h

データ書き込みレジスタ 358h

データ読み出しレジスタ 35Ch

予約済み 360h

予約済み 364h

予約済み 368h

予約済み36Ch-3BCh

オプション(3) 次の Cap Cap.Ver. PCI Express 拡張機能 - VC 3C0h

ポート VC 機能レジスタ 1 3C4h

ポート VC 機能レジスタ 2 3C8h

ポート VC ステータスポート VC 制御 3CCh

VC リソース機能レジスタ 0 3D0h

VC リソース制御レジスタ 0 3D4h

VC リソースステータスレジスタ 0 3D8h

予約済み400h-FFFh

注記 :

1. MSI 機能構造体は、 Vivado IDE 内での選択内容によって異なります。

2. エンドポイントコンフィギュレーション用に予約されています (0x00000000 を返す)。

3. PCI Express 拡張コンフィギュレーション空間のレイアウト (100h-FFFh) は、有効化されたオプション機能によって変わりま

す。この表は、オプションのすべての拡張機能構造体 (RBAR) が有効な場合での拡張コンフィギュレーション空間レイアウト

を示しています。

4. SR-IOV オプションが有効に設定されている場合、デフォルトで有効となります。


31 16 15 0





表 2-27 : タイプ 0 PCI コンフィギュレーション空間ヘッダー

31 16 15 0





ベースアドレスレジスタ 0 10h



ベースアドレスレジスタ 3 1Ch



Cardbus CIS ポインター 28h

サブシステム ID サブシステムベンダー ID 2Ch

拡張 ROM ベースアドレス 30h

予約済み CapPtr 34h

予約済み 38h

Max Lat Min Gnt 割り込みピン割り込みライン 3Ch

表 2-28 : タイプ 1 PCI コンフィギュレーション空間ヘッダー

31 16 15 0







セカンドラッチタイマーサブバス番号セカンドバス番号プライマリバス番号 18h

セカンダリステータス I/O 制限 I/O ベース 1Ch

メモリ制限メモリベース 20h

プリフェッチ可能なメモリ制限プリフェッチ可能なメモリベース 24h

プリフェッチ可能なベース上位 32 ビット 28h

プリフェッチ可能な制限上位 32 ビット 2Ch

I/O 制限上位 16 ビット I/O ベース上位 16 ビット 30h

予約済み CapPtr 34h

拡張 ROM ベースアドレス 38h

ブリッジ制御割り込みピン割り込みライン 3Ch




第 3 章

コアを使用するデザインこの章では、コアを使用した設計をより容易にするためのガイドラインおよび追加情報を紹介します。

共有ロジックこの機能により、 PCIe® ブロックの複数のインスタンス間で共通ロジックを共有したり、または制限事項はありますがほかのコアと共通ロジックを共有することができます。この共有ロジックにより、デザインの上位モジュールに共有するロジックを配置するのに必要な HDL の変更を小限に抑えることができ、また上位モジュールの追加ポートを有効にし、共有を可能にすることができます。共有ロジックはエンドポイントモードに対してのみ利用でき、ルートポートモードでは使用できません。

Vivado® Design Suite ではコアをカスタマイズするときの [Shared Logic] ページでこのオプションを設定することができます。

ロジック共有には 2 つのタイプがあります。

• コアに含まれた共有ロジック

• サンプルデザインに含まれた共有ロジック

これらの両ケースで GT_COMMON ブロックが共有されます。

重要 : [Include Shared Logic in Example Design] オプションをオンにして該当するモジュールがサポートディレクトリに生成されるようにする場合、出力ファイルの生成後に [Open IP Example Design] を実行する必要があります。 [IncludeShared Logic in Core] (デフォルト ) オプションをオンにすると、これらのモジュールがソースディレクトリに生成されます。




第 3 章 : コアを使用するデザイン

コアに含まれた共有ロジック

この機能を使用すると、 GT_COMMON ブロックをコア内部で共有することができます (サポートラッパーではない)。[Shared Logic] ページで [Include Shared Logic in Core] をオンにして、この機能を有効にします。 X-Ref Target - Figure 3-1

図 3-1 : コアに含まれた共有ロジック





共有 GT_COMMONGT_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 : サンプルデザインに含まれた共有ロジック





Tandem コンフィギュレーションUltraScale Architecture Gen3 Integrated Block for PCIe ソリューションは、 PCI Express 仕様のタイミング要件を満たすために、さらに 2 つのコンフィギュレーション方法を提供しています。PCI Express 仕様では、システムが電源安定 (powergood) 状態になってから 100ms 後に PERST# がディアサートされ、 PERST# がディアサートされてから 20ms 以内にPCI Express でリンクトレーニングが確立するよう定められています。これは、一般的に「100ms ブートタイム要件」と呼ばれています。 2 つのコンフィギュレーション方法は、タンデム PROM とタンデム PCI Express (PCIe) とそれぞれが呼ばれています。これらのソリューションは、この特定の目標を達成するためにデザインされています。ユーザーアプリケーションのダイナミックフィールドアップデートなど、その他のコンフィギュレーションの柔軟性が必要な場合は、 Tandem コンフィギュレーションの代わりに一般的なパーシャルリコンフィギュレーションを使用してください。

タンデム PROM とタンデム PCIe は、どちらも 2 段階のコンフィギュレーション手法を採用します。タンデムPROM とタンデム PCIe では、 PCI Express 動作に重要な第 1 コンフィギュレーションメモリセルは、ローカルPROM を使用してロードされます。これらのセルのロードが完了すると、第 1 ビットストリームの終わりに FPGAスタートアップコマンドが FPGA コンフィギュレーションコントローラーへ送信されます。部分的にコンフィギュレーションされた FPGA は、第 1 ビットストリームコンテンツでアクティブ状態となります。完全機能の PCI Expressポートを含む第 1 ビットストリームは、第 2 ビットストリームが FPGA へロードされている間、PCI Express エニュメレート中に受信されるトラフィックに応答します。第 1 ビットストリームには、PCI Express ポート全体を機能させるのに必要となる、 PCI Express 統合ブロック、ギガビットトランシーバー、ブロック RAM、クロッキングリソース、FPGA ロジック、および配線リソースが含まれます。第 2 ビットストリームには、ユーザーが指定するアプリケーションやその他のクロッキングおよび I/O リソースが含まれ、基本的には残りの FPGA デザインが含まれます。第 2ビットストリームをロードするためのメカニズムは、タンデム PROM とタンデム PCIe 間で異なります。

サポートされるデバイス

UltraScale Architecture Gen3 Integrated Block for PCIe コアおよび Vivado ツールフローは、ザイリンクスのリファレンスボードと特定のデバイス /パッケージの組み合わせをターゲットにしたインプリメンテーションをサポートしています。

Vivado Design Suite 2014.4 リリースでは、 Tandem コンフィギュレーションは、特定デバイスに対してのみソフトウェア専用ベータ版としてサポートされています。エンジニアリングサンプル 2 (ES2) (Virtex UltraScale) または Production仕様 (Kintex UltraScale) シリコンがリリースされてソフトウェアでサポートされるまで、ビットストリームの生成はできません。それまでは、デザインを実装して、サポートされるシリコンがリリースされるまで準備しておくことができます。 Tandem コンフィギュレーションは、表 3-2 にあるコンフィギュレーションをサポートしています。

表 3-2 : タンデム PROM/PCIe がサポートするコンフィギュレーション

HDL Verilog のみ

PCIe コンフィギュレーションすべてのコンフィギュレーション ( 大 : X8Gen3)

ザイリンクスリファレンスボードのサポート

KCU105 評価ボード (Kintex Ultrascale FPGA 用)VCU107 評価ボード (Virtex Ultrascale FPGA 用)





デバイスサポート

サポートされるデバイス/パッケージの組み合わせ :

デバイス番号パッケージ [PCIe Block Location] PCIe リセットのロケーション

ステータス

Kintex UltraScale

XCKU035 すべて PCIE_3_1_X0Y0 IOB_X1Y103 まだサポートされていない

XCKU040 すべて PCIE_3_1_X0Y0 IOB_X1Y103 ベータ版(1)

XCKU060 すべて PCIE_3_1_X0Y0 IOB_X2Y103 ベータ版




Virtex UltraScale

XCVU065 すべて PCIE_3_1_X0Y0 IOB_X1Y103 まだサポートされていない


XCVU095 すべて PCIE_3_1_X0Y0 IOB_X1Y103 ベータ版(2)


XCVU160 すべて PCIE_3_1_X0Y2(3) IOB_X1Y363 まだサポートされていない



注記 :

1. タンデムフローのビットストリーム生成は、 Production 仕様の Kintex UltraScale デバイスでのみサポートされます。

2. タンデムフローのビットストリーム生成は、ES2 または Production 仕様シリコンの Virtex UltraScale デバイスでのみサポートさ

れます。

3. このロケーションは、Vivado Design Suite 2014.3 で変更されました。以前のバージョンでは、PCIE_3_1_X0Y1 となっていました。

表 3-2 : タンデム PROM/PCIe がサポートするコンフィギュレーション (続き)





タンデムツールフローの概要

タンデム PROM およびタンデム PCIe ソリューションは、 Vivado Design Suite でのみサポートされています。これらのソリューションのツールフローは、次のとおりです。

1. コアのカスタマイズ : 表 3-2 からサポートされるデバイスを選択し、コンフィギュレーションモードに[Advanced] オプションを選択して、 Tandem コンフィギュレーションオプションとして [Tandem PROM] または[Tandem PCIe] のいずれかを選択します。

2. コアを生成します。

3. サンプルプロジェクトを開いて、サンプルデザインをインプリメントします。

4. ユーザープロジェクトで、サンプルプロジェクトからの IP や XDC を使用して、コアをインスタンシエートします。

5. ユーザーデザインを合成してインプリメントします。

6. ビットファイルを生成し、次に prom ファイルを生成します。

タンデムフローの一環として、 PCIe コアロジックの外部にある特定エレメントも第 1 ビットストリームに含める必要があります。 Vivado DRC は、これらの状況を認識し、問題を解決する方法を指示します。通常、デザインの制約を変更したり、追加して問題を解決します。

サンプルデザインが作成される場合には、特定の制約を含むサンプルの XDC ファイルが生成され、これはユーザーが指定するプロジェクトの XDC ファイルへコピーされる必要があります。具体的な制約内容は、サンプルデザインの XDC ファイルに記載されています。また、このサンプルデザイン XDC ファイルには、 BPI や SPI などのフラッシュデバイス用のオプションの設定方法の例も含まれています。

Tandem コンフィギュレーションは、AXI4-Stream バージョンのコアに対してのみサポートされており、 IP カタログを使用して生成される必要があります。

タンデム PROM タンデム PROM ソリューションは、ビットストリームを 2 つに分割していますが、これらのは両方ともオンボードのローカルコンフィギュレーションメモリ (通常は PROM またはフラッシュデバイス) からロードされます。初のビットストリームは、デザインの PCI Express 部分をコンフィギュレーションし、 2 つ目のビットストリームは FPGAの残りの部分をコンフィギュレーションします。図 3-3 に示すように、デザインは 2 段階に分けられていますが、生成される BIT ファイルは 1 つだけであり、 1 つ目と 2 つ目を両方含みます。


図 3-3 : タンデム PROM ビットストリームのロード手順





タンデム PROM VCU107 サンプルツールフロー

このセクションでは、 VCU107 リファレンスボードをターゲットにした場合の 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. [Customize IP] ダイアログボックスの [Basic] タブで、次のようにオプションが選択されていることを確認します。

° [Mode] : Advanced

° [PCIe Block Location] : X0Y0

° [Tandem Configuration or Partial Reconfiguration] : Tandem PROM


図 3-4 : Vivado IP カタログ





4. その他に必要な PCIe カスタマイズを実行し、 [OK] をクリックしてコアを生成します。

5. どの出力ファイルを生成するかをたずねる画面が表示されたら、 [Generate] をクリックします。

6. [Sources] ウィンドウでコアを右クリックし、 [Open IP Example Design] をクリックします。

Vivado の新しいインスタンスが開き、サンプルデザインが自動的に Vivado IDE にロードされます。

7. 合成およびインプリメンテーションを実行します。

Flow Navigator で [Run Implementation] をクリックします。合成を先に実行するには、 [OK] をクリックします。完全ツールフローによってデザインが実行され、タンデム PROM をサポートする完全に配線されたデザインが作成されます。

8. PROM またはフラッシュを設定します。

PROM またはフラッシュデバイスのビットストリームを生成するため、適切な設定を行います。詳細は、85 ページの「デバイスのプログラム」を参照してください。


図 3-5 : タンデム PROM





9. ビットストリームを生成します。

合成およびインプリメンテーション完了後、 Flow Navigator で [Generate Bitstream] をクリックします。 Tandem コンフィギュレーションをサポートするビットストリームが runs ディレクトリに生成されます。例 : ./pcie_ultrascale_0_example.runs/impl/xilinx_pcie3_uscale_ep_tandem.bit

重要 : Tandem コンフィギュレーションをサポートするシリコンがリリースされるまでビットストリームの生成はできません。詳細は、ザイリンクスまでお問い合わせください。

注記 : 第 1 段階と第 2 段階のビットストリームを個別に生成するオプションがあります。このフローでは、テスト用の JTAG インターフェイスを使用して、各段階のビットストリームロードを制御できます。ビットストリーム生成に必要なコマンドを次に示します。このコマンドは、 Tcl スクリプトに追加したり、ビットストリームの書き込み段階の tcl.pre ファイルとして含めることができます。これは [Bitstream Settings] ダイアログボックスの tcl.pre 設定の中で指定できます。

set_property HD.SEPARATE_BITSTREAMS TRUE [current_design]

生成されたビットファイル名は、xilinx_pcie3_uscale_ep_tandem1.bit および xilinx_pcie3_uscale_ep_tandem2.bit となります。

10. PROM ファイルを生成します。

Vivado の Tcl コンソールで、次のコマンドを実行して、 VCU107 開発ボードでサポートされる PROM ファイルを作成します。

write_cfgmem -format mcs -interface BPI -size 256 -loadbit "up 0x0 xilinx_pcie3_uscale_ep.bit" xilinx_pcie3_uscale_ep.mcs

タンデム PROM のまとめ

タンデム PROM を使用することにより、 UltraScale アーキテクチャデザインの PCIe 部分をコンフィギュレーションするのに必要な時間を大幅に短縮できます。 UltraScale Architecture Gen3 Integrated Block for PCIe コアがデザインの詳細の多くを管理するため、設計者はユーザーアプリケーションに集中できます。

タンデム PCIeタンデム PCIe は、タンデム PROM と類似しています。第 1 段階のビットストリームには、 PCI Express 動作に必要なコンフィギュレーションメモリセルのみが PROM からロードされます。第 1 段階のビットストリームがロードされた後、 PCI Express ポートは、エニュメレーショントラフィックに応答します。これに続いて、第 2 段階のビットストリームが PCI Express リンクから送信されます。図 3-6 に、ビットストリームのロードフローを示します。


図 3-6 : タンデム PCIe ビットストリームのロード手順





タンデム PCIe は、ツールフローとビットストリーム生成に関して言えば、今使用されている標準モデルに類似しています。 2 つのビットストリームは、ビットストリーム生成が実行されると生成されます。第 1 段階を表す BIT ファイルが PROM にダウンロードされる間、ユーザーアプリケーション (第 2 段階) を表すもう一つの BIT ファイルが MediaConfiguration Access Port (MCAP) を使用して FPGA の残りの部分をコンフィギュレーションします。

注記 : 第 2 ビットストリームのフィールドアップデート、つまり不変の第 1 ビットストリームの複数のユーザーアプリケーションイメージは、 2014.3 リリースの時点でまだサポートされていません。

タンデム PCIe VCU107 サンプルツールフロー

このセクションでは、 VCU107 リファレンスボードをターゲットにした場合の Vivado ツールフローを初から後まで説明します。このフローを説明する上で表示されるパスおよびポインター名には、デフォルトのコンポーネント名「 pcie3_ultrascale_0 」を使用しています。

1. 新規の Vivado プロジェクトを作成して、表 3-2 にあるデバイス /パッケージの組み合わせを選択します。

2. Vivado IP カタログで、 [Standard Bus Interfaces] → [PCI Express] を展開表示し、 [Ultrascale FPGA Gen3 IntegratedBlock for PCI Express] をダブルクリックして [Customize IP] ダイアログボックスを開きます。

3. [Customize IP] ダイアログボックスの [Basic] タブで、次のようにオプションが選択されていることを確認します。

° [Mode] : Advanced

° [PCIe Block Location] : X0Y0

° [Tandem Configuration or Partial Reconfiguration] : Tandem PCIe


図 3-7 : Vivado IP カタログ





4. サンプルデザインのソフトウェアは、ベンダー ID およびデバイス ID を使用してデバイスに接続します。ベンダー ID は 16'h10EE、デバイス ID は 16'h8038 となります。 [PFO IDs] タブで次のように設定します。

° [Vendor ID] : 10EE

° [Device ID] : 8038

注記 : 別のソリューションの場合は、ベンダー ID およびデバイス ID を変更し、ソフトウェアをアップデートして新しい値と一致させます。


図 3-8 : タンデム PCIe





5. その他に必要な PCIe カスタマイズを実行し、 [OK] をクリックしてコアを生成します。

コアが生成されると、 Vivado IDE の [Source] ウィンドウにコアの階層が表示されます。

6. [Sources] ウィンドウでコアを右クリックし、 [Open IP Example Design] をクリックします。

Vivado の新しいインスタンスが開き、サンプルデザインプロジェクトが自動的に Vivado IDE にロードされます。

7. 合成およびインプリメンテーションを実行します。

Flow Navigator で [Run Implementation] をクリックします。合成を先に実行するには、 [OK] をクリックします。完全ツールフローによってデザインが実行され、タンデム PCIe をサポートする完全に配線されたデザインが作成されます。

8. PROM またはフラッシュを設定します。

PROM またはフラッシュデバイスのビットストリームを生成するため、適切な設定を行います。詳細は、85 ページの「デバイスのプログラム」を参照してください。

9. ビットストリームを生成します。

合成およびインプリメンテーション完了後、 Flow Navigator で [Generate Bitstream] をクリックします。次の 2 つのファイルが作成されて、 runs ディレクトリに保存されます。

xilinx_pcie3_uscale_ep_tandem1.bit|xilinx_pcie3_uscale_ep_tandem2.bit

重要 : Tandem コンフィギュレーションをサポートするシリコンがリリースされるまでビットストリームの生成はできません。詳細は、ザイリンクスまでお問い合わせください。


図 3-9 : [PFO IDs] タブ





10. 第 1 段階用の PROM ファイルを生成します。

Vivado の Tcl コンソールで、次のコマンドを実行して、 VCU107 開発ボードでサポートされる 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 51950 を参照してください。

タンデム PCIe のまとめ

タンデム PCIe を使用することにより、 UltraScale アーキテクチャデザインの PCIe 部分をコンフィギュレーションするのに必要な時間を大幅に短縮でき、またビットストリームフラッシュストレージの要件も軽減できます。UltraScaleArchitecture Gen3 Integrated Block for PCIe コアがデザインの詳細の多くを管理するため、設計者はユーザーアプリケーションに集中できます。

ユーザーハードウェアデザインでのタンデムの使用

ユーザーデザインにタンデムフローを適用するには 2 つの方法があります。1 番目はコアと共に配布されるサンプルデザインを使用する方法です。 2 番目は、既存デザインに PCIe IP をインポートして、必要に応じてデザインの階層を変更する方法です。

いずれの方法でも、タンデムソリューションに必要なサンプルのクロック供給構造、タイミング制約、および物理ブロック (Pblock) 制約を得るために PCIe サンプルデザインを作成する必要があります。

方法 1 - 既存 PCI Express サンプルデザインの使用

PCI Express コアで必要な作業という観点から見ると、これがも簡単な方法ですが、すべてのユーザーにとって実現可能というわけではありません。このアプローチがデザイン構造上のニーズに見合う場合は、次の手順に従ってください。

1. サンプルデザインを作成します。

「タンデム PROM VCU107 サンプルツールフロー」および「タンデム PCIe VCU107 サンプルツールフロー」で説明されているとおりにサンプルデザインを生成します。

2. ユーザーアプリケーションを挿入します。

PIO サンプルデザインをユーザーデザインに置き換えます。I/O やグローバルクロッキングなどのグローバルおよび上位エレメントは上位デザインに挿入することを推奨します。

ボードデザインの要件に応じて、SPI または BPI フラッシュプログラミングの設定についてコメントを外す、または変更します。

3. 通常どおりにデザインをインプリメントします。


japan.xilinx.com/support/answers/51950.htm




方法 2 - PCIe デザインを新規 Vivado プロジェクトに移行

方法 1 を利用できない場合は、次の手順に従って PCIe コアおよび目的のタンデムフロー (PROM または PCIe) を新しいプロジェクトで使用します。サンプルデザインにはユーザーデザインに移行する必要のある RTL およびスクリプトが数多くあります。

1. サンプルデザインを作成します。

「タンデム PROM VCU107 サンプルツールフロー」および「タンデム PCIe VCU107 サンプルツールフロー」で説明されているとおりにサンプルデザインを生成します。

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 プロジェクトにタンデム PCIe IP を追加します。

Flow Navigator で [Add Sources] をクリックします。 [Add Source] ウィザードで [Add Existing IP] をクリックして、タンデム PCIe サンプルデザインの作成に使用した XCI ファイルを参照します。

6. サンプルデザインの XDC ファイルから適切な SPI または BPI の設定をコピーして、ユーザーデザインの XDCファイルに貼り付けます。

7. 通常どおりにデザインをインプリメントします。





Tandem コンフィギュレーションの RTL デザイン

Tandem コンフィギュレーションの場合、タンデム以外の PCI Express 製品から若干の変更が必要になります。このセクションでは、コア内に統合されている追加ロジックと、タンデム PROM ソリューションをインプリメントするために追加されるユーザーアプリケーションの役割について説明します。

クリティカル入力の多重化

コアへの入力ポートの一部は、 2 番目のコンフィギュレーションプロセス中に無効になるように、多重化されます。これらのマルチプレクサーは上位のコアファイルにあり、 mcap_design_switch 信号で制御されます。

これらの入力は、第 2 段階のビットストリームがロードされている間ディアサート状態に保たれます。これで、第 2段階のドライバーがないために発生する不要なグリッチを防ぎ、 PCIe コアは有効な状態に保たれます。mcap_design_switch がアサートされると、マルチプレクサーは切り替わり、すべてのインターフェイス信号がこの資料で説明されているように動作します。

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 段階がロードされた後にアサートされます。

• mcap_eos_out は、 STARTUP プリミティブからの EOS 信号のパススルー出力です。この出力は、第 1 段階がロードされるまでディアサート状態となり、第 1 と第 2 の間でアサートされ、第 2 段階の終わりで再びアサートされます。 FPGA DONE ピンもタンデムビットストリームをロードする際に同様の動作を示します。

• user_reset も同様に、コア自体がリセットされるときに、コアと通信する任意のロジックをリセットするために使用できます。

表 3-3 : ハンドシェイクポート

名称方向極性説明

mcap_design_switch 出力アクティブ High

第 2 段階のユーザーロジックへの切り換えが完了したことを示します。

0 : 第 2 段階のロードは完了していない

1 : 第 2 段階のロードが完了している

mcap_eos_out 出力アクティブ High STARTUP プリミティブの End of Startup (EOS) ピンからのパススルー出力です。

user_reset 出力アクティブ HighPCIe がリセットされるときに、PCIe インターフェイスロジックをリセットするために使用できます。 user_clock と同期します。

user_clk 出力 N/A PCIe インターフェイスロジックで使用されるクロックです。

user_lnk_up 出力アクティブ High PCI Express コアがホストデバイスとリンクアップしたことを示します。





• user_clk は、 PCIe IP コアで使用されるメインの内部クロックにすぎません。このクロックを使用して、コアと直接通信するユーザーロジックと同期化させます。

• user_lnk_up は、名前が示すとおり、確立されたリンク上で PCIe コアが現在動作していることを示します。

ユーザーアプリケーションハンドシェイク

タンデムソリューションが PCI Express ブロックのコア制御とユーザーアプリケーションとの間で切り換えを行うには、 FPGA 内に内部コンプリーションイベントが存在する必要があります。この切り換えメカニズムが必要な理由については、「クリティカル入力の多重化」で説明しています。タンデムソリューションは、 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 と同じ I/O バンクにある第 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 first stage 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 がトライステートになります。タンデム PCIe の場合、第 1 段階と第 2 段階の間には相当な時間が生じ、その時点でこれらのピンはコンフィギュレーションされていないため、各 I/O の内部の弱いプルダウンによって Low に接続されます。

コンフィギュレーションピンの動作

DONE ピンは標準アプローチでのコンフィギュレーションの完了を示します。このピンは Tandem コンフィギュレーションにも使用されますが、その動作は少し異なります。 DONE は、スタートアップシーケンスが実行されるとき、1 番目のコンフィギュレーションの後で High になり、2 番目のロードが始まると Low に戻ります。タンデム PROMの場合、 2 番目が同じビットファイルにあるので、この動作がすぐに開始します。タンデム PCIe の場合、第 2 段階のビットストリームが PCIe MCAP に転送されるときにこの動作が発生します。 DONE ピンは 2 番目のコンフィギュレーションの後に High になりその状態を維持します。

コンフィギュレーションパーシスト (タンデム PROM の場合のみ)

UltraScale デバイスでタンデム PROM コンフィギュレーションを使用する場合は、コンフィギュレーションパーシスト (Persist) が必要です。第 1 および第 2 段階コンフィギュレーションで使用された多目的 I/O は、第 2 段階コンフィギュレーションが完了した後ユーザー I/O として使用できません。

使用するコンフィギュレーションモードに対して 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.

タンデム PROM を使用するには、これらのサイトを使用しているユーザー I/O の位置を変更する必要があります。





PROM の選択

コンフィギュレーション PROM には、 Tandem コンフィギュレーションに対する特定要件はありませんが、 100ms 仕様を満たすには、次の 3 つの条件を満たす PROM を選択する必要があります。

1. ザイリンクスコンフィギュレーションでサポートされていること。

2. 1 番目と 2 番目の両方のコンフィギュレーションに合わせてサイズ調整されていること。つまり、ビットストリーム全体が入るだけのサイズの PROM であること。

° タンデム PROM の場合、第 1 段階と第 2 段階の両方のビットストリームがここに格納されます。このビットストリームは標準ビットストリームよりも若干サイズが大きくなります (4 ～ 5% 大きい)。

° タンデム PCIe の場合、ビットストリームのサイズは約 1MB ですが、デザインのインプリメンテーション結果、デバイス選択、および圧縮効果によって多少変わります。

3. 第 1 段階のビットストリームサイズおよびビットストリームのロード時間の予測に基づき、 PCI Express のコンフィギュレーション時間要件を満たすこと。「Tandem コンフィギュレーションのビットストリームロード時間の計算」を参照。

サポートされている PROM およびデバイスビットストリームサイズのリストは、『UltraScale アーキテクチャコンフィギュレーションガイド』 (UG570) を参照してください。

デバイスのプログラム

タンデムビットストリームを PROM にプログラムするにあたり、標準ビットストリームをプログラムする場合と比較して特に注意事項はありません。タンデムビットストリームは、 JTAG、スレーブ/マスター SelectMAP、 SPI、 BPI など、すべての標準プログラミング方法でプログラムできます。いずれのプログラミング方法を使用した場合でも、第1 段階のビットストリームがロードされて動作が開始した後に DONE ピンがアサートされます。

SPI または BPI のフラッシュプログラミングの準備を整えるには、ビットストリーム生成の前に適切な設定を有効にしておく必要があります。これは、次に示すようにデザインの XDC ファイルに特定フラッシュデバイスの設定を追加することで完了します。例は、PCI Express サンプルデザインを使用して生成した制約ファイルの中にあります。使用しているボードおよびフラッシュプログラミング要件を満たすよう、既存のオプション (コメントされている ) をコピーします。

タンデム 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 は、コンフィギュレーションクロックの耐性が低いため、高速なコンフィギュレーションレートを提供することを目的に使用できます。 Design Suite で EMCCLK を使用する場合の詳細は、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) を参照してください。

Vivado Design Suite でのコンフィギュレーションの詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) を参照してください。

既知の制限事項

ビットストリームの暗号化は、Tandem コンフィギュレーションでサポートされていません。第 1 段階がコンフィギュレーションされてデバイスがアクティブになると、第 2 段階のビットストリーム (暗号されている /暗号化されていない) を転送するには内部のコンフィギュレーションポート (ICAP または MCAP) しか使用できません。このため、タンデム PROM は、暗号化されたビットストリームをサポートできません。タンデム PCIe に関しては、今後のリリースで検討されています。





タンデム 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 カスケード接続はサポートされていません。

PCIe リセットピンの移動

一般的に、第 1 段階のビットストリームのサイズを適化 ( 小化) するためには、専用のリセット配線と専用の PCIeリセットパッケージピン (PERSTN0) を使用する必要があります。これらの選択は、適用可能な場合にはデフォルトで有効になっています。この専用リセットを使用できないシステムデザインの場合、 Vivado IDE で専用 PERST 配線リソースの使用を無効にする必要があります。リセットピン用に新しいロケーションを選択する場合は、第 1 段階でコンフィギュレーションされる I/O のロケーションを考慮する必要があります。コアから物理的に離れた場所に I/Oが配置されていると、第 1 段階に余分なコンフィギュレーションフレームが含められてしまいます。これは、第 1 段階にこれらの I/O を含めるには、多くの配線リソースが必要になるためです。

非プロジェクトフロー

非プロジェクト環境では、プロジェクト環境と同じ基本アプローチが取られます。まず、「タンデム PCIe VCU107 サンプルツールフロー」に示すように 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>

注記 : コンテキスト外の合成を実行する場合は、制約ファイルを使用して、インプリメンテーション中にのみ使用される Pblock 制約を適用する必要があるかもしれません。インプリメンテーション中にのみ適用されます。これは、一部の制約は、結合されているデザイン全体に依存して制約を適用するためです。

5. Persist ピンを設定するためのコンフィギュレーションモードの確認など、デザインに対するすべてのカスタマイズは、デザインの XDC ファイル内で行われていることを確認します。





6. デザインをインプリメントします。

opt_designplace_designroute_design

7. ビットファイルを生成します。タンデム PCIe には -bin_file オプションを使用してください。 BIN ファイルは 32 ビットの境界に揃い、 PCIe を使用する第 2 段階ビットストリームのソフトウェアロードを促進します。

write_bitstream -bin_file <file>.bit

タンデム IP コアのシミュレーション

タンデム PROM または Tandm PCIe コアの機能は STARTUP モジュールに依存しているため、シミュレーション中にこの点を考慮する必要があります。

PCI Express コアは、第 2 段階のビットストリームがデバイスにいつロードされたかを認識するため、 EOS 出力信号のアサートに STARTUP ブロックを利用します。PCIe コアを第 2 段階のロジックと機能させるためにリリースするのに、この STARTUP ブロックをシミュレーションする必要があります。これを実行するには、階層参照を使用し、STARTUP ブロックに EOS 信号を強制します。次のコード例はその方法を示したものです。

// 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>

// De-assert 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>

// Re-assert 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 段階のロード時間 = (PROM 帯域幅) / (第 1 段階のビットストリームサイズ)





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 段階のビットストリームのサイズを小限に抑えることがタンデムコンフィギュレーションの終目的であるため、ビットストリーム圧縮は非常に有効です。このオプションでは、マルチフレーム書き込みテクニックを利用してビットストリームのサイズを縮小するため、その結果コンフィギュレーション時間を短縮できます。圧縮量は各デザインで異なります。タンデムが選択されている場合、 IP レベルの制約で圧縮機能が有効になります。これは、必要に応じてユーザーデザイン制約に上書きできます。次のコマンドを使用して、ビットストリーム圧縮を有効化/無効化できます。

set_property BITSTREAM.GENERAL.COMPRESS <TRUE|FALSE> [current_design]

ビットストリームのロード時間に関するその他の注意事項

ビットストリームコンフィギュレーション時間は、次の要素によっても影響を受けます。

• 電源の立ち上がり時間 (レギュレータによる遅延など)

• TPOR (パワーオンリセット )

電源の立ち上がり時間はデザインによって異なります。立ち上がり時間の長いデザインや遅延の多いデザインは避けてください。 FPGA コンフィギュレーションを開始するために必要な FPGA 電源については、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) を参照してください。

通常、 FPGA の電源はシステム電源と同時またはその少し前に立ち上がります。このような場合、システム電源が安定するまで 100ms はカウントされないため、タイミングマージンを得ることができます。しかしこれもまたデザインによって異なります。 FPGA 電源とシステム電源との関係を理解するには、システムを特性評価する必要があります。

TPOR は、標準電源立ち上がりレートの場合は 57ms、 UltraScale デバイスの高速立ち上がりレートの場合は 20ms です。詳細は、『Kintex UltraScale アーキテクチャデータシート : DC 特性および AC スイッチ特性』 (DS892) および『VirtexUltraScale アーキテクチャデータシート : DC 特性および AC スイッチ特性』 (DS893) を参照してください。

「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 クワッドの選択によって、第 1 段階ビットストリームのサイズが変わります。も効率的にリソースを使用するには、 PCI Express ハードブロックに隣接する GT クワッドを使用します。

• 圧縮 : デバイス使用率が高くなると、圧縮の効果は低くなります。

ベースラインとして、 PCIe IP と共に生成されるサンプル (PIO) デザインのビットストリームサイズおよびコンフィギュレーション時間の例をいくつか示します。

タンデム PCIe 手法を使用して第 2 段階のビットストリームをロードするのにかかる時間は、次の 3 つの追加要因によって異なります。

• PCI Express リンクの幅と速度

• MCAP をプログラムするのに使用されたクロック周波数

• ルートポートホストがエンドポイント FPGA デザインへビットストリームを供給できる効率性。ほとんどのデザインでは、これらが制限要因となります。

これら 3 つの要因のも低い帯域幅によって、第 2 段階のビットストリームがロードされる速度が決定します。

表 3-4 : ビットストリームサイズおよびコンフィギュレーション時間の例(1)

デバイス変数フルビットストリーム

フル : BPI16 (50MHz)

タンデム第 1 段階(2)

タンデム : BPI16(50MHz)

KU040Tandem PROM 122.1Mb 152.7ms 7.6Mb 9.5ms

Tandem PCIe 122.1Mb 152.7ms 7.6Mb 9.5ms

KU060Tandem PROM 184.1Mb 230.1ms 7.6Mb 9.5ms


VU095Tandem PROM 273.5Mb 341.8ms 8.8Mb 10.9ms


注記 :

1. ここに示すコンフィギュレーション時間には TPOR は含まれていません。

2. PIO デザインは非常に小さいため、ビットストリームサイズを小さくするのに圧縮は非常に効果的です。これらの数値は、フ

ルデザインを使用した場合により正確な見積もりができるように、圧縮なしで得たものです。これらの値は、 Vivado DesignSuite 2014.4 で PCIe Gen3x8 コンフィギュレーションを使用して生成されました。





クロッキングコアには、 100MHz の基準クロック入力が必要です。詳細は、ザイリンクス 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 カタログで有効にする必要があります。基準クロックの追加情報は、 98 ページの「クロッキング要件」を参照してください。

各リンクパートナーデバイスは同じクロックソースを共有します。図 3-10 および図 3-11 は、100MHz の基準クロックを使用するシステムを示しています。

デバイスがエンベデッドシステムの一部であったとしても、システムがコマーシャル版の PCI Express ルートコンプレックスまたはスイッチを一般的なマザーボードクロック供給で使用する場合は、同期クロック供給をやはり使用する必要があります。

注記 : 図 3-10 および図 3-11 では、ボードレイアウトを示しています。ボードレイアウト時には、カップリング、終端などが適切に使用されていることを確認してください。


図 3-10 : 100MHz の基準クロックを使用したエンベデッドシステム


http://japan.xilinx.com/support/answers/34536.htm




リセットこのコアは、 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 が開始されると、エラーロギングやエラー通知なしでリクエストおよびコンプリーションが破棄されます。


図 3-11 : 100MHz の基準クロックを使用したオープンシステムアドインカード





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-12 に、コアのクライアント側のインターフェイスを示します。





このインターフェイスは、 PCIe リンクとユーザーアプリケーション間でのデータ転送を可能にする 4 つの個別のインターフェイスとして構成されています。

• PCIe のコンプリーターリクエスト (CQ) インターフェイスを介して、リンクからのリクエストがユーザーアプリケーションに送信されます。


図 3-12 : UltraScale FPGA Gen3 Integrated Block のクライアントインターフェイスのブロック図





• 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 インターフェイスはすべて、いかなる場合においても同じ幅に設定されます。

さらに、統合ブロックには 2 つのインターフェイスが含まれ、これらのインターフェイスを介してステータス情報がユーザーアプリケーションの PCIe のマスター側に通知されます。

• フロー制御ステータスインターフェイスを介して現在利用可能な送信クレジットに関する情報を提供します。これにより、ユーザーアプリケーションは利用可能なクレジットに基づいてリクエストをスケジューリングできます。

• タグ可用性ステータスインターフェイスを介してノンポステッドリクエストへの割り当てに利用可能なタグの数に関する情報を提供します。これにより、 PCIe コントローラー内で使用されているすべてのタグによってブロックされる危険を伴うことなく、ユーザーアプリケーションはリクエストをスケジューリングできます。

後に、統合ブロックにはリンクからメッセージを受信したことをユーザーロジックに示す受信メッセージインターフェイスも含まれ、 CQ インターフェイスを介してメッセージ全体が転送されることはありません。

表 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 インターフェイスそれぞれに対してアライメントモードを個別に選択できます。この選択には、対応するアライメントモードパラメーターを設定しますが、リクエスターコンプリーション (RC) インターフェイスはアドレスアライメントモードに設定され得るという制約が伴います。アドレスアライメントの詳細と図の例は、 98 ページの「インターフェイスの動作」を参照してください。

リクエスターコンプリーションインターフェイスのストラドルオプション

リクエスターコンプリーション (RC) インターフェイスが 256 ビット幅に設定されると、インターフェイスのビートごとに開始できるまたは終了できる TLP の数が大で 1 つの場合、インターフェイスの使用が著しく非効率になるこ

Gen3 (8.0GT/s)

X1 64 ビット 125 または 250

x264 ビット 250

128 ビット 125

x4128 ビット 250

256 ビット 125

x8 256 ビット 250

表 3-5 : クライアントインターフェイス向けのデータ幅とクロック周波数の設定 (続き)

PCI Express 世代/最大リンクスピード可能な最大リンク幅

AXI4-Stream インターフェイス幅

ユーザークロック周波数 (MHz)





とがあります。ただし、これは TLP のタイプとペイロードのサイズによって異なります。レシーバークレジットが無制限であることが示されると (Infinite Receiver Credit)、 RC インターフェイスの非効率な使用が原因でコンプリーション FIFO のオーバーフローが発生する可能性があります。次に示すいずれかの措置を行う必要があります。

• 受信した合計コンプリーションを 64 未満に抑え、指定した FIFO サイズ内に抑えるために、未処理のノンポステッドリクエストの数を制限します。

• RC インターフェイスストラドルオプションを使用します。このオプションを使用した場合の波形を図 3-66 に示しています。

ストラドルオプションは、 256 ビット幅の RC インターフェイスでのみ利用可能で、Vivado IP カタログで有効にします。 IP カタログでこのオプションを有効にする手順は、第 4 章「デザインフローの手順」を参照してください。このオプションが有効の場合、以前の TLP が終了した時点のバイトレーン 16 または同じビートのバイトレーン 15 で統合ブロックは新しいコンプリーション TLP を開始できます。したがって、このオプションが有効の場合、統合ブロックは RC インターフェイス上の同じビートで 2 つのコンプリーション TLP を送信できます。ただし、いずれも 2Dword 以上のペイロードがないことが条件です。

ストラドルオプションは、インターフェイス幅が 256 ビットに設定されており、RC インターフェイスが Dword アライメントモードに設定されている場合のみ利用可能です。

表 3-6 に、インターフェイス幅、アドレッシングモードおよびストラドルオプションの有効な組み合わせを示します。

受信トランザクションの順序

TLP がリンクから受信され、コンプリーターリクエストインターフェイスを介して送信されるよう、またリクエスターコンプリーションインターフェイスが PCI Express トランザクション順序の制約を違反しないように、コアの受信側にはロジックが含まれています。統合ブロックによる順序付けは、次の重要な規則に基づいています。

• ポステッドリクエストはコンプリーターリクエスト (CQ) インターフェイスでノンポステッドリクエストを追い越すことが求められます。この機能を有効にするために、統合ブロックはフロー制御メカニズムを CQ インターフェイスにインプリメントします。このインターフェイスを介して、ユーザーロジックはポステッドリクエストに影響を及ぼすことなくノンポステッドリクエストのフローを制御できます。ユーザーロジックは、pcie_cq_np_req 信号をアサートしてノンポステッドリクエストを受信するためのバッファーの利用可否を伝えます。

利用可能なクレジットが 0 ではない場合にのみ、統合ブロックはノンポステッドリクエストをユーザーアプリケーションに送信します。クレジット数が不足しているためノンポステッドリクエストの送信が中断されている間、統合ブロックはポステッドリクエストを送信し続けます。ノンポステッドリクエストの送信に対してクレジットメカニズムによってバックプレッシャーが適用されない場合、統合ブロックはリンクから受信した同じ順序でポステッドリクエストおよびノンポステッドリクエストを送信します。ノンポステッドリクエストのフロー制御については、 117 ページの「ノンポステッドリクエストの選択的フロー制御」を参照してください。

表 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 アライメント、ストラドル有効

( リクエスターコンプリーションインターフェイスでのみ可)






• PCIe の順序付けでは、次のケースを除き、コンプリーション TLP はポステッドリクエストを越えて送信できないことが要件となっています。

° 緩和型順序付け (Relaxed Ordering) 属性ビットセットを使用するコンプリーション TLP は、ポステッドリクエストを追い越すことができる。

° コンプリーター ID がポステッドリクエスター ID と異なる場合、 ID ベースの順序付けビットセットを使用するコンプリーション TLP はポステッドリクエストを追い越すことができる。

上記の 2 つのルールのうち 1 つが適用されない限り、前に到着したすべてのポステッド TLP の転送が完全に完了するまで、統合ブロックはリクエスターコンプリーション (RC) インターフェイスでリンクから受信したコンプリーション TLP の転送を開始しません。

TLP が完全にクライアント側に転送されたら、ユーザーアプリケーションは順序の制約を必要に応じて強化する必要があります。

送信トランザクションの順序

送信側では、統合ブロックはリクエスターリクエスト (RQ) インターフェイスとコンプリーターコンプリーション(CC) インターフェイスで TLP を受信します。統合ブロックは、これらの各インターフェイスから受信したトランザクションの順序を変更しません。リクエスター側のリクエストとコンプリーター側のコンプリーションが 1 つのトラフィックストリームに多重化された後、統合ブロックの転送パイプラインでこれらがどのように順序付けされるのか予測するのは難しくなります。コンプリーション TLP がリクエストに対して順序付けを維持しなければならない場合、ユーザーロジックは、 CC インターフェイスから送信されるコンプリーションに対して厳密な順序付けを維持する必要があるリクエストに 4 ビットのシーケンス番号を提供できます。これには、 s_axis_rq_tuser バス内のseq_num[3:0] 入力を使用します。ユーザーアプリケーションからの新しいコンプリーション TLP がリクエスト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-XTLP 間で順序付けを維持することが求められます。この場合、 MSI メッセージインターフェイスで MSI またはMSI-X を提示する前に、ユーザーロジックは pcie_rq_seq_num[3:0] 出力にリクエスターリクエストのシーケンス番号が現れるのを待機する必要があります。

クロッキング要件コアのクライアントインターフェイス信号はすべてユーザークロック (user_clk) と同期が取られ、設定されたリンクスピードとリンク幅に応じて 62.5、 125、または 250MHz の周波数になります (表 3-5 を参照)。

インターフェイスの動作ここでは、コアインターフェイスのクライアント側における動作について説明します。





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

このインターフェイスは、 AXI4-Stream プロトコルに基づいて、 PCIe リンクから受信したトランザクション (メモリ、I/O の読み出し /書き込み、メッセージ、アトミック操作) をコンプリーターリクエスト (CQ) インターフェイスのトランザクションにマップします。コンプリーターインターフェイスは、各方向のデータ転送にそれぞれが用いられる 2つの個別のインターフェイスで構成されます。各インターフェイスは AXI4-Stream プロトコルに基づき、 64、 128、または 256 ビット幅に設定できます。 CQ インターフェイスは、 (関連するペイロードデータを含む) リクエストをユーザーアプリケーションに転送するために用いられ、コンプリーターコンプリーション (CC) インターフェイスはコンプリーションデータ (ノンポステッドリクエスト向け) をユーザーアプリケーションに送信してからリンクに転送するために用いられます。これら 2 つのインターフェイスは独立して動作します。つまり、統合ブロックは、前回のリクエストのコンプリーションを受信すると同時に CQ インターフェイスを介して新しいリクエストを転送できます。

コンプリーターリクエストディスクリプターのフォーマット

統合ブロックは、 CQ インターフェイスを介してリンクから受信した各リクエスト TLP を独立した AXI4-Stream パケットとして転送します。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 16 バイト長となり、リクエストパケットの初の 16 バイトで送信されます。ディスクリプターは、64 ビットインターフェイスでは初の 2 サイクル間で送信され、128 ビットまたは 256 ビットの場合は初のサイクルで送信されます。

図 3-13、図 3-14、図 3-15、および図 3-16 に、ディスクリプターのフォーマットをリクエストタイプ別に示しています。図 3-13 に示すフォーマットは、転送されているリクエスト TLP がメモリ読み出し /書き込みリクエスト、 I/O 読み出し /書き込みリクエスト、またはアトミック操作リクエストのときに適用されます。図 3-14 に示すフォーマットは、ベンダー定義メッセージ (タイプ 0 またはタイプ 1) 専用です。図 3-15 に示すフォーマットは、すべての ATS メッセージ (Invalid Request、 Invalid Completion、Page Request、PRG Response) に使用されます。その他のメッセージのディクスリプターについては、図 3-16 に示すフォーマットとなります。


図 3-13 : メモリリクエスト、 I/O リクエスト、アトミック操作リクエストのコンプリーターリクエストディスクリプターフォーマット






図 3-14 : ベンダー定義メッセージのコンプリーターリクエストディスクリプターフォーマット


図 3-15 : ATS メッセージのコンプリーターリクエストディスクリプターフォーマット





表 3-7 に、コンプリーターリクエストディスクリプターの個別フィールドを示します。


図 3-16 : その他メッセージのコンプリーターリクエストディスクリプターフォーマット

表 3-7 : コンプリーターリクエストディスクリプターのフィールド

ビットインデックスフィールド名説明

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-8 に示します。





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

114:112 BAR ID

このフィールドは、メモリ、 I/O、およびアトミック操作の各リクエスト専用に定義されます。リクエスト内のアドレス向けに一致した BAR 番号を提供します。

• 000 : BAR 0 (VF の場合 VF-BAR 0)• 001 : BAR 1 (VF の場合 VF-BAR 1)• 010 : BAR 2 (VF の場合 VF-BAR 2)• 011 : BAR 3 (VF の場合 VF-BAR 3)• 100 : BAR 4 (VF の場合 VF-BAR 4)• 101 : BAR 5 (VF の場合 VF-BAR 5)• 110 : 拡張 ROM アクセス

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 が使用するメモリ空間に基づきます。

表 3-7 : コンプリーターリクエストディスクリプターのフィールド (続き)






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 BaseSpecification、rev. 3.0』 [参照 2] の「Appendix F」を参照してください。

114:112Message Routing

(メッセージルーティング)

このフィールドはすべてのメッセージ用に定義されます。これらのビットは、 TLP ヘッダーからの 3 ビットの配線フィールド r[2:0] を提供します。

15:0Destination ID

(デスティネーション ID)

このフィールドはベンダー定義メッセージにのみ適用されます。メッセージが ID によって配線される場合 (つまり、メッセージ配線フィールドが 010 バイナリ )、このフィールドはメッセージのデスティネーション ID を提供します。

63:32

Vendor-Defined Header

(ベンダー定義のヘッダー )

このフィールドはベンダー定義メッセージにのみ適用されます。TLP ヘッダーの Dword 3 から抽出されたバイトが含まれます。

63:0ATS Header

(ATS ヘッダー )このフィールドは ATS メッセージにのみ適用可能です。 TLP ヘッダーの Dword 2 と Dwod 3 から抽出されたバイトが含まれます。

表 3-7 : コンプリーターリクエストディスクリプターのフィールド (続き)






表 3-8 : トランザクションタイプ

リクエストタイプ (バイナリ ) 説明

0000 メモリ読み出しリクエスト

0001 メモリ書き込みリクエスト

0010 I/O 読み出しリクエスト

0011 I/O 書き込みリクエスト

0100 メモリのフェッチおよび追加リクエスト

0101 メモリの無条件スワップリクエスト

0110 メモリの比較およびスワップリクエスト

0111 読み出しリクエストのロック (レガシデバイスでのみ可能)

1000 タイプ 0 のコンフィギュレーション読み出しリクエスト ( リクエスター側のみ)

1001 タイプ 1 のコンフィギュレーション読み出しリクエスト ( リクエスター側のみ)

1010 タイプ 0 のコンフィギュレーション書き込みリクエスト ( リクエスター側のみ)

1011 タイプ 1 のコンフィギュレーション書き込みリクエスト ( リクエスター側のみ)

1100 ATS およびベンダー定義メッセージを除くすべてのメッセージ

1101 ベンダー定義メッセージ

1110 ATS メッセージ

1111 予約済み





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

図 3-17 に、コアのコンプリーターリクエストインターフェイスに関連する信号を示します。コアは、このインターフェイスを介して各 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-17 : コンプリーターリクエストインターフェイスの信号





コンプリーターを介すメモリ書き込み動作

図 3-18、図 3-19、および図 3-20 のタイミング図は、コンプリーターリクエスト (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 ビットも含まれます。これらのビットはパケットの初のビートで有効になり、ペイロードの初と後の Dwords の有効バイトを指定します。

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 ステアリングタグおよびステアリングタグタイプ) に関連するパラメーターを転送します。






図 3-18 : コンプリーターリクエストインターフェイスでのメモリ書き込みトランザクション (Dword アライメントモード、インターフェイス幅 = 64 ビット )





図 3-21、図 3-22、および図 3-23 のタイミング図は、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-21 : コンプリーターリクエストインターフェイスでのメモリ書き込みトランザクション (アドレスアライメントモード、インターフェイス幅 = 64 ビット )





コンプリーターメモリ読み出し

AXI4-Stream パケットに 16 バイトディスクリプターしか含まれない場合を除いて、メモリ読み出しリクエストはメモリ書き込みリクエストと同様にコンプリーターリクエストインターフェイス全体で転送されます。図 3-24、図 3-25、および図 3-26 のタイミング図は、コンプリーターリクエスト (CQ) インターフェイスを介してリンクから受信したメモリ読み出し TLP の転送を 64、128、および 256 ビット別に示しています。パケットは、64 ビットインターフェイスについては連続する 2 ビートを使用して転送されますが、 128 ビットまたは 256 ビットインターフェイスについては 1 ビートで転送されます。m_axis_cq_tvalid 信号は、パケットが送信される間アサートされたままになります。m_axis_cq_treadyをディアサートしてビートを随時延ばすことができます。 m_axis_cq_tuser バスの sop 信号は、初のディスクリプターバイトがバスに存在する場合アサートされます。


図 3-24 : コンプリーターリクエストインターフェイスでのメモリ読み出しトランザクション (インターフェイス幅 = 64 ビット )





初の Dword と後の Dword の読み出しリクエストに関連するバイトイネーブルビットは、m_axis_cq_tuser サイドバンドバスの統合ブロックで提供されます。初のディスクリプターバイトが転送中で、このバイトを使用してバイトレベルの開始アドレスとリクエストに関連するバイトカウントを決定しなければならないとき、これらのビットが有効です。 1 Dword や 2 Dword の読み出しといった特殊なケースでは、バイトイネーブルは非連続にできます。それ以外では、バイトイネーブルは連続しています。 Dword カウントフィールドが 1 にセットされ、初のバイトイネーブルと後のバイトイネーブルが 0 にセットされた状態で、長さ 0 のメモリ読み出しが CQ インターフェイスで送信されます。

ユーザーアプリケーションは、コンプリーションを用いて各メモリ読み出しリクエストに応答する必要があります。読み出しによって要求されたデータは、1 つのコンプリーションまたは複数のスプリットコンプリーションとして送信できます。これらのコンプリーションは統合ブロックのコンプリーターコンプリーション (CC) インターフェイスを介して送信する必要があります。 2 つの異なるリクエストに対応するコンプリーションは順序を問わず送信できますが、同じリクエストに対応するスプリットコンプリーションについては順序を追って送信する必要があります。CCインターフェイスの動作は、 118 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。







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 (サポートされないリクエスト ) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 118 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

I/O 読み出し

CQ インターフェイスにおける I/O 読み出しリクエストの転送はメモリ読み出しリクエストと同様で、そこにはディスクリプターしか含まれません。要求されたデータの長さは常に 1 Dword となり、m_axis_cq_tuser 内の First ByteEnable ビットは読み出し対象の有効バイトを示します。

ユーザーロジックは、 1 Dword のコンプリーション (またはエラーの場合はデータを含まないコンプリーション) で I/O 読み出しリクエストに応答する必要があります。2 つの異なる I/O 読み出しリクエストに対応するコンプリーションは順序を問わず送信できます。 I/O 読み出しトランザクションに関連するエラーが発生した場合、コンプリーションディスクリプターにあるコンプリーションステータスフィールドに CA (コンプリーターの中断) または UR (サポートされないリクエスト ) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 118 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

コンプリーターリクエストインターフェイスでのアトミック操作

コンプリーターリクエストインターフェイスにおけるアトミック操作リクエストの転送は、メモリ書き込みリクエストと同様です。アトミック操作のペイロードの範囲は、 1 Dword から 8 Dword までで、開始アドレスは必ず Dword境界に揃えられます。転送は 128 ビットディスクリプターから始まり、その後ペイロードが続きます。Dword アライメントモードを使用する場合、ディスクリプターの直後に初の Dword ペイロードが続きます。アドレスアライメントモードを使用する場合、ディスクリプターの後にペイロードが新しいビートで開始し、そのアライメントはディスクリプターのアドレスに基づきます。 m_axis_cq_tkeep 出力は、ペイロードの終わりを示します。また、m_axis_cq_tuser 内の byte_en 信号は、ペイロード内の有効バイトを示します。 m_axis_cq_tuser 内の FirstByte Enable と Last Byte Enable ビットはアトミック操作に使用できません。

アトミック操作はノンポステッドトランザクションであるため、ユーザーロジックはこれに対して操作結果を含むコンプリーションを用いて応答する必要があります。操作に関連するエラーが発生した場合、コンプリーションディスクリプターにあるコンプリーションステータスフィールドにコンプリーターの中断 (CA) またはサポートされないリクエスト (UR) を適宜設定してリクエスターにこのエラーを通知することができます。コンプリーターコンプリーションインターフェイスの動作は、 118 ページの「コンプリーターコンプリーションインターフェイスの動作」を参照してください。

コンプリーターリクエストインターフェイスでのメッセージリクエスト

ペイロードが常に存在するわけではないことを除いて、 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 にセットされます。

• 統合ブロックのリセットが解除されたら、クロックサイクルごとにカウンターは次のような動作となります。

° pcie_cq_np_req が High で、ノンポステッドリクエストがこのサイクルで送信されない場合、クレジットカウントが 32 の飽和限界に達していなければ、 1 つずつインクリメントされます。

° pcie_cq_np_req が Low で、ノンポステッドリクエストがこのサイクルで送信される場合、クレジットカウントがまだ 0 になっていなければ、 1 つずつデクリメントされます。

° 上記に該当しない場合、クレジットカウントの値は変わりません。

• クレジットカウントが 1 以上の場合、統合ブロックはノンポステッド TLP の送信を開始します。

ユーザーアプリケーションは、ノンポステッドリクエストを受信できる状態になるたびに pcie_cq_np_req に 1 サイクルのパルスを提供するか、ノンポステッドリクエストに対する選択的なバックプレッシャーを実行する必要がない場合は永久的にアサートされた状態に維持します。クレジットカウントが常に 0 以外の場合、統合ブロックはリンクから受信した同じ順序でポステッドリクエストおよびノンポステッドリクエストを送信します。カウントが一定時間 0 の状態が続くと、ノンポステッドリクエストは統合ブロック FIFO に保管できます。その後、クレジットカウントが 0 以外になると、統合ブロックは既に送信されたポステッドリクエストよりも前に到達して保管していたノンポステッドリクエストを先に送信し、その後リンクから受信した順にリクエストを送信します。

pcie_cq_np_req 信号のアサートおよびディアサートは、コンプリーターリクエストインターフェイス上のパケット送信と揃う必要はありません。

出力 (pcie_cq_np_req_count[5:0]) で現在のクレジットカウント値をモニタリングできます。カウンターは 32が大です。内部パイプラインの遅延が原因となり、コアが pcie_cq_np_req 入力でのパルスを受信してから pcie_cq_np_req_count 出力をアップデートするまでの間には数サイクルの遅延が生じます。このため、ユーザーアプリケーションにある程度のバッファー空間がある場合は、あらかじめクレジットを提供しておくと、クレジット不足でコアがノンポステッドリクエストをホールドすることがなくなります。





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

図 3-27 に、コアのコンプリーターコンプリーションインターフェイスに関連する信号を示します。コアは、このインターフェイスを介して各 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-28 を参照してください。コンプリーターリクエストディスクリプターの各フィールドの詳細は、表 3-9 で説明しています。


図 3-27 : コンプリーターコンプリーションインターフェイスの信号






図 3-28 : コンプリーターコンプリーションディスクリプターのフォーマット

表 3-9 : コンプリーターコンプリーションディスクリプターのフィールド


フィールド名説明

6:0Lower Address

(下位アドレス)

メモリ読み出しのコンプリーションの場合、このフィールドは、送信されるメモリブロックのバイトレベルの開始アドレスの下位 7 ビットに設定される必要があります。その他のコンプリーションの場合、この下位アドレスはすべて 0 にセットされる必要があります。

9:8Address Type


このフィールドは、メモリトランザクションおよびアトミック操作のコンプリーション用に定義されます。これらのコンプリーションの場合、対応するリクエストのディスクリプターの AT ビットをユーザーがこのフィールドへコピーする必要があります。その他のコンプリーションの場合、このフィールドは 0 にセットされる必要があります。

28:16Byte Count

(バイトカウント )

これらの 13 ビットには、 0 ～ 4096 バイトの範囲の値が含まれます。シングルコンプリーションを使用すしてメモリ読み出しリクエストが完了する場合、このバイトカウント値がペイロードサイズをバイト単位で示します。I/O の読み出しコンプリーションや I/O の書き込みコンプリーションの場合、このフィールドは 4 にセットされる必要があります。長さ 0 のメモリ読み出しに対するコンプリーションを送信している間、バイトカウント値は 1 にセットされる必要があり、ダミーのペイロードとして 1 Dword がディスクリプターの後に送信される必要があります。各メモリ読み出しコンプリーションでは、このバイトカウントフィールドがリクエストを完了するのに必要となる残りのバイト数を示します (コンプリーションで返ってきたバイト数を含む)。複数のコンプリーションを使用してメモリ読み出しリクエストが完了する場合、各コンプリーションのこのバイトカウント値は、先行するコンプリーションが示す値から先行するコンプリーションで返ってきたバイト数を引いた値となります。メモリ読み出しリクエストを完了するのに必要な合計バイト数の計算式は、121 ページの表 3-10 を参照してください。

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 タグです ( リクエストからコピー )。

79:72

Target Function/Device Number

(ターゲットファンクション/デバイス番号)

コンプリーターファンクションのファンクション番号です。ユーザーアプリケーションは、常にファンクション番号を提供する必要があります。 ARI が使用される場合は、このフィールドの全 8 ビットにターゲットファンクション番号を設定する必要があります。その他の場合は、ビット [74:72] をターゲットファンクション番号に設定する必要があります。ユーザーアプリケーションは、対応するリクエストのディスクリプターの Target Function フィールドからこの値をコピーする必要があります。その他の場合は、ビット [74:72] をターゲットファンクション番号に設定する必要があります。

ARI が使用されていない場合で、統合ブロックがルートコンプレックスとしてコンフィギュレーションされている場合は、ユーザーアプリケーションがコンプリーターの 5 ビットのデバイス番号をビット [79:75] に提供する必要があります。

ARI が使用されていない場合で、統合ブロックがエンドポイントとしてコンフィギュレーションされている場合は、ユーザーアプリケーションがオプションでコンプリーターの 5 ビットのデバイス番号をビット [79:75] に提供することが可能です。デバイス番号がビット [79:75] に提供される場合は、ユーザーアプリケーションがディスクリプターの Completer ID Enable ビットをセットする必要があります。この値は、コンプリーション TLP を送信する際に統合ブロックで使用されます (提供されない場合は、統合ブロックがコンフィギュレーションリクエストから取得して格納したデバイス番号値を使用)。

表 3-9 : コンプリーターコンプリーションディスクリプターのフィールド (続き)







87:80

Completer Bus Number

(コンプリーターバス番号)

コンプリーターファンクションに関連するバス番号です。統合ブロックがルートコンプレックスとしてコンフィギュレーションされている場合、ユーザーアプリケーションがこのフィールドにコンプリーターの 8 ビットのバス番号を提供する必要があります。

統合ブロックがエンドポイントとしてコンフィギュレーションされている場合、ユーザーアプリケーションはオプションとしてこのフィールドにバス番号を提供できます。バス番号がこのフィールドに提供される場合は、ユーザーアプリケーションがディスクリプターの Completer ID Enable ビットをセットする必要があります。この値は、コンプリーション TLP を送信する際に統合ブロックで使用されます (提供されない場合は、統合ブロックがコンフィギュレーションリクエストから取得して格納したバス番号値を使用)。

88Completer ID

Enable

このフィールドは、Completer ID フィールドの構成に使用されるバス番号やデバイス番号をユーザーアプリケーションが提供することを可能にします。このフィールドは、エンドポイントコンフィギュレーションにのみ適用可能です。

このフィールドが 0 の場合、統合ブロックはキャプチャしたバス番号やデバイス番号を使用してコンプリーター ID を構成します。このフィールドが 1 の場合、統合ブロックはディスクリプターに提供されたバス番号やデバイス番号を使用してコンプリーター ID を構成します。

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-10 : first_be[3:0]、 last_be[3:0]、および Dword Count[10:0] からのバイトカウント計算

first_be[3:0] last_be[3:0] 合計バイトカウント

1xx1 0000 4

01x1 0000 3

1x10 0000 3

0011 0000 2

0110 0000 2

1100 0000 2

0001 0000 1

0010 0000 1

0100 0000 1

1000 0000 1

0000 0000 1

xxx1 1xxx Dword_count*4

xxx1 01xx (Dword_count*4)-1

xxx1 001x (Dword_count*4)-2

表 3-9 : コンプリーターコンプリーションディスクリプターのフィールド (続き)







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-29、図 3-30、および図 3-31 のタイミング図は、CC インターフェイスを介すユーザーアプリケーションからの Dword アライメント転送を、インターフェイス幅 64、 128、および 256 ビット別に示しています。この場合、ペイロードの初の Dword がディスクリプターの直後で開始しています。データブロックが 4 バイトの倍数でない場合、またはペイロードの開始が Dword の境界に揃っていない場合は、ペイロードの開始が Dwordの境界に揃うように、またペイロードが Dword の倍数値となるように、ユーザーアプリケーションは NULL を追加する必要があります。たとえば、データブロックがバイトアドレス 7 から開始し、サイズが 3 バイトの場合は、初のバイトの前に NULL バイトを 3 つ追加し、2 Dword の長さにするためにブロックの終わりに NULL バイトを 2 つ追加する必要があります。また、不連続な読み出しの場合は、データブロック内のすべてのバイトが有効として返されるとは限りません。このような場合は、必要に応じて有効バイトの間にある隙間に NULL バイトを追加して、正しい位置にある有効なバイトを返す必要があります。インターフェイスには、ペイロード内の有効なバイトを示す信号がありません。これは、リクエスターがリクエスト内のバイトイネーブルを追跡してコンプリーションから無効なバイトを破棄する役割を果たすため、必要ありません。

Dword アライメントモードでは、転送は 12 ディスクリプターバイトから始まり、その直後にペイロードバイトが続きます。ユーザーアプリケーションは、パケットが送信される間、s_axis_cc_tvalid 信号をアサートしたままに保持する必要があります。パケット送信中に s_axis_cc_tvalid がディアサートされると、統合ブロックはこれをエラーとして処理し、リンク上の対応するコンプリーション TLP を無効にしてデータ破損を回避します。

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-10 : first_be[3:0]、 last_be[3:0]、および Dword Count[10:0] からのバイトカウント計算 (続き)

first_be[3:0] last_be[3:0] 合計バイトカウント





またユーザーアプリケーションは、パケットの後のビートで s_axis_cc_tlast をアサートします。統合ブロックは、データの受信準備が整っていない場合に、任意のサイクルで s_axis_cc_tready をディアサートできます。統合ブロックが s_axis_cc_tready をディアサートしたクロックサイクル内では、ユーザーアプリケーションはCC インターフェイス上の値を変更できません。


図 3-29 : コンプリーターコンプリーションインターフェイスでの一般的なコンプリーションの転送 (Dword アライメントモード、インターフェイス幅 = 64 ビット )







アドレスアライメントモードでは、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。メモリ読み出しのコンプリーションの場合、ペイロードの初の有効バイトのアドレスに基づいて、ペイロードの初のバイトはどのバイトレーンにも出力できます。その他すべてのコンプリーションの場合、ペイロードはバイトレーン 0 で開始する必要があります。

図 3-32、図 3-33、および図 3-34 のタイミング図は、コンプリーターコンプリーションインターフェイスを介すメモリ読み出しコンプリーションのアドレスアライメント転送を 64、 128、および 256 ビット別に示しています。図示することを目的として、送信されるデータブロックの開始 Dword アドレス (ディスクリプターの下位アドレスフィールドのビット [6:2] で伝搬) は (m * 8 +1 ) と仮定されています (整数 m)。データブロックのサイズは、 n Dword と仮定され、 n = k * 32 + 28 (k > 0) となります。








図 3-32 : コンプリーターコンプリーションインターフェイスでの一般的なコンプリーションの転送 (アドレスアライメントモード、インターフェイス幅 = 64 ビット )







コンプリーションの転送中断

ユーザーアプリケーションは、 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) 機能を使用して訂正不可能な内部エラーとして、接続される先のルートコンプレックスに対して統合ブロックがエラーをレポートします。







Error ステータス (UA および CA) のコンプリーション

コンプリーターリクエストインターフェイスで受信したリクエストに対して UR (サポートされないリクエスト ) または CA (コンプリーション中断) で応答する場合、ユーザーアプリケーションは、図 3-28 に示すフォーマットで 3Dword のコンプリーションディスクリプターを送信し、その後にコンプリーションを生成したリクエストの情報を含む 5 Dword を送信する必要があります。これらの 5 Dword は、統合ブロックが AER ヘッダーログレジスタにリクエストに関する情報を記録するのに不可欠です。

図 3-35 に、 UR または CA ステータスのコンプリーションを送信する際に転送される情報のシーケンスを示します。この情報は、合計 8 Dword の AXI4-Stream パケットとしてフォーマットされ、次のように組織化されます。

• 初の 3 Dword には、図 3-28 の形式のコンプリーションディスクリプターが含まれます。

• 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-35 : UR/CA コンプリーションの AXI4-Stream パケットの構成





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

ユーザーアプリケーションは、コアが提供する独立した受信メッセージインターフェイスを使用して、リンクから受信したメッセージ情報を受け取ることができます。受信メッセージインターフェイスが有効に設定されている場合、統合ブロックは、メッセージタイプ (表 3-11) を示す cfg_msg_received_type[4:0] 出力を設定してcfg_msg_received 信号を 1 サイクルまたは複数サイクル間パルスし、リンクからメッセージが到達したことを伝達します。 cfg_msg_received のアサートサイクル数は、受信するメッセージタイプによって異なります (表 3-12 を参照)。 cfg_msg_received が High のとき、統合パラメーターは、 cfg_msg_received_data バス上にメッセージに関する任意のパラメーターを 1 回につき 8 ビットで転送します。表 3-12 では、cfg_msg_received がアサートされる各サイクルで、このバスに転送されるパラメーターをメッセージタイプ別に示しています。ベンダーが指定するメッセージの場合、統合ブロックはこのインターフェイスを介して関連するペイロードの初の Dword のみ転送します。さらに大規模なペイロードが使用される場合は、メッセージの転送にコンプリーターリクエストインターフェイスを使用する必要があります。

表 3-11 : 受信メッセージインターフェイスのメッセージタイプエンコード

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-12 : 受信メッセージインターフェイスのメッセージパラメーター

メッセージタイプcfg_msg_received のアサートサイクル数

cfg_msg_received_data[7:0] で転送されるパラメーター

ERR_COR、ERR_NONFATAL、

ERR_FATAL2

サイクル 1 : リクエスター ID、バス番号

サイクル 2 : リクエスター ID、デバイス /ファンクション番号

Assert_INTx、 Deassert_INTx 2 サイクル 1 : リクエスター ID、バス番号


PM_PME、 PME_TO_Ack、PME_Turn_off、

PM_Active_State_Nak2



Set_Slot_Power_Limit 6



サイクル 3 : ペイロードのビット [7:0]サイクル 4 : ペイロードのビット [15:8]サイクル 5 : ペイロードのビット [23:16]サイクル 6 : ペイロードのビット [31:24]

LTR (Latency Tolerance Reporting)

6



サイクル 3 : スヌープレイテンシのビット [7:0]サイクル 4 : スヌープレイテンシのビット [15:8]サイクル 5 : ノースヌープレイテンシのビット [7:0]サイクル 6 : ノースヌープレイテンシのビット [15:8]

OBFF (Optimized Buffer Flush/Fill)

3サイクル 1 : リクエスター ID、バス番号


サイクル 3 : OBFF コード

アンロック 2 サイクル 1 : リクエスター ID、バス番号


Vendor_Defined タイプ 0

データがない場合は 4 サイクル、

データがある場合は 8 サイクル



サイクル 3 : ベンダー ID[7:0] サイクル 4 : ベンダー ID[15:8] サイクル 5 : ペイロードのビット [7:0]サイクル 6 : ペイロードのビット [15:8]サイクル 7 : ペイロードのビット [23:16]サイクル 8 : ペイロードのビット [31:24]

Vendor_Defined タイプ 1

データがない場合は 4 サイクル、

データがある場合は 8 サイクル



サイクル 3 : ベンダー ID[7:0] サイクル 4 : ベンダー ID[15:8] サイクル 5 : ペイロードのビット [7:0]サイクル 6 : ペイロードのビット [15:8]サイクル 7 : ペイロードのビット [23:16]サイクル 8 : ペイロードのビット [31:24]

ATS 無効なリクエスト 2 サイクル 1 : リクエスター ID、バス番号


ATS 無効なコンプリーション

2 サイクル 1 : リクエスター ID、バス番号






図 3-36 に、受信メッセージインターフェイスでの Set_Slot_Power_Limit メッセージ例を示すタイミング図を示します。このメッセージには、関連する 1 Dword ペイロードが含まれています。このメッセージでは、連続する 6 サイクル間でパラメーターが送信されます。各サイクルで cfg_msg_received_data バスに次の情報が現れます。

• サイクル 1 : リクエスター ID のバス番号

• サイクル 2 : リクエスター ID のデバイス番号/ファンクション番号

• サイクル 3 : ペイロード Dword のビット [7:0]




統合ブロックは、 cfg_msg_received 出力の有効なパルス間に 1 サイクル以上のギャップを挿入します。受信メッセージインターフェイスを介して送信されるメッセージ表示にはバックプレッシャーを適用するメカニズムがありません。このインターフェイスを使用する場合、ユーザーロジックは常にメッセージ表示を受信する準備が整っている必要があります。

受信メッセージインターフェイスのデザイン要件

Endoint としてコンフィギュレーションされている場合、ユーザーアプリケーションは次の要件を満たす必要があります。

1. ユーザーアプリケーションは、RO ビットがセットされたコンプリーションをもたらすノンポステッドリクエストを発行する必要があります。

2. ユーザーアプリケーションは、設定したコンプリーション空間を超えてはいけません。

この要件を満たすことで、 RX コンプリーションバッファーのオーバーフローを回避できます。

ATS ページリクエスト 2 サイクル 1 : リクエスター ID、バス番号


ATS PRG 応答 2 サイクル 1 : リクエスター ID、バス番号



図 3-36 : [Receive Message Interface]

表 3-12 : 受信メッセージインターフェイスのメッセージパラメーター (続き)

メッセージタイプcfg_msg_received のアサートサイクル数

cfg_msg_received_data[7:0] で転送されるパラメーター





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

リクエスターインターフェイスは、ユーザーエンドポイントアプリケーションがバスマスターとして PCIe リンクからホストメモリへの PCI トランザクションを開始できるようにします。ルートコンプレックスの場合も、このインターフェイスを使用して I/O およびコンフィギュレーションリクエストを開始します。このインターフェイスは、PCIe リンク上でメッセージを送信するために、エンドポイントとルートコンプレックスの両方で使用できます。このインターフェイスでのトランザクションは、 Completer インターフェイスでのトランザクションと同じですが、コアとユーザーアプリケーションの役割が逆になります。ポステッドトランザクションは、分割できない単一動作として処理されますが、ノンポステッドトランザクションはスプリットトランザクションとして処理されます。

リクエスターインターフェイスは、各方向のデータ転送にそれぞれが用いられる 2 つの個別のインターフェイスで構成されます。各インターフェイスは AXI4-Stream プロトコルに基づき、 64、 128、または 256 ビット幅に設定できます。リクエスターリクエスト (RQ) インターフェイスはユーザーアプリケーションから統合ブロックへリクエスト (関連するペイロードデータを含む) を転送するために使用され、リクエスターコンプリーション (RC) インターフェイスは、統合ブロックがリンクから受信したコンプリーション (ノンポステッドリクエスト ) をユーザーアプリケーションへ送信するために使用されます。これら 2 つのインターフェイスは独立して動作します。つまり、統合ブロックが前回のリクエストのコンプリーションを受信する間に、ユーザーアプリケーションが RQ インターフェイスを介して新しいリクエストを転送できます。





リクエスターリクエストインターフェイスの動作

RQ インターフェイスでは、ユーザーアプリケーションが各 TLP を AXI4-Stream パケットとして送信します。このパケットは 128 ビットディスクリプターから始まり、 TLP にペイロードが含まれる場合はその後をデータが続きます。図 3-37 に、リクエスターリクエストインターフェイスで使用される信号を示します。


図 3-37 : リクエスターリクエストインターフェイス





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] のビットをセットする必要があります。

統合ブロックで 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-38 ～図 3-42 に、ディスクリプターのフォーマットをリクエストタイプ別に示しています。図 3-38 に示すフォーマットは、転送されているリクエスト TLP がメモリ読み出し /書き込みリクエスト、 I/O 読み出し /書き込みリクエスト、またはアトミック操作リクエストのときに適用されます。図 3-39 に示すフォーマットは、コンフィギュレーションリクエストに使用されます。図 3-40 に示すフォーマットは、ベンダー定義メッセージ (タイプ 0 またはタイプ 1)専用です。図 3-41 に示すフォーマットは、すべての ATS メッセージ (無効なリクエスト、無効なコンプリーション、ページリクエスト、 PRG 応答) に使用されます。その他のメッセージのディクスリプタについては、図 3-42 に示すフォーマットとなります。






図 3-38 : メモリリクエスト、 I/O リクエスト、アトミック操作リクエストのリクエスターリクエストディスクリプターフォーマット


図 3-39 : コンフィギュレーションリクエストのリクエスターリクエストディスクリプターフォーマット






図 3-40 : ベンダー定義メッセージのリクエスターリクエストディスクリプターフォーマット


図 3-41 : ATS メッセージのリクエスターリクエストディスクリプターフォーマット





表 3-13 に、コンプリーターリクエストディスクリプターの個別フィールドを示します。


図 3-42 : その他メッセージのリクエスターリクエストディスクリプターフォーマット

表 3-13 : リクエスターリクエストディスクリプターのフィールド


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-8 に示します。





79Poisoned Request

(ポイズンリクエスト )

このビットは、送信されるリクエスト TLP にポイズニングを適用する場合に使用できます。この機能は、タイプ 0 およびタイプ 1 のコンフィギュレーション書き込みリクエスト以外のすべてのリクエストでサポートされています。ユーザーアプリケーションがディスクリプターの後に続くデータブロック内にエラーを検出し、 PCI Express のデータポイズニング機能を使用してこのエラー情報を伝える場合以外は、このビットはすべてのリクエストで 0 にセットする必要があります。

この機能は、タイプ 0 およびタイプ 1 のコンフィギュレーション書き込みリクエスト以外のすべてのリクエストでサポートされています。

87:80

Requester Function/Device Number ( リクエスター

ファンクション番号/デバイス番号)

リクエスターファンクションに関連するバス番号です。統合ブロックがエンドポイントとしてコンフィギュレーションされている場合、ユーザーアプリケーションはディスクリプター内のRequester ID Enable ビットを 0b に設定して、このフィールドに 8’b0を提供する必要があります。この場合、統合ブロックが ConfigurationRequest からキャプチャした Bus Number に格納されている値が使用されます。

それ以外では、統合ブロックがルートコンプレックスとしてコンフィギュレーションされている場合、ユーザーアプリケーションがこのフィールドにリクエスターの 8 ビットのバス番号を提供する必要があります。

95:88Requester Bus Number

( リクエスターバス番号)

リクエスターファンクションに関連するバス番号です。統合ブロックがエンドポイントとしてコンフィギュレーションされている場合、ユーザーアプリケーションはディスクリプター内のRequester ID Enable ビットを 0b に設定して、このフィールドに 8’b0を提供する必要があります。この場合、統合ブロックが ConfigurationRequest からキャプチャした Bus Number に格納されている値が使用されます。

それ以外では、統合ブロックがルートコンプレックスとしてコンフィギュレーションされている場合、ユーザーアプリケーションがこのフィールドにリクエスターの 8 ビットのバス番号を提供する必要があります。

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 ビットのファンクション番号として扱われます。

表 3-13 : リクエスターリクエストディスクリプターのフィールド (続き)






120Requester ID Enable ( リクエスター ID

イネーブル)

このフィールドは、 Requester ID フィールドの構成に使用されるバス番号、デバイス番号、およびファンクション番号をユーザーアプリケーションが提供することを可能にします。このフィールドは、統合ブロックがルートコンプレックスとしてコンフィギュレーションされている場合には 1b に設定され、エンドポイントとしてコンフィギュレーションされている場合には 0b に設定されている必要があります。詳細要件は、Requester Bus Number ( リクエスターバス番号) および Requester Function/Device Number ( リクエスターファンクション番号/デバイス番号) フィールドを参照してください。

123:121 Transaction Class (TC) リクエストに関連する PCIe トランザクションクラス (TC) です。

126:124 Attributes (属性)

これらのビットは、リクエストに関連する Attribute ビットの設定を提供します。ビット 124 は No Snoop ビットで、ビット 125 はRelaxed Ordering ビットです。ビット 126 は ID-Based Ordering ビットで、メモリリクエストとメッセージ専用にセットできます。ファンクションの PCI Express Device Control Register で対応する属性が有効に設定されていない場合、統合ブロックはリンク上に送信されるリクエストの属性ビットを強制的に 0 にします。

127 Force ECRC

強制的に ECRC を挿入します。このビットを 1 にセットすると、リクエストを送信するファンクションで ECRC 機能が有効に設定されていない場合でも、統合ブロックがリクエスト TLP に ECRC を含む TLP Digest を追加します。

15:0Snoop Latency

(スヌープレイテンシ)

このフィールドは LTR メッセージ専用に定義されます。メッセージの TLP ヘッダーにある 16 ビットのスヌープレイテンシフィールドの値を提供します。

31:16No-Snoop Latency (ノースヌープレイテンシ)

このフィールドは LTR メッセージ専用に定義されます。メッセージの TLP ヘッダーにある 16 ビットのノースヌープフィールドの値を提供します。

35:32 OBFF コード

OBFF コードフィールドは、さまざまな OBFF ケースを識別するために使用されます。

• 1111b : CPU アクティブ – バスマスタリングや割り込みなど、すべてのデバイスアクションに対してシステムが完全にアクティブである

• 0001b : OBFF – デバイスメモリの読み出し /書き込みバスマスターの動作で利用可能なシステムメモリパス

• 0000b : アイドル – システムがアイドル状態で、低電力ステート

その他すべてのコードは予約されています。

111:104 メッセージコード

このフィールドはすべてのメッセージ用に定義されます。TLP ヘッダーに設定される 8 ビットのメッセージコードが含まれます。

サポート対象のメッセージコードの一覧は、『PCI Express BaseSpecification、rev. 3.0』 [参照 2] の「Appendix F」を参照してください。

114:112Message Routing

(メッセージルーティング)

このフィールドはすべてのメッセージ用に定義されます。統合ブロックは、これらのビットをリクエスト TLP の TLP ヘッダーにある 3 ビットの Routing フィールド r[2:0] へコピーします。

15:0Destination ID

(デスティネーション ID)

このフィールドはベンダー定義メッセージにのみ適用されます。メッセージが ID を使用して送信される場合 (つまり、 MessageRouting フィールドが 010 バイナリの場合)、このフィールドはメッセージの Destination ID を提供します。







リクエスターメモリ書き込み動作

Dword アライメントモードでは、転送は 16 ディスクリプターバイトから始まり、その直後にペイロードバイトが続きます。ユーザーアプリケーションは、パケットが送信される間、 s_axis_rq_tvalid 信号をアサートしたままに保持する必要があります。パケット送信中に s_axis_rq_tvalid がディアサートされると、統合ブロックはこれをエラーとして処理し、リンク上の対応するリクエスト TLP を無効にしてデータ破損を回避します。

またユーザーアプリケーションは、パケットの後のビートで s_axis_rq_tlast をアサートします。統合ブロックは、データの受信準備が整っていない場合に、任意のサイクルで s_axis_rq_tready をディアサートできます。統合ブロックが s_axis_rq_tready をディアサートしたクロックサイクル内では、ユーザーアプリケーションがRQ インターフェイス上の値を変更してはいけません。 AXI4-Stream インターフェイス信号 m_axis_cq_tkeep (各Dword 位置に 1 つ) をセットして、ディクスリプタなどのパケット内の有効な Dword およびディスクリプターとペイロード間に挿入される NULL バイトを示す必要があります。つまり、ディスクリプターの初の Dword からペイロードの後の Dword まで、tkeep ビットは継続的に 1 にセットされる必要があります。パケットの転送中、インターフェイスの幅全体がパケットで埋められないときは、パケットの後のビートに限り tkeep ビットを 0 にできます。

リクエスターリクエストインターフェイスでは、 s_axis_rq_tuser バスに First Byte Enable ビットと Last Enableビットも含まれます。これらのビットはパケットの初のビートでセットされ、ペイロードの初と後の Dword にある有効なバイト情報を提供します。

ユーザーアプリケーションは、 1 つのリクエストで転送されるペイロードのサイズを、統合ブロックで設定した大ペイロードサイズまでに制限し、ペイロードが 4k バイトの境界を超えないようにする必要があります。 2 Dword またはそれ以下のメモリ書き込みの場合、 first_be および last_be で 1 が連続しない場合があります。長さ 0 のメモリ書き込みリクエストなど特殊な場合は、 first_be と last_be が両方ともすべて 0 にセットされた状態でユーザーアプリケーションがダミーの 1 Dword ペイロードを提供する必要があります。その他の場合、 first_be および last_be における 1 は連続する必要があります。

図 3-43、図 3-44、および図 3-45 のタイミング図は、リクエスターリクエストインターフェイスを介すユーザーアプリケーションからのメモリ書き込みリクエストの Dword アライメント転送を、インターフェイス幅 64、 128、および256 ビット別に示しています。説明用として、ユーザーアプリケーションメモリに書き込まれるデータブロックのサイズは n Dword と仮定し、 n = k * 32 + 29 (k > 0) となります。

63:32Vendor-Defined Header

(ベンダー定義のヘッダー )

このフィールドはベンダー定義メッセージにのみ適用されます。TLP ヘッダーの Dword 3 へコピーされます。

63:0ATS Header

(ATS ヘッダー )

このフィールドは ATS メッセージにのみ適用可能です。統合ブロックが TLP ヘッダーの Dword 2 と Dwod 3 へコピーするバイトが含まれます。








図 3-43 : リクエスターリクエストインターフェイスでのメモリ書き込みトランザクション (Dword アライメントモード、インターフェイス幅 = 64 ビット )







図 3-46、図 3-47、および図 3-48 のタイミング図は、 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] のビットをセットする必要があります。








図 3-46 : リクエスターリクエストインターフェイスでのメモリ書き込みトランザクション (アドレスアライメントモード、インターフェイス幅 = 64 ビット )







ペイロードを含まないノンポステッドトランザクション

ペイロードを含まないノンポステッドトランザクション (メモリ書き込みリクエスト、 I/O 読み出しリクエスト、コンフィギュレーション読み出しリクエスト ) は、メモリ書き込みリクエストと同様に RQ インターフェイスを介して送信されますが、このトランザクションでは AXI4-Stream パケット 7 に 16 バイトのディスクリプターのみ含まれます。図 3-49、図 3-50、および図 3-51 のタイミング図は、 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 と last_beが両方ともすべて 0 にセットされた状態で、リクエストの長さは 1 Dword に設定される必要があります。さらに、アドレスアライメントモードの場合は、s_axis_rq_tuser の addr_offset[2:0] がリクエスターコンプリーションインターフェイス上に返されるデータの任意の開始アライメントを指定します。アライメントは、リクエストのアドレスと相関性を持つ必要はありません。








図 3-49 : リクエスターリクエストインターフェイスでのメモリ読み出しトランザクション (インターフェイス幅 = 64 ビット )





ペイロードを含むノンポステッドトランザクション

ペイロードを含むノンポステッドリクエスト (I/O 書き込みリクエスト、コンフィギュレーション書き込みリクエスト、またはアトミック操作リクエスト ) の転送は、メモリリクエストの転送と類似していますが、ペイロードがデータパス上で揃えう方法において次の点が異なります。

• Dword アライメントモードの場合、ペイロードの初の Dword はディスクリプターの後の Dword の後に転送され、この 2 つの Dword 間にギャップは生じません。

• アドレスアライメントモードの場合、ペイロードの送信は必ず、ディスクリプターの後のバイトの後に続いて発生するビートで開始します。ペイロードはデータパス上の任意の Dword 位置で開始できます。初の Dwordのオフセットは、 addr_offset[2:0] 信号を使用して指定される必要があります。

I/O およびコンフィギュレーション書き込みリクエストの場合、 1 Dword ペイロードの有効バイトは、first_be[3:0] 信号を使用して指定されます。アトミック操作リクエストの場合、初と後の Dword のすべてのバイトを有効と見なします。







リクエスターインターフェイスでのメッセージリクエスト

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_cc_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 (内部タグ管理) : AXISTEN_IF_ENABLE_CLIENT_TAG パラメーターを FALSE に設定すると、この動作モードが選択され、これはコアのデフォルト設定となります。リクエスター側から開始された各ノンポステッドリクエストに対して、統合ブロック内のロジックがタグの割り当てを実行します。統合ブロックは、フリータグのリストを管理し、ユーザーアプリケーションがノンポステッドトランザクションを開始する際に各リクエストにこれらのいずれかを割り当て、その後 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-52 に、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-53 および図 3-54 は、同じ例のクレジットとタグのタイミングを、インターフェイス幅 128 ビットおよび 64 ビット別に示しています。






図 3-52 : リクエスターリクエストインターフェイスでの利用可能なクレジット数およびタグ数を示す信号 (インターフェイス幅 = 256 ビット )







トランザクション順序の維持

統合ブロックは、リクエスターインターフェイスでユーザーアプリケーションから受信したリクエストをリンクに送信する際に順序を変更しません。ユーザーアプリケーションが 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] に現れた後に統合ブロックから送信されたコンプリーションは、内部送信パイプライン内のポステッドリクエストを飛び越えることができません。







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

ユーザーロジックで生成されたリクエストに対するコンプリーションは、統合ブロックのリクエスターコンプリーション (RC) インターフェイスに現れます。図 3-55 に、リクエストコンプリーションインターフェイスに現れる信号を示しています。ストラドルが無効に設定されている場合、統合ブロックはこのインターフェイスを使用して各TLP を AXI4-Stream パケットとして送信します。パケットは 96 ビットディスクリプターから始まり、コンプリーションにペイロードが含まれる場合はその後をデータが続きます。

RC インターフェイスでは、ペイロードの転送において 2 つのデータアライメントモードをサポートします。 Dwordアライメントモードの場合、統合ブロックはディスクリプターの後の Dword の直後にコンプリーションペイロードの初の Dword を送信する必要があります。アドレスアライメントモードの場合、統合ブロックはディスクリプターの後の Dword に続いて発生するビートでペイロードの送信を開始し、その初の Dword はデータパス上の任意の Dword 位置で開始できます。ペイロードの初の Dword のアライメントは、ユーザーアプリケーションが統合ブロックにリクエストを送信したときに提供されるアドレスオフセット (つまり、 RQ インターフェイスのaddr_offset[2:0] 入力の設定) で決定します。したがって、アドレスアライメントモードは、 RQ インターフェイスで使用できるように設定されている場合のみ、 RC インターフェイスで使用できます。


図 3-55 : リクエスターコンプリーションインターフェイス





リクエスターコンプリーションのディスクリプターのフォーマット

統合ブロックの RC インターフェイスは、リンクから受信したコンプリーションデータをユーザーアプリケーションへ AXI4-Stream パケットとして送信します。各パケットはディスクリプターから始まり、ディスクリプターの後にペイロードデータが続きます。ディスクリプターは必ず 12 バイト長となり、コンプリーションパケットの初の 12バイトで送信されます。ディスクリプターは、 64 ビットインターフェイスでは初の 2 サイクル間で送信され、 128ビットまたは 256 ビットの場合は初のサイクルで送信されます。コンプリーションデータが複数のスプリットコンプリーションに分割される場合は、統合ブロックが各スプリットコンプリーションを個別にディスクリプターを備えた AXI4-Stream パケットとして送信します。

リクエスターコンプリーションディスクリプターのフォーマットは、図 3-56 を参照してください。 RC ディスクリプターの各フィールドの詳細は、表 3-14 で説明しています。


図 3-56 : リクエスターコンプリーションのディスクリプターのフォーマット

表 3-14 : リクエスターコンプリーションディスクリプターのフィールド



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 ～ 4096 バイトの範囲の値が含まれます。シングルコンプリーションを使用してメモリ読み出しリクエストが完了する場合、このバイトカウント値がペイロードサイズをバイト単位で示します。 I/O の読み出しコンプリーションや I/O の書き込みコンプリーションの場合、このフィールドは 4 にセットされる必要があります。長さ 0 のメモリ読み出しに対するコンプリーションを送信している間、バイトカウント値は 1 にセットされる必要があり、ダミーのペイロードとして 1 Dword がディスクリプターの後に送信される必要があります。各メモリ読み出しコンプリーションでは、このバイトカウントフィールドがリクエストを完了するのに必要となる残りのバイト数を示します (コンプリーションで返ってきたバイト数を含む)。複数のコンプリーションを使用してメモリ読み出しリクエストが完了する場合、各コンプリーションのこのバイトカウント値は、先行するコンプリーションが示す値から先行するコンプリーションで返ってきたバイト数を引いた値となります。

29

Locked Read Completion

(ロックされた読み出し

コンプリーション)

Locked Read (ロックされた読み出し ) リクエストに対してコンプリーション応答する場合、このビットを 1 にセットします。その他のコンプリーション応答の場合、このフィールドは 0 にセットする必要があります。

表 3-14 : リクエスターコンプリーションディスクリプターのフィールド (続き)







データを含まないコンプリーションの転送

図 3-57、図 3-58、および図 3-59 のタイミング図は、 RC インターフェイスを介して、リンクから受信したペイロードを含まないコンプリーション TLP の転送を 64、 128、および 256 ビット別に示しています。このセクションのタイミング図では、 256 ビットインターフェイスでコンプリーションがストラドルされないことを仮定しています。ストラドル機能の詳細は、 163 ページの「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-14 : リクエスターコンプリーションディスクリプターのフィールド (続き)








図 3-57 : リクエスターコンプリーションインターフェイスでのデータを含まないコンプリーションの転送 (インターフェイス幅 = 64 ビット )







コンプリーション 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_cq_tlast信号は必ずパケットの後のビートでアサートされます。

m_axi_cq_tuser バスには is_sof_0 信号も含まれており、すべてのパケットの初のビートでアサートされます。ユーザーアプリケーションは、オプションでこの信号を使用して、インターフェイス上のディスクリプターの開始を示すことができます。ストラドルオプションを使用しない場合、 m_axi_cq_tuser バス内のその他の信号は、データを含まないコンプリーションの転送に関連しません。

データを含むコンプリーションの転送

図 3-60、図 3-61、および図 3-62 のタイミング図は、 RC インターフェイスを介して、リンクから受信したペイロードを含むコンプリーション TLP の Dword アライメント転送を 64、 128、および 256 ビット別に示しています。説明用として、ユーザーアプリケーションメモリに書き込まれるデータブロックのサイズは n Dword と仮定し、 n =k * 32 + 28 (k > 0) となります。このセクションのタイミング図では、 256 ビットインターフェイスでコンプリーションがストラドルされないことを仮定しています。ストラドル機能の詳細は、 163 ページの「256 ビットインターフェイスのストラドルオプション」を参照してください。







Dword アライメントモードでは、転送は 3 ディスクリプター Dword から始まり、その直後にペイロード Dword が続きます。ディスクリプターとペイロードを含むすべての TLP は、 1 つの AXI4-Stream パケットとして転送されます。ペイロードの長さが 2 Dword を超える場合、ペイロード内のデータは常に連続するバイトストリームとなります。ペイロードの初の Dword 内の初の有効バイトと後の Dword 内の後の有効バイトの位置は、リクエスターコンプリーションディスクリプターの Lower Address フィールドと Byte Count フィールドから判断できます。ペイロードサイズが 2 Dword 以下の場合、ペイロード内の有効なバイトは連続しません。このような場合、ユーザーアプリケーションは RQ インターフェイスを介して送信される各リクエストに関連する First Byte Enable フィールドと Last ByteEnable フィールドを格納し、これらを使用してコンプリーションペイロード内の有効バイトを判断する必要があります。連続および非連続のペイロードの場合に、ユーザーアプリケーションはオプションで m_axi_cq_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 にセットされて統合ブロックが 1Dword のペイロードを転送するときの、長さ 0 のメモリ読み出しが挙げられます。つまり、あらゆるケースでユーザーロジックは byte_en 信号を直接使用することで、関連するバイトをメモリへに書き込むことができます。

64 ビット /128 ビットインターフェイスおよびストラドルオプションが無効になっている 256 ビットインターフェイスでは、 m_axis_rc_tuser バス内の is_sof_1、 is_eof_0[3:0]、および is_eof_1[3:0] 信号は使用されません。


図 3-60 : リクエスターコンプリーションインターフェイスでのデータを含むコンプリーションの転送 (Dword アライメントモード、インターフェイス幅 = 64 ビット )





図 3-63、図 3-64、および図 3-65 のタイミング図は、 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] を使用してペイロード内の有効バイトを判断できます。


図 3-63 : リクエスターコンプリーションインターフェイスでのデータを含むコンプリーションの転送 (アドレスアライメントモード、インターフェイス幅 = 64 ビット )





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-66 に、ストラドルオプションが有効に設定された 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 ですべての転送が完了しています。





コンプリーションの転送中断

関連するペイロードを含むリクエストの場合、転送されたペイロードにエラーがあると、統合ブロックはm_axis_rc_tuser バスの Discontinue 信号をパケットの後のビートでアサートしてこのエラーを通知できます。これは、内部メモリからデータを読み出す間に統合ブロックが訂正不可能なエラーを検出したときに発生します。パケットの後のビートで Discontinue 信号がアサートされたことを検出した場合、ユーザーアプリケーションはパケット全体を破棄する必要があります。これは、統合ブロックでは致命的エラーと認識されます。


図 3-66 : ストラドルオプションが有効に設定されたリクエスターコンプリーションインターフェイスでのコンプリーション TLP の転送





ストラドルオプションが使用されている場合、統合ブロックは Discontinue 信号をアサートしたビートで 2 番目のコンプリーション TLP を開始せず、そのビートで終了するコンプリーション TLP の転送を中断します。

コンプリーションエラーの対応

統合ブロックは、リンクからコンプリーション TLP を受信すると、対応するリクエストを判断するためにスプリットコンプリーションテーブル内の未処理リクエストと一致させ、それらのヘッダー内のフィールドと予想値を照らし合わせてあらゆるエラーを検出します。その後、統合ブロックはコンプリーションディスクリプターの一部としてユーザーアプリケーションへ送信する 4 ビットのエラーコードでエラー状況を通知します。また、統合ブロックは、ディスクリプターの Request Completed ビット (ビット 30) をセットして、特定リクエストの後のコンプリーションを示します。表 3-15 は、さまざまなエラーコードが示すエラー状況について説明しています。

表 3-15 : エラーコードのエンコード

エラーコード説明

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 ビットがセットされたコンプリーションディスクリプターを受信すると、ユーザーアプリケーションは対応するリクエストのすべてのステートを削除できます。

0101

開始アドレスのエラーを示します。コンプリーション TLP ヘッダーの下位アドレスが、そのリクエストの次に予想されるバイトの開始アドレスと一致しませんでした。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。さらに、ディスクリプターの Request Completed ビットがセットされていない場合は、 Request Completed ビットがセットされたコンプリーションディスクリプターを受信するまで、このタグの後続コンプリーションに対応するデータを破棄し続ける必要があります。Request Completed ビットがセットされたコンプリーションディスクリプターを受信すると、ユーザーアプリケーションは対応するリクエストのすべてのステートを破棄できます。

0110タグが無効であることを示します。このエラーコードは、コンプリーション TLP のタグが未処理リクエストのタグと一致していないことを示します。ユーザーアプリケーションは、ディスクリプターに続くすべてのデータを破棄する必要があります。





タグが統合ブロックの内部で管理される場合、統合ブロック内のロジックによって、そのリクエストのすべてのコンプリーションが受信されるまで、あるいはリクエストがタイムアウトするまで、ペンディングリクエストに割り当てられたタグが再び使用されることはありません。

ただし、タグがユーザーアプリケーションで管理される場合は、ユーザーアプリケーションがコンプリーションディスクリプターの Request Completed ビットをセットして、統合ブロックがリクエストの終了を示すまで、そのリクエストに割り当てられたタグが再び使用されないようにする必要があります。ユーザーアプリケーションは、 0 以外のエラーコードを含むコンプリーションを受信した場合にペンディングリクエストを終了できますが、コンプリーションディスクリプターの Request Completed ビットがセットされていない限り、関連するタグをリリースできません。あるリクエストが複数のスプリットコンプリーションを受信し、それらのいずれかにエラーが検出された場合にこのような状況が適用されます。この場合、統合ブロックは、エラーが検出された後であってもペンディングリクエストに対するコンプリーション 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-15 : エラーコードのエンコード (続き)

エラーコード説明





パワーマネージメントコアは、次のパワーマネージメントモードをサポートします。

• 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 をサポートしています。 L0 と 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 をリンクパートナーに対して送受信して、リンクを低電力 PPML1 ステートへ遷移させます。これはユーザーロジックにはトランスペアレントです。

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-16 を参照)、ユーザーロジックからcfg_power_state_change_ack の応答を待機します。

3. ハンドシェイクが成功すると、パワーマネージメントをオフにする承認メッセージ (PME-turnoff_ack) がコアからアップストリームリンクパートナーへ送信されます。

4. コアはインターフェイスをすべて閉じ、物理層/データリンク層/ トランザクション層を無効にして、コアに対するパワーオフの準備を整えます。

この場合、例外が 2 つあります。

° コアがエンドポイントとしてコンフィギュレーションされていて、ユーザーコンフィギュレーション空間がイネーブルになっている場合。このとき、 cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエスト TLP を送信できませんが、ユーザーコンフィギュレーション空間をターゲットにしたコンフィギュレーショントランザクションに対してはコンプリーションを返すことができます。

° コアがルートポートルートポートとしてコンフィギュレーションされている場合。この状況で準拠を保つには、 cfg_function_power_state が D0 以外の場合、ユーザーアプリケーションは新しいリクエストを送信すべきではありません。

表 3-16 : パワーマネージメントのハンドシェイク信号

ポート名方向説明

cfg_power_state_change_interrupt 出力アップストリームデバイスからパワーダウンリクエスト TLP を受信した場合にアサートされます。その後、ユーザーアプリケーションが cfg_power_state_change_ack をアサートするまで、cfg_power_state_change_interrupt はアサート状態を保持する必要があります。

cfg_power_state_change_ack 入力安全にパワーダウンできる場合に、ユーザーアプリケーションによってアサートされます。





パワーダウン交渉は、次の手順で行われます。

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 を送信します。

割り込みリクエストの生成47 ページの表 2-20 に示す cfg_interrupt_msi* および cfg_interrupt_msix_* の説明を参照してください。

注記 : このセクションは Gen3 Integrated Block for PCIe コアのエンドポイントコンフィギュレーションのみを対象にしています。

統合ブロックは、割り込みリクエストをレガシ、メッセージ MSI、または MSI-X 割り込みとして送信できます。動作モードは、 MSI Capability Structure (MSI 機能構造体) にあるメッセージ制御レジスタの MSI Enable ビットおよびMSI-X Capability Structure (MSI-X 機能構造体) にある MSI-X メッセージ制御レジスタの MSI-X Enable ビットを使用してプログラムされます。 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-17 は、コアの cfg_interrupt_msi_enable 出力およびcfg_interrupt_msix_enable 出力に基づいてプログラムされている割り込みモードについて説明しています。


図 3-67 : パワーマネージメントのハンドシェイク : 64 ビット





MSI 制御レジスタの MSI Enable ビット、 MSI-X 制御レジスタの MSI-X Enable ビット、 PCI コマンドレジスタのInterrupt Disable ビットは、ルートコンプレックスによってプログラムされます。ユーザーアプリケーションでは、これらのビットを直接制御しません。

コアの Internal Interrupt Controller は、レガシ割り込みと MSI 割り込みのみ生成します。 MSI-X 割り込みは、ユーザーアプリケーションで生成され、送信 AXI4-Stream インターフェイスに現れる必要があります。cfg_interrupt_msi_enable のステータスが Internal Interrupt Controller で生成される割り込みタイプを決定します。

MSI Enable ビットが 1 の場合は、コアがメモリ書き込み TLP を送信して MIS リクエストを生成します。 MSI Enableビットが 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-13 を参照してください。

ユーザーアプリケーションは 2 つの方法で割り込みを要求します。これらの方法は次のセクションで説明します。

レガシ割り込みモード

• ユーザーアプリケーションは、割り込み信号をアサートするために、まず cfg_interrupt_int および cfg_interrupt_pending をアサートします。

• その後、コアが cfg_interrupt_sent をアサートして、割り込みが受信されたことを示します。次のクロックでユーザーアプリケーションは cfg_interrupt_int をディアサートして、 PCI コマンドレジスタのInterrupt Disable ビットが 0 にセットされている場合にはコアがアサート割り込みメッセージ (Assert_INTA) を送信します。

• ユーザーアプリケーションが cfg_interrupt_int をディアサートした後、コアはディアサート割り込みメッセージ (Deassert_INTA) を送信します。これは、 cfg_interrupt_sent の 2 回目のアサートで示されます。

• cfg_interrupt_int は、ユーザーが ASSERT_INTA の確認信号を受信するまでに (cfg_interrupt_sent のアサーションで示される) アサートされる必要があります。 cfg_interrupt_int をディアサートすると、コアが DEASSERT_INTA を送信します。 cfg_interrupt_pending は、割り込みが対応されるまでアサートされている必要があります。途中でディアサートされると、ステータスレジスタの割り込みステータスビットが正しく更新されません。ソフトウェアがこのビットを読み出すと、「No Interrupt Pending (割り込みペンディングなし )」が出力されます。

表 3-17 : 割り込みモード

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) を送信できます (任意で選択)。





MSI モード

• 図 3-68 に示すとおり、ユーザーアプリケーションは cfg_interrupt_msi_int の値を初にアサートします。

• コアは、 cfg_interrupt_msi_sent をアサートして割り込みが受け入れられたことを示し、 MSI メモリ書き込み TLP を送信します。

MSI リクエストは、32 ビットのアドレス指定可能なメモリ書き込み TLP または 64 ビットのアドレス指定可能なメモリ書き込み TLP のいずれかです。アドレス値は、 MSI 機能構造体の Message Address フィールドと Message UpperAddress フィールドから取得し、ペイロードは Message Data フィールドから取得します。これらの値は、 MSI 機能構造体へのコンフィギュレーション書き込みによってシステムソフトウェアでプログラムされます。コアがマルチベクター MSI 用にコンフィギュレーションされている場合、 Multiple Message Enable フィールドに 0 以外の値をプログラムすることで、システムソフトウェアはマルチベクター MSI メッセージを許可することができます。

送信される MSI TLP のタイプ (32 ビットまたは 64 ビットのアドレス指定可能なもの) は、 MSI 機能構造体の UpperAddress フィールドの値によって変わります。デフォルトでは MSI メッセージは 32 ビットのアドレス指定可能なメモリ書き込み TLP として送信されます。上位アドレスレジスタに 0 以外の値がシステムソフトウェアによってプログラムされている場合のみ、 MSI メッセージは 64 ビットのアドレス指定可能なメモリ書き込み TLP を使用します。

マルチベクター MSI メッセージが有効場合、アップストリームに送信されたさまざまな MSI メッセージを区別するため、送信された MSI TLP の各 Message Data フィールドの 1 つまたは複数の下位ビットをユーザーアプリケーションが上書きできます。 Message Data フィールドにあるユーザーアプリケーションで使用可能な下位ビット数は、 IP カタログで設定されている Multiple Message Capable フィールドの値、システムソフトウェアで設定されている MultipleMessage Enable フィールドの値、および cfg_interrupt_msi_mmenable[2:0] コア出力で使用できる値の中でも小さい値によって決定されます。コアは cfg_interrupt_msi_select 内のビットをマスクしますが、これらはシステムソフトウェアで Multiple Message Enable を使用して設定されません。


図 3-68 : レガシ割り込みの信号


図 3-69 : MSI モード





必要なプロセスを示したサンプルコードは次のとおりです。

// 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 = {Padding_0s, MSI_Vector_Num};} else { // Single-Vector MSI Enabled

cfg_interrupt_msi_int = Padding_0s;}

} else {// Legacy Interrupts Enabled

}

例 :

1. cfg_interrupt_mmenable[2:0] == 000b、つまり 1 つの MSI ベクターが有効の場合、 cfg_interrupt_msi_int = 00h; となります。

2. cfg_interrupt_mmenable[2:0] == 101b、つまり 32 の MSI ベクターが有効の場合、 cfg_interrupt_msi_int = {{27'b0}, {MSI_Vector#}}; となります。

MSI_Vector# が 5 ビット値ならば、 00000b ≤ MSI_Vector# ≤ 11111b となることが可能です。

ベクターごとのマスキング (Per-Vector Masking) が有効になっている場合は、送信されているべクターがマスクレジスタでマスクされていないことをまず確認する必要があります。コンフィギュレーションインターフェイスでこのレジスタを読み出すことでこの確認はできます (コアはマスクレジスタを確認しない)。

MSI-X モード

Gen3 Integrated Block for PCIe コアは、オプションで図 3-70 に示す MSI-X 機能構造体をサポートします。 MSI-X ベクターテーブルと MSI-X Pending Bit Array は、ロジックの一部として BAR の隙間を利用してインプリメントする必要があります。


図 3-70 : MSI-X モード





コンフィギュレーション空間レジスタとコンフィギュレーションインターフェイスを使用するデザインコンフィギュレーションレジスタで使用されるポートについては、 26 ページの表 2-13 で説明しています。ルートポートは、コンフィギュレーション空間を構築するためにコンフィギュレーションポートを使用する必要があります。エンドポイントもコンフィギュレーションポートを使用して、読み出し /書き込みを実行できます。ただし、システムに悪影響を及ぼす原因を回避するよう注意が必要です。

ユーザーは、バイトアドレスではなく Dword アドレスとしてアドレスを提供する必要があります。

ヒント : バイトアドレスを 4 で割ると、レジスタ用の Dword アドレスを算出できます。

例 :

PCI コンフィギュレーション空間ヘッダーのコマンド /ステータスレジスタ :

• Dword アドレスは 01h

注記 : バイトアドレスは 04h

BAR0 :

• Dword アドレスは

注記 : バイトアドレスは 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-71 に、コンフィギュレーション空間の読み出し動作の信号を例示します。


図 3-71 : cfg_mgmt_read_type0_type1





コンフィギュレーション空間のレジスタに書き込みを実行するには、ユーザーロジックが 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 をディアサートする必要があります。

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


図 3-72 : cfg_mgmt_write_type0


図 3-73 : cfg_mgmt_write_type1_override





リンクトレーニング : 2 レーン、 4 レーン、および 8 レーンコンポーネント2 レーン、 4 レーン、 8 レーンのコアは、『PCI Express Base Specification』 [参照 2] で規定されている大レーン幅未満で動作可能です。次のサブセクションで定義されているように、指定されている大レーン幅未満でコアが動作するケースは 2 つあります。

リンクパートナーが少ないレーン数をサポートする場合

2 レーンコアが 1 レーンのみをインプリメントするデバイスに接続されている場合、このコアはレーン 0 を使用して1 レーンデバイスとしてリンクを確立して動作します。

4 レーンコアが 1 レーンのみをインプリメントするデバイスに接続されている場合、図 3-74 に示すようにこのコアはレーン 0 を使用して、 1 レーンデバイスとしてリンクを確立して動作します。同様に、 4 レーンコアが 2 レーンデバイスに接続されている場合、このコアはレーン 0 および 1 を使用して 2 レーンデバイスとしてリンクを確立して動作します。

8 レーンコアが 4 レーンのみをインプリメントするデバイスに接続されている場合、このコアはレーン 0 から 3 を使用して、 4 レーンデバイスとしてリンクを確立して動作します。また、接続されているデバイスが 1 または 2 レーンのみをインプリメントする場合、この 8 レーンコアは 1 レーンまたは 2 レーンデバイスとしてリンクを確立して動作します。

レーンにエラーが発生した場合

コアおよびリンクパートナーデバイスでサポートされている大レーン幅にリンクトレーニングを行った後にリンクにエラーが発生すると、コアは回復を試み、可能であれば小さいレーン幅でリンクトレーニングを実行します。レーン 0 にエラーが発生した場合、リンクは回復不可能となり失われます。レーン 1 から 7 のいずれか、またはすべてにエラーが発生した場合、リンクは回復モードに遷移し、まだ動作しているレーンを使用して回復可能な大レーンを回復しようとします。

たとえば、 8 レーンコアを使用する場合、レーン 1 が損失すると回復措置が取られレーン 0 で 1 レーン動作になりますが、レーン 6 が損失するとレーン 0 から 3 で 4 レーン動作になります。回復措置後、エラーの発生したレーンが再び動作可能な状態になっても、コアは大きいリンク幅へと回復措置を取ろうとはしません。値の大きいほうのリンク幅へ回復措置が取られるのは、リンクがダウンし初からリンクトレーニングを行う場合のみです。


図 3-74 : 4 レーンエンドポイントブロックの動作 (4 レーンから 1 レーン)





user_clk クロック出力は IP カタログで設定された固定周波数になります。リンクの回復またはリンクトレーニングのダウンが発生しても user_clk の周波数は変更されません。

レーン反転統合ブロックは、限定的なレーン反転機能をサポートし、リンクパートナーに対して柔軟なボードデザインを提供します。リンクパートナーは反転されたレーン番号でボードをレイアウトするよう選択でき、統合ブロックはリンクトレインを継続し、通常どおりに動作します。レーン反転をサポートするコンフィギュレーションは x8 および x4 です (ダウンシフトモードを除く )。ダウンシフトとは、各リンクパートナーがそれぞれ異なるリンク幅機能を持つ場合に発生するリンク幅交渉プロセスを指します。リンク幅交渉の結果、リンクパートナーは 2 つのレーン幅のうち値の小さいほうに交渉を成立させます。表 3-18 には、ダウンシフトモードを含むさまざま組み合わせ、およびレーン反転サポートの有無がまとめられています。

表 3-18 : レーン反転サポート

統合ブロックの可能なレーン幅

交渉されるレーン幅

レーン番号のマッピング(エンドポイントリンクパートナー ) レーン反転

サポートエンドポイントリンクパートナー

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) [参照 9]

• 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 8]

• 『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参照 10]

• 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 12]

コアのカスタマイズおよび生成ここでは、ザイリンクスツールを使用し、 Vivado Design Suite でコアをカスタマイズおよび生成する方法について説明します。

重要 : Vivado IP インテグレーターでコアをカスタマイズおよび生成する場合は、『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994) [参照 9] を参照してください。デザインの検証または生成時に一部の設定値が IP インテグレーターによって自動的に計算される場合があります。値が変わるかどうかを確認するには、この章のパラメーターの説明を参照してください。パラメーター値を確認するには、 Tcl コンソールから validate_bd_design コマンドを実行してください。

Gen3 Integrated Block for PCIe コアはユーザーデザインに合わせてカスタマイズできます。それには、 IP コアに関連する各種パラメーターの値を次の手順に従って指定します。

1. Vivado IP カタログから IP を選択します。

2. 選択した IP をダブルクリックするか、ツールバーまたは右クリックメニューから [Customize IP] コマンドをクリックします。

詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 8] および『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参照 10] を参照してください。

注記 : この章の図には Vivado 統合設計環境 (IDE) のスクリーンショットが使用されていますが、現在のバージョンとはレイアウトが異なる場合があります。

UltraScale Architecture Gen3 Integrated Block for PCIe FPGA 用の [Customize IP] ダイアログボックスには、2 つのモード ( 「Basic モード」、「[Advanced] モード」 ) があります。モード選択には、 [Customize IP] ダイアログボックスの初のページにある [Mode] ドロップダウンリストを使用します。




第 4 章 : デザインフローの手順

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 つのオプションがあります。96 ページの「データアライメントオプション」を参照してください。

[Requestor Completion Straddle]

インターフェイス幅が 256 ビットの場合、コアはリクエスターコンプリーションインターフェイス上でパケットをストラドルするオプションを利用できます。 163 ページの「256 ビットインターフェイスのストラドルオプション」を参照してください。

[Enable Client Tag]

クライアントタグの利用を可能にします。

[Reference Clock Frequency]

sys_clk に供給される基準クロックの周波数を選択します。コアのクロック供給の詳細は、「クロッキング」を参照してください。

[Xilinx Development Board]

ザイリンクス開発ボードに特化した制約ファイルを生成する場合、このオプションを選択します。

[Silicon Revision]

シリコンのリビジョンを選択します。有効なオプションは [Production] です。

[Enable External PIPE Interface]

このオプションが有効の場合、外部のサードパーティバスファンクショナルモデル (BFM) を PCIe 統合ブロックのPIPE インターフェイスへ接続できます。このオプションは、エンドポイントモードとルートポートモードの両方に利用可能であり、 [Include Shared Logic (Clocking) in example design] オプションが選択されている場合のみ有効です。

[Capabilities]

このオプションの設定については、このセクションで説明します。

表 4-3 : レーン幅、リンクスピード、およびインターフェイス幅

レーン幅リンクスピード (Gb/s) インターフェイス幅 (Bits)

x8 8.0 256





[Enable Physical Function 0]

追加の Physical Function (PF) をインプリメントします。

統合ブロックは、 PF0 に関連する大 6 個までの Virtual Function をインプリメントします (有効な場合)。

[MPS]

このフィールドは、デバイスまたはファンクションが TLP 用にサポートできる大ペイロードサイズを示します。デバイス機能レジスタ (Device Capabilities Register) を介してシステムに伝達される値です。

[Extended Tag]

リクエスターとしてサポートされているタグフィールドの大サイズを示します。使用可能なオプションは次のとおりです。

• 選択されている場合は、 6 ビットのタグフィールド (64 タグ) がサポートされる

• 選択されていない場合は、 5 ビットのタグフィールド (32 タグ) がサポートされる

[Slot Clock Configuration]

リンクステータスレジスタの Slot Clock Configuration ビットを有効にします。このオプションを選択した場合、リンクに同期クロックが供給されます。クロッキングオプションの詳細は、「クロッキング」を参照してください。

[Identity Settings] (PF0 IDs および PF1 IDs)

このオプション設定では、 IP の初期値、クラスコード、および Cardbus CIS ポインター情報をカスタマイズします。Physical Function 1 (PF1) のページは、 PF1 が有効の場合のみ表示されます。

PF0 ID の初期値

• [Vendor ID] : デバイスまたはアプリケーションの製造者 ID です。各 ID の重複を避けるため PCI Special InterestGroup によって有効な ID が割り当てられています。デフォルト値「10EEh」はザイリンクスのベンダー ID です。ここにベンダー ID を入力します。「FFFFh」は予約されています。

• [Device ID] : アプリケーションの ID です。デフォルト値は選択されているコンフィギュレーションにより異なりますが、「70<link speed><link width>h」となります。このフィールドには任意の値を入力できます。アプリケーションに合わせて変更してください。

• [Revision ID] : デバイスまたはアプリケーションのリビジョンを指し、デバイス ID に付随するものです。デフォルト値は「00h」です。アプリケーションに合った値を入力してください。

• [Subsystem Vendor ID] : デバイスまたはアプリケーションの製造者をさらに細分化させるための ID です。ここにサブシステムベンダー ID を入力します。デフォル値は「10EEh」です。通常、この値はベンダー ID と同じです。この値を「0000h」に設定すると準拠テスト問題が発生します。

• [Subsystem ID] : デバイスまたはアプリケーションの製造者をさらに細分化させるための ID です。この値は通常デバイス ID と同じです。デフォルト値は選択されているレーン幅およびリンクスピードにより異なります。この値を「0000h」に設定すると準拠テスト問題が発生します。





クラスコード

クラスコードは、デバイスの一般的な機能を識別するもので、 3 つのバイトサイズフィールドに分かれています。

• [Base Class] : デバイスにより実行される機能のタイプを広義に識別します。

• [Sub-Class] : デバイス機能をさらに細かく識別します。

• [Interface] : デバイスに依存したソフトウェアがデバイスとインターフェイスできるようにするレジスタレベルのプログラミングインターフェイスを定義します。

クラスコードのエンコードについては www.pcisig.com を参照してください。

[Class Code Look-up Assistant]

選択されているデバイスの一般機能に対して、ベースクラス、サブクラス、およびインターフェイスの値を提供します。この検索ツールは、選択されている機能に対し 3 つの値を表示するだけです。デバイス設定に変換するには、ユーザー自身が「クラスコード」にこれらの値を入力する必要があります。

[Base Address Registers] (PF0 および PF1)

Base Address Registers (BARs) のページでは、エンドポイントコンフィギュレーションのベースアドレスレジスタ空間を設定します。各 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 はレガシ PCIExpress エンドポイントコアに対してのみ使用できます。

° [Memory] : Memory BAR は 64 ビットまたは 32 ビットに設定でき、プリフェッチ可能です。 BAR が 64 ビットに設定されている場合、拡張アドレス空間用に次の BAR が使用され、その BAR にはアクセスできなくなります。

• [Size] : 使用可能なサイズ範囲は、[PCIe Device/Port Type] および [Type of BAR] の設定によって異なります。表 4-4に、 BAR サイズの範囲がまとめられています。

表 4-4 : デバイスコンフィギュレーション別の BAR サイズ範囲

[PCIe Device/Port Type] BAR タイプ BAR サイズ範囲

PCI Express Endpoint32 ビットメモリ 128 バイト (B) ～ 2 ギガバイト (GB)

64 ビットメモリ 128B ～ 256GB

http://www.pcisig.com





• [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 は無効になります。

[Legacy/MSI Capabilities]

このページでは、該当するすべての Physical Function および Virtual Function に対して [Legacy Interrupt Settings] および[MSI Capabilities] を設定できます。

[Legacy Interrupt Settings]

• [Enable INTX] : PCI Express ファンクションの INTx 割り込み生成機能を有効にします。

レガシ PCI Express Endpoint



I/O 16B ～ 2GB

表 4-4 : デバイスコンフィギュレーション別の BAR サイズ範囲 (続き)






• [Interrupt PIN] : レガシ割り込みメッセージのマッピングを示します。 [None] は、レガシ割り込みが使用されていないことを示します。

[MSI Capabilities]

• [Enable MSI Capability Structure] : MSI 機能構造体を有効にします。

注記 : MSI または MSI-X を有効にしないことも可能ですが、その場合、コアが規格に準拠しなくなる可能性があります。『PCI Express Base Specification』 [参照 2] では、 MSI または MSI-X のいずれかまたは両方が有効になることが条件として定義されています。

• [Multiple Message Capable] :ルートコンプレックスから要求する MSI ベクターの数を選択します。

• [Per Vector Masking Capable] : ファンクションが MSI のベクターごとのマスキングをサポートすることを示します。

[Advanced] モード

[Customize IP] ダイアログボックスでは、このセクションで説明するコンフィギュレーションオプションを選択できます。

[Basic]

Advanced モード用の [Basic] ページには、いくつかの追加設定があります。 Advance モードを選択した場合に [Basic]ページで指定できるパラメーターは次のとおりです。

[Use the dedicated PERST routing resources]

PCIE_X0Y0 ブロックの sys_rst 専用配線を有効にします。

[System reset polarity]

sys_rst の極性 (ACTIVE_HIGH または ACTIVE_LOW) を設定します。

[PCIe DRP Ports]

オンにすると、 PCIe DRP インターフェイスが有効になります。

[GT Channel DRP]

オンにすると、 GT チャネル DRP インターフェイスが有効になります。

[Enable GT Quad Selection]

デバイス /パケージの移行を可能にします。「UltraScale アーキテクチャ PCI Express デザインのパッケージ移行」を参照してください。

[GT Quad]

ドロップダウンメニューを使用して任意の GTH クワッドを選択します。このオプションは、 [Enable GT QuadSelection] がオンになっている場合のみ有効です。

[PPM Offset between receiver and transmitter]

受信データと送信データ間における PPM (Programmed Power Management) のオフセットを指定します。





[Spread spectrum clocking]

PPM でのスペクトラム拡散クロックの変調を指定します。

[Insertion loss at Nyquist]

ナイキスト周波数でのトランスミッターからレシーバーの挿入ロスを示します (dB)。

[Capabilities]

Advanced モード用の [Capabilities] 設定には、 Basic モードの設定にさらに 3 つのパラメーターが追加されています。詳細は次のとおりです。

[SRIOV Capabilities]

SRIOV (Single Root Port I/O Virtualization) 機能を有効にします。統合ブロックが拡張型の Single Root Port I/O VirtualizationPCIe をインプリメントします。このオプションが有効の場合、SRIOV は PF0 と PF1 の両方 (選択されている場合) にインプリメントされます。

[Function Level Reset]

ファンクションレベルのリセット機能が有効であることを示します。ユーザーが特定のデバイス機能をリセットできます。このオプションは、エンドポイントコンフィギュレーションにのみ適用可能です。

[Device Capabilities Registers 2]

AtomicOps および TPH Completer をサポートするためのオプションを指定します。詳細は、『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]

hysical Function 用の 4 ビットの SRIOV Capability バージョンを示します。

[SRIOV Function Select]

Physical Function と関連する Virtual Function の数を示します。 PF0 および PF1 には、大で 6 個の Virtual Function を指定できます。

[SRIOV Functional Dependency Link]

Physical Function 用の SRIOV 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 までです。メモリのみに使用します。

表 4-5 : Virtual Function のマッピング例

Physical Function Virtual Function ファンクション番号の範囲

PF0 VF0 64

PF0 VF1 65

PF1 VF0 66

PF1 VF1 67

PF1 VF1 68





すべての SRIOV BAR レジスタに次のオプションがあります。

• チェックボックス : BAR を有効にするにはチェックボックスをオンします。 BAR を無効にするにはこのチェックボックスをオフにします。

• [Type] : SRIOV BAR は I/O または Memory のいずれかにできます。

° [I/O] : I/O BAR は 32 ビットのみです。 I/O BAR はプリフェッチ対応ではありません。 I/O BAR はレガシ PCIExpress エンドポイントコアに対してのみ使用できます。

° [Memory] : Memory BAR は 64 ビットまたは 32 ビットに設定でき、プリフェッチ可能です。 BAR が 64 ビットに設定されている場合、拡張アドレス空間用に次の BAR が使用され、その BAR にはアクセスできなくなります。

• [Size] : 使用可能なサイズ範囲は、[PCIe Device/Port Type] および [Type of BAR] の設定によって異なります。表 4-6に、 BAR サイズの範囲がまとめられています。

• [Prefetchable] : メモリ空間をプリフェッチ可能にするかどうかを設定します。

• [Value] : 現在の選択内容に基づいて BAR に値が割り当てられます。

SRIOV ベースアドレスレジスタの設定の管理については、「ベースアドレスレジスタの設定の管理」を参照してください。

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 は無効になります。

表 4-6 : デバイスコンフィギュレーション別の SRIOV BAR サイズ範囲


PCI Express Endpoint32 ビットメモリ 128B ～ 2GB


レガシ PCI Express Endpoint



I/O 16B ～ 2GB





[Legacy/MSI Capabilities]

このページは、 Basic モードと同じです。

[MSI-X Capabilities]

Advanced モードでのみ有効です。

• [Enable MSIx Capability Structure] : MSI-X Capability が有効になっていることを示します。

注記 : Capability Structure (機能構造体) では、少なくとも 1 つの Mamory BAR を設定する必要があります。ユーザーは、アプリケーションの MSI-X テーブルおよび Pending Bit Array の設定を管理する必要があります。

• [MSIx Table Settings] : MSI-X テーブルの構造を定義します。

° [Table Size] : MSI-X テーブルのサイズを指定します。

° [Table Offset] : MSI-X テーブルのベースを指し示す、ベースアドレスレジスタからのオフセット値を指定します。

° [BAR Indicator] : MSI-X テーブルのファンクションをメモリ空間へマップするために使用されるコンフィギュレーション空間のベースアドレスレジスタを示します。 64 ビットのベースアドレスレジスタの場合、これは下位 DWORD を指します。

• [MSIx Pending Bit Array (PBA) Settings] : MSI-X PBA (Pending Bit Array) の構造を定義します。

° [PBA Offset] : MSI-X PBA のベースを指し示す、ベースアドレスレジスタからのオフセット値を指定します。

° [PBA BAR Indicator] : MSI-X PBA のファンクションをメモリ空間へマップするために使用されるコンフィギュレーション空間のベースアドレスレジスタを示します。

[Power Management] (パワーマネージメント )

[Power Management] ページでは、パワーマネージメントレジスタ、電力消費、および電力損失に関する設定を行います。これらの設定は、 PF1 が有効の場合に両方の Physical Function に対して適用されます。

• [D1 Support] : ファンクションで D1 Power Management State がサポートされていることを示します。詳細は、『PCIBus 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 (offset0x100h)] は常に有効に設定されています。 [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] (ルートポートコンフィギュレーションのみ) : このオプションがオンの場合、 NoSnoop 属性が適用されているが TLP ヘッダーでは設定されていないトランザクションは、サポートされないリクエスト (UR) として拒否される可能性があります。

• [Enable AER Capability] : Advanced Error Reporting 機能をサポートするオプションの PCIe 拡張機能です。この機能は常に有効となります。

その他のオプション機能

• [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 機能をインプリメントします。

[Shared Logic] (共有ロジック )

このページで 1 つまたは複数のオプションを選択して、複数のインスタンシエーション間で共通のブロックを共有できるようにします。詳細は、第 3 章の「共有ロジック」を参照してください。

[Core Interface Parameters]

コアインターフェイスのパラメーターを選択できます。デフォルトで、すべてのポートが選択されているため、使用しないインターフェイスを無効にできます。無効になると、コアの上位からそのインターフェイス (ポート ) が削除されます。

推奨 : 通常の使用では、インターフェイスを無効にしないでください。特別な場合のみポートを無効にしてください。





.

[Tansmit FC Interface]

コアが提供するフロー制御情報を要求できます。このオプションをオフにすると、次のポートが削除されます。

• pcie_tfc_nph_av

• pcie_tfc_npd_av


図 4-1 : [Core Interface Parameters]





[Config FC Interface]

UltraScale Architecture Gen3 Integrated Block for PCIe コア用のコンフィギュレーションフロー制御を制御できます。このオプションをオフにすると、次のポートがコアから削除されます。

• cfg_fc_ph

• cfg_fc_pd

• cfg_fc_nph

• cfg_fc_npd

• cfg_fc_cplh

• cfg_fc_cpld

• cfg_fc_sel

[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

出力の生成

詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 8] を参照してください。





コアへの制約ここでは、 Vivado® Design Suite でコアに制約を指定する方法について説明します。

必須の制約

UltraScale Architecture Gen3 Integrated Block for PCIe ソリューションでは、 PCI Express® 用の特定性能要件を満たすために、タイミングおよびその他の物理的なインプリメンテーション制約を指定する必要があります。これらの制約は、エンドポイントおよびルートポートソリューションで、ザイリンクスデザイン制約 (XDC) ファイルを用いて適用されます。生成される XDC ファイルにあるピン配置および階層名は、配布されているサンプルデザインのものと一致しています。

一貫したインプリメンテーション結果を得るには、ザイリンクスツールでデザインを実行するときに、変更されていない元の制約を含んだ XDC ファイルを使用する必要があります。XDC または特定の制約の定義および使用方法についての詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 [参照 11] を参照してください。

統合ブロックソリューションで提供されている制約は、ハードウェア上でテスト済みで、一貫した結果を提供します。制約は変更可能ですが、各制約をよく理解した上で変更してください。また、提供されている制約を規定から逸脱した形で使用したデザインに対してはサポートを提供しておりません。

デバイス、パッケージ、およびスピードグレードの選択

XDC のデバイス選択セクションには、ターゲットにするパーツ、パッケージ、スピードグレードが記述されており、この情報がインプリメンテーションツールに渡されます。

重要 : Gen3 Integrated Block for PCIe コアは特定のパーツとパッケージの組み合わせに対して設計されているため、このセクションは変更しないでください。

このセクションには常にパーツを選択する行が含まれていますが、パーツまたはパッケージ別のオプションも含まれている場合があります。たとえば、次のようになります。

CONFIG PART = XCKU040-ffva1156-3-e-es1

クロック周波数

クロック要件の詳細は、第 3 章「コアを使用するデザイン」を参照してください。

クロック管理


クロック配置


バンキング

このセクションは、この IP コアには適用されません。





トランシーバーの配置


I/O 規格と配置


シミュレーションVivado シミュレーションコンポーネントについて、またサポートされているサードパーティツールについては、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 12] を参照してください。

サンプルデザインのシミュレーション方法は、第 5 章の「サンプルデザインのシミュレーション」を参照してください。

PIPE モードシミュレーション

UltraScale Architecture 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 を使用するための必要な接続も提供されます。

詳細は、 179 ページの「[Enable External PIPE Interface]」を参照してください。

表 4-7 および表 4-8 に、コアの上位に含まれる PIPE バス信号と、 EP コア (pcie_top) PIPE 信号のマッピングを示します。

ヒント : PIPE モードは、シミュレーション専用です。インプリメンテーションはサポートされていません。





表 4-7 : 共通の入力/出力コマンドと Endpoint PIPE 信号のマッピング

入力コマンドEndpoint PIPE 信号の

マッピング出力コマンド

Endpoint PIPE 信号のマッピング

common_commands_in[0]common_commands_in[1]common_commands_in[2]common_commands_in[3]common_commands_in[4]common_commands_in[5]common_commands_in[11:6]common_commands_in[17:12]common_commands_in[25:18]

pipe_clk(1)

core_clk(2)

user_clk(3)

rec_clk(4)

phy_rdy(5)

mmcm_lock(6)

pipe_tx_eqfs(7)

pipe_rx_eqlf(8)

pipe_rx_syncdone(9)

common_commands_out[0] common_commands_out[2:1]common_commands_out[3] common_commands_out[6:4]common_commands_out[7]common_commands_out[8]common_commands_out[16:9]

pipe_tx_rcvr_det_gtpipe_tx_rate_gtpipe_tx_deemph_gtpipe_tx_margin_gtpipe_tx_swing_gtpipe_tx_reset_gtpipe_tx_slide_gt

注記 :

1. pipe_clk は、 AveryDesign Systems 社製 BFM クロック信号 aclk250M の位相に基づいて再生成されたクロックです。リンクスピードが Gen1 の場合、 pipe_clk は 125MHz となり、 Gen3 の場合は 250MHz となります。

2. core_clk は、ザイリンクスの PCI Express エンドポイントクロックです。Gen3 x8 コンフィギュレーションの場合、core_clk = 500MHzとなります。

3. user_clk は、ザイリンクスの PCI Express エンドポイントクロックです。Gen3 x8 コンフィギュレーションの場合、user_clk = 250MHzとなります。

4. rec_clk は、ザイリンクスの PCI Express エンドポイントクロックです。 pipe_clk 信号へ接続してください。

5. phy_rdy は、 10µs 後にアサートされる必要があります。

6. mmcm_lock は、 10µs 後にアサートできます。

7. 6’d40 を pipe_tx_eqfs に割り当てます。

8. 6’d15 を pipe_tx_eqlf に割り当てます。

9. 8’d0 を pipe_rx_syncdone に割り当てます。





合成およびインプリメンテーション合成およびインプリメンテーションの詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 8] を参照してください。

サンプルデザインの合成およびインプリメンテーションに関する詳細は、第 5 章の「サンプルデザインの合成およびインプリメンテーション」を参照してください。

表 4-8 : 入力/出力バスと Endpoint PIPE 信号のマッピング

入力バス Endpoint PIPE 信号のマッピング出力バスEndpoint PIPE 信号の

マッピング

pipe_rx_0_sigs[31:0]pipe_rx_0_sigs[33:32]pipe_rx_0_sigs[34] pipe_rx_0_sigs[35] pipe_rx_0_sigs[36] pipe_rx_0_sigs[38:37]pipe_rx_0_sigs[41:39]pipe_rx_0_sigs[42]pipe_rx_0_sigs[43]pipe_rx_0_sigs[44](1)

pipe_rx_0_sigs[62:45](2)

pipe_rx_0_sigs[80:63](3)

pipe_rx_0_sigs[81](4)



pipe_rx0_data_gtpipe_rx0_char_is_k_gtpipe_rx0_data_valid_gtpipe_rx0_elec_idle_gtpipe_rx0_start_block_gtpipe_rx0_syncheader_gtpipe_rx0_status_gtpipe_rx0_valid_gtpipe_rx0_phy_status_gtpipe_rx0_eqdone_gtpipe_rx0_eqcoeff_gtpipe_rx0_eqlp_new_txcoef_forpreset_gtpipe_rx0_eqlp_lffs_sel_gtpipe_rx0_eqlp_adaptdone_gtpipe_rx0_eqdone_gt

pipe_tx_0_sigs[31:0]pipe_tx_0_sigs[33:32]pipe_tx_0_sigs[34]pipe_tx_0_sigs[35]pipe_tx_0_sigs[36]pipe_tx_0_sigs[38:37]pipe_tx_0_sigs[39]pipe_tx_0_sigs[41:40]pipe_tx_0_sigs[43:42]pipe_tx_0_sigs[47:44](7)

pipe_tx_0_sigs[53:48](7)

pipe_tx_0_sigs[55:54]pipe_tx_0_sigs[58:56](7)



pipe_tx_0_sigs[69]

pipe_tx0_data_gtpipe_tx0_char_is_k_gtpipe_tx0_elec_idle_gtpipe_tx0_data_valid_gtpipe_tx0_start_block_gtpipe_tx0_syncheader_gtpipe_tx0_polarity_gtpipe_tx0_powerdown_gtpipe_tx0_eqcontrol_gtpipe_tx0_eqpreset_gtpipe_tx0_eqdeemph_gtpipe_rx0_eqcontrol_gtpipe_rx0_eqpreset_gtpipe_rx0_eqlp_lffs_gtpipe_rx0_eqlp_txpreset_gtpipe_tx0_compliance_gt

注記 :

1. pipe_tx0_eqcontrol_gt (pipe_tx_0_sigs[43:42]) がトグルしている間は常にアサートされます。

2. 18'd2 を割り当てます。

3. 18'd0 を割り当てます。

4. 1'b1 を割り当てます。

5. 1'b0 を割り当てます。

6. pipe_rx0_eqcontrol_gt (pipe_tx_0_sigs[55:54]) がトグルしている間は常にアサートされます。

7. これらの信号は無視できます。




第 5 章

サンプルデザインこの章では、 Vivado® Design Suite で提供されているサンプルデザインについて説明します。

サンプルデザインの概要このセクションでは、 UltraScale Architecture Gen3 Integrated Block for PCIe のサンプルデザインについて説明します。

統合ブロックのエンドポイントコンフィギュレーションの概要

統合ブロックのエンドポイントコンフィギュレーションのサンプルシミュレーションデザインは、 2 つの完全に独立したパーツで構成されています。

• ルートポートモデル : PCI Express® のバストラフィックを生成、使用、チェックするテストベンチです。

• PIO (Programmed Input/Output) サンプルデザイン : PCI Express のコンプリーターアプリケーションです。 PIO サンプルデザインは、そのメモリ空間への読み出しおよび書き込みリクエストに応答し、ハードウェアでのテスト用に合成することができます。




第 5 章 : サンプルデザイン

シミュレーションデザインの概要

シミュレーションデザインの場合、トランザクションはルートポートモデルからコア (エンドポイントとしてコンフィギュレーション) に送信され、 PIO サンプルデザインによって処理されます。図 5-1 は、コアで提供されているシミュレーションデザインについて説明しています。ルートポートモデルの詳細は、 210 ページの「エンドポイント用ルートポートモデルテストベンチ」を参照してください。

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

図 5-2 にあるように、インプリメンテーションデザインは、読み出しおよび書き込みトランザクションを受理してリクエストに応答できる、簡単な PIO サンプルデザインで構成されています。このサンプルのソースコードはコアと共に提供されています。PIO サンプルデザインのシミュレーションについては、201 ページの「PIO (Programmed Input/Output) : エンドポイントのサンプルデザイン」を参照してください。


図 5-1 : シミュレーションサンプルデザインのブロック図





サンプルデザインのエレメント

PIO サンプルデザインには、次のエレメントがあります。

• コアラッパー

• サンプルの Verilog HDL ラッパー (コアおよびサンプルデザインをインスタンシエートする )

• サンプルデザインをシミュレーションするためのカスタマイズ可能なデモ用テストベンチ

このサンプルデザインは、次のシミュレータを使用して Vivado Design Suite でテストおよび検証されています。

• Vivado シミュレータ

• Mentor Graphics 社製 Questa Sim

• Cadence 社製 Incisive Enterprise Simulator (IES)

• Synopsys 社製 Verilog Compiler Simularor (VCS)

サポートされているツールのバージョンは、『Vivado Design Suite ユーザーガイド : リリースノート、インストールおよびライセンス』 (2) を参照してください。


図 5-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 デザイン Port Model は、コア (Endpoint Block Plus for PCI Express および Endpoint PIPE for PCI Express ソリューション) で共有されます。このセクションでは、総称的に Endpoint for PCI Express (または Endpoint for PCIe™) の名前を使用してすべてのソリューションを表しています。

システムの概要

PIO デザインは、シンプルなターゲット専用のアプリケーションで、 PCIe コア用エンドポイントのトランザクション(AXI4-Stream) インターフェイスと接続され、これを手掛かりにして独自デザインを構築できるように提供されています。次の機能が含まれています。

• 内部 FPGA ブロック RAM を使用するトランザクションごとの 2KB ターゲット領域が 4 つ (ターゲット空間の合計は 8192 バイト )。

• コンプリーション 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 が開始します。





CPU が MMIO アドレスコマンドに格納レジスタを出力すると、データはダウンストリームに移動します。ルートコンプレックスは通常、適切な MMIO ロケーションアドレス、バイトイネーブル、およびレジスタの内容を含むメモリ書き込み TLP を生成します。エンドポイントがこのメモリ書き込み TLP を受信し、対応するローカルレジスタをアップデートすると、トランザクションは終了します。

CPU が MMIO アドレスコマンドからロードレジスタを出力すると、データはアップストリームに移動します。ルートコンプレックスは通常、適切な MMIO ロケーションアドレスおよびバイトイネーブルのあるメモリ読み出し TLPを生成します。エンドポイントはこのメモリ読み出し TLP を受信した後に、データ TLP と共にコンプリーションを生成します。このコンプリーションはルートコンプレックスに送信され、ペイロードがターゲットレジスタにロードされると、トランザクションは完了します。

PIO ハードウェア

PIO デザインは、 PCIe 用エンドポイントの背後にある FPGA ブロック RAM に 8192 バイトのターゲット空間をインプリメントします。この 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 リクエストがうまくいったことを示すステータスと共に、データなしのコンプリーションを返します。


図 5-3 : システムの概要





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 RequestDescriptor[114:112] の該当ビット (BAR ID[2:0]) をアサートします。

表 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





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 の書き込みリクエストコントローラーへ、これを渡すことができるようにします。

アサートされた特定の 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 デザインではどちらでも使用できます。データパスの幅は、ターゲットになっているコアによって異なります。

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-2 : PIO ファイルの構造

ファイル説明

PIO.v 上位デザインのラッパー

PIO_INTR_CTRL.v PIO 割り込みコントローラー

PIO_EP.v PIO アプリケーションモジュール

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-4 は、 PIO デザインのさまざまなコンポーネントを示しています。 PIO デザインは、 TX エンジン、 RX エンジン、メモリアクセスコントローラー、パワーマネージメントターンオフコントローラーという 4 つの主なパーツに分かれています。

PIO の動作

PIO 読み出しトランザクション

図 5-5 は、 PIO デザインへの連続するメモリ読み出しリクエストを表しています。受信エンジンは、初の TLP が完全に受信されるとすぐに、 m_axis_rx_tready をディアサートします。次の読み出しトランザクションは、送信エンジンが compl_done_o をアサートし、初のリクエストが完全に送信されたことを示すコンプリーションが生成された後にのみ受け入れられます。

表 5-3 : PIO コンフィギュレーション

コア X1 x2 x4 x8

UltraScale FPGA Gen3 Integrated Block 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 デザインのコンポーネント





PIO 書き込みトランザクション

図 5-6 は、PIO デザインへの連続するメモリ書き込みリクエストを表しています。次の書き込みトランザクションは、メモリアクセスユニットが wr_busy_o をディアサートし、初のリクエストに関連するデータがメモリアパーチャーへすべて書き込まれたことを示した後にのみ受け入れられます。


図 5-5 : 連続する読み出しトランザクション


図 5-6 : 連続する書き込みトランザクション





デバイス使用量

表 5-4 に、 PIO デザインの FPGA リソース使用量を示します。

サンプルデザインのシミュレーションサンプルデザインを使用すると、 Vivado Design Suite で生成した PCI Express エンドポイントおよびルートポート用コアのサンプルデザインプロジェクトのビヘイビアーを簡単にシミュレーションして確認できます。

現在サポートされているシミュレータは次のとおりです。

• Vivado シミュレータ (デフォルト )

• ModelSim Questa Sim

• 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 BehavioralSimulation] をクリックします。

重要 : 合成後およびインプリメンテーション後のシミュレーションオプションは、PCI Express ブロックではサポートされていません。

[Run Behavioral Simulation] を実行した後、 [Tcl Console] ビューおよび [Log] ビューの [Simulation] タブで、コンパイルおよびエラボレーション段階を確認できます。

3. [Tcl Console] ビューに「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] のいずれかに設定します。

表 5-4 : PIO デザインの FPGA リソース使用率

リソース使用されているリソース数

LUT 300

フリップフロップ 500

ブロック RAM 4





3. [Simulator] タブで、 [Run Simulation] → [Run Behavioral Simulation] をクリックします。

4. プロンプトが表示されたら、変更するため [Yes] をクリックし、シミュレータを実行します。

エンドポイントコンフィギュレーション

エンドポイントコンフィギュレーションの Gen3 Integrated Block for PCIe コアで提供されているシミュレーション環境では、 PIO サンプルデザインに対して簡単なメモリアクセステストが実行されます。トランザクションはルートポートモデルにより生成され、 PIO サンプルデザインがそれに応答します。

• PCI Express TLP (Transaction Layer Packet) はテストベンチの送信ユーザーアプリケーション (pci_exp_usrapp_tx)によって生成されます。これが TLP を送信すると、ログファイル (tx.dat) も生成されます。

• PCI Express TLP はテストベンチの受信ユーザーアプリケーション (pci_exp_usrapp_rx) によって受信されます。ユーザーアプリケーションが TLP を受信すると、ログファイル (rx.dat) も生成されます。

テストベンチの詳細は、 210 ページの「エンドポイント用ルートポートモデルテストベンチ」を参照してください。

サンプルデザインの合成およびインプリメンテーションサンプルデザインの合成とインプリメンテーションを行うには、 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 デザインまたはユーザーデザインで使用できるテストプログラムインターフェイスを提供するテストベンチ環境です。ルートポートモデルは、カスタマーデザインをシミュレーションするため、ダウンストリームの 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 : ルートポートモデルおよび最上位エンドポイント





シミュレーションタイムアウトの設定

このコアのシミュレーションモデルは、シミュレーション中に妥当な時間内でリンクが確立されるよう、タイムアウトを設定できます。『PCI Express Specification, rev. 2.1』 [参照 2] によると、Link Training Status State Machine (LTSSM) のステートに関連付けられたさまざまなタイムアウトがあります。コアは、タイムアウトを設定できない RecoverySpeed_1 LTSSM ステートを除いて、シミュレーションで 256 の係数でこれらのタイムアウトを設定します。

テストの選択

表 6-1 ではルートポートモデルで提供されているテストについて説明し、その後のセクションでは Verilog テストについて詳しく説明します。

Verilog テストの選択

ルートポートモデルで使用される Verilog テストモデルでは、実行されるテスト名をコマンドラインパラメーターとしてシミュレータに指定できます。

実行されるテストを変更する場合は、テストファイル sample_tests1.v および pio_tests.v に定義されているTESTNAME の値を変更します。このメカニズムは、 Mentor Graphics Questa Sim で使用されています。 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) [参照 12] を参照してください。

Verilog フロー

ルートポートモデルは、+dump_all コマンドラインパラメーターをシミュレータに指定して、保管するシミュレーション波形を出力するためのメカニズムを提供します。

表 6-1 : ルートポートモデルで提供されるテスト

テスト名 Verilog でテスト説明

sample_smoke_test0 Verilog PCI タイプ 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 つのプロセス内に複数のテストが含まれ、順次プログラムと類似した動作をします。214 ページの「テストプログラム : 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:011:03:0

トランザクションインターフェイスのリセット、およびルートポートモデルとエンドポイント DUT 間のリンクアップを待ちます。

このタスクはエンドポイントコア初期化前に起動する必要があります。

TSK_TX_TYPE1_CONFIGURATION_READ tag_reg_addr_first_dw_be_

7:011:03:0

ルートポートモデルからのタイプ 1 PCIExpress コンフィギュレーション読み出し TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。

エンドポイント DUT から返された CplD は、コンプリーション ID としてグローバル COMPLETE_ID_CFG の内容を使用します。

TSK_TX_TYPE0_CONFIGURATION_WRITE tag_reg_addr_reg_data_first_dw_be_

7:011:031:03:0

ルートポートモデルからのタイプ 0 PCIExpress コンフィギュレーション書き込み TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。

エンドポイント DUT から返された Cpl は、コンプリーション ID としてグローバル COMPLETE_ID_CFG の内容を使用します。





TSK_TX_TYPE1_CONFIGURATION_WRITE tag_reg_addr_reg_data_first_dw_be_

7:011:031:03:0

ルートポートモデルからのタイプ 1 PCIExpress コンフィギュレーション書き込み TLP を、 tag_ および first_dw_be_ 入力のある、エンドポイント DUT の reg_addr_ に送信します。

エンドポイント DUT から返された Cpl は、コンプリーション ID としてグローバル COMPLETE_ID_CFG の内容を使用します。

TSK_TX_MEMORY_READ_32 tag_tc_len_addr_last_dw_be_first_dw_be_

7:02:0

10:031:03:03:0

ルートポートモデルからの PCI Express メモリ読み出し TLP を、エンドポイント DUT の 32 ビットメモリアドレス addr_ に送信します。


TSK_TX_MEMORY_READ_64 tag_tc_len_addr_last_dw_be_first_dw_be_

7:02:0

10:063:03:03:0

ルートポートモデルからの PCI Express メモリ読み出し TLP を、エンドポイント DUT の 64 ビットメモリアドレス addr_ に送信します。


TSK_TX_MEMORY_WRITE_32 tag_tc_len_addr_last_dw_be_first_dw_be_ep_

7:02:0

10:031:03:03: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:02:0

10:063:03:03:0–

ルートポートモデルからの PCI Express メモリ書き込み TLP を、エンドポイント DUT の 64 ビットメモリアドレス addr_ に送信します。


グローバルな DATA_STORE バイトアレイは、書き込みデータをタスクに渡すために使用されます。

TSK_TX_COMPLETION tag_tc_len_comp_status_

7:02:0

10:02:0

グローバル COMPLETE_ID_CFG をコンプリーション ID として使用し、 PCI Express コンプリーション TLP をルートポートモデルからエンドポイント DUT に送信します。

TSK_TX_COMPLETION_DATA tag_tc_len_byte_countlower_addrcomp_statusep_

7:02:0

10:011:06:02:0–

グローバル COMPLETE_ID_CFG をコンプリーション ID として使用し、PCI Express のデータ付きのコンプリーション TLP をルートポートモデルからエンドポイント DUT に送信します。

グローバルな DATA_STORE バイトアレイは、コンプリーションデータをタスクに渡すために使用されます。

表 6-3 : TLP タスク (続き)

名称入力説明





TSK_TX_MESSAGE tag_tc_len_datamessage_rtgmessage_code

7:02:0

10:063:02:07:0

PCI Express メッセージ TLP をルートポートモデルからエンドポイント DUT 送信します。

エンドポイント DUT から返されたコンプリーションは、コンプリーション ID としてグローバルCOMPLETE_ID_CFG の内容を使用します。

TSK_TX_MESSAGE_DATA tag_tc_len_datamessage_rtgmessage_code

7:02:0

10:063:02:07:0

PCI Express のデータ付メッセージ TLP をルートポートモデルからエンドポイント DUT に送信します。

グローバルな DATA_STORE バイトアレイは、メッセージデータをタスクに渡すために使用されます。

エンドポイント DUT から返されたコンプリーションは、コンプリーション ID としてグローバルCOMPLETE_ID_CFG の内容を使用します。

TSK_TX_IO_READ tag_addr_first_dw_be_

7:031:03:0

PCI Express I/O 読み出し TLP を、ルートポートモデルからエンドポイント DUT の I/O アドレスaddr_[31:2] に送信します。


TSK_TX_IO_WRITE tag_addr_first_dw_be_data

7:031:03:0

31:0

PCI Express I/O 書き込み TLP を、ルートポートモデルからエンドポイント DUT の I/O アドレスaddr_[31:2] に送信します。


TSK_TX_BAR_READ bar_indexbyte_offsettag_tc_

2:031:07:02: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_indexbyte_offsettag_tc_data_

2:031:07:02: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 をチェックする必要があります。


名称入力説明

表 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_BUS bar_indexnBytes

2:031:0

入力 bar_index がポイントしている I/O またはメモリアドレスで開始するアドレステストを実行して、PIO デザインの FPGAブロック RAM アドレスバスインターフェイスが正しく接続されているかどうかをテストします。

しっかりとテストを実行するには、PIO デザインで使用されている各ブロック RAM に対し 1 回ずつ、このタスクを 4 回呼び出します。さらに、 nBytes 入力で個々のブロック RAM の全体的なサイズを指定する必要があります。

TSK_MEM_TEST_DEVICE bar_indexnBytes

2:031:0

入力 nBytes で指定された範囲で、入力 bar_index によりポイントされているブロック RAM で始まるすべてのビットに対し、インクリメント /デクリメントテストを実行することによって、PIO デザインの FPGA ブロック RAM の各ビットの整合性をテストします。

しっかりとテストを実行するには、PIO デザインで使用されている各ブロック RAM に対し 1 回ずつ、このタスクを 4 回呼び出します。さらに、 nBytes 入力で個々のブロック RAM の全体的なサイズを指定する必要があります。





TSK_RESET 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_classtdepattrlengthcompleter_idcompleter_statusbcmbyte_countrequester_idtagaddress_low

2:0--

1:010:015:02:0-

11:015:07:06:0

ステータスを予期

traffic_class、 td、 ep、 attr、 length、payload が一致するデータ付きのコンプリーション TLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。

TSK_EXPECT_CPL traffic_classtdepattrcompleter_idcompleter_statusbcmbyte_countrequester_idtagaddress_low

2:0--

1:015:02:0-

11:015:07:06:0


traffic_class、 td、 ep、 attr、 length が一致するデータなしのコンプリーション TLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。

TSK_EXPECT_MEMRD traffic_classtdepattrlengthrequester_idtaglast_dw_befirst_dw_beaddress

2:0--

1:010:015:07:03:03:029:0


ヘッダーフィールドが一致する 32ビットのアドレスメモリ読み出しTLP を待ちます。

正しく完了すると 1 が返され、それ以外の場合は 0 が返されます。このタスクは、バスマスターデザインと併用する場合にのみ使用できます。





TSK_EXPECT_MEMRD64 traffic_classtdepattrlengthrequester_idtaglast_dw_befirst_dw_beaddress

2:0--

1:010:015:07:03:03:061:0


ヘッダーフィールドが一致する 64ビットのアドレスメモリ読み出しTLP を待ちます。正しく完了すると1 が返され、それ以外の場合は 0 が返されます。

このタスクは、バスマスターデザインと併用する場合にのみ使用できます。

TSK_EXPECT_MEMWR traffic_classtdepattrlengthrequester_idtaglast_dw_befirst_dw_beaddress

2:0--

1:010:015:07:03:03:029:0


ヘッダーフィールドが一致する 32ビットのアドレスメモリ書き込みTLP を待ちます。正しく完了すると1 が返され、それ以外の場合は 0 が返されます。


TSK_EXPECT_MEMWR64 traffic_classtdepattrlengthrequester_idtaglast_dw_befirst_dw_beaddress

2:0--

1:010:015:07:03:03:061:0


ヘッダーフィールドが一致する 64ビットのアドレスメモリ書き込みTLP を待ちます。正しく完了すると1 が返され、それ以外の場合は 0 が返されます。


TSK_EXPECT_IOWR tdeprequester_idtagfirst_dw_beaddressdata

--

15:07:03:031:031:0


ヘッダーフィールドが一致する I/O書き込み 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) : エンドポイントのサンプルデザイン」を参照してください。

デザインのシミュレーション

Mentor Graphics Questa Sim シミュレータを使用するシミュレーションをサポートするために、シミュレーションスクリプト (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) のステートに関連付けられたさまざまなタイムアウトがあります。コアは、タイムアウトを設定できない RecoverySpeed_1 LTSSM ステートを除いて、シミュレーションで 256 の係数でこれらのタイムアウトを設定します。

波形ダンピング

シミュレータ波形のダンピングの詳細は、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900)[参照 12] を参照してください。

出力のログ

テストベンチはメッセージを出力し、シミュレーションログに記録されます。このログには次のものが発生した時間が記録されています。

• 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 への移行Vivado Design Suite への移行方法については、『ISE から Vivado Design Suite への移行ガイド』 (UG911) [参照 13] を参照してください。

Vivado Design Suite でのアップグレードこのセクションでは、Vivado Design Suite でこの IP コアの新版にアップグレードする際の、ユーザーロジックおよびポートの変更について説明します。

パラメーターの変更点

図 A-1 に、新版コアのパラメーターの変更点をまとめています。

表 A-1 : パラメーターの変更点

# ユーザーパラメーター名表示名

新規/変更/削除

詳細デフォルト値

1 silicon_rev [Silicon Revision] 削除

必要なくなったため削除されたパラメーターです。このシリコンリビジョンオプションは Vivado GUI から選択する必要があります。

該当なし

2RM_PPM_OFFSET

[PPM offset between receiverand transmitter] 新規

受信データと送信データ間におけるPPM のオフセットを指定します。

0

3 RM_SSC_PPM [Spread spectrum clocking] 新規PPM でのスペクトラム拡散クロックの変調を指定します。

0

4 INS_LOSS_NYQ[Insertion loss at Nyquist (dB)] 新規

ナイキスト周波数でのトランスミッターからレシーバーの挿入ロスを示します (dB)。

20

5mcap_enablement

[Tandem Configuration] 新規利用可能な Tandem コンフィギュレーションを有効にします。

None




付録 A : 移行およびアップグレード

ポートの変更点

図 A-2 のポートは、 [GT Channel DRP] オプションが TRUE に設定されている場合に有効になります。

図 A-3 のポートは、 [Tandem Configuration] オプションが None 以外に設定されている場合に有効になります。

6en_ext_ch_gt_drp

[GT Channel DRP] 新規オンの場合、GT チャネル DRP インターフェイスが有効になります。

False

7ext_startup_primitive

[Use an external STARTUP primitive] 新規

オンになっていない場合は、TPROM または TPCIe が選択されている場合に IP内部に STARTUP ブロックが生成されます。

False

8en_gt_selection

[Enable GT Quad Selection] 新規オンの場合、異なる PCIE ブロック用に異なる GTH クワッドを選択する機能が有効になります。

False

9 select_quad [GT Quad] 新規対象となる有効な GTH クワッドを示します。

GTH_Quad_224

表 A-1 : パラメーターの変更点 (続き)

# ユーザーパラメーター名表示名

新規/変更/削除

詳細デフォルト値

表 A-2 : [GT Channel DRP] オプションで有効になるポート

ポート方向幅

ext_ch_gt_drpaddr I 72 ビット

ext_ch_gt_drpen I 8 ビット

ext_ch_gt_drpdi I 128 ビット

ext_ch_gt_drpdo O 128 ビット

ext_ch_gt_drprdy O 8 ビット

ext_ch_gt_drpwe I 8 ビット

表 A-3 : [Tandem Configuration] オプションで有効になるポート

ポート方向幅

cap_gnt I 2 ビット

cap_rel I 1 ビット

cap_req O 1 ビット





7 シリーズ Gen2 コアから UltraScale アーキテクチャベースの Gen3 コアへの移行このセクションでは、 7 シリーズ Gen2 コアから UltraScale® アーキテクチャベース Gen3 コアへの移行ガイドを提供します。

注記 : 7 シリーズ Gen3 コアのインターフェイスは、 UltraScale アーキテクチャベース Gen3 コアのインターフェイスと同じです。

図 1-1 に、 AXI4 Streaming TX および RX インターフェイスを示します。

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]m_axis_cq_tdata[78:75]

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 に接続可能



rx_is_eof [4:0] m_axis_cq_tlastm_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_tstrb m_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-7 : AXI4-Stream RC インターフェイス信号のマッピング (続き)


AXI4-Stream (強化型) RC インターフェイス名

異なる点

表 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] Poisoned Completion

データバス上にディスクリプターが存在する場合のみ有効 (is_sof0/is_sof1=1)

m_axis_rx_tuser[9:2] rx_bar_hit[7:0] N/A (CQ インターフェイスを参照)

N/A N/A



rx_is_sof[4:0] m_axis_rc_tuser[32]m_axis_rc_tuser[33]

(256 ビットでストラドルが有効な場合のみ)

is_sof_0is_sof_1

• 256 ビット RC インターフェイスにはストラドルオプションがあります。このオプションを有効にすると、コアは、同じビート内に 2 つのコンプリーション TLP をストラドルできます。

• is_sof_1 は、 256 ビットインターフェイスでストラドルオプションが有効な場合のみ使用されます。





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 信号バスのマッピングを示します。



rx_is_eof [4:0] m_axis_rc_tuser[37:34]m_axis_rx_tuser[41:38]

(256 ビットでストラドルが有効な場合のみ)

Is_eof_0[3:0]Is_eof_1[3:0]

is_eof_1 は、 256 ビットインターフェイスでストラドルオプションが有効な場合のみ使用されます。

同等信号なし m_axis_rc_tuser[74:43] Parity

表 A-9 : m_axis_rx_tuser の RC インターフェイス信号 (続き)

AXI4-Stream 受信インターフェイス名

ニーモニックAXI4-Stream コンプリーター

リクエストインターフェイス名ニーモニック注記

表 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_cc_tdata[28:16]「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 NA なし

tx_cfg_gnt NA なし

表 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





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 NA NA 同等信号なし

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 NA この機能は存在しない

tx_cfg_gnt NA この機能は存在しない

表 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 NA NA 同等信号なし

s_axis_tx_tuser[2] t_src_dsc s_axis_rq_tuser[11] Discontinue 同等

機能





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

表 A-17 では、コアが提供するその他のインターフェイスについて説明しています。

表 A-17 : コアが提供するその他のインターフェイス

インターフェイス説明注記

Transmit Flow Control (送信フロー制御)

コアが提供するフロー制御情報を要求するためにユーザーアプリケーションが使用します。

コアへのフロー制御入力の設定に基づいて、このインターフェイスはユーザーアプリケーションに次を提供します。

• ポステッド /ノンポステッドヘッダーフロー制御クレジット

• ポステッド /ノンポステッドデータフロー制御クレジット

• コンプリーションヘッダーフロー制御クレジット

• コンプリーションデータフロー制御クレジット

類似機能

Configuration Management (コンフィギュレーション管理)

コンフィギュレーション空間レジスタの読み出しおよび書き込みに使用します。

類似機能

Configuration Status (コンフィギュレーションステータス)

コアのコンフィギュレーション状況を示す情報 (ネゴシエートされたリンク幅やスピード、コアの電力ステート、コンフィギュレーションエラー ) を提供します。

コンフィギュレーション専用レジスタのポートと類似機能

Configuration Received Message (コンフィギュレーション受信メッセージ)

リンクからのデコード可能なメッセージ、データに関連するパラメーター、受信されたメッセージタイプのロジックを示します。

受信メッセージ TLP のステータスポートと類似機能

Configuration Transmit Message (コンフィギュレーション送信メッセージ)

ユーザーアプリケーションがコアへメッセージを送信する場合に使用されます。ユーザーアプリケーションが送信メッセージタイプとデータ情報をコアへ提供し、それに対してDone 信号で応えます。

Per Function Status (ファンクションごとのステータス)

選択したファンクションを介して、ユーザーアプリケーションからのリクエストを受けてステータスデータを提供します。

エラーレポーティングポートと類似機能

Configuration Control (コンフィギュレーション制御)

ユーザーアプリケーションとコア間でさまざまな情報を送受信可能にします。ユーザーアプリケーションはこのインターフェイスを使用して次を行います。

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

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

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

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

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

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

パワーマネージメントポートと類似機能

Configuration Interrupt Controller (コンフィギュレーション割り込みコントローラー )

ユーザーアプリケーションがレガシ PCIe 割り込み、 MSI 割り込み、または MSI-X 割り込みをセットできます。コアは、送信されたコンフィギュレーション割り込みに割り込みステータス、およびエラー信号を提供します。

割り込みの生成およびステータスポートと類似機能

Configuration Extended (コンフィギュレーション拡張)

外部にコンフィギュレーションレジスタが実装されている場合、コアがコンフィギュレーション情報をユーザーアプリケーションへ送信することが可能になります。

Received Configuration TLP のステータスポートと類似機能





UltraScale アーキテクチャ PCI Express デザインのパッケージ移行UltraScale アーキテクチャは、同じパッケージフットプリントを共有する多くのデバイスを提供しています。この移行パスによって、デバイス間でのデザインの移行が簡単に行えるため、デザインサイズの変更が可能になり、またより多くの DSP ブロックが必要になる場合は Virtex® から Kintex® へ移行するなど、特定の機能を充実させることが可能になります。

ほとんどの PCI Express コンフィギュレーションは 1 つのパッケージで簡単に移行できますが、特定 PCI Express インプリメンテーションの移行が不可能なデザインおよび設定もあります。このセクションでは、デバイス間で自由に移行できる PCI Express デザインの作成方法を説明すると同時に、移行できないピンの割り当てについても説明します。

UltraScale ファミリ用の総合的なピンの割り当て方法の詳細は、『UltraScale アーキテクチャ PCB デザインユーザーガイド』 (UG583) [参照 7] を参照してください。

配置規則

Vivado IP カタログから提供される UltraScale Architecture 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 の位置を推奨しています。 GHT の位置は変更できますが、その場合、タイミングクロージャの達成を保証できません。

Vivado 2014.3 ツールのリリース以降、デザインで使用する GT の位置をより柔軟に選択できるようになりました。ユーザーは次を選択できます。

• PCIe ブロックの位置、およびレーン 1 が配置されている GTH クワッドの位置

• GT クワッドの位置 (PCIe ブロックより 1 クロック領域上、同じ領域、または 1 クロック領域下)

クワッドの位置を選択すると、残りの GHT の位置は選択したリンク幅に基づいて制約されます。利用可能な GTH は、SLR の境界や結合されていない GT の影響を受けます。 x8 リンク幅が選択されている場合、使用する 2 つの GTH は隣接配置する必要があります。





図 A-1 では、 x8 PCIe リンク幅の場合に、それぞれの初の GTH クワッドの位置にどのようにレーンが配置されているかを示しています。

X-Ref Target - Figure A-1

図 A-1 : GTH クワッドの位置





スタックドシリコンインターコネクト (SSI) デバイス

SSI デバイスを使用する場合、 PCI Express ハードブロックおよびこのブロックに接続された GTH クワッドは、同じSRL (Super Logic Region) に配置する必要があります。

図 A-2 に、 A2377 パッケージの XCVU125 デバイスを示します。ロケーション Y2 の PCIe ブロックがバンク 228 のGTH を選択することは、 SLR 境界を超えてしまうため不可能です。


図 A-2 : A2377 パッケージの XCVU125 デバイス





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 : 移行の例





Tandem コンフィギュレーションの移行

同じパッケージの異なるデバイス間で Tandem コンフィギュレーションデザインを移行する手順は非常にシンプルです。タンデム PCIe をサポートする PCI Express ブロックが選択されていることを確認してください。

重要 : タンデム PCIe は、各デバイスで 1 PCIe ハードブロックに対してのみサポートされます。

タンデムをサポートする PCI Express ブロックのロケーションおよび専用リセットピンの一覧は、表 3-2 を参照してください。




付録 B

コアのピン配置この付録では、この IP コアのデフォルトのピン配置ロケーション一覧を提供します。その他に選択可能なロケーションについては、付録 A の「UltraScale アーキテクチャ PCI Express デザインのパッケージ移行」を参照してください。

Kintex UltraScale デバイスコアのピン配置表 B-1 に、 Kintex® UltraScale™ デバイスコアのピン配置の一覧を提供します。

表 B-1 : Kintex Ultrascale コアのピン配置

パッケージデバイス PCIe ブロックレーン X1 x2 x4 x8

FBVA676FBVA900

XCKU035XCKU040

X0Y0

レーン 0 X0Y7 X0Y7 X0Y7 X0Y7

レーン 1 X0Y6 X0Y6 X0Y6

レーン 2 X0Y5 X0Y5


レーン 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 : コアのピン配置

FFVA1156

XCKU035XCKU040

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

XCKU060XCKU075

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

表 B-1 : Kintex Ultrascale コアのピン配置 (続き)






FFVA1156

(続き )

XCKU040

X0Y2

レーン 0 X0Y19 X0Y19 X0Y19

サポートされないレーン 1 X0Y18 X0Y18

レーン 2 X0Y17

レーン 3 X0Y16

XCKU060XCKU075

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16

FFVA1517

XCKU060XCKU075

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

XCKU060 X0Y2

レーン 0 X1Y19 X1Y19 X1Y19


レーン 2 X1Y17

レーン 3 X1Y16







FFVA1517

(続き )XCKU075

X0Y2 (x8) モード

レーン 0 X1Y23 X1Y23 X1Y23 X1Y23

レーン 1 X1Y22 X1Y22 X1Y22



レーン 4 X1Y19

レーン 5 X1Y18

レーン 6 X1Y17

レーン 7 X1Y16

X0Y2 (x4) モード

レーン 0 X1Y19 X1Y19 X1Y19

適用外レーン 1 X1Y18 X1Y18

レーン 2 X1Y17

レーン 3 X1Y16

X0Y3

レーン 0 X1Y35 X1Y35 X1Y35 X1Y35

レーン 1 X1Y34 X1Y34 X1Y34



レーン 4 X1Y31

レーン 5 X1Y30

レーン 6 X1Y29

レーン 7 X1Y28

FFVB1760 XCKU075 X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0







FFVB1760

(続き )

XCKU075

(続き )

X0Y1

レーン 0 X1Y15 X1Y15 X1Y15 X1Y15

レーン 1 X1Y14 X1Y14 X1Y14



レーン 4 X1Y11

レーン 5 X1Y10

レーン 6 X1Y9

レーン 7 X1Y8

X0Y2

レーン 0 X1Y23 X1Y23 X1Y23 X1Y23

レーン 1 X1Y22 X1Y22 X1Y22



レーン 4 X1Y19

レーン 5 X1Y18

レーン 6 X1Y17

レーン 7 X1Y16

X0Y3

レーン 0 X1Y31 X1Y31 X1Y31 X1Y31

レーン 1 X1Y30 X1Y30 X1Y30



レーン 4 X1Y27

レーン 5 X1Y26

レーン 6 X1Y25

レーン 7 X1Y24

FLVA1517XCKU100XCKU115

X0Y0





レーン 4 X1Y3

レーン 5 X1Y2

レーン 6 X1Y1

レーン 7 X1Y0







FLVA1517

(続き )

XCKU100XCKU115

(続き )

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







FLVD1924XCKU100XCKU115

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







FLVF1924FLVD1517

XCKU100XCKU115

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







FLVF1924FLVD1517

(続き )

XCKU100XCKU115

(続き )

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

FLVB1760XCKU100XCKU115

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







FLVB1760

(続き )

XCKU100XCKU115

(続き )

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

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







FLVA2104

(続き )

XCKU115

(続き )

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







FLVB2104

(続き )

XCKU115

(続き )

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 デバイスコアのピン配置表 B-2 に、 Kintex® UltraScale デバイスコアのピン配置の一覧を提供します。

表 B-2 : Virtex UltraScale コアのピン配置


FFVC1517

XCVU065XCVU080XCVU095

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

XCVU080XCVU095

X0Y2

レーン 0 X0Y19 X0Y19 X0Y19


レーン 2 X0Y17

レーン 3 X0Y16





FFVA2104XCVU080XCVU095

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-2 : Virtex UltraScale コアのピン配置 (続き)






FFVB2104FFVB1760FFVD1517

XCVU080XCVU095

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







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







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







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




レーン 4 X0Y31

レーン 5 X0Y30

レーン 6 X0Y29

レーン 7 X0Y28

X0Y3

レーン 0 X0Y39 X0Y39 X0Y39 X0Y39

レーン 1 X0Y38 X0Y38 X0Y38









FLVB2104FLVC2104FLVD1517

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







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







FLGA2577

(続き )

XCVU190

(続き )

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

FLGB2104XCVU160XCVU190

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







FLGB2104

(続き )

XCVU160XCVU190

(続き )

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

FLGC2104XCVU160XCVU190

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







FLGC2104

(続き )

XCVU160XCVU190

(続き )

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







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







FLGB2377

(続き )

XCVU440

(続き )X0Y5

レーン 0 X0Y59 X0Y59 X0Y59


レーン 2 X0Y57

レーン 3 X0Y56

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






付録 C

受信されるコンプリーションに対する受信バッファー空間の管理

『PCI Express® Base Specification』 [参照 2] では、すべてのエンドポイントは受信したコンプリーションに対して無限のフロー制御クレジットをリンクパートナーに出力することが規定されています。これは、エンドポイントがコンプリーション応答を受け入れるスペースがある場合にのみ、ノンポステッドリクエストを送信する、ということです。ここでは、この要件を満たすために、ユーザーアプリケーションで UltraScale Architecture Gen3 Integrated Block forPCIe コアの受信バッファー空間を管理する方法について説明します。

一般的な注意事項と概念

コンプリーション空間

表 C-1 では、コアによって予約されている受信バッファーのコンプリーション空間が定義されています。これらの値は、コアの Capability Max Payload Size (機能大のペイロードサイズ) の設定と選択されたパフォーマンスレベルによって異なります。値はクレジット数で、 10 進数で表記されます。

最大リクエストサイズ

メモリ読み出しは、 Max_Request_Size で指定された値を超える値は要求できません。これは、表 C-2 で定義されるように、コンフィギュレーションビット cfg_dcommand[14:12] で指定されます。ユーザーアプリケーションがMax_Request_Size 値を読み出さない場合は、デフォルト値の 128 バイトが使用されます。

表 C-1 : 受信バッファーのコンプリーション空間

Capability Max Payload Size (バイト )

パフォーマンスレベル : Good パフォーマンスレベル : High

CPH CPD CPH CPD

128 64 7,936B 64 15,872B

256 64 7,936B 64 15,872B

512 64 7,936B 64 15,872B

1024 64 7,936B 64 15,872B




付録 C : 受信されるコンプリーションに対する受信バッファー空間の管理

読み出しコンプリーションの境界

1 回のメモリ読み出しには複数のコンプリーションで応答できます。これらをまとめると、要求されたデータがすべて返されます。パケットヘッダーオーバーヘッドに余裕を持たせるため、ユーザーアプリケーションは、返される可能性のあるコンプリーションの大数分、スペースを用意しておく必要があります。

このプロセスを簡単にするため、それぞれが自然にアライメントされ読み出しコンプリーション境界 (RCB) で開始および終了するように (元のリクエストの開始/終了アドレスを提供する場合を除く )、『PCI Express Base Specification』では、すべてのコンプリーションパケットの長さを量子化しています。 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 バイトを使用する必要があります。

ノンポステッドリクエストに必要なコンプリーションクレジット数を計算する際は、コンプリーション応答が必要になる可能性のある、 RCB で分けられたブロック数を決定します。これは、必要なコンプリーションヘッダークレジットの数と同じです。

表 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





高性能アプリケーションの重要事項

1 つのリクエストに応答するコンプリーションの大数をユーザーアプリケーションが計算することによって、プログラムされた RCB 値を使用できますが、高性能メモリコントローラーには、大規模な読み出しリクエストの応答に際して、 RCB サイズのブロックを組み合わせてそのリンクの Max_Payload_Size 値またはそれに近いサイズのコンプリーションにできるオプション機能があります。ホスト CPU のメモリコントローラーでこの機能がサポートされている場合は、使用を推奨しています。RCB 値の整数倍 (>1) でのコンプリーション応答をベースとするデータ送受信の場合、 PCI Express インターフェイスの使用効率とペイロードの効率が非常に高くなり、またエンドポイントレシーバーのコンプリーション空間の使用効率も高くなります。

コンプリーション空間の管理方法ユーザーアプリケーションには、表 C-4 に示す、受信バッファーのコンプリーション空間を管理する 5 つの方法の中から 1 つを選択できます。ここでは、これらの方法を便宜上 LIMIT_FC、 PACKET_FC、 RCB_FC、および DATA_FCと呼ぶことにします。これらの方法にはそれぞれメリットとデメリットがあり、ユーザーアプリケーションを開発する際に考慮する必要があります。

LIMIT_FCLIMIT_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)

表 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 よりも複雑なユーザーロジックになります。





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_FCPACKET_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_FCRCB_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_FCDATA_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 Architecture Gen3 Integrated Block for PCIe を使用した設計およびデバッグでヘルプが必要な場合は、ザイリンクスサポートウェブページから製品の資料、リリースノート、アンサーなどを参照するか、テクニカルサポートでケースを開いてください。

資料

この製品ガイドは UltraScale Architecture Gen3 Integrated Block for PCIe に関する主要資料です。このガイド並びに全製品の設計プロセスをサポートする資料はすべて、ザイリンクスサポートウェブページ (http://japan.xilinx.com/support)またはザイリンクスの Documentation Navigator から入手できます。

Documentation Navigator は、ダウンロードページ (http://japan.xilinx.com/download) の [デザインツール] タブからダウンロードできます。このツールの詳細および機能は、インストール後にオンラインヘルプを参照してください。

アンサー

アンサーには、よく発生する問題についてその解決方法、およびザイリンクス製品に関する既知の問題などの情報が記載されています。アンサーは、ユーザーが該当製品の新情報にアクセスできるよう作成および管理されています。

このコアに関するアンサーの検索には、ザイリンクスサポートウェブページにある検索ボックスを使用します。より的確な検索結果を得るには、次のようなキーワードを使用してください。

• 製品名

• ツールで表示されるメッセージ

• 問題の概要

検索結果は、フィルター機能を使用してさらに絞り込むことができます。

MIS に関するマスターアンサー : UltraScale Architecture Gen3 Integrated Block for PCIe

AR : 57945


japan.xilinx.com/support


japan.xilinx.com/download


http://japan.xilinx.com/support/answers/57945.htm



付録 D : デバッグ

テクニカルサポート

ザイリンクスは、製品資料の説明に従って使用されている LogiCORE™ IP 製品に対するテクニカルサポートをjapan.xilinx.com/support で提供しています。資料で定義されていないデバイスにインプリメントしたり、許容されている範囲を超えてカスタマイズしたり、あるいは「DO NOT MODIFY」とされているデザインセクションに変更を加えたりした場合、タイミング、機能、製品サポートは保証されません。

テクニカルサポートへのお問い合わせ方法は、次のとおりです。

1. http://japan.xilinx.com/support にアクセスします。

2. 「その他のリソース」の下の [ウェブケースを作成] リンクをクリックし、ウェブケースを開きます。

ウェブケースを作成する際は、次の情報を含めてください。

• パッケージおよびデバイススピードグレードを含むターゲット FPGA の情報

• 該当するすべてのザイリンクスデザインツールとシミュレータのソフトウェアバージョン

• 問題によっては、ファイルの追加を求められる場合があります。ウェブケースに含める特定ファイルについては、この資料の関連セクションを参照してください。

注記 : すべての問題がウェブケースの利用対象になるわけではありません。ウェブケースツールにログインしてサポートオプションを確認してください。


http://japan.origin.xilinx.com/support/clearexpress/websupport.htm





付録 E

その他のリソースおよび法的通知

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

参考資料次の資料は、この製品ガイドの補足資料として役立ちます。

注記 : 日本語版のバージョンは、英語版より古い場合があります。

1. 『AMBA AXI4-Stream Protocol Specification』

2. PCI-SIG 仕様 (www.pcisig.com/specifications)

3. 『Virtex-7 FPGA Integrated Block for PCI Express 製品ガイド』 (PG023)

4. 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570 : 英語版、日本語版)

5. 『Kintex UltraScale アーキテクチャデータシート : DC 特性および AC スイッチ特性』 (DS892 : 英語版、日本語版)

6. 『Virtex UltraScale アーキテクチャデータシート : DC 特性および AC スイッチ特性』 (DS893 : 英語版、日本語版)

7. 『UltraScale アーキテクチャ PCB デザインユーザーガイド』 (UG583 : 英語版、日本語版)

8. 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896)

9. 『Vivado Design Suite ユーザーガイド : IP インテグレーターを使用した IP サブシステムの設計』 (UG994)

10. 『Vivado Design Suite ユーザーガイド : 入門』 (UG910)

11. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903)

12. 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900)

13. 『ISE から Vivado Design Suite への移行ガイド』 (UG911)

14. 『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908)

15. 『ATX Power Supply Design Guide』


http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf


www.pcisig.com/specifications

http://japan.xilinx.com/cgi-bin/docs/ipdoc?c=pcie3_7x;v=latest;d=pg023_v7_pcie_gen3.pdf

http://www.xilinx.com/support/documentation/data_sheets/ds892-kintex-ultrascale-data-sheet.pdf

http://www.xilinx.com/support/documentation/data_sheets/ds893-virtex-ultrascale-data-sheet.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug583-ultrascale-pcb-design.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug994-vivado-ip-subsystems.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf

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

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug911-vivado-migration.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug570-ultrascale-configuration.pdf

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0051a/index.html

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug570-ultrascale-configuration.pdf

http://www.formfactors.org/developer/specs/ATX12V_PSDG_2_2_public_br2.pdf

http://japan.xilinx.com/support/documentation/data_sheets/j_ds892-kintex-ultrascale-data-sheet.pdf

http://japan.xilinx.com/support/documentation/data_sheets/j_ds893-virtex-ultrascale-data-sheet.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug583-ultrascale-pcb-design.pdf



付録 E : その他のリソースおよび法的通知

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

日付バージョン内容

2016 年 8 月 18 日 3.1 • 表 2-4、表 2-6、表 2-8、表 2-10 それぞれの「parity」信号の説明で、「偶数パリティ」を「奇数パリティ」に訂正。

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 に関する説明を追加。

• Tandem コンフィギュレーションに関する情報をアップデート。

• Cadence Incisive Enterprise Simulator (IES) および Synopsys Verilog Compiler Simulator (VCS) のサポートを追加。

• デバイスコアのピン配置をアップデート。

2014 年 10 月 1 日 3.1 • コア v3.1 に合わせてアップデート。

• Tandem コンフィギュレーションに関する情報をアップデート。

• UltraScale アーキテクチャデザインのパッケージ移行情報を追加。

2014 年 6 月 4 日 3.0 • デバイス情報をアップデート。

2014 年 4 月 2 日 3.0 • ブロックセレクションをアップデート。

• コアのピン配置情報をアップデート。

• 共有ロジックの情報をアップデート。

2013 年 12 月 18 日 2.0 初版




付録 E : その他のリソースおよび法的通知

法的通知The information disclosed to you hereunder (the "Materials") is provided solely for the selection and use of Xilinx products. To the maximum extentpermitted by applicable law: (1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES ANDCONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY,NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort,including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connectionwith, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage(including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if suchdamage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct anyerrors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute,or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of Xilinx's limited warranty,please refer to Xilinx's Terms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and supportterms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any applicationrequiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx'sTerms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos.

© Copyright 2013–2015 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brandsincluded herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners.

This document contains preliminary information and is subject to change without notice. Information provided herein relates to products and/orservices not yet available for sale, and provided solely for information purposes and are not intended, or to be construed, as an offer for sale or anattempted commercialization of the products and/or services referred to herein.

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。

mailto:[email protected]

http://www.xilinx.com/legal.htm#tos

http://www.xilinx.com/legal.htm#tos



ultrascale architecture gen3 integrated block for pci ... · ultrascale architecture gen3...

Documents