JP3630523B2 - バス転送処理システム - Google Patents
バス転送処理システム Download PDFInfo
- Publication number
- JP3630523B2 JP3630523B2 JP10331197A JP10331197A JP3630523B2 JP 3630523 B2 JP3630523 B2 JP 3630523B2 JP 10331197 A JP10331197 A JP 10331197A JP 10331197 A JP10331197 A JP 10331197A JP 3630523 B2 JP3630523 B2 JP 3630523B2
- Authority
- JP
- Japan
- Prior art keywords
- retry
- status
- bus
- signal
- cpu
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Bus Control (AREA)
Description
【発明の属する技術分野】
本発明はバス転送処理システムに関し、特にＣＰＵが接続されているｎビット幅のバスに拡張アダプタを介してＩＯ（入出力装置）が接続されているバス転送処理システムに関する。
【０００１】
【従来技術】
図５には、ＣＰＵ＃１とＩＯ４０がバスＢＵＳに接続されるとともに、ＩＯ４０が複数（ＩＯ＃１〜＃３）接続される場合、バスＢＵＳの負荷を軽減する為に拡張アダプタＢＥＸを介してＣＰＵ＃１とＩＯ４０を接続したバス転送処理システムが示されている。
【０００２】
このバス転送処理システムにおける、ＣＰＵ＃１から拡張アダプタＢＥＸを介してＩＯ４０に対して行う基本的なリードアクセス動作を図６を参照して説明する。
【０００３】
（１）ＣＰＵ＃１よりアクセス種別（リード／ライト、アクセスワード数等の情報でこれを図示のように“オーダ”（ｏｒｄｅｒ） と記す）とＩＯ４０へアクセスするためのアドレス（ａｄｄと記す）をクロックに従って転送する。
（２）オーダとアドレスを受信した拡張アダプタＢＥＸはその内容を判定する。判定結果からＣＰＵ＃１へ、図７に詳細に示すようなステータスコードを返送する。この場合に、正常を示すステータスコード（“０００１”）を返送した場合には、ＩＯ４０からデータを読み出す。以降、ステータスコードが示す状態については、図７を参照する。
【０００４】
（３）データをＩＯ４０から読出した拡張アダプタＢＥＸはＣＰＵ＃１へアクセス種別（返送の場合アンサ（ａｎｓと記す）とデータ（ｄａｔａと記す）を返送する。
（４）アンサ及びデータを正常（パリティエラー等なし）に受信するとＣＰＵ＃１は拡張アダプタＢＥＸへ正常を示すステータスコード（“０００１”）を返送し、リードアクセスが終了となる。なお、オーダとアンサが返送されるまでの時間は可変である。
【０００５】
次に、このバス転送処理システムにおいてＣＰＵ＃１における処理が時分割にされるような時にアクセス種別（オーダ）の優先順位によりリトライ処理となる場合について説明する。
【０００６】
このアクセス種別（オーダ）には、優先順位を示すビットが設けられており、そのビットが“１”になっているアクセス種別（オーダ）は優先順位が高くなり、そのアクセスについての処理が優先される。優先順位によりリトライ処理となる場合を図８（１）を参照して説明する。
【０００７】
（１）拡張アダプタＢＥＸがＣＰＵ＃１から優先順位が高いアクセス種別（オーダ）“ｏｒｄｅｒ１”とＩＯ４０からデータを読出すアドレスとを受信する。
（２）受信した拡張アダプタＢＥＸはオーダ及びアドレスを判定する。判定結果が正常な（パリティエラー等がない）時、ＣＰＵ＃１へ正常を示すステータスコード（”０００１”）を返送する。また、正常を示すステータスコードを返送した場合には、オーダに従って処理する。
【０００８】
（３）拡張アダプタＢＥＸが上記アクセス種別（オーダ）“ｏｒｄｅｒ１”処理中に優先順位が低いアクセス種別（オーダ）“ｏｒｄｅｒ２”とＩＯ４０からデータを読出すアドレスとを受信する。
（４）拡張アダプタＢＥＸは、正常を示すステータスコード（“０００１”）とオーダの優先順位が低いことからリトライ信号をＣＰＵ＃１へ返送する。
（５）ＣＰＵ＃１は一定期間後、リトライとなったアクセス種別（オーダ）“ｏｒｄｅｒ２”を再転送するリトライ処理を行い、拡張アダプタＢＥＸでアクセス種別（オーダ）“ｏｒｄｅｒ１”の処理が終了していればアクセス種別（オーダ）“ｏｒｄｅｒ２”の処理を実行する。
【０００９】
更に、この装置においてＣＰＵ＃１における処理が時分割で行われるような時に、拡張アダプタＢＥＸを介したＩＯ４０からのデータ読出しに時間がかかり拡張アダプタＢＥＸからＣＰＵ＃１への応答がある以前にＣＰＵ＃１からＩＯ４０へのアクセスが次々に起こる（輻輳する）場合について図８（２）を参照して説明する。
【００１０】
すなわち、ＣＰＵ＃１からＩＯ４０へのアクセスが輻輳し拡張アダプタＢＥＸがバッファフルとなるようなアクセスの場合は次の処理手順になる。
【００１１】
（１）ＣＰＵ＃１よりアクセス種別（オーダ）“ｏｒｄｅｒ３”とＩＯ４０からデータを読出すアドレスを転送する。
（２）受信した拡張アダプタＢＥＸがＩＯ４０から（１）に対するデータを読み出す前にＣＰＵ＃１からＩＯ４０へのアクセス種別（オーダ）“ｏｒｄｅｒ４”と読出しアドレスが転送され、その結果輻輳することになる。
（３）拡張アダプタＢＥＸがバッファフル状態となる。
（４）アクセス種別（オーダ）“ｏｒｄｅｒ４“に対してリトライ信号をアサートし、異常を示すステータスコード（バッファフル：“００１０”）を返送し、ＣＰＵ＃１にてリトライ処理を実行する。
【００１２】
上記の例では単一のＣＰＵの場合について説明したが、複数のＣＰＵによるマルチプロセッサ構成について説明すると、この構成は図９〜図１４に示すように、ｎビット幅のバスＢＵＳ上に同一の処理を実施するＣＰＵ＃１とＣＰＵ＃２を接続し、ＣＰＵの信頼性を高めるものとなっている。
【００１３】
このマルチプロセッサ構成におけるステータスコードとリトライ信号による処理例としてコピーバック・キャッシュのアクセス手順の一例を示す。なお、ＣＰＵ＃１，＃２はそれぞれ自分がスレーブ，マスタであることを知っているものとする。さらにステータスコードとリトライ信号は上記の拡張アダプタを介さない場合を例にとったが、拡張アダプタについても同様に上記のとおりステータスコードとリトライ信号が発生し得るものである。
【００１４】
（１）ＣＰＵ＃２での処理（図９）：
マスタ側のＣＰＵ＃２におけるＭＰＵ＃２からライトアクセス（書込アドレス及びデータの転送）し、ＣＡＣ（Ｃａｓｈ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）＃２内のキャッシュメモリ（図示せず）を更新する。このとき共通メモリＣＭは必ず未更新状態であるので、ＣＡＣ＃２における制御では、キャッシュメモリの状態を「キャッシュ無効」から「非共有・書き換え有り」に遷移する。
【００１５】
（２）ＣＰＵ＃１での処理（図１０）：
ＭＰＵ＃１からＣＡＣ＃１のキャッシュメモリにリードアクセス（データを読出すアドレスの転送）する。しかし、ＣＡＣ＃１のキャッシュメモリは、更新されていないので「キャッシュ無効」の状態（キャッシュ・ミスヒット状態）である。
【００１６】
（３）共通メモリＣＭへのリードアクセス（図１１）：
ＣＡＣ＃１が「キャッシュ無効」の状態であることから共通メモリＣＭに対してリードアクセス（読出アドレスの転送）を行なう。すなわち、ＣＡＣ＃１は、スレーブであることを知っているので、キャッシュ無効であっても自分で更新しないで共通メモリＣＭを見に行く。この時、ＣＡＣ＃２では、スヌープ動作（ＣＭ， ＣＡＣ＃１， ＣＡＣ＃２は同一バスで接続されていることからＣＡＣ＃１−共通メモリＣＭ間のアクセスを監視する動作）を行っている。
【００１７】
（４）共通メモリＣＭ，ＣＡＣ＃２からの返送（図１２）：
共通メモリＣＭでは、（メインメモリの更新はされていないが、）読み出し時にパリティエラーのアクセス異常がなければステータスを正常（アクセスオーダのみが正常の意味）として返送する。この時、スヌープしていたＣＡＣ＃２は、「非共有・書き換え有り」の状態であることから共通メモリＣＭが正常を示すステータスコード（“０００１”）を返送するタイミングでリトライ信号を同時にアサートする（図１５（１）参照）。ＣＡＣ＃１は、返送されたステータスとリトライ信号からリトライアクセスとして処理し、一定時間後に再アクセスを行なう。
【００１８】
（５）共通メモリＣＭへＣＡＣ＃２のキャッシュ内容の書込（図１３）：
ＣＡＣ＃２は、共通メモリＣＭへライトアクセス（書込アドレス及びデータの転送）し、ＣＡＣ＃２のキャッシュメモリの内容を共通メモリＣＭへ書き込む（コピーバック）。このように共通メモリＣＭへ一旦書き込めば、ＣＰＵを更に増やした構成にした場合でも全ＣＰＵのキャッシュに対してメモリの更新をしなくても済む。
【００１９】
（６）ＣＡＣ＃１リトライアクセス・キャッシュ書換，ＭＰＵ＃１リードデータ受信（図１４）：
ＣＡＣ＃１は、一定時間が経つとリトライアクセス（上記（３）と同じリードアクセス）し、読み出したデータでＣＡＣ＃１のキャッシュメモリを更新すると同時にＭＰＵ＃１へリードデータを転送する。
【００２０】
上記手順例のように従来のシステムにおいてＣＡＣ＃１は、正常を示すステータスコード（“０００１”）とリトライ信号アサートによりリトライと判定しリトライ指示を出力している。
【００２１】
一方、図示のようにマルチプロセッサ構成のバスＢＵＳに拡張アダプタＢＥＸを接続している場合、拡張アダプタＢＥＸ（これも上記のようにステータス信号及びリトライ信号を発生し得る）は、バッファフルの時にエラー処理とならないようにＣＰＵがキャッシュ・ミスヒットしたように動作し、その間に（ＣＰＵがコピーバック中と判断し一定時間後にリトライを行う迄に）バッファフルを解除するように作り込む必要がある。
【００２２】
これを図１６の従来例で説明すると、上記のようなバス転送処理システムには、各ＣＰＵ＃１，＃２がバスＢＵＳ２に接続されているが、このバスＢＵＳ２とＣＰＵ＃１，＃２との間にはそれぞれステータス受信判定回路ＳＲＪ１，ＳＲＪ２が挿入接続されている。
【００２３】
このステータス受信判定回路ＳＲＪ１，ＳＲＪ２は、受信したステータスコードを識別するデコーダ１と、このデコーダ１の出力信号の内のステータスコード“０００１”識別出力を除くステータスコード“００１０−０１１０”の論理和を取ってエラー判定出力を発生するＯＲゲート２と、ＯＲゲート２の出力信号の反転値とバスＢＵＳ２からのリトライ信号との論理積を取ってリトライ指示信号を発生するＡＮＤゲート２１と、ステータスコード“０００１”識別出力とリトライ信号の反転値との論理積を取って受信データを取り込むべきか否かを判定するＡＮＤゲート２２とで構成されている。
【００２４】
このようなステータス受信判定回路ＳＲＪ１，ＳＲＪ２がバス転送処理システムに設けられている場合には、図７に示したようにバッファフルの場合にはステータスコードが“００１０”となるので、このデータはデコーダ１及びＯＲゲート２を経てエラー判定として出力されてしまい、且つＡＮＤゲート２１をディスエーブル状態にしてしまうのでリトライ信号の値に関わらずリトライ指示が出ないこととなる（図１５（２）参照）。
【００２５】
これは、「バッファフル」という状態が本来エラー処理を必要とするものではないにも関わらず、エラー処理として時間を要する面倒な処理が実行されてしまうことを意味している。
【００２６】
また、共通メモリＣＭのアクセス自体がステータスの異常を示すステータスコード“００１０−０１１０”であればマルチプロセッサ動作自体が継続して運転（処理）を続けることはできなくなり、その場合はシステムの再起動（ＩＰＬ）などの動作から行なうことが必要となるからである。
【００２７】
このような不都合を避けるため、図１６の従来のバス転送処理システムには、さらにステータス制御回路ＳＣＣがバスＢＵＳ２と拡張アダプタＢＥＸとの間に接続されている。
【００２８】
このステータス制御回路ＳＣＣは、拡張アダプタＢＥＸからのステータスコードをデコードするデコーダ１１と、このデコーダ１１の出力信号とリトライ信号との論理積を取るＡＮＤゲート１２と、ステータスコード“０００１”の発生回路１３と、ＡＮＤゲート１２の出力信号により受信したステータスコード又はステータスデータ発生回路１３を選択してステータス出力を発生するセレクタ１４とで構成されている。
【００２９】
このステータス制御回路ＳＣＣでは、バッファフルの場合はキャッシュ・ミスヒット時同様にデコーダ１１の出力信号が“１”となり、リトライ信号アサート（“１”）をＡＮＤゲート１２で検出し、さらに共通メモリＣＭと同様に正常を示すステータスコード（”０００１”）をセレクタ１４で選択して返送している。
【００３０】
すなわち、バッファフルのデータ“００１０”を正常を示すステータスコード“０００１”にステータス変換していることになる。
【００３１】
【発明が解決しようとする課題】
上記のようにバス転送処理システムにおいて、ステータス受信判定回路ＳＲＪだけでなくステータス制御回路ＳＣＣも付加したハードウェアを実現すると上記のように障害（エラー）の内容によりステータス変更やリトライ信号のゲート制御が必要となり、その結果次のような問題を生ずる。
【００３２】
▲１▼ステータス内容の解析からリトライ信号アサート迄に時間がかかってしまう。すなわち、システムバスはクロック同期でありステータスの確定した出力をＣＰＵが次のサイクルで確実にサンプリングするため（図１７（１）の例）には、バスクロック自体を遅くする必要が出て来る（さもなければ、同図（２）に示すように次のサイクルで正確にサンプリングできず、リトライ指示が出ずにエラー判定が出てしまう）。それにより、システムバス自体の転送能力の低下を招くという問題があった。
【００３３】
▲２▼さらにステータス制御回路追加でハード量が増加する為コストアップの要因にもなっている。
【００３４】
したがって本発明は、複数のＣＰＵと共通メモリが同一バスに接続され、且つ該バスに複数のＩＯが共通の拡張アダプタを介して接続されているバス転送処理システムにおいて、ステータス制御回路を使用することなく小さなハードウェア規模で確実にステータス受信判定を行いリトライ指示を可能にすることを目的とする。
【００３５】
【課題を解決するための手段】
上記の目的を達成するため、本発明に係るバス転送処理システムは、該複数のＣＰＵのいずれかから送信されたオーダおよびアドレスに対して、該アドレスで指定される該共通メモリから、または該アドレスで指定される該ＩＯが接続された該拡張アダプタから、クロックに同期してステータスコードを返送する手段を有し、各ＣＰＵと該バスとの間に、該バスから該ステータスコードを受信した時に、同時に、該バスから受信したリトライ信号がアサート状態のとき、該ステータスコードの値に関わらず接続されたＣＰＵに対してリトライ処理の指示を出すと共に該受信したリトライ信号がネゲート状態のとき、該同時に受信したステータスコードの値が正常状態を示していれば受信可能の判定を出力し、該ステータスコードの値が異常状態を示していればエラー判定を出力するステータス受信判定回路を接続したことを特徴としている。
【００３６】
この場合、上記のステータス信号は、該共通メモリ又は該拡張アダプタから発生され、該リトライ信号はＣＰＵ又は該拡張アダプタから発生され得るものである。
【００３７】
すなわち、本発明では、各ＣＰＵと該バスとの間に設けたステータス受信判定回路が、例えばマスタのＣＰＵ側からバスを介してリトライ信号を受けたとき、共通メモリ又は拡張アダプタのステータスに関わらずそのリトライ信号をそのまま対応するＣＰＵに送り、該ＣＰＵはリトライ処理を実行する。
【００３８】
したがって、該バスに接続された拡張アダプタが例えばバッファフルであっても該拡張アダプタは常にリトライ信号をアサートするので、正確にリトライ処理を指示することになる。
【００４０】
さらに上記のステータス受信判定回路は、該リトライ信号のアサート状態が所定回数に達した後は該リトライ処理の指示を出さないことができる。
【００４１】
すなわち、障害等でバッファフル状態がスタックした場合などにもリトライ信号が返送されて無限にリトライ処理が続いてしまう（無限リトライ状態）ことがないようにするため、リトライ信号によりリトライした回数が一定値を越えた場合は、再度リトライを行なわないようにしている。
【００４２】
この場合、リトライ信号がアサート状態でスタックした場合にも、リトライ処理が続いてしまうので、これを無くすためにリトライ信号アサート回数が一定値を越えた場合は、エラー処理の指示を出すようにしてもよい。
【００４３】
さらに、上記のステータス受信判定回路は、前記ＣＰＵから、該ＣＰＵがプログラム処理停止状態であることを示す信号を検出したときに該リトライ処理が繰り返されている場合は、再度該リトライ処理の指示を出さないことも可能である。
【００４４】
すなわち、プログラム処理の停止状態を監視する機能がある装置において、プログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合は、再度リトライを行なわないようにすることもできる。
【００４５】
【発明の実施の形態】
図１は、本発明に係るバス転送処理システムの実施例を示したもので、この実施例では、ステータス制御回路は用いず、ステータス受信判定回路ＳＲＪ１，ＳＲＪ２ではバスＢＵＳ２からのリトライ信号をそのままリトライ指示信号として出力しており、さらに、受信したステータスを識別するデコーダ１と、このデコーダ１の出力信号の内のステータスコード“０００１”識別出力を除くステータスコード“００１０−０１１０”の論理和を取るＯＲゲート２と、ステータスコード“０００１”識別出力とリトライ信号の反転値との論理積を取って受信データを取り込むべきか否かを判定するＡＮＤゲート３と、ＯＲゲート２の出力信号と該リトライ信号の反転値との論理積を取ってエラー判定信号を出力するＡＮＤゲート４と、で構成されている。
【００４６】
すなわち、従来例では図１６に示したようにステータス制御回路を経て入力されたステータスをデコードした値を参照し「エラー判定」、「リトライ指示」を出していたが、本実施例では「リトライ指示」は以下のようにステータスに関係なくリトライ信号がアサートされていると「リトライ指示」が“１”となるように構成している。
【００４７】
この実施例の動作においては、▲１▼バスＢＵＳ２から受信したリトライ信号がアサート状態の時、そのまま出力されるのでリトライ指示を出力することになる。また、▲２▼該リトライ信号がネゲート状態の時はステータスのデコード結果が反映され、ステータスが正常の時、デコーダ１のステータスコード“０００１”識別出力が“１”となるのでＡＮＤゲート３は“１”となり受信可能の判定出力（アクセスが終了）を行う。さらに、▲３▼該リトライ信号がネゲート状態でステータス異常のときは、ステータスコード“００１０−０１１０”識別出力のいずれかが“１”となるのでＯＲゲート２の出力も“１”となり、ＡＮＤゲート４の出力はエラー判定を示す“１”となる。
【００４８】
これを図２について説明すると、まず同図（１）に示す正常アクセス時の例は図１２に示した従来例のコピーバック・キャッシュ処理手順（４）に相当し、共通メモリＣＭからの正常を示すステータスコード（”０００１”）でＣＰＵ＃２からリトライ信号がアサートされた場合に該リトライ信号そのものによりリトライ処理となる。
【００４９】
この場合、拡張アダプタＢＥＸでバッファフルとなる場合のアクセス時（図２（２）参照）では、マルチプロセッサ構成に拡張アダプタＢＥＸが接続されていてもＣＰＵ＃２からのリトライ信号がアサートされていることよりＡＮＤゲート４の出力は“０”となり、ＣＰＵ＃１においてエラーと判定されずリトライ処理と判定される。
【００５０】
一方、図１の実施例では、障害等でバッファフル状態がスタックした場合などにもリトライ信号が返送されて無限リトライとなってしまう欠点がある。この欠点を解決する方法としては次のものが考えられる。
【００５１】
（１）リトライ信号によりリトライした回数が一定値を越えた場合は、再度リトライを行なわない。
（２）プログラム処理の停止状態を監視する機能がある装置において、プログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合は、再度リトライを行なわない。
【００５２】
また、リトライ信号がアサート状態（“１”）にスタックした場合にリトライが続いてしまうという欠点があり、これについては、
（３）リトライ信号のアサート回数が一定値を越えた場合は、エラー処理とする、ことで解決することができる。
【００５３】
図３は、本発明に係るバス転送処理システムの実施例（２）を示し、特にステータス受信判定回路ＳＲＪの変形例を示したものである。
【００５４】
この実施例では、上記（１）のリトライ信号によりリトライした回数が一定値を越えた場合に再度リトライを行なわない方法と、上記（３）のリトライ信号アサート回数が一定値を越えた場合はエラー処理とする方法を実現する実施例となっている。
【００５５】
すなわち、図１に示したデコーダ１とＯＲゲート２とＡＮＤゲート３，４に加えて、ＡＮＤゲート３の出力信号を入力するロード入力端子ＬＤとバスＢＵＳ２からのリトライ信号を入力するイネーブル端子ＥＮとクロック端子ＣＫとを有する８ビット・カウンタ５と、このカウンタ５のキャリ・オーバ出力Ｃｏの反転値と該リトライ信号とを入力するＡＮＤゲート６と、該リトライ信号と該キャリ・オーバ出力Ｃｏとを入力するＡＮＤゲート７と、このＡＮＤゲート７の出力信号とＡＮＤゲート４の出力信号とを入力するＯＲゲート８とで構成され、ＡＮＤゲート６の出力信号をリトライ指示信号とし、ＡＮＤゲート３の出力信号を受信判定信号とし、ＯＲゲート８の出力信号をエラー判定信号としている。
【００５６】
動作においては、カウンタ５でリトライ信号がアサートされた数をクロックによりカウントしている。リトライ信号がネゲートされており正常を示すステータスコード（“０００１”）を検出した時は、ＡＮＤゲート３の出力信号が“１”となりカウンタ５をクリアする。
【００５７】
リトライ信号が２５５回繰り返しアサートされるとカウンタ５のキャリ・オーバがアサートされＡＮＤゲート６をディスエーブル状態にしてリトライ指示信号をマスクする。マスクされた状態で再びリトライ信号を受信した場合は、ＡＮＤゲート７の出力信号が“１”となりＯＲゲート８を介してエラー判定信号がアサートされ、異常ステータス受信と判定される。
【００５８】
図４は、本発明に係るバス転送処理システムの実施例（３）を示し、特にステータス受信判定回路ＳＲＪのさらに別の変形例を示したものである。この実施例は、上記（２）のプログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合に、再度リトライを行なわない方法を実現するものである。
【００５９】
すなわち、、図３の実施例におけるカウンタ５の代わり、リトライ信号とデコーダ１のステータスコード識別（“０００１”）端子とＯＲゲート２の各出力信号を入力するＯＲゲート９と、このＯＲゲート９の出力信号とＣＰＵ側に設けたウォッチドッグタイマＷＤＴからのキャリ・オーバ信号とを入力して出力信号をＡＮＤゲート６，７に与えるラッチ回路（Ｊ−Ｋフリップフロップ）１０を設けている点が異なっている。なお、ＣＰＵの中に設けたウォッチドッグタイマＷＤＴは、クロックにより更新されるカウンタであり周期的にソフトがクリアするタイマである。
【００６０】
動作において、バスでリトライ信号によりアクセスが無限リトライとなっている場合は、ソフト走行できないため、このクリアが行なわれずウォッチドッグタイマＷＤＴのキャリ・オーバ出力Ｃｏがアサートされる。
【００６１】
このキャリ・オーバ出力Ｃｏをラッチ回路１０でラッチし、ＯＲゲート９からのリトライ信号入力をマスクする。マスクされた状態で再びリトライ信号を受信した場合は、エラー判定信号がアサートされ異常ステータス受信と判定されるように構成されている。
【００６２】
【発明の効果】
上記のように、本発明に係るバス転送処理システムによれば、拡張アダプタ側でステータス解析しリトライとの出力を確定するステータス制御回路を削除できるため、クリティカルパスは改善され、かつ、回路量も削減することができる。
【００６３】
ただし、拡張アダプタで他の障害によるエラーステータスを返送した場合もリトライが返送されて固定障害の場合は、無限リトライとなってしまう。しかし、無限リトライに対しては、▲１▼リトライによりリトライ回数をカウントして有限回とする、▲２▼ウォッチドッグタイマなどでスタック状態を検出し再起動を行なう、ことで回避することができる。
【図面の簡単な説明】
【図１】本発明に係るバス転送処理システムの実施例（１）を示したブロック回路図である。
【図２】本発明に係るバス転送処理システムの動作を説明するためのフローチャート図である。
【図３】本発明に係るバス転送処理システムの実施例（２）を示したブロック回路図である。
【図４】本発明に係るバス転送処理システムの実施例（３）を示したブロック回路図である。
【図５】拡張アダプタを介したＣＰＵとＩＯの接続構成例を示したブロック図である。
【図６】図５の基本的なアクセス処理を示したタイムチャート図である。
【図７】本発明及び従来例で用いるステータスコード例を示した図である。
【図８】図５においてリトライ信号が発生したときのタイムチャート図である。
【図９】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（１）を示したブロック図である。
【図１０】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（２）を示したブロック図である。
【図１１】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（３）を示したブロック図である。
【図１２】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（４）を示したブロック図である。
【図１３】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（５）を示したブロック図である。
【図１４】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（６）を示したブロック図である。
【図１５】図９〜図１４のバス転送処理システムにおける動作を説明するためのタイムチャート図である。
【図１６】ステータス制御回路を含む従来のバス転送処理システムを示したブロック回路図である。
【図１７】図１６の従来例の動作を説明するためのタイムチャート図である。
【符号の説明】
ＳＲＪ１，ＳＲＪ２ ステータス受信判定回路
ＣＭ 共通メモリ
ＢＥＸ 拡張アダプタ
４０ ＩＯ
ＢＵＳ１，ＢＵＳ２ バス
１ デコーダ
２，９ ＯＲゲート
３，４，６，７ ＡＮＤゲート
５ カウンタ
１０ ラッチ回路
ＷＤＴ ウォッチドッグタイマ
図中、同一符号は同一又は相当部分を示す。
本発明はバス転送処理システムに関し、特にＣＰＵが接続されているｎビット幅のバスに拡張アダプタを介してＩＯ（入出力装置）が接続されているバス転送処理システムに関する。
【０００１】
【従来技術】
図５には、ＣＰＵ＃１とＩＯ４０がバスＢＵＳに接続されるとともに、ＩＯ４０が複数（ＩＯ＃１〜＃３）接続される場合、バスＢＵＳの負荷を軽減する為に拡張アダプタＢＥＸを介してＣＰＵ＃１とＩＯ４０を接続したバス転送処理システムが示されている。
【０００２】
このバス転送処理システムにおける、ＣＰＵ＃１から拡張アダプタＢＥＸを介してＩＯ４０に対して行う基本的なリードアクセス動作を図６を参照して説明する。
【０００３】
（１）ＣＰＵ＃１よりアクセス種別（リード／ライト、アクセスワード数等の情報でこれを図示のように“オーダ”（ｏｒｄｅｒ） と記す）とＩＯ４０へアクセスするためのアドレス（ａｄｄと記す）をクロックに従って転送する。
（２）オーダとアドレスを受信した拡張アダプタＢＥＸはその内容を判定する。判定結果からＣＰＵ＃１へ、図７に詳細に示すようなステータスコードを返送する。この場合に、正常を示すステータスコード（“０００１”）を返送した場合には、ＩＯ４０からデータを読み出す。以降、ステータスコードが示す状態については、図７を参照する。
【０００４】
（３）データをＩＯ４０から読出した拡張アダプタＢＥＸはＣＰＵ＃１へアクセス種別（返送の場合アンサ（ａｎｓと記す）とデータ（ｄａｔａと記す）を返送する。
（４）アンサ及びデータを正常（パリティエラー等なし）に受信するとＣＰＵ＃１は拡張アダプタＢＥＸへ正常を示すステータスコード（“０００１”）を返送し、リードアクセスが終了となる。なお、オーダとアンサが返送されるまでの時間は可変である。
【０００５】
次に、このバス転送処理システムにおいてＣＰＵ＃１における処理が時分割にされるような時にアクセス種別（オーダ）の優先順位によりリトライ処理となる場合について説明する。
【０００６】
このアクセス種別（オーダ）には、優先順位を示すビットが設けられており、そのビットが“１”になっているアクセス種別（オーダ）は優先順位が高くなり、そのアクセスについての処理が優先される。優先順位によりリトライ処理となる場合を図８（１）を参照して説明する。
【０００７】
（１）拡張アダプタＢＥＸがＣＰＵ＃１から優先順位が高いアクセス種別（オーダ）“ｏｒｄｅｒ１”とＩＯ４０からデータを読出すアドレスとを受信する。
（２）受信した拡張アダプタＢＥＸはオーダ及びアドレスを判定する。判定結果が正常な（パリティエラー等がない）時、ＣＰＵ＃１へ正常を示すステータスコード（”０００１”）を返送する。また、正常を示すステータスコードを返送した場合には、オーダに従って処理する。
【０００８】
（３）拡張アダプタＢＥＸが上記アクセス種別（オーダ）“ｏｒｄｅｒ１”処理中に優先順位が低いアクセス種別（オーダ）“ｏｒｄｅｒ２”とＩＯ４０からデータを読出すアドレスとを受信する。
（４）拡張アダプタＢＥＸは、正常を示すステータスコード（“０００１”）とオーダの優先順位が低いことからリトライ信号をＣＰＵ＃１へ返送する。
（５）ＣＰＵ＃１は一定期間後、リトライとなったアクセス種別（オーダ）“ｏｒｄｅｒ２”を再転送するリトライ処理を行い、拡張アダプタＢＥＸでアクセス種別（オーダ）“ｏｒｄｅｒ１”の処理が終了していればアクセス種別（オーダ）“ｏｒｄｅｒ２”の処理を実行する。
【０００９】
更に、この装置においてＣＰＵ＃１における処理が時分割で行われるような時に、拡張アダプタＢＥＸを介したＩＯ４０からのデータ読出しに時間がかかり拡張アダプタＢＥＸからＣＰＵ＃１への応答がある以前にＣＰＵ＃１からＩＯ４０へのアクセスが次々に起こる（輻輳する）場合について図８（２）を参照して説明する。
【００１０】
すなわち、ＣＰＵ＃１からＩＯ４０へのアクセスが輻輳し拡張アダプタＢＥＸがバッファフルとなるようなアクセスの場合は次の処理手順になる。
【００１１】
（１）ＣＰＵ＃１よりアクセス種別（オーダ）“ｏｒｄｅｒ３”とＩＯ４０からデータを読出すアドレスを転送する。
（２）受信した拡張アダプタＢＥＸがＩＯ４０から（１）に対するデータを読み出す前にＣＰＵ＃１からＩＯ４０へのアクセス種別（オーダ）“ｏｒｄｅｒ４”と読出しアドレスが転送され、その結果輻輳することになる。
（３）拡張アダプタＢＥＸがバッファフル状態となる。
（４）アクセス種別（オーダ）“ｏｒｄｅｒ４“に対してリトライ信号をアサートし、異常を示すステータスコード（バッファフル：“００１０”）を返送し、ＣＰＵ＃１にてリトライ処理を実行する。
【００１２】
上記の例では単一のＣＰＵの場合について説明したが、複数のＣＰＵによるマルチプロセッサ構成について説明すると、この構成は図９〜図１４に示すように、ｎビット幅のバスＢＵＳ上に同一の処理を実施するＣＰＵ＃１とＣＰＵ＃２を接続し、ＣＰＵの信頼性を高めるものとなっている。
【００１３】
このマルチプロセッサ構成におけるステータスコードとリトライ信号による処理例としてコピーバック・キャッシュのアクセス手順の一例を示す。なお、ＣＰＵ＃１，＃２はそれぞれ自分がスレーブ，マスタであることを知っているものとする。さらにステータスコードとリトライ信号は上記の拡張アダプタを介さない場合を例にとったが、拡張アダプタについても同様に上記のとおりステータスコードとリトライ信号が発生し得るものである。
【００１４】
（１）ＣＰＵ＃２での処理（図９）：
マスタ側のＣＰＵ＃２におけるＭＰＵ＃２からライトアクセス（書込アドレス及びデータの転送）し、ＣＡＣ（Ｃａｓｈ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）＃２内のキャッシュメモリ（図示せず）を更新する。このとき共通メモリＣＭは必ず未更新状態であるので、ＣＡＣ＃２における制御では、キャッシュメモリの状態を「キャッシュ無効」から「非共有・書き換え有り」に遷移する。
【００１５】
（２）ＣＰＵ＃１での処理（図１０）：
ＭＰＵ＃１からＣＡＣ＃１のキャッシュメモリにリードアクセス（データを読出すアドレスの転送）する。しかし、ＣＡＣ＃１のキャッシュメモリは、更新されていないので「キャッシュ無効」の状態（キャッシュ・ミスヒット状態）である。
【００１６】
（３）共通メモリＣＭへのリードアクセス（図１１）：
ＣＡＣ＃１が「キャッシュ無効」の状態であることから共通メモリＣＭに対してリードアクセス（読出アドレスの転送）を行なう。すなわち、ＣＡＣ＃１は、スレーブであることを知っているので、キャッシュ無効であっても自分で更新しないで共通メモリＣＭを見に行く。この時、ＣＡＣ＃２では、スヌープ動作（ＣＭ， ＣＡＣ＃１， ＣＡＣ＃２は同一バスで接続されていることからＣＡＣ＃１−共通メモリＣＭ間のアクセスを監視する動作）を行っている。
【００１７】
（４）共通メモリＣＭ，ＣＡＣ＃２からの返送（図１２）：
共通メモリＣＭでは、（メインメモリの更新はされていないが、）読み出し時にパリティエラーのアクセス異常がなければステータスを正常（アクセスオーダのみが正常の意味）として返送する。この時、スヌープしていたＣＡＣ＃２は、「非共有・書き換え有り」の状態であることから共通メモリＣＭが正常を示すステータスコード（“０００１”）を返送するタイミングでリトライ信号を同時にアサートする（図１５（１）参照）。ＣＡＣ＃１は、返送されたステータスとリトライ信号からリトライアクセスとして処理し、一定時間後に再アクセスを行なう。
【００１８】
（５）共通メモリＣＭへＣＡＣ＃２のキャッシュ内容の書込（図１３）：
ＣＡＣ＃２は、共通メモリＣＭへライトアクセス（書込アドレス及びデータの転送）し、ＣＡＣ＃２のキャッシュメモリの内容を共通メモリＣＭへ書き込む（コピーバック）。このように共通メモリＣＭへ一旦書き込めば、ＣＰＵを更に増やした構成にした場合でも全ＣＰＵのキャッシュに対してメモリの更新をしなくても済む。
【００１９】
（６）ＣＡＣ＃１リトライアクセス・キャッシュ書換，ＭＰＵ＃１リードデータ受信（図１４）：
ＣＡＣ＃１は、一定時間が経つとリトライアクセス（上記（３）と同じリードアクセス）し、読み出したデータでＣＡＣ＃１のキャッシュメモリを更新すると同時にＭＰＵ＃１へリードデータを転送する。
【００２０】
上記手順例のように従来のシステムにおいてＣＡＣ＃１は、正常を示すステータスコード（“０００１”）とリトライ信号アサートによりリトライと判定しリトライ指示を出力している。
【００２１】
一方、図示のようにマルチプロセッサ構成のバスＢＵＳに拡張アダプタＢＥＸを接続している場合、拡張アダプタＢＥＸ（これも上記のようにステータス信号及びリトライ信号を発生し得る）は、バッファフルの時にエラー処理とならないようにＣＰＵがキャッシュ・ミスヒットしたように動作し、その間に（ＣＰＵがコピーバック中と判断し一定時間後にリトライを行う迄に）バッファフルを解除するように作り込む必要がある。
【００２２】
これを図１６の従来例で説明すると、上記のようなバス転送処理システムには、各ＣＰＵ＃１，＃２がバスＢＵＳ２に接続されているが、このバスＢＵＳ２とＣＰＵ＃１，＃２との間にはそれぞれステータス受信判定回路ＳＲＪ１，ＳＲＪ２が挿入接続されている。
【００２３】
このステータス受信判定回路ＳＲＪ１，ＳＲＪ２は、受信したステータスコードを識別するデコーダ１と、このデコーダ１の出力信号の内のステータスコード“０００１”識別出力を除くステータスコード“００１０−０１１０”の論理和を取ってエラー判定出力を発生するＯＲゲート２と、ＯＲゲート２の出力信号の反転値とバスＢＵＳ２からのリトライ信号との論理積を取ってリトライ指示信号を発生するＡＮＤゲート２１と、ステータスコード“０００１”識別出力とリトライ信号の反転値との論理積を取って受信データを取り込むべきか否かを判定するＡＮＤゲート２２とで構成されている。
【００２４】
このようなステータス受信判定回路ＳＲＪ１，ＳＲＪ２がバス転送処理システムに設けられている場合には、図７に示したようにバッファフルの場合にはステータスコードが“００１０”となるので、このデータはデコーダ１及びＯＲゲート２を経てエラー判定として出力されてしまい、且つＡＮＤゲート２１をディスエーブル状態にしてしまうのでリトライ信号の値に関わらずリトライ指示が出ないこととなる（図１５（２）参照）。
【００２５】
これは、「バッファフル」という状態が本来エラー処理を必要とするものではないにも関わらず、エラー処理として時間を要する面倒な処理が実行されてしまうことを意味している。
【００２６】
また、共通メモリＣＭのアクセス自体がステータスの異常を示すステータスコード“００１０−０１１０”であればマルチプロセッサ動作自体が継続して運転（処理）を続けることはできなくなり、その場合はシステムの再起動（ＩＰＬ）などの動作から行なうことが必要となるからである。
【００２７】
このような不都合を避けるため、図１６の従来のバス転送処理システムには、さらにステータス制御回路ＳＣＣがバスＢＵＳ２と拡張アダプタＢＥＸとの間に接続されている。
【００２８】
このステータス制御回路ＳＣＣは、拡張アダプタＢＥＸからのステータスコードをデコードするデコーダ１１と、このデコーダ１１の出力信号とリトライ信号との論理積を取るＡＮＤゲート１２と、ステータスコード“０００１”の発生回路１３と、ＡＮＤゲート１２の出力信号により受信したステータスコード又はステータスデータ発生回路１３を選択してステータス出力を発生するセレクタ１４とで構成されている。
【００２９】
このステータス制御回路ＳＣＣでは、バッファフルの場合はキャッシュ・ミスヒット時同様にデコーダ１１の出力信号が“１”となり、リトライ信号アサート（“１”）をＡＮＤゲート１２で検出し、さらに共通メモリＣＭと同様に正常を示すステータスコード（”０００１”）をセレクタ１４で選択して返送している。
【００３０】
すなわち、バッファフルのデータ“００１０”を正常を示すステータスコード“０００１”にステータス変換していることになる。
【００３１】
【発明が解決しようとする課題】
上記のようにバス転送処理システムにおいて、ステータス受信判定回路ＳＲＪだけでなくステータス制御回路ＳＣＣも付加したハードウェアを実現すると上記のように障害（エラー）の内容によりステータス変更やリトライ信号のゲート制御が必要となり、その結果次のような問題を生ずる。
【００３２】
▲１▼ステータス内容の解析からリトライ信号アサート迄に時間がかかってしまう。すなわち、システムバスはクロック同期でありステータスの確定した出力をＣＰＵが次のサイクルで確実にサンプリングするため（図１７（１）の例）には、バスクロック自体を遅くする必要が出て来る（さもなければ、同図（２）に示すように次のサイクルで正確にサンプリングできず、リトライ指示が出ずにエラー判定が出てしまう）。それにより、システムバス自体の転送能力の低下を招くという問題があった。
【００３３】
▲２▼さらにステータス制御回路追加でハード量が増加する為コストアップの要因にもなっている。
【００３４】
したがって本発明は、複数のＣＰＵと共通メモリが同一バスに接続され、且つ該バスに複数のＩＯが共通の拡張アダプタを介して接続されているバス転送処理システムにおいて、ステータス制御回路を使用することなく小さなハードウェア規模で確実にステータス受信判定を行いリトライ指示を可能にすることを目的とする。
【００３５】
【課題を解決するための手段】
上記の目的を達成するため、本発明に係るバス転送処理システムは、該複数のＣＰＵのいずれかから送信されたオーダおよびアドレスに対して、該アドレスで指定される該共通メモリから、または該アドレスで指定される該ＩＯが接続された該拡張アダプタから、クロックに同期してステータスコードを返送する手段を有し、各ＣＰＵと該バスとの間に、該バスから該ステータスコードを受信した時に、同時に、該バスから受信したリトライ信号がアサート状態のとき、該ステータスコードの値に関わらず接続されたＣＰＵに対してリトライ処理の指示を出すと共に該受信したリトライ信号がネゲート状態のとき、該同時に受信したステータスコードの値が正常状態を示していれば受信可能の判定を出力し、該ステータスコードの値が異常状態を示していればエラー判定を出力するステータス受信判定回路を接続したことを特徴としている。
【００３６】
この場合、上記のステータス信号は、該共通メモリ又は該拡張アダプタから発生され、該リトライ信号はＣＰＵ又は該拡張アダプタから発生され得るものである。
【００３７】
すなわち、本発明では、各ＣＰＵと該バスとの間に設けたステータス受信判定回路が、例えばマスタのＣＰＵ側からバスを介してリトライ信号を受けたとき、共通メモリ又は拡張アダプタのステータスに関わらずそのリトライ信号をそのまま対応するＣＰＵに送り、該ＣＰＵはリトライ処理を実行する。
【００３８】
したがって、該バスに接続された拡張アダプタが例えばバッファフルであっても該拡張アダプタは常にリトライ信号をアサートするので、正確にリトライ処理を指示することになる。
【００４０】
さらに上記のステータス受信判定回路は、該リトライ信号のアサート状態が所定回数に達した後は該リトライ処理の指示を出さないことができる。
【００４１】
すなわち、障害等でバッファフル状態がスタックした場合などにもリトライ信号が返送されて無限にリトライ処理が続いてしまう（無限リトライ状態）ことがないようにするため、リトライ信号によりリトライした回数が一定値を越えた場合は、再度リトライを行なわないようにしている。
【００４２】
この場合、リトライ信号がアサート状態でスタックした場合にも、リトライ処理が続いてしまうので、これを無くすためにリトライ信号アサート回数が一定値を越えた場合は、エラー処理の指示を出すようにしてもよい。
【００４３】
さらに、上記のステータス受信判定回路は、前記ＣＰＵから、該ＣＰＵがプログラム処理停止状態であることを示す信号を検出したときに該リトライ処理が繰り返されている場合は、再度該リトライ処理の指示を出さないことも可能である。
【００４４】
すなわち、プログラム処理の停止状態を監視する機能がある装置において、プログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合は、再度リトライを行なわないようにすることもできる。
【００４５】
【発明の実施の形態】
図１は、本発明に係るバス転送処理システムの実施例を示したもので、この実施例では、ステータス制御回路は用いず、ステータス受信判定回路ＳＲＪ１，ＳＲＪ２ではバスＢＵＳ２からのリトライ信号をそのままリトライ指示信号として出力しており、さらに、受信したステータスを識別するデコーダ１と、このデコーダ１の出力信号の内のステータスコード“０００１”識別出力を除くステータスコード“００１０−０１１０”の論理和を取るＯＲゲート２と、ステータスコード“０００１”識別出力とリトライ信号の反転値との論理積を取って受信データを取り込むべきか否かを判定するＡＮＤゲート３と、ＯＲゲート２の出力信号と該リトライ信号の反転値との論理積を取ってエラー判定信号を出力するＡＮＤゲート４と、で構成されている。
【００４６】
すなわち、従来例では図１６に示したようにステータス制御回路を経て入力されたステータスをデコードした値を参照し「エラー判定」、「リトライ指示」を出していたが、本実施例では「リトライ指示」は以下のようにステータスに関係なくリトライ信号がアサートされていると「リトライ指示」が“１”となるように構成している。
【００４７】
この実施例の動作においては、▲１▼バスＢＵＳ２から受信したリトライ信号がアサート状態の時、そのまま出力されるのでリトライ指示を出力することになる。また、▲２▼該リトライ信号がネゲート状態の時はステータスのデコード結果が反映され、ステータスが正常の時、デコーダ１のステータスコード“０００１”識別出力が“１”となるのでＡＮＤゲート３は“１”となり受信可能の判定出力（アクセスが終了）を行う。さらに、▲３▼該リトライ信号がネゲート状態でステータス異常のときは、ステータスコード“００１０−０１１０”識別出力のいずれかが“１”となるのでＯＲゲート２の出力も“１”となり、ＡＮＤゲート４の出力はエラー判定を示す“１”となる。
【００４８】
これを図２について説明すると、まず同図（１）に示す正常アクセス時の例は図１２に示した従来例のコピーバック・キャッシュ処理手順（４）に相当し、共通メモリＣＭからの正常を示すステータスコード（”０００１”）でＣＰＵ＃２からリトライ信号がアサートされた場合に該リトライ信号そのものによりリトライ処理となる。
【００４９】
この場合、拡張アダプタＢＥＸでバッファフルとなる場合のアクセス時（図２（２）参照）では、マルチプロセッサ構成に拡張アダプタＢＥＸが接続されていてもＣＰＵ＃２からのリトライ信号がアサートされていることよりＡＮＤゲート４の出力は“０”となり、ＣＰＵ＃１においてエラーと判定されずリトライ処理と判定される。
【００５０】
一方、図１の実施例では、障害等でバッファフル状態がスタックした場合などにもリトライ信号が返送されて無限リトライとなってしまう欠点がある。この欠点を解決する方法としては次のものが考えられる。
【００５１】
（１）リトライ信号によりリトライした回数が一定値を越えた場合は、再度リトライを行なわない。
（２）プログラム処理の停止状態を監視する機能がある装置において、プログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合は、再度リトライを行なわない。
【００５２】
また、リトライ信号がアサート状態（“１”）にスタックした場合にリトライが続いてしまうという欠点があり、これについては、
（３）リトライ信号のアサート回数が一定値を越えた場合は、エラー処理とする、ことで解決することができる。
【００５３】
図３は、本発明に係るバス転送処理システムの実施例（２）を示し、特にステータス受信判定回路ＳＲＪの変形例を示したものである。
【００５４】
この実施例では、上記（１）のリトライ信号によりリトライした回数が一定値を越えた場合に再度リトライを行なわない方法と、上記（３）のリトライ信号アサート回数が一定値を越えた場合はエラー処理とする方法を実現する実施例となっている。
【００５５】
すなわち、図１に示したデコーダ１とＯＲゲート２とＡＮＤゲート３，４に加えて、ＡＮＤゲート３の出力信号を入力するロード入力端子ＬＤとバスＢＵＳ２からのリトライ信号を入力するイネーブル端子ＥＮとクロック端子ＣＫとを有する８ビット・カウンタ５と、このカウンタ５のキャリ・オーバ出力Ｃｏの反転値と該リトライ信号とを入力するＡＮＤゲート６と、該リトライ信号と該キャリ・オーバ出力Ｃｏとを入力するＡＮＤゲート７と、このＡＮＤゲート７の出力信号とＡＮＤゲート４の出力信号とを入力するＯＲゲート８とで構成され、ＡＮＤゲート６の出力信号をリトライ指示信号とし、ＡＮＤゲート３の出力信号を受信判定信号とし、ＯＲゲート８の出力信号をエラー判定信号としている。
【００５６】
動作においては、カウンタ５でリトライ信号がアサートされた数をクロックによりカウントしている。リトライ信号がネゲートされており正常を示すステータスコード（“０００１”）を検出した時は、ＡＮＤゲート３の出力信号が“１”となりカウンタ５をクリアする。
【００５７】
リトライ信号が２５５回繰り返しアサートされるとカウンタ５のキャリ・オーバがアサートされＡＮＤゲート６をディスエーブル状態にしてリトライ指示信号をマスクする。マスクされた状態で再びリトライ信号を受信した場合は、ＡＮＤゲート７の出力信号が“１”となりＯＲゲート８を介してエラー判定信号がアサートされ、異常ステータス受信と判定される。
【００５８】
図４は、本発明に係るバス転送処理システムの実施例（３）を示し、特にステータス受信判定回路ＳＲＪのさらに別の変形例を示したものである。この実施例は、上記（２）のプログラム処理停止状態を検出した時にリトライ信号によりリトライが繰り返されている場合に、再度リトライを行なわない方法を実現するものである。
【００５９】
すなわち、、図３の実施例におけるカウンタ５の代わり、リトライ信号とデコーダ１のステータスコード識別（“０００１”）端子とＯＲゲート２の各出力信号を入力するＯＲゲート９と、このＯＲゲート９の出力信号とＣＰＵ側に設けたウォッチドッグタイマＷＤＴからのキャリ・オーバ信号とを入力して出力信号をＡＮＤゲート６，７に与えるラッチ回路（Ｊ−Ｋフリップフロップ）１０を設けている点が異なっている。なお、ＣＰＵの中に設けたウォッチドッグタイマＷＤＴは、クロックにより更新されるカウンタであり周期的にソフトがクリアするタイマである。
【００６０】
動作において、バスでリトライ信号によりアクセスが無限リトライとなっている場合は、ソフト走行できないため、このクリアが行なわれずウォッチドッグタイマＷＤＴのキャリ・オーバ出力Ｃｏがアサートされる。
【００６１】
このキャリ・オーバ出力Ｃｏをラッチ回路１０でラッチし、ＯＲゲート９からのリトライ信号入力をマスクする。マスクされた状態で再びリトライ信号を受信した場合は、エラー判定信号がアサートされ異常ステータス受信と判定されるように構成されている。
【００６２】
【発明の効果】
上記のように、本発明に係るバス転送処理システムによれば、拡張アダプタ側でステータス解析しリトライとの出力を確定するステータス制御回路を削除できるため、クリティカルパスは改善され、かつ、回路量も削減することができる。
【００６３】
ただし、拡張アダプタで他の障害によるエラーステータスを返送した場合もリトライが返送されて固定障害の場合は、無限リトライとなってしまう。しかし、無限リトライに対しては、▲１▼リトライによりリトライ回数をカウントして有限回とする、▲２▼ウォッチドッグタイマなどでスタック状態を検出し再起動を行なう、ことで回避することができる。
【図面の簡単な説明】
【図１】本発明に係るバス転送処理システムの実施例（１）を示したブロック回路図である。
【図２】本発明に係るバス転送処理システムの動作を説明するためのフローチャート図である。
【図３】本発明に係るバス転送処理システムの実施例（２）を示したブロック回路図である。
【図４】本発明に係るバス転送処理システムの実施例（３）を示したブロック回路図である。
【図５】拡張アダプタを介したＣＰＵとＩＯの接続構成例を示したブロック図である。
【図６】図５の基本的なアクセス処理を示したタイムチャート図である。
【図７】本発明及び従来例で用いるステータスコード例を示した図である。
【図８】図５においてリトライ信号が発生したときのタイムチャート図である。
【図９】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（１）を示したブロック図である。
【図１０】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（２）を示したブロック図である。
【図１１】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（３）を示したブロック図である。
【図１２】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（４）を示したブロック図である。
【図１３】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（５）を示したブロック図である。
【図１４】マルチプロセッサ構成のバス転送処理システムにおけるコピー・バックキャッシュのアクセス手順例（６）を示したブロック図である。
【図１５】図９〜図１４のバス転送処理システムにおける動作を説明するためのタイムチャート図である。
【図１６】ステータス制御回路を含む従来のバス転送処理システムを示したブロック回路図である。
【図１７】図１６の従来例の動作を説明するためのタイムチャート図である。
【符号の説明】
ＳＲＪ１，ＳＲＪ２ ステータス受信判定回路
ＣＭ 共通メモリ
ＢＥＸ 拡張アダプタ
４０ ＩＯ
ＢＵＳ１，ＢＵＳ２ バス
１ デコーダ
２，９ ＯＲゲート
３，４，６，７ ＡＮＤゲート
５ カウンタ
１０ ラッチ回路
ＷＤＴ ウォッチドッグタイマ
図中、同一符号は同一又は相当部分を示す。
Claims (5)
- 複数のＣＰＵと共通メモリが同一バスに接続され、且つ該バスに複数のＩＯが共通の拡張アダプタを介して接続されているバス転送処理システムにおいて、
該複数のＣＰＵのいずれかから送信されたオーダおよびアドレスに対して、該アドレスで指定される該共通メモリから、または該アドレスで指定される該ＩＯが接続された該拡張アダプタから、クロックに同期してステータスコードを返送する手段を有し、
各ＣＰＵと該バスとの間に、該バスから該ステータスコードを受信した時に、同時に、該バスから受信したリトライ信号がアサート状態のとき、該ステータスコードの値に関わらず接続されたＣＰＵに対してリトライ処理の指示を出すと共に該受信したリトライ信号がネゲート状態のとき、該同時に受信したステータスコードの値が正常状態を示していれば受信可能の判定を出力し、該ステータスコードの値が異常状態を示していればエラー判定を出力するステータス受信判定回路を接続したことを特徴とするバス転送処理システム。 - 請求項１において、
該ステータス信号が、該共通メモリ又は該拡張アダプタから発生され、該リトライ信号がＣＰＵ又は該拡張アダプタから発生されたことを特徴とするバス転送処理システム。 - 請求項１又は２において、
該ステータス受信判定回路は、該リトライ信号がアサート状態になるリトライ回数が所定回数に達した後は該リトライ処理の指示を出さないことを特徴とするバス転送処理システム。 - 請求項３において、
該ステータス受信判定回路は、該リトライ処理の指示を出さない状態で再度リトライ信号を受けたときには、エラー処理の指示を出すことを特徴としたバス転送処理システム。 - 請求項１において、
該ステータス受信判定回路は、前記ＣＰＵから、該ＣＰＵがプログラム処理停止状態であることを示す信号を検出したときに該リトライ処理が繰り返されている場合は、再度該リトライ処理の指示を出さないことを特徴としたバス転送処理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10331197A JP3630523B2 (ja) | 1997-04-21 | 1997-04-21 | バス転送処理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10331197A JP3630523B2 (ja) | 1997-04-21 | 1997-04-21 | バス転送処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10293743A JPH10293743A (ja) | 1998-11-04 |
| JP3630523B2 true JP3630523B2 (ja) | 2005-03-16 |
Family
ID=14350675
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10331197A Expired - Fee Related JP3630523B2 (ja) | 1997-04-21 | 1997-04-21 | バス転送処理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3630523B2 (ja) |
-
1997
- 1997-04-21 JP JP10331197A patent/JP3630523B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10293743A (ja) | 1998-11-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US4939643A (en) | Fault tolerant digital data processor with improved bus protocol | |
| US5226150A (en) | Apparatus for suppressing an error report from an address for which an error has already been reported | |
| EP0422103B1 (en) | I/o bus to system bus interface | |
| JP2565642B2 (ja) | マルチプロセッサのための拡張プロセッサバッファインターフェース | |
| US5426765A (en) | Multiprocessor cache abitration | |
| US6604060B1 (en) | Method and apparatus for determining CC-NUMA intra-processor delays | |
| US5640508A (en) | Fault detecting apparatus for a microprocessor system | |
| US7406632B2 (en) | Error reporting network in multiprocessor computer | |
| US20030037280A1 (en) | Computer memory error management system and method | |
| US5966728A (en) | Computer system and method for snooping date writes to cacheable memory locations in an expansion memory device | |
| US6108735A (en) | Method and apparatus for responding to unclaimed bus transactions | |
| US5938777A (en) | Cycle list based bus cycle resolution checking in a bus bridge verification system | |
| US5557622A (en) | Method and apparatus for parity generation | |
| JP3630523B2 (ja) | バス転送処理システム | |
| WO1998009221A1 (en) | Method and apparatus for supporting multiple overlapping address spaces on a shared bus | |
| JP3862777B2 (ja) | 二重化データ一致化方法および二重化制御装置 | |
| KR970002400B1 (ko) | 다중프로세서 인터럽트 요청기에서의 인터럽트 송신 및 완료 제어방법(Control scheme of interrupt go and done in a multiprocessor interrupt requester) | |
| KR960015586B1 (ko) | 다중프로세서 인터럽트 요청기에서의 전송 실패 인터럽트의 구동방법 | |
| KR920010969B1 (ko) | 공유 캐쉬 메모리의 경로로의 접근제어방법 | |
| Somani et al. | An echo-back protocol for a fault tolerant bus architecture | |
| JPH02297650A (ja) | 受信装置 | |
| JPS6320641A (ja) | メモリアクセス方式 | |
| JP2000348001A (ja) | メモリ制御回路及びそれに用いるメモリ障害検出方法並びにその制御プログラムを記録した記録媒体 | |
| JPH0195356A (ja) | マルチプロセッサ装置 | |
| JPH05289946A (ja) | メモリ制御方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040511 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040712 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040803 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040915 |
|
| 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: 20041214 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041214 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071224 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101224 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101224 Year of fee payment: 6 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101224 Year of fee payment: 6 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101224 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111224 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111224 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121224 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121224 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131224 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |