(57)【特許請求の範囲】
【請求項１】
第１のスレーブ・デバイスとプロセッサ・インターフェース・バスとの間でかつ第２のスレーブ・デバイスと前記プロセッサ・インターフェース・バスとの間でデータを転送する方法であって、前記プロセッサ・インターフェース・バスは、マスタ・デバイスと通信し、前記方法は：
前記マスタ・デバイスによって、前記プロセッサ・インターフェース・バスへアドレスを提供する段階；
前記プロセッサ・インターフェース・バス上で第１信号をアサートすることによって、前記第１スレーブ・デバイスが第１データ転送トランザクションを処理していることを表示する段階であって、前記第１スレーブ・デバイスはキャッシュを有する、段階；
前記プロセッサ・インターフェース・バス上で第２信号をアサートすることによって、前記第１データ転送トランザクションに対応するデータは、前記プロセッサ・インターフェース・バスと通信するメイン・メモリ・コントローラによって、メイン・メモリに格納すべきものか否かを示す段階；
前記第１スレーブ・デバイスと前記プロセッサ・インターフェース・バスとの間で前記第１データ転送トランザクションに対応するデータを転送する段階；
前記マスタ・デバイスによって、第２のアドレスを前記プロセッサ・インターフェース・バスに提供する段階；
前記プロセッサ・インターフェース・バス上で前記第１信号をアサートすることによって、前記第２スレーブ・デバイスが第２データ転送トランザクションを処理していることを表示する段階であって、前記第２スレーブ・デバイスのメモリ範囲は前記メイン・メモリのアドレス空間の外部にある、段階；および
前記第２データ転送トランザクションに対応するデータを前記第２スレーブ・デバイスと前記プロセッサ・インターフェース・バスとの間で転送する段階；
を具備することを特徴とするデータを転送する方法。
【請求項２】
前記第１信号および前記第２信号は前記プロセッサ・インターフェース・バスの共通ピンによって順次アサートされることを特徴とする請求項１記載の方法。
【請求項３】
データ処理システムであって：
プロセッサ・インターフェース・バス；
前記プロセッサ・インターフェース・バスに応答するメモリ・コントローラ；
前記メモリ・コントローラに応答するメモリ・デバイス；
前記プロセッサ・インターフェース・バスに応答し、マスタ・デバイスとして動作し、第１キャッシュを有する第１デバイス；および
前記プロセッサ・インターフェース・バスに応答し、スレーブ・デバイスとして動作し、第２キャッシュを有する第２デバイス；
を具備し、前記プロセッサ・インターフェース・バスは、バス・プロトコルに応じて動作し、該バス・プロトコルに従って、前記第１デバイスの前記第１キャッシュ・メモリと前記第２デバイスの前記第２キャッシュ・メモリとの間のデータの転送を含む第１動作を処理し、更に前記第１および第２デバイスの一方と、前記プロセッサ・インターフェース・バスに結合されているローカル・バス・スレーブ・デバイスとの間のデータの転送を含む第２動作を処理し；
前記ローカル・バス・スレーブ・デバイスは前記メモリ・デバイスのメモリ範囲の外部のメモリ範囲を有し；かつ
前記第２デバイスは前記プロセッサ・インターフェース・バス上で第１信号をアサートすることによって、前記第２デバイスが前記第１動作を処理していることを表示し、かつ前記ローカル・バス・スレーブ・デバイスは前記プロセッサ・インターフェース・バス上で前記第１信号をアサートすることによって、前記ローカル・バス・スレーブ・デバイスが前記第２動作を処理していることを表示し、そして前記第２デバイスは前記プロセッサ・インターフェース・バス上で第２信号をアサートすることによって、前記プロセッサ・インターフェース・バスを使用して前記第１動作において転送されるべきデータが前記メイン・メモリ・コントローラによって前記メモリ・デバイスに格納されるべきか否かを示す；
ことを特徴とするデータ処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的に、データ転送に関し、更に特定すれば、プロセッサ・インターフェース・バスを通じたデータ転送に関するものである。
【０００２】
【従来の技術】
現在、メイン・メモリ内に常駐しないキャッシュ可能なデータまたはキャッシュ不可能なデータを含む、ローカル・バス・スレーブ・デバイス(local bus slave device)のためのデータ転送を処理するためには、通常、種々のバス・プロトコルが用いられる。メイン・メモリ内に常駐するキャッシュ可能なデータを一方のキャッシュから他方に直接転送するためには、通常、別個のバス・プロトコルが用いられる。
【０００３】
【発明が解決しようとする課題】
種々のバス・プロトコルの各々は、異なる制御ピン集合を有するので、システム内で用いられるプロトコルが増えると、同様に必要な制御ピンも増え、このためにシステムのコストおよび複雑性が増大する。したがって、キャッシュ間転送およびローカル・バス・スレーブ・デバイスを伴うデータ転送の双方に対応し、効率および経済性を高めたバス・プロトコルが必要とされている。
【０００４】
【課題を解決するための手段】
概して言えば、本発明は、プロセッサ・インターフェース・バスを通じてデータを転送する方法および装置に関する。一実施例では、この方法は、プロセッサ・インターフェース・バスと通信するスレーブ・デバイス間のデータ転送に関し、プロセッサ・インターフェース・バスはマスタ・デバイスと通信する。この方法は、マスタ・デバイスから与えられたアドレスをプロセッサ・インターフェース・バスから受信する段階と、プロセッサ・インターフェース・バス上で第１信号をアサートし、スレーブ・デバイスが関連するデータ転送トランザクションを処理していることを示す段階と、プロセッサ・インターフェース・バス上で第２信号をアサートし、プロセッサ・インターフェース・バスを用いて転送すべきデータは、プロセッサ・インターフェース・バスと通信するメイン・メモリ・コントローラによって、メイン・メモリに格納すべきものか否かを示す段階を含む。次いで、スレーブ・デバイスとプロセッサ・インターフェース・バスとの間でデータを転送する。
【０００５】
他の実施例では、前述の方法は、プロセッサ・インターフェース・バスと通信するスレーブ・デバイス間におけるデータを転送に関連し、この場合、プロセッサ・インターフェース・バスは、マスタ・デバイスと通信する。この方法は、プロセッサ・インターフェース・バスからアドレスを受信する段階であって、アドレスがマスタ・デバイスから与えられる段階と、前記プロセッサ・インターフェース・バス上で第１信号をアサートし、スレーブ・デバイスが関連するデータ転送トランザクションを処理していることを示す段階と、プロセッサ・インターフェース・バス上で第２信号をアサートし、プロセッサ・インターフェース・バスを用いて転送すべきデータは、プロセッサ・インターフェース・バスと通信するメイン・メモリ・コントローラによって、メイン・メモリに格納すべきものか否かを示す段階とを含む。プロセッサ・インターフェース・バス上で第３信号をアサートし、スレーブ・デバイスが、データ転送トランザクションを実行する準備ができたことを示す。次いで、スレーブ・デバイスとプロセッサ・インターフェース・バスとの間でデータを転送する。
【０００６】
更に他の実施例では、前述の方法は、外部ソースからのデータの、複数のデバイスと通信するプロセッサ・インターフェース・バスへの転送に関する。この方法は、外部データ・ソースから、プロセッサ・インターフェース・バスに応答したコントローラにおけるデータおよび関連するメモリ・アドレスを受信する段階を含む。関連するメモリ・アドレスが、複数のデバイスのためのメモリ範囲内にあるか否かについて判定を行った後、プロセッサ・インターフェース・バス上でライト・トランザクションを開始し、プロセッサ・インターフェース・バスを監視し、複数のデバイスからの複数の応答を見つけ出す。複数のデバイスの部分集合から、プロセッサ・インターフェース・バスを通じて、データ・レディ信号を受信する。プロセッサ・インターフェース・バスを制御し、プロセッサ・インターフェース・バスに対するアクセスを、複数のデバイスの部分集合に付与する。次いで、外部データ・ソースから受信したデータを、プロセッサ・インターフェース・バスに転送する。
【０００７】
本発明の一実施例では、前述の装置は、プロセッサ・インターフェース・バスと、プロセッサ・インターフェース・バスに応答するメモリ・コントローラと、メモリ・コントローラに応答するメモリ・デバイスと、プロセッサ・インターフェース・バスに応答し、マスタ・デバイスとして動作する第１デバイスと、第２デバイスとを含むデータ処理システムである。第２デバイスは、プロセッサ・インターフェース・バスに応答し、スレーブ・デバイスとして動作し、プロセッサ・インターフェース・バス上で第１信号をアサートして、スレーブ・デバイスがデータ転送トランザクションを処理していることを示す。また、第２デバイスは、プロセッサ・インターフェース・バス上で第２信号をアサートし、プロセッサ・インターフェース・バスを用いて転送すべきデータは、メイン・メモリ・コントローラによって、メモリ・デバイスに格納すべきものか否かを示す。
【０００８】
他の実施例では、前述の装置は、プロセッサ・インターフェース・バスと、プロセッサ・インターフェース・バスに応答するメモリ・コントローラと、メモリ・コントローラに応答するメモリ・デバイスと、プロセッサ・インターフェース・バスに応答し、マスタ・デバイスとして動作し、第１キャッシュを有する第１デバイスとを含むデータ処理システムである。また、データ処理システムは、プロセッサ・インターフェース・バスに応答し、スレーブ・デバイスとして動作し、第２キャッシュを有する第２デバイスも含む。プロセッサ・インターフェース・バスは、バス・プロトコルに応じて動作し、このバス・プロトコルは、第１デバイスの第１キャッシュ・メモリと第２デバイスの第２キャッシュ・メモリとの間のデータの転送を含む第１動作、および前記第１および第２デバイスの一方と、プロセッサ・インターフェース・バスに結合されているローカル・バス・スレーブ・デバイスとの間のデータの転送を含む第２動作を処理する。
【０００９】
【発明の実施の形態】
図１は、第１マイクロプロセッサ１２，第２マイクロプロセッサ１４，追加のマイクロプロセッサ１６（必要に応じて）、レベル３キャッシュ１８，他のスレーブ・デバイス２０，マスタ・スレーブ・デバイス２２，チップ・セット３２を内蔵し、これらが全てプロセッサ・インターフェース・バス３４に結合されているデータ処理システム１０を示す。第１マイクロプロセッサ１２は、第１レベル２キャッシュ２４に結合され、第２マイクロプロセッサ１４は第２レベル２キャッシュ２６に結合されている。マイクロプロセッサ１６は、レベル２キャッシュ２８に結合されている。メモリ３０は、マスタ・スレーブ・デバイス２２に結合されている。メイン・メモリ３６は、チップ・セット３２に結合されている。チップ・セット３２は、アドレス・コントローラ４４，データ・コントローラ４６，およびメイン・メモリ３６用メモリ・コントローラ（図示せず）を含む。また、チップ・セット３２は、バス調停ユニット４８も含む。更に、チップ・セット３２は、バス３８を通じて、入出力デバイス４０およびその他のバス・モジュール４２にも結合されている。一実施例では、バス３８は周辺Ｉ／Ｏバスである。別の実施例では、アドレス・コントローラ，データ・コントローラ，およびメモリ・コントローラを、チップ・セット３２外部の別個のユニットとして含むことも可能であり、あるいはかかるコントローラ全てを単一のコントローラ内に統合して含むことも可能である。チップ・セット３２は、最新のデスクトップ・コンピュータ・システムにおいて見られるチップ・セットと同様に機能する。したがって、チップ・セットの具体的な機能および設計は、それを用いるシステムによって異なる。図１に示すデータ・システム１０の動作については、図２ないし図７において更に詳しく説明する。
【００１０】
図１のバス３４の特定実施例を図２に示す。一実施例では、バス３４は２つの部分を含む。即ち、アドレス・バス５０とそれに関連する制御および調停ビット、ならびにデータ・バス６０とそれに関連する制御ビットである。この実施例では、アドレスおよびデータ・バスは切り離されているが、他の実施例では、アドレスおよびデータは単一のバス構造に結合することができる。別の実施例では、バスも種々の異なる部分に分割することが可能である。その場合、制御ならびに制御および属性を別個のバスとするか、あるいは互いにリンクさせる。バス・サイズは、データ処理システム１０に必要なアドレス・ビット，データ・ビット，ならびに制御および属性ビットの数によって異なり、したがってシステム毎に異なる可能性があり、それに応じて設計することができる。プロセッサ・バス３４は、最近のデスクトップ・コンピュータ・システムに見られるバスと同様に機能する。バスの設計は、データ処理システムの必要条件によって異なることを、当業者は認めよう。例えば、必要なバス・プロトコルを実施するために、プロセッサ・バスに異なる制御信号が必要となる場合もあり得る。
【００１１】
図３は、図１のデータ処理システム１０において行われる、高レベルのトランザクションのフロー１００を示す。このトランザクション・フローは、種々のバス・フェーズ１０２，１０４，１０６，１０８，１１０を含み、これらが時間に対して相対的に発生する順に示している。アドレス調停フェーズ１０２の間、チップ・セット３２内に位置する調停ユニット４８は、アドレス・バス５０を要求しているデバイスの内、どれがトランザクションのためにアドレス・バス５０の所有権を受信するかについて判定を行う。別の実施例では、調停ユニット４８は、チップ・セット３２外部に、別個のユニットとして配置することも可能である。一旦調停ユニット４８が判断を下したなら、バス所有権を有するデバイス、即ち、マスタ・デバイスは、アドレス転送フェーズ１０４の間、関連する制御ビットと共に、アドレス・バス５０上にマスタ・アドレスを置く。アドレス（スヌープ）応答フェーズ１０６の間、バス３４に結合されている他のデバイスがアドレス・バス５０をスヌープ即ち監視し、マスタ・アドレスに応答する必要があるか否かについて判定を行う。所与のトランザクションに対して、当該トランザクションを要求したデバイスがマスタとなり、アドレスに応答したデバイスがスレーブとなり、マスタのトランザクション要求を処理する(service)。
【００１２】
データ調停フェーズ１０８の間、マスタ・アドレスに関連するデータを含むデバイスは、次にデータ・バス６０の所有権を要求する。データ・バス６０の所有権は、データを含むデバイスが、トランザクションの間データ・バス６０上の情報を制御することを許可する。一旦調停ユニット４８がデータ・バス６０を、それを要求したデバイスまたはデバイス群に付与したなら、データ転送フェーズ１１０が開始し、マスタ・デバイスとスレーブ・デバイスとの間でデータが転送される。尚、別の実施例では、データ処理システム１０の設計による要求に応じて、バス・フェーズのいくつかが同時に発生したり、あるいは時間的に順次発生する可能性もあることを注記しておく。また、別の実施例では、後続のトランザクションのバス・フェーズが、以前のトランザクションのバス・フェーズと重複（または並行）することもあり得る。更に、異なるトランザクションのデータ転送フェーズは、それらに関連するアドレス・フェーズに関して、順序を変更することも可能である。
【００１３】
図４は、チップ・セット３２を用いた、バス３４上のデータ転送トランザクションの一例を表すフローチャート２００を示す。フローチャート２００は、図３のスヌープ応答フェーズ１０６内における、判断ダイヤモンド２０２から開始する。ローカル・バス・デバイスは、デバイス２２，２０，１２，１４，１８のような、バス３４に結合されているデバイスを参照する。アドレスをスヌープした後、ローカル・バス・デバイスがトランザクションを要求していない場合、ブロック２０４に示すように、チップ・セット３２はトランザクション自体を処理する。一方、マスタ・スレーブ・デバイス２２またはその他のスレーブ・デバイス２０のようなローカル・バス・デバイスがトランザクションを要求した場合、フローは判断ダイヤモンド２０６に進む。ローカル・バス・デバイスがトランザクションを要求し、スナーフ信号(snarf signal)をアサートした場合、ローカル・バス・デバイスは既にトランザクションを受け入れており（したがって、スレーブ・デバイスとなっている）、メイン・メモリ３６を更新する必要があることをチップ・セット３２に通知している。本発明の一実施例では、ローカル・バス・スレーブ・デバイスは、要求されているデータを変更し、変更したデータをメイン・メモリ３６および要求元デバイスに書き込みたい場合に、スナーフ信号をアサートする。別の実施例では、ローカル・バス・スレーブ・デバイス（例えば、ライト・スルー・キャッシュ）は、他のデバイスからデータを受信し、そのデータを更にメイン・メモリ３６に送出する場合に、スナーフ信号をアサートする場合もある。更に別の実施例では、チップ・セット３２は、スナーフ禁止信号(don't#snarf signal)がスレーブ・デバイスによってアサートされなければ、デフォルトでスナーフ・モードにすることも可能である。この場合、スナーフしないことを指示する信号がアサートされなければ、データをメイン・メモリ３６に書き込む。
【００１４】
一旦ローカル・バス・スレーブ・デバイスがデータ転送の準備を整えたなら（判断ブロック２０８）、ローカル・バス・スレーブ・デバイスはデータ・レディ信号をアサートし、ローカル・バス・スレーブ・デバイスがデータ・バス６０を要求していることを調停ユニット４８に通知する（ブロック２１０）。マスタによって当初要求されたトランザクション・タイプが読み出された場合、スナーフ動作を実行し、ローカル・バス・スレーブ・デバイスとマスタとの間のデータ転送が、ブロック２１２において行われ、メイン・メモリ３６へのデータ・ライトも行われる。一方、トランザクションが変更を意図したリード（ＲＷＩＴＭ：read-with-intent-to-modify）である場合、ローカル・バス・スレーブ・デバイスとマスタ・デバイスとの間にデータ転送が行われるが、メイン・メモリ３６にはデータは書き込まれない（ブロック２１８に示す通りである）。
【００１５】
判断ダイヤモンド２０６において、スレーブ・デバイスがスナーフ信号をアサートしなかった場合、このトランザクションにはメイン・メモリ３６へのライトは必要でない。一旦データ転送の準備ができたなら（判断ダイヤモンド２１４）、ローカル・バス・スレーブ・デバイスはデータ・レディ信号をアサートし、データ・バス６０の制御を要求する。ブロック２１６において、データ・バス６０の制御が付与されると、ブロック２１８において、ローカル・バス・スレーブ・デバイスとマスタ・デバイスとの間のデータ転送が、データ・バス６０上で行われる。
【００１６】
本発明の一実施例では、マスタは、マイクロプロセッサ１２，１４または１６の１つのようなマイクロプロセッサ，あるいはマスタ／スレーブ・デバイス２２である場合があり、一方スレーブは、その他のマイクロプロセッサ，レベル３キャッシュ１８，マスタ／スレーブ・デバイス２２，またはその他のスレーブ・デバイス２０である場合がある。特定の実施例では、マスタ／スレーブ・デバイス２２が、メモリ３０をそのフレーム・バッファとして有する、グラフィックス・コントローラとすることができる。また、特定の実施例では、別のスレーブ・デバイス２０が、キャッシュ・コントローラ，メイン・メモリ３６外部のアドレスを有するメモリのためのメモリ・コントローラ，または特殊目的のコプロセッサとすることができる。また、別の実施例では、マイクロプロセッサ１つのみを含む場合や、マスタ／スレーブ・デバイスおよびその他のスレーブ・デバイスの種々の組み合わせを含む場合もあり得る。
【００１７】
図５は、バス３４を用いてローカル・バス・デバイスがデータを転送する場合のフローチャートである。ブロック３０２において、ローカル・バス・デバイスは、アドレス・バス５０からのマスタのアドレスをスヌープし、デバイスのタイプにしたがって（判断ダイヤモンド３０４）、そのアドレスへのデータ転送を処理するか否かについて判定を行う特定の方法に従う。ローカル・バス・デバイスがキャッシュ・コントローラである場合（したがって、キャッシュ機能を有する）、ローカル・バス・デバイスのメモリは、メイン・メモリ３６の部分集合となる。例えば、図１において、レベル２キャッシュ２４およびマイクロプロセッサ１２内にある第１キャッシュは、メイン・メモリ３６の部分集合である。この場合、メイン・メモリ３６と、レベル２キャッシュ２４または第１キャッシュのようなメイン・メモリ３６の部分集合との間において、メモリのコヒーレンシ(coherency)が重要となる。デバイスがデータを要求する場合、要求されたデータを含むデバイスは、そのデータの最後に更新されたバージョンにアクセスする必要がある。
【００１８】
しかしながら、ローカル・バス・デバイスが、別個のメモリ範囲のコントローラである場合、メイン・メモリ３６内にはない別個のメモリ範囲を含む。例えば、図１において、メモリ３０（グラフィックス・コントローラ用フレーム・バッファのような）は、メイン・メモリ３６内にはない別個のメモリ範囲となる場合もあり得る。
【００１９】
ローカル・バス・デバイスがキャッシュ・コントローラであり、アドレスがキャッシュ内のタグと一致した場合のように、アドレス・バス５０上でスヌープされたアドレスが、それに関連するキャッシュ内で発見された場合、メモリ・ヒットが得られる。判断ダイヤモンド３０６において、メモリ・ヒットが得られない場合、フローはブロック３０２に戻る。一実施例では、バス３４の介入プロトコル(intervention protocol)を、キャッシュ間介入(cache to cache intervention)のために、プログラムによってイネーブルまたはディゼーブルすることができる。あるいは、介入は、ハードウエアでイネーブルまたはディゼーブルすることも可能である。介入プロトコルをイネーブルした場合、データをメイン・メモリ３６へ又はメイン・メモリ３６から転送しなければならない代わりに、プロセッサ間のキャッシュからキャッシュへの転送のように、ローカル・バス・デバイス間での直接データ転送が可能となる。
【００２０】
介入がイネーブルされず（判断ダイヤモンド３０８）、要求されたデータがローカル・バス・スレーブ・デバイスによって変更されていない（判断ダイヤモンド３１０）場合、ローカル・バス・スレーブ・デバイスはそのトランザクションを完了し、マスタは、ローカル・バス・スレーブ・デバイスからではなく、メイン・メモリ３６からデータを受信する。次に、フローはブロック３０２に戻る。しかしながら、データが変更されている場合、ブロック３１２において、ローカル・バス・スレーブ・デバイスはスヌープ応答を発行し、リトライ要求を示す。リトライ要求は、マスタに、メイン・メモリ３６内のデータが変更バージョンではないことを通知し、そのトランザクション要求を後の時点まで待ってリトライさせる。次に、ブロック３１４において、ローカル・バス・スレーブ・デバイスは、変更したデータをメイン・メモリ３６に書き込む。この時点において、ローカル・バス・スレーブ・デバイスはそのトランザクションを完了し、ローカル・バス・スレーブ・デバイス内のデータには、もはや変更済みとは印されていない。次に、フローはブロック３０２に戻る。ここで、マスタは、そのトランザクションを再度要求することができ、更新済みのデータをメイン・メモリ３６から読み出す。
【００２１】
一方、判断ダイヤモンド３０８において介入がイネーブルされた場合、ローカル・バス・デバイス間の直接トランザクションが許される。介入がイネーブルされ、要求されたデータがローカル・バス・スレーブ・デバイスによって変更されている場合（判断ダイヤモンド３１６）、ブロック３１８において、ローカル・バス・スレーブ・デバイスは、第１信号をアサートすることによって、トランザクションを要求する。第１信号を、ヒット信号とも呼ぶことにする。また、ローカル・バス・スレーブ・デバイスは、第２信号もアサートし、変更済みデータ値のメイン・メモリ３６へのライトを強制する（ブロック３２０）。第２信号を、スナーフ信号とも呼ぶことにする。したがって、マスタはローカル・バス・スレーブ・デバイスへ又はローカル・バス・スレーブ・デバイスから直接データを転送するが、メイン・メモリ３６もデータの更新済みコピーを受信する。次に、フローはブロック３２６におけるデータ転送ステップに進む。これについては、図６を参照して以下で更に詳しく説明する。
【００２２】
介入プロトコルは、判断ダイヤモンド３２２に示すように、変更介入(modified intervention)だけでなく、無変更介入(unmodified intervention)も可能である。無変更介入は、データがローカル・バス・デバイスによって変更されておらず、したがってメイン・メモリ３６から引き出すことも可能であるにも拘らず、ローカル・バス・デバイスの転送を可能にする。データが変更されておらず、無変更介入がイネーブルされない場合、ローカル・バス・スレーブ・デバイスはこのトランザクションを完了しており、マスタ・デバイスはその情報をメイン・メモリ３６から得る。フローは再度ブロック３０２に戻る。しかしながら、無変更介入がイネーブルされ、データがローカル・バス・スレーブ・デバイスによって変更されていない場合、ローカル・バス・スレーブ・デバイスは、スナーフ信号をアサートせずに、ヒット信号をアサートするため（ブロック３２４）、スナーフ動作は行われない。この場合、データが変更されていないので、スナーフ動作は不要である。したがって、メイン・メモリ３６は既にそのデータの最新バージョンを有するので、メイン・メモリ３６へのライトは不要である。次に、フローは、ブロック３２６のデータ転送に進む。
【００２３】
判断ダイヤモンド３０４において先に論じたデバイス・タイプが、別個のメモリ範囲のコントローラである場合、マスタ・アドレスをスヌープする際に、ローカル・バス・スレーブ・デバイスは、判断ダイヤモンド３２８において、マスタ・アドレスがそのメモリ範囲内に該当する場合、メモリ・ヒットが得られたと判断する。メモリ・ヒットが得られ、ローカル・バス・スレーブ・デバイスがトランザクションを処理する役割を担う場合（判断ダイヤモンド３３０）、ローカル・バス・スレーブ・デバイスは、ブロック３４２において、ヒット信号をアサートすることによって、トランザクションを要求する。この場合も、ローカル・バス・デバイスのメモリ範囲はメイン・メモリ３６の外部にあるので、スナーフ動作は不要である。したがって、メイン・メモリ３６へのライトは不要であり、そのアドレス位置はメイン・メモリ３６内に存在すらしないので、このライトは望ましくない。この時点において、ブロック３２６のデータ転送ステップに到達したことになる。
【００２４】
図６は、ローカル・バス・スレーブ・デバイスへのまたはローカル・バス・スレーブ・デバイスからのデータ転送ステップ３２６を示す。トランザクション・タイプがリードである場合（判断ダイヤモンド３５０）、ローカル・バス・スレーブ・デバイスは、ブロック３５２において、マスタ・デバイスに送るデータをフェッチする。トランザクションがライトである場合、ローカル・バス・スレーブ・デバイスは、ブロック３５４において、マスタ・デバイスからデータを受信する準備を行う。リード・トランザクションでは、スレーブはデータを与えるデバイスであり、一方ライト・トランザクションでは、マスタがデータを与えるデバイスとなる。一旦スレーブ・デバイスが転送を進める準備ができたなら、ブロック３５６において、第３信号をアサートすることによって、データ・バス６０を要求する。第３信号を、データ・レディ信号とも呼ぶことにする。この時点で、転送するデータを与えるデバイスは、データ・バス６０へのアクセスを待つ（ブロック３５８）。一旦データ・バス６０の所有権が付与されたなら、データを与えるデバイスは、ブロック３６０に示すように、受信側デバイスが受信する（そして、そのメモリまたはキャッシュに書き込む）データを、データ・バス６０上に置くことによって、データを転送する。
【００２５】
一実施例では、データ・バス６０およびアドレス・バス５０を切断し（図２に示すように）、ローカル・バス・スレーブ・デバイスがデータをフェッチしたり、あるいはデータを受信する用意を行っている間、他のデバイスがデータ・バス６０を自由に使用可能にする。このようにすると、調停ユニット４８がデータ・レディ信号を受信した後、データ・バス６０の所有権をローカル・バス・スレーブ・デバイスに付与するまでは、データ・バス６０は自由に他のために使用することができる。別の実施例では、スレーブ・デバイスは、ライト・トランザクションの間、直ちにマスタ・デバイスからデータを受信可能であると想定する。この場合、スレーブがマスタからのライトを要求するのであれば、データ・レディ信号をアサートする必要はない。
【００２６】
本発明の一実施例は、前述のような３つの信号の組み合わせを用いる。ヒット信号は、メモリ・ヒットが得られたときに、ローカル・バス・スレーブ・デバイスによってアサートされ、データ・レディ信号は、データを転送する準備ができたときに送られ、スナーフ信号は、スナーフ動作を行ってデータをメイン・メモリ３６に送出可能となったときにアサートされる。これらの信号によって、単一のプロトコルが、キャッシュ間転送、ならびにローカル・バス・スレーブ・デバイスおよびメイン・メモリ３６を伴うリードおよびライト双方に対応することが可能となる（図２ないし図６を参照して説明した通りである）。本実施例では、この共通プロトコルに必要な信号は僅か３つに過ぎないので、データ処理システム１０においてこのプロトコルを得るためには、バス３４の制御ピンは３本あればよい。特定の実施例では、ヒット信号とスナーフ信号を単一のピン上に時間多重化することにより、僅か２本の制御ピンのみを用いてこのプロトコルを実施する。この場合、スナーフ応答枠の後の追加サイクルのためにヒット信号をアサートし、データをメイン・メモリ３６にスナーフする必要がないことを示す。これは、拡張ヒット・プロトコルと呼ぶことができ、ヒット信号およびスナーフ信号のための制御ピンは１本だけで済む。何故なら、これらは、この共通ピン上で順次アサートすることが可能であるからである。
【００２７】
スヌープ枠とは、チップ・セット３２が、マスタ・アドレスをスヌープしているスレーブ・デバイスからスヌープ応答を受信するのにどれだけ待つかを意味する。一実施例では、このスヌープ枠は固定長とすることができ、あるいは、データ処理システム１０内においてユーザによってプログラム可能とすることもできる。別の実施例では、異なる方法を用いて、いつスレーブ・デバイスのいずれかによってヒット信号またはスナーフ信号がアサートされたかを判定することも可能である。
【００２８】
上述の実施例にはいくつかの利点がある。例えば、キャッシュ間転送およびメイン・メモリへのライトの選択使用を行うために制御ピンを２本だけ使用すればよいので、システム・コストおよび複雑性双方が低下する。スレーブ・デバイスおよび内部プロセッサ・キャッシュ転送のような種々の異なるトランザクションに単一のプロトコルを用いると、対応する種々の異なるシステムおよびソフトウエア機能を便利にかつ価格効率的に、かかるプロトコルを用いるデータ処理システム上で実行することが可能となる。このように、上述の実施例は、キャッシュ間転送およびローカル・バス・スレーブ・デバイスを伴うデータ転送双方に対応する、低価格でしかも効率的なバス・プロトコルに対する必要性に対処するものである。尚、別実施例では、共通プロトコルを達成するためには、より多くの制御ピン、異なる信号、または信号群の異なる符号化の使用が必要な場合もあり得ることを、当業者は認めよう。
【００２９】
図７は、ブロードキャスト・プロトコル(broadcast protocol)を可能にする、本発明の他の実施例を示す。この実施例では、ブロック４０２において、システム・コントローラは、Ｉ／Ｏ４０またはバス３８上にある他のバス・モジュール４２の１つから外部データを受信する。判断ブロック４０４において、外部データがメイン・メモリ３６またはＩ／Ｏアドレス範囲内に位置することをシステムコントローラが判定した場合、通常のトランザクションが続き（ブロック４０６）、ブロードキャストは行わない。外部データがメイン・メモリ３６またはＩ／Ｏアドレス範囲に該当しない場合、ライト・トランザクションをブロードキャストするデバイスは、バス３４上のライト・アドレスをマスタする（ブロック４０８）。別の実施例では、ブロードキャスト・デバイスは、メイン・メモリ３６にコピーしかつバス３４上のローカル・バス・デバイスにブロードキャストしなければならないデータのアドレス範囲を認識することができる。バス３４上のデバイスは全て、これらがマスタ・デバイスかスレーブ・デバイスかには係らず、バスを監視し、アドレスをスヌープして当該アドレスがそれらのメモリ範囲に該当するか否かについて判定を行う（ブロック４１０）。該当する場合、メモリ範囲がマスタ・アドレスを含むデバイスが、それらのスヌープ応答としてヒット信号をアサートすることにより、トランザクションを要求する。チップ・セット３２の調停ユニット４８のようなブロードキャストを発生するデバイスは、他のデバイス全てからのスヌープ応答を監視し、ヒット信号を探し出す。
【００３０】
一実施例では、ブロードキャストはチップ・セット３２によって発生され、一方他の実施例では、バス３４上のいずれのマスタ・デバイスがブロードキャストを発生することも可能である。一旦バス３４上のデバイスが、チップ・セット３２からブロードキャストされたライトを受け入れる準備ができたなら、当該デバイスは、それらのデータ・レディ信号をアサートすることによって、データ・バス６０の所有権を要求する。一旦調停ユニット４８が、ヒット信号をアサートしたデバイスの各々から、データ・レディ信号の全てを受信したなら（ブロック４１２，４１４）、調停ユニット４８は、これらのデバイス各々およびマスタ・デバイスに、データ・バス６０の所有権を付与する（ブロック４１６）。次いで、ブロック４１８において、データはデータ・バス６０上に転送され、ヒット信号をアサートしたデバイスの各々は、データを沈める(sink)ことができる（バス３４からデータを読み取り、それらのメモリまたはキャッシュにデータを書き込む）。一旦データをスレーブ・デバイスに転送したなら、トランザクションは完了する。
【００３１】
以上、具体的な実施例を参照しながら本発明について説明したが、更なる変更や改良も当業者には想起されよう。また、設計および要素に種々の変更を加えても本発明の機能を達成可能であることを当業者は認めよう。したがって、本発明は、特許請求の範囲に規定した本発明の範囲から逸脱しない変更の全て、およびその均等物を含むと理解すべきものとする。
【図面の簡単な説明】
【図１】本発明の一実施例によるデータ処理システムを示すブロック図。
【図２】図１のバスを示す概略図。
【図３】図１のデータ処理システム内のプロセッサ・インターフェース・バスのバス・フェーズを示す図。
【図４】図３のバスフェーズ１０６，１０８，１１０内において実行される特定の方法を示すフローチャート。
【図５】図３のバス・フェーズ１０４，１０６，１０８，１１０の間においてバスとスレーブとの間で通信を行う方法を示すフローチャート。
【図６】図５のデータ転送ステップを示すフローチャート。
【図７】本発明の一実施例によるブロードキャスト方法を示すフローチャート。
【符号の説明】
１２    第１マイクロプロセッサ
１４    第２マイクロプロセッサ
１６    追加のマイクロプロセッサ
１８    レベル３キャッシュ
２０    スレーブ・デバイス
２２    マスタ・スレーブ・デバイス
２４    第１レベル２キャッシュ
２６    第２レベル２キャッシュ
２８    レベル２キャッシュ
３０    メモリ
３２    チップ・セット
３４    プロセッサ・インターフェース・バス
３６    メイン・メモリ
３８    バス
４０    入出力デバイス
４２    バス・モジュール
４４    アドレス・コントローラ
４６    データ・コントローラ
４８    バス調停ユニット
５０    アドレス・バス
６０    データ・バス
１０２    アドレス調停フェーズ
１０４    アドレス転送フェーズ
１０６    アドレス（スヌープ）応答フェーズ
１０８    バス調停フェーズ
１１０    データ転送フェーズ
【図１】
0003723700.tif 000002
【図２】
0003723700.tif 000003
【図３】
0003723700.tif 000004
【図４】
0003723700.tif 000005
【図５】
0003723700.tif 000006
【図６】
0003723700.tif 000007
【図７】
0003723700.tif 000008