I.処理装置およびデータ処理システム
ここで図面、特に図1について説明するが、図1は、本発明による処理装置100の例示としての実施形態のハイレベル・ブロック図である。図の実施形態の場合には、処理装置100は、命令およびデータを別々に処理するための2つのプロセッサ・コア102a、102bを含む1つの集積回路である。各処理コア102は、実行のために命令を取り出し、順番に配置するための少なくとも1つの命令シーケンシング・ユニット(ISU)104、および命令を実行するための1つまたは複数の実行ユニット106を含む。命令ユニット106により実行される命令としては、例えば、固定および浮動点演算命令、論理命令およびメモリ・ブロックへの読取りおよび書込みアクセスを要求する命令等がある。
各プロセッサ・コア102a、102bの動作は、その最低レベルのところに1つまたは複数の共有システム・メモリ132(図1には1つしか示していない)、およびその上のレベルのところに、1つまたは複数のレベルのキャッシュ・メモリを有する多重レベル揮発性メモリ階層によりサポートされている。図に示すように、処理装置100は、プロセッサ・コア102a、102bから受信した要求に応じて、システム・メモリ132への読取りおよび書込みアクセスを制御し、スヌーパ126により(以下に説明するように)相互接続装置上にスヌープされた動作を制御する集積メモリ・コントローラ(IMC)124を含む。
例示としての実施形態の場合には、処理装置100のキャッシュ・メモリ階層は、各プロセッサ・コア102a、102b内にレベル1(L1)キャッシュ108を通しての記憶装置、および処理装置100のプロセッサ・コア102a、102bが共有するレベル2(L2)キャッシュ110を含む。L2キャッシュ110は、L2アレイおよびディレクトリ114、マスタ112およびスヌーパ116を含む。マスタ112は、関連するプロセッサ・コア102a、102bから受信したメモリ・アクセス(および他の)要求に応じて、相互接続装置上で処理を開始し、L2アレイおよびディレクトリ114にアクセスする。スヌーパ116は、相互接続装置上の動作を検出し、適当な応答を提供し、動作が要求するL2アレイおよびディレクトリ114への任意のアクセスを行う。図のキャッシュ階層は、2つのレベルのキャッシュしか含んでいないが、当業者であれば、他の実施形態は上のレベルのキャッシュの内容を全部含むことができ、その一部を含むことができ、または全然含んでいないオンチップまたはオフチップ・インラインまたはルックアサイド・キャッシュの追加のレベル(L3、L4等)を含むことができることを理解することができるだろう。
さらに図1に示すように、処理装置100は、処理装置100をより大きなデータ処理システムの一部として相互接続ファブリックに結合することができる集積相互接続ロジック120を含む。図の実施形態の場合には、相互接続ロジック120は、この場合にはインバウンドおよびアウトバウンドX、YおよびZリンクを含む「第1の層」の相互接続リンクの任意の番号t1をサポートする。相互接続ロジック120は、さらに、インバウンドおよびアウトバウンドAおよびBリンクとして、図1に示す第2の層リンクの任意の数t2をサポートする。これらの第1および第2の層のリンクにより、t1/2+t2/2(この場合は5)までの他の処理装置100への二方向通信のために、各処理装置100を結合することができる。相互接続ロジック120は、動作の異なるフェーズ中に情報を処理し転送するための、要求ロジック121a、部分応答ロジック121b、結合応答ロジック121cおよびデータ・ロジック121dを含む。さらに、相互接続ロジック120は、処理装置100を構成するために使用する複数のモード・ビットを含む構成レジスタ123を含む。以下にさらに詳細に説明するように、これらのモード・ビットは、好ましくは、(1)第1および第2の層のリンクのための所望のリンク情報割当てを選択する1つまたは複数のモード・ビットの第1の組と、(2)処理装置100の第1および第2の層リンクのうちのどちらを他の処理装置100に接続するのかを指定するモード・ビットの第2の組と、(3)保護ウィンドウ拡張のプログラム可能な期間を決定するモード・ビットの第3の組と、(4)上記米国特許出願第11/055,305号に記載されているように、ノードだけのブロードキャスト範囲または全システム範囲の間から動作毎に処理装置100が開始する動作のためのブロードキャスト範囲を予測して選択するモード・ビットの第4の組を含む。
各プロセッサ・ユニット100は、さらに、処理装置100のキャッシュ階層と他の処理装置100のキャッシュ階層との間のキャッシュ・コヒーレンシを維持する分散型コヒーレンシ信号機構の一部を実施する応答ロジック122のインスタンスを含む。最後に、各処理装置100は、入出力装置130のような1つまたは複数の入出力装置のアタッチメントをサポートしている集積I/O(入出力)コントローラ128を含む。入出力コントローラ128は、入出力装置130による要求に応じてX、Y、Z、AおよびBリンク上で動作を発行し、データを受信することができる。
ここで図2を参照すると、この図は、本発明による複数の処理装置100からなるデータ処理システム200の例示としての実施形態のブロック図である。図に示すように、データ処理システム200は、図の実施形態の場合にはそれぞれ4つの処理装置100を含むパッケージを備える多重チップ・モジュール(MCM)として実行されている8つの処理ノード202a0〜202d0および202a1〜202d1を含む。各処理ノード202内の処理装置100は、図に示すように、処理装置X、Y、およびZリンクによりポイント・ツー・ポイント通信のために結合している。各処理装置100は、さらに、処理装置AおよびBリンクによるポイント・ツー・ポイント通信のために、2つの異なる処理ノード202内で処理装置100に結合することができる。図2においては両方に矢尻のある矢印で示してあるが、X、Y、Z、AおよびBの各対は、好ましくは(しかし、必ずしもそうである必要はないが)二方向リンクとしてではなく、2つの一方向リンクとして実施することを理解されたい。
図2のトポロジを形成するための一般的な表現は下記のようになる。
Node[I][K].chip[J].link[K]connects to Node[J][K].chip[I].link[K],(すべての1≠Jに対して);and
Node[I][K].chip[I].link[K]connects to Node[I][not K].chip[I].link[not K];and
Node[I][K].chip[I].link[not K]connects either to:
(1)将来の拡張に対して何も予約しない;または
(2)Node[extra][not K].chip[I].link[K](すべてのリンクが完全に使用される(すなわち、72方向システムを形成する9つの8方向ノード)の場合);and
ここで、IおよびJは、組{a,b,c,d}に属し、Kは、組{A,B}に属する。
もちろん、他の機能的に等価のトポロジを形成するために他の表現も定義することができる。さらに、図のトポロジは代表的なものであるが、本発明を実施するデータ処理システム・トポロジを網羅しているものではないこと、および他のトポロジも使用することができることを理解されたい。このような他のトポロジの場合には、例えば、各処理装置100と結合する第1の層のリンクおよび第2の層のリンクの数は、任意の数であってもよいし、各層(すなわち、I)内の処理ノード202の数は、処理ノード100(すなわち、J)毎の処理装置100の数と等しくなくてもよい。
図2に示す方法で完全に接続していても、すべての処理ノード202は、各動作をすべての他の処理ノード202に通知する必要はない。より詳細に説明すると、すでに説明したように、処理装置100は、その処理ノード202に限定した範囲で、またはすべての処理ノード202を含む全システム範囲のようなより広い範囲で動作をブロードキャストすることができる。
図37に示すように、例えば、L2(またはより低いレベル)のキャッシュのスヌーパ116、またはIMC124のスヌーパ126のような、データ処理システム200内の例示としてのスヌーピング・デバイス1900は、スヌーピーング・デバイス1900が責任を有する実アドレスを含む実アドレス空間の1つまたは複数の領域を識別する1つまたは複数のベース・アドレス・レジスタ(BAR)1902を含むことができる。スヌーピーング・デバイス1900は、そうしたい場合には、スヌーピーング・デバイス1900がそのアドレスを担当するかどうかについてさらに資格を与えるために、BAR1902が識別した実アドレス空間の領域に入る実アドレス上でハッシュ機能を実行するハッシュ・ロジック1904をさらに含むことができる。最後に、スヌーピーング・デバイス1900は、BAR1902およびハッシュ・ロジック1904が資格を与えた要求アドレスを指定するスヌープした要求に応じて、リソース1910(例えば、L2キャッシュ・アレイおよびディレクトリ114またはシステム・メモリ132)にアクセスする多数のスヌーパ1906a〜1906mを含む。
図に示すように、リソース1910は、それぞれが実際のアドレスの各組と関連する複数のバンク1912a〜1912nを含むバンクを含む構造を有することができる。当業者であれば周知のように、このようなバンクを含む設計は、リソース1910を複数の独立しているアクセス可能なリソースに効果的に再分割することにより、リソース1910に対する要求のより速い到着レートをサポートするために多くの場合使用される。このようにして、スヌーピーング・デバイス1900またはリソース1910あるいはその両方の動作周波数が、このような要求の最大到着レートと同じ速度のリソース1910にアクセスするように要求にサービスすることができない場合でも、スヌーピーング・デバイス1900は、所与の時間間隔内に任意のバンク1912に対して受信した要求の数がその時間間隔内にそのバンク1912がサービスを与えることができる要求の数を超えない限り、再試行を行わなくてもこのような要求にサービスを与えることができる。
当業者であれば、SMPデータ処理システム100が、相互接続ブリッジ、不揮発性記憶装置、ネットワークまたは取り付けたデバイス等に接続するためのポートなどのような多くの追加の図示していない構成要素を含むことができることを理解することができるだろう。このような追加の構成要素は、本発明を理解するのに必要ではないので、これらの構成要素は、図2に示してないし、これ以上の説明は省略する。
II.例示としての動作
ここで図3を参照すると、この図は、図2のデータ処理システム200の相互接続ファブリック上の例示としての動作の時間空間図である。動作は、マスタ300(例えば、L2キャッシュ110のマスタ112、または入出力コントローラ128内のマスタ)が、相互接続ファブリック上で要求302を発行した場合に開始する。好ましくは、要求302は、少なくとも所望のアクセスのタイプを示すトランザクション・タイプ、要求によりアクセスされるリソースを示すリソース識別子(例えば、実アドレス)を含む。好ましくは、要求の共通のタイプは、表Iに示すものを含む。
これら動作に関するこれ以上の詳細およびこれらの動作の効率的処理を容易にする例示としてのキャッシュ・コヒーレンシ・プロトコルについては、上記参照に記載されている米国特許公開第20060179252号を参照されたい。
要求302は、スヌーパ304、例えば、データ処理システム200内に分散しているL2キャッシュ110のスヌーパ116およびIMC124のスヌーパ126により受信される。一般に、いくつかの例外はあるが、要求302のマスタ112としての同じL2キャッシュ110内のスヌーパ116は、要求302をスヌープしない(すなわち、一般に、自己スヌーピーングは行われない)。何故なら、要求302が処理装置100により内部でサービスを受けることができない場合には、要求302は相互接続装置だけにより送信されるからである。要求302を受信し処理するスヌーパ304は、それぞれ要求302への少なくともそのスヌーパ304の応答を表す各部分応答306を提供する。IMC124内のスヌーパ126は、例えば、スヌーパ126が要求アドレスを担当しているかどうか、およびスヌーパ126が要求にサービスするために使用することができるリソースを有しているかどうかに基づいて提供する部分応答306を決定する。L2キャッシュ110のスヌーパ116は、例えば、そのL2キャッシュ・ディレクトリ114の利用度、要求を処理するためのスヌーパ116内のスヌープ・ロジック・インスタンスの利用度、およびL2キャッシュ・ディレクトリ114内の要求アドレスに関連するコヒーレンシ状態に基づいてその部分応答306を決定することができる。
スヌーパ304の部分応答306は、要求302に対する結合応答(CR)310を決定するために、応答ロジック122の1つまたは複数のインスタンスにより、いくつかのフェーズでまたはすべて直ちに論理的に結合される。以後引用する1つの好ましい実施形態の場合には、結合応答310の発生を担当する応答ロジック122のインスタンスは、要求302を発行したマスタ300を含む処理装置100内に位置する。応答ロジック122は、要求302への応答(例えば、成功、失敗、再試行等)を示すために、相互接続ファブリックを介してマスタ300およびスヌーパ304に結合応答310を提供する。CR310が要求302の成功を示している場合には、CR310は、例えば、要求されたメモリ・ブロックのデータ・ソース、要求したメモリ・ブロックがマスタ300によりキャッシュされるキャッシュ状態、1つまたは複数のL2キャッシュ110内で要求したメモリ・ブロックを無効にする「クリーンアップ」動作が必要であるかどうかを示すことができる。
結合応答310を受信した場合には、1つまたは複数のマスタ300およびスヌーパ304は、通常、要求302にサービスするために1つまたは複数の動作を行う。これらの動作は、マスタ300にデータを供給すること、1つまたは複数のL2キャッシュ110内にキャッシュしたデータのコヒーレンシ状態を無効にするか、または更新すること、キャストアウト動作を行うこと、システム・メモリ132にデータを書き戻すことなどを含むことができる。要求302により要求された場合、要求されたまたは目標メモリ・ブロックを応答ロジック122による結合応答310の発生の前または後で、マスタ300へまたはから送信することができる。
以下の説明においては、要求302へのスヌーパ304の部分応答306、および要求302またはその結合応答310あるいはその両方に応じてスヌーパ304が行った動作について、そのスヌーパが、要求が指定した要求アドレスに対して最高コヒーレンシ点(HPC)であるか、最低コヒーレンシ点(LPC)であるか、またはいずれでもないかを参照しながら説明する。本明細書においては、LPCは、メモリ・ブロックのリポジトリとして働くメモリ・デバイスまたは入出力装置として定義される。メモリ・ブロックに対するHPCが存在しない場合には、LPCはメモリ・ブロックの真のイメージを保持し、メモリ・ブロックの追加のキャッシュ・コピーを発生する要求を許可または拒否する権限を有する。図1および図2のデータ処理システムの実施形態の典型的な要求の場合には、LPCは、参照したメモリ・ブロックを保持しているシステム・メモリ132に対するメモリ・コントローラ124である。本明細書においては、HPCは、メモリ・ブロックの真のイメージをキャッシュする一意に識別されたデバイスとして定義され(LPCのところの対応するメモリ・ブロックと一致していてもまたは一致していなくてもよい)、メモリ・ブロックを修正する要求を許可または拒否する権限を有する。説明すると、HPCは、また、メモリ・ブロックを修正しない動作に応じて要求者にメモリ・ブロックのコピーを提供することができる。それ故、図1および図2のデータ処理システムの実施形態の典型的な要求の場合には、HPCは、もしある場合には、L2キャッシュ110であってもよい。メモリ・ブロックのHPCを指定するために他のインジケータも使用することができるが、本発明の好ましい実施形態は、もしあった場合、メモリ・ブロックに対するHPCをL2キャッシュ110のL2キャッシュ・ディレクトリ114内の選択したキャッシュ・コヒーレンシ状態により示す。
引き続き図3を参照すると、要求302内で参照したメモリ・ブロックに対するHPCがもし存在する場合には、またはHPCが存在しない場合には、好ましくは、メモリ・ブロックのLPCは、必要な場合には、要求302への応答内のメモリ・ブロックの所有権の移転を保護する責任を有する。図3の例示としてのシナリオの場合には、要求302の要求アドレスが指定するメモリ・ブロックに対するHPCのところのスヌーパ304n(またはHPCが存在しない場合には、LPC)は、スヌーパ304nがその部分応答306を決定した時点からスヌーパ304nが結合応答310を受信するまで継続する保護ウィンドウ312aの間、およびスヌーパ304nによる結合応答310の受信を超えてプログラム可能な時間が延びる以降のウィンドウ延長部312bの間、マスタ300への要求されたメモリ・ブロックの所有権の移転を保護する。保護ウィンドウ312aおよびウィンドウ延長部312bの間、スヌーパ304nは、マスタ300への所有権の移転が成功するまで、所有権(例えば、再試行部分応答)を他のマスタが入手するのを防止する同じ要求アドレスを指定している他の要求に部分応答306を提供することにより、所有権の移転を保護する。マスタ300は、同様に、結合応答310を受信した後で要求302で要求されたメモリ・ブロックのその所有権を保護するために、保護ウィンドウ313を開始する。
スヌーパ304はいずれも、CPUおよび上記入出力要求を処理するためのリソースは限られたものであるので、いくつかの異なるレベルの部分応答および対応するCRが可能である。例えば、要求されたメモリ・ブロックを担当するメモリ・コントローラ124内のスヌーパ126が、要求を処理するために使用することができるキューを有する場合には、スヌーパ126は、要求に対してLPCとして働くことができることを示す部分応答で応答することができる。一方、スヌーパ126が要求を処理するために使用することができるキューを有していない場合には、スヌーパ126は、メモリ・ブロックに対するLPCであることを示す部分応答で応答することができるが、現時点で要求にサービスすることはできない。同様に、L2キャッシュ110内のスヌーパ116は、要求を処理するためにスヌーパ・ロジックの使用することができるインスタンスを要求することができ、L2キャッシュ・ディレクトリ114にアクセスすることができる。これらリソースの一方(または両方)にアクセスしない場合には、必要なリソースがないために要求にサービスすることができないことを知らせる部分応答(および対応するCR)になる。
III.例示としての動作のブロードキャストの流れ
ここで図6〜図8のところでも説明する図4を参照すると、この図は、図2のデータ処理システム200内の全システムの範囲の動作の例示としての動作の流れの時間空間図である。これらの図面中、データ処理システム200内の種々の処理装置100には、2つの位置識別子、すなわち、処理装置100が属する処理ノード202を識別するための第1の位置識別子、および処理ノード202内の特定の処理装置100を識別するための第2の位置識別子がついている。それ故、例えば、処理装置100a0cは、処理ノード202a0の処理装置100cを示す。さらに、各処理装置100には、動作に参加する他の処理装置100に対するその機能を示す機能識別子がつけてある。これらの機能識別子としては、(1)動作を開始する処理装置100であるローカル・マスタ(LM)、(2)ローカル・マスタと同じ処理ノード202であり、他の処理ノード202への動作の送信を担当する処理装置100であるローカル・ハブ(LH)(ローカル・マスタはローカル・ハブであってもよい)、(3)ローカル・マスタ以外の処理ノード202内に位置していて、その処理ノード202内の他の処理装置100への動作の分散を担当する処理装置100であるリモート・ハブ(RH)、(4)ローカル・マスタとは異なる処理ノード220内に位置していて、リモート・ハブではない処理装置100であるリモート・リーフ(RL)などがある。
図4に示すように、図3のところですでに説明したように、例示としての動作は、少なくとも3つのフェーズ、すなわち、要求(またはアドレス)フェーズ、部分応答(Presp)フェーズ、および結合応答(Cresp)フェーズを有する。好ましくは、これらの3つのフェーズは、上記順序で行われ、重ならない。動作は、さらにそうしたい場合には、要求、部分応答および結合応答フェーズのうちのいずれかと重なることができるデータフェーズを有することができる。
さらに図4および図6を参照すると、要求フェーズは、ローカル・マスタ100a0c(すなわち処理ノード202a0の処理装置100c)が、例えば、読取り要求のような要求を、その処理ノード202a0内のローカル・ハブ100a0a、100a0b、100a0cおよび100a0dそれぞれに同期ブロードキャストした場合に開始する。ローカル・ハブのリストが、また、ローカル・マスタであるローカル・ハブ100a0cを含むことに留意されたい。以下にさらに詳細に説明するように、この内部送信は、以下に説明するタイミング制約がもっと容易に満たされるように、ローカル・ハブ100a0cの動作をローカル・ハブ100a0a、100a0bおよび100a0dと同期させるために有利に使用される。
要求を受信した場合、そのAまたはBリンクによりリモート・ハブ100と結合している各ローカル・ハブ100は、動作をそのリモート・ハブ100に送信する。それ故、ローカル・ハブ100a0aは、そのアウトバウンドAリンクにより動作を送信しないで、そのアウトバウンドBリンクを介して処理ノード202a1内のリモート・ハブに動作を送信する。ローカル・ハブ100a0b、100a0cおよび100a0dは、それぞれ各アウトバウンドAおよびBリンクを介して、処理ノード202b0および202b1、処理ノード202c0および202c1、および処理ノード202d0および202d1内のリモート・ハブに動作を送信する。動作を受信する各リモート・ハブ100は、順次、その処理ノード202内の各リモート・リーフ100に動作を送信する。それ故、例えば、ローカル・ハブ100b0aは、リモート・リーフ100b0b、100b0cおよび100b0dに動作を送信する。このようにして、動作は、3つ以下のリンクによる送信によりデータ処理システム200内のすべての処理装置100に効率的にブロードキャストされる。
図4および図7に示すように、要求フェーズの後で、部分応答(Presp)フェーズが行われる。部分応答フェーズ中に、各リモート・リーフ100は、動作を評価し、動作へのその部分応答をその各リモート・ハブ100に提供する。例えば、リモート・リーフ100b0b、100b0cおよび100b0dは、その各部分応答をリモート・ハブ100b0aに送信する。各リモート・ハブ100は、順次、ローカル・ハブ100a0a、100a0b、100a0cおよび100a0dそれぞれに、その部分応答およびそれ自身の部分応答を送信する。次に、ローカル・ハブ100a0a、100a0b、100a0cおよび100a0dは、処理ノード202a0内の各ローカル・ハブ100に、これらの部分応答およびそれ自身の部分応答をブロードキャストする。図7により、処理ノード202a0内のローカル・ハブ100による部分応答のブロードキャストは、タイミングの理由で、それ自身の部分応答の各ローカル・ハブ100による自己ブロードキャストを含むことに留意されたい。
理解していただけると思うが、図の方法による部分応答の収集は、多数の異なる方法により実施することができる。例えば、個々の部分応答を、他の各ローカル・ハブ、リモート・ハブおよびリモート・リーフから各ローカル・ハブに返送することができる。別の方法としては、より効率的にするために、部分応答がローカル・ハブに返送された場合に、部分応答を蓄積することが望ましい場合がある。各部分応答の効果が、確実に正確にローカル・ハブ100に返送されるようにするためには、好ましくは、例えば、論理OR機能、および機能(例えば、「ワンホット(one hot)」暗号化)を適用した場合に、関連情報が喪失しない暗号化により、非破壊的方法で、もしある場合、部分応答を蓄積する。
さらに図4および図8に示すように、処理ノード202a0内の各ローカル・ハブ100のところの応答ロジック122は、要求への全システム応答を示す結合応答を入手するために、他の処理装置100の部分応答をコンパイルする。次に、ローカル・ハブ100a0a〜100a0dは、要求フェーズの際に使用したのと同じ分散経路を通して、すべての処理装置100に結合応答をブロードキャストする。それ故、結合応答は、リモート・ハブ100への最初のブロードキャストであり、リモート・ハブ100は、その各処理ノード202内の各リモート・リーフ100に結合応答を送信する。例えば、リモート・ハブ100a0bは、リモート・ハブ100b0aに結合応答を送信し、リモート・ハブ100b0aは、リモート・リーフ100b0b、100b0cおよび100b0dに結合応答を送信する。
すでに説明したように、動作のサービスは、図9または図10に示すような追加のデータ・フェーズを必要とする場合がある。例えば、図9に示すように、動作が読取りまたはRWITM動作のような読取りタイプの動作である場合には、リモート・リーフ100b0dは、リモート・リーフ100b0dをリモート・ハブ100b0aに、リモート・ハブ100b0aをローカル・ハブ100a0bに、ローカル・ハブ100a0bをローカル・マスタ100a0cに接続しているリンクを介して、ローカル・マスタ100a0cに要求されたメモリ・ブロックの出所を明示することができる。逆に、動作が、例えば、修正したメモリ・ブロックをリモート・リーフ100b0bのシステム・メモリ132にライトバックするキャッシュ・キャストアウト動作のような書込みタイプの動作である場合には、図10に示すように、ローカル・マスタ100a0cをローカル・ハブ100a0bに、ローカル・ハブ100a0bをリモート・ハブ100b0aに、リモート・ハブ100b0aをリモート・リーフ100b0bに接続しているリンクを介してメモリ・ブロックが送信される。
ここで図5を参照すると、この図は、図2のデータ処理システム200内のノードだけの範囲の動作の例示としての動作の流れの時間空間図である。この図の場合、データ処理システム200内の種々の処理装置100には、2つの位置識別子、すなわち、処理装置100が属する処理ノード202を識別するための第1の位置識別子、および処理ノード202内の特定の処理装置100を識別するための第2の位置識別子がついている。それ故、例えば、処理装置100b0aは、処理ノード202b0の処理装置100bを示す。さらに、各処理装置100には、動作に参加する他の処理装置100に対するその機能を示す機能識別子がつけてある。これらの機能識別子としては、(1)ノードだけの範囲の動作を開始する処理装置100であるノード・マスタ(NM)、(2)ノード・マスタと同じ処理ノード202内にあり、ノード・マスタではない処理装置100であるノード・リーフ(NL)等がある。
図5に示すように、すでに説明したように、例示としてのノードだけの動作は少なくとも3つのフェーズ、すなわち、要求(またはアドレス)フェーズ、部分応答(Presp)フェーズ、および結合応答(Cresp)フェーズを有する。この場合も、これらの3つのフェーズは、上記順序で行われ、重ならないことが好ましい。動作は、さらにそうしたい場合には、要求、部分応答および結合応答フェーズのうちのいずれかと重なることができるデータ・フェーズを有することができる。
さらに図5を参照すると、要求フェーズは、図4の動作シナリオ内のリモート・ハブと非常によく似た働きをするノード・マスタ100b0a(すなわち処理ノード202b0の処理装置100a)が、例えば、読取り要求のような要求を、その処理ノード202b0内のノード・リーフ100b0b、100b0cおよび100b0dそれぞれに同期ブロードキャストした場合に開始する。ブロードキャスト送信の範囲が1つのノードに限定されているために、要求のオフ・ノード送信を同期させるために、ノード・マスタ100b0a内で要求の内部送信が使用されないことに留意されたい。
図5に示すように、要求フェーズの後で、部分応答(Presp)フェーズが行われる。部分応答フェーズ中に、各ノード・リーフ100b0b、100b0c、および100b0dは、動作を評価し、動作へのその部分応答をノード・マスタ100b0aに提供する。次に、さらに図5に示すように、処理ノード202b0内のノード・マスタ100b0aのところの応答ロジック122は、要求への全ノード応答を示す結合応答を入手するために、他の処理装置100の部分応答をコンパイルする。次に、ノード・マスタ100b0aは、ノード・マスタ100b0aのX、YおよびZリンクにより、すべてのノード・リーフ100b0b、100b0cおよび100b0dに結合応答をブロードキャストする。
すでに説明したように、動作のサービスは、追加のデータ・フェーズを必要とする場合がある。例えば、動作が読取りまたはRWITM動作のような読取りタイプの動作である場合には、ノード・リーフ100b0dは、ノード・リーフ100b0dをノード・マスタ100b0aに接続しているZリンクを介して、ノード・マスタ100b0aに要求されたメモリ・ブロックの出所を明示することができる。逆に、動作が、例えば、修正したメモリ・ブロックをリモート・リーフ100b0bのシステム・メモリ132にライトバックするキャッシュ・キャストアウト動作のような書込みタイプの動作である場合には、ノード・マスタ100b0aをノード・リーフ100b0bに接続しているXリンクを介してメモリ・ブロックが送信される。
もちろん、図4、図6〜図10および図5に示す2つの動作は、データ処理システム200のようなマルチプロセッサ・データ処理システムで同時に行うことができる無数の可能な全システムおよびノードだけの動作の単に例示としてのものに過ぎない。
IV.タイミング考慮事項
図3のところですでに説明したように、保護ウィンドウ312a、ウィンドウ拡張部312b、および保護ウィンドウ313を通して、同じメモリ・ブロックの所有権を競合する他のマスタが存在する可能性がある場合には、スヌーパ304nから要求しているマスタ300にメモリ・ブロックのコヒーレンシ所有権の「ハンドオフ」の間、コヒーレンシが維持される。例えば、図11に示すように、保護ウィンドウ312aおよびウィンドウ拡張部312bの両方は、競合するマスタ(CM)320による競合する要求322の存在下で、スヌーパ304nからウィニング・マスタ(WM)300に要求されたメモリ・ブロックのコヒーレンシ所有権の移転を保護するのに十分な持続時間を有するものでなければならない。保護ウィンドウ312aおよびウィンドウ拡張部312bが、スヌーパ304nからウィニング・マスタ300へ要求されたメモリ・ブロックの所有権の移転を保護するための十分長い持続時間を確保することができるように、好ましくは、図4および図5の処理装置100間の通信の待ち時間は、下記の条件が満たされるように制約する。
A_lat(CM_S)≦A_lat(CM_WM)+C_lat(WM_S)+ε
ここで、A_lat(CM_S)は、要求されたメモリ・ブロックのコヒーレンスを所有するスヌーパ(S)304nへの任意の競合マスタ(CM)320のアドレス待ち時間であり、A_lat(CM_WM)は、スヌーパ304nにより与えられたコヒーレンシ所有権である「ウィニング」マスタ(WM)300への任意の競合マスタ(CM)320のアドレス待ち時間であり、C_lat(WM_S)は、ウィニング・マスタ(WM)300が結合応答を受信した時間から、要求したメモリ・ブロックを所有するスヌーパ(S)304nが結合応答を受信した時間までの結合応答待ち時間であり、εはウィンドウ拡張部312bの持続時間である。
任意のトポロジのシステムに適用することができる上記タイミング制約を満たさない場合には、競合マスタ320の要求322を(1)ウィニング・マスタ300がコヒーレンシ所有権を入手し、保護ウィンドウ312bを開始する前に、ウィニング・マスタ300により、(2)保護ウィンドウ312aおよびウィンドウ拡張部312bが終了した後でスヌーパ304nにより受信することができる。このような場合、ウィニング・マスタ300もスヌーパ304nも、競合マスタ320がメモリ・ブロックのコヒーレンシ所有権を入手し、コヒーレントでないデータをメモリから読み取るのを防止する部分応答を競合要求322に提供しない。しかし、このコヒーレンシ・エラーを避けるために、ウィンドウ拡張部312bは、待ち時間の変動、またはコヒーレンシを維持するために満たさなければならないタイミング制約をそうでなければ満たすことができないかもしれない物理的実施態様の欠点を補償するために、(例えば、構成レジスタ123を適当に設定することにより)任意の長さ(ε)にプログラムすることができるように設定することができる。それ故、εについての上式を解くことにより、任意の実施態様に対するウィンドウ延長部312bの理想的な長さを決定することができる。図2のデータ処理システムの実施形態の場合には、好ましくは、εは複数の処理ノード202を含む範囲を有するブロードキャスト動作のための1つの第1の層のリンクのチップ・ホップの待ち時間に等しい持続時間を有し、ノードだけの範囲の動作に対してゼロの持続時間を有する。
上記タイミング制約についていくつかの観察をすることができる。第一に、競合マスタ320から所有するスヌーパ304aへのアドレス待ち時間は、必要な下限を有していないが上限を持たなければならない。上限は、とりわけ、達成することができる最悪の場合の待ち時間を決定することにより、可能な最大オッシレータ・ドリフト、処理装置100に結合している最長のリンク、蓄積したストールの最大数、および保証された最悪の場合のスループットに対して設計される。上限が確実に観察されるように、相互接続ファブリックはブロックを起こさない行動を確保しなければならない。
第二に、競合マスタ320からウィニング・マスタ300へのアドレス待ち時間は、必要な上限を有していないが下限を持たなければならない。下限は、とりわけ達成することができる最善の場合の待ち時間により、特定の静的構成の場合の、ストールがない場合、処理装置100間の可能な最短リンク、および最も遅いオッシレータ・ドリフトに対して決定される。
所与の動作の場合、各ウィニング・マスタ300および競合マスタ320は、その各要求に対して1つのタイミング限界だけを有しているが、動作中、任意の処理装置100は、いくつかの動作のためのウィニング・マスタであってもよく、他の動作のための競合(およびルージング)マスタであってもよいことを理解することができるだろう。それ故、各処理装置100は、そのアドレス待ち時間に対して上限および下限を効果的に有する。
第三に、結合応答が発生した時間からウィニング・マスタ300により結合応答が観察された時間までの結合応答待ち時間は、必要な下限を持たないが(結合応答は、任意の早い時点でウィニング・マスタ300のところに到着することができる)、上限を持たなければならない。対照的に、結合応答が発生した時間からスヌーパ304nが結合応答を受信した時間までの結合応答待ち時間は、下限を有しているが必要な上限を有していない(しかし、フライト中に同時に行われる動作の回数を制限するために、ある上限を任意に課することができる)。
第四に、部分応答待ち時間には制限がない。すなわち、上に列挙したタイミング制約のすべての項は、要求/アドレス待ち時間および結合応答待ち時間に関連しているので、ウィニング・マスタ300へのスヌーパ304および競合マスタ320の部分応答待ち時間は、必要な上限または下限を持たない。
V.例示としてのリンク情報割当て
処理装置100を接続している第1の層および第2の層のリンクは、図2のトポロジを入手し、図11のタイミング制約に適合するための種々の方法により実施することができる。1つの好ましい実施形態の場合には、各インバウンドおよびアウトバウンドの第1の層(X、YおよびZ)リンクおよび各インバウンドおよびアウトバウンドの第2の層(AおよびB)リンクは、アドレス、データ、制御およびコヒーレンシ情報を運ぶための多数の異なる仮想チャネルまたは保有期間を含む一方向8バイト・バスとして実施される。
ここで図12〜図13を参照すると、これらの図は、第1の層のX、YおよびZリンクおよび第2の層のAおよびBリンクに対する第1の例示としてのタイム・スライスした情報割当てを示す。図に示すように、この第1の実施形態の場合には、第1の4サイクルが2つのアドレス保有期間トランスポート・アドレス、コヒーレンシおよび制御情報を有し、第2の4サイクルがデータ・トランスポートを行うデータ保有期間専用のサイクルである8サイクル・フレームを反復する際に、第1および第2の層のリンク上で情報が割り当てられる。
最初に図12を参照すると、この図は、第1の層のリンクに対するリンク情報割当てを示す。サイクル数モジュロ8が0である各サイクル中に、バイト0は、第1の動作のトランザクション・タイプ700a(例えば、読取り)を送り、バイト1〜5は、第1の動作の要求アドレスの5つの低いアドレス・バイト702a1を提供し、バイト6〜7は予約フィールド704を形成する。次のサイクル(すなわち、サイクル数モジュロ8が1であるサイクル)中には、バイト0〜1は第1の動作(例えば、L2キャッシュ・マスタ112のうちの1つまたは入出力コントローラ128内のマスタ)のマスタ300を識別するマスタ・タグ706aを送り、バイト2は第1の動作の要求アドレスの高いアドレス・バイト702a2を送る。第1の動作に関連するこの情報と一緒に、異なる動作、すなわち同じ処理ノード202内のローカル・マスタ宛のローカル部分応答708a(バイト3〜4)、バイト5の結合応答710a、および異なる処理ノード202のローカル・マスタ宛のリモート部分応答712a(またはノードだけのブロードキャストの場合には、ノード・リーフ100からノード・マスタ100へ送られた部分応答)(バイト6〜7)に関連する最大3つの追加フィールドが送られる。これらの第1の2つのサイクルは、本明細書においては、アドレス保有期間と呼ばれるものを形成する。
さらに図12に示すように、次の2つのサイクル(すなわち、サイクル数モジュロ8が2および3であるサイクル)が、第1のアドレス保有期間と同じ基本パターンを有する第2のアドレス保有期間を形成する。例外は予約フィールド704がデータ保有期間の一部を形成するデータ・タグ714およびデータ・トークン715で置換されていることである。より詳細に説明すると、データ・タグ714は、サイクル4〜7に含まれている32バイトのデータ・ペイロード716a〜716dが送られる宛先データ・シンクを識別する。ペイロード・データの直前に位置するアドレス保有期間内のその位置により、ペイロード・データを受信する前に下流のステアリングを有利に構成することができ、そのため指定のデータ・シンクに向けてデータを効率的に経路指定することができる。データ・トークン715は、下流のキュー・エントリが解放され、その結果、オーバーランの危険なしでペアのX、Y、ZまたはAリンクにより追加のデータを送信することができることを示す表示を提供する。この場合も、トランザクション・タイプ700b、マスタ・タグ706b、低アドレス・バイト702b1および高アドレス・バイト702b2は、すべて第2の動作に関連し、データ・タグ714、ローカル部分応答708b、結合応答710bおよびリモート部分応答712bは、すべて第2の動作以外の1つまたは複数の動作に関連することに留意されたい。
好ましくは、各トランザクション・タイプ・フィールド700および結合応答フィールド710は、それが属する動作がノードだけ(ローカル)のまたは全システム(グローバル)の範囲を有しているかどうかを示す範囲インジケータ730を含む。上記相互参照の米国特許公開第20060179252号に詳細に記載されているように、データ・タグ714は、さらに、データ・ペイロード716a〜716d内に含まれているデータのリモート・コピーが存在するかどうかを示すために、LPCにより設定することができるドメイン・インジケータ732を含む。
図13は、第2の層のAおよびBリンクに対するリンク情報の割当てを示す。図12と比較すると分かるように、第2の層のAおよびBリンク上でのリンク情報の割当ては、図12の第1の層のリンクに対するものと同じである。例外は、ローカル部分応答フィールド708a、708bが予約フィールド718a、718bにより置換されていることである。この置換を行ったのは、第2の層のリンクとして、ローカル部分応答を送る必要がないという簡単な理由によるものである。
図14は、書込み要求に応じて、ローカル部分応答フィールド708a、708bまたはリモート部分応答フィールド712a、712b内にトランスポートすることができる書込み要求部分応答720の例示としての実施形態である。図に示すように、書込み要求部分応答720は、長さが2バイトで、書込みデータの宛先であり、宛先タグ・フィールド724の有効性を示すための1ビット有効(V)フラグ722の宛先であるスヌーパ(例えば、IMCスヌーパ126)のタグを指定するための15ビット宛先タグ・フィールド724を含む。
ここで図15〜図16を参照すると、これらの図は、第1の層のX、YおよびZリンク、および第2の層のAリンクに対する第2の例示としてのサイクル状の情報割当てを示す。図に示すように、この第2の実施形態の場合には、第1の2サイクルが、アドレスを含むアドレス・フレーム、コヒーレンシおよび制御情報を有し、第2の4サイクルがデータトランスポート専用のサイクルである6サイクル・フレームを反復する際に、第1および第2の層のリンク上で情報が割り当てられる。図15〜図16の実施形態の保有期間は、図12〜図13のサイクル2〜7の保有期間と同じであるので、ここではこれ以上の説明は省略する。書込み要求の場合には、ローカル部分応答フィールド808およびリモート部分応答フィールド812内に送られた部分応答は、図14の書込み要求の部分応答720の形をとることができる。
当業者であれば、図12〜図13および図15〜図16の実施形態は、非常に多くの可能なリンク情報割当てのうちの2つだけを示していることを理解することができるだろう。実施する選択したリンク情報割当ては、例えば、図1の構成レジスタ123内のハードウェアまたはソフトウェアあるいはその両方の設定可能モード・ビットによりプログラムすることができるようにすることができる。リンク情報割当ての選択は、通常、予想される作業量のタイプのような1つまたは複数の要因に基づいて行われる。例えば、データ処理システム200において科学的作業量が圧倒的に多い場合には、一般に、データ・ペイロードへの第1および第2の層のリンク上により広い帯域幅を割り当てるのがより好ましい。それ故、図15〜図16の第2の実施形態は、性能が改善される可能性が高い。逆に、データ処理システム200において商業的作業量が圧倒的に多い場合には、一般に、アドレス、コヒーレンシおよび制御情報により広い帯域幅を割り当てるのがより好ましい。この場合、図12〜図13の第1の実施形態は、より高い性能をサポートする。予想される作業量のタイプの決定、および構成レジスタ123の設定は、人間のオペレータにより行うことができるが、決定を自動的にハードウェアまたはソフトウェアあるいはその両方により行うのが有利である。例えば、一実施形態の場合には、作業量のタイプの決定は、1つまたは複数の処理装置100または専用補助サービス・プロセッサ(図示せず)上で実行されるサービス・プロセッサ・コードにより行うことができる。
VI.要求フェーズの構造および動作
ここで図17を参照すると、この図は、動作の要求フェーズ処理の際に使用する図1の相互接続ロジック120内の要求ロジック121aを示すブロック図である。図に示すように、要求ロジック121aは、処理装置100のマスタ300(例えば、L2キャッシュ110内のマスタ112および入出力コントローラ128内のマスタ)により、要求を受信するように結合しているマスタ・マルチプレクサ900を含む。マスタ・マルチプレクサ900の出力は、要求マルチプレクサ904の1つの入力となる。要求マルチプレクサ904の第2の入力は、保持バッファ902a、902bの出力と結合しているその入力を有するリモート・ハブ・マルチプレクサ903の出力と結合している。保持バッファは、それぞれインバウンドAおよびBリンク上の受信およびバッファ要求と結合している。リモート・ハブ・マルチプレクサ903は、以下にさらに詳細に説明する、保持バッファ902a〜902b内にバッファされるインバウンドAおよびBリンクから受信した要求の中から公平に選択する公平な割当てポリシーを実施する。存在する場合には、リモート・ハブ・マルチプレクサ903により要求マルチプレクサ904に提示された要求には、いつでも要求マルチプレクサ904により優先権が与えられる。要求マルチプレクサ904の出力は、アウトバウンドX、YおよびZリンク、ノード・マスタ/リモート・ハブ(NM/RH)保持バッファ906、およびローカル・ハブ(LH)アドレス・ランチ・バッファ910にそれぞれ結合している要求バス905を駆動する。また、好ましくは、要求バス905と結合している前の要求FIFOバッファ907は、もしある場合には、アドレスがそのアドレス保有期間ハッシュにより送られるアドレス・スライスまたはリソース・バンク1912を決定することができるように、多数の前のアドレス保有期間それぞれに対する少量のアドレス関連情報を保持する。例えば、一実施形態の場合には、前の要求FIFOバッファ907の各エントリは、関連要求の要求アドレスがハッシュされるバンク1912a〜1912nの特定の1つのバンクを識別する「1−ホット」暗号化を含む。要求が要求バス905により送信されないアドレス保有期間の場合には、1−ホットコード化はすべて「0」である。
インバウンドの第1の層の(X、YおよびZ)リンクは、それぞれLHアドレス・ランチ・バッファ910および各ノード・リーフ/リモート・リーフ(NL/RL)保持バッファ914a〜914cと結合している。NM/RH保持バッファ906、LHアドレス・ランチ・バッファ910およびNL/RL保持バッファ914a〜914cの出力は、すべてスヌープ・マルチプレクサ920の入力になる。LHアドレス・ランチ・バッファ910の出力には、好ましくは、前の要求FIFOバッファ907のような構造のもう1つの前のバッファ911が結合している。スヌープ・マルチプレクサ920の出力は、要求FIFOキュー924、処理装置100のスヌーパ304(例えば、L2キャッシュ110のスヌーパ116およびIMC124のスヌーパ126)、およびアウトバウンドAおよびBリンクが結合しているスヌープ・バス922を駆動する。スヌーパ304は、さらに、ローカル・ハブ(LH)部分応答FIFOキュー930およびノード・マスタ/リモート・ハブ(NM/RH)部分応答FIFOキュー940と結合していてこれらによりサポートされる。
他の実施形態を使用することもできるが、好ましくは 通信待ち時間を最小限度に短縮するために、バッファ902、906および914a〜914cはショート状態にある。1つの好ましい実施形態の場合には、各バッファ902、906および914a〜914cは、選択したリンク情報割当ての1つのフレームのアドレス保有期間だけを保持する大きさになっている。
ここで図18を参照すると、この図は、図17のローカル・ハブ(LH)アドレス・ランチ・バッファ910のより詳細なブロック図である。図に示すように、LHアドレス・ランチ・バッファ910のローカルおよびインバウンドX、YおよびZリンク入力は、マップ・ロジック1010の入力となり、マップ・ロジックは特定の各入力上で受信した要求を、対応する各位置に依存するFIFOキュー1020a〜1020dに入れる。図の名称の場合、処理ノード/MCM202の左上隅の処理装置100aは、「S」チップであり、処理ノード/MCM202の右上隅の処理装置100bは「T」チップであり、処理ノード/MCM202の左下隅の処理装置100cは「U」チップであり、処理ノード202の右下隅の処理装置100dは「V」チップである。それ故、例えば、ローカル・マスタ/ローカル・ハブ100acの場合には、ローカル入力上で受信した要求は、マップ・ロジック1010によりU FIFOキュー1020c内に入れられ、インバウンドYリンク上で受信した要求は、マップ・ロジック1010によりS FIFOキュー1020a内に入れられる。マップ・ロジック1010は、すべてのローカル・ハブ100内の以下に説明するアービトレーション・ロジック1032が、任意の明示の相互通信を使用しないで、要求を同じように処理するために同期するように入力の流れを正規化するために使用される。
位置に依存するFIFOキュー1020a〜1020d内に位置しているが、要求はすぐには有効というマークがつけられるわけではなく、ディスパッチのために使用できるわけでもない。それどころか、各位置に依存するFIFOキュー1020a〜1020d内の要求の有効性は、4つの入力上の各アドレス保有期間中に受信する要求を同期させるために、各プログラム可能な遅延1000a〜1000dを発生する。それ故、ローカル・マスタ/ローカル・ハブ100のところで要求の自己ブロードキャストを受信するローカル入力に関連するプログム可能な遅延1000aは、一般に、他の入力に関連するプログラム可能な遅延よりかなり長い。適当な要求を確実に有効にするために、プログラム可能な遅延1000a〜1000dが発生した有効信号は、基本的な要求としてマップ・ロジック1010により同じようにマッピングされる。
位置に依存するFIFOキュー1020a〜1020dの出力は、ローカル・ハブ要求マルチプレクサ1030の入力となり、このローカル・ハブ要求マルチプレクサは、アービタ1032が発生した選択信号に応じて、スヌープ・マルチプレクサ920に提示するための位置に依存するFIFOキュー1020a〜1020dから1つの要求を選択する。アービタ1032は、図4および図6に示すように、処理ノード202内のすべてのローカル・ハブ100により同時に、アウトバウンドAリンクにより同じ要求がブロードキャストされるように、その選択の際に所与の処理ノード202内のすべての他のローカル・ハブ100のアービタ1032と同期する公平なアービトレーション・ポリシーを実施する。それ故、図13および図16に示す例示としてのリンク情報割当てのいずれかの場合、ローカル・ハブ要求マルチプレクサ1030の出力は、アウトバウンドAリンク要求フレームのアドレス保有期間にタイムスライス整合する。
LHアドレス・ランチ・バッファ910の入力帯域幅は、その出力帯域幅の4倍であるので、位置に依存するFIFOキュー1020a〜1020dのオーバーランは設計に関連する。好ましい実施形態の場合には、キューのオーバーランは、各位置に依存するFIFOキュー1020に対して、関連する位置に依存するFIFOキュー1020の深さと同じ大きさのローカル・ハブ・トークンのプールを実施することにより防止される。ローカル・マスタが要求をローカル・ハブに送信するには自由ローカル・ハブ・トークンが必要であり、この自由ローカル・ハブ・トークンは、ローカル・ハブが要求をキューに入れることができることを保証する。それ故、ローカル・マスタ100が要求を発行した場合には、ローカル・ハブ・トークンがローカル・ハブ100内の位置に依存するFIFOキュー1020に割り当てられ、アービタ1032が位置に依存するFIFOキュー1020からエントリを発行した場合には、再度使用するために解放される。
ここで図19を参照すると、この図は、処理装置100のところで要求および関連する結合応答が観察される順序を追跡するために使用される、図17の要求FIFOキュー924のより詳細なブロック図である。米国特許公開第20060187939号に詳細に記載されている本発明の他の実施形態の場合には、すべての要求FIFOキュー924は、要求を開始するマスタのタグを格納するための物理的FIFOキューとして実施される。要求および関連する結合応答は、順番に任意の処理装置により観察されるので、物理要求FIFOキューにより、動作のマスタ・タグをすべての部分応答および結合応答と一緒にトランスポートしなくても、そのマスタ・タグを動作の結合応答と関連づけることができる。しかし、物理要求FIFOキューの数は、通信リンクの数により幾何学的に増大するので、上記特許出願に開示されている要求FIFOキューの全物理的実施態様は、小規模なシステムまたは数本の通信リンクを含むシステムによりよく適している。他の実施形態のいくつかの物理要求FIFOキューの代わりに仮想要求FIFOキューを使用することにより、本明細書に開示している好ましい実施形態のスケーラビリティが改善される。
ここで図19の好ましい実施形態を参照すると、要求FIFOキュー924は、アービタ1032が開始し、その処理装置100内のマスタ300が開始した、グローバルな範囲の要求のマスタ・タグを格納するためのいくつかの物理エントリを有する物理ローカル・ハブ(LH)タグFIFOキュー924aを含む。LHタグFIFO924aは、次の新しい要求のマスタ・タグを保持するために割り当てるエントリを識別する関連ヘッド・ポインタ(HP)1100a、および受信する次の結合応答(CR)と関連するマスタ・タグを含むエントリを識別するテール・ポインタ(TP)1102aを有する。要求FIFOキュー924は、さらに、アービタ1032が開始し、その処理装置100内のマスタ300が開始したノードだけの範囲の要求のマスタ・タグを格納するためのいくつかの物理エントリを有する物理的ノード・マスタ(NM)タグFIFOキュー924b2を含む。NMタグFIFO924b2は、次の新しい要求のマスタ・タグを保持するために割り当てるエントリを識別する関連ヘッド・ポインタ(HP)1100b2、および受信する次の結合応答(CR)と関連させるマスタ・タグを含むエントリを識別するテール・ポインタ(TP)1102b2を有する。
物理LHタグFIFO924a、および物理NMタグFIFO924b2の他に、要求FIFOキュー924は、図に鎖線で示すように、要求ロジック121a内に物理的に存在しないいくつかの仮想FIFOキューを有するチケット発行機構を含む。代わりに、各仮想FIFOキュー924は、それぞれ各「チケット番号」により識別されるいくつかの仮想(すなわち、物理的でない)エントリを有する。各仮想FIFOキュー924は、また、一対の関連する物理ポインタ、すなわち、次の新しい要求に割り当てられる仮想エントリを識別するヘッド・ポインタ(HP)1100、および受信した次の結合応答(CR)と関連させる仮想エントリを識別するテール・ポインタ(TP)1102を有する。その値が自身がポイントする仮想エントリの特定のチケット番号を示すカウンタとして、ポインタ1100および1102を有利に実施するすることができる。ある実施形態の場合には、異なる範囲を異なる仮想FIFOキュー924のポインタのペア1100、1102に割り当てることができ、そのためチケット番号も、チケット番号を関連づける仮想FIFOキュー924を始めから示す。
図に示すように、要求FIFOキュー924のうちの仮想FIFOキューは、各インバウンドAおよびBリンクを介して受信した全システム範囲の要求を追跡するリモート・ハブ(RH)仮想FIFOキュー924b0〜924b1を含む。仮想FIFOキューは、また、それぞれがインバウンドの第1および第2の層のリンクの各一意の組合せを介して、リモート・リーフ100により受信した全システム範囲の要求を追跡するリモート・リーフ(RL)仮想FIFOキュー924c0〜924c1、924d0〜924d1および924e0〜924e1を含む。最後に、仮想FIFOキューは、それぞれが各第1の層のX、YおよびZリンク上でノード・リーフ100が受信した要求を追跡するノード・リーフ(NL)仮想FIFOキュー924c2、924d2および924e2を含む。
要求に対する可能な各役割(LH、NM、RH、RLおよびNL)内でサービスを提供している処理装置100のところで要求を受信した場合には、要求FIFOキュー924の関連キューのヘッド・ポインタ1100により識別された物理的または仮想エントリは、その要求に割り当てられ、ヘッド・ポインタ1100が前進する。物理キューの場合には、その要求を開始したマスタ300を識別するマスタ・タグが割り当てられたエントリ内に配置される。非物理キューの場合には、前進する前にヘッド・ポインタ1100が示すチケット番号は、単に要求と関連するだけである。処理装置100のところで要求に対する結合応答を受信した場合には、要求に割り当てられたキュー・エントリを識別するために、要求に対する処理装置100がサービスした役割に対する要求FIFOキュー924の関連するキューのテール・ポインタ1102に対してアクセスが行われ、テール・ポインタ1102が前進する。物理キューの場合には、要求を開始したマスタ300を識別するマスタ・タグが割り当てられたエントリから検索され、仮想キューの場合には、要求のチケット番号だけが検索される。
物理要求FIFOキューだけではなく、仮想要求FIFOキューを実施すると、他の実施形態と比較した場合タグ記憶装置が有意に低減し、同時にシステムのスケーラビリティが改善される。種々の処理装置100のところで結合応答を受信する順序が、関連する要求を受信した順番と同じである場合には、キュー・エントリの割当ておよび検索についてのFIFOポリシーを有利に使用することができる。さらに、当業者であれば、特定の動作内でプロセッサ100が行っている役割ではなく、絶対チップ位置(例えば、S、T、U、V)に基づいて要求FIFOキュー924を別の方法により実施することができることを理解されたい。
以下に説明する図22〜図23に示すように、LHタグFIFOキュー924a内のエントリは、全システム・ブロードキャスト動作に対して最も長い保有期間を有し、NMタグFIFOキュー924b2は、ノードだけのブロードキャスト動作に対して最も長い保有期間を有する。それ故、LHタグFIFOキュー924aおよびNMタグFIFOキュー924b2の深さは、それぞれ処理ノード202が相互接続ファブリック上で発行することができる全システム範囲の同時動作の数、および所与の処理装置100が相互接続ファブリック上で発行することができるノードだけの範囲の同時動作の数を制限する。これらの深さは必要な関連を有していないし、異なるものであってもよい。しかし、好ましくは、仮想FIFOキュー924b0〜924b1、924c0〜924c1、924d0〜924d1および924e0〜924e1の深さは、LHタグFIFOキュー924aの深さと等しくなるように設計し、好ましくは、仮想FIFOキュー924c2、924d2および924e2の深さは、NMタグFIFOキュー924b2の深さと等しくなるように設計する。
ここで図20および図21を参照すると、これらの図は、図17のローカル・ハブ(LH)部分応答FIFOキュー930およびノード・マスタ/リモート・ハブ(NM/RH)部分応答FIFOキュー940の例示としての実施形態のより詳細なブロック図である。図に示すように、LH部分応答FIFOキュー930は、それぞれが、要求に対する蓄積した部分応答を格納するための部分応答フィールド1202、および異なる時間にまたはできれば同時に、ローカル・ハブ100が部分応答(すなわち、ローカル(L)、第1の層のX、Y、Zリンク、および第2の層のAおよびBリンク)を受信することができる6つの可能な各ソースに対する各フラグを有する応答フラグ・アレイ1204を含むいくつかのエントリ1200を含む。LH部分応答FIFOキュー930内のエントリ1200は、割当てポインタ1210を介して割り当てられ、割当解除ポインタ1212を介して割当解除される。Aポインタ1214、Bポインタ1215、Xポインタ1216、Yポインタ1218、およびZポインタ1220により、応答フラグ・アレイ1204を備える種々のフラグに対してアクセスが行われる。
以下にさらに説明するように、ローカル・ハブ100のところで部分応答ロジック121bにより特定の要求に対する部分応答を受信した場合には、部分応答は、部分応答フィールド1202内に蓄積され、部分応答を受信したリンクが、応答フラグ・アレイ1204内の対応するフラグを設定することにより記録される。次に、ポインタ1214、1215、1216、1218および1220のうちの対応するポインタが以降のエントリ1200に進む。
もちろん、すでに説明したように、各処理装置100をその5つのインバウンド(X、Y、Z、AおよびB)リンクのそれぞれにより他の処理装置100に完全に結合しなくてもよい。それ故、接続していないリンクに関連する応答フラグ・アレイ1204内のフラグは無視される。もし存在する場合、各処理装置100の接続していないリンクは、例えば、構成レジスタ123内に表示されている構成により表示することができ、構成レジスタは、例えば、システム始動の際のブート・コードまたはデータ処理システム200を分割する際にオペレーティング・システムにより設定することができる。
図21と図20とを比較すれば分かるように、NM/RH部分応答FIFOキュー940は、LH部分応答FIFOキュー930類似の構造を有している。NM/RH部分応答FIFOキュー940は、それぞれが蓄積した部分応答、およびノード・マスタまたはリモート・ハブ100が、部分応答(すなわち、ノード・マスタ(NM)/リモート(R)、および第1の層のX、YおよびZリンク)を受信することができる最大4つの各可能なソースに対する各フラグを有する応答フラグ・アレイ1234を格納するための部分応答フィールド1202を含むいくつかのエントリ1230を含む。さらに、各エントリ1230は、動作がノードだけのブロードキャスト動作であるか、または全システム・ブロードキャスト動作であるかを識別し、全システム・ブロードキャスト動作の場合には、インバウンドの第2の層のリンクのうちのどれが要求を受信したのか(それ故、アウトバウンドの第2の層のリンクのどれが蓄積した部分応答を送信するのか)を識別するルート・フィールド1236を含む。NM/RH部分応答FIFOキュー940内のエントリ1230は、割当ポインタ1210を介して割り当てられ、割当解除ポインタ1212を介して割当が解除される。応答フラグ・アレイ1234を含む種々のフラグは、Xポインタ1216、Yポインタ1218、およびZポインタ1220によりアクセスされ、更新される。
図20のところですでに説明したように、各処理装置100をその第1の層のX、Y、およびZリンクそれぞれにより他の処理装置100に完全に結合しなくてもよい。それ故、接続していないリンクに関連する応答フラグ・アレイ1204内のフラグは無視される。もし存在する場合、各処理装置100に接続していないリンクは、例えば、構成レジスタ123内に表示されている構成により表示することができる。
ここで図22を参照すると、この図は、図17〜図21の例示としてのデータ構造に関する例示としての全システム・ブロードキャスト動作の保有期間を示す時間空間図である。図22の頂部に示し、図4のところですでに説明したように、動作はローカル・マスタ100a0cによりローカル・ハブ100a0bを含む各ローカル・ハブ100に発行される。ローカル・ハブ100a0bは、動作をリモート・ハブ100b0aに転送し、このリモート・ハブは動作をリモート・リーフ100b0dを含むそのリモート・リーフに転送する。動作への部分応答は、同じ一連のリンクをローカル・ハブ100a0a〜100a0dへ逆の方向に横断し、ローカル・ハブ100a0a〜100a0dのそれぞれへ蓄積した部分応答をブロードキャストする。次に、ローカル・ハブ100a0bを含むローカル・ハブ100a0a〜100a0cは、要求と同じ送信経路を通して結合応答を配信する。それ故、ローカル・ハブ100a0bは、リモート・ハブ100b0aに結合応答を送信し、このリモート・ハブは、リモート・リーフ100b0dに結合応答を送信する。
上記タイミング制約により説明したように、ローカル・マスタ100a0cによる動作の開始からローカル・ハブ100a0a、100a0b、100a0cおよび100a0dによるそのランチまでの時間は変化し、ローカル・ハブ100による動作のランチからリモート・リーフ100によるその受信までの時間は制限された時間であり、リモート・リーフ100からローカル・ハブ100への部分応答待ち時間は変化し、ローカル・ハブ100からリモート・リーフ100までの結合応答待ち時間は制限された時間である。
このタイミング・シーケンスの背景に対して、図22は、動作の要求フェーズ、部分応答フェーズ、および結合応答フェーズ中のデータ処理システム200内の種々のデータ構造内の情報の種々の項目の保有期間を示す。より詳細に説明すると、参照番号1300は、LHランチ・バッファ910内の要求の保有期間(および、それ故、ローカル・ハブ・トークンの保有期間)を示し、参照番号1302は、LHタグFIFOキュー924a内のエントリの保有期間を示し、ブロック1304は、LH部分応答FIFOキュー930内のエントリ1200の保有期間を示し、参照番号1306は、RH仮想FIFO924b0または924b1内のエントリの保有期間を示し、参照番号1308は、NM/RH部分応答FIFOキュー940内のエントリ1230の保有期間を示し、参照番号1310は、RL仮想FIFOキュー924c0〜924c1、924d0〜924d1および924e0〜924e1内のエントリの保有期間を示す。図22は、さらに、保護ウィンドウ1312a、およびその部分応答の発生から結合応答の受信後までのローカル・マスタ100a0cへのメモリ・ブロックのコヒーレンシ所有権の移転を保護するために、リモート・リーフ100b0d内のスヌーパにより拡張されたウィンドウ延長部1312b(また図3および図11の312a〜312b)の持続時間を示す。参照番号1314(およびまた図3および図11の参照番号313)により示すように、ローカル・マスタ100a0cも、結合応答の受信からの所有権の移転を保護する。
参照番号1302、1306および1310で示すように、LHタグFIFOキュー924a、RH仮想FIFOキュー924b0〜924b1およびRL仮想FIFOキュー924c0〜924c1、924d0〜924d1、および924e0〜924e1内のエントリには最も長い保有期間が適用される。それ故、(一般に同じになるように設計される)要求FIFOキュー924の最小深さは、任意の時点でデータ処理システム200内のフライト中に存在することができる要求の最大数を制限する。一般に、要求FIFOキュー924の所望の深さは、任意に選択した処理装置100による要求のスヌーピーングからその処理装置100による結合応答の受信までの予想最大待ち時間を、選択したリンク情報割当てが発行することができる要求の最大数で割ることにより選択することができる。他のキュー(例えば、LH部分応答FIFOキュー930およびNM/RH部分応答FIFOキュー940)もそのエントリの保有期間がもっと短い場合には、短いキュー深さを安全に割り当てることができるが、説明を簡単にするために、少なくともいくつかの実施形態の場合には、LH部分応答FIFOキュー930の深さを要求FIFOキュー924と同じになるように設定し、NM/RH部分応答FIFOキュー940の深さを、NMタグFIFO924b2の深さにRL仮想FIFOキュー924の深さのt2/2倍を加えたものと等しくなるように設定することが望ましい。
図23は、図17〜図21の例示としてのデータ構造に関する例示としてのノードだけのブロードキャスト動作の保有期間を示す時間空間図である。図23の頂部に示し、図5のところですでに説明したように、動作は、ノード・マスタ100b0aにより、その第1の層のリンクを介して、ノード・リーフ100b0bを含むそのノード・リーフ100それぞれに発行される。動作に対する部分応答は、第1の層のリンクを横断してノード・マスタ100b0aに戻る。次に、ノード・マスタ100b0aは、その第1の層のリンクを介してノード・リーフ100b0bを含むそのノード・リーフ100それぞれに結合応答をブロードキャストする。
上記タイミング制約のところで説明したように、ノード・マスタ100b0aによる動作の開始からノード・リーフ100b0b、100b0c、100b0d内でのその送信までの時間は限定された時間であり、ノード・リーフ100からノード・マスタ100b0aまでの部分応答待ち時間は変化する時間であり、ノード・マスタ100b0aからリモート・リーフ100までの結合応答待ち時間は限定された時間である。
図23は、さらに、ノードだけのブロードキャスト動作の要求フェーズ、部分応答フェーズ、および結合応答フェーズ中のデータ処理システム200内の種々のデータ構造内の情報の種々の項目の保有期間を示す。より詳細に説明すると、参照番号1320は、NMタグFIFOキュー924b2内のエントリの保有期間を示し、参照番号1322は、NM/RH部分応答FIFOキュー940内のエントリ1230の保有期間を示し、参照番号1324は、NL仮想FIFOキュー924c2、924d2および924e2内のエントリの保有期間を示す。LHランチ・バッファ910(または関連するローカル・ハブ・トークン)、LHタグFIFOキュー924a、またはLH部分応答FIFOキュー930の保有期間は図示していない。何故なら、これらの構造は、ノードだけのブロードキャスト動作のためには使用されないからである。
最後に、図23は、その部分応答の発生から結合応答の受信までのノード・マスタ100b0aへのメモリ・ブロックのコヒーレンシ所有権の移転を保護するために、必要な場合には、ノード・リーフ100b0b内のスヌーパにより拡張した保護ウィンドウ1326(同様に、図3および図11の参照番号312a)の持続時間を示す。参照番号1328(およびまた図3および図11の参照番号313)により示すように、ノード・マスタ100b0aも、結合応答の受信からの所有権の移転を保護する。ノードだけのブロードキャスト動作の場合には、上記のタイミング制約に適合するためにウィンドウ拡張部312bは必要ない。
ここで図24〜図27を参照すると、これらの図面は、それぞれ本発明の例示としての実施形態によるローカル・マスタ(またはノード・マスタ)、ローカル・ハブ、リモート・ハブ(またはノード・マスタ)、およびリモート・リーフ(またはノード・リーフ)のところの要求フェーズ中の動作の例示としての処理を示すフローチャートである。ここで特に図24を参照すると、ローカル・マスタ(ノードだけのブロードキャストの場合には、ノード・マスタ)100のところの要求フェーズ処理は、ローカル・マスタ100内の特定のマスタ300(例えば、入出力コントローラ128内のL2キャッシュ110またはマスタ内のマスタ112のうちの1つ)が要求を発生するとブロック1400から開始する。すでに説明したように、好ましくは、要求302は、所望のアクセスのタイプを示す少なくともトランザクション・タイプおよび要求がアクセスするリソースを示すリソース識別子(例えば、実アドレス)を含む。要求は、さらに、要求の範囲(例えば、ノードだけまたは全システム)を示す(Ttypeの一部を形成することができる)範囲表示および図38に示すフォームの動作タグ2000を含むかまたは伴う。図38に示すように、動作タグ2000は、動作を開始する処理ノード202、プロセッサ100および特定のマスタ300をそれぞれ識別するノードID2002、チップID2004、およびマスタ・タグ2006を含む。ブロック1400から、プロセスはブロック1402、1404、1406、および1408に進むが、これらの各ブロックは、特定のマスタ300による要求の発行の条件を示す。ブロック1402および1404に示す条件は、マスタ・マルチプレクサ900の動作を示し、ブロック1406および1408に示す条件は要求マルチプレクサ904の動作を示す。
最初にブロック1402および1404について説明すると、マスタ・マルチプレクサ900が、マスタ・マルチプレクサ900を支配する公平なアービトレーション・ポリシーが(おそらく)複数の競合マスタ300の要求の中から特定のマスタ300の要求を選択した場合には(ブロック1402)、また要求が全システム・ブロードキャストである場合には、またローカル・ハブ・トークンが要求への割当てのために使用できる場合には(ブロック1404)、特定のマスタ300の要求を出力する。ブロック1415に示すように、マスタ300が、その要求の範囲としてノードだけの範囲を選択した場合には(例えば、構成レジスタ123の設定または上記米国特許出願第11/055,305号に記載されているような範囲予測機構あるいはその両方を参照して)、ローカル・ハブ・トークンは必要ではなく、ブロック1404に示す条件は外される。
特定のマスタ300の要求がマスタ・マルチプレクサ900を通して要求マルチプレクサ904に進んだ場合には、要求マルチプレクサ904は、アウトバウンドの第1の層のリンク情報割当て内の要求に対してアドレス保有期間を使用することができる場合だけ、要求バス905上に要求を発行する(ブロック1406)。すなわち、要求マルチプレクサ904の出力は、選択したリンク情報割当てとタイムスライス整合し、要求(例えば、図12の実施形態のサイクル0または2、または図15の実施形態のサイクル0)を運ぶように設計されたサイクル中だけ出力を発生する。さらにブロック1408に示すように、要求マルチプレクサ904は、いつでも優先権が与えられるリモート・ハブ・マルチプレクサ903が、インバウンドの第2の層のAおよびBリンクから要求を提示しない場合にだけ要求を発行する(ブロック1406)。それ故、第2の層のリンクは、インバウンド要求によりブロックされないことを保証される。このようなブロックされないポリシーを使用した場合でも、マスタ300による要求は、下流のハブのインバウンドAおよびBリンク上のいくつかの連続しているアドレス保有期間中、要求の「レンガ壁」を防止する上流ハブのアービタ1032内の適当なポリシーの実施により「不足」から免れることができる。
ブロック1402〜1408のうちの任意のブロックにおいて「いいえ」と判断した場合には、ブロック1402〜1408すべてのブロックでの判断が「はい」である後続のサイクルまでブロック1401に示すように要求は遅延する。一方、ブロック1402〜1408すべてのところで「はい」と判断された場合には、プロセスはブロック1417に進む。ブロック1417は、(Ttypeフィールド700の範囲インジケータ730またはTtypeフィールド800の範囲インジケータ830が示すように)ノードだけの範囲の要求に、ブロック1419〜1423に示す2つの追加条件が課せられることを示す。最初に、ブロック1419に示すように、要求がノードだけのブロードキャスト要求である場合には、NMタグFIFOキュー924b2内の要求への割当てにエントリを使用することができる場合だけ、要求マルチプレクサ904は要求を発行する。そうでない場合には、プロセスはブロック1419からすでに説明したブロック1410へ戻る。
第二に、ブロック1423に示すように、要求マルチプレクサ904は、前の要求FIFOバッファ907内にバッファされている選択した数の前の要求のいずれかとして、バンクを含むリソース1910の同じバンク1912に要求アドレスがハッシュされない場合だけ、ノードだけの範囲の要求を発行する。例えば、スヌーピーング・デバイス1900が最大要求到着レートで要求にサービスすることはできないが、代わりに1/Rで表される最大到着レートの何分の1かで要求にサービスすることができるように、スヌーピーング・デバイス1900およびその関連するリソース1910が構成されていると仮定した場合には、同じアドレス・スライスに入るかどうかを判定するために、要求マルチプレクサ904によるランチのために競合している現在のノードだけの要求が比較される選択した数の前の要求は、好ましくは、R−1である。複数の異なるスヌーピーング・デバイス1900を、この方法で要求のオーバーランから保護する場合には、選択した数の要求R−1は、好ましくは、個々のスヌーピーング・デバイス1900に対して計算した一組の数値R−1の最大値に設定する。好ましくは、処理装置100はブロードキャストのための要求のその選択に調整しないので、ブロック1423に示す方法で要求を絞っても、特定のスヌーピーング・デバイス1900のところの要求の到着レートがスヌーピーング・デバイス1900のサービス速度を超えないという保証はない。しかし、図の方法でノードだけのブロードキャスト要求を絞り込めば、所与の数のサイクル中に到着する要求の数が下式のように制限される。
絞り込まれた到着レート=Rサイクル当たりのPU要求
ここで、PUは処理ノード202当たりの処理装置100の数である。好ましくは、スヌーピーング・デバイス1900は、再試行を行わないでこのような絞り込まれた到着レートで到着するノードだけのブロードキャスト要求を処理するように設計する。
ブロック1423に示す条件を満たさない場合には、プロセスはブロック1423からすでに説明したブロック1410に戻る。しかし、ブロック1419および1423に示す両方の条件を満たす場合には、要求マルチプレクサ904は、要求バス905上でノードだけのブロードキャスト要求を発行し、プロセスはページ・コネクタ1425を通って図26のブロック1427に進む。
再度ブロック1417に戻って説明すると、要求がノードだけのブロードキャスト要求ではなく全システム・ブロードキャスト要求である場合には、プロセスはブロック1412に進み、図13の保有期間1300を開始する。ブロック1412は、各アウトバウンドX、YおよびZリンクおよびローカル・ハブ・アドレス・ランチ・バッファ910に要求バス 905により要求をブロードキャストしている要求マルチプレクサ904を示す。その後で、プロセスは2つに分岐し、各ローカル・ハブ100のところでの要求の処理を示す図25へのページ・コネクタ1414および1416を通る。
ここで図25を参照すると、これらの図面は、また、ブロック1416から開始するローカル・マスタ100であるローカル・ハブ100のところでの要求の処理、およびブロック1414から開始するローカル・マスタ100としての同じ処理ノード202内の他のローカル・ハブ100のそれぞれのところでの要求の処理を示す。最初にブロック1414について説明すると、インバウンドX、YおよびZリンク上でローカル・ハブ100が受信した要求は、LHアドレス・ランチ・バッファ910により受信される。図18のブロック1420のところに示すように、マップ・ロジック1010は、バッファするために位置に依存するFIFOキュー1020a〜1020dのうちの適当なキューに、X、YおよびZ要求のそれぞれをマッピングする。すでに説明したように、X、YおよびZリンク上で受信し、位置に依存するキュー1020a〜1020d内に収容した要求はすぐには確認されない。代わりに、これらの要求には、所与のローカル・ハブ100上のX、YおよびZ要求およびローカル要求の処理を、同じ処理ノード202内の他のローカル・ハブ100のところの対応する要求の処理と同期させる各調整遅延1000a〜1000dが与えられる(ブロック1422)。その後で、ブロック1430に示すように、調整遅延1000は、位置に依存するFIFOキュー1020a〜1020d内のその各キューを確認する。
ここでブロック1416について説明すると、ローカル・マスタ/ローカル・ハブ100のところで、要求バス905上の要求は、直接、LHアドレス・ランチ・バッファ910に送られる。チップ間リンクを通過していないので、このローカル要求は、同じサイクル内で発行された要求がインバウンドX、YおよびZリンク上に到着するより早く、LHアドレス・ランチFIFO910に到着する。それ故、ブロック1424に示すマップ・ロジック1010によるマッピングの後で、調整遅延1000a〜1000dのうちの1つが、その確認をインバウンドX、YおよびZリンク上で受信した要求の確認と同期させるために、ローカル要求に長い遅延を適用する(ブロック1426)。この遅延間隔の後で、関連する調整遅延1000が、ブロック1430に示すようにローカル要求を確認する。
ブロック1430のところでのLHアドレス・ランチ・バッファ910内のキューの形をしている要求の確認の後で、プロセスは、それぞれがアービタ1032が強制的に行ったLHアドレス・ランチ・バッファ910からの要求の発行の条件を示すブロック1434〜1440に進む。すでに説明したように、すべての処理装置100内のアービタ1032は同期しているので、相互通信を行わなくてもすべてのローカル・ハブ100は同じ決定を行う。ブロック1434に示すように、アービタ1032により、ローカル・ハブ要求マルチプレクサ1030は、アウトバウンドの第2の層のリンク情報割当て内の要求に対してアドレス保有期間を使用することができる場合だけ、要求を出力することができる。それ故、例えば、アービタ1032は、図13の実施形態のサイクル0または2、または図16の実施形態のサイクル0の間だけ、ローカル・ハブ要求マルチプレクサ1030に要求の送信を開始させる。さらに、アービタ1032が実施した公平なアービトレーション・ポリシーが、要求が次にサービスを受ける位置に依存するFIFOキュー1020a〜1020dに属すると判定した場合に、ローカル・ハブ要求マルチプレクサ1030により要求が出力される(ブロック1436)。
さらにブロック1437および1438に示すように、アービタ1032は、自身が連続しているアドレス保有期間内にそんなに多くの要求を出力していないと判定した場合だけ、ローカル・ハブ要求マルチプレクサ1030に要求を出力させる。より詳細には、ブロック1437に示すように、アウトバウンドAおよびBリンクに接続しているハブ100の要求バス905の過度の駆動を避けるために、アービタ1032は、最悪の場合(すなわち、下流のハブ100の他の第2の層のリンクに接続している上流のハブ100が、同じサイクル中に要求を送信している場合)を仮定して、使用できるアドレス保有期間の僅か半分(すなわち、1/t2)の間に要求をランチする。さらに、ブロック1438に示すように、アービタ1032は、さらに、そのアウトバウンドAおよびBリンクに結合している処理装置100内のマスタ300の起こりうる「不足状態」を回避するために、第2の層のリンク上のトラフィックの公平な割当ての下で要求のランチを制限する。
例えば、処理ノード202当たり2対の第2の層のリンクおよび4つの処理装置100を含む図2の実施形態の場合には、下流のハブ100の要求バス905上のトラフィックは、最大9つの処理装置100、すなわち、第2の層のリンクおよび下流のハブ100自身により、下流のハブ100と結合している2つの各処理ノード202内の4つの処理装置100と競合することになる。それ故、可能な要求ソース間で要求バス905の帯域幅を等しく分割する例示としての公平な割当てポリシーは、帯域幅の4/9を各インバウンドAおよびBリンクに、帯域幅の1/9をローカル・マスタ300に割り当てる。任意の数の第1および第2の層のリンクに対して一般化した場合、アービタ1032が使用する例示としての公平な割当てポリシーが消費する割当ての使用することができるアドレス・フレームの一部は、下式により表すことができる。
一部(fraction)=(t1/2+1)/(t2/2*(t1/2+1)+1)
ここで、t1およびt2は、処理装置100を結合することができる第1および第2の層のリンクの全数であり、数値「t1/2+1」は、処理ノード202当たりの処理装置100の数であり、数値「t2/2」は、下流のハブ100が結合することができる処理ノード202の数であり、一定の数値「1」は下流のハブ100に割り当てられた帯域幅の一部である。
ブロック1439に示すように、アービタ1032は、要求アドレスが、バンクを含むリソース1910の同じバンク1912にハッシュしない場合だけに、前の要求FIFOバッファ911内にバッファされているR−1の前の要求のいずれかとして、全システム・ブロードキャスト要求を発行することにより全システム・ブロードキャスト要求の送信をさらに絞り込む。ここで、1/Rは、最も遅い保護されているスヌーピーング・デバイス1900が要求にサービスすることができる最大到着レートの一部である。それ故、図の方法で全システム・ブロードキャスト要求を絞り込めば、所与の数のサイクル中に所与のスヌーピーング・デバイス1900のところに到着することができる要求の数が下式のように制限される。
絞り込まれた到着レート(throttled_arr_rate)
=Rサイクル当たりのN要求
ここで、Nは処理ノード202の数である。好ましくは、スヌーピーング・デバイス1900は、再試行を行わないでこのような絞り込まれた到着レートで到着する要求を処理するように設計する。
最後にブロック1440のところに示す条件について説明すると、アービタ1032により、ローカル・ハブ要求マルチプレクサ1030は、LHタグFIFOキュー924a内の割当てに対してエントリを使用することができる場合だけ要求を出力することができる(ブロック1440)。
ブロック1434〜1440のいずれかで「いいえ」と判断した場合には、ブロック1434〜1440すべてのブロックでの判断が「はい」である後続のサイクルまで、ブロック1442に示すように要求は遅延する。一方、ブロック1434〜1440すべてのところで「はい」と判断した場合には、アービタ1032は、ローカル・ハブ要求マルチプレクサ1030に、もしあった場合に、LHアドレス・ランチ・バッファ910が提示する要求にいつでも優先権を与えるマルチプレクサ920の入力に選択した要求を出力するように信号を送る。それ故、マルチプレクサ920は、スヌープ・バス922上で要求を発行する。マルチプレクサ920の他のポート(例えば、RH、RLX、RLY、およびRLZ)は、LHアドレス・ランチ・バッファ910と一緒に、スヌープ・バス922の最大帯域幅が、最大到着レートに遅れないためにアウトバウンドAおよびBリンクの帯域幅の10/8(図13の実施形態を仮定した場合)または5/6(図16の実施形態を仮定した場合)でなければならないことを意味する要求を提示することができることに留意されたい。
また、ローカル・ハブ・アドレス・ランチ・バッファ910内にバッファしている要求だけが、アウトバウンドAおよびBリンクにより送信され、リンク情報割当て内のアドレス保有期間との整合が要求されることを観察されたい。マルチプレクサ920の発行に競合するすべての他の要求は、アウトバウンドAおよびBリンクではなくローカル・スヌーパ304およびその各FIFOキューだけを目標としているので、このような要求を情報フレームの残りのサイクル中に発行することができる。それ故、マルチプレクサ920が使用する特定のアービトレーション・スキームが何であれ、マルチプレクサ920に同時に提示されるすべての要求の1つの情報フレームの持続時間内での送信が保証される。
ブロック1444に示すように、スヌープ・バス922上での要求の発行に応じて、LHタグFIFOキュー924aは、保有期間1302を開始する次の使用できるエントリのマスタ・タグ・フィールド1100内の要求に指定されているマスタ・タグを記録する。次に、要求は、ブロック1446に示すように、アウトバウンドAおよびBリンクに経路指定される。次に、プロセスは、ページ・コネクタ1448を通って、要求フェーズ中の各リモート・ハブのところの要求の処理を示す図25に進む。
図25に示すプロセスは、また、ブロック1446からLHアドレス・ランチ・バッファ910、終わりの保有期間1300からの要求の除去に応じて、要求に割り当てられたローカル・ハブ・トークンを解放するローカル・ハブ100を示すブロック1450に進む。要求は、さらに、ブロック1452に示すように、LHタグFIFOキュー924a内の割り当てられたエントリを識別するチケット番号と一緒に、ローカル・ハブ100内のスヌーパ304に経路指定される。すでに説明したように、要求は、少なくとも、所望のアクセスのタイプを示すトランザクション・タイプ(Ttype)、要求がアクセスするリソースを示すリソース識別子(例えば、実アドレス)を含み、さらに、(Ttypeの一部を形成することができる)範囲インジケータおよび動作タグを含むかまたは伴っている。要求を受信すると、チケット番号、範囲インジケータおよび動作タグ、スヌーパ304は、必要な場合には、ノードID2002、チップID2004、マスタ・タグ2006、チケット番号2022および範囲インジケータ2024を、図40に示すように、要求バッファ2020内にバッファする。さらに、スヌーパ304は、必要な場合には、LH部分応答FIFOキュー930、開始保有期間1304内に記録される部分応答(ブロック1454)を発生する(ブロック1456)。より詳細に説明すると、ブロック1456において、LH部分応答FIFOキュー930内のエントリ1200は、割当ポインタ1210を参照して要求に割り当てられ、割当ポインタ1210は増分増大し、ローカル・ハブの部分応答は、割り当てられたエントリの部分応答フィールド1202内に収容され、またローカル(L)フラグは、応答フラグ・フィールド1204内に設定される。その後で、ローカル・ハブ100の要求フェーズ処理はブロック1458のところで終了する。
ここで図26を参照すると、この図は、本発明によるリモート・ハブ(またはノードだけのブロードキャスト要求に対するノード・マスタ)100のところでの例示としての要求の処理方法のハイレベル論理フローチャートである。図に示すように、全システム・ブロードキャスト要求の場合には、プロセスは、そのインバウンドAおよびBリンクの一方上のリモート・ハブ100のところで要求を受信した場合に、ページ・コネクタ1448のところから開始する。すでに説明したように、ブロック1460に示すように、各保持バッファ902a〜902bに要求がラッチされた後で、ブロック1464および1465のところに示すように、要求バス905により送信するために、要求がリモート・ハブ・マルチプレクサ903および要求マルチプレクサ904により評価される。より詳細には、ブロック1464において、リモート・ハブ・マルチプレクサ903は、インバウンドの第2の層のリンク上で受信した要求にアドレス保有期間を均等に割り当てる公平な割当てポリシーにより、要求を出力するかどうかを決定する。さらに、ブロック1465に示すように、第1の層のリンク情報割当てとタイムスライス整合している要求マルチプレクサ904は、アドレス保有期間を使用することができる場合にだけ要求を出力する。それ故、ブロック1466に示すように、要求が、マルチプレクサ903の公平な割当てポリシーの下でのウィニング要求でない場合、または次にアドレス保有期間が使用できない場合には、マルチプレクサ904は次のアドレス保有期間を受信するために待機する。しかし、インバウンドの第2の層のリンク上で受信した要求が遅延している場合でも、遅延は第1の層のリンク情報割当ての僅か1つのフレームにしか過ぎないことを理解することができるだろう。
ブロック1464および1465に示す両方の条件が満たされた場合には、マルチプレクサ904は、要求バス905上で要求をランチし、プロセスはブロック1465からブロック1468に進む。図に示すように、図24のブロック1421からのものでブロック1423において引き続き行われるノード・マスタ100のところでの要求フェーズ処理もブロック1468に進む。ブロック1468は、要求バス905上で発行された要求のアウトバウンドX、YおよびZリンクならびにNM/RH保持バッファ906への経路指定を示す。ブロック1468の後で、プロセスは2つに分岐する。第1の経路は、ページ・コネクタ1470を通って、リモート(またはノード)リーフ100のところでの例示としての要求の処理方法を示す図27に進む。ブロック1468からの第2の経路は、その入力のところに提示された要求のうちのどれをスヌープ・バス922に出力すべきかを決定するスヌープ・マルチプレクサ920を示すブロック1474に進む。図に示すように、スヌープ・マルチプレクサ920は、リモート・ハブ要求よりも高い優先権をローカル・ハブ要求に与え、リモート・ハブ要求は、NL/RL保持バッファ914a〜914c内にバッファされている要求よりも高い優先権を有する。それ故、ローカル・ハブ要求がLHアドレス・ランチ・バッファ910により選択のために提示された場合には、ブロック1476に示すように、NM/RH保持バッファ906内にバッファされている要求は遅延する。しかし、LHアドレス・ランチ・バッファ910により要求が提示されない場合には、スヌープ・マルチプレクサ920は、スヌープ・バス922上のNM/RH保持バッファ906から要求を発行する。
スヌープ・バス922上で要求を検出した場合には、要求FIFOキュー924bのうちの適当なキュー(すなわち、ノードだけのブロードキャスト要求の場合には、NMタグFIFOキュー924b2、全システム・ブロードキャスト要求の場合には、要求を受信したインバウンドの第2の層のリンクに関連するRH仮想FIFOキュー924b0および924b1のうちの1つ)は、要求に、関連するヘッド・ポインタ1100、開始保有期間1306または1320が識別した次に使用できるキュー・エントリを割り当てる(ブロック1478)。NMタグFIFOキュー924b2がキュー・エントリを割り当てた場合には、マスタ・タグも割り当てられたエントリ内に配置される。すでに説明したように、ノードだけのブロードキャスト要求および全システムのブロードキャスト要求は、要求のTtypeフィールド700または800内の範囲識別子730または830により異なる。リモート・ハブ100内においては、ブロック1480に示すように、動作タグ2000および関連する要求FIFOキュー924b内の割り当てられたエントリを識別するチケット番号と一緒に、要求がさらにスヌーパ304に経路指定される。
要求、チケット番号および動作タグを受信した場合には、スヌーパ304は、必要な場合には、図40に示すように、要求バッファ2020内に、ノードID2002、チップID2004、マスタ・タグ2006、チケット番号2022および範囲インジケータ2024をバッファする。さらに、スヌーパ304は、NM/RH部分応答FIFOキュー940、開始保有期間1308または1322内に記録される部分応答をブロック1482のところで発生する(ブロック1484)。より詳細には、NM/RH部分応答FIFOキュー940内のエントリ1230は、その割当ポインタ1210を参照して要求に割り当てられ、割当ポインタ1210が増分増大し、リモート・ハブの部分応答が、部分応答フィールド1202内に収容され、ノード・マスタ/リモート・フラグ(NM/R)が応答フラグ・フィールド1234内に設定される。それ故、NM/RH部分応答FIFOキュー940が、同じデータ構造の異なる範囲の動作に対する部分応答をバッファすることに留意されたい。その後で、リモート・ハブ100のところでの要求フェーズ処理はブロック1486のところで終了する。
ここで図27を参照すると、この図は、本発明によるリモート・リーフ(またはノード・リーフ)100のところでの例示としての要求処理方法のハイレベル論理フローチャートである。図に示すように、プロセスは、そのインバウンドX、YおよびZリンクのうちの1つによりリモート・リーフまたはノード・リーフ100のところで要求を受信した場合に、ページ・コネクタ1470のところから開始する。ブロック1490に示すように、要求を受信すると、要求は、要求を受信した第1の層のリンクに関連するNL/RL保持バッファ914a〜914cのうちの特定のバッファ内にラッチされる。次に、ブロック1491に示すように、要求は、その入力に提示された他の要求と一緒にスヌープ・マルチプレクサ920により評価される。すでに説明したように、スヌープ・マルチプレクサ920は、リモート・ハブ要求よりも高い優先権をローカル・ハブ要求に与え、リモート・ハブ要求は、NL/RL保持バッファ914a〜941c内にバッファされている要求よりも高い優先権を有する。それ故、ローカル・ハブ要求またはリモート・ハブ要求が選択のために提示された場合には、ブロック1492に示すように、NL/RL保持バッファ914内にバッファされている要求は遅延する。しかし、スヌープ・マルチプレクサ920により高い優先権要求が提示されなかった場合には、スヌープ・マルチプレクサ920は、スヌープ・バス922上のNL/RL保持バッファ914から要求を発行し、X、YおよびZ要求の間で公平な選択を行う。
スヌープ・バス922上の要求に応じて、要求の範囲および要求を受信した経路に関連する仮想FIFOキュー924c0〜924c2、924d0〜924d2および924e0〜924e2の特定のキュー内の次に使用することができるエントリが、ヘッド・ポインタ1100、開始保有期間1310または1324を参照して割り当てられる(ブロック1493)。すなわち、要求のTtypeフィールド700または800内の範囲インジケータ730または830が、要求がノードだけの範囲であるか、または全システムの範囲であるかを判定するために使用される。すでに説明したように、ノードだけのブロードキャスト要求の場合には、要求を受信したインバウンドの第1の層のリンクに関連するNL仮想FIFOキュー924c2、924d2および924e2の特定の1つのキュー内でエントリが割り当てられる。全システム・ブロードキャスト要求の場合には、要求を受信したインバウンドの第1および第2の層のリンクの組合せに対応するRL仮想FIFOキュー924c0〜924c1、924d0〜924d1および924e0〜924e1のうちの特定の1つのキュー内でエントリが割り当てられる。要求、動作タグ2000、およびRL仮想FIFOキュー924のうちの1つ内の要求に割り当てられた仮想エントリを識別するチケット番号は、さらに、ブロック1494に示すように、リモート・リーフ100内のスヌーパ304に経路指定される。すでに説明したように、要求は、少なくとも、所望のアクセスのタイプを示すトランザクション・タイプ(Ttype)、要求がアクセスするリソースを示すリソース識別子(例えば、実アドレス)を含み、さらに、(Ttypeの一部を形成することができる)範囲インジケータを含むかまたは伴っている。要求、チケット番号、および動作タグを受信すると、図40に示すように、スヌーパ304は、必要な場合には、ノードID2002、チップID2004、マスタ・タグ2006、チケット番号2022および範囲インジケータ2024を要求バッファ2020内にバッファする。また、スヌーパ304は、その処理装置100の部分応答を入手するために、要求を処理し、その各部分応答を発生し、部分応答を蓄積する(ブロック1495)。ページ・コネクタ1497が示すように、リモート・リーフまたはノード・リーフ100のスヌーパ304の部分応答は、以下に説明する図30により処理される。
図28は、図25〜図27の例えばブロック1454、1482、および1495のところでスヌーパ304が要求に対する部分応答を発生する例示としての方法のハイレベル論理フローチャートである。プロセスは、スヌーパ304(例えば、IMCスヌーパ126、L2キャッシュ・スヌーパ116または入出力コントローラ128内のスヌーパ)が要求を受信した場合にブロック1401から開始する。要求を受信すると、スヌーパ304は、要求が指定するトランザクション・タイプを参照して、要求がキャストアウト要求、書込み要求、または部分書込み要求のような書込みタイプの要求であるかどうかを判定する。スヌーパ304がブロック1403で要求が書込みタイプの要求ではない(例えば、読取りまたはRWITM要求)と判定した場合には、プロセスは、必要な場合には、従来の処理により要求に対する部分応答を発生するスヌーパ304を示すブロック1405に進む。しかし、スヌーパ304が要求が書込みタイプの要求であると判定した場合には、プロセスはブロック1407に進む。
ブロック1407は、それが書込みタイプの要求が指定する要求アドレスに対するLPCであるかどうかを判定するスヌーパ304を示す。例えば、スヌーパ304は、1つまたは複数のベース・アドレス・レジスタ(BAR)またはスヌーパ304が責任を有するアドレス範囲を指定しているアドレス・ハッシュ関数(すなわち、LPC)あるいはその両方を参照して図の判定を行うことができる。スヌーパ304がそれが要求アドレスに対するLPCでないと判定した場合には、プロセスはブロック1409に進む。ブロック1409は、有効フィールド722および宛先タグ・フィールド724が、すべて「0」からなり、それによりスヌーパ304が要求アドレスに対するLPCでないことを意味する書込み要求部分応答720(図14)を発生しているスヌーパ304を示す。しかし、スヌーパ304が、ブロック1407において、それが要求アドレスに対するLPCであると判定した場合には、プロセスは、有効フィールド722が「1」に設定され、宛先タグ・フィールド724が、宛先タグまたはデータ処理システム200内でスヌーパ304の位置を一意に識別する経路を指定する書込み要求部分応答720を発生しているスヌーパ304を示すブロック1411に進む。ブロック1409または1411の後で、図28のプロセスはブロック1413において終了する。
VII.部分応答フェーズの構造および動作
ここで図29を参照すると、この図は、図1の相互接続ロジック120内の部分応答ロジック121bの例示としての実施形態を示すブロック図である。図に示すように、部分応答ロジック121bは、リモート・リーフ(またはノード・リーフ)100のところでスヌーパ304が発生したリモート部分応答を、アウトバウンドの第1の層のX、YおよびZリンクのうちの適当な1つのリンクを介して要求を受信したリモート・ハブ(またはノード・マスタ)100に経路指定するルート・ロジック1500を含む。さらに、部分応答ロジック121bは、結合ロジック1502およびルート・ロジック1504を含む。結合ロジック1502は、NM/RH部分応答FIFOキュー940内にバッファされている同じ要求に対する他の部分応答と一緒に、リモート(またはノード)リーフ100から受信した部分応答を蓄積する。ノードだけのブロードキャスト動作の場合には、ノード・マスタ100の結合ロジック1502は、蓄積した部分応答を応答ロジック122に直接提供する。全システムのブロードキャスト動作の場合には、結合ロジック1502は、蓄積した部分応答を、蓄積した部分応答をアウトバウンドAおよびBリンクのうちの1つを介してローカル・ハブ100に経路指定するルート・ロジック1504に供給する。
部分応答ロジック121bは、さらに、リモート・ハブ100からの部分応答を受信し、バッファする保持バッファ1506a〜1506b、保持バッファ1506a〜1506b内にバッファされている部分応答の中から選択するための公平なアービトレーション・ポリシーを適用するマルチプレクサ1507、およびマルチプレクサ1507が選択した部分応答を、その処理ノード202内の他の各処理装置100にブロードキャストするブロードキャスト・ロジック1508を含む。マルチプレクサ1507の出力をプログラマブル遅延装置1509と結合している経路によりさらに示すように、マルチプレクサ1507は、ほぼ1つの第1の層のリンクの待ち時間だけプログラマブル遅延装置1509により遅延している部分応答のローカル・ブロードキャストを行い、そのためインバウンドX、YおよびZリンク上で他の処理装置100から受信した部分応答とほぼ同時に、ローカル的にブロードキャストした部分応答が結合ロジック1510により受信される。結合ロジック1510は、(LH部分応答FIFOキュー930内にバッファされている)ローカル的に発生した部分応答と一緒に、インバウンドX、YおよびZリンク上で受信した部分応答、およびインバウンドの第2の層のリンクから受信したローカル的にブロードキャストした部分応答を蓄積し、要求に対する結合応答を発生するために蓄積した部分応答を応答ロジック122に送る。
ここで図30〜図32を参照すると、これらの図は、リモート・リーフ(またはノード・リーフ)、リモート・ハブ(またはノード・マスタ)、およびローカル・ハブのところでの動作の部分応答フェーズ中の例示としての処理をそれぞれ示すフローチャートである。これらの図面中、部分応答の送信は、図には明示していない種々の遅延を受ける。しかし、すでに説明したように、部分応答待ち時間にはタイミングの制約がないので、このような遅延は、もし存在しても、動作中エラーを発生しないのでこれ以上の説明は省略する。
ここで図30について詳細に説明すると、リモート・リーフ(またはノード・リーフ)100のところでの部分応答フェーズの処理は、リモート・リーフ(またはノード・リーフ)100のスヌーパ304が要求の部分応答を発生した場合に、ブロック1600から開始する。ブロック1602に示すように、次に、ルート・ロジック1500は、リンク情報割当のリモート部分応答フィールド712または812により、要求を受信したインバウンドの第1の層のリンクに対応するアウトバウンドX、YまたはZリンクを介して、要求に対するリモート・ハブ100に部分応答を経路指定する。すでに説明したように、要求を受信し、仮想FIFOキュー924c0〜924c2、924d0〜924d2および924e0〜924e2のうちの1つが要求に仮想エントリを割り当てたインバウンドの第1の層のリンクが示される。その後で、ページ・コネクタ1604により示し、図31を参照して以下に説明するように、リモート・ハブ(またはノード・マスタ)100のところで部分応答の処理が引き続き行われる。
ここで図31を参照すると、この図は、本発明によるリモート・ハブ(またはノード・マスタ)のところでの部分応答の処理方法の例示としての実施形態のハイレベル論理フローチャートである。図のプロセスは、第1の層のX、YおよびZリンクのうちの1つによりリモート・ハブ(またはノード・マスタ)100と結合しているリモート・リーフ(またはノード・リーフ)100のうちの1つの部分応答を受信した場合に、ページ・コネクタ1604から開始する。部分応答を受信すると、結合ロジック1502は、動作に割り当てられたNM/RH部分応答FIFOキュー940内のエントリ1230を読み出す。エントリは、部分応答を受信したリンクに関連するX、YまたはZポインタ1216〜1220が示すように、NM/RH部分応答FIFOキュー940内で観察したFIFOの順序により識別される。次に、結合ロジック1502は、読み取ったエントリ1230の部分応答フィールド1202の内容と一緒に、リモート(またはノード)リーフ100の部分応答を蓄積する。すでに説明したように、好ましくは、蓄積動作は、論理OR演算のような非破壊的動作である。次に、結合ロジック1502は、ブロック1614のところで、エントリ1230の応答フラグ・アレイ1234を参照して、ブロック1604のところで受信した部分応答により、すべてのリモート・リーフ100がその各部分応答を報告したかどうかを判定する。報告していない場合には、プロセスは、蓄積した部分応答により動作に割り当てられたエントリ1230の部分応答フィールド1202を更新し、どのリモート・リーフ100が部分応答を提供したのかを示すために、応答フラグ・アレイ1234内に適当なフラグを設定し、ポインタ1216〜1220のうちの関連するものを前進させる結合ロジック1502を示すブロック1616に進む。その後で、プロセスはブロック1618のところで終了する。
再度ブロック1614について説明すると、結合ロジック1502が、すべてのリモート(またはノード)リーフ100が動作に対する各部分応答を報告したと判定した場合に、結合ロジック1502は、割当解除ポインタ1212、終了保有期間1308または1322を参照して、NM/RH部分応答FIFOキュー940からの動作に対するエントリ1230の割当を解除する(ブロック1620)。ブロック1621および1623に示すように、エントリのルート・フィールド1236が動作がノードだけのブロードキャスト動作であると表示した場合には、結合ロジック1502は、蓄積した部分応答を応答ロジック122に直接提供する。その後で、プロセスは、以下に説明する図34のページ・コネクタ1625を通して進む。ブロック1621に戻って説明すると、割当解除したエントリのルート・フィールド1236が、動作がノードだけのブロードキャスト動作でなく、全システム・ブロードキャスト動作であると表示した場合には、結合ロジック1502は、代わりに、ブロック1622に示すように、リンク割当情報内のリモート部分応答フィールド712または812により、ルート・フィールド1236の内容により表示するアウトバウンドAおよびBリンクのうちの特定の1つのリンクに、蓄積した部分応答を経路指定する。その後で、プロセスはページ・コネクタ1624を通して図32に進む。
ここで図32を参照すると、この図は、本発明のある実施形態によるローカル・ハブ100(ローカル・マスタ100を含む)のところでの部分応答処理の例示としての方法のハイレベル論理フローチャートである。プロセスは、インバウンドAおよびBリンクの一方を介してリモート・ハブ100から部分応答のローカル・ハブ100のところでの受信に応じて、ブロック1624から開始する。受信すると、部分応答は、部分応答を受信したインバウンドの第2の層のリンクと結合している保持バッファ1506a、1506b内に収容される。ブロック1627に示すように、マルチプレクサ1507は、保持バッファ1506a〜1506b内にバッファされている部分応答の中から選択するために、公平なアービトレーション・ポリシーを適用する。それ故、公平なアービトレーション・ポリシーにより部分応答が選択されなかった場合には、ブロック1628のところに示すように、部分応答のブロードキャストが遅延する。部分応答が公平なアービトレーション・ポリシーにより選択されると、おそらく遅延の後で、マルチプレクサ1507はブロードキャスト・ロジック1508およびプログラマブル遅延装置1509に部分応答を出力する。マルチプレクサ1507の出力バスは、部分応答によりオーバーランにならない。何故なら、部分応答の到着レートが、要求ランチの速度により制限されるからである。ブロック1627の後で、プロセスはブロック1629に進む。
ブロック1629は、第1の層のX、YおよびZリンクを介してその処理ノード202内で他の各処理装置100、およびプログラマブル遅延装置1509へ部分応答を出力することにより、部分応答のローカル・ブロードキャストを行っているマルチプレクサ1507に、マルチプレクサ1507が選択した部分応答をブロードキャストしているブロードキャスト・ロジック1508を示す。その後で、プロセスは2つに分岐し、他のローカル・バス100のところでの部分応答フェーズの処理の継続を示すブロック1631およびブロック1630のそれぞれに進む。ブロック1630に示すように、現在のローカル・ハブ100内の部分応答ブロードキャストは、第1の層のリンクのほぼ送信の待ち時間だけ、プログラマブル遅延装置1509により遅延するので、インバウンドX、YおよびZリンク上で他の処理装置100から受信した部分応答とほぼ同時に、ローカル的にブロードキャストした部分応答が結合ロジック1510により受信される。ブロック1640のところに示すように、結合ロジック1510は、インバウンドの第1の層のリンクから受信した部分応答と一緒に、またLH部分応答FIFOキュー930内にバッファされるローカル的に発生した部分応答と一緒に、ローカル的にブロードキャストした部分応答を蓄積する。
部分応答を蓄積するために、結合ロジック1510は、最初に動作に割り当てられたLH部分応答FIFOキュー930内のエントリ1200を読み出す。エントリは、部分応答を受信したポインタ1214、1215のうちの特定の1つのポインタが示すように、LH部分応答FIFOキュー930内で観察したFIFOの順序により識別される。次に、結合ロジック1510は、読み取ったエントリ1200の部分応答フィールド1202の内容と一緒に、リモート・ハブ100のローカル的にブロードキャストした部分応答を蓄積する。次に、ブロック1642に示すように、結合ロジック1510は、さらに、エントリ1200の応答フラグ・アレイ1204を参照して、現在受信した部分応答により、部分応答を予想した各処理装置100から部分応答を受信したかどうかを判定する。受信していない場合には、プロセスは、新しく蓄積した部分応答により、LH部分応答FIFOキュー930から読み取ったエントリ1200を更新している結合ロジック1510を示すブロック1644に進む。その後で、プロセスはブロック1646のところで終了する。
ブロック1642に戻って説明すると、結合ロジック1510が、部分応答を予想するすべての処理装置100が、その部分応答を報告したと判定した場合には、プロセスはブロック1650に進む。ブロック1650は、割当解除ポインタ1212、終了保有期間1304を参照して、LH部分応答FIFOキュー930からの動作に割り当てられたエントリ1200の割当を解除する結合ロジック1510を示す。次に、結合ロジック1510は、ブロック1652に示すように、結合応答を発生するために応答ロジック122に、蓄積した部分応答を送る。その後で、プロセスは、ページ・コネクタ1654を通って、ローカル・ハブ100のところでの結合応答処理を示す図34に進む。
ここでブロック1632に戻って説明すると、1つまたは複数の第1の層のリンク上でローカル・ハブ100が受信した部分応答の処理は、結合ロジック1510が部分応答を受信した場合に開始する。ブロック1634に示すように、結合ロジック1510は、部分応答の処理を他の各部分応答およびローカル的にブロードキャストした部分応答と同期させるために、短い調整遅延をインバウンドの第1の層のリンク上で受信した部分応答に適用することができる。その後で、部分応答は、すでに説明したブロック1640および後続のブロックのところに示すように処理される。
VIII.結合応答フェーズの構造および動作
ここで図33を参照すると、この図は、本発明による図1の相互接続ロジック120内の結合応答ロジック121cの例示としての実施形態のブロック図である。図に示すように、結合応答ロジック121cは、各インバウンドAおよびBリンクによりローカル・ハブ100と結合しているリモート・ハブ100から結合応答をそれぞれ受信し、バッファする保持バッファ1702a〜1702bを含む。保持バッファ1702a〜1702bの出力は、情報フレームの結合応答フィールド710または810内の第1のバス1705上にランチするために、もしあった場合に、保持バッファ1702a〜1702bがバッファする結合応答の中から選択するために公平なアービトレーション・ポリシーを適用する第1のマルチプレクサ1704の2つの入力を形成する。
第1のマルチプレクサ1704は、保持バッファ1702a〜1702b内に結合応答が全然存在しない場合に、情報フレームの結合応答フィールド710または810内の第1のバス1705上に選択およびランチするために、応答ロジック122によりノードだけのブロードキャスト動作の結合応答が提示される第3の入力を有する。第1のマルチプレクサ1704は、いつでも、リモート・ハブ100から受信した全システム・ブロードキャスト動作に対する結合応答に、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答に対するよりも高い優先権を与えるので、応答ロジック122は、ある動作条件の場合には、第1のマルチプレクサ1704がそれが提示する結合応答を選択するために、かなりの時間待機しなければならない場合がある。それ故、最悪の場合には、応答ロジック122は、所与の処理装置100が、任意の時点でフライト中に有することができるノードだけのブロードキャスト動作の最大数を決定するNMタグFIFOキュー924b2内のエントリの数に等しいいくつかの結合応答および部分応答のペアをキュー内に入れることができなければならない。結合応答がかなりの時間遅延しても、マスタ300およびスヌーパ304による結合応答の観察は、同じ長さの時間だけ遅延する。それ故、結合応答の遅延ランチは、上記タイミング制限に違反する恐れはない。何故なら、ウィニング・マスタ300による結合応答の観察と所有スヌーパ304による結合応答の観察との間の時間は、それにより短縮しないからである。
第1のバス1705は、アウトバウンドX、YおよびZリンクのそれぞれおよびノード・マスタ/リモート・ハブ(NM/RH)バッファ1706と結合している。ノードだけのブロードキャスト動作の場合には、NM/RHバッファ1706は、このノード・マスタ100のところで応答ロジック122が提供する結合応答および蓄積した部分応答(すなわち、宛先タグ)をバッファする。
インバウンドの第1の層のX、YおよびZリンクは、それぞれ各リモート・リーフ(RL)バッファ1714a〜1714cと結合している。NM/RHバッファ1706およびRLバッファ1714a〜1714cの出力は、第2のマルチプレクサ1720の4つの入力を形成する。第2のマルチプレクサ1720は、全システムのブロードキャスト動作の場合には、このローカル・ハブ100のところで応答ロジック122が提供する結合応答および蓄積した部分応答(すなわち、宛先タグ)をバッファするローカル・ハブ(LH)保持バッファ1710の出力と結合している追加の第5の入力を有する。第2のマルチプレクサ1720の出力は、要求FIFOキュー924およびアウトバウンドの第2の層のリンクが結合している第2のバス1722上で結合応答を駆動する。図に示すように、要求FIFOキュー924は、さらに、追加のチャネルを介して、LH保持バッファ1710またはNM/RHバッファ1706内にバッファされている蓄積した部分応答(すなわち、宛先タグ)を受信するために結合している。マスタ300およびスヌーパ304は、さらに要求FIFOキュー924と結合している。要求FIFOキュー924と接続しているので、スヌーパ304は、結合応答を観察することができ、関連するマスタ300は、もしある場合には、結合応答および宛先タグを受信することができる。
上記ウィンドウ拡張部312bがなくても、ほぼ同時にマスタ300およびスヌーパ304により結合応答を観察すると、ある動作シナリオの場合には、ウィニング・マスタ300からスヌーパ304n(すなわち、C_lat(WM_S))への結合応答待ち時間に関連するタイミング制約期間を、タイミング制約に違反にしてゼロに近づけることができる。しかし、ウィンドウ拡張部312bは、ほぼ第1の層のリンク送信待ち時間の持続時間を有しているので、マスタ300およびスヌーパ304により結合応答をほぼ同時に観察しても、上記タイミング制約を満足させることができる。
ここで図34〜図36を参照すると、これらの図は、本発明の例示としての実施形態によるローカル・ハブ(またはノード・マスタ)、リモート・ハブ(またはノード・マスタ)、およびリモート・リーフ(またはノード・リーフ)のところでの例示としての結合応答フェーズの処理をそれぞれ示すハイレベル論理フローチャートである。ここで図34についてより詳細に説明すると、ローカル・ハブ(またはノード・マスタ)100のところでの結合応答フェーズの処理はブロック1800から開始し、次に、要求のタイプおよび蓄積した部分応答に基づいて動作に対する結合応答を発生する応答ロジック122を示すブロック1802に進む。ブロック1803〜1805に示すように、結合応答710または810内の範囲インジケータ730または830が、動作がノードだけのブロードキャスト動作であることを示している場合には、ノード・マスタ100のところでの結合応答フェーズ処理は、図35のブロック1863のところで続行される。しかし、範囲インジケータ730または830が動作が全システム・ブロードキャスト動作であることを示している場合には、リモート・ハブ100の応答ロジック122は、ブロック1804のところに示すように、結合応答および蓄積した部分応答をLH保持バッファ1710内に収容する。OR演算による部分応答の蓄積のために、書込みタイプの要求の場合には、蓄積した部分応答は、付随の宛先タグ・フィールド724内に有効宛先タグが存在することを意味する「1」に設定された有効フィールド722を含む。他のタイプの要求の場合には、蓄積した部分応答のビット0は、このような宛先タグを含んでいないことを示すために「0」に設定される。
ブロック1844のところに示すように、第2のマルチプレクサ1720は、選択した第2の層のリンク情報割当てとタイム・スライス整合していて、アドレス保有期間がアウトバウンドの第2の層のリンク情報割当て内の結合応答に対して使用できる場合だけ、ランチ(launch)のためにLH保持バッファ1710から結合応答および蓄積した部分応答を選択する。それ故、例えば、第2のマルチプレクサ1720は、図13の実施形態のサイクル1または3、または図16の実施形態のサイクル1の間だけ結合応答および蓄積した部分応答をLH保持バッファ1710から出力する。ブロック1844において「いいえ」の判断が行われた場合には、LH保持バッファ1710内の結合応答のランチは、ブロック1846に示すように、アドレス保有期間を使用することができる以降のサイクルまで遅延する。一方、ブロック1844において「はい」の判断が行われた場合には、第2のマルチプレクサ1720は、優先的に第2のバス1722上へのランチおよびアウトバウンドの第2の層のリンク上の以降の送信のために、その他の入力よりもLH保持バッファ1710内の結合応答を選択する。
また、第2のマルチプレクサ1720の他のポート(例えば、RH、RLX、RLY、およびRLZ)は、LH保持バッファ1710と一緒に、第2のバス1722の最大帯域幅が、最大到着レートに遅れないために、アウトバウンドの第2の層のリンクの帯域幅の10/8(図13の実施形態を仮定した場合には)、または5/6(図16の実施形態を仮定した場合には)でなければならないことを意味する要求を提示することができることに留意されたい。また、LH保持バッファ1710内にバッファしている結合応答だけが、アウトバウンドの第2の層のリンク上で送信され、リンク情報割当て内のアドレス保有期間との整合が要求されることを観察されたい。第2のマルチプレクサ1720の発行に競合するすべての他の結合応答は、アウトバウンドの第2の層のリンクではなくローカル・マスタ300、スヌーパ304およびその各FIFOキューのみを目標としているので、このような結合応答を情報フレームの残りのサイクル中に発行することができる。それ故、第2のマルチプレクサ1720が使用する特定のアービトレーション・スキームが何であれ、第2のマルチプレクサ1720に同時に提示されるすべての結合応答は、1つの情報フレームの待ち時間内に送信されることが保証される。
第2のバス1722上での結合応答の発行の後で、プロセスは2つに分岐し、ブロック1848および1852のそれぞれに進む。ブロック1848は、第2のバス1722上にランチした結合応答のリモート・ハブ100への送信のためのアウトバウンドの第2の層のリンクへの経路指定を示す。その後で、プロセスはページ・コネクタ1850を通して、リモート・ハブ100のところでの結合応答処理の例示としての方法を示す図36に進む。
ここでブロック1852について説明すると、第2のバス1722上で発行された結合応答も、テール・ポインタ1102aにより識別されるその内部の最も古いエントリからマスタ・タグを入手するために、LHタグFIFOキュー924aへの問い合わせをおこなうために使用される。その後で、LHタグFIFOキュー924aは、動作に割り当てられたエントリの割当てを解除し、テール・ポインタ1102a、終了保有期間1302を進める(ブロック1854)。ブロック1854の後で、プロセスは2つに分岐し、ブロック1810および1856のそれぞれに進む。ブロック1810のところで、LHタグFIFOキュー924aに関連する図示していないロジックが、マスタ・タグが、結合応答に関連する要求を開始したマスタ300が、このローカル・ハブ100内に常駐していることを表示したかどうかを判定する。常駐していると表示しなかった場合には、この経路内の処理はブロック1816のところで終了する。しかし、マスタ・タグが、発呼マスタ300が現在のローカル・ハブ100内に常駐していると表示した場合には、LHタグFIFOキュー924aは、マスタ・タグ、結合応答および蓄積した部分応答をマスタ・タグが識別した発呼マスタ300に経路指定する(ブロック1812)。結合応答およびマスタ・タグを受信した場合には、発呼マスタ300は結合応答を処理し、対応する要求が書込みタイプの要求であった場合には、蓄積した部分応答を処理する(ブロック1814)。
マスタ300は、各マスタ300のところで例示としての結合応答資格付与ロジック2008により、結合応答がその要求のうちの1つに対する結合応答であることを確認するために、結合応答に資格を与えることができる。図39に示すように、マスタ300は、自身に割り当てられたマスタ・タグ2006のコピーを保持する。マスタ300が結合応答2014を受信した場合には、結合応答2014は 図38に示す動作タグ2000を伴い、それぞれ処理ノード202を識別するノードID2002、チップID2004、およびマスタ・タグ2006、プロセッサ100および動作を開始する特定のマスタ300を含む。
結合応答2014が付随の動作タグを受信した場合には、マスタ300は、マスタのマスタ・タグ2006を、結合応答2014と一緒に受信した動作タグ2000の対応するマスタ・タグ2006と比較するためのコンパレータ2010により、結合応答2014がその要求のうちの1つに対するものであるかどうかを判定する。コンパレータ2010の出力は、その他の入力としてマスタCResp有効信号を有するANDゲート2012によりさらに資格が与えられる。コンパレータ2010が一致を示し、マスタCResp有効信号がアサートされた場合には、ANDゲート2012はその出力をアサートし、マスタ300が受信した結合応答2014が、マスタ300の未解決の要求へのシステム応答であることを示す。マスタ300が結合応答2014がその要求のうちの1つに対するものであると判定した場合には、マスタ300は適当な処理を行う。
例えば、結合応答が「成功」を示していて、対応する要求が読取りタイプの要求(例えば、読取り、DClaimまたはRWITM要求)である場合には、発呼マスタ300は、要求したメモリ・ブロックを受信するために更新または準備を行うことができる。この場合、蓄積した部分応答は破棄される。結合応答が「成功」を示していて、対応する要求が書込みタイプの要求(例えば、キャストアウト、書込み、または部分書込み要求)である場合には、発呼マスタ300は、蓄積した部分応答から宛先タグ・フィールド724を抽出し、その内容をその宛先に動作の以降のデータ・フェーズを経路指定するために使用したデータ・タグ714または814として使用する。「成功」結合応答が、発呼マスタ300のHPC状態の許可を示すか、または意味している場合には、発呼マスタ300は、さらに、参照番号313および1314のところに示すように、メモリ・ブロックのその所有権の保護を開始する。しかし、ブロック1814のところで受信した結合応答が、「再試行」のような他の結果を示している場合には、発呼マスタ300に、おそらく異なる範囲(例えば、ローカルでなくグローバル)で要求の再発行を要求することができる。その後で、プロセスはブロック1816のところで終了する。
ここでブロック1856について説明すると、LHタグFIFOキュー924aも、ローカル・ハブ100内のスヌーパ304に、結合応答、範囲インジケータ、および関連するチケット番号(すなわち、キュー・エントリ識別子)を経路指定する。チケット番号自身が関連する要求FIFOキュー924を示していない場合には、チケット番号が属する要求FIFOキュー924の表示(すなわち、結合応答が横断する経路を示すルート表示)も、スヌーパ304に送られる。結合応答および関連する情報を受信した場合には、スヌーパ304は、結合応答を処理し、それに応じて必要なすべての動作を行う(ブロック1857)。
ここで図40を参照すると、この図は、各スヌーパ304のところの例示としての結合応答資格付与ロジック2018の例示としての実施形態である。図に示すように、スヌーパ304は、それぞれがスヌーパ304が観察している要求を記述している情報を保持している1つまたは複数の要求バッファ2020を有する。要求バッファ2020内の情報は、要求の動作タグ2000からのノードID2002、チップID2004およびマスタ・タグ2006、要求FIFOキュー924のうちの1つからの要求に割り当てられたチケット番号2022、および(例えば、範囲インジケータ730または830の設定により表示した)要求の範囲を示す範囲インジケータ2024を含む。
要求に割り当てられたチケット番号自身が、それが関連する要求FIFOキュー924を一意に識別しない場合には、異なる要求FIFOキュー924に割り当てられたチケット番号間でのエイリアシングを除去するために、ある種の機構が実施される。例えば、チケット番号が割り当てられる要求FIFOキュー924の別の表示を要求バッファ2020内にバッファすることができる。別の方法としては、図40に示すように、ルート・ロジック2034を実施することもできる。
図に示すように、ルート・ロジック2034は、入力として、結合応答2014のチケット番号が属する要求FIFOキュー924の表示、およびスヌーパ304のノードIDを受信する。これらの入力に基づいて、ルート・ロジック2034は、全システム範囲の要求の要求マスタ300のノードIDを判定する。(ノードだけの範囲の動作は、スヌーパ304として同じノード内で発呼することがわかっている。)例えば、さらに図2を参照すると、処理ノード202b0の処理装置100d内のスヌーパ304が、そのRL[A,Z]仮想FIFOキュー924e0に関連するチケット番号と一緒に、全システム範囲の動作に対する結合応答2014を受信した場合には、ルート・ロジック2034は、動作の要求しているマスタ300が、AおよびZ通信リンクの組合せにより処理ノード202b0の処理装置100dと結合している処理ノード202a0内に存在するにちがいないと判定する。要求FIFOキュー表示およびスヌーパ・ノードIDからルート・ロジック2034が判定したマスタ・ノードIDは、必要な場合には、異なる要求FIFOキュー924に属するチケット番号を明確にするために使用することができる。
図40にさらに示すように、応答資格付与ロジック2018は、さらに、ルート・ロジック2034が決定したマスタ・ノードID、結合応答チケット番号、および結合応答範囲インジケータを、要求バッファ2020の対応するフィールドと比較するためのコンパレータ2030を含む。コンパレータ2030の出力は、その他の入力としてスヌーパCResp有効信号を有するANDゲート2032によりさらに資格が与えられる。コンパレータ2030が一致を示し、スヌーパCResp有効信号がアサートされた場合には、ANDゲート2032はその出力をアサートし、スヌーパ304が受信した結合応答2014が、情報が要求バッファ2020内にバッファされる要求に対するシステム応答であることを示す。次に、スヌーパ304は、結合応答2014により何かが表示されている場合には、行動を行う。
例えば、スヌーパ304は、要求の発呼マスタ300に、要求したメモリ・ブロックの出所を明確にし、要求したメモリ・ブロック等のキャッシュしたコピーを無効にすることができる。結合応答がスヌーパ304が要求しているマスタ300へメモリ・ブロックの所有権を移すべきであるという表示を含む場合には、スヌーパ304は、その保護ウィンドウ312aの末尾に、図のトポロジの場合には、好ましくは、第1の層のリンク上の1つのチップ・ホップの待ち時間にほぼ等しい持続時間を有するプログラム可能な長さのウィンドウ拡張部312bを添付する(ブロック1858)。もちろん、他のデータ処理システム・トポロジおよび相互接続ロジック120の異なる実施態様の場合には、プログラム可能なウィンドウ拡張部312bは、リンクの待ち時間の違い(例えば、異なる処理ノード202を結合している異なる長さのケーブル)、トポロジ的または物理的制約、回路設計制約、または種々の動作フェーズの限定された待ち時間の大きな変動を補償するために、他の長さに有利に設定することができる。その後で、ローカル・ハブ100のところでの結合応答フェーズの処理はブロック1859のところで終了する。
ここで図35を参照すると、この図は、本発明によるリモート・ハブ(またはノード・マスタ)100のところでの結合応答フェーズの処理の例示としての方法のハイレベル論理フローチャートである。図に示すように、リモート・ハブ100のところでの結合応答フェーズの処理の場合には、プロセスは、そのインバウンドAまたはBリンクの一方上でリモート・ハブ100のところで結合応答を受信した場合に、ページ・コネクタ1860から開始する。次に、ブロック1862に示すように、結合応答が保持バッファ1702a〜1702bの関連する1つのバッファ内にバッファされる。次に、バッファされた結合応答は、ブロック1864および1865に示す両方の条件が満たされるや否や、第1のバス1705上で第1のマルチプレクサ1704により送信される。より詳細に説明すると、アドレス保有期間を第1の層のリンク情報割当て内で使用することができなければならないし(ブロック1864)、第1のマルチプレクサ1704により実施した公平な割当てポリシーは、結合応答がバッファされる保持バッファ1702a、1702bを選択しなければならない(ブロック1865)。
ブロック1864に示すように、これらの条件のいずれかが満たされなかった場合、第1のバス1705上に第1のマルチプレクサ1704による結合応答のランチは、次のアドレス保有期間まで遅延する。しかし、ブロック1864および1865に示す条件が両方とも満たされた場合には、プロセスはブロック1865から、結合応答フィールド710または810内のアウトバウンドX、YおよびZリンクおよびNM/RH保持バッファ1706へ第1のバス1705により結合応答をブロードキャストしている第1のマルチプレクサ1704を示すブロック1868へ進む。ブロック1863および1867〜ブロック1868を含む経路の接続で示すように、ノードだけのブロードキャスト動作の場合には、第1のマルチプレクサ1704は、保持バッファ1702a〜1702bにより競合する結合応答が提示されていない場合だけ、アウトバウンドX、YおよびZリンクおよびNM/RH保持バッファ1706に経路指定するために、第1のバス1705上に応答ロジック122が提示した結合応答を発行する。インバウンドの第2の層のリンクのうちの1つを介してリモート・ハブ100から全システム・ブロードキャスト動作に対して何らかの競合結合応答を受信した場合には、ブロック1867に示すように、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答は遅延する。最後に、第1のマルチプレクサ1704が、ノードだけのブロードキャスト動作に対するローカル的に発生した結合応答を選択した場合には、応答ロジック122は、関連する蓄積した部分応答をNM/RH保持バッファ1706内に直接収容する。
ブロック1868の後で、プロセスは2つに分岐する。第1の経路は、ページ・コネクタ1870を通って、リモート・リーフ(またはノード・リーフ)100のところでの結合応答フェーズの処理の例示としての方法を示す図36に進む。ブロック1868からの第2の経路は、その入力のところに提示される結合応答のうちのどれが、第2のバス1722上に出力するのかを決定する第2のマルチプレクサ1720を示すブロック1874に進む。すでに説明したように、第2のマルチプレクサ1720は、リモート・ハブ結合応答よりも高い優先権をローカル・ハブ結合応答に与え、リモート・ハブ結合応答は、リモート・リーフ・バッファ1714a〜1714c内にバッファされている結合応答よりも高い優先権を有する。それ故、ローカル・ハブ結合応答がLH保持バッファ1710により選択のために提示された場合には、ブロック1876に示すように、リモート・ハブ・バッファ1706内にバッファされている結合要求は遅延する。しかし、LH保持バッファ1710により結合応答が提示されなかった場合には、第2のマルチプレクサ1720は、第2のバス1722上にNM/RHバッファ1706から結合応答を発行する。
第2のバス1722上で結合応答を検出した場合には、結合応答を受信した第2の層のリンクに関連する仮想FIFOキュー924b0および924b1のうちの特定の1つのキューのテール・ポインタ1102(またはノードだけのブロードキャスト動作の場合には、物理NMタグFIFOキュー924b2)が、ブロック1878に示すように、要求に割り当てられたチケット番号を決定するためにアクセスされる。NMタグFIFOキュー924b2がアクセスされると、マスタ・タグも、アクセスしたキュー・エントリから読み出される。次に、テール・ポインタ1102は、仮想または物理キュー・エントリ、終了保有期間1306または1320の割当てを解除するために前進する(ブロック1880)。次に、プロセスは2つに分岐し、ブロック1882および1881のそれぞれに進む。ブロック1882は、(範囲インジケータと一緒に)結合応答を経路指定するタグFIFOキュー924bのうちの関連する1つのキュー、チケット番号、および必要な場合には、リモート・ハブ(またはノード・マスタ)100内のスヌーパ304への要求FIFOキュー表示を示す。結合応答および関連する情報を受信した場合、すでに説明したように、スヌーパ304は、結合応答を処理し(ブロック1884)、すべての必要な動作を行う。動作が全システム・ブロードキャスト動作であり、結合応答がスヌーパ304はメモリ・ブロックのコヒーレンシ所有権を要求しているマスタ300に移転すべきであるという表示を含む場合には、ブロック1885に示すように、スヌーパ304は、ウィンドウ拡張部312bをその保護ウィンドウ312aに添付する。その後で、リモート・ハブ100のところの結合応答フェーズの処理は、ブロック1886で終了する。
ここでブロック1881について説明すると、結合応答フィールド710または810内の範囲インジケータ730または830が、動作がノードだけのブロードキャスト動作ではなく、全システム・ブロードキャスト動作であることを示している場合には、リモート・ハブ100のところでこれ以上処理は行われず、プロセスはブロック1886のところで終了する。しかし、範囲インジケータ730または830が、動作がノードだけのブロードキャスト動作であることを示している場合には、プロセスは、マスタ・タグ、結合応答および蓄積した部分応答を、マスタ・タグが識別する発呼マスタ300に経路指定するNMタグFIFOキュー924b2を示すブロック1883に進む。結合応答およびマスタ・タグを受信した場合には、発呼マスタ300は、図39のところで説明したように、結合応答に資格を与える。結合応答が発呼マスタ300の要求に属するものとしての資格を与えられた場合には、発呼マスタ300は結合応答を処理し、対応する要求が書込みタイプの要求であった場合には、蓄積した部分応答を処理する(ブロック1887)。
例えば、結合応答が「成功」を示していて、対応する要求が読取りタイプの要求(例えば、読取り、DClaimまたはRWITM要求)であった場合には、発呼マスタ300は、要求したメモリ・ブロックを受信するために更新または準備を行うことができる。この場合、蓄積した部分応答は破棄される。結合応答が「成功」を示していて、対応する要求が書込みタイプの要求(例えば、キャストアウト、書込みまたは部分書込み要求)である場合には、発呼マスタ300は、蓄積した部分応答から宛先タグ・フィールド724を抽出し、その内容をその宛先に動作の以降のデータ・フェーズを経路指定するために使用したデータ・タグ714または814として使用する。「成功」結合応答が、発呼マスタ300のHPC状態の許可を示すか、意味する場合には、発呼マスタ300は、さらに、参照番号313および1314のところに示すように、メモリ・ブロックのその所有権の保護を開始する。しかし、ブロック1814のところで受信した結合応答が、「再試行」のような他の結果を示している場合には、発呼マスタ300に要求の再発行を要求することができる。その後で、プロセスはブロック1886のところで終了する。
ここで図36を参照すると、この図は、本発明によるリモート(またはノード)リーフ100のところでの結合応答フェーズの処理の例示としての方法のハイレベル論理フローチャートである。図に示すように、プロセスはそのインバウンドX、YおよびZリンクのうちの1つ上のリモート(またはノード)リーフ100のところで結合応答を受信した場合に、ページ・コネクタ1888のところから開始する。ブロック1890に示すように、結合応答は、NL/RL保持バッファ1714a〜1714cのうちの1つ内にラッチされる。次に、ブロック1891のところに示すように、結合応答は、その入力に提示された他の結合応答と一緒に第2のマルチプレクサ1720により評価される。すでに説明したように、第2のマルチプレクサ1720は、リモート・ハブ結合応答よりも高い優先権をローカル・ハブ結合応答に与え、リモート・ハブ結合応答は、NL/RL保持バッファ1714a〜1714c内にバッファされている結合応答よりも高い優先権を有する。それ故、ローカル・ハブまたはリモート・ハブ結合応答が選択のために提示された場合には、ブロック1892に示すように、NL/RL保持バッファ1714内にバッファされている結合応答は遅延する。しかし、第2のマルチプレクサ1720により高い優先権の結合応答が提示されなかった場合には、第2のマルチプレクサ920は、第2のバス1722上にNL/RL保持バッファ1714から結合応答を発行する。
第2のバス1722上で結合応答を検出した場合には、動作範囲および結合応答を受信した経路に関連する仮想FIFOキュー924c0〜924c2、924d0〜924d2、および924e0〜924e2のうちの特定の1つのキューのテール・ポインタ1102が、ブロック1893に示すように、関連する要求のチケット番号を決定するためにアクセスされる。すなわち、結合応答フィールド710または810内の範囲インジケータ730または830は、要求がノードだけの範囲であるか、または全システムの範囲であるかを判定するために使用される。ノードだけのブロードキャスト要求の場合には、結合応答を受信したインバウンドの第1の層のリンクに関連するNL仮想FIFOキュー924c2、924d2および924e2のうちの特定の1つのキューのテール・ポインタ1102が、チケット番号を決定するためにアクセスされる。全システム・ブロードキャスト要求の場合には、結合応答を受信したインバウンドの第1および第2の層のリンクの組合せに対応するRL仮想FIFOキュー924c0〜924c1、924d0〜924d1および924e0〜924e1のうちの特定の1つのキューのテール・ポインタ1102が、チケット番号を決定するためにアクセスされる。
関連する仮想FIFOキュー924が、動作のために適当なエントリを識別すると、仮想FIFOキュー924のテール・ポインタ1102は、エントリ、終了保有期間1310または1324の割当てを解除するために前進する(ブロック1894)。結合応答(範囲インジケータを含む)、チケット番号、および必要な場合には、要求FIFO表示が、ブロック1895に示すように、リモート(またはノード)リーフ100内のスヌーパ304にさらに経路指定される。結合応答および関連する情報を受信した場合には、すでに説明したように、スヌーパ304は、結合応答を処理し(ブロック1896)、すべての必要な動作を行う。動作がノードだけの動作でなく、また結合応答がスヌーパ304はメモリ・ブロックのコヒーレンシ所有権を要求しているマスタ300に移転すべきであるという表示を含む場合には、すでに説明したように、またブロック1897に示すように、スヌーパ304は、ウィンドウ拡張部312bをその保護ウィンドウ312a(および図22の保護ウィンドウ1312)の末尾に添付する。その後で、リモート・リーフ100のところの結合応答フェーズの処理は、ブロック1898で終了する。
IX.データ・フェーズの構造および動作
データ・ロジック121dおよびデータ発送のその処理は、種々の方法で実施することができる。1つの好ましい実施形態の場合には、データ・ロジック121dおよびその動作は、前記米国特許公開第20060179252号及び米国特許公開第20060187939号に詳細に記載してある方法で実施することができる。
X.結論
今まで説明してきたように、本発明は、改良形処理装置、データ処理システムおよびデータ処理システムのための相互接続ファブリックを提供する。本明細書に開示する本発明のデータ処理システムのトポロジは、システム・スケールで相互接続帯域幅を増大する。さらに、本明細書に開示するトポロジを使用するデータ処理システムは、個々の処理ノードの接続、切離しまたは修理による結果としてのデータ処理システム内の処理装置間の通信を中断しないで、ホット・アップグレードすることもできるし(すなわち、動作中に処理ノードを追加することもできるし)、ダウングレードすることもできるし(すなわち、処理ノードを除去することもできるし)、または修理することもできる。
本発明は、また、種々の範囲(例えば、ノードだけのブロードキャスト・モード、全システム・ブロードキャスト範囲)の動作の同時の流れを有利にサポートする。ご理解いただけると思うが、全システム範囲以下の動作に対するサポートは、相互接続ファブリック上の帯域幅を有利に保存し、システム全体の性能を向上させる。本発明は、また少なくとも2つの他の処理装置間の通信経路内に介在する中間処理装置のキュー要件を緩和する改良形動作追跡機構を提供する。中間処理装置のところの動作追跡機構は、その処理装置内でマスタが開始した要求のマスタ・タグを格納するための物理キューを含む。さらに、動作追跡機構は、他の処理装置内でマスタが開始し、その処理装置による上記各第2の要求の観察の順序を示すチケット番号を有するその処理装置のところで観察した各要求に関連するチケット発行機構を含む。
好ましい実施形態を参照しながら本発明を詳細に図示し、説明してきたが、当業者であれば本発明の精神および範囲から逸脱することなしに、形状および詳細を種々に変更することができることを理解することができるだろう。例えば、本発明は、動作に関連するタグおよび部分応答の順序を決めるためにFIFOキューを使用する好ましい実施形態を開示しているが、当業者であれば、上記方法で動作の種々のタグおよび部分応答間の順序を維持するために他の順序のデータ構造を使用することができることを理解することができるだろう。さらに、本発明の好ましい実施形態は、一方向通信リンクを使用しているが、当業者であれば、上記説明により二方向通信リンクを別の方法として使用することができることを理解することができるだろう。