JP2512651B2 - メモリ共有マルチプロセッサ - Google Patents

Description

【発明の詳細な説明】

【０００１】この発明はコンピュータ・システムに対す
る同期的なパケット切り換え式のメモリ・バスに関する
ものであり、より詳細には、共有データの多重のキャッ
シュ・コピー間の両立性が必要とされる、特にメモリが
共有されたマルチプロセッサにおけるこのようなバスの
使用可能なバンド幅を増大させるためのバス・アーキテ
クチュアおよびプロトコルに関するものである。これを
更に詳細にいえば、この発明は、多重の階層化したメモ
リ・キャッシュを備えたメモリ共有マルチプロセッサを
含んでいるＶＬＳＩ（超大規模集積化）コンピュータ・
システムに対する、前述のタイプのスケーラブル・メモ
リ・バスに関するものである。

【０００２】コンピュータのメモリ・バスを設計すると
きの主要な目標は、それらの使用可能なバンド幅を最大
にすることにある。ショート・バスのサイクル・タイム
はこれを達成するために必要とされるものであるが、こ
れだけではバスの使用可能なバンド幅がその電気的なバ
ンド幅と確実に両立するようにはならない。その理由
は、該当の目標を達成するためには、バスも高い効率
（通常は、使用可能なバスのバンド幅に対するその電気
的なバンド幅の比率として規定される）を持たねばなら
ないからである。

【０００３】実際に、通常の回路で切り換えられるバス
の使用可能なバンド幅を増大させるためには、ショート
・バスのサイクル・タイムは比較的価値が低いものであ
るが、その理由は、該回路でのバスの切り換えにより、
トランザクション対トランザクションをベースとして、
連続的なトランザクションに対するリクエスト（要求）
／リプライ（応答）のペアが直列化されるからである。
知られているように、コンピュータ・システムがその実
行を要求されるメイン・メモリのトランザクションの数
および頻度を減少させるべくキャッシュ・メモリ・シス
テムを用いることができるけれども、高い実行能力のシ
ステムにおいては、通常は静止状態にあるメモリ・バス
上のトラフィックが実行能力の有力な制限ファクタであ
る。

【０００４】不都合なことに、経済的に実用可能なメイ
ン・メモリのアクセス・タイムが、典型的には、実現可
能なバスの最小のサイクル・タイムよりも数倍も長く、
このために、回路で切り換えられるバスの使用可能なバ
ンド幅がメイン・メモリのアクセス・タイムによって制
限され易くなる。キャッシュ・メモリを有するシステム
においては、回路で切り換えられるバスの無駄にされ
た”ウエイト（待ち）”サイクル（即ち、その無駄にさ
れたバンド幅）の減小は、メイン・メモリ／キャッシュ
・メモリのデータ・トランスポート・ユニットのサイズ
を増大させることにより可能であって、これにより、よ
り大きいデータのブロックにわたるバスのウエイト・サ
イクルを償却するようにされる。しかしながら、このア
プローチによれば、１台または複数台のプロセッサによ
ってバス上に配置されるバンド幅ロードが増大する傾向
が生じて、より大きいデータ転送ユニットの利点が少な
くとも部分的に失われることになる。

【０００５】他の者が認識していることは、“パケット
によって切り換えられる”バス（ときには、“スプリッ
ト・サイクル”バスまたは“ペンディング”バスと呼ば
れることもある）を用いることにより、アイドル・バス
・サイクルに起因するバンド幅の不利益点が回避できる
ということである。バスのパケットでの切り換えにより
バスのトランザクションのリクエストおよびリプライが
互いに分離され、これによって、多重のトランザクショ
ンに対するリクエストおよびリプライがバス上でインタ
リーブすることが許容される。一般的なルールとして、
アイドル・バス・サイクルの回避は、メイン・メモリが
関係するトランザクション（即ち、“メイン・メモリ・
トランザクション”）のリクエストおよびリプライを分
離することによって簡単に可能にされる。しかしなが
ら、全てのバス・トランザクションのリクエストおよび
リプライを分離することが有利であることは見出されて
おり、そのために、（実施方法によって異なる最小数の
サイクルを超える）可変数のバス・サイクルが、任意の
リクエストとそれに対応するリプライとの間に介在する
ことができて、ある所定のタイムアウト周期内にリプラ
イが受け入れられないリクエストの、可能性のある終了
または不成功にのみ追従するようにされる。全てのリク
エストおよびリプライについてのこの本質的な完全な分
離によりバスのデッドロックの排除の助けがなされる
が、産業上の標準的なシステムを含んでいる、異なるま
たは“関連のない”コンピュータ・システムのメモリ・
バスのような、非同期式のデバイスと該バスとのインタ
フェースがより容易になるようにされる。更に、インタ
リーブされたメイン・メモリ・モジュールの使用が容易
にされ、また、マルチレベルで階層性のキャッシュ・メ
モリ・システムを有するマルチプロセッサに対するキャ
ッシュの両立性の問題に対する解決が簡単にされる。

【０００６】使用可能なバンド幅とキャッシュの両立性
とは、関連しているけれども分離可能な問題である。こ
こで理解されるようにキャッシュの両立性にはより詳細
な考慮がなされる。その理由は、マルチプロセッサにお
けるような異なるプロセッサのコントロールの下に、キ
ャッシュされたデータ・コピーの中の異なるものが更新
されることを許容しながら、共有データの多重にキャッ
シュされたコピーのアクセスをするバスに対して特別の
要求があるからである。

【０００７】回路で切り換えられるバスに対するキャッ
シュの両立性の問題については、幾つかの解決策が知ら
れている。例えば、ともに係属中であり譲渡されたＰａ
ｒａｄｅｅｐ Ｓ．Ｓｉｎｄｈｕ ｅｔ ａｌ．の米国
特許出願が参照される。この米国特許出願は、“マルチ
プロセッサのためのマルチ・レベルのキャッシュ・メモ
リ・ツリー”として、１９８６年１１月１２日に、出願
番号第９２９，５４４号をもって出願されたもの（Ｄ／
８６２８８）である。しかしながら、キャッシュの両立
性を維持するためのこれら既知の技術は、パケットで切
り換えられるバスに対して直接的に適用できるものでは
ない。なお、Ａｎｄｒｅｗ Ｗ．Ｗｉｌｓｏｎ，Ｊ
ｒ．，“Ｈｉｅｒａｒｃｈｉｃａｌ Ｃａｃｈｅ／Ｂｕ
ｓ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｓｈａｒｅｄ
Ｍｅｍｏｒｙ ｍｕｌｔｉｐｒｏｃｅｓｓｏｒｓ，”
Ｃｏｍｐｕｔｅｒ ＡｒｃｈｉｔｅｃｔｕｒｅＣｏｎｆ
ｅｒｅｎｃｅ ＩＥＥＥ／ＡＣＭ），１９８７，ｐｐ２
４４−２５２を参照されたい。

【０００８】この発明においては、複数個のプロセッ
サ、複数個のＩ／Ｏデバイス、複数個のキャッシュ・メ
モリおよび１個のメイン・メモリ間でのデータ転送のた
めのパケットで切り換えられるバスを有する、メモリ共
有式のマルチプロセッサによってバス・プロトコルが採
用されている。そして、あらゆる時点において、全ての
プロセッサおよび全てのＩ／Ｏデバイスによる、全ての
データに対する両立性のある値のアクセスを確実にしな
がら、異なるプロセッサのコントロールの下に、データ
の多重コピーを更新することが許容される。

【０００９】この発明の他の利点および特徴について
は、添付の図面と関連させて以下の説明を参照すること
によって明かにされる。

【００１０】この発明の説明は、所定の例示された実施
例に関して相当程度詳細になされているけれども、この
発明はそれらの実施例に限定することを意図するもので
はないことが理解されるべきである。むしろ、その目的
とするところは、添記されている特許請求の範囲の欄に
よって規定されるように、この発明の全ての修正、変更
および均等物をカバーすることにある。

【００１１】ここで開示されるメモリ・システムには幾
つかの重要な特徴があるから、異なる特徴に関連して構
成体を配置する助けとなるように、その開示は次のよう
な組成がなされている。 Ｉ． 初めの実施例 Ａ． システム・アーキテクチュア １． バスおよびメモリの階層性 ａ． マルチレベルのバス・システム Ｂ． バスの論理的な術語 Ｃ． バスの物理的な術語 Ｄ． デバイス−バス・インタフェース １． 信号 ２． 裁定・インタフェース ３． データ／コントロール・インタフェース ４． 両立性ポート Ｅ． トランザクション １． メモリ関連トランザクション ２． Ｉ／Ｏトランザクション ３． 多面的トランザクション Ｆ． データの両立性 １． 単一レベルのシステムにおけるデータの両立性 ２． マルチレベルのシステムにおけるデータの両立性 ＩＩ． 増強された実施例 Ａ． システム・アーキテクチュア Ｂ． デバイス−バス・インタフェース １． 信号 ２． 裁定・インタフェース ３． データ／コントロール・インタフェース ４． 両立性ポート Ｃ．トランザクション １． メモリ関連トランザクション ２． Ｉ／Ｏトランザクション ３． 多面的トランザクション Ｄ．データの両立性

【００１２】Ｉ． 初めの実施例 ここで図面に移行すると、特に図１についてみると、複
数個のプロセッサ１２ａａ−１２ｉｊおよび共有のメイ
ン・メモリ１３を備えたマルチプロセッサ１１が示され
ている。このメイン・メモリ１３は集中化されたものと
して描かれているけれども、ここで理解されることは、
物理的なアドレス空間の使用されたサブセットについて
分裂した（即ち、相互に排他的であり、また、徹底的
な）カバーをするために分散化できるということであ
る。

【００１３】Ａ． システム・アーキテクチュア １． バスおよびメモリの階層性 プロセッサ１２ａａ−１２ｉｊは１個または複数個のク
ラスタ１４ａ−１４ｉ内で構成されているが、その各々
には、裁定され、パケットで切り換えられるローカル・
バス１５ａ−１５ｉがそれぞれに備えられている。例示
された実施例においてクラスタ１４ａ−１４ｉの各々に
含まれているものは、義務的なものではないが、１個ま
たは複数個のプロセッサ１２ａａ−１２ｉｊである。所
望であれば、例えば該クラスタの中の一つが、マルチプ
ロセッサ１３に対するＩ／Ｏ動作の実行のためのものと
されている。しかしながら、ここで重要であるとされる
ことは、プロセッサ１２ａａ−１２ｉｊの各々が、第１
レベルのキャッシュ・メモリ１６ａａ−１６ｉｊによっ
て、それぞれに（プロセッサ自体には、図示されない
が、１個または複数個のより低レベルでもあるキャッシ
ュ・メモリを含ませることができる）、そのクラスタま
たは“ローカル・ホスト”バス１５ａ．．．，もしくは
１５ｉに結合されているということである。その理由
は、プロセッサ１２ａａ−１２ｉｊがそれらのキャッシ
ュ・メモリ１６ａａ−１６ｉｊを介してそれらのホスト
・バスと通信するようにされているからである。ローカ
ル・バス１５ａ−１５ｉは、これに次いで、それぞれ
に、クラスタ１４ａ−１４ｉ内の共有資源に対してキャ
ッシュ１６ａａ−１６ｉｊをリンクさせる。例えばクラ
スタ１４ａのローカル・バス１５ａは、プロセッサ１２
ａａ−１２ｉｊに対する第１レベルのキャッシュ１６ａ
ａ−１６ｉｊを、それぞれに、オプションのマップ・キ
ャッシュ１７ａおよび中間レベルまたは第２レベルのキ
ャッシュ・メモリ１９ａと相互接続させる。ここで示さ
れているように、該第２レベルのキャッシュ１９ａは、
ランダム・アクセス・メモリ（ＲＡＭ）モジュール２０
ａおよびコントローラ２１ａからなるものである。

【００１４】ａ． マルチレベルのバス・アーキテクチ
ュア 例示されたマルチプロセッサ１１は階層的なアーキテク
チュアを有するものであり、異なるレベルの階層におけ
る同様な構成要素を同定するために同様な参照数字が採
用されている。更に、該構成要素の階層的な依存性を同
定するときの助け（デュアル・キャラクタのサフィック
スの第１のキャラクタを参照）のために、および、共通
の依存性を有する同様な構成要素間での区別をする（デ
ュアル・キャラクタのサフィックスの第２のキャラクタ
を参照）ために、アルファベットのサフィックスが前記
の参照数字に付加されている。

【００１５】所望であれば、クラスタ１４ａ−１４ｉの
いずれのものでも、完全に機能的なモノプロセッサまた
はマルチプロセッサのコンピュータ・システムとして動
作するように構成することができる。この発明のバス・
プロトコルによれば、単一のバス上で幾つかのプロセッ
サを支持するために十分に使用可能なバスのバンド幅が
付与されるが、ここでのシステムの構成は、大方の現存
するデスクトップ・ワークステーションの適用のため
に、および、多くの現存するプリント・サーバーおよび
ファイル・サーバーの適用のために十分な演算パワーを
付与するものである。しかしながら、マルチプロセッサ
１１のツリー状にされた階層的なアーキテクチュアによ
れば、ローカル・クラスタのバス・トランザクション
が、グローバルなメイン・メモリのトランザクションの
ようなグローバル・バス２６上の大方のトランザクショ
ンから効果的に分離される。この結果として、バスに対
するバス・トラフィックと電気的なローディングとが分
散され、これによって、より大きくてより有力なマルチ
プロセッサの構成が許容される。

【００１６】実際には、２−レベルの階層構成が例示さ
れているだけであるが、ここで理解されることは、階層
の任意所与のレベルにおける２本またはそれよりも多く
のバスを次に高いレベルにおけるバスと相互接続させる
ために、マルチプロセッサ１１のツリー状にされたアー
キテクチュアが、キャッシュ・メモリの付加的な層（図
示されない）の使用を通して伸長可能にされるというこ
とである。ここで認められるように、キャッシュ・メモ
リ１６ａａ−１６ｉｊおよび１９ａ−１９ｉはキャッシ
ュ・メモリのツリーとして構成されており、これらのキ
ャッシュの記憶能力は、典型的には、ツリーの深さが増
すにつれて減少するようにされている。階層の全てのレ
ベルにおいて同じバス・プロトコルが用いられているこ
とから、ある特定の適用についての特別の要求により良
く合わせるべくマルチプロセッサ１１の再構成をするた
めに、システムの設計者は十分な自由度を有している。

【００１７】メイン・メモリ１３は適当なコントローラ
２５を介してトップ・レベルの“グローバル”バス２６
に接続されているが、プロセッサおよびＩ／Ｏデバイス
は階層の任意のレベルにおいてバスに接続することがで
きる。バスの階層性は全てのバス・クライエント（即
ち、それぞれにプロセッサ１２ａａ−１２ｉｊに対する
キャッシュ１６ａａ−１６ｉｊ；Ｉ／Ｏブリッジ１８ｉ
がホスト・バス１５ｉと通信するときに介在するキャッ
シュ６０；ローカル・エリア・ネットワーク（ＬＡＮ）
３０ｉおよびディスプレイまたはプリンタ・デバイス３
１ｉがそれぞれにホスト・バス１５ｉと通信するときに
介在するコントローラ２８ｉおよび２９ｉ；クラスタ１
４ａ−１４ｉがそれぞれにグローバル・バス２６と通信
するときに介在する第２レベルのキャッシュ１９ａ−１
９ｉ；および、メイン・メモリ１３がグローバル・バス
２６と通信するときに介在するコントローラ２５）に対
して透明なものであり、このために、クライエントは、
可能性のあるシステム構成のいずれに対してもカスタム
化する必要がない。セクションＩ．Ｄ．において更に十
分に後述されるように、バス・クライエント・インタフ
ェースはシステム構成から独立している。

【００１８】Ｂ． バスの論理的な術語 この発明のバス・プロトコルに含まれているものは、３
個の異なるレベル（即ち、バス・サイクルの電気的なレ
ベル、パケットの論理的なレベル、および、トランザク
ションの機能的なレベル）におけるバスの動作である。
規定すべきこととしては、“バス・サイクル”が任意の
所与バス上におけるクロックの完全な周期であることか
ら、それは単一のバスを介する電気的な情報の転送のた
めの時間的な単位である。これに対して、“パケット”
は、論理的な情報の転送のための連続的なバス・サイク
ルの近接しているシーケンスである。そして、“トラン
ザクション”は論理的な機能を実行するための“リクエ
スト”パケットおよびそれに対応する“リプライ”パケ
ットからなるものであって、ここでの論理的な機能と
は、データ・フェッチ操作（即ち、ある特定のメモリ・
アドレス位置からのデータの読み取り）またはデータ記
憶操作（即ち、ある特定のメモリ・アドレス位置に対す
るデータの書き込み）のようなことである。先に指摘さ
れたように、リクエスト／リプライの全てのペアは分離
していることから、“ペンディング・リクエスト”（即
ち、リプライを待っているリクエスト）に対して予め選
択されたタイムアウトの周期によって規定される制限に
なるまでは、いずれのトランザクションに対するリクエ
ストおよびリプライでも任意数のバス・サイクルによっ
て分離されることができる。特徴的なこととしては、各
パケットの第１のサイクル（いわゆる“ヘッダ”）はア
ドレスおよびコントロール情報を有しており、これに対
して、後続のサイクルはトランザクションの規定によっ
てしかるべく実行することを要求されたときのデータを
有している。

【００１９】バス１５ａ−１５ｉおよび２６の各々は同
期的なものであるが、バス対バスの情報の転送が第２レ
ベルのキャッシュ１９ａ−１９ｉのようなキャッシュに
よって完全にバッファされることから、これらは必ずし
も互いに同期している必要はない。更に、より十分に後
述されるように、バス１５ａ−１５ｉおよび２６の各々
は、裁定手段３５ａ，３５ｂ，３５ｉおよび３６によっ
て独立に裁定されるものである。

【００２０】パケットで切り換えられる全てのクライエ
ント・デバイス（規定すべきこととして、“クライエン
ト・デバイス”とは、−“バス・クライエント”として
参照されることもあるが−、ホスト・バス１４ａ−１４
ｉおよび２６を介してパケットの送受をするデバイスで
ある）は、バス“マスター”およびバス“スレーブ”と
しての双方の機能を果たすことが可能でなければならな
い。しかしながら、ある所与のトランザクションを開始
するためのリクエスト・パケットを発するクライエント
が“リクエスタ”として規定されているとき、または、
このようなリクエストに応答してリプライ・パケットを
発する任意のデバイスが“レスポンダ”として規定され
ているときには、クライエント・デバイスのトランザク
ション・レベルにおける相互作用は幾らか理解し易いも
のである。ここで認められるように、任意の所与のリク
エストに対して１個を超えるレスポンダは存在しない。

【００２１】その動作において、リクエスタに対するバ
スが裁定手段によって許容されることは、リクエスタに
よってなされる裁定のリクエストに応答することであ
る。バスの許容がなされたときには、このリクエスタは
バス“マスター”になり、これに次いでそのリクエスト
・パケットを発するようにされる。他の全てのバス・ク
ライエントはこのパケットによって保持されているアド
レスおよびコマンドを調べて、それらが何等かの動作を
するように要求されているかどうかの決定をする。１個
または複数個のクライエントは、要求された動作を実行
するために“スレーブ”としての動作の機能を果たすべ
く要求されているが、そのリクエスト・パケットを発す
ることが終了すると、該当のバスがリクエスタによって
即座に解放される。かくして、リプライ・パケットをリ
クエスタに対して返すことができるのに先だって裁定手
段からのバス・マスターシップを取得するために、レス
ポンダは、固有の独立した裁定リクエストをしなければ
ならない。このリプライ・パケットはリクエスタに対し
てアドレスされているから、このリクエスタはそれを受
け入れるためにスレーブ・モードで動作することにな
る。

【００２２】Ｃ． バスの物理的な術語 任意の所与のバス（例えば、ローカル・バス１５ａ−１
５ｉまたはグローバル・バス２６の任意のもの）は多く
のセグメントからなるものであるが、好適には、バスの
実行能力の低下を回避するために、いずれの単一のバス
内にも２個を超える双方向性のバス・セグメントが存在
しないようにされる。このために、図３−図５を参照し
て認められることは、コンピュータ・システムが、図３
におけるようなモノボード・コンピュータとして、図４
におけるようなマルチボード・コンピュータとして、ま
たは、図５におけるようなマルチボード／マルチモジュ
ール・コンピュータとして構成されるかどうかに拘ら
ず、各バスのセグメントが同期してクロックされるパイ
プライン・レジスタ３７を介して接続されていることで
ある。この発明のバス・プロトコルに対しては、また
は、このプロトコルで確実にされるキャッシュの両立性
を維持するためには、パイプライン操作は必須のことで
はないけれども、１本または複数本のバスの電気的な特
性を最適化することは容易にされる。しかしながら、こ
こで理解されることは、バスの各々がパケットで切り換
えられることから、パイプライン操作が実現の可能性が
あるオプションであるということである。より詳細にい
えば、図３−図５に描かれているシステムは、それぞれ
に、２−レベル，３−レベルおよび４−レベルのパイプ
ライン操作のものである。好適には、パイプライン式の
バス・セグメントは短いものであり、また、一般的には
等しい長さのものであって、電気的な信号の伝播の遅れ
時間を最小にし、また、多少なりとも等しくするように
される。更に、実際には、バス・セグメントのあるもの
またはその全てが、不所望の信号の反射を抑制するため
に、平衡型の抵抗性終端部（図示されない）等によって
終端されている。しかしながら、ここで注意されるべき
ことは、バスとバス・プロトコルとの電気的な特性は互
いに独立しているということである。

【００２３】Ｄ． デバイス−バス・インタフェース ここで想起されるように、図２の４１において示されて
いるような標準化されたバス・インタフェースは、バス
１４ａ−１４ｉおよび２６をそれぞれの“クライエント
・デバイス”と電気的に相互接続させるために設けられ
ている。好適には、これらのバス・クライエントに備え
られているオープン・ドレイン型のＣＭＯＳドライバお
よびレシーバ（係属中であり譲渡された、１９９０年３
月３０日に出願番号第０７／５０２，３７２号として出
願の、Ｗｉｌｌｉａｍ Ｆ．Ｇｕｎｎｉｎｇの米国特許
出願であって、“Ｄｒｉｖｅｒｓ ａｎｄ Ｒｅｃｅｉ
ｖｅｒｓ ｆｏｒ Ｉｎｔｅｒｆａｃｉｎｇ ＶＬＳＩ
ＣＭＯＳ Ｃｉｒｃｕｉｔｓ ｔｏ Ｔｒａｎｓｍｉ
ｓｓｉｏｎ Ｌｉｎｅｓ”，Ｄ／９０１５３を参照）
は、それぞれに、バスに対する出力信号の適用をし、ま
た、バスからの入力信号を受け入れるためのものであ
る。インタフェース４１のクライエント側においてこの
ようなドライバおよびレシーバを用いることの利点は、
それらの電力消費が著しく低く、現に利用可能なＶＬＳ
Ｉ技術を用いてこの発明を実施することが許容されるこ
とである。

【００２４】１． 信号 図６において示されているように、バス・インタフェー
ス４１に備えられているものは、コントロール・ポー
ト、裁定ポート、受け入れポート、送出ポートおよび両
立性ポートである。インタフェース４１のコントロール
・ポートに対して加えられるホスト・バスによるクロッ
ク信号は、インタフェース４１とその関連のバス・クラ
イエント・デバイスとの間の全ての相互作用についての
タイミングをコントロールし、また、クライエント・デ
バイスによって要求される任意の他のクロック信号を導
出することができる基準を付与するためのものである。
コントロール・ポートには、同期ストップ出力信号（Ｓ
ＳｔｏｐＯｕｔ）のための出力および対応の同期ストッ
プ入力信号（ＳＳｔｏｐＩｎ）のための入力も含まれて
おり、これによって、関連のクライエント・デバイス
は、システムを同期ストップに移行することが所望され
るときには、ＳＳｔｏｐＯｕｔを主張することができ
る。いずれのバス・クライエントによるＳＳｔｏｐＯｕ
ｔの主張であっても、バス上の全てのクライエントおよ
び該バスに対する裁定手段に対して“真の”ＳＳｔｏｐ
Ｉｎ信号が加わるようにされ、これによって、クライエ
ントがＳＳｔｏｐＯｕｔの主張を解除するまでは、バス
上の全ての活動を停止するようにされる。

【００２５】２． 裁定インタフェース 裁定手段３５ａ−３５ｉおよび３６は、それぞれに、任
意の所与時点において競合しているクライエント・デバ
イスの中でバス１４ａ−１４ｉおよび２６を時間多重化
させ、これによって、それぞれのクライエントが、その
ホスト・バスに対する公平に拘束された時間的なアクセ
スを確保するようにされる。これらのクライエント・デ
バイスは、１本または複数本の専用リクエスト・ライン
によって、および、１本または複数本の専用許容ライン
によって、それらのホスト・バスに対する裁定手段に結
合されている。

【００２６】その動作において、クライエント・デバイ
スは、そのバス上にリクエスト・パケットまたはリプラ
イ・パケットを予め出力し、その１本または複数本の専
用リクエスト・ラインを介して、そのホスト・バスのた
めの裁定手段に対するバス・リクエストの送信をする。
大方の場合においては、裁定リクエストがなされるため
のリクエスト・パケットまたはリプライ・パケットをク
ライエントが十分にアセンブルした後で、該裁定リクエ
ストの送信がなされるものであるが、幾つかの場合にお
いては、クライエントによる待機時間を減少させるた
め、該クライエントがまだパケットのアセンブルをして
いる間に、裁定リクエストが裁定手段によって登録され
る。例えば、メイン・メモリ１３の待機時間を減少させ
るために、メモリ・コントローラ２５は、好適には、メ
イン・メモリ１３からのリプライに含まれるべきデータ
の検索をしながら、ＲｅａｄＢｌｏｃｋのリプライ（よ
り詳細に後述される）に対するその裁定リクエストを登
録するようにされる。

【００２７】ここで認められるように、それぞれの裁定
手段が受け入れる裁定リクエストは異なる優先度を有し
ており、また、異なる長さのパケットの送信のためのバ
スを取得するようにされる（例えば、この初めの実施例
の実施においては、２−サイクル長および５−サイクル
長のパケットが用いられている）。このために、多くの
裁定リクエスト・ラインを設けることが好都合である
（図２および図６を参照）が、その理由は、クライエン
ト・デバイスによってわずか数クロック・サイクル（こ
の初めの実施例および増強された実施例に関して、それ
ぞれに、１サイクルの裁定リクエストおよび２サイクル
の裁定リクエストが後述される）の間にそれらの裁定リ
クエストをコード化することが、該多くの裁定リクエス
ト・ラインによって許容されるからであり、コード化す
ることを用いることにより、異なる優先度の裁定リクエ
ストと異なる長さのパケットの送信のための裁定リクエ
ストとの間での識別が、裁定手段によって可能にされ
る。いずれのクライエント・デバイスでも、任意の瞬間
におけるそのバス裁定手段と係属する多くの裁定リクエ
ストを備えている。裁定手段は、これに次いで、競合し
ているクライエント・デバイスについて係属する裁定リ
クエストの優先度を定めるための予め選択された裁定ル
ールを適用し、そして、専属の１本または複数本のライ
ンを介して、該競合しているクライエント・デバイスに
対してバス許容信号を次々に返すことにより、逐次的に
それらのリクエストを優先順位をもって許容していく。
例えば、１個または複数個のクライエント・デバイスの
任意のものが、ホスト・バスに対して異なる優先度の登
録された裁定リクエストを有するときに支配をする裁定
ルールにより、裁定手段が優先度の降下する順序に応じ
てそれらのリクエストを許容するようにされる。これに
対して、１個または複数個のクライエント・デバイスか
らの同じ優先度の裁定リクエストは、競合しているクラ
イエントの間で裁定を下すための“ラウンド−ロビン”
ルール、および、任意の所与のクライエントの多くのリ
クエストの間での裁定を下すためのＦＩＦＯ（先入れ／
先出し）ルールを用いて適当に処理される。

【００２８】より詳細にいえば、図６において示されて
いるように、各クライエント・デバイスは、２本の裁定
リクエスト・ライン３８および１本の許容ライン３９を
有している。これら２本の裁定リクエスト・ライン３８
のために、４個までの異なる裁定リクエストをコード化
することがクライエントにより可能にされて、図７の４
０および４１におけるような裁定手段によるデコード操
作をするようにされる。全てのバス・クライエントの裁
定の要求は、メイン・メモリ・コントローラを除いて、
それらのコード化に対して以下の意味を指定することに
よって満足することができる。 コード化 Ｎｏ． 意味 ０ システム−ワイドの保持に対するデマンドの解除 １ システム−ワイドの保持に対するデマンド ２ 低優先度の裁定リクエストの付加 ３ 高優先度の裁定リクエストの付加

【００２９】メイン・メモリの全ての裁定リクエスト
は同じ優先度のものであることから、メイン・メモリ・
コントローラからの裁定リクエストは以下のように適当
に解釈される。 コード化 Ｎｏ． 意味 ０ システム−ワイドの保持に対するデマンドの解除 １ システム−ワイドの保持に対するデマンド ２ 短い（２サイクルの）パケットに対するリクエスト の付加 ３ 長い（５サイクルの）パケットに対するリクエスト の付加

【００３０】その実際においては、裁定リクエストにつ
いての前述の解釈が、（図示されない手段により）シス
テムの初期化の間に、裁定手段における裁定ポート内に
プログラムされる。より詳細にいえば、メモリ・コント
ローラに接続されているポート４３のような裁定ポート
は、いわゆる“メモリ・ポート”として機能するように
プログラムされるが、これの意味することは、それらが
単一のＦＩＦＯリクエスト・レジスタを用いており、ま
た、短いリプライ・パケットおよび長いリプライ・パケ
ット（より高い優先度は“キャッシュ・リプライ優先
度”だけである）の双方に対して“メモリ優先度”が指
定されることである。別の裁定ポート４２は、いわゆる
“正常ポート”として機能するようにプログラムされる
が、これの意味することは、低い優先度のリクエストお
よび高い優先度のリクエストを登録するために、分離し
たカウンタまたはレジスタが用いられるということであ
る。このために、関連したクライエント・デバイスによ
って低い優先度および高い優先度の裁定リクエストが形
成されるパケットの長さに関して、これらの裁定ポート
４２の各々が更にプログラムされる。

【００３１】サービスが要求されるものとして、異なる
タイプのクライエント・デバイスから裁定手段が受け入
れることができる、裁定リクエストに対する優先度の典
型的な指定は以下の通りである（下降する順序での優先
度）。 優先度 Ｎｏ． 指定 ０ キャッシュのリプライの優先度 １ メモリ・コントローラおよびＩ／Ｏのリプライの優 先度 ２ ディスプレイ・コントローラ・リクエストの高い優 先度 ３ Ｉ／Ｏリクエストの優先度 ４ キャッシュのリクエストの優先度 ５ ディスプレイ・コントローラ・リクエストの低い優 先度

【００３２】一般的にいえば、ディスプレイ・コントロ
ーラ（図１の２８ｉを参照）ではそのリクエストを満た
すために低い裁定の優先度が用いられていることから、
他のものがアイドル状態にあるバス・サイクル中に、通
常は、そのコントローラに対して伝送されるデータによ
ってディスプレイの駆動がなされる。しかしながら、デ
ィスプレイに対するデータ・キューが近傍のエンプティ
・レベルに落ちるときには、ディスプレイ・コントロー
ラは、そのデータ・キューを補充するために、幾つかの
リクエスト・パケットに対するその高い優先度のリクエ
スト・レベルを採用するようにされる。

【００３３】係属するリプライの個数を減少させるため
に、２個の最も高い裁定の優先度がリプライに対して指
定される。これは、バスのデッドロックを回避するため
の、重要なフロー・コントロールのメカニズムである。
また、トランザクションの実行の遅れ（即ち、リクエス
トの発行とこれに応じるリプライの受け入れとの間の時
間）も減少される。しかしながら、リプライに対して与
えられる高い優先度は、オーバフローのリスクを冒しな
がら、そのトランザクション・リクエスト・レジスタ３
４（図２）に対して十分な個数のトランザクション・リ
クエストを累積するクライエント・デバイスの可能性を
増大させる。従って、このような渋滞を防止するため
に、裁定手段についてシステム・ワイドでの保持をデマ
ンドする任意のクライエント・デバイスによって求めら
れる第２のフロー・コントロールのメカニズムがある。
システム・ワイドでの保持に対するデマンドにより、リ
クエスト・パケットの送信についての許可を、裁定手段
がバスに対して出すことが不可能になることから、該裁
定手段は該バスをして、リプライ・パケットを送信する
ための裁定リクエストを出しているクライエントに専用
のものとする。一旦デマンドが出されると、このような
システム・ワイドでの保持により、そのデマンドを出し
ているクライエントによって解放されるまで、有効な状
態に留められる。これによって可能にされることは、渋
滞の状態にあるクライエントが、正常な動作が再開され
るのに先だってその渋滞の状態を解放するために、その
係属中のリクエストキューが十分に低いレベルまで降下
することを確実にすることである。

【００３４】前述されたことから理解されるように、異
なるクライエント・デバイスは異なるレベルの優先度を
もつことができるけれども、ホスト・バスの割当が予め
強調されることはない。その結果として、そのホスト・
バスが許容されたクライエント・デバイスは、バス上で
完全なリクエスト・パケットまたはリプライ・パケット
を配することができるように、十分な時間的な周期にわ
たって“バス・マスター”であることになる。

【００３５】しかしながら、ここで理解されるべきこと
は、裁定リクエストのコード化をすることの重要な利点
の一つとして、任意の処与のクライエントからの任意の
処与の裁定リクエストに対して、その処与の裁定リクエ
ストに応じてバスが許容されたときの、該処与のクライ
エントが発するパケットの長さを、裁定手段によって予
言的に決定することができる。これで許容されること
は、クライエントが発するパケットのために必要とされ
るバス・サイクルの正確な個数について、任意の処与の
クライエント・デバイスに対してバスが許容する時間の
長さを、裁定手段によって制限することである。より有
意義なこととしては、図８に示されているように、Ｇｒ
ａｎｔ₁ およびＧｒａｎｔ₂ のような連続的な許可のタ
イミングのコントロールが、裁定手段によって可能にさ
れる。このために、第２の許可（Ｇｒａｎｔ₂ ）が発せ
られるのは、生じているパケットＡの最終バス・サイク
ルに対する許可（Ｇｒａｎｔ₁）を現在のバス・マスタ
ーのクライエントが評価した直後である。次に続くバス
・マスターになるクライエントによって、この早期の許
可の告知のために可能にされることは、その直前のパケ
ットＡの最終サイクルに追従するパケットＢのはじめの
サイクルの間に、そのパケットＢに対するヘッダー・サ
イクルをもってバスを駆動するために適当な高い電圧レ
ベルまで、バス・ドライバによって移行させるのに十分
な時間がもたらされることである。かくして、明瞭であ
ることは、裁定手段は、バス上のパケットの送信に関す
る時間的なオーバラップをしながらバスの裁定を実行す
るだけではなく、クライエントが全ての利用可能なバス
・サイクルをパケットで満たすことも許容することであ
る。

【００３６】図３，図４および図５において示されてい
るような複数個のパイプライン式のバス・セグメントか
ら構成されているバスは、それらのクライエントが全て
の利用可能なバス・サイクルをパケットで満たすことも
許容するために、前述されたタイプの予測的なオーバラ
ップ式の裁定を用いるように所望されているときには、
ある程度の注意を払って設計されねばならない。これを
より詳細にいえば、連続的なパケットＡおよびＢは、こ
のようなバスの中間セグメントまたはいわゆる“バック
パネル”セグメント上において、該バックパネル・セグ
メントがバスの双方向性セグメントだけであるときにの
み、連続的なバス・サイクルに詰め込むことができる。
そうでないときには、パケットＡおよびＢを連続的なバ
ス・サイクルに詰め込もうとするいかなる試行でも、任
意の処与のバス・セグメント上でのそれら２個のパケッ
ト間での時間的なオーバラップに対する禁止によって妨
げられる。図３，図４および図５において示されている
ように、その解決策は、バックパネル・セグメントに対
するものを除いて、このようなバスの全てのセグメント
に対して単方向性のバス・セグメントを使用することで
ある。この解決策の有効性は図８において示されてい
る。ここで、図４に示されているバスの、それぞれに単
方向性の出力セグメントＡ₁ およびＡ₂からのパケット
ＡおよびＢは、そのバックパネル・セグメントＢを介し
て、それぞれに単方向性の入力セグメントＣ₁ およびＣ
₂ に至るようにされる。

【００３７】図示されている２本の付加的なワイヤ５１
および５２は、サービスに責任のある全てのクライエン
ト・デバイスに対する各裁定手段に接続されている。あ
る処与のクライエント・デバイスに対するバスの許可の
直前のサイクルにおいて、いわゆるＨＩＰＧｒａｎｔラ
イン５１上の信号の論理的なレベルにより、次に続く許
可が高い優先度のリクエストに相応しているか否かの決
定がクライエント・デバイスによってなされ、また、い
わゆるＬｏｎｇＧｒａｎｔライン５２上の信号の論理的
なレベルにより、次に続く許可が長いパケットに対する
ものであるか否かの決定がクライエント・デバイスによ
ってなされる。従って、これら２個の信号により、異な
る優先度の係属中の裁定リクエストに対する許可の間に
ついて、および、異なる長さのパケットの送信を認める
ために与えられる許可の間について、クライエントがそ
の区別をすることが可能になる。

【００３８】３． データ／コントロール・インタフェ
ース ここで図１に戻ると、グローバル・バス２６および１４
ａ−１４ｉのようなクラスタ・バスの各々は、２ⁿ で表
されるような２の累乗のビット・ワイドの多重化したデ
ータ／アドレス・パスを形成するようにされている。ク
ライエント・デバイスを単方向性のバス・セグメントに
接続するために、その標準的なインタフェース４１（図
６）には１個の送出ポートおよび１個の受容ポートが備
えられており、その各々は、２ⁿ ビット・ワイドのデー
タ／アドレス・パス（この発明の典型的な実施において
は、各バスのデータ／アドレス・パスは６４ビット・ワ
イドである）を構成している。しかしながら、インタフ
ェース４１の送出ポートは双方向性のモードで動作でき
ることから、クライエント・デバイスを双方向性のバス
・セグメントに接続するために、送出／受容（送受両
用）ポートとして用いられることになる。

【００３９】ここで示されているように、これらの送出
ポートおよび受容ポートにも、ヘッダー・サイクル・ビ
ットのための１本のワイヤおよびパリティ・ビットのた
めの１本のワイヤが含まれている。この実施例において
は、パケットのヘッダー・サイクルを同定するために、
バス・マスター（即ち、該当のパケットを発しているク
ライエント）による各パケットのはじめのサイクルの間
に、ＨｅａｄｅｒＣｙｃｌｅの論理的な真（“１”）の
信号が出される。その他方において、受容側がデータ送
信のエラーを検出できるように、関連するパケットで搬
送されるデータからのパリティの算出がデータ源におい
てなされる。このパリティ・チェック操作は全く従来か
らのものであることから、この特定の実施例においてバ
スがアイドル状態にあるときの論理的なレベルがロー
（“０”）であるために、偶数パリティが採用されてい
ることを注意すれば十分である。

【００４０】４． 両立性ポート 任意の処与の時点において、任意の処与のバス上の２個
またはそれよりも多くのキャッシュ・メモリ・クライエ
ント内にキャッシュされている、メモリ・アドレスの各
々の全てのキャッシュされたコピーを通してデータの両
立性を維持するために、バス・デバイス・インタフェー
ス４１は、それぞれに、キャッシュ・メモリからのＳｈ
ａｒｅｄＯｕｔ信号およびＯｗｎｅｒＯｕｔ信号を送信
するための出力部６２および６３とともに、メモリ・コ
ントローラ（中間レベルまたはより高いレベルのキャッ
シュに対するコントローラを含んでいる）からのＳｈａ
ｒｅｄＩｎ信号およびＯｗｎｅｒＩｎ信号を受信するた
めの入力部６１および６２を備えている。

【００４１】同じバス上のキャッシュ・リクエスタがメ
モリ・リクエスト（例えば、この実施例におけるＷｒｉ
ｔｅＳｉｎｇｌｅ，ＣｏｎｄｉｔｕｏｎａｌＷｒｉｔｅ
ＳｉｎｇｌｅまたはＲｅａｄＢｌｏｃｋＲｅｑｕｅｓ
ｔ）を出すときはいつでも、ある固定的な時間遅れの後
に、真の（論理“１”の）ＳｈａｒｅｄＯｕｔ信号の状
態がキャッシュによって主張される。その他方におい
て、ＳｈａｒｅｄＩｎは、バス上の全てのキャッシュか
らのＳｈａｒｅｄＯｕｔ信号の、適当に遅れた論理的Ｏ
Ｒにされている。この論理的ＯＲの操作に起因する遅れ
も固定されており、リクエストを受け入れたときにリク
エスタによって特定されたアドレスがバス上の他のキャ
ッシュのいずれかによって共有されているかどうかを決
定する為に、このようなリクエスト・パケットを受け入
れてからある所定の時間の後で、レスポンダによってＳ
ｈａｒｅｄＩｎ信号のレベルが評価される。ここで認め
られるように、リプライ・パケットのヘッダー・サイク
ルにおける、いわゆる“ｒｅｐｌｙＳｈａｒｅｄ”ビッ
トによって、そのリプライをレスポンダが発するときに
は、このＳｈａｒｅｄＩｎ信号の値はリクエスタに戻さ
れる。そして、これにより、そのリクエストがなされた
ときに、そのリクエストが指向されたデータが共有され
ているか否かについて、リクエスタに告知するようにさ
れる。

【００４２】他のキャッシュから受け入れられる読み取
りリクエスト（例えば、ＲｅａｄＢｌｏｃｋＲｅｑｕｅ
ｓｔ）において特定されるアドレスに存在するデータ・
ブロックの“ｏｗｎｅｒ”であるときはいつでも、ある
固定的な時間遅れの後に、真の（論理“１”の）Ｏｗｎ
ｅｒＯｕｔ信号の状態がキャッシュによって主張され
る。より詳細に後述されるように、データが特定のデー
タ・ブロックに書き込まれるときはいつでも、キャッシ
ュはデータ・ブロックの“ｏｗｎｅｒ”になる。これの
意味することは、その所有権は、たとえ存在するとして
も、最後にデータ・ブロックに書き込まれたキャッシュ
に属することから、任意の所与のデータ・ブロックにつ
いて、一時に１個の“ｏｗｎｅｒ”しか存在しないこと
になる。それにも拘らず、タイミングを簡略化するため
に、ＯｗｎｅｒＩｎ信号は、好適には、バス上のキャッ
シュからのＯｗｎｅｒＯｕｔ信号の同様に遅れた論理的
ＯＲであるから、リプライを出すか、または、データに
ついてのより低いレベルのキャッシュの“ｏｗｎｅｒ”
からのリプライに従うかを決定するためにＳｈａｒｅｄ
Ｉｎを評価するのと同じ時点において、バス上の最上位
のクライエント（即ち、メモリ・コントローラまたはよ
り高いレベルのキャッシュ）はＯｗｎｅｒＩｎを評価す
ることができる。ここで認められるように、１個よりも
多くのキャッシュがＯｗｎｅｒＯｕｔを主張することは
できないために、キャッシュからのＯｗｎｅｒＯｕｔ信
号のＯＲ操作をすることは必須のことではないけれど
も、ＳｈａｒｅｄＩｎの値およびＯｗｎｅｒＩｎの値に
ついて一様な扱いがもたらされることになる。

【００４３】ここで注目されるべきことは、Ｓｈａｒｅ
ｄＩｎ信号の値およびＯｗｎｅｒＩｎ信号の値が、ワイ
ヤ式のＯＲ操作よりも論理的なＯＲ操作によって演算さ
れるということである。これによってＳｈａｒｅｄＩｎ
およびＯｗｎｅｒＩｎのパイプライン操作が許容され、
その一方では、それらのタイミングおよび解釈上での電
気的な制約を回避するようにされる。所望されるときに
は、ＳｈａｒｅｄＯｕｔ／ＳｈａｒｅｄＩｎ信号の値お
よびＯｗｎｅｒＯｕｔ／ＯｗｎｅｒＩｎ信号の値のパリ
ティ・チェック操作も許容される（増強した実施例につ
いての以下の説明において、このオプションの検討を参
照されたい）。

【００４４】Ｅ． トランザクション トランザクションはバス・プロトコルの最上層のもので
ある。各トランザクションは、独立して裁定されるリク
エスト・パケットおよびリプライ・パケットからなるも
のである。リクエスタがバスに対する裁定手段による裁
定リクエストを登録したときに、ある１個のトランザク
ションが始まるけれども、該裁定手段がバスに許可を出
すまでは、該当のリクエスト・パケットはそのリクエス
ト・レジスタ２８に記憶される。該当のことが生起する
と、リクエスタは、連続的なバス・サイクルの間に、そ
のリクエスト・パケットを一時に１サイクルだけ発生さ
せる。

【００４５】“ヘッダー・サイクル”と呼ばれるリクエ
スト・パケットの初めのサイクルには、リクエスタおよ
びこのリクエスタが始めるトランザクションを同定する
ために必要な全ての情報が含まれている。これには、該
当のトランザクションを好適な結論に導くときに関与す
ることが必要な、１個または複数個のクライエント・デ
バイスを選択するために十分な情報も含まれている。リ
クエスト・パケットの後続のサイクルに一般的に含まれ
ているものは、実行されるべきトランザクションに依存
するデータである。全てのクライエント・デバイス（リ
クエスタを含む）はリクエスト・パケットを受け入れ
て、該当のトランザクションに関与することが要求され
ているか否かを決定するために、該デバイスの各々によ
ってそのヘッダー・サイクルを調べるようにされる。

【００４６】一般的なルールとして、各リクエスト・パ
ケットにおけるヘッダー・サイクルの相当な個数のビッ
トが、メモリ位置またはＩ／Ｏデバイス・レジスタの選
択をするために、リクエスタによって出されるアドレス
に対して保留される。デバイスがある１個のトランザク
ションにおいて関与するように選択されるメカニズム
は、異なるトランザクションのためには異なることがあ
り得るけれども、大方のトランザクションにおいては、
選択メカニズムとしてそのヘッダー・サイクルに含まれ
ているアドレスを使用するようにされる。

【００４７】図９を参照しながら、より詳細にいえば、
この実施例においては、各リクエスト・パケットにおけ
るヘッダー・サイクルの４７ビットがアドレス・フィー
ルドに対して割り当てられている（この実施において
は、これらのビットの中の３２ビットだけが用いられて
おり、このために、他の１５ビットは更に別の伸長作業
のために利用可能なものであって、これの意味すること
は、それらが全て“０”であることを確認するためにア
ドレス・フィールドを読み取るときに、これらの使用さ
れないビットがチェックされねばならないということで
ある）。他のビットの中の１０個のビットは、各クライ
エント・デバイスが指定される固有の識別子である、い
わゆる“ＤｅｖｉｃｅＩＤ”を搬送するために保留され
ている（これらのＤｅｖｉｃｅＩＤは、図示されない手
段によるシステムの起動の間に適当に指定されるもので
ある）。更に、リクエストのヘッダー・サイクルにおけ
る残りのビットの中の５個のビットは、トランザクショ
ンのコマンドのコード化のために使用される。そして、
更に１個の余分のビットは、クライエント・デバイスに
よる保護的“モード”のチェック操作のために用いられ
る（このモードのチェック操作によってクライエント・
デバイスに可能にされることは、リクエスタが、特定さ
れたトランザクションを開始するように権限を付与され
ているかどうかを決定することであるが、このようなモ
ードのチェック操作はこの発明の範囲を超えるものであ
る）。従って、この特定の実施においては、リクエスト
のヘッダー・サイクルで指定のないビットは１ビットだ
けである。

【００４８】リクエスト・パケットを受け入れると、多
くのクライエントがその内部的な状態を変更することが
できるけれども、１個だけのクライエント・デバイスが
任意の所与のリクエストに対してリプライを出すことに
なる。レスポンダは、初めに、部分的または完全にその
リプライのアセンブルをし、これに次いで、そのバスに
対する裁定手段をもって、バスの裁定リクエストの登録
をする。その後で、バスの許可がなされると、１個また
は複数個のデータ・サイクルによって追従されるヘッダ
ー・サイクルをもって再開する連続的なバス・サイクル
の間に、レスポンダは一時に１サイクルのリプライ・パ
ケットを送出する。例えば６４ビット・ワイドのバスに
より、各データ・サイクル上での８オクテット（８ビッ
ト・バイト）のデータ転送ユニットが支持される。これ
に次いで、様々に異なるワードに基づくソフトウエア・
アーキテクチュアを実施するために、これらのバイトが
種々の長さのワードに組成される。

【００４９】図１０に示されているように、各リプライ
・パケットにおけるヘッダー・サイクルは、リクエスタ
から受け入れられたコード化したコマンド、リクエスタ
によって特定されたアドレス、および、リクエスタのＤ
ｅｖｉｃｅＩＤのビットを同定するトランザクションの
反復をする。典型的には、このレスポンダは、リクエス
ト・パケットにおけるヘッダー・サイクルからこの情報
を取り出して、リプライ・パケットにおけるヘッダー・
サイクルの構成の際に用いるためにそれを記憶するだけ
である。この情報によれば、リプライ・パケットが関係
するトランザクションを固有に同定するだけではなく、
リプライ・パケットをトランザクションのリクエスタに
対して明確にリンクするようにされる。

【００５０】ある程度の付加的な詳細における典型的な
リプライ・パケットのヘッダー・サイクルについて考慮
すると、ここで好適に観察されることは、対応するリク
エスト・パケットにおけるヘッダー・サイクルに対して
ビット対ビットで等価のものであって、以下の例外が存
在する。即ち：（１）該当のパケットがリプライである
ことを指示するために、リクエスト／リプライ・フラグ
・ビットが反転される；（２）リプライのアセンブルを
しているとき、レスポンダがフォールトに遭遇したか否
かを指示するために、リクエスト・ヘッダーにおけるモ
ード・ビットが、リプライ・ヘッダーにおけるフォール
ト・ビットとして用いられる；そして、（３）レスポン
ダがトランザクションのためのリクエスト・パケットを
受け入れた時点において、該トランザクションに対して
特定されたアドレスでのデータが多くのキャッシュによ
って共有されたか否かを指示するために、リクエスト・
ヘッダーにおける不使用のビットが、ｒｅｐｌｙＳｈａ
ｒｅｄビットとして用いられる。このｒｅｐｌｙＳｈａ
ｒｅｄビットの機能については、更に十分に後述され
る。しかしながら、この点について適切に注意されるこ
とは、フォールトに遭遇したときにのみ、レスポンダが
フォールト・ビットを真の（“１”の）論理レベルの状
態に駆動するということである。そして、このようなフ
ォールトが生じたときにはいつでも、このビットはリク
エスタに対して効果的にこれを告知する。これにより、
該リクエスタをして、フォールト・コード（これは好適
にはリプライ・パケットにおける第２サイクルの３２個
の下位順序のビットにおいて伝送される）を受け入れる
べく用意をさせる。フォールトの検出およびフォールト
・コードの発生はこの発明の範囲外のことである。

【００５１】前述のように、全てのクライエント・デバ
イスは、何等かの動作がそれらについて要求されている
かどうかを決定するために、リプライ・パケットにおけ
るヘッダー・サイクルを調べるようにされる。その動作
においては、異なるクライエント・デバイスの中でのリ
プライを明確にするためにＤｅｖｉｃｅＩＤが当てにさ
れる。しかしながら、ある種のクライエントは、多くの
未解決または係属のリクエストを持っている可能性があ
る。このために、好適には、多くのＤｅｖｉｃｅＩＤを
クライエントに対して指定することにより、または、そ
れらの未解決なリクエストに対するリプライを明確にす
るために、それらを可能化させるべく何等かの他の適当
な備えをすることにより、リプライがそれらのクライエ
ントの各々において更に明確にされる。

【００５２】リクエスタがリプライを受け入れたときに
は、トランザクションは完了する。大方の場合におい
て、この発明のバス・プロトコルによれば、リクエスト
とリプライとの間で１対１の対応が成立する。しかしな
がら、ある種のリクエスト・パケットは対応のリプライ
・パケットを持っておらず、また、これと逆の関係も成
り立つが、その理由は、バス・プロトコルの実行による
ため、または、エラー等によるためのいずれかである。
かくして、このプロトコルは、不変のものとしてのリク
エスト／リプライのペアリングには依存しないことにな
る。これに代えて要求されることは、任意の所与のバス
上の全てのクライエント・デバイスが、到着の順序にお
けるそれらからの動作を要求するリクエスト・パケット
にサービスをすることだけである。ここで認められるよ
うに、この要求はデータの両立性を維持することの中心
にあるものである。

【００５３】コマンドのコード化、および、この初めの
実施例のために規定されたトランザクションに対するリ
クエスト／リプライ・ペアのパケット・レングスを要約
するテーブルが以下に示されている。 トランザクション・ペア 省略形 コード化 レングス ReadBlockRequest RBRqst 0000 0 2 ReadBlockReply RBRply 0000 1 5 WriteBlockRequest WBRqst 0001 0 5 WriteBlockReply WBRply 0001 1 2 WriteSingleRequest WSRqst 0010 0 2 WriteSingleReply WSRply 0010 1 2 ConditionalWriteSingleRequest CWSRqst 0011 0 2 ConditionalWriteSingleReply CWSRply 0011 1 5 FlushBlockRequest FBRqst 0100 0 5 FlushBlockReply FBRply 0100 1 2 未定義（Undefined ） 0101 0 未定義（Undefined ） 0111 1 IOReadRequest IORRqst 1000 0 2 IOReadReply IORRply 1000 1 2 IOWriteRequest IOWRqst 1001 0 2 IOWriteReply IOWRply 1001 1 2 BIOWriteRequest BIOWRqst 1010 0 2 BIOWriteReply BIOWRply 1010 1 2 MapRequest MapRqst 1110 0 2 MapReply MapRply 1110 1 2 DeMapRequest DeMapRqst 1111 0 2 DeMapReply DeMapRply 1111 1 2

【００５４】ここで認められるように、３個の一般的な
タイプのトランザクションがある。即ち、（ａ）キャッ
シュされたデータの両立性を維持しながら、メモリ・ア
クセス動作を実行するためのメモリ・トランザクショ
ン、（ｂ）プログラムされたＩ／Ｏ動作を実行するため
のＩ／Ｏ・トランザクション、および、（ｃ）更に他の
機能を実施するための多面的なトランザクションがあ
る。ここで評価されるように、リクエスト／リプライ・
フラグ・ビット（即ち、前述のテーブルにおいて示され
ているようなコマンド・フィールドの第５ビット）の論
理的なレベル（“０”または“１”）は、任意の所与の
パケットがリクエストまたはリプライのいずれであるか
を指示するためには十分なものであることから、トラン
ザクションのコマンドの極めてコンパクトで効率的なコ
ード化をすることが実際的である。このコマンド・フィ
ールドのフォーマットを用いて、１６個までの異なるコ
マンドのコード化をすることが可能であるから、上記の
ように規定されたトランザクションでは、コマンド・フ
ィールドの容量を部分的に消耗するだけであることが理
解される。勿論、所望であるときには、付加的な特徴を
実現する更に別のトランザクションを規定するために、
コマンド・フィールドの余分の容量を用いることができ
る。

【００５５】１． メモリ関連のトランザクション Ｉ／Ｏデバイスとメモリとの間でと同様に、プロセッサ
とメモリとの間でのデータの転送をするためにメモリ・
トランザクションが用いられる。これをより詳細にいえ
ば、メイン・メモリ１３または他のキャッシュからデー
タ・ブロックを読み取るために、所望のデータ・ブロッ
クのバージョンがメモリ・システムのいずれかの位置に
キャッシュされているかどうかに依存して、そして、そ
うであるときには、該キャッシュされたバージョンが
“ｏｗｎｅｄ（所有されている）”であるかどうかに依
存して、ＲｅａｄＢｌｏｃｋがキャッシュ・リクエスタ
によって呼ばれる。所有されているデータ・ブロック
（即ち、局部的に初期化された書き込み−即ち、メモリ
・ツリーの同じブランチにおけるプロセッサによって初
期化された書き込み−によって最近に修正されたデータ
のブロック）をメイン・メモリ１３に対して書き戻すた
めに、ＦｌｕｓｈＢｌｏｃｋがキャッシュ・リクエスタ
によって呼ばれることができる。そして、ＷｒｉｔｅＢ
ｌｏｃｋは、任意の中間的なレベルのキャッシュ１９ａ
−１９ｉおよびトランザクションに対して特定されるア
ドレス上で合致する任意の第１のレベルのキャッシュ１
６ａａ−１６ａｊ（図１を参照）に対するのと同様に、
データ・ブロックをメイン・メモリ１３に対して直接書
き込むために、２次的なデータ源（即ち、メモリ・シス
テムに対して外部にあるデータ・プロデューサ）を可能
化するために利用できるものである。換言すれば、この
ＷｒｉｔｅＢｌｏｃｋで許容されることは、キャッシュ
を通してデータを迂回させることなく、新規なデータを
マルチプロセッサ１１の主要なメモリ・システムに導入
することである。

【００５６】これらの“ブロック”トランザクションの
全ては、物理的なアドレス空間に直列に整列している４
個の６４−ビット・ワードのような、複数個の連続的な
ワードにわたっている。そのために、任意のこのような
データ・ブロック内の第１の個別にアドレス可能な量の
アドレスは０ ｍｏｄ Ｎであり、ここに、Ｎは各デー
タ・ブロックに含まれている個別にアドレス可能な量の
個数である。有利なことに、各バス上での全てのデータ
・ブロックの転送の組成は、アドレスされた量がバス上
の第１のデータ・サイクル内に現れ、データ・ブロック
の残りの量がサイクリックな順序でこれに追従するよう
にされていることである。図１１を参照されたい。これ
により、特定されたアドレスからデータを検索するため
のメモリの待機が最小にされるが、これはキャッシュ
“ミス”のときには特に望ましいことである。

【００５７】ＷｒｉｔｅＳｉｎｇｌｅトランザクション
は、共有しているデータについて多くのキャッシュされ
たコピーを更新するために、必ずしもメイン・メモリ１
３に影響をおよぼすことなく、キャッシュ・リクエスタ
によって呼ばれる。このトランザクションは、影響のあ
るデータ・ブロックのコピーを含んでいるキャッシュに
よってのみ呼ばれるものである。Ｃｏｎｄｉｔｉｏｎａ
ｌＷｒｉｔｅＳｉｎｇｌｅは、このように共有されてい
るデータに対して微細な読み取り−修正−書き込みの実
行をするために、キャッシュ・リクエスタによって呼ぶ
ことができる、密接な関連のあるオプション的なトラン
ザクションである。

【００５８】２． Ｉ／Ｏ トランザクション Ｉ／Ｏトランザクションによれば、図１におけるＬＡＮ
コントローラ２９ｉのようなＩ／Ｏデバイスとの間で、
プロセッサがデータの転送をすることが許容される。こ
れらのＩ／Ｏトランザクションのために採用されるアド
レス空間（即ち、“Ｉ／Ｏ空間”）は、全体としては、
メモリ・トランザクションのために使用されるアドレス
空間（即ち、“メモリ空間”）とは関連しておらず、こ
のために、ある所与の有効なアドレスがメモリ空間また
はＩ／Ｏ空間のいずれかに存在するけれども、その双方
に存在することはない。ここで認められるように、Ｉ／
Ｏトランザクションはデータの両立性についての関連を
持たず、また、データ両立性プロトコルはＩ／Ｏトラン
ザクションについての関連を持たないものである。

【００５９】ＩＯＲｅａｄ，ＩＯＷｒｉｔｅおよびＢＩ
ＯＷｒｉｔｅトランザクションは、この実施例におい
て、Ｉ／Ｏ動作を実行するために規定されたものであ
る。各Ｉ／Ｏデバイスは共通のアドレス空間の固有の部
分が指定されており、これらのトランザクションは該当
のアドレス空間に対して発せられる。このために、図１
におけるコントローラ２９ｉのようなＩ／Ｏデバイス
は、それらに対してアドレスされるＩ／Ｏコマンドを解
釈することが自由であり、所要に応じて、それらを所望
のトランザクションに対して効率的に関与させることが
できる。ＩＯＲｅａｄトランザクションおよびＩＯＷｒ
ｉｔｅトランザクションは、キャッシュ・リクエスタに
より起動されて、それぞれに、特定されたＩ／Ｏアドレ
スとの間でアドレス可能な量の読み取りおよび書き込み
をするようにされる。ＢＩＯＷｒｉｔｅもキャッシュ起
動式のトランザクションであって、Ｉ／Ｏアドレス空間
に対して単一のアドレス可能な量を書き込むためのもの
であるが、ある所与の“デバイス・タイプ”の多くの事
例に対してデータを同時に書き込むことが許容されてい
るために、Ｉ／ＯＷｒｉｔｅトランザクションとは異な
るものである。このために、ＢＩＯＷｒｉｔｅは無制限
のグローバルな放送的トランザクションではないけれど
も、ある所与のタイプの全てのデバイスに対しては放送
的なものである。“デバイス・タイプ”の規定はシステ
ムに依存するものであり、この発明の範囲を超えてい
る。

【００６０】図１の１８ｉにおいて示されているＩ／Ｏ
ブリッジに移行して理解されるべきことは、メモリ・シ
ステムに関する限りはそれがハイブリッド・デバイスで
あるということである。より詳細にいえば、このＩ／Ｏ
ブリッジ・デバイス１８ｉは、キャッシュ１６ａａ−１
６ｉｊと機能的に類似のキャッシュ６０を介してマルチ
プロセッサ１１のメモリ・システムに直接アクセスす
る、外部系列のコンピュータ・システムのメモリ・バス
のような、非同期的なＩ／Ｏデバイスを備えるために有
用なものである。その目的のためにブリッジ１８ｉに含
まれているもの（図示されない）は、このようなＩ／Ｏ
デバイスによって出されたメモリの読み取りおよび書き
込みをバッファリングするための、そして、それらの読
み取りおよび書き込みを規定のメモリ・トランザクショ
ンに変換するためのものである。しかしながら、それは
Ｉ／Ｏ空間の部分内のＩ／Ｏトランザクションにも応答
するものであるが、その意味するところは、プロセッサ
１２ａａ−１２ｉｊがＩ／Ｏブリッジ１８ｉの内部資源
および該ブリッジ１８ｉが接続されるＩ／Ｏデバイスの
レジスタをアクセスできることである。

【００６１】Ｉ／Ｏアドレス空間の指定は通常のことで
はないが、その理由は、マルチプロセッサ１１のいずれ
かのバスに接続され得る異なるＩ／Ｏデバイスについて
のＩ／Ｏアドレス空間のサイズに関する要求が相当に異
なっていることにあるだけである。従って、実際的な態
様としては、各Ｉ／Ｏデバイスに対するＩ／Ｏアドレス
空間の指定が該デバイスにとって必要であるようなアド
レス空間と合理的に近似することが確実であるように、
Ｉ／Ｏアドレス空間を指定するときにこれらの差異を考
慮に入れるべきである。

【００６２】３． 多面的トランザクション ＭａｐおよびＤｅＭａｐはキャッシュで呼ばれるトラン
ザクションであって、マルチプロセッサ１１の仮想メモ
リ環境において高速の仮想的−物理的アドレス空間のマ
ッピングを実行するためのものである。その目的のため
に、Ｍａｐでキャッシュ・リクエスタが許容されること
は、図１の１７ａにおけるようなマップ・キャッシュか
ら、仮想的ページ−物理的ページのマッピング・エント
リを読み取ることである。これに対して、ＤｅＭａｐに
よれば、仮想的なアドレス空間の任意特定のページに対
するキャッシュ駐在の仮想的−物理的アドレス・マップ
を無効にするために、キャッシュ・リクエスタが可能に
される。

【００６３】Ｆ． データの両立性 全てのバス・クライエントに対する共有メモリのマルチ
プロセッサ環境において必須であることは、メモリ空間
における任意の所与のアドレスに対するデータ値を同じ
シーケンスでアクセスすることである。これは“データ
の両立性”として参照される。このようなマルチプロセ
ッサにおける個別のプロセッサに対して分離したキャッ
シュ・メモリを用いることは、このデータの両立性を維
持するという問題を複雑にするものであり、特に、より
大規模なシステムにおいて、任意の所与の時点において
キャッシュ内に存在し得るある所与のコピーの潜在的な
個数が大きいときに問題を複雑にするものである。

【００６４】しかしながら、特に効果的なデータの両立
性のプロトコルを実施することは、プロセッサ１２ａａ
−１２ｉｊおよびＩ／Ｏブリッジ１８ｉによって要求さ
れるメモリ・トランザクションの開始および実行をする
ために、いわゆる書き戻しキャッシュ（即ち、メイン・
メモリを即座に更新することなく、プロセッサによって
出されたデータの書き込みに従ってキャッシュされたデ
ータの更新をするキャッシュ）を用いることによって可
能にされる。これらのキャッシュは、メモリ空間におけ
る全てのアドレスからの要求に応じてデータのフェッチ
および記憶をすることができるが、その理由は、メモリ
空間内の任意の所与のアドレスにおけるデータの多くの
コピーの外部的な両立性が、上述されたトランザクショ
ンのある所定のものの使用を通して、ハードウエアによ
って自動的かつ透明的に維持されるためである。更に、
プロセッサ１２ａａ−１２ｉｊおよびＩ／Ｏブリッジ１
８ｉに対するメモリの両立性のある観察を維持しなが
ら、Ｉ／Ｏデバイスによるメモリ空間に対する直接アク
セスが許容される。

【００６５】より詳細には、更に詳述されるように、キ
ャッシュ１２ａａ−１２ｉｊ，１９ａ−１９ｉ，６０
は、それぞれのバス上のトラフィックを直接または間接
にモニタすることによってデータが共有されるようにな
った時点を検出し、また、任意のプロセッサ（またはＩ
／Ｏブリッジ１８ｉ）がメモリ空間における共有のデー
タ値を更新したときには、いつでも放送的な書き込みを
実行する。キャッシュ１２ａａ−１２ｉｊおよび６０の
全ては“スヌーピー・キャッシュ”であるが、これの意
味することは、それらがバス上の全てのトランザクショ
ンをモニタすることにある。

【００６６】１． シングル・レベル・システムにおけ
るデータの両立性 先に指摘されたように、シングル・レベル・システムを
構成する１個または複数個のプロセッサは、図１におけ
るプロセッサ１２ａａ−１２ａｊのようなものであっ
て、共有のメイン・メモリとともに、それぞれのキャッ
シュ１６ａａ−１６ａｊを介して、それらのメモリ・バ
ス１５ａと接続されている。プロセッサ１２ａａ−１２
ａｊは、それぞれに、それらのキャッシュ１６ａａ−１
６ａｊを介してメイン・メモリをアクセスしていること
から、任意の所与のアドレスにおける全てのキャッシュ
されたコピーの間のデータの両立性を維持することで十
分であることが明かにされてくる。これの意味すること
は、キャッシュされているメイン・メモリのコピーが、
１個または複数個のキャッシュされたコピーに関しては
古いことがあり得ることであるが、この古いメイン・メ
モリのデータに起因する演算上のエラーのリスクを負う
ことはない。

【００６７】データの両立性を維持するために、両立性
プロトコルが依存する各キャッシュは、特定のキャッシ
ュの要求においてバス上で係属しているトランザクショ
ンに従う任意のデータ・ブロックに対するｐｅｎｄｉｎ
ｇＳｔａｔｅとともに、キャッシュしている各データ・
ブロックに対する“共有”および“固有”の２個の状態
ビットを保持している。これに加えて、通常は、キャッ
シュ１６ａａ−１６ａｊは、現にキャッシュされている
データ・ブロックと、オーバライト可能な削除された、
または、“空白の”データ・ブロックとの間の区別をす
るために、それらのデータ・ブロックの各々に対する
“有効”状態ビットを保持している。

【００６８】共有ビットの状態で指示されることは、関
連のデータ・ブロックについて多くのキャッシュされた
コピーが存在し得るか否かということである。多くのキ
ャッシュされたコピーが存在するときには、該共有ビッ
トは真の（“１”の）状態に肯定的にセットされるが、
キャッシュされたコピーが１個しか存在しないときに
は、必ずしも偽の（“０”の）状態にはリセットされな
いことから、これは控え目な指示である。これに対し
て、ある所与のキャッシュを介して通信するプロセッサ
その他のデバイスが、特定のデータ・ブロックに対する
最近の（即ち、最後の）書き込みを実行する責任があっ
たときにのみ、該データ・ブロックに対する固有ビット
が該所与のキャッシュにおいて真の（“１”の）状態に
セットされる。これの意味することは、バス上の１個ま
たは複数個の他のキャッシュも同じデータ・ブロックの
コピーを含んでいるとしても、任意の所与のバス上での
任意の時点におけるある所与のデータ・ブロックについ
て、“固有”のキャッシュは１個だけということであ
る。これに加えて、バス上で係属している各トランザク
ションに対してキャッシュが維持するｐｅｎｄｉｎｇＳ
ｔａｔｅによってキャッシュにできることは、トランザ
クションがまだ係属中であるときに該当のデータ・ブロ
ックのキャッシュされたコピーの個数が変化するとして
も、リプライが受け入れられたときに、トランザクショ
ンが関連しているデータ・ブロックに対するその共有ビ
ットのための値を正確に演算することができる。このｐ
ｅｎｄｉｎｇＳｔａｔｅの情報によってキャッシュにで
きることは、より十分に後述されるように、該当のトラ
ンザクションに対する正確なデータ値を得るべく、キャ
ッシュが適切な動作をするように、その係属中のトラン
ザクションによって特定されるアドレスにおけるデータ
の値を修正できる介在のトランザクションを同定するこ
とでもある。

【００６９】一般的なルールとして、その関連のプロセ
ッサがフェッチ・コマンドまたは記憶コマンドを発生し
たときには（即ち、このようなコマンドが発生されるべ
きアドレスがキャッシュ内に存在しないときには）、第
１のレベルのキャッシュでＲｅａｄＢｌｏｃｋＲｅｑｕ
ｅｓｔが起動して、“キャッシュ・ミス”が生じるよう
にする。必要であるときには、キャッシュからメイン・
メモリにデータを書き込み、これによって新規なデータ
を記憶するためのキャッシュ内の記憶スペースを自由に
するように、このキャッシュもＦｌｕｓｈＢｌｏｃｋを
起動させることができる（ここで想起されるように、古
いデータをメイン・メモリに書き込むことを回避するた
めに、それらの固有ビットのセットを有するデータ・ブ
ロックだけがＦｌｕｓｈＢｌｏｃｋによって書き出され
ることになる）。共有ビットのセット（“１”）を有す
るデータ・ブロックに対して関連のあるプロセッサによ
る書き込みがなされるときには、更にキャッシュによっ
てＷｒｉｔｅＳｉｎｇｌｅトランザクション（これは前
述された書き込みであって、データの両立性が無視でき
るときには、必要とされる最小のセットの動作から両立
性プロトコルを区別することである）が始められる。

【００７０】リクエスタを含んでいる全てのキャッシュ
は、ＲＢＲｑｓｔ，ＷＳＲｑｓｔ，ＷＳＲｐｌｙ，ＣＷ
ＳＲｑｓｔ，ＣＷＳＲｐｌｙ，およびＷＢＲｑｓｔパケ
ット（即ち、特定されたアドレスにおけるデータの値お
よび／または非共有状態に影響があり得るパケット）の
いずれかのヘッダー・サイクルにおいて特定されるアド
レスに合致させようとする。その係属中のトランザクシ
ョンの各々に対してリクエスタが維持しているｐｅｎｄ
ｉｎｇＳｔａｔｅに含まれているデータのアドレスは、
リクエスタがその固有のリクエスト・パケットを受け入
れたときに偽の（“０”の）状態にクリアされる共有の
状態とともに、同じアドレスを特定する前述のタイプの
介在パケットをリクエスタが検出できるためのトランザ
クションに従うものである。これでリクエスタが可能に
されることは、トランザクションが係属中である間に特
定のデータ・ブロックが共有の状態になるときに、その
係属中のトランザクションに従う任意のデータ・ブロッ
クに対する共有の状態を真の（“１”の）状態にセット
することである。更に、ある程度詳細に付加的に後述さ
れるように、トランザクションが係属中である間に、デ
ータの値が、係属中のトランザクションが変化されるの
に従っているときには、リクエスタによって適当な訂正
動作をすることも可能にされる。

【００７１】リクエスタ以外の全てのキャッシュによっ
て簡単に合致されることは、上記のように列挙されたヘ
ッダー・サイクルにおいて特定されたアドレスを、それ
らがキャッシュしているデータ・ブロックのアドレスに
対抗させて、該特定のアドレスが含まれているかどうか
を決定するためである。ＦｌｕｓｈＢｌｏｃｋトランザ
クションは、そのような動作がなされている他のキャッ
シュに対して告知をすることを必要とせずに、キャッシ
ュからメイン・メモリへのデータ・ブロックの書き込み
だけのために使用されるものであることから、このよう
な合致操作はＦＢＲｑｓｔパケットまたはＦＥＲｐｌｙ
パケットのいずれかのために必要とされることはない。
同様にして、メモリが対応のＷＢＲｑｓｔパケットを処
理したことを確認するだけであることから、ＷＢＲｐｌ
ｙに対するアドレスの合致操作は不要である。更に、Ｒ
ＢＲｐｌｙはリクエスタだけに関連するものであるか
ら、他のキャッシュはこのようなパケットを無視するこ
とができる。

【００７２】ＲＢＲｑｓｔ，ＷＳＲｑｓｔまたはＣＷＳ
Ｒｑｓｔパケットのヘッダー・サイクルにおいて特定さ
れるアドレスと好都合に合致しているリクエスタを除く
各キャッシュは、そのバス・インタフェース４１（図
６）の両立性ポートにおけるＳｈａｒｅｄＯｕｔの主張
をし、これによって、該当する特定のアドレスにおける
データ・ブロックが共有されていることの信号をする。
このようなキャッシュも、先にそのようにセットされて
いないときには、該特定されたデータ・ブロックのその
コピーに対する共有ビットを真の（“１”の）状態にセ
ットする。ここで想起されるように、全てのリクエスト
・パケットおよびリプライ・パケットのヘッダーはＤｅ
ｖｉｃｅＩＤ（図９および図１０を参照）を備えてい
て、それらが任意の所与のパケットに対するリクエスタ
であるか否かについて、バス・クライエントで決定する
ことが可能にされる。

【００７３】ここで認められるように、バス上の任意の
キャッシュによるＳｈａｒｅｄＯｕｔの主張は、データ
・ブロックのキャッシュ・オーナまたはメイン・メモリ
１３（キャッシュ・オーナが存在しないとき）によって
リプライが付与されるかどうかには拘らず、対応するリ
プライ・パケットのヘッダー・サイクルにおけるｒｅｐ
ｌｙＳｈａｒｅｄビットを真の（“１”の）状態にセッ
トさせるのに十分なものである。これは次の事実に従う
ものである。即ち、キャッシュからのＳｈａｒｅｄＯｕ
ｔ信号は（図示されない手段により）論理的にＯＲがと
られ、共有ライン６１（図１２）を介して、全てのバス
・クライエント・インタフェース４１の両立性ポートに
加えられるＳｈａｒｅｄＩｎ信号の値を完成するように
される。

【００７４】これに対して、リクエスタは、その係属す
るトランザクションに対するリプライのヘッダー・サイ
クルにおいて受け入れるｒｅｐｌｙＳｈａｒｅｄビット
と、該トランザクションのためにそのｐｅｎｄｉｎｇＳ
ｔａｔｅにおいて維持される共有ビットとのＯＲをとる
ようにされる。このために、リクエスタがそのリクエス
ト・パケットを発したときにデータ・ブロックが他のキ
ャッシュ内に存在しているとき、または、リクエスタが
そのリプライを待機している間にデータ・ブロックが他
のキャッシュ内にコピーされたときのいずれかであると
きには、特定されたデータ・ブロックのそのコピーに対
するリクエスタの共有ビットは、そのリプライを受け入
れたときに真に（“１”に）セットされる。

【００７５】ＷＳＲｑｓｔまたはＣＷＳＲｑｓｔを発す
るリクエスタはデータ・ブロックのそのコピーに対する
その共有ビットのセットまたはリセットをする。このデ
ータ・ブロックに関連するトランザクションは、それを
受け入れる対応のリプライ・パケット（図１０参照）の
ヘッダー・サイクルにおけるｒｅｐｌｙＳｈａｒｅｄビ
ットの状態、および、該当のリプライが受け入れられる
ときのそのｐｅｎｄｉｎｇＳｔａｔｅの共有状態に依存
するものである。リプライのヘッダーにおけるｒｅｐｌ
ｙＳｈａｒｅｄビットが偽の（“０”の）状態にあると
き、および、該トランザクションに対するそのｐｅｎｄ
ｉｎｇＳｔａｔｅにおける共有状態が偽（“０”）であ
るときの双方であるときには、その書き込みがなされて
いるデータ・ブロックのコピーが他のキャッシュには含
まれていないことが、リクエスタによって確認される。
従って、リクエスタはこれに次いで特定のデータ・ブロ
ックに対するその共有ビットを偽の（“０”の）状態に
リセットし、これによって、データ・ブロックの状態が
共有状態から非共有状態に変更されるときに、該共有ビ
ットが最終的に確実にリセットするようにされる。

【００７６】記憶されているデータ・ブロックに対して
キャッシュが維持しているオーナ・ビットの扱いは更に
簡単なことである。これを略述すれば、そのプロセッサ
の側でデータ・ブロックへの書き込みがなされるときは
いつでも、キャッシュにおいて、データ・ブロックに対
するそのオーナ・ビットのセットがなされる。これに対
して、キャッシュにおいては、データ・ブロックに含ま
れているアドレスのために、任意の他のキャッシュによ
って要求されるＷｒｉｔｅＳｉｎｇｌｅまたはＣｏｎｄ
ｉｔｉｏｎａｌＷｒｉｔｅＳｉｎｇｌｅトランザクショ
ンに対するＷＳＲｐｌｙまたはＣＷＳＲｐｌｙにおける
特定のアドレスで、該キャッシュをして好都合に合致す
るようにさせるときにはいつでも、データ・ブロックに
対するそのオーナ・ビットのリセット（クリア）がなさ
れる。データ両立性のプロトコルに関する限り、Ｗｒｉ
ｔｅＳｉｎｇｌｅおよびＣｏｎｄｉｔｉｏｎａｌＷｒｉ
ｔｅＳｉｎｇｌｅは完全に等価のものであるから、ここ
で理解されるべきことは、共有ビットおよびオーナ・ビ
ットに対するＷｒｉｔｅＳｉｎｇｌｅトランザクション
の効果についての以下の説明は、Ｃｏｎｄｉｔｉｏｎａ
ｌＷｒｉｔｅＳｉｎｇｌｅに対して良好に当てはまるも
のである。

【００７７】先に指摘されたように、プロセッサによれ
ば、それぞれのキャッシュ内に存在するデータ・ブロッ
クにデータを書き込むことにより、共有メモリ・システ
ムへのデータの記憶がなされる。データ・ブロックに対
する共有ビットが偽の（“０”の）論理レベルにある間
に、関連のキャッシュ内に存在するデータ・ブロックの
一つのワードまたはアドレス可能な量の一つにおいて、
ある所与のデータ値を記憶させるための記憶コマンドが
プロセッサから発せられたときには、該プロセッサは即
座にキャッシュされたデータ・ブロックの適切な部位
（例えば、ワード）の更新を行い、これと同時に、該当
のデータ・ブロックに対するオーナ・ビットのセットを
する。これに対して、プロセッサによる記憶コマンドが
指向されるデータ・ブロックに対する共有ビットが真の
（“１”の）論理レベルにセットされたときには、該キ
ャッシュは記憶コマンドの実行を留保してＷＳＲｑｓｔ
パケットを発する。このＷＳＲｑｓｔパケットによれ
ば、（ａ）該プロセッサがその記憶コマンドに指向した
物理的アドレス（この物理的アドレスは典型的にはプロ
セッサによって付与された仮想的アドレスの変換によっ
て規定される）が同定され、また、（ｂ）該プロセッサ
によって生成されたデータ値を含むようにされる。

【００７８】全てのＷＳＲｐｌｙパケットは、単一レベ
ル・システムにおけるメモリ・コントローラからのもの
である。更に、１個のＷＳＲｐｌｙパケットは、対応す
るＷＳＲｑｓｔパケットの物理的アドレスおよびデータ
値の双方を写しているものである。このために、そのＷ
ＳＲｐｌｙパケットを受け入れると、キャッシュ・リク
エスタは、そのプロセッサに対するデータの記憶を実行
するだけではなく、該プロセッサのデータが真の
（“１”の）状態に書き込まれるデータ・ブロックに対
するそのオーナ・ビットのセットも実行する。このＷＳ
Ｒｐｌｙパケットのヘッダー・サイクルにおいて特定さ
れるアドレス上で合致する他のキャッシュのいずれであ
っても、（ａ）リプライ・パケットによって与えられる
データ値に基づいてアドレスされる、該リプライ・パケ
ットに対するそれらのデータのコピーを更新し、また、
（ｂ）偽の（“０”の）状態に更新されたデータ・ブロ
ックに対するそれらのオーナ・ビットをリセットするよ
うにされる。ここで認められるように、これで確実にさ
れることは、任意の所与のバス・サイクルの間に、いず
れのキャッシュであっても任意の所与のデータ・ブロッ
クについての所有権を主張できないということである。
これの意味することは、メイン・メモリから読み取られ
てから書き込みがなされていない、いずれのキャッシュ
されたデータ・ブロックについて、いずれのキャッシュ
による所有権の主張もなされないということである。

【００７９】前述のことに鑑みて理解されることは、キ
ャッシュ・リクエスタがある特定のアドレスにおいてデ
ータ・ブロックに対するそのバス上にＲＢＲｑｓｔパケ
ットを生成させたときには、該データ・ブロックは該バ
ス上での他のキャッシュに固有のものになったり、なら
なかったりできるということである。しかしながら、他
のキャッシュの一つが特定のデータ・ブロックを固有の
ものにしているときには、そのオーナ（および、恐らく
は１個または複数個の他のキャッシュの）はそのアドレ
ス上で合致するようにされて、これにより、それらの各
々がＳｈａｒｅｄＯｕｔを主張するようにされる。更
に、このオーナはＯｗｎｅｒＯｕｔの主張も行い、これ
によりＯｗｎｅｒＯｕｔ信号の論理的ＯＲをとるように
もされて、ＯｗｎｅｒＩｎライン６２（図１２）を真の
（“１”の）状態に駆動するようにされる。Ｏｗｎｅｒ
Ｉｎ信号の真の（“１”の）状態により、メイン・メモ
リがＲＢＲｑｓｔに応答することが防止されて、対応の
ＲＢＲｐｌｙパケットを供給するための責任が特定のデ
ータ・ブロックについてのキャッシュ・オーナに転嫁さ
れる。これに対して、キャッシュのいずれも該特定のデ
ータ・ブロックの所有権を主張しないときには（即ち、
ＯｗｎｅｒＩｎ信号が偽（“０”）であるときには）、
該データ・ブロックが共有されているものであっても、
メイン・メモリからＲＢＲｐｌｙが供給される。

【００８０】前述されたように、パケットによるバスの
切り換えで生成されるリスクは、データ・ブロックの所
有権の変化がなされるのは、リクエスタがＲＢＲｑｓｔ
を発した後であるが、対応のＲＢＲｐｌｙを受け入れる
前であるということである。例えば、リクエストが発せ
られる時点においてメイン・メモリに固有のものである
データ・ブロックに対して、キャッシュはＲＢＲｑｓｔ
を発することができる。しかしながら、僅かな時間だけ
早いときには、その同じデータ・ブロックに対して新規
なデータを書き込むために、他のいずれかのキャッシュ
がＷＳＲｑｓｔを発していることがある。ここでのリス
クは、リクエスト・パケットの到着順にメモリによるサ
ービスがなされるために、ＲＢＲｐｌｙパケットに先だ
って、ＷＳＲｐｌｙパケットがメモリによって発せられ
ることである。もし、これが生じたとすると、Ｗｒｉｔ
ｅＳｉｎｇｌｅトランザクションを開始させたキャッシ
ュが、該データ・ブロックのオーナになる。データ・ブ
ロックの所有権におけるこの介在的な変化にも拘らず、
そのようにできるときには、メイン・メモリ１３（図
１）はまだＲＢＲｐｌｙを供給することになる。これの
理由は、ＲＢＲｑｓｔが受け入れられたときに、特定の
データ・ブロックについて、キャッシュ・オーナがその
所有権を主張する用意がなかったからである。これの意
味することは、このＲＢＲｑｓｔパケットによって付与
されたデータは古いということである。従って、古いデ
ータの取り込みを回避するためには、リクエストされた
データ・ブロックに対する正しい値を算出するため、ま
たは、その当初のＲＢＲｑｓｔに対するＲＢＲｐｌｙの
受け入れの後でのＲｅａｄＢｌｏｃｋの再試行を始める
ためのいずれかのために、ＲｅａｄＢｌｏｃｋリクエス
タにおいては、そのＲＢＲｑｓｔに対するｐｅｎｄｉｎ
ｇＳｔａｔｅが用いられる。そのリクエストが古いデー
タの使用を避けるために係属している間に、ＲｅａｄＢ
ｌｏｃｋリクエスタが考慮に入れることを必要とするパ
ケットは、そのＲＢＲｑｓｔパケットがアドレスされる
データ（ＷＳＲｐｌｙ、ＣＷＳＲｐｌｙおよびＷＢＲｑ
ｓｔ）を修正するためのものである。

【００８１】メモリ・システムに関する限り、Ｗｒｉｔ
ｅＢｌｏｃｋトランザクションはＦｌｕｓｈＢｌｏｃｋ
トランザクションに類似しているけれども、これと等価
のものではない。キャッシュはＦＢＲｑｓｔを無視する
けれども、ＷＢＲｑｓｔを無視することはない。これに
代えて、ＷＢＲｑｓｔによって特定されるアドレス上で
合致する任意のキャッシュにより、そのアドレスで合致
しているデータ・ブロックを、ＷＢＲｑｓｔパケットに
よって含まれているデータ・ブロックをもってオーバラ
イトされ、そして、該当のデータ・ブロックに対するそ
のオーナ・ビットを偽の（“０”の）状態にリセット
（クリア）するようにされる。

【００８２】一つの簡単な例により、単一レベルの両立
性プロトコルについての前述の説明に対して、ある種の
有用な見通しが付加される。ここで認められるように、
次に続く例において説明されることは、特定されたメモ
リ位置（アドレス７３）に対するイベントのシーケンス
であって、図１２に示されている共有メモリ・システム
８３における５個のキャッシュ８２ａ−８２ｅのいずれ
にも該当のアドレスが含まれていない状態から出発する
ようにされている。その便宜のために、この例において
用いられている参照数字は、図１２において用いられて
いる参照数字に対応している。 １． ａ．プロセッサ８１ａでアドレス７３を読み取
る。 ｂ．キャッシュ８２ａはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．メイン・メモリ８６でリクエストされたデータを付
与する。 ｄ．データ・ブロックのキャッシュされたコピーに対す
る状態ビットは：Ｓｈａｒｅｄ_82a ＝０，かつＯｗｎｅ
ｒ_82a ＝０である。 ２． ａ．プロセッサ８１ｂでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｂはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａはアドレス７３を含んでいるデー
タ・ブロックに対するそのＳｈａｒｅｄビットを真の
（“１”の）状態にセットし、また、ＳｈａｒｅｄＯｕ
ｔを主張して、ある所定の遅れの後に、ＳｈａｒｅｄＩ
ｎライン６１が真の（“１”の）状態になるように駆動
される。 ｄ．メモリ８６はまだデータを付与する。 ｅ．データ・ブロックのキャッシュされたコピーに対す
る状態ビットは：Ｓｈａｒｅｄ_82a ＝Ｓｈａｒｅｄ_82b
＝１；Ｏｗｎｅｒ_82a ＝Ｏｗｎｅｒ_82b ＝０である。 ３． ａ．プロセッサ８１ｃでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｃはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａおよびキャッシュ８２ｂはＳｈａ
ｒｅｄＯｕｔを主張して、これにより、ＳｈａｒｅｄＩ
ｎライン６１が再びハイ（“１”）になるように駆動さ
れる。 ｄ．メモリ８６はまだデータを付与する。 ｅ．データ・ブロックのキャッシュされたコピーに対す
る現在の状態ビットは：Ｓｈａｒｅｄ_82a ＝Ｓｈａｒｅ
ｄ_82b ＝Ｓｈａｒｅｄ_82c ＝１；Ｏｗｎｅｒ_82a ＝Ｏｗ
ｎｅｒ_82b ＝Ｏｗｎｅｒ_82c ＝０である。 ４． ａ．プロセッサ８１ｃでアドレス７３を書き込
む。 ｂ．データが共有されていることから、キャッシュ８２
ｂがバス８５上でＷｒｉｔｅＳｉｎｇｌｅを実行する。 ｃ．キャッシュ８２ａおよびキャッシュ８２ｃはＳｈａ
ｒｅｄＯｕｔを主張して、これにより、ＳｈａｒｅｄＩ
ｎライン６１がハイ（“１”）に駆動される。 ｄ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはアドレス７３におけるそれらの値を更新す
るが、メモリ８６は実行しない。 ｅ．キャッシュ８２ｂはアドレス７３を含むデータ・ブ
ロックのオーナになる（Ｏｗｎｅｒ_82b ＝１）が、そう
ではないデータ・ブロックのキャッシュされたコピーに
対する共有状態ビットおよび固有状態ビットは変化しな
い。 ５． ａ．プロセッサ８１ｄでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｄはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはライン６１上のＳｈａｒｅｄＩｎに対する
ＳｈａｒｅｄＯｕｔを主張する。 ｄ．キャッシュ８２ｂはＯｗｎｅｒＯｕｔを主張し、こ
れにより、ある所定の遅れの後で、ＯｗｎｅｒＩｎのラ
イン６２を真の（“１”の）状態に駆動するようにされ
る。これにより、メイン・メモリ８６の応答が禁止され
る。これに代えて、データ・ブロックがそのオーナ・キ
ャッシュ８２ｂによって付与される。 ｅ．キャッシュ８２ｄはデータ・ブロックのそのコピー
を、Ｓｈａｒｅｄ_82d ＝１，Ｏｗｎｅｒ_82d ＝０，とし
てマークする。そうではないデータ・ブロックのキャッ
シュされたコピーに対する共有状態ビットおよび固有状
態ビットは変化しない。 ６． ａ．プロセッサ８１ｄで現在のアドレス７３を書
き込む。 ｂ．データは共有されていることから、キャッシュ８２
ｄはバス８５上でＷｒｉｔｅＳｉｎｇｌｅを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはＳｈａｒｅｄＯｕｔを主張して、Ｓｈａｒ
ｅｄＩｎのライン６１が再びハイ（“１”）に駆動され
る。 ｄ．アドレス７３を含むデータ・ブロックの所有権がキ
ャッシュ８２ｂからキャッシュ８２ｄに変化する（Ｏｗ
ｎｅｒ_82b ＝０，Ｏｗｎｅｒ_82d ＝１）。そうではない
データ・ブロックのキャッシュされたコピーに対する共
有状態ビットおよび固有状態ビットは変化しない。 ７． ａ．プロセッサ８１ｅでアドレス７３を書き込
む。 ｂ．キャッシュ８２ｅはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂ，キャッシュ
８２ｃ，およびキャッシュ８２ｄはＳｈａｒｅｄＯｕｔ
を主張して、これにより、前述された遅れの後で、Ｓｈ
ａｒｅｄＩｎライン６１が真の（“１”の）状態になる
ように駆動される。 ｄ．アドレス７３を含むデータ・ブロックの現在のオー
ナであるキャッシュ８２ｄはＯｗｎｅｒＯｕｔを主張
し、ＯｗｎｅｒＩｎライン６２をハイ（“１”）に駆動
するようにされて、メモリ８６はそれを行うためのデー
タを供給することが禁止される。 ｅ．キャッシュ８２ｅはデータ・ブロックのそのコピー
に対するその状態ビットを、Ｓｈａｒｅｄ_82e ＝１，Ｏ
ｗｎｅｒ_82e ＝０としてマークする。 ｆ．次いで、データが共有されていることから、キャッ
シュ８２ｅはアドレス７３に対してＷｒｉｔｅＳｉｎｇ
ｌｅを実行する。 ｇ．キャッシュ８２ａ，キャッシュ８２ｂ，キャッシュ
８２ｃ，およびキャッシュ８２ｅはＳｈａｒｅｄＯｕｔ
を主張し、これによりＳｈａｒｅｄＩｎライン６１を駆
動して、ＷＳＲｐｌｙのヘッダーにおけるｒｅｐｌｙＳ
ｈａｒｅｄビットをして、真の（“１”の）状態にセッ
トさせる。 ｈ．アドレス７３を含んでいるデータ・ブロックの所有
権が、キャッシュ８２ｄからキャッシュ８２ｅにスイッ
チする（Ｏｗｎｅｒ_82d ＝０，Ｏｗｎｅｒ_82e ＝１）。
そうでないときには、データ・ブロックのキャッシュさ
れたコピーに対する共有および固有状態ビットは変更さ
れずに留まる。

【００８３】２． マルチレベル・システムにおけるデ
ータの両立性 ここで想起されるように、１個の２レベルのメモリ・シ
ステムは、“クラスタ”と呼ばれており、それぞれに第
２レベルのキャッシュ１９ａ−１９ｉを介してメイン・
バス（グローバル・バス）２６に接続されているよう
な、複数個の１レベルのメモリ・システム１４ａ−１４
ｉ（図１）からなるものである。これを換言すれば、各
クラスタに含まれている単一の第２レベルのキャッシュ
は、この第２レベルのキャッシュをクラスタ内の第１レ
ベルのキャッシュに接続させるプライベート・バスとと
もに、該クラスタをグローバル・バス２６に接続させる
ものである。このプライベートなクラスタに対するバス
は、電気的にも論理的にも、他のクラスタ・バスおよび
グローバル・バスから区別されるものである。メイン・
メモリ１３はグローバル・バス２６に接続されている。

【００８４】このようなメモリ・システムのクラスタ・
バスのレベルにおいては、第２レベルのキャッシュがメ
イン・メモリの機能的な属性を有している。これに対し
て、グローバル・バスのレベルにおいては、該第２レベ
ルのキャッシュは、単一レベルのシステムにおけるキャ
ッシュと本質的に同じ態様の機能を果している。ここで
認められるように、バス・プロトコルおよびデータの両
立性のプロトコルの設計により、１レベルまたはマルチ
レベルのメモリ・システムとして動作しているかどうか
について、該第１レベルのキャッシュが見出すことを妨
げるような動作をするようにされる。これを換言すれ
ば、第１レベルのキャッシュがそれらの環境から受け入
れる応答は、双方の場合において同じである。このため
に、１レベルのメモリ・システムに対するデータの両立
性のプロトコルについての前述の説明は、マルチレベル
のシステムのクラスタの各々に対して当てはまるものと
して適切に説明されていることを注意すれば十分であ
る。

【００８５】マルチレベルのシステムに対するデータ両
立性のプロトコルの拡張では、より高いレベルのキャッ
シュ１９ａ−１９ｉが、いわゆる“ｅｘｉｓｔｓＢｅｌ
ｏｗ”ビットに加えて、第１レベルのキャッシュが保持
している全ての状態ビット（ｓｈａｒｅｄＳｔａｔｅ，
ｏｗｎｅｒＳｔａｔｅおよびｐｅｎｄｉｎｇＳｔａｔ
ｅ）を維持することが必要とされる。これをより詳細に
いえば、より高いレベルのキャッシュの各々は、キャッ
シュしている各データ・ブロックに対する１個のｅｘｉ
ｓｔｓＢｅｌｏｗビットを保持している。このｅｘｉｓ
ｔｓＢｅｌｏｗビットは、メモリ・ツリーの同じブラン
チにおける１個または複数個の次に低いレベルのキャッ
シュが該当の特定のデータ・ブロックを有しているとき
にのみ、より高いレベルのキャッシュ内の任意の所与の
データ・ブロックに対して真の（“１”の）状態にセッ
トする。このために、例えば図１の２レベルのシステム
においては、第２レベルのキャッシュ１９ａ−１９ｉが
グローバル・バス２６上に現れるパケットのフィルタ操
作が該ｅｘｉｓｔｓＢｅｌｏｗビットにより可能にされ
て、ある所与のクラスタ・バス１５ａ，・・・または１
５ｉ上にトラフィックを生成するグローバル・バスのト
ラフィックだけが、１個または複数個のクラスタ・バス
のクライエント・デバイスに関連するようにされる。こ
こで認められるように、このようなフィルタ操作をする
ことなく、グローバル・バス２６上の全てのトラフィッ
クが全てのクラスタ・バス１５ａ−１５ｉ上に現れ、こ
れにより、メモリ・システムの２レベルの組成について
の目的に勝るようにされる。

【００８６】クラスタ・バス上に現れるパケットがメイ
ン・バス（グローバル・バス）２６上のパケット・トラ
フィックとどのように関連しているのか、および、これ
とは逆のときにはどのように関連しているのかについて
の包括的な理解を付与するためには、キャッシュ１９ａ
のような第２レベルのキャッシュの一つの動作につい
て、ある程度詳細に考察することが有用である。

【００８７】第２レベルのキャッシュ１９ａがそのクラ
スタ・バス１５ａの上でリクエスタからのＲＢＲｑｓｔ
を受け入れたときには、該第２レベルのキャッシュ１９
ａは、ＲＢＲｑｓｔによって特定されるデータ・ブロッ
クのコピーを含むこともあり、含まないこともある。そ
れがコピーを有しているときには、リプライ・パケット
におけるｒｅｐｌｙＳｈａｒｅｄビットを次のように論
理的なＯＲにされたＳｈａｒｅｄＩｎの値に対してセッ
トした後で、該第２レベルのキャッシュはＲＢＲｐｌｙ
を介してリクエスタにデータを戻す。即ち、（ａ）ＲＢ
Ｒｑｓｔの結果として第１レベルのキャッシュから受け
入れられるＳｈａｒｅｄＯｕｔ信号、および、（ｂ）特
定されたデータ・ブロックに対するその共有ビットの現
在の値について、論理的にＯＲにされたＳｈａｒｅｄＩ
ｎの値に対してリプライ・パケットにおけるｒｅｐｌｙ
Ｓｈａｒｅｄビットをセットした後で、該第２レベルの
キャッシュはＲＢＲｐｌｙを介してリクエスタにデータ
を戻す（ここで想起されるように、単一レベルのシステ
ムにおいては、リクエスタからＲＢＲｑｓｔが受け入れ
られてからある固定的な時間後に、メイン・メモリ・コ
ントローラ２５がＳｈａｒｅｄＩｎライン６１上のＳｈ
ａｒｅｄＩｎ信号のレベルを評価して、リクエスタに対
して戻されるＲＢＲｐｌｙパケットに対するヘッダーの
ｒｅｐｌｙＳｈａｒｅｄビットに対して、当該評価され
た信号のレベルをコピーするようにされる）。

【００８８】これに対して、第２レベルのキャッシュ１
９ａがそのクラスタ・バスのリクエスタによって特定さ
れるデータ・ブロックのコピーを有していないときに
は、この第２レベルのキャッシュ１９ａはグローバル・
バス上にＲＢＲｑｓｔパケットを発生させる。このリク
エストに対するＲＢＲｐｌｙの戻りにより、該第２レベ
ルのキャッシュは新規なデータ・ブロックをもって自己
の更新を行い、この新規なデータ・ブロックに対するそ
の共有ビットの値を算出するためにそのＲＢＲｑｓｔに
対するそのｐｅｎｄｉｎｇＳｔａｔｅを使用し、そし
て、クラスタ・バス１５ａ上にＲＢＲｐｌｙを生成させ
ることによる応答をする。

【００８９】キャッシュ１９ａのような第２レベルのキ
ャッシュがそのクラスタ・バス上でリクエスタからのＷ
ＳＲｑｓｔを受け入れたときには、該ＷＳＲｑｓｔによ
って特定されたアドレスを含むデータ・ブロックに対す
るその共有ビットがセットされているかどうかを定める
ために、該キャッシュ１９ａでチェックされる。当該特
定のデータ・ブロックに対する共有ビットがセットされ
ていないときには、該第２レベルのキャッシュ１９ａは
ＷＳＲｑｓｔデータに従ってデータの更新を行い、この
更新されたデータに対するその固有ビットのセットを
し、そして、そのクラスタ・バスを介して（適切な時点
において、ＳｈａｒｅｄＩｎライン６１の値におけるｒ
ｅｐｌｙＳｈａｒｅｄビットをもって）ＷＳＲｐｌｙを
生成させる。これに対して、第２レベルのキャッシュ１
９ａが真の状態（“１”）に対してセットされたＷＳＲ
ｑｓｔに従うデータ・ブロックに対するその共有ビット
を有しているときには、グローバル・バス２６上にＷＳ
Ｒｑｓｔを生成させることにより、クラスタ・レベルの
リクエスタのＷＳＲｑｓｔを伝播させる。メイン・メモ
リ・コントローラ２５は、ある所定の時間遅れの後に、
ＷＳＲｐｌｙを付与することによってこのグローバル・
レベルのリクエストに応答する。このリプライが受け入
れられたときには、該第２レベルのキャッシュ１９ａは
ＷＳＲｑｓｔによって付与されたデータのＷＳＲｐｌｙ
の反映に従ってデータ・ブロックのそのコピーを更新
し、該データ・ブロックのそのコピーに対するその固有
ビットをセットし、そして、そのクラスタ・バス上に
（グローバル・バス２６を介して受け入れられたＷＳＲ
ｐｌｙにおけるｒｅｐｌｙＳｈａｒｅｄビットの値、お
よび、クラスタ・バス上の当初のＷＳＲｑｓｔに対応す
るＳｈａｒｅｄＩｎライン６１の値の論理的なＯＲに対
するこのクラスタ・レベルのＷＳＲｐｌｙのセットのヘ
ッダー・サイクルにおけるｒｅｐｌｙＳｈａｒｅｄビッ
トをもって）ＷＳＲｐｌｙを生成させる。

【００９０】各第２レベルのキャッシュは、グローバル
・バス２６上のＲＢＲｑｓｔパケットをモニタして、ア
ドレスの合致がなされているＲＢＲｑｓｔの同定をす
る。このようなアドレスの合致が生じたときには、キャ
ッシュ１９ａのような第２レベルのキャッシュは、特定
されたデータ・ブロックのそのコピーに対する固有ビッ
トおよびｅｘｉｓｔｓＢｅｌｏｗビットのチェックをす
る。当該特定のデータ・ブロックに対するその固有ビッ
トがセットされているときには、該キャッシュ１９ａは
データについて応答するけれども、ＲＢＲｐｌｙパケッ
トがアセンブルされる態様は、そのｅｘｉｓｔｓＢｅｌ
ｏｗビットもセットされているか否かに依存することに
なる。これをより詳細にいえば、該ｅｘｉｓｔｓＢｅｌ
ｏｗビットがセットされているときには、キャッシュ１
９ａは初めにそのクラスタ・バス１９ａ上でＲＢＲｑｓ
ｔを生成させて、特定されたデータ・ブロックの第１レ
ベルのキャッシュ・オーナから、グローバル・レベルの
ＲＢＲｑｓｔによって呼ばれるデータを検索するように
される。しかしながら、該特定されたデータ・ブロック
のキャッシュ１９ａによるコピーに対するｅｘｉｓｔｓ
Ｂｅｌｏｗビットがセットされていないときには、キャ
ッシュ１９ａにはそのコピーが現在のものであるとして
含まれていることから、グローバル・レベルでのリクエ
スタのＲＢＲｑｓｔを伝播させることなく、グローバル
・レベルでのＲＢＲｐｌｙに応答するようにされる。

【００９１】キャッシュ１９ａのような第２レベルのキ
ャッシュが、グローバル・バス２６上のＷＳＲｑｓｔに
おいて特定されたアドレスに合致しているときには、通
常のようにＳｈａｒｅｄＯｕｔが主張されるけれども、
他の動作をすることはない。しかしながら、キャッシュ
１９ａがグローバル・バス２６上のＷＳＲｐｌｙにおい
て特定されたアドレス上で合致しているときには、該当
のアドレスにおけるデータのそのコピーが更新される。
これに加えて、ＷＳＲｐｌｙによって特定されたアドレ
スを含むデータ・ブロックのそのコピーに対するｅｘｉ
ｓｔｓＢｅｌｏｗビットがセットされることが起きたと
きには、キャッシュ１９ａもそのクラスタ・バス１５ａ
上でＷＳＲｐｌｙを生成させる。ここで注目すべきこと
は、このＷＳＲｐｌｙパケットはクラスタ・バス上の対
応するＷＳＲｑｓｔパケットによって先行されるもので
はなく、バス上でのリクエスト・パケットの数とリプラ
イ・パケットの数とが等しくないのは別の理由によると
いうことである。

【００９２】ある第２レベルのキャッシュがそのクラス
タ・バスからＦＢＲｑｓｔを取得したときには、リクエ
ストがアドレスされるデータ・ブロックのそのコピーが
更新され、ＦＢＲｐｌｙが伝送されて、それぞれにリク
エスタに対して戻されるだけである。ＦｌｕｓｈＢｌｏ
ｃｋに対するレスポンダは、常に該レスポンダに対する
実際のまたは明白なメイン・メモリであるから、第２レ
ベルのキャッシュではグローバル・バス上の全てのＦＢ
Ｒｑｓｔが無視される。

【００９３】ここで想起されるように、ＷｒｉｔｅＢｌ
ｏｃｋトランザクションは、データを物理的なアドレス
空間に入力するために、２次的なデータ・プロデューサ
（メモリ・システムの外部にあるデータ源）による使用
のために有効なものである。該当の目的のために、この
トランザクションによれば、メイン・メモリに対して、
および、ＷＢＲｑｓｔにおいて特定されたアドレス上で
合致する任意のキャッシュに対して、サイクリックに順
序付けられたデータ・ブロックの書き込みがなされる。
マルチレベル・システムにおいては、ＷｒｉｔｅＢｌｏ
ｃｋトランザクションは、グローバル・バス・トランザ
クションとしての使用のために限定されることができ
る。該当のイベントにおいて、ＷＢＲｑｓｔはグローバ
ル・バス２６とインタフェースされているデバイスによ
ってのみ生成される。そして、全てのＷＢＲｑｓｔはメ
イン・メモリ１３によって供給される（ＷｒｉｔｅＢｌ
ｏｃｋについてのこの限定された適用に対するＷＢＲｐ
ｌｙには、不確定のサイクルによって追従される標準的
なリプライのヘッダー・サイクルが含まれている）。代
替的に、このＷｒｉｔｅＢｌｏｃｋトランザクション
は、より低いレベルのキャッシュがそれを呼ぶことが許
容されるように再規定することができる。そうであると
きには、より低いレベルのローカル・キャッシュのいず
れかによって生成されたＷＢＲｑｓｔは第２レベルのキ
ャッシュに渡され、これに次いで、該ＷＢＲｑｓｔをグ
ローバル・バス２６上に配置するようにされる。ＷＢＲ
ｐｌｙを受け入れると書き込みが実行される。

【００９４】ここで認められるように、この実施例で必
要とされることは、第２レベルのキャッシュの各々に
は、それらの下部でキャッシュされていた全てのデータ
・ブロックのコピーが維持されるということである。該
当の目的のために、該第２レベルのキャッシュ１９ａ−
１９ｉは、それぞれに、それらのそれぞれのクラスタ・
バス上で第１レベルのキャッシュの記憶容量の和に少な
くとも等しいデータの記憶容量を有するように選択され
る。更に、第２レベルのキャッシュ１９ａ−１９ｉは、
それぞれに、それらのそれぞれのクラスタ・バス上で第
１レベルのキャッシュの連想性の和に少なくとも等しい
連想性の程度を有するように選択される。例えば、ある
１個のクラスタに４個の第レベルの直接にマッピングさ
れたキャッシュ（即ち、１の程度の連想性を有するキャ
ッシュ）が含まれているとすると、該当のクラスタに対
する第２レベルのキャッシュは、そのクラスタ・バス上
で現れ得る任意のデータ・ブロックのアドレス上で確実
に合致できるように、少なくとも４の程度の連想性を有
するように選択される。

【００９５】ＩＩ．増強された実施例 この発明のメモリ・システムは容易に拡張できるもので
あり、また、簡単に増強されるものであるから、修正お
よび改善のためのその可能性を例示するために、ある所
定の拡張および増強についての説明をする。その初めの
実施例の説明の構成をするために上記で使用されたと同
じ一般論的なアウトラインが追従されて、この増強され
た実施例に独特の特徴が属する事項を同定するようにさ
れる。

【００９６】Ａ． システム・アーキテクチュア 所望であるときには、多重のバスは並列に動作するよう
にインターリーブさせることが可能であり（図示されな
い）、これによって、必要とされるバス・ワイヤの本数
に比例して増大する危険性を招きながら、使用可能なバ
スのバンド幅を増大するようにされる。例えば、ある１
個の実施においては、ある所与のパケットが伝送される
インターリーブしたバスを同定するために使用されるべ
きリクエスト・パケットおよびリプライ・パケット（そ
れぞれに図１３および図１４を参照）に対するヘッダー
のアドレス・フィールドにおけるビット８および９が許
容される。このために、該当の実施においては、バス・
アーキテクチュアについての１−ウエイ、２−ウエイお
よび４−ウエイのインターリーブが許容される。

【００９７】Ｂ． デバイス・バス・インタフェース 図１５に示されているように、増強された実施例のため
の標準的なデバイス・バス・インタフェース１０１に
は、幾つかの注目すべき修正が取り込まれている。その
差異のあるものは種々の信号を同定するために使用され
る術語に関連しているが、他のものは相当に重要なこと
である。インタフェース１０１の内部ロジックは図１６
に例示されている。図１６に示されているドライバ１０
４−１０９およびレシーバ１１１−１１７は、典型的に
はオープン・ドレインのＣＭＯＳデバイスであって、前
述のＧｕｎｎｉｎｇの出願である出願番号第０７／５０
２，３７２号の教示を維持しているものである。

【００９８】１． 信号 インタフェース１０１および図６のインタフェース４１
の信号ポート間に存在する実質的な区別については、こ
のセクションの以下のヘッディングの下にある程度詳細
に開示される。

【００９９】２． 裁定インタフェース ここで想起されるように、この発明によるメモリ・シス
テムの各バスは、全ての競合しているバス・クライエン
トは彼らのホスト・バスに対する公平で限界のあるタイ
ム・アクセスを確実にし、また、バス上でのパケットの
渋滞を回避するフロー・コントロールを実施するための
裁定手段を備えている。上記で指摘されたように、１個
または複数個のバスがパケットで切り換えられることか
ら、パケットの渋滞は一つの結末をなすものであり、こ
れの意味することは、それらのサービスが可能になるよ
りも早く、バス・クライエントがトランザクション・リ
クエストを累積できることである。

【０１００】この増強された実施例においては、各クラ
イエント・デバイスは、３本のリクエスト・ワイヤ Ｒ
ｅｑ Ｌ［２．．０］および３本の許可タイプ・ワイヤ
Ｇｎｔ−Ｔｙｐｅ Ｌ［２．．０］を有する裁定ポート
を介して、そのバスのための裁定手段と相互作用をす
る。これに加えて、該裁定手段に接続されている全ての
クライエントによって共有される単一のＧｎｔ Ｌワイヤ
がある。

【０１０１】ある１個のバス・クライエントは、１クロ
ック・サイクルまたは２個の連続するサイクルの間、そ
のＲｅｑ Ｌワイヤを用いて、そのバスのための裁定手
段に対してその裁定リクエストの通信をする。その第１
のサイクルにおいては、該クライエントはそのリクエス
トの優先権についての通信をする。これに加えて、正常
な裁定リクエストのためには、クライエントはそのＲｅ
ｑ Ｌワイヤの１本の上で第２のサイクルを用いて、バ
スがリクエストされているパケット長について裁定手段
に告知するようにされる。典型的には、これらの裁定リ
クエストの２個のサイクルに対するコード化は次の通り
である。 第１サイクル ７：裁定停止（Ｓｔｏｐ Ａｒｂｉｔｒａｔｉｏｎ） ６：リプライ・ハイ（Ｒｅｐｌｙ Ｈｉｇｈ） ５：ポーズ（Ｐａｕｓｅ） ４：リプライ・ロー（Ｒｅｐｌｙ Ｌｏｗ） ３：ホールド（Ｈｏｌｄ） ２：リクエスト・ハイ（Ｒｅｑｕｅｓｔ Ｈｉｇｈ） １：リクエスト・ロー（Ｒｅｑｕｅｓｔ Ｌｏｗ） ０：ノー・リクエスト（Ｎｏ Ｒｅｑｕｅｓｔ） 第２サイクル Ｌ：パケット長（０＝＞２サイクル，１＝＞９サイク
ル）

【０１０２】４個の優先権であるＲｅｑｕｅｓｔ Ｌｏ
ｗ，Ｒｅｑｕｅｓｔ Ｈｉｇｈ，Ｒｅｐｌｙ Ｌｏｗ，
およびＲｅｐｌｙ Ｈｉｇｈ は、バスに対する“正常
な”裁定リクエストに対応している。これを換言すれ
ば、それらが使用されるのは、裁定リクエストを登録し
ているデバイスが実際にパケットを伝送しようとすると
きである。Ｒｅｐｌｙ Ｈｉｇｈはキャッシュのリプラ
イだけに用いられる；Ｒｅｐｌｙ Ｌｏｗはメモリのリ
プライだけに用いられる；そして、Ｒｅｑｕｅｓｔ Ｈ
ｉｇｈはプロセッサおよびＩＯキャッシュのような大方
のリクエスタに対するものである。Ｒｅｑｕｅｓｔ Ｌ
ｏｗは、裁定手段からの許可を得るために長い遅れが裁
定的に黙認される“バックグラウンド”デバイスによっ
てのみ用いられるものである。再びこの実施例において
は、ある１個のクライエントは多くの裁定リクエストを
続けて発することができるが、この場合に、ある１個の
分離したリクエストはリクエスト・サイクルの各ペアに
対して登録される。更に、クライエントは、裁定手段が
ある所与のクライエントの側にたって登録できる裁定リ
クエストの個数だけ、該裁定手段によって課される実施
限界を彼らが超えていないことを確実にするという責任
がある。上述された裁定のルールを維持しながら、より
高い優先度の裁定リクエストが、より低い優先度のリク
エストに先だってサービスされる。そして、同じ優先度
のレベル内にある裁定リクエストは、ほぼラウンド・ロ
ビン式の順序でサービスされることになる。

【０１０３】（ＮｏＲｅｑｕｅｓｔ，Ｈｏｌｄ，Ｐａｕ
ｓｅおよびＳｔｏｐのような）この実施例によって支持
される他の裁定の優先権は、クライエントが彼らのホス
ト・バスに対する裁定手段からの特別なサービスをリク
エストすることが許容されるように利用可能なものであ
る。これらの特別な裁定リクエストは、裁定の優先度を
特定する１サイクルのリクエストだけ裁定手段に対して
通信される。裁定手段からのサービスは何もリクエスト
されないときには、バス・クライエントはＮｏＲｅｑｕ
ｅｓｔを使用する。Ｈｏｌｄは、リクエスト・パケット
に対するいかなるリクエストでも裁定手段が許容しない
ように所望するクライエントによって使用される（Ｈｏ
ｌｄを下回る優先度）。このために、Ｈｏｌｄは、その
目的および機能において、先に説明された実施例で採用
された裁定リクエストについて、“システム・ワイドの
保持を要求すること”および“システム・ワイドの保持
に対する要求を解除すること”のコード化をすることと
類似している。しかしながら、この実施例においては、
クライエントがＨｏｌｄコードを主張するサイクルだけ
にわたって、裁定手段はＨｏｌｄ状態に留まる。Ｐａｕ
ｓｅはこの発明に対しては固有のコード化をすることで
ある。キャッシュによって主張できることは、メモリに
よって発生されるリプライが殺到するのを回避すること
である。最後に、Ｓｔｏｐは、デバイスが全ての裁定を
停止させようと所望するときに用いられる。これによ
り、裁定手段をして、任意の裁定手段がＳｔｏｐコード
を主張するだけのサイクルにわたってバスの許可を停止
させる。このために、ここで理解されることは、Ｓｔｏ
ｐコードは、初めの実施例において考えられたＳＳｔｏ
ｐ信号と機能的に類似であるということである。

【０１０４】Ｇｎｔ ＬおよびＧｎｔＴｙｐｅ Ｌは、
次のバス・マスターになるように裁定手段によって選択
されていることをクライエントに対して告知するため
に、裁定手段によって用いられるものである。この信号
は１サイクルだけ主張されるものであり、一連の後続の
サイクルにわたって、選択されたバス・クライエントに
バス・マスターシップを付与するものである。ここで、
ＧｎｔＴｙｐｅ Ｌは許可が与えられている裁定リクエ
ストの優先度を指示している。このような目的のため
に、ＧｎｔＴｙｐｅ Ｌは次のように好適にコード化さ
れる。 ７：裁定停止（Ｓｔｏｐ Ａｒｂｉｔｒａｔｉｏｎ） ６：リプライ・ハイの許可（Ｇｒａｎｔ Ｒｅｐｌｙ
Ｈｉｇｈ） ５：保留（Ｒｅｓｅｒｖｅｄ）（使用されない） ４：リプライ・ローの許可（Ｇｒａｎｔ Ｒｅｐｌｙ
Ｌｏｗ） ３：保留（Ｒｅｓｅｒｖｅｄ）（使用されない） ２：リクエスト・ハイの許可（Ｇｒａｎｔ Ｒｅｑｕｅ
ｓｔ Ｈｉｇｈ） １：リクエスト・ローの許可（Ｇｒａｎｔ Ｒｅｑｕｅ
ｓｔ Ｌｏｗ） ０：許可ナシ（Ｎｏ Ｇｒａｎｔ）

【０１０５】Ｇｎｔ Ｌが主張されており、該当のクラ
イエントに対するＧｎｔＴｙｐｅ Ｌ がゼロではないと
きにのみ、所与のクライエントはそのバスに対する裁定
手段からの有効な許可を有している。この実施例におい
て、ある所与のクライエント・デバイスに対するインタ
フェース１０１におけるサイクルｉ上でＧｎｔ Ｌおよ
びＧｎｔＴｙｐｅ Ｌが主張されているときには、クラ
イエントは、サイクルｉ＋２において、その出ていく単
方向または双方向のバス・セグメントを駆動することが
できる。図１７に示されているものは、裁定（５サイク
ルの裁定の潜在が仮定されている）およびパケットの伝
送の間の、裁定リクエスタのデバイス・バス・インタフ
ェース１０１における、より重要な裁定リクエストおよ
び許可信号についてのタイミングである。この図１７を
読むときには図１６にも留意すべきである。

【０１０６】上述された実施例におけるように、裁定手
段はフロー・コントロールを実施するための２個の異な
るメカニズムを有している。裁定の優先度は、これらの
フロー・コントロールのメカニズムの第１のものであ
る。ここで理解されるように、リクエスト・パケットお
よびリプライ・パケットの双方を発するクライエント・
デバイスは、リクエスト・パケットの伝送に対するそれ
らの裁定リクエストよりも、リプライ・パケットの伝送
に対するそれらの裁定リクエストに対して、より高い優
先度を常に指定している。渋滞の始まりに先だってデバ
イスが常にリプライの用意をしているときには、これは
渋滞の問題を除外するために十分なものであるが、全て
のデバイスにとってはこの要求を満たすことはできな
い。例えば、それらが受け入れ得るリクエスト・パケッ
トに対する到達レートにおいて応答するためには、メモ
リ・コントローラ２５（図１）のような、より遅いデバ
イスを予期することは実際的ではない。更に、このよう
なデバイスでオーバフローのリスクなしで累積できる入
力キューの長さは法外に長いものである。

【０１０７】このために、裁定手段は、Ｈｏｌｄおよび
Ｐａｕｓｅの裁定リクエストのコード化に対する上述の
応答を介して、第２のフロー・コントロールのメカニズ
ムを実施するようにされる。ここで認められるように、
ＨｏｌｄまたはＰａｕｓｅのリクエストに対する裁定手
段の応答は即座のものではないから、それらのＨｏｌｄ
またはＰａｕｓｅのリクエストがバスの裁定手段におい
て効力を生じる間に幾つかの入来するパケットの累積が
許容されるように、クライエント・デバイスはそれらの
入力キューにおいて十分な余裕を持たねばならない。し
かしながら、クライエント・デバイスのいずれかが極め
て頻繁にＨｏｌｄまたはＰａｕｓｅのリクエストをする
ときには、バスのスループットが無用な逆効果を生じる
ことから、バランスが衝撃を受けることがある。

【０１０８】３． データ／コントロール・インタフェ
ース インタフェース１０１のデータ・ポートおよびオプショ
ンの受け入れポート（図１５）は、その目的および機能
において、それぞれに、インタフェース４１の送出ポー
トおよび受け入れポート（図４）に類似している。しか
しながら、インタフェース４１のＨｅａｄｅｒＣｙｃｌ
ｅＩｎ信号およびＨｅａｄｅｒＣｙｃｌｅＯｕｔ信号
は、パケットのヘッダー・サイクルを同定するための逆
パリティ・シンドロームを採用するという立場から、こ
れらは除外されている。各バス上の全てのパケットの各
サイクルに対するバイト・レベルにおいて、パリティの
演算がこの増強された実施例でなされていることから、
これは実際的なことである。各バスでは、典型的に、６
４ビット幅の多重化したアドレス／データ・パスが設け
られているとすると、これの意味することは、全てのパ
ケットの各サイクルについて８個のパリティ・ビットが
あるということである。その結果として、データ・サイ
クルに対する正しい偶数パリティのコード化は、ヘッダ
ー・サイクルに対する正しい奇数パリティのコード化か
ら、８のハミング距離だけ離されることになるが、標準
的なエラー検出技術を用いてパリティ・エラーを検出す
ることの可能性について妥協することからは、パリティ
のこの異常な使用を防止するためには十分な離隔である
と信じられる。

【０１０９】インタフェース１０１の他の差別的な特徴
は、ＢｉｄＥＮ Ｌ信号がそのコントロール・ポートに
加えられて、該インタフェース１０１が単方向のバス・
セグメントまたは双方向のバス・セグメントに接続され
ているかどうかを肯定的に指示するようにされることで
ある。ＢｉｄＥＮ Ｌが主張されているとき、または真
（“１”）であるときには、ＤａｔａＰｏｒｔは双方向
モードで動作して、クライエント・デバイスと双方向の
バス・セグメントとの間で、双方向のパケット通信を支
持するようにされる。これに対して、ＢｉｄＥＮ Ｌが
主張されていないとき、または偽（“０”）であるとき
には、ＤａｔａＰｏｒｔは単方向の出力モードで動作
し、また、ＲｅｃｅｉｖｅＯｐｔｉｏｎＰｏｒｔは単方
向の入力モードで動作するようにされる。

【０１１０】４． 両立性ポート 図４に示されているインタフェース４１の両立性ポート
は、図１５のインタフェース１０１における直接的な対
応を備えてはいないが、ここで認められることは、両立
性の信号がインタフェース１０１の裁定ポートにマージ
されていることである。この表象的な（ｐｒｅｓｅｎｔ
ａｔｉｏｎａｌ）変更がなされているのは次の理由によ
る。即ち、（ａ）バス・クライエントからのＲｅｑＳｈ
ａｒｅｄ Ｌ 信号（ＳｈａｒｅｄＯｕｔ信号として先に
同定されたもの）の論理的なＯＲをとって、それらのク
ライエントに対してＧｒａｎｔＳｈａｒｅｄ Ｌ信号
（ＳｈａｒｅｄＩｎ信号として先に同定されたもの）を
供給するために、および、（ｂ）バス・クライエントか
らのＲｅｑＯｗｎｅｒ Ｌ信号（ＯｗｎｅｒＯｕｔ信号
として先に同定されたもの）の論理的なＯＲをとり、そ
れらに対してＧｒａｎｔＯｗｎｅｒ Ｌ信号（Ｏｗｎｅ
ｒＩｎ信号として先に同定されたもの）を供給するため
には、各バスに対する裁定手段が便利な位置にあること
が見出されたからである。実際に、ＲｅｑＳｈａｒｅｄ
Ｌ，ＧｒａｎｔＳｈａｒｅｄ Ｌ，ＲｅｑＯｗｎｅｒ
ＬおよびＳｈａｒｅｄＯｕｔ Ｌは、機能的には、そ
れぞれに、インタフェース４１のＳｈａｒｅｄＯｕｔ，
ＳｈａｒｅｄＩｎ，ＯｗｎｅｒＯｕｔおよびＯｗｎｅｒ
Ｉｎ信号と同等のものであるから、ＳｈａｒｅｄＯｕ
ｔ，ＳｈａｒｅｄＩｎ，ＯｗｎｅｒＯｕｔおよびＯｗｎ
ｅｒＩｎ なる名称は、拡張されたデータ両立性のプロ
トコルの記述を簡略化するために、以下のそれらの信号
を参照する際に用いられることになる。両立性信号をイ
ンタフェース１０１の裁定ポートにマージさせることの
付加的な利点は、出力信号に対してはインタフェース１
０１において、また、入力信号に対しては裁定手段にお
いて、単一ビット・パリティのコード化の使用を介する
ようにして、裁定および両立性の入力信号および出力信
号について組み合わされたパリティ・チェック操作を容
易にするものである。

【０１１１】Ｃ． トランザクション この実施例に対して規定されているトランザクションは
次の通りである。 トランザクション リクエスト コマンド リクエスト 名 ／リプライ コード化 ／リプライ 省略形 （リクエスト パケット長 ／リプライ） Noop/Error Noop/Error 00000(0/1) 1/1 サイクル WriteSingleInvalidate WSIRqst/WSIRply 00001(0/1) 2/2 サイクル NonCacheableReadBlock NCRBqst/NCRBRply 00010(0/1) 2/9 サイクル FlushBlock FBRqst/FBRply 00011(0/1) 9/2 サイクル （未定義） - 00100(0/1) - WriteSingleUpdate WSURqst/WSURply 00101(0/1) 2/2 サイクル ReadBlock RBRqst/RBRply 00110(0/1) 2/9 サイクル WriteBlock WBRqst/WBRply 00111(0/1) 9/9 サイクル IOReadSingle IORSRqst/IORSRply 01000(0/1) 2/2 サイクル IOWriteSingle IOWSRqst/IOWSRply 01001(0/1) 2/2 サイクル IOReadBlock IORBRqst/IORBRply 01010(0/1) 2/9 サイクル IOWriteBlock IOWBRqst/IOWBRply 01011(0/1) 9/2 サイクル （未定義） - 01100(0/1) - Lock LRqst/LRply 01101(0/1) 2/2 サイクル DemapInitiate DmIRqst/DmIRply 01110(0/1) 2/2 サイクル Interrupt Int/- 01111(0/1) 2/- サイクル （未定義） - 10000(0/1) - SwapSingleInvalidate SSIRqst/SSIRply 10001(0/1) 2/2 サイクル （未定義） - 10010(0/1) - KillBlock KBRqst/KBRply 10011(0/1) 2/2 サイクル （未定義） - 10100(0/1) - SwapSingleUpdate SSURqst/SSURply 10101(0/1) 2/2 サイクル （未定義） - 10110(0/1) - （未定義） - 10111(0/1) - （未定義） - 11000(0/1) - IOSwapSingle IOSSRqst/IOSSRply 11001(0/1) 2/2 サイクル （未定義） - 11010(0/1) - （未定義） - 11011(0/1) - （未定義） - 11100(0/1) - UnLock URqst/URply 11101(0/1) 2/2 サイクル DemapTerminate DmTRqst/DmTRply 11110(0/1) 2/2 サイクル （未定義） - 11111(0/1) -

【０１１２】再び、全てのリクエスト・パケットおよび
リプライ・パケットの第１のサイクルはヘッダー・サイ
クルである。図１３に戻って認められることは、この実
施例におけるリクエスト・パケットに対するヘッダー・
サイクルのフォーマットが、４２ビット幅のアドレス・
フィールドとともに、６ビット幅のコマンド・フィール
ド（リクエスト／リプライのフラグ・ビットを含んでい
る）を有するようにされていて、規定されている増大し
た個数のトランザクションのコード化に対して十分な能
力を備えていることである。アドレス・フィールドのよ
り上位の２ビットは、実施されている種々の“単一の”
（ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ，Ｉ／ＯＲｅａ
ｄＳｉｎｇｌｅ，等の）トランザクションに対してアド
レスされた“単一のもの”のサイズ（ＳＳｉｚｅ）を特
定するために採用されており、また、このフィールドの
下位の４０ビットはＩ／Ｏアドレス空間またはメモリ・
アドレス空間（即ち、物理的なアドレス空間）のいずれ
かにおけるバイト・アドレスを特定するために有用なも
のである。一つの実施においては、これらのバイト・ア
ドレス・ビットの中の３６個だけが採用されており、残
りの４ビット（例えば、該バイト・アドレスの上位４ビ
ット）は、将来のアドレス拡張のために保留されている
（保留または不使用のアドレス・ビットに対してとられ
る対策については上記の説明を参照）。

【０１１３】図１３におけるリクエスト・パケットのヘ
ッダー・サイクルに付加的に含まれているＰＬｅｎビッ
トは、該パケットが（９サイクルの）長パケットである
か、または、（２サイクルの）短パケットであるかの信
号を出すためのものである。このコード化はヘッダーの
コマンド・フィールドで搬送されるコマンドについては
冗長性があるけれども、ある所定の事例では長パケット
に関連しており、他の事例では短パケットに関連するよ
うな、まだ規定されていないコマンドの適当なコード化
を許容するようにされる。更に、キャッシュ・リクエス
タによって任意の所与のデータ・ブロック上に維持され
るオーナ・ビットをコントロールするための Ｏｗビッ
トがあり、該所与のデータ・ブロックの値または共有状
態に影響し得るトランザクションを開始するようにされ
る。該当のカテゴリに入るこの実施例のトランザクショ
ンは、ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ，Ｗｒｉｔ
ｅＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎ
ｇｌｅＵｐｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＩｎｖａｌ
ｉｄａｔｅおよびＲｅａｄＢｌｏｃｋである。それらの
トランザクションに対するリクエスト・パケットのヘッ
ダーにおけるＯｗビットの状態により、該トランザクシ
ョンが関係するデータ・ブロックの所有権を受け入れる
ために、リクエスタに用意があるかどうかの指示がなさ
れる。他の全てのトランザクションに対しては、このＯ
ｗビットの値が偽りの（“０”の）状態にあるように維
持される。

【０１１４】この実施例におけるリクエスト・パケット
のヘッダーには８ビット幅のＤｅｖｉｃｅＩＤフィール
ドおよび４ビット幅のＳｕｂＩＤフィールドも含まれて
いるが、これらは、その目的および機能において、上記
された実施例のヘッダーによって搬送されるＤｅｖｉｃ
ｅＩＤと類似している（この例においては、ＳｕｂＩＤ
は、多くの未解決のリクエストに対するリプライの曖昧
さをなくすことを、バスのクライエント・デバイスで可
能にするために採用できるものであり、また、ＳｕｂＩ
Ｄフィールドは、リクエスタの状態を内部的に記憶させ
ることを回避するために、トランザクションのリクエス
タに対する内部的な状態またはｐｅｎｄｉｎｇＳｔａｔ
ｅをコード化するために採用できるものである）（両立
性プロトコルについての検討を参照）。図１３における
ヘッダーに付加的に含まれているエラー・ビット（Ｅｒ
ｒ）および不使用ビットの双方は、リクエスト・ヘッダ
ーにおいて偽の（“０”の）状態に維持される（Ｅｒｒ
ビットはリプライ・ヘッダーにおいてのみ意味があるも
のである）。

【０１１５】図１４と図１３との比較により、リプライ
・パケットに対するヘッダー・サイクルが対応のリクエ
スト・パケットに対してビット対ビットで同等であるこ
とが確かめられる。ただし、コマンド・フィールドのリ
クエスト／リプライ・ビットは該パケットをリプライと
して同定するように反転される；リプライ・パケットの
長さ（即ち、長または短）は ＰＬｅｎ ビットによっ
てコード化される；Ｅｒｒビットは、リプライのアセン
ブルをしているときにレスポンダがエラーに遭遇したか
否かに依存して、真の（“１”の）状態にセットされる
か、または、偽りの（“０”の）状態に維持される；Ｏ
ｗビットの状態が採用されて、トランザクションが関係
しているデータ・ブロックの所有権を獲得するためにリ
クエスタが許容されているか否かの指示をするようにさ
れる；そして、リクエスト・ヘッダーの不使用ビットが
共有（Ｓｈ）ビットとして採用されて、対応のリクエス
トがアドレスされたデータが、リクエスト・パケットを
受け入れた時点において共有されているか否かの信号を
するようにされる（このように共有されたデータについ
ての、より緻密な説明は上記で現れている）。

【０１１６】１． メモリ関連トランザクション この実施例のために備えられているメモリ・アクセス・
トランザクションは、ＲｅａｄＢｌｏｃｋ，ＮｏｎＣａ
ｃｈｅａｂｌｅＲｅａｄＢｌｏｃｋ，ＦｌｕｓｈＢｌｏ
ｃｋ，ＷｒｉｔｅＢｌｏｃｋ，ＷｒｉｔｅＳｉｎｇｌｅ
Ｕｐｄａｔｅ，ＷｒｉｔｅＳｉｎｇｌｅＩｎｖａｌｉｄ
ａｔｅ，ＳｗａｐＳｉｎｇｌｅＵｐｄａｔｅ，Ｓｗａｐ
ＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅおよびＫｉｌｌＢｌ
ｏｃｋである。ＲｅａｄＢｌｏｃｋ，ＷｒｉｔｅＢｌｏ
ｃｋおよびＦｌｕｓｈＢｌｏｃｋトランザクションは、
多くの点において、第１の実施例において対応する同名
のトランザクションと同等のものであるが、この実施例
におけるこれらのトランザクションおよびその他の“ブ
ロックの”トランザクションでは８サイクルのデータ転
送ユニット（即ち、８バス・サイクルであって、その各
々には８個の連続バイトが含まれている）が用いられる
点で差異がある。更に、ＷｒｉｔｅＳｉｎｇｌｅＵｐｄ
ａｔｅトランザクションは、早期の実施例におけるＷｒ
ｉｔｅＳｉｎｇｌｅトランザクションと機能的に類似し
ているが、新規に規定されたＷｒｉｔｅＳｉｎｇｌｅＩ
ｎｖａｌｉｄａｔｅトランザクションとの区別のために
その名称が変更されている。同様にして、ＳｗａｐＳｉ
ｎｇｌｅＵｐｄａｔｅは、前述されたＣｏｎｄｉｔｉｏ
ｎａｌＷｒｉｔｅＳｉｎｇｌｅトランザクションを比較
的小幅に修正したトランザクションである（即ち、Ｓｗ
ａｐＳｉｎｇｌｅＵｐｄａｔｅは、Ｃｏｎｄｉｔｉｏｎ
ａｌＷｒｉｔｅＳｉｎｇｌｅで実行される細かい読み取
り−修正−書き込みよりは、細かい読み書きを実行する
ために用いられるものである。）。新規に規定されたＳ
ｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅトランザクシ
ョンとの区別をするために、それは“Ｕｐｄａｔｅ”な
トランザクションとして同定される。

【０１１７】ＷｒｉｔｅＳｉｎｇｌｅＩｎｖａｌｉｄａ
ｔｅおよびＳｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ
トランザクションは、それぞれに、ＷｒｉｔｅＳｉｎｇ
ｌｅＵｐｄａｔｅおよびＳｗａｐＳｉｎｇｌｅＵｐｄａ
ｔｅトランザクションに対する書き込み無効化のスタイ
ルの対応事項を備えるように規定されている。それらに
より、特定のデータ・ブロックのコピーをキャッシュ・
リクエスタで更新することが可能にされ、受け入れてい
るキャッシュがトランザクションのペンディングをする
データ・ブロックに対して無効化のリクエストがアドレ
スされない限り、同じデータ・ブロックのコピーを含ん
でいる任意の他のキャッシュはそのコピーを無効にする
ようにされている。ここで想起されるように、該当のデ
ータ・ブロックに対するＶａｌｉｄビットを偽の
（“０”の）状態にクリアするだけで、キャッシュはそ
のデータ・ブロックの任意のものを無効化し、または、
削除することができる。

【０１１８】この実施例において、メイン・メモリ１３
（図１）から読み取られた後で修正されたデータ・ブロ
ックの所有権は、必ずしも最後に書き込みをしたプロセ
ッサに対するキャッシュに属するものではない。代替的
に、データ・ブロックの所有権の転移は、ＷｒｉｔｅＳ
ｉｎｇｌｅＵｐｄａｔｅ，ＷｒｉｔｅＳｉｎｇｌｅＩｎ
ｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＵｐｄａｔ
ｅ，ＳｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅおよび
ＲｅａｄＢｌｏｃｋトランザクションに対するリクエス
ト・パケットおよびリプライ・パケットのヘッダー・サ
イクルにおけるＯｗビットの状態のコントロールによっ
てなされる。これを詳細にいえば、リクエスタを除く全
てのキャッシュであって、ＷＳＩＲｐｌｙ，ＷＳＵＲｐ
ｌｙ，ＳＳＩＲｐｌｙおよびＳＳＵＲｐｌｙと合致する
ものは、特定のデータ・ブロックに対するそれらのオー
ナ・ビットを偽の（“０”の）状態に無条件でクリアさ
せる。これに対して、リクエスタは、このようなリプラ
イを受け入れると、該リプライにおけるＯｗビットに依
存して、該当のデータ・ブロックに対するそのオーナ・
ビットを（“１”）にセット、または（“０”）にクリ
アする。リプライ・ヘッダーにおけるＯｗビットが真の
（“１”の）状態にセットされているときには、リクエ
スタは、該データ・ブロックに対するそのオーナ・ビッ
トを真の（“１”の）状態にセットする。しかしなが
ら、リプライ・ヘッダーにおけるＯｗビットが偽の
（“０”の）状態にクリアされているときには、対応の
リクエスト・パケット内のＯｗビットが偽の（“０”
の）状態にクリアされているために、または、ある他の
理由により、リプライを用意しながらレスポンダがＯｗ
ビットを偽の（“０”の）状態にクリアしたために、リ
クエスタは、トランザクションが関係するデータ・ブロ
ックに対するそのオーナ・ビットを偽の（“０”の）状
態にクリアする。ここで認められるように、メイン・メ
モリ１３（図１）は、物理的なアドレス空間における全
てのデータ・ブロックの欠陥のあるオーナである。従っ
て、ＷＳＩＲｑｓｔ，ＷＳＵＲｑｓｔ，ＳＳＩＲｑｓｔ
またはＳＳＵＲｑｓｔのヘッダーに偽の（“０”の）Ｏ
ｗビットが含まれているときには、メモリ１３は、通常
は、リクエストによって付与される新規なデータに従っ
て更新される。勿論、ＳＳＩＲｑｓｔまたはＳＳＵＲｑ
ｓｔを発するキャッシュが、これらのトランザクション
の読み取りフェーズを支持する際に、まだプロセッサに
対して古いデータを供給する責任があることから、リク
エスタは、そのリクエストに対するリプライを少なくと
も受け入れるまでは、該当のデータ値を留めておくよう
にされる。

【０１１９】ＯｗビットはＲｅａｄＢｌｏｃｋトランザ
クションにおいても用いられる。特に、関連のプロセッ
サによる書き込みに対するプレリュードとして、キャッ
シュ・リクエスタによって発せられるＲＢＲｑｓｔにお
いて、それは真の（“１”の）状態にセットされて、対
応のＲＢＲｑｓｔが受け入れられるときに、特定のデー
タ・ブロックに対するそのオーナ・ビットを真の
（“１”の）状態にセットすることを、リクエスタが所
望していることが告知される。このために、ここで理解
されることは、ＲＢＲｑｓｔのヘッダーにおけるＯｗビ
ットにより、リクエスタに対する特定のデータ・ブロッ
クの所有権の加速された転移が許容されることになる。

【０１２０】この実施例に対するＲｅａｄＢｌｏｃｋト
ランザクションに特有の別の特徴は、ＲＢＲｐｌｙを可
能にするようにされた提案事項であって、リプライにつ
いての任意のデータ・サイクルにおいて、リクエスタに
対して戻されるべきデータをフェッチしている間にメモ
リ・エラーが生じたときには、該リクエスタにこれを告
知するようにされている。何等かのこのようなデータの
フェッチ・エラーが生じたことがレスポンダによって見
出されたときには、１個または複数個のエラーで影響を
受けるＲＢＲｐｌｙのデータ・サイクルの各々に対し
て、メモリ・フォールト（ＭｅｍＦａｕｌｔ）サイクル
が代用される。ＭｅｍＦａｕｌｔサイクルは独特のもの
として同定可能であるが、その理由は、（ａ）そのため
のパリティがヘッダー・サイクルの奇数パリティに対し
て反転されること、（ｂ）Ｎｏｏｐに対するコマンド・
コードが含まれていること、および、（ｃ）そのＤｅｖ
ｉｃｅＩＤおよびＳｕｂＤｅｖｉｃｅＩＤフィールドが
エンプティ（全て０）であることのためである。生じて
いるメモリ・エラーのタイプを同定するエラー・コード
は、このようなＭｅｍＦａｕｌｔサイクルの下位３２ビ
ットによって支承されている。このようなメモリのフォ
ールト・サイクルのメカニズムを付与する重要な利点
は、リクエストされたメモリの読み取り動作を実行しな
がら、レスポンダがＲＢＲｐｌｙを発することが許容さ
れることであるが、これの意味することはメモリの待ち
時間を減少できることである。

【０１２１】ＫｉｌｌＢｌｏｃｋは規定されている新規
なトランザクションであって、（メイン・メモリと同様
な）第２のまたはより高いレベルのキャッシュが、それ
らがブランチするより低いレベルのキャッシュから不使
用のデータ・ブロックを排除できるようにされる。例え
ば、しばらくの間図１に戻ると、キャッシュ１９ａはＫ
ｉｌｌＢｌｏｃｋを始動させて、クラスタ・バス１５ａ
上にある全てのキャッシュ１６ａａ−１６ａｊから特定
のデータ・ブロックの全てのコピーを除去させることが
できる。

【０１２２】これをより詳細にいえば、該ＫｉｌｌＢｌ
ｏｃｋトランザクションが重要であるという理由は、第
２のまたはより高いレベルのキャッシュにより実在のデ
ータ・ブロックを犠牲にすることが許容されて、該当の
データに対して指定されていた記憶位置が、その上位ま
たは高位レベルのバス（即ち、キャッシュ１９ａの場合
にはグローバル・バス２６）上でＲｅａｄＢｌｏｃｋを
実行することによってキャッシュが獲得する新規なデー
タを記憶させるために再指定できるようにされる。ここ
で想起されるように、それらのより下位レベルのバス
（例えば、バス１５ａ）上の任意のＲＢＲｑｓｔ上で
“ミス”にされたときには、これらのより高位レベルの
キャッシュはそれらのバス上でＲｅａｄＢｌｏｃｋを始
動させる。このために、ＫｉｌｌＢｌｏｃｋトランザク
ションの規定は、初めの実施例における第２のまたはよ
り高位レベルのキャッシュに対して課された、潜在的に
繁雑な“ａｓｓｏｃｉａｔｏｒ ｃｏｖｅｒａｇｅ（連
想範囲）”を回避するためのものである。ここでより詳
細に想起されることは、第２レベルのキャッシュ１９ａ
−１９ｉの各々を選択することにより、第１レベルのキ
ャッシュに対して連想範囲を付与することが可能にされ
て、（ａ）それらの下位に存在する第１レベルのキャッ
シュの容量の和に少なくとも等しい容量、および、
（ｂ）それらの第１レベルのキャッシュの連想性の和に
少なくとも等しい連想性の程度を持たせることである。
しかしながら、このＫｉｌｌＢｌｏｃｋトランザクショ
ンによれば、代替的でコストが潜在的に低い技術が付与
されて、第２レベルのキャッシュにより、それらの第１
レベルのチャイルド・キャッシュ（即ち、それらがブラ
ンチする第１レベルのキャッシュ）に対する完全な範囲
を与えることが確実にされる。

【０１２３】ＫｉｌｌＢｌｏｃｋを実行するために、よ
り高位レベルのキャッシュにより適当な犠牲アルゴリズ
ム（周知のいかなる犠牲アルゴリズムでも使用できる）
の使用を介して潜在的な犠牲としてのデータ・ブロック
が選択され、そして、該選択されたデータ・ブロックに
対するそのオーナ・ビットの状態がチェックされる。潜
在的な犠牲ブロックに対するそのオーナ・ビットが真の
（“１”の）状態にセットされると、ＫｉｌｌＢｌｏｃ
ｋの始動手段（ｉｎｉｔｉａｔｏｒ）により、その下位
レベルのバス（即ち、第２レベルのキャッシュ１９ａの
場合にはクラスタ・バス１５ａ）上にＲＢＲｑｓｔがま
ず発せられる。このＲＢＲｑｓｔは潜在的な犠牲にアド
レスされているから、対応のＲＢＲｐｌｙが受け入れら
れるときには、該ＫｉｌｌＢｌｏｃｋの始動手段により
潜在的な犠牲のそのコピーが更新される。所要であれば
更新の後で（ＫｉｌｌＢｌｏｃｋの始動手段が潜在的な
犠牲に対するそのオーナ・ビットを偽の（“０”の）状
態にクリアしたときには、更新の実行はされない）、こ
のＫｉｌｌＢｌｏｃｋの始動手段は、その下位レベルの
バスを用いて、該潜在的な犠牲に対してアドレスされる
ＫＢＲｐｌｙを発するようにされる。このＫＢＲｐｌｙ
上で合致する、より下位レベルのキャッシュ（例えば、
キャッシュ１２ａａ−１２ａｊ）の各々は、その上でペ
ンディングしているトランザクションがない限りは、特
定されたデータ・ブロックのそのコピーに対するそのＶ
ａｌｉｄビットをクリアするようにされる。このＫｉｌ
ｌＢｌｏｃｋの始動手段は、次いで、その下位レベルの
バス上にＫＢＲｑｓｔを発する。このＫＢＲｑｓｔは潜
在的な犠牲に対してアドレスされているから、ＫＲＢｑ
ｓｔが受け入れられ、そのＫＲＢｑｓｔに応答して、よ
り下位レベルのキャッシュの任意のものがＲｅｑＳｈａ
ｒｅｄ Ｌ（ＳｈａｒｅｄＯｕｔ）が決定されるときに
は、ＫｉｌｌＢｌｏｃｋの始動手段によってそのＧｒａ
ｎｔＳｈａｒｅｄ Ｌ入力信号（換言すれば、そのＳｈａ
ｒｅｄＩｎ信号）の状態がチェックされる。もしそうで
あるとすると、ＫｉｌｌＢｌｏｃｋの始動手段がリセッ
トされて、ある所定の将来の時点まで、選択されたデー
タ・ブロックを犠牲にすることが延期される。しかしな
がら、ＫＲＢｑｓｔの受け入れの際に、より下位レベル
のキャッシュのいずれもＲｅｑＳｈａｒｅｄ Ｌ（Ｓｈ
ａｒｅｄＯｕｔ）を主張しないときに、このＫｉｌｌＢ
ｌｏｃｋの始動手段で確認されることは、その下位レベ
ルのバス上の任意のキャッシュにおいて特定されたデー
タ・ブロックのコピーは存在せず、これに次いで、その
より高位レベルのバス上でＦｌｕｓｈＢｌｏｃｋが始動
して、データ・ブロックのそのコピーをメイン・メモリ
１３に書き戻すようにされる（または、次に高いレベル
のキャッシュに書き戻すようにされる）。

【０１２４】メモリ・システムの効率性を増大させるた
めに規定されている別のトランザクションは、ＮｏｎＣ
ａｃｈｅａｂｌｅＲｅａｄＢｌｏｃｋトランザクション
である。このトランザクションは、アドレスされている
データ・ブロックの共有／非共有状態が影響を受けない
ことを除き、前述されたＲｅａｄＢｌｏｃｋトランザク
ションと同等のものである。従って、その適用は、ＤＭ
ＡＩ／Ｏデバイスのような非キャッシュ式のリクエスタ
の側にたって、合致性のあるメモリ空間（即ち、物理的
なアドレス空間）からのデータ・ブロックの読み取りに
限定される。

【０１２５】２． Ｉ／Ｏ トランザクション Ｉ／Ｏデバイス間でのデータ・ブロックの読み取りおよ
び書き込み（それぞれに、ＩＯＲｅａｄＢｌｏｃｋおよ
びＩＯＷｒｉｔｅＢｌｏｃｋ）をするために、また、Ｉ
／Ｏデバイスに対してアトミックな読み／書き（ＩＯＳ
ｗａｐＳｉｎｇｌｅ）を実行するために、Ｉ／Ｏトラン
ザクションは付加的なトランザクションの支持を付与す
るように拡張されている。更に、第１実施例のＢＩＯＷ
ｒｉｔｅトランザクションは、次のＳｅｃｔｉｏｎにお
いて略述されるような、より特定のＩｎｔｅｒｒｕｐｔ
トランザクションを備えるために省略されている。

【０１２６】３． 他のトランザクション ＬｏｃｋおよびＵｎＬｏｃｋは、このカテゴリにおい
て、より関心のある拡張がなされる２個のトランザクシ
ョンである。Ｌｏｃｋはキャッシュ・リクエスタにより
呼ばれることができて、リクエスタを除く任意のクライ
エントにとって、特定されたデータ・ブロックに影響が
あり得るいずれのトランザクションでもその実行を防止
するようにされる（即ち、ＷｒｉｔｅＢｌｏｃｋ，Ｗｒ
ｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ，ＷｒｉｔｅＳｉｎｇ
ｌｅＩｎｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＩｎ
ｖａｌｉｄａｔｅまたはＫｉｌｌＢｌｏｃｋ）。従っ
て、ある所与のデータ・ブロックに課されるトランザク
ション上に、細かい順序付けの程度を課することが有用
である。また、リクエストされるデータ・ブロックに対
する書き込みの頻度のために、古いデータが戻されるＲ
ＢＲｑｓｔ上での無限回数の再試行をキャッシュで防止
することも有用である。全てのキャッシュ・クライエン
トによってロックされたデータ・ブロックのアドレス
（ＬｏｃｋＡｄｄｒｅｓｓ）を登録することにより、ま
た、リクエスタ以外の全てのキャッシュに対して真の
（“１”の）状態にセットされるフラグ・ビット（Ｌｏ
ｃｋＡｄｄｒｅｓｓＶａｌｉｄ）を備えることにより、
Ｌｏｃｋは好都合に呼ばれることになる。かくして、こ
の特徴のこのような実施により、１個だけのデータ・ブ
ロックが任意所与の時点においてロックされることが許
容される。ＵｎＬｏｃｋは、ある１個のＬｏｃｋのホル
ダーがそのＬｏｃｋをクリアするために呼ぶことができ
る、相対的なトランザクションである。キャッシュの各
々をして、特定されたデータ・ブロックに対するそのＬ
ｏｃｋＡｄｄｒｅｓｓＶａｌｉｄビットをクリアさせる
ことにより、その達成がなされる。

【０１２７】前述されたように、Ｉｎｔｅｒｒｕｐｔト
ランザクションも、プロセッサに対する割り込みの信号
を出力するために規定されたものである。プロセッサの
割り込みはこの発明の範囲を超えたものであるけれど
も、ここで注意されることは、このＩｎｔｅｒｒｕｐｔ
トランザクションは、ある特定のプロセッサを目標とす
るもの、または、システムにおける全てのプロセッサに
対する放送的なものである。

【０１２８】ＤｅｍａｐＩｎｉｔｉａｔｅは、上述され
たＤｅＭａｐトランザクションに類似のものである。し
かしながら、この事例においては、仮想的なアドレスか
ら物理的アドレスへの変換は、それぞれに、プロセッサ
１２ａａ−１２ｉｊ（図１）に対して設けられるトラン
ザクションのルック・アサイド・バッファ（図示されな
い）によって実行される。かくして、ＤｅＭａｐＴｅｒ
ｍｉｎａｔｅトランザクションが規定されていて、リク
エストされたＤｅＭａｐが完了したときに、プロセッサ
１２ａａ−１２ｉｊの各々により、その第１レベルのキ
ャッシュ１６ａａ−１６ｉｊをしてこのトランザクショ
ンを始動させることになる。プロセッサ１２ａａ−１２
ｉｊがｄｅｍａｐの動作を実行している間に、キャッシ
ュ１６ａａ−１６ｉｊがＲｅｑＳｈａｒｅｄ Ｌ（Ｓｈ
ａｒｅｄＯｕｔ）を主張して、ＤｍＩＲｐｌｙがそのＳ
ｈ（換言すれば、ｒｅｐｌｙＳｈａｒｅｄ）ビットを偽
の（“０”の）状態にクリアさせる合致が生じたとき
に、プロセッサ１２ａａ−１２ｉｊの全てがリクエスト
されたｄｅｍａｐを完了したという確認をＤｅＭａｐＩ
ｎｉｔｉａｔｅリクエスタが得るようにされる。

【０１２９】Ｆ．データの両立性 この発明のこの実施例のために規定されているＷｒｉｔ
ｅＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎ
ｇｌｅＩｎｖａｌｉｄａｔｅおよびＫｉｌｌＢｌｏｃｋ
トランザクションは、生起するデータ・ブロック共有の
量を減少させ、これによって、データ両立性のプロトコ
ルが、第１の実施例における純粋な更新プロトコルとい
うよりも、ハイブリッドな更新／無効化プロトコルとし
て振舞うようにされる。この変更がなされたのは、両立
性プロトコルの効率性を増大させるという目的のためで
ある。これらの新規なトランザクションのために、両立
性プロトコルの効率性において注目すべき改善があるか
どうかはまだ不確実ではあるけれども、この新規なトラ
ンザクションが両立性プロトコルの有用性または効率性
の逆効果とはならないことは明かである。

【０１３０】両立性のプロトコルに対してなされた別の
変更は、リクエスト・パケットおよびリプライ・パケッ
トのヘッダー・サイクルにおけるＯｗビットの使用に関
連している。上記で指摘されたように、両立性のあるメ
モリ空間内で実行される読み取りおよび書き込みに関連
するリクエスタおよびレスポンダに対してこのビットで
与えられることは、このような読み取りおよび書き込み
が指向されるデータ・ブロックの所有権の転移に対する
ある所定の付加的なコントロールである。しかしなが
ら、純粋な更新の両立性プロトコルまたはハイブリッド
な更新／無効化の両立性プロトコルのいずれの有効性ま
たは有用性に影響することはない。むしろ、特定のデー
タ・ブロックが“共有”されているか否か、および、
“固有”のものであるか否かについての追跡を維持する
ための、複写され、非同期に維持されているアドレス／
状態・タグに依存するアーキテクチュア（図示されな
い）を用いて、実施されているキャッシュに対する支持
が与えられる。状態の変更はこのようなキャッシュのタ
グからタグへと伝わるから、該キャッシュのプロセッサ
側からは共有されておらず、また、固有でもないように
みえる、局部的にキャッシュされているデータ・ブロッ
クに対してプロセッサが書き込みを発するときには、あ
る一つの競合条件を生じさせることができる。

【０１３１】このような競合条件が生じることを回避す
るために、偽の（“０”の）状態の共有ビットおよびオ
ーナ・ビットを有しているデータ・ブロックに指向され
る書き込みを関連のプロセッサが発したときには、キャ
ッシュに対してＷｒｉｔｅＳｉｎｇｌｅの始動を要求す
ることができるが、これではバス・トラフィックが増大
することになる。従って、このようなＷｒｉｔｅＳｉｎ
ｇｌｅの頻度を減少させるためにＯｗビットが含まれて
いる。特に、プロセッサが書き込みのペンディング状態
にあるデータ・ブロックのコピーを得るためにＲＢＲｑ
ｓｔを発するときには、そのＲＢＲｑｓｔのヘッダー・
サイクルにおけるＯｗビットをキャッシュによってセッ
トすることが可能となり、これによって、対応のＲＢＲ
ｐｌｙにおけるＯｗビットが真の（“１”の）状態にセ
ットされるようにリクエスタが要求していることがレス
ポンダに告知されることになる。

【図面の簡単な説明】

【図１】 この発明を有利に用いることができる、階層
性のキャッシュ・メモリ・システムを備えたメモリ共有
式のマルチプロセッサを示す簡略化したブロック図であ
る。

【図２】 図１に示されているマルチプロセッサのため
の、標準的なバス／クライエント・インタフェースにお
ける内部ロジックの簡略化した概略図である。

【図３】 この発明を用いるモノボード・コンピュータ
のためのパイプライン式メモリ・バスの概略図である。

【図４】 この発明のマルチボードによる実施例のため
のパイプライン式メモリ・バスの概略図である。

【図５】この発明のマルチボード、マルチモジュールに
よる実施例のためのパイプライン式メモリ・バスの概略
図である。

【図６】 図２に示されているバス／クライエント・イ
ンタフェースの種々の信号ポートを同定するための機能
図である。

【図７】 バス上のパケット送信との間で時間的にオー
バラップした関係にあるときの、前述されたタイプのメ
モリ・バスに対して裁定をするための裁定手段を示す機
能的なブロック図である。

【図８】 図４において示されているパイプライン式の
バスの裁定とその上でのパケットの送信との間の時間的
なオーバラップを例示するタイミング図である。

【図９】 この発明の初めの実施例のために選択された
フォーマットにおける、バス・トランザクションのため
のリクエスト・パケットにおけるヘッダー・サイクルを
ビット・レベルで示す図である。

【図１０】 対応のフォーマットにされたリプライ・パ
ケットにおけるヘッダー・サイクルをビット・レベルで
示す図である。

【図１１】 アドレスされた量のデータ・ブロックが転
送ユニットの第１のデータ・サイクル内に含まれるよう
に、バス上においてデータ・ブロックの転送ユニットに
ついてサイクリックな再順番付けの例示をするための図
である。

【図１２】 この発明の初め実施例のために備えられて
いる、データの両立性のプロトコルについての基本的な
原理を例示するために有用な、単一レベルのメモリ共有
マルチプロセッサの簡略化した概略図である。

【図１３】 この発明の増強された実施例によって実行
される、バス・トランザクションにおけるリクエスト・
パケットのためのヘッダー・サイクル・フォーマットを
ビット・レベルで示す図である。

【図１４】 この発明の増強された実施例によって実行
される、バス・トランザクションにおけるリプライ・パ
ケットのためのヘッダー・サイクル・フォーマットをビ
ット・レベルで示す図である。

【図１５】 この発明の増強された実施例に対する標準
的なデバイス−バス・インタフェースの種々の信号ポー
トを同定するための機能図である。

【図１６】 図１５に示されているデバイス−バス・イ
ンタフェースにおける内部ロジックの簡略化した概略図
である。

【図１７】 この発明の増強された実施例で依存され
る、２−サイクルの長いリクエスト・パケットおよびリ
プライ・パケットの裁定および送信のための、ある所定
の信号の相対的なタイミングを例示するタイミング図で
ある。

【符号の説明】

１１：マルチプロセッサ、１２ａａ−１２ｉｊ：プロセ
ッサ、１３：メイン・メモリ、１４ａ−１４ｉ：クラス
タ、１５ａ−１５ｉ：ローカル・バス、１６ａａ−１６
ｉｊ：キャッシュ・メモリ、１７ａ：マップキャッシ
ュ、１８ｉ：ＩＯブリッジ（裁定手段）、１９ａ−１９
ｉ：キャッシュ・メモリ、２０ａ−２０ｉ：ＲＡＭモジ
ュール、２１ａ−２１ｉ：コントローラ、２５：コント
ローラ、２６：グローバル・バス、２８ｉ，２９ｉ：コ
ントローラ、３０ｉ：ＬＡＮ、３１ｉ：ディスプレイ／
プリンタ・デバイス、３４：トランザクション・リクエ
スト・レジスタ、３５ａ−３５ｉ，３６：裁定手段、３
７：パイプライン・レジスタ、３８：裁定リクエスト・
ライン、３９：許容ライン、４０，４１：裁定手段、４
２：裁定ポート、４３：ポート、５１，５２：ワイヤ、
６０：キャッシュ、６１，６２：ライン

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジャン・エイ・ガスティネル アメリカ合衆国 カリフォルニア州 94043 マウンテンビュー スターライ トコート 47 (56)参考文献 特開 平２−211572（ＪＰ，Ａ) ＩＥＥＥ ＴＲＡＮＳＡＣＴＩＯＮ ＯＮ ＣＯＭＰＵＴＥＲＳ，Ｖｏｌ. 37，Ｎｏ．８（1988−８），ＰＰ．909 −920

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】１個のメイン・メモリ、複数個のプロセッ
   サ、複数個のＩ／Ｏデバイス、および、前記プロセッサ
   および前記Ｉ／Ｏデバイスに結合されたそれぞれのキャ
   ッシュ・メモリを備えているメモリ共有マルチプロセッ
   サにおいて、その改良が、 前記複数個のプロセッサの異なるプロセッサのコントロ
   ールの下に異なる時点において更新されるべきデータの
   少なくとも幾つかの多重コピーを生じさせるトランザク
   ションを含む所定組のメモリ・トランザクションの選択
   されたものに従って、コマンド、メモリ・アドレス、お
   よびそれらの間の前記データを転送するために前記メイ
   ン・メモリおよび前記キャッシュ・メモリに結合された
   パケット切り換え式バスを含んでおり、 前記トランザクションの各々は、不確定な時間遅れでリ
   プライ・パケットが追従するリクエスト・パケットから
   なり、これによって多重トランザクションのためのリク
   エスト・パケットおよびリプライ・パケットが前記バス
   上で時間的にインタリーブされることが可能とされ、 前記トランザクションは、前記プロセッサの全ておよび
   前記Ｉ／Ｏデバイスの全てが、前記多重コピーによって
   表される全てのデータを含んでいる前記キャッシュ・メ
   モリ内に記憶されている全てのデータに対する両立性が
   ある値に対するアクセスを有することを確実にする両立
   性プロトコルを実施するために選択されており、前記バスは、前記バス上の時間を一連のクロック・サイ
   クルに分割する実質的に一定クロック周波数で動作する
   同期式のバスであり、 前記選択されたトランザクションのそれぞれのリクエス
   ト・パケットおよびリプライ・パケットは、それぞれ前
   記バス上で時間が移動された組の連続したクロック・サ
   イクルを占有し、 前記トランザクションの或る異なったもののリクエスト
   ・パケットおよびリプライ・パケットは、前記バス上で
   異なったクロック・サイクル数を占めるものである メモ
   リ共有マルチプロセッサ。