JPH04239350A - 情報処理装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報処理装置に関し、
特に、その主記憶装置におけるメモリアクセス制御の技
術に関するものである。

【０００２】

【従来の技術】従来のメモリアクセス制御の技術として
は、特開平２−１０４４号公報（「メモリアクセス制御
方式」）記載の技術が知られている。

【０００３】この従来技術は、メモリアクセスのリクエ
スト発生装置と主記憶制御装置がバス形式で結合した情
報処理装置におけるメモリアクセス方式である。

【０００４】この方式によれば、受付けたリクエストを
、メモリアクセス可能となるまで、リクエストバッファ
にキューイングしておくことにより、一つのリクエスト
がバス権を得てメモリアクセスを行っている間のバス未
使用期間に、次のリクエストの受付を可能としている。

【０００５】このようにすることで、リクエストバッフ
ァを用いて、メモリアクセス時間ピッチでの、メモリア
クセス要求の処理を可能とし、リクエスト発生装置と主
記憶制御装置間のバススループットを向上している。

【０００６】

【発明が解決しようとする課題】しかしながら、前記従
来技術によれば、連続した３以上のリクエストを受け付
けることはできない。

【０００７】そのため、３番目以降のリクエストは常に
受け付けられず、メモリアクセス時間が長い情報処理装
置においては、充分なリクエスト発生装置と主記憶制御
装置間のバススループットの向上を図ることができなか
った。

【０００８】そこで、本発明は、連続して発生した３以
上のリクエストを可能な限り受付け、リクエスト発生元
装置と主記憶制御装置間のバススループットの向上を図
ることのできる情報処理装置を提供することを目的とす
る。

【０００９】

【課題を解決するための手段】前記目的達成のために、
本発明は、リクエストバッファを備え、かつ、受け付け
た主記憶装置へのアクセス要求を一旦リクエストバッフ
ァに格納し、その後に格納したアクセス要求をリクエス
トバッファより取り出して実行する主記憶装置と、主記
憶装置へアクセス要求を発行する１以上の命令処理装置
と、前記命令処理装置および主記憶装置を結合するシス
テムバスとを、少なくとも備えた情報処理装置であって
、前記主記憶装置は、受け付けた主記憶装置へのアクセ
ス要求を、複数格納可能な前記リクエストバッファと、
格納した複数のアクセス要求を、順次、リクエストバッ
ファより取り出して実行する実行手段と、アクセス要求
を受け付けた時点で、受け付けたアクセス要求に関する
情報に応じて、当該アクセス要求を前記リクエストバッ
ファへ格納した場合のリクエストバッファ内のアクセス
要求数の増加量を予測する予測手段と、予測手段が予測
した増加量とリクエストバッファ現記憶量とを用いて次
のアクセス要求の受付けの可否を判定する判定手段と、
を有することを特徴とする情報処理装置を提供する。

【００１０】なお、前記判定手段は、前記予測手段が予
測した増加量とリクエストバッファ現記憶量とを用い、
次のアクセス要求の種別に応じて、該アクセス要求の受
付けの可否の判定を行うようにしても良い。

【００１１】

【作用】本発明に係る情報処理装置によれば、主記憶装
置のリクエストバッファは、複数のアクセス要求を格納
可能であって、実行手段がリクエストバッファに格納さ
れた複数のアクセス要求を、順次、取り出して実行する
。このため、リクエストバッファの記憶残量が充分に存
在する場合には連続して発生した３以上のリクエストで
も受付、実行することができる。

【００１２】また、この場合、リクエストバッファの記
憶容量を超えて、アクセス要求を受け付けないように、
受付けを抑止する必要があるが、本発明に係る情報処理
装置によれば、アクセス要求を受け付けた時点で、予測
手段は、受け付けたアクセス要求に関する情報に応じて
、当該アクセス要求を前記リクエストバッファへ格納し
た場合のリクエストバッファ内のアクセス要求数の増加
量を予測し、判定手段は、予測手段が予測した増加量と
リクエストバッファ現記憶量とを用いて、望ましくは、
その種別に応じて、次のアクセス要求の受付けの可否を
判定し、受付け可能であれば、アクセス要求を受け付け
る。したがい、受付からリクエストバッファへのアクセ
ス要求の格納迄の期間においても、リクエストバッファ
の記憶容量を超えたアクセス要求の受け付けを防止しつ
つも、反面、過剰な、受付け抑止を防止することができ
、連続して発生した３以上のリクエストを可能な限り受
付けることができる。

【００１３】

【実施例】以下、本発明に係る情報処理装置の一実施例
を説明する。

【００１４】本実施例において、情報処理装置はマルチ
プロセッサ構成を採用しているものとして説明する。

【００１５】まず、図７に本実施例に係る情報処理装置
の基本構成を示す。

【００１６】すなわち、図示するように、本実施例に係
る情報処理装置においては、２個の命令処理装置（ＩＰ
０）１−ａ、（ＩＰ１）１−ｂ、２個の入出力処理装置
（ＩＯＰ０）１−ｃ、（ＩＯＰ１）１−ｄ、主記憶制御
装置（ＳＣＵ）１００および１個のＲＡＭ（ＲＡＭ）１
０を、Ｓバス２００に結合することにより、基本処理装
置（ＢＰＵ）１０が構成されている。

【００１７】また、本実施例においては、ＳＣＵ１００
の内部にバス権仲裁を行なうバスアービタ３００を設け
る。

【００１８】また、ＢＰＵ１０の主記憶であるＲＡＭ１
０は、４ウェイ・インタリーブ構成で連続アドレス番地
付けされている。

【００１９】命令処理装置（ＩＰ０）１−ａと（ＩＰ１
）１−ｂ、入出力処理装置（ＩＯＰ０）１−ｃと、（Ｉ
ＯＰ１）１−ｄはＳバス２００のバス権が必要になると
、バス権要求信号（ＢＵＳＲＥＱ）１−ａ〜１−ｄをバ
スアービタ３００に送る。

【００２０】バスアービタ３００は、バスの空きを待ち
、バス空きサイクルに対応した時点で最も優先順位の高
いリクエストを受付ける。バス権を得たリクエスタは、
Ｓバス２００を用いて、リクエスト（アドレス、ライト
データ、リードライトの別等の詳細情報）を送出する。

【００２１】次に、図２に前記ＳＣＵ１００の構成の一
例を示す。

【００２２】図示するように、メモリアクセス制御部７
００−０〜３およびＲＡＭ１０−０〜３は、４つ存在し
、４Ｗａｙインタリーヴとして並列に動作する。

【００２３】本実施例におけるＳＣＵ１００は、バス権
仲裁を行なうバスアービタ３００、Ｓバス２００とのイ
ンタフェースを行なうバスインタフェース４００、各ウ
ェイ毎のリクエストのバッファであるバッファ管理部６
００−０〜６００−３、および各ウェイ毎のメモリアク
セスを行なうメモリアクセス制御部７００−０〜７００
−３からなり、望ましくは１チップのＬＳＩとして構成
する。

【００２４】次に、図２と図３を用いて、ＳＣＵにおけ
るリクエストの受付けからバッファ管理部６００−０〜
３へのリクエストセットまでの動作について説明する。

【００２５】図３は、リクエストを発行するリクエスタ
（ＩＰまたはＩＰＯ）とＳＣＵ間のバスインタフェ−ス
を模式的に示したものである。

【００２６】バスアービタ３００は、バス権要求信号（
ＢＵＳＲＥＱｉ）２−ｉを受け、バスの使用状態、バッ
ファの状態、リクエストの優先順位に応じて、バス権要
求を受付け、バス権要求受付信号（ＢＵＳＡＣＰｉ）４
−ｉをリクエスタ１−ｉに返す。

【００２７】バス権が受付けられると、リクエスタ１−
ｉは、Ｓバス２００を使用して、リクエスト詳細情報群
５により、リクエスト詳細情報を、ＳＣＵ１００のバス
インタフェース部４００に転送する。

【００２８】バスインタフェース部４００は、リクエス
ト詳細情報に従って、各バッファ管理部６００−ｉに、
アドレス等の詳細情報６２０−ｉ（以後これをリクエス
トと呼ぶ）と、それらのセット信号であるＱＳＥＴ−ｉ
（６３０−ｉ）を送る。転送されるバッファ番号、セッ
トするタイミングはリクエスト種によって異なる。

【００２９】次に、図４にバッファ管理部６００−ｉ（
ｉ＝０−３）の構成を示す。

【００３０】本実施例においては、バッファ６４０−ｊ
（ｊ＝０−３）の段数を４段とする。　　そしてインポ
インタＱｉＰ６１０の示す番号のバッファに、バスイン
タフェース部４００からの情報がＱＳＥＴ−ｉ（６３０
−ｉ）によってセットする。

【００３１】アウトポインターＱＯＰ６２０は、次にメ
モリアクセス制御部７００−ｉに転送されるリクエスト
が存在するバッファ番号を示す。ＱｉＰ６１０−ｉ（ｉ
＝０−３）の値からＱＯＰ６２０−ｉ（ｉ＝０−３）の
値を減じることによりバッファ内部に存在するリクエス
ト数を示す信号ＱＣＮＴ−ｉ（１６−ｉ、ｉ＝０−３）
を生成する。

【００３２】次に、受付けるリクエストの種類をリクエ
ストＡとリクエストＢの２つに限定し、リクエストバッ
ファのセット完了状態での増加分の予測と、バッファの
あふれ抑止について、図５と、図６、図１を用いて説明
する。

【００３３】図５は、リクエストの受付けから、バッフ
ァ管理部までのセットまでを示すタイミング図である。 リクエストタイプＡの場合、バッファ管理部０からバッ
ファ管理部３までに、１個のリクエストが一定時間毎に
セットされる。タイプＡのリクエストには、たとえば、
データ分割転送型のライトリクエスト等がある。

【００３４】リクエストタイプＢの場合、全てのバッフ
ァ管理部に、リクエストを２個同じタイミングでセット
する。タイプＢのリクエストには、たとえば、連続アド
レスでのリ−ドリクエスト等がある。

【００３５】以上の様にリクエスト受付けから、バッフ
ァ管理部６００−ｉへリクエストをセットするまでの間
、バッファ管理部６００−ｉのリクエスト数が不確定で
ある。　　ところで、今、４段のバッファの中に一つの
リクエストがあり、メモリアクセス中だと仮定すると、
この状態でリクエストを連続して４つ受付けるとバッフ
ァがあふれるという問題が生ずる。このように、受付け
たリクエストによりリクエストバッファがあふれてしま
う場合には、リクエストの受付を抑止しなければならな
い。しかし、リクエスト受付け抑止を過剰に行えば、バ
ススループットの低下を招く。

【００３６】一つの最も単純なリクエストバッファあふ
れ抑止方法としては、リクエストの受付けからバッファ
へのセットまでの期間は、次のリクエストを受付けず、
リクエストバッファへのリクエストセットが完了すると
、バッファ中に存在するメモリアクセス待ちリクエスト
数に基づき、次のリクエスト受付けの可、不可を判定す
るという方法がある。

【００３７】しかし、リクエストバッファが４段あり、
メモリアクセス待ちリクエストが１つの場合、リクエス
トは、あと３つまで、受付けることが可能であり、リク
エストセットまでの期間中にリクエストを受付けないこ
とは過剰抑止であり、バススループットの低下を招く。

【００３８】そこで、本実施例においては、この期間に
おいてもリクエスト詳細情報に基づきリクエストバッフ
ァのセット完了状態での増加分の予測を行い、それによ
り次のリクエスト受付けでリクエストバッファがあふる
か否かを判定しリクエスト受付けの可、不可を行うもの
である。

【００３９】今、リクエストＡを受付けたと仮定し、バ
ッファのセット完了状態での増加分の予測、バッファの
あふれ抑止を考慮したリクエストの受付け判定がいかに
行われるかを、図１を用いて説明する。

【００４０】図１は、バスインタフェ−ス４００、バス
ア−ビタ３００、バッファ管理部６００の、バッファの
セット完了状態での増加分の予測、バッファのあふれ抑
止を考慮したリクエストの受付け判定に関する部位を抜
き出して示したものである。図示するように、バスイン
タフェ−ス４００は補正信号発生器４３０を備え、バス
ア−ビタ３００は、リクエスト受付回路３０３、リクエ
スト数補正回路３６０−ｉ（ｉ＝０−３）、デコ−ダ３
８０−ｉ（ｉ＝０−３）を備える。また、リクエスト数
補正回路３６０−ｉはプラス１補正器３９０−ｉ（ｉ＝
０−３）とプラス２補正器３９５−ｉ（ｉ＝０−３）を
備える。

【００４１】リクエストタイプＡを受付け、リクエスト
詳細情報が、バスインタフェース部に送られてくると、
それに基づいてリクエストを、図５（ａ）のごとく、各
バッファ管理部にリクエストを一個セットするが、それ
によって、バッファ管理部内のリクエスト数が１つ増え
る。

【００４２】そこで、バスインタフェース部は、リクエ
ストタイプＡを受付けた時点でバッファへのセット完了
状態での増加分の予測を行い、バッファ管理部内のリク
エスト数を示す信号ＱＣＮＴ−ｉ（１６−ｉ）にプラス
１の補正を行う信号Ｑ１ＲＳＶ−ｉ（４１０−ｉ、ｉ＝
０−３）を図６（ａ）のごとく各バッファ管理部６００
−ｉにリクエストがセットされるまで発行する。

【００４３】Ｑ１ＲＳＶ−ｉは、ＱＣＮＴ−ｉ（１６−
ｉ）と供に、バスアービタ（３００）に送られる。

【００４４】次に、前記２つの信号によりバッファのあ
ふれ抑止とリクエスト受付けの判定が、いかに行われる
かを順を追って説明する。

【００４５】Ｑ１ＲＳＶ−ｉとＱＣＮＴ−ｉは、共にバ
スアービタ（３００）に送られ、ＱＣＮＴ−ｉは、リク
エスト数補正回路でＱ１ＲＳＶ−ｉによりプラス１の補
正を受け、ＱＣＮＴ−ｉ（３１０−ｉ、ｉ＝０−３）が
つくられる。

【００４６】この信号はデコードされ、バッファ管理部
（６００−ｉ）内のリクエスト数を示す信号、Ｑ０ＦＲ
ＥＥ−ｉ（ｉ＝０−３）、Ｑ１ＦＲＥＥ−ｉ（ｉ＝０−
３）の２本の信号が生成される。

【００４７】Ｑ０ＦＲＥＥ−ｉ（ｉ＝０−３）は、各バ
ッファ管理部内にリクエストが、４個あることを示して
いる。Ｑ１ＦＲＥＥ−ｉ（ｉ＝０−３）は、各バッファ
管理部内にリクエストが、３個あることを示している。

【００４８】バッファのあふれを抑止するためには、次
にリクエストタイプＡを受付けたとき、各バッファ管理
部に１段以上の空きが、またリクエストタイプＢを受付
けたとき、各バッファ管理部は２段以上の空きが存在し
なければならない。

【００４９】したがって、ＢＵＳＲＥＱ−ｉのデコード
結果であり、リクエストタイプＡを示す信号ＲＥＱＴＹ
ＰＡ（３０１）はＱ０ＦＲＥＥ−０（３２０−０）、Ｑ
０ＦＲＥＥ−１（３２０−１）、Ｑ０ＦＲＥＥ−２（３
２０−２）、Ｑ０ＦＲＥＥ−３（３２０−３）の４本の
信号の論理和Ｑ０ＦＲＥＥ（３３０）で抑止され、リク
エスト受付回路３０３に入る。

【００５０】リクエストタイプＢを示す信号ＲＥＱＴＹ
ＰＢ（３０２）は、Ｑ０ＦＲＥＥ信号（３３０）と、Ｑ
１ＦＲＥＥ−０（３４０−０）、Ｑ１ＦＲＥＥ−１（３
４０−１）、Ｑ１ＦＲＥＥ−２（３４０−２）、Ｑ１Ｆ
ＲＥＥ−３（３４０−３）の論理和がとられた信号Ｑ１
ＦＲＥＥ（３５０）によって抑止され、リクエスト受付
回路３０３に入る。

【００５１】以上が、リクエストＡを受付けたときのリ
クエストセット動作中における、バッファのあふれを抑
止した、次リクエストの受付け判定であるが、リクエス
トＢを受付けたときは、同様にバスインタフェース４０
０において、バッファのセット完了状態の増分をリクエ
スト詳細情報により予測し、バッファ管理部内のリクエ
スト数を示す信号ＱＣＮＴ−ｉにプラス２の補正を行う
信号Ｑ２ＲＳＶ−ｉ（４２０−ｉ、ｉ＝０−３）を、図
６（ｂ）のごとく一つめのリクエストが、各バッファ管
理部にセットされるまで発行し、ＱＣＮＴ−ｉにプラス
２の補正を行い、１回目のリクエストセットから２回目
のリクエストセットまでの間、ＱＣＮＴ−ｉにプラス１
の補正を行う信号を発行し、ＱＣＮＴ−ｉにプラス１の
補正を行う。補正をうけた信号はデコードされ、リクエ
ストＡの受付けの場合と同様にして、次リクエストの受
付判定に用いられる。

【００５２】以上が、リクエストのタイプが、リクエス
トＡ、リクエストＢの２つある場合の実施例であるが、
本発明は、これに限ったものでなく、リクエスト詳細情
報により、リクエストバッファのセットの方式が判れば
、任意のリクエストに対し、リクエストバッファのセッ
ト完了状態を予測でき、リクエストバッファ中のリクエ
スト数を、リクエストバッファのセット完了状態でのリ
クエスト数に補正することにより、リクエストセット中
においても、バッファのあふれをおこすことなく、リク
エストの受付判定を行うことができる。

【００５３】なお、本実施例においては、各デコ−ダ３
４０−ｉのデコ−ド結果の論理和により、単純にリクエ
ストを抑止する方式を採用したが、各デコ−ダ３４０−
ｉのデコ−ド結果と、リクエストを受け付けた場合の各
バッファへのセットタイミングとを考慮して、バッファ
のあふれをおこすことがなければリクエストを受け付け
るようにしてもよい。

【００５４】すなわち、本実施例によればメモリアクセ
スのリクエストを発生するリクエスト発生装置とバス形
式で結合しており、かつ、リクエスト連続受付を可能と
するためのリクエストバッファを内部に有する主記憶制
御装置において、受付けたリクエストのバッファセット
完了状態を予測することにより、リクエストセット動作
中においても次のリクエストの受付の可、不可を判定す
ることができるので、リクエストの受付のピッチをはや
めることができ、バススループットが向上する。また、
リクエストタイプが複数ある場合には、前記リクエスト
受付の判定を、リクエスト種毎に行うことができるので
、リクエストの受付可能なケースを増やすことができ、
これによってもバススループットが向上できる。

【００５５】

【発明の効果】以上説明してきたように、本発明によれ
ば、連続して発生した３以上のリクエストを可能な限り
受付け、リクエスト発生元装置と主記憶制御装置間のバ
ススループットの向上を図ることのできる情報処理装置
を提供することができる。

【図面の簡単な説明】

【図１】バスインタフェ−ス、バスア−ビタ、バッファ
管理部の特徴部位の構成を示すブロック図である。

【図２】主記憶制御装置の構成を示すブロック図である
。

【図３】リクエスタと主記憶制御装置のバスインタフェ
ースを示すブロック図である。

【図４】バッファ管理部の構成を示すブロック図である
。

【図５】リクエスト受付けからバッファ管理部へのリク
エストセット動作を示すタイムチャートである。

【図６】バッファ管理部内リクエスト数の補正信号の発
行動作を示すタイミングチャ−トである。

【図７】本発明の一実施例に係る情報処理装置の構成を
示すブロック図である。

【符号の説明】

１−ａ、１−ｂ　　　　命令処理装置（ＩＰ）１−ｃ、
１−ｄ　　　　入出力処理装置（ＩＯＰ）２−ｊ（ｊ＝
ａ、ｂ、ｃ、ｄ）　　　　バスリクエスト４−ｊ（ｊ＝
ａ、ｂ、ｃ、ｄ）　　　　バスアクセプト５　　　　リ
クエスト詳細情報群 １４　　　　ＲＡＭ（ＲＡＭ） １６−ｉ（ｉ＝０−３）　　　　バッファ内リクエスト
数１００　　　　主記憶制御装置（ＳＣＵ）２００　　
　　Ｓバス ３００　　　　バスアービタ ３０３　　　　リクエスト受付回路 ３１０−ｉ（ｉ＝０−３）　　　　補正されたバッファ
内リクエスト数 ３６０−ｉ　　　　リクエスト数補正回路４００　　　
　バスインタフェ−ス ４１０−ｉ（ｉ＝０−３）　　　　バッファ内リクエス
ト数プラス１補正信号 ４２０−ｉ（ｉ＝０−３）　　　　バッファ内リクエス
トプラス２補正信号 ４３０　　　　補正信号発生器 ６００−ｉ　　　　バッファ管理部 ７００　　　　メモリアクセス制御

Claims (2)

【特許請求の範囲】
1. 【請求項１】　　リクエストバッファを備え、かつ、受
   け付けた主記憶装置へのアクセス要求を一旦リクエスト
   バッファに格納し、その後に格納したアクセス要求をリ
   クエストバッファより取り出して実行する主記憶装置と
   、主記憶装置へアクセス要求を発行する１以上の命令処
   理装置と、前記命令処理装置および主記憶装置を結合す
   るシステムバスとを、少なくとも備えた情報処理装置で
   あって、前記主記憶装置は、受け付けた主記憶装置への
   アクセス要求を、複数格納可能な前記リクエストバッフ
   ァと、格納した複数のアクセス要求を、順次、リクエス
   トバッファより取り出して実行する実行手段と、アクセ
   ス要求を受け付けた時点で、受け付けたアクセス要求に
   関する情報に応じて、当該アクセス要求を前記リクエス
   トバッファへ格納した場合のリクエストバッファ内のア
   クセス要求数の増加量を予測する予測手段と、予測手段
   が予測した増加量とリクエストバッファ現記憶量とを用
   いて次のアクセス要求の受付けの可否を判定する判定手
   段と、を有することを特徴とする情報処理装置。
2. 【請求項２】　　請求項１記載の情報処理装置であって
   、前記判定手段は、前記予測手段が予測した増加量とリ
   クエストバッファ現記憶量とを用い、次のアクセス要求
   の種別に応じて、該アクセス要求の受付けの可否の判定
   を行うことを特徴とする情報処理装置。