(57)【要約】バッファ管理システムが、書き込み可能な数のほぼ均一なサイズのバッファ（２２０乃至２２３）に全メモリ空き容量（２００）を分割する。アプリケーションは、バッファ管理システム（２００）に所望の数のバッファを通信し、それからアプリケーションによって使用されるデータ転送経路の間に当該バッファを割り当てる。随意的に複数の均一なサイズのバッファが、単一の論理バッファを形成するように結合され得る。均一なサイズのバッファ（２２０乃至２２３）への全メモリ空き容量（２００）の分割をもたらすことによって、複数のバッファを管理するのに必要とされるオーバヘッドは最小限化される。選択された数の管理バッファをアプリケーションにもたらすことによってバッファ管理の詳細に配慮する必要なしに当該アプリケーションは必要に応じてバッファを割り当て得る。【特許請求の範囲】
【請求項１】
バッファメモリと、前記バッファメモリに可動的に結合され、前記バッファの数量を決定する分割パラメータに依存して前記バッファメモリを複数の独立バッファに分割するように構成される制御器とを有するバッファ管理システムであって、前記複数の独立バッファの各々のバッファは、前記バッファへの循環アクセスを容易化するように２の整数べき乗になるバッファサイズを有するバッファ管理システム。    
【請求項２】
前記制御器は、前記複数の独立バッファの選択バッファに対するポインタの循環インクリメントをもたらすためにビット上書き関数及びアドレスインクリメント関数しか必要としない循環インクリメント関数を含むように構成される請求項１に記載のバッファ管理システム。
【請求項３】
前記複数の独立バッファのバッファサイズは等しくなる請求項１に記載のバッファ管理システム。
【請求項４】
前記制御器は、複数の送信元−送信先経路の間に前記複数の独立バッファを割り当てるように更に構成される請求項１に記載のバッファ管理システム。
【請求項５】
前記制御器は、一つ又はそれより多くのアプリケーションに対して書き込みインタフェイス部及び読み出しインタフェイス部をもたらすように更に構成され、前記書き込みインタフェイス部は、記憶されるべきデータの識別部及び前記データを記憶する前記複数の独立バッファの選択バッファの識別部しか必要とせず、前記読み出しインタフェイス部は、前記選択バッファの識別部しか必要としない請求項１に記載のバッファ管理システム。
【請求項６】
前記バッファメモリはＭビットアドレスによってアドレスされ、前記複数の独立バッファの各々のバッファは、前記Ｍビットアドレスの一組のＮ最上位ビットを形成するＮビットインデックスによってインデックスされ、前記各々のバッファのサイズは少なくとも２Ｍ−Ｎになる請求項１に記載のバッファ管理システム。  
【請求項７】
分割パラメータを受信するステップと、前記メモリバッファを複数の独立バッファに分割するステップとを有するバッファメモリを管理する方法であって、前記バッファの数量は前記分割パラメータから決定され、前記複数の独立バッファの各々のバッファのサイズは２の整数べき乗になり、それによって各々のバッファの循環アドレッシングが容易化されるバッファメモリを管理する方法。  
【請求項８】
前記複数の独立バッファのバッファサイズは等しくなる請求項７に記載の方法。
【請求項９】
各々のバッファに対して循環アドレッシングをもたらすステップを更に含み、前記循環アドレッシングは、前記バッファメモリに対するアドレスをインクリメントするステップと、前記バッファメモリ内の前記バッファに対するインデックスに対応して前記アドレスの選択ビットを上書きするステップとを含む請求項７に記載の方法。
【請求項１０】
記憶されるべきデータの識別部及び前記データを記憶する前記複数の独立バッファの選択バッファの識別部しか必要としない書き込みインタフェイス部をもたらすステップと、前記選択バッファの識別部しか必要としない読み出しインタフェイス部をもたらすステップとを更に含む請求項７に記載の方法。
【請求項１１】
前記バッファメモリはＭビットアドレスによってアドレスされ、前記複数の独立バッファの各々のバッファは、前記Ｍビットアドレスの一組のＮ最上位ビットを形成するＮビットインデックスによってインデックスされ、前記各々のバッファのサイズは少なくとも２Ｍ−Ｎになる請求項７に記載の方法。
【請求項１２】
バッファメモリと、書き込み制御論理部及び読み出し制御論理部を含む制御器とを有する集積回路であって、前記制御器は、前記制御器にもたらされる分割パラメータに基づいて前記バッファメモリを複数のバッファに分割するように構成され、前記複数のバッファの各々のバッファは、２の整数べき乗になるサイズを有し、前記書き込み制御論理部及び読み出し制御論理部は各々、循環バッファとしての各々のバッファの使用を容易化するように構成される集積回路。
【請求項１３】
前記複数のバッファのサイズは等しくなる請求項１２に記載の集積回路。
【請求項１４】
前記循環バッファとしての各々のバッファの使用は、循環アドレッシングを必要とし、前記制御器は、前記バッファメモリに対するアドレスをインクリメントするように構成されるインクリメンタと、前記バッファメモリ内の前記バッファに対するインデックスに対応して前記アドレスの選択ビットを上書きするように構成されるビットマスク器とを介して前記循環アドレッシングをもたらすように構成される請求項１２に記載の集積回路。
【請求項１５】
前記書き込み制御論理部は、前記複数のバッファの選択バッファへのデータ値の記憶を前記データ値の識別及び前記選択バッファの識別にのみ基づいてもたらし、前記読み出し制御論理部は、前記データ値の読み出しを前記選択バッファの識別にのみ基づいてもたらす請求項１２に記載の集積回路。
【請求項１６】
前記バッファメモリはＭビットアドレスによってアドレスされ、前記複数の独立バッファの各々のバッファは、前記Ｍビットアドレスの一組のＮ最上位ビットを形成するＮビットインデックスによってインデックスされ、前記各々のバッファのサイズは少なくとも２Ｍ−Ｎになる請求項１２に記載の集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電子回路、特に複数の独立の読み出し／書き込み（リード／ライト（ｒｅａｄ／ｗｒｉｔｅ））バッファをもたらすように構成可能な（コンフィギュラブル（ｃｏｎｆｉｇｕｒａｂｌｅ））メモリシステムに関する。
【背景技術】
【０００２】
バッファは通常、データが送信元（ソース（ｓｏｕｒｃｅ））から送信先（デスティネーション（ｄｅｓｔｉｎａｔｉｏｎ））に伝送されるときデータを一時的に記憶するために使用される。当該データの一時記憶（ｔｅｍｐｏｒａｒｙ  ｓｔｏｒａｇｅ）により、送信元と送信先との非同期動作が可能になり、データの損失（ロス）なしに送信元のデータ転送レート（ｄａｔａ−ｔｒａｎｓｆｅｒ  ｒａｔｅ）を制限する効率的な手段がもたらされる。
【０００３】
最初に送信元からのデータは、送信元が供給し得るのと同じくらい高速にバッファに書き込まれ、送信先が受信し得るのと同じくらい高速にバッファから読み出される。送信元が送信先よりも低速となる場合、送信先はデータがバッファにおいて利用可能になるのを待たなければならない。送信元が送信先よりも高速になる場合、送信元はバッファが満杯（フル（ｆｕｌｌ））又は満杯近くになるまでデータをバッファにもたらし続け、バッファが満杯（フル（ｆｕｌｌ））又は満杯近くになる時点で送信元は、送信先がバッファからデータを削除して送信元データのために空き容量（スペース（ｓｐａｃｅ））を生成するまで送信を中止するように命令される。バッファが満杯になるまで送信元の転送レートで送信元からのデータの受信を可能にすることによって、間欠（断続）的な平均より高い転送レート（ｉｎｔｅｍｉｔｔｅｎｔ  ｈｉｇｈｅｒ−ｔｈａｎ−ａｖｅｒａｇｅ  ｔｒａｎｓｆｅｒ  ｒａｔｅ）はサポートされ、送信先における間欠受信遅延は必ずしも送信元に伝播されない。データ転送レート全体に影響を与えることなしに吸収（ａｃｃｏｍｍｏｄａｔｅ）され得る送信元及び送信先の転送速度における間欠の差（intermittent difference）の量はバッファのサイズ（大きさ）に依存しており、大きなバッファは小さなバッファよりも大きな差を吸収し得る。
【０００４】
バッファのサイズは通常、送信元若しくは送信先の何れか、又は送信元と送信先との両方の特性に基づいて、特に送信元及び送信先のデータ転送速度の間欠特性に関連して決定される。送信元と送信先とが各々均一な転送レートを有する場合、少ないバッファリングが必要とされる。送信元がデータのバースト（ｂｕｒｓｔ）をもたらす場合、又は送信先がブロックでデータを処理する場合、バッファは通常、バースト又はブロックのサイズを吸収するようにサイズが変更される。
【０００５】
ほとんどのシステムは、複数の送信元及び送信先を含んでおり、複数のバッファが各々の送信元と送信先との間のデータ転送を容易化するように使用される。ほとんどの場合、メモリの総量は制限され、各々のバッファに割り当てられるメモリの量は、特定の送信元と送信先との間の高い転送レートを保持することに関連する相対的な優先度（ｒｅｌａｔｉｖｅ  ｐｒｉｏｒｉｔｙ）及び他の性能ファクタ（ｐｅｒｆｏｒｍａｎｃｅ  ｆａｃｔｏｒ）だけでなく、送信元及び送信先の前述の特性に基づいて決定される。しかしながら多くの例において、システムがサポートするように設計される全ての送信元及び／又は送信先を利用しないシステム上でアプリケーションは実行され、当該送信元及び／又は送信先に関連するバッファは使用されない。同様に、異なるアプリケーションは、特定の送信元と送信先との間の転送に異なる優先度を関連付けてもよく、バッファのサイズの分布（分散（ｄｉｓｔｒｉｂｕｔｉｏｎ））は所望の優先度と一致していなくてもよい。
【０００６】
メモリの完全に構成可能な分割（パーティショニング（ｐａｔｉｔｉｏｎｉｎｇ））は、全バッファメモリ空き容量をアプリケーションにもたらし、当該アプリケーションにメモリを個別のサイズ変更されたバッファ（ｉｎｄｉｖｉｄｕａｌｌｙ  ｓｉｚｅｄ−ｂｕｆｆｅｒ）に論理的に分割させることによってアプリケーションにもたらされ得る。しかしながらこのような手法は通常、アプリケーションがバッファ管理の全ての態様を処理することを必要とする。代わりに当該システムはバッファ管理を処理する一方、書き込み（プログラム）可能なバッファサイズ（バッファの大きさ）も可能にする責任を保持してもよい。しかしながらこのような実施例において、バッファサイズを変化させるような知られていない組み合わせを管理することに関連するシステムのオーバヘッドは法外な犠牲をもたらし、且つ／又はシステムの性能を劣化させる処理遅延をもたらし得る。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、最小限のオーバヘッドでの構成可能なメモリ分割を可能にするバッファ管理システムを提供することにある。本発明の更なる目的は、制御すること及び使用することが容易なバッファ管理システムを提供することにある。本発明の他の更なる目的は、ハードウエアデバイスにおける実現に適したバッファ管理システムを提供することにある。
【課題を解決するための手段】
【０００８】
当該目的及び他の目的は、書き込み可能な数のほぼ均一なサイズのバッファに全メモリ空き容量を分割するバッファ管理システムをもたらすことによって実現される。アプリケーションは、バッファ管理システムに所望の数のバッファを通信し、それからアプリケーションによって使用されるデータ転送経路（パス（ｐａｔｈ））の間で当該バッファを割り当てる。随意的に複数の均一なサイズのバッファが、単一の論理バッファを形成するように結合され得る。均一なサイズのバッファへの全メモリ空き容量の分割をもたらすことによって、複数のバッファを管理するのに必要とされるオーバヘッドは最小限化される。選択された数の管理バッファをアプリケーションにもたらすことによってバッファ管理の詳細に配慮する必要なしに当該アプリケーションは必要に応じてバッファを割り当て得る。
【０００９】
本発明は、添付図面を参照して実施例によって更に詳細に記載される。
【発明を実施するための最良の形態】
【００１０】
図面を通じて同じ参照符号は同じ若しくは対応する特徴又は機能を示す。
【００１１】
図１は本発明によるバッファ管理システム１００のブロック図の例を示す。バッファ管理システム１００は、一つ又はそれより多くの送信元１１０から一つ又はそれより多くの送信先１２０へのデータの転送を容易化するために、書き込み制御論理部（ｗｒｉｔｅ  ｃｏｎｔｒｏｌ  ｌｏｇｉｃ）１３０及び読み出し制御論理部（ｒｅａｄ  ｃｏｎｔｒｏｌ  ｌｏｇｉｃ）１４０を制御するように構成される制御器（コントローラ（ｃｏｎｔｒｏｌｌｅｒ））１５０を有する。理解の簡単化のために別個の制御ブロック１３０、１４０、及び１５０として示されているが、制御ブロック１３０及び１４０は通常、制御器１５０のコンポーネントになる。従来技術において一般的となっているように、データを送信すると共に受信し得るデバイスは送信元１１０と送信先１２０との両方として含まれ得る。参照の簡単化のために送信元−送信先経路はこの場合、特定の送信元から特定の送信先へのデータの転送、複数の送信元から特定の送信先へのデータの転送、特定の送信元から複数の送信先へのデータの転送、複数の送信元から複数の送信先へのデータの転送をもたらす導管（コンジット）として規定される。すなわち送信元−送信先経路内のバッファは一つの送信元から一つの送信先へのデータのみを受信してもよく、一つの送信先にアドレスされるデータの全てを受信してもよく、一つの送信元から送信されるデータの全てを受信してもよく、又は複数の送信元から複数の送信先へのデータの全てを受信してもよい。
【００１２】
一つ又はそれより多くのアプリケーション（図示略）は、送信元１１０と送信先１４０との間の転送を開始させる。特定のアプリケーションに依存して、異なる送信元−送信先経路が規定されてもよく、異なる優先度が各々の経路に割り当てられてもよく、異なるトラフィック（データの流れ）パターン（ｔｒａｆｆｉｃ  ｐａｔｔｅｒｎ）がもたらされてもよい。本発明によれば制御器１５０は、異なる送信元−送信先経路の間の実効的且つ効率的なデータ転送に対する一つ又はそれより多くのアプリケーションの要求仕様に依存して独立バッファへのバッファメモリ２００の分割を構成する。
【００１３】
本開示から当業者にとって明らかなことに本発明は、様々な送信元−送信先経路の間でデータを転送しているアプリケーションが先験的に知られている実現に特によく適しているが、送信先ポートの総数は実行時におけるアプリケーションによって決定される。例えばバッファメモリ２００、書き込み制御論理部１３０、読み出し制御論理部１４０、制御器１５０は、ハードウエア設計システムにおける所定の“ライブラリ（ｌｉｂｒａｒｙ）”要素として具現化されてもよい。これらのライブラリを使用して顧客設計（カスタムデザイン）された集積回路が生成されると、制御器１５０は、集積回路において具現化されるか、又は当該集積回路を含むシステムにおいて具現化されるアプリケーションをサポートするためにバッファメモリ２００の分割をもたらす。他の例においてバッファ管理システム１００が、書き込み可能なデバイス又は様々なアプリケーションを実行し得るシステムに含まれていてもよく、アプリケーションの特定のセットが書き込み可能なデバイスに書き込まれるとき制御器１５０はバッファメモリ２００の分割をもたらす。
【００１４】
本発明の好ましい実施例において制御器１５０は、バッファメモリ２００から必要とされるバッファの数を特定するパラメータを受信する。以下分割（パーティション）パラメータ（ｐａｒｔｉｔｉｏｎ  ｐａｒａｍｅｔｅｒ）と称される当該パラメータに基づいて、制御器１５０はバッファメモリ２００を複数の等しいサイズのバッファに分割する。ここでバッファの等しいサイズｋは２のべき乗になる。本発明の好ましい実施例において、図２に示されているように分割の数も２のべき乗になる。
【００１５】
図２においてメモリ２００ａは、１の分割パラメータに対応する単一のバッファＢ０を有し、メモリ２００ｂは、２の分割パラメータに対応する二つのバッファＢ０  ２１０及びＢ１  ２１１を有する。メモリ２００ｃは、３又は４の分割パラメータに対応する四つのバッファ２２０、２２１、２２２、及び２２３を有する。通常の場合、メモリ２００ｄによって示されているように、図１のメモリ２００は、２Ｎ−１＋１とｎとの間の分割パラメータに対応する“ｎ”（ここで“ｎ”は２の整数べき乗（ｎ＝２Ｎ））の等しいサイズのバッファに分割される。
【００１６】
理解の簡単化のために本発明は最初、ｎに等しくなる分割パラメータの例に対してもたらされる。ここでｎは２のべき乗（ｎ＝２Ｎ）となる。以下２Ｎよりも小さな分割パラメータの例がもたらされる。
【００１７】
送信元からのデータは、次に利用可能な書き込み位置に挿入されるか、又は書き込まれ、最後の読み出されていない読み出し位置（last-unread read location）から送信先に移動させられるか、又は読み出される。書き込み制御論理部１３０により、次に利用可能な書き込み位置は使用されないことが保証される。ここで“使用されないこと”とは、まだ送信先に読み出されなければならないデータを含まないことと規定される。バッファ全体は、まだ送信先に読み出されなければならないデータを含むようにバッファが“満杯”になる場合、バッファへの書き込みは、最も古いか、又は最後に読み出されていないデータが送信先に読み出されるまで遅延させられ、それによってバッファにおける利用可能な空き容量は解放（ｆｒｅｅ）される。読み出し制御論理部１４０により、まだ送信先に読み出されていないデータは利用可能となることが保証される。さもなければ読み出し動作はストール（停止）（ｓｔａｌｌ）される。
【００１８】
従来のバッファシステムにおいて、本発明のように各々のバッファＢ０、Ｂ１、．．．は、バッファの“最上位（トップ（ｔｏｐ））”又は“最後尾（エンド（ｅｎｄ））”
の後の“次の”位置が “先頭（スタート（ｓｔａｒｔ））又は“最下位（ボトム（ｂｏｔｔｏｍ））” になる循環（環状）バッファ（ｃｉｒｃｕｌａｒ  ｂｕｆｆｅｒ）として構成される。書き込み制御論理部１３０及び読み出し制御論理部１４０は、複数のバッファにおける当該同時循環アドレッシングをもたらすように構成される。以下の擬似コード（ｐｓｅｕｄｏ−ｃｏｄｅ）は、単一のバッファに対して循環インクリメント関数（ｃｉｒｃｕｌａｒ−ｉｎｃｒｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）をもたらす。
function next_address(current_address, buffer_start, buffer_end)
if current_address < buffer_end 
then next_address == current_address + 1
else next_address == buffer_start
【００１９】
ｎバッファを備えるバッファメモリ２００の例において、関数next_addressは
function next_address(current_address, buffer_index)
if current_address < buffer_end[buffer_index]
then next_address == current_address + 1
else next_address == buffer_start[buffer_index];
として規定される。ここでbuffer_start及びbuffer_end配列（アレイ（ａｒｒａｙ））は各々のバッファの先頭及び最後尾の位置を含んでおり、関数に局所的に（ローカルに）認知される。関数の当該形態を使用して、ｎバッファのバッファ“ｊ”までの書き込みポインタ（ｗｐ）のインクリメントは以下のコマンドを介してもたらされる。
wp[j]
= next_address(wp[j], j) 
【００２０】
同様にバッファ“ｊ”までの読み出しポインタ（ｒｐ）のインクリメントは以下のコマンドを介してもたらされる。
rp[j]
= next_address(rp[j], j) 
【００２１】
バッファｊへの書き込みは以下の擬似コードによって規定され得る。
function write(data, j)
if OK_to_write(j)
then:      buffer[wp[j]] == data
wp[j] == next_address(wp[j],j)
write == SUCCESS;
else:      write == FAILURE;
ここで当該モデルにおいて書き込みポインタｗｐは、データを配置するためにバッファにおける次の利用可能な位置をポイント（ｐｏｉｎｔ）し、関数に局所的に認知される。OK_to_write関数は、読み出し及び書き込みポインタの比較に基づいてバッファが満杯でないことを検証する従来の確認関数（ｃｈｅｃｋｉｎｇ  ｆｕｎｃｔｉｏｎ）である。本例において書き込み関数がFAILUREを返す場合、送信元は更なるデータを送信しないように命令（指示）され、書き込み関数は、SUCCESSが返されるまでアプリケーションによって繰り返し呼び出され、送信元は他のデータ要素（ｄａｔａ  ｉｔｅｍ）を送信するために再びイネーブル（許可（ｅｎａｂｌｅ））される。従来技術において知られているように送信元とバッファとの間にかなりの時間差（タイムラグ（ｔｉｍｅ  ｌａｇ））が存在する場合、“ほぼ満杯（ｎｅａｒｌｙ  ｆｕｌｌ）”を規定するために閾値数のデータスロットを使用して、バッファが“ほぼ満杯”になるときはいつでも送信元は更なるデータを送信するのをディスエーブル（禁止（ｄｉｓａｂｌｅ））されてもよい。
【００２２】
バッファｊからの読み出しは以下の擬似コードによって規定され得る。
function read(j)
loop here until OK_to_read(j);
read == buffer[rp[j]]
rp[j] == next_address(rp[j],j]); 
【００２３】
ここで当該モデルにおいて読み出しポインタｒｐは、データを読み出すためにバッファにおける次の潜在的に利用可能な位置をポイントする。OK_to_read(j)関数は、データがバッファに書き込まれたこと、及びデータがまだ読み出されていないことを検証する従来の確認関数である。本例においてバッファ内で読み出されるべきデータが存在することをOK_to_read関数が示すまで読み出し関数は自身の内部ループにおいて待機する。
【００２４】
上記の例においてアプリケーションによるｎバッファのうちの一つへの書き込み又はｎバッファのうちの一つからの読み出しは単一の関数呼出し（ファンクションコール（ｆｕｎｃｔｉｏｎ  ｃａｌｌ））しか必要とせず、それによってアプリケーションの複雑さが最小限に保持されることは注意されるべきである。本発明によればアプリケーションは、制御器１５０にバッファに対する自身の必要性を単に通知し、その後上記バッファインデックス（添え字（ｉｎｄｅｘ））（上記の例における“ｊ”）を使用して各々のバッファを各々の送信元−送信先データ経路に割り当てることを必要とするだけである。様々な経路に沿う各々の読み出し又は書き込みは、対応するインデックスされたバッファに対して読み出し又は書き込みを実行することによってもたらされる。図１の破線矢印によって示されているようにデータ転送のための経路の識別は、データ内の送信先フィールドの使用を介する場合のように、多くの場合転送されているデータ内に含まれる。当該実施例において制御器１５０は、識別された送信先に対応するバッファインデックスへの、データにおける送信先フィールドの変換をもたらすための書き込み制御論理部１３０に対して適切なマッピングをもたらす。当該実施例において明示的な“書き込み”関数呼出しがアプリケーションに含まれることは必要とされず、書き込み関数は送信先フィールドを含むデータパケットの受信（到達（ａｒｒｉｖａｌ））によって暗示的に呼び出され、バッファインデックスはデータ自体から自動的に計算される。
【００２５】
上記の例において各々の読み出し又は書き込み動作は、明示的又は暗示的の何れにおいてもnext_address関数に対する呼出しを必要とすることも注意されるべきである。それ故にnext_address関数の複雑さは、バッファ管理システム１００の達成可能なスループットに直接的な効果を有するであろう。next_address関数は上記のように、buffer_start及びbuffer_end配列のインデックスされたコンテンツに基づく割り当て、比較、及び条件テスト（ｃｏｎｄｉｔｉｎａｌ  ｔｅｓｔ）を必要とする。更にnext_address関数は上記のように、これらの配列又は同様の構造体の記憶を必要とする。当業者は上記のnext_address関数が特にハードウエアデバイスにおける実現にあまり適していないことも理解するであろう。
【００２６】
本発明によればnext_address関数は、buffer_start及びbuffer_end配列のインデックスされたコンテンツに基づく割り当て及び比較だけでなく条件テストも削除するように最適化され、それによってハードウエアの実現に特によく適している関数がもたらされる。好ましい実施例において、buffer_start及びbuffer_end配列も削除される。
【００２７】
上記で注意されるように本発明によれば、ｎの等しいサイズのバッファ（ｎ  ｅｑｕａｌ−ｓｉｚｅｄ  ｂｕｆｆｅｒ）の各々は、２の整数べき乗になるサイズ“ｋ”（ｋ＝２Ｚ）を有する。サイズ２Mのバッファメモリ２００の開始をアドレスゼロと規定すること、及びｎの等しいサイズのバッファの各々は、アドレスセロで始まり２M−１で終わるバッファメモリ２００において連続になると仮定することにより、各々のバッファを２Ｚのサイズｋに制限することにより以下の有利な結果がもたらされる。すなわち
アドレスのより低い次数Ｚビットはバッファの各々における固有の位置（０から２Ｚ−１まで）に対応し、
より高い次数Ｍ−Ｚビットはバッファの各々に対する上記インデックス（０からｎ−１まで）に対応する。
【００２８】
図３は、本発明による分割バッファシステムにおける使用のためのバッファアドレッシング方式の構成例を示す。上記で注意されるようにバッファメモリ２００はサイズ２Mと仮定され、それ故にＭビットはバッファメモリ２００内のメモリ位置の各々を一意的に（ｕｎｉｑｕｅｌｙ）アドレスするために使用される。当然のことながらＭビット及びＮビットは２Ｎまでのバッファをインデックスすることが必要とされる。残されるＭ−Ｎビットはそれから、上記で注意されるようにアドレスのより低い次数Ｚ（＝Ｍ−Ｎ）ビットがサイズ２Ｎのバッファ内に固有位置（ｕｎｉｑｕｅ  ｌｏｃａｔｉｏｎ）に対応するため、２Ｎバッファの各々の範囲内における直接アドレッシングに対して利用可能となる。
【００２９】
図３に示されている構造体を使用して、循環インクリメント関数を実現するための擬似コードは
function next_address(current_address, buffer_index)
next_address == current_address + 1
next_address{upper N bits} == buffer_index;
でもたらされる。
ここで括弧の表記は、next_addressの上位Ｎビットが、もたらされているbuffer_indexによって置換されることを示している。
【００３０】
当業者は、上記関数がハードウエアにおける実現に特によく適していることを理解するであろう。第一の記述は単に、current_addressの全コンテンツにもたらされるアドレスインクリメント関数に対応する。current_addressが、バッファメモリ２００における割り当てられたバッファ空き容量の最後尾になる場合、当該インクリメント関数は‘キャリー（ｃａｒｒｙ）’を、図３の構造体のバッファインデックスフィールド（上位Ｎビット）にもたらすであろう。これにより、次の記述はないが、next_addressは次の隣接するバッファに誤って関連付けられ得る。しかしながら第二の記述は、next_addressがバッファインデックスフィールドにおいて適切なbuffer_indexで返されることを保証することによってこのような誤った関連付け（ｅｒｒｏｎｅｏｕｓ  ａｓｓｏｃｉａｔｉｏｎ）を自動的に修復する（回復させる（ｃｕｒｅ））ビット上書き（ｂｉｔ−ｏｖｅｒｗｒｉｔｅ）関数である。ハードウエアにおいて当該記述は一つ又は二つのビットマスキング（ｂｉｔ−ｍａｓｋｉｎｇ）動作を介してもたらされる。
【００３１】
当業者は、図３の構造体が等しいサイズのバッファの各々に対して最大限に利用可能なメモリをもたらすことも認識するであろう。図２に示されているように、一つのバッファだけが必要とされる場合、Ｎはゼロに等しくなり、全バッファメモリ２００は当該バッファに割り当てられる。二つのバッファだけが必要とされる場合、Ｎは１に等しくなり、各々のバッファは全バッファメモリ２００の半分としてもたらされる。四つのバッファが必要とされる場合、Ｎは２に等しくなり、各々のバッファは全バッファメモリ２００の４分の１としてもたらされる。
【００３２】
通常のハードウエアの実施例において前述の“ライブラリ”要素は大きなバッファメモリ２００を含むであろう。わずかな送信元データ経路（ｓｏｕｒｃｅ−ｄａｔａ  ｐａｔｈ）しか含まないアプリケーションにおいて、送信元データ経路の各々は当該バッファメモリ２００の大きなセグメント（区分（ｓｅｇｍｅｎｔ））として割り当てられ、それによってことによると高いスループットレートがもたらされる。多くの送信元データ経路を含むアプリケーションにおいて、経路の各々は当該バッファのより小さなセグメントとしてもたらされ、通常多くの送信元データ経路を備えるアプリケーションにおいて固有のことであるようにスループットは制限される傾向にあるが、当該アプリケーションはライブラリ要素の再設計を必要とすることなくサポートされるであろう。
【００３３】
すなわち２の整数べき乗となる等しいサイズのバッファにメモリ空き容量を分割することによって、複数の循環バッファを管理するために必要とされる最小限のオーバヘッド及び全利用可能なバッファメモリを分割すると共に割り当てる最小限のオーバヘッドが効率的且つ効果的なバッファ管理システムにもたらされ得る。
【００３４】
バッファは等しい物理サイズになるが、アプリケーションは複数の等しい物理サイズバッファ（ｅｑｕａｌ−ｐｈｙｓｉｃａｌ−ｓｉｚｅ  ｂｕｆｆｅｒ）を一つの論理バッファに論理的に関連付け、このより大きな論理バッファを特定の送信元−送信先経路に関連付け得ることを当業者は認識するであろう。例えばアプリケーションは図２のバッファメモリ２００ｃのバッファＢ０、Ｂ１、及びＢ２を一方の経路に割り当て、バッファＢ３を他方の経路に割り当て得る。第一の経路を介するデータ転送は、Ｂ０、Ｂ１、Ｂ２、Ｂ０、Ｂ１等のようにバッファの各々に書き込むと共にバッファの各々から読み出すラウンドロビン（ｒｏｕｎｄ−ｒｏｂｉｎ）を介してもたらされ得る。代わりに、送信元−送信先経路よりも多くのバッファが存在する場合、アプリケーションは一つ又はそれより多くのバッファを“予備（ｉｎ  ｒｅｓｅｒｖｅ）”として保持するように構成され、トラフィックの突然のバーストのために高いレベルの書き込み誤り（ｗｒｉｔｅ−ｆａｉｌｕｒｅ）を特定の経路が受けるとき、必要に応じてこれらのバッファを動的に割り当て得る。本発明によってもたらされる利点を使用するためのこれら及び他の技術は当業者にとって明らかであろう。
【００３５】
本発明の基本原理は、たとえ複雑さにおけるわずかな増大がもたらされても、等しくないサイズのバッファを使用して具現化されてもよい。例えばバッファメモリ２００を三つのバッファに分割することを考える。メモリ２００ｃを四つのバッファに分割する例において、００、０１、１０、及び１１の組み合わせを使用してバッファインデックスするために二つのビットが必要とされる。これらの組み合わせの各々は、２００ｃのバッファＢ０、Ｂ１、Ｂ２、及びＢ３のうちの一つを一意的に識別する。三つのバッファもバッファインデックスするために二つのビットを必要とするが、上記で詳述のアルゴリズムを使用するとインデックスビット組み合わせの一つは使用されず、従って分割部の一つは使用のために利用可能となり得ない。
【００３６】
しかしながら代わりの実施例において、バッファインデックスが複数のビット組み合わせに対応し得る。すなわち例えばバッファＢ０はインデックスビット組み合わせ００に対応することが可能であり、バッファＢ１はインデックスビット組み合わせ０１に対応することが可能であり、バッファＢ２はビット組み合わせ１０又は１１の何れかに対応することが可能である。このようにバッファＢ０及びＢ１は各々、バッファメモリ２００の４分の１として割り当てられ、バッファＢ２は、バッファメモリ２００の半分として割り当てられるであろう。インデックスビット組み合わせのこのような複数の割り当ては、従来技術において一般的な“ｄｏｎ’ｔ  ｃａｒｅ（ドントケア）”ビットマスキング動作の導入を介して実現され得る。すなわち“ｄｏｎ’ｔ  ｃａｒｅ”ビットを識別するためにシンボル（記号）“−”を使用して、上記のインデックスビット割り当てが、Ｂ０＝００、Ｂ１＝０１、及びＢ２＝１−として特定される。この仕様を使用して、バッファインデックスをnext_addressの上位Ｎビットに記憶した上記ビット割り当て記述は、“ｄｏｎ’ｔ  ｃａｒｅ”ビットではなく、特定されたビットをただ置換するように修正される。８ビットのアドレス空き容量（０乃至７）を備えるバッファメモリの、１、２、３、又は４バッファへの分割を可能にするバッファ管理システムのハードウエア記述のための以下の例の擬似コードはこの技術を示している。
Address increment:
case (no. of buffers)
1: ptr[7:0]+1;
2: case (buffer index)
0:ptr0[7:0] <= {0,ptr0[6:0]+1};
1:ptr1[7:0] <= {1,ptr1[6:0]+1};
endcase
3: case (buffer index)
0:ptr0[7:0] <= {00,ptr0[5:0]+1};
1:ptr1[7:0] <= {01,ptr1[5:0]+1};
2:ptr2[7:0] <= {1, ptr2[6:0]+1};
endcase
4: case (buffer index)
0:ptr0[7:0] <= {00,ptr0[5:0]+1};
1:ptr1[7:0] <= {01,ptr1[5:0]+1};
2:ptr2[7:0] <= {10,ptr2[5:0]+1};
3:ptr3[7:0] <= {11,ptr3[5,0]+1};
endcase
endcase
【００３７】
この例の擬似コードにおいて、“<=”シンボルがシンボルの左のレジスタへのシンボルの右のコンテンツの転送を示しており、中括弧（ｃｕｒｌｅｄ  ｂｒａｃｋｅｔ）が、第一の引数（ａｒｇｕｍｅｎｔ）は最上位ビットが受信する値を示し、第二の引数は最下位ビットが受信する値を示すビット指向オペレーション（動作）（ｂｉｔ−ｏｒｉｅｎｔｅｄ  ｏｐｅｒａｔｉｏｎ）を示している。
【００３８】
上記擬似コードにおける三つのバッファの場合において、バッファＢ０（ｐｔｒ０）に対するポインタがインクリメントされているとき、ポインタの上位二つのビットは強制的に００にさせられ、バッファＢ１（ｐｔｒ１）に対するポインタがインクリメントされているとき、ポインタの上位二つのビットは強制的に０１にさせられるが、バッファＢ２（ｐｔｒ２）に対するポインタがインクリメントされているとき、ポインタの最上位ビットだけが強制的に１にさせられ、２番目の最上位ビットはビット指向オペレーションの２番目の引数によって制御される。すなわちバッファＢ２（ｐｔｒ２）に対するポインタの下位７ビット（ビット６からビット０まで）は通常の計数（カウント）サイクル（ｃｏｕｎｔｉｎｇ  ｃｙｃｌｅ）を通じて進行し、バッファＢ０（ｐｔｒ０）及びＢ１（ｐｔｒ１）に対するポインタの下位６ビット（ビット５からビット０まで）のみは通常の計数サイクルを通じて進行する。“ｄｏｎ’ｔ  ｃａｒｅ”インデックスビットの他の組み合わせは、等しくないバッファサイズをもたらすように容易に規定され得る。例えば（００−，０１−，１−０，１０１，１１１）の一組のインデックスは全バッファメモリ２００のサイズ（１／４，１／４，１／４，１／８，１／８）のバッファに対応する。
【００３９】
前述の記載は本発明の基本原理を示すのみである。従って当業者が、ここに明示的に記載又は開示されていないが、本発明の基本原理を具現化し、従って請求項の範囲内に入る様々な構成体を発明し得ることは評価されるであろう。  
【図面の簡単な説明】
【００４０】
【図１】本発明によるバッファ管理システムのブロック図の例を示す。
【図２】本発明による均一なサイズのバッファへのメモリ空き容量の分割例を示す。
【図３Ａ】本発明による分割バッファシステムにおける使用のためのバッファアドレッシング方式の構成例を示す。
【図３Ｂ】本発明による分割バッファシステムにおける使用のための他のバッファアドレッシング方式の構成例を示す。
【図４】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図５】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図６】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図７】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図８】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図９】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１０】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１１】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１２】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１３】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１４】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１５】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１６】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１７】本発明によるバッファ管理システムのブロック図の他の例を示す。
【図１】
2006510083.tif 000002
【図２】
2006510083.tif 000003
2006510083.tif 000004
【図４】
2006510083.tif 000005
【図５】
2006510083.tif 000006
【図６】
2006510083.tif 000007
【図７】
2006510083.tif 000008
【図８】
2006510083.tif 000009
【図９】
2006510083.tif 000010
【図１０】
2006510083.tif 000011
【図１１】
2006510083.tif 000012
【図１２】
2006510083.tif 000013
【図１３】
2006510083.tif 000014
【図１４】
2006510083.tif 000015
【図１５】
2006510083.tif 000016
【図１６】
2006510083.tif 000017
【図１７】
2006510083.tif 000018
【国際調査報告】
2006510083.tif 000019
2006510083.tif 000020
2006510083.tif 000021