(57)【要約】【課題】アロイド予測に基づいてブール論理を使用して、原因となるデバイスをピンポイントすることができる方法および構造を提供すること。【解決手段】ペアワイズ・パーティシパントを有するバスを監視する方法（およびシステム）は、バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出すること、および、どのパーティシパントがこの問題について故障しているか、または、この問題がシステミックなバス問題を含むかどうかを決定することを含む。【選択図】図１
2004192640.tif 000002
【特許請求の範囲】
【請求項１】
ペアワイズ・パーティシパントを有するバスを監視する方法であって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出するステップと、
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定するステップとを含む方法。
【請求項２】
前記決定するステップは、複数のトランザクションを観察するステップ、および前記問題を検出するステップに基づく、請求項１に記載の方法。
【請求項３】
バス上のデバイス・レベルの故障分離の方法であって、
ハードウェア・バス仕様に基づいて、モニタにより、前記ハードウェア・バスの制約が従われているかどうかを検出するステップを含み、
前記モニタが、挙動を記述するためにハードウェア記述言語（ＨＤＬ）を使用して開発され、環境を使用して実施される方法。
【請求項４】
前記環境はエージェントを含む、請求項３に記載の方法。
【請求項５】
エージェントのコントロール下の制約が従われている場合、前記エージェントは正しい信号を生成し、前記エージェントが誤りである信号を生成する場合、前記ハードウェア・バス制約が違反されている、請求項３に記載の方法。
【請求項６】
システム内で故障を分離する方法であって、前記システムはデバイス・ペアをバス上に有し、
故障が発生しているかどうかを判断するステップと、
デバイス・ペアのデバイスの一方が前記故障を引き起こしたかどうかを決定するステップと、
前記デバイスのうち前記一方が前記故障を引き起こしていないと決定される場合、前記故障の原因をバスの故障として識別するステップとを含む方法。
【請求項７】
前記バスは周辺装置相互接続（ＰＣＩ）バスを含む、請求項６に記載の方法。
【請求項８】
前記デバイスはＰＣＩデバイスを含む、請求項６に記載の方法。
【請求項９】
バス上のデバイス・レベルの故障を分離するためのシステムであって、
マスタ・アドレス情報およびターゲット・アドレス情報を受信するためのデバイス・ペア検出器と、
前記デバイス・ペア検出器から出力を受信するためのデバイス・ペア情報レジスタと、
前記デバイス・ペアから出力を受信するためのエラー検出ロジックと、
前記デバイス・ペア検出器およびプロトコル違反チェック・ロジックから出力を受信するためのグローバル情報レジスタと、
前記ターゲットおよび前記マスタがある場合、そのうちのどちらが前記故障の原因であるかを、前記エラー検出ロジックおよび前記グローバル情報レジスタからの出力に基づいて決定するための論理演算ユニットとを含み、
前記論理演算ユニットが、前記ターゲットおよび前記マスタのいずれをも前記原因として識別しない場合、前記論理演算ユニットは、前記原因がシステミックなバス問題を含むと決定するシステム。
【請求項１０】
ターゲット・デバイス情報を得るためのユニットをさらに含む、請求項９に記載のシステム。
【請求項１１】
前記ユニットは、ターゲット・マッピング・モジュールおよびデジタル・ロジックを含み、オペレーティング・システムは、デバイス・アドレスが現れるとき、前記デジタル・ロジックが前記デバイスの識別を示す出力を提供するように前記デジタル・ロジックをセット・アップする、請求項１０に記載のシステム。
【請求項１２】
前記ターゲット情報が、トランザクションに従事する前記デバイス・ペア検出器に入力され、前記デバイス・ペア検出器は前記マスタ・アドレスを前記バスから直接受信し、
前記デバイス・ペア検出器はＡＮＤ演算を実行して、前記出力を前記グローバル情報レジスタおよび前記デバイス・ペア情報レジスタに提供する、請求項１１に記載のシステム。
【請求項１３】
前記グローバル情報レジスタが、モニタベースの手法を使用してプロトコルの違反を決定するための、超高速集積回路設計用ハードウェア記述言語（ＶＨＤＬ）コードによって実施される、請求項９に記載のシステム。
【請求項１４】
前記ＶＨＤＬコードは少なくとも１つのエラー信号を含み、
前記少なくとも１つのエラー信号は、ターゲット・アボート、マスタ・アボート、割り込み信号およびパリティ・エラー（ＰＥＲＲ）信号を含む、請求項１３に記載のシステム。
【請求項１５】
前記グローバル情報レジスタはバス・プロトコル信号を受信し、前記プロトコルは、監視されるべき前記エラー信号に対応する、請求項９に記載のシステム。
【請求項１６】
選択的にトランザクションに関係する少なくとも第１および第２のパーティシパントを含むバスにおける故障分離の方法であって、
バス信号を監視して、前記バスのオペレーションをチェックするステップと、
バス制約が従われているかどうかを決定するステップと、
前記バス制約が従われていない場合、診断ロジックに接触して、それによりエラーのタイプを決定し、前記トランザクションに関係する前記第１および第２のパーティシパントのうち一方へ前記エラーをピンポイントするステップとを含む方法。
【請求項１７】
前記接触するステップは、前記制約を使用してこれらをエラーのタイプに対応付けて、前記エラー・タイプを識別し、かつ後に探し出すことができるようにするステップを含む、請求項１６に記載の方法。
【請求項１８】
エラー情報をオペレーティング・システムに送信するステップをさらに含む、請求項１６に記載の方法。
【請求項１９】
前記エラーを直すための処置を実行するステップをさらに含む、請求項１８に記載の方法。
【請求項２０】
すべてのトランザクションが前記バスに関係し、あるトランザクションが進行中である間にエラー信号が取り込まれる、請求項１６に記載の方法。
【請求項２１】
バス上で特定の故障したデバイスを決定するためのトラブル・シューティングの方法であって、
トランザクションにおける第１および第２のパーティシパントに関係する前記トランザクションにおけるエラーを示すエラー信号を得るステップと、
前記信号が所定の値を有するかどうかを決定するステップと、
前記信号が前記所定の値を有する場合、グローバル情報レジスタにより論理演算を実行して、それにより、前記２つのパーティシパントのうちどちらが問題を有するかを示すステップとを含む方法。
【請求項２２】
前記論理演算は排他的ＯＲ演算を含む、請求項２１に記載の方法。
【請求項２３】
前記エラー信号が第２の所定の値を有する場合、それがマスタの問題であるかターゲットの問題であるかが不確実であると判断するステップと、
問題のタイプおよびどのパーティシパントが前記問題を引き起こしたかを決定するステップとを含み、前記決定するステップは、前記エラー信号および前記グローバル情報レジスタの情報により第２の論理演算を実行して、所定の値を有する信号を得るステップとをさらに含み、
前記信号が第１の所定の値を有する場合、前記問題がバスの問題として識別され、前記信号が第２の所定の値を有する場合、前記問題を引き起こす前記パーティシパントおよびそのオペレーションのモードが決定される、請求項２１に記載の方法。
【請求項２４】
前記第２の論理演算はＡＮＤ演算を含み、前記第１の所定の値は低く、前記第２の所定の値は前記第１の所定の値に対して高い、請求項２３に記載の方法。
【請求項２５】
前記信号が、高い所定の値を有するかどうかを決定するステップと、
前記信号が、低い所定の値を有する場合、エラーがないことを宣言するステップとをさらに含む、請求項２２に記載の方法。
【請求項２６】
前記信号が高い場合、前記マスタのプロトコルが違反されているかどうかを決定するステップであって、前記マスタ・プロトコルは、前記トランザクション内でマスタであった者は誰でも故障していたことを示すステップと、
前記マスタ・プロトコルが違反されていない場合、前記デバイスに問題がないと決定するステップと、
前記マスタ・プロトコルが違反されていると決定される場合、前記デバイスを前記問題の原因として宣言し、そのオペレーションのモードを宣言するステップとをさらに含む、請求項２５に記載の方法。
【請求項２７】
前記所定の値は、「故障なし」または具体的に前記エラーがある所の情報あるいはその両方を示す、請求項２２に記載の方法。
【請求項２８】
前記方法が、前記バスに結合された各デバイスについて並列に実行される、請求項２１に記載の方法。
【請求項２９】
前記エラー検出ロジックは複数の排他的ＯＲゲートを含む、請求項９に記載のシステム。
【請求項３０】
ペアワイズ・パーティシパントを有するバスを監視する方法を実行するために、デジタル処理装置によって実行可能な機械可読命令のプログラムを有形に実施する信号搬送媒体であって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出すること、および
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定することを含む信号搬送媒体。
【請求項３１】
ペアワイズ・パーティシパントを有するバスを監視するためのシステムであって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出するための検出器と、
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定するための決定ユニットとを含むシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にハードウェアの故障を診断するための方法およびシステムに関し、より詳細には、周辺装置相互接続（ＰＣＩ）バス上のデバイスにおける故障を診断するための方法およびシステムに関する。
【背景技術】
【０００２】
ハードウェア予測技術は、ハードウェアのオペレーションを予測するために使用される。ハードウェア・プレディクタを、ある入力ビットおよびその内部状態が与えられると特定のビットの未知の値の予測を出力する有限状態機械として実施することができる。
【０００３】
予測のために使用されるロジックは通常、２つのモードで動作する。第１のモードは「予測モード」（たとえば、入力を受け付け、出力を生成する）と呼ばれ、第２のモードは「更新モード」（たとえば、入力を受け入れ、その過去のレコードを更新する）と呼ばれる。
【０００４】
予測誤りは電力およびサイクルを無駄にするので、これらを回避することが望ましい。この問題を最小限にするため、アロイド・プレディクタ（Alloyed Predictors）が開発されている。これらは、分岐予測のためにグローバル履歴およびローカル履歴に依拠する。これは、予測誤りの数を減らす助けとなる。
【０００５】
ＰＣＩアーキテクチャでは、マスタまたはスレーブがエラーを生じる可能性がある。これらのエラーのいくつかは本質的に重大であり、パリティ・エラーなどであり、これはマスク不可能割り込み（ＮＭＩ）のような重大な割り込みが生じる結果となる可能性があり、さらに結果としてシステムのシャットダウンとなる可能性がある。
【０００６】
ＮＭＩの発生を引き起こす可能性のある他の信号がある。たとえば、トランザクション・フェーズ中のターゲット・アボートは、ＮＭＩの発生に通じる可能性がある。これにより、トランザクション・フェーズ中に問題を引き起こしているデバイスをピンポイントする必要性が生じる。
【０００７】
しかし、本発明より前には、予測誤りに基づいた重みではなくアロイド予測（alloyedprediction）に基づいてブール論理を使用して、原因となる（culprit）デバイスをピンポイントすることができる手法がなかった。その代わりに、従来の手法は履歴テーブルまたはパターン履歴テーブルを必要とし、それによりハードウェアおよびシステムの複雑さが増す結果となった。
【０００８】
さらに従来の手法では、オペレーティング・システム（ＯＳ）は故障の重大性に基づいていかなる必要な処置も取ることができなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来の方法および構造の上述および他の問題、欠点および短所に鑑みて、本発明の例示的目的は、アロイド予測に基づいてブール論理を使用して、原因となるデバイスをピンポイントすることができる方法および構造を提供することである。
【００１０】
もう１つの目的は、履歴テーブルまたはパターン履歴テーブルを必要とせず、それによりハードウェア要件を減らす結果となる方法および構造を提供することである。
【００１１】
さらなる目的は、ＯＳが故障の重大性に基づいていずれかの必要な処置を取ることができる方法および構造を提供することである。
【課題を解決するための手段】
【００１２】
本発明の第１の態様では、ペアワイズ（pair-wise）・パーティシパント（participants）を有するバスを監視する方法（およびシステム）は、第１および第２のパーティシパントの間のトランザクション中に問題を検出すること、および、どのパーティシパントがこの問題について故障しているか、または、この問題がシステミックなバス問題を含むかどうかを決定することを含む。
【００１３】
本発明のユニークかつ明白でない特徴により、原因となるデバイスを、予測誤りに基づいた重みではなくアロイド予測に基づいてブール論理を使用してピンポイントすることができる。加えて、この手法は履歴テーブル（パターン履歴テーブルなど）を必要とせず、それによりハードウェアが低減される結果となる。加えて、本発明により、ＯＳがエラーの重大性に基づいていずれかの必要な処置を取ることができる。
【００１４】
本発明では、ＰＣＩバス仕様に基づいたモニタベースの手法（たとえば、本発明の目的では、これは、システムまたはサブシステムのオペレーションを監視するための外部エージェントの使用を意味する）が、ＰＣＩバス制約が従われているかどうかを検出するために使用される。このモニタは、適切な挙動を記述するためにハードウェア記述言語（ＨＤＬ）を使用して開発されることが好ましく、環境またはエージェントを使用して実施されることが好ましい。
【００１５】
エージェントのコントロール下の制約が従われている場合、エージェントは正しい信号を生成し、これが誤りである信号を生成する場合、ＰＣＩバス制約が違反されている。モニタベースの手法が満たすべきである他の基準がある。
【００１６】
すなわち、このシステムはアイドル状態に戻らなければならず、これはデッドロック状態を発見する助けとなる。加えて、ターミネーション・タイプは単一のトランザクション中に変化しないべきであり、これは、エージェントがあるサイクル内でターゲット・アボートの信号を送り、次いでトランザクションが終了する前に次のクロック・サイクル内でリトライを返すことができるかどうかを、チェックする助けとなる。
【発明を実施するための最良の形態】
【００１７】
このとき、図面、より詳細には図１〜１８を参照して、本発明による方法および構造の好ましい実施形態を示す。読者の理解のため、かつ明確にするために、図においてある特徴を参照するために使用された参照番号は、類似の項目を例示するために図面全体を通じて使用される。
【００１８】
図１は、本発明の手法および環境の上位レベル・アーキテクチャ１００を示し、これはモニタ１１０および複数のエージェント（たとえば、第１および第２のエージェント）１２０、１３０を含み、これらのエージェントがＰＣＩバス１４０を介して共にリンクされる。各エージェントは１つまたは複数のＰＣＩデバイス１１５を含むことができる。２つのモニタ・エージェント１２０、１３０は、それらの監視下でデバイスによって従われるべきＰＣＩ制約をチェックすることを担うように作成されている。
【００１９】
診断ロジック１２５、１３５は各環境（たとえば、エージェント１２０、１３０）に存在し、そのオペレーションのモードにおいて故障したデバイスまたはバスに関係する他のいずれかの問題を管理する。
【００２０】
図１の破線（参照なし）は、ＰＣＩデバイス１１５と診断ロジック１２５、１３５の間のＧＮＴ信号、ＤＥＶＳＥＬ信号、バス・エラー信号、ＰＣＩバス・プロトコル信号などについてのものである。
【００２１】
このように、これらの２つのモニタ・エージェント１２０、１３０が作成されており、これらが、それらの監視下でデバイスによって従われるべきＰＣＩ制約をチェックすることを担うようになる。
【００２２】
全体のシステム・アーキテクチャ２００を図２に示し、アーキテクチャ２００によって従われるプロセスを、図３の方法３００の流れ図に示す。
【００２３】
図２のアーキテクチャ２００は、デバイス・ペア検出器２３０（図５に示し、以下でさらに詳細に論じる）、デバイス・ペア情報レジスタ２４０（図５に示し、以下でさらに詳細に論じる）、エラー検出ロジック２６０（図９に示し、以下でさらに詳細に論じる）、およびグローバル情報レジスタ２５０（図１０に示し、以下でさらに詳細に論じる）を含む。
【００２４】
図２では、オペレーティング・システムがシステムを初期化することに留意されたい。さらに、ＰＣＩバス１４０（デバイス・ペアのパーティシパントを有し、一方のデバイスがマスタであり、別のデバイスがスレーブである）の問題は、マスタ・アドレスをバス１４０から直接読み取ることができることであることに留意されたい。しかし、ターゲット・アドレスをバス１４０から直接読み取ることはできない。
【００２５】
したがって、図２では、左上のボックス（たとえば、ボックス２１０）が、ターゲット・デバイス情報を得るための方法／手段（たとえば、ソフトウェアおよびハードウェア）として提供される（このオペレーションを以下で図１３を参照してさらに詳細に説明する）。ターゲット（たとえば、スレーブ・デバイス）がバス上に提供するものは、アドレスだけである。
【００２６】
したがってアドレスを実際のターゲット・デバイス（たとえば、スレーブ・デバイス）にマップしなければならない。このようなオペレーションがボックス２１０によって実行され、このようなものはオペレーティング・システムからの助け（たとえば、入力）なしに実行することはできない。ボックス２１０内で「Ｓ／Ｗ」によって参照されたソフトウェアは、図１３のターゲット・マッピング・ソフトウェア１１１０であり、「Ｈ／Ｗ」によって参照されたハードウェアはゲート・アレイ１１２０であることに留意されたい。基本的に、ソフトウェアは、デバイス・アドレスが現れるとき、それがどのデバイスであるかをゲート・アレイ１１２０が示すことができるように、ゲート・アレイ１１２０をセット・アップしなければならない。よって、ソフトウェアがセット・アップされた後、ここではさらにソフトウェアの関与することはない。
【００２７】
次いで、ターゲット情報が、トランザクションに従事するデバイス・ペア検出器２３０に入力される。また、デバイス・ペア検出器２３０によって、マスタ・アドレスも受信される（たとえば、ＰＣＩバス１４０から直接受信される）。
【００２８】
次いで、デバイス・ペア検出器２３０はＡＮＤ演算を実行する（すなわち、これを以下で図５を参照してさらに詳細に説明する）。
【００２９】
次いで、デバイス・ペア検出器２３０は、デバイス・ペア情報レジスタ（ハードウェア）２４０およびグローバル情報レジスタ（Ｈ／Ｗ−ハードウェア）２５０に出力を提供する。図５もまたデバイス・ペアレジスタ２４０を例示することに留意されたい。すなわち、ＡＮＤネットワークが図５の左側にあるのに対し、図５の右側はデバイス・ペア情報レジスタ２４０を示す。
【００３０】
グローバル情報レジスタ２５０はまた、モニタベースの手法を使用してプロトコルの違反を決定するための、ＶＨＤＬ（超高速集積回路設計用ハードウェア記述言語）コードも受信する。本出願の目的で、かつ上述のように、「モニタベースの手法」は、システムまたはサブシステムのオペレーションを監視するための外部エージェントの使用を意味する。
【００３１】
図のように、これらの信号がエラー信号としてレジスタ２５０に入力される。これらのエラー信号を図６に示す。すなわち、図６のレジスタ２４０の列ａ、ｂおよびｃは、どこにエラー信号が送り込まれるかを例示する。よって、図６は、第１のデバイスがマスタであり、第２のデバイスがスレーブ・デバイスである３つのＰＣＩデバイス１、２および３のトランザクションの可能な組み合わせ（たとえば、６つ）を示す。したがって、図６の一番左の列は、どのデバイス・ペアがエラーを生じているかを指定する。
【００３２】
すなわち、最初の行ではデバイス１がマスタであり、デバイス２がスレーブであり、行２ではデバイス１がマスタであり、デバイス３がスレーブである、などとなる。列（たとえば、ａ、ｂおよびｃ）は可能なエラーを表す。エラーのタイプ（たとえば、ターゲット・アボート、マスタ・アボート、割り込み信号、ＰＥＲＲ（たとえば、パリティ・エラー）など）を以下でさらに詳細に説明する。
【００３３】
デバイス・ペア情報レジスタ２４０は、どの行が検査されているか（たとえば、どれがマスタであり、どれがターゲット／スレーブであるか）を示す。上に挙げたエラーのあらゆるものについて、列（たとえば、ａ、ｂ、ｃ、ｄ、ｅなどのうち１つ）がそのために設けられる。したがって、エラーのタイプが、対応する列に挿入される。よって、エラーが高く（たとえば、「１」に）なる場合、そのデバイス・ペアが問題を有することがわかる。よって、最初の行の列ａの「１」は、ターゲット・アボート・エラーが１−２デバイス・ペアにおいて発生したことを示す可能性がある。
【００３４】
エラー信号をより詳細に考察すると、図７は、様々な組み合わせが示されるテーブルを示す。１−２および１−３の組み合わせについての図７の行１では、結論は、エラーがこれらのデバイス・ペアの両方で発生する場合、１が両方に共通しているので、これがその中でエラーを有するマスタに違いないということである。ただ１つのトランザクションしかない場合、ただ１つのデバイス・ペアが関係していることに留意されたい。トランザクションのグループを考察する場合、多数のデバイス・ペアを関係させることができる。
【００３５】
したがって、このとき図２に戻ると、デバイス・ペア情報レジスタ２４０はバス・エラー信号を受信し、次いで入力をエラー検出ロジック２６０（以下で図９に関してさらに詳細に説明する）に提供する。エラー検出ロジック２６０はエラーを、デバイス・ペア情報信号に基づいて検出し、入力を論理演算デバイス２７０に提供する。
【００３６】
論理演算デバイス２７０はまた、グローバル情報レジスタ信号も受信し、ＡＮＤ演算を実行して、故障したデバイスを分離する。
【００３７】
次いで、論理演算デバイス２７０は、故障したデバイスについての情報を表す出力を提供する。
【００３８】
本発明の方法
このとき図３を参照して、本発明の方法３００を説明する。
【００３９】
最初にステップ３１０で、バス信号が監視されて、バスのオペレーションがチェックされる。
【００４０】
ステップ３２０で、ＰＣＩ制約が従われているかどうかが監視される。ＰＣＩ制約が従われている（たとえば、ステップ３２０で「ＹＥＳ」）場合、プロセスがステップ３１０に戻る。
【００４１】
ＰＣＩ制約が従われていない（たとえば、「ＮＯ」）場合、プロセスがステップ３３０に進み、そこで診断ロジック（たとえば、図１の１２５、１３５）に接触して、それによりエラーのタイプを決定し、トランザクションに関係したデバイス（たとえば、マスタまたはターゲット）へエラーをピンポイントする。これは本発明の重要なステップである。すなわち、制約を使用してこれらを適切なエラーのタイプ（たとえば、レジスタ内の列）に対応付けることによって、エラー・タイプを識別し、後に探し出すことができる。
【００４２】
ステップ３４０で、エラー情報がオペレーティング・システムに送信される。
【００４３】
ステップ３５０でプロセスが終了し、ここでエラーを治すために必要な処置が実行される。このような必要な処置には、プロセッサへの割り込みを提示することが含まれる可能性があり、次いでこれが適切なエラー処理ソフトウェアを呼び出すことができる。たとえば、システムを別のハードウェア・デバイスにフェイルオーバーするように命令することができ、またはメンテナンス呼び出しを要求して誤動作デバイスを置き換えることができ、あるいはその両方が可能である。
【００４４】
診断ロジック１２５、１３５の設計
上述の問題との関連において、診断ロジック１２５、１３５を設計することは大変重要である。結果として、情報についての信号の選択は重要な役割を果たす。このロジックはアロイド予測手法に基づき、このロジックを図４の構成４００に示す。
【００４５】
図４は、デバイス・ペア検出器２３０からグローバル情報レジスタ２５０に、かつ、そこでビットが収集されるデバイス・ペア情報レジスタ２４０に提供されている、デバイス・ペア情報信号を示す。レジスタ２４０（エラー検出ロジック２６０を通じて）および２５０からの信号が判断ロジックに提供され、これは論理演算デバイス２７０に対応して、「Ｔａｋｅｎ」または「Ｎｏｔ  Ｔａｋｅｎ」を決定する。
【００４６】
図４では、すべての信号が入手可能であり、すべてのトランザクションがＰＣＩ（バス）ブリッジに関係することが仮定される。エラー信号が好ましくは、トランザクションが進行中である間に取り込まれる。これは、最大数のエラーを生じるマスタ・スレーブの組み合わせを探し出す助けとなる。この手法は、単にデバイスではなく、正確なマスタ・スレーブ・ペアをピンポイントする助けとなる。さらにこれは、どのオペレーションのタイプ（たとえば、バス読み取り、バス書き込み、またはステータス情報転送など）が最大数のエラーを引き起こすかを決定する助けとなる。この手法に関するいくつかの技術的問題があり、これには、いくつかの信号がスレーブから発するようになるので、トランザクションが開始するときにデバイス・ペア情報をもたらす方法、そのデバイスがマスタまたはスレーブとして原因であること、および、インフラストラクチャまたはタイミングの問題などのある他の問題がＰＣＩバス上にあるかを知る方法が含まれる。本発明はこれらの各問題に最適な方法で対処し、これを以下で論じる。
【００４７】
図５は、デバイス・ペア情報レジスタ２４０のオペレーションを示す。
【００４８】
図５のように、デバイス・ペア情報レジスタ２４０は２つのタイプの信号をその入力（たとえば、マスタおよびスレーブ）について使用する。マスタがバスの所有権について裁定することは周知である。裁定は許可（ＧＮＴ）信号をマスタにアサートし、バスを駆動することをマスタに許可する。「ＤＥＶＳＥＬ」と呼ばれる信号がターゲットによって出され、それにより、それがトランザクション・フェーズのための準備ができていることを応答する。
【００４９】
３つのデバイス１、２および３がモニタ・エージェントの下にあると仮定すると、どれがマスタであり、どれがスレーブであるかが不確実である。ここで、Ｍ１、Ｍ２およびＭ３がＧＮＴ信号として、Ｓ１、Ｓ２およびＳ３がＤＥＶＳＥＬ信号として表される。これらの信号が、トランザクションに関係したデバイス・ペアについての情報を得るために、図５のようなＡＮＤゲート５１０によってＡＮＤされる。
【００５０】
マスタ・スレーブの組み合わせの間でトランザクション中に発するエラー信号についての情報を、レジスタ２４０に格納することができる。したがって、上述のように、３つのエラー信号ａ、ｂおよびｃがそれぞれ監視されていると仮定すると、レジスタ２４０は図６のように見えるようになる。エラー信号がアサートされる場合、「１」が登録され、そうでない場合、「０」が登録される。このとき、各レジスタの列（ａ）を考察すると、可能な組み合わせが図７のテーブルで与えられる。
【００５１】
上述のように、デバイス・ペア情報レジスタ２４０のためのエラー信号を、どの信号が監視されるべきであるかに応じて、ターゲット・アボート（ＴＲＤＹがデアサートされ、ＳＴＯＰがアサートされ、ＤＥＶＳＥＬがデアサートされるとき、生成される）、マスタ・アボート、割り込み信号およびＰＥＲＲにすることができる。
【００５２】
このとき、ケース（ｉ）、（ｉｖ）、（ｖｉ）および（ｘｉ）が擬似冗長であり、デバイス「１」が原因となるデバイスであることのみを示す。同様に、ケース（ｉｉｉ）、（ｖ）、（ｘ）および（ｘｉｉ）はデバイス２についての同じ情報を与え、ケース（ｖｉｉ）、（ｉｘ）、（ｘｉｉｉ）および（ｘｖ）はデバイス３について同じ情報を提供する。このように、これらのケースのいずれかを取ることができる。また、ケース（ｉｉ）、（ｖｉｉ）および（ｘｉｖ）は、いかなる追加の情報も提供しない。よって、これらを処理することができる方法を図９に示す。
【００５３】
図９はエラー検出ロジック２６０を示し、これは例示的構成においてＯＲゲート２６０１の配列を含み、各ＯＲゲートは第１および第２の入力を受信し、出力をＡＮＤゲート２６０２に提供する。ＡＮＤゲートはＡＮＤ演算をそれへの入力において実行して、それにより、バス・エラー信号のエラーのタイプ（たとえば、ＥＲＲ１（ａ）など）を出力する。デバイス・ペア１＋２および１＋３の間の誤ったトランザクションは、「１」によって示されるエラーを生じ、それにより、デバイス１をメンバとして有するあるデバイス・ペアによるエラーを示すことに留意されたい。
【００５４】
このとき、エラーをマスタまたはターゲットにピンポイントしなければならない。このオペレーションでは、グローバル情報レジスタ２５０からの入力が使用される。
【００５５】
グローバル情報レジスタ２５０では、設計およびアドレス指定スキームが、デバイス・ペア情報レジスタ２４０のものと同じとなり、ただし、エラー信号の代わりに、バス・プロトコル信号が存在するようになる。いずれかの制約が違反される場合、「１」がそれについて登録され、そうでない場合、「０」が登録される。ここで重要なことは、プロトコルの選択である。プロトコルは、結論を強化する助けとなるので、監視されるべきエラー信号に対応するようになる。
【００５６】
特定の故障したデバイス（この場合はデバイス「１」）を決定するための方法８００のトラブル・シューティングの流れ図を、図１０に示す。
【００５７】
このとき、デバイス３および１の間にトランザクションがないと仮定し、これは、「ＭＳ１−ＭＳ３」が低くなることを含意する。「ＭＳ１−ＭＳ２」が高くなる場合でも、「ＥＲＲ１」は低いまま残り、それによりエラーについての間違った情報を与えるようになる。さらに、「ＥＲＲ１」が高い場合、それがマスタの問題であるかターゲットの問題であるかが不確かである。よって、これらの制限を克服するため、グローバル情報レジスタ２５０が提供され、これは、複数のデバイスの間のトランザクション中にプロトコルについての追加の情報を有することが好ましい。よって、エラーが識別された後、このときマスタまたはターゲットを、デバイス・ペアにおけるデバイスによるプロトコルの違反によって、原因となるものとして識別しなければならず、それに応じてグローバル情報レジスタ２５０が使用される。
【００５８】
グローバル情報レジスタ２５０の設計およびオペレーション
グローバル情報レジスタ２５０の設計およびアドレス指定スキームは、デバイス・ペア情報レジスタ２４０のものと類似である。例外は、レジスタ２４０におけるエラー信号の代わりに、バス・プロトコル信号が使用されるようになることである。
【００５９】
いずれかの制約が違反される場合、「１」がその違反について登録され、そうでない場合、「０」が登録される。重要な態様は、プロトコルの選択である。プロトコルは、結論を強化する助けとなるので、監視されるべきエラー信号に対応する。したがって、再度、曖昧性の問題が与えられると、ＧＩＲ２５０は、原因となるものがマスタであるかターゲット／スレーブであるかを決定するための助けとなる。それが、マスタおよびスレーブ／ターゲットの両方に関係するバスの問題である場合、ＧＩＲ２５０は同様にこのような宣言を行なうようになる。特定の故障したデバイス（この場合はデバイス「１」）を決定するためのトラブル・シューティングの流れ図を、図１０の方法８００で提供する。
【００６０】
具体的には、図１０は、あるデバイス（たとえば、デバイス１）について実行されて、デバイス１が問題である／エラーを有する（たとえば、原因となるものである）かどうかがテストされる、ステップの流れ図を表す。他の類似の流れが、バスに接続された他のデバイスについて行なわれて、これらのデバイスに問題／エラーが存在するかどうかがテストされる。このように、３つのデバイスがバスに接続されていた場合、図１０のものに類似した３つの流れが並列に実行されるようになる。
【００６１】
方法８００で、概して流れ図の右側のステップは、故障が存在する所が知られていることを示す（たとえば、エラーが、ターゲットおよびマスタのうち特定の１つに存在することが知られている）のに対し、左側は、故障がマスタおよびターゲットのうち特定の１つに存在することが知られていないことを示す。
【００６２】
ステップ８１０で、信号（たとえば、図９の「ＥＲＲ１」）が得られる。図９のように、「ＥＲＲ１」は、マスタ１−スレーブ２およびマスタ２−スレーブ１の排他的ＯＲ演算を表す。このように、マスタ１−スレーブ２の間のトランザクション、または、マスタ２−スレーブ１の間のトランザクションの間でエラーが発生する場合、「１」の結果となる。同様に、エラーがこれらのトランザクションの両方における（たとえば、共通する）ものである場合、排他的ＯＲ演算に基づいて「０」の結果となる。
【００６３】
次いで、ステップ８２０で、信号が低いかどうかが決定される。（グローバル情報レジスタ２５０が主として、バスの下位レベルを有する信号に関心を有することに留意されたい。）
【００６４】
信号が低い（たとえば、「ＹＥＳ」）場合（「故障なし」または具体的にエラーがある所の情報あるいはその両方を意味する）、ステップ８３０で、排他的ＯＲ演算が、グローバル情報レジスタ２５０（たとえば、Ｍ１−Ｓ２）により実行される。このステップ８２０を、図１１の上部に示し、以下でさらに詳細に説明することに留意されたい。
【００６５】
すなわち、排他的ＯＲ演算がＥＲＲ１とＭ１−Ｓ２の間で実行され、これが図１１のＸＯＲゲート９１０に挿入されて、それにより、マスタとして高い「１」の場合にスレーブ２で問題を有することを表す出力を提供する。すなわち、ＸＯＲ論理は、ＥＲＲ１が低いときにのみ従事する。このように、ＸＯＲの出力が高い場合、ＧＩＲ２５０がＭ１−Ｓ２のトランザクションにおけるプロトコル違反を検出していることを意味する。
【００６６】
以下でさらに詳細に論じるように、ＥＲＲ１が高い（「１」）場合、それがマスタの問題であるかターゲットの問題であるかが不確実であり、ステップ８２５などを、問題のタイプおよびどのデバイスがこの問題を引き起こしたかを決定するために、実行しなければならない。再度、ＥＲＲ１が高い場合、エラーがマスタに存在するか、スレーブ／ターゲットに存在するかが知られておらず、ＡＮＤ演算（図１２の４つのＡＮＤゲート１０１０を介する）がＥＲＲ１およびＧＩＲ２５０情報により実行され、これを図１２に示し、以下でさらに詳細に説明する。４つのＡＮＤゲートが図１２で使用されており、これは、デバイス１に問題があること、および、次いでどのモード（たとえば、マスタまたはスレーブ）でそれが動作中であったか、およびどの他のデバイス（たとえば、Ｍ２、Ｍ３、Ｓ２、Ｓ３）によりそれがトランザクションを実行中であったかを決定しなければならないことが、知られているからであることに留意されたい。
【００６７】
ステップ８４０で、信号が高い（たとえば、「１」）かどうかが決定される。信号が高い（たとえば、「ＹＥＳ」）場合、プロセスがステップ８６０に進む。信号が低い（たとえば、「ＮＯ」）場合、ステップ８５０で、エラーがないことが宣言される（デバイスにエラーがないことを意味する）。このように、信号が低い場合、マスタとしてもスレーブとしても、バス・エラーまたはプロトコル・エラーを生じたデバイス１に関係するトランザクションはなかった。
【００６８】
ステップ８６０で、マスタ・プロトコルが違反されているかどうかが決定される。マスタ・プロトコルをリストし、以下でさらに詳細に説明する。本発明では、プロトコルをマスタ・プロトコル、ターゲット・プロトコル、およびユニバーサル（universal）（マスタ・ターゲット）プロトコルにすることができる。マスタ・プロトコルは、トランザクション内でマスタであった何者かが故障していたことを示す。ある例示的マスタ・プロトコルが違反されているかどうかをチェックする方法は、それぞれ図１４〜１６の例示的プロトコル・チェック方法１２００〜１４００において実行される。
【００６９】
マスタ・プロトコルが違反されていなかった場合、ステップ８７０で、デバイス「１」に問題がないと決定される。
【００７０】
同様に、ステップ８６０で、マスタ・プロトコルが違反されていると決定された場合、プロセスがステップ８７５に進み、ここでデバイス１が原因となるものとして宣言され、同様にそのオペレーションのモード（たとえば、マスタまたはスレーブ）が宣言される。
【００７１】
このときステップ８２０に戻ると、ステップ８２０で信号が低くない（たとえば、「ＮＯ」）であると決定された場合、プロセスがステップ８２５に分岐する。
【００７２】
ステップ８２５で、このような情報が、グローバル情報レジスタ（Ｍ１−Ｓ２）２５０からの情報によりＡＮＤされる。
【００７３】
次いでステップ８３５で、信号が高いかどうかが決定される。信号が高い場合、ステップ８４５で、バスに問題がないと決定される。（すなわち、信号が低い場合、問題がバスに存在すると決定される。）このような場合、デバイスを適切に動作可能にすることができるが、その上でこれらのデバイスが通信中であるバスがトランザクションに影響を及ぼしていた可能性がある（または、どのデバイスが原因となるものであるかを決定することができない場合）。
【００７４】
ステップ８３５で信号が高いと決定された場合、ステップ８７５で、デバイス「１」が原因となるものとして宣言され、オペレーションのモード（たとえば、デバイス１はマスタであるか、あるいはデバイス１はスレーブである）が宣言される。その時点で、オペレーティング・システムが是正処置を取ることができる。再度、「オペレーションのモード」が宣言されることは、デバイスがマスタとして動作中であること、または、デバイスがスレーブとして動作中であることも宣言されることを意味する。
【００７５】
図１０の方法８００から明らかなことは、ＰＣＩプロトコル信号をある順序で登録する必要があることである。したがって、「ｐ」個のＰＣＩプロトコル信号があり、「ｍ」がマスタであり、「ｎ」がターゲットであり、「ｉ」がマスタおよびスレーブ・プロトコルであると仮定する。したがって、ＧＩＲ２５０は、最初にマスタ・プロトコル専用の「ｍ」個のセル、次にターゲット・プロトコルへの「ｎ」などを有するようになる。よって、判断オペレーション「マスタ・プロトコルが違反されているか」の場合、戻ってレジスタ２５０をチェックすることができる。「ｍ」個の最初のビットのいずれかが高い場合、これはマスタ・プロトコル違反である。
【００７６】
以下で、判断を行なう方法を説明する。これを、マルチプレクサの助けにより行なうことができる。次に、ＸＯＲおよびその演算を行なう方法、その重要性などを説明する。これを図１１に示す。
【００７７】
このように、図１１に戻ると、デバイス・ペア情報レジスタ２４０が誤った結果を与える場合も、なおＧＩＲ２５０におけるグローバル情報に基づいて予測を行なうことができる。ＸＯＲ演算の後、信号が高くなる場合、これは、故障したデバイスについての完全な情報を提供しないが、オペレーションのモードを示す。どのプロトコルが破られているかを調べるために、ＧＩＲ２５０がチェックされる場合、故障したデバイスおよびそのオペレーションのモードについて結論を下すことができる。
【００７８】
図１１のように、両方の信号が高い場合、故障したデバイスおよびそのオペレーションのモードについて予測することができる。
【００７９】
以下で、デバイス・ペアにおける上記のエラーを直し、故障したデバイスをピンポイントする方法を、さらに詳細に説明する。
【００８０】
ＰＣＩバス上のターゲット・デバイスのアドレスの取り込み（ＤＥＶＳＥＬ信号のタッピング（Tapping））
以下で、デバイス・アドレスを得る方法を説明する。マスタに関して、情報を、ＰＣＩバス・ブリッジ１４０上に存在するバス・アービタから得ることができる。マスタ・デバイス・アドレスを、ＧＮＴがアサートされるとすぐに得ることができる。
【００８１】
次の問題は、ターゲット信号（ＤＥＶＳＥＬ）を得る方法であり、これはこの信号がバス信号であるためである。これが以下のように実施される。
【００８２】
システムが起動するたびに、オペレーティング（ＯＳ）はデバイスのアドレス初期化を実行する。よって、ＯＳはデバイスのためのアドレス空間を確保し、情報が各デバイスのデバイス・ドライバ内に残る。フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）またはある他のロジックの集まりを設計することができ、これにおいて、コードがＯＳとしてターゲット・マッピング・ソフトウェアによって起動され、デバイス・アドレスをゲート・アレイに書き込むようになる。デバイス（ターゲット）アドレスをＰＣＩバス・ブリッジから得ることができ、よって、ターゲット・デバイスについての情報を得ることができる。上で触れたように、この手法を図１３の構造１１００に示すように理解することができ、この構造はターゲット・マッピング・ソフトウェア１１１０およびゲート・アレイ１１２０を含む。デバイス選択１１３０は、デバイス・ペア検出２３０（ターゲット・アドレス情報を得るため）と同じであることに留意されたい。
【００８３】
可能なＰＣＩプロトコルのリスト
可能なＰＣＩプロトコルについて、以下でいくつかの例示的プロトコルを提供する。
【００８４】
Ｉ．バスがアイドルになるか、アイドルに戻るべきである（ＦＲＡＭＥおよびＩＲＤＹがデアサートされる）。
【００８５】
ＩＩ．ＤＥＶＳＥＬ（デバイス選択）がアサートされるまで、ＴＲＤＹ（ターゲット・レディ）を駆動することはできない。
【００８６】
ＩＩＩ．ＩＲＤＹがアサートされるときにのみ、最後のデータ・フェーズを示すＦＲＡＭＥをデアサートすることができる。
【００８７】
ＩＶ．タイマが切れた後、ＧＮＴがデアサートされない限り、トランザクションが終了される必要はない。
【００８８】
Ｖ．ＦＲＡＭＥがデアサートされた後、これを同じトランザクション中に再アサートすることはできない。
【００８９】
ＶＩ．マスタがＩＲＤＹをアサートした後、マスタは、現在のデータ・フェーズが完了するまで、ＩＲＤＹまたはＦＲＡＭＥを変更することはできない。
【００９０】
ＶＩＩ．最後のデータ・フェーズの完了後、マスタはＩＲＤＹをデアサートしなければならない。
【００９１】
ＶＩＩＩ．読み取りトランザクションのアドレス・フェーズと最初のデータ・フェーズの間のターンアラウンド・サイクル中に、ＳＴＯＰをアサートすることはできない。
【００９２】
ＩＸ．データ・フェーズは、その上でＩＲＤＹがアサートされ、ＳＴＯＰまたはＴＲＤＹのいずれかがアサートされるいずれかの立上りで完了する。
【００９３】
Ｘ．ＳＴＯＰの状態に関係なく、ＩＲＤＹおよびＴＲＤＹがアサートされるとき、データ転送が行なわれる。
【００９４】
ＸＩ．ＳＴＯＰがアサートされた後、ＦＲＡＭＥがデアサートされてターゲットがＳＴＯＰをデアサートしなければならなくなるまで、ターゲットはＳＴＯＰがアサートされたまま保たなければならない。
【００９５】
ＸＩＩ．ＴＲＤＹまたはＳＴＯＰがアサートされた後、ターゲットは、データ・フェーズが完了するまで、ＤＥＶＳＥＬ、ＴＲＤＹまたはＳＴＯＰを変更することができない。
【００９６】
ＸＩＩＩ．ＳＴＯＰがアサートされ、マスタは、ＩＲＤＹをデアサートできるようになるとすぐに、デアサートしなければならない。
【００９７】
ＸＩＶ．最後のデータ・フェーズの完了の後に続いて、ＴＲＤＹ、ＳＴＯＰおよびＤＥＶＳＥＬをデアサートしなければならない。
【００９８】
ＸＶ．ＧＮＴがデアサートされ、ＦＲＡＭＥがアサートされた場合、バス・トランザクションは有効であり、継続するようになる。
【００９９】
ＸＶＩ．ＦＲＡＭＥがデアサートされる間、より高い優先順位のマスタにサービスするために、ＧＮＴをいかなるときにもデアサートすることができる。
【０１００】
ＸＶＩＩ．ＦＲＡＭＥおよびＩＲＤＹがデアサートされ、そのＧＮＴがアサートされるとき、マスタはＦＲＡＭＥを最初に可能なクロックでアサートしなければならない。
【０１０１】
ＸＶＩＩＩ．ターゲットがトランザクションをＳＴＯＰにより終了させるとき、マスタはそのＲＥＱを最小限の２クロックの間、デアサートしなければならない。
【０１０２】
ＸＩＸ．ターゲットは、ＤＥＶＳＥＬを構成コマンド上にアサートできるようになる前に、ＩＤＳＥＬをＦＲＡＭＥによりクオリファイ（qualify）しなければならない。
【０１０３】
ＸＸ．特殊サイクル・コマンド：ターゲットなしの応答。
【０１０４】
これらのプロトコルは「ユニバーサル・プロトコル」として分類され、これは、これらのプロトコルが、他のプロトコルの違反を決定して判断を行なう助けとなることを意味する。
【０１０５】
たとえば、プロトコル「１」はユニバーサル・プロトコルであり、これは、バスがあらゆるデータ・トランザクションの終了後にアイドルになるからである。同様に、プロトコル２、３、７、９、１４および１７はユニバーサル・プロトコルである。
【０１０６】
以下で、これらのプロトコルを図１４〜１６の方法１２００、１３００および１４００で実施することができる方法についての流れ図を説明する。いくつかのプロトコルを以下で例示する。他のすべてのプロトコルを、図１４〜１６のように実施することができる。これらのプロトコルは、「マスタ・プロトコル」（１、３、５、６、７、１３および１７）、「ターゲット・プロトコル」（２、８、１２、１４、１９）および「マスタ・ターゲット・プロトコル」（１１および１８）として分類することができる。
【０１０７】
図１４を参照して、上述のプロトコル１７（たとえば、「ＦＲＡＭＥおよびＩＲＤＹがデアサートされ、そのＧＮＴ（許可）がアサートされるとき、マスタはＦＲＡＭＥを最初に可能なクロックでアサートしなければならない」）を処理して、プロトコル１７が従われているか、違反されているかを決定するための方法１２００の流れ図を示す。プロトコル１７では、ＩＲＤＹはＩ／Ｏレディを意味する。
【０１０８】
ステップ１２１０で、バスがアイドルであり、ＦＲＡＭＥおよびＩＲＤＹがデアサートされている。
【０１０９】
ステップ１２２０で、ＧＮＴ（許可）がアサートされ、ステップ１２３０で、システムが１クロック期間で待機する。この待機は、ＰＣＩバス標準仕様に従って、あるバス・タイミング要件を満たすためである。
【０１１０】
ステップ１２４０で、ＦＲＡＭＥがアサート（たとえば、マスタによってアサート）されているかどうかが決定される。ＦＲＡＭＥがアサートされている（たとえば、「ＹＥＳ」）場合、ステップ１２５０で、プロトコル１７が従われていると決定される。
【０１１１】
ＦＲＡＭＥがアサートされていない（たとえば、ステップ１２４０で「ＮＯ」）場合、プロトコル１７がマスタによって違反されていると決定される。
【０１１２】
図１５は、他のプロトコル（たとえば、プロトコル６、１２、１４）が従われるか、違反されるかをチェックする方法１３００を示す。プロトコル１２および１４はターゲット・プロトコルであるのに対して、プロトコル６はマスタ・プロトコルである。このように、図１５は、二重違反が検出される可能性のある方法を示す。これらのチェックは、方法１３００で並列に実行される。
【０１１３】
ステップ１３０５で、バスがアイドルである。
【０１１４】
ステップ１３１０で、ＧＮＴがアサートされ、ＦＲＡＭＥがアサートされる。
【０１１５】
ステップ１３１５で、ＩＲＤＹがアサートされ、ステップ１３２０で、ＤＥＶＳＥＬがアサートされる。
【０１１６】
ステップ１３２５で、データ・フェーズが完了されるかどうかが決定される。「ＹＥＳ」である場合、プロセスがステップ１３３０に進み、そこで、完了されたデータ・フェーズが最後のデータ・フェーズであるかどうかが決定される。「ＮＯ」である場合、プロセスがステップ１３２５にループ・バックする。
【０１１７】
ステップ１３３０で「ＹＥＳ」である（たとえば、完了されたデータ・フェーズが最後のデータ・フェーズである）場合、ステップ１３３５で、ＴＲＤＹ、ＳＴＯＰおよびＤＥＶＳＥＬがデアサートされるかどうかが決定される。ＴＲＤＹ、ＳＴＯＰおよびＤＥＶＳＥＬがデアサートされる（たとえば、「ＹＥＳ」）場合、プロセスがステップ１３０５にループ・バックする。
【０１１８】
同様に、ＴＲＤＹ、ＳＴＯＰおよびＤＥＶＳＥＬがデアサートされていない（たとえば、「ＮＯ」）場合、プロトコル１４が違反されたと決定される。
【０１１９】
さらに、ステップ１３２５に関して、データ・フェーズが完了しているが、これが最後のデータ・フェーズではない（たとえば、ステップ１３３０で「ＮＯ」）場合、プロトコル１２の違反についてのチェックが行なわれることに留意されたい。
【０１２０】
このように、ステップ１３２５で、データ・フェーズが完了している（が、ステップ１３３０によって決定されたように最後のフェーズではない）と決定された場合、プロセスがステップ１３４５に進み、そこで、ＴＲＤＹがデアサートされるかどうかが決定される。
【０１２１】
ステップ１３４５で「ＹＥＳ」である場合、プロトコル１２が違反されていると決定される。「ＮＯ」である場合、ステップ１３５０で、ＤＥＶＳＥＬがデアサートされるかどうかが決定される。「ＹＥＳ」である場合、プロトコル１２が違反されている。
【０１２２】
ステップ１３４５で「ＮＯ」である場合、プロトコル１２が従われていると決定される。
【０１２３】
ステップ１３２５で、データ・フェーズが完了していないと決定された場合、ステップ１３６５で、ＩＲＤＹがデアサートされるかどうかが決定される。ステップ１３６５で「ＹＥＳ」である場合、ステップ１３７０で、プロトコル６が違反されるという結論が下される。
【０１２４】
ステップ１３６５で「ＮＯ」である場合、ステップ１３７５で、ＦＲＡＭＥがデアサートされるかどうかが決定される。ＦＲＡＭＥがデアサートされる（たとえば、ステップ１３７５で「ＹＥＳ」）場合、ステップ１３７０で、プロトコル６が違反されるという結論が下される。
【０１２５】
ステップ１３７５で「ＮＯ」が生じる（たとえば、ＦＲＡＭＥがデアサートされない）場合、ステップ１３８０で、プロトコル６が従われていると決定される。
【０１２６】
図１６は、図１５の方法と共に使用されるサブルーチンである方法１４００を例示し、これは、マスタおよびターゲットが互いに通信中であり、データがバスを介して送信されている、特定のトランザクションにおいて、データ・フェーズが完了しているかどうかを決定する（たとえば、図１５のステップ１３２５）。このように、図１６はプロトコルのチェックを表さないが、その代わりに、データ・フェーズが完了しているかどうかを決定する（たとえば、図１５のステップ１３２５）サブルーチンである。すなわち、このサブルーチンは、データが完全に送信されており、図１５の方法１３００の流れ図と共に有用となるかどうかを決定する。
【０１２７】
具体的には、バスは「スタッター（stutter）」することができ、したがって、トランザクションは間に何もない開始および終了を有していないが、代わりに開始を有することができ、次いで停止、次いで継続できることを理解されたい。このように、所与のトランザクションが完了しているときを決定する方法を有することが有用である。結果として、図１６の方法１４００が提供され、これを図１５のステップ１３２５で挿入することができる。
【０１２８】
このとき図１６の方法１４００を参照すると、ステップ１４０５で、バスがアイドルであり、ステップ１４１０でＧＮＴがアサートされ、ＦＲＡＭＥがアサートされる。その後、ステップ１４１５で、ＩＲＤＹがアサートされる。
【０１２９】
ステップ１４２０で、ＤＥＶＳＥＬがアサートされ、ステップ１４２５で、ＴＲＤＹがアサートされる。
【０１３０】
ステップ１４３０で、ＩＲＤＹおよびＴＲＤＹの状況がチェックされる。
【０１３１】
ステップ１４４０で、これら（ＩＲＤＹおよびＴＲＤＹ）が再度共にバス信号の同じ立上りで再アサートされるかどうかが決定される。ステップ１４４０で「ＮＯ」である場合、ステップ１４４５で、トランザクションが継続する。
【０１３２】
ステップ１４４０で「ＹＥＳ」である（たとえば、ＩＲＤＹおよびＴＲＤＹが再度共にバス信号の同じ立上りで再アサートされている）場合、ステップ１４５０でデータ・フェーズが完了され、ステップ１４５５で、ＦＲＡＭＥがデアサートされるかどうか、ＳＴＯＰがアサートされるかどうかが決定される。
【０１３３】
「ＮＯ」である場合、プロセスがステップ１４５０にループ・バックする。「ＹＥＳ」である場合、ステップ１４６０で、これが最後のデータ・フェーズであるという結論が下される（これは、図１５の判断ブロック１３３０に対応する）。
【０１３４】
上述の方法は、ただ１つのトランザクション（たとえば、これにおいて、図６のただ１つの行を場合によってはポピュレートする（populated）ことができる）に基づいて診断を行なうことを対象としているが、診断をいくつかのトランザクションに基づくようにすることができ、この場合は、図６のいくつかの行がエントリを含む可能性があることに留意されたい。
【０１３５】
たとえば、図８は、いくつかのトランザクションが発生した後のエラー・レジスタの内容を示す。セルの「０」は、その行の最初の列で指名されたデバイス・ペアについて、その列の最初の行に示されたタイプのエラーがなかったことを示し、セルの「１」は、このようなエラーがこのようなデバイス・ペアについて観察されたことを示すことを想起されたい。これらのすべてのトランザクションでは、デバイス２が故障しているが、エラー・タイプｂについてのみであり、それがスレーブであるときのみであると仮定する。監視されているトランザクションには、１がマスタであり２がスレーブであるトランザクション、および、３がマスタであり２がスレーブであるトランザクションが含まれると仮定すると、テーブルは図８のように現れるようになる。
【０１３６】
図８のテーブルの「１」の位置から、デバイス２がスレーブ容量（slavecapacity）で動作中であるとき、エラーであると決定することが可能である。この技術に従って、バス上のすべてのパーティシパントの間の多数のトランザクションの観察により、デバイス・ペアのうちどのデバイスが故障しているかを決定することが可能となる。
【０１３７】
図１７は、本発明と共に使用するための情報処理／コンピュータ・システムの典型的なハードウェア構成を例示し、これは少なくとも１つのプロセッサまたは中央処理装置（ＣＰＵ）１５１１を有することが好ましい。
【０１３８】
ＣＰＵ１５１１がシステム・バス１５１２を介して、ランダム・アクセス・メモリ（ＲＡＭ）１５１４、読み取り専用メモリ（ＲＡＭ）１５１６、入力／出力（Ｉ／Ｏ）アダプタ１５１８（ディスク・ユニット１５２１およびテープ・ドライブ１５４０などの周辺デバイスをバス１５１２に接続するためのもの）、ユーザ・インターフェイス・アダプタ１５２２（キーボード１５２４、マウス１５２６、スピーカ１５２８、マイクロフォン１５３２または他のユーザ・インターフェイス・デバイスあるいはその両方をバス１５１２に接続するためのもの）、情報処理システムをデータ処理ネットワーク、インターネット、イントラネット、パーソナル・エリア・ネットワーク（ＰＡＮ）などに接続するための通信アダプタ１５３４、および、バス１５１２を表示デバイス１５３８またはプリンタあるいはその両方に接続するための表示アダプタ１５３６に相互接続される。
【０１３９】
上述のハードウェア／ソフトウェア環境に加えて、本発明の異なる態様は、上述の方法を実行するためのコンピュータ実施方法を含む。一実施例として、これらの方法を、上述の特定の環境で実施することができる。
【０１４０】
このような方法を、たとえば、デジタル・データ処理装置によって実施されたようなコンピュータを操作して、一連の機械可読命令を実行することによって、実施することができる。これらの命令は、様々なタイプの信号搬送媒体（signal-bearing media）内に存在することができる。
【０１４１】
この信号搬送媒体は、たとえば、ＣＰＵ１５１１内に含まれたＲＡＭを含むことができ、これをたとえば、高速アクセス・ストレージによって表す。別法として、これらの命令を別の信号搬送媒体に含めることができ、これはＣＰＵ１５１１によって直接的または間接的にアクセス可能な磁気データ・ストレージ・ディスク１６００（図１８）などである。
【０１４２】
ディスケット１６００に含まれるか、コンピュータ／ＣＰＵ１５１１に含まれるか、他の場所に含まれるかにかかわらず、これらの命令を様々な機械可読データ・ストレージ・メディアに格納することができ、これはＤＡＳＤストレージ（たとえば、従来の「ハード・ドライブ」またはＲＡＩＤアレイ）、磁気テープ、電子読み取り専用メモリ（たとえば、ＲＯＭ、ＥＰＲＯＭまたはＥＥＰＲＯＭ）、光ストレージ・デバイス（たとえば、ＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、デジタル光テープなど）、紙の「パンチ」カード、または、デジタルおよびアナログおよび通信リンクおよびワイヤレスなどの伝送媒体を含む他の適切な信号搬送媒体などである。本発明の例示的実施形態では、機械可読命令は、「Ｃ」などの言語からコンパイルされたソフトウェア・オブジェクト・コードなどを含むことができる。
【０１４３】
本発明のユニークかつ明白でない特徴により、原因となるデバイスを、予測誤りに基づいた重みではなくアロイド予測に基づいてブール論理を使用して、ピンポイントすることができる。加えて、履歴テーブルまたはパターン履歴テーブルが本発明によって必要とされず、それによりハードウェアが低減される結果となる。加えて、ＯＳが故障の重大性に基づいていずれかの必要な処置を取ることができる。
【０１４４】
よって、本発明は、ＰＣＩバス仕様に基づき、ＰＣＩバス制約が従われているかどうかを検出するために使用される、モニタベースの手法を提供する。このモニタは、適切な挙動を記述するためにハードウェア記述言語（ＨＤＬ）を使用して開発されることが好ましく、環境またはエージェントを使用して実施されることが好ましい。これらのエージェントは分離可能性の規則を満たし、これは、各エージェントの出力が他のエージェントの出力とは異なることを意味する。
【０１４５】
本発明をいくつかの好ましい実施形態に関して説明したが、本発明を、付属の特許請求の精神および範囲内の修正と共に実施できることは、当業者には理解されよう。
【０１４６】
さらに、出願人の意図は、審査手続き（prosecution）中に後で補正される場合でも、すべての特許請求の範囲の要素の等価物を包含することである。
【０１４７】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１４８】
（１）ペアワイズ・パーティシパントを有するバスを監視する方法であって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出するステップと、
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定するステップとを含む方法。
（２）前記決定するステップは、複数のトランザクションを観察するステップ、および前記問題を検出するステップに基づく、上記（１）に記載の方法。
（３）バス上のデバイス・レベルの故障分離の方法であって、
ハードウェア・バス仕様に基づいて、モニタにより、前記ハードウェア・バスの制約が従われているかどうかを検出するステップを含み、
前記モニタが、挙動を記述するためにハードウェア記述言語（ＨＤＬ）を使用して開発され、環境を使用して実施される方法。
（４）前記環境はエージェントを含む、上記（３）に記載の方法。
（５）エージェントのコントロール下の制約が従われている場合、前記エージェントは正しい信号を生成し、前記エージェントが誤りである信号を生成する場合、前記ハードウェア・バス制約が違反されている、上記（３）に記載の方法。
（６）システム内で故障を分離する方法であって、前記システムはデバイス・ペアをバス上に有し、
故障が発生しているかどうかを判断するステップと、
デバイス・ペアのデバイスの一方が前記故障を引き起こしたかどうかを決定するステップと、
前記デバイスのうち前記一方が前記故障を引き起こしていないと決定される場合、前記故障の原因をバスの故障として識別するステップとを含む方法。
（７）前記バスは周辺装置相互接続（ＰＣＩ）バスを含む、上記（６）に記載の方法。
（８）前記デバイスはＰＣＩデバイスを含む、上記（６）に記載の方法。
（９）バス上のデバイス・レベルの故障を分離するためのシステムであって、
マスタ・アドレス情報およびターゲット・アドレス情報を受信するためのデバイス・ペア検出器と、
前記デバイス・ペア検出器から出力を受信するためのデバイス・ペア情報レジスタと、
前記デバイス・ペアから出力を受信するためのエラー検出ロジックと、
前記デバイス・ペア検出器およびプロトコル違反チェック・ロジックから出力を受信するためのグローバル情報レジスタと、
前記ターゲットおよび前記マスタがある場合、そのうちのどちらが前記故障の原因であるかを、前記エラー検出ロジックおよび前記グローバル情報レジスタからの出力に基づいて決定するための論理演算ユニットとを含み、
前記論理演算ユニットが、前記ターゲットおよび前記マスタのいずれをも前記原因として識別しない場合、前記論理演算ユニットは、前記原因がシステミックなバス問題を含むと決定するシステム。
（１０）ターゲット・デバイス情報を得るためのユニットをさらに含む、上記（９）に記載のシステム。
（１１）前記ユニットは、ターゲット・マッピング・モジュールおよびデジタル・ロジックを含み、オペレーティング・システムは、デバイス・アドレスが現れるとき、前記デジタル・ロジックが前記デバイスの識別を示す出力を提供するように前記デジタル・ロジックをセット・アップする、上記（１０）に記載のシステム。
（１２）前記ターゲット情報が、トランザクションに従事する前記デバイス・ペア検出器に入力され、前記デバイス・ペア検出器は前記マスタ・アドレスを前記バスから直接受信し、
前記デバイス・ペア検出器はＡＮＤ演算を実行して、前記出力を前記グローバル情報レジスタおよび前記デバイス・ペア情報レジスタに提供する、上記（１１）に記載のシステム。
（１３）前記グローバル情報レジスタが、モニタベースの手法を使用してプロトコルの違反を決定するための、超高速集積回路設計用ハードウェア記述言語（ＶＨＤＬ）コードによって実施される、上記（９）に記載のシステム。
（１４）前記ＶＨＤＬコードは少なくとも１つのエラー信号を含み、
前記少なくとも１つのエラー信号は、ターゲット・アボート、マスタ・アボート、割り込み信号およびパリティ・エラー（ＰＥＲＲ）信号を含む、上記（１３）に記載のシステム。
（１５）前記グローバル情報レジスタはバス・プロトコル信号を受信し、前記プロトコルは、監視されるべき前記エラー信号に対応する、上記（９）に記載のシステム。
（１６）選択的にトランザクションに関係する少なくとも第１および第２のパーティシパントを含むバスにおける故障分離の方法であって、
バス信号を監視して、前記バスのオペレーションをチェックするステップと、
バス制約が従われているかどうかを決定するステップと、
前記バス制約が従われていない場合、診断ロジックに接触して、それによりエラーのタイプを決定し、前記トランザクションに関係する前記第１および第２のパーティシパントのうち一方へ前記エラーをピンポイントするステップとを含む方法。
（１７）前記接触するステップは、前記制約を使用してこれらをエラーのタイプに対応付けて、前記エラー・タイプを識別し、かつ後に探し出すことができるようにするステップを含む、上記（１６）に記載の方法。
（１８）エラー情報をオペレーティング・システムに送信するステップをさらに含む、上記（１６）に記載の方法。
（１９）前記エラーを直すための処置を実行するステップをさらに含む、上記（１８）に記載の方法。
（２０）すべてのトランザクションが前記バスに関係し、あるトランザクションが進行中である間にエラー信号が取り込まれる、上記（１６）に記載の方法。
（２１）バス上で特定の故障したデバイスを決定するためのトラブル・シューティングの方法であって、
トランザクションにおける第１および第２のパーティシパントに関係する前記トランザクションにおけるエラーを示すエラー信号を得るステップと、
前記信号が所定の値を有するかどうかを決定するステップと、
前記信号が前記所定の値を有する場合、グローバル情報レジスタにより論理演算を実行して、それにより、前記２つのパーティシパントのうちどちらが問題を有するかを示すステップとを含む方法。
（２２）前記論理演算は排他的ＯＲ演算を含む、上記（２１）に記載の方法。
（２３）前記エラー信号が第２の所定の値を有する場合、それがマスタの問題であるかターゲットの問題であるかが不確実であると判断するステップと、
問題のタイプおよびどのパーティシパントが前記問題を引き起こしたかを決定するステップとを含み、前記決定するステップは、前記エラー信号および前記グローバル情報レジスタの情報により第２の論理演算を実行して、所定の値を有する信号を得るステップとをさらに含み、
前記信号が第１の所定の値を有する場合、前記問題がバスの問題として識別され、前記信号が第２の所定の値を有する場合、前記問題を引き起こす前記パーティシパントおよびそのオペレーションのモードが決定される、上記（２１）に記載の方法。
（２４）前記第２の論理演算はＡＮＤ演算を含み、前記第１の所定の値は低く、前記第２の所定の値は前記第１の所定の値に対して高い、上記（２３）に記載の方法。
（２５）前記信号が、高い所定の値を有するかどうかを決定するステップと、
前記信号が、低い所定の値を有する場合、エラーがないことを宣言するステップとをさらに含む、上記（２２）に記載の方法。
（２６）前記信号が高い場合、前記マスタのプロトコルが違反されているかどうかを決定するステップであって、前記マスタ・プロトコルは、前記トランザクション内でマスタであった者は誰でも故障していたことを示すステップと、
前記マスタ・プロトコルが違反されていない場合、前記デバイスに問題がないと決定するステップと、
前記マスタ・プロトコルが違反されていると決定される場合、前記デバイスを前記問題の原因として宣言し、そのオペレーションのモードを宣言するステップとをさらに含む、上記（２５）に記載の方法。
（２７）前記所定の値は、「故障なし」または具体的に前記エラーがある所の情報あるいはその両方を示す、上記（２２）に記載の方法。
（２８）前記方法が、前記バスに結合された各デバイスについて並列に実行される、上記（２１）に記載の方法。
（２９）前記エラー検出ロジックは複数の排他的ＯＲゲートを含む、上記（９）に記載のシステム。
（３０）ペアワイズ・パーティシパントを有するバスを監視する方法を実行するために、デジタル処理装置によって実行可能な機械可読命令のプログラムを有形に実施する信号搬送媒体であって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出すること、および
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定することを含む信号搬送媒体。
（３１）ペアワイズ・パーティシパントを有するバスを監視するためのシステムであって、
前記バス上の第１および第２のパーティシパントの間のトランザクション中に問題を検出するための検出器と、
どのパーティシパントが前記問題について故障しているか、または、前記問題がシステミックなバス問題を含むかどうかを決定するための決定ユニットとを含むシステム。
【図面の簡単な説明】
【０１４９】
【図１】本発明が使用される例示的上位レベル環境１００を例示する図である。
【図２】本発明によるアーキテクチャ２００を例示する図である。
【図３】本発明によるプロセス３００の最上位レベルの流れ図を例示する図である。
【図４】本発明による図２のアーキテクチャ２００の一部（サブセット）を例示する図である。
【図５】本発明による図２のデバイス・ペア情報レジスタ２４０についての例示的論理流れ５００を例示する図である。
【図６】本発明による図２のグローバル情報レジスタ２５０に設けられたテーブル６００を例示する図であり、より詳細には、第１のデバイスがマスタであり、第２のデバイスがスレーブ・デバイスである３つのＰＣＩデバイス１、２および３のトランザクションの可能な組み合わせ（たとえば、６つ）を示す図である。
【図７】バスを介して発生するマスタ・スレーブ・トランザクションの様々な組み合わせを示すテーブル６５０を例示する図である。
【図８】単一のトランザクションではなく、いくつかのトランザクションに基づいて故障チェック診断が行なわれるテーブルを例示する図である。
【図９】本発明による複数のマスタ・スレーブの組み合わせの間の移行の論理的流れ７００を例示する図である。
【図１０】本発明によるバス上のデバイス「１」についてのプロセス８００の流れ図を例示する図である。
【図１１】本発明によるロジック９００を例示する図である。
【図１２】本発明によるロジック１０００を例示する図である。
【図１３】バス（たとえば、ＰＣＩバス）上のターゲット・デバイスのアドレスの取り込みを例示する図である。
【図１４】本発明による、プロトコルが違反されているかどうかを決定するためのプロセス１２００の流れ図を例示する図である。
【図１５】本発明による、もう１つのプロトコルが違反されているかどうかを決定するためのプロセス１３００の流れ図を例示する図である。
【図１６】本発明による図１３の方法と共に使用されるプロセス１４００の流れ図を例示する図である。
【図１７】本発明をその中に組み込むための例示的ハードウェア／情報処理システム１５００を例示する図である。
【図１８】本発明による方法のプログラムのステップを格納するための信号搬送媒体１６００（たとえば、ストレージ・メディア）を例示する図である。
【符号の説明】
【０１５０】
１１０  モニタ
１１５  ＰＣＩデバイス
１２０  エージェント
１２５  診断ロジック
１３０  エージェント
１３５  診断ロジック
１４０  ＰＣＩバス
２１０  ターゲット・デバイス情報を得るための方法／手段
２２０  モニタベースの手法を使用してプロトコルの違反を決定するためのＶＨＤＬコード
２３０  デバイス・ペア検出器
２４０  デバイス・ペア情報レジスタ
２５０  グローバル情報レジスタ
２６０  エラー検出ロジック
２７０  論理演算デバイス
【図１】
2004192640.tif 000003
【図２】
2004192640.tif 000004
【図３】
2004192640.tif 000005
【図４】
2004192640.tif 000006
【図５】
2004192640.tif 000007
【図６】
2004192640.tif 000008
【図７】
2004192640.tif 000009
【図８】
2004192640.tif 000010
【図９】
2004192640.tif 000011
【図１０】
2004192640.tif 000012
【図１１】
2004192640.tif 000013
【図１２】
2004192640.tif 000014
【図１３】
2004192640.tif 000015
【図１４】
2004192640.tif 000016
【図１５】
2004192640.tif 000017
【図１６】
2004192640.tif 000018
【図１７】
2004192640.tif 000019
【図１８】
2004192640.tif 000020