JP4758384B2 - チケット・ベースの動作の追跡をサポートするデータを処理するためのデータ処理システムおよび方法 - Google Patents

Description

本発明は、概して、データ処理システムに関し、特に、データ処理システム用の改良形相互接続装置に関する。

サーバ・コンピュータ・システムのような従来の対称的マルチプロセッサ（ＳＭＰ）コンピュータ・システムは、通常１つまたは複数のアドレス、データおよび制御バスを備える、すべてがシステム相互接続と結合している複数の処理装置を含む。システム相互接続には、マルチプロセッサ・コンピュータ・システム内の最低レベルの揮発性メモリであり、通常すべての処理装置が読取り／書込みアクセスのためにアクセスすることができるシステム・メモリが結合している。システム・メモリ内の常駐する命令およびデータへのアクセス待ち時間を短縮するために、各処理装置は、通常、そのより低いレベルを１つまたは複数のプロセッサ・コアにより共有することができる各多重レベル・キャッシュ階層によりさらにサポートされている。

現在、ＳＭＰコンピュータ・システムは、種々のレベルのスケーラビリティを有する種々のシステム・アーキテクチャを使用している。従来のＳＭＰアーキテクチャのスケーラビリティに対する１つの制限は、システム全体を流れる動作（例えば、データ読取り要求、データ書込み要求、入出力要求等）を追跡するために使用しているキューの数である。一般的に、システムのスケールが大きくなるにつれて、動作を追跡するのに必要なキューの数および深さがリニア速度より速く増大する。
米国特許出願第１１／０５５，３０５号（米国特許公開第２００６０１７９２５２号） 米国特許出願第１１／０５４，８２０号（米国特許公開第２００６０１８７９３９号）

それ故、改良形データ処理システム、データ処理のための通信装置、および動作を追跡するために使用するキューの数を低減するデータを処理するための方法の開発が待望されている。

処理装置が動作することができるクロック周波数が高くなり、システムのスケールが増大してきているので、システム相互接続を介しての処理装置間の通信の待ち時間は、性能上の重要な問題になってきている。この性能上の問題を解決するために、従来のバスによる相互接続よりもさらに性能およびスケーラビリティを改善するための種々の相互接続設計が提案され／実施されてきた。

本発明は、データ処理システムにおける改良形データ処理システム、相互接続装置および通信方法を提供する。ある実施形態の場合には、データ処理システムは、処理装置のうちの複数の異なる処理装置間の通信のうちの少なくともいくつかが、複数の処理装置間の中間処理装置を介して送信されるように、ポイント・ツー・ポイント通信のための複数の通信リンクにより結合している複数の処理装置を含む。通信は、要求およびその要求へのシステム応答を表す結合応答を有する動作を含む。少なくとも各中間処理装置は、第１の動作を開始する１つまたは複数のマスタと、複数の処理装置のうちの少なくとも１つの他の処理装置が開始した少なくとも第２の動作を受信するスヌーパ（snooper）と、その処理装置内の１つまたは複数のマスタが開始した第１の動作のマスタ・タグを格納する物理キューと、中間処理装置のところで観察した第２の動作に、中間処理装置が観察した他の第２の動作に関する観察の順序を示すチケット番号を割り当てるチケット発行機構とを含む。チケット発行機構は、動作に割り当てられたチケット番号を、動作の結合応答により処理するためにスヌーパに提供する。

本発明のすべての目的、機能および利点は、下記の詳細な説明を読めば理解することができるだろう。

Ｉ．処理装置およびデータ処理システム
ここで図面、特に図１について説明するが、図１は、本発明による処理装置１００の例示としての実施形態のハイレベル・ブロック図である。図の実施形態の場合には、処理装置１００は、命令およびデータを別々に処理するための２つのプロセッサ・コア１０２ａ、１０２ｂを含む１つの集積回路である。各処理コア１０２は、実行のために命令を取り出し、順番に配置するための少なくとも１つの命令シーケンシング・ユニット（ＩＳＵ）１０４、および命令を実行するための１つまたは複数の実行ユニット１０６を含む。命令ユニット１０６により実行される命令としては、例えば、固定および浮動点演算命令、論理命令およびメモリ・ブロックへの読取りおよび書込みアクセスを要求する命令等がある。

各プロセッサ・コア１０２ａ、１０２ｂの動作は、その最低レベルのところに１つまたは複数の共有システム・メモリ１３２（図１には１つしか示していない）、およびその上のレベルのところに、１つまたは複数のレベルのキャッシュ・メモリを有する多重レベル揮発性メモリ階層によりサポートされている。図に示すように、処理装置１００は、プロセッサ・コア１０２ａ、１０２ｂから受信した要求に応じて、システム・メモリ１３２への読取りおよび書込みアクセスを制御し、スヌーパ１２６により（以下に説明するように）相互接続装置上にスヌープされた動作を制御する集積メモリ・コントローラ（ＩＭＣ）１２４を含む。

例示としての実施形態の場合には、処理装置１００のキャッシュ・メモリ階層は、各プロセッサ・コア１０２ａ、１０２ｂ内にレベル１（Ｌ１）キャッシュ１０８を通しての記憶装置、および処理装置１００のプロセッサ・コア１０２ａ、１０２ｂが共有するレベル２（Ｌ２）キャッシュ１１０を含む。Ｌ２キャッシュ１１０は、Ｌ２アレイおよびディレクトリ１１４、マスタ１１２およびスヌーパ１１６を含む。マスタ１１２は、関連するプロセッサ・コア１０２ａ、１０２ｂから受信したメモリ・アクセス（および他の）要求に応じて、相互接続装置上で処理を開始し、Ｌ２アレイおよびディレクトリ１１４にアクセスする。スヌーパ１１６は、相互接続装置上の動作を検出し、適当な応答を提供し、動作が要求するＬ２アレイおよびディレクトリ１１４への任意のアクセスを行う。図のキャッシュ階層は、２つのレベルのキャッシュしか含んでいないが、当業者であれば、他の実施形態は上のレベルのキャッシュの内容を全部含むことができ、その一部を含むことができ、または全然含んでいないオンチップまたはオフチップ・インラインまたはルックアサイド・キャッシュの追加のレベル（Ｌ３、Ｌ４等）を含むことができることを理解することができるだろう。

さらに図１に示すように、処理装置１００は、処理装置１００をより大きなデータ処理システムの一部として相互接続ファブリックに結合することができる集積相互接続ロジック１２０を含む。図の実施形態の場合には、相互接続ロジック１２０は、この場合にはインバウンドおよびアウトバウンドＸ、ＹおよびＺリンクを含む「第１の層」の相互接続リンクの任意の番号ｔ１をサポートする。相互接続ロジック１２０は、さらに、インバウンドおよびアウトバウンドＡおよびＢリンクとして、図１に示す第２の層リンクの任意の数ｔ２をサポートする。これらの第１および第２の層のリンクにより、ｔ１／２＋ｔ２／２（この場合は５）までの他の処理装置１００への二方向通信のために、各処理装置１００を結合することができる。相互接続ロジック１２０は、動作の異なるフェーズ中に情報を処理し転送するための、要求ロジック１２１ａ、部分応答ロジック１２１ｂ、結合応答ロジック１２１ｃおよびデータ・ロジック１２１ｄを含む。さらに、相互接続ロジック１２０は、処理装置１００を構成するために使用する複数のモード・ビットを含む構成レジスタ１２３を含む。以下にさらに詳細に説明するように、これらのモード・ビットは、好ましくは、（１）第１および第２の層のリンクのための所望のリンク情報割当てを選択する１つまたは複数のモード・ビットの第１の組と、（２）処理装置１００の第１および第２の層リンクのうちのどちらを他の処理装置１００に接続するのかを指定するモード・ビットの第２の組と、（３）保護ウィンドウ拡張のプログラム可能な期間を決定するモード・ビットの第３の組と、（４）上記米国特許出願第１１／０５５，３０５号に記載されているように、ノードだけのブロードキャスト範囲または全システム範囲の間から動作毎に処理装置１００が開始する動作のためのブロードキャスト範囲を予測して選択するモード・ビットの第４の組を含む。

各プロセッサ・ユニット１００は、さらに、処理装置１００のキャッシュ階層と他の処理装置１００のキャッシュ階層との間のキャッシュ・コヒーレンシを維持する分散型コヒーレンシ信号機構の一部を実施する応答ロジック１２２のインスタンスを含む。最後に、各処理装置１００は、入出力装置１３０のような１つまたは複数の入出力装置のアタッチメントをサポートしている集積Ｉ／Ｏ（入出力）コントローラ１２８を含む。入出力コントローラ１２８は、入出力装置１３０による要求に応じてＸ、Ｙ、Ｚ、ＡおよびＢリンク上で動作を発行し、データを受信することができる。

ここで図２を参照すると、この図は、本発明による複数の処理装置１００からなるデータ処理システム２００の例示としての実施形態のブロック図である。図に示すように、データ処理システム２００は、図の実施形態の場合にはそれぞれ４つの処理装置１００を含むパッケージを備える多重チップ・モジュール（ＭＣＭ）として実行されている８つの処理ノード２０２ａ０〜２０２ｄ０および２０２ａ１〜２０２ｄ１を含む。各処理ノード２０２内の処理装置１００は、図に示すように、処理装置Ｘ、Ｙ、およびＺリンクによりポイント・ツー・ポイント通信のために結合している。各処理装置１００は、さらに、処理装置ＡおよびＢリンクによるポイント・ツー・ポイント通信のために、２つの異なる処理ノード２０２内で処理装置１００に結合することができる。図２においては両方に矢尻のある矢印で示してあるが、Ｘ、Ｙ、Ｚ、ＡおよびＢの各対は、好ましくは（しかし、必ずしもそうである必要はないが）二方向リンクとしてではなく、２つの一方向リンクとして実施することを理解されたい。

図２のトポロジを形成するための一般的な表現は下記のようになる。
Ｎｏｄｅ［Ｉ］［Ｋ］．ｃｈｉｐ［Ｊ］．ｌｉｎｋ［Ｋ］ｃｏｎｎｅｃｔｓ ｔｏ Ｎｏｄｅ［Ｊ］［Ｋ］．ｃｈｉｐ［Ｉ］．ｌｉｎｋ［Ｋ］，（すべての１≠Ｊに対して）；ａｎｄ
Ｎｏｄｅ［Ｉ］［Ｋ］．ｃｈｉｐ［Ｉ］．ｌｉｎｋ［Ｋ］ｃｏｎｎｅｃｔｓ ｔｏ Ｎｏｄｅ［Ｉ］［ｎｏｔ Ｋ］．ｃｈｉｐ［Ｉ］．ｌｉｎｋ［ｎｏｔ Ｋ］；ａｎｄ
Ｎｏｄｅ［Ｉ］［Ｋ］．ｃｈｉｐ［Ｉ］．ｌｉｎｋ［ｎｏｔ Ｋ］ｃｏｎｎｅｃｔｓ ｅｉｔｈｅｒ ｔｏ：
（１）将来の拡張に対して何も予約しない；または
（２）Ｎｏｄｅ［ｅｘｔｒａ］［ｎｏｔ Ｋ］．ｃｈｉｐ［Ｉ］．ｌｉｎｋ［Ｋ］（すべてのリンクが完全に使用される（すなわち、７２方向システムを形成する９つの８方向ノード）の場合）；ａｎｄ
ここで、ＩおよびＪは、組｛ａ，ｂ，ｃ，ｄ｝に属し、Ｋは、組｛Ａ，Ｂ｝に属する。

もちろん、他の機能的に等価のトポロジを形成するために他の表現も定義することができる。さらに、図のトポロジは代表的なものであるが、本発明を実施するデータ処理システム・トポロジを網羅しているものではないこと、および他のトポロジも使用することができることを理解されたい。このような他のトポロジの場合には、例えば、各処理装置１００と結合する第１の層のリンクおよび第２の層のリンクの数は、任意の数であってもよいし、各層（すなわち、Ｉ）内の処理ノード２０２の数は、処理ノード１００（すなわち、Ｊ）毎の処理装置１００の数と等しくなくてもよい。

図２に示す方法で完全に接続していても、すべての処理ノード２０２は、各動作をすべての他の処理ノード２０２に通知する必要はない。より詳細に説明すると、すでに説明したように、処理装置１００は、その処理ノード２０２に限定した範囲で、またはすべての処理ノード２０２を含む全システム範囲のようなより広い範囲で動作をブロードキャストすることができる。

図３７に示すように、例えば、Ｌ２（またはより低いレベル）のキャッシュのスヌーパ１１６、またはＩＭＣ１２４のスヌーパ１２６のような、データ処理システム２００内の例示としてのスヌーピング・デバイス１９００は、スヌーピーング・デバイス１９００が責任を有する実アドレスを含む実アドレス空間の１つまたは複数の領域を識別する１つまたは複数のベース・アドレス・レジスタ（ＢＡＲ）１９０２を含むことができる。スヌーピーング・デバイス１９００は、そうしたい場合には、スヌーピーング・デバイス１９００がそのアドレスを担当するかどうかについてさらに資格を与えるために、ＢＡＲ１９０２が識別した実アドレス空間の領域に入る実アドレス上でハッシュ機能を実行するハッシュ・ロジック１９０４をさらに含むことができる。最後に、スヌーピーング・デバイス１９００は、ＢＡＲ１９０２およびハッシュ・ロジック１９０４が資格を与えた要求アドレスを指定するスヌープした要求に応じて、リソース１９１０（例えば、Ｌ２キャッシュ・アレイおよびディレクトリ１１４またはシステム・メモリ１３２）にアクセスする多数のスヌーパ１９０６ａ〜１９０６ｍを含む。

図に示すように、リソース１９１０は、それぞれが実際のアドレスの各組と関連する複数のバンク１９１２ａ〜１９１２ｎを含むバンクを含む構造を有することができる。当業者であれば周知のように、このようなバンクを含む設計は、リソース１９１０を複数の独立しているアクセス可能なリソースに効果的に再分割することにより、リソース１９１０に対する要求のより速い到着レートをサポートするために多くの場合使用される。このようにして、スヌーピーング・デバイス１９００またはリソース１９１０あるいはその両方の動作周波数が、このような要求の最大到着レートと同じ速度のリソース１９１０にアクセスするように要求にサービスすることができない場合でも、スヌーピーング・デバイス１９００は、所与の時間間隔内に任意のバンク１９１２に対して受信した要求の数がその時間間隔内にそのバンク１９１２がサービスを与えることができる要求の数を超えない限り、再試行を行わなくてもこのような要求にサービスを与えることができる。

当業者であれば、ＳＭＰデータ処理システム１００が、相互接続ブリッジ、不揮発性記憶装置、ネットワークまたは取り付けたデバイス等に接続するためのポートなどのような多くの追加の図示していない構成要素を含むことができることを理解することができるだろう。このような追加の構成要素は、本発明を理解するのに必要ではないので、これらの構成要素は、図２に示してないし、これ以上の説明は省略する。

ＩＩ．例示としての動作
ここで図３を参照すると、この図は、図２のデータ処理システム２００の相互接続ファブリック上の例示としての動作の時間空間図である。動作は、マスタ３００（例えば、Ｌ２キャッシュ１１０のマスタ１１２、または入出力コントローラ１２８内のマスタ）が、相互接続ファブリック上で要求３０２を発行した場合に開始する。好ましくは、要求３０２は、少なくとも所望のアクセスのタイプを示すトランザクション・タイプ、要求によりアクセスされるリソースを示すリソース識別子（例えば、実アドレス）を含む。好ましくは、要求の共通のタイプは、表Ｉに示すものを含む。

これら動作に関するこれ以上の詳細およびこれらの動作の効率的処理を容易にする例示としてのキャッシュ・コヒーレンシ・プロトコルについては、上記参照に記載されている米国特許公開第２００６０１７９２５２号を参照されたい。

要求３０２は、スヌーパ３０４、例えば、データ処理システム２００内に分散しているＬ２キャッシュ１１０のスヌーパ１１６およびＩＭＣ１２４のスヌーパ１２６により受信される。一般に、いくつかの例外はあるが、要求３０２のマスタ１１２としての同じＬ２キャッシュ１１０内のスヌーパ１１６は、要求３０２をスヌープしない（すなわち、一般に、自己スヌーピーングは行われない）。何故なら、要求３０２が処理装置１００により内部でサービスを受けることができない場合には、要求３０２は相互接続装置だけにより送信されるからである。要求３０２を受信し処理するスヌーパ３０４は、それぞれ要求３０２への少なくともそのスヌーパ３０４の応答を表す各部分応答３０６を提供する。ＩＭＣ１２４内のスヌーパ１２６は、例えば、スヌーパ１２６が要求アドレスを担当しているかどうか、およびスヌーパ１２６が要求にサービスするために使用することができるリソースを有しているかどうかに基づいて提供する部分応答３０６を決定する。Ｌ２キャッシュ１１０のスヌーパ１１６は、例えば、そのＬ２キャッシュ・ディレクトリ１１４の利用度、要求を処理するためのスヌーパ１１６内のスヌープ・ロジック・インスタンスの利用度、およびＬ２キャッシュ・ディレクトリ１１４内の要求アドレスに関連するコヒーレンシ状態に基づいてその部分応答３０６を決定することができる。

スヌーパ３０４の部分応答３０６は、要求３０２に対する結合応答（ＣＲ）３１０を決定するために、応答ロジック１２２の１つまたは複数のインスタンスにより、いくつかのフェーズでまたはすべて直ちに論理的に結合される。以後引用する１つの好ましい実施形態の場合には、結合応答３１０の発生を担当する応答ロジック１２２のインスタンスは、要求３０２を発行したマスタ３００を含む処理装置１００内に位置する。応答ロジック１２２は、要求３０２への応答（例えば、成功、失敗、再試行等）を示すために、相互接続ファブリックを介してマスタ３００およびスヌーパ３０４に結合応答３１０を提供する。ＣＲ３１０が要求３０２の成功を示している場合には、ＣＲ３１０は、例えば、要求されたメモリ・ブロックのデータ・ソース、要求したメモリ・ブロックがマスタ３００によりキャッシュされるキャッシュ状態、１つまたは複数のＬ２キャッシュ１１０内で要求したメモリ・ブロックを無効にする「クリーンアップ」動作が必要であるかどうかを示すことができる。

結合応答３１０を受信した場合には、１つまたは複数のマスタ３００およびスヌーパ３０４は、通常、要求３０２にサービスするために１つまたは複数の動作を行う。これらの動作は、マスタ３００にデータを供給すること、１つまたは複数のＬ２キャッシュ１１０内にキャッシュしたデータのコヒーレンシ状態を無効にするか、または更新すること、キャストアウト動作を行うこと、システム・メモリ１３２にデータを書き戻すことなどを含むことができる。要求３０２により要求された場合、要求されたまたは目標メモリ・ブロックを応答ロジック１２２による結合応答３１０の発生の前または後で、マスタ３００へまたはから送信することができる。

以下の説明においては、要求３０２へのスヌーパ３０４の部分応答３０６、および要求３０２またはその結合応答３１０あるいはその両方に応じてスヌーパ３０４が行った動作について、そのスヌーパが、要求が指定した要求アドレスに対して最高コヒーレンシ点（ＨＰＣ）であるか、最低コヒーレンシ点（ＬＰＣ）であるか、またはいずれでもないかを参照しながら説明する。本明細書においては、ＬＰＣは、メモリ・ブロックのリポジトリとして働くメモリ・デバイスまたは入出力装置として定義される。メモリ・ブロックに対するＨＰＣが存在しない場合には、ＬＰＣはメモリ・ブロックの真のイメージを保持し、メモリ・ブロックの追加のキャッシュ・コピーを発生する要求を許可または拒否する権限を有する。図１および図２のデータ処理システムの実施形態の典型的な要求の場合には、ＬＰＣは、参照したメモリ・ブロックを保持しているシステム・メモリ１３２に対するメモリ・コントローラ１２４である。本明細書においては、ＨＰＣは、メモリ・ブロックの真のイメージをキャッシュする一意に識別されたデバイスとして定義され（ＬＰＣのところの対応するメモリ・ブロックと一致していてもまたは一致していなくてもよい）、メモリ・ブロックを修正する要求を許可または拒否する権限を有する。説明すると、ＨＰＣは、また、メモリ・ブロックを修正しない動作に応じて要求者にメモリ・ブロックのコピーを提供することができる。それ故、図１および図２のデータ処理システムの実施形態の典型的な要求の場合には、ＨＰＣは、もしある場合には、Ｌ２キャッシュ１１０であってもよい。メモリ・ブロックのＨＰＣを指定するために他のインジケータも使用することができるが、本発明の好ましい実施形態は、もしあった場合、メモリ・ブロックに対するＨＰＣをＬ２キャッシュ１１０のＬ２キャッシュ・ディレクトリ１１４内の選択したキャッシュ・コヒーレンシ状態により示す。

引き続き図３を参照すると、要求３０２内で参照したメモリ・ブロックに対するＨＰＣがもし存在する場合には、またはＨＰＣが存在しない場合には、好ましくは、メモリ・ブロックのＬＰＣは、必要な場合には、要求３０２への応答内のメモリ・ブロックの所有権の移転を保護する責任を有する。図３の例示としてのシナリオの場合には、要求３０２の要求アドレスが指定するメモリ・ブロックに対するＨＰＣのところのスヌーパ３０４ｎ（またはＨＰＣが存在しない場合には、ＬＰＣ）は、スヌーパ３０４ｎがその部分応答３０６を決定した時点からスヌーパ３０４ｎが結合応答３１０を受信するまで継続する保護ウィンドウ３１２ａの間、およびスヌーパ３０４ｎによる結合応答３１０の受信を超えてプログラム可能な時間が延びる以降のウィンドウ延長部３１２ｂの間、マスタ３００への要求されたメモリ・ブロックの所有権の移転を保護する。保護ウィンドウ３１２ａおよびウィンドウ延長部３１２ｂの間、スヌーパ３０４ｎは、マスタ３００への所有権の移転が成功するまで、所有権（例えば、再試行部分応答）を他のマスタが入手するのを防止する同じ要求アドレスを指定している他の要求に部分応答３０６を提供することにより、所有権の移転を保護する。マスタ３００は、同様に、結合応答３１０を受信した後で要求３０２で要求されたメモリ・ブロックのその所有権を保護するために、保護ウィンドウ３１３を開始する。

スヌーパ３０４はいずれも、ＣＰＵおよび上記入出力要求を処理するためのリソースは限られたものであるので、いくつかの異なるレベルの部分応答および対応するＣＲが可能である。例えば、要求されたメモリ・ブロックを担当するメモリ・コントローラ１２４内のスヌーパ１２６が、要求を処理するために使用することができるキューを有する場合には、スヌーパ１２６は、要求に対してＬＰＣとして働くことができることを示す部分応答で応答することができる。一方、スヌーパ１２６が要求を処理するために使用することができるキューを有していない場合には、スヌーパ１２６は、メモリ・ブロックに対するＬＰＣであることを示す部分応答で応答することができるが、現時点で要求にサービスすることはできない。同様に、Ｌ２キャッシュ１１０内のスヌーパ１１６は、要求を処理するためにスヌーパ・ロジックの使用することができるインスタンスを要求することができ、Ｌ２キャッシュ・ディレクトリ１１４にアクセスすることができる。これらリソースの一方（または両方）にアクセスしない場合には、必要なリソースがないために要求にサービスすることができないことを知らせる部分応答（および対応するＣＲ）になる。

ＩＩＩ．例示としての動作のブロードキャストの流れ
ここで図６〜図８のところでも説明する図４を参照すると、この図は、図２のデータ処理システム２００内の全システムの範囲の動作の例示としての動作の流れの時間空間図である。これらの図面中、データ処理システム２００内の種々の処理装置１００には、２つの位置識別子、すなわち、処理装置１００が属する処理ノード２０２を識別するための第１の位置識別子、および処理ノード２０２内の特定の処理装置１００を識別するための第２の位置識別子がついている。それ故、例えば、処理装置１００ａ０ｃは、処理ノード２０２ａ０の処理装置１００ｃを示す。さらに、各処理装置１００には、動作に参加する他の処理装置１００に対するその機能を示す機能識別子がつけてある。これらの機能識別子としては、（１）動作を開始する処理装置１００であるローカル・マスタ（ＬＭ）、（２）ローカル・マスタと同じ処理ノード２０２であり、他の処理ノード２０２への動作の送信を担当する処理装置１００であるローカル・ハブ（ＬＨ）（ローカル・マスタはローカル・ハブであってもよい）、（３）ローカル・マスタ以外の処理ノード２０２内に位置していて、その処理ノード２０２内の他の処理装置１００への動作の分散を担当する処理装置１００であるリモート・ハブ（ＲＨ）、（４）ローカル・マスタとは異なる処理ノード２２０内に位置していて、リモート・ハブではない処理装置１００であるリモート・リーフ（ＲＬ）などがある。

図４に示すように、図３のところですでに説明したように、例示としての動作は、少なくとも３つのフェーズ、すなわち、要求（またはアドレス）フェーズ、部分応答（Ｐｒｅｓｐ）フェーズ、および結合応答（Ｃｒｅｓｐ）フェーズを有する。好ましくは、これらの３つのフェーズは、上記順序で行われ、重ならない。動作は、さらにそうしたい場合には、要求、部分応答および結合応答フェーズのうちのいずれかと重なることができるデータフェーズを有することができる。

さらに図４および図６を参照すると、要求フェーズは、ローカル・マスタ１００ａ０ｃ（すなわち処理ノード２０２ａ０の処理装置１００ｃ）が、例えば、読取り要求のような要求を、その処理ノード２０２ａ０内のローカル・ハブ１００ａ０ａ、１００ａ０ｂ、１００ａ０ｃおよび１００ａ０ｄそれぞれに同期ブロードキャストした場合に開始する。ローカル・ハブのリストが、また、ローカル・マスタであるローカル・ハブ１００ａ０ｃを含むことに留意されたい。以下にさらに詳細に説明するように、この内部送信は、以下に説明するタイミング制約がもっと容易に満たされるように、ローカル・ハブ１００ａ０ｃの動作をローカル・ハブ１００ａ０ａ、１００ａ０ｂおよび１００ａ０ｄと同期させるために有利に使用される。

要求を受信した場合、そのＡまたはＢリンクによりリモート・ハブ１００と結合している各ローカル・ハブ１００は、動作をそのリモート・ハブ１００に送信する。それ故、ローカル・ハブ１００ａ０ａは、そのアウトバウンドＡリンクにより動作を送信しないで、そのアウトバウンドＢリンクを介して処理ノード２０２ａ１内のリモート・ハブに動作を送信する。ローカル・ハブ１００ａ０ｂ、１００ａ０ｃおよび１００ａ０ｄは、それぞれ各アウトバウンドＡおよびＢリンクを介して、処理ノード２０２ｂ０および２０２ｂ１、処理ノード２０２ｃ０および２０２ｃ１、および処理ノード２０２ｄ０および２０２ｄ１内のリモート・ハブに動作を送信する。動作を受信する各リモート・ハブ１００は、順次、その処理ノード２０２内の各リモート・リーフ１００に動作を送信する。それ故、例えば、ローカル・ハブ１００ｂ０ａは、リモート・リーフ１００ｂ０ｂ、１００ｂ０ｃおよび１００ｂ０ｄに動作を送信する。このようにして、動作は、３つ以下のリンクによる送信によりデータ処理システム２００内のすべての処理装置１００に効率的にブロードキャストされる。

図４および図７に示すように、要求フェーズの後で、部分応答（Ｐｒｅｓｐ）フェーズが行われる。部分応答フェーズ中に、各リモート・リーフ１００は、動作を評価し、動作へのその部分応答をその各リモート・ハブ１００に提供する。例えば、リモート・リーフ１００ｂ０ｂ、１００ｂ０ｃおよび１００ｂ０ｄは、その各部分応答をリモート・ハブ１００ｂ０ａに送信する。各リモート・ハブ１００は、順次、ローカル・ハブ１００ａ０ａ、１００ａ０ｂ、１００ａ０ｃおよび１００ａ０ｄそれぞれに、その部分応答およびそれ自身の部分応答を送信する。次に、ローカル・ハブ１００ａ０ａ、１００ａ０ｂ、１００ａ０ｃおよび１００ａ０ｄは、処理ノード２０２ａ０内の各ローカル・ハブ１００に、これらの部分応答およびそれ自身の部分応答をブロードキャストする。図７により、処理ノード２０２ａ０内のローカル・ハブ１００による部分応答のブロードキャストは、タイミングの理由で、それ自身の部分応答の各ローカル・ハブ１００による自己ブロードキャストを含むことに留意されたい。

理解していただけると思うが、図の方法による部分応答の収集は、多数の異なる方法により実施することができる。例えば、個々の部分応答を、他の各ローカル・ハブ、リモート・ハブおよびリモート・リーフから各ローカル・ハブに返送することができる。別の方法としては、より効率的にするために、部分応答がローカル・ハブに返送された場合に、部分応答を蓄積することが望ましい場合がある。各部分応答の効果が、確実に正確にローカル・ハブ１００に返送されるようにするためには、好ましくは、例えば、論理ＯＲ機能、および機能（例えば、「ワンホット（one hot）」暗号化）を適用した場合に、関連情報が喪失しない暗号化により、非破壊的方法で、もしある場合、部分応答を蓄積する。

さらに図４および図８に示すように、処理ノード２０２ａ０内の各ローカル・ハブ１００のところの応答ロジック１２２は、要求への全システム応答を示す結合応答を入手するために、他の処理装置１００の部分応答をコンパイルする。次に、ローカル・ハブ１００ａ０ａ〜１００ａ０ｄは、要求フェーズの際に使用したのと同じ分散経路を通して、すべての処理装置１００に結合応答をブロードキャストする。それ故、結合応答は、リモート・ハブ１００への最初のブロードキャストであり、リモート・ハブ１００は、その各処理ノード２０２内の各リモート・リーフ１００に結合応答を送信する。例えば、リモート・ハブ１００ａ０ｂは、リモート・ハブ１００ｂ０ａに結合応答を送信し、リモート・ハブ１００ｂ０ａは、リモート・リーフ１００ｂ０ｂ、１００ｂ０ｃおよび１００ｂ０ｄに結合応答を送信する。

すでに説明したように、動作のサービスは、図９または図１０に示すような追加のデータ・フェーズを必要とする場合がある。例えば、図９に示すように、動作が読取りまたはＲＷＩＴＭ動作のような読取りタイプの動作である場合には、リモート・リーフ１００ｂ０ｄは、リモート・リーフ１００ｂ０ｄをリモート・ハブ１００ｂ０ａに、リモート・ハブ１００ｂ０ａをローカル・ハブ１００ａ０ｂに、ローカル・ハブ１００ａ０ｂをローカル・マスタ１００ａ０ｃに接続しているリンクを介して、ローカル・マスタ１００ａ０ｃに要求されたメモリ・ブロックの出所を明示することができる。逆に、動作が、例えば、修正したメモリ・ブロックをリモート・リーフ１００ｂ０ｂのシステム・メモリ１３２にライトバックするキャッシュ・キャストアウト動作のような書込みタイプの動作である場合には、図１０に示すように、ローカル・マスタ１００ａ０ｃをローカル・ハブ１００ａ０ｂに、ローカル・ハブ１００ａ０ｂをリモート・ハブ１００ｂ０ａに、リモート・ハブ１００ｂ０ａをリモート・リーフ１００ｂ０ｂに接続しているリンクを介してメモリ・ブロックが送信される。

ここで図５を参照すると、この図は、図２のデータ処理システム２００内のノードだけの範囲の動作の例示としての動作の流れの時間空間図である。この図の場合、データ処理システム２００内の種々の処理装置１００には、２つの位置識別子、すなわち、処理装置１００が属する処理ノード２０２を識別するための第１の位置識別子、および処理ノード２０２内の特定の処理装置１００を識別するための第２の位置識別子がついている。それ故、例えば、処理装置１００ｂ０ａは、処理ノード２０２ｂ０の処理装置１００ｂを示す。さらに、各処理装置１００には、動作に参加する他の処理装置１００に対するその機能を示す機能識別子がつけてある。これらの機能識別子としては、（１）ノードだけの範囲の動作を開始する処理装置１００であるノード・マスタ（ＮＭ）、（２）ノード・マスタと同じ処理ノード２０２内にあり、ノード・マスタではない処理装置１００であるノード・リーフ（ＮＬ）等がある。

図５に示すように、すでに説明したように、例示としてのノードだけの動作は少なくとも３つのフェーズ、すなわち、要求（またはアドレス）フェーズ、部分応答（Ｐｒｅｓｐ）フェーズ、および結合応答（Ｃｒｅｓｐ）フェーズを有する。この場合も、これらの３つのフェーズは、上記順序で行われ、重ならないことが好ましい。動作は、さらにそうしたい場合には、要求、部分応答および結合応答フェーズのうちのいずれかと重なることができるデータ・フェーズを有することができる。

さらに図５を参照すると、要求フェーズは、図４の動作シナリオ内のリモート・ハブと非常によく似た働きをするノード・マスタ１００ｂ０ａ（すなわち処理ノード２０２ｂ０の処理装置１００ａ）が、例えば、読取り要求のような要求を、その処理ノード２０２ｂ０内のノード・リーフ１００ｂ０ｂ、１００ｂ０ｃおよび１００ｂ０ｄそれぞれに同期ブロードキャストした場合に開始する。ブロードキャスト送信の範囲が１つのノードに限定されているために、要求のオフ・ノード送信を同期させるために、ノード・マスタ１００ｂ０ａ内で要求の内部送信が使用されないことに留意されたい。

図５に示すように、要求フェーズの後で、部分応答（Ｐｒｅｓｐ）フェーズが行われる。部分応答フェーズ中に、各ノード・リーフ１００ｂ０ｂ、１００ｂ０ｃ、および１００ｂ０ｄは、動作を評価し、動作へのその部分応答をノード・マスタ１００ｂ０ａに提供する。次に、さらに図５に示すように、処理ノード２０２ｂ０内のノード・マスタ１００ｂ０ａのところの応答ロジック１２２は、要求への全ノード応答を示す結合応答を入手するために、他の処理装置１００の部分応答をコンパイルする。次に、ノード・マスタ１００ｂ０ａは、ノード・マスタ１００ｂ０ａのＸ、ＹおよびＺリンクにより、すべてのノード・リーフ１００ｂ０ｂ、１００ｂ０ｃおよび１００ｂ０ｄに結合応答をブロードキャストする。

すでに説明したように、動作のサービスは、追加のデータ・フェーズを必要とする場合がある。例えば、動作が読取りまたはＲＷＩＴＭ動作のような読取りタイプの動作である場合には、ノード・リーフ１００ｂ０ｄは、ノード・リーフ１００ｂ０ｄをノード・マスタ１００ｂ０ａに接続しているＺリンクを介して、ノード・マスタ１００ｂ０ａに要求されたメモリ・ブロックの出所を明示することができる。逆に、動作が、例えば、修正したメモリ・ブロックをリモート・リーフ１００ｂ０ｂのシステム・メモリ１３２にライトバックするキャッシュ・キャストアウト動作のような書込みタイプの動作である場合には、ノード・マスタ１００ｂ０ａをノード・リーフ１００ｂ０ｂに接続しているＸリンクを介してメモリ・ブロックが送信される。

もちろん、図４、図６〜図１０および図５に示す２つの動作は、データ処理システム２００のようなマルチプロセッサ・データ処理システムで同時に行うことができる無数の可能な全システムおよびノードだけの動作の単に例示としてのものに過ぎない。

ＩＶ．タイミング考慮事項
図３のところですでに説明したように、保護ウィンドウ３１２ａ、ウィンドウ拡張部３１２ｂ、および保護ウィンドウ３１３を通して、同じメモリ・ブロックの所有権を競合する他のマスタが存在する可能性がある場合には、スヌーパ３０４ｎから要求しているマスタ３００にメモリ・ブロックのコヒーレンシ所有権の「ハンドオフ」の間、コヒーレンシが維持される。例えば、図１１に示すように、保護ウィンドウ３１２ａおよびウィンドウ拡張部３１２ｂの両方は、競合するマスタ（ＣＭ）３２０による競合する要求３２２の存在下で、スヌーパ３０４ｎからウィニング・マスタ（ＷＭ）３００に要求されたメモリ・ブロックのコヒーレンシ所有権の移転を保護するのに十分な持続時間を有するものでなければならない。保護ウィンドウ３１２ａおよびウィンドウ拡張部３１２ｂが、スヌーパ３０４ｎからウィニング・マスタ３００へ要求されたメモリ・ブロックの所有権の移転を保護するための十分長い持続時間を確保することができるように、好ましくは、図４および図５の処理装置１００間の通信の待ち時間は、下記の条件が満たされるように制約する。
Ａ＿ｌａｔ（ＣＭ＿Ｓ）≦Ａ＿ｌａｔ（ＣＭ＿ＷＭ）＋Ｃ＿ｌａｔ（ＷＭ＿Ｓ）＋ε
ここで、Ａ＿ｌａｔ（ＣＭ＿Ｓ）は、要求されたメモリ・ブロックのコヒーレンスを所有するスヌーパ（Ｓ）３０４ｎへの任意の競合マスタ（ＣＭ）３２０のアドレス待ち時間であり、Ａ＿ｌａｔ（ＣＭ＿ＷＭ）は、スヌーパ３０４ｎにより与えられたコヒーレンシ所有権である「ウィニング」マスタ（ＷＭ）３００への任意の競合マスタ（ＣＭ）３２０のアドレス待ち時間であり、Ｃ＿ｌａｔ（ＷＭ＿Ｓ）は、ウィニング・マスタ（ＷＭ）３００が結合応答を受信した時間から、要求したメモリ・ブロックを所有するスヌーパ（Ｓ）３０４ｎが結合応答を受信した時間までの結合応答待ち時間であり、εはウィンドウ拡張部３１２ｂの持続時間である。

任意のトポロジのシステムに適用することができる上記タイミング制約を満たさない場合には、競合マスタ３２０の要求３２２を（１）ウィニング・マスタ３００がコヒーレンシ所有権を入手し、保護ウィンドウ３１２ｂを開始する前に、ウィニング・マスタ３００により、（２）保護ウィンドウ３１２ａおよびウィンドウ拡張部３１２ｂが終了した後でスヌーパ３０４ｎにより受信することができる。このような場合、ウィニング・マスタ３００もスヌーパ３０４ｎも、競合マスタ３２０がメモリ・ブロックのコヒーレンシ所有権を入手し、コヒーレントでないデータをメモリから読み取るのを防止する部分応答を競合要求３２２に提供しない。しかし、このコヒーレンシ・エラーを避けるために、ウィンドウ拡張部３１２ｂは、待ち時間の変動、またはコヒーレンシを維持するために満たさなければならないタイミング制約をそうでなければ満たすことができないかもしれない物理的実施態様の欠点を補償するために、（例えば、構成レジスタ１２３を適当に設定することにより）任意の長さ（ε）にプログラムすることができるように設定することができる。それ故、εについての上式を解くことにより、任意の実施態様に対するウィンドウ延長部３１２ｂの理想的な長さを決定することができる。図２のデータ処理システムの実施形態の場合には、好ましくは、εは複数の処理ノード２０２を含む範囲を有するブロードキャスト動作のための１つの第１の層のリンクのチップ・ホップの待ち時間に等しい持続時間を有し、ノードだけの範囲の動作に対してゼロの持続時間を有する。

上記タイミング制約についていくつかの観察をすることができる。第一に、競合マスタ３２０から所有するスヌーパ３０４ａへのアドレス待ち時間は、必要な下限を有していないが上限を持たなければならない。上限は、とりわけ、達成することができる最悪の場合の待ち時間を決定することにより、可能な最大オッシレータ・ドリフト、処理装置１００に結合している最長のリンク、蓄積したストールの最大数、および保証された最悪の場合のスループットに対して設計される。上限が確実に観察されるように、相互接続ファブリックはブロックを起こさない行動を確保しなければならない。

第二に、競合マスタ３２０からウィニング・マスタ３００へのアドレス待ち時間は、必要な上限を有していないが下限を持たなければならない。下限は、とりわけ達成することができる最善の場合の待ち時間により、特定の静的構成の場合の、ストールがない場合、処理装置１００間の可能な最短リンク、および最も遅いオッシレータ・ドリフトに対して決定される。

所与の動作の場合、各ウィニング・マスタ３００および競合マスタ３２０は、その各要求に対して１つのタイミング限界だけを有しているが、動作中、任意の処理装置１００は、いくつかの動作のためのウィニング・マスタであってもよく、他の動作のための競合（およびルージング）マスタであってもよいことを理解することができるだろう。それ故、各処理装置１００は、そのアドレス待ち時間に対して上限および下限を効果的に有する。

第三に、結合応答が発生した時間からウィニング・マスタ３００により結合応答が観察された時間までの結合応答待ち時間は、必要な下限を持たないが（結合応答は、任意の早い時点でウィニング・マスタ３００のところに到着することができる）、上限を持たなければならない。対照的に、結合応答が発生した時間からスヌーパ３０４ｎが結合応答を受信した時間までの結合応答待ち時間は、下限を有しているが必要な上限を有していない（しかし、フライト中に同時に行われる動作の回数を制限するために、ある上限を任意に課することができる）。

第四に、部分応答待ち時間には制限がない。すなわち、上に列挙したタイミング制約のすべての項は、要求／アドレス待ち時間および結合応答待ち時間に関連しているので、ウィニング・マスタ３００へのスヌーパ３０４および競合マスタ３２０の部分応答待ち時間は、必要な上限または下限を持たない。

Ｖ．例示としてのリンク情報割当て
処理装置１００を接続している第１の層および第２の層のリンクは、図２のトポロジを入手し、図１１のタイミング制約に適合するための種々の方法により実施することができる。１つの好ましい実施形態の場合には、各インバウンドおよびアウトバウンドの第１の層（Ｘ、ＹおよびＺ）リンクおよび各インバウンドおよびアウトバウンドの第２の層（ＡおよびＢ）リンクは、アドレス、データ、制御およびコヒーレンシ情報を運ぶための多数の異なる仮想チャネルまたは保有期間を含む一方向８バイト・バスとして実施される。

ここで図１２〜図１３を参照すると、これらの図は、第１の層のＸ、ＹおよびＺリンクおよび第２の層のＡおよびＢリンクに対する第１の例示としてのタイム・スライスした情報割当てを示す。図に示すように、この第１の実施形態の場合には、第１の４サイクルが２つのアドレス保有期間トランスポート・アドレス、コヒーレンシおよび制御情報を有し、第２の４サイクルがデータ・トランスポートを行うデータ保有期間専用のサイクルである８サイクル・フレームを反復する際に、第１および第２の層のリンク上で情報が割り当てられる。

最初に図１２を参照すると、この図は、第１の層のリンクに対するリンク情報割当てを示す。サイクル数モジュロ８が０である各サイクル中に、バイト０は、第１の動作のトランザクション・タイプ７００ａ（例えば、読取り）を送り、バイト１〜５は、第１の動作の要求アドレスの５つの低いアドレス・バイト７０２ａ１を提供し、バイト６〜７は予約フィールド７０４を形成する。次のサイクル（すなわち、サイクル数モジュロ８が１であるサイクル）中には、バイト０〜１は第１の動作（例えば、Ｌ２キャッシュ・マスタ１１２のうちの１つまたは入出力コントローラ１２８内のマスタ）のマスタ３００を識別するマスタ・タグ７０６ａを送り、バイト２は第１の動作の要求アドレスの高いアドレス・バイト７０２ａ２を送る。第１の動作に関連するこの情報と一緒に、異なる動作、すなわち同じ処理ノード２０２内のローカル・マスタ宛のローカル部分応答７０８ａ（バイト３〜４）、バイト５の結合応答７１０ａ、および異なる処理ノード２０２のローカル・マスタ宛のリモート部分応答７１２ａ（またはノードだけのブロードキャストの場合には、ノード・リーフ１００からノード・マスタ１００へ送られた部分応答）（バイト６〜７）に関連する最大３つの追加フィールドが送られる。これらの第１の２つのサイクルは、本明細書においては、アドレス保有期間と呼ばれるものを形成する。

さらに図１２に示すように、次の２つのサイクル（すなわち、サイクル数モジュロ８が２および３であるサイクル）が、第１のアドレス保有期間と同じ基本パターンを有する第２のアドレス保有期間を形成する。例外は予約フィールド７０４がデータ保有期間の一部を形成するデータ・タグ７１４およびデータ・トークン７１５で置換されていることである。より詳細に説明すると、データ・タグ７１４は、サイクル４〜７に含まれている３２バイトのデータ・ペイロード７１６ａ〜７１６ｄが送られる宛先データ・シンクを識別する。ペイロード・データの直前に位置するアドレス保有期間内のその位置により、ペイロード・データを受信する前に下流のステアリングを有利に構成することができ、そのため指定のデータ・シンクに向けてデータを効率的に経路指定することができる。データ・トークン７１５は、下流のキュー・エントリが解放され、その結果、オーバーランの危険なしでペアのＸ、Ｙ、ＺまたはＡリンクにより追加のデータを送信することができることを示す表示を提供する。この場合も、トランザクション・タイプ７００ｂ、マスタ・タグ７０６ｂ、低アドレス・バイト７０２ｂ１および高アドレス・バイト７０２ｂ２は、すべて第２の動作に関連し、データ・タグ７１４、ローカル部分応答７０８ｂ、結合応答７１０ｂおよびリモート部分応答７１２ｂは、すべて第２の動作以外の１つまたは複数の動作に関連することに留意されたい。

好ましくは、各トランザクション・タイプ・フィールド７００および結合応答フィールド７１０は、それが属する動作がノードだけ（ローカル）のまたは全システム（グローバル）の範囲を有しているかどうかを示す範囲インジケータ７３０を含む。上記相互参照の米国特許公開第２００６０１７９２５２号に詳細に記載されているように、データ・タグ７１４は、さらに、データ・ペイロード７１６ａ〜７１６ｄ内に含まれているデータのリモート・コピーが存在するかどうかを示すために、ＬＰＣにより設定することができるドメイン・インジケータ７３２を含む。

図１３は、第２の層のＡおよびＢリンクに対するリンク情報の割当てを示す。図１２と比較すると分かるように、第２の層のＡおよびＢリンク上でのリンク情報の割当ては、図１２の第１の層のリンクに対するものと同じである。例外は、ローカル部分応答フィールド７０８ａ、７０８ｂが予約フィールド７１８ａ、７１８ｂにより置換されていることである。この置換を行ったのは、第２の層のリンクとして、ローカル部分応答を送る必要がないという簡単な理由によるものである。

図１４は、書込み要求に応じて、ローカル部分応答フィールド７０８ａ、７０８ｂまたはリモート部分応答フィールド７１２ａ、７１２ｂ内にトランスポートすることができる書込み要求部分応答７２０の例示としての実施形態である。図に示すように、書込み要求部分応答７２０は、長さが２バイトで、書込みデータの宛先であり、宛先タグ・フィールド７２４の有効性を示すための１ビット有効（Ｖ）フラグ７２２の宛先であるスヌーパ（例えば、ＩＭＣスヌーパ１２６）のタグを指定するための１５ビット宛先タグ・フィールド７２４を含む。

ここで図１５〜図１６を参照すると、これらの図は、第１の層のＸ、ＹおよびＺリンク、および第２の層のＡリンクに対する第２の例示としてのサイクル状の情報割当てを示す。図に示すように、この第２の実施形態の場合には、第１の２サイクルが、アドレスを含むアドレス・フレーム、コヒーレンシおよび制御情報を有し、第２の４サイクルがデータトランスポート専用のサイクルである６サイクル・フレームを反復する際に、第１および第２の層のリンク上で情報が割り当てられる。図１５〜図１６の実施形態の保有期間は、図１２〜図１３のサイクル２〜７の保有期間と同じであるので、ここではこれ以上の説明は省略する。書込み要求の場合には、ローカル部分応答フィールド８０８およびリモート部分応答フィールド８１２内に送られた部分応答は、図１４の書込み要求の部分応答７２０の形をとることができる。

当業者であれば、図１２〜図１３および図１５〜図１６の実施形態は、非常に多くの可能なリンク情報割当てのうちの２つだけを示していることを理解することができるだろう。実施する選択したリンク情報割当ては、例えば、図１の構成レジスタ１２３内のハードウェアまたはソフトウェアあるいはその両方の設定可能モード・ビットによりプログラムすることができるようにすることができる。リンク情報割当ての選択は、通常、予想される作業量のタイプのような１つまたは複数の要因に基づいて行われる。例えば、データ処理システム２００において科学的作業量が圧倒的に多い場合には、一般に、データ・ペイロードへの第１および第２の層のリンク上により広い帯域幅を割り当てるのがより好ましい。それ故、図１５〜図１６の第２の実施形態は、性能が改善される可能性が高い。逆に、データ処理システム２００において商業的作業量が圧倒的に多い場合には、一般に、アドレス、コヒーレンシおよび制御情報により広い帯域幅を割り当てるのがより好ましい。この場合、図１２〜図１３の第１の実施形態は、より高い性能をサポートする。予想される作業量のタイプの決定、および構成レジスタ１２３の設定は、人間のオペレータにより行うことができるが、決定を自動的にハードウェアまたはソフトウェアあるいはその両方により行うのが有利である。例えば、一実施形態の場合には、作業量のタイプの決定は、１つまたは複数の処理装置１００または専用補助サービス・プロセッサ（図示せず）上で実行されるサービス・プロセッサ・コードにより行うことができる。

ＶＩ．要求フェーズの構造および動作
ここで図１７を参照すると、この図は、動作の要求フェーズ処理の際に使用する図１の相互接続ロジック１２０内の要求ロジック１２１ａを示すブロック図である。図に示すように、要求ロジック１２１ａは、処理装置１００のマスタ３００（例えば、Ｌ２キャッシュ１１０内のマスタ１１２および入出力コントローラ１２８内のマスタ）により、要求を受信するように結合しているマスタ・マルチプレクサ９００を含む。マスタ・マルチプレクサ９００の出力は、要求マルチプレクサ９０４の１つの入力となる。要求マルチプレクサ９０４の第２の入力は、保持バッファ９０２ａ、９０２ｂの出力と結合しているその入力を有するリモート・ハブ・マルチプレクサ９０３の出力と結合している。保持バッファは、それぞれインバウンドＡおよびＢリンク上の受信およびバッファ要求と結合している。リモート・ハブ・マルチプレクサ９０３は、以下にさらに詳細に説明する、保持バッファ９０２ａ〜９０２ｂ内にバッファされるインバウンドＡおよびＢリンクから受信した要求の中から公平に選択する公平な割当てポリシーを実施する。存在する場合には、リモート・ハブ・マルチプレクサ９０３により要求マルチプレクサ９０４に提示された要求には、いつでも要求マルチプレクサ９０４により優先権が与えられる。要求マルチプレクサ９０４の出力は、アウトバウンドＸ、ＹおよびＺリンク、ノード・マスタ／リモート・ハブ（ＮＭ／ＲＨ）保持バッファ９０６、およびローカル・ハブ（ＬＨ）アドレス・ランチ・バッファ９１０にそれぞれ結合している要求バス９０５を駆動する。また、好ましくは、要求バス９０５と結合している前の要求ＦＩＦＯバッファ９０７は、もしある場合には、アドレスがそのアドレス保有期間ハッシュにより送られるアドレス・スライスまたはリソース・バンク１９１２を決定することができるように、多数の前のアドレス保有期間それぞれに対する少量のアドレス関連情報を保持する。例えば、一実施形態の場合には、前の要求ＦＩＦＯバッファ９０７の各エントリは、関連要求の要求アドレスがハッシュされるバンク１９１２ａ〜１９１２ｎの特定の１つのバンクを識別する「１−ホット」暗号化を含む。要求が要求バス９０５により送信されないアドレス保有期間の場合には、１−ホットコード化はすべて「０」である。

インバウンドの第１の層の（Ｘ、ＹおよびＺ）リンクは、それぞれＬＨアドレス・ランチ・バッファ９１０および各ノード・リーフ／リモート・リーフ（ＮＬ／ＲＬ）保持バッファ９１４ａ〜９１４ｃと結合している。ＮＭ／ＲＨ保持バッファ９０６、ＬＨアドレス・ランチ・バッファ９１０およびＮＬ／ＲＬ保持バッファ９１４ａ〜９１４ｃの出力は、すべてスヌープ・マルチプレクサ９２０の入力になる。ＬＨアドレス・ランチ・バッファ９１０の出力には、好ましくは、前の要求ＦＩＦＯバッファ９０７のような構造のもう１つの前のバッファ９１１が結合している。スヌープ・マルチプレクサ９２０の出力は、要求ＦＩＦＯキュー９２４、処理装置１００のスヌーパ３０４（例えば、Ｌ２キャッシュ１１０のスヌーパ１１６およびＩＭＣ１２４のスヌーパ１２６）、およびアウトバウンドＡおよびＢリンクが結合しているスヌープ・バス９２２を駆動する。スヌーパ３０４は、さらに、ローカル・ハブ（ＬＨ）部分応答ＦＩＦＯキュー９３０およびノード・マスタ／リモート・ハブ（ＮＭ／ＲＨ）部分応答ＦＩＦＯキュー９４０と結合していてこれらによりサポートされる。

他の実施形態を使用することもできるが、好ましくは 通信待ち時間を最小限度に短縮するために、バッファ９０２、９０６および９１４ａ〜９１４ｃはショート状態にある。１つの好ましい実施形態の場合には、各バッファ９０２、９０６および９１４ａ〜９１４ｃは、選択したリンク情報割当ての１つのフレームのアドレス保有期間だけを保持する大きさになっている。

ここで図１８を参照すると、この図は、図１７のローカル・ハブ（ＬＨ）アドレス・ランチ・バッファ９１０のより詳細なブロック図である。図に示すように、ＬＨアドレス・ランチ・バッファ９１０のローカルおよびインバウンドＸ、ＹおよびＺリンク入力は、マップ・ロジック１０１０の入力となり、マップ・ロジックは特定の各入力上で受信した要求を、対応する各位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄに入れる。図の名称の場合、処理ノード／ＭＣＭ２０２の左上隅の処理装置１００ａは、「Ｓ」チップであり、処理ノード／ＭＣＭ２０２の右上隅の処理装置１００ｂは「Ｔ」チップであり、処理ノード／ＭＣＭ２０２の左下隅の処理装置１００ｃは「Ｕ」チップであり、処理ノード２０２の右下隅の処理装置１００ｄは「Ｖ」チップである。それ故、例えば、ローカル・マスタ／ローカル・ハブ１００ａｃの場合には、ローカル入力上で受信した要求は、マップ・ロジック１０１０によりＵ ＦＩＦＯキュー１０２０ｃ内に入れられ、インバウンドＹリンク上で受信した要求は、マップ・ロジック１０１０によりＳ ＦＩＦＯキュー１０２０ａ内に入れられる。マップ・ロジック１０１０は、すべてのローカル・ハブ１００内の以下に説明するアービトレーション・ロジック１０３２が、任意の明示の相互通信を使用しないで、要求を同じように処理するために同期するように入力の流れを正規化するために使用される。

位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄ内に位置しているが、要求はすぐには有効というマークがつけられるわけではなく、ディスパッチのために使用できるわけでもない。それどころか、各位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄ内の要求の有効性は、４つの入力上の各アドレス保有期間中に受信する要求を同期させるために、各プログラム可能な遅延１０００ａ〜１０００ｄを発生する。それ故、ローカル・マスタ／ローカル・ハブ１００のところで要求の自己ブロードキャストを受信するローカル入力に関連するプログム可能な遅延１０００ａは、一般に、他の入力に関連するプログラム可能な遅延よりかなり長い。適当な要求を確実に有効にするために、プログラム可能な遅延１０００ａ〜１０００ｄが発生した有効信号は、基本的な要求としてマップ・ロジック１０１０により同じようにマッピングされる。

位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄの出力は、ローカル・ハブ要求マルチプレクサ１０３０の入力となり、このローカル・ハブ要求マルチプレクサは、アービタ１０３２が発生した選択信号に応じて、スヌープ・マルチプレクサ９２０に提示するための位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄから１つの要求を選択する。アービタ１０３２は、図４および図６に示すように、処理ノード２０２内のすべてのローカル・ハブ１００により同時に、アウトバウンドＡリンクにより同じ要求がブロードキャストされるように、その選択の際に所与の処理ノード２０２内のすべての他のローカル・ハブ１００のアービタ１０３２と同期する公平なアービトレーション・ポリシーを実施する。それ故、図１３および図１６に示す例示としてのリンク情報割当てのいずれかの場合、ローカル・ハブ要求マルチプレクサ１０３０の出力は、アウトバウンドＡリンク要求フレームのアドレス保有期間にタイムスライス整合する。

ＬＨアドレス・ランチ・バッファ９１０の入力帯域幅は、その出力帯域幅の４倍であるので、位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄのオーバーランは設計に関連する。好ましい実施形態の場合には、キューのオーバーランは、各位置に依存するＦＩＦＯキュー１０２０に対して、関連する位置に依存するＦＩＦＯキュー１０２０の深さと同じ大きさのローカル・ハブ・トークンのプールを実施することにより防止される。ローカル・マスタが要求をローカル・ハブに送信するには自由ローカル・ハブ・トークンが必要であり、この自由ローカル・ハブ・トークンは、ローカル・ハブが要求をキューに入れることができることを保証する。それ故、ローカル・マスタ１００が要求を発行した場合には、ローカル・ハブ・トークンがローカル・ハブ１００内の位置に依存するＦＩＦＯキュー１０２０に割り当てられ、アービタ１０３２が位置に依存するＦＩＦＯキュー１０２０からエントリを発行した場合には、再度使用するために解放される。

ここで図１９を参照すると、この図は、処理装置１００のところで要求および関連する結合応答が観察される順序を追跡するために使用される、図１７の要求ＦＩＦＯキュー９２４のより詳細なブロック図である。米国特許公開第２００６０１８７９３９号に詳細に記載されている本発明の他の実施形態の場合には、すべての要求ＦＩＦＯキュー９２４は、要求を開始するマスタのタグを格納するための物理的ＦＩＦＯキューとして実施される。要求および関連する結合応答は、順番に任意の処理装置により観察されるので、物理要求ＦＩＦＯキューにより、動作のマスタ・タグをすべての部分応答および結合応答と一緒にトランスポートしなくても、そのマスタ・タグを動作の結合応答と関連づけることができる。しかし、物理要求ＦＩＦＯキューの数は、通信リンクの数により幾何学的に増大するので、上記特許出願に開示されている要求ＦＩＦＯキューの全物理的実施態様は、小規模なシステムまたは数本の通信リンクを含むシステムによりよく適している。他の実施形態のいくつかの物理要求ＦＩＦＯキューの代わりに仮想要求ＦＩＦＯキューを使用することにより、本明細書に開示している好ましい実施形態のスケーラビリティが改善される。

ここで図１９の好ましい実施形態を参照すると、要求ＦＩＦＯキュー９２４は、アービタ１０３２が開始し、その処理装置１００内のマスタ３００が開始した、グローバルな範囲の要求のマスタ・タグを格納するためのいくつかの物理エントリを有する物理ローカル・ハブ（ＬＨ）タグＦＩＦＯキュー９２４ａを含む。ＬＨタグＦＩＦＯ９２４ａは、次の新しい要求のマスタ・タグを保持するために割り当てるエントリを識別する関連ヘッド・ポインタ（ＨＰ）１１００ａ、および受信する次の結合応答（ＣＲ）と関連するマスタ・タグを含むエントリを識別するテール・ポインタ（ＴＰ）１１０２ａを有する。要求ＦＩＦＯキュー９２４は、さらに、アービタ１０３２が開始し、その処理装置１００内のマスタ３００が開始したノードだけの範囲の要求のマスタ・タグを格納するためのいくつかの物理エントリを有する物理的ノード・マスタ（ＮＭ）タグＦＩＦＯキュー９２４ｂ２を含む。ＮＭタグＦＩＦＯ９２４ｂ２は、次の新しい要求のマスタ・タグを保持するために割り当てるエントリを識別する関連ヘッド・ポインタ（ＨＰ）１１００ｂ２、および受信する次の結合応答（ＣＲ）と関連させるマスタ・タグを含むエントリを識別するテール・ポインタ（ＴＰ）１１０２ｂ２を有する。

物理ＬＨタグＦＩＦＯ９２４ａ、および物理ＮＭタグＦＩＦＯ９２４ｂ２の他に、要求ＦＩＦＯキュー９２４は、図に鎖線で示すように、要求ロジック１２１ａ内に物理的に存在しないいくつかの仮想ＦＩＦＯキューを有するチケット発行機構を含む。代わりに、各仮想ＦＩＦＯキュー９２４は、それぞれ各「チケット番号」により識別されるいくつかの仮想（すなわち、物理的でない）エントリを有する。各仮想ＦＩＦＯキュー９２４は、また、一対の関連する物理ポインタ、すなわち、次の新しい要求に割り当てられる仮想エントリを識別するヘッド・ポインタ（ＨＰ）１１００、および受信した次の結合応答（ＣＲ）と関連させる仮想エントリを識別するテール・ポインタ（ＴＰ）１１０２を有する。その値が自身がポイントする仮想エントリの特定のチケット番号を示すカウンタとして、ポインタ１１００および１１０２を有利に実施するすることができる。ある実施形態の場合には、異なる範囲を異なる仮想ＦＩＦＯキュー９２４のポインタのペア１１００、１１０２に割り当てることができ、そのためチケット番号も、チケット番号を関連づける仮想ＦＩＦＯキュー９２４を始めから示す。

図に示すように、要求ＦＩＦＯキュー９２４のうちの仮想ＦＩＦＯキューは、各インバウンドＡおよびＢリンクを介して受信した全システム範囲の要求を追跡するリモート・ハブ（ＲＨ）仮想ＦＩＦＯキュー９２４ｂ０〜９２４ｂ１を含む。仮想ＦＩＦＯキューは、また、それぞれがインバウンドの第１および第２の層のリンクの各一意の組合せを介して、リモート・リーフ１００により受信した全システム範囲の要求を追跡するリモート・リーフ（ＲＬ）仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１および９２４ｅ０〜９２４ｅ１を含む。最後に、仮想ＦＩＦＯキューは、それぞれが各第１の層のＸ、ＹおよびＺリンク上でノード・リーフ１００が受信した要求を追跡するノード・リーフ（ＮＬ）仮想ＦＩＦＯキュー９２４ｃ２、９２４ｄ２および９２４ｅ２を含む。

要求に対する可能な各役割（ＬＨ、ＮＭ、ＲＨ、ＲＬおよびＮＬ）内でサービスを提供している処理装置１００のところで要求を受信した場合には、要求ＦＩＦＯキュー９２４の関連キューのヘッド・ポインタ１１００により識別された物理的または仮想エントリは、その要求に割り当てられ、ヘッド・ポインタ１１００が前進する。物理キューの場合には、その要求を開始したマスタ３００を識別するマスタ・タグが割り当てられたエントリ内に配置される。非物理キューの場合には、前進する前にヘッド・ポインタ１１００が示すチケット番号は、単に要求と関連するだけである。処理装置１００のところで要求に対する結合応答を受信した場合には、要求に割り当てられたキュー・エントリを識別するために、要求に対する処理装置１００がサービスした役割に対する要求ＦＩＦＯキュー９２４の関連するキューのテール・ポインタ１１０２に対してアクセスが行われ、テール・ポインタ１１０２が前進する。物理キューの場合には、要求を開始したマスタ３００を識別するマスタ・タグが割り当てられたエントリから検索され、仮想キューの場合には、要求のチケット番号だけが検索される。

物理要求ＦＩＦＯキューだけではなく、仮想要求ＦＩＦＯキューを実施すると、他の実施形態と比較した場合タグ記憶装置が有意に低減し、同時にシステムのスケーラビリティが改善される。種々の処理装置１００のところで結合応答を受信する順序が、関連する要求を受信した順番と同じである場合には、キュー・エントリの割当ておよび検索についてのＦＩＦＯポリシーを有利に使用することができる。さらに、当業者であれば、特定の動作内でプロセッサ１００が行っている役割ではなく、絶対チップ位置（例えば、Ｓ、Ｔ、Ｕ、Ｖ）に基づいて要求ＦＩＦＯキュー９２４を別の方法により実施することができることを理解されたい。

以下に説明する図２２〜図２３に示すように、ＬＨタグＦＩＦＯキュー９２４ａ内のエントリは、全システム・ブロードキャスト動作に対して最も長い保有期間を有し、ＮＭタグＦＩＦＯキュー９２４ｂ２は、ノードだけのブロードキャスト動作に対して最も長い保有期間を有する。それ故、ＬＨタグＦＩＦＯキュー９２４ａおよびＮＭタグＦＩＦＯキュー９２４ｂ２の深さは、それぞれ処理ノード２０２が相互接続ファブリック上で発行することができる全システム範囲の同時動作の数、および所与の処理装置１００が相互接続ファブリック上で発行することができるノードだけの範囲の同時動作の数を制限する。これらの深さは必要な関連を有していないし、異なるものであってもよい。しかし、好ましくは、仮想ＦＩＦＯキュー９２４ｂ０〜９２４ｂ１、９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１および９２４ｅ０〜９２４ｅ１の深さは、ＬＨタグＦＩＦＯキュー９２４ａの深さと等しくなるように設計し、好ましくは、仮想ＦＩＦＯキュー９２４ｃ２、９２４ｄ２および９２４ｅ２の深さは、ＮＭタグＦＩＦＯキュー９２４ｂ２の深さと等しくなるように設計する。

ここで図２０および図２１を参照すると、これらの図は、図１７のローカル・ハブ（ＬＨ）部分応答ＦＩＦＯキュー９３０およびノード・マスタ／リモート・ハブ（ＮＭ／ＲＨ）部分応答ＦＩＦＯキュー９４０の例示としての実施形態のより詳細なブロック図である。図に示すように、ＬＨ部分応答ＦＩＦＯキュー９３０は、それぞれが、要求に対する蓄積した部分応答を格納するための部分応答フィールド１２０２、および異なる時間にまたはできれば同時に、ローカル・ハブ１００が部分応答（すなわち、ローカル（Ｌ）、第１の層のＸ、Ｙ、Ｚリンク、および第２の層のＡおよびＢリンク）を受信することができる６つの可能な各ソースに対する各フラグを有する応答フラグ・アレイ１２０４を含むいくつかのエントリ１２００を含む。ＬＨ部分応答ＦＩＦＯキュー９３０内のエントリ１２００は、割当てポインタ１２１０を介して割り当てられ、割当解除ポインタ１２１２を介して割当解除される。Ａポインタ１２１４、Ｂポインタ１２１５、Ｘポインタ１２１６、Ｙポインタ１２１８、およびＺポインタ１２２０により、応答フラグ・アレイ１２０４を備える種々のフラグに対してアクセスが行われる。

以下にさらに説明するように、ローカル・ハブ１００のところで部分応答ロジック１２１ｂにより特定の要求に対する部分応答を受信した場合には、部分応答は、部分応答フィールド１２０２内に蓄積され、部分応答を受信したリンクが、応答フラグ・アレイ１２０４内の対応するフラグを設定することにより記録される。次に、ポインタ１２１４、１２１５、１２１６、１２１８および１２２０のうちの対応するポインタが以降のエントリ１２００に進む。

もちろん、すでに説明したように、各処理装置１００をその５つのインバウンド（Ｘ、Ｙ、Ｚ、ＡおよびＢ）リンクのそれぞれにより他の処理装置１００に完全に結合しなくてもよい。それ故、接続していないリンクに関連する応答フラグ・アレイ１２０４内のフラグは無視される。もし存在する場合、各処理装置１００の接続していないリンクは、例えば、構成レジスタ１２３内に表示されている構成により表示することができ、構成レジスタは、例えば、システム始動の際のブート・コードまたはデータ処理システム２００を分割する際にオペレーティング・システムにより設定することができる。

図２１と図２０とを比較すれば分かるように、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０は、ＬＨ部分応答ＦＩＦＯキュー９３０類似の構造を有している。ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０は、それぞれが蓄積した部分応答、およびノード・マスタまたはリモート・ハブ１００が、部分応答（すなわち、ノード・マスタ（ＮＭ）／リモート（Ｒ）、および第１の層のＸ、ＹおよびＺリンク）を受信することができる最大４つの各可能なソースに対する各フラグを有する応答フラグ・アレイ１２３４を格納するための部分応答フィールド１２０２を含むいくつかのエントリ１２３０を含む。さらに、各エントリ１２３０は、動作がノードだけのブロードキャスト動作であるか、または全システム・ブロードキャスト動作であるかを識別し、全システム・ブロードキャスト動作の場合には、インバウンドの第２の層のリンクのうちのどれが要求を受信したのか（それ故、アウトバウンドの第２の層のリンクのどれが蓄積した部分応答を送信するのか）を識別するルート・フィールド１２３６を含む。ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内のエントリ１２３０は、割当ポインタ１２１０を介して割り当てられ、割当解除ポインタ１２１２を介して割当が解除される。応答フラグ・アレイ１２３４を含む種々のフラグは、Ｘポインタ１２１６、Ｙポインタ１２１８、およびＺポインタ１２２０によりアクセスされ、更新される。

図２０のところですでに説明したように、各処理装置１００をその第１の層のＸ、Ｙ、およびＺリンクそれぞれにより他の処理装置１００に完全に結合しなくてもよい。それ故、接続していないリンクに関連する応答フラグ・アレイ１２０４内のフラグは無視される。もし存在する場合、各処理装置１００に接続していないリンクは、例えば、構成レジスタ１２３内に表示されている構成により表示することができる。

ここで図２２を参照すると、この図は、図１７〜図２１の例示としてのデータ構造に関する例示としての全システム・ブロードキャスト動作の保有期間を示す時間空間図である。図２２の頂部に示し、図４のところですでに説明したように、動作はローカル・マスタ１００ａ０ｃによりローカル・ハブ１００ａ０ｂを含む各ローカル・ハブ１００に発行される。ローカル・ハブ１００ａ０ｂは、動作をリモート・ハブ１００ｂ０ａに転送し、このリモート・ハブは動作をリモート・リーフ１００ｂ０ｄを含むそのリモート・リーフに転送する。動作への部分応答は、同じ一連のリンクをローカル・ハブ１００ａ０ａ〜１００ａ０ｄへ逆の方向に横断し、ローカル・ハブ１００ａ０ａ〜１００ａ０ｄのそれぞれへ蓄積した部分応答をブロードキャストする。次に、ローカル・ハブ１００ａ０ｂを含むローカル・ハブ１００ａ０ａ〜１００ａ０ｃは、要求と同じ送信経路を通して結合応答を配信する。それ故、ローカル・ハブ１００ａ０ｂは、リモート・ハブ１００ｂ０ａに結合応答を送信し、このリモート・ハブは、リモート・リーフ１００ｂ０ｄに結合応答を送信する。

上記タイミング制約により説明したように、ローカル・マスタ１００ａ０ｃによる動作の開始からローカル・ハブ１００ａ０ａ、１００ａ０ｂ、１００ａ０ｃおよび１００ａ０ｄによるそのランチまでの時間は変化し、ローカル・ハブ１００による動作のランチからリモート・リーフ１００によるその受信までの時間は制限された時間であり、リモート・リーフ１００からローカル・ハブ１００への部分応答待ち時間は変化し、ローカル・ハブ１００からリモート・リーフ１００までの結合応答待ち時間は制限された時間である。

このタイミング・シーケンスの背景に対して、図２２は、動作の要求フェーズ、部分応答フェーズ、および結合応答フェーズ中のデータ処理システム２００内の種々のデータ構造内の情報の種々の項目の保有期間を示す。より詳細に説明すると、参照番号１３００は、ＬＨランチ・バッファ９１０内の要求の保有期間（および、それ故、ローカル・ハブ・トークンの保有期間）を示し、参照番号１３０２は、ＬＨタグＦＩＦＯキュー９２４ａ内のエントリの保有期間を示し、ブロック１３０４は、ＬＨ部分応答ＦＩＦＯキュー９３０内のエントリ１２００の保有期間を示し、参照番号１３０６は、ＲＨ仮想ＦＩＦＯ９２４ｂ０または９２４ｂ１内のエントリの保有期間を示し、参照番号１３０８は、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内のエントリ１２３０の保有期間を示し、参照番号１３１０は、ＲＬ仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１および９２４ｅ０〜９２４ｅ１内のエントリの保有期間を示す。図２２は、さらに、保護ウィンドウ１３１２ａ、およびその部分応答の発生から結合応答の受信後までのローカル・マスタ１００ａ０ｃへのメモリ・ブロックのコヒーレンシ所有権の移転を保護するために、リモート・リーフ１００ｂ０ｄ内のスヌーパにより拡張されたウィンドウ延長部１３１２ｂ（また図３および図１１の３１２ａ〜３１２ｂ）の持続時間を示す。参照番号１３１４（およびまた図３および図１１の参照番号３１３）により示すように、ローカル・マスタ１００ａ０ｃも、結合応答の受信からの所有権の移転を保護する。

参照番号１３０２、１３０６および１３１０で示すように、ＬＨタグＦＩＦＯキュー９２４ａ、ＲＨ仮想ＦＩＦＯキュー９２４ｂ０〜９２４ｂ１およびＲＬ仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１、および９２４ｅ０〜９２４ｅ１内のエントリには最も長い保有期間が適用される。それ故、（一般に同じになるように設計される）要求ＦＩＦＯキュー９２４の最小深さは、任意の時点でデータ処理システム２００内のフライト中に存在することができる要求の最大数を制限する。一般に、要求ＦＩＦＯキュー９２４の所望の深さは、任意に選択した処理装置１００による要求のスヌーピーングからその処理装置１００による結合応答の受信までの予想最大待ち時間を、選択したリンク情報割当てが発行することができる要求の最大数で割ることにより選択することができる。他のキュー（例えば、ＬＨ部分応答ＦＩＦＯキュー９３０およびＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０）もそのエントリの保有期間がもっと短い場合には、短いキュー深さを安全に割り当てることができるが、説明を簡単にするために、少なくともいくつかの実施形態の場合には、ＬＨ部分応答ＦＩＦＯキュー９３０の深さを要求ＦＩＦＯキュー９２４と同じになるように設定し、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０の深さを、ＮＭタグＦＩＦＯ９２４ｂ２の深さにＲＬ仮想ＦＩＦＯキュー９２４の深さのｔ２／２倍を加えたものと等しくなるように設定することが望ましい。

図２３は、図１７〜図２１の例示としてのデータ構造に関する例示としてのノードだけのブロードキャスト動作の保有期間を示す時間空間図である。図２３の頂部に示し、図５のところですでに説明したように、動作は、ノード・マスタ１００ｂ０ａにより、その第１の層のリンクを介して、ノード・リーフ１００ｂ０ｂを含むそのノード・リーフ１００それぞれに発行される。動作に対する部分応答は、第１の層のリンクを横断してノード・マスタ１００ｂ０ａに戻る。次に、ノード・マスタ１００ｂ０ａは、その第１の層のリンクを介してノード・リーフ１００ｂ０ｂを含むそのノード・リーフ１００それぞれに結合応答をブロードキャストする。

上記タイミング制約のところで説明したように、ノード・マスタ１００ｂ０ａによる動作の開始からノード・リーフ１００ｂ０ｂ、１００ｂ０ｃ、１００ｂ０ｄ内でのその送信までの時間は限定された時間であり、ノード・リーフ１００からノード・マスタ１００ｂ０ａまでの部分応答待ち時間は変化する時間であり、ノード・マスタ１００ｂ０ａからリモート・リーフ１００までの結合応答待ち時間は限定された時間である。

図２３は、さらに、ノードだけのブロードキャスト動作の要求フェーズ、部分応答フェーズ、および結合応答フェーズ中のデータ処理システム２００内の種々のデータ構造内の情報の種々の項目の保有期間を示す。より詳細に説明すると、参照番号１３２０は、ＮＭタグＦＩＦＯキュー９２４ｂ２内のエントリの保有期間を示し、参照番号１３２２は、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内のエントリ１２３０の保有期間を示し、参照番号１３２４は、ＮＬ仮想ＦＩＦＯキュー９２４ｃ２、９２４ｄ２および９２４ｅ２内のエントリの保有期間を示す。ＬＨランチ・バッファ９１０（または関連するローカル・ハブ・トークン）、ＬＨタグＦＩＦＯキュー９２４ａ、またはＬＨ部分応答ＦＩＦＯキュー９３０の保有期間は図示していない。何故なら、これらの構造は、ノードだけのブロードキャスト動作のためには使用されないからである。

最後に、図２３は、その部分応答の発生から結合応答の受信までのノード・マスタ１００ｂ０ａへのメモリ・ブロックのコヒーレンシ所有権の移転を保護するために、必要な場合には、ノード・リーフ１００ｂ０ｂ内のスヌーパにより拡張した保護ウィンドウ１３２６（同様に、図３および図１１の参照番号３１２ａ）の持続時間を示す。参照番号１３２８（およびまた図３および図１１の参照番号３１３）により示すように、ノード・マスタ１００ｂ０ａも、結合応答の受信からの所有権の移転を保護する。ノードだけのブロードキャスト動作の場合には、上記のタイミング制約に適合するためにウィンドウ拡張部３１２ｂは必要ない。

ここで図２４〜図２７を参照すると、これらの図面は、それぞれ本発明の例示としての実施形態によるローカル・マスタ（またはノード・マスタ）、ローカル・ハブ、リモート・ハブ（またはノード・マスタ）、およびリモート・リーフ（またはノード・リーフ）のところの要求フェーズ中の動作の例示としての処理を示すフローチャートである。ここで特に図２４を参照すると、ローカル・マスタ（ノードだけのブロードキャストの場合には、ノード・マスタ）１００のところの要求フェーズ処理は、ローカル・マスタ１００内の特定のマスタ３００（例えば、入出力コントローラ１２８内のＬ２キャッシュ１１０またはマスタ内のマスタ１１２のうちの１つ）が要求を発生するとブロック１４００から開始する。すでに説明したように、好ましくは、要求３０２は、所望のアクセスのタイプを示す少なくともトランザクション・タイプおよび要求がアクセスするリソースを示すリソース識別子（例えば、実アドレス）を含む。要求は、さらに、要求の範囲（例えば、ノードだけまたは全システム）を示す（Ｔｔｙｐｅの一部を形成することができる）範囲表示および図３８に示すフォームの動作タグ２０００を含むかまたは伴う。図３８に示すように、動作タグ２０００は、動作を開始する処理ノード２０２、プロセッサ１００および特定のマスタ３００をそれぞれ識別するノードＩＤ２００２、チップＩＤ２００４、およびマスタ・タグ２００６を含む。ブロック１４００から、プロセスはブロック１４０２、１４０４、１４０６、および１４０８に進むが、これらの各ブロックは、特定のマスタ３００による要求の発行の条件を示す。ブロック１４０２および１４０４に示す条件は、マスタ・マルチプレクサ９００の動作を示し、ブロック１４０６および１４０８に示す条件は要求マルチプレクサ９０４の動作を示す。

最初にブロック１４０２および１４０４について説明すると、マスタ・マルチプレクサ９００が、マスタ・マルチプレクサ９００を支配する公平なアービトレーション・ポリシーが（おそらく）複数の競合マスタ３００の要求の中から特定のマスタ３００の要求を選択した場合には（ブロック１４０２）、また要求が全システム・ブロードキャストである場合には、またローカル・ハブ・トークンが要求への割当てのために使用できる場合には（ブロック１４０４）、特定のマスタ３００の要求を出力する。ブロック１４１５に示すように、マスタ３００が、その要求の範囲としてノードだけの範囲を選択した場合には（例えば、構成レジスタ１２３の設定または上記米国特許出願第１１／０５５，３０５号に記載されているような範囲予測機構あるいはその両方を参照して）、ローカル・ハブ・トークンは必要ではなく、ブロック１４０４に示す条件は外される。

特定のマスタ３００の要求がマスタ・マルチプレクサ９００を通して要求マルチプレクサ９０４に進んだ場合には、要求マルチプレクサ９０４は、アウトバウンドの第１の層のリンク情報割当て内の要求に対してアドレス保有期間を使用することができる場合だけ、要求バス９０５上に要求を発行する（ブロック１４０６）。すなわち、要求マルチプレクサ９０４の出力は、選択したリンク情報割当てとタイムスライス整合し、要求（例えば、図１２の実施形態のサイクル０または２、または図１５の実施形態のサイクル０）を運ぶように設計されたサイクル中だけ出力を発生する。さらにブロック１４０８に示すように、要求マルチプレクサ９０４は、いつでも優先権が与えられるリモート・ハブ・マルチプレクサ９０３が、インバウンドの第２の層のＡおよびＢリンクから要求を提示しない場合にだけ要求を発行する（ブロック１４０６）。それ故、第２の層のリンクは、インバウンド要求によりブロックされないことを保証される。このようなブロックされないポリシーを使用した場合でも、マスタ３００による要求は、下流のハブのインバウンドＡおよびＢリンク上のいくつかの連続しているアドレス保有期間中、要求の「レンガ壁」を防止する上流ハブのアービタ１０３２内の適当なポリシーの実施により「不足」から免れることができる。

ブロック１４０２〜１４０８のうちの任意のブロックにおいて「いいえ」と判断した場合には、ブロック１４０２〜１４０８すべてのブロックでの判断が「はい」である後続のサイクルまでブロック１４０１に示すように要求は遅延する。一方、ブロック１４０２〜１４０８すべてのところで「はい」と判断された場合には、プロセスはブロック１４１７に進む。ブロック１４１７は、（Ｔｔｙｐｅフィールド７００の範囲インジケータ７３０またはＴｔｙｐｅフィールド８００の範囲インジケータ８３０が示すように）ノードだけの範囲の要求に、ブロック１４１９〜１４２３に示す２つの追加条件が課せられることを示す。最初に、ブロック１４１９に示すように、要求がノードだけのブロードキャスト要求である場合には、ＮＭタグＦＩＦＯキュー９２４ｂ２内の要求への割当てにエントリを使用することができる場合だけ、要求マルチプレクサ９０４は要求を発行する。そうでない場合には、プロセスはブロック１４１９からすでに説明したブロック１４１０へ戻る。

第二に、ブロック１４２３に示すように、要求マルチプレクサ９０４は、前の要求ＦＩＦＯバッファ９０７内にバッファされている選択した数の前の要求のいずれかとして、バンクを含むリソース１９１０の同じバンク１９１２に要求アドレスがハッシュされない場合だけ、ノードだけの範囲の要求を発行する。例えば、スヌーピーング・デバイス１９００が最大要求到着レートで要求にサービスすることはできないが、代わりに１／Ｒで表される最大到着レートの何分の１かで要求にサービスすることができるように、スヌーピーング・デバイス１９００およびその関連するリソース１９１０が構成されていると仮定した場合には、同じアドレス・スライスに入るかどうかを判定するために、要求マルチプレクサ９０４によるランチのために競合している現在のノードだけの要求が比較される選択した数の前の要求は、好ましくは、Ｒ−１である。複数の異なるスヌーピーング・デバイス１９００を、この方法で要求のオーバーランから保護する場合には、選択した数の要求Ｒ−１は、好ましくは、個々のスヌーピーング・デバイス１９００に対して計算した一組の数値Ｒ−１の最大値に設定する。好ましくは、処理装置１００はブロードキャストのための要求のその選択に調整しないので、ブロック１４２３に示す方法で要求を絞っても、特定のスヌーピーング・デバイス１９００のところの要求の到着レートがスヌーピーング・デバイス１９００のサービス速度を超えないという保証はない。しかし、図の方法でノードだけのブロードキャスト要求を絞り込めば、所与の数のサイクル中に到着する要求の数が下式のように制限される。
絞り込まれた到着レート＝Ｒサイクル当たりのＰＵ要求
ここで、ＰＵは処理ノード２０２当たりの処理装置１００の数である。好ましくは、スヌーピーング・デバイス１９００は、再試行を行わないでこのような絞り込まれた到着レートで到着するノードだけのブロードキャスト要求を処理するように設計する。

ブロック１４２３に示す条件を満たさない場合には、プロセスはブロック１４２３からすでに説明したブロック１４１０に戻る。しかし、ブロック１４１９および１４２３に示す両方の条件を満たす場合には、要求マルチプレクサ９０４は、要求バス９０５上でノードだけのブロードキャスト要求を発行し、プロセスはページ・コネクタ１４２５を通って図２６のブロック１４２７に進む。

再度ブロック１４１７に戻って説明すると、要求がノードだけのブロードキャスト要求ではなく全システム・ブロードキャスト要求である場合には、プロセスはブロック１４１２に進み、図１３の保有期間１３００を開始する。ブロック１４１２は、各アウトバウンドＸ、ＹおよびＺリンクおよびローカル・ハブ・アドレス・ランチ・バッファ９１０に要求バス ９０５により要求をブロードキャストしている要求マルチプレクサ９０４を示す。その後で、プロセスは２つに分岐し、各ローカル・ハブ１００のところでの要求の処理を示す図２５へのページ・コネクタ１４１４および１４１６を通る。

ここで図２５を参照すると、これらの図面は、また、ブロック１４１６から開始するローカル・マスタ１００であるローカル・ハブ１００のところでの要求の処理、およびブロック１４１４から開始するローカル・マスタ１００としての同じ処理ノード２０２内の他のローカル・ハブ１００のそれぞれのところでの要求の処理を示す。最初にブロック１４１４について説明すると、インバウンドＸ、ＹおよびＺリンク上でローカル・ハブ１００が受信した要求は、ＬＨアドレス・ランチ・バッファ９１０により受信される。図１８のブロック１４２０のところに示すように、マップ・ロジック１０１０は、バッファするために位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄのうちの適当なキューに、Ｘ、ＹおよびＺ要求のそれぞれをマッピングする。すでに説明したように、Ｘ、ＹおよびＺリンク上で受信し、位置に依存するキュー１０２０ａ〜１０２０ｄ内に収容した要求はすぐには確認されない。代わりに、これらの要求には、所与のローカル・ハブ１００上のＸ、ＹおよびＺ要求およびローカル要求の処理を、同じ処理ノード２０２内の他のローカル・ハブ１００のところの対応する要求の処理と同期させる各調整遅延１０００ａ〜１０００ｄが与えられる（ブロック１４２２）。その後で、ブロック１４３０に示すように、調整遅延１０００は、位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄ内のその各キューを確認する。

ここでブロック１４１６について説明すると、ローカル・マスタ／ローカル・ハブ１００のところで、要求バス９０５上の要求は、直接、ＬＨアドレス・ランチ・バッファ９１０に送られる。チップ間リンクを通過していないので、このローカル要求は、同じサイクル内で発行された要求がインバウンドＸ、ＹおよびＺリンク上に到着するより早く、ＬＨアドレス・ランチＦＩＦＯ９１０に到着する。それ故、ブロック１４２４に示すマップ・ロジック１０１０によるマッピングの後で、調整遅延１０００ａ〜１０００ｄのうちの１つが、その確認をインバウンドＸ、ＹおよびＺリンク上で受信した要求の確認と同期させるために、ローカル要求に長い遅延を適用する（ブロック１４２６）。この遅延間隔の後で、関連する調整遅延１０００が、ブロック１４３０に示すようにローカル要求を確認する。

ブロック１４３０のところでのＬＨアドレス・ランチ・バッファ９１０内のキューの形をしている要求の確認の後で、プロセスは、それぞれがアービタ１０３２が強制的に行ったＬＨアドレス・ランチ・バッファ９１０からの要求の発行の条件を示すブロック１４３４〜１４４０に進む。すでに説明したように、すべての処理装置１００内のアービタ１０３２は同期しているので、相互通信を行わなくてもすべてのローカル・ハブ１００は同じ決定を行う。ブロック１４３４に示すように、アービタ１０３２により、ローカル・ハブ要求マルチプレクサ１０３０は、アウトバウンドの第２の層のリンク情報割当て内の要求に対してアドレス保有期間を使用することができる場合だけ、要求を出力することができる。それ故、例えば、アービタ１０３２は、図１３の実施形態のサイクル０または２、または図１６の実施形態のサイクル０の間だけ、ローカル・ハブ要求マルチプレクサ１０３０に要求の送信を開始させる。さらに、アービタ１０３２が実施した公平なアービトレーション・ポリシーが、要求が次にサービスを受ける位置に依存するＦＩＦＯキュー１０２０ａ〜１０２０ｄに属すると判定した場合に、ローカル・ハブ要求マルチプレクサ１０３０により要求が出力される（ブロック１４３６）。

さらにブロック１４３７および１４３８に示すように、アービタ１０３２は、自身が連続しているアドレス保有期間内にそんなに多くの要求を出力していないと判定した場合だけ、ローカル・ハブ要求マルチプレクサ１０３０に要求を出力させる。より詳細には、ブロック１４３７に示すように、アウトバウンドＡおよびＢリンクに接続しているハブ１００の要求バス９０５の過度の駆動を避けるために、アービタ１０３２は、最悪の場合（すなわち、下流のハブ１００の他の第２の層のリンクに接続している上流のハブ１００が、同じサイクル中に要求を送信している場合）を仮定して、使用できるアドレス保有期間の僅か半分（すなわち、１／ｔ２）の間に要求をランチする。さらに、ブロック１４３８に示すように、アービタ１０３２は、さらに、そのアウトバウンドＡおよびＢリンクに結合している処理装置１００内のマスタ３００の起こりうる「不足状態」を回避するために、第２の層のリンク上のトラフィックの公平な割当ての下で要求のランチを制限する。

例えば、処理ノード２０２当たり２対の第２の層のリンクおよび４つの処理装置１００を含む図２の実施形態の場合には、下流のハブ１００の要求バス９０５上のトラフィックは、最大９つの処理装置１００、すなわち、第２の層のリンクおよび下流のハブ１００自身により、下流のハブ１００と結合している２つの各処理ノード２０２内の４つの処理装置１００と競合することになる。それ故、可能な要求ソース間で要求バス９０５の帯域幅を等しく分割する例示としての公平な割当てポリシーは、帯域幅の４／９を各インバウンドＡおよびＢリンクに、帯域幅の１／９をローカル・マスタ３００に割り当てる。任意の数の第１および第２の層のリンクに対して一般化した場合、アービタ１０３２が使用する例示としての公平な割当てポリシーが消費する割当ての使用することができるアドレス・フレームの一部は、下式により表すことができる。
一部（ｆｒａｃｔｉｏｎ）＝（ｔ１／２＋１）／（ｔ２／２＊（ｔ１／２＋１）＋１）
ここで、ｔ１およびｔ２は、処理装置１００を結合することができる第１および第２の層のリンクの全数であり、数値「ｔ１／２＋１」は、処理ノード２０２当たりの処理装置１００の数であり、数値「ｔ２／２」は、下流のハブ１００が結合することができる処理ノード２０２の数であり、一定の数値「１」は下流のハブ１００に割り当てられた帯域幅の一部である。

ブロック１４３９に示すように、アービタ１０３２は、要求アドレスが、バンクを含むリソース１９１０の同じバンク１９１２にハッシュしない場合だけに、前の要求ＦＩＦＯバッファ９１１内にバッファされているＲ−１の前の要求のいずれかとして、全システム・ブロードキャスト要求を発行することにより全システム・ブロードキャスト要求の送信をさらに絞り込む。ここで、１／Ｒは、最も遅い保護されているスヌーピーング・デバイス１９００が要求にサービスすることができる最大到着レートの一部である。それ故、図の方法で全システム・ブロードキャスト要求を絞り込めば、所与の数のサイクル中に所与のスヌーピーング・デバイス１９００のところに到着することができる要求の数が下式のように制限される。
絞り込まれた到着レート（ｔｈｒｏｔｔｌｅｄ＿ａｒｒ＿ｒａｔｅ）
＝Ｒサイクル当たりのＮ要求
ここで、Ｎは処理ノード２０２の数である。好ましくは、スヌーピーング・デバイス１９００は、再試行を行わないでこのような絞り込まれた到着レートで到着する要求を処理するように設計する。

最後にブロック１４４０のところに示す条件について説明すると、アービタ１０３２により、ローカル・ハブ要求マルチプレクサ１０３０は、ＬＨタグＦＩＦＯキュー９２４ａ内の割当てに対してエントリを使用することができる場合だけ要求を出力することができる（ブロック１４４０）。

ブロック１４３４〜１４４０のいずれかで「いいえ」と判断した場合には、ブロック１４３４〜１４４０すべてのブロックでの判断が「はい」である後続のサイクルまで、ブロック１４４２に示すように要求は遅延する。一方、ブロック１４３４〜１４４０すべてのところで「はい」と判断した場合には、アービタ１０３２は、ローカル・ハブ要求マルチプレクサ１０３０に、もしあった場合に、ＬＨアドレス・ランチ・バッファ９１０が提示する要求にいつでも優先権を与えるマルチプレクサ９２０の入力に選択した要求を出力するように信号を送る。それ故、マルチプレクサ９２０は、スヌープ・バス９２２上で要求を発行する。マルチプレクサ９２０の他のポート（例えば、ＲＨ、ＲＬＸ、ＲＬＹ、およびＲＬＺ）は、ＬＨアドレス・ランチ・バッファ９１０と一緒に、スヌープ・バス９２２の最大帯域幅が、最大到着レートに遅れないためにアウトバウンドＡおよびＢリンクの帯域幅の１０／８（図１３の実施形態を仮定した場合）または５／６（図１６の実施形態を仮定した場合）でなければならないことを意味する要求を提示することができることに留意されたい。

また、ローカル・ハブ・アドレス・ランチ・バッファ９１０内にバッファしている要求だけが、アウトバウンドＡおよびＢリンクにより送信され、リンク情報割当て内のアドレス保有期間との整合が要求されることを観察されたい。マルチプレクサ９２０の発行に競合するすべての他の要求は、アウトバウンドＡおよびＢリンクではなくローカル・スヌーパ３０４およびその各ＦＩＦＯキューだけを目標としているので、このような要求を情報フレームの残りのサイクル中に発行することができる。それ故、マルチプレクサ９２０が使用する特定のアービトレーション・スキームが何であれ、マルチプレクサ９２０に同時に提示されるすべての要求の１つの情報フレームの持続時間内での送信が保証される。

ブロック１４４４に示すように、スヌープ・バス９２２上での要求の発行に応じて、ＬＨタグＦＩＦＯキュー９２４ａは、保有期間１３０２を開始する次の使用できるエントリのマスタ・タグ・フィールド１１００内の要求に指定されているマスタ・タグを記録する。次に、要求は、ブロック１４４６に示すように、アウトバウンドＡおよびＢリンクに経路指定される。次に、プロセスは、ページ・コネクタ１４４８を通って、要求フェーズ中の各リモート・ハブのところの要求の処理を示す図２５に進む。

図２５に示すプロセスは、また、ブロック１４４６からＬＨアドレス・ランチ・バッファ９１０、終わりの保有期間１３００からの要求の除去に応じて、要求に割り当てられたローカル・ハブ・トークンを解放するローカル・ハブ１００を示すブロック１４５０に進む。要求は、さらに、ブロック１４５２に示すように、ＬＨタグＦＩＦＯキュー９２４ａ内の割り当てられたエントリを識別するチケット番号と一緒に、ローカル・ハブ１００内のスヌーパ３０４に経路指定される。すでに説明したように、要求は、少なくとも、所望のアクセスのタイプを示すトランザクション・タイプ（Ｔｔｙｐｅ）、要求がアクセスするリソースを示すリソース識別子（例えば、実アドレス）を含み、さらに、（Ｔｔｙｐｅの一部を形成することができる）範囲インジケータおよび動作タグを含むかまたは伴っている。要求を受信すると、チケット番号、範囲インジケータおよび動作タグ、スヌーパ３０４は、必要な場合には、ノードＩＤ２００２、チップＩＤ２００４、マスタ・タグ２００６、チケット番号２０２２および範囲インジケータ２０２４を、図４０に示すように、要求バッファ２０２０内にバッファする。さらに、スヌーパ３０４は、必要な場合には、ＬＨ部分応答ＦＩＦＯキュー９３０、開始保有期間１３０４内に記録される部分応答（ブロック１４５４）を発生する（ブロック１４５６）。より詳細に説明すると、ブロック１４５６において、ＬＨ部分応答ＦＩＦＯキュー９３０内のエントリ１２００は、割当ポインタ１２１０を参照して要求に割り当てられ、割当ポインタ１２１０は増分増大し、ローカル・ハブの部分応答は、割り当てられたエントリの部分応答フィールド１２０２内に収容され、またローカル（Ｌ）フラグは、応答フラグ・フィールド１２０４内に設定される。その後で、ローカル・ハブ１００の要求フェーズ処理はブロック１４５８のところで終了する。

ここで図２６を参照すると、この図は、本発明によるリモート・ハブ（またはノードだけのブロードキャスト要求に対するノード・マスタ）１００のところでの例示としての要求の処理方法のハイレベル論理フローチャートである。図に示すように、全システム・ブロードキャスト要求の場合には、プロセスは、そのインバウンドＡおよびＢリンクの一方上のリモート・ハブ１００のところで要求を受信した場合に、ページ・コネクタ１４４８のところから開始する。すでに説明したように、ブロック１４６０に示すように、各保持バッファ９０２ａ〜９０２ｂに要求がラッチされた後で、ブロック１４６４および１４６５のところに示すように、要求バス９０５により送信するために、要求がリモート・ハブ・マルチプレクサ９０３および要求マルチプレクサ９０４により評価される。より詳細には、ブロック１４６４において、リモート・ハブ・マルチプレクサ９０３は、インバウンドの第２の層のリンク上で受信した要求にアドレス保有期間を均等に割り当てる公平な割当てポリシーにより、要求を出力するかどうかを決定する。さらに、ブロック１４６５に示すように、第１の層のリンク情報割当てとタイムスライス整合している要求マルチプレクサ９０４は、アドレス保有期間を使用することができる場合にだけ要求を出力する。それ故、ブロック１４６６に示すように、要求が、マルチプレクサ９０３の公平な割当てポリシーの下でのウィニング要求でない場合、または次にアドレス保有期間が使用できない場合には、マルチプレクサ９０４は次のアドレス保有期間を受信するために待機する。しかし、インバウンドの第２の層のリンク上で受信した要求が遅延している場合でも、遅延は第１の層のリンク情報割当ての僅か１つのフレームにしか過ぎないことを理解することができるだろう。

ブロック１４６４および１４６５に示す両方の条件が満たされた場合には、マルチプレクサ９０４は、要求バス９０５上で要求をランチし、プロセスはブロック１４６５からブロック１４６８に進む。図に示すように、図２４のブロック１４２１からのものでブロック１４２３において引き続き行われるノード・マスタ１００のところでの要求フェーズ処理もブロック１４６８に進む。ブロック１４６８は、要求バス９０５上で発行された要求のアウトバウンドＸ、ＹおよびＺリンクならびにＮＭ／ＲＨ保持バッファ９０６への経路指定を示す。ブロック１４６８の後で、プロセスは２つに分岐する。第１の経路は、ページ・コネクタ１４７０を通って、リモート（またはノード）リーフ１００のところでの例示としての要求の処理方法を示す図２７に進む。ブロック１４６８からの第２の経路は、その入力のところに提示された要求のうちのどれをスヌープ・バス９２２に出力すべきかを決定するスヌープ・マルチプレクサ９２０を示すブロック１４７４に進む。図に示すように、スヌープ・マルチプレクサ９２０は、リモート・ハブ要求よりも高い優先権をローカル・ハブ要求に与え、リモート・ハブ要求は、ＮＬ／ＲＬ保持バッファ９１４ａ〜９１４ｃ内にバッファされている要求よりも高い優先権を有する。それ故、ローカル・ハブ要求がＬＨアドレス・ランチ・バッファ９１０により選択のために提示された場合には、ブロック１４７６に示すように、ＮＭ／ＲＨ保持バッファ９０６内にバッファされている要求は遅延する。しかし、ＬＨアドレス・ランチ・バッファ９１０により要求が提示されない場合には、スヌープ・マルチプレクサ９２０は、スヌープ・バス９２２上のＮＭ／ＲＨ保持バッファ９０６から要求を発行する。

スヌープ・バス９２２上で要求を検出した場合には、要求ＦＩＦＯキュー９２４ｂのうちの適当なキュー（すなわち、ノードだけのブロードキャスト要求の場合には、ＮＭタグＦＩＦＯキュー９２４ｂ２、全システム・ブロードキャスト要求の場合には、要求を受信したインバウンドの第２の層のリンクに関連するＲＨ仮想ＦＩＦＯキュー９２４ｂ０および９２４ｂ１のうちの１つ）は、要求に、関連するヘッド・ポインタ１１００、開始保有期間１３０６または１３２０が識別した次に使用できるキュー・エントリを割り当てる（ブロック１４７８）。ＮＭタグＦＩＦＯキュー９２４ｂ２がキュー・エントリを割り当てた場合には、マスタ・タグも割り当てられたエントリ内に配置される。すでに説明したように、ノードだけのブロードキャスト要求および全システムのブロードキャスト要求は、要求のＴｔｙｐｅフィールド７００または８００内の範囲識別子７３０または８３０により異なる。リモート・ハブ１００内においては、ブロック１４８０に示すように、動作タグ２０００および関連する要求ＦＩＦＯキュー９２４ｂ内の割り当てられたエントリを識別するチケット番号と一緒に、要求がさらにスヌーパ３０４に経路指定される。

要求、チケット番号および動作タグを受信した場合には、スヌーパ３０４は、必要な場合には、図４０に示すように、要求バッファ２０２０内に、ノードＩＤ２００２、チップＩＤ２００４、マスタ・タグ２００６、チケット番号２０２２および範囲インジケータ２０２４をバッファする。さらに、スヌーパ３０４は、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０、開始保有期間１３０８または１３２２内に記録される部分応答をブロック１４８２のところで発生する（ブロック１４８４）。より詳細には、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内のエントリ１２３０は、その割当ポインタ１２１０を参照して要求に割り当てられ、割当ポインタ１２１０が増分増大し、リモート・ハブの部分応答が、部分応答フィールド１２０２内に収容され、ノード・マスタ／リモート・フラグ（ＮＭ／Ｒ）が応答フラグ・フィールド１２３４内に設定される。それ故、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０が、同じデータ構造の異なる範囲の動作に対する部分応答をバッファすることに留意されたい。その後で、リモート・ハブ１００のところでの要求フェーズ処理はブロック１４８６のところで終了する。

ここで図２７を参照すると、この図は、本発明によるリモート・リーフ（またはノード・リーフ）１００のところでの例示としての要求処理方法のハイレベル論理フローチャートである。図に示すように、プロセスは、そのインバウンドＸ、ＹおよびＺリンクのうちの１つによりリモート・リーフまたはノード・リーフ１００のところで要求を受信した場合に、ページ・コネクタ１４７０のところから開始する。ブロック１４９０に示すように、要求を受信すると、要求は、要求を受信した第１の層のリンクに関連するＮＬ／ＲＬ保持バッファ９１４ａ〜９１４ｃのうちの特定のバッファ内にラッチされる。次に、ブロック１４９１に示すように、要求は、その入力に提示された他の要求と一緒にスヌープ・マルチプレクサ９２０により評価される。すでに説明したように、スヌープ・マルチプレクサ９２０は、リモート・ハブ要求よりも高い優先権をローカル・ハブ要求に与え、リモート・ハブ要求は、ＮＬ／ＲＬ保持バッファ９１４ａ〜９４１ｃ内にバッファされている要求よりも高い優先権を有する。それ故、ローカル・ハブ要求またはリモート・ハブ要求が選択のために提示された場合には、ブロック１４９２に示すように、ＮＬ／ＲＬ保持バッファ９１４内にバッファされている要求は遅延する。しかし、スヌープ・マルチプレクサ９２０により高い優先権要求が提示されなかった場合には、スヌープ・マルチプレクサ９２０は、スヌープ・バス９２２上のＮＬ／ＲＬ保持バッファ９１４から要求を発行し、Ｘ、ＹおよびＺ要求の間で公平な選択を行う。

スヌープ・バス９２２上の要求に応じて、要求の範囲および要求を受信した経路に関連する仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ２、９２４ｄ０〜９２４ｄ２および９２４ｅ０〜９２４ｅ２の特定のキュー内の次に使用することができるエントリが、ヘッド・ポインタ１１００、開始保有期間１３１０または１３２４を参照して割り当てられる（ブロック１４９３）。すなわち、要求のＴｔｙｐｅフィールド７００または８００内の範囲インジケータ７３０または８３０が、要求がノードだけの範囲であるか、または全システムの範囲であるかを判定するために使用される。すでに説明したように、ノードだけのブロードキャスト要求の場合には、要求を受信したインバウンドの第１の層のリンクに関連するＮＬ仮想ＦＩＦＯキュー９２４ｃ２、９２４ｄ２および９２４ｅ２の特定の１つのキュー内でエントリが割り当てられる。全システム・ブロードキャスト要求の場合には、要求を受信したインバウンドの第１および第２の層のリンクの組合せに対応するＲＬ仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１および９２４ｅ０〜９２４ｅ１のうちの特定の１つのキュー内でエントリが割り当てられる。要求、動作タグ２０００、およびＲＬ仮想ＦＩＦＯキュー９２４のうちの１つ内の要求に割り当てられた仮想エントリを識別するチケット番号は、さらに、ブロック１４９４に示すように、リモート・リーフ１００内のスヌーパ３０４に経路指定される。すでに説明したように、要求は、少なくとも、所望のアクセスのタイプを示すトランザクション・タイプ（Ｔｔｙｐｅ）、要求がアクセスするリソースを示すリソース識別子（例えば、実アドレス）を含み、さらに、（Ｔｔｙｐｅの一部を形成することができる）範囲インジケータを含むかまたは伴っている。要求、チケット番号、および動作タグを受信すると、図４０に示すように、スヌーパ３０４は、必要な場合には、ノードＩＤ２００２、チップＩＤ２００４、マスタ・タグ２００６、チケット番号２０２２および範囲インジケータ２０２４を要求バッファ２０２０内にバッファする。また、スヌーパ３０４は、その処理装置１００の部分応答を入手するために、要求を処理し、その各部分応答を発生し、部分応答を蓄積する（ブロック１４９５）。ページ・コネクタ１４９７が示すように、リモート・リーフまたはノード・リーフ１００のスヌーパ３０４の部分応答は、以下に説明する図３０により処理される。

図２８は、図２５〜図２７の例えばブロック１４５４、１４８２、および１４９５のところでスヌーパ３０４が要求に対する部分応答を発生する例示としての方法のハイレベル論理フローチャートである。プロセスは、スヌーパ３０４（例えば、ＩＭＣスヌーパ１２６、Ｌ２キャッシュ・スヌーパ１１６または入出力コントローラ１２８内のスヌーパ）が要求を受信した場合にブロック１４０１から開始する。要求を受信すると、スヌーパ３０４は、要求が指定するトランザクション・タイプを参照して、要求がキャストアウト要求、書込み要求、または部分書込み要求のような書込みタイプの要求であるかどうかを判定する。スヌーパ３０４がブロック１４０３で要求が書込みタイプの要求ではない（例えば、読取りまたはＲＷＩＴＭ要求）と判定した場合には、プロセスは、必要な場合には、従来の処理により要求に対する部分応答を発生するスヌーパ３０４を示すブロック１４０５に進む。しかし、スヌーパ３０４が要求が書込みタイプの要求であると判定した場合には、プロセスはブロック１４０７に進む。

ブロック１４０７は、それが書込みタイプの要求が指定する要求アドレスに対するＬＰＣであるかどうかを判定するスヌーパ３０４を示す。例えば、スヌーパ３０４は、１つまたは複数のベース・アドレス・レジスタ（ＢＡＲ）またはスヌーパ３０４が責任を有するアドレス範囲を指定しているアドレス・ハッシュ関数（すなわち、ＬＰＣ）あるいはその両方を参照して図の判定を行うことができる。スヌーパ３０４がそれが要求アドレスに対するＬＰＣでないと判定した場合には、プロセスはブロック１４０９に進む。ブロック１４０９は、有効フィールド７２２および宛先タグ・フィールド７２４が、すべて「０」からなり、それによりスヌーパ３０４が要求アドレスに対するＬＰＣでないことを意味する書込み要求部分応答７２０（図１４）を発生しているスヌーパ３０４を示す。しかし、スヌーパ３０４が、ブロック１４０７において、それが要求アドレスに対するＬＰＣであると判定した場合には、プロセスは、有効フィールド７２２が「１」に設定され、宛先タグ・フィールド７２４が、宛先タグまたはデータ処理システム２００内でスヌーパ３０４の位置を一意に識別する経路を指定する書込み要求部分応答７２０を発生しているスヌーパ３０４を示すブロック１４１１に進む。ブロック１４０９または１４１１の後で、図２８のプロセスはブロック１４１３において終了する。

ＶＩＩ．部分応答フェーズの構造および動作
ここで図２９を参照すると、この図は、図１の相互接続ロジック１２０内の部分応答ロジック１２１ｂの例示としての実施形態を示すブロック図である。図に示すように、部分応答ロジック１２１ｂは、リモート・リーフ（またはノード・リーフ）１００のところでスヌーパ３０４が発生したリモート部分応答を、アウトバウンドの第１の層のＸ、ＹおよびＺリンクのうちの適当な１つのリンクを介して要求を受信したリモート・ハブ（またはノード・マスタ）１００に経路指定するルート・ロジック１５００を含む。さらに、部分応答ロジック１２１ｂは、結合ロジック１５０２およびルート・ロジック１５０４を含む。結合ロジック１５０２は、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内にバッファされている同じ要求に対する他の部分応答と一緒に、リモート（またはノード）リーフ１００から受信した部分応答を蓄積する。ノードだけのブロードキャスト動作の場合には、ノード・マスタ１００の結合ロジック１５０２は、蓄積した部分応答を応答ロジック１２２に直接提供する。全システムのブロードキャスト動作の場合には、結合ロジック１５０２は、蓄積した部分応答を、蓄積した部分応答をアウトバウンドＡおよびＢリンクのうちの１つを介してローカル・ハブ１００に経路指定するルート・ロジック１５０４に供給する。

部分応答ロジック１２１ｂは、さらに、リモート・ハブ１００からの部分応答を受信し、バッファする保持バッファ１５０６ａ〜１５０６ｂ、保持バッファ１５０６ａ〜１５０６ｂ内にバッファされている部分応答の中から選択するための公平なアービトレーション・ポリシーを適用するマルチプレクサ１５０７、およびマルチプレクサ１５０７が選択した部分応答を、その処理ノード２０２内の他の各処理装置１００にブロードキャストするブロードキャスト・ロジック１５０８を含む。マルチプレクサ１５０７の出力をプログラマブル遅延装置１５０９と結合している経路によりさらに示すように、マルチプレクサ１５０７は、ほぼ１つの第１の層のリンクの待ち時間だけプログラマブル遅延装置１５０９により遅延している部分応答のローカル・ブロードキャストを行い、そのためインバウンドＸ、ＹおよびＺリンク上で他の処理装置１００から受信した部分応答とほぼ同時に、ローカル的にブロードキャストした部分応答が結合ロジック１５１０により受信される。結合ロジック１５１０は、（ＬＨ部分応答ＦＩＦＯキュー９３０内にバッファされている）ローカル的に発生した部分応答と一緒に、インバウンドＸ、ＹおよびＺリンク上で受信した部分応答、およびインバウンドの第２の層のリンクから受信したローカル的にブロードキャストした部分応答を蓄積し、要求に対する結合応答を発生するために蓄積した部分応答を応答ロジック１２２に送る。

ここで図３０〜図３２を参照すると、これらの図は、リモート・リーフ（またはノード・リーフ）、リモート・ハブ（またはノード・マスタ）、およびローカル・ハブのところでの動作の部分応答フェーズ中の例示としての処理をそれぞれ示すフローチャートである。これらの図面中、部分応答の送信は、図には明示していない種々の遅延を受ける。しかし、すでに説明したように、部分応答待ち時間にはタイミングの制約がないので、このような遅延は、もし存在しても、動作中エラーを発生しないのでこれ以上の説明は省略する。

ここで図３０について詳細に説明すると、リモート・リーフ（またはノード・リーフ）１００のところでの部分応答フェーズの処理は、リモート・リーフ（またはノード・リーフ）１００のスヌーパ３０４が要求の部分応答を発生した場合に、ブロック１６００から開始する。ブロック１６０２に示すように、次に、ルート・ロジック１５００は、リンク情報割当のリモート部分応答フィールド７１２または８１２により、要求を受信したインバウンドの第１の層のリンクに対応するアウトバウンドＸ、ＹまたはＺリンクを介して、要求に対するリモート・ハブ１００に部分応答を経路指定する。すでに説明したように、要求を受信し、仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ２、９２４ｄ０〜９２４ｄ２および９２４ｅ０〜９２４ｅ２のうちの１つが要求に仮想エントリを割り当てたインバウンドの第１の層のリンクが示される。その後で、ページ・コネクタ１６０４により示し、図３１を参照して以下に説明するように、リモート・ハブ（またはノード・マスタ）１００のところで部分応答の処理が引き続き行われる。

ここで図３１を参照すると、この図は、本発明によるリモート・ハブ（またはノード・マスタ）のところでの部分応答の処理方法の例示としての実施形態のハイレベル論理フローチャートである。図のプロセスは、第１の層のＸ、ＹおよびＺリンクのうちの１つによりリモート・ハブ（またはノード・マスタ）１００と結合しているリモート・リーフ（またはノード・リーフ）１００のうちの１つの部分応答を受信した場合に、ページ・コネクタ１６０４から開始する。部分応答を受信すると、結合ロジック１５０２は、動作に割り当てられたＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内のエントリ１２３０を読み出す。エントリは、部分応答を受信したリンクに関連するＸ、ＹまたはＺポインタ１２１６〜１２２０が示すように、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０内で観察したＦＩＦＯの順序により識別される。次に、結合ロジック１５０２は、読み取ったエントリ１２３０の部分応答フィールド１２０２の内容と一緒に、リモート（またはノード）リーフ１００の部分応答を蓄積する。すでに説明したように、好ましくは、蓄積動作は、論理ＯＲ演算のような非破壊的動作である。次に、結合ロジック１５０２は、ブロック１６１４のところで、エントリ１２３０の応答フラグ・アレイ１２３４を参照して、ブロック１６０４のところで受信した部分応答により、すべてのリモート・リーフ１００がその各部分応答を報告したかどうかを判定する。報告していない場合には、プロセスは、蓄積した部分応答により動作に割り当てられたエントリ１２３０の部分応答フィールド１２０２を更新し、どのリモート・リーフ１００が部分応答を提供したのかを示すために、応答フラグ・アレイ１２３４内に適当なフラグを設定し、ポインタ１２１６〜１２２０のうちの関連するものを前進させる結合ロジック１５０２を示すブロック１６１６に進む。その後で、プロセスはブロック１６１８のところで終了する。

再度ブロック１６１４について説明すると、結合ロジック１５０２が、すべてのリモート（またはノード）リーフ１００が動作に対する各部分応答を報告したと判定した場合に、結合ロジック１５０２は、割当解除ポインタ１２１２、終了保有期間１３０８または１３２２を参照して、ＮＭ／ＲＨ部分応答ＦＩＦＯキュー９４０からの動作に対するエントリ１２３０の割当を解除する（ブロック１６２０）。ブロック１６２１および１６２３に示すように、エントリのルート・フィールド１２３６が動作がノードだけのブロードキャスト動作であると表示した場合には、結合ロジック１５０２は、蓄積した部分応答を応答ロジック１２２に直接提供する。その後で、プロセスは、以下に説明する図３４のページ・コネクタ１６２５を通して進む。ブロック１６２１に戻って説明すると、割当解除したエントリのルート・フィールド１２３６が、動作がノードだけのブロードキャスト動作でなく、全システム・ブロードキャスト動作であると表示した場合には、結合ロジック１５０２は、代わりに、ブロック１６２２に示すように、リンク割当情報内のリモート部分応答フィールド７１２または８１２により、ルート・フィールド１２３６の内容により表示するアウトバウンドＡおよびＢリンクのうちの特定の１つのリンクに、蓄積した部分応答を経路指定する。その後で、プロセスはページ・コネクタ１６２４を通して図３２に進む。

ここで図３２を参照すると、この図は、本発明のある実施形態によるローカル・ハブ１００（ローカル・マスタ１００を含む）のところでの部分応答処理の例示としての方法のハイレベル論理フローチャートである。プロセスは、インバウンドＡおよびＢリンクの一方を介してリモート・ハブ１００から部分応答のローカル・ハブ１００のところでの受信に応じて、ブロック１６２４から開始する。受信すると、部分応答は、部分応答を受信したインバウンドの第２の層のリンクと結合している保持バッファ１５０６ａ、１５０６ｂ内に収容される。ブロック１６２７に示すように、マルチプレクサ１５０７は、保持バッファ１５０６ａ〜１５０６ｂ内にバッファされている部分応答の中から選択するために、公平なアービトレーション・ポリシーを適用する。それ故、公平なアービトレーション・ポリシーにより部分応答が選択されなかった場合には、ブロック１６２８のところに示すように、部分応答のブロードキャストが遅延する。部分応答が公平なアービトレーション・ポリシーにより選択されると、おそらく遅延の後で、マルチプレクサ１５０７はブロードキャスト・ロジック１５０８およびプログラマブル遅延装置１５０９に部分応答を出力する。マルチプレクサ１５０７の出力バスは、部分応答によりオーバーランにならない。何故なら、部分応答の到着レートが、要求ランチの速度により制限されるからである。ブロック１６２７の後で、プロセスはブロック１６２９に進む。

ブロック１６２９は、第１の層のＸ、ＹおよびＺリンクを介してその処理ノード２０２内で他の各処理装置１００、およびプログラマブル遅延装置１５０９へ部分応答を出力することにより、部分応答のローカル・ブロードキャストを行っているマルチプレクサ１５０７に、マルチプレクサ１５０７が選択した部分応答をブロードキャストしているブロードキャスト・ロジック１５０８を示す。その後で、プロセスは２つに分岐し、他のローカル・バス１００のところでの部分応答フェーズの処理の継続を示すブロック１６３１およびブロック１６３０のそれぞれに進む。ブロック１６３０に示すように、現在のローカル・ハブ１００内の部分応答ブロードキャストは、第１の層のリンクのほぼ送信の待ち時間だけ、プログラマブル遅延装置１５０９により遅延するので、インバウンドＸ、ＹおよびＺリンク上で他の処理装置１００から受信した部分応答とほぼ同時に、ローカル的にブロードキャストした部分応答が結合ロジック１５１０により受信される。ブロック１６４０のところに示すように、結合ロジック１５１０は、インバウンドの第１の層のリンクから受信した部分応答と一緒に、またＬＨ部分応答ＦＩＦＯキュー９３０内にバッファされるローカル的に発生した部分応答と一緒に、ローカル的にブロードキャストした部分応答を蓄積する。

部分応答を蓄積するために、結合ロジック１５１０は、最初に動作に割り当てられたＬＨ部分応答ＦＩＦＯキュー９３０内のエントリ１２００を読み出す。エントリは、部分応答を受信したポインタ１２１４、１２１５のうちの特定の１つのポインタが示すように、ＬＨ部分応答ＦＩＦＯキュー９３０内で観察したＦＩＦＯの順序により識別される。次に、結合ロジック１５１０は、読み取ったエントリ１２００の部分応答フィールド１２０２の内容と一緒に、リモート・ハブ１００のローカル的にブロードキャストした部分応答を蓄積する。次に、ブロック１６４２に示すように、結合ロジック１５１０は、さらに、エントリ１２００の応答フラグ・アレイ１２０４を参照して、現在受信した部分応答により、部分応答を予想した各処理装置１００から部分応答を受信したかどうかを判定する。受信していない場合には、プロセスは、新しく蓄積した部分応答により、ＬＨ部分応答ＦＩＦＯキュー９３０から読み取ったエントリ１２００を更新している結合ロジック１５１０を示すブロック１６４４に進む。その後で、プロセスはブロック１６４６のところで終了する。

ブロック１６４２に戻って説明すると、結合ロジック１５１０が、部分応答を予想するすべての処理装置１００が、その部分応答を報告したと判定した場合には、プロセスはブロック１６５０に進む。ブロック１６５０は、割当解除ポインタ１２１２、終了保有期間１３０４を参照して、ＬＨ部分応答ＦＩＦＯキュー９３０からの動作に割り当てられたエントリ１２００の割当を解除する結合ロジック１５１０を示す。次に、結合ロジック１５１０は、ブロック１６５２に示すように、結合応答を発生するために応答ロジック１２２に、蓄積した部分応答を送る。その後で、プロセスは、ページ・コネクタ１６５４を通って、ローカル・ハブ１００のところでの結合応答処理を示す図３４に進む。

ここでブロック１６３２に戻って説明すると、１つまたは複数の第１の層のリンク上でローカル・ハブ１００が受信した部分応答の処理は、結合ロジック１５１０が部分応答を受信した場合に開始する。ブロック１６３４に示すように、結合ロジック１５１０は、部分応答の処理を他の各部分応答およびローカル的にブロードキャストした部分応答と同期させるために、短い調整遅延をインバウンドの第１の層のリンク上で受信した部分応答に適用することができる。その後で、部分応答は、すでに説明したブロック１６４０および後続のブロックのところに示すように処理される。

ＶＩＩＩ．結合応答フェーズの構造および動作
ここで図３３を参照すると、この図は、本発明による図１の相互接続ロジック１２０内の結合応答ロジック１２１ｃの例示としての実施形態のブロック図である。図に示すように、結合応答ロジック１２１ｃは、各インバウンドＡおよびＢリンクによりローカル・ハブ１００と結合しているリモート・ハブ１００から結合応答をそれぞれ受信し、バッファする保持バッファ１７０２ａ〜１７０２ｂを含む。保持バッファ１７０２ａ〜１７０２ｂの出力は、情報フレームの結合応答フィールド７１０または８１０内の第１のバス１７０５上にランチするために、もしあった場合に、保持バッファ１７０２ａ〜１７０２ｂがバッファする結合応答の中から選択するために公平なアービトレーション・ポリシーを適用する第１のマルチプレクサ１７０４の２つの入力を形成する。

第１のマルチプレクサ１７０４は、保持バッファ１７０２ａ〜１７０２ｂ内に結合応答が全然存在しない場合に、情報フレームの結合応答フィールド７１０または８１０内の第１のバス１７０５上に選択およびランチするために、応答ロジック１２２によりノードだけのブロードキャスト動作の結合応答が提示される第３の入力を有する。第１のマルチプレクサ１７０４は、いつでも、リモート・ハブ１００から受信した全システム・ブロードキャスト動作に対する結合応答に、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答に対するよりも高い優先権を与えるので、応答ロジック１２２は、ある動作条件の場合には、第１のマルチプレクサ１７０４がそれが提示する結合応答を選択するために、かなりの時間待機しなければならない場合がある。それ故、最悪の場合には、応答ロジック１２２は、所与の処理装置１００が、任意の時点でフライト中に有することができるノードだけのブロードキャスト動作の最大数を決定するＮＭタグＦＩＦＯキュー９２４ｂ２内のエントリの数に等しいいくつかの結合応答および部分応答のペアをキュー内に入れることができなければならない。結合応答がかなりの時間遅延しても、マスタ３００およびスヌーパ３０４による結合応答の観察は、同じ長さの時間だけ遅延する。それ故、結合応答の遅延ランチは、上記タイミング制限に違反する恐れはない。何故なら、ウィニング・マスタ３００による結合応答の観察と所有スヌーパ３０４による結合応答の観察との間の時間は、それにより短縮しないからである。

第１のバス１７０５は、アウトバウンドＸ、ＹおよびＺリンクのそれぞれおよびノード・マスタ／リモート・ハブ（ＮＭ／ＲＨ）バッファ１７０６と結合している。ノードだけのブロードキャスト動作の場合には、ＮＭ／ＲＨバッファ１７０６は、このノード・マスタ１００のところで応答ロジック１２２が提供する結合応答および蓄積した部分応答（すなわち、宛先タグ）をバッファする。

インバウンドの第１の層のＸ、ＹおよびＺリンクは、それぞれ各リモート・リーフ（ＲＬ）バッファ１７１４ａ〜１７１４ｃと結合している。ＮＭ／ＲＨバッファ１７０６およびＲＬバッファ１７１４ａ〜１７１４ｃの出力は、第２のマルチプレクサ１７２０の４つの入力を形成する。第２のマルチプレクサ１７２０は、全システムのブロードキャスト動作の場合には、このローカル・ハブ１００のところで応答ロジック１２２が提供する結合応答および蓄積した部分応答（すなわち、宛先タグ）をバッファするローカル・ハブ（ＬＨ）保持バッファ１７１０の出力と結合している追加の第５の入力を有する。第２のマルチプレクサ１７２０の出力は、要求ＦＩＦＯキュー９２４およびアウトバウンドの第２の層のリンクが結合している第２のバス１７２２上で結合応答を駆動する。図に示すように、要求ＦＩＦＯキュー９２４は、さらに、追加のチャネルを介して、ＬＨ保持バッファ１７１０またはＮＭ／ＲＨバッファ１７０６内にバッファされている蓄積した部分応答（すなわち、宛先タグ）を受信するために結合している。マスタ３００およびスヌーパ３０４は、さらに要求ＦＩＦＯキュー９２４と結合している。要求ＦＩＦＯキュー９２４と接続しているので、スヌーパ３０４は、結合応答を観察することができ、関連するマスタ３００は、もしある場合には、結合応答および宛先タグを受信することができる。

上記ウィンドウ拡張部３１２ｂがなくても、ほぼ同時にマスタ３００およびスヌーパ３０４により結合応答を観察すると、ある動作シナリオの場合には、ウィニング・マスタ３００からスヌーパ３０４ｎ（すなわち、Ｃ＿ｌａｔ（ＷＭ＿Ｓ））への結合応答待ち時間に関連するタイミング制約期間を、タイミング制約に違反にしてゼロに近づけることができる。しかし、ウィンドウ拡張部３１２ｂは、ほぼ第１の層のリンク送信待ち時間の持続時間を有しているので、マスタ３００およびスヌーパ３０４により結合応答をほぼ同時に観察しても、上記タイミング制約を満足させることができる。

ここで図３４〜図３６を参照すると、これらの図は、本発明の例示としての実施形態によるローカル・ハブ（またはノード・マスタ）、リモート・ハブ（またはノード・マスタ）、およびリモート・リーフ（またはノード・リーフ）のところでの例示としての結合応答フェーズの処理をそれぞれ示すハイレベル論理フローチャートである。ここで図３４についてより詳細に説明すると、ローカル・ハブ（またはノード・マスタ）１００のところでの結合応答フェーズの処理はブロック１８００から開始し、次に、要求のタイプおよび蓄積した部分応答に基づいて動作に対する結合応答を発生する応答ロジック１２２を示すブロック１８０２に進む。ブロック１８０３〜１８０５に示すように、結合応答７１０または８１０内の範囲インジケータ７３０または８３０が、動作がノードだけのブロードキャスト動作であることを示している場合には、ノード・マスタ１００のところでの結合応答フェーズ処理は、図３５のブロック１８６３のところで続行される。しかし、範囲インジケータ７３０または８３０が動作が全システム・ブロードキャスト動作であることを示している場合には、リモート・ハブ１００の応答ロジック１２２は、ブロック１８０４のところに示すように、結合応答および蓄積した部分応答をＬＨ保持バッファ１７１０内に収容する。ＯＲ演算による部分応答の蓄積のために、書込みタイプの要求の場合には、蓄積した部分応答は、付随の宛先タグ・フィールド７２４内に有効宛先タグが存在することを意味する「１」に設定された有効フィールド７２２を含む。他のタイプの要求の場合には、蓄積した部分応答のビット０は、このような宛先タグを含んでいないことを示すために「０」に設定される。

ブロック１８４４のところに示すように、第２のマルチプレクサ１７２０は、選択した第２の層のリンク情報割当てとタイム・スライス整合していて、アドレス保有期間がアウトバウンドの第２の層のリンク情報割当て内の結合応答に対して使用できる場合だけ、ランチ（launch）のためにＬＨ保持バッファ１７１０から結合応答および蓄積した部分応答を選択する。それ故、例えば、第２のマルチプレクサ１７２０は、図１３の実施形態のサイクル１または３、または図１６の実施形態のサイクル１の間だけ結合応答および蓄積した部分応答をＬＨ保持バッファ１７１０から出力する。ブロック１８４４において「いいえ」の判断が行われた場合には、ＬＨ保持バッファ１７１０内の結合応答のランチは、ブロック１８４６に示すように、アドレス保有期間を使用することができる以降のサイクルまで遅延する。一方、ブロック１８４４において「はい」の判断が行われた場合には、第２のマルチプレクサ１７２０は、優先的に第２のバス１７２２上へのランチおよびアウトバウンドの第２の層のリンク上の以降の送信のために、その他の入力よりもＬＨ保持バッファ１７１０内の結合応答を選択する。

また、第２のマルチプレクサ１７２０の他のポート（例えば、ＲＨ、ＲＬＸ、ＲＬＹ、およびＲＬＺ）は、ＬＨ保持バッファ１７１０と一緒に、第２のバス１７２２の最大帯域幅が、最大到着レートに遅れないために、アウトバウンドの第２の層のリンクの帯域幅の１０／８（図１３の実施形態を仮定した場合には）、または５／６（図１６の実施形態を仮定した場合には）でなければならないことを意味する要求を提示することができることに留意されたい。また、ＬＨ保持バッファ１７１０内にバッファしている結合応答だけが、アウトバウンドの第２の層のリンク上で送信され、リンク情報割当て内のアドレス保有期間との整合が要求されることを観察されたい。第２のマルチプレクサ１７２０の発行に競合するすべての他の結合応答は、アウトバウンドの第２の層のリンクではなくローカル・マスタ３００、スヌーパ３０４およびその各ＦＩＦＯキューのみを目標としているので、このような結合応答を情報フレームの残りのサイクル中に発行することができる。それ故、第２のマルチプレクサ１７２０が使用する特定のアービトレーション・スキームが何であれ、第２のマルチプレクサ１７２０に同時に提示されるすべての結合応答は、１つの情報フレームの待ち時間内に送信されることが保証される。

第２のバス１７２２上での結合応答の発行の後で、プロセスは２つに分岐し、ブロック１８４８および１８５２のそれぞれに進む。ブロック１８４８は、第２のバス１７２２上にランチした結合応答のリモート・ハブ１００への送信のためのアウトバウンドの第２の層のリンクへの経路指定を示す。その後で、プロセスはページ・コネクタ１８５０を通して、リモート・ハブ１００のところでの結合応答処理の例示としての方法を示す図３６に進む。

ここでブロック１８５２について説明すると、第２のバス１７２２上で発行された結合応答も、テール・ポインタ１１０２ａにより識別されるその内部の最も古いエントリからマスタ・タグを入手するために、ＬＨタグＦＩＦＯキュー９２４ａへの問い合わせをおこなうために使用される。その後で、ＬＨタグＦＩＦＯキュー９２４ａは、動作に割り当てられたエントリの割当てを解除し、テール・ポインタ１１０２ａ、終了保有期間１３０２を進める（ブロック１８５４）。ブロック１８５４の後で、プロセスは２つに分岐し、ブロック１８１０および１８５６のそれぞれに進む。ブロック１８１０のところで、ＬＨタグＦＩＦＯキュー９２４ａに関連する図示していないロジックが、マスタ・タグが、結合応答に関連する要求を開始したマスタ３００が、このローカル・ハブ１００内に常駐していることを表示したかどうかを判定する。常駐していると表示しなかった場合には、この経路内の処理はブロック１８１６のところで終了する。しかし、マスタ・タグが、発呼マスタ３００が現在のローカル・ハブ１００内に常駐していると表示した場合には、ＬＨタグＦＩＦＯキュー９２４ａは、マスタ・タグ、結合応答および蓄積した部分応答をマスタ・タグが識別した発呼マスタ３００に経路指定する（ブロック１８１２）。結合応答およびマスタ・タグを受信した場合には、発呼マスタ３００は結合応答を処理し、対応する要求が書込みタイプの要求であった場合には、蓄積した部分応答を処理する（ブロック１８１４）。

マスタ３００は、各マスタ３００のところで例示としての結合応答資格付与ロジック２００８により、結合応答がその要求のうちの１つに対する結合応答であることを確認するために、結合応答に資格を与えることができる。図３９に示すように、マスタ３００は、自身に割り当てられたマスタ・タグ２００６のコピーを保持する。マスタ３００が結合応答２０１４を受信した場合には、結合応答２０１４は 図３８に示す動作タグ２０００を伴い、それぞれ処理ノード２０２を識別するノードＩＤ２００２、チップＩＤ２００４、およびマスタ・タグ２００６、プロセッサ１００および動作を開始する特定のマスタ３００を含む。

結合応答２０１４が付随の動作タグを受信した場合には、マスタ３００は、マスタのマスタ・タグ２００６を、結合応答２０１４と一緒に受信した動作タグ２０００の対応するマスタ・タグ２００６と比較するためのコンパレータ２０１０により、結合応答２０１４がその要求のうちの１つに対するものであるかどうかを判定する。コンパレータ２０１０の出力は、その他の入力としてマスタＣＲｅｓｐ有効信号を有するＡＮＤゲート２０１２によりさらに資格が与えられる。コンパレータ２０１０が一致を示し、マスタＣＲｅｓｐ有効信号がアサートされた場合には、ＡＮＤゲート２０１２はその出力をアサートし、マスタ３００が受信した結合応答２０１４が、マスタ３００の未解決の要求へのシステム応答であることを示す。マスタ３００が結合応答２０１４がその要求のうちの１つに対するものであると判定した場合には、マスタ３００は適当な処理を行う。

例えば、結合応答が「成功」を示していて、対応する要求が読取りタイプの要求（例えば、読取り、ＤＣｌａｉｍまたはＲＷＩＴＭ要求）である場合には、発呼マスタ３００は、要求したメモリ・ブロックを受信するために更新または準備を行うことができる。この場合、蓄積した部分応答は破棄される。結合応答が「成功」を示していて、対応する要求が書込みタイプの要求（例えば、キャストアウト、書込み、または部分書込み要求）である場合には、発呼マスタ３００は、蓄積した部分応答から宛先タグ・フィールド７２４を抽出し、その内容をその宛先に動作の以降のデータ・フェーズを経路指定するために使用したデータ・タグ７１４または８１４として使用する。「成功」結合応答が、発呼マスタ３００のＨＰＣ状態の許可を示すか、または意味している場合には、発呼マスタ３００は、さらに、参照番号３１３および１３１４のところに示すように、メモリ・ブロックのその所有権の保護を開始する。しかし、ブロック１８１４のところで受信した結合応答が、「再試行」のような他の結果を示している場合には、発呼マスタ３００に、おそらく異なる範囲（例えば、ローカルでなくグローバル）で要求の再発行を要求することができる。その後で、プロセスはブロック１８１６のところで終了する。

ここでブロック１８５６について説明すると、ＬＨタグＦＩＦＯキュー９２４ａも、ローカル・ハブ１００内のスヌーパ３０４に、結合応答、範囲インジケータ、および関連するチケット番号（すなわち、キュー・エントリ識別子）を経路指定する。チケット番号自身が関連する要求ＦＩＦＯキュー９２４を示していない場合には、チケット番号が属する要求ＦＩＦＯキュー９２４の表示（すなわち、結合応答が横断する経路を示すルート表示）も、スヌーパ３０４に送られる。結合応答および関連する情報を受信した場合には、スヌーパ３０４は、結合応答を処理し、それに応じて必要なすべての動作を行う（ブロック１８５７）。

ここで図４０を参照すると、この図は、各スヌーパ３０４のところの例示としての結合応答資格付与ロジック２０１８の例示としての実施形態である。図に示すように、スヌーパ３０４は、それぞれがスヌーパ３０４が観察している要求を記述している情報を保持している１つまたは複数の要求バッファ２０２０を有する。要求バッファ２０２０内の情報は、要求の動作タグ２０００からのノードＩＤ２００２、チップＩＤ２００４およびマスタ・タグ２００６、要求ＦＩＦＯキュー９２４のうちの１つからの要求に割り当てられたチケット番号２０２２、および（例えば、範囲インジケータ７３０または８３０の設定により表示した）要求の範囲を示す範囲インジケータ２０２４を含む。

要求に割り当てられたチケット番号自身が、それが関連する要求ＦＩＦＯキュー９２４を一意に識別しない場合には、異なる要求ＦＩＦＯキュー９２４に割り当てられたチケット番号間でのエイリアシングを除去するために、ある種の機構が実施される。例えば、チケット番号が割り当てられる要求ＦＩＦＯキュー９２４の別の表示を要求バッファ２０２０内にバッファすることができる。別の方法としては、図４０に示すように、ルート・ロジック２０３４を実施することもできる。

図に示すように、ルート・ロジック２０３４は、入力として、結合応答２０１４のチケット番号が属する要求ＦＩＦＯキュー９２４の表示、およびスヌーパ３０４のノードＩＤを受信する。これらの入力に基づいて、ルート・ロジック２０３４は、全システム範囲の要求の要求マスタ３００のノードＩＤを判定する。（ノードだけの範囲の動作は、スヌーパ３０４として同じノード内で発呼することがわかっている。）例えば、さらに図２を参照すると、処理ノード２０２ｂ０の処理装置１００ｄ内のスヌーパ３０４が、そのＲＬ［Ａ，Ｚ］仮想ＦＩＦＯキュー９２４ｅ０に関連するチケット番号と一緒に、全システム範囲の動作に対する結合応答２０１４を受信した場合には、ルート・ロジック２０３４は、動作の要求しているマスタ３００が、ＡおよびＺ通信リンクの組合せにより処理ノード２０２ｂ０の処理装置１００ｄと結合している処理ノード２０２ａ０内に存在するにちがいないと判定する。要求ＦＩＦＯキュー表示およびスヌーパ・ノードＩＤからルート・ロジック２０３４が判定したマスタ・ノードＩＤは、必要な場合には、異なる要求ＦＩＦＯキュー９２４に属するチケット番号を明確にするために使用することができる。

図４０にさらに示すように、応答資格付与ロジック２０１８は、さらに、ルート・ロジック２０３４が決定したマスタ・ノードＩＤ、結合応答チケット番号、および結合応答範囲インジケータを、要求バッファ２０２０の対応するフィールドと比較するためのコンパレータ２０３０を含む。コンパレータ２０３０の出力は、その他の入力としてスヌーパＣＲｅｓｐ有効信号を有するＡＮＤゲート２０３２によりさらに資格が与えられる。コンパレータ２０３０が一致を示し、スヌーパＣＲｅｓｐ有効信号がアサートされた場合には、ＡＮＤゲート２０３２はその出力をアサートし、スヌーパ３０４が受信した結合応答２０１４が、情報が要求バッファ２０２０内にバッファされる要求に対するシステム応答であることを示す。次に、スヌーパ３０４は、結合応答２０１４により何かが表示されている場合には、行動を行う。

例えば、スヌーパ３０４は、要求の発呼マスタ３００に、要求したメモリ・ブロックの出所を明確にし、要求したメモリ・ブロック等のキャッシュしたコピーを無効にすることができる。結合応答がスヌーパ３０４が要求しているマスタ３００へメモリ・ブロックの所有権を移すべきであるという表示を含む場合には、スヌーパ３０４は、その保護ウィンドウ３１２ａの末尾に、図のトポロジの場合には、好ましくは、第１の層のリンク上の１つのチップ・ホップの待ち時間にほぼ等しい持続時間を有するプログラム可能な長さのウィンドウ拡張部３１２ｂを添付する（ブロック１８５８）。もちろん、他のデータ処理システム・トポロジおよび相互接続ロジック１２０の異なる実施態様の場合には、プログラム可能なウィンドウ拡張部３１２ｂは、リンクの待ち時間の違い（例えば、異なる処理ノード２０２を結合している異なる長さのケーブル）、トポロジ的または物理的制約、回路設計制約、または種々の動作フェーズの限定された待ち時間の大きな変動を補償するために、他の長さに有利に設定することができる。その後で、ローカル・ハブ１００のところでの結合応答フェーズの処理はブロック１８５９のところで終了する。

ここで図３５を参照すると、この図は、本発明によるリモート・ハブ（またはノード・マスタ）１００のところでの結合応答フェーズの処理の例示としての方法のハイレベル論理フローチャートである。図に示すように、リモート・ハブ１００のところでの結合応答フェーズの処理の場合には、プロセスは、そのインバウンドＡまたはＢリンクの一方上でリモート・ハブ１００のところで結合応答を受信した場合に、ページ・コネクタ１８６０から開始する。次に、ブロック１８６２に示すように、結合応答が保持バッファ１７０２ａ〜１７０２ｂの関連する１つのバッファ内にバッファされる。次に、バッファされた結合応答は、ブロック１８６４および１８６５に示す両方の条件が満たされるや否や、第１のバス１７０５上で第１のマルチプレクサ１７０４により送信される。より詳細に説明すると、アドレス保有期間を第１の層のリンク情報割当て内で使用することができなければならないし（ブロック１８６４）、第１のマルチプレクサ１７０４により実施した公平な割当てポリシーは、結合応答がバッファされる保持バッファ１７０２ａ、１７０２ｂを選択しなければならない（ブロック１８６５）。

ブロック１８６４に示すように、これらの条件のいずれかが満たされなかった場合、第１のバス１７０５上に第１のマルチプレクサ１７０４による結合応答のランチは、次のアドレス保有期間まで遅延する。しかし、ブロック１８６４および１８６５に示す条件が両方とも満たされた場合には、プロセスはブロック１８６５から、結合応答フィールド７１０または８１０内のアウトバウンドＸ、ＹおよびＺリンクおよびＮＭ／ＲＨ保持バッファ１７０６へ第１のバス１７０５により結合応答をブロードキャストしている第１のマルチプレクサ１７０４を示すブロック１８６８へ進む。ブロック１８６３および１８６７〜ブロック１８６８を含む経路の接続で示すように、ノードだけのブロードキャスト動作の場合には、第１のマルチプレクサ１７０４は、保持バッファ１７０２ａ〜１７０２ｂにより競合する結合応答が提示されていない場合だけ、アウトバウンドＸ、ＹおよびＺリンクおよびＮＭ／ＲＨ保持バッファ１７０６に経路指定するために、第１のバス１７０５上に応答ロジック１２２が提示した結合応答を発行する。インバウンドの第２の層のリンクのうちの１つを介してリモート・ハブ１００から全システム・ブロードキャスト動作に対して何らかの競合結合応答を受信した場合には、ブロック１８６７に示すように、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答は遅延する。最後に、第１のマルチプレクサ１７０４が、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答を選択した場合には、応答ロジック１２２は、関連する蓄積した部分応答をＮＭ／ＲＨ保持バッファ１７０６内に直接収容する。

ブロック１８６８の後で、プロセスは２つに分岐する。第１の経路は、ページ・コネクタ１８７０を通って、リモート・リーフ（またはノード・リーフ）１００のところでの結合応答フェーズの処理の例示としての方法を示す図３６に進む。ブロック１８６８からの第２の経路は、その入力のところに提示される結合応答のうちのどれが、第２のバス１７２２上に出力するのかを決定する第２のマルチプレクサ１７２０を示すブロック１８７４に進む。すでに説明したように、第２のマルチプレクサ１７２０は、リモート・ハブ結合応答よりも高い優先権をローカル・ハブ結合応答に与え、リモート・ハブ結合応答は、リモート・リーフ・バッファ１７１４ａ〜１７１４ｃ内にバッファされている結合応答よりも高い優先権を有する。それ故、ローカル・ハブ結合応答がＬＨ保持バッファ１７１０により選択のために提示された場合には、ブロック１８７６に示すように、リモート・ハブ・バッファ１７０６内にバッファされている結合要求は遅延する。しかし、ＬＨ保持バッファ１７１０により結合応答が提示されなかった場合には、第２のマルチプレクサ１７２０は、第２のバス１７２２上にＮＭ／ＲＨバッファ１７０６から結合応答を発行する。

第２のバス１７２２上で結合応答を検出した場合には、結合応答を受信した第２の層のリンクに関連する仮想ＦＩＦＯキュー９２４ｂ０および９２４ｂ１のうちの特定の１つのキューのテール・ポインタ１１０２（またはノードだけのブロードキャスト動作の場合には、物理ＮＭタグＦＩＦＯキュー９２４ｂ２）が、ブロック１８７８に示すように、要求に割り当てられたチケット番号を決定するためにアクセスされる。ＮＭタグＦＩＦＯキュー９２４ｂ２がアクセスされると、マスタ・タグも、アクセスしたキュー・エントリから読み出される。次に、テール・ポインタ１１０２は、仮想または物理キュー・エントリ、終了保有期間１３０６または１３２０の割当てを解除するために前進する（ブロック１８８０）。次に、プロセスは２つに分岐し、ブロック１８８２および１８８１のそれぞれに進む。ブロック１８８２は、（範囲インジケータと一緒に）結合応答を経路指定するタグＦＩＦＯキュー９２４ｂのうちの関連する１つのキュー、チケット番号、および必要な場合には、リモート・ハブ（またはノード・マスタ）１００内のスヌーパ３０４への要求ＦＩＦＯキュー表示を示す。結合応答および関連する情報を受信した場合、すでに説明したように、スヌーパ３０４は、結合応答を処理し（ブロック１８８４）、すべての必要な動作を行う。動作が全システム・ブロードキャスト動作であり、結合応答がスヌーパ３０４はメモリ・ブロックのコヒーレンシ所有権を要求しているマスタ３００に移転すべきであるという表示を含む場合には、ブロック１８８５に示すように、スヌーパ３０４は、ウィンドウ拡張部３１２ｂをその保護ウィンドウ３１２ａに添付する。その後で、リモート・ハブ１００のところの結合応答フェーズの処理は、ブロック１８８６で終了する。

ここでブロック１８８１について説明すると、結合応答フィールド７１０または８１０内の範囲インジケータ７３０または８３０が、動作がノードだけのブロードキャスト動作ではなく、全システム・ブロードキャスト動作であることを示している場合には、リモート・ハブ１００のところでこれ以上処理は行われず、プロセスはブロック１８８６のところで終了する。しかし、範囲インジケータ７３０または８３０が、動作がノードだけのブロードキャスト動作であることを示している場合には、プロセスは、マスタ・タグ、結合応答および蓄積した部分応答を、マスタ・タグが識別する発呼マスタ３００に経路指定するＮＭタグＦＩＦＯキュー９２４ｂ２を示すブロック１８８３に進む。結合応答およびマスタ・タグを受信した場合には、発呼マスタ３００は、図３９のところで説明したように、結合応答に資格を与える。結合応答が発呼マスタ３００の要求に属するものとしての資格を与えられた場合には、発呼マスタ３００は結合応答を処理し、対応する要求が書込みタイプの要求であった場合には、蓄積した部分応答を処理する（ブロック１８８７）。

例えば、結合応答が「成功」を示していて、対応する要求が読取りタイプの要求（例えば、読取り、ＤＣｌａｉｍまたはＲＷＩＴＭ要求）であった場合には、発呼マスタ３００は、要求したメモリ・ブロックを受信するために更新または準備を行うことができる。この場合、蓄積した部分応答は破棄される。結合応答が「成功」を示していて、対応する要求が書込みタイプの要求（例えば、キャストアウト、書込みまたは部分書込み要求）である場合には、発呼マスタ３００は、蓄積した部分応答から宛先タグ・フィールド７２４を抽出し、その内容をその宛先に動作の以降のデータ・フェーズを経路指定するために使用したデータ・タグ７１４または８１４として使用する。「成功」結合応答が、発呼マスタ３００のＨＰＣ状態の許可を示すか、意味する場合には、発呼マスタ３００は、さらに、参照番号３１３および１３１４のところに示すように、メモリ・ブロックのその所有権の保護を開始する。しかし、ブロック１８１４のところで受信した結合応答が、「再試行」のような他の結果を示している場合には、発呼マスタ３００に要求の再発行を要求することができる。その後で、プロセスはブロック１８８６のところで終了する。

ここで図３６を参照すると、この図は、本発明によるリモート（またはノード）リーフ１００のところでの結合応答フェーズの処理の例示としての方法のハイレベル論理フローチャートである。図に示すように、プロセスはそのインバウンドＸ、ＹおよびＺリンクのうちの１つ上のリモート（またはノード）リーフ１００のところで結合応答を受信した場合に、ページ・コネクタ１８８８のところから開始する。ブロック１８９０に示すように、結合応答は、ＮＬ／ＲＬ保持バッファ１７１４ａ〜１７１４ｃのうちの１つ内にラッチされる。次に、ブロック１８９１のところに示すように、結合応答は、その入力に提示された他の結合応答と一緒に第２のマルチプレクサ１７２０により評価される。すでに説明したように、第２のマルチプレクサ１７２０は、リモート・ハブ結合応答よりも高い優先権をローカル・ハブ結合応答に与え、リモート・ハブ結合応答は、ＮＬ／ＲＬ保持バッファ１７１４ａ〜１７１４ｃ内にバッファされている結合応答よりも高い優先権を有する。それ故、ローカル・ハブまたはリモート・ハブ結合応答が選択のために提示された場合には、ブロック１８９２に示すように、ＮＬ／ＲＬ保持バッファ１７１４内にバッファされている結合応答は遅延する。しかし、第２のマルチプレクサ１７２０により高い優先権の結合応答が提示されなかった場合には、第２のマルチプレクサ９２０は、第２のバス１７２２上にＮＬ／ＲＬ保持バッファ１７１４から結合応答を発行する。

第２のバス１７２２上で結合応答を検出した場合には、動作範囲および結合応答を受信した経路に関連する仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ２、９２４ｄ０〜９２４ｄ２、および９２４ｅ０〜９２４ｅ２のうちの特定の１つのキューのテール・ポインタ１１０２が、ブロック１８９３に示すように、関連する要求のチケット番号を決定するためにアクセスされる。すなわち、結合応答フィールド７１０または８１０内の範囲インジケータ７３０または８３０は、要求がノードだけの範囲であるか、または全システムの範囲であるかを判定するために使用される。ノードだけのブロードキャスト要求の場合には、結合応答を受信したインバウンドの第１の層のリンクに関連するＮＬ仮想ＦＩＦＯキュー９２４ｃ２、９２４ｄ２および９２４ｅ２のうちの特定の１つのキューのテール・ポインタ１１０２が、チケット番号を決定するためにアクセスされる。全システム・ブロードキャスト要求の場合には、結合応答を受信したインバウンドの第１および第２の層のリンクの組合せに対応するＲＬ仮想ＦＩＦＯキュー９２４ｃ０〜９２４ｃ１、９２４ｄ０〜９２４ｄ１および９２４ｅ０〜９２４ｅ１のうちの特定の１つのキューのテール・ポインタ１１０２が、チケット番号を決定するためにアクセスされる。

関連する仮想ＦＩＦＯキュー９２４が、動作のために適当なエントリを識別すると、仮想ＦＩＦＯキュー９２４のテール・ポインタ１１０２は、エントリ、終了保有期間１３１０または１３２４の割当てを解除するために前進する（ブロック１８９４）。結合応答（範囲インジケータを含む）、チケット番号、および必要な場合には、要求ＦＩＦＯ表示が、ブロック１８９５に示すように、リモート（またはノード）リーフ１００内のスヌーパ３０４にさらに経路指定される。結合応答および関連する情報を受信した場合には、すでに説明したように、スヌーパ３０４は、結合応答を処理し（ブロック１８９６）、すべての必要な動作を行う。動作がノードだけの動作でなく、また結合応答がスヌーパ３０４はメモリ・ブロックのコヒーレンシ所有権を要求しているマスタ３００に移転すべきであるという表示を含む場合には、すでに説明したように、またブロック１８９７に示すように、スヌーパ３０４は、ウィンドウ拡張部３１２ｂをその保護ウィンドウ３１２ａ（および図２２の保護ウィンドウ１３１２）の末尾に添付する。その後で、リモート・リーフ１００のところの結合応答フェーズの処理は、ブロック１８９８で終了する。

ＩＸ．データ・フェーズの構造および動作
データ・ロジック１２１ｄおよびデータ発送のその処理は、種々の方法で実施することができる。１つの好ましい実施形態の場合には、データ・ロジック１２１ｄおよびその動作は、前記米国特許公開第２００６０１７９２５２号及び米国特許公開第２００６０１８７９３９号に詳細に記載してある方法で実施することができる。

Ｘ．結論
今まで説明してきたように、本発明は、改良形処理装置、データ処理システムおよびデータ処理システムのための相互接続ファブリックを提供する。本明細書に開示する本発明のデータ処理システムのトポロジは、システム・スケールで相互接続帯域幅を増大する。さらに、本明細書に開示するトポロジを使用するデータ処理システムは、個々の処理ノードの接続、切離しまたは修理による結果としてのデータ処理システム内の処理装置間の通信を中断しないで、ホット・アップグレードすることもできるし（すなわち、動作中に処理ノードを追加することもできるし）、ダウングレードすることもできるし（すなわち、処理ノードを除去することもできるし）、または修理することもできる。

本発明は、また、種々の範囲（例えば、ノードだけのブロードキャスト・モード、全システム・ブロードキャスト範囲）の動作の同時の流れを有利にサポートする。ご理解いただけると思うが、全システム範囲以下の動作に対するサポートは、相互接続ファブリック上の帯域幅を有利に保存し、システム全体の性能を向上させる。本発明は、また少なくとも２つの他の処理装置間の通信経路内に介在する中間処理装置のキュー要件を緩和する改良形動作追跡機構を提供する。中間処理装置のところの動作追跡機構は、その処理装置内でマスタが開始した要求のマスタ・タグを格納するための物理キューを含む。さらに、動作追跡機構は、他の処理装置内でマスタが開始し、その処理装置による上記各第２の要求の観察の順序を示すチケット番号を有するその処理装置のところで観察した各要求に関連するチケット発行機構を含む。

好ましい実施形態を参照しながら本発明を詳細に図示し、説明してきたが、当業者であれば本発明の精神および範囲から逸脱することなしに、形状および詳細を種々に変更することができることを理解することができるだろう。例えば、本発明は、動作に関連するタグおよび部分応答の順序を決めるためにＦＩＦＯキューを使用する好ましい実施形態を開示しているが、当業者であれば、上記方法で動作の種々のタグおよび部分応答間の順序を維持するために他の順序のデータ構造を使用することができることを理解することができるだろう。さらに、本発明の好ましい実施形態は、一方向通信リンクを使用しているが、当業者であれば、上記説明により二方向通信リンクを別の方法として使用することができることを理解することができるだろう。

本発明による処理装置のハイレベル・ブロック図である。 本発明による例示としてのデータ処理システムのハイレベル・ブロック図である。 要求フェーズ、部分応答フェーズおよび結合応答フェーズを含む例示としての動作の時間空間図である。 図２のデータ処理システム内の全システム範囲の例示としての動作の時間空間図である。 図２のデータ処理システム内のノードだけの範囲の例示としての動作の時間空間図である。 図４の例示としての動作の情報の流れを示す。 図４の例示としての動作の情報の流れを示す。 図４の例示としての動作の情報の流れを示す。 本発明による例示としての全システムのブロードキャスト動作の例示としてのデータの流れを示す。 本発明による例示としての全システムのブロードキャスト動作の例示としてのデータの流れを示す。 任意のデータ処理システム・トポロジのタイミング制約を示す例示としての動作の時間空間図である。 本発明による第１および第２の層のリンクに対する第１の例示としてのリンク情報割当てを示す。 本発明による第１および第２の層のリンクに対する第１の例示としてのリンク情報割当てを示す。 リンク情報割当て内に含まれる書込み要求のための部分応答フィールドの例示としての実施形態である。 本発明による第１および第２の層のリンクに対する第２の例示としてのリンク情報割当てを示す。 本発明による第１および第２の層のリンクに対する第２の例示としてのリンク情報割当てを示す。 動作の要求フェーズ内で使用する図１の相互接続ロジックの一部を示すブロック図である。 図１７のローカル・ハブ・アドレス・ランチ・バッファのより詳細なブロック図である。 図１７の要求ＦＩＦＯキューのより詳細なブロック図である。 それぞれ図１７のローカル・ハブ部分応答ＦＩＦＯキューおよびリモート・ハブ部分応答ＦＩＦＯキューのより詳細なブロック図である。 それぞれ図１７のローカル・ハブ部分応答ＦＩＦＯキューおよびリモート・ハブ部分応答ＦＩＦＯキューのより詳細なブロック図である。 それぞれ図１７のデータ構造に関する全システム・ブロードキャスト動作およびノードだけのブロードキャスト動作の保有期間を示す時間空間図である。 それぞれ図１７のデータ構造に関する全システム・ブロードキャスト動作およびノードだけのブロードキャスト動作の保有期間を示す時間空間図である。 それぞれローカル・マスタ、ローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の要求フェーズを示すフローチャートである。 それぞれローカル・マスタ、ローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の要求フェーズを示すフローチャートである。 それぞれローカル・マスタ、ローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の要求フェーズを示すフローチャートである。 それぞれローカル・マスタ、ローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の要求フェーズを示すフローチャートである。 本発明によるスヌーパのところの部分応答を発生するための例示としての方法のハイレベル論理フローチャートである。 動作の部分応答フェーズ内で使用する図１の相互接続ロジックの一部を示すブロック図である。 それぞれリモート・リーフ、リモート・ハブ、ローカル・ハブおよびローカル・マスタのところの動作の部分応答フェーズを示すフローチャートである。 それぞれリモート・リーフ、リモート・ハブ、ローカル・ハブおよびローカル・マスタのところの動作の部分応答フェーズを示すフローチャートである。 それぞれリモート・リーフ、リモート・ハブ、ローカル・ハブおよびローカル・マスタのところの動作の部分応答フェーズを示すフローチャートである。 動作の結合応答フェーズ内で使用する図１の相互接続ロジックの一部を示すブロック図である。 それぞれローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の結合応答フェーズを示すフローチャートである。 それぞれローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の結合応答フェーズを示すフローチャートである。 それぞれローカル・ハブ、リモート・ハブおよびリモート・リーフのところの動作の結合応答フェーズを示すフローチャートである。 図２のデータ処理システムの例示としてのスヌーピング構成要素のより詳細なブロック図である。 本発明の一実施形態による全動作タグの例示としての実施形態である。 それぞれマスタ３００およびスヌーパ３０４のところの例示としての結合応答資格付与ロジックを示す。 それぞれマスタ３００およびスヌーパ３０４のところの例示としての結合応答資格付与ロジックを示す。

符号の説明

１００ 処理装置
１００ａ０ａ，１００ａ０ｂ，１００ａ０ｃ ローカル・ハブ
１００ａ，１０２ｂ プロセッサ・コア
１０４ 命令シーケンシング・ユニット（ＩＳＵ）
１０６ 命令ユニット
１０８ Ｌ１キャッシュ
１１０ Ｌ２キャッシュ
１１２ マスタ
１１４ Ｌ２キャッシュ・ディレクトリ
１１６ スヌーパ
１２０ 集積相互接続ロジック
１２１ａ 要求ロジック
１２１ｂ 部分応答ロジック
１２１ｃ 結合応答ロジック
１２１ｄ データ・ロジック
１２２ 応答ロジック
１２３ 構成レジスタ
１２４ 集積メモリ・コントローラ（ＩＭＣ）
１２６ スヌーパ
１２８ 集積入出力コントローラ
１３０ 入出力装置
１３２ システム・メモリ
２００ データ処理システム
２０２ａ０〜２０２ｄ０，２０２ａ１〜２０２ｄ１ 処理ノード
３００ ウィニング・マスタ
３０２，３２２ 要求
３０４，３０４ｎ スヌーパ
３０６ 部分応答
３１０ ＣＲ
３１２ａ 保護ウィンドウ
３１２ｂ ウィンドウ拡張部
３１３ 保護ウィンドウ
７００ａ トランザクション・タイプ
７０４ 予約フィールド
７０６ａ マスタ・タグ
７０８ａ，７０８ｂ ローカル部分応答フィールド
７１０ａ 結合応答
７１２ａ 遠隔部分応答
７１４ データ・タグ
７１６ａ〜７１６ｄ データ・ペイロード
７１８ａ，７１８ｂ 予約フィールド
７２０ 要求部分応答
７２４ 宛先タグ・フィールド
８０８ ローカル部分応答フィールド
８１２ リモート部分応答フィールド
９００ マスタ・マルチプレクサ
９０２ａ，９０２ｂ 保持バッファ
９０３ リモート・ハブ・マルチプレクサ
９０４ 要求マルチプレクサ
９０５ 要求バス
９０６ ＮＭ／ＲＨ保持バッファ
９０７ 前の要求ＦＩＦＯバッファ
９１０ ＬＨアドレス・ランチ・バッファ
９１４ａ〜９１４ｃ ノード・リーフ／リモート・リーフ（ＮＬ／ＲＬ）保持バッファ
９２２ スヌープ・バス
９３０ ローカル・ハブ（ＬＨ）部分応答ＦＩＦＯキュー
９４０ ノード・マスタ／リモート・ハブ（ＮＭ／ＲＨ）部分応答ＦＩＦＯキュー
１０１０ マップ・ロジック
１９００ スヌーピング・デバイス
１９０２ ＢＡＲ
１９０４ ハッシュ・ロジック
１９０６ａ〜１９０６ｍ スヌーパ
１９１０ リソース
１９１２ａ〜１９１２ｎ バンク

Claims (8)

1. データ処理システムであって、
   処理装置のうちの複数の異なる処理装置間の通信のうちの少なくともいくつかが、複数の処理装置のうちの少なくとも１つの中間処理装置を介して送信されるように、ポイント・ツー・ポイント通信のための複数の通信リンクにより結合している複数の処理装置を備え、前記通信が、それぞれが要求および前記要求へのシステム応答を表す結合応答を有する動作を含み、
   前記複数の処理装置のうちの前記少なくとも１つの中間処理装置が、
   第１の動作を開始する１つまたは複数のマスタと、
   前記複数の処理装置のうちの１つの他の処理装置が開始した第２の動作を受信するスヌーパと、
   その処理装置内で前記１つまたは複数のマスタが開始した第１の動作のマスタ・タグを格納するための物理キューと、
   前記中間処理装置のところで観察した第２の動作に、前記中間処理装置が観察した他の第２の動作に関する観察の順序を示すチケット番号を割り当てるチケット発行機構であって、前記チケット発行機構が、動作に割り当てられた前記チケット番号を、前記動作の結合応答による処理のために前記スヌーパに提供するチケット発行機構とを含み、
   前記チケット発行機構が、それぞれが前記通信リンクに沿って複数の各経路から受信した動作を追跡する複数の動作追跡構造を有し、
   前記複数の各動作追跡構造が、特定のチケット番号を動作の要求に割り当てるヘッド・ポインタと、前記特定のチケットを先入れ先出し（ＦＩＦＯ）順序で前記動作の結合応答に割り当てるテール・ポインタとを含み、
   前記チケット発行機構は、物理的に存在しない複数の仮想ＦＩＦＯキューを有し、該各仮想ＦＩＦＯキューは、一対の関連する物理ポインタと関連させる仮想エントリを識別するテール・ポインタを有する、
   データ処理システム。
2. 各中間処理装置が、前記要求のチケット番号および前記結合応答のチケット番号を参照して、前記スヌーパに対する結合応答に資格を与える結合応答資格付与ロジックを含む、請求項１に記載のデータ処理システム。
3. 前記チケット発行機構が、前記スヌーパに、前記結合応答が横断する前記複数の通信リンクのうちの１つまたは複数を備える経路を示す経路表示を提供し、
   前記結合応答資格付与ロジックが、前記経路表示に基づいて前記データ処理システム内の要求しているマスタの位置を決定する経路ロジックを含み、前記結合応答資格付与ロジックが、さらに、前記位置に基づいて前記スヌーパに対する前記結合応答に資格を与える、請求項２に記載のデータ処理システム。
4. 各中間処理装置が、前記結合応答と関連する前記物理キューから受信した前記マスタ・タグを参照して、１つまたは複数のマスタのうちのあるマスタに対して結合応答の資格を与える結合応答資格付与ロジックを含む、請求項１に記載のデータ処理システム。
5. 複数の処理装置のうちの複数の異なる処理装置間の通信のうちの少なくともいくつかが、前記複数の処理装置のうちの少なくとも１つの中間処理装置を介して送信されるように、ポイント・ツー・ポイント通信のための複数の通信リンクにより結合している複数の処理装置を含むデータ処理システムのための処理装置であって、前記通信が、それぞれが要求および前記要求へのシステム応答を表す結合応答を有する動作を含み、前記処理装置が、
   第１の動作を開始する１つまたは複数のマスタと、
   前記複数の処理装置のうちの他の処理装置が開始した第２の動作を受信するスヌーパと、
   その処理装置内で前記１つまたは複数のマスタが開始した第１の動作のマスタ・タグを格納するための物理キューと、
   前記処理装置のところで観察した第２の動作に、前記処理装置が観察した他の第２の動作に関する観察の順序を示すチケット番号を割り当てるチケット発行機構であって、前記チケット発行機構が、動作に割り当てられた前記チケット番号を、前記動作の結合応答による処理のために前記スヌーパに提供するチケット発行機構とを備え、
   前記チケット発行機構が、それぞれが前記通信リンクに沿って複数の各経路から受信した動作を追跡する複数の動作追跡構造を有し、
   前記複数の各動作追跡構造が、特定のチケット番号を動作の要求に割り当てるヘッド・ポインタと、前記特定のチケットを先入れ先出し（ＦＩＦＯ）順序で前記動作の結合応答に割り当てるテール・ポインタとを含み、
   前記チケット発行機構は、物理的に存在しない複数の仮想ＦＩＦＯキューを有し、該各仮想ＦＩＦＯキューは、一対の関連する物理ポインタと関連させる仮想エントリを識別するテール・ポインタを有する、
   処理装置。
6. 前記処理装置が、前記要求のチケット番号および前記結合応答のチケット番号を参照して、前記スヌーパに対する結合応答に資格を与える結合応答資格付与ロジックを含む、請求項５に記載の処理装置。
7. 前記チケット発行機構が、前記スヌーパに、前記結合応答が横断する前記複数の通信リンクのうちの１つまたは複数を備える経路を示す経路表示を提供し、
   前記結合応答資格付与ロジックが、前記経路表示に基づいて前記データ処理システム内の要求しているマスタの位置を決定する経路ロジックを含み、前記結合応答資格付与ロジックが、さらに、前記位置に基づいて前記スヌーパに対する前記結合応答に資格を与える、請求項６に記載の処理装置。
8. 結合応答と関連する前記物理キューから受信した前記マスタ・タグを参照して、１つまたは複数のマスタのうちのあるマスタに対して結合応答の資格を与える結合応答資格付与ロジックをさらに備える、請求項５に記載の処理装置。

Images