JP2012039661A - リソースの粒度がクレジットの粒度よりも大きいときのクレジット管理 - Google Patents

Abstract

【課題】デジタルシステムにおいてインタフェースに関するクレジット方式のフロー制御メカニズムを適切に管理することを目的とする。
【解決手段】一実施例において、データクレジットよりも粗い粒度で割り当てられたバッファメモリ内に、データペイロードが少数で未使用のデータクレジットを負担するときよりも前に、受信機はクレジットベースのフロー制御されたインタフェース上で１以上のデータクレジットを解放する。別の実施例では、ヘッダークレジット及びデータクレジットは、実際のパケットデータ・ペイロードサイズに基づきダイナミックに調整される。
【選択図】図３

Description

本発明はデジタルシステムに関し、より詳細にはデジタルシステムにおいてインタフェースに関するクレジット方式のフロー制御メカニズムの管理を認めることに関するものである。

デジタルシステムには、システムにおける集積回路（ＩＣ）間、システム間、時には一つのＩＣ内においてでさえも、フロー制御インタフェースを含んでいることがよくある。一般的に、フロー制御はバッファのオーバーランや、受信機に生じるデータ状況の他の損失を避けるために存在する。例えば、通常のフロー制御メカニズムはクレジット方式に基づいている。インタフェース上の受信機は、様々なタイプの送信信号に利用可能なクレジットの数をブロードキャストし、そして送信機はこれらのクレジットを記録する。次に、送信機は各送信信号のためにクレジットを保有してインタフェースで送信することができる。クレジットを使いきってしまうと、送信機は送信を中止しなければならない。受信機は、受信した送信処理を完了するとき、各送信で消費してしまったクレジットを解放し、この解放されたクレジットを送信機に戻す。

受信機によって通知されたクレジットは、伝送をハンドリングする受信機で利用可能なリソースにより制限されているのが一般的である。例えば、受信された送信信号を記憶するためにバッファが用意されることが多い。利用可能なバッファは、各送信タイプのためにどのくらいの数のクレジットが通知されるかを示していることになる。或るケースでは、バッファはメモリとして実装される。このメモリがクレジットと同じ（又はより細かい）粒度、すなわち粗さで配置されていなければ、メモリの使用は非効率的になる。一般的に、フルメモリ粒度が割り当てられ、任意のデータ量を最大このフルメモリ粒度で記憶しなければならない。データはメモリの粒度よりも少なく（又は或る非整数の複数メモリ粒度で）送信されるので、通知されうるクレジットの数というのはメモリサイズの知識に基づき推測できる数よりも少ない。その結果、インタフェース上で実現可能なバンド幅は、メモリがより大きな粒度で割り当てられるであろう可能性よりも小さくなってしまっていた。

一実施例において、装置はバッファメモリに結合された受信機を含む。この受信機は、使用の最中に当該受信機に結合されたインタフェースの関するフロー制御クレジットを管理するクレジット管理ユニットを含む。インタフェースで受信される各パケットは、パケットヘッダーを含み、オプションでパケットデータも含む。パケットデータは、当該パケットデータのサイズに依存するフロー制御クレジットにおけるデータクレジットの単位で測定される。ここで、各データは固定のデータバイト数をあらわしている。バッファメモリはパケットヘッダーと、受信機がインタフェース上で受信するパケットに対応するパケットデータを記憶する。この場合、バッファメモリは、データクレジットのサイズにＮ（Ｎは１よりも大きな整数）を乗じたバッファユニットにおいて受信機によって割り当て可能である。データクレジットの総数は、パケットデータを記憶するのに利用できるバッファメモリにおいて、バッファユニットの数にＮを乗じた値に等しい。そしてクレジット管理ユニットは、パケットデータがバッファユニットをあふれさせず、更に処理中に同時に存在することが認められるパケット数に基づく場合に、使用できないデータクレジットの最大数に基づき複数の総データクレジットをとっておくように構成されている。クレジット管理ユニットは、使用できないデータクレジットの最大数よりも少ないこととなる所与のパケットに関するパケットデータを受信することに応答し、１以上のデータクレジットを解放するように構成されている。クレジット管理ユニットは、所与のパケットが消費される前に１以上のデータクレジットを解放するよう構成されている。上記装置に対応する方法も考慮されるものである。

一実施例において、装置はバッファメモリに結合された受信機を含む。この受信機は、受信機の使用中に結合されるインタフェースに関するフロー管理クレジットを管理するよう構成されたクレジット管理ユニットを含む。インタフェースで受信される各パケットはヘッダーを含み、オプションとしてデータも含む。ヘッダーはインタフェース上でフロー制御のための１以上のヘッダークレジットの単位で測定され、データは当該インタフェース上でフロー制御のための１以上のデータクレジットの単位で測定される。各データクレジットは固定のデータバイト数をあらわす。バッファメモリは、受信機によってインタフェース上で受信されたパケットに対応するパケットヘッダー及びパケットデータを記憶するように構成されている。クレジット管理ユニットは、パケットヘッダーを記憶するために使用される第１の量のバッファメモリ、及び１以上の受信パケットにおけるパケットデータのサイズに応じたパケットデータを記憶するために使用される第２の量のバッファメモリをダイナミックに調整するよう構成されている。クレジット管理ユニットは、上記ダイナミック調整に合わせて、送信機に対してデータクレジット及びヘッダークレジットをインタフェース上で解放するよう構成されている。

本発明は、様々な修正及び代替の態様を受け入れる余地がありながら、その特定の実施例が図面において一例として示されており、ここに詳細に説明されている。しかしながら、図及び詳細な説明は開示された特別の態様として本発明を限定するように意図されておらず、これに対して本発明は、添付の特許請求の範囲によって定義される本発明の精神及び範囲を逸脱しないあらゆる修正、均等物、及び代替例をカバーするものである。ここで使用される見出しは、体系化の目的のみ意図されており、記載の範囲を制限するために使用されことを意図していない。本願全体を通じて使用される単語の「may」は、義務の意味（すなわち、「しなければならない」という意味）というよりは、許容の意味（すなわち、可能性があるという意味）で使用されている。同様に、「含む(include)」、「含んでいる(including)」、「含む(includes)」は、限定されるわけではないという意味の「含む」である。

以下の詳細な説明は添付の図面を参照しながら行なわれる。

図１は、デジタルシステムの一実施例のためのブロック図である。 図２は、メモリバッファ割り当ての一実施例のためのブロック図である。 図３は、図１で示した受信機の一実施例のためのブロック図である。 図４は、図１で示したシステムの初期設定中、図３で示した受信機の一実施例のオペレーションをあらわすフローチャートである。 図５は、図１で示したシステムのパケットを受信することに応じて、図３で示した受信機の一実施例のオペレーションをあらわすフローチャートである。 図６は、図１で示したシステムのターゲットにより消費されるパケットに応じて、図３で示した受信機の一実施例のオペレーションをあらわすフローチャートである。 図７は、図１で示した受信機の別の実施例のためのブロック図である。 図８は、図１で示したシステムの初期設定中、図７で示した受信機の一実施例の追加的オペレーションをあらわすフローチャートである。 図９は、図１で示したシステムのパケットを受信することに応じて、図７で示した受信機の一実施例の追加的オペレーションをあらわすフローチャートである。 図１０は、図７で示した受信機の一実施例の追加的な詳細をあらわす擬似コードである。 図１１は、図７で示した受信機の一実施例の追加的な詳細をあらわす擬似コードである。

図１を参照すれば、システム１０の一実施例のブロック図が示されている。本実施例の場合、システム１０は、送信機１２、受信機１４、バッファメモリ１６、そしてオプションとしてパケットターゲット１８を含む。送信機は、受信機１４も接続されたインタフェース２０に接続されている。バッファメモリ１６は、受信機１４及び当該１８に接続されている。

送信機１２はヘッダークレジット及びデータクレジットを保持するよう構成され、どのくらいの数のパケットヘッダー及びパケットデータトラフィックを、受信機１４が現在のところ受け入れることができるのかを示す。例えば、図１において、送信機１２は、ヘッダークレジットレジスタ２２及びデータクレジットレジスタ２４を含む。システム１０の初期化中、そして可能性としてはインタフェース２０がリセットされるオペレーション中の他の時点で、受信機１４は、送信機１２に対して通知するために、ヘッダークレジット及びデータクレジットの数を決定する。送信機１２は通知されたクレジットでレジスタ２２及び２４を初期化することができる。送信機１２はパケットヘッダー及びパケットデータを送信するので、送信機１２は、送信されたヘッダー及びデータにより消費されたクレジットを保有する。受信機１４は、解放後のクレジットを送信機１２に返信し、送信機１２は解放後のクレジットをレジスタ２２及び２４に加える。その結果、所与の任意の時点で、送信機１２は、レジスタ２２及び２４内のクレジットに応じて、どのくらい多い情報がインタフェース２０を介して送信されたかをコントロールすることができる。仮に、送信のためにあまり十分でないクレジットしか利用されないのであれば、例えば、送信機１２は必要とされるクレジット数が利用できるようになるまでその送信を遅延させることができる。

一般的に、通知クレジットは、利用可能なクレジット数を送信機１２に知らせるために、受信機１４のメカニズムを参照する。同様に、解放クレジットは、送信機１２に返信されるのに利用可能な相互接続器２０の伝送経由で消費されるクレジットを決定するメカニズム、そしてそれらのクレジットを返信するメカニズムを参照する。この通知及び解放を実行するメカニズムは、インタフェース２０の定義に基づく特有の実装（インプリメンテーション）であるが、一般的に受信機１４から送信機１２までのインタフェース２０上での伝送を含むものである。例えば、解放クレジットを送信するパケットが定義されたり、すべてのパケットのために用いられるヘッダーのフィールドが解放クレジットを含むことができる。解放クレジットを送信するパケットは初期化中に送信され、所望の数のクレジットを通知する。パケットのフィールドに送信され得る以上に多くのクレジットが通知される場合には、複合パケットが送信され得る。

一般的に、インタフェース２０で送信されるパケットは、（パケットのタイプを定義し、他のコントロール情報を提供する）ヘッダーを含み、そしてオプション的にデータ（すなわち、「ぺイロード」）を含む。このヘッダーはサイズが固定されており、したがって各ヘッダーは、送信機１２により送信されるとき、１つのヘッダークレジットを消費する。他の実施例では、可変サイズのヘッダーが実装され、所与のパケットにとって必要なヘッダークレジットの数がそのヘッダーサイズに影響される。データペイロードは、可変サイズである。したがって、データクレジットは、固定数のデータバイト（「データ単位」として引用される。）をあらわすように定義され、所与のパケットにとって要求されるデータクレジットの数は、ペイロードのサイズをデータクレジットのサイズで割った値となる。データクレジットのサイズはインタフェース２０定義の一部である。例えば、一実施例において、インタフェース２０は、周辺機器コンポーネント相互接続Express（ＰＣＩｅ）インタフェースであり、データクレジットは１６バイトをあらわす。

受信機１４はクレジット管理ユニット２６を含み、当該クレジット管理ユニット２６によって使用される値を記憶し、送信機１２に関するクレジットを管理する１以上のクレジットレジスタ２８を含む。様々な実施例の補足する詳細については後述する。また、受信機１４はインタフェース２０で通信するため、バッファメモリ１６と通信するため等の様々な他の回路も含む。さらに、図１は、受信機１４へ送信する送信機１２を示すのであるが、この通信はインタフェース２０上で双方向である。つまり、送信機の機能はインタフェース２０の両サイドに存在し、受信機の機能もインタフェース２０の両サイドに存在するのである。話を簡略化するため、ここでの記載は、受信機１４へ送信する送信機１２について言及するものであるが、図１の受信機１４側から送信機１２側へパケットが送信され得ることを理解されたい。

図示した実施例の場合、インタフェース２０は、一組の双方向なポイント・ツー・ポイントリンクを含む。パケットはこのリンク上で送信される。他の実施例においては、インタフェース２０は他の定義を有する。例えば、インタフェース２０は、アドレス及びデータトランスミッションを有するバスとなり得る。アドレストランスミッションは、（ヘッダークレジットに類似する）アドレスクレジットによりフロー制御され、データトランスミッションはデータクレジットによりフロー制御される。インタフェース２０の定義に基づき、クレジットの任意のセットが使用される。一般的に、クレジットのセットはフロー制御クレジットとして引用される。

ターゲット１８はバッファメモリ１６からのパケットを消費する任意の回路を参照するのが一般的である。ターゲット１８は受信機１４（例えば、ＩＣ）を含むデバイスの一部であったり、或いは分離されていたりする。例えば、受信機１４は、パケットを受信し、かつ、パケットを別のインタフェースに転送するスイッチである。この場合、バッファメモリ１６からのパケットの消費は、他のインタフェース上の転送パケットである。

バッファメモリ１６は、受信機１４にアクセス可能な任意のタイプのメモリを含む。例えば、バッファメモリ１６は、メモリコントローラに接続されたダイナミックランダムアクセスメモリ（ＤＲＡＭ）などのシステムメモリ１６を含む。なお、メモリコントローラは、ＤＲＡＭに対するインタフェースを構成する。例えば、シングル・インライン・メモリ・モジュール（ＳＩＭＭ）、デュアル・インライン・メモリ・モジュール（ＤＩＭＭ）など様々なＤＲＡＭはメモリモジュールがサポートされる。任意のＤＲＡＭ技術が使用される（例えば、同期型ＤＲＡＭ（ＳＤＲＡＭ）、デュアル・データ・レート（ＤＤＲ）ＳＤＲＡＭ、ＤＤＲ２ ＳＤＲＡＭ、ＤＤＲ３ ＳＤＲＡＭ、Ｒａｍｂｕｓ ＤＲＡＭ（ＲＤＲＡＭ）など）。このような実施例において、受信機１４はメモリコントローラに対する書込みコマンドを発生させ、パケットヘッダー及びパケットデータをメモリ１６に書き込む。ターゲット１８はメモリコントローラに対する読み出しコマンドを発生させ、パケットヘッダー及びパケットデータを読み出す。他の実施例においては、バッファメモリ１６は、受信機１４に対するプライベートメモリを有したり、或いは受信機１４及びシステム１０内の１以上の他の送受信機によって共有されるメモリを含む。バッファメモリ１６は、例えば、キャッシュメモリや他の専用バッファメモリを含む。或る実施例において、バッファメモリ１６は、スタティックＲＡＭ（ＳＲＡＭ）を含む。

バッファメモリ１６は、パケットヘッダー及びパケットデータを記憶するように割り当てられる。詳細には、データクレジット（幾つかの実施例では、さらにヘッダークレジットの少なくともいずれか）よりも粗い粒度でバッファメモリ１６を割り当てる。バッファメモリ１６は、ここでは、バッファユニット（ＢＵ）として引用される、顆粒状態で割り当てられる。したがって、図１において、ヘッダーＢＵ３０及びデータＢＵ３２が示される。本記載の残りは、ＢＵと同じ粒度のヘッダークレジット及びより細かな粒度のデータクレジットの実施例を使用することとする。しかしながら、ＢＵよりも粒度の細かいヘッダークレジット、及びデータクレジットメカニズムと同様のメカニズムがヘッダークレジットのために用いられる実施例が考慮される。

ＢＵ粒度はＤＵ粒度よりも粗いので、バッファメモリ１６はデータを記憶するのに十分に用いられないかもしれない。図２は、ＢＵがＤＵのサイズの４倍である場合の完全利用よりも少ない一例を示したブロック図である。他の実施例は、ＤＵのサイズをＮ倍したＢＵを一般的に含む。ここで、Ｎは１より大きな整数である。或る実施例の場合、Ｎは２の累乗である。

一般的に、様々なパケットのデータペイロードは、０及びＭ個のＤＵの間である。ここで、Ｍは０よりも大きな整数である。Ｍのサイズは実装（インプリメンテーション）に影響され、インタフェース２０の定義に依存する（例えば、インタフェース２０はパケット当りの最大データペイロードサイズを定義する）。しかしながら、Ｍは、Ｎとの特別な関係を必ずしも持っていない。つまり、Ｍ/Ｎは所与のパケットに対して整数値である必要はない。

図２の右側にＢＵが、一例として記憶されたデータペイロードの内部を点線で延長して示されている。左側には、実線でＤＵを示している。上述したように、本例ではＢＵ当り４個のＤＵがある。５個のＤＵペイロードが図２に示されている。最初の４個のＤＵはＢＵ０に記憶され、ＢＵすべて占領する。５番目のＤＵはＢＵ１に記憶される。バッファメモリ１６は、ＢＵ粒度でペイロードデータを記憶するよう割り当てられるので、ＢＵ１内で３個のＤＵを未使用にしたまま、ＢＵ１の完全性はペイロード４０に割り当てられる。別のやり方を検討すると、ペイロード４０に対応するパケットが消費されるまで、バッファメモリ１６の３ＤＵは使用できず、そして、ペイロード４０を送信するための送信機１２により消費されるＤＵ（及び、その結果、データクレジット）の数に関するアカウンティング・エラーを本質的に構成してしまうかもしれない。つまり、送信機１２はペイロード４０を送信するために５個のクレジットを消費するが、実際にはペイロード４０はバッファメモリ１６の８個のクレジットを占領する。

別のペイロード４２が図２に示されている。これは、一例として４個のＤＵである。したがって、ペイロード４２はＢＵ２に記憶されており、未使用のＤＵはない。３番目のペイロード４４もまた示され、これは、ＢＵ３及びＢＵ４の２個のＤＵを占領する６個のＤＵである。したがって、バッファメモリ１６内の２以上ＤＵが未使用である。一般的に、パケットは最大Ｐ個のＢＵを占領し、ペイロードがＮの偶数個のＤＵでないならば、最後に占領されたＢＵ内の１以上のＤＵが未使用である。言い換えると、未使用のＤＵが、（そのペイロードがＢＵの始めに割り当てられることを要求されないのであれば）ペイロードによって占領されたＢＵの始め、若しくは始め及び終わりの両方に存在する。いずれにしても、ＢＵに対応するＤＵの数に基づき、データペイロードに関する最大の起こりうるエラーが定義される。１つのＤＵがＢＵを占領する場合は最大エラーが生じ、その結果、所与のペイロードに関する最大エラーがＮ−１個のＤＵ（又はＮ−１個のデータクレジット）である。

したがって、パケットデータを記憶するために割り当て可能な所与の数Ｙ個のＢＵについて、Ｙ＊Ｎ個よりも少ないデータクレジットが送信機１２に通知される。クレジット管理ユニット２６は、オーバーフローがバッファメモリ１６に生じないことを保証することを通知したであろうデータクレジットを用意しておく。具体的に言うと、各データペイロードが最大エラー（Ｎ−１）を負うとき、最悪ケースの総エラーが生じる。最大でＣパケットが送信されるならば（例えば、ヘッダークレジットの数がＣである）、最悪ケースの全体エラーはＣ−１×Ｎ−１である。最後のデータペイロードのエラーが検出されないのでＣ−１が用いられる。というのも、送信機１２はヘッダークレジットが使い果たされたとき別のパケットを送信することができないからである。

データペイロードを有する所与のパケットが受信されるとき、ペイロードが最大エラーよりも少ない量を負うのであれば、幾つかのデータクレジットは、（パケットが消費される前）ただちに解放される。つまり、クレジット管理ユニット２６が送信機１２に対してブロードキャストされていなかったということを、保有されていたクレジットが明らかにした量よりも、データペイロードに関するバッファメモリ１６内の未使用のＤＵは少ない。例えば、図２において、ペイロード４２はゼロエラーを認識し、その結果、３（Ｎ−１−０）のデータクレジットがペイロード４２を受信することに応じて解放される。ペイロード４４は２エラーを認識し、その結果、１（Ｎ−１−２）のデータクレジットがペイロード４２を受信することに応じて解放される。

ひとたびパケットが消費されると、保有されていたクレジットが再び必要とされる（なぜなら、受信される次のパケットは未使用のＤＵの最大数を実現するペイロードを有するからである）。したがって、送信機によって実際に消費された残りのクレジットは、パケットが消費されるときに解放される。つまり、パケットが消費されるときに解放されるクレジットの数は、ペイロードに対応する実際のクレジット数から、パケットが受信されたときに解放されるクレジット数を差し引いた値に等しい。

未認識のエラーに対応したクレジットを解放することによって、利用可能なデータクレジットの欠如のために遅延したであろう追加パケットを送信できる可能性がある。つまり、インタフェース２０上のバンド幅はより効率的に利用されるのである。

図３は、受信機１４の一実施例を示すブロック図であり、未使用ＤＵの最大数よりも少ない未使用ＤＵを負担するデータペイロードに関するデータクレジットの早期解放のインプリメントを詳細に示している。本実施例の場合、クレジット管理ユニット２６が示され、最大ＤＵエラーレジスタ２８Ａ及び解放データクレジット（ＤＣｒｓ）レジスタ２８Ｂに結合されている。レジスタ２８Ａ-２８Ｂは、図１に示したクレジットレジスタ２８の一部である。また、図３に示したデータクレジットＦＩＦＯ２８Ｃは、１以上のクレジットレジスタ２８又はＦＩＦＯメモリ若しくは他のメモリとしてインプリメントされている。或いはまた、データクレジットＦＩＦＯ２８Ｃはインプリメントされず、そのかわりに、そこに記憶されたデータが受信パケットにより（例えば、バッファメモリ１６内に）キューされる。

クレジット管理ユニット２６は、未使用ＤＵの最大数を参照し、様々な点で解放されるクレジットを計算する。最大ＤＵエラーレジスタ２８Ａはこの値を記憶する。クレジット管理ユニット２６が上記値を生成するか、若しくは上記値がソフトウェアによってレジスタ２８A内にプログラム化されるかの何れかである。或る実施例では、DU及びBUの両方が固定され、かつ、クレジット管理ユニット２６内にきっちりコード化される。そして、レジスタ２８Aは除外される。

一実施例において、クレジット管理ユニット２６は解放クレジットを蓄積し、これを解放データクレジットレジスタ２８Ｂ内の送信機１２へ送信する。クレジット管理ユニット２６は、解放クレジットを送信するときを決定する任意のメカニズムを使用する。例えば、解放クレジットの最後の送信や、経過時間及び解放クレジットの数の組み合わせなどがあってから或る期間の時間が経過した後、或る数のクレジットが蓄積されたら（例えば、プログラム化された閾値を超えるなど）解放クレジットを送信する。同様のレジスタが解放ヘッダークレジットを蓄積するのに用いられたり、又は同じレジスタ内のフィールドが使用されたりする。

データクレジットＦＩＦＯ２８Ｃは、バッファメモリ１６に記憶される各パケットに関するデータクレジットの数（＃ＤＣrs）を記憶する。パケットはバッファメモリから消費されるので、データクレジットの対応する数はデータクレジットＦＩＦＯ２８Ｃから読み出され、そして解放される。クレジット管理ユニット２６は、パケットを送信するのに消費したデータクレジット総数、及び当該パケットを受信することに応じて解放したデータクレジットの数に基づき、各受信したパケットのデータクレジット数を計算する。

図４は、システム１０の初期化中に受信機１４の一実施例におけるオペレーションを示すフローチャートである。理解を容易にする目的でブロック図は特定の順序で示したが、他の順序も用いられ得る。ブロックは、受信機１４内のロジックを並列に、組み合わせて実行することができる。ブロック、ブロックの組み合わせ、フローチャートの少なくとも１つは、全体としてマルチ・クロック・サイクル上でパイプライン化され得る。

クレジット管理ユニット２６は、受信機１２に通知されるはずのヘッダークレジットの数（header_credits）及びバッファユニット（Ｎ）当りのデータユニットの数に基づき、総ポテンシャル・データユニット・エラー（DU_Err）を決定する。詳しく言うと、DU_Errは、(N-1)*(header_credits−１)によって与えられる（ブロック５０）。クレジット管理ユニット２６は、データユニット（データクレジット）の数を決定し、送信機１２に通知する（DU_Adv）。つまり、DU_Advは、バッファメモリ１６におけるデータユニットの総数（Ｎ*パケットデータを記憶するために割り当てられたバッファユニット数）−ブロック５０で決定されたDU_Errとして計算される（ブロック５２）。効率的には、DU_Errはバッファメモリ１６内のバッファユニットで生じ得る未使用のデータユニットを扱うために保有されていたデータクレジットの数である。クレジット管理ユニット２６は、ヘッダークレジット及びデータクレジットのためのDU_Advを通知する（ブロック５４）。くわえて、クレジット管理ユニット２６は、レジスタ２８Ａ内のMax_DU_ErrをＮ−１にセットし、そしてまた、レジスタ２８Ｂ内の解放データクレジットをゼロに初期化する（ブロック５６）。

図５は、インタフェース２０上でパケットを受信することに応じた受信機１４のオペレーションの一例を示すフローチャートである。理解を容易にする目的でブロック図は特定の順序で示したが、他の順序も用いられ得る。ブロックは、受信機１４内のロジックを並列に、組み合わせて実行することができる。ブロック、ブロックの組み合わせ、フローチャートの少なくとも１つは、全体としてマルチ・クロック・サイクル上でパイプライン化され得る。

クレジット管理ユニット２６は、ペイロードにおいて認識されたデータエラー（すなわち、ペイロードデータを記憶するバッファユニットで未使用なデータユニットの数）を決定する（ブロック６０）。クレジット管理ユニット２６は、未認識のデータエラーがMax_DU_Errから認識されたデータエラーを差し引いた値に等しいことを決定する（ブロック６２）。未認識のデータエラーは、パケットを受信すると解放されるデータクレジットの数である。クレジット管理ユニット２６は、解放データクレジットレジスタ２８Ｂ内の解放データクレジットに対して未認識のデータエラーを追加する（ブロック６４）。さらに、パケットがデータクレジットＦＩＦＯ２８Ｃ内のバッファメモリ１６から消費されるとき、クレジット管理ユニット２６は解放されるはずのデータクレジット数を記憶する（ブロック６６）。詳しく言うと、ＦＩＦＯに書き込まれた数は、ペイロードから未認識のデータエラーを差し引いた値に対応する実際のデータクレジット数である。

図６はバッファメモリ１６から消費されるパケットに応じた受信機１４のオペレーションの一例を示すフローチャートである。一般的に、ターゲット１８によってバッファメモリ１６から読み出されるとき、そうでなければパケットがバッファメモリ１６にもはや記憶する必要がないとき（例えば、パケットが落ち込んだ等）、パケット消費される。理解を容易にする目的でブロック図は特定の順序で示したが、他の順序も用いられ得る。ブロックは、受信機１４内のロジックを並列に、組み合わせて実行することができる。ブロック、ブロックの組み合わせ、フローチャートの少なくとも１つは、全体としてマルチ・クロック・サイクル上でパイプライン化され得る。

クレジット管理ユニット２６は、データクレジットＦＩＦＯ２８Ｃ内のエントリーからデータクレジット数を読み出し、そのデータクレジット数をレジスタ２８Ｂ内の解放データクレジットに追加する。その結果、データクレジットを解放する（ブロック７０及び７２）。一実施例において、パケットは受信した順序で消費され、そしてデータクレジット数はＦＩＦＯのヘッダーから読み出される。パケットが異なる順序で消費される場合、所望のエントリーに対してＦＩＦＯへのオフセットが提供される。

図４〜６は、各ペイロードについて取っておいた最大数と比較したとき、バッファユニット内の未使用のデータクレジットの実際の数に基づき、データクレジットの早期の解放に関連するオペレーションを示していることに留意されたい。受信機１４及びクレジット管理ユニット２６の少なくとも何れかは、各ポイントにおいて上述したものと同様の追加のオペレーションを含む。

受信機１４の別の実施例は、上述したデータクレジットの早期解放に加えて又は代わりに、適合クレジット管理を実行するする。適合クレジット管理により、受信機１４はヘッダーに割り当てられるバッファメモリ１６に、及びインタフェース２０に実際に受信されるトラフィックへのデータに割り当てられるバッファメモリ１６に一致することを試みる。つまり、データペイロードのサイズが増大するとき、多くのデータクレジット及び少ないヘッダークレジットがインタフェースバンド幅のより効率的な使用を認める。（というのも、各パケットは依然として１つのヘッダークレジットを要求するが、ペイロードについてはマルチのデータクレジットであるからである）。データペイロードのサイズが増大するので、少ないデータクレジット及び多くのヘッダークレジットを持つことはインタフェースのバンド幅の効率的な使用を求めることになる（というのも、各パケットの要求されたデータクレジットに対する、要求されたヘッダークレジットの比率は増加しているからである）。

したがって、クレジット管理ユニット２６は、受信機１４により受信されたデータペイロードのサイズをモニタし、ヘッダーに割り当てられたバッファメモリ（例えば、ヘッダーのバッファユニット３０のサイズ）の量及びデータペイロードに割り当てられたバッファメモリ（例えば、データのバッファユニット３２のサイズ）の量をダイナミックに修正する。或いはまた、ヘッダーに割り当てられたメモリの量は、所望のヘッダー最大数に対応するのに十分な大きさであるが、クレジットは送信機が利用可能なヘッダークレジットの数及びデータクレジットの数を増減するように管理される。このようなダイナミックなクレジット管理は、バッファメモリ１６のより効率的な使用を許可することでもある。なぜなら、上述したとおり、ヘッダークレジットの数はバッファユニットにおける未使用のデータユニットに基づき留保されるべきデータクレジットの数に影響を及ぼすからである。

一実施例において、ペイロードの期待したサイズの真ん中に、適当なデータペイロードをもつパケットに関して、ヘッダー及びデータクレジット（及び対応するバッファメモリ割り当て）を初期化する。例えば、一実施例において、インタフェース２０は、ＰＣＩｅインタフェースであり、データペイロードのサイズは０と２５６バイトの間にあり、クレジットは１２８バイトペイロードに関して初期化される。次に、オペレーションで経験されたペイロードの実際のサイズに応答してダイナミックな調整が実行される。

図７は、上述したデータクレジットの早期解放と共に、ダイナミックなクレジット管理の一実施例を行うための詳細に関する受信機１４の一実施形態を表したブロック図である。図７の実施例は、上述したレジスタ２８Ａ、２８Ｂ、及びＦＩＦＯ２８Ｃを含む。さらに、解放ヘッダークレジット（ＨＣre）レジスタ２８Ｄ、最大外部ヘッダークレジット（MaxExHead）レジスタ２８Ｅ、最大再呼び出しヘッダークレジット（MaxRecHead）レジスタ２８Ｆ、ペンディングヘッダークレジット（PendHeadCr）レジスタ２８Ｇ、ペンディングデータクレジット（PendDataCr）レジスタ２８H、認識データクレジット（RlzdDataCr）レジスタ２８Ｉ、及び認識ヘッダークレジット（RlzdHeadCr）レジスタ２８Ｊを含み、図７に示すクレジット管理ユニット２６にすべて結合される。

解放ヘッダークレジット（ＨＣre）レジスタ２８Ｄはレジスタ２８Ｂに類似するが、解放ヘッダークレジットを蓄積する。或いはまた、上述したとおり、解放ヘッダークレジット及び解放データクレジットは、所望であれば同一レジスタの２つのフィールドに蓄積される。MaxExHead及びMaxRecHeadレジスタ２８Ｅ−２８Ｆは、ダイナミックなクレジット管理に制限される。これらのクレジットは後述するとおり、クレジット管理ユニット２６によって自動的にセットされたり、又は所望であればソフトウェアによってプログラムされる。詳しく言うと、データクレジットを差し控えることにより割り当てられる追加のヘッダークレジットの最大数は、MaxExHeadレジスタ２８Ｅにより示される。追加のヘッダークレジットを解放するために差し控えられるヘッダークレジットの最大数は、MaxRecHeadレジスタ２８Ｆにより示される。

ペンディングヘッダークレジット及びペンディングデータクレジットレジスタ２８Ｇ−２８Hは、計画されたヘッダー及びデータクレジット調整と、その計画された調整を満たすために要求された解放ヘッダー又はデータクレジットとを蓄積する。これらの蓄積は、ダイナミック調整が生じる際に実行され、そのダイナミック調整において扱われないクレジットをキャプチャーする。例えば、一実施例において、ヘッダークレジットの増加が３つのデータクレジットの減少を要求するとする。３つのデータクレジットがまだ使用可能でない場合、レジスタ２８Hに使用可能なデータクレジットが蓄積される。ペンディングヘッダー及びデータクレジットは、その後の解放クレジットを介して取得される必要なクレジットのキャプチャーを許可する値が送られる。認識されたデータクレジット及びヘッダークレジットレジスタ２８Ｉ−２８Ｊは、送信後の認識されたヘッダークレジット調整及びデータクレジット調整を記憶する。

図８を参照すると、適合クレジット管理を実行するシステム１０の初期化中、受信機１４の一実施例のオペレーションを例示する高レベルのフローチャートが示されている。データクレジットの早期解放を実行する実施例ということから、図８のオペレーションは、図４のオペレーションに追加されるものである。理解を容易にする目的で特定の順序にあるブロックが示されているが、他の順序も用いられ得る。ブロックは、受信機１４内のロジックを並列に、組み合わせて実行することができる。ブロック、ブロックの組み合わせ、フローチャートの少なくとも１つは、全体としてマルチ・クロック・サイクル上でパイプライン化され得る。

クレジット管理ユニット２６は、MaxExHeadレジスタ２８Ａを、許可された最大ヘッダー数（＃ＣＭＤ）から中間サイズパケット（header_credits）のために割り当てられたヘッダークレジット数を差し引いた値に初期化する。許可された最大ヘッダー数（＃ＣＭＤ）は、ハードウェアの最大数であったり、或いはヘッダーのバッファユニット３０の割り当てに基づくソフトウェアによりプログラムされていてもよい。ヘッダークレジットの数は、例えば、データバッファユニットの数を中間サイズパケットの２で除算した値に等しいこともある。したがって、追加のヘッダークレジットの最大数は、ヘッダーのバッファユニットで割り当てられなかった残りのスペースであり得る（ブロック８０）。リコールされたヘッダークレジットの最大数（追加のデータクレジットを許可するためにダイナミックに除去されるヘッダークレジット-MaxRecHead）は、現在ヘッダークレジットの１／２、又は、バッファメッセージ１６内のデータバッファユニットの総数を４で割った数の整数値をヘッダークレジットから差し引いた数の小さい方として初期化される（ブロック８２）。ヘッダークレジット数の１／２は、最大パケットに関する合理的な数であるとして選択されるものである。４で割られたデータバッファユニットの数は、本実施例に関しては最小である。なぜなら、最大のデータペイロードが４バッファユニットであるからである。一実施例において、ヘッダークレジットの初期数が２以下の場合、最大リコールヘッダークレジットはゼロに設定されることに留意されたい。２又は１つのヘッダークレジットのとき、ヘッダークレジットを削減することによって得られる利益は何もない。というのは、ヘッダークレジットの不足は追加データクレジットを使用することを回避するからである。クレジット管理ユニット２６は、ヘッダークレジットの数及びデータユニットの通知データクレジット（DU_Advデータクレジット）を通知する（ブロック８４）。

図９を参照すると、パケットを受信することに反応した受信機１４の一実施例のオペレーションを例示する高レベルのフローチャートが示されている。データクレジットの早期解放を実行する実施例ということから、図９のオペレーションは、図５のオペレーションに追加されるものである。理解を容易にする目的で特定の順序にあるブロックが示されているが、他の順序も用いられ得る。ブロックは、受信機１４内のロジックを並列に、組み合わせて実行することができる。ブロック、ブロックの組み合わせ、フローチャートの少なくとも１つは、全体としてマルチ・クロック・サイクル上でパイプライン化され得る。

一般的に、クレジット管理ユニット２６は、データペイロードのサイズに基づき４カテゴリーの１つにパケットを分類し、そしてそのカテゴリーに従いクレジットを調整する。その結果、本実施例では、各受信パケットに基づく調整を行なう。他の実施例では、所望であれば、調整をするために２以上のパケットにわたるパケットサイズのモニタリングを行う。

パケットがデータペイロード処理を含まない場合（判断ブロック９０で、「yes」）、そのパケットはCat０パケットであり、どんな調整も行なわれない。パケットが中間サイズのパケットデータペイロードの１／２以下（例えば、上述したPCIe実施例における６４バイト）であれば（判断ブロック９２で、「yes」）、そのパケットはCat１パケットである。データペイロードはCat１パケットよりも相当に小さく、その結果、データクレジットを削減すること及びヘッダークレジットを増加することは、インタフェースのバンド幅使用を良くすることにつながる（ブロック９４）。パケットが中間サイズのパケットの０．５〜１．５倍の間にあるデータペイロードを含む場合（判断ブロック９６で、「yes」）、パケットはCat２パケットである。Cat２において、パケットデータペイロードは、ほぼ中間サイズである。Cat２サイズのレンジの場合、初期のヘッダー及びデータクレジットはほぼ正しい。ペンディング及び認識されたクレジットがゼロでない場合、クレジット管理ユニットは最新の調整とは反対の方向にクレジットを調整する（ブロック９８）。つまり、最新の調整がヘッダークレジットを増加し、データクレジットを減少させるためであった場合、クレジット管理ユニットはデータクレジットを増加させ、ヘッダークレジットを減少させる。これに対して、最新の調整がヘッダークレジットを減少させ、データクレジットを増加させるためであった場合、クレジット管理ユニットはデータクレジットを減少させ、ヘッダークレジットを増加させる。最後に、データペイロードが大（中間パケットの１．５倍以上、判断ブロック９６で、「no」）ならば、そのパケットはCat３パケットである。大きなペイロード（Cat３）パケットは、多くのデータクレジット及び少ないヘッダークレジットからの利益を享受し、その結果、クレジット管理ユニット２６はヘッダークレジットを減少させ、データクレジットを増加させる（ブロック１００）。

MaxHeadCr及びMaxRecHeadレジスタ２８F−２８Ｇがダイナミッククレジット調整に限界を与えるために使用される場合、図９のオペレーションは制限を受けることになることに留意すべきである（例えば、その調整がMaxHeadCr及びMaxRecHeadレジスタ２８F−２８Ｇによってセットされた限界に違反しているならば、クレジットは図示したように調整されない。）。

図１０及び１１は、一実施例に関し、図９のオペレーションを詳細に示す擬似コードをあらわす。図７に示したレジスタ名はこの擬似コードで示されている。さらに、擬似コードを簡便にするため、ヘッダークレジット及びデータクレジットに関するベクトル化された注釈が使用される。詳細には、adaptive_creditsは、｛adaptive_header_credits, adaptive_data_credits｝として定義され、pending_creditsは、｛PendHeadCr, PendDataCr｝として定義される。adaptive_creditsは、（将来的に調整の可能性がある）ヘッダークレジット及びデータクレジットである。解放ヘッダークレジット(releasing_header_credits)及び解放データクレジット(releasing_data_credits)は、現在、解放されているクレジットである。解放データクレジット(releasing_data_credits)は、上述したように、データエラーが所与のパケットに関する最大エラーよりも少ないとき、早期に解放されるデータクレジットを含む。また、解放ヘッダークレジット(releasing_header_credits)及び解放データクレジット(releasing_data_credits)の変数は、バッファメモリ１６からのパケット消費を理由に解放されたクレジットを含む。

図１０は、適合クレジットの生成を示す。一般的に、限界に達したならば、適合クレジットはペンディングクレジットに等しい。そうでなければ、適合クレジットは、受信パケットのカテゴリーに依存する（及びCat２パケットのケースでは最新の調整に依存する）クレジットを、ペンディングクレジットに増減することを含む。本実施例の場合、最新の調整は、ペンディングヘッダークレジット及び認識されたヘッダークレジットの総和をとって、それをゼロと比較することによって検出される。

図１０にみられるとおり、本実施例の場合、１つのヘッダークレジットが３つのデータクレジットに等しい。それゆえ、ヘッダークレジットを１つ増やすことは、データクレジットを３つ減らすことである。逆も同じである。他の実施例では、Ｎ−１に基づき、データクレジットに対する異なる比率のヘッダークレジットを有する。

最後に、図１０において、中間値であるremaining_pemding_dが計算される。このremaining_pemding_dは、０以下であり、且つ３より小さくするべきである。一実施例において、PendHeadCrが負であれば、remaining_pemding_dは０である。

図１１は、図１０で決定された適合クレジット及び解放クレジット（releasing credits）に基づく認識されたクレジットの計算を示す。繰り返しになるが、図１１の例は１つのヘッダークレジットに等しい３つのデータクレジットに基づくものである。それは、任意の所与の時点で調子をあわせてペンディングされる１又は２のデータクレジットを許可する。最後に、レジスタ２８Ｂ、２８Ｄ、及び２８Ｇ−２８Ｊの更新が図１１に示されている。ここで、“＋＝”は、等号の記号の右側の値で、レジスタの現在値を増加させることをあらわし、“−＝”は、等号の記号の右側の値で、レジスタの現在値を減少させることをあらわしている。

上述した開示が完全に理解されることによって、多数の変形例及び修正例が当業者によって明らかになるであろう。特許請求の範囲は、これらの変形例及び修正例のすべてを包含するように解釈されることを意図している。

Claims (13)

1. クレジット管理ユニットを含む受信機と、前記受信機に結合されたバッファメモリとを備えた装置であって、前記受信機の使用中に前記受信機と結合するインタフェースに関する前記フロー制御クレジットを管理し、前記インタフェースで受信される各パケットは、前記インタフェースでのフロー制御に関する１以上のヘッダークレジットとして数えられるヘッダーと、更にオプションとして前記インタフェースでのフロー制御に関する１以上のデータクレジットとして数えられるデータとを含み、前記各データクレジットは固定されたデータバイト数をあらわし、さらに前記バッファメモリには、前記受信機によって前記インタフェースで受信されるパケットに対応するパケットヘッダー及びパケットデータが記憶され、
   前記クレジット管理ユニットは、１以上の前記受信したパケット内のパケットデータのサイズにあわせて前記パケットデータを記憶するのに使用される、第１の量のバッファメモリと、第２の量のバッファメモリをダイナミックに調整し、
   前記クレジット管理ユニットは、前記ダイナミックな調整にあわせて、前記インタフェースと接続する送信機に対するデータクレジット及びヘッダークレジットを解放し、
   前記クレジット管理ユニットは、前記第１の量を増加させ、かつ、第２の量を減少させ、そして消費したパケットに対応する１以上のデータクレジットを保有し、その代わりに前記第１及び第２の量の修正に影響を与えるために前記送信機で１以上のヘッダークレジットを解放する、前記装置。
2. ヘッダークレジットは、データクレジットにより示される前記固定されたデータバイト数をＮ−１倍してあらわされ、前記クレジット管理ユニットは、１個のヘッダークレジットを解放するためにＮ−１個のデータクレジットを保有する、請求項１に記載の装置。
3. 前記クレジット管理ユニットは、第１の閾値よりサイズの小さなパケットデータを有する１以上のパケットを受信することにあわせて、前記第１の量を増加させて且つ前記第２の量を減少させる、請求項１に記載の装置。
4. 前記クレジット管理ユニットは、前記第１の量を減少させて前記第２の量を増加させ、そして消費したパケットに対応する１以上のヘッダークレジットを保有し、その代わりに送信機において前記調整に影響を与えるために１以上のデータクレジットを解放する、請求項１に記載の装置。
5. 前記クレジット管理ユニットは、第２の閾値よりサイズの大きなパケットデータを有する１以上のパケットを受信することにあわせて、前記第１の量を減少させて且つ前記第２の量を増加させる、請求項４に記載の装置。
6. 前記クレジット管理ユニットは、第１の閾値よりサイズの大きく、第２の閾値よりサイズの小さなパケットデータを有する１以上のパケットを受信することにあわせて、最新に行なった調整とは反対の調整を実行する、請求項１に記載の装置。
7. 前記クレジット管理ユニットは、前記第１の量の最小サイズ及び前記第１の量の最大サイズを決定し、そして前記最小サイズ及び前記最大サイズに基づき、前記第１の量及び第２の量の前記ダイナミックな修正を制限する、請求項１に記載の装置。
8. フロー制御クレジットを管理する受信機において実行される方法であって、前記受信機の使用中に前記受信機と接続するインタフェースに関する前記フロー制御クレジットを管理し、前記インタフェースで受信される各パケットは、前記インタフェースでのフロー制御に関する１以上のヘッダークレジットとして数えられるヘッダーと、更にオプションとして前記インタフェースでのフロー制御に関する１以上のデータクレジットとして数えられるデータとを含み、前記各データクレジットは固定されたデータバイト数をあらわし、前記方法は、
   １以上の受信したパケット内のパケットデータのサイズにあわせて、第１の量のヘッダークレジットをダイナミックに増加させ、第２の量のデータクレジットをダイナミックに減少させる処理と、
   ダイナミックに調整する前記処理にあわせて、送信機に対するデータクレジット及びヘッダークレジットを前記インタフェース上で解放する処理であって、前記解放は、消費したパケットに対応する１以上のデータクレジットを保有し、その代わりに前記調整に影響を与えるために前記送信機で１以上のヘッダークレジットを解放することを含む当該処理と、を含む方法。
9. 第１の閾値よりサイズの小さなパケットデータを有する１以上のパケットを受信する処理を更に含み、前記第１の量をダイナミックに増加させて且つ前記第２の量をダイナミックに減少させる処理は前記受信にあわせて行なわれる、請求項８に記載の方法。
10. 前記第１の量をダイナミックに減少させ且つ前記第２の量をダイナミックに増加させる処理と、
    消費したパケットに対応する１以上のヘッダークレジットを保有し、その代わりに前記修正に影響を与えるために前記送信機で１以上のデータクレジットを解放する処理と、
    を含む、請求項８に記載の方法。
11. 第２の閾値よりサイズの大きなパケットデータを有する１以上のパケットを受信することを更に含み、前記受信にあわせて前記第１の量を減少させて且つ前記第２の量を増加させる、請求項１０に記載の方法。
12. 第１の閾値よりサイズの大きく、第２の閾値よりサイズの小さなパケットデータを有する１以上のパケットを受信することにあわせて、最新に行なった調整とは反対の調整を実行することを更に含む、請求項８に記載の方法。
13. 前記第１の量の最小サイズ及び前記第１の量の最大サイズを決定する処理と、
    前記最小サイズ及び前記最大サイズに基づき、前記第１及び第２の量の前記ダイナミックな修正を制限する処理と、
    を更に含む請求項８に記載の方法。

Images