JP4737438B2 - 複数の処理ユニットでリソースを共有する情報処理装置 - Google Patents

Description

本発明は、複数の汎用または特定用途用のプロセッサを搭載したアプリケーションプロセッサ、あるいは専用ＬＳＩ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＳＯＣ(System On Chip)等から成る情報処理装置に関する。

複数の汎用または特定用途のプロセッサを搭載した従来の情報処理装置の一例を図１に示す。図１は携帯電話機や携帯端末装置に搭載されるアプリケーションプロセッサの一例を示している。

図１に示すように、情報処理装置３０１は、複数の情報処理ユニットと、各情報処理ユニットで共通に利用される複数の共有リソースとを有し、それらが内部バス３１２を介して互いに情報の送受信が可能に接続された構成である。

図１に示すアプリケーションプロセッサの場合、情報処理ユニットは、ＣＰＵ３０２やＤＳＰ３０３等の汎用プロセッサ、あるいはＤＭＡコントローラ（ＤＭＡＣ）３０４、カメラコントローラ３０５、ＬＣＤコントローラ３０６等の周辺コントローラである。

また、共有リソースは、内蔵メモリであるＳＲＡＭ３０８、外部メモリであるＳＤＲＡＭ(Synchronous Dynamic Random Access Memory)に対するデータの読み出し／書き込みを制御するＳＤＲＡＭコントローラ３０７、外部メモリ（例えばフラッシュメモリ）が接続される外部バスとのインタフェースである外部バスブリッジ３０９、各種周辺デバイス３１０、３１１等である。

このような複数の情報処理ユニットを備えた情報処理装置では、装置設計や性能検証を容易にするため、内部バス３１２に標準バスを用い、それに対応して各情報処理ユニットのバスインタフェースを設計する手法が一般的である。標準バスとしては、例えばＡＲＭ社（英国ケンブリッジ）が提唱しているＡＭＢＡ（Advanced Microcontroller Bus Architecture）を実現するＡＨＢ(Advanced High-performance Bus)が知られている。なお、ＡＨＢについては、例えば米国特許第5,740,461号明細書に詳しく説明されている。

しかしながら、図１に示したような従来の情報処理装置では、動画再生のように負荷が重い処理を行う場合、内部バス３１２のトラフィックの多くが画像データであるため、ＣＰＵ３０１等の処理で十分なバス帯域を確保することができず、処理性能が劣化するという問題が生じる。

このような問題を解決するには、例えば画像データ専用のバスを設ける等、複数の独立したバスを備えた構成が考えられる。しかしながら、このような構成では、各バスにメモリ等の複数の共有リソースをそれぞれ接続しなければならないため、情報処理装置のコストが上昇する問題がある。さらに、複数のバスを跨ってメモリに対してデータの書き込みや読み出しを行う際にはアクセス制限や遅延が生じるなど、ソフトウェアの開発に制約が課されることが多いという問題も生じる。

なお、バス帯域を確保するための他の手法として、データバスのビット幅を拡げることが考えられる。例えば３２ビット幅のデータバスを６４ビット幅に拡げればデータの転送時間が半減することが期待できる。しかしながら、汎用プロセッサでは３２ビット幅以下のデータの読み出し処理や書き込み処理も実行するため、バスのビット幅を拡大しても十分な効果が得られない。

そのため、複数のバスを並列に備えるMulti-Layer AHBと呼ばれるバス構造が上記ＡＲＭ社から提案されている。このMulti-Layer AHBの構成を図２に示す。

図２に示すように、Multi-Layer AHBは、複数の情報処理ユニット４０１〜４０３（図２では３台）と複数の共有リソース（図２では４台）４０８〜４１１とがマルチレイヤーバス４０７を介して接続される構成である。情報処理ユニット４０１〜４０３は、それぞれが備えるバスインタフェース４０４〜４０６によってマルチレイヤーバス４０７と接続され、共有リソース４０８〜４１１は、それぞれが備えるバスインタフェース４１２〜４１５によってマルチレイヤーバス４０７と接続される。

マルチレイヤーバス４０７は、情報処理ユニット４０１〜４０３に対応して設けられた入出力インタフェースである入力ステージ４２７〜４２９と、共有リソース４０８〜４１１に対応して設けられた、各情報処理ユニット４０１〜４０３から共有リソース４０８〜４１１宛に発行された各種リクエスト（アクセス要求）を調停するマルチプレクサ４２０〜４２３と、情報処理ユニット４０１〜４０３から発行されたアクセス要求を送信先の共有リソース４０８〜４１１へ転送するための制御を行うデコーダ４２４〜４２６とを有する構成である。

このような構成において、情報処理ユニット４０１〜４０３から発行されたアクセス要求は、それぞれが備えるバスインタフェース（BUS I/F）４０４〜４０６を介してマルチレイヤーバス４０７の入力ステージ（Input Stage）４１６〜４１８へ送信される。

デコーダ（Decode）４１９〜４２１は、入力ステージ（Input Stage）４１６〜４１８で受信したアクセス要求を解読し、その送信先の共有リソースに対応するマルチプレクサ(MUX)４２０〜４２３へ転送する。マルチプレクサ４２０〜４２３は、情報処理ユニット４０１〜４０３から発行されたアクセス要求を調停し、許可したアクセス要求から順にバスインタフェース（BUS I/F）４１２〜４１５を介して共有リソース（Slave）４０８〜４１１へ送信する。

このような構成では、複数の情報処理ユニット４０１〜４０３から共有リソース４０８〜４１１へ同時にアクセスする場合でも、競合が生じることなく同時にデータの送受信が可能であり、バス帯域の実質的な拡大が実現できる。

ところで、近年、大容量メモリとして代表的に用いられるＳＤＲＡＭは、データの書き込みや読み出し制御がＳＲＡＭ(Static Random Access Memory)等に比べて複雑であり、アクセス要求を受け付けてから実際にデータが書き込まれるまで、あるいはデータを取得できるまでに遅延が生じる。但し、ＳＤＲＡＭは複数ワード単位でデータの読み出しや書き込みが可能であり、連続してコマンドを与えることで、高いデータの読み出し／書き込み速度が実現できる。さらに、ＤＤＲ(Double Data Rate)−ＳＤＲＡＭは、動作クロックの立ち上がり及び立下りのタイミングでそれぞれデータの書き込み／読み出しが行われるため、通常のＳＤＲＡＭの２倍の速度で読み出し処理や書き込み処理が可能になる。

このＤＤＲ−ＳＤＲＡＭを情報処理装置の外部メモリとして使用する場合、ＤＤＲ−ＳＤＲＡＭに接続するバスやブリッジの伝送速度やビット幅をＤＤＲ−ＳＤＲＡＭのそれと同一にすると、ＤＤＲ−ＳＤＲＡＭの処理速度がバスの伝送速度を上回る。したがって、バスの伝送速度を２倍にするか、ビット幅を２倍にしてバスの伝送能力をＤＤＲ−ＳＤＲＡＭのデータ処理速度に一致させる必要がある。

しかしながら、バスの伝送速度を２倍にすると配線による遅延や消費電力が増大する問題が生じる。また、バスのビット幅を２倍にすると、情報処理ユニットのビット幅と一致しなくなるため、ビット幅を変換するデバイス等が必要になる。

ＤＤＲ−ＳＤＲＡＭによる応答遅延の影響を緩和する手法として、上記ＡＨＢ等の高性能バスでは、Split Transactionと呼ばれるプロトコルを用意している。Split
Transactionでは、例えば情報処理ユニットからメモリに対するデータ読み出し要求をメモリコントローラ（バスインタフェース）で受け付けると、該メモリコントローラは一旦バスを解放して読み出し処理を実行し、要求されたデータの読み出し処理が全て完了した時点で、要求元の情報処理ユニットに対するバス接続を再び確立し、読み出したデータを返送する。このようなプロトコルを利用することで、バスを解放している間に他の情報処理ユニットからのメモリアクセス要求を受け付けることが可能になる。すなわち連続したコマンドの受け付けが可能になる。

しかしながら、このような手法ではＤＤＲ−ＳＤＲＡＭ自体の応答遅延は隠蔽できるが、上述したＤＤＲ−ＳＤＲＡＭの処理速度とバスの伝送能力の不均衡は解消しない。また、Split Transactionを採用しても、任意の情報処理ユニットからのリクエストを受け付けている間はデータ転送が実行できないため、ＤＤＲ−ＳＤＲＡＭを十分に高い効率で利用しているとは言い難い。

さらに、Split Transactionをサポートするハードウェアでは、情報処理ユニットのバスインタフェース、バスのアービタ、共有リソースのバスインタフェース等の論理複雑度が増加する。そのため、ＡＲＭ社はリクエストとデータ転送を論理的に分離したＡＸＩ(Advanced eXtensible Interface)を提案しているが、論理的な複雑さが十分に改善されているとは言い難い。また、従来のバス規約で作成されたモジュール等を接続するためには、バス規約変換用のモジュールを用いるかバスインタフェースを再設計する必要があった。

本発明は上記したような従来の技術が有する問題点を解決するためになされたものであり、バスの伝送速度やビット幅を拡大することなく、共有リソースの利用効率を向上させ、かつ処理能力を向上させることができる情報処理装置を提供することを目的とする。

上記目的を達成するため本発明の情報処理装置は、少なくとも１つの共有リソースに複数のバスインタフェースを接続し、このバスインタフェースをマルチレイヤーバスにそれぞれ接続する。さらにバスインタフェース毎に各々リードデータ及びライトデータを保持するデータバッファを備える。各バスインタフェースからのアクセス要求はアービタにより調停し、共有リソースへのアクセス権を得たアクセス要求に応じてデータの読み書き等を行う。

このような構成では、共有リソースに対応して複数のバスインタフェースがあるため、Split Transactionを用いることなく、複数のアクセス要求を共有リソース内で連続してスケジューリングすることが可能であり、ＳＤＲＡＭ等の応答遅延による影響を低減できる。また、バスの伝送速度やビット幅を拡大することなく、処理速度が異なる共有リソースに対するアクセスも可能になる。

また、共有リソースからリードバッファへのデータの読み出し処理あるいはライトバッファから共有リソースへのデータの書き込み処理を実行中でも、次のアクセス要求を受け付けることができるため、共有リソースへ連続してアクセス要求を与えることが可能であり、共有リソースの利用効率が向上する。

携帯電話機や携帯端末装置に搭載されるアプリケーションプロセッサの構成を示すブロック図である。 Multi-Layer AHBの構成を示すブロック図である。 本発明の情報処理装置の第１の実施の形態の構成を示すブロック図である。 図３に示した情報処理装置のデータ読み出し時の動作を示すタイミングチャートである。 図３に示した情報処理装置のデータ書き込み時の動作を示すタイミングチャートである。 第２の実施の形態の情報処理装置が備えるリードバッファの構成を示すブロック図である。 図６に示したリードバッファの動作を示すタイミングチャートである。 本発明の情報処理装置の第３の実施の形態の構成を示すブロック図である。 本発明の情報処理装置の第４の実施の形態の構成を示すブロック図である。 ＳＤＲＡＭ調停のための優先度決定アルゴリズムの一例を示すフローチャートである。 排他的なアクセスがあったときのアービタ動作を示すフローチャートである。 排他的でないアクセスがあったときのアービタ動作を示すフローチャートである。 リードバッファにバッファスルーパスを備えた構成を示す図である。 図１２に示した構成とした場合のデータ読み出し時の動作を示すタイミングチャートである。

本発明の実施形態について図面を参照して詳細に説明する。

（第１の実施の形態）
図３は本発明の情報処理装置の第１の実施の形態の構成を示すブロック図である。

図３に示すように、第１の実施の形態の情報処理装置は、複数の情報処理ユニット１〜３（図３では３台）と複数の共有リソース（図３では３台）８〜１０とを備え、それらがマルチレイヤーバス７を介して接続された構成である。情報処理ユニット１〜３は、それぞれが備えるバスインタフェース４〜６によってマルチレイヤーバス７と接続され、共有リソース９、１０はバスインタフェース１８、１９によってマルチレイヤーバス７と接続される。

本実施形態では、複数の共有リソースのうち、任意の１台の共有リソース（ここでは共有リソース８）に、マルチレイヤーバス７と接続される２つのバスインタフェース（BUS I/F）１１，１２を備えた構成である。バスインタフェース１１，１２は、共有リソース８から読み出されたデータを保持するリードバッファ１３，１４と、共有リソース８へ格納するデータを保持するライトバッファ１５、１６とを備えた構成である。バスインタフェース１１，１２と共有リソース８とは、共有リソース８に対するアクセス要求を調停するアービタ１７を介して接続される。

マルチレイヤーバス７は、情報処理ユニット１〜３に対応して設けられた入出力インタフェースである入力ステージ２６〜２８と、各情報処理ユニット１〜３から共有リソース８〜１０宛に発行された各種リクエスト（アクセス要求）を調停するマルチプレクサ２０〜２２と、情報処理ユニット１〜３から発行されたアクセス要求を送信先の共有リソース８〜１０へ転送するためのデコーダ２３〜２５とを有する構成である。なお、図３では情報処理ユニット及び共有リソースをそれぞれ３台有する構成例を示しているが、情報処理ユニット及び共有リソースの数は３台に限定されるものではなく、それぞれ幾つであってもよい。

このような構成において、情報処理ユニット１〜３から発行されたアクセス要求は、それぞれが備えるバスインタフェース４〜６を介してマルチレイヤーバス７の入力ステージ（Input Stage）２６〜２８へ送信される。

デコーダ（Decode）２３〜２５は、入力ステージ（Input Stage）２６〜２８で受信したアクセス要求を解読し、送信先の共有リソースに対応するマルチプレクサ(MUX)２０〜２２へ転送する。マルチプレクサ２０〜２２は、情報処理ユニット１〜３から発行されたアクセス要求を調停し、許可を与えたアクセス要求から順にバスインタフェース（BUS I/F）１１、１２、１８，１９を介して共有リソース（Slave）８〜１１へ送信する。

図３に示す情報処理装置では、共有リソース８に対応して２つのバスインタフェース１１，１２を備え、情報処理ユニット１から共有リソース８へ発行されたアクセス要求はバスインタフェース１１へ直接送信され、情報処理ユニット２または情報処理ユニット３から共有リソース８へ発行されたアクセス要求はマルチプレクサ２０を介してバスインタフェース１２へ送信される。また、情報処理ユニット２及び情報処理ユニット３から共有リソース８へ発行されたアクセス要求はマルチプレクサ２０によって調停される。

共有リソース９、１０は、従来と同様に１つのバスインタフェースを備えた構成であるため、マルチプレクサ２１、２２により情報処理ユニット１〜３からのアクセス要求が調停される。

このように、１つの共有リソース８に対応してバスインタフェースを複数備え、アービタ１７により共有リソース８に対するアクセス要求を調停することで、Split Transactionを用いることなく、複数の情報処理ユニットからのアクセス要求を連続してスケジューリングすることが可能になる。

一般にＳＤＲＡＭでは、その特性上、同一バンクの異なるページに対して連続してアクセスするとき、一旦プリチャージを行って必要な時間が経過するまで、次のアクセスのためにＲＯＷをオープンすることができない。また、リードとライトの切り替えには一定の間隔が必要となる。本実施形態において、アービタ１７は、過去に実行したアクセス要求と、その実行からの経過時間とからバンク毎のＳＤＲＡＭの状態を把握しており、複数のリードバッファ１３，１４またはライトバッファ１５，１６からのアクセス要求について、ＳＤＲＡＭの特性および状態を考慮してアクセスするための時間が短く済むアクセス要求を選択するように調停を行う。アービタ１７は、例えば、アクセス要求があると、その優先度を決定し、その優先度に従って調停を行えばよい。これにより、システム全体として、ＳＤＲＡＭのデータ帯域を有効に拡大することが可能になる。

図１０は、ＳＤＲＡＭ調停のための優先度決定アルゴリズムの一例を示すフローチャートである。ここでは、優先度１〜９の９段階の優先度があり、優先度１が最も優先度が高く、優先度９が最も優先度が低いものとする。

図１０を参照すると、アクセス要求があると、アービタ１７は、まず、そのアクセス要求の実行にリードライトの切り替えが有るか否か判定する（ステップ５０１）。リードライトの切り替えがなければ、アービタ１７は、それがリード要求であるか否か判定する（ステップ５０４）。

ステップ５０１にてリードライトの切り替えが無いと判定された場合、アービタ１７は、同一ＲＯＷに対するアクセスか否かを判定する（ステップ５０２）。同一ＲＯＷへのアクセスであれば、そのアクセス要求は優先度１とされる。ステップ５０２にて同一ＲＯＷへのアクセスでなければ、アービタ１７は、バンク競合が有るか否か判定する（ステップ５０３）。バンク競合がなければ、そのアクセス要求は優先度２とされ、バンク競合があれば、そのアクセス要求は優先度７とされる。

また、ステップ５０４にてリード要求と判定された場合、アービタ１７は、同一ＲＯＷに対するアクセスか否かを判定する（ステップ５０５）。同一ＲＯＷへのアクセスであれば、そのアクセス要求は優先度３とされる。ステップ５０５にて同一ＲＯＷへのアクセスでなければ、アービタ１７は、バンク競合が有るか否か判定する（ステップ５０６）。バンク競合がなければ、そのアクセス要求は優先度４とされ、バンク競合があれば、そのアクセス要求は優先度８とされる。

また、ステップ５０４にてリード要求でないと判定された場合、アービタ１７は、同一ＲＯＷに対するアクセスか否かを判定する（ステップ５０７）。同一ＲＯＷへのアクセスであれば、そのアクセス要求は優先度５とされる。ステップ５０７にて同一ＲＯＷへのアクセスでなければ、アービタ１７は、バンク競合が有るか否か判定する（ステップ５０８）。バンク競合がなければ、そのアクセス要求は優先度６とされ、バンク競合があれば、そのアクセス要求は優先度９とされる。

このようにしてアービタ１７は、共有リソース９へのアクセス要求の優先度を決定し、優先度の高いアクセス要求から優先的に選択するように調停を行う。その際、複数のアクセス要求が同一の優先度となった場合、任意の方法でいずれかのアクセス要求を先に選択すればよい。例えば、同一優先度のアクセス要求の中からランダムに選択してもよく、またラウンドロビンと呼ばれるポリシーで公平に選択してもよい。

また、一般に、ＳＤＲＡＭへのアクセスでは、同一バンク、同一ＲＯＷに対するアクセスについては、ＲＯＷのオープンおよびプリチャージを1回で済ますことができる。そこで、本実施形態のアービタ１７は、同一バンク、同一ＲＯＷへのアクセスを連続して選択するように調停を行うこととしてもよい。

例えば、情報処理ユニット１からＳＤＲＡＭのBANK=１、ROW=１０、COLUMN=２０のデータライトアクセス要求と、情報処理ユニット２から、同じくBANK=1、ROW=１０、COLUMN＝１２のデータライトアクセス要求が生じたとする。それらの書き込みデータはライトバッファ１５、１６の各々に格納される。その場合、アービタ１７がそれらの要求を連続して共有リソース８のＳＤＲＡＭに発行することにより、システムは、BANK＝１、ROW=１０のページをオープンしたまま２つのアクセス要求を連続して処理し、情報処理ユニット１，２の書き込みを連続して行ったのちにプリチャージによってページを閉じるという操作が可能となる。これにより、性能向上とページオープンクローズ回数削減による省電力化を図ることが可能になる。

しかしながら、このようにデータ帯域だけを重視した調停では、調停に負け続けて実際のアクセスがなかなかできないという事態が想定され、アクセス要求によってはデータ転送効率を落とす可能性がある。これに対して、アービタ１７は、各アクセス要求について何回目の調停かをカウントしておくためのカウンタを備え、所定回数以上になったアクセス要求については、ＳＤＲＡＭの状態に関わらず優先的に選択することととしてもよい。

また、情報処理ユニット１〜３の各々にデータ遅延の許容量に差がある場合がある。その場合、ＳＤＲＡＭの状態からデータ転送効率だけを重視して調停する方法ではシステムとして十分な調停とならない。それに対して、アービタ１７は、情報処理ユニット１〜３についてアクセス元としての優先度を予め定めておき、共有リソース８へのアクセス要求があると、それがいずれの情報処理ユニットからのものかを特定し、アクセス元としての優先度とデータ転送効率の双方を考慮して調停を行うこととしてもよい。

一方、情報処理ユニット１，２の処理によっては、共有リソース８のメモリに排他制御により複数のメモリアクセスを不可分に行う必要がある。その一連のメモリアクセスの間、他の情報処理ユニットがそのメモリ領域にアクセスしないことをハードウェアによって保証する。これは、例えばＡＲＭ社から供給されるＡＲＭ９２６プロセッサの命令セットでは、SWAPという命令によって定義されている。このSWAP命令では、同一アドレスに対してリード要求とライト要求を連続して不可分に行うため、このリード要求とライト要求の間に他のアクセスを許可せずＡＨＢバスをロックし、結果的にメモリをロックする。

図３に示した情報処理装置では、共有リソース８は複数のバスインタフェース１１，１２によってマルチレイヤーバス７に接続されている。そのため、１つのバスインタフェースでバスをロックするだけでは、共有リソース８は完全にはロックされない。例えば、情報処理ユニット２が共有リソース８に対してロックを行うと、バスインタフェース１２に接続されるバスはロックされ、情報処理ユニット３からのアクセスは行えなくなる。しかし、情報処理ユニット１は他のバスインタフェース１１を介しているため共有リソース８にアクセスすることができてしまう。その結果、情報処理ユニット２による共有リソース８への不可分なアクセスが保証できなくなる。

これに対して、一例として、バスインタフェース１２にてロックによる共有リソース８へのアクセス要求があると、複数のアクセスが不可分に行われることを保証するために、共有リソース８に関する全てのリードバッファ１３，１４の内容をクリアし、またライトバッファ１５，１６の内容を共有リソース８へ反映させる。そして、その処理の後にバスインタフェース１１を介した共有リソース８へのアクセスの受け付けを一時的に保留とする処理を行って情報処理ユニット２からの複数のアクセス要求を不可分に処理することとしてもよい。これにより、共有リソース８への排他的なアクセスが可能となる。バスアービタ１７は、この間、他のアクセスを調停に参加させないようにする。

しかし、この方法では、共有リソース８への排他アクセス中は、共有リソース８の排他領域に関係しないアドレスへのアクセスも全て待たされることとなる。この制御が性能に与えるインパクトは大きい。

そこで、他の例として、排他アクセスを行うアドレスを一定の範囲に絞ることとしてもよい。これによれば、共有リソース８の利用効率の低下を抑制しつつ、排他アクセスを実現することができる。図１１は、排他アクセスを可能にするアービタ動作を示すフローチャートである。

図１１Ａにおいて、排他的なアクセス要求があると、アービタ１７は、まず、排他アクセス中の情報処理ユニットが他に存在するか否か確認する（ステップ６０１）。他に排他アクセス中の情報処理ユニットがあれば、その排他アクセスが終了するまで待ち合わせる（ステップ６０６）。

排他アクセス中の他の情報処理ユニットがない状態で、アービタ１７は、アクセス要求のアドレスと、リードバッファおよびライトバッファに格納されているアドレスとを比較し（ステップ６０２）、アクセス要求のアドレスと同一のアドレスがリードバッファまたはライトバッファに存在するか否か判定する（ステップ６０３）。

同一アドレスがリードバッファまたはライトバッファにあれば、アービタ１７は、リードバッファの無効化、またはライトバッファの内容の共有リソース８への書き戻しを行う（ステップ６０４）。

ステップ６０３の判定において同一アドレスがリードバッファおよびライトバッファに存在しないとき、またはステップ６０４の処理の後、アービタ１７は、通常のアービトレーションとして、共有リソース８に対して一連の排他アクセスを許可する（ステップ６０５）。

一方、図１１Ｂにおいて、排他的でないアクセス要求があると、アービタ１７は、他に排他アクセスが存在するか否か確認する（ステップ６０７）。他に排他アクセスが存在しなければ、アービタ１７は、通常のアービトレーションとして、共有リソース８に対するアクセスを許可する（ステップ６１０）。

ステップ６０７の判定において他に排他アクセスが存在すれば、アービタ１７は、その排他アクセスと同一アドレスへのアクセス要求か否か判定する（ステップ６０８）。同一アドレスでなければ、アービタ１７は、排他アクセスと無関係に、通常のアービトレーションとして、共有リソース８に対するアクセスを許可する（ステップ６１０）。

ステップ６０８の判定において、他の排他アクセスと同一アドレスに対するアクセス要求であれば、アービタ１７は、その排他アクセスが終了するまで待ち合わせ（ステップ６０９）、ステップ６０７の処理に戻る。

なお、ここで同一アドレスとは同一のアドレス範囲のことを指しており、リードバッファあるいはライトバッファに格納されるデータ領域に相応する。

また、本実施形態のおいて、このような排他アクセスを行えるバスを１つに制限することとしてもよい。それにより、他に排他アクセス中の情報処理ユニットがあるか否か判定するステップ６０１の処理が不要となり、また、同時に複数の情報処理ユニットが排他アクセスを行う場合の競合による論理的複雑性も解消される。

また、１つの共有リソース８に対応して２つのバスインタフェース１１，１２を備えることで、情報処理ユニット１〜３が備えるバスインタフェース４〜６、あるいは他の共有リソース９，１０が備えるバスインタフェース１８，１９等を、仕様を変更することなく接続することができる。

さらに、共有リソース８からリードバッファへのデータの読み出し処理あるいはライトバッファから共有リソースへのデータの書き込み処理を実行中でも、次のアクセス要求を受け付けることができるため、共有リソース８へ連続してアクセス要求を与えることが可能であり、共有リソース８の利用効率が向上する。

次に、本実施形態の情報処理装置の動作について、マルチレイヤーバス７の伝送速度に対して共有リソース８の処理速度が２倍である場合（例えば共有リソース８がＤＤＲ−ＳＤＲＡＭの場合）を例にして説明する。

まず、情報処理ユニット１により共有リソース８からデータを読み出す場合の動作について図４を用いて説明する。図４は図３に示した情報処理装置のデータ読み出し時の動作を示すタイミングチャートである。

図４に示すように、情報処理ユニット１から共有リソース８にデータの読み出し要求（以下、リード要求と称す）が発行されると、該リード要求はバスインタフェース４を介してＴ１のタイミングでマルチレイヤーバス７へ送信される。デコーダ２３は、マルチレイヤーバス７の入力ステージ２６が情報処理ユニット１からのリード要求を受信すると、該リード要求に含まれるアクセス先のアドレスを基に共有リソース８へのアクセス要求であると判断し、該リード要求をバスインタフェース１１へ転送する。

バスインタフェース１１は、Ｔ２のタイミングでこのアクセス要求を受理し、リード要求であると判断すると、リードバッファ１３を介してアービタ１７に該リード要求を転送する。

アービタ１７による調停で共有リソース８へのアクセス要求が許可されると、リードバッファ１３はＴ３のタイミングで共有リソース８からのデータの読み出し処理を開始する（Read 起動）。ここでは、共有リソース８がマルチレイヤーバス７の２倍の伝送能力を備え、４ワード単位でデータが読み出されるとする。その場合、リードバッファ１３へは、図４に示すＴ３の後半からＴ５のタイミングで読み出されたデータ（以下、リードデータと称す）が格納される。

また、リードバッファ１３は、Ｔ４のタイミングから情報処理ユニット１へのデータ返送を開始する。情報処理ユニット１に対するリードデータの転送は、共有リソース８からリードバッファ１３へのデータ転送よりも時間を要するため、図４に示すＴ７のタイミングでデータ転送が完了する。

共有リソース８は、図４に示すＴ５の後半のタイミングから待機状態となるため、Ｔ６のタイミングからリードバッファ１４またはライトバッファ１５，１６を介したアクセス要求の処理が可能となる。

一方、図３に示したリードバッファ１３、１４について、バスインタフェース１１とアービタ１７をバッファを通らずに結ぶパス（以下「バッファスルーパス」という）を設けることとしてもよい。図１２は、リードバッファにバッファスルーパスを備えた構成を示す図である。図１２を参照すると、リードバッファ７０２を通らないバッファスルーパス７０１が設けられ、リードバッファ７０２をスルーすることができるような構成となっている。この構成によれば、リードアクセスについて、データ応答サイクルを短縮することができる。

図１３は、図１２に示した構成とした場合のデータ読み出し時の動作を示すタイミングチャートである。図１３を参照すると、情報処理ユニットへのデータ応答のタイミングだけが図４に示したタイミングチャートと異なっている。

図１３の例では、最初のデータ転送Ｒ１では、バッファスルーパス７０１によりＴ３サイクルにてデータ応答が行われている。その後のデータ転送Ｒ２〜Ｒ４では、データ応答が通常のリードバッファ７０２を介してＴ４〜Ｔ６サイクルで行われる。その結果、図４に示した例よりも1サイクル分だけ早くデータ転送が完了している。

次に、情報処理ユニット１から共有リソース８へデータを格納する場合の動作について図５を用いて説明する。

図５は図３に示した情報処理装置のデータ格納時の動作を示すタイミングチャートである。

図５に示すように、情報処理ユニット１から共有リソース８にデータの書き込み要求（以下、ライト要求と称す）が発行されると、該ライト要求は、リード要求時と同様にバスインタフェース４を介してＴ１のタイミングでマルチレイヤーバス７へ送信される。デコーダ２３は、マルチレイヤーバス７の入力ステージ２６が情報処理ユニット１からライト要求を受信すると、該ライト要求に含まれるアクセス先のアドレスを基に共有リソース８へのアクセス要求であると判断し、該ライト要求をバスインタフェース１１へ転送する。

バスインタフェース１１は、Ｔ２のタイミングでこのアクセス要求を受理し、ライト要求であると判断すると、ここではＴ２からＴ５のタイミングで４ワード分の書き込み用のデータ（以下、ライトデータと称す）を受信する。

ライトバッファ１５は、Ｔ５のタイミングでライトデータの受信を完了すると、Ｔ６の前半のタイミングでアービタ１７に対してライト要求を送信する。

アービタ１７による調停で共有リソース８へのアクセス要求が許可されると、ライトバッファ１５はＴ７のタイミングから共有リソース８への書き込み処理を開始（Write 起動）し、Ｔ７〜Ｔ８のタイミングで４ワード分のライトデータを共有リソース８へ格納する。

したがって、ライトバッファ１５による共有リソース８への書き込み処理を実行している間、リードバッファ１３，１４あるいはライトバッファ１６を介したアクセス要求の処理が可能となる。

また、共有リソースの処理速度がバスの伝送速度を上回る場合にも、情報処理ユニットから共有リソースへの書き込み時には、一旦バッファに一定量のデータを格納した後、共有リソースに共有リソースの処理速度でデータを書き込み、データを読み出す場合は、共有リソースからバッファにデータを書きこみつつ、バスの転送速度で情報処理ユニットに応答できる。逆にバスの伝送速度が速い場合も、リードバッファあるいはライトバッファによってデータを一時的に蓄えることにより、バスに不必要な待ち受け処理を実行しなくても済むためバスの利用効率が向上する。

これは、本実施形態においてバスインタフェース１１に対してリードバッファ１３およびライトバッファ１５を備え、バスインタフェース１２に対してリードバッファ１４およりライトバッファ１６を備えるというように、リードバッファおよびライトバッファの双方を備えたバスインタフェースにより実現されている。

ところで、図３に示した構成では、バスインタフェース１１、１２が備えるリードバッファ１３，１４及びライトバッファ１５，１６を介して受信したアクセス要求をアービタ１７により調停し、共有リソース８に対するアクセス順序を決定している。ここで、アクセスするアドレスが異なる場合は、上述したようにリード要求を優先して処理することで情報処理装置としての処理速度の向上が期待できる。これは、リード要求に対するリードバッファへのデータ転送待ちの時間を短縮することで、情報処理ユニットによる共有リソース８からの応答待ち時間が短縮されるためである。

しかしながら、異なる情報処理ユニットあるいは同一の情報処理ユニットから同一のアドレスに対して複数のアクセス要求が発行された場合はアクセス要求の受け付け順序を維持する必要がある。

例えば、ライトバッファに格納されたデータの書き込みアドレスと同一のアドレスから引き続きデータを読み出す場合、ライトバッファのデータをメモリ（共有リソース）へ格納した後に読み出し処理を実行しないと、更新前のデータを読み出すことになる。また、異なる情報処理ユニットから同一のアドレスへデータを書き込む場合、２つのアクセス要求の順序を維持しなければ、メモリ内のデータは正しく更新されない。

そこで、本実施形態の情報処理装置では、バスインタフェース１１，１２にそれぞれ不図示のアドレス比較器を備えていてもよい。アドレス比較器は、例えば共有リソース８に対する新たなライト要求をライトバッファ１５で受信すると、ライトバッファ１６内に格納されたライトデータとその書き込みアドレスをそれぞれ比較する。そして、同一アドレスへ格納するライトデータがある場合は、そのデータが共有リソース８へ格納されるまで受信した新たなライト要求をアービタ１７へ転送しないように制御する。また、同時にリードバッファ１３，１４内に読み出し処理が完了していないリードデータがある場合は、それらの読み出しアドレスとそれぞれ比較する。そして、新たに受信したライト要求のアドレスと同一アドレスからデータが読み出されている場合は、その読み出し処理が完了するまで受信した新たなライト要求をアービタ１７へ転送しないように制御する。

このような処理を行うことで、アービタ１７はバスインタフェース１１、１２にアクセス要求が到着する順序に関係なく調停を行うことが可能になり、リード要求の処理をライト要求の処理よりも優先することで、情報処理装置としての性能を向上させることができる。

なお、情報処理ユニット１〜３、リードバッファ１３，１４、並びにライトバッファ１５，１６には予め処理の優先度を設定しておいてもよい。その場合、アービタ１７は、共有リソース８に対する複数のアクセス要求を受信すると、予め設定された優先度にしたがって、より優先度の高い情報処理ユニットまたはバッファからのアクセス要求を優先的に許可する。

このような処理を行うことで、例えば、より速い応答を要望する情報処理ユニットがある場合は、その情報処理ユニットからのリード要求に対する応答時間を短縮できる。特に優先度の設定を、ソフトウェア等によって書換え可能なレジスタに格納すれば、より柔軟なシステムが構築できる。

但し、情報処理ユニットや各バッファに優先度を設定する場合も、リードバッファあるいはライトバッファ内のデータと同一のアドレスに対するアクセス要求が発行された場合は、それらのアクセス要求の受け付け順序を維持する必要がある。

例えば、ライト要求に続いて同一アドレスに対するリード要求が発行された場合、ライトバッファ中のデータの共有リソースへの格納が完了しなければ、続いて発行されたリード要求を処理することはできない。その場合、ライトバッファ内のデータの書き込み処理を優先する必要がある。上述したバスインタフェース１１，１２では、ライト要求の優先度がリード要求の優先度よりも低く設定されてしまう。

そこで、同一のアドレスに対するアクセス要求が発行された場合、ライトバッファ１５，１６はライト要求の優先度をリード要求と同等またはそれよりも高く設定してアービタ１７に調停を要求する。アービタ１７は、優先度の高いライト要求を優先的に許可するため、ライトバッファ内のデータが共有リソース８へ優先的に格納される。

なお、バスインタフェース１１，１２は、優先度が低いことでアクセス権を得ることができない状態が続いた場合は、そのアクセス要求を発行した情報処理ユニットやバッファの優先度を上げてもよく、共有リソース８に対応する複数のバスインタフェースのうち、一方のバスインタフェースからのアクセス要求の優先度を上げる等の処理も可能である。

（第２の実施の形態）
次に本発明の情報処理装置の第２の実施の形態について図面を用いて説明する。

第２の実施の形態の情報処理装置は、共有リソースからリードバッファに読み出したデータを、読み出し応答終了後も可能な限り保持しておき、後続するアクセス要求が同一のアドレスに対するリード要求だった場合は、共有リソース８へアクセスすることなくリードバッファから情報処理ユニットへリードデータを送信する構成である。

図６は第２の実施の形態の情報処理装置が備えるリードバッファの構成を示すブロック図である。なお、図６に示すリードバッファは４つのエントリによって構成される例を示している。

図６に示すように、各エントリには、複数ワード（図６では４ワード）のリードデータが格納されるデータ領域５３と、データ領域５３に格納されたリードデータが有効であるか無効であるかを示す状態ビット５２と、リードデータのアドレス（例えば先頭アドレス）を示すアドレスタグ５１と、アドレスタグ５１とアクセス要求から抽出されたアクセス先のアドレスとを比較するアドレス比較器５４とをそれぞれ備えている。

状態コントローラ５５は、アドレス比較器５４による比較結果を収集し、該比較結果に基づき各状態ビット５２をそれぞれ更新する。データ領域５３には共有リソース８から読み出されたリードデータが格納され、データ領域５３内のリードデータはバスインタフェース１１または１２へ送出される。

図７は図６に示したリードバッファの動作を示すタイミングチャートである。

図７に示すように、第２の実施の形態の情報処理装置では、例えば情報処理ユニット１から共有リソース８へリード要求が発行されると、第１の実施の形態と同様に該リード要求はバスインタフェース４を介してマルチレイヤーバス７へ送信され、デコーダ２３による解読結果にしたがってバスインタフェース１１へ転送される。

バスインタフェース１１は、Ｔ２のタイミングでこのアクセス要求を受理し、リード要求であると判断すると、アドレス比較器５４により各エントリのアドレスタグ５１と該リード要求に含まれるアクセス先のアドレスとを比較する。そして、アクセス先のアドレスとアドレスタグ５１の値が同一であり、かつ状態ビット５２が有効を示すエントリがある場合、バスインタフェース１１は、共有リソース８へのアクセスは不要と判断し、Ｔ３のタイミングからリードバッファ内の当該エントリのデータ領域５３で保持するリードデータを情報処理ユニット１へ返送する。

状態コントローラ５５は、共有リソース８からデータを読み出しデータ領域５３に格納したとき当該エントリの状態ビット５２を有効に設定し、アドレス比較器５４により同じアドレスに対するデータの書き込みを検出したとき、当該エントリの状態ビット５２を無効に設定する。また、新たなリード要求を受信したとき、全てのエントリに有効なデータが格納され、かつそれらのアドレスが当該リード要求によるアクセス先のアドレスと異なる場合は、予め設定した手順にしたがって新たなリードデータに置き換えるエントリを決定する。

本実施形態の情報処理装置によれば、情報処理ユニットによるデータ読み出し時の応答速度が改善されるとともに、各バッファと共有リソース間のデータの整合性を保つことが可能となり、共有リソースへのアクセス頻度を低減できる。特に共有リソースから複数ワード単位でデータを読み出し、それらのデータをリードバッファで保持しておけば、主として１ワード単位でデータを読み出す情報処理ユニットによるリソースの利用効率を向上させることができる。また、データをバッファ内に長期に保持することが可能となり、共有リソースへのアクセス頻度を分散させることも可能である。

なお、ライトバッファにおいても、図６に示したリードバッファと同様に、数ワードのライトデータ単位で１つのエントリを構成すれば、１ワード単位の連続したアドレスに対する書き込み処理時に、それらのライトデータをライトバッファで統合することで共有リソースへの書き込み処理を１度にまとめることが可能であり、共有リソースへのアクセス回数を効率的に減らすことができる。

また、情報処理ユニットからのライトデータをライトバッファに保持しておき、共有リソースへの他のアクセス要求が生じないとき、同一のアドレスに対するリード要求が生じたとき、共有リソースが特定の状態でない時まで、実際の共有リソースへの書き込みを遅らせる等、ライト要求の順序にこだわることなく共有リソースへの書き込みを行うことで、共有リソースのアクセス効率をさらに向上させるとともに、データの読み出し応答速度を向上させることも可能である。

（第３の実施の形態）
図８は本発明の情報処理装置の第３の実施の形態の構成を示すブロック図である。

図８に示すように、第３の実施の形態の情報処理装置は、情報処理ユニット１０１〜１０３と共有リソース１０８〜１１０とがマルチレイヤ−バス１０７を介して接続され、共有リソース１０８及び共有リソース１０９に対応して２つのバスインタフェース１１１、１１２を備えた構成である。バスインタフェース１１１、１１２は、リードバッファ１１３，１１４及びライトバッファ１１５，１１６を備え、バスインタフェース１１１、１１２と共有リソース１０８とは第１のアービタ１１７を介して接続され、バスインタフェース１１１、１１２と共有リソース１０９とは第２のアービタ１１８を介して接続される。

マルチレイヤーバス１０７は、情報処理ユニット１０１〜１０３に対応して設けられた入出力インタフェースである入力ステージ１２６〜１２８と、各情報処理ユニット１０１〜１０３から共有リソース１０８〜１１０宛に発行された各種リクエスト（アクセス要求）を調停するマルチプレクサ１２０、１２２と、情報処理ユニット１０１〜１０３から発行されたアクセス要求を送信先の共有リソース１０８〜１１０へ転送するためのデコーダ１２３〜１２５とを有する構成である。

共有リソース１１０は、従来と同様に１つのバスインタフェースを備えた構成であるため、マルチプレクサ１２０、１２２により情報処理ユニット１０１〜１０３からのアクセス要求が調停される。

なお、２つのバスインタフェース１１１、１１２を共有する共有リソース１０８と共有リソース１０９とは、同じ性質の装置である必要はなく、レイテンシやデータ転送速度が異なっていてもよい。その他の構成及び処理は第１及び第２の実施の形態の情報処理装置と同様であるため、その説明は省略する。

本実施形態の情報処理装置によれば、リードバッファ１１３、１１４及びライトバッファ１１５、１１６を増やすことなく、転送速度が異なる複数の共有リソース１０８、１０９についても第１及び第２の実施の形態と同様の効果を得ることができる。

例えばＳＯＣ等の外部に接続するメモリコントローラと内蔵メモリを統合的に扱い、データ転送速度の差を吸収すれば、本発明の効果を複数のメモリリソースに対して得ることができる。

（第４の実施の形態）
図９は本発明の情報処理装置の第４の実施の形態の構成を示すブロック図である。

図９に示すように、第４の実施の形態の情報処理装置は、情報処理ユニット２０１〜２０３と共有リソース２０８、２０９とを備え、情報処理ユニット２０２，２０３と共有リソース２０８、２０９とがマルチレイヤ−バス２０７を介して接続された構成である。

共有リソース１０８は、対応する２つのバスインタフェース２１１、２１２を備え、情報処理ユニット２０１とバスインタフェース２１１とが専用のバス２３０で接続された構成である。

バスインタフェース２１２はマルチレイヤーバス２０７を介して情報処理ユニット２０２、２０３とそれぞれ接続され、共有リソース２０９に対応するバスインタフェース２１８はマルチレイヤーバス２０７を介して情報処理ユニット２０２、２０３とそれぞれ接続される。

マルチレイヤーバス２０７は、情報処理ユニット２０２、２０３に対応して設けられた入出力インタフェースである入力ステージ２２７、２２８と、各情報処理ユニット２０２、２０３から共有リソース２０８、２０９宛に発行された各種リクエスト（アクセス要求）を調停するマルチプレクサ２２０、２２１と、情報処理ユニット２０２、２０３から発行されたアクセス要求を送信先の共有リソース２０８、２０９へ転送するためのデコーダ２２４、２２５とを有する構成である。

情報処理ユニット２０１とバスインタフェース２１１とを接続するバス２３０は、マルチレイヤーバス２０７に準拠するものではなく、異なるバス規約に基づくものが用いられる。すなわち、共有リソース２０８には、異なる規約の２つのバスが接続された構成となる。その他の構成及び処理は第１及び第２の実施の形態の情報処理装置と同様であるため、その説明は省略する。

本実施形態の情報処理装置では、リードバッファ２１３及び２１４、ライトバッファ２１５及び２１６、並びにアービタ２１７を第１及び第２の実施の形態と同様の構成とし、さらに同様の処理を実行すれば、異なる規約の２つのバスから共有リソース２０８へのアクセスを可能にしつつ、第１及び第２の実施の形態と同様の効果を得ることができる。これにより既存の２種類以上のＡＳＩＣなどを１チップに集積するような場合に、効率的にリソースの共有化が実現できる。

また、このような構成では、例えば読み出し専用インタフェースや書き込み専用インタフェース、排他処理アクセスをサポートしないインタフェース等、機能を削ったインタフェースを用意できるため、情報処理装置のコストを低減できる。

Claims (17)

1. 複数の情報処理ユニットと、
   前記情報処理ユニットからのアクセス要求に応じて返送するためのリードデータを一時的に保持するリードバッファ、および前記情報処理ユニットから受信したライトデータを一時的に保持するライトバッファをそれぞれ有する複数のバスインタフェースと、前記情報処理ユニットから発行された複数のアクセス要求を調停するアービタとを有し、前記情報処理ユニットからアクセスされる共有リソースと、
   複数のバスインタフェースに対して個々に独立してデータの入出力が可能な、前記情報処理ユニットのバスインタフェースと前記共有リソースのバスインタフェースを複数対複数で相互に接続するマルチレイヤーバスと、
   を有する情報処理装置。
2. 前記リードバッファは、
   前記共有リソースの処理速度で前記共有リソースから前記リードデータを格納し、前記マルチレイヤーバスの伝送速度で前記情報処理ユニットへ該リードデータを送信し、
   前記ライトバッファは、
   前記マルチレイヤーバスの伝送速度で前記情報処理ユニットから受信した前記ライトデータを格納し、前記共有リソースの処理速度で該ライトデータを前記共有リソースへ書き込む、請求項１記載の情報処理装置。
3. 前記共有リソースのバスインタフェースは、
   前記情報処理ユニットからのアクセス要求を受信すると、該アクセス要求によるアクセス先のアドレスと前記リードバッファ及び前記ライトバッファで既に保持されたデータに対応するアクセス先のアドレスを比較し、
   前記リードバッファ及び前記ライトバッファで保持されたデータに対応するアクセス先のアドレスと同じアドレスに対するアクセス要求である場合は、前記共有リソースから該リードバッファへの前記リードデータの格納が完了した後、または該ライトバッファで保持されたライトデータの前記共有リソースへの書き込みが完了した後に前記アービタに該アクセス要求を送信するアドレス比較器をさらに有する、請求項１記載の情報処理装置。
4. 前記情報処理ユニット、前記リードバッファ、または前記ライトバッファに予め所定の優先度が付与され、
   前記アービタは、
   前記共有リソースに対する複数のアクセス要求を受信すると、該優先度にしたがった順に該アクセス要求を許可する、請求項１記載の情報処理装置。
5. 前記共有リソースのバスインタフェースは、
   前記リードバッファ及び前記ライトバッファで保持されたデータに対応するアクセス先のアドレスと同じアドレスに対するアクセス要求を受信した場合、該リードバッファへの前記共有リソースからの前記リードデータの読み出し処理または該ライトバッファから前記共有リソースへの前記ライトデータの書き込み処理の優先度を上げる、請求項４記載の情報処理装置。
6. 前記リードバッファは、
   前記情報処理ユニットからのアクセス要求を受信すると、該アクセス要求によるアクセス先のアドレスと前記リードバッファで既に保持されたリードデータに対応するアクセス先のアドレスを比較し、
   前記リードバッファで保持されたリードデータに対応するアクセス先のアドレスと同じアドレスに対するアクセス要求である場合は、前記共有リソースから該リードデータを読み出すことなく、前記リードバッファで保持されたリードデータを該情報処理ユニットへ返送する、請求項１記載の情報処理装置。
7. 前記ライトバッファは、
   前記情報処理ユニットからのアクセス要求を受信すると、該アクセス要求によるアクセス先のアドレスと前記ライトバッファで既に保持されたライトデータに対応するアクセス先のアドレスを比較し、
   前記ライトバッファで保持されたライトデータに対応するアクセス先のアドレスと連続するアドレスに対するアクセス要求である場合は、前記ライトバッファで保持されたライトデータと該情報処理ユニットから受信したライトデータをまとめて共有リソースへ格納する、請求項１記載の情報処理装置。
8. 前記共有リソースの複数のバスインタフェースが、
   複数の共有リソースに対応して共通に設けられた、請求項１記載の情報処理装置。
9. 前記共有リソースの複数のバスインタフェースは、
   それぞれが異なるバス規約である、請求項１記載の情報処理装置。
10. 前記共有リソースがＳＤＲＡＭによる主記憶であり、
    前記アービタは、前記ＳＤＲＡＭの状態を把握しており、該状態に基づいて、優先的に選択するアクセス要求を決定する、請求項１記載の情報処理装置。
11. 前記アービタは、発行されてからの調停回数が所定回数を経過したアクセス要求については前記ＳＤＲＡＭの状態に関わらず優先的に選択する、請求項１０記載の情報処理装置。
12. 単一の共有リソースに備えられた複数の前記バスインタフェースは、アクセス要求があると、該アクセス要求を発行した情報処理ユニットを特定し、
    前記単一の共有リソースに備えられた前記アービタは、前記情報処理ユニットの各々に対して優先度を予め定めており、前記バスインタフェースで特定された情報処理ユニットの前記優先度にしたがって調停を行う、請求項１記載の情報処理装置。
13. 前記共有リソースにアクセスを行う情報処理ユニットが、他の情報処理ユニットによる該共有リソースに対するアクセスの禁止をすると、
    禁止をした前記情報処理ユニットからのアクセスに用いられるバスインタフェースに加えて、該バスインタフェースと同じ前記共有リソースに備えられた他のバスインタフェースによる前記共有リソースへのアクセスが禁止される、請求項１記載の情報処理装置。
14. 他の情報処理ユニットによる該共有リソースに対するアクセスを禁止するための機能を、単一の共有リソースに備えられた複数の前記バスインタフェースのうちいずれか１つだけに持たせた、請求項１３記載の情報処理装置。
15. 前記共有リソースにアクセスを行う情報処理ユニットが他の情報処理ユニットによる該共有リソースの特定アドレス領域に対するアクセスの禁止をすると、
    禁止をした前記情報処理ユニットからのアクセスに用いられるバスインタフェースに加えて、該バスインタフェースと同じ前記共有リソースに備えられた他のバスインタフェースによる前記共有リソースの前記特定アドレス領域に対するアクセスが禁止される、請求項１記載の情報処理装置。
16. 他の情報処理ユニットによる該共有リソースに対するアクセスを禁止するための機能を、単一の共有リソースに備えられた複数の前記バスインタフェースのうちいずれか１つだけに持たせた、請求項１５記載の情報処理装置。
17. 前記リードバッファは、該リードバッファを介さずにデータを転送するスルーパスを備え、所定のサイクルにおいて、前記共有リソースからのデータを前記スルーパスによって前記情報処理ユニットに応答する、請求項１記載の情報処理装置。

Images