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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 【０００１】この発明はコンピュータ・システムに対す
る同期的なパケット切り換え式のメモリ・バスに関する
ものであり、より詳細には、共有データの多重のキャッ
シュ・コピー間の両立性が必要とされる、特にメモリが
共有されたマルチプロセッサにおけるこのようなバスの
使用可能なバンド幅を増大させるためのバス・アーキテ
クチュアおよびプロトコルに関するものである。これを
更に詳細にいえば、この発明は、多重の階層化したメモ
リ・キャッシュを備えたメモリ共有マルチプロセッサを
含んでいるＶＬＳＩ（超大規模集積化）コンピュータ・
システムに対する、前述のタイプのスケーラブル・メモ
リ・バスに関するものである。 【０００２】コンピュータのメモリ・バスを設計すると
きの主要な目標は、それらの使用可能なバンド幅を最大
にすることにある。ショート・バスのサイクル・タイム
はこれを達成するために必要とされるものであるが、こ
れだけではバスの使用可能なバンド幅がその電気的なバ
ンド幅と確実に両立するようにはならない。その理由は
、該当の目標を達成するためには、バスも高い効率（通
常は、使用可能なバスのバンド幅に対するその電気的な
バンド幅の比率として規定される）を持たねばならない
からである。 【０００３】実際に、通常の回路で切り換えられるバス
の使用可能なバンド幅を増大させるためには、ショート
・バスのサイクル・タイムは比較的価値が低いものであ
るが、その理由は、該回路でのバスの切り換えにより、
トランザクション対トランザクションをベースとして、
連続的なトランザクションに対するリクエスト（要求）
／リプライ（応答）のペアが直列化されるからである。 知られているように、コンピュータ・システムがその実
行を要求されるメイン・メモリのトランザクションの数
および頻度を減少させるべくキャッシュ・メモリ・シス
テムを用いることができるけれども、高い実行能力のシ
ステムにおいては、通常は静止状態にあるメモリ・バス
上のトラフィックが実行能力の有力な制限ファクタであ
る。 【０００４】不都合なことに、経済的に実用可能なメイ
ン・メモリのアクセス・タイムが、典型的には、実現可
能なバスの最小のサイクル・タイムよりも数倍も長く、
このために、回路で切り換えられるバスの使用可能なバ
ンド幅がメイン・メモリのアクセス・タイムによって制
限され易くなる。キャッシュ・メモリを有するシステム
においては、回路で切り換えられるバスの無駄にされた
”ウエイト（待ち）”サイクル（即ち、その無駄にされ
たバンド幅）の減小は、メイン・メモリ／キャッシュ・
メモリのデータ・トランスポート・ユニットのサイズを
増大させることにより可能であって、これにより、より
大きいデータのブロックにわたるバスのウエイト・サイ
クルを償却するようにされる。しかしながら、このアプ
ローチによれば、１台または複数台のプロセッサによっ
てバス上に配置されるバンド幅ロードが増大する傾向が
生じて、より大きいデータ転送ユニットの利点が少なく
とも部分的に失われることになる。 【０００５】他の者が認識していることは、“パケット
によって切り換えられる”バス（ときには、“スプリッ
ト・サイクル”バスまたは“ペンディング”バスと呼ば
れることもある）を用いることにより、アイドル・バス
・サイクルに起因するバンド幅の不利益点が回避できる
ということである。バスのパケットでの切り換えにより
バスのトランザクションのリクエストおよびリプライが
互いに分離され、これによって、多重のトランザクショ
ンに対するリクエストおよびリプライがバス上でインタ
リーブすることが許容される。一般的なルールとして、
アイドル・バス・サイクルの回避は、メイン・メモリが
関係するトランザクション（即ち、“メイン・メモリ・
トランザクション”）のリクエストおよびリプライを分
離することによって簡単に可能にされる。しかしながら
、全てのバス・トランザクションのリクエストおよびリ
プライを分離することが有利であることは見出されてお
り、そのために、（実施方法によって異なる最小数のサ
イクルを超える）可変数のバス・サイクルが、任意のリ
クエストとそれに対応するリプライとの間に介在するこ
とができて、ある所定のタイムアウト周期内にリプライ
が受け入れられないリクエストの、可能性のある終了ま
たは不成功にのみ追従するようにされる。全てのリクエ
ストおよびリプライについてのこの本質的な完全な分離
によりバスのデッドロックの排除の助けがなされるが、
産業上の標準的なシステムを含んでいる、異なるまたは
“関連のない”コンピュータ・システムのメモリ・バス
のような、非同期式のデバイスと該バスとのインタフェ
ースがより容易になるようにされる。更に、インタリー
ブされたメイン・メモリ・モジュールの使用が容易にさ
れ、また、マルチレベルで階層性のキャッシュ・メモリ
・システムを有するマルチプロセッサに対するキャッシ
ュの両立性の問題に対する解決が簡単にされる。 【０００６】使用可能なバンド幅とキャッシュの両立性
とは、関連しているけれども分離可能な問題である。こ
こで理解されるようにキャッシュの両立性にはより詳細
な考慮がなされる。その理由は、マルチプロセッサにお
けるような異なるプロセッサのコントロールの下に、キ
ャッシュされたデータ・コピーの中の異なるものが更新
されることを許容しながら、共有データの多重にキャッ
シュされたコピーのアクセスをするバスに対して特別の
要求があるからである。 【０００７】回路で切り換えられるバスに対するキャッ
シュの両立性の問題については、幾つかの解決策が知ら
れている。例えば、ともに係属中であり譲渡されたＰａ
ｒａｄｅｅｐ　　Ｓ．Ｓｉｎｄｈｕ　　ｅｔ　　ａｌ．
の米国特許出願が参照される。この米国特許出願は、“
マルチプロセッサのためのマルチ・レベルのキャッシュ
・メモリ・ツリー”として、１９８６年１１月１２日に
、出願番号第９２９，５４４号をもって出願されたもの
（Ｄ／８６２８８）である。しかしながら、キャッシュ
の両立性を維持するためのこれら既知の技術は、パケッ
トで切り換えられるバスに対して直接的に適用できるも
のではない。なお、Ａｎｄｒｅｗ　　Ｗ．Ｗｉｌｓｏｎ
，Ｊｒ．，“Ｈｉｅｒａｒｃｈｉｃａｌ　　Ｃａｃｈｅ
／Ｂｕｓ　　Ａｒｃｈｉｔｅｃｔｕｒｅ　　ｆｏｒ　　
Ｓｈａｒｅｄ　　Ｍｅｍｏｒｙ　　ｍｕｌｔｉｐｒｏｃ
ｅｓｓｏｒｓ，”Ｃｏｍｐｕｔｅｒ　　Ａｒｃｈｉｔｅ
ｃｔｕｒｅＣｏｎｆｅｒｅｎｃｅ　　ＩＥＥＥ／ＡＣＭ
），１９８７，ｐｐ２４４−２５２を参照されたい。 【０００８】この発明においては、複数個のプロセッサ
、複数個のＩ／Ｏデバイス、複数個のキャッシュ・メモ
リおよび１個のメイン・メモリ間でのデータ転送のため
のパケットで切り換えられるバスを有する、メモリ共有
式のマルチプロセッサによってバス・プロトコルが採用
されている。そして、あらゆる時点において、全てのプ
ロセッサおよび全てのＩ／Ｏデバイスによる、全てのデ
ータに対する両立性のある値のアクセスを確実にしなが
ら、異なるプロセッサのコントロールの下に、データの
多重コピーを更新することが許容される。 【０００９】この発明の他の利点および特徴については
、添付の図面と関連させて以下の説明を参照することに
よって明かにされる。 【００１０】この発明の説明は、所定の例示された実施
例に関して相当程度詳細になされているけれども、この
発明はそれらの実施例に限定することを意図するもので
はないことが理解されるべきである。むしろ、その目的
とするところは、添記されている特許請求の範囲の欄に
よって規定されるように、この発明の全ての修正、変更
および均等物をカバーすることにある。 【００１１】ここで開示されるメモリ・システムには幾
つかの重要な特徴があるから、異なる特徴に関連して構
成体を配置する助けとなるように、その開示は次のよう
な組成がなされている。 Ｉ．　　初めの実施例 Ａ．　　システム・アーキテクチュア １．　　バスおよびメモリの階層性 ａ．　　マルチレベルのバス・システムＢ．　　バスの
論理的な術語 Ｃ．　　バスの物理的な術語 Ｄ．　　デバイス−バス・インタフェース１．　　信号 ２．　　裁定・インタフェース ３．　　データ／コントロール・インタフェース４．　
　両立性ポート Ｅ．　　トランザクション １．　　メモリ関連トランザクション ２．　　Ｉ／Ｏトランザクション ３．　　多面的トランザクション Ｆ．　　データの両立性 １．　　単一レベルのシステムにおけるデータの両立性
２．　　マルチレベルのシステムにおけるデータの両立
性ＩＩ．　　増強された実施例 Ａ．　　システム・アーキテクチュア Ｂ．　　デバイス−バス・インタフェース１．　　信号 ２．　　裁定・インタフェース ３．　　データ／コントロール・インタフェース４．　
　両立性ポート Ｃ．トランザクション １．　　メモリ関連トランザクション ２．　　Ｉ／Ｏトランザクション ３．　　多面的トランザクション Ｄ．データの両立性 【００１２】Ｉ．　　初めの実施例 ここで図面に移行すると、特に図１についてみると、複
数個のプロセッサ１２ａａ−１２ｉｊおよび共有のメイ
ン・メモリ１３を備えたマルチプロセッサ１１が示され
ている。このメイン・メモリ１３は集中化されたものと
して描かれているけれども、ここで理解されることは、
物理的なアドレス空間の使用されたサブセットについて
分裂した（即ち、相互に排他的であり、また、徹底的な
）カバーをするために分散化できるということである。 【００１３】Ａ．　　システム・アーキテクチュア１．
　　バスおよびメモリの階層性 プロセッサ１２ａａ−１２ｉｊは１個または複数個のク
ラスタ１４ａ−１４ｉ内で構成されているが、その各々
には、裁定され、パケットで切り換えられるローカル・
バス１５ａ−１５ｉがそれぞれに備えられている。例示
された実施例においてクラスタ１４ａ−１４ｉの各々に
含まれているものは、義務的なものではないが、１個ま
たは複数個のプロセッサ１２ａａ−１２ｉｊである。所
望であれば、例えば該クラスタの中の一つが、マルチプ
ロセッサ１３に対するＩ／Ｏ動作の実行のためのものと
されている。しかしながら、ここで重要であるとされる
ことは、プロセッサ１２ａａ−１２ｉｊの各々が、第１
レベルのキャッシュ・メモリ１６ａａ−１６ｉｊによっ
て、それぞれに（プロセッサ自体には、図示されないが
、１個または複数個のより低レベルでもあるキャッシュ
・メモリを含ませることができる）、そのクラスタまた
は“ローカル・ホスト”バス１５ａ．．．，もしくは１
５ｉに結合されているということである。その理由は、
プロセッサ１２ａａ−１２ｉｊがそれらのキャッシュ・
メモリ１６ａａ−１６ｉｊを介してそれらのホスト・バ
スと通信するようにされているからである。ローカル・
バス１５ａ−１５ｉは、これに次いで、それぞれに、ク
ラスタ１４ａ−１４ｉ内の共有資源に対してキャッシュ
１６ａａ−１６ｉｊをリンクさせる。例えばクラスタ１
４ａのローカル・バス１５ａは、プロセッサ１２ａａ−
１２ｉｊに対する第１レベルのキャッシュ１６ａａ−１
６ｉｊを、それぞれに、オプションのマップ・キャッシ
ュ１７ａおよび中間レベルまたは第２レベルのキャッシ
ュ・メモリ１９ａと相互接続させる。ここで示されてい
るように、該第２レベルのキャッシュ１９ａは、ランダ
ム・アクセス・メモリ（ＲＡＭ）モジュール２０ａおよ
びコントローラ２１ａからなるものである。 【００１４】ａ．　　マルチレベルのバス・アーキテク
チュア 例示されたマルチプロセッサ１１は階層的なアーキテク
チュアを有するものであり、異なるレベルの階層におけ
る同様な構成要素を同定するために同様な参照数字が採
用されている。更に、該構成要素の階層的な依存性を同
定するときの助け（デュアル・キャラクタのサフィック
スの第１のキャラクタを参照）のために、および、共通
の依存性を有する同様な構成要素間での区別をする（デ
ュアル・キャラクタのサフィックスの第２のキャラクタ
を参照）ために、アルファベットのサフィックスが前記
の参照数字に付加されている。 【００１５】所望であれば、クラスタ１４ａ−１４ｉの
いずれのものでも、完全に機能的なモノプロセッサまた
はマルチプロセッサのコンピュータ・システムとして動
作するように構成することができる。この発明のバス・
プロトコルによれば、単一のバス上で幾つかのプロセッ
サを支持するために十分に使用可能なバスのバンド幅が
付与されるが、ここでのシステムの構成は、大方の現存
するデスクトップ・ワークステーションの適用のために
、および、多くの現存するプリント・サーバーおよびフ
ァイル・サーバーの適用のために十分な演算パワーを付
与するものである。しかしながら、マルチプロセッサ１
１のツリー状にされた階層的なアーキテクチュアによれ
ば、ローカル・クラスタのバス・トランザクションが、
グローバルなメイン・メモリのトランザクションのよう
なグローバル・バス２６上の大方のトランザクションか
ら効果的に分離される。この結果として、バスに対する
バス・トラフィックと電気的なローディングとが分散さ
れ、これによって、より大きくてより有力なマルチプロ
セッサの構成が許容される。 【００１６】実際には、２−レベルの階層構成が例示さ
れているだけであるが、ここで理解されることは、階層
の任意所与のレベルにおける２本またはそれよりも多く
のバスを次に高いレベルにおけるバスと相互接続させる
ために、マルチプロセッサ１１のツリー状にされたアー
キテクチュアが、キャッシュ・メモリの付加的な層（図
示されない）の使用を通して伸長可能にされるというこ
とである。ここで認められるように、キャッシュ・メモ
リ１６ａａ−１６ｉｊおよび１９ａ−１９ｉはキャッシ
ュ・メモリのツリーとして構成されており、これらのキ
ャッシュの記憶能力は、典型的には、ツリーの深さが増
すにつれて減少するようにされている。階層の全てのレ
ベルにおいて同じバス・プロトコルが用いられているこ
とから、ある特定の適用についての特別の要求により良
く合わせるべくマルチプロセッサ１１の再構成をするた
めに、システムの設計者は十分な自由度を有している。 【００１７】メイン・メモリ１３は適当なコントローラ
２５を介してトップ・レベルの“グローバル”バス２６
に接続されているが、プロセッサおよびＩ／Ｏデバイス
は階層の任意のレベルにおいてバスに接続することがで
きる。バスの階層性は全てのバス・クライエント（即ち
、それぞれにプロセッサ１２ａａ−１２ｉｊに対するキ
ャッシュ１６ａａ−１６ｉｊ；Ｉ／Ｏブリッジ１８ｉが
ホスト・バス１５ｉと通信するときに介在するキャッシ
ュ６０；ローカル・エリア・ネットワーク（ＬＡＮ）３
０ｉおよびディスプレイまたはプリンタ・デバイス３１
ｉがそれぞれにホスト・バス１５ｉと通信するときに介
在するコントローラ２８ｉおよび２９ｉ；クラスタ１４
ａ−１４ｉがそれぞれにグローバル・バス２６と通信す
るときに介在する第２レベルのキャッシュ１９ａ−１９
ｉ；および、メイン・メモリ１３がグローバル・バス２
６と通信するときに介在するコントローラ２５）に対し
て透明なものであり、このために、クライエントは、可
能性のあるシステム構成のいずれに対してもカスタム化
する必要がない。セクションＩ．Ｄ．において更に十分
に後述されるように、バス・クライエント・インタフェ
ースはシステム構成から独立している。 【００１８】Ｂ．　　バスの論理的な術語この発明のバ
ス・プロトコルに含まれているものは、３個の異なるレ
ベル（即ち、バス・サイクルの電気的なレベル、パケッ
トの論理的なレベル、および、トランザクションの機能
的なレベル）におけるバスの動作である。 規定すべきこととしては、“バス・サイクル”が任意の
所与バス上におけるクロックの完全な周期であることか
ら、それは単一のバスを介する電気的な情報の転送のた
めの時間的な単位である。これに対して、“パケット”
は、論理的な情報の転送のための連続的なバス・サイク
ルの近接しているシーケンスである。そして、“トラン
ザクション”は論理的な機能を実行するための“リクエ
スト”パケットおよびそれに対応する“リプライ”パケ
ットからなるものであって、ここでの論理的な機能とは
、データ・フェッチ操作（即ち、ある特定のメモリ・ア
ドレス位置からのデータの読み取り）またはデータ記憶
操作（即ち、ある特定のメモリ・アドレス位置に対する
データの書き込み）のようなことである。先に指摘され
たように、リクエスト／リプライの全てのペアは分離し
ていることから、“ペンディング・リクエスト”（即ち
、リプライを待っているリクエスト）に対して予め選択
されたタイムアウトの周期によって規定される制限にな
るまでは、いずれのトランザクションに対するリクエス
トおよびリプライでも任意数のバス・サイクルによって
分離されることができる。特徴的なこととしては、各パ
ケットの第１のサイクル（いわゆる“ヘッダ”）はアド
レスおよびコントロール情報を有しており、これに対し
て、後続のサイクルはトランザクションの規定によって
しかるべく実行することを要求されたときのデータを有
している。 【００１９】バス１５ａ−１５ｉおよび２６の各々は同
期的なものであるが、バス対バスの情報の転送が第２レ
ベルのキャッシュ１９ａ−１９ｉのようなキャッシュに
よって完全にバッファされることから、これらは必ずし
も互いに同期している必要はない。更に、より十分に後
述されるように、バス１５ａ−１５ｉおよび２６の各々
は、裁定手段３５ａ，３５ｂ，３５ｉおよび３６によっ
て独立に裁定されるものである。 【００２０】パケットで切り換えられる全てのクライエ
ント・デバイス（規定すべきこととして、“クライエン
ト・デバイス”とは、−“バス・クライエント”として
参照されることもあるが−、ホスト・バス１４ａ−１４
ｉおよび２６を介してパケットの送受をするデバイスで
ある）は、バス“マスター”およびバス“スレーブ”と
しての双方の機能を果たすことが可能でなければならな
い。しかしながら、ある所与のトランザクションを開始
するためのリクエスト・パケットを発するクライエント
が“リクエスタ”として規定されているとき、または、
このようなリクエストに応答してリプライ・パケットを
発する任意のデバイスが“レスポンダ”として規定され
ているときには、クライエント・デバイスのトランザク
ション・レベルにおける相互作用は幾らか理解し易いも
のである。ここで認められるように、任意の所与のリク
エストに対して１個を超えるレスポンダは存在しない。 【００２１】その動作において、リクエスタに対するバ
スが裁定手段によって許容されることは、リクエスタに
よってなされる裁定のリクエストに応答することである
。バスの許容がなされたときには、このリクエスタはバ
ス“マスター”になり、これに次いでそのリクエスト・
パケットを発するようにされる。他の全てのバス・クラ
イエントはこのパケットによって保持されているアドレ
スおよびコマンドを調べて、それらが何等かの動作をす
るように要求されているかどうかの決定をする。１個ま
たは複数個のクライエントは、要求された動作を実行す
るために“スレーブ”としての動作の機能を果たすべく
要求されているが、そのリクエスト・パケットを発する
ことが終了すると、該当のバスがリクエスタによって即
座に解放される。かくして、リプライ・パケットをリク
エスタに対して返すことができるのに先だって裁定手段
からのバス・マスターシップを取得するために、レスポ
ンダは、固有の独立した裁定リクエストをしなければな
らない。このリプライ・パケットはリクエスタに対して
アドレスされているから、このリクエスタはそれを受け
入れるためにスレーブ・モードで動作することになる。 【００２２】Ｃ．　　バスの物理的な術語任意の所与の
バス（例えば、ローカル・バス１５ａ−１５ｉまたはグ
ローバル・バス２６の任意のもの）は多くのセグメント
からなるものであるが、好適には、バスの実行能力の低
下を回避するために、いずれの単一のバス内にも２個を
超える双方向性のバス・セグメントが存在しないように
される。このために、図３−図５を参照して認められる
ことは、コンピュータ・システムが、図３におけるよう
なモノボード・コンピュータとして、図４におけるよう
なマルチボード・コンピュータとして、または、図５に
おけるようなマルチボード／マルチモジュール・コンピ
ュータとして構成されるかどうかに拘らず、各バスのセ
グメントが同期してクロックされるパイプライン・レジ
スタ３７を介して接続されていることである。この発明
のバス・プロトコルに対しては、または、このプロトコ
ルで確実にされるキャッシュの両立性を維持するために
は、パイプライン操作は必須のことではないけれども、
１本または複数本のバスの電気的な特性を最適化するこ
とは容易にされる。しかしながら、ここで理解されるこ
とは、バスの各々がパケットで切り換えられることから
、パイプライン操作が実現の可能性があるオプションで
あるということである。より詳細にいえば、図３−図５
に描かれているシステムは、それぞれに、２−レベル，
３−レベルおよび４−レベルのパイプライン操作のもの
である。好適には、パイプライン式のバス・セグメント
は短いものであり、また、一般的には等しい長さのもの
であって、電気的な信号の伝播の遅れ時間を最小にし、
また、多少なりとも等しくするようにされる。更に、実
際には、バス・セグメントのあるものまたはその全てが
、不所望の信号の反射を抑制するために、平衡型の抵抗
性終端部（図示されない）等によって終端されている。 しかしながら、ここで注意されるべきことは、バスとバ
ス・プロトコルとの電気的な特性は互いに独立している
ということである。 【００２３】Ｄ．　　デバイス−バス・インタフェース
ここで想起されるように、図２の４１において示されて
いるような標準化されたバス・インタフェースは、バス
１４ａ−１４ｉおよび２６をそれぞれの“クライエント
・デバイス”と電気的に相互接続させるために設けられ
ている。好適には、これらのバス・クライエントに備え
られているオープン・ドレイン型のＣＭＯＳドライバお
よびレシーバ（係属中であり譲渡された、１９９０年３
月３０日に出願番号第０７／５０２，３７２号として出
願の、Ｗｉｌｌｉａｍ　　Ｆ．Ｇｕｎｎｉｎｇの米国特
許出願であって、“Ｄｒｉｖｅｒｓ　　ａｎｄ　Ｒｅｃ
ｅｉｖｅｒｓ　　ｆｏｒ　　Ｉｎｔｅｒｆａｃｉｎｇ　
　ＶＬＳＩ　　ＣＭＯＳ　　Ｃｉｒｃｕｉｔｓ　　ｔｏ
　　Ｔｒａｎｓｍｉｓｓｉｏｎ　　Ｌｉｎｅｓ”，Ｄ／
９０１５３を参照）は、それぞれに、バスに対する出力
信号の適用をし、また、バスからの入力信号を受け入れ
るためのものである。インタフェース４１のクライエン
ト側においてこのようなドライバおよびレシーバを用い
ることの利点は、それらの電力消費が著しく低く、現に
利用可能なＶＬＳＩ技術を用いてこの発明を実施するこ
とが許容されることである。 【００２４】１．　　信号 図６において示されているように、バス・インタフェー
ス４１に備えられているものは、コントロール・ポート
、裁定ポート、受け入れポート、送出ポートおよび両立
性ポートである。インタフェース４１のコントロール・
ポートに対して加えられるホスト・バスによるクロック
信号は、インタフェース４１とその関連のバス・クライ
エント・デバイスとの間の全ての相互作用についてのタ
イミングをコントロールし、また、クライエント・デバ
イスによって要求される任意の他のクロック信号を導出
することができる基準を付与するためのものである。 コントロール・ポートには、同期ストップ出力信号（Ｓ
ＳｔｏｐＯｕｔ）のための出力および対応の同期ストッ
プ入力信号（ＳＳｔｏｐＩｎ）のための入力も含まれて
おり、これによって、関連のクライエント・デバイスは
、システムを同期ストップに移行することが所望される
ときには、ＳＳｔｏｐＯｕｔを主張することができる。 いずれのバス・クライエントによるＳＳｔｏｐＯｕｔの
主張であっても、バス上の全てのクライエントおよび該
バスに対する裁定手段に対して“真の”ＳＳｔｏｐＩｎ
信号が加わるようにされ、これによって、クライエント
がＳＳｔｏｐＯｕｔの主張を解除するまでは、バス上の
全ての活動を停止するようにされる。 【００２５】２．　　裁定インタフェース裁定手段３５
ａ−３５ｉおよび３６は、それぞれに、任意の所与時点
において競合しているクライエント・デバイスの中でバ
ス１４ａ−１４ｉおよび２６を時間多重化させ、これに
よって、それぞれのクライエントが、そのホスト・バス
に対する公平に拘束された時間的なアクセスを確保する
ようにされる。これらのクライエント・デバイスは、１
本または複数本の専用リクエスト・ラインによって、お
よび、１本または複数本の専用許容ラインによって、そ
れらのホスト・バスに対する裁定手段に結合されている
。 【００２６】その動作において、クライエント・デバイ
スは、そのバス上にリクエスト・パケットまたはリプラ
イ・パケットを予め出力し、その１本または複数本の専
用リクエスト・ラインを介して、そのホスト・バスのた
めの裁定手段に対するバス・リクエストの送信をする。 大方の場合においては、裁定リクエストがなされるため
のリクエスト・パケットまたはリプライ・パケットをク
ライエントが十分にアセンブルした後で、該裁定リクエ
ストの送信がなされるものであるが、幾つかの場合にお
いては、クライエントによる待機時間を減少させるため
、該クライエントがまだパケットのアセンブルをしてい
る間に、裁定リクエストが裁定手段によって登録される
。例えば、メイン・メモリ１３の待機時間を減少させる
ために、メモリ・コントローラ２５は、好適には、メイ
ン・メモリ１３からのリプライに含まれるべきデータの
検索をしながら、ＲｅａｄＢｌｏｃｋのリプライ（より
詳細に後述される）に対するその裁定リクエストを登録
するようにされる。 【００２７】ここで認められるように、それぞれの裁定
手段が受け入れる裁定リクエストは異なる優先度を有し
ており、また、異なる長さのパケットの送信のためのバ
スを取得するようにされる（例えば、この初めの実施例
の実施においては、２−サイクル長および５−サイクル
長のパケットが用いられている）。このために、多くの
裁定リクエスト・ラインを設けることが好都合である（
図２および図６を参照）が、その理由は、クライエント
・デバイスによってわずか数クロック・サイクル（この
初めの実施例および増強された実施例に関して、それぞ
れに、１サイクルの裁定リクエストおよび２サイクルの
裁定リクエストが後述される）の間にそれらの裁定リク
エストをコード化することが、該多くの裁定リクエスト
・ラインによって許容されるからであり、コード化する
ことを用いることにより、異なる優先度の裁定リクエス
トと異なる長さのパケットの送信のための裁定リクエス
トとの間での識別が、裁定手段によって可能にされる。 いずれのクライエント・デバイスでも、任意の瞬間にお
けるそのバス裁定手段と係属する多くの裁定リクエスト
を備えている。裁定手段は、これに次いで、競合してい
るクライエント・デバイスについて係属する裁定リクエ
ストの優先度を定めるための予め選択された裁定ルール
を適用し、そして、専属の１本または複数本のラインを
介して、該競合しているクライエント・デバイスに対し
てバス許容信号を次々に返すことにより、逐次的にそれ
らのリクエストを優先順位をもって許容していく。 例えば、１個または複数個のクライエント・デバイスの
任意のものが、ホスト・バスに対して異なる優先度の登
録された裁定リクエストを有するときに支配をする裁定
ルールにより、裁定手段が優先度の降下する順序に応じ
てそれらのリクエストを許容するようにされる。これに
対して、１個または複数個のクライエント・デバイスか
らの同じ優先度の裁定リクエストは、競合しているクラ
イエントの間で裁定を下すための“ラウンド−ロビン”
ルール、および、任意の所与のクライエントの多くのリ
クエストの間での裁定を下すためのＦＩＦＯ（先入れ／
先出し）ルールを用いて適当に処理される。 【００２８】より詳細にいえば、図６において示されて
いるように、各クライエント・デバイスは、２本の裁定
リクエスト・ライン３８および１本の許容ライン３９を
有している。これら２本の裁定リクエスト・ライン３８
のために、４個までの異なる裁定リクエストをコード化
することがクライエントにより可能にされて、図７の４
０および４１におけるような裁定手段によるデコード操
作をするようにされる。全てのバス・クライエントの裁
定の要求は、メイン・メモリ・コントローラを除いて、
それらのコード化に対して以下の意味を指定することに
よって満足することができる。 　　　　コード化　　Ｎｏ．　　　　　　　　　　　　
　　　　　　　　　　　　意味　　　　　　　　０　　
　　　　　　　　　　　　　　システム−ワイドの保持
に対するデマンドの解除　　　　　　　　１　　　　　
　　　　　　　　　　　システム−ワイドの保持に対す
るデマンド　　　　　　　　２　　　　　　　　　　　
　　　　　低優先度の裁定リクエストの付加　　　　　
　　　３　　　　　　　　　　　　　　　　高優先度の
裁定リクエストの付加　　【００２９】メイン・メモリ
の全ての裁定リクエストは同じ優先度のものであること
から、メイン・メモリ・コントローラからの裁定リクエ
ストは以下のように適当に解釈される。 　　　　コード化　　Ｎｏ．　　　　　　　　　　　　
　　　　　　　　　　　　意味　　　　　　　　０　　
　　　　　　　　　　　　　　システム−ワイドの保持
に対するデマンドの解除　　　　　　　　１　　　　　
　　　　　　　　　　　システム−ワイドの保持に対す
るデマンド　　　　　　　　２　　　　　　　　　　　
　　　　　短い（２サイクルの）パケットに対するリク
エスト　　　　　　　　　　　　　　　　　　　　　　
　　　　の付加　　　　　　　　３　　　　　　　　　
　　　　　　　長い（５サイクルの）パケットに対する
リクエスト　　　　　　　　　　　　　　　　　　　　
　　　　　　の付加【００３０】その実際においては、
裁定リクエストについての前述の解釈が、（図示されな
い手段により）システムの初期化の間に、裁定手段にお
ける裁定ポート内にプログラムされる。より詳細にいえ
ば、メモリ・コントローラに接続されているポート４３
のような裁定ポートは、いわゆる“メモリ・ポート”と
して機能するようにプログラムされるが、これの意味す
ることは、それらが単一のＦＩＦＯリクエスト・レジス
タを用いており、また、短いリプライ・パケットおよび
長いリプライ・パケット（より高い優先度は“キャッシ
ュ・リプライ優先度”だけである）の双方に対して“メ
モリ優先度”が指定されることである。別の裁定ポート
４２は、いわゆる“正常ポート”として機能するように
プログラムされるが、これの意味することは、低い優先
度のリクエストおよび高い優先度のリクエストを登録す
るために、分離したカウンタまたはレジスタが用いられ
るということである。このために、関連したクライエン
ト・デバイスによって低い優先度および高い優先度の裁
定リクエストが形成されるパケットの長さに関して、こ
れらの裁定ポート４２の各々が更にプログラムされる。 【００３１】サービスが要求されるものとして、異なる
タイプのクライエント・デバイスから裁定手段が受け入
れることができる、裁定リクエストに対する優先度の典
型的な指定は以下の通りである（下降する順序での優先
度）。 　　　　優先度　　Ｎｏ．　　　　　　　　　　　　　
　　　　　　　　　　　　　　　指定　　　　　　　　
０　　　　　　　　　　　　　　　　キャッシュのリプ
ライの優先度　　　　　　　　１　　　　　　　　　　
　　　　　　メモリ・コントローラおよびＩ／Ｏのリプ
ライの優　　　　　　　　　　　　　　　　　　　　　
　　　　　先度　　　　　　　　２　　　　　　　　　
　　　　　　　ディスプレイ・コントローラ・リクエス
トの高い優　　　　　　　　　　　　　　　　　　　　
　　　　　　先度　　　　　　　　３　　　　　　　　
　　　　　　　　Ｉ／Ｏリクエストの優先度　　　　　
　　　４　　　　　　　　　　　　　　　　キャッシュ
のリクエストの優先度　　　　　　　　５　　　　　　
　　　　　　　　　　ディスプレイ・コントローラ・リ
クエストの低い優　　　　　　　　　　　　　　　　　
　　　　　　　　　先度【００３２】一般的にいえば、
ディスプレイ・コントローラ（図１の２８ｉを参照）で
はそのリクエストを満たすために低い裁定の優先度が用
いられていることから、他のものがアイドル状態にある
バス・サイクル中に、通常は、そのコントローラに対し
て伝送されるデータによってディスプレイの駆動がなさ
れる。しかしながら、ディスプレイに対するデータ・キ
ューが近傍のエンプティ・レベルに落ちるときには、デ
ィスプレイ・コントローラは、そのデータ・キューを補
充するために、幾つかのリクエスト・パケットに対する
その高い優先度のリクエスト・レベルを採用するように
される。 【００３３】係属するリプライの個数を減少させるため
に、２個の最も高い裁定の優先度がリプライに対して指
定される。これは、バスのデッドロックを回避するため
の、重要なフロー・コントロールのメカニズムである。 また、トランザクションの実行の遅れ（即ち、リクエス
トの発行とこれに応じるリプライの受け入れとの間の時
間）も減少される。しかしながら、リプライに対して与
えられる高い優先度は、オーバフローのリスクを冒しな
がら、そのトランザクション・リクエスト・レジスタ３
４（図２）に対して十分な個数のトランザクション・リ
クエストを累積するクライエント・デバイスの可能性を
増大させる。従って、このような渋滞を防止するために
、裁定手段についてシステム・ワイドでの保持をデマン
ドする任意のクライエント・デバイスによって求められ
る第２のフロー・コントロールのメカニズムがある。 システム・ワイドでの保持に対するデマンドにより、リ
クエスト・パケットの送信についての許可を、裁定手段
がバスに対して出すことが不可能になることから、該裁
定手段は該バスをして、リプライ・パケットを送信する
ための裁定リクエストを出しているクライエントに専用
のものとする。一旦デマンドが出されると、このような
システム・ワイドでの保持により、そのデマンドを出し
ているクライエントによって解放されるまで、有効な状
態に留められる。これによって可能にされることは、渋
滞の状態にあるクライエントが、正常な動作が再開され
るのに先だってその渋滞の状態を解放するために、その
係属中のリクエストキューが十分に低いレベルまで降下
することを確実にすることである。 【００３４】前述されたことから理解されるように、異
なるクライエント・デバイスは異なるレベルの優先度を
もつことができるけれども、ホスト・バスの割当が予め
強調されることはない。その結果として、そのホスト・
バスが許容されたクライエント・デバイスは、バス上で
完全なリクエスト・パケットまたはリプライ・パケット
を配することができるように、十分な時間的な周期にわ
たって“バス・マスター”であることになる。 【００３５】しかしながら、ここで理解されるべきこと
は、裁定リクエストのコード化をすることの重要な利点
の一つとして、任意の処与のクライエントからの任意の
処与の裁定リクエストに対して、その処与の裁定リクエ
ストに応じてバスが許容されたときの、該処与のクライ
エントが発するパケットの長さを、裁定手段によって予
言的に決定することができる。これで許容されることは
、クライエントが発するパケットのために必要とされる
バス・サイクルの正確な個数について、任意の処与のク
ライエント・デバイスに対してバスが許容する時間の長
さを、裁定手段によって制限することである。より有意
義なこととしては、図８に示されているように、Ｇｒａ
ｎｔ１　およびＧｒａｎｔ２　のような連続的な許可の
タイミングのコントロールが、裁定手段によって可能に
される。このために、第２の許可（Ｇｒａｎｔ２　）が
発せられるのは、生じているパケットＡの最終バス・サ
イクルに対する許可（Ｇｒａｎｔ１）を現在のバス・マ
スターのクライエントが評価した直後である。次に続く
バス・マスターになるクライエントによって、この早期
の許可の告知のために可能にされることは、その直前の
パケットＡの最終サイクルに追従するパケットＢのはじ
めのサイクルの間に、そのパケットＢに対するヘッダー
・サイクルをもってバスを駆動するために適当な高い電
圧レベルまで、バス・ドライバによって移行させるのに
十分な時間がもたらされることである。かくして、明瞭
であることは、裁定手段は、バス上のパケットの送信に
関する時間的なオーバラップをしながらバスの裁定を実
行するだけではなく、クライエントが全ての利用可能な
バス・サイクルをパケットで満たすことも許容すること
である。 【００３６】図３，図４および図５において示されてい
るような複数個のパイプライン式のバス・セグメントか
ら構成されているバスは、それらのクライエントが全て
の利用可能なバス・サイクルをパケットで満たすことも
許容するために、前述されたタイプの予測的なオーバラ
ップ式の裁定を用いるように所望されているときには、
ある程度の注意を払って設計されねばならない。これを
より詳細にいえば、連続的なパケットＡおよびＢは、こ
のようなバスの中間セグメントまたはいわゆる“バック
パネル”セグメント上において、該バックパネル・セグ
メントがバスの双方向性セグメントだけであるときにの
み、連続的なバス・サイクルに詰め込むことができる。 そうでないときには、パケットＡおよびＢを連続的なバ
ス・サイクルに詰め込もうとするいかなる試行でも、任
意の処与のバス・セグメント上でのそれら２個のパケッ
ト間での時間的なオーバラップに対する禁止によって妨
げられる。図３，図４および図５において示されている
ように、その解決策は、バックパネル・セグメントに対
するものを除いて、このようなバスの全てのセグメント
に対して単方向性のバス・セグメントを使用することで
ある。この解決策の有効性は図８において示されている
。ここで、図４に示されているバスの、それぞれに単方
向性の出力セグメントＡ１　およびＡ２からのパケット
ＡおよびＢは、そのバックパネル・セグメントＢを介し
て、それぞれに単方向性の入力セグメントＣ１　および
Ｃ２　に至るようにされる。 【００３７】図示されている２本の付加的なワイヤ５１
および５２は、サービスに責任のある全てのクライエン
ト・デバイスに対する各裁定手段に接続されている。あ
る処与のクライエント・デバイスに対するバスの許可の
直前のサイクルにおいて、いわゆるＨＩＰＧｒａｎｔラ
イン５１上の信号の論理的なレベルにより、次に続く許
可が高い優先度のリクエストに相応しているか否かの決
定がクライエント・デバイスによってなされ、また、い
わゆるＬｏｎｇＧｒａｎｔライン５２上の信号の論理的
なレベルにより、次に続く許可が長いパケットに対する
ものであるか否かの決定がクライエント・デバイスによ
ってなされる。従って、これら２個の信号により、異な
る優先度の係属中の裁定リクエストに対する許可の間に
ついて、および、異なる長さのパケットの送信を認める
ために与えられる許可の間について、クライエントがそ
の区別をすることが可能になる。 【００３８】３．　　データ／コントロール・インタフ
ェース ここで図１に戻ると、グローバル・バス２６および１４
ａ−１４ｉのようなクラスタ・バスの各々は、２ｎ　で
表されるような２の累乗のビット・ワイドの多重化した
データ／アドレス・パスを形成するようにされている。 クライエント・デバイスを単方向性のバス・セグメント
に接続するために、その標準的なインタフェース４１（
図６）には１個の送出ポートおよび１個の受容ポートが
備えられており、その各々は、２ｎ　ビット・ワイドの
データ／アドレス・パス（この発明の典型的な実施にお
いては、各バスのデータ／アドレス・パスは６４ビット
・ワイドである）を構成している。しかしながら、イン
タフェース４１の送出ポートは双方向性のモードで動作
できることから、クライエント・デバイスを双方向性の
バス・セグメントに接続するために、送出／受容（送受
両用）ポートとして用いられることになる。 【００３９】ここで示されているように、これらの送出
ポートおよび受容ポートにも、ヘッダー・サイクル・ビ
ットのための１本のワイヤおよびパリティ・ビットのた
めの１本のワイヤが含まれている。この実施例において
は、パケットのヘッダー・サイクルを同定するために、
バス・マスター（即ち、該当のパケットを発しているク
ライエント）による各パケットのはじめのサイクルの間
に、ＨｅａｄｅｒＣｙｃｌｅの論理的な真（“１”）の
信号が出される。その他方において、受容側がデータ送
信のエラーを検出できるように、関連するパケットで搬
送されるデータからのパリティの算出がデータ源におい
てなされる。このパリティ・チェック操作は全く従来か
らのものであることから、この特定の実施例においてバ
スがアイドル状態にあるときの論理的なレベルがロー（
“０”）であるために、偶数パリティが採用されている
ことを注意すれば十分である。 【００４０】４．　　両立性ポート 任意の処与の時点において、任意の処与のバス上の２個
またはそれよりも多くのキャッシュ・メモリ・クライエ
ント内にキャッシュされている、メモリ・アドレスの各
々の全てのキャッシュされたコピーを通してデータの両
立性を維持するために、バス・デバイス・インタフェー
ス４１は、それぞれに、キャッシュ・メモリからのＳｈ
ａｒｅｄＯｕｔ信号およびＯｗｎｅｒＯｕｔ信号を送信
するための出力部６２および６３とともに、メモリ・コ
ントローラ（中間レベルまたはより高いレベルのキャッ
シュに対するコントローラを含んでいる）からのＳｈａ
ｒｅｄＩｎ信号およびＯｗｎｅｒＩｎ信号を受信するた
めの入力部６１および６２を備えている。 【００４１】同じバス上のキャッシュ・リクエスタがメ
モリ・リクエスト（例えば、この実施例におけるＷｒｉ
ｔｅＳｉｎｇｌｅ，ＣｏｎｄｉｔｕｏｎａｌＷｒｉｔｅ
ＳｉｎｇｌｅまたはＲｅａｄＢｌｏｃｋＲｅｑｕｅｓｔ
）を出すときはいつでも、ある固定的な時間遅れの後に
、真の（論理“１”の）ＳｈａｒｅｄＯｕｔ信号の状態
がキャッシュによって主張される。その他方において、
ＳｈａｒｅｄＩｎは、バス上の全てのキャッシュからの
ＳｈａｒｅｄＯｕｔ信号の、適当に遅れた論理的ＯＲに
されている。この論理的ＯＲの操作に起因する遅れも固
定されており、リクエストを受け入れたときにリクエス
タによって特定されたアドレスがバス上の他のキャッシ
ュのいずれかによって共有されているかどうかを決定す
る為に、このようなリクエスト・パケットを受け入れて
からある所定の時間の後で、レスポンダによってＳｈａ
ｒｅｄＩｎ信号のレベルが評価される。ここで認められ
るように、リプライ・パケットのヘッダー・サイクルに
おける、いわゆる“ｒｅｐｌｙＳｈａｒｅｄ”ビットに
よって、そのリプライをレスポンダが発するときには、
このＳｈａｒｅｄＩｎ信号の値はリクエスタに戻される
。そして、これにより、そのリクエストがなされたとき
に、そのリクエストが指向されたデータが共有されてい
るか否かについて、リクエスタに告知するようにされる
。 【００４２】他のキャッシュから受け入れられる読み取
りリクエスト（例えば、ＲｅａｄＢｌｏｃｋＲｅｑｕｅ
ｓｔ）において特定されるアドレスに存在するデータ・
ブロックの“ｏｗｎｅｒ”であるときはいつでも、ある
固定的な時間遅れの後に、真の（論理“１”の）Ｏｗｎ
ｅｒＯｕｔ信号の状態がキャッシュによって主張される
。より詳細に後述されるように、データが特定のデータ
・ブロックに書き込まれるときはいつでも、キャッシュ
はデータ・ブロックの“ｏｗｎｅｒ”になる。これの意
味することは、その所有権は、たとえ存在するとしても
、最後にデータ・ブロックに書き込まれたキャッシュに
属することから、任意の所与のデータ・ブロックについ
て、一時に１個の“ｏｗｎｅｒ”しか存在しないことに
なる。それにも拘らず、タイミングを簡略化するために
、ＯｗｎｅｒＩｎ信号は、好適には、バス上のキャッシ
ュからのＯｗｎｅｒＯｕｔ信号の同様に遅れた論理的Ｏ
Ｒであるから、リプライを出すか、または、データにつ
いてのより低いレベルのキャッシュの“ｏｗｎｅｒ”か
らのリプライに従うかを決定するためにＳｈａｒｅｄＩ
ｎを評価するのと同じ時点において、バス上の最上位の
クライエント（即ち、メモリ・コントローラまたはより
高いレベルのキャッシュ）はＯｗｎｅｒＩｎを評価する
ことができる。ここで認められるように、１個よりも多
くのキャッシュがＯｗｎｅｒＯｕｔを主張することはで
きないために、キャッシュからのＯｗｎｅｒＯｕｔ信号
のＯＲ操作をすることは必須のことではないけれども、
ＳｈａｒｅｄＩｎの値およびＯｗｎｅｒＩｎの値につい
て一様な扱いがもたらされることになる。 【００４３】ここで注目されるべきことは、Ｓｈａｒｅ
ｄＩｎ信号の値およびＯｗｎｅｒＩｎ信号の値が、ワイ
ヤ式のＯＲ操作よりも論理的なＯＲ操作によって演算さ
れるということである。これによってＳｈａｒｅｄＩｎ
およびＯｗｎｅｒＩｎのパイプライン操作が許容され、
その一方では、それらのタイミングおよび解釈上での電
気的な制約を回避するようにされる。所望されるときに
は、ＳｈａｒｅｄＯｕｔ／ＳｈａｒｅｄＩｎ信号の値お
よびＯｗｎｅｒＯｕｔ／ＯｗｎｅｒＩｎ信号の値のパリ
ティ・チェック操作も許容される（増強した実施例につ
いての以下の説明において、このオプションの検討を参
照されたい）。 【００４４】Ｅ．　　トランザクショントランザクショ
ンはバス・プロトコルの最上層のものである。各トラン
ザクションは、独立して裁定されるリクエスト・パケッ
トおよびリプライ・パケットからなるものである。リク
エスタがバスに対する裁定手段による裁定リクエストを
登録したときに、ある１個のトランザクションが始まる
けれども、該裁定手段がバスに許可を出すまでは、該当
のリクエスト・パケットはそのリクエスト・レジスタ２
８に記憶される。該当のことが生起すると、リクエスタ
は、連続的なバス・サイクルの間に、そのリクエスト・
パケットを一時に１サイクルだけ発生させる。 【００４５】“ヘッダー・サイクル”と呼ばれるリクエ
スト・パケットの初めのサイクルには、リクエスタおよ
びこのリクエスタが始めるトランザクションを同定する
ために必要な全ての情報が含まれている。これには、該
当のトランザクションを好適な結論に導くときに関与す
ることが必要な、１個または複数個のクライエント・デ
バイスを選択するために十分な情報も含まれている。リ
クエスト・パケットの後続のサイクルに一般的に含まれ
ているものは、実行されるべきトランザクションに依存
するデータである。全てのクライエント・デバイス（リ
クエスタを含む）はリクエスト・パケットを受け入れて
、該当のトランザクションに関与することが要求されて
いるか否かを決定するために、該デバイスの各々によっ
てそのヘッダー・サイクルを調べるようにされる。 【００４６】一般的なルールとして、各リクエスト・パ
ケットにおけるヘッダー・サイクルの相当な個数のビッ
トが、メモリ位置またはＩ／Ｏデバイス・レジスタの選
択をするために、リクエスタによって出されるアドレス
に対して保留される。デバイスがある１個のトランザク
ションにおいて関与するように選択されるメカニズムは
、異なるトランザクションのためには異なることがあり
得るけれども、大方のトランザクションにおいては、選
択メカニズムとしてそのヘッダー・サイクルに含まれて
いるアドレスを使用するようにされる。 【００４７】図９を参照しながら、より詳細にいえば、
この実施例においては、各リクエスト・パケットにおけ
るヘッダー・サイクルの４７ビットがアドレス・フィー
ルドに対して割り当てられている（この実施においては
、これらのビットの中の３２ビットだけが用いられてお
り、このために、他の１５ビットは更に別の伸長作業の
ために利用可能なものであって、これの意味することは
、それらが全て“０”であることを確認するためにアド
レス・フィールドを読み取るときに、これらの使用され
ないビットがチェックされねばならないということであ
る）。他のビットの中の１０個のビットは、各クライエ
ント・デバイスが指定される固有の識別子である、いわ
ゆる“ＤｅｖｉｃｅＩＤ”を搬送するために保留されて
いる（これらのＤｅｖｉｃｅＩＤは、図示されない手段
によるシステムの起動の間に適当に指定されるものであ
る）。更に、リクエストのヘッダー・サイクルにおける
残りのビットの中の５個のビットは、トランザクション
のコマンドのコード化のために使用される。そして、更
に１個の余分のビットは、クライエント・デバイスによ
る保護的“モード”のチェック操作のために用いられる
（このモードのチェック操作によってクライエント・デ
バイスに可能にされることは、リクエスタが、特定され
たトランザクションを開始するように権限を付与されて
いるかどうかを決定することであるが、このようなモー
ドのチェック操作はこの発明の範囲を超えるものである
）。従って、この特定の実施においては、リクエストの
ヘッダー・サイクルで指定のないビットは１ビットだけ
である。 【００４８】リクエスト・パケットを受け入れると、多
くのクライエントがその内部的な状態を変更することが
できるけれども、１個だけのクライエント・デバイスが
任意の所与のリクエストに対してリプライを出すことに
なる。レスポンダは、初めに、部分的または完全にその
リプライのアセンブルをし、これに次いで、そのバスに
対する裁定手段をもって、バスの裁定リクエストの登録
をする。その後で、バスの許可がなされると、１個また
は複数個のデータ・サイクルによって追従されるヘッダ
ー・サイクルをもって再開する連続的なバス・サイクル
の間に、レスポンダは一時に１サイクルのリプライ・パ
ケットを送出する。例えば６４ビット・ワイドのバスに
より、各データ・サイクル上での８オクテット（８ビッ
ト・バイト）のデータ転送ユニットが支持される。これ
に次いで、様々に異なるワードに基づくソフトウエア・
アーキテクチュアを実施するために、これらのバイトが
種々の長さのワードに組成される。 【００４９】図１０に示されているように、各リプライ
・パケットにおけるヘッダー・サイクルは、リクエスタ
から受け入れられたコード化したコマンド、リクエスタ
によって特定されたアドレス、および、リクエスタのＤ
ｅｖｉｃｅＩＤのビットを同定するトランザクションの
反復をする。典型的には、このレスポンダは、リクエス
ト・パケットにおけるヘッダー・サイクルからこの情報
を取り出して、リプライ・パケットにおけるヘッダー・
サイクルの構成の際に用いるためにそれを記憶するだけ
である。この情報によれば、リプライ・パケットが関係
するトランザクションを固有に同定するだけではなく、
リプライ・パケットをトランザクションのリクエスタに
対して明確にリンクするようにされる。 【００５０】ある程度の付加的な詳細における典型的な
リプライ・パケットのヘッダー・サイクルについて考慮
すると、ここで好適に観察されることは、対応するリク
エスト・パケットにおけるヘッダー・サイクルに対して
ビット対ビットで等価のものであって、以下の例外が存
在する。即ち：（１）該当のパケットがリプライである
ことを指示するために、リクエスト／リプライ・フラグ
・ビットが反転される；（２）リプライのアセンブルを
しているとき、レスポンダがフォールトに遭遇したか否
かを指示するために、リクエスト・ヘッダーにおけるモ
ード・ビットが、リプライ・ヘッダーにおけるフォール
ト・ビットとして用いられる；そして、（３）レスポン
ダがトランザクションのためのリクエスト・パケットを
受け入れた時点において、該トランザクションに対して
特定されたアドレスでのデータが多くのキャッシュによ
って共有されたか否かを指示するために、リクエスト・
ヘッダーにおける不使用のビットが、ｒｅｐｌｙＳｈａ
ｒｅｄビットとして用いられる。このｒｅｐｌｙＳｈａ
ｒｅｄビットの機能については、更に十分に後述される
。しかしながら、この点について適切に注意されること
は、フォールトに遭遇したときにのみ、レスポンダがフ
ォールト・ビットを真の（“１”の）論理レベルの状態
に駆動するということである。そして、このようなフォ
ールトが生じたときにはいつでも、このビットはリクエ
スタに対して効果的にこれを告知する。これにより、該
リクエスタをして、フォールト・コード（これは好適に
はリプライ・パケットにおける第２サイクルの３２個の
下位順序のビットにおいて伝送される）を受け入れるべ
く用意をさせる。フォールトの検出およびフォールト・
コードの発生はこの発明の範囲外のことである。 【００５１】前述のように、全てのクライエント・デバ
イスは、何等かの動作がそれらについて要求されている
かどうかを決定するために、リプライ・パケットにおけ
るヘッダー・サイクルを調べるようにされる。その動作
においては、異なるクライエント・デバイスの中でのリ
プライを明確にするためにＤｅｖｉｃｅＩＤが当てにさ
れる。しかしながら、ある種のクライエントは、多くの
未解決または係属のリクエストを持っている可能性があ
る。このために、好適には、多くのＤｅｖｉｃｅＩＤを
クライエントに対して指定することにより、または、そ
れらの未解決なリクエストに対するリプライを明確にす
るために、それらを可能化させるべく何等かの他の適当
な備えをすることにより、リプライがそれらのクライエ
ントの各々において更に明確にされる。 【００５２】リクエスタがリプライを受け入れたときに
は、トランザクションは完了する。大方の場合において
、この発明のバス・プロトコルによれば、リクエストと
リプライとの間で１対１の対応が成立する。しかしなが
ら、ある種のリクエスト・パケットは対応のリプライ・
パケットを持っておらず、また、これと逆の関係も成り
立つが、その理由は、バス・プロトコルの実行によるた
め、または、エラー等によるためのいずれかである。 かくして、このプロトコルは、不変のものとしてのリク
エスト／リプライのペアリングには依存しないことにな
る。これに代えて要求されることは、任意の所与のバス
上の全てのクライエント・デバイスが、到着の順序にお
けるそれらからの動作を要求するリクエスト・パケット
にサービスをすることだけである。ここで認められるよ
うに、この要求はデータの両立性を維持することの中心
にあるものである。 【００５３】コマンドのコード化、および、この初めの
実施例のために規定されたトランザクションに対するリ
クエスト／リプライ・ペアのパケット・レングスを要約
するテーブルが以下に示されている。 　　トランザクション・ペア　　　　　　　　　　　　
　　省略形　　　　　　コード化　　　　　　レングス
　　ＲｅａｄＢｌｏｃｋＲｅｑｕｅｓｔ　　　　　　　
　　　　　　　　　　　　　ＲＢＲｑｓｔ　　　　　　
　　００００　０　　　　　　　　　　２　　　Ｒｅａ
ｄＢｌｏｃｋＲｅｐｌｙ　　　　　　　　　　　　　　
　　　　　　　　ＲＢＲｐｌｙ　　　　　　　　０００
０　１　　　　　　　　　　５　　　ＷｒｉｔｅＢｌｏ
ｃｋＲｅｑｕｅｓｔ　　　　　　　　　　　　　　　　
　　　ＷＢＲｑｓｔ　　　　　　　　０００１　０　　
　　　　　　　　５　　　ＷｒｉｔｅＢｌｏｃｋＲｅｐ
ｌｙ　　　　　　　　　　　　　　　　　　　　　ＷＢ
Ｒｐｌｙ　　　　　　　　０００１　１　　　　　　　
　　　２　　　ＷｒｉｔｅＳｉｎｇｌｅＲｅｑｕｅｓｔ
　　　　　　　　　　　　　　　　　　ＷＳＲｑｓｔ　
　　　　　　　００１０　０　　　　　　　　　　２　
　　ＷｒｉｔｅＳｉｎｇｌｅＲｅｐｌｙ　　　　　　　
　　　　　　　　　　　　　ＷＳＲｐｌｙ　　　　　　
　　００１０　１　　　　　　　　　　２　　　Ｃｏｎ
ｄｉｔｉｏｎａｌＷｒｉｔｅＳｉｎｇｌｅＲｅｑｕｅｓ
ｔ　　　　　　　ＣＷＳＲｑｓｔ　　　　　　　００１
１　０　　　　　　　　　　２　　　Ｃｏｎｄｉｔｉｏ
ｎａｌＷｒｉｔｅＳｉｎｇｌｅＲｅｐｌｙ　　　　　　
　　　ＣＷＳＲｐｌｙ　　　　　　　００１１　１　　
　　　　　　　　５　　　ＦｌｕｓｈＢｌｏｃｋＲｅｑ
ｕｅｓｔ　　　　　　　　　　　　　　　　　　　ＦＢ
Ｒｑｓｔ　　　　　　　　０１００　０　　　　　　　
　　　５　　　ＦｌｕｓｈＢｌｏｃｋＲｅｐｌｙ　　　
　　　　　　　　　　　　　　　　　　ＦＢＲｐｌｙ　
　　　　　　　０１００　１　　　　　　　　　　２　
　　未定義（Ｕｎｄｅｆｉｎｅｄ　）　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　０１０
１　０　　未定義（Ｕｎｄｅｆｉｎｅｄ　）　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
０１１１　１　　ＩＯＲｅａｄＲｅｑｕｅｓｔ　　　　
　　　　　　　　　　　　　　　　　　　ＩＯＲＲｑｓ
ｔ　　　　　　　１０００　０　　　　　　　　　　２
　　　ＩＯＲｅａｄＲｅｐｌｙ　　　　　　　　　　　
　　　　　　　　　　　　　　ＩＯＲＲｐｌｙ　　　　
　　　１０００　１　　　　　　　　　　２　　　ＩＯ
ＷｒｉｔｅＲｅｑｕｅｓｔ　　　　　　　　　　　　　
　　　　　　　　　ＩＯＷＲｑｓｔ　　　　　　　１０
０１　０　　　　　　　　　　２　　　ＩＯＷｒｉｔｅ
Ｒｅｐｌｙ　　　　　　　　　　　　　　　　　　　　
　　　　ＩＯＷＲｐｌｙ　　　　　　　１００１　１　
　　　　　　　　　２　　　ＢＩＯＷｒｉｔｅＲｅｑｕ
ｅｓｔ　　　　　　　　　　　　　　　　　　　　　Ｂ
ＩＯＷＲｑｓｔ　　　　　　１０１０　０　　　　　　
　　　　２　　　ＢＩＯＷｒｉｔｅＲｅｐｌｙ　　　　
　　　　　　　　　　　　　　　　　　　ＢＩＯＷＲｐ
ｌｙ　　　　　　１０１０　１　　　　　　　　　　２
　　　ＭａｐＲｅｑｕｅｓｔ　　　　　　　　　　　　
　　　　　　　　　　　　　　ＭａｐＲｑｓｔ　　　　
　　　１１１０　０　　　　　　　　　　２　　　Ｍａ
ｐＲｅｐｌｙ　　　　　　　　　　　　　　　　　　　
　　　　　　　　　ＭａｐＲｐｌｙ　　　　　　　１１
１０　１　　　　　　　　　　２　　　ＤｅＭａｐＲｅ
ｑｕｅｓｔ　　　　　　　　　　　　　　　　　　　　
　　　　ＤｅＭａｐＲｑｓｔ　　　　　１１１１　０　
　　　　　　　　　２　　　ＤｅＭａｐＲｅｐｌｙ　　
　　　　　　　　　　　　　　　　　　　　　　　　Ｄ
ｅＭａｐＲｐｌｙ　　　　　１１１１　１　　　　　　
　　　　２　 【００５４】ここで認められるように、３個の一般的な
タイプのトランザクションがある。即ち、（ａ）キャッ
シュされたデータの両立性を維持しながら、メモリ・ア
クセス動作を実行するためのメモリ・トランザクション
、（ｂ）プログラムされたＩ／Ｏ動作を実行するための
Ｉ／Ｏ・トランザクション、および、（ｃ）更に他の機
能を実施するための多面的なトランザクションがある。 ここで評価されるように、リクエスト／リプライ・フラ
グ・ビット（即ち、前述のテーブルにおいて示されてい
るようなコマンド・フィールドの第５ビット）の論理的
なレベル（“０”または“１”）は、任意の所与のパケ
ットがリクエストまたはリプライのいずれであるかを指
示するためには十分なものであることから、トランザク
ションのコマンドの極めてコンパクトで効率的なコード
化をすることが実際的である。このコマンド・フィール
ドのフォーマットを用いて、１６個までの異なるコマン
ドのコード化をすることが可能であるから、上記のよう
に規定されたトランザクションでは、コマンド・フィー
ルドの容量を部分的に消耗するだけであることが理解さ
れる。勿論、所望であるときには、付加的な特徴を実現
する更に別のトランザクションを規定するために、コマ
ンド・フィールドの余分の容量を用いることができる。 【００５５】１．　　メモリ関連のトランザクションＩ
／Ｏデバイスとメモリとの間でと同様に、プロセッサと
メモリとの間でのデータの転送をするためにメモリ・ト
ランザクションが用いられる。これをより詳細にいえば
、メイン・メモリ１３または他のキャッシュからデータ
・ブロックを読み取るために、所望のデータ・ブロック
のバージョンがメモリ・システムのいずれかの位置にキ
ャッシュされているかどうかに依存して、そして、そう
であるときには、該キャッシュされたバージョンが“ｏ
ｗｎｅｄ（所有されている）”であるかどうかに依存し
て、ＲｅａｄＢｌｏｃｋがキャッシュ・リクエスタによ
って呼ばれる。所有されているデータ・ブロック（即ち
、局部的に初期化された書き込み−即ち、メモリ・ツリ
ーの同じブランチにおけるプロセッサによって初期化さ
れた書き込み−によって最近に修正されたデータのブロ
ック）をメイン・メモリ１３に対して書き戻すために、
ＦｌｕｓｈＢｌｏｃｋがキャッシュ・リクエスタによっ
て呼ばれることができる。そして、ＷｒｉｔｅＢｌｏｃ
ｋは、任意の中間的なレベルのキャッシュ１９ａ−１９
ｉおよびトランザクションに対して特定されるアドレス
上で合致する任意の第１のレベルのキャッシュ１６ａａ
−１６ａｊ（図１を参照）に対するのと同様に、データ
・ブロックをメイン・メモリ１３に対して直接書き込む
ために、２次的なデータ源（即ち、メモリ・システムに
対して外部にあるデータ・プロデューサ）を可能化する
ために利用できるものである。換言すれば、このＷｒｉ
ｔｅＢｌｏｃｋで許容されることは、キャッシュを通し
てデータを迂回させることなく、新規なデータをマルチ
プロセッサ１１の主要なメモリ・システムに導入するこ
とである。 【００５６】これらの“ブロック”トランザクションの
全ては、物理的なアドレス空間に直列に整列している４
個の６４−ビット・ワードのような、複数個の連続的な
ワードにわたっている。そのために、任意のこのような
データ・ブロック内の第１の個別にアドレス可能な量の
アドレスは０　　ｍｏｄ　　Ｎであり、ここに、Ｎは各
データ・ブロックに含まれている個別にアドレス可能な
量の個数である。有利なことに、各バス上での全てのデ
ータ・ブロックの転送の組成は、アドレスされた量がバ
ス上の第１のデータ・サイクル内に現れ、データ・ブロ
ックの残りの量がサイクリックな順序でこれに追従する
ようにされていることである。図１１を参照されたい。 これにより、特定されたアドレスからデータを検索する
ためのメモリの待機が最小にされるが、これはキャッシ
ュ“ミス”のときには特に望ましいことである。 【００５７】ＷｒｉｔｅＳｉｎｇｌｅトランザクション
は、共有しているデータについて多くのキャッシュされ
たコピーを更新するために、必ずしもメイン・メモリ１
３に影響をおよぼすことなく、キャッシュ・リクエスタ
によって呼ばれる。このトランザクションは、影響のあ
るデータ・ブロックのコピーを含んでいるキャッシュに
よってのみ呼ばれるものである。Ｃｏｎｄｉｔｉｏｎａ
ｌＷｒｉｔｅＳｉｎｇｌｅは、このように共有されてい
るデータに対して微細な読み取り−修正−書き込みの実
行をするために、キャッシュ・リクエスタによって呼ぶ
ことができる、密接な関連のあるオプション的なトラン
ザクションである。 【００５８】２．　　Ｉ／Ｏ　　トランザクションＩ／
Ｏトランザクションによれば、図１におけるＬＡＮコン
トローラ２９ｉのようなＩ／Ｏデバイスとの間で、プロ
セッサがデータの転送をすることが許容される。これら
のＩ／Ｏトランザクションのために採用されるアドレス
空間（即ち、“Ｉ／Ｏ空間”）は、全体としては、メモ
リ・トランザクションのために使用されるアドレス空間
（即ち、“メモリ空間”）とは関連しておらず、このた
めに、ある所与の有効なアドレスがメモリ空間またはＩ
／Ｏ空間のいずれかに存在するけれども、その双方に存
在することはない。ここで認められるように、Ｉ／Ｏト
ランザクションはデータの両立性についての関連を持た
ず、また、データ両立性プロトコルはＩ／Ｏトランザク
ションについての関連を持たないものである。 【００５９】ＩＯＲｅａｄ，ＩＯＷｒｉｔｅおよびＢＩ
ＯＷｒｉｔｅトランザクションは、この実施例において
、Ｉ／Ｏ動作を実行するために規定されたものである。 各Ｉ／Ｏデバイスは共通のアドレス空間の固有の部分が
指定されており、これらのトランザクションは該当のア
ドレス空間に対して発せられる。このために、図１にお
けるコントローラ２９ｉのようなＩ／Ｏデバイスは、そ
れらに対してアドレスされるＩ／Ｏコマンドを解釈する
ことが自由であり、所要に応じて、それらを所望のトラ
ンザクションに対して効率的に関与させることができる
。ＩＯＲｅａｄトランザクションおよびＩＯＷｒｉｔｅ
トランザクションは、キャッシュ・リクエスタにより起
動されて、それぞれに、特定されたＩ／Ｏアドレスとの
間でアドレス可能な量の読み取りおよび書き込みをする
ようにされる。ＢＩＯＷｒｉｔｅもキャッシュ起動式の
トランザクションであって、Ｉ／Ｏアドレス空間に対し
て単一のアドレス可能な量を書き込むためのものである
が、ある所与の“デバイス・タイプ”の多くの事例に対
してデータを同時に書き込むことが許容されているため
に、Ｉ／ＯＷｒｉｔｅトランザクションとは異なるもの
である。このために、ＢＩＯＷｒｉｔｅは無制限のグロ
ーバルな放送的トランザクションではないけれども、あ
る所与のタイプの全てのデバイスに対しては放送的なも
のである。“デバイス・タイプ”の規定はシステムに依
存するものであり、この発明の範囲を超えている。 【００６０】図１の１８ｉにおいて示されているＩ／Ｏ
ブリッジに移行して理解されるべきことは、メモリ・シ
ステムに関する限りはそれがハイブリッド・デバイスで
あるということである。より詳細にいえば、このＩ／Ｏ
ブリッジ・デバイス１８ｉは、キャッシュ１６ａａ−１
６ｉｊと機能的に類似のキャッシュ６０を介してマルチ
プロセッサ１１のメモリ・システムに直接アクセスする
、外部系列のコンピュータ・システムのメモリ・バスの
ような、非同期的なＩ／Ｏデバイスを備えるために有用
なものである。その目的のためにブリッジ１８ｉに含ま
れているもの（図示されない）は、このようなＩ／Ｏデ
バイスによって出されたメモリの読み取りおよび書き込
みをバッファリングするための、そして、それらの読み
取りおよび書き込みを規定のメモリ・トランザクション
に変換するためのものである。しかしながら、それはＩ
／Ｏ空間の部分内のＩ／Ｏトランザクションにも応答す
るものであるが、その意味するところは、プロセッサ１
２ａａ−１２ｉｊがＩ／Ｏブリッジ１８ｉの内部資源お
よび該ブリッジ１８ｉが接続されるＩ／Ｏデバイスのレ
ジスタをアクセスできることである。 【００６１】Ｉ／Ｏアドレス空間の指定は通常のことで
はないが、その理由は、マルチプロセッサ１１のいずれ
かのバスに接続され得る異なるＩ／Ｏデバイスについて
のＩ／Ｏアドレス空間のサイズに関する要求が相当に異
なっていることにあるだけである。従って、実際的な態
様としては、各Ｉ／Ｏデバイスに対するＩ／Ｏアドレス
空間の指定が該デバイスにとって必要であるようなアド
レス空間と合理的に近似することが確実であるように、
Ｉ／Ｏアドレス空間を指定するときにこれらの差異を考
慮に入れるべきである。 【００６２】３．　　多面的トランザクションＭａｐお
よびＤｅＭａｐはキャッシュで呼ばれるトランザクショ
ンであって、マルチプロセッサ１１の仮想メモリ環境に
おいて高速の仮想的−物理的アドレス空間のマッピング
を実行するためのものである。その目的のために、Ｍａ
ｐでキャッシュ・リクエスタが許容されることは、図１
の１７ａにおけるようなマップ・キャッシュから、仮想
的ページ−物理的ページのマッピング・エントリを読み
取ることである。これに対して、ＤｅＭａｐによれば、
仮想的なアドレス空間の任意特定のページに対するキャ
ッシュ駐在の仮想的−物理的アドレス・マップを無効に
するために、キャッシュ・リクエスタが可能にされる。 【００６３】Ｆ．　　データの両立性 全てのバス・クライエントに対する共有メモリのマルチ
プロセッサ環境において必須であることは、メモリ空間
における任意の所与のアドレスに対するデータ値を同じ
シーケンスでアクセスすることである。これは“データ
の両立性”として参照される。このようなマルチプロセ
ッサにおける個別のプロセッサに対して分離したキャッ
シュ・メモリを用いることは、このデータの両立性を維
持するという問題を複雑にするものであり、特に、より
大規模なシステムにおいて、任意の所与の時点において
キャッシュ内に存在し得るある所与のコピーの潜在的な
個数が大きいときに問題を複雑にするものである。 【００６４】しかしながら、特に効果的なデータの両立
性のプロトコルを実施することは、プロセッサ１２ａａ
−１２ｉｊおよびＩ／Ｏブリッジ１８ｉによって要求さ
れるメモリ・トランザクションの開始および実行をする
ために、いわゆる書き戻しキャッシュ（即ち、メイン・
メモリを即座に更新することなく、プロセッサによって
出されたデータの書き込みに従ってキャッシュされたデ
ータの更新をするキャッシュ）を用いることによって可
能にされる。これらのキャッシュは、メモリ空間におけ
る全てのアドレスからの要求に応じてデータのフェッチ
および記憶をすることができるが、その理由は、メモリ
空間内の任意の所与のアドレスにおけるデータの多くの
コピーの外部的な両立性が、上述されたトランザクショ
ンのある所定のものの使用を通して、ハードウエアによ
って自動的かつ透明的に維持されるためである。更に、
プロセッサ１２ａａ−１２ｉｊおよびＩ／Ｏブリッジ１
８ｉに対するメモリの両立性のある観察を維持しながら
、Ｉ／Ｏデバイスによるメモリ空間に対する直接アクセ
スが許容される。 【００６５】より詳細には、更に詳述されるように、キ
ャッシュ１２ａａ−１２ｉｊ，１９ａ−１９ｉ，６０は
、それぞれのバス上のトラフィックを直接または間接に
モニタすることによってデータが共有されるようになっ
た時点を検出し、また、任意のプロセッサ（またはＩ／
Ｏブリッジ１８ｉ）がメモリ空間における共有のデータ
値を更新したときには、いつでも放送的な書き込みを実
行する。キャッシュ１２ａａ−１２ｉｊおよび６０の全
ては“スヌーピー・キャッシュ”であるが、これの意味
することは、それらがバス上の全てのトランザクション
をモニタすることにある。 【００６６】１．　　シングル・レベル・システムにお
けるデータの両立性 先に指摘されたように、シングル・レベル・システムを
構成する１個または複数個のプロセッサは、図１におけ
るプロセッサ１２ａａ−１２ａｊのようなものであって
、共有のメイン・メモリとともに、それぞれのキャッシ
ュ１６ａａ−１６ａｊを介して、それらのメモリ・バス
１５ａと接続されている。プロセッサ１２ａａ−１２ａ
ｊは、それぞれに、それらのキャッシュ１６ａａ−１６
ａｊを介してメイン・メモリをアクセスしていることか
ら、任意の所与のアドレスにおける全てのキャッシュさ
れたコピーの間のデータの両立性を維持することで十分
であることが明かにされてくる。これの意味することは
、キャッシュされているメイン・メモリのコピーが、１
個または複数個のキャッシュされたコピーに関しては古
いことがあり得ることであるが、この古いメイン・メモ
リのデータに起因する演算上のエラーのリスクを負うこ
とはない。 【００６７】データの両立性を維持するために、両立性
プロトコルが依存する各キャッシュは、特定のキャッシ
ュの要求においてバス上で係属しているトランザクショ
ンに従う任意のデータ・ブロックに対するｐｅｎｄｉｎ
ｇＳｔａｔｅとともに、キャッシュしている各データ・
ブロックに対する“共有”および“固有”の２個の状態
ビットを保持している。これに加えて、通常は、キャッ
シュ１６ａａ−１６ａｊは、現にキャッシュされている
データ・ブロックと、オーバライト可能な削除された、
または、“空白の”データ・ブロックとの間の区別をす
るために、それらのデータ・ブロックの各々に対する“
有効”状態ビットを保持している。 【００６８】共有ビットの状態で指示されることは、関
連のデータ・ブロックについて多くのキャッシュされた
コピーが存在し得るか否かということである。多くのキ
ャッシュされたコピーが存在するときには、該共有ビッ
トは真の（“１”の）状態に肯定的にセットされるが、
キャッシュされたコピーが１個しか存在しないときには
、必ずしも偽の（“０”の）状態にはリセットされない
ことから、これは控え目な指示である。これに対して、
ある所与のキャッシュを介して通信するプロセッサその
他のデバイスが、特定のデータ・ブロックに対する最近
の（即ち、最後の）書き込みを実行する責任があったと
きにのみ、該データ・ブロックに対する固有ビットが該
所与のキャッシュにおいて真の（“１”の）状態にセッ
トされる。これの意味することは、バス上の１個または
複数個の他のキャッシュも同じデータ・ブロックのコピ
ーを含んでいるとしても、任意の所与のバス上での任意
の時点におけるある所与のデータ・ブロックについて、
“固有”のキャッシュは１個だけということである。こ
れに加えて、バス上で係属している各トランザクション
に対してキャッシュが維持するｐｅｎｄｉｎｇＳｔａｔ
ｅによってキャッシュにできることは、トランザクショ
ンがまだ係属中であるときに該当のデータ・ブロックの
キャッシュされたコピーの個数が変化するとしても、リ
プライが受け入れられたときに、トランザクションが関
連しているデータ・ブロックに対するその共有ビットの
ための値を正確に演算することができる。このｐｅｎｄ
ｉｎｇＳｔａｔｅの情報によってキャッシュにできるこ
とは、より十分に後述されるように、該当のトランザク
ションに対する正確なデータ値を得るべく、キャッシュ
が適切な動作をするように、その係属中のトランザクシ
ョンによって特定されるアドレスにおけるデータの値を
修正できる介在のトランザクションを同定することでも
ある。 【００６９】一般的なルールとして、その関連のプロセ
ッサがフェッチ・コマンドまたは記憶コマンドを発生し
たときには（即ち、このようなコマンドが発生されるべ
きアドレスがキャッシュ内に存在しないときには）、第
１のレベルのキャッシュでＲｅａｄＢｌｏｃｋＲｅｑｕ
ｅｓｔが起動して、“キャッシュ・ミス”が生じるよう
にする。必要であるときには、キャッシュからメイン・
メモリにデータを書き込み、これによって新規なデータ
を記憶するためのキャッシュ内の記憶スペースを自由に
するように、このキャッシュもＦｌｕｓｈＢｌｏｃｋを
起動させることができる（ここで想起されるように、古
いデータをメイン・メモリに書き込むことを回避するた
めに、それらの固有ビットのセットを有するデータ・ブ
ロックだけがＦｌｕｓｈＢｌｏｃｋによって書き出され
ることになる）。共有ビットのセット（“１”）を有す
るデータ・ブロックに対して関連のあるプロセッサによ
る書き込みがなされるときには、更にキャッシュによっ
てＷｒｉｔｅＳｉｎｇｌｅトランザクション（これは前
述された書き込みであって、データの両立性が無視でき
るときには、必要とされる最小のセットの動作から両立
性プロトコルを区別することである）が始められる。 【００７０】リクエスタを含んでいる全てのキャッシュ
は、ＲＢＲｑｓｔ，ＷＳＲｑｓｔ，ＷＳＲｐｌｙ，ＣＷ
ＳＲｑｓｔ，ＣＷＳＲｐｌｙ，およびＷＢＲｑｓｔパケ
ット（即ち、特定されたアドレスにおけるデータの値お
よび／または非共有状態に影響があり得るパケット）の
いずれかのヘッダー・サイクルにおいて特定されるアド
レスに合致させようとする。その係属中のトランザクシ
ョンの各々に対してリクエスタが維持しているｐｅｎｄ
ｉｎｇＳｔａｔｅに含まれているデータのアドレスは、
リクエスタがその固有のリクエスト・パケットを受け入
れたときに偽の（“０”の）状態にクリアされる共有の
状態とともに、同じアドレスを特定する前述のタイプの
介在パケットをリクエスタが検出できるためのトランザ
クションに従うものである。これでリクエスタが可能に
されることは、トランザクションが係属中である間に特
定のデータ・ブロックが共有の状態になるときに、その
係属中のトランザクションに従う任意のデータ・ブロッ
クに対する共有の状態を真の（“１”の）状態にセット
することである。更に、ある程度詳細に付加的に後述さ
れるように、トランザクションが係属中である間に、デ
ータの値が、係属中のトランザクションが変化されるの
に従っているときには、リクエスタによって適当な訂正
動作をすることも可能にされる。 【００７１】リクエスタ以外の全てのキャッシュによっ
て簡単に合致されることは、上記のように列挙されたヘ
ッダー・サイクルにおいて特定されたアドレスを、それ
らがキャッシュしているデータ・ブロックのアドレスに
対抗させて、該特定のアドレスが含まれているかどうか
を決定するためである。ＦｌｕｓｈＢｌｏｃｋトランザ
クションは、そのような動作がなされている他のキャッ
シュに対して告知をすることを必要とせずに、キャッシ
ュからメイン・メモリへのデータ・ブロックの書き込み
だけのために使用されるものであることから、このよう
な合致操作はＦＢＲｑｓｔパケットまたはＦＥＲｐｌｙ
パケットのいずれかのために必要とされることはない。 同様にして、メモリが対応のＷＢＲｑｓｔパケットを処
理したことを確認するだけであることから、ＷＢＲｐｌ
ｙに対するアドレスの合致操作は不要である。更に、Ｒ
ＢＲｐｌｙはリクエスタだけに関連するものであるから
、他のキャッシュはこのようなパケットを無視すること
ができる。 【００７２】ＲＢＲｑｓｔ，ＷＳＲｑｓｔまたはＣＷＳ
Ｒｑｓｔパケットのヘッダー・サイクルにおいて特定さ
れるアドレスと好都合に合致しているリクエスタを除く
各キャッシュは、そのバス・インタフェース４１（図６
）の両立性ポートにおけるＳｈａｒｅｄＯｕｔの主張を
し、これによって、該当する特定のアドレスにおけるデ
ータ・ブロックが共有されていることの信号をする。 このようなキャッシュも、先にそのようにセットされて
いないときには、該特定されたデータ・ブロックのその
コピーに対する共有ビットを真の（“１”の）状態にセ
ットする。ここで想起されるように、全てのリクエスト
・パケットおよびリプライ・パケットのヘッダーはＤｅ
ｖｉｃｅＩＤ（図９および図１０を参照）を備えていて
、それらが任意の所与のパケットに対するリクエスタで
あるか否かについて、バス・クライエントで決定するこ
とが可能にされる。 【００７３】ここで認められるように、バス上の任意の
キャッシュによるＳｈａｒｅｄＯｕｔの主張は、データ
・ブロックのキャッシュ・オーナまたはメイン・メモリ
１３（キャッシュ・オーナが存在しないとき）によって
リプライが付与されるかどうかには拘らず、対応するリ
プライ・パケットのヘッダー・サイクルにおけるｒｅｐ
ｌｙＳｈａｒｅｄビットを真の（“１”の）状態にセッ
トさせるのに十分なものである。これは次の事実に従う
ものである。即ち、キャッシュからのＳｈａｒｅｄＯｕ
ｔ信号は（図示されない手段により）論理的にＯＲがと
られ、共有ライン６１（図１２）を介して、全てのバス
・クライエント・インタフェース４１の両立性ポートに
加えられるＳｈａｒｅｄＩｎ信号の値を完成するように
される。 【００７４】これに対して、リクエスタは、その係属す
るトランザクションに対するリプライのヘッダー・サイ
クルにおいて受け入れるｒｅｐｌｙＳｈａｒｅｄビット
と、該トランザクションのためにそのｐｅｎｄｉｎｇＳ
ｔａｔｅにおいて維持される共有ビットとのＯＲをとる
ようにされる。このために、リクエスタがそのリクエス
ト・パケットを発したときにデータ・ブロックが他のキ
ャッシュ内に存在しているとき、または、リクエスタが
そのリプライを待機している間にデータ・ブロックが他
のキャッシュ内にコピーされたときのいずれかであると
きには、特定されたデータ・ブロックのそのコピーに対
するリクエスタの共有ビットは、そのリプライを受け入
れたときに真に（“１”に）セットされる。 【００７５】ＷＳＲｑｓｔまたはＣＷＳＲｑｓｔを発す
るリクエスタはデータ・ブロックのそのコピーに対する
その共有ビットのセットまたはリセットをする。このデ
ータ・ブロックに関連するトランザクションは、それを
受け入れる対応のリプライ・パケット（図１０参照）の
ヘッダー・サイクルにおけるｒｅｐｌｙＳｈａｒｅｄビ
ットの状態、および、該当のリプライが受け入れられる
ときのそのｐｅｎｄｉｎｇＳｔａｔｅの共有状態に依存
するものである。リプライのヘッダーにおけるｒｅｐｌ
ｙＳｈａｒｅｄビットが偽の（“０”の）状態にあると
き、および、該トランザクションに対するそのｐｅｎｄ
ｉｎｇＳｔａｔｅにおける共有状態が偽（“０”）であ
るときの双方であるときには、その書き込みがなされて
いるデータ・ブロックのコピーが他のキャッシュには含
まれていないことが、リクエスタによって確認される。 従って、リクエスタはこれに次いで特定のデータ・ブロ
ックに対するその共有ビットを偽の（“０”の）状態に
リセットし、これによって、データ・ブロックの状態が
共有状態から非共有状態に変更されるときに、該共有ビ
ットが最終的に確実にリセットするようにされる。 【００７６】記憶されているデータ・ブロックに対して
キャッシュが維持しているオーナ・ビットの扱いは更に
簡単なことである。これを略述すれば、そのプロセッサ
の側でデータ・ブロックへの書き込みがなされるときは
いつでも、キャッシュにおいて、データ・ブロックに対
するそのオーナ・ビットのセットがなされる。これに対
して、キャッシュにおいては、データ・ブロックに含ま
れているアドレスのために、任意の他のキャッシュによ
って要求されるＷｒｉｔｅＳｉｎｇｌｅまたはＣｏｎｄ
ｉｔｉｏｎａｌＷｒｉｔｅＳｉｎｇｌｅトランザクショ
ンに対するＷＳＲｐｌｙまたはＣＷＳＲｐｌｙにおける
特定のアドレスで、該キャッシュをして好都合に合致す
るようにさせるときにはいつでも、データ・ブロックに
対するそのオーナ・ビットのリセット（クリア）がなさ
れる。データ両立性のプロトコルに関する限り、Ｗｒｉ
ｔｅＳｉｎｇｌｅおよびＣｏｎｄｉｔｉｏｎａｌＷｒｉ
ｔｅＳｉｎｇｌｅは完全に等価のものであるから、ここ
で理解されるべきことは、共有ビットおよびオーナ・ビ
ットに対するＷｒｉｔｅＳｉｎｇｌｅトランザクション
の効果についての以下の説明は、Ｃｏｎｄｉｔｉｏｎａ
ｌＷｒｉｔｅＳｉｎｇｌｅに対して良好に当てはまるも
のである。 【００７７】先に指摘されたように、プロセッサによれ
ば、それぞれのキャッシュ内に存在するデータ・ブロッ
クにデータを書き込むことにより、共有メモリ・システ
ムへのデータの記憶がなされる。データ・ブロックに対
する共有ビットが偽の（“０”の）論理レベルにある間
に、関連のキャッシュ内に存在するデータ・ブロックの
一つのワードまたはアドレス可能な量の一つにおいて、
ある所与のデータ値を記憶させるための記憶コマンドが
プロセッサから発せられたときには、該プロセッサは即
座にキャッシュされたデータ・ブロックの適切な部位（
例えば、ワード）の更新を行い、これと同時に、該当の
データ・ブロックに対するオーナ・ビットのセットをす
る。これに対して、プロセッサによる記憶コマンドが指
向されるデータ・ブロックに対する共有ビットが真の（
“１”の）論理レベルにセットされたときには、該キャ
ッシュは記憶コマンドの実行を留保してＷＳＲｑｓｔパ
ケットを発する。このＷＳＲｑｓｔパケットによれば、
（ａ）該プロセッサがその記憶コマンドに指向した物理
的アドレス（この物理的アドレスは典型的にはプロセッ
サによって付与された仮想的アドレスの変換によって規
定される）が同定され、また、（ｂ）該プロセッサによ
って生成されたデータ値を含むようにされる。 【００７８】全てのＷＳＲｐｌｙパケットは、単一レベ
ル・システムにおけるメモリ・コントローラからのもの
である。更に、１個のＷＳＲｐｌｙパケットは、対応す
るＷＳＲｑｓｔパケットの物理的アドレスおよびデータ
値の双方を写しているものである。このために、そのＷ
ＳＲｐｌｙパケットを受け入れると、キャッシュ・リク
エスタは、そのプロセッサに対するデータの記憶を実行
するだけではなく、該プロセッサのデータが真の（“１
”の）状態に書き込まれるデータ・ブロックに対するそ
のオーナ・ビットのセットも実行する。このＷＳＲｐｌ
ｙパケットのヘッダー・サイクルにおいて特定されるア
ドレス上で合致する他のキャッシュのいずれであっても
、（ａ）リプライ・パケットによって与えられるデータ
値に基づいてアドレスされる、該リプライ・パケットに
対するそれらのデータのコピーを更新し、また、（ｂ）
偽の（“０”の）状態に更新されたデータ・ブロックに
対するそれらのオーナ・ビットをリセットするようにさ
れる。ここで認められるように、これで確実にされるこ
とは、任意の所与のバス・サイクルの間に、いずれのキ
ャッシュであっても任意の所与のデータ・ブロックにつ
いての所有権を主張できないということである。 これの意味することは、メイン・メモリから読み取られ
てから書き込みがなされていない、いずれのキャッシュ
されたデータ・ブロックについて、いずれのキャッシュ
による所有権の主張もなされないということである。 【００７９】前述のことに鑑みて理解されることは、キ
ャッシュ・リクエスタがある特定のアドレスにおいてデ
ータ・ブロックに対するそのバス上にＲＢＲｑｓｔパケ
ットを生成させたときには、該データ・ブロックは該バ
ス上での他のキャッシュに固有のものになったり、なら
なかったりできるということである。しかしながら、他
のキャッシュの一つが特定のデータ・ブロックを固有の
ものにしているときには、そのオーナ（および、恐らく
は１個または複数個の他のキャッシュの）はそのアドレ
ス上で合致するようにされて、これにより、それらの各
々がＳｈａｒｅｄＯｕｔを主張するようにされる。更に
、このオーナはＯｗｎｅｒＯｕｔの主張も行い、これに
よりＯｗｎｅｒＯｕｔ信号の論理的ＯＲをとるようにも
されて、ＯｗｎｅｒＩｎライン６２（図１２）を真の（
“１”の）状態に駆動するようにされる。ＯｗｎｅｒＩ
ｎ信号の真の（“１”の）状態により、メイン・メモリ
がＲＢＲｑｓｔに応答することが防止されて、対応のＲ
ＢＲｐｌｙパケットを供給するための責任が特定のデー
タ・ブロックについてのキャッシュ・オーナに転嫁され
る。これに対して、キャッシュのいずれも該特定のデー
タ・ブロックの所有権を主張しないときには（即ち、Ｏ
ｗｎｅｒＩｎ信号が偽（“０”）であるときには）、該
データ・ブロックが共有されているものであっても、メ
イン・メモリからＲＢＲｐｌｙが供給される。 【００８０】前述されたように、パケットによるバスの
切り換えで生成されるリスクは、データ・ブロックの所
有権の変化がなされるのは、リクエスタがＲＢＲｑｓｔ
を発した後であるが、対応のＲＢＲｐｌｙを受け入れる
前であるということである。例えば、リクエストが発せ
られる時点においてメイン・メモリに固有のものである
データ・ブロックに対して、キャッシュはＲＢＲｑｓｔ
を発することができる。しかしながら、僅かな時間だけ
早いときには、その同じデータ・ブロックに対して新規
なデータを書き込むために、他のいずれかのキャッシュ
がＷＳＲｑｓｔを発していることがある。ここでのリス
クは、リクエスト・パケットの到着順にメモリによるサ
ービスがなされるために、ＲＢＲｐｌｙパケットに先だ
って、ＷＳＲｐｌｙパケットがメモリによって発せられ
ることである。もし、これが生じたとすると、Ｗｒｉｔ
ｅＳｉｎｇｌｅトランザクションを開始させたキャッシ
ュが、該データ・ブロックのオーナになる。データ・ブ
ロックの所有権におけるこの介在的な変化にも拘らず、
そのようにできるときには、メイン・メモリ１３（図１
）はまだＲＢＲｐｌｙを供給することになる。これの理
由は、ＲＢＲｑｓｔが受け入れられたときに、特定のデ
ータ・ブロックについて、キャッシュ・オーナがその所
有権を主張する用意がなかったからである。これの意味
することは、このＲＢＲｑｓｔパケットによって付与さ
れたデータは古いということである。従って、古いデー
タの取り込みを回避するためには、リクエストされたデ
ータ・ブロックに対する正しい値を算出するため、また
は、その当初のＲＢＲｑｓｔに対するＲＢＲｐｌｙの受
け入れの後でのＲｅａｄＢｌｏｃｋの再試行を始めるた
めのいずれかのために、ＲｅａｄＢｌｏｃｋリクエスタ
においては、そのＲＢＲｑｓｔに対するｐｅｎｄｉｎｇ
Ｓｔａｔｅが用いられる。そのリクエストが古いデータ
の使用を避けるために係属している間に、ＲｅａｄＢｌ
ｏｃｋリクエスタが考慮に入れることを必要とするパケ
ットは、そのＲＢＲｑｓｔパケットがアドレスされるデ
ータ（ＷＳＲｐｌｙ、ＣＷＳＲｐｌｙおよびＷＢＲｑｓ
ｔ）を修正するためのものである。 【００８１】メモリ・システムに関する限り、Ｗｒｉｔ
ｅＢｌｏｃｋトランザクションはＦｌｕｓｈＢｌｏｃｋ
トランザクションに類似しているけれども、これと等価
のものではない。キャッシュはＦＢＲｑｓｔを無視する
けれども、ＷＢＲｑｓｔを無視することはない。これに
代えて、ＷＢＲｑｓｔによって特定されるアドレス上で
合致する任意のキャッシュにより、そのアドレスで合致
しているデータ・ブロックを、ＷＢＲｑｓｔパケットに
よって含まれているデータ・ブロックをもってオーバラ
イトされ、そして、該当のデータ・ブロックに対するそ
のオーナ・ビットを偽の（“０”の）状態にリセット（
クリア）するようにされる。 【００８２】一つの簡単な例により、単一レベルの両立
性プロトコルについての前述の説明に対して、ある種の
有用な見通しが付加される。ここで認められるように、
次に続く例において説明されることは、特定されたメモ
リ位置（アドレス７３）に対するイベントのシーケンス
であって、図１２に示されている共有メモリ・システム
８３における５個のキャッシュ８２ａ−８２ｅのいずれ
にも該当のアドレスが含まれていない状態から出発する
ようにされている。その便宜のために、この例において
用いられている参照数字は、図１２において用いられて
いる参照数字に対応している。 １．　　ａ．プロセッサ８１ａでアドレス７３を読み取
る。 ｂ．キャッシュ８２ａはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．メイン・メモリ８６でリクエストされたデータを付
与する。 ｄ．データ・ブロックのキャッシュされたコピーに対す
る状態ビットは：Ｓｈａｒｅｄ８２ａ　＝０，かつＯｗ
ｎｅｒ８２ａ　＝０である。 ２．　　ａ．プロセッサ８１ｂでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｂはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａはアドレス７３を含んでいるデー
タ・ブロックに対するそのＳｈａｒｅｄビットを真の（
“１”の）状態にセットし、また、ＳｈａｒｅｄＯｕｔ
を主張して、ある所定の遅れの後に、ＳｈａｒｅｄＩｎ
ライン６１が真の（“１”の）状態になるように駆動さ
れる。 ｄ．メモリ８６はまだデータを付与する。 ｅ．データ・ブロックのキャッシュされたコピーに対す
る状態ビットは：Ｓｈａｒｅｄ８２ａ　＝Ｓｈａｒｅｄ
８２ｂ　＝１；Ｏｗｎｅｒ８２ａ　＝Ｏｗｎｅｒ８２ｂ
　＝０である。 ３．　　ａ．プロセッサ８１ｃでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｃはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａおよびキャッシュ８２ｂはＳｈａ
ｒｅｄＯｕｔを主張して、これにより、ＳｈａｒｅｄＩ
ｎライン６１が再びハイ（“１”）になるように駆動さ
れる。 ｄ．メモリ８６はまだデータを付与する。 ｅ．データ・ブロックのキャッシュされたコピーに対す
る現在の状態ビットは：Ｓｈａｒｅｄ８２ａ　＝Ｓｈａ
ｒｅｄ８２ｂ　＝Ｓｈａｒｅｄ８２ｃ　＝１；Ｏｗｎｅ
ｒ８２ａ　＝Ｏｗｎｅｒ８２ｂ　＝Ｏｗｎｅｒ８２ｃ　
＝０である。 ４．　　ａ．プロセッサ８１ｃでアドレス７３を書き込
む。 ｂ．データが共有されていることから、キャッシュ８２
ｂがバス８５上でＷｒｉｔｅＳｉｎｇｌｅを実行する。 ｃ．キャッシュ８２ａおよびキャッシュ８２ｃはＳｈａ
ｒｅｄＯｕｔを主張して、これにより、ＳｈａｒｅｄＩ
ｎライン６１がハイ（“１”）に駆動される。 ｄ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはアドレス７３におけるそれらの値を更新す
るが、メモリ８６は実行しない。 ｅ．キャッシュ８２ｂはアドレス７３を含むデータ・ブ
ロックのオーナになる（Ｏｗｎｅｒ８２ｂ　＝１）が、
そうではないデータ・ブロックのキャッシュされたコピ
ーに対する共有状態ビットおよび固有状態ビットは変化
しない。 ５．　　ａ．プロセッサ８１ｄでアドレス７３を読み取
る。 ｂ．キャッシュ８２ｄはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはライン６１上のＳｈａｒｅｄＩｎに対する
ＳｈａｒｅｄＯｕｔを主張する。 ｄ．キャッシュ８２ｂはＯｗｎｅｒＯｕｔを主張し、こ
れにより、ある所定の遅れの後で、ＯｗｎｅｒＩｎのラ
イン６２を真の（“１”の）状態に駆動するようにされ
る。これにより、メイン・メモリ８６の応答が禁止され
る。これに代えて、データ・ブロックがそのオーナ・キ
ャッシュ８２ｂによって付与される。 ｅ．キャッシュ８２ｄはデータ・ブロックのそのコピー
を、Ｓｈａｒｅｄ８２ｄ　＝１，Ｏｗｎｅｒ８２ｄ　＝
０，としてマークする。そうではないデータ・ブロック
のキャッシュされたコピーに対する共有状態ビットおよ
び固有状態ビットは変化しない。 ６．　　ａ．プロセッサ８１ｄで現在のアドレス７３を
書き込む。 ｂ．データは共有されていることから、キャッシュ８２
ｄはバス８５上でＷｒｉｔｅＳｉｎｇｌｅを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂおよびキャッ
シュ８２ｃはＳｈａｒｅｄＯｕｔを主張して、Ｓｈａｒ
ｅｄＩｎのライン６１が再びハイ（“１”）に駆動され
る。 ｄ．アドレス７３を含むデータ・ブロックの所有権がキ
ャッシュ８２ｂからキャッシュ８２ｄに変化する（Ｏｗ
ｎｅｒ８２ｂ　＝０，Ｏｗｎｅｒ８２ｄ　＝１）。そう
ではないデータ・ブロックのキャッシュされたコピーに
対する共有状態ビットおよび固有状態ビットは変化しな
い。 ７．　　ａ．プロセッサ８１ｅでアドレス７３を書き込
む。 ｂ．キャッシュ８２ｅはミスして、バス８５上のＲｅａ
ｄＢｌｏｃｋを実行する。 ｃ．キャッシュ８２ａ，キャッシュ８２ｂ，キャッシュ
８２ｃ，およびキャッシュ８２ｄはＳｈａｒｅｄＯｕｔ
を主張して、これにより、前述された遅れの後で、Ｓｈ
ａｒｅｄＩｎライン６１が真の（“１”の）状態になる
ように駆動される。 ｄ．アドレス７３を含むデータ・ブロックの現在のオー
ナであるキャッシュ８２ｄはＯｗｎｅｒＯｕｔを主張し
、ＯｗｎｅｒＩｎライン６２をハイ（“１”）に駆動す
るようにされて、メモリ８６はそれを行うためのデータ
を供給することが禁止される。 ｅ．キャッシュ８２ｅはデータ・ブロックのそのコピー
に対するその状態ビットを、Ｓｈａｒｅｄ８２ｅ　＝１
，Ｏｗｎｅｒ８２ｅ　＝０としてマークする。 ｆ．次いで、データが共有されていることから、キャッ
シュ８２ｅはアドレス７３に対してＷｒｉｔｅＳｉｎｇ
ｌｅを実行する。 ｇ．キャッシュ８２ａ，キャッシュ８２ｂ，キャッシュ
８２ｃ，およびキャッシュ８２ｅはＳｈａｒｅｄＯｕｔ
を主張し、これによりＳｈａｒｅｄＩｎライン６１を駆
動して、ＷＳＲｐｌｙのヘッダーにおけるｒｅｐｌｙＳ
ｈａｒｅｄビットをして、真の（“１”の）状態にセッ
トさせる。 ｈ．アドレス７３を含んでいるデータ・ブロックの所有
権が、キャッシュ８２ｄからキャッシュ８２ｅにスイッ
チする（Ｏｗｎｅｒ８２ｄ　＝０，Ｏｗｎｅｒ８２ｅ　
＝１）。 そうでないときには、データ・ブロックのキャッシュさ
れたコピーに対する共有および固有状態ビットは変更さ
れずに留まる。 【００８３】２．　　マルチレベル・システムにおける
データの両立性 ここで想起されるように、１個の２レベルのメモリ・シ
ステムは、“クラスタ”と呼ばれており、それぞれに第
２レベルのキャッシュ１９ａ−１９ｉを介してメイン・
バス（グローバル・バス）２６に接続されているような
、複数個の１レベルのメモリ・システム１４ａ−１４ｉ
（図１）からなるものである。これを換言すれば、各ク
ラスタに含まれている単一の第２レベルのキャッシュは
、この第２レベルのキャッシュをクラスタ内の第１レベ
ルのキャッシュに接続させるプライベート・バスととも
に、該クラスタをグローバル・バス２６に接続させるも
のである。このプライベートなクラスタに対するバスは
、電気的にも論理的にも、他のクラスタ・バスおよびグ
ローバル・バスから区別されるものである。メイン・メ
モリ１３はグローバル・バス２６に接続されている。 【００８４】このようなメモリ・システムのクラスタ・
バスのレベルにおいては、第２レベルのキャッシュがメ
イン・メモリの機能的な属性を有している。これに対し
て、グローバル・バスのレベルにおいては、該第２レベ
ルのキャッシュは、単一レベルのシステムにおけるキャ
ッシュと本質的に同じ態様の機能を果している。ここで
認められるように、バス・プロトコルおよびデータの両
立性のプロトコルの設計により、１レベルまたはマルチ
レベルのメモリ・システムとして動作しているかどうか
について、該第１レベルのキャッシュが見出すことを妨
げるような動作をするようにされる。これを換言すれば
、第１レベルのキャッシュがそれらの環境から受け入れ
る応答は、双方の場合において同じである。このために
、１レベルのメモリ・システムに対するデータの両立性
のプロトコルについての前述の説明は、マルチレベルの
システムのクラスタの各々に対して当てはまるものとし
て適切に説明されていることを注意すれば十分である。 【００８５】マルチレベルのシステムに対するデータ両
立性のプロトコルの拡張では、より高いレベルのキャッ
シュ１９ａ−１９ｉが、いわゆる“ｅｘｉｓｔｓＢｅｌ
ｏｗ”ビットに加えて、第１レベルのキャッシュが保持
している全ての状態ビット（ｓｈａｒｅｄＳｔａｔｅ，
ｏｗｎｅｒＳｔａｔｅおよびｐｅｎｄｉｎｇＳｔａｔｅ
）を維持することが必要とされる。これをより詳細にい
えば、より高いレベルのキャッシュの各々は、キャッシ
ュしている各データ・ブロックに対する１個のｅｘｉｓ
ｔｓＢｅｌｏｗビットを保持している。このｅｘｉｓｔ
ｓＢｅｌｏｗビットは、メモリ・ツリーの同じブランチ
における１個または複数個の次に低いレベルのキャッシ
ュが該当の特定のデータ・ブロックを有しているときに
のみ、より高いレベルのキャッシュ内の任意の所与のデ
ータ・ブロックに対して真の（“１”の）状態にセット
する。このために、例えば図１の２レベルのシステムに
おいては、第２レベルのキャッシュ１９ａ−１９ｉがグ
ローバル・バス２６上に現れるパケットのフィルタ操作
が該ｅｘｉｓｔｓＢｅｌｏｗビットにより可能にされて
、ある所与のクラスタ・バス１５ａ，・・・または１５
ｉ上にトラフィックを生成するグローバル・バスのトラ
フィックだけが、１個または複数個のクラスタ・バスの
クライエント・デバイスに関連するようにされる。ここ
で認められるように、このようなフィルタ操作をするこ
となく、グローバル・バス２６上の全てのトラフィック
が全てのクラスタ・バス１５ａ−１５ｉ上に現れ、これ
により、メモリ・システムの２レベルの組成についての
目的に勝るようにされる。 【００８６】クラスタ・バス上に現れるパケットがメイ
ン・バス（グローバル・バス）２６上のパケット・トラ
フィックとどのように関連しているのか、および、これ
とは逆のときにはどのように関連しているのかについて
の包括的な理解を付与するためには、キャッシュ１９ａ
のような第２レベルのキャッシュの一つの動作について
、ある程度詳細に考察することが有用である。 【００８７】第２レベルのキャッシュ１９ａがそのクラ
スタ・バス１５ａの上でリクエスタからのＲＢＲｑｓｔ
を受け入れたときには、該第２レベルのキャッシュ１９
ａは、ＲＢＲｑｓｔによって特定されるデータ・ブロッ
クのコピーを含むこともあり、含まないこともある。そ
れがコピーを有しているときには、リプライ・パケット
におけるｒｅｐｌｙＳｈａｒｅｄビットを次のように論
理的なＯＲにされたＳｈａｒｅｄＩｎの値に対してセッ
トした後で、該第２レベルのキャッシュはＲＢＲｐｌｙ
を介してリクエスタにデータを戻す。即ち、（ａ）ＲＢ
Ｒｑｓｔの結果として第１レベルのキャッシュから受け
入れられるＳｈａｒｅｄＯｕｔ信号、および、（ｂ）特
定されたデータ・ブロックに対するその共有ビットの現
在の値について、論理的にＯＲにされたＳｈａｒｅｄＩ
ｎの値に対してリプライ・パケットにおけるｒｅｐｌｙ
Ｓｈａｒｅｄビットをセットした後で、該第２レベルの
キャッシュはＲＢＲｐｌｙを介してリクエスタにデータ
を戻す（ここで想起されるように、単一レベルのシステ
ムにおいては、リクエスタからＲＢＲｑｓｔが受け入れ
られてからある固定的な時間後に、メイン・メモリ・コ
ントローラ２５がＳｈａｒｅｄＩｎライン６１上のＳｈ
ａｒｅｄＩｎ信号のレベルを評価して、リクエスタに対
して戻されるＲＢＲｐｌｙパケットに対するヘッダーの
ｒｅｐｌｙＳｈａｒｅｄビットに対して、当該評価され
た信号のレベルをコピーするようにされる）。 【００８８】これに対して、第２レベルのキャッシュ１
９ａがそのクラスタ・バスのリクエスタによって特定さ
れるデータ・ブロックのコピーを有していないときには
、この第２レベルのキャッシュ１９ａはグローバル・バ
ス上にＲＢＲｑｓｔパケットを発生させる。このリクエ
ストに対するＲＢＲｐｌｙの戻りにより、該第２レベル
のキャッシュは新規なデータ・ブロックをもって自己の
更新を行い、この新規なデータ・ブロックに対するその
共有ビットの値を算出するためにそのＲＢＲｑｓｔに対
するそのｐｅｎｄｉｎｇＳｔａｔｅを使用し、そして、
クラスタ・バス１５ａ上にＲＢＲｐｌｙを生成させるこ
とによる応答をする。 【００８９】キャッシュ１９ａのような第２レベルのキ
ャッシュがそのクラスタ・バス上でリクエスタからのＷ
ＳＲｑｓｔを受け入れたときには、該ＷＳＲｑｓｔによ
って特定されたアドレスを含むデータ・ブロックに対す
るその共有ビットがセットされているかどうかを定める
ために、該キャッシュ１９ａでチェックされる。当該特
定のデータ・ブロックに対する共有ビットがセットされ
ていないときには、該第２レベルのキャッシュ１９ａは
ＷＳＲｑｓｔデータに従ってデータの更新を行い、この
更新されたデータに対するその固有ビットのセットをし
、そして、そのクラスタ・バスを介して（適切な時点に
おいて、ＳｈａｒｅｄＩｎライン６１の値におけるｒｅ
ｐｌｙＳｈａｒｅｄビットをもって）ＷＳＲｐｌｙを生
成させる。これに対して、第２レベルのキャッシュ１９
ａが真の状態（“１”）に対してセットされたＷＳＲｑ
ｓｔに従うデータ・ブロックに対するその共有ビットを
有しているときには、グローバル・バス２６上にＷＳＲ
ｑｓｔを生成させることにより、クラスタ・レベルのリ
クエスタのＷＳＲｑｓｔを伝播させる。メイン・メモリ
・コントローラ２５は、ある所定の時間遅れの後に、Ｗ
ＳＲｐｌｙを付与することによってこのグローバル・レ
ベルのリクエストに応答する。このリプライが受け入れ
られたときには、該第２レベルのキャッシュ１９ａはＷ
ＳＲｑｓｔによって付与されたデータのＷＳＲｐｌｙの
反映に従ってデータ・ブロックのそのコピーを更新し、
該データ・ブロックのそのコピーに対するその固有ビッ
トをセットし、そして、そのクラスタ・バス上に（グロ
ーバル・バス２６を介して受け入れられたＷＳＲｐｌｙ
におけるｒｅｐｌｙＳｈａｒｅｄビットの値、および、
クラスタ・バス上の当初のＷＳＲｑｓｔに対応するＳｈ
ａｒｅｄＩｎライン６１の値の論理的なＯＲに対するこ
のクラスタ・レベルのＷＳＲｐｌｙのセットのヘッダー
・サイクルにおけるｒｅｐｌｙＳｈａｒｅｄビットをも
って）ＷＳＲｐｌｙを生成させる。 【００９０】各第２レベルのキャッシュは、グローバル
・バス２６上のＲＢＲｑｓｔパケットをモニタして、ア
ドレスの合致がなされているＲＢＲｑｓｔの同定をする
。このようなアドレスの合致が生じたときには、キャッ
シュ１９ａのような第２レベルのキャッシュは、特定さ
れたデータ・ブロックのそのコピーに対する固有ビット
およびｅｘｉｓｔｓＢｅｌｏｗビットのチェックをする
。当該特定のデータ・ブロックに対するその固有ビット
がセットされているときには、該キャッシュ１９ａはデ
ータについて応答するけれども、ＲＢＲｐｌｙパケット
がアセンブルされる態様は、そのｅｘｉｓｔｓＢｅｌｏ
ｗビットもセットされているか否かに依存することにな
る。これをより詳細にいえば、該ｅｘｉｓｔｓＢｅｌｏ
ｗビットがセットされているときには、キャッシュ１９
ａは初めにそのクラスタ・バス１９ａ上でＲＢＲｑｓｔ
を生成させて、特定されたデータ・ブロックの第１レベ
ルのキャッシュ・オーナから、グローバル・レベルのＲ
ＢＲｑｓｔによって呼ばれるデータを検索するようにさ
れる。しかしながら、該特定されたデータ・ブロックの
キャッシュ１９ａによるコピーに対するｅｘｉｓｔｓＢ
ｅｌｏｗビットがセットされていないときには、キャッ
シュ１９ａにはそのコピーが現在のものであるとして含
まれていることから、グローバル・レベルでのリクエス
タのＲＢＲｑｓｔを伝播させることなく、グローバル・
レベルでのＲＢＲｐｌｙに応答するようにされる。 【００９１】キャッシュ１９ａのような第２レベルのキ
ャッシュが、グローバル・バス２６上のＷＳＲｑｓｔに
おいて特定されたアドレスに合致しているときには、通
常のようにＳｈａｒｅｄＯｕｔが主張されるけれども、
他の動作をすることはない。しかしながら、キャッシュ
１９ａがグローバル・バス２６上のＷＳＲｐｌｙにおい
て特定されたアドレス上で合致しているときには、該当
のアドレスにおけるデータのそのコピーが更新される。 これに加えて、ＷＳＲｐｌｙによって特定されたアドレ
スを含むデータ・ブロックのそのコピーに対するｅｘｉ
ｓｔｓＢｅｌｏｗビットがセットされることが起きたと
きには、キャッシュ１９ａもそのクラスタ・バス１５ａ
上でＷＳＲｐｌｙを生成させる。ここで注目すべきこと
は、このＷＳＲｐｌｙパケットはクラスタ・バス上の対
応するＷＳＲｑｓｔパケットによって先行されるもので
はなく、バス上でのリクエスト・パケットの数とリプラ
イ・パケットの数とが等しくないのは別の理由によると
いうことである。 【００９２】ある第２レベルのキャッシュがそのクラス
タ・バスからＦＢＲｑｓｔを取得したときには、リクエ
ストがアドレスされるデータ・ブロックのそのコピーが
更新され、ＦＢＲｐｌｙが伝送されて、それぞれにリク
エスタに対して戻されるだけである。ＦｌｕｓｈＢｌｏ
ｃｋに対するレスポンダは、常に該レスポンダに対する
実際のまたは明白なメイン・メモリであるから、第２レ
ベルのキャッシュではグローバル・バス上の全てのＦＢ
Ｒｑｓｔが無視される。 【００９３】ここで想起されるように、ＷｒｉｔｅＢｌ
ｏｃｋトランザクションは、データを物理的なアドレス
空間に入力するために、２次的なデータ・プロデューサ
（メモリ・システムの外部にあるデータ源）による使用
のために有効なものである。該当の目的のために、この
トランザクションによれば、メイン・メモリに対して、
および、ＷＢＲｑｓｔにおいて特定されたアドレス上で
合致する任意のキャッシュに対して、サイクリックに順
序付けられたデータ・ブロックの書き込みがなされる。 マルチレベル・システムにおいては、ＷｒｉｔｅＢｌｏ
ｃｋトランザクションは、グローバル・バス・トランザ
クションとしての使用のために限定されることができる
。該当のイベントにおいて、ＷＢＲｑｓｔはグローバル
・バス２６とインタフェースされているデバイスによっ
てのみ生成される。そして、全てのＷＢＲｑｓｔはメイ
ン・メモリ１３によって供給される（ＷｒｉｔｅＢｌｏ
ｃｋについてのこの限定された適用に対するＷＢＲｐｌ
ｙには、不確定のサイクルによって追従される標準的な
リプライのヘッダー・サイクルが含まれている）。代替
的に、このＷｒｉｔｅＢｌｏｃｋトランザクションは、
より低いレベルのキャッシュがそれを呼ぶことが許容さ
れるように再規定することができる。そうであるときに
は、より低いレベルのローカル・キャッシュのいずれか
によって生成されたＷＢＲｑｓｔは第２レベルのキャッ
シュに渡され、これに次いで、該ＷＢＲｑｓｔをグロー
バル・バス２６上に配置するようにされる。ＷＢＲｐｌ
ｙを受け入れると書き込みが実行される。 【００９４】ここで認められるように、この実施例で必
要とされることは、第２レベルのキャッシュの各々には
、それらの下部でキャッシュされていた全てのデータ・
ブロックのコピーが維持されるということである。該当
の目的のために、該第２レベルのキャッシュ１９ａ−１
９ｉは、それぞれに、それらのそれぞれのクラスタ・バ
ス上で第１レベルのキャッシュの記憶容量の和に少なく
とも等しいデータの記憶容量を有するように選択される
。更に、第２レベルのキャッシュ１９ａ−１９ｉは、そ
れぞれに、それらのそれぞれのクラスタ・バス上で第１
レベルのキャッシュの連想性の和に少なくとも等しい連
想性の程度を有するように選択される。例えば、ある１
個のクラスタに４個の第レベルの直接にマッピングされ
たキャッシュ（即ち、１の程度の連想性を有するキャッ
シュ）が含まれているとすると、該当のクラスタに対す
る第２レベルのキャッシュは、そのクラスタ・バス上で
現れ得る任意のデータ・ブロックのアドレス上で確実に
合致できるように、少なくとも４の程度の連想性を有す
るように選択される。 【００９５】ＩＩ．増強された実施例 この発明のメモリ・システムは容易に拡張できるもので
あり、また、簡単に増強されるものであるから、修正お
よび改善のためのその可能性を例示するために、ある所
定の拡張および増強についての説明をする。その初めの
実施例の説明の構成をするために上記で使用されたと同
じ一般論的なアウトラインが追従されて、この増強され
た実施例に独特の特徴が属する事項を同定するようにさ
れる。 【００９６】Ａ．　　システム・アーキテクチュア所望
であるときには、多重のバスは並列に動作するようにイ
ンターリーブさせることが可能であり（図示されない）
、これによって、必要とされるバス・ワイヤの本数に比
例して増大する危険性を招きながら、使用可能なバスの
バンド幅を増大するようにされる。例えば、ある１個の
実施においては、ある所与のパケットが伝送されるイン
ターリーブしたバスを同定するために使用されるべきリ
クエスト・パケットおよびリプライ・パケット（それぞ
れに図１３および図１４を参照）に対するヘッダーのア
ドレス・フィールドにおけるビット８および９が許容さ
れる。このために、該当の実施においては、バス・アー
キテクチュアについての１−ウエイ、２−ウエイおよび
４−ウエイのインターリーブが許容される。 【００９７】Ｂ．　　デバイス・バス・インタフェース
図１５に示されているように、増強された実施例のため
の標準的なデバイス・バス・インタフェース１０１には
、幾つかの注目すべき修正が取り込まれている。その差
異のあるものは種々の信号を同定するために使用される
術語に関連しているが、他のものは相当に重要なことで
ある。インタフェース１０１の内部ロジックは図１６に
例示されている。図１６に示されているドライバ１０４
−１０９およびレシーバ１１１−１１７は、典型的には
オープン・ドレインのＣＭＯＳデバイスであって、前述
のＧｕｎｎｉｎｇの出願である出願番号第０７／５０２
，３７２号の教示を維持しているものである。 【００９８】１．　　信号 インタフェース１０１および図６のインタフェース４１
の信号ポート間に存在する実質的な区別については、こ
のセクションの以下のヘッディングの下にある程度詳細
に開示される。 【００９９】２．　　裁定インタフェースここで想起さ
れるように、この発明によるメモリ・システムの各バス
は、全ての競合しているバス・クライエントは彼らのホ
スト・バスに対する公平で限界のあるタイム・アクセス
を確実にし、また、バス上でのパケットの渋滞を回避す
るフロー・コントロールを実施するための裁定手段を備
えている。上記で指摘されたように、１個または複数個
のバスがパケットで切り換えられることから、パケット
の渋滞は一つの結末をなすものであり、これの意味する
ことは、それらのサービスが可能になるよりも早く、バ
ス・クライエントがトランザクション・リクエストを累
積できることである。 【０１００】この増強された実施例においては、各クラ
イエント・デバイスは、３本のリクエスト・ワイヤ　　
Ｒｅｑ　　Ｌ［２．．０］および３本の許可タイプ・ワ
イヤＧｎｔ−Ｔｙｐｅ　　Ｌ［２．．０］を有する裁定
ポートを介して、そのバスのための裁定手段と相互作用
をする。これに加えて、該裁定手段に接続されている全
てのクライエントによって共有される単一のＧｎｔＬワ
イヤがある。 【０１０１】ある１個のバス・クライエントは、１クロ
ック・サイクルまたは２個の連続するサイクルの間、そ
のＲｅｑ　　Ｌワイヤを用いて、そのバスのための裁定
手段に対してその裁定リクエストの通信をする。その第
１のサイクルにおいては、該クライエントはそのリクエ
ストの優先権についての通信をする。これに加えて、正
常な裁定リクエストのためには、クライエントはそのＲ
ｅｑ　　Ｌワイヤの１本の上で第２のサイクルを用いて
、バスがリクエストされているパケット長について裁定
手段に告知するようにされる。典型的には、これらの裁
定リクエストの２個のサイクルに対するコード化は次の
通りである。 第１サイクル ７：裁定停止（Ｓｔｏｐ　　Ａｒｂｉｔｒａｔｉｏｎ）
６：リプライ・ハイ（Ｒｅｐｌｙ　　Ｈｉｇｈ）５：ポ
ーズ（Ｐａｕｓｅ） ４：リプライ・ロー（Ｒｅｐｌｙ　　Ｌｏｗ）３：ホー
ルド（Ｈｏｌｄ） ２：リクエスト・ハイ（Ｒｅｑｕｅｓｔ　　Ｈｉｇｈ）
１：リクエスト・ロー（Ｒｅｑｕｅｓｔ　　Ｌｏｗ）０
：ノー・リクエスト（Ｎｏ　　Ｒｅｑｕｅｓｔ）第２サ
イクル Ｌ：パケット長（０＝＞２サイクル，１＝＞９サイクル
） 【０１０２】４個の優先権であるＲｅｑｕｅｓｔ　　Ｌ
ｏｗ，Ｒｅｑｕｅｓｔ　　Ｈｉｇｈ，Ｒｅｐｌｙ　　Ｌ
ｏｗ，およびＲｅｐｌｙ　　Ｈｉｇｈ　　は、バスに対
する“正常な”裁定リクエストに対応している。これを
換言すれば、それらが使用されるのは、裁定リクエスト
を登録しているデバイスが実際にパケットを伝送しよう
とするときである。Ｒｅｐｌｙ　　Ｈｉｇｈはキャッシ
ュのリプライだけに用いられる；Ｒｅｐｌｙ　　Ｌｏｗ
はメモリのリプライだけに用いられる；そして、Ｒｅｑ
ｕｅｓｔ　　ＨｉｇｈはプロセッサおよびＩＯキャッシ
ュのような大方のリクエスタに対するものである。Ｒｅ
ｑｕｅｓｔ　　Ｌｏｗは、裁定手段からの許可を得るた
めに長い遅れが裁定的に黙認される“バックグラウンド
”デバイスによってのみ用いられるものである。再びこ
の実施例においては、ある１個のクライエントは多くの
裁定リクエストを続けて発することができるが、この場
合に、ある１個の分離したリクエストはリクエスト・サ
イクルの各ペアに対して登録される。更に、クライエン
トは、裁定手段がある所与のクライエントの側にたって
登録できる裁定リクエストの個数だけ、該裁定手段によ
って課される実施限界を彼らが超えていないことを確実
にするという責任がある。上述された裁定のルールを維
持しながら、より高い優先度の裁定リクエストが、より
低い優先度のリクエストに先だってサービスされる。そ
して、同じ優先度のレベル内にある裁定リクエストは、
ほぼラウンド・ロビン式の順序でサービスされることに
なる。 【０１０３】（ＮｏＲｅｑｕｅｓｔ，Ｈｏｌｄ，Ｐａｕ
ｓｅおよびＳｔｏｐのような）この実施例によって支持
される他の裁定の優先権は、クライエントが彼らのホス
ト・バスに対する裁定手段からの特別なサービスをリク
エストすることが許容されるように利用可能なものであ
る。これらの特別な裁定リクエストは、裁定の優先度を
特定する１サイクルのリクエストだけ裁定手段に対して
通信される。裁定手段からのサービスは何もリクエスト
されないときには、バス・クライエントはＮｏＲｅｑｕ
ｅｓｔを使用する。Ｈｏｌｄは、リクエスト・パケット
に対するいかなるリクエストでも裁定手段が許容しない
ように所望するクライエントによって使用される（Ｈｏ
ｌｄを下回る優先度）。このために、Ｈｏｌｄは、その
目的および機能において、先に説明された実施例で採用
された裁定リクエストについて、“システム・ワイドの
保持を要求すること”および“システム・ワイドの保持
に対する要求を解除すること”のコード化をすることと
類似している。しかしながら、この実施例においては、
クライエントがＨｏｌｄコードを主張するサイクルだけ
にわたって、裁定手段はＨｏｌｄ状態に留まる。Ｐａｕ
ｓｅはこの発明に対しては固有のコード化をすることで
ある。キャッシュによって主張できることは、メモリに
よって発生されるリプライが殺到するのを回避すること
である。最後に、Ｓｔｏｐは、デバイスが全ての裁定を
停止させようと所望するときに用いられる。これにより
、裁定手段をして、任意の裁定手段がＳｔｏｐコードを
主張するだけのサイクルにわたってバスの許可を停止さ
せる。このために、ここで理解されることは、Ｓｔｏｐ
コードは、初めの実施例において考えられたＳＳｔｏｐ
信号と機能的に類似であるということである。 【０１０４】Ｇｎｔ　　ＬおよびＧｎｔＴｙｐｅ　　Ｌ
は、次のバス・マスターになるように裁定手段によって
選択されていることをクライエントに対して告知するた
めに、裁定手段によって用いられるものである。この信
号は１サイクルだけ主張されるものであり、一連の後続
のサイクルにわたって、選択されたバス・クライエント
にバス・マスターシップを付与するものである。ここで
、ＧｎｔＴｙｐｅ　　Ｌは許可が与えられている裁定リ
クエストの優先度を指示している。このような目的のた
めに、ＧｎｔＴｙｐｅ　Ｌは次のように好適にコード化
される。 ７：裁定停止（Ｓｔｏｐ　　Ａｒｂｉｔｒａｔｉｏｎ）
６：リプライ・ハイの許可（Ｇｒａｎｔ　　Ｒｅｐｌｙ
　　Ｈｉｇｈ） ５：保留（Ｒｅｓｅｒｖｅｄ）（使用されない）４：リ
プライ・ローの許可（Ｇｒａｎｔ　　Ｒｅｐｌｙ　　Ｌ
ｏｗ） ３：保留（Ｒｅｓｅｒｖｅｄ）（使用されない）２：リ
クエスト・ハイの許可（Ｇｒａｎｔ　　Ｒｅｑｕｅｓｔ
　　Ｈｉｇｈ） １：リクエスト・ローの許可（Ｇｒａｎｔ　　Ｒｅｑｕ
ｅｓｔ　　Ｌｏｗ） ０：許可ナシ（Ｎｏ　　Ｇｒａｎｔ） 【０１０５】Ｇｎｔ　　Ｌが主張されており、該当のク
ライエントに対するＧｎｔＴｙｐｅＬ　　がゼロではな
いときにのみ、所与のクライエントはそのバスに対する
裁定手段からの有効な許可を有している。この実施例に
おいて、ある所与のクライエント・デバイスに対するイ
ンタフェース１０１におけるサイクルｉ上でＧｎｔ　　
ＬおよびＧｎｔＴｙｐｅ　　Ｌが主張されているときに
は、クライエントは、サイクルｉ＋２において、その出
ていく単方向または双方向のバス・セグメントを駆動す
ることができる。図１７に示されているものは、裁定（
５サイクルの裁定の潜在が仮定されている）およびパケ
ットの伝送の間の、裁定リクエスタのデバイス・バス・
インタフェース１０１における、より重要な裁定リクエ
ストおよび許可信号についてのタイミングである。この
図１７を読むときには図１６にも留意すべきである。 【０１０６】上述された実施例におけるように、裁定手
段はフロー・コントロールを実施するための２個の異な
るメカニズムを有している。裁定の優先度は、これらの
フロー・コントロールのメカニズムの第１のものである
。ここで理解されるように、リクエスト・パケットおよ
びリプライ・パケットの双方を発するクライエント・デ
バイスは、リクエスト・パケットの伝送に対するそれら
の裁定リクエストよりも、リプライ・パケットの伝送に
対するそれらの裁定リクエストに対して、より高い優先
度を常に指定している。渋滞の始まりに先だってデバイ
スが常にリプライの用意をしているときには、これは渋
滞の問題を除外するために十分なものであるが、全ての
デバイスにとってはこの要求を満たすことはできない。 例えば、それらが受け入れ得るリクエスト・パケットに
対する到達レートにおいて応答するためには、メモリ・
コントローラ２５（図１）のような、より遅いデバイス
を予期することは実際的ではない。更に、このようなデ
バイスでオーバフローのリスクなしで累積できる入力キ
ューの長さは法外に長いものである。 【０１０７】このために、裁定手段は、Ｈｏｌｄおよび
Ｐａｕｓｅの裁定リクエストのコード化に対する上述の
応答を介して、第２のフロー・コントロールのメカニズ
ムを実施するようにされる。ここで認められるように、
ＨｏｌｄまたはＰａｕｓｅのリクエストに対する裁定手
段の応答は即座のものではないから、それらのＨｏｌｄ
またはＰａｕｓｅのリクエストがバスの裁定手段におい
て効力を生じる間に幾つかの入来するパケットの累積が
許容されるように、クライエント・デバイスはそれらの
入力キューにおいて十分な余裕を持たねばならない。し
かしながら、クライエント・デバイスのいずれかが極め
て頻繁にＨｏｌｄまたはＰａｕｓｅのリクエストをする
ときには、バスのスループットが無用な逆効果を生じる
ことから、バランスが衝撃を受けることがある。 【０１０８】３．　　データ／コントロール・インタフ
ェース インタフェース１０１のデータ・ポートおよびオプショ
ンの受け入れポート（図１５）は、その目的および機能
において、それぞれに、インタフェース４１の送出ポー
トおよび受け入れポート（図４）に類似している。しか
しながら、インタフェース４１のＨｅａｄｅｒＣｙｃｌ
ｅＩｎ信号およびＨｅａｄｅｒＣｙｃｌｅＯｕｔ信号は
、パケットのヘッダー・サイクルを同定するための逆パ
リティ・シンドロームを採用するという立場から、これ
らは除外されている。各バス上の全てのパケットの各サ
イクルに対するバイト・レベルにおいて、パリティの演
算がこの増強された実施例でなされていることから、こ
れは実際的なことである。各バスでは、典型的に、６４
ビット幅の多重化したアドレス／データ・パスが設けら
れているとすると、これの意味することは、全てのパケ
ットの各サイクルについて８個のパリティ・ビットがあ
るということである。その結果として、データ・サイク
ルに対する正しい偶数パリティのコード化は、ヘッダー
・サイクルに対する正しい奇数パリティのコード化から
、８のハミング距離だけ離されることになるが、標準的
なエラー検出技術を用いてパリティ・エラーを検出する
ことの可能性について妥協することからは、パリティの
この異常な使用を防止するためには十分な離隔であると
信じられる。 【０１０９】インタフェース１０１の他の差別的な特徴
は、ＢｉｄＥＮ　　Ｌ信号がそのコントロール・ポート
に加えられて、該インタフェース１０１が単方向のバス
・セグメントまたは双方向のバス・セグメントに接続さ
れているかどうかを肯定的に指示するようにされること
である。ＢｉｄＥＮ　　Ｌが主張されているとき、また
は真（“１”）であるときには、ＤａｔａＰｏｒｔは双
方向モードで動作して、クライエント・デバイスと双方
向のバス・セグメントとの間で、双方向のパケット通信
を支持するようにされる。これに対して、ＢｉｄＥＮ　
　Ｌが主張されていないとき、または偽（“０”）であ
るときには、ＤａｔａＰｏｒｔは単方向の出力モードで
動作し、また、ＲｅｃｅｉｖｅＯｐｔｉｏｎＰｏｒｔは
単方向の入力モードで動作するようにされる。 【０１１０】４．　　両立性ポート 図４に示されているインタフェース４１の両立性ポート
は、図１５のインタフェース１０１における直接的な対
応を備えてはいないが、ここで認められることは、両立
性の信号がインタフェース１０１の裁定ポートにマージ
されていることである。この表象的な（ｐｒｅｓｅｎｔ
ａｔｉｏｎａｌ）変更がなされているのは次の理由によ
る。即ち、（ａ）バス・クライエントからのＲｅｑＳｈ
ａｒｅｄＬ　　信号（ＳｈａｒｅｄＯｕｔ信号として先
に同定されたもの）の論理的なＯＲをとって、それらの
クライエントに対してＧｒａｎｔＳｈａｒｅｄ　　Ｌ信
号（ＳｈａｒｅｄＩｎ信号として先に同定されたもの）
を供給するために、および、（ｂ）バス・クライエント
からのＲｅｑＯｗｎｅｒ　　Ｌ信号（ＯｗｎｅｒＯｕｔ
信号として先に同定されたもの）の論理的なＯＲをとり
、それらに対してＧｒａｎｔＯｗｎｅｒ　　Ｌ信号（Ｏ
ｗｎｅｒＩｎ信号として先に同定されたもの）を供給す
るためには、各バスに対する裁定手段が便利な位置にあ
ることが見出されたからである。実際に、ＲｅｑＳｈａ
ｒｅｄ　　Ｌ，ＧｒａｎｔＳｈａｒｅｄ　　Ｌ，Ｒｅｑ
Ｏｗｎｅｒ　　ＬおよびＳｈａｒｅｄＯｕｔ　　Ｌは、
機能的には、それぞれに、インタフェース４１のＳｈａ
ｒｅｄＯｕｔ，ＳｈａｒｅｄＩｎ，ＯｗｎｅｒＯｕｔお
よびＯｗｎｅｒＩｎ信号と同等のものであるから、Ｓｈ
ａｒｅｄＯｕｔ，ＳｈａｒｅｄＩｎ，ＯｗｎｅｒＯｕｔ
およびＯｗｎｅｒＩｎ　　なる名称は、拡張されたデー
タ両立性のプロトコルの記述を簡略化するために、以下
のそれらの信号を参照する際に用いられることになる。 両立性信号をインタフェース１０１の裁定ポートにマー
ジさせることの付加的な利点は、出力信号に対してはイ
ンタフェース１０１において、また、入力信号に対して
は裁定手段において、単一ビット・パリティのコード化
の使用を介するようにして、裁定および両立性の入力信
号および出力信号について組み合わされたパリティ・チ
ェック操作を容易にするものである。 【０１１１】Ｃ．　　トランザクションこの実施例に対
して規定されているトランザクションは次の通りである
。 　　トランザクション　　　　　　　　リクエスト　　
　　　　　　コマンド　　　　　　　　　　リクエスト
　　名　　　　　　　　　　　　　　　　　　　　　　
／リプライ　　　　　　　　コード化　　　　　　　　
　　／リプライ　　　　　　　　　　　　　　　　　　
　　　　　　　　省略形　　　　　　　　　　　　（リ
クエスト　　　　　　パケット長　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　／リプライ）Ｎｏｏｐ／Ｅｒｒｏｒ
　　　　　　　　　　　　　Ｎｏｏｐ／Ｅｒｒｏｒ　　
　　　　　　　　　０００００（０／１）　　　　　　
１／１　サイクルＷｒｉｔｅＳｉｎｇｌｅＩｎｖａｌｉ
ｄａｔｅ　　ＷＳＩＲｑｓｔ／ＷＳＩＲｐｌｙ　　　　
　　００００１（０／１）　　　　　　２／２　サイク
ルＮｏｎＣａｃｈｅａｂｌｅＲｅａｄＢｌｏｃｋ　　Ｎ
ＣＲＢｑｓｔ／ＮＣＲＢＲｐｌｙ　　　　　０００１０
（０／１）　　　　　　２／９　サイクルＦｌｕｓｈＢ
ｌｏｃｋ　　　　　　　　　　　　　ＦＢＲｑｓｔ／Ｆ
ＢＲｐｌｙ　　　　　　　　０００１１（０／１）　　
　　　　９／２　サイクル（未定義）　　　　　　　　
　　　　　　−　　　　　　　　　　　　　　　　　　
　００１００（０／１）　　　　　　−　　　　　　　
　　ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ　　　　　　
ＷＳＵＲｑｓｔ／ＷＳＵＲｐｌｙ　　　　　　００１０
１（０／１）　　　　　　２／２　サイクルＲｅａｄＢ
ｌｏｃｋ　　　　　　　　　　　　　　ＲＢＲｑｓｔ／
ＲＢＲｐｌｙ　　　　　　　　００１１０（０／１）　
　　　　　２／９　サイクルＷｒｉｔｅＢｌｏｃｋ　　
　　　　　　　　　　　ＷＢＲｑｓｔ／ＷＢＲｐｌｙ　
　　　　　　　００１１１（０／１）　　　　　　９／
９　サイクルＩＯＲｅａｄＳｉｎｇｌｅ　　　　　　　
　　　　ＩＯＲＳＲｑｓｔ／ＩＯＲＳＲｐｌｙ　　　　
０１０００（０／１）　　　　　　２／２　サイクルＩ
ＯＷｒｉｔｅＳｉｎｇｌｅ　　　　　　　　　　ＩＯＷ
ＳＲｑｓｔ／ＩＯＷＳＲｐｌｙ　　　　０１００１（０
／１）　　　　　　２／２　サイクルＩＯＲｅａｄＢｌ
ｏｃｋ　　　　　　　　　　　　ＩＯＲＢＲｑｓｔ／Ｉ
ＯＲＢＲｐｌｙ　　　　０１０１０（０／１）　　　　
　　２／９　サイクルＩＯＷｒｉｔｅＢｌｏｃｋ　　　
　　　　　　　　ＩＯＷＢＲｑｓｔ／ＩＯＷＢＲｐｌｙ
　　　　０１０１１（０／１）　　　　　　９／２　サ
イクル（未定義）　　　　　　　　　　　　　　−　　
　　　　　　　　　　　　　　　　　０１１００（０／
１）　　　　　　−　　　　　　　　　Ｌｏｃｋ　　　
　　　　　　　　　　　　　　　　ＬＲｑｓｔ／ＬＲｐ
ｌｙ　　　　　　　　　　０１１０１（０／１）　　　
　　　２／２　サイクルＤｅｍａｐＩｎｉｔｉａｔｅ　
　　　　　　　　　ＤｍＩＲｑｓｔ／ＤｍＩＲｐｌｙ　
　　　　　０１１１０（０／１）　　　　　　２／２　
サイクルＩｎｔｅｒｒｕｐｔ　　　　　　　　　　　　
　　Ｉｎｔ／−　　　　　　　　　　　　　　　　０１
１１１（０／１）　　　　　　２／−　サイクル（未定
義）　　　　　　　　　　　　　　−　　　　　　　　
　　　　　　　　　　　１００００（０／１）　　　　
　　−　　　　　　　　　ＳｗａｐＳｉｎｇｌｅＩｎｖ
ａｌｉｄａｔｅ　　　ＳＳＩＲｑｓｔ／ＳＳＩＲｐｌｙ
　　　　　　１０００１（０／１）　　　　　　２／２
　サイクル（未定義）　　　　　　　　　　　　　　−
　　　　　　　　　　　　　　　　　　　１００１０（
０／１）　　　　　　−　　　　　　　　　ＫｉｌｌＢ
ｌｏｃｋ　　　　　　　　　　　　　　ＫＢＲｑｓｔ／
ＫＢＲｐｌｙ　　　　　　　　１００１１（０／１）　
　　　　　２／２　サイクル（未定義）　　　　　　　
　　　　　　　−　　　　　　　　　　　　　　　　　
　　１０１００（０／１）　　　　　　−　　　　　　
　　　ＳｗａｐＳｉｎｇｌｅＵｐｄａｔｅ　　　　　　
　ＳＳＵＲｑｓｔ／ＳＳＵＲｐｌｙ　　　　　　１０１
０１（０／１）　　　　　　２／２　サイクル（未定義
）　　　　　　　　　　　　　　−　　　　　　　　　
　　　　　　　　　　１０１１０（０／１）　　　　　
　−　　　　　　　　　（未定義）　　　　　　　　　
　　　　　−　　　　　　　　　　　　　　　　　　　
１０１１１（０／１）　　　　　　−　　　　　　　　
　（未定義）　　　　　　　　　　　　　　−　　　　
　　　　　　　　　　　　　　　１１０００（０／１）
　　　　　　−　　　　　　　　　ＩＯＳｗａｐＳｉｎ
ｇｌｅ　　　　　　　　　　　ＩＯＳＳＲｑｓｔ／ＩＯ
ＳＳＲｐｌｙ　　　　１１００１（０／１）　　　　　
　２／２　サイクル（未定義）　　　　　　　　　　　
　　　−　　　　　　　　　　　　　　　　　　　１１
０１０（０／１）　　　　　　−　　　　　　　　　（
未定義）　　　　　　　　　　　　　　−　　　　　　
　　　　　　　　　　　　　１１０１１（０／１）　　
　　　　−　　　　　　　　　（未定義）　　　　　　
　　　　　　　　−　　　　　　　　　　　　　　　　
　　　１１１００（０／１）　　　　　　−　　　　　
　　　　ＵｎＬｏｃｋ　　　　　　　　　　　　　　　
　　ＵＲｑｓｔ／ＵＲｐｌｙ　　　　　　　　　　１１
１０１（０／１）　　　　　　２／２　サイクルＤｅｍ
ａｐＴｅｒｍｉｎａｔｅ　　　　　　　　　ＤｍＴＲｑ
ｓｔ／ＤｍＴＲｐｌｙ　　　　　　１１１１０（０／１
）　　　　　　２／２　サイクル（未定義）　　　　　
　　　　　　　　　−　　　　　　　　　　　　　　　
　　　　１１１１１（０／１）　　　　　　　−　　　
　　　　　 【０１１２】再び、全てのリクエスト・パケットおよび
リプライ・パケットの第１のサイクルはヘッダー・サイ
クルである。図１３に戻って認められることは、この実
施例におけるリクエスト・パケットに対するヘッダー・
サイクルのフォーマットが、４２ビット幅のアドレス・
フィールドとともに、６ビット幅のコマンド・フィール
ド（リクエスト／リプライのフラグ・ビットを含んでい
る）を有するようにされていて、規定されている増大し
た個数のトランザクションのコード化に対して十分な能
力を備えていることである。アドレス・フィールドのよ
り上位の２ビットは、実施されている種々の“単一の”
（ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ，Ｉ／ＯＲｅａ
ｄＳｉｎｇｌｅ，等の）トランザクションに対してアド
レスされた“単一のもの”のサイズ（ＳＳｉｚｅ）を特
定するために採用されており、また、このフィールドの
下位の４０ビットはＩ／Ｏアドレス空間またはメモリ・
アドレス空間（即ち、物理的なアドレス空間）のいずれ
かにおけるバイト・アドレスを特定するために有用なも
のである。一つの実施においては、これらのバイト・ア
ドレス・ビットの中の３６個だけが採用されており、残
りの４ビット（例えば、該バイト・アドレスの上位４ビ
ット）は、将来のアドレス拡張のために保留されている
（保留または不使用のアドレス・ビットに対してとられ
る対策については上記の説明を参照）。 【０１１３】図１３におけるリクエスト・パケットのヘ
ッダー・サイクルに付加的に含まれているＰＬｅｎビッ
トは、該パケットが（９サイクルの）長パケットである
か、または、（２サイクルの）短パケットであるかの信
号を出すためのものである。このコード化はヘッダーの
コマンド・フィールドで搬送されるコマンドについては
冗長性があるけれども、ある所定の事例では長パケット
に関連しており、他の事例では短パケットに関連するよ
うな、まだ規定されていないコマンドの適当なコード化
を許容するようにされる。更に、キャッシュ・リクエス
タによって任意の所与のデータ・ブロック上に維持され
るオーナ・ビットをコントロールするための　　Ｏｗビ
ットがあり、該所与のデータ・ブロックの値または共有
状態に影響し得るトランザクションを開始するようにさ
れる。該当のカテゴリに入るこの実施例のトランザクシ
ョンは、ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔｅ，Ｗｒｉ
ｔｅＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ，ＳｗａｐＳｉ
ｎｇｌｅＵｐｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＩｎｖａ
ｌｉｄａｔｅおよびＲｅａｄＢｌｏｃｋである。それら
のトランザクションに対するリクエスト・パケットのヘ
ッダーにおけるＯｗビットの状態により、該トランザク
ションが関係するデータ・ブロックの所有権を受け入れ
るために、リクエスタに用意があるかどうかの指示がな
される。他の全てのトランザクションに対しては、この
Ｏｗビットの値が偽りの（“０”の）状態にあるように
維持される。 【０１１４】この実施例におけるリクエスト・パケット
のヘッダーには８ビット幅のＤｅｖｉｃｅＩＤフィール
ドおよび４ビット幅のＳｕｂＩＤフィールドも含まれて
いるが、これらは、その目的および機能において、上記
された実施例のヘッダーによって搬送されるＤｅｖｉｃ
ｅＩＤと類似している（この例においては、ＳｕｂＩＤ
は、多くの未解決のリクエストに対するリプライの曖昧
さをなくすことを、バスのクライエント・デバイスで可
能にするために採用できるものであり、また、ＳｕｂＩ
Ｄフィールドは、リクエスタの状態を内部的に記憶させ
ることを回避するために、トランザクションのリクエス
タに対する内部的な状態またはｐｅｎｄｉｎｇＳｔａｔ
ｅをコード化するために採用できるものである）（両立
性プロトコルについての検討を参照）。図１３における
ヘッダーに付加的に含まれているエラー・ビット（Ｅｒ
ｒ）および不使用ビットの双方は、リクエスト・ヘッダ
ーにおいて偽の（“０”の）状態に維持される（Ｅｒｒ
ビットはリプライ・ヘッダーにおいてのみ意味があるも
のである）。 【０１１５】図１４と図１３との比較により、リプライ
・パケットに対するヘッダー・サイクルが対応のリクエ
スト・パケットに対してビット対ビットで同等であるこ
とが確かめられる。ただし、コマンド・フィールドのリ
クエスト／リプライ・ビットは該パケットをリプライと
して同定するように反転される；リプライ・パケットの
長さ（即ち、長または短）は　　ＰＬｅｎ　　ビットに
よってコード化される；Ｅｒｒビットは、リプライのア
センブルをしているときにレスポンダがエラーに遭遇し
たか否かに依存して、真の（“１”の）状態にセットさ
れるか、または、偽りの（“０”の）状態に維持される
；Ｏｗビットの状態が採用されて、トランザクションが
関係しているデータ・ブロックの所有権を獲得するため
にリクエスタが許容されているか否かの指示をするよう
にされる；そして、リクエスト・ヘッダーの不使用ビッ
トが共有（Ｓｈ）ビットとして採用されて、対応のリク
エストがアドレスされたデータが、リクエスト・パケッ
トを受け入れた時点において共有されているか否かの信
号をするようにされる（このように共有されたデータに
ついての、より緻密な説明は上記で現れている）。 【０１１６】１．　　メモリ関連トランザクションこの
実施例のために備えられているメモリ・アクセス・トラ
ンザクションは、ＲｅａｄＢｌｏｃｋ，ＮｏｎＣａｃｈ
ｅａｂｌｅＲｅａｄＢｌｏｃｋ，ＦｌｕｓｈＢｌｏｃｋ
，ＷｒｉｔｅＢｌｏｃｋ，ＷｒｉｔｅＳｉｎｇｌｅＵｐ
ｄａｔｅ，ＷｒｉｔｅＳｉｎｇｌｅＩｎｖａｌｉｄａｔ
ｅ，ＳｗａｐＳｉｎｇｌｅＵｐｄａｔｅ，ＳｗａｐＳｉ
ｎｇｌｅＩｎｖａｌｉｄａｔｅおよびＫｉｌｌＢｌｏｃ
ｋである。ＲｅａｄＢｌｏｃｋ，ＷｒｉｔｅＢｌｏｃｋ
およびＦｌｕｓｈＢｌｏｃｋトランザクションは、多く
の点において、第１の実施例において対応する同名のト
ランザクションと同等のものであるが、この実施例にお
けるこれらのトランザクションおよびその他の“ブロッ
クの”トランザクションでは８サイクルのデータ転送ユ
ニット（即ち、８バス・サイクルであって、その各々に
は８個の連続バイトが含まれている）が用いられる点で
差異がある。更に、ＷｒｉｔｅＳｉｎｇｌｅＵｐｄａｔ
ｅトランザクションは、早期の実施例におけるＷｒｉｔ
ｅＳｉｎｇｌｅトランザクションと機能的に類似してい
るが、新規に規定されたＷｒｉｔｅＳｉｎｇｌｅＩｎｖ
ａｌｉｄａｔｅトランザクションとの区別のためにその
名称が変更されている。同様にして、ＳｗａｐＳｉｎｇ
ｌｅＵｐｄａｔｅは、前述されたＣｏｎｄｉｔｉｏｎａ
ｌＷｒｉｔｅＳｉｎｇｌｅトランザクションを比較的小
幅に修正したトランザクションである（即ち、Ｓｗａｐ
ＳｉｎｇｌｅＵｐｄａｔｅは、Ｃｏｎｄｉｔｉｏｎａｌ
ＷｒｉｔｅＳｉｎｇｌｅで実行される細かい読み取り−
修正−書き込みよりは、細かい読み書きを実行するため
に用いられるものである。）。新規に規定されたＳｗａ
ｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅトランザクション
との区別をするために、それは“Ｕｐｄａｔｅ”なトラ
ンザクションとして同定される。 【０１１７】ＷｒｉｔｅＳｉｎｇｌｅＩｎｖａｌｉｄａ
ｔｅおよびＳｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ
トランザクションは、それぞれに、ＷｒｉｔｅＳｉｎｇ
ｌｅＵｐｄａｔｅおよびＳｗａｐＳｉｎｇｌｅＵｐｄａ
ｔｅトランザクションに対する書き込み無効化のスタイ
ルの対応事項を備えるように規定されている。それらに
より、特定のデータ・ブロックのコピーをキャッシュ・
リクエスタで更新することが可能にされ、受け入れてい
るキャッシュがトランザクションのペンディングをする
データ・ブロックに対して無効化のリクエストがアドレ
スされない限り、同じデータ・ブロックのコピーを含ん
でいる任意の他のキャッシュはそのコピーを無効にする
ようにされている。ここで想起されるように、該当のデ
ータ・ブロックに対するＶａｌｉｄビットを偽の（“０
”の）状態にクリアするだけで、キャッシュはそのデー
タ・ブロックの任意のものを無効化し、または、削除す
ることができる。 【０１１８】この実施例において、メイン・メモリ１３
（図１）から読み取られた後で修正されたデータ・ブロ
ックの所有権は、必ずしも最後に書き込みをしたプロセ
ッサに対するキャッシュに属するものではない。代替的
に、データ・ブロックの所有権の転移は、ＷｒｉｔｅＳ
ｉｎｇｌｅＵｐｄａｔｅ，ＷｒｉｔｅＳｉｎｇｌｅＩｎ
ｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＵｐｄａｔｅ
，ＳｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅおよびＲ
ｅａｄＢｌｏｃｋトランザクションに対するリクエスト
・パケットおよびリプライ・パケットのヘッダー・サイ
クルにおけるＯｗビットの状態のコントロールによって
なされる。これを詳細にいえば、リクエスタを除く全て
のキャッシュであって、ＷＳＩＲｐｌｙ，ＷＳＵＲｐｌ
ｙ，ＳＳＩＲｐｌｙおよびＳＳＵＲｐｌｙと合致するも
のは、特定のデータ・ブロックに対するそれらのオーナ
・ビットを偽の（“０”の）状態に無条件でクリアさせ
る。これに対して、リクエスタは、このようなリプライ
を受け入れると、該リプライにおけるＯｗビットに依存
して、該当のデータ・ブロックに対するそのオーナ・ビ
ットを（“１”）にセット、または（“０”）にクリア
する。リプライ・ヘッダーにおけるＯｗビットが真の（
“１”の）状態にセットされているときには、リクエス
タは、該データ・ブロックに対するそのオーナ・ビット
を真の（“１”の）状態にセットする。しかしながら、
リプライ・ヘッダーにおけるＯｗビットが偽の（“０”
の）状態にクリアされているときには、対応のリクエス
ト・パケット内のＯｗビットが偽の（“０”の）状態に
クリアされているために、または、ある他の理由により
、リプライを用意しながらレスポンダがＯｗビットを偽
の（“０”の）状態にクリアしたために、リクエスタは
、トランザクションが関係するデータ・ブロックに対す
るそのオーナ・ビットを偽の（“０”の）状態にクリア
する。ここで認められるように、メイン・メモリ１３（
図１）は、物理的なアドレス空間における全てのデータ
・ブロックの欠陥のあるオーナである。従って、ＷＳＩ
Ｒｑｓｔ，ＷＳＵＲｑｓｔ，ＳＳＩＲｑｓｔまたはＳＳ
ＵＲｑｓｔのヘッダーに偽の（“０”の）Ｏｗビットが
含まれているときには、メモリ１３は、通常は、リクエ
ストによって付与される新規なデータに従って更新され
る。勿論、ＳＳＩＲｑｓｔまたはＳＳＵＲｑｓｔを発す
るキャッシュが、これらのトランザクションの読み取り
フェーズを支持する際に、まだプロセッサに対して古い
データを供給する責任があることから、リクエスタは、
そのリクエストに対するリプライを少なくとも受け入れ
るまでは、該当のデータ値を留めておくようにされる。 【０１１９】ＯｗビットはＲｅａｄＢｌｏｃｋトランザ
クションにおいても用いられる。特に、関連のプロセッ
サによる書き込みに対するプレリュードとして、キャッ
シュ・リクエスタによって発せられるＲＢＲｑｓｔにお
いて、それは真の（“１”の）状態にセットされて、対
応のＲＢＲｑｓｔが受け入れられるときに、特定のデー
タ・ブロックに対するそのオーナ・ビットを真の（“１
”の）状態にセットすることを、リクエスタが所望して
いることが告知される。このために、ここで理解される
ことは、ＲＢＲｑｓｔのヘッダーにおけるＯｗビットに
より、リクエスタに対する特定のデータ・ブロックの所
有権の加速された転移が許容されることになる。 【０１２０】この実施例に対するＲｅａｄＢｌｏｃｋト
ランザクションに特有の別の特徴は、ＲＢＲｐｌｙを可
能にするようにされた提案事項であって、リプライにつ
いての任意のデータ・サイクルにおいて、リクエスタに
対して戻されるべきデータをフェッチしている間にメモ
リ・エラーが生じたときには、該リクエスタにこれを告
知するようにされている。何等かのこのようなデータの
フェッチ・エラーが生じたことがレスポンダによって見
出されたときには、１個または複数個のエラーで影響を
受けるＲＢＲｐｌｙのデータ・サイクルの各々に対して
、メモリ・フォールト（ＭｅｍＦａｕｌｔ）サイクルが
代用される。ＭｅｍＦａｕｌｔサイクルは独特のものと
して同定可能であるが、その理由は、（ａ）そのための
パリティがヘッダー・サイクルの奇数パリティに対して
反転されること、（ｂ）Ｎｏｏｐに対するコマンド・コ
ードが含まれていること、および、（ｃ）そのＤｅｖｉ
ｃｅＩＤおよびＳｕｂＤｅｖｉｃｅＩＤフィールドがエ
ンプティ（全て０）であることのためである。生じてい
るメモリ・エラーのタイプを同定するエラー・コードは
、このようなＭｅｍＦａｕｌｔサイクルの下位３２ビッ
トによって支承されている。このようなメモリのフォー
ルト・サイクルのメカニズムを付与する重要な利点は、
リクエストされたメモリの読み取り動作を実行しながら
、レスポンダがＲＢＲｐｌｙを発することが許容される
ことであるが、これの意味することはメモリの待ち時間
を減少できることである。 【０１２１】ＫｉｌｌＢｌｏｃｋは規定されている新規
なトランザクションであって、（メイン・メモリと同様
な）第２のまたはより高いレベルのキャッシュが、それ
らがブランチするより低いレベルのキャッシュから不使
用のデータ・ブロックを排除できるようにされる。例え
ば、しばらくの間図１に戻ると、キャッシュ１９ａはＫ
ｉｌｌＢｌｏｃｋを始動させて、クラスタ・バス１５ａ
上にある全てのキャッシュ１６ａａ−１６ａｊから特定
のデータ・ブロックの全てのコピーを除去させることが
できる。 【０１２２】これをより詳細にいえば、該ＫｉｌｌＢｌ
ｏｃｋトランザクションが重要であるという理由は、第
２のまたはより高いレベルのキャッシュにより実在のデ
ータ・ブロックを犠牲にすることが許容されて、該当の
データに対して指定されていた記憶位置が、その上位ま
たは高位レベルのバス（即ち、キャッシュ１９ａの場合
にはグローバル・バス２６）上でＲｅａｄＢｌｏｃｋを
実行することによってキャッシュが獲得する新規なデー
タを記憶させるために再指定できるようにされる。ここ
で想起されるように、それらのより下位レベルのバス（
例えば、バス１５ａ）上の任意のＲＢＲｑｓｔ上で“ミ
ス”にされたときには、これらのより高位レベルのキャ
ッシュはそれらのバス上でＲｅａｄＢｌｏｃｋを始動さ
せる。このために、ＫｉｌｌＢｌｏｃｋトランザクショ
ンの規定は、初めの実施例における第２のまたはより高
位レベルのキャッシュに対して課された、潜在的に繁雑
な“ａｓｓｏｃｉａｔｏｒ　　ｃｏｖｅｒａｇｅ（連想
範囲）”を回避するためのものである。ここでより詳細
に想起されることは、第２レベルのキャッシュ１９ａ−
１９ｉの各々を選択することにより、第１レベルのキャ
ッシュに対して連想範囲を付与することが可能にされて
、（ａ）それらの下位に存在する第１レベルのキャッシ
ュの容量の和に少なくとも等しい容量、および、（ｂ）
それらの第１レベルのキャッシュの連想性の和に少なく
とも等しい連想性の程度を持たせることである。 しかしながら、このＫｉｌｌＢｌｏｃｋトランザクショ
ンによれば、代替的でコストが潜在的に低い技術が付与
されて、第２レベルのキャッシュにより、それらの第１
レベルのチャイルド・キャッシュ（即ち、それらがブラ
ンチする第１レベルのキャッシュ）に対する完全な範囲
を与えることが確実にされる。 【０１２３】ＫｉｌｌＢｌｏｃｋを実行するために、よ
り高位レベルのキャッシュにより適当な犠牲アルゴリズ
ム（周知のいかなる犠牲アルゴリズムでも使用できる）
の使用を介して潜在的な犠牲としてのデータ・ブロック
が選択され、そして、該選択されたデータ・ブロックに
対するそのオーナ・ビットの状態がチェックされる。潜
在的な犠牲ブロックに対するそのオーナ・ビットが真の
（“１”の）状態にセットされると、ＫｉｌｌＢｌｏｃ
ｋの始動手段（ｉｎｉｔｉａｔｏｒ）により、その下位
レベルのバス（即ち、第２レベルのキャッシュ１９ａの
場合にはクラスタ・バス１５ａ）上にＲＢＲｑｓｔがま
ず発せられる。このＲＢＲｑｓｔは潜在的な犠牲にアド
レスされているから、対応のＲＢＲｐｌｙが受け入れら
れるときには、該ＫｉｌｌＢｌｏｃｋの始動手段により
潜在的な犠牲のそのコピーが更新される。所要であれば
更新の後で（ＫｉｌｌＢｌｏｃｋの始動手段が潜在的な
犠牲に対するそのオーナ・ビットを偽の（“０”の）状
態にクリアしたときには、更新の実行はされない）、こ
のＫｉｌｌＢｌｏｃｋの始動手段は、その下位レベルの
バスを用いて、該潜在的な犠牲に対してアドレスされる
ＫＢＲｐｌｙを発するようにされる。このＫＢＲｐｌｙ
上で合致する、より下位レベルのキャッシュ（例えば、
キャッシュ１２ａａ−１２ａｊ）の各々は、その上でペ
ンディングしているトランザクションがない限りは、特
定されたデータ・ブロックのそのコピーに対するそのＶ
ａｌｉｄビットをクリアするようにされる。このＫｉｌ
ｌＢｌｏｃｋの始動手段は、次いで、その下位レベルの
バス上にＫＢＲｑｓｔを発する。このＫＢＲｑｓｔは潜
在的な犠牲に対してアドレスされているから、ＫＲＢｑ
ｓｔが受け入れられ、そのＫＲＢｑｓｔに応答して、よ
り下位レベルのキャッシュの任意のものがＲｅｑＳｈａ
ｒｅｄ　　Ｌ（ＳｈａｒｅｄＯｕｔ）が決定されるとき
には、ＫｉｌｌＢｌｏｃｋの始動手段によってそのＧｒ
ａｎｔＳｈａｒｅｄＬ入力信号（換言すれば、そのＳｈ
ａｒｅｄＩｎ信号）の状態がチェックされる。もしそう
であるとすると、ＫｉｌｌＢｌｏｃｋの始動手段がリセ
ットされて、ある所定の将来の時点まで、選択されたデ
ータ・ブロックを犠牲にすることが延期される。しかし
ながら、ＫＲＢｑｓｔの受け入れの際に、より下位レベ
ルのキャッシュのいずれもＲｅｑＳｈａｒｅｄ　　Ｌ（
ＳｈａｒｅｄＯｕｔ）を主張しないときに、このＫｉｌ
ｌＢｌｏｃｋの始動手段で確認されることは、その下位
レベルのバス上の任意のキャッシュにおいて特定された
データ・ブロックのコピーは存在せず、これに次いで、
そのより高位レベルのバス上でＦｌｕｓｈＢｌｏｃｋが
始動して、データ・ブロックのそのコピーをメイン・メ
モリ１３に書き戻すようにされる（または、次に高いレ
ベルのキャッシュに書き戻すようにされる）。 【０１２４】メモリ・システムの効率性を増大させるた
めに規定されている別のトランザクションは、ＮｏｎＣ
ａｃｈｅａｂｌｅＲｅａｄＢｌｏｃｋトランザクション
である。このトランザクションは、アドレスされている
データ・ブロックの共有／非共有状態が影響を受けない
ことを除き、前述されたＲｅａｄＢｌｏｃｋトランザク
ションと同等のものである。従って、その適用は、ＤＭ
ＡＩ／Ｏデバイスのような非キャッシュ式のリクエスタ
の側にたって、合致性のあるメモリ空間（即ち、物理的
なアドレス空間）からのデータ・ブロックの読み取りに
限定される。 【０１２５】２．　　Ｉ／Ｏ　　トランザクションＩ／
Ｏデバイス間でのデータ・ブロックの読み取りおよび書
き込み（それぞれに、ＩＯＲｅａｄＢｌｏｃｋおよびＩ
ＯＷｒｉｔｅＢｌｏｃｋ）をするために、また、Ｉ／Ｏ
デバイスに対してアトミックな読み／書き（ＩＯＳｗａ
ｐＳｉｎｇｌｅ）を実行するために、Ｉ／Ｏトランザク
ションは付加的なトランザクションの支持を付与するよ
うに拡張されている。更に、第１実施例のＢＩＯＷｒｉ
ｔｅトランザクションは、次のＳｅｃｔｉｏｎにおいて
略述されるような、より特定のＩｎｔｅｒｒｕｐｔトラ
ンザクションを備えるために省略されている。 【０１２６】３．　　他のトランザクションＬｏｃｋお
よびＵｎＬｏｃｋは、このカテゴリにおいて、より関心
のある拡張がなされる２個のトランザクションである。 Ｌｏｃｋはキャッシュ・リクエスタにより呼ばれること
ができて、リクエスタを除く任意のクライエントにとっ
て、特定されたデータ・ブロックに影響があり得るいず
れのトランザクションでもその実行を防止するようにさ
れる（即ち、ＷｒｉｔｅＢｌｏｃｋ，ＷｒｉｔｅＳｉｎ
ｇｌｅＵｐｄａｔｅ，ＷｒｉｔｅＳｉｎｇｌｅＩｎｖａ
ｌｉｄａｔｅ，ＳｗａｐＳｉｎｇｌｅＩｎｖａｌｉｄａ
ｔｅまたはＫｉｌｌＢｌｏｃｋ）。従って、ある所与の
データ・ブロックに課されるトランザクション上に、細
かい順序付けの程度を課することが有用である。また、
リクエストされるデータ・ブロックに対する書き込みの
頻度のために、古いデータが戻されるＲＢＲｑｓｔ上で
の無限回数の再試行をキャッシュで防止することも有用
である。全てのキャッシュ・クライエントによってロッ
クされたデータ・ブロックのアドレス（ＬｏｃｋＡｄｄ
ｒｅｓｓ）を登録することにより、また、リクエスタ以
外の全てのキャッシュに対して真の（“１”の）状態に
セットされるフラグ・ビット（ＬｏｃｋＡｄｄｒｅｓｓ
Ｖａｌｉｄ）を備えることにより、Ｌｏｃｋは好都合に
呼ばれることになる。かくして、この特徴のこのような
実施により、１個だけのデータ・ブロックが任意所与の
時点においてロックされることが許容される。ＵｎＬｏ
ｃｋは、ある１個のＬｏｃｋのホルダーがそのＬｏｃｋ
をクリアするために呼ぶことができる、相対的なトラン
ザクションである。キャッシュの各々をして、特定され
たデータ・ブロックに対するそのＬｏｃｋＡｄｄｒｅｓ
ｓＶａｌｉｄビットをクリアさせることにより、その達
成がなされる。 【０１２７】前述されたように、Ｉｎｔｅｒｒｕｐｔト
ランザクションも、プロセッサに対する割り込みの信号
を出力するために規定されたものである。プロセッサの
割り込みはこの発明の範囲を超えたものであるけれども
、ここで注意されることは、このＩｎｔｅｒｒｕｐｔト
ランザクションは、ある特定のプロセッサを目標とする
もの、または、システムにおける全てのプロセッサに対
する放送的なものである。 【０１２８】ＤｅｍａｐＩｎｉｔｉａｔｅは、上述され
たＤｅＭａｐトランザクションに類似のものである。し
かしながら、この事例においては、仮想的なアドレスか
ら物理的アドレスへの変換は、それぞれに、プロセッサ
１２ａａ−１２ｉｊ（図１）に対して設けられるトラン
ザクションのルック・アサイド・バッファ（図示されな
い）によって実行される。かくして、ＤｅＭａｐＴｅｒ
ｍｉｎａｔｅトランザクションが規定されていて、リク
エストされたＤｅＭａｐが完了したときに、プロセッサ
１２ａａ−１２ｉｊの各々により、その第１レベルのキ
ャッシュ１６ａａ−１６ｉｊをしてこのトランザクショ
ンを始動させることになる。プロセッサ１２ａａ−１２
ｉｊがｄｅｍａｐの動作を実行している間に、キャッシ
ュ１６ａａ−１６ｉｊがＲｅｑＳｈａｒｅｄ　　Ｌ（Ｓ
ｈａｒｅｄＯｕｔ）を主張して、ＤｍＩＲｐｌｙがその
Ｓｈ（換言すれば、ｒｅｐｌｙＳｈａｒｅｄ）ビットを
偽の（“０”の）状態にクリアさせる合致が生じたとき
に、プロセッサ１２ａａ−１２ｉｊの全てがリクエスト
されたｄｅｍａｐを完了したという確認をＤｅＭａｐＩ
ｎｉｔｉａｔｅリクエスタが得るようにされる。 【０１２９】Ｆ．データの両立性 この発明のこの実施例のために規定されているＷｒｉｔ
ｅＳｉｎｇｌｅＩｎｖａｌｉｄａｔｅ，ＳｗａｐＳｉｎ
ｇｌｅＩｎｖａｌｉｄａｔｅおよびＫｉｌｌＢｌｏｃｋ
トランザクションは、生起するデータ・ブロック共有の
量を減少させ、これによって、データ両立性のプロトコ
ルが、第１の実施例における純粋な更新プロトコルとい
うよりも、ハイブリッドな更新／無効化プロトコルとし
て振舞うようにされる。この変更がなされたのは、両立
性プロトコルの効率性を増大させるという目的のためで
ある。これらの新規なトランザクションのために、両立
性プロトコルの効率性において注目すべき改善があるか
どうかはまだ不確実ではあるけれども、この新規なトラ
ンザクションが両立性プロトコルの有用性または効率性
の逆効果とはならないことは明かである。 【０１３０】両立性のプロトコルに対してなされた別の
変更は、リクエスト・パケットおよびリプライ・パケッ
トのヘッダー・サイクルにおけるＯｗビットの使用に関
連している。上記で指摘されたように、両立性のあるメ
モリ空間内で実行される読み取りおよび書き込みに関連
するリクエスタおよびレスポンダに対してこのビットで
与えられることは、このような読み取りおよび書き込み
が指向されるデータ・ブロックの所有権の転移に対する
ある所定の付加的なコントロールである。しかしながら
、純粋な更新の両立性プロトコルまたはハイブリッドな
更新／無効化の両立性プロトコルのいずれの有効性また
は有用性に影響することはない。むしろ、特定のデータ
・ブロックが“共有”されているか否か、および、“固
有”のものであるか否かについての追跡を維持するため
の、複写され、非同期に維持されているアドレス／状態
・タグに依存するアーキテクチュア（図示されない）を
用いて、実施されているキャッシュに対する支持が与え
られる。状態の変更はこのようなキャッシュのタグから
タグへと伝わるから、該キャッシュのプロセッサ側から
は共有されておらず、また、固有でもないようにみえる
、局部的にキャッシュされているデータ・ブロックに対
してプロセッサが書き込みを発するときには、ある一つ
の競合条件を生じさせることができる。 【０１３１】このような競合条件が生じることを回避す
るために、偽の（“０”の）状態の共有ビットおよびオ
ーナ・ビットを有しているデータ・ブロックに指向され
る書き込みを関連のプロセッサが発したときには、キャ
ッシュに対してＷｒｉｔｅＳｉｎｇｌｅの始動を要求す
ることができるが、これではバス・トラフィックが増大
することになる。従って、このようなＷｒｉｔｅＳｉｎ
ｇｌｅの頻度を減少させるためにＯｗビットが含まれて
いる。特に、プロセッサが書き込みのペンディング状態
にあるデータ・ブロックのコピーを得るためにＲＢＲｑ
ｓｔを発するときには、そのＲＢＲｑｓｔのヘッダー・
サイクルにおけるＯｗビットをキャッシュによってセッ
トすることが可能となり、これによって、対応のＲＢＲ
ｐｌｙにおけるＯｗビットが真の（“１”の）状態にセ
ットされるようにリクエスタが要求していることがレス
ポンダに告知されることになる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

Claims (1)

【特許請求の範囲】
1. 【請求項１】１個のメイン・メモリ、複数個のプロセッ
   サ、複数個のＩ／Ｏデバイス、および、前記プロセッサ
   および前記Ｉ／Ｏデバイスに対するそれぞれのキャッシ
   ュ・メモリを備えているメモリ共有マルチプロセッサに
   おける；前記プロセッサ、前記Ｉ／Ｏデバイス、前記キ
   ャッシュ・メモリおよび前記メイン・メモリ間でのデー
   タ転送のためのメモリ・トランザクションを実行するた
   めのパケット切り換え式バスであって；前記トランザク
   ションの各々は不確定な時間遅れでリプライ・パケット
   が追従するリクエスト・パケットからなり、これによっ
   て多重トランザクションに対するリクエスト・パケット
   およびリプライ・パケットが前記バス上で時間的にイン
   タリーブされていて、異なるプロセッサのコントロール
   の下に前記データの少なくとも幾らかが異なる時点にお
   いて更新されるべく多重コピーをさせるトランザクショ
   ンが含まれており；前記プロセッサの全ておよび前記Ｉ
   ／Ｏデバイスの全てに対して、前記キャッシュ・メモリ
   内に記憶されており、前記多重コピーによって表される
   全てのデータを含んでいる、全てのデータと両立性があ
   る値を与えるための手段が、前記バスに設けられている
   ；メモリ共有マルチプロセッサのための両立性があるパ
   ケット切り換え式メモリ・バス。