JP2015188215A - リトライバッファ及びリトライバッファを用いてリトライ動作を実行する方法 - Google Patents

Abstract

【課題】リトライ動作に対応するために、着信パケットストリームを一時停止するか、着信パケットストリームのパケットのうちの幾つかを廃棄する方法を提供する。【解決手段】送信エージェント１１０がパケットストリームをリトライバッファ２００に順次書き込み、リトライバッファに書き込まれたパケットを受信エージェント１３０に順次送信しつつ、追加のパケットをリトライバッファに順次書き込み続け、受信エージェントから肯定応答を受信しつつ、リトライバッファに書き込まれたパケットを受信エージェントに順次送信し続ける。送信パケットの受信不成功時には、受信エージェントからリトライ要求を受信し、リトライ要求が得られた送信パケットから開始して、リトライバッファから受信エージェントにパケットを再送するとともに、送信エージェントから受信された追加のパケットをリトライバッファに順次書き込み続ける。【選択図】図１

Description

一般に、従来の高速シリアルデータ伝送プロトコルは、或る形態の「リトライ」動作をサポートしている。このリトライ動作に従って、送信エージェント（例えば、ホストデバイス）によって送信され、受信エージェント（例えば、メモリデバイス）によって誤って又は失敗して受信されたパケット（例えば、データパケット）を、要求に応じて再送することができる。パケットの受信失敗は、例えば、高いビットエラーレートに基づいて判断することができる。リトライ動作は、受信エージェントが、送信エージェントからのパケットをバスの順方向リンク上で受信することに失敗し、その後、再送の必要があるパケットを識別する情報を、通常は戻りリンク上で送信エージェントに送信することを伴う。リトライ動作を可能にするために、パケットの受信に成功した（すなわち、それゆえにリトライ動作を必要としない）ことが受信エージェントによって確認されるまで、送信パケットを一時的に記憶するリトライバッファが設けられる。ここで、バッファリングされた送信パケットは、必要に応じて、無視されて上書きされる場合がある。受信に成功せず、受信エージェントがパケットの受信に成功したことを確認しないときは、リトライ動作が開始され、その結果、既知の送信成功の最後の時点からのバッファリングされたパケットが再送される。

ハイブリッドメモリキューブ（ＨＭＣ）プロトコル等の幾つかの伝送プロトコルは、ポインタ交換動作を用いて、再送の必要があるパケットを識別する情報を通信する。例えば、ＨＭＣプロトコルは、１２８ビットフローユニットからなるパケットを提供する。これらのパケットのそれぞれは、「ＦＬＩＴ」（「フローユニット（FLow unIT」）と呼ばれる。各パケットを用いて、リトライバッファ内のそのパケットの位置を表すリトライポインタが送信される。リトライポインタは、各パケットを用いて順方向リンク上を順方向に進む順方向リトライポインタ（ＦＲＰ）と、逆方向リンク上（例えば、順方向リンクの反対側）を逆方向に進む同じリトライポインタである逆方向リトライポインタ（ＲＲＰ）とを含むことができ、それによって、ラウンドトリップが完成する。リトライバッファは、ＦＬＩＴアドレスを用いてアドレス指定され、リトライポインタは、リトライバッファにおける対応するパケット位置を表す。例えば、送信エージェントによって送信される各パケットは、そのパケットがリトライバッファ内に記憶されているアドレスを示す８ビットＦＲＰフィールドを含む。同様に、受信エージェントから送信エージェントに返される各パケットは、最後に受信に成功したＦＲＰの値を示す８ビットＲＲＰフィールドを含む。したがって、送信エージェントは、返されたパケット上のＲＲＰフィールドを調べることによって、受信エージェントがどのパケットの受信に成功したのかを知ることができる。ＲＲＰは、逆方向リンク上を戻り、ラウンドトリップを完成させる同じリトライポインタである。ＨＭＣプロトコルのより詳細な内容は、例えば、ハイブリッドメモリキューブコンソーシアム（Hybrid Memory Cube Consortium）の「Hybrid Memory Cube」（2012）に記載されている。この文献の全内容は、引用することによって本明細書の一部をなすものとする。

しかしながら、ポインタ交換に基づくプロトコルを用いることの限界は、リトライバッファ内の許容可能な空間が、リトライポインタがアドレス指定するためにサイズ決めされた空間によって制限されるということである。したがって、そのような制限を回避するためにリトライバッファの空間を拡張する必要がある。さらに、着信パケットがリアルタイムでストリーミングされる場合、それらのパケットのバッファリングは、リトライ動作（既に送信されたパケットの再送）の実行を試みている間であっても続けなければならない。これらの状況の下、従来のシステムは、一般に、リトライ動作に対応するために、着信（リアルタイム）パケットストリームを一時停止するか、又は着信パケットストリームのパケットのうちの幾つかを廃棄することを必要とする。

２つの個別のメモリを有する２つのバッファを実装することによって、これらの問題に対処することができる。ここで、一方のバッファは、リトライバッファとして動作し、他方のバッファ（リトライバッファの上流に位置する）は、単なる先入れ先出し（ＦＩＦＯ）バッファである。しかしながら、各チップメモリは、付随したオーバヘッド（例えば、ＢＩＳＴ回路部）を有し、そのため、このアーキテクチャは、実際には、２倍のオーバヘッド及び２倍のチップ面積を有する。

代表的な実施形態では、パケットストリームのパケットをリアルタイムで送信する方法が提供される。この方法は、パケットを送信エージェントのリトライバッファに順次書き込むステップであって、前記リトライバッファは、複数のコンテキストを含む、書き込むステップと、前記リトライバッファに書き込まれた前記パケットを受信エージェントに順次送信するとともに、追加のパケットを前記リトライバッファに順次書き込み続けるステップと、前記受信エージェントが前記送信パケットの受信に成功したとき、前記受信エージェントから肯定応答を受信するとともに、前記リトライバッファに書き込まれた前記パケットを前記受信エージェントに順次送信し続けるステップと、前記受信エージェントが前記送信パケットの受信に成功しなかったとき、前記受信エージェントからリトライ要求を受信するステップと、前記受信エージェントが受信に成功せず、その結果、前記リトライ要求が得られた前記送信パケットから開始して、前記リトライバッファから前記受信エージェントに前記パケットを再送するとともに、送信エージェントから受信される前記追加のパケットを前記リトライバッファに順次書き込み続けるステップと、を含む。

別の代表的な実施形態では、パケットを受信エージェントに送信する方法が提供される。この方法は、パケットストリームのパケットをリトライバッファにリアルタイムで順次書き込むとともに、前記リトライバッファにおいて書き込みポインタを前進させることによって前記パケットの前記書き込みを追跡するステップと、前記リトライバッファに書き込まれた前記パケットを前記受信エージェントに順次送信するとともに、再生ポインタを前進させることによって前記パケットの前記送信を追跡するステップと、前記受信エージェントによる前記送信パケットの受信成功に肯定応答する情報を受信するとともに、読み出しポインタを前進させることによって前記受信成功を追跡するステップと、前記送信パケットが前記受信エージェントによる受信に成功しなかったとき、リトライ要求を受信するステップと、前記リトライ要求に応答して、前記再生ポインタを前記読み出しポインタの現在のロケーションに再配置するステップと、前記リトライ要求に応答して、前記再配置された再生ポインタから開始して、前記リトライバッファに書き込まれたパケットを前記受信エージェントに順次再送することによってリトライ動作を開始するとともに、前記再生ポインタを前進させることによって前記パケットの前記再送を追跡するステップと、を含む。前記パケットストリームの前記パケットは、前記リトライ動作中、前記リトライバッファにリアルタイムで書き込まれ続けるとともに、前記書き込みポインタによって追跡され続ける。

別の代表的な実施形態では、バスを介してパケットを受信エージェントに送信するための送信エージェントが設けられる。該送信エージェントは、トランザクションレイヤ及びリトライバッファを備える。前記トランザクションレイヤは、前記受信エージェントに送信されるパケットを発行するように構成されている。前記リトライバッファは、該送信エージェントの前記トランザクションレイヤからの前記パケットをリアルタイムで順次受信して記憶することと、前記バスの順方向リンクを介して、前記記憶されたパケットを前記受信エージェントに順次送信することであって、まだ送信されていない前記記憶されたパケットは、バッファリングされたパケットである、送信することと、前記受信エージェントが前記送信パケットの受信に成功したときに、前記受信エージェントから肯定応答を受信することであって、前記肯定応答がまだ受信されていない前記送信パケットは、ペンディング中のパケットである、受信することと、前記受信エージェントによる受信に成功していない前記送信パケットから開始して、前記ペンディング中のパケットを前記受信エージェントに順次再送することと、該送信エージェントの前記トランザクションレイヤからの前記パケットをリアルタイムで順次受信して記憶し続けるとともに、前記ペンディング中のパケットを順次再送することとを行うように構成されている。

代表的な実施形態は、以下の詳細な説明を添付図面の図とともに読むと、その説明から最も良く理解される。適用可能な箇所ではなるべく、同様の参照符号が同様の要素を指している。

代表的な実施形態によるデータ通信システムの簡略ブロック図である。 代表的な実施形態によるデータ通信システムのリトライバッファ及びリトライ動作の実行前の例示のポインタの簡略ブロック図である。 代表的な実施形態によるデータ通信システムのリトライバッファ及びリトライ動作の実行前の例示のポインタの簡略ブロック図である。 代表的な実施形態によるデータ通信システムのリトライバッファ及びリトライ動作の開始時の例示のポインタの簡略ブロック図である。 代表的な実施形態によるデータ通信システムのリトライバッファ及びリトライ動作の最中の例示のポインタの簡略ブロック図である。 代表的な実施形態による、パケットを受信エージェントにリアルタイムで送信する方法を示す流れ図である。

以下の詳細な説明では、限定ではなく説明の目的で、具体的な詳細を開示する例示の実施形態が、本教示による実施形態の完全な理解を提供するために明らかにされる。しかしながら、本開示内容の利益を有する者には、本明細書に開示した具体的な詳細から逸脱しない本教示による他の実施形態も、添付の特許請求の範囲の範囲内にあることが明らかであろう。その上、よく知られたデバイス及び方法の説明は、この例示的な実施形態の説明を分かりにくくしないために省略されている場合がある。そのような方法及びデバイスも、本教示の範囲内にある。

一般に、数量に指定がないもの（terms “a”, “an” and “the”）は、本明細書及び添付の特許請求の範囲で用いられるとき、文脈が明らかに別段の規定をしていない限り、単数形及び複数形の双方の指示対象を含むことが理解される。したがって、例えば、「デバイス」は、１つのデバイス及び複数のデバイスを含む。

「実質的な」又は「実質的に」という用語は、本明細書及び添付の特許請求の範囲で用いられるとき、それらの通常の意味に加えて、許容可能な限度内又は程度内にあることを意味する。例えば、「実質的にキャンセルされる」は、当業者であれば、キャンセルを許容可能であるとみなすことを意味する。更なる例として、「実質的に除去される」は、当業者であれば、除去を許容可能であるとみなすことを意味する。

「ほぼ（approximately）」という用語は、本明細書及び添付の特許請求の範囲で用いられるとき、その通常の意味に加えて、当業者に許容可能な限度内又は数量内にあることを意味する。例えば、「ほぼ同じ」は、当業者であれば、比較されているアイテムを同じとみなすことを意味する。

一般に、リトライバッファは、リンクエラーが発生した場合又は受信エージェントがそれ以外で送信パケットの受信に成功しなかった場合の潜在的な再送に備えて、送信エージェントから受信エージェントに送信されている着信パケットストリームからのパケットを一時的に記憶する。様々な実施形態によれば、リトライバッファは、書き込みポインタ、再生ポインタ、及び読み出しポインタに依拠して、記憶されたパケットのステータスを追跡する。書き込みポインタは、着信パケットが記憶されるごとに前進される。再生ポインタは、各発信パケットが受信エージェントに送信されることによって前進され、読み出しポインタは、送信パケットの受信に成功した肯定応答によって前進される。

上述したＨＭＣプロトコルによれば、例えば、送信エージェントによって送信される各パケット（例えば、データパケット）は、そのパケットがリトライバッファ内に記憶されるアドレス（書き込みポインタ）を示す８ビットのＦＲＰフィールドを含み、受信エージェントから返される各パケットは、最後に受信に成功したＦＲＰ（読み出しポインタ）の値を示す８ビットのＲＲＰフィールドを含む。しかしながら、８ビットのポインタフィールドを各パケットに組み込むことによって、アドレス指定可能空間は、２５６個のユニットにのみ制限される。このアドレス指定可能空間は、１つの「コンテキスト」として定義される。すなわち、従来のリトライバッファ空間は、２５６個のユニットに制限される。さらに、ＨＭＣプロトコルの場合、特に、２５６個のユニットはパケットではなくＦＬＩＴであるので、各パケットは、通常、複数（整数個）のＦＬＩＴからなる。したがって、ほとんどのパケットはマルチＦＬＩＴパケットであるので、２５６個よりも実質的に少ないパケットが、２５６個のユニットに記憶される場合がある。例えば、各パケットが９ＦＬＩＴ長である場合、２５６個のユニットに制限される単一のコンテキストリトライバッファは、２８個のパケット（それぞれ９個のＦＬＩＴからなる）しか記憶することができない。したがって、ＲＲＰが受信されると、読み出しポインタは、書き込みポインタに遅れてリトライバッファアドレス空間を回り、これによって、やがてリトライバッファアドレス空間を折り返して先頭に戻る、あるいは、ラップアラウンドし、ＦＲＰの受信成功の肯定応答をまだ受信していないペンディング中のパケットに追いつく場合がある。その結果、パケットストリームの流れが中断される。

一般に、本発明の様々の代表的な実施形態は、複数のコンテキストを組み込んだ（したがって、例えば、２５６個のユニットからなる１つのコンテキストを有する従来のリトライバッファよりも大きい）単一の拡張されたリトライバッファを実施することによって、この問題に対処する。この実施形態では、リトライバッファの各コンテキストは、アドレス指定可能パケット空間よりも大きくない（例えば、上記例における２５６個のＦＬＩＴよりも大きくない）。しかしながら、任意の所与の時点において、リトライバッファの複数のコンテキストがアクティブである場合があり、そのため、多数のリトライ動作が実行されている場合に、この拡張されたリトライバッファの全利益を、「バッファリングされる」パケットを記憶するのに利用することができる。

図１は、代表的な実施形態によるデータ通信システムの簡略ブロック図である。

図１を参照すると、データ通信システム１００は、送信エージェント１１０と、受信エージェント１３０と、バス１４０とを備える。送信エージェント１１０は、トランザクションレイヤパケット（パケットストリーム）の着信パケットストリームを生成するトランザクションレイヤ１０５と、送信パス１１５と、リトライバッファ２００とを備える。このリトライバッファは、バス１４０を介した受信エージェント１３０へのパケットの送信をバッファリングするとともにリトライ動作を管理するバッファメモリとして実施される。例えば、以下で論述するように、リトライバッファ２００は、受信エージェント１３０によるパケットの受信成功（成功パケットと呼ばれる場合がある）を追跡し、受信に成功したとの肯定応答がなされていないあらゆるパケット（不成功パケットと呼ばれる場合がある）を、その不成功パケットの送信後であって受信不成功の表示の受信前に受信エージェントに引き続き送信されたあらゆるパケットとともに送信することをリトライする。バス１４０は、リトライバッファ２００から受信エージェント１３０にパケットを送信するための順方向リンク１４１と、受信エージェント１３０からリトライバッファ２００にパケットの成功又は失敗に関する情報を送信する戻りリンク１４２とを有する。例えば、戻りリンク１４２上で受信される肯定応答は、対応するパケットの受信成功を示すのに用いることができる。

図２及び図３は、代表的な実施形態によるデータ通信システムのリトライバッファ及びリトライ動作の実行前の例示のポインタの簡略ブロック図である。

図２及び図３を参照すると、リトライバッファ２００は、代表的な第１のコンテキスト２１０（ＦＲＰ空間０）と、第２のコンテキスト２２０（ＦＲＰ空間１）と、第３のコンテキスト２３０（ＦＲＰ空間２）とによって示される複数のコンテキストを備える。第１のコンテキスト２１０〜第３のコンテキスト２３０は、それぞれＦＲＰ空間０〜２として参照される場合がある。なぜならば、単一のコンテキストは、上記で論述した８ビットのＦＲＰ（アドレス）フィールドによってアドレス指定可能であるが、リトライバッファ２００等のマルチコンテキストフルバッファは、より多くの数のアドレスに起因して、８ビットのＦＲＰフィールドによってアドレス指定可能でないからである。すなわち、リトライバッファ２００の第１のコンテキスト２１０〜第３のコンテキスト２３０のそれぞれは、２５６個のＦＬＩＴであるアドレス指定可能空間よりも大きくならないように制限される。しかしながら、本例では、例示の目的で、アドレス指定可能空間は、第１のコンテキスト２１０〜第３のコンテキスト２３０のそれぞれの２３４個のＦＬＩＴに制限される。また、本例では、各パケットは、９ＦＬＩＴ長（例えば、リトライバッファ２００の最上行に示すＦＬＩＴ０〜８）に仮定され、それゆえ、各コンテキストは、２６個のパケットを含む。したがって、第１のコンテキスト２１０はＦＬＩＴ０〜２３３を含み、第２のコンテキスト２２０はＦＬＩＴ２３４〜４６８を含み、第３のコンテキスト２３０はＦＬＩＴ４６８〜７０１を含む。その結果、リトライバッファ２００は、それぞれ９個のＦＬＩＴからなる７８個までのパケット、すなわち、合計７０２個のＦＬＩＴを記憶するように構成される。パケットは、第１のコンテキスト２１０における９ＦＬＩＴ幅読み出しポート２１５に入り、第３のコンテキスト２３０における９ＦＬＩＴ幅書き込みポート２３５から出て行く。

もちろん、様々な実施形態は、図２及び図３に示された例に示すようなコンテキスト及び／又はパケットのサイズに限定されるものではない。例えば、第１のコンテキスト２１０〜第３のコンテキスト２３０のそれぞれのアドレス指定可能空間は、２４３個のＦＬＩＴに制限することができ、この場合、各コンテキストは、それぞれ９個のＦＬＩＴを含む２７個のパケットを含む。又は、第１のコンテキスト２１０〜第３のコンテキスト２３０のそれぞれのアドレス指定可能空間は、２５２個のＦＬＩＴに制限することができ、この場合、各コンテキストは、それぞれ９個のＦＬＩＴを含む２８個のパケットを含む。同様に、パケットは、本教示の範囲から逸脱することなく、異なる数のＦＬＩＴ（例えば、１ＦＬＩＴ長、２ＦＬＩＴ長等）を含むことができる。特に、サポートされるパケット混合体（packet mix）が拡張するにつれて、例えば、時に空のロケーションが存在することに起因して、リトライバッファ２００の効率性が低下し始める場合がある。

一般に、任意の所与の時点において、リトライバッファ２００の行に存在するパケットは、「バッファリングされた」、「ペンディング中」、又は「リタイアされた」として分類することができる。バッファリングされたパケットは、リトライバッファ２００に書き込み済みであり、受信エージェント１３０への送信を待機しているパケットである。ペンディング中のパケットは、送信エージェント１１０によって送信済みであるが、受信エージェント１３０が受信に成功したとの肯定応答をまだ受けていないパケットである。リタイアされたパケットは、受信成功の肯定応答が受信されたパケットである。新たなパケットが第３のコンテキスト２３０の最後の行に書き込まれた後にリトライバッファが先頭に回帰してきたとき、リタイアされたパケットをやがて上書きすることができる。

図２及び図３は、バッファリング動作及びリトライ動作を実施するのに用いられる代表的なポインタも示している。書き込みポインタｗｒ＿ｐｔｒは、着信パケットストリームからの最も近時の(most recent)新たなパケット（例えば、９個のＦＬＩＴを含む）が、例えばリアルタイムで配置又は記憶される行を指し示す。リトライバッファ２００が、着信パケットを受信して記憶した後、書き込みポインタｗｒ＿ｐｔｒは、全メモリ深度ＴＭＤを法として上方に前進する。図示した例では、７０２を法としている。すなわち、ｗｒ＿ｐｔｒは、ＴＭＤ−１（例えば、７０１）に達するまでインクリメンタルに上方に前進し（インクリメンタルに増加される）、その後、第１のコンテキスト２１０内の行０にロールオーバし、前進シーケンスを再度開始する。このように、パケットは、最後のコンテキスト（例えば、第３のコンテキスト２３０）までリトライバッファ２００に順次書き込まれ、その後、最初のコンテキスト（例えば、第１のコンテキスト２１０）に折り返して、この最初のコンテキストに順次書き込まれる。

再生ポインタｐｂ＿ｐｔｒは、以前に記憶された対応するパケットがバス１４０の順方向リンク１４１を介して受信エージェント１３０に送信されるリトライバッファ２００の行を指し示す。この送信プロセスを管理するのに用いられるトークンは、新たなパケットが再生ポインタｐｂ＿ｐｔｒに応じて送信される際に消費されなければならない。書き込みポインタｗｒ＿ｐｔｒと再生ポインタｐｂ＿ｐｔｒとの間におけるリトライバッファ２００内のいずれのパケットも、上記で論述したような「バッファリングされた」とみなされる。リトライ動作がない場合、再生ポインタｐｂ＿ｐｔｒは、上記で論述したように、ＴＭＤを法として、パケット送信ごとに上方に前進し、実際には、書き込みポインタｗｒ＿ｐｔｒの１行後に留まる。

読み出しポインタｒｄ＿ｐｔｒは、受信エージェント１３０によってパケットの受信が成功したことの最後の（最も近時の）肯定応答を有するパケットを記憶するリトライバッファ２００の行を指し示す。すなわち、読み出しポインタｒｄ＿ｐｔｒは、最も近時の成功パケットを含む行を指し示す。したがって、読み出しポインタｒｄ＿ｐｔｒと再生ポインタｐｂ＿ｐｔｒとの間に位置するいずれのパケットも、上記で論述したような「ペンディング中」とみなされ、読み出しポインタｒｄ＿ｐｔｒに先行するパケットは、上記で論述したような「リタイアされた」とみなされる。送信の成功及び読み出しポインタｒｄ＿ｐｔｒの前進を確保することは、８ビットのＲＲＰフィールドを観察することに基づくことができる。

図２に示す例では、書き込みポインタｗｒ＿ｐｔｒ、ｐｂ＿ｐｔｒ、及び読み出しポインタｒｄ＿ｐｔｒのそれぞれは、第１のコンテキスト２１０内の行を指し示している。書き込みポインタｗｒ＿ｐｔｒは、着信パケットストリームの新たなパケットが（リアルタイムに）到着するにつれて、第２のコンテキスト２２０及び第３のコンテキスト２３０の行をインクリメンタルに前進し、ついには、書き込みポインタｗｒ＿ｐｔｒは、第１のコンテキスト２１０の最初の行に折り返す。例えば、図３では、書き込みポインタｗｒ＿ｐｔｒは、次の連続したコンテキスト（第２のコンテキスト２２０）に前進し、この時、第２のコンテキスト２２０内の行を指し示している。同様に、再生ポインタｐｂ＿ｐｔｒは、記憶されたパケットが送信されるにつれて、第２のコンテキスト２２０及び第３のコンテキスト２３０の行をインクリメンタルに前進し、ついには、再生ポインタｐｂ＿ｐｔｒは、第１のコンテキスト２１０の最初の行に折り返す、あるいはラップアラウンドする。この場合も、図３では、再生ポインタｐｂ＿ｐｔｒも、次の連続したコンテキスト（第２のコンテキスト２２０）に前進する一方、読み出しポインタｒｄ＿ｐｔｒは、まだ第１のコンテキスト２１０に存在する。書き込みポインタｗｒ＿ｐｔｒ、再生ポインタｐｂ＿ｐｔｒ、及び／又は読み出しポインタｒｄ＿ｐｔｒは、特定の動作状態に応じて、同じ又は異なるコンテキストに位置する場合があることが理解されよう。

これと比較して、従来のリトライバッファは、１つだけのコンテキストの最後の行に書き込みを行った後、最初の行に折り返す。したがって、最初の行のパケットの受信成功が、受信デバイスによってまだ肯定応答されていない（すなわち、パケットがまだリタイアされていない）とき、適切な肯定応答が受信されて、コンテキストの先頭にある最初の行（及び後続の行）が解放されるまで、新たなパケットをもはやバッファリングすることができない。この場合、データのリアルタイムの書き込みは行われない。すなわち、送信エージェント１１０へのパケットの流れは停止し、リアルタイム送信が中断される。

図２を再び参照すると、矢印２４０は、再生ポインタｐｂ＿ｐｔｒと読み出しポインタｒｄ＿ｐｔｒとの間の間隔を示す。この間隔は、図示した例では、ラウンドトリップ時間（ＲＴＴ）とＦＬＩＴ送信レートとの積（すなわち、ＲＴＴ×ＦＬＩＴ送信レート）によって求められる。ＲＴＴは、パケットの送信と対応する肯定応答の受信との間の時間であり、ＦＬＩＴ送信レートは、リトライバッファ２００が、バス１４０の順方向リンク１４１を介して受信エージェント１３０に送信するレートである。ＦＬＩＴ送信レートは、リンクレベル送信レートと呼ばれる場合もある。矢印２４０によって示される間隔は、上記で論述したペンディング中のパケットの行も包含する。特に、ＲＴＴとＦＬＩＴ送信レートとの積が、図示した例では２３４個のＦＬＩＴ未満である限り、未処理の同じ値の複数のＦＲＰが存在することはない。

上述したように、リトライ動作がない場合、再生ポインタｐｂ＿ｐｔｒは、ＴＭＤを法として、パケット送信ごとに上方に前進し、したがって、実際には、書き込みポインタｗｒ＿ｐｔｒの１行後に留まる。しかしながら、リトライ動作が開始すると、再生ポインタｐｂ＿ｐｔｒは、再度前進することが可能になる前に、リセットされて、読み出しポインタｒｄ＿ｐｔｒのロケーションに戻る。図４及び図５は、代表的な実施形態によるリトライ動作を実施するためのステップのシーケンスを示す、データ通信システムのリトライバッファのブロック図である。

リトライ動作の開始を示す図４を参照すると、例示の目的で、リトライ動作が、リトライ要求に応答して開始されたものと仮定されている。このリトライ要求は、例えば、受信エージェント１３０によって開始され、リトライ要求パケットに存在する最後に受信された有効なＲＲＰとしてリトライバッファ２００によって受信される。この場合、リトライ動作が要求された時点におけるそれぞれのロケーションをマーキングするために、再生ポインタｐｂ＿ｐｔｒの現在のロケーションが、現在の再生ロケーションを示す再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎによってマーキングされ、読み出しポインタｒｄ＿ｐｔｒの現在のロケーションが、現在の読み出しロケーションを示す読み出しポインタスナップショットｒｄ＿ｐｔｒ＿ｓｎによってマーキングされる。再生ポインタｐｂ＿ｐｔｒは、リセットされて、読み出しポインタｒｄ＿ｐｔｒ（及び対応する読み出しポインタスナップショットｒｄ＿ｐｔｒ＿ｓｎ）のロケーションに戻される。

その間、リトライバッファ２００は、リアルタイムの着信パケットストリームを受信及び記憶し続け、書き込みポインタｗｒ＿ｐｔｒは、それに応じて前進し続ける。また、再生ポインタｐｂ＿ｐｔｒは、再配置された後、再度、再生ポインタｐｂ＿ｐｔｒの新たなロケーションから開始して、ＴＭＤを法として、パケット送信ごとに前進を開始する。この結果、読み出しポインタスナップショットｒｄ＿ｐｔｒ＿ｓｎと再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎとの間のパケットがインクリメンタルに再送され、対応する肯定応答が受信され、これによって、読み出しポインタｒｄ＿ｐｔｒが前進される。

図４に見ることができるように、再生ポインタｐｂ＿ｐｔｒは、この時、書き込みポインタｗｒ＿ｐｔｒに対して大きく遅れている。しかしながら、再生ポインタｐｂ＿ｐｔｒは、書き込みポインタｗｒ＿ｐｔｒよりも高速に前進する。その理由の一部は、再生ポインタｐｂ＿ｐｔｒがリンクレベル送信レートで進むことが可能である一方、書き込みポインタｗｒ＿ｐｔｒは、ＦＬＩＴ発行レートで進み、このＦＬＩＴ発行レートは、リンクレベル送信レートよりも少なくともインクリメンタルに遅くなるからである。ＦＬＩＴ発行レートは、トランザクションレイヤ発行レートと呼ばれる場合もある。加えて、再送されているペンディング中のパケットのトークンは、（最初の送信中に）既に消費されているので、再生ポインタｐｂ＿ｐｔｒが前進するレートは、フロー制御によって抑制されない。もちろん、再生ポインタｐｂ＿ｐｔｒが再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎのロケーションを通過すると、フロー制御は、再生ポインタｐｂ＿ｐｔｒに応答して、バッファリングされたパケットが（初めて）送信される際にトークンが消費されることを必要とする。したがって、再生ポインタｐｂ＿ｐｔｒが書き込みポインタｗｒ＿ｐｔｒに向けて大きく進行する前に、後続のリトライ動作が発生しない限り、再生ポインタｐｂ＿ｐｔｒは、時間とともに書き込みポインタｗｒ＿ｐｔｒにやがて追いつくことができる。

図５は、再生ポインタｐｂ＿ｐｔｒが再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎのロケーションを通過したことによって示されるように、リトライ動作（「リプレイ後フェーズ（post-replay phase）」と呼ばれる場合がある）の最中のリトライバッファ２００を示している。再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎのロケーションを通過後、再生ポインタｐｂ＿ｐｔｒは、バッファリングされたパケットが受信エージェント１３０に送信されるリトライバッファ２００の行を改めて指し示す。これは、リプレイ後フェーズと呼ばれる場合がある。特に、読み出しポインタｒｄ＿ｐｔｒも、前進しており、受信エージェント１３０がパケットの受信に成功したことの最後の（最も近時の）肯定応答を有するパケットを記憶するリトライバッファ２００の行を指し示す。図５では、コンテキストベースが、第１のコンテキスト２１０から第２のコンテキスト２２０に完全にインクリメントしており、そのため、書き込みポインタｗｒ＿ｐｔｒ、ｐｂ＿ｐｔｒ、及び読み出しポインタｒｄ＿ｐｔｒのそれぞれは、第２のコンテキスト２２０内の行を指し示す。これは、最後に返されたＲＲＰがＦＬＩＴ２３３に対応する行（第１のコンテキスト２１０における最も高い行）を通過して前進し、その結果、読み出しポインタｒｄ＿ｐｔｒがＦＬＩＴ２３４を含む行における次のコンテキスト（第２のコンテキスト２２０）に加わる時に発生する。図示した動作例では、第２のコンテキスト２２０は、書き込みポインタｗｒ＿ｐｔｒ及び再生ポインタｐｂ＿ｐｔｒが位置するコンテキストと偶然同じコンテキストでもある。この時点において、第１のコンテキスト２１０の行の全てが、リタイアされたパケットを含み、これらのリタイアされたパケットは、書き込みポインタｗｒ＿ｐｔｒがやがて行０にロールオーバしたときに安全に上書きすることができる。

図５に示すように、再生ポインタｐｂ＿ｐｔｒは、依然として、書き込みポインタｗｒ＿ｐｔｒにまだ追いついていない。この差は、矢印５４１によって示され、この矢印は、上記で論述したように、バッファリングされたパケットを示す。バッファリングされたＦＬＩＴの数は、ＲＴＴとＦＬＩＴ発行レートとの積に等しい。一方、再生ポインタｐｂ＿ｐｔｒと読み出しポインタｒｄ＿ｐｔｒとの間の差が、矢印５４２によって示され、この矢印は、ペンディング中のパケットを示す。上記で論述したように、ペンディング中のＦＬＩＴの数は、ＲＴＴとＦＬＩＴ送信レートとの積（矢印５４０によっても示される）に等しい。この時点において、別のリトライ動作が、リトライ要求に応答して開始された場合、矢印５４０によって示される間隔は、矢印２４０によって示される間隔よりも大きいので、再生ポインタｐｂ＿ｐｔｒは、最初のリトライ動作について書き込みポインタｗｒ＿ｐｔｒに遅れていたよりも更に遅れることになる。実際には、連続したリトライ動作が、互いに比較的接近して発生した場合、書き込みポインタｗｒ＿ｐｔｒは、やがて再生ポインタｐｂ＿ｐｔｒのかなり前方になる場合があり、そのため、折り返して、あるいはラップアラウンドして、肯定応答をまだ受けていないペンディング中のパケット（例えば、読み出しポインタｒｄ＿ｐｔｒによって示される）の上書きを開始する場合がある。この場合、新たなパケットのリアルタイム送信を中断する必要がある。中断しない場合、これによって、リトライバッファは、リトライ動作が要求された場合、破損したリトライ動作に対して脆弱になる。しかしながら、いずれにしてもそのようなイベントの発生は、リトライバッファ２００のサイズが大きいことに起因して起こる可能性はない。

様々な実施形態では、リアルタイムデータを記憶するためのリトライ動作を実行する方法は、プロトコル又は複数の基本ルールによって効果的に管理される。これらの基本ルールは、上記で論述した書き込みポインタｗｒ＿ｐｔｒ、再生ポインタｐｂ＿ｐｔｒ、再生ポインタスナップショットｐｂ＿ｐｔｒ＿ｓｎ、読み出しポインタｒｄ＿ｐｔｒ、及び読み出しポインタスナップショットｒｄ＿ｐｔｒ＿ｓｎに関するルールを含む。より詳細には、そのようなルールの例示のセットは、以下のものを含むことができる。

第１に、書き込みポインタｗｒ＿ｐｔｒ及び再生ポインタｐｂ＿ｐｔｒは、例えば、図２によって図示された例に示すように、７０２を法とする９個のＦＬＩＴの倍数単位でインクリメントする。

第２に、読み出しポインタｒｄ＿ｐｔｒは、最後に返されたＲＲＰ（８ビット量）にｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄを加えたものに等しい。このｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄは、ｒｄ＿ｐｔｒが位置すべきコンテキスト（例えば、第１のコンテキスト２１０〜第３のコンテキスト２３０のうちの１つ）を追跡するものである。ｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄは、図示した例では、０、２３４、又は４６８の値を取ることができる。

第３に、ＲＲＰは、０〜２５５の任意の数とすることができる。しかしながら、上記で論述した例を管理するルールによれば、ＲＲＰは、０〜２３３の値しか取らない。この範囲の値の利点は、２３４が９の倍数（factor）であるということであり、これによって、例示の構成の下での計算が単純になる。もちろん、ＲＲＰは、本教示の範囲から逸脱することなく、０〜２５１（２５２は９の別の倍数である）等の他の範囲内になるように設計することができる。実際には、ＲＲＰは、任意の特定の数の倍数とすることができる。ただし、幾つかの値は、当業者に明らかであるように、実施を単純にする。

第４に、上述したｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄは、値０、２３４、４６８間でインクリメントし、その後、最初のｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄ値に折り返すことによって同じ値の間を繰り返す。図２によって示される例を参照すると、値０は、第１のコンテキスト２１０の最初の行に対応し、値２３４は、第２のコンテキスト２２０の最初の行に対応し、４６８は、第３のコンテキスト２３０の最初の行に対応する。

第５に、ｃｏｎｔｅｘｔ＿ｂａｓｅ＿ｒｅａｄは、最後に返されたＲＲＰが折り返して０を通過するときに、例えば、２３４だけインクリメントする。ＲＲＰストリームのストール（stall）が存在する場合であっても、折り返しを検出するロジックがある。１つの注意点は、このロジックが、連続するＲＲＰの戻りの間のストールが２３４個のＦＬＩＴからなるＦＲＰ空間の２分の１よりも大きい場合に機能しない場合があるということである。

第６のものは、上記で論述したように、以下の動作のリトライの開始時に、ごく僅かに（atomically）起こる。再生ポインタｐｂ＿ｐｔｒは、リプレイを終了する必要があるとともにトークンの消費を再度開始する必要がある箇所を示すために、ｐｂ＿ｐｔｒ＿ｓｎに保存される。読み出しポインタｒｄ＿ｐｔｒは、リプレイを開始する必要がある箇所を示すために、ｒｄ＿ｐｔｒ＿ｓｎに保存される。再生ポインタｐｂ＿ｐｔｒは、リプレイ動作の開始位置を示すために、読み出しポインタｒｄ＿ｐｔｒに設定される。

第７に、上述したように、再生ポインタｐｂ＿ｐｔｒは、トランザクションレイヤリンクのＦＬＩＴ送信レート（例えば、２００Ｇｂｐｓ／１２８＝１．５６２５ＦＬＩＴ／ｎｓ）で前進し、したがって、ＦＬＩＴ発行レートである、書き込みポインタｗｒ＿ｐｔｒが前進するレートよりも高速である。すなわち、ＦＬＩＴ発行レートは、リンクのオーバフローを防止するために、ＦＬＩＴ送信レートよりも僅かに低くなるようにペーサによって設定される。

第８に、ＦＲＰ値は、読み出されると、ＦＬＩＴの位置のＦＬＩＴ粒度の再生ポインタｐｂ＿ｐｔｒに１を加え、更に２３４を法とする値が詰め込まれる。

第９に、読み出しポート２１５及び書き込みポート２３５は、それぞれ９ＦＬＩＴ幅であるので、ＦＬＩＴは、９ＦＬＩＴのチャンクでスケジューラに送信される。未使用のＦＬＩＴ位置は、ＮＵＬＬのＦＬＩＴ（すなわち、０）に設定される。リプレイ中、現在の読み出しポインタｒｄ＿ｐｔｒが９の倍数でない場合、再送されるべきでない最初のＦＬＩＴ（なぜならば、これらのＦＬＩＴは、エラーのあるパケットの前に到来したものであるので）をＮＵＬＬにするロジックが存在する。

上記ルール、並びに様々なポインタ及び値の間の対応する相互関係は例示であり、これらのルールは、本教示の範囲から逸脱することなく、任意の特定の状況に固有の利益を提供するように又は様々な実施態様のアプリケーション特有の設計要件を満たすように変化し得ることが理解されよう。例えば、上述したように、書き込みポインタｗｒ＿ｐｔｒ及び再生ポインタｐｂ＿ｐｔｒは、ＦＬＩＴの他の数の倍数でインクリメントすることができる。

さらに、図２〜図５は、リトライバッファ２００を、３つのコンテキストを有するものとして示しているが、様々な代替の実施形態によれば、設計者／ユーザがこの機能にどれだけの量のメモリを充てる用意があるのかということ以外に、マルチコンテキストリトライバッファは、コンテキストの数に関して限定されるものではない。各コンテキストは、例えば、０ＦＬＩＴ長〜２５５ＦＬＩＴ長とすることができ、ここで、数２５５は、一般的な関係２^{（ｐｏｉｎｔｅｒ ｗｉｄｔｈ）}−１に基づいている。ここで、ｐｏｉｎｔｅｒ ｗｉｄｔｈ（ポインタ幅）は、ＦＲＰ又はＲＲＰの幅を指す。そのため、ＦＲＰポインタ幅及び／又はＲＲＰポインタ幅が８である図示した実施形態に適用されると、コンテキストは、２^８−１＝２５５となる。さらに、各コンテキストの長さは、行幅（図示した例では９である）の倍数であるべきである。そうでない場合、他のポインタルールが影響を受けることになる。

実際問題として、ゼロは、ゆるい下限である一方、実際の下限は、ペンディング中のパケット内のＦＬＩＴの予想される最大数によって設定される。したがって、ペンディング中のＦＬＩＴのセットは、常に、（例えば、図３に示すように）多くとも２つの連続したコンテキストに及んでいる。

これとは対照的に、バッファリングされたパケット内のＦＬＩＴのセット（すなわち、書き込みポインタｗｒ＿ｐｔｒが再生ポインタｐｂ＿ｐｔｒからどれだけ前方にいるか）は、３つ以上のコンテキストに及ぶ場合がある。制限は、上述したように、書き込みポインタｗｒ＿ｐｔｒがマルチコンテキストリトライバッファの先頭に折り返して、読み出しポインタｒｄ＿ｐｔｒによって示される空間を上書きすることができないということである。

図６は、代表的な実施形態による、パケットを受信エージェントにリアルタイムで送信する方法を示す流れ図である。

図６を参照すると、パケットは、ブロックＳ６１１において、送信エージェント（例えば、送信エージェント１１０）のリトライバッファ（例えば、リトライバッファ２００）に順次書き込まれる。このリトライバッファは、複数のコンテキスト（例えば、第１のコンテキスト２１０〜第３のコンテキスト２３０）を含む。リトライバッファへのパケットの書き込みは、リトライバッファにおいて書き込みポインタを設定し、前進させることによって追跡することができる。すなわち、書き込みポインタは、各受信パケットに応答して、リトライバッファ内の次の書き込みロケーションにインクリメンタルに増加される。パケットは、例えば、送信エージェントのトランザクションレイヤによってリトライバッファにＦＬＩＴ発行レートで書き込むことができる。

ブロックＳ６１２において、リトライバッファ内のパケットは、受信エージェント（例えば、受信エージェント１３０）に順次送信され、その間、追加のパケットが、リトライバッファに順次書き込まれ続ける。パケットの送信は、リトライバッファにおいて再生ポインタを設定し、前進させることによって追跡することができる。すなわち、再生ポインタは、各パケットがリトライバッファから送信されることに応答して、リトライバッファ内の次の再生ロケーションにインクリメンタルに増加される。パケットは、例えば、上記で論述したように、トランザクションレイヤ発行レートよりも高速のリンクレベル送信レートで受信エージェントに送信することができる。

ブロックＳ６１３において、各パケットが、受信エージェントに送信された順序で、受信エージェントによる受信に成功したか否かが判断される。受信エージェントが送信パケットの受信に成功したとき（ブロックＳ６１３：Ｙｅｓ）、ブロックＳ６１４において、対応する肯定応答が受信エージェントから受信され、その間、リトライバッファに書き込まれたパケットは、受信エージェントに順次送信され続ける。受信成功は、リトライバッファにおいて読み出しポインタを設定し、前進させることによって追跡することができる。すなわち、読み出しポインタは、送信パケットに対応する受信成功の各肯定応答に応答してリトライバッファ内の次の読み出しロケーションにインクリメンタルに増加される。一方、受信エージェントが送信パケットの受信に成功しなかったとき（ブロックＳ６１３：Ｎｏ）、ブロックＳ６１５において、リトライ要求が受信エージェントから受信される。次に、ブロックＳ６１６において、リトライバッファからのペンディング中のパケットが、受信エージェントによる受信に成功しなかった（その結果、リトライ要求が得られる）送信パケットから開始して、受信エージェントに再送される。パケットの再送は、再生ポインタを、受信に成功しなかった送信パケットのロケーションにリセットし、再生ポインタを再送パケットを用いて前進させることによって追跡することができる。その間、追加のパケットが、リトライバッファにリアルタイムで順次書き込まれ続ける。

一般に、バッファリングされるパケットのより大きなセットを単一のバッファメモリにおいてサポートすることができることによって、リアルタイムストリーミングアプリケーションは、リンクにビットエラーが存在する状態で、より高い信頼性（すなわち「稼働時間」）を有することが可能になる。これは、高い稼働時間を必要とする高帯域幅リアルタイムストリーミングアプリケーションにとって重要である。また、より大きなリトライバッファによって、バッファリングされたパケットの送信と受信エージェントによるパケットの受信成功の肯定応答との間に、より長いＲＴＴレイテンシが許容される。さらに、より大きなメモリ空間は、大きなオンチップメモリマクロを用いて高帯域幅ストリーミングアプリケーションのリトライバッファ記憶及びリトライフェーズバッファリングを提供する能力を提供する。

当業者であれば、本教示に従う多くの変形形態が可能であり、かつ、添付の特許請求の範囲の範囲内にあることを理解する。これらの変形形態及び他の変形形態は、本明細書、図面、及び添付の特許請求の範囲を調べた後、当業者には明らかになるであろう。したがって、本発明は、添付の特許請求の範囲の趣旨及び範囲内を除いて限定されるべきではない。

１０５ トランザクションレイヤ
１１０ 送信エージェント
１１５ 送信バス
１３０ 受信エージェント
１４０ バス
１４１ 順方向リンク
１４２ 戻りリンク
２００ リトライバッファ

Claims (20)

1. パケットストリームのパケットをリアルタイムで送信する方法であって、
   パケットを送信エージェント（１１０）のリトライバッファ（２００）に順次書き込むステップであって、前記リトライバッファは、複数のコンテキストを含む、書き込むステップ（Ｓ６１１）と、
   前記リトライバッファに書き込まれた前記パケットを受信エージェント（１３０）に順次送信するとともに、追加のパケットを前記リトライバッファに順次書き込み続けるステップ（Ｓ６１２）と、
   前記受信エージェントが前記送信パケットの受信に成功したとき、前記受信エージェントから肯定応答を受信するとともに、前記リトライバッファに書き込まれた前記パケットを前記受信エージェントに順次送信し続けるステップ（Ｓ６１４）と、
   前記受信エージェントが前記送信パケットの受信に成功しなかったとき、前記受信エージェントからリトライ要求を受信するステップ（Ｓ６１５）と、
   前記受信エージェントが受信に成功せず、その結果、前記リトライ要求が得られた前記送信パケットから開始して、前記リトライバッファから前記受信エージェントに前記パケットを再送するとともに、前記追加のパケットを前記リトライバッファに順次書き込み続けるステップ（Ｓ６１６）と、
   を含む、パケットストリームのパケットをリアルタイムで送信する方法。
2. 最も近時に受信されたパケットが書き込まれる前記リトライバッファ内の書き込みロケーションを示す書き込みポインタ（ｗｒ＿ｐｔｒ）を設定するステップと、
   以前に記憶されたパケットが前記リトライバッファから前記受信エージェントに送信される前記リトライバッファ内の再生ロケーションを示す再生ポインタ（ｐｂ＿ｐｔｒ）を設定するステップと、
   前記受信エージェントによる受信成功の肯定応答が受信された、以前に送信されたパケットの前記リトライバッファ内の読み出しロケーションを示す読み出しポインタ（ｒｄ＿ｐｔｒ）を設定するステップと、
   を更に含む、請求項１に記載の方法。
3. 前記書き込みポインタは、各受信パケットに応答して、前記リトライバッファ内の次の書き込みロケーションにインクリメンタルに増加され、
   前記再生ポインタは、前記各パケットが前記リトライバッファから送信されることに応答して、前記バッファ内の次の再生ロケーションにインクリメンタルに増加され、
   前記読み出しポインタは、送信パケットに対応する受信成功の各肯定応答に応答して、前記リトライバッファ内の次の読み出しロケーションにインクリメンタルに増加される、
   請求項２に記載の方法。
4. 前記リトライ要求に応答して、前記リトライバッファ内の現在の再生ロケーションを示す再生ポインタスナップショットを前記再生ポインタに設定するステップと、
   前記リトライ要求に応答して、前記リトライバッファ内の現在の読み出しロケーションを示す読み出しポインタスナップショットを前記読み出しポインタに設定するステップと、
   前記再生ポインタを前記読み出しポインタによって示される前記読み出しロケーションにリセットするステップと、
   を更に含み、
   前記リトライバッファから前記受信エージェントにパケットを再送するステップは、前記リセットされた再生ポインタから開始する、請求項２に記載の方法。
5. 前記送信エージェントのトランザクションレイヤ（１０５）から受信されたパケットが前記リトライバッファに順次書き込まれる受信レートよりも高速の送信レートで、前記リトライバッファから前記受信エージェントに前記パケットを順次再送するステップ、
   を更に含む、請求項４に記載の方法。
6. 前記より高速の送信レートは、リンクレベル送信レートに対応し、前記受信レートは、トランザクションレイヤ発行レートに対応する、請求項５に記載の方法。
7. 前記リトライバッファは、バッファリングされたパケットを前記書き込みポインタと前記再生ポインタとの間に含み、該バッファリングされたパケットは、前記リトライバッファに書き込まれているが、前記受信エージェントにまだ送信されていない、請求項２に記載の方法。
8. 前記リトライバッファは、ペンディング中のパケットを前記再生ポインタと前記読み出しポインタとの間に含み、該ペンディング中のパケットは、前記リトライバッファから送信されているが、前記受信エージェントが受信に成功したとの肯定応答をまだ受けていない、請求項２に記載の方法。
9. 前記リトライバッファは、リタイアされたパケットを前記リトライバッファの先頭と前記読み出しポインタとの間に含み、前記リタイアされたパケットは、前記受信エージェントが受信に成功したとの肯定応答を受けている、請求項２に記載の方法。
10. 前記送信エージェントから受信された前記追加のパケットを前記リトライバッファに順次書き込み続けるステップは、前記パケットが再送されているコンテキストとは異なるコンテキストに前記追加のパケットを順次書き込むステップを含む、請求項１に記載の方法。
11. 前記パケットを前記リトライバッファに順次書き込むステップは、前記リトライバッファの最後のコンテキストの終わりに達した後、前記最後のコンテキストに前記パケットを書き込むことから最初のコンテキストに前記パケットを書き込むことに折り返すステップを含む、請求項１に記載の方法。
12. 前記各パケットは、複数のフローユニット（ＦＬＩＴ）を含み、前記各ＦＬＩＴは、複数のビットを含む、請求項１に記載の方法。
13. 前記リトライバッファ内の前記複数のコンテキストの該各コンテキストは、複数の行を含み、該各行は、前記複数のＦＬＩＴを含むパケットに対応する、請求項１２に記載の方法。
14. 前記各コンテキストの長さは、該コンテキスト内の行の幅の倍数である、請求項１３に記載の方法。
15. パケットを受信エージェント（１３０）に送信する方法であって、
    パケットストリームのパケットをリトライバッファ（２００）にリアルタイムで順次書き込むとともに、前記リトライバッファにおいて書き込みポインタを前進させることによって前記パケットの前記書き込みを追跡するステップ（Ｓ６１１）と、
    前記リトライバッファに書き込まれた前記パケットを前記受信エージェントに順次送信するとともに、再生ポインタを前進させることによって前記パケットの前記送信を追跡するステップ（Ｓ６１２）と、
    前記受信エージェントによる前記送信パケットの受信成功に肯定応答する情報を受信するとともに、読み出しポインタを前進させることによって前記受信成功を追跡するステップ（Ｓ６１４）と、
    前記送信パケットが前記受信エージェントによる受信に成功しなかったとき、リトライ要求を受信するステップ（Ｓ６１５）と、
    前記リトライ要求に応答して、前記再生ポインタを前記読み出しポインタの現在のロケーションに再配置するステップと、
    前記リトライ要求に応答して、前記再配置された再生ポインタから開始して、前記リトライバッファに書き込まれたパケットを前記受信エージェントに順次再送することによってリトライ動作を開始するとともに、前記再生ポインタを前進させることによって前記パケットの前記再送を追跡するステップ（Ｓ６１６）と、
    を含み、
    前記パケットストリームの前記パケットは、前記リトライ動作中、前記リトライバッファにリアルタイムで書き込まれ続けるとともに、前記書き込みポインタによって追跡され続ける、パケットを受信エージェントに送信する方法。
16. 前記リトライ要求に応答して、前記リトライバッファ内の現在の再生ロケーションを示す再生ポインタスナップショットを前記再生ポインタに設定するステップと、
    前記リトライ要求に応答して、前記リトライバッファ内の現在の読み出しロケーションを示す読み出しポインタスナップショットを前記読み出しポインタに設定するステップと、
    を更に含む、請求項１５に記載の方法。
17. バス（１４０）を介してパケットを受信エージェント（１３０）に送信するための送信エージェント（１１０）であって
    前記受信エージェントに送信されるパケットを発行するように構成されたトランザクションレイヤ（１０５）と、
    リトライバッファ（２００）であって、
    該送信エージェントの前記トランザクションレイヤからの前記パケットをリアルタイムで順次受信して記憶することと、
    前記バスの順方向リンクを介して、前記記憶されたパケットを前記受信エージェントに順次送信することであって、まだ送信されていない前記記憶されたパケットは、バッファリングされたパケットである、送信することと、
    前記受信エージェントが前記送信パケットの受信に成功したときに、前記受信エージェントから肯定応答を受信することであって、前記肯定応答がまだ受信されていない前記送信パケットは、ペンディング中のパケットである、受信することと、
    前記受信エージェントによる受信に成功していない前記送信パケットから開始して、前記ペンディング中のパケットを前記受信エージェントに順次再送することと、
    該送信エージェントの前記トランザクションレイヤからの前記パケットをリアルタイムで順次受信して記憶し続けるとともに、前記ペンディング中のパケットを順次再送することと、
    を行うように構成された、リトライバッファと、
    を備える、バスを介してパケットを受信エージェントに送信するための送信エージェント。
18. 前記送信エージェントはホストデバイスを含み、前記受信エージェントはメモリデバイスを含む、請求項１７に記載の送信エージェント。
19. 前記リトライバッファは、
    前記トランザクションレイヤから最も近時に受信されたパケットが記憶される書き込みロケーションを示すように設定された書き込みポインタ（ｗｒ＿ｐｔｒ）と、
    記憶されたパケットが最も近時に送信された再生ロケーションを示す再生ポインタ（ｐｂ＿ｐｔｒ）と、
    肯定応答が受信された、以前に送信されたパケットの読み出しロケーションを示すように設定された読み出しポインタ（ｒｄ＿ｐｔｒ）と、
    を備える、請求項１７に記載の送信エージェント。
20. 前記リトライバッファは、複数のコンテキストを含み、前記書き込みポインタ、前記再生ポインタ、及び前記読み出しポインタのそれぞれは、隣接するコンテキスト間を前進することができる、請求項１９に記載の送信エージェント。

Images