01signal: マルチギガビット・トランシーバを用いた FPGA 間通信のためのプロトコル一覧

このページは、マルチギガビット・トランシーバ(MGT)を紹介する一連のページの 2 ページ目です。

はじめに

MGT は、よく知られた多くのプロトコルの基本構成要素です:PCIe、SATA、Gigabit Ethernet、SuperSpeed USB、Thunderbolt、DisplayPort など。これらのプロトコルには共通点が 1 つあります。必ずコンピュータが関わっていることです。電気通信向けのプロトコルもいくつかあり、光ファイバリンクで電話を伝送する用途を想定しています。

また、MGT は 2 つの FPGA 間でデータをやり取りするのにも有用です。この目的で MGT を使う際に注意すべき点をいくつか、前のページに挙げました。物理的なチャネル上でデータを正しく、許容できる信頼性で伝送するには、何らかのプロトコルが必要です。そのようなプロトコルの実装はかなり複雑です。そこで、既製のプロトコルや、役に立つ他の構成要素がないかが問題になります。

このページでは、主な選択肢の概要をまとめます。アプリケーションロジック(application logic)の複雑さの順に、簡単なものから挙げています。

特に断りがない限り、以下に挙げるプロトコルはすべて、双方向リンク(全二重)としても、片方向リンク(半二重)としても動作します。

Xillyp2p

Xillyp2p は、2 つの FPGA 間で複数のデータストリームを確実に転送する独自プロトコルです。このプロトコルは、アプリケーションデータの伝送、スケジューリング、再送、フロー制御(flow control)を、TCP/IP がネットワーク上でデータを転送する方法と同様に管理します。すべてのデータが相手側に正しく届くことが保証されます。

アプリケーションロジックは、標準的な FIFO を介してプロトコルの実装とやり取りします。プロトコルは、2 つの FPGA にまたがる標準的な FIFO のような動作を提供します。この仮想 FIFO の書き込み側は一方の FPGA にあり、読み出し側はもう一方の FPGA にあります。

2 つの FPGA のそれぞれにおいて、FIFO の一方の側はアプリケーションロジックに接続され、もう一方の側はプロトコルのロジックとやり取りします。つまり、送信側 FPGA のアプリケーションロジックは FIFO にデータを書き込み、受信側 FPGA のアプリケーションロジックは別の FIFO からデータを読み出します。プロトコルは、送信側 FPGA の FIFO から受信側 FPGA の FIFO へデータを移動させる役割を担います。また、プロトコルのフロー制御により、宛先 FPGA の FIFO が full(満杯)状態になることはありません。

このプロトコルは、双方向で複数の FIFO を扱えます。公平なデータ送信スケジューラにより、MGT の帯域幅が効率的に利用されます。送信側 FIFO 内のデータは十分な速さで消費されるため、その FIFO が full(満杯)になることはありません(帯域幅がそれを許し、相手側の FIFO からデータが消費されている限り)。

また、パケットを送信するための別のインターフェースも備えています(EOP ポートを使用)。

半二重オプションもサポートされています。この場合、プロトコルは到着するすべてのデータが正しいことを保証します。物理チャネルでビット誤りが発生すると、誤ったデータがアプリケーションロジックに届く前に、データフローが停止されます。

Gigabit Ethernet

Gigabit Ethernet はコンピュータ間の通信を目的としていますが、この単純なプロトコルを使って 2 つの FPGA 間でパケットを送ることも可能です。通常、適切な IP コア(IP core)は FPGA メーカーから提供されます。したがって、アプリケーションロジックは、標準的なインターフェース(GMII、RGMII、XGMII など)を介して Ethernet パケットを生成し受信する役割を担います。

どの Ethernet リンクでも同じですが、データをパケットにまとめ、リンク上のエラー(再送など)を処理するのはアプリケーションロジックの役割です。

Interlaken

Interlaken は、チップ間でパケットを通信するためのオープンなプロトコルです。これは 64b/67b エンコーディングに基づいています。低レベルのデータフローは、64 ビットのセグメントを繰り返し送信することで構成されます。各セグメントの前には、アプリケーションデータと制御ワードを区別するために 3 ビットが追加されます。このプロトコルは、シンプレックスリンク(片方向物理チャネル)向けに定義されています。全二重リンク(双方向物理チャネル)を使用する場合も、フロー制御メッセージを逆方向に送れることを除けば、シンプレックスリンクと同じように動作します。

このプロトコルの基本となる伝送単位は、可変長のバースト(burst)です。各バーストの直前と直後には、それぞれ制御ワードが送信されます。これらの 2 つの制御ワードには、パケットとチャネルの抽象化を可能にする情報が含まれます。その情報には、次のようなものがあります。

チャネル番号:0〜255 の数値で、後続のデータバーストを特定のチャネルに関連付けます。チャネル数は最大 65536 まで拡張できます。
SOP:後続のデータがパケットの先頭であることを示すフラグです。
EOP:制御ワードの直前のバーストが、パケットの最後のデータであることを示すフラグです。EOP は、バーストの最後のワード内の有効バイト数と、パケットにエラーが含まれるかどうかも示します。

各バーストの長さは、BurstMax を超えてはならず、BurstShort より短くてもいけません。BurstMax と BurstShort はどちらも、特定のアプリケーション向けに選ぶパラメータです。BurstShort は最低 32 バイト(かつ 8 の倍数)で、BurstMax は 64 バイトの倍数でなければなりません。

制御ワードと、その直前にある(場合もある)データバーストの内容は、CRC24 を使ってビット誤りがないか検査されます。

バーストが CRC24 テストに失敗した場合(すなわちビット誤りが検出された場合)、Interlaken Retransmit Extension Protocol Definition で定義されているとおり、再送を要求できます。その推奨メカニズムでは、この要求は、受信側から送信側へ向けて 3 本の物理配線を通して送られます。これらの配線は FC_CLK、FC_DATA、FC_SYNC という名前で、もともとは帯域外フロー制御(OOBFC)用に意図されたものです。フロー制御要求を送るための単純なシリアルデータ伝送プロトコルが定義されています。再送が有効になっている場合、これらのビットの 1 つは「RT」と呼ばれ、再送要求に使われます。言い換えると、このプロトコルは、再送要求を MGT リンク自体で送る方法を定義しておらず、3 本の別個の帯域外物理配線で送るのです。

再送要求には、どのバーストから再送を開始すべきかという情報は含まれません。代わりに、送信側は一定量のバーストデータをバッファに保存しておく必要があります。再送要求が到着すると、バッファ内のすべてのバーストが再送されます。したがって、バッファのサイズは、失われたバーストを収められるだけの大きさが必要です。しかし、バッファが大きすぎると、再送が必要以上に長くなります。バッファサイズを決めるには、Interlaken プロトコルを実装するロジックにバーストを渡してから再送要求が到着するまでの往復時間(round-trip time)を注意深く計算する必要があります。

受信側は、最初に送信されたバーストごとに増分されるカウンタを利用して、再送バーストを検出します(2、4、8 バーストごとに増分することも可能)。このカウンタの値は、各バーストの前後に送信される制御ワードの Multiple-Use 部分に載せて送られます。受信側はこのカウンタを使って、新しいバーストと再送バーストを区別します。

Interlaken プロトコルには、診断目的の CRC32 チェックもあります(各メタフレーム(Meta Frame)につき 1 回)。しかし、この検査でエラーが検出された場合、それはデータの大きな区間に関係しており、特定のバーストやパケットを指し示すものではありません。つまり、ビット誤りがあるにもかかわらず CRC24 テストを通過したデータは、後になって初めて検出されますが、その時点では誤りを含むバーストを特定できません。

再送メカニズムは、逆方向の MGT データフローを利用して設計・実装することも可能です。Interlaken プロトコルはそのような再送メカニズムの方法を示していませんが、再送を要求するパケット専用のチャネルを割り当てることは可能です。このような解決策には、何を再送するかをより具体的に要求できるという大きな利点があります。また、バースト単位ではなくパケット単位で、より優れた CRC を適用することも可能です。ただし、この方法を取る場合は、メカニズム全体をアプリケーションロジックで実装しなければなりません。

Interlaken のフロー制御メカニズムについては、別のページで説明します。

Aurora

Aurora は、Xilinx(現在は AMD)が自社の FPGA 向けに開発したプロトコルです。このプロトコルの基本伝送単位は、単一のワードです(関与する MGT の数に応じて固定幅が決まります)。ただし、パケット(フレームと呼ばれる)の送信もサポートしています。アプリケーションロジックは、「last」入力ポートを使ってデータストリームをパケットに分割します。

Aurora には 2 つのバリアントがあります。8b/10b エンコーディングを使うものと、64b/66b エンコーディングを使うものです。64b/66b エンコーディングの方が効率的なので、可能であればこちらを選ぶべきです。

Aurora は、シンプレックスリンク(片方向物理チャネル)と全二重リンク(双方向物理チャネル)の両方で定義されています。フロー制御がシンプレックスリンクでは意味を持たないことを除けば、アプリケーションロジックの観点では、2 つの選択肢の間に大きな違いはありません。

Interlaken とは異なり、Aurora プロトコルにはチャネルという概念が登場しないことに注意してください。言い換えると、物理チャネル上で伝送されるすべてのデータは、1 つのデータストリームに属します。プロトコルで「チャネル」という言葉が使われる場合、それは物理チャネルのことであり、データを独立したストリームに分割することを指していません。そのような分割が必要なら、各パケットにヘッダを付けるなどの方法でアプリケーションロジックが実装する役割を担います。

物理チャネル上のビット誤りは、プロトコルでは訂正されません。ただし、このプロトコルでパケットを送信する場合、送信側は各パケットの末尾に CRC を付加することができます(Xilinx によるプロトコル実装の場合)。プロトコルの実装は受信側でこの CRC を検査し、パケットにエラーが検出された場合にアプリケーションロジックへ知らせます。Aurora をパケットなしで使う場合(「last」信号なし)、エラー検出はプロトコルではサポートされません。

プロトコル自身の制御情報は、ビット誤りに対する保護なしで送信されます。そうしたトラフィックには CRC が一切ありません。物理リンクにビット誤りがあると、プロトコルはさまざまな形で誤動作する可能性があります。

再送メカニズム、複数チャネルの多重化、送信スケジューリングはいずれも、アプリケーションロジックで実装する必要があります。Aurora でフロー制御を実装する可能性については、別のページで説明します。

Serial Lite

Altera には、Serial Lite という名前を共有する一連のプロトコルと IP コア(IP core)があります。

SerialLite II:パケットベースまたは非パケットのデータ送受信インターフェース(「Atlantic Interface」と呼ばれる)。ビット誤りに応じた再送をサポート。対応 FPGA は初期の製品のみ(Arria II からシリーズ V FPGA まで)。
Serial Lite III:Continuous モードと Burst モードをサポート。Continuous モードでは、データストリームは送信側と受信側の間で途切れることなく、隙間なく流れ続けます。そのため、両側が同じ基準クロックに依存している必要があります。このプロトコルの内部は Interlaken に基づいていますが、チャネルや SOP/EOP はサポートされません。したがって、インターフェースのデータ幅は、使用する MGT の数を 64 ビットに掛けた値になります。物理リンク上のビット誤りは、それを引き起こした MGT に関する診断イベントとして報告されますが、特定のデータ区間との関連では報告されません。対応 FPGA はシリーズ V FPGA とシリーズ 10 FPGA です。
Serial Lite IV:パケットの開始と終了を示す信号を備えた Avalon Streaming Interface に基づく(MAC)。送信側がパケット末尾に CRC を挿入し、受信側が検査するオプションがあります。また、パケット分割を行わない Basic モードもあります。対応 FPGA は Stratix 10 と Agilex E-tile です。

これらの IP コアは、この一連のプロトコルの異なるメンバ間では互換性がありません。再送を開始できるのは SerialLite II だけです。

RapidIO

RapidIO は、パケットベースのプロトコルであり、サポートするパケットタイプが CPU が必要とする操作に対応しているという点で、PCIe に似ています。その操作には、次のようなものがあります。

Write:データをアドレスに書き込みます。この操作にはいくつかのバリアントがあり、そのうちの 1 つは操作が完了したことを示す応答を要求します。
Read:アドレスからデータを読み出す要求です。これに対して、ターゲットが応答パケットを送信します。
Atomic read-modify-write:以前の値を読み出した後に、アドレスへデータを書き込む要求をアトミック操作として行います。サポートされる操作には、アトミックインクリメントとアトミックデクリメント、アトミックスワップ、比較とスワップ(compare and swap)などがあります。
ディスカバリ、制御、ステータスのためのメンテナンス要求もいくつかあります。PCI プロトコルのコンフィグレーションレジスタ空間と同様に、これらのメンテナンス要求はケイパビリティレジスタ(CAR)とコマンド/ステータスレジスタ(CSR)にアクセスします。

RapidIO と PCIe の主な機能上の違いは、PCIe プロトコルでは、システム内のすべてのエンドポイントを中央ユニット(Root Complex、通常は CPU)が設定することが必要なことです。RapidIO システムには、そのような中央ユニットは必要ありません。

PCIe とのもう 1 つの違いは、パケットの再送がオプションであることです。再送が行われるのは、「reliable traffic(信頼性のあるトラフィック、RT)」として送信されたパケットだけです。パケットは「continuous traffic(連続トラフィック、CT)」として送信することもできます。このようなパケットは、確認応答も再送も行われません。

RapidIO プロトコルは、電気仕様からパケットフォーマット、再送、フロー制御まで、通信のすべての側面を定義しています。

RapidIO は、その複雑さのため、2 つの FPGA 間の単純なポイントツーポイント接続にはあまり魅力的な候補ではないかもしれません。RapidIO は、スイッチを介した複数 FPGA 間の相互接続に適している可能性があります。特に、システム内に CPU が必要なために PCIe が不向きな場合には有効です。

まとめ

ここまで、アプリケーションデータを伝送するためのいくつかのプロトコルを紹介しました。各プロトコルは、データの転送を実装し、そのフローを制御し、ビット誤りに(もしあれば)応答するための異なる方法を示しています。アプリケーションに適したプロトコルは、プロトコルが提供する機能と、足りない部分をアプリケーションロジックで実装するために必要な労力とのバランスで決まります。

以上で、MGT に関するこの一連のページの 2 ページ目を終わります。次のページでは、MGT でよく使われるいくつかの符号化方式を紹介します。