JP2512651B2 - メモリ共有マルチプロセッサ - Google Patents
メモリ共有マルチプロセッサInfo
- Publication number
- JP2512651B2 JP2512651B2 JP3312723A JP31272391A JP2512651B2 JP 2512651 B2 JP2512651 B2 JP 2512651B2 JP 3312723 A JP3312723 A JP 3312723A JP 31272391 A JP31272391 A JP 31272391A JP 2512651 B2 JP2512651 B2 JP 2512651B2
- Authority
- JP
- Japan
- Prior art keywords
- bus
- cache
- data
- memory
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
- G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
- G06F12/0815—Cache consistency protocols
- G06F12/0831—Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Bus Control (AREA)
- Information Transfer Systems (AREA)
- Multi Processors (AREA)
Description
る同期的なパケット切り換え式のメモリ・バスに関する
ものであり、より詳細には、共有データの多重のキャッ
シュ・コピー間の両立性が必要とされる、特にメモリが
共有されたマルチプロセッサにおけるこのようなバスの
使用可能なバンド幅を増大させるためのバス・アーキテ
クチュアおよびプロトコルに関するものである。これを
更に詳細にいえば、この発明は、多重の階層化したメモ
リ・キャッシュを備えたメモリ共有マルチプロセッサを
含んでいるVLSI(超大規模集積化)コンピュータ・
システムに対する、前述のタイプのスケーラブル・メモ
リ・バスに関するものである。
きの主要な目標は、それらの使用可能なバンド幅を最大
にすることにある。ショート・バスのサイクル・タイム
はこれを達成するために必要とされるものであるが、こ
れだけではバスの使用可能なバンド幅がその電気的なバ
ンド幅と確実に両立するようにはならない。その理由
は、該当の目標を達成するためには、バスも高い効率
(通常は、使用可能なバスのバンド幅に対するその電気
的なバンド幅の比率として規定される)を持たねばなら
ないからである。
の使用可能なバンド幅を増大させるためには、ショート
・バスのサイクル・タイムは比較的価値が低いものであ
るが、その理由は、該回路でのバスの切り換えにより、
トランザクション対トランザクションをベースとして、
連続的なトランザクションに対するリクエスト(要求)
/リプライ(応答)のペアが直列化されるからである。
知られているように、コンピュータ・システムがその実
行を要求されるメイン・メモリのトランザクションの数
および頻度を減少させるべくキャッシュ・メモリ・シス
テムを用いることができるけれども、高い実行能力のシ
ステムにおいては、通常は静止状態にあるメモリ・バス
上のトラフィックが実行能力の有力な制限ファクタであ
る。
ン・メモリのアクセス・タイムが、典型的には、実現可
能なバスの最小のサイクル・タイムよりも数倍も長く、
このために、回路で切り換えられるバスの使用可能なバ
ンド幅がメイン・メモリのアクセス・タイムによって制
限され易くなる。キャッシュ・メモリを有するシステム
においては、回路で切り換えられるバスの無駄にされ
た”ウエイト(待ち)”サイクル(即ち、その無駄にさ
れたバンド幅)の減小は、メイン・メモリ/キャッシュ
・メモリのデータ・トランスポート・ユニットのサイズ
を増大させることにより可能であって、これにより、よ
り大きいデータのブロックにわたるバスのウエイト・サ
イクルを償却するようにされる。しかしながら、このア
プローチによれば、1台または複数台のプロセッサによ
ってバス上に配置されるバンド幅ロードが増大する傾向
が生じて、より大きいデータ転送ユニットの利点が少な
くとも部分的に失われることになる。
によって切り換えられる”バス(ときには、“スプリッ
ト・サイクル”バスまたは“ペンディング”バスと呼ば
れることもある)を用いることにより、アイドル・バス
・サイクルに起因するバンド幅の不利益点が回避できる
ということである。バスのパケットでの切り換えにより
バスのトランザクションのリクエストおよびリプライが
互いに分離され、これによって、多重のトランザクショ
ンに対するリクエストおよびリプライがバス上でインタ
リーブすることが許容される。一般的なルールとして、
アイドル・バス・サイクルの回避は、メイン・メモリが
関係するトランザクション(即ち、“メイン・メモリ・
トランザクション”)のリクエストおよびリプライを分
離することによって簡単に可能にされる。しかしなが
ら、全てのバス・トランザクションのリクエストおよび
リプライを分離することが有利であることは見出されて
おり、そのために、(実施方法によって異なる最小数の
サイクルを超える)可変数のバス・サイクルが、任意の
リクエストとそれに対応するリプライとの間に介在する
ことができて、ある所定のタイムアウト周期内にリプラ
イが受け入れられないリクエストの、可能性のある終了
または不成功にのみ追従するようにされる。全てのリク
エストおよびリプライについてのこの本質的な完全な分
離によりバスのデッドロックの排除の助けがなされる
が、産業上の標準的なシステムを含んでいる、異なるま
たは“関連のない”コンピュータ・システムのメモリ・
バスのような、非同期式のデバイスと該バスとのインタ
フェースがより容易になるようにされる。更に、インタ
リーブされたメイン・メモリ・モジュールの使用が容易
にされ、また、マルチレベルで階層性のキャッシュ・メ
モリ・システムを有するマルチプロセッサに対するキャ
ッシュの両立性の問題に対する解決が簡単にされる。
とは、関連しているけれども分離可能な問題である。こ
こで理解されるようにキャッシュの両立性にはより詳細
な考慮がなされる。その理由は、マルチプロセッサにお
けるような異なるプロセッサのコントロールの下に、キ
ャッシュされたデータ・コピーの中の異なるものが更新
されることを許容しながら、共有データの多重にキャッ
シュされたコピーのアクセスをするバスに対して特別の
要求があるからである。
シュの両立性の問題については、幾つかの解決策が知ら
れている。例えば、ともに係属中であり譲渡されたPa
radeep S.Sindhu et al.の米国
特許出願が参照される。この米国特許出願は、“マルチ
プロセッサのためのマルチ・レベルのキャッシュ・メモ
リ・ツリー”として、1986年11月12日に、出願
番号第929,544号をもって出願されたもの(D/
86288)である。しかしながら、キャッシュの両立
性を維持するためのこれら既知の技術は、パケットで切
り換えられるバスに対して直接的に適用できるものでは
ない。なお、Andrew W.Wilson,J
r.,“Hierarchical Cache/Bu
s Architecture for Shared
Memory multiprocessors,”
Computer ArchitectureConf
erence IEEE/ACM),1987,pp2
44−252を参照されたい。
サ、複数個のI/Oデバイス、複数個のキャッシュ・メ
モリおよび1個のメイン・メモリ間でのデータ転送のた
めのパケットで切り換えられるバスを有する、メモリ共
有式のマルチプロセッサによってバス・プロトコルが採
用されている。そして、あらゆる時点において、全ての
プロセッサおよび全てのI/Oデバイスによる、全ての
データに対する両立性のある値のアクセスを確実にしな
がら、異なるプロセッサのコントロールの下に、データ
の多重コピーを更新することが許容される。
は、添付の図面と関連させて以下の説明を参照すること
によって明かにされる。
例に関して相当程度詳細になされているけれども、この
発明はそれらの実施例に限定することを意図するもので
はないことが理解されるべきである。むしろ、その目的
とするところは、添記されている特許請求の範囲の欄に
よって規定されるように、この発明の全ての修正、変更
および均等物をカバーすることにある。
つかの重要な特徴があるから、異なる特徴に関連して構
成体を配置する助けとなるように、その開示は次のよう
な組成がなされている。 I. 初めの実施例 A. システム・アーキテクチュア 1. バスおよびメモリの階層性 a. マルチレベルのバス・システム B. バスの論理的な術語 C. バスの物理的な術語 D. デバイス−バス・インタフェース 1. 信号 2. 裁定・インタフェース 3. データ/コントロール・インタフェース 4. 両立性ポート E. トランザクション 1. メモリ関連トランザクション 2. I/Oトランザクション 3. 多面的トランザクション F. データの両立性 1. 単一レベルのシステムにおけるデータの両立性 2. マルチレベルのシステムにおけるデータの両立性 II. 増強された実施例 A. システム・アーキテクチュア B. デバイス−バス・インタフェース 1. 信号 2. 裁定・インタフェース 3. データ/コントロール・インタフェース 4. 両立性ポート C.トランザクション 1. メモリ関連トランザクション 2. I/Oトランザクション 3. 多面的トランザクション D.データの両立性
数個のプロセッサ12aa−12ijおよび共有のメイ
ン・メモリ13を備えたマルチプロセッサ11が示され
ている。このメイン・メモリ13は集中化されたものと
して描かれているけれども、ここで理解されることは、
物理的なアドレス空間の使用されたサブセットについて
分裂した(即ち、相互に排他的であり、また、徹底的
な)カバーをするために分散化できるということであ
る。
ラスタ14a−14i内で構成されているが、その各々
には、裁定され、パケットで切り換えられるローカル・
バス15a−15iがそれぞれに備えられている。例示
された実施例においてクラスタ14a−14iの各々に
含まれているものは、義務的なものではないが、1個ま
たは複数個のプロセッサ12aa−12ijである。所
望であれば、例えば該クラスタの中の一つが、マルチプ
ロセッサ13に対するI/O動作の実行のためのものと
されている。しかしながら、ここで重要であるとされる
ことは、プロセッサ12aa−12ijの各々が、第1
レベルのキャッシュ・メモリ16aa−16ijによっ
て、それぞれに(プロセッサ自体には、図示されない
が、1個または複数個のより低レベルでもあるキャッシ
ュ・メモリを含ませることができる)、そのクラスタま
たは“ローカル・ホスト”バス15a...,もしくは
15iに結合されているということである。その理由
は、プロセッサ12aa−12ijがそれらのキャッシ
ュ・メモリ16aa−16ijを介してそれらのホスト
・バスと通信するようにされているからである。ローカ
ル・バス15a−15iは、これに次いで、それぞれ
に、クラスタ14a−14i内の共有資源に対してキャ
ッシュ16aa−16ijをリンクさせる。例えばクラ
スタ14aのローカル・バス15aは、プロセッサ12
aa−12ijに対する第1レベルのキャッシュ16a
a−16ijを、それぞれに、オプションのマップ・キ
ャッシュ17aおよび中間レベルまたは第2レベルのキ
ャッシュ・メモリ19aと相互接続させる。ここで示さ
れているように、該第2レベルのキャッシュ19aは、
ランダム・アクセス・メモリ(RAM)モジュール20
aおよびコントローラ21aからなるものである。
ュア 例示されたマルチプロセッサ11は階層的なアーキテク
チュアを有するものであり、異なるレベルの階層におけ
る同様な構成要素を同定するために同様な参照数字が採
用されている。更に、該構成要素の階層的な依存性を同
定するときの助け(デュアル・キャラクタのサフィック
スの第1のキャラクタを参照)のために、および、共通
の依存性を有する同様な構成要素間での区別をする(デ
ュアル・キャラクタのサフィックスの第2のキャラクタ
を参照)ために、アルファベットのサフィックスが前記
の参照数字に付加されている。
いずれのものでも、完全に機能的なモノプロセッサまた
はマルチプロセッサのコンピュータ・システムとして動
作するように構成することができる。この発明のバス・
プロトコルによれば、単一のバス上で幾つかのプロセッ
サを支持するために十分に使用可能なバスのバンド幅が
付与されるが、ここでのシステムの構成は、大方の現存
するデスクトップ・ワークステーションの適用のため
に、および、多くの現存するプリント・サーバーおよび
ファイル・サーバーの適用のために十分な演算パワーを
付与するものである。しかしながら、マルチプロセッサ
11のツリー状にされた階層的なアーキテクチュアによ
れば、ローカル・クラスタのバス・トランザクション
が、グローバルなメイン・メモリのトランザクションの
ようなグローバル・バス26上の大方のトランザクショ
ンから効果的に分離される。この結果として、バスに対
するバス・トラフィックと電気的なローディングとが分
散され、これによって、より大きくてより有力なマルチ
プロセッサの構成が許容される。
れているだけであるが、ここで理解されることは、階層
の任意所与のレベルにおける2本またはそれよりも多く
のバスを次に高いレベルにおけるバスと相互接続させる
ために、マルチプロセッサ11のツリー状にされたアー
キテクチュアが、キャッシュ・メモリの付加的な層(図
示されない)の使用を通して伸長可能にされるというこ
とである。ここで認められるように、キャッシュ・メモ
リ16aa−16ijおよび19a−19iはキャッシ
ュ・メモリのツリーとして構成されており、これらのキ
ャッシュの記憶能力は、典型的には、ツリーの深さが増
すにつれて減少するようにされている。階層の全てのレ
ベルにおいて同じバス・プロトコルが用いられているこ
とから、ある特定の適用についての特別の要求により良
く合わせるべくマルチプロセッサ11の再構成をするた
めに、システムの設計者は十分な自由度を有している。
25を介してトップ・レベルの“グローバル”バス26
に接続されているが、プロセッサおよびI/Oデバイス
は階層の任意のレベルにおいてバスに接続することがで
きる。バスの階層性は全てのバス・クライエント(即
ち、それぞれにプロセッサ12aa−12ijに対する
キャッシュ16aa−16ij;I/Oブリッジ18i
がホスト・バス15iと通信するときに介在するキャッ
シュ60;ローカル・エリア・ネットワーク(LAN)
30iおよびディスプレイまたはプリンタ・デバイス3
1iがそれぞれにホスト・バス15iと通信するときに
介在するコントローラ28iおよび29i;クラスタ1
4a−14iがそれぞれにグローバル・バス26と通信
するときに介在する第2レベルのキャッシュ19a−1
9i;および、メイン・メモリ13がグローバル・バス
26と通信するときに介在するコントローラ25)に対
して透明なものであり、このために、クライエントは、
可能性のあるシステム構成のいずれに対してもカスタム
化する必要がない。セクションI.D.において更に十
分に後述されるように、バス・クライエント・インタフ
ェースはシステム構成から独立している。
個の異なるレベル(即ち、バス・サイクルの電気的なレ
ベル、パケットの論理的なレベル、および、トランザク
ションの機能的なレベル)におけるバスの動作である。
規定すべきこととしては、“バス・サイクル”が任意の
所与バス上におけるクロックの完全な周期であることか
ら、それは単一のバスを介する電気的な情報の転送のた
めの時間的な単位である。これに対して、“パケット”
は、論理的な情報の転送のための連続的なバス・サイク
ルの近接しているシーケンスである。そして、“トラン
ザクション”は論理的な機能を実行するための“リクエ
スト”パケットおよびそれに対応する“リプライ”パケ
ットからなるものであって、ここでの論理的な機能と
は、データ・フェッチ操作(即ち、ある特定のメモリ・
アドレス位置からのデータの読み取り)またはデータ記
憶操作(即ち、ある特定のメモリ・アドレス位置に対す
るデータの書き込み)のようなことである。先に指摘さ
れたように、リクエスト/リプライの全てのペアは分離
していることから、“ペンディング・リクエスト”(即
ち、リプライを待っているリクエスト)に対して予め選
択されたタイムアウトの周期によって規定される制限に
なるまでは、いずれのトランザクションに対するリクエ
ストおよびリプライでも任意数のバス・サイクルによっ
て分離されることができる。特徴的なこととしては、各
パケットの第1のサイクル(いわゆる“ヘッダ”)はア
ドレスおよびコントロール情報を有しており、これに対
して、後続のサイクルはトランザクションの規定によっ
てしかるべく実行することを要求されたときのデータを
有している。
期的なものであるが、バス対バスの情報の転送が第2レ
ベルのキャッシュ19a−19iのようなキャッシュに
よって完全にバッファされることから、これらは必ずし
も互いに同期している必要はない。更に、より十分に後
述されるように、バス15a−15iおよび26の各々
は、裁定手段35a,35b,35iおよび36によっ
て独立に裁定されるものである。
ント・デバイス(規定すべきこととして、“クライエン
ト・デバイス”とは、−“バス・クライエント”として
参照されることもあるが−、ホスト・バス14a−14
iおよび26を介してパケットの送受をするデバイスで
ある)は、バス“マスター”およびバス“スレーブ”と
しての双方の機能を果たすことが可能でなければならな
い。しかしながら、ある所与のトランザクションを開始
するためのリクエスト・パケットを発するクライエント
が“リクエスタ”として規定されているとき、または、
このようなリクエストに応答してリプライ・パケットを
発する任意のデバイスが“レスポンダ”として規定され
ているときには、クライエント・デバイスのトランザク
ション・レベルにおける相互作用は幾らか理解し易いも
のである。ここで認められるように、任意の所与のリク
エストに対して1個を超えるレスポンダは存在しない。
スが裁定手段によって許容されることは、リクエスタに
よってなされる裁定のリクエストに応答することであ
る。バスの許容がなされたときには、このリクエスタは
バス“マスター”になり、これに次いでそのリクエスト
・パケットを発するようにされる。他の全てのバス・ク
ライエントはこのパケットによって保持されているアド
レスおよびコマンドを調べて、それらが何等かの動作を
するように要求されているかどうかの決定をする。1個
または複数個のクライエントは、要求された動作を実行
するために“スレーブ”としての動作の機能を果たすべ
く要求されているが、そのリクエスト・パケットを発す
ることが終了すると、該当のバスがリクエスタによって
即座に解放される。かくして、リプライ・パケットをリ
クエスタに対して返すことができるのに先だって裁定手
段からのバス・マスターシップを取得するために、レス
ポンダは、固有の独立した裁定リクエストをしなければ
ならない。このリプライ・パケットはリクエスタに対し
てアドレスされているから、このリクエスタはそれを受
け入れるためにスレーブ・モードで動作することにな
る。
5iまたはグローバル・バス26の任意のもの)は多く
のセグメントからなるものであるが、好適には、バスの
実行能力の低下を回避するために、いずれの単一のバス
内にも2個を超える双方向性のバス・セグメントが存在
しないようにされる。このために、図3−図5を参照し
て認められることは、コンピュータ・システムが、図3
におけるようなモノボード・コンピュータとして、図4
におけるようなマルチボード・コンピュータとして、ま
たは、図5におけるようなマルチボード/マルチモジュ
ール・コンピュータとして構成されるかどうかに拘ら
ず、各バスのセグメントが同期してクロックされるパイ
プライン・レジスタ37を介して接続されていることで
ある。この発明のバス・プロトコルに対しては、また
は、このプロトコルで確実にされるキャッシュの両立性
を維持するためには、パイプライン操作は必須のことで
はないけれども、1本または複数本のバスの電気的な特
性を最適化することは容易にされる。しかしながら、こ
こで理解されることは、バスの各々がパケットで切り換
えられることから、パイプライン操作が実現の可能性が
あるオプションであるということである。より詳細にい
えば、図3−図5に描かれているシステムは、それぞれ
に、2−レベル,3−レベルおよび4−レベルのパイプ
ライン操作のものである。好適には、パイプライン式の
バス・セグメントは短いものであり、また、一般的には
等しい長さのものであって、電気的な信号の伝播の遅れ
時間を最小にし、また、多少なりとも等しくするように
される。更に、実際には、バス・セグメントのあるもの
またはその全てが、不所望の信号の反射を抑制するため
に、平衡型の抵抗性終端部(図示されない)等によって
終端されている。しかしながら、ここで注意されるべき
ことは、バスとバス・プロトコルとの電気的な特性は互
いに独立しているということである。
いるような標準化されたバス・インタフェースは、バス
14a−14iおよび26をそれぞれの“クライエント
・デバイス”と電気的に相互接続させるために設けられ
ている。好適には、これらのバス・クライエントに備え
られているオープン・ドレイン型のCMOSドライバお
よびレシーバ(係属中であり譲渡された、1990年3
月30日に出願番号第07/502,372号として出
願の、William F.Gunningの米国特許
出願であって、“Drivers and Recei
vers for Interfacing VLSI
CMOS Circuits to Transmi
ssion Lines”,D/90153を参照)
は、それぞれに、バスに対する出力信号の適用をし、ま
た、バスからの入力信号を受け入れるためのものであ
る。インタフェース41のクライエント側においてこの
ようなドライバおよびレシーバを用いることの利点は、
それらの電力消費が著しく低く、現に利用可能なVLS
I技術を用いてこの発明を実施することが許容されるこ
とである。
ス41に備えられているものは、コントロール・ポー
ト、裁定ポート、受け入れポート、送出ポートおよび両
立性ポートである。インタフェース41のコントロール
・ポートに対して加えられるホスト・バスによるクロッ
ク信号は、インタフェース41とその関連のバス・クラ
イエント・デバイスとの間の全ての相互作用についての
タイミングをコントロールし、また、クライエント・デ
バイスによって要求される任意の他のクロック信号を導
出することができる基準を付与するためのものである。
コントロール・ポートには、同期ストップ出力信号(S
StopOut)のための出力および対応の同期ストッ
プ入力信号(SStopIn)のための入力も含まれて
おり、これによって、関連のクライエント・デバイス
は、システムを同期ストップに移行することが所望され
るときには、SStopOutを主張することができ
る。いずれのバス・クライエントによるSStopOu
tの主張であっても、バス上の全てのクライエントおよ
び該バスに対する裁定手段に対して“真の”SStop
In信号が加わるようにされ、これによって、クライエ
ントがSStopOutの主張を解除するまでは、バス
上の全ての活動を停止するようにされる。
意の所与時点において競合しているクライエント・デバ
イスの中でバス14a−14iおよび26を時間多重化
させ、これによって、それぞれのクライエントが、その
ホスト・バスに対する公平に拘束された時間的なアクセ
スを確保するようにされる。これらのクライエント・デ
バイスは、1本または複数本の専用リクエスト・ライン
によって、および、1本または複数本の専用許容ライン
によって、それらのホスト・バスに対する裁定手段に結
合されている。
スは、そのバス上にリクエスト・パケットまたはリプラ
イ・パケットを予め出力し、その1本または複数本の専
用リクエスト・ラインを介して、そのホスト・バスのた
めの裁定手段に対するバス・リクエストの送信をする。
大方の場合においては、裁定リクエストがなされるため
のリクエスト・パケットまたはリプライ・パケットをク
ライエントが十分にアセンブルした後で、該裁定リクエ
ストの送信がなされるものであるが、幾つかの場合にお
いては、クライエントによる待機時間を減少させるた
め、該クライエントがまだパケットのアセンブルをして
いる間に、裁定リクエストが裁定手段によって登録され
る。例えば、メイン・メモリ13の待機時間を減少させ
るために、メモリ・コントローラ25は、好適には、メ
イン・メモリ13からのリプライに含まれるべきデータ
の検索をしながら、ReadBlockのリプライ(よ
り詳細に後述される)に対するその裁定リクエストを登
録するようにされる。
手段が受け入れる裁定リクエストは異なる優先度を有し
ており、また、異なる長さのパケットの送信のためのバ
スを取得するようにされる(例えば、この初めの実施例
の実施においては、2−サイクル長および5−サイクル
長のパケットが用いられている)。このために、多くの
裁定リクエスト・ラインを設けることが好都合である
(図2および図6を参照)が、その理由は、クライエン
ト・デバイスによってわずか数クロック・サイクル(こ
の初めの実施例および増強された実施例に関して、それ
ぞれに、1サイクルの裁定リクエストおよび2サイクル
の裁定リクエストが後述される)の間にそれらの裁定リ
クエストをコード化することが、該多くの裁定リクエス
ト・ラインによって許容されるからであり、コード化す
ることを用いることにより、異なる優先度の裁定リクエ
ストと異なる長さのパケットの送信のための裁定リクエ
ストとの間での識別が、裁定手段によって可能にされ
る。いずれのクライエント・デバイスでも、任意の瞬間
におけるそのバス裁定手段と係属する多くの裁定リクエ
ストを備えている。裁定手段は、これに次いで、競合し
ているクライエント・デバイスについて係属する裁定リ
クエストの優先度を定めるための予め選択された裁定ル
ールを適用し、そして、専属の1本または複数本のライ
ンを介して、該競合しているクライエント・デバイスに
対してバス許容信号を次々に返すことにより、逐次的に
それらのリクエストを優先順位をもって許容していく。
例えば、1個または複数個のクライエント・デバイスの
任意のものが、ホスト・バスに対して異なる優先度の登
録された裁定リクエストを有するときに支配をする裁定
ルールにより、裁定手段が優先度の降下する順序に応じ
てそれらのリクエストを許容するようにされる。これに
対して、1個または複数個のクライエント・デバイスか
らの同じ優先度の裁定リクエストは、競合しているクラ
イエントの間で裁定を下すための“ラウンド−ロビン”
ルール、および、任意の所与のクライエントの多くのリ
クエストの間での裁定を下すためのFIFO(先入れ/
先出し)ルールを用いて適当に処理される。
いるように、各クライエント・デバイスは、2本の裁定
リクエスト・ライン38および1本の許容ライン39を
有している。これら2本の裁定リクエスト・ライン38
のために、4個までの異なる裁定リクエストをコード化
することがクライエントにより可能にされて、図7の4
0および41におけるような裁定手段によるデコード操
作をするようにされる。全てのバス・クライエントの裁
定の要求は、メイン・メモリ・コントローラを除いて、
それらのコード化に対して以下の意味を指定することに
よって満足することができる。 コード化 No. 意味 0 システム−ワイドの保持に対するデマンドの解除 1 システム−ワイドの保持に対するデマンド 2 低優先度の裁定リクエストの付加 3 高優先度の裁定リクエストの付加
は同じ優先度のものであることから、メイン・メモリ・
コントローラからの裁定リクエストは以下のように適当
に解釈される。 コード化 No. 意味 0 システム−ワイドの保持に対するデマンドの解除 1 システム−ワイドの保持に対するデマンド 2 短い(2サイクルの)パケットに対するリクエスト の付加 3 長い(5サイクルの)パケットに対するリクエスト の付加
いての前述の解釈が、(図示されない手段により)シス
テムの初期化の間に、裁定手段における裁定ポート内に
プログラムされる。より詳細にいえば、メモリ・コント
ローラに接続されているポート43のような裁定ポート
は、いわゆる“メモリ・ポート”として機能するように
プログラムされるが、これの意味することは、それらが
単一のFIFOリクエスト・レジスタを用いており、ま
た、短いリプライ・パケットおよび長いリプライ・パケ
ット(より高い優先度は“キャッシュ・リプライ優先
度”だけである)の双方に対して“メモリ優先度”が指
定されることである。別の裁定ポート42は、いわゆる
“正常ポート”として機能するようにプログラムされる
が、これの意味することは、低い優先度のリクエストお
よび高い優先度のリクエストを登録するために、分離し
たカウンタまたはレジスタが用いられるということであ
る。このために、関連したクライエント・デバイスによ
って低い優先度および高い優先度の裁定リクエストが形
成されるパケットの長さに関して、これらの裁定ポート
42の各々が更にプログラムされる。
タイプのクライエント・デバイスから裁定手段が受け入
れることができる、裁定リクエストに対する優先度の典
型的な指定は以下の通りである(下降する順序での優先
度)。 優先度 No. 指定 0 キャッシュのリプライの優先度 1 メモリ・コントローラおよびI/Oのリプライの優 先度 2 ディスプレイ・コントローラ・リクエストの高い優 先度 3 I/Oリクエストの優先度 4 キャッシュのリクエストの優先度 5 ディスプレイ・コントローラ・リクエストの低い優 先度
ーラ(図1の28iを参照)ではそのリクエストを満た
すために低い裁定の優先度が用いられていることから、
他のものがアイドル状態にあるバス・サイクル中に、通
常は、そのコントローラに対して伝送されるデータによ
ってディスプレイの駆動がなされる。しかしながら、デ
ィスプレイに対するデータ・キューが近傍のエンプティ
・レベルに落ちるときには、ディスプレイ・コントロー
ラは、そのデータ・キューを補充するために、幾つかの
リクエスト・パケットに対するその高い優先度のリクエ
スト・レベルを採用するようにされる。
に、2個の最も高い裁定の優先度がリプライに対して指
定される。これは、バスのデッドロックを回避するため
の、重要なフロー・コントロールのメカニズムである。
また、トランザクションの実行の遅れ(即ち、リクエス
トの発行とこれに応じるリプライの受け入れとの間の時
間)も減少される。しかしながら、リプライに対して与
えられる高い優先度は、オーバフローのリスクを冒しな
がら、そのトランザクション・リクエスト・レジスタ3
4(図2)に対して十分な個数のトランザクション・リ
クエストを累積するクライエント・デバイスの可能性を
増大させる。従って、このような渋滞を防止するため
に、裁定手段についてシステム・ワイドでの保持をデマ
ンドする任意のクライエント・デバイスによって求めら
れる第2のフロー・コントロールのメカニズムがある。
システム・ワイドでの保持に対するデマンドにより、リ
クエスト・パケットの送信についての許可を、裁定手段
がバスに対して出すことが不可能になることから、該裁
定手段は該バスをして、リプライ・パケットを送信する
ための裁定リクエストを出しているクライエントに専用
のものとする。一旦デマンドが出されると、このような
システム・ワイドでの保持により、そのデマンドを出し
ているクライエントによって解放されるまで、有効な状
態に留められる。これによって可能にされることは、渋
滞の状態にあるクライエントが、正常な動作が再開され
るのに先だってその渋滞の状態を解放するために、その
係属中のリクエストキューが十分に低いレベルまで降下
することを確実にすることである。
なるクライエント・デバイスは異なるレベルの優先度を
もつことができるけれども、ホスト・バスの割当が予め
強調されることはない。その結果として、そのホスト・
バスが許容されたクライエント・デバイスは、バス上で
完全なリクエスト・パケットまたはリプライ・パケット
を配することができるように、十分な時間的な周期にわ
たって“バス・マスター”であることになる。
は、裁定リクエストのコード化をすることの重要な利点
の一つとして、任意の処与のクライエントからの任意の
処与の裁定リクエストに対して、その処与の裁定リクエ
ストに応じてバスが許容されたときの、該処与のクライ
エントが発するパケットの長さを、裁定手段によって予
言的に決定することができる。これで許容されること
は、クライエントが発するパケットのために必要とされ
るバス・サイクルの正確な個数について、任意の処与の
クライエント・デバイスに対してバスが許容する時間の
長さを、裁定手段によって制限することである。より有
意義なこととしては、図8に示されているように、Gr
ant1 およびGrant2 のような連続的な許可のタ
イミングのコントロールが、裁定手段によって可能にさ
れる。このために、第2の許可(Grant2 )が発せ
られるのは、生じているパケットAの最終バス・サイク
ルに対する許可(Grant1)を現在のバス・マスタ
ーのクライエントが評価した直後である。次に続くバス
・マスターになるクライエントによって、この早期の許
可の告知のために可能にされることは、その直前のパケ
ットAの最終サイクルに追従するパケットBのはじめの
サイクルの間に、そのパケットBに対するヘッダー・サ
イクルをもってバスを駆動するために適当な高い電圧レ
ベルまで、バス・ドライバによって移行させるのに十分
な時間がもたらされることである。かくして、明瞭であ
ることは、裁定手段は、バス上のパケットの送信に関す
る時間的なオーバラップをしながらバスの裁定を実行す
るだけではなく、クライエントが全ての利用可能なバス
・サイクルをパケットで満たすことも許容することであ
る。
るような複数個のパイプライン式のバス・セグメントか
ら構成されているバスは、それらのクライエントが全て
の利用可能なバス・サイクルをパケットで満たすことも
許容するために、前述されたタイプの予測的なオーバラ
ップ式の裁定を用いるように所望されているときには、
ある程度の注意を払って設計されねばならない。これを
より詳細にいえば、連続的なパケットAおよびBは、こ
のようなバスの中間セグメントまたはいわゆる“バック
パネル”セグメント上において、該バックパネル・セグ
メントがバスの双方向性セグメントだけであるときにの
み、連続的なバス・サイクルに詰め込むことができる。
そうでないときには、パケットAおよびBを連続的なバ
ス・サイクルに詰め込もうとするいかなる試行でも、任
意の処与のバス・セグメント上でのそれら2個のパケッ
ト間での時間的なオーバラップに対する禁止によって妨
げられる。図3,図4および図5において示されている
ように、その解決策は、バックパネル・セグメントに対
するものを除いて、このようなバスの全てのセグメント
に対して単方向性のバス・セグメントを使用することで
ある。この解決策の有効性は図8において示されてい
る。ここで、図4に示されているバスの、それぞれに単
方向性の出力セグメントA1 およびA2からのパケット
AおよびBは、そのバックパネル・セグメントBを介し
て、それぞれに単方向性の入力セグメントC1 およびC
2 に至るようにされる。
および52は、サービスに責任のある全てのクライエン
ト・デバイスに対する各裁定手段に接続されている。あ
る処与のクライエント・デバイスに対するバスの許可の
直前のサイクルにおいて、いわゆるHIPGrantラ
イン51上の信号の論理的なレベルにより、次に続く許
可が高い優先度のリクエストに相応しているか否かの決
定がクライエント・デバイスによってなされ、また、い
わゆるLongGrantライン52上の信号の論理的
なレベルにより、次に続く許可が長いパケットに対する
ものであるか否かの決定がクライエント・デバイスによ
ってなされる。従って、これら2個の信号により、異な
る優先度の係属中の裁定リクエストに対する許可の間に
ついて、および、異なる長さのパケットの送信を認める
ために与えられる許可の間について、クライエントがそ
の区別をすることが可能になる。
ース ここで図1に戻ると、グローバル・バス26および14
a−14iのようなクラスタ・バスの各々は、2n で表
されるような2の累乗のビット・ワイドの多重化したデ
ータ/アドレス・パスを形成するようにされている。ク
ライエント・デバイスを単方向性のバス・セグメントに
接続するために、その標準的なインタフェース41(図
6)には1個の送出ポートおよび1個の受容ポートが備
えられており、その各々は、2n ビット・ワイドのデー
タ/アドレス・パス(この発明の典型的な実施において
は、各バスのデータ/アドレス・パスは64ビット・ワ
イドである)を構成している。しかしながら、インタフ
ェース41の送出ポートは双方向性のモードで動作でき
ることから、クライエント・デバイスを双方向性のバス
・セグメントに接続するために、送出/受容(送受両
用)ポートとして用いられることになる。
ポートおよび受容ポートにも、ヘッダー・サイクル・ビ
ットのための1本のワイヤおよびパリティ・ビットのた
めの1本のワイヤが含まれている。この実施例において
は、パケットのヘッダー・サイクルを同定するために、
バス・マスター(即ち、該当のパケットを発しているク
ライエント)による各パケットのはじめのサイクルの間
に、HeaderCycleの論理的な真(“1”)の
信号が出される。その他方において、受容側がデータ送
信のエラーを検出できるように、関連するパケットで搬
送されるデータからのパリティの算出がデータ源におい
てなされる。このパリティ・チェック操作は全く従来か
らのものであることから、この特定の実施例においてバ
スがアイドル状態にあるときの論理的なレベルがロー
(“0”)であるために、偶数パリティが採用されてい
ることを注意すれば十分である。
またはそれよりも多くのキャッシュ・メモリ・クライエ
ント内にキャッシュされている、メモリ・アドレスの各
々の全てのキャッシュされたコピーを通してデータの両
立性を維持するために、バス・デバイス・インタフェー
ス41は、それぞれに、キャッシュ・メモリからのSh
aredOut信号およびOwnerOut信号を送信
するための出力部62および63とともに、メモリ・コ
ントローラ(中間レベルまたはより高いレベルのキャッ
シュに対するコントローラを含んでいる)からのSha
redIn信号およびOwnerIn信号を受信するた
めの入力部61および62を備えている。
モリ・リクエスト(例えば、この実施例におけるWri
teSingle,CondituonalWrite
SingleまたはReadBlockReques
t)を出すときはいつでも、ある固定的な時間遅れの後
に、真の(論理“1”の)SharedOut信号の状
態がキャッシュによって主張される。その他方におい
て、SharedInは、バス上の全てのキャッシュか
らのSharedOut信号の、適当に遅れた論理的O
Rにされている。この論理的ORの操作に起因する遅れ
も固定されており、リクエストを受け入れたときにリク
エスタによって特定されたアドレスがバス上の他のキャ
ッシュのいずれかによって共有されているかどうかを決
定する為に、このようなリクエスト・パケットを受け入
れてからある所定の時間の後で、レスポンダによってS
haredIn信号のレベルが評価される。ここで認め
られるように、リプライ・パケットのヘッダー・サイク
ルにおける、いわゆる“replyShared”ビッ
トによって、そのリプライをレスポンダが発するときに
は、このSharedIn信号の値はリクエスタに戻さ
れる。そして、これにより、そのリクエストがなされた
ときに、そのリクエストが指向されたデータが共有され
ているか否かについて、リクエスタに告知するようにさ
れる。
りリクエスト(例えば、ReadBlockReque
st)において特定されるアドレスに存在するデータ・
ブロックの“owner”であるときはいつでも、ある
固定的な時間遅れの後に、真の(論理“1”の)Own
erOut信号の状態がキャッシュによって主張され
る。より詳細に後述されるように、データが特定のデー
タ・ブロックに書き込まれるときはいつでも、キャッシ
ュはデータ・ブロックの“owner”になる。これの
意味することは、その所有権は、たとえ存在するとして
も、最後にデータ・ブロックに書き込まれたキャッシュ
に属することから、任意の所与のデータ・ブロックにつ
いて、一時に1個の“owner”しか存在しないこと
になる。それにも拘らず、タイミングを簡略化するため
に、OwnerIn信号は、好適には、バス上のキャッ
シュからのOwnerOut信号の同様に遅れた論理的
ORであるから、リプライを出すか、または、データに
ついてのより低いレベルのキャッシュの“owner”
からのリプライに従うかを決定するためにShared
Inを評価するのと同じ時点において、バス上の最上位
のクライエント(即ち、メモリ・コントローラまたはよ
り高いレベルのキャッシュ)はOwnerInを評価す
ることができる。ここで認められるように、1個よりも
多くのキャッシュがOwnerOutを主張することは
できないために、キャッシュからのOwnerOut信
号のOR操作をすることは必須のことではないけれど
も、SharedInの値およびOwnerInの値に
ついて一様な扱いがもたらされることになる。
dIn信号の値およびOwnerIn信号の値が、ワイ
ヤ式のOR操作よりも論理的なOR操作によって演算さ
れるということである。これによってSharedIn
およびOwnerInのパイプライン操作が許容され、
その一方では、それらのタイミングおよび解釈上での電
気的な制約を回避するようにされる。所望されるときに
は、SharedOut/SharedIn信号の値お
よびOwnerOut/OwnerIn信号の値のパリ
ティ・チェック操作も許容される(増強した実施例につ
いての以下の説明において、このオプションの検討を参
照されたい)。
ある。各トランザクションは、独立して裁定されるリク
エスト・パケットおよびリプライ・パケットからなるも
のである。リクエスタがバスに対する裁定手段による裁
定リクエストを登録したときに、ある1個のトランザク
ションが始まるけれども、該裁定手段がバスに許可を出
すまでは、該当のリクエスト・パケットはそのリクエス
ト・レジスタ28に記憶される。該当のことが生起する
と、リクエスタは、連続的なバス・サイクルの間に、そ
のリクエスト・パケットを一時に1サイクルだけ発生さ
せる。
スト・パケットの初めのサイクルには、リクエスタおよ
びこのリクエスタが始めるトランザクションを同定する
ために必要な全ての情報が含まれている。これには、該
当のトランザクションを好適な結論に導くときに関与す
ることが必要な、1個または複数個のクライエント・デ
バイスを選択するために十分な情報も含まれている。リ
クエスト・パケットの後続のサイクルに一般的に含まれ
ているものは、実行されるべきトランザクションに依存
するデータである。全てのクライエント・デバイス(リ
クエスタを含む)はリクエスト・パケットを受け入れ
て、該当のトランザクションに関与することが要求され
ているか否かを決定するために、該デバイスの各々によ
ってそのヘッダー・サイクルを調べるようにされる。
ケットにおけるヘッダー・サイクルの相当な個数のビッ
トが、メモリ位置またはI/Oデバイス・レジスタの選
択をするために、リクエスタによって出されるアドレス
に対して保留される。デバイスがある1個のトランザク
ションにおいて関与するように選択されるメカニズム
は、異なるトランザクションのためには異なることがあ
り得るけれども、大方のトランザクションにおいては、
選択メカニズムとしてそのヘッダー・サイクルに含まれ
ているアドレスを使用するようにされる。
この実施例においては、各リクエスト・パケットにおけ
るヘッダー・サイクルの47ビットがアドレス・フィー
ルドに対して割り当てられている(この実施において
は、これらのビットの中の32ビットだけが用いられて
おり、このために、他の15ビットは更に別の伸長作業
のために利用可能なものであって、これの意味すること
は、それらが全て“0”であることを確認するためにア
ドレス・フィールドを読み取るときに、これらの使用さ
れないビットがチェックされねばならないということで
ある)。他のビットの中の10個のビットは、各クライ
エント・デバイスが指定される固有の識別子である、い
わゆる“DeviceID”を搬送するために保留され
ている(これらのDeviceIDは、図示されない手
段によるシステムの起動の間に適当に指定されるもので
ある)。更に、リクエストのヘッダー・サイクルにおけ
る残りのビットの中の5個のビットは、トランザクショ
ンのコマンドのコード化のために使用される。そして、
更に1個の余分のビットは、クライエント・デバイスに
よる保護的“モード”のチェック操作のために用いられ
る(このモードのチェック操作によってクライエント・
デバイスに可能にされることは、リクエスタが、特定さ
れたトランザクションを開始するように権限を付与され
ているかどうかを決定することであるが、このようなモ
ードのチェック操作はこの発明の範囲を超えるものであ
る)。従って、この特定の実施においては、リクエスト
のヘッダー・サイクルで指定のないビットは1ビットだ
けである。
くのクライエントがその内部的な状態を変更することが
できるけれども、1個だけのクライエント・デバイスが
任意の所与のリクエストに対してリプライを出すことに
なる。レスポンダは、初めに、部分的または完全にその
リプライのアセンブルをし、これに次いで、そのバスに
対する裁定手段をもって、バスの裁定リクエストの登録
をする。その後で、バスの許可がなされると、1個また
は複数個のデータ・サイクルによって追従されるヘッダ
ー・サイクルをもって再開する連続的なバス・サイクル
の間に、レスポンダは一時に1サイクルのリプライ・パ
ケットを送出する。例えば64ビット・ワイドのバスに
より、各データ・サイクル上での8オクテット(8ビッ
ト・バイト)のデータ転送ユニットが支持される。これ
に次いで、様々に異なるワードに基づくソフトウエア・
アーキテクチュアを実施するために、これらのバイトが
種々の長さのワードに組成される。
・パケットにおけるヘッダー・サイクルは、リクエスタ
から受け入れられたコード化したコマンド、リクエスタ
によって特定されたアドレス、および、リクエスタのD
eviceIDのビットを同定するトランザクションの
反復をする。典型的には、このレスポンダは、リクエス
ト・パケットにおけるヘッダー・サイクルからこの情報
を取り出して、リプライ・パケットにおけるヘッダー・
サイクルの構成の際に用いるためにそれを記憶するだけ
である。この情報によれば、リプライ・パケットが関係
するトランザクションを固有に同定するだけではなく、
リプライ・パケットをトランザクションのリクエスタに
対して明確にリンクするようにされる。
リプライ・パケットのヘッダー・サイクルについて考慮
すると、ここで好適に観察されることは、対応するリク
エスト・パケットにおけるヘッダー・サイクルに対して
ビット対ビットで等価のものであって、以下の例外が存
在する。即ち:(1)該当のパケットがリプライである
ことを指示するために、リクエスト/リプライ・フラグ
・ビットが反転される;(2)リプライのアセンブルを
しているとき、レスポンダがフォールトに遭遇したか否
かを指示するために、リクエスト・ヘッダーにおけるモ
ード・ビットが、リプライ・ヘッダーにおけるフォール
ト・ビットとして用いられる;そして、(3)レスポン
ダがトランザクションのためのリクエスト・パケットを
受け入れた時点において、該トランザクションに対して
特定されたアドレスでのデータが多くのキャッシュによ
って共有されたか否かを指示するために、リクエスト・
ヘッダーにおける不使用のビットが、replySha
redビットとして用いられる。このreplySha
redビットの機能については、更に十分に後述され
る。しかしながら、この点について適切に注意されるこ
とは、フォールトに遭遇したときにのみ、レスポンダが
フォールト・ビットを真の(“1”の)論理レベルの状
態に駆動するということである。そして、このようなフ
ォールトが生じたときにはいつでも、このビットはリク
エスタに対して効果的にこれを告知する。これにより、
該リクエスタをして、フォールト・コード(これは好適
にはリプライ・パケットにおける第2サイクルの32個
の下位順序のビットにおいて伝送される)を受け入れる
べく用意をさせる。フォールトの検出およびフォールト
・コードの発生はこの発明の範囲外のことである。
イスは、何等かの動作がそれらについて要求されている
かどうかを決定するために、リプライ・パケットにおけ
るヘッダー・サイクルを調べるようにされる。その動作
においては、異なるクライエント・デバイスの中でのリ
プライを明確にするためにDeviceIDが当てにさ
れる。しかしながら、ある種のクライエントは、多くの
未解決または係属のリクエストを持っている可能性があ
る。このために、好適には、多くのDeviceIDを
クライエントに対して指定することにより、または、そ
れらの未解決なリクエストに対するリプライを明確にす
るために、それらを可能化させるべく何等かの他の適当
な備えをすることにより、リプライがそれらのクライエ
ントの各々において更に明確にされる。
は、トランザクションは完了する。大方の場合におい
て、この発明のバス・プロトコルによれば、リクエスト
とリプライとの間で1対1の対応が成立する。しかしな
がら、ある種のリクエスト・パケットは対応のリプライ
・パケットを持っておらず、また、これと逆の関係も成
り立つが、その理由は、バス・プロトコルの実行による
ため、または、エラー等によるためのいずれかである。
かくして、このプロトコルは、不変のものとしてのリク
エスト/リプライのペアリングには依存しないことにな
る。これに代えて要求されることは、任意の所与のバス
上の全てのクライエント・デバイスが、到着の順序にお
けるそれらからの動作を要求するリクエスト・パケット
にサービスをすることだけである。ここで認められるよ
うに、この要求はデータの両立性を維持することの中心
にあるものである。
実施例のために規定されたトランザクションに対するリ
クエスト/リプライ・ペアのパケット・レングスを要約
するテーブルが以下に示されている。 トランザクション・ペア 省略形 コード化 レングス 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
タイプのトランザクションがある。即ち、(a)キャッ
シュされたデータの両立性を維持しながら、メモリ・ア
クセス動作を実行するためのメモリ・トランザクショ
ン、(b)プログラムされたI/O動作を実行するため
のI/O・トランザクション、および、(c)更に他の
機能を実施するための多面的なトランザクションがあ
る。ここで評価されるように、リクエスト/リプライ・
フラグ・ビット(即ち、前述のテーブルにおいて示され
ているようなコマンド・フィールドの第5ビット)の論
理的なレベル(“0”または“1”)は、任意の所与の
パケットがリクエストまたはリプライのいずれであるか
を指示するためには十分なものであることから、トラン
ザクションのコマンドの極めてコンパクトで効率的なコ
ード化をすることが実際的である。このコマンド・フィ
ールドのフォーマットを用いて、16個までの異なるコ
マンドのコード化をすることが可能であるから、上記の
ように規定されたトランザクションでは、コマンド・フ
ィールドの容量を部分的に消耗するだけであることが理
解される。勿論、所望であるときには、付加的な特徴を
実現する更に別のトランザクションを規定するために、
コマンド・フィールドの余分の容量を用いることができ
る。
とメモリとの間でのデータの転送をするためにメモリ・
トランザクションが用いられる。これをより詳細にいえ
ば、メイン・メモリ13または他のキャッシュからデー
タ・ブロックを読み取るために、所望のデータ・ブロッ
クのバージョンがメモリ・システムのいずれかの位置に
キャッシュされているかどうかに依存して、そして、そ
うであるときには、該キャッシュされたバージョンが
“owned(所有されている)”であるかどうかに依
存して、ReadBlockがキャッシュ・リクエスタ
によって呼ばれる。所有されているデータ・ブロック
(即ち、局部的に初期化された書き込み−即ち、メモリ
・ツリーの同じブランチにおけるプロセッサによって初
期化された書き込み−によって最近に修正されたデータ
のブロック)をメイン・メモリ13に対して書き戻すた
めに、FlushBlockがキャッシュ・リクエスタ
によって呼ばれることができる。そして、WriteB
lockは、任意の中間的なレベルのキャッシュ19a
−19iおよびトランザクションに対して特定されるア
ドレス上で合致する任意の第1のレベルのキャッシュ1
6aa−16aj(図1を参照)に対するのと同様に、
データ・ブロックをメイン・メモリ13に対して直接書
き込むために、2次的なデータ源(即ち、メモリ・シス
テムに対して外部にあるデータ・プロデューサ)を可能
化するために利用できるものである。換言すれば、この
WriteBlockで許容されることは、キャッシュ
を通してデータを迂回させることなく、新規なデータを
マルチプロセッサ11の主要なメモリ・システムに導入
することである。
全ては、物理的なアドレス空間に直列に整列している4
個の64−ビット・ワードのような、複数個の連続的な
ワードにわたっている。そのために、任意のこのような
データ・ブロック内の第1の個別にアドレス可能な量の
アドレスは0 mod Nであり、ここに、Nは各デー
タ・ブロックに含まれている個別にアドレス可能な量の
個数である。有利なことに、各バス上での全てのデータ
・ブロックの転送の組成は、アドレスされた量がバス上
の第1のデータ・サイクル内に現れ、データ・ブロック
の残りの量がサイクリックな順序でこれに追従するよう
にされていることである。図11を参照されたい。これ
により、特定されたアドレスからデータを検索するため
のメモリの待機が最小にされるが、これはキャッシュ
“ミス”のときには特に望ましいことである。
は、共有しているデータについて多くのキャッシュされ
たコピーを更新するために、必ずしもメイン・メモリ1
3に影響をおよぼすことなく、キャッシュ・リクエスタ
によって呼ばれる。このトランザクションは、影響のあ
るデータ・ブロックのコピーを含んでいるキャッシュに
よってのみ呼ばれるものである。Conditiona
lWriteSingleは、このように共有されてい
るデータに対して微細な読み取り−修正−書き込みの実
行をするために、キャッシュ・リクエスタによって呼ぶ
ことができる、密接な関連のあるオプション的なトラン
ザクションである。
コントローラ29iのようなI/Oデバイスとの間で、
プロセッサがデータの転送をすることが許容される。こ
れらのI/Oトランザクションのために採用されるアド
レス空間(即ち、“I/O空間”)は、全体としては、
メモリ・トランザクションのために使用されるアドレス
空間(即ち、“メモリ空間”)とは関連しておらず、こ
のために、ある所与の有効なアドレスがメモリ空間また
はI/O空間のいずれかに存在するけれども、その双方
に存在することはない。ここで認められるように、I/
Oトランザクションはデータの両立性についての関連を
持たず、また、データ両立性プロトコルはI/Oトラン
ザクションについての関連を持たないものである。
OWriteトランザクションは、この実施例におい
て、I/O動作を実行するために規定されたものであ
る。各I/Oデバイスは共通のアドレス空間の固有の部
分が指定されており、これらのトランザクションは該当
のアドレス空間に対して発せられる。このために、図1
におけるコントローラ29iのようなI/Oデバイス
は、それらに対してアドレスされるI/Oコマンドを解
釈することが自由であり、所要に応じて、それらを所望
のトランザクションに対して効率的に関与させることが
できる。IOReadトランザクションおよびIOWr
iteトランザクションは、キャッシュ・リクエスタに
より起動されて、それぞれに、特定されたI/Oアドレ
スとの間でアドレス可能な量の読み取りおよび書き込み
をするようにされる。BIOWriteもキャッシュ起
動式のトランザクションであって、I/Oアドレス空間
に対して単一のアドレス可能な量を書き込むためのもの
であるが、ある所与の“デバイス・タイプ”の多くの事
例に対してデータを同時に書き込むことが許容されてい
るために、I/OWriteトランザクションとは異な
るものである。このために、BIOWriteは無制限
のグローバルな放送的トランザクションではないけれど
も、ある所与のタイプの全てのデバイスに対しては放送
的なものである。“デバイス・タイプ”の規定はシステ
ムに依存するものであり、この発明の範囲を超えてい
る。
ブリッジに移行して理解されるべきことは、メモリ・シ
ステムに関する限りはそれがハイブリッド・デバイスで
あるということである。より詳細にいえば、このI/O
ブリッジ・デバイス18iは、キャッシュ16aa−1
6ijと機能的に類似のキャッシュ60を介してマルチ
プロセッサ11のメモリ・システムに直接アクセスす
る、外部系列のコンピュータ・システムのメモリ・バス
のような、非同期的なI/Oデバイスを備えるために有
用なものである。その目的のためにブリッジ18iに含
まれているもの(図示されない)は、このようなI/O
デバイスによって出されたメモリの読み取りおよび書き
込みをバッファリングするための、そして、それらの読
み取りおよび書き込みを規定のメモリ・トランザクショ
ンに変換するためのものである。しかしながら、それは
I/O空間の部分内のI/Oトランザクションにも応答
するものであるが、その意味するところは、プロセッサ
12aa−12ijがI/Oブリッジ18iの内部資源
および該ブリッジ18iが接続されるI/Oデバイスの
レジスタをアクセスできることである。
はないが、その理由は、マルチプロセッサ11のいずれ
かのバスに接続され得る異なるI/Oデバイスについて
のI/Oアドレス空間のサイズに関する要求が相当に異
なっていることにあるだけである。従って、実際的な態
様としては、各I/Oデバイスに対するI/Oアドレス
空間の指定が該デバイスにとって必要であるようなアド
レス空間と合理的に近似することが確実であるように、
I/Oアドレス空間を指定するときにこれらの差異を考
慮に入れるべきである。
ザクションであって、マルチプロセッサ11の仮想メモ
リ環境において高速の仮想的−物理的アドレス空間のマ
ッピングを実行するためのものである。その目的のため
に、Mapでキャッシュ・リクエスタが許容されること
は、図1の17aにおけるようなマップ・キャッシュか
ら、仮想的ページ−物理的ページのマッピング・エント
リを読み取ることである。これに対して、DeMapに
よれば、仮想的なアドレス空間の任意特定のページに対
するキャッシュ駐在の仮想的−物理的アドレス・マップ
を無効にするために、キャッシュ・リクエスタが可能に
される。
プロセッサ環境において必須であることは、メモリ空間
における任意の所与のアドレスに対するデータ値を同じ
シーケンスでアクセスすることである。これは“データ
の両立性”として参照される。このようなマルチプロセ
ッサにおける個別のプロセッサに対して分離したキャッ
シュ・メモリを用いることは、このデータの両立性を維
持するという問題を複雑にするものであり、特に、より
大規模なシステムにおいて、任意の所与の時点において
キャッシュ内に存在し得るある所与のコピーの潜在的な
個数が大きいときに問題を複雑にするものである。
性のプロトコルを実施することは、プロセッサ12aa
−12ijおよびI/Oブリッジ18iによって要求さ
れるメモリ・トランザクションの開始および実行をする
ために、いわゆる書き戻しキャッシュ(即ち、メイン・
メモリを即座に更新することなく、プロセッサによって
出されたデータの書き込みに従ってキャッシュされたデ
ータの更新をするキャッシュ)を用いることによって可
能にされる。これらのキャッシュは、メモリ空間におけ
る全てのアドレスからの要求に応じてデータのフェッチ
および記憶をすることができるが、その理由は、メモリ
空間内の任意の所与のアドレスにおけるデータの多くの
コピーの外部的な両立性が、上述されたトランザクショ
ンのある所定のものの使用を通して、ハードウエアによ
って自動的かつ透明的に維持されるためである。更に、
プロセッサ12aa−12ijおよびI/Oブリッジ1
8iに対するメモリの両立性のある観察を維持しなが
ら、I/Oデバイスによるメモリ空間に対する直接アク
セスが許容される。
ャッシュ12aa−12ij,19a−19i,60
は、それぞれのバス上のトラフィックを直接または間接
にモニタすることによってデータが共有されるようにな
った時点を検出し、また、任意のプロセッサ(またはI
/Oブリッジ18i)がメモリ空間における共有のデー
タ値を更新したときには、いつでも放送的な書き込みを
実行する。キャッシュ12aa−12ijおよび60の
全ては“スヌーピー・キャッシュ”であるが、これの意
味することは、それらがバス上の全てのトランザクショ
ンをモニタすることにある。
るデータの両立性 先に指摘されたように、シングル・レベル・システムを
構成する1個または複数個のプロセッサは、図1におけ
るプロセッサ12aa−12ajのようなものであっ
て、共有のメイン・メモリとともに、それぞれのキャッ
シュ16aa−16ajを介して、それらのメモリ・バ
ス15aと接続されている。プロセッサ12aa−12
ajは、それぞれに、それらのキャッシュ16aa−1
6ajを介してメイン・メモリをアクセスしていること
から、任意の所与のアドレスにおける全てのキャッシュ
されたコピーの間のデータの両立性を維持することで十
分であることが明かにされてくる。これの意味すること
は、キャッシュされているメイン・メモリのコピーが、
1個または複数個のキャッシュされたコピーに関しては
古いことがあり得ることであるが、この古いメイン・メ
モリのデータに起因する演算上のエラーのリスクを負う
ことはない。
プロトコルが依存する各キャッシュは、特定のキャッシ
ュの要求においてバス上で係属しているトランザクショ
ンに従う任意のデータ・ブロックに対するpendin
gStateとともに、キャッシュしている各データ・
ブロックに対する“共有”および“固有”の2個の状態
ビットを保持している。これに加えて、通常は、キャッ
シュ16aa−16ajは、現にキャッシュされている
データ・ブロックと、オーバライト可能な削除された、
または、“空白の”データ・ブロックとの間の区別をす
るために、それらのデータ・ブロックの各々に対する
“有効”状態ビットを保持している。
連のデータ・ブロックについて多くのキャッシュされた
コピーが存在し得るか否かということである。多くのキ
ャッシュされたコピーが存在するときには、該共有ビッ
トは真の(“1”の)状態に肯定的にセットされるが、
キャッシュされたコピーが1個しか存在しないときに
は、必ずしも偽の(“0”の)状態にはリセットされな
いことから、これは控え目な指示である。これに対し
て、ある所与のキャッシュを介して通信するプロセッサ
その他のデバイスが、特定のデータ・ブロックに対する
最近の(即ち、最後の)書き込みを実行する責任があっ
たときにのみ、該データ・ブロックに対する固有ビット
が該所与のキャッシュにおいて真の(“1”の)状態に
セットされる。これの意味することは、バス上の1個ま
たは複数個の他のキャッシュも同じデータ・ブロックの
コピーを含んでいるとしても、任意の所与のバス上での
任意の時点におけるある所与のデータ・ブロックについ
て、“固有”のキャッシュは1個だけということであ
る。これに加えて、バス上で係属している各トランザク
ションに対してキャッシュが維持するpendingS
tateによってキャッシュにできることは、トランザ
クションがまだ係属中であるときに該当のデータ・ブロ
ックのキャッシュされたコピーの個数が変化するとして
も、リプライが受け入れられたときに、トランザクショ
ンが関連しているデータ・ブロックに対するその共有ビ
ットのための値を正確に演算することができる。このp
endingStateの情報によってキャッシュにで
きることは、より十分に後述されるように、該当のトラ
ンザクションに対する正確なデータ値を得るべく、キャ
ッシュが適切な動作をするように、その係属中のトラン
ザクションによって特定されるアドレスにおけるデータ
の値を修正できる介在のトランザクションを同定するこ
とでもある。
ッサがフェッチ・コマンドまたは記憶コマンドを発生し
たときには(即ち、このようなコマンドが発生されるべ
きアドレスがキャッシュ内に存在しないときには)、第
1のレベルのキャッシュでReadBlockRequ
estが起動して、“キャッシュ・ミス”が生じるよう
にする。必要であるときには、キャッシュからメイン・
メモリにデータを書き込み、これによって新規なデータ
を記憶するためのキャッシュ内の記憶スペースを自由に
するように、このキャッシュもFlushBlockを
起動させることができる(ここで想起されるように、古
いデータをメイン・メモリに書き込むことを回避するた
めに、それらの固有ビットのセットを有するデータ・ブ
ロックだけがFlushBlockによって書き出され
ることになる)。共有ビットのセット(“1”)を有す
るデータ・ブロックに対して関連のあるプロセッサによ
る書き込みがなされるときには、更にキャッシュによっ
てWriteSingleトランザクション(これは前
述された書き込みであって、データの両立性が無視でき
るときには、必要とされる最小のセットの動作から両立
性プロトコルを区別することである)が始められる。
は、RBRqst,WSRqst,WSRply,CW
SRqst,CWSRply,およびWBRqstパケ
ット(即ち、特定されたアドレスにおけるデータの値お
よび/または非共有状態に影響があり得るパケット)の
いずれかのヘッダー・サイクルにおいて特定されるアド
レスに合致させようとする。その係属中のトランザクシ
ョンの各々に対してリクエスタが維持しているpend
ingStateに含まれているデータのアドレスは、
リクエスタがその固有のリクエスト・パケットを受け入
れたときに偽の(“0”の)状態にクリアされる共有の
状態とともに、同じアドレスを特定する前述のタイプの
介在パケットをリクエスタが検出できるためのトランザ
クションに従うものである。これでリクエスタが可能に
されることは、トランザクションが係属中である間に特
定のデータ・ブロックが共有の状態になるときに、その
係属中のトランザクションに従う任意のデータ・ブロッ
クに対する共有の状態を真の(“1”の)状態にセット
することである。更に、ある程度詳細に付加的に後述さ
れるように、トランザクションが係属中である間に、デ
ータの値が、係属中のトランザクションが変化されるの
に従っているときには、リクエスタによって適当な訂正
動作をすることも可能にされる。
て簡単に合致されることは、上記のように列挙されたヘ
ッダー・サイクルにおいて特定されたアドレスを、それ
らがキャッシュしているデータ・ブロックのアドレスに
対抗させて、該特定のアドレスが含まれているかどうか
を決定するためである。FlushBlockトランザ
クションは、そのような動作がなされている他のキャッ
シュに対して告知をすることを必要とせずに、キャッシ
ュからメイン・メモリへのデータ・ブロックの書き込み
だけのために使用されるものであることから、このよう
な合致操作はFBRqstパケットまたはFERply
パケットのいずれかのために必要とされることはない。
同様にして、メモリが対応のWBRqstパケットを処
理したことを確認するだけであることから、WBRpl
yに対するアドレスの合致操作は不要である。更に、R
BRplyはリクエスタだけに関連するものであるか
ら、他のキャッシュはこのようなパケットを無視するこ
とができる。
Rqstパケットのヘッダー・サイクルにおいて特定さ
れるアドレスと好都合に合致しているリクエスタを除く
各キャッシュは、そのバス・インタフェース41(図
6)の両立性ポートにおけるSharedOutの主張
をし、これによって、該当する特定のアドレスにおける
データ・ブロックが共有されていることの信号をする。
このようなキャッシュも、先にそのようにセットされて
いないときには、該特定されたデータ・ブロックのその
コピーに対する共有ビットを真の(“1”の)状態にセ
ットする。ここで想起されるように、全てのリクエスト
・パケットおよびリプライ・パケットのヘッダーはDe
viceID(図9および図10を参照)を備えてい
て、それらが任意の所与のパケットに対するリクエスタ
であるか否かについて、バス・クライエントで決定する
ことが可能にされる。
キャッシュによるSharedOutの主張は、データ
・ブロックのキャッシュ・オーナまたはメイン・メモリ
13(キャッシュ・オーナが存在しないとき)によって
リプライが付与されるかどうかには拘らず、対応するリ
プライ・パケットのヘッダー・サイクルにおけるrep
lySharedビットを真の(“1”の)状態にセッ
トさせるのに十分なものである。これは次の事実に従う
ものである。即ち、キャッシュからのSharedOu
t信号は(図示されない手段により)論理的にORがと
られ、共有ライン61(図12)を介して、全てのバス
・クライエント・インタフェース41の両立性ポートに
加えられるSharedIn信号の値を完成するように
される。
るトランザクションに対するリプライのヘッダー・サイ
クルにおいて受け入れるreplySharedビット
と、該トランザクションのためにそのpendingS
tateにおいて維持される共有ビットとのORをとる
ようにされる。このために、リクエスタがそのリクエス
ト・パケットを発したときにデータ・ブロックが他のキ
ャッシュ内に存在しているとき、または、リクエスタが
そのリプライを待機している間にデータ・ブロックが他
のキャッシュ内にコピーされたときのいずれかであると
きには、特定されたデータ・ブロックのそのコピーに対
するリクエスタの共有ビットは、そのリプライを受け入
れたときに真に(“1”に)セットされる。
るリクエスタはデータ・ブロックのそのコピーに対する
その共有ビットのセットまたはリセットをする。このデ
ータ・ブロックに関連するトランザクションは、それを
受け入れる対応のリプライ・パケット(図10参照)の
ヘッダー・サイクルにおけるreplySharedビ
ットの状態、および、該当のリプライが受け入れられる
ときのそのpendingStateの共有状態に依存
するものである。リプライのヘッダーにおけるrepl
ySharedビットが偽の(“0”の)状態にあると
き、および、該トランザクションに対するそのpend
ingStateにおける共有状態が偽(“0”)であ
るときの双方であるときには、その書き込みがなされて
いるデータ・ブロックのコピーが他のキャッシュには含
まれていないことが、リクエスタによって確認される。
従って、リクエスタはこれに次いで特定のデータ・ブロ
ックに対するその共有ビットを偽の(“0”の)状態に
リセットし、これによって、データ・ブロックの状態が
共有状態から非共有状態に変更されるときに、該共有ビ
ットが最終的に確実にリセットするようにされる。
キャッシュが維持しているオーナ・ビットの扱いは更に
簡単なことである。これを略述すれば、そのプロセッサ
の側でデータ・ブロックへの書き込みがなされるときは
いつでも、キャッシュにおいて、データ・ブロックに対
するそのオーナ・ビットのセットがなされる。これに対
して、キャッシュにおいては、データ・ブロックに含ま
れているアドレスのために、任意の他のキャッシュによ
って要求されるWriteSingleまたはCond
itionalWriteSingleトランザクショ
ンに対するWSRplyまたはCWSRplyにおける
特定のアドレスで、該キャッシュをして好都合に合致す
るようにさせるときにはいつでも、データ・ブロックに
対するそのオーナ・ビットのリセット(クリア)がなさ
れる。データ両立性のプロトコルに関する限り、Wri
teSingleおよびConditionalWri
teSingleは完全に等価のものであるから、ここ
で理解されるべきことは、共有ビットおよびオーナ・ビ
ットに対するWriteSingleトランザクション
の効果についての以下の説明は、Conditiona
lWriteSingleに対して良好に当てはまるも
のである。
ば、それぞれのキャッシュ内に存在するデータ・ブロッ
クにデータを書き込むことにより、共有メモリ・システ
ムへのデータの記憶がなされる。データ・ブロックに対
する共有ビットが偽の(“0”の)論理レベルにある間
に、関連のキャッシュ内に存在するデータ・ブロックの
一つのワードまたはアドレス可能な量の一つにおいて、
ある所与のデータ値を記憶させるための記憶コマンドが
プロセッサから発せられたときには、該プロセッサは即
座にキャッシュされたデータ・ブロックの適切な部位
(例えば、ワード)の更新を行い、これと同時に、該当
のデータ・ブロックに対するオーナ・ビットのセットを
する。これに対して、プロセッサによる記憶コマンドが
指向されるデータ・ブロックに対する共有ビットが真の
(“1”の)論理レベルにセットされたときには、該キ
ャッシュは記憶コマンドの実行を留保してWSRqst
パケットを発する。このWSRqstパケットによれ
ば、(a)該プロセッサがその記憶コマンドに指向した
物理的アドレス(この物理的アドレスは典型的にはプロ
セッサによって付与された仮想的アドレスの変換によっ
て規定される)が同定され、また、(b)該プロセッサ
によって生成されたデータ値を含むようにされる。
ル・システムにおけるメモリ・コントローラからのもの
である。更に、1個のWSRplyパケットは、対応す
るWSRqstパケットの物理的アドレスおよびデータ
値の双方を写しているものである。このために、そのW
SRplyパケットを受け入れると、キャッシュ・リク
エスタは、そのプロセッサに対するデータの記憶を実行
するだけではなく、該プロセッサのデータが真の
(“1”の)状態に書き込まれるデータ・ブロックに対
するそのオーナ・ビットのセットも実行する。このWS
Rplyパケットのヘッダー・サイクルにおいて特定さ
れるアドレス上で合致する他のキャッシュのいずれであ
っても、(a)リプライ・パケットによって与えられる
データ値に基づいてアドレスされる、該リプライ・パケ
ットに対するそれらのデータのコピーを更新し、また、
(b)偽の(“0”の)状態に更新されたデータ・ブロ
ックに対するそれらのオーナ・ビットをリセットするよ
うにされる。ここで認められるように、これで確実にさ
れることは、任意の所与のバス・サイクルの間に、いず
れのキャッシュであっても任意の所与のデータ・ブロッ
クについての所有権を主張できないということである。
これの意味することは、メイン・メモリから読み取られ
てから書き込みがなされていない、いずれのキャッシュ
されたデータ・ブロックについて、いずれのキャッシュ
による所有権の主張もなされないということである。
ャッシュ・リクエスタがある特定のアドレスにおいてデ
ータ・ブロックに対するそのバス上にRBRqstパケ
ットを生成させたときには、該データ・ブロックは該バ
ス上での他のキャッシュに固有のものになったり、なら
なかったりできるということである。しかしながら、他
のキャッシュの一つが特定のデータ・ブロックを固有の
ものにしているときには、そのオーナ(および、恐らく
は1個または複数個の他のキャッシュの)はそのアドレ
ス上で合致するようにされて、これにより、それらの各
々がSharedOutを主張するようにされる。更
に、このオーナはOwnerOutの主張も行い、これ
によりOwnerOut信号の論理的ORをとるように
もされて、OwnerInライン62(図12)を真の
(“1”の)状態に駆動するようにされる。Owner
In信号の真の(“1”の)状態により、メイン・メモ
リがRBRqstに応答することが防止されて、対応の
RBRplyパケットを供給するための責任が特定のデ
ータ・ブロックについてのキャッシュ・オーナに転嫁さ
れる。これに対して、キャッシュのいずれも該特定のデ
ータ・ブロックの所有権を主張しないときには(即ち、
OwnerIn信号が偽(“0”)であるときには)、
該データ・ブロックが共有されているものであっても、
メイン・メモリからRBRplyが供給される。
切り換えで生成されるリスクは、データ・ブロックの所
有権の変化がなされるのは、リクエスタがRBRqst
を発した後であるが、対応のRBRplyを受け入れる
前であるということである。例えば、リクエストが発せ
られる時点においてメイン・メモリに固有のものである
データ・ブロックに対して、キャッシュはRBRqst
を発することができる。しかしながら、僅かな時間だけ
早いときには、その同じデータ・ブロックに対して新規
なデータを書き込むために、他のいずれかのキャッシュ
がWSRqstを発していることがある。ここでのリス
クは、リクエスト・パケットの到着順にメモリによるサ
ービスがなされるために、RBRplyパケットに先だ
って、WSRplyパケットがメモリによって発せられ
ることである。もし、これが生じたとすると、Writ
eSingleトランザクションを開始させたキャッシ
ュが、該データ・ブロックのオーナになる。データ・ブ
ロックの所有権におけるこの介在的な変化にも拘らず、
そのようにできるときには、メイン・メモリ13(図
1)はまだRBRplyを供給することになる。これの
理由は、RBRqstが受け入れられたときに、特定の
データ・ブロックについて、キャッシュ・オーナがその
所有権を主張する用意がなかったからである。これの意
味することは、このRBRqstパケットによって付与
されたデータは古いということである。従って、古いデ
ータの取り込みを回避するためには、リクエストされた
データ・ブロックに対する正しい値を算出するため、ま
たは、その当初のRBRqstに対するRBRplyの
受け入れの後でのReadBlockの再試行を始める
ためのいずれかのために、ReadBlockリクエス
タにおいては、そのRBRqstに対するpendin
gStateが用いられる。そのリクエストが古いデー
タの使用を避けるために係属している間に、ReadB
lockリクエスタが考慮に入れることを必要とするパ
ケットは、そのRBRqstパケットがアドレスされる
データ(WSRply、CWSRplyおよびWBRq
st)を修正するためのものである。
eBlockトランザクションはFlushBlock
トランザクションに類似しているけれども、これと等価
のものではない。キャッシュはFBRqstを無視する
けれども、WBRqstを無視することはない。これに
代えて、WBRqstによって特定されるアドレス上で
合致する任意のキャッシュにより、そのアドレスで合致
しているデータ・ブロックを、WBRqstパケットに
よって含まれているデータ・ブロックをもってオーバラ
イトされ、そして、該当のデータ・ブロックに対するそ
のオーナ・ビットを偽の(“0”の)状態にリセット
(クリア)するようにされる。
性プロトコルについての前述の説明に対して、ある種の
有用な見通しが付加される。ここで認められるように、
次に続く例において説明されることは、特定されたメモ
リ位置(アドレス73)に対するイベントのシーケンス
であって、図12に示されている共有メモリ・システム
83における5個のキャッシュ82a−82eのいずれ
にも該当のアドレスが含まれていない状態から出発する
ようにされている。その便宜のために、この例において
用いられている参照数字は、図12において用いられて
いる参照数字に対応している。 1. a.プロセッサ81aでアドレス73を読み取
る。 b.キャッシュ82aはミスして、バス85上のRea
dBlockを実行する。 c.メイン・メモリ86でリクエストされたデータを付
与する。 d.データ・ブロックのキャッシュされたコピーに対す
る状態ビットは:Shared82a =0,かつOwne
r82a =0である。 2. a.プロセッサ81bでアドレス73を読み取
る。 b.キャッシュ82bはミスして、バス85上のRea
dBlockを実行する。 c.キャッシュ82aはアドレス73を含んでいるデー
タ・ブロックに対するそのSharedビットを真の
(“1”の)状態にセットし、また、SharedOu
tを主張して、ある所定の遅れの後に、SharedI
nライン61が真の(“1”の)状態になるように駆動
される。 d.メモリ86はまだデータを付与する。 e.データ・ブロックのキャッシュされたコピーに対す
る状態ビットは:Shared82a =Shared82b
=1;Owner82a =Owner82b =0である。 3. a.プロセッサ81cでアドレス73を読み取
る。 b.キャッシュ82cはミスして、バス85上のRea
dBlockを実行する。 c.キャッシュ82aおよびキャッシュ82bはSha
redOutを主張して、これにより、SharedI
nライン61が再びハイ(“1”)になるように駆動さ
れる。 d.メモリ86はまだデータを付与する。 e.データ・ブロックのキャッシュされたコピーに対す
る現在の状態ビットは:Shared82a =Share
d82b =Shared82c =1;Owner82a =Ow
ner82b =Owner82c =0である。 4. a.プロセッサ81cでアドレス73を書き込
む。 b.データが共有されていることから、キャッシュ82
bがバス85上でWriteSingleを実行する。 c.キャッシュ82aおよびキャッシュ82cはSha
redOutを主張して、これにより、SharedI
nライン61がハイ(“1”)に駆動される。 d.キャッシュ82a,キャッシュ82bおよびキャッ
シュ82cはアドレス73におけるそれらの値を更新す
るが、メモリ86は実行しない。 e.キャッシュ82bはアドレス73を含むデータ・ブ
ロックのオーナになる(Owner82b =1)が、そう
ではないデータ・ブロックのキャッシュされたコピーに
対する共有状態ビットおよび固有状態ビットは変化しな
い。 5. a.プロセッサ81dでアドレス73を読み取
る。 b.キャッシュ82dはミスして、バス85上のRea
dBlockを実行する。 c.キャッシュ82a,キャッシュ82bおよびキャッ
シュ82cはライン61上のSharedInに対する
SharedOutを主張する。 d.キャッシュ82bはOwnerOutを主張し、こ
れにより、ある所定の遅れの後で、OwnerInのラ
イン62を真の(“1”の)状態に駆動するようにされ
る。これにより、メイン・メモリ86の応答が禁止され
る。これに代えて、データ・ブロックがそのオーナ・キ
ャッシュ82bによって付与される。 e.キャッシュ82dはデータ・ブロックのそのコピー
を、Shared82d =1,Owner82d =0,とし
てマークする。そうではないデータ・ブロックのキャッ
シュされたコピーに対する共有状態ビットおよび固有状
態ビットは変化しない。 6. a.プロセッサ81dで現在のアドレス73を書
き込む。 b.データは共有されていることから、キャッシュ82
dはバス85上でWriteSingleを実行する。 c.キャッシュ82a,キャッシュ82bおよびキャッ
シュ82cはSharedOutを主張して、Shar
edInのライン61が再びハイ(“1”)に駆動され
る。 d.アドレス73を含むデータ・ブロックの所有権がキ
ャッシュ82bからキャッシュ82dに変化する(Ow
ner82b =0,Owner82d =1)。そうではない
データ・ブロックのキャッシュされたコピーに対する共
有状態ビットおよび固有状態ビットは変化しない。 7. a.プロセッサ81eでアドレス73を書き込
む。 b.キャッシュ82eはミスして、バス85上のRea
dBlockを実行する。 c.キャッシュ82a,キャッシュ82b,キャッシュ
82c,およびキャッシュ82dはSharedOut
を主張して、これにより、前述された遅れの後で、Sh
aredInライン61が真の(“1”の)状態になる
ように駆動される。 d.アドレス73を含むデータ・ブロックの現在のオー
ナであるキャッシュ82dはOwnerOutを主張
し、OwnerInライン62をハイ(“1”)に駆動
するようにされて、メモリ86はそれを行うためのデー
タを供給することが禁止される。 e.キャッシュ82eはデータ・ブロックのそのコピー
に対するその状態ビットを、Shared82e =1,O
wner82e =0としてマークする。 f.次いで、データが共有されていることから、キャッ
シュ82eはアドレス73に対してWriteSing
leを実行する。 g.キャッシュ82a,キャッシュ82b,キャッシュ
82c,およびキャッシュ82eはSharedOut
を主張し、これによりSharedInライン61を駆
動して、WSRplyのヘッダーにおけるreplyS
haredビットをして、真の(“1”の)状態にセッ
トさせる。 h.アドレス73を含んでいるデータ・ブロックの所有
権が、キャッシュ82dからキャッシュ82eにスイッ
チする(Owner82d =0,Owner82e =1)。
そうでないときには、データ・ブロックのキャッシュさ
れたコピーに対する共有および固有状態ビットは変更さ
れずに留まる。
ータの両立性 ここで想起されるように、1個の2レベルのメモリ・シ
ステムは、“クラスタ”と呼ばれており、それぞれに第
2レベルのキャッシュ19a−19iを介してメイン・
バス(グローバル・バス)26に接続されているよう
な、複数個の1レベルのメモリ・システム14a−14
i(図1)からなるものである。これを換言すれば、各
クラスタに含まれている単一の第2レベルのキャッシュ
は、この第2レベルのキャッシュをクラスタ内の第1レ
ベルのキャッシュに接続させるプライベート・バスとと
もに、該クラスタをグローバル・バス26に接続させる
ものである。このプライベートなクラスタに対するバス
は、電気的にも論理的にも、他のクラスタ・バスおよび
グローバル・バスから区別されるものである。メイン・
メモリ13はグローバル・バス26に接続されている。
バスのレベルにおいては、第2レベルのキャッシュがメ
イン・メモリの機能的な属性を有している。これに対し
て、グローバル・バスのレベルにおいては、該第2レベ
ルのキャッシュは、単一レベルのシステムにおけるキャ
ッシュと本質的に同じ態様の機能を果している。ここで
認められるように、バス・プロトコルおよびデータの両
立性のプロトコルの設計により、1レベルまたはマルチ
レベルのメモリ・システムとして動作しているかどうか
について、該第1レベルのキャッシュが見出すことを妨
げるような動作をするようにされる。これを換言すれ
ば、第1レベルのキャッシュがそれらの環境から受け入
れる応答は、双方の場合において同じである。このため
に、1レベルのメモリ・システムに対するデータの両立
性のプロトコルについての前述の説明は、マルチレベル
のシステムのクラスタの各々に対して当てはまるものと
して適切に説明されていることを注意すれば十分であ
る。
立性のプロトコルの拡張では、より高いレベルのキャッ
シュ19a−19iが、いわゆる“existsBel
ow”ビットに加えて、第1レベルのキャッシュが保持
している全ての状態ビット(sharedState,
ownerStateおよびpendingStat
e)を維持することが必要とされる。これをより詳細に
いえば、より高いレベルのキャッシュの各々は、キャッ
シュしている各データ・ブロックに対する1個のexi
stsBelowビットを保持している。このexis
tsBelowビットは、メモリ・ツリーの同じブラン
チにおける1個または複数個の次に低いレベルのキャッ
シュが該当の特定のデータ・ブロックを有しているとき
にのみ、より高いレベルのキャッシュ内の任意の所与の
データ・ブロックに対して真の(“1”の)状態にセッ
トする。このために、例えば図1の2レベルのシステム
においては、第2レベルのキャッシュ19a−19iが
グローバル・バス26上に現れるパケットのフィルタ操
作が該existsBelowビットにより可能にされ
て、ある所与のクラスタ・バス15a,・・・または1
5i上にトラフィックを生成するグローバル・バスのト
ラフィックだけが、1個または複数個のクラスタ・バス
のクライエント・デバイスに関連するようにされる。こ
こで認められるように、このようなフィルタ操作をする
ことなく、グローバル・バス26上の全てのトラフィッ
クが全てのクラスタ・バス15a−15i上に現れ、こ
れにより、メモリ・システムの2レベルの組成について
の目的に勝るようにされる。
ン・バス(グローバル・バス)26上のパケット・トラ
フィックとどのように関連しているのか、および、これ
とは逆のときにはどのように関連しているのかについて
の包括的な理解を付与するためには、キャッシュ19a
のような第2レベルのキャッシュの一つの動作につい
て、ある程度詳細に考察することが有用である。
スタ・バス15aの上でリクエスタからのRBRqst
を受け入れたときには、該第2レベルのキャッシュ19
aは、RBRqstによって特定されるデータ・ブロッ
クのコピーを含むこともあり、含まないこともある。そ
れがコピーを有しているときには、リプライ・パケット
におけるreplySharedビットを次のように論
理的なORにされたSharedInの値に対してセッ
トした後で、該第2レベルのキャッシュはRBRply
を介してリクエスタにデータを戻す。即ち、(a)RB
Rqstの結果として第1レベルのキャッシュから受け
入れられるSharedOut信号、および、(b)特
定されたデータ・ブロックに対するその共有ビットの現
在の値について、論理的にORにされたSharedI
nの値に対してリプライ・パケットにおけるreply
Sharedビットをセットした後で、該第2レベルの
キャッシュはRBRplyを介してリクエスタにデータ
を戻す(ここで想起されるように、単一レベルのシステ
ムにおいては、リクエスタからRBRqstが受け入れ
られてからある固定的な時間後に、メイン・メモリ・コ
ントローラ25がSharedInライン61上のSh
aredIn信号のレベルを評価して、リクエスタに対
して戻されるRBRplyパケットに対するヘッダーの
replySharedビットに対して、当該評価され
た信号のレベルをコピーするようにされる)。
9aがそのクラスタ・バスのリクエスタによって特定さ
れるデータ・ブロックのコピーを有していないときに
は、この第2レベルのキャッシュ19aはグローバル・
バス上にRBRqstパケットを発生させる。このリク
エストに対するRBRplyの戻りにより、該第2レベ
ルのキャッシュは新規なデータ・ブロックをもって自己
の更新を行い、この新規なデータ・ブロックに対するそ
の共有ビットの値を算出するためにそのRBRqstに
対するそのpendingStateを使用し、そし
て、クラスタ・バス15a上にRBRplyを生成させ
ることによる応答をする。
ャッシュがそのクラスタ・バス上でリクエスタからのW
SRqstを受け入れたときには、該WSRqstによ
って特定されたアドレスを含むデータ・ブロックに対す
るその共有ビットがセットされているかどうかを定める
ために、該キャッシュ19aでチェックされる。当該特
定のデータ・ブロックに対する共有ビットがセットされ
ていないときには、該第2レベルのキャッシュ19aは
WSRqstデータに従ってデータの更新を行い、この
更新されたデータに対するその固有ビットのセットを
し、そして、そのクラスタ・バスを介して(適切な時点
において、SharedInライン61の値におけるr
eplySharedビットをもって)WSRplyを
生成させる。これに対して、第2レベルのキャッシュ1
9aが真の状態(“1”)に対してセットされたWSR
qstに従うデータ・ブロックに対するその共有ビット
を有しているときには、グローバル・バス26上にWS
Rqstを生成させることにより、クラスタ・レベルの
リクエスタのWSRqstを伝播させる。メイン・メモ
リ・コントローラ25は、ある所定の時間遅れの後に、
WSRplyを付与することによってこのグローバル・
レベルのリクエストに応答する。このリプライが受け入
れられたときには、該第2レベルのキャッシュ19aは
WSRqstによって付与されたデータのWSRply
の反映に従ってデータ・ブロックのそのコピーを更新
し、該データ・ブロックのそのコピーに対するその固有
ビットをセットし、そして、そのクラスタ・バス上に
(グローバル・バス26を介して受け入れられたWSR
plyにおけるreplySharedビットの値、お
よび、クラスタ・バス上の当初のWSRqstに対応す
るSharedInライン61の値の論理的なORに対
するこのクラスタ・レベルのWSRplyのセットのヘ
ッダー・サイクルにおけるreplySharedビッ
トをもって)WSRplyを生成させる。
・バス26上のRBRqstパケットをモニタして、ア
ドレスの合致がなされているRBRqstの同定をす
る。このようなアドレスの合致が生じたときには、キャ
ッシュ19aのような第2レベルのキャッシュは、特定
されたデータ・ブロックのそのコピーに対する固有ビッ
トおよびexistsBelowビットのチェックをす
る。当該特定のデータ・ブロックに対するその固有ビッ
トがセットされているときには、該キャッシュ19aは
データについて応答するけれども、RBRplyパケッ
トがアセンブルされる態様は、そのexistsBel
owビットもセットされているか否かに依存することに
なる。これをより詳細にいえば、該existsBel
owビットがセットされているときには、キャッシュ1
9aは初めにそのクラスタ・バス19a上でRBRqs
tを生成させて、特定されたデータ・ブロックの第1レ
ベルのキャッシュ・オーナから、グローバル・レベルの
RBRqstによって呼ばれるデータを検索するように
される。しかしながら、該特定されたデータ・ブロック
のキャッシュ19aによるコピーに対するexists
Belowビットがセットされていないときには、キャ
ッシュ19aにはそのコピーが現在のものであるとして
含まれていることから、グローバル・レベルでのリクエ
スタのRBRqstを伝播させることなく、グローバル
・レベルでのRBRplyに応答するようにされる。
ャッシュが、グローバル・バス26上のWSRqstに
おいて特定されたアドレスに合致しているときには、通
常のようにSharedOutが主張されるけれども、
他の動作をすることはない。しかしながら、キャッシュ
19aがグローバル・バス26上のWSRplyにおい
て特定されたアドレス上で合致しているときには、該当
のアドレスにおけるデータのそのコピーが更新される。
これに加えて、WSRplyによって特定されたアドレ
スを含むデータ・ブロックのそのコピーに対するexi
stsBelowビットがセットされることが起きたと
きには、キャッシュ19aもそのクラスタ・バス15a
上でWSRplyを生成させる。ここで注目すべきこと
は、このWSRplyパケットはクラスタ・バス上の対
応するWSRqstパケットによって先行されるもので
はなく、バス上でのリクエスト・パケットの数とリプラ
イ・パケットの数とが等しくないのは別の理由によると
いうことである。
タ・バスからFBRqstを取得したときには、リクエ
ストがアドレスされるデータ・ブロックのそのコピーが
更新され、FBRplyが伝送されて、それぞれにリク
エスタに対して戻されるだけである。FlushBlo
ckに対するレスポンダは、常に該レスポンダに対する
実際のまたは明白なメイン・メモリであるから、第2レ
ベルのキャッシュではグローバル・バス上の全てのFB
Rqstが無視される。
ockトランザクションは、データを物理的なアドレス
空間に入力するために、2次的なデータ・プロデューサ
(メモリ・システムの外部にあるデータ源)による使用
のために有効なものである。該当の目的のために、この
トランザクションによれば、メイン・メモリに対して、
および、WBRqstにおいて特定されたアドレス上で
合致する任意のキャッシュに対して、サイクリックに順
序付けられたデータ・ブロックの書き込みがなされる。
マルチレベル・システムにおいては、WriteBlo
ckトランザクションは、グローバル・バス・トランザ
クションとしての使用のために限定されることができ
る。該当のイベントにおいて、WBRqstはグローバ
ル・バス26とインタフェースされているデバイスによ
ってのみ生成される。そして、全てのWBRqstはメ
イン・メモリ13によって供給される(WriteBl
ockについてのこの限定された適用に対するWBRp
lyには、不確定のサイクルによって追従される標準的
なリプライのヘッダー・サイクルが含まれている)。代
替的に、このWriteBlockトランザクション
は、より低いレベルのキャッシュがそれを呼ぶことが許
容されるように再規定することができる。そうであると
きには、より低いレベルのローカル・キャッシュのいず
れかによって生成されたWBRqstは第2レベルのキ
ャッシュに渡され、これに次いで、該WBRqstをグ
ローバル・バス26上に配置するようにされる。WBR
plyを受け入れると書き込みが実行される。
要とされることは、第2レベルのキャッシュの各々に
は、それらの下部でキャッシュされていた全てのデータ
・ブロックのコピーが維持されるということである。該
当の目的のために、該第2レベルのキャッシュ19a−
19iは、それぞれに、それらのそれぞれのクラスタ・
バス上で第1レベルのキャッシュの記憶容量の和に少な
くとも等しいデータの記憶容量を有するように選択され
る。更に、第2レベルのキャッシュ19a−19iは、
それぞれに、それらのそれぞれのクラスタ・バス上で第
1レベルのキャッシュの連想性の和に少なくとも等しい
連想性の程度を有するように選択される。例えば、ある
1個のクラスタに4個の第レベルの直接にマッピングさ
れたキャッシュ(即ち、1の程度の連想性を有するキャ
ッシュ)が含まれているとすると、該当のクラスタに対
する第2レベルのキャッシュは、そのクラスタ・バス上
で現れ得る任意のデータ・ブロックのアドレス上で確実
に合致できるように、少なくとも4の程度の連想性を有
するように選択される。
あり、また、簡単に増強されるものであるから、修正お
よび改善のためのその可能性を例示するために、ある所
定の拡張および増強についての説明をする。その初めの
実施例の説明の構成をするために上記で使用されたと同
じ一般論的なアウトラインが追従されて、この増強され
た実施例に独特の特徴が属する事項を同定するようにさ
れる。
にインターリーブさせることが可能であり(図示されな
い)、これによって、必要とされるバス・ワイヤの本数
に比例して増大する危険性を招きながら、使用可能なバ
スのバンド幅を増大するようにされる。例えば、ある1
個の実施においては、ある所与のパケットが伝送される
インターリーブしたバスを同定するために使用されるべ
きリクエスト・パケットおよびリプライ・パケット(そ
れぞれに図13および図14を参照)に対するヘッダー
のアドレス・フィールドにおけるビット8および9が許
容される。このために、該当の実施においては、バス・
アーキテクチュアについての1−ウエイ、2−ウエイお
よび4−ウエイのインターリーブが許容される。
の標準的なデバイス・バス・インタフェース101に
は、幾つかの注目すべき修正が取り込まれている。その
差異のあるものは種々の信号を同定するために使用され
る術語に関連しているが、他のものは相当に重要なこと
である。インタフェース101の内部ロジックは図16
に例示されている。図16に示されているドライバ10
4−109およびレシーバ111−117は、典型的に
はオープン・ドレインのCMOSデバイスであって、前
述のGunningの出願である出願番号第07/50
2,372号の教示を維持しているものである。
の信号ポート間に存在する実質的な区別については、こ
のセクションの以下のヘッディングの下にある程度詳細
に開示される。
テムの各バスは、全ての競合しているバス・クライエン
トは彼らのホスト・バスに対する公平で限界のあるタイ
ム・アクセスを確実にし、また、バス上でのパケットの
渋滞を回避するフロー・コントロールを実施するための
裁定手段を備えている。上記で指摘されたように、1個
または複数個のバスがパケットで切り換えられることか
ら、パケットの渋滞は一つの結末をなすものであり、こ
れの意味することは、それらのサービスが可能になるよ
りも早く、バス・クライエントがトランザクション・リ
クエストを累積できることである。
イエント・デバイスは、3本のリクエスト・ワイヤ R
eq L[2..0]および3本の許可タイプ・ワイヤ
Gnt−Type L[2..0]を有する裁定ポート
を介して、そのバスのための裁定手段と相互作用をす
る。これに加えて、該裁定手段に接続されている全ての
クライエントによって共有される単一のGnt Lワイヤ
がある。
ック・サイクルまたは2個の連続するサイクルの間、そ
のReq Lワイヤを用いて、そのバスのための裁定手
段に対してその裁定リクエストの通信をする。その第1
のサイクルにおいては、該クライエントはそのリクエス
トの優先権についての通信をする。これに加えて、正常
な裁定リクエストのためには、クライエントはそのRe
q Lワイヤの1本の上で第2のサイクルを用いて、バ
スがリクエストされているパケット長について裁定手段
に告知するようにされる。典型的には、これらの裁定リ
クエストの2個のサイクルに対するコード化は次の通り
である。 第1サイクル 7:裁定停止(Stop Arbitration) 6:リプライ・ハイ(Reply High) 5:ポーズ(Pause) 4:リプライ・ロー(Reply Low) 3:ホールド(Hold) 2:リクエスト・ハイ(Request High) 1:リクエスト・ロー(Request Low) 0:ノー・リクエスト(No Request) 第2サイクル L:パケット長(0=>2サイクル,1=>9サイク
ル)
w,Request High,Reply Low,
およびReply High は、バスに対する“正常
な”裁定リクエストに対応している。これを換言すれ
ば、それらが使用されるのは、裁定リクエストを登録し
ているデバイスが実際にパケットを伝送しようとすると
きである。Reply Highはキャッシュのリプラ
イだけに用いられる;Reply Lowはメモリのリ
プライだけに用いられる;そして、Request H
ighはプロセッサおよびIOキャッシュのような大方
のリクエスタに対するものである。Request L
owは、裁定手段からの許可を得るために長い遅れが裁
定的に黙認される“バックグラウンド”デバイスによっ
てのみ用いられるものである。再びこの実施例において
は、ある1個のクライエントは多くの裁定リクエストを
続けて発することができるが、この場合に、ある1個の
分離したリクエストはリクエスト・サイクルの各ペアに
対して登録される。更に、クライエントは、裁定手段が
ある所与のクライエントの側にたって登録できる裁定リ
クエストの個数だけ、該裁定手段によって課される実施
限界を彼らが超えていないことを確実にするという責任
がある。上述された裁定のルールを維持しながら、より
高い優先度の裁定リクエストが、より低い優先度のリク
エストに先だってサービスされる。そして、同じ優先度
のレベル内にある裁定リクエストは、ほぼラウンド・ロ
ビン式の順序でサービスされることになる。
seおよびStopのような)この実施例によって支持
される他の裁定の優先権は、クライエントが彼らのホス
ト・バスに対する裁定手段からの特別なサービスをリク
エストすることが許容されるように利用可能なものであ
る。これらの特別な裁定リクエストは、裁定の優先度を
特定する1サイクルのリクエストだけ裁定手段に対して
通信される。裁定手段からのサービスは何もリクエスト
されないときには、バス・クライエントはNoRequ
estを使用する。Holdは、リクエスト・パケット
に対するいかなるリクエストでも裁定手段が許容しない
ように所望するクライエントによって使用される(Ho
ldを下回る優先度)。このために、Holdは、その
目的および機能において、先に説明された実施例で採用
された裁定リクエストについて、“システム・ワイドの
保持を要求すること”および“システム・ワイドの保持
に対する要求を解除すること”のコード化をすることと
類似している。しかしながら、この実施例においては、
クライエントがHoldコードを主張するサイクルだけ
にわたって、裁定手段はHold状態に留まる。Pau
seはこの発明に対しては固有のコード化をすることで
ある。キャッシュによって主張できることは、メモリに
よって発生されるリプライが殺到するのを回避すること
である。最後に、Stopは、デバイスが全ての裁定を
停止させようと所望するときに用いられる。これによ
り、裁定手段をして、任意の裁定手段がStopコード
を主張するだけのサイクルにわたってバスの許可を停止
させる。このために、ここで理解されることは、Sto
pコードは、初めの実施例において考えられたSSto
p信号と機能的に類似であるということである。
次のバス・マスターになるように裁定手段によって選択
されていることをクライエントに対して告知するため
に、裁定手段によって用いられるものである。この信号
は1サイクルだけ主張されるものであり、一連の後続の
サイクルにわたって、選択されたバス・クライエントに
バス・マスターシップを付与するものである。ここで、
GntType Lは許可が与えられている裁定リクエ
ストの優先度を指示している。このような目的のため
に、GntType Lは次のように好適にコード化さ
れる。 7:裁定停止(Stop Arbitration) 6:リプライ・ハイの許可(Grant Reply
High) 5:保留(Reserved)(使用されない) 4:リプライ・ローの許可(Grant Reply
Low) 3:保留(Reserved)(使用されない) 2:リクエスト・ハイの許可(Grant Reque
st High) 1:リクエスト・ローの許可(Grant Reque
st Low) 0:許可ナシ(No Grant)
イエントに対するGntType L がゼロではないと
きにのみ、所与のクライエントはそのバスに対する裁定
手段からの有効な許可を有している。この実施例におい
て、ある所与のクライエント・デバイスに対するインタ
フェース101におけるサイクルi上でGnt Lおよ
びGntType Lが主張されているときには、クラ
イエントは、サイクルi+2において、その出ていく単
方向または双方向のバス・セグメントを駆動することが
できる。図17に示されているものは、裁定(5サイク
ルの裁定の潜在が仮定されている)およびパケットの伝
送の間の、裁定リクエスタのデバイス・バス・インタフ
ェース101における、より重要な裁定リクエストおよ
び許可信号についてのタイミングである。この図17を
読むときには図16にも留意すべきである。
段はフロー・コントロールを実施するための2個の異な
るメカニズムを有している。裁定の優先度は、これらの
フロー・コントロールのメカニズムの第1のものであ
る。ここで理解されるように、リクエスト・パケットお
よびリプライ・パケットの双方を発するクライエント・
デバイスは、リクエスト・パケットの伝送に対するそれ
らの裁定リクエストよりも、リプライ・パケットの伝送
に対するそれらの裁定リクエストに対して、より高い優
先度を常に指定している。渋滞の始まりに先だってデバ
イスが常にリプライの用意をしているときには、これは
渋滞の問題を除外するために十分なものであるが、全て
のデバイスにとってはこの要求を満たすことはできな
い。例えば、それらが受け入れ得るリクエスト・パケッ
トに対する到達レートにおいて応答するためには、メモ
リ・コントローラ25(図1)のような、より遅いデバ
イスを予期することは実際的ではない。更に、このよう
なデバイスでオーバフローのリスクなしで累積できる入
力キューの長さは法外に長いものである。
Pauseの裁定リクエストのコード化に対する上述の
応答を介して、第2のフロー・コントロールのメカニズ
ムを実施するようにされる。ここで認められるように、
HoldまたはPauseのリクエストに対する裁定手
段の応答は即座のものではないから、それらのHold
またはPauseのリクエストがバスの裁定手段におい
て効力を生じる間に幾つかの入来するパケットの累積が
許容されるように、クライエント・デバイスはそれらの
入力キューにおいて十分な余裕を持たねばならない。し
かしながら、クライエント・デバイスのいずれかが極め
て頻繁にHoldまたはPauseのリクエストをする
ときには、バスのスループットが無用な逆効果を生じる
ことから、バランスが衝撃を受けることがある。
ース インタフェース101のデータ・ポートおよびオプショ
ンの受け入れポート(図15)は、その目的および機能
において、それぞれに、インタフェース41の送出ポー
トおよび受け入れポート(図4)に類似している。しか
しながら、インタフェース41のHeaderCycl
eIn信号およびHeaderCycleOut信号
は、パケットのヘッダー・サイクルを同定するための逆
パリティ・シンドロームを採用するという立場から、こ
れらは除外されている。各バス上の全てのパケットの各
サイクルに対するバイト・レベルにおいて、パリティの
演算がこの増強された実施例でなされていることから、
これは実際的なことである。各バスでは、典型的に、6
4ビット幅の多重化したアドレス/データ・パスが設け
られているとすると、これの意味することは、全てのパ
ケットの各サイクルについて8個のパリティ・ビットが
あるということである。その結果として、データ・サイ
クルに対する正しい偶数パリティのコード化は、ヘッダ
ー・サイクルに対する正しい奇数パリティのコード化か
ら、8のハミング距離だけ離されることになるが、標準
的なエラー検出技術を用いてパリティ・エラーを検出す
ることの可能性について妥協することからは、パリティ
のこの異常な使用を防止するためには十分な離隔である
と信じられる。
は、BidEN L信号がそのコントロール・ポートに
加えられて、該インタフェース101が単方向のバス・
セグメントまたは双方向のバス・セグメントに接続され
ているかどうかを肯定的に指示するようにされることで
ある。BidEN Lが主張されているとき、または真
(“1”)であるときには、DataPortは双方向
モードで動作して、クライエント・デバイスと双方向の
バス・セグメントとの間で、双方向のパケット通信を支
持するようにされる。これに対して、BidEN Lが
主張されていないとき、または偽(“0”)であるとき
には、DataPortは単方向の出力モードで動作
し、また、ReceiveOptionPortは単方
向の入力モードで動作するようにされる。
は、図15のインタフェース101における直接的な対
応を備えてはいないが、ここで認められることは、両立
性の信号がインタフェース101の裁定ポートにマージ
されていることである。この表象的な(present
ational)変更がなされているのは次の理由によ
る。即ち、(a)バス・クライエントからのReqSh
ared L 信号(SharedOut信号として先に
同定されたもの)の論理的なORをとって、それらのク
ライエントに対してGrantShared L信号
(SharedIn信号として先に同定されたもの)を
供給するために、および、(b)バス・クライエントか
らのReqOwner L信号(OwnerOut信号
として先に同定されたもの)の論理的なORをとり、そ
れらに対してGrantOwner L信号(Owne
rIn信号として先に同定されたもの)を供給するため
には、各バスに対する裁定手段が便利な位置にあること
が見出されたからである。実際に、ReqShared
L,GrantShared L,ReqOwner
LおよびSharedOut Lは、機能的には、そ
れぞれに、インタフェース41のSharedOut,
SharedIn,OwnerOutおよびOwner
In信号と同等のものであるから、SharedOu
t,SharedIn,OwnerOutおよびOwn
erIn なる名称は、拡張されたデータ両立性のプロ
トコルの記述を簡略化するために、以下のそれらの信号
を参照する際に用いられることになる。両立性信号をイ
ンタフェース101の裁定ポートにマージさせることの
付加的な利点は、出力信号に対してはインタフェース1
01において、また、入力信号に対しては裁定手段にお
いて、単一ビット・パリティのコード化の使用を介する
ようにして、裁定および両立性の入力信号および出力信
号について組み合わされたパリティ・チェック操作を容
易にするものである。
次の通りである。 トランザクション リクエスト コマンド リクエスト 名 /リプライ コード化 /リプライ 省略形 (リクエスト パケット長 /リプライ) 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) -
リプライ・パケットの第1のサイクルはヘッダー・サイ
クルである。図13に戻って認められることは、この実
施例におけるリクエスト・パケットに対するヘッダー・
サイクルのフォーマットが、42ビット幅のアドレス・
フィールドとともに、6ビット幅のコマンド・フィール
ド(リクエスト/リプライのフラグ・ビットを含んでい
る)を有するようにされていて、規定されている増大し
た個数のトランザクションのコード化に対して十分な能
力を備えていることである。アドレス・フィールドのよ
り上位の2ビットは、実施されている種々の“単一の”
(WriteSingleUpdate,I/ORea
dSingle,等の)トランザクションに対してアド
レスされた“単一のもの”のサイズ(SSize)を特
定するために採用されており、また、このフィールドの
下位の40ビットはI/Oアドレス空間またはメモリ・
アドレス空間(即ち、物理的なアドレス空間)のいずれ
かにおけるバイト・アドレスを特定するために有用なも
のである。一つの実施においては、これらのバイト・ア
ドレス・ビットの中の36個だけが採用されており、残
りの4ビット(例えば、該バイト・アドレスの上位4ビ
ット)は、将来のアドレス拡張のために保留されている
(保留または不使用のアドレス・ビットに対してとられ
る対策については上記の説明を参照)。
ッダー・サイクルに付加的に含まれているPLenビッ
トは、該パケットが(9サイクルの)長パケットである
か、または、(2サイクルの)短パケットであるかの信
号を出すためのものである。このコード化はヘッダーの
コマンド・フィールドで搬送されるコマンドについては
冗長性があるけれども、ある所定の事例では長パケット
に関連しており、他の事例では短パケットに関連するよ
うな、まだ規定されていないコマンドの適当なコード化
を許容するようにされる。更に、キャッシュ・リクエス
タによって任意の所与のデータ・ブロック上に維持され
るオーナ・ビットをコントロールするための Owビッ
トがあり、該所与のデータ・ブロックの値または共有状
態に影響し得るトランザクションを開始するようにされ
る。該当のカテゴリに入るこの実施例のトランザクショ
ンは、WriteSingleUpdate,Writ
eSingleInvalidate,SwapSin
gleUpdate,SwapSingleInval
idateおよびReadBlockである。それらの
トランザクションに対するリクエスト・パケットのヘッ
ダーにおけるOwビットの状態により、該トランザクシ
ョンが関係するデータ・ブロックの所有権を受け入れる
ために、リクエスタに用意があるかどうかの指示がなさ
れる。他の全てのトランザクションに対しては、このO
wビットの値が偽りの(“0”の)状態にあるように維
持される。
のヘッダーには8ビット幅のDeviceIDフィール
ドおよび4ビット幅のSubIDフィールドも含まれて
いるが、これらは、その目的および機能において、上記
された実施例のヘッダーによって搬送されるDevic
eIDと類似している(この例においては、SubID
は、多くの未解決のリクエストに対するリプライの曖昧
さをなくすことを、バスのクライエント・デバイスで可
能にするために採用できるものであり、また、SubI
Dフィールドは、リクエスタの状態を内部的に記憶させ
ることを回避するために、トランザクションのリクエス
タに対する内部的な状態またはpendingStat
eをコード化するために採用できるものである)(両立
性プロトコルについての検討を参照)。図13における
ヘッダーに付加的に含まれているエラー・ビット(Er
r)および不使用ビットの双方は、リクエスト・ヘッダ
ーにおいて偽の(“0”の)状態に維持される(Err
ビットはリプライ・ヘッダーにおいてのみ意味があるも
のである)。
・パケットに対するヘッダー・サイクルが対応のリクエ
スト・パケットに対してビット対ビットで同等であるこ
とが確かめられる。ただし、コマンド・フィールドのリ
クエスト/リプライ・ビットは該パケットをリプライと
して同定するように反転される;リプライ・パケットの
長さ(即ち、長または短)は PLen ビットによっ
てコード化される;Errビットは、リプライのアセン
ブルをしているときにレスポンダがエラーに遭遇したか
否かに依存して、真の(“1”の)状態にセットされる
か、または、偽りの(“0”の)状態に維持される;O
wビットの状態が採用されて、トランザクションが関係
しているデータ・ブロックの所有権を獲得するためにリ
クエスタが許容されているか否かの指示をするようにさ
れる;そして、リクエスト・ヘッダーの不使用ビットが
共有(Sh)ビットとして採用されて、対応のリクエス
トがアドレスされたデータが、リクエスト・パケットを
受け入れた時点において共有されているか否かの信号を
するようにされる(このように共有されたデータについ
ての、より緻密な説明は上記で現れている)。
トランザクションは、ReadBlock,NonCa
cheableReadBlock,FlushBlo
ck,WriteBlock,WriteSingle
Update,WriteSingleInvalid
ate,SwapSingleUpdate,Swap
SingleInvalidateおよびKillBl
ockである。ReadBlock,WriteBlo
ckおよびFlushBlockトランザクションは、
多くの点において、第1の実施例において対応する同名
のトランザクションと同等のものであるが、この実施例
におけるこれらのトランザクションおよびその他の“ブ
ロックの”トランザクションでは8サイクルのデータ転
送ユニット(即ち、8バス・サイクルであって、その各
々には8個の連続バイトが含まれている)が用いられる
点で差異がある。更に、WriteSingleUpd
ateトランザクションは、早期の実施例におけるWr
iteSingleトランザクションと機能的に類似し
ているが、新規に規定されたWriteSingleI
nvalidateトランザクションとの区別のために
その名称が変更されている。同様にして、SwapSi
ngleUpdateは、前述されたConditio
nalWriteSingleトランザクションを比較
的小幅に修正したトランザクションである(即ち、Sw
apSingleUpdateは、Condition
alWriteSingleで実行される細かい読み取
り−修正−書き込みよりは、細かい読み書きを実行する
ために用いられるものである。)。新規に規定されたS
wapSingleInvalidateトランザクシ
ョンとの区別をするために、それは“Update”な
トランザクションとして同定される。
teおよびSwapSingleInvalidate
トランザクションは、それぞれに、WriteSing
leUpdateおよびSwapSingleUpda
teトランザクションに対する書き込み無効化のスタイ
ルの対応事項を備えるように規定されている。それらに
より、特定のデータ・ブロックのコピーをキャッシュ・
リクエスタで更新することが可能にされ、受け入れてい
るキャッシュがトランザクションのペンディングをする
データ・ブロックに対して無効化のリクエストがアドレ
スされない限り、同じデータ・ブロックのコピーを含ん
でいる任意の他のキャッシュはそのコピーを無効にする
ようにされている。ここで想起されるように、該当のデ
ータ・ブロックに対するValidビットを偽の
(“0”の)状態にクリアするだけで、キャッシュはそ
のデータ・ブロックの任意のものを無効化し、または、
削除することができる。
(図1)から読み取られた後で修正されたデータ・ブロ
ックの所有権は、必ずしも最後に書き込みをしたプロセ
ッサに対するキャッシュに属するものではない。代替的
に、データ・ブロックの所有権の転移は、WriteS
ingleUpdate,WriteSingleIn
validate,SwapSingleUpdat
e,SwapSingleInvalidateおよび
ReadBlockトランザクションに対するリクエス
ト・パケットおよびリプライ・パケットのヘッダー・サ
イクルにおけるOwビットの状態のコントロールによっ
てなされる。これを詳細にいえば、リクエスタを除く全
てのキャッシュであって、WSIRply,WSURp
ly,SSIRplyおよびSSURplyと合致する
ものは、特定のデータ・ブロックに対するそれらのオー
ナ・ビットを偽の(“0”の)状態に無条件でクリアさ
せる。これに対して、リクエスタは、このようなリプラ
イを受け入れると、該リプライにおけるOwビットに依
存して、該当のデータ・ブロックに対するそのオーナ・
ビットを(“1”)にセット、または(“0”)にクリ
アする。リプライ・ヘッダーにおけるOwビットが真の
(“1”の)状態にセットされているときには、リクエ
スタは、該データ・ブロックに対するそのオーナ・ビッ
トを真の(“1”の)状態にセットする。しかしなが
ら、リプライ・ヘッダーにおけるOwビットが偽の
(“0”の)状態にクリアされているときには、対応の
リクエスト・パケット内のOwビットが偽の(“0”
の)状態にクリアされているために、または、ある他の
理由により、リプライを用意しながらレスポンダがOw
ビットを偽の(“0”の)状態にクリアしたために、リ
クエスタは、トランザクションが関係するデータ・ブロ
ックに対するそのオーナ・ビットを偽の(“0”の)状
態にクリアする。ここで認められるように、メイン・メ
モリ13(図1)は、物理的なアドレス空間における全
てのデータ・ブロックの欠陥のあるオーナである。従っ
て、WSIRqst,WSURqst,SSIRqst
またはSSURqstのヘッダーに偽の(“0”の)O
wビットが含まれているときには、メモリ13は、通常
は、リクエストによって付与される新規なデータに従っ
て更新される。勿論、SSIRqstまたはSSURq
stを発するキャッシュが、これらのトランザクション
の読み取りフェーズを支持する際に、まだプロセッサに
対して古いデータを供給する責任があることから、リク
エスタは、そのリクエストに対するリプライを少なくと
も受け入れるまでは、該当のデータ値を留めておくよう
にされる。
クションにおいても用いられる。特に、関連のプロセッ
サによる書き込みに対するプレリュードとして、キャッ
シュ・リクエスタによって発せられるRBRqstにお
いて、それは真の(“1”の)状態にセットされて、対
応のRBRqstが受け入れられるときに、特定のデー
タ・ブロックに対するそのオーナ・ビットを真の
(“1”の)状態にセットすることを、リクエスタが所
望していることが告知される。このために、ここで理解
されることは、RBRqstのヘッダーにおけるOwビ
ットにより、リクエスタに対する特定のデータ・ブロッ
クの所有権の加速された転移が許容されることになる。
ランザクションに特有の別の特徴は、RBRplyを可
能にするようにされた提案事項であって、リプライにつ
いての任意のデータ・サイクルにおいて、リクエスタに
対して戻されるべきデータをフェッチしている間にメモ
リ・エラーが生じたときには、該リクエスタにこれを告
知するようにされている。何等かのこのようなデータの
フェッチ・エラーが生じたことがレスポンダによって見
出されたときには、1個または複数個のエラーで影響を
受けるRBRplyのデータ・サイクルの各々に対し
て、メモリ・フォールト(MemFault)サイクル
が代用される。MemFaultサイクルは独特のもの
として同定可能であるが、その理由は、(a)そのため
のパリティがヘッダー・サイクルの奇数パリティに対し
て反転されること、(b)Noopに対するコマンド・
コードが含まれていること、および、(c)そのDev
iceIDおよびSubDeviceIDフィールドが
エンプティ(全て0)であることのためである。生じて
いるメモリ・エラーのタイプを同定するエラー・コード
は、このようなMemFaultサイクルの下位32ビ
ットによって支承されている。このようなメモリのフォ
ールト・サイクルのメカニズムを付与する重要な利点
は、リクエストされたメモリの読み取り動作を実行しな
がら、レスポンダがRBRplyを発することが許容さ
れることであるが、これの意味することはメモリの待ち
時間を減少できることである。
なトランザクションであって、(メイン・メモリと同様
な)第2のまたはより高いレベルのキャッシュが、それ
らがブランチするより低いレベルのキャッシュから不使
用のデータ・ブロックを排除できるようにされる。例え
ば、しばらくの間図1に戻ると、キャッシュ19aはK
illBlockを始動させて、クラスタ・バス15a
上にある全てのキャッシュ16aa−16ajから特定
のデータ・ブロックの全てのコピーを除去させることが
できる。
ockトランザクションが重要であるという理由は、第
2のまたはより高いレベルのキャッシュにより実在のデ
ータ・ブロックを犠牲にすることが許容されて、該当の
データに対して指定されていた記憶位置が、その上位ま
たは高位レベルのバス(即ち、キャッシュ19aの場合
にはグローバル・バス26)上でReadBlockを
実行することによってキャッシュが獲得する新規なデー
タを記憶させるために再指定できるようにされる。ここ
で想起されるように、それらのより下位レベルのバス
(例えば、バス15a)上の任意のRBRqst上で
“ミス”にされたときには、これらのより高位レベルの
キャッシュはそれらのバス上でReadBlockを始
動させる。このために、KillBlockトランザク
ションの規定は、初めの実施例における第2のまたはよ
り高位レベルのキャッシュに対して課された、潜在的に
繁雑な“associator coverage(連
想範囲)”を回避するためのものである。ここでより詳
細に想起されることは、第2レベルのキャッシュ19a
−19iの各々を選択することにより、第1レベルのキ
ャッシュに対して連想範囲を付与することが可能にされ
て、(a)それらの下位に存在する第1レベルのキャッ
シュの容量の和に少なくとも等しい容量、および、
(b)それらの第1レベルのキャッシュの連想性の和に
少なくとも等しい連想性の程度を持たせることである。
しかしながら、このKillBlockトランザクショ
ンによれば、代替的でコストが潜在的に低い技術が付与
されて、第2レベルのキャッシュにより、それらの第1
レベルのチャイルド・キャッシュ(即ち、それらがブラ
ンチする第1レベルのキャッシュ)に対する完全な範囲
を与えることが確実にされる。
り高位レベルのキャッシュにより適当な犠牲アルゴリズ
ム(周知のいかなる犠牲アルゴリズムでも使用できる)
の使用を介して潜在的な犠牲としてのデータ・ブロック
が選択され、そして、該選択されたデータ・ブロックに
対するそのオーナ・ビットの状態がチェックされる。潜
在的な犠牲ブロックに対するそのオーナ・ビットが真の
(“1”の)状態にセットされると、KillBloc
kの始動手段(initiator)により、その下位
レベルのバス(即ち、第2レベルのキャッシュ19aの
場合にはクラスタ・バス15a)上にRBRqstがま
ず発せられる。このRBRqstは潜在的な犠牲にアド
レスされているから、対応のRBRplyが受け入れら
れるときには、該KillBlockの始動手段により
潜在的な犠牲のそのコピーが更新される。所要であれば
更新の後で(KillBlockの始動手段が潜在的な
犠牲に対するそのオーナ・ビットを偽の(“0”の)状
態にクリアしたときには、更新の実行はされない)、こ
のKillBlockの始動手段は、その下位レベルの
バスを用いて、該潜在的な犠牲に対してアドレスされる
KBRplyを発するようにされる。このKBRply
上で合致する、より下位レベルのキャッシュ(例えば、
キャッシュ12aa−12aj)の各々は、その上でペ
ンディングしているトランザクションがない限りは、特
定されたデータ・ブロックのそのコピーに対するそのV
alidビットをクリアするようにされる。このKil
lBlockの始動手段は、次いで、その下位レベルの
バス上にKBRqstを発する。このKBRqstは潜
在的な犠牲に対してアドレスされているから、KRBq
stが受け入れられ、そのKRBqstに応答して、よ
り下位レベルのキャッシュの任意のものがReqSha
red L(SharedOut)が決定されるときに
は、KillBlockの始動手段によってそのGra
ntShared L入力信号(換言すれば、そのSha
redIn信号)の状態がチェックされる。もしそうで
あるとすると、KillBlockの始動手段がリセッ
トされて、ある所定の将来の時点まで、選択されたデー
タ・ブロックを犠牲にすることが延期される。しかしな
がら、KRBqstの受け入れの際に、より下位レベル
のキャッシュのいずれもReqShared L(Sh
aredOut)を主張しないときに、このKillB
lockの始動手段で確認されることは、その下位レベ
ルのバス上の任意のキャッシュにおいて特定されたデー
タ・ブロックのコピーは存在せず、これに次いで、その
より高位レベルのバス上でFlushBlockが始動
して、データ・ブロックのそのコピーをメイン・メモリ
13に書き戻すようにされる(または、次に高いレベル
のキャッシュに書き戻すようにされる)。
めに規定されている別のトランザクションは、NonC
acheableReadBlockトランザクション
である。このトランザクションは、アドレスされている
データ・ブロックの共有/非共有状態が影響を受けない
ことを除き、前述されたReadBlockトランザク
ションと同等のものである。従って、その適用は、DM
AI/Oデバイスのような非キャッシュ式のリクエスタ
の側にたって、合致性のあるメモリ空間(即ち、物理的
なアドレス空間)からのデータ・ブロックの読み取りに
限定される。
び書き込み(それぞれに、IOReadBlockおよ
びIOWriteBlock)をするために、また、I
/Oデバイスに対してアトミックな読み/書き(IOS
wapSingle)を実行するために、I/Oトラン
ザクションは付加的なトランザクションの支持を付与す
るように拡張されている。更に、第1実施例のBIOW
riteトランザクションは、次のSectionにお
いて略述されるような、より特定のInterrupt
トランザクションを備えるために省略されている。
て、より関心のある拡張がなされる2個のトランザクシ
ョンである。Lockはキャッシュ・リクエスタにより
呼ばれることができて、リクエスタを除く任意のクライ
エントにとって、特定されたデータ・ブロックに影響が
あり得るいずれのトランザクションでもその実行を防止
するようにされる(即ち、WriteBlock,Wr
iteSingleUpdate,WriteSing
leInvalidate,SwapSingleIn
validateまたはKillBlock)。従っ
て、ある所与のデータ・ブロックに課されるトランザク
ション上に、細かい順序付けの程度を課することが有用
である。また、リクエストされるデータ・ブロックに対
する書き込みの頻度のために、古いデータが戻されるR
BRqst上での無限回数の再試行をキャッシュで防止
することも有用である。全てのキャッシュ・クライエン
トによってロックされたデータ・ブロックのアドレス
(LockAddress)を登録することにより、ま
た、リクエスタ以外の全てのキャッシュに対して真の
(“1”の)状態にセットされるフラグ・ビット(Lo
ckAddressValid)を備えることにより、
Lockは好都合に呼ばれることになる。かくして、こ
の特徴のこのような実施により、1個だけのデータ・ブ
ロックが任意所与の時点においてロックされることが許
容される。UnLockは、ある1個のLockのホル
ダーがそのLockをクリアするために呼ぶことができ
る、相対的なトランザクションである。キャッシュの各
々をして、特定されたデータ・ブロックに対するそのL
ockAddressValidビットをクリアさせる
ことにより、その達成がなされる。
ランザクションも、プロセッサに対する割り込みの信号
を出力するために規定されたものである。プロセッサの
割り込みはこの発明の範囲を超えたものであるけれど
も、ここで注意されることは、このInterrupt
トランザクションは、ある特定のプロセッサを目標とす
るもの、または、システムにおける全てのプロセッサに
対する放送的なものである。
たDeMapトランザクションに類似のものである。し
かしながら、この事例においては、仮想的なアドレスか
ら物理的アドレスへの変換は、それぞれに、プロセッサ
12aa−12ij(図1)に対して設けられるトラン
ザクションのルック・アサイド・バッファ(図示されな
い)によって実行される。かくして、DeMapTer
minateトランザクションが規定されていて、リク
エストされたDeMapが完了したときに、プロセッサ
12aa−12ijの各々により、その第1レベルのキ
ャッシュ16aa−16ijをしてこのトランザクショ
ンを始動させることになる。プロセッサ12aa−12
ijがdemapの動作を実行している間に、キャッシ
ュ16aa−16ijがReqShared L(Sh
aredOut)を主張して、DmIRplyがそのS
h(換言すれば、replyShared)ビットを偽
の(“0”の)状態にクリアさせる合致が生じたとき
に、プロセッサ12aa−12ijの全てがリクエスト
されたdemapを完了したという確認をDeMapI
nitiateリクエスタが得るようにされる。
eSingleInvalidate,SwapSin
gleInvalidateおよびKillBlock
トランザクションは、生起するデータ・ブロック共有の
量を減少させ、これによって、データ両立性のプロトコ
ルが、第1の実施例における純粋な更新プロトコルとい
うよりも、ハイブリッドな更新/無効化プロトコルとし
て振舞うようにされる。この変更がなされたのは、両立
性プロトコルの効率性を増大させるという目的のためで
ある。これらの新規なトランザクションのために、両立
性プロトコルの効率性において注目すべき改善があるか
どうかはまだ不確実ではあるけれども、この新規なトラ
ンザクションが両立性プロトコルの有用性または効率性
の逆効果とはならないことは明かである。
変更は、リクエスト・パケットおよびリプライ・パケッ
トのヘッダー・サイクルにおけるOwビットの使用に関
連している。上記で指摘されたように、両立性のあるメ
モリ空間内で実行される読み取りおよび書き込みに関連
するリクエスタおよびレスポンダに対してこのビットで
与えられることは、このような読み取りおよび書き込み
が指向されるデータ・ブロックの所有権の転移に対する
ある所定の付加的なコントロールである。しかしなが
ら、純粋な更新の両立性プロトコルまたはハイブリッド
な更新/無効化の両立性プロトコルのいずれの有効性ま
たは有用性に影響することはない。むしろ、特定のデー
タ・ブロックが“共有”されているか否か、および、
“固有”のものであるか否かについての追跡を維持する
ための、複写され、非同期に維持されているアドレス/
状態・タグに依存するアーキテクチュア(図示されな
い)を用いて、実施されているキャッシュに対する支持
が与えられる。状態の変更はこのようなキャッシュのタ
グからタグへと伝わるから、該キャッシュのプロセッサ
側からは共有されておらず、また、固有でもないように
みえる、局部的にキャッシュされているデータ・ブロッ
クに対してプロセッサが書き込みを発するときには、あ
る一つの競合条件を生じさせることができる。
るために、偽の(“0”の)状態の共有ビットおよびオ
ーナ・ビットを有しているデータ・ブロックに指向され
る書き込みを関連のプロセッサが発したときには、キャ
ッシュに対してWriteSingleの始動を要求す
ることができるが、これではバス・トラフィックが増大
することになる。従って、このようなWriteSin
gleの頻度を減少させるためにOwビットが含まれて
いる。特に、プロセッサが書き込みのペンディング状態
にあるデータ・ブロックのコピーを得るためにRBRq
stを発するときには、そのRBRqstのヘッダー・
サイクルにおけるOwビットをキャッシュによってセッ
トすることが可能となり、これによって、対応のRBR
plyにおけるOwビットが真の(“1”の)状態にセ
ットされるようにリクエスタが要求していることがレス
ポンダに告知されることになる。
性のキャッシュ・メモリ・システムを備えたメモリ共有
式のマルチプロセッサを示す簡略化したブロック図であ
る。
の、標準的なバス/クライエント・インタフェースにお
ける内部ロジックの簡略化した概略図である。
のためのパイプライン式メモリ・バスの概略図である。
のパイプライン式メモリ・バスの概略図である。
よる実施例のためのパイプライン式メモリ・バスの概略
図である。
ンタフェースの種々の信号ポートを同定するための機能
図である。
バラップした関係にあるときの、前述されたタイプのメ
モリ・バスに対して裁定をするための裁定手段を示す機
能的なブロック図である。
バスの裁定とその上でのパケットの送信との間の時間的
なオーバラップを例示するタイミング図である。
フォーマットにおける、バス・トランザクションのため
のリクエスト・パケットにおけるヘッダー・サイクルを
ビット・レベルで示す図である。
ケットにおけるヘッダー・サイクルをビット・レベルで
示す図である。
送ユニットの第1のデータ・サイクル内に含まれるよう
に、バス上においてデータ・ブロックの転送ユニットに
ついてサイクリックな再順番付けの例示をするための図
である。
いる、データの両立性のプロトコルについての基本的な
原理を例示するために有用な、単一レベルのメモリ共有
マルチプロセッサの簡略化した概略図である。
される、バス・トランザクションにおけるリクエスト・
パケットのためのヘッダー・サイクル・フォーマットを
ビット・レベルで示す図である。
される、バス・トランザクションにおけるリプライ・パ
ケットのためのヘッダー・サイクル・フォーマットをビ
ット・レベルで示す図である。
的なデバイス−バス・インタフェースの種々の信号ポー
トを同定するための機能図である。
ンタフェースにおける内部ロジックの簡略化した概略図
である。
る、2−サイクルの長いリクエスト・パケットおよびリ
プライ・パケットの裁定および送信のための、ある所定
の信号の相対的なタイミングを例示するタイミング図で
ある。
ッサ、13:メイン・メモリ、14a−14i:クラス
タ、15a−15i:ローカル・バス、16aa−16
ij:キャッシュ・メモリ、17a:マップキャッシ
ュ、18i:IOブリッジ(裁定手段)、19a−19
i:キャッシュ・メモリ、20a−20i:RAMモジ
ュール、21a−21i:コントローラ、25:コント
ローラ、26:グローバル・バス、28i,29i:コ
ントローラ、30i:LAN、31i:ディスプレイ/
プリンタ・デバイス、34:トランザクション・リクエ
スト・レジスタ、35a−35i,36:裁定手段、3
7:パイプライン・レジスタ、38:裁定リクエスト・
ライン、39:許容ライン、40,41:裁定手段、4
2:裁定ポート、43:ポート、51,52:ワイヤ、
60:キャッシュ、61,62:ライン
Claims (1)
- 【請求項1】1個のメイン・メモリ、複数個のプロセッ
サ、複数個のI/Oデバイス、および、前記プロセッサ
および前記I/Oデバイスに結合されたそれぞれのキャ
ッシュ・メモリを備えているメモリ共有マルチプロセッ
サにおいて、その改良が、 前記複数個のプロセッサの異なるプロセッサのコントロ
ールの下に異なる時点において更新されるべきデータの
少なくとも幾つかの多重コピーを生じさせるトランザク
ションを含む所定組のメモリ・トランザクションの選択
されたものに従って、コマンド、メモリ・アドレス、お
よびそれらの間の前記データを転送するために前記メイ
ン・メモリおよび前記キャッシュ・メモリに結合された
パケット切り換え式バスを含んでおり、 前記トランザクションの各々は、不確定な時間遅れでリ
プライ・パケットが追従するリクエスト・パケットから
なり、これによって多重トランザクションのためのリク
エスト・パケットおよびリプライ・パケットが前記バス
上で時間的にインタリーブされることが可能とされ、 前記トランザクションは、前記プロセッサの全ておよび
前記I/Oデバイスの全てが、前記多重コピーによって
表される全てのデータを含んでいる前記キャッシュ・メ
モリ内に記憶されている全てのデータに対する両立性が
ある値に対するアクセスを有することを確実にする両立
性プロトコルを実施するために選択されており、前記バスは、前記バス上の時間を一連のクロック・サイ
クルに分割する実質的に一定クロック周波数で動作する
同期式のバスであり、 前記選択されたトランザクションのそれぞれのリクエス
ト・パケットおよびリプライ・パケットは、それぞれ前
記バス上で時間が移動された組の連続したクロック・サ
イクルを占有し、 前記トランザクションの或る異なったもののリクエスト
・パケットおよびリプライ・パケットは、前記バス上で
異なったクロック・サイクル数を占めるものである メモ
リ共有マルチプロセッサ。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US62050890A | 1990-11-30 | 1990-11-30 | |
US620508 | 1990-11-30 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH04306758A JPH04306758A (ja) | 1992-10-29 |
JP2512651B2 true JP2512651B2 (ja) | 1996-07-03 |
Family
ID=24486243
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP3312723A Expired - Lifetime JP2512651B2 (ja) | 1990-11-30 | 1991-11-27 | メモリ共有マルチプロセッサ |
Country Status (5)
Country | Link |
---|---|
US (1) | US5924119A (ja) |
EP (1) | EP0488770B1 (ja) |
JP (1) | JP2512651B2 (ja) |
CA (1) | CA2051222C (ja) |
DE (1) | DE69130203T2 (ja) |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0836526A (ja) * | 1994-07-22 | 1996-02-06 | Nec Gumma Ltd | 情報処理システム |
KR0140571B1 (ko) * | 1995-01-19 | 1998-07-01 | 김광호 | 버스제어수단을 구비한 다중프로세서시스템 |
US7266725B2 (en) | 2001-09-03 | 2007-09-04 | Pact Xpp Technologies Ag | Method for debugging reconfigurable architectures |
US5944807A (en) | 1996-02-06 | 1999-08-31 | Opti Inc. | Compact ISA-bus interface |
DE19651075A1 (de) | 1996-12-09 | 1998-06-10 | Pact Inf Tech Gmbh | Einheit zur Verarbeitung von numerischen und logischen Operationen, zum Einsatz in Prozessoren (CPU's), Mehrrechnersystemen, Datenflußprozessoren (DFP's), digitalen Signal Prozessoren (DSP's) oder dergleichen |
DE19654595A1 (de) | 1996-12-20 | 1998-07-02 | Pact Inf Tech Gmbh | I0- und Speicherbussystem für DFPs sowie Bausteinen mit zwei- oder mehrdimensionaler programmierbaren Zellstrukturen |
DE19654846A1 (de) * | 1996-12-27 | 1998-07-09 | Pact Inf Tech Gmbh | Verfahren zum selbständigen dynamischen Umladen von Datenflußprozessoren (DFPs) sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstrukturen (FPGAs, DPGAs, o. dgl.) |
ATE243390T1 (de) | 1996-12-27 | 2003-07-15 | Pact Inf Tech Gmbh | Verfahren zum selbständigen dynamischen umladen von datenflussprozessoren (dfps) sowie bausteinen mit zwei- oder mehrdimensionalen programmierbaren zellstrukturen (fpgas, dpgas, o.dgl.) |
US6542998B1 (en) | 1997-02-08 | 2003-04-01 | Pact Gmbh | Method of self-synchronization of configurable elements of a programmable module |
JP3288261B2 (ja) * | 1997-06-19 | 2002-06-04 | 甲府日本電気株式会社 | キャッシュシステム |
US8686549B2 (en) | 2001-09-03 | 2014-04-01 | Martin Vorbach | Reconfigurable elements |
DE19861088A1 (de) | 1997-12-22 | 2000-02-10 | Pact Inf Tech Gmbh | Verfahren zur Reparatur von integrierten Schaltkreisen |
DE19807872A1 (de) * | 1998-02-25 | 1999-08-26 | Pact Inf Tech Gmbh | Verfahren zur Verwaltung von Konfigurationsdaten in Datenflußprozessoren sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstruktur (FPGAs, DPGAs, o. dgl. |
CN1378665A (zh) | 1999-06-10 | 2002-11-06 | Pact信息技术有限公司 | 编程概念 |
US6766325B1 (en) * | 1999-12-02 | 2004-07-20 | Microsoft Corporation | System and method for maintaining data for performing “what if” analysis |
EP1342158B1 (de) | 2000-06-13 | 2010-08-04 | Richter, Thomas | Pipeline ct-protokolle und -kommunikation |
US6678840B1 (en) * | 2000-08-31 | 2004-01-13 | Hewlett-Packard Development Company, Lp. | Fault containment and error recovery in a scalable multiprocessor |
US8058899B2 (en) | 2000-10-06 | 2011-11-15 | Martin Vorbach | Logic cell array and bus system |
US7844796B2 (en) | 2001-03-05 | 2010-11-30 | Martin Vorbach | Data processing device and method |
US9037807B2 (en) | 2001-03-05 | 2015-05-19 | Pact Xpp Technologies Ag | Processor arrangement on a chip including data processing, memory, and interface elements |
US7444531B2 (en) | 2001-03-05 | 2008-10-28 | Pact Xpp Technologies Ag | Methods and devices for treating and processing data |
AU2002347560A1 (en) * | 2001-06-20 | 2003-01-02 | Pact Xpp Technologies Ag | Data processing method |
US7996827B2 (en) | 2001-08-16 | 2011-08-09 | Martin Vorbach | Method for the translation of programs for reconfigurable architectures |
US7434191B2 (en) | 2001-09-03 | 2008-10-07 | Pact Xpp Technologies Ag | Router |
US8686475B2 (en) | 2001-09-19 | 2014-04-01 | Pact Xpp Technologies Ag | Reconfigurable elements |
US6678799B2 (en) * | 2001-10-18 | 2004-01-13 | Hewlett-Packard Development Company, Lp. | Aggregation of cache-updates in a multi-processor, shared-memory system |
AU2003208266A1 (en) | 2002-01-19 | 2003-07-30 | Pact Xpp Technologies Ag | Reconfigurable processor |
AU2003214003A1 (en) | 2002-02-18 | 2003-09-09 | Pact Xpp Technologies Ag | Bus systems and method for reconfiguration |
US8914590B2 (en) | 2002-08-07 | 2014-12-16 | Pact Xpp Technologies Ag | Data processing method and device |
TWI282513B (en) * | 2002-06-12 | 2007-06-11 | Mediatek Inc | A pre-fetch device of instruction for an embedded system |
US7657861B2 (en) | 2002-08-07 | 2010-02-02 | Pact Xpp Technologies Ag | Method and device for processing data |
WO2004021176A2 (de) | 2002-08-07 | 2004-03-11 | Pact Xpp Technologies Ag | Verfahren und vorrichtung zur datenverarbeitung |
AU2003289844A1 (en) | 2002-09-06 | 2004-05-13 | Pact Xpp Technologies Ag | Reconfigurable sequencer structure |
EP1486875A1 (en) * | 2003-06-12 | 2004-12-15 | STMicroelectronics Limited | Allowing multiple simultaneous acccesses to a cache |
EP1676208A2 (en) | 2003-08-28 | 2006-07-05 | PACT XPP Technologies AG | Data processing device and method |
KR100658591B1 (ko) * | 2005-11-23 | 2006-12-15 | 엠텍비젼 주식회사 | 공유 메모리를 이용한 디스플레이 제어 방법 및 장치 |
EP1808774A1 (en) | 2005-12-22 | 2007-07-18 | St Microelectronics S.A. | A hierarchical reconfigurable computer architecture |
WO2007082730A1 (de) | 2006-01-18 | 2007-07-26 | Pact Xpp Technologies Ag | Hardwaredefinitionsverfahren |
US7756943B1 (en) | 2006-01-26 | 2010-07-13 | Symantec Operating Corporation | Efficient data transfer between computers in a virtual NUMA system using RDMA |
US7702743B1 (en) * | 2006-01-26 | 2010-04-20 | Symantec Operating Corporation | Supporting a weak ordering memory model for a virtual physical address space that spans multiple nodes |
CN101918931B (zh) * | 2007-02-02 | 2013-09-04 | 普西迈斯特公司 | 具有集成高速分组交换串行接口的处理器芯片架构 |
US9582440B2 (en) * | 2013-02-10 | 2017-02-28 | Mellanox Technologies Ltd. | Credit based low-latency arbitration with data transfer |
US9641465B1 (en) | 2013-08-22 | 2017-05-02 | Mellanox Technologies, Ltd | Packet switch with reduced latency |
US10452573B2 (en) | 2016-12-06 | 2019-10-22 | Hewlett Packard Enterprise Development Lp | Scripted arbitration circuit |
US10944694B2 (en) * | 2016-12-06 | 2021-03-09 | Hewlett Packard Enterprise Development Lp | Predictive arbitration circuit |
US10721185B2 (en) | 2016-12-06 | 2020-07-21 | Hewlett Packard Enterprise Development Lp | Age-based arbitration circuit |
KR102471523B1 (ko) * | 2018-04-26 | 2022-11-28 | 에스케이하이닉스 주식회사 | 반도체 집적 회로 장치 및 이를 포함하는 반도체 메모리 시스템 |
US10693811B2 (en) | 2018-09-28 | 2020-06-23 | Hewlett Packard Enterprise Development Lp | Age class based arbitration |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2474201B1 (fr) * | 1980-01-22 | 1986-05-16 | Bull Sa | Procede et dispositif pour gerer les conflits poses par des acces multiples a un meme cache d'un systeme de traitement numerique de l'information comprenant au moins deux processus possedant chacun un cache |
US4451880A (en) * | 1980-10-31 | 1984-05-29 | Honeywell Information Systems Inc. | Memory controller with interleaved queuing apparatus |
US4442487A (en) * | 1981-12-31 | 1984-04-10 | International Business Machines Corporation | Three level memory hierarchy using write and share flags |
US4535448A (en) * | 1982-12-10 | 1985-08-13 | At&T Bell Laboratories | Dual bus communication system |
US4622631B1 (en) * | 1983-12-30 | 1996-04-09 | Recognition Int Inc | Data processing system having a data coherence solution |
US4843542A (en) * | 1986-11-12 | 1989-06-27 | Xerox Corporation | Virtual memory cache for use in multi-processing systems |
US4928225A (en) * | 1988-08-25 | 1990-05-22 | Edgcore Technology, Inc. | Coherent cache structures and methods |
US5050066A (en) * | 1988-10-14 | 1991-09-17 | Intel Corporation | Apparatus with a single memory and a plurality of queue counters for queuing requests and replies on a pipelined packet bus |
US5023488A (en) | 1990-03-30 | 1991-06-11 | Xerox Corporation | Drivers and receivers for interfacing VLSI CMOS circuits to transmission lines |
-
1991
- 1991-09-12 CA CA002051222A patent/CA2051222C/en not_active Expired - Lifetime
- 1991-11-27 JP JP3312723A patent/JP2512651B2/ja not_active Expired - Lifetime
- 1991-11-29 DE DE69130203T patent/DE69130203T2/de not_active Expired - Lifetime
- 1991-11-29 EP EP91311092A patent/EP0488770B1/en not_active Expired - Lifetime
-
1994
- 1994-01-27 US US08/188,660 patent/US5924119A/en not_active Expired - Lifetime
Non-Patent Citations (1)
Title |
---|
IEEETRANSACTIONONCOMPUTERS,Vol.37,No.8(1988−8),PP.909−920 |
Also Published As
Publication number | Publication date |
---|---|
JPH04306758A (ja) | 1992-10-29 |
US5924119A (en) | 1999-07-13 |
EP0488770A2 (en) | 1992-06-03 |
CA2051222A1 (en) | 1992-05-31 |
DE69130203T2 (de) | 1999-03-04 |
EP0488770A3 (en) | 1992-07-15 |
CA2051222C (en) | 1998-05-05 |
DE69130203D1 (de) | 1998-10-22 |
EP0488770B1 (en) | 1998-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2512651B2 (ja) | メモリ共有マルチプロセッサ | |
JPH0810446B2 (ja) | バスの競合を解決するための裁定手段 | |
US5265235A (en) | Consistency protocols for shared memory multiprocessors | |
US6014690A (en) | Employing multiple channels for deadlock avoidance in a cache coherency protocol | |
US6279084B1 (en) | Shadow commands to optimize sequencing of requests in a switch-based multi-processor system | |
US5796605A (en) | Extended symmetrical multiprocessor address mapping | |
JP4472909B2 (ja) | マルチプロセッサノードコントローラ回路及び方法 | |
US6101420A (en) | Method and apparatus for disambiguating change-to-dirty commands in a switch based multi-processing system with coarse directories | |
US6912612B2 (en) | Shared bypass bus structure | |
US6108752A (en) | Method and apparatus for delaying victim writes in a switch-based multi-processor system to maintain data coherency | |
EP0911731B1 (en) | Order supporting mechanisms for use in a switch-based multi-processor system | |
US7529799B2 (en) | Method and apparatus for transaction tag assignment and maintenance in a distributed symmetric multiprocessor system | |
US8407432B2 (en) | Cache coherency sequencing implementation and adaptive LLC access priority control for CMP | |
US6249520B1 (en) | High-performance non-blocking switch with multiple channel ordering constraints | |
JPH0810447B2 (ja) | メモリ共有マルチプロセッサが使用する全ての物理的アドレスのデータ両立性を保持する方法 | |
JPH06180682A (ja) | データの転送方法およびその装置 | |
KR100387541B1 (ko) | 멀티프로세서 시스템에서 캐쉬 코히어런시 유지 방법, 멀티프로세서 시스템 및 노드 제어기 | |
EP0817095A2 (en) | Extended symmetrical multiprocessor architecture | |
JP4361909B2 (ja) | キャッシュコヒーレンス装置 | |
US6889343B2 (en) | Method and apparatus for verifying consistency between a first address repeater and a second address repeater | |
JP4424619B2 (ja) | 情報処理装置 | |
US6735654B2 (en) | Method and apparatus for efficiently broadcasting transactions between an address repeater and a client | |
JP3914250B2 (ja) | キャッシュコヒーレンス装置 | |
JP2006179034A (ja) | キャッシュコヒーレンス装置 | |
EP1370954A2 (en) | Method and apparatus for efficiently broadcasting transactions between a first address repeater and a second address repeater |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 19950123 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 19960220 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 13 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 13 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 14 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 15 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 16 |
|
EXPY | Cancellation because of completion of term | ||
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 16 |