JP4466653B2 - 複数のソースからコミュニケーションバスを介してデータを送信する方法および装置 - Google Patents

Description

本発明は、一般的に、パケットベースのコミュニケーションバス上でデータをアセンブルして送信する方法に関し、特に、複数のソースからのデータをアセンブルして（組み立てて）、コミュニケーションバス上に送信するように調節するための方法に関する。

図１に示したような典型的なコンピュータシステム 100 は、プロセッサ 102 、メモリコントローラ 104 、およびメインメモリストレージ 106 を含む。メインメモリストレージ 106 は、ダイナミックランダムアクセスメモリ（DRAM）のようなひとつもしくは複数のメモリチップを含む。

プロセッサ 102 がメインメモリストレージ 106 からデータを得るために、プロセッサ 102 は、データリクエストをコミュニケーションバス 108 を介してメモリコントローラ 104 へと送る。メモリコントローラ 104 は、そのリクエストを処理して再フォーマットして、ひとつもしくは複数の再フォーマットされたリクエストメッセージをメインメモリストレージバス 110 を介してメインメモリストレージ 106 へと送る。その後、メインメモリストレージ 106 はリクエストされたデータを、メインメモリストレージバス 110 を介してメモリコントローラ 104 へと返す。リクエストされたデータを受信した後に、メモリコントローラ 104 はデータをコミュニケーションバス 108 を介してプロセッサ 102 へと送る。

特定のリクエストに関連する情報およびデータのことを、「トランザクション」と呼ぶことがある。メモリコントローラ 104 は、複数のトランザクションを同時に処理することができる場合がある。これによって、複数のソース（例えば、メインメモリストレージ 106 内の複数のDRAM）からのデータがあるような状況において、メインメモリストレージ 106 からメインメモリストレージバス 110 を介して、メモリコントローラ 104 へと同時に返すことができる。こういうことが行われる際には、メモリコントローラ 104 は、メインメモリストレージバス 110 にアクセスが許可されるソース（例えばDRAM）を決定するための、アービトレーション処理を実行する。

アクセスが許可されると、メインメモリストレージ 106 は、トランザクションと関連するデータをメインメモリストレージバス 110 上に、トランザクションのサイズおよびメインメモリストレージバス 110 の幅（例えば、パラレルビットの数）に依る1以上のバスクロックサイクルに亘って配置する。例えば、トランザクションが52データビットを含み、バス幅が32ビットであるとすると、バス 110 上でデータを転送するためには2クロックサイクルが必要となる。単純化するためにヘッダ情報が含まれていないと仮定すると、初めの32ビットが第一クロックサイクルの間に転送され、終わりの20ビットが第二のクロックサイクルの間に転送されるということになる。

上述した例では、トランザクションのデータがメインメモリストレージバス 110 上で転送されている終わりのクロックサイクルの間には、バス 110 は完全には埋まっていない場合がある。この例においては、第二クロックサイクルの間には、使用可能な32ビットのうちの20ビットのみが埋まっていて、残りの12ビットは空のままとなる。現行のシステムにおいては、メインメモリストレージバス 110 が、別のソース（例えば、別のDRAM）にトランザクションの補完を許可する場合には、これらの12ビットは空のままであって、次のトランザクションのデータは次のクロックサイクルから始まるということになる。

この例では、従来技術を用いたときの、メインメモリストレージバス 110 上に固有に存在するギャップを説明している。これらのギャップによって、システムの遅延（レイテンシ）が増大してしまい、またバンド幅が減少してしまう。したがって、必要とされているのは、バス上で転送するための、複数のソースからデータをより効率的にアセンブルする方法および装置である。

或る実施形態においては、電子システムは、ひとつもしくは複数のメモリアクセスリクエストを生成して送信するプロセッサ、ならびに複数のメモリモジュールを含む。複数のメモリモジュールは、コミュニケーションバスを介して動作可能に互いに接続されていて、ひとつもしくは複数のメモリアクセスリクエスト中でリクエストされたデータを返す。複数のメモリモジュールのそれぞれはデータソースであって、また、複数のメモリモジュールのうちのひとつのメモリモジュールが、第一ソースデータおよび第二ソースデータが使用可能であることを判定する。また、データブロックの第一セクション内のひとつもしくは複数の第一連続レーン（contiguous lanes）が、第一ソースデータのうちの少なくとも一部に対して分配され、また、データブロックの第二セクション内のひとつもしくは複数の第二連続レーンが、第二ソースデータのうちの少なくとも一部に対して分配される。ここで、データブロックは複数のレーンのセットを含み、また、それぞれのレーンは複数の構成可能（コンフィギュラブル）なビットのセットを含む。第二セクションは、第一セクションに連続する次のレーンから始まる。また、メモリモジュールは、データブロック転送期間中に、データブロックの第一セクション内の第一ソースデータの少なくとも一部と、データブロックの第二セクション内の第二ソースデータの少なくとも一部との送信もコミュニケーションバスを介して行う。さらに、第一セクション内のひとつもしくは複数の第一連続レーンが分配される際、または、第二セクション内のひとつもしくは複数の第二連続レーンが分配される際、ブレイクポイントの位置が予測される。

さらなる実施形態においては、ローカルデータを格納するためのひとつもしくは複数のメモリストレージユニット、ならびに、ひとつもしくは複数のメモリストレージユニットとコミュニケーションバスとに動作可能に接続されたハブであって、他のひとつもしくは複数のハブからのダウンストリームデータを受信することができるようなハブ、がメモリモジュールに含まれる。ハブは、第一ソースデータおよび第二ソースデータが使用可能であることを判定する。ハブは、データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、第一ソースデータのうちの少なくとも一部に対して分配し、また、データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、第二ソースデータのうちの少なくとも一部に対して分配する。ここで、データブロックは複数のレーンのセットを含み、また、それぞれのレーンは複数の構成可能なビットのセットを含み、また、第二セクションは第一セクションに連続する次のレーンから始まる。また、ハブは、データブロック転送期間中に、データブロックの第一セクション内の第一ソースデータの少なくとも一部と、データブロックの第二セクション内の第二ソースデータの少なくとも一部とをコミュニケーションバスを介して送信することも行う。さらに、第一セクション内のひとつもしくは複数の第一連続レーンを分配する際、または、第二セクション内のひとつもしくは複数の第二連続レーンを分配する際、ブレイクポイントの位置を予測する。

さらなる実施形態においては、データのアセンブルおよび送信のための装置は、ひとつもしくは複数のメモリストレージユニットからのローカルデータを受信する手段、ひとつもしくは複数のダウンストリームデータソースからコミュニケーションバスを介してダウンストリームデータを受信するための手段、ならびに、ローカルデータおよびダウンストリームデータがコミュニケーションバスを介してどうやって送信されることになるのかを決定するための手段、を含む。データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、ローカルデータの少なくとも一部に分配するステップ、ならびに、データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、ダウンストリームデータの少なくとも一部に分配するステップが、上述の決定するステップに含まれる。ここで、データブロックは複数のレーンのセットを含み、また、それぞれのレーンは複数の構成可能なビットのセットを含み、また、第二セクションは第一セクションに連続する次のレーンから始まる。さらに、第一セクション内のひとつもしくは複数の第一連続レーンを分配する上記ステップ、または、第二セクション内のひとつもしくは複数の第二連続レーンを分配する上記ステップは、ブレイクポイントの位置を予測するステップを含んでいる。

さらなる実施形態においては、コミュニケーションバスを介してデータを送信するための装置は、第一データソースから第一ソースデータを受信するための手段、第二データソースから第二ソースデータを受信するための手段、ならびに、第一ソースデータおよび第二ソースデータをコミュニケーションバスを介して送信するための手段、を含む。第一ソースデータおよび第二ソースデータを送信するステップは、第一ソースデータをコミュニケーションバスを介して送信するステップ、第一ソースデータの末尾に対応する第一ブレイクポイントを識別するステップ、第一ソースデータの末尾に連続するような第二ソースデータをコミュニケーションバスを介して送信するステップ、ならびに、第二ソースデータの末尾に対応する第二ブレイクポイントを識別するステップ、を含む。ここで、第一ブレイクポイントは、コミュニケーションバスへのアクセスを許可する際に生成された予測位置と一致し、また、第二ブレイクポイントは、コミュニケーションバスへのアクセスを許可する際に生成された予測位置と一致する。

さらなる実施形態においては、コミュニケーションバス上でデータを送信するための方法は、第一処理期間中に、第一ソースデータの第一部分をデータブロック構造内に配置するステップ、ならびに、第一ソースデータの第一部分をコミュニケーションバスを介して送信するステップ、を含む。ここで、データブロック構造は、一定数の連続的且つ構成可能なビットを含む。この方法は、さらに、第二処理期間中に、第一ソースデータの残余部分を、データブロック構造の第一セクション内に配置するステップ、第二処理期間中に、第二ソースデータの第一部分をデータブロック構造の第二セクション内に配置するステップ、ならびに、第一ソースデータの残余部分と第二ソースデータの第一部分とを送信するステップ、を含む。ここで、第一セクションは、連続するビットの第一セットを含み、第二セクションは、連続するビットの第二セットを含み、また、第二セクションは第一セクションに連続するものである。さらに、第一ソースデータの第一部分を配置する上記ステップ、および、第一ソースデータの残余部分を配置する上記ステップは、ブレイクポイントの位置を予測するステップを含む。

さらなる実施形態においては、本方法は、第一ソースデータおよび第二ソースデータが使用可能であることを判定するステップ、ならびに、データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、第一ソースデータの少なくとも一部に対して分配するステップを含み、ここで、データブロックは複数のレーンのセットを含み、また、それぞれのレーンは構成可能なビットのセットを含む。この方法は、さらに、データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、第二ソースデータの少なくとも一部に対して分配するステップ、ならびに、データブロック転送期間中に、データブロックの第一セクション内の第一ソースデータの少なくとも一部と、データブロックの第二セクション内の第二ソースデータの少なくとも一部とを、コミュニケーションバスを介して送信するステップ、を含む。ここで、第二セクションは、第一セクションに連続する次のレーンから始まるものである。また、第一セクション内のひとつもしくは複数の第一連続レーンを分配する上記ステップ、または、第二セクション内のひとつもしくは複数の第二連続レーンを分配する上記ステップは、ブレイクポイントの位置を予測するステップを含む。

さらなる実施形態においては、本方法は、第一ソースからの第一ソースデータを、データブロック構造の第一セクション内に配置するステップを含み、ここで、データブロック構造は、一定数の連続的且つ構成可能なビットを含み、また、データブロック構造内部のデータは、コミュニケーションバス上に周期的に送出される。この方法は、さらに、第二ソースからの第二ソースデータが、コミュニケーションバスを介して送信可能であるかを決定するステップ、ならびに、第二ソースデータを送信するために、コミュニケーションバスへのアクセスをリクエストするステップ、を含む。この方法は、さらに、データブロック構造内のどこに、第二ソースデータの少なくとも一部を収めるべきかについての指標を受信するステップ、第二ソースデータの少なくとも一部を、上記指標に従って、データブロック構造内に配置して、第二ソースデータの少なくとも一部が、第一セクションの末尾に連続するデータブロックの第二セクションを占有するようにするステップ、ならびに、データブロック転送期間中に、第一ソースデータ、および第二ソースデータの少なくとも一部を、コミュニケーションバスを介して送信するステップ、を含む。さらに、第一ソースデータを第一セクション内に配置する上記ステップ、または、第二ソースデータの少なくとも一部を配置する上記ステップは、ブレイクポイントの位置を予測するステップを含む。
さらなる実施形態においては、本方法は、データブロック構造の第一セクション内に、第一ソースデータを配置するステップを含み、ここで、データブロック構造は、一定数の連続的且つ構成可能なビットを含む。この方法は、さらに、第二ソースデータの送信リクエストをコミュニケーションバスを介して受信するステップ、第一ソースデータ内のブレイクポイントの位置を識別するステップ、ならびに、ブレイクポイントの後のデータブロック構造の第二セクション内に、第二ソースデータの少なくとも一部を配置するステップ、を含み、ここで、第二セクションは、第一セクションの末尾に連続している。この方法は、さらに、データブロック転送期間中に、第一ソースデータ、および第二ソースデータの少なくとも一部を、コミュニケーションバスを介して送信するステップを含む。また、第一ソースデータを配置する上記ステップ、および、第二ソースデータの少なくとも一部を配置する上記ステップは、ブレイクポイントの位置を予測するステップを含む。

以下の実施形態の記載においては、明細書の一部であって本発明を実施することができる特定の実施形態を図示している添付図面を参照する。これらの実施形態については、当業者が本発明を実施するに足る詳細な記載をしており、また、本発明の範囲を逸脱しない範囲で、他の実施形態を利用できるということと、処理的変更もしくは機構的変更を行うことができるということとを理解されたい。実施においては、さまざまな実施形態の方法を、同時にもしくは連続的に、組み合わせることができるということに留意されたい。さまざまな交換および組み合わせは、当業者にとっては至極明白である。

本明細書で詳述する本発明の種々の実施形態は、データのアセンブルおよび送信のための新規且つ未踏の方法ならびに装置を含んでいる。本発明の実施形態は、従来技術に係る方法を凌ぐだけの充分な利点をいくつか有している。特に、本発明の実施形態は、複数のソースからのデータをひとつもしくは複数のリクエスタ （ requesters ） に返す必要があるようなメモリシステムにおいて実行される際に、システム遅延の低減と、バンド幅の増大とを提供する。

図２は、本発明の実施形態に係る、コンピュータシステム 200 の単純化されたブロック図である。或る実施形態においては、システム 200 は、ひとつもしくは複数のプロセッサ 202 、リンクコントローラ 206 、ならびにひとつもしくは複数のメモリモジュール 208〜211 を含む。記載を簡単にするために、ひとつのプロセッサ 202 およびリンクコントローラ 206 のみを図示して説明する。しかしながら、複数のプロセッサ 202 および／もしくは複数のリンクコントローラ 206 が、システム内部に存在するようにすることもできる。同様に、四つのメモリモジュール 208〜211 を図示しているが、これよりも多いもしくは少ないメモリモジュールが、システム内部に存在するようにすることもできる。

或る実施形態においては、メモリモジュール 208〜211 のそれぞれは、挿入可能な回路基板などの別々の基板上に設置される。他の実施形態においては、複数のメモリモジュールを、単独の基板上に設置することができ、および／もしくは、メモリモジュールの一部を複数の基板に亘って分けることもできる。本発明の実施形態に係るメモリモジュールについては、図３と関連させてさらに詳しく後述する。

プロセッサ 202 は、ひとつもしくは複数のメモリモジュール 208〜211 内部に格納された情報にアクセスするためのリクエストを生成し送信することがある。これらの「メモリアクセスリクエスト」には、メモリモジュール 208〜211 内部にデータを格納するリクエスト、さらには、ひとつもしくは複数のメモリモジュール 208〜211 からデータを検索するリクエストが含まれる。或る実施形態では、プロセッサ 202 に加えて、ひとつもしくは複数の他のリクエスタ 204 がシステム 200 内に存在するようにすることができる。例えば、システム 200 は、ひとつもしくは複数の他のプロセッサ、インターフェイス、ポート、アダプター、もしくは、データをリクエストできるような他のエンティティを含むことができる。本明細書においては、プロセッサ 202 ならびにひとつもしくは複数の他のリクエスタ 204 のことを、「リクエストオリジネータ」 （ "request originators" ） と称する。

リクエストオリジネータ202, 204 からのアクセスリクエストを受信するリンクコントローラ 206 は、それぞれのアクセスリクエストを初期処理する。例えば、限定をするものでは無いが、リンクコントローラ 206 は、ノースブリッジ、もしくは他のタイプの処理要素とすることができる。リンクコントローラ 206 は、リクエストの内容に基づいて、ひとつもしくは複数の「メモリアクセスコマンド」を生成し、コミュニケーションバス 220 （本明細書では「リンクバス」 （ "link bus" ） と呼ぶ）を介してひとつもしくは複数のメモリモジュール 208〜211 へと送信することができる。メモリアクセスリクエストが（格納とは反対に）データを検索する（取り出す）ことを求める場合、メモリモジュール 208〜211 はリクエストされたデータをリンクバス 220 を介してリンクコントローラ 206 へと返し、リンクコントローラ 206 はリクエストオリジネータ 202, 204 へと返すようにリクエストされたデータを発送する。

或る実施形態においては、メモリモジュール 208〜211 は、「トンネル」構成もしくは「デイジーチェイン」構成として、リンクバス 220 を介して動作可能に互いに接続される。この構成においては、リンクコントローラ 206 は、リンクバスを介して第一メモリモジュール 208 と相互接続される。したがって、リンクバス 220 の第一部分 222 は、リンクコントローラ 206 および第一メモリモジュール 208 と相互接続される。同様に、第一メモリモジュール 208 は、リンクバスを介して第二メモリモジュール 209 と相互接続される。そこで、リンクバス 220 の第二部分 224 は、第一メモリモジュール 208 、第二メモリモジュール 209 、等々に相互接続することになる。

或る実施形態においては、リンクバス 220 はパラレルバスである。例えば、限定をするものでは無いが、リンクバス 220 は32ビット幅である。他の実施形態においては、リンクバス 220 は32ビットよりも広くすることも、もしくは狭くすることもでき、または、リンクバス 220 をシリアルバスとすることもできる。

「ダウンストリーム（下流）」および「アップストリーム（上流）」という語を、以降の本記載において用いてゆく。最下部のメモリモジュール 211 は、リンクバス 220 のダウンストリームの最下端に存在し、また、リンクコントローラ 206 は、リンクバス 220 のアップストリームの最上端に存在する。したがって、最後（最下位）のメモリモジュール 211 の方向から、メモリモジュールが受信したデータおよび情報のことを、ダウンストリーム方向から受信した情報と見做す。対照的に、リンクコントローラ 206 の方向から、メモリモジュールが受信したデータおよび情報のことを、アップストリーム方向から受信した情報と見做す。同様の術語を用いると、メモリモジュール 211 はメモリモジュール 210 から見てダウンストリームに在ると見做せ、また、メモリモジュール 210, 211 はメモリモジュール 209 から見てダウンストリームに在ると見做せ、また、メモリモジュール 209〜211 はメモリモジュール208 から見てダウンストリームに在ると見做せる。

メモリモジュール208〜210 （最下位メモリモジュール211を除く）のそれぞれは、いずれかのダウンストリームメモリモジュールとトンネル接続をしている。所望であれば、追加のメモリモジュール（図示せず）をメモリモジュール 211 のダウンストリームに追加することができ、また、追加のメモリモジュールをトンネルの任意の点に挿入することもできる（例えば、存在しているひとつもしくは複数のメモリモジュールの、間もしくは上）。

或る実施形態においては、メモリモジュール 208〜210 のそれぞれは、各メモリモジュールが受信したメモリアクセスコマンドを、コマンドの宛先（例えば、コマンドが指定されているメモリモジュール）には拘らず、自身の次のダウンストリームメモリモジュールへと通過させる。別の実施形態においては、メモリモジュール 208〜210 のそれぞれは、受信したメモリアクセスコマンドを、自身がコマンドの宛先で無い場合にのみ、ダウンストリーム方向へと通過させる。

ダウンストリーム方向から受信される任意のタイプの情報のことを、本明細書では「ダウンストリームデータ」と呼び、メモリから検索されるデータ、ヘッダーおよび他のプロトコル情報、ならびに、ダウンストリームメモリモジュールから受信される他の任意のタイプの情報、を含む。同様に、本明細書では、「アップストリームデータ」という語をアップストリーム方向から受信された任意のタイプの情報の意味で用い、また、「アップストリームデータ」には、メモリアクセスコマンド、格納されるべきデータ、ヘッダー、および他のプロトコル情報、が含まれる。「データ」という語を使用する場合、格納もしくは検索されるような実際のデータのみには限定されない。この語は、ヘッダー、他のプロトコル情報、コマンド、および他のタイプの情報をも含む。

図３は、本発明の実施形態に係るメモリモジュール 300 の単純化されたブロック図である。或る実施形態においては、メモリモジュール 300 のそれぞれは、ハブ 302 、ならびにひとつもしくは複数のメモリストレージユニット 304 を含む。本発明の実施形態に係るハブについては、図４と関連させてさらに詳しく後述する。

或る実施形態においては、ハブ 302 およびメモリストレージユニット 304 は、コミュニケーションバスにリムーバブルに接続できるような単独の基板（例えばプリント回路基板）上に共に設置される。他の実施形態においては、ハブ 302 およびひとつもしくは複数のメモリストレージユニット 304 を、別々の基板上に設置することができ、ならびに／または、基板をバスに恒久的に接続してしまうこともできる。いずれにしても、ハブ 302 のそれぞれは、ハブに関連し、またハブが排他的にアクセスすることができるようなメモリストレージユニット 304 のセットを有する。したがって、メモリモジュール 300 のそれぞれは、「データソース」と見做すことができる。

メモリストレージユニット 304 は、（図示しているように）コモンリンク、 point-to-point 接続、デイジーチェインリンク、もしくは、他の手段、を介して、ハブ 302 と接続することができる。或る実施形態においては、メモリストレージユニット 304 のそれぞれは、例えばダイナミックランダムアクセスメモリ（DRAM）デバイスのような特徴的なメモリコンポーネントとなる。他の実施形態においては、メモリストレージユニット 304 は、他のタイプのメモリデバイス（例えば、リードオンリーメモリ（例えば、ROM、PROM、EEPROM等）、フラッシュメモリ、または他のタイプのメモリ）を含むことができる。図３には、四つのメモリストレージユニット 304 を示しているが、それよりも多いもしくは少ないユニット 304 を、任意のメモリモジュール 300 内に含めることもできる。

ハブ 302 は、或る実施形態において、ひとつもしくは複数の特定用途向け集積回路 （ application-specific integrated circuits; ASICs ） を含む。別の実施形態においては、ハブ 302 は、ひとつもしくは複数の汎用プロセッサもしくは特定用途プロセッサを含む。ハブ302 は、アップストリームリンクバス 310 を介して、アップストリームメモリモジュール 208 （図２）もしくはリンクコントローラ 206 と通信する。加えて、ダウンストリームメモリモジュールが存在する場合、ハブ 302 は、ダウンストリームリンクバス 312 を介してダウンストリームメモリモジュールと通信する。したがって、ハブ 302 は、バス（即ち、ダウンストリームリンクバス 312 ）の第一部位上にあるダウンストリームメモリモジュールからのデータを受信して、バス（即ち、アップストリームリンクバス 310 ）の第二部位上にあるリンクコントローラ 206 へとデータを送信する。

或る実施形態においては、ハブ 302 がアップストリームリンクバス 310 上のメモリアクセスコマンドを受信した際に、ハブ 302 がそのコマンドをダウンストリームリンクバス 312 へと再転送して、そのコマンドに関する情報をコマンドキューに格納する（後述する図４の要素 412 を見よ）。また、ハブ 302 は、メモリストレージユニットがコマンドの宛先であるかどうかの判定も行う。そうであった場合には、ハブ 302 は、メモリモジュール 300 に関連するメモリストレージユニット 304 へのアクセスにおいて、何が必要であるかを決定して、リクエストされたデータをアップストリームリンクバス 310 上へと送信する。加えて、ハブ 302 は、ダウンストリームメモリモジュール（図示せず）からのダウンストリームリンクバス 312 上のデータを受信し、さらにハブ 302 はそのデータをアップストリームリンクバス 310 上へと再転送する。

前のパラグラフで示唆したように、ハブ 302 は少なくとも二つのソースからのデータ、即ち a）メモリストレージユニット 304 からのデータ、および b） ダウンストリームメモリモジュールからのデータ、を受信する。ハブ 302 に関連するメモリストレージユニット 304 から、ハブ 302 によって検索されたデータのことを、本明細書では「ローカルデータ」と呼ぶ。一方、ダウンストリームリンクバス 312 上のひとつもしくは複数のダウンストリームメモリモジュールから受信したデータのことを、本明細書では「ダウンストリームデータ」と呼ぶ。「ローカルデータ」および「ダウンストリームデータ」という語は、システム内部にデータソースが二つだけ存在するような意味にも取れるが、この語はこのような限定をするものでは無い。ひとつもしくは複数の他のソース（例えば、ひとつもしくは複数のダウンストリームメモリモジュール、または他のソース）から、データを生成することができる。

ハブ 302 によって得られる重要な機能は、ローカルデータとダウンストリームデータとの双方を受信し、この両者をアップストリームリンクバス 310 へと与えるということである。或る実施形態においては、ハブ 302 はローカルデータおよびダウンストリームデータを受信して、アップストリームリンクバス 310 上の使用可能なリソースを効率的に使用することができるような方法で、アップストリームリンクバス 310 上にデータを送信する。特に、データは、ダウンストリームデータもしくはローカルデータを返すことができる状態であっても、バス上で重大なデータ「ギャップ」が発生しないように、マージされて送信される。ここで、「ギャップ」には、リンクバスを介して送信されているような、有意なデータを含んでいないひとつもしくは複数のビット、が含まれている。この手法の実施については、図４〜８に示される実施形態と関連させて後に詳述する。

図４は、本発明の実施形態に係るハブ 400 の単純化された機能ブロック図である。或る実施形態においては、ハブ 400 はさまざまな機能要素を含んでおり、これらを図４に別個のブロックとして描いて図示した。さまざまな実施形態においては、実際の論理素子と、各々の機能要素に関連するハードウェアとを、単独のASIC内に常駐させることができ、または、複数のASCIおよび／もしくは他の別個のデバイス内に常駐させることもできる。さらには、図４に示した機能要素のさまざまな特徴は、ハードウェア、ソフトウェア、もしくはその双方において実行することができる。

つまり、或る実施形態においては、ハブ 400 はローカルデータおよびダウンストリームデータを受信し、二つのソースからのこれらのデータを共にマージする方法を決定して、マージしたデータをアップストリームリンクバス 452 へと与える。ハブ 400 の機能部品については、次のパラグラフにおいて、或る特定の実施形態と関連させて要約して後述する。他の実施形態、および付加的な詳細についての説明は、以降の記載に含める。

ハブ 400 は、必要であれば、ローカルデータバッファ410 およびダウンストリームデータバッファ 420 を含み、これらはそれぞれ、ローカルデータおよびダウンストリームデータを受信して格納するための手段である。また、ハブ 400 は、ローカルアービトレーション論理手段 414 、ダウンストリームアービトレーション論理手段 422 、およびソース間アービトレーション手段 416 も含み、これらは協働的に、ローカルデータおよびダウンストリームデータをアップストリームリンクバス 452 へと送信するための方法を決定する。また、ハブ 400 は、ローカル出力配置手段 430 、ダウンストリーム出力配置手段 432 、およびデータアセンブリ手段 450 も含み、これらは、アービトレーション手段 414, 416, 422 による決定に従って、ローカルデータおよびダウンストリームデータをデータブロック構造へと配置する機能を担う。データブロック構造は、バッファ 440, 442 によって表される。データブロック構造へと編成されたデータは、アップストリームリンクバス 452 上に連続的に送信される。加えて、ハブ 400 はコマンドキュー 412 を含み、ハブは、受信したメモリアクセスコマンドに関係する情報をコマンドキュー412 内に格納する。

データブロック構造について、さらに詳述する。データブロック構造（ここでは単に「データブロック」とも呼ぶ）は、或る実施形態においては、一定数の構成可能なビットを含む。例えば、或る実施形態においては、データブロックは256ビットを含む。別の実施形態においては、データブロック内部に、さらに多いビットもしくはさらに少ないビットを含めることができる。データがアップストリームリンクバス 452 上に送信された際には、データブロック構造のビットは、データによって適切に構成され（例えば、 "1" もしくは "0" で埋めるようにする）、データブロック転送期間（即ち、後述するようなひとつもしくは複数のバスクロックサイクル）中に、データはバス上にクロック出力される （ is clocked out ） 。

或る実施形態においては、データブロックは、整数個の連続する「レーン」に分割され、それぞれのレーンは構成可能なビットのセットを含んでいる。例えば、或る実施形態においては、データブロックは8個のレーンのセットを含む。データブロック構造内のレーンの数は固定され、それぞれのレーンは等しい数のビットを含む。他の実施形態においては、レーンの数が可変とすることができ、および／もしくは、レーンあたりのビットの数がレーン毎に異なるようにすることもできる。レーン構造は、図４のバッファ 440, 442 として表現されている。バッファ 440, 442 のそれぞれは、 "0" 〜 "7" とラベルされた8レーンのデータブロックで表現されている。実施においては、バッファ 440, 442 は別々のバッファとすることもでき、または、同一のバッファとすることもできる。簡単のため、図４ではバッファ 440, 442 は別々に表現している。

256ビットデータブロックであり、ブロックあたり8レーンであるような例を用いると、各レーンは32ビットを含むことになる。したがって、レーン 0 にはビット 0〜31 を割り当て、レーン 1 にはビット 32〜63 を割り当て、レーン 2 にはビット 64〜95 を割り当てて、と同様に行っていき、レーン 7 にはビット 224〜255 が割り当てられるようにすることができる。別の実施形態においては、データブロック内部にはより多いレーン、もしくはより少ないレーンを設置することができる。例えば、データブロックがレーンを二つだけ含むようにすることができる。さらなる別の実施形態においては、レーン 0 が最上位ビットを含み、レーン 7 は最下位ビットを含むようにすることもでき、もしくはその逆の構成も可能であり、あるいは、ビットを非連続的に各レーンに分配することもできる。

さらに詳しく後述するように、さまざまな実施形態のレーン構造によって、ローカルソースとダウンストリームソースの双方からのデータが使用可能となった場合に、ハブ 400 が、データをアップストリームリンクバス 452 を介して効率的に送信できるようになる。ハブ 400 は、いくつかの基礎処理を行う。まず、第一ソースおよび第二ソース（例えば、ローカルソースおよびダウンストリームソース、またはその逆）からのデータを受信して使用可能となったことを、ハブが判定する。二番目に、アービトレーション処理を行って、任意の特定のデータブロック転送期間中に、アップストリームリンクバスにアクセスを許可するデータを決定する。三番目に、レーン埋め処理 （ a lane filling process ） を行い、特定のデータブロック転送期間中にどのデータを用いてどのレーンを利用するのかを識別する。レーン埋め処理には、データブロックの第一セクション内部のひとつもしくは複数の第一連続レーンを、少なくともいくつかの第一ソースデータに分配するステップと、データブロックの第二セクション内部のひとつもしくは複数の第二連続レーンを、少なくともいくつかの第二ソースデータに分配するステップとを含み、ここで、第二セクションは、第一セクションに連続する次のレーンから始まるものである。最後に、データブロック転送期間中に、第一ソースデータの一部と、第二ソースデータの一部とを、コミュニケーションバスを介して送信する。

図４を再度参照すると、ダウンストリームデータは、ダウンストリームリンクバス 454 から受信される。或る実施形態においては、ダウンストリームデータは、ダウンストリームデータバッファ 420 内に収められるか、もしくはダウンストリームフライスルーパス 472 の経路を採る。同様に、ローカルデータは、メモリストレージユニット 402 （例えば、図３のユニット 304 ）から受信される。或る実施形態においては、ローカルデータは、ローカルデータバッファ 410 内に収められるか、もしくはローカルフライスルーパス 470 の経路を採る。

或る実施形態においては、ダウンストリームデータバッファ 420 もしくはローカルデータバッファ 410 内に、未だ送信されていないダウンストリームデータもしくはローカルデータが残留していない場合、ならびに、ひとつのソースのみからのデータしかアップストリームリンクバス 452 で競合しない場合に、ダウンストリームフライスルーパス 472 およびローカルフライスルーパス 470 を用いる。このような状況では、リクエスタへのデータの戻りを促すために、バスは、いずれか一方のソースからのデータを単純に許可する。他の実施形態においては、フライスルーパス 470, 472 の一方もしくは双方をシステムから除くことができ、この場合、ローカルデータおよびダウンストリームデータは、バッファ 410, 420 の状態にかかわらず、バッファされる。

さまざまな実施形態におけるレーン-パッキング技術 （ lane-packing techniques ） について完全に記載するために、以降の記載では、複数のソースがバスに関して競合し、また、ローカルデータおよびダウンストリームデータは、フライスルーパス 470, 472 への迂回よりも、ローカルデータバッファ 410 および／もしくはダウンストリームデータバッファ 420 にそれぞれ一時的に格納されることを優先するものと仮定する。したがって、以降の記載の大部分においては、複数のソースからのデータが使用可能であると仮定し、また、アップストリームリンクバス 452 へのアクセスを巡って複数のソースが競合するとも仮定する。

ダウンストリームデータがダウンストリームリンクバス 454 から受信されると、ダウンストリームデータストローブシグナル 408 がダウンストリームアービトレーション論理手段 422 へと送信される。ダウンストリームデータが、ダウンストリームデータバッファ 420 内に収められると仮定すると、ダウンストリームバッファステータスシグナル 467 が、ダウンストリームデータバッファが空では無いことを報せることになる。バッファが空では無い場合、ダウンストリームフライスルーパス 472 は使用されない。

ダウンストリームアービトレーション論理手段 422 は、バスアクセスリクエストを生成するための手段を含む。データストローブシグナル 408 およびバッファステータスシグナル 467 は、ダウンストリームデータをアップストリームリンクバス 452 を介して送信可能であるということを報せ、ダウンストリームアービトレーション論理手段 422 が、ダウンストリームリクエストシグナル 461 をソース間アービトレーション手段 416 へと送信する。ダウンストリームリクエストは、ダウンストリームアービトレーション論理手段 422 がダウンストリームデータをアップストリームリンクバス 452 へと与えてよいかということを、ソース間アービトレーション手段 416 に問い合わせる。

同様に、ローカルデータの側では、ローカルデータがメモリストレージユニット 402から受信されると、ローカルデータストローブシグナル 404 がローカルアービトレーション論理手段 414 へと送信される。ローカルデータが、ローカルデータバッファ 410 内に収められると仮定すると、ローカルバッファステータスシグナル 477 が、ローカルデータバッファが空では無いことを報せることになる。バッファが空では無い場合、ローカルフライスルーパス 470 は使用されない。

ローカルアービトレーション論理手段 414 は、バスアクセスリクエストを生成するための手段を含む。データストローブシグナル 404 およびバッファステータスシグナル 477 は、ローカルデータをアップストリームリンクバス 452 を介して送信可能であるということを報せ、ローカルアービトレーション論理手段414 が、ローカルリクエストシグナル 471 をソース間アービトレーション手段 416 へと送信する。前述したダウンストリーム側と同様に、ローカルリクエストは、ソース間アービトレーション手段 416 に、ローカルアービトレーション論理手段 414 がダウンストリームデータをアップストリームリンクバス 452 へと与えることを要求する。

したがって、或る実施形態においては、ソース間アービトレーション手段 416 は、リクエスト 471, 461 を受信して、ローカルアービトレーション論理手段 414 とダウンストリームアービトレーション論理手段 422 との双方からバスへとアクセスする。ローカルデータおよびダウンストリームデータをバスを介して送信するための方法の決定を行うための手段を、ソース間アービトレーション手段 416 は含む。したがって、複数のリクエストが未決となっている場合には、手段 416 はアービトレーション処理を行い、ローカルデータもしくはダウンストリームデータへのアクセスを許可する。

ローカルアービトレーション論理手段 414 もしくはダウンストリームアービトレーション論理手段 422 のいずれも、バスへのアクセスが許可される迄はデータを送信することは無い。加えて、ソース間アービトレーション手段 416 は、或るソースから別のソースへの許可の切り換えを決定し、次のソースがそのデータをレーン構造内のどこで開始するべきかを、ソース間アービトレーション手段 416 が決定して指示する。ソース間アービトレーション手段 416 は、この決定を行うにあたって、ダウンストリームアービトレーション論理手段 422 およびローカルアービトレーション論理手段 414 からのさまざまな情報を使用する。

特に、或る実施形態においては、バスへのアクセスが許可されたソースが、そのデータ内のどこに「ブレイクポイント」が発生するかを予測し、ソース間アービトレーション手段 416 に予測したブレイクポイントの位置を伝える。その後、ソース間アービトレーション手段 416 は、予測した位置を用いて、次に許可されたソースがレーン構造内のどこにそのデータを挿入して開始することができるかを決定する。

実施例によって、このコンセプトを明瞭にする。実施例では、本発明の実施形態に係るタイミング図を示す図５も参照してゆく。まず、内部クロックシグナル 502 とレーンデータシグナル 508〜515 だけについて論じる。図５の他のシグナルについては、さらに後述する。

シグナル 502 は、内部クロックシグナルを示している。内部クロックシグナルは、それぞれのデータブロックをアセンブルする「処理期間」を定義するために用いられる。処理期間とは、単独のデータブロックをアセンブルするための時間の期間のことである。図５では、処理期間が1内部クロックサイクル長であるとしているが、処理期間を1内部クロックサイクルよりも長くすることも短くすることもできる。

この実施例においては、データブロックは8レーンを含み、また、レーン内の使用可能な有意なデータのことをレーンデータシグナル 508〜515 と称する。第一処理期間 540 において、データブロック構造のレーン 508〜515 内にデータを挿入する。データがアセンブルされると、バスがデータを使用できるようになる。次の処理期間 542 において、別のデータがデータブロック構造のレーン 508〜515 内に挿入された後に、バスがデータを使用できるようになる。

さらに、内部クロックの種々のエッジ（即ち、立ち上がりエッジおよび立ち下がりエッジ）と、データおよび他のシグナルとの間の相関について、図５に或る特定の手法で示しているが、他の実施形態においてはこの相関を異なるものにすることもできる。例えば、クロックシグナルを、他のシグナルに関して逆転させることもできる。他の変形についても同様に実行することができる。

或る実施形態においては、特定のメモリアクセスリクエストのことを「トランザクション」と見做し、返されたデータを識別するために、トランザクション識別子をリクエストに関連づける。トランザクションは、実質的に任意の長さとすることができる。例えば、トランザクションを単独のビットのみの短さにすることも、もしくは数百万ビットの長さとすることもできる。或る実施形態においては、トランザクションと関連づけられたデータは、「データフラグメント」のセットとして返され、ここで各フラグメントはレーンの幅に対応する数のビットを含んでいる。例えば、トランザクションが256ビットを含み、各レーンが32ビット幅である場合には、トランザクションを8個のデータフラグメントに分割することができる。トランザクションにおいて、データの識別のために、データにヘッダーを付与して送信することができる。ヘッダーは任意の長さとすることができる。後述する実施形態においては、ヘッダーはひとつのレーン以上を占めることは無い。他の実施形態においては、ヘッダーはひとつ以上のレーンを占めるか、もしくは、ヘッダーがそれぞれのトランザクションに応じて返されないようなプロトコルを用いる。

図５に示した実施例においては、処理期間 540 中に、レーン"0" 508 に収められて転送されている第一データはヘッダー 550 を含み、また、七個のローカルデータのフラグメントから成るローカルデータの第一部分を、レーン "1〜7" 509〜515 とする。それぞれのデータを示す囲みに含まれている記号は、以下のような意味である。即ち、 "L" はローカルデータ、 "R" はダウンストリーム（リモート）データ、 "T*" はトランザクション番号、 "D*" はトランザクションのためのデータフラグメント番号を意味する。したがって、処理期間 540 中のレーン "1" 509 内の識別子 "L_T0_D0" は、レーン "1" 内部のデータが、 "0" によって識別されたローカルトランザクション（T0）におけるローカルデータ（L）の第一フラグメント（D0）に相当する、ということを意味する。同様に、処理期間 544 中のレーン "1" 509 内の識別子 "R_T0_D7" は、データが、 "0" によって識別されたダウンストリームトランザクション（T0）におけるダウンストリームデータ（R）の第八フラグメント（D7）に相当する、ということを意味する。

第一処理期間 540 中に、ローカルソースからのデータがレーン構造内に存在しているので、ソース間アービトレーション手段（図４の 416 ）が、事前にバスにローカルソースへのアクセスを許可していると見做せる。図示した例においては、ローカルソースは、第一許可 （ the first grant ） が出ている間に送信する八個のデータフラグメントを有する。第一処理期間 540 中に、ヘッダー 550 がレーン "0" 508 を占めるため、その八個のデータフラグメントのうちの七個だけを第一処理期間 540 中にアセンブルすることができる。 "L_T0_D7" と記号を振られたローカルソースデータの残余部分は、第二処理期間 542 中にレーン "0" に在ることが示されている。

第八フラグメント"L_T0_D7" の末尾は、ローカルソースデータの「ブレイクポイント」となる。このブレイクポイントは、第二処理期間 542 のレーン "1" 509 の端緒と符合する。或る実施形態においては、ローカルソースもしくはダウンストリームソースからのデータを、第二処理期間 542 中に残留しているレーン "1〜7" を埋めるために使うことができる。

本実施例においては、ソース間アービトレーション手段（図４の 416 ）が、次に、ダウンストリームソース（R）にアクセスを許可している。特に、ダウンストリームソースは、ヘッダー、および、その第一トランザクション（T0）中に送信するための十六個のデータフラグメント（D0〜D15）を有する。ブレイクポイントは、第二処理期間 542 のレーン "1" 509 の端緒に生じるため、ヘッダーはそこに位置することになる。第二処理期間 542 のレーン "2" 510 内の指標 "R_T0_D0" から、第四処理期間 546 のレーン "1" 509 内の指標 "R_T0_D15" によって示されるように、十六個のデータフラグメントがフローする。特に、第二処理期間 542 のレーン 2〜7 には、十六個のデータフラグメントのうちの六個（ R_T0_D0 〜 R_T0_D5 ）が入っている。したがって、第二処理期間 542 中には、第一ソースからのデータの残余部分が、データブロック構造の第一セクション内に収められ、また、第二ソースからのデータの一部が、データブロック構造の第二セクション内に収められる。

第三処理期間 544 は、そのすべてが R_T0 トランザクションによって占められており、この期間内にはブレイクポイントは生じない。ダウンストリームトランザクションのブレイクポイントは、第四処理期間 546 のレーン "2" 510 の端緒までは生じない。ダウンストリームトランザクションのブレイクポイントの後に、ヘッダと、第二ローカルトランザクション（"T1"）に関する十個のローカルデータフラグメントのうちの最初の五個とが、第四処理期間 546 および第五処理期間 548 中にアセンブルされることになる。

図５に示しているように、複数のソースからのデータは、レーン内に収められて、特定のデータブロック転送期間中に送信される。これは特に、処理期間 542 および 546 の中において示されていることである。或る実施形態においては、第一ソースからのデータ（例えば、ローカルデータもしくはダウンストリームデータ）が、すべてのレーンを占めないような場合には、第二ソースからのデータ（例えば、ダウンストリームデータもしくはローカルデータ）を、使用されていない余ったレーンに収めることができる。このようにして、単独のデータブロック転送期間中に、第一ソースデータと第二ソースデータの双方を、アップストリームリンクバス上に送信することができる。換言すると、第一ソースデータがデータブロックの第一セクションに収められ、第二ソースデータがデータブロックの第二セクションに収められるということであって、ここで、第二セクションは、第一セクションと連続する次のレーンから始まるものである。本発明の実施形態に係る、複数のソースからのデータを、同一のデータブロック内に収めるというこの手法によって、データの戻りに関する遅延を低減することができ、また、リンクバスのバンド幅の利用を増大することができる。

図４に示した実施形態に係る操作について、図５に示した実施例と関連させてさらに詳述する。第一処理期間 540 中において、第一ローカルトランザクション（"L_T0"）に関連するローカルデータは、ローカルデータシグナル 504 の状態に依り、利用可能な状態にあるということが示される。加えて、第一ダウンストリームトランザクション（"R_T0"）に関連するダウンストリームデータは、ダウンストリームデータシグナル 506 の状態に依り、利用可能な状態にあるということが示される。

図４も参照すると、ローカルデータシグナル 504 が、ローカルデータバッファ 410 に格納されたデータに対応し、また、ダウンストリームデータシグナル 506 が、ダウンストリームデータバッファ 420 に格納されたデータに対応する。ローカルデータストローブ 404 は、データがローカルソースから使用可能であることを示し、ローカルアービトレーション論理手段 414 は、バスアクセスリクエスト 471 をソース間アービトレーション手段 416 へと送信する。同様に、ダウンストリームデータストローブ 408 が、データがダウンストリームソースから使用可能であることを示し、ダウンストリームアービトレーション論理手段 422 も、バスアクセスリクエスト 461 をソース間アービトレーション手段 416 へと送信する。

ソース間アービトレーション手段 416 は、種々の基準を用いて、所与の任意の処理期間中に、どれにバスが許可されるかを決定する。ソース間アービトレーション手段 416 は、特定のソースにバスを許可した際に、バス許可シグナルをそのソースへと送信する。例えば、図５では、ローカルデータ 504 （L_T0）が最初にバスを許可される。そこで、ソース間アービトレーション手段 416 が、バス許可シグナル 474 をローカルアービトレーション論理手段 414 へと送信する。或る実施形態においては、バス許可シグナル 474 が、データが実際にデータブロック内に収められることになる処理期間（例えば、処理期間 540 ）中に送信される。他の実施形態においては、シグナル 474 は、先行の処理期間中に送信することができる。

加えて、ソース間アービトレーション手段 416 は、後述するような位置指標 （ position indicator ） を送信する。これは、ローカルアービトレーション論理手段 414 が、ヘッダーもしくはデータが最初に収まるべきレーンを識ることができるようにするためのものである。或る実施形態においては、ソース間アービトレーション手段 416 は、この報知を、〈次のレーンはここから〉シグナル （ "next lane in" signal ） 475 という形態で、ローカルアービトレーション論理手段 414 へと送信する。図５の実施例においては、第一処理期間 540 についての〈次のレーンはここから〉は、レーン "0" 508 のこととなる。したがって、レーン"0" は、ローカルアービトレーション論理手段 414 が、そのトランザクションデータに関するヘッダーを収めるためのレーンということになる。

或る実施形態においては、ローカル出力配置手段 （ arrange local output means ） 430 は、ローカルアービトレーション論理手段 414 からの、次のレーンを示すシグナル 476 を受信する。その後、ローカル出力配置手段 430 は、その処理期間内にアセンブルするべきかについてヘッダーを検索する。或る実施形態においては、ヘッダーに含まれるべき情報は、コマンドキュー 412 から検索される。加えて、手段 430 は、ローカルデータバッファ 410 からデータを検索する。ローカル出力配置手段 430 は、データブロック／レーン構造を有する転送前ローカルデータブロック （ local pre-transmit data block ） 440 内に、ヘッダーおよび／もしくはデータを配置する。例えば、次のレーンがレーン "0" から始まる場合には、ローカル出力配置手段 430 が、転送前ローカルデータブロック 440 のレーン "0" 内にヘッダーを収めて、最初の七個のデータフラグメント（ L_T0_D0 〜 L_T0_D6 ）をレーン "1"〜"7" に収めることになる。

ひとたび許可がローカルアービトレーション論理手段 414 に下されると、手段 414 はそのデータのブレイクポイントを予測する。換言すると、手段 414 は、トランザクションに関するデータが完了することになる処理期間とレーンとを決定する、ということである。或る実施形態においては、コマンドキュー 412 内に事前に格納されるトランザクションサイズに依る識別に基づいて、ローカルアービトレーション論理手段 414 がこの予測を行う。或る実施形態においては、ローカルアービトレーション論理手段 414 は、トランザクション全体の末尾としてブレイクポイントを予測する。別の実施形態においては、トランザクションに関するデータの戻りを、複数の部分で実行することができ（例えば、トランザクションが或るサイズを超過した場合）、また、データの末尾以前であればどこでもブレイクポイントとすることもできる。

或る実施形態においては、ローカルアービトレーション論理手段 414 は、ブレイクポイントが次の未来の処理期間内に発生することを予測して、ブレイクポイントが発生するということを、ローカルブレイクポイント報知シグナル 472 をソース間アービトレーション手段へと送ることによって報せる。加えて、手段 414 は、データブロック構造内部の、データの末尾の位置を報知する。或る実施形態においては、レーン構造のどこでブレイクポイントが発生するのかについての指標 473 を送信することによってこれを行う。これらのシグナルは、それぞれ、図５のシグナル526 とシグナル 524 に相当する。

図５の実施例においては、ローカルデータアービトレーション論理手段 414 は、そのトランザクションサイズが八個のデータフラグメント（D0〜D7）を含むということを認識しており、よって、トランザクションを完了させるためには第二処理期間 542 のレーン "0" 508 までを埋めればよい、と判断する。したがって、ローカルデータアービトレーション論理手段 414 は、次の処理期間 542 中にブレイクポイントが発生するということを判断することになる。

ローカルブレイクポイントシグナル 472 （図４）, 526 （図５） を用いて、ブレイクポイントが発生するということを、ローカルデータアービトレーション論理手段 414 がソース間アービトレーション手段 416 に報せる。図示した実施形態においては、シグナル 472, 526 をハイ状態にすることによって、この報知を行う。別の実施形態においては、ロー状態を用いることもでき、または他のタイプの報知を行うこともできる。ローカルブレイクポイントシグナル 472, 526 は二値の指標（即ち、未来のブレイクポイントが有るか無いか）であるため、シグナルは単一のビットもしくはワイヤで表現することができる。

加えて、ローカルデータアービトレーション論理手段 414 は、次のローカルレーンシグナル 473 （図４）, 524 （図５） を用いて、ソース間アービトレーション論理手段 416 に次のブレイクポイントがレーン構造内のどこで発生するかを報せる。或る実施形態においては、この報知は、次の処理期間 542 においてどのレーンが最初に使用可能となるかを報せるというかたちで行われる。実施例で示しているように、次のローカルレーンシグナル 473, 524 は、ひとつの "1" を伝えることができ、これは、（バスアクセスを許可されたならば）別のソースがレーン "1" 509 を使用可能な状態になる、ということを意味している。別の実施形態においては、次のローカルレーンシグナル 473, 524 は、現在のトランザクションに関するデータの最後のフラグメントを担うのはどのレーンであるか（例えば、この実施例においては "L_T0_D7" である）を報知することができる。このような実施形態においては、レーン "0" 508 が最後のフラグメントを担うということを、次のローカルレーンシグナル 473, 524 が "0" を伝えることによって報知する。

次のローカルレーンシグナル 473, 524 はレーンの識別について報せるので、シグナル 473, 524 に用いることができるビットの数は、このような報知を行うために充分なものとする。八個のレーンを用いる実施形態においては、3ビットの情報もしくはワイヤをシグナル 473, 524 のために用いる。

さまざまな別種の実施形態においては、ソース間アービトレーション手段 416 は、ブレイクポイントが次の処理期間内に発生することになるかどうか、およびブレイクポイントがどこに生じるのかを決定することができる、といったような他のタイプの情報を受信することができる。別の手法として、ソース間アービトレーション手段 416 はこれらの決定の一方もしくは双方を自身のみで行うことができる。なおも別の実施形態においては、ブレイクポイントが次の処理期間のさらに後の処理期間で発生する場合についても、アービトレーション手段 414, 416 or 422 がブレイクポイントがどこで発生するかを決定して報知する。その他数多の実施形態を実施することができ、また、それらの実施形態は本発明の範囲内に在る。

ソース間アービトレーション手段 416 が、（シグナル 526 を介して）ブレイクポイントが次の処理期間 542 に発生するということを確定した際には、手段 416 は、次の期間 542 中におけるバスを同一のソース（即ち、この実施例ではローカルソース）に許可するか、あるいは別のソース（即ち、この実施例ではダウンストリームソース）に許可するかを決めることができる。図５の実施例においては、ソース間アービトレーションユニット 416 は、第一処理期間 540 からの未決のリクエストをやはり有するダウンストリームデータ 506 （R_T0）へのバスの許可を決定する。したがって、ソース間アービトレーション手段 416 は、バス許可シグナル 464 をダウンストリームアービトレーション論理手段 422 へと送信する。或る実施形態においては、シグナル 464 は第二処理期間 542 中に送信される。別の実施形態においては、シグナル 464 は早期に送信することができる（例えば、第一処理期間 540 中）。

加えて、ソース間アービトレーション手段 416 は、ダウンストリームアービトレーション論理手段 422 にそのヘッダもしくはデータを最初にどのレーンに収めるべきかということを報せるための位置指標を送信する。或る実施形態においては、ソース間アービトレーション手段 416 は、〈次のレーンはここから〉シグナル 465 という形態をとった指標を、ダウンストリームアービトレーション論理手段 422 へと送信する。〈次のレーンはここから〉シグナル 465 は、レーンを識別するための整数であるような「レーン識別子」 （ "lane identifier" ） を含むことができる。例えば、データブロック構造内部に八個のレーンが存在している実施例においては、レーン識別子は0から7の整数とすることができる。他の実施形態においては、データ構造内部のビットの数（例えば、256ビットデータ構造ならば 0〜255 の数）、もしくは、ブレイクポイントの位置の他の指標を送信することができる。

或る実施形態においては、〈次のレーンはここから〉シグナル 465 は、前の処理期間 540 中に、以前に許可されたソース（例えば、この場合はローカルソース）によって送信された次のローカルレーンシグナル 524 に相当する。前述したように、ローカルアービトレーション論理手段 414 によって前の処理期間中に送信された次のローカルレーンシグナル 524 は、"1" であって、これは、ローカルデータのブレイクポイントの後に最初に使用可能となるレーンが、レーン"1" 509 である、ということを意味している。

他の実施形態においては、〈次のレーンはここから〉シグナル 465 は、次のローカルレーンシグナル 524 の値と完全に同一では無いが、次のローカルレーンシグナル 524 の値に基づいた値とすることができる。例えば、限定するものでは無いが、次のローカルレーンシグナル 524 が、ローカルデータが占めることになる最後のレーンを報知し、また、〈次のレーンはここから〉シグナル 465 が、ダウンストリームデータがまず占めるべき最初のレーンを報知するようにすることができる。加えて、次のローカルレーンシグナルと、〈次のレーンはここから〉シグナルとが、レーン識別子以外の方法で報知されるようにすることもできる。例えば、一方もしくは双方が、データブロック内部のビット位置を報知するようにするか、または、同様の他の方法で報知するようにすることができる。

図５の実施例においては、第二処理期間 542 についての〈次のレーンはここから〉は、レーン "1" 509 となり、これが処理期間 540 中に報知されることになる。したがって、レーン "1" が、ダウンストリームアービトレーション論理手段 422 が収めるそのトランザクションデータのヘッダーを入れ込むレーンとなる。その後、第二処理期間 542 において余るレーンが、第一トランザクションのデータフラグメントで埋まるように、ダウンストリームアービトレーション論理手段 422 がそのデータを配置する。

ダウンストリームアービトレーション論理手段 422 に許可が発せられると、ダウンストリームアービトレーション論理手段 422 はそのデータのブレイクポイントを予測する。或る実施形態においては、ダウンストリームアービトレーション論理手段 422 が、コマンドキュー 412 に事前に格納されているトランザクションサイズの認識に基づいてこの予測を行う。示した実施例においては、トランザクションサイズはデータフラグメント十六個分となる。したがって、第三処理期間 544 （即ち、次の処理期間）中にはブレイクポイントは発生しない。そこで、予測されるブレイクポイントは、第四処理期間 546 中に発生することになる。さらに、ダウンストリームアービトレーション論理手段 422 は、十六個のデータフラグメント（D0〜D15）を含むそのトランザクションサイズを認識して、トランザクションを完了するために、第四処理期間 546 のレーン "0" とレーン "1" とがデータフラグメントで埋まることになるということを判定する。

処理期間 542 では、ダウンストリームアービトレーション論理手段 422 が、残余の連続レーンを、そのヘッダーおよびデータフラグメントで埋めることになる。しかしながら、ブレイクポイントが次の処理期間 544 では発生しないので、来たるべきブレイクポイントが有るということがダウンストリームブレイクポイントシグナル 462, 530 を介して処理期間 542 中に報知されることは無い。そこで、後述するように、この報知は処理期間 544 中に行われることになる。

処理期間 544 中には、ダウンストリームアービトレーション論理手段 544 が、そのトランザクションデータ（D6〜D13）でデータブロック全体を埋める。ここで、ブレイクポイントが次の処理期間 546 中に発生することになるので、ダウンストリームアービトレーション論理手段 422 が、来たるべきブレイクポイントが有るということをダウンストリームブレイクポイントシグナル 462, 530 を介して報知する。加えて、ダウンストリームアービトレーション論理手段 422 が、次のダウンストリームレーンシグナル 463, 528 を介して、ブレイクポイントの位置を報知する。図５の実施例の次のダウンストリームレーンシグナル 528 が報知するように、ブレイクポイントは、第四処理期間 546 中のレーン "2" 510 に発生することになる。

ソース間アービトレーション手段 416 が（シグナル 530 を介して）次の処理期間 546 においてブレイクポイントが発生するということを判定する際には、手段 416 は、次の期間 546 中に同じソース（即ち、この実施例ではダウンストリームソース）にバスを許可するか、あるいは、別のソース（即ち、この実施例ではローカルソース）にバスを許可するかを決定する。図５の実施例においては、ソース間アービトレーションユニット 416 が、第二処理期間 542 からの未決のリクエストを有するローカルデータ 506 （R_T1）へのバスの許可を決定する。その後、この処理は反復して継続される。

上述したように、データブロックのレーンが、ローカルデータもしくはダウンストリームデータで正しく埋まるように、ローカルアービトレーション論理手段 414 およびダウンストリームアービトレーション論理手段 422 は、所与の任意の処理期間に亘ってそのデータを配置する。或る実施形態においては、この処理を、第二処理期間 542 の実施例（図５）を用いた以下の説明のようにして実行する。

ダウンストリーム出力配置手段 432 は、ローカルアービトレーション論理手段 414 から、〈次のレーンはここから〉を報知するシグナルを受信する。その後、ダウンストリーム出力配置手段 432 は、その処理期間内にアセンブルすべきときは、ヘッダーを取り出す。或る実施形態においては、ヘッダーに含まれるべき情報が、コマンドキュー 412 から取り出される。加えて、手段 432 は、ダウンストリームデータバッファ 420 からデータを取り出す。ダウンストリーム出力配置手段 432 は、データブロック／レーン構造を有する転送前ダウンストリームデータブロック 442 内に、ヘッダーおよび／もしくはデータを配置する。例えば、〈次のレーンはここから〉がレーン "1" であるとすると、ダウンストリーム出力配置手段 432 は、転送前ダウンストリームデータブロック 442 内のレーン "1" にヘッダーを収めて、六個のデータフラグメント（ R_T0_D0〜R_T0_D5 ）を、レーン "2"〜"7" に収める。前述したように、データブロックのレーン "0" は、ローカルソースからのデータの残余部分に割り当てられる。したがって、ローカル出力配置手段 430 は、転送前ローカルデータブロック 440 内に残余データを収める。特に、トランザクションからの最後のデータフラグメント（L_T0_D7）を、転送前ローカルデータブロック 440 のレーン "0" に収めることになる。

転送前データブロック440, 442 内のデータを複合化するために、ソース間アービトレーション手段 416 は、〈ローカル／ダウンストリーム選択〉シグナル （"local/downstream select" signal ） 460 を、データアセンブリ手段 450 へと送信する。データアセンブリ手段 450 は、データブロック転送期間中に、データをアセンブルして、アップストリームリンクバス 452 を介してデータを送信するための手段を含む。

或る実施形態においては、ローカル／ダウンストリーム選択シグナル 460 は、データブロック構造内のレーンの数に対応する数のビットを有するようなシグナルである。この実施例においては、ローカル／ダウンストリーム選択シグナル 460 は、8ビットのシグナルであって、それぞれのビットがレーンに対応している。ビットが第一状態（例えば、 "0" ）に在る場合には、データアセンブリ手段 450 に対して、転送前ローカルデータブロック 440 の対応するレーンから、データを検索すべきである、ということを報知することができる。また、ビットが第二状態（例えば、 "1" ）に在る場合には、データアセンブリ手段 450 に対して、転送前ダウンストリームデータブロック 442 の対応するレーンから、データを検索すべきである、ということを報知することができる。あるいは、上記の逆の組み合わせで行うこともできる。

例えば、ローカル／ダウンストリーム選択シグナル 460 の最上位ビットがレーン "0" に対応し、最下位ビットがレーン "7" に対応すると仮定する。さらに、値 "0" がローカルソースを、また値 "1" がダウンストリームソースを意味すると仮定する。すると、第二処理期間 542 （図５）に亘って、ローカル／ダウンストリーム選択シグナル 460 は、値 "0 1 1 1 1 1 1 1" を持つことになる。また、第四処理期間 546 に亘って、シグナル 460 は、値 "1 1 0 0 0 0 0 0" を持つことになる。

他の実施形態においては、どのビットがどの特定のレーンに対応するかを変えることができる。加えて、値"1" がローカルソースを、値 "0" がダウンストリームソースを意味するようにすることもできる。なおも他の別個の実施形態においては、データアセンブリ手段 450 が、異なったフォーマットを施された情報を用いて、どのソースに対してどのレーンにするかを決めることができる。なおも他の別個の実施形態においては、転送前ローカルデータブロック 440 と転送前ダウンストリームデータブロック 442 を別々に用いることはしない。その代わりに、ローカルおよびダウンストリームソースからのデータを、直接に、単独の転送前データブロック（図示せず）内に収めることができる。この実施形態においては、データアセンブリ手段 450 に、レーンの構成（即ち、どのソースにどのレーンを許可したのかということ）についての情報を報せる必要が無い。その代わりに、データアセンブリ手段 450 は、単一の転送前データブロック内のデータを、アップストリームリンクバス 452 へと単純に与える。

或る実施形態においては、内部クロックシグナル 502 が、リンクバスクロックよりも低い周波数で作動し、また、リンクバスクロック周波数が、内部クロックシグナル 502 の周波数のほぼ整数倍となる。例えば、限定をするものでは無いが、内部クロックシグナル 502 がメガヘルツ（MHz）範囲の周波数で作動し、その一方、リンクバスクロックがギガヘルツ（GHz）範囲で作動するようにすることができる。同様に、内部クロックおよび／もしくはリンクバスクロックが、より高い周波数もしくはより低い周波数で作動するようにすることもできる。加えて、他の実施形態においては、これらのクロックがほぼ同一の周波数で作動するようにすることもできる。

リンクバスクロックの各サイクルにおいて、データアセンブリ手段 450 によって与えられるデータを、アップストリームリンクバス 452 を介して送信することができる。或る実施形態においては、リンクバスクロックのひとつもしくは複数のサイクルの長さとすることができるようなひとつの「データブロック転送期間」中に、アップストリームリンクバス 452 を介して、ひとつのデータブロックを送信することができる。

例えば、限定をするものでは無いが、各データブロックが64ビットのデータを含むと仮定する。リンクバスが32ビット幅である場合には、ひとつのデータブロックを送信するために、リンクバスクロックの2サイクルをかけるようにすることができる。処理期間（例えば、期間 540 ）が内部クロックサイクルひとつ分の長さであると（実際にはそうでは無いとしても）仮定すると、この実施例においては、リンクバスクロック周波数を、内部クロック周波数の二倍とすることができる。例えば、内部クロックが400MHzで作動する場合には、リンクバスクロックが約800MHzで作動するようにできる。別の例を用いると、データブロックが256ビット幅であり、またリンクバスが16ビット幅である場合には、ひとつのデータブロックを送信するために、リンクバスクロックの16サイクルをかけるようにすることができる。したがって、１つのデータブロック転送期間は、リンクバスクロックの16サイクル分の長さとなる。この例では、リンクバスクロック周波数を、内部クロック周波数の十六倍にすることができる。例えば、内部クロックが400MHzで作動する場合には、リンクバスクロックが約6.4GHzで作動するようにできる。

上述した実施例では、リンクバス幅に対応する数のビットが、リンクバスクロックのそれぞれのサイクル毎に送出される（例えば、クロックの立ち上がりもしくは立ち下がりに合わせて）。別の実施形態においては、複数のビットセットを、クロックサイクル毎に送出することができる（例えば、クロックの立ち上がりもしくは立ち下がりに合わせて）。これらの別の実施形態においては、データブロック転送期間が持続する時間を、上述した実施例のそれから変えることもできる。

ローカルアービトレーション論理手段 414 、ダウンストリームアービトレーション論理手段 422 、およびソース間アービトレーション論理手段 416 の機能のうちのいくつかは、フローチャートとして容易に図解することができるような方法として実行することができる。そこで、種々の実施形態のさらなる理解のために図６および図７を示す。

図６は、本発明の実施形態に係る、バスへのアクセスをリクエストするための方法を示すフローチャートである。或る実施形態においては、この方法のすべてもしくは一部を、ローカルアービトレーション論理手段 414 （図４）、および／もしくはダウンストリームアービトレーション論理手段 422 （図４）によって行うことができる。他の実施形態においては、他の機能要素が、この方法のすべてもしくは一部を実行することができる。説明のために、「第一ソース」、「第二ソース」という語を用いて、アップストリームリンクバスへのアクセスをリクエストする処理の全体を記載する。これらの語は、特定のローカルアービトレーション論理手段 414 もしくはダウンストリームアービトレーション論理手段 422 を指すものとは限らない。

この方法は、ブロック602 から始まり、まず、アップストリームリンクバスを介して転送可能であるような第一ソースからのデータが有るかどうかを判定する。或る実施形態においては、この判定を、データストローブシグナル（例えば、図４のストローブ 404, 408 ）の状態を基にして行うことができる。別の実施形態においては、この判定を、〈バッファが空かそうでないか〉シグナル （例えば、図４のシグナル 477, 467 ）を基にして行うことができる。同様に、他の実施形態においては、この判定を他の方法で行うこともできる。使用可能な第一ソースデータが無ければ、この方法は待機に入る。

第一ソースデータが使用可能であれば、ブロック 604 で、第一ソースがバスアクセスリクエストを送信する。或る実施形態においては、リクエストを、ソース間アービトレーション手段 416 （図４）に送信する。ソース間アービトレーション手段 416 は、特定の内部処理期間中に、他のソースからのリクエストを同様に受信することができる。ソース間アービトレーション手段 416 は、入ってくるバスアクセスリクエストをアービトレーションして、アクセスを許可するという責務を負う。

ブロック 606 では、或る実施形態においては、第一ソースは、ソース間アービトレーション手段 416 からの許可報知を待つ。加えて、アクセスが許可された際には、第一ソースは、ソース間アービトレーション手段 416 からの〈次のレーンが使用可能となった〉指標を求める。〈次のレーンが使用可能となった〉指標は、第一ソースに、転送のために構築されているデータブロックの内部にヘッダーおよび／もしくはデータを収めはじめるべき箇所を伝える。

その後、ブロック608 では、第一ソースがデータブロック内部にそのデータを状況に応じて配置する。或る実施形態においては、ひとつもしくは複数の転送前データブロック（例えば、図４の 440, 442 ）の内部にデータを配置する。いくつかの処理期間中に、ひとつのソースだけがデータブロック内部にデータを配置し、一方、その他の処理期間中には、少なくとも二つのソースがデータブロック内部にデータを配置する。

ブロック 610 では、第一ソースのトランザクションが、次の処理期間中に完了するかどうかという判定が行われる。完了しない場合には、第一ソースは、次のデータブロックの内部へのデータの配置を継続する。処理期間中にトランザクションが完了しないので、次のデータブロックのすべてのレーンが第一ソースによって占められることになる。その後、この手順が反復される。

次の処理期間中に第一ソースのトランザクションが完了することになると判断した場合に、ブロック 612 では、第一ソースが、ブレイクポイントが発生することになるということを、ソース間アービトレーションユニット 416 （図４）へと報知する。加えて、第一ソースは、どこでブレイクポイントが発生することになるのかについても送信する。例えば、第一ソースは、トランザクションの末尾の後に、使用可能となるような次のレーンを確定して送信することができる。

ブロック 614 では、次の処理期間中に、第一ソースが、次のデータブロックの第一セクション内のひとつもしくは複数の第一連続レーン内部に、残留したデータをできる限り配置する。データが残っていない場合（例えば、前の処理期間の最後のレーンの後にブレイクポイントが発生した場合）には、第一ソースは次のデータブロック内にはデータを収めることは無い。その後、この方法を繰り返す。

ソース間アービトレーションユニット 416 （図４）が、バスの次の許可先として第二ソースに決定した場合には、第二ソースからのデータが、データブロックの第二セクション内のひとつもしくは複数の第二連続レーンの内部に収められることになる。ここで、第二セクションは、第一セクションに連続する次のレーンから始まるものである。データブロックが満たされると、データブロック転送期間（即ち、リンクバスクロックのひとつもしくは複数のサイクル）中に、第一ソースデータおよび第二ソースデータが、バスを介して送信される。

図７は、本発明の実施形態に係る、バスへのアクセスを許可するための方法のフローチャートを示している。或る実施形態においては、この方法のすべてもしくは一部を、ソース間アービトレーション論理手段 416 （図４）が実行することができる。他の実施形態においては、他の機能要素が、この方法のすべてもしくは一部を実行することができる。

この方法は、第一ソースからバスアクセスリクエストを受信するブロック 702 から始まる。例えば、バスアクセスリクエストは、ローカルアービトレーション論理手段 414 （図４）、もしくはダウンストリームアービトレーション論理手段 422 （図４）によって生成することができる。ソース間アービトレーション論理手段 416 は、時宜に応じて、リクエスタが未だバスへのアクセスを許可されていないということを意味しているような、零個から多数の未決のバスアクセスリクエストを有することができる。

ブロック 704 では、バスがアイドル状態にあるかどうかを判定する。或る実施形態においては、バス上で現在転送されている他のソースが無く、且つ未決のリクエストが無いときに、バスがアイドル状態になっていると見做す。ブロック 714 では、バスがアイドル状態にあるとき、ソース間アービトレーション手段 416 は、第一ソースに対してバスへのアクセスを許可したということを報知することができる。加えて、別のソースが処理期間中にバス上の転送を完了するような場合において、ソース間アービトレーション手段 416 は、ブレイクポイントがどこで発生するかということ（例えば、使用可能な次のレーンを確定すること）を報知することができる。

ブロック 718 では、ソース間アービトレーション手段 416 （図４）が、送信されるデータブロックの内部のデータのアセンブリおよび転送を制御することができる。或る実施形態においては、アップストリームリンクバスを介してデータを複合化して送信する責務を負うような機能要素（例えば、図４のデータアセンブリ手段 450 ）へと、ローカル／ダウンストリーム選択シグナル 460 （図４）を送信することによってこれを実行する。その後、方法が終了する。

ブロック 704 まで話を戻すと、バスがアイドル状態ではないとき（例えば、別のソースがバス上を転送されているとき、もしくは、他のリクエストが未決であるようなとき）に、ブロック 706 では、次の処理期間中にブレイクポイントが発生することになるかどうかを判定する。或る実施形態においては、バスを使用しているソースが出すブレイクポイントシグナル（例えば、図４のシグナル 472, 462 ）を観察することによって、この判定を行う。未来にブレイクポイントが無ければ、方法は待機に入る。

現在バスを使用しているソースが、次の処理期間においてブレイクポイントが発生することになるということを報知した場合、ブロック 708 では、ブレイクポイントの位置を確定する。或る実施形態においては、バスを使用しているソースが出す〈次のレーンはここまで〉シグナル （ "next lane out" signal ） （例えば、図４のシグナル 473, 463 ）を観察することによって、ブレイクポイントの位置を決定する。

ブロック 710 では、すべての未決のリクエストがアービトレーションして、バスを使用するためのアクセスを次に許可されることになるのはどれかを決定する。このアービトレーション処理においては、バスへのアクセスを与えられることになる物を決定するために、種々の基準を用いることができる。

ブロック 712 では、第一ソースが、次にバスを介してデータを送信することができるかどうかについての決定が行われる。もしそうであれば、上記で詳述したブロック 714 およびブロック 718 が実行される。その後、方法が終了する。

ブロック 712 において第一ソースがバスへのアクセスを許可されない場合には、ブロック 716 で、ソース間アービトレーション手段 416 が、バスへのアクセスが許可されたということを、バスへのアクセスをリクエストした別のソースへと報知する。加えて、ソース間アービトレーション手段 416 は、ブレイクポイントがどこで発生するかということ（例えば、使用可能な次のレーンを確定すること）を報知することができる。ブロック 718 が実行された後、方法は終了する。

上述した実施形態では、ハブ・アーキテクチャは、主にハードウェアで実施されるものとして記載している。他の実施形態においては、ハブ・アーキテクチャのひとつもしくは複数の要素を、マイクロプロセッサもしくは他のコンピュータデバイスによって実行された際に上述した実施形態の同一の結果が得られるような一連の命令として、ファームウェアまたはソフトウェア内で実施することができる。したがって、ハブの機能を実現するための、コンピュータが実行可能な命令のセットを、コンピュータが読み取り可能な媒体（例えば、ハードディスク、光学もしくは磁気ディスク、ROM、RAM、または実質的に他の任意のコンピュータが読み取り可能な媒体）に格納することができる。

加えて、ハブ・アーキテクチャは電子システムの一部として含めることもできる。図８は、本発明の或る実施形態に係る電子システムを示している。図８および以降の説明は、本発明の実施形態を実施することができるような適切な環境についての、要約した一般的な記載を与えるものである。

ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサに基づくエレクトロニクスもしくはプログラマブルコンシュマーエレクトロニクス、ネットワークパーソナルコンピュータ、ミニコンピュータ、メインフレームコンピュータ、データベースコンピュータ、ならびにそれらの類似物を含むような他のコンピュータシステム構成を以って、本発明を実施することができるということを、当業者は正しく理解することができる。

図８に示したシステムは汎用コンピュータ 800 を含み、汎用コンピュータ 800 は、ひとつもしくは複数の処理ユニット 810 、ノースブリッジ 812 、システムメモリ 814 、および、任意の様々なタイプのバス構造とすることができ、種々のシステムコンポーネントに内部接続するようなシステムバス 820 を含む。

ノースブリッジ 812 は、或る実施形態においては、システムバス 820 と処理ユニット 810 とシステムメモリ 814 との間のインターフェイスとして機能する。したがって、ノースブリッジ 812 は、入出力（I/O）コントローラ、およびメモリコントローラとして作動する。或る実施形態においては、ノースブリッジ 812 は、メモリコントローラの代わりにリンクコントローラを含むようにすることもできる。ノースブリッジ 812 は、プロセッサバス 816 を介して、処理ユニット 810 と通信し、また、メモリバス 818 を介して、システムメモリ 814 と通信する。

システムメモリ 814 は、本発明の実施形態に従って構成される。したがって、システムメモリ 814 はひとつもしくは複数のメモリモジュール 824 （例えば、図２のモジュール 208 ）を含む。さらに、システムメモリ 814 は、種々の実施形態において、リンクコントローラ（例えば、図２のコントローラ 206 ）、および／もしくは、リードオンリーメモリ（ROM） 825 、および／もしくは、ランダムアクセスメモリ（RAM） 826 を含むことができる。

コンピュータ 800 は、ハードディスク（図示せず）を読み書きするためのハードディスクドライブ 827 、リムーバブル磁気ディスク 829 を読み書きするための磁気ディスクドライブ 828 、ならびに、 CD ROM もしくは他の光学メディアのようなリムーバブル光学ディスク 831 を読み書きするための光学ディスクドライブ 830 、をさらに含むことができる。ハードディスクドライブ 827 、磁気ディスクドライブ 828 、および光学ディスクドライブ 830 は、それぞれ、ハードディスクドライブインターフェイス 832 、磁気ディスクドライブインターフェイス 833 、および光学ディスクドライブインターフェイス 834 によって、システムバス 820 に接続することができる。

ユーザーは、キーボード840 、ポインティングデバイス 842 、もしくは他の入力デバイス（図示せず）のような入力デバイスを介して、コンピュータ 800 にリクエストと情報を入力することができる。このような入力デバイスおよびその他の入力デバイスは、システムバスに接続したシリアルポートインターフェイス 846 を介して処理ユニット 810 に接続することもでき、または、パラレルポート、ゲームポート、もしくはユニバーサルシリアルバス（USB）のような他のインターフェイスによって接続することもできる。モニター 847 もしくは他のタイプの表示デバイスを、ビデオアダプター 848 のようなインターフェイスを介してシステムバス 820 に接続することもできる。モニターに加えて、システムが、スピーカーおよびプリンターのような他の周辺出力デバイス（図示せず）を含むこともできる。

リモートコンピュータ849 のようなひとつもしくは複数のリモートコンピュータへの論理接続を用いてネットワーク化された環境内で、コンピュータ 800 が動作することもできる。コンピュータ 800 およびリモートコンピュータ 849 は、クライアント、サーバー、ルーター、ネットワークパーソナルコンピュータ、ピアデバイス （ peer devices ） 、もしくは他のコモンネットワークノードとすることができる。図８に示した論理接続は、ローカルエリアネットワーク（LAN） 851 およびワイドエリアネットワーク（WAN） 852 を含む。

LAN環境において用いた場合、コンピュータ 800 は、ネットワークインターフェイスもしくはアダプター 853 を介してローカルネットワーク 851 に接続される。WAN環境において用いた場合、コンピュータ 800 は、典型的には、WAN 852 を介して接続を確立するための、モデム 854 もしくは他の手段を含む。モデム 854 は、シリアルポートインターフェイス 846 を介して、システムバス 820 に内部的もしくは外部的に接続することができる。 示したネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立するための他の手段を使用することもできるということを理解されたい。
［結論］
データパケットをアセンブルして送信するための方法および装置の種々の実施形態について、電子システム内の実施形態と組み合わせて記載してきた。当業者にとって明らかであるような変形例は、同一の結果を導けるような種々の実施形態とすることができる。特に、限定をするものでは無いが、種々の示された機能ブロック間および方法のステップ間の配置および内部接続は変えることができ、また、他の異なる機能ブロックおよびステップを用いて同一の機能を実行して、実質的に同一のやりかたで、実質的に同一の結果を得ることもできる。さらに、実施形態が内部に組み込まれるようなシステムのタイプは、異なるものとすることができる（例えば、図示して記載したものに較べて、より多いコンポーネント、より少ないコンポーネント、もしくは異なるコンポーネントを含むこともでき、あるいは、異なるやりかたでコンポーネントを内部接続することもできる）。さらに、機能コンポーネントのいくつかもしくはすべてを、ソフトウェア上で実行することもできる。

ここで図示し記載した特定の実施形態にかかわらず、同一の目的を実現するために考慮された任意の配置を、示した特定の実施形態の代わりにすることができるということを、当業者は理解することができる。本発明の数多の翻案は、当業者にとっては明らかなものである。したがって、本出願は、本発明の任意の翻案もしくは変形をもカバーすることになる。本発明は、以下の請求項およびその等価物によってのみ限定されるということをここに宣言するものである。

図１は、従来技術に係るコンピュータシステムの単純化したブロック図である。 図２は、本発明の実施形態に係るコンピュータシステムの単純化したブロック図である。 図３は、本発明の実施形態に係るメモリモジュールの単純化したブロック図である。 図４は、本発明の実施形態に係るハブの単純化したブロック図である。 図５は、本発明の実施形態に係るタイミング図の例である。 図６は、本発明の実施形態に係る、バスへのアクセスをリクエストするための方法のフローチャートである。 図７は、本発明の実施形態に係る、バスへのアクセスを許可するための方法のフローチャートである。 図８は、本発明の或る実施形態に係る電子システムを示す。

Claims (46)

1. ひとつもしくは複数のメモリアクセスリクエストを生成して送信するプロセッサと、
   コミュニケーションバスを介して動作可能に互いに接続されていて、前記ひとつもしくは複数のメモリアクセスリクエスト中でリクエストされたデータを返す複数のメモリモジュールと、
   を含む電子システムであって、
   前記複数のメモリモジュールのそれぞれがデータソースであり、また、前記複数のメモリモジュールのうちのひとつのメモリモジュールが、
   第一ソースデータおよび第二ソースデータが使用可能であることを判定するステップと、
   データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、前記第一ソースデータのうちの少なくとも一部に対して分配するステップであって、前記データブロックが複数のレーンのセットを含み、また、それぞれのレーンがコンフィギュラブルなビットのセットを含む、ステップと、
   前記データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、前記第二ソースデータのうちの少なくとも一部に対して分配するステップであって、前記第二セクションが、前記第一セクションに連続する次のレーンから始まる、ステップと、
   データブロック転送期間中に、前記コミュニケーションバスを介して、前記データブロックの前記第一セクション内の前記第一ソースデータのうちの前記少なくとも一部と、前記データブロックの前記第二セクション内の前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
   を実行するように動作可能であり、
   前記第一セクション内の前記ひとつもしくは複数の第一連続レーンを分配する前記ステップ、または、前記第二セクション内の前記ひとつもしくは複数の第二連続レーンを分配する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、電子システム。
2. 前記プロセッサと、前記複数のメモリモジュールのうちの少なくともひとつとの間に動作可能に接続されたリンクコントローラであって、前記ひとつもしくは複数のメモリアクセスリクエストを受信し、かつ、前記ひとつもしくは複数のメモリアクセスリクエストに基づいて、ひとつもしくは複数のメモリアクセスコマンドを生成して、前記コミュニケーションバスを介して前記複数のメモリモジュールへと送信するように動作可能であるリンクコントローラ、をさらに含むことを特徴とする、請求項１記載の電子システム。
3. 前記メモリモジュールが、更に、
   前記コミュニケーションバスの第一部分上で、ダウンストリーム方向からひとつもしくは複数の他のメモリモジュールからデータを受信し、かつ、
   前記第一ソースデータの前記少なくとも一部と、前記第二ソースデータの前記少なくとも一部とを、前記コミュニケーションバスの第二部分上の前記リンクコントローラへと送信する、
   ように動作可能であることを特徴とする、請求項２記載の電子システム。
4. 前記メモリモジュールが、
   前記コミュニケーションバスを介して、第二メモリモジュールからのダウンストリームデータを受信するよう動作可能な第一回路であって、前記ダウンストリームデータは前記第一ソースデータである、第一回路と、
   前記メモリモジュールにアクセス可能なひとつもしくは複数のメモリストレージユニットからのローカルデータを受信するよう動作可能な第二回路であって、前記ローカルデータは前記第二ソースデータである、第二回路と、
   前記ダウンストリームデータおよび前記ローカルデータを、前記データブロックへとアセンブルするよう動作可能な第三回路と、
   を含むことを特徴とする、請求項１記載の電子システム。
5. 前記メモリモジュールが、
   前記コミュニケーションバスを介して、第二メモリモジュールからのダウンストリームデータを受信するよう動作可能な第一回路であって、前記ダウンストリームデータは前記第二ソースデータである、第一回路と、
   前記メモリモジュールにアクセス可能なひとつもしくは複数のメモリストレージユニットからのローカルデータを受信するよう動作可能な第二回路であって、前記ローカルデータは前記第一ソースデータである、第二回路と、
   前記ダウンストリームデータおよび前記ローカルデータを、前記データブロックへとアセンブルするよう動作可能な第三回路と、
   を含むことを特徴とする、請求項１記載の電子システム。
6. 前記電子システムがコンピュータであることを特徴とする、請求項１記載の電子システム。
7. ローカルデータを格納するためのひとつもしくは複数のメモリストレージユニットと、
   前記ひとつもしくは複数のメモリストレージユニットとコミュニケーションバスとに動作可能に接続されたハブであって、前記コミュニケーションバスを介して、ひとつもしくは複数の他のハブからのダウンストリームデータを受信することができるハブと、
   を含み、
   前記ハブが、
   第一ソースデータおよび第二ソースデータが使用可能であることを判定するステップと、
   データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、前記第一ソースデータのうちの少なくとも一部に対して分配するステップであって、前記データブロックが複数のレーンのセットを含み、また、それぞれのレーンが、コンフィギュラブルなビットのセットを含む、ステップと、
   前記データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、前記第二ソースデータのうちの少なくとも一部に対して分配するステップであって、前記第二セクションが、前記第一セクションに連続する次のレーンから始まる、ステップと、
   データブロック転送期間中に、前記コミュニケーションバスを介して、前記データブロックの前記第一セクション内の前記第一ソースデータのうちの前記少なくとも一部と、前記データブロックの前記第二セクション内の前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
   を実行するよう動作可能であり、
   前記第一セクション内の前記ひとつもしくは複数の第一連続レーンを分配する前記ステップ、または、前記第二セクション内の前記ひとつもしくは複数の第二連続レーンを分配する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、メモリモジュール。
8. 前記ひとつもしくは複数のメモリストレージユニット、ならびに前記ハブが、前記コミュニケーションバスにリムーバブルに接続可能な単一の基板上に共に設置されることを特徴とする、請求項７記載のメモリモジュール。
9. 前記ひとつもしくは複数のメモリストレージユニットが、ひとつもしくは複数のランダムアクセスメモリコンポーネントを含むことを特徴とする、請求項７記載のメモリモジュール。
10. 前記ひとつもしくは複数のランダムアクセスメモリコンポーネントが、ひとつもしくは複数のダイナミックランダムアクセスメモリコンポーネントを含むことを特徴とする、請求項９記載のメモリモジュール。
11. 前記ひとつもしくは複数のメモリストレージユニットが、ひとつもしくは複数のリードオンリーメモリコンポーネントを含むことを特徴とする、請求項７記載のメモリモジュール。
12. 前記ハブが、ひとつもしくは複数の特定用途向け集積回路を含むことを特徴とする、請求項７記載のメモリモジュール。
13. 前記ハブが、
    前記コミュニケーションバスを介して、第二ハブから前記ダウンストリームデータを受信するよう動作可能な第一回路であって、前記ダウンストリームデータは前記第一ソースデータである、第一回路と、
    前記ひとつもしくは複数のメモリストレージユニットから、前記ローカルデータを受信するよう動作可能な第二回路であって、前記ローカルデータは前記第二ソースデータである、第二回路と、
    前記ダウンストリームデータおよび前記ローカルデータを、前記データブロックへとアセンブルするよう動作可能な第三回路と、
    を含むことを特徴とする、請求項７記載のメモリモジュール。
14. 前記ハブが、
    前記コミュニケーションバスを介して、第二ハブから前記ダウンストリームデータを受信するよう動作可能な第一回路であって、前記ダウンストリームデータは前記第二ソースデータである、第一回路と、
    前記ひとつもしくは複数のメモリストレージユニットから、前記ローカルデータを受信するよう動作可能な第二回路であって、前記ローカルデータは前記第一ソースデータである、第二回路と、
    前記ダウンストリームデータおよび前記ローカルデータを、前記データブロックへとアセンブルするよう動作可能な第三回路と、
    を含むことを特徴とする、請求項７記載のメモリモジュール。
15. データをアセンブルして送信するための装置であって、
    ひとつもしくは複数のメモリストレージユニットからローカルデータを受信するための手段と、
    コミュニケーションバスを介して、ひとつもしくは複数のダウンストリームデータソースからダウンストリームデータを受信するための手段と、
    前記ローカルデータおよび前記ダウンストリームデータを、前記コミュニケーションバスを介して送信する方法を決定するための手段と、
    を含み、
    前記決定するステップが、
    データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、前記ローカルデータのうちの少なくとも一部に対して分配するステップであって、前記データブロックが複数のレーンのセットを含み、また、それぞれのレーンがコンフィギュラブルなビットのセットを含む、ステップと、
    前記データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、前記ダウンストリームデータのうちの少なくとも一部に対して分配するステップであって、前記第一セクションと前記第二セクションとが連続している、ステップと、
    を含み、
    前記第一セクション内の前記ひとつもしくは複数の第一連続レーンを分配する前記ステップ、または、前記第二セクション内の前記ひとつもしくは複数の第二連続レーンを分配する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、装置。
16. 前記コミュニケーションバスを介して前記ローカルデータを送信するための第一アクセスリクエストを生成するための手段と、
    前記コミュニケーションバスを介して前記ダウンストリームデータを送信するための第二アクセスリクエストを生成するための手段と、
    をさらに含み、
    前記決定するための手段が、前記第一アクセスリクエストおよび前記第二アクセスリクエストを受信し、また、前記第一アクセスリクエストおよび前記第二アクセスリクエストを前記決定の基礎とすることを特徴とする、請求項１５記載の装置。
17. 前記決定に従って、前記ローカルデータおよび前記ダウンストリームデータを、前記データブロックへと配置するための手段と、
    データブロック転送期間中に、前記コミュニケーションバスを介して、前記データブロック内の前記データを送信するための手段と、
    をさらに含むことを特徴とする、請求項１５記載の装置。
18. コミュニケーションバスを介してデータを送信するための装置であって、
    第一データソースから第一ソースデータを受信するよう動作可能な第一回路と、
    第二データソースから第二ソースデータを受信するよう動作可能な第二回路と、
    前記コミュニケーションバスを介して、前記第一ソースデータおよび前記第二ソースデータを送信するよう動作可能な第三回路と、
    を含み、
    前記第一ソースデータおよび前記第二ソースデータを送信するステップが、
    前記コミュニケーションバスを介して前記第一ソースデータを送信するステップと、
    前記第一ソースデータの末尾に対応する第一ブレイクポイントを識別するステップであって、前記第一ブレイクポイントが、前記コミュニケーションバスへのアクセスを許可する際に生成された予測位置と一致する、ステップと、
    前記第一ソースデータの前記末尾に連続して、前記コミュニケーションバスを介して、前記第二ソースデータを送信するステップと、
    前記第二ソースデータの末尾に対応する第二ブレイクポイントを識別するステップであって、前記第二ブレイクポイントが、前記コミュニケーションバスへのアクセスを許可する際に生成された予測位置と一致する、ステップと、
    を含むことを特徴とする、装置。
19. 前記第一回路が、前記コミュニケーションバスからダウンストリームデータを受信するよう動作可能な第四回路を含み、また、
    前記第二回路が、ひとつもしくは複数のローカルメモリーストレージユニットからローカルデータを受信するよう動作可能な第五回路を含むことを特徴とする、請求項１８記載の装置。
20. 前記コミュニケーションバスを介して前記第一ソースデータを送信する前記ステップが、
    第一処理期間中に、前記第一ソースデータの第一部分を、データブロック構造内に配置するステップであって、前記データブロック構造が、一定数の連続的且つコンフィギュラブルなビットを含む、ステップと、
    第二処理期間中に、前記第一ソースデータの残余部分を、前記データブロック構造の第一セクション内に配置するステップであって、前記第一セクションが、連続するビットの第一セットを含む、ステップと、
    を含むことを特徴とする、請求項１８記載の装置。
21. 前記第一ブレイクポイントを識別する前記ステップが、前記第二処理期間中に、前記第一ブレイクポイントを前記データブロック構造の前記第一セクションの末尾として識別するステップ、をさらに含むことを特徴とする、請求項２０記載の装置。
22. 前記コミュニケーションバスを介して前記第二ソースデータを送信する前記ステップが、
    前記第二処理期間中に、前記第二ソースデータの第一部分を、前記データブロック構造の第二セクション内に配置するステップであって、前記第二セクションが、前記第一セクションに連続し、また、前記第二セクションが、連続するビットの第二セットを含む、ステップ、
    を含むことを特徴とする、請求項２１記載の装置。
23. 前記データブロック構造が、一定数のレーンを含み、また、それぞれのレーンが、同一の数のビットを含み、また、前記データブロック構造の前記第一セクションが、前記一定数のレーンの第一セットを含み、また、前記データブロック構造の前記第二セクションが、前記一定数のレーンの第二セットを含むことを特徴とする、請求項２２記載の装置。
24. コミュニケーションバス上にデータを送信するための方法であって、
    第一処理期間中に、第一ソースデータの第一部分を、データブロック構造内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含む、ステップと、
    前記コミュニケーションバスを介して、前記第一ソースデータの前記第一部分を送信するステップと、
    第二処理期間中に、前記第一ソースデータの残余部分を、前記データブロック構造の第一セクション内に配置するステップであって、前記第一セクションが、連続するビットの第一セットを含む、ステップと、
    前記第二処理期間中に、第二ソースデータの第一部分を、前記データブロック構造の第二セクション内に配置するステップであって、前記第二セクションが前記第一セクションに連続し、また、前記第二セクションが、連続するビットの第二セットを含む、ステップと、
    前記コミュニケーションバスを介して、前記第一ソースデータの前記残余部分と、前記第二ソースデータの前記第一部分とを送信するステップと、
    を含み、
    前記第一ソースデータの前記第一部分を配置する前記ステップ、および、前記第一ソースデータの前記残余部分を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、方法。
25. 前記第一処理期間中において、前記第一ソースデータ内の前記ブレイクポイントが、前記第二処理期間中に発生することになるということを報知するステップ、をさらに含むことを特徴とする、請求項２４記載の方法。
26. 前記第一処理期間中において、前記第一セクションの末尾の位置を報知するステップ、をさらに含むことを特徴とする、請求項２４記載の方法。
27. 前記データブロック構造が、一定数のレーンを含み、また、それぞれのレーンが、同一の数のビットを含み、また、前記データブロック構造の前記第一セクションが、前記一定数のレーンの第一セットを含み、また、前記データブロック構造の前記第二セクションが、前記一定数のレーンの第二セットを含むことを特徴とする、請求項２４記載の方法。
28. 前記第一処理期間中において、前記第一セクションの最後のレーンに対応するレーン識別子を報知するステップ、をさらに含むことを特徴とする、請求項２７記載の方法。
29. 前記第一処理期間中において、前記第二セクションの最初のレーンに対応するレーン識別子を報知するステップ、をさらに含むことを特徴とする、請求項２７記載の方法。
30. 第一処理期間中に、第一ソースデータの第一部分を、データブロック構造内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含む、ステップと、
    コミュニケーションバスを介して、前記第一ソースデータの前記第一部分を送信するステップと、
    第二処理期間中に、前記第一ソースデータの残余部分を、前記データブロック構造の第一セクション内に配置するステップであって、前記第一セクションが、連続するビットの第一セットを含む、ステップと、
    前記第二処理期間中に、第二ソースデータの第一部分を、前記データブロック構造の第二セクション内に配置するステップであって、前記第二セクションが前記第一セクションに連続し、また、前記第二セクションが連続するビットの第二セットを含む、ステップと、
    前記コミュニケーションバスを介して、前記第一ソースデータの前記残余部分と、前記第二ソースデータの前記第一部分とを送信するステップと、
    を含む方法であって、
    前記第一ソースデータの前記第一部分を配置する前記ステップ、および、前記第一ソースデータの前記残余部分を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含み、前記第二セクションが前記ブレイクポイントの前記予測された位置で前記第一セクションに連続する、方法、
    を実行するための、コンピュータ実行可能な命令を有する、コンピュータ読み取り可能媒体。
31. 第一ソースデータおよび第二ソースデータが使用可能であることを判断するステップと、
    データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、前記第一ソースデータのうちの少なくとも一部に対して分配するステップであって、前記データブロックが、複数のレーンのセットを含み、また、それぞれのレーンが、コンフィギュラブルなビットのセットを含む、ステップと、
    前記データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、前記第二ソースデータのうちの少なくとも一部に対して分配するステップであって、前記第二セクションが、前記第一セクションに連続する次のレーンから始まる、ステップと、
    データブロック転送期間中に、コミュニケーションバスを介して、前記データブロックの前記第一セクション内の前記第一ソースデータのうちの前記少なくとも一部と、前記データブロックの前記第二セクション内の前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
    を含み、
    前記第一セクション内の前記ひとつもしくは複数の第一連続レーンを分配する前記ステップ、または、前記第二セクション内の前記ひとつもしくは複数の第二連続レーンを分配する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、方法。
32. 前記第一ソースデータおよび前記第二ソースデータが使用可能であることを判断する前記ステップが、
    前記第一ソースデータが使用可能であるという第一指標を、第一データソースから受信するステップと、
    前記第二ソースデータが使用可能であるという第二指標を、第二データソースから受信するステップと、
    を含むことを特徴とする、請求項３１記載の方法。
33. 前記第一ソースデータおよび前記第二ソースデータが使用可能であることを判断する前記ステップが、
    前記コミュニケーションバスを介して、前記第一ソースデータの送信のための第一リクエストを受信するステップと、
    前記コミュニケーションバスを介して、前記第二ソースデータの送信のための第二リクエストを受信するステップと、
    を含むことを特徴とする、請求項３１記載の方法。
34. 前記ひとつもしくは複数の第二連続レーンを分配する前記ステップが、
    どのレーンが前記の次の連続レーンであるのかを識別することを可能にする情報を受信するステップと、
    或る数のレーンを、前記第二ソースデータのうちの前記少なくとも一部に対して分配するステップであって、前記或る数のレーンの最初のレーンが、前記の次の連続レーンである、ステップと、
    を含むことを特徴とする、請求項３１記載の方法。
35. 第一のソースデータおよび第二ソースデータが使用可能であることを判断するステップと、
    データブロックの第一セクション内のひとつもしくは複数の第一連続レーンを、前記第一ソースデータのうちの少なくとも一部に対して分配するステップであって、前記データブロックが、複数のレーンのセットを含み、また、それぞれのレーンが、コンフィギュラブルなビットのセットを含む、ステップと、
    前記データブロックの第二セクション内のひとつもしくは複数の第二連続レーンを、前記第二ソースデータのうちの少なくとも一部に対して分配するステップであって、前記第二セクションが、前記第一セクションに連続する次のレーンから始まる、ステップと、
    データブロック転送期間中に、コミュニケーションバスを介して、前記データブロックの前記第一セクション内の前記第一ソースデータのうちの前記少なくとも一部と、前記データブロックの前記第二セクション内の前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
    を含む方法であって、
    前記第一セクション内の前記ひとつもしくは複数の第一連続レーンを分配する前記ステップ、または、前記第二セクション内の前記ひとつもしくは複数の第二連続レーンを分配する前記ステップは、ブレイクポイントの位置を予測するステップを含む、方法、
    を実行するための、コンピュータ実行可能な命令を有する、コンピュータ読み取り可能媒体。
36. 第一ソースからの第一ソースデータを、データブロック構造の第一セクション内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含み、また、前記データブロック構造内のデータが、コミュニケーションバス上に周期的に送出される、ステップと、
    第二ソースからの第二ソースデータが、前記コミュニケーションバスを介して送信可能であるかを判定するステップと、
    前記第二ソースデータを送信するため、前記コミュニケーションバスへのアクセスをリクエストするステップと、
    前記データブロック構造内のどこに、前記第二ソースデータの少なくとも一部を収めるべきかについての指標を受信するステップと、
    前記第二ソースデータのうちの前記少なくとも一部を、前記指標に従って、前記データブロック構造内に配置して、前記第二ソースデータのうちの前記少なくとも一部が、前記第一セクションの末尾に連続する前記データブロックの第二セクションを占めるようにするステップと、
    データブロック転送期間中に、前記コミュニケーションバスを介して、前記第一ソースデータと、前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
    を含み、
    前記第一ソースデータを前記第一セクション内に配置する前記ステップ、または、前記第二ソースデータのうちの前記少なくとも一部を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、方法。
37. 前記データブロック構造が、一定数のレーンを含み、また、それぞれのレーンが、同一の数のビットを含み、また、前記データブロック構造の前記第一セクションが、前記一定数のレーンの第一セットを含み、また、前記データブロック構造の前記第二セクションが、前記一定数のレーンの第二セットを含むことを特徴とする、請求項３６記載の方法。
38. 前記指標を受信する前記ステップが、前記第一セクションの最後のレーンに対応するレーン識別子を受信するステップ、を含むことを特徴とする、請求項３７記載の方法。
39. 前記指標を受信する前記ステップが、前記第二セクションの最初のレーンに対応するレーン識別子を受信するステップ、を含むことを特徴とする、請求項３７記載の方法。
40. 前記第二ソースデータ内のどこでブレイクポイントが発生することになるかを予測するステップ、をさらに含むことを特徴とする、請求項３７記載の方法。
41. 第一ソースからの第一ソースデータを、データブロック構造の第一セクション内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含み、また、前記データブロック構造内のデータが、コミュニケーションバス上に周期的に送出される、ステップと、
    第二ソースからの第二ソースデータが、前記コミュニケーションバスを介して送信可能であるかを判定するステップと、
    前記第二ソースデータを送信するために、前記コミュニケーションバスへのアクセスをリクエストするステップと、
    前記データブロック構造内のどこに、前記第二ソースデータの少なくとも一部を収めるべきかについての指標を受信するステップと、
    前記第二ソースデータのうちの前記少なくとも一部を、前記指標に従って、前記データブロック構造内に配置して、前記第二ソースデータのうちの前記少なくとも一部が、前記第一セクションの末尾に連続する前記データブロックの第二セクションを占めるようにするステップと、
    データブロック転送期間中に、前記コミュニケーションバスを介して、前記第一ソースデータと、前記第二ソースデータのうちの前記少なくとも一部とを送信するステップと、
    を含む方法であって、
    前記第一ソースデータを配置する前記ステップ、および、前記第二ソースデータのうちの前記少なくとも一部を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含む、方法、
    を実行するための、コンピュータ実行可能な命令を有する、コンピュータ読み取り可能媒体。
42. 第一ソースデータを、データブロック構造の第一セクション内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含む、ステップと、
    コミュニケーションバスを介して第二ソースデータを送信するためのリクエストを受信するステップと、
    前記第一ソースデータ内のブレイクポイントの位置を識別するステップと、
    前記第二ソースデータのうちの少なくとも一部を、前記ブレイクポイントの後の前記データブロック構造の第二セクション内に配置するステップであって、前記第二セクションが、前記第一セクションの末尾に連続する、ステップと、
    データブロック転送期間中に、前記第一ソースデータと、前記第二ソースデータのうちの前記少なくとも一部とを、前記コミュニケーションバスを介して送信するステップと、
    を含み、
    前記第一ソースデータを配置する前記ステップ、および、前記第二ソースデータのうちの少なくとも一部を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含むことを特徴とする、方法。
43. 前記データブロック構造が、一定数のレーンを含み、また、それぞれのレーンが、同一の数のビットを含み、また、前記データブロック構造の前記第一セクションが、前記一定数のレーンの第一セットを含み、また、前記データブロック構造の前記第二セクションが、前記一定数のレーンの第二セットを含むことを特徴とする、請求項４２記載の方法。
44. 前記位置を識別する前記ステップが、前記第一セクションの最後のレーンに対応するレーンを識別するステップ、を含むことを特徴とする、請求項４３記載の方法。
45. 前記位置を識別する前記ステップが、前記第二セクションの最初のレーンに対応するレーンを識別するステップ、を含むことを特徴とする、請求項４３記載の方法。
46. 第一ソースデータを、データブロック構造の第一セクション内に配置するステップであって、前記データブロック構造が、一定数の連続するコンフィギュラブルなビットを含む、ステップと、
    コミュニケーションバスを介して第二ソースデータを送信するためのリクエストを受信するステップと、
    前記第一ソースデータ内のブレイクポイントの位置を識別するステップと、
    前記第二ソースデータのうちの少なくとも一部を、前記ブレイクポイントの後の前記データブロック構造の第二セクション内に配置するステップであって、前記第二セクションが、前記第一セクションの末尾に連続する、ステップと、
    データブロック転送期間中に、前記第一ソースデータと、前記第二ソースデータのうちの前記少なくとも一部とを、前記コミュニケーションバスを介して送信するステップと、
    を含む方法であって、
    前記第一ソースデータを配置する前記ステップ、および、前記第二ソースデータのうちの少なくとも一部を配置する前記ステップは、ブレイクポイントの位置を予測するステップを含む、方法、
    を実行するための、コンピュータ実行可能な命令を有する、コンピュータ読み取り可能媒体。