Flow control: MGTsで使用するための方法と protocols

このページは、 Multi-Gigabit Transceiver (MGT) を紹介する一連のページの 8 番目で最後のページです。

序章

Flow control は、様々な種類のデータリンクでよく使用されるメカニズムです。このメカニズムの目的は、送信されるデータ量が受信側で処理できる量を超えてしまう状況を防ぐことです。

MGTs に関連するProtocols は、この機能に対して異なるレベルのサポートを提供しています。例えば、 PCIe protocolを実装した logic は、受信側の buffers が満杯の場合、 packet の送信を決して受け入れません。 PCIe protocol を使用する application logic は、この点に関して何も実装する必要はありません。むしろ、 application logic と PCIe protocol logic 間のインターフェースにより、 protocol は一時的に新しいデータの受信を拒否することができます(例えば、 VALID や READYなどの AXI-S ports の助けを借りて)。同様に、 application logic は、反対側から到着するデータの受信を一時的に拒否することができます。これにより、 application logic は overflowから自身を保護します。

flow control を、 MGT自身の elastic bufferで overflow を防止するために使用されるメカニズムと混同しないことが重要です。 Flow control は、 MGT自身の buffersに関するページで言及されている skip symbols とは全く関係がありません。むしろ、 flow control は application logicの buffersを保護します。また、 MGT を共有リソースとして使用するデータチャネルが複数存在する場合が多いため、 flow control は各チャネルに対して個別に独立して適用されます。

一般的に、コンピュータとの通信を定義する protocols は、 flow control のメカニズムを担います。 application logic は、他の多くの logic blocksと同様に、シンプルな handshake portsを介して protocol logic とのインターフェースのみを必要とします。PCIeに加えて、 SuperSpeed USBとSATAは flow control を独自に処理します。

残念ながら、 FPGAs 間の通信用の protocols は、通常、このレベルでは flow control をサポートしていません。 flow control を完全にサポートする protocol はXillyp2pのみです。 FPGAs 用の他の protocols には、 application logicに flow control を実装する際に役立つ可能性のある機能がいくつかあるだけです。

このページでは、 flow controlを実装するためのいくつかのテクニックについて説明します。 Aurora と Interlaken が flow control をどのようにサポートするかについては、後ほど簡単に説明します。ただし、 Xillyp2pを使用する場合を除き、 overflowを防ぐのは application logic であることを覚えておくことが重要です。

Flow control テクニック

flow control の究極の目標は、受信側が処理能力を超えるデータを受け取る状況を防ぐことです。通常、受信側は到着したデータを buffers (または FIFO)に格納するため、 buffers にすべての到着データのためのスペースが確保されることが重要です。

Flow control を MGTsで使用するための実装は、主に物理チャネルの遅延が大きいため、より困難です。そのため、データ送信停止要求が送信機に到達するまでに時間がかかります。さらに、送信機がデータ送信を停止してから受信機にデータが到着しなくなるまでにも、一定の時間がかかります。

MGTs のもう 1 つの難点は、物理チャネル上の bit errors によって、データの送信を停止する要求が失われる可能性があることです。

これら 2 つの困難に加えて、 MGTs のデータ レートは高く、通常、この物理データ チャネルを効率的に使用することが期待されます。

serial port (RS-232)のようなより単純な通信チャネルと比較して、 MGT 用の flow control は、 overflow が発生しないことを保証するために、より高度な技術を必要とします。以下では、以下の3つの技術について説明します。

• XON / XOFF
• 期間限定 XOFF (「Pause」)
• Credits

プロジェクトで protocol を使用することを検討する場合、次の 2 つの質問をすることが重要です。

• flow controlと比較して、 application logic は何を実装する必要があるのでしょうか? おそらく、 PCIe、 SuperSpeed USB 、 Xillyp2pと同様に、何も実装する必要はないでしょう。
• application data が異なるチャネルに属している場合: flow control メカニズムでは、各チャネルの通信を個別に一時停止できますか? それとも、物理チャネルを通過するすべてのトラフィックに影響しますか?

In-band および out-of-band

これら 3 つの手法について個別に説明する前に、 in-band flow control と out-of-band flow controlを区別することが重要です。

flow control のあらゆるメカニズムにおいて、受信側はデータフローを調整するために、送信側にリクエストや情報を送信する必要があります。多くの実用的な使用シナリオでは、双方向に物理データチャネルが存在します。つまり、受信側にも、データを送信するための同等の物理チャネルが逆方向に存在します。

反対方向にそのような物理チャネルが存在する場合、そのチャネルが flow control リクエストの送信に使用されるかどうかが問題となります。チャネルがこのように使用される場合、このメカニズムは in-band flow controlと呼ばれます。そうでない場合は、 out-of-band flow control が適用されます。

一般的に言えば、 out-of-band flow control は、特にこの目的のために別々の物理的な配線が必要となるため、あまり洗練されたソリューションとは言えません。しかし、 MGTのチャネルが単方向である場合、これが唯一の選択肢となります。

このトピックについては、 Interlaken が flow controlを実装する方法に関連して以下でさらに詳しく説明します。

さて、次は 3 つの flow control テクニックについて説明します。

XON / XOFF

XON / XOFF は transmit on / offの略称です。これは最もシンプルな flow control のメカニズムですが、いくつか重大な欠点があります。

この方法はさまざまな方法で実装できますが、考え方は常に同じです。 受信側は、これ以上データを受け付けられない場合、送信側に対し「今すぐ送信を停止する」という意味のメッセージを送信します。これが XOFF です。その後、受信側がデータを受付可能になった時点で、データフローの再開を要求するために XON が送信されます。これらの要求は単純なため、 in-band と out-of-bandの両方の伝送に適しています。

MGT を用いた flow control に関して上記で述べたすべての問題点は、 XON / XOFF 方式でも実証されています。最初の問題点は、 XOFF 要求が送信機に到達するまでに時間がかかることです。 送信側は、この要求が到着するまでデータの送信を続けます。さらに、要求が到着した時点で既に物理チャネル上にあるデータは、受信側にも引き続き到着します。

したがって、受信側は、後から到着するデータを処理できるように、 XOFF を十分に早く送信する必要があります。しかし、どれくらい早く送信すれば十分なのでしょうか?これは物理チャネルのラウンドトリップ時間に依存します。場合によっては、このパラメータが既知であるか、少なくともラウンドトリップ時間が短いことが分かっています。

例えば、 SATA protocol は XON / XOFFを使用します。これは理にかなっています。 protocol は、 SATA controllerに物理的に近いハードディスクとの通信を目的としているからです。2つのリンクパートナー間の距離が不明で、かつ距離が長い可能性がある場合、 XOFFを要求する最適なタイミングを定義することは困難です。

もう一つの要素は、送信機が XOFFを受信したときに直ちに停止できるかどうかです。例えば、送信内容が packetsで構成されている場合、 protocol では packetの途中で送信を停止できない可能性があります。 XOFF または XONを送信する条件を定義する際には、あらゆるシナリオを考慮する必要があります。

もう一つの問題は、 bit error などの物理チャネルの障害によって XOFF メッセージが失われた場合に何が起こるかということです。この場合、送信側はデータフローを継続し、 overflowが発生する可能性があります。そのため、 protocol は、 XOFF 要求が失われる可能性がある場合に、送信を確実に停止する必要があります。 Interlaken がこの問題にどのように対処するかについては、以下を参照してください。

このメカニズムを要約すると次のようになります。 XON / XOFF 法は簡単な概念に基づいていますが、この方法を用いて overflow 法が決して発生しないことを保証するのは残念ながら困難であり、予期せぬ事態に細心の注意を払う必要があります。以下で説明する credits 法は、この逆の考え方に基づいています。 理解するのは複雑ですが、目的は簡単に達成できます。

期間限定 XOFF (「Pause」)

時間制限のある XOFF は、 XON / XOFF メソッドのバリエーションです。 flow control 要求には番号が付けられています。この番号は、送信機がこの要求を受信した時点から、データ送信を一時停止する時間を示します。より正確には、送信機がデータを送信すべきでない clock cycles の番号です。この方法は Ethernet Pause frameに似ています。

この方法の利点は、後で XON を使用する必要がないことです。この機能は特定の状況では役立ちますが、その場合でもメリットは非常に小さいです。

ここで時間制限のある XOFF について言及されている唯一の理由は、このメソッドが Aurora Protocolの一部であるためです。

Credits

Credits は、通信チャネルの初期化以降に送信可能なデータ要素数の制限です。この数値は、 protocolで定義された制御チャネルを介して、受信側から送信側へ送信されます。これにより、受信側は送信されるデータの量を制御します。

これは簡単な例で説明するのが一番です: 受信側の buffer が当初1000個のデータ要素を受信できるとします。したがって、 buffer は送信側に credits が1000個のデータ要素であることを通知するメッセージを送信します。送信側は1000個のデータ要素をすぐに送信することも、後から送信することもできます。ただし、 credits が更新されない限り、送信側が送信するデータ要素の総数は1000個を超えることはありません。

しばらく時間が経過し、500個のデータ要素が受信側に到着しました。この間に、 application logic は100個のデータ要素を消費しました。この状況では、 bufferには400個のデータワードがあるため、 bufferにはさらに600個のデータ要素を格納できる余裕があります。

この時点で、受信側は別のメッセージを送信し、 credits を1100に更新します。これは、すでに500個のデータ要素が到着しており、 application logic が bufferのデータを使用しなくても、さらに600個のデータ要素が送信可能であることを示しています。したがって、送信側が開始から合計1100個のデータ要素を送信した場合、 buffer は満たされます。これを別の視点から見ると、次のようになります。 受信側は、 bufferから消費されるデータ要素の数に応じて、常に credits を増加させます。

このメカニズムにより、送信側は受信側が許容するデータ量を超えるデータを送信しないため、 overflow 攻撃を確実に防ぐことができます。ただし、この方法には2つの小さな問題があります。

最初の問題は、受信側と送信側が送信データ要素数がゼロとなる開始点について合意する必要があることです。これには、双方が countersをリセットする何らかの初期化手順が必要です。 credits を使用するすべての protocols には、何らかの初期開始手順があります。これにより、双方が同時に state から別の state に切り替える必要があるため、 protocolは複雑になります。

2つ目の問題は、データフローが永久に継続できる必要があることです。 credits は常に増加し続けます。 credits を限られたビット数の数値として送信するにはどうすればよいでしょうか?この質問への答えは、 credits のバイナリ表現の下位部分(つまり LSbsのみ)を送信すれば十分だということです。送信機は、送信したデータ要素の数を表すために、同じ数の bits を使用します。

送信側は credits を、送信可能なデータ要素数を計算するためだけに使用するため、これで十分です。この数は、 credits から既に送信済みのデータ要素数を差し引いて計算されます。この結果、受信側における buffer のサイズを超える数値にはなりません。この数値が 2ⁿより小さい場合、 n LSbs より上の bits はすべてゼロになります。したがって、これらを計算するのは無意味です。 n bitsのみで減算すれば十分です。したがって、 flow control リクエストでは、 credits のバイナリ表現の下位 n bits のみが必要です。

たとえば、 PCIeの flow control は、 flow control が保護する buffer のタイプに応じて、 8 bits または 12 bitsで構成されるバイナリ ワードとして credits を送信することに基づいています。

credits を使用すると多くの利点があります:

• flow control リクエストが失われた場合、 overflowにはリスクはありません。 credits は送信停止を要求する XON / XOFFとは異なり、より多くのデータを送信する許可を与えます。したがって、 credits の更新が失われた場合、送信機は許可されたデータ量よりも少ないデータを送信することになります。その結果、 overflow が発生することはありません。
• credits メカニズムは、物理チャネルの遅延が不明で、かつ遅延が大きい可能性がある場合でも効率的です。 flow control リクエストの遅延を補うために、データフローを一時停止する必要はありません。
• 送信機は、 flow controlによって途中で停止することなく packet を送信できるかどうかを事前に把握しています。そのため、 packets を連続して送信することが可能です。

Flow control と Interlaken

Interlaken protocol については別のページで簡単に紹介されています。

flow controlについて説明するにあたり、 protocol は各データバーストにチャネル番号(通常は0~255)を割り当てる点に留意してください。つまり、 protocol は、物理チャネルを共有する複数の application data ストリームという概念に基づいています。したがって、 flow control のメカニズムは、 application data の各ストリームを独立して制御します。

この protocol には、2 種類の flow control メカニズムが用意されています。 In-band flow control と out-of-band flow control (OOBFC)。どちらも XON/XOFF メカニズムです。ステータスは、 channelごとに1つの bit によって伝達されます。この bit は、このチャネルがデータ受信可能な状態(XON)の場合は「1」、そうでない場合は「0」(XOFF)となります。

これら 2 つのメカニズムの違いは、 bits がどのように送信されるかです。 in-band flow control メカニズムは、各バーストの前後に control word が送信されるという事実に基づいています。この control word は 64 bitsで構成され、そのうち 16 bits は flow controlに割り当てられます。これにより、 control wordごとに最大16個の XON / XOFF 要求が可能になります。ただし、これは最大256チャネルをサポートするには不十分です。 各チャネルには独自の XON / XOFF bitがあります。これを解決するために、 flow control 情報は複数の control wordsに分割されます。この方法はcalendarと呼ばれます。 control word 内の Bit 56 は「Reset Calendar」と呼ばれます。この bit が「1」の場合、 control word にはチャネル0から15に関する XON / XOFF リクエストが含まれます。続く control word にはチャネル16から31のリクエストが含まれます。以下同様に続きます。すべてのチャネルがカバーされると(場合によっては control wordが1つだけの場合もあります)、シーケンスは「Reset Calendar」を使用して再開されます。

バーストの CRC24によって bit error が検出されると、すべてのチャネルが XOFF 状態になります。これは、 CRC24 が control wordもカバーしているため、エラーが検出された場合、 flow control 部分は無視されるためです。したがって、このようなイベントが発生した後は、どのチャネルでも送信することは安全ではありません。その後の control words における flow control 要求に基づいて、通常の動作が徐々に再開されます。

in-band flow control の主な欠点は、 XON / XOFF 要求の配信が、同じ方向に送信されるデータバーストに依存することです。これらのバーストが長い場合、または一定期間バーストが全く送信されない場合、 XON / XOFF の配信に時間がかかることがあります。これは、同じ物理チャネルで送信されるデータトランスポートメッセージと flow control メッセージが帯域幅を奪い合うのは避けられないため、ある程度は正当化されます。しかし、他の protocols は通常、一貫した最大遅延を保証する方法で flow control メッセージを優先します。

out-of-band flow control (OOBFC)方式は、データバーストとの競合を回避します。この方式では、 XON / XOFF リクエストは3本の追加の物理線(FC_CLK、 FC_DATA 、 FC_SYNC)を介して送信されます。すべてのチャネルの XON / XOFF bits は、1本の長い frameで送信されます。

FC_SYNC signal は、この frameの最初の bit と合わせて high になります。 FC_CLK の frequency は 0 と 100 MHz の間にあり、 DDR clocking も許可されます。 4 bits (CRC-4)で構成される CRC は、64回の XON / XOFF 要求の後、または最後の XON / XOFF 要求の後に挿入されます。 CRCによってエラーが検出された場合、すべてのチャネルは XOFF 状態になります。

もちろん、 in-band flow control と out-of-band flow control のどちらを選択するかは、プロジェクトの要件によって異なります。

Interlaken には、チャネルからのデータを多重化するメカニズムが組み込まれていません。したがって、チャネルからのデータ送信要求を調停し、バースト(または packet全体)の送信にどのチャネルがアクセスするかを選択するのは、 application logicの役割です。したがって、 application logic は、 XOFFから要求された場合、チャネルの送信を一時停止する役割も担います。 Interlaken protocol を実装した logic は、 XON / XOFF 要求の送受信のみを担当します。

protocol では、 credits を flow controlの実装方法として言及していますが、これは専用チャネルを利用してこの方式を実装するためのオープンな提案に過ぎません。 protocol では、これを実装する方法についての詳細は記載されていません。

Flow control と Aurora

Aurora protocol については別のページで簡単に紹介されています。この protocol では、 flow controlを容易にするための2つのメカニズムが提案されています。 NFC と UFC。これら2つについては、以下で個別に説明します。

まず、 Native Flow Control (NFC): このメカニズムにより、受信側の application logic は送信側に flow control リクエストを送信するためのインターフェースを備えています。これらのリクエストは2つの部分に分かれています。 XOFF bit と時間制限付きの XOFF (「pause」)部品(どちらの概念も上記で説明済み)。送信側の protocolの logic は、以下の要求に従う役割を担います。 XOFF bit が「0」の場合、送信機は flow control 要求に含まれる8ビットの数値に対応する clock cycles の数だけデータ送信を一時停止します。この数値が0の場合、データ送信は直ちに再開されます。要求内の数値は累積されません。代わりに、 NFC 要求ごとに一時停止のカウントダウンが新しい値に更新されます。

XOFF bit が「1」の場合、送信機はデータ送信を無期限に停止します。送信機は、 flow control 要求に XOFF = '0' が応答した場合にのみデータ送信を再開します。このような要求は前述のように処理されます。

この flow control メカニズムは、物理データチャネルを介したすべてのデータトラフィックを制御することに注意してください。したがって、 NFC は、複数のチャネルを個別に制御する実装には適していません。

2番目のメカニズムは User Flow Control (UFC)です。 実際には、これは最大256バイトのメッセージを相手側に送信するための別のチャネルです。 UFC メッセージはデータ送信よりも優先度が高いため、低遅延で相手側に到達します。

プロトコルではこれらのメッセージのフォーマットが定義されていないため、あらゆるタイプの flow control を実装するために使用できます。このような実装は application logicで完全に行われます。 UFC メッセージは、他のあらゆる種類のステータス情報の送信にも使用できます。

これら2つの flow control メカニズムで使用されるメッセージはいずれも、物理リンク上の bit errors から保護されていないことに注意してください。そのため、 flow control 要求は誤って到着したり、まったく到着しなかったりする可能性があり、受信側で overflow が発生する可能性があります。

両方のフロー制御メカニズムは反対方向のデータ リンクに基づいているため、これらは full duplex モードでのみ使用できます。

概要

このページでは、主に flow control に関する 2 つのテクニックを紹介しました。 XON / XOFF と creditsです。コンピュータ関連の protocols (例: PCIe、 SuperSpeed USB 、 SATA)については、 flow control は protocol logicによって実装されます。一方、 FPGAs間の通信を目的とした protocols については、 application logic が実装のすべてまたは大部分を担います。唯一の例外は Xillyp2pで、 flow control、エラー検出、再送信を含むデータ通信のあらゆる側面を処理します。

FPGAs 向けの 2 つの protocols の flow control 関連機能が紹介されました。 Interlaken と Aurora。ご覧のとおり、これらの protocols は、特定の使用シナリオでは protocol自身の機能によって一部の作業を実行できる可能性があるにもかかわらず、 flow control の実装という大きな負担を application logicに委ねています。

これで、 MGTsに関するこのシリーズの最後のページは終了です。