インテル® アクセラレーション・スタック (インテル® Xeon® CPU&FPGA対応) コア・キャッシュ・インターフェイス (CCI-P) リファレンス・マニュアル
1. アクセラレーション・スタック (インテル® Xeon® CPU & FPGA対応) コア・キャッシュ・インターフェイス (CCI-P) リファレンス・マニュアル
1.1. 本リファレンス・マニュアルについて
1.1.1. 本リファレンス・マニュアルのご利用にあたり
ハードウェアAFUは、CCI-P仕様に準拠するようにデザインする必要があります。
1.1.2. 規則
規則 | 説明 |
---|---|
# | コマンドに先行し、そのコマンドがルートとして入力されることを示します。 |
$ | ユーザーとして入力されるコマンドを示します。 |
このフォント (This font) で書かれている文字 | ファイル名、コマンド、およびキーワードはこのフォントで表示されます。長いコマンドラインもこのフォントで表示され、次の行に折り返されている場合がありますが、改行はコマンドの一部ではありません。Enterキーを押さないでください。 |
<variable_name> | プレースホルダー・テキストを示し、山括弧の間に表示されます。このテキストは適切な値に置き換える必要があります。山括弧は入力しないでください。 |
1.1.3. 関連資料
資料 | 説明 |
---|---|
Intel® Software Developers Manual |
この資料には、 Intel® 64 and IA-32 Architecture Software Development Manualの3つのVolumeすべてが含まれます (Basic Architecture: 注文番号253665、Instruction Set Reference A-Z: 注文番号325383、System Programming Guide: 注文番号325384)。デザインニーズを評価する際は、この3つのVolumeをすべて参照ください。 |
Intel® Virtualization Technology for Directed I/O Architecture Specification |
このドキュメントは、ダイレクトI/O向けインテル・バーチャライゼーション・テクノロジー (ダイレクトI/O向けインテルVT) について説明しています。このテクノロジーは、インテルのプラットフォーム仕様に準拠するインテル・プロセッサーおよびコア・ロジック・チップセットを使用するプラットフォームに適用されるため、I/Oバーチャライゼーションをサポートするコンポーネントに関して具体的に説明します。 |
1.1.4. アクセラレーション・スタック (インテル Xeon® CPU & FPGA対応) コア・キャッシュ・インターフェイス (CCI-P) リファレンス・マニュアルの頭字語一覧
頭字語 | 展開 | A/B | 説明 |
---|---|---|---|
AF | アクセラレーター・ファンクション | A、B | FPGAロジックに実装されるコンパイル済みのハードウェア・アクセラレーター・イメージで、アプリケーションを高速化します。 |
AFU | アクセラレーター・ファンクショナル・ユニット | A、B | FPGAロジックに実装されるハードウェア・アクセラレーターで、CPUからアプリケーションの演算動作をオフロードし、パフォーマンスを向上させます。 |
BBB | インテル® FPGAベーシック・ビルディング・ブロック | A、B |
インテル® FPGAベーシック・ビルディング・ブロックは、CCI-Pブリッジと接続可能なコンポーネントとして定義されます。 詳細は、Basic Building Blocks (BBB) for OPAE-managed Intel FPGAsのWebページを参照ください。 |
CA | キャッシュ・エージェント | A |
キャッシュ・エージェント (CA) は、システム内のコヒーレント・メモリーに対して読み出しおよび書き込みのリクエストを行います。また、システム内のほかのインテル・ウルトラ・パス・インターコネクト (インテル UPI) エージェントが生成したスヌーピングにも対応します。 |
CCI-P | コア・キャッシュ・インターフェイス | A、B | CCI-Pは、AFUがホストと通信するために使用する標準インターフェイスです。 |
CL | キャッシュライン | A、B | 64バイトのキャッシュライン。 |
DFL | デバイス・フィーチャー・リスト | A、B | DFLは、機能などのグループ化と、それらを列挙するための構造を定義します。 |
FIM | FPGAインターフェイス・マネージャー | A、B |
FPGAインターフェイス・ユニット (FIU) および、メモリーやネットワークなどで使用する外部インターフェイスを含むFPGAハードウェアです。 アクセラレーター・ファンクション (AF) は、ランタイムにFIMと接続します。 |
FIU | FPGAインターフェイス・ユニット | A、B | FIUはプラットフォーム・インターフェイス層であり、PCIe、UPIなどのプラットフォーム・インターフェイスと、CCI-PなどのAFU側のインターフェイスの間のブリッジとして機能します。 |
KiB | 1024バイト | A、B |
KiBという用語は1024バイトを表し、KBは1000バイトを表します。メモリーについて述べる場合はKBが一般的に使用され、KiBは暗黙的に示されます。クロック周波数について述べる場合はkHzが使用され、その場合のKは1000です。 |
Mdata | メタデータ | A、B |
これはユーザー定義のフィールドであり、TxヘッダーからRxヘッダーに渡されます。トランザクションIDまたはチャネルIDで、リクエストにタグを付けるために使用されます。 |
RdLine_I | 無効な読み出しライン | A、B |
FPGAのキャッシュヒントがInvalid (無効) に設定されたメモリー読み出しリクエストです。このラインはFPGAにキャッシュされませんが、FPGAのキャッシュ・ポリューションを引き起こす可能性があります。 注: キャッシュタグは、インテル・ウルトラ・パス・インターコネクト (インテル UPI) 上の未処理のリクエストすべてのリクエストステータスを追跡します。そのため、完了時にRdLine_Iは無効とマークされますが、UPIでリクエストステータスを追跡するためにキャッシュタグを一時的に消費します。この動作はキャッシュラインのエビクションを引き起こし、キャッシュ・ポリューションが発生する場合があります。RdLine_Iを使用する利点は、これがCPUディレクトリーによって追跡されないことです。そのため、CPUからのスヌーピングを防ぎます。
注: キャッシュ機能は、FPGAを統合したインテル®
Xeon®プロセッサーにのみ適用されます。
|
RdLine-S | 共有される読み出しライン | A | FPGAのキャッシュヒントがShared (共有) に設定されたメモリー読み出しリクエストです。これを共有状態でFPGAキャッシュに保持する試みが行われます。 |
Rx | 受信 | A、B | AFUの視点からの受信または入力 |
SMBUS | システム管理バス | A | システム管理バス (SMBUS) インターフェイスは、アウトオブバンドの温度の監視、ブートストラップ・プロセス中のコンフィグレーションおよびプラットフォームのデバッグを目的とする動作を行います。 |
Tx | 送信 | A、B | AFUの視点からの送信または出力 |
Upstream | CPUに向かう方向 | A、B | CPUに向かう論理方向です。例えばアップストリーム・ポートは、CPUへ向かうポートです。 |
UMsg | CPUからAFUへの順序付けされていないメッセージ | A | 64バイトのペイロードの順序付けされていない通知です。 |
UMsgH | CPUからAFUへの順序付けされていないメッセージヒント | A | このメッセージは、後続するUMsgのヒントです。データペイロードはありません。 |
Intel® UPI | インテル・ウルトラ・パス・インターコネクト | A | インテル コアやその他のIP間の、インテル独自のコヒーレント・インターコネクト・プロトコルです。 |
WrLine_I | 無効な書き込みライン | A、B |
FPGAのキャッシュヒントがInvalid (無効) に設定されたメモリー書き込みリクエストです。FIUは、FPGAキャッシュにデータを保持することを意図せずにデータを書き込みます。 |
WrLine_M | 変更された書き込みライン | A |
FPGAのキャッシュヒントがModified (変更済み) に設定されたメモリー書き込みリクエストです。FIUはデータを書き込み、それを変更済みの状態でFPGAキャッシュに残します。 |
WrPush_I | 無効な書き込みプッシュ | A |
FPGAのキャッシュヒントがInvalid (無効) に設定されたメモリー書き込みリクエストです。FIUは、データをFPGAキャッシュに保持することを意図せずに、プロセッサーのラスト・レベル・キャッシュ (LLC) にデータを書き込みます。書き込み先のLLCはかならず、DRAMアドレスが属するプロセッサーに関連付けられたLLCです。 |
1.1.5. アクセラレーションの用語集
用語 | 略語 | 説明 |
---|---|---|
インテル® アクセラレーション・スタック (インテル® Xeon® CPU & FPGA対応) | アクセラレーション・スタック |
インテルFPGAと インテル® Xeon® プロセッサー間において最高のパフォーマンスをもたらす接続を可能にする一連のソフトウェア、ファームウェアおよびツールです。 |
インテル®FPGA プログラマブル・アクセラレーション・カード (インテル® FPGA PAC) | インテル® FPGA PAC |
インテル® FPGA PAC搭載の PCIe* アクセラレーター・カードです。 PCIe* バス上で インテル® Xeon® プロセッサーと接続するFPGAインターフェイス・マネージャー (FIM) を含みます。 |
FPGAを統合したインテル® Xeon® スケーラブル・プラットフォーム | FPGA統合プラットフォーム |
インテル® Xeon® とFPGAが1つのパッケージになったプラットフォームで、インテル・ウルトラ・パス・インターコネクト (UPI) を使用し一貫したメモリービューを共有します。 |
1.2. 概要
CCI-Pは、アクセラレーター・ファンクショナル・ユニット (AFU) のホスト・インターフェイス・バスであり、個別のヘッダーとデータワイヤーを備えます。これは、AFUをFPGA内のFPGAインターフェイス・ユニット (FIU) に接続するためのものです。このドキュメントでは、CCI-Pプロトコルと信号インターフェイスを定義します。これには、リクエストタイプ、ヘッダー・フォーマット、タイミング図、およびメモリーモデルの定義が含まれます。
- CCI-Pに準拠するAFUをデザインするために必要な必須AFUレジスター
- デバイス・フィーチャー・リスト (DFL)—モジュラーデザインおよび、ソフトウェアからのAFUフィーチャーの容易な列挙を促進するレジスター構成の標準
- インテル® FPGAベーシック・ビルディング・ブロック (BBB)—ハードウェア・モジュールとソフトウェア・モジュールで構成される再利用可能なFPGAライブラリーを定義するアーキテクチャー
CCI-Pは、PCIeやUPIなどのさまざまなプラットフォーム・インターフェイスの上に実装可能な抽象化レイヤーを提供します。それにより、CCI-Pに準拠するAFUの相互運用をプラットフォーム間で可能にします。
次の表は、AFUに向けたCCI-Pインターフェイス固有の機能をまとめています。
機能 | 説明 |
---|---|
MMIOリクエスト—AFU I/Oメモリーに対するCPUの読み出しおよび書き込み |
|
メモリーリクエスト |
メモリーに対するAFUの読み出しまたは書き込み
|
FPGAキャッシュヒント (FPGA統合プラットフォームのみ) |
AFUは、FIUに対して特定の状態でCLをキャッシュするようリクエストすることができます。VL0に向けられるリクエストの場合、FIUはヒントとしてリクエストされた状態でデータのキャッシュを試みます。VH0およびVH1でのキャッシュ・ヒント・リクエストは、WrPush_Iを除き無視されます。 注: キャッシュヒントは単なるヒントであり、最終的なキャッシュ状態を保証するものではありません。キャッシュヒントを無視することはパフォーマンスに影響しますが、機能的に影響はありません。
|
仮想チャネル (VC) |
AFUには、仮想チャネルとして物理リンクが提供されます。AFUは、各メモリーリクエストに対して仮想チャネルを選択できます。
|
UMsg (FPGA統合プラットフォームのみ) | CPUからAFUへの順序付けされていない通知です。
|
応答順序 | 順不同の応答 |
アップストリーム・リクエスト | 利用可 |
1.2.1. FPGAインターフェイス・マネージャー (FIM)
- FIU
- 外部メモリーと接続するためのEMIF
- 外部トランシーバー接続のためのHSSI
FIMの実装に関する特定の内容については、お使いのプラットフォームを参照ください。
FIUは、AFUとプラットフォーム間のブリッジのような役割を担います。図 1 は、PCIe、SMBus (管理性を向上するためのもの)、およびホストに対するUPIスタック全体とFIUの接続を表しています。FIMはまた、FPGA上のすべてのハードIP (PLLなど)、パーシャル・リコンフィグレーション (PR) エンジン、JTAGアトム、IO、温度センサーを所有します。FIMは起動時に最初にコンフィグレーションされ、プラットフォームの電源を再投入するまで持続しますが、AFUは動的にリコンフィグレーション可能です。インテルのパーシャル・リコンフィグレーション技術は動的なリコンフィグレーション機能を可能にし、AFUはパーシャル・リコンフィグレーション領域として定義され、FIMは静的領域として定義されます。AFUとFIU間のインターフェイスはホットプラグ機能を提供し、トラフィックの一時停止およびパーシャル・リコンフィグレーション後のAFUの再列挙を行います。
FIMは、プラットフォームの機能に応じて1つもしくは複数のインターフェイスをAFUに提供します。このドキュメントでは、AFUが インテル® Xeon® プロセッサーと通信するためのインターフェイスであるCCI-Pに焦点を当てています。CCI-PはダイレクトI/O向けインテル・バーチャライゼーション・テクノロジー (インテルVT-d) を使用し、アドレス空間の分離と保護を提供します。CCI-Pは、PCIeの機能に定義されているものと同じ保護を備えます。AFUは、PCIeの列挙およびVT-dの観点において単機能のデバイスです。
またFIUは場合によっては、エラー監視とレポート、電力と温度の監視、コンフィグレーション・ブートストラップ、ビットストリームのセキュリティー・フロー、リモートデバッグなどの管理性を向上させるための機能を実装し、データセンター環境でのFPGAの展開および管理を容易にします。また、FIUは一部の実装において、ボード管理コントローラー (BMC) とのアウトオブバンド通信インターフェイスを備えている場合があります。1.2.2. インテルFPGAインターフェイス・ユニット (FIU)
1.2.2.1. インテル FPGA PAC向けFIU
インテル® FPGA PACは、 インテル® Xeon® プロセッサーにPCIe物理リンクを介して接続します。図 2 の インテル® FPGA PAC FIUのブロック図は、CCI-PをPCIeリンクにマッピングするブロックのみを示しています。この図には、AFUに向かうボードローカルのメモリーのFIMブロックは示されていません。 インテル® FPGA PAC向けFIUは、1つの物理リンクをCCI-Pにマッピングするシンプルな機能を備えます。
インテル® FPGA PAC FIUは、CCI-P仮想チャネルのVH0およびVAをPCIeリンクにマッピングします。仮想オートチャネル (VA) は、任意のプラットフォームのすべての利用可能なチャネルにわたってリクエストを最適にマッピングし、最大の帯域幅を実現します。
仮想チャネルについての詳細は、「CCI-Pの機能の概要」の章を参照ください。ダウンストリームのPCIe制御パスは、FPGA管理エンジン (FME)、CCI-PポートおよびAFUにアドレスマッピングされます。
FMEは、AFUのエラー、パフォーマンス、電力、温度の監視およびパーシャル・リコンフィグレーションの機能を提供します。CCI-Pポートモジュールは、ポートごとのリセット、休止、エラーの監視および、ネットワーク経由でのSignal Tapを使用するリモートデバッグを実装します。
1.2.2.2. インテルFPGA統合プラットフォーム向けFIU
FPGA統合プラットフォームは、FPGAをプロセッサーに接続するリンクを3つ備えています。1つはインテルUPIコヒーレント・リンク、残りの2つはPCIe Gen3x8リンクです。これらの3つのリンクをCCI-PインターフェイスにマッピングするのはFIUの機能であり、それによってAFUは、3つのリンクの総帯域幅に等しい帯域幅を持つホスト・プロセッサーへの単一の論理通信インターフェイスを認識します。図 1 は、UPIおよびPCIeリンクのCCI-Pへのマッピングに関連するFIUロジックのみを示しています。
- 単一の論理アップストリーム・リンク: CCI-Pは、3つの物理リンクを4つの仮想チャネルにマッピングします (PCIe0をVH0、PCIe1をVH1、UPIをVL0、すべての物理リンクをVAに)。VAを使用しているAFUは物理リンクに依存せず、FPGAで利用可能なアップストリームの帯域幅全体を使用できる単一の論理リンクと接続します。VAは重み付きデマルチプレクサーを実装し、リクエストをすべての物理リンクにルーティングします。プラットフォームに依存しないAFUをデザインするには、VA仮想チャネルの使用が推奨されます。
- 単一の制御ポイント: FIUは、単一の制御インターフェイスをシステムのソフトウェア・スタックに登録します。ドライバーとFIUの相互通信はすべて、PCIe-0に向けられます。AFUはPCIe-0で検出され、列挙されます。
- 統一されたアドレス空間を提供するVT-dの単一ID: アップストリームのリクエストはすべて、単一の関数番号をアドレス変換に使用します。そのため、FPGAを統合したインテル® Xeon® スケーラブル・プラットフォームは、PCIe-0およびPCIe-1ルートポートでIOMMUを無効にし、代わりにIOMMUをFIUでインスタンス化します。このIOMMUは、すべての3つの物理リンクを介してアップストリームに向かうリクエストの変換に使用されます。
インテル® FPGA PACと同様に、FPGA統合プラットフォームもまた、FMEおよびCCI-Pポートで提供されるサービス一式を実装し、FPGAの展開および管理を行います。
1.2.2.3. FIU機能の比較
FIUの機能 | インテル® FPGA PACでサポートされる | FPGA統合プラットフォームでサポートされる |
---|---|---|
統一アドレス空間 | はい | |
AFU向けインテルVT-d | はい | |
パーシャル・リコンフィグレーション | はい | |
リモートデバッグ | はい | |
FPGAキャッシュサイズ | 該当なし | 128 KiB直接マッピング |
CCI-P | ||
メモリーマップドI/O (MMIO) 読み出しおよび書き込み | はい | |
CPUへのAFU割り込み | はい | いいえ |
CPUからAFUへのUMsg | いいえ | はい |
CCI-Pメモリーリクエスト | ||
データ転送サイズ | 64バイト (1 CL)、128バイト (2 CL)、256バイト (4 CL) | |
アドレス指定モード | 物理アドレス指定モード | |
アドレス指定幅 (CLにアライメントされたアドレス) | 42ビット | |
キャッシュヒント | いいえ | はい |
仮想チャネル | VA、VH0 | VA、VH0、VH1、VL0 |
1.2.3. メモリーおよびキャッシュ階層
CCI-Pプロトコルはキャッシュヒントのメカニズムを提供します。AFUに精通しているデベロッパーは、このメカニズムを使用しパフォーマンスを調整することができます。この章では、 インテル® FPGA PACおよびFPGA統合プラットフォームのメモリーとキャッシュ階層について説明します。CCI-Pが提供する制御メカニズムについては、次の「インテル FPGA PAC」と「FPGA統合プラットフォーム」の章で説明します。
インテル® FPGA PAC
- ホストメモリーと呼ばれている、プロセッサーのSDRAM (Synchronous Dynamic Random Access Memory)
- ローカルメモリーと呼ばれている、FPGAに接続するSDRAM
PCIeを介してCPUメモリーに向かうAFUリクエストは、図 4 で示されるように、プロセッサー側で処理することができます。
- 受信する読み出しリクエストのレイテンシーは、 SDRAM (図中A.2) から読み出すよりも小さくなります。
- 書き込みリクエストヒントを使用し、書き込まれたデータをどのように処理するかをラスト・レベル・キャッシュに指示できます (キャッシュ可または不可、および局所性など)。
リクエストがラスト・レベル・キャッシュでミスになった場合、SDRAMで処理することが可能です。
詳細は、CCI-Pプロトコルの定義にあるWrPush_Iリクエストを参照ください。
FPGA統合プラットフォーム
- FPGAキャッシュ (A.1) —インテルUPIのコヒーレント・リンクは、 インテル® Xeon® プロセッサーのコヒーレンシー・ドメインをFPGAキャッシュに拡張します。FPGAキャッシュでヒットするリクエストのレイテンシーは最も小さく、また、帯域幅は最も高くなります。VL0仮想チャネルを使用するAFUリクエストおよびUPIパスの使用が選択されたVAリクエストは、FPGAキャッシュをまず検索し、ミスになった場合にのみチップからプロセッサーに送信されます。
- プロセッサー側のキャッシュ (A.2) —プロセッサー側のキャッシュでヒットする読み出しリクエストのレイテンシーは、FPGAキャッシュでヒットする場合よりも大きくなりますが、プロセッサーのSDRAMから読み出す場合よりも小さくなります。書き込みリクエストヒントを使用し、プロセッサー側のキャッシュへの書き込みを指示できます。詳細は、CCI-Pプロトコルの定義にあるWrPush_Iリクエストを参照ください。
- プロセッサーのSDRAM (A.3) —プロセッサー側のキャッシュでミスとなったリクエストは、SDRAMで処理されます。
データアクセスのレイテンシーは、(A.1) から (A.3) に増加します。
VCステアリング・ロジックの制限の1つに、ステアリングの決定においてキャッシュの局所性を考慮しないことがあります。VCのステアリングの決定はキャッシュ検索の前に行われます。つまり、キャッシュラインがFPGAキャッシュにある場合でも、リクエストがVH0またはVH1に向けられる場合があることを意味します。そのようなリクエストでは、リクエストを完了させるために場合によってはプロセッサーがFPGAキャッシュをスヌーピングする必要があるため、レイテンシーがさらに課される可能性があります。AFUがすでにアクセスの局所性を認識している場合は、VL0仮想チャネルを使用しキャッシュの局所性を活用するほうが有効な場合があります。
1.3. CCI-Pインターフェイス
- メインメモリー
- メモリーマップドI/O (MMIO)
メモリータイプ | 説明 |
---|---|
メインメモリー |
メインメモリーは、プロセッサーに接続され、オペレーティング・システムに公開されるメモリーです。AFUからメインメモリーへのリクエストはアップストリーム・リクエストと呼ばれます。後続の章では、メインメモリーは単純にメモリーと呼ばれます。 |
メモリーマップドI/O |
I/Oメモリーは、ホストからAFUへのCCI-Pリクエストとして実装されます。MMIOは一般的に、AFU制御レジスターとして使用されます。このメモリーの実装方法および編成方法は、AFUデベロッパーによって異なります。AFUは、M20KまたはMLABのロジックを選択することが可能です。 CCI-Pインターフェイスは、メモリーマップドI/O (MMIO) リクエストを使用して、I/Oメモリーにアクセスするリクエスト形式を定義します。プロセッサーからI/Oメモリーへのリクエストは、ダウンストリーム・リクエストと呼ばれます。 AFUのMMIOアドレス空間サイズは256 kBです。 |
信号の種類 | 説明 |
---|---|
TxまたはRx |
フローの方向はAFUの視点からのものです。TxはAFUからFIUへのフローです。RxはFIUからAFUへのフローです。 |
チャネル |
信号をグループ化したもので、それらによってリクエストまたは応答を完全に定義します。 |
1.3.1. 信号情報
- CCI-P信号はすべて、pClkに同期している必要があります。
- インテルでは、ccip_if_pkg.svファイル内で定義されているCCI-P構造を使用することを推奨しています。このファイルはRTLパッケージに含まれています。
- AFUの入力および出力信号はすべて、レジスターする必要があります。
- RSVDでマークされているAFU出力ビットは予約されており、0に駆動する必要があります。
- RSVD-DNCでマークされているAFU出力はドント・ケア・ビットです。AFUは、0または1のいずれかを駆動できます。
- RSVDでマークされているAFU入力ビットは、AFUでドントケア (X) として扱う必要があります。
- 明示的に示されない限り信号はすべてアクティブHighです。アクティブLowの信号には、末尾に _nを付けます。
次の図は、ccip_std_afuモジュールのポートマップを表しています。ここでAFUをインスタンス化する必要があります。以降の章では、インターフェイス信号について説明します。

1.3.2. メインメモリーに対する読み出しおよび書き込み
CCI-Pは物理アドレスを使用し、プロセッサーのメインメモリーにアクセスするアップストリームのメモリー読み出しおよび書き込みリクエストを定義します。非仮想化システムの場合、AFUはホストの物理アドレスを駆動することが求められます。仮想化システムの場合、AFUはゲストの物理アドレスを駆動することが求められます。アドレス指定モードは、AFUハードウェア・デベロッパーに対してトランスペアレントです。ソフトウェア・アプリケーション・デベロッパーは、ソフトウェアがAFUに物理アドレスを提供することを確認する必要があります。
CCI-Pの仕様は、アップストリームのメモリーリクエストに弱いメモリー整合性モデルを定義します。
詳細は、「順序付けの規則」の章を参照してください。
1.3.2.1. メインメモリーからの読み出し
AFUは、pck_af2cp_sTx.c0を使用し、CCI-P Channel 0 (C0) を介してメモリー読み出しリクエストを送信します。また、pck_cp2af_sRx.c0を使用し、C0を介して応答を受信します。
c0_ReqMemHdr構造は、フラット・ビットベクトルから読み出しリクエストフィールドまでの便利なマッピングを提供します。AFUはpck_af2cp_sTx.c0.valid信号をアサートし、メモリー読み出しリクエストをhdrで駆動します。req_typeはキャッシュヒントを指定します。RDLINE_Iはキャッシュしないことを指定し、RDLINE_Sは共有状態でキャッシュすることを指定します。mdataフィールドはユーザー定義のリクエストIDであり、応答とともに変更されずに返されます。
c0_RspMemHdr構造は、フラット・ビットベクトルから応答フィールドまでの便利なマッピングを提供します。FIUはpck_cp2af_sRx.c0.resp_valid信号をアサートし、読み出し応答とデータをhdrおよびdataでそれぞれ駆動します。resp_typeはデコードされ、応答タイプを識別します (メモリー読み出しまたはUmsg)。読み出し応答順序は保証されていないため、mdataフィールドを定義し、リクエストで送信された値と同じ値が返されるようにする必要があります。
例えば、AFUはmdataを使用し、AFU内部のリクエストおよび応答をルーティングできます。すなわち、情報は次にトリガーされる動作で運ばれます。
1.3.2.2. メインメモリーへの書き込み
AFUは、pck_af2cp_sTx.c1を使用し、CCI-P Channel 1 (C1) を介してメモリー書き込みリクエストを送信します。また、pck_cp2af_sRx.c1を使用し、C1を介して書き込み完了確認応答を受信します。
- WrLine_Iは、FPGAキャッシュの意図がないことを指定します。
- WrLine_Mは、FPGAキャッシュをM状態で保持する意図を指定します。
- WrPush_Iは、プロセッサー側のキャッシュでキャッシュする意図を指定します。
- eMOD_CLは、単一または複数のキャッシュにアライメントされた書き込みを指定します。
-
eMOD_BYTEは、バイト・イネーブル書き込みを指定します。注: このメモリー・リクエスト・モードは、 インテル® PAC (インテル® Arria® 10 GX FPGA 搭載版) では利用できません。
c1_RspMemHdr構造は、フラット・ビットベクトルから応答フィールドまでの便利なマッピングを提供します。FIUはpck_cp2af_sRx.c1.resp_valid信号をアサートし、読み出し応答をhdrで駆動します。resp_typeフィールドは、応答タイプをデコードするためにデコードされます (メモリー書き込み、書き込みフェンスまたは割り込み)。
WrFenceは、メモリー書き込みリクエストをグローバルに可視化するために使用されます。WrFenceリクエストは、データペイロードとアドレスを受け入れないことを除いて、メモリー書き込みリクエストと同じフローに従います。
詳細については、Txヘッダーのフォーマット内の書き込みリクエストヘッダーのフォーマットを参照してください。
1.3.3. 割り込み
割り込みは、FPGA統合プラットフォームではサポートされていません。
AFUは割り込みIDを使用し、TxチャネルC1を介して割り込みを送信します。また、RxチャネルC1を介して応答を受信します。
AFUでは、発行される割り込みIDは一度に1つのみ持つようにしてください。発行された割り込みIDの応答が返されるまで待機せず、AFUが同じIDで別の割り込みを発行した場合、ホストは2番目の割り込みの到着を認識しない可能性があります。AFUが同じ割り込みIDを使用して割り込みを発行する前に、ソフトウェアによって割り込みリクエストを処理することが推奨されます。
1.3.4. UMsg
UMsgは、CCI-Pの読み出し帯域幅を消費することなく、AFUのスピンループと同じ機能を提供します。これはスピンループの最適化と考えることができ、FPGAキャッシュ・コントローラー内の監視エージェントが、ドライバーによって割り当てられたキャッシュラインへのスヌーピングを監視しています。キャッシュラインへのスヌーピングを検出すると、データを読み出し、AFUにUMsgを送信します。
UMsgフローはキャッシュ・コヒーレンシー・プロトコルを使用し、CPUからAFUへの順序付けされていない高速通信パスを実装します。このプロセスは図 8 に示されるとおり、2つの段階で構成されます。
最初の段階は初期化です。ここでSWはUMsgアドレス空間 (UMAS) を固定し、UMASの開始アドレスをFPGAキャッシュ・コントローラーと共有します。これが完了すると、FPGAキャッシュ・コントローラーはUMASの各キャッシュラインを読み出し、それをFPGAキャッシュに共有状態で配置します。
機能的にUMsgは、スピンループもしくは、インテルXeonプロセッサーのmonitorおよびmwait命令と同等です。
- マルチスレッド・アプリケーションの異なるアドレスへのスピンループに相対的な順序付けの保証がないように、異なるアドレスへのUMsgに順序付けの保証はありません。
- UMAS CLへのCPUの書き込みがすべて、対応するUMsgになるわけではありません。AFUはそれまでに行われたCLの値の変更を見逃す可能性がありますが、CLの最新データを読むことが保証されています。前述のとおり、これをスピンループのように考えると理解しやすくなります。プロデューサー・スレッドがフラグCLを複数回更新した場合、ポーリングスレッドはそれまでに行われた値の変更を見逃す可能性がありますが、最新の値を読むことが保証されています。
- UMsgはFPGAキャッシュを使用するため、キャッシュ・ポリューションを引き起こす可能性があります。キャッシュ・ポリューションとは、プログラムが不必要にデータをキャッシュにロードし、ほかの必要なデータを追い出すことでパフォーマンスが低下することです。
- CPUは誤ったスヌーピングを示す場合があるため、UMsgHは手がかりとなる情報として扱う必要があります。つまり、投機的実行またはUMsgHに基づくプリフェッチを開始することは可能ですが、結果を確定する前にUMsgを待つ必要があります。
- UMsgのレイテンシーは、RdLine_Sを使用するAFUの読み出しポーリングと同じですが、読み出しトラフィックに使用できるCCI-Pチャネルの帯域幅を節約します。
1.3.5. I/OメモリーへのMMIOアクセス
CCI-Pは、AFUレジスターファイルにアクセスするためのMMIO読み出しおよび書き込みリクエストを定義します。MMIOリクエストは、単一のPCIeチャネルを介してCPUからAFUへルーティングされます。
MMIO読み出し
AFUは、pck_cp2af_sRx.c0を介してMMIO読み出しリクエストを受信します。CCI-Pは、mmioRdValidをアサートし、MMIO読み出しリクエストをhdrで駆動します。c0_ReqMmioHdr構造は、フラット・ビットベクトルからMMIOリクエストフィールド (address、length、tid) までの便利なマッピングを提供します。
AFUは、MMIO読み出し応答をpck_af2cp_sTx.c2で駆動します。AFUはmmioRdValidをアサートし、応答ヘッダーとデータをそれぞれhdrおよびdataで駆動します。AFUは対応する応答とともに、応答をリクエストに関連付けるために使用したリクエストtidを返すことが予期されます。
- サポートされるデータ長は4バイトおよび8バイトです。
- 応答の長さはリクエストの長さと一致する必要があります。例えば、8バイトのMMIO読み出しリクエストに対して4バイトの応答を2つ返すことは不正です。
- 未処理のMMIO読み出しリクエスト数は、最大64に制限されます。
- 未定義のAFUレジスターに対するMMIO読み出しの場合でも応答を返します。
MMIO書き込み
AFUは、MMIO書き込みリクエストをpck_cp2af_sRx.c0を介して受信します。CCI-PはmmioWrValidをアサートし、MMIO書き込みリクエストヘッダーとデータを、それぞれhdrおよびdataで駆動します。c0_ReqMmioHdr構造は、フラット・ビットベクトルからMMIOリクエストフィールド (address、length、tid) までの便利なマッピングを提供します。MMIO書き込みリクエストはポストされ、AFUからの応答は予期されません。
サポートされるデータ長は、4バイト、8バイト、および64バイトです。
MMIOアクセスを実装する際の注意点
- DFHを実装するには、AFUが8バイトのアクセスをサポートしていることが必須です。
- 4バイトのMMIOアクセスに対するサポートはオプションです。AFUデベロッパーはソフトウェア・アプリケーション・デベロッパーと調整し、4バイトのアクセスを回避してください。
- AFUは、到着したMMIOリクエストを連続して遅延なく受け入れることが可能です。
- アライメントされていないMMIOアクセスは、エラーになります。ソフトウェア・アプリケーション・デベロッパーは、MMIOアドレスがリクエストの長さにアライメントされていることを確認する必要があります。例えば、8バイトのMMIOリクエストのバイトアドレスは、8の倍数である必要があります。つまり、バイトアドレス [2:0] は0でなければなりません。
1.3.6. CCI-P Tx信号

Txチャネルは3つあります。
C0およびC1 Txチャネルは、メモリーリクエストに使用されます。C0およびC1 Txチャネルはどちらも、独立したフロー制御を備えます。C0 Txチャネルはメモリー読み出しリクエストに使用され、C1 Txチャネルはメモリー書き込みリクエストに使用されます。
C2 Txチャネルは、MMIO読み出し応答をFIUに返すために使用されます。CCI-PポートはC2で応答を受け入れることを保証しているため、フロー制御はありません。

各TxチャネルにはValid信号があり、構造内の対応するヘッダーおよびデータ信号を分類します。
次の表に、CCI-P Txインターフェイスを構成する信号を示します。
信号 | 幅 (ビット) | 方向 | 説明 |
---|---|---|---|
pck_af2cp_sTx.c0.hdr | 74 | 出力 | チャネル0のリクエストヘッダーです。表 18 を参照ください。 |
pck_af2cp_sTx.c0.valid | 1 | 出力 | 1に設定されている場合、チャネル0のリクエストヘッダーが有効であることを示します。 |
pck_cp2af_sRx.c0TxAlmFull | 1 | 入力 |
1に設定されている場合、Txチャネル0はフルに近い状態です。この信号が設定されると、8つまでのリクエストの送信がAFUに許可されます。 0に設定されている場合、AFUはリクエストの送信をすぐに開始することができます。 |
信号 | 幅 | 方向 | 説明 |
---|---|---|---|
pck_af2cp_sTx.c1.hdr | 80 | 出力 | チャネル1のリクエストヘッダーです。表 12 を参照ください。 |
pck_af2cp_sTx.c1.data | 512 | 出力 | チャネル1のデータです。 |
pck_af2cp_sTx.c1.valid | 1 | 出力 | 1に設定されている場合、チャネル1のリクエストヘッダーおよびデータが有効であることを示します。 |
pck_cp2af_sRx.c1TxAlmFull | 1 | 入力 |
1に設定されている場合、Txチャネル1はフルに近い状態です。この信号が設定されると、8つまでのリクエストまたはデータの送信がAFUに許可されます。 0に設定されている場合、AFUはリクエストの送信をすぐに開始することができます。 |
信号 | 幅 (ビット) | 方向 | 説明 |
---|---|---|---|
pck_af2cp_sTx.c2.hdr | 9 | 出力 | チャネル2の応答ヘッダーです。表 12 を参照ください。 |
pck_af2cp_sTx.c2.mmioRdValid | 1 | 出力 | 1に設定されている場合、チャネル2の応答ヘッダーおよびデータが有効であることを示します。 |
pck_af2cp_sTx.c2.data | 64 | 出力 |
チャネル2のデータで、AFUがFIUに返すMMIO読み出しデータです。 4バイトの読み出しの場合、データはビット [31:0] で駆動する必要があります。 8バイトの読み出しの場合、AFUは8バイトのデータ応答を1つ駆動しなければなりません。応答を4バイトの応答2つに分割することはできません。 |
1.3.7. Txヘッダーのフォーマット
フィールド | 説明 |
---|---|
mode | メモリー・アクセス・モード
注: マルチ・キャッシュ・ライン書き込みの途中でモードを変更することはできません。
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
byte_start | バイト・アクセス・モードのバイト開始インデックスです。
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
byte_len | バイト・アクセス・モード (mode =
eMOD_BYTE) のバイト長です。
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
mdata |
メタデータです。ユーザー定義のリクエストIDで、リクエストから応答ヘッダーに変更されずに返されます。 C1 TxでのマルチCL書き込みの場合、mdataはsop=1の場合にのみヘッダーに有効です。 |
tid |
トランザクションIDです。AFUは、tid MMIO読み出しリクエストを応答ヘッダーに返す必要があります。これは、応答をリクエストに対して一致させるために使用されます。 |
vc_sel | 選択される仮想チャネルです。
マルチCL書き込みリクエストを形成するCLはすべて、同じ仮想チャネルでルーティングされます。 |
req_type | 表 13 で一覧になっているリクエストタイプです。 |
sop | マルチCLメモリー書き込みのパケットの開始です。
|
cl_len | メモリーリクエストの長さです。
注:
mode = eMOD_BYTEの場合、cl_lenは2’h0である必要があります。
|
address |
64バイトにアライメントされた物理アドレスです。つまり、byte_address>> 6です。 アドレスは、cl_lenフィールドに自然にアライメントする必要があります。例えばcl_len=2’b01の場合、address[0] は1'b0、同様にcl_len=2'b11の場合、address[1:0] は2'b00でなければなりません。 |
リクエストタイプ | エンコーディング | データペイロード | 説明 | ヘッダー・フォーマット |
---|---|---|---|---|
t_if_ccip_c0_tx: enum t_ccip_c0_req | ||||
eREQ_RDLINE_I | 4’h0 | いいえ |
キャッシュする意図のないメモリー読み出しリクエスト。 |
C0メモリー・リクエスト・ヘッダー。表 14 を参照ください。 |
eREQ_RDLINE_S | 4’h1 | いいえ |
キャッシュヒントがShared (共有) に設定されたメモリー読み出しリクエスト。 |
|
t_if_ccip_c1_tx: enum t_ccip_c1_req | ||||
eREQ_WRLINE_I | 4’h0 | はい |
FPGAキャッシュにデータを保持する意図のないメモリー書き込みリクエスト。 キャッシュラインをFPGAキャッシュに保持しません。また、CPU側のキャッシュについてのガイダンスも提供しません。
注: CPUはCPU側のキャッシュを担います。
|
C1メモリー・リクエスト・ヘッダー。表 15 を参照ください。 |
eREQ_WRLINE_M | 4’h1 | はい |
キャッシュヒントがModified (変更済み) に設定されたメモリー書き込みリクエスト。 |
|
eREQ_WRPUSH_I | 4’h2 | はい |
キャッシュヒントがInvalid (無効) に設定されたメモリー書き込みリクエスト。FIUは、FPGAキャッシュにデータを保持する意図なしに、プロセッサーのラスト・レベル・キャッシュ (LLC) にデータを書き込みます。書き込み先のLLCは常に、SDRAMアドレスが属するプロセッサーに関連付けられたLLCです。 FPGAキャッシュにキャッシュラインを保持しませんが、そのラインをCPU LLCにプッシュします。 |
|
eREQ_WRFENCE | 4’h4 | いいえ |
メモリー書き込みフェンスリクエスト。 |
フェンスヘッダー。表 16 を参照ください。 |
eREQ_INTR | 4'h6 | いいえ | 割り込み | 割り込みヘッダー。表 17 を参照ください。 |
t_if_ccip_c2_tx – リクエスト・タイプ・フィールドはありません。 | ||||
MMIO Rd | 該当なし | はい | MMIO読み出し応答 |
MMIO 読み出し応答ヘッダー。 表 18 を参照ください。 |
未使用のエンコーディングはすべてRSVD0とみなされます。
ビット | ビット数 | フィールド |
---|---|---|
[73:72] | 2 | vc_sel |
[71:70] | 2 | RSVD |
[69:68] | 2 | cl_len |
[67:64] | 4 | req_type |
[63:58] | 6 | RSVD |
[57:16] | 42 | address |
[15:0] | 16 | mdata |
ビット | ビット数 | Field SOP=1 | Field SOP=0 |
---|---|---|---|
[79:74] | 6 |
byte_len (mode=eMOD_CLの場合は0でなければなりません)
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
byte_len (sop=0の場合は0でなければなりません) 注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
[73:72] | 2 | vc_sel | RSVD-DNC |
[71] | 1 | sop=1 | sop=0 |
[70] | 1 |
mode
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
mode (sop=0の場合、eMOD_CLである必要があります) 注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
[69:68] | 2 | cl_len | RSVD-DNC |
[67:64] | 4 | req_type | req_type |
[63:58] | 6 |
byte_start (mode=eMOD_CLの場合は0でなければなりません)
注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
byte_start (sop=0の場合は0でなければなりません) 注: このフィールドは、
インテル® FPGA PAC N3000および
インテル® PAC (インテル®
Arria® 10 GX FPGA 搭載版) にRSVD0です。
|
[57:18] | 40 | address[41:0] | RSVD-DNC |
[17:16] | 2 | address[1:0] | |
[15:0] | 16 | mdata | RSVD-DNC |
ビット | ビット数 | フィールド |
---|---|---|
[79:74] | 6 | RSVD |
[73:72] | 2 | vc_sel |
[71:68] | 4 | RSVD |
[67:64] | 4 | req_type |
[63:16] | 48 | RSVD |
[15:0] | 16 | mdata |
ビット | ビット数 | フィールド |
---|---|---|
[79:74] | 6 | RSVD |
[73:72] | 2 | vc_sel |
[71:68] | 4 | RSVD |
[67:64] | 4 | req_type |
[63:12] | 62 | RSVD |
[1:0] | 2 | id |
ビット | ビット数 | フィールド |
---|---|---|
[8:0] | 9 | tid |
1.3.8. CCI-P Rx信号

Rxチャネルは2つあります。
- チャネル0はメモリー応答、MMIOリクエストおよびUMsgをインターリーブします。
- チャネル1は、Txチャネル1で開始されたAFUリクエストに対する応答を返します。
c0TxAlmFull信号およびc1TxAlmFull信号は、AFUへの入力です。これらはRx信号の構造で宣言されますが、論理的にはTxインターフェイスに属します。そのため、前章において説明されています。
Rxチャネルにはフロー制御がありません。AFUは、生成したメモリーリクエストに対する応答を受け入れる必要があります。AFUは、メモリーリクエストを生成する前にバッファーを事前に割り当てる必要があります。AFUはまた、MMIOリクエストを受け入れる必要があります。
Rxチャネル0には、メモリー応答およびMMIOリクエストに対する個別のValid信号があります。それらのValid信号の1つのみをサイクルに設定できます。MMIOリクエストには、MMIO読み出しとMMIO書き込みに個別のValid信号があります。mmioRdValidもしくはmmioWrValidのどちらかが設定されている場合、そのメッセージはMMIOリクエストであり、t_if_ccip_c0_Rx.hdrをt_ccip_c0_ReqMmioHdrにキャストし処理する必要があります。
信号 | 幅 (ビット) | 方向 | 説明 |
---|---|---|---|
pck_cp2af_sRx.c0.hdr | 28 | 入力 |
チャネル0の応答ヘッダーもしくはMMIOリクエストヘッダー。 表 21 を参照してください。 |
pck_cp2af_sRx.c0.data | 512 | 入力 |
チャネル0データバスのメモリー読み出し応答とUMsg。
MMIO書き込みリクエスト
|
pck_cp2af_sRx.c0.rspValid | 1 | 入力 |
1に設定されている場合、チャネル0のヘッダーとデータが有効であることを示します。ヘッダーは、メモリー応答として解釈され、resp_typeフィールドをデコードする必要があります。 |
pck_cp2af_sRx.c0.mmioRdValid | 1 | 入力 |
1に設定されている場合、チャネル0のMMIO読み出しリクエストを示します。 |
pck_cp2af_sRx.c0.mmioWrValid | 1 | 入力 |
1に設定されている場合、チャネル0のMMIO書き込みリクエストを示します。 |
信号 | 幅 (ビット) | 方向 | 説明 |
---|---|---|---|
pck_cp2af_sRx.c1.hdr | 28 | 入力 |
チャネル1の応答ヘッダー。表 21 を参照ください。 |
pck_cp2af_sRx.c1.rspValid | 1 | 入力 |
1に設定されている場合、チャネル1のヘッダーは有効な応答であることを示します。 |
1.3.8.1. RxヘッダーおよびRxデータの形式
フィールド | 説明 |
---|---|
mdata |
メタデータです。ユーザー定義のリクエストIDで、メモリーリクエストから応答ヘッダーに変更されずに返されます。 マルチCLのメモリー応答の場合、各CLに同じmdataが返されます。 |
vc_used |
使用される仮想チャネルです。VAを使用する場合、このフィールドはリクエストに対してFIUが選択した仮想チャネルを識別します。そのほかのVCの場合はリクエストVCを返します。 |
format |
マルチCLのメモリー書き込みリクエストを使用している場合、FIUはペイロード全体に対する単一の応答、もしくはペイロードの各CLに対して応答を返す場合があります。
|
cl_num |
Format=0:
1 CLのデータペイロードを超える応答の場合、このフィールドはcl_numを識別します。 2’h0 – 最初のCL。最下位アドレス。 2’h1 – 2番目のCL。 2'h2 – 3番目のCL。 2’h3 – 4番目のCL。最上位アドレス。 注: 応答は順不同で返される場合があります。
|
Format=1:
このフィールドは、データのペイロードサイズを識別します。 2’h0 – 1 CL、または64バイト 2’h1 – 2 CL、または128バイト 2’h3 – 4 CL、または256バイト |
|
hit_miss |
キャッシュのヒットもしくはミスのステータスです。AFUはこれを使用し、さまざまなモジュールの詳細なヒットおよびミスの統計を生成できます。 1’b0 – キャッシュミス 1’b1 – キャッシュヒット |
MMIOの長さ |
MMIOリクエストの長さ 2’h0 – 4バイト 2’h1 – 8バイト 2'h2 - 64バイト (MMIO書き込みのみ) |
MMIOアドレス | ダブルワード (DWORD) にアライメントされたMMIOアドレスオフセットです。つまり、byte address>>2です。 |
UMsg ID | UMsgに対応するCLを識別します。 |
UMsgタイプ |
2つのタイプのUMsgがサポートされています。 1’b1 – データなしのUMsgH (ヒント) 1’b0 – データ付きのUMsg |
リクエストタイプ | エンコーディング | データペイロード | ヘッダー・フォーマット |
---|---|---|---|
t_if_ccip_c0_Rx: enum t_ccip_c0_rsp | |||
eRSP_RDLINE | 4’h0 | はい |
メモリー応答ヘッダー。表 23 を参照ください。 c0.rspValidで識別されます。 |
MMIO読み出し | 該当なし | いいえ | MMIOリクエストヘッダー。表 24 を参照ください。 |
MMIO書き込み | 該当なし | はい | 該当なし |
eRSP_UMSG | 4’h4 | はい/いいえ |
Umsg応答ヘッダー。表 26 を参照ください。c0.rspValidで識別されます。 |
t_if_ccip_c1_Rx: enum t_ccip_c1_rsp | |||
eRSP_WRLINE | 4’h0 | いいえ |
メモリー応答ヘッダー。表 25 を参照ください。 c1.rspValidで識別されます。 |
eRSP_WRFENCE | 4'h4 | いいえ | Wrフェンス応答ヘッダー。表 27 を参照ください。 |
eRSP_INTR | 4'h6 | いいえ | 割り込み応答ヘッダー。表 28 を参照ください。 |
ビット | ビット数 | フィールド |
---|---|---|
[27:26] | 2 | vc_used |
[25] | 1 | RSVD |
[24] | 1 | hit_miss |
[23:22] | 2 | RSVD |
[21:20] | 2 | cl_num |
[19:16] | 4 | resp_type |
[15:0] | 16 | mdata |
ビット | ビット数 | フィールド |
---|---|---|
[27:12] | 16 | address |
[11:10] | 2 | length |
[9] | 1 | RSVD |
[8:0] | 9 | TID |
ビット | ビット数 | フィールド |
---|---|---|
[27:26] | 2 | vc_used |
[25] | 1 | RSVD |
[24] | 1 | hit_miss |
[23] | 1 | format |
[22] | 1 | RSVD |
[21:20] | 2 | cl_num |
[19:16] | 4 | resp_type |
[15:0] | 16 | mdata |
ビット | ビット数 | フィールド |
---|---|---|
[27:20] | 8 | RSVD |
[19:16] | 4 | resp_type |
[15] | 1 | UMsgタイプ |
[14:3] | 12 | RSVD |
[2:0] | 3 | UMsg ID |
ビット | ビット数 | フィールド |
---|---|---|
[27:20] | 8 | RSVD |
[19:16] | 4 | resp_type |
[15:0] | 16 | mdata |
ビット | ビット数 | フィールド |
---|---|---|
[27:26] | 2 | vc_used |
[25:20] | 6 | RSVD |
[19:16] | 4 | resp_type |
[15:2] | 14 | RSVD |
[1:0] | 2 | id |
1.3.9. マルチキャッシュ・ライン・メモリー・リクエスト
最高のリンク効率を実現するには、メモリーリクエストを大きな転送サイズにパッキングします。これにはマルチCLリクエストを使用します。以下に、マルチCLメモリーリクエストの特性を示します。
- 4 CLのデータペイロードを使用する場合に、最高のメモリー帯域幅が実現されます。
- メモリー書き込みリクエストは、かならず最下位アドレスから開始する必要があります。c1_ReqMemHdrのSOP=1は、最初のCLを示します。マルチCLリクエストの後続のヘッダーはすべて、Address[1:0] の増分値を駆動する必要があり、Address[41:2] はドントケアとして扱われます。
- N CLメモリー書き込みリクエストは、チャネル1でNサイクルかかります。マルチCLリクエストの途中でアイドルサイクルを持つことは正当ですが、1つのリクエストを別のリクエストとインターリーブすることはできません。マルチCL書き込みリクエストのデータペイロード全体を完了せずに新しいリクエストを開始することは不正です。
- FIUは、マルチCLのVAリクエストを単一のVCで完了することを保証します。
- メモリー・リクエスト・アドレスは自然にアライメントされている必要があります。2CLリクエストは2-CL境界で開始し、そのCLアドレスは2で割り切れなければなりません。すなわち、address[0] = 1'b0です。4CLリクエストは4-CL境界でアライメントし、そのCLアドレスは4で割り切れなければなりません。すなわち、address[1:0] = 2'b00です。
- マルチCLバーストは、他のリクエストを発行する前にすべてのワードを送信し、完了している必要があります。これは、単一のマルチCLバースト内では次の特別なメモリー書き込みリクエストをインターリーブできないことを意味します。
- 書き込みフェンス
- 割り込み
- バイト・イネーブル書き込み
次の図は、マルチCLメモリー書き込みリクエストの例です。
次の図は、メモリー書き込み応答サイクルの例です。アンパッキングされた応答の場合、各CLは順不同で返される場合があります。
以下は、メモリー読み出し応答サイクルの例です。読み出し応答は、それ自体の中で並べ替えることができます。すなわち、マルチCL読み出しの各CLの順序は保証されていません。マルチCL応答内のCLはすべて、同じmdataと同じvc_usedを持ちます。マルチCL読み出しのそれぞれのCLは、cl_numフィールドを使用して識別されます。
1.3.10. バイト・イネーブル・メモリー・リクエスト (インテル FPGA PAC D5005)
- バイト・イネーブル・メモリー・リクエストは、バイト不変のリトル・エンディアン・スキームを使用します。すなわち、これは次のことを意味します。
- データ構造内の単一または複数バイトの要素の場合、その要素はメモリーの同じ連続バイトを使用します。これは、byte_startおよびbyte_lenヘッダーフィールドで指定されます。
- 書き込みデータは、キャッシュライン内の格納されるオフセットのデータフィールドに配置されます。最初に書き込まれるデータビットは、ビットbyte_start*8です。
- byte_startはバイト・インデックスを指定します。最下位バイトは0 (pck_af2cp_sTx.c1.data[7:0]) であり、最上位バイトは63 (pck_af2cp_sTx.c1.data[511:504]) です。
- byte_lenは、バイト・イネーブルのメモリー書き込みトランザクションに含まれるバイト数を指定します。バイト長は、書き込みデータを最上位バイトに向かって拡張します。
- バイト・イネーブル・メモリー・リクエストは、キャッシュ長 (cl_len) を0 (1 CLメモリー書き込みリクエスト) に設定して行う必要があります。
- 長さは、pck_af2cp_sTx.c1.dataのバイト63を超えることができません。許容される最大のバイト長は、次の計算式で表すことができます。
-
byte_startが0の場合
- MAX_BYTE_LEN = 63
-
byte_startが0ではない場合
- MAX_BYTE_LEN = 64 – byte_start
-
byte_startが0の場合
ビット・インデックス | 幅 (ビット) | フィールド | 値 | |
---|---|---|---|---|
ヘッダー | 79:74 | 6 | byte_len | 0x11 |
73:72 | 2 | vc_sel | eVC_VA (0x0) | |
71 | 1 | sop=1 | 1 | |
70 | 1 | (CL/バイト) 0:CL、1:バイト | 1 | |
69:68 | 2 | cl_len | 0 | |
67:64 | 4 | req_type | eREQ_WRLINE_I (0x0) | |
63:58 | 6 | byte_start | 0x4 | |
57:18 | 40 | address | 0xFFF00 | |
17:16 | 2 | — | 0x0 | |
15:0 | 16 | mdata | 0x0 | |
データ | — | 512 | データ | 0xAAAABBBBCCCCDDDDE |
1.3.10.1. バイト・イネーブルとフル・キャッシュ・ライン・アクセスの併用
一部のアプリケーションでは、AFUは、ホストメモリーの64バイト境界に始まりがアライメントされていないバッファー、または次の64バイト境界よりも前に終わるバッファーにアクセスすることが必要になります。AFUは、バイト・イネーブルのトランザクションおよびフル・キャッシュライン・アクセスを併用し、任意の境界で開始または終了するバッファー書き込みを実行することができます。そのような転送の場合にAFUは、バイト・イネーブルのバースト (mode=eMOD_BYTE) とフル・キャッシュ・ラインのバースト (mode=eMOD_CL) を混在させることはできません。
最初のアクセスが64バイト境界で開始しないため、モードはeMOD_BYTEに設定されます。byte_startフィールドは0x2C、byte_lenフィールドは0x14、そしてCCIPアドレスビット41:2は0x62に設定され、CCIPアドレスビット1:0は0x3に設定されます。
2番目のアクセスは2CLの境界にアライメントされているため、次の128バイトは、モードがeMOD_CLに設定された2ビートのバーストとしてポストすることができます。2つのモードを同じバーストでインターリーブすることはできないため、このアクセスは、モードをeMOD_BYTEに設定するビートと組み合わせることはできません。
1.3.11. そのほかの制御信号
特に明記されない限り、信号はすべてアクティブHighです。
信号 | 幅 (ビット) | 方向 | 説明 |
---|---|---|---|
pck_cp2af_softReset | 1 | 入力 |
アクティブHIGHの同期ソフトリセット。 1に設定された場合、AFUはすべてのロジックをリセットする必要があります。最小リセットパルス幅は256 pClkサイクルです。未処理のCCI-Pリクエストはすべて、ソフトリセットをディアサートする前にフラッシュされます。 ソフトリセットはFIUをリセットしません。 |
pClk | 1 | 入力 |
一次インターフェイス・クロック。CCI-Pインターフェイス信号はすべて、このクロックに同期しています。 |
pClkDiv2 | 1 | 入力 | pClkに同期し位相しています。 0.5xのpClkクロック周波数です。 |
pClkDiv4 | 1 | 入力 | pClkに同期し位相しています。0.25xのpClkクロック周波数です。 |
uClk_usr | 1 | 入力 |
ユーザー定義のクロックは、pClkと同期していません。 AFUはCCI-Pインターフェイスを駆動する前に、この信号をpClkドメインに同期する必要があります。 AFUのロード・ユーティリティーは、pck_cp2af_softResetをディアサートする前にユーザー定義のクロック周波数をプログラムします。 |
uClk_usrDiv2 | 1 | 入力 |
uClk_usrと同期し、0.5xの周波数です。 注: 周波数は、uClk_usrと同期しない値に設定することが可能です。
|
pck_cp2af_pwrState | 2 | 入力 |
現在のAFUの消費電力状態に対するリクエストを示します。これに対応し、AFUは消費電力の削減を試みる必要があります。十分な消費電力の削減が達成されない場合、AFUがリセットになる場合があります。 2’h0 – AP0 - 通常の動作モード 2’h1 – AP1 - 50%の消費電力削減リクエスト 2’h2 – 予約済み 2’h3 – AP2 - 90%の消費電力削減リクエスト pck_cp2af_pwrStateがAP1に設定されると、FIUは50%のスループットの削減を実現するためにメモリー・リクエスト・パスの抑制を開始します。AFUもまた、FPGA内部メモリーリソースおよび計算エンジンへのアクセスを抑制することで、電力使用率を50%まで低減することが期待されます。同様に、AP2に移行すると、FIUはメモリー・リクエスト・パスを抑制し、通常状態に対して90%のスループットを削減します。AFUもまた、電力使用率を90%まで低減することが期待されます。 |
pck_cp2af_error | 1 | 入力 |
CCI-Pプロトコルエラーが検出され、PORT Errorレジスターに記録されています。このレジスターは、AFUに対して可視化されています。 これは、信号タップのトリガー条件として使用できます。 このようなエラーが検出されると、CCI-Pインターフェイスは新しいリクエストの受け入れを停止し、AlmFullを1に設定します。 CCI-Pプロトコルエラーが発生した際は、AFUがまだアクティブな (リセット状態になっていない) 場合でも、未処理のトランザクションが完了すると考えないでください。 |
1.3.12. プロトコルフロー
1.3.12.1. アップストリーム・リクエスト
タイプ | Txリクエスト | Txデータ | Rx応答 | Rxデータ |
---|---|---|---|---|
メモリー書き込み | WrLine_I | はい | WrLine | いいえ |
WrLine_M | ||||
WrPush_I | ||||
メモリー読み出し | RdLine_I | いいえ | RdLine | はい |
RdLine_S | ||||
特別なメッセージ | WrFence | いいえ | WrFence | いいえ |
Interrupt | いいえ | Interrupt | いいえ |
CCI-Pリクエスト | FPGAキャッシュ | UPIサイクル | 次の状態 | CCI-P応答 | UPIサイクル | 次の状態 | CCI-P応答 | UPIサイクル | 次の状態 | |
---|---|---|---|---|---|---|---|---|---|---|
ヒット/ミス | 状態 | フェーズ1 | フェーズ2 | フェーズ3 | ||||||
WrLine_I | ヒット | M | なし | M | WrLine | WbMtoI | I | |||
ヒット | S | InvItoE | ||||||||
ミス | I | |||||||||
WrLine_M | ヒット | M | なし | M | WrLine | 該当なし | ||||
ヒット | S | InvtoE | ||||||||
ミス | I | |||||||||
WrLine_I | ミス | M | WbMotI | I | InvItoE | M | WrLine | WbMotI | I | |
WrLine_M | ||||||||||
WrPush_I | WbPushMotI | I | ||||||||
WrLine_I | ミス | S | EvctCln | I | InvItoE | M | WrLine | WbMotI | I | |
WrLine_M | ||||||||||
WrPush_I | WbPushMotI | I | ||||||||
WrPush_I | ヒット | M | なし | M | WrLine | WbPushMotI | I | |||
S、I | InvItoE | |||||||||
RdLine_S | ヒット | S、M | なし | 変更なし | RdLine | 該当なし | ||||
ミス | I | RdCode | S | RdLine | ||||||
RdLine_I | ヒット | S、M | なし | 変更なし | RdLine | 該当なし | ||||
ミス | I | RdCur | I | RdLine | ||||||
RdLine_I | ミス | M | WbMtoI | I | RdCur | I | RdLine | |||
RdLine_S | RdCode | S | ||||||||
RdLine_I | S | EvctCln | RdCur | I | ||||||
RdLine_S | RdCode | S |
1.3.12.2. ダウンストリーム・リクエスト
Rxリクエスト | Rxデータ | Tx応答 | Txデータ |
---|---|---|---|
MMIO読み出し | いいえ | MMIO読み出しデータ | はい |
MMIO書き込み | はい | なし | 該当なし |
UMsg | はい | なし | 該当なし |
UMsgH | いいえ | なし | 該当なし |
1.3.13. 順序付けの規則
1.3.13.1. メモリーリクエスト
CCI-Pメモリーの一貫性モデルは、PCIeの一貫性モデルとは異なります。CCI-Pは、「緩和された」メモリーの一貫性モデルを実装します。
- 同じアドレス
- 異なるアドレス
表 33 は、CCI-P上の2つのメモリーリクエスト間の順序付けの関係を定義しています。同じ規則が、同じアドレスもしくは異なるアドレスへのリクエストに適用されます。下記表の内容は次のように定義されています。
- はい: 最初の列のリクエストは、最初の行のリクエストを渡すことができます。
- いいえ: 最初の列のリクエストは、最初の行のリクエストを渡すことができません。
行は列をバイパスするか | 読み出し | 書き込み | WrFence | 割り込み |
---|---|---|---|---|
読み出し | はい | はい | はい | はい |
書き込み | はい | はい | いいえ | はい |
WrFence | はい | いいえ | いいえ | いいえ |
割り込み | はい | はい | いいえ | はい |
上記表は、次のように解釈できます。
- WrFencesに関しては、読み出しを除いてすべての動作が順序付けられます。
- そのほかの動作はすべて、順序付けられません。
VC内における書き込みの可観測性
メモリー書き込み応答を受信すると、書き込みはローカルの可観測点に達します。
- AFUから同じ物理チャネルへのその後の読み出しはすべて、新しいデータを受信します。
- 同じ物理チャネルでのその後の書き込みはすべて、データを置き換えます。
VC間における書き込みの可観測性
メモリー書き込み応答は、そのデータがすべてのチャネルにわたりグローバルに可観測であることを意味するものではありません。別のチャネルでの後続の読み出しが古いデータを返し、別のチャネルでの後続の書き込みが元の書き込みよりも先に退く場合があります。VAへのWrFenceは、VC間で同期することが保証されているプロトコルを呼び出します。WrFence VAは、すべてのチャネルでブロードキャスト動作を行います。
- 書き込みフェンスに先行する書き込みはすべて、グローバルな可観測点にプッシュされます。
- WrFence応答を受信すると、AFUからのその後の読み出しはすべて、書き込みフェンスが発行されるまでに書き込まれたデータの最新のコピーを受信します。
1.3.13.1.1. メモリー書き込みフェンス
CCI-P WrFenceリクエスト
- WrFenceは、書き込みフェンスに続く書き込みが処理される前に、そのフェンスに先行するすべての割り込みまたは書き込みがメモリーに確定されることを保証します。
- WrFenceの順序は、ほかのメモリー書き込み、割り込み、またはWrFenceリクエストと入れ替わりません。
- WrFenceは、読み出しリクエストに関して順序付けの保証はしません。
- WrFenceはそれに続く読み出しをブロックしません。すなわち、メモリー読み出しはWrFenceをバイパスできます。この規則は、「メモリーリクエスト」の章で説明されています。
- WrFenceリクエストにはvc_selフィールドがあります。これにより、WrFenceが適用される仮想チャネルを決定できます。例えば、VL0を使用してデータブロックを移動する場合は、VL0上の書き込みリクエストのみをシリアル化します。つまり、WrFenceをVL0で使用する必要があります。同様に、VAでのメモリー書き込みを使用する場合は、WrFenceをVAで使用します。
- WrFenceリクエストは応答を返します。応答はRX C1を介してAFUに伝達され、resp_typeフィールドで識別されます。読み出しはWrFenceをバイパスできるため、書き込みに続いて読み出し を行い、最新のデータが読み出されるようにするには (RaWハザード)、WrFenceを発行し、同じ位置に読み出しを発行する前にWrFenceの応答を待ちます。
書き込み応答のカウント
- すべての書き込みではなく、特定の未処理の書き込みの完了のみを待機するため、バリアーのレイテンシーの影響を最小限に抑えます。
- 無関係な書き込みストリームを継続して進行させることができるため、リンクの使用率が向上します。
1.3.13.1.2. メモリーの一貫性の説明
CCI-Pは、同じアドレスおよび異なるアドレスへのリクエストの順序を変更することができます。同じアドレスに対するリクエストのデータハザードを特定するロジックは実装していません。
同じVCへの2つの書き込み
メモリーでは、最初の書き込み応答が受信された後に2つ目の書き込みリクエストが生成されない限り、同じVCに対する2つの書き込みは、それらの実行順序とは異なる場合があります。これは一般的に、ライトアフターライト (WaW) ハザードとして知られています。
次の表は、最初の書き込みが受信された後に2番目の書き込みが実行される場合の、同じVCへの2つの書き込みを示しています。
AFU | プロセッサー |
---|---|
VH1: Write1 Addr=X, Data=A Resp 1 VH1: Write2 Addr=X, Data=B Resp 2 |
— |
— |
Read1 Addr=X, Data = A Read2 Addr=X, Data = B |
AFUは同じVCでアドレスXへ2回書き込みますが、最初の書き込みが受信されてからのみ2番目の書き込みを送信します。これにより、最初の書き込みがリンクで送信された後に次の書き込みが送信されるようになります。CCI-Pは、プロセッサーがこれらの書き込みを発行された順序で認識するよう保証します。プロセッサーはアドレスXを複数回読み出す際に、データAを認識し、その後データBを認識します。
同じVCへの書き込み間に順序付けを強制するには、WrFenceを代わりに使用します。WrFenceのセマンティクスはより強力で、フェンス前の書き込みがすべて完了するまでフェンス後の書き込み処理すべてをストールすることに注意してください。
異なるVCへの2つの書き込み
次の表は、異なるVCへの2つの書き込みが、発行された順序とは異なる順序でメモリーに確定される場合があることを示しています。
AFU | プロセッサー |
---|---|
VH1: Write1 X, Data=A VL0: Write2 X, Data=B |
— |
— |
Read1 X, Data = B Read2 X, Data = A |
AFUはXに対して2回の書き込みを行います (VH1を介してData=A、VL0を介してData=B)。プロセッサーはアドレスXでポーリングし、Xへの更新を逆の順序で認識する場合があります (CPUはData=Bの後にData=Aを認識する)。すなわち、プロセッサーが認識する書き込み順序は、AFUが書き込みを完了した順序とは異なる場合があります。異なるチャネルへの書き込みには順序付けの規則がないため、書き込みフェンスをVAにブロードキャストし、それらを同期させる必要があります。
次の表は、WrFenceを使用し書き込み順序を強制する方法を示しています。
AFU | プロセッサー |
---|---|
VH1: Write1 Addr=X, Data=A VA: WrFence VL0: Write2 Addr=X, Data=B |
— |
— |
Read1 Addr=X, Data = A Read2 Addr=X, Data = B |
異なるVCからの2つの読み出し
異なるVCへ読み出しを発行すると、順不同で完了する場合があり、最後の読み出し応答が古いデータを返す場合があります。
次の表に、異なるVCを介した同じアドレスからの読み出しが順不同になる場合があることを示します。
プロセッサー | AFU | |
---|---|---|
Store addr=X, Data=A Store addr=X, Data=B |
Request | Response |
VH1: Read1 Addr=X | — | |
VL0: Read2 Addr=X | — | |
— | VL0: Resp2 Addr=X, Data=B | |
— | VH1: Resp1 Addr=X, Data=A |
同じVCからの2つの読み出し
プロセッサー | AFU | |
---|---|---|
Store Addr=X, Data=A Store Addr=X, Data=B |
Request | Response |
VL0: Read1 Addr=X | — | |
VL0: Read2 Addr=X | — | |
— | VL0: Resp2 Addr=X, Data=A | |
— | VL0: Resp1 Addr=X, Data=B |
プロセッサーはX=1の後にX=2を書き込みます。AFUは同じVCを介してアドレスXを2回読み出します。Read1およびRead2はどちらもVL0に送信されます。FIUが読み出し応答順序を変更する場合がありますが、CCI-P標準は最新のデータを最後に返すことを保証しています。つまり、AFUはアドレスXへの更新を、プロセッサーが書き込んだ順序で認識します。
VAを使用する場合、FIUは順不同でデータを返す場合があります。これは、VAリクエストはVL0、VH0またはVH1に向けられる場合があるためです。
同じVCからのリードアフターライト
CCI-P標準は、同じアドレスへの読み出しおよび書き込みリクエストの場合でも、それらのリクエストの順序付けを行いません。AFUは明示的にこの依存関係を解決する必要があります。
異なるVCからのリードアフターライト
AFUは異なるVCが使用される場合において、リードアフターライトの依存関係を解決することはできません。
同じVCまたは異なるVCに対するライトアフターリード
CCI-Pは同じアドレスに対するリクエストの場合でも、読み出し後の書き込みの順序付けを行いません。AFUは明示的にこの依存関係を解決する必要があります。AFUは、読み出し応答が受信された後にのみ書き込みリクエストを送信する必要があります。
トランザクションの順序付けのシナリオ例
- 例1: 同じアドレスXへの2つの書き込みは、順不同で完了する場合があります。アドレスXの最終的な値は非決定的です。順序付けを強制するには、書き込みリクエストの間にWrFenceを追加します。または、同じ仮想チャネルにアクセスする場合は、最初の書き込みからの応答が返されるまで待機し、その後2番目の書き込みを発行します。
- 例2: 同じアドレスXからの2つの読み出しは、順不同で完了する場合があります。これはデータハザードではありませんが、AFUデベロッパーは順序付けに関する前提を立てないでください。読み出しがどちらも同じ仮想チャネルに発行されている場合、受信する2番目の読み出し応答はアドレスXに保存されている最新のデータを含みます。
- 例3: アドレスXに対する書き込み後のアドレスXからの読み出しは非決定的です。すなわち、読み出しはアドレスXの新しいデータ (書き込み後のデータ) または古いデータ (書き込み前のデータ) を返します。確実に最新データの読み出しを行うには、同じ仮想チャネルを使用し、アドレスXへの読み出しを発行する前に書き込み応答が返されるのを待機します。
-
例4: アドレスXに対する読み出し後の書き込みは非決定的です。すなわち、読み出しはアドレスXの新しいデータ
(書き込み後のデータ) または古いデータ (書き込み前のデータ) を返します。
読み出し応答を使用し、読み出しの依存関係を解決します。
-
例1:
AFUがアドレスZへデータを書き込み、その後アドレスXのフラグの値を更新することでSWスレッドに通知を行うとします。
これを実装するには、AFUはZへの書き込みとXへの書き込みの間に書き込みフェンスを使用する必要があります。書き込みフェンスは、Xへの書き込みが処理される前にZをグローバルに可視化します。
-
例2:
AFUがアドレスZから始まるデータを読み出し、その後アドレスXのフラグの値を更新することでソフトウェア・スレッドに通知を行うとします。
これを実装するには、AFUはZからの読み出しを実行し、読み出し応答をすべて待機した後にXへの書き込みを実行する必要があります。
1.3.13.2. MMIOリクエスト
FIUは、AFUのMMIOアドレス空間を64ビットのプリフェッチ可能な PCIe* BARにマッピングします。AFUのMMIOがマッピングされたレジスターに、読み出しの副作用はありません。これらのレジスターへの書き込みは、書き込みマージを許容します。
プリフェッチ可能なBARに関する詳細は、PCIeの仕様を参照ください。
AFUをターゲットとするMMIOリクエストは、 PCIe* リンクから受信した順序のとおりにAFUに送信されます。同様に、MMIO読み出し応答は、AFUがCCI-Pインターフェイスに送信した順序と同じ順序で PCIe* リンクに返されます。すなわちFIUは、AFUをターゲットとするMMIOリクエストまたは応答順序の変更を行いません。
IAプロセッサーは、 PCIe* BARをUCもしくはWCのメモリータイプとしてマッピングすることができます。表 39 に、UCおよびWCタイプのBARに対するIAの順序付けの規則が説明されています。
UC (キャッシュ不可) およびWC (ライトコンバイン) の順序付けの規則に関する詳細は、Intel Software Developers Manualを参照ください。
リクエスト | メモリー属性 | ペイロードサイズ | メモリーの順序 | 備考 |
---|---|---|---|---|
MMIO書き込み | UC | 4バイト、8バイト、または64バイト | 強く順序付けられます | 一般的なケース (ソフトウェアの動作) |
WC | 4バイト、8バイト、または64バイト (インテル® Advanced Vector Extensions 512 (インテル® AVX-512) が必要です) | 弱い順序付けです | 特別なケース | |
MMIO読み出し | UC | 4バイトまたは8バイト | 強く順序付けられます | 一般的なケース (ソフトウェアの動作) |
WC | 4バイトまたは8バイト | 弱い順序付けです | 特別なケース。ストリーミング読み出し (MOVNTDQA) は、より広い読み出しを引き起こす可能性があります。サポートされていません。 |
1.3.14. タイミング図
WrFenceは、選択されたVCに対してそれまでに発行された書き込みのみをフェンスします。すべてのVCにわたって書き込みをフェンスするには、VAを選択します。
1.3.15. CCI-P のガイダンス
この章では、インテルFPGA IPシステムでFPGA統合プラットフォームまたは インテル® FPGA PACの使用を開始する際に推奨される有効な手法および設定を提供します。
CCI-Pインターフェイスは、FPGAキャッシュ状態および仮想チャネルを詳細に制御するための複数の高度な機能を提供します。それらを正しく使用することで、インターフェイスにわたる最適なパフォーマンスを実現することができます。それらが正しく使用されないと、パフォーマンスが大幅に低下する場合があります。
次の表に、リクエストフィールドに推奨されるパラメーターをいくつか示します。
フィールド | 推奨されるオプション | |
---|---|---|
vc_sel | ProducerとConsumerタイプのフローの場合 | VA |
レイテンシーに影響されやすいフローの場合 | VL0 | |
データに依存するフローの場合 | VAを除くVCのいずれかを使用する、もしくはMPFのVCマップを使用する | |
cl_len | 最大の帯域幅に向けて | 4 CL (256バイト) |
req_type | メモリー読み出し | RdLine_I |
メモリー書き込み | WrLine_M |
-
インテル® FPGA PAC
- VH0で64の未処理のリクエスト
- VAおよびVH0は、同じ64の未処理のリクエスト・バッファーを共有できます。
-
FPGA統合プラットフォーム
- VH0およびVH1はそれぞれ、64の未処理のリクエストを持つことができます。
- VL0がフルの帯域幅に達するには最低128のインフライトのトランザクションを必要とします。また、長いレイテンシー・テイルに対処するのに256を超える未処理のリクエストは必要ありません。
- VAの場合、最大限のパフォーマンスは最低256、最大384のトランザクションで達成することができます。デザイン領域の節減に向け、VAバッファーをほかのVCと共有することを検討します。
1.4. AFUの要件
この章では、電源投入時におけるAFUの初期化フローと、必須のAFUのコントロールおよびステータスレジスター (CSR) について定義します。
AFUのCSRに関する詳細は、「デバイス・フィーチャー・リスト」の章を参照ください。
1.4.1. 必須AFU CSRの定義
AFUのCSRに対するソフトウェア・アクセスには、次の要件が定義されています。
- ソフトウェアは、アライメントされたクワッドワード (8バイト) として64ビットのCSRにアクセスすることが想定されています。64ビット・レジスターのフィールド (ビットまたはバイト) の変更には、クワッドワード全体が読み出され、適切なフィールドが変更され、クワッドワード全体が書き戻されます (リードモディファイライト動作)。
- 32ビットのCSRをサポートするAFUの場合も同様に、ソフトウェアは、アライメントされたダブルワード (4バイト) でそれらにアクセスすることが想定されています。
CCI-Pに準拠するAFUにはそれぞれ、次の表で定義されている4つの必須レジスター (0x0000のDEV_FEATURE_HDR (DFH) を除く) の実装が必要です。これらのレジスターを実装していない場合、もしくは正しく実装していない場合、AFUの検出に失敗する、もしくは他の予期せぬ動作が起こる場合があります。
属性 | 展開 | 説明 |
---|---|---|
RO | Read Only | ビットはハードウェアでのみ設定されます。ソフトウェアはこのビットの読み出しのみ可能です。書き込みには効果がありません。 |
Rsvd | Reserved | 今後定義される内容に予約されています。AFUはこれらを0に設定する必要があります。ソフトウェアは、これらのフィールドを無視する必要があります。 |
名称 |
DWORDアドレス オフセット (CCI-P) |
バイト・アドレス・ オフセット (ソフトウェア) |
---|---|---|
DEV_FEATURE_HDR (DFH) ビットの説明に関しては、表 43 を参照ください。
注:
AFU のCSRは64ビットです。
|
0x0000 | 0x0000 |
AFU_ID_L AFU_ID GUIDの下位64ビット |
0x0002 | 0x0008 |
AFU_ID_H AFU_ID GUIDの上位64ビット |
0x0004 | 0x0010 |
DFH_RSVD0 | 0x0006 | 0x0018 |
DFH_RSVD1 | 0x0008 | 0x0020 |

ソフトウェアとAFU RTLは同じAFU IDを参照する必要があります。

ビット | 属性 | デフォルト | 説明 |
---|---|---|---|
63:60 | RO | 0x1 | タイプ: AFU |
59:52 | Rsvd | 0x0 | 予約済み |
51:48 | RO | 0x0 |
AFUマイナーバージョン番号 ユーザー定義の値 |
47:41 | Rsvd | 0x0 | 予約済み |
40 | RO | 該当なし |
リストの末尾 1’b0: この後に別のフィーチャー・ヘッダーがあります (「次のDFHのバイトオフセット」を確認ください。) 1’b1: これはこのAFUの最後のフィーチャー・ヘッダーです。 |
39:16 | RO | 0x0 |
次のデバイス・フィーチャー・ヘッダーへのバイトオフセットです。つまり、現在のアドレスからのオフセットです。 DFHのバイトオフセット例に関しては、表 45 を参照ください。 |
15:12 | RO | 0x0 |
AFUメジャーバージョン番号 ユーザー定義の値 |
11:0 | RO | 該当なし |
CCI-Pバージョン番号 ccip_if_pkg.svのCCIP_VERSION_NUMBERパラメーターを使用します。 |
1.4.2. AFUの検出フロー
CCI-Pに準拠するAFUには、必須のAFU CSRを実装する必要があります。次の図は、pck_cp2af_softResetがディアサートされた直後の最初のトランザクションを表しています。AFUは、ソフトリセットがディアサートされた直後にMMIO読み出しサイクルを受け入れる必要があります。
1.4.3. AFU_ID
AFU_IDの目的は、AFUのアーキテクチャーのインターフェイスを正確に識別することです。このインターフェイスは、AFUがソフトウェアと行うコントラクトです。
AFUの複数のインスタンスは同じAFU_IDの値を持つことができますが、AFUのアーキテクチャーのインターフェイスが変更になった場合は新しいAFU_IDが必要です。
AFUのアーキテクチャーのインターフェイスは、AFUの機能、CSRの定義、CSRを操作する際にAFUが想定するプロトコル、およびバッファーに関するすべての暗黙的または明示的な仮定もしくは保証から成るAFUデザインの構文とセマンティクスで構成されています。
ソフトウェア・フレームワークとアプリケーション・ソフトウェアは、AFU_IDを使用しそれらが正しいAFUと一致することを確認します。つまり、それらは同じアーキテクチャーのインターフェイスに従っています。
AFU_IDは128ビットの値です。また、UUID/GUIDジェネレーターを使用し、値が一意になるように生成することができます。
UUID/GUIDの詳細については「Online GUID Generator」のWebページを確認ください。
1.5. インテル FPGAベーシック・ビルディング・ブロック
インテル® FPGAベーシック・ビルディング・ブロック (BBB) は、インテルが提供するIPで、ユーザーが各自のAFUでインスタンス化できるものです。BBBには、ソフトウェアに可視化されるタイプ (レジスター・インターフェイスを公開し、ソフトウェアとの通信が必要) と、ソフトウェアに可視化されないタイプ (ソフトウェアの通信を必要としない) の2つがあります。どちらのタイプの場合においても、AFUデベロッパーはハードウェアとソフトウェアをAFUに統合する責任を負います。
BBBの詳細については、「Intel FPGA Basic Building Blocks (BBB)」のWebページを参照ください。
1.6. デバイス・フィーチャー・リスト
この章では、MMIO空間内のフィーチャーのリンクリストを作成するデバイス・フィーチャー・リスト (DFL) 構造を定義し、それによりフィーチャーの追加および列挙を行う拡張可能な方法を提供します。フィーチャー領域 (「フィーチャー」と呼ばれる場合もあります) は、関連するCSRのまとまりです。例えば、DMAエンジンの2つの異なるフィーチャーに、キュー管理とQoS機能があります。キュー管理とQoS機能は、2つの異なるフィーチャー領域にグループ化することが可能です。デバイス・フィーチャー・ヘッダー (DFH) レジスターは、フィーチャー領域の開始を示します。
ソフトウェアはDFL全体を見渡し、以下を列挙することができます。
-
AFU
- AFUはCCI-Pインターフェイスに準拠しており、CCI-Pポートに直接接続されます。AFU IDなどの必須AFUレジスターを実装する必要があります。
- AFU DFHは、MMIOアドレス0x0に位置している必要があります。
- プライベート・フィーチャー
- これはAFU内のフィーチャーのリンクリストであり、AFU内の機能を編成する方法を提供します。それらの列挙および管理は、AFUデベロッパーの責任です。
- これはIDの実装を必要としません。
-
インテル® FPGAベーシック・ビルディング・ブロック
- AFU内の特別なフィーチャーであり、再利用可能なビルディング・ブロックを意味します (一度デザインし、何度も再利用する)。ソフトウェアに可視化される インテル® FPGAベーシック・ビルディング・ブロックは一般的に、 インテル® FPGAベーシック・ビルディング・ブロックの列挙とコンフィグレーションを行うための、対応するソフトウェア・サービスとともに提供されます。また、場合によっては インテル® FPGAベーシック・ビルディング・ブロックに向けたより高いレベルのソフトウェア・インターフェイスが提供されます。
- AFUのような厳しいハードウェア・インターフェイス要件はありませんが、ソフトウェアの観点から明確に定義されたアーキテクチャーのセマンティクスを必要とします。
- 可視化される場合、必須DFHレジスターを実装する必要があります。
- ソフトウェアに可視化される インテル® FPGAベーシック・ビルディング・ブロックに対してのみ、GUIDを実装する必要があります。
次の図は、BBBとプライベート・フィーチャーで構成されるAFUのフィーチャー階層の例を表しています。
デバイス・フィーチャー・ヘッダー | |||
---|---|---|---|
ビット | 説明 | ||
63:60 | フィーチャー・タイプ | ||
4’h1 – AFU | 4’h2 – BBB | 4’h3 – プライベート・フィーチャー | |
59:52 | 予約済み | ||
51:48 |
AFUマイナーバージョン番号 ユーザー定義の値 |
予約済み | |
47:41 | 予約済み | ||
40 |
リストの末尾 1’b0: この後に別のフィーチャー・ヘッダーがあります (「次のDFHのバイトオフセット」を参照ください)。 1’b1: これは、このAFUの最後のフィーチャー・ヘッダーです。 |
||
39:16 |
次のDFHのバイトオフセット 次のDFHアドレス = 現在のDFHアドレス + 次のDFHのバイトオフセット このフィーチャーが占有するMMIO領域の最大サイズの指標としても使用されます。最後のフィーチャーの場合、このオフセットは割り当てられていないMMIO領域の開始を指します (ある場合)。もしくは、MMIO空間の範囲を超えます。 表 45 にある例を参照ください。 |
||
15:12 |
AFUメジャーバージョン番号 ユーザー定義 |
フィーチャーのリビジョン番号 ユーザー定義 |
|
11:0 |
CCI-Pバージョン番号 ccip_if_pkg.svのCCIP_VERSION_NUMBERパラメーターを使用します。 |
フィーチャーID AFU内のフィーチャーを識別するユーザー定義のIDを含みます。 |
フィーチャー | DFHアドレス | EOL | 次のDFHのバイトオフセット |
---|---|---|---|
0 | 0x0 | 0x0 | 0x100 |
1 | 0x100 | 0x0 | 0x180 |
2 (最後のフィーチャー) | 0x280 | 0x1 | 0x80 |
割り当てられていないMMIO空間、DFHなし | 0x300 | 該当なし | 該当なし |
BBBにタイプが設定されているDFHは、次の表にある必須BBBレジスターを後に続ける必要があります。
DFH内のバイト・アドレス・オフセット | レジスター名 |
---|---|
0x0000 | DFH Type=BBB |
0x0008 | BBB_ID_L |
0x0010 | BBB_ID_H |
レジスター名 | BB_ID_L | ||
---|---|---|---|
ビット | 属性 | 説明 | |
63:0 | RO | BBB_ID IDの下位64ビット |
レジスター名 | BB_ID_H | ||
---|---|---|---|
ビット | 属性 | 説明 | |
63:0 | RO | BBB_ID IDの上位64ビット |
BBB_IDはGUIDであり、概念的にはAFU_IDに類似しています。それぞれのBBBが一意の識別子を持つように定義されます。これにより、ソフトウェアがBBBハードウェアに関連付けられたソフトウェア・サービスを識別できるようになります。
次の図は、この章で定義されているDFHレジスターを使用し、論理フィーチャー階層 (左側に示されています) をどのように表現することができるかを示しています。
1.7. インテル® アクセラレーション・スタック (インテル® Xeon® CPU & FPGA対応) コア・キャッシュ・インターフェイス (CCI-P) リファレンス・マニュアルの改訂履歴
ドキュメント・バージョン | インテル・アクセラレーション・スタックのバージョン | 変更内容 |
---|---|---|
2019.11.04 | 2.0.1 (インテル Quartus® Prime プロ・エディション19.2でサポートされています)、2.0 (インテル Quartus Primeプロ・エディション18.1.2でサポートされています)、1.2 (インテル Quartus Primeプロ・エディション17.1.1でサポートされています) | CCI-Pバイト・イネーブルのフィーチャーを追加しました。 |
2019.08.05 | 2.0 (インテル Quartus Prime プロ・エディション18.1.2でサポートされています) および1.2 (インテル Quartus Primeプロ・エディション17.1.1でサポートされています) |
|
2018.12.04 | 1.2 (インテル Quartus Primeプロ・エディション17.1.1でサポートされています) | このドキュメントのアーカイブバージョンを含む「インテル・アクセラレーション・スタック (インテル Xeon CPU & FPGA 対応) コア・キャッシュ・インターフェイス (CCI-P) リファレンス・マニュアルのアーカイブ」の章を追加しました。 |
2018.08.06 | 1.1 (インテル Quartus Primeプロ・エディション17.1.1でサポートされています) および1.0 (インテル Quartus Primeプロ・エディション17.0.0でサポートされています) | 「FIU機能の比較」の章にある表6からクロック周波数の詳細を削除しました。また、このドキュメントから「クロック周波数」の章を削除しました。 注: このドキュメントでは複数のプラットフォームについて説明しているため、クロック周波数はこのドキュメントから削除されました。
|
2018.04.11 | 1.0 (インテル Quartus Primeプロ・エディション17.0でサポートされています) |
|