JP2004506986A - マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 - Google Patents
マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 Download PDFInfo
- Publication number
- JP2004506986A JP2004506986A JP2002520472A JP2002520472A JP2004506986A JP 2004506986 A JP2004506986 A JP 2004506986A JP 2002520472 A JP2002520472 A JP 2002520472A JP 2002520472 A JP2002520472 A JP 2002520472A JP 2004506986 A JP2004506986 A JP 2004506986A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- node
- posted
- packets
- response
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4265—Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
【技術分野】
この発明はコンピュータシステムの分野に関し、より特定的には、マルチプロセッサコンピュータシステムにおけるノード間のデータルーティングに関する。
【0002】
【発明の背景】
一般的に、パーソナルコンピュータ(PC)および他のタイプのコンピュータシステムは、メモリにアクセスするための共有バスシステムの付近に設計されてきた。1つ以上のプロセッサおよび1つ以上の入力/出力(I/O)デバイスは、共有バスを介してメモリに結合される。I/Oデバイスは、共有バスとI/Oデバイスとの間の情報の転送を管理するI/Oブリッジを介して共有バスに結合されてもよく、一方、プロセッサは、典型的に、共有バスに直接に結合されるかまたは、キャッシュ階層を介して共有バスに結合される。
【0003】
残念ながら、共有バスシステムにはいくつか欠点がある。たとえば、共有バスに取付けられる複数のデバイスは、バス上の信号を駆動するデバイスに対し、比較的大きな電気キャパシタンスを与える。さらに、共有バス上の複数の取付け点は高い信号周波数での信号反射を生じ、これは信号の完全性を低減してしまう。その結果、信号の完全性を受容可能なレベルに維持するため、バス上の信号周波数を比較的低く保つのが一般的である。比較的低い信号周波数は信号帯域幅を低減し、バスに取付けられるデバイスの性能を限定してしまう。
【0004】
より多数のデバイスへのスケーラビリティのなさが共有バスシステムのもう1つの欠点である。共有バスの利用可能な帯域幅は実質的に固定されている(さらなるデバイスを加えることでバス上の信号周波数が低減されれば、小さくなり得る)。(直接または間接に)バスに取付けられるデバイスの帯域幅必要量が一旦バスの利用可能帯域幅を超えると、バスへのアクセスを試みたときにデバイスがしばしばストールし、共有バスを含むコンピュータシステムの全体的な性能が低くなってしまう見込みが非常に高くなる。
【0005】
一方、分散メモリシステムには上記欠点の多くがない。分散メモリシステムを備えたコンピュータシステムは複数のノードを含み、そのうち2つ以上は異なるメモリに結合される。ノードは任意の好適な配線によって互いに結合される。たとえば、各ノードは、専用線によって互いのノードに結合されてもよい。これに代えて、各ノードは固定数の他のノードに接続されてもよく、トランザクションは、第1のノードから、1つ以上の中間ノードを介して第1のノードが直接には接続されない第2のノードへルーティングされてもよい。コンピュータシステムのメモリアドレス空間は、各ノードにおいてメモリにわたって割当てられる。
【0006】
一般的に、「ノード」は、相互接続されるとトランザクションに加わることができるデバイスである。たとえば、相互接続はパケットベースであってもよく、トランザクションの一部としてパケットを送受信するようにノードを構成してもよい。一般的に、トランザクションとは一連のパケットである。「リクエスタ」または「ソース」ノードは、リクエストパケットを発行することにより、「ターゲット」ノードに向けられるトランザクションを開始する。トランザクションの一部である各パケットは、2つのノード間で個々のパケットの「デスティネーション」として指定された受信ノードに伝えられる。パケットが最終的にターゲットノードに達すると、ターゲットノードはパケットが運搬した情報を受入れ、その情報を内部で処理する。これに代えて、ソースノードとターゲットノードとの間の通信経路上に位置するノードは、リクエスタノードからターゲットノードにパケットを中継し得る。
【0007】
トランザクションの結果、オリジナルのリクエストパケットだけでなく、各々が特定のデスティネーションに向けられた、応答、プローブおよびブロードキャストなどの他のタイプのパケットも発行され得る。たとえば、オリジナルのリクエストパケットを受取ると、ターゲットノードは、処理システム中の他のノードにブロードキャストまたはプローブパケットを発行し得る。次に、これらのノードが応答を生成し得、これらがターゲットノードまたはリクエスタノードのいずれかに向けられ得る。ターゲットノードに向けられた場合、ターゲットノードは、リクエスタノードに応答を戻すことによって応答し得る。
【0008】
分散メモリシステムは、共有バスシステムにおける課題とは異なる設計上の課題を呈する。たとえば、共有バスシステムは、バスアービトレーションによってトランザクションの開始を統制する。したがって、公平なアービトレーションアルゴリズムにより、各バスに加わっているノードにトランザクションを開始する機会が与えられる。バス上でのトランザクションの順序は、(たとえば、コヒーレンシの目的のために)トランザクションが行なわれる順序を表わし得る。一方、分散システムでは、ノードは並行してトランザクションを開始し、相互接続を用いてトランザクションを他のノードに送信し得る。これらのトランザクションは、それらの間で論理的競合(たとえば、同じアドレスを含むトランザクションに対するコヒーレンシ競合)を有することがあり、かつ、リソース競合に遭遇することがある(たとえば、さまざまなノードでバッファ空間が利用不可能なことがある)。これは、トランザクションの開始を統制するための中央メカニズムを設けていないからである。したがって、情報がノード間をスムーズに伝播し続けることと、(トランザクション間での競合のためにトランザクションが完了しない)デッドロック状態を回避することとを確実にするのがより困難である。
【0009】
たとえば、「ポストされた(posted)」書込トランザクションと関連のパケットが、ポストされた書込トランザクションと関連のない他のトラフィックを通すことを許されない場合、周辺機器相互接続(PCI)I/Oシステムなどの公知のI/Oシステムにおいて、あるデッドロック状態が起こり得る。一般的に、ポストされた書込トランザクションは、リクエスタが書込リクエストおよび対応のデータを(たとえばソースインターフェイスを介して)送信したときに、リクエスタによって完了したとみなされるものであり、したがって、リクエスタで実質的に完了する。リクエスタは、ポストされた書込トランザクションをターゲットがいつ実際に完了したかに直接に気づかないため、ポストされた動作に対する順序付けのサポートをハードウェアにおいてより多く与える必要がある。したがって、リクエスタは、ポストされた書込トランザクションのパケットまたは複数のパケットがターゲットに移動する間に、さらなるリクエストを発行し得る。ただし、これは、当初のポストされたトランザクションが完了した後にそのようなさらなるリクエストが完了すると仮定した場合である。この仮定をサポートするには、十分なハードウェアが利用可能でなければならない。
【0010】
これに対し、「ノンポステッド(non−posted)」書込トランザクションは、ターゲット(たとえばターゲットインターフェイス)がノンポステッド書込トランザクションを完了するまでは、リクエスタによって完了したとみなされない。ターゲットは一般的に、ノンポステッド書込トランザクションが完了したときに、肯定応答(acknowledgement)をリクエスタに送信する。そのような肯定応答は相互接続帯域幅を消費し、リクエスタは肯定応答を受信しかつ勘案する(accounted for)必要がある。たとえば、リクエスタが、次のトランザクションが発行される前に以前のトランザクションが完了したことを知る必要がある場合、ノンポステッド書込トランザクションが発行され得る。
【0011】
分散メモリシステムを有するコンピュータシステムでは、他の保留中のメモリ動作に対して、I/Oノードから来ているメモリリクエスト(たとえば、読出および書込動作)を適切に順序付けてコンピュータシステム内のメモリコヒーレンシを保ち、I/Oシステムのいかなる順序付け要件も満たす必要があろう。たとえば、メモリ動作は、それらが生成された順に完了されてコンピュータシステム内のメモリコヒーレンシを保ちかつI/O順序付け要件を満たす必要があろう。したがって、ポストされたリクエストに対して別個の通信チャネルを設けるためのシステムおよび方法を実現するコンピュータシステムを有することが望ましい。そのようなシステムおよび方法は、(ハードウェアの観点で)装置を最小化して実現を容易にしながら、デッドロック状態を回避する。
【0012】
【発明の開示】
バーチャルチャネルを用い、そのバーチャルチャネルに異なるリソースを割振るためのシステムおよび方法を実現するコンピュータシステムが提示される。より特定的には、コンピュータシステムは、コンピュータシステム内のコヒーレントファブリックおよびノンコヒーレントファブリックを介してリクエストをルーティングするため、ノンポステッドコマンドバーチャルチャネルとは別個のポステッドコマンドバーチャルチャネルを設ける。ポステッドライト(posted write)はポステッドコマンドバーチャルチャネルに属し、その他のリクエストはノンポステッドコマンドバーチャルチャネルに属し得る。バーチャルチャネルはコンピュータシステム内に別個のリソースを設けるため、ポステッドライトは、同じソースからの他のリクエストと順序付けられないことが許され得る。有利には、コンピュータシステムは、ポステッドライトが以前のノンポステッドリクエストに対して順序付けられないことを必要とする、以前のI/Oシステム(たとえば、周辺機器相互接続バスまたはPCI)との互換性を維持し得、それにより、互換性がなければI/Oシステムで起こり得るあるデッドロックを回避する。有利には、ポステッドコマンドバーチャルチャネルを設けることにより、コンピュータシステムは所望の互換性を与えかつ、デッドロックのない動作を行ない得る。
【0013】
概して述べると、コンピュータシステムで複数のノード間でパケットをルーティングするための方法が企図される。ポストされたリクエストパケットは、複数のノードのうち第1のノードで受信される。第1のノードは複数のパケットバッファを含み、その各々は、複数のバーチャルチャネルのうち異なるものに割当てられる。ポストされたリクエストパケットは、複数のパケットバッファの1つであるポステッドコマンドバッファに記憶される。ポステッドコマンドバッファは、複数のバーチャルチャネルの1つであるポステッドコマンドバーチャルチャネル中のパケット専用である。
【0014】
さらに、第1のノードおよび第2のノードを含むコンピュータシステムが企図される。第1のノードは、ポストされたリクエストパケットを送信するように構成される。第2のノードは、ポストされたリクエストパケットを第1のノードから受信するように結合されて、ポステッドコマンドバッファを含む複数のパケットバッファを含む。複数のパケットバッファの各々は、ポステッドコマンドバッファが割当てられるポステッドコマンドバーチャルチャネルを含む複数のバーチャルチャネルの異なるものに割当てられる。第2のノードは、ポストされたリクエストパケットをポステッドコマンドバッファに記憶するように構成される。
【0015】
この発明のその他の目的および利点は、添付の図面を参照し、以下の詳細な説明を読むと明らかになるであろう。
【0016】
この発明は、さまざまな変形および代替的な形態が可能であるが、その特定の実施例が例示のみの目的のために図面に示され、本明細書に詳細に説明される。しかしながら、図面およびその詳細な説明は、開示される特定の形態にこの発明を限定することを意図するものではなく、反対に、添付の請求項が規定するような、この発明の精神および範囲内に入るすべての変形、均等物および代替物を含むことを意図することを理解されたい。
【0017】
【発明を実行するためのモード】
システム概要
図1を参照して、コンピュータシステム10の1つの実施例が示される。コンピュータシステム10の他の実施例が可能でありかつ企図される。図1の実施例では、コンピュータシステム10はいくつかの処理ノード12A、12B、12Cおよび12Dを含むが、用いる処理ノードの数はこれより多くてもまたは少なくてもよい。各処理ノードは、各々それぞれの処理ノード12A−12D内に含まれるメモリコントローラ16A−16Dを介してそれぞれのメモリ14A−14Dに結合される。コンピュータシステム10のメモリアドレス空間は、システム10が分散メモリシステムを有するようにメモリ14A−14Dにわたって割当てられる。さらに、処理ノード12A−12Dは、処理ノード12A−12D間で通信するのに用いるインターフェイスロジックを含む。たとえば、処理ノード12Aは、処理ノード12Bと通信するためのインターフェイスロジック18Aと、処理ノード12Cと通信するためのインターフェイスロジック18Bと、また別の処理ノード(図示せず)と通信するための第3のインターフェイスロジック18Cとを含む。同様に、処理ノード12Bはインターフェイスロジック18D、18E、18Fを含み;処理ノード12Cはインターフェイスロジック18G、18Hおよび18Iを含み;処理ノード12Dはインターフェイスロジック18J、18Kおよび18Lを含む。処理ノード12Dは、インターフェイスロジック18Lを介してI/Oブリッジ20と通信するように結合される。他の処理ノードは同じ態様で他のI/Oブリッジと通信し得る。I/Oブリッジ20はI/Oバス22に結合される。
【0018】
処理ノード12A−12Dは、プロセス間ノード通信のためにパケットベース2方向リンク24を実現する。この実施例では、2方向リンクは1方向線の組として実現される(たとえば、線24Aを用いて処理ノード12Aから処理ノード12Bへパケットを送信し、線24Bを用いて処理ノード12Bから処理ノード12Aにパケットを送信する)。図1に図示されるように、線24C−24Hの他の組を用いて他の処理ノード間でパケットを送信する。リンクはキャッシュコヒーレントな態様で動作して処理ノード(コヒーレントリンク)間で通信してもよくまたは、ノンコヒーレントな態様で動作して処理ノードとI/Oブリッジ(ノンコヒーレントリンク)との間で通信してもよい。さらに、I/Oデバイス間のデイジーチェーン構造としてノンコヒーレントリンクを実現してI/Oバス22と置き換えてもよい。コヒーレントリンクを介した2つ以上のノードの相互接続を「コヒーレントファブリック」と称し得る。同様に、ノンコヒーレントリンクを介した2つ以上のノードの相互接続を「ノンコヒーレントファブリック」と称し得る。1つの処理ノードから別の処理ノードに送信すべきパケットは1つ以上の中間ノードを通り得ることに留意されたい。たとえば、処理ノード12Aによって処理ノード12Dに送信されるパケットは、図1に示されるように、処理ノード12Bまたは処理ノード12Cのいずれかを通り得る。いずれの好適なルーティングアルゴリズムを用いてもよい。
【0019】
メモリ14A−14Dはいずれの好適なメモリデバイスを含んでもよい。たとえば、メモリ14A−14Dは、1つ以上のRAMBUS DRAM(RDRAM)、同期DRAM(SDRAM)、スタティックRAMなどを含み得る。述べられたように、コンピュータシステム10のアドレス空間はメモリ14A−14Dにわたって割当てられる。各処理ノード12A−12Dは、どのアドレスをどのメモリ14A−14Dにマッピングし、したがってどの処理ノード12A−12Dに向けて特定のアドレスに対するメモリリクエストをルーティングすべきかを判断するのに用いられるメモリマップを含み得る。1つの実施例では、コンピュータシステム10内のアドレスのコヒーレンシ点は、アドレスに対応するバイトを記憶するメモリに結合された特定のメモリコントローラ16A−16Dである。言い換えると、メモリコントローラ16A−16Dは、対応のメモリ14A−14Dへの各メモリアクセスがキャッシュコヒーレントな態様で起こるのを確実にする役割がある。メモリコントローラ16A−16Dは、メモリ14A−14Dにインターフェイスするための制御回路構成を含み得る。さらに、メモリコントローラ16A−16Dは、メモリリクエストを待ち行列に入れるためにリクエスト待ち行列を含み得る。
【0020】
一般的に、インターフェイスロジック18A−18Lは、2方向リンクからパケットを受取りかつ、送信すべきパケットをリンク上でバッファするためのバッファを含み得る。コンピュータシステム10は、パケットを送信するためのいかなる好適なフロー制御メカニズムを用いてもよい。たとえば、各ノード内のインターフェイスロジックは、通信リンクの他方端にある受信ノードのインターフェイスロジック内に各タイプのバッファの数のカウントを記憶し得る。パケットを記憶するための正しいタイプの空きバッファを受信ノードが有していない場合、送信ノードはパケットを送信しないであろう。(たとえば記憶されたパケットをルーティングすることにより)各バッファが受信ノード内で空いていれば、受信ノードは、バッファが空いていることを示すメッセージを送信ノードに送信する。そのようなメカニズムを「クーポンベース」システムと称し得る。
【0021】
次に図2を参照して、処理ノード12Aおよび12Bを図示するブロック図を示し、その間の2方向リンク24の例示的な実施例を図示する。通信リンク24の他の実施例が可能でありかつ企図される。図2の実施例では、2方向リンク24は1方向線24Aおよび1方向線24Bを含む。線24Aは、クロック信号線(CLK)24AA、制御信号線(CTL)24ABおよびコマンド/アドレス/データバス(CAD)24ACを含む。同様に、線24Bは、クロック信号線24BA、制御信号線24BBおよびコマンド/アドレス/データバス24BCを含む。
【0022】
クロック線は、制御線およびコマンド/アドレス/データバスのサンプル点を示すクロック信号を送信する。1つの特定の実施例では、データ/制御ビットは、クロック信号の各エッジ(すなわち立上がりエッジおよび立下がりエッジ)で送信される。したがって、クロックサイクルごとに線1本当り2データビットが送信され得る。本明細書中では、線1本当り1ビットを送信するのに用いる時間の量を「ビット時間」と称する。上述の実施例は1クロックサイクル当り2ビット時間を含む。パケットは2ビット時間またはそれ以上にわたって送信され得る。コマンド/アドレス/データバスの幅に依存して、複数のクロック線を用いてもよい。たとえば、32ビットコマンド/アドレス/データバスに対して4本のクロック線を用いてもよい。
【0023】
制御線は、コマンド/アドレス/データバス上を送信されるデータが制御情報のビット時間であるのかまたはデータのビット時間であるのかを示す。制御線はアサートされて制御情報のビット時間を示し、デアサートされてデータのビット時間を示す。ある制御情報はデータが後に続いていることを示す。データは対応の制御情報のすぐ後に続いてもよい。1つの実施例では、他の制御情報がデータの送信に割込んでもよい。そのような割込は、データ送信の間に多数のビット時間にわたって制御線をアサートし、制御線がアサートされている間に制御情報のビット時間を送信することによって行なわれ得る。データに割込む制御情報は、データが後に続いていることを示さないであろう。さらに、1つの実施例では、制御線は制御情報の送信の間にデアサートされてストールビット時間を示し得る。制御線のその後の再アサートは、制御情報が継続していることを示し得る。
【0024】
コマンド/アドレス/データバスは、データ/制御ビットを送信するための線の組を含む。1つの実施例では、コマンド/アドレス/データバスは8本、16本または32本の線を含み得る。各処理ノードまたはI/Oブリッジは、設計の選択に従って、サポートされる数の線のうちいずれのものを用いてもよい。他の実施例は、所望により、他のサイズのコマンド/アドレス/データバスをサポートし得る。
【0025】
1つの実施例に従うと、コマンド/アドレス/データバス線およびクロック線で差分シグナリング(differential signaling)を用い得る。これに代えて、線は、アクティブローデータ(すなわち、論理「1」が線上の低電圧として表わされ、論理「0」が高電圧として表わされる)またはアクティブハイデータ(論理「1」が線上の高電圧として表わされ、論理「0」が低電圧として表わされる)のいずれかを搬送してもよい。
【0026】
コンピュータシステム10内を送信されるパケットは、1つ以上の中間処理ノードを通り得る。たとえば、システム10内を処理ノード12Aによって処理ノード12Dに送信されるパケットは、処理ノード12Bまたは処理ノード12Cのいずれかを通り得る(図1を参照)。処理ノード12Aがコヒーレントパケットを処理ノード12Bに送信する場合、処理ノード12Bはパケットを受取り、次にそのパケットを処理ノード12Dに転送し得る。一方、処理ノード12Aがコヒーレントパケットを処理ノード12Cに送信する場合、処理ノード12Cはパケットを受取り、次にそのパケットを処理ノード12Dに転送し得る。システム10内でいずれの好適なパケットルーティングアルゴリズムを用いてもよい。コンピュータシステム10の他の実施例は、図1の実施例よりも多いまたは少ない数の処理ノード12を含んでもよい。
【0027】
システム10内で用いられるコヒーレントパケットは異なるフォーマットを有してもよく、異なるデータを含んでもよい。図3−図6は、処理サブシステム12内で用い得る例示的なコヒーレントパケットフォーマットを図示する。図3−図5は、例示的なコヒーレント情報、リクエストおよび応答パケットをそれぞれ図示し、図6は、例示的なコヒーレントデータパケットを図示する。情報(info)パケットは、フロー制御情報、エラーステータスなど、通信リンクの一般的動作に関する情報を搬送する。リクエストおよび応答パケットは、トランザクションに関する制御情報を搬送する。いくつかのリクエストおよび応答パケットは、データパケットが後に続いていることを明示する。データパケットは、トランザクションおよび対応のリクエストまたは応答パケットに関連のデータを搬送する。他の実施例は異なるパケットフォーマットを用いてもよい。
【0028】
図3−図6の例示的なパケットフォーマットは、連続した「ビット時間」の間に並行に送信される8ビットバイトのビット7−0の中身を示す。本明細書中では、パケットの各データ単位(たとえばバイト)を送信するのに用いる時間の量を「ビット時間」と称する。各ビット時間はCLK信号の周期の一部である。たとえば、CLK信号の単一の周期内で、CLK信号の立上がりエッジで第1のバイトを送信し、CLK信号の立下がりエッジで異なるバイトを送信し得る。この場合、ビット時間はCLK信号の周期の半分である。図面中で値を与えられていないビット時間は、所与のパケット用の予備であるかまたは、パケット特有の情報を送信するのに用いられ得る。点線で示されるフィールドは、あるタイプのパケットのすべてに含まれるとは限らないオプションのフィールドを示す。
【0029】
図3は、処理サブシステム12内で用い得る例示的なコヒーレント情報(info)パケット30の図である。情報パケット30は、8ビットコヒーレント通信リンク上の4ビット時間を含む。6ビットのコマンドフィールドCmd[5:0]は第1のビット時間(すなわちビット時間0)の間に送信される。図4および図5のリクエストおよび応答パケットは、ビット時間0の間の同じビット位置に同様のコマンドエンコーディングを含む。情報パケット30を用いて、メッセージがアドレスを含まないときに最も近い近隣処理ノード間でメッセージを送信し得る。情報パケットはファブリック内でルーティングされないため、レシーバノードでバッファリングを全く必要としないであろう。さらに、情報パケットを用いて、上述のクーポンベースフロー機構においてバッファの空きを示すメッセージを送信し得る。他のタイプの情報パケットは、図7に図示されるように、システム同期(Sync)パケットおよび非動作(NOP)パケットを含む。1つの実施例では、メッセージングプロトコルは、情報パケットがフロー制御されずかつ、常にそれらのデスティネーションノードで受入れられなければならないことを必要とし得る。
【0030】
図4は、処理サブシステム12内で用い得る例示的なコヒーレントリクエストパケット32の図である。リクエストパケット32は、8ビットのコヒーレント通信リンク上の8ビット時間を含む。リクエストパケット32を用いて、トランザクション(たとえば読出または書込トランザクション)を開始しかつ、トランザクションによって影響を受けるアドレスを搬送するそれらのリクエストのためにトランザクションを実行するプロセスでリクエストを送信し得る。一般的に、リクエストパケットは、デスティネーションノードが行なうべき動作を示す。
【0031】
リクエストのタイプを識別するコマンドフィールドCmd[5:0]のビットはビット時間0の間に送信される。ソースノード内のソースユニットを識別する値を含むソースユニットフィールドSrcUnit[1:0]のビットもビット時間0の間に送信される。コンピュータシステム10内のユニットのタイプは、メモリコントローラ、キャッシュ、プロセッサなどを含み得る。トランザクションを開始したノードを識別する値を含むソースノードフィールドSrcNode[2:0]のビットはビット時間1の間に送信される。デスティネーションノードを一意に識別する値を含むデスティネーションノードフィールドDestNode[2:0]のビットもビット時間1の間に送信され得、これを用いてパケットをデスティネーションノードにルーティングし得る。パケットを受取るべきデスティネーションノード内のデスティネーションユニットを識別する値を含むデスティネーションユニットフィールドDestUnit[1:0]のビットもビット時間1の間に送信され得る。
【0032】
多くのリクエストパケットは、ビット時間2にソースタグフィールドSrcTag[4:0]のビットを含み得、これは、ソースノードフィールドSrcNode[2:0]およびソースユニットフィールドSrcUnit[1:0]とともに、それ自身がその一部である特定のトランザクションにパケットを一意にリンクし得る。いくつかのリクエストでは、ビット時間3を用いて、トランザクションの影響を受けるメモリアドレスの最下位ビットを送信してもよい。ビット時間4−7を用いて、トランザクションの影響を受けるアドレスの最上位ビットを含むアドレスフィールドAddr[39:8]のビットを送信する。パケット32の未定義フィールドのうちいくつかをさまざまなリクエストパケットと用いてコマンド特有の情報を搬送してもよい。
【0033】
図5は、処理サブシステム12内で用い得る例示的なコヒーレント応答パケット34の図である。応答パケット34は、コマンドフィールドCmd[5:0]、デスティネーションノードフィールドDestNode[2:0]およびデスティネーションユニットフィールドDestUnit[1:0]を含む。デスティネーションノードフィールドDestNode[2:0]は、応答パケットのためのデスティネーションノードを識別する(これは、ある場合には、トランザクションのソースノードまたはターゲットノードであり得る)。デスティネーションユニットフィールドDestUnit[1:0]は、デスティネーションノード内のデスティネーションユニットを識別する。さまざまなタイプの応答パケットがさらなる情報を含み得る。たとえば、読出応答パケットは、後に続くデータパケットで与えられる読出データの量を示す。プローブ応答は、(ビット時間3でオプションの共有ビット「Sh」を用いて)プローブされたノードがリクエストされたキャッシュブロックのコピーを保持しているか否かを示し得る。
【0034】
一般的に、応答パケット34はトランザクションの実行の間の応答に用いられ、そのトランザクションの影響を受けるアドレスの送信を必要としない。さらに、応答パケット34を用いて肯定応答パケットを送信してトランザクションを終了させ得る。リクエストパケット32と同様に、応答パケット34は、(図5のオプションフィールドとして図示される)多くのタイプの応答のために、ソースノードフィールドSrcNode[2:0]、ソースユニットフィールドSrcUnit[1:0]およびソースタグフィールドSrcTag[4:0]を含み得る。
【0035】
図6は、処理サブシステム12内で用い得る例示的なコヒーレントデータパケット36の図である。図6のデータパケット36は、8ビットのコヒーレント通信リンク上の8ビット時間を含む。データパケット36は、転送されるデータ量に依存して、異なる数のビット時間を含み得る。たとえば、1つの実施例では、キャッシュブロックは、64バイト、すなわち8ビットリンク上の64ビット時間を含む。他の実施例は、所望により、キャッシュブロックを異なるサイズに規定してもよい。さらに、キャッシュ不可能な読出および書込のためにキャッシュブロックよりも小さいサイズでデータを送信してもよい。キャッシュブロックサイズよりも小さなデータを送信するためのデータパケットが用いるビット時間はより少ない。1つの実施例では、ノンキャッシュブロックサイズのデータパケットは、データ送信の前に数ビット時間のマスクビットを送信して、データバイトがデータパケット内で有効であることを示し得る。さらに、キャッシュブロックデータは、リクエストアドレスファーストの最下位ビットによってアドレス指定される8バイトのクワッドワードとして戻され、その後、残余のクワッドワードがインタリーブされて戻され得る。
【0036】
図3−図6は、8ビットのコヒーレント通信リンクのためのパケットを図示する。図3−図6の連続したビット時間を連結することによって16ビットおよび32ビットリンクのためのパケットを形成し得る。たとえば、16ビットリンク上のパケットのビット時間0は、8ビットリンク上のビット時間0および1の間に送信される情報を含み得る。同様に、32ビットリンク上のパケットのビット時間0は、8ビットリンク上のビット時間0−3の間に送信される情報を含み得る。
【0037】
以下の式1および2は、8ビットリンクからのビット時間に従う、16ビットリンクのビット時間0と32ビットリンクのビット時間1との形態を示す。
【0038】
BT016[15:0]=BT18[7:0]‖BT28[7:0] (1)
BT032[31:0]=BT38[7:0]‖BT28[7:0]‖BT18[7:0]‖BT08[7:0] (2)
図7は、処理サブシステム12内で用い得る異なるタイプのコヒーレントパケットを一覧にしたテーブル38である。処理サブシステム12の他の実施例が可能でありかつ企図され、パケットタイプとコマンドフィールドエンコーディングとの他の好適なセットを含み得る。テーブル38は、各コヒーレントコマンドごとのコマンドフィールドCmd[5:0]の中身を含むコマンドコード列と、コマンドを表わすニーモニックを含むコマンド列と、コヒーレントパケット30、32および34(および特定されている場合はデータパケット36)のうちどれをそのコマンドに対して用いるかを示すパケットタイプ列とを含む。テーブル38のコマンドのうちいくつかの簡単な機能説明が以下に与えられる。
【0039】
読出トランザクションは、サイズドリード(Read(Sized))リクエスト、リードブロック(RdBlk)リクエスト、リードブロック共有(RdBlkS)リクエストまたはリードブロック変更(RdBlkMod)リクエストを用いて開始され得る。Read(Sized)リクエストは、所定サイズのキャッシュブロック以外のデータの読出またはキャッシュ不可能な読出に用いられる。読出すべきデータの量は、Read(Sized)リクエストパケットにエンコードされる。キャッシュブロックの読出にはRdBlkリクエストを用い得る。ただしこれは、以下の2つの場合を除いてである。すなわち、(i)書込可能なキャッシュブロックのコピーが所望される場合であり、この場合、RdBlkModリクエストを用い得る;または(ii)キャッシュブロックのコピーが所望されるが、ブロックを変更する意図が知られていない場合であり、この場合、RdBlkSリクエストを用い得る。RdBlkSリクエストを用いて、あるタイプのコヒーレンシ機構(たとえばディレクトリベースのコヒーレンシ機構)をより効率的にし得る。
【0040】
一般的に、トランザクションを開始するには、ソースノードから、キャッシュブロックに対応するメモリを所有するターゲットノードに適切な読出リクエストを送信する。ターゲットノードのメモリコントローラは、システムの他のノードにプローブリクエストを送信して、それらのノードのキャッシュブロックの状態を変えることおよび、キャッシュブロックの更新済コピーを含むノードにキャッシュブロックをソースノードへ送らせることによってコヒーレンシを維持する。プローブリクエストを受ける各ノードは、ソースノードにプローブ応答(ProbeResp)パケットを送信する。
【0041】
プローブされたノードが変更された読出データのコピー(すなわちダーティデータ)を有する場合、そのノードは、読出応答(RdResponse)パケットおよびダーティデータをソースノードに送信する。ダーティデータを送信するノードは、リクエストされた読出データのターゲットノードによる送信をキャンセルしようとして、ターゲットノードにメモリキャンセル(MemCancel)応答パケットも送信し得る。さらに、ターゲットノードのメモリコントローラは、RdResponse応答パケットを用いて、リクエストされた読出データを送信し、その後にデータパケットのデータを送信する。
【0042】
プローブされたノードからソースノードがRdResponse応答パケットを受けると、受けた読出データが用いられる。受けない場合は、ターゲットノードからのデータが用いられる。プローブ応答および読出データの各々が一旦ソースノードで受けられると、ソースノードは、トランザクションの終了の肯定応答としてソースダン(SrcDone)応答パケットをターゲットノードに送信する。
【0043】
書込トランザクションは、サイズドライト(Wr(Sized))リクエストパケットまたは犠牲(Victim)ブロック(VicBlk)リクエストパケット、なおこの後には対応のデータパケットが続く、を用いて開始され得る。Wr(Sized)リクエストは、所定のサイズのキャッシュブロック以外のデータの書込またはキャッシュ不可能な書込に用いられる。Wr(Sized)リクエストのためのコヒーレンシを維持するため、ターゲットノードのメモリコントローラは、システムの他のノードの各々にプローブリクエストを送信する。プローブリクエストに応答して、プローブされた各ノードは、ターゲットノードにProbeResp応答パケットを送信する。プローブされたノードがダーティデータを記憶している場合、プローブされたノードは、RdResponse応答パケットおよびダーティデータで応答する。このように、Wr(Sized)リクエストによって更新されたキャッシュブロックはメモリコントローラに戻され、Wr(Sized)リクエストが与えたデータと合流する。メモリコントローラは、プローブされたノードの各々からプローブ応答を受けると、ソースノードにターゲットダン(TgtDone)応答パケットを送信して、トランザクションの終了の肯定応答を与える。ソースノードはSrcDone応答パケットで答える。
【0044】
ノードによって変更されかつノード内でキャッシュの中で置き換えられる犠牲キャッシュブロックは、VicBlkリクエストパケットを用いてメモリに戻される。VicBlkリクエストにはプローブは必要ない。したがって、ターゲットメモリコントローラが犠牲ブロックデータをメモリにコミットする準備ができれば、ターゲットメモリコントローラは犠牲ブロックのソースノードにTgtDone応答パケットを送信する。ソースノードは、SrcDone応答パケットで答えてデータをコミットすべきであることを示すかまたは、MemCancal応答パケットで答えてVicBlkリクエストの送信と(たとえば介入プローブに応答した)TgtDone応答パケットの受信との間にデータが無効にされたことを示す。
【0045】
ソースノードはダーティへ変更(ChangetoDirty)リクエストパケットを送信して、書込不可能な状態でソースノードが記憶したキャッシュブロックの書込許可を入手し得る。ChangetoDirtyリクエストで開始されたトランザクションは、ターゲットノードがデータを戻さないことを除き、読出トランザクションと同様に動作し得る。ソースノードがキャッシュブロック全体を更新することを意図する場合、ブロック有効化(ValidateBlk)リクエストを用いて、ソースノードが記憶していないキャッシュブロックへの書込許可を入手し得る。そのようなトランザクションの場合、ソースノードにはデータが全く転送されないが、それ以外の場合は、読出トランザクションと同様に動作する。
【0046】
ターゲットは、ターゲットスタート(TgtStart)応答を用いて、(たとえばその後のトランザクションの順序付けのために)トランザクションをスタートさせたことを示し得る。非動作(NOP)情報パケットを用いて、ノード間にフロー制御情報(たとえばバッファ空き表示)を転送してもよい。ブロードキャストリクエストパケットを用いて、ノード間でメッセージをブロードキャスト(たとえば割込を配信)してもよい。最後に、同期(Sync)情報パケットを用いてノード動作(たとえば、エラー検出、リセット、初期化など)を同期化してもよい。
【0047】
テーブル38はバーチャルチャネル(Vchan)列も含む。Vchan列は、各パケットがその中を移動する(すなわち各パケットが属する)バーチャルチャネルを示す。この実施例では、4つのバーチャルチャネルが定義される。すなわち、ノンポステッドコマンド(NPC)バーチャルチャネル、ポステッドコマンド(PC)バーチャルチャネル、応答(R)バーチャルチャネルおよびプローブ(P)バーチャルチャネルである。
【0048】
バーチャルチャネル
次に図8を参照して、2つのバーチャルチャネル40Aおよび40Bならびにそれらと処理ノード12A−12Dとの関係が概略的に図示される。バーチャルチャネルは2つしか示されていないが、コンピュータシステム10の他の実施例はいずれの好適な数のバーチャルチャネルを用いてもよいことを理解されたい。
【0049】
一般的に、「バーチャルチャネル」とは、さまざまな処理ノード間でパケットを搬送するための通信経路である。各バーチャルチャネルは他のバーチャルチャネルとはリソース独立している(すなわち、1つのバーチャルチャネルを流れるパケットは、物理的送信という観点では、別のバーチャルチャネル中のパケットの存在または不在による影響を受けないことが一般的である)。パケットは、パケットのタイプに基づいてバーチャルチャネルに割当てられる。同じバーチャルチャネル中のパケットは、互いの送信と物理的に競合し得る(すなわち、同じバーチャルチャネル中のパケットはリソース競合に遭遇し得る)が、異なるバーチャルチャネル中のパケットの送信とは物理的に競合しないであろう。
【0050】
あるパケットは他のパケットと論理的に競合し得る(すなわち、プロトコルの理由、コヒーレンシの理由またはその他のそのような理由により、1つのパケットが別のパケットと論理的に競合し得る)。論理的/プロトコルの理由のために、第2のパケットがそのデスティネーションノードに到着する前に第1のパケットがそのデスティネーションノードに到着する必要がある場合に、(たとえば競合するリソースを占めることによって)第2のパケットが第1のパケットの送信を物理的にブロックすれば、コンピュータシステムがデッドロックを起こす可能性がある。第1および第2のパケットを別個のバーチャルチャネルに割当てることにより、かつ、別個のバーチャルチャネル中のパケットが互いの送信をブロックできないようにコンピュータシステム内の送信媒体を実現することにより、デッドロックのない動作を達成し得る。異なるバーチャルチャネルからのパケットは同じ物理リンク(たとえば図1の線24)上を送信されることに留意されたい。しかしながら、送信前に受信バッファが利用可能であるため、バーチャルチャネルは、この共有リソースを用いる間ですら互いをブロックすることはない。
【0051】
各々の異なるパケットタイプ(たとえば各々の異なるコマンドフィールドCMD[5:0])は、それ自身のバーチャルチャネルに割当てられ得る。しかしながら、バーチャルチャネルにおいて物理的に競合がないことを確実にするハードウェアは、バーチャルチャネルの数とともに増加し得る。たとえば、1つの実施例では、各バーチャルチャネルに別個のバッファが割振られる。各バーチャルチャネルごとに別個のバッファを用いるため、1つのバーチャルチャネルからのパケットは別のバーチャルチャネルからのパケットと物理的に競合しない(そのようなパケットは他のバッファに置かれるからである)。しかしながら、バッファの数がバーチャルチャネルの数に比例することに留意されたい。したがって、論理的/プロトコルの態様で競合しないさまざまなパケットタイプを組合せることによりバーチャルチャネルの数を低減することが望ましい。同じバーチャルチャネルを移動する際、そのようなパケットは互いと物理的に競合し得るが、論理的競合がないことにより、デッドロックすることなくリソース競合を解決することができる。同様に、互いと論理的に競合し得るパケットを別個のバーチャルチャネルに保持することにより、パケット間でのリソース競合がなくなる。したがって、先に完了すべきパケットを前に進めることによってパケット間のリソース競合をなくすことで、論理的競合を解決し得る。
【0052】
1つの実施例では、特定のソースノードから特定のデスティネーションノードへコヒーレントリンク上の特定のバーチャルチャネル内を移動するパケットは順序付けられたままである。しかしながら、異なるバーチャルチャネルを移動する特定のソースノードから特定のデスティネーションノードへのパケットは順序付けられていない。同様に、特定のソースノードから異なるデスティネーションノードへまたは異なるソースノードから同じデスティネーションノードへのパケットは、(同じバーチャルチャネル中を移動しているとしても)順序付けられない。
【0053】
バーチャルチャネルはコヒーレントファブリックおよびノンコヒーレントファブリックに物理的にマッピングされる(図19参照)。たとえば、図1に示されるコンピュータシステム10の実施例では、相互接続は各処理ノード間の一方向リンクを含む。したがって、さまざまなバーチャルチャネルを移動するパケットは一方向リンク上を物理的に送信される。パケットは、ソースとデスティネーションとの間の中間ノードを通って移動し得る。たとえば、ノード12Aからノード12Dに移動するパケットはノード12Bまたはノード12Cを通り得る。異なるバーチャルチャネルを移動するパケットは、コンピュータシステム10を通って異なってルーティングされ得る。たとえば、ノード12Aからノード12Dへ第1のバーチャルチャネルを移動するパケットはノード12Bを通り得るが、ノード12Aから12Dへ第2のバーチャルチャネルを移動するパケットはノード12Cを通り得る。各ノードは、異なるバーチャルチャネル中のパケットが互いと物理的に競合しないのを確実にする回路構成を含み得る。ノンコヒーレントファブリックでは、I/Oノードからのパケットは、そのI/Oノードとホストブリッジとの間で互いのI/Oノードを通り得る(図19参照)。I/Oノードは、図8に示されたのと同様の態様でバーチャルチャネルに結合され得ることに留意されたい。
【0054】
以下により詳細に記載される1つの特定の実施例では、各バーチャルチャネルにコマンドパケットバッファが割当てられて、そのバーチャルチャネルを移動するパケットをバッファする。データパケットを搬送し得る各バーチャルチャネルに別個のデータパケットバッファを割当ててもよい。コマンドパケットバッファ(その各々のエントリは比較的小さな数のビット時間を含み得る)とデータパケットバッファ(その各々のエントリは比較的大きな数のビット時間を含んでキャッシュブロックを保持し得る)とを分けることにより、好適なデータ記憶を依然として提供しながらバッファ空間を節約し得る。データパケットバッファよりも多くのコマンドパケットバッファを実現してもよい(すべてのデータパケットは対応のリクエストまたは応答パケットを有するが、すべてのリクエストまたは応答パケットが対応のデータパケットを有するとは限らないからである)。バッファ空間を比較的効率よく用いている間は、スループットは高いであろう。
【0055】
図9は、コンピュータシステム10の1つの実施例に従って規定されたバーチャルチャネルを図示するテーブル42である。他の実施例が可能でありかつ企図される。示された実施例については、4つのバーチャルチャネルが規定される。コヒーレントリンクのためにそれらのバーチャルチャネルに属するパケットが図7に示され、ノンコヒーレントリンクのためにそれらのバーチャルチャネルに属するパケットが図20に示される。
【0056】
所与のリクエストは「ポストされた」または「ノンポステッド」リクエストであろう。一般的に、ポストされたリクエストは、ソースノード(たとえばソースノード内のインターフェイス)がリクエストおよび対応のデータを送信するときにソースノードによって完了したとみなされる。したがって、ポストされたリクエストはソースで実質的に完了する。その結果、ソースノードは、ポストされたリクエストのパケットまたは複数のパケットがターゲットノードに移動し、ターゲットノードがポストされたリクエストを完了する間に、他のリクエストを発行しかつ他の動作を継続し得る。ソースノードは、ターゲットノードがいつポストされたリクエストを実際に完了するかに直接に気づかない。例示的な実施例では、コヒーレントポステッドリクエストパケットは、バーチャルチャネル識別子として用いられるコマンドフィールドにポステッドビットを含む。コヒーレントポステッドリクエストは、ターゲットインターフェイス(たとえばノンコヒーレントリンク)でポステッドリクエストを完了する前にTgtDone応答をソースノードに送信することにより、コヒーレントファブリックにおいて完了する。
【0057】
ポストされたリクエストに対して、ノンポステッドリクエストは、ターゲットインターフェイス上で完了する前にソースインターフェイスで完了しないリクエストである。このように、リクエストのソースは、リクエストがターゲットで完了したことに(リクエストの完了を介して)直接に気づく。一般的に、さまざまなノンポステッドリクエストパケットは、互いと論理的/プロトコル競合を有しない。なぜなら、それらがデスティネーション(すなわちトランザクションのターゲット)に到達するまではそれらの間に順序が存在しないからである。したがって、ノンポステッドリクエストパケットを1つのバーチャルチャネルに含んでもよい。
【0058】
例示的な実施例では、ポステッドおよびノンポステッドリクエストパケットは別個のバーチャルチャネルに属して、ある入力/出力(または周辺)バスプロトコルとの互換性を与える。たとえば、周辺機器相互接続(PCI)バスインターフェイスはポステッドライトを与える。以下の順序付けルールはPCIをソースとする動作についてPCIが必要とするものである。
【0059】
(i) 同じソースからのポステッドライトはターゲットインターフェイス上に順序付けられたままである。
【0060】
(ii) ポステッドライトおよびその後の同じソースからの読出は、読出データが戻される前にターゲットインターフェイス上で完了する。
【0061】
(iii) ノンポステッドライトは同じソースからのポステッドライトを通さない。
【0062】
(iv) ポステッドライトは、先行するノンポステッドリクエストを通すことを許されなければならない。
【0063】
要件(i)は、ホストブリッジが実現するある制約とともに、ポステッドリクエストをポステッドコマンドバーチャルチャネルに置く(したがってそれらは特定のターゲットに向けて順序付けられたままである)ことによって達成される(図28参照)。要件(ii)および(iii)は、ノンコヒーレントファブリック上のポステッドリクエストチャネルとノンポステッドコマンドチャネルとの間の論理的競合である。ノンコヒーレントリンク上での論理的競合に関するさらなる詳細を以下に述べる。要件(ii)および(iii)は、ある制約をホストブリッジで実現することにより、ポステッドライトがノンコヒーレントリンクからコヒーレントリンクに送信されるときに満たされ得る(図28参照)。要件(iv)は、別個のポステッドコマンド、ノンポステッドコマンドおよび応答バーチャルチャネルを設けることによって満たされる。
【0064】
ポステッドおよびノンポステッドリクエストは、プローブリクエストパケットの生成を引起して(コヒーレントファブリックにおいてコヒーレンシを維持し)、応答パケットの生成を引起して(データを転送しかつトランザクションの肯定応答を与え得る)。したがって、プローブパケットおよび応答パケットは、ポステッドおよびノンポステッドリクエストと同じバーチャルチャネルには含まれず(リソース競合および論理的競合がデッドロックを生じるのを防止する)。さらに、プローブパケットはプローブ応答および読出応答パケットの生成を引起し得るため、それらは応答パケットとは別個のバーチャルチャネルに置かれる。
【0065】
応答パケットはさらなる応答パケットも生成し得る(たとえば、SrcDoneおよびTgtDoneは互いを生成させ得る)。したがって、応答パケットは、すべての応答パケットが同じバーチャルチャネルに割当てられれば、他の応答パケットと論理的に競合し得る。しかし、応答パケットを複数の異なるバーチャルチャネルに割当てることは、さらなるバーチャルチャネルを扱うリソース要件(たとえばバッファ)が増加するために望ましくないであろう。応答パケットは(ポステッドまたはノンポステッドのいずれかの)リクエストパケットの(たとえばリクエストパケットに応答して生成されたプローブを介した)直接または間接の結果であることに留意されたい。したがって、例示的な実施例では、ノード12A−12D(および以下に示されるI/Oノード)は、ポステッドまたはノンポステッドリクエストパケットでトランザクションを開始する前に、そのトランザクションの間に送信されるいかなるものにも応答して生成され得る、(いずれの応答データパケットも含む)応答パケットを処理するにも十分なリソースを割振るように構成され得る。同様に、プローブリクエストパケットを生成する前に、ノードは、(応答パケットがそのノードに戻される場合に)プローブ応答パケットを処理するのに十分なリソースを割振るように構成され得る。この予めのリソース割振りによって論理的競合が回避され、すべての応答パケットが処理ノードによって受取り可能になる。したがって、応答パケットは1つの応答バーチャルチャネルに合流し得、その中をすべての応答パケット(および対応のデータパケット)が移動し得る。
【0066】
プローブリクエストパケットはプローブバーチャルチャネルを移動する。プローブを用いて、さまざまなキャッシュされたメモリ場所のコピーとメモリ場所自体との間のコヒーレンシを維持する。メモリコントローラが処理する第1のリクエストパケットに対応するコヒーレンシアクティビティは、その後のリクエストパケットを処理し得る前に完了する必要があり得る。たとえば、メモリコントローラの待ち行列が同じキャッシュブロックと関連のリクエストで満杯である場合、第1のリクエストが完了するまでは、メモリコントローラにおいてさらなるリクエストパケットの処理は起こり得ない。したがって、プローブリクエストパケットを別個のバーチャルチャネルに割当てて、他のバーチャルチャネル中のパケットとのリソース競合がプローブリクエストパケットをブロックしないことを確実にし得る。
【0067】
テーブル42は、各タイプのバーチャルチャネルをサポートする(たとえばコヒーレントまたはノンコヒーレント)通信リンクのタイプも示す。たとえば、ノンコヒーレントおよびコヒーレントリンクは両者とも、ポステッドコマンド、ノンポステッドコマンドおよび応答バーチャルチャネルをサポートする。しかしながら、プローブリクエストパケットはコヒーレンシを確実にすることを意図されるがノンコヒーレントリンクはコヒーレンシをサポートしていないため、ノンコヒーレントリンクはプローブバーチャルチャネルとしては用いられないであろう。
【0068】
バーチャルチャネル−コヒーレントファブリック
ここで図10を参照して、例示的な処理ノード12Aの1つの実施例のブロック図が示される。他の処理ノード12B−12Dは同様に構成され得る。さらに、処理ノード12A−12Dの他の実施例が可能でありかつ企図される。図10の実施例では、処理ノード12Aは、インターフェイスロジック18A、18Bおよび18Cならびにメモリコントローラ16Aを含む。さらに、処理ノード12Aは、プロセッサコア52およびキャッシュ50、パケット処理ロジック58を含み、オプションで第2のプロセッサコア56および第2のキャッシュ54を含み得る。インターフェイスロジック18A−18Cはパケット処理ロジック58に結合される。プロセッサコア52および56はそれぞれキャッシュ50および54に結合される。キャッシュ50および54はパケット処理ロジック58に結合される。パケット処理ロジック58はメモリコントローラ16Aに結合される。
【0069】
一般的に、パケット処理ロジック58は、処理ノード12Aが結合されるリンク上で受信されるリクエストパケットに応答して、キャッシュ50および54ならびに/またはプロセッサコア52および56からのリクエストに応答してリクエストパケットを生成し、サービスのため(for service)メモリコントローラ16Aが選択したトランザクションに応答してプローブリクエストおよび応答パケットを生成し、かつ、ノード12Aを中間ノードとするパケットをインターフェイスロジック18A−18Cのうち別のものにルーティングして別のノードに送信するように構成される。インターフェイスロジック18A、18Bおよび18Cは、パケットを受信しかつパケット処理ロジック58が用いる内部クロックとパケットとを同期するロジックを含み得る。
【0070】
パケット処理ロジック58は、コンピュータシステム10がサポートするバーチャルチャネルからのリソース独立をサポートするハードウェアを含み得る。たとえば、パケット処理ロジック58は、図11に図示されるように、各バーチャルチャネルごとに別個のバッファを設け得る。代替的な実施例は、インターフェイスロジック18A−18C内または任意の他の好適な場所に、バーチャルチャネルからのリソース独立を与えるためのハードウェアを設け得る。
【0071】
キャッシュ50および54は、データのキャッシュブロックを記憶するように構成された高速キャッシュメモリを含む。キャッシュ50および54はそれぞれのプロセッサコア52および56内に一体化されてもよい。これに代えて、キャッシュ50および54は、所望により、裏面キャッシュ構成またはインライン構成でプロセッサコア52および56に結合されてもよい。さらに、キャッシュ50および54はキャッシュ階層として実現されてもよい。所望により、(キャッシュ階層内の)プロセッサコア52および56により近い方のキャッシュがプロセッサコア52および56と一体化されてもよい。
【0072】
プロセッサコア52および56は、予め規定された命令セットに従って命令を実行するための回路構成を含む。たとえば、x86命令セットアーキテクチャを選択し得る。これに代えて、Alpha(R)、PowerPC(R)またはいずれの他の命令セットアーキテクチャを選択してもよい。一般的に、プロセッサコアはデータおよび命令を求めてキャッシュにアクセスする。キャッシュミスが検出されれば読出リクエストが生成されて、ミスしているキャッシュブロックがマッピングされるノード内のメモリコントローラに送信される。
【0073】
ここで図11を参照して、パケット処理ロジック58の例示的な実施例のブロック図が示される。他の実施例が可能でありかつ企図される。図11の実施例では、パケット処理ロジック58は、第1の組のコマンドおよびデータパケットバッファ60と、第2の組のコマンドおよびデータパケットバッファ62と、第3の組のコマンドおよびデータパケットバッファ64と、制御ロジック66と、データバッファプール68と、応答カウンタプール70とを含む。コマンドおよびデータパケットバッファ60は、ポステッドコマンドバッファ(PCB)60A、ノンポステッドコマンドバッファ(NPCB)60B、応答バッファ(RB)60C、プローブバッファ(PB)60D、ポステッドコマンドデータバッファ(PCDB)60E、ノンポステッドコマンドデータバッファ(NPCDB)60Fおよび応答データバッファ(RDB)60Gを含む。
【0074】
同様に、コマンドおよびデータパケットバッファ62は、ポステッドコマンドバッファ(PCB)62A、ノンポステッドコマンドバッファ(NPCB)62B、応答バッファ(RB)62C、プローブバッファ(PB)62D、ポステッドコマンドデータバッファ(PCDB)62E、ノンポステッドコマンドデータバッファ(NPCDB)62Fおよび応答データバッファ(RDB)62Gを含む。コマンドおよびデータパケットバッファ64は、ポステッドコマンドバッファ(PCB)64A、ノンポステッドコマンドバッファ(NPCB)64B、応答バッファ(RB)64C、プローブバッファ(PB)64D、ポステッドコマンドデータバッファ(PCDB)64E、ノンポステッドコマンドデータバッファ(NPCDB)64Fおよび応答データバッファ(RDB)64Gを含む。コマンドおよびデータパケットバッファ60は、(たとえば線24B上で)インターフェイスロジック18Aが受けるパケットを受けるように結合される。同様に、コマンドおよびデータパケットバッファ62は、インターフェイスロジック18Bが受けるパケットを受けるように結合され、コマンドおよびデータパケットバッファ64は、インターフェイスロジック18Cが受けるパケットを受けるように結合される。コマンドおよびデータパケットバッファ60、62および64は制御ロジック66に結合される。
【0075】
さらに、応答データバッファ60G、62Gおよび64Gはデータバッファプール68に結合される。データバッファプール68および応答カウンタプール70は制御ロジック66に結合され、制御ロジック66は、ノードIDレジスタ72、コマンドパケットアクティブレジスタ74A−74Cおよびデータパケットアクティブレジスタ76A−76Cをさらに含む。制御ロジック66は送受信インターフェイスを介してインターフェイス18A−18Cに結合され、かつ、メモリコントローラ16Aおよびキャッシュ50(およびオプションのキャッシュ54)にも結合される。データバッファプール68はメモリコントローラ16Aおよびキャッシュ50(およびオプションのキャッシュ54)にさらに結合される。
【0076】
コマンドおよびデータパケットバッファの各組はバーチャルチャネルの各々ごとに異なるバッファを設ける。たとえば、この実施例では、ポステッドコマンドバッファ60Aはポステッドコマンドバーチャルチャネルに割当てられ、ノンポステッドコマンドバッファ60Bはノンポステッドコマンドバーチャルチャネルに割当てられ、応答バッファ60Cは応答バーチャルチャネルに割当てられ、かつ、プローブバッファ60Dはプローブバーチャルチャネルに割当てられ得る。このように、1つのバーチャルチャネルでのパケットの受信は、別のバーチャルチャネルでのパケットの受信によって妨げられることはないであろう。各バーチャルチャネルからのパケットは、そのバーチャルチャネルに対応するコマンドパケットバッファに記憶され得るため、(異なるコマンドパケットバッファに記憶される)別のバーチャルチャネルから受けたパケットと物理的に競合することはない。バッファ62および64内の同じ名前のバッファは、上述のようにバーチャルチャネルに割当てられ得る。
【0077】
同様に、データパケットバッファは、データパケットを搬送する各バーチャルチャネルごとに設けられる。例示的な実施例では、プローブバーチャルチャネルはデータパケットを搬送しないであろう。たとえば、ポステッドコマンドデータバッファ60Eはポステッドコマンドバーチャルチャネルに割当てられ、ノンポステッドコマンドデータバッファ60Fはノンポステッドコマンドバーチャルチャネルに割当てられ、かつ、応答データバッファ60Gは応答バーチャルチャネルに割当てられ得る。バッファ62および64内の同じ名前のバッファは、上述のようにバーチャルチャネルに割当てられ得る。
【0078】
この実施例では、インターフェイスロジック18A−18Cは、受信パケットを、制御経路上に与えられたパケットとデータ経路上に与えられたデータパケットとに分けるように構成される。制御経路はコマンドパケットバッファに結合され(たとえば、バッファ60A−60Dはインターフェイスロジック18Aからの制御経路に結合され)、データ経路はデータパケットバッファに結合される(たとえば、バッファ60E−60Gはインターフェイスロジック18Aからのデータ経路に結合される)。制御ロジック66は、送受信インターフェイスを介してパケットのタイプの表示を受けるように構成され、さらに、受信中のパケット用のバッファエントリを割振るように構成され得る。他の企図される実施例では、インターフェイスロジックは受信パケットを分割しない。そのような実施例では、制御ロジック66は制御(CTL)信号を受信して、データのビット時間と制御情報のビット時間とを区別し得る。
【0079】
一般的に、制御ロジック66は、他のバッファに保持されるパケットとは独立してさまざまなバッファからのパケットを処理するように構成され得る。したがって、異なるバーチャルチャネルを移動するパケット間の物理的競合を回避することができる。
【0080】
例示的な実施例では、制御ロジック66は、コマンドパケットバッファ60、62および64内のパケットを調べて、パケットがノード12A(このノード)に宛先決めされているのかまたはこれを別のノードに転送すべきかを判断する。ノードIDレジスタ72は「このノード」のノードIDを記憶し、制御ロジック66はノードIDを参照して比較を行ない、パケットが「このノード」に宛先決めされているか否かを判断し得る。この実施例では、プローブバーチャルチャネル中のパケットはブロードキャストパケットであるので、「このノード」と「このノード」がパケットを送信すべき他のノードとの双方に宛先決めされていることに留意されたい。したがって、制御ロジック66はプローブバーチャルチャネルで受信するパケットのノードID比較を省略してもよい。しかしながら、プローブバーチャルチャネル以外のバーチャルチャネル中のパケットは、パケットがこのノードに宛先決めされているのかまたはこれを別のノードに転送すべきかをパケットのデスティネーションノードフィールドが識別する対象の、方向付けられたパケットである。したがって、制御ロジック66は、そのようなパケットについてノードID比較を行ない得る。
【0081】
制御ロジック66は、各デスティネーションノードごとに、インターフェイスロジック18A−18Cのうちどれを用いてブロードキャストパケットまたは他のノードに宛先決めされたパケットを転送し得るかを示す1つ以上のルーティングテーブルを含み得る。制御ロジック66は、識別されたインターフェイスロジック18A−18Cを介して送信されたパケットを受けるように結合された受信ノードが、そのパケットが割当てられるバーチャルチャネル用の空きのあるコマンドパケットバッファを有する場合に、パケットを転送し得る。さらに、パケットがデータパケットを特定している場合、制御ロジック66は、制御ロジック66がパケットおよび特定されたデータパケットを転送する前に、パケットが割当てられるバーチャルチャネル用のデータパケットバッファの利用可能性を確認する。制御ロジック66が、パケット(および特定されていればデータパケット)を転送すべきであると判断しかつ適切なパケットバッファの利用可能性を確認すれば、制御ロジックは、送受信インターフェイスを用いて、識別されたインターフェイスロジック18A−18Cにそのパケットを転送する。その後、インターフェイスロジック18A−18Cはパケットを受信ノードに転送する。また、制御ロジック66は、対応するタイプのバッファが空いたことに気づく(パケットおよび特定されていればデータパケットが転送されたからである)。次に適切なインターフェイス18A−18Cを介して情報パケットが送信され、受信端のノードにバッファの利用可能性を通知し得る。
【0082】
しかしながら、パケットが「このノード」に宛先決めされている場合、制御ロジック66は、パケットのタイプに基づいてパケットを処理する。たとえば、パケットがメモリコントローラ16Aにターゲット決めされた書込リクエストである場合、制御ロジック66は、書込リクエストパケットをメモリコントローラ16Aに運搬しようとする。メモリコントローラ16Aは、処理すべきトランザクションに待ち行列を用いてもよく、たとえば待ち行列が満杯である場合は書込リクエストパケットを拒否してもよい。受信パケットがプローブリクエストパケットである場合、制御ロジック66は、キャッシュ50および54(ならびにプロセッサコア52および56の内部の任意のキャッシュ)と通信して、プローブがアドレス指定するキャッシュブロックのステータスを判断し得る。次に制御ロジック66は、アドレス指定されたキャッシュブロックのステータスを報告するプローブ応答パケット(またはキャッシュブロックが変更されていれば、データを備える読出応答パケット)を生成することによってプローブに応答し、次に、受信ノードが適切なパケットバッファの利用可能性を示していれば、プローブ応答パケットを送信し得る。
【0083】
受信パケットを処理することに加え、制御ロジック66は、キャッシュ50および54からの犠牲ブロックおよびフィルリクエストに応答してパケットを生成しかつ、(たとえばキャッシュ不可能なリクエスト、I/Oリクエストなどの)プロセッサコア52および56から直接のリクエストに応答してパケットを生成し得る。さらに、応答パケットは、送信のためのデータを与えるかまたはトランザクションを完了するメモリコントローラに応答して生成され得る。制御ロジック66は、処理に対する対応のリクエストを選択するメモリコントローラ16Aに応答してプローブリクエストパケットを生成し、受信ノードバッファが利用可能であればプローブリクエストパケットをブロードキャストしてもよい。
【0084】
上述のように、ノードは、そのノードが送信するリクエストパケットに応答して、受信した応答パケットを処理するのに十分なリソースを割振る。例示的な実施例では、制御ロジック66はパケットを送信し得、その結果、次の2つの場合に応答パケットがノードに戻されることになり得る。すなわち、(i)リクエストパケットを生成して(たとえば、キャッシュ50および54またはプロセッサコア52および56からのリクエストに応答して)トランザクションを開始する場合;および(ii)メモリコントローラ16Aをターゲットとするリクエストパケットに対しプローブリクエストパケットを生成する場合、である。より特定的には、メモリコントローラ16Aをターゲットにするサイズドライトについて、(ii)の場合が起こり得る。いずれにせよ、制御ロジック66はリソースを割振って、応答パケットの受信および処理を行なう。
【0085】
例示的な実施例では、制御ロジック66は、データバッファプール68および応答カウンタプール70からリソースを割振って、応答を受信しかつ処理し得る。データバッファプール68は、データのキャッシュブロックを記憶するために複数のエントリを含み得る一方、応答カウンタプール70は複数のカウンタを含み得る。データバッファプールエントリは、トランザクションに対応する応答データを記憶するように割振られ得る。カウンタは、受信した応答をカウントし、かつ、プローブ応答において与えられ得るいかなるステート情報も保持するように割振られ得る。応答パケットは、割振られたカウンタを用いて(たとえば、予期される数の応答に達するまで)カウントされ得、応答パケットとともに受信されたデータは、割振られたデータバッファに記憶され得る。トランザクションに関わる、多くても2つの応答パケット(MemCancel応答パケットが応答パケットの送信前にメモリコントローラに達しない場合の、ターゲット決めされたメモリコントローラからのパケットと、変更されキャッシュされたデータのコピーを有した、プローブされたノードからのパケット)がデータを搬送し得ることに留意されたい。2つのデータパケットを受信した場合、プローブされたノードからのパケットが保持され、メモリコントローラからのパケットが破棄される。
【0086】
予期される応答および応答データの各々を一旦受信すると、制御ロジック66は、行なわれたトランザクションのタイプに依存して、データをメモリコントローラ16Aまたはキャッシュ50もしくは54に送信し得る。たとえば、応答が、パケット処理ロジック58が生成したプローブリクエストに応答して生成されたプローブ応答である場合、応答データはメモリコントローラ16Aに送信され得る。これに代えて、読出トランザクションの結果として応答が生成された場合、データはキャッシュ50または54に送信され得る。
【0087】
データバッファプール68を用いて、ノード12Aから送信されるべきデータを記憶してもよいことに留意されたい。たとえば、犠牲ブロックデータまたはノード12Aをソースとする書込リクエストのための書込データをデータバッファプール68に記憶してもよい。これに代えて、そのようなデータに別個のバッファを設けてもよい。さらに、さまざまなトランザクションに用い得るバッファのプールを設ける代わりに、各トランザクションタイプごとに別個のバッファを設けてもよい。
【0088】
一般的に、本明細書中で用いるように、バッファは、後の検索のために1つ以上の情報項目を記憶するのに用いられる記憶素子である。バッファは、1つ以上のレジスタ、ラッチ、フリップフロップまたは他のクロック記憶装置を含み得る。これに代えて、バッファは、好適に配置されたランダムアクセスメモリ(RAM)セルの組を含んでもよい。バッファは複数の記憶場所に分割され、各記憶場所は、バッファが意図される対象のタイプの情報の1項目を記憶するように構成される。記憶場所はいずれの好適な態様で割振られても割振り解除されてもよい。たとえば、バッファは、より古いエントリが削除されれば、記憶されたエントリが所定の場所にシフトダウンしていく、シフティング先入れ先出し(FIFO)バッファとして動作してもよい。これに代えて、ヘッドおよびテールポインタを用いて、バッファの中で最も古いおよび最も新しいエントリ場所を示してもよく、エントリは、そこから削除されるまでは、バッファの特定の記憶場所に留まり得る。本明細書中で用いられるような「制御ロジック」という用語は、入力に対する動作を行ない、かつ、それに応答して出力を生成して上記動作を行なう、組み合わせロジックおよび/またはステートマシンのいずれの組み合わせも指す。
【0089】
例示的な実施例では、パケットは、一連のビット時間としてインターフェイスロジック18A−18Cから受信される。インターフェイスロジック18A−18Cは、コマンドまたはデータビット時間が送信されているかを示し、制御ロジック66が、適切なバッファにビット時間を記憶させる。制御ロジック66は、コマンドパケットアクティブ(CPA)レジスタ74およびデータパケットアクティブ(DPA)レジスタ76を用いて、現在受信されているパケットがどのバーチャルチャネルに割当てられるのかを識別し得る。CPAレジスタ74は、各インターフェイスロジック18A−18Cのために提供される(たとえば、CPA74Aは、インターフェイス18Aに対応し得る)。同様に、DPAレジスタ76は、各インターフェイスロジック18A−18Cのために提供される(たとえば、DPAレジスタ76Aは、インターフェイス18Aに対応し得る)。
【0090】
したがって、例示的な実施例では、受信されるパケットの第1のビット時間に応答して、制御ロジック66は、(ビット時間1内の)コマンドフィールドをデコードし、受信されるパケットがどのバーチャルチャネルに割当てられるかを判断する。制御ロジック66は、(インターフェイスロジック18A−18Cであって、それらからパケットが受信されるインターフェイスロジック18A−18Cに対応するセット内の)対応するコマンドパケットバッファ内でバッファ場所を割振り、インターフェイスロジック18A−18Cであって、それらからパケットが受信されるインターフェイスロジック18A−18Cに対応するCPAレジスタ76の状態を設定してそのコマンドパケットバッファ場所の割振りを示す。同じインターフェイスロジック18A−18Cからの後続のパケットビット時間は、パケットの各ビット時間が受信されるまで、示されたバッファ内の示された場所に記憶される。同様に、パケットがデータパケットを特定するならば、制御ロジック66は、識別されるバーチャルチャネルに対応するデータパケットバッファ内でデータパケットバッファ場所を割振る。データパケットビット時間は、データの各ビット時間が受信されるまで、示されたバッファの示された場所に記憶される。
【0091】
代替的な実施例では、インターフェイスロジック18A−18Cは、パケットのビット時間を集め、次に、全パケットをパケット処理ロジック58に送信し得る。このような実施例では、CPAレジスタ74およびDPAレジスタ96は削除され得る。さらなる別の実施例では、インターフェイスロジック18A−18Cは、パケット処理ロジック58への並行送信のためにいくつかのビット時間を集め得るが、ビット時間の数はパケットよりも少ないであろう。さらなる別の実施例では、バッファ60、62、および64は、パケット処理ロジック58内ではなく、それぞれのインターフェイスロジック18A−18C内に位置づけられてもよい。
【0092】
図11で示される実施例は、各インターフェイスロジック18A−18Cに対して別個の組のバッファを提供する。代替的な実施例では、バッファは、インターフェイスロジック間で分割され得る(各バーチャルチャネルタイプのための)1つ以上のバッファプールとして提供され得る。このような実施例では、バッファは、別のノードに結合されていないインターフェイスロジック(たとえば、図1の例でのインターフェイスロジック18C)に割当てられる必要はなく、バッファプールが最大限に効率的に用いられる。したがって、これ以外の場合にはインターフェイスロジック18Cに割振られたであろうバッファは、インターフェイスロジック18A−18Bによって用いられるために割振られ得る。
【0093】
次に図12を参照して、データバッファプール68内にあり得るデータバッファプール場所80の1つの実施例を例示する図が示される。他の実施例も可能であり、企図される。図12の実施例では、データバッファプール場所80は、ソースタグフィールド82、ソースノードフィールド84、ソースユニットフィールド88、およびデータフィールド86を含む。
【0094】
制御ロジック66がデータバッファプール場所80を割振ってトランザクションのための応答データパケットを記憶すると、制御ロジック66は、トランザクションのソースノード、ソースユニット、およびソースタグを、それぞれソースノードフィールド84、ソースユニットフィールド88、およびソースタグフィールド82に記憶し得る。ソースノード、ソースユニット、およびソースタグは未処理のトランザクションを一意に識別し、ソースノード、ソースユニット、およびソースタグは、未処理のトランザクションに対応する応答パケットによって搬送されるため、トランザクションの応答パケット(および対応するデータパケット)は、制御ロジック66によって識別され得、データパケットは、割振られるエントリへと記憶され得る。たとえば、応答データパケットを特定する応答パケットが受信されると、応答パケットのソースノード、ソースユニット、およびソースタグは、ソースノードフィールド84、ソースユニットフィールド88、およびソースタグフィールド84と比較されて応答データのために以前に割振られたデータバッファプール場所80が決定され得る。応答データは次に、応答データバッファから、割振られたデータバッファプール場所80のデータフィールド86へとコピーされ得る。例示的な実施例では、データフィールド86はデータのキャッシュブロックを含み得る。
【0095】
次に図13を参照して、応答カウンタプール70内に存在し得る応答カウンタ90の例示的な実施例を例示する図が示される。他の実施例も可能であり、企図される。図13の実施例では、応答カウンタ90は、ソースタグフィールド92、ソースノードフィールド94、ソースユニットフィールド95、応答カウントフィールド96、および受信状態フィールド98を含む。
【0096】
制御ロジック66が応答カウンタ90を割振ってトランザクションのための応答カウントを記憶すると、制御ロジック66は、トランザクションのソースノード、ソースユニット、およびソースタグを、それぞれソースノードフィールド94、ソースユニットフィールド95、およびソースタグフィールド92に記憶し得る。ソースノードフィールド94、ソースユニットフィールド95、およびソースタグフィールド92は、データバッファプール場所80の対応するフィールド84、88、および82と同様の様態で用いられ得る。
【0097】
応答カウントフィールド96は、トランザクションへの割振り時に、そのトランザクションに対して予期される応答数に初期設定され得る。フィールド94、95、および92にそれぞれ記憶されるソースノード、ソースユニット、およびソースタグを有する応答パケットが受信されると、応答カウントは減分され得る。応答カウントが0に達するとき、全応答が受信されており、トランザクションはコミットされ得る。代替的には、カウントは0に初期設定されてもよく、予期される応答数が受信されるまで、応答パケットは応答カウントの増分を引き起こし得る。
【0098】
受信状態フィールド98を用いて、データが受信され得る状態が示され得る。状態は、キャッシュブロックへのアクセス権と、キャッシュブロックを受信したときにノード12Aが必要とした、キャッシュブロックのためのコヒーレンシーを維持するための応答性(responsibilities)とを示す。例示的な実施例では、MOESI(修正、所有、排他、共有、および無効)コヒーレンシー状態が用いられ得、受信状態フィールド98は、サポートされる状態のうちの1つにエンコードされ得る。代替的には、他のいずれかの好適な組のコヒーレンシー状態が用いられてもよい(たとえば、MESI状態)。受信状態フィールド98は、トランザクションによって転送されているキャッシュブロックのコピーを他のノードが有さない状態に対応する状態に初期設定され得る。応答が受信されると、受信状態フィールドが更新され得る。たとえば、キャッシュブロックのコピーがプローブされたノードによって維持されていること、またはダーティデータに応答が提供されていることをプローブ応答が示すと、受信状態フィールド98はそれに応じて更新され得る。ある実施例では、共有ビットはプローブ応答パケット内に含まれて、キャッシュブロックのコピーが、プローブ応答を提供しているプローブされたノードによって維持されていることが示され得る。加えて、プローブされたノードからリード応答パケットを受信することによって、ノードがキャッシュブロックのダーティコピーを有したことが示され得る。リード応答パケットはまた共有ビットを含んでキャッシュブロックのコピーが、プローブされたノードによって維持されているかが示され得る。
【0099】
リソースを割振るためにデータバッファプール68および応答カウンタプール70を実現することは、単なる例示にすぎず、未処理のトランザクションのための応答を処理するためのリソースの割振りは、他の様態で実現され得ることが注目される。たとえば、未処理のトランザクションのテーブルが維持され得る。テーブルは、全応答が受信されたのかを制御ロジック66が判断することを可能にする上述または同等の情報と同様のソースノード、ソースユニット、ソースタグ、データ、受信状態、および応答カウントを含み得る。
【0100】
図14を参照して、パケット受信のための例示的なパケット処理ロジック58の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図14で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック58内で組合せ論理を用いて並列に行なわれてもよい。図14で例示されるステップは、各インターフェイスロジック18A−18Cに対して、独立して、さらには並列に行なわれ得る。なぜならば、ビット時間は、各インターフェイスロジックから並行に受信され得るためである。
【0101】
図14で例示される実施例は、一連のビット時間としてパケット処理ロジック58へのパケットを受信する。他の実施例は、インターフェイスロジック18A−18C内でパケットのビット時間を蓄積し、完全なパケットをパケット処理ロジック58に提供し、この場合には、ビット時間でのパケットの受信を管理することに関連したステップは、省略され得る。図14で例示される実施例では、ビット時間が受信されると、パケット処理ロジック58は、受信されたビット時間がデータパケットまたはコマンドパケットの一部であるかを示すインターフェイスロジックからの信号を受信する。ビット時間がデータパケットビット時間ならば(判定ブロック100)、ビット時間は、そのインターフェイスロジックに対応するデータパケットアクティブレジスタによって示される割振られたバッファ場所内のデータバッファに記憶される(ステップ102)。データパケットビット時間がデータパケットの最後のビット時間ならば、制御ロジック66は、対応するデータパケットアクティブレジスタを無効化し得る。
【0102】
しかし、ビット時間がコマンドパケットビット時間ならば、パケット処理ロジック58は、コマンドパケットが現在受信されている最中にあるのかを(たとえば、コマンドパケットアクティブレジスタが有効であるのかを)判断する(判定ブロック104)。コマンドパケットが現在進行中ならば、ビット時間は、コマンドパケットアクティブレジスタによって示されるコマンドパケットバッファに記憶される(ステップ106)。コマンドパケットビット時間がパケットの最後のビット時間ならば、制御ロジック66は、対応するコマンドパケットアクティブレジスタを無効化し得る。
【0103】
コマンドパケットが現在進行中でないならば、パケット処理ロジック58は、新しく受信されるパケットのコマンドフィールドをデコードして、パケットが割当てられるバーチャルチャネルを識別する(ステップ108)。識別されたバーチャルチャネルに対応するコマンドパケットバッファ場所が割振られ、コマンドパケットビット時間が、割振られたコマンドパケットバッファ場所に記憶される。
【0104】
加えて、パケット処理ロジック58は、コマンドパケットが後続のデータパケットを特定するかを判断する(判定ブロック110)。データパケットが特定されると、パケット処理ロジック58は、識別されたバーチャルチャネルに対応するデータバッファからのデータバッファ場所を割当て、データパケットアクティブレジスタを更新して、割当てられたデータバッファおよびデータバッファ場所を示す(ステップ112)。
【0105】
次に図15を参照して、リクエストパケット(たとえば、ノンポステッドリクエストパケットまたはポステッドリクエストパケットのいずれか)を処理するための例示的なパケット処理ロジック58の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図15で示されるステップは、わかりやすくするためにある特定の順序で示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック58内で組合せ論理を用いて並列に行なわれてもよい。図15で示されるステップは、各インターフェイスロジック18A−18Cおよび/または各コマンドパケットバッファに対して、独立して、さらには並列に行なわれ得る。なぜならば、異なるインターフェイスおよび/または異なるバーチャルチャネルからのリクエストパケットは、物理的に独立しているためである。代替的には、1つのリクエストパケット(または、インターフェイスロジック18A−18Cにつき1つのリクエストパケット)が、好適な公平性アルゴリズムに従って処理のために選択され得る。一般に、処理のために1つのバーチャルチャネルから選択されるパケットは、バーチャルチャネル内のパケットの順序付けルールに従うが(たとえば、同じソースから同じデスティネーションへのパケットが順番に選択される)、順序付けルールが順序から外れた選択を許容するならば、所望であれば、パケットは順序付けから外れて処理のために選択されてもよい。
【0106】
図15で例示されるように、パケット処理ロジック58は、リクエストパケットのターゲットが「このノード」であるかを判断する(判定ブロック126)。たとえば、パケット処理ロジック58は、リクエストパケットのデスティネーションノード(DestNode)フィールド内に記録されるデスティネーションノードIDを、ノードIDレジスタ72に記憶されるノードIDと比較し得る。ノードIDが整合すると、リクエストは「このノード」をターゲットとしている。リクエストが「このノード」をターゲットとしないならば、パケット処理ロジック58は、リクエストパケット(および、特定するならば、対応するデータパケット)を適切なデスティネーションノードへと送り得る(ステップ128)。たとえば、パケット処理ロジック58は、どのインターフェイスロジック18A−18Cが、パケットをある特定のデスティネーションノードに送るための送信インターフェイスであるのかを識別するパケットルーティングテーブルを維持し得る。次に、対応するコマンドバッファ(および、データパケットが特定されるならば、データバッファ)が、パケットルーティングテーブルによって特定されるリンクに結合される受信ノード内で利用可能であることがロジック58によって判断されたならば、パケット処理ロジック58は、識別されるインターフェイスロジック18を介してリクエストパケットをデスティネーションノードに送る。ある特定の実施例では、リクエストパケットがデータパケットを特定すると、ロジック58は、ロジック58が特定されたデータパケットを受信するまで、リクエストパケットの送信を遅延し得る。
【0107】
リクエストパケットが「このノード」をターゲットとするならば、パケット処理ロジック58は、リクエストパケット(および、適切ならば、対応するデータパケット)をメモリコントローラ16Aに提供し得る(ステップ130)。一旦リクエストパケットが処理されると(つまり、送信されるか、または「このノード」によって受入れられると)、リクエストパケットはコマンドバッファから除去され、対応するいずれかのデータがコマンドデータバッファから除去されることが注目される。
【0108】
プローブリクエストも同様の態様で処理され得ることが注目される。しかし、プローブリクエストは対応するデータパケットを有さないため、データパケットのためのチェックは省略され得る。さらに、プローブリクエストはブロードキャストパケットであり得るため、プローブリクエストは、(たとえば、ノード内でキャッシュをプローブすることによって)内部で処理もされ、送信もされ得る。プローブされるノードは、「このノード」または別のノードにかかわらず、キャッシュのプローブ後、プローブ応答パケットを生成し、送信し得る。
【0109】
選択されるリクエストパケットが対応するデータパケットを特定するならば、さまざまな実施例は、たとえデータパケットが受信されていない場合でもリクエストパケットを処理し得ることが注目される。代替的には、ノードは、データパケットの到着を待ってデータ送信を簡素化し得るか、または完全に受信されたデータパケットを特定する別のパケットが同じリンク上で送信されることを可能にし得る。リクエストパケットが処理されるときにデータパケットが受信されていない場合、データパケットは、データパケットが最終的に受信されるときに図14に関して上で説明されたように処理され得る。
【0110】
次に図16を参照して、応答パケットを処理するための例示的なパケット処理ロジック58の一部の動作を示すフローチャートが図示される。他の実施例も可能であり、企図される。わかりやすくするために、図16で示されるステップは、ある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック58内で組合せ論理を用いて並列に行なわれ得る。図16で例示されるステップは、各インターフェイスロジック18A−18Cおよび/または各応答パケットバッファに対して、独立して、さらには並列に行なわれ得る。なぜならば、異なるインターフェイスおよび/または異なるバーチャルチャネルからのパケットは、物理的に独立しているためである。
【0111】
図16で示されるように、パケット処理ロジック58は、上で説明されたものと実質的に同じ様態で、応答パケットのデスティネーションノードが「このノード」であるかを判断する(判定ブロック144)。デスティネーションノードが別のノードならば、パケット処理ロジック58は応答パケット(および、適切ならば、対応するデータパケット)を送信するが、以上は、応答パケットが送信されるリンク上のレシーバノード内の応答バーチャルチャネルのための自由バッファ場所が利用可能な場合に、行なわれる(ステップ146)。
【0112】
応答パケットのデスティネーションが「このノード」ならば、パケット処理ロジック58は、対応する応答カウンタを減分し、(応答が、受信される状態がデフォルト状態から変更されるべきであると示すプローブ応答ならば)受信された状態を更新する(ステップ148)。加えて、応答パケットがデータパケットを特定するならば、データパケットは、対応する応答データバッファから、その応答に割振られるデータバッファへと移動させられる(ステップ150)。
【0113】
カウンタの減分後、パケット処理ロジックは、カウンタをテストしてすべての応答パケットが受信および処理されたかを判断し得る(判定ブロック152)。すべての応答パケットが受信および処理されたと判断されると、パケット処理ロジック58は、メモリコントローラ16Aまたはキャッシュ50および54に、それらがトランザクションを完了してもよいことを知らせ、データバッファからの関連データおよび応答カウンタからの受信状態を(適切ならば)提供し得る(ステップ154)。一旦応答パケットが処理されると(つまり、送信されるか、または「このノード」によって受入れられると)、応答パケットは応答バッファから除去され、対応するいずれかの応答データが応答データバッファから除去されることが注目される。
【0114】
ある特定の実施例では、選択される応答パケットが対応するデータパケットを特定するならば、応答パケットは、たとえデータパケットが受信されていない場合にも(つまり、データパケットがデータバッファ内に存在しない場合にも)処理され得、または応答パケット処理は、データパケットの到着を待ってデータ送信を簡素化するか、または完全に受信されたデータパケットを特定する別のパケットが同じリンク上で送信されることを可能にし得ることが注目される。応答パケットが処理されるときにデータパケットが受信されていないならば、データパケットは、データパケットが最終的に受信されるときに図14に関して上で説明されたように処理され得る。
【0115】
次に図17を参照して、ノードが結合される通信リンク上でパケットを開始するための例示的なパケット処理ロジック58の一部の動作を示すフローチャートが図示される。他の実施例も可能であり、企図される。わかりやすくするために、図17で示されるステップはある特定の順序で示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、パケット処理ロジック58内で組合せ論理を用いて並列に行なわれてもよい。パケット処理ロジック58は、プロセッサコア52および56が実行する動作および/またはキャッシュ50および54からのフィルリクエスト/犠牲ブロックに応答して、リンク上でパケットを開始し得る。加えて、プローブパケットは、処理のためにメモリ動作を選択するメモリコントローラ16Aに応答して開始され得る。応答パケットは、プローブが処理された後、および、「このノード」から来ているか、または「このノード」をターゲットとしたトランザクションの完了に応答して、開始され得る。
【0116】
図12で示されるように、パケット処理ロジック58は、開始されるべきパケットによって結果として、データがこのノードに戻され得るのかを判断する(判定ブロック160)。たとえば、ノードが開始するリードトランザクションによって、データはノードに戻されるが、ノードが開始するライトトランザクションによっては、データはノードに戻されない。ChangetoDirtyトランザクションによって結果として、(別のノードが影響を及ぼされるキャッシュブロックをダーティ状態で有するならば)データはノードに戻され得る。同様に、別のノードが影響を及ぼされるキャッシュブロックをダーティ状態で有し、さらにはプローブ応答がこのノードに向けられるべきならば、プローブパケットによってデータはこのノードに戻され得る。トランザクションによって結果として、データがこのノードに戻され得るならば、パケット処理ロジック58は、データバッファプール68からデータバッファを割り振る(ステップ162)。
【0117】
加えて、パケット処理ロジック58は、パケットに応答してプローブ応答がこのノードに戻されるかを判断する(ステップ166)。パケットがプローブであるならば、またはパケットがトランザクションを開始して結果として「このノード」へのプローブ応答(たとえば、リードトランザクション)が得られるならば、プローブ応答のリターンが生じ得る。プローブ応答が「このノード」に戻されるならば、パケット処理ロジック58は、受信される応答を数えるための応答カウンタをトランザクションに割振り、応答カウンタを予期される応答数(たとえば、コヒーレントファブリック内のノード数)に初期設定する(ステップ168)。
【0118】
パケット処理ロジック58はさらに、パケットが開始されていることに応答して、他の応答がこのノードに戻されるか(たとえば、SrcDone、TgtDone等)を判断する(ステップ164)。このような他の応答が戻されるならば、パケット処理ロジック58は、応答カウンタを割振り、初期カウントを、たとえば、1または他のいずれかの適切な開始カウントに設定する(ステップ165)。後に、パケット処理ロジック58はパケットを送信する(ステップ170)。
【0119】
トランザクションを開始する前にリソースを予め割振って(データを含む)応答パケットを処理することによって、応答パケットは、受信時に処理され得る。したがって、たとえいくつかの応答パケットが他の応答パケットとの論理/プロトコル競合を有し得る場合でさえも、応答パケットは、応答バーチャルチャネルに併合され得る。なぜならば、物理的な競合は、各応答パケットを受信時にそのディスティネーションノードで処理することによって、除去されるためである。
【0120】
次に、図18を参照して、バッファリリースフィールドを含む情報パケット180の1つの実施例を例示するブロック図が示される。他の実施例も可能であり、企図される。図18で示される例示的な実施例では、バッファリリースフィールドは、各バッファタイプに対して含まれる。RespDataフィールドは、応答データバッファに対応し、応答フィールドは、応答バッファに対応する。同様に、PostCmdDataフィールドは、ポステッドコマンドデータバッファに対応し、PostCmdフィールドは、ポステッドコマンドバッファに対応する。NonPostDataフィールドは、ノンポステッドコマンドデータバッファに対応し、NonPostCmdフィールドは、ノンポステッドコマンドバッファに対応する。プローブフィールドは、プローブバッファに対応する。
【0121】
バッファリリースフィールドの各々は、2つのビットを含み、トランスミッタからある特定の通信リンク上のレシーバまでの単一の情報パケット180の送信によって、最大3つの、各タイプのバッファ場所のリリースまたは解放が可能となる。3つよりも多い、ある特定のタイプのバッファ場所が提供されると、所望ならば、さらなる情報パケットを用いてさらなるバッファ場所が解放され得る。パケット処理ロジック58は、バッファの各タイプおよび各インターフェイスロジック18A−18Cのためのバッファカウントを含み得、各インターフェイスが結合されるリンクの他端上のレシーバによって提供される各タイプのバッファのトータル数を示し得る。これらのカウンタは、バッファリリースフィールドがレシーバ内で利用可能なバッファ場所の数に設定された状態で、情報パケットをそのレシーバからトランスミッタへと送信することによって、電源投入時に初期設定され得る。レシーバが、3つよりも多い、ある特定のタイプのバッファ場所を有するならば、多数の情報パケットが送信され得る。
【0122】
パケット処理ロジック58は、対応するタイプのバッファ(および、パケットがデータパケットを特定するならば、データバッファ)が、パケットが送信されているレシーバ内で利用可能である限り、ある特定のバーチャルチャネル内でパケットを送信し得る。加えて、パケット処理ロジック58は、パケット処理ロジック58によるパケットの処理の結果としてノード12A内で解放された各インターフェイス18A−18Cのための各タイプのバッファ場所の数を表わす。定期的に、パケット処理ロジック58は、各インターフェイスロジック18A−18Cを介して情報パケット180を送信し、それぞれの通信リンク上のトランスミッタに対して、パケット処理ロジック58によって解放されたバッファ場所の数を示す。
【0123】
バーチャルチャネル−ノンコヒーレントファブリック
次に図19を参照して、I/Oサブシステム200の1つの実施例のブロック図が示される。他の実施例も可能であり、企図される。図19の実施例では、I/Oサブシステム200は、ホストブリッジ202、複数のI/Oノード204A、204B、および204Cを含む。ホストブリッジ202は、ライン24I−24Jを含むコヒーレントリンクを介して処理ノード12Dに結合され、さらにライン24K−24Lを含むノンコヒーレントリンクを介してI/Oノード204Aに結合される。I/Oノード204A−204Cは、デイジーチェーン構成で追加的なノンコヒーレントリンクを介して(ライン24N−24O)相互接続される。ホストブリッジ202は処理ノード12から離れて示されているが、ホストブリッジ202は、所望ならば、処理ノードと一体化されてもよいことが注目される。
【0124】
一般に、ホストブリッジ202は、I/Oサブシステムと処理ノードとの間で移動するパケットを変換する。たとえば、I/Oノード204Bによって送信され、かつ処理ノード12A内にターゲットを有するノンコヒーレントパケットは、I/Oノード204Aを通ってホストブリッジ202へと進む。ホストブリッジ202は、ノンコヒーレントパケットを対応するコヒーレントパケットに変換する。
【0125】
一般に、I/Oノード204A−204Cは、I/Oサブシステム200内でトランザクションを開始し得る。トランザクションは最終的に、別のI/Oノード204A−204C、別のノンコヒーレントリンク上のI/Oノード、またはメモリ14をターゲットとし得る。簡素化のために、トランザクションは、実際のターゲットにかかわらず、ホストブリッジ202とI/Oノード204A−204Cとの間で行なわれ得る。たとえば、ホストブリッジ202は、処理ノード12A−12Dからのリクエストの代わりに、I/Oサブシステム200内でトランザクションを開始し得、コンピュータシステム内のコヒーレントファブリックまたは別のホストブリッジをターゲットとするI/Oノード204A−204Cによって開始されるトランザクションを処理し得る。
【0126】
I/Oサブシステム200内のパケットはI/Oストリーム内を伝わるが、これらは、ノンコヒーレントファブリックによって独立して取り扱われ得るトラフィックの集約(groupings)である。例示的な実施例では、ピアツーピア通信は、ノンコヒーレントファブリック内に存在せず、すべてのパケットは、ホストブリッジ202へと、またはホストブリッジ202から移動し得る。したがって、I/Oノード204A−204Cによって送信されるパケットは、デイジーチェーン接続を通してホストブリッジ202へと(つまり、「アップストリームに」)流され得る。I/Oノード204A−204Cによって発行されるリクエストパケットは、ソースノードのUnitIDを含むことが注目される。同様に、I/Oノード204A−204Cによって発行される応答パケットは、応答を生成したノードのUnitIDを含む。したがって、UnitIDを用いてアップストリームパケットのためのI/Oストリームが識別され得る。
【0127】
ホストブリッジ202によって送信されるパケットは、受信I/Oノード204A−204Cへと(つまり、「ダウンストリームに」)流され得る。例示的な実施例では、ダウンストリーム応答は、応答が送信されているノードのUnitIDを含み、ダウンストリームリクエストは、UnitIDのために0の値を有し、これは、ホストブリッジ202のためにリザーブされるエンコーディングであることが注目されるべきである。したがって、独立したI/Oストリームは、ダウンストリームリクエストトラフィック内で認識できないかもしれず、すべてのダウンストリームトラフィック(リクエストと応答との両方)が同じI/Oストリーム内にあると仮定され得る。
【0128】
ファブリック上のすべてのデバイスは、それらのホストブリッジの方向を「アップストリーム」と認識するようにプログラムされる。デイジーチェーン内でI/Oノードおよびホストブリッジを相互接続し、さらにはI/Oノードに(トランザクションレベルで)ホストブリッジのみと通信させることによって、I/Oノードが他のノードではなくホストブリッジに直接接続されているように見えるI/Oサブシステム200の論理ビューが提供される。
【0129】
I/Oサブシステム200はデイジーチェーン相互接続の両端上でホストブリッジに接続されてリンク故障時の頑強性に備えてもよく、または処理ノードのクラスタ間での共有I/Oサブシステムを可能にしてもよい。デイジーチェーンの第1の端部でのブリッジは、マスタブリッジとして指定され、他端でのブリッジは、スレーブブリッジとして指定され得る。例示的な実施例では、サブシステム内のすべてのI/Oノードがマスタブリッジに属する。リンク故障が検出されると、故障部分の両側のI/Oノードは再びプログラムされて故障部分のそれぞれの側のホストブリッジに属するようにされる。したがって、2つのI/Oサブシステムが形成され、処理サブシステム内の処理ノードとの通信が維持され得る。代替的な実施例では、I/Oノードは、たとえリンク故障が生じていなくても、I/Oサブシステム内の2つのホストブリッジ間で割当てられ得る。このような構成は、通信トラフィックのバランスを取る助けとなり得る。
【0130】
パケットがデイジーチェーンの端部(たとえば、図19の例のI/Oノード204C)に到達し、さらにはI/Oノード204A−204Cがパケットを受入れなかった場合、I/Oノードによってチェーンの端部でエラーが生成され得る。
【0131】
一般に、I/Oサブシステム200は、ノンコヒーレント相互接続としてリンク24K−24Pを実現する。例示的な実施例では、ノンコヒーレントリンクのためのデータパケット定義は、コヒーレントリンクのためのデータパケット定義に関して図6で図示され、説明されたものと同様である。同様に、ノンコヒーレントリンクのための情報パケット定義は、(プローブフィールドがリザーブされている)図3および図18で示されたコヒーレント情報パケット定義と同様であり得る。ノンコヒーレントリンクのためのリクエストおよび応答パケット定義は、図21および図22で例示され、以下で説明される。
【0132】
例示的な実施例では、コヒーレントリンクに関して上で説明されたバーチャルチャネル定義は、ノンコヒーレントリンクにも適用可能である。バーチャルチャネル定義およびそれらのそれぞれの適用可能なリンクは、図9で示される。プローブリクエストはノンコヒーレントリンク上で用いられないかもしれず、したがって、プローブバーチャルチャネルは、ノンコヒーレントリンクのために除去され得ることが注目される。
【0133】
次に図20を参照して、コンピュータシステム10内のノンコヒーレントリンクの1つの例示的な実施例に従って採用されるパケットを例示した表210が示される。好適な他のいずれかのパケットセットおよびコマンドフィールドエンコーディングを含んだ他の実施例も可能であり、企図される。表210は、各コマンドに割当てられるコマンドエンコーディングを例示したコマンドコード(CMD)列と、ノンコヒーレントパケットの各々が割当てられるバーチャルチャネルを規定するバーチャルチャネル(Vchan)列と、コマンドを示すニーモニックを含むコマンド(Command)列と、パケット30、212、および214(ならびに、特定される場合には、データパケット36)のうちのどれが対応するコマンドのために採用されるのかを示すパケットタイプ(Packet Type)列とを含む。
【0134】
表210で示されるように、ノンコヒーレントパケットは、NOP、Wr(サイズド)、リード(サイズド)、RdResponse、TgtDone、ブロードキャスト、および同期(Sync)パケットを含み、これらは、例示的な実施例では、図7に関して説明された対応のコヒーレントパケットと同様である。しかし、ノンコヒーレントリンク内では、プローブパケットもプローブ応答パケットも発行されないことが注目される。コヒーレントリンクに関して上で説明されたように、ポステッドライトリクエストは、Wr(サイズド)リクエストパケットのポステッドビットを設定することによって、識別され得る。しかし、ノンコヒーレントファブリックでは、セットポステッドビットは、バーチャルチャネル識別子として働くだけではなく、ライトリクエストがファブリック内で応答を受信しないことも示す。つまり、コヒーレントファブリックとは異なり、TgtDone応答パケットは、ポステッドライトリクエストに応答してノンコヒーレントファブリック内で発行されない。
【0135】
ノンコヒーレントパケットはまた、フラッシュ(Flush)およびフェンスリクエストパケットを含み、これらは、以下でさらに詳細に説明される。
【0136】
次に図21を参照して、ノンコヒーレントリンク内で採用され得るリクエストパケット212の1つの実施例のブロック図が示される。リクエストパケット212は、コヒーレントリクエストパケットと同様のコマンドフィールド(CMD[5:0])を含む。さらに、任意のソースタグフィールド(SrcTag[4:0])は、コヒーレントリクエストパケットと同様に、ビット時間2内に含まれ得る。アドレス(Addr[15:8]、Addr[23:16]、Addr[31:24]、Addr[39:32])は、ビット時間4−7内に(任意で、最下位アドレスビットについてはビット時間3内に)含まれる。
【0137】
リクエストパケット212はさらに、(コヒーレント片われ(counterpart)パケットのソースノードIDではなく)ビット時間1内にユニットID(UnitID[4:0])を含む。ユニットIDは、パケットの論理ソースを識別する。たとえば、ノードが論理的に別の(separate)多数のデバイスまたは機能を含むならば、I/Oノードは多数のユニットIDを有し得る。したがって、I/Oノードは、異なるユニットIDを有するパケットを生成し、受け入れ得る。1つの実施例では、ユニットIDは5つのビットを含み得る。したがって、ユニットID0がホストブリッジに割当てられ、ユニットID31が用いられてエラーが報告されると、最大30のユニットIDが、1つのデイジーチェーン構成のI/Oサブシステム内で結合されるI/Oノード内に存在し得る。
【0138】
加えて、リクエストパケット212は、ビット時間0および1内にシーケンスID(SeqID[3:0])フィールドを含む。SeqIDフィールドを用いて、同じバーチャルチャネル内で移動しており、かつ同じユニットIDを有する2つ以上のリクエストパケットのセットがグループ分けされ、順序付けられ得る。たとえば、SeqIDフィールドが0ならば、パケットは、他のパケットに対して順序付けされない。しかし、SeqIDフィールドが0ではない値を有すると、パケットは、同じUnitIDおよびSeqIDフィールド内で整合する値を有する同じチャネル内の他のパケットに対して順序付けられる。
【0139】
さらに、リクエストパケット212は、ビット時間1内でパスポステッドライト(PassPW)ビットを含む。PassPWビットは、リクエストパケット212が、同じユニットIDから送信されるポステッドライトリクエストを渡すことができるかを示す。例示的な実施例では、PassPWビットがクリアならば、パケットは、以前に送信されたポステッドライトリクエストパケットを渡すことはできない。PassPWビットがセットされていると、パケットは、前のポステッドライトパケットを渡すことができる。リードリクエストパケットについては、コマンドフィールドは、リード応答がポステッドライトリクエストを渡し得るかを示す状態を有するビットを含み得る。そのビットの状態は、リードリクエストパケットに対応する応答パケット内のPassPWビットの状態を決定する。
【0140】
上述のように、ノンコヒーレントリクエストパケットは、フラッシュおよびフェンスリクエストを含む。フラッシュリクエストは、ソースノードによって用いられて1つ以上の以前に発行された、ポステッドライトがホストメモリで観察されたことが保証され得る。フラッシュは、フラッシュと同じI/Oストリーム内のリクエストにのみ適用され、アップストリーム方向に発行され得るのみである。その意図される機能を実行するために、フラッシュリクエストは、ノンポステッドコマンドバーチャルチャネル内を進み、ポステッドコマンドチャネル内のすべてのリクエストをその先に(たとえば、以下で説明されるPassPWビットを介して)プッシュする。したがって、フラッシュリクエストの発行および対応するTgtDone応答パケットの受信によって、以前のポステッドリクエストがコヒーレントファブリック内のそれらのデスティネーションにフラッシュされたことをソースノードが判断することが可能となる。
【0141】
フェンスリクエストは、I/Oシステム内のすべてのUnitID中に適用されるポステッドライト間でバリアを提供する。フェンスリクエストは、アップストリーム方向にのみ発行され得、ポステッドコマンドバーチャルチャネル内を進む。その意図される機能を実行するために、フェンスリクエストは、ポステッドコマンドチャネル内のすべてのポステッドリクエストをその先にプッシュする。たとえば、PassPWビットがクリアならば、フェンスパケットは、パケットのUnitIDにかかわらず、ポステッドチャネル内のいずれのパケットも渡さない。PassPWビットクリアを有する他のパケットは、UnitIDにかかわらず、フェンスパケットを渡さない。
【0142】
次に図22を参照して、ノンコヒーレントリンク内で採用され得る応答パケット214の1つの実施例のブロック図が示される。応答パケット214は、リクエストパケット212と同様のコマンド(CMD[5:0])フィールド、ユニットID(UnitID[4:0])フィールド、ソースタグ(SrcTag[4:0])フィールド、およびPassPWビットを含む。しかし、他のフィールドおよびビットも所望であれば含まれ得ることが理解されるべきである。
【0143】
次に図23を参照して、I/Oノード204Aの1つの実施例を例示するブロック図が示される。他のI/Oノード204B−204Cも同様に構成され得る。他の実施例も可能であり、企図される。図23の実施例では、I/Oノード204Aは、インターフェイスロジック18Mおよび18N、第1の組のパケットバッファ220、第2の組のパケットバッファ222、およびノードロジック224を含む。インターフェイスロジック18Mは、ライン24Kおよび24L、パケットバッファ220、およびノードロジック224に結合される。インターフェイスロジック18Nは、ライン24Mおよび24N、パケットバッファ222、およびノードロジック224に結合される。ノードロジック224はさらに、パケットバッファ220および222に結合される。
【0144】
インターフェイスロジック18Mおよび18Nは、(それぞれ)ライン24Lおよび24Mからパケットを受信し、(それぞれ)ライン24Kおよび24N上でパケットを送信するように構成される。コヒーレントリンクに関して上で説明されたインターフェイスロジックと同様に、インターフェイスロジック18Mおよび18Nは、受信されたパケットを制御経路およびデータ経路へと分離し得る。制御経路は、コマンドパケットバッファに結合され、データ経路は、データパケットバッファに結合される。代替的には、インターフェイスロジック18Mおよび18Nは、受信されたパケットを制御経路およびデータ経路へと分離しなくてもよく、代わりに、ノードロジック224が、各ビット時間に対応したCTL信号を受信し、それに従って分離を実行してもよい。コヒーレントインターフェイスと同様に、パケットバッファ220および222は、各々、ノンコヒーレントリンク内の各バーチャルチャネルのためのバッファを含む。つまり、バッファ220および222は、ノンコヒーレントリンク内で実現される3つのバーチャルチャネルに対応する、コマンドパケットのための応答バッファ(RB)、ノンポステッドコマンドバッファ(NPCB)、およびポステッドコマンドバッファ(PCB)を含む。加えて、バッファ220および222は、各バーチャルチャネルのためのデータパケットバッファ(たとえば、ポステッドコマンドデータバッファ(PCDB)、ノンポステッドコマンドデータバッファ(NPCDB)、および応答データバッファ(RDB))を含む。
【0145】
ノードロジック224は、バッファ220および222で受信されるパケットを処理し得、I/Oノード204Aによって実現された周辺機能に応答してパケットを開始し得る。図11で示される制御ロジック66と同様に、ノードロジック224は、(パケットバッファ220および222にそれぞれ対応する)コマンドパケットアクティブレジスタ226Aおよび226B、さらには(パケットバッファ220および222にそれぞれ対応する)データパケットアクティブレジスタ228Aおよび228Bを実現し得る。加えて、ノンコヒーレントリンク上の通信は、ノードIDではなくユニットIDに対応するため、ノードロジック224は、1つ以上のユニットIDレジスタ230A−230Nを含んでI/Oノード204Aに割当てられるユニットIDを記憶し得る。ユニットIDレジスタ230A−230Nの数は、そのI/Oノード内で実現されるユニットIDの数に従って、ノードごとに異なり得る。
【0146】
異なるバーチャルチャネル内のパケットはI/Oノード204A内の異なるバッファ内に記憶されるため、異なるバーチャルチャネル内のパケットは、物理的に互いと競合することはない。したがって、実質的にデッドロックのない動作が達成され得る。加えて、応答パケットが単一のバーチャルチャネルに併合され得るように、ノードロジック224は、リソースを予め割振って(コヒーレントリンクに関して上で説明されたように)応答パケットおよび応答データを処理し得る。
【0147】
ノードロジック224はさらに、I/Oノード204Aによって行なわれる周辺機能または種々のI/Oに対応するロジックを含み得る。たとえば、I/Oノード204Aは、ディスクドライブ、CD ROM、およびDVDドライブ等の記憶周辺装置を含み得る。I/Oノード204Aは、IEEE1394、イーサネット(R)、ユニバーサルシリアルバス(USB)、周辺コンポーネント相互接続(Peripheral Component Interconnect)(PCI)バス、およびモデム等の通信周辺装置を含み得る。好適ないずれかのI/O機能が、I/Oノード204A内に含まれ得る。
【0148】
次に図24を参照して、パケットを受信するための例示的なノードロジック224の一部の動作のフローチャートが示される。他の実施例も可能であり、企図される。図24で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序が用いられてもよい。加えて、ステップは、ノードロジック224内で組合せ論理を用いて並列に実行され得る。図24で示されるステップは、各インターフェイスロジック18M−18Nに対して、独立して、さらには並列に行なわれ得る。なぜならば、ビット時間は、各インターフェイスロジックから並行に受信され得るためである。
【0149】
図24で例示される実施例では、パケットは、一連のビット時間としてバッファ220および222で受信される。他の実施例は、インターフェイスロジック18M−18N内でパケットのビット時間を蓄積し、完全なパケットをバッファ220および222に提供し得るが、この場合、ビット時間でのパケットの受信を管理することに関連したステップは、省略され得る。図24では、ステップ100−112は、上で図14に関して説明された対応するステップ100−112と同じか、または同様であり得る。しかし、ノードロジック224は、図24のステップ114および116によって部分的に例示されるような、特定の追加的な順序付けルールを実現し得る。特定のコマンドパケットは、同じソースノードから送信された、ポステッドリクエストパケットを「プッシュする」ように構成され得る。言換えると、プッシュされる、ポステッドリクエストパケットは、他のパケットがそれらのデスティネーションノードに到達する前に、デスティネーションノードに到着する。
【0150】
1つの実施例では、たとえば、(PassPWビットクリアを有すると定義される)フラッシュリクエストパケット、およびそれらのPassPWビットクリアを有する他のパケットは、上述のように、ポステッドリクエストパケットをプッシュすると定義され得る。さらに、それらのSeqIDフィールド内で0ではない値を有するリクエストパケットは、同じI/Oストリーム内にあり、さらにはそれらのそれぞれのSeqIDフィールド内で整合した値を有する前のリクエストパケットをプッシュすると定義される。したがって、PassPWビットクリア、またはSeqIDフィールド内の0ではない値を有するパケットが受信されると(判定ブロック114)、ノードロジック224は、ポステッドコマンドバッファおよびコマンドバーチャルチャネル内で前のリクエストパケットを探索し得る。たとえば、ノードロジック224は、クリアPassPWビットを有するパケットと同じユニットIDを有する、ポステッドリクエストパケットを求めてポステッドコマンドバッファを探索し得る。さらに、ノードロジック224は、受信されるパケットのシーケンスIDに整合するSeqIDフィールド内の0ではない値を有するリクエストパケットを求めてコマンドバーチャルチャネルを探索し得る。ノードロジック224が前のリクエストパケットを検出すると、前のリクエストパケットのソースタグ(SrcTag)がセーブされ得る。たとえば、前のリクエストパケットのSrcTagは、リクエストパケットに割振られる同じバッファ場所に記憶され得る(ステップ116)。ノードロジック224は、対応する前のリクエストパケットが処理されるまで、リクエストパケットの処理を差し控え得る。
【0151】
次に図25を参照して、リクエストパケット(たとえば、ノンポステッドリクエストパケットまたはポステッドリクエストパケット)を処理するためのノードロジック224の1つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図25で示されるステップは、わかりやすくするためにある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、ノードロジック224内で組合せ論理を用いて並列に実行され得る。図25で示されるステップは、各インターフェイスロジック18M−18Nおよび/または各コマンドパケットバッファに対して、独立して、さらには並列に実行され得る。なぜならば、異なるインターフェイスおよび/または異なるバーチャルチャネルからのリクエストパケットは物理的に独立しているためである。代替的には、1つのリクエストパケット(または、インターフェイスロジック18M−18Nにつき1つのリクエストパケット)が、好適な公平性アルゴリズムに従った処理のために選択され得る。一般に、処理のために1つのバーチャルチャネルから選択されるパケットは、バーチャルチャネル内のパケットの順序付けルールに従うが(たとえば、同じソースから同じデスティネーションへのパケットが、順番に選択される)、所望であれば、さらには順序付けルールが順序付けから外れた選択を許容するならば、パケットは順序付けから外れて処理のために選択されてもよい。
【0152】
リクエストパケットがダウンストリームで流れるならば(ステップ125)、ノードロジック224は、リクエストパケット内のアドレスをデコードしてパケットが受入れられるベきかを判断する(ステップ126)。しかし、ダウンストリームリクエストパケットがブロードキャストならば(ステップ241)、ノードは、他の基準に関係なくパケットの受入れおよび送信の両方を行う。さらに、ノードロジック224は、リクエストパケットの処理の前に追加的なステップを実現し得る。たとえば、判定ブロック124では、ノードロジック224は、まだ処理されていない前のリクエストパケットをプッシュするようにリクエストパケットが構成されているかを判断する。上述のように、リクエストパケットが、受信され、さらには(たとえば、PassPWビットの状態またはSeqIDフィールド内の0ではない値を介して)前のリクエストパケットをプッシュするように構成されているならば、プッシュされるべきリクエストパケットのソースタグ(SrcTag)が記録される。ノードロジック224は、プッシュするリクエストパケットに対応したソースタグ(およびユニットID)を求めてコマンドバッファをスキャンすることによって、前のリクエストパケットを探索し得る。ソースタグおよびユニットIDを有する、記憶されたリクエストパケットが見つかると、プッシュするリクエストパケットの処理は、前の記憶されたリクエストパケットが処理されるまで、中断され得る。
【0153】
加えて、ノードロジック224は、パケットルーティングテーブルに従ってではなく、同じ方向(アップストリームまたはダウンストリーム)でリクエストパケットを送信するように構成される(ステップ242)。パケットがアップストリームに流れていると、パケットが、「このノード」によって受入れられることは全くなく、代わりに、それがホストブリッジに到達するまで送信される。一旦パケットが処理されると(たとえば、「このノード」によって送信されるか、または受入れられると)、パケットは対応するバッファ場所から除去され、適切であれば、関連のデータパケットはデータバッファ場所から除去されることが注目される。
【0154】
選択されるリクエストパケットが対応するデータパケットを特定するならば、種々の実施例は、たとえデータパケットがまだ受信されていなくても、リクエストパケットを処理し得ることがさらに注目される。代替的には、完全なデータパケットの到着まで、処理が遅延されてもよく、したがって、データパケットの送信が簡素化されるか、または完全に到着したデータパケットを特定する別のパケットが同じ通信リンク上で送信されることが可能となる。リクエストパケットの処理が完全なデータパケットの到着を待たない状況では、データパケットは、データパケットが最終的に完全に受信されるときに、図24に関して上で説明されたように処理され得る。
【0155】
次に図26を参照して、応答パケットを処理するためのノードロジック224の1つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図26で示されるステップは、わかりやすくするために、ある特定の順序で例示されているが、好適ないずれの順序も用いられ得る。加えて、ステップは、ノードロジック224内で組合せロジックを用いて並列に実行され得る。図26で示されるステップは、各インターフェイスロジック18M−18Nおよび/または各応答パケットバッファに対して、独立して、さらには並列に実行され得る。なぜならば、異なるインターフェイスおよび/または異なるバーチャルチャネルからのパケットは物理的に独立しているためである。
【0156】
パケットがダウンストリームに流れていると(ステップ249)、ノードロジック224は、応答パケットのUnitIDフィールドおよびユニットIDレジスタ230A−230N内に記録されるユニットIDを調べることによってパケットを受入れるべきかを判断する(ステップ144、これは、図16の対応するステップ144と同様のものである)。上述のように、ダウンストリーム応答パケット内では、UnitIDは、応答の発行を生じさせた元のリクエストパケットのソースである。しかし、応答パケットがアップストリームに流れていると、パケットは受入れられず、代わりに、それがホストブリッジに到達するまで送信される。アップストリーム応答パケット内では、UnitIDは、リクエストのターゲットノード(つまり、応答を発行するノード)である。
【0157】
図25のフローチャートと同様に、ノードロジック224は、応答パケットの処理の前に追加的なチェックを実現し得る。たとえば、判定ブロック140では、ノードブロック224は、応答パケットが、処理されていない前のリクエストパケットをプッシュするように構成されているかを判断する。上述のように、応答パケットが、受信され、さらには(たとえば、PassPWビットを介して)前のリクエストパケットをプッシュするように構成されていると、応答パケットが受信されるときにプッシュされるべきリクエストパケットのソースタグが記録される。ノードロジック224は、応答パケットに対応するソースタグ(およびユニットID)を有するリクエストパケットを求めてコマンドバッファをスキャンし得る。ソースタグおよびユニットIDを有する、記憶されたリクエストパケットが見つかると、応答パケットの処理は、前のリクエストパケットが処理されるまで、中断され得る。
【0158】
応答パケットのためのデスティネーションノードが別のノードならば、ノードロジック224は、応答パケット(および、適切ならば、対応するデータパケット)を、応答パケットが送信されているレシーバ内の応答バーチャルチャネルのための自由バッファ場所の利用可能性に従って送信する(ステップ250)。例示的な実施例では、レシーバは、パケットが既に流れていたのと同じ方向で(アップストリームまたはダウンストリームで)応答パケットが流れることを可能にするノードである。
【0159】
応答パケットのデスティネーションノードが「このノード」ならば、ノードロジック224は、存在するのであれば対応するデータパケットを、対応する応答データバッファから、応答パケットに割振られるデータバッファへと移動させるように構成される(ステップ252)。次に、ノードロジック224は、対応する応答パケットの処理を完了し、データバッファの割振りを解除する(ステップ254)。一旦応答パケットが処理されると(つまり、送信されるか、または「このノード」によって受入れられると)、応答パケットは応答バッファ場所から除去され、適切ならば、対応するデータパケットは、データバッファ場所から除去されることが注目される。
【0160】
選択される応答パケットが対応するデータパケットを特定するならば、種々の実施例は、たとえデータパケットがまだ受信されていなくても、応答パケットを処理し得ることが注目される。代替的には、処理は、データパケットの到着まで遅延されてもよく、したがって、データ送信が簡素化されるか、または完全に受信されるデータパケットを特定する別のパケットが同じリンク上で送信されることが可能となる。応答パケットの処理が遅延されていない状況では、対応するデータパケットは、データパケットが最終的に受信されるときに図24に関して上で説明されたように処理され得る。
【0161】
次に図27を参照して、ノードが結合されるリンク上でパケットを開始するためのノードロジック224の1つの実施例の動作を例示するフローチャートが図示される。他の実施例も可能であり、企図される。図27で示されるステップは、わかりやすくするために、ある特定の順序で例示されているが、好適ないずれの順序を用いてもよい。加えて、ステップは、ノードロジック224内で組合せ論理を用いて並列に実行され得る。
【0162】
図27で示されるように、ノードロジック224は、開始されるべきトランザクションによって結果としてデータが「このノード」に戻され得るかを判断する(判定ブロック260)。たとえば、「このノード」によって開始されるリードトランザクションによって、データは「このノード」に戻されるが、「このノード」によって開始されるライトトランザクションによっては、データは「このノード」に戻されない。トランザクションによって結果としてデータが「このノード」に戻され得るならば、ノードロジック224は、データバッファを割振って戻されるデータを記憶する(ステップ262)。後に、ノードロジック224はパケットを送信する(ステップ264)。
【0163】
次に図28を参照して、ノンコヒーレントファブリック内のある特定のユニットから受信される順序付けられたリクエストのペアに応答したホストブリッジ202の1つの実施例の動作を例示する表270が示される。コヒーレントファブリックそれ自体によって提供される唯一の順序付けルールは、同じソースから同じデスティネーションへと同じバーチャルチャネル内で進むパケットは、順序付けられて残されることが保証されることである。しかし、コヒーレントファブリックの分散性のために、コヒーレントファブリックに入るI/Oストリームは、多数のターゲット上で拡がり(spread)得る。したがって、すべてのオブザーバーの観点からの順序付けを保証するためには、ホストブリッジは、コヒーレントファブリックへと新しいパケットを発行する前に、前のパケットに対する応答を待つ。この様態で、ホストブリッジは、順序付けを乱すことなく後続のパケットが発行されるのに十分なほど前のパケットがコヒーレントファブリック内を進んだことを判断し得る。
【0164】
ホストブリッジは、ノンコヒーレントファブリックから来るパケットのうちのどれが順序付け要件を有するのかを判断し得る。このような判断は、パケットの各々の中のコマンドエンコーディング、UnitID、SeqID、PassPWフィールドを調べることによって、達成され得る。順序付けされていないパケットは、ホストブリッジによる特別なアクションを必要とせず、それらは、ホストブリッジがそれらを送り出し得るのと同じぐらい速く、いずれかの順序でコヒーレントファブリックへと発行され得る。対照的に、順序付けされたパケットは、表270に列挙されている種々の待機要件を有する。
【0165】
表270は、順序付けされるペアの第1のリクエストを列挙するリクエスト1列、順序付けされるペアの第2のリクエストを列挙するリクエスト2列、およびホストブリッジによって第2のリクエストが進行することが可能となり得る前に受信されなければならない応答を列挙する待機要件列を含む。
【0166】
表270内で特に指示されない限りは、参照されるパケットは、コヒーレントファブリック上にある。また、例示的な実施例では、表270内で列挙されていないリクエストの組合せは、待機要件を有さない。さらに、ホストブリッジ202がまず2つのリクエストパケット間に順序付け要件が存在すると判断する場合にのみ、表270は適用される。たとえば、2つのリクエストパケットが整合する0ではないシーケンスIDを有するならば、または第1のリクエストパケットがポステッドライトであり、第2のリクエストがPassPWビットクリアを有するならば、順序付け要件は存在し得る。
【0167】
表270の第1のエントリでは、順序付けされたメモリライトリクエストのペアは、第1のメモリライトリクエストに対応するTgtStartパケットがホストブリッジによってコヒーレントファブリック内で受信されるまで、第2のメモリライトリクエストの送信を遅延することによって、ホストブリッジにより完了される。加えて、ホストブリッジは、第1のメモリライトリクエストに応答するTgtDoneパケットが受信されるまで、第2のメモリライトリクエストに対応するSrcDoneパケットを差し控える。最終的に、ノンコヒーレントリンク上の第2のメモリライトリクエストに対応するTgtDoneパケットは(メモリライトがノンポステッドリクエストならば)、第1のメモリライトリクエストに対応するTgtDoneパケットがコヒーレントファブリックから受信されるまで、遅延される。図28の表内の他のエントリは、第1のエントリについて上で与えられた説明と同様の様態で解釈され得る。
【0168】
コヒーレントファブリック内でのポステッドコマンドバーチャルチャネルの提供に加えて、図28の表で列挙される待機要件を実現するためのホストブリッジ202の提供によって、コヒーレントファブリック内のポステッドライトリクエストのための順序付け要件が満たされ得ることが保証される。ノンコヒーレントファブリック上のポステッドライトリクエストのための順序付け要件は、上述のようなPassPWビットを用いることによって、満たされ得る。図9に関して上で説明されたように、以下の4つの要件が、I/Oサブシステム内のPCIバス上のポステッドライトに適用される。
【0169】
(i) 同じソースからのポステッドライトは、ターゲットインターフェイス上で順序付けられて残される。
【0170】
(ii) 同じソースからのリードが後に続くポステッドライトは、リードデータが戻される前に、ターゲットインターフェイス上で完了される。
【0171】
(iii) ノンポステッドライトは、同じソースからポステッドライトを渡し得ない。
【0172】
(iv) ポステッドライトは、前のポストされていない動作を渡すことが可能にされなければならない。
【0173】
要件(i)は、ポステッドライトリクエストパケットをポステッドコマンドバーチャルチャネル内に置き、さらには表270のエントリ272の待機要件を、異なるコヒーレントターゲットノードに向けられるポステッドライトリクエストに適用することによって、同じコヒーレントターゲットノードに向けられるポステッドライトリクエストに対して満たされる。要件(ii)は、表270のエントリ274の待機要件を適用することによって、満たされ得る。要件(iii)は、エントリ272の待機要件を適用することによって、満たされ得る。最終的に、要件(iv)は、ポステッドコマンドバーチャルチャネルを採用することによって、満たされ得る。要件(i)−(iv)の各々について、第2のパケット内のPassPWビットはクリアであると仮定される。それ以外の場合には、PassPWビットがセットされるならば、第2のパケットは、第1のパケットを渡すことが可能となり得る。表270内の他のエントリを用いて、ノンコヒーレントリンクから来たコヒーレントファブリック内の他のタイプのリクエストの順序付けが提供され得る。
【0174】
一旦、上述の開示を完全に理解すると、多くの変更および変形が当業者に明らかとなるであろう。前掲の請求項は、このようなすべての変更および変形を包含すると解釈されるべきであると意図される。
【0175】
この発明には種々の変形および代替の形が可能であり得るが、具体的な実施例は、図の例によって示され、ここで詳細に説明された。しかし、この発明は、開示されたある特定の形に限定されると意図されないことが理解されるべきである。逆に、この発明は、前掲の添付の請求項によって規定されるこの発明の思想および範囲内に入るすべての変形、均等物、および代替物を包含する。
【図面の簡単な説明】
【図1】複数の処理ノードを含むコンピュータ処理システムの例示的な実施例のブロック図である。
【図2】ノードを相互接続する通信リンクの例示的な実施例を示す、図1の処理ノードのうち2つのブロック図である。
【図3】処理サブシステム内で用い得る例示的なコヒーレント情報パケットの図である。
【図4】処理サブシステム内で用い得る例示的なコヒーレントリクエストパケットの図である。
【図5】処理サブシステム内で用い得る例示的なコヒーレント応答パケットの図である。
【図6】処理サブシステム内で用い得る例示的なコヒーレントデータパケットの図である。
【図7】処理サブシステム内で用い得る異なるタイプのコヒーレントパケットを一覧にしたテーブルの図である。
【図8】処理システム中の1対のバーチャルチャネルを図示するブロック図である。
【図9】1組のバーチャルチャネルおよびその適用可能なリンクの例示的な実施例を図示するテーブルの図である。
【図10】図1の処理ノードの例示的な実施例のブロック図であり、ノードがパケット処理ロジックを含む、図である。
【図11】図10のノードのパケット処理ロジックの例示的な実施例のブロック図であり、パケット処理ロジックはデータバッファプールおよび応答カウンタプールを含む、図である。
【図12】図11のデータバッファプール中の場所の例示的な実施例のブロック図である。
【図13】図11の応答カウンタプール中の場所の例示的な実施例のブロック図である。
【図14】パケットを受けるための、図10のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図15】リクエストパケットを処理するための、図10のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図16】応答パケットを処理するための、図10のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図17】パケットを開始するための、図10のパケット処理ロジックの一部の例示的な実施例の動作のフローチャートの図である。
【図18】バッファ解放フィールドを含む情報パケットの例示的な実施例を図示するブロック図である。
【図19】図1および図2に示される相互接続と同様のリンクを介して相互接続される複数のI/Oノードおよびホストブリッジを含むI/Oサブシステムの例示的な実施例のブロック図である。
【図20】ノンコヒーレントリンクのためのパケット定義の例示的な実施例を図示するテーブルの図である。
【図21】処理システムで用い得る例示的なノンコヒーレントリクエストパケットの図である。
【図22】処理システムで用い得る例示的なノンコヒーレント応答パケットの図である。
【図23】図19のI/OサブシステムのI/Oノードの例示的な実施例のブロック図であり、I/Oノードはノードロジックを含む、図である。
【図24】パケット受取りのための、図23のノードロジックの例示的な部分の動作のフローチャートの図である。
【図25】リクエストパケットを処理するための、図24のノードロジックの例示的な部分の動作のフローチャートの図である。
【図26】応答パケットを処理するための、図24のノードロジックの例示的な部分の動作のフローチャートの図である。
【図27】パケットを開始するための、図27のノードロジックの例示的な部分の動作のフローチャートの図である。
【図28】図19のホストブリッジが実現し得る例示的な順序付けルールを一覧にするテーブルの図である。
Claims (10)
- コンピュータシステム内の複数のノード間でパケットをルーティングするための方法であって、
複数のノードの第1のノード(12、204)で第1のパケットを受信するステップを含み、第1のノード(12、204)は複数のパケットバッファ(60、62、64、220、222)を含み、各パケットバッファ(60、62、64、220、222)は、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、第1のパケットは第1のバーチャルチャネル上で受信され、前記方法はさらに、
複数のパケットバッファ(60、62、64、220、222)のうちの第1のパケットバッファに第1のパケットを記憶するステップを含み、第1のパケットバッファは、第1のバーチャルチャネル上で受信されるパケットのために確保されている、方法。 - 第1のノード(12、204)で第2のパケットを受信するステップと、
第2のパケットが受信される第2のバーチャルチャネルを決定するステップと、
第2のバーチャルチャネルの決定に基づいて、複数のパケットバッファ(60、62、64、220、222)のうちの第2のパケットバッファに第2のパケットを記憶するステップとをさらに含む、請求項1に記載の方法。 - 請求項2に記載の方法であって、
第2のパケットのデスティネーションを決定するステップをさらに含み、
デスティネーションが第1のノード(12、204)以外の第2のノード(12、204)であって、第2のノードは第2の複数のパケットバッファ(60、62、64、220、222)を含むならば、第2の複数のパケットバッファの各々は、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、
第2のバーチャルチャネルに割振られる第2の複数のパケットバッファ(60、62、64、220、222)のうちの1つの利用可能性を判断するステップと、
判断された利用可能性に基づいて、第2のパケットを第2のノード(12、204)に送信するステップとをさらに含む、請求項2に記載の方法。 - 第2のパケットがポステッドリクエストパケットをプッシュするように構成されているかを判断するステップをさらに含み、その場合には、
複数のパケットバッファ(60、62、64、220、222)のうちのポステッドコマンドバッファ(60A、62A、64A、220、222)内で、第2のパケットを生成した同じソースによって生成される、記憶されたポステッドリクエストパケットを見つけるステップと、
見つけられた、記憶されたポステッドリクエストパケットを第2のノードに、第2のパケットの処理の前に送信するステップとを含む、請求項2に記載の方法。 - コンピュータシステムであって、
複数のバーチャルチャネル上でパケットを送信するように構成される第1のノード(12、204)と、
複数のバーチャルチャネル上で第1のノード(12、204)からパケットを受信するように結合される第2のノード(12、204)とを含み、第2のノードは複数のパケットバッファ(60、62、64、220、222)を含み、各パケットバッファはある特定のバーチャルチャネルに割振られ、第2のノード(12、204)は、それぞれのパケットが受信される特定のバーチャルチャネルに割振られるパケットバッファ(60、62、64、220、222)のうちの1つに受信されるパケットの各々を記憶するように構成される、コンピュータシステム。 - 第1のノード(12、204)は、ポステッドコマンドバーチャルチャネル上でポステッドリクエストパケットを送信するように構成され、第2のノード(12、204)は、第1のパケットをポステッドコマンドパケットバッファ(60A、62A、64A、220、222)に記憶するように構成され、第1のノード(12、204)は、ポステッドコマンドバーチャルチャネル以外の第2のバーチャルチャネル上で第2のノード(12、204)へと第2のパケットを送信するように構成され、第2のノードは、ポステッドコマンドパケットバッファ(60A、62A、64A、220、222)以外のパケットバッファ(60、62、64、220、222)に第2のパケットを記憶するように構成される、請求項5に記載のコンピュータシステム。
- 複数のバーチャルチャネル上で第2のノード(12、204)からパケットを受信するように結合される第3のノード(12、204)をさらに含み、第3のノード(12、204)は第2の複数のパケットバッファ(60、62、64、220、222)を含み、第2の複数のパケットバッファの各々は、ある特定のバーチャルチャネルに割振られ、第2のノード(12、204)は、第2のバーチャルチャネルに割振られる第2の複数のパケットバッファ(60、62、64、220、222)のうちの1つの利用可能性に基づいて、第2のパケットを第3のノード(12、204)に送信するように構成される、請求項6に記載のコンピュータシステム。
- 第2のパケットは、ポステッドリクエストパケットをプッシュするように構成され、第2のノード(12、204)は、第2のパケットを生成した同じソースによって生成される、記憶された、ポステッドリクエストパケットを求めてポステッドコマンドパケットバッファ(60A、62A、64A、220、222)を探索し、さらには第2のパケットの処理の前に、記憶された、ポステッドリクエストパケットを第3のノード(12、204)に送信するように構成される、請求項6に記載のコンピュータシステム。
- コンピュータシステム内の複数のノード間でパケットをルーティングするための方法であって、
複数のノードのうちの第1のノード(12、204)内でポステッドリクエストパケットを生成するステップと、
ポステッドリクエストパケットを含む複数のパケットを第1のノード(12、204)から複数のバーチャルチャネルを介して送信するステップとを含み、複数のパケットの各々はある特定のバーチャルチャネルを介して送信され、ポステッドリクエストパケットは、ポステッドリクエストパケットのために確保されたポステッドコマンドバーチャルチャネル上で第2のノード(12、204)へと送信され、ポステッドリクエストパケットは、他のバーチャルチャネル上で送信される他のパケットから独立して送信され、
第2のノード(12、204)は、ポステッドコマンドパケットバッファ(60A、62A、64A、220、222)を含む複数のパケットバッファ(60、62、64、220、222)を含み、各パケットバッファは、複数のバーチャルチャネルのうちのある特定のバーチャルチャネルに割振られ、第2のノード(12、204)への第2のパケットの送信は、ポステッドコマンドパケットバッファ(60A、62A、64A、220、222)の利用可能性に依存する、方法。 - 請求項9に記載の方法であって、第1のノード(12、204)は、複数のバーチャルチャネル間で割振られる複数のパケットバッファ(60、62、64、220、222)を含み、前記方法は、
第1のノード(12、204)内で第2のパケットを生成するステップを含み、第2のパケットは、ターゲットノード(12、204)からの応答パケットを生成するように構成され、前記方法はさらに、
パケットバッファ(60、62、64、220、222)のうちの1つを割振って応答パケットを受信するステップを含み、割振られたパケットバッファは、複数のバーチャルチャネルのうちの1つである応答バーチャルチャネルに割振られ、前記方法はさらに、
第2のパケットをターゲットノード(12、204)に送信するステップを含む、請求項9に記載の方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/640,602 US6950438B1 (en) | 1999-09-17 | 2000-08-17 | System and method for implementing a separate virtual channel for posted requests in a multiprocessor computer system |
US09/640,602 | 2000-08-17 | ||
PCT/US2001/023733 WO2002015470A2 (en) | 2000-08-17 | 2001-07-27 | System and method for separate virtual channels for posted requests in a multiprocessor system |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2004506986A true JP2004506986A (ja) | 2004-03-04 |
JP2004506986A5 JP2004506986A5 (ja) | 2008-08-28 |
JP4906226B2 JP4906226B2 (ja) | 2012-03-28 |
Family
ID=24568914
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002520472A Expired - Lifetime JP4906226B2 (ja) | 2000-08-17 | 2001-07-27 | マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 |
Country Status (6)
Country | Link |
---|---|
EP (1) | EP1314094B1 (ja) |
JP (1) | JP4906226B2 (ja) |
AU (1) | AU2001280857A1 (ja) |
DE (1) | DE60109940T2 (ja) |
TW (1) | TW521189B (ja) |
WO (1) | WO2002015470A2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4926947B2 (ja) * | 2004-04-27 | 2012-05-09 | エヌヴィディア コーポレイション | システムメモリへのgpuのレンダリング |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7003615B2 (en) * | 2002-04-22 | 2006-02-21 | Broadcom Corporation | Tracking a non-posted writes in a system using a storage location to store a write response indicator when the non-posted write has reached a target device |
US7194566B2 (en) * | 2002-05-03 | 2007-03-20 | Sonics, Inc. | Communication system and method with configurable posting points |
US7165131B2 (en) | 2004-04-27 | 2007-01-16 | Intel Corporation | Separating transactions into different virtual channels |
US7702835B2 (en) * | 2005-02-03 | 2010-04-20 | Oracle America, Inc. | Tagged interrupt forwarding |
US7945719B2 (en) * | 2006-09-20 | 2011-05-17 | Intel Corporation | Controller link for manageability engine |
US7861024B2 (en) * | 2008-09-30 | 2010-12-28 | Intel Corporation | Providing a set aside mechanism for posted interrupt transactions |
US8392667B2 (en) | 2008-12-12 | 2013-03-05 | Nvidia Corporation | Deadlock avoidance by marking CPU traffic as special |
US9639490B2 (en) | 2011-11-29 | 2017-05-02 | Intel Corporation | Ring protocol for low latency interconnect switch |
US9910807B2 (en) | 2011-11-29 | 2018-03-06 | Intel Corporation | Ring protocol for low latency interconnect switch |
DE112014006490T5 (de) | 2014-03-20 | 2016-12-08 | Intel Corporation | Verfahren, Vorrichtung und System zur Regelung von Leistung ungenutzter Hardware einer Linkschnittstelle |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08185380A (ja) * | 1994-12-28 | 1996-07-16 | Hitachi Ltd | 並列計算機 |
JP2000067023A (ja) * | 1998-05-08 | 2000-03-03 | Fujitsu Ltd | ネットワ―ク通信におけるデッドロックを回避するためのコンピュ―タア―キテクチャ |
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 |
US6094686A (en) * | 1997-10-24 | 2000-07-25 | Compaq Computer Corporation | Multi-processor system for transferring data without incurring deadlock using hierarchical virtual channels |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06509896A (ja) * | 1992-05-12 | 1994-11-02 | セイコーエプソン株式会社 | スケーラブル・コプロセッサ |
-
2001
- 2001-07-27 JP JP2002520472A patent/JP4906226B2/ja not_active Expired - Lifetime
- 2001-07-27 EP EP01959284A patent/EP1314094B1/en not_active Expired - Lifetime
- 2001-07-27 DE DE60109940T patent/DE60109940T2/de not_active Expired - Lifetime
- 2001-07-27 AU AU2001280857A patent/AU2001280857A1/en not_active Abandoned
- 2001-07-27 WO PCT/US2001/023733 patent/WO2002015470A2/en active IP Right Grant
- 2001-08-17 TW TW90120192A patent/TW521189B/zh not_active IP Right Cessation
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08185380A (ja) * | 1994-12-28 | 1996-07-16 | Hitachi Ltd | 並列計算機 |
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 |
JP2000508094A (ja) * | 1995-10-31 | 2000-06-27 | クレイ・リサーチ・インコーポレイテッド | マルチプロセッシングシステムにおける仮想メンテナンスネットワーク |
US6094686A (en) * | 1997-10-24 | 2000-07-25 | Compaq Computer Corporation | Multi-processor system for transferring data without incurring deadlock using hierarchical virtual channels |
JP2000067023A (ja) * | 1998-05-08 | 2000-03-03 | Fujitsu Ltd | ネットワ―ク通信におけるデッドロックを回避するためのコンピュ―タア―キテクチャ |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4926947B2 (ja) * | 2004-04-27 | 2012-05-09 | エヌヴィディア コーポレイション | システムメモリへのgpuのレンダリング |
Also Published As
Publication number | Publication date |
---|---|
EP1314094A2 (en) | 2003-05-28 |
DE60109940D1 (de) | 2005-05-12 |
AU2001280857A1 (en) | 2002-02-25 |
EP1314094B1 (en) | 2005-04-06 |
DE60109940T2 (de) | 2006-02-09 |
JP4906226B2 (ja) | 2012-03-28 |
WO2002015470A3 (en) | 2003-02-27 |
WO2002015470A2 (en) | 2002-02-21 |
TW521189B (en) | 2003-02-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6950438B1 (en) | System and method for implementing a separate virtual channel for posted requests in a multiprocessor computer system | |
JP4410967B2 (ja) | デッドロックのないコンピュータシステム動作のためのバーチャルチャネルおよび対応するバッファ割当て | |
US6888843B2 (en) | Response virtual channel for handling all responses | |
US6721813B2 (en) | Computer system implementing a system and method for tracking the progress of posted write transactions | |
US6557048B1 (en) | Computer system implementing a system and method for ordering input/output (IO) memory operations within a coherent portion thereof | |
US7069361B2 (en) | System and method of maintaining coherency in a distributed communication system | |
US7620694B2 (en) | Early issue of transaction ID | |
US6948035B2 (en) | Data pend mechanism | |
JP4700773B2 (ja) | スイッチをベースとするマルチプロセッサシステムに使用するための順序サポート機構 | |
US7953936B2 (en) | Hiding conflict, coherence completion and transaction ID elements of a coherence protocol | |
US7269695B2 (en) | Ambiguous virtual channels | |
TW472195B (en) | Method and apparatus for achieving correct order among bus memory transactions in a physically distributed SMP system | |
EP0911736A1 (en) | Low occupancy protocol for managing concurrent transactions with dependencies | |
KR100387541B1 (ko) | 멀티프로세서 시스템에서 캐쉬 코히어런시 유지 방법, 멀티프로세서 시스템 및 노드 제어기 | |
JP2021522611A (ja) | I/oマスタとcpuとの間の最適化されたデータ共有を可能にするための順序付けられた書き込みスタッシュの高性能なストリーミング | |
JP4906226B2 (ja) | マルチプロセッサコンピュータシステムにおいて、ポストされたリクエストのための別個のバーチャルチャネルを実現するためのシステムおよび方法 | |
US6714994B1 (en) | Host bridge translating non-coherent packets from non-coherent link to coherent packets on conherent link and vice versa | |
US6757793B1 (en) | Reducing probe traffic in multiprocessor systems using a victim record table | |
EP1363188B1 (en) | Load-linked/store conditional mechanism in a cc-numa (cache-coherent nonuniform memory access) system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080711 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080711 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110629 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110830 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111130 |
|
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: 20111220 |
|
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: 20120110 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150120 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4906226 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
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 |