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の観点において単機能のデバイスです。

インテル^® 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を使用するリモートデバッグを実装します。

FPGA統合プラットフォームは、FPGAをプロセッサーに接続するリンクを3つ備えています。1つはインテルUPIコヒーレント・リンク、残りの2つはPCIe Gen3x8リンクです。これらの3つのリンクをCCI-PインターフェイスにマッピングするのはFIUの機能であり、それによってAFUは、3つのリンクの総帯域幅に等しい帯域幅を持つホスト・プロセッサーへの単一の論理通信インターフェイスを認識します。図 1 は、UPIおよびPCIeリンクのCCI-Pへのマッピングに関連するFIUロジックのみを示しています。

インテル^® FPGA PACと同様に、FPGA統合プラットフォームもまた、FMEおよびCCI-Pポートで提供されるサービス一式を実装し、FPGAの展開および管理を行います。

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内部のリクエストおよび応答をルーティングできます。すなわち、情報は次にトリガーされる動作で運ばれます。

AFUは、pck_af2cp_sTx.c1を使用し、CCI-P Channel 1 (C1) を介してメモリー書き込みリクエストを送信します。また、pck_cp2af_sRx.c1を使用し、C1を介して書き込み完了確認応答を受信します。

c1_RspMemHdr構造は、フラット・ビットベクトルから応答フィールドまでの便利なマッピングを提供します。FIUはpck_cp2af_sRx.c1.resp_valid信号をアサートし、読み出し応答をhdrで駆動します。resp_typeフィールドは、応答タイプをデコードするためにデコードされます (メモリー書き込み、書き込みフェンスまたは割り込み)。

WrFenceは、メモリー書き込みリクエストをグローバルに可視化するために使用されます。WrFenceリクエストは、データペイロードとアドレスを受け入れないことを除いて、メモリー書き込みリクエストと同じフローに従います。

詳細については、Txヘッダーのフォーマット内の書き込みリクエストヘッダーのフォーマットを参照してください。

割り込みは、FPGA統合プラットフォームではサポートされていません。

AFUは割り込みIDを使用し、TxチャネルC1を介して割り込みを送信します。また、RxチャネルC1を介して応答を受信します。

AFUでは、発行される割り込みIDは一度に1つのみ持つようにしてください。発行された割り込みIDの応答が返されるまで待機せず、AFUが同じIDで別の割り込みを発行した場合、ホストは2番目の割り込みの到着を認識しない可能性があります。AFUが同じ割り込みIDを使用して割り込みを発行する前に、ソフトウェアによって割り込みリクエストを処理することが推奨されます。

未使用のエンコーディングはすべてRSVD0とみなされます。

図 11. ccip_if_pkg.sv内の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にキャストし処理する必要があります。

最高のリンク効率を実現するには、メモリーリクエストを大きな転送サイズにパッキングします。これにはマルチ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フィールドを使用して識別されます。

一部のアプリケーションでは、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に設定するビートと組み合わせることはできません。

特に明記されない限り、信号はすべてアクティブHighです。

CCI-Pメモリーの一貫性モデルは、PCIeの一貫性モデルとは異なります。CCI-Pは、「緩和された」メモリーの一貫性モデルを実装します。

表 33 は、CCI-P上の2つのメモリーリクエスト間の順序付けの関係を定義しています。同じ規則が、同じアドレスもしくは異なるアドレスへのリクエストに適用されます。下記表の内容は次のように定義されています。

• はい: 最初の列のリクエストは、最初の行のリクエストを渡すことができます。
• いいえ: 最初の列のリクエストは、最初の行のリクエストを渡すことができません。

上記表は、次のように解釈できます。

• WrFencesに関しては、読み出しを除いてすべての動作が順序付けられます。
• そのほかの動作はすべて、順序付けられません。

VC内における書き込みの可観測性

メモリー書き込み応答を受信すると、書き込みはローカルの可観測点に達します。

• AFUから同じ物理チャネルへのその後の読み出しはすべて、新しいデータを受信します。
• 同じ物理チャネルでのその後の書き込みはすべて、データを置き換えます。

VC間における書き込みの可観測性

メモリー書き込み応答は、そのデータがすべてのチャネルにわたりグローバルに可観測であることを意味するものではありません。別のチャネルでの後続の読み出しが古いデータを返し、別のチャネルでの後続の書き込みが元の書き込みよりも先に退く場合があります。VAへのWrFenceは、VC間で同期することが保証されているプロトコルを呼び出します。WrFence VAは、すべてのチャネルでブロードキャスト動作を行います。

• 書き込みフェンスに先行する書き込みはすべて、グローバルな可観測点にプッシュされます。
• WrFence応答を受信すると、AFUからのその後の読み出しはすべて、書き込みフェンスが発行されるまでに書き込まれたデータの最新のコピーを受信します。

CCI-P WrFenceリクエスト

書き込み応答のカウント

CCI-Pは、同じアドレスおよび異なるアドレスへのリクエストの順序を変更することができます。同じアドレスに対するリクエストのデータハザードを特定するロジックは実装していません。

同じVCへの2つの書き込み

メモリーでは、最初の書き込み応答が受信された後に2つ目の書き込みリクエストが生成されない限り、同じVCに対する2つの書き込みは、それらの実行順序とは異なる場合があります。これは一般的に、ライトアフターライト (WaW) ハザードとして知られています。

次の表は、最初の書き込みが受信された後に2番目の書き込みが実行される場合の、同じVCへの2つの書き込みを示しています。

AFUは同じVCでアドレスXへ2回書き込みますが、最初の書き込みが受信されてからのみ2番目の書き込みを送信します。これにより、最初の書き込みがリンクで送信された後に次の書き込みが送信されるようになります。CCI-Pは、プロセッサーがこれらの書き込みを発行された順序で認識するよう保証します。プロセッサーはアドレスXを複数回読み出す際に、データAを認識し、その後データBを認識します。

同じVCへの書き込み間に順序付けを強制するには、WrFenceを代わりに使用します。WrFenceのセマンティクスはより強力で、フェンス前の書き込みがすべて完了するまでフェンス後の書き込み処理すべてをストールすることに注意してください。

異なるVCへの2つの書き込み

次の表は、異なるVCへの2つの書き込みが、発行された順序とは異なる順序でメモリーに確定される場合があることを示しています。

AFUはXに対して2回の書き込みを行います (VH1を介してData=A、VL0を介してData=B)。プロセッサーはアドレスXでポーリングし、Xへの更新を逆の順序で認識する場合があります (CPUはData=Bの後にData=Aを認識する)。すなわち、プロセッサーが認識する書き込み順序は、AFUが書き込みを完了した順序とは異なる場合があります。異なるチャネルへの書き込みには順序付けの規則がないため、書き込みフェンスをVAにブロードキャストし、それらを同期させる必要があります。

次の表は、WrFenceを使用し書き込み順序を強制する方法を示しています。

異なるVCからの2つの読み出し

異なるVCへ読み出しを発行すると、順不同で完了する場合があり、最後の読み出し応答が古いデータを返す場合があります。

次の表に、異なるVCを介した同じアドレスからの読み出しが順不同になる場合があることを示します。

同じVCからの2つの読み出し

プロセッサーは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は、読み出し応答が受信された後にのみ書き込みリクエストを送信する必要があります。

トランザクションの順序付けのシナリオ例

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

WrFenceは、選択されたVCに対してそれまでに発行された書き込みのみをフェンスします。すべてのVCにわたって書き込みをフェンスするには、VAを選択します。

この章では、インテルFPGA IPシステムでFPGA統合プラットフォームまたは インテル^® FPGA PACの使用を開始する際に推奨される有効な手法および設定を提供します。

CCI-Pインターフェイスは、FPGAキャッシュ状態および仮想チャネルを詳細に制御するための複数の高度な機能を提供します。それらを正しく使用することで、インターフェイスにわたる最適なパフォーマンスを実現することができます。それらが正しく使用されないと、パフォーマンスが大幅に低下する場合があります。

次の表に、リクエストフィールドに推奨されるパラメーターをいくつか示します。

この章では、電源投入時におけるAFUの初期化フローと、必須のAFUのコントロールおよびステータスレジスター (CSR) について定義します。

AFUのCSRに関する詳細は、「デバイス・フィーチャー・リスト」の章を参照ください。

AFUのCSRに対するソフトウェア・アクセスには、次の要件が定義されています。

1. ソフトウェアは、アライメントされたクワッドワード (8バイト) として64ビットのCSRにアクセスすることが想定されています。64ビット・レジスターのフィールド (ビットまたはバイト) の変更には、クワッドワード全体が読み出され、適切なフィールドが変更され、クワッドワード全体が書き戻されます (リードモディファイライト動作)。
2. 32ビットのCSRをサポートするAFUの場合も同様に、ソフトウェアは、アライメントされたダブルワード (4バイト) でそれらにアクセスすることが想定されています。

CCI-Pに準拠するAFUにはそれぞれ、次の表で定義されている4つの必須レジスター (0x0000のDEV_FEATURE_HDR (DFH) を除く) の実装が必要です。これらのレジスターを実装していない場合、もしくは正しく実装していない場合、AFUの検出に失敗する、もしくは他の予期せぬ動作が起こる場合があります。

図 23.  AFUでの必須AFUレジスターの設定

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

図 24. ソフトウェアによるAFU IDの読み出し

CCI-Pに準拠するAFUには、必須のAFU CSRを実装する必要があります。次の図は、pck_cp2af_softResetがディアサートされた直後の最初のトランザクションを表しています。AFUは、ソフトリセットがディアサートされた直後にMMIO読み出しサイクルを受け入れる必要があります。

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ページを確認ください。

この章では、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のフィーチャー階層の例を表しています。

BBBにタイプが設定されているDFHは、次の表にある必須BBBレジスターを後に続ける必要があります。

BBB_IDはGUIDであり、概念的にはAFU_IDに類似しています。それぞれのBBBが一意の識別子を持つように定義されます。これにより、ソフトウェアがBBBハードウェアに関連付けられたソフトウェア・サービスを識別できるようになります。

次の図は、この章で定義されているDFHレジスターを使用し、論理フィーチャー階層 (左側に示されています) をどのように表現することができるかを示しています。