<目 次>
1.システム構成
2.CPUリードアクセス時のキャッシュコヒーレンス
3.CPUライトアクセス時のキャッシュコヒーレンス
4.キャッシュユニットのアクセス競合処理
5.コピーバックの書込所有権
6.システム共通バス
(1)バス構成
(2)バスアビトレーション動作
(3)バス転送シーケンス
(4)バス間転送
(5)バスコマンド
7.第2ディレクトリメモリ
8.その他
1.システム構成
図2は本発明のキャッシュコヒーレンス装置が適用されるマルチプロセッサシステムのブロック図である。このシステムは、少なくとも1つのプロセッサエレメントをもつプロセッサ群として例えば5つのプロセッサモジュール10−1〜10−5を有し、プロセッサモジュール10−1〜10−5を2本のシステムバス(第2共通バス)12−1,12−2を介してお互いに接続している。
プロセッサモジュール10−1〜10−5は、図3のプロセッサモジュール10−1に代表して示すように、例えば4つのプロセッサエレメント14−1〜14−4を有し、スヌープバス22を介してお互いに接続している。プロセッサエレメント14−1〜14−4のそれぞれは、プロセッサ16−1〜16−4、キャッシュユニット18−1〜18−4およびスヌープユニット20−1〜20−4を備える。
メモリモジュール25は、スヌープバス22に接続されると同時に、他のポートよりシステムバス12−1,12−2に接続される。メモリモジュール25はプロトコル管理ユニット24、メモリ管理ユニット26およびモジュール接続ユニット32を備える。プロトコル管理ユニット24は、システムバス12−1,12−2と内部のスヌープバス22との間のプロトコル変換を行う。バス接続ユニット32はメモリモジュール25とシステムバス12−1,12−2の間のバスアクセスを行う。
メモリ管理ユニット26には、主記憶として機能するローカルストレージ28と、プロセッサモジュール間でのキャッシュコヒーレンスの実現に使用されるディレクトリメモリ30が接続される。
スヌープユニット22−1〜22−4は、スヌープバス22で特定のマシンサイクルに同期させて複数のキャッシュユニット18−1〜18−4をスヌープするスヌーププロトコルに従って、主記憶としてのローカルストレージ28とキャッシュユニット18−1〜18−4の間のキャッシュコヒーレンスを実現する。即ち、スヌープユニット22−1〜22−4は、内部コヒーレンス処理部として機能する。
他のプロセッサモジュールとの間のキャッシュコヒーレンスを実現する外部コヒーレンス処理部としての機能は、メモリ管理ユニット26に設けたキャッシュ変換部80により行われる。キャッシュ変換部80は、システムバス12−1,12−2を使用した他のプロセッサモジュールとの間のやり取りを通じ、ディレクトリメモリ30の参照に基づき、プロセッサモジュール間でのキャッシュコヒーレンスを実現する。
プロセッサエレメント14−1〜14−4は、図4のプロセッサエレメント14−1に代表して示すように、CPU回路16−1には1次キャッシュ36をもつCPU34が設けられ、CPU34の外部には2次キャッシュ38が接続される。2次キャッシュ38の制御部として2次キャッシュ制御モジュール35が設けられ、2次キャッシュ制御モジュール35にはタグメモリ40が接続される。CPU34の1次キャッシュ36はライトスルーで制御され、2次キャッシュ38はコピーバックで制御される。
2次キャッシュ制御モジュール35は、2次キャッシュ38のデータのアドレスと、そのエントリのキャッシュ状態を示す情報を、タグメモリ40に登録している。ここで2次キャッシュ38は、図5に示すように、キャッシュデータを256バイト他印のデータとして登録している。このためキャッシュ制御モジュール35は、256バイトのアドレス単位でキャッシュ登録を管理する。この2次キャッシュ38上の256バイト単位のデータをキャッシュライン100という。
したがって、タグメモリ40の中には256バイト単位のキャッシュライン100のアドレスが保持されている。更に本発明にあっては、256バイトのキャッシュライン100を64バイト単位のサブライン102−1〜102−4に分割して、サブライン102−1〜102−4ごとにキャッシュ状態を保持している。
2次キャッシュ38は常にCPU34の1次キャッシュ36を包含するように制御される。スヌープバス22で接続されている例えば図3に示す4つのプロセッサエレメント14−1〜14−4における各キャッシュユニット18−1〜18−4間でのデータのコヒーレンスを保証するため、スヌープバス22によって2次キャッシュ38がスヌープされる。
スヌープバス22はパケットプロトコルによるバスで、2次キャッシュ38のスヌープを行うための機構としてスヌープ送受信ユニット42、スヌープバッファ44、コピーバックバッファ46およびプロセッサアクセスユニット48を有する。スヌープバス22には各種のスヌープコマンドが準備されている。スヌープバスはパケットプロトコルであるため、複数のアクセスを同時に進行させることができる。
2次キャッシュ38のスヌープは、スヌープバス22に接続されている各プロセッサエレメント14−1〜14−4の2次キャッシュ制御モジュール35で同時に行われ、その結果が同時にスヌープバス22上のプロセッサエレメント固有のキャッシュ状態信号に反映される。このキャッシュ状態信号は、スヌープバスに接続している全てのプロセッサエレメント14−1〜14−4とメモリモジュール25で参照される。
メモリモジュール25側のスヌープバス22に対するユニットとしては、空間識別ユニット50、スヌープ送受信ユニット52およびスヌープバス送信ユニット60が設けられている。プロセッサエレメント14−1の2次キャッシュ制御モジュール35がキャッシュ状態信号によってキャッシュ状態を表示すると同様に、メモリモジュール25に設けているメモリ管理ユニット26も、主記憶を分割配置したローカルストレージ28の状態を表示するため、メモリ状態信号を持っている。このメモリ状態信号も、スヌープバス22内の全ての2次キャッシュ制御モジュール35に供給される。
このようなスヌープバス22上における2次キャッシュ38に関するキャッシュ状態信号と、メモリモジュール25に接続したローカルストレージ28のメモリ状態信号の内容から、プロセッサエレメント14−1〜14−4に設けた2次キャッシュ制御モジュール35のそれぞれは、CPU34のアクセスに対し応答を行うプロセッサエレメントの判定、アクセス対象となったキャッシュデータの最新値を書込権の所有状態で持っている所謂オーナーの決定、各種のスヌープコマンドの成否を判定する。
更に、タグメモリ40に保持している2次キャッシュ38のキャッシュ状態の変更を必要に応じて行う。更に、1次キャッシュ36の無効化や2次キャッシュ38からのデータの応答を伴う場合もある。このようなスヌープバス22による一連の動作はパイプラインで制御される。
2次キャッシュ38のキャッシュ状態信号による表示は、ビジー、ミス、クリーン、ダーティ、エラーの表示がある。ビジー表示は、受信コマンドが処理資源の枯渇で処理できない場合あるいはプロトコル上矛盾をきたすタイミングのときに表示される。ミス、クリーンおよびダーティ表示は、2次キャッシュ38のタグメモリ40のスヌープ結果である。
即ち、ミス表示は、スヌープコマンドのアドレスで2次キャッシュ38をスヌープした結果、そのアドレスのデータを2次キャッシュ38で保持していないミスヒット検出の際に表示される。クリーン表示は、2次キャッシュ38をスヌープした結果、ローカルストレージ28の内容と同じデータを2次キャッシュ38内に保持している場合と、ローカルストレージ28の内容に対し変更が加えられたデータを2次キャッシュ38内に保持している場合である。
更にダーティ表示は、2次キャッシュ38をスヌープした結果、ローカルストレージ28の内容に対し変更が加えられた最新データを2次キャッシュ38内に保持している場合であり、ローカルストレージ28へのオーナーによる反映を行う責任を負っていることから、この状態を書込権を所有しているオーナーと呼ぶ。このようにプロセッサエレメント14−1〜14−4間は、スヌープバス22を用いたスヌープ方式によりキャッシュコヒーレンスが保たれる。
次にメモリモジュール25側を説明する。メモリモジュール25にはメモリ管理ユニット26が設けられ、メモリ管理ユニット26にメモリバス66を介してローカルストレージ28を接続し、また専用線を介してディレクトリメモリ30を接続している。ローカルストレージ28は4本のメモリバス66ごとに、メモリアクセスユニット68−1〜68−4と主記憶素子としてのSRAM70−1〜70−4を接続している。
メモリバス66は32ビット幅のバスであり、2つのバスを同時にアクセスすることで、キャッシュラインにおけるサブラインの64ビット幅に一致する1ワードのデータのアクセスを行う。ローカルストレージ28は、4つのメモリバス66で4グループに分けられており、例えばメモリアクセスユニット68−1,68−2の2グループで1ワードのアクセスを行い、メモリアクセスユニット68−3と68−4で1ワードのアクセスを行うインターリーブ方式でアクセス可能としている。
メモリモジュール25は、空間識別ユニット50により、メモリユニット26により接続したローカルストレージ28のメモリ空間を全てのPM10−1〜10−5から参照可能な物理空間にマッピングすることができる。図6は図4の空間識別ユニット50のマッピング機能を示す。まずプロセッサエレメント14−1に設けたCPU34のCPU物理アドレス空間86は、例えば64GB(ギガバイト)のアドレス空間をもつ。
このうち先頭の0〜4GBの領域を、CPUで使用する制御レジスタ空間88に割り当てている。また最後の60〜64GBの領域を、CPUのROM空間92に割り当てている。残り4〜60GBの56GB幅の領域は、PM10−1〜10−5に設けている全てのCPU34でアクセス可能な共有空間90としている。CPUで任意の36ビット物理アドレス94を指定したCPUアクセス(読出アクセスまたは書込アクセス)が発生すると、この36ビット物理アドレス94はスヌープコマンドによってスヌープバス22を経由して、メモリ制御モジュール25の空間識別ユニット50に送られる。
勿論、空間識別ユニット50にスヌープバス22を介して送られるのは、スヌープバス22で接続しているプロセッサエレメント14−1〜14−4のキャッシュ上に、アクセス対象となった物理アドレス94のキャッシュラインが存在しない場合である。
空間識別ユニット50は、制御テーブル95を保持している。制御テーブル95には共有空間90のアドレス4GBから60GBのエントリが設けられ、このアドレスによるエントリに対応してID領域を設けている。対応ID領域には、共有空間90のアドレスが割り当てられたプロセッサモジュールを示す情報としてユニットIDが登録されている。このユニットIDは、物理的には、図2のシステムバス12−1,12−2にプロセッサモジュールを接続することのできるスロット番号を示している。
この例にあっては、4GBから24GBのアドレスに対応してユニットID#00〜#07を登録している。対応ID領域には、ユニットIDに加えてプロセッサモジュールの実装と未実装を示す情報も登録されている。この例では、12〜16GBの物理アドレスをもつユニットID=#02のプロセッサモジュールは未実装となっていることがわかる。またユニットID=#00〜#03の4つについては4GB幅のアドレス領域が割り当てられているが、ユニットID=#04〜#03の4つにプロセッサモジュールについては1GB幅のアドレスが割り当てられている。
更に、制御テーブル95の対応ID領域には自ホーム情報も格納されている。自ホーム情報とは、CPUアクセスで発行された36ビット物理アドレス94がプロセッサモジュール自身に内蔵したローカルストレージのアドレス空間に存在することを意味する。
このような空間識別ユニット50に対するスヌープバス22からの36ビット物理アドレス94によるアクセスで、生成情報としてホーム情報96、ユニットID98、36ビット物理アドレス94が生成される。ホーム情報96は、アクセスされた物理アドレス94が自ホームか否か、即ち物理アドレス94がアクセスを起こしたプロセッサモジュール自身に存在するか否かを表わす。
ユニットID98は、物理アドレス94が存在するプロセッサモジュールを示す。具体例を説明すると、次のようになる。CPUアクセスにより36ビット物理アドレス94として、16進表示でX´4.D000.0000´が発生したとする。この場合、空間識別ユニット50の制御テーブル95のエントリで対応IDエリアからユニットID=#03が生成され、右側の破線の枠に示すように、ホーム情報96としてPM自身がホームでないことを示す「not Home」、ユニットID=#03、物理アドレス94であるX´4.D000.0000´を生成する。
再び図4のメモリモジュール25を参照するに、メモリモジュール25はスヌープバス22を通してプロセッサエレメント14−1のCPU34からアクセスされ、またシステムバス12−1(12−2を含む)を通して、他のプロセッサモジュール10−2〜10−5に設けているCPU34からもアクセスされる。
プロセッサモジュール10−1内に設けたプロセッサエレメント14−1〜14−4のキャッシュ間におけるキャッシュコヒーレンスはスヌープバス22を使用して実現されているのに対し、プロセッサモジュール10−1〜10−5間にあっては、システムバス12−1,12−2を使用したディレクトリ方式でキャッシュコヒーレンスを保っている。このディレクトリ方式によるキャッシュコヒーレンスを実現するため、ディレクトリメモリ32には256バイトのキャッシュライン単位に1エントリが記憶されている。
このディレクトリエントリは、CPUアクセスで発生した36ビット物理アドレスで選択され、キャッシュラインの状態を表示している。このディレクトリエントリにおけるキャッシュラインの状態表示には、ダーティ、シェアおよびインバリッドの状態がある。
ダーティとは、ある2次キャッシュ38上のキャッシュラインが書き替えられて最新データとなっており、キャッシュラインのコピー元となるローカルストレージ28上には旧いデータしかなく、書き替えたプロセッサエレメントが最新データを所有していることを意味する。
シェアとは、キャッシュラインのデータがプロセッサモジュールによって参照されたことを示し、ローカルストレージ28上のデータと同一のデータが2次キャッシュ38に同時に存在している可能性を示す。
更にインバリッドとは、キャッシュラインが、どのプロセッサモジュールからも参照されず、また書き替えられていない状態を示す。
更に、あるキャッシュラインがダーティの場合、書き替えられた最新データをもつプロセッサモジュールの識別情報がメモリ管理ユニット26に保持される。またキャッシュラインがシェアの場合にも、ローカルストレージ28のデータのコピーをもつプロセッサモジュールの識別情報がメモリ管理ユニット26に保持される。
図7は、図4のメモリモジュール25に設けたメモリ管理ユニット26の詳細である。図7において、メモリ管理ユニット26には、バスアービタ74、メモリバス60を介してローカルストレージ28を接続したメモリバス制御ユニット76、専用線でディレクトリメモリ30を接続したディレクトリ制御ユニット78が設けられる。
またメモリ管理ユニット26には、プロセッサモジュール間をディレクトリ方式を使ってキャッシュコヒーレンスを保つため、キャッシュ変換部80が設けられ、ローカルステートマシン81、ホームステートマシン82およびリモートステートマシン83を内蔵している。
本発明のディレクトリ方式を使用したプロセッサモジュール間のキャッシュコヒーレンスの制御にあっては、アクセスを起動したプロセッサモジュールをローカルと呼び、アクセスしたアドレスをローカルストレージにもっているプロセッサモジュールをホームと呼ぶ。また、アクセスしたローカルストレージのアドレスがダーティ状態、即ちローカルストレージのアドレスに旧いデータしかなく他のプロセッサモジュールのキャッシュ上で最新データをキャッシュ上に所有しているプロセッサエレメントが属しているプロセッサモジュールをリモートと呼ぶ。
このようなプロセッサモジュールのローカル、ホームおよびリモートの各ステートは、キャッシュ変換部80に設けたローカルステートマシン80、ホームステートマシン82およびリモートステートマシン84の処理動作で実現される。
これら3つのステートマシン81,82,83に対応し、図4のメモリモジュール25には、バスアービタ74を経由して、それぞれのステートマシンの処理対象となるコマンドおよびデータを保持するためのバッファキューが設けられている。即ち、ローカルステートマシン80に対応してローカルアクセスバッファキュー54が設けられる。
ローカルアクセスバッファキュー54には、空間識別ユニット50で生成された図6の生成情報であるホーム情報Home、ユニットIDおよび36ビット物理アドレスが格納される。更に、ローカルアクセスバッファキュー54に対してはスヌープ送受信ユニット52より応答割込みINT が与えられ、またローカルアクセスバッファキュー54が一杯になると、フル状態を示す情報Fullをスヌープ送受信ユニット52に返している。
ホームステートマシン82に対応しては、メモリモジュール25にホームアクセスバッファキュー56が設けられる。ホームアクセスバッファキュー56には、システムバス12−1,12−2を使用して発行されたローカルとなったプロセッサモジュールからのアクセスコマンド、所謂ホームコマンドが格納される。リモートステートマシン84に対応しては、リモートアクセスバッファキュー58が設けられる。リモートアクセスバッファキュー58には、ホームとなったプロセッサモジュールからシステムバス12−1,12−2を使用して発行されたアクセスコマンド、所謂リモートコマンドが格納される。
ローカルアクセスバッファキュー54に格納するローカルコマンドおよびホームアクセスバッファキュー56に格納するホームコマンドについては、メモリ管理ユニット26に設けているローカルステートマシン80およびホームステートマシン82のそれぞれでローカルストレージ28のアクセスを伴うが、リモートアクセスバッファキュー58のリモートコマンドはプロセッサエレメント14−1の2次キャッシュ38上のキャッシュラインを対象とするアクセスであるため、スヌープバス送信ユニット60によって直接、スヌープバス22に接続されている。
次に、図7のメモリ管理ユニット26に設けたディレクトリ制御ユニット78および専用線で接続したディレクトリメモリ30の内容を説明する。
図8は、メモリ管理ユニット26に設けたディレクトリ制御ユニット78に設けられるディレクトリエントリレジスタ104の内容であり、このディレクトリエントリレジスタ104の内容がディレクトリメモリ30に格納されたキャッシュラインごとのディレクトリエントリの読出結果である。したがってディレクトリエントリレジスタ104の内容は、これ即ちディレクトリメモリ30に記憶されたディレクトリエントリデータそのものの説明となる。
ディレクトリエントリレジスタ104は、下位8ビットにシェアードマップビット領域106を割り当てている。このシェアードマップビット領域106は、プロセッサモジュール内の主記憶であるローカルストレージ28のキャッシュラインに対応するデータが参照されて、いずれのプロセッサモジュールの2次キャッシュ上に存在するかを示すビットである。
このシェアードマップビット領域106に対しては、図9に示すシェアードマップビット対応レジスタ112が組み合わされ、更に、シェアードマップビット対応レジスタ112には図10のプロセッサモジュール構成レジスタ114が組み合わされる。
ディレクトリエントリレジスタ104のシェアードマップビット領域106はビットS0〜S7であり、このビットS0〜S7を1にセットすることで、シェアードマップビット対応レジスタ112で示されるプロセッサモジュール上にキャッシュラインのデータがシェア状態で存在することを示す。
シェアードマップビット対応レジスタ112は例えば16台のプロセッサモジュールのユニットID=#00〜#15に対応するマップビット対応エリアをもっている。これに対しシェアードマップビット領域106は、S0〜S7の8ビットと半分しかない。このため、シェアードマップビット対応レジスタ112にシェアードマップビット領域106のシェアードマップビットを重複して格納することで、シェアードマップビットを複数のプロセッサモジュールについて表現することができ、ディレクトリエントリレジスタ104のビット低減を実現している。
更に、シェアードマップビット領域106に格納するシェアードマップビットS0〜S7は、2次キャッシュ上では256バイトのキャッシュラインを4分割した64バイトのキャッシュサブラインごとに保持されている。これに対しシェアードマップビットは1ビットしかないことから、4つのキャッシュサブラインのシェア状態をORによって表わしている。
この4つのサブラインのORによるシェアードマップビットの表現は、2次キャッシュのキャッシュコヒーレンスがスヌープ方式で実現されているため、シェア状態のキャッシュラインが存在するプロセッサエレメントを意識することなくアクセスでき、複数のサブラインのOR表現が可能となっている。
図9のシェアードマップビット対応レジスタ112に対応して設けた図1010のプロセッサモジュール構成レジスタ114には、プロセッサモジュール実装ビット領域116とバスIDビット領域118が設けられている。バスIDビット領域118にはシステムバス12−1,12−2に分けたバスIDが格納されている。各システムバス12−1,12−2は16個のスロットをもっている。したがって最大16台のプロセッサモジュールを実装することができる。
プロセッサモジュール実装ビット領域116はユニットIDと同じスロット番号#00〜#15に1対1に対応したビット領域をもっており、実装状態でビット1がセットされ、未実装状態でビット0にリセットされている。
図11は、ディレクトリエントリレジスタ104、シェアードマップビット対応レジスタ112およびプロセッサモジュール構成レジスタ114の具体的な対応関係を示している。まずプロセッサモジュール構成レジスタ114はプロセッサモジュール実装ビット領域116のみを示しており、ビット1にセットされたユニットIDが実装されたプロセッサモジュールを示している。
この例ではユニットID=#00,#02,#05,#06,#08,#10,#11,#13にプロセッサモジュールが実装されて、それ以外は未実装となっている。プロセッサモジュール構成レジスタ114の各ビットは、シェアードマップビット対応レジスタ112に1対1に対応している。
あるプロセッサモジュールのCPUアクセスで、あるプロセッサモジュールの主記億となるローカルストレージのキャッシュラインが参照されて、そのコピーがキャッシュ上に存在するシェア状態が起きると、そのキャッシュラインのディレクトリエントリデータのシェアードマップビット領域106の空きビットが1にセットされ、同時にシェアードマップビット対応レジスタ112のコピーデータがシェア状態で存在するプロセッサモジュールのレジスタ領域、シェアードマップビット領域106のビット1を示すインデックス情報が格納される。
例えば、シェアードマップビットS6については、シェアードマップビット対応レジスタ112のユニットID=#06と#10に対応したエリアに、それぞれS6を格納している。これによって、シェアードマップビットS6はユニットID=#06および#10の2つのプロセッサモジュールに参照され、それぞれキャッシュ上でシェア状態にあることを表わしている。
再び図8のディレクトリエントリレジスタ104を参照するに、シェアードマップビット領域106に続いてはダーティサブラインビット領域108が設けられている。ダーティサブラインビット領域108は256バイトのキャッシュラインを分割した4つのサブラインに対応してビットD0〜D3が割り当てられている。
このダーティサブラインビットD0〜D3は、ビット1にセットすることで、システム内のいずれかのプロセッサモジュールのキャッシュ上に、主記憶としてのローカルストレージ28の旧いデータに対し、書き替えられた最新データが存在することを表わしている。また、ダーティサブラインビット領域108がビット0にリセットされている場合には非ダーティ状態を意味する。
この場合には主記憶としてのローカルストレージ28に最新データが存在し、シェアードマップビットS0〜S7で指定されるいずれかのプロセッサモジュール上に、シェア状態でそのコピーデータが存在することを意味する。データサブラインビットD0〜D3に関するプロセッサモジュールの識別情報は、主記憶としてのローカルストレージ28上の特定領域、例えば図6のCPU物理アドレス空間86における制御レジスタ空間88に格納されている。
図12は、ディレクトリエントリレジスタ104の具体的な内容を示す。まずシェアードマップビット領域は、システムバス12−1,12−2に対応してシェアードマップビット領域106−1と106−2に分けられている。ここで、システムバス12−1側についてのみプロセッサモジュールを実装しており、システムバス12−2側についてはプロセッサモジュールを未実装であった場合には、シェアードマップビット領域106−1側が実装プロセッサモジュール用に使用される。
シェアードマップビット領域106−1では、シェアードマップビットS3とS4にビット1がセットされている。この場合、図9に示したシェアードマップビット対応レジスタ112による対応で、例えばシェアードマップビットS3はユニットID=#03のプロセッサモジュールのキャッシュラインのデータの全サブラインのシェア情報のORを意味する。また、シェアードマップビットS4が同じく図9のシェアードマップビット対応レジスタ112による対応関係の指定で、例えばユニットID=#04のプロセッサモジュール上のあるプロセッサエレメントのキャッシュ上の全サブラインのシェア状態のORとなる。
一方、ダーティサブラインビット領域108については、例えばダーティサブラインビットD1とD4がビット1にセットされ、D2とD3がビット0にリセットされている。このダーティサブラインビットD1〜D4に対応して、ローカルストレージ28にはプロセッサモジュール情報格納領域120,122,124,126が設けられている。
例えばダーティサブラインビットD1のプロセッサモジュール情報領域120には、ユニットID=#01のプロセッサモジュールに存在するキャッシュ上にダーティ状態として最新データが存在することを示している。同様に、ビット1にセットされたダーティサブラインビットD4については、プロセッサモジュール情報領域126にユニットID=#02のプロセッサモジュールに存在するキャッシュ上にダーティ状態として最新データが存在することを示している。
またビット0にリセットされたダーティサブラインビットD2,D3のプロセッサモジュール情報領域122,124については、このキャッシュラインの物理アドレスが存在する主記憶としてのローカルストレージに最新データがあり、いずれかのプロセッサモジュールのキャッシュ上に主記憶の最新データの参照によりコピーデータがシェア状態で存在することを示す。
シェア状態でコピーデータが存在するプロセッサモジュールのユニットIDについては、シェアードマップビット領域106−1のビット1にセットされたシェアードマップビットS3,S4に対する図9のシェアードマップビット対応レジスタ112の参照で得られ、例えばユニットID=#03,#04のプロセッサモジュール上にシェア状態でコピーデータが存在する可能性を示す情報が格納されている。
またビット0にセットされたダーティサブラインビットD2,D3のプロセッサモジュール情報領域122,124の内容は、シェアード以外に非シェアードが格納される場合もあり、この場合には、対応する主記憶としてのローカルストレージにのみ最新データが存在することを示す。
次に、スヌープバス22のパケットを説明する。パケットは起動コマンドと応答コマンドに分類される。起動コマンドと応答コマンドは、基本的に対になっている。パケットはコマンドフェーズとデータフェーズからなる。コマンドフェーズは1クロックである。データフェーズは、コマンドとサイズによって0から8クロックまでの長さをとることができる。
起動コマンドのコマンドフェーズは、パケットの宛先を示す宛先フィールド、パケット処理について補助的な指示を含むフラグフィールド、処理対象のデータサイズを示すサイズフィールド、コマンドの種別を示すタイプフィールド、コマンドの処理対象のアドレスを示すアドレスフィールドから構成される。起動コマンドと応答コマンドの区別はタイプフィールドで識別する。
一方、応答コマンドもコマンドフェーズとデータフェーズからなる。コマンドフェーズは1クロックで、データフェーズはコマンドとサイズによって0から8のクロックの長さをとることができる。応答コマンドのコマンドフェーズは、パケットの宛先を示す宛先フィールド、アクセスの成否,エラー要因およびリトライ指示を示すリプライコードフィールド、リプライの種別を示すリプライフィールド、コマンドの種別を示すコマンドフィールド(リプライであることを示す種別情報が格納される)、コマンドの処理対象のアドレスを示すアドレスフィールドから構成される。
複数のプロセッサモジュール間を接続するシステムバス12−1,12−2についても、パケットは基本的にスヌープバス22と同じであるが、バスクロックが相違する。即ち、スヌープバスはバスの線路長がモジュール筐体内で済むことから短く、電気的特性が良いので、例えば60MHzのクロック周波数とできる。
これに対しシステムバス12−1,12−2はバックパネルを介して複数のプロセッサモジュール間に接続されるために線路長が長く、電気的特性の制約から例えば40MHzのクロック周波数に抑えられている。このようなスヌープバス22とシステムバス12−1,12−2の間のクロック周波数の相違によるタイミングは、図3のメモリモジュール25に示したプロトコル管理ユニット24によるプロトコル変換機能により調整がとられている。
図13は、スヌープバス22で使用されるコマンドの種類を、プロセッサ16、スヌープユニット20、メモリ管理ユニット26に分けて示している。
次に、図4のプロセッサエレメント14−1に設けているキャッシュ制御モジュール35側におけるキャッシュ状態の遷移を説明する。まず、2次キャッシュ制御モジュール35のタグメモリ40にキャッシュサブライン単位に保持されるキャッシュ状態には、図14に示す無効状態、シェアードクリーン状態、シェアードモディファイ状態、排他的ダーティ状態、シェアードダーティ状態の5つがある。
無効状態INVは2次キャッシュ38上にデータが存在しない非キャッシュ状態である。シェアードクリーン状態SH&Cは、ホームとなるプロセッサモジュールの主記憶であるローカルストレージと同一内容のデータを保持している状態である。シェアードモディファイ状態SH&Mは、ホームとなる主記憶上にあるデータは最新データではない旧いデータであり、自分自身の2次キャッシュには、そのコピーデータが存在し、更に自分のプロセッサモジュール内の他の2次キャッシュ上に排他的ダーティ状態EX&Dにより、システム内で唯一の最新データが存在している状態である。
排他的ダーティ状態EX&Dはシステム内で唯一の最新データを保留している状態であり、この場合、書込権を所有した所謂オーナーとなっている。更に、シェアードダーティ状態SH&Dは、ホームとしての主記憶上に最新データがなく、自分のプロセッサモジュール内の2次キャッシュ群に最新データを保留しており、更に、自分のプロセッサモジュール内の2次キャッシュ群にホームの主記憶データのコピーをもったシェアードモディファイ状態SH&Mが存在し、最新データを保留しているキャッシュ制御モジュール自身が書込権を所有してオーナーとなっている場合である。
図15は図4の2次キャッシュ制御モジュール35におけるキャッシュ状態の遷移を示す。まず初期状態は、ブロック130の無効状態INVである。この状態でプロセッサのリードアクセスによって1次キャッシュ36がミスヒットになると、アクセス要求が2次キャッシュ状態モジュール35に発行される。このとき2次キャッシュ38の該当するキャッシュサブラインが無効状態INVであれば、スヌープバス22へデータを要求するコマンドを送出する。
この場合、遷移状態はブロック150のシェアードモディファイ状態SH&Mに遷移するケース1の場合と、ブロック140のシェアードクリーン状態SH&Cに遷移するケース2の場合の2つがある。ケース1の場合、ブロック150のシェアードモディファイ状態(SH&M)は、他のプロセッサエレメントが排他的ダーティ状態EX&Dあるいはシェアードダーティ状態SH&Dで、アクセス対象となったサブラインをキャッシュ上に所有している場合であり、いずれかのプロセッサエレメントのキャッシュ状態信号によってダーティが表示される。
そこで、ダーティが表示されたプロセッサエレメントのキャッシュ制御モジュール35が2次キャッシュ38をアクセスし、データ応答をスヌープバス22に発行する。このとき応答を行ったプロセッサエレメントでキャッシュ状態がブロック160の排他的ダーティ状態EX&Dであった場合には、ブロック170のシェアードダーティ状態SH&Dに遷移する。応答を受け取ったプロセッサエレメントは、キャッシュ状態をブロック150のシェアードモディファイ状態SH&Mへ遷移する。
一方、ケース2の場合は、プロセッサのリードアクセスの1次キャッシュにおけるミスヒットに対するアクセス要求に対し、他のプロセッサエレメントがブロック140のシェアードクリーン状態SH&Cか或いはブロック130の無効状態INVであった場合であり、キャッシュ状態信号およびメモリモジュール25側のメモリ状態信号はクリーン或いはミスが表示される。クリーン表示を行ったキャッシュ制御モジュール35は、キャッシュ状態信号を参照して、応答を作成すべきか否か判断する。
同様に、メモリ状態信号を参照したメモリモジュール25、即ちメモリモジュール25に設けているメモリ管理ユニット26も、メモリ状態信号を参照して、応答を作成すべきか否か判断する。応答すべきことを検出したモジュールが2次キャッシュ制御モジュール35であれば、2次キャッシュメモリ38にアクセスし、データの応答をスヌープバス22に発行する。応答すべきことを検出したモジュールがメモリモジュール25のメモリ管理ユニット26であれば、主記憶としてのローカルストレージ28へのアクセスを起動し、スヌープバス22に応答データを発行する。
このようにしてスヌープバス22から応答データを受け取ったアクセス元の2次キャッシュ制御モジュール35は、ブロック130の無効状態INVからブロック140のシェアードクリーン状態SH&Cに遷移する。
2.CPUリードアクセス時のキャッシュコヒーレンス
次に、図2に示したプロセッサモジュール10−1〜10−5のいずれかのCPUでリードアクセスが発生した場合のキャッシュコヒーレンスの処理を、読出モード1〜3に分けて説明する。
(1)読出モード1
図16は読出モード1のキャッシュコヒーレンスのプロトコルを示している。
読出モード1は、プロセッサモジュール10−1内の任意のCPUの読出アクセスP−RDに対し、キャッシュユニット群18の中の自己のキャッシュユニットでミスヒットし、且つスヌープバス22で接続した他の全てのキャッシュユニット18でミスヒットした場合である。
この場合には、メモリ管理ユニット26に対し主記憶となるローカルストレージ28をアクセスするためのリモートコマンドとしてコマンドT−CRが発行される。ここで、読出アドレスがプロセッサモジュール10−1のローカルストレージ28にあることでプロセッサモジュール10−1はホームとなり、更にローカルストレージ28のデータがリモートとなるプロセッサモジュール10−2内のキャッシュユニット群のいずれかに最新データをもつダーティ状態で存在していたものとする。
このような場合、読出アクセスを発生したプロセッサモジュール10−1のメモリ管理ユニット26は、システムバス12にリモートコマンド220を発行して、プロセッサモジュール10−2にアクセスする。このリモートコマンド220を受領したプロセッサモジュール10−2のメモリ管理ユニット26は、スヌープバス22を介してダーティ状態Dにあるキャッシュユニットから最新データを取得した後に、システムバス12を使用して最新データをリプライデータ230として、ローカルで且つホームとなっているプロセッサモジュール10−1に応答する。
プロセッサモジュール10−1は、システムバス12の応答として得られたリプライデータ230をアクセス元のキャッシュユニットにスヌープバス22を介して格納し、CPUの読出アクセスに対するリードデータとして応答させる。同時に、主記憶としてのローカルストレージ28に最新データを書き込むことで、キャッシュコヒーレンスを実現する。ここでリモートコマンド220を受けて最新データの応答を行ったプロセッサモジュール10−2のキャッシュユニットにあっては、ダーティ状態Dをクリーン状態Cに更新する。また、アクセス元のプロセッサモジュール10−1のローカルストレージ28のキャッシュデータを管理しているディレクトリメモリについて、アクセス対象となったキャッシュラインのダーティ状態Dをシェア状態Sに更新する。更に、アクセス元のキャッシュユニットについては、無効状態Iをクリーン状態Cに更新する。
(2)読出モード2
図17は読出モード2におけるキャッシュコヒーレンスのためのプロトコルを示す。この読出モード2は、任意のCPUの読出アクセスP−RDに対し自己のキャッシュユニットでミスヒットし、且つスヌープバス22で接続した他の全てのキャッシュユニットでミスヒットし、且つ読出アドレスが他のプロセッサモジュール10−2の主記憶であるローカルストレージ28にあり、このローカルストレージ28の読出アドレスのデータが別のプロセッサモジュール10−3のいずれかのキャッシュユニット上に最新データをもつダーティ状態Dで存在する場合である。
この場合、読出アクセスが起きたプロセッサモジュール10−2のメモリ管理ユニット26はローカルとして動作し、システムバス12にホームコマンド240を発行してプロセッサモジュール10−2にアクセスする。プロセッサモジュール10−2は、システムバス12から受領したホームコマンド240に基づき、読出アドレスによるディレクトリメモリの参照でプロセッサモジュール10−3のキャッシュ上にダーティ状態Dで最新データが存在することを認識し、システムバス12にリモートコマンド250を発行してプロセッサモジュール10−3にアクセスする。
プロセッサモジュール10−3は、システム12−2から受領したリモートコマンド250に基づき、メモリ管理ユニット26がリモートとして動作し、スヌープバス22によってダーティ状態Dにあるキャッシュユニットにアクセスして最新データを取得した後、システムバス12を使用して、ホームとしてのプロセッサモジュール10−2およびローカルとしてのプロセッサモジュール10−1のそれぞれにリプライデータ260を応答する。ホームとしてのプロセッサモジュール10−2は、システムバス12の応答により得られたリプライデータ260により主記憶としてのローカルストレージ28の対応データのオーナーを行って、最新データに更新する。
同時に、ローカルとしてのプロセッサモジュール10−1にあっては、システムバス12からの応答で受領したリプライデータ260をスヌープバス22を介してアクセス元のキャッシュユニットに転送して2次キャッシュ上に格納し、CPUの読出アクセスに対しリードデータとして応答させる。
ここで、リモートとなったプロセッサモジュール10−3で最新データの応答を行ったキャッシュユニットは、キャッシュ状態をダーティ状態Dからクリーン状態Cに更新する。またホームとなったプロセッサモジュール10−2にあっては、アクセス対象となったキャッシュラインの状態をダーティ状態Dからシェア状態Sに更新する。
具体的には、図8のディレクトリエントリレジスタ104のダーティサブラインビット領域108の対応するサブラインビットを1から0にリセットする。また、リモートとしてのプロセッサモジュール10−3およびローカルとしてのプロセッサモジュール10−1にシェア状態でホームにおけるローカルストレージ28のデータと同一データが存在するシェア状態にあることから、シェアードマップビット領域106の対応するシェアードマップビットを1にセットする。
更に、ローカルとなったプロセッサモジュール10−1のアクセスが発生したキャッシュユニットにあっては、無効状態Iをクリーン状態Cに遷移させる。
(3)読出モード3
図18は読出モード3におけるキャッシュコヒーレンスのプロトコルであり、このモードにあっては、アクセスが発生したモジュールの内部のキャッシュユニット間でのスヌープバス22を使用したキャッシュコヒーレンスが行われる。読出モードには図18(A)と図18(B)の2つのケースがある。
図18(A)はCPUの読出アクセスP−RDが発生したキャッシュユニット18−4が無効状態INVにあってミスヒットとなったが、スヌープバス22で接続された他のキャッシュユニット18−1に最新データがシェアードクリーン状態SH&Cで存在していた場合である。この場合には、キャッシュユニット18−4がスヌープバス22を使用してコマンドT−CRを発行し、キャッシュユニット18−1から該当するサブラインを含むリプライデータ270の応答が行われ、キャッシュユニット18−4上に格納されて、読出アクセスにリードデータとして応答する。
このときアクセス元のキャッシュユニット18−4にあっては、無効化状態INVからシェアードクリーン状態SH&Cに遷移し、アクセス先のキャッシュユニット18−1にあってはシェアードクリーン状態SH&Cを維持する。
図18(B)は無効化状態INVにあるキャッシュユニット18−4に対するCPUからの読出アクセスP−RDに対し、スヌープバス22で接続したキャッシュユニット18−1に最新データが排他的ダーティ状態EX−Dで存在した場合、即ち書込権を所有した状態で存在した場合である。この場合のキャッシュユニット18−4からのアクセスT−CRに対し、同様にキャッシュユニット18−1から最新データのサブラインを含むリプライデータ280の応答が行われる。
この場合、アクセス元のキャッシュユニット18−4は無効化状態INVからシェアードモディファイ状態SH&M、即ち自分のプロセッサモジュール内の他のキャッシュユニットにシェアードダーティ状態で最新データが存在することを示す。またアクセス先のキャッシュユニット18−1にあっては、排他的ダーティ状態EX&Dからシェアードダーティ状態SH&Dに遷移する。
(4)ローカルプロセッサモジュールのリード処理
図19のフローチャートは、図16,図17の読出モード1,2におけるローカルとなったプロセッサモジュールのリード処理である。まずステップS1で、プロセッサエレメントのリードアクセスを受けて、ステップS2で、キャッシュヒットの有無が判定され、キャッシュヒットであれば、ステップS14で、プロセッサエレメントにデータを応答して処理を終了する。
キャッシュミスヒットの場合には、ステップS3で、タグメモリ40からキャッシュステータスを取得し、ステップS4で、他のプロセッサエレメントのキャッシュ上に最新データがあるか否かチェックする。他のプロセッサエレメントのキャッシュ上に最新データがあれば、ステップS15に進み、スヌープバス22にコマンドを送出し、ステップS16でリプライデータを受けて、ステップS13で、キャッシュに格納してプロセッサエレメントに応答する。このステップS15〜S17は、図18の読出モード3の処理である。
一方、ステップS4で他のプロセッサエレメントのキャッシュ上にも最新データがなかった場合には、ステップS5で、ローカルコマンドをスヌープバス22を介してメモリ管理ユニット26に送出する。メモリ管理ユニット26側にあっては、まずステップS6で、図4に示した空間識別ユニット50によりコマンドの物理アドレスからプロセッサモジュール空間を判別する。
ステップS7で、リードアドレスが自分のプロセッサモジュールのローカルストレージ28の主記憶空間であった場合、ステップS8で、自らをホームとしてディレクトリメモリ30のディリクトリエントリからキャッシュステータスを取得する。キャッシュステータスについて、ステップS9で、サブラインがダーティか否かチェックし、ダーティであれば、ステップS10で、リモートプロセッサモジュールに対しシステムバスを介してリモートコマンドを送出する。
このリモートコマンドに対しステップS11で応答があると、リプライデータをステップS12で主記憶としてのローカルストレージ28に書き込み、ダーティ状態をシェアード状態に更新する。そしてステップS13で、アクセス元のキャッシュユニットに応答し、処理を終了する。ステップS9でサブラインがダーティでなかった場合には、ステップS22で、主記憶としてのローカルストレージ28からデータを読み出してアクセス元のキャッシュユニットに応答し、ステップS23で、主記憶としてのローカルストレージ28のサブラインのシェアードビットをオンする。
またステップS7で、アクセスした物理アドレスが他のプロセッサモジュール空間であった場合には、ステップS18で、システムバスを介してホームとなるプロセッサモジュールに対しホームコマンドを送出する。このホームコマンドの送出に対し、システムバスを介して最新データのリプライがあることから、ステップS19でリプライを判別すると、ステップS20で、アクセスごとのキャッシュに応答して処理を終了する。
(5)ホームプロセッサモジュールのリード処理
図20のフローチャートは、図16,図17の読出モード1,2においてホームとなったプロセッサモジュールのリード処理を示す。まずステップS1で、ホームコマンドを受領する。ホームコマンドは、システムバスを経由して受領する場合と、自分自身がローカルで且つホームとなる場合に自分自身で生成したホームコマンドを受領する場合とがある。
ホームコマンドを受領すると、ステップS2で、自分自身をホームとしてディレクトリメモリ30からキャッシュラインのステータスを取得し、ステップS3で、サブラインがダーティか否かチェックする。サブラインがダーティであった場合には、ステップS4で、自分のプロセッサモジュール内のプロセッサエレメントのキャッシュ上に最新データがあるか否かチェックする。
最新データが自分自身のキャッシュ上にあれば、ステップS5でスヌープバス22にコマンドを送出し、ステップS6でリプライを待って、ステップS7でリプライデータを主記憶としてのローカルストレージ28に書き込み、ディレクトリエントリのダーティ状態をシェアード状態に更新する。続いてステップS8で、ローカルプロセッサモジュールに対しリプライデータをシステムバスを使用して送出する。
またステップS4で、別のプロセッサモジュール内のプロセッサエレメントのキャッシュ上にダーティ状態の最新データが存在している場合には、ステップS12で、システムバスを介してリモートプロセッサモジュールにリモートコマンドを送出し、ステップS13でリプライを待って、ステップS14で、主記憶としてのローカルストレージ28に最新データを書き込んでディレクトリアントリのダーティ状態をシェアード状態に更新する。
一方、ステップS3でサブラインがダーティでなかった場合には、主記憶としてのローカルストレージ28から最新データを読み出して、システムバスを介してローカルプロセッサモジュールにリプライデータを送出し、処理を終了する。
(6)リモートプロセッサモジュールのリード処理
図21のフローチャートは、図16,図17の読出モード1,2におけるリモートプロセッサモジュールのリード処理である。まずステップS1で、システムバスを介してリモートコマンドを受領すると、ステップS2で、自分自身をリモートとしてキャッシュユニットにスヌープバスを介してコマンドを送出する。該当するプロセッサエレメントのキャッシュユニットからデータのリプライを受けると、ステップS4で、スヌープバス22からリプライデータを受領し、ステップS5で、システムバスを介してホームプロセッサモジュールおよびローカルプロセッサモジュールにリプライデータを送出する。
(7)プロセッサエレメントのリード処理
図22のフローチャートはプロセッサエレメント自身のリード処理である。まずステップS1でCPUのリード要求が発生すると、ステップS2でキャッシュヒットの有無を判定し、キャッシュヒットであれば、ステップS12で、キャッシュデータをリードアクセスに対し応答する。
キャッシュミスヒットとなった場合には、ステップS3で、キャッシュ制御モジュール35でキャッシュラインのステータスをタグメモリ40から取得し、ステップS4で、他のプロセッサエレメントのキャッシュ上でヒットか否か判定する。この場合、ミスヒットであればステップS13に進み、メモリモジュール20側に対するアクセスで他のプロセッサモジュールに対する処理を行う。
ステップS4でキャッシュヒットとなった場合には、ステップS5で、他のプロセッサエレメントのキャッシュ状態はシェアードクリーン状態SH&Cか否かチェックする。シェアードクリーン状態SH&Cであれば、ステップS6で、スヌープバス22にコマンドを送出し、ステップS7で、リプライデータを受領してキャッシュに応答し、ステップS8で、ステータスを無効化状態INVからシェアードクリーン状態SH&Cに更新する。
一方、他のプロセッサが排他的ダーティ状態EX&Dであった場合には、ステップS9でスヌープバス22にコマンドを送出した後、ステップS10で、リプライデータを受領してキャッシュに応答し、ステップS11で、ステータスをシェアードモディファイ状態SH&Mに更新する。
3.CPU書込アクセスに対するキャッシュコヒーレンス
(1)書込モード1
図23は、書込モード1におけるキャッシュコヒーレンスのプロトコルを示す。この書込モード1は、プロセッサモジュール10−1の任意のCPUの書込アクセスP−WTに対し自己のキャッシュユニットでミスヒットし、且つスヌープバス22で接続した他のキャッシュユニットにおいてもミスヒットとなり、且つ書込アドレスがプロセッサモジュール10−1の主記憶であるローカルストレージ28にあり、更に、ローカルストレージ28の書込アドレスのコピーデータが他の複数のプロセッサモジュール10−2,10−3のキャッシュ上にシェア状態で存在する場合である。
この場合には、スヌープバス22を介して書込アクセスT−CRIを受けたプロセッサモジュール10−1のメモリ管理ユニット26は、自らをローカルおよびホームとし、キャッシュディレクトリの参照で、シェア状態にある全てのプロセッサモジュール10−2,10−3に対し、システムバス12を使用して無効化指令であるパージコマンド300を発行する。
このパージコマンド300に対し、プロセッサモジュール10−2,10−3はリモートとして動作し、それぞれのメモリ管理ユニット26はスヌープバス22を介してシェア状態Cにあるメモリユニットに対し無効化を要求する。シェア状態にあるキャッシュユニットで無効化に成功すると、プロセッサモジュール10−2,10−3はシステムバス12を使用して独立にパージ応答310,320を行う。このパージ応答310,320には、プロセッサモジュール10−2,10−3における対象となったキャッシュラインのキャッシュステータスが含まれている。
ホームとしてのプロセッサモジュール10−1は、システムバス12から全てのパージ応答310,320を受理したことで無効化の成功を認識し、主記憶としてのローカルストレージ28の書込アドレスのコピーデータをアクセス元のキャッシュユニットに格納して、書込アクセスにより上書きさせる。このときホームとしてのプロセッサモジュール10−1にあっては、アクセス対象となったキャッシュラインのディレクトリエントリのシェア状態Sをダーティ状態Dに更新する。
このように書込アクセスにあっては、アクセス元のキャッシュ上で主記憶としてのローカルストレージ28と同一データが上書きにより変更されて最新データとなることで、ローカルストレージ28のデータが旧いデータとなった状態で処理を終了し、ローカルストレージ28の旧いデータの最新データとのコヒーレンスは、既に説明したリードアクセスを通じて行われることになる。
(2)書込モード2
図24は、書込モード2によるキャッシュコヒーレンスのプロトコルを示す。書込モード2は、CPUアクセスが発生したプロセッサモジュール10−1のキャッシュユニットに、スヌープバス22で接続した他のキャッシュユニットに書込権を所有しないシェア状態Cで主記憶としてのローカルストレージ28と同一データが存在している場合であり、それ以外の状態は図23のモード1と同じである。
この書込モード2にあっては、CPUの書込アクセスP−WTに基づいて、ホームとして動作したメモリ管理ユニット26よりシステムバス12を使用してリモートとしてのプロセッサモジュール10−2,10−3にパージコマンド300を発行すると同時に、これに並行して、同じプロセッサモジュール10内のキャッシュユニット群18に対しパージコマンド325を発行する。
このため、ホームとして動作したプロセッサモジュール10−1のメモリ管理ユニット26は、システムバス12を介してリモートとしてのプロセッサモジュール10−2,10−3からのパージ応答310,320の全ての応答と、自己のスヌープバス22からのパージ応答を受理したことで、無効化の成功を認識し、主記憶としてのローカルストレージ28の最新データのコピーデータをアクセス元のキャッシュユニットに格納して、CPUの書込アクセスにより上書きする。この場合にも、書込モード1と同様、ディレクトリエントリのシェア状態Sはダーティ状態Dに更新される。
(3)書込モード3
図25は、書込モード3によるキャッシュコヒーレンスのプロトコルを示す。この書込モード3は、プロセッサモジュール10−1のCPUの書込アクセスP−WTに対し、自己のキャッシュユニットおよびスヌープバス22を介して接続したキャッシュユニットを含むキャッシュ群18のいずれにもコピーデータがオーナーを所有した状態で登録されておらず、ミスヒットになり、書込アドレスがプロセッサモジュール10−2の主記憶であるローカルストレージ28にあり、更にローカルストレージ28の最新データのコピーデータがプロセッサモジュール10−2以外の他の複数のプロセッサモジュール10−3,10−4にシェア状態Cで存在する場合である。
この場合、ローカルとしてのプロセッサモジュール10のメモリ管理ユニット26は、システムバス12を使用してホームとしてのプロセッサモジュール10−2に書込所有権の要求指令、所謂ホームコマンド330を発行する。書込所有権の要求指令であるホームコマンド330を受領したプロセッサモジュール10−2は、シェア状態にある他のプロセッサモジュール10−3,10−4に対し、システムバス12を使用して無効化指令としてのパージコマンド340を発行する。
プロセッサモジュール10−3,10−4は、パージコマンド340を受理すると、スヌープバス22を介して、シェア状態にあるキャッシュ群18の中のキャッシュユニットに対し無効化を指令し、無効化に成功すると、システムバス12を使用してホームとしてのプロセッサモジュール10−2に独立にパージ応答350,360を返す。
ホームとしてのプロセッサモジュール10−2は、全てのパージ応答350,360を受理したことで無効化の成功を認識すると、ローカルとしてのプロセッサモジュール10−1に対し、システムバス12を使用して自分自身の主記憶であるローカルストレージ28の最新データのコピーデータを含む書込所有権の移動を応答する。
ローカルのプロセッサモジュール10−1は、システムバス12より書込所有権の応答であるリプライデータ370の受領により得られたコピーデータをアクセス元のキャッシュユニットに格納し、CPUの書込アクセスにより上書きさせる。ここで、無効化の成功を認識して書込所有権の移動を行ったホームとしてのプロセッサモジュール10−2のメモリ管理ユニットは、ディレクトリエントリのシェア状態Sをダーティ状態Dに更新する。またプロセッサモジュール10−1のアクセス元のキャッシュユニットにあっては、書込アクセスの終了でキャッシュ状態を書込権を所有したダーティ状態Dに更新する。
(4)書込モード4
図26は、書込モード4によるキャッシュコヒーレンスのプロトコルを示す。書込モード4は、ローカルとして動作するプロセッサモジュール10−1におけるCPUの書込アクセスP−WTに対し、自己のキャッシュユニットがミスヒットで、且つスヌープバス22を介して接続した他のキャッシュユニットにもコピーデータが書込権を所有した状態で登録されておらずにミスヒットとなり、書込アドレスがプロセッサモジュール10−2の主記憶であるローカルストレージ28にあり、更にローカルストレージ28の最新データのコピーデータがプロセッサモジュール10−2を含む複数のプロセッサモジュール10−3,10−4のキャッシュユニットにシェア状態Cで存在する場合である。
この場合には、書込アクセスが発生したローカルとしてのプロセッサモジュール10−1のメモリ管理ユニット26が、ホームとしてプロセッサモジュール10−2に対しシステムバス12を使用して書込所有権の要求指令であるホームコマンド370を発行する。この書込所有権要求指令となるホームコマンド370を受領したプロセッサモジュール10−2のメモリ管理ユニット26は、シェア状態にある全てのプロセッサモジュール10−3,10−4に対し、システムバス12を使用して無効化指令としてのパージコマンド380を発行する。
このパージコマンド380の発行に並行して更に、メモリ管理ユニット26は、自己のシェア状態にあるキャッシュ群18の中のキャッシュユニットに対しスヌープバス22を使用して無効化指令としてのパージコマンド410を発行する。
キャッシュ上でシェア状態Cにある全てのプロセッサモジュール10−3,10−4はリモートとして動作し、パージコマンド340を同時に受理して、スヌープバス22を介してキャッシュ群18側に無効化を指令し、無効化に成功すると、システムバス12を使用して、プロセッサモジュール10−2に独立にパージ応答350,360を返す。これに並行してプロセッサモジュール10−2のシェア状態Cにあるキャッシュユニットからは、無効化の成功がスヌープバス22を使用して応答される。
ホームとなるプロセッサモジュール10−2は、システムバス12からの全ての無効化成功のパージ応答350,360と、スヌープバス22からの無効化成功の応答を受領したことで、無効化の成功を認識して、システムバス12を使用してローカルのプロセッサモジュール10−1に対し自分の主記憶であるローカルストレージ28の最新データのコピーデータを含む書込所有権の移動をリプライデータ430として応答する。
プロセッサモジュール10−1は、システムバス12から書込所有権の応答の受領で得られたコピーデータをアクセス元のキャッシュユニットに格納して、CPUの書込アクセスにより上書きさせる。ここでプロセッサモジュール10−2は、無効化の成功を認識して書込所有権の移動を応答した際に、自己のディレクトリエントリのシェア状態Sをダーティ状態Dに更新する。
(5)書込モード5
図27は、書込モード5によるキャッシュコヒーレンスのプロトコルを示す。この書込モード5は、プロセッサモジュール10−1のCPUの書込アクセスP−WTに対し自己のキャッシュユニットおよびスヌープバス22で接続した他のキャッシュユニットのキャッシュ群18にコピーデータが書込権を所有した状態で登録されておらずにミスヒットとなり、且つ書込アドレスがプロセッサモジュール10−1の主記憶であるローカルストレージ28にあり、更にローカルストレージ28の書込アドレスの最新データがプロセッサモジュール10−2のキャッシュユニットに書込権を所有したダーティ状態Dで存在する場合である。
この場合、ローカルおよびホームとしてのプロセッサモジュール10−1は、ダーティ状態Dにあるプロセッサモジュール10−2に対し、システムバス12を使用して、書込所有権の要求指令となるリモートコマンド440を発行する。プロセッサモジュール10−2は、システムバス12から書込所有権の要求指令であるリモートコマンド440を受理して、キャッシュユニット上のシェア状態Dの最新データを含む書込所有権の移動を示すリプライデータ450をシステムバス12を使用してプロセッサモジュール10−1に応答する。
プロセッサモジュール10−1は、リプライデータ450による書込所有権の応答で得られた最新データをアクセス元のキャッシュユニットに格納して、CPUによる書込アクセスで上書きさせる。
ここでプロセッサモジュール10−2の書込所有権を移動したキャッシュユニットにあっては、ダーティ状態Dを無効化状態Iに更新する。またプロセッサモジュール10−1のメモリ管理ユニット26は、書込所有権を受領した際にディレクトリエントリのダーティ状態Dを自分のキャッシュ上に最新データが存在するダーティ状態D´に更新する。
(6)書込モード6
図28は、書込モード6によるキャッシュコヒーレンスのプロトコルを示す。この書込モード6は、プロセッサモジュール10−1のCPUによる書込アクセスP−WTに対し、自己のキャッシュユニットおよびスヌープバス22で接続した他のキャッシュユニットを含むキャッシュ群18にコピーデータが書込権を所有した状態で登録されておらずに、ミスヒットとなり、書込アドレスがプロセッサモジュール10−2の主記憶であるローカルストレージ28にあり、更にローカルストレージ28の書込アドレスの最新データがプロセッサモジュール10−3のキャッシュユニットに書込権を所有したダーティ状態Dで存在する場合である。
この場合に、ローカルとしてのプロセッサモジュール10−1のメモリ管理ユニット26は、システムバス12を使用して、書込所有権の要求指令となるホームコマンド460を発行する。ホームコマンド460を受領したホームとなるプロセッサモジュール10−2のメモリ管理ユニット26は、リモートとなるプロセッサモジュール10−3に対し、システムバス12を使用して、同じく書込所有権の要求指令であるリモートコマンド470を発行する。
リモートコマンド470を受領したプロセッサモジュール10−3は、ダーティ状態Dにあるキャッシュユニットの最新データを含む書込所有権を、システムバス12を使用して、リプライデータ480としてホームであるプロセッサモジュール10−2およびローカルであるプロセッサモジュール10−1に応答する。
ホームであるプロセッサモジュール10−2は、書込所有権の応答であるリプライデータ480を受領して、書込所有権の移動を認識する。またローカルとなるプロセッサモジュール10−1は、リプライデータ480による書込所有権の受領で得られた最新データをアクセス元のキャッシュユニットに格納して、CPUの書込アクセスで上書きさせる。
ここで、リモートとなるプロセッサモジュール10−3のキャッシュユニットにあっては、ダーティ状態Dを書込所有権を移動した際に無効化状態Iに更新する。またホームとなるプロセッサモジュール10−2は、書込所有権の移動を確認した際に、ディレクトリエントリのダーティ状態Dを最新データが存在するプロセッサモジュール10−1の情報に変更したダーティ状態D´に更新する。
更に、ローカルとなるプロセッサモジュール10−1のアクセス元のキャッシュユニットにあっては、最新データを格納した後に、書込権を所有しているダーティ状態Dに更新する。
(7)書込モード7
図29は、書込モード7によるキャッシュコヒーレンスのプロトコルを示す。この書込モード7は、プロセッサモジュール10−1内の複数のキャッシュユニット間でアクセスする場合である。即ち、プロセッサモジュール10−1内のCPUの書込アクセスP−WTに対し、自己のキャッシュユニット18−4はミスヒットしたが、スヌープバス22を介して接続した他のキャッシュユニット18−1に書込アドレスの最新データが書込権を所有したダーティ状態、即ち排他的ダーティ状態EX&Dで存在する場合である。
この場合、アクセス元のキャッシュユニット18−4はスヌープバス22を介してコマンドT−CRIを発行し、これに応答してキャッシュユニット18−1は最新のキャッシュサブラインのデータを含むリプライデータ490を応答し、キャッシュユニット18−4に格納した後に、書込アクセスにより上書きさせる。
ここで、アクセス先のキャッシュユニット18−1にあっては、書込所有権を移動した後に無効化状態INVに更新される。またアクセス元のキャッシュユニット18−4は、書込権を獲得した後に無効化状態INVから書込権を所有するダーティ状態である排他的ダーティ状態EX&Dに更新される。
(8)書込アクセスのプロセッサライト処理
図30のフローチャートは、書込アクセスに伴うキャッシュコヒーレンスでローカルとなったプロセッサモジュールのライト処理である。ステップS1で、プロセッサエレメントのライトアクセスが発生すると、ステップS2で、2次キャッシュ38のキャッシュヒットが判定され、キャッシュヒットであれば、ステップS14で、キャッシュ上にデータを上書きする。
キャッシュミスヒットであればタグメモリ40からキャッシュステータスを取得し、スヌープバス22で取得した他のキャッシュユニットに最新データがあるか否かステップS4でチェックする。他のキャッシュ上に最新データがあれば、ステップS15で他のプロセッサエレメントにコマンドを送出し、ステップS16でリプライを待ち、ステップS17で、最新のリプライデータに上書きを行って、書込アクセスを終了する。
ステップS14で、スヌープバス22で接続した他のプロセッサエレメントのキャッシュ上に最新データがなかった場合には、ステップS5で、ローカルコマンドをスヌープバス22を介してメモリ管理ユニット26に送出し、ステップS6で、空間識別ユニット50からプロセッサモジュール空間を判別し、ステップS7で、自分自身のプロセッサモジュール空間か否か判断する。
自分自身のプロセッサモジュール空間であれば、ステップS8で、自分自身をホームとしてディレクトリメモリ30からキャッシュラインのステータスを見るためにディレクトリエントリを取得する。ステップS9で、ディレクトリエントリのサブラインはダーティか否かチェックし、ダーティであれば、ステップS10で、リモートとなるプロセッサモジュールにシステムバス12を介してパージを要求する。
このパージ要求に対しステップS11で応答があれば、ディレクトリエントリの別のサブラインにダーティをセットし、キャッシュステータスを更新する。そしてステップS13で、プロセッサエレメントのアクセス元のキャッシュ上でリプライデータを上書きし、無効化状態INVを書込所有権付きのダーティ状態EX&Dに更新する。
一方、ステップS9で、ディレクトリエントリのサブラインがダーティではなくシェアであった場合には、ステップS21で、リモートプロセッサモジュールにパージを要求し、ステップS22でリプライを待って、ステップS23で、ディレクトリエントリのシェア状態Sをダーティ状態Dに更新するキャッシュステータスの更新を行い、最終的に、ステップS24で、キャッシュデータに上書きを行って無効化状態INVからシェアードダーティ状態SH&Dに更新する。
このステップS8〜S13およびステップS21〜S24は、ローカルプロセッサモジュールが同時にホームプロセッサモジュールとなった場合の処理である。
一方、ステップS7で、アクセス空間が自分自身のプロセッサモジュール空間でなかった場合には、ステップS18で、他のプロセッサモジュールに対しホームコマンドを送出し、ステップS19で、最新データのリプライを待って、ステップS20で、リプライデータをキャッシュ上で上書きして無効化状態INVから排他的ダーティ状態EX&Dに更新する。これはホームコマンドにより書込所有権の移動を伴うものである。
図31のフローチャートは、書込アクセスによるキャッシュコヒーレンスでホームプロセッサモジュールとなった場合のライト処理である。ステップS1でホームコマンドを受領すると、ステップS2で、自分自身をホームとしてディレクトリメモリ30からキャッシュステータスとしてのディレクトリエントリを取得する。
ステップS3で、ディレクトリエントリのサブラインを参照してダーティか否かチェックし、ダーティであれば、ステップS4で、ダーティ状態の最新データの存在が自分自身のプロセッサモジュールのキャッシュ上か否かチェックする。自分自身のキャッシュ上であれば、ステップS5で、スヌープバス22を介してパージを要求し、ステップS6のリプライを待って新データを、ステップS7で、主記憶としてのローカルストレージ28のキャッシュ状態であるディレクトリエントリの新たなサブラインをダーティ状態にセットし、ステップS8で、ローカルプロセッサモジュールに最新データをリプライデータとして送出する。
ステップS4で、ダーティ状態の最新データが他のプロセッサモジュールのキャッシュ上に存在する場合には、ステップS9で、リモートプロセッサモジュールに対しパージを要求し、ステップS10でリプライを待って、ステップS11に進み、ディレクトリエントリにおける新サブラインのダーティをセットする。
一方、ステップS3で、ディレクトリエントリのサブラインがダーティでなくシェア状態であった場合には、ステップS12で、自分自身のプロセッサモジュール内のキャッシュ上か否かチェックする。自分自身のキャッシュ上でなければ、ステップS13で、リモートプロセッサモジュールにパージを要求し、ステップS14でリプライを待って、ステップS15で、主記憶としてのローカルストレージから最新データとしてのリプライデータを読み出してローカルプロセッサモジュールに送出し、キャッシュディレクトリをダーティ状態Dからシェア状態Sに更新する。
またステップS2で、自分自身のプロセッサモジュール内のキャッシュ上にシェア状態が存在するときには、ステップS16で、スヌープバス22を介してパージを要求し、ステップS17でリプライを待って、ステップS18に進み、ディレクトリエントリのシェア状態をダーティ状態に更新する。そしてステップS19で、主記憶としてのローカルストレージ28の最新データをローカルプロセッサモジュールにリプライデータとして送出する。
図32のフローチャートは、書込アクセスにおいてリモートプとなるロセッサモジュールのライト処理である。リモートプロセッサモジュールのライト処理にあっては、まずステップS1で、システムバス12からリモートコマンド、即ち書込所有権の要求指令を受領すると、ステップS2で、スヌープバス22にコマンドを送出し、ステップS3で、スヌープバス22からのリプライを待ち、ローカルプロセッサモジュールおよびホームプロセッサモジュールに対し、ステップS4で、書込所有権の移動を応答するコマンドと最新データをリプライデータとして送出する。
図33は、書込アクセスが発生した際のプロセッサエレメントのライト処理のフローチャートである。まずステップS1でライト要求が発生すると、ステップS2で、自分自身のキャッシュユニットおよびスヌープバス22で接続した他のキャッシュユニットに書込権を所有した最新データが存在するか否かチェックする。
他のキャッシュ上に存在すれば、ステップS9で、アクセス元に転送してキャッシュデータの上書きを行い、読出時のキャッシュユニットでキャッシュヒットとなるか否か、ステップS2でチェックする。キャッシュヒットであれば、ステップS9に進み、キャッシュデータにライト要求によるデータを上書きし、自分自身のキャッシュ状態を同じ書込所有権付きの排他的ダーティ状態EX&D´に送信する。
自分自身のキャッシュユニットに書込権を所有した状態で最新データが存在しなかった場合には、ステップS3に進み、キャッシュ制御モジュール35でタグメモリ40を参照して、キャッシュラインのステータスを取得し、他のプロセッサエレメントのキャッシュ上に書込権を所有した状態で最新データが存在するか否かチェックする。
存在すればヒットと判定し、ステップS5で、スヌープバス22にコマンドを送出し、書込所有権の要求指令を行う。ステップS6でリプライがあると、アクセス元のキャッシュ上にリプライデータを格納して上書きし、ステップS8で、キャッシュステータスを無効状態INVから排他的ダーティ状態EX&Dに更新する。
ステップS4で、他のプロセッサエレメントに書込所有権が存在した状態で最新データがない場合には、ステップS10に進み、他のプロセッサモジュールに対するアクセス処理となり、これは図30のローカルプロセッサモジュールのライト処理を起動することになる。
4.キャッシュユニットのアクセス競合処理
本発明のキャッシュコヒーレンス装置にあっては、複数のプロセッサモジュールの各々のプロセッサエレメント毎に設けたキャッシュユニットは、モジュール内のプロセッサエレメント及び外部のプロセッサモジュールのアクセス対象となり、このため特定のキャッシュユニットにアクセスが集中する可能性がある。
例えばリモートのプロセッサモジュール内のプロセッサエレメントとキャッシュユニット間でデータ授受が行われているとき、外部のホームとして機能するプロセッサモジュールからのリモートコマンドがスヌープバスに現れたとき、後発のリモートコマンドは、先発したキャッシュ制御によってリトライが指示される。これは、先発のコマンドによって、キャッシュ状態が遷移過渡期にあるため、リモートコマンドへの対処が決定できないからである。
このように、リモートのプロセッサモジュール内でのデータの授受が際限なく続いた場合、リモートコマンドを送出したホームのプロセッサモジュールは、リトライを繰り返す場合がある。このときシステムバスに対するバス接続ユニットでは、アクセス応答の時間監視を行っており、リトライの繰り返しがバスタイムアウトの引金になる。
図34において,プロセッサモジュール10−1は,アクセス対象となるデータのアドレスを主記憶28に持つことからホームとして機能する。この主記憶28のアクセスアドレスのデータは最新データでないことから,ディレクトリを管理するメモリ管理ユニット26はダーティ状態Dを登録している。このアクセスアドレスのデータの最新データは、プロセッサモジュール10−2のキャッシュユニット群18における4番目のプロセッサエレメントPE#3のキャッシュユニットに排他的ダーティ状態EX&Dで保持されている。
この状態でプロセッサモジュール10−1の第4プロセッサエレメントPE#3でライトコマンドP−WTが発生し、またプロセッサモジュール10−2の第1プロセッサモジュールPE#0で同じアドレスに対するライトコマンドP−WTが発生したとする。
プロセッサモジュール10−2にあっては、第1プロセッサエレメントPE#1の発生したライトアクセスに基づき、キャッシュユニット18−1からスヌープバス22に、aのようにコヒーレントライト&インバリデートのCRIコマンドが発行される。この場合、第4プロセッサエレメントPE#3のキャッシュユニット18−4にアクセスアドレスのデータが排他的ダーティ状態EX&Dで記録されているため、cのように第4プロセッサエレメントPE#3のキャッシュユニットから第1プロセッサエレメントPE#0に対しデータが供給される。
このようなプロセッサモジュール10−2内におけるアクセスに並行して、プロセッサモジュール10−1の第4プロセッサエレメントPE#3のライトアクセスに基づき、システムバス12にリモートコマンド220が送出され、bのようにリモートとなるプロセッサモジュール10−2のスヌープバス22にリモートコマンドが現れる。
このときa,cに示した内部のプロセッサエレメントPE#0,#3の間のアクセスが終了していれば問題ないが、アクセス中にリモートコマンドが現れるとバスビジーとなって、プロセッサモジュール10−1に対しシステムバス12を介してリトライを指示するためのリプライコマンド230がeのように送出される。
このため、リプライコマンド230を受けたプロセッサモジュール10−1は、再度リモートコマンド220をプロセッサモジュール10−2に送出するリトライ動作を行うが、このときのプロセッサモジュール10−2の内部のアクセスによりスヌープバス22がビジーであると、再度リプライコマンド230によるリトライとなり、リトライが際限なく続く可能性がある。
図35は、リモートコマンドに対するリトライ指示が繰り返されるプロセッサモジュール10−2の処理のタイムチャートである。
図35のタイムチャートにあっては、横軸にバスクロックサイクルの処理タイミングを示し、縦軸にスヌープバス22の使用中のプロセッサエレメント、プロセッサエレメントPE#0〜#3ごとのビジー期間、更に各プロセッサエレメント#0〜#3に対応したキャッシュステータス信号CST0〜3を示している。
まずaのように、第1プロセッサエレメントPE#0のライトコマンドの発行に伴い、スヌープバス22がプロセッサエレメントPE#0で占有され、コヒーレント&インバリデートのCRTコマンドが送出される。このCRTコマンドに伴い、アクセス先のプロセッサエレメントPE#0のビジー状態が設定される。アクセス先となるプロセッサエレメントPE#0のビジー期間中に、bのように、外部のプロセッサエレメント10−1からのリモートコマンド#RのCRIコマンドが現われると、アクセス先のプロセッサエレメントPE#0はビジー状態にあることからビジー応答となり、例えば4サイクル後のdのタイミングでリモートコマンド#Rに対するビジー応答のリプライコマンドがプロセッサモジュール10−1に送出される。
一方、bのリモートコマンド#RのCRIコマンドの後にプロセッサエレメントPE#3からデータトランスファのDTコマンドが現われ、CRIコマンドを受けたプロセッサエレメントPE#0から要求元のプロセッサエレメントPE#3に対するデータ転送が行われる。このcのDTコマンドに基づくデータ転送の終了後に、eのように、プロセッサエレメントPE#1のCRIコマンドがスヌープバス22に現われ、このアクセス要求先がビジーリプライとなったリモートコマンド#Rと同じプロセッサエレメント#0であったとすると、再びプロセッサエレメントPE#0がビジー状態となる。
このため、eのリモートコマンドに対するビジーリプライに基づいてプロセッサモジュール10−1から、fのようにリモートコマンド#Rのリトライがスヌープバス上に現われても、アクセス要求先となるプロセッサエレメント#0はビジー状態にあるため、hのように、リモートコマンド#Rに対するビジーリプライとなる。
そして、このようなリモートコマンド#Rに対するアクセス要求先のプロセッサエレメント#0のビジー状態によるリトライ指示が際限なく繰り返され、結局はプロセッサモジュール10−1からのアクセスがバスタイムアウトとなってエラー終了してしまう。
このような特定のキャッシュユニットにおけるアクセスの競合に対し本発明にあっては、プロセッサモジュールの各プロセッサエレメントの中に、自己のアクセス処理中にリモートコマンドを受けてリトライの指示を行ったことを記憶するフラグと、そのときのアクセスアドレスを保持するアドレスレジスタを設ける。
そして、リモートコマンドに対するリトラスの指示を行ったことを示すフラグが有効な期間の間は、アドレスレジスタにセットしたアクセスアドレスと同じリモートコマンド以外のアクセス要求は全て受け付けずにリトライを指示するように構成する。
このため、プロセッサモジュールのスヌープバス22上で内部的なアクセス中にリモートコマンドによるアクセスが競合した場合、1回はリトライ指示となるが、2回目のリトライによるリモートコマンドについては、他のアクセスが一切拒否されている。このため、2回目のリモートコマンドによるアクセスを優先的に受け付けた処理を行うことができる。
図36は、プロセッサエレメントにリモートコマンドのアクセスを優先させるためのフラグ及びアドレスレジスタを設けた場合の本発明による処理動作のタイムチャートである。
図36において、aのようにプロセッサエレメントPE#0のライトアクセスによるCRTコマンドがスヌープバス22に現われたならば、このCRTコマンドを発行したプロセッサエレメントPE#0において、bのように、プロセッサエレメントPE#3側のアクセス対象となるアドレスをレジスタに格納する。
プロセッサエレメントPE#0のCRIコマンドに伴うプロセッサエレメントPE#0のビジー期間中に、cのようにリモートコマンド#RのCRIコマンドが現われると、dのようにリモートコマンド#Rに対するリトライ指示を行ったことを示すフラグをセットする。
この第1回目のリモートコマンド#Rについては、図35と同様、fでビジーリプライによるリトライ指示となる。続いてeのアクセス要求先のプロセッサエレメントPE#3からのデータ転送が行われ、スヌープバス22の使用が解除された後に、fのように別のプロセッサエレメントPE#1から同じプロセッサエレメントPE#3の同一アドレスに対しCRIコマンドが発行されたとする。
これに対し、1回目のリモートコマンド#Rに対しリトライ指示を行ったプロセッサエレメントPE#0は、リモートコマンドに対しリトライ指示を行ったことを示すフラグのセット状態と、そのときのアクセスアドレスを記憶保持していることから、fのプロセッサエレメントPE#1のCRIコマンドに対しgでバスビジーとなり、hでプロセッサエレメントPE#1に対するビジーリプライによってリトライを指示し、アクセス要求を拒否する。
続いてiでリトライによるリモートコマンド#Rが現われると、このときアクセス要求先のプロセッサエレメントPE#0は空き状態にあることから、リモートコマンド#RのCRIコマンドによる処理が受け入れられ、リモート側に対するデータ転送に入る。このデータ転送を開始すると、その後のタイミングで、(10)に示すように、プロセッサエレメント#0に記憶されていたフラグ及びアクセスアドレスは順次初期化されて解除され、リトライを行ったリモートコマンド#Rに対する優先受付けを解除することになる。
尚、図36のタイムチャートは外部のプロセッサモジュールからのリモートコマンドと内部のプロセッサエレメントのアクセスコマンドの競合を例にとっているが、内部のプロセッサエレメント同士のアクセスコマンドの競合についても同様な処理により、後続したアクセスコマンドは1回リトライとなるが、2回目については優先的に受け入れられ、スヌープバス22上におけるキャッシュコヒーレントのためのアクセス競合を適切に調整することができる。
5.コピーバックの書込所有権
図37は、プロセッサモジュール10−1のキャッシュユニットのいずれかで保有している最新データを、最新データのリプレースが発生した際に分散型の主記憶としてのローカルストレージ28にコピーバックするための書込所有権の移動に関する制御手順の説明図である。
いまプロセッサモジュール10−1において、分散型主記憶としてのローカルストレージ28のデーダか最新データでなく、スヌープバス22でメモリ管理ユニット26に接続された4つのキャッシュユニットの内のキャッシュユニット18−1,18−4に存在していたとする。更に同じ最新データを共有しているキャッシュユニット18−1,18−4の内、キャッシュユニット18−1が、最新データをローカルストレージ28にコピーバックする書込所有権を保有していたとする。
この時のキャッシュ状態は、最新データ及び書込所有権を保有したキャッシュユニット18−1がシェアードダーティ状態EX&Dで表わされ、最新データを保有するが書込所有権はもたないキャッシュユニット18−4がシェアードモディファイ状態SH&Mで現わされる。更にメモリ管理ユニット26にあっては、ローカルストレージ28の対象データがダーティ状態Dにあることを表わしている。ここでローカルストレージ28へのコピーバックのための書込所有権を保有しているキャッシュユニット18−1をオーナーという。
このような図37のプロセッサモジュール10−1におけるキャッシュ状態で、オーナーとして書込所有権を保有しているキャッシュユニット18−1の最新データがプロセッサの動作によりデータ破棄等でリプレースされたとする。このリプレースに伴い、スヌープバス22にはリプレースコマンドP−RPが発生する。また書込所有権を保有していたキャッシュユニット18−1は無効状態INVに遷移する。
一方、最新データを保有しているが書込所有権を保有していないキャッシュユニット18−4は、スヌープバス22に表われたリプレースコマンドP−RPに基づき、書込所有権の委譲を受けてオーナーとなり、シェアードダーティ状態EX&Dに遷移する。このため、メモリユニット18−1で最新データのリプレースが行われても、書込所有権は別のキャッシュユニット18−4に移り、最新データのローカルストレージ28に対するコピーバックはこの時点では行われない。
書込所有権が移った後にキャッシュユニット18−4で同様なプロセッサ動作によるリプレースが起きると、この場合には他のメモリユニットに書込所有権を移すことができないことから、ローカルストレージ28に対する最新データのコピーバックが行われる。
またキャッシュユニット18−1からキャッシュユニット18−4に書込所有権を委譲した際に、メモリ管理ユニット26にあっては、書込所有権の委譲の対象となったデータについてダーティ状態Dを保有しているが、書込所有権がキャッシュユニット18−1,18−4間で行われても、このダーティ状態はそのまま維持する。
メモリ管理ユニット26のダーティ状態は、最新データをもつキャッシュラインが別のプロセッサモジュールに移って初めて移動することになる。またローカルストレージ28に対する最新データのコピーバックが行われると、ダーティ状態Dはクリーン状態Cに遷移する。
図37は、4つのキャッシュユニット18−1〜18−4の内の2つにローカルストレージ28の最新データが保有されている場合を例にとっているが、3つまたは4つのキャッシュユニットに最新データが保有されている場合には、書込所有権を委譲するキャッシュユニットが複数となるため、この場合には例えば図38に示す予め定めた順番に従った書込所有権の委譲が行われる。
図38は、キャッシュユニット18−1〜18−4の識別番号を#0〜#3として表わし、書込所有権を保有してリプレースしたキャッシュユニットをインデックスとして残りの3つのキャッシュユニットに対する書込所有権を移す順番を示している。
例えばキャッシュユニット#0が書込所有権を有し、他のキャッシュユニット#1〜#3の3つが最新データを保有していた場合には、キャッシュユニット#0のリプレースが起きると書込所有権を移す優先度は#1,#2,#3の順番に優先度が決まっている。このため、最も優先度の高いキャッシュユニット#1に書込所有権を委譲する。そして次はキャッシュユニット#2、そして最後はキャッシュユニット#3となる。勿論、書込所有権を移すキャッシュユニットの順番は図38のユニット識別番号以外にも適宜に定めることができる。
6.システム共通バス
(1)バス構成
図39は、図3の本発明によるキャッシュコヒーレンス装置を基幹としたサブシステムの構成図である。図39において、サブシステム500−1は基本システム501として例えば5つのプロセッサモジュール10−1〜10−5を、第2共有バスとしてのシステムバス12により接続している。システムバス12にはバス調停を行うバスアービタ502が設けられる。
このような基本システム501に対し、例えばプロセッサモジュール510−1〜510−3の3台をバスアービタ503を備えたシステムバス12−10に接続した拡張システム506を接続している。基本システム501に対し拡張システム506は、同じ構成のバスアービタ及びプロセッサモジュールを使用している。更に基本システム501のシステムバス12に対しては、異種バス拡張ユニット540を介して異種システム505を接続している。異種システム505はシステムバス542により適宜の処理ユニット544−1〜544−3を接続している。異種サブシステム505は、本発明によるキャッシュコヒーレンス装置を実現する基本システム501,拡張システム506とは全く異なったシステムであり、例えば外部記憶装置に対するI/Oシステムを構成している。
このようなサブシステム500−1に対しては、同じ構成をもつ別のサブシステム500−2を拡張することができる。サブシステム500−1は、サブシステム間接続ユニット512により拡張したサブシステム500−2と接続することができる。サブシステム500−2側もサブシステム500−1側と同様、サブシステム間接続ユニットを介して自己のシステムバスと接続している。
ここで基本ユニット501のシステムバス12に対しては、最大で例えば16台のモジュールもしくはユニットを接続することができる。この実施形態では、システムバスに5台のプロセッサモジュール10−1〜10−5、サブシステム間接続ユニット512、異種バス拡張ユニット540及びバスアービタ502の8台を接続している。
システムバス12に接続可能なモジュールもしくはユニットに対しては、ユニットID#0〜#15が割り当てられる。例えばプロセッサモジュール10−1〜10−5にはユニットID(UID)#0〜#4が割り当てられ、サブシステム間接続ユニット512にはユニットID#6が割り当てられ、異種バス拡張ユニット510にはユニットID#8が割り当てられ、更にバスアービタ502にはユニットID#16が割り当てられている。
残りのユニットIDは空きとなっている。なおバス拡張ユニット504は単なるシステムバス12間のインタフェースであり、ユニットIDの指定は不要である。
バス拡張ユニット504を介して接続した拡張システム506のシステムバス12−10に接続しているバスアービタ502及びプロセッサモジュール510−1〜510−3についても、システムバス12−10に固有な16個のユニットIDが適宜に割り当てられている。更に異種サブシステム505については、基本システム501や拡張システム506とは全く異なった異種システム固有のユニットID#A,#B,#Cが割り当てられている。
図40は、図39の基本システム501に設けているシステムバス12の信号線の構成である。図4040において、プロセッサモジュール12−1〜12−5とバスアービタ502の間は、基本的にはバスデータ線507とタグ制御線509で構成される。
バスデータ線507には共通データバス線514とデータパリティ線516が含まれる。共通データバス線514は例えば128回線で構成され、1バイトを8ビットとすると16バイトのビットデータを並列転送することができる。データパリティ線516は16回線であり、1バイトのデータパリティを転送する。
タグ制御線は、バスリクエスト線520、緊急バスリクエスト線522、バスグラント線524、バスID線526、ユニットID線528、ホルト線530、マスタ権切替線532、インストール線534、ディスコネクト通知線536及びクロック線538で構成される。
このような図40のデータバス12の構成を更に詳細に説明すると次のようになる。まず共通データバス線514及びデータパリティ線516は、全てのプロセッサモジュール12−1〜12−5とバスアービタ502に共通に接続され、データ128ビット(16バイト),パリティ16ビット(1バイト)の並列伝送を双方向に行ってデータを授受する。
共通タグバス線518は4回線で構成され、全てのプロセッサモジュール12−1〜12−5とバスアービタ502に共通接続される。この共通タグバス線518の信号を参照することにより、そのときのバスサイクルの共通データバス線514上のデータの種類を知ることができる。共通タグバス線518で示される共通データバス線128上のデータの種類は図41のようになる。
図41において、タグバスコード(TBコード)は、3ビットのコードにより共通データバス線514の各バスクロックサイクルにおける動作を指定している。この共通タグバス線518の信号状態は、プロセッサモジュール12−1〜12−5における送信元となるバスマスタ及び宛先となるバススレーブ、更にバスアービタ502によって参照され、後の説明で明らかにするバスクラント(使用許可)の切替え、バスサイクルの切替え、及びデータ受信の制御を行う。
図41のタグバスコード0番は、コマンド終結とバス使用権の継続を意味する。タグバスコード1番はコマンド終結とバス使用権の開放を意味する。タグバスコード2番はコマンドの継続を意味する。タグバスコード3番はリトライ(無効化)とバス使用権の開放を意味する。タグバスコード4番はシングルワードコマンドとバス使用権の継続を意味する。タグバスコード5番はシングルワードコマンドとバス使用権の開放を意味する。タグバスコード6番はマルチワードコマンドの開始、必要ならばバス使用権の継続を意味する。タグバスコード7番はアイドルサイクルを意味する。
ここでシングルワードコマンドとは、1バスクロックサイクルでパケット転送を終了するコマンドである。これに対しマルチワードコマンドとは、複数のバスクロックサイクルでのパケット転送を必要とするコマンドである。またバス使用権の開放とは、これを示すタグバスコードのバスサイクルでバス使用権を放棄し、他のバス使用要求者にバスを開放することを示す。
またバス使用権の継続とは、タグバスコードが示すバスサイクルの次のサイクルも継続してバスを使用することを示す。更にリトライとは、タグバスコードが示すバスサイクル(バスコマンド)を強制終了してリトライすることを示す。このときバススレーブは、リトライ指示されたバスコマンドを破棄する。またリトライを実行するか否かはシステムのインプリメントに依存している。更にまたアイドルサイクルとは、如何なるユニットもバスを使用していないときの状態を示す。このときバススレーブ側は、アイドルサイクルとなるバスサイクルは無視することになる。
次に図40のバスリクエスト線520と緊急バスリクエスト線522を説明する。バスリクエスト線520及び緊急バスリクエスト線522はそれぞれ15の信号線で構成され、プロセッサモジュール12−1〜12−5とバスアービタ502との間で1対1に接続され、プロセッサモジュール12−1〜12−5側からバスアービタ502に対しバス転送要求を行う。
通常の転送要求については、バスリクエスト線520のみによる転送要求が行われる。これに対し異常検出等の緊急時にあっては、バスリクエスト線520と緊急バスリクエスト線522の両方を使用した転送要求が行われる。
図42は、バスリクエスト線520と緊急バスリクエスト線522の組合せによるバスアービタ502に対する要求事項を示す。まずバスリクエストBRQと緊急バスリクエストBREが共にLレベルの場合には、ユニットID#Nのスロットのユニットが非動作状態にあることを示す。
次の緊急バスリクエストBREのみがHレベルとなった場合はバス要求なしであり、現在バスリクエストを行っていないユニットが緊急バスリクエストのみをアサートした場合である。
3番目のバスリクエストBRQのみがHレベルとなるのは通常のバス要求であり、緊急バスリクエスト以外の通常のバス要求である。4番目のバスリクエストBRQ及び緊急バスリクエストBREの両方がHレベルとなるのは緊急バス要求であり、バススレーブがエラーを検出したときに、エラーリプライのためのバス獲得のためにこの要求を行う。
再び図40を参照するに、次のバスグラント線524はバスアービタ502と各プロセッサモジュール12−1〜12−5との間で1対1に接続され、バスアービタ502がバスグラント線524の信号をHレベルとすることで、バスの使用許可を与えたことを示す。
バスID線526は、プロセッサモジュール12−1〜12−5及びバスアービタ502が接続されているシステムバス12の番号を設定している。同じシステムバスに接続されているユニットは全て同じ値が設定される。図39のシステム構成にあっては、基本システム501のシステムバス102にバスID#1が設定される。これに対し、バス拡張ユニット504を介して接続した拡張システム506のシステムバス12−10にはバスID#2が設定される。
次に図40のユニットID線528を説明する。ユニットID線528は、バスアービタ502及びプロセッサモジュール12−1〜12−5のバス上での識別番号を設定する。図39にあっては、プロセッサモジュール10−1〜10−5にユニットID#1〜#5を設定し、バスアービタ502にユニットID#16を設定している。
このため、バスID線526とユニットID線528によるバスIDとユニットIDの組合せでシステム全体におけるプロセッサモジュール12−1〜12−5及びバスアービタ502の番号が一意に決まる。
次に図40のホルト線530とマスタ権切替線532を説明する。ホルト線530はバスアービタ502からプロセッサモジュール12−1〜12−5を含む全ユニットに例えば9通りに接続され、ホルト線530をHレベルとすることでバスアービタ502が自分自身の故障を検出して停止状態にあることを示す。
マスタ権切替線532はバスアービタ5−2からプロセッサモジュール12−1〜12−5を含む全ユニットに共通に接続され、ホルト線530と共にバスの調停処理に使用される。このホルト線530とマスタ権切替線532の信号の組合せによるバス調停処理は、図43のようになる。
図43において、まずホルトHLTがHレベルでマスタ権切替MFC(MasterForce Change) がLレベルの状態は、バスアービタ502の非実装を意味する。次のホルトHLT及びマスタ権切替MFCの両方がHレベルの場合には、バスアービタ502のホルト即ちバスアービタ502の自己診断等でエラーとなり、バスアービタ502が停止状態にあることを通知する。
3番目のホルトHLT及びマスタ権切替MFCが共にLレベルの場合はバスグラントGBRの通常切替であり、バスアービタ502がバス要求を保持しているときにバスサイクルの終了を検出した場合のバスグラントGBRを切り替えるタイミングを意味する。最後のホルトHLTがLレベルでバス権切替MFCがHレベルの状態はバスグラントGBRの強制切替えであり、バスアービタ502がバス要求を保持しており、且つそのバスが未使用の場合のバスグラント切替タイミングを与える。
再び図40を参照するに、インストール線534はプロセッサモジュール12−1〜12−5を含む各ユニットとバスアービタ502の間で1対1に接続され、Lレベルにセットすることでバスアービタ502に対しユニットが実装されていることを通知する。
ディスコネクト通知線536は、プロセッサモジュール12−1〜12−5を含む各ユニットとバスアービタ502との間で1他1に接続される。ディスコネクト通知線536をLレベルにすることで、バスアービタ502に対しユニットがシステムバス12から切り離された状態にあることを通知する。
(2)バスアビトレーション動作
次に図40のバスデータ線507とタグ制御線509で構成されるシステムバス12のバスアビトレーション動作を説明する。本発明のシステムバスのバスアビトレーション動作としては、ファーストモードとセーフティモードの2つのモードがある。また優先バスアビトレーションとしてバススレーブが優先バスアビトレーションを要求する場合と、バスアービタが優先バスアビトレーションを要求する場合とに分けられる。
図44は、ファーストモードによるアビトレーションのタイムチャートであり、横軸のバスクロックサイクルT1,T2,T3,・・・に対し縦軸方向にバスアービタ502の内部動作とシステムバス12上のインタフェース信号に分けて示している。バスアービタ502の内部動作としては、バスリクエストのホールド動作である。システムバス12上のインタフェース信号としては、バスリクエスト、バスグラント、タグバス及びデータバスを示している。
まずサイクルT1で、ユニットID#0,#1からaに示すように、バスリクエスト信号の1サイクルのアサートが行われたとする。このときデータバスはアイドル状態にあることから、バスアービタ502は全てのバス要求元からのバスリクエストの立上がりを監視している。
aのようにユニットID#0,#1の2つのバスリクエスト信号がアサートされると、次のサイクルT2でbに示すように全てのリクエスト要求をホールドする。ここで複数のバスリクエストがあった場合には、ユニットIDの番号の若い方が優先順位が高いものとする。
このためバスアービタ502は、アイドル状態からの優先順位の高いユニットID#0に対するバスグラント信号を、cに示すように、マスタ権切替信号と共にアサートする。続いてバスアービタ502は、次のサイクルT3で、バスの使用権を許可したユニットID#0のバスリクエストのホールド要求を破棄すると同時に、他のホールド要求があればバスグラント信号を切り替える。
このときユニットID#1のホールド要求があることから、バスリクエスト信号をユニットID#1に切り替える。このようにバスアービタ502からのバスグラント信号及びマスタ権切替信号により許可を受けたバスマスタとしてのユニットID#0は、次のサイクルT3からデータ転送を開始する。このサイクルT3からはタグバス信号が図41に示したタグバスコード010,100または110(CC,SC&C,MC&S)のいずれかを示す。この場合には、複数のバスクロックサイクルでデータを送ることから、タグバスコードは110(MC&S)のマルチワードコマンドの開始となる。
このようなサイクルT3からのデータ転送中にバスシーケンスが、例えばサイクルT5に示すようにタグバスによって終了ENDを示すと、dのように、このときのバスグラント信号に従ってバスマスタがユニットID#1に切り替わり、次のサイクルT6から、バスマスタとなったユニットID#1からのデータ転送を開始する。ここでデータ転送終了を示すタグバスのタグバスコードは、図41の001,011,101(CE&E,リトライ,SC&E)のいずれかとなる。
一方、バスアービタ502はサイクルT2で一旦保持したユニットID#1からのバスリクエストの処理中に、例えばサイクルT3,T4のように他のユニットID#0,#2からのバスリクエストの立上がりを検出すると、それぞれのバスリクエストを別途記憶する。そしてサイクルT5のように、ホールド要求がないときのタグバスによる終了通知のタイミングで、eのように、ユニットID#0,#2の新たなバスリクエストをホールドする。
更にサイクルT4のユニットID#0からの2回目のバスリクエストはシングルコマンドであり、このためサイクルT8でユニットID#1のデータ転送が終了すると、次のサイクルT9で、サイクルT3で出された下位のユニットID#2のバスリクエストに先行してユニットID#0のシングルコマンドのデータ転送を行う。このシングルコマンドのデータ転送は同時に転送終了を意味することから、ユニットID#1がサイクルT6で行ったバスリクエストのホールドをサイクルT10のfのように行う。
図44のファーストモードのバスアビトレーションにあっては、バスアービタ502にバスリクエストがホールドされている限り、データバスに空きサイクルを生ずることなく連続的にバス転送が行われ、空きサイクルを発生しないことでバス転送速度を高めることができる。
図45は本発明のバスアビトレーションにおけるセーフティモードのタイムチャートである。このセーフティモードのタイムチャートにあっても、図44のファーストモードと同様なユニットID#0〜#2によるバスリクエストが行われた場合を例にとっている。
セーフティモードにあっては、バスアービタ502からのバスグラント信号とマスタ権切替信号のアサートによりバスマスタとしてのユニットIDが許可を受けた後に、1サイクルのアイドルサイクルを置いてデータ転送を開始するようにしている。
即ち、サイクルT1におけるaのバスリクエストに対し、サイクルT2でbのようにバスアービタ502のバスリクエストのホールドが行われ、優先順位の高いユニットID#0に対するバスグラント信号と更にマスタ切替信号をcのようにアサートすると、次のサイクルT3をアイドルサイクルとした後、サイクルT4よりデータ転送を開始する。
このサイクルT3のアイドルサイクルはタグバスの過渡状態を安定化させるための期間であり、このアイドルサイクルにおいて全てのユニットはタグバスの値を無視する。サイクルT6でユニットID#0のバスマスタによるデータ転送が終了して、そのときのユニットID#1のバスグラント信号によるデータ転送についても、サイクルT7の1サイクルのアイドル期間を設けた後に、fのようにデータ転送を開始している。
このようにバスアービタ502からデータ転送の許可を受けてデータ転送開始までの間に1サイクルのアイドル期間を置く以外の動作は、図44のファーストモードと同じである。
図46は、バススレーブがデータ転送中にエラーを検出した場合のエラーリプライ動作のための優先バスアビトレーションのタイムチャートである。いまサイクルT1に示すように、ユニットID#0〜#2の3つのユニットからのバスリクエストがアイドル状態で同時に行われ、次のサイクルT2でバスアービタ502に全てのバスリクエストがホールドされると、優先順位の最も高いユニットID#0に対しバスアービタ502よりバスグラント信号が出力される。
同時にマスタ権切替信号もアサートされることで、サイクルT3よりバスマスタとなったユニットID#0からバススレーブとしての例えばユニットID#3に対しデータ転送が開始される。このデータ転送中のサイクルT4でバススレーブとなるユニットID#3でエラーを検出したとすると、バスアービタ502に対しユニットID#3からバスリクエスト信号及び緊急バスリクエスト信号の両方がaのように出力される。
サイクルT6のバスリクエスト信号及び緊急バスリクエスト信号を受けたバスアービタ502は、バスリクエストを最優先でホールドすると同時に、bのように、バスを早期に切り替えるためにバスグラントを、エラー検出を行ったユニットID#3に切り替える。このためサイクルT8でデータ転送が終了すると、このときバスグラント信号が有効となっているエラー検出を行ったバススレーブとしてのユニットID#3をバスマスタに切り替え、サイクルT9で、cのように、エラーを検出したバスマスタのユニットID#3からエラーリプライを行わせる。
このときバスアービタ502内の最優先のホールド要求は破棄され、次のサイクルT10からは通常のアビトレーションを続行する。ここで、バススレーブ側で検出するエラーには物理バッファフル等のブロック検出も含まれている。このようにバス転送中にバススレーブ側でエラー検出が行われると、次のバス転送に切り替える前に強制的にエラー検出を行ったバススレーブがバスマスタに切り替わってエラーリプライを行うことができ、バス転送中のエラーを迅速に検出してリトライ等の対応処置をとることができる。
図47は、バススレーブ側が確定する前のバス転送中に起きたエラーをバスアービタ502で検出した場合のエラーリプライのための優先バスアビトレーションのタイムチャートである。即ち本発明のバス転送にあっては、スプリット型のパケット転送を採用しており、パケットの第1ワードとしてコマンドワードを転送するため、コマンドワードの宛先フィールドの解読が終了しないとバススレーブが確定しない。
このバススレーブが確定するまではバスアービタ502でバス転送のエラーを監視し、エラーを検出するとスレーブの代わりにバスアービタ502がエラーリプライを行うようになる。
図47にあっては、サイクルT1のユニットT1のユニットID#0〜#2からのバスリクエストがあると、サイクルT2で全てバスアービタ502がホールドする。そして優先順位の最も高いユニットID#0について、バスグラント信号を有効とすると共にマスタ権切替信号をアサートし、次のサイクルT3からデータ転送を開始する。
このサイクルT2において、バスアービタ502はaのように、バス使用許可を与えたバスマスタを示すユニットID#0のバスマスタフラグをもっており、このバスマスタフラグをユニットID#0のサイクルT3〜T8に亘るバスサイクル期間中ホールドしておく。
バスマスタであるユニットID#0からのデータ転送中のサイクルT5で、bのようにアービタ502がエラーを検出した場合、例えばパケットヘッダのパリティエラーを検出した場合、そのエラー内容を保持すると同時にバスアービタ502の内部に自分自身の緊急バス要求フラグをcのようにセットする。尚、エラー検出が行われたサイクルT5は、バスマスタとしてのユニットID#01が、連続した複数のバスコマンドを転送中にエラーを検出した例である。
続いてバスアービタ502は、自分自身のセットした緊急要求バスフラグcにより、現在ホールドしている他のバスリクエストをマスクし、ホールド中のバスリクエストについてバスグラントをアサートしないようにする。そしてサイクルT8でバスマスタをユニットID#0としたデータ転送を検出すると、このバスマスタ切替タイミングでバスアービタ502自身がバスマスタとなって、dのようにサイクルT9でエラーリプライを転送する。
即ち、バス上には現われないバスアービタ502の内部でのアビトレーションにより、バスアービタ502自身がバスマスタとなってエラーリプライを行うことになる。このようなバスアービタ502のエラーリプライが済むと、同時にバスアービタ502内でセットした緊急バス要求フラグ及びバスマスタフラグが破棄され、次のバスマスタとしてのユニットID#1への切替えがバスグラントにより行われ、次のサイクルT10から通常のアビトレーションを実行する。
(3)バス転送シーケンス
次に図40のシステムバス12上におけるバスコマンド及びデータの転送シーケンスを説明する。図48はユニット#1からユニット#2にメモリの読出要求を行うときの転送シーケンスである。ここで読出要求元のユニット#1をソースユニットとし、読出要求先のユニット#2を宛先ユニット(ディストネーションユニット)とする。
まず要求元のユニット#1は、コマンド内容、要求元、要求先、転送バイト数及びアクセスアドレスを指定したパケットヘッダを、バスコマンドとして送信する。このパケットヘッダはバスコマンドの第1ワードを構成する。具体的には、ユニット#1はパケットヘッダのコマンドフィールドにメモリリードを指定し、ソースフィールドに要求元となる自分自身のユニットID#1を指定し、宛先フィールドに要求先のユニットID#2を指定する。
更に転送バイト数を示すサイドのフィールドに16バイトを指定し、更にアドレスフィールドにアクセスアドレスを指定したパケットヘッダを作成して送信する。本発明のバス転送にあっては、パケットヘッダとして送信されるバスコマンドの第1ワードには、要求元を示すソースフィールド、要求先を示す宛先フィールドに加え、第2の要求先を示す第2宛先フィールドが設けられている。
ここで、通常使用される宛先フィールドは、以下、第1宛先フィールドという。尚、第1宛先フィールドは、第2宛先フィールドの指定がない場合には単に宛先フィールドという場合もある。このパケットヘッダとして送出されるバスコマンドの第1ワードのソースフィールド、第1宛先フィールド及び第2宛先フィールドをもつバスコマンドの詳細は、後の説明で明らかにされる。
図48のメモリリードの転送シーケンスにあっては、宛先は1つであることから、ユニット#1から送出されるパケットヘッダは第1宛先フィールドに読出要求先ユニットID#2を指定しているだけである。システムバスはユニット#1からのパケットヘッダの送信が終了すると開放され、次に割り当てられたユニットにバス使用権が移る。
読出要求先となるユニット#2にあっては、システムバス上の転送パケットを受信してその宛先フィールドのIDを識別しており、自分自身が指定されたパケットであればそれを受信し、受信パケットで指定された処理即ちユニット#1からのパケットヘッダで指定されたメモリのリード処理を開始する。ユニット#2において、要求されたリードデータが準備できたならば、bに示すリプライバスコマンドとデータを作成して返送する。
このリプライバスコマンドの第1ワードは、ソースフィールドに自分自身のユニットID#2を指定し、宛先フィールドに要求元のユニットID#1を指定し、コマンドフィールドはリプライコマンドであることを指定し、更に必要に応じたステータス情報を付加して送出する。リプライバスコマンドのパケットヘッダである第1ワードの送出が済むと、続けて指定バイト数16バイト分のデータを返送する。この実施例において、データバス幅は16バイトであることから、2ワードのリプライバスコマンドは2バスサイクルで転送を終了する。
図49は、本発明のシステムバスにおけるメモリライトの転送シーケンスである。まず書込要求元のユニット#1は、書込要求先となるユニット#2に対しバスコマンドの第1ワードとなるパケットヘッダを作成して転送し、パケットヘッダに続いて例えば32バイトデータを書き込む場合には、16バイト単位に分けて2ワードのデータパケットを転送する。
第1ワード目のパケットヘッダには、ソースフィールドを自分自身のユニットID#1とし、宛先フィールドを書込相手先のユニットID#2とし、コマンドフィールドにメモリライトを指定し、更にアドレスフィールドに32バイトアドレスを指定して、バスに送出する。
書込要求先のユニット#2にあっては、宛先フィールドで自分自身のユニットID#2を指定したパケットであればそのパケットを受信し、コマンドフィールドで指定された書込処理を開始する。書込処理が終了すると、bのように、書込要求元のユニット#1に対するリプライバスコマンドを作成して処理のステータスを返送する。
即ち、リプライバスコマンドはソースフィールドを自分自身のユニットID#2、宛先フィールドを書込要求元のユニットID#1、コマンドフィールドをリプライとし、更にステータスフィールドに例えば書込正常を示すステータスをセットして返送するようになる。
図50は、システムバスに接続している複数のユニットを同時に指定してデータを転送するブロードキャストの転送シーケンスである。この例では、ユニット#1がキャッシュコヒーレントのためのキャッシュインバリデートのバスコマンドを、ユニット#2,#3,#4にブロードキャストコマンドとして転送した場合である。
まずキャッシュインバリデートの要求元のユニット#1は、ブロードキャストバスコマンドのパケットヘッダにつき、ソースフィールドに要求元のユットID#1を指定し、ブロードキャストフィールドに要求先となるユニット#2,#3,#4の3つを指定する。更にコマンドフィールドにキャッシュインバリデートを指定し、更にアクセスアドレスを指定して送出する。
キャッシュインバリデートの要求先となるユニット#2,#3,#4のそれぞれは、要求元のユニット#1からのブロードキャストバスコマンドを受信し、ブロードキャストフィールドに自己の指定があればそれを受信し、指定されたキャッシュインバリデートの処理を開始する。キャッシュインバリデート処理が完了すると、完了した順番に要求元のユニット#1に対しリプライバスコマンドを送出する。
この例では、ユニット#2,#4,#3の順番にキャッシュインバリデート処理を終了してリプライバスコマンドを返送している。例えば最初のユニット#2にあっては、ソースフィールドを自分自身のユニットID#2とし、宛先フィールドを要求元のユニットID#1とし、コマンドフィールドでリプライを指定し、更にステータスフィールドにキャッシュインバリデートの処理結果をセットして返送する。ユニット#4,#3についても同様である。
要求元のユニット#1は全ての要求先のユニット#2,#3,#4からのリプライバスコマンドを受領し、そのステータス情報からキャッシュインバリデートの成功を認識すると、次の処理に移行する。図51は、図39において基本システム501のユニットから拡張システム506のユニットとの間でバス転送を行う場合の転送シーケンスである。図51にあっては、基本システムにおけるシステムバス1のユニット#1からバス拡張ユニット504を介して拡張システムのシステムバス#2のユニット#3にリード要求を行った場合の転送シーケンスである。
まずシステムバス#1のユニット#1は、aのように、システムバス#2のユニット#3を要求先とするバスコマンドを作成して送出する。このユニット#1からのバスコマンドは、ソーススフィールドに要求元のシステムバスを示すバスID#1とユニット#1を示すユニットID#1を指定している。また宛先フィールドには相手先のシステムバスを示すバスID#2と相手先のユニットを示すユニットID#3を指定している。
これ以外の点は、同じシステムバス上のバスコマンドと同様、コマンドフィールドにメモリリードを指定し、更に転送バイト数を指定して送信する。バス拡張ユニット504は、ユニット#1からのバスコマンドを受信し、このバスコマンドの宛先フィールドのバスID#2が、自分自身が接続拡張しているバスであることを認識すると、そのバスコマンドを受理し、システムバス#2に対し同じバスコマンドをbのように発行する。
システムバス#2のユニット#3にあっては、宛先フィールドのユニットIDが自己のユニットID#3であることを認識すると、そのバスコマンドを受信してリード処理を行い、リードデータが準備できたならば、cのように、コマンドを第1ワード、データを第2ワードとするリプライバスコマンドを送信する。
このリプライバスコマンドについても、ソースフィールドにシステムバスのID#2と自分自身のユニットID#3を指定し、宛先フィールドについては別のシステムバスのバスID#1とユニットID#1を指定し、更にコマンドフィールドにリプライを指定し、更にリード結果のステータスを付けて送信する。リプライバスコマンドの1ワード目の送信が済むと、次の2ワード目の16バイトデータのパケットを送信する。
バス拡張ユニット504はcのリプライコマンドを受信し、その宛先フィールドのバスID#1から自分自身が接続拡張しているシステムバス#1であることを認識すると、同じリプライコマンドをシステムバス#1に転送する。システムバス#1のユニット#1は、このリプライコマンドから自分自身の宛先ユニットID#1を認識するとリプライバスコマンドを受信し、次の2ワード目の16バイトのリードデータを受信して処理を終了する。
図52は、図39におけるサブシステム500−1とサブシステム500−2の間のサブシステム間接続ユニット512を経由したバス転送のシーケンスである。
図52にあっては、サブシステム#1のユニット#1から別のサブシステム#2のユニット#3にリード要求を行った場合である。まず要求元となるサブシステム#1のユニット#1は、aのように、リード要求のためのバスコマンドを送出する。このバスコマンドはパケットヘッダを2つ使用した2ワードのバスコマンドで構成される。
まずバスコマンドの第1ワード目には、拡張サブシステム#2のアクセスを指定するための識別子、即ちサブシステム拡張識別子EXの指定を行う。続いてソースフィールドにサブシステム#1のバスID#1とユニットID#1をセットし、サブシステム#2に対するサブシステム間接続ユニット512のユニットID#6を宛先フィールドで指定する。
更にコマンドフィールドにはメモリリードを指定し、アドレスフィールドにはアクセスアドレスを指定し、更に図示しないサイズフィールドに転送バイト数を指定する。次の2ワード目はシステムバス拡張識別子EXの指定で付加された拡張バスコマンドであり、ソースフィールドに要求元のサブシステムID#1、バスID#1及びユニットID#1が指定される。
また宛先フィールドには、要求先のサブシステムID#2、要求先のバスID#2及び要求先のユニットID#3が指定される。この2ワードとなるバスコマンドがシステムバスに送出されると、サブシステム間接続ユニット512において、第1ワード目の宛先フィールドのユニットID#6を認識し、バスコマンドの第1ワード及び第2ワードを受信する。
そしてサブシステム#2側に設けているサブシステム間接続ユニット513に対し、同じバスコマンドをそのまま転送する。この転送制御はバスコマンドの第2ワード目の各IDにより定まる。サブシステム#1のサブシステム間接続ユニット512からのバスコマンドを受信したサブシステム#2のサブシステム間接続ユニット513は、バスコマンドの第1ワード目のソースフィールドにおけるユニットIDを自分自身のユニットID#7の指定に変更すると共に、宛先フィールドを第2ワードから解読したユニットID#3の指定に変更してシステムバス#2に送出する。バスコマンドの第2ワード目はそのまま送出する。
システムバス#2のユニット#3は、サブシステム間接続ユニット513から送出されたバスコマンドの第1ワード目の受信で宛先フィールドのユニットIDが自分自身のユニットID#3であることを認識すると、このコマンドを受信し、更に第2ワード目も受信する。そして第1ワード目のコマンドフィールドにより指定されたメモリリードを、指定されたアクセスアドレスについて行う。
リードデータが準備できると、dに示すようにリプライバスコマンドを送出する。このリプライバスコマンドは、第1ワード目のソースフィールドにサブシステム識別子EXをセットし、更にバスID#2及びユニットID#3をセットし、宛先フィールドはサブシステム間接続ユニット513のユニットID#7を指定する。もちろんコマンドフィールドはリプライを指定し、図示しないステータスもセットする。
リプライバスコマンドの第2ワード目は、ソースフィールドにサブシステムID#2、システムバスID#2及びユニットID#3を指定し、宛先フィールドについては要求元となるサブシステムID#1、システムバスID#1及びユニットID#1を指定する。そして第3ワード目がリードデータとなる16バイトデータである。
サブシステム間接続ユニット513は、ユニット#3から送出されたリプライバスコマンドの第1ワード目の宛先フィールドから自己のユニットID#7を認識すると、このバスコマンドを受信し、eのように、サブシステム間インタフェースを介してサブシステム#1のサブシステム間接続ユニット512にリプライバスコマンドの第1ワード、第2ワード、第3ワードを転送する。
サブシステム#1のサブシステム間接続ユニット512は、リプライバスコマンドの第1ワードのソースフィールドのユニットIDを自分自身のユニットID#6の指定に変更すると共に、宛先フィールドを要求元のユニットID#1に変更してシステムバス#1に送出する。
このソースフィールド及び宛先フィールドのユニットIDの変更は、受信したリプライバスコマンドの第2ワード目を参照することで指定変更できる。リプライバスコマンドの第2ワード目は、そのまま送出する。第2ワード目の16バイトデータについても、そのまま転送する。
サブシステム#1のユニット#1は、リプライバスコマンドの第1ワードの宛先フィールドから自己のユニットIDを認識すると、このバスコマンドの受信を開始し、第3ワードまで受信して処理を終了する。
図53は、本発明のシステムバスのバス幅を8バイトバスとした場合の転送シーケンスである。図40のシステムバスにあっては、共通データバス線514を128本とすることで16バイト転送を行っているが、システムによっては半分の8バイトバスを使用する場合もある。このように8バイトシステムバスを使用した場合には、今まで説明した16バイト幅の1クロックサイクルでのバス転送は2バスクロック分の転送を行うことになる。
図53は、8バイトバスを使用した場合のユニット#1からユニット#2にリード要求を行った場合の転送シーケンスである。ユニット#1は、16バイトのバスコマンドを8バイト単位の第1ワードと第2ワードに分けてシステムバスに送出する。8バイトバスコマンドの第1ワードには、ソースフィールド、宛先フィールド、コマンドフィールド及びサイドフィールドのそれぞれが設けられている。第2ワード目はアドレスフィールドである。
このような8バイトの2ワードで構成されるバスコマンドがシステムバスに送出されると、要求先のユニット#2はバスコマンドの第1ワード目の宛先ユニットID#2を認識してバスコマンドを受信し、第2ワード目で指定されたアクセスアドレスについてメモリのリード動作を行う。リードデータが準備できると、bのようにリプライバスコマンドを送出する。リプライバスコマンドは、8バイトの第1ワードがパケットヘッダとなり、その後ろに8バイトずつ分けた合計16バイトの2ワードを付加して送出する。
図54は、図39のサブシステム500−1における基本システム501と異種サブシステム505との間のバス転送シーケンスである。
図51において、基本システムのシステムバス#1は異種バス拡張ユニット540を介して異種システムバス#2に接続される。異種バス拡張ユニット540には、システムバス#1側のコマンドを異種システムバス#2側のコマンドに変換するコマンド変換機能が設けられている。
いま、システムバス#1のユニット#1から異種システムバス#2のユニット#Bに対しアクセス要求を行うものとする。ユニット#1はバスコマンドとして2ワードのパケットをパケットヘッダとして送出する。このバスコマンドの第1ワード目にはソースフィールドでバスID#1及びユニットID#1を指定し、また宛先フィールドにバスID#1と異種バス拡張ユニット540のユニットID#8を指定している。
更にコマンドフィールドには、異種システムバス#2のコマンド体系に変換するためのエミュレーション識別子EMが指定されている。第2ワード目は異種システムバス#2に適合したバスコマンドであり、ソースフィールドに異種システムバス#2空間における異種バス拡張ユニット540のユニットid#1が指定され、宛先フィールドには異種システムバス#2のユニットIDuid#Bが指定されている。
このシステムバス#1のユニット#1から送出された2ワードのバスコマンドは、異種バス拡張ユニット54において、第1ワード目の宛先フィールドから自己のユニットID#8を認識することで受信される。異種バス拡張ユニット540自身が接続拡張している異種システムバス#2に対するエミュレーションコマンドであることを認識すると、コマンド依存フィールドとなる第2ワードのみを異種システムバス#2にbのように送出する。
異種システムバス#2のユニット#Bは、その宛先フィールドのuid#Bから自己の宛先を認識して受信し、コマンドフィールドで指定された処理を実行し、処理が済むと、cに示すリプライコマンドを送出する。ユニット#Bからのリプライコマンドは第1ワードのソースフィールドにユニットid#Bを指定し、宛先フィールドに異種バス拡張ユニット540のユニットid#1を指定し、更に2ワード目にステータスやその他必要なデータを転送する。
異種バス拡張ユニット540は、ユニット#Bからのリプライバスコマンドの第1ワード目から自分自身が接続しているシステムバス#1に対するリプライコマンドであることを認識すると、このリプライコマンドを受理して、dのようにシステムバス#1側に同様なリプライバスコマンドを送出する。
このリプライバスコマンドの第1ワードはソースフィールドによりシステムバスID#1と異種バス拡張ユニット540のユニットID#8を指定し、宛先フィールドに要求元のシステムバスID#1のユニットID#1を指定している。第2ワード目及び第3ワード目は、異種システムバス#2のユニット#Bから送出されたバスコマンドがそのまま付加される。
このような異種バス拡張ユニット540による簡単なバスコマンドの変換により、異なるバスシステムのユニット間でのデータ転送が可能となる。またエミュレーションバスコマンドで使用するそれぞれのバス上におけるユニットIDは、各々のバス上で一意であればよく、拡張された異種システムバス上のIDも異種バス拡張ユニット540を含めて一意となる。
(5)バスコマンド
図55は、本発明のキャッシュコヒーレンス装置のシステムバス12のバス転送に使用するバスコマンドの基本的なコマンドフォーマットである。
図55において、1バイトを8ビットとすると、基本バスコマンドは16バイト長で構成される。図55にあっては、コマンドフィールドを4バイト(32ビット)幅に分けて示している。
基本バスコマンドは、先頭の基本バイト部分にソースフィールド552、第1宛先フィールド560及び第2宛先フィールド564を設けている。ソースフィールド552にはアクセス要求元の情報を指定する。第1宛先フィールド560には、ソースフィールドの要求元からアクセス要求を行う相手先の情報が指定される。第2宛先フィールド564には、ソースフィールド552と第1宛先フィールド560以外に、アクセスを行う別の相手先の情報が指定される。
具体的には、例えば図17に示した本発明のキャッシュコヒーレンス装置における読出モード2における処理動作を例にとると、次のようになる。図17は、アクセス要求元であるローカルのプロセッサモジュール10−1からアクセス対象となる主記憶を保持しているホームとなるプロセッサモジュール10−2に対しリード要求を行ったが、主記憶28に最新のデータが存在しておらず、リモートとなるプロセッサモジュール10−3のキャッシュユニットに最新データが存在している場合の処理である。
このようなリード処理にあって、まずローカルのプロセッサモジュール10−1からホームのプロセッサモジュール10−2にリード要求を行う場合には、図55のソースフィールド552にローカルのユニットIDを指定し、第1宛先フィールド560はホームのユニットIDを指定する。このとき第2宛先フィールド564は使用しない。
次にホームのプロセッサモジュール10−2からリモートのプロセッサモジュール10−3にリード要求を行う場合には、ソースフィールド552はホームIDとし、第1宛先フィールド560はリモートIDとし、更に第2宛先フィールド564に最初のアクセス要求元であるローカルIDを指定する。
更に、リモートのプロセッサモジュール10−3からリプライデータ260を送出する際には、図55のソースフィールド552にリモートIDを指定し、第1宛先フィールド560は要求元であるホームIDを指定し、更に第2宛先フィールド564には最初の要求元であるローカルIDを指定する。具体的には、リモートのプロセッサモジュール10−3で受信したバスコマンドと同じ情報をそのままセットしてリプライコマンドとしてのリプライデータを260を送出すればよい。
このように本発明のキャッシュコヒーレンス装置でローカル、ホーム、リモートとなる3つのプロセッサモジュール間でのデータ転送を必要とするリードアクセスにおいて、図55におけるソースフィールド552、第1宛先フィールド560及び第2宛先フィールド564のコマンドフォーマットが意味をもつことになる。
図55の基本バスコマンドにおいて、ソースフィールド552は実際にはソースバスIDフィールドとソースユニットIDフィールドに分けられている。ソースバスIDフィールドをもつことで、異なるシステムバス間でのデータ転送が可能となる。同様に、第1宛先フィールド560及び第2宛先フィールド564についても、宛先バスIDフィールドと宛先ユニットIDフィールドがそれぞれ設けられている。更に、第1宛先フィールド560と第2宛先フィールド564にはアクセスIDフィールドが設けられている。
第1宛先フィールド560のアクセスIDフィールドは、スプリット転送でのバスアクセスの多重動作を行うための動作識別ID番号を指定するフィールドであり、コマンドあるいはコマンド群に対して有効である。このアクセスIDフィールドによる動作識別ID番号の用途は、複数のバスアクセスポートの同時動作や単一のDMAポートのパイプライン動作等であり、1ユニット当たり16種類までの多重動作が指定できる。
第2宛先フィールド564の指定がない通常のバスコマンドにおいては、第1宛先フィールド560のIDフィールドにはソースユニットの任意の動作識別ID番号を指定すればよい。この場合、ソースユニットにおいてはアクセスユニットIDと同じ動作識別ID番号を記憶しており、リプライコマンドを受信した際に第1宛先フィールド560のアクセスIDフィールドとソースユニットに記憶している動作識別ID番号を比較し、一致したならば、自分自身が発行したバスコマンドに対するリプライコマンドであると判断する。
一方、図17の読出モード2におけるリード処理で、ホームのプロセッサモジュール10−2からの第2バスコマンド及びリモートのプロセッサモジュール10−3からのリプライコマンドのように、第2宛先フィールド564が指定されているときには、ソースユニット自身がバスコマンド送出の際に記憶している動作識別ID番号とリプライコマンドにおける第2宛先フィールド564のアクセスIDフィールドを比較し、一致したならば、自分自身が発行したバスコマンドに対するリプライが第1宛先フィールド560で指定されたリプライコマンドと判断する。
具体的には、図17においてローカルのプロセッサモジュール10−1はホームのプロセッサモジュール10−2に送出したバスコマンドに対するリプライコマンドを待っているが、実際にはホームのプロセッサモジュール10−2からリモートのプロセッサモジュール10−3に送出した第2バスコマンドに対するリプライコマンドがホームのプロセッサモジュール10−2ではなくリモートのプロセッサモジュール10−3から返送されてくる。
このときに第2宛先フィールド564のアクセスIDフィールドをローカルのプロセッサモジュール10−1でバスコマンド送出時に記憶した動作識別ID番号と比較して、一致すれば、これはホームのプロセッサモジュール10−2に対する自分自身の送出したバスコマンドに対するリプライコマンドと見做してリプライコマンドを受信することになる。
この結果、本来の要求元であるローカルのプロセッサモジュール10−1は、リモートのプロセッサモジュール10−3を意識することなく、ホームとなるプロセッサモジュール10−2の主記憶28には存在せずリモートのプロセッサモジュール10−3のキャッシュユニットに存在する最新データを受領することができる。
このときローカルのプロセッサモジュール10−1にあっては、リプライデータの受信時間を監視するバスタイマとしてホームのプロセッサモジュール10−2からのリプライを考慮した時間T1(第1時間)を設定しているが、ホームのプロセッサモジュール10−2からリモートのプロセッサモジュール10−3に対する第2のバスコマンドの送出によるリプライであることから、ローカルのプロセッサモジュール10−1におけるバスタイムアウトの監視タイマの時間を、リモートのプロセッサモジュール10−3を考慮した、より長い時間T2(第2時間)に変更して、バス転送のタイムアウトを監視する。
このバスタイムアウトカウンタの時間変更は、ローカルのプロセッサモジュール10−1でホームからリモートに送出されるリモートコマンド250の送出を監視して行えばよい。もちろん、図40に示したタグ情報線509を利用した時間変更を行うことも可能である。
更に図17のリモートとなるプロセッサモジュール10−3からのリプライデータ260であるリプライコマンドの返送については、リプライコマンドの契機となったホームとなるプロセッサモジュール10−2からのリモートコマンド250であるバスコマンドの第1宛先フィールド560におけるアクセスIDフィールドの動作識別ID番号をそのまま指定することになる。
図55の基本バスコマンドは、先頭にサブシステム拡張指定フラグ550を設けている。このサブシステム拡張指定フラグ550は、図52のように、異なったサブシステムのユニット間でデータ転送を行う場合に1にセットされ、これにより図55の基本バスコマンドに加えて、図62に示すサブシステム拡張用のバスコマンドの第2ワード目が作成される。このサブシステム拡張用の第2ワード目については後の説明で明らかにする。
図55の基本バスコマンドにおいて、ソースフィールド552と第1宛先フィールド560の境界部分にはブロードキャスト指定フラグ558が設けられ、ブロードキャストバスコマンドとして使用する際に1にセットされる。また第2宛先フィールド564の先頭部分には第2宛先指定フラグ562が設けられ、第2宛先フィールド564を使用する際に1にセットされる。
基本バスコマンドの2行目となる5〜8バイト部分には、コマンドフィールド566、サイズフィールド568及びフラグフィールド570が設けられる。コマンドフィールド566には、リードコマンド、ライトコマンド、リプライコマンド、ブロードキャストコマンド等のコマンド識別コードが設定される。次のサイドフィールド568にはデータ転送サイズが設定される。
リード系のバスコマンドではリプライコマンドで返送するデータサイズを指定し、ライト系のバスコマンドではバスコマンドに後続する書込データのデータサイズを指定する。次のフラグフィールド570には、コマンドの修飾フラグや属性フラグが必要に応じて設けられる。最後のコマンドパラメータフィールド572は、コマンドフィールド566のコマンド種別に依存した例えばアクセスアドレス等が指定される。
図56は、本発明で使用するブロードキャストバスコマンドのコマンドフォーマットである。ブロードキャストバスコマンドは、ソースフィールド552に続いて設けた第1宛先フィールド560について、図5555の基本バスコマンドにおける宛先ユニットIDの代わりに16ビット幅のブロードキャスト宛先マップフィールド574を設けている。
本発明のシステムバス12は最大で16ユニットを接続することができるので、ブロードキャスト宛先マップフィールド574はビット対応によりブロードキャストコマンドの相手先となるユニットをビット対応で指定することができる。プロードコースバスコマンドもブロードキャストバスコマンドと同じフォーマットをもつ。
図57は、本発明のシステムバスで使用される基本リプライ用及びエラーリプライ用のバスコマンドのコマンドフォーマットである。この基本リプライ及びエラーリプライ用のバスコマンドは、第2行目の部分にリプライタイプ574、エラーレベル576、エラータイプ578、エラーコード580の各フィールドを設けたことを特徴とする。それ以外の構造は図55の基本バスコマンドと同じである。なお最後のコマンドパラメータ572のフィールドは使用していない。
リプライタイプフィールド574には、リプライを要求したソースユニットが発行したバスコマンドのコマンドコードが指定される。またリプライコマンドの付加情報のフォーマットやデータの有無は、このリプライタイプフィールド574のコマンドコードによって決められる。
次のエラーレベルフィールド576は、エラーリプライバスコマンドとして使用する際にエラーレベルが格納される。また次のエラータイプフィールド578には、エラー返信時のエラーの分類を示すエラータイプが通知される。更にエラーコードフィールド580には、エラー返信時にエラーの詳細な要因が通知される。
図59は図57のエラータイプフィールド578の例であり、ソフトウェアエラー、システム構成エラー、ハードウェアエラー、バスエラーの分類情報がエラー検出に基づいてセットされる。図60は図57のエラーレベルフィールド576によるエラーの詳細分類をエラータイプと組み合わせて示している。
ここで図60R>0の「nnn」は、エラーの種別によって異なる。また「xx」は、00でソース(ローカル)、01で第1宛先(ホーム)、10で第2宛先(リモート)、11で第1宛先(ホーム)のミラーユニットを表わす。また「r」は、0でライト、1でリードとなる。
尚、図56に示したブロードキャストバスコマンドは、図23の書込モード1、図24の書込モード2、図25の書込モード3、図26の書込モード4等におけるキャッシュインバリデードのためのバスコマンドとして使用される。
図58は、本発明のシステムバスで使用されるキャッシュステータスリプライバスコマンドのコマンドフォーマットである。このキャッシュステータスリプライコマンドにあっては、ソースフィールド552,第1宛先フィールド560に続いて、キャッシュサブラインステータスフィールド582−1を設け、更に2行目の最後の4ビットに同じくキャッシュサブラインステータスフィールド582−2を設けている。
本発明のキャッシュコヒーレンス装置にあっては、64バイトのキャッシュラインを16バイト単位のキャッシュサブラインに分けている。そこで、キャッシュサブラインを#0〜#3で表わし、キャッシュサブラインステータス582−1,582−2の組合せで各サブラインを3ビットずつ割り当て、キャッシュバスコマンドに対するリプライバスコマンドにより、アクセス対象となったキャッシュサブラインの現在の状態を表示する。
即ち、キャッシュサブラインステータスフィールド582−1にはサブラインID#0〜#3のビット0、ビット1の2ビットがそれぞれ割り当てられ、2行目の最後のキャッシュサブラインステータスフィールド582−2にビット2の第3ビット目が割り当てられている。このキャッシュサブラインステータスフィールド582−1,582−2によるキャッシュサブライン状態は、図61に示すようになる。
図62は、図55のサブシステムバス拡張識別フラグ550を1にセットした際にバスコマンドの第2ワードとして作成されるサブシステム拡張バスコマンドのコマンドフォーマットである。このサブシステム拡張バスコマンドは1行目にソースシステムフィールド586を設け、ソースユニットを設けているソースシステムID、ソースバスID及びソースユニットIDの各フィールドを指定する。
2行目については、サブシステム第1宛先フィールド558が設けられ、宛先システムID、宛先バスID、宛先ユニットIDの各フィールドを設けている。続いてサブシステム第2宛先フィールド590が設けられ、同様に宛先システムID、宛先バスID、宛先ユニットIDの各フィールドを設けている。また第2宛先指定フラグ592もセットされる。このような図62のサブシステム拡張バスコマンドを図55の基本バスコマンドの第1ワードに対し第2ワードとして組み合わせることで、図52に示した複数のサブシステムのユニット間でのデータ転送を行うことができる。
このように本発明のキャッシュコヒーレンス装置で使用する第2共通バスとしてのシステムバス12は、ディレクトリ方式に従った分散共有メモリ型のマルチプロセッサシステムにおいて、キャッシュコヒーレンスを効率良く実現するための共通バスを提供することができ、ディレクトリ方式の拡張性を損うことのない共通バスが提供できる。
またシステムバス単位に構築されるサブシステムを複数結合した大規模なマルチプロセッサシステムへの拡張を考慮した信頼性の高い共通バスが提供できる。更に、異なったバスとの接続を考慮していることから、既存のバス資産の有効活用を可能とする共通バスが提供できる。
7.第2ディレクトリメモリ
図63は、本発明の他の実施形態であり、プロセッサモジュールのシステムバスに対するバス接続ユニットに第2ディレクトリメモリを設けたことを特徴とする。
図63は、プロセッモジュール10−1がローカルとしてホームのプロセッサモジュール10−2の主記憶28に対しホームコマンド600を発行して書込アクセスを行い、ホームからリモートとしてのプロセッサモジュール10−3,10−4にキャッシュインバリデートのリモートコマンド602を発行した場合を示している。
プロセッサモジュール10−1〜10−4の各々は、メモモリ管理ユニット26に対し分散主記憶としてのローカルストレージ28とディレクトリメモリ30を設けており、これは図3の実施形態と同じである。これに加え図63の実施形態では、バス接続ユニット32に第2ディレクトリメモリ31を設けている。この第2ディレクトリメモリ31に対しディレクトリメモリ30を第1ディレクトリメモリと呼ぶ。
第2ディレクトリメモリ31は、自己のローカルストレージ28に存在するキャッシュライン単位のデータにつき、そのデータがシスムテバス上で他のバスコマンドによりアクセス状態を登録している。この登録内容としては、例えば、リモートコマンドによるキャッシュインバリデート待ちがある。図63のプロセッサモジュール10−2は、ホームとしてプロセッサモジュール10−3,10−4にキャッシュインパリデータのリモートコマンド602を発行しており、コマンド応答を待っている。このときプロセッサモジュール10−2の第2ディレクトリメモリ31の該当するキャッシュラインについては、リモートからのキャッシュインバリデートの応答待ちが登録されている。
この状態で、例えばプロセッサモジュール10−3の2番目キャッシュユニット側から、同じキャッシュラインを対象にライトアクスセのホームコマンド608が発行されたとする。このホームコマンド602に対しバス接続ユニット32は第2ディレクトリメモリ31を参照してキャッシュインバリデートの完了待ちにあることをメモリ管理ユニット26に送ることなく直ちに認識し、ビジー応答をリプライコマンドで返す。
この場合、システムバス12上でのリトライとすることは無駄になるので、アクセス元のキャッシュユニットまでビジーを通知し、リトライを行わせる。このように第2ディレクトリメモリ31の参照でリモートコマンドによるアクセス不能な状態が判るので、メモリ管理ユニット26側でアクセス不能を判断してビシーを応答する場合に比べ、処理を高速化できる。
リモートのプロセッサモジュール10−3,10−4でキャッシュインバリデートが完了してリプライコマンドが帰されると、第2ディレクトリメモリ31の登録は削除され、プロセッモジュール10−3からのリトライによるリモートコマンド602が受け入れられる。
図64は、図63のホームのキャッシュインバリデートの完了待ちの状態にあるホームとしてのプロセッサモジュール10−2に対し、他のプロセッサモジュールからホームコマンド606が複数発行され、バス接続ユニット32のバッファがフルとなった場合である。このバッファフルの状態で、プロセッサモジュール10−3からリモートコマンド602が発行されたとすると、第2ディレクトリメモリ31を参照することなく、直ちにバッファフルのビジー応答を返す。
この場合、アクセス要求元のキャッシュユニットまでバッファフルのビジー応答を返すと、スヌープバス22やキャッシュユニットがリトライ動作に忙殺されることから、システムバス12上でのリモートコマンドのリトライとする。
8.その他
図4のプロセッサエレメント14−1に設けた2次キャッシュ制御モジュール35は、2次キャッシュ38のキャッシュデータをLRUで管理しており、新たなキャッシュデータのオーナーで2次キャッシュ38がオーバフローすると、キャッシュデータのLRU追出し処理が行われる。このLRU追い出し処理は、追い出し対象となったキャッシュラインが書込権を所有した排他的ダーティ状態、即ちオーナーであった場合には、メモリモジュール25に対しスヌープバス22を介してコピーバックコマンドを発行し、ホームとなるプロセッサモジュールのローカルストレージ28に、追い出されたキャッシュデータを格納する。
一方、書込所有権が存在した排他的ダーティ状態EX&DのキャッシュラインのLRU追い出しの際に、他のスヌープバスを介して接続した他のキャッシュ上にシェアードモディファイ状態でキャッシュデータが存在する場合には、追い出されたキャッシュデータを消した後、他のキャッシュユニットにリプライコマンドRPを送って、シェアードモディファイ状態SH&Mから排他的ダーティ状態EX&Dに切り替えて書込所有権を移す。この場合には、LRUで追い出されたキャッシュデータのローカルストレージ28へのオーナーは不要である。
尚、上記の実施例は、1つのプロセッサモジュールに4つのプロセッサエレメントを設けた場合を例にとっているが、プロセッサモジュールには少なくとも1台のプロセッサエレメントが設けられればよい。また、プロセッサエレメントの数は必要に応じて適宜に設けることができる。更に、システムバスで接続されるプロセッサモジュールの実施例に限定されず、2以上であれば任意の数のプロセッサモジュールを接続できる。