JP4410967B2 - デッドロックのないコンピュータシステム動作のためのバーチャルチャネルおよび対応するバッファ割当て - Google Patents
デッドロックのないコンピュータシステム動作のためのバーチャルチャネルおよび対応するバッファ割当て Download PDFInfo
- Publication number
- JP4410967B2 JP4410967B2 JP2001525542A JP2001525542A JP4410967B2 JP 4410967 B2 JP4410967 B2 JP 4410967B2 JP 2001525542 A JP2001525542 A JP 2001525542A JP 2001525542 A JP2001525542 A JP 2001525542A JP 4410967 B2 JP4410967 B2 JP 4410967B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- packet
- control packet
- data
- buffer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
- G06F15/17356—Indirect interconnection networks
- G06F15/17368—Indirect interconnection networks non hierarchical topologies
- G06F15/17381—Two dimensional, e.g. mesh, torus
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Information Transfer Systems (AREA)
- Small-Scale Networks (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の背景】
１．技術分野
この発明はコンピュータシステムの分野に関し、より特定的には、コンピュータシステムにおけるノード間の相互接続に関する。
【０００２】
２．背景技術
一般的には、パーソナルコンピュータ（ＰＣ）およびその他の種類のコンピュータシステムは、メモリにアクセスするために共用バスシステムを中心に設計されてきた。１つ以上のプロセッサおよび１つ以上の入力／出力（Ｉ／Ｏ）装置が、共用バスを介してメモリに結合される。Ｉ／Ｏ装置は、共用バスとＩ／Ｏ装置との間の情報の転送を管理するＩ／Ｏブリッジを介して共用バスに結合される場合もある一方、プロセッサは典型的には、直接共用バスに結合されるか、またはキャッシュ階層構造を介して共用バスに結合される。
【０００３】
残念ながら、共用バスシステムはいくつかの欠点を有する。たとえば、共用バスには多数の装置が装着されることから、バスは典型的には比較的低い周波数で動作される。多数の装着物は、バス上で信号を駆動する装置に容量的な高負荷をもたらし、多数の装着点は、比較的複雑な高周波数に対する伝送ラインモデルをもたらす。したがって、周波数は低く留められ、共用バスで使用できる帯域幅も同様に比較的低い。低帯域幅は共用バスに付加的な装置を装着するのに障壁になり得るが、これは使用できる帯域幅によって性能が制限されるおそれがあるためである。
【０００４】
共用バスシステムの他の欠点は、より多くの装置に対するスケーラビリティの欠如である。上述のように、帯域幅が固定される（そして、もし付加的な装置の追加によってバスの動作可能周波数が減じられると、減少し得る）。バスに（直接的にまたは間接的に）装着された装置の帯域幅要件が、一旦バスの利用可能な帯域幅を超えると、装置はバスへのアクセスを試みたときにしばしばストールし得る。全体的な性能が減じられるであろう。
【０００５】
上述の問題のうちの１つまたはいくつかには、分散メモリシステムを用いて対処し得る。分散メモリシステムを用いるコンピュータシステムは、複数のノードを含む。２つ以上のノードがメモリに接続され、それらのノードは何らかの好適な相互接続を用いて相互接続される。たとえば、ノードの各々は専用ラインを用いて他のノードに互いに接続されることができる。これに代えて、ノードの各々は固定された数の他のノードに接続され、トランザクションは第１のノードから１つ以上の中間ノードを介して、第１のノードに直接接続されていない第２のノードに経路制御されてもよい。メモリアドレス空間は、各々のノードのメモリにわたって割当てられる。一般的に、「ノード」とは相互接続上のトランザクションに関わることのできる装置である。たとえば、パケットベースの相互接続においては、ノードは他のノードとパケットを送受信し得るよう構成される。特定のトランザクションを行なうために、１つ以上のパケットが採用され得る。特定のノードは、パケットに対するデスティネーションであり得るが、この場合情報はノードによって受取られて、ノード内で処理される。これに変えて、特定のノードは、もし特定のノードがパケットのデスティネーションノードでなければ、パケットをソースノードからデスティネーションノードへ中継するためにも用い得る。
【０００６】
分散メモリシステムは、共用バスシステムの困難とは異なった設計上の困難を呈示する。たとえば、共用バスシステムはバスアービトレーションを介してトランザクションの開始を規制する。したがって、明確なアービトレーションアルゴリズムが、関与するバスにトランザクションを開始させる機会を与える。バス上のトランザクションの順序が、そのトランザクションが行なわれる順序を表し得る（たとえば、コヒーレンシ目的で）。一方、分散システムにおいては、ノードは並行にトランザクションを開始し、相互接続を用いてトランザクションを他のノードに送信し得る。これらのトランザクションは、それらの間でロジック的コンフリクト（たとえば、同じアドレスへのトランザクションに対するコヒーレンシコンフリクト）を有し、資源コンフリクトが生じるおそれがあるが、これはトランザクションの開始を規制するための中央機構が提供されていないためである。したがって、情報がノード間を円滑に伝播しつづけ、かつ（トランザクション間のコンフリクトによりトランザクションが完了しない）デッドロック状態が回避されることを確実にすることが、より困難である。分散システムにおけるデッドロックを回避するための方法および装置が望まれる。さらに、実現を容易にするために、（ハードウェアの意味での）装置を最小化することが望まれる。
【０００７】
Ｖ・Ｓ・アドヴェおよびＭ・Ｋ・ヴァーノン（V. S. Adve and M. K. Vernon）の「判断経路制御によるメッシュ相互接続ネットワークのパフォーマンス分析（Performance Analysis of mesh interconnection networks with deterministic routing）INTERNET [Online]１９９４年、１〜４０頁、ＸＰ２１５５４２４は、物理的リンクの各々が、別々のバッファによって与えられる２つのバーチャルチャネルにより共用される、デッドロックのない経路制御アルゴリズムを用いた処理ノードのネットワークの間のメッセージを経路制御する方法を開示する。
上に概要を述べた問題は、ここで説明するようにバーチャルチャネルを用い、かつバーチャルチャネルに異なった資源を割当てることにより、大部分が解決される。
この発明の１つの局面によると、コンピュータシステム内の複数のノードの間でパケットを経路制御するための方法が開示され、方法は請求項１に定義される。
この発明の第２の局面によると、請求項５に定義されるコンピュータシステムが提供される。
一般的に、ロジック的／プロトコル関連のコンフリクトを有さないパケットは、バーチャルチャネルにグループ化される。したがって、ロジック的コンフリクトは別々のバーチャルチャネル内のパケットの間で生じる。１つのバーチャルチャネル内のパケットは資源を共用する（よって資源コンフリクトが生じる）が、異なったバーチャルチャネル内のパケットは資源を共用しないであろう。資源コンフリクトが生じるパケットはロジック的コンフリクトは生じなく、かつロジック的コンフリクトが生じるパケットは資源コンフリクトは生じないために、デッドロックのない動作が達成される。
【０００８】
さらに、各バーチャルチャネルには、制御パケットバッファとデータパケットバッファとが割当てられ得る。制御パケットは、データパケットよりも実質的にサイズが小さく、データパケットよりも頻繁に生じ得る。別々のバッファを与えることにより、バッファ空間を効率的に用いることができる。データパケットを特定しない制御パケットが受取られると、データパケットバッファ空間は割当てられない。データパケットを特定する制御パケットが受取られると、制御パケットバッファ空間およびデータパケットバッファ空間の両方が割当てられる。制御パケットはデータパケットよりも小さくより頻繁に生じることが多いので、全体的なバッファ記憶を実質的に増加させることなく、データパケットバッファ内よりも制御パケットバッファ内でより多くのバッファエントリを提供することができる。しかしながら、パケットのスループットは上昇し得る。
【００１１】
この発明の他の目的と利点とは、以下の詳細な説明を読み、添付の図面を参照することにより、より明らかとなるであろう。
【００１２】
この発明はさまざまな変形と代替形に対処するものであるが、その特定の実施例を図面において例示の目的で示し、以下に詳述する。しかしながら、図面とその詳細な説明とは開示される発明を特定の形に限定することを意図せず、反対に、すべての変形、等価物、および代替例は前掲の特許請求の範囲に規定されるこの発明の精神および範囲に入ることを意図する。
【００１３】
【発明の実施の形態】
システムの概要
図１は、マルチプロセッシングコンピュータシステム１０の一実施例を示す。他の実施例が可能であり企図される。図１の実施例においては、コンピュータシステム１０はいくつかの処理ノード１２Ａ、１２Ｂ、１２Ｃ、および１２Ｄを含む。処理ノードの各々は、処理ノード１２Ａ−１２Ｄにそれぞれ含まれるメモリコントローラ１６Ａ−１６Ｄを介して、それぞれのメモリ１４Ａ−１４Ｄに結合される。さらに、処理ノード１２Ａ−１２Ｄは、処理ノード１２Ａ−１２Ｄの間の通信のために用いるインターフェイスロジックを含む。たとえば、処理ノード１２Ａは、処理ノード１２Ｂと通信するためのインターフェイスロジック１８Ａと、処理ノード１２Ｃと通信するためのインターフェイスロジック１８Ｂと、さらに別の処理ノード（図示せず）と通信するための第３のインターフェイスロジック１８Ｃを含む。同様に、処理ノード１２Ｂはインターフェイスロジック１８Ｄ、１８Ｅ、および１８Ｆを含み、処理ノード１２Ｃはインターフェイスロジック１８Ｇ、１８Ｈ、および１８Ｉを含み、処理ノード１２Ｄはインターフェイスロジック１８Ｊ、１８Ｋ、および１８Ｌを含む。処理ノード１２Ｄは、インターフェイスロジック１８Ｌを介して結合されてＩ／Ｏブリッジ２０と通信する。他の処理ノードは同様の様式で他のＩ／Ｏブリッジと通信し得る。Ｉ／Ｏブリッジ２０はＩ／Ｏバス２２に結合される。
【００１４】
処理ノード１２Ａ−１２Ｄは、処理ノード間通信のためのパケットベースのリンクを実現化する。この実施例においては、リンクは単方向ラインの組として実現化される（たとえば、ライン２４Ａはパケットを処理ノード１２Ａから処理ノード１２Ｂへ送信するために用いられ、ライン２４Ｂはパケットを処理ノード１２Ｂから処理ノード１２Ａへ送信するために用いられる）。ライン２４Ｃ−２４Ｈの他の組は、図１に示すようにパケットを他の処理ノード間で通信するために用いられる。リンクは、処理ノード間の通信のためにキャッシュコヒーレント様式で動作するか（「コヒーレントリンク」）、または処理ノードとＩ／Ｏブリッジとの間の通信のために非コヒーレント様式で動作し得る（「非コヒーレントリンク」）。さらに、非コヒーレントリンクは、Ｉ／Ｏバス２２の代わりにＩ／Ｏ装置の間でデイジーチェーン構造として用いられ得る。コヒーレントリンクを介した２つ以上のノードの相互接続は、「コヒーレントファブリック」と呼ばれる。同様に、非コヒーレントリンクを介した２つ以上のノードの相互接続は、「非コヒーレントファブリック」と呼ばれる。一方の処理ノードから他方へ送信されるべきパケットは、１つ以上の中間ノードを通過し得ることに留意されたい。たとえば、処理ノード１２Ａから処理ノード１２Ｄに送信されるパケットは、図１に示すように、処理ノード１２Ｂまたは処理ノード１２Ｃのいずれかを通過し得る。いかなる好適な経路制御アルゴリズムをも用い得る。コンピュータシステム１０の他の実施例は、図１に示す実施例よりも多いかまたは少ない処理ノードを含み得る。
【００１５】
処理ノード１２Ａ−１２Ｄは、メモリコントローラとインターフェイスロジックに加えて、１つ以上のプロセッサを含み得る。概略的には、処理ノードは少なくとも１つのプロセッサを含み、選択により、メモリおよび所望の他のロジックとの間で通信するためのメモリコントローラを含む。
【００１６】
メモリ１４Ａ−１４Ｄは、何らかの好適なメモリ装置を含み得る。たとえば、メモリ１４Ａ−１４Ｄは、１つ以上のＲＡＭＢＵＳ ＤＲＡＭ（ＲＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭなどを含み得る。コンピュータシステム１０のアドレス空間は、メモリ１４Ａ−１４Ｄの間で分割される。処理ノード１２Ａ−１２Ｄの各々はメモリマップを含むことができ、該メモリマップを用いて、どのアドレスがどのメモリ１４Ａ−１４Ｄにマッピングされているか、よって、ある特定のアドレスに対するメモリ要求がどの処理ノード１２Ａ−１２Ｄに経路制御されるべきかを判断する。一実施例においては、コンピュータシステム１０内のアドレスに対するコヒーレンシ点は、アドレスに対応するバイトを記憶しているメモリに結合された、メモリコントローラ１６Ａ−１６Ｄである。言い換えると、メモリコントローラ１６Ａ−１６Ｄは、対応するメモリ１４Ａ−１４Ｄへのメモリアクセスの各々を、キャッシュコヒーレントな様式で起こることを確実にすることを担当している。メモリコントローラ１６Ａ−１６Ｄは、メモリ１４Ａ−１４Ｄにインターフェイスするための制御回路を含み得る。さらに、メモリコントローラ１６Ａ−１６Ｄは、メモリ要求を待ち行列として管理するための、要求待ち行列を含み得る。
【００１７】
一般的には、インターフェイスロジック１８Ａ−１８Ｌは、リンクからパケットを受取り、かつリンクに送信されるべきパケットをバッファするための、バッファを含み得る。コンピュータシステム１０は、パケットを送るために好適などのようなフロー制御をも用い得る。たとえば一実施例においては、ノードの各々は、インターフェイスロジックの各々が接続されたリンクの他端のレシーバ内に、いくつかの各種のバッファのカウントを記憶する。ノードは、受信ノードがパケットを記憶するための空いたバッファを有さない限り、パケットを送信しない。パケットを次に経路制御することにより受信バッファが空くと、受信インターフェイスロジックは送信インターフェイスロジックにメッセージを送り、バッファが空いたことを示す。そのような機構は、「クーポンに基づく」システムと呼べる。
【００１８】
次に図２は、処理ノード１２Ａおよび１２Ｂのブロック図を示し、それらの間のリンクの一実施例を詳細に例示する。他の例も可能であり、企図される。図２の実施例においては、ライン２４Ａは、クロックライン２４ＡＡと、制御ライン２４ＡＢと、制御／アドレス／データバス２４ＡＣとを含む。同様に、ライン２４Ｂは、クロックライン２４ＢＡと、制御ライン２４ＢＢと、制御／アドレス／データバス２４ＢＣとを含む。
【００１９】
クロックラインは、制御ラインおよび制御／アドレス／データバスに対するサンプルポイントを示すクロック信号を送信する。特定の一実施例においては、データ／制御ビットはクロック信号のエッジの各々（すなわち立上がりエッジおよび立下がりエッジ）で送信される。したがって、クロックサイクルごとに、ラインごとに２つのデータビットを送信し得る。ラインごとに１ビットを送信するために使用される時間は、ここでは「ビット時間」と呼ぶ。上述の実施例は、クロックサイクルごとに２つのビット時間を含む。パケットは２つ以上のビット時間で送信し得る。制御／アドレス／データバスの幅に依存して、多数のクロックラインを用い得る。たとえば３２ビット制御／アドレス／データバスに対しては２つのクロックラインを用い得る（制御／アドレス／データバスの半分では一方のクロックラインが参照され、残りの半分の制御／アドレス／データバスと制御ラインとでは他方のクロックラインが参照される）。
【００２０】
制御ラインは、制御／アドレス／データバスに送信されたデータが、ビット時間の制御パケットか、またはビット時間のデータパケットであるかを示す。制御ラインはアサートされてビット時間の制御パケットを示し、デアサートされてビット時間のデータパケットを示す。ある制御パケットは、後にデータパケットが続くことを示す。データパケットは、対応する制御パケットのすぐ後に続き得る。一実施例においては、他の制御パケットがデータパケットの送信に割込むおそれがある。そのような割込は、データパケットの送信の間に制御ラインをいくつかのビット時間アサートし、かつ制御ラインがアサートされている間にビット時間の制御パケットを送信することにより行なわれる可能性がある。データパケットに割込む制御パケットは、データパケットが後に続くことを示さないおそれがある。さらに、一実施例においては、制御ラインが制御パケットの送信の間にデアサートされてストールビット時間を示し得る。後の制御ラインの再アサートは、制御パケットが続いていることを示し得る。
【００２１】
制御／アドレス／データバスは、データ／制御ビットを送信するための１組のラインを含む。一実施例においては、制御／アドレス／データバスは、８、１６、または３２のラインを含み得る。処理ノードまたはＩ／Ｏブリッジの各々は、設計選択にしたがってサポートされる数のラインのうちのいずれかを用い得る。他の実施例は、所望により他のサイズの制御／アドレス／データバスをサポートし得る。
【００２２】
一実施例によると、コマンド／アドレス／データバスラインおよびクロックラインは、反転データを担持し得る（すなわち、ロジック１はライン上の低電圧として表わされ、ロジック０が高電圧として表わされる）。これに代えて、これらのラインは非反転データを担持してもよい（ロジック１はライン上の高電圧として表わされ、ロジック０は低電圧として表わされる）。
【００２３】
図３から図６は、コヒーレントリンクの一実施例において用いられる、例示的なパケットを示す。図３から図５は制御パケットを示し、図６はデータパケットを示す。他の実施例は、所望により異なったパケット定義を用い得る。パケットの各々は、「ビット時間」の見出しの下に列挙される一連のビット時間で示される。パケットのビット時間は、リストされたビット時間順序に従って送信される。図３から図６は、８ビット制御／アドレス／データバス実現化のためのパケットを示す。したがって、ビット時間の各々は、７から０まで番号が付与された８つのビットを含む。図中、いずれの値も付与されていないビットは、所与のパケットのために予約されているか、またはパケット特定情報を送信するために用いられるかのいずれかであり得る。点線で示されるフィールドは、あるタイプのすべてのパケットに含まれない可能性のある任意のフィールドを示す。
【００２４】
一般的に、パケットは２つのノード（パケットを送信する起動ノードおよびパケットを受取るデスティネーションノード）間の通信である。起動ノードおよびデスティネーションノードは、パケットが関わるトランザクションのソースおよびターゲットノードとは異なるか、またはいずれかのノードがソースノードまたはターゲットノードのいずれかであり得る。制御パケットは、トランザクションに関する制御情報を担持するパケットである。ある制御パケットは、データパケットが後に続くことを特定する。データパケットは、トランザクションに対応し、かつ特定する制御パケットに対応するデータを担持する。
【００２５】
図３は情報パケット（infoパケット）３０を示す。情報パケット３０は、８ビットリンク上の４つのビット時間を含む。この実施例においては、コマンド符号化はビット時間１の間に送信され、かつ６ビットを含む。図４、および図５に示す他方の制御パケットの各々は、ビット時間１の間に同じビット位置においてコマンド符号化を含む。メッセージがメモリアドレスを含まないときに、情報パケット３０を用いてこのメッセージを処理ノード間で送信し得る。さらに、クーポンに基づくフロー制御方策を用いてバッファ空きカウントを送信するためにも、情報パケットを用い得る。
【００２６】
図４はコマンドパケット（commandパケット）３２を示す。コマンドパケット３２は、８ビットリンク上の８つのビット時間を含む。コマンド符号化は、ビット時間１の間に送信される。ソースユニット番号も同様にビット時間１の間に送信され、ソースノード番号はビット時間２の間に送信される。ノード番号はコンピュータシステム１０内の処理ノード１２Ａ−１２Ｄのうちの１つを明確に識別し、かつパケットをコンピュータシステム１０を介して経路制御するために用いられる。ユニット番号は、トランザクションを発したノード内のユニットを識別するか（ソースユニット番号）、またはトランザクションのデスティネーションであるノード内のユニットを識別する（デスティネーションユニット番号）。ユニットは、メモリコントローラ、キャッシュ、プロセッサなどを含み得る。任意で、コマンドパケット３２はビット時間２におけるデスティネーションノード番号およびデスティネーションユニットのいずれかを含み得る（または他のいくつかのパケットでは、ターゲットノード番号およびターゲットユニット）。もしデスティネーション番号が含まれていれば、これはパケットをデスティネーションノードに経路制御するために用いられる。また、多くのコマンドパケットがビット時間３にソースタグを含み得るが、これはソースノードおよびソースユニットと併せて、パケットを関連する特定のトランザクションにリンクし得る。ビット時間５から８は、トランザクションによって影響されるメモリアドレスの最上位のビットを送信するために用いられる。コマンドパケット３２は、トランザクションを開始し（たとえば、読出または書込トランザクション）、かつトランザクションによって影響されるメモリアドレスを担持するコマンドに対するトランザクションを実行するプロセスにおいてコマンドを送信するために用いられる。一般的に、コマンドパケットはデスティネーションノードによって実行されるべき動作を示す。
【００２７】
パケット３２内の定義されないいくつかのフィールドをコマンドパケットにおいて用いて、パケット特定情報を担持し得る。さらに、ビット時間４をいくつかのコマンド内で用いて、トランザクションによって影響されるメモリアドレスの最下位のビットを送信する。
【００２８】
図５は、応答パケット（responseパケット）３４を示す。応答パケット３４は、コマンド符号化と、デスティネーションノード番号およびデスティネーションユニット番号とを含む。デスティネーションノード番号は、応答パケットに対するデスティネーションノードを識別する（これは、場合によってトランザクションのソースノードまたはターゲットノードであり得る）。さまざまな種類の応答パケットは付加的な情報を含み得る。たとえば、読出応答パケットは、後に続くデータパケットで提供される読出データの量を示し得る。プローブ応答は、プローブノードによって要求されたキャッシュブロックのコピーが保持されているか否かを示し得る（ビット時間４における任意の共用ビット“Ｓｈ”を用いる）。一般的に、応答パケット３４は、トランザクションを行なう間に、トランザクションによって影響されるメモリアドレスの送信を必要としないコマンドに対して用いられる。さらに、応答パケット３４を用いて肯定応答パケットを送信してトランザクションを終了させることができる。コマンドパケット３２と同様に、応答パケット３４はさまざまな種類の応答に対するソースノード番号、ソースユニット番号、およびソースタグを含み得る（図５に任意のフィールドとして示す）。
【００２９】
図６は、データパケット（dataパケット）３６を示す。データパケット３６は、図６の実施例において、８ビットリンク上の８つのビット時間を含む。データパケット３６は、送信されるデータの量に依存して、異なった数のビット時間を含み得る。たとえば、一実施例においてはキャッシュブロックは６４バイトを含み、したがって８ビットリンク上の６４のビット時間を含む。他の実施例では、キャッシュブロックのサイズを所望により別に定義し得る。さらに、キャッシュ不可能な読出および書込に対しては、キャッシュブロックサイズよりも小さなサイズでデータを送信し得る。キャッシュブロックサイズより小さなデータを送信するためのデータパケットは、より少ないビット時間を用いる。一実施例においては、キャッシュブロックサイズではないデータはデータを送信する前にいくつかのビット時間のバイトイネーブルを送信して、データパケット内でどのデータバイトが有効であるかを示し得る。さらに、キャッシュブロックデータは最初に、要求されたアドレスの最下位のビットによってアドレスされたクワッドワードを備えて返され、その後インターリーブされた残りのクワッドワードのリターンが続く。一実施例においては、クワッドワードは８バイトを含み得る。
【００３０】
図３から図６は、８ビットリンクのためのパケットを示す。１６および３２ビットリンクのためのパケットは、図３から図６に示す連続的なビット時間を連結することにより形成し得る。たとえば、１６ビットリンク上のパケットのビット時間１は、８ビットリンク上のビット時間１および２の間に送信される情報を含み得る。同様に、３２ビットリンク上のパケットのビット時間１は、８ビットリンク上のビット時間１から４までの間に送信される情報を含み得る。以下の式（１）および式（２）は、８ビットリンクによるビット時間における、１６ビットリンクのビット時間１および３２ビットリンクのビット時間１の構成を示す。
【００３１】
【数１】
【００３２】
図７は、コンピュータシステム１０内のコヒーレントリンクの１つの例示的な実施例によって用いられるコマンドを示すテーブル３８を示す。パケットおよびコマンドフィールド符号化のいかなる好適な組をも含む、他の実施例も可能であり企図される。テーブル３８は、コマンドの各々に割当てられたコマンド符号化を示すコマンド符号化列、コマンドの名前を示すコマンド列、およびどのコマンドパケット３０−３４（および特定される場合には、データパケット３６）がそのコマンドに対して用いられるかを示すパケットタイプ列を含む。
【００３３】
読出トランザクションは、ReadSized，RdBlk，RdBlkSまたはRdBlkModのコマンドのうち、１つを用いて開始される。ReadSizedコマンドは、キャッシュ不可能な読出のために、またはサイズの合ったキャッシュブロック以外のデータの読出のために用いられる。読出されるべきデータ量は、ReadSizedコマンドパケット内に符号化される。キャッシュブロックの読出には、以下の場合以外にRdBlkコマンドを用いることができる。すなわち、（ｉ）キャッシュブロックの書込可能なコピーを所望である場合。この場合はRdBlkModコマンドを用い得る。または（ii）キャッシュブロックのコピーを所望するが、ブロックを変更する意図があるとは分らない場合。この場合はRdBlkS コマンドを用いることができる。RdBlkSコマンドを用いて、ある種のコヒーレントな方式（たとえばディレクトリに基づくコヒーレントな方式）をより効率化できる。一般的に、適切な読出コマンドはソースから送信されて、キャッシュブロックに対応するメモリを有するターゲットノードへの読出トランザクションを開始する。ターゲットノード内のメモリコントローラは、システム内の他のノードに（プローブ応答からのトランザクションのソースへのリターンを示す）Probeコマンドを送信して、これらのノード内のキャッシュブロックの状態を変化させること、およびキャッシュブロックの更新されたコピーを含むノードにキャッシュブロックをソースノードに送らせることにより、コヒーレンシを維持する。Probeコマンドを受取ったノードの各々は、ProbeResp応答パケットをソースノードに送信する。プローブされたノードが読出データの更新されたコピー（すなわちダーティデータ）を有していれば、そのノードはRdResponse応答パケットおよびダーティデータを送信する。ダーティデータを送信するノードはまた、ターゲットノードによる要求された読出データの送信をキャンセルしようと試みて、ターゲットノードにMemCancel応答パケットをも送信し得る。さらに、ターゲットノード内のメモリコントローラは、RdResponse応答パケットとその後に続くデータパケット内のデータとを用いて要求された読出データを送信する。ソースノードがプローブされたノードからRdResponse応答パケットを受取れば、その読出されたデータが用いられる。そうでなければ、ターゲットノードからのデータが用いられる。一旦ソースノードにおいてプローブ応答および読出されたデータの各々が受取られると、ソースノードはトランザクションの終了の肯定応答として、ターゲットノードにSrcDone応答パケットを送信する。
【００３４】
書込トランザクションはWrSizedまたはVicBlkコマンドを用いて開始され、その後に関連のデータパケットが続く。WrSizedコマンドは、キャッシュ不可書込またはサイズの合わないキャッシュブロックのデータの書込に用いられる。WrSizedコマンドに対するコヒーレンシの維持のために、ターゲットノード内のメモリコントローラはシステム内の他のノードの各々に（トランザクションのターゲットノードに対するプローブ応答のリターンを示す）Probeコマンドを送信する。Probeコマンドに応答して、プローブされたノードの各々はターゲットノードにProbeResp応答パケットを送信する。もしプローブされたノードがダーティデータを記憶していれば、プローブされたノードはRdResponse応答パケットおよびダーティデータで応答する。このようにして、WrSizedコマンドによって更新されたキャッシュブロックは、メモリコントローラに返されて、WrSizedコマンドによって提供されるデータとマージされる。メモリコントローラは、プローブされたノードの各々からプローブ応答を受取ると、ソースノードにTgtDoneパケットを送信してトランザクションの終了の肯定応答を提供する。ソースノードはSrcDone応答パケットで応答する。
【００３５】
ノードによって変更され、かつノード内のキャッシュで置き換えられたヴィクティムキャッシュブロックは、VicBlkコマンドを用いてメモリに返される。VicBlkコマンドに対してはプローブは必要ではない。したがって、ターゲットメモリコントローラがビクティムブロックデータをメモリにコミットする準備ができたとき、ターゲットメモリコントローラはビクティムブロックのソースノードにTgtDone応答パケットを送信する。ソースノードは、データがコミットされるべきことを示すSrcDone応答パケットか、またはデータが（たとえば介入するプローブに応答して）VicBlkコマンドの送信とTgtDone応答パケットの受信との間で無効化されたことを示すMemCancel応答パケットのいずれかで応答する。
【００３６】
ソースノードに記憶された書込不可能状態のキャッシュブロックへの書込許可を得るために、ソースノードはChangetoDirtyコマンドパケットを送信し得る。ChangetoDirtyコマンドによって開始されるトランザクションは、ターゲットノードがデータを返さないという点を除いて、読出と同様に動作し得る。もしソースノードがキャッシュブロック全体を更新する意図があるのであれば、ValidateBlkコマンドを用いて、ソースノードによって記憶されていないキャッシュブロックへの書込許可を得ることができる。そのようなトランザクションに対してはソースノードへデータは送られないが、それ以外では読出トランザクションと同様に動作する。
【００３７】
Nop infoパケットは、たとえばノード間のバッファ空き表示を送信するために用いられる、非動作パケットである。Broadcastコマンドは、ノード間でメッセージをブロードキャストするために用い得る（たとえば、ブロードキャストコマンドは割込を分散させるために用い得る）。最後に、sync infoパケットは、ファブリックの同期が所望である場合（たとえば、エラー検出、リセット、初期化）に用い得る。
【００３８】
テーブル３８はまた、バーチャルチャネル列（Vchan）をも含む。バーチャルチャネル列は、パケットの各々が移動する（すなわち、パケットの各々が属する）バーチャルチャネルを示す。この実施例においては、３つのバーチャルチャネルが定義される：コマンド（Command、Ｃ）、応答（Response、Ｒ）、およびプローブ（Probe、Ｐ）である。バーチャルチャネルを以下に詳細に説明する。情報パケットは隣接するノード間の通信のために用いられ、よってこの実施例においてはバーチャルチャネルには割当てられないことに留意されたい。
【００３９】
バーチャルチャネル
図８を参照すると、バーチャルチャネルを例示するブロック図が示される。図８において、２つのバーチャルチャネルが示される（バーチャルチャネル４０Ａおよび４０Ｂ）。処理ノード１２Ａ−１２Ｄの各々は、バーチャルチャネル４０Ａ−４０Ｂに結合される。２つのバーチャルチャネルは例示目的でのみ図８に示す。他の実施例は、いかなる好適な数のバーチャルチャネルをも含み得る。たとえば、コンピュータシステム１０の実施例は以下の図９に示されるように４つのバーチャルチャネルを用い得る。
【００４０】
一般的に、「バーチャルチャネル」は、さまざまな処理ノードの間でパケットを担持するための通信経路である。各バーチャルチャネルは、他のバーチャルチャネルから資源的に独立している（すなわち、１つのバーチャルチャネル内で流れるパケットは、物理的な通信の意味において、一般的に別のバーチャルチャネルにおけるパケットの存在または不在によって影響されない）。パケットは、パケットタイプに基づいてバーチャルチャネルに割当てられる。同じバーチャルチャネル内のパケットは、互いの通信に対して物理的にコンフリクトし得る（すなわち、同じバーチャルチャネル内のパケットには資源コンフリクトが生じる可能性がある）が、異なったバーチャルチャネル内のパケットの通信に対しては物理的にコンフリクトしない。
【００４１】
ある種のパケットは、他のパケットとロジック的にコンフリクトする（すなわち、プロトコルの理由、コヒーレンシの理由、または他のそのような理由から、一方のパケットはロジック的に別のパケットとコンフリクトし得る）。もし第１のパケットが、ロジック／プロトコル理由から、第２のパケットがそのデスティネーションノードに到着する前にそのデスティネーションノードに到着しなければならない場合、第２のパケットが物理的に第１のパケット通信をブロックするのであれば、（コンフリクトする資源を占有することにより）コンピュータシステムがデッドロックする可能性がある。第１および第２のパケットを別々のバーチャルチャネルに割当てることにより、かつ別々のバーチャルチャネルにおけるパケットが互いの通信をブロックしないようコンピュータシステム内の送信媒体を実現することにより、デッドロックのない動作を実現し得る。異なったバーチャルチャネルからのパケットは、同じ物理的リンク（たとえば、図１のライン２４）をわたって通信されることに留意されたい。しかしながら、受信バッファは送信の前に利用可能になっているので、バーチャルチャネルはこの共用資源を用いる間にも、互いをブロックしない。
【００４２】
１つの観点から見ると、異なったパケットタイプの各々（たとえば、異なったコマンド符号化の各々）は、それ自身のバーチャルチャネルに割当てられることができる。しかしながら、バーチャルチャネルが物理的にコンフリクトしないことを確実にするためのハードウェアは、バーチャルチャネルの数とともに増大する。たとえば、一実施例においては、別々のバッファがバーチャルチャネルごとに割当てられる。別々のバッファがバーチャルチャネルごとに用いられるために、１つのバーチャルチャネルからのパケットは別のバーチャルチャネルからのパケットと物理的にコンフリクトしない（そのようなパケットは別のバッファに入れられるためである）。しかしながら、バッファの数はバーチャルチャネルの数に比例する。したがって、ロジック／プロトコル態様でコンフリクトしないさまざまなパケットの種類を組合せることにより、バーチャルチャネルの数を減じることが望ましい。そのようなパケットは、同じバーチャルチャネルを移動する際に互いに対して物理的にコンフリクトし得るが、ロジック的コンフリクトを有さないために、デッドロックなしに資源コンフリクトを解決することを可能にする。同様に、ロジック的にコンフリクトするおそれのあるパケットを別々のバーチャルチャネルに保つことは、パケット間の資源コンフリクトをなくす。したがって、ロジック的コンフリクトは、第１に完了させるべきパケットの進行を可能にすることによりパケット間の資源コンフリクトをなくして、解決される。
【００４３】
一実施例においては、コヒーレントリンク上で特定のバーチャルチャネル内で特定のソースノードから特定のデスティネーションノードに移動するパケットは順序を保つ。しかしながら、異なったバーチャルチャネルを特定のソースノードから特定のデスティネーションノードに移動するパケットは、順序付けられない。同様に、（たとえ同じバーチャルチャネルを移動するとしても）特定のソースノードから異なったデスティネーションノードへのパケット、または異なったソースノードから同じデスティネーションノードへのパケットは、順序付けられない。
【００４４】
バーチャルチャネルは、コヒーレントファブリックおよび非コヒーレントファブリック上に物理的にマッピングされる（図１９を参照）。たとえば、図１に示すコンピュータシステム１０の実施例においては、相互接続は各ノード間の単方向リンクを含む。したがって、さまざまなバーチャルチャネルを移動するパケットは、単方向リンクに物理的に送信される。パケットは、ソースとデスティネーションとの間で中間のノードを通って移動し得る。たとえば、ノード１２Ａからノード１２Ｄを通って移動するパケットは、ノード１２Ｂおよび１２Ｃを通過し得る。異なったバーチャルチャネルを移動するパケットは、コンピュータシステム１０によって異なって経路制御される。たとえば、第１のバーチャルチャネル内でノード１２Ａからノード１２Ｄを移動するパケットは、ノード１２Ｂを通過し得る一方、ノード１２Ａからノード１２Ｄを第２のバーチャルチャネル内で移動するパケットは、ノード１２Ｃを通過し得る。ノードの各々は、異なったバーチャルチャネル内のパケットの互いに対する物理的コンフリクトを確実になくすための回路を含む。非コヒーレントファブリックにおいては、Ｉ／Ｏノードからのパケットは、そのＩ／Ｏノードとホストブリッジ（図１９を参照）との間で互いのＩ／Ｏノードを通って通過し得る。Ｉ／Ｏノードは、図８に示されるものと同様の態様でバーチャルチャネルに結合され得ることに留意されたい。
【００４５】
以下に詳述される特定の実施例においては、制御パケットバッファは各バーチャルチャネルに割当てられて、そのバーチャルチャネル内を移動する制御パケットをバッファする。別々のデータパケットバッファがまた、データパケットを担持し得る各バーチャルチャネルに割当てられてもよい。制御パケットバッファ（その各エントリは、比較的小さなビット時間を含む）を分けることにより、およびデータパケットバッファ（その各エントリは、キャッシュブロックを保持するために比較的大きな数のビット時間を含む）を分けることにより、バッファ空間を節約する一方で、それでも好適なデータ記憶装置を提供する。データパケットバッファよりも制御パケットバッファが多く実現される（これは、データパケットはすべて対応の制御パケットを有するが、制御パケットはすべてが対応のデータパケットを有するわけではないためである）。バッファ空間を比較的効率的に用いる一方、スループットは高くなり得る。
【００４６】
図９は、コンピュータシステムの一実施例に従って規定されるバーチャルチャネルを示すテーブル４２である。他の実施例も可能であり企図される。示される実施例に対しては、３つのバーチャルチャネルが規定される。コヒーレントリンクに対するこれらのバーチャルチャネルに属するパケットを図７に示し、非コヒーレントリンクに対するバーチャルチャネルに属するパケットを図２０に示す。
【００４７】
コマンドバーチャルチャネルはコマンドパケット（および対応のデータパケット）に対して用いられる。一般的に、コマンドはトランザクションを開始し、よってコマンドは付加的なコマンドパケットの通信を生じさせない。さらに、さまざまなコマンドパケットは、デスティネーション（トランザクションのターゲット）に到達するまでこれらの間に順序がないので、互いに対してロジック／プロトコルコンフリクトを有さない。したがって、コマンドパケットは１つのバーチャルチャネル内に含まれることができる。
【００４８】
コマンドは、（コヒーレントファブリックにおけるコヒーレンシの維持のための）プローブコマンドパケットの生成および（データを送りトランザクションの肯定応答を提供するための）応答パケットの生成をもたらし得る。したがって、プローブパケットおよび応答パケットは、コマンドと同じバーチャルチャネルには含まれない（これにより資源コンフリクトおよびロジック的コンフリクトがデッドロックを生じさせることを防ぐ）。さらに、プローブパケットはプローブ応答および読出応答パケットの生成をもたらし得るので、応答パケットとは異なったバーチャルチャネルに入れられる。
【００４９】
応答パケットもまた、付加的な応答パケットを生じさせる可能性がある（たとえば、SrcDoneおよびTgtDoneは、互いを生じさせ得る）。したがって、応答パケットは、他の応答パケットと同じバーチャルチャネルに入れられることにより、それらとのロジック的コンフリクトを生じさせる可能性がある。しかしながら、多数の応答バーチャルチャネルを設けることは、付加的なバーチャルチャネルを扱うための資源要求（すなわち、バッファ）が増大するので、不所望であるおそれがある。応答パケットは、直接的または（たとえば、コマンドパケットに応答して生成されたプローブを介する）間接的のいずれであっても、コマンドパケットの結果である。ノード１２Ａ−１２Ｄ（および以下に示すＩ／Ｏノード）は、コマンドパケットとのトランザクションを開始する前に、トランザクションの間に生成され得る応答パケット（どのような応答データパケットも含む）を処理するために十分な資源を割当てるよう構成される。同様に、プローブコマンドパケットを生成する前に、ノードはプローブ応答パケットを処理するために十分な資源を割当てるよう構成される（応答パケットがそのノードに返される場合）。この態様で、すべての応答パケットがデスティネーションノードによって受取られる。したがって、応答パケットは１つの応答バーチャルチャネルにマージされる。応答パケット（および対応のデータパケット）は、応答バーチャルチャネル内を移動する。
【００５０】
最後に、プローブコマンドパケットはプローブバーチャルチャネル内を移動する。プローブは、さまざまなメモリ場所のキャッシュ済コピーと、メモリ場所自体との間のコヒーレンシを維持するために用いられる。メモリコントローラによって処理される第１のコマンドパケットに対応するコヒーレンシアクティビティは、次のコマンドパケットが処理される前に完了させなければならない可能性がある。たとえば、もしメモリコントローラの待ち行列が同じキャッシュブロックのコマンドで満たされていれば、最初のコマンドが完了するまでメモリコントローラでさらなるコマンドパケットの処理は起こらない。したがって、プローブコマンドパケット（および応答）は、別々のバーチャルチャネルに与えられて、他のバーチャルチャネル内のパケットとの資源コンフリクトが、プローブコマンドパケットをブロックしないことを確実にする。
【００５１】
テーブル４２はまた、バーチャルチャネルが適用されるコンピュータシステム１０におけるリンクの形成を示す（コヒーレントノードの間のコヒーレントリンクおよび非コヒーレントノードの間の非コヒーレントリンク）。非コヒーレントおよびコヒーレントリンクは両方とも、コマンドおよび応答バーチャルチャネルをサポートする。非コヒーレントリンクはコヒーレンシをサポートせず（プローブコマンドパケットはこれを確実にするために用いられる）、したがって、プローブバーチャルチャネルをサポートしない。
【００５２】
バーチャルチャネル−コヒーレントファブリック
図１０を参照すると、例示的な処理ノード１２Ａの一実施例のブロック図が示される。他の処理ノード１２Ｂ−１２Ｄも同様に構成され得る。他の実施例も可能であり企図される。図１０の実施例においては、処理ノード１２Ａはインターフェイスロジック１８Ａ、１８Ｂ、および１８Ｃおよびメモリコントローラ１６Ａを含む。さらに、処理ノード１２Ａは、プロセッサコア５２、キャッシュ５０、パケット処理ロジック５８、および任意で第２のプロセッサコア５６および第２のキャッシュ５４を含む。インターフェイスロジック１８Ａ−１８Ｃはパケット処理ロジック５８に結合される。プロセッサコア５２および５６は、キャッシュ５０および５４にそれぞれ結合される。キャッシュ５０および５４はパケット処理ロジック５８に結合される。パケット処理ロジック５８はメモリコントローラ１６Ａに結合される。
【００５３】
一般的に、パケット処理ロジック５８は、処理ノード１２Ａが結合されるリンクで受取られる制御パケットに応答し、キャッシュ５０および５４および／またはプロセッサコア５２および５６に応答して制御パケットを生成し、サービスに対してメモリコントローラ１６Ａによって選択されるトランザクションに応答してプローブコマンドおよび応答パケットを生成し、かつ別のノードへの送信のために、ノード１２Ａが中間のノードとなるパケットを、インターフェイスロジック１８Ａ−１８Ｃの別のものへ経路制御するよう構成される。インターフェイスロジック１８Ａ、１８Ｂ、１８Ｃは、ロジックを含み、パケットを受けて、パケット処理ロジック５８によって用いられる内部クロックにパケットを同期させる。
【００５４】
パケット処理ロジック５８は、コンピュータシステム１０によってサポートされるバーチャルチャネルから独立して資源をサポートするためのハードウェアを含む。たとえば、パケット処理ロジック５８はバーチャルチャネルごとに別々のバッファを提供する。図１１に例示的な実施例を示す。代替的な実施例は、インターフェイスロジック１８Ａ−１８Ｃ内、または他のいずれかの好適な場所にバーチャルチャネルから独立して資源を提供するためのハードウェアを提供する。
【００５５】
キャッシュ５０および５４は、高速キャッシュメモリを含み、該高速キャッシュメモリは、データのキャッシュブロックを記憶するよう構成される。キャッシュ５０および５４は、プロセッサコア５２および５６の内部にそれぞれ統合され得る。これに代えて、キャッシュ５０および５４は所望のようにバックサイドキャッシュ構成またはインライン構成でプロセッサコア５２および５６に結合されてもよい。さらに、キャッシュ５０および５４は、キャッシュの階層として実現されてもよい。（階層内で）プロセッサコア５２および５６に近い方のキャッシュは、所望であればプロセッサコア５２および５６内に統合されてもよい。
【００５６】
プロセッサコア５２および５６は、予め定められた命令セットに従って命令を実行するための回路を含む。たとえば、ｘ８６命令セットアーキテクチャが選択される。これに代えて、アルファ、パワーＰＣ、または他のどのような命令セットアーキテクチャを選択してもよい。一般的に、プロセッサコアはデータおよび命令のためにキャッシュにアクセスする。もしキャッシュミスが検出されると、読出要求が生成され、ミスのあるキャッシュブロックがマッピングされたノード内のメモリコントローラに送信される。
【００５７】
図１１を参照すると、パケット処理ロジック５８の一実施例のブロック図が示される。他の実施例が可能であり企図される。図１１の実施例においては、パケット処理ロジック５８は、第１の組の制御およびデータパケットバッファ６０、第２の組の制御およびデータパケットバッファ６２、第３の組の制御およびデータパケットバッファ６４、制御ロジック６６、データバッファプール６８、および応答カウンタプール７０を含む。制御およびデータパケットバッファ６０は、コマンドバッファ（ＣＢ）６０Ａ、応答バッファ（ＲＢ）６０Ｂ、プローブバッファ（ＰＢ）６０Ｃ、コマンドデータバッファ（ＣＤＢ）６０Ｄ、および応答データバッファ（ＲＤＢ）６０Ｅを含む。同様に、制御およびデータパケットバッファ６２は、コマンドバッファ（ＣＢ）６２Ａ、応答バッファ（ＲＢ）６２Ｂ、プローブバッファ（ＰＢ）６２Ｃ、コマンドデータバッファ（ＣＤＢ）６２Ｄ、および応答データバッファ（ＲＤＢ）６２Ｅを含む。制御およびデータパケットバッファ６４は、コマンドバッファ（ＣＢ）６４Ａ、応答バッファ（ＲＢ）６４Ｂ、プローブバッファ（ＰＢ）６４Ｄ、コマンドデータバッファ（ＣＤＢ）６４Ｄおよび応答データバッファ（ＲＤＢ）６４Ｅを含む。制御およびデータパケットバッファ６０はインターフェイスロジック１８Ａによって受取られたパケットを受取るよう結合される（たとえば、ライン２４Ｂ上）。同様に、制御およびデータパケットバッファ６２は、インターフェイスロジック１８Ｂによって受取られたパケットを受取るよう結合され、制御およびデータパケットバッファ６４はインターフェイスロジック１８Ｃによって受取られたパケットを受取るよう結合される。制御およびデータパケットバッファ６０、６２、および６４は、制御ロジック６６に結合される。さらに、応答データバッファ６０Ｅ、６２Ｅ、および６４Ｅが、データバッファプール６８に結合される。データバッファプール６８および応答カウンタプール７０は、制御ロジック６６に結合され、これはさらにノードＩＤレジスタ７２、制御パケットアクティブレジスタ７４Ａ−７４Ｃおよびデータパケットアクティブレジスタ７６Ａ−７６Ｃを含む。制御ロジック６６は、受信および送信インタフェースを介してインターフェイス１８Ａ−１８Ｃに結合され、かつ同様にメモリコントローラ１６Ａおよびキャッシュ５０（および任意のキャッシュ５４）に結合される。データバッファプール６８がさらにメモリコントローラ１６Ａおよびキャッシュ５０（および任意のキャッシュ５４）に結合される。
【００５８】
制御およびデータパケットバッファの組の各々が、バーチャルチャネルごとに異なったバッファを提供する。すなわち、本実施例においては、コマンドバッファ６０Ａはコマンドバーチャルチャネルに割当てられ、応答バッファ６０Ｂは応答バーチャルチャネルに割当てられ、プローブバッファ６０Ｅはプローブバーチャルチャネルに割当てられる。この態様で、１つのバーチャルチャネルにおける制御パケットの受信は、別のバーチャルチャネルにおける制御パケットの受信によって妨げられない。各バーチャルチャネルからの制御パケットは、そのバーチャルチャネルに対応する制御パケットバッファに記憶され、よって別のバーチャルチャネルからの制御パケット（異なった制御パケットバッファに記憶される）と物理的コンフリクトを起こさない。同様に名称がつけられるバッファ６２および６４内のバッファは、上述のようにバーチャルチャネルに割当てられる。
【００５９】
同様に、データパケットバッファは、データパケットを担持する各バーチャルチャネルに与えられる（プローブバーチャルチャネルはこの実施例においてはデータパケットを担持しない）。すなわち、本実施例においては、コマンドデータバッファ６０Ｄはコマンドバーチャルチャネルに割当てられ、応答データバッファ６０Ｅは応答バーチャルチャネルに割当てられる。同様に名称がつけられるバッファ６２および６４内のバッファは、上述のようにバーチャルチャネルに割当てられる。
【００６０】
本実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、受取ったパケットを制御パケット（制御経路内に提供される）と、データパケット（データ経路に提供される）とに分割するよう構成される。制御経路は、制御パケットバッファに結合され（たとえば、バッファ６０Ａ−６０Ｃがインターフェイスロジック１８Ａからの制御経路に結合される）、データ経路はデータパケットバッファに結合される（たとえば、バッファ６０Ｄ−６０Ｅがインターフェイスロジック１８Ａからのデータ経路に結合される）。制御ロジック６６は、受信および送信インターフェイスを介してパケットの表示を受取るよう結合され、かつ受取ったパケットのバッファエントリを割当てるよう構成される。他の企図される実施例においては、受取ったパケットはインターフェイスロジックによって制御およびデータパケットに分割されない。そのような実施例においては、制御ロジック６６はＣＴＬ信号を受取って、ビット時間のデータパケットとビット時間の制御パケットとを区別する。
【００６１】
一般的に、制御ロジック６６は、他のバッファ内のパケットから独立してさまざまなバッファからのパケットを処理するよう構成される。したがって、異なったバーチャルチャネル内を移動するパケットは互いに対して物理的にコンフリクトしない。
【００６２】
制御ロジック６６は、バッファ６０、６２および６４内の制御パケットを調べて、制御パケットがノード１２Ａ（「このノード」）に対して宛先決めされているか、または別のノードに送られるべきかどうかを判断する。ノードＩＤレジスタ７２は、このノードのノードＩＤを記憶し、制御ロジック６６はノードＩＤを用いて制御パケットがこのノードに対して宛先決めされているかどうかを判断する。本実施例においては、プローブバーチャルチャネル内のパケットはブロードキャストパケットであり、よってこのノードと、このノードがパケットを送るべき他のノードに対して宛先決めされる（よってノードＩＤ比較は用いられない）。他のバーチャルチャネル内のパケットは方向付けられた（directed）パケットであり、これに対してデスティネーションノードフィールドは、パケットがこのノードに宛先決めされているか、または別のノードに送られるべきであるかどうかを識別する。制御ロジック６６は、１つ以上の経路制御テーブルを含み、これはデスティネーションノードごとに、インターフェイスロジック１８Ａ−１８Ｃのどれがパケットを送るために用いられるべきかを示す。制御ロジック６６は、識別されたインターフェイスロジック１８Ａ−１８Ｃを介して送信された受信パケットを受けるよう結合される受信ノードが、制御パケットに対応するバーチャルチャネルに対する空いた制御パケットバッファを有している場合に、制御パケットを送り得る。さらに、制御パケットがデータパケットを識別すると、制御パケットに対応するバーチャルチャネルに対する空いたデータパケットバッファは、制御パケットおよび後続の特定されたデータパケットを送る前に識別される。制御ロジック６６は、制御パケット（およびもし特定されていればデータパケット）が送られるべきであるかどうかを判断し、受信および送信インターフェイスを用いてパケットを識別されたインターフェイスロジック１８Ａ−１８Ｃに送り、これは次いでパケットを受信ノードに送る。また、制御ロジック６６は、対応の種類のバッファが空いたことを記憶して、次の情報パケットがインターフェイス１８Ａ−１８Ｃを介して送られるようにし、パケットはノード１２Ａによって受取られて、受信インターフェイスの送信ノードに対する空きバッファを示す。
【００６３】
一方、もし制御パケットがこのノードに宛先決めされていれば、制御ロジック６６はパケットの種類に依存してパケットを処理する。たとえば、もし制御パケットがメモリコントローラ１６Ａに標的を定められたコマンドであれば、制御ロジック６６は制御パケットをメモリコントローラ１６Ａに運ぶことを試みる。メモリコントローラ１６Ａは、たとえば処理されるべきトランザクションに対して待ち行列を用い、かつ待ち行列がフルであれば制御パケットを拒絶し得る。プローブパケットを処理するために、制御ロジック６６はキャッシュ５０および５４（およびプロセッサコア５２および５６の内部のいずれのキャッシュでも）と通信して、アドレス指定されたキャッシュブロックのステータスを判断する。制御ロジック６６は、ステータスを備えたプローブ応答パケット（またはもしキャッシュブロックがノード内で変更されていれば、読出応答パケットとデータ）を生成し、プローブ応答パケットを送信する（受信ノードバッファが利用可能である場合）。
【００６４】
受取ったパケットの処理に加えて、制御ロジック６６は、キャッシュ５０および５４からのフィル要求およびヴィクティムブロックに応答してパケットを生成し、かつプロセッサコア５２および５６からの直接の要求に応答してパケットを生成する（たとえば、キャッシュ不可能要求、Ｉ／Ｏ要求など）。さらに、応答パケットはメモリコントローラに応答して生成され、送信に対するデータを提供、またはトランザクションを完了させる。制御ロジック６６は、メモリコントローラ１６に応答して、処理に対する対応のコマンドを選択してプローブコマンドパケットを生成し、プローブコマンドパケットをブロードキャストし得る（他のパケット送信と同様に、受信ノードバッファが利用可能であると想定する）。
【００６５】
上述のように、ノードはそのノードによって生成された制御パケットに対応する応答パケットを処理するための十分な資源を提供する。本実施例においては、制御ロジック６６はパケットを生成するが、このパケットは２つの場合においてノードに返される応答パケットをもたらし得る：（ｉ）トランザクションを開始するためのコマンドパケットを生成する場合（たとえば、キャッシュ５０および５４、またはプロセッサコア５２および５６からの要求に応答する）；および（ii）メモリコントローラ１６Ａを標的とする制御パケットに対するプローブパケットを生成する場合。より特定的には、（ii）の場合は、メモリコントローラ１６Ａを標的とするサイズ決めされた書込の場合に生じ得る。いずれの場合においても、制御ロジック６６は、応答パケットを処理するための資源を割当てる。
【００６６】
本実施例においては、制御ロジック６６は応答を処理するためにデータバッファプール６８および応答カウントプール７０からの資源を割当てる。データバッファプール６８は、データのキャッシュブロックを記憶するための複数のエントリを含み得る一方、応答カウンタプール７０は複数のカウンタを含み得る。データバッファプールエントリは、トランザクションに対応する応答データを記憶するために割当てられ得る。カウンタは、受取った応答をカウントする（かつ、プローブ応答において提供され得るいかなる状態情報をも保持する）ために割当てられ得る。応答パケットは、割当てられたカウンタを用いて（期待される数の応答に到達するまで）カウントされ、応答パケットによって受取られたデータは割当てられたデータバッファに記憶され得る。トランザクションに関与する最大２つのパケットがデータを担持し得ることに留意されたい（１つは、MemCancel応答パケットが、応答パケットの送信の前にメモリコントローラに到達しなかった場合の、標的決めされたメモリコントローラからのものであり、他方はデータの変更されたキャッシュ済コピーを有するプローブされたノードからのものである）。２つのデータパケットが受取られた場合には、プローブされたノードからのパケットが保持されて、メモリコントローラからのパケットは捨てられる。
【００６７】
一旦期待される応答の各々が受取られ、応答データが受取られていると、制御ロジック６６は行なわれているトランザクションのタイプに依存して、データをメモリコントローラ１６Ａまたはキャッシュ５０または５４に、送信する。たとえば、もし応答がパケット処理ロジック５８によって生成されたプローブコマンドに応答して生成されたプローブ応答であれば、応答データはメモリコントローラ１６Ａに送信され得る。これに代えて、もし応答が読出トランザクションによるものであれば、データはキャッシュ５０または５４に送信される。
【００６８】
データバッファプール６８は、ノード１２Ａから送信されるべきデータを記憶するためにも用いられることに留意されたい。たとえば、ノード１２Ａからの書込コマンドに対するヴィクティムブロックデータまたは書込データは、データバッファプール６８に記憶され得る。これに代えて、別々のバッファがこのデータのために提供されてもよい。さらに、さまざまなトランザクションに対して用いられるバッファのプールを提供する代わりに、所望のように、トランザクションタイプによって別々のバッファが提供されてもよい。
【００６９】
ここで用いられる場合、バッファとは後の検索のために情報の１つ以上の項目を記憶するために用いられる記憶要素である。バッファは、１つ以上のレジスタ、ラッチ、フリップフロップ、または他のクロックされる記憶装置を含む。これに代えて、バッファは好適に構成された組のランダムアクセスメモリ（ＲＡＭ）セルを含んでもよい。バッファは、いくつかのエントリに分割され、各エントリはバッファが設計されている情報の１つの項目を記憶するよう設計される。エントリは、いかなる好適な様式においても割当てられおよび割当て解除され得る。たとえば、バッファはより古いエントリが削除されるにつれエントリがシフトされる、シフト先入れ先出し（ＦＩＦＯ）バッファで動作されてもよい。これに代えて、ヘッドおよびテールポインタを用いて、バッファ内の最も古いおよび最も新しいエントリを示し、エントリはバッファから削除されるまでバッファの特定の記憶場所に保持されてもよい。ここで使用される「制御ロジック」という用語は、説明された動作を実現するために、入力に対して動作し、これに応答して出力を生成する、組合わせロジックおよび／またはステートマシンのいかなる組合せをも指す。
【００７０】
特定の一実施例においては、パケットは一連のビット時間としてインターフェイスロジック１８Ａ−１８Ｂから受取られる。インターフェイスロジック１８Ａ−１８Ｃは、制御またはデータビット時間が送信されているかどうかを示し、制御ロジック６６は、ビット時間を記憶するための適切なバッファを生じさせる。制御ロジック６６は、制御パケットアクティブレジスタ７４およびデータパケットアクティブレジスタ７６を用いて、現在受取られている制御パケットまたはデータパケットがどのバーチャルチャネルに属しているかを識別し得る。制御パケットアクティブレジスタ７４は、インタフェースロジック１８Ａ−１８Ｃごとに与えられる（たとえば、制御パケットアクティブレジスタ７４Ａはインターフェイス１８Ａに対応し得る）。同様に、データパケットアクティブレジスタ７６はインターフェイスロジック１８Ａ−１８Ｃごとに与えられる（たとえば、データパケットアクティブレジスタ７６Ａはインターフェイス１８Ａに対応し得る）。第１のビット時間の制御パケットに応答して、制御ロジック６６はコマンドフィールド（第１のビット時間内）をデコードし、制御パケットがどのバーチャルチャネルに割当てられているかを判断する。制御ロジック６６は、バッファエントリを対応の（制御パケットが受取られるインターフェイスロジック１８Ａ−１８Ｃに対応する組内の）制御パケットバッファに割当て、および、パケットが受取られるインターフェイスロジック１８Ａ−１８Ｃに対応する制御パケットアクティブレジスタ７６が、その制御パケットバッファを示すよう設定する。同じインターフェイスロジック１８Ａ−１８Ｃからの後続の制御パケットビット時間は、各ビット時間の制御パケットが受取られるまで、示されたバッファ内の示されたエントリに記憶される。もし制御パケットがデータパケットを特定すると、制御ロジック６６は、データパケットバッファエントリを識別されたバーチャルチャネルに対応するデータパケットバッファに割当てる。データパケットビット時間は、各ビット時間のデータが受取られるまで、示されたバッファの示されたエントリ内に記憶される。代替的な実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、ビット時間のパケットを集め、パケット全体をパケット処理ロジック５８に送信してもよい。そのような実施例においては、制御パケットアクティブレジスタ７４およびデータパケットアクティブレジスタをなくしてもよい。さらに別の実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、パケット処理ロジック５８への並行した送信のためのいくつかのビット時間を集めるが、ビット時間の数がパケットよりも少ない可能性がある。さらに別の実施例においては、バッファ６０、６２および６４はパケット処理ロジック５８の代わりにそれぞれのインターフェイスロジック１８Ａ−１８Ｃ内に場所決めされてもよい。
【００７１】
図１１に示される実施例においては、インターフェイスロジック１８Ａ−１８Ｃごとにバッファの別々の組が提供される。代替的な実施例においては、バッファはインターフェイスロジックの間で分割され得る（バーチャルチャネルタイプごとの）プールとして提供されてもよい。そのような実施例は、別のノードには結合されないインターフェイスロジック（たとえば、図１の例におけるインターフェイスロジック１８Ｃ）に、ゼロバッファを与えることによりバッファを活用し得る。インターフェイスロジック１８Ｃに割当てられたであろうバッファは、インターフェイスロジック１８Ａ−１８Ｂによって用いられるために割当てられる。
【００７２】
図１２を参照すると、データバッファプール６８内のデータバッファプールエントリ８０の一実施例を例示する図が示される。他の実施例も可能であり企図される。図１２の実施例においては、データバッファプールエントリ８０は、ソースタグフィールド８２、ソースノードフィールド８４、ソースユニットフィールド８８、およびデータフィールド８６を含む。
【００７３】
制御ロジック６６が、トランザクションに対する応答データパケットを記憶するためにデータバッファプールエントリ８０を割当てる場合、制御ロジック６６はトランザクションのソースノード、ソースユニット、およびソースタグを、ソースノードフィールド８４、ソースユニットフィールド８８、およびソースタグフィールド８２にそれぞれ記憶する。ソースノード、ソースユニット、およびソースタグは独自に未処理の（outstanding）トランザクションを識別し、かつソースノード、ソースユニット、およびソースタグは未処理のトランザクションに対応する応答パケットによって担持されるために、トランザクションの応答パケット（および対応のデータパケット）が識別されて、データパケットは割当てられたエントリに記憶され得る。言換えると、応答データパケットを特定する応答パケットが受取られると、応答パケットのソースノード、ソースユニット、およびソースタグは、ソースノードフィールド８４、ソースユニットフィールド８８およびソースタグフィールド８４と比較されて、応答データのために先行して割当てられたデータバッファプールエントリ８０の位置を突止め、データは応答データバッファからデータバッファプールエントリ８０のデータフィールド８６にコピーされ得る。データフィールド８６はデータのキャッシュブロックを含み得る。
【００７４】
図１３を参照すると、応答カウンタプール７０内の応答カウンタ９０の一実施例を例示する図が示される。他の実施例も可能であり企図される。図１３の実施例においては、応答カウンタ９０はソースタグフィールド９２、ソースノードフィールド９４、ソースユニットフィールド９５、応答カウントフィールド９６、および受信ステートフィールド９８を含む。
【００７５】
制御ロジック６６が、トランザクションに対する応答カウントを記憶するために応答カウンタ９０を割当てる場合、制御ロジック６６はソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２にそれぞれトランザクションのソースノード、ソースユニットおよびソースタグを記憶し得る。ソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２は、データバッファプールエントリ８０の対応のフィールド８４、８８、および８２と同様に用い得る。
【００７６】
トランザクションの割当の際に、応答カウントフィールド９６は、トランザクションに対して期待される応答の数に初期化され得る。ソースノード、ソースユニット、およびソースタグがフィールド９４、９５および９２にそれぞれ記憶された応答パケットが受取られると、応答カウントがデクリメントされる。応答カウンタが０に到達すると、すべての応答は受取られ、トランザクションはコミットされている。これに代えて、カウントは０に初期化されて、応答パケットは期待される数の応答が受取られるまで応答カウントをインクリメントしてもよい。
【００７７】
応答ステートフィールド９８は、データが受取られるであろう状態を示すために用い得る。状態は、ノード１２Ａがキャッシュブロックの受信の際に獲得した、キャッシュブロックに対するアクセス権およびキャッシュブロックに対するコヒーレンシを維持するための責任を示す。たとえば、ＭＯＥＳＩ（変更、所有、排他的、共用、および無効）コヒーレンシ状態が用いられて、受信状態フィールド９８は、サポートされる状態のうちの１つに符号化される。これに代えて、他のいかなる好適な組のコヒーレンシ状態が用いられてもよい（たとえばＭＥＳＩ状態）。受信状態フィールド９８は、どの他のノードもトランザクションによって送られるキャッシュブロックのコピーを有さない場合に獲得される状態に初期化され得る。プローブ応答が受取られて、キャッシュブロックのコピーがプローブノードによって維持されているか、またはダーティデータが提供されていることを示すと、受信状態フィールド９８はそれに従って更新される。一実施例においては、共用ビットがプローブ応答パケットに含まれて、キャッシュブロックのコピーがプローブ応答を提供したプローブされたノードによって維持されていることを示し得る。さらに、プローブされたノードからの読出応答パケットの受信は、ノードがキャッシュブロックのダーティコピーを有することを示す。読出応答パケットはまた、プローブされたノードによってコピーが維持されているかどうかを示すための共用ビットを含み得る。
【００７８】
データバッファプール６８および応答カウンタプール７０は、未処理のトランザクションに対する応答を扱うための一例にすぎないことに留意されたい。別の実施例においては、未処理のトランザクションのテーブルが維持される。テーブルは、上述のものと同様のソースノード、ソースユニット、ソースタグ、データ、受信状態、および応答カウント（または、制御ロジック６６がすべての応答が受取られたことを判断し得る等価の情報）を含む。いかなる好適な組の資源をも用い得る。
【００７９】
図１４は、パケットを受信するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートである。他の実施例も可能であり企図される。示される実施例は、パケットを一連のビット時間としてパケット処理ロジック５８内に受取る。他の実施例は、ビット時間のパケットをインタフェースロジック１８Ａ−１８Ｃに累積させ、完全なパケットをパケット処理ロジック５８に提供するが、この場合パケットの受信をビット時間で管理することに関連するステップは削除される。図１４に示されるステップは、理解を助けるために特定の順序で示されているが、いかなる好適な順序をも用い得る。さらに、ステップはパケット処理ロジック５８内の組合せロジックを用いて並列に行なわれてもよい。図１４に示されるステップは、インターフェイスロジック１８Ａ−１８Ｃの各々から独立して並列に行われ得るが、これはインターフェイスロジックごとにビット時間が並行に受信されるためである。
【００８０】
パケット処理ロジック５８は、受信したビット時間がデータパケットの一部であるか、またはコマンドパケットの一部であるかを示すインターフェイスロジックからの信号を受取る。もしビット時間がデータパケットビット時間であれば（判断ブロック１００）、ビット時間はそのインターフェイスロジックに対応するデータパケットアクティブレジスタによって示されるデータバッファ（およびデータバッファ内のエントリ）によって記憶される（ステップ１０２）。もしデータパケットビット時間がデータパケットの最後のビット時間であると、制御ロジック６６は対応のデータパケットアクティブレジスタを無効化する。一方、もしビット時間が制御パケットビット時間であれば、パケット処理ロジック５８は制御パケットが現在受取りが進行中のものであるかどうかを判断する（たとえば、制御パケットアクティブレジスタが有効であるかどうか、判断ブロック１０４）。もし制御パケットが現在進行中であれば、ビット時間は制御パケットアクティブレジスタによって示される制御パケットバッファに記憶される（ステップ１０６）。もし制御パケットビット時間が制御パケットの最後のビット時間であれば、制御ロジック６６は対応の制御パケットアクティブレジスタを無効化し得る。
【００８１】
これに代えて、制御パケットは現在進行中ではない可能性がある。この場合には、パケット処理ロジック５８は新しく受取られた制御パケットのコマンドフィールドをデコードして、制御パケットが属するバーチャルチャネルを識別する（ステップ１０８）。識別されたバーチャルチャネルに対応する制御パケットバッファエントリは割当てられ、制御パケットビット時間は割当てられた制御パケットバッファエントリに記憶される。
【００８２】
さらに、パケット処理ロジック５８は、制御パケットが後続のデータパケットを特定するかどうかを判断する（判断ブロック１１０）。データパケットが特定されると、パケット処理ロジック５８は識別されたバーチャルチャネルに対応するデータバッファからデータバッファエントリを割当て、そのデータバッファ（およびエントリ）を示すようデータパケットアクティブレジスタを更新する（ステップ１１２）。
【００８３】
ここで図１５を参照して、コマンドパケットを処理するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１５に示されるステップは理解を容易にするためある特定の順序にて示されるが、任意の好適な順序を用いてよい。さらに、ステップは、並列に、組合せロジックをパケット処理ロジック５８内にて用いながら実行してもよい。図１５に示されるステップは並列かつ独立して各インターフェイスロジック１８Ａ〜１８Ｃおよび／または各コマンドパケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。代替的に、１つのコマンドパケット（またはインターフェイスロジック１８Ａ〜１８Ｃにつき１つのコマンドパケット）を、処理に対し、好適な公平性アルゴリズムに従って選択してもよい。一般に、１つのバーチャルチャネルから処理のために選択されたパケットはあるチャネル内におけるパケットに対する順序付け規則に従う（たとえば、同じソースから同じデスティネーションへのパケットは順に選択される）が、パケットの、処理に対する選択は、所望されかつ順序付け規則が許す場合には、順序が乱れた状態でなされてもよい。
【００８４】
パケット処理ロジック５８はコマンドパケットの標的がこのノードであるかどうかを判断する（判断ブロック１２６）。たとえば、パケット処理ロジック５８はコマンドパケットのデスティネーションノードフィールドに記録されるデスティネーションノードをノードＩＤレジスタ７２に記憶されるノードＩＤと比較してもよい。これらのノードが一致する場合、そのコマンドはこのノードを標的としている。コマンドがこのノードを標的としない場合には、パケット処理ロジック５８はそのコマンドパケット（および特定される場合には対応のデータパケット）をデスティネーションノードに応答して送る（ステップ１２８）。たとえば、パケット処理ロジック５８は、パケットを特定のデスティネーションノードへ送るためインターフェイスロジック１８Ａ〜１８Ｃの１つを送信インターフェイスとして識別するパケット経路制御テーブルを維持してもよい。対応のコマンドバッファ（およびデータパケットが特定される場合にはデータバッファ）が、パケット経路制御テーブルにより特定されるリンクに結合される受信ノードにおいて利用可能であるなら、パケット処理ロジック５８はコマンドパケットを送る。加えて、コマンドパケットがデータパケットを特定する場合には、コマンドパケットを送ることは、送信リンク上のデータパケットが活性状態ではあるが未だ送信されていない場合には、ストールされてもよい。
【００８５】
コマンドパケットがこのノードを標的としている場合、パケット処理ロジック５８はコマンドパケット（および適用可能である場合には対応のデータパケット）をメモリコントローラ１６Ａに与えてもよい（ステップ１３０）。一旦コマンドパケットが処理される（送られるかまたはこのノードによって受け入れられる）と、そのコマンドパケットはコマンドバッファエントリから取除かれ（適用可能である場合にはデータはコマンドデータバッファエントリから取除かれ）ることに注目されたい。
【００８６】
プローブコマンドは同じ態様で処理されてもよいが、ただし、プローブコマンドは後のデータパケットを特定せず、したがって、データパケットに対するチェックは無視されるかもしれないことに注意されたい。さらに、プローブは内部的に（たとえば当該ノード内においてキャッシュをプローブすることにより）処理されるとともに送られてもよく、なぜならば、それらは放送パケットであるからである。ノードはキャッシュのプローブ後にプローブ応答パケットを発生し送信してもよい。
【００８７】
選択されるコマンドパケットが対応のデータパケットを特定する場合には、さまざまな実施例によってそのコマンドパケットの処理をたとえそのデータパケットがまだ受取られていなくても行なってもよく、またはそのデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。コマンドパケットが処理されるときにデータパケットが受取られていなかった場合には、そのデータパケットはそれが受取られるときに上述のように処理されてもよい。
【００８８】
図１６を参照して、応答パケットを処理するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１６に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。さらに、ステップは、並列に、組合せロジックをパケット処理ロジック５８内で用いながら実行してもよい。図１６に示されるステップは並列かつ独立して各インターフェイスロジック１８Ａ〜１８Ｃおよび／または各応答パケットバッファごとに実行してもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。
【００８９】
パケット処理ロジック５８は応答パケットのデスティネーションノードがこのノードであるか否かを判断する（判断ブロック１４４）。デスティネーションノードが別のノードである場合に、応答バーチャルチャネルに対する空いているバッファエントリがその応答パケットが送られるリンク上の受信機にある場合には、パケット処理ロジック５８はその応答パケット（および適用可能である場合には対応のデータパケット）を送る（ステップ１４６）。
【００９０】
応答パケットのデスティネーションノードがこのノードである場合には、パケット処理ロジック５８は対応の応答カウンタを減分し受信状態を更新するよう構成されるが、それは、その応答が、受信状態がデフォルト状態から変更されるべきである旨を示すプローブ応答である場合である（ステップ１４８）。加えて、その応答パケットがデータパケットを特定する場合には、そのデータパケットを、対応の応答データバッファから、その応答に割当てられたデータバッファに移動させる（ステップ１５０）。
【００９１】
カウンタを減分した後、パケット処理ロジックはカウンタをテストしてすべての応答パケットが受取られ処理されたか否かを判断する（判断ブロック１５２）。すべての応答パケットが受取られ処理されたと判断される場合には、パケット処理ロジック５８はメモリコントローラ１６Ａまたはキャッシュ５０および５４に対しそれらがコマンドを完了してもよい旨を知らせ、データバッファからの関連のデータおよび応答カウンタからの受信状態を与えてもよい（適用可能である場合−−ステップ１４５）。一旦応答パケットが処理される（送られるかまたはこのノードによって受入れられる）と、その応答パケットは応答バッファエントリ（および適用可能である場合には応答データバッファエントリ）から取除かれる。
【００９２】
上の議論において、コマンドパケットまたは応答パケットの処理の「中断」という語が用いられている。一般に、処理が「中断」されるのは、その特定のパケットの処理が、中断の理由が取除かれるまで停止される場合である。同じタイプの他のパケットの処理をそのコマンドまたは応答の処理の中断中に行なってもよい。
【００９３】
選択される応答パケットが対応のデータパケットを特定する場合、さまざまな実施例による応答パケットの処理をたとえそのデータパケットがまだ受取られていなくても（つまりそのデータパケットがまだデータバッファ内になくても）行なってもよく、またはデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。応答パケットが処理されるときにデータパケットが到着していない場合には、そのデータパケットはそれが受取られるときに上記のように処理されてもよい。
【００９４】
図１７を参照して、ノードが結合されるリンク上においてパケットを起動するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１７に示されるステップは理解を容易にするためある特定の順序にて示されるが、任意の好適な順序を用いてよい。さらに、ステップを、並列に、組合せロジックをパケット処理ロジック５８内にて用いながら実行してもよい。パケット処理ロジック５８はリンク上のパケットを応答的に起動することによりキャッシュ５０および５４からの要求／犠牲ブロックならびに／またはコア５２および５６により実行される動作を満たしてもよい。加えて、プローブパケットの起動を、処理のためにメモリ動作を選択するメモリコントローラ１６Ａに応答して行なってもよい。応答パケットの起動は、プローブが処理された後、かつこのノードによりソースを与えられるかまたはこのノードを標的としているトランザクションが完了されたことに応答して行なわれてもよい。
【００９５】
パケット処理ロジック５８は、起動されるべきパケットの結果、データがこのノードに戻されるかもしれないか否かを判断する（判断ブロック１６０）。たとえば、ノードによって起動される読出トランザクションはデータがノードに戻されることを引き起こし、一方、ノードにより起動される書込トランザクションはデータがノードに戻されることを引き起こさない。ChangetoDirtyトランザクションの結果、データはノードに戻されるかもしれない（別のノードがキャッシュブロックに対しダーティ状態において影響を与えた場合）。同様に、プローブパケットはデータをこのノードへ戻すことを引き起こすかもしれないが、それは、別のノードがキャッシュブロックに対しダーティ状態において影響を及ぼしプローブ応答がこのノードに向けられる場合である。トランザクションの結果、データがこのノードに戻される場合には、パケット処理ロジック５８はあるデータバッファをデータバッファプール６８から割当てる（ステップ１６２）。
【００９６】
加えて、パケット処理ロジック５８はプローブ応答がこのノードに対しパケットに応答して戻されるか否かを判断する（ステップ１６６）。これが生ずるのはパケットがプローブであるかまたはパケットがこのノードへのプローブ応答をもたらすようなトランザクションを開始している場合であるかもしれない（たとえば読出トランザクション）。プローブ応答がこのノードに戻される場合、パケット処理ロジック５８は応答カウンタを応答に対し当該トランザクションに割当てその応答カウンタをコヒーレントファブリックにおけるノードの数に初期化する（ステップ１６８）。
【００９７】
パケット処理ロジック５８は、さらに、他の応答が、このノード（たとえばSrcDone、TgtDoneなど）に対し、起動中のパケットに応答して戻されるかどうかを判断する（ステップ１６４）。そのような他の応答が戻される場合には、パケット処理ロジック５８は応答カウンタを割当て初期カウントを１に設定する（ステップ１６５）。この後、パケット処理ロジック５８はパケットを送る（ステップ１７０）。
【００９８】
予め資源を割当てることにより応答パケット（データを含む）の取扱いをトランザクションの起動前に行なうことにより、応答パケットは受信で処理可能である。したがって、ある応答パケットは他の応答パケットとロジック的／プロトコルコンフリクトを有するかもしれないが、応答パケットは応答バーチャルチャネルにマージされるかもしれず、なぜならば、物理的コンフリクトは各応答パケットがそのデスティネーションノードに到着するにつれ処理されることにより取除かれるかもしれないからである。
【００９９】
次に図１８を参照して、バッファ解放フィールドを含む情報パケット１８０の一実施例を示すブロック図が示される。他の実施例も可能であり意図される。バッファ解放フィールドは各バッファのタイプごとに含まれる。RespDataフィールドは応答データバッファに対応する。Responseフィールドは応答バッファに対応する。同様に、CmdDataフィールドはコマンドデータバッファに対応し、Cmdフィールドはコマンドバッファに対応する。Probeフィールドはプローブバッファに対応する。
【０１００】
バッファ解放フィールドの各々は２つのビットを含み、単一のリンク上における送信機から受信機への１つの情報パケット１８０の伝送において解放されるべき０〜３の各タイプのバッファを斟酌する。３つより多いエントリをバッファ内において与えてもよく、複数の情報パケットを用いて１つのタイプのうちの３つより多くを解放してもよい。パケット処理ロジック５８はバッファカウントを各タイプのバッファおよび各インターフェイスロジック１８Ａ〜１８Ｃごとに含んで、各インターフェイスが結合されるリンクの他方端における受信機によって与えられる各タイプのバッファの総数を示してもよい。これらのカウンタの初期化は、パワーアップにおいて、情報パケットを受信機から送信機へ、バッファ解放フィールドがその受信機において利用可能なバッファ数にセットされる状態で送ることにより行なわれてもよい。３つより多いエントリは、複数の情報パケットを送ることにより示されてもよい。
【０１０１】
パケット処理ロジック５８はパケットをある所与のバーチャルチャネルにおいて送ってもよいが、それは、対応のタイプのバッファ（およびパケットがデータパケットを特定する場合にはデータバッファ）が、パケットが送られている受信機において利用可能である限りにおいてである。加えて、パケット処理ロジック５８は、ノード１２Ａにおいてパケット処理ロジック５８によるパケットの処理のため解放される、各インターフェイス１８Ａ〜１８Ｃに対する各タイプのバッファの数に注目する。周期的に、パケット処理ロジック５８は情報パケット１８０を各インターフェイスロジック１８Ａ〜１８Ｃを介して送り、そのリンク上の送信機に対し、パケット処理ロジック５８により解放されたバッファエントリの数を示す。
【０１０２】
バーチャルチャネル−非コヒーレントファブリック
ここで図１９を参照して、Ｉ／Ｏサブシステム２００の一実施例のブロック図を示す。他の実施例も可能であり意図される。図１９の実施例においては、Ｉ／Ｏサブシステム２００はホストブリッジ２０２と複数のＩ／Ｏノード２０４Ａ、２０４Ｂおよび２０４Ｃとを含む。ホストブリッジ２０２は、処理ノード１２Ｄに、ライン２４Ｉ〜２４Ｊを含むコヒーレントリンクを介して結合され、さらには、Ｉ／Ｏノード２０４Ａに、ライン２４Ｋ〜２４Ｌを含む非コヒーレントリンクを用いて結合される。Ｉ／Ｏノード２０４Ａ〜２０４Ｃはさらなる非コヒーレントリンクを用いてデージーチェーン構成で相互接続される（ライン２４Ｎ〜２４Ｏ）。
【０１０３】
一般に、Ｉ／Ｏノード２０４Ａ〜２０４ＣはトランザクションをＩ／Ｏサブシステム２００内にて起動してもよい。それらトランザクションは究極的には別のＩ／Ｏノード２０４Ａ〜２０４Ｃ、別の非コヒーレントリンク上のＩ／Ｏノード、またはメモリ１４にて標的としてもよい。単純化のため、トランザクションはホストブリッジ２０２とＩ／Ｏノード２０４Ａ〜２０４Ｃとの間においてその実際の標的にかかわらず実行されてよい。ホストブリッジ２０２はトランザクションをＩ／Ｏサブシステム２０２内において処理ノード１２Ａ〜１２Ｄからの要求に代わって起動してもよく、当該コヒーレントファブリックまたはコンピュータシステム内の他のホストブリッジを標的としているＩ／Ｏノード２０４Ａ〜２０４Ｃにより起動されるトランザクションを取扱ってもよい。したがって、Ｉ／Ｏノード２０４Ａ〜２０４Ｃにより送られるパケットはホストブリッジ２０２に向かってデージーチェーン接続を介して流れてもよい（「上流に」流れる）。ホストブリッジ２０２により送られるパケットは受信側Ｉ／Ｏノード２０４Ａ〜２０４Ｎの方向に流れてもよい（「下流に」流れる）。Ｉ／Ｏノードとホストブリッジとをデージーチェーンで相互接続しＩ／Ｏノードが（トランザクションレベルにおいて）ホストブリッジとのみ通信することにより、Ｉ／Ｏノードが他のノードではなくホストブリッジに直接接続されるように見えるＩ／Ｏサブシステム２００のロジック的な眺めが与えられる。
【０１０４】
Ｉ／Ｏサブシステム２００はホストブリッジに対しデージーチェーン相互接続の両端で接続されることによりリンク欠陥の場合における堅牢性を可能にするかまたは共有されるＩ／Ｏサブシステムを処理ノードのクラスタ間にて可能にしてもよい。１つのブリッジはマスタブリッジとして定義され、他のブリッジはスレーブブリッジとして規定されるであろう。リンク欠陥がない場合、サブシステム内におけるすべてのＩ／Ｏノードはマスタブリッジに属してもよい。リンク欠陥の検出で、その欠陥の両側のノードは再プログラミングされることによりホストブリッジに対しその欠陥の同じ側で属し、それによって、２つの異なるサブシステムを形成し処理ノードとの通信を維持する。Ｉ／Ｏノードを、２つのホストブリッジ間において、欠陥がない状態で分配する（２つのロジック的に別々のチェーンを形成する）ことにより、トラフィックも同様にバランスをとってもよい。
【０１０５】
パケットがデージーチェーンの端部（たとえば図１９の例においてはＩ／Ｏノード２０４Ｃ）に到達しＩ／Ｏノード２０４Ａ〜２０４Ｃのいずれもそのパケットを受入れない場合、エラーをそのチェーンの端部にあるノードによって発生してもよい。
【０１０６】
一般に、Ｉ／Ｏサブシステム２００はリンクを非コヒーレント相互接続として実現してもよい。その非コヒーレントリンクにおけるデータパケット定義は図６に示され記載されるものと同様であってもよく、その非コヒーレントリンクにおける情報パケット定義は図３および図１８において（Probeフィールドが予約される状態で）示されるパケット定義と同様であってもよい。コマンドおよび応答パケットは下に図２１および図２２において示される。
【０１０７】
バーチャルチャネルに関し、非コヒーレントリンクは上記のコヒーレントリンクと同じバーチャルチャネルを用いてもよい。しかしながら、プローブは非コヒーレントリンクにおいては用いられないので、プローブバーチャルチャネルは取除かれてもよい。図９に示される表４２は非コヒーレントリンクの一実施例に対して定義されるバーチャルチャネルを示す。
【０１０８】
ホストノード２０２は処理ノード１２から分離して示されているが、ホストノード２０２は所望される場合には処理ノードに統合されてもよいことに注目されたい。
【０１０９】
次に図２０を参照して、テーブル２１０はコンピュータシステム１０内における非コヒーレントリンクの一例示的実施例に従って用いられるパケットを示す。他の実施例も可能であり意図され、任意の他の好適な組のパケットおよびコマンドフィールドエンコーディングを含む。テーブル２１０は、各コマンドに割当てられるコマンドエンコーディングを示すコマンドコードコラムと、非コヒーレントパケットが属するバーチャルチャネルを定義するバーチャルチャネル（Vchan）コラムと、コマンドを名づけるコマンドコラムと、コマンドパケット３０、２１２および２１４のうちどれがそのコマンドに対して用いられるかを示すパケットタイプコラムとを含む。
【０１１０】
Nop、WrSized、ReadSized、RdResponse、TgtDone、Broadcast、およびSyncパケットは、図７に関して記載された対応のコヒーレントパケットと同様であってもよい。しかしながら、非コヒーレントリンクでは、プローブパケットもプローブ応答パケットも出されない。
【０１１１】
AssignおよびAssignAckパケットを用いてUnit IDをノードに割当てる。マスタホストブリッジはパケットを各ノードに（一度に１つ）割当て、最後に用いられたUnit IDを示す。受信ノードは、そのノードによって必要とされるUnit IDの数を、最後に用いられたUnit ID＋１から開始して割当てる。受信ノードは、割当てられたUnit IDの数を示すＩＤカウントを含んで、AssignAckパケットを戻す。
【０１１２】
次に図２１を参照して、非コヒーレントリンクにおいて用いられてもよいコマンドパケット２１２の一実施例のブロック図を示す。コマンドパケット２１２はコヒーレントパケットと同様なコマンドフィールドを含む。加えて、随意のソースタグフィールドを、コヒーレントコマンドパケットと同様に、ビット時間３において含んでもよい（SrcTag）。アドレスはビット時間５−８（および最下位アドレスビットに対しては随意にビット時間４）に含まれる。しかしながら、ソースノードの代わりに、ユニットＩＤが与えられる。
【０１１３】
ユニットＩＤはパケットを同じロジックソースから来るものとして認識するよう働く（ユニットＩＤが等しい場合）。しかしながら、Ｉ／Ｏノードは複数のユニットＩＤを有してもよい（たとえばノードがロジック的に分離している複数のデバイスまたは機能を含む場合）。したがって、ノードは１つを超えるユニットＩＤを有するパケットを受入れてもよい。加えて、パケットはホストブリッジとノードとの間を流れるので、パケットに関与するノードの１つ（ホストブリッジノード）が当該パケットに対して暗示される。したがって、単一のユニットＩＤを非コヒーレントパケットにおいて用いてもよい。一実施例では、ユニットＩＤは５つのビットを含んでもよい。ユニットＩＤ０はホストブリッジに割当てられてもよく、ユニットＩＤ３１はエラーケースに対して用いられてもよい。したがって、３０までのユニットＩＤが１つのデージーチェーン内へ結合されるＩ／Ｏノードにおいて存在してもよい。
【０１１４】
加えて、コマンドパケット２１２はシーケンスＩＤフィールドをビット時間１および２に含む。このシーケンスＩＤフィールドを用いて同じユニットＩＤから２つ以上のコマンドパケットの組をグループ化しその組が順序づけられる旨を示してもよい。より特定的には、シーケンスＩＤフィールドが０である場合、パケットは順序づけられない。シーケンスＩＤフィールドが０でない場合、パケットは同じシーケンスＩＤフィールド値を有する他のパケットに関し順序づけられる。
【０１１５】
次に図２２を参照して、非コヒーレントリンクにおいて用いられてもよい応答パケット２１４の一実施例のブロック図が示される。応答パケット２１４は、コマンドフィールドと、ユニットＩＤフィールドと、コマンドパケット２１２に類似するソースタグフィールドとを含む。他のビットを所望のように含んでもよい。
【０１１６】
ここで図２３を参照して、Ｉ／Ｏノード２０４Ａの一実施例を示すブロック図が示される。他のＩ／Ｏノード２０４Ｂ〜２０４Ｃも同様に構成されてもよい。他の実施例も可能であり意図される。図２３の実施例では、Ｉ／Ｏノード２０４Ａは、インターフェイスロジック１８Ｍおよび１８Ｎと、パケットバッファの第１の組２２０と、パケットバッファの第２の組２２２と、ノードロジック２２４とを含む。インターフェイスロジック１８Ｍはライン２４Ｋおよび２４Ｌと、パケットバッファ２２０およびノードロジック２２４とに結合される。インターフェイスロジック１８Ｎは、パケットバッファ２２２およびノードロジック２２４と並んで、ライン２４Ｍおよび２４Ｎに結合される。ノードロジック２２４はさらにパケットバッファ２２２および２２４に結合される。
【０１１７】
インターフェイスロジック１８Ｍおよび１８Ｎはパケットをライン２４Ｌおよび２４Ｍから（それぞれ）受取りパケットをライン２４Ｋおよび２４Ｎで（それぞれ）送るよう構成される。上記においてコヒーレントリンクに対し記載されたインターフェイスロジックと同様に、インターフェイスロジック１８Ｍおよび１８Ｎは受取られたパケットを制御経路およびデータ経路に分離してもよい。制御経路は制御パケットバッファに結合され、データ経路はデータパケットバッファに結合される。代替的に、インターフェイスロジックは受取られたパケットを制御経路およびデータ経路に分離せず、ノードロジック２２４によって各ビット時間に対応するＣＤＬ信号を受取り分離を実行してもよい。コヒーレントインターフェイスと同様に、パケットバッファ２２０および２２２は、コマンドバッファ（ＣＢ）および応答バッファ（ＲＴ）を制御パケットに対して、非コヒーレントリンクにおいて実施される２つのバーチャルチャネルに対応して含む。加えて、データパケットバッファが各バーチャルチャネルに対して与えられる（つまりコマンドデータバッファ（ＣＤＢ）および応答データバッファ（ＲＤＢ））。
【０１１８】
ノードロジック２２４はバッファ２２２および２２４内に受取られたパケットを処理し、パケットをＩ／Ｏノード２０４Ａにより実現される周辺機能性に応答して起動してもよい。図１１に示される制御ロジック６６と同様に、ノードロジック２２４は制御パケットアクティブレジスタ２２６Ａおよび２２６Ｂ（パケットバッファ２２２および２２４にそれぞれ対応する）ならびにデータパケットアクティブレジスタ２２８Ａおよび２２８Ｂ（パケットバッファ２２２および２２４にそれぞれ対応する）を実現してもよい。加えて、非コヒーレントリンクはNode IDの代わりにUnit IDに従って動作するので、ノードロジック２２４は１つ以上のUnit IDレジスタ２３０Ａ〜２３０Ｎを含んでＩ／Ｏノード２０４Ａに割当てられるUnit IDを記憶してもよい。Unit IDレジスタ２３０Ａ〜２３０Ｎの数は、ノードよって、当該ノード内にて実現されるUnit IDの数に従って変動してもよい。
【０１１９】
異なるバーチャルチャネルにおけるパケットはＩ／Ｏノード２０４Ａ内の異なるバッファに記憶されるので、異なるバーチャルチャネルにおけるパケットは物理的には互いとコンフリクトしない。したがって、デッドロックのない動作が与えられてもよい。加えて、ノードロジック２２４は予め資源を割当てて資源パケットおよび応答データを取扱ってもよく（上述のとおり）、したがって応答パケットは１つのバーチャルチャネル内にマージされてもよい（上述のとおり）。ノードロジック２２４は、さらに、図１８に示されるパケットと同様のNopパケットの送受（予約されたプローブフィールドとともに）をフロー制御バッファ２２０および２２２（および他のノードにおける同様のバッファ）に対してパケットの送受に関し行なうよう構成されてもよい。
【０１２０】
ノードロジック２２４は、さらに、Ｉ／Ｏノード２０４Ａにより実行されるさまざまなＩ／Ｏまたは周辺機能に対応するロジックを含んでもよい。たとえば、Ｉ／Ｏノード２０４Ａは記憶周辺装置、たとえばディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤドライブなどを含んでもよい。Ｉ／Ｏノード２０４Ａは通信周辺装置、たとえばＩＥＥＥ １３９４、イーサネット（Ｒ）、ユニバーサル・シリアル・バス（ＵＳＢ）、周辺構成要素相互接続（ＰＣＩ）バス、モデムなどを含んでもよい。任意の好適なＩ／Ｏ機能をＩ／Ｏノード２０４Ａに含んでよい。
【０１２１】
ここで図２４を参照して、パケットを受信するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。示される実施例はパケットをバッファ２２０および２２２に一連のビット時間として受取る。他の実施例はパケットのビット時間をインターフェイスロジック１８Ｍ〜１８Ｎにおいて累積し、完全なパケットをバッファ２２０および２２２に与えてもよく、その場合には、ビット時間においてパケットの受取りを管理することに関連するステップは除いてもよい。図２４に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内において用いながら実行されてもよい。図２４に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎごとに実行されてもよく、なぜならば、ビット時間は同時に各インターフェイスロジックから受取られてもよいからである。ステップ１００〜１１２は上記の図１４の対応して記載されたステップと同様であってもよい。
【０１２２】
次に図２５を参照して、コマンドパケットを処理するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２５に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行されてもよい。図２５に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎごとおよび／または各コマンドパケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。代替的に、１つのコマンドパケット（またはインターフェイスロジック１８Ｍ〜１８Ｎにつき１つのコマンドパケット）を、処理のために、好適な公平性アルゴリズムに従って選択してもよい。一般に、１つのバーチャルチャネルから処理のために選択されるパケットはバーチャルチャネル内におけるパケットに対する順序付け規則に従う（たとえば同じソースから同じデスティネーションへのパケットは順序よく選択される）が、パケットの、処理に対する選択は、所望されかつ順序付け規則が許す場合には、順序が乱れた状態でなされてもよい。
【０１２３】
ステップ１２６は一般に図１５の対応のステップと同様であってもよい（が、ユニットＩＤおよびユニットＩＤレジスタ２３０Ａ〜２３０Ｎに基づく）。加えて、ノードロジック２２４はパケットをパケット経路制御テーブルに従ってではなく同じ方向（上流または下流）において送るよう構成される（ステップ２４２）。パケットがこのノードを標的としている場合、ノードロジック２２４はそのパケットを受入れ（パケットを下流のフローから取除く）、それを処理する（ステップ２４０）。一旦コマンドパケットが処理される（送られるかまたはこのノードによって受入れられる）と、そのコマンドパケットはコマンドバッファエントリから取除かれ（適用可能である場合にはデータパケットはデータバッファエントリから取除かれ）ることに注目されたい。
【０１２４】
選択されたコマンドパケットが対応するデータパケットを特定する場合には、さまざまな実施例によるコマンドパケットの処理をたとえそのデータパケットがまだ受取られていなくても行なってもよく、またはデータパケットの到着を待つことによりデータを送ることを単純化するかまたは完全なデータパケットを特定する他の制御パケットが同じリンク上において送られるようにしてもよい。データパケットがコマンドパケットの処理時に受取られていない場合、そのデータパケットは、上述のように、それが受取られるときに処理されてもよい。
【０１２５】
次に図２６を参照して、応答パケットを処理するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２６に示されるステップは理解を容易にするためある特定の順序で示されるが、他の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行されてもよい。図２６に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎおよび／または各応答パケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。ステップ１１４は図１６の対応するステップと同様であってもよい（が、ノードロジック２２４に対してはユニットＩＤおよびユニットＩＤレジスタ２３０Ａ〜２３０Ｎに基づく）。
【０１２６】
デスティネーションノードが別のノードである場合、応答バーチャルチャネルに対する空いているバッファエントリが受信機において応答パケットが送られるリンク上にあるならば、ノードロジック２２４は応答パケット（および適用可能である場合には対応のデータパケット）を送る（ステップ２５０）。この受信機は応答パケットをそのパケットが既に流れているのと同じ方向（上流または下流）において流れさせるノードである。
【０１２７】
応答パケットのデスティネーションノードがこのノードである場合、ノードロジック２２４は、もし対応のデータパケットがあれば、それを、対応の応答データバッファから、その応答が割当てられるデータバッファへ移動させるよう構成される（ステップ２５２）。換言すれば、ノードロジック２２４はそのデータを消費する。ノードロジック２２４は次いで対応のコマンドを完了し、データバッファの割当てを解除する（ステップ２５４）。一旦応答パケットが処理される（送られるかまたはこのノードによって受入れられる）と、その応答パケットは応答バッファエントリから取除かれ（適用可能である場合にはデータパケットはデータバッファエントリから取除かれ）ることに注目されたい。
【０１２８】
選択された応答パケットが対応するデータパケットを特定する場合には、さまざまな実施例によるその応答パケットの処理がたとえそのデータパケットがまだ受取られていなくとも行なってもよく、またはそのデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。データパケットが応答パケットの処理時に受取られていない場合、データパケットは、上述のように、そのデータパケットが受取られるときに扱ってもよい。
【０１２９】
次に図２７を参照して、ノードが結合されるリンク上においてパケットを起動するためのノードロジックの一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２７に示されるステップは理解を容易にするためある特定の順序で示されるが、他の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行してもよい。
【０１３０】
ノードロジック２２４は、開始されるべきトランザクションの結果、データがこのノードに戻されるかどうかを判断する（判断ブロック２６０）。たとえば、ノードにより開始される読出トランザクションはデータをノードに戻し、一方、ノードにより開始される書込トランザクションはデータをノードに戻さない。トランザクションの結果、データがこのノードに戻される場合、ノードロジック２２４はデータバッファを割当てて、戻されたデータを記憶する（ステップ２６２）。この後、ノードロジック２２４はパケットを送る（ステップ１６４）。
【０１３１】
産業上の利用可能性
この発明はコンピュータシステムにおいて適用可能であってよい。
【図面の簡単な説明】
【図１】 コンピュータシステムの一実施例のブロック図である。
【図２】 図１に示される２つのノードの、間のリンクの一実施例が強調される、一実施例のブロック図である。
【図３】 情報パケットの一実施例を示すブロック図である。
【図４】 コヒーレントリンクのためのコマンドパケットの一実施例を示すブロック図である。
【図５】 コヒーレントリンクのための応答パケットの一実施例を示すブロック図である。
【図６】 データパケットの一実施例を示すブロック図である。
【図７】 コヒーレントリンクのためのパケット定義の一実施例を示すテーブルである。
【図８】 バーチャルチャネルの対を示すブロック図である。
【図９】 バーチャルチャネルの組の一実施例を示すテーブルである。
【図１０】 図１に示される処理ノードの一実施例のブロック図である。
【図１１】 図１０に示されるパケット処理ロジックの一実施例のブロック図である。
【図１２】 データバッファプールエントリの一実施例を示すブロック図である。
【図１３】 応答カウンタプールエントリの一実施例を示すブロック図である。
【図１４】 パケット受信のために図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１５】 コマンドパケットを処理するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１６】 応答パケットを処理するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１７】 パケットを起動するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１８】 バッファ空きフィールドを含む情報パケットの一実施例を示すブロック図である。
【図１９】 図１および図２に示される相互接続に類似したリンクを介して相互接続されるホストブリッジおよび複数のＩ／Ｏノードを含むＩ／Ｏサブシステムの一実施例のブロック図である。
【図２０】 非コヒーレントリンクのパケット定義の一実施例を示すテーブルである。
【図２１】 非コヒーレントリンクのためのコマンドパケットの一実施例のブロック図である。
【図２２】 非コヒーレントリンクのための応答パケットの一実施例のブロック図である。
【図２３】 Ｉ／Ｏノードの一実施例のブロック図である。
【図２４】 パケット受信のための図２３に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２５】 コマンドパケットを処理するための図２４に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２６】 応答パケットを処理するための図２４に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２７】 パケットを起動するための図２７に示されるノードロジックの一実施例の動作を示すフローチャートである。
【発明の背景】
１．技術分野
この発明はコンピュータシステムの分野に関し、より特定的には、コンピュータシステムにおけるノード間の相互接続に関する。
【０００２】
２．背景技術
一般的には、パーソナルコンピュータ（ＰＣ）およびその他の種類のコンピュータシステムは、メモリにアクセスするために共用バスシステムを中心に設計されてきた。１つ以上のプロセッサおよび１つ以上の入力／出力（Ｉ／Ｏ）装置が、共用バスを介してメモリに結合される。Ｉ／Ｏ装置は、共用バスとＩ／Ｏ装置との間の情報の転送を管理するＩ／Ｏブリッジを介して共用バスに結合される場合もある一方、プロセッサは典型的には、直接共用バスに結合されるか、またはキャッシュ階層構造を介して共用バスに結合される。
【０００３】
残念ながら、共用バスシステムはいくつかの欠点を有する。たとえば、共用バスには多数の装置が装着されることから、バスは典型的には比較的低い周波数で動作される。多数の装着物は、バス上で信号を駆動する装置に容量的な高負荷をもたらし、多数の装着点は、比較的複雑な高周波数に対する伝送ラインモデルをもたらす。したがって、周波数は低く留められ、共用バスで使用できる帯域幅も同様に比較的低い。低帯域幅は共用バスに付加的な装置を装着するのに障壁になり得るが、これは使用できる帯域幅によって性能が制限されるおそれがあるためである。
【０００４】
共用バスシステムの他の欠点は、より多くの装置に対するスケーラビリティの欠如である。上述のように、帯域幅が固定される（そして、もし付加的な装置の追加によってバスの動作可能周波数が減じられると、減少し得る）。バスに（直接的にまたは間接的に）装着された装置の帯域幅要件が、一旦バスの利用可能な帯域幅を超えると、装置はバスへのアクセスを試みたときにしばしばストールし得る。全体的な性能が減じられるであろう。
【０００５】
上述の問題のうちの１つまたはいくつかには、分散メモリシステムを用いて対処し得る。分散メモリシステムを用いるコンピュータシステムは、複数のノードを含む。２つ以上のノードがメモリに接続され、それらのノードは何らかの好適な相互接続を用いて相互接続される。たとえば、ノードの各々は専用ラインを用いて他のノードに互いに接続されることができる。これに代えて、ノードの各々は固定された数の他のノードに接続され、トランザクションは第１のノードから１つ以上の中間ノードを介して、第１のノードに直接接続されていない第２のノードに経路制御されてもよい。メモリアドレス空間は、各々のノードのメモリにわたって割当てられる。一般的に、「ノード」とは相互接続上のトランザクションに関わることのできる装置である。たとえば、パケットベースの相互接続においては、ノードは他のノードとパケットを送受信し得るよう構成される。特定のトランザクションを行なうために、１つ以上のパケットが採用され得る。特定のノードは、パケットに対するデスティネーションであり得るが、この場合情報はノードによって受取られて、ノード内で処理される。これに変えて、特定のノードは、もし特定のノードがパケットのデスティネーションノードでなければ、パケットをソースノードからデスティネーションノードへ中継するためにも用い得る。
【０００６】
分散メモリシステムは、共用バスシステムの困難とは異なった設計上の困難を呈示する。たとえば、共用バスシステムはバスアービトレーションを介してトランザクションの開始を規制する。したがって、明確なアービトレーションアルゴリズムが、関与するバスにトランザクションを開始させる機会を与える。バス上のトランザクションの順序が、そのトランザクションが行なわれる順序を表し得る（たとえば、コヒーレンシ目的で）。一方、分散システムにおいては、ノードは並行にトランザクションを開始し、相互接続を用いてトランザクションを他のノードに送信し得る。これらのトランザクションは、それらの間でロジック的コンフリクト（たとえば、同じアドレスへのトランザクションに対するコヒーレンシコンフリクト）を有し、資源コンフリクトが生じるおそれがあるが、これはトランザクションの開始を規制するための中央機構が提供されていないためである。したがって、情報がノード間を円滑に伝播しつづけ、かつ（トランザクション間のコンフリクトによりトランザクションが完了しない）デッドロック状態が回避されることを確実にすることが、より困難である。分散システムにおけるデッドロックを回避するための方法および装置が望まれる。さらに、実現を容易にするために、（ハードウェアの意味での）装置を最小化することが望まれる。
【０００７】
Ｖ・Ｓ・アドヴェおよびＭ・Ｋ・ヴァーノン（V. S. Adve and M. K. Vernon）の「判断経路制御によるメッシュ相互接続ネットワークのパフォーマンス分析（Performance Analysis of mesh interconnection networks with deterministic routing）INTERNET [Online]１９９４年、１〜４０頁、ＸＰ２１５５４２４は、物理的リンクの各々が、別々のバッファによって与えられる２つのバーチャルチャネルにより共用される、デッドロックのない経路制御アルゴリズムを用いた処理ノードのネットワークの間のメッセージを経路制御する方法を開示する。
上に概要を述べた問題は、ここで説明するようにバーチャルチャネルを用い、かつバーチャルチャネルに異なった資源を割当てることにより、大部分が解決される。
この発明の１つの局面によると、コンピュータシステム内の複数のノードの間でパケットを経路制御するための方法が開示され、方法は請求項１に定義される。
この発明の第２の局面によると、請求項５に定義されるコンピュータシステムが提供される。
一般的に、ロジック的／プロトコル関連のコンフリクトを有さないパケットは、バーチャルチャネルにグループ化される。したがって、ロジック的コンフリクトは別々のバーチャルチャネル内のパケットの間で生じる。１つのバーチャルチャネル内のパケットは資源を共用する（よって資源コンフリクトが生じる）が、異なったバーチャルチャネル内のパケットは資源を共用しないであろう。資源コンフリクトが生じるパケットはロジック的コンフリクトは生じなく、かつロジック的コンフリクトが生じるパケットは資源コンフリクトは生じないために、デッドロックのない動作が達成される。
【０００８】
さらに、各バーチャルチャネルには、制御パケットバッファとデータパケットバッファとが割当てられ得る。制御パケットは、データパケットよりも実質的にサイズが小さく、データパケットよりも頻繁に生じ得る。別々のバッファを与えることにより、バッファ空間を効率的に用いることができる。データパケットを特定しない制御パケットが受取られると、データパケットバッファ空間は割当てられない。データパケットを特定する制御パケットが受取られると、制御パケットバッファ空間およびデータパケットバッファ空間の両方が割当てられる。制御パケットはデータパケットよりも小さくより頻繁に生じることが多いので、全体的なバッファ記憶を実質的に増加させることなく、データパケットバッファ内よりも制御パケットバッファ内でより多くのバッファエントリを提供することができる。しかしながら、パケットのスループットは上昇し得る。
【００１１】
この発明の他の目的と利点とは、以下の詳細な説明を読み、添付の図面を参照することにより、より明らかとなるであろう。
【００１２】
この発明はさまざまな変形と代替形に対処するものであるが、その特定の実施例を図面において例示の目的で示し、以下に詳述する。しかしながら、図面とその詳細な説明とは開示される発明を特定の形に限定することを意図せず、反対に、すべての変形、等価物、および代替例は前掲の特許請求の範囲に規定されるこの発明の精神および範囲に入ることを意図する。
【００１３】
【発明の実施の形態】
システムの概要
図１は、マルチプロセッシングコンピュータシステム１０の一実施例を示す。他の実施例が可能であり企図される。図１の実施例においては、コンピュータシステム１０はいくつかの処理ノード１２Ａ、１２Ｂ、１２Ｃ、および１２Ｄを含む。処理ノードの各々は、処理ノード１２Ａ−１２Ｄにそれぞれ含まれるメモリコントローラ１６Ａ−１６Ｄを介して、それぞれのメモリ１４Ａ−１４Ｄに結合される。さらに、処理ノード１２Ａ−１２Ｄは、処理ノード１２Ａ−１２Ｄの間の通信のために用いるインターフェイスロジックを含む。たとえば、処理ノード１２Ａは、処理ノード１２Ｂと通信するためのインターフェイスロジック１８Ａと、処理ノード１２Ｃと通信するためのインターフェイスロジック１８Ｂと、さらに別の処理ノード（図示せず）と通信するための第３のインターフェイスロジック１８Ｃを含む。同様に、処理ノード１２Ｂはインターフェイスロジック１８Ｄ、１８Ｅ、および１８Ｆを含み、処理ノード１２Ｃはインターフェイスロジック１８Ｇ、１８Ｈ、および１８Ｉを含み、処理ノード１２Ｄはインターフェイスロジック１８Ｊ、１８Ｋ、および１８Ｌを含む。処理ノード１２Ｄは、インターフェイスロジック１８Ｌを介して結合されてＩ／Ｏブリッジ２０と通信する。他の処理ノードは同様の様式で他のＩ／Ｏブリッジと通信し得る。Ｉ／Ｏブリッジ２０はＩ／Ｏバス２２に結合される。
【００１４】
処理ノード１２Ａ−１２Ｄは、処理ノード間通信のためのパケットベースのリンクを実現化する。この実施例においては、リンクは単方向ラインの組として実現化される（たとえば、ライン２４Ａはパケットを処理ノード１２Ａから処理ノード１２Ｂへ送信するために用いられ、ライン２４Ｂはパケットを処理ノード１２Ｂから処理ノード１２Ａへ送信するために用いられる）。ライン２４Ｃ−２４Ｈの他の組は、図１に示すようにパケットを他の処理ノード間で通信するために用いられる。リンクは、処理ノード間の通信のためにキャッシュコヒーレント様式で動作するか（「コヒーレントリンク」）、または処理ノードとＩ／Ｏブリッジとの間の通信のために非コヒーレント様式で動作し得る（「非コヒーレントリンク」）。さらに、非コヒーレントリンクは、Ｉ／Ｏバス２２の代わりにＩ／Ｏ装置の間でデイジーチェーン構造として用いられ得る。コヒーレントリンクを介した２つ以上のノードの相互接続は、「コヒーレントファブリック」と呼ばれる。同様に、非コヒーレントリンクを介した２つ以上のノードの相互接続は、「非コヒーレントファブリック」と呼ばれる。一方の処理ノードから他方へ送信されるべきパケットは、１つ以上の中間ノードを通過し得ることに留意されたい。たとえば、処理ノード１２Ａから処理ノード１２Ｄに送信されるパケットは、図１に示すように、処理ノード１２Ｂまたは処理ノード１２Ｃのいずれかを通過し得る。いかなる好適な経路制御アルゴリズムをも用い得る。コンピュータシステム１０の他の実施例は、図１に示す実施例よりも多いかまたは少ない処理ノードを含み得る。
【００１５】
処理ノード１２Ａ−１２Ｄは、メモリコントローラとインターフェイスロジックに加えて、１つ以上のプロセッサを含み得る。概略的には、処理ノードは少なくとも１つのプロセッサを含み、選択により、メモリおよび所望の他のロジックとの間で通信するためのメモリコントローラを含む。
【００１６】
メモリ１４Ａ−１４Ｄは、何らかの好適なメモリ装置を含み得る。たとえば、メモリ１４Ａ−１４Ｄは、１つ以上のＲＡＭＢＵＳ ＤＲＡＭ（ＲＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭなどを含み得る。コンピュータシステム１０のアドレス空間は、メモリ１４Ａ−１４Ｄの間で分割される。処理ノード１２Ａ−１２Ｄの各々はメモリマップを含むことができ、該メモリマップを用いて、どのアドレスがどのメモリ１４Ａ−１４Ｄにマッピングされているか、よって、ある特定のアドレスに対するメモリ要求がどの処理ノード１２Ａ−１２Ｄに経路制御されるべきかを判断する。一実施例においては、コンピュータシステム１０内のアドレスに対するコヒーレンシ点は、アドレスに対応するバイトを記憶しているメモリに結合された、メモリコントローラ１６Ａ−１６Ｄである。言い換えると、メモリコントローラ１６Ａ−１６Ｄは、対応するメモリ１４Ａ−１４Ｄへのメモリアクセスの各々を、キャッシュコヒーレントな様式で起こることを確実にすることを担当している。メモリコントローラ１６Ａ−１６Ｄは、メモリ１４Ａ−１４Ｄにインターフェイスするための制御回路を含み得る。さらに、メモリコントローラ１６Ａ−１６Ｄは、メモリ要求を待ち行列として管理するための、要求待ち行列を含み得る。
【００１７】
一般的には、インターフェイスロジック１８Ａ−１８Ｌは、リンクからパケットを受取り、かつリンクに送信されるべきパケットをバッファするための、バッファを含み得る。コンピュータシステム１０は、パケットを送るために好適などのようなフロー制御をも用い得る。たとえば一実施例においては、ノードの各々は、インターフェイスロジックの各々が接続されたリンクの他端のレシーバ内に、いくつかの各種のバッファのカウントを記憶する。ノードは、受信ノードがパケットを記憶するための空いたバッファを有さない限り、パケットを送信しない。パケットを次に経路制御することにより受信バッファが空くと、受信インターフェイスロジックは送信インターフェイスロジックにメッセージを送り、バッファが空いたことを示す。そのような機構は、「クーポンに基づく」システムと呼べる。
【００１８】
次に図２は、処理ノード１２Ａおよび１２Ｂのブロック図を示し、それらの間のリンクの一実施例を詳細に例示する。他の例も可能であり、企図される。図２の実施例においては、ライン２４Ａは、クロックライン２４ＡＡと、制御ライン２４ＡＢと、制御／アドレス／データバス２４ＡＣとを含む。同様に、ライン２４Ｂは、クロックライン２４ＢＡと、制御ライン２４ＢＢと、制御／アドレス／データバス２４ＢＣとを含む。
【００１９】
クロックラインは、制御ラインおよび制御／アドレス／データバスに対するサンプルポイントを示すクロック信号を送信する。特定の一実施例においては、データ／制御ビットはクロック信号のエッジの各々（すなわち立上がりエッジおよび立下がりエッジ）で送信される。したがって、クロックサイクルごとに、ラインごとに２つのデータビットを送信し得る。ラインごとに１ビットを送信するために使用される時間は、ここでは「ビット時間」と呼ぶ。上述の実施例は、クロックサイクルごとに２つのビット時間を含む。パケットは２つ以上のビット時間で送信し得る。制御／アドレス／データバスの幅に依存して、多数のクロックラインを用い得る。たとえば３２ビット制御／アドレス／データバスに対しては２つのクロックラインを用い得る（制御／アドレス／データバスの半分では一方のクロックラインが参照され、残りの半分の制御／アドレス／データバスと制御ラインとでは他方のクロックラインが参照される）。
【００２０】
制御ラインは、制御／アドレス／データバスに送信されたデータが、ビット時間の制御パケットか、またはビット時間のデータパケットであるかを示す。制御ラインはアサートされてビット時間の制御パケットを示し、デアサートされてビット時間のデータパケットを示す。ある制御パケットは、後にデータパケットが続くことを示す。データパケットは、対応する制御パケットのすぐ後に続き得る。一実施例においては、他の制御パケットがデータパケットの送信に割込むおそれがある。そのような割込は、データパケットの送信の間に制御ラインをいくつかのビット時間アサートし、かつ制御ラインがアサートされている間にビット時間の制御パケットを送信することにより行なわれる可能性がある。データパケットに割込む制御パケットは、データパケットが後に続くことを示さないおそれがある。さらに、一実施例においては、制御ラインが制御パケットの送信の間にデアサートされてストールビット時間を示し得る。後の制御ラインの再アサートは、制御パケットが続いていることを示し得る。
【００２１】
制御／アドレス／データバスは、データ／制御ビットを送信するための１組のラインを含む。一実施例においては、制御／アドレス／データバスは、８、１６、または３２のラインを含み得る。処理ノードまたはＩ／Ｏブリッジの各々は、設計選択にしたがってサポートされる数のラインのうちのいずれかを用い得る。他の実施例は、所望により他のサイズの制御／アドレス／データバスをサポートし得る。
【００２２】
一実施例によると、コマンド／アドレス／データバスラインおよびクロックラインは、反転データを担持し得る（すなわち、ロジック１はライン上の低電圧として表わされ、ロジック０が高電圧として表わされる）。これに代えて、これらのラインは非反転データを担持してもよい（ロジック１はライン上の高電圧として表わされ、ロジック０は低電圧として表わされる）。
【００２３】
図３から図６は、コヒーレントリンクの一実施例において用いられる、例示的なパケットを示す。図３から図５は制御パケットを示し、図６はデータパケットを示す。他の実施例は、所望により異なったパケット定義を用い得る。パケットの各々は、「ビット時間」の見出しの下に列挙される一連のビット時間で示される。パケットのビット時間は、リストされたビット時間順序に従って送信される。図３から図６は、８ビット制御／アドレス／データバス実現化のためのパケットを示す。したがって、ビット時間の各々は、７から０まで番号が付与された８つのビットを含む。図中、いずれの値も付与されていないビットは、所与のパケットのために予約されているか、またはパケット特定情報を送信するために用いられるかのいずれかであり得る。点線で示されるフィールドは、あるタイプのすべてのパケットに含まれない可能性のある任意のフィールドを示す。
【００２４】
一般的に、パケットは２つのノード（パケットを送信する起動ノードおよびパケットを受取るデスティネーションノード）間の通信である。起動ノードおよびデスティネーションノードは、パケットが関わるトランザクションのソースおよびターゲットノードとは異なるか、またはいずれかのノードがソースノードまたはターゲットノードのいずれかであり得る。制御パケットは、トランザクションに関する制御情報を担持するパケットである。ある制御パケットは、データパケットが後に続くことを特定する。データパケットは、トランザクションに対応し、かつ特定する制御パケットに対応するデータを担持する。
【００２５】
図３は情報パケット（infoパケット）３０を示す。情報パケット３０は、８ビットリンク上の４つのビット時間を含む。この実施例においては、コマンド符号化はビット時間１の間に送信され、かつ６ビットを含む。図４、および図５に示す他方の制御パケットの各々は、ビット時間１の間に同じビット位置においてコマンド符号化を含む。メッセージがメモリアドレスを含まないときに、情報パケット３０を用いてこのメッセージを処理ノード間で送信し得る。さらに、クーポンに基づくフロー制御方策を用いてバッファ空きカウントを送信するためにも、情報パケットを用い得る。
【００２６】
図４はコマンドパケット（commandパケット）３２を示す。コマンドパケット３２は、８ビットリンク上の８つのビット時間を含む。コマンド符号化は、ビット時間１の間に送信される。ソースユニット番号も同様にビット時間１の間に送信され、ソースノード番号はビット時間２の間に送信される。ノード番号はコンピュータシステム１０内の処理ノード１２Ａ−１２Ｄのうちの１つを明確に識別し、かつパケットをコンピュータシステム１０を介して経路制御するために用いられる。ユニット番号は、トランザクションを発したノード内のユニットを識別するか（ソースユニット番号）、またはトランザクションのデスティネーションであるノード内のユニットを識別する（デスティネーションユニット番号）。ユニットは、メモリコントローラ、キャッシュ、プロセッサなどを含み得る。任意で、コマンドパケット３２はビット時間２におけるデスティネーションノード番号およびデスティネーションユニットのいずれかを含み得る（または他のいくつかのパケットでは、ターゲットノード番号およびターゲットユニット）。もしデスティネーション番号が含まれていれば、これはパケットをデスティネーションノードに経路制御するために用いられる。また、多くのコマンドパケットがビット時間３にソースタグを含み得るが、これはソースノードおよびソースユニットと併せて、パケットを関連する特定のトランザクションにリンクし得る。ビット時間５から８は、トランザクションによって影響されるメモリアドレスの最上位のビットを送信するために用いられる。コマンドパケット３２は、トランザクションを開始し（たとえば、読出または書込トランザクション）、かつトランザクションによって影響されるメモリアドレスを担持するコマンドに対するトランザクションを実行するプロセスにおいてコマンドを送信するために用いられる。一般的に、コマンドパケットはデスティネーションノードによって実行されるべき動作を示す。
【００２７】
パケット３２内の定義されないいくつかのフィールドをコマンドパケットにおいて用いて、パケット特定情報を担持し得る。さらに、ビット時間４をいくつかのコマンド内で用いて、トランザクションによって影響されるメモリアドレスの最下位のビットを送信する。
【００２８】
図５は、応答パケット（responseパケット）３４を示す。応答パケット３４は、コマンド符号化と、デスティネーションノード番号およびデスティネーションユニット番号とを含む。デスティネーションノード番号は、応答パケットに対するデスティネーションノードを識別する（これは、場合によってトランザクションのソースノードまたはターゲットノードであり得る）。さまざまな種類の応答パケットは付加的な情報を含み得る。たとえば、読出応答パケットは、後に続くデータパケットで提供される読出データの量を示し得る。プローブ応答は、プローブノードによって要求されたキャッシュブロックのコピーが保持されているか否かを示し得る（ビット時間４における任意の共用ビット“Ｓｈ”を用いる）。一般的に、応答パケット３４は、トランザクションを行なう間に、トランザクションによって影響されるメモリアドレスの送信を必要としないコマンドに対して用いられる。さらに、応答パケット３４を用いて肯定応答パケットを送信してトランザクションを終了させることができる。コマンドパケット３２と同様に、応答パケット３４はさまざまな種類の応答に対するソースノード番号、ソースユニット番号、およびソースタグを含み得る（図５に任意のフィールドとして示す）。
【００２９】
図６は、データパケット（dataパケット）３６を示す。データパケット３６は、図６の実施例において、８ビットリンク上の８つのビット時間を含む。データパケット３６は、送信されるデータの量に依存して、異なった数のビット時間を含み得る。たとえば、一実施例においてはキャッシュブロックは６４バイトを含み、したがって８ビットリンク上の６４のビット時間を含む。他の実施例では、キャッシュブロックのサイズを所望により別に定義し得る。さらに、キャッシュ不可能な読出および書込に対しては、キャッシュブロックサイズよりも小さなサイズでデータを送信し得る。キャッシュブロックサイズより小さなデータを送信するためのデータパケットは、より少ないビット時間を用いる。一実施例においては、キャッシュブロックサイズではないデータはデータを送信する前にいくつかのビット時間のバイトイネーブルを送信して、データパケット内でどのデータバイトが有効であるかを示し得る。さらに、キャッシュブロックデータは最初に、要求されたアドレスの最下位のビットによってアドレスされたクワッドワードを備えて返され、その後インターリーブされた残りのクワッドワードのリターンが続く。一実施例においては、クワッドワードは８バイトを含み得る。
【００３０】
図３から図６は、８ビットリンクのためのパケットを示す。１６および３２ビットリンクのためのパケットは、図３から図６に示す連続的なビット時間を連結することにより形成し得る。たとえば、１６ビットリンク上のパケットのビット時間１は、８ビットリンク上のビット時間１および２の間に送信される情報を含み得る。同様に、３２ビットリンク上のパケットのビット時間１は、８ビットリンク上のビット時間１から４までの間に送信される情報を含み得る。以下の式（１）および式（２）は、８ビットリンクによるビット時間における、１６ビットリンクのビット時間１および３２ビットリンクのビット時間１の構成を示す。
【００３１】
【数１】
図７は、コンピュータシステム１０内のコヒーレントリンクの１つの例示的な実施例によって用いられるコマンドを示すテーブル３８を示す。パケットおよびコマンドフィールド符号化のいかなる好適な組をも含む、他の実施例も可能であり企図される。テーブル３８は、コマンドの各々に割当てられたコマンド符号化を示すコマンド符号化列、コマンドの名前を示すコマンド列、およびどのコマンドパケット３０−３４（および特定される場合には、データパケット３６）がそのコマンドに対して用いられるかを示すパケットタイプ列を含む。
【００３３】
読出トランザクションは、ReadSized，RdBlk，RdBlkSまたはRdBlkModのコマンドのうち、１つを用いて開始される。ReadSizedコマンドは、キャッシュ不可能な読出のために、またはサイズの合ったキャッシュブロック以外のデータの読出のために用いられる。読出されるべきデータ量は、ReadSizedコマンドパケット内に符号化される。キャッシュブロックの読出には、以下の場合以外にRdBlkコマンドを用いることができる。すなわち、（ｉ）キャッシュブロックの書込可能なコピーを所望である場合。この場合はRdBlkModコマンドを用い得る。または（ii）キャッシュブロックのコピーを所望するが、ブロックを変更する意図があるとは分らない場合。この場合はRdBlkS コマンドを用いることができる。RdBlkSコマンドを用いて、ある種のコヒーレントな方式（たとえばディレクトリに基づくコヒーレントな方式）をより効率化できる。一般的に、適切な読出コマンドはソースから送信されて、キャッシュブロックに対応するメモリを有するターゲットノードへの読出トランザクションを開始する。ターゲットノード内のメモリコントローラは、システム内の他のノードに（プローブ応答からのトランザクションのソースへのリターンを示す）Probeコマンドを送信して、これらのノード内のキャッシュブロックの状態を変化させること、およびキャッシュブロックの更新されたコピーを含むノードにキャッシュブロックをソースノードに送らせることにより、コヒーレンシを維持する。Probeコマンドを受取ったノードの各々は、ProbeResp応答パケットをソースノードに送信する。プローブされたノードが読出データの更新されたコピー（すなわちダーティデータ）を有していれば、そのノードはRdResponse応答パケットおよびダーティデータを送信する。ダーティデータを送信するノードはまた、ターゲットノードによる要求された読出データの送信をキャンセルしようと試みて、ターゲットノードにMemCancel応答パケットをも送信し得る。さらに、ターゲットノード内のメモリコントローラは、RdResponse応答パケットとその後に続くデータパケット内のデータとを用いて要求された読出データを送信する。ソースノードがプローブされたノードからRdResponse応答パケットを受取れば、その読出されたデータが用いられる。そうでなければ、ターゲットノードからのデータが用いられる。一旦ソースノードにおいてプローブ応答および読出されたデータの各々が受取られると、ソースノードはトランザクションの終了の肯定応答として、ターゲットノードにSrcDone応答パケットを送信する。
【００３４】
書込トランザクションはWrSizedまたはVicBlkコマンドを用いて開始され、その後に関連のデータパケットが続く。WrSizedコマンドは、キャッシュ不可書込またはサイズの合わないキャッシュブロックのデータの書込に用いられる。WrSizedコマンドに対するコヒーレンシの維持のために、ターゲットノード内のメモリコントローラはシステム内の他のノードの各々に（トランザクションのターゲットノードに対するプローブ応答のリターンを示す）Probeコマンドを送信する。Probeコマンドに応答して、プローブされたノードの各々はターゲットノードにProbeResp応答パケットを送信する。もしプローブされたノードがダーティデータを記憶していれば、プローブされたノードはRdResponse応答パケットおよびダーティデータで応答する。このようにして、WrSizedコマンドによって更新されたキャッシュブロックは、メモリコントローラに返されて、WrSizedコマンドによって提供されるデータとマージされる。メモリコントローラは、プローブされたノードの各々からプローブ応答を受取ると、ソースノードにTgtDoneパケットを送信してトランザクションの終了の肯定応答を提供する。ソースノードはSrcDone応答パケットで応答する。
【００３５】
ノードによって変更され、かつノード内のキャッシュで置き換えられたヴィクティムキャッシュブロックは、VicBlkコマンドを用いてメモリに返される。VicBlkコマンドに対してはプローブは必要ではない。したがって、ターゲットメモリコントローラがビクティムブロックデータをメモリにコミットする準備ができたとき、ターゲットメモリコントローラはビクティムブロックのソースノードにTgtDone応答パケットを送信する。ソースノードは、データがコミットされるべきことを示すSrcDone応答パケットか、またはデータが（たとえば介入するプローブに応答して）VicBlkコマンドの送信とTgtDone応答パケットの受信との間で無効化されたことを示すMemCancel応答パケットのいずれかで応答する。
【００３６】
ソースノードに記憶された書込不可能状態のキャッシュブロックへの書込許可を得るために、ソースノードはChangetoDirtyコマンドパケットを送信し得る。ChangetoDirtyコマンドによって開始されるトランザクションは、ターゲットノードがデータを返さないという点を除いて、読出と同様に動作し得る。もしソースノードがキャッシュブロック全体を更新する意図があるのであれば、ValidateBlkコマンドを用いて、ソースノードによって記憶されていないキャッシュブロックへの書込許可を得ることができる。そのようなトランザクションに対してはソースノードへデータは送られないが、それ以外では読出トランザクションと同様に動作する。
【００３７】
Nop infoパケットは、たとえばノード間のバッファ空き表示を送信するために用いられる、非動作パケットである。Broadcastコマンドは、ノード間でメッセージをブロードキャストするために用い得る（たとえば、ブロードキャストコマンドは割込を分散させるために用い得る）。最後に、sync infoパケットは、ファブリックの同期が所望である場合（たとえば、エラー検出、リセット、初期化）に用い得る。
【００３８】
テーブル３８はまた、バーチャルチャネル列（Vchan）をも含む。バーチャルチャネル列は、パケットの各々が移動する（すなわち、パケットの各々が属する）バーチャルチャネルを示す。この実施例においては、３つのバーチャルチャネルが定義される：コマンド（Command、Ｃ）、応答（Response、Ｒ）、およびプローブ（Probe、Ｐ）である。バーチャルチャネルを以下に詳細に説明する。情報パケットは隣接するノード間の通信のために用いられ、よってこの実施例においてはバーチャルチャネルには割当てられないことに留意されたい。
【００３９】
バーチャルチャネル
図８を参照すると、バーチャルチャネルを例示するブロック図が示される。図８において、２つのバーチャルチャネルが示される（バーチャルチャネル４０Ａおよび４０Ｂ）。処理ノード１２Ａ−１２Ｄの各々は、バーチャルチャネル４０Ａ−４０Ｂに結合される。２つのバーチャルチャネルは例示目的でのみ図８に示す。他の実施例は、いかなる好適な数のバーチャルチャネルをも含み得る。たとえば、コンピュータシステム１０の実施例は以下の図９に示されるように４つのバーチャルチャネルを用い得る。
【００４０】
一般的に、「バーチャルチャネル」は、さまざまな処理ノードの間でパケットを担持するための通信経路である。各バーチャルチャネルは、他のバーチャルチャネルから資源的に独立している（すなわち、１つのバーチャルチャネル内で流れるパケットは、物理的な通信の意味において、一般的に別のバーチャルチャネルにおけるパケットの存在または不在によって影響されない）。パケットは、パケットタイプに基づいてバーチャルチャネルに割当てられる。同じバーチャルチャネル内のパケットは、互いの通信に対して物理的にコンフリクトし得る（すなわち、同じバーチャルチャネル内のパケットには資源コンフリクトが生じる可能性がある）が、異なったバーチャルチャネル内のパケットの通信に対しては物理的にコンフリクトしない。
【００４１】
ある種のパケットは、他のパケットとロジック的にコンフリクトする（すなわち、プロトコルの理由、コヒーレンシの理由、または他のそのような理由から、一方のパケットはロジック的に別のパケットとコンフリクトし得る）。もし第１のパケットが、ロジック／プロトコル理由から、第２のパケットがそのデスティネーションノードに到着する前にそのデスティネーションノードに到着しなければならない場合、第２のパケットが物理的に第１のパケット通信をブロックするのであれば、（コンフリクトする資源を占有することにより）コンピュータシステムがデッドロックする可能性がある。第１および第２のパケットを別々のバーチャルチャネルに割当てることにより、かつ別々のバーチャルチャネルにおけるパケットが互いの通信をブロックしないようコンピュータシステム内の送信媒体を実現することにより、デッドロックのない動作を実現し得る。異なったバーチャルチャネルからのパケットは、同じ物理的リンク（たとえば、図１のライン２４）をわたって通信されることに留意されたい。しかしながら、受信バッファは送信の前に利用可能になっているので、バーチャルチャネルはこの共用資源を用いる間にも、互いをブロックしない。
【００４２】
１つの観点から見ると、異なったパケットタイプの各々（たとえば、異なったコマンド符号化の各々）は、それ自身のバーチャルチャネルに割当てられることができる。しかしながら、バーチャルチャネルが物理的にコンフリクトしないことを確実にするためのハードウェアは、バーチャルチャネルの数とともに増大する。たとえば、一実施例においては、別々のバッファがバーチャルチャネルごとに割当てられる。別々のバッファがバーチャルチャネルごとに用いられるために、１つのバーチャルチャネルからのパケットは別のバーチャルチャネルからのパケットと物理的にコンフリクトしない（そのようなパケットは別のバッファに入れられるためである）。しかしながら、バッファの数はバーチャルチャネルの数に比例する。したがって、ロジック／プロトコル態様でコンフリクトしないさまざまなパケットの種類を組合せることにより、バーチャルチャネルの数を減じることが望ましい。そのようなパケットは、同じバーチャルチャネルを移動する際に互いに対して物理的にコンフリクトし得るが、ロジック的コンフリクトを有さないために、デッドロックなしに資源コンフリクトを解決することを可能にする。同様に、ロジック的にコンフリクトするおそれのあるパケットを別々のバーチャルチャネルに保つことは、パケット間の資源コンフリクトをなくす。したがって、ロジック的コンフリクトは、第１に完了させるべきパケットの進行を可能にすることによりパケット間の資源コンフリクトをなくして、解決される。
【００４３】
一実施例においては、コヒーレントリンク上で特定のバーチャルチャネル内で特定のソースノードから特定のデスティネーションノードに移動するパケットは順序を保つ。しかしながら、異なったバーチャルチャネルを特定のソースノードから特定のデスティネーションノードに移動するパケットは、順序付けられない。同様に、（たとえ同じバーチャルチャネルを移動するとしても）特定のソースノードから異なったデスティネーションノードへのパケット、または異なったソースノードから同じデスティネーションノードへのパケットは、順序付けられない。
【００４４】
バーチャルチャネルは、コヒーレントファブリックおよび非コヒーレントファブリック上に物理的にマッピングされる（図１９を参照）。たとえば、図１に示すコンピュータシステム１０の実施例においては、相互接続は各ノード間の単方向リンクを含む。したがって、さまざまなバーチャルチャネルを移動するパケットは、単方向リンクに物理的に送信される。パケットは、ソースとデスティネーションとの間で中間のノードを通って移動し得る。たとえば、ノード１２Ａからノード１２Ｄを通って移動するパケットは、ノード１２Ｂおよび１２Ｃを通過し得る。異なったバーチャルチャネルを移動するパケットは、コンピュータシステム１０によって異なって経路制御される。たとえば、第１のバーチャルチャネル内でノード１２Ａからノード１２Ｄを移動するパケットは、ノード１２Ｂを通過し得る一方、ノード１２Ａからノード１２Ｄを第２のバーチャルチャネル内で移動するパケットは、ノード１２Ｃを通過し得る。ノードの各々は、異なったバーチャルチャネル内のパケットの互いに対する物理的コンフリクトを確実になくすための回路を含む。非コヒーレントファブリックにおいては、Ｉ／Ｏノードからのパケットは、そのＩ／Ｏノードとホストブリッジ（図１９を参照）との間で互いのＩ／Ｏノードを通って通過し得る。Ｉ／Ｏノードは、図８に示されるものと同様の態様でバーチャルチャネルに結合され得ることに留意されたい。
【００４５】
以下に詳述される特定の実施例においては、制御パケットバッファは各バーチャルチャネルに割当てられて、そのバーチャルチャネル内を移動する制御パケットをバッファする。別々のデータパケットバッファがまた、データパケットを担持し得る各バーチャルチャネルに割当てられてもよい。制御パケットバッファ（その各エントリは、比較的小さなビット時間を含む）を分けることにより、およびデータパケットバッファ（その各エントリは、キャッシュブロックを保持するために比較的大きな数のビット時間を含む）を分けることにより、バッファ空間を節約する一方で、それでも好適なデータ記憶装置を提供する。データパケットバッファよりも制御パケットバッファが多く実現される（これは、データパケットはすべて対応の制御パケットを有するが、制御パケットはすべてが対応のデータパケットを有するわけではないためである）。バッファ空間を比較的効率的に用いる一方、スループットは高くなり得る。
【００４６】
図９は、コンピュータシステムの一実施例に従って規定されるバーチャルチャネルを示すテーブル４２である。他の実施例も可能であり企図される。示される実施例に対しては、３つのバーチャルチャネルが規定される。コヒーレントリンクに対するこれらのバーチャルチャネルに属するパケットを図７に示し、非コヒーレントリンクに対するバーチャルチャネルに属するパケットを図２０に示す。
【００４７】
コマンドバーチャルチャネルはコマンドパケット（および対応のデータパケット）に対して用いられる。一般的に、コマンドはトランザクションを開始し、よってコマンドは付加的なコマンドパケットの通信を生じさせない。さらに、さまざまなコマンドパケットは、デスティネーション（トランザクションのターゲット）に到達するまでこれらの間に順序がないので、互いに対してロジック／プロトコルコンフリクトを有さない。したがって、コマンドパケットは１つのバーチャルチャネル内に含まれることができる。
【００４８】
コマンドは、（コヒーレントファブリックにおけるコヒーレンシの維持のための）プローブコマンドパケットの生成および（データを送りトランザクションの肯定応答を提供するための）応答パケットの生成をもたらし得る。したがって、プローブパケットおよび応答パケットは、コマンドと同じバーチャルチャネルには含まれない（これにより資源コンフリクトおよびロジック的コンフリクトがデッドロックを生じさせることを防ぐ）。さらに、プローブパケットはプローブ応答および読出応答パケットの生成をもたらし得るので、応答パケットとは異なったバーチャルチャネルに入れられる。
【００４９】
応答パケットもまた、付加的な応答パケットを生じさせる可能性がある（たとえば、SrcDoneおよびTgtDoneは、互いを生じさせ得る）。したがって、応答パケットは、他の応答パケットと同じバーチャルチャネルに入れられることにより、それらとのロジック的コンフリクトを生じさせる可能性がある。しかしながら、多数の応答バーチャルチャネルを設けることは、付加的なバーチャルチャネルを扱うための資源要求（すなわち、バッファ）が増大するので、不所望であるおそれがある。応答パケットは、直接的または（たとえば、コマンドパケットに応答して生成されたプローブを介する）間接的のいずれであっても、コマンドパケットの結果である。ノード１２Ａ−１２Ｄ（および以下に示すＩ／Ｏノード）は、コマンドパケットとのトランザクションを開始する前に、トランザクションの間に生成され得る応答パケット（どのような応答データパケットも含む）を処理するために十分な資源を割当てるよう構成される。同様に、プローブコマンドパケットを生成する前に、ノードはプローブ応答パケットを処理するために十分な資源を割当てるよう構成される（応答パケットがそのノードに返される場合）。この態様で、すべての応答パケットがデスティネーションノードによって受取られる。したがって、応答パケットは１つの応答バーチャルチャネルにマージされる。応答パケット（および対応のデータパケット）は、応答バーチャルチャネル内を移動する。
【００５０】
最後に、プローブコマンドパケットはプローブバーチャルチャネル内を移動する。プローブは、さまざまなメモリ場所のキャッシュ済コピーと、メモリ場所自体との間のコヒーレンシを維持するために用いられる。メモリコントローラによって処理される第１のコマンドパケットに対応するコヒーレンシアクティビティは、次のコマンドパケットが処理される前に完了させなければならない可能性がある。たとえば、もしメモリコントローラの待ち行列が同じキャッシュブロックのコマンドで満たされていれば、最初のコマンドが完了するまでメモリコントローラでさらなるコマンドパケットの処理は起こらない。したがって、プローブコマンドパケット（および応答）は、別々のバーチャルチャネルに与えられて、他のバーチャルチャネル内のパケットとの資源コンフリクトが、プローブコマンドパケットをブロックしないことを確実にする。
【００５１】
テーブル４２はまた、バーチャルチャネルが適用されるコンピュータシステム１０におけるリンクの形成を示す（コヒーレントノードの間のコヒーレントリンクおよび非コヒーレントノードの間の非コヒーレントリンク）。非コヒーレントおよびコヒーレントリンクは両方とも、コマンドおよび応答バーチャルチャネルをサポートする。非コヒーレントリンクはコヒーレンシをサポートせず（プローブコマンドパケットはこれを確実にするために用いられる）、したがって、プローブバーチャルチャネルをサポートしない。
【００５２】
バーチャルチャネル−コヒーレントファブリック
図１０を参照すると、例示的な処理ノード１２Ａの一実施例のブロック図が示される。他の処理ノード１２Ｂ−１２Ｄも同様に構成され得る。他の実施例も可能であり企図される。図１０の実施例においては、処理ノード１２Ａはインターフェイスロジック１８Ａ、１８Ｂ、および１８Ｃおよびメモリコントローラ１６Ａを含む。さらに、処理ノード１２Ａは、プロセッサコア５２、キャッシュ５０、パケット処理ロジック５８、および任意で第２のプロセッサコア５６および第２のキャッシュ５４を含む。インターフェイスロジック１８Ａ−１８Ｃはパケット処理ロジック５８に結合される。プロセッサコア５２および５６は、キャッシュ５０および５４にそれぞれ結合される。キャッシュ５０および５４はパケット処理ロジック５８に結合される。パケット処理ロジック５８はメモリコントローラ１６Ａに結合される。
【００５３】
一般的に、パケット処理ロジック５８は、処理ノード１２Ａが結合されるリンクで受取られる制御パケットに応答し、キャッシュ５０および５４および／またはプロセッサコア５２および５６に応答して制御パケットを生成し、サービスに対してメモリコントローラ１６Ａによって選択されるトランザクションに応答してプローブコマンドおよび応答パケットを生成し、かつ別のノードへの送信のために、ノード１２Ａが中間のノードとなるパケットを、インターフェイスロジック１８Ａ−１８Ｃの別のものへ経路制御するよう構成される。インターフェイスロジック１８Ａ、１８Ｂ、１８Ｃは、ロジックを含み、パケットを受けて、パケット処理ロジック５８によって用いられる内部クロックにパケットを同期させる。
【００５４】
パケット処理ロジック５８は、コンピュータシステム１０によってサポートされるバーチャルチャネルから独立して資源をサポートするためのハードウェアを含む。たとえば、パケット処理ロジック５８はバーチャルチャネルごとに別々のバッファを提供する。図１１に例示的な実施例を示す。代替的な実施例は、インターフェイスロジック１８Ａ−１８Ｃ内、または他のいずれかの好適な場所にバーチャルチャネルから独立して資源を提供するためのハードウェアを提供する。
【００５５】
キャッシュ５０および５４は、高速キャッシュメモリを含み、該高速キャッシュメモリは、データのキャッシュブロックを記憶するよう構成される。キャッシュ５０および５４は、プロセッサコア５２および５６の内部にそれぞれ統合され得る。これに代えて、キャッシュ５０および５４は所望のようにバックサイドキャッシュ構成またはインライン構成でプロセッサコア５２および５６に結合されてもよい。さらに、キャッシュ５０および５４は、キャッシュの階層として実現されてもよい。（階層内で）プロセッサコア５２および５６に近い方のキャッシュは、所望であればプロセッサコア５２および５６内に統合されてもよい。
【００５６】
プロセッサコア５２および５６は、予め定められた命令セットに従って命令を実行するための回路を含む。たとえば、ｘ８６命令セットアーキテクチャが選択される。これに代えて、アルファ、パワーＰＣ、または他のどのような命令セットアーキテクチャを選択してもよい。一般的に、プロセッサコアはデータおよび命令のためにキャッシュにアクセスする。もしキャッシュミスが検出されると、読出要求が生成され、ミスのあるキャッシュブロックがマッピングされたノード内のメモリコントローラに送信される。
【００５７】
図１１を参照すると、パケット処理ロジック５８の一実施例のブロック図が示される。他の実施例が可能であり企図される。図１１の実施例においては、パケット処理ロジック５８は、第１の組の制御およびデータパケットバッファ６０、第２の組の制御およびデータパケットバッファ６２、第３の組の制御およびデータパケットバッファ６４、制御ロジック６６、データバッファプール６８、および応答カウンタプール７０を含む。制御およびデータパケットバッファ６０は、コマンドバッファ（ＣＢ）６０Ａ、応答バッファ（ＲＢ）６０Ｂ、プローブバッファ（ＰＢ）６０Ｃ、コマンドデータバッファ（ＣＤＢ）６０Ｄ、および応答データバッファ（ＲＤＢ）６０Ｅを含む。同様に、制御およびデータパケットバッファ６２は、コマンドバッファ（ＣＢ）６２Ａ、応答バッファ（ＲＢ）６２Ｂ、プローブバッファ（ＰＢ）６２Ｃ、コマンドデータバッファ（ＣＤＢ）６２Ｄ、および応答データバッファ（ＲＤＢ）６２Ｅを含む。制御およびデータパケットバッファ６４は、コマンドバッファ（ＣＢ）６４Ａ、応答バッファ（ＲＢ）６４Ｂ、プローブバッファ（ＰＢ）６４Ｄ、コマンドデータバッファ（ＣＤＢ）６４Ｄおよび応答データバッファ（ＲＤＢ）６４Ｅを含む。制御およびデータパケットバッファ６０はインターフェイスロジック１８Ａによって受取られたパケットを受取るよう結合される（たとえば、ライン２４Ｂ上）。同様に、制御およびデータパケットバッファ６２は、インターフェイスロジック１８Ｂによって受取られたパケットを受取るよう結合され、制御およびデータパケットバッファ６４はインターフェイスロジック１８Ｃによって受取られたパケットを受取るよう結合される。制御およびデータパケットバッファ６０、６２、および６４は、制御ロジック６６に結合される。さらに、応答データバッファ６０Ｅ、６２Ｅ、および６４Ｅが、データバッファプール６８に結合される。データバッファプール６８および応答カウンタプール７０は、制御ロジック６６に結合され、これはさらにノードＩＤレジスタ７２、制御パケットアクティブレジスタ７４Ａ−７４Ｃおよびデータパケットアクティブレジスタ７６Ａ−７６Ｃを含む。制御ロジック６６は、受信および送信インタフェースを介してインターフェイス１８Ａ−１８Ｃに結合され、かつ同様にメモリコントローラ１６Ａおよびキャッシュ５０（および任意のキャッシュ５４）に結合される。データバッファプール６８がさらにメモリコントローラ１６Ａおよびキャッシュ５０（および任意のキャッシュ５４）に結合される。
【００５８】
制御およびデータパケットバッファの組の各々が、バーチャルチャネルごとに異なったバッファを提供する。すなわち、本実施例においては、コマンドバッファ６０Ａはコマンドバーチャルチャネルに割当てられ、応答バッファ６０Ｂは応答バーチャルチャネルに割当てられ、プローブバッファ６０Ｅはプローブバーチャルチャネルに割当てられる。この態様で、１つのバーチャルチャネルにおける制御パケットの受信は、別のバーチャルチャネルにおける制御パケットの受信によって妨げられない。各バーチャルチャネルからの制御パケットは、そのバーチャルチャネルに対応する制御パケットバッファに記憶され、よって別のバーチャルチャネルからの制御パケット（異なった制御パケットバッファに記憶される）と物理的コンフリクトを起こさない。同様に名称がつけられるバッファ６２および６４内のバッファは、上述のようにバーチャルチャネルに割当てられる。
【００５９】
同様に、データパケットバッファは、データパケットを担持する各バーチャルチャネルに与えられる（プローブバーチャルチャネルはこの実施例においてはデータパケットを担持しない）。すなわち、本実施例においては、コマンドデータバッファ６０Ｄはコマンドバーチャルチャネルに割当てられ、応答データバッファ６０Ｅは応答バーチャルチャネルに割当てられる。同様に名称がつけられるバッファ６２および６４内のバッファは、上述のようにバーチャルチャネルに割当てられる。
【００６０】
本実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、受取ったパケットを制御パケット（制御経路内に提供される）と、データパケット（データ経路に提供される）とに分割するよう構成される。制御経路は、制御パケットバッファに結合され（たとえば、バッファ６０Ａ−６０Ｃがインターフェイスロジック１８Ａからの制御経路に結合される）、データ経路はデータパケットバッファに結合される（たとえば、バッファ６０Ｄ−６０Ｅがインターフェイスロジック１８Ａからのデータ経路に結合される）。制御ロジック６６は、受信および送信インターフェイスを介してパケットの表示を受取るよう結合され、かつ受取ったパケットのバッファエントリを割当てるよう構成される。他の企図される実施例においては、受取ったパケットはインターフェイスロジックによって制御およびデータパケットに分割されない。そのような実施例においては、制御ロジック６６はＣＴＬ信号を受取って、ビット時間のデータパケットとビット時間の制御パケットとを区別する。
【００６１】
一般的に、制御ロジック６６は、他のバッファ内のパケットから独立してさまざまなバッファからのパケットを処理するよう構成される。したがって、異なったバーチャルチャネル内を移動するパケットは互いに対して物理的にコンフリクトしない。
【００６２】
制御ロジック６６は、バッファ６０、６２および６４内の制御パケットを調べて、制御パケットがノード１２Ａ（「このノード」）に対して宛先決めされているか、または別のノードに送られるべきかどうかを判断する。ノードＩＤレジスタ７２は、このノードのノードＩＤを記憶し、制御ロジック６６はノードＩＤを用いて制御パケットがこのノードに対して宛先決めされているかどうかを判断する。本実施例においては、プローブバーチャルチャネル内のパケットはブロードキャストパケットであり、よってこのノードと、このノードがパケットを送るべき他のノードに対して宛先決めされる（よってノードＩＤ比較は用いられない）。他のバーチャルチャネル内のパケットは方向付けられた（directed）パケットであり、これに対してデスティネーションノードフィールドは、パケットがこのノードに宛先決めされているか、または別のノードに送られるべきであるかどうかを識別する。制御ロジック６６は、１つ以上の経路制御テーブルを含み、これはデスティネーションノードごとに、インターフェイスロジック１８Ａ−１８Ｃのどれがパケットを送るために用いられるべきかを示す。制御ロジック６６は、識別されたインターフェイスロジック１８Ａ−１８Ｃを介して送信された受信パケットを受けるよう結合される受信ノードが、制御パケットに対応するバーチャルチャネルに対する空いた制御パケットバッファを有している場合に、制御パケットを送り得る。さらに、制御パケットがデータパケットを識別すると、制御パケットに対応するバーチャルチャネルに対する空いたデータパケットバッファは、制御パケットおよび後続の特定されたデータパケットを送る前に識別される。制御ロジック６６は、制御パケット（およびもし特定されていればデータパケット）が送られるべきであるかどうかを判断し、受信および送信インターフェイスを用いてパケットを識別されたインターフェイスロジック１８Ａ−１８Ｃに送り、これは次いでパケットを受信ノードに送る。また、制御ロジック６６は、対応の種類のバッファが空いたことを記憶して、次の情報パケットがインターフェイス１８Ａ−１８Ｃを介して送られるようにし、パケットはノード１２Ａによって受取られて、受信インターフェイスの送信ノードに対する空きバッファを示す。
【００６３】
一方、もし制御パケットがこのノードに宛先決めされていれば、制御ロジック６６はパケットの種類に依存してパケットを処理する。たとえば、もし制御パケットがメモリコントローラ１６Ａに標的を定められたコマンドであれば、制御ロジック６６は制御パケットをメモリコントローラ１６Ａに運ぶことを試みる。メモリコントローラ１６Ａは、たとえば処理されるべきトランザクションに対して待ち行列を用い、かつ待ち行列がフルであれば制御パケットを拒絶し得る。プローブパケットを処理するために、制御ロジック６６はキャッシュ５０および５４（およびプロセッサコア５２および５６の内部のいずれのキャッシュでも）と通信して、アドレス指定されたキャッシュブロックのステータスを判断する。制御ロジック６６は、ステータスを備えたプローブ応答パケット（またはもしキャッシュブロックがノード内で変更されていれば、読出応答パケットとデータ）を生成し、プローブ応答パケットを送信する（受信ノードバッファが利用可能である場合）。
【００６４】
受取ったパケットの処理に加えて、制御ロジック６６は、キャッシュ５０および５４からのフィル要求およびヴィクティムブロックに応答してパケットを生成し、かつプロセッサコア５２および５６からの直接の要求に応答してパケットを生成する（たとえば、キャッシュ不可能要求、Ｉ／Ｏ要求など）。さらに、応答パケットはメモリコントローラに応答して生成され、送信に対するデータを提供、またはトランザクションを完了させる。制御ロジック６６は、メモリコントローラ１６に応答して、処理に対する対応のコマンドを選択してプローブコマンドパケットを生成し、プローブコマンドパケットをブロードキャストし得る（他のパケット送信と同様に、受信ノードバッファが利用可能であると想定する）。
【００６５】
上述のように、ノードはそのノードによって生成された制御パケットに対応する応答パケットを処理するための十分な資源を提供する。本実施例においては、制御ロジック６６はパケットを生成するが、このパケットは２つの場合においてノードに返される応答パケットをもたらし得る：（ｉ）トランザクションを開始するためのコマンドパケットを生成する場合（たとえば、キャッシュ５０および５４、またはプロセッサコア５２および５６からの要求に応答する）；および（ii）メモリコントローラ１６Ａを標的とする制御パケットに対するプローブパケットを生成する場合。より特定的には、（ii）の場合は、メモリコントローラ１６Ａを標的とするサイズ決めされた書込の場合に生じ得る。いずれの場合においても、制御ロジック６６は、応答パケットを処理するための資源を割当てる。
【００６６】
本実施例においては、制御ロジック６６は応答を処理するためにデータバッファプール６８および応答カウントプール７０からの資源を割当てる。データバッファプール６８は、データのキャッシュブロックを記憶するための複数のエントリを含み得る一方、応答カウンタプール７０は複数のカウンタを含み得る。データバッファプールエントリは、トランザクションに対応する応答データを記憶するために割当てられ得る。カウンタは、受取った応答をカウントする（かつ、プローブ応答において提供され得るいかなる状態情報をも保持する）ために割当てられ得る。応答パケットは、割当てられたカウンタを用いて（期待される数の応答に到達するまで）カウントされ、応答パケットによって受取られたデータは割当てられたデータバッファに記憶され得る。トランザクションに関与する最大２つのパケットがデータを担持し得ることに留意されたい（１つは、MemCancel応答パケットが、応答パケットの送信の前にメモリコントローラに到達しなかった場合の、標的決めされたメモリコントローラからのものであり、他方はデータの変更されたキャッシュ済コピーを有するプローブされたノードからのものである）。２つのデータパケットが受取られた場合には、プローブされたノードからのパケットが保持されて、メモリコントローラからのパケットは捨てられる。
【００６７】
一旦期待される応答の各々が受取られ、応答データが受取られていると、制御ロジック６６は行なわれているトランザクションのタイプに依存して、データをメモリコントローラ１６Ａまたはキャッシュ５０または５４に、送信する。たとえば、もし応答がパケット処理ロジック５８によって生成されたプローブコマンドに応答して生成されたプローブ応答であれば、応答データはメモリコントローラ１６Ａに送信され得る。これに代えて、もし応答が読出トランザクションによるものであれば、データはキャッシュ５０または５４に送信される。
【００６８】
データバッファプール６８は、ノード１２Ａから送信されるべきデータを記憶するためにも用いられることに留意されたい。たとえば、ノード１２Ａからの書込コマンドに対するヴィクティムブロックデータまたは書込データは、データバッファプール６８に記憶され得る。これに代えて、別々のバッファがこのデータのために提供されてもよい。さらに、さまざまなトランザクションに対して用いられるバッファのプールを提供する代わりに、所望のように、トランザクションタイプによって別々のバッファが提供されてもよい。
【００６９】
ここで用いられる場合、バッファとは後の検索のために情報の１つ以上の項目を記憶するために用いられる記憶要素である。バッファは、１つ以上のレジスタ、ラッチ、フリップフロップ、または他のクロックされる記憶装置を含む。これに代えて、バッファは好適に構成された組のランダムアクセスメモリ（ＲＡＭ）セルを含んでもよい。バッファは、いくつかのエントリに分割され、各エントリはバッファが設計されている情報の１つの項目を記憶するよう設計される。エントリは、いかなる好適な様式においても割当てられおよび割当て解除され得る。たとえば、バッファはより古いエントリが削除されるにつれエントリがシフトされる、シフト先入れ先出し（ＦＩＦＯ）バッファで動作されてもよい。これに代えて、ヘッドおよびテールポインタを用いて、バッファ内の最も古いおよび最も新しいエントリを示し、エントリはバッファから削除されるまでバッファの特定の記憶場所に保持されてもよい。ここで使用される「制御ロジック」という用語は、説明された動作を実現するために、入力に対して動作し、これに応答して出力を生成する、組合わせロジックおよび／またはステートマシンのいかなる組合せをも指す。
【００７０】
特定の一実施例においては、パケットは一連のビット時間としてインターフェイスロジック１８Ａ−１８Ｂから受取られる。インターフェイスロジック１８Ａ−１８Ｃは、制御またはデータビット時間が送信されているかどうかを示し、制御ロジック６６は、ビット時間を記憶するための適切なバッファを生じさせる。制御ロジック６６は、制御パケットアクティブレジスタ７４およびデータパケットアクティブレジスタ７６を用いて、現在受取られている制御パケットまたはデータパケットがどのバーチャルチャネルに属しているかを識別し得る。制御パケットアクティブレジスタ７４は、インタフェースロジック１８Ａ−１８Ｃごとに与えられる（たとえば、制御パケットアクティブレジスタ７４Ａはインターフェイス１８Ａに対応し得る）。同様に、データパケットアクティブレジスタ７６はインターフェイスロジック１８Ａ−１８Ｃごとに与えられる（たとえば、データパケットアクティブレジスタ７６Ａはインターフェイス１８Ａに対応し得る）。第１のビット時間の制御パケットに応答して、制御ロジック６６はコマンドフィールド（第１のビット時間内）をデコードし、制御パケットがどのバーチャルチャネルに割当てられているかを判断する。制御ロジック６６は、バッファエントリを対応の（制御パケットが受取られるインターフェイスロジック１８Ａ−１８Ｃに対応する組内の）制御パケットバッファに割当て、および、パケットが受取られるインターフェイスロジック１８Ａ−１８Ｃに対応する制御パケットアクティブレジスタ７６が、その制御パケットバッファを示すよう設定する。同じインターフェイスロジック１８Ａ−１８Ｃからの後続の制御パケットビット時間は、各ビット時間の制御パケットが受取られるまで、示されたバッファ内の示されたエントリに記憶される。もし制御パケットがデータパケットを特定すると、制御ロジック６６は、データパケットバッファエントリを識別されたバーチャルチャネルに対応するデータパケットバッファに割当てる。データパケットビット時間は、各ビット時間のデータが受取られるまで、示されたバッファの示されたエントリ内に記憶される。代替的な実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、ビット時間のパケットを集め、パケット全体をパケット処理ロジック５８に送信してもよい。そのような実施例においては、制御パケットアクティブレジスタ７４およびデータパケットアクティブレジスタをなくしてもよい。さらに別の実施例においては、インターフェイスロジック１８Ａ−１８Ｃは、パケット処理ロジック５８への並行した送信のためのいくつかのビット時間を集めるが、ビット時間の数がパケットよりも少ない可能性がある。さらに別の実施例においては、バッファ６０、６２および６４はパケット処理ロジック５８の代わりにそれぞれのインターフェイスロジック１８Ａ−１８Ｃ内に場所決めされてもよい。
【００７１】
図１１に示される実施例においては、インターフェイスロジック１８Ａ−１８Ｃごとにバッファの別々の組が提供される。代替的な実施例においては、バッファはインターフェイスロジックの間で分割され得る（バーチャルチャネルタイプごとの）プールとして提供されてもよい。そのような実施例は、別のノードには結合されないインターフェイスロジック（たとえば、図１の例におけるインターフェイスロジック１８Ｃ）に、ゼロバッファを与えることによりバッファを活用し得る。インターフェイスロジック１８Ｃに割当てられたであろうバッファは、インターフェイスロジック１８Ａ−１８Ｂによって用いられるために割当てられる。
【００７２】
図１２を参照すると、データバッファプール６８内のデータバッファプールエントリ８０の一実施例を例示する図が示される。他の実施例も可能であり企図される。図１２の実施例においては、データバッファプールエントリ８０は、ソースタグフィールド８２、ソースノードフィールド８４、ソースユニットフィールド８８、およびデータフィールド８６を含む。
【００７３】
制御ロジック６６が、トランザクションに対する応答データパケットを記憶するためにデータバッファプールエントリ８０を割当てる場合、制御ロジック６６はトランザクションのソースノード、ソースユニット、およびソースタグを、ソースノードフィールド８４、ソースユニットフィールド８８、およびソースタグフィールド８２にそれぞれ記憶する。ソースノード、ソースユニット、およびソースタグは独自に未処理の（outstanding）トランザクションを識別し、かつソースノード、ソースユニット、およびソースタグは未処理のトランザクションに対応する応答パケットによって担持されるために、トランザクションの応答パケット（および対応のデータパケット）が識別されて、データパケットは割当てられたエントリに記憶され得る。言換えると、応答データパケットを特定する応答パケットが受取られると、応答パケットのソースノード、ソースユニット、およびソースタグは、ソースノードフィールド８４、ソースユニットフィールド８８およびソースタグフィールド８４と比較されて、応答データのために先行して割当てられたデータバッファプールエントリ８０の位置を突止め、データは応答データバッファからデータバッファプールエントリ８０のデータフィールド８６にコピーされ得る。データフィールド８６はデータのキャッシュブロックを含み得る。
【００７４】
図１３を参照すると、応答カウンタプール７０内の応答カウンタ９０の一実施例を例示する図が示される。他の実施例も可能であり企図される。図１３の実施例においては、応答カウンタ９０はソースタグフィールド９２、ソースノードフィールド９４、ソースユニットフィールド９５、応答カウントフィールド９６、および受信ステートフィールド９８を含む。
【００７５】
制御ロジック６６が、トランザクションに対する応答カウントを記憶するために応答カウンタ９０を割当てる場合、制御ロジック６６はソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２にそれぞれトランザクションのソースノード、ソースユニットおよびソースタグを記憶し得る。ソースノードフィールド９４、ソースユニットフィールド９５、およびソースタグフィールド９２は、データバッファプールエントリ８０の対応のフィールド８４、８８、および８２と同様に用い得る。
【００７６】
トランザクションの割当の際に、応答カウントフィールド９６は、トランザクションに対して期待される応答の数に初期化され得る。ソースノード、ソースユニット、およびソースタグがフィールド９４、９５および９２にそれぞれ記憶された応答パケットが受取られると、応答カウントがデクリメントされる。応答カウンタが０に到達すると、すべての応答は受取られ、トランザクションはコミットされている。これに代えて、カウントは０に初期化されて、応答パケットは期待される数の応答が受取られるまで応答カウントをインクリメントしてもよい。
【００７７】
応答ステートフィールド９８は、データが受取られるであろう状態を示すために用い得る。状態は、ノード１２Ａがキャッシュブロックの受信の際に獲得した、キャッシュブロックに対するアクセス権およびキャッシュブロックに対するコヒーレンシを維持するための責任を示す。たとえば、ＭＯＥＳＩ（変更、所有、排他的、共用、および無効）コヒーレンシ状態が用いられて、受信状態フィールド９８は、サポートされる状態のうちの１つに符号化される。これに代えて、他のいかなる好適な組のコヒーレンシ状態が用いられてもよい（たとえばＭＥＳＩ状態）。受信状態フィールド９８は、どの他のノードもトランザクションによって送られるキャッシュブロックのコピーを有さない場合に獲得される状態に初期化され得る。プローブ応答が受取られて、キャッシュブロックのコピーがプローブノードによって維持されているか、またはダーティデータが提供されていることを示すと、受信状態フィールド９８はそれに従って更新される。一実施例においては、共用ビットがプローブ応答パケットに含まれて、キャッシュブロックのコピーがプローブ応答を提供したプローブされたノードによって維持されていることを示し得る。さらに、プローブされたノードからの読出応答パケットの受信は、ノードがキャッシュブロックのダーティコピーを有することを示す。読出応答パケットはまた、プローブされたノードによってコピーが維持されているかどうかを示すための共用ビットを含み得る。
【００７８】
データバッファプール６８および応答カウンタプール７０は、未処理のトランザクションに対する応答を扱うための一例にすぎないことに留意されたい。別の実施例においては、未処理のトランザクションのテーブルが維持される。テーブルは、上述のものと同様のソースノード、ソースユニット、ソースタグ、データ、受信状態、および応答カウント（または、制御ロジック６６がすべての応答が受取られたことを判断し得る等価の情報）を含む。いかなる好適な組の資源をも用い得る。
【００７９】
図１４は、パケットを受信するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートである。他の実施例も可能であり企図される。示される実施例は、パケットを一連のビット時間としてパケット処理ロジック５８内に受取る。他の実施例は、ビット時間のパケットをインタフェースロジック１８Ａ−１８Ｃに累積させ、完全なパケットをパケット処理ロジック５８に提供するが、この場合パケットの受信をビット時間で管理することに関連するステップは削除される。図１４に示されるステップは、理解を助けるために特定の順序で示されているが、いかなる好適な順序をも用い得る。さらに、ステップはパケット処理ロジック５８内の組合せロジックを用いて並列に行なわれてもよい。図１４に示されるステップは、インターフェイスロジック１８Ａ−１８Ｃの各々から独立して並列に行われ得るが、これはインターフェイスロジックごとにビット時間が並行に受信されるためである。
【００８０】
パケット処理ロジック５８は、受信したビット時間がデータパケットの一部であるか、またはコマンドパケットの一部であるかを示すインターフェイスロジックからの信号を受取る。もしビット時間がデータパケットビット時間であれば（判断ブロック１００）、ビット時間はそのインターフェイスロジックに対応するデータパケットアクティブレジスタによって示されるデータバッファ（およびデータバッファ内のエントリ）によって記憶される（ステップ１０２）。もしデータパケットビット時間がデータパケットの最後のビット時間であると、制御ロジック６６は対応のデータパケットアクティブレジスタを無効化する。一方、もしビット時間が制御パケットビット時間であれば、パケット処理ロジック５８は制御パケットが現在受取りが進行中のものであるかどうかを判断する（たとえば、制御パケットアクティブレジスタが有効であるかどうか、判断ブロック１０４）。もし制御パケットが現在進行中であれば、ビット時間は制御パケットアクティブレジスタによって示される制御パケットバッファに記憶される（ステップ１０６）。もし制御パケットビット時間が制御パケットの最後のビット時間であれば、制御ロジック６６は対応の制御パケットアクティブレジスタを無効化し得る。
【００８１】
これに代えて、制御パケットは現在進行中ではない可能性がある。この場合には、パケット処理ロジック５８は新しく受取られた制御パケットのコマンドフィールドをデコードして、制御パケットが属するバーチャルチャネルを識別する（ステップ１０８）。識別されたバーチャルチャネルに対応する制御パケットバッファエントリは割当てられ、制御パケットビット時間は割当てられた制御パケットバッファエントリに記憶される。
【００８２】
さらに、パケット処理ロジック５８は、制御パケットが後続のデータパケットを特定するかどうかを判断する（判断ブロック１１０）。データパケットが特定されると、パケット処理ロジック５８は識別されたバーチャルチャネルに対応するデータバッファからデータバッファエントリを割当て、そのデータバッファ（およびエントリ）を示すようデータパケットアクティブレジスタを更新する（ステップ１１２）。
【００８３】
ここで図１５を参照して、コマンドパケットを処理するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１５に示されるステップは理解を容易にするためある特定の順序にて示されるが、任意の好適な順序を用いてよい。さらに、ステップは、並列に、組合せロジックをパケット処理ロジック５８内にて用いながら実行してもよい。図１５に示されるステップは並列かつ独立して各インターフェイスロジック１８Ａ〜１８Ｃおよび／または各コマンドパケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。代替的に、１つのコマンドパケット（またはインターフェイスロジック１８Ａ〜１８Ｃにつき１つのコマンドパケット）を、処理に対し、好適な公平性アルゴリズムに従って選択してもよい。一般に、１つのバーチャルチャネルから処理のために選択されたパケットはあるチャネル内におけるパケットに対する順序付け規則に従う（たとえば、同じソースから同じデスティネーションへのパケットは順に選択される）が、パケットの、処理に対する選択は、所望されかつ順序付け規則が許す場合には、順序が乱れた状態でなされてもよい。
【００８４】
パケット処理ロジック５８はコマンドパケットの標的がこのノードであるかどうかを判断する（判断ブロック１２６）。たとえば、パケット処理ロジック５８はコマンドパケットのデスティネーションノードフィールドに記録されるデスティネーションノードをノードＩＤレジスタ７２に記憶されるノードＩＤと比較してもよい。これらのノードが一致する場合、そのコマンドはこのノードを標的としている。コマンドがこのノードを標的としない場合には、パケット処理ロジック５８はそのコマンドパケット（および特定される場合には対応のデータパケット）をデスティネーションノードに応答して送る（ステップ１２８）。たとえば、パケット処理ロジック５８は、パケットを特定のデスティネーションノードへ送るためインターフェイスロジック１８Ａ〜１８Ｃの１つを送信インターフェイスとして識別するパケット経路制御テーブルを維持してもよい。対応のコマンドバッファ（およびデータパケットが特定される場合にはデータバッファ）が、パケット経路制御テーブルにより特定されるリンクに結合される受信ノードにおいて利用可能であるなら、パケット処理ロジック５８はコマンドパケットを送る。加えて、コマンドパケットがデータパケットを特定する場合には、コマンドパケットを送ることは、送信リンク上のデータパケットが活性状態ではあるが未だ送信されていない場合には、ストールされてもよい。
【００８５】
コマンドパケットがこのノードを標的としている場合、パケット処理ロジック５８はコマンドパケット（および適用可能である場合には対応のデータパケット）をメモリコントローラ１６Ａに与えてもよい（ステップ１３０）。一旦コマンドパケットが処理される（送られるかまたはこのノードによって受け入れられる）と、そのコマンドパケットはコマンドバッファエントリから取除かれ（適用可能である場合にはデータはコマンドデータバッファエントリから取除かれ）ることに注目されたい。
【００８６】
プローブコマンドは同じ態様で処理されてもよいが、ただし、プローブコマンドは後のデータパケットを特定せず、したがって、データパケットに対するチェックは無視されるかもしれないことに注意されたい。さらに、プローブは内部的に（たとえば当該ノード内においてキャッシュをプローブすることにより）処理されるとともに送られてもよく、なぜならば、それらは放送パケットであるからである。ノードはキャッシュのプローブ後にプローブ応答パケットを発生し送信してもよい。
【００８７】
選択されるコマンドパケットが対応のデータパケットを特定する場合には、さまざまな実施例によってそのコマンドパケットの処理をたとえそのデータパケットがまだ受取られていなくても行なってもよく、またはそのデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。コマンドパケットが処理されるときにデータパケットが受取られていなかった場合には、そのデータパケットはそれが受取られるときに上述のように処理されてもよい。
【００８８】
図１６を参照して、応答パケットを処理するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１６に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。さらに、ステップは、並列に、組合せロジックをパケット処理ロジック５８内で用いながら実行してもよい。図１６に示されるステップは並列かつ独立して各インターフェイスロジック１８Ａ〜１８Ｃおよび／または各応答パケットバッファごとに実行してもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。
【００８９】
パケット処理ロジック５８は応答パケットのデスティネーションノードがこのノードであるか否かを判断する（判断ブロック１４４）。デスティネーションノードが別のノードである場合に、応答バーチャルチャネルに対する空いているバッファエントリがその応答パケットが送られるリンク上の受信機にある場合には、パケット処理ロジック５８はその応答パケット（および適用可能である場合には対応のデータパケット）を送る（ステップ１４６）。
【００９０】
応答パケットのデスティネーションノードがこのノードである場合には、パケット処理ロジック５８は対応の応答カウンタを減分し受信状態を更新するよう構成されるが、それは、その応答が、受信状態がデフォルト状態から変更されるべきである旨を示すプローブ応答である場合である（ステップ１４８）。加えて、その応答パケットがデータパケットを特定する場合には、そのデータパケットを、対応の応答データバッファから、その応答に割当てられたデータバッファに移動させる（ステップ１５０）。
【００９１】
カウンタを減分した後、パケット処理ロジックはカウンタをテストしてすべての応答パケットが受取られ処理されたか否かを判断する（判断ブロック１５２）。すべての応答パケットが受取られ処理されたと判断される場合には、パケット処理ロジック５８はメモリコントローラ１６Ａまたはキャッシュ５０および５４に対しそれらがコマンドを完了してもよい旨を知らせ、データバッファからの関連のデータおよび応答カウンタからの受信状態を与えてもよい（適用可能である場合−−ステップ１４５）。一旦応答パケットが処理される（送られるかまたはこのノードによって受入れられる）と、その応答パケットは応答バッファエントリ（および適用可能である場合には応答データバッファエントリ）から取除かれる。
【００９２】
上の議論において、コマンドパケットまたは応答パケットの処理の「中断」という語が用いられている。一般に、処理が「中断」されるのは、その特定のパケットの処理が、中断の理由が取除かれるまで停止される場合である。同じタイプの他のパケットの処理をそのコマンドまたは応答の処理の中断中に行なってもよい。
【００９３】
選択される応答パケットが対応のデータパケットを特定する場合、さまざまな実施例による応答パケットの処理をたとえそのデータパケットがまだ受取られていなくても（つまりそのデータパケットがまだデータバッファ内になくても）行なってもよく、またはデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。応答パケットが処理されるときにデータパケットが到着していない場合には、そのデータパケットはそれが受取られるときに上記のように処理されてもよい。
【００９４】
図１７を参照して、ノードが結合されるリンク上においてパケットを起動するためのパケット処理ロジック５８の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。図１７に示されるステップは理解を容易にするためある特定の順序にて示されるが、任意の好適な順序を用いてよい。さらに、ステップを、並列に、組合せロジックをパケット処理ロジック５８内にて用いながら実行してもよい。パケット処理ロジック５８はリンク上のパケットを応答的に起動することによりキャッシュ５０および５４からの要求／犠牲ブロックならびに／またはコア５２および５６により実行される動作を満たしてもよい。加えて、プローブパケットの起動を、処理のためにメモリ動作を選択するメモリコントローラ１６Ａに応答して行なってもよい。応答パケットの起動は、プローブが処理された後、かつこのノードによりソースを与えられるかまたはこのノードを標的としているトランザクションが完了されたことに応答して行なわれてもよい。
【００９５】
パケット処理ロジック５８は、起動されるべきパケットの結果、データがこのノードに戻されるかもしれないか否かを判断する（判断ブロック１６０）。たとえば、ノードによって起動される読出トランザクションはデータがノードに戻されることを引き起こし、一方、ノードにより起動される書込トランザクションはデータがノードに戻されることを引き起こさない。ChangetoDirtyトランザクションの結果、データはノードに戻されるかもしれない（別のノードがキャッシュブロックに対しダーティ状態において影響を与えた場合）。同様に、プローブパケットはデータをこのノードへ戻すことを引き起こすかもしれないが、それは、別のノードがキャッシュブロックに対しダーティ状態において影響を及ぼしプローブ応答がこのノードに向けられる場合である。トランザクションの結果、データがこのノードに戻される場合には、パケット処理ロジック５８はあるデータバッファをデータバッファプール６８から割当てる（ステップ１６２）。
【００９６】
加えて、パケット処理ロジック５８はプローブ応答がこのノードに対しパケットに応答して戻されるか否かを判断する（ステップ１６６）。これが生ずるのはパケットがプローブであるかまたはパケットがこのノードへのプローブ応答をもたらすようなトランザクションを開始している場合であるかもしれない（たとえば読出トランザクション）。プローブ応答がこのノードに戻される場合、パケット処理ロジック５８は応答カウンタを応答に対し当該トランザクションに割当てその応答カウンタをコヒーレントファブリックにおけるノードの数に初期化する（ステップ１６８）。
【００９７】
パケット処理ロジック５８は、さらに、他の応答が、このノード（たとえばSrcDone、TgtDoneなど）に対し、起動中のパケットに応答して戻されるかどうかを判断する（ステップ１６４）。そのような他の応答が戻される場合には、パケット処理ロジック５８は応答カウンタを割当て初期カウントを１に設定する（ステップ１６５）。この後、パケット処理ロジック５８はパケットを送る（ステップ１７０）。
【００９８】
予め資源を割当てることにより応答パケット（データを含む）の取扱いをトランザクションの起動前に行なうことにより、応答パケットは受信で処理可能である。したがって、ある応答パケットは他の応答パケットとロジック的／プロトコルコンフリクトを有するかもしれないが、応答パケットは応答バーチャルチャネルにマージされるかもしれず、なぜならば、物理的コンフリクトは各応答パケットがそのデスティネーションノードに到着するにつれ処理されることにより取除かれるかもしれないからである。
【００９９】
次に図１８を参照して、バッファ解放フィールドを含む情報パケット１８０の一実施例を示すブロック図が示される。他の実施例も可能であり意図される。バッファ解放フィールドは各バッファのタイプごとに含まれる。RespDataフィールドは応答データバッファに対応する。Responseフィールドは応答バッファに対応する。同様に、CmdDataフィールドはコマンドデータバッファに対応し、Cmdフィールドはコマンドバッファに対応する。Probeフィールドはプローブバッファに対応する。
【０１００】
バッファ解放フィールドの各々は２つのビットを含み、単一のリンク上における送信機から受信機への１つの情報パケット１８０の伝送において解放されるべき０〜３の各タイプのバッファを斟酌する。３つより多いエントリをバッファ内において与えてもよく、複数の情報パケットを用いて１つのタイプのうちの３つより多くを解放してもよい。パケット処理ロジック５８はバッファカウントを各タイプのバッファおよび各インターフェイスロジック１８Ａ〜１８Ｃごとに含んで、各インターフェイスが結合されるリンクの他方端における受信機によって与えられる各タイプのバッファの総数を示してもよい。これらのカウンタの初期化は、パワーアップにおいて、情報パケットを受信機から送信機へ、バッファ解放フィールドがその受信機において利用可能なバッファ数にセットされる状態で送ることにより行なわれてもよい。３つより多いエントリは、複数の情報パケットを送ることにより示されてもよい。
【０１０１】
パケット処理ロジック５８はパケットをある所与のバーチャルチャネルにおいて送ってもよいが、それは、対応のタイプのバッファ（およびパケットがデータパケットを特定する場合にはデータバッファ）が、パケットが送られている受信機において利用可能である限りにおいてである。加えて、パケット処理ロジック５８は、ノード１２Ａにおいてパケット処理ロジック５８によるパケットの処理のため解放される、各インターフェイス１８Ａ〜１８Ｃに対する各タイプのバッファの数に注目する。周期的に、パケット処理ロジック５８は情報パケット１８０を各インターフェイスロジック１８Ａ〜１８Ｃを介して送り、そのリンク上の送信機に対し、パケット処理ロジック５８により解放されたバッファエントリの数を示す。
【０１０２】
バーチャルチャネル−非コヒーレントファブリック
ここで図１９を参照して、Ｉ／Ｏサブシステム２００の一実施例のブロック図を示す。他の実施例も可能であり意図される。図１９の実施例においては、Ｉ／Ｏサブシステム２００はホストブリッジ２０２と複数のＩ／Ｏノード２０４Ａ、２０４Ｂおよび２０４Ｃとを含む。ホストブリッジ２０２は、処理ノード１２Ｄに、ライン２４Ｉ〜２４Ｊを含むコヒーレントリンクを介して結合され、さらには、Ｉ／Ｏノード２０４Ａに、ライン２４Ｋ〜２４Ｌを含む非コヒーレントリンクを用いて結合される。Ｉ／Ｏノード２０４Ａ〜２０４Ｃはさらなる非コヒーレントリンクを用いてデージーチェーン構成で相互接続される（ライン２４Ｎ〜２４Ｏ）。
【０１０３】
一般に、Ｉ／Ｏノード２０４Ａ〜２０４ＣはトランザクションをＩ／Ｏサブシステム２００内にて起動してもよい。それらトランザクションは究極的には別のＩ／Ｏノード２０４Ａ〜２０４Ｃ、別の非コヒーレントリンク上のＩ／Ｏノード、またはメモリ１４にて標的としてもよい。単純化のため、トランザクションはホストブリッジ２０２とＩ／Ｏノード２０４Ａ〜２０４Ｃとの間においてその実際の標的にかかわらず実行されてよい。ホストブリッジ２０２はトランザクションをＩ／Ｏサブシステム２０２内において処理ノード１２Ａ〜１２Ｄからの要求に代わって起動してもよく、当該コヒーレントファブリックまたはコンピュータシステム内の他のホストブリッジを標的としているＩ／Ｏノード２０４Ａ〜２０４Ｃにより起動されるトランザクションを取扱ってもよい。したがって、Ｉ／Ｏノード２０４Ａ〜２０４Ｃにより送られるパケットはホストブリッジ２０２に向かってデージーチェーン接続を介して流れてもよい（「上流に」流れる）。ホストブリッジ２０２により送られるパケットは受信側Ｉ／Ｏノード２０４Ａ〜２０４Ｎの方向に流れてもよい（「下流に」流れる）。Ｉ／Ｏノードとホストブリッジとをデージーチェーンで相互接続しＩ／Ｏノードが（トランザクションレベルにおいて）ホストブリッジとのみ通信することにより、Ｉ／Ｏノードが他のノードではなくホストブリッジに直接接続されるように見えるＩ／Ｏサブシステム２００のロジック的な眺めが与えられる。
【０１０４】
Ｉ／Ｏサブシステム２００はホストブリッジに対しデージーチェーン相互接続の両端で接続されることによりリンク欠陥の場合における堅牢性を可能にするかまたは共有されるＩ／Ｏサブシステムを処理ノードのクラスタ間にて可能にしてもよい。１つのブリッジはマスタブリッジとして定義され、他のブリッジはスレーブブリッジとして規定されるであろう。リンク欠陥がない場合、サブシステム内におけるすべてのＩ／Ｏノードはマスタブリッジに属してもよい。リンク欠陥の検出で、その欠陥の両側のノードは再プログラミングされることによりホストブリッジに対しその欠陥の同じ側で属し、それによって、２つの異なるサブシステムを形成し処理ノードとの通信を維持する。Ｉ／Ｏノードを、２つのホストブリッジ間において、欠陥がない状態で分配する（２つのロジック的に別々のチェーンを形成する）ことにより、トラフィックも同様にバランスをとってもよい。
【０１０５】
パケットがデージーチェーンの端部（たとえば図１９の例においてはＩ／Ｏノード２０４Ｃ）に到達しＩ／Ｏノード２０４Ａ〜２０４Ｃのいずれもそのパケットを受入れない場合、エラーをそのチェーンの端部にあるノードによって発生してもよい。
【０１０６】
一般に、Ｉ／Ｏサブシステム２００はリンクを非コヒーレント相互接続として実現してもよい。その非コヒーレントリンクにおけるデータパケット定義は図６に示され記載されるものと同様であってもよく、その非コヒーレントリンクにおける情報パケット定義は図３および図１８において（Probeフィールドが予約される状態で）示されるパケット定義と同様であってもよい。コマンドおよび応答パケットは下に図２１および図２２において示される。
【０１０７】
バーチャルチャネルに関し、非コヒーレントリンクは上記のコヒーレントリンクと同じバーチャルチャネルを用いてもよい。しかしながら、プローブは非コヒーレントリンクにおいては用いられないので、プローブバーチャルチャネルは取除かれてもよい。図９に示される表４２は非コヒーレントリンクの一実施例に対して定義されるバーチャルチャネルを示す。
【０１０８】
ホストノード２０２は処理ノード１２から分離して示されているが、ホストノード２０２は所望される場合には処理ノードに統合されてもよいことに注目されたい。
【０１０９】
次に図２０を参照して、テーブル２１０はコンピュータシステム１０内における非コヒーレントリンクの一例示的実施例に従って用いられるパケットを示す。他の実施例も可能であり意図され、任意の他の好適な組のパケットおよびコマンドフィールドエンコーディングを含む。テーブル２１０は、各コマンドに割当てられるコマンドエンコーディングを示すコマンドコードコラムと、非コヒーレントパケットが属するバーチャルチャネルを定義するバーチャルチャネル（Vchan）コラムと、コマンドを名づけるコマンドコラムと、コマンドパケット３０、２１２および２１４のうちどれがそのコマンドに対して用いられるかを示すパケットタイプコラムとを含む。
【０１１０】
Nop、WrSized、ReadSized、RdResponse、TgtDone、Broadcast、およびSyncパケットは、図７に関して記載された対応のコヒーレントパケットと同様であってもよい。しかしながら、非コヒーレントリンクでは、プローブパケットもプローブ応答パケットも出されない。
【０１１１】
AssignおよびAssignAckパケットを用いてUnit IDをノードに割当てる。マスタホストブリッジはパケットを各ノードに（一度に１つ）割当て、最後に用いられたUnit IDを示す。受信ノードは、そのノードによって必要とされるUnit IDの数を、最後に用いられたUnit ID＋１から開始して割当てる。受信ノードは、割当てられたUnit IDの数を示すＩＤカウントを含んで、AssignAckパケットを戻す。
【０１１２】
次に図２１を参照して、非コヒーレントリンクにおいて用いられてもよいコマンドパケット２１２の一実施例のブロック図を示す。コマンドパケット２１２はコヒーレントパケットと同様なコマンドフィールドを含む。加えて、随意のソースタグフィールドを、コヒーレントコマンドパケットと同様に、ビット時間３において含んでもよい（SrcTag）。アドレスはビット時間５−８（および最下位アドレスビットに対しては随意にビット時間４）に含まれる。しかしながら、ソースノードの代わりに、ユニットＩＤが与えられる。
【０１１３】
ユニットＩＤはパケットを同じロジックソースから来るものとして認識するよう働く（ユニットＩＤが等しい場合）。しかしながら、Ｉ／Ｏノードは複数のユニットＩＤを有してもよい（たとえばノードがロジック的に分離している複数のデバイスまたは機能を含む場合）。したがって、ノードは１つを超えるユニットＩＤを有するパケットを受入れてもよい。加えて、パケットはホストブリッジとノードとの間を流れるので、パケットに関与するノードの１つ（ホストブリッジノード）が当該パケットに対して暗示される。したがって、単一のユニットＩＤを非コヒーレントパケットにおいて用いてもよい。一実施例では、ユニットＩＤは５つのビットを含んでもよい。ユニットＩＤ０はホストブリッジに割当てられてもよく、ユニットＩＤ３１はエラーケースに対して用いられてもよい。したがって、３０までのユニットＩＤが１つのデージーチェーン内へ結合されるＩ／Ｏノードにおいて存在してもよい。
【０１１４】
加えて、コマンドパケット２１２はシーケンスＩＤフィールドをビット時間１および２に含む。このシーケンスＩＤフィールドを用いて同じユニットＩＤから２つ以上のコマンドパケットの組をグループ化しその組が順序づけられる旨を示してもよい。より特定的には、シーケンスＩＤフィールドが０である場合、パケットは順序づけられない。シーケンスＩＤフィールドが０でない場合、パケットは同じシーケンスＩＤフィールド値を有する他のパケットに関し順序づけられる。
【０１１５】
次に図２２を参照して、非コヒーレントリンクにおいて用いられてもよい応答パケット２１４の一実施例のブロック図が示される。応答パケット２１４は、コマンドフィールドと、ユニットＩＤフィールドと、コマンドパケット２１２に類似するソースタグフィールドとを含む。他のビットを所望のように含んでもよい。
【０１１６】
ここで図２３を参照して、Ｉ／Ｏノード２０４Ａの一実施例を示すブロック図が示される。他のＩ／Ｏノード２０４Ｂ〜２０４Ｃも同様に構成されてもよい。他の実施例も可能であり意図される。図２３の実施例では、Ｉ／Ｏノード２０４Ａは、インターフェイスロジック１８Ｍおよび１８Ｎと、パケットバッファの第１の組２２０と、パケットバッファの第２の組２２２と、ノードロジック２２４とを含む。インターフェイスロジック１８Ｍはライン２４Ｋおよび２４Ｌと、パケットバッファ２２０およびノードロジック２２４とに結合される。インターフェイスロジック１８Ｎは、パケットバッファ２２２およびノードロジック２２４と並んで、ライン２４Ｍおよび２４Ｎに結合される。ノードロジック２２４はさらにパケットバッファ２２２および２２４に結合される。
【０１１７】
インターフェイスロジック１８Ｍおよび１８Ｎはパケットをライン２４Ｌおよび２４Ｍから（それぞれ）受取りパケットをライン２４Ｋおよび２４Ｎで（それぞれ）送るよう構成される。上記においてコヒーレントリンクに対し記載されたインターフェイスロジックと同様に、インターフェイスロジック１８Ｍおよび１８Ｎは受取られたパケットを制御経路およびデータ経路に分離してもよい。制御経路は制御パケットバッファに結合され、データ経路はデータパケットバッファに結合される。代替的に、インターフェイスロジックは受取られたパケットを制御経路およびデータ経路に分離せず、ノードロジック２２４によって各ビット時間に対応するＣＤＬ信号を受取り分離を実行してもよい。コヒーレントインターフェイスと同様に、パケットバッファ２２０および２２２は、コマンドバッファ（ＣＢ）および応答バッファ（ＲＴ）を制御パケットに対して、非コヒーレントリンクにおいて実施される２つのバーチャルチャネルに対応して含む。加えて、データパケットバッファが各バーチャルチャネルに対して与えられる（つまりコマンドデータバッファ（ＣＤＢ）および応答データバッファ（ＲＤＢ））。
【０１１８】
ノードロジック２２４はバッファ２２２および２２４内に受取られたパケットを処理し、パケットをＩ／Ｏノード２０４Ａにより実現される周辺機能性に応答して起動してもよい。図１１に示される制御ロジック６６と同様に、ノードロジック２２４は制御パケットアクティブレジスタ２２６Ａおよび２２６Ｂ（パケットバッファ２２２および２２４にそれぞれ対応する）ならびにデータパケットアクティブレジスタ２２８Ａおよび２２８Ｂ（パケットバッファ２２２および２２４にそれぞれ対応する）を実現してもよい。加えて、非コヒーレントリンクはNode IDの代わりにUnit IDに従って動作するので、ノードロジック２２４は１つ以上のUnit IDレジスタ２３０Ａ〜２３０Ｎを含んでＩ／Ｏノード２０４Ａに割当てられるUnit IDを記憶してもよい。Unit IDレジスタ２３０Ａ〜２３０Ｎの数は、ノードよって、当該ノード内にて実現されるUnit IDの数に従って変動してもよい。
【０１１９】
異なるバーチャルチャネルにおけるパケットはＩ／Ｏノード２０４Ａ内の異なるバッファに記憶されるので、異なるバーチャルチャネルにおけるパケットは物理的には互いとコンフリクトしない。したがって、デッドロックのない動作が与えられてもよい。加えて、ノードロジック２２４は予め資源を割当てて資源パケットおよび応答データを取扱ってもよく（上述のとおり）、したがって応答パケットは１つのバーチャルチャネル内にマージされてもよい（上述のとおり）。ノードロジック２２４は、さらに、図１８に示されるパケットと同様のNopパケットの送受（予約されたプローブフィールドとともに）をフロー制御バッファ２２０および２２２（および他のノードにおける同様のバッファ）に対してパケットの送受に関し行なうよう構成されてもよい。
【０１２０】
ノードロジック２２４は、さらに、Ｉ／Ｏノード２０４Ａにより実行されるさまざまなＩ／Ｏまたは周辺機能に対応するロジックを含んでもよい。たとえば、Ｉ／Ｏノード２０４Ａは記憶周辺装置、たとえばディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤドライブなどを含んでもよい。Ｉ／Ｏノード２０４Ａは通信周辺装置、たとえばＩＥＥＥ １３９４、イーサネット（Ｒ）、ユニバーサル・シリアル・バス（ＵＳＢ）、周辺構成要素相互接続（ＰＣＩ）バス、モデムなどを含んでもよい。任意の好適なＩ／Ｏ機能をＩ／Ｏノード２０４Ａに含んでよい。
【０１２１】
ここで図２４を参照して、パケットを受信するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図される。示される実施例はパケットをバッファ２２０および２２２に一連のビット時間として受取る。他の実施例はパケットのビット時間をインターフェイスロジック１８Ｍ〜１８Ｎにおいて累積し、完全なパケットをバッファ２２０および２２２に与えてもよく、その場合には、ビット時間においてパケットの受取りを管理することに関連するステップは除いてもよい。図２４に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内において用いながら実行されてもよい。図２４に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎごとに実行されてもよく、なぜならば、ビット時間は同時に各インターフェイスロジックから受取られてもよいからである。ステップ１００〜１１２は上記の図１４の対応して記載されたステップと同様であってもよい。
【０１２２】
次に図２５を参照して、コマンドパケットを処理するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２５に示されるステップは理解を容易にするためある特定の順序で示されるが、任意の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行されてもよい。図２５に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎごとおよび／または各コマンドパケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。代替的に、１つのコマンドパケット（またはインターフェイスロジック１８Ｍ〜１８Ｎにつき１つのコマンドパケット）を、処理のために、好適な公平性アルゴリズムに従って選択してもよい。一般に、１つのバーチャルチャネルから処理のために選択されるパケットはバーチャルチャネル内におけるパケットに対する順序付け規則に従う（たとえば同じソースから同じデスティネーションへのパケットは順序よく選択される）が、パケットの、処理に対する選択は、所望されかつ順序付け規則が許す場合には、順序が乱れた状態でなされてもよい。
【０１２３】
ステップ１２６は一般に図１５の対応のステップと同様であってもよい（が、ユニットＩＤおよびユニットＩＤレジスタ２３０Ａ〜２３０Ｎに基づく）。加えて、ノードロジック２２４はパケットをパケット経路制御テーブルに従ってではなく同じ方向（上流または下流）において送るよう構成される（ステップ２４２）。パケットがこのノードを標的としている場合、ノードロジック２２４はそのパケットを受入れ（パケットを下流のフローから取除く）、それを処理する（ステップ２４０）。一旦コマンドパケットが処理される（送られるかまたはこのノードによって受入れられる）と、そのコマンドパケットはコマンドバッファエントリから取除かれ（適用可能である場合にはデータパケットはデータバッファエントリから取除かれ）ることに注目されたい。
【０１２４】
選択されたコマンドパケットが対応するデータパケットを特定する場合には、さまざまな実施例によるコマンドパケットの処理をたとえそのデータパケットがまだ受取られていなくても行なってもよく、またはデータパケットの到着を待つことによりデータを送ることを単純化するかまたは完全なデータパケットを特定する他の制御パケットが同じリンク上において送られるようにしてもよい。データパケットがコマンドパケットの処理時に受取られていない場合、そのデータパケットは、上述のように、それが受取られるときに処理されてもよい。
【０１２５】
次に図２６を参照して、応答パケットを処理するためのノードロジック２２４の一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２６に示されるステップは理解を容易にするためある特定の順序で示されるが、他の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行されてもよい。図２６に示されるステップは並列かつ独立して各インターフェイスロジック１８Ｍ〜１８Ｎおよび／または各応答パケットバッファごとに実行されてもよく、なぜならば、異なるインターフェイスおよび／または異なるバーチャルチャネルからのコマンドパケットは物理的に独立しているからである。ステップ１１４は図１６の対応するステップと同様であってもよい（が、ノードロジック２２４に対してはユニットＩＤおよびユニットＩＤレジスタ２３０Ａ〜２３０Ｎに基づく）。
【０１２６】
デスティネーションノードが別のノードである場合、応答バーチャルチャネルに対する空いているバッファエントリが受信機において応答パケットが送られるリンク上にあるならば、ノードロジック２２４は応答パケット（および適用可能である場合には対応のデータパケット）を送る（ステップ２５０）。この受信機は応答パケットをそのパケットが既に流れているのと同じ方向（上流または下流）において流れさせるノードである。
【０１２７】
応答パケットのデスティネーションノードがこのノードである場合、ノードロジック２２４は、もし対応のデータパケットがあれば、それを、対応の応答データバッファから、その応答が割当てられるデータバッファへ移動させるよう構成される（ステップ２５２）。換言すれば、ノードロジック２２４はそのデータを消費する。ノードロジック２２４は次いで対応のコマンドを完了し、データバッファの割当てを解除する（ステップ２５４）。一旦応答パケットが処理される（送られるかまたはこのノードによって受入れられる）と、その応答パケットは応答バッファエントリから取除かれ（適用可能である場合にはデータパケットはデータバッファエントリから取除かれ）ることに注目されたい。
【０１２８】
選択された応答パケットが対応するデータパケットを特定する場合には、さまざまな実施例によるその応答パケットの処理がたとえそのデータパケットがまだ受取られていなくとも行なってもよく、またはそのデータパケットの到着を待つことによりそのデータを送ることを単純化するかまたは完全なデータパケットを特定する別の制御パケットが同じリンク上において送られるようにしてもよい。データパケットが応答パケットの処理時に受取られていない場合、データパケットは、上述のように、そのデータパケットが受取られるときに扱ってもよい。
【０１２９】
次に図２７を参照して、ノードが結合されるリンク上においてパケットを起動するためのノードロジックの一実施例の動作を示すフローチャートを示す。他の実施例も可能であり意図されてよい。図２７に示されるステップは理解を容易にするためある特定の順序で示されるが、他の好適な順序を用いてよい。加えて、ステップは、並列に、組合せロジックをノードロジック２２４内にて用いながら実行してもよい。
【０１３０】
ノードロジック２２４は、開始されるべきトランザクションの結果、データがこのノードに戻されるかどうかを判断する（判断ブロック２６０）。たとえば、ノードにより開始される読出トランザクションはデータをノードに戻し、一方、ノードにより開始される書込トランザクションはデータをノードに戻さない。トランザクションの結果、データがこのノードに戻される場合、ノードロジック２２４はデータバッファを割当てて、戻されたデータを記憶する（ステップ２６２）。この後、ノードロジック２２４はパケットを送る（ステップ１６４）。
【０１３１】
産業上の利用可能性
この発明はコンピュータシステムにおいて適用可能であってよい。
【図面の簡単な説明】
【図１】 コンピュータシステムの一実施例のブロック図である。
【図２】 図１に示される２つのノードの、間のリンクの一実施例が強調される、一実施例のブロック図である。
【図３】 情報パケットの一実施例を示すブロック図である。
【図４】 コヒーレントリンクのためのコマンドパケットの一実施例を示すブロック図である。
【図５】 コヒーレントリンクのための応答パケットの一実施例を示すブロック図である。
【図６】 データパケットの一実施例を示すブロック図である。
【図７】 コヒーレントリンクのためのパケット定義の一実施例を示すテーブルである。
【図８】 バーチャルチャネルの対を示すブロック図である。
【図９】 バーチャルチャネルの組の一実施例を示すテーブルである。
【図１０】 図１に示される処理ノードの一実施例のブロック図である。
【図１１】 図１０に示されるパケット処理ロジックの一実施例のブロック図である。
【図１２】 データバッファプールエントリの一実施例を示すブロック図である。
【図１３】 応答カウンタプールエントリの一実施例を示すブロック図である。
【図１４】 パケット受信のために図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１５】 コマンドパケットを処理するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１６】 応答パケットを処理するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１７】 パケットを起動するための図１０に示されるパケット処理ロジックの一実施例の動作を示すフローチャートである。
【図１８】 バッファ空きフィールドを含む情報パケットの一実施例を示すブロック図である。
【図１９】 図１および図２に示される相互接続に類似したリンクを介して相互接続されるホストブリッジおよび複数のＩ／Ｏノードを含むＩ／Ｏサブシステムの一実施例のブロック図である。
【図２０】 非コヒーレントリンクのパケット定義の一実施例を示すテーブルである。
【図２１】 非コヒーレントリンクのためのコマンドパケットの一実施例のブロック図である。
【図２２】 非コヒーレントリンクのための応答パケットの一実施例のブロック図である。
【図２３】 Ｉ／Ｏノードの一実施例のブロック図である。
【図２４】 パケット受信のための図２３に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２５】 コマンドパケットを処理するための図２４に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２６】 応答パケットを処理するための図２４に示されるノードロジックの一実施例の動作を示すフローチャートである。
【図２７】 パケットを起動するための図２７に示されるノードロジックの一実施例の動作を示すフローチャートである。
Claims (26)
- パケットをコンピュータシステムにおいて複数のノード間で経路づけるための方法であって、
第１の制御パケットを前記複数のノードのうち第１のノードにおいて受取ることを含み、前記第１のノードは複数の制御パケットバッファを含み、前記複数の制御パケットバッファの各々は複数のバーチャルチャネルのうち異なるバーチャルチャネルに割当てられ、前記第１のノードの複数のインターフェースロジックの各々に対して前記複数のバーチャルチャネルが割当てられ、前記方法はさらに、
前記複数のバーチャルチャネルのうち前記第１の制御パケットが属する第１のバーチャルチャネルを判断することと、
前記第１の制御パケットを前記複数の制御パケットバッファのうち第１の制御パケットバッファにおいて記憶することとを含み、前記第１の制御パケットバッファは前記第１のバーチャルチャネルに割当てられ、前記方法はさらに、
前記第１の制御パケットにより特定される第１のデータパケットを受取ることと、
前記第１のデータパケットを前記第１のノード内において複数のデータバッファのうち第１のデータバッファにおいて記憶することとを含み、前記第１のデータバッファは前記第１のバーチャルチャネルに割当てられ、前記複数のデータバッファの各々は、前記複数のバーチャルチャネルのうち、対応するデータパケットを特定する少なくとも１つの制御パケットを含む異なるバーチャルチャネルに割当てられる、方法。 - 第２の制御パケットを前記第１のノードにおいて受取ることと、
前記複数のバーチャルチャネルのうち前記第２の制御パケットが属する第２のバーチャルチャネルを判断することとを含み、前記第２のバーチャルチャネルは前記第１のバーチャルチャネルとは異なり、前記方法はさらに、
前記第２の制御パケットを前記複数の制御パケットバッファのうち第２の制御パケットバッファにおいて記憶することを含み、前記第２の制御パケットバッファは前記第２のバーチャルチャネルに割当てられる、請求項１に記載の方法。 - 前記第１の制御パケットを前記複数のノードのうち第３のノードに送信することをさらにを含み、前記第３のノードは第２の複数の制御パケットバッファを含み、前記第２の複数の制御パケットバッファの各々は前記複数のバーチャルチャネルのうち異なるバーチャルチャネルに割当てられ、前記送信は前記第２の複数の制御パケットバ
ッファのうち前記第１の制御パケットを記憶する空間を含む第３の制御パケットバッファに応答し、前記第３の制御パケットバッファは前記第１のバーチャルチャネルに割当てられ、前記方法はさらに、
前記第２の複数の制御パケットバッファのうち前記第２の制御パケットを記憶する空間を含む第４の制御パケットバッファに応答して前記第２の制御パケットを前記第３のノードに送信することを含み、前記第４の制御パケットバッファは前記第２のバーチャルチャネルに割当てられる、請求項２に記載の方法。。 - 前記判断することは、前記第１の制御パケットのコマンドフィールドをデコードすることを含む、請求項１に記載の方法。
- 前記判断することは、前記第１の制御パケットはポストされないコマンドバーチャルチャネルに属すると判断することを含む、請求項１に記載の方法。
- 前記判断することは、前記第１の制御パケットはプローブバーチャルチャネルに属すると判断することを含む、請求項１に記載の方法。
- 前記判断することは、前記第１の制御パケットは応答バーチャルチャネルに属すると判断することを含む、請求項１に記載の方法。
- 前記複数のバーチャルチャネルのうち少なくとも１つのバーチャルチャネルに含まれる各制御パケットはデータパケットを特定せず、前記複数のデータバッファのいずれも前記少なくとも１つのバーチャルチャネルに割当てられない、請求項１に記載の方法。
- 第１の制御パケットを送信するよう構成される第１のノードと、
前記第１の制御パケットを前記第１のノードから受信するよう結合される第２のノードとを含み、前記第２のノードは複数の制御パケットバッファを含み、前記複数の制御パケットバッファの各々は複数のバーチャルチャネルのうち異なるバーチャルチャネルに割当てられ、前記第２のノードの複数のインターフェースロジックの各々に対して前記複数のバーチャルチャネルが割当てられ、前記第２のノードは、前記複数のバーチャルチャネルのうち前記第１の制御パケットが属する第１のバーチャルチャネルに応答して前記複数の制御パケットバッファのうち第１の制御パケットバッファにおいて前記第１の制御パケットを記憶するよう構成され、前記第２のノードは複数のデータバッファをさらに含み、前記複数のデータバッファの各々は、前記複数のバーチャルチャネルのうち、対応するデータパケットを特定する少なくとも１つの制御パケットを含む、異なるバーチャルチャネルに割当てられ、前記第１のノードは前記第１の制御パケットにより特定される第１のデータパケットを送信するよう構成され、前記第２のノードは前記第１のデータパケットを前記複数のデータバッファのうち第１のデータバッファに記憶するよう構成され、前記第１のデータバッファは前記第１のバーチャルチャネルに割当てられる、コンピュータシステム。 - 前記第１のノードは前記複数のバーチャルチャネルのうち第２のバーチャルチャネルに属する第２の制御パケットを送信するよう構成され、前記第２のバーチャルチャネルは前記第１のバーチャルチャネルとは異なり、前記第２のノードは前記第２の制御パケットを前記複数の制御パケットバッファのうち第２の制御パケットバッファにおいて記憶するよう構成される、請求項９に記載のコンピュータシステム。
- 第２の複数の制御パケットバッファを含む第３のノードをさらに含み、前記第２の複数の制御パケットバッファの各々は前記複数のバーチャルチャネルのうち異なるバーチャルチャネルに割当てられ、前記第２のノードは前記第２の複数の制御パケットバッファのうち前記第１の制御パケットを記憶する空間を含む第３の制御パケットバッファに応答して前記第１の制御パケットを前記第３のノードに送信するよう構成され、前記第３の制御パケットバッファは前記第１のバーチャルチャネルに割当てられ、前記第２のノードは前記第２の複数の制御パケットバッファのうち前記第２の制御パケットを記憶する空間を含む第４の制御パケットバッファに応答して前記第２の制御パケットを前記第３のノードに送信するよう構成され、前記第４の制御パケットバッファは前記第１のバーチャルチャネルに割当てられる、請求項１０に記載のコンピュータシステム。
- 前記第２のノードが前記第１の制御パケットのデスティネーションである場合、前記第２のノードは前記第１の制御パケットを前記第１の制御パケットバッファから取除き前記第１の制御パケットに応答するよう構成される、請求項９に記載のコンピュータシステム。
- 前記第２のノードは、さらに、前記第１のデータパケットを前記第１のデータバッファから取除き前記第１のデータパケットを処理するよう構成される、請求項１２に記載のコンピュータシステム。
- 前記第２のノードはキャッシュおよびメモリコントローラを含み、前記第２のノードは前記第１の制御パケットに応答して前記第１のデータパケットを前記キャッシュおよび前記メモリコントローラのうちの１つに与えるよう構成される、請求項１３に記載のコンピュータシステム。
- パケットを前記第２のノードから受信するよう結合される第３のノードをさらに含み、前記第２のノードが前記第１の制御パケットのデスティネーションでない場合、前記第２のノードは前記第１の制御パケットを前記第１の制御パケットバッファから取除き前記第１の制御パケットを前記第３のノードへ送るよう構成される、請求項９に記載のコンピュータシステム。
- 前記第２のノードは前記第１のデータパケットを前記第１のデータバッファから取除き前記第１のデータパケットを前記第３のノードに送るようさらに構成される、請求項１４に記載のコンピュータシステム。
- 前記第２のノードは、前記第１の制御パケットが属する前記第１のバーチャルチャネルを、前記第１の制御パケットのコマンドフィールドをデコードすることにより判断するよう構成される、請求項９に記載のコンピュータシステム。
- 前記複数のバーチャルチャネルのうち少なくとも１つのバーチャルチャネルに含まれる各制御パケットはデータパケットを特定せず、前記複数のデータバッファのいずれも前記少なくとも１つのバーチャルチャネルに割当てられない、請求項９に記載のコンピュータシステム。
- 第１の制御パケットおよび前記第１の制御パケットにより特定される第１のデータパケットを受取るよう結合されるノードであって、
複数の制御パケットバッファを含み、前記複数の制御パケットバッファの各々は複数のバーチャルチャネルのうちの異なるバーチャルチャネルに割当てられ、前記ノードの複数のインターフェースロジックの各々に対して前記複数のバーチャルチャネルが割当てられ、前記ノードはさらに、
複数のデータバッファを含み、前記複数のデータバッファの各々は、前記複数のバーチャルチャネルのうち、対応するデータパケットを特定する少なくとも１つの制御パケットを含む、異なるバーチャルチャネルに割当てられ、前記ノードはさらに、
前記複数のバーチャルチャネルのうち前記第１の制御パケットが属する第１のバーチャルチャネルに応答して前記第１の制御パケットを前記複数の制御パケットバッファのうちの第１の制御パケットバッファに記憶するよう構成され、さらに、前記第１のデータパケットを前記複数のデータバッファのうちの第１のデータバッファに記憶するよう構成される回路系を含み、前記第１のデータバッファは前記第１のバーチャルチャネルに割当てられる、ノード。 - 前記ノードが前記第１の制御パケットのデスティネーションである場合、前記回路系は前記第１の制御パケットを前記第１の制御パケットバッファから取除くよう構成され、前記ノードは前記第１の制御パケットに応答するよう構成される、請求項１９に記載のノード。
- 前記回路系は、さらに、前記第１のデータパケットを前記第１のデータバッファから取除くよう構成され、前記ノードは前記第１のデータパケットを処理するよう構成される、請求項２０に記載のノード。
- キャッシュおよびメモリコントローラをさらに含み、前記ノードは前記第１の制御パケットに応答して前記第１のデータパケットを前記キャッシュおよび前記メモリコントローラのうちの１つに与えるよう構成される、請求項２１に記載のノード。
- 前記第２のノードが前記第１の制御パケットのデスティネーションでない場合、前記回路系は前記第１の制御パケットを前記第１の制御パケットバッファから取除き前記第１の制御パケットを別のノードへ送るよう構成される、請求項１９に記載のノード。
- 前記回路系は前記第１のデータパケットを前記第１のデータバッファから取除き前記第１のデータパケットを前記別のノードに送るようさらに構成される、請求項２３に記載のノード。
- 前記回路系は、前記第１の制御パケットが属する前記第１のバーチャルチャネルを、前記第１の制御パケットのコマンドフィールドをデコードすることにより判断するよう構成される、請求項１９に記載のノード。
- 前記複数のバーチャルチャネルのうち少なくとも１つのバーチャルチャネルに含まれる各制御パケットはデータパケットを特定せず、前記複数のデータバッファのいずれも前記少なくとも１つのバーチャルチャネルに割当てられない、請求項１９に記載のノード。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/399,281 US6938094B1 (en) | 1999-09-17 | 1999-09-17 | Virtual channels and corresponding buffer allocations for deadlock-free computer system operation |
| US09/399,281 | 1999-09-17 | ||
| PCT/US2000/012574 WO2001022247A1 (en) | 1999-09-17 | 2000-05-09 | Virtual channels and corresponding buffer allocations for deadlock-free computer system operation |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003510686A JP2003510686A (ja) | 2003-03-18 |
| JP2003510686A5 JP2003510686A5 (ja) | 2007-05-31 |
| JP4410967B2 true JP4410967B2 (ja) | 2010-02-10 |
Family
ID=23578934
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001525542A Expired - Lifetime JP4410967B2 (ja) | 1999-09-17 | 2000-05-09 | デッドロックのないコンピュータシステム動作のためのバーチャルチャネルおよび対応するバッファ割当て |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6938094B1 (ja) |
| EP (1) | EP1222558B1 (ja) |
| JP (1) | JP4410967B2 (ja) |
| KR (1) | KR100643873B1 (ja) |
| DE (1) | DE60003834T2 (ja) |
| WO (1) | WO2001022247A1 (ja) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7230917B1 (en) * | 2001-02-22 | 2007-06-12 | Cisco Technology, Inc. | Apparatus and technique for conveying per-channel flow control information to a forwarding engine of an intermediate network node |
| US9836424B2 (en) | 2001-08-24 | 2017-12-05 | Intel Corporation | General input/output architecture, protocol and related methods to implement flow control |
| WO2003019394A1 (en) | 2001-08-24 | 2003-03-06 | Intel Corporation | A general input/output architecture, protocol and related methods to support legacy interrupts |
| US7979573B2 (en) * | 2002-05-15 | 2011-07-12 | Broadcom Corporation | Smart routing between peers in a point-to-point link based system |
| US7447872B2 (en) * | 2002-05-30 | 2008-11-04 | Cisco Technology, Inc. | Inter-chip processor control plane communication |
| US20040122973A1 (en) * | 2002-12-19 | 2004-06-24 | Advanced Micro Devices, Inc. | System and method for programming hyper transport routing tables on multiprocessor systems |
| JP4891521B2 (ja) | 2003-03-28 | 2012-03-07 | 三洋電機株式会社 | データ入出力方法、およびその方法を利用可能な記憶装置およびホスト装置 |
| US7386626B2 (en) * | 2003-06-23 | 2008-06-10 | Newisys, Inc. | Bandwidth, framing and error detection in communications between multi-processor clusters of multi-cluster computer systems |
| US7395347B2 (en) * | 2003-08-05 | 2008-07-01 | Newisys, Inc, | Communication between and within multi-processor clusters of multi-cluster computer systems |
| US7949782B2 (en) * | 2003-11-06 | 2011-05-24 | Qualcomm Incorporated | Extended link monitoring channel for 10 Gb/s Ethernet |
| US7793067B2 (en) * | 2005-08-12 | 2010-09-07 | Globalfoundries Inc. | Translation data prefetch in an IOMMU |
| US7480784B2 (en) | 2005-08-12 | 2009-01-20 | Advanced Micro Devices, Inc. | Ensuring deadlock free operation for peer to peer traffic in an input/output memory management unit (IOMMU) |
| US7516247B2 (en) | 2005-08-12 | 2009-04-07 | Advanced Micro Devices, Inc. | Avoiding silent data corruption and data leakage in a virtual environment with multiple guests |
| US7543131B2 (en) | 2005-08-12 | 2009-06-02 | Advanced Micro Devices, Inc. | Controlling an I/O MMU |
| US9053072B2 (en) * | 2007-01-25 | 2015-06-09 | Hewlett-Packard Development Company, L.P. | End node transactions at threshold-partial fullness of storage space |
| US7809006B2 (en) * | 2007-08-16 | 2010-10-05 | D. E. Shaw Research, Llc | Routing with virtual channels |
| JP5119882B2 (ja) * | 2007-11-21 | 2013-01-16 | 富士通株式会社 | メモリクロック設定機能を有する情報処理装置およびメモリクロック設定方法 |
| US7562168B1 (en) | 2008-05-29 | 2009-07-14 | International Business Machines Corporation | Method of optimizing buffer usage of virtual channels of a physical communication link and apparatuses for performing the same |
| JP5195933B2 (ja) * | 2009-01-30 | 2013-05-15 | 富士通株式会社 | 情報処理システム、情報処理装置、情報処理装置の制御方法、情報処理装置の制御プログラム及びコンピュータ読み取り可能な記録媒体 |
| JP5696779B2 (ja) * | 2011-03-22 | 2015-04-08 | 富士通株式会社 | 並列計算機システム及び並列計算機システムの制御方法 |
| US8631212B2 (en) | 2011-09-25 | 2014-01-14 | Advanced Micro Devices, Inc. | Input/output memory management unit with protection mode for preventing memory access by I/O devices |
| US9007962B2 (en) | 2013-01-24 | 2015-04-14 | International Business Machines Corporation | Deadlock-free routing using edge-disjoint sub-networks |
| US9552045B2 (en) | 2014-03-20 | 2017-01-24 | Intel Corporation | Method, apparatus, and system for controlling power consumption of unused hardware of a link interface |
| US20160188519A1 (en) * | 2014-12-27 | 2016-06-30 | Intel Corporation | Method, apparatus, system for embedded stream lanes in a high-performance interconnect |
| US10075383B2 (en) | 2016-03-30 | 2018-09-11 | Advanced Micro Devices, Inc. | Self-timed router with virtual channel control |
| US11238041B2 (en) | 2020-03-25 | 2022-02-01 | Ocient Holdings LLC | Facilitating query executions via dynamic data block routing |
Family Cites Families (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4905231A (en) | 1988-05-03 | 1990-02-27 | American Telephone And Telegraph Company, At&T Bell Laboratories | Multi-media virtual circuit |
| GB8915136D0 (en) | 1989-06-30 | 1989-08-23 | Inmos Ltd | Method for controlling communication between computers |
| JPH06509896A (ja) | 1992-05-12 | 1994-11-02 | セイコーエプソン株式会社 | スケーラブル・コプロセッサ |
| US5533198A (en) | 1992-11-30 | 1996-07-02 | Cray Research, Inc. | Direction order priority routing of packets between nodes in a networked system |
| US6157967A (en) | 1992-12-17 | 2000-12-05 | Tandem Computer Incorporated | Method of data communication flow control in a data processing system using busy/ready commands |
| KR100304063B1 (ko) | 1993-08-04 | 2001-11-22 | 썬 마이크로시스템즈, 인코포레이티드 | 2지점간상호접속통신유틸리티 |
| US5583990A (en) | 1993-12-10 | 1996-12-10 | Cray Research, Inc. | System for allocating messages between virtual channels to avoid deadlock and to optimize the amount of message traffic on each type of virtual channel |
| US5613129A (en) | 1994-05-02 | 1997-03-18 | Digital Equipment Corporation | Adaptive mechanism for efficient interrupt processing |
| FI98774C (fi) * | 1994-05-24 | 1997-08-11 | Nokia Telecommunications Oy | Menetelmä ja laitteisto liikenteen priorisoimiseksi ATM-verkossa |
| JPH08185380A (ja) * | 1994-12-28 | 1996-07-16 | Hitachi Ltd | 並列計算機 |
| US5659796A (en) * | 1995-04-13 | 1997-08-19 | Cray Research, Inc. | System for randomly modifying virtual channel allocation and accepting the random modification based on the cost function |
| US6088736A (en) | 1995-07-19 | 2000-07-11 | Fujitsu Network Communications, Inc. | Joint flow control mechanism in a telecommunications network |
| GB2304210B (en) * | 1995-08-11 | 2000-02-16 | Fujitsu Ltd | Data receiving devices |
| US6055618A (en) | 1995-10-31 | 2000-04-25 | Cray Research, Inc. | Virtual maintenance network in multiprocessing system having a non-flow controlled virtual maintenance channel |
| US6094431A (en) * | 1995-11-30 | 2000-07-25 | Kabushiki Kaisha Toshiba | Node device and network resource reservation method for data packet transfer using ATM networks |
| US5848068A (en) | 1996-03-07 | 1998-12-08 | Lsi Logic Corporation | ATM communication system interconnect/termination unit |
| US5748900A (en) | 1996-03-13 | 1998-05-05 | Cray Research, Inc. | Adaptive congestion control mechanism for modular computer networks |
| JPH09293015A (ja) | 1996-04-24 | 1997-11-11 | Mitsubishi Electric Corp | メモリシステムおよびそれに用いられる半導体記憶装置 |
| US5892970A (en) | 1996-07-01 | 1999-04-06 | Sun Microsystems, Inc. | Multiprocessing system configured to perform efficient block copy operations |
| US5749095A (en) | 1996-07-01 | 1998-05-05 | Sun Microsystems, Inc. | Multiprocessing system configured to perform efficient write operations |
| US5881316A (en) | 1996-11-12 | 1999-03-09 | Hewlett-Packard Company | Dynamic allocation of queue space using counters |
| US5996013A (en) * | 1997-04-30 | 1999-11-30 | International Business Machines Corporation | Method and apparatus for resource allocation with guarantees |
| US6122700A (en) | 1997-06-26 | 2000-09-19 | Ncr Corporation | Apparatus and method for reducing interrupt density in computer systems by storing one or more interrupt events received at a first device in a memory and issuing an interrupt upon occurrence of a first predefined event |
| US6005851A (en) * | 1997-10-10 | 1999-12-21 | Nortel Networks Corporation | Adaptive channel control for data service delivery |
| US6014690A (en) * | 1997-10-24 | 2000-01-11 | Digital Equipment Corporation | Employing multiple channels for deadlock avoidance in a cache coherency protocol |
| US6094686A (en) * | 1997-10-24 | 2000-07-25 | Compaq Computer Corporation | Multi-processor system for transferring data without incurring deadlock using hierarchical virtual channels |
| US6101420A (en) * | 1997-10-24 | 2000-08-08 | Compaq Computer Corporation | Method and apparatus for disambiguating change-to-dirty commands in a switch based multi-processing system with coarse directories |
| US6279084B1 (en) | 1997-10-24 | 2001-08-21 | Compaq Computer Corporation | Shadow commands to optimize sequencing of requests in a switch-based multi-processor system |
| GB9809183D0 (en) | 1998-04-29 | 1998-07-01 | Sgs Thomson Microelectronics | Microcomputer with interrupt packets |
| US6370621B1 (en) | 1998-12-21 | 2002-04-09 | Advanced Micro Devices, Inc. | Memory cancel response optionally cancelling memory controller's providing of data in response to a read operation |
| US6205508B1 (en) | 1999-02-16 | 2001-03-20 | Advanced Micro Devices, Inc. | Method for distributing interrupts in a multi-processor system |
| US6449267B1 (en) * | 1999-02-24 | 2002-09-10 | Hughes Electronics Corporation | Method and apparatus for medium access control from integrated services packet-switched satellite networks |
| US6370600B1 (en) | 1999-05-25 | 2002-04-09 | Advanced Micro Devices, Inc. | Staging buffer for translating clock domains when source clock frequency exceeds target clock frequency |
| US6389526B1 (en) | 1999-08-24 | 2002-05-14 | Advanced Micro Devices, Inc. | Circuit and method for selectively stalling interrupt requests initiated by devices coupled to a multiprocessor system |
| US6484220B1 (en) | 1999-08-26 | 2002-11-19 | International Business Machines Corporation | Transfer of data between processors in a multi-processor system |
| GB2360168B (en) | 2000-03-11 | 2003-07-16 | 3Com Corp | Network switch including hysteresis in signalling fullness of transmit queues |
| US6715055B1 (en) | 2001-10-15 | 2004-03-30 | Advanced Micro Devices, Inc. | Apparatus and method for allocating buffer space |
-
1999
- 1999-09-17 US US09/399,281 patent/US6938094B1/en not_active Expired - Lifetime
-
2000
- 2000-05-09 EP EP00932185A patent/EP1222558B1/en not_active Expired - Lifetime
- 2000-05-09 JP JP2001525542A patent/JP4410967B2/ja not_active Expired - Lifetime
- 2000-05-09 DE DE60003834T patent/DE60003834T2/de not_active Expired - Lifetime
- 2000-05-09 KR KR1020027003545A patent/KR100643873B1/ko active IP Right Grant
- 2000-05-09 WO PCT/US2000/012574 patent/WO2001022247A1/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| US6938094B1 (en) | 2005-08-30 |
| DE60003834T2 (de) | 2004-05-13 |
| KR20020030825A (ko) | 2002-04-25 |
| WO2001022247A1 (en) | 2001-03-29 |
| EP1222558B1 (en) | 2003-07-09 |
| KR100643873B1 (ko) | 2006-11-10 |
| DE60003834D1 (de) | 2003-08-14 |
| JP2003510686A (ja) | 2003-03-18 |
| EP1222558A1 (en) | 2002-07-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4410967B2 (ja) | デッドロックのないコンピュータシステム動作のためのバーチャルチャネルおよび対応するバッファ割当て | |
| US6950438B1 (en) | System and method for implementing a separate virtual channel for posted requests in a multiprocessor computer system | |
| JP4700773B2 (ja) | スイッチをベースとするマルチプロセッサシステムに使用するための順序サポート機構 | |
| US6888843B2 (en) | Response virtual channel for handling all responses | |
| US6279084B1 (en) | Shadow commands to optimize sequencing of requests in a switch-based multi-processor system | |
| US7069361B2 (en) | System and method of maintaining coherency in a distributed communication system | |
| US6948035B2 (en) | Data pend mechanism | |
| US7269695B2 (en) | Ambiguous virtual channels | |
| US6085276A (en) | Multi-processor computer system having a data switch with simultaneous insertion buffers for eliminating arbitration interdependencies | |
| US6249520B1 (en) | High-performance non-blocking switch with multiple channel ordering constraints | |
| US6154816A (en) | Low occupancy protocol for managing concurrent transactions with dependencies | |
| US6014690A (en) | Employing multiple channels for deadlock avoidance in a cache coherency protocol | |
| US6101420A (en) | Method and apparatus for disambiguating change-to-dirty commands in a switch based multi-processing system with coarse directories | |
| US6108752A (en) | Method and apparatus for delaying victim writes in a switch-based multi-processor system to maintain data coherency | |
| US7620694B2 (en) | Early issue of transaction ID | |
| US6529990B1 (en) | Method and apparatus to eliminate failed snoops of transactions caused by bus timing conflicts in a distributed symmetric multiprocessor system | |
| JP4906226B2 (ja) | マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 | |
| US6714994B1 (en) | Host bridge translating non-coherent packets from non-coherent link to coherent packets on conherent link and vice versa | |
| US11449489B2 (en) | Split transaction coherency protocol in a data processing system | |
| US10642760B2 (en) | Techniques for command arbitation in symmetric multiprocessor systems | |
| EP1363188B1 (en) | Load-linked/store conditional mechanism in a cc-numa (cache-coherent nonuniform memory access) system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070405 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070405 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080829 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080902 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081128 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091104 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091116 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4410967 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121120 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131120 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |