JP4214521B2 - 情報処理システム及びマルチプロセッサ・システム - Google Patents

Description

技術分野
本発明は、一般にマルチプロセッサ・コンピュータ・システムの分野に関し、より具体的には共通のアドレス・バスまたはデータ・バスの制御を必要とする複数の装置間でバス・アービトレーションを実行するための装置に関する。
背景技術
近年、大量の計算能力を必要とするアプリケーションでは、ますますマルチプロセッサ・コンピューティング・システムが使用されるようになっている。多くのタイプのマルチプロセッサ・システムが存在するが、一般に、このようなシステムは、プロセッサ間の資源の共用を容易にするために共通バス上にまとめて結合された複数のプロセッサが独立して動作している。バスはすべてのプロセッサに共通し、各プロセッサは独立して動作しているので、複数のプロセッサが同時に、すなわち、同一クロック・サイクルでそのバスにアクセスしようと試みる。複数のプロセッサがバスの制御権を獲得しようとした場合、バスからのデータ衝突が発生する恐れがある。
したがって、マルチプロセッサ・コンピュータ・システムがバスに対する同時要求のアービトレーションを効果的に行うことは重要なことである。通常、これは、要求側プロセッサの１つに優先順位を割り当て、それがアクセスを実行できるようにすることによって行われる。バスの制御権を獲得しようと試みる装置または実際にバスを制御する装置は「バス・マスタ」と呼ばれる。バス・マスタがバスにアクセスした後、その優先順位は、バスへのアクセスを必要とする他のプロセッサに渡される。
バスに結合された様々なプロセッサ間に優先順位を割り当てる方法は多数存在する。しかし、アービトレーション方式によってバスにアクセスする機会がすべてのプロセッサに、効率的に与えられることは重要なことである。そうではない場合、１つのプロセッサによって繰返しアクセスすると、他のプロセッサはバスの制御権を取得することができず、それにより、他のプロセッサのデータ・ストリームに許されないバス待ち時間が発生する可能性がある。
また、マルチドメイン、分散アービトレーションシステム、およびマルチプロセッサシステムバスのリクエストのアービトレーション制御を複数のアービターによって処理することで、アービトレーションの処理を高速化する方法が、米国特許５，５０９，１２５号に記載されている。ここでは、リクエストは、マルチプロセッサバスに結合された複数のノードで生成される。リクエストは、複数のアービトレーション要求ライン上に示される。各ノードは、対応するノードに関連付けられた１つのアービターを持っている。優先順位は、他のドメインに対する関係として各ドメインにアサインされる。各アービターは、アービトレーションリクエストライン上のリクエストをモニターし、そのノードからのリクエストが待ち状態だった場合に、そのノードが結果としてアービトレーションの結果選択されるか否かの結果を示す信号を生成する。更に、アービターは、アサインされた優先順位に従ってアービトレーションの結果どのノードが選択されたか、結果を示す信号を生成する。
また、従来型のバスは、アドレス・フェーズにデータ・フェーズが（ウェイト・ステートを除いて）常に直ぐに続くバスとして定義される「接続トランザクション・バス」である。換言すれば、アドレス・フェーズ及びデータ・フェーズはデータ・フェーズ中に転送されるデータが常にデータ・フェーズの直前でバス上に配置されたアドレスに関連されるように接続される。アービトレーション・フェーズをアドレス・フェーズ及びデータ・フェーズに重複するのは良いが、アドレス・フェーズ及びデータ・フェーズを重複させることやデータ・フェーズをアドレス・フェーズに対して無関係に発生させることはできない。
これに対して、「スプリットトランザクション・バス」として知られているバスは、データ転送に対して４つのフェーズ、即ち、（１）アドレス・アービトレーション・フェーズ、（２）アドレス／コマンド・フェーズ（３）データ・アービトレーション・フェーズ、及び（４）データ転送フェーズを有する。
スプリットトランザクション・バスでは、データ・フェーズがバス上に配置された関連のアドレス・フェーズに直ぐに続く必要はない。データ・フェーズは、対応するアドレス・フェーズが発生するのと同一順序で発生する必要はない。従って、同じバスのバス・マスタは、何らかのデータが戻される前に、多重アドレス・フェーズを実行することができる。更に、第２のバス・マスタのアドレス・フェーズを第１のバス・マスタのデータ・フェーズに重複させることもできる。スプリットトランザクション・バスにおけるアドレス・アービトレーションは、接続トランザクション・バスのものと同様である。しかし、一つの相違は、アドレス・フェーズにおいて、バス・マスタがアドレス／コマンド信号及びトランザクション識別（ＩＤ）をアサートし、次いでアドレス・バスを直ちに開放する。その際に、バス・マスタは、スレーブがデータを戻すまで待機してもよく、又はアドレス・バスに対して再アービトレーションを行い、かつ付加的なアドレス・フェーズを実行してもよい。スレーブは、アドレス・フェーズにおいて発行されたアドレス／コマンド及びバス・マスタ識別情報を記憶し、次いで転送を完了するためにレディになっているときは、データ・バスに対してアービトレーションを行う。スレーブがデータ・バスについてバスの使用権を得たときは、データ・バス上にプロセッサを識別するトランザクションＩＤを送出すると同時に、データ・バス上にデータを送出する。次いで、バス・マスタはそのトランザクションＩＤを認識して、前記データを受け入れることによって、トランザクションを完了する。
スプリットトランザクション・バスは、バスの利用効率を高めるという点で、非常に優れた手法であるが、その改良という点では、あまり効果的な提案はなされていない。トランザクションを同時発行数を増やせば、ある程度のスプリットトランザクション・バスの効果的な利用を可能とするものの、ハードウエアに対する負担が増加してしまう。
従って、スプリットトランザクション・バスの潜在的な可能性を、更に引き出すことが可能となれば、バスの実効的な帯域を更に広げることができる。
発明の開示
本発明の主な目的は、マルチプロセッサバスの均等な優先順位とスプリットトランザクションの効率の良い複合アービトレーションためのシステムを提供することである。
本件発明者は、スプリットトランザクション・バスの、利用形態を調査し、その最も効果的な利用方法を探るべき目的で研究を行った。その結果、従来のスプリットトランザクション・バスでは、優先順位が、全てのバス・マスタ・デバイス及びバス・スレーブ・デバイスに対して均等に割当てられているという点が再考に値することが明らかになった。そして、スプリット・トランザクションによりバスの実効的な使用効率を向上させた場合、通常外部ポートを通してアクセスタイムの長い外部デバイスにアクセスしたリードデータを転送するためにバスコントローラは、優先順位を待つ必要が生じるという点が、スプリットトランザクションの効果を下げているということを発見した。
図１は、本発明の実施形態による２段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムを説明する図である。ここで、共用バスへのアクセスを行う複数のデバイスは、少なくとも２つのグループに分かれており、第２のグループに属するデバイス（典型的にはリソース）のいずれからもバス使用要求が発行されていない場合にのみ、第１のグループに属するデバイス（典型的にはプロセッサ）のいずれかが、１次のラウンドロビンによってバスの使用が許可される。しかし、第２のグループに属するデバイスからバス使用要求が発行されている場合、第１のグループに属するデバイスのバス使用要求は常に許可されない。この場合、２次のラウンドロビンによって第２のグループに属するデバイスのいずれかにバス使用が許可される。
従って、本発明（請求項１）は，共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行うアービターとからなり、前記複数のデバイスは、少なくとも２つのグループに分かれており、第２のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第１のグループに属するデバイスのいずれかが、前記第１のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第２のグループに属するデバイスからバス使用要求が発行されている場合、前記第１のグループに属するデバイスのバス使用要求は常に許可されず、前記第２のグループに属するデバイスの間で行われるラウンドロビンによって前記第２のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とする情報処理システムを提供する。
本発明（請求項２）は，上記請求項１において，前記複数のデバイスの前記第１のグループは、前記共用バスのバス・マスタとしての複数のプロセッサであり、前記複数のデバイスの前記第２のグループは、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスであることを特徴とする情報処理システムを提供する。
本発明（請求項３）は，上記請求項２において，前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行されることを特徴とする情報処理システムを提供する。
本発明（請求項４）は，上記請求項２において，バス使用の優先順位を決定するアービトレーション装置が、前記複数のプロセッサの各々に設けられていることを特徴とする情報処理システムを提供する。
本発明（請求項５）は，上記請求項２において，バス使用の優先順位を決定するアービトレーション装置が、前記複数のバス・スレーブ・デバイスの各々に設けられていることを特徴とする情報処理システムを提供する。
本発明（請求項６）は，上記請求項２において，前記バス・スレーブ・デバイスは、外部メモリへのアクセスを行うコントローラ及びペリフェラルバスＩＦを含むことを特徴とする情報処理システムを提供する。
本発明（請求項７）は，上記請求項２において，前記複数のプロセッサ、前記バス・スレーブ・デバイス及び前記共用バスは、シングルチップに集積されていることを特徴とする情報処理システムを提供する。
本発明（請求項８）は，共用バスと、前記共用バスのバス・マスタとしての複数のプロセッサと、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスとからなり、前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行され、前記バス・スレーブ・デバイスのいずれからもバス使用要求が発行されていない場合、前記複数のプロセッサのバス使用要求のいずれかが、前記複数のプロセッサの間で行われるラウンドロビンによって許可され、前記バス・スレーブ・デバイスからバス使用要求が発行されている場合、前記複数のプロセッサのバス使用要求は常に許可されず、前記複数のバス・スレーブ・デバイスの間で行われるラウンドロビンによって前記バス・スレーブ・デバイスのいずれかにバス使用が許可されることを特徴とするマルチプロセッサ・システムを提供する。
本発明（請求項９）は，共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行う装置であって、前記複数のデバイスは、少なくとも２つのグループに分かれており、第２のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第１のグループに属するデバイスのいずれかが、前記第１のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第２のグループに属するデバイスからバス使用要求が発行されている場合、前記第１のグループに属するデバイスのバス使用要求は常に許可されず、前記第２のグループに属するデバイスの間で行われるラウンドロビンによって前記第２のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とするバス・アービトレーション装置を提供する。
発明を実施するための最良の形態
図２は、本発明の実施形態による内部バスの高性能分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムのブロックダイアグラムである。このマルチプロセッサシステムには、マスターコントローラＭＣと、ＲＩＳＣエンジンＲＥ０，ＲＩＳＣエンジンＲＥ１と、ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１の５つのプロセッサが備えられている。ここで、マスターコントローラＭＣは、全体の制御を行っており、非対称のマルチプロセッサシステムとなっている。
ＲＩＳＣエンジンＲＥ０及びＲＩＳＣエンジンＲＥ１は、一般にはそれぞれ対等の立場で設けられている汎用のＲＩＳＣプロセッサであるが、同一のプロセッサエンジンでも良いし、異なるプロセッサエンジンを用いても良い。また、既存プロセッサエンジンを利用することも、新たにプロセッサエンジンを設計してもよい。しかし、それらのプロセッサエンジンには、以下に詳細に説明する本発明の実施形態による分散バス・アービトレーションを、それぞれに実装する必要がある。
ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１は、特定の処理内容を持つ数値演算プロセッサであり、転送レートの高いデータの流れをリアルタイムで処理することが可能である。ここでも、ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１は、同一の既存プロセッサエンジンでも良いし、異なる既存プロセッサエンジンを用いても実装できる。また、既存プロセッサエンジンを利用することも、新たにプロセッサエンジンを設計してもよい。しかし、それらのプロセッサエンジンには、やはり、以下に詳細に説明する本発明の実施形態による分散バス・アービトレーションを、それぞれに実装する必要がある。
ＲＩＳＣエンジンＲＥ０及びＲＩＳＣエンジンＲＥ１とＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１は、内部命令バスＩＢＵＳ及び内部システムバスＳＢＵＳを介してプログラム用メモリＩＭに接続されている。同様に、これらは、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳを介してデータ用メモリＤＭに接続されている。これらＲＩＳＣエンジンとＤＳＰエンジンは、内部命令バスＩＢＵＳと、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳのバス・マスタ・デバイスである。また、プログラム用メモリＩＭ及びデータ用メモリＤＭは内部命令バスＩＢＵＳと、内部データバスＤＢＵＳのバス・スレーブ・デバイスである。
また、マスターコントローラＭＣは、内部システムバスＳＢＵＳを介してプログラム用メモリＩＭに接続され、内部データバスＤＢＵＳを介してデータ用メモリＤＭに接続されている。マスターコントローラＭＣは、内部システムバスＳＢＵＳのバス・マスタである。
これら内部命令バスＩＢＵＳ、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳは、それぞれ１２８ビットのバス幅をもち、それぞれに３２ビットのアドレスバスが備えられている。この１２８ビットのバス幅を、２００ＭＨｚで駆動すれば、最大３．２Ｇバイトのバンド幅でデータの転送を行うことができる。もちろん、これらの数値は例示的なもので、更に拡張又は縮小することは、応用によって決定される。
また、１２８ビットのバス幅をもち、それぞれに３２ビットのアドレスバスに加えて、これら内部命令バスＩＢＵＳ、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳには、以下の説明で詳しく述べる次の様な信号線が設けられている。即ち、内部命令バスＩＢＵＳには、ｉ＿ｐｒｉｏｒｉｔｙ（１：０）、ｉ＿ｂｕｓｙ（１：０）、ｉ＿ｒｅｑｕｅｓｔ（３：０）、ｉ＿ｒｅｑｕｅｓｔ＿ｓｌ、ｉ＿ｃｍｄ、ｉ＿ｂｅｒｒの各信号線が設けられている。また、内部データバスＤＢＵＳには、ｄ＿ｐｒｉｏｒｉｔｙ（１：０）、ｄ＿ｂｕｓｙ（３：０）、ｄ＿ｒｅｑｕｅｓｔ（３：０）、ｄ＿ｒｅｑｕｅｓｔ＿ｓｌ、ｄ＿ｃｍｄ（３：０）、ｄ＿ｒｅａｄｙ、ｄ＿ｂｅｒｒの各信号線が設けられている。また、内部システムバスＳＢＵＳには、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）、ｓｙｓ＿ｂｕｓｙ（８：０）、ｓｙｓ＿ｒｅｑｕｅｓｔ（４：０）、ｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（３：０）、ｓｙｓ＿ａｄｄｒｅｓｓ（３１：０）、ｓｙｓ＿ｃｍｄ（１０：０）、ｓｙｓ＿ｂｉｕ＿ｂｅｒｒ、ｓｙｓ＿ｉｐｕ＿ｂｅｒｒ、ｓｙｓ＿ｄｍ＿ｂｅｒｒの各信号線が設けられている。図３は、これらの接続関係を示すブロック図である。ただし、図ではエラー関係の信号（ｘ＿ｂｅｒｒ）は省略している。
また、本実施形態によるシングルチップ・マルチプロセッサシステムでは、外部のメモリへのアクセス用に、２系統のアドレス／データバスが設けられている。１つは、外部システムバスＥＭ１であり、２２ビットのアドレスバスと、１６ビットのデータバスを持っている。そして、最大８ＭバイトのＲＯＭ／フラッシュＲＯＭ、最大１６ＭバイトのＲＯＭ／フラッシュＲＯＭ、及び最大２４Ｍバイトの外部リソースを、この外部システムバスＥＭ１に接続することができる。
もう１つは、外部システムバスＥＭ２であり、２０ビットのアドレスバスと、１６ビット又は３２ビットのデータバスを持っている。そして、最大８ＭバイトのＲＯＭ／フラッシュＲＯＭ、最大３２ＭバイトのＳＲＡＭ／ＳＤＲＡＭ、及び最大２Ｍバイトの外部リソース（ペリフェラル）を、この外部システムバスＥＭ１に接続することができる。
このマルチプロセッサシステムと、外部のメモリとのアクセスは、内蔵されているバスコントローラＢＣが行う。このバスコントローラＢＣは、内部システムバスＳＢＵＳを介して、ＲＩＳＣエンジンＲＥ０及びＲＩＳＣエンジンＲＥ１とＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１と、更に、マスターコントローラＭＣと、スプリットトランザクションを行う。それとは別に、バスコントローラＢＣは、マスターコントローラＭＣと、専用の命令バスＭＩとデータバスＭＤによって接続されており、マスターコントローラＭＣへの命令とデータの供給を行う。また、バスコントローラＢＣとマスターコントローラＭＣとの間には、命令キャッシュが介在しており、通常の方法によって、キャッシングを行う。
更に、内蔵の周辺回路として、タイマ回路とＩ／Ｏポートが、ペリフェラルバス及びペリフェラルバスＩＦ（インターフェース回路）を介して、内部システムバスＳＢＵＳに接続されている。このタイマ回路は、６本のタイマを実装しており、タイマバスを介して、ＲＩＳＣエンジンＲＥ０、ＲＩＳＣエンジンＲＥ１、ＤＳＰエンジンＤＥ０、ＤＳＰエンジンＤＥ１、マスターコントローラＭＣへ、タイマ割り込みを行う。また、ペリフェラルバスを介して、プロセッサ割り込み制御回路へタイマ割り込みを行う。プロセッサ割り込み制御回路は、プロセッサ割り込み要求バスを介して、各プロセッサエンジンのプロセッサ割り込みを行う。バスコントローラＢＣ、ペリフェラルバスＩＦ、プログラム用メモリＩＭ及びデータ用メモリＤＭは内部システムバスＳＢＵＳのバス・スレーブ・デバイス（リソース）である。
以上の、構成要素、ＲＩＳＣエンジンＲＥ０、ＲＩＳＣエンジンＲＥ１、ＤＳＰエンジンＤＥ０、ＤＳＰエンジンＤＥ１、マスターコントローラＭＣ、バスコントローラＢＣ、命令キャッシュ、タイマ回路、プロセッサ割プロセッサ割り込み制御回路、ペリフェラルバスＩＦ、Ｉ／Ｏポートは、１チップの集積回路として実装される。
その他の外部制御信号や、付随する制御回路は、従来のシングルチップ・マルチプロセッサシステムと、基本的に同じなので、詳細な説明を省略する。
以下、本発明の特徴である内部バスの高性能分散バス・アービトレーション方式について、詳細に説明する。前述の５つのプロセッサエンジンには、内部命令バスＩＢＵＳ、データバスそして、内部システムバスＳＢＵＳのそれぞれのバスにアクセスする為のバスアービターを内蔵している。同様に、バスコントローラＢＣ、ペリフェラルバスＩＦ、プログラム用メモリＩＭ及びデータ用メモリＤＭも、内部システムバスＳＢＵＳにアクセスする為のバスアービターを内蔵している。
アービトレーションの方法は、信号の往復を最小限にすることによって短時間で優先順位を決定することができる分散型のアービトレーション方式を採用する。即ち、それぞれのプロセッサエンジンは、バスアービターを内蔵しており、以下に説明するアービトレーションに関係する制御信号は全てこのバスアービターに入力されている。そして、バスアービターは、他のプロセッサやリソースからのリクエストと自分自身のリクエスト、バスのビジー状態、及び優先順位を参照することによってサイクル毎にバスの使用権を獲得できるかどうか判定する。この結果、バスの使用権を獲得したプロセッサが次のサイクルでコマンド及びアドレスを送出しバスを使用することができる。優先順位は、バスの使用権に基づいてラウンドロビン方式で行われる。
この実施形態では、プログラム用メモリＩＭ及びデータ用メモリＤＭは、内部命令バスＩＢＵＳ、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳの駆動クロック周波数に比較して応答速度が低く、リードサイクルでアドレスやコマンドを受けてから、データを返すまで数クロックを要する。また、バスコントローラＢＣやペリフェラルバスＩＦも、外部バスやペリフェラルバスを介して周辺回路へアクセスするので、更に応答速度が遅い。従って、これらバス・スレーブ・デバイスは、リードサイクルでスプリットトランザクションを行う。
即ち、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンのバス・マスタ・デバイスと、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣやペリフェラルバスＩＦのバス・スレーブ・デバイス（リソース）は、スプリットトランザクションを行う。すなわち、（１）アドレス・アービトレーション・フェーズ、（２）アドレス／コマンド・フェーズ、（３）データ・アービトレーション・フェーズ、及び（４）データ転送フェーズを有する。ただし、（１）アドレス・アービトレーション・フェーズ及び（２）アドレス／コマンド・フェーズと、（３）データ・アービトレーション・フェーズ及び（４）データ転送フェーズとは、分割されている。
＜バス使用権の獲得方法＞
本発明の実施形態では、２段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。即ち、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦの各リソースは、バスの使用権について、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンの各プロセッサよりも常に高い優先権が与えられる。そして、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦ間の優先権は、適応型ラウンドロビンによって移動する。同様に、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンの各プロセッサ間の各リソースの優先権も、適応型ラウンドロビンによって移動する。
ここで、図１に示した様な、本発明の実施形態による２段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。１次側の適応型ラウンドロビンは、ＲＩＳＣエンジンＲＥ０，ＲＩＳＣエンジンＲＥ１と、ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１の５つのプロセッサからなる。また、２次側のラウンドロビンは、バス・スレーブとなるプログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦの各リソースからなっている。
１次側の適応型ラウンドロビンでは、各プロセッサは、バスを使用するためにアービトレーションサイクルでリクエストを発行する。各プロセッサからのリクエストは全てのプロセッサによって参照される。即ち、各プロセッサ内のバスアービターは、全てのプロセッサからのリクエストを参照する。バス使用権の優先順位は、ラウンドロビン方式で各プロセッサに対し公平に与えられる。そのアービトレーションアルゴリズムは以下の通り。
▲１▼ ２次側のラウンドロビンのアービトレーションからリクエストが発行されていれば、そのリソース（２次側でバスのアクセス権を獲得したリソース）が、バスの使用権を得る。
▲２▼ ２次側のラウンドロビンのアービトレーションからリクエストが無く、現在優先権を持つプロセッサがリクエストを発行していれば、そのプロセッサがバスの使用権を得る。
▲３▼ ２次側のラウンドロビンのアービトレーションからリクエストが無く、現在優先権を持つプロセッサがリクエストを発行していなければ、優先権の与えられる順序に従ってリクエストを発行しているプロセッサがバスの使用権を得る。
▲４▼ ２次側のラウンドロビンのアービトレーションからリクエストが無く、１次側の何れのプロセッサからもリクエストが全く無い場合、あるいはリクエスト先がビジーでリクエストが受け付けられない場合、優先権は移動しない。
▲５▼ 次のサイクルの優先権は、バスの使用権を獲得した次のプロセッサに移動する。
また、１次側の適応型ラウンドロビンによるアービトレーションの結果、２次側のリソースに対するアクセスが行われるが、アクセスがスプリット・トランザクションの場合、即ちリードアクセスの場合にのみ２次側のラウンドロビンが使用される。ライトアクセスの場合、リソース側のバッファに取り込まれるので、プロセッサから見れば、ノーウエイトで処理が完了するので、スプリット・トランザクションをする必要はない。
各リソースは、リードデータの準備が出来ると、バスを使用するためにアービトレーションサイクルでリクエストを発行する。各リソースからのリクエストは全てのリソースによって参照される。即ち、各リソース内のバスアービターは、全てのリソースからのリクエストを参照する。バス使用権の優先順位は、ラウンドロビン方式で各リソースに対し公平に与えられる。そのアービトレーションアルゴリズムは以下の通り。
▲１▼ 現在優先権を持つリソースがリクエストを発行していれば、そのリソースがバスの使用権を得る。
▲２▼ 現在優先権を持つリソースがリクエストを発行していなければ、優先権の与えられる順序に従ってリクエストを発行しているリソースがバスの使用権を得る。
▲３▼ 何れのリソースからもリクエストが全く無い場合、優先権は移動しない。
▲４▼ 次のサイクルの優先権は、バスの使用権を獲得した次のリソースに移動する。
すなわち、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦの各リソースからなるグループと、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンの各プロセッサからなるグループとの間では、固定優先の分散型アービトレーションを行い、グループの内部では、適応型ラウンドロビンに基づいて、分散型アービトレーションを行う。即ち、マルチプロセッサバスの均等な優先順位の移動と、固定的に優先権の与えられたスプリットトランザクションによる、効率の良い複合アービトレーションが実現する。
このような複合アービトレーションによれば、スプリット・トランザクションによりバスの実効的な使用効率を向上させる上で、明瞭なアドバンテージをもたらす。本件発明者が調査したところ、一般的なプログラムの実行において、各リソースに常に最高の優先権を与えたことによる処理が遅れる具体例は発見できなかった。そして、統計的に、バスの使用効率の向上と全体の処理速度の向上が期待できることが分かった。
これは、次の様な事情による。すなわち、各リソースがリクエストを発行している場合、各リソースがバスにデータを出力すると、それを要求したプロセッサは、直ちにそのデータの処理を行うことができ、確実に１サイクル分処理が速まる。一方、各リソースにバスの使用権を譲ったプロセッサは、１サイクル分処理が遅れる場合と、実質的な処理の遅れはない場合がある。
それに対して各リソースがリクエストを発行している場合で、もし他のプロセッサにバスの使用権を与えた場合には、プロセッサはバスの使用後、次のデータがくるまで、そこで処理が止まってしまうということがあり得る。一方、各リソースも確実に１サイクル分処理が遅れ、そのデータを待っているプロセッサもやはり１サイクル分処理が遅れる。
＜バスサイクルとバスの動作モード＞
図４は、内部バスを使用して、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンによる、各リソースからのリードサイクルを示す図である。まず、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンは、アービトレーションの後、各リソースに対して、コマンドと共にアドレスを送出する。各リソースがデータの準備ができると、アービトレーション（リクエスト）によって内部システムバスＳＢＵＳの使用権を獲得し、コマンドを発行し、該当するＲＩＳＣエンジンやＤＳＰエンジンは、そのデータを取り込む。
図５は、内部バスを使用して、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンによる、各リソースからのリードサイクルを示す図であるが、アドレスを送出する際に、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンは、転送データ数ｎを各リソースに通知する。各リソースがデータの準備ができて連続転送する場合、リクエストを発行し続けておき、外部バスからのレディに応じて内部バスにデータを転送することができる。
＜内部命令バスＩＢＵＳへのアクセス＞
以下、内部命令バスＩＢＵＳへのアクセス制御の詳細を説明する。ＲＩＳＣエンジンやＤＳＰエンジンが共用するプログラム用メモリをアクセスする時に、内部命令バスＩＢＵＳの使用権を得る場合には、ある時点での内部命令バスＩＢＵＳ使用の優先順位を示すための２ビットの信号ｉ＿ｐｒｉｏｒｉｔｙ（１：０）を用いる。図６は、ｉ＿ｐｒｉｏｒｉｔｙ（１：０）によって示される優先順位を説明する図である。ここに示した通り、ｉ＿ｐｒｉｏｒｉｔｙ（１：０）が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
各ＲＩＳＣエンジンやＤＳＰエンジンは、プログラム用メモリＩＭが内部命令バスＩＢＵＳの使用リクエストｉ＿ｒｅｑｕｅｓｔ＿ｓｌを発行していない場合で且つ、ｉ＿ｂｕｓｙ（１：０）信号をみて”使用可能”の状態の時に、内部命令バスＩＢＵＳの使用リクエストを発行し、優先順位に従って内部命令バスＩＢＵＳの使用権を獲得する。ｉ＿ｂｕｓｙ（０）信号は、マスターコントローラＭＣによって出力される。図７は、内部命令バスＩＢＵＳ及び内部システムバスＳＢＵＳによるプログラム用メモリのアクセス状況によって、マスターコントローラＭＣが生成するｉ＿ｂｕｓｙ（０）信号の生成アルゴリズムを示す表である。ここで、（１ｓｔ）又は（２ｎｄ）は、リクエストが重なった場合の順番を示す。例えば、リードリクエストが重なった場合に、最初に処理されるリードリクエストがＲｅａｄ（１ｓｔ）であり、次に処理されるリードリクエストがＲｅａｄ（２ｎｄ）である。Ｗｒｉｔｅ Ｌａｓｔは、連続書き込みの最後のライトサイクルを意味する。また、ｉ＿ｂｕｓｙ（１）信号は、バス権を獲得したＲＩＳＣエンジンやＤＳＰエンジンがコマンドを送出する時、内部命令バスＩＢＵＳを続けて使用する場合に１、内部命令バスＩＢＵＳを１サイクルだけ使用する場合には０とする。
また、プログラム用メモリは、リードリクエストに対してデータレディ信号としてバス使用要求信号ｉ＿ｒｅｑｕｅｓｔ＿ｓｌを出力する。このバス使用要求信号ｉ＿ｒｅｑｕｅｓｔ＿ｓｌは、アドレス送出（コマンド）に対するデータが準備完了であることを示す。プロセッサは、リードに対するデータをプログラム用メモリからのデータレディ信号としてのバス使用要求信号ｉ＿ｒｅｑｕｅｓｔ＿ｓｌを見て受け取る。
ＲＩＳＣエンジンやＤＳＰエンジンからのバス使用リクエストは、ｉ＿ｒｅｑｕｅｓｔ（３：０）の内の各１ビットの信号を各ＲＩＳＣエンジンやＤＳＰエンジンが出力する。すなわちＲＩＳＣエンジンＲＥ０はｉ＿ｒｅｑｕｅｓｔ（０）、ＲＩＳＣエンジンＲＥ１はｉ＿ｒｅｑｕｅｓｔ（１）、ＤＳＰエンジンＤＥ０はｉ＿ｒｅｑｕｅｓｔ（２）、ＤＳＰエンジンＤＥ１はｉ＿ｒｅｑｕｅｓｔ（３）をドライブする。図８は、ＲＩＳＣエンジンＲＥ０が出力するｉ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。ダブル・フェッチサイクルは、分岐のターゲットアドレスの下位４ビットが８ｈ以上、即ち１回のフェッチサイクルで、一命令を２バイトとして、４命令以下の命令コードしかフェッチできないような場合に用いられる。
バスの使用権は、ｉ＿ｂｕｓｙ（１：０）＝”００”のときにアービトレーションで決定される。図９は、内部命令バスＩＢＵＳのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのｉ＿ｐｒｉｏｒｉｔｙ（１：０）は、バス使用権を獲得したＲＩＳＣエンジンやＤＳＰエンジンの次のＲＩＳＣエンジンやＤＳＰエンジン（順序は、ＲＥ０→ＲＥ１→ＤＥ０→ＤＥ１→ＲＥ０）を指す。
ＲＩＳＣエンジンやＤＳＰエンジンは、アービトレーション・サイクルでバス使用権獲得後、次のサイクル（アドレス送出サイクル）でアドレスとともにプログラム用メモリに対するコマンドｉ＿ｃｍｄを出力する。図１０は、コマンドｉ＿ｃｍｄの意味を説明する図である。プログラム用メモリへの書き込みは内部システムバスＳＢＵＳを介して行われる。
プログラム用メモリ側で、要求されたデータの準備が完了すると、バス使用要求信号ｉ＿ｒｅｑｕｅｓｔ＿ｓｌを発行する。バス使用要求信号ｉ＿ｒｅｑｕｅｓｔ＿ｓｌは、他のバス使用要求信号に優先するので、直ちにデータの転送が行われる。
尚、プログラム用メモリは、プロセッサから送られてきたアドレスが、プログラム用メモリの実装されているアドレス空間外のときデータサイクルで、バスエラーｉ＿ｂｅｒｒ＝１が返される。このとき、プログラム用メモリの出力ｉ＿ｄａｔａ（１２７：０）の内容は無効である。
＜内部データバスＤＢＵＳへのアクセス＞
以下、内部データバスＤＢＵＳへのアクセスの詳細を説明する。ＲＩＳＣエンジンやＤＳＰエンジンが共用するデータ用メモリＤＭへのアクセスする時に、内部データバスＤＢＵＳの使用権を得る必要がある。この場合、ある時点での内部データバスＤＢＵＳ使用の優先順位を示すための２ビットの信号ｄ＿ｐｒｉｏｒｉｔｙ（１：０）を用いる。図１１は、ｄ＿ｐｒｉｏｒｉｔｙ（１：０）によって示される優先順位を説明する図である。ここに示した通り、ｉ＿ｐｒｉｏｒｉｔｙ（１：０）が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
各ＲＩＳＣエンジンやＤＳＰエンジンは、データ用メモリＤＭが内部データバスＤＢＵＳの使用リクエストｄ＿ｒｅｑｕｅｓｔ＿ｓｌを発行していない場合で且つ、ｄ＿ｂｕｓｙ（３：０）信号をみて”使用可能”の状態の時に、内部データバスＤＢＵＳの使用リクエストを発行し、優先順位に従って内部命令バスＩＢＵＳの使用権を獲得する。ｄ＿ｂｕｓｙ（３：２）は、アドレス送出サイクルでのバスの使用状況に応じて、バス使用権を獲得したプロセッサが生成される。どのプロセッサもバスの使用権を獲得していない時にはマスターコントローラＭＣが”００”をドライブする。図１２は、内部データバスＤＢＵＳ及び内部システムバスＳＢＵＳによるデータ用メモリのアクセス状況によって、マスターコントローラＭＣが生成するｄ＿ｂｕｓｙ（１：０）信号の生成アルゴリズムを示す表である。ここで、ｄ＿ｂｕｓｙ（２）は、将来の為のリザーブビットであり、内部リソースが追加された場合に使用される。ｄ＿ｂｕｓｙ（３）は、バス権を獲得したＲＩＳＣエンジンやＤＳＰエンジンがコマンドを送出する時、内部データバスＤＢＵＳを続けて使用する場合に１、内部データバスＤＢＵＳを１サイクルだけ使用する場合には０をドライブする。
ＲＩＳＣエンジンやＤＳＰエンジンからのバス使用リクエストは、ｄ＿ｒｅｑｕｅｓｔ（３：０）の内の各１ビットの信号を各ＲＩＳＣエンジンやＤＳＰエンジンが出力する。すなわちＲＩＳＣエンジンＲＥ０はｄ＿ｒｅｑｕｅｓｔ（０）、ＲＩＳＣエンジンＲＥ１はｄ＿ｒｅｑｕｅｓｔ（１）、ＤＳＰエンジンＤＥ０はｄ＿ｒｅｑｕｅｓｔ（２）、ＤＳＰエンジンＤＥ１はｄ＿ｒｅｑｕｅｓｔ（３）をドライブする。図１３は、ＲＩＳＣエンジンＲＥ０が出力するｄ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。
図１４は、内部命令バスＩＢＵＳのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのｄ＿ｐｒｉｏｒｉｔｙ（１：０）は、バス使用権を獲得したＲＩＳＣエンジンやＤＳＰエンジンの次のＲＩＳＣエンジンやＤＳＰエンジン（順序は、ＲＥ０→ＲＥ１→ＤＥ０→ＤＥ１→ＲＥ０）を指す。
各ＲＩＳＣエンジンやＤＳＰエンジンは、リードリクエストであればｄ＿ｂｕｓｙ（３：０）＝”００００”のとき、ライトリクエストであればｄ＿ｂｕｓｙ＝”００００”あるいはｄ＿ｂｕｓｙ＝”００１０”のときにリクエストを出力できる。また、各ＲＩＳＣエンジンやＤＳＰエンジンは、アービトレーション・サイクルでバス使用権獲得後、次のサイクル（アドレス送出サイクル）でアドレスとともにデータ用メモリに対するコマンドｄ＿ｃｍｄ（３：０）を出力する。図１５は、データ用メモリに対するコマンドｄ＿ｃｍｄ（３：０）の意味を説明する図である。
尚、データ用メモリは、プロセッサから送られてきたアドレスが、データ用メモリの実装されているアドレス空間外のときデータサイクルで、バスエラーｉ＿ｂｅｒｒ＝１が返される。このとき、データ用メモリの出力ｄ＿ｄａｔａ（１２７：０）の内容は無効である。
また、データ用メモリは、リードリクエストに対してデータレディ信号としてバス使用要求信号ｄ＿ｒｅｑｕｅｓｔ＿ｓｌを出力する。このバス使用要求信号ｄ＿ｒｅｑｕｅｓｔ＿ｓｌは、アドレス送出（コマンド）に対するデータが準備完了であることを示す。プロセッサは、リードに対するデータをプログラム用メモリからのデータレディ信号としてのバス使用要求信号ｄ＿ｒｅｑｕｅｓｔ＿ｓｌを見て受け取る。
データ用メモリに対して内部システムバスＳＢＵＳと内部データバスＤＢＵＳから同時にリードリクエストが送出された場合、プログラム用メモリでは内部システムバスＳＢＵＳからのコマンドを受け取った後に内部命令バスＩＢＵＳからのコマンドを行う。
＜内部システムバスＳＢＵＳへのアクセス＞
以下、内部システムバスＳＢＵＳへのアクセスの詳細を説明する。マスターコントローラＭＣと、ＲＩＳＣエンジンＲＥ０，ＲＩＳＣエンジンＲＥ１と、ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１の５つのプロセッサは、内部システムバスＳＢＵＳを介して、バスコントローラＢＣとペリフェラルバスＩＦ及びプログラム用メモリＩＭとデータ用メモリＤＭに対してリードサイクル及びライトサイクルを実行することができる。ただし、バスコントローラＢＣは、直接プログラム用メモリＩＭとデータ用メモリＤＭに対してリードサイクル及びライトサイクルを実行することができる。
従って、内部システムバスＳＢＵＳの効率の良いアービトレーションは、全体のスループットを向上させる上で、極めて重要となる。ここでは、５つのプロセッサからマスターコントローラＭＣ（外部メモリ空間）へのリードサイクル、ＲＩＳＣエンジンＲＥ０及びＲＩＳＣエンジンＲＥ１からプログラム用メモリＩＭとデータ用メモリＤＭに対してのリードサイクル（内部メモリ空間）、及び５つのプロセッサからペリフェラルバスＩＦに対してのリードサイクル（内部メモリマップドＩ／Ｏ空間）は、スプリット・トランザクションによって、実効的なバスの使用効率を向上させている。
特に重要なのは、優先順位の設定である。本発明の実施形態では、２段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。即ち、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦの各リソースは、バスの使用権について、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンの各プロセッサよりも常に高い優先権が与えられる。そして、プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦ間の優先権は、適応型ラウンドロビンによって移動する。同様に、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンの各プロセッサ間の優先権も、適応型ラウンドロビンによって移動する。
マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンは、バスコントローラＢＣとペリフェラルバスＩＦのいずれも内部システムバスＳＢＵＳの使用リクエストを行っていない場合にのみ、内部システムバスＳＢＵＳの使用リクエストを発行できる。図１６は、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）によって示される優先順位を説明する図である。
プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦからのバス使用リクエストを行う場合には、ｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（３：０）の内の各１ビットの信号を各ＲＩＳＣエンジンやＤＳＰエンジンが出力する。すなわちプログラム用メモリＩＭはｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（０）、データ用メモリＤＭはｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（１）、バスコントローラＢＣはｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（２）、ペリフェラルバスＩＦはｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（３）をドライブする。図１７は、バスコントローラＢＣが出力するｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（０）の意味を説明する図である。図１８は、ｓｙｓ＿ｐｒｉｏｒｉｔｙ＿ｓｌ（２：０）によって示される優先順位を説明する図である。
図１９は、内部システムバスＳＢＵＳのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのｓｙｓ＿ｐｒｉｏｒｉｔｙ＿ｓｌ（１：０）は、バス使用権を獲得したプログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦ（順序は、ＩＭ→ＤＭ→ＢＣ→ＩＦ）を指す。
プログラム用メモリＩＭ、データ用メモリＤＭ、バスコントローラＢＣ及びペリフェラルバスＩＦの各リソースのいずれも内部システムバスＳＢＵＳの使用リクエストを行っていない場合、各ＲＩＳＣエンジンやＤＳＰエンジンは、ｓｙｓ＿ｂｕｓｙ（８：０）信号（バスコントローラＢＣ、ペリフェラルバスＩＦ、プログラム用メモリＩＭ及びデータ用メモリＤＭのステータスを示す）を見て、バスがビジーでなく、アクセスターゲットがビジーでなければ内部システムバスＳＢＵＳの使用リクエストを出し、優先順位に従って使用権を獲得する。
ここで、ｓｙｓ＿ｂｕｓｙ（０）信号は、バスコントローラＢＣがドライブする。すなわち、バスコントローラＢＣが、このｓｙｓ＿ｂｕｓｙ（０）信号をアサートした場合、他のプロセッサは、バスコントローラＢＣへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、バスコントローラＢＣは、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンから、リードコマンドやアドレスを受けると、バスコントローラＢＣは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、ｓｙｓ＿ｂｕｓｙ（０）信号をアサートし、それ以上の受付けを停止する。
また、ｓｙｓ＿ｂｕｓｙ（１）信号は、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンが、バスコントローラＢＣへ後述するコマンドを出力すると同時に１クロックだけアサートする。これは、バスコントローラＢＣからコマンドに対する応答ステートが返されるまでの間（１クロック）、他のプロセッサからバスコントローラＢＣへアクセスすることを禁止する為である。
マスターコントローラＭＣと、ＲＩＳＣエンジンＲＥ０，ＲＩＳＣエンジンＲＥ１と、ＤＳＰエンジンＤＥ０及びＤＳＰエンジンＤＥ１との間のアービトレーションは、適応型ラウンドロビンで行われる。この場合、ある時点での内部データバスＤＢＵＳ使用の優先順位を示すための３ビットの信号ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）を用いる。図２１は、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）によって示される優先順位を説明する図である。ここに示した通り、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
ここで、ｓｙｓ＿ｂｕｓｙ（２）信号は、データ用メモリＤＭがドライブする。すなわち、データ用メモリＤＭが、このｓｙｓ＿ｂｕｓｙ（２）信号をアサートした場合、他のプロセッサは、データ用メモリＤＭへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、データ用メモリＤＭは、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンから、リードコマンドやアドレスを受けると、データ用メモリＤＭは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、ｓｙｓ＿ｂｕｓｙ（２）信号をアサートし、それ以上の受付けを停止する。
また、ｓｙｓ＿ｂｕｓｙ（３）信号は、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンが、データ用メモリＤＭへ後述するコマンドを出力すると同時に１クロックだけアサートする。これは、データ用メモリＤＭからコマンドに対する応答ステートが返されるまでの間（１クロック）、他のプロセッサからデータ用メモリＤＭへアクセスすることを禁止する為である。
ここで、ｓｙｓ＿ｂｕｓｙ（４）信号は、プログラム用メモリがドライブする。すなわち、プログラム用メモリが、このｓｙｓ＿ｂｕｓｙ（４）信号をアサートした場合、他のプロセッサは、プログラム用メモリへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、プログラム用メモリは、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンから、リードコマンドやアドレスを受けると、プログラム用メモリは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、ｓｙｓ＿ｂｕｓｙ（４）信号をアサートし、それ以上の受付けを停止する。
また、ｓｙｓ＿ｂｕｓｙ（５）信号は、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンが、プログラム用メモリへ後述するコマンドを出力すると同時に１クロックだけアサートする。これは、プログラム用メモリからコマンドに対する応答ステートが返されるまでの間（１クロック）、他のプロセッサからプログラム用メモリへアクセスすることを禁止する為である。
ｓｙｓ＿ｂｕｓｙ（６）信号は、ペリフェラルバスＩＦでドライブされ、ペリフェラルバスＩＦのステータスを示す。ｓｙｓ＿ｂｕｓｙ（６）信号が状態の時は、ペリフェラルバスＩＦへのアクセス目的でバス使用リクエストを要求することはできない。もちろん、ペリフェラルバスＩＦへのコマンドも発行できない。具体的に説明すれば、ペリフェラルバスＩＦは、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンから、リードコマンドやアドレスを受けると、ペリフェラルバスＩＦは一旦それを内部のバッファに保持し、比較的低速な周辺回路へのアクセスし結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、ｓｙｓ＿ｂｕｓｙ（６）信号をアサートし、それ以上の受付けを停止する。
また、ｓｙｓ＿ｂｕｓｙ（７）信号は、ペリフェラルバスＩＦがドライブによってドライブされ、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンが、ペリフェラルバスＩＦへ後述するコマンドを出力すると同時に１クロックだけアサートする。これは、ペリフェラルバスＩＦからコマンドに対する応答ステートが返されるまでの間（１クロック）、他のプロセッサからペリフェラルバスＩＦへアクセスすることを禁止する為である。
ｓｙｓ＿ｂｕｓｙ（８）信号は、バスの使用権を獲得したマスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンがコマンドを送出する時、内部システムバスＳＢＵＳを続けて使用する場合に１、内部システムバスＳＢＵＳを１サイクルだけ使用する場合には０をドライブする。これによって、連続してバスを使用することができる。
このｓｙｓ＿ｂｕｓｙ（８）信号は、マスターコントローラＭＣ、ＲＩＳＣエンジン、ＤＳＰエンジンがバスコントローラＢＣやペリフェラルバスＩＦのようにリード・アクセスを要求し、データのレディを待つ場合に、コマンド送出サイクルから最後のレディを受け取るまでの間、バス使用権を獲得したプロセッサによって出力される。
内部システムバスＳＢＵＳ使用リクエストは、ｓｙｓ＿ｒｅｑｕｅｓｔ（４：０）の内の各１ビットの信号をマスターコントローラＭＣおよび各ＲＩＳＣエンジンやＤＳＰエンジンが出力する。すなわちＲＩＳＣエンジンＲＥ０はｓｙｓ＿ｒｅｑｕｅｓｔ（０）、ＲＩＳＣエンジンＲＥ１はｓｙｓ＿ｒｅｑｕｅｓｔ（１）、ＤＳＰエンジンＤＥ０はｓｙｓ＿ｒｅｑｕｅｓｔ（２）、ＤＳＰエンジンＤＥ１はｓｙｓ＿ｒｅｑｕｅｓｔ（３）、マスターコントローラＭＣはｓｙｓ＿ｒｅｑｕｅｓｔ（４）をドライブする。図２０は、ＲＩＳＣエンジンＲＥ０が出力するｓｙｓ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。
バス使用権は、図２１に示す規則に従って決められる。また、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンは、バス使用権獲得後、次のサイクルでアドレスとともにコマンドを出力する。図２２は、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンが出力するコマンドの一覧である。ここで、コマンド発行元ＳＲＣのＰｘは、コントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンのプロセッサＩＤであり、アクセス先のＢＩＵはバスコントローラＢＣ、ＤＭはデータ用メモリＤＭ、ＩＭはプログラム用メモリＩＭ、ＩＰＵはペリフェラルバスＩＦを示す。
尚、コマンドｓｙｓ＿ｃｍｄ（３：０）は、転送データ数（ロードマルチ、ストアマルチでＢＩＵに対するコマンド時に使用）であり、たとえば、”００００”は１６ロングワード、”０００１”は１ロングワード、”１１１１”は１５ロングワードである。また、コマンドｓｙｓ＿ｃｍｄ（５：４）、は、データサイズ（００：バイト、０１：ワード、１０：ロングワード、１１：リザーブ）であり、ｓｙｓ＿ｃｍｄ（６）によって、ロードストア（０：ストア、１：ロード）を識別し、ｓｙｓ＿ｃｍｄ（１０：７）は、アクセスのデスティネーション（ＢＣからのコマンドを除く）を示す。更に、”００００”のとき、コマンドはＮＯＰとなる。
尚、マスターコントローラＭＣは、ＲＩＳＣエンジンやＤＳＰエンジンから送られてきたアドレスが、実装されているアドレス空間外のとき、あるいはリザーブのコマンドが送られてきた時にデータサイクルで、バスエラーｓｙｓ＿ｂｉｕ＿ｂｅｒｒ＝１を返す。同様に、データ用メモリＤＭは、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンから送られてきたアドレスが、実装されているアドレス空間外の時にデータサイクルで、バスエラーｓｙｓ＿ｄｍ＿ｂｅｒｒ＝１を返す。また、プログラム用メモリは、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンから送られてきたアドレスが、実装されているアドレス空間外の時にデータサイクルで、バスエラーｓｙｓ＿ｄｍ＿ｂｅｒｒ＝１を返す。また、ペリフェラルバスＩＦは、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンから送られてきたアドレスが、そのアドレス空間外の時にデータサイクルで、バスエラーｓｙｓ＿ｉｐｕ＿ｂｅｒｒ＝１を返す。
以上、本発明を実施例により詳細に説明したが、当業者にとっては、本発明が本願中に説明した実施例に限定されるものではないということは明らかである。本発明の装置は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本願の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
例えば、上記実施例では、マスターコントローラＭＣおよび各ＲＩＳＣエンジンやＤＳＰエンジンとには、非対称のマルチプロセッサシステムとなっている。しかし、各ＲＩＳＣエンジンやＤＳＰエンジンのみからなる対称型のマルチプロセッサの実装も、当業者であれば、上記の開示から本発明の実施例として実装可能であることは明らかである。
また、上記実施例では、ＲＩＳＣエンジンやＤＳＰエンジンのみの組み合わせであるが、それ以外のエンジン、例えばＳプログラム用メモリ、Ｄ型のエンジン、グラフィックスエンジン、Ｖｅｃｔｏｒ型のエンジン、あるいはカスタムエンジンとして特定のハードウエアブロックをエンジンとして組み込むこともできる。
更に、上記実施例では、プロセッサエンジンの数は４個であるが、同様の方法により、エンジンの数を８個まで、１６個まで、３２個まで、というように増やすことは、当業者にとって容易に可能である。
更に、上記実施例では、内部メモリを命令メモリとデータメモリの２つとしているが、同様の方法により、さらに数多くのメモリを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、外部バスコントローラは１つであるが、同様の方法により、複数の外部バスコントローラを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、内部ペリフェラルユニットにタイマおよびＩ／Ｏを付けているが、同様の方法により、様々な周辺デバイスを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、マスターコントローラ、ＲＩＳＣエンジン、ＤＳＰエンジンのアーキテクチャ例を示しているが、他のアーキテクチャのプロセッサに同様のバスアーキテクチャを組み合わせることは、当業者にとって容易に可能である。
産業上の利用可能性
以上説明したように、本発明の実施形態によるスプリットトランザクションの為のアービトレーションシステムによれば、スプリットトランザクション時に、アクセスを開始したプロセッサが外部メモリからのデータを待つ時間を短縮することができ、全体の処理速度を向上させることができる。
【図面の簡単な説明】
図１は、本発明の実施形態による分散バス・アービトレーション方式における、適応型ラウンドロビンによる２段のアービトレーションを示す説明図である。
図２は、本発明の実施形態による分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムのブロックダイアグラムである。
図３は、本発明の実施形態による分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムの制御信号の接続関係を示すブロック図である。
図４は、本発明の実施形態による分散バス・アービトレーション方式における、内部バスを使用して、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンによる、各リソースからのリードサイクルを示す図である。
図５は、本発明の実施形態による分散バス・アービトレーション方式における、内部バスを使用して、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンによる、各リソースからのリードサイクルを示す図であり、アドレスを送出する際に、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンは、転送データ数ｎを各リソースに通知する図。
図６は、本発明の実施形態による分散バス・アービトレーション方式において、制御信号のｉ＿ｐｒｉｏｒｉｔｙ（１：０）によって示される優先順位を説明する図である。
図７は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスＩＢＵＳ及び内部システムバスＳＢＵＳによるプログラム用メモリのアクセス状況によって、マスターコントローラＭＣが生成するｉ＿ｂｕｓｙ（０）信号の生成アルゴリズムを示す表である。
図８は、本発明の実施形態による分散バス・アービトレーション方式における、ＲＩＳＣエンジンＲＥ０が出力するｉ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。
図９は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスＩＢＵＳのアービトレーションの規則を説明する図である。
図１０は、本発明の実施形態による分散バス・アービトレーション方式における、プログラム用メモリに対するコマンドｉ＿ｃｍｄの意味を説明する図である。
図１１は、本発明の実施形態による分散バス・アービトレーション方式における、ｄ＿ｐｒｉｏｒｉｔｙ（１：０）によって示される優先順位を説明する図である。
図１２は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスＩＢＵＳ及び内部システムバスＳＢＵＳによるプログラム用メモリのアクセス状況によって、マスターコントローラＭＣが生成するｄ＿ｂｕｓｙ（０）信号の生成アルゴリズムを示す表である。
図１３は、本発明の実施形態による分散バス・アービトレーション方式における、ＲＩＳＣエンジンＲＥ０が出力するｄ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。
図１４は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスＩＢＵＳのアービトレーションの規則を説明する図である。
図１５は、本発明の実施形態による分散バス・アービトレーション方式における、コマンドｄ＿ｃｍｄの意味を説明する図である。プログラム用メモリへの書き込みは内部システムバスＳＢＵＳを介して行われる。
図１６は、本発明の実施形態による分散バス・アービトレーション方式における、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）によって示される優先順位を説明する図である。
図１７は、本発明の実施形態による分散バス・アービトレーション方式における、バスコントローラＢＣが出力するｓｙｓ＿ｒｅｑｕｅｓｔ＿ｓｌ（０）の意味を説明する図である。
図１８は、本発明の実施形態による分散バス・アービトレーション方式における、ｓｙｓ＿ｐｒｉｏｒｉｔｙ＿ｓｌ（２：０）によって示される優先順位を説明する図である。
図１９は、本発明の実施形態による分散バス・アービトレーション方式における、内部システムバスＳＢＵＳのアービトレーションの規則を説明する図である。
図２０は、本発明の実施形態による分散バス・アービトレーション方式における、ＲＩＳＣエンジンＲＥ０が出力するｓｙｓ＿ｒｅｑｕｅｓｔ（０）の意味を説明する図である。
図２１は、本発明の実施形態による分散バス・アービトレーション方式における、ｓｙｓ＿ｐｒｉｏｒｉｔｙ（２：０）によって示される優先順位を説明する図である。
図２２は、本発明の実施形態による分散バス・アービトレーション方式における、マスターコントローラＭＣ、ＲＩＳＣエンジンやＤＳＰエンジンが出力するコマンドの一覧である。

Claims (4)

1. 共用バスと、前記共用バスへのアクセスを行う複数のバス・マスタ・デバイスおよびバス・スレーブ・デバイスと、前記バス・マスタ・デバイスおよびバス・スレーブ・デバイスの夫々に個別に設けられ、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行うアービトレーション手段とからなり、前記複数のデバイスは、アービトレーションに関して、前記バス・マスタ・デバイスで構成される第１のグループと、前記バス・スレーブ・デバイスで構成される第２のグループに分かれており、前記バス・マスタ・デバイスとバス・スレーブ・デバイスとが、いずれもスプリットトランザクションを採用しており、データのやり取りをスプリットトランザクションを用いて行ない、前記バス・スレーブ・デバイスの夫々は、そのビジー状態を示す信号を前記バス・マスタ・デバイスの夫々へ出力し、前記バス・マスタ・デバイスは、前記バス・スレーブ・デバイスの１つにアクセスしたい場合、当該バス・スレーブ・デバイスがビジーでないタイミングでバス使用要求を発行し、前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによって、バス使用要求が発行され、前記第２のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、前記第１のグループに属するデバイスのいずれかが、前記第１のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第２のグループに属するデバイスからバス使用要求が発行されている場合、前記第１のグループに属するデバイスのバス使用要求は常に許可されず、前記第２のグループに属するデバイスの間で行われるラウンドロビンによって前記第２のグループに属するデバイスのいずれかにバス使用が許可され、バス使用が許可された前記第１のグループに属するデバイスは、バス連続使用を示す信号を出力することにより、連続してバスを使用することができることを特徴とする情報処理システム。
2. 前記複数のバス・マスタ・デバイスは、複数のプロセッサであり、前記複数のバス・スレーブ・デバイスは、外部メモリへのアクセスを行うコントローラ、内部メモリ、及びペリフェラルバスＩＦを含むことを特徴とする請求項１に記載の情報処理システム。
3. 前記複数のバス・マスタ・デバイス、前記バス・スレーブ・デバイス及び前記共用バスは、シングルチップに集積されていることを特徴とする請求項２に記載の情報処理システム。
4. 共用バスと、前記共用バスのバス・マスタとしての複数のプロセッサと、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスとからなり、前記複数のプロセッサとバス・スレーブ・デバイスとが、いずれもスプリットトランザクションを採用しており、データのやり取りをスプリットトランザクションを用いて行ない、前記バス・スレーブ・デバイスの夫々は、そのビジー状態を示す信号を前記複数のプロセッサの夫々へ出力し、前記複数のプロセッサは、前記バス・スレーブ・デバイスの１つにアクセスしたい場合、当該バス・スレーブ・デバイスがビジーでないタイミングでバス使用要求を発行し、前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行され、前記バス・スレーブ・デバイスのいずれからもバス使用要求が発行されていない場合、前記複数のプロセッサのバス使用要求のいずれかが、前記複数のプロセッサの間で行われるラウンドロビンによって許可され、前記バス・スレーブ・デバイスからバス使用要求が発行されている場合、前記複数のプロセッサのバス使用要求は常に許可されず、前記複数のバス・スレーブ・デバイスの間で行われるラウンドロビンによって前記バス・スレーブ・デバイスのいずれかにバス使用が許可され、前記バス使用要求のアービトレーションを行う装置が、前記複数のプロセッサおよびバス・スレーブ・デバイスの夫々に個別に設けられ、バス使用が許可された前記複数のプロセッサは、バス連続使用を示す信号を出力することにより、連続してバスを使用することができることを特徴とするマルチプロセッサ・システム。

Images