このページは、 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 がネットワーク経由でデータを転送する方法と同様に、アプリケーションデータの送信、スケジューリング、再送信、および flow control を管理します。 すべてのデータが相手側に正しく到着することが保証されます。
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 は simplex link (単方向物理チャネル)用に定義されています。 full duplex link (双方向物理チャネル)を使用する場合、 simplex linkと同様に動作しますが、 flow control メッセージは逆方向に送信できます。
protocolの基本的な送信単位は、可変長のバーストです。制御ワードは、各バーストの直前と直後に送信されます。この 2 つの制御ワードには、パケットとチャネルを抽象化するための情報が含まれています。これには、次のような情報が含まれます。
- チャンネル番号: 0から255までの数値で、後続のデータバーストをチャネルに関連付けます。チャネル数は最大65536まで拡張可能です。
- SOP: 後続のデータが packetの始まりであることを示すフラグ。
- EOP: 制御ワードの前の packet がパケットの最後のデータであることを示すフラグ。 EOP は、バーストの最後のワードに含まれる有効なバイト数と、パケットにエラーが含まれているかどうかも示します。
各バーストの長さは、 BurstMax より長くてはならず、 BurstShortより短くてはなりません。 BurstMax と BurstShort はどちらも特定のアプリケーション用に選択されるパラメータです。 BurstShort は 32 bytes 以上(かつ8の倍数である必要があります)であり、 BurstMax は 64 bytesの倍数である必要があります。
制御ワードの内容と、その前に(おそらく)送信されたデータ バーストは、 CRC24を使用してビット エラーがチェックされます。
バーストが CRC24 テストに失敗した(つまり、ビットエラーが検出された)場合、 Interlaken Retransmit Extension Protocol Definitionで定義されているように再送信を要求できます。提案されているメカニズムによると、この要求は受信機から送信機への3本の物理線を介して送信されます。これらの線は FC_CLK、 FC_DATA 、 FC_SYNCと名付けられており、本来は out-of-band flow control (OOBFC)を対象としています。 flow control 要求を送信するためのシンプルなシリアルデータ伝送プロトコルが定義されています。再送信が有効になっている場合、これらのビットの1つは「RT」と呼ばれ、再送信を要求するために使用されます。言い換えれば、 protocol は MGT リンク自体ではなく、3本の別々の物理的な帯域外線を介して再送信要求を送信する方法を定義しています。
再送要求には、どのバーストから再送を開始するかという情報は含まれていません。代わりに、送信側は bufferに一定量のバーストデータを保存する必要があります。再送要求が到着すると、 buffer 内のすべてのバーストが再送されます。したがって、 buffer のサイズは、失われたバーストを収容できる大きさである必要があります。しかし、 buffer のサイズが大きすぎると、再送に必要以上に時間がかかります。 bufferのサイズを定義するには、 Interlaken protocol を実装するロジックにバーストを送信してから再送要求が到着するまでの往復時間を慎重に計算する必要があります。
受信側は、初めて送信されるバーストごとにインクリメントされるカウンタを用いて再送バーストを検出します(2、4、8バーストごとにカウンタをインクリメントすることも可能です)。このカウンタの値は、各バーストの前後に送信される制御ワードの Multiple-Use 部分で送信されます。受信側はこのカウンタを用いて、新規バーストと再送バーストを区別します。
Interlaken protocol には、診断目的で CRC32 チェックも搭載されています( Meta Frameごとに1回)。ただし、このテストでエラーが検出された場合、それは特定のバーストや packetではなく、データの大部分に関連するものです。つまり、 bit errorテストにもかかわらずデータが CRC24 テストに合格した場合、これは後になって初めて検出され、どのバーストに欠陥データが含まれているかを特定することはできません。
MGTの逆方向のデータフローに基づいた再送メカニズムを設計・実装することは可能です。 Interlaken protocol ではそのような再送メカニズムの手法は提案されていませんが、 packets の再送要求用に専用のチャネルを割り当てることは可能です。このソリューションは、再送対象をより具体的に指定できるため、大きな利点があります。また、バーストではなく、より優れた CRCを packets に適用することも可能です。ただし、このアプローチを採用する場合、メカニズム全体を application logicに実装する必要があります。
Interlakenの flow control メカニズムについては別のページで説明します。
Aurora
Aurora は、 Xilinx (現在の AMD)が独自の FPGAs用に開発した protocol です。この protocolの基本伝送単位は1ワード(使用する MGTs の数に応じて固定長)です。ただし、 protocol は packets ( framesと呼ばれます)の伝送もサポートしています。 application logic は、 "last" input portを用いてデータストリームを packets に分割します。
Auroraには 2 つのバリエーションがあります。 8b/10b エンコーディングと64b/66b エンコーディングを使用します。 64b/66b エンコーディングの方が効率的なので、可能な場合はこのバリエーションを優先する必要があります。
Aurora は、 simplex link (単方向物理チャネル)と full duplex link (双方向物理チャネル)の両方で定義されています。 application logicの観点からは、 flow control が simplex linkでは意味を持たないことを除き、これら2つのオプションに大きな違いはありません。
Interlakenとは異なり、 Aurora protocol には channelsに関する記述がないことに注意してください。つまり、物理チャネルを介して送信されるすべてのデータは、1つのデータストリームに属します。 protocolで「channel」という用語が使用されている場合、これは物理チャネルを指し、データが独立したデータストリームに分割されていることを意味するものではありません。このような分割が必要な場合は、 application logicがこれを実装する役割を担っており、 packetごとに header を追加するなど、様々な方法が考えられます。
物理チャネル上のBit errors は protocolでは訂正されません。ただし、 protocol を用いて packetsを送信する場合、送信側は各 packet の末尾に CRC を任意に追加します( Xilinxによる protocolの実装)。 protocolの実装は、受信側でこの CRC をチェックし、パケットにエラーが検出された場合は application logic に通知します。 Aurora を packets なし( "last" signalなし)で使用する場合、 protocolによるエラー検出はサポートされません。
protocol自身の制御情報は、 bit errorsに対する保護なしに送信されます。このようなトラフィックには CRC は存在しません。物理リンク上に bit errors が存在する場合、 protocol は様々な形で誤動作する可能性があります。
再送メカニズム、複数チャネルの多重化、および送信スケジューリングは、 application logicで実装する必要があります。 flow control を Auroraで実装する可能性については、別のページで説明します。
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でよく使用されるエンコード方式をいくつか紹介します。