このページは、 Multi-Gigabit Transceiver (MGT) を紹介する一連のページの 2 番目です。
序章
Multi-Gigabit transceivers (MGTs) は、多くの有名な protocolsの基本的な構成要素です。 PCIe、 SATA、 Gigabit Ethernet、 SuperSpeed USB、 Thunderbolt 、 Displayport。これらすべての protocols には共通点が 1 つあります。 コンピュータが関係しています。また、光ファイバーリンクを介して電話の通話を転送するために使用する通信用の protocols もいくつかあります。
MGTs は、2 つの FPGAs間でデータを交換するのにも役立ちます。この目的で MGT を使用する際に注意すべき点が、前のページに記載されています。明らかに、物理チャネルを介してデータが適切に、かつ許容できる信頼性で送信されるようにするには、何らかの protocol が必要です。このような protocol の実装は非常に複雑なので、既製の protocols または他のビルディング ブロックが役立つかどうかが問題となります。
このページは、主な代替案をまとめたものです。これらは、 application logicの複雑さのレベルに従って、最も複雑さの少ないものから順に以下にリストされています。
以下のすべての protocols は、特に明記しない限り、双方向リンク (全二重) としても一方向リンク (半二重) としても機能します。
Xillyp2p
Xillyp2p は、2 つの FPGAs間で複数のデータ ストリームを信頼性高く転送できる独自の protocol です。 protocol は、 TCP/IP protocol がネットワーク経由でデータを転送する方法と同様に、アプリケーション データの転送、フロー制御、スケジュール、再転送を管理します。 すべてのデータが相手側に正しく到着することが保証されます。
application logic は、標準 FIFOsを介して protocolの実装と対話します。 protocol は、2 つの FPGAsにまたがる標準 FIFO の錯覚を作り出します。 この仮想 FIFOの書き込み側は 1 つの FPGAにあり、読み取り側はもう 1 つの FPGAにあります。
2 つの FPGAsのそれぞれにおいて、 FIFO の片側は application logic に接続され、もう片側は protocolの logicとやり取りします。したがって、送信側の application logic は FIFO にデータを書き込み、受信側の application logic は別の FIFOからデータを読み取ります。 protocol は、送信側 FPGA の FIFO から受信側 FPGAの FIFO にデータを移動します。 protocolのフロー制御により、送信先 FPGA の FIFO がいっぱいにならないようにします。
protocol は、双方向で複数の FIFOs にサービスを提供できます。公平なデータ転送スケジューラにより、 MGTの帯域幅が効率的に利用されます。送信側の FIFO のデータはすぐに消費されるため、この FIFO がいっぱいになることはありません (帯域幅が許し、反対側の FIFO からデータが消費される限り)。
protocol には、パケットを送信するための別のインターフェースもあります ( EOP portの助けを借りて)。
半二重オプションもサポートされています。この場合、 protocol は到着するすべてのデータが正しいことを保証します。物理チャネルでビット エラーが発生した場合、障害のあるデータが application logicに到達する前にデータ フローが停止されます。
Gigabit Ethernet
Gigabit Ethernet はコンピュータ間の通信を目的としていますが、このシンプルな protocol を使用して 2 台の FPGAs間でパケットを送信することもできます。適切な IP は通常、 FPGA の製造元によって提供されます。したがって、 application logic は標準インターフェイス (GMII、 RGMII、 XGMII など) の 1 つを介して Ethernet パケットの作成と受信を担当します。
他の Ethernet リンクと同様に、データをパケットに整理し、リンク上のエラーを処理する (再送信など) のは application logicの役割です。
Interlaken
Interlaken は、 chips間の通信用のオープン protocol です。64b/67b エンコーディングに基づいています。 低レベルのデータ フローは、 64 bitsのセグメントを繰り返し送信することで構成されます。各セグメントの前に、アプリケーション データと制御ワードを区別するために 3 bits が追加されます。
protocolの基本的な送信単位は、可変長のバーストです。制御ワードは、各バーストの直前と直後に送信されます。この 2 つの制御ワードには、パケットとチャネルを抽象化するための情報が含まれています。これには、次のような情報が含まれます。
- チャンネル番号: 0 ~ 255 の数値で、後続のデータ バーストをチャネルに関連付けます。
- SOP: 後続のデータがパケットの始まりであることを示すフラグ。
- EOP: 制御ワードの前のバーストがパケットの最後のデータであったことを示すフラグ。 EOP は、バースト内の有効なバイト数と、パケットにエラーが含まれているかどうかも示します。
制御ワードの内容と、その前に(おそらく)送信されたデータ バーストは、 CRC24を使用してビット エラーがチェックされます。
Interlaken protocol には、診断目的の CRC32 チェックもあります ( Meta Frameごとに 1 回)。ただし、このテストでエラーが検出された場合、それは特定のバーストやパケットではなく、大きなデータ セグメントに関連しています。つまり、ビット エラーにもかかわらずデータが CRC24 テストに合格した場合、これは後になって初めて検出され、不良データを含むバーストを特定することはできません。
Interlaken では、次の 2 つのメカニズムを使用してフロー制御要求を送信することもできます。 インバンド フロー制御とアウトオブバンド フロー制御 (OOBFC)。どちらのメカニズムも、 XON/XOFF セマンティクスを使用して、受信側がデータを受信する準備ができているかどうかを通知する手段で構成されています。この情報は、受信エンティティごとに 1 つの bit で構成されます。この bit は、このエンティティがデータを受信する準備ができている場合は「1」、そうでない場合は「0」になります。「受信エンティティ」の正確な意味は、アプリケーションによって異なります。
インバンド フロー制御メカニズムは、フロー制御要求を送信するために制御ワードで 16 bits を使用します。アウトオブバンド フロー制御メカニズムでは、情報を転送するために 3 つの追加の物理ワイヤ (clock、 sync 、および data) が必要です。
Interlaken には調停や送信スケジュールのメカニズムがないため、フロー制御を強制できません。異なるソースからのデータの送信を調停し、フロー制御要求が遵守されていることを確認するのは、 application logic の役割です。 Interlaken IP core がフロー制御をサポートしているとアナウンスする場合、それは多くの場合、データ フローを制御するのではなく、フロー制御要求の送信を許可することを意味します。
バーストが CRC24 テストに失敗した場合 (つまり、ビット エラーが検出された場合)、 Interlaken Retransmit Extension Protocol Definitionで定義されているように再送信を要求できます。この再送信要求は、前述の帯域外インターフェイス (OOBFC) で送信されます。つまり、 protocol では、 MGT リンク自体で再送信要求を送信する方法は定義されておらず、3 つの個別の物理的な帯域外ワイヤで再送信要求を送信する方法が定義されています。
Aurora
Aurora は、 Xilinx (現在の AMD) が独自の FPGAs用に開発した protocol です。この protocolの基本的な送信単位は 1 ワードです (幅は、関係する MGTs の数に応じて固定されます)。ただし、 protocol は、パケットの最後のワードとともにチャネルを通過する「last」信号をオプションで公開することにより、パケット モードもサポートします。
物理チャネル上のビット エラーは protocolでは修正されません。
送信側では、両側 ( protocol と application logic) ) がハンドシェイク信号によってデータ フローを制限できます。受信側では、 application logic は到着したデータ ワードを常に受け入れる必要があります。ただし、 protocol は送信側がデータを送信しないようにする 2 つのオプションを提供します。
- Native Flow Control (NFC) : 受信側の application logic は、送信側に対して、要求で指定されたデータ スロット数の間、データ送信を一時停止するように要求します。 protocolの logic は、送信側のハンドシェイク信号によってこの要求に従う責任があります。
- User Flow Control (UFC) : protocol を使用すると、受信側は別のチャネルを介して任意のメッセージを送信できます。送信側の application logic は、この要求を処理して従う責任を負います。
両方のフロー制御メカニズムは反対方向のデータ リンクに基づいているため、これらは全二重モードでのみ使用できます。
protocol を使用してパケットを送信する場合、送信側はオプションで各パケットの末尾に CRC を追加します ( Xilinxの protocolの実装)。 protocolの実装では、受信側でこの CRC をチェックし、パケットでエラーが検出された場合に application logic に通知します。 Aurora がパケットなし (「last」信号なし) で使用される場合、 protocolによるエラー検出は行われません。
あらゆる再送信メカニズム、複数チャネルの多重化、および送信スケジューリングは、 application logicによって実装される必要があります。
Auroraには 2 つのバリエーションがあります。 8b/10b エンコーディングと64b/66b エンコーディングを使用します。 64b/66b エンコーディングの方が効率的なので、可能な場合はこのバリエーションを優先する必要があります。
Serial Lite
Altera には、 Serial Liteという名前を共有する protocols および IP cores のシリーズがあります。
- SerialLite II: データの送受信用のパケットベースまたは非パケット インターフェイス (名前は「Atlantic Interface」)。ビット エラーに対する再送信をサポートします。初期の FPGAs ( Arria II から series-V FPGAsまで) にのみ適用されます。
- Serial Lite III: 連続モードとバースト モードをサポートします。連続モードでは、データ ストリームは送信側と受信側の間で途切れることなく流れます。これには、両側が同じ reference clockに依存している必要があります。この protocol は内部的には Interlakenに基づいていますが、チャネルや SOP/EOPをサポートしていません。したがって、インターフェイスのデータ幅は、使用される MGTs の数に 64 bits を掛けた値になります。物理リンク上のビット エラーは、エラーの原因となった MGT に関する診断イベントとして報告されますが、特定のデータ セグメントに関するものではありません。 series-V FPGAs および series-10 FPGAsに適用されます。
- Serial Lite IV: パケットの開始と終了の信号 (MAC) を備えた Avalon streaming インターフェイスに基づいています。 CRC は、送信側によってパケットの最後にオプションで挿入され、受信側によってチェックされます。パケットに分割されない基本モードもあります。 Stratix 10 および Agilex E-tileに適用可能です。
IP cores は、このシリーズの protocolsの異なるメンバー間で互換性がありません。再送信を開始できるのは SerialLite II のみです。
RapidIO
RapidIOはパケットベースの protocol であり、サポートするパケット タイプが CPUに必要な操作に対応しているという点でPCIeに似ています。
- 書く: addressにデータを書き込みます。この操作にはいくつかのバリエーションがあり、そのうちの 1 つでは、操作が完了したことを示す応答が必要です。
- 読む: addressからデータを読み取る要求。この要求に対してターゲットから応答パケットが送信されます。
- アトミック読み取り-変更-書き込み: 前の値を読み取った後、アトミック操作として address にデータを書き込む要求。サポートされている操作には次のものがあります: Atomic increment および atomic decrement、 atomic swap、 compare and swap など。
- 検出、制御、ステータスに関する複数のメンテナンス要求。 PCI protocolの configuration register spaceと同様に、これらのメンテナンス要求は registers capability registers (CAR) および command and status registers (CSR) にアクセスします。
RapidIO と PCIe の主な機能上の違いは、 PCIe protocol では中央ユニット ( Root Complex、通常は CPU) がシステム内のすべてのエンドポイントを構成する必要があることです。 RapioIO システムでは、この種の中央ユニットは必要ありません。
PCIe とのもう 1 つの違いは、パケットの再送信がオプションであることです。再送信は、「reliable traffic」(RT) として送信されたパケットに対してのみ行われます。パケットは、「continuous traffic」(CT) として送信することもできます。このようなパケットは確認応答も再送信もされません。
RapidIO protocol は、電気仕様からパケット形式、再送信、フロー制御まで、通信のあらゆる側面を定義します。
RapidIO は、 protocolの複雑さのため、2 つの FPGAs間の単純なポイントツーポイント接続には適さない可能性があります。特に、システム内に CPU が必要なために PCIe が適していない場合は、 RapidIO が switchを介して複数の FPGAs 間の相互接続としてより適している可能性があります。
概要
アプリケーション データを伝送するための protocols がいくつか紹介されました。各 protocol は、データの転送、フローの制御、ビット エラーへの対応 (ある場合) を実装するためのさまざまな方法を提供します。アプリケーションに適した protocol は、 protocol が提供する機能と、 application logicで不足している部分を実装するために必要な作業とのバランスです。
これで、 MGTsに関するこのシリーズの 2 ページ目は終了です。次のページでは、 MGTsでよく使用されるエンコード方式をいくつか紹介します。