バスアクセスエラー処理方式

【目的】バスアクセスエラーを処理する方式に関し、ＣＰＵにおけるバスアクセスエラーに対する処理を簡単にするとともに、活線保守可能なバスの延長を容易にすることを目的とする。
【構成】バスアクセスエラーの発生時、すなわちバス２を介するＣＰＵ１から被制御デバイス３に対するアクセスが正常に終了しなかったとき、被制御デバイス３からバスエラー信号をＣＰＵ１に返送することによって、ＣＰＵ１が基本プログラムに基づいて例外処理を実行するシステムにおいて、ＣＰＵ１がバスエラー信号を受信したとき、バスアクセスエラー発生を対応するフラグ４に表示することによって、ユーザプログラム側でバスアクセスエラー発生時の回避処理を実行可能にすることで構成する。

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、バスアクセスエラーを処理する方式に関し、特に中央処理装置（ＣＰＵ）におけるバスアクセスエラーに対する処理を簡単にするとともに、活線保守可能なバスの延長を容易にしたバスアクセスエラー処理方式に関するものである。
【０００２】
【従来の技術】従来、高機能なＣＰＵにおいては、一般に、ＣＰＵからバスをアクセスした結果、アクセスされた側が障害等のため、正常にアクセスできなかった場合等に、ＣＰＵに対してバスエラー（ＢＥＲＲ）信号をアサートすることによって、ＣＰＵに例外割り込みを発生させる機能が具備されている。
【０００３】図１３は、ＣＰＵにおけるＢＥＲＲの位置付けを示したものであって、ＣＰＵ１１と被制御デバイス１２の間において、ＣＰＵ１１からのアドレス信号ＡＤＤと、リード／ライト制御信号Ｒ／Ｗとに応じて、ＣＰＵ１１と被制御デバイス１２間でデータ信号ＤＡＴＡの授受が行われ、データの転送の処理が終了したとき、被制御デバイス１２からＣＰＵ１１に対してデータ転送終了信号＊ＤＣが送出されるとともに、バスアクセスエラー発生時、バスエラー信号＊ＢＥＲＲが被制御デバイス１２からＣＰＵ１１に対して送出されることが示されている。
【０００４】このような機能を使用すれば、該当アクセス部が存在しなかったり、パリティエラーが発生した場合等のように、障害が発生したときに、ＣＰＵが直ちに致命的な状態に遷移することなく、ＣＰＵのハードウェアが割り込みを発生することによって、基本プログラム中の例外処理部で障害原因を判定して、再実行や、異常時の回避処理に移行することができる。
【０００５】しかしながら、この方式では、システムを構築する場合に、例外処理部のソフトウェアをシステム構成に合わせて作成する必要があるとともに、システムが拡張されたような場合には、基本的な例外処理部に対しても、変更を加える必要が生じる。
【０００６】また、あるアドレス空間をアクセスしたときバスエラーが発生する可能性がある場合には、ソフトウェアをプログラミングする際に、バスエラー発生時の回避処理を記述した番地を、例外処理部に登録するなどして、バスエラー割り込み発生時の処理に対応する必要がある。このように従来の方式では、ソフトウェアの記述が複雑になる。
【０００７】また、近年において、プロセッサを使用した制御系の場合、その規模が大きくなるのに伴って、システムの機能を分割して、複数のパッケージによって、所望の機能を構成するようにしたシステムが増加している。
【０００８】このようなシステムでは、あるパッケージに障害が発生した場合等に、すべての機能を停止することなく、全体の機能としては運転を継続しながら、故障したパッケージのみを交換する、いわゆる活線保守が可能なようにすることが要求されている。
【０００９】このような場合には、ＣＰＵが該当部をアクセスしようとしたとき、パッケージが存在しないと、ＣＰＵからのアクセスに対してバスエラーを発生させることが可能であるが、この場合のエラー原因はパッケージがないためであるから、パッケージの不存在を判断することによって、処理を継続することが可能となる。
【００１０】しかしながら、このような判断を例外処理部に記述することは、システムを複雑にする。すなわち、従来のＣＰＵの例外処理は、本来発生しない筈の事象が発生した場合の処理を記述したものであって、致命的なエラーと考えられている。従って、活線保守を行うシステム等においては、利用しづらい面がある。
【００１１】また、ＣＰＵのバスを延長する場合には、直接、バスを延長する方式の他に、通信ＬＳＩ等を利用して、ＣＰＵの命令を他のプロトコルに変換して遠隔にアクセスする方式が一般に用いられている。
【００１２】図１４は、通信ＬＳＩを用いたバス延長方式のイメージを示したものであって、ＣＰＵ搭載パッケージ１３に、ＣＰＵ１４とＣＰＵバスで接続された通信ＬＳＩ１５を設けるととにも、被制御パッケージ１６にも、被制御デバイス１７とＣＰＵバスで接続された通信ＬＳＩ１８を設け、両通信ＬＳＩ１５，１８間において、それぞれのＣＰＵの命令をあるプロトコルに変換して、往路の通信路と復路の通信路とを経て通信を行うことによって、バスを延長することが示されている。
【００１３】この場合における、一般的な通信ＬＳＩのプログラミングは、以下のようなものである。
■ 送り元アドレスをＬＳＩに設定する。
■ 宛て先アドレスをＬＳＩに設定する。
■ 転送データをＬＳＩに書き込むことによって、ＬＳＩに起動をかけ、通信を開始する。
■ 相手からの応答を待ち、応答情報を受け取る。
【００１４】このように、通信ＬＳＩを用いたバス延長方式では、ＣＰＵは直接、相手に対してデータを書いたり、読んだりすることはできず、所定の手順（プロトコル）に基づいて、処理を行うことが必要である。
【００１５】この方式では、ある空間をアクセスする際に、ＣＰＵの命令で直接アクセスするのではなく、通信ＬＳＩを制御して通信を行う必要がある。そのため、このような方式では、プログラムが複雑化するとともに、処理に時間がかかることになる。
【００１６】
【発明が解決しようとする課題】上述のように、バスエラー発生時、ＣＰＵが例外割り込みを発生する方式では、システムを構築する際、基本プログラム中の例外処理部のソフトウェアをシステム構成に合わせて作成する必要があるとともに、システムの拡張時には、基本的な例外処理部に対しても、変更を加える必要が生じるとともに、バスエラーが発生する可能性がある場合には、ソフトウェア作成時、バスエラー発生時の回避処理を記述した番地を、例外処理部に登録する等のように、バスエラー割り込み発生時の処理に対応する必要がある。このように従来の方式では、ソフトウェアの記述が複雑になるという問題がある。
【００１７】また、活線保守を行うために、パッケージの不存在の判断を例外処理部に記述することは、システムを複雑にするとともに、従来のＣＰＵの例外処理は、活線保守を行うシステム等においては、利用しづらい面があるという問題がある。
【００１８】さらに、ＣＰＵのバスを延長する際に、通信ＬＳＩを制御して通信を行う方式では、プログラムが複雑化するとともに、処理に時間がかかるという問題がある。
【００１９】本発明は、このような従来技術の課題を解決しようとするものであって、バスエラー発生時における例外処理部のソフトウェアをシステム構成に合わせて作成する必要がなく、システムの拡張時に、基本的な例外処理部に対して、変更を加える必要がなく、ユーザ側で回避処理を簡単に記述できるとともに、活線保守が可能なシステムに対してバスの拡張が容易であり、また単純にＣＰＵバスを延長できないシステムにおいても、簡単に活線保守が可能なプログラミングを記述できるバスアクセスエラー処理方式を提供することを目的としている。
【００２０】
【課題を解決するための手段】
(1) 図１は、本発明の原理的構成を示したものである。本発明は、ＣＰＵ１からのバス２を介する被制御デバイス３へのアクセスが正常に終了しないバスアクセスエラーの発生時、被制御デバイス３からバスエラー信号をＣＰＵ１に返送することによってＣＰＵ１が基本プログラムに基づいて例外処理を実行するシステムにおいて、バスエラー信号受信時、ＣＰＵ１がバスアクセスエラー発生を対応するフラグ４に表示することによって、ユーザプログラム側でバスアクセスエラー発生時の回避処理を実行可能にしたものである。
【００２１】(2) また本発明は(1) において、ユーザプログラム側における回避処理が、バスアクセスエラー発生時、ＣＰＵ１がユーザプログラムにおける次の実行ステップを退避して例外処理へトラップし、この例外処理においてバスアクセスエラーを発生したアドレス空間がシステムに致命的影響を与えないものであることを判断したとき、例外処理を終了して退避されているユーザプログラムへ戻るものである。
【００２２】(3) また本発明は(2) において、ユーザプログラムは、バスアクセスエラーが発生する可能性があるアドレス空間をアクセスする際には、アクセス後、フラグ４を確認してから次の処理を行うものである。
【００２３】(4) また本発明は(1) において、基本プログラムにおいて使用する第１のバスエラー信号と、ユーザプログラムにおいて使用する第２のバスエラー信号とを設け、第１のバスエラー信号発生時には例外処理を実行し、第２のバスエラー信号発生時にはフラグ４に表示して処理を継続するものである。
【００２４】(5) また本発明は(4) において、ユーザプログラムは、バスアクセスエラーが発生する可能性があるアドレス空間をアクセスする際には、アクセス後、フラグ４を確認してから次の処理を行うものである。
【００２５】(6) また本発明は(1) または(2) において、ＣＰＵ１と被制御デバイス３とが異なるパッケージに収容される場合に、活線保守可能なシステムを構築するものである。
【００２６】(7) また本発明は(1) または(2) において、ＣＰＵ１と被制御デバイス３とが異なるパッケージに収容される場合に、それぞれのパッケージにフラグ４の内容を中継可能な通信手段５，６を設け、通信手段５，６を介して通信を行うことによって、活線保守可能なシステムを構築するものである。
【００２７】
【作用】バスエラー発生時に、すべて例外処理ルーチンで処理するのではなく、アクセスを行ったプログラム側にそのアクセスでバスエラーが発生したことを通知できれば、プログラム側でバスエラー時の回避処理を記述することができ、上述のような、従来技術の問題点を解決することが可能となる。
【００２８】バスエラー発生の通知は、ＣＰＵに具備されているフラグに、バスエラー時にセットできるフラグを追加することによって実現できる。このようなバスエラーに対応するフラグに基づく、問題解決の方法としては、次のようなものがある。
【００２９】■ ＣＰＵへの＊ＢＥＲＲ信号がアサートされると、一応、例外処理割り込みが発生し、内容を例外処理部で判断したのち、ユーザ側（通常のプログラム側）へ返却する方法。
【００３０】■ ＣＰＵへの＊ＢＥＲＲ信号として、ユーザプログラム側で使用する＊ＢＥＲＲ２信号と、基本プログラム（ＯＳ）側で使用する＊ＢＥＲＲ１信号とを設ける。基本プログラム側で使用する＊ＢＥＲＲ１がＣＰＵにアサートされると、例外処理が発生して、そこで処理が実行される。ユーザ側で使用する＊ＢＥＲＲ２がＣＰＵにアサートされると、バスエラーフラグをセットして、そのまま処理を継続する方法。
【００３１】図２は、＊ＢＥＲＲ１信号と＊ＢＥＲＲ２信号の使用方法を示したものであって、ＣＰＵ２１に対して、メモリ２２から＊ＢＥＲＲ１が入力され、通信用ＬＳＩ２３から＊ＢＥＲＲ２が入力されることが示されている。
【００３２】＊ＢＥＲＲ１と＊ＢＥＲＲ２の２つの信号の使い方としては、バスエラーが発生すると、システムに致命的な影響を与え、基本プログラムの介在が必要となる場合には、＊ＢＥＲＲ１を用いる。一方、バスエラーが発生しても、局所的な影響しかなく、ユーザ側で対処可能なときは、＊ＢＥＲＲ２を使用する。例えば、バスの拡張の箇所で発生したバスエラー等は、＊ＢＥＲＲ２に入力し、メモリ等で発生したバスエラー等は、＊ＢＥＲＲ１に入力する。
【００３３】上述の■の方法について詳細に説明する。以下においては、バスエラーが発生した際の例外処理の場合の例について示す。
【００３４】バスエラーが発生したとき、ＣＰＵは内部のレジスタにバスエラーに対応するフラグをセットして、例外処理へトラップする。トラップする際には、スタック上に、ユーザプログラムで次に実行するプログラムカウンタと、実行時のフラグとを退避するとともに、現在まで動作していたプログラムカウンタと、アクセスしていた空間およびデータを退避してあるものとする。
【００３５】バスエラーによる例外処理では、アクセスしていたアドレス空間を確認後、その空間がシステムに致命的な影響を与えない空間であると判断した場合には、例外処理を終了してユーザプログラムに戻る。この際、スタック上に退避されていたフラグが、再度ＣＰＵに設定されるので、ユーザプログラム側でバスエラーフラグがセットされていることを確認できる。
【００３６】ユーザプログラム側では、バスエラーが発生する可能性があるアドレス空間をアクセスする場合には、アクセスしたあとで、必ずエラーフラグを確認して、もしもセットされていた場合には、異常処理を実行する。もしもクリアされたままであった場合は、アクセスに成功しているので、処理を継続する。
【００３７】上述の■の方法について詳細に説明する。以下においては、バスエラーが発生した際の例外処理の場合の例について示す。
【００３８】ユーザプログラムが処理するバスエラーは＊ＢＥＲＲ２に接続する。ＣＰＵが＊ＢＥＲＲ２がアサートされたことを認識した場合には、バスエラーフラグをセットして、処理を継続する。
【００３９】ユーザプログラム側では、■の方法と同様に、バスエラーが発生する可能性があるアドレス空間をアクセスする場合には、アクセスしたあとで、必ず、エラーフラグを確認して、もしもセットされていた場合には、異常処理を実行する。もしも、エラーフラグがクリアされたままであった場合には、アクセスに成功しているので、処理を継続する。
【００４０】■の方法では、ＣＰＵのハードウェアが、＊ＢＥＲＲ１と＊ＢＥＲＲ２とを認識できるため、＊ＢＥＲＲ２がアサートされた場合には、例外処理を行わず、そのまま処理を継続することが可能である。
【００４１】以上説明した■と■のどちらの方法でも実現可能である。この方式を用いれば、バスを延長するときにも、延長用のデバイスで相手の応答がない等のプロトコルエラーを検出した場合に、バスエラー信号としてＣＰＵに返送すれば、プログラム上でプロトコルを書き込まなくても、通常のＣＰＵの命令を使用して、バスを延長することが可能である。
【００４２】すなわち、通信用のＬＳＩは、直接、ＣＰＵバスを通信信号に変換し、コマンドを送出して応答を待つ。無応答の場合には、ＣＰＵに対してバスエラー信号を返送する。こうすることによって、プログラム上ではあるアドレス空間にアクセスしたのち、バスエラーフラグを確認するだけで、処理の完了と未完了の判断を行うことができる。
【００４３】
【実施例】以下においては、まず本発明の一実施例としてのＣＰＵのモデルを説明する。図３は、フラグの構成例を示したものである。Ｚはゼロフラグであって、演算結果がゼロか否かを反映する。Ｎはネガティブフラグであって、演算結果が負か否かを反映する。Ｖはオーバフラグであって、オーバフローの発生を反映する。Ｃはキャリアフラグであって、キャリアの発生を反映する。Ｅはバスエラーフラグであって、バスエラーの発生を反映する。
【００４４】以上のフラグは“０”でネゲート、“１”でアサートの意味とされる。これらのフラグは、Ｅフラグを除いて、一般的に使用されているフラグであり、その他のフラグが存在しても、または、他のフラグで代替されても差し支えない。
【００４５】分岐命令は、以下のようなものである。Ｅフラグの状態によって、分岐をするか否かの命令を、以下にモデルとして示す。
ＢＥＳＢｒａｎｃｈＥｒｒｏｒＳｅｔ（Ｅフラグ＝１のときブランチする）
ＢＥＣＢｒａｎｃｈＥｒｒｏｒＣｌｅａｒ（Ｅフラグ＝０のときブランチする）
【００４６】Ｅフラグの制御命令は、以下のようなものである。Ｅフラグをプログラムで強制的にクリアしたり、セットしたりする命令を示す。
ＳＥＥＳｅｔＥｒｒｏｒｆｌａｇ（Ｅフラグを１に設定する）
ＣＬＥＣｌｅａｒＥｒｒｏｒｆｌａｇ（Ｅフラグを０に設定する）
【００４７】Ｅフラグの設定動作は、以下のようなものである。空間アクセス命令でアドレス空間をアクセスした場合に、バスエラーで終了した場合にはＥ＝１とし、ＣＬＥ命令が実行されるまでは、フラグにセットされたままである。空間アクセス命令で空間をアクセスした場合に、正常に終了した場合には、変化しない。
【００４８】なお、上述の方法■の場合には、ＢＥＲＲが発生した場合に、Ｅフラグはセットされるが、そのフラグは例外処理ルーチンにトラップする際に、スタック上に保存され、例外処理が終了して本来のプログラムに戻る際に、再度Ｅフラグに反映されるものとする。
【００４９】図４は、バスエラーフラグの実現方法を示すハードウェア（１）のブロック図であって、前述の方法■に対応している。図中において３１，３２はアンドゲート、３３はオアゲート、３４はリセットセット（ＲＳ）フリップフロップ、３５はトライステートバッファである。
【００５０】図４において、アンドゲート３１は、リセット信号＊ＲＥＳＥＴとＣＬＥ命令実行時のアクセスとの論理積によって出力を発生して、ＲＳフリップフロップ３４のリセット端子Ｒに入力する。一方、オアゲート３３は、＊ＢＥＲＲ信号と＊ＤＣ信号との論理和によって出力を発生する。オアゲート３３の出力は、例外処理の起動用信号になるとともに、アンドゲート３２に入力される。アンドゲート３２は、オアゲート３３の出力とＳＥＥ命令実行時のアクセスとの論理積によって出力を発生して、ＲＳフリップフロップ３４のセット端子Ｓに入力する。
【００５１】ＲＳフリップフロップ３４は、リセット端子Ｒの入力によってリセットし、セット端子Ｓの入力によってセットして、ＯＵＴに出力を発生する。ＲＳフリップフロップ３４の出力は、分岐命令に使用されるとともに、入力ＩＮからトライステートバッファ３５に書き込まれ、フラグの読みだしアクセスに応じてＯＵＴに出力を発生して、データバスに送られる。
【００５２】図５は、バスエラーフラグの実現方法を示すハードウェア（２）のブロック図であって、前述の方法■に対応している。図中において、図４におけると同じものを同じ番号で示している。
【００５３】図５において、アンドゲート３１は、リセット信号＊ＲＥＳＥＴとＣＬＥ命令実行時のアクセスとの論理積によって出力を発生して、ＲＳフリップフロップ３４のリセット端子Ｒに入力する。一方、オアゲート３３は、＊ＢＥＲＲ２信号と＊ＤＣ信号との論理和によって出力を発生し、アンドゲート３２は、オアゲート３３の出力とＳＥＥ命令実行時のアクセスとの論理積によって出力を発生して、ＲＳフリップフロップ３４のセット端子Ｓに入力する。
【００５４】ＲＳフリップフロップ３４は、リセット端子Ｒの入力によってリセットし、セット端子Ｓの入力によってセットして、ＯＵＴに出力を発生する。ＲＳフリップフロップ３４の出力は、分岐命令に使用されるとともに、入力ＩＮからトライステートバッファ３５に書き込まれ、フラグの読みだしアクセスに応じてＯＵＴに出力を発生して、データバスに送られる。
【００５５】以下においては、上述のＣＰＵのモデルに基づいて、あるアドレス空間（被制御デバイス）をアクセスする場合のプログラムの例を示す。
MOVE #1000,a4000 ; データ1000をアドレス4000番地に書く BES NOPKG ; もしバスエラーの場合にはNOPKG 番地にブランチ・ ; 正常アクセス時の継続動作プログラム・NOPKG: CLE ; Ｅフラグのクリア・ ; 被制御デバイスアクセスに失敗した場合の対応・ ; 処理のプログラムの記述・ ; ( 例として、PKG の実装状態を確認した後、未実装と判断した場合は該当PKG を切り離す等の処理)
【００５６】一方、バス拡張用の通信ＬＳＩの機能の実現例を以下に示す。簡単なモデルとして、アドレスバス１６本，データバス１６本，Ｒ／Ｗ信号，ＤＣ，ＢＥＲＲからなる場合を考えるものとする。
【００５７】図６は、多重フォーマットの簡単な例を示したものであって、（ａ）はコマンド（ＣＭＤ）側を示し、（ｂ）はレスポンス（ＲＳＰ）側を示す。
【００５８】図６（ａ）において、ＴＯＰは多重情報の開始を示す１ビットの情報であって、１は開始を示す。Ｒ／Ｗは、リード／ライトを示す１ビットの情報であって、１はリード、０はライトである。ＡＤＤ０：１５は、アドレス情報を示し、１６ビットからなる。ＤＡＴＡ０：１５は、データ情報であって１６ビットからなり、ライト時にデータを多重する。ＰＴＹは、ＴＯＰ〜ＤＡＴＡ０：１５までのパリティである。なおフォーマット上において、情報以外の部分は０とする。実際に多重情報を転送する際には、論理を反転させて、負論理にして転送する。
【００５９】図６（ｂ）において、ＴＯＰは多重情報の開始を示す１ビットの情報であって、１は開始を示す。ＤＣは、完了を示す１ビットの情報であって、１は完了を示す。ＢＥＲＲは、バスエラーが発生したことを示す１ビットの情報であって、１はバスエラーの発生を示す。ＤＡＴＡ０：１５は、データ情報であって１６ビットからなり、リード時にデータを多重する。ＰＴＹは、ＴＯＰ〜ＤＡＴＡ０：１５までのパリティである。なお、フォーマット上において、情報以外の部分は０とする。実際に多重情報を転送する際には、論理を反転させて、負論理にして転送する。
【００６０】図７は、バス拡張用通信ＬＳＩＢＵＳＥＸＰＡを示したものである。ＢＵＳＥＸＰＡは、ＣＰＵからのバスをクロックＣＬＫに同期させて多重し、コマンド（ＣＭＤ）信号に変換して送出する。送出後、相手からの応答を待ち、もしもある時間後にも無応答の場合には、＊ＢＥＲＲ端子からＢＥＲＲ信号をアサートして、ＣＰＵに被制御デバイスが存在しないことを通知する。
【００６１】ＢＵＳＥＸＰＡにおいて、ＣＰＵからのバスにおける、ＡＤＤ，ＤＡＴＡ，Ｒ／ＷがクロックＣＬＫに同期して多重され、コマンド（ＣＭＤ）として出力される。一方、レスポンス（ＲＳＰ）として、ＤＡＴＡ，ＤＣ，ＢＥＲＲが多重され入力される。
【００６２】ＢＵＳＥＸＰＡの内部には、ＣＰＵバス上のどのアドレス空間を外部に拡張するかを設定するレジスタや、応答に対する結果の正常性を保存するレジスタ（無応答や相手側でＢＥＲＲを検出した等の情報）を具備している。
【００６３】ＢＵＳＥＸＰＡにおいては、ＣＡＤＤ０：７で指定されたアドレスがアドレス空間の上位８ビットと一致した場合に、多重して送出するものとする。一例として、４０Ｈを設定すると、アドレス空間で４０００〜４０ＦＦの空間をアクセスされた場合に、多重して外部にデータを送出する。
【００６４】図８は、通信ＬＳＩＢＵＳＥＸＰＡの送信部の内部構成を示すブロック図、図９は通信ＬＳＩＢＵＳＥＸＰＡの受信部の内部構成を示すブロック図である。
【００６５】送信側においては、起動制御部４１において、ＣＡＤＤ０：７で設定されたアドレスと、ＣＰＵバスのアドレスとを比較して、一致した場合にカウンタ（ＣＮＴ）４２を動作させて、多重回路４３に起動をかけて多重を開始する。
【００６６】またタイマ４４にも起動をかけて、受信部でレスポンス（ＲＳＰ）がある時間待ってもない場合には、タイムオーバになることによって、ＤＣ作成部４５に対して、ＤＣとＢＥＲＲをアサートする。
【００６７】また、起動時には、起動制御部４１は受信部における制御部５１に対しても制御をかけることによって、受信待ちになるようにする。
【００６８】多重は、図６にフォーマットを示すように、ＴＯＰに１を挿入し、制御信号ラッチ４６，アドレスラッチ４７，データラッチ４８を経て入力された、Ｒ／Ｗ信号，ＡＤＤ０：１５，ＤＡＴＡ０：１５を順次多重し、最後にパリティ生成部４９において生成されたパリティビットを、合成部５０において付加して、コマンド（ＣＭＤ）として送出する。
【００６９】受信側では、ＴＯＰが１であることを確認すると同時に、分離部５２においてレスポンス（ＲＳＰ）データを分離し、ＤＣ，ＢＥＲＲ，ＤＡＴＡ０：１５に分解するとともに、パリティ監視部５５において、パリティをチェックして、正常の場合には、ＤＡＴＡ０：１５を制御部５１からの受信完了信号に応じて、データラッチ５３，トライステートバッファ５４を経てＣＰＵバスに出力する。
【００７０】さらにＤＣ作成部４５を経てＤＣ，ＢＥＲＲをＣＰＵバスへのせるとともに、タイマ４４に対して停止制御を行う。もしもパリティエラーが発生した場合には、ＬＳＩ内部でＤＣ，ＢＥＲＲをアサートして、バスエラーとして強制的にアクセスを終了させる。
【００７１】図１０は、バス拡張用通信ＬＳＩＢＵＳＥＸＰＢを示したものである。ＢＵＳＥＸＰＢは、多重されたデータを受信して、再度ＣＰＵバスに変換する作用を行う。
【００７２】ＢＵＳＥＸＰＢにおいて、ＣＰＵバスにおける、ＡＤＤ，ＤＡＴＡ，Ｒ／ＷがクロックＣＬＫに同期して多重され、コマンド（ＣＭＤ）を受信し、応答としてＤＡＴＡ，ＤＣ，ＢＥＲＲを多重して、レスポンス（ＲＳＰ）として、ＣＰＵバスに返送する。
【００７３】図１１は、通信ＬＳＩＢＵＳＥＸＰＢの内部構成をブロック図によって示したものである。
【００７４】ＢＵＳＥＸＰＢでは、多重されたコマンド（ＣＭＤ）を監視し、ＴＯＰが１のとき、受信アドレスチェック部６１において、そのあとのアドレスをＲＡＤＤ０：７と比較して、一致したとき、分離部６２を起動し、Ｒ／Ｗ，ＡＤＤ，ＤＡＴＡを分離する。そしてパリティ監視部６３においてパリティが正常のとき、それぞれラッチ６４，６５を経て，Ｒ／Ｗ，ＡＤＤ０：１５を出力し、ラッチ６６，バッファ６７を経て、ＤＡＴＡ０：１５を出力して、拡張側にＣＰＵバスを延長する。
【００７５】その後、被制御部からＤＣおよびＢＥＲＲが返送されたとき、多重回路６８においてデータＤＡＴＡ０：１５を多重して、パリティ生成部６９において生成されたパリティビットを合成部７０において付加して、レスポンス（ＲＳＰ）として返送する。
【００７６】図１２は、バス拡張用通信ＬＳＩの使用例を示したものである。ＣＰＵパッケージ（ＰＫＧ）７１内において、バス拡張用通信ＬＳＩＢＵＳＥＸＰＡ７２を使用し、被制御パッケージ（ＰＫＧ）７３内において、バス拡張用通信ＬＳＩＢＵＳＥＸＰＢ７４を使用して、両通信ＬＳＩＢＵＳＥＸＰＡ７２とＢＵＳＥＸＰＢ７４とを接続することによって、ＣＰＵから被制御デバイス７５に対するバスが延長されることが示されている。
【００７７】
【発明の効果】以上説明したように本発明によれば、ＣＰＵのバスアクセスエラーが発生したとき、ＣＰＵにエラーフラグを設定することによって、ユーザ側でバスエラーの回避処理を簡単に行うことができるようになる。また、このようなユーザ側でバスエラーを認識可能となるＣＰＵを用いることによって、パッケージ間の距離が短いシステムの場合、活線保守可能なシステムに対して、容易にバスの延長を行うことができる。さらにこのようなＣＰＵを用いることによって、パッケージ間の距離が長いシステムの場合は、バス延長用通信ＬＳＩを使用することによって、活線保守可能なシステムに対して、容易にバスの延長を行うことができる。
【図面の簡単な説明】
【図１】本発明の原理的構成を示す図である。
【図２】＊ＢＥＲＲ１信号と＊ＢＥＲＲ２信号の使用方法を示す図である。
【図３】フラグの構成例を示す図である。
【図４】バスエラーフラグの実現方法を示すハードウェア（１）のブロック図である。
【図５】バスエラーフラグの実現方法を示すハードウェア（２）のブロック図である。
【図６】多重フォーマットの簡単な例を示す図であって、（ａ）はコマンド（ＣＭＤ）側を示し、（ｂ）はレスポンス（ＲＳＰ）側を示す。
【図７】バス拡張用通信ＬＳＩＢＵＳＥＸＰＡを示す図である。
【図８】通信ＬＳＩＢＵＳＥＸＰＡの送信部の内部構成を示すブロック図である。
【図９】通信ＬＳＩＢＵＳＥＸＰＡの受信部の内部構成を示すブロック図である。
【図１０】バス拡張用通信ＬＳＩＢＵＳＥＸＰＢを示す図である。
【図１１】通信ＬＳＩＢＵＳＥＸＰＢの内部構成を示すブロック図である。
【図１２】バス拡張用通信ＬＳＩの使用例を示す図である。
【図１３】ＣＰＵにおけるＢＥＲＲの位置付けを示す図である。
【図１４】通信ＬＳＩを用いたバス延長方式のイメージを示す図である。
【符号の説明】
１ＣＰＵ
２バス
３被制御デバイス
４フラグ
５通信手段
６通信手段

【特許請求の範囲】
【請求項１】ＣＰＵ（１）からのバス（２）を介する被制御デバイス（３）へのアクセスが正常に終了しないバスアクセスエラーの発生時、被制御デバイス（３）からバスエラー信号をＣＰＵ（１）に返送することによってＣＰＵ（１）が基本プログラムに基づいて例外処理を実行するシステムにおいて、前記バスエラー信号受信時、ＣＰＵ（１）がバスアクセスエラー発生を対応するフラグ（４）に表示することによって、ユーザプログラム側でバスアクセスエラー発生時の回避処理を実行可能にしたことを特徴とするバスアクセスエラー処理方式。
【請求項２】前記ユーザプログラム側における回避処理が、バスアクセスエラー発生時、ＣＰＵ（１）がユーザプログラムにおける次の実行ステップを退避して例外処理へトラップし、該例外処理においてバスアクセスエラーを発生したアドレス空間がシステムに致命的影響を与えないものであることを判断したとき、該例外処理を終了して退避されているユーザプログラムへ戻ることを特徴とする請求項１に記載のバスアクセスエラー処理方式。
【請求項３】請求項２に記載のバスアクセスエラー処理方式において、ユーザプログラムは、バスアクセスエラーが発生する可能性があるアドレス空間をアクセスする際には、アクセス後、前記フラグ（４）を確認してから次の処理を行うことを特徴とするバスアクセスエラー処理方式。
【請求項４】請求項１に記載のバスアクセスエラー処理方式において、基本プログラムにおいて使用する第１のバスエラー信号と、ユーザプログラムにおいて使用する第２のバスエラー信号とを設け、該第１のバスエラー信号発生時には例外処理を実行し、第２のバスエラー信号発生時には前記フラグ（４）に表示して処理を継続することを特徴とするバスアクセスエラー処理方式。
【請求項５】請求項４に記載のバスアクセスエラー処理方式において、ユーザプログラムは、バスアクセスエラーが発生する可能性があるアドレス空間をアクセスする際には、アクセス後、前記フラグ（４）を確認してから次の処理を行うことを特徴とするバスアクセスエラー処理方式。
【請求項６】前記ＣＰＵ（１）と被制御デバイス（３）とが異なるパッケージに収容される場合に、活線保守可能なシステムを構築することを特徴とする請求項１または２に記載のバスアクセスエラー処理方式。
【請求項７】前記ＣＰＵ（１）と被制御デバイス（３）とが異なるパッケージに収容される場合に、それぞれのパッケージに前記フラグ（４）の内容を中継可能な通信手段（５，６）を設け、該通信手段（５，６）を介して通信を行うことによって、活線保守可能なシステムを構築することを特徴とする請求項１または２に記載のバスアクセスエラー処理方式。

【図１】