バス制御方法

【目的】バスの使用効率を向上する。
【構成】スレーブとなるモジュール１０１に対してリードアクセスを行うモジュール（マスタ）１００は、ＢＲＥＱ６１信号によりバス使用権をバスアービタに要求すると共に、ＬＣ信号６３により次のサイクルがマスタが使用する最後のサイクルである旨を伝える。そして、ＢＧＲＡＮＴ信号６２によってバス使用を許可されたら、次のサイクルでアドレスをシステムバスのＡ／Ｄ５０を用いてスレーブ１０１に転送することによりリードアクセスを起動し、バス使用権を手放す。スレーブ１０１は、転送されたアドレスを受付けることができなかった場合にのみ、受付けられなかったアドレスの転送サイクルの２サイクル後にＲＥＴＲＹ信号５５をアサートする。ＲＥＴＲＹ信号５５がアサートされたサイクルの２サイクル前に転送を実行したモジュール１００は、２サイクル前に実行した転送を再度実行する。
【効果】転送するアドレスを受付ける用意のできているモジュールに対しては１サイクルのみでアドレスの転送を実現することができる。

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、パーソナルコンピュータやワークステーション等の情報処理システムに関し、特に、情報処理システムのバスの制御技術に関するものである。
【０００２】
【従来の技術】情報処理システムにおいて、バス上に接続された複数のモジュールが共通クロックに同期してデータを転送する同期バスの制御技術としては、たとえば、特開昭６１ー１１８７２号公報記載の技術等が知られている。
【０００３】このような従来の同期バスの制御について説明する。
【０００４】図１６に、従来の同期バス制御技術によるバス上のデータ転送のタイミングを示す。
【０００５】図中、ＣＬＫはバスに接続された各々のモジュールが共通に有するデータ転送用同期クロック、Ａ／Ｄは多重化されたアドレスおよびデータ、ＡＤＲＶはＡ／Ｄ上のアドレスが有効であることを示すアドレスバリッド信号、ＷＲＩＴＥはライトアクセスの指定信号で、Ａ／Ｄ上のデータが有効であることも併せて示している。また、ＷＡＩＴはスレーブ側のバッファがデータを受け付けられる状態になっていないことをマスター側に伝えるウエイト信号である。
【０００６】このような信号から構成されるバスを用いて、１のモジュールが他のモジュールにライトアクセスを行う場合は、まず、バスマスタがＡ／Ｄ上のアドレスが有効であることを示すアドレスバリッド信号ＡＤＲＶをアサートすると同時にＡ／Ｄ上にアクセス先のアドレスを出力する。
【０００７】一方、このアドレスのデコード結果とライトアクセスの指定信号ＷＲＩＴＥにより、自モジュールに対するライトアクセスであることを検知したスレーブモジュールは、データを取り込む準備ができている場合は同期クロックＣＬＫのタイミングでＡ／Ｄ上の有効データを取り込む。もしスレーブモジュールがデータを取り込む準備ができていない場合は、データを受け付ける状態になっていないことをマスター側に伝えるウエイト信号ＷＡＩＴによりデータサイクルの延長を要求する。
【０００８】マスタモジュールはウエイト信号がアサートされている場合は、この間、データサイクルを延長する。スレーブモジュールはデータを取り込む準備ができた時点で同期クロックＣＬＫのタイミングでＡ／Ｄ上の有効データを取り込み、ウエイト信号をネゲートする。そして、マスタモジュールは、ウエイト信号がネゲートされたらデータサイクルを打切り、アクセスを終了する。
【０００９】このように、従来の同期バスの制御技術によれば、ハンドシェイク式にデータ転送が可能か否かをウエイト信号によって伝え合いつつ、データ転送を行っていた。
【００１０】
【発明が解決しようとする課題】しかし、従来の技術によれば、データ転送を行う場合に、データの転送に先立ち、ウエイトサイクルを挿入しているので、ウエイトサイクルの分だけオーバヘッドが生じ、データ転送速度が低下すると共に、バスの占有時間が増大し、バスの使用効率が低下するという問題があった。
【００１１】そこで、本発明は、データ転送のオーバヘッドを低減することにより、バス使用効率の向上を図ることのできるバスの制御方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】前記目的達成のために、本発明は、バスと、バスに接続された複数のモジュールを有する情報処理システムにおいて、バスの使用権を獲得したモジュ−ル（マスタ）が前記バスを制御して転送先のモジュ−ル（スレ−ブ）にアドレスおよびデータを、各モジュ−ルに共通のクロックに同期して転送するバス制御方法であって、前記マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、受け取ったアドレスもしくはデータについての転送サイクルのそれぞれに対して、受領を報告するアクノレッジ報告を、対応する転送サイクルから所定数後のサイクルにおいて他の全モジュ−ルに送出し、アクノレッジ報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたアクノレッジ報告より実行した転送サイクルの成否を確認することを特徴とするバス制御方法を提供する。
【００１３】また、本発明は、前記目的達成のために、マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブでありながら、転送されたアドレスもしくはデータを受け付けることができなかったモジュ−ルは、転送の再実行を要求するリトライ要求を、受付けることのできなかった転送サイクルから所定数後のサイクルにおいて他の全モジュ−ルに送出し、リトライ要求が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、前記所定数前のサイクルに実行した転送を再度実行することを特徴とするバス制御方法を提供する。
【００１４】また、さらに、本発明は、マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、受け取ったアドレスもしくはデータに転送誤りがあった場合に、転送誤りの発生を報告するエラ−報告を、前記転送誤りがあったサイクルから所定数後のサイクルにおいて、他の全モジュ−ルに送出し、エラ−報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたエラ−報告より転送誤りが発生した転送の内容を確認することを特徴とするバス制御方法を提供する。
【００１５】
【作用】本発明に係るバス制御方法によれば、たとえば、マスタは、バスの使用権を獲得したらスレ−ブの状態を確認することなしに、アドレスもしくはデータをスレ−ブに転送する転送サイクルを実行し、転送の成否を確認することなしにバスの使用権を放棄する。一方、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、受け取ったアドレスもしくはデータについての転送サイクルのそれぞれに対して、受領を報告するアクノレッジ報告を、対応する転送サイクルから所定数後のサイクルにおいて他の全モジュ−ルに送出し、アクノレッジ報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたアクノレッジ報告より実行した転送サイクルの転送の成否を確認し、もし、転送が成功していない場合にのみ、対策を講じる。
【００１６】したがい、マスタよりの転送を受け入れる用意のあるスレ−ブに対する転送は、実際にアドレスやデータを転送するサイクルのみで実現でき、バスの使用効率を向上することができる。
【００１７】
【実施例】以下、本発明に係る情報処理システムの一実施例について説明する。
【００１８】まず、図１に本実施例に係る情報処理システムの構成を示す。
【００１９】図示するように、本実施例に係る情報処理システムは、システムバス５０〜６０と、これに接続する複数のモジュール０〜７（１００〜１０７）と、各モジュール１００〜１０７間のバス使用権を調停するバスアービタ１０８と、各モジュール１００〜１０７に接続するＩ／Ｏバス１００、Ｉ／Ｏバスに接続するＩ／Ｏ装置とを有している。また、各モジュール１００〜１０７には、単独のＩ／Ｏ装置のみが接続することもある。各モジュールは、システムバスインタフェース装置を内蔵し、システムバス５０〜６０と、図示せざるＩ／ＯバスもしくはＩ／Ｏ装置との間のデータ転送を仲介する。
【００２０】また、図中、６１はモジュール０からバスアービタ１０８に対してバス使用権を要求するためのバス権要求信号（ＢＲＥＱ０）、６２はバスアービタ１０８からモジュール０（１００）にバス使用の許可を与えるバス使用許可信号（ＢＧＲＡＮＴ０）、６３はモジュール０（１００）からバスアービタ１０８に対して次のサイクルがバス使用の最終サイクルであることを伝えるラストサイクル信号（ＬＣ０）である。同様に、６４はモジュール１（１０１）からバスアービタ１０８に対するバス権要求信号（ＢＲＥＱ１）、６５はバスアービタ１０８からモジュール１（１０１）に対するバス使用許可信号（ＢＧＲＡＮＴ１）、６６はモジュール１（１０１）からバスアービタ１０８に対して最終サイクルであることを伝えるラストサイクル信号（ＬＣ１）、６７はモジュール７（１０７）からバスアービタ１０８に対するバス権要求信号（ＢＲＥＱ７）、６８はバスアービタ１０８からモジュール７（１０７）に対するバス使用許可信号（ＢＧＲＡＮＴ７）、６９はモジュール７（１０７）からバスアービタ１０８に対して最終サイクルであることを伝えるラストサイクル信号（ＬＣ７）である。
【００２１】また、システムバスにおいて、５０はアドレスおよびデータバス（Ａ／Ｄ）、５１はアクセスの種類を指定するコマンド信号（ＣＭＤ）、５２はＡ／Ｄ上のアドレスが有効であることを示すアドレスバリッド信号（ＡＤＲＶ）、５３はＡ／Ｄ上のデータが有効であることを示すデータバリッド信号（ＤＡＴＡＶ）、５４はスレーブ側がアドレスもしくはデータを確かに受け取ったことをマスタ側に伝えるトランザクションアクノリッジ信号（ＴＡＣＫ）、５５はスレーブ側のマスタ側に対するリトライ要求信号（ＲＥＴＲＹ）、５６はスレーブ側からマスタ側に対するトランザクションに同期したエラー報告信号であるシンクロナスエラー（ＳＥＲＲ）、５７はトランザクションに同期しないエラー報告信号であるアシンクロナスエラー（ＡＥＲＲ）、５８はシンクロナスエラー５６およびアシンクロナスエラー５７と同時に出力して診断用トランザクション以外を凍結するフリーズ信号（ＦＲＺ）、５９はフリーズ中の診断用トランザクションによるエラー回復が終了後フリーズ信号を解除するためのバスリセット信号（ＢＲＳＴ）、６０は各モジュールに共通に供給される同期用クロック信号（ＣＬＫ）である。
【００２２】次に、図２に、各モジュールの内部構成を示す。
【００２３】図中、１がバス制御を担うシステムバスインタフェース装置であって、システムバス５０〜６０と、図示せざるＩ／ＯバスもしくはＩ／Ｏ装置との間に接続され、両者間のデータ転送を仲介する。
【００２４】２はシステムバスインタフェース装置１内部のシステムバス制御部、３はシステムバスインタフェース装置１を介して接続されるＩ／ＯバスもしくはＩ／Ｏ装置を制御する制御部である。また、４は、システムバス制御部２とＩ／ＯバスもしくはＩ／Ｏの制御部３間のインタフェースを整合させる変換部、５はバスアービトレーション制御部、６はエラー制御部、７はシステムバス制御部、８はリトライ制御部、９は受けデータ用バッファ、１０はアドレス変換部、１１はデータ変換部、１２はプロトコル変換部、１３はアドレス入出力部、１４はデータ入出力部、１５はＩ／Ｏ（バス）制御部、１６は出力用最終段バッファ、１７は入力用初段バッファ、１８はアドレス出力バッファ、１９〜２２はバーストライト用データバッファ、２３は入力アドレスバッファ、２４は入力アドレス、データチェック用バッファ、２５はアービトレーション制御信号、２６はアドレスバス、２７はデータバス、２８は制御信号、２９はデータのパリティ等より転送誤りを検出するエラーチェッカーである。
【００２５】以下、このような情報処理システムにおけるデータ転送動作について説明する。
【００２６】まず、リードアクセス動作について説明する。本実施例では、リードアクセスを、読み出し要求側がアドレスをシステムバスに出力する起動シーケンスと、被要求側が受け取ったアドレスに応えデータをシステムバスに出力する応答シーケンスより実現する。また、本実施例においては、起動シーケンスと応答シーケンスが独立したスプリット動作によりリードアスセス動作を実現する。
【００２７】本実施例においては、あるモジュールがリードアクセス動作を行う場合、まず、バス権要求信号（ＢＲＥＱ）によりバスアービタ１０８に対しバス使用権を要求する。また、このとき同時にラストサイクル信号（ＬＣ）を出力し、バスアービタ１０８に対し１サイクルでバス権を放棄することを予告する。
【００２８】そして、バス使用許可信号（ＢＧＲＡＮＴ）がアサートされたらアドレス等をシステムバスに出力し、バス使用を終了する。
【００２９】図３には、モジュール０（１００）からモジュール３（１０３）までが、リードアクセスのために、同時にＢＲＥＱをアサートした場合について示した。
【００３０】図示するように、モジュール０（１００）からモジュール３までが同時にＢＲＥＱをアサートしている。ただし、モジュール０（１００）、モジュール１（１０１）、モジュール２、モジュール３の順でバス使用の優先順位が高いものとする。
【００３１】図示するように、第３サイクル、第４サイクル、第５サイクル、第６サイクルと、バスマスタがモジュール０（１００）、モジュール１（１０１）、モジュール２、モジュール３の順に切り換わっている。すなわち、バスマスタが１サイクルごとに切り替わってもアイドルサイクルが挿入されない。
【００３２】図３に、リードアクセスを起動するシーケンスを示す。
【００３３】図示するように、このシーケンスにおいて、リードアクセスのために、ＢＲＥＱとＬＣをアサートした起動モジュールは、バスアービタ１０８からバス使用許可信号（ＢＧＲＡＮＴ）を受けるとＡ／Ｄ上のアドレスが有効であることを示すアドレスバリッド信号（ＡＤＲＶ）５２を有効にし、アドレスデータバス（Ａ／Ｄ）５０にアクセス先のアドレスを出力する。また、同時に、アクセスの種類がリードアクセスであるということをコマンド信号（ＣＭＤ）５１に出力し、起動シーケンスを終了する。なお、リードアクセスの起動サイクルは図中第４サイクルとなっている。
【００３４】次に、応答シーケンスを図５に示す。
【００３５】リードアクセスのコマンドおよびアドレスを受け取ったモジュールは応答するべきデータが準備できた時点でバス権を獲得した後、Ａ／Ｄ上のデータが有効であることを示すデータバリッド信号（ＤＡＴＡＶ）５３を有効にし、アドレスおよびデータバス（Ａ／Ｄ）５０に応答データを出力する。また、同時に、アクセスの種類がリード応答アクセスであるということをコマンド信号（ＣＭＤ）５１に出力する。応答サイクルは、図中第７サイクルである。
【００３６】なお、ここでバーストリード時のリードアクセスの応答シーケンスを図５に示しておく。図中、応答サイクルは第５から第８サイクルである。
【００３７】以上のように、本実施例においては、従来のようなウエイト信号等を用いずに、各モジュールの受けデータ用バッファ（図１、９）が、いつでもデータを取り込み可能と仮定し、バス権獲得後は、転送を必ず１データもしくは１アドレスあたり１サイクルで行い、バス占有時間を減らし、バス使用効率を向上させている。
【００３８】なお、ライトアクセスのシーケンスにおいても、図７に示すように、アドレス転送、データ転送をともに１サイクルずつで終了させることができる。アドレス等を転送し、ライトアクセスを起動する起動サイクルが第４サイクル、データ等を転送する応答サイクルが第５サイクルである。
【００３９】また、バーストライト時のシーケンスにおいても、図８に示すように、転送サイクルを必ず１データもしくはアドレスあたり１サイクルで行うことができる。図８中、アドレスを転送する起動サイクルが第３サイクル、これに応え４つのデータを転送する応答サイクルが第４から第７サイクルである。
【００４０】さて、前述したように、各モジュールの受けデータ用バッファ（図１、９）が、いつでもデータを取り込み可能と仮定し、バス権獲得後は、転送サイクルを必ず１データもしくはアドレスあたり１サイクルで行うようにしたが、バッファの容量にも限りがあるため連続でライトアクセス等が行われるとバッファがオーバフローしデータを受けきれなくなる場合が有りえる。
【００４１】そこで、本実施例では、スレーブ側がアドレスもしくはデータを確かに受け取ったことをマスタ側に伝えるトランザクションアクノリッジ信号（ＴＡＣＫ）５４、スレーブ側がマスタ側に再送を要求するリトライ要求信号（ＲＥＴＲＹ）５５、スレーブ側がマスタ側にエラーの発生をトランザクションに同期して報告するシンクロナスエラー（ＳＥＲＲ）５６を設けた。また、これらの信号は、必ず、マスタ側よりの転送サイクルの２サイクル後にスレーブ側が出力することとし、そのマスタ側よりのトランザクションが成功したか否かをマスタ側が認識できるようにした。
【００４２】また、各モジュールはトランザクションの起動をかけられた時点で、バッファが当該トランザクションによってオーバフローするか否かを判別することができるので、スレーブ側モジュールのリトライ要求信号（ＲＥＴＲＹ）５５のアサートはトランザクションの先頭のサイクルに対してのみ行う。なお、バーストライトもしくはバーストリード時には、トランザクションの先頭のサイクルでＣＭＤにバースト転送量の情報を含めるので、この場合も、各モジュールはトランザクションの起動をかけられた時点で、バッファが当該トランザクションによってオーバフローするか否かを判別することができる。
【００４３】リードアクセスに対するリトライのシーケンス例を図９に示す。
【００４４】図示した例では、１回目の起動サイクル（第４サイクル）に対して、第６サイクルにスレーブからＲＥＴＲＹをアサートし、これに対しマスタが第１１サイクルで再度起動サイクルを実行しリトライを成功させている。
【００４５】次に、転送エラーが起こった場合のシーケンス例を図１０に示す。
【００４６】図示した例は、バーストライトアクセスの２つめのデータ転送サイクル（第６サイクル）でパリディエラーが起こった場合で、スレーブ側からマスタ側に対するトランザクションに同期したエラー報告信号であるシンクロナスエラー（ＳＥＲＲ）５６が、パリディエラーが起こったサイクルの２サイクル後（第８サイクル）にスレーブ側より出力されている。また、スレーブ側モジュールは、エラー報告をおこなうのと同時に、フリーズ信号（ＦＲＺ）５８によりバスを凍結する。一方、シンクロナスエラー（ＳＥＲＲ）５６がアサートされると、マスター側は、シンクロナスエラー（ＳＥＲＲ）５６がアサートされタイミングと、記憶しておいた過去に実行した各サイクルについての情報より、エラー発生サイクル、エラーアドレスなどを求め、ロギング情報として保持する。
【００４７】また、シンクロナスエラー（ＳＥＲＲ）５６がアサートされると、いずれかのモジュールに接続したプロセッサ等、エラー回復処理を担う所定の装置がマスター側のモジュールが保持したエラー発生サイクル、エラーアドレスなどのロギング情報をもとにエラーを回復（第９サイクルから第１８サイクルの間のどこかのタイミング）した後、バスリセット信号（ＢＲＳＴ）５９によりフリーズを解除し、通常のトランザクションをリスタートさせる（第２４サイクル以降）。
【００４８】このように、本実施例においては、マスタ側は、トランザクションに完全に同期したエラー報告を受けるので、どのサイクルでエラーが起こったかという情報までロギングすることができ、その後のエラーの解析、エラーの回復処理を容易にすることができる。
【００４９】ところで、次に、このようなプロトコルを有するシステムバスを用いて、複数のモジュールに対して同時にライトを行う放送型トランザクションであるブロードキャストを行う場合について説明する。
【００５０】このような放送型トランザクションにおいては、同時に複数モジュールに対してライトすることが必須であるため、一部のモジュールのみがバッファのオバーフローを起こしライトできたモジュールとそうでないモジュールが生じてしまう場合が有りえる。
【００５１】そこで、本実施例においては、ブロードキャスト時には、マスタは必ず転送サイクルの２サイクル後までバス権を保持したままで待ち、リトライ要求信号（ＲＥＴＲＹ）５５がないか、シンクロナスエラー報告（ＳＥＲＲ）５６がないかを確認するようにする。
【００５２】また、ここで、トランザクションアクノリッジ信号（ＴＡＣＫ）５４、リトライ要求信号（ＲＥＴＲＹ）５５、シンクロナスエラー報告（ＳＥＲＲ）５６が、複数のモジュールによって同時にアサートする可能性があるため、ワイヤードＯＲ信号として準備しておく。そして、マスタは、リトライ要求があればバス権を保持したままでもう一度同じアクセスサイクルを実行するようにする。一方、転送を受け取った各スレ−ブも、必ず転送サイクルの２サイクル後まで、転送されたデータの処理を開始せずに保持したままで待ち、他のスレ−ブよりのリトライ要求信号（ＲＥＴＲＹ）５５がないか、シンクロナスエラー報告（ＳＥＲＲ）５６がないかを確認し、リトライ要求信号（ＲＥＴＲＹ）５５がないか、シンクロナスエラー報告（ＳＥＲＲ）５６があった場合には、受け取ったデータを廃棄する。
【００５３】ブロードキャストアクセス動作時のシーケンス例を図１１、図１２に示す。
【００５４】図１１は、１度のブロードキャストアクセスで成功した例で、図１２はブロードキャストアクセスで成功した例を示している。
【００５５】図１１に示す例では、転送サイクルの２サイクル後までバス権を保持したままで待っても、リトライ要求信号（ＲＥＴＲＹ）５５、シンクロナスエラー報告（ＳＥＲＲ）５６がない場合、マスタは、ＬＣを発行し、バス権を手放している。
【００５６】一方、図１２に示す例では、第３サイクルおよび第７サイクルでマスタが起動をかけたブロードキャストアクセスに対して第５、第９サイクルでＲＥＴＲＹがアサートされている。マスタは、各ＲＲＥＴＲＹのアサートに対して、第７、第１１サイクルでリトライの起動をかけ、３回目のリトライに対しては第１３サイクルでＲＲＥＴＲＹがアサートされず、最終転送サイクルの２サイクル後の第１４サイクルまでにエラー報告もなかったことを確認してＬＣを発行しバス権を手放してトランザクションを終了している。
【００５７】ここで、図１３に、ブロードキャストアクセスを行うマスタの実行する手順を示しておく。図示するように、マスタは、１５０で処理を開始後、１５１で全モジュールを対象とした放送型のライトアクセスを実行する。そして、１５２で１５１にたいするリトライ要求があるかどうかを判定し、あれば１５１にもどり全モジュールを対象とした放送型のライトアクセスを再実行する。１５２で１５１にたいするリトライ要求がなければ１５３で２サイクル待って全スレーブがエラーなくデータを受け取ったかどうかを確認し、１５４でエラー報告を受ければ１５５に遷移してエラー処理を行い、エラー報告がなければ１５６で終了する。
【００５８】なお、連続ライトアクセスを受けるモジュ−ルが、階層の異なるバス間のプロトコル変換を行うバスコンバ−タである場合には、当該モジュ−ルは、最後のサイクルのデ−タまでバッファ内に受け取ったことを確認してから異なる階層のバスへの転送を開始するようにする。
【００５９】ところで、前述したように、リトライ要求が返ってくるサイクルは起動サイクルの２サイクル後となるため、図１４に示すように、同一モジュールから特定のモジュールに対して連続してライトアクセス（第３および第５サイクルで起動）を行うような場合、バスインタフェース装置の都合で１番目のライトアクセスがバッファのオーバフロー等により受付けられなかったのにもかかわらず、２番目のライトアクセスが引き続きマスタ側より行われる。そして、この２番目のライトアクセスのみが受け付けられる可能性がある。すなわち、アクセスの順序が保証されない場合が生じえる。
【００６０】そこで、本実施例においては、同一モジュールから特定のモジュールに対して連続ライトアクセスを行うような場合は、起動をかけるバスインタフェース装置において、連続ライトの場合は、ライトアクセス終了後は必ず２サイクル待って、リトライ要求が返ってこないことを確認した後、次のライトアクセスを起動するようにする。
【００６１】図１５に同一モジュールから特定のモジュールに対して連続ライトアクセスを行う場合のシーケンス例を示す。
【００６２】図示した例では、マスタは第４サイクルで１度目のライトアクセスを終了した後に、第５サイクルにリトライ要求がアサートされないことを確認した後、第７サイクルに２番目のアクセスを起動している。
【００６３】なお、本実施例において、リトライ要求、アクノリッジ、エラー報告を２サイクル後に行っている理由は、システムバスの負荷を極力低減し、転送の同期用クロックであるＣＬＫの周波数を高くすることを可能とするために、エラーチェッカー（図１、２９）等を直接システムバスに接続しないことに起因するものである。
【００６４】以上、説明してきたように、本実施例に係る情報処理システムによれば、相手モジュールのデータ受け付けの可否を確認するためのレディ制御などのハンドシェイクを行わず、また、データ転送元が転送先であるスレーブのアクノリッジ信号を確認することなしに転送サイクルを終了するので、バスの使用効率を向上することができると共に、アクセス速度を向上することができる。
【００６５】また、エラー処理に関しては、トランザクションの各々のサイクルに同期したエラー報告を行うので、エラー報告をうけたマスタモジュールが、エラーが発生したサイクルの個所まで詳細にロギングをとることができ、エラー発生後の回復処理を容易にすることができる。
【００６６】
【発明の効果】以上のように、本発明によれば、データ転送のオーバヘッドを低減することにより、バス使用効率の向上を図ることのできるバスの制御方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の一実施例に係る情報処理システムの構成を示すブロック図である。
【図２】システムバスインタフェース装置の構成を示すブロック図である。
【図３】リードアクセスのためのバス権要求が競合した場合のシーケンスを示すタイムチャートである。
【図４】リードアクセスの起動シーケンスを示すタイムチャートである。
【図５】リードアクセスの応答シーケンスを示すタイムチャートである。
【図６】バースト転送によるリードアクセスの起動シーケンスを示すタイムチャートである。
【図７】ライトアクセスのシーケンスを示すタイムチャートである。
【図８】バースト転送によるライトアクセスのシーケンスを示すタイムチャートである。
【図９】リードアクセスのリトライシーケンスを示すタイムチャートである。
【図１０】転送エラー発生時のシーケンスを示すタイムチャートである。
【図１１】ブロードキャスアクセス時のシーケンスを示すタイムチャートである。
【図１２】ブロードキャスアクセス時のリトライシーケンスを示すタイムチャートである。
【図１３】ブロードキャスアクセス時にマスタが行う手順を示すフローチャートである。
【図１４】通常のライトアクセスと同様の連続ライトアクセスを行った場合のリトライシーケンスを示すタイムチャートである。
【図１５】連続ライトアクセスのシーケンスを示すタイムチャートである。
【図１６】従来のバス制御技術によるライトアクセスのシーケンスを示すタイミングチャートである。
【符号の説明】
１・・・システムバスインタフェース装置
２・・・システムバス制御部
３・・・制御部
４・・・変換部
５・・・バスアービトレーション制御部
６・・・エラー制御部
７・・・システムバス制御部
８・・・リトライ制御部
９・・・受けデータ用バッファ
１０・・・アドレス変換部
１１・・・データ変換部
１２・・・プロトコル変換部
１３・・・アドレス入出力部
１４・・・データ入出力部
１５・・・Ｉ／Ｏ（バス）制御部
１６・・・出力用最終段バッファ
１７・・・入力用初段バッファ
１８・・・アドレス出力バッファ
１９、２０、２１、２２・・・バーストライト用データバッファ
２３・・・入力アドレスバッファ
２４・・・入力アドレス、データチェック用バッファ
２５・・・アービトレーション制御信号
２６・・・アドレスバス
２７・・・データバス
２８・・・制御信号
２９・・・エラーチェッカー
５０・・・データバス（Ａ／Ｄ）
５１・・・コマンド信号（ＣＭＤ）
５２・・・アドレスバリッド信号（ＡＤＲＶ）
５３・・・データバリッド信号（ＤＡＴＡＶ）
５４・・・トランザクションアクノリッジ信号（ＴＡＣＫ）
５５・・・リトライ要求信号（ＲＥＴＲＹ）
５６・・・シンクロナスエラー（ＳＥＲＲ）
５７・・・アシンクロナスエラー（ＡＥＲＲ）
５８・・・フリーズ信号（ＦＲＺ）
５９・・・バスリセット信号（ＢＲＳＴ）
６０・・・同期用クロック信号（ＣＬＫ）

【特許請求の範囲】
【請求項１】バスと、バスに接続された複数のモジュールを有する情報処理システムにおいて、バスの使用権を獲得したモジュ−ル（マスタ）が前記バスを制御して転送先のモジュ−ル（スレ−ブ）にアドレスおよびデータを、各モジュ−ルに共通のクロックに同期して転送するバス制御方法であって、前記マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、受け取ったアドレスもしくはデータについての転送サイクルのそれぞれに対して、受領を報告するアクノレッジ報告を、対応する転送サイクルから所定数後のサイクルにおいて他の全モジュ−ルに送出し、アクノレッジ報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたアクノレッジ報告より実行した転送サイクルの転送の成否を確認することを特徴とするバス制御方法。
【請求項２】バスと、バスに接続された複数のモジュールを有する情報処理システムにおいて、バスの使用権を獲得したモジュ−ル（マスタ）が前記バスを制御して転送先のモジュ−ル（スレ−ブ）にアドレスおよびデータを、各モジュ−ルに共通のクロックに同期して転送するバス制御方法であって、前記マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブでありながら、転送されたアドレスもしくはデータを受け付けることができなかったモジュ−ルは、転送の再実行を要求するリトライ要求を、受付けることのできなかった転送サイクルから所定数後のサイクルにおいて他の全モジュ−ルに送出し、リトライ要求が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、前記所定数前のサイクルに実行した転送を再度実行することを特徴とするバス制御方法。
【請求項３】バスと、バスに接続された複数のモジュールを有する情報処理システムにおいて、バスの使用権を獲得したモジュ−ル（マスタ）が前記バスを制御して転送先のモジュ−ル（スレ−ブ）にアドレスおよびデータを、各モジュ−ルに共通のクロックに同期して転送するバス制御方法であって、前記マスタは、バスの使用権を獲得したらアドレスもしくはデータをスレ−ブに転送する転送サイクルを実行してバスの使用権を放棄し、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、受け取ったアドレスもしくはデータに転送誤りがあった場合に、転送誤りの発生を報告するエラ−報告を、前記転送誤りがあったサイクルから所定数後のサイクルにおいて、他の全モジュ−ルに送出し、エラ−報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたエラ−報告より転送誤りが発生した転送の内容を確認することを特徴とするバス制御方法。
【請求項４】請求項２記載のバス制御方法であって、スレ−ブでありながら、転送されたアドレスもしくはデータを受け付けることができなかった前記モジュ−ルは、前記マスタが前記転送サイクルを連続して実行した場合には、前記マスタが連続して実行した転送サイクルのうちの先頭の転送サイクルから所定数後のサイクルにおいてのみ、前記リトライ要求を他の全モジュ−ルに送出し、リトライ要求が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、前記所定数前のサイクルから連続して実行した転送を再度実行することを特徴とするバス制御方法。
【請求項５】請求項３記載のバス制御方法であって、エラ−回復処理を実行するエラ−処理手段を備え、スレ−ブとして、転送されたアドレスもしくはデータを受け取った前記モジュ−ルは、前記エラ−報告と同時に、診断用のトランザクション以外のバス上のトランザクションを凍結するフリーズ信号を他の全てのモジュ−ルに送出し、エラ−報告が送出されたサイクルより前記所定数前のサイクルにマスタとして転送を実行したモジュ−ルは、当該送出されたエラ−報告の送出タイミングより、転送誤りが発生した転送サイクルおよび転送アドレスについての情報を求め、ロギング情報として保持すると共にエラ−回復処理の実行を前記エラ−処理手段に送出し、前記エラ−処理手段は、前記ロギング情報をもとにエラーを回復した後、バス上の通常のトランザクションを再開させるバスリセット信号を他の各モジュ−ルに送出することを特徴とするバス制御方法。
【請求項６】請求項１記載のバス制御方法であって、前記マスタは、アドレスもしくはデータをスレ−ブに連続して転送する場合には、転送サイクルの実行後に、当該転送サイクルに対するスレ−ブよりのアクノレッジ報告を確認するまで、前記所定数のサイクル、バスの使用権を保持し、当該転送サイクルに対するスレ−ブよりのアクノレッジ報告を確認した後に次の転送サイクルを実行することを特徴とするバス制御方法。
【請求項７】請求項２記載のバス制御方法であって、前記マスタは、アドレスもしくはデータをスレ−ブに連続して転送する場合には、転送サイクルの実行後に、当該転送サイクルに対するスレ−ブよりのリトライ要求の有無を確認するまで、前記所定数のサイクル、バスの使用権を保持し、リトライ要求があった場合には、当該転送サイクルで実行した転送の再実行を、次の転送サイクルの実行に優先して実行することを特徴とするバス制御方法。
【請求項８】請求項３記載のバス制御方法であって、前記マスタは、アドレスもしくはデータをスレ−ブに連続して転送する場合には、転送サイクルの実行後に、当該転送サイクルに対するスレ−ブよりのエラ−報告の有無を確認するまで、前記所定数のサイクル、バスの使用権を保持し、エラ−報告のないことを確認した後に、次の転送サイクルを実行することを特徴とするバス制御方法。
【請求項９】請求項２記載のバス制御方法であって、スレ−ブとして、転送誤りのあるアドレスもしくはデータを受け取った前記モジュ−ルは、転送誤りの発生を報告するエラ−報告を、前記転送誤りがあったサイクルから所定数後のサイクルにおいて、他の全モジュ−ルに送出し、前記マスタは、複数のスレーブに対して同時にデータの書き込みのための同報転送を行う場合には、当該転送を実行する転送サイクルに対する各スレ−ブよりのエラ−報告およびリトライ要求の有無を確認するまで、前記所定数のサイクル、バスの使用権を保持し、いずれかのスレ−ブからリトライ要求があった場合には、全てのスレーブに対する同報転送を再度実行し、いずれかのスレ−ブからエラ−報告があった場合には所定のエラ−回復処理を実行し、各スレ−ブは、前記同報転送時には、マスタよりのデータの転送を受け取った後、当該転送を受け取った転送サイクルに対する他のスレ−ブよりのリトライ要求およびエラー報告の送出の有無を確認するまで、前記所定数のサイクル、転送されたデータを保持し、いずれかのスレ−ブからのリトライ要求もしくはエラ−報告の送出があった場合には、保持したデータを廃棄することを特徴とするバス制御方法。

【図１】