JPWO2002101565A1 - 情報処理システム、マルチプロセッサ・システム及びバス・アービトレーション装置 - Google Patents
情報処理システム、マルチプロセッサ・システム及びバス・アービトレーション装置 Download PDFInfo
- Publication number
- JPWO2002101565A1 JPWO2002101565A1 JP2003504257A JP2003504257A JPWO2002101565A1 JP WO2002101565 A1 JPWO2002101565 A1 JP WO2002101565A1 JP 2003504257 A JP2003504257 A JP 2003504257A JP 2003504257 A JP2003504257 A JP 2003504257A JP WO2002101565 A1 JPWO2002101565 A1 JP WO2002101565A1
- Authority
- JP
- Japan
- Prior art keywords
- bus
- request
- devices
- group
- engine
- 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.)
- Granted
Links
Images
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/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bus Control (AREA)
- Multi Processors (AREA)
Abstract
Description
本発明は、一般にマルチプロセッサ・コンピュータ・システムの分野に関し、より具体的には共通のアドレス・バスまたはデータ・バスの制御を必要とする複数の装置間でバス・アービトレーションを実行するための装置に関する。
背景技術
近年、大量の計算能力を必要とするアプリケーションでは、ますますマルチプロセッサ・コンピューティング・システムが使用されるようになっている。多くのタイプのマルチプロセッサ・システムが存在するが、一般に、このようなシステムは、プロセッサ間の資源の共用を容易にするために共通バス上にまとめて結合された複数のプロセッサが独立して動作している。バスはすべてのプロセッサに共通し、各プロセッサは独立して動作しているので、複数のプロセッサが同時に、すなわち、同一クロック・サイクルでそのバスにアクセスしようと試みる。複数のプロセッサがバスの制御権を獲得しようとした場合、バスからのデータ衝突が発生する恐れがある。
したがって、マルチプロセッサ・コンピュータ・システムがバスに対する同時要求のアービトレーションを効果的に行うことは重要なことである。通常、これは、要求側プロセッサの1つに優先順位を割り当て、それがアクセスを実行できるようにすることによって行われる。バスの制御権を獲得しようと試みる装置または実際にバスを制御する装置は「バス・マスタ」と呼ばれる。バス・マスタがバスにアクセスした後、その優先順位は、バスへのアクセスを必要とする他のプロセッサに渡される。
バスに結合された様々なプロセッサ間に優先順位を割り当てる方法は多数存在する。しかし、アービトレーション方式によってバスにアクセスする機会がすべてのプロセッサに、効率的に与えられることは重要なことである。そうではない場合、1つのプロセッサによって繰返しアクセスすると、他のプロセッサはバスの制御権を取得することができず、それにより、他のプロセッサのデータ・ストリームに許されないバス待ち時間が発生する可能性がある。
また、マルチドメイン、分散アービトレーションシステム、およびマルチプロセッサシステムバスのリクエストのアービトレーション制御を複数のアービターによって処理することで、アービトレーションの処理を高速化する方法が、米国特許5,509,125号に記載されている。ここでは、リクエストは、マルチプロセッサバスに結合された複数のノードで生成される。リクエストは、複数のアービトレーション要求ライン上に示される。各ノードは、対応するノードに関連付けられた1つのアービターを持っている。優先順位は、他のドメインに対する関係として各ドメインにアサインされる。各アービターは、アービトレーションリクエストライン上のリクエストをモニターし、そのノードからのリクエストが待ち状態だった場合に、そのノードが結果としてアービトレーションの結果選択されるか否かの結果を示す信号を生成する。更に、アービターは、アサインされた優先順位に従ってアービトレーションの結果どのノードが選択されたか、結果を示す信号を生成する。
また、従来型のバスは、アドレス・フェーズにデータ・フェーズが(ウェイト・ステートを除いて)常に直ぐに続くバスとして定義される「接続トランザクション・バス」である。換言すれば、アドレス・フェーズ及びデータ・フェーズはデータ・フェーズ中に転送されるデータが常にデータ・フェーズの直前でバス上に配置されたアドレスに関連されるように接続される。アービトレーション・フェーズをアドレス・フェーズ及びデータ・フェーズに重複するのは良いが、アドレス・フェーズ及びデータ・フェーズを重複させることやデータ・フェーズをアドレス・フェーズに対して無関係に発生させることはできない。
これに対して、「スプリットトランザクション・バス」として知られているバスは、データ転送に対して4つのフェーズ、即ち、(1)アドレス・アービトレーション・フェーズ、(2)アドレス/コマンド・フェーズ(3)データ・アービトレーション・フェーズ、及び(4)データ転送フェーズを有する。
スプリットトランザクション・バスでは、データ・フェーズがバス上に配置された関連のアドレス・フェーズに直ぐに続く必要はない。データ・フェーズは、対応するアドレス・フェーズが発生するのと同一順序で発生する必要はない。従って、同じバスのバス・マスタは、何らかのデータが戻される前に、多重アドレス・フェーズを実行することができる。更に、第2のバス・マスタのアドレス・フェーズを第1のバス・マスタのデータ・フェーズに重複させることもできる。スプリットトランザクション・バスにおけるアドレス・アービトレーションは、接続トランザクション・バスのものと同様である。しかし、一つの相違は、アドレス・フェーズにおいて、バス・マスタがアドレス/コマンド信号及びトランザクション識別(ID)をアサートし、次いでアドレス・バスを直ちに開放する。その際に、バス・マスタは、スレーブがデータを戻すまで待機してもよく、又はアドレス・バスに対して再アービトレーションを行い、かつ付加的なアドレス・フェーズを実行してもよい。スレーブは、アドレス・フェーズにおいて発行されたアドレス/コマンド及びバス・マスタ識別情報を記憶し、次いで転送を完了するためにレディになっているときは、データ・バスに対してアービトレーションを行う。スレーブがデータ・バスについてバスの使用権を得たときは、データ・バス上にプロセッサを識別するトランザクションIDを送出すると同時に、データ・バス上にデータを送出する。次いで、バス・マスタはそのトランザクションIDを認識して、前記データを受け入れることによって、トランザクションを完了する。
スプリットトランザクション・バスは、バスの利用効率を高めるという点で、非常に優れた手法であるが、その改良という点では、あまり効果的な提案はなされていない。トランザクションを同時発行数を増やせば、ある程度のスプリットトランザクション・バスの効果的な利用を可能とするものの、ハードウエアに対する負担が増加してしまう。
従って、スプリットトランザクション・バスの潜在的な可能性を、更に引き出すことが可能となれば、バスの実効的な帯域を更に広げることができる。
発明の開示
本発明の主な目的は、マルチプロセッサバスの均等な優先順位とスプリットトランザクションの効率の良い複合アービトレーションためのシステムを提供することである。
本件発明者は、スプリットトランザクション・バスの、利用形態を調査し、その最も効果的な利用方法を探るべき目的で研究を行った。その結果、従来のスプリットトランザクション・バスでは、優先順位が、全てのバス・マスタ・デバイス及びバス・スレーブ・デバイスに対して均等に割当てられているという点が再考に値することが明らかになった。そして、スプリット・トランザクションによりバスの実効的な使用効率を向上させた場合、通常外部ポートを通してアクセスタイムの長い外部デバイスにアクセスしたリードデータを転送するためにバスコントローラは、優先順位を待つ必要が生じるという点が、スプリットトランザクションの効果を下げているということを発見した。
図1は、本発明の実施形態による2段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムを説明する図である。ここで、共用バスへのアクセスを行う複数のデバイスは、少なくとも2つのグループに分かれており、第2のグループに属するデバイス(典型的にはリソース)のいずれからもバス使用要求が発行されていない場合にのみ、第1のグループに属するデバイス(典型的にはプロセッサ)のいずれかが、1次のラウンドロビンによってバスの使用が許可される。しかし、第2のグループに属するデバイスからバス使用要求が発行されている場合、第1のグループに属するデバイスのバス使用要求は常に許可されない。この場合、2次のラウンドロビンによって第2のグループに属するデバイスのいずれかにバス使用が許可される。
従って、本発明(請求項1)は,共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行うアービターとからなり、前記複数のデバイスは、少なくとも2つのグループに分かれており、第2のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第1のグループに属するデバイスのいずれかが、前記第1のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第2のグループに属するデバイスからバス使用要求が発行されている場合、前記第1のグループに属するデバイスのバス使用要求は常に許可されず、前記第2のグループに属するデバイスの間で行われるラウンドロビンによって前記第2のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とする情報処理システムを提供する。
本発明(請求項2)は,上記請求項1において,前記複数のデバイスの前記第1のグループは、前記共用バスのバス・マスタとしての複数のプロセッサであり、前記複数のデバイスの前記第2のグループは、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスであることを特徴とする情報処理システムを提供する。
本発明(請求項3)は,上記請求項2において,前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行されることを特徴とする情報処理システムを提供する。
本発明(請求項4)は,上記請求項2において,バス使用の優先順位を決定するアービトレーション装置が、前記複数のプロセッサの各々に設けられていることを特徴とする情報処理システムを提供する。
本発明(請求項5)は,上記請求項2において,バス使用の優先順位を決定するアービトレーション装置が、前記複数のバス・スレーブ・デバイスの各々に設けられていることを特徴とする情報処理システムを提供する。
本発明(請求項6)は,上記請求項2において,前記バス・スレーブ・デバイスは、外部メモリへのアクセスを行うコントローラ及びペリフェラルバスIFを含むことを特徴とする情報処理システムを提供する。
本発明(請求項7)は,上記請求項2において,前記複数のプロセッサ、前記バス・スレーブ・デバイス及び前記共用バスは、シングルチップに集積されていることを特徴とする情報処理システムを提供する。
本発明(請求項8)は,共用バスと、前記共用バスのバス・マスタとしての複数のプロセッサと、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスとからなり、前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行され、前記バス・スレーブ・デバイスのいずれからもバス使用要求が発行されていない場合、前記複数のプロセッサのバス使用要求のいずれかが、前記複数のプロセッサの間で行われるラウンドロビンによって許可され、前記バス・スレーブ・デバイスからバス使用要求が発行されている場合、前記複数のプロセッサのバス使用要求は常に許可されず、前記複数のバス・スレーブ・デバイスの間で行われるラウンドロビンによって前記バス・スレーブ・デバイスのいずれかにバス使用が許可されることを特徴とするマルチプロセッサ・システムを提供する。
本発明(請求項9)は,共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行う装置であって、前記複数のデバイスは、少なくとも2つのグループに分かれており、第2のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第1のグループに属するデバイスのいずれかが、前記第1のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第2のグループに属するデバイスからバス使用要求が発行されている場合、前記第1のグループに属するデバイスのバス使用要求は常に許可されず、前記第2のグループに属するデバイスの間で行われるラウンドロビンによって前記第2のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とするバス・アービトレーション装置を提供する。
発明を実施するための最良の形態
図2は、本発明の実施形態による内部バスの高性能分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムのブロックダイアグラムである。このマルチプロセッサシステムには、マスターコントローラMCと、RISCエンジンRE0,RISCエンジンRE1と、DSPエンジンDE0及びDSPエンジンDE1の5つのプロセッサが備えられている。ここで、マスターコントローラMCは、全体の制御を行っており、非対称のマルチプロセッサシステムとなっている。
RISCエンジンRE0及びRISCエンジンRE1は、一般にはそれぞれ対等の立場で設けられている汎用のRISCプロセッサであるが、同一のプロセッサエンジンでも良いし、異なるプロセッサエンジンを用いても良い。また、既存プロセッサエンジンを利用することも、新たにプロセッサエンジンを設計してもよい。しかし、それらのプロセッサエンジンには、以下に詳細に説明する本発明の実施形態による分散バス・アービトレーションを、それぞれに実装する必要がある。
DSPエンジンDE0及びDSPエンジンDE1は、特定の処理内容を持つ数値演算プロセッサであり、転送レートの高いデータの流れをリアルタイムで処理することが可能である。ここでも、DSPエンジンDE0及びDSPエンジンDE1は、同一の既存プロセッサエンジンでも良いし、異なる既存プロセッサエンジンを用いても実装できる。また、既存プロセッサエンジンを利用することも、新たにプロセッサエンジンを設計してもよい。しかし、それらのプロセッサエンジンには、やはり、以下に詳細に説明する本発明の実施形態による分散バス・アービトレーションを、それぞれに実装する必要がある。
RISCエンジンRE0及びRISCエンジンRE1とDSPエンジンDE0及びDSPエンジンDE1は、内部命令バスIBUS及び内部システムバスSBUSを介してプログラム用メモリIMに接続されている。同様に、これらは、内部データバスDBUS及び内部システムバスSBUSを介してデータ用メモリDMに接続されている。これらRISCエンジンとDSPエンジンは、内部命令バスIBUSと、内部データバスDBUS及び内部システムバスSBUSのバス・マスタ・デバイスである。また、プログラム用メモリIM及びデータ用メモリDMは内部命令バスIBUSと、内部データバスDBUSのバス・スレーブ・デバイスである。
また、マスターコントローラMCは、内部システムバスSBUSを介してプログラム用メモリIMに接続され、内部データバスDBUSを介してデータ用メモリDMに接続されている。マスターコントローラMCは、内部システムバスSBUSのバス・マスタである。
これら内部命令バスIBUS、内部データバスDBUS及び内部システムバスSBUSは、それぞれ128ビットのバス幅をもち、それぞれに32ビットのアドレスバスが備えられている。この128ビットのバス幅を、200MHzで駆動すれば、最大3.2Gバイトのバンド幅でデータの転送を行うことができる。もちろん、これらの数値は例示的なもので、更に拡張又は縮小することは、応用によって決定される。
また、128ビットのバス幅をもち、それぞれに32ビットのアドレスバスに加えて、これら内部命令バスIBUS、内部データバスDBUS及び内部システムバスSBUSには、以下の説明で詳しく述べる次の様な信号線が設けられている。即ち、内部命令バスIBUSには、i_priority(1:0)、i_busy(1:0)、i_request(3:0)、i_request_sl、i_cmd、i_berrの各信号線が設けられている。また、内部データバスDBUSには、d_priority(1:0)、d_busy(3:0)、d_request(3:0)、d_request_sl、d_cmd(3:0)、d_ready、d_berrの各信号線が設けられている。また、内部システムバスSBUSには、sys_priority(2:0)、sys_busy(8:0)、sys_request(4:0)、sys_request_sl(3:0)、sys_address(31:0)、sys_cmd(10:0)、sys_biu_berr、sys_ipu_berr、sys_dm_berrの各信号線が設けられている。図3は、これらの接続関係を示すブロック図である。ただし、図ではエラー関係の信号(x_berr)は省略している。
また、本実施形態によるシングルチップ・マルチプロセッサシステムでは、外部のメモリへのアクセス用に、2系統のアドレス/データバスが設けられている。1つは、外部システムバスEM1であり、22ビットのアドレスバスと、16ビットのデータバスを持っている。そして、最大8MバイトのROM/フラッシュROM、最大16MバイトのROM/フラッシュROM、及び最大24Mバイトの外部リソースを、この外部システムバスEM1に接続することができる。
もう1つは、外部システムバスEM2であり、20ビットのアドレスバスと、16ビット又は32ビットのデータバスを持っている。そして、最大8MバイトのROM/フラッシュROM、最大32MバイトのSRAM/SDRAM、及び最大2Mバイトの外部リソース(ペリフェラル)を、この外部システムバスEM1に接続することができる。
このマルチプロセッサシステムと、外部のメモリとのアクセスは、内蔵されているバスコントローラBCが行う。このバスコントローラBCは、内部システムバスSBUSを介して、RISCエンジンRE0及びRISCエンジンRE1とDSPエンジンDE0及びDSPエンジンDE1と、更に、マスターコントローラMCと、スプリットトランザクションを行う。それとは別に、バスコントローラBCは、マスターコントローラMCと、専用の命令バスMIとデータバスMDによって接続されており、マスターコントローラMCへの命令とデータの供給を行う。また、バスコントローラBCとマスターコントローラMCとの間には、命令キャッシュが介在しており、通常の方法によって、キャッシングを行う。
更に、内蔵の周辺回路として、タイマ回路とI/Oポートが、ペリフェラルバス及びペリフェラルバスIF(インターフェース回路)を介して、内部システムバスSBUSに接続されている。このタイマ回路は、6本のタイマを実装しており、タイマバスを介して、RISCエンジンRE0、RISCエンジンRE1、DSPエンジンDE0、DSPエンジンDE1、マスターコントローラMCへ、タイマ割り込みを行う。また、ペリフェラルバスを介して、プロセッサ割り込み制御回路へタイマ割り込みを行う。プロセッサ割り込み制御回路は、プロセッサ割り込み要求バスを介して、各プロセッサエンジンのプロセッサ割り込みを行う。バスコントローラBC、ペリフェラルバスIF、プログラム用メモリIM及びデータ用メモリDMは内部システムバスSBUSのバス・スレーブ・デバイス(リソース)である。
以上の、構成要素、RISCエンジンRE0、RISCエンジンRE1、DSPエンジンDE0、DSPエンジンDE1、マスターコントローラMC、バスコントローラBC、命令キャッシュ、タイマ回路、プロセッサ割プロセッサ割り込み制御回路、ペリフェラルバスIF、I/Oポートは、1チップの集積回路として実装される。
その他の外部制御信号や、付随する制御回路は、従来のシングルチップ・マルチプロセッサシステムと、基本的に同じなので、詳細な説明を省略する。
以下、本発明の特徴である内部バスの高性能分散バス・アービトレーション方式について、詳細に説明する。前述の5つのプロセッサエンジンには、内部命令バスIBUS、データバスそして、内部システムバスSBUSのそれぞれのバスにアクセスする為のバスアービターを内蔵している。同様に、バスコントローラBC、ペリフェラルバスIF、プログラム用メモリIM及びデータ用メモリDMも、内部システムバスSBUSにアクセスする為のバスアービターを内蔵している。
アービトレーションの方法は、信号の往復を最小限にすることによって短時間で優先順位を決定することができる分散型のアービトレーション方式を採用する。即ち、それぞれのプロセッサエンジンは、バスアービターを内蔵しており、以下に説明するアービトレーションに関係する制御信号は全てこのバスアービターに入力されている。そして、バスアービターは、他のプロセッサやリソースからのリクエストと自分自身のリクエスト、バスのビジー状態、及び優先順位を参照することによってサイクル毎にバスの使用権を獲得できるかどうか判定する。この結果、バスの使用権を獲得したプロセッサが次のサイクルでコマンド及びアドレスを送出しバスを使用することができる。優先順位は、バスの使用権に基づいてラウンドロビン方式で行われる。
この実施形態では、プログラム用メモリIM及びデータ用メモリDMは、内部命令バスIBUS、内部データバスDBUS及び内部システムバスSBUSの駆動クロック周波数に比較して応答速度が低く、リードサイクルでアドレスやコマンドを受けてから、データを返すまで数クロックを要する。また、バスコントローラBCやペリフェラルバスIFも、外部バスやペリフェラルバスを介して周辺回路へアクセスするので、更に応答速度が遅い。従って、これらバス・スレーブ・デバイスは、リードサイクルでスプリットトランザクションを行う。
即ち、マスターコントローラMC、RISCエンジンやDSPエンジンのバス・マスタ・デバイスと、プログラム用メモリIM、データ用メモリDM、バスコントローラBCやペリフェラルバスIFのバス・スレーブ・デバイス(リソース)は、スプリットトランザクションを行う。すなわち、(1)アドレス・アービトレーション・フェーズ、(2)アドレス/コマンド・フェーズ、(3)データ・アービトレーション・フェーズ、及び(4)データ転送フェーズを有する。ただし、(1)アドレス・アービトレーション・フェーズ及び(2)アドレス/コマンド・フェーズと、(3)データ・アービトレーション・フェーズ及び(4)データ転送フェーズとは、分割されている。
<バス使用権の獲得方法>
本発明の実施形態では、2段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。即ち、プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFの各リソースは、バスの使用権について、マスターコントローラMC、RISCエンジンやDSPエンジンの各プロセッサよりも常に高い優先権が与えられる。そして、プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIF間の優先権は、適応型ラウンドロビンによって移動する。同様に、マスターコントローラMC、RISCエンジンやDSPエンジンの各プロセッサ間の各リソースの優先権も、適応型ラウンドロビンによって移動する。
ここで、図1に示した様な、本発明の実施形態による2段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。1次側の適応型ラウンドロビンは、RISCエンジンRE0,RISCエンジンRE1と、DSPエンジンDE0及びDSPエンジンDE1の5つのプロセッサからなる。また、2次側のラウンドロビンは、バス・スレーブとなるプログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFの各リソースからなっている。
1次側の適応型ラウンドロビンでは、各プロセッサは、バスを使用するためにアービトレーションサイクルでリクエストを発行する。各プロセッサからのリクエストは全てのプロセッサによって参照される。即ち、各プロセッサ内のバスアービターは、全てのプロセッサからのリクエストを参照する。バス使用権の優先順位は、ラウンドロビン方式で各プロセッサに対し公平に与えられる。そのアービトレーションアルゴリズムは以下の通り。
▲1▼ 2次側のラウンドロビンのアービトレーションからリクエストが発行されていれば、そのリソース(2次側でバスのアクセス権を獲得したリソース)が、バスの使用権を得る。
▲2▼ 2次側のラウンドロビンのアービトレーションからリクエストが無く、現在優先権を持つプロセッサがリクエストを発行していれば、そのプロセッサがバスの使用権を得る。
▲3▼ 2次側のラウンドロビンのアービトレーションからリクエストが無く、現在優先権を持つプロセッサがリクエストを発行していなければ、優先権の与えられる順序に従ってリクエストを発行しているプロセッサがバスの使用権を得る。
▲4▼ 2次側のラウンドロビンのアービトレーションからリクエストが無く、1次側の何れのプロセッサからもリクエストが全く無い場合、あるいはリクエスト先がビジーでリクエストが受け付けられない場合、優先権は移動しない。
▲5▼ 次のサイクルの優先権は、バスの使用権を獲得した次のプロセッサに移動する。
また、1次側の適応型ラウンドロビンによるアービトレーションの結果、2次側のリソースに対するアクセスが行われるが、アクセスがスプリット・トランザクションの場合、即ちリードアクセスの場合にのみ2次側のラウンドロビンが使用される。ライトアクセスの場合、リソース側のバッファに取り込まれるので、プロセッサから見れば、ノーウエイトで処理が完了するので、スプリット・トランザクションをする必要はない。
各リソースは、リードデータの準備が出来ると、バスを使用するためにアービトレーションサイクルでリクエストを発行する。各リソースからのリクエストは全てのリソースによって参照される。即ち、各リソース内のバスアービターは、全てのリソースからのリクエストを参照する。バス使用権の優先順位は、ラウンドロビン方式で各リソースに対し公平に与えられる。そのアービトレーションアルゴリズムは以下の通り。
▲1▼ 現在優先権を持つリソースがリクエストを発行していれば、そのリソースがバスの使用権を得る。
▲2▼ 現在優先権を持つリソースがリクエストを発行していなければ、優先権の与えられる順序に従ってリクエストを発行しているリソースがバスの使用権を得る。
▲3▼ 何れのリソースからもリクエストが全く無い場合、優先権は移動しない。
▲4▼ 次のサイクルの優先権は、バスの使用権を獲得した次のリソースに移動する。
すなわち、プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFの各リソースからなるグループと、マスターコントローラMC、RISCエンジンやDSPエンジンの各プロセッサからなるグループとの間では、固定優先の分散型アービトレーションを行い、グループの内部では、適応型ラウンドロビンに基づいて、分散型アービトレーションを行う。即ち、マルチプロセッサバスの均等な優先順位の移動と、固定的に優先権の与えられたスプリットトランザクションによる、効率の良い複合アービトレーションが実現する。
このような複合アービトレーションによれば、スプリット・トランザクションによりバスの実効的な使用効率を向上させる上で、明瞭なアドバンテージをもたらす。本件発明者が調査したところ、一般的なプログラムの実行において、各リソースに常に最高の優先権を与えたことによる処理が遅れる具体例は発見できなかった。そして、統計的に、バスの使用効率の向上と全体の処理速度の向上が期待できることが分かった。
これは、次の様な事情による。すなわち、各リソースがリクエストを発行している場合、各リソースがバスにデータを出力すると、それを要求したプロセッサは、直ちにそのデータの処理を行うことができ、確実に1サイクル分処理が速まる。一方、各リソースにバスの使用権を譲ったプロセッサは、1サイクル分処理が遅れる場合と、実質的な処理の遅れはない場合がある。
それに対して各リソースがリクエストを発行している場合で、もし他のプロセッサにバスの使用権を与えた場合には、プロセッサはバスの使用後、次のデータがくるまで、そこで処理が止まってしまうということがあり得る。一方、各リソースも確実に1サイクル分処理が遅れ、そのデータを待っているプロセッサもやはり1サイクル分処理が遅れる。
<バスサイクルとバスの動作モード>
図4は、内部バスを使用して、マスターコントローラMC、RISCエンジンやDSPエンジンによる、各リソースからのリードサイクルを示す図である。まず、マスターコントローラMC、RISCエンジンやDSPエンジンは、アービトレーションの後、各リソースに対して、コマンドと共にアドレスを送出する。各リソースがデータの準備ができると、アービトレーション(リクエスト)によって内部システムバスSBUSの使用権を獲得し、コマンドを発行し、該当するRISCエンジンやDSPエンジンは、そのデータを取り込む。
図5は、内部バスを使用して、マスターコントローラMC、RISCエンジンやDSPエンジンによる、各リソースからのリードサイクルを示す図であるが、アドレスを送出する際に、マスターコントローラMC、RISCエンジンやDSPエンジンは、転送データ数nを各リソースに通知する。各リソースがデータの準備ができて連続転送する場合、リクエストを発行し続けておき、外部バスからのレディに応じて内部バスにデータを転送することができる。
<内部命令バスIBUSへのアクセス>
以下、内部命令バスIBUSへのアクセス制御の詳細を説明する。RISCエンジンやDSPエンジンが共用するプログラム用メモリをアクセスする時に、内部命令バスIBUSの使用権を得る場合には、ある時点での内部命令バスIBUS使用の優先順位を示すための2ビットの信号i_priority(1:0)を用いる。図6は、i_priority(1:0)によって示される優先順位を説明する図である。ここに示した通り、i_priority(1:0)が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
各RISCエンジンやDSPエンジンは、プログラム用メモリIMが内部命令バスIBUSの使用リクエストi_request_slを発行していない場合で且つ、i_busy(1:0)信号をみて”使用可能”の状態の時に、内部命令バスIBUSの使用リクエストを発行し、優先順位に従って内部命令バスIBUSの使用権を獲得する。i_busy(0)信号は、マスターコントローラMCによって出力される。図7は、内部命令バスIBUS及び内部システムバスSBUSによるプログラム用メモリのアクセス状況によって、マスターコントローラMCが生成するi_busy(0)信号の生成アルゴリズムを示す表である。ここで、(1st)又は(2nd)は、リクエストが重なった場合の順番を示す。例えば、リードリクエストが重なった場合に、最初に処理されるリードリクエストがRead(1st)であり、次に処理されるリードリクエストがRead(2nd)である。Write Lastは、連続書き込みの最後のライトサイクルを意味する。また、i_busy(1)信号は、バス権を獲得したRISCエンジンやDSPエンジンがコマンドを送出する時、内部命令バスIBUSを続けて使用する場合に1、内部命令バスIBUSを1サイクルだけ使用する場合には0とする。
また、プログラム用メモリは、リードリクエストに対してデータレディ信号としてバス使用要求信号i_request_slを出力する。このバス使用要求信号i_request_slは、アドレス送出(コマンド)に対するデータが準備完了であることを示す。プロセッサは、リードに対するデータをプログラム用メモリからのデータレディ信号としてのバス使用要求信号i_request_slを見て受け取る。
RISCエンジンやDSPエンジンからのバス使用リクエストは、i_request(3:0)の内の各1ビットの信号を各RISCエンジンやDSPエンジンが出力する。すなわちRISCエンジンRE0はi_request(0)、RISCエンジンRE1はi_request(1)、DSPエンジンDE0はi_request(2)、DSPエンジンDE1はi_request(3)をドライブする。図8は、RISCエンジンRE0が出力するi_request(0)の意味を説明する図である。ダブル・フェッチサイクルは、分岐のターゲットアドレスの下位4ビットが8h以上、即ち1回のフェッチサイクルで、一命令を2バイトとして、4命令以下の命令コードしかフェッチできないような場合に用いられる。
バスの使用権は、i_busy(1:0)=”00”のときにアービトレーションで決定される。図9は、内部命令バスIBUSのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのi_priority(1:0)は、バス使用権を獲得したRISCエンジンやDSPエンジンの次のRISCエンジンやDSPエンジン(順序は、RE0→RE1→DE0→DE1→RE0)を指す。
RISCエンジンやDSPエンジンは、アービトレーション・サイクルでバス使用権獲得後、次のサイクル(アドレス送出サイクル)でアドレスとともにプログラム用メモリに対するコマンドi_cmdを出力する。図10は、コマンドi_cmdの意味を説明する図である。プログラム用メモリへの書き込みは内部システムバスSBUSを介して行われる。
プログラム用メモリ側で、要求されたデータの準備が完了すると、バス使用要求信号i_request_slを発行する。バス使用要求信号i_request_slは、他のバス使用要求信号に優先するので、直ちにデータの転送が行われる。
尚、プログラム用メモリは、プロセッサから送られてきたアドレスが、プログラム用メモリの実装されているアドレス空間外のときデータサイクルで、バスエラーi_berr=1が返される。このとき、プログラム用メモリの出力i_data(127:0)の内容は無効である。
<内部データバスDBUSへのアクセス>
以下、内部データバスDBUSへのアクセスの詳細を説明する。RISCエンジンやDSPエンジンが共用するデータ用メモリDMへのアクセスする時に、内部データバスDBUSの使用権を得る必要がある。この場合、ある時点での内部データバスDBUS使用の優先順位を示すための2ビットの信号d_priority(1:0)を用いる。図11は、d_priority(1:0)によって示される優先順位を説明する図である。ここに示した通り、i_priority(1:0)が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
各RISCエンジンやDSPエンジンは、データ用メモリDMが内部データバスDBUSの使用リクエストd_request_slを発行していない場合で且つ、d_busy(3:0)信号をみて”使用可能”の状態の時に、内部データバスDBUSの使用リクエストを発行し、優先順位に従って内部命令バスIBUSの使用権を獲得する。d_busy(3:2)は、アドレス送出サイクルでのバスの使用状況に応じて、バス使用権を獲得したプロセッサが生成される。どのプロセッサもバスの使用権を獲得していない時にはマスターコントローラMCが”00”をドライブする。図12は、内部データバスDBUS及び内部システムバスSBUSによるデータ用メモリのアクセス状況によって、マスターコントローラMCが生成するd_busy(1:0)信号の生成アルゴリズムを示す表である。ここで、d_busy(2)は、将来の為のリザーブビットであり、内部リソースが追加された場合に使用される。d_busy(3)は、バス権を獲得したRISCエンジンやDSPエンジンがコマンドを送出する時、内部データバスDBUSを続けて使用する場合に1、内部データバスDBUSを1サイクルだけ使用する場合には0をドライブする。
RISCエンジンやDSPエンジンからのバス使用リクエストは、d_request(3:0)の内の各1ビットの信号を各RISCエンジンやDSPエンジンが出力する。すなわちRISCエンジンRE0はd_request(0)、RISCエンジンRE1はd_request(1)、DSPエンジンDE0はd_request(2)、DSPエンジンDE1はd_request(3)をドライブする。図13は、RISCエンジンRE0が出力するd_request(0)の意味を説明する図である。
図14は、内部命令バスIBUSのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのd_priority(1:0)は、バス使用権を獲得したRISCエンジンやDSPエンジンの次のRISCエンジンやDSPエンジン(順序は、RE0→RE1→DE0→DE1→RE0)を指す。
各RISCエンジンやDSPエンジンは、リードリクエストであればd_busy(3:0)=”0000”のとき、ライトリクエストであればd_busy=”0000”あるいはd_busy=”0010”のときにリクエストを出力できる。また、各RISCエンジンやDSPエンジンは、アービトレーション・サイクルでバス使用権獲得後、次のサイクル(アドレス送出サイクル)でアドレスとともにデータ用メモリに対するコマンドd_cmd(3:0)を出力する。図15は、データ用メモリに対するコマンドd_cmd(3:0)の意味を説明する図である。
尚、データ用メモリは、プロセッサから送られてきたアドレスが、データ用メモリの実装されているアドレス空間外のときデータサイクルで、バスエラーi_berr=1が返される。このとき、データ用メモリの出力d_data(127:0)の内容は無効である。
また、データ用メモリは、リードリクエストに対してデータレディ信号としてバス使用要求信号d_request_slを出力する。このバス使用要求信号d_request_slは、アドレス送出(コマンド)に対するデータが準備完了であることを示す。プロセッサは、リードに対するデータをプログラム用メモリからのデータレディ信号としてのバス使用要求信号d_request_slを見て受け取る。
データ用メモリに対して内部システムバスSBUSと内部データバスDBUSから同時にリードリクエストが送出された場合、プログラム用メモリでは内部システムバスSBUSからのコマンドを受け取った後に内部命令バスIBUSからのコマンドを行う。
<内部システムバスSBUSへのアクセス>
以下、内部システムバスSBUSへのアクセスの詳細を説明する。マスターコントローラMCと、RISCエンジンRE0,RISCエンジンRE1と、DSPエンジンDE0及びDSPエンジンDE1の5つのプロセッサは、内部システムバスSBUSを介して、バスコントローラBCとペリフェラルバスIF及びプログラム用メモリIMとデータ用メモリDMに対してリードサイクル及びライトサイクルを実行することができる。ただし、バスコントローラBCは、直接プログラム用メモリIMとデータ用メモリDMに対してリードサイクル及びライトサイクルを実行することができる。
従って、内部システムバスSBUSの効率の良いアービトレーションは、全体のスループットを向上させる上で、極めて重要となる。ここでは、5つのプロセッサからマスターコントローラMC(外部メモリ空間)へのリードサイクル、RISCエンジンRE0及びRISCエンジンRE1からプログラム用メモリIMとデータ用メモリDMに対してのリードサイクル(内部メモリ空間)、及び5つのプロセッサからペリフェラルバスIFに対してのリードサイクル(内部メモリマップドI/O空間)は、スプリット・トランザクションによって、実効的なバスの使用効率を向上させている。
特に重要なのは、優先順位の設定である。本発明の実施形態では、2段階の適応型ラウンドロビンのバス・アービトレーションアルゴリズムが適用される。即ち、プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFの各リソースは、バスの使用権について、マスターコントローラMC、RISCエンジンやDSPエンジンの各プロセッサよりも常に高い優先権が与えられる。そして、プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIF間の優先権は、適応型ラウンドロビンによって移動する。同様に、マスターコントローラMC、RISCエンジンやDSPエンジンの各プロセッサ間の優先権も、適応型ラウンドロビンによって移動する。
マスターコントローラMC、RISCエンジン、DSPエンジンは、バスコントローラBCとペリフェラルバスIFのいずれも内部システムバスSBUSの使用リクエストを行っていない場合にのみ、内部システムバスSBUSの使用リクエストを発行できる。図16は、sys_priority(2:0)によって示される優先順位を説明する図である。
プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFからのバス使用リクエストを行う場合には、sys_request_sl(3:0)の内の各1ビットの信号を各RISCエンジンやDSPエンジンが出力する。すなわちプログラム用メモリIMはsys_request_sl(0)、データ用メモリDMはsys_request_sl(1)、バスコントローラBCはsys_request_sl(2)、ペリフェラルバスIFはsys_request_sl(3)をドライブする。図17は、バスコントローラBCが出力するsys_request_sl(0)の意味を説明する図である。図18は、sys_priority_sl(2:0)によって示される優先順位を説明する図である。
図19は、内部システムバスSBUSのアービトレーションの規則を説明する図である。この図に示す様に、次のサイクルのsys_priority_sl(1:0)は、バス使用権を獲得したプログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIF(順序は、IM→DM→BC→IF)を指す。
プログラム用メモリIM、データ用メモリDM、バスコントローラBC及びペリフェラルバスIFの各リソースのいずれも内部システムバスSBUSの使用リクエストを行っていない場合、各RISCエンジンやDSPエンジンは、sys_busy(8:0)信号(バスコントローラBC、ペリフェラルバスIF、プログラム用メモリIM及びデータ用メモリDMのステータスを示す)を見て、バスがビジーでなく、アクセスターゲットがビジーでなければ内部システムバスSBUSの使用リクエストを出し、優先順位に従って使用権を獲得する。
ここで、sys_busy(0)信号は、バスコントローラBCがドライブする。すなわち、バスコントローラBCが、このsys_busy(0)信号をアサートした場合、他のプロセッサは、バスコントローラBCへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、バスコントローラBCは、マスターコントローラMC、RISCエンジン、DSPエンジンから、リードコマンドやアドレスを受けると、バスコントローラBCは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、sys_busy(0)信号をアサートし、それ以上の受付けを停止する。
また、sys_busy(1)信号は、マスターコントローラMC、RISCエンジン、DSPエンジンが、バスコントローラBCへ後述するコマンドを出力すると同時に1クロックだけアサートする。これは、バスコントローラBCからコマンドに対する応答ステートが返されるまでの間(1クロック)、他のプロセッサからバスコントローラBCへアクセスすることを禁止する為である。
マスターコントローラMCと、RISCエンジンRE0,RISCエンジンRE1と、DSPエンジンDE0及びDSPエンジンDE1との間のアービトレーションは、適応型ラウンドロビンで行われる。この場合、ある時点での内部データバスDBUS使用の優先順位を示すための3ビットの信号sys_priority(2:0)を用いる。図21は、sys_priority(2:0)によって示される優先順位を説明する図である。ここに示した通り、sys_priority(2:0)が更新されることによって、ラウンドロビンによるアービトレーションが実現される。
ここで、sys_busy(2)信号は、データ用メモリDMがドライブする。すなわち、データ用メモリDMが、このsys_busy(2)信号をアサートした場合、他のプロセッサは、データ用メモリDMへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、データ用メモリDMは、マスターコントローラMC、RISCエンジン、DSPエンジンから、リードコマンドやアドレスを受けると、データ用メモリDMは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、sys_busy(2)信号をアサートし、それ以上の受付けを停止する。
また、sys_busy(3)信号は、マスターコントローラMC、RISCエンジン、DSPエンジンが、データ用メモリDMへ後述するコマンドを出力すると同時に1クロックだけアサートする。これは、データ用メモリDMからコマンドに対する応答ステートが返されるまでの間(1クロック)、他のプロセッサからデータ用メモリDMへアクセスすることを禁止する為である。
ここで、sys_busy(4)信号は、プログラム用メモリがドライブする。すなわち、プログラム用メモリが、このsys_busy(4)信号をアサートした場合、他のプロセッサは、プログラム用メモリへのアクセスを目的にバス使用リクエストを発行することができない。具体的には、プログラム用メモリは、マスターコントローラMC、RISCエンジン、DSPエンジンから、リードコマンドやアドレスを受けると、プログラム用メモリは一旦それを内部のバッファに保持し、比較的低速な外部メモリへのアクセスしリード結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、sys_busy(4)信号をアサートし、それ以上の受付けを停止する。
また、sys_busy(5)信号は、マスターコントローラMC、RISCエンジン、DSPエンジンが、プログラム用メモリへ後述するコマンドを出力すると同時に1クロックだけアサートする。これは、プログラム用メモリからコマンドに対する応答ステートが返されるまでの間(1クロック)、他のプロセッサからプログラム用メモリへアクセスすることを禁止する為である。
sys_busy(6)信号は、ペリフェラルバスIFでドライブされ、ペリフェラルバスIFのステータスを示す。sys_busy(6)信号が状態の時は、ペリフェラルバスIFへのアクセス目的でバス使用リクエストを要求することはできない。もちろん、ペリフェラルバスIFへのコマンドも発行できない。具体的に説明すれば、ペリフェラルバスIFは、マスターコントローラMC、RISCエンジン、DSPエンジンから、リードコマンドやアドレスを受けると、ペリフェラルバスIFは一旦それを内部のバッファに保持し、比較的低速な周辺回路へのアクセスし結果を返す。しかし、リードコマンドが連続して発行され内部のバッファがいっぱいになると、sys_busy(6)信号をアサートし、それ以上の受付けを停止する。
また、sys_busy(7)信号は、ペリフェラルバスIFがドライブによってドライブされ、マスターコントローラMC、RISCエンジン、DSPエンジンが、ペリフェラルバスIFへ後述するコマンドを出力すると同時に1クロックだけアサートする。これは、ペリフェラルバスIFからコマンドに対する応答ステートが返されるまでの間(1クロック)、他のプロセッサからペリフェラルバスIFへアクセスすることを禁止する為である。
sys_busy(8)信号は、バスの使用権を獲得したマスターコントローラMC、RISCエンジンやDSPエンジンがコマンドを送出する時、内部システムバスSBUSを続けて使用する場合に1、内部システムバスSBUSを1サイクルだけ使用する場合には0をドライブする。これによって、連続してバスを使用することができる。
このsys_busy(8)信号は、マスターコントローラMC、RISCエンジン、DSPエンジンがバスコントローラBCやペリフェラルバスIFのようにリード・アクセスを要求し、データのレディを待つ場合に、コマンド送出サイクルから最後のレディを受け取るまでの間、バス使用権を獲得したプロセッサによって出力される。
内部システムバスSBUS使用リクエストは、sys_request(4:0)の内の各1ビットの信号をマスターコントローラMCおよび各RISCエンジンやDSPエンジンが出力する。すなわちRISCエンジンRE0はsys_request(0)、RISCエンジンRE1はsys_request(1)、DSPエンジンDE0はsys_request(2)、DSPエンジンDE1はsys_request(3)、マスターコントローラMCはsys_request(4)をドライブする。図20は、RISCエンジンRE0が出力するsys_request(0)の意味を説明する図である。
バス使用権は、図21に示す規則に従って決められる。また、マスターコントローラMC、RISCエンジンやDSPエンジンは、バス使用権獲得後、次のサイクルでアドレスとともにコマンドを出力する。図22は、マスターコントローラMC、RISCエンジンやDSPエンジンが出力するコマンドの一覧である。ここで、コマンド発行元SRCのPxは、コントローラMC、RISCエンジンやDSPエンジンのプロセッサIDであり、アクセス先のBIUはバスコントローラBC、DMはデータ用メモリDM、IMはプログラム用メモリIM、IPUはペリフェラルバスIFを示す。
尚、コマンドsys_cmd(3:0)は、転送データ数(ロードマルチ、ストアマルチでBIUに対するコマンド時に使用)であり、たとえば、”0000”は16ロングワード、”0001”は1ロングワード、”1111”は15ロングワードである。また、コマンドsys_cmd(5:4)、は、データサイズ(00:バイト、01:ワード、10:ロングワード、11:リザーブ)であり、sys_cmd(6)によって、ロードストア(0:ストア、1:ロード)を識別し、sys_cmd(10:7)は、アクセスのデスティネーション(BCからのコマンドを除く)を示す。更に、”0000”のとき、コマンドはNOPとなる。
尚、マスターコントローラMCは、RISCエンジンやDSPエンジンから送られてきたアドレスが、実装されているアドレス空間外のとき、あるいはリザーブのコマンドが送られてきた時にデータサイクルで、バスエラーsys_biu_berr=1を返す。同様に、データ用メモリDMは、マスターコントローラMC、RISCエンジンやDSPエンジンから送られてきたアドレスが、実装されているアドレス空間外の時にデータサイクルで、バスエラーsys_dm_berr=1を返す。また、プログラム用メモリは、マスターコントローラMC、RISCエンジンやDSPエンジンから送られてきたアドレスが、実装されているアドレス空間外の時にデータサイクルで、バスエラーsys_dm_berr=1を返す。また、ペリフェラルバスIFは、マスターコントローラMC、RISCエンジンやDSPエンジンから送られてきたアドレスが、そのアドレス空間外の時にデータサイクルで、バスエラーsys_ipu_berr=1を返す。
以上、本発明を実施例により詳細に説明したが、当業者にとっては、本発明が本願中に説明した実施例に限定されるものではないということは明らかである。本発明の装置は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本願の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
例えば、上記実施例では、マスターコントローラMCおよび各RISCエンジンやDSPエンジンとには、非対称のマルチプロセッサシステムとなっている。しかし、各RISCエンジンやDSPエンジンのみからなる対称型のマルチプロセッサの実装も、当業者であれば、上記の開示から本発明の実施例として実装可能であることは明らかである。
また、上記実施例では、RISCエンジンやDSPエンジンのみの組み合わせであるが、それ以外のエンジン、例えばSプログラム用メモリ、D型のエンジン、グラフィックスエンジン、Vector型のエンジン、あるいはカスタムエンジンとして特定のハードウエアブロックをエンジンとして組み込むこともできる。
更に、上記実施例では、プロセッサエンジンの数は4個であるが、同様の方法により、エンジンの数を8個まで、16個まで、32個まで、というように増やすことは、当業者にとって容易に可能である。
更に、上記実施例では、内部メモリを命令メモリとデータメモリの2つとしているが、同様の方法により、さらに数多くのメモリを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、外部バスコントローラは1つであるが、同様の方法により、複数の外部バスコントローラを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、内部ペリフェラルユニットにタイマおよびI/Oを付けているが、同様の方法により、様々な周辺デバイスを搭載するように変更を加えることは、当業者にとって容易に可能である。
更に、上記実施例では、マスターコントローラ、RISCエンジン、DSPエンジンのアーキテクチャ例を示しているが、他のアーキテクチャのプロセッサに同様のバスアーキテクチャを組み合わせることは、当業者にとって容易に可能である。
産業上の利用可能性
以上説明したように、本発明の実施形態によるスプリットトランザクションの為のアービトレーションシステムによれば、スプリットトランザクション時に、アクセスを開始したプロセッサが外部メモリからのデータを待つ時間を短縮することができ、全体の処理速度を向上させることができる。
【図面の簡単な説明】
図1は、本発明の実施形態による分散バス・アービトレーション方式における、適応型ラウンドロビンによる2段のアービトレーションを示す説明図である。
図2は、本発明の実施形態による分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムのブロックダイアグラムである。
図3は、本発明の実施形態による分散バス・アービトレーション方式を採用したシングルチップ・マルチプロセッサシステムの制御信号の接続関係を示すブロック図である。
図4は、本発明の実施形態による分散バス・アービトレーション方式における、内部バスを使用して、マスターコントローラMC、RISCエンジンやDSPエンジンによる、各リソースからのリードサイクルを示す図である。
図5は、本発明の実施形態による分散バス・アービトレーション方式における、内部バスを使用して、マスターコントローラMC、RISCエンジンやDSPエンジンによる、各リソースからのリードサイクルを示す図であり、アドレスを送出する際に、マスターコントローラMC、RISCエンジンやDSPエンジンは、転送データ数nを各リソースに通知する図。
図6は、本発明の実施形態による分散バス・アービトレーション方式において、制御信号のi_priority(1:0)によって示される優先順位を説明する図である。
図7は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスIBUS及び内部システムバスSBUSによるプログラム用メモリのアクセス状況によって、マスターコントローラMCが生成するi_busy(0)信号の生成アルゴリズムを示す表である。
図8は、本発明の実施形態による分散バス・アービトレーション方式における、RISCエンジンRE0が出力するi_request(0)の意味を説明する図である。
図9は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスIBUSのアービトレーションの規則を説明する図である。
図10は、本発明の実施形態による分散バス・アービトレーション方式における、プログラム用メモリに対するコマンドi_cmdの意味を説明する図である。
図11は、本発明の実施形態による分散バス・アービトレーション方式における、d_priority(1:0)によって示される優先順位を説明する図である。
図12は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスIBUS及び内部システムバスSBUSによるプログラム用メモリのアクセス状況によって、マスターコントローラMCが生成するd_busy(0)信号の生成アルゴリズムを示す表である。
図13は、本発明の実施形態による分散バス・アービトレーション方式における、RISCエンジンRE0が出力するd_request(0)の意味を説明する図である。
図14は、本発明の実施形態による分散バス・アービトレーション方式における、内部命令バスIBUSのアービトレーションの規則を説明する図である。
図15は、本発明の実施形態による分散バス・アービトレーション方式における、コマンドd_cmdの意味を説明する図である。プログラム用メモリへの書き込みは内部システムバスSBUSを介して行われる。
図16は、本発明の実施形態による分散バス・アービトレーション方式における、sys_priority(2:0)によって示される優先順位を説明する図である。
図17は、本発明の実施形態による分散バス・アービトレーション方式における、バスコントローラBCが出力するsys_request_sl(0)の意味を説明する図である。
図18は、本発明の実施形態による分散バス・アービトレーション方式における、sys_priority_sl(2:0)によって示される優先順位を説明する図である。
図19は、本発明の実施形態による分散バス・アービトレーション方式における、内部システムバスSBUSのアービトレーションの規則を説明する図である。
図20は、本発明の実施形態による分散バス・アービトレーション方式における、RISCエンジンRE0が出力するsys_request(0)の意味を説明する図である。
図21は、本発明の実施形態による分散バス・アービトレーション方式における、sys_priority(2:0)によって示される優先順位を説明する図である。
図22は、本発明の実施形態による分散バス・アービトレーション方式における、マスターコントローラMC、RISCエンジンやDSPエンジンが出力するコマンドの一覧である。
Claims (9)
- 共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行うアービターとからなり、前記複数のデバイスは、少なくとも2つのグループに分かれており、第2のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第1のグループに属するデバイスのいずれかが、前記第1のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第2のグループに属するデバイスからバス使用要求が発行されている場合、前記第1のグループに属するデバイスのバス使用要求は常に許可されず、前記第2のグループに属するデバイスの間で行われるラウンドロビンによって前記第2のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とする情報処理システム。
- 前記複数のデバイスの前記第1のグループは、前記共用バスのバス・マスタとしての複数のプロセッサであり、前記複数のデバイスの前記第2のグループは、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスであることを特徴とする請求項2に記載の情報処理システム。
- 前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行されることを特徴とする請求項2に記載の情報処理システム。
- バス使用の優先順位を決定するアービトレーション装置が、前記複数のプロセッサの各々に設けられていることを特徴とする請求項2に記載の情報処理システム。
- バス使用の優先順位を決定するアービトレーション装置が、前記複数のバス・スレーブ・デバイスの各々に設けられていることを特徴とする請求項2に記載の情報処理システム。
- 前記バス・スレーブ・デバイスは、外部メモリへのアクセスを行うコントローラ及びペリフェラルバスIFを含むことを特徴とする請求項2に記載の情報処理システム。
- 前記複数のプロセッサ、前記バス・スレーブ・デバイス及び前記共用バスは、シングルチップに集積されていることを特徴とする請求項2に記載の情報処理システム。
- 共用バスと、前記共用バスのバス・マスタとしての複数のプロセッサと、前記共用バスのバス・スレーブとしての複数のバス・スレーブ・デバイスとからなり、前記複数のプロセッサと前記バス・スレーブ・デバイスからは、前記共用バスへのスプリットトランザクションによるバス使用要求が発行され、前記バス・スレーブ・デバイスのいずれからもバス使用要求が発行されていない場合、前記複数のプロセッサのバス使用要求のいずれかが、前記複数のプロセッサの間で行われるラウンドロビンによって許可され、前記バス・スレーブ・デバイスからバス使用要求が発行されている場合、前記複数のプロセッサのバス使用要求は常に許可されず、前記複数のバス・スレーブ・デバイスの間で行われるラウンドロビンによって前記バス・スレーブ・デバイスのいずれかにバス使用が許可されることを特徴とするマルチプロセッサ・システム。
- 共用バスと、前記共用バスへのアクセスを行う複数のデバイスと、前記複数のデバイスからの前記共用バスの使用要求を受けて、アービトレーションを行う装置であって、前記複数のデバイスは、少なくとも2つのグループに分かれており、第2のグループに属するデバイスのいずれからもバス使用要求が発行されていない場合、第1のグループに属するデバイスのいずれかが、前記第1のグループに属するデバイスの間で行われるラウンドロビンによってバスの使用が許可され、前記第2のグループに属するデバイスからバス使用要求が発行されている場合、前記第1のグループに属するデバイスのバス使用要求は常に許可されず、前記第2のグループに属するデバイスの間で行われるラウンドロビンによって前記第2のグループに属するデバイスのいずれかにバス使用が許可されることを特徴とするバス・アービトレーション装置。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2001/004968 WO2002101565A1 (fr) | 2001-06-12 | 2001-06-12 | Systeme de traitement de donnees, systeme de multiprocesseur et arbitre de bus |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2002101565A1 true JPWO2002101565A1 (ja) | 2004-09-30 |
JP4214521B2 JP4214521B2 (ja) | 2009-01-28 |
Family
ID=11737423
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003504257A Expired - Lifetime JP4214521B2 (ja) | 2001-06-12 | 2001-06-12 | 情報処理システム及びマルチプロセッサ・システム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP4214521B2 (ja) |
WO (1) | WO2002101565A1 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007026022A (ja) * | 2005-07-15 | 2007-02-01 | Nec Electronics Corp | バス調停装置及びバス調停方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6368956A (ja) * | 1986-09-11 | 1988-03-28 | Fujitsu Ltd | バス優先順位決定回路 |
US4969120A (en) * | 1989-02-13 | 1990-11-06 | International Business Machines Corporation | Data processing system for time shared access to a time slotted bus |
JPH04195242A (ja) * | 1990-11-22 | 1992-07-15 | Fujitsu Ltd | アービトレーション方法 |
JPH06266657A (ja) * | 1993-03-17 | 1994-09-22 | Toshiba Corp | 情報処理装置 |
-
2001
- 2001-06-12 WO PCT/JP2001/004968 patent/WO2002101565A1/ja active Application Filing
- 2001-06-12 JP JP2003504257A patent/JP4214521B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP4214521B2 (ja) | 2009-01-28 |
WO2002101565A1 (fr) | 2002-12-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11334262B2 (en) | On-chip atomic transaction engine | |
US11907528B2 (en) | Multi-processor bridge with cache allocate awareness | |
JP5787629B2 (ja) | マシンビジョン用マルチプロセッサシステムオンチップ | |
US20180293199A1 (en) | Multicore bus architecture with non-blocking high performance transaction credit system | |
JP3570810B2 (ja) | 対称多重処理システム | |
US20120079155A1 (en) | Interleaved Memory Access from Multiple Requesters | |
US11803505B2 (en) | Multicore bus architecture with wire reduction and physical congestion minimization via shared transaction channels | |
JP5137171B2 (ja) | データ処理装置 | |
JP2012038293A5 (ja) | ||
US6647450B1 (en) | Multiprocessor computer systems with command FIFO buffer at each target device | |
US20040111547A1 (en) | High speed memory cloning facility via a lockless multiprocessor mechanism | |
JP4214521B2 (ja) | 情報処理システム及びマルチプロセッサ・システム | |
JP2011221931A (ja) | データプロセッサ | |
WO2002101563A1 (fr) | Systeme multiprocesseurs et arbitres de bus | |
WO2002101562A1 (fr) | Systeme multiprocesseur et processeur de signaux | |
WO2002101564A1 (fr) | Systeme multiprocesseur, procede permettant de le concevoir et systeme de multiprocesseur decrit en langage de description de materiel | |
Gupta | Multiple Protocol Engines for a Directory based Cache Coherent DSM Multiprocessor | |
JPH04335457A (ja) | バスアービトレーション・システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060425 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060626 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070213 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070416 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070427 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080828 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080924 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081023 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4214521 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111114 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121114 Year of fee payment: 4 |
|
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: 20121114 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131114 Year of fee payment: 5 |
|
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 |
|
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 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |