(57)【要約】【課題】リードリクエストの発行者に負荷を与えることなく、かつ、装置としての汎用性を維持するとともに、受信バッファのオーバーフローを回避したメモリリードアクセスを可能とするインタフェースコントローラ、リードアクセス制御方法及び該インタフェースコントローラを備える情報処理装置を提供することである。【解決手段】データを記憶した記憶装置１１０へリードリクエストを行うリードリクエスト装置１０１、１０２に接続されたインタフェースコントローラ１０４であって、前記リードリクエスト装置１０１、１０２から送信されたリードリクエストに対する前記記憶装置１１０のリードレスポンスを保持する保持手段２０６と、前記保持手段２０６の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置１０１、１０２にリードリクエスト許可を行う制御手段２０２と、を備える。【選択図】図２
2008146459.tif 000002
【特許請求の範囲】
【請求項１】
データを記憶した記憶装置へリードリクエストを行うリードリクエスト装置に接続されたインタフェースコントローラであって、
前記リードリクエスト装置から送信されたリードリクエストに対する前記記憶装置のリードレスポンスを保持する保持手段と、
前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置にリードリクエスト許可を行う制御手段と、を備えたことを特徴とするインタフェースコントローラ。
【請求項２】
請求項１に記載のインタフェースコントローラであって、
前記制御手段は、発行済リードリクエストのリードリクエストサイズの合計値を蓄積する第１蓄積手段と、処理済リードレスポンスのリードレスポンスサイズの合計値を蓄積する第２蓄積手段と、を含み、該第１蓄積手段に蓄積された合計値と該第２蓄積手段に蓄積された合計値とに基づいて、前記リードリクエスト装置にリードリクエスト許可を行うことを特徴とするインタフェースコントローラ。
【請求項３】
請求項２に記載のインタフェースコントローラであって、
前記制御手段は、さらに、前記リードリクエスト装置から送信されたリードリクエストのリードリクエストサイズと前記第１蓄積手段に蓄積された合計値との和を算出する第１算出手段と、前記保持手段の容量と前記第２蓄積手段に蓄積された合計値との和を算出する第２算出手段と、該第１算出手段の算出結果と該第２算出手段の算出結果とを比較する比較手段と、を含み、該比較手段の比較結果に基づいて、前記リードリクエスト装置にリードリクエスト許可を行うことを特徴とするインタフェースコントローラ。
【請求項４】
データを記憶した記憶装置に対するリードリクエスト装置のリードリクエストを制御するリードアクセス制御方法であって、
前記リードリクエスト装置から送信されたリードリクエストに対する前記記憶装置のリードレスポンスを保持手段に保持し、
前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置にリードリクエスト許可を行うことを特徴とするリードアクセス制御方法。
【請求項５】
データを記憶する記憶装置と接続可能な情報処理装置であって、
リードリクエスト許可に応じて前記記憶装置に対するリードリクエストを行うリードリクエスト装置と、
前記リードリクエストに対する前記記憶装置のリードレスポンスを保持する保持手段と、前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置に前記リードリクエスト許可を行う制御手段と、を含むインタフェースコントローラと、を備えたことを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶装置との通信を制御するインタフェースコントローラ、リードアクセス制御方法及び該インタフェースコントローラを備える情報処理装置に関し、特に、連続でリードリクエストを発行するインタフェースコントローラ、連続でリードリクエストを発行するリードアクセス制御方法及び該インタフェースコントローラを備える情報処理装置に関する。
【背景技術】
【０００２】
２つのデバイスを接続するためのインタフェースとしてＰＣＩ  Ｅｘｐｒｅｓｓが知られている。ＰＣＩ  Ｅｘｐｒｅｓｓにおける通信は、メモリを含む相手側のデバイスに対してメモリに記憶されたデータを読み出すメモリリードのためのメモリアクセス（メモリリードアクセス）を行う場合に、メモリリードを要求するパケット（リードリクエスト）を送信し、相手側のデバイスから返信されるリードレスポンスを受信するものである。受信されたリードレスポンスは、受信バッファに保存された後に上位のシステムバスへ送信される。
【０００３】
リードレスポンスを受信バッファに保存するとともに、パフォーマンスを向上させるための方法として、リードリクエストの発行者（例えば、ＣＰＵ、ＤＭＡ等）が受信バッファのサイズを考慮して連続発行する方法があった。この場合には、リードレスポンスを受信する受信バッファにオーバーフローが発生しないようにするために、リードリクエストの発行者が受信バッファのサイズや状況を伝えるサイドバンド信号に基づいてメモリリードアクセスにおけるデータ送信量を算出し、データ送信量を制御する必要があった。
【０００４】
しかし、データ送信量を算出する際に、リードリクエストの発行者に負荷が発生していた。さらに、サイドバンド信号を送受信するためのシステムバスが必要となり、装置としての汎用性を低減していた。
【特許文献１】特開２００５−３２２３０８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、リードリクエストの発行者に負荷を与えることなく、かつ、装置としての汎用性を維持するとともに、受信バッファのオーバーフローを回避したメモリリードアクセスを可能とするインタフェースコントローラ、リードアクセス制御方法及び該インタフェースコントローラを備える情報処理装置を提供することである。
【課題を解決するための手段】
【０００６】
本発明の第１態様によれば、データを記憶した記憶装置へリードリクエストを行うリードリクエスト装置に接続されたインタフェースコントローラであって、前記リードリクエスト装置から送信されたリードリクエストに対する前記記憶装置のリードレスポンスを保持する保持手段と、前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置にリードリクエスト許可を行う制御手段と、を備えたことを特徴とするインタフェースコントローラが提供される。
【０００７】
本発明の第２態様によれば、データを記憶した記憶装置に対するリードリクエスト装置のリードリクエストを制御するリードアクセス制御方法であって、前記リードリクエスト装置から送信されたリードリクエストに対する前記記憶装置のリードレスポンスを保持手段に保持し、前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置にリードリクエスト許可を行うことを特徴とするリードアクセス制御方法が提供される。
【０００８】
本発明の第３態様によれば、データを記憶する記憶装置と接続可能な情報処理装置であって、リードリクエスト許可に応じて前記記憶装置に対するリードリクエストを行うリードリクエスト装置と、前記リードリクエストに対する前記記憶装置のリードレスポンスを保持する保持手段と、前記保持手段の容量、リードリクエストサイズ及びリードレスポンスサイズに基づいて、前記リードリクエスト装置に前記リードリクエスト許可を行う制御手段と、を含むインタフェースコントローラと、を備えたことを特徴とする情報処理装置が提供される。
【発明の効果】
【０００９】
本発明によれば、リードリクエストの発行者に負荷を与えることなく、かつ、装置としての汎用性を維持するとともに、受信バッファのオーバーフローを回避したメモリリードアクセスが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施例について図面を参照して説明する。なお、以下の実施例は本発明の実施の一形態であって、本発明の範囲を限定するものではない。
【００１１】
図１は、本発明の実施例に係る情報処理システムの構成を示すブロック図である。
【００１２】
本発明の実施例に係る情報処理システムは、情報処理装置１００及び記憶装置１１０を含み、両者が互いに接続されたものである。
【００１３】
情報処理装置１００は、ＣＰＵ１０１、ＤＭＡ１０２、ＣＰＵ１０３、インタフェースコントローラ１０４及びＲＡＭ１０５を含み、互いにバスａ１０６を介して接続される。ＣＰＵ１０１、ＤＭＡ１０２及びＣＰＵ１０３は、記憶装置１１０に対するメモリアクセス（リクエスト）を行う装置であり、ＣＰＵ１０１及びＤＭＡ１０２は、リードリクエスト装置として動作し、ＣＰＵ１０３は、ライトリクエスト・リードレスポンス装置として動作する。インタフェースコントローラ１０４は、ＣＰＵ１０１、ＤＭＡ１０２及びＣＰＵ１０３によるメモリアクセスを制御する。ＲＡＭ１０５は、記憶装置１１０から送信されたリードレスポンスを記憶する。バスａ１０６は、汎用的なプロトコル（例えば、ＯＣＰ（Ｏｐｅｎ  Ｃｏｒｅ  Ｐｒｏｔｏｃｏｌ））に従って通信を行うものである。なお、ＣＰＵ１０３は、記憶装置１１０に対するリクエスト装置又は記憶装置１１０からのリクエストに対するレスポンス装置として動作しても良い。
【００１４】
記憶装置１１０は、記憶装置のインタフェースコントローラ１１１及び記憶部１１２を含み、互いにバスｂ１１３を介して接続される。記憶装置のインタフェースコントローラ１１１は、バスｂ１１３のプロトコルに従って記憶部１１２から送信されるレスポンスを情報処理装置１００に送信するための通信を制御する。例えば、記憶装置のインタフェースコントローラは、ＰＣＩ  Ｅｘｐｒｅｓｓ用のコントローラである。記憶部１１２は、情報処理装置１００において用いられる様々なデータを記憶可能であって、情報処理装置１００のＣＰＵ１０１、ＤＭＡ１０２及びＣＰＵ１０３によるメモリアクセスに応じてデータの読み出し及び書き込みを行う。
【００１５】
図２は、本発明の実施例に係るインタフェースコントローラ１０４の内部構成を示すブロック図である。なお、図２に含まれる実線矢印（１）〜（１４）は、ＣＰＵ１０１又はＤＭＡ１０２により「リードリクエスト」が行われた場合の経路を示し、点線矢印（１）′〜（３）′は、ＣＰＵ１０３により「ライトリクエスト又はリードレスポンス」が行われた場合の経路を示し、点線矢印（４）′〜（７）′は、記憶装置１１０により「情報処理装置１００に対するリードリクエスト等（リードリクエスト、ライトリクエスト又はリードレスポンス）」が行われた場合のデータ経路を示す。
【００１６】
本発明の実施例に係るインタフェースコントローラ１０４は、プロトコル解釈手段ａ２０１、リード発行制御手段２０２、プロトコル生成手段ｂ２０３、Ｂｕｓｙ信号生成手段２０４、プロトコル解釈手段ｂ２０５、受信バッファ（保持手段）２０６及びプロトコル生成手段ａ２０７を含む。プロトコル解釈手段ａ２０１及びプロトコル生成手段ａ２０７は、バスａ１０６と接続される。プロトコル生成手段ｂ２０３及びプロトコル解釈手段ｂ２０５は、記憶装置のインタフェースコントローラ１１１と接続される。Ｂｕｓｙ信号生成手段２０４は、バスａ１０６及び記憶装置のインタフェースコントローラ１１１と接続される。各手段２０１〜２０７は、図示しない電気回路により実現される。
【００１７】
はじめに、ＣＰＵ１０１又はＤＭＡ１０２により「リードリクエスト」が行われた場合について説明する。（１）プロトコル解釈手段ａ２０１は、バスａ１０６のプロトコルに従って、リードリクエストを受信し、プロトコルの内容を解釈する。（２）プロトコル解釈手段ａ２０１は、リードリクエストに解釈部識別情報（プロトコル解釈手段ａ２０１のどの解釈部（図３を参照）によりリードリクエストが解釈されたかを示す情報）を付加して、リード発行制御手段２０２に送信する。（３）プロトコル解釈手段ａ２０１は、解釈部識別情報をプロトコル生成手段ａ２０７に送信する。（４）リード発行制御手段２０２は、プロトコル解釈手段ａ２０１から送信されたリードリクエストに対して後述するリード発行制御処理（図７を参照）を行い、プロトコル生成手段ｂ２０３に送信する。（５）リード発行制御手段２０２は、リード発行制御処理においてリードＢｕｓｙ信号が生成された場合は、生成されたリードＢｕｓｙ信号に解釈部識別情報を付加して、Ｂｕｓｙ信号生成手段２０４に送信する。（６）プロトコル生成手段ｂ２０３は、リード発行制御手段２０２から送信されたリードリクエストを受信し、バスｂ１１３のプロトコルに変換し、記憶装置のインタフェースコントローラ１１１に送信する。（７）Ｂｕｓｙ信号生成手段２０４は、記憶装置のインタフェースコントローラ１１１からバスｂ１１３のＢｕｓｙ状態を示すバスｂＢｕｓｙ信号を受信する。（８）Ｂｕｓｙ信号生成手段２０４は、リードＢｕｓｙ信号又はバスｂＢｕｓｙ信号を受信した場合に、バスａ１０６に対するＢｕｓｙ信号を生成し、バスａ１０６に送信する。（９）プロトコル解釈手段ｂ２０５は、バスｂ１１３のプロトコルに従って、記憶装置のインタフェースコントローラ１１１からリードレスポンスを受信する。（１０）受信バッファ（保持手段）２０６は、プロトコル解釈手段ｂ２０５から送信されたリードレスポンスを一時的に保持する。（１１）受信バッファ（保持手段）２０６は、受信バッファサイズ（受信バッファの最大容量）をリード発行制御手段２０２に送信する。（１２）受信バッファ（保持手段）２０６は、リードレスポンスサイズ（リードレスポンスのデータサイズ）をリード発行制御手段２０２に送信する。（１３）受信バッファ（保持手段）２０６は、リードレスポンスをプロトコル生成手段ａ２０７に送信する。（１４）プロトコル生成手段ａ２０７は、受信バッファ（保持手段）２０６から送信されたリードレスポンスをバスａ１０６のプロトコルに変換し、プロトコル解釈手段ａ２０１から送信された解釈部識別情報と対応付けてバスａ１０６に送信する。
【００１８】
次に、ＣＰＵ１０３により「ライトリクエスト又はリードレスポンス」が行われた場合について説明する。（１）′プロトコル解釈手段ａ２０１は、バスａ１０６のプロトコルに従って、ライトリクエスト又はリードレスポンスを受信し、プロトコルの内容を解釈する。（２）′プロトコル解釈手段ａ２０１は、解釈結果に基づいてライトリクエスト又はリードレスポンスをプロトコル生成手段ｂ２０３に送信する。（３）′プロトコル生成手段ｂ２０３は、プロトコル解釈手段ａ２０１から送信されたライトリクエスト又はリードレスポンスを受信し、バスｂ１１３のプロトコルに変換し、記憶装置のインタフェースコントローラ１１１に送信する。
【００１９】
次に、記憶装置１１０により「情報処理装置１００に対するリードリクエスト等」が行われた場合について説明する。（４）′プロトコル解釈手段ｂ２０５は、バスｂ１１３のプロトコルに従って、記憶装置のインタフェースコントローラ１１１から情報処理装置１００に対するリードリクエスト等を受信する。（５）′受信バッファ（保持手段）２０６は、プロトコル解釈手段ｂ２０５から送信された情報処理装置１００に対するリードリクエスト等を一時的に保持する。（６）′受信バッファ（保持手段）２０６は、情報処理装置１００に対するリードリクエスト等をプロトコル生成手段ａ２０７に送信する。（７）′プロトコル生成手段ａ２０７は、受信バッファ（保持手段）２０６から送信された情報処理装置１００に対するリードリクエスト等をバスａ１０６のプロトコルに変換し、バスａ１０６に送信する。
【００２０】
なお、受信バッファ（保持手段）２０６の容量は、バスｂ１１３のリードリクエストサイズ（一度のリードリクエストで要求できるレスポンスのデータサイズ）より大きな容量が必要である。例えば、受信バッファ（保持手段）２０６の容量がリードリエクスサイズの８倍である場合は、最大８回のリードリクエストを連続して発行することができる。また、本実施例では、１つの受信バッファ（保持手段）２０６を設けた構成を説明したが、プロトコル解釈手段ｂ２０５による解釈結果毎に複数の受信バッファ（保持手段）２０６を設けても良い。
【００２１】
図３は、本発明の実施例に係るプロトコル解釈手段ａ２０１の内部構成を示すブロック図である。
【００２２】
本発明の実施例に係るプロトコル解釈手段ａ２０１は、第１バッファ３１２と接続される第１解釈部３１１、第２バッファ３２２と接続される第２解釈部３２１、及び第３バッファ３３２と接続される第３解釈部３３１を含み、各解釈部３１１〜３３１はバスａ１０６と接続される。各解釈部３１１〜３３１は、図示しない電気回路により実現される。
【００２３】
第１解釈部３１１〜第３解釈部３３１は、バスａ１０６を介して送信されたリクエスト又はレスポンスの発行元毎に設けられる。本実施例では、第１解釈部３１１は、ＣＰＵ１０１により発行されたリクエストのプロトコルを解釈し、第２解釈部３２１は、ＤＭＡ１０２により発行されたリクエストのプロトコルを解釈し、第３解釈部３３１は、ＣＰＵ１０３により発行されたリクエスト又はレスポンスのプロトコルを解釈する。
【００２４】
第１解釈部３１１は、ＣＰＵ１０１により発行されたリードリクエストを、バスａ１０６を介して受信し、第１バッファ３１２に格納し、プロトコル解釈を行う。また、リード発行制御手段２０２にリードリクエストを送信するまでは、第１バッファ３１２に格納したリードリクエストを保持し続ける。第２解釈部３２１及び第２バッファ３２２、並びに第３解釈部３３１及び第３バッファ３３２については、第１解釈部３１１及び第１バッファ３１２と同様であるので、説明を省略する。
【００２５】
図４は、本発明の実施例に係るリード発行制御手段２０２の内部構成を示すブロック図である。
【００２６】
本発明の実施例に係るリード発行制御手段２０２は、プロトコル解釈部選択手段４０１、第１蓄積手段４０２、第２蓄積手段４０３、第１算出手段４０４、第２算出手段４０５、比較手段４０６及びリードＢｕｓｙ信号生成手段４０７を含む。各手段４０１〜４０７は、図示しない電気回路により実現される。
【００２７】
プロトコル解釈部選択手段４０１は、プロトコル解釈手段ａ２０１の第１解釈部３１１〜第３解釈部３３１から複数のリクエストが並行して送信された場合に、所定の優先順位に基づいて、リード発行制御処理の対象となる解釈部を選択する。この優先順位は、例えば、ラウンドロビン方式（第１解釈部３１１〜第３解釈部３３１の優先順位を経時的に変更する方式）又は固定方式（予め定められた優先順位に基づく方式）により定められる。
【００２８】
第１蓄積手段４０２は、リード発行が完了したリードリクエストについてのリードリクエストサイズの合計値（ｍ２）を蓄積する。第２蓄積手段４０３は、レスポンス処理が完了したリードレスポンスについてのリードレスポンスサイズの合計値（ｎ１）を蓄積する。
【００２９】
第１算出手段４０４は、プロトコル解釈部選択手段４０１により選択された解釈部のリードリクエストのリードリクエストサイズ（ｍ１）と、第１蓄積手段４０２に蓄積されたリードリクエストサイズの合計値（ｍ２）との和（Ｍ（＝ｍ１＋ｍ２））を算出する。第２算出手段４０５は、第２蓄積手段４０３に蓄積されたリードレスポンスサイズの合計値（ｎ１）と、受信バッファ（保持手段）２０６から送信された受信バッファサイズ（ｎ２）との和（Ｎ（＝ｎ１＋ｎ２））を算出する。
【００３０】
比較手段４０６は、第１算出手段４０２の算出結果（Ｍ）と第２算出手段４０５の算出結果（Ｎ）の大小関係を比較する。リードＢｕｓｙ信号生成手段４０７は、比較手段４０６の比較結果がＭ＞Ｎとなる場合に、リードＢｕｓｙ信号を生成し、Ｂｕｓｙ信号生成手段２０４に送信する。
【００３１】
図５は、本発明の実施例に係るインタフェースコントローラ１０４のリクエスト処理における処理手順を示すフローチャートである。
【００３２】
はじめに、本発明の実施例に係るインタフェースコントローラ１０４は、バスａ１０６のプロトコルに従ってリクエストを受信する（Ｓ５０１）。続いて、受信されたリクエストのプロトコルの内容を解釈する（Ｓ５０２）。なお、Ｓ５０１及びＳ５０２は、各解釈部３１１〜３３１により並列的に行われる。
【００３３】
続いて、所定の優先順位に基づいて処理対象とする解釈部（第１解釈部３１１〜第３解釈部３３１のいずれか）を選択する（Ｓ５０３）。続いて、Ｓ５０３において選択された解釈部の解釈結果が「リードリクエスト」であった場合には（Ｓ５０４−Ｙｅｓ）、後述する「リード発行制御処理（図７）」を行う（Ｓ５０５）。続いて、リードＢｕｓｙ信号が生成された場合（Ｓ５０５−Ｙｅｓ）、又は記憶装置のインタフェースコントローラ１１１からバスｂＢｕｓｙ信号が送信された場合（Ｓ５０６−Ｙｅｓ）には、Ｓ５０３に戻る。
【００３４】
一方、リードＢｕｓｙ信号及びバスｂＢｕｓｙ信号がいずれも無かった場合には（Ｓ５０６−Ｎｏ、Ｓ５０７−Ｎｏ）、Ｓ５０５においてリード発行制御処理が行われたリードリクエストのリードリクエストサイズをｍ２（発行済リードリクエストサイズ）の値に加算し、更新する（Ｓ５０８）。続いて、Ｓ５０３において選択された解釈部のリードリクエストをバスｂ１１３のプロトコルに変換する（Ｓ５０９）。続いて、バスｂ１１３のプロトコルに従って、記憶装置のインタフェースコントローラ１１１にリードリクエストを送信する（Ｓ５１０）。
【００３５】
他方、Ｓ５０３において選択された解釈部の解釈結果が「ライトリクエスト又はリードレスポンス」であった場合には（Ｓ５０４−Ｎｏ）、バスａ１０６からバスｂ１１３に対するライトリクエスト処理又はリードレスポンス処理を行う（Ｓ５１１）。ライトリクエスト処理又はリードレスポンス処理については、説明を省略する。続いて、Ｓ５１１において処理されたライトリクエスト又はリードレスポンスをバスｂ１１３のプロトコルに変換する（Ｓ５０９）。続いて、バスｂ１１３のプロトコルに従って、記憶装置のインタフェースコントローラ１１１にライトリクエスト又はリードレスポンスを送信する（Ｓ５１０）。
【００３６】
図６は、本発明の実施例に係るインタフェースコントローラ１１４のレスポンス処理における処理手順を示すフローチャートである。なお、レスポンス処理は、ＣＰＵ１０１、ＤＭＡ１０２又はＣＰＵ１０３により行われたリクエストに対する処理である。
【００３７】
はじめに、本発明の実施例に係るインタフェースコントローラ１１４は、バスｂ１１３のプロトコルに従って、レスポンスを受信する（Ｓ６０１）。続いて、受信されたレスポンスのプロトコルの内容を解釈する（Ｓ６０２）。
【００３８】
続いて、Ｓ６０２における解釈結果が「リードレスポンス」であった場合には（Ｓ６０３−Ｙｅｓ）、リードレスポンスを受信バッファ２０６へ格納する（Ｓ６０４）。続いて、図５のＳ５０３において選択された解釈部の解釈部識別情報と、受信バッファ２０６へ格納されたリードレスポンスとを対応付ける（Ｓ６０５）。続いて、第２蓄積手段３０２に蓄積されたリードレスポンスサイズの合計値（ｎ２）に、Ｓ６０５においてレスポンス対応付けが行われたリードレスポンスのリードレスポンスサイズを加算し、更新する（Ｓ６０６）。続いて、Ｓ６０４において受信バッファ２０６へ格納されたリードレスポンスをバスａ１０６のプロトコルに変換する（Ｓ６０７）。続いて、バスａ１０６のプロトコルに従って、バスａ１０６にリードレスポンスを送信する（Ｓ６０８）。
【００３９】
一方、Ｓ６０２における解釈結果が「リードリクエスト又はライトリクエスト」であった場合には（Ｓ６０３−Ｎｏ）、バスｂ１１３からバスａ１０６に対するリードリクエスト処理又はライトリクエスト処理を行う（Ｓ６０９）。リードリクエスト処理又はライトリクエスト処理については説明を省略する。続いて、Ｓ６０９において処理されたリードリクエスト又はライトリクエストをバスａ１０６のプロトコルに変換する（Ｓ６０７）。続いて、バスａ１０６のプロトコルに従って、バスａ１０６にリードリクエスト又はライトリクエストを送信する（Ｓ６０８）。
【００４０】
図７は、本発明の実施例に係るリード発行制御手段２０２のリード発行制御処理（図５のＳ５０５）における処理手順を示すフローチャートである。
【００４１】
はじめに、本発明の実施例に係るリード発行制御手段２０２は、Ｓ５０３において選択された解釈部のリードリクエストサイズ（ｍ１）を取得する（Ｓ７０１）。続いて、第１蓄積手段４０２に蓄積されたリードリクエストサイズの合計値（ｍ２）を取得する（Ｓ７０２）。続いて、Ｍ（＝ｍ１＋ｍ２）を算出する（Ｓ７０３）。
【００４２】
また、第２蓄積手段４０３に蓄積されたリードレスポンスサイズの合計値（ｎ１）を取得する（Ｓ７０４）。続いて、受信バッファ（保持手段）２０６の受信バッファサイズ（ｎ２）を取得する（Ｓ７０５）。続いて、Ｎ（＝ｎ１＋ｎ２）を算出する（Ｓ７０６）。
【００４３】
続いて、ＭとＮの大小関係を比較する（Ｓ７０７）。Ｍ＞Ｎの場合は（Ｓ７０８−Ｙｅｓ）、リードＢｕｓｙ信号を生成し、Ｂｕｓｙ信号生成手段２０４に送信する（Ｓ７０８）。一方、Ｍ＜Ｎの場合は（Ｓ７０８−Ｎｏ）、リード発行を行い、リードリクエストをプロトコル生成手段ｂ２０３に送信する（Ｓ７０９）。
【００４４】
本発明によれば、Ｍ≦Ｎとなる場合に限り、リード発行（Ｓ７０９）を行うので、受信バッファ（保持手段）２０６にオーバーフローを発生させることがない。従って、ＣＰＵ１０１及びＤＭＡ１０２は、受信バッファ（保持手段）２０６にオーバーフローを発生させることなく、リードリクエストを連続的に発行することができる。
【００４５】
また、ＣＰＵ１０１及びＤＭＡ１０２は、Ｂｕｓｙ信号生成手段２０４によりＢｕｓｙ信号が生成されたか否か（すなわち、バスａがＢｕｓｙ状態であるか否か）に基づいて、リードリクエストを発行する。すなわち、ＣＰＵ１０１及びＤＭＡ１０２は、バスａがＢｕｓｙ状態でない場合は、リードリクエストサイズを算出することなく、リードリクエストを発行する。従って、ＣＰＵ１０１及びＤＭＡ１０２は、リードリクエストサイズを算出するための処理を行う必要がなく、余分な負荷を与えることがない。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施例に係る情報処理システムの構成を示すブロック図である。
【図２】本発明の実施例に係るインタフェースコントローラ１０４の内部構成を示すブロック図である。
【図３】本発明の実施例に係るプロトコル解釈手段ａ２０１の内部構成を示すブロック図である。
【図４】本発明の実施例に係るリード発行制御手段２０２の内部構成を示すブロック図である。
【図５】本発明の実施例に係るインタフェースコントローラ１０４のリクエスト処理における処理手順を示すフローチャートである。
【図６】本発明の実施例に係るインタフェースコントローラ１０４のレスポンス処理における処理手順を示すフローチャートである。
【図７】本発明の実施例に係るリード発行制御手段２０２のリード発行制御処理（図５のＳ５０５）における処理手順を示すフローチャートである。
【符号の説明】
【００４７】
１００  情報処理装置
１０１、１０３  ＣＰＵ
１０２  ＤＭＡ
１０４  インタフェースコントローラ
１０５  ＲＡＭ
１０６  バスａ
１１０  記憶装置
１１１  記憶装置のインタフェースコントローラ
１１２  記憶部
１１３  バスｂ
【図１】
2008146459.tif 000003
【図２】
2008146459.tif 000004
【図３】
2008146459.tif 000005
【図４】
2008146459.tif 000006
【図５】
2008146459.tif 000007
【図６】
2008146459.tif 000008
【図７】
2008146459.tif 000009