JP2004506986A - マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 - Google Patents

Abstract

コンピュータシステムは、コンピュータシステム内のコヒーレントファブリックおよびノンコヒーレントファブリックを通してポステッドリクエストおよびノンポステッドリクエストをルーティングするために、ノンポステッドコマンドバーチャルチャネルとは別のポステッドコマンドバーチャルチャネルを提供する。コンピュータシステムはまた、別個のリソースをバーチャルチャネルの各々に割振り、したがって、ポステッドリクエストが、同じソースからの他のリクエストとともに順序付けされないことが可能となる。このような実現例によって、ポステッドライトリクエストが前のポステッドリクエストと順序付けされ得ないＩ／Ｏシステム（たとえば、周辺コンポーネント相互接続バス）との互換性をコンピュータシステムが維持することが可能となる。

Description

【０００１】
【技術分野】
この発明はコンピュータシステムの分野に関し、より特定的には、マルチプロセッサコンピュータシステムにおけるノード間のデータルーティングに関する。
【０００２】
【発明の背景】
一般的に、パーソナルコンピュータ（ＰＣ）および他のタイプのコンピュータシステムは、メモリにアクセスするための共有バスシステムの付近に設計されてきた。１つ以上のプロセッサおよび１つ以上の入力／出力（Ｉ／Ｏ）デバイスは、共有バスを介してメモリに結合される。Ｉ／Ｏデバイスは、共有バスとＩ／Ｏデバイスとの間の情報の転送を管理するＩ／Ｏブリッジを介して共有バスに結合されてもよく、一方、プロセッサは、典型的に、共有バスに直接に結合されるかまたは、キャッシュ階層を介して共有バスに結合される。
【０００３】
残念ながら、共有バスシステムにはいくつか欠点がある。たとえば、共有バスに取付けられる複数のデバイスは、バス上の信号を駆動するデバイスに対し、比較的大きな電気キャパシタンスを与える。さらに、共有バス上の複数の取付け点は高い信号周波数での信号反射を生じ、これは信号の完全性を低減してしまう。その結果、信号の完全性を受容可能なレベルに維持するため、バス上の信号周波数を比較的低く保つのが一般的である。比較的低い信号周波数は信号帯域幅を低減し、バスに取付けられるデバイスの性能を限定してしまう。
【０００４】
より多数のデバイスへのスケーラビリティのなさが共有バスシステムのもう１つの欠点である。共有バスの利用可能な帯域幅は実質的に固定されている（さらなるデバイスを加えることでバス上の信号周波数が低減されれば、小さくなり得る）。（直接または間接に）バスに取付けられるデバイスの帯域幅必要量が一旦バスの利用可能帯域幅を超えると、バスへのアクセスを試みたときにデバイスがしばしばストールし、共有バスを含むコンピュータシステムの全体的な性能が低くなってしまう見込みが非常に高くなる。
【０００５】
一方、分散メモリシステムには上記欠点の多くがない。分散メモリシステムを備えたコンピュータシステムは複数のノードを含み、そのうち２つ以上は異なるメモリに結合される。ノードは任意の好適な配線によって互いに結合される。たとえば、各ノードは、専用線によって互いのノードに結合されてもよい。これに代えて、各ノードは固定数の他のノードに接続されてもよく、トランザクションは、第１のノードから、１つ以上の中間ノードを介して第１のノードが直接には接続されない第２のノードへルーティングされてもよい。コンピュータシステムのメモリアドレス空間は、各ノードにおいてメモリにわたって割当てられる。
【０００６】
一般的に、「ノード」は、相互接続されるとトランザクションに加わることができるデバイスである。たとえば、相互接続はパケットベースであってもよく、トランザクションの一部としてパケットを送受信するようにノードを構成してもよい。一般的に、トランザクションとは一連のパケットである。「リクエスタ」または「ソース」ノードは、リクエストパケットを発行することにより、「ターゲット」ノードに向けられるトランザクションを開始する。トランザクションの一部である各パケットは、２つのノード間で個々のパケットの「デスティネーション」として指定された受信ノードに伝えられる。パケットが最終的にターゲットノードに達すると、ターゲットノードはパケットが運搬した情報を受入れ、その情報を内部で処理する。これに代えて、ソースノードとターゲットノードとの間の通信経路上に位置するノードは、リクエスタノードからターゲットノードにパケットを中継し得る。
【０００７】
トランザクションの結果、オリジナルのリクエストパケットだけでなく、各々が特定のデスティネーションに向けられた、応答、プローブおよびブロードキャストなどの他のタイプのパケットも発行され得る。たとえば、オリジナルのリクエストパケットを受取ると、ターゲットノードは、処理システム中の他のノードにブロードキャストまたはプローブパケットを発行し得る。次に、これらのノードが応答を生成し得、これらがターゲットノードまたはリクエスタノードのいずれかに向けられ得る。ターゲットノードに向けられた場合、ターゲットノードは、リクエスタノードに応答を戻すことによって応答し得る。
【０００８】
分散メモリシステムは、共有バスシステムにおける課題とは異なる設計上の課題を呈する。たとえば、共有バスシステムは、バスアービトレーションによってトランザクションの開始を統制する。したがって、公平なアービトレーションアルゴリズムにより、各バスに加わっているノードにトランザクションを開始する機会が与えられる。バス上でのトランザクションの順序は、（たとえば、コヒーレンシの目的のために）トランザクションが行なわれる順序を表わし得る。一方、分散システムでは、ノードは並行してトランザクションを開始し、相互接続を用いてトランザクションを他のノードに送信し得る。これらのトランザクションは、それらの間で論理的競合（たとえば、同じアドレスを含むトランザクションに対するコヒーレンシ競合）を有することがあり、かつ、リソース競合に遭遇することがある（たとえば、さまざまなノードでバッファ空間が利用不可能なことがある）。これは、トランザクションの開始を統制するための中央メカニズムを設けていないからである。したがって、情報がノード間をスムーズに伝播し続けることと、（トランザクション間での競合のためにトランザクションが完了しない）デッドロック状態を回避することとを確実にするのがより困難である。
【０００９】
たとえば、「ポストされた（ｐｏｓｔｅｄ）」書込トランザクションと関連のパケットが、ポストされた書込トランザクションと関連のない他のトラフィックを通すことを許されない場合、周辺機器相互接続（ＰＣＩ）Ｉ／Ｏシステムなどの公知のＩ／Ｏシステムにおいて、あるデッドロック状態が起こり得る。一般的に、ポストされた書込トランザクションは、リクエスタが書込リクエストおよび対応のデータを（たとえばソースインターフェイスを介して）送信したときに、リクエスタによって完了したとみなされるものであり、したがって、リクエスタで実質的に完了する。リクエスタは、ポストされた書込トランザクションをターゲットがいつ実際に完了したかに直接に気づかないため、ポストされた動作に対する順序付けのサポートをハードウェアにおいてより多く与える必要がある。したがって、リクエスタは、ポストされた書込トランザクションのパケットまたは複数のパケットがターゲットに移動する間に、さらなるリクエストを発行し得る。ただし、これは、当初のポストされたトランザクションが完了した後にそのようなさらなるリクエストが完了すると仮定した場合である。この仮定をサポートするには、十分なハードウェアが利用可能でなければならない。
【００１０】
これに対し、「ノンポステッド（ｎｏｎ−ｐｏｓｔｅｄ）」書込トランザクションは、ターゲット（たとえばターゲットインターフェイス）がノンポステッド書込トランザクションを完了するまでは、リクエスタによって完了したとみなされない。ターゲットは一般的に、ノンポステッド書込トランザクションが完了したときに、肯定応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をリクエスタに送信する。そのような肯定応答は相互接続帯域幅を消費し、リクエスタは肯定応答を受信しかつ勘案する（ａｃｃｏｕｎｔｅｄ ｆｏｒ）必要がある。たとえば、リクエスタが、次のトランザクションが発行される前に以前のトランザクションが完了したことを知る必要がある場合、ノンポステッド書込トランザクションが発行され得る。
【００１１】
分散メモリシステムを有するコンピュータシステムでは、他の保留中のメモリ動作に対して、Ｉ／Ｏノードから来ているメモリリクエスト（たとえば、読出および書込動作）を適切に順序付けてコンピュータシステム内のメモリコヒーレンシを保ち、Ｉ／Ｏシステムのいかなる順序付け要件も満たす必要があろう。たとえば、メモリ動作は、それらが生成された順に完了されてコンピュータシステム内のメモリコヒーレンシを保ちかつＩ／Ｏ順序付け要件を満たす必要があろう。したがって、ポストされたリクエストに対して別個の通信チャネルを設けるためのシステムおよび方法を実現するコンピュータシステムを有することが望ましい。そのようなシステムおよび方法は、（ハードウェアの観点で）装置を最小化して実現を容易にしながら、デッドロック状態を回避する。
【００１２】
【発明の開示】
バーチャルチャネルを用い、そのバーチャルチャネルに異なるリソースを割振るためのシステムおよび方法を実現するコンピュータシステムが提示される。より特定的には、コンピュータシステムは、コンピュータシステム内のコヒーレントファブリックおよびノンコヒーレントファブリックを介してリクエストをルーティングするため、ノンポステッドコマンドバーチャルチャネルとは別個のポステッドコマンドバーチャルチャネルを設ける。ポステッドライト（ｐｏｓｔｅｄ ｗｒｉｔｅ）はポステッドコマンドバーチャルチャネルに属し、その他のリクエストはノンポステッドコマンドバーチャルチャネルに属し得る。バーチャルチャネルはコンピュータシステム内に別個のリソースを設けるため、ポステッドライトは、同じソースからの他のリクエストと順序付けられないことが許され得る。有利には、コンピュータシステムは、ポステッドライトが以前のノンポステッドリクエストに対して順序付けられないことを必要とする、以前のＩ／Ｏシステム（たとえば、周辺機器相互接続バスまたはＰＣＩ）との互換性を維持し得、それにより、互換性がなければＩ／Ｏシステムで起こり得るあるデッドロックを回避する。有利には、ポステッドコマンドバーチャルチャネルを設けることにより、コンピュータシステムは所望の互換性を与えかつ、デッドロックのない動作を行ない得る。
【００１３】
概して述べると、コンピュータシステムで複数のノード間でパケットをルーティングするための方法が企図される。ポストされたリクエストパケットは、複数のノードのうち第１のノードで受信される。第１のノードは複数のパケットバッファを含み、その各々は、複数のバーチャルチャネルのうち異なるものに割当てられる。ポストされたリクエストパケットは、複数のパケットバッファの１つであるポステッドコマンドバッファに記憶される。ポステッドコマンドバッファは、複数のバーチャルチャネルの１つであるポステッドコマンドバーチャルチャネル中のパケット専用である。
【００１４】
さらに、第１のノードおよび第２のノードを含むコンピュータシステムが企図される。第１のノードは、ポストされたリクエストパケットを送信するように構成される。第２のノードは、ポストされたリクエストパケットを第１のノードから受信するように結合されて、ポステッドコマンドバッファを含む複数のパケットバッファを含む。複数のパケットバッファの各々は、ポステッドコマンドバッファが割当てられるポステッドコマンドバーチャルチャネルを含む複数のバーチャルチャネルの異なるものに割当てられる。第２のノードは、ポストされたリクエストパケットをポステッドコマンドバッファに記憶するように構成される。
【００１５】
この発明のその他の目的および利点は、添付の図面を参照し、以下の詳細な説明を読むと明らかになるであろう。
【００１６】
この発明は、さまざまな変形および代替的な形態が可能であるが、その特定の実施例が例示のみの目的のために図面に示され、本明細書に詳細に説明される。しかしながら、図面およびその詳細な説明は、開示される特定の形態にこの発明を限定することを意図するものではなく、反対に、添付の請求項が規定するような、この発明の精神および範囲内に入るすべての変形、均等物および代替物を含むことを意図することを理解されたい。
【００１７】
【発明を実行するためのモード】
システム概要
図１を参照して、コンピュータシステム１０の１つの実施例が示される。コンピュータシステム１０の他の実施例が可能でありかつ企図される。図１の実施例では、コンピュータシステム１０はいくつかの処理ノード１２Ａ、１２Ｂ、１２Ｃおよび１２Ｄを含むが、用いる処理ノードの数はこれより多くてもまたは少なくてもよい。各処理ノードは、各々それぞれの処理ノード１２Ａ−１２Ｄ内に含まれるメモリコントローラ１６Ａ−１６Ｄを介してそれぞれのメモリ１４Ａ−１４Ｄに結合される。コンピュータシステム１０のメモリアドレス空間は、システム１０が分散メモリシステムを有するようにメモリ１４Ａ−１４Ｄにわたって割当てられる。さらに、処理ノード１２Ａ−１２Ｄは、処理ノード１２Ａ−１２Ｄ間で通信するのに用いるインターフェイスロジックを含む。たとえば、処理ノード１２Ａは、処理ノード１２Ｂと通信するためのインターフェイスロジック１８Ａと、処理ノード１２Ｃと通信するためのインターフェイスロジック１８Ｂと、また別の処理ノード（図示せず）と通信するための第３のインターフェイスロジック１８Ｃとを含む。同様に、処理ノード１２Ｂはインターフェイスロジック１８Ｄ、１８Ｅ、１８Ｆを含み；処理ノード１２Ｃはインターフェイスロジック１８Ｇ、１８Ｈおよび１８Ｉを含み；処理ノード１２Ｄはインターフェイスロジック１８Ｊ、１８Ｋおよび１８Ｌを含む。処理ノード１２Ｄは、インターフェイスロジック１８Ｌを介してＩ／Ｏブリッジ２０と通信するように結合される。他の処理ノードは同じ態様で他のＩ／Ｏブリッジと通信し得る。Ｉ／Ｏブリッジ２０はＩ／Ｏバス２２に結合される。
【００１８】
処理ノード１２Ａ−１２Ｄは、プロセス間ノード通信のためにパケットベース２方向リンク２４を実現する。この実施例では、２方向リンクは１方向線の組として実現される（たとえば、線２４Ａを用いて処理ノード１２Ａから処理ノード１２Ｂへパケットを送信し、線２４Ｂを用いて処理ノード１２Ｂから処理ノード１２Ａにパケットを送信する）。図１に図示されるように、線２４Ｃ−２４Ｈの他の組を用いて他の処理ノード間でパケットを送信する。リンクはキャッシュコヒーレントな態様で動作して処理ノード（コヒーレントリンク）間で通信してもよくまたは、ノンコヒーレントな態様で動作して処理ノードとＩ／Ｏブリッジ（ノンコヒーレントリンク）との間で通信してもよい。さらに、Ｉ／Ｏデバイス間のデイジーチェーン構造としてノンコヒーレントリンクを実現してＩ／Ｏバス２２と置き換えてもよい。コヒーレントリンクを介した２つ以上のノードの相互接続を「コヒーレントファブリック」と称し得る。同様に、ノンコヒーレントリンクを介した２つ以上のノードの相互接続を「ノンコヒーレントファブリック」と称し得る。１つの処理ノードから別の処理ノードに送信すべきパケットは１つ以上の中間ノードを通り得ることに留意されたい。たとえば、処理ノード１２Ａによって処理ノード１２Ｄに送信されるパケットは、図１に示されるように、処理ノード１２Ｂまたは処理ノード１２Ｃのいずれかを通り得る。いずれの好適なルーティングアルゴリズムを用いてもよい。
【００１９】
メモリ１４Ａ−１４Ｄはいずれの好適なメモリデバイスを含んでもよい。たとえば、メモリ１４Ａ−１４Ｄは、１つ以上のＲＡＭＢＵＳ　ＤＲＡＭ（ＲＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭなどを含み得る。述べられたように、コンピュータシステム１０のアドレス空間はメモリ１４Ａ−１４Ｄにわたって割当てられる。各処理ノード１２Ａ−１２Ｄは、どのアドレスをどのメモリ１４Ａ−１４Ｄにマッピングし、したがってどの処理ノード１２Ａ−１２Ｄに向けて特定のアドレスに対するメモリリクエストをルーティングすべきかを判断するのに用いられるメモリマップを含み得る。１つの実施例では、コンピュータシステム１０内のアドレスのコヒーレンシ点は、アドレスに対応するバイトを記憶するメモリに結合された特定のメモリコントローラ１６Ａ−１６Ｄである。言い換えると、メモリコントローラ１６Ａ−１６Ｄは、対応のメモリ１４Ａ−１４Ｄへの各メモリアクセスがキャッシュコヒーレントな態様で起こるのを確実にする役割がある。メモリコントローラ１６Ａ−１６Ｄは、メモリ１４Ａ−１４Ｄにインターフェイスするための制御回路構成を含み得る。さらに、メモリコントローラ１６Ａ−１６Ｄは、メモリリクエストを待ち行列に入れるためにリクエスト待ち行列を含み得る。
【００２０】
一般的に、インターフェイスロジック１８Ａ−１８Ｌは、２方向リンクからパケットを受取りかつ、送信すべきパケットをリンク上でバッファするためのバッファを含み得る。コンピュータシステム１０は、パケットを送信するためのいかなる好適なフロー制御メカニズムを用いてもよい。たとえば、各ノード内のインターフェイスロジックは、通信リンクの他方端にある受信ノードのインターフェイスロジック内に各タイプのバッファの数のカウントを記憶し得る。パケットを記憶するための正しいタイプの空きバッファを受信ノードが有していない場合、送信ノードはパケットを送信しないであろう。（たとえば記憶されたパケットをルーティングすることにより）各バッファが受信ノード内で空いていれば、受信ノードは、バッファが空いていることを示すメッセージを送信ノードに送信する。そのようなメカニズムを「クーポンベース」システムと称し得る。
【００２１】
次に図２を参照して、処理ノード１２Ａおよび１２Ｂを図示するブロック図を示し、その間の２方向リンク２４の例示的な実施例を図示する。通信リンク２４の他の実施例が可能でありかつ企図される。図２の実施例では、２方向リンク２４は１方向線２４Ａおよび１方向線２４Ｂを含む。線２４Ａは、クロック信号線（ＣＬＫ）２４ＡＡ、制御信号線（ＣＴＬ）２４ＡＢおよびコマンド／アドレス／データバス（ＣＡＤ）２４ＡＣを含む。同様に、線２４Ｂは、クロック信号線２４ＢＡ、制御信号線２４ＢＢおよびコマンド／アドレス／データバス２４ＢＣを含む。
【００２２】
クロック線は、制御線およびコマンド／アドレス／データバスのサンプル点を示すクロック信号を送信する。１つの特定の実施例では、データ／制御ビットは、クロック信号の各エッジ（すなわち立上がりエッジおよび立下がりエッジ）で送信される。したがって、クロックサイクルごとに線１本当り２データビットが送信され得る。本明細書中では、線１本当り１ビットを送信するのに用いる時間の量を「ビット時間」と称する。上述の実施例は１クロックサイクル当り２ビット時間を含む。パケットは２ビット時間またはそれ以上にわたって送信され得る。コマンド／アドレス／データバスの幅に依存して、複数のクロック線を用いてもよい。たとえば、３２ビットコマンド／アドレス／データバスに対して４本のクロック線を用いてもよい。
【００２３】
制御線は、コマンド／アドレス／データバス上を送信されるデータが制御情報のビット時間であるのかまたはデータのビット時間であるのかを示す。制御線はアサートされて制御情報のビット時間を示し、デアサートされてデータのビット時間を示す。ある制御情報はデータが後に続いていることを示す。データは対応の制御情報のすぐ後に続いてもよい。１つの実施例では、他の制御情報がデータの送信に割込んでもよい。そのような割込は、データ送信の間に多数のビット時間にわたって制御線をアサートし、制御線がアサートされている間に制御情報のビット時間を送信することによって行なわれ得る。データに割込む制御情報は、データが後に続いていることを示さないであろう。さらに、１つの実施例では、制御線は制御情報の送信の間にデアサートされてストールビット時間を示し得る。制御線のその後の再アサートは、制御情報が継続していることを示し得る。
【００２４】
コマンド／アドレス／データバスは、データ／制御ビットを送信するための線の組を含む。１つの実施例では、コマンド／アドレス／データバスは８本、１６本または３２本の線を含み得る。各処理ノードまたはＩ／Ｏブリッジは、設計の選択に従って、サポートされる数の線のうちいずれのものを用いてもよい。他の実施例は、所望により、他のサイズのコマンド／アドレス／データバスをサポートし得る。
【００２５】
１つの実施例に従うと、コマンド／アドレス／データバス線およびクロック線で差分シグナリング（ｄｉｆｆｅｒｅｎｔｉａｌ ｓｉｇｎａｌｉｎｇ）を用い得る。これに代えて、線は、アクティブローデータ（すなわち、論理「１」が線上の低電圧として表わされ、論理「０」が高電圧として表わされる）またはアクティブハイデータ（論理「１」が線上の高電圧として表わされ、論理「０」が低電圧として表わされる）のいずれかを搬送してもよい。
【００２６】
コンピュータシステム１０内を送信されるパケットは、１つ以上の中間処理ノードを通り得る。たとえば、システム１０内を処理ノード１２Ａによって処理ノード１２Ｄに送信されるパケットは、処理ノード１２Ｂまたは処理ノード１２Ｃのいずれかを通り得る（図１を参照）。処理ノード１２Ａがコヒーレントパケットを処理ノード１２Ｂに送信する場合、処理ノード１２Ｂはパケットを受取り、次にそのパケットを処理ノード１２Ｄに転送し得る。一方、処理ノード１２Ａがコヒーレントパケットを処理ノード１２Ｃに送信する場合、処理ノード１２Ｃはパケットを受取り、次にそのパケットを処理ノード１２Ｄに転送し得る。システム１０内でいずれの好適なパケットルーティングアルゴリズムを用いてもよい。コンピュータシステム１０の他の実施例は、図１の実施例よりも多いまたは少ない数の処理ノード１２を含んでもよい。
【００２７】
システム１０内で用いられるコヒーレントパケットは異なるフォーマットを有してもよく、異なるデータを含んでもよい。図３−図６は、処理サブシステム１２内で用い得る例示的なコヒーレントパケットフォーマットを図示する。図３−図５は、例示的なコヒーレント情報、リクエストおよび応答パケットをそれぞれ図示し、図６は、例示的なコヒーレントデータパケットを図示する。情報（ｉｎｆｏ）パケットは、フロー制御情報、エラーステータスなど、通信リンクの一般的動作に関する情報を搬送する。リクエストおよび応答パケットは、トランザクションに関する制御情報を搬送する。いくつかのリクエストおよび応答パケットは、データパケットが後に続いていることを明示する。データパケットは、トランザクションおよび対応のリクエストまたは応答パケットに関連のデータを搬送する。他の実施例は異なるパケットフォーマットを用いてもよい。
【００２８】
図３−図６の例示的なパケットフォーマットは、連続した「ビット時間」の間に並行に送信される８ビットバイトのビット７−０の中身を示す。本明細書中では、パケットの各データ単位（たとえばバイト）を送信するのに用いる時間の量を「ビット時間」と称する。各ビット時間はＣＬＫ信号の周期の一部である。たとえば、ＣＬＫ信号の単一の周期内で、ＣＬＫ信号の立上がりエッジで第１のバイトを送信し、ＣＬＫ信号の立下がりエッジで異なるバイトを送信し得る。この場合、ビット時間はＣＬＫ信号の周期の半分である。図面中で値を与えられていないビット時間は、所与のパケット用の予備であるかまたは、パケット特有の情報を送信するのに用いられ得る。点線で示されるフィールドは、あるタイプのパケットのすべてに含まれるとは限らないオプションのフィールドを示す。
【００２９】
図３は、処理サブシステム１２内で用い得る例示的なコヒーレント情報（ｉｎｆｏ）パケット３０の図である。情報パケット３０は、８ビットコヒーレント通信リンク上の４ビット時間を含む。６ビットのコマンドフィールドＣｍｄ［５：０］は第１のビット時間（すなわちビット時間０）の間に送信される。図４および図５のリクエストおよび応答パケットは、ビット時間０の間の同じビット位置に同様のコマンドエンコーディングを含む。情報パケット３０を用いて、メッセージがアドレスを含まないときに最も近い近隣処理ノード間でメッセージを送信し得る。情報パケットはファブリック内でルーティングされないため、レシーバノードでバッファリングを全く必要としないであろう。さらに、情報パケットを用いて、上述のクーポンベースフロー機構においてバッファの空きを示すメッセージを送信し得る。他のタイプの情報パケットは、図７に図示されるように、システム同期（Ｓｙｎｃ）パケットおよび非動作（ＮＯＰ）パケットを含む。１つの実施例では、メッセージングプロトコルは、情報パケットがフロー制御されずかつ、常にそれらのデスティネーションノードで受入れられなければならないことを必要とし得る。
【００３０】
図４は、処理サブシステム１２内で用い得る例示的なコヒーレントリクエストパケット３２の図である。リクエストパケット３２は、８ビットのコヒーレント通信リンク上の８ビット時間を含む。リクエストパケット３２を用いて、トランザクション（たとえば読出または書込トランザクション）を開始しかつ、トランザクションによって影響を受けるアドレスを搬送するそれらのリクエストのためにトランザクションを実行するプロセスでリクエストを送信し得る。一般的に、リクエストパケットは、デスティネーションノードが行なうべき動作を示す。
【００３１】
リクエストのタイプを識別するコマンドフィールドＣｍｄ［５：０］のビットはビット時間０の間に送信される。ソースノード内のソースユニットを識別する値を含むソースユニットフィールドＳｒｃＵｎｉｔ［１：０］のビットもビット時間０の間に送信される。コンピュータシステム１０内のユニットのタイプは、メモリコントローラ、キャッシュ、プロセッサなどを含み得る。トランザクションを開始したノードを識別する値を含むソースノードフィールドＳｒｃＮｏｄｅ［２：０］のビットはビット時間１の間に送信される。デスティネーションノードを一意に識別する値を含むデスティネーションノードフィールドＤｅｓｔＮｏｄｅ［２：０］のビットもビット時間１の間に送信され得、これを用いてパケットをデスティネーションノードにルーティングし得る。パケットを受取るべきデスティネーションノード内のデスティネーションユニットを識別する値を含むデスティネーションユニットフィールドＤｅｓｔＵｎｉｔ［１：０］のビットもビット時間１の間に送信され得る。
【００３２】
多くのリクエストパケットは、ビット時間２にソースタグフィールドＳｒｃＴａｇ［４：０］のビットを含み得、これは、ソースノードフィールドＳｒｃＮｏｄｅ［２：０］およびソースユニットフィールドＳｒｃＵｎｉｔ［１：０］とともに、それ自身がその一部である特定のトランザクションにパケットを一意にリンクし得る。いくつかのリクエストでは、ビット時間３を用いて、トランザクションの影響を受けるメモリアドレスの最下位ビットを送信してもよい。ビット時間４−７を用いて、トランザクションの影響を受けるアドレスの最上位ビットを含むアドレスフィールドＡｄｄｒ［３９：８］のビットを送信する。パケット３２の未定義フィールドのうちいくつかをさまざまなリクエストパケットと用いてコマンド特有の情報を搬送してもよい。
【００３３】
図５は、処理サブシステム１２内で用い得る例示的なコヒーレント応答パケット３４の図である。応答パケット３４は、コマンドフィールドＣｍｄ［５：０］、デスティネーションノードフィールドＤｅｓｔＮｏｄｅ［２：０］およびデスティネーションユニットフィールドＤｅｓｔＵｎｉｔ［１：０］を含む。デスティネーションノードフィールドＤｅｓｔＮｏｄｅ［２：０］は、応答パケットのためのデスティネーションノードを識別する（これは、ある場合には、トランザクションのソースノードまたはターゲットノードであり得る）。デスティネーションユニットフィールドＤｅｓｔＵｎｉｔ［１：０］は、デスティネーションノード内のデスティネーションユニットを識別する。さまざまなタイプの応答パケットがさらなる情報を含み得る。たとえば、読出応答パケットは、後に続くデータパケットで与えられる読出データの量を示す。プローブ応答は、（ビット時間３でオプションの共有ビット「Ｓｈ」を用いて）プローブされたノードがリクエストされたキャッシュブロックのコピーを保持しているか否かを示し得る。
【００３４】
一般的に、応答パケット３４はトランザクションの実行の間の応答に用いられ、そのトランザクションの影響を受けるアドレスの送信を必要としない。さらに、応答パケット３４を用いて肯定応答パケットを送信してトランザクションを終了させ得る。リクエストパケット３２と同様に、応答パケット３４は、（図５のオプションフィールドとして図示される）多くのタイプの応答のために、ソースノードフィールドＳｒｃＮｏｄｅ［２：０］、ソースユニットフィールドＳｒｃＵｎｉｔ［１：０］およびソースタグフィールドＳｒｃＴａｇ［４：０］を含み得る。
【００３５】
図６は、処理サブシステム１２内で用い得る例示的なコヒーレントデータパケット３６の図である。図６のデータパケット３６は、８ビットのコヒーレント通信リンク上の８ビット時間を含む。データパケット３６は、転送されるデータ量に依存して、異なる数のビット時間を含み得る。たとえば、１つの実施例では、キャッシュブロックは、６４バイト、すなわち８ビットリンク上の６４ビット時間を含む。他の実施例は、所望により、キャッシュブロックを異なるサイズに規定してもよい。さらに、キャッシュ不可能な読出および書込のためにキャッシュブロックよりも小さいサイズでデータを送信してもよい。キャッシュブロックサイズよりも小さなデータを送信するためのデータパケットが用いるビット時間はより少ない。１つの実施例では、ノンキャッシュブロックサイズのデータパケットは、データ送信の前に数ビット時間のマスクビットを送信して、データバイトがデータパケット内で有効であることを示し得る。さらに、キャッシュブロックデータは、リクエストアドレスファーストの最下位ビットによってアドレス指定される８バイトのクワッドワードとして戻され、その後、残余のクワッドワードがインタリーブされて戻され得る。
【００３６】
図３−図６は、８ビットのコヒーレント通信リンクのためのパケットを図示する。図３−図６の連続したビット時間を連結することによって１６ビットおよび３２ビットリンクのためのパケットを形成し得る。たとえば、１６ビットリンク上のパケットのビット時間０は、８ビットリンク上のビット時間０および１の間に送信される情報を含み得る。同様に、３２ビットリンク上のパケットのビット時間０は、８ビットリンク上のビット時間０−３の間に送信される情報を含み得る。
【００３７】
以下の式１および２は、８ビットリンクからのビット時間に従う、１６ビットリンクのビット時間０と３２ビットリンクのビット時間１との形態を示す。
【００３８】
ＢＴ０_１６［１５：０］＝ＢＴ１_８［７：０］‖ＢＴ２_８［７：０］　　（１）
ＢＴ０_３２［３１：０］＝ＢＴ３_８［７：０］‖ＢＴ２_８［７：０］‖ＢＴ１_８［７：０］‖ＢＴ０_８［７：０］　　（２）
図７は、処理サブシステム１２内で用い得る異なるタイプのコヒーレントパケットを一覧にしたテーブル３８である。処理サブシステム１２の他の実施例が可能でありかつ企図され、パケットタイプとコマンドフィールドエンコーディングとの他の好適なセットを含み得る。テーブル３８は、各コヒーレントコマンドごとのコマンドフィールドＣｍｄ［５：０］の中身を含むコマンドコード列と、コマンドを表わすニーモニックを含むコマンド列と、コヒーレントパケット３０、３２および３４（および特定されている場合はデータパケット３６）のうちどれをそのコマンドに対して用いるかを示すパケットタイプ列とを含む。テーブル３８のコマンドのうちいくつかの簡単な機能説明が以下に与えられる。
【００３９】
読出トランザクションは、サイズドリード（Ｒｅａｄ（Ｓｉｚｅｄ））リクエスト、リードブロック（ＲｄＢｌｋ）リクエスト、リードブロック共有（ＲｄＢｌｋＳ）リクエストまたはリードブロック変更（ＲｄＢｌｋＭｏｄ）リクエストを用いて開始され得る。Ｒｅａｄ（Ｓｉｚｅｄ）リクエストは、所定サイズのキャッシュブロック以外のデータの読出またはキャッシュ不可能な読出に用いられる。読出すべきデータの量は、Ｒｅａｄ（Ｓｉｚｅｄ）リクエストパケットにエンコードされる。キャッシュブロックの読出にはＲｄＢｌｋリクエストを用い得る。ただしこれは、以下の２つの場合を除いてである。すなわち、（ｉ）書込可能なキャッシュブロックのコピーが所望される場合であり、この場合、ＲｄＢｌｋＭｏｄリクエストを用い得る；または（ｉｉ）キャッシュブロックのコピーが所望されるが、ブロックを変更する意図が知られていない場合であり、この場合、ＲｄＢｌｋＳリクエストを用い得る。ＲｄＢｌｋＳリクエストを用いて、あるタイプのコヒーレンシ機構（たとえばディレクトリベースのコヒーレンシ機構）をより効率的にし得る。
【００４０】
一般的に、トランザクションを開始するには、ソースノードから、キャッシュブロックに対応するメモリを所有するターゲットノードに適切な読出リクエストを送信する。ターゲットノードのメモリコントローラは、システムの他のノードにプローブリクエストを送信して、それらのノードのキャッシュブロックの状態を変えることおよび、キャッシュブロックの更新済コピーを含むノードにキャッシュブロックをソースノードへ送らせることによってコヒーレンシを維持する。プローブリクエストを受ける各ノードは、ソースノードにプローブ応答（ＰｒｏｂｅＲｅｓｐ）パケットを送信する。
【００４１】
プローブされたノードが変更された読出データのコピー（すなわちダーティデータ）を有する場合、そのノードは、読出応答（ＲｄＲｅｓｐｏｎｓｅ）パケットおよびダーティデータをソースノードに送信する。ダーティデータを送信するノードは、リクエストされた読出データのターゲットノードによる送信をキャンセルしようとして、ターゲットノードにメモリキャンセル（ＭｅｍＣａｎｃｅｌ）応答パケットも送信し得る。さらに、ターゲットノードのメモリコントローラは、ＲｄＲｅｓｐｏｎｓｅ応答パケットを用いて、リクエストされた読出データを送信し、その後にデータパケットのデータを送信する。
【００４２】
プローブされたノードからソースノードがＲｄＲｅｓｐｏｎｓｅ応答パケットを受けると、受けた読出データが用いられる。受けない場合は、ターゲットノードからのデータが用いられる。プローブ応答および読出データの各々が一旦ソースノードで受けられると、ソースノードは、トランザクションの終了の肯定応答としてソースダン（ＳｒｃＤｏｎｅ）応答パケットをターゲットノードに送信する。
【００４３】
書込トランザクションは、サイズドライト（Ｗｒ（Ｓｉｚｅｄ））リクエストパケットまたは犠牲（Ｖｉｃｔｉｍ）ブロック（ＶｉｃＢｌｋ）リクエストパケット、なおこの後には対応のデータパケットが続く、を用いて開始され得る。Ｗｒ（Ｓｉｚｅｄ）リクエストは、所定のサイズのキャッシュブロック以外のデータの書込またはキャッシュ不可能な書込に用いられる。Ｗｒ（Ｓｉｚｅｄ）リクエストのためのコヒーレンシを維持するため、ターゲットノードのメモリコントローラは、システムの他のノードの各々にプローブリクエストを送信する。プローブリクエストに応答して、プローブされた各ノードは、ターゲットノードにＰｒｏｂｅＲｅｓｐ応答パケットを送信する。プローブされたノードがダーティデータを記憶している場合、プローブされたノードは、ＲｄＲｅｓｐｏｎｓｅ応答パケットおよびダーティデータで応答する。このように、Ｗｒ（Ｓｉｚｅｄ）リクエストによって更新されたキャッシュブロックはメモリコントローラに戻され、Ｗｒ（Ｓｉｚｅｄ）リクエストが与えたデータと合流する。メモリコントローラは、プローブされたノードの各々からプローブ応答を受けると、ソースノードにターゲットダン（ＴｇｔＤｏｎｅ）応答パケットを送信して、トランザクションの終了の肯定応答を与える。ソースノードはＳｒｃＤｏｎｅ応答パケットで答える。
【００４４】
ノードによって変更されかつノード内でキャッシュの中で置き換えられる犠牲キャッシュブロックは、ＶｉｃＢｌｋリクエストパケットを用いてメモリに戻される。ＶｉｃＢｌｋリクエストにはプローブは必要ない。したがって、ターゲットメモリコントローラが犠牲ブロックデータをメモリにコミットする準備ができれば、ターゲットメモリコントローラは犠牲ブロックのソースノードにＴｇｔＤｏｎｅ応答パケットを送信する。ソースノードは、ＳｒｃＤｏｎｅ応答パケットで答えてデータをコミットすべきであることを示すかまたは、ＭｅｍＣａｎｃａｌ応答パケットで答えてＶｉｃＢｌｋリクエストの送信と（たとえば介入プローブに応答した）ＴｇｔＤｏｎｅ応答パケットの受信との間にデータが無効にされたことを示す。
【００４５】
ソースノードはダーティへ変更（ＣｈａｎｇｅｔｏＤｉｒｔｙ）リクエストパケットを送信して、書込不可能な状態でソースノードが記憶したキャッシュブロックの書込許可を入手し得る。ＣｈａｎｇｅｔｏＤｉｒｔｙリクエストで開始されたトランザクションは、ターゲットノードがデータを戻さないことを除き、読出トランザクションと同様に動作し得る。ソースノードがキャッシュブロック全体を更新することを意図する場合、ブロック有効化（ＶａｌｉｄａｔｅＢｌｋ）リクエストを用いて、ソースノードが記憶していないキャッシュブロックへの書込許可を入手し得る。そのようなトランザクションの場合、ソースノードにはデータが全く転送されないが、それ以外の場合は、読出トランザクションと同様に動作する。
【００４６】
ターゲットは、ターゲットスタート（ＴｇｔＳｔａｒｔ）応答を用いて、（たとえばその後のトランザクションの順序付けのために）トランザクションをスタートさせたことを示し得る。非動作（ＮＯＰ）情報パケットを用いて、ノード間にフロー制御情報（たとえばバッファ空き表示）を転送してもよい。ブロードキャストリクエストパケットを用いて、ノード間でメッセージをブロードキャスト（たとえば割込を配信）してもよい。最後に、同期（Ｓｙｎｃ）情報パケットを用いてノード動作（たとえば、エラー検出、リセット、初期化など）を同期化してもよい。
【００４７】
テーブル３８はバーチャルチャネル（Ｖｃｈａｎ）列も含む。Ｖｃｈａｎ列は、各パケットがその中を移動する（すなわち各パケットが属する）バーチャルチャネルを示す。この実施例では、４つのバーチャルチャネルが定義される。すなわち、ノンポステッドコマンド（ＮＰＣ）バーチャルチャネル、ポステッドコマンド（ＰＣ）バーチャルチャネル、応答（Ｒ）バーチャルチャネルおよびプローブ（Ｐ）バーチャルチャネルである。
【００４８】
バーチャルチャネル
次に図８を参照して、２つのバーチャルチャネル４０Ａおよび４０Ｂならびにそれらと処理ノード１２Ａ−１２Ｄとの関係が概略的に図示される。バーチャルチャネルは２つしか示されていないが、コンピュータシステム１０の他の実施例はいずれの好適な数のバーチャルチャネルを用いてもよいことを理解されたい。
【００４９】
一般的に、「バーチャルチャネル」とは、さまざまな処理ノード間でパケットを搬送するための通信経路である。各バーチャルチャネルは他のバーチャルチャネルとはリソース独立している（すなわち、１つのバーチャルチャネルを流れるパケットは、物理的送信という観点では、別のバーチャルチャネル中のパケットの存在または不在による影響を受けないことが一般的である）。パケットは、パケットのタイプに基づいてバーチャルチャネルに割当てられる。同じバーチャルチャネル中のパケットは、互いの送信と物理的に競合し得る（すなわち、同じバーチャルチャネル中のパケットはリソース競合に遭遇し得る）が、異なるバーチャルチャネル中のパケットの送信とは物理的に競合しないであろう。
【００５０】
あるパケットは他のパケットと論理的に競合し得る（すなわち、プロトコルの理由、コヒーレンシの理由またはその他のそのような理由により、１つのパケットが別のパケットと論理的に競合し得る）。論理的／プロトコルの理由のために、第２のパケットがそのデスティネーションノードに到着する前に第１のパケットがそのデスティネーションノードに到着する必要がある場合に、（たとえば競合するリソースを占めることによって）第２のパケットが第１のパケットの送信を物理的にブロックすれば、コンピュータシステムがデッドロックを起こす可能性がある。第１および第２のパケットを別個のバーチャルチャネルに割当てることにより、かつ、別個のバーチャルチャネル中のパケットが互いの送信をブロックできないようにコンピュータシステム内の送信媒体を実現することにより、デッドロックのない動作を達成し得る。異なるバーチャルチャネルからのパケットは同じ物理リンク（たとえば図１の線２４）上を送信されることに留意されたい。しかしながら、送信前に受信バッファが利用可能であるため、バーチャルチャネルは、この共有リソースを用いる間ですら互いをブロックすることはない。
【００５１】
各々の異なるパケットタイプ（たとえば各々の異なるコマンドフィールドＣＭＤ［５：０］）は、それ自身のバーチャルチャネルに割当てられ得る。しかしながら、バーチャルチャネルにおいて物理的に競合がないことを確実にするハードウェアは、バーチャルチャネルの数とともに増加し得る。たとえば、１つの実施例では、各バーチャルチャネルに別個のバッファが割振られる。各バーチャルチャネルごとに別個のバッファを用いるため、１つのバーチャルチャネルからのパケットは別のバーチャルチャネルからのパケットと物理的に競合しない（そのようなパケットは他のバッファに置かれるからである）。しかしながら、バッファの数がバーチャルチャネルの数に比例することに留意されたい。したがって、論理的／プロトコルの態様で競合しないさまざまなパケットタイプを組合せることによりバーチャルチャネルの数を低減することが望ましい。同じバーチャルチャネルを移動する際、そのようなパケットは互いと物理的に競合し得るが、論理的競合がないことにより、デッドロックすることなくリソース競合を解決することができる。同様に、互いと論理的に競合し得るパケットを別個のバーチャルチャネルに保持することにより、パケット間でのリソース競合がなくなる。したがって、先に完了すべきパケットを前に進めることによってパケット間のリソース競合をなくすことで、論理的競合を解決し得る。
【００５２】
１つの実施例では、特定のソースノードから特定のデスティネーションノードへコヒーレントリンク上の特定のバーチャルチャネル内を移動するパケットは順序付けられたままである。しかしながら、異なるバーチャルチャネルを移動する特定のソースノードから特定のデスティネーションノードへのパケットは順序付けられていない。同様に、特定のソースノードから異なるデスティネーションノードへまたは異なるソースノードから同じデスティネーションノードへのパケットは、（同じバーチャルチャネル中を移動しているとしても）順序付けられない。
【００５３】
バーチャルチャネルはコヒーレントファブリックおよびノンコヒーレントファブリックに物理的にマッピングされる（図１９参照）。たとえば、図１に示されるコンピュータシステム１０の実施例では、相互接続は各処理ノード間の一方向リンクを含む。したがって、さまざまなバーチャルチャネルを移動するパケットは一方向リンク上を物理的に送信される。パケットは、ソースとデスティネーションとの間の中間ノードを通って移動し得る。たとえば、ノード１２Ａからノード１２Ｄに移動するパケットはノード１２Ｂまたはノード１２Ｃを通り得る。異なるバーチャルチャネルを移動するパケットは、コンピュータシステム１０を通って異なってルーティングされ得る。たとえば、ノード１２Ａからノード１２Ｄへ第１のバーチャルチャネルを移動するパケットはノード１２Ｂを通り得るが、ノード１２Ａから１２Ｄへ第２のバーチャルチャネルを移動するパケットはノード１２Ｃを通り得る。各ノードは、異なるバーチャルチャネル中のパケットが互いと物理的に競合しないのを確実にする回路構成を含み得る。ノンコヒーレントファブリックでは、Ｉ／Ｏノードからのパケットは、そのＩ／Ｏノードとホストブリッジとの間で互いのＩ／Ｏノードを通り得る（図１９参照）。Ｉ／Ｏノードは、図８に示されたのと同様の態様でバーチャルチャネルに結合され得ることに留意されたい。
【００５４】
以下により詳細に記載される１つの特定の実施例では、各バーチャルチャネルにコマンドパケットバッファが割当てられて、そのバーチャルチャネルを移動するパケットをバッファする。データパケットを搬送し得る各バーチャルチャネルに別個のデータパケットバッファを割当ててもよい。コマンドパケットバッファ（その各々のエントリは比較的小さな数のビット時間を含み得る）とデータパケットバッファ（その各々のエントリは比較的大きな数のビット時間を含んでキャッシュブロックを保持し得る）とを分けることにより、好適なデータ記憶を依然として提供しながらバッファ空間を節約し得る。データパケットバッファよりも多くのコマンドパケットバッファを実現してもよい（すべてのデータパケットは対応のリクエストまたは応答パケットを有するが、すべてのリクエストまたは応答パケットが対応のデータパケットを有するとは限らないからである）。バッファ空間を比較的効率よく用いている間は、スループットは高いであろう。
【００５５】
図９は、コンピュータシステム１０の１つの実施例に従って規定されたバーチャルチャネルを図示するテーブル４２である。他の実施例が可能でありかつ企図される。示された実施例については、４つのバーチャルチャネルが規定される。コヒーレントリンクのためにそれらのバーチャルチャネルに属するパケットが図７に示され、ノンコヒーレントリンクのためにそれらのバーチャルチャネルに属するパケットが図２０に示される。
【００５６】
所与のリクエストは「ポストされた」または「ノンポステッド」リクエストであろう。一般的に、ポストされたリクエストは、ソースノード（たとえばソースノード内のインターフェイス）がリクエストおよび対応のデータを送信するときにソースノードによって完了したとみなされる。したがって、ポストされたリクエストはソースで実質的に完了する。その結果、ソースノードは、ポストされたリクエストのパケットまたは複数のパケットがターゲットノードに移動し、ターゲットノードがポストされたリクエストを完了する間に、他のリクエストを発行しかつ他の動作を継続し得る。ソースノードは、ターゲットノードがいつポストされたリクエストを実際に完了するかに直接に気づかない。例示的な実施例では、コヒーレントポステッドリクエストパケットは、バーチャルチャネル識別子として用いられるコマンドフィールドにポステッドビットを含む。コヒーレントポステッドリクエストは、ターゲットインターフェイス（たとえばノンコヒーレントリンク）でポステッドリクエストを完了する前にＴｇｔＤｏｎｅ応答をソースノードに送信することにより、コヒーレントファブリックにおいて完了する。
【００５７】
ポストされたリクエストに対して、ノンポステッドリクエストは、ターゲットインターフェイス上で完了する前にソースインターフェイスで完了しないリクエストである。このように、リクエストのソースは、リクエストがターゲットで完了したことに（リクエストの完了を介して）直接に気づく。一般的に、さまざまなノンポステッドリクエストパケットは、互いと論理的／プロトコル競合を有しない。なぜなら、それらがデスティネーション（すなわちトランザクションのターゲット）に到達するまではそれらの間に順序が存在しないからである。したがって、ノンポステッドリクエストパケットを１つのバーチャルチャネルに含んでもよい。
【００５８】
例示的な実施例では、ポステッドおよびノンポステッドリクエストパケットは別個のバーチャルチャネルに属して、ある入力／出力（または周辺）バスプロトコルとの互換性を与える。たとえば、周辺機器相互接続（ＰＣＩ）バスインターフェイスはポステッドライトを与える。以下の順序付けルールはＰＣＩをソースとする動作についてＰＣＩが必要とするものである。
【００５９】
（ｉ）　同じソースからのポステッドライトはターゲットインターフェイス上に順序付けられたままである。
【００６０】
（ｉｉ）　ポステッドライトおよびその後の同じソースからの読出は、読出データが戻される前にターゲットインターフェイス上で完了する。
【００６１】
（ｉｉｉ）　ノンポステッドライトは同じソースからのポステッドライトを通さない。
【００６２】
（ｉｖ）　ポステッドライトは、先行するノンポステッドリクエストを通すことを許されなければならない。
【００６３】
要件（ｉ）は、ホストブリッジが実現するある制約とともに、ポステッドリクエストをポステッドコマンドバーチャルチャネルに置く（したがってそれらは特定のターゲットに向けて順序付けられたままである）ことによって達成される（図２８参照）。要件（ｉｉ）および（ｉｉｉ）は、ノンコヒーレントファブリック上のポステッドリクエストチャネルとノンポステッドコマンドチャネルとの間の論理的競合である。ノンコヒーレントリンク上での論理的競合に関するさらなる詳細を以下に述べる。要件（ｉｉ）および（ｉｉｉ）は、ある制約をホストブリッジで実現することにより、ポステッドライトがノンコヒーレントリンクからコヒーレントリンクに送信されるときに満たされ得る（図２８参照）。要件（ｉｖ）は、別個のポステッドコマンド、ノンポステッドコマンドおよび応答バーチャルチャネルを設けることによって満たされる。
【００６４】
ポステッドおよびノンポステッドリクエストは、プローブリクエストパケットの生成を引起して（コヒーレントファブリックにおいてコヒーレンシを維持し）、応答パケットの生成を引起して（データを転送しかつトランザクションの肯定応答を与え得る）。したがって、プローブパケットおよび応答パケットは、ポステッドおよびノンポステッドリクエストと同じバーチャルチャネルには含まれず（リソース競合および論理的競合がデッドロックを生じるのを防止する）。さらに、プローブパケットはプローブ応答および読出応答パケットの生成を引起し得るため、それらは応答パケットとは別個のバーチャルチャネルに置かれる。
【００６５】
応答パケットはさらなる応答パケットも生成し得る（たとえば、ＳｒｃＤｏｎｅおよびＴｇｔＤｏｎｅは互いを生成させ得る）。したがって、応答パケットは、すべての応答パケットが同じバーチャルチャネルに割当てられれば、他の応答パケットと論理的に競合し得る。しかし、応答パケットを複数の異なるバーチャルチャネルに割当てることは、さらなるバーチャルチャネルを扱うリソース要件（たとえばバッファ）が増加するために望ましくないであろう。応答パケットは（ポステッドまたはノンポステッドのいずれかの）リクエストパケットの（たとえばリクエストパケットに応答して生成されたプローブを介した）直接または間接の結果であることに留意されたい。したがって、例示的な実施例では、ノード１２Ａ−１２Ｄ（および以下に示されるＩ／Ｏノード）は、ポステッドまたはノンポステッドリクエストパケットでトランザクションを開始する前に、そのトランザクションの間に送信されるいかなるものにも応答して生成され得る、（いずれの応答データパケットも含む）応答パケットを処理するにも十分なリソースを割振るように構成され得る。同様に、プローブリクエストパケットを生成する前に、ノードは、（応答パケットがそのノードに戻される場合に）プローブ応答パケットを処理するのに十分なリソースを割振るように構成され得る。この予めのリソース割振りによって論理的競合が回避され、すべての応答パケットが処理ノードによって受取り可能になる。したがって、応答パケットは１つの応答バーチャルチャネルに合流し得、その中をすべての応答パケット（および対応のデータパケット）が移動し得る。
【００６６】
プローブリクエストパケットはプローブバーチャルチャネルを移動する。プローブを用いて、さまざまなキャッシュされたメモリ場所のコピーとメモリ場所自体との間のコヒーレンシを維持する。メモリコントローラが処理する第１のリクエストパケットに対応するコヒーレンシアクティビティは、その後のリクエストパケットを処理し得る前に完了する必要があり得る。たとえば、メモリコントローラの待ち行列が同じキャッシュブロックと関連のリクエストで満杯である場合、第１のリクエストが完了するまでは、メモリコントローラにおいてさらなるリクエストパケットの処理は起こり得ない。したがって、プローブリクエストパケットを別個のバーチャルチャネルに割当てて、他のバーチャルチャネル中のパケットとのリソース競合がプローブリクエストパケットをブロックしないことを確実にし得る。
【００６７】
テーブル４２は、各タイプのバーチャルチャネルをサポートする（たとえばコヒーレントまたはノンコヒーレント）通信リンクのタイプも示す。たとえば、ノンコヒーレントおよびコヒーレントリンクは両者とも、ポステッドコマンド、ノンポステッドコマンドおよび応答バーチャルチャネルをサポートする。しかしながら、プローブリクエストパケットはコヒーレンシを確実にすることを意図されるがノンコヒーレントリンクはコヒーレンシをサポートしていないため、ノンコヒーレントリンクはプローブバーチャルチャネルとしては用いられないであろう。
【００６８】
バーチャルチャネル−コヒーレントファブリック
ここで図１０を参照して、例示的な処理ノード１２Ａの１つの実施例のブロック図が示される。他の処理ノード１２Ｂ−１２Ｄは同様に構成され得る。さらに、処理ノード１２Ａ−１２Ｄの他の実施例が可能でありかつ企図される。図１０の実施例では、処理ノード１２Ａは、インターフェイスロジック１８Ａ、１８Ｂおよび１８Ｃならびにメモリコントローラ１６Ａを含む。さらに、処理ノード１２Ａは、プロセッサコア５２およびキャッシュ５０、パケット処理ロジック５８を含み、オプションで第２のプロセッサコア５６および第２のキャッシュ５４を含み得る。インターフェイスロジック１８Ａ−１８Ｃはパケット処理ロジック５８に結合される。プロセッサコア５２および５６はそれぞれキャッシュ５０および５４に結合される。キャッシュ５０および５４はパケット処理ロジック５８に結合される。パケット処理ロジック５８はメモリコントローラ１６Ａに結合される。
【００６９】
一般的に、パケット処理ロジック５８は、処理ノード１２Ａが結合されるリンク上で受信されるリクエストパケットに応答して、キャッシュ５０および５４ならびに／またはプロセッサコア５２および５６からのリクエストに応答してリクエストパケットを生成し、サービスのため（ｆｏｒ ｓｅｒｖｉｃｅ）メモリコントローラ１６Ａが選択したトランザクションに応答してプローブリクエストおよび応答パケットを生成し、かつ、ノード１２Ａを中間ノードとするパケットをインターフェイスロジック１８Ａ−１８Ｃのうち別のものにルーティングして別のノードに送信するように構成される。インターフェイスロジック１８Ａ、１８Ｂおよび１８Ｃは、パケットを受信しかつパケット処理ロジック５８が用いる内部クロックとパケットとを同期するロジックを含み得る。
【００７０】
パケット処理ロジック５８は、コンピュータシステム１０がサポートするバーチャルチャネルからのリソース独立をサポートするハードウェアを含み得る。たとえば、パケット処理ロジック５８は、図１１に図示されるように、各バーチャルチャネルごとに別個のバッファを設け得る。代替的な実施例は、インターフェイスロジック１８Ａ−１８Ｃ内または任意の他の好適な場所に、バーチャルチャネルからのリソース独立を与えるためのハードウェアを設け得る。
【００７１】
キャッシュ５０および５４は、データのキャッシュブロックを記憶するように構成された高速キャッシュメモリを含む。キャッシュ５０および５４はそれぞれのプロセッサコア５２および５６内に一体化されてもよい。これに代えて、キャッシュ５０および５４は、所望により、裏面キャッシュ構成またはインライン構成でプロセッサコア５２および５６に結合されてもよい。さらに、キャッシュ５０および５４はキャッシュ階層として実現されてもよい。所望により、（キャッシュ階層内の）プロセッサコア５２および５６により近い方のキャッシュがプロセッサコア５２および５６と一体化されてもよい。
【００７２】
プロセッサコア５２および５６は、予め規定された命令セットに従って命令を実行するための回路構成を含む。たとえば、ｘ８６命令セットアーキテクチャを選択し得る。これに代えて、Ａｌｐｈａ（Ｒ）、ＰｏｗｅｒＰＣ（Ｒ）またはいずれの他の命令セットアーキテクチャを選択してもよい。一般的に、プロセッサコアはデータおよび命令を求めてキャッシュにアクセスする。キャッシュミスが検出されれば読出リクエストが生成されて、ミスしているキャッシュブロックがマッピングされるノード内のメモリコントローラに送信される。
【００７３】
ここで図１１を参照して、パケット処理ロジック５８の例示的な実施例のブロック図が示される。他の実施例が可能でありかつ企図される。図１１の実施例では、パケット処理ロジック５８は、第１の組のコマンドおよびデータパケットバッファ６０と、第２の組のコマンドおよびデータパケットバッファ６２と、第３の組のコマンドおよびデータパケットバッファ６４と、制御ロジック６６と、データバッファプール６８と、応答カウンタプール７０とを含む。コマンドおよびデータパケットバッファ６０は、ポステッドコマンドバッファ（ＰＣＢ）６０Ａ、ノンポステッドコマンドバッファ（ＮＰＣＢ）６０Ｂ、応答バッファ（ＲＢ）６０Ｃ、プローブバッファ（ＰＢ）６０Ｄ、ポステッドコマンドデータバッファ（ＰＣＤＢ）６０Ｅ、ノンポステッドコマンドデータバッファ（ＮＰＣＤＢ）６０Ｆおよび応答データバッファ（ＲＤＢ）６０Ｇを含む。
【００７４】
同様に、コマンドおよびデータパケットバッファ６２は、ポステッドコマンドバッファ（ＰＣＢ）６２Ａ、ノンポステッドコマンドバッファ（ＮＰＣＢ）６２Ｂ、応答バッファ（ＲＢ）６２Ｃ、プローブバッファ（ＰＢ）６２Ｄ、ポステッドコマンドデータバッファ（ＰＣＤＢ）６２Ｅ、ノンポステッドコマンドデータバッファ（ＮＰＣＤＢ）６２Ｆおよび応答データバッファ（ＲＤＢ）６２Ｇを含む。コマンドおよびデータパケットバッファ６４は、ポステッドコマンドバッファ（ＰＣＢ）６４Ａ、ノンポステッドコマンドバッファ（ＮＰＣＢ）６４Ｂ、応答バッファ（ＲＢ）６４Ｃ、プローブバッファ（ＰＢ）６４Ｄ、ポステッドコマンドデータバッファ（ＰＣＤＢ）６４Ｅ、ノンポステッドコマンドデータバッファ（ＮＰＣＤＢ）６４Ｆおよび応答データバッファ（ＲＤＢ）６４Ｇを含む。コマンドおよびデータパケットバッファ６０は、（たとえば線２４Ｂ上で）インターフェイスロジック１８Ａが受けるパケットを受けるように結合される。同様に、コマンドおよびデータパケットバッファ６２は、インターフェイスロジック１８Ｂが受けるパケットを受けるように結合され、コマンドおよびデータパケットバッファ６４は、インターフェイスロジック１８Ｃが受けるパケットを受けるように結合される。コマンドおよびデータパケットバッファ６０、６２および６４は制御ロジック６６に結合される。
【００７５】
さらに、応答データバッファ６０Ｇ、６２Ｇおよび６４Ｇはデータバッファプール６８に結合される。データバッファプール６８および応答カウンタプール７０は制御ロジック６６に結合され、制御ロジック６６は、ノードＩＤレジスタ７２、コマンドパケットアクティブレジスタ７４Ａ−７４Ｃおよびデータパケットアクティブレジスタ７６Ａ−７６Ｃをさらに含む。制御ロジック６６は送受信インターフェイスを介してインターフェイス１８Ａ−１８Ｃに結合され、かつ、メモリコントローラ１６Ａおよびキャッシュ５０（およびオプションのキャッシュ５４）にも結合される。データバッファプール６８はメモリコントローラ１６Ａおよびキャッシュ５０（およびオプションのキャッシュ５４）にさらに結合される。
【００７６】
コマンドおよびデータパケットバッファの各組はバーチャルチャネルの各々ごとに異なるバッファを設ける。たとえば、この実施例では、ポステッドコマンドバッファ６０Ａはポステッドコマンドバーチャルチャネルに割当てられ、ノンポステッドコマンドバッファ６０Ｂはノンポステッドコマンドバーチャルチャネルに割当てられ、応答バッファ６０Ｃは応答バーチャルチャネルに割当てられ、かつ、プローブバッファ６０Ｄはプローブバーチャルチャネルに割当てられ得る。このように、１つのバーチャルチャネルでのパケットの受信は、別のバーチャルチャネルでのパケットの受信によって妨げられることはないであろう。各バーチャルチャネルからのパケットは、そのバーチャルチャネルに対応するコマンドパケットバッファに記憶され得るため、（異なるコマンドパケットバッファに記憶される）別のバーチャルチャネルから受けたパケットと物理的に競合することはない。バッファ６２および６４内の同じ名前のバッファは、上述のようにバーチャルチャネルに割当てられ得る。
【００７７】
同様に、データパケットバッファは、データパケットを搬送する各バーチャルチャネルごとに設けられる。例示的な実施例では、プローブバーチャルチャネルはデータパケットを搬送しないであろう。たとえば、ポステッドコマンドデータバッファ６０Ｅはポステッドコマンドバーチャルチャネルに割当てられ、ノンポステッドコマンドデータバッファ６０Ｆはノンポステッドコマンドバーチャルチャネルに割当てられ、かつ、応答データバッファ６０Ｇは応答バーチャルチャネルに割当てられ得る。バッファ６２および６４内の同じ名前のバッファは、上述のようにバーチャルチャネルに割当てられ得る。
【００７８】
この実施例では、インターフェイスロジック１８Ａ−１８Ｃは、受信パケットを、制御経路上に与えられたパケットとデータ経路上に与えられたデータパケットとに分けるように構成される。制御経路はコマンドパケットバッファに結合され（たとえば、バッファ６０Ａ−６０Ｄはインターフェイスロジック１８Ａからの制御経路に結合され）、データ経路はデータパケットバッファに結合される（たとえば、バッファ６０Ｅ−６０Ｇはインターフェイスロジック１８Ａからのデータ経路に結合される）。制御ロジック６６は、送受信インターフェイスを介してパケットのタイプの表示を受けるように構成され、さらに、受信中のパケット用のバッファエントリを割振るように構成され得る。他の企図される実施例では、インターフェイスロジックは受信パケットを分割しない。そのような実施例では、制御ロジック６６は制御（ＣＴＬ）信号を受信して、データのビット時間と制御情報のビット時間とを区別し得る。
【００７９】
一般的に、制御ロジック６６は、他のバッファに保持されるパケットとは独立してさまざまなバッファからのパケットを処理するように構成され得る。したがって、異なるバーチャルチャネルを移動するパケット間の物理的競合を回避することができる。
【００８０】
例示的な実施例では、制御ロジック６６は、コマンドパケットバッファ６０、６２および６４内のパケットを調べて、パケットがノード１２Ａ（このノード）に宛先決めされているのかまたはこれを別のノードに転送すべきかを判断する。ノードＩＤレジスタ７２は「このノード」のノードＩＤを記憶し、制御ロジック６６はノードＩＤを参照して比較を行ない、パケットが「このノード」に宛先決めされているか否かを判断し得る。この実施例では、プローブバーチャルチャネル中のパケットはブロードキャストパケットであるので、「このノード」と「このノード」がパケットを送信すべき他のノードとの双方に宛先決めされていることに留意されたい。したがって、制御ロジック６６はプローブバーチャルチャネルで受信するパケットのノードＩＤ比較を省略してもよい。しかしながら、プローブバーチャルチャネル以外のバーチャルチャネル中のパケットは、パケットがこのノードに宛先決めされているのかまたはこれを別のノードに転送すべきかをパケットのデスティネーションノードフィールドが識別する対象の、方向付けられたパケットである。したがって、制御ロジック６６は、そのようなパケットについてノードＩＤ比較を行ない得る。
【００８１】
制御ロジック６６は、各デスティネーションノードごとに、インターフェイスロジック１８Ａ−１８Ｃのうちどれを用いてブロードキャストパケットまたは他のノードに宛先決めされたパケットを転送し得るかを示す１つ以上のルーティングテーブルを含み得る。制御ロジック６６は、識別されたインターフェイスロジック１８Ａ−１８Ｃを介して送信されたパケットを受けるように結合された受信ノードが、そのパケットが割当てられるバーチャルチャネル用の空きのあるコマンドパケットバッファを有する場合に、パケットを転送し得る。さらに、パケットがデータパケットを特定している場合、制御ロジック６６は、制御ロジック６６がパケットおよび特定されたデータパケットを転送する前に、パケットが割当てられるバーチャルチャネル用のデータパケットバッファの利用可能性を確認する。制御ロジック６６が、パケット（および特定されていればデータパケット）を転送すべきであると判断しかつ適切なパケットバッファの利用可能性を確認すれば、制御ロジックは、送受信インターフェイスを用いて、識別されたインターフェイスロジック１８Ａ−１８Ｃにそのパケットを転送する。その後、インターフェイスロジック１８Ａ−１８Ｃはパケットを受信ノードに転送する。また、制御ロジック６６は、対応するタイプのバッファが空いたことに気づく（パケットおよび特定されていればデータパケットが転送されたからである）。次に適切なインターフェイス１８Ａ−１８Ｃを介して情報パケットが送信され、受信端のノードにバッファの利用可能性を通知し得る。
【００８２】
しかしながら、パケットが「このノード」に宛先決めされている場合、制御ロジック６６は、パケットのタイプに基づいてパケットを処理する。たとえば、パケットがメモリコントローラ１６Ａにターゲット決めされた書込リクエストである場合、制御ロジック６６は、書込リクエストパケットをメモリコントローラ１６Ａに運搬しようとする。メモリコントローラ１６Ａは、処理すべきトランザクションに待ち行列を用いてもよく、たとえば待ち行列が満杯である場合は書込リクエストパケットを拒否してもよい。受信パケットがプローブリクエストパケットである場合、制御ロジック６６は、キャッシュ５０および５４（ならびにプロセッサコア５２および５６の内部の任意のキャッシュ）と通信して、プローブがアドレス指定するキャッシュブロックのステータスを判断し得る。次に制御ロジック６６は、アドレス指定されたキャッシュブロックのステータスを報告するプローブ応答パケット（またはキャッシュブロックが変更されていれば、データを備える読出応答パケット）を生成することによってプローブに応答し、次に、受信ノードが適切なパケットバッファの利用可能性を示していれば、プローブ応答パケットを送信し得る。
【００８３】
受信パケットを処理することに加え、制御ロジック６６は、キャッシュ５０および５４からの犠牲ブロックおよびフィルリクエストに応答してパケットを生成しかつ、（たとえばキャッシュ不可能なリクエスト、Ｉ／Ｏリクエストなどの）プロセッサコア５２および５６から直接のリクエストに応答してパケットを生成し得る。さらに、応答パケットは、送信のためのデータを与えるかまたはトランザクションを完了するメモリコントローラに応答して生成され得る。制御ロジック６６は、処理に対する対応のリクエストを選択するメモリコントローラ１６Ａに応答してプローブリクエストパケットを生成し、受信ノードバッファが利用可能であればプローブリクエストパケットをブロードキャストしてもよい。
【００８４】
上述のように、ノードは、そのノードが送信するリクエストパケットに応答して、受信した応答パケットを処理するのに十分なリソースを割振る。例示的な実施例では、制御ロジック６６はパケットを送信し得、その結果、次の２つの場合に応答パケットがノードに戻されることになり得る。すなわち、（ｉ）リクエストパケットを生成して（たとえば、キャッシュ５０および５４またはプロセッサコア５２および５６からのリクエストに応答して）トランザクションを開始する場合；および（ｉｉ）メモリコントローラ１６Ａをターゲットとするリクエストパケットに対しプローブリクエストパケットを生成する場合、である。より特定的には、メモリコントローラ１６Ａをターゲットにするサイズドライトについて、（ｉｉ）の場合が起こり得る。いずれにせよ、制御ロジック６６はリソースを割振って、応答パケットの受信および処理を行なう。
【００８５】
例示的な実施例では、制御ロジック６６は、データバッファプール６８および応答カウンタプール７０からリソースを割振って、応答を受信しかつ処理し得る。データバッファプール６８は、データのキャッシュブロックを記憶するために複数のエントリを含み得る一方、応答カウンタプール７０は複数のカウンタを含み得る。データバッファプールエントリは、トランザクションに対応する応答データを記憶するように割振られ得る。カウンタは、受信した応答をカウントし、かつ、プローブ応答において与えられ得るいかなるステート情報も保持するように割振られ得る。応答パケットは、割振られたカウンタを用いて（たとえば、予期される数の応答に達するまで）カウントされ得、応答パケットとともに受信されたデータは、割振られたデータバッファに記憶され得る。トランザクションに関わる、多くても２つの応答パケット（ＭｅｍＣａｎｃｅｌ応答パケットが応答パケットの送信前にメモリコントローラに達しない場合の、ターゲット決めされたメモリコントローラからのパケットと、変更されキャッシュされたデータのコピーを有した、プローブされたノードからのパケット）がデータを搬送し得ることに留意されたい。２つのデータパケットを受信した場合、プローブされたノードからのパケットが保持され、メモリコントローラからのパケットが破棄される。
【００８６】
予期される応答および応答データの各々を一旦受信すると、制御ロジック６６は、行なわれたトランザクションのタイプに依存して、データをメモリコントローラ１６Ａまたはキャッシュ５０もしくは５４に送信し得る。たとえば、応答が、パケット処理ロジック５８が生成したプローブリクエストに応答して生成されたプローブ応答である場合、応答データはメモリコントローラ１６Ａに送信され得る。これに代えて、読出トランザクションの結果として応答が生成された場合、データはキャッシュ５０または５４に送信され得る。
【００８７】
データバッファプール６８を用いて、ノード１２Ａから送信されるべきデータを記憶してもよいことに留意されたい。たとえば、犠牲ブロックデータまたはノード１２Ａをソースとする書込リクエストのための書込データをデータバッファプール６８に記憶してもよい。これに代えて、そのようなデータに別個のバッファを設けてもよい。さらに、さまざまなトランザクションに用い得るバッファのプールを設ける代わりに、各トランザクションタイプごとに別個のバッファを設けてもよい。
【００８８】
一般的に、本明細書中で用いるように、バッファは、後の検索のために１つ以上の情報項目を記憶するのに用いられる記憶素子である。バッファは、１つ以上のレジスタ、ラッチ、フリップフロップまたは他のクロック記憶装置を含み得る。これに代えて、バッファは、好適に配置されたランダムアクセスメモリ（ＲＡＭ）セルの組を含んでもよい。バッファは複数の記憶場所に分割され、各記憶場所は、バッファが意図される対象のタイプの情報の１項目を記憶するように構成される。記憶場所はいずれの好適な態様で割振られても割振り解除されてもよい。たとえば、バッファは、より古いエントリが削除されれば、記憶されたエントリが所定の場所にシフトダウンしていく、シフティング先入れ先出し（ＦＩＦＯ）バッファとして動作してもよい。これに代えて、ヘッドおよびテールポインタを用いて、バッファの中で最も古いおよび最も新しいエントリ場所を示してもよく、エントリは、そこから削除されるまでは、バッファの特定の記憶場所に留まり得る。本明細書中で用いられるような「制御ロジック」という用語は、入力に対する動作を行ない、かつ、それに応答して出力を生成して上記動作を行なう、組み合わせロジックおよび／またはステートマシンのいずれの組み合わせも指す。
【００８９】
例示的な実施例では、パケットは、一連のビット時間としてインターフェイスロジック１８Ａ−１８Ｃから受信される。インターフェイスロジック１８Ａ−１８Ｃは、コマンドまたはデータビット時間が送信されているかを示し、制御ロジック６６が、適切なバッファにビット時間を記憶させる。制御ロジック６６は、コマンドパケットアクティブ（ＣＰＡ）レジスタ７４およびデータパケットアクティブ（ＤＰＡ）レジスタ７６を用いて、現在受信されているパケットがどのバーチャルチャネルに割当てられるのかを識別し得る。ＣＰＡレジスタ７４は、各インターフェイスロジック１８Ａ−１８Ｃのために提供される（たとえば、ＣＰＡ７４Ａは、インターフェイス１８Ａに対応し得る）。同様に、ＤＰＡレジスタ７６は、各インターフェイスロジック１８Ａ−１８Ｃのために提供される（たとえば、ＤＰＡレジスタ７６Ａは、インターフェイス１８Ａに対応し得る）。
【００９０】
したがって、例示的な実施例では、受信されるパケットの第１のビット時間に応答して、制御ロジック６６は、（ビット時間１内の）コマンドフィールドをデコードし、受信されるパケットがどのバーチャルチャネルに割当てられるかを判断する。制御ロジック６６は、（インターフェイスロジック１８Ａ−１８Ｃであって、それらからパケットが受信されるインターフェイスロジック１８Ａ−１８Ｃに対応するセット内の）対応するコマンドパケットバッファ内でバッファ場所を割振り、インターフェイスロジック１８Ａ−１８Ｃであって、それらからパケットが受信されるインターフェイスロジック１８Ａ−１８Ｃに対応するＣＰＡレジスタ７６の状態を設定してそのコマンドパケットバッファ場所の割振りを示す。同じインターフェイスロジック１８Ａ−１８Ｃからの後続のパケットビット時間は、パケットの各ビット時間が受信されるまで、示されたバッファ内の示された場所に記憶される。同様に、パケットがデータパケットを特定するならば、制御ロジック６６は、識別されるバーチャルチャネルに対応するデータパケットバッファ内でデータパケットバッファ場所を割振る。データパケットビット時間は、データの各ビット時間が受信されるまで、示されたバッファの示された場所に記憶される。
【００９１】
代替的な実施例では、インターフェイスロジック１８Ａ−１８Ｃは、パケットのビット時間を集め、次に、全パケットをパケット処理ロジック５８に送信し得る。このような実施例では、ＣＰＡレジスタ７４およびＤＰＡレジスタ９６は削除され得る。さらなる別の実施例では、インターフェイスロジック１８Ａ−１８Ｃは、パケット処理ロジック５８への並行送信のためにいくつかのビット時間を集め得るが、ビット時間の数はパケットよりも少ないであろう。さらなる別の実施例では、バッファ６０、６２、および６４は、パケット処理ロジック５８内ではなく、それぞれのインターフェイスロジック１８Ａ−１８Ｃ内に位置づけられてもよい。
【００９２】
図１１で示される実施例は、各インターフェイスロジック１８Ａ−１８Ｃに対して別個の組のバッファを提供する。代替的な実施例では、バッファは、インターフェイスロジック間で分割され得る（各バーチャルチャネルタイプのための）１つ以上のバッファプールとして提供され得る。このような実施例では、バッファは、別のノードに結合されていないインターフェイスロジック（たとえば、図１の例でのインターフェイスロジック１８Ｃ）に割当てられる必要はなく、バッファプールが最大限に効率的に用いられる。したがって、これ以外の場合にはインターフェイスロジック１８Ｃに割振られたであろうバッファは、インターフェイスロジック１８Ａ−１８Ｂによって用いられるために割振られ得る。
【００９３】
次に図１２を参照して、データバッファプール６８内にあり得るデータバッファプール場所８０の１つの実施例を例示する図が示される。他の実施例も可能であり、企図される。図１２の実施例では、データバッファプール場所８０は、ソースタグフィールド８２、ソースノードフィールド８４、ソースユニットフィールド８８、およびデータフィールド８６を含む。
【００９４】
制御ロジック６６がデータバッファプール場所８０を割振ってトランザクションのための応答データパケットを記憶すると、制御ロジック６６は、トランザクションのソースノード、ソースユニット、およびソースタグを、それぞれソースノードフィールド８４、ソースユニットフィールド８８、およびソースタグフィールド８２に記憶し得る。ソースノード、ソースユニット、およびソースタグは未処理のトランザクションを一意に識別し、ソースノード、ソースユニット、およびソースタグは、未処理のトランザクションに対応する応答パケットによって搬送されるため、トランザクションの応答パケット（および対応するデータパケット）は、制御ロジック６６によって識別され得、データパケットは、割振られるエントリへと記憶され得る。たとえば、応答データパケットを特定する応答パケットが受信されると、応答パケットのソースノード、ソースユニット、およびソースタグは、ソースノードフィールド８４、ソースユニットフィールド８８、およびソースタグフィールド８４と比較されて応答データのために以前に割振られたデータバッファプール場所８０が決定され得る。応答データは次に、応答データバッファから、割振られたデータバッファプール場所８０のデータフィールド８６へとコピーされ得る。例示的な実施例では、データフィールド８６はデータのキャッシュブロックを含み得る。
【００９５】
次に図１３を参照して、応答カウンタプール７０内に存在し得る応答カウンタ９０の例示的な実施例を例示する図が示される。他の実施例も可能であり、企図される。図１３の実施例では、応答カウンタ９０は、ソースタグフィールド９２、ソースノードフィールド９４、ソースユニットフィールド９５、応答カウントフィールド９６、および受信状態フィールド９８を含む。
【００９６】
制御ロジック６６が応答カウンタ９０を割振ってトランザクションのための応答カウントを記憶すると、制御ロジック６６は、トランザクションのソースノード、ソースユニット、およびソースタグを、それぞれソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２に記憶し得る。ソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２は、データバッファプール場所８０の対応するフィールド８４、８８、および８２と同様の様態で用いられ得る。
【００９７】
応答カウントフィールド９６は、トランザクションへの割振り時に、そのトランザクションに対して予期される応答数に初期設定され得る。フィールド９４、９５、および９２にそれぞれ記憶されるソースノード、ソースユニット、およびソースタグを有する応答パケットが受信されると、応答カウントは減分され得る。応答カウントが０に達するとき、全応答が受信されており、トランザクションはコミットされ得る。代替的には、カウントは０に初期設定されてもよく、予期される応答数が受信されるまで、応答パケットは応答カウントの増分を引き起こし得る。
【００９８】
受信状態フィールド９８を用いて、データが受信され得る状態が示され得る。状態は、キャッシュブロックへのアクセス権と、キャッシュブロックを受信したときにノード１２Ａが必要とした、キャッシュブロックのためのコヒーレンシーを維持するための応答性（ｒｅｓｐｏｎｓｉｂｉｌｉｔｉｅｓ）とを示す。例示的な実施例では、ＭＯＥＳＩ（修正、所有、排他、共有、および無効）コヒーレンシー状態が用いられ得、受信状態フィールド９８は、サポートされる状態のうちの１つにエンコードされ得る。代替的には、他のいずれかの好適な組のコヒーレンシー状態が用いられてもよい（たとえば、ＭＥＳＩ状態）。受信状態フィールド９８は、トランザクションによって転送されているキャッシュブロックのコピーを他のノードが有さない状態に対応する状態に初期設定され得る。応答が受信されると、受信状態フィールドが更新され得る。たとえば、キャッシュブロックのコピーがプローブされたノードによって維持されていること、またはダーティデータに応答が提供されていることをプローブ応答が示すと、受信状態フィールド９８はそれに応じて更新され得る。ある実施例では、共有ビットはプローブ応答パケット内に含まれて、キャッシュブロックのコピーが、プローブ応答を提供しているプローブされたノードによって維持されていることが示され得る。加えて、プローブされたノードからリード応答パケットを受信することによって、ノードがキャッシュブロックのダーティコピーを有したことが示され得る。リード応答パケットはまた共有ビットを含んでキャッシュブロックのコピーが、プローブされたノードによって維持されているかが示され得る。
【００９９】
リソースを割振るためにデータバッファプール６８および応答カウンタプール７０を実現することは、単なる例示にすぎず、未処理のトランザクションのための応答を処理するためのリソースの割振りは、他の様態で実現され得ることが注目される。たとえば、未処理のトランザクションのテーブルが維持され得る。テーブルは、全応答が受信されたのかを制御ロジック６６が判断することを可能にする上述または同等の情報と同様のソースノード、ソースユニット、ソースタグ、データ、受信状態、および応答カウントを含み得る。
【０１００】
図１４を参照して、パケット受信のための例示的なパケット処理ロジック５８の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図１４で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック５８内で組合せ論理を用いて並列に行なわれてもよい。図１４で例示されるステップは、各インターフェイスロジック１８Ａ−１８Ｃに対して、独立して、さらには並列に行なわれ得る。なぜならば、ビット時間は、各インターフェイスロジックから並行に受信され得るためである。
【０１０１】
図１４で例示される実施例は、一連のビット時間としてパケット処理ロジック５８へのパケットを受信する。他の実施例は、インターフェイスロジック１８Ａ−１８Ｃ内でパケットのビット時間を蓄積し、完全なパケットをパケット処理ロジック５８に提供し、この場合には、ビット時間でのパケットの受信を管理することに関連したステップは、省略され得る。図１４で例示される実施例では、ビット時間が受信されると、パケット処理ロジック５８は、受信されたビット時間がデータパケットまたはコマンドパケットの一部であるかを示すインターフェイスロジックからの信号を受信する。ビット時間がデータパケットビット時間ならば（判定ブロック１００）、ビット時間は、そのインターフェイスロジックに対応するデータパケットアクティブレジスタによって示される割振られたバッファ場所内のデータバッファに記憶される（ステップ１０２）。データパケットビット時間がデータパケットの最後のビット時間ならば、制御ロジック６６は、対応するデータパケットアクティブレジスタを無効化し得る。
【０１０２】
しかし、ビット時間がコマンドパケットビット時間ならば、パケット処理ロジック５８は、コマンドパケットが現在受信されている最中にあるのかを（たとえば、コマンドパケットアクティブレジスタが有効であるのかを）判断する（判定ブロック１０４）。コマンドパケットが現在進行中ならば、ビット時間は、コマンドパケットアクティブレジスタによって示されるコマンドパケットバッファに記憶される（ステップ１０６）。コマンドパケットビット時間がパケットの最後のビット時間ならば、制御ロジック６６は、対応するコマンドパケットアクティブレジスタを無効化し得る。
【０１０３】
コマンドパケットが現在進行中でないならば、パケット処理ロジック５８は、新しく受信されるパケットのコマンドフィールドをデコードして、パケットが割当てられるバーチャルチャネルを識別する（ステップ１０８）。識別されたバーチャルチャネルに対応するコマンドパケットバッファ場所が割振られ、コマンドパケットビット時間が、割振られたコマンドパケットバッファ場所に記憶される。
【０１０４】
加えて、パケット処理ロジック５８は、コマンドパケットが後続のデータパケットを特定するかを判断する（判定ブロック１１０）。データパケットが特定されると、パケット処理ロジック５８は、識別されたバーチャルチャネルに対応するデータバッファからのデータバッファ場所を割当て、データパケットアクティブレジスタを更新して、割当てられたデータバッファおよびデータバッファ場所を示す（ステップ１１２）。
【０１０５】
次に図１５を参照して、リクエストパケット（たとえば、ノンポステッドリクエストパケットまたはポステッドリクエストパケットのいずれか）を処理するための例示的なパケット処理ロジック５８の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図１５で示されるステップは、わかりやすくするためにある特定の順序で示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック５８内で組合せ論理を用いて並列に行なわれてもよい。図１５で示されるステップは、各インターフェイスロジック１８Ａ−１８Ｃおよび／または各コマンドパケットバッファに対して、独立して、さらには並列に行なわれ得る。なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのリクエストパケットは、物理的に独立しているためである。代替的には、１つのリクエストパケット（または、インターフェイスロジック１８Ａ−１８Ｃにつき１つのリクエストパケット）が、好適な公平性アルゴリズムに従って処理のために選択され得る。一般に、処理のために１つのバーチャルチャネルから選択されるパケットは、バーチャルチャネル内のパケットの順序付けルールに従うが（たとえば、同じソースから同じデスティネーションへのパケットが順番に選択される）、順序付けルールが順序から外れた選択を許容するならば、所望であれば、パケットは順序付けから外れて処理のために選択されてもよい。
【０１０６】
図１５で例示されるように、パケット処理ロジック５８は、リクエストパケットのターゲットが「このノード」であるかを判断する（判定ブロック１２６）。たとえば、パケット処理ロジック５８は、リクエストパケットのデスティネーションノード（ＤｅｓｔＮｏｄｅ）フィールド内に記録されるデスティネーションノードＩＤを、ノードＩＤレジスタ７２に記憶されるノードＩＤと比較し得る。ノードＩＤが整合すると、リクエストは「このノード」をターゲットとしている。リクエストが「このノード」をターゲットとしないならば、パケット処理ロジック５８は、リクエストパケット（および、特定するならば、対応するデータパケット）を適切なデスティネーションノードへと送り得る（ステップ１２８）。たとえば、パケット処理ロジック５８は、どのインターフェイスロジック１８Ａ−１８Ｃが、パケットをある特定のデスティネーションノードに送るための送信インターフェイスであるのかを識別するパケットルーティングテーブルを維持し得る。次に、対応するコマンドバッファ（および、データパケットが特定されるならば、データバッファ）が、パケットルーティングテーブルによって特定されるリンクに結合される受信ノード内で利用可能であることがロジック５８によって判断されたならば、パケット処理ロジック５８は、識別されるインターフェイスロジック１８を介してリクエストパケットをデスティネーションノードに送る。ある特定の実施例では、リクエストパケットがデータパケットを特定すると、ロジック５８は、ロジック５８が特定されたデータパケットを受信するまで、リクエストパケットの送信を遅延し得る。
【０１０７】
リクエストパケットが「このノード」をターゲットとするならば、パケット処理ロジック５８は、リクエストパケット（および、適切ならば、対応するデータパケット）をメモリコントローラ１６Ａに提供し得る（ステップ１３０）。一旦リクエストパケットが処理されると（つまり、送信されるか、または「このノード」によって受入れられると）、リクエストパケットはコマンドバッファから除去され、対応するいずれかのデータがコマンドデータバッファから除去されることが注目される。
【０１０８】
プローブリクエストも同様の態様で処理され得ることが注目される。しかし、プローブリクエストは対応するデータパケットを有さないため、データパケットのためのチェックは省略され得る。さらに、プローブリクエストはブロードキャストパケットであり得るため、プローブリクエストは、（たとえば、ノード内でキャッシュをプローブすることによって）内部で処理もされ、送信もされ得る。プローブされるノードは、「このノード」または別のノードにかかわらず、キャッシュのプローブ後、プローブ応答パケットを生成し、送信し得る。
【０１０９】
選択されるリクエストパケットが対応するデータパケットを特定するならば、さまざまな実施例は、たとえデータパケットが受信されていない場合でもリクエストパケットを処理し得ることが注目される。代替的には、ノードは、データパケットの到着を待ってデータ送信を簡素化し得るか、または完全に受信されたデータパケットを特定する別のパケットが同じリンク上で送信されることを可能にし得る。リクエストパケットが処理されるときにデータパケットが受信されていない場合、データパケットは、データパケットが最終的に受信されるときに図１４に関して上で説明されたように処理され得る。
【０１１０】
次に図１６を参照して、応答パケットを処理するための例示的なパケット処理ロジック５８の一部の動作を示すフローチャートが図示される。他の実施例も可能であり、企図される。わかりやすくするために、図１６で示されるステップは、ある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック５８内で組合せ論理を用いて並列に行なわれ得る。図１６で例示されるステップは、各インターフェイスロジック１８Ａ−１８Ｃおよび／または各応答パケットバッファに対して、独立して、さらには並列に行なわれ得る。なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのパケットは、物理的に独立しているためである。
【０１１１】
図１６で示されるように、パケット処理ロジック５８は、上で説明されたものと実質的に同じ様態で、応答パケットのデスティネーションノードが「このノード」であるかを判断する（判定ブロック１４４）。デスティネーションノードが別のノードならば、パケット処理ロジック５８は応答パケット（および、適切ならば、対応するデータパケット）を送信するが、以上は、応答パケットが送信されるリンク上のレシーバノード内の応答バーチャルチャネルのための自由バッファ場所が利用可能な場合に、行なわれる（ステップ１４６）。
【０１１２】
応答パケットのデスティネーションが「このノード」ならば、パケット処理ロジック５８は、対応する応答カウンタを減分し、（応答が、受信される状態がデフォルト状態から変更されるべきであると示すプローブ応答ならば）受信された状態を更新する（ステップ１４８）。加えて、応答パケットがデータパケットを特定するならば、データパケットは、対応する応答データバッファから、その応答に割振られるデータバッファへと移動させられる（ステップ１５０）。
【０１１３】
カウンタの減分後、パケット処理ロジックは、カウンタをテストしてすべての応答パケットが受信および処理されたかを判断し得る（判定ブロック１５２）。すべての応答パケットが受信および処理されたと判断されると、パケット処理ロジック５８は、メモリコントローラ１６Ａまたはキャッシュ５０および５４に、それらがトランザクションを完了してもよいことを知らせ、データバッファからの関連データおよび応答カウンタからの受信状態を（適切ならば）提供し得る（ステップ１５４）。一旦応答パケットが処理されると（つまり、送信されるか、または「このノード」によって受入れられると）、応答パケットは応答バッファから除去され、対応するいずれかの応答データが応答データバッファから除去されることが注目される。
【０１１４】
ある特定の実施例では、選択される応答パケットが対応するデータパケットを特定するならば、応答パケットは、たとえデータパケットが受信されていない場合にも（つまり、データパケットがデータバッファ内に存在しない場合にも）処理され得、または応答パケット処理は、データパケットの到着を待ってデータ送信を簡素化するか、または完全に受信されたデータパケットを特定する別のパケットが同じリンク上で送信されることを可能にし得ることが注目される。応答パケットが処理されるときにデータパケットが受信されていないならば、データパケットは、データパケットが最終的に受信されるときに図１４に関して上で説明されたように処理され得る。
【０１１５】
次に図１７を参照して、ノードが結合される通信リンク上でパケットを開始するための例示的なパケット処理ロジック５８の一部の動作を示すフローチャートが図示される。他の実施例も可能であり、企図される。わかりやすくするために、図１７で示されるステップはある特定の順序で示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック５８内で組合せ論理を用いて並列に行なわれてもよい。パケット処理ロジック５８は、プロセッサコア５２および５６が実行する動作および／またはキャッシュ５０および５４からのフィルリクエスト／犠牲ブロックに応答して、リンク上でパケットを開始し得る。加えて、プローブパケットは、処理のためにメモリ動作を選択するメモリコントローラ１６Ａに応答して開始され得る。応答パケットは、プローブが処理された後、および、「このノード」から来ているか、または「このノード」をターゲットとしたトランザクションの完了に応答して、開始され得る。
【０１１６】
図１２で示されるように、パケット処理ロジック５８は、開始されるべきパケットによって結果として、データがこのノードに戻され得るのかを判断する（判定ブロック１６０）。たとえば、ノードが開始するリードトランザクションによって、データはノードに戻されるが、ノードが開始するライトトランザクションによっては、データはノードに戻されない。ＣｈａｎｇｅｔｏＤｉｒｔｙトランザクションによって結果として、（別のノードが影響を及ぼされるキャッシュブロックをダーティ状態で有するならば）データはノードに戻され得る。同様に、別のノードが影響を及ぼされるキャッシュブロックをダーティ状態で有し、さらにはプローブ応答がこのノードに向けられるべきならば、プローブパケットによってデータはこのノードに戻され得る。トランザクションによって結果として、データがこのノードに戻され得るならば、パケット処理ロジック５８は、データバッファプール６８からデータバッファを割り振る（ステップ１６２）。
【０１１７】
加えて、パケット処理ロジック５８は、パケットに応答してプローブ応答がこのノードに戻されるかを判断する（ステップ１６６）。パケットがプローブであるならば、またはパケットがトランザクションを開始して結果として「このノード」へのプローブ応答（たとえば、リードトランザクション）が得られるならば、プローブ応答のリターンが生じ得る。プローブ応答が「このノード」に戻されるならば、パケット処理ロジック５８は、受信される応答を数えるための応答カウンタをトランザクションに割振り、応答カウンタを予期される応答数（たとえば、コヒーレントファブリック内のノード数）に初期設定する（ステップ１６８）。
【０１１８】
パケット処理ロジック５８はさらに、パケットが開始されていることに応答して、他の応答がこのノードに戻されるか（たとえば、ＳｒｃＤｏｎｅ、ＴｇｔＤｏｎｅ等）を判断する（ステップ１６４）。このような他の応答が戻されるならば、パケット処理ロジック５８は、応答カウンタを割振り、初期カウントを、たとえば、１または他のいずれかの適切な開始カウントに設定する（ステップ１６５）。後に、パケット処理ロジック５８はパケットを送信する（ステップ１７０）。
【０１１９】
トランザクションを開始する前にリソースを予め割振って（データを含む）応答パケットを処理することによって、応答パケットは、受信時に処理され得る。したがって、たとえいくつかの応答パケットが他の応答パケットとの論理／プロトコル競合を有し得る場合でさえも、応答パケットは、応答バーチャルチャネルに併合され得る。なぜならば、物理的な競合は、各応答パケットを受信時にそのディスティネーションノードで処理することによって、除去されるためである。
【０１２０】
次に、図１８を参照して、バッファリリースフィールドを含む情報パケット１８０の１つの実施例を例示するブロック図が示される。他の実施例も可能であり、企図される。図１８で示される例示的な実施例では、バッファリリースフィールドは、各バッファタイプに対して含まれる。ＲｅｓｐＤａｔａフィールドは、応答データバッファに対応し、応答フィールドは、応答バッファに対応する。同様に、ＰｏｓｔＣｍｄＤａｔａフィールドは、ポステッドコマンドデータバッファに対応し、ＰｏｓｔＣｍｄフィールドは、ポステッドコマンドバッファに対応する。ＮｏｎＰｏｓｔＤａｔａフィールドは、ノンポステッドコマンドデータバッファに対応し、ＮｏｎＰｏｓｔＣｍｄフィールドは、ノンポステッドコマンドバッファに対応する。プローブフィールドは、プローブバッファに対応する。
【０１２１】
バッファリリースフィールドの各々は、２つのビットを含み、トランスミッタからある特定の通信リンク上のレシーバまでの単一の情報パケット１８０の送信によって、最大３つの、各タイプのバッファ場所のリリースまたは解放が可能となる。３つよりも多い、ある特定のタイプのバッファ場所が提供されると、所望ならば、さらなる情報パケットを用いてさらなるバッファ場所が解放され得る。パケット処理ロジック５８は、バッファの各タイプおよび各インターフェイスロジック１８Ａ−１８Ｃのためのバッファカウントを含み得、各インターフェイスが結合されるリンクの他端上のレシーバによって提供される各タイプのバッファのトータル数を示し得る。これらのカウンタは、バッファリリースフィールドがレシーバ内で利用可能なバッファ場所の数に設定された状態で、情報パケットをそのレシーバからトランスミッタへと送信することによって、電源投入時に初期設定され得る。レシーバが、３つよりも多い、ある特定のタイプのバッファ場所を有するならば、多数の情報パケットが送信され得る。
【０１２２】
パケット処理ロジック５８は、対応するタイプのバッファ（および、パケットがデータパケットを特定するならば、データバッファ）が、パケットが送信されているレシーバ内で利用可能である限り、ある特定のバーチャルチャネル内でパケットを送信し得る。加えて、パケット処理ロジック５８は、パケット処理ロジック５８によるパケットの処理の結果としてノード１２Ａ内で解放された各インターフェイス１８Ａ−１８Ｃのための各タイプのバッファ場所の数を表わす。定期的に、パケット処理ロジック５８は、各インターフェイスロジック１８Ａ−１８Ｃを介して情報パケット１８０を送信し、それぞれの通信リンク上のトランスミッタに対して、パケット処理ロジック５８によって解放されたバッファ場所の数を示す。
【０１２３】
バーチャルチャネル−ノンコヒーレントファブリック
次に図１９を参照して、Ｉ／Ｏサブシステム２００の１つの実施例のブロック図が示される。他の実施例も可能であり、企図される。図１９の実施例では、Ｉ／Ｏサブシステム２００は、ホストブリッジ２０２、複数のＩ／Ｏノード２０４Ａ、２０４Ｂ、および２０４Ｃを含む。ホストブリッジ２０２は、ライン２４Ｉ−２４Ｊを含むコヒーレントリンクを介して処理ノード１２Ｄに結合され、さらにライン２４Ｋ−２４Ｌを含むノンコヒーレントリンクを介してＩ／Ｏノード２０４Ａに結合される。Ｉ／Ｏノード２０４Ａ−２０４Ｃは、デイジーチェーン構成で追加的なノンコヒーレントリンクを介して（ライン２４Ｎ−２４Ｏ）相互接続される。ホストブリッジ２０２は処理ノード１２から離れて示されているが、ホストブリッジ２０２は、所望ならば、処理ノードと一体化されてもよいことが注目される。
【０１２４】
一般に、ホストブリッジ２０２は、Ｉ／Ｏサブシステムと処理ノードとの間で移動するパケットを変換する。たとえば、Ｉ／Ｏノード２０４Ｂによって送信され、かつ処理ノード１２Ａ内にターゲットを有するノンコヒーレントパケットは、Ｉ／Ｏノード２０４Ａを通ってホストブリッジ２０２へと進む。ホストブリッジ２０２は、ノンコヒーレントパケットを対応するコヒーレントパケットに変換する。
【０１２５】
一般に、Ｉ／Ｏノード２０４Ａ−２０４Ｃは、Ｉ／Ｏサブシステム２００内でトランザクションを開始し得る。トランザクションは最終的に、別のＩ／Ｏノード２０４Ａ−２０４Ｃ、別のノンコヒーレントリンク上のＩ／Ｏノード、またはメモリ１４をターゲットとし得る。簡素化のために、トランザクションは、実際のターゲットにかかわらず、ホストブリッジ２０２とＩ／Ｏノード２０４Ａ−２０４Ｃとの間で行なわれ得る。たとえば、ホストブリッジ２０２は、処理ノード１２Ａ−１２Ｄからのリクエストの代わりに、Ｉ／Ｏサブシステム２００内でトランザクションを開始し得、コンピュータシステム内のコヒーレントファブリックまたは別のホストブリッジをターゲットとするＩ／Ｏノード２０４Ａ−２０４Ｃによって開始されるトランザクションを処理し得る。
【０１２６】
Ｉ／Ｏサブシステム２００内のパケットはＩ／Ｏストリーム内を伝わるが、これらは、ノンコヒーレントファブリックによって独立して取り扱われ得るトラフィックの集約（ｇｒｏｕｐｉｎｇｓ）である。例示的な実施例では、ピアツーピア通信は、ノンコヒーレントファブリック内に存在せず、すべてのパケットは、ホストブリッジ２０２へと、またはホストブリッジ２０２から移動し得る。したがって、Ｉ／Ｏノード２０４Ａ−２０４Ｃによって送信されるパケットは、デイジーチェーン接続を通してホストブリッジ２０２へと（つまり、「アップストリームに」）流され得る。Ｉ／Ｏノード２０４Ａ−２０４Ｃによって発行されるリクエストパケットは、ソースノードのＵｎｉｔＩＤを含むことが注目される。同様に、Ｉ／Ｏノード２０４Ａ−２０４Ｃによって発行される応答パケットは、応答を生成したノードのＵｎｉｔＩＤを含む。したがって、ＵｎｉｔＩＤを用いてアップストリームパケットのためのＩ／Ｏストリームが識別され得る。
【０１２７】
ホストブリッジ２０２によって送信されるパケットは、受信Ｉ／Ｏノード２０４Ａ−２０４Ｃへと（つまり、「ダウンストリームに」）流され得る。例示的な実施例では、ダウンストリーム応答は、応答が送信されているノードのＵｎｉｔＩＤを含み、ダウンストリームリクエストは、ＵｎｉｔＩＤのために０の値を有し、これは、ホストブリッジ２０２のためにリザーブされるエンコーディングであることが注目されるべきである。したがって、独立したＩ／Ｏストリームは、ダウンストリームリクエストトラフィック内で認識できないかもしれず、すべてのダウンストリームトラフィック（リクエストと応答との両方）が同じＩ／Ｏストリーム内にあると仮定され得る。
【０１２８】
ファブリック上のすべてのデバイスは、それらのホストブリッジの方向を「アップストリーム」と認識するようにプログラムされる。デイジーチェーン内でＩ／Ｏノードおよびホストブリッジを相互接続し、さらにはＩ／Ｏノードに（トランザクションレベルで）ホストブリッジのみと通信させることによって、Ｉ／Ｏノードが他のノードではなくホストブリッジに直接接続されているように見えるＩ／Ｏサブシステム２００の論理ビューが提供される。
【０１２９】
Ｉ／Ｏサブシステム２００はデイジーチェーン相互接続の両端上でホストブリッジに接続されてリンク故障時の頑強性に備えてもよく、または処理ノードのクラスタ間での共有Ｉ／Ｏサブシステムを可能にしてもよい。デイジーチェーンの第１の端部でのブリッジは、マスタブリッジとして指定され、他端でのブリッジは、スレーブブリッジとして指定され得る。例示的な実施例では、サブシステム内のすべてのＩ／Ｏノードがマスタブリッジに属する。リンク故障が検出されると、故障部分の両側のＩ／Ｏノードは再びプログラムされて故障部分のそれぞれの側のホストブリッジに属するようにされる。したがって、２つのＩ／Ｏサブシステムが形成され、処理サブシステム内の処理ノードとの通信が維持され得る。代替的な実施例では、Ｉ／Ｏノードは、たとえリンク故障が生じていなくても、Ｉ／Ｏサブシステム内の２つのホストブリッジ間で割当てられ得る。このような構成は、通信トラフィックのバランスを取る助けとなり得る。
【０１３０】
パケットがデイジーチェーンの端部（たとえば、図１９の例のＩ／Ｏノード２０４Ｃ）に到達し、さらにはＩ／Ｏノード２０４Ａ−２０４Ｃがパケットを受入れなかった場合、Ｉ／Ｏノードによってチェーンの端部でエラーが生成され得る。
【０１３１】
一般に、Ｉ／Ｏサブシステム２００は、ノンコヒーレント相互接続としてリンク２４Ｋ−２４Ｐを実現する。例示的な実施例では、ノンコヒーレントリンクのためのデータパケット定義は、コヒーレントリンクのためのデータパケット定義に関して図６で図示され、説明されたものと同様である。同様に、ノンコヒーレントリンクのための情報パケット定義は、（プローブフィールドがリザーブされている）図３および図１８で示されたコヒーレント情報パケット定義と同様であり得る。ノンコヒーレントリンクのためのリクエストおよび応答パケット定義は、図２１および図２２で例示され、以下で説明される。
【０１３２】
例示的な実施例では、コヒーレントリンクに関して上で説明されたバーチャルチャネル定義は、ノンコヒーレントリンクにも適用可能である。バーチャルチャネル定義およびそれらのそれぞれの適用可能なリンクは、図９で示される。プローブリクエストはノンコヒーレントリンク上で用いられないかもしれず、したがって、プローブバーチャルチャネルは、ノンコヒーレントリンクのために除去され得ることが注目される。
【０１３３】
次に図２０を参照して、コンピュータシステム１０内のノンコヒーレントリンクの１つの例示的な実施例に従って採用されるパケットを例示した表２１０が示される。好適な他のいずれかのパケットセットおよびコマンドフィールドエンコーディングを含んだ他の実施例も可能であり、企図される。表２１０は、各コマンドに割当てられるコマンドエンコーディングを例示したコマンドコード（ＣＭＤ）列と、ノンコヒーレントパケットの各々が割当てられるバーチャルチャネルを規定するバーチャルチャネル（Ｖｃｈａｎ）列と、コマンドを示すニーモニックを含むコマンド（Ｃｏｍｍａｎｄ）列と、パケット３０、２１２、および２１４（ならびに、特定される場合には、データパケット３６）のうちのどれが対応するコマンドのために採用されるのかを示すパケットタイプ（Ｐａｃｋｅｔ Ｔｙｐｅ）列とを含む。
【０１３４】
表２１０で示されるように、ノンコヒーレントパケットは、ＮＯＰ、Ｗｒ（サイズド）、リード（サイズド）、ＲｄＲｅｓｐｏｎｓｅ、ＴｇｔＤｏｎｅ、ブロードキャスト、および同期（Ｓｙｎｃ）パケットを含み、これらは、例示的な実施例では、図７に関して説明された対応のコヒーレントパケットと同様である。しかし、ノンコヒーレントリンク内では、プローブパケットもプローブ応答パケットも発行されないことが注目される。コヒーレントリンクに関して上で説明されたように、ポステッドライトリクエストは、Ｗｒ（サイズド）リクエストパケットのポステッドビットを設定することによって、識別され得る。しかし、ノンコヒーレントファブリックでは、セットポステッドビットは、バーチャルチャネル識別子として働くだけではなく、ライトリクエストがファブリック内で応答を受信しないことも示す。つまり、コヒーレントファブリックとは異なり、ＴｇｔＤｏｎｅ応答パケットは、ポステッドライトリクエストに応答してノンコヒーレントファブリック内で発行されない。
【０１３５】
ノンコヒーレントパケットはまた、フラッシュ（Ｆｌｕｓｈ）およびフェンスリクエストパケットを含み、これらは、以下でさらに詳細に説明される。
【０１３６】
次に図２１を参照して、ノンコヒーレントリンク内で採用され得るリクエストパケット２１２の１つの実施例のブロック図が示される。リクエストパケット２１２は、コヒーレントリクエストパケットと同様のコマンドフィールド（ＣＭＤ［５：０］）を含む。さらに、任意のソースタグフィールド（ＳｒｃＴａｇ［４：０］）は、コヒーレントリクエストパケットと同様に、ビット時間２内に含まれ得る。アドレス（Ａｄｄｒ［１５：８］、Ａｄｄｒ［２３：１６］、Ａｄｄｒ［３１：２４］、Ａｄｄｒ［３９：３２］）は、ビット時間４−７内に（任意で、最下位アドレスビットについてはビット時間３内に）含まれる。
【０１３７】
リクエストパケット２１２はさらに、（コヒーレント片われ（ｃｏｕｎｔｅｒｐａｒｔ）パケットのソースノードＩＤではなく）ビット時間１内にユニットＩＤ（ＵｎｉｔＩＤ［４：０］）を含む。ユニットＩＤは、パケットの論理ソースを識別する。たとえば、ノードが論理的に別の（ｓｅｐａｒａｔｅ）多数のデバイスまたは機能を含むならば、Ｉ／Ｏノードは多数のユニットＩＤを有し得る。したがって、Ｉ／Ｏノードは、異なるユニットＩＤを有するパケットを生成し、受け入れ得る。１つの実施例では、ユニットＩＤは５つのビットを含み得る。したがって、ユニットＩＤ０がホストブリッジに割当てられ、ユニットＩＤ３１が用いられてエラーが報告されると、最大３０のユニットＩＤが、１つのデイジーチェーン構成のＩ／Ｏサブシステム内で結合されるＩ／Ｏノード内に存在し得る。
【０１３８】
加えて、リクエストパケット２１２は、ビット時間０および１内にシーケンスＩＤ（ＳｅｑＩＤ［３：０］）フィールドを含む。ＳｅｑＩＤフィールドを用いて、同じバーチャルチャネル内で移動しており、かつ同じユニットＩＤを有する２つ以上のリクエストパケットのセットがグループ分けされ、順序付けられ得る。たとえば、ＳｅｑＩＤフィールドが０ならば、パケットは、他のパケットに対して順序付けされない。しかし、ＳｅｑＩＤフィールドが０ではない値を有すると、パケットは、同じＵｎｉｔＩＤおよびＳｅｑＩＤフィールド内で整合する値を有する同じチャネル内の他のパケットに対して順序付けられる。
【０１３９】
さらに、リクエストパケット２１２は、ビット時間１内でパスポステッドライト（ＰａｓｓＰＷ）ビットを含む。ＰａｓｓＰＷビットは、リクエストパケット２１２が、同じユニットＩＤから送信されるポステッドライトリクエストを渡すことができるかを示す。例示的な実施例では、ＰａｓｓＰＷビットがクリアならば、パケットは、以前に送信されたポステッドライトリクエストパケットを渡すことはできない。ＰａｓｓＰＷビットがセットされていると、パケットは、前のポステッドライトパケットを渡すことができる。リードリクエストパケットについては、コマンドフィールドは、リード応答がポステッドライトリクエストを渡し得るかを示す状態を有するビットを含み得る。そのビットの状態は、リードリクエストパケットに対応する応答パケット内のＰａｓｓＰＷビットの状態を決定する。
【０１４０】
上述のように、ノンコヒーレントリクエストパケットは、フラッシュおよびフェンスリクエストを含む。フラッシュリクエストは、ソースノードによって用いられて１つ以上の以前に発行された、ポステッドライトがホストメモリで観察されたことが保証され得る。フラッシュは、フラッシュと同じＩ／Ｏストリーム内のリクエストにのみ適用され、アップストリーム方向に発行され得るのみである。その意図される機能を実行するために、フラッシュリクエストは、ノンポステッドコマンドバーチャルチャネル内を進み、ポステッドコマンドチャネル内のすべてのリクエストをその先に（たとえば、以下で説明されるＰａｓｓＰＷビットを介して）プッシュする。したがって、フラッシュリクエストの発行および対応するＴｇｔＤｏｎｅ応答パケットの受信によって、以前のポステッドリクエストがコヒーレントファブリック内のそれらのデスティネーションにフラッシュされたことをソースノードが判断することが可能となる。
【０１４１】
フェンスリクエストは、Ｉ／Ｏシステム内のすべてのＵｎｉｔＩＤ中に適用されるポステッドライト間でバリアを提供する。フェンスリクエストは、アップストリーム方向にのみ発行され得、ポステッドコマンドバーチャルチャネル内を進む。その意図される機能を実行するために、フェンスリクエストは、ポステッドコマンドチャネル内のすべてのポステッドリクエストをその先にプッシュする。たとえば、ＰａｓｓＰＷビットがクリアならば、フェンスパケットは、パケットのＵｎｉｔＩＤにかかわらず、ポステッドチャネル内のいずれのパケットも渡さない。ＰａｓｓＰＷビットクリアを有する他のパケットは、ＵｎｉｔＩＤにかかわらず、フェンスパケットを渡さない。
【０１４２】
次に図２２を参照して、ノンコヒーレントリンク内で採用され得る応答パケット２１４の１つの実施例のブロック図が示される。応答パケット２１４は、リクエストパケット２１２と同様のコマンド（ＣＭＤ［５：０］）フィールド、ユニットＩＤ（ＵｎｉｔＩＤ［４：０］）フィールド、ソースタグ（ＳｒｃＴａｇ［４：０］）フィールド、およびＰａｓｓＰＷビットを含む。しかし、他のフィールドおよびビットも所望であれば含まれ得ることが理解されるべきである。
【０１４３】
次に図２３を参照して、Ｉ／Ｏノード２０４Ａの１つの実施例を例示するブロック図が示される。他のＩ／Ｏノード２０４Ｂ−２０４Ｃも同様に構成され得る。他の実施例も可能であり、企図される。図２３の実施例では、Ｉ／Ｏノード２０４Ａは、インターフェイスロジック１８Ｍおよび１８Ｎ、第１の組のパケットバッファ２２０、第２の組のパケットバッファ２２２、およびノードロジック２２４を含む。インターフェイスロジック１８Ｍは、ライン２４Ｋおよび２４Ｌ、パケットバッファ２２０、およびノードロジック２２４に結合される。インターフェイスロジック１８Ｎは、ライン２４Ｍおよび２４Ｎ、パケットバッファ２２２、およびノードロジック２２４に結合される。ノードロジック２２４はさらに、パケットバッファ２２０および２２２に結合される。
【０１４４】
インターフェイスロジック１８Ｍおよび１８Ｎは、（それぞれ）ライン２４Ｌおよび２４Ｍからパケットを受信し、（それぞれ）ライン２４Ｋおよび２４Ｎ上でパケットを送信するように構成される。コヒーレントリンクに関して上で説明されたインターフェイスロジックと同様に、インターフェイスロジック１８Ｍおよび１８Ｎは、受信されたパケットを制御経路およびデータ経路へと分離し得る。制御経路は、コマンドパケットバッファに結合され、データ経路は、データパケットバッファに結合される。代替的には、インターフェイスロジック１８Ｍおよび１８Ｎは、受信されたパケットを制御経路およびデータ経路へと分離しなくてもよく、代わりに、ノードロジック２２４が、各ビット時間に対応したＣＴＬ信号を受信し、それに従って分離を実行してもよい。コヒーレントインターフェイスと同様に、パケットバッファ２２０および２２２は、各々、ノンコヒーレントリンク内の各バーチャルチャネルのためのバッファを含む。つまり、バッファ２２０および２２２は、ノンコヒーレントリンク内で実現される３つのバーチャルチャネルに対応する、コマンドパケットのための応答バッファ（ＲＢ）、ノンポステッドコマンドバッファ（ＮＰＣＢ）、およびポステッドコマンドバッファ（ＰＣＢ）を含む。加えて、バッファ２２０および２２２は、各バーチャルチャネルのためのデータパケットバッファ（たとえば、ポステッドコマンドデータバッファ（ＰＣＤＢ）、ノンポステッドコマンドデータバッファ（ＮＰＣＤＢ）、および応答データバッファ（ＲＤＢ））を含む。
【０１４５】
ノードロジック２２４は、バッファ２２０および２２２で受信されるパケットを処理し得、Ｉ／Ｏノード２０４Ａによって実現された周辺機能に応答してパケットを開始し得る。図１１で示される制御ロジック６６と同様に、ノードロジック２２４は、（パケットバッファ２２０および２２２にそれぞれ対応する）コマンドパケットアクティブレジスタ２２６Ａおよび２２６Ｂ、さらには（パケットバッファ２２０および２２２にそれぞれ対応する）データパケットアクティブレジスタ２２８Ａおよび２２８Ｂを実現し得る。加えて、ノンコヒーレントリンク上の通信は、ノードＩＤではなくユニットＩＤに対応するため、ノードロジック２２４は、１つ以上のユニットＩＤレジスタ２３０Ａ−２３０Ｎを含んでＩ／Ｏノード２０４Ａに割当てられるユニットＩＤを記憶し得る。ユニットＩＤレジスタ２３０Ａ−２３０Ｎの数は、そのＩ／Ｏノード内で実現されるユニットＩＤの数に従って、ノードごとに異なり得る。
【０１４６】
異なるバーチャルチャネル内のパケットはＩ／Ｏノード２０４Ａ内の異なるバッファ内に記憶されるため、異なるバーチャルチャネル内のパケットは、物理的に互いと競合することはない。したがって、実質的にデッドロックのない動作が達成され得る。加えて、応答パケットが単一のバーチャルチャネルに併合され得るように、ノードロジック２２４は、リソースを予め割振って（コヒーレントリンクに関して上で説明されたように）応答パケットおよび応答データを処理し得る。
【０１４７】
ノードロジック２２４はさらに、Ｉ／Ｏノード２０４Ａによって行なわれる周辺機能または種々のＩ／Ｏに対応するロジックを含み得る。たとえば、Ｉ／Ｏノード２０４Ａは、ディスクドライブ、ＣＤ　ＲＯＭ、およびＤＶＤドライブ等の記憶周辺装置を含み得る。Ｉ／Ｏノード２０４Ａは、ＩＥＥＥ１３９４、イーサネット（Ｒ）、ユニバーサルシリアルバス（ＵＳＢ）、周辺コンポーネント相互接続（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）（ＰＣＩ）バス、およびモデム等の通信周辺装置を含み得る。好適ないずれかのＩ／Ｏ機能が、Ｉ／Ｏノード２０４Ａ内に含まれ得る。
【０１４８】
次に図２４を参照して、パケットを受信するための例示的なノードロジック２２４の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図２４で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序が用いられてもよい。加えて、ステップは、ノードロジック２２４内で組合せ論理を用いて並列に実行され得る。図２４で示されるステップは、各インターフェイスロジック１８Ｍ−１８Ｎに対して、独立して、さらには並列に行なわれ得る。なぜならば、ビット時間は、各インターフェイスロジックから並行に受信され得るためである。
【０１４９】
図２４で例示される実施例では、パケットは、一連のビット時間としてバッファ２２０および２２２で受信される。他の実施例は、インターフェイスロジック１８Ｍ−１８Ｎ内でパケットのビット時間を蓄積し、完全なパケットをバッファ２２０および２２２に提供し得るが、この場合、ビット時間でのパケットの受信を管理することに関連したステップは、省略され得る。図２４では、ステップ１００−１１２は、上で図１４に関して説明された対応するステップ１００−１１２と同じか、または同様であり得る。しかし、ノードロジック２２４は、図２４のステップ１１４および１１６によって部分的に例示されるような、特定の追加的な順序付けルールを実現し得る。特定のコマンドパケットは、同じソースノードから送信された、ポステッドリクエストパケットを「プッシュする」ように構成され得る。言換えると、プッシュされる、ポステッドリクエストパケットは、他のパケットがそれらのデスティネーションノードに到達する前に、デスティネーションノードに到着する。
【０１５０】
１つの実施例では、たとえば、（ＰａｓｓＰＷビットクリアを有すると定義される）フラッシュリクエストパケット、およびそれらのＰａｓｓＰＷビットクリアを有する他のパケットは、上述のように、ポステッドリクエストパケットをプッシュすると定義され得る。さらに、それらのＳｅｑＩＤフィールド内で０ではない値を有するリクエストパケットは、同じＩ／Ｏストリーム内にあり、さらにはそれらのそれぞれのＳｅｑＩＤフィールド内で整合した値を有する前のリクエストパケットをプッシュすると定義される。したがって、ＰａｓｓＰＷビットクリア、またはＳｅｑＩＤフィールド内の０ではない値を有するパケットが受信されると（判定ブロック１１４）、ノードロジック２２４は、ポステッドコマンドバッファおよびコマンドバーチャルチャネル内で前のリクエストパケットを探索し得る。たとえば、ノードロジック２２４は、クリアＰａｓｓＰＷビットを有するパケットと同じユニットＩＤを有する、ポステッドリクエストパケットを求めてポステッドコマンドバッファを探索し得る。さらに、ノードロジック２２４は、受信されるパケットのシーケンスＩＤに整合するＳｅｑＩＤフィールド内の０ではない値を有するリクエストパケットを求めてコマンドバーチャルチャネルを探索し得る。ノードロジック２２４が前のリクエストパケットを検出すると、前のリクエストパケットのソースタグ（ＳｒｃＴａｇ）がセーブされ得る。たとえば、前のリクエストパケットのＳｒｃＴａｇは、リクエストパケットに割振られる同じバッファ場所に記憶され得る（ステップ１１６）。ノードロジック２２４は、対応する前のリクエストパケットが処理されるまで、リクエストパケットの処理を差し控え得る。
【０１５１】
次に図２５を参照して、リクエストパケット（たとえば、ノンポステッドリクエストパケットまたはポステッドリクエストパケット）を処理するためのノードロジック２２４の１つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図２５で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、ノードロジック２２４内で組合せ論理を用いて並列に実行され得る。図２５で示されるステップは、各インターフェイスロジック１８Ｍ−１８Ｎおよび／または各コマンドパケットバッファに対して、独立して、さらには並列に実行され得る。なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのリクエストパケットは物理的に独立しているためである。代替的には、１つのリクエストパケット（または、インターフェイスロジック１８Ｍ−１８Ｎにつき１つのリクエストパケット）が、好適な公平性アルゴリズムに従った処理のために選択され得る。一般に、処理のために１つのバーチャルチャネルから選択されるパケットは、バーチャルチャネル内のパケットの順序付けルールに従うが（たとえば、同じソースから同じデスティネーションへのパケットが、順番に選択される）、所望であれば、さらには順序付けルールが順序付けから外れた選択を許容するならば、パケットは順序付けから外れて処理のために選択されてもよい。
【０１５２】
リクエストパケットがダウンストリームで流れるならば（ステップ１２５）、ノードロジック２２４は、リクエストパケット内のアドレスをデコードしてパケットが受入れられるベきかを判断する（ステップ１２６）。しかし、ダウンストリームリクエストパケットがブロードキャストならば（ステップ２４１）、ノードは、他の基準に関係なくパケットの受入れおよび送信の両方を行う。さらに、ノードロジック２２４は、リクエストパケットの処理の前に追加的なステップを実現し得る。たとえば、判定ブロック１２４では、ノードロジック２２４は、まだ処理されていない前のリクエストパケットをプッシュするようにリクエストパケットが構成されているかを判断する。上述のように、リクエストパケットが、受信され、さらには（たとえば、ＰａｓｓＰＷビットの状態またはＳｅｑＩＤフィールド内の０ではない値を介して）前のリクエストパケットをプッシュするように構成されているならば、プッシュされるべきリクエストパケットのソースタグ（ＳｒｃＴａｇ）が記録される。ノードロジック２２４は、プッシュするリクエストパケットに対応したソースタグ（およびユニットＩＤ）を求めてコマンドバッファをスキャンすることによって、前のリクエストパケットを探索し得る。ソースタグおよびユニットＩＤを有する、記憶されたリクエストパケットが見つかると、プッシュするリクエストパケットの処理は、前の記憶されたリクエストパケットが処理されるまで、中断され得る。
【０１５３】
加えて、ノードロジック２２４は、パケットルーティングテーブルに従ってではなく、同じ方向（アップストリームまたはダウンストリーム）でリクエストパケットを送信するように構成される（ステップ２４２）。パケットがアップストリームに流れていると、パケットが、「このノード」によって受入れられることは全くなく、代わりに、それがホストブリッジに到達するまで送信される。一旦パケットが処理されると（たとえば、「このノード」によって送信されるか、または受入れられると）、パケットは対応するバッファ場所から除去され、適切であれば、関連のデータパケットはデータバッファ場所から除去されることが注目される。
【０１５４】
選択されるリクエストパケットが対応するデータパケットを特定するならば、種々の実施例は、たとえデータパケットがまだ受信されていなくても、リクエストパケットを処理し得ることがさらに注目される。代替的には、完全なデータパケットの到着まで、処理が遅延されてもよく、したがって、データパケットの送信が簡素化されるか、または完全に到着したデータパケットを特定する別のパケットが同じ通信リンク上で送信されることが可能となる。リクエストパケットの処理が完全なデータパケットの到着を待たない状況では、データパケットは、データパケットが最終的に完全に受信されるときに、図２４に関して上で説明されたように処理され得る。
【０１５５】
次に図２６を参照して、応答パケットを処理するためのノードロジック２２４の１つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図２６で示されるステップは、わかりやすくするために、ある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、ノードロジック２２４内で組合せロジックを用いて並列に実行され得る。図２６で示されるステップは、各インターフェイスロジック１８Ｍ−１８Ｎおよび／または各応答パケットバッファに対して、独立して、さらには並列に実行され得る。なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのパケットは物理的に独立しているためである。
【０１５６】
パケットがダウンストリームに流れていると（ステップ２４９）、ノードロジック２２４は、応答パケットのＵｎｉｔＩＤフィールドおよびユニットＩＤレジスタ２３０Ａ−２３０Ｎ内に記録されるユニットＩＤを調べることによってパケットを受入れるべきかを判断する（ステップ１４４、これは、図１６の対応するステップ１４４と同様のものである）。上述のように、ダウンストリーム応答パケット内では、ＵｎｉｔＩＤは、応答の発行を生じさせた元のリクエストパケットのソースである。しかし、応答パケットがアップストリームに流れていると、パケットは受入れられず、代わりに、それがホストブリッジに到達するまで送信される。アップストリーム応答パケット内では、ＵｎｉｔＩＤは、リクエストのターゲットノード（つまり、応答を発行するノード）である。
【０１５７】
図２５のフローチャートと同様に、ノードロジック２２４は、応答パケットの処理の前に追加的なチェックを実現し得る。たとえば、判定ブロック１４０では、ノードブロック２２４は、応答パケットが、処理されていない前のリクエストパケットをプッシュするように構成されているかを判断する。上述のように、応答パケットが、受信され、さらには（たとえば、ＰａｓｓＰＷビットを介して）前のリクエストパケットをプッシュするように構成されていると、応答パケットが受信されるときにプッシュされるべきリクエストパケットのソースタグが記録される。ノードロジック２２４は、応答パケットに対応するソースタグ（およびユニットＩＤ）を有するリクエストパケットを求めてコマンドバッファをスキャンし得る。ソースタグおよびユニットＩＤを有する、記憶されたリクエストパケットが見つかると、応答パケットの処理は、前のリクエストパケットが処理されるまで、中断され得る。
【０１５８】
応答パケットのためのデスティネーションノードが別のノードならば、ノードロジック２２４は、応答パケット（および、適切ならば、対応するデータパケット）を、応答パケットが送信されているレシーバ内の応答バーチャルチャネルのための自由バッファ場所の利用可能性に従って送信する（ステップ２５０）。例示的な実施例では、レシーバは、パケットが既に流れていたのと同じ方向で（アップストリームまたはダウンストリームで）応答パケットが流れることを可能にするノードである。
【０１５９】
応答パケットのデスティネーションノードが「このノード」ならば、ノードロジック２２４は、存在するのであれば対応するデータパケットを、対応する応答データバッファから、応答パケットに割振られるデータバッファへと移動させるように構成される（ステップ２５２）。次に、ノードロジック２２４は、対応する応答パケットの処理を完了し、データバッファの割振りを解除する（ステップ２５４）。一旦応答パケットが処理されると（つまり、送信されるか、または「このノード」によって受入れられると）、応答パケットは応答バッファ場所から除去され、適切ならば、対応するデータパケットは、データバッファ場所から除去されることが注目される。
【０１６０】
選択される応答パケットが対応するデータパケットを特定するならば、種々の実施例は、たとえデータパケットがまだ受信されていなくても、応答パケットを処理し得ることが注目される。代替的には、処理は、データパケットの到着まで遅延されてもよく、したがって、データ送信が簡素化されるか、または完全に受信されるデータパケットを特定する別のパケットが同じリンク上で送信されることが可能となる。応答パケットの処理が遅延されていない状況では、対応するデータパケットは、データパケットが最終的に受信されるときに図２４に関して上で説明されたように処理され得る。
【０１６１】
次に図２７を参照して、ノードが結合されるリンク上でパケットを開始するためのノードロジック２２４の１つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図２７で示されるステップは、わかりやすくするために、ある特定の順序で例示されているが、好適ないずれの順序を用いてもよい。加えて、ステップは、ノードロジック２２４内で組合せ論理を用いて並列に実行され得る。
【０１６２】
図２７で示されるように、ノードロジック２２４は、開始されるべきトランザクションによって結果としてデータが「このノード」に戻され得るかを判断する（判定ブロック２６０）。たとえば、「このノード」によって開始されるリードトランザクションによって、データは「このノード」に戻されるが、「このノード」によって開始されるライトトランザクションによっては、データは「このノード」に戻されない。トランザクションによって結果としてデータが「このノード」に戻され得るならば、ノードロジック２２４は、データバッファを割振って戻されるデータを記憶する（ステップ２６２）。後に、ノードロジック２２４はパケットを送信する（ステップ２６４）。
【０１６３】
次に図２８を参照して、ノンコヒーレントファブリック内のある特定のユニットから受信される順序付けられたリクエストのペアに応答したホストブリッジ２０２の１つの実施例の動作を例示する表２７０が示される。コヒーレントファブリックそれ自体によって提供される唯一の順序付けルールは、同じソースから同じデスティネーションへと同じバーチャルチャネル内で進むパケットは、順序付けられて残されることが保証されることである。しかし、コヒーレントファブリックの分散性のために、コヒーレントファブリックに入るＩ／Ｏストリームは、多数のターゲット上で拡がり（ｓｐｒｅａｄ）得る。したがって、すべてのオブザーバーの観点からの順序付けを保証するためには、ホストブリッジは、コヒーレントファブリックへと新しいパケットを発行する前に、前のパケットに対する応答を待つ。この様態で、ホストブリッジは、順序付けを乱すことなく後続のパケットが発行されるのに十分なほど前のパケットがコヒーレントファブリック内を進んだことを判断し得る。
【０１６４】
ホストブリッジは、ノンコヒーレントファブリックから来るパケットのうちのどれが順序付け要件を有するのかを判断し得る。このような判断は、パケットの各々の中のコマンドエンコーディング、ＵｎｉｔＩＤ、ＳｅｑＩＤ、ＰａｓｓＰＷフィールドを調べることによって、達成され得る。順序付けされていないパケットは、ホストブリッジによる特別なアクションを必要とせず、それらは、ホストブリッジがそれらを送り出し得るのと同じぐらい速く、いずれかの順序でコヒーレントファブリックへと発行され得る。対照的に、順序付けされたパケットは、表２７０に列挙されている種々の待機要件を有する。
【０１６５】
表２７０は、順序付けされるペアの第１のリクエストを列挙するリクエスト_１列、順序付けされるペアの第２のリクエストを列挙するリクエスト_２列、およびホストブリッジによって第２のリクエストが進行することが可能となり得る前に受信されなければならない応答を列挙する待機要件列を含む。
【０１６６】
表２７０内で特に指示されない限りは、参照されるパケットは、コヒーレントファブリック上にある。また、例示的な実施例では、表２７０内で列挙されていないリクエストの組合せは、待機要件を有さない。さらに、ホストブリッジ２０２がまず２つのリクエストパケット間に順序付け要件が存在すると判断する場合にのみ、表２７０は適用される。たとえば、２つのリクエストパケットが整合する０ではないシーケンスＩＤを有するならば、または第１のリクエストパケットがポステッドライトであり、第２のリクエストがＰａｓｓＰＷビットクリアを有するならば、順序付け要件は存在し得る。
【０１６７】
表２７０の第１のエントリでは、順序付けされたメモリライトリクエストのペアは、第１のメモリライトリクエストに対応するＴｇｔＳｔａｒｔパケットがホストブリッジによってコヒーレントファブリック内で受信されるまで、第２のメモリライトリクエストの送信を遅延することによって、ホストブリッジにより完了される。加えて、ホストブリッジは、第１のメモリライトリクエストに応答するＴｇｔＤｏｎｅパケットが受信されるまで、第２のメモリライトリクエストに対応するＳｒｃＤｏｎｅパケットを差し控える。最終的に、ノンコヒーレントリンク上の第２のメモリライトリクエストに対応するＴｇｔＤｏｎｅパケットは（メモリライトがノンポステッドリクエストならば）、第１のメモリライトリクエストに対応するＴｇｔＤｏｎｅパケットがコヒーレントファブリックから受信されるまで、遅延される。図２８の表内の他のエントリは、第１のエントリについて上で与えられた説明と同様の様態で解釈され得る。
【０１６８】
コヒーレントファブリック内でのポステッドコマンドバーチャルチャネルの提供に加えて、図２８の表で列挙される待機要件を実現するためのホストブリッジ２０２の提供によって、コヒーレントファブリック内のポステッドライトリクエストのための順序付け要件が満たされ得ることが保証される。ノンコヒーレントファブリック上のポステッドライトリクエストのための順序付け要件は、上述のようなＰａｓｓＰＷビットを用いることによって、満たされ得る。図９に関して上で説明されたように、以下の４つの要件が、Ｉ／Ｏサブシステム内のＰＣＩバス上のポステッドライトに適用される。
【０１６９】
（ｉ）　同じソースからのポステッドライトは、ターゲットインターフェイス上で順序付けられて残される。
【０１７０】
（ｉｉ）　同じソースからのリードが後に続くポステッドライトは、リードデータが戻される前に、ターゲットインターフェイス上で完了される。
【０１７１】
（ｉｉｉ）　ノンポステッドライトは、同じソースからポステッドライトを渡し得ない。
【０１７２】
（ｉｖ）　ポステッドライトは、前のポストされていない動作を渡すことが可能にされなければならない。
【０１７３】
要件（ｉ）は、ポステッドライトリクエストパケットをポステッドコマンドバーチャルチャネル内に置き、さらには表２７０のエントリ２７２の待機要件を、異なるコヒーレントターゲットノードに向けられるポステッドライトリクエストに適用することによって、同じコヒーレントターゲットノードに向けられるポステッドライトリクエストに対して満たされる。要件（ｉｉ）は、表２７０のエントリ２７４の待機要件を適用することによって、満たされ得る。要件（ｉｉｉ）は、エントリ２７２の待機要件を適用することによって、満たされ得る。最終的に、要件（ｉｖ）は、ポステッドコマンドバーチャルチャネルを採用することによって、満たされ得る。要件（ｉ）−（ｉｖ）の各々について、第２のパケット内のＰａｓｓＰＷビットはクリアであると仮定される。それ以外の場合には、ＰａｓｓＰＷビットがセットされるならば、第２のパケットは、第１のパケットを渡すことが可能となり得る。表２７０内の他のエントリを用いて、ノンコヒーレントリンクから来たコヒーレントファブリック内の他のタイプのリクエストの順序付けが提供され得る。
【０１７４】
一旦、上述の開示を完全に理解すると、多くの変更および変形が当業者に明らかとなるであろう。前掲の請求項は、このようなすべての変更および変形を包含すると解釈されるべきであると意図される。
【０１７５】
この発明には種々の変形および代替の形が可能であり得るが、具体的な実施例は、図の例によって示され、ここで詳細に説明された。しかし、この発明は、開示されたある特定の形に限定されると意図されないことが理解されるべきである。逆に、この発明は、前掲の添付の請求項によって規定されるこの発明の思想および範囲内に入るすべての変形、均等物、および代替物を包含する。
【図面の簡単な説明】
【図１】複数の処理ノードを含むコンピュータ処理システムの例示的な実施例のブロック図である。
【図２】ノードを相互接続する通信リンクの例示的な実施例を示す、図１の処理ノードのうち２つのブロック図である。
【図３】処理サブシステム内で用い得る例示的なコヒーレント情報パケットの図である。
【図４】処理サブシステム内で用い得る例示的なコヒーレントリクエストパケットの図である。
【図５】処理サブシステム内で用い得る例示的なコヒーレント応答パケットの図である。
【図６】処理サブシステム内で用い得る例示的なコヒーレントデータパケットの図である。
【図７】処理サブシステム内で用い得る異なるタイプのコヒーレントパケットを一覧にしたテーブルの図である。
【図８】処理システム中の１対のバーチャルチャネルを図示するブロック図である。
【図９】１組のバーチャルチャネルおよびその適用可能なリンクの例示的な実施例を図示するテーブルの図である。
【図１０】図１の処理ノードの例示的な実施例のブロック図であり、ノードがパケット処理ロジックを含む、図である。
【図１１】図１０のノードのパケット処理ロジックの例示的な実施例のブロック図であり、パケット処理ロジックはデータバッファプールおよび応答カウンタプールを含む、図である。
【図１２】図１１のデータバッファプール中の場所の例示的な実施例のブロック図である。
【図１３】図１１の応答カウンタプール中の場所の例示的な実施例のブロック図である。
【図１４】パケットを受けるための、図１０のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図１５】リクエストパケットを処理するための、図１０のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図１６】応答パケットを処理するための、図１０のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図１７】パケットを開始するための、図１０のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図１８】バッファ解放フィールドを含む情報パケットの例示的な実施例を図示するブロック図である。
【図１９】図１および図２に示される相互接続と同様のリンクを介して相互接続される複数のＩ／Ｏノードおよびホストブリッジを含むＩ／Ｏサブシステムの例示的な実施例のブロック図である。
【図２０】ノンコヒーレントリンクのためのパケット定義の例示的な実施例を図示するテーブルの図である。
【図２１】処理システムで用い得る例示的なノンコヒーレントリクエストパケットの図である。
【図２２】処理システムで用い得る例示的なノンコヒーレント応答パケットの図である。
【図２３】図１９のＩ／ＯサブシステムのＩ／Ｏノードの例示的な実施例のブロック図であり、Ｉ／Ｏノードはノードロジックを含む、図である。
【図２４】パケット受取りのための、図２３のノードロジックの例示的な部分の動作のフローチャートの図である。
【図２５】リクエストパケットを処理するための、図２４のノードロジックの例示的な部分の動作のフローチャートの図である。
【図２６】応答パケットを処理するための、図２４のノードロジックの例示的な部分の動作のフローチャートの図である。
【図２７】パケットを開始するための、図２７のノードロジックの例示的な部分の動作のフローチャートの図である。
【図２８】図１９のホストブリッジが実現し得る例示的な順序付けルールを一覧にするテーブルの図である。

Claims (10)

1. コンピュータシステム内の複数のノード間でパケットをルーティングするための方法であって、
   複数のノードの第１のノード（１２、２０４）で第１のパケットを受信するステップを含み、第１のノード（１２、２０４）は複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含み、各パケットバッファ（６０、６２、６４、２２０、２２２）は、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、第１のパケットは第１のバーチャルチャネル上で受信され、前記方法はさらに、
   複数のパケットバッファ（６０、６２、６４、２２０、２２２）のうちの第１のパケットバッファに第１のパケットを記憶するステップを含み、第１のパケットバッファは、第１のバーチャルチャネル上で受信されるパケットのために確保されている、方法。
2. 第１のノード（１２、２０４）で第２のパケットを受信するステップと、
   第２のパケットが受信される第２のバーチャルチャネルを決定するステップと、
   第２のバーチャルチャネルの決定に基づいて、複数のパケットバッファ（６０、６２、６４、２２０、２２２）のうちの第２のパケットバッファに第２のパケットを記憶するステップとをさらに含む、請求項１に記載の方法。
3. 請求項２に記載の方法であって、
   第２のパケットのデスティネーションを決定するステップをさらに含み、
   デスティネーションが第１のノード（１２、２０４）以外の第２のノード（１２、２０４）であって、第２のノードは第２の複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含むならば、第２の複数のパケットバッファの各々は、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、
   第２のバーチャルチャネルに割振られる第２の複数のパケットバッファ（６０、６２、６４、２２０、２２２）のうちの１つの利用可能性を判断するステップと、
   判断された利用可能性に基づいて、第２のパケットを第２のノード（１２、２０４）に送信するステップとをさらに含む、請求項２に記載の方法。
4. 第２のパケットがポステッドリクエストパケットをプッシュするように構成されているかを判断するステップをさらに含み、その場合には、
   複数のパケットバッファ（６０、６２、６４、２２０、２２２）のうちのポステッドコマンドバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）内で、第２のパケットを生成した同じソースによって生成される、記憶されたポステッドリクエストパケットを見つけるステップと、
   見つけられた、記憶されたポステッドリクエストパケットを第２のノードに、第２のパケットの処理の前に送信するステップとを含む、請求項２に記載の方法。
5. コンピュータシステムであって、
   複数のバーチャルチャネル上でパケットを送信するように構成される第１のノード（１２、２０４）と、
   複数のバーチャルチャネル上で第１のノード（１２、２０４）からパケットを受信するように結合される第２のノード（１２、２０４）とを含み、第２のノードは複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含み、各パケットバッファはある特定のバーチャルチャネルに割振られ、第２のノード（１２、２０４）は、それぞれのパケットが受信される特定のバーチャルチャネルに割振られるパケットバッファ（６０、６２、６４、２２０、２２２）のうちの１つに受信されるパケットの各々を記憶するように構成される、コンピュータシステム。
6. 第１のノード（１２、２０４）は、ポステッドコマンドバーチャルチャネル上でポステッドリクエストパケットを送信するように構成され、第２のノード（１２、２０４）は、第１のパケットをポステッドコマンドパケットバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）に記憶するように構成され、第１のノード（１２、２０４）は、ポステッドコマンドバーチャルチャネル以外の第２のバーチャルチャネル上で第２のノード（１２、２０４）へと第２のパケットを送信するように構成され、第２のノードは、ポステッドコマンドパケットバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）以外のパケットバッファ（６０、６２、６４、２２０、２２２）に第２のパケットを記憶するように構成される、請求項５に記載のコンピュータシステム。
7. 複数のバーチャルチャネル上で第２のノード（１２、２０４）からパケットを受信するように結合される第３のノード（１２、２０４）をさらに含み、第３のノード（１２、２０４）は第２の複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含み、第２の複数のパケットバッファの各々は、ある特定のバーチャルチャネルに割振られ、第２のノード（１２、２０４）は、第２のバーチャルチャネルに割振られる第２の複数のパケットバッファ（６０、６２、６４、２２０、２２２）のうちの１つの利用可能性に基づいて、第２のパケットを第３のノード（１２、２０４）に送信するように構成される、請求項６に記載のコンピュータシステム。
8. 第２のパケットは、ポステッドリクエストパケットをプッシュするように構成され、第２のノード（１２、２０４）は、第２のパケットを生成した同じソースによって生成される、記憶された、ポステッドリクエストパケットを求めてポステッドコマンドパケットバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）を探索し、さらには第２のパケットの処理の前に、記憶された、ポステッドリクエストパケットを第３のノード（１２、２０４）に送信するように構成される、請求項６に記載のコンピュータシステム。
9. コンピュータシステム内の複数のノード間でパケットをルーティングするための方法であって、
   複数のノードのうちの第１のノード（１２、２０４）内でポステッドリクエストパケットを生成するステップと、
   ポステッドリクエストパケットを含む複数のパケットを第１のノード（１２、２０４）から複数のバーチャルチャネルを介して送信するステップとを含み、複数のパケットの各々はある特定のバーチャルチャネルを介して送信され、ポステッドリクエストパケットは、ポステッドリクエストパケットのために確保されたポステッドコマンドバーチャルチャネル上で第２のノード（１２、２０４）へと送信され、ポステッドリクエストパケットは、他のバーチャルチャネル上で送信される他のパケットから独立して送信され、
   第２のノード（１２、２０４）は、ポステッドコマンドパケットバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）を含む複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含み、各パケットバッファは、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、第２のノード（１２、２０４）への第２のパケットの送信は、ポステッドコマンドパケットバッファ（６０Ａ、６２Ａ、６４Ａ、２２０、２２２）の利用可能性に依存する、方法。
10. 請求項９に記載の方法であって、第１のノード（１２、２０４）は、複数のバーチャルチャネル間で割振られる複数のパケットバッファ（６０、６２、６４、２２０、２２２）を含み、前記方法は、
    第１のノード（１２、２０４）内で第２のパケットを生成するステップを含み、第２のパケットは、ターゲットノード（１２、２０４）からの応答パケットを生成するように構成され、前記方法はさらに、
    パケットバッファ（６０、６２、６４、２２０、２２２）のうちの１つを割振って応答パケットを受信するステップを含み、割振られたパケットバッファは、複数のバーチャルチャネルのうちの１つである応答バーチャルチャネルに割振られ、前記方法はさらに、
    第２のパケットをターゲットノード（１２、２０４）に送信するステップを含む、請求項９に記載の方法。

Images