JP3920280B2 - Ｉ２ｃルータを通じたデータ送信方法 - Google Patents

Description

本発明は、データ処理の分野に関する。

有用なタスクを実行するのに、多くの電子回路および電子システムが利用されている。
これらのタスクの実行において、電子回路および電子システムは、通信バスを介して相互に通信することが多い。
通信バスの１つのタイプが、集積回路間バス（Ｉ２Ｃ（inter-integrated circuit）バス）である。
Ｉ２Ｃバスは、集積回路（ＩＣ）と電子システムとの間の通信リンクを提供する。
従来、Ｉ２Ｃバスは、シリアルデータライン（ＳＤＡ）およびシリアルクロックライン（ＳＣＬ）と呼ばれる２つのアクティブワイヤからなる。

従来技術の図１は、従来の例示的な配置で構成されたＩ２Ｃバスシステム１００を示したものである。
このＩ２Ｃバスシステム１００では、管理プロセッサ１１０が、Ｉ２Ｃバス１１５上の通信アクセスを管理する。
Ｉ２Ｃバス１１５は、ＳＣＬライン１１２およびＳＤＡライン１１４を含む。
これらのＳＣＬライン１１２およびＳＤＡライン１１４は、モジュール形式のフィールド交換可能ユニット（ＦＲＵ）１２０、１２１、および１２２に接続される双方向通信パスを提供する。
プルアップ抵抗器１３５および１３７は、ＳＣＬライン１１２およびＳＤＡライン１１４にそれぞれ接続されて、各ラインのデフォルト状態を確立する。
ＦＲＵは、サーバブレード、サーバカード、ドライバ、メモリ、または複合機能ＩＣが含まれるさまざまなコンポーネントとすることができる。
Ｉ２Ｃバスは、インテリジェントプラットフォーム管理インターフェース（ＩＰＭＩ（Intelligent Platform Management Interface））または他のＩ２Ｃプロトコルと共に使用することができる。

従来のＩ２Ｃバスは、バスに接続されたデバイス間でのパケット（例えば、ヘッダ、データ、およびトレーラを含む明確に定義されたデータブロック）の送信用にマスタ−スレーブ通信プロトコルまたはマスタ−マスタ通信プロトコルを利用する。
Ｉ２Ｃバスに接続されたコンポーネント（例えばＦＲＵ）は、一意のアドレスを有し、（例えば、そのデバイスの特定の機能に応じて）データの送り手または受け手として振る舞うことができる。
ＩＰＭＩによると、バス上のそれぞれの「インテリジェント」デバイスは、マスタとしての役割を果たし、マスタ−マスタ通信プロトコルを利用する。
別のマスタ（例えば管理プロセッサ）がバスを制御している間に、あるコンポーネント（例えばＦＲＵ１２０）が、Ｉ２Ｃバス上で情報の送信を試みる場合には、そのコンポーネントは、Ｉ２Ｃの調停ルールに従わなければならない。
基本的に、バスの制御権を得ようと試みているすべてのデバイスは、バスの監視も行わなければならず、そして、信号が、その個々のデバイスが書き込もうとしているものと一致しないとすぐに引き下がらなければならない。
バスは、プルアップ抵抗器によってハイレベルに引き上げられており、アクティブなデバイスによってのみローレベルに駆動されるので、ローレベルを駆動するデバイスが、バスの制御権を得る。

通信システムの１つの主要な関心事は、セキュリティの保持である。
意図的でないエンティティおよび／または認可されていないエンティティがバス上で通信される情報にアクセスすることを防止することが、一般に望ましい。
しかしながら、従来、意図的でないコンポーネントが、Ｉ２Ｃバス上の通信をスプーフィングすることは一般に可能である。
例えば、共通の筐体（例えば、共通の筐体においてスロットが貸し出されているホスト−クライアントの状況）のＩ２Ｃバス上における、第１のエンティティ（例えば第１の企業）が利用するコンポーネント向けの通信は、第２のエンティティ（例えば競争相手企業）が利用する別のコンポーネントによって受信可能である。
より具体的に言うと、Ｉ２Ｃバスを「スプーフィング」するデバイスは、この特定の「スプーフィング」を行うデバイスに宛てられていなかったデータ（例えば競争相手の機密情報）を故意に受信することが可能である。

従来のＩ２Ｃバスシステムの保守には、多くの問題が発生している。
例えば、Ｉ２Ｃバスのあるセグメントにバス障害があると、バスに接続されたコンポーネントが破損したセグメントにない場合であっても、そのコンポーネントへの通信は、通常、失われる。
適切な保守を提供するには、Ｉ２Ｃバスに接続されたデバイスのタイプおよび個数をよく理解することが、一般に有益である。
従来、これは、手作業で行われており、特に、コンポーネントが遠隔に位置する場合には、大きな労力を必要とし、多くの場合、不便であった。
また、システムのエラーを発見して是正の方向を提供することも、一般に困難であった。
例えば、あるデバイスがマスタになって、他のデバイスのバスの使用を妨げる情報を絶えず送信することによりバスを有効に「捕捉」するといった状況は、従来、検出および修正することが困難であった。
Ｉ２Ｃバスに接続されたデバイスの容量特性も、多くの場合、保守および再構成を困難にする可能性がある。

Ｉ２Ｃバスに接続されたコンポーネントは、一般に、Ｉ２Ｃバス上に容量性負荷を生成する。
この容量性負荷は、プルアップ抵抗器と共に、Ｉ２Ｃバスを介して通信される信号の属性に影響を与えるＲＣ定数の特性を生成する。
例えば、信号波形が、変更される可能性があり、コンポーネントが論理的な１と０とを区別する機能が、影響を受ける可能性がある。
その結果、Ｉ２Ｃバスラインの容量特性と抵抗特性との間の適切なバランスを維持することが望ましい。
しかしながら、バス上のコンポーネントの個数およびタイプが容量特性に影響を与えるので、コンポーネントを動的に追加したり除去したりすると、容量および抵抗のバランスを維持することは困難となる可能性がある。
バランスを実現する従来の試みは、一般に、Ｉ２Ｃに接続されるコンポーネントの個数を制限するものであり、多くの場合、高価なバスの再設計が必要となるものであった。
この再設計が誤って行われると、バス割り込みが引き起こされる可能性があり、場合によっては、破局的なバス障害が引き起こされる可能性がある。

現在のＩ２Ｃバスシステムでは、各コンポーネントにＩ２Ｃアドレスが割り当てられる。
例えば、図１を参照して、ＦＲＵ１２０、ＦＲＵ１２１、およびＦＲＵ１２２はそれぞれ、割り当てられたＩ２Ｃアドレスを有する。
上述したように、ＦＲＵ１２０が第１のエンティティによって操作され、ＦＲＵ１２１が第２のエンティティによって操作される状況を考察する。
第２のエンティティが、ＦＲＵ１２０へ送信中のデータにアクセスしたい場合、ＦＲＵ１２１は、ＦＲＵ１２０のＩ２Ｃアドレスを使用することにより、現在のＩ２Ｃバスシステムをスプーフィングして、ＦＲＵ１２１がＦＲＵ１２０であると信じさせることができる。

また、従来技術によるＩ２Ｃバスは、当該Ｉ２Ｃバスに接続されたデバイス（例えば、フィールド交換可能ユニット）の存在を検出できないという欠点、Ｉ２Ｃバスに接続されたデバイスが有効であるかどうかを判断できないという欠点、および／またはエラーが発生してもデバイスをリセットできないという欠点もある。
さらに、従来技術によるＩ２Ｃバスには、Ｉ２Ｃバス上のデータトラフィックを容易に分析してデバッグすることができないという欠点もある。
シリアルの２ラインＩ２Ｃバスは、イベントをトラップする場合、シリアルデータパターンをトラップしなければならないので、イベントのトラップが困難である。
さらに、どのデバイスが、送信元デバイスであるかを検出することも困難である。
すなわち、宛先のデバイスアドレスしか容易にトラップできない。

本発明は、上述の背景からなされたものであり、セキュリティ向上などのために改良されたＩ２Ｃルータを通じたデータ送信方法を提供することを目的とする。

送信元ポートから宛先ポートへＩ２Ｃルータを通じてデータを送信する方法であって、Ｉ２Ｃルータの第１のＩ２Ｃ送信元ポートバッファにデータを受信すること、第１のＩ２Ｃ送信元ポートバッファがオーバーフローする前に、Ｉ２Ｃ宛先ポートを捕捉すること、第２のＩ２Ｃ送信元ポートバッファからＩ２Ｃ宛先ポートへの送信を制限すると同時に、第１のＩ２Ｃ送信元ポートバッファからＩ２Ｃ宛先ポートへデータを送信することを含む方法である。

添付図面の図に、限定としてではなく例として本発明を示す。
添付図面において、同じ参照符号は、同様の要素を参照する。

次に、本発明の実施の形態を詳細に参照する。
これらの実施の形態の例を添付図面に示す。
本発明を、これらの実施の形態と共に説明するが、実施の形態は、本発明をこれらの実施の形態に限定することを意図するものはないことが理解されよう。
それとは反対に、本発明は、代替なもの、変更したもの、および均等なものをカバーするように意図されており、これらは、添付した特許請求の範囲によって画定されるような本発明の精神および範囲内に含めることができる。
さらに、以下の本発明の詳細な説明では、本発明の十分な理解を提供するために、多数の具体的な細部について述べる。
しかしながら、本発明は、これらの具体的な細部がなくても実践することができることが理解されよう。
それ以外の場合には、既知の方法、手順、コンポーネント、および回路は、本発明の態様を不必要に分かりにくくしないように詳細に説明していない。

［集積回路間ルータ］
次に、図２を参照する。
図２には、本発明の一実施の形態による集積回路間（Ｉ２Ｃ）ルータシステム２００のブロック図を示す。
この例示のＩ２Ｃルータシステム２００は、管理プロセッサ２０１、Ｉ２Ｃルータ２５０、ならびに複数のフィールド交換可能ユニット（ＦＲＵ（field removable unit））２２０、２２１、および２２２を備える。
管理プロセッサ２０１は、高速外部バス２４０によってＩ２Ｃルータ２５０に接続されている。
ＦＲＵ２２０、２２１、および２２２は、電気的に分離されたＩ２Ｃバス部２４１、２４２、および２４３によってＩ２Ｃルータ２５０にそれぞれ接続されている。
それぞれのＩ２Ｃバス部２４１、２４２、および２４３は、ＳＤＡラインおよびＳＣＬラインを備える。
例えば、Ｉ２Ｃバス部２４１のＳＤＡライン２６１およびＳＣＬライン２７１は、ＦＲＵ２２０をＩ２Ｃルータ２５０に通信接続し、Ｉ２Ｃバス部２４２のＳＤＡ２６２およびＳＣＬライン２７２は、ＦＲＵ２２１をＩ２Ｃルータ２５０に通信接続し、Ｉ２Ｃバス部２４３のＳＤＡライン２６３およびＳＣＬライン２７３は、ＦＲＵ２２２をＩ２Ｃルータ２５０に通信接続する。
プルアップ抵抗器（例えば、プルアップ抵抗器２９０）は、ＳＤＡラインおよびＳＣＬライン（例えば、ＳＣＬライン２７３）に接続されている。

例示のＩ２Ｃルータ２５０は、高速外部ポート２１０、高速内部バス２８１、Ｉ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎを備える。
Ｉ２Ｃルータ２５０は、任意の個数のポートを備えることができ、この実施の形態に限定されるものではないことが理解されるべきである。
高速内部バス２８１は、高速外部ポート２１０、ならびにＩ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎに接続されている。
一実施の形態において、それぞれのＩ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎは、それぞれ、電気コネクタ２５９ａ、２５９ｂ、および２５９ｎに接続されたコントローラ２５７ａ、２５７ｂ、および２５７ｎを含む。

一実施の形態において、例示のＩ２Ｃルータ２５０のコンポーネントは、協働的に動作して、Ｉ２Ｃルータ２５０に含まれるポートを通る通信を制御することにより、Ｉ２Ｃルータ２５０に接続されたＩ２Ｃバス部（例えば、Ｉ２Ｃバス部２４１、２４２、および２４３）の間の通信のセキュリティを提供する。
電気コネクタ２５９ａ、２５９ｂ、および２５９ｎは、それぞれのＩ２Ｃバス部２４１、２４２、および２４３をＩ２Ｃルータ２５０に通信接続する。
例示の一実施態様において、各電気コネクタは、シリアルデータピンおよびシリアルクロックピンを含む。
コントローラ２５７ａ、２５７ｂ、および２５７ｎは、対応する電気コネクタ２５９ａ、２５９ｂ、および２５９ｎを流れるデータ通信を制御し、これらの電気コネクタが、認可されずにデータ（例えば、内部高速バス２８１上で通信されるデータ）にアクセスすることを防止する。
本発明の一実施の形態において、コントローラは、フィールドプログラマブルゲートアレイ、マイクロプロセッサなどとすることができる。

電気コネクタによる認可されていないデータアクセスを防止することによって、Ｉ２Ｃルータ２５０を利用して相互に通信する外部コンポーネントまたはデバイス（例えば、ＦＲＵ２２０、２２１、および２２２）のセキュリティがさらに提供される。
例えば、コントローラ２５７ａは、電気コネクタ２５９ａを通じたＩ２Ｃバス２４１上への通信について、内部高速バス２８１からのデータのスプーフィングを防止する。
集積回路間ポートの下流に接続されたＦＲＵが、情報の受信を認可されていない場合に、集積回路間ポートは、上記情報がＩ２Ｃバス部へ通信されるのを妨げることができる。
したがって、それぞれのバス部（例えば、２４１および２４３）に接続されたデバイス（例えば、ＦＲＵ２２０および２２２）を制御する１つのエンティティ（例えば企業）または複数のエンティティ（例えば、供給業者と購入者）は、別個のバス部（例えば２４２）に接続されたデバイス（例えばＦＲＵ２２１）を制御する認可または承認されていないエンティティ（例えば競争相手）による情報の不正なスプーフィングを受けることなく、互いに情報を通信することができる。
本発明のコントローラ（例えば２５７ｂ）は、情報が、対応する電気コネクタ（例えば２５９ｂ）を介して通信されることを防止するので、認可または承認されていないエンティティは、情報を不正に受け取ることができない。

高速内部バス２８１は、Ｉ２Ｃルータ２５０のコンポーネントに内部通信パスを提供する。
高速内部バス２８１は、パラレルバスとすることもできるし、本発明のさまざまな構成と互換性のある他の任意の高速バスとすることもできることが理解されよう。
高速内部バス２８１は、Ｉ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎのそれぞれの間で情報を通信し、また、これらのポートのそれぞれと高速外部ポート２１０との間でも情報を通信する。
高速内部バス２８１の通信速度は、各ポートの外部通信速度と異なってもよい。
オプションとして、ポート２５３ａ、２５３ｂ、２５３ｎ、および／または２１０は、各ポートで通信される情報をバッファリングするキャッシュメモリを備える。
これらのキャッシュと高速内部バスとの組み合わせにより、複数のポートは、Ｉ２Ｃルータ２５０への情報の通信およびＩ２Ｃルータ２５０からの情報の通信を同時に行うことが可能になる。

キャッシュのサイズは、さまざまなＩ２Ｃルータ２５０の実施態様に従って構成することができる。
例えば、インテリジェントプラットフォーム管理インターフェース（ＩＰＭＩ）がパケットを３２バイトに制限し、Ｉ２Ｃルータ２５０がこのＩＰＭＩプロトコルを利用する構成で使用される場合、キャッシュは、そのパケットサイズの倍数（例えば、６４バイト、９６バイトなど）のサイズにすることができる。
リトライ方式およびフロー制御方式を利用してオーバーフロー状況の処理を援助する本発明の実施の形態では、付加的な柔軟性を実現することができる。
例えば、特定のポートに関連付けられたキャッシュが、あらかじめ定められた容量に達すると、プログラミングされたオーバーフロー制御ルーチンが、バスに割り込みを行って、そのポートがそのメモリをダンプしてエラーを防止できるようにする。

本発明の一実施の形態において、Ｉ２Ｃルータ２５０の集積回路間ポートは、Ｉ２Ｃバス部２４１、２４２、および２４３の相互間のセグメント化または分離を提供する。
集積回路間ポートは、Ｉ２Ｃバス部の相互間を電気的に分離する。
例えば、ポート２５３ａ、２５３ｂ、および２５３ｎは、Ｉ２Ｃバス部２４１、２４２、および２４３の相互間を電気的に分離する。
Ｉ２Ｃバスを電気的に分離することにより、Ｉ２Ｃバス部に接続されたデバイス（例えば、ＦＲＵ２２０、２２１、および２２２）のホットスワッピングが容易になる。
例示の一実施態様では、Ｉ２Ｃバス部を電気的に分離することによって、ＦＲＵのスワッピングにより影響を受けるＩ２Ｃバス部のプルアップ抵抗器（例えば、プルアップ抵抗器２９０）を変更して容量の変化を吸収する必要なく、ＦＲＵのスワッピングが可能になる。

さらに、Ｉ２Ｃバス上のデバイスを電気的に分離することによって、容量限界（例えば、４００ｐＦ、Ｉ２Ｃ仕様限界など）に達するまでの間、本発明は、Ｉ２Ｃルータ２５０に接続された各バス部に、バス部に接続されたデバイスのタイプおよび／または個数に関して、より大きな柔軟性を有利に提供する。
したがって、全体の容量限界には、従来のＩ２Ｃバスが使用された場合よりも柔軟性が得られる。
また、Ｉ２Ｃバス部をセグメント化して電気的に分離することにより、Ｉ２Ｃバス部の１つに接続されたデバイス（例えばＦＲＵ）が障害を起こした場合であっても、Ｉ２Ｃ機能を維持することも容易となる。
あるＩ２Ｃバス部（例えば、Ｉ２Ｃバス部２４２）に接続されたデバイス（例えばＦＲＵ２２１）が、障害を起こしても、そのデバイスは、他のＩ２Ｃバス部（例えば、２４１および２４３）に接続された他のデバイス（例えば、ＦＲＵ２２０および２２２）が相互に通信することを妨げることはない。

本発明の一実施の形態において、Ｉ２Ｃルータ２５０は、パケットベースのルータである。
このパケットベースのルータでは、数バイトが、ポートで同時（例えば、Ｉ２Ｃ停止（STOP）状態の待機中）に読み出され、次いで、Ｉ２Ｃルータ２５０の別のポートに転送される。
Ｉ２Ｃルータ２５０の各ポートは、接続されたＩ２Ｃバス（例えば、２４１、２４２、および２４３）上の正当なＩ２Ｃ通信プロトコルの挙動を認識でき、Ｉ２Ｃルータ２５０は、必要に応じてＩ２Ｃハンドシェークを処理できる。
例示の一実施態様において、Ｉ２Ｃルータ２５０は、別のＩ２Ｃポートに接続されたデバイスが、Ｉ２Ｃルータ２５０と同時に通信することを許可することができ、それによって、従来、Ｉ２Ｃバスの部分が空くまでデバイスが必ず待たなければならないという必要はなくなる。
一実施の形態において、Ｉ２Ｃルータ２５０のポートに接続されたＦＲＵまたはデバイスは、従来のＩ２Ｃバスにおいて動作するのと同様に通常どおり動作し、Ｉ２Ｃルータ２５０の存在は、ＦＲＵまたはデバイスにはトランスペアレントなものである。

図２を続けて参照して、Ｉ２Ｃルータ２５０の高速ポート２１０は、高速外部バス２４０を介して外部デバイスに接続することができる。
高速外部バス２４０は、パラレルポートバスとすることもできるし、高速Ｉ２Ｃバスとすることもできるし、他の任意の高速バスとすることもできることが理解されよう。
この場合も、Ｉ２Ｃルータ２５０は、別のポート（例えば、Ｉ２Ｃポート２２０、２２１、および／または２２２）から受信したデータをキャッシュして、高速外部バス２４０上にデータをポンピングするバッファをオプションとして備える。
それによって、Ｉ２Ｃルータ２５０に接続された複数のデバイスが、同時に通信することが可能になる。

本発明の一実施の形態では、電気コネクタ２５９ａ、２５９ｂ、および２５９ｎは、Ｉ２Ｃバス２４１、２４２、および２４３にそれぞれ通信接続するためのＩ２Ｃバスカプラである。
例示の一実施態様において、コントローラ３５１は、高速内部バス３７５（２４３ではない）を介してこれらのＩ２Ｃバスカプラに接続されたポート管理コンポーネントである。
このポート管理コンポーネントは、上記Ｉ２Ｃコネクタが上記データに不正にアクセスするのを防止することを含めて、Ｉ２Ｃバスカプラを通るデータ通信フローを管理する。

本発明は、さまざまな実施態様に容易に適用できることが理解されよう。
一実施の形態において、第２のポート（例えば２５３ｂ）からの情報が、第１のポート（例えば２５３ａ）にもアドレス指定されておらず、第１のポートに接続された外部デバイス（例えばＦＲＵ２２０）にもアドレス指定されていない場合、第１のポートに関連付けられたコントローラ（例えば２５７ａ）は、第２のポートからの情報が第１のポートを介して電気コネクタ（例えば２５９ａ）に通信されるのを防止する。
さらに別の実施の形態では、コントローラ（例えば、２５７ａ、２５７ｂ、２５７ｎ）は、Ｉ２Ｃポートが、別のＩ２Ｃポートにデータを送信することも防止する。

次に図３を参照する。
図３には、本発明の一実施の形態による集積回路間（Ｉ２Ｃ）ルータ３５０のブロック図３００を示す。
Ｉ２Ｃルータ３５０は、ポート３５３ａ、３５３ｂ、および３５３ｎのそれぞれにコントローラを有するのではなく単一のコントローラ３５１を有する点を除いて、Ｉ２Ｃルータ２５０と同様である。
Ｉ２Ｃルータ３５０は、高速内部バス３７５、コントローラ３５１、外部高速ポート３１０、ならびにＩ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎを備える。
高速内部バス３７５は、コントローラ３５１、高速外部ポート３１０、ならびにＩ２Ｃポート２５３ａ、２５３ｂ、および２５３ｎに接続されている。
高速内部バス３７５は、双方向とすることができることが理解されよう。
Ｉ２Ｃルータ３５０は、任意の個数のポート（例えば、１６個の個別のＩ２Ｃポート）を含むことができることも理解されよう。
コントローラ３５１は、対応するポート３５３ａ、３５３ｂ、および３５３ｎを通るデータ通信フローを制御し、これらのポートが認可されずにデータ（例えば、内部高速バス３７５上で通信されるデータ）にアクセスすることを防止する。
本発明の一実施の形態において、コントローラは、フィールドプログラマブルアレイ、マイクロプロセッサなどとすることができる。

コストなどの要因が、ルータの構成に影響を与えることがあり、コストの目的に応じて、ポートが、それ自身のコントローラをその内部に有することもあるし、各ポートが、中央コントローラを共有することもある。
本発明の実施の形態によると、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの単一のユニットを使用して、ルータ内のポートのすべてを制御することができ、この場合、その汎用入出力ピンは、Ｉ２Ｃバスとして使用され、したがって、Ｉ２Ｃポートがその内部に作成される。

本発明は、さまざまなＩ２Ｃバス構成（例えば、単一のＩ２Ｃバス上で記述可能な１２７個のアドレス用のＩ２Ｃ仕様規定と互換性のあるシステム）での使用に容易に適合することができる。
本発明の一実施の形態において、Ｉ２Ｃルータは、Ｉ２Ｃルータのいずれのポートについても、ポートアドレスへの双方向（例えば、データ受信方向およびデータ送信方向）の通信を阻止することができる。
例えば、ポート２５３ａが、ポート２５３ｂとの通信のみを許可され、ポート２５３ｂが、ポート２５３ａとの通信のみを許可されていると仮定する。
ポート２５３ａからそれ以外のどのアドレス（例えば、ポート２５３ｎ）へのどのパケットも、Ｉ２Ｃルータ２５０を通じて転送されない。
その結果、Ｉ２Ｃルータ２５０によってサポートされるＩ２Ｃデバイスの個数は、そのルータのポート数の１２７倍に増加する。
例えば、Ｉ２Ｃルータ２５０が、１６個のポートを有する場合、利用可能なアドレス数は、２０３２個となる。
したがって、２０３２個までのデバイスを１６ポートのＩ２Ｃルータに接続することが可能になる。

次に図４を参照する。
図４には、本発明の一実施の形態に従って、集積回路間（Ｉ２Ｃ）ルータでの通信を制御するプロセスのフロー図４００を示す。
本発明の一実施の形態によると、ルータは、ポートが情報をスプーフィングする能力を制限することによって、ポート間の通信を制御する。

ステップ４１０において、Ｉ２Ｃバス接続インターフェース上で通信されるデータが受信される。
本発明の実施の形態において、Ｉ２Ｃバス接続インターフェースは、Ｉ２Ｃコネクタアドレスと関連付けられている。
そのデータに含まれる宛先アドレスが、Ｉ２Ｃコネクタアドレスに対応しているかどうかが判断される。
例えば、受信データパケットが検査されて、そのデータパケットのヘッダ部において、送信元アドレスおよび宛先アドレスが特定される。
データが、Ｉ２Ｃコネクタアドレスに対応している場合、そのＩ２Ｃ接続インターフェースが、そのデータの通信の承認を受けているものであるかどうかを分析する分析が行われる。
例示の一実施態様において、データは、Ｉ２Ｃバス部を介してサーバブレードから受信される。
データは、（例えば、高速外部バス、外部Ｉ２Ｃバスなどから）Ｉ２Ｃルータの第１のバス接続インターフェース上で受信できることが理解されよう。
この場合、データは、Ｉ２Ｃルータに含まれる第２のバス接続インターフェース宛てのものである。

Ｉ２Ｃバス接続インターフェースが、データの通信の承認を受けている場合には、ステップ４２０において、データは、Ｉ２Ｃバス接続インターフェース上で転送される。
本発明の一実施の形態において、データは、あるデバイス（例えばＦＲＵ）へＩ２Ｃバス部を介して転送される。

Ｉ２Ｃバスコネクタが承認を受けていない場合には、ステップ４３０において、Ｉ２Ｃ接続インターフェース上でのデータの通信は禁止される。
Ｉ２Ｃインターフェース上での通信を禁止することにより、Ｉ２Ｃバス上での「スプーフィング」が防止され、これによって、外部コンポーネントまたはデバイス（例えば、図２からのＦＲＵ２２０、２２１、および２２２）には、セキュリティがさらに提供される。

集積回路間（Ｉ２Ｃ）通信制御方法４００の一実施の形態において、Ｉ２Ｃバス接続インターフェースは、Ｉ２Ｃバスを異なる部分に分割するのに利用される。
例えば、Ｉ２Ｃバス接続インターフェースは、Ｉ２Ｃバスの一部を電気的に分離するのに利用される。
Ｉ２Ｃバス接続インターフェースがＩ２Ｃバスを異なる部分に分割するのに利用される例示の一実施態様においては、プルアップ抵抗（例えば、図２のプルアップ抵抗器２９０）を変更することなく、Ｉ２Ｃバス接続インターフェースに接続されたコンポーネントのホットスワッピングが可能になる。

次に図５を参照する。
図５には、本発明の実施の形態による集積回路間（Ｉ２Ｃ）ルータのブロック図を示す。
ルータ５７０は、高速ポート５１０を備える。
高速ポート５１０は、このルータを高速外部バス５４０に接続する。
高速バス５４０は、高速Ｉ２Ｃバスとすることもできるし、パラレルバスとすることもできるし、当技術分野で既知の他の任意の高速バスとすることもできることが理解されよう。
本発明による一実施の形態において、高速バス５４０は、８線パラレルバスである。

高速ポート５１０は、高速内部バス５７５上の通信を制御する制御ロジック５１５を備える。
制御ロジックは、マスク５３０に接続されている。
マスク５３０は、制御ロジック５１５に制御情報を提供する。
また、高速ポート５１０は、高速内部バス５７５上の通信をバッファリングするオプションバッファ５２０も含む。
上述したように、オーバーフロールーチンおよびバッファリング方式は、制御ロジック５１５によって実施されて、データオーバーフローから生じるエラーからの保護を行う。
オプションとして、高速ポート５１０は、エラーレジスタおよび対応するシステムイベントログを備える。
エラーレジスタは、ルータにおけるエラーを追跡し、システムイベントログは、エラーを編成して、報告することができる。

高速内部バス５７５には、複数のＩ２Ｃポートが接続されている。
分かりやすくするために、図５は、２つのＩ２Ｃポート５５０および５６０を示している。
ポート５５０は、制御ロジック５１６およびマスク５３１を備える。
制御ロジック５１６は、ポート５５０の通信を制御する。
マスク５３１は、制御ロジック５１６に制御情報を提供する。
マスク５３１は、ソフトウェアを使用してプログラミングすることもできるし、Ｉ２Ｃデュアルインラインプラグ（ＤＩＰ）スイッチにより手動でプログラミングすることもできることが理解されよう。
マスク５３１は、ポート５５０がデータ送信可能なポートアドレスを提供する。
ポートが、マスク５３１において許可されていないアドレスへデータを送信しようとすると、そのデータは、ルータ５７０に入力されない。
各Ｉ２Ｃポートは、Ｉ２Ｃプロトコルを制御するＩ２Ｃコントローラも含むことが理解されよう。
ポート５６０は、ポート５５０と同様に構成され、この場合、ポート５６０は、制御ロジック５１７、マスク５３２、およびオプションバッファ５２２を備えることが理解されよう。
本発明の実施の形態によると、ルータ５７０の複数のポートは、中央制御ロジックおよび中央マスクを共有する。
集中化した構成では、単一のプロセッサおよび単一のマスクが、高速内部バス５７４上の通信を制御することができる。

Ｉ２Ｃポート５５０およびポート５６０には、従来のＩ２Ｃバス接続をデバイスに提供してデバイスへ接続を行うＳＤＡライン５６１とＳＣＬライン５７１、および、ＳＤＡライン５６２とＳＣＬライン５７２が、それぞれ接続されている。
ポート５５０は、Ｉ２Ｃバス５４１に接続され、ポート５６０は、Ｉ２Ｃバス５４２に接続されている。
本発明の一実施の形態によると、Ｉ２Ｃポート５５０は、自身に接続されたデバイスの存在を検出するためのオプションの検出ラインも含む。
さらに、ポート５５０に接続された応答しないデバイスをリセットするオプションのリセットラインが、ポート５５０に接続される。
リセットラインは、ルータ５７０でエラーを引き起こしているデバイスをリセットする手段を提供することができる。
本発明の一実施の形態において、高速ポート５１０は、デバッグロジックを備える。
このデバッグロジックは、ルータでエラーを起こしているデバイスに接続されたリセットラインを、その応答しないデバイスをリセットするように切り換えることができる。

本発明の実施の形態によると、例えばポート５５０や５６０など、ルータ５７０に接続されたポートは、異なる速度でルータ５７０と通信することができる。
例えば、ポート５５０に接続されたデバイスは、わずか１００ｋｂ／ｓでしか通信できない場合があり、ポート５６０は、自身に接続されたデバイスであって、１．４Ｍｂ／ｓで通信できるデバイス、を有する場合がある。
内部高速バス５７５は、ルータ５７０のＩ２Ｃポートに接続されたデバイスが高速で通信できるような帯域幅を提供する。

上述したように、本発明は、制御ロジックおよびアドレスマスクを使用して、Ｉ２Ｃバスをセグメント化するポートの通信を制御することにより、Ｉ２Ｃバス上にセキュリティを提供する。
有利なこととして、ルータ５７０のポートに接続されたデバイスは、従来のＩ２Ｃバス上で動作するのと同様に通常どおり動作し、それらのデバイスは、ルータ５７０に気付くことはない。
好都合なこととして、ルータ５７０は、Ｉ２Ｃバスをデバイスごとに電気的にセグメント化し、有利なこととして、特定のポートの特定の送信元に宛てられたパケットのみがそのポートに転送される。

Ｉ２Ｃバス上にセキュリティを提供することに加えて、本発明は、Ｉ２Ｃバス上のデバイスを電気的に分離することによって、ホットスワッピングを可能にする。
従来のＩ２Ｃバスの実施態様では、すべてのデバイスが単一のバスを共有し、かつ、当該単一のバスに取り付けられるが、この従来のＩ２Ｃバスの実施態様とは対照的に、本発明は、有利なこととして、ルータに接続されたデバイスを電気的に分離する。
したがって、バス上のあらゆる障害デバイスは、他のポートの他のデバイスに影響を与えることはない。
さらに、Ｉ２Ｃバスをセグメント化して、Ｉ２Ｃバス上のデバイスを電気的に分離することにより、プルアップ抵抗器を変更してバス上の容量の変化を吸収する必要なく、Ｉ２Ｃバス上のデバイスをホットスワッピングすることが可能になる。
その上、Ｉ２Ｃバス上のデバイスを電気的に分離することにより、本発明は、ルータの各ポートをＩ２Ｃ仕様の４００ｐＦの容量限界に近づける。
したがって、各セグメントまたはポートに必要な容量の要件は、従来のＩ２Ｃバスが使用された場合よりも緩和されたものとすることができる。

［集積回路間ポートにおけるデータ通信を安全に制御するプロセス］
図５を全体的に参照して、本発明の実施の形態は、Ｉ２Ｃルータ５７０を通じたデータ通信を安全に制御するプロセスを提供する。
一実施の形態において、Ｉ２Ｃルータ５７０は、Ｉ２Ｃポート５５０、Ｉ２Ｃポート５６０、および高速ポート５１０を備える。
Ｉ２Ｃルータ５７０は、任意の個数のＩ２Ｃポートを備えることができ、図５に示す実施の形態によって限定されないことが理解されるべきである。
例えば、Ｉ２Ｃルータ５７０は、１６個のＩ２Ｃポートを備えることができる。
各Ｉ２Ｃポートは、高速内部バス５７５に接続されている。

一実施の形態において、各Ｉ２Ｃポートは、コントローラ（例えば、Ｉ２Ｃポート５５０の制御ロジック５１６およびＩ２Ｃポート５６０の制御ロジック５１７）と、マスクレジスタ（例えば、Ｉ２Ｃポート５５０のマスク５３１およびＩ２Ｃポート５６０のマスク５３２）とを備える。
このコントローラは、マスクレジスタが提供する制御情報に基づいてＩ２Ｃポートを通じたデータ通信を制御するように動作できる。
一実施の形態において、マスクレジスタは、コントローラ（例えば制御ロジック５１６）のランダムアクセスメモリ（例えばＲＡＭ）内に記憶される。
制御情報は、Ｉ２Ｃポートを通じた送信が許可されるデータ通信を指定するものである。
一実施の形態において、制御情報は、Ｉ２Ｃポートを通じてデータを送信することができる宛先のＩ２Ｃアドレスを指定する。

一実施の形態において、Ｉ２Ｃルータ５７０は、アドレスを制御情報と比較する論理回路を備える。
一実施の形態において、この論理回路は、アドレスを制御情報と比較するための排他的ＯＲ（ＸＯＲ）およびＡＮＤの論理回路を備える。
このＸＯＲおよびＡＮＤの論理回路は、制御ロジック（例えば、制御ロジック５１５、５１６、および５１７）内に含めることができる。

一実施の形態において、Ｉ２Ｃルータ５７０は、ポート識別タグ（ＰＩＴ（port identification tag））レジスタを備える。
１つのＩ２Ｃポートまたは１組のＩ２Ｃポートが、特定のデータ通信の受信者であると識別されると、アクセスの妥当性確認が、ＰＩＴレジスタで示される。
一実施の形態において、ＰＩＴレジスタは、コントローラ（例えば制御ロジック５１６）のＲＡＭ内に記憶される。
ＰＩＴレジスタは、少なくとも、Ｉ２Ｃルータ５７０に存在するポートと同数のビットを含むことが理解されるべきである。
アクセスの妥当性確認は、ＰＩＴレジスタで「１」として示される。

次に図６Ａを参照する。
図６Ａには、本発明の一実施の形態に従って、集積回路間（Ｉ２Ｃ）ポートにおけるデータ通信を安全に制御するコンピュータ実施されるプロセス６００のフロー図を示す。
本発明による一実施の形態において、プロセス６００は、集積回路間ポート（例えば、図５のＩ２Ｃポート５５０）で実行される。
プロセス６００には、具体的なブロックが開示されるが、このようなブロックは例示である。
すなわち、本発明による実施の形態は、他のさまざまなブロックまたは図６Ａに列挙したブロックを変形したものを実行することにもよく適している。

プロセス６００のステップ６１０において、データが、Ｉ２Ｃルータ（例えば、図５のＩ２Ｃルータ５７０）のＩ２Ｃポートで受信される。
このデータは、宛先アドレスを含む。
一実施の形態では、このデータは、ヘッダおよびペイロードを含むデータパケットである。
宛先アドレスは、ヘッダ内に含まれる。
Ｉ２Ｃポートを通じたデータ通信を安全に制御し、かつ、アドレススプーフィングを防止するために、宛先アドレスは、Ｉ２Ｃポートで妥当性が確認されなければならない。
一実施の形態では、宛先アドレスは１バイトである。

ステップ６２０において、Ｉ２Ｃポートの制御情報がアクセスされる。
上述したように、この制御情報は、特定の宛先アドレスに向けられたデータを特定のＩ２Ｃポートを通じて送信することが許可されているかどうかを指定するものである。
一実施の形態では、この制御情報は、１つのＩ２Ｃアドレスを含む。
別の実施の形態では、この制御情報は、ある範囲のＩ２Ｃアドレスを含む。

一実施の形態において、制御情報は、マスクレジスタ（例えば、図５のマスク５３１）内に記憶される。
一実施の形態において、このマスクレジスタは、コントローラ（例えば制御ロジック５１６）のランダムアクセスメモリ（例えばＲＡＭ）内に記憶される。
マスクレジスタが設定されると、１つのＩ２Ｃポートを通じた通信またはある範囲のＩ２Ｃポートを通じた通信が可能になる。
一実施の形態では、Ｉ２Ｃポートのマスクレジスタは、単一のＩ２Ｃアドレスに設定される。
別の実施の形態では、Ｉ２Ｃポートのマスクレジスタは、ある範囲のＩ２Ｃアドレスに設定される。

マスクレジスタは、任意の個数のＩ２Ｃアドレスを記憶する任意のバイト数を含むことが可能であることが理解されるべきである。
一実施の形態では、高速ポート５１０のマスク５３０が設定されることにより、アドレス２０ｈ（１６進数表記）への通信が可能になる。
Ｉ２Ｃルータ５７０の他のＩ２Ｃポートのマスクレジスタは、最初、単一のＩ２Ｃアドレスに設定することができる。
マスクレジスタは、複数のＩ２Ｃアドレスを記憶する個別の設定を占めるように管理することができる。

一実施の形態では、マスクレジスタは、単一のＩ２Ｃアドレスを記憶する１バイトである。
別の実施の形態では、マスクレジスタは、ある範囲のＩ２Ｃアドレスを記憶する２バイトである。
図７Ａは、本発明の実施の形態による２バイトのマスクレジスタの例示のマスクレジスタ設定７００および７１０を示している。

図７Ａに示すようなマスクレジスタは、ドントケアレジスタおよびアドレスレジスタの２つのレジスタを備える。
アドレスレジスタは、Ｉ２Ｃアドレスを示すためのものである。
ドントケアレジスタは、アドレスレジスタのビットが、許可された宛先アドレスを示すために使用されることを示すためのものである。
ドントケアレジスタにおけるそれぞれの「１」は、使用されるビットを示し、ドントケアレジスタにおけるそれぞれの「０」は、使用されないビットを示す。
ドントケアレジスタおよびアドレスレジスタは、単一のＩ２Ｃアドレスまたはある範囲のＩ２Ｃアドレスを提供するように機能できる。

マスクレジスタ設定７００は、宛先アドレス２０ｈを許可する例示のマスク設定を示している。
図示するように、ドントケアレジスタは、１１１１ １１１０（２進数表記）に設定され、アドレスレジスタは、００１０ ００００ｂに設定されている。
ドントケアレジスタのビットは、最後のビットを除いてすべて１に設定されている。
アドレスレジスタのすべてのビットは、許可された宛先アドレスを決定するために使用される。
したがって、許可されたアドレスは、００１０ ０００ｘｂ（２０ｈおよび２１ｈ）のみである。
アドレス空間の最初の７ビットのみが使用されることが理解されるべきである。
このバイトの最後のビットは、アクセスが読み出しであるのか書き込みであるのかを決定するものである。

マスクレジスタ設定７１０は、宛先アドレス２０ｈ〜２７ｈを許可する例示のマスク設定を示している。
図示するように、ドントケアレジスタは、１１１１ １０００ｂ（Ｆ８ｈ）に設定され、アドレスレジスタは、００１０ ００００ｂに設定されている。
ドントケアレジスタにおける最後の３ビットが、０に設定されているので、許可された宛先アドレスは、００１０ ０ｘｘｘｂとなり得る。
ここで、ｘは、１であってもよいし、０であってもよい。
したがって、許可されたアドレスは、２０ｈ〜２７ｈの範囲のアドレスとなる。
マスクレジスタ設定７００と同様に、アドレス空間の最初の７ビットのみが使用される。
このバイトの最後のビットは、アクセスが読み出しであるのか書き込みであるのかを決定するものである。

図６Ａを参照して、ステップ６３０において、宛先アドレスは、制御情報と比較される。
制御情報は、宛先アドレスが、Ｉ２Ｃポートを通じた送信を許可されているかどうかを示すものである。

次に図６Ｂを参照する。
図６Ｂには、本発明の一実施の形態による、宛先アドレスを制御情報と比較するプロセス６３０のフロー図を示す。
本発明による一実施の形態において、プロセス６３０は、集積回路間ポート（例えば、図５のＩ２Ｃポート５５０）で実行される。
プロセス６３０には、具体的なブロックが開示されるが、このようなブロックは例示である。
すなわち、本発明による実施の形態は、他のさまざまなブロックまたは図６Ｂに列挙したブロックを変形したものを実行することにもよく適している。

プロセス６３０のステップ６３２において、宛先アドレスとアドレスレジスタとの論理排他的ＯＲ（ＸＯＲ）演算が実行される。
宛先アドレスおよびアドレスレジスタの各ビットが比較される。
これらのビットが一致しない場合には、「１」が返される。
あるいは、これらのビットが一致する場合には、「０」が返される。

ステップ６３４において、ＸＯＲ演算の結果とドントケアレジスタとの論理ＡＮＤ演算が実行される。
ＸＯＲ演算の結果およびドントケアレジスタの各ビットが比較される。
これらのビットのいずれかが「０」である場合には、「０」が返される。
あるいは、これらのビットのいずれもが「０」でない場合には、「１」が返される。

ステップ６３６において、論理ＡＮＤ演算が、０の値（例えば、００ｈまたは００００ ００００ｂ）を返すかどうかが判断される。
０の値は、宛先アドレスが、マスクレジスタに記憶された制御情報と一致することを示す。
一致することは、宛先アドレスが、Ｉ２Ｃポートを通じたデータの送信を許可されることを示す。

図７Ｂは、本発明の実施の形態による制御情報と宛先アドレスとの例示の比較７２０および７３０を示している。
比較７２０および７３０は共に、図７Ａのマスクレジスタ設定７１０に示すのと同様のマスクレジスタ設定に基づいており、この場合、許可されるアドレスは、２０ｈ〜２７ｈの範囲のアドレスである。

比較７２０は、宛先アドレスが２４ｈである場合の例示の比較を示している。
図６Ｂのステップ６３２に示すように、宛先アドレス（２４ｈ）およびアドレスレジスタ（２０ｈ）に対して、論理ＸＯＲ演算が実行され、０４ｈの結果が返される。
次いで、図６Ｂのステップ６３４に示すように、ＸＯＲ演算の結果（０４ｈ）およびドントケアレジスタ（Ｆ８ｈ）に対して、論理ＡＮＤ演算が実行される。
論理ＡＮＤ演算の結果は、００ｈになり、Ｉ２Ｃポートを通じた送信を許可する宛先アドレスを示す。

比較７３０は、宛先アドレスが２８ｈである場合の例示の比較を示している。
宛先アドレス（２８ｈ）およびアドレスレジスタ（２０ｈ）に対して実行される論理ＸＯＲ演算は、０８ｈの結果を返す。
ＸＯＲ演算の結果（０８ｈ）およびドントケアレジスタ（Ｆ８ｈ）に対して実行される論理ＡＮＤ演算は、０８ｈの結果を返す。
論理ＡＮＤ演算の結果が、００ｈでない値になるので、この宛先アドレスは、Ｉ２Ｃポートを通じた送信を許可されない。

図６Ｂを参照して、論理ＡＮＤ演算が、０の値を返す場合には、ステップ６３８に示すように、Ｉ２Ｃポートを通じた送信が許可される。
次いで、プロセス６３０は、図６Ａのプロセス６００のステップ６４０に進む。
あるいは、論理ＡＮＤ演算が、０以外の値を返す場合には、ステップ６３９に示すように、Ｉ２Ｃポートを通じた送信は許可されない。
次いで、プロセス６３０は、図６Ａのプロセス６００のステップ６４０に進む。

図６Ａのステップ６４０において、Ｉ２Ｃポートを通じた送信が許可されるかどうかが判断される。
一実施の形態において、この判断は、図６Ｂのプロセス６３０で説明したように、宛先アドレスと制御情報との比較の結果に基づく。
宛先アドレスを制御情報と比較するには、任意の比較を使用することができ、本発明は、図６Ｂのプロセス６３０で説明した実施の形態に限定されないことが理解されるべきである。
例えば、マスクレジスタが、１つのアドレスを記憶する１バイトである場合、マスクレジスタおよび宛先アドレスに対してＸＯＲ演算を実行することができ、この場合、００ｈの結果は、許可された宛先アドレスを示す。

Ｉ２Ｃポートを通じた送信が許可される場合、ステップ６５０に示すように、データは、Ｉ２Ｃポートを通じて送信される。
次いで、プロセス６００は、ステップ６７０に進む。
あるいは、Ｉ２Ｃポートを通じた送信が許可されない場合、ステップ６６０に示すように、データは、Ｉ２Ｃポートによって無視される。

ステップ６７０において、宛先アドレスがＩ２Ｃポートに対応するものであることが、Ｉ２ＣルータのＰＩＴレジスタに示される。
一実施の形態では、ＰＩＴレジスタのＩ２Ｃポートに対応するビットに、「１」が示される。

したがって、本発明の実施の形態は、Ｉ２Ｃルータにおけるデータ通信を安全に制御するプロセスを提供する。
Ｉ２Ｃポートのマスクレジスタを使用することにより、バスにわたって通信される情報にアクセスする意図的でないエンティティおよび／または認可されていないエンティティを防ぐことが可能である。
各ポートには、アドレスが割り当てられ、特定のアドレスに向けられた情報のみを、ポートを通じて送信することができる。
さらに、バスをスプーフィングするデバイスは、マスクレジスタにより、認可されていないデータを故意に受信することはできない。

［Ｉ２Ｃルータを通じたデータ送信方法］
図５を再び全体的に参照して、本発明の実施の形態は、バッファオーバーフローを回避するＩ２Ｃルータ５７０を通じたデータの新規な送信方法を提供する。
本発明の一実施の形態において、Ｉ２Ｃルータ５７０は、第１のＩ２Ｃ送信元ポートバッファ５２２と、高速内部バス５７５を介して第１のＩ２Ｃ送信元バッファ５２２に接続されたＩ２Ｃ宛先ポート５５０と、同様に高速内部バス５７５を介してＩ２Ｃ宛先ポート５５０に接続された第２のＩ２Ｃ送信元ポートバッファ（図示しないが、バッファ５２１および５２２と同様である）とを備える。
ルータ５７０の各バッファは、ルータ５７０のポートに関連付けられている（例えば、第１のＩ２Ｃ送信元バッファ５２２は、Ｉ２Ｃポート５６０に関連付けられている）。
ルータのポートは、内部バス（例えば、高速バス５７５）を通じて互いに通信する。

一実施の形態において、第１のＩ２Ｃポート５６０からＩ２Ｃ宛先ポート５５０に送信される予定のデータは、第１のＩ２Ｃポートバッファ５２２に受信される。
第１のＩ２Ｃ送信元ポートバッファ５２２にデータを受信すると、ルータ５７０は、第１のＩ２Ｃ送信元ポートバッファ５２２がオーバーフローする前に、Ｉ２Ｃ宛先ポート５５０を捕捉するように動作できる。
ルータは、宛先ポート５５０を捕捉すると、他の送信元ポートバッファ（図示せず）から宛先ポート５５０への送信を制限すると同時に、第１のＩ２Ｃ送信元ポートバッファ５２２からＩ２Ｃ宛先ポート５５０にデータを送信するように動作できる。
したがって、本発明によると、ルータ５７０は、ポート間でデータを送信するルータ／ハブとして動作できる。
同様に、ルータ５７０は、ポート間で安全な送信を行うマルチバスハブ（multi bus hub）として動作できる。

本発明のこの実施の形態をより詳細に説明するために、次に、図８Ａおよび図８Ｂのフローチャート８００ならびに図９のフローチャート９００と共に図５を参照する。
本発明のこの実施の形態の具体的なステップが、フローチャート８００、９００に開示されるが、このようなステップは例示である。
すなわち、本発明の実施の形態は、他のさまざまなステップまたはフローチャート８００、９００に列挙したステップと均等なステップによっても実行することができる。
また、フローチャート８００、９００のステップは、提示したものとは異なる順序で実行することができ、フローチャート８００、９００のステップのすべてが実行され得るとは限らない。
フローチャート８００、９００により説明される方法のすべてまたは一部は、コンピュータ可読で、かつ、コンピュータ実行可能な命令を使用して実施することができる。
これらの命令は、例えば、コンピュータシステムまたは同様のデバイスのコンピュータ使用可能媒体に存在する。
一実施の形態において、フローチャート８００、９００のステップは、図５の例示のルータ５７０によって実施することができる。

次に、図８Ａおよび図８Ｂを参照する。
図８Ａおよび図８Ｂには、本発明の一実施の形態による、集積回路間（Ｉ２Ｃ）ルータ（例えば、図５のルータ５７０）を通じたデータ送信方法のフロー図８００を示す。
この方法は、ステップ８０１から開始する。
この開始は、送信元ポート（例えば、送信元ポート５６０）が、Ｉ２Ｃデータパケットの開始を表す新たなデータを受信したことを、ルータ５７０が気付いた時に行われる。
この新たなデータは、送信元ポート５６０に接続された送信デバイス（図示せず）からＳＤＡ５６２およびＳＬＣ５７２を通じて受信されるものであり、宛先ポート（例えば、ルータ５７０の宛先ポート５５０）に送信するためのものである。

ステップ８０２において、データパケットが、送信元ポート５６０に受信されて読み出される。
ステップ８０３において、データは、チェックされ、そのパケットが、ポート５６０以外の別のポートに転送されるべきかどうかが判断される。
Ｉ２Ｃ送信では、データパケットの最初のバイトが、そのパケットの宛先アドレスを含む。
データパケットが別のポートに転送されるべきかどうかをチェックする際に、ルータ５７０は、このバイトを検査し、受信する宛先ポートがもしあれば、どの宛先ポートがそのパケットを受信すべきかを決定する。

ステップ８０４において、パケットが別のポートに転送されるべきものでない場合、パケットは無視され、この方法は、ステップ８０５で終了する。
ステップ８０４において、パケットが別のポート（例えば、ポート５５０）に転送されるべきものであると、ルータ５７０が判断した場合、ステップ８０６において、データは、ルータ５７０によって、宛先ポート５５０への転送についての妥当性が確認される。
この確認は、ルータのマスク５３２のデータを宛先ポート５５０のアドレスと比較することにより行われる。

ステップ８０７において、データが、マスク５３２によって妥当でないと確認された場合、データは、ステップ８０８で無視される。
一方、ステップ８０７において、データが、宛先ポート５５０に転送されることについて妥当であると確認されると、ステップ８０９において、ルータ５７０は、宛先ポート５５０が、送信元ポート５６０から入来するデータの受信準備ができたことの確認を受信するまで、送信元ポート５６０のバッファ５２２にデータをキューイングする。

入来するデータが、バッファ５２２にキューイングされている間、ルータ５７０は、ステップ８１０において、ポート５５０に取り付けられた制御ライン（図示せず）を使用して、宛先ポート５５０用に指定された必要なレジスタ（図示せず）を監視することにより、宛先ポート５５０を制御する。

ステップ８１１において、宛先ポート５５０Ｉ２Ｃが現在利用可能であると判断されると、ルータ５７０は、送信元ポートバッファ５２２から宛先ポート５５０に高速内部バス５７５を介してデータを送信する。
この送信において、ステップ８１８、８１９、および８２０で、バッファ５２２の残りのデータと共にこのデータを、高速バス５７５を介して宛先ポート５５０にストリーミングすることができる。

一方、ステップ８１１において、宛先ポート５５０が、現在ビジーであると判断されると、データは、送信元ポート５６０で受信されるに伴い、送信元ポートバッファ５２２に続けて記憶される。
図８Ｂのステップ８１２において、ルータ５７０は、ポーリングすることによって、送信元ポートバッファ５２２をチェックし、送信元ポートバッファ５２２のあらかじめ定められた点（例えば中間点）に到達したかどうかを判断する。
あるいは、送信元ポートバッファは、そのあらかじめ定められた点に到達すると、ルータへの割り込みを起動する。
ステップ８１３において、ルータ５７０は、宛先ポートが利用可能かどうかを調べるために、宛先ポート５５０のレジスタをポーリングし、宛先ポート５５０の制御を得るための交渉も行う。
送信元ポートバッファ５２２の容量が、まだ、あらかじめ定められた点未満である限り、ルータ５７０は、データを送信元バッファ５２２に続けてキューイングし、宛先ポート５５０の制御を得るための交渉を続けて行う。

ステップ８１４において、データが送信元ポートバッファ５２２に受信された後、長い間、宛先ポート５５０がビジーの状態であり、送信元ポートバッファ５２２の容量が、あらかじめ定められた点（例えば中間点）に達すると、ルータ５７０は、バッファ５２２がオーバーフローする前に、以下の２つの動作の一方を行い、宛先ポート５５０を捕捉する。

ａ）ステップ８１６において、ルータ５７０は、宛先ポート５５０との通信を現在試みている他のポートをビジーにし、そして、送信元ポートバッファ５２２のデータが宛先ポート５５０へ送信完了するまで、第１のポートバッファ５２２からデータを送信する。
これは、ルータ５７０が、宛先ポート５５０のＳＤＡラインおよびＳＣＬライン以外のすべてのＳＤＡラインおよびＳＣＬラインを論理的なローレベルにアサートすることにより達成される。

ｂ）あるいは、ステップ８１７において、ルータ５７０は、高速内部バス５７５上で送信側ポートに、０からなるバイトを送信することにより、宛先ポート５５０に割り込む。
Ｉ２Ｃプロトコルのもとでは、送信側ポートが、自身のポートで０からなるバイトのデータを受信している認識すると、その最初の送信を停止し、その送信の再送を試みる。
本発明によると、送信元ポート５６０以外のポートにおける最初のデータの停止時と再送時との間で、ルータ５７０は、宛先ポート５５０に割り込み、宛先ポート５５０の交渉を勝ち取る。
ルータ５７０が、宛先ポート５５０の捕捉動作を開始した時に、宛先ポート５５０がビジーでない場合、ルータ５７０は、宛先ポート５５０の制御を取得し、宛先ポート５５０へのデータの送出を（例えば、送信元ポートバッファ５２２が満たされていくのと同じ速度で）開始することに留意すべきである。

ルータ５７０は、ステップ８１６、８１７で宛先ポート５５０を捕捉するまで、または、送信元ポートバッファ５２２がその容量をオーバーフローするまで、これらの２つの動作のいずれかを続ける。
ルータ５７０は、宛先ポート５５０を捕捉すると、送信元ポート５６０における宛先ポート５５０向けのデータが送信されるまで、ステップ８１８、８１９、および８２０において、送信元ポート５６０から宛先ポート５５０にデータを送信する。
ルータ５７０が、宛先ポート５５０を捕捉できず、送信元ポートバッファ５２２がオーバーフローすると、この方法は、ステップ８１５において、送信元ポート５６０でデータが損失するという結果で終了する。

本発明のこの実施の形態において、送信元ポートバッファ５２２がオーバーフローする可能性は、送信元バッファ５２２がパケット長の２倍のサイズの容量を有するように設計すること、送信元ポートバッファ５２２がその容量のあらかじめ定められた点（例えば中間点）に達した場合に、送信元ポートバッファ５２２がステップ８１４でオーバーフローする前に宛先ポート５５０の捕捉を開始することとによって低減される。
したがって、例えば、パケット長が３２バイトであり、送信元ポートバッファ５２２の容量が６４バイトである場合に、宛先ポート５５０の捕捉動作は、送信元ポートバッファ５２２が３２バイトになった時に開始する。
これらの状況下で、送信元ポートバッファ５２２は、オーバーフローしないはずである。
本発明のこの実施の形態では、パケット長とバッファ容量との他の設計比も使用できることに留意すべきである。

次に図９を参照する。
図９には、本発明の一実施の形態による、集積回路間（Ｉ２Ｃ）ルータを通じた代替的なデータ送信方法のフロー図を示す。
このＩ２Ｃルータ９００を通じたデータ送信方法は、ステップ９０１において、ルータ５７０の第１の送信元ポートバッファ５２２のデータを受信することを含む。
ステップ９０２において、ルータ５７０は、第１の送信元ポートバッファ５２２がオーバーフローする前に、宛先ポート５５０を捕捉するように動作できる。
ステップ９０３において、ルータ５７０は、他の送信元ポートバッファ（図示せず）から宛先ポート５５０への送信を制限すると同時に、第１の送信元ポートバッファ５２２から宛先ポート５５０にデータを送信するように動作できる。

説明を簡略化するために、上記実施の形態は、第１のＩ２Ｃポートと第２のＩ２Ｃポートとの間での通信の観点から本発明を説明したものである。
しかしながら、データをバッファリングする方法は、Ｉ２Ｃポートと外部高速ポートとの間の通信、および、Ｉ２Ｃポートと複数のＩ２Ｃポートとの間の通信も含むことが可能であることが理解されよう。

［Ｉ２ＣルータにおけるＩ２Ｃパケットのオーバーフロー回復方法］
図５を全体的に再び参照して、本発明の実施の形態は、例えばバッファ５２２などの送信元ポートバッファがオーバーフローした場合の、Ｉ２Ｃルータ５７０を通じた新規なデータ送信方法も提供する。
本発明のこの実施の形態において、ルータ５７０は、第１のＩ２Ｃ送信元バッファ５２２と、高速内部バス５７５を介して第１のＩ２Ｃ送信元バッファ５２２に接続されたＩ２Ｃ宛先ポート５５０と、同様に高速内部バス５７５を介してＩ２Ｃ宛先ポート５５０に接続された第２のＩ２Ｃ送信元ポートバッファ（図示しないが、バッファ５２１および５２２と同様である）とを備える。
例えば、バッファ５２１、５２２などのルータ５７０の各バッファは、例えば、ルータ５７０のポート５５０、５６０などのポートに関連付けられている。
例えば、第１のＩ２Ｃ送信元バッファ５２２は、Ｉ２Ｃポート５６０に関連付けられている。
ルータのポートは、例えば高速バス５７５などの内部バスを通じて互いに通信する。

送信元ポートのデータがオーバーフローした一実施の形態において、例えば第１のＩ２Ｃ送信元ポートバッファ５２２などのバッファがオーバーフローすると、ルータ５７０は、第１のＩ２Ｃ送信元ポートバッファ５２２へのオーバーフローしたデータの再送を要求するように動作できる。
送信元バッファ５２２へのデータの再送を要求すると、ルータ５７０は、宛先ポート５５０への送信を現在試みている他のポート、または、宛先ポート５５０へ現在送信中の他のポートをビジーにするように動作できる。
あるいは、ルータ５７０は、Ｉ２Ｃ宛先ポート５５０に割り込むように動作できる。
いずれの場合も、Ｉ２Ｃ宛先ポートへのアクセスに成功すると、ルータは、他の送信元ポートバッファ（図示せず）から宛先ポート５５０への送信を制限すると同時に、送信元ポートバッファ５２２から宛先ポート５５０に回復データを再送するように動作できる。
したがって、本発明によると、ルータ５７０は、ポート間でデータを送信するルータ／ハブとして動作できる。
同様に、ルータ５７０は、ポート間で安全な送信を行うマルチバスハブとして動作できる。

次に、図１０Ａおよび図１０Ｂのフローチャート１０００ならびに図１１のフローチャート１１００と共に図５を参照して、本発明のこの実施の形態をより詳細に説明する。
本発明のこの実施の形態の具体的なステップが、フローチャート１０００、１１００に開示されるが、このようなステップは例示である。
すなわち、本発明の実施の形態は、他のさまざまなステップまたはフローチャート１０００、１１００に列挙したステップと均等なステップによっても実行することができる。
また、フローチャート１０００、１１００のステップは、提示したものとは異なる順序で実行することができ、フローチャート１０００、１１００のステップのすべてが実行され得るとは限らない。
フローチャート１０００、１１００により説明される方法のすべてまたは一部は、コンピュータ可読で、かつ、コンピュータ実行可能な命令を使用して実施することができる。
これらの命令は、例えば、コンピュータシステムまたは同様のデバイスのコンピュータ使用可能媒体に存在する。
一実施の形態において、フローチャート１０００、１１００のステップは、図３および図５の例示のルータ５７０によって実施することができる。

次に、図１０Ａおよび図１０Ｂを参照する。
図１０Ａおよび図１０Ｂには、本発明の一実施の形態による、集積回路間（Ｉ２Ｃ）ルータ５７０を通じたデータ送信方法のフロー図１０００を示す。
この方法は、ステップ１００１から開始する。
この開始は、送信元ポート（例えば、送信元ポート５６０）が、パケットの開始を表す新たなデータを受信したという情報を、ルータ５７０が受信した時に行われる。
この新たなデータは、送信元ポート５６０の送信デバイスからのものであり、宛先ポート（例えば、宛先ポート５５０）に送信するためのものである。

ステップ１００２において、データが読み出され、ステップ１００３において、データは、チェックされ、そのパケットが別のポートに転送されるべきかどうかが判断される。
Ｉ２Ｃ送信では、パケットの最初のバイトが、そのパケットの宛先アドレスを含む。
データが転送されるべきかどうかをチェックする際に、ルータ５７０は、このバイトを検査し、例えばポート５５０などの宛先ポートがもしあれば、どの宛先ポートがそのパケットを受信すべきかを決定する。

ステップ１００４において、パケットが転送されるべきものでない場合、パケットは無視され、この方法は、ステップ１００５で終了する。
ステップ１００４において、パケットが転送されるべきものであると、ルータ５７０が判断した場合、ステップ１００６において、データは、宛先ポート５５０への送信についての妥当性が確認される。
この確認は、ルータのマスクデータ５３２を宛先ポートアドレスと比較することにより行われる。

ステップ１００７において、データが、マスク５３２によって妥当でないと確認された場合、データは、ステップ１００８で無視される。
一方、ステップ１００７において、データが、宛先ポート５５０に転送されることについて妥当であると確認されると、ステップ１００９において、ルータ５７０は、宛先ポート５５０が、送信元ポート５６０から入来するデータの受信準備ができたことの確認を受信するまで、送信元ポート５６０のバッファ５２２にデータをキューイングする。

データが、バッファ５２２にキューイングされている間、ルータ５７０は、ステップ１０１０において、ポート５５０に取り付けられた制御ライン（図示せず）を使用して、宛先ポート５５０用に指定された必要なレジスタを監視することにより、宛先ポート５５０を制御する。

ステップ１０１１において、宛先ポート５５０が現在利用可能であると判断され、かつ、バッファ５２２がオーバーフローしていないと判断されると、ルータ５７０は、送信元ポートバッファ５２２から宛先ポート５５０にデータを送信する。
この送信において、ステップ１０１６、１０１７、および４１８で、バッファ５２２の残りのデータと共にこのデータを宛先ポート５５０にストリーミングする。

ステップ１０１１および続く図１０Ｂのステップ１０１２において、宛先ポート５５０が、現在ビジーであるが、バッファ５２２は、オーバーフローしていないと判断されると、データは、受信されるに伴い、バッファ５２２に続けて記憶され、ルータ５７０は、宛先ポート５５０の制御の交渉を続けて行う。

ステップ１０１２において、バッファ５２２がオーバーフローしていると判断されると、ルータ５７０は、ステップ１０１３で、送信元ポートＩ２Ｃバスからのデータの再送を要求し、このデータに対してステップ１００２を再開する。
ステップ１０１３において、ルータ５７０は、以下の２つの動作の一方を行い、宛先ポート５５０を捕捉する。

ａ）ステップ１０１４において、バッファ５２２の最初のデータが、宛先ポート５５０へ送信完了するまで、ルータ５７０は、宛先ポート５５０との通信を現在試みているポートをビジーにする。
これは、ルータ５７０が、宛先ポート５５０以外のすべてのＳＤＡラインおよびＳＣＬラインを論理的なローレベルにアサートすることにより達成される。

ｂ）あるいは、ステップ１０１５において、ルータ５７０は、送信側ポートに、０からなるバイトを送信することにより、宛先ポート５５０に割り込む。
Ｉ２Ｃプロトコルのもとでは、送信側ポートが、自身のポートで０からなるバイトのデータを受信していると認識すると、その最初の送信を停止し、その送信の再送を試みる。
最初のデータの停止時と再送時との間で、ルータ５７０は、宛先ポート５５０に割り込み、宛先ポート５５０の交渉を勝ち取る。
ルータ５７０が、宛先ポート５５０の捕捉動作を開始した時に、宛先ポート５５０がビジーでない場合、ルータ５７０は、宛先ポート５５０を制御し、バッファ５２２が満たされていくのと同じ速度で、データの送出を開始することに留意すべきである。

ルータ５７０は、宛先ポート５５０を捕捉するまで、これらの２つの動作のいずれかを続ける。
補足した時点で、ルータ５７０は、ステップ１０１６において、データの送信がステップ１０１７で完了するまで、送信元ポート５６０から宛先ポート５５０へデータを供給する。
データが宛先ポート５５０に供給されている時、ルータ５７０は、パケットの送信が成功に終わるまで、ＳＣＬラインおよびＳＤＡライン上のローレベルを引き伸ばすことにより、他のポートをビジーに維持する。
その後、ルータ５７０は、通常動作に戻る。

次に図１１を参照する。
図１１には、本発明の一実施の形態による、集積回路間（Ｉ２Ｃ）ルータを通じた代替的なデータ送信方法のフロー図１１００を示す。
ステップ１１０１において、オーバーフローしたデータは、第１のＩ２Ｃ送信元ポートバッファに再送される。
Ｉ２Ｃルータは、Ｉ２Ｃ宛先ポートおよび第２のＩ２Ｃ送信元ポートバッファをさらに備える。
ステップ１１０２において、オーバーフローしたデータは、第１のＩ２Ｃ送信元ポートバッファで受信される。
ステップ１１０３において、Ｉ２Ｃ宛先ポートが捕捉される。
ステップ１１０４において、第１のＩ２Ｃ送信元ポートバッファからのデータが、Ｉ２Ｃ宛先ポートに送信される。

本発明によると、ルータは、ＭＨｚの範囲の速度で機能することができ、送信元ポートから宛先ポートへの送信は、解放されたビジーでない状況下では、トランスペアレントにすることができる。
さらに、本発明によると、バッファがオーバーフローすると、宛先ポートに再送するために、データを回復させることができる。
また、本発明によると、ルータは、送信されたデータを追跡することもでき、バスを獲得するために交渉することもできるので、指定されたポートへのアクセスを制限することにより、各ポートへの安全な送信を有するマルチバスデータハブとしてルータを動作させることができる。

説明を簡略化するために、上記実施の形態は、第１のＩ２Ｃポートと第２のＩ２Ｃポートとの間での通信の観点から本発明を説明したものである。
しかしながら、Ｉ２Ｃパケットのオーバーフロー回復方法は、Ｉ２Ｃポートと外部高速ポートとの間の通信、および、Ｉ２Ｃポートと複数のＩ２Ｃポートとの間の通信も含むことが可能であることが理解されよう。

［集積回路間ルータエラー管理システムおよび方法］
図１２は、本発明の一実施の形態による集積回路間（Ｉ２Ｃ）ルータエラー管理システム１２００のブロック図である。
このＩ２Ｃルータエラー管理システム１２００は、内部バス１２１５、高速ポート１２２０、デバッグコネクタ１２３０、ならびにＩ２Ｃポート１２５０および１２７０を備える。
内部バス１２１５は、（例えば、本発明の他の内部バス２８１、３７５、１８１０などと同様に）高速ポート１２２０、デバッグコネクタ１２３０、ならびにＩ２Ｃポート１２５０および１２７０を通信接続する。
高速外部ポート１２２０は、（例えば、高速外部ポート２１０、３１０、１８１５などと同様に）内部バス１２１５および高速外部バス１２２１からの高速インターフェースを提供する。
デバッグコネクタ１２３０は、Ｉ２Ｃルータシステム１２００のコンポーネントから外部デバッグメカニズムへのインターフェースを提供する。
Ｉ２Ｃポート１２５０は、外部Ｉ２Ｃバス１２１３間のインターフェースを提供し、Ｉ２Ｃポート１２７０は、外部Ｉ２Ｃバス１２１７間のインターフェースを提供する。

Ｉ２Ｃポート１２５０および１２７０は、本明細書で説明した他のＩ２Ｃポート（例えば、２５３ａ、５５０、１６２５など）と同様のものであり、また、エラー管理機能も含む。
例えば、Ｉ２Ｃポート１２５０は、制御ロジック１２５１、マスク１２５２、バッファ１２５５、パラレル／シリアルバスインターフェース１２９０、エラーレジスタ１２５３、およびシステムイベントログ１２５７を備える。
制御ロジック１２５１は、（例えば、制御ロジック２５７ａ、５１７、１６４０などと同様に）Ｉ２Ｃポート１２５０を通じた情報フローを制御する。
マスク１２５２は、（例えば、方法６００ならびに／または図７Ａおよび図７Ｂに示す設定などに従って）制御ロジック１２５１に制御情報を提供する。
バッファ１２５５は、Ｉ２Ｃポート１２５０を介して通信される情報をバッファリングする。
例示の一実施態様において、バッファ１２５５は、方法８００、９００、１０００、または１１００に従って情報をバッファリングすることができる。
パラレル／シリアルバスインターフェース１２９０は、Ｉ２Ｃポート１２５０の内部パラレル通信と外部シリアルＩ２Ｃバス通信との間のインターフェースを提供する。
エラーレジスタ１２５３は、（例えば、Ｉ２Ｃポート１２５０を通じた情報のデータフローに関連付けられ、制御ロジック１２５１によって制御される）エラー表示を追跡する（例えば記憶する）。
イベントシステムログ１２５７は、エラー情報および統計値を、整理および相関された形式でログ記録する。

Ｉ２Ｃポート１２５０および１２７０は、それぞれバス１２１３および１２１７上のＩ２Ｃ信号の内部バス１２１５への通信、および、その逆方向の通信を行うインターフェースを提供する。
本発明のＩ２Ｃバス１２１３は、ＳＤＡライン１２０１、ＳＣＬライン１２０２、存在検出ライン１２０３、およびリセットライン１２０４を含む。
本発明のＩ２Ｃバス１２１７は、ＳＤＡライン１２０７、ＳＣＬライン１２０８、存在検出ライン１２０９、およびリセットライン１２１０を含む。
存在検出ライン１２０３および１２０９は、（例えば、ライン１６６０および１６６５と同様に）バス１２１３および１２１７にそれぞれ通信接続されたコンポーネントの存在を示す。
リセットライン１２０４および１２１０は、バス１２１３および１２１７にそれぞれ通信接続されたコンポーネントにリセット表示を通信するために利用される。

図１２を続けて参照して、エラーレジスタ１２５３は、さまざまな異なる方法で通信オペレーション中のエラー情報を捕捉することができる。
エラーレジスタ１２５３は、フラグ１５３Ａおよび１５３Ｂを利用して、エラー表示を捕捉することができる（例えば、エラーレジスタ１２５３に含まれる特定のビットが、あらかじめ定められた論理値に設定され、ある種類のエラーの存在を示す）。
エラーレジスタ１２５３は、Ｉ２Ｃポートに障害が発生したときに設定される障害ポートレジスタまたは障害ポートフラグを含むことができる。
また、このレジスタは、回復のために障害ポートの制御を取り戻してそのポートを監視するプロセスを実行する２次状態機械を起動することもできる。
この２次状態機械は、Ｉ２Ｃルータシステム１２００に含めることもできる（例えば、シリアルバスインターフェース１２９０に並列に含めることができる）し、Ｉ２Ｃルータシステム１２００から独立させることもできる。
Ｉ２Ｃルータシステム１２００におけるエラーのない残りのポートは、障害ポートからの影響も２次状態機械からの影響も受けることなく、データを継続して適切に通過させる。
エラーのないＩ２Ｃルータシステム１２００のポートが、「分離された」障害ポートとの通信を試みると、送信側ポートは、その通信の少なくとも一部が完了しないことを信号で伝えられる。
例示の一実施態様において、エラーレジスタ１２５３は、エラーカウントを保持する。
例えば、エラーレジスタ１２５３は、エラーレジスタフラグに関連付けられたエラーイベントが検出されるごとに、そのエラーレジスタフラグに含まれる値をインクリメントすることによって、エラーカウントを追跡することができる。

エラーレジスタ１２５３は、多数の異なるエラー表示の捕捉およびそれらのエラーからの回復を対象にしたさまざまなエラー管理ポリシーを有する実施態様に柔軟に適合することができる。
一実施の形態において、エラーレジスタ１２５３は、障害ポートの状態の表示を捕捉することができ、エラーからの回復に関与することができる。
例えば、障害ポートの状態は、ＳＣＬライン１２０２およびＳＤＡライン１２０１の制御権を得るために、パラレル／シリアルバスインターフェース１２９０が自身のポートのリセットを試みた回数の表示によって認識することができる。
あるいは、障害ポートの状態は、Ｉ２Ｃルータシステム１２００が、障害の疑いのあるＩ２Ｃポートの制御権の取得を試みて失敗した回数の表示によって認識することができる。
また、エラーレジスタ１２５３を利用して、バッファ問題（例えばバッファオーバーフロー）の捕捉およびバッファ問題からの回復を行うこともできる。
例えば、エラーレジスタを利用して、バッファ１２５５のバッファリング能力を超える長い送信パケットを検出することができる。
本発明のエラー管理ポリシーは、特定のＩ２Ｃポートによる有害なバス独占の可能性を最小にすることも対象にすることができる。

Ｉ２Ｃルータシステム１２００は、エラー回復メカニズムおよび機能も含み、エラー状態からの回復を容易にする。
一実施の形態において、Ｉ２Ｃポートが「破損した（lost）」とみなされる（例えば、１つまたは複数の致命的なエラーがＩ２Ｃポートに発生した）場合、Ｉ２Ｃルータシステムは、データが、破損したＩ２Ｃポートへまたは当該Ｉ２Ｃポートから通過するのを防止することができる。
障害のあるＩ２Ｃポートは、Ｉ２Ｃルータシステム１２００のデータ転送部（例えば、内部バス１２１５）から分離される。
例示の一実施態様において、Ｉ２Ｃルータシステム１２００は、Ｉ２Ｃルータが適切に機能していない（例えば、「破損」した）ことを示すために起動される障害ライトを含む。

図１２をさらに参照して、パラレル／シリアルバスインターフェース１２９０を利用して、エラー表示をエラーレジスタ１２５３に提供することができる。
例示の一実施態様においては、タイムアウトレジスタ１２９１を利用して、エラー表示を提供することができる。
タイムアウトレジスタ１２９１には、最大タイムアウト値が設定される。
この最大タイムアウト値は、リセットが（例えば、リセットライン１２０４を介して）開始される前において、ＳＣＬライン（例えばＳＣＬ１２０２）がローレベルに保持される最大時間である。
交渉が長引いた場合、ストップビットが欠如した場合、および／またはバスがハングした場合を含めて、さまざまな理由から、ＳＣＬをローレベルに保持することができる。
このタイムアウト機能は、ＳＣＬがローレベルになった時に開始し、ＳＣＬラインがハイレベルになった時にリセットされる。
ＳＣＬラインが、タイムアウト値以上の時間の間、ローレベルにあると、Ｉ２Ｃルータシステム１２００は、バスエラーが発生したものと結論する。
パラレル／シリアルバスインターフェース１２９０は、ＳＣＬラインがローレベルに固定されていることの表示またはステータスコードをステータスレジスタ１２９３にロードし、ＳＣＬライン１２０２およびＳＤＡライン１２０１の解放を試みる割り込み信号を生成する。
制御ロジック１２５１は、ステータスレジスタ１２９３をポーリングし、割り込み信号ラインを監視することにより、エラーイベントの発生を判断することができる。
制御ロジック１２５２は、Ｉ２Ｃバスエラーカウンタの値を１つずつインクリメントし、かつ、障害ポートと障害のないポートとを区別するためのポートエラーＬＥＤを設定することにより、応答することができる。

パラレル／シリアルバスインターフェース１２９０の他の機能を利用して、他のＩ２Ｃ「ヘルス」インジケータまたはエラーカウンタを実施することができる。
例示の一実施態様において、ストップビットの欠落が発生すると、パラレル／シリアルバスインターフェース１２９０は、シリアル転送中のバスエラーの発生を示すステータスコードをロードすることができる。
バスエラーは、フォーマットフレームの誤った（「違反した」）位置でスタート状態またはストップ状態が発生することにより引きこされることがある。
あるいは、ある外部インターフェースが、パラレル／シリアルバスインターフェースと干渉する。
例えば、あるデータビットまたは肯定応答ビットが、アドレスバイトにおいて送信される。
エラーが発生すると、（例えば、シリアル割り込みフラグの設定を含めて）割り込みが設定される。
ストップビットの欠落エラーが発生すると、制御ロジック１２５１は、ステータスレジスタ１２９３を再びポーリングして、ストップビット欠落エラーカウントを１つだけインクリメントすることができる。

図１３は、本発明の一実施の形態による相互接続ルータエラー管理方法である、相互集積接続（inter-integrated connected）（Ｉ２Ｃ）ルータエラー管理方法１３００のフローチャートである。
Ｉ２Ｃルータエラー管理方法１３００は、エラー問題を追跡し、表形式にし、かつ、エラー問題からの回復を行う。
相互集積接続（Ｉ２Ｃ）ルータエラー管理方法は、Ｉ２Ｃルータシステムのロバスト性および信頼性を向上させる。

ステップ１３１０において、Ｉ２Ｃルータの通信活動が監視される。
例えば、ポートの通信トラフィックフロー特性が検査される。
Ｉ２Ｃポートが内部バスを捕捉している時間量を検査することもできるし、Ｉ２Ｃポートが１つのパケットで通信する情報量を検査することもできる。
例示の一実施態様では、バッファ（例えばバッファ１２５５）のオーバーフローが監視される。

通信活動に関連したエラーが、ステップ１３２０で捕捉される。
一実施の形態では、ステップ１３１０で特定されたエラーが追跡される。
例えば、特定の種類のエラーの発生カウントが保持される。
例示の一実施態様では、エラー表示が、整理および相関された形式でログ記録される。
デバッグ分析を拡大して行うために、エラー表示をデバッグシステムへ通信することができる。

ステップ１３３０において、エラーからの回復動作が実行される。
本発明の一実施の形態において、この回復動作は、エラーに関連したＩ２Ｃ通信活動を一時停止することを含む。
例えば、バッファを使用して大きなパケットをその宛先ポートに直接送信することが可能になるまで、影響を受けるポートを介した長い送信パケットの通信が一時停止される。
例示の一実施態様では、長いパケットの送信元ポートが、内部Ｉ２Ｃルータバスを捕捉できるまで、通信は一時停止される。
あるいは、大きなパケットは、送信元ポートを介して通信することが許可されず、大きなパケットの通信を試みる送信元ポートは、無効にされる。
送信元ポートを無効にすることは、他のポートが内部バス（例えば１２１５）にアクセスして、それらのポートを効果的に停止させることを、暴走プロセスおよび／またはサービス拒否攻撃が妨げるのを防止することにも利用できる。
本発明の一実施の形態において、エラー回復動作は、リセットを起動すること（例えば、Ｉ２Ｃポートに接続されたデバイスをリセットすること）を含む。
また、本発明は、複数のＩ２Ｃポートをリセットして、全Ｉ２Ｃ通信ネットワークエラー監視／回復システムの実施を容易にすることにも柔軟に適合することができる。

［個別の送信速度をサポートする集積回路間ルータ］
次に図１４を参照する。
図１４には、本発明の一実施の形態による、個別の送信速度をサポートする集積回路間（Ｉ２Ｃ）ルータのデータフロー図を示す。
本実施の形態の説明を分かりやすくするために、Ｉ２Ｃルータ１４００を使用して、個別の送信速度を有する接続デバイスをサポートできるＩ２Ｃルータを示す。
しかしながら、図５のＩ２Ｃルータ５７０で説明したものなど、本発明の他の実施の形態も、個別の送信速度を接続デバイスに提供するように動作でき、個別の送信速度のサポートは、図１４で説明する実施の形態だけに限定されるものでないことが理解されるべきである。

Ｉ２Ｃルータ１４００は、第１の送信速度１４１０でデータを送信するように動作できる内部バス１４０２を備える。
一実施の形態において、内部バス１４０２は高速バスである。
一実施の形態において、第１の送信速度１４１０は、ほぼ１．４メガヘルツ（ＭＨｚ）である。
内部バス１４０２は、電気的に分離された外部バスへの接続用に構成されたポートを備える。
電気的に分離されたバス（例えば、外部Ｉ２Ｃバス１４２４および外部バス１４３４）は、電気的に分離されたポートが接続される他のバスとは、当該ポートを通じて独立に動作することができる。

Ｉ２Ｃルータ１４００は、内部バス１４０２に接続されたＩ２Ｃポート１４２０を備える。
Ｉ２Ｃポート１４２０は、バッファ１４２２を備え、外部Ｉ２Ｃバス１４２４に接続される。
外部Ｉ２Ｃバス１４２４は、内部バス１４０２から電気的に分離されている。
外部Ｉ２Ｃバス１４２４は、第２の送信速度１４２６でデータを送信するように動作できる。
一実施の形態では、第２の送信速度１４２６は、ほぼ１００キロヘルツ（ｋＨｚ）である。
別の実施の形態では、第２の送信速度１４２６は、ほぼ４００ｋＨｚである。
外部Ｉ２Ｃバス１４２４は、外部デバイスまたは外部コンポーネント（例えば、図２のＦＲＵ２２０、２２１、および２２２）への接続用に構成される。

第１の送信速度１４１０が、第２の送信速度１４２６と異なる場合、バッファ１４２２は、内部バス１４１０と外部Ｉ２Ｃバス１４２４との間で送信されるデータをバッファリングするように動作できる。
バッファ１４２２は、データが内部バス１４１０と外部Ｉ２Ｃバス１４２４との間で送信される時にそのデータを一時的に記憶するデータキャッシュを備える。
一実施の形態において、第１の送信速度１４１０が、第２の送信速度１４２４よりも大きい場合、バッファ１４２２は、第１の送信速度１４１０で内部バス１４０２からのデータを受信して、送信速度の相違により送信できないそのデータを記憶することによって、そのデータをバッファリングし、そして、第２の送信速度１４２６で外部Ｉ２Ｃバス１４２４にわたってデータを送信するように動作できる。
実質的には、バッファ１４２２は、低速リンクが、高速リンクからデータを受信できるように、データ送信速度を減速するように動作できる。
上述したように、バッファ１４２２のサイズは、さまざまなＩ２Ｃルータ１４００の実施態様に従って構成することができる。
例えば、Ｉ２Ｃルータ１４００が、ＩＰＭＩプロトコルを利用する構成で使用される場合、キャッシュは、３２バイトのパケットサイズの倍数（例えば、６４バイト、９６バイトなど）のサイズとすることができる。

一実施の形態において、第１の送信速度１４１０が、第２の送信速度１４２４よりも大きい場合、バッファ１４２２は、第２の送信速度１４２６で外部Ｉ２Ｃバス１４２４からデータをキャッシュし、そして、第１の送信速度１４１０で内部バス１４０２にわたってバーストによりデータを送信するように動作できる。
例えば、データは、外部バス１４２４からＩ２Ｃポート１４２０に受信される。
バッファ１４２２は、そのデータをキャッシュする。
十分なデータがキャッシュされると、キャッシュされたデータは、内部バス１４０２にわたってバーストにより送信される。
バッファ１４２２は、低速リンクからデータを受信し、そのデータをキャッシュし、そして、そのデータをより高速で高速リンクにポンピングすることによって、より高いスループットを効果的に達成するように動作する。
データをバーストにすることにより、高速バス１４１０は、バス１４２４とは独立に他のデータを自由にバーストにすることができる。

一実施の形態において、Ｉ２Ｃルータ１４００は、内部バス１４０２に接続されたポート１４３０を備える。
ポート１４３０は、バッファ１４３２を備え、外部バス１４３４に接続されている。
外部バス１４３４は、内部バス１４０２から電気的に分離されている。
外部バス１４３４は、第３の送信速度１４３６でデータを送信するように動作できる。
バッファ１４３２は、バッファ１４２２と同様に動作し、第１の送信速度１４１０が第３の送信速度１４３６と異なる場合に、データをバッファリングするように動作できることが理解されるべきである。

一実施の形態では、ポート１４３０は、第２のＩ２Ｃポート（例えば、図５のポート５６０）であり、外部バス１４３４は、Ｉ２Ｃバス（例えば、図５のＩ２Ｃバス５４２）である。
別の実施の形態では、ポート１４３０は、高速ポート（例えば、図５の高速ポート５１０）であり、外部バス１４３４は、外部高速バス（例えば、図５の高速外部バス５４０）である。

一実施の形態において、第１の送信速度１４１０は、第２の送信速度１４２６および第３の送信速度１４３６のうちの高速な方と少なくとも同じ速度である。
一実施の形態において、内部バス１４０２は、第１の送信速度よりも小さな送信速度でデータを送信するように動作できる。
本実施の形態では、外部Ｉ２Ｃバス１４２４からポート１４２０に受信されたデータをキャッシュする必要はなく、また、そのデータを第１の送信速度１４１０でバーストにより送信する必要はない。
ポート１４２０は、第２の送信速度で内部バス１４１０にわたってデータを送信するように動作可能であってよい。
バッファ１４３２は、第２の送信速度１４２６で内部バス１４０２からデータを受信するように動作でき、第３の送信速度１４３６でポート１４３０から外部バス１４３４へデータを送信するように動作できる。

別の実施の形態において、バッファ１４２２は、第２の送信速度１４２６で外部Ｉ２Ｃポート１４２４から受信したデータをキャッシュするように動作でき、第１の送信速度１４１０で内部バス１４０２にわたってバーストによりデータを送信するように動作できる。
バッファ１４３２は、第１の送信速度１４１０で内部バス１４０２からデータを受信するように動作でき、第３の送信速度１４３６で外部バス１４３４へデータを送信するように動作できる。
バッファ１４３２は、第３の送信速度１４３６で外部バス１４３４から受信したデータをキャッシュするように動作でき、第１の送信速度１４１０で内部バス１４０２にわたってバーストによりデータを送信するように動作できる。

次に図１５Ａ〜図１５Ｃを参照する。
これらの図には、本発明の実施の形態に従って、集積回路間（Ｉ２Ｃ）ルータのポート間でデータを通信するプロセス１５００、１５２０、および１５３０を示すフロー図を示す。
本発明による一実施の形態において、プロセス１５００、１５２０、および１５３０は、Ｉ２Ｃルータ（例えば、図１４のＩ２Ｃルータ１４００）で実行される。
プロセス１５００には、具体的なブロックが開示されるが、このようなブロックは例示である。
すなわち、本発明による実施の形態は、他のさまざまなブロックまたは図１５Ａに列挙したブロックを変形したものを実行することにもよく適している。
分かりやすくするために、図１４のＩ２Ｃルータ１４００と共に、プロセス１５００、１５２０、および１５３０を説明することにする。
しかしながら、説明する本発明の実施の形態は、他のＩ２Ｃルータ（例えば、図５のＩ２Ｃルータ５７０）においても実施できることが理解されるべきである。

プロセス１５００のステップ１５０２において、データが、バス（例えば内部バス１４０２）を介して第１の送信速度１４１０でＩ２Ｃポート１４２０に受信される。
ステップ１５０４において、第１の送信速度１４１０が、Ｉ２Ｃポート１４２０に接続された外部Ｉ２Ｃバス１４２４の第２の送信速度１４２６よりも高速である場合、データは、バッファ１４２２にバッファリングされる。
ステップ１５０６において、データは、第２の送信速度１４２６で外部Ｉ２Ｃバス１４２４にわたって送信される。

ステップ１５０８において、第２のデータが、外部Ｉ２Ｃバス１４２４を介して第２の送信速度１４２６でＩ２Ｃポート１４２０に受信される。
ステップ１５１０において、第１の送信速度１４１０が、第２の送信速度１４２６よりも高速である場合、データは、バッファ１４２２にキャッシュされる。
ステップ１５１２において、データは、第１の送信速度１４１０で内部バス１４０２にわたってバーストにより送信される。

図１５Ｂを参照して、本発明の一実施の形態に従って第２のＩ２Ｃポートに第２のデータをバッファリングするプロセス１５２０を説明する。
本実施の形態では、ポート１４３０が、第２のＩ２Ｃポートであり、外部バス１４３４が、第２の外部Ｉ２Ｃバスである。

プロセス１５２０のステップ１５２２において、第２のデータが、内部バス１４０２を介して第１の送信速度１４１０で第２のＩ２Ｃポートに受信される。
ステップ１５２４において、第１の送信速度１４１０が、第２の外部Ｉ２Ｃバスの第３の送信速度１４３６よりも高速である場合、第２のデータは、バッファ１４３２にバッファリングされる。
ステップ１５２６において、第２のデータは、第３の送信速度１４３６で第２の外部Ｉ２Ｃバスにわたって送信される。

図１５Ｃを参照して、本発明の一実施の形態に従って高速ポートに第２のデータをバッファリングするプロセス１５３０を説明する。
本実施の形態では、ポート１４３０が、高速ポートであり、外部バス１４３４が、外部高速バスである。

プロセス１５３０のステップ１５３２において、第２のデータが、内部バス１４０２を介して第１の送信速度１４１０で高速ポートに受信される。
ステップ１５３４において、第１の送信速度１４１０が、外部高速バスの第３の送信速度１４３６よりも高速である場合、第２のデータは、バッファ１４３２にバッファリングされる。
ステップ１５３６において、第２のデータは、第３の送信速度１４３６で外部高速バスにわたって送信される。

したがって、本発明のさまざまな実施の形態は、個別の送信速度をサポートするＩ２Ｃルータを提供する。
このＩ２Ｃルータは、複数のＩ２Ｃポートおよび１つの高速ポートに接続された高速内部バスを備えることができる。
バス接続されたそれぞれのＩ２Ｃポートおよび高速ポートは、電気的に分離され、異なる速度で動作することができる。
Ｉ２Ｃポートのそれぞれでデータをバッファリングすることに加えて、データをキャッシュして、高速でデータをポンピングすることにより、Ｉ２Ｃルータで単一の高速バスを使用して、より大きなスループットを提供することができる。
さらに、１つの高速ポートおよび複数のＩ２Ｃポートを有することにより、性能を損なうことなく、使用コストを最適化することができる。

［デバイスの存在検出およびリセットのシステムおよび方法］
本発明の実施の形態は、集積回路間（Ｉ２Ｃ）ルータに接続されたデバイス（例えば、フィールド交換可能ユニット）の検出、および／または、そのデバイスのリセットを提供する。
ここで図１６を参照する。
図１６には、本発明の一実施の形態によるＩ２Ｃルータ１６０５のブロック図を示す。
図１６に示すように、Ｉ２Ｃルータ１６０５は、内部バス１６１０、複数のバスポート１６１５〜１６３０、および制御ロジック１６４０を備える。
内部バス１６１０は、複数のバスポート１６１５〜１６３０および制御ロジック１６４０を通信接続する。
複数のバスポート１６１５〜１６３０は、高速外部バスポート１６１５および複数のＩ２Ｃバスポート１６２０〜１６３０（例えば、１６個のＩ２Ｃバスポートインターフェース）を備える。

内部バス１６１０は、双方向高速通信パスを備える。
一実施の形態において、この高速通信パスは、双方向パラレルバス（例えば、スピードウェイ）などを備える。
一実施態様において、この双方向パラレルバスは、８本のデータライン、２本のアドレスライン、および５本の制御ライン（例えば、読み出し、書き込み、イネーブル、割り込み、およびリセット）を備える。
内部バス１６１０の帯域幅は、Ｉ２Ｃルータ１６０５に接続されたデバイス間の高速通信を可能にするのに十分なものである。

制御ロジック１６４０は、複数のバスポート１６１５〜１６３０上の通信の制御、Ｉ２Ｃバスポート１６２０〜１６３０の１つまたは２つ以上のものに接続されたデバイスの検出、および／またはＩ２Ｃバスポート１６２０〜１６３０の１つまたは２つ以上のもののデバイスのリセットを行うロジックを実施する。
制御ロジック１６４０は、Ｉ２Ｃルータ１６０５内で集中化されてもよいし、複数のバスポート１６１５〜１６３０のそれぞれの間で分散されてもよい。

高速外部バスポート１６１５は、Ｉ２Ｃルータ１６０５と高速外部バスとの間の通信を制御するインターフェースを備える。
高速外部バスは、接続された外部デバイスとＩ２Ｃルータ１６０５との間の通信パスを備える。
高速外部バスは、パラレルバスであってもよいし、高速Ｉ２Ｃバス（例えば、１．４ＭＨｚ）などであってもよい。
それぞれのＩ２Ｃバスポート１６２０〜１６３０は、Ｉ２Ｃルータと、対応する区画された（例えば、分離された）Ｉ２Ｃバスとの間の通信を制御するインターフェースを備える。
Ｉ２Ｃバスは、それぞれ、１つまたは２つ以上の接続されたデバイスとＩ２Ｃルータ１６０５との間の通信パスを備える。
Ｉ２Ｃルータ１６０５は、複数のバスポート１６２０〜１６３０のいずれか１つにおいて１つまたは２つ以上のデータパケットを受信し、そのパケットを正しい宛先バスポート１６１５〜１６３０に転送する。
したがって、Ｉ２Ｃルータ１６０５は、高速外部バスに接続されたデバイスとＩ２Ｃバスのいずれか１つに接続されたデバイスとの間の通信、および／または、Ｉ２Ｃバスの第１のものに接続されたデバイスとＩ２Ｃバスの他のいずれかに接続された別のデバイスとの間の通信を提供する。

それぞれのＩ２Ｃバスポート１６２０〜１６３０は、双方向通信を提供するシリアルデータライン（ＳＤＡ）１６５０およびシリアルクロックライン（ＳＣＬ）１６５５を備える。
それぞれのＩ２Ｃバスポート１６２０は、存在ライン１６６０およびリセットライン１６６５をさらに備える。
一実施の形態において、存在ライン１６６０は、バスポート１６２０に入力されるアクティブローのラインであり、リセットライン１６６５は、バスポート１６２０から出力されるアクティブハイのラインである。
より具体的に言うと、存在ライン１６６０は、Ｉ２Ｃバスポート１６２０または制御ロジック１６４０によってハイレベルにバイアスされている（例えば、適切な供給電圧へ接続されたプルアップ抵抗器）。
デバイスがＩ２Ｃバスポート１６２０に接続され、そのデバイスが機能していると、そのデバイスは、存在ライン１６６０をローにする。
デバイスが、Ｉ２Ｃバスポート１６２０に接続されていないか、または、機能していない場合、存在ライン１６６０は、ハイレベルにバイアスされた状態を維持する。
したがって、Ｉ２Ｃルータ１６０５は、所与のＩ２Ｃバスポート１６２０に接続された動作可能なデバイスの存在を、対応する存在ライン１６６０の状態に応じて容易に判断することができる。

同様にして、リセットライン１６６５は、Ｉ２Ｃバスポート１６２０によりローレベルにバイアスされている（例えば、グラウンドに接続されたプルダウン抵抗器）。
リセット状況が、Ｉ２Ｃルータによって判断されると、Ｉ２Ｃバスポート１６２０または制御ロジック１６４０は、所望の（例えば、あらかじめ定められた）時間の間、リセットライン１６６５をハイレベルにする。
Ｉ２Ｃバスポート１６２０に接続されたデバイスは、リセットライン１６６５のハイ状態を検知すると、リセットプロセスを実行する。

次に図１７Ａを参照する。
図１７Ａには、本発明の一実施の形態に従って、集積回路間（Ｉ２Ｃ）ルータに接続されたデバイス（例えば、フィールド交換可能ユニット）の存在を検出する方法のフロー図を示す。
図１７Ａに示すように、この方法は、１７１０において、存在ラインを第１の状態にバイアスすることを含む。
一実施態様において、存在ラインは、当該存在ラインをハイレベルに引き上げることによりバイアスされる（例えば、適切な電源装置に接続されたプルアップ抵抗器）。

１７１５において、存在ラインは、当該存在ラインに接続された機能しているデバイスによって第２の状態にされる。
一実施態様において、この機能デバイスは、存在ラインをローレベルにする。
あるいは、１７２０において、デバイスが存在ラインに接続されていないか、または、デバイスが機能していない場合には、存在ラインは、第１の状態を維持する。

１７２５において、Ｉ２Ｃルータは、存在ラインを検知する。
存在ラインが、第２の状態である場合、１７３０において、Ｉ２Ｃルータは、デバイスが存在し、かつ／または、機能していると判断する。
存在ラインが、第１の状態である場合、１７３５において、Ｉ２Ｃルータは、デバイスが接続されていないか、または、デバイスが機能していないと判断する。
デバイスが存在するかしないか、および／または、機能するかどうかを判断すると、この方法は、１７２５に戻る。

次に図１７Ｂを参照する。
図１７Ｂには、本発明の一実施の形態に従って、集積回路間（Ｉ２Ｃ）ルータに接続されたデバイス（例えば、フィールド交換可能ユニット）をリセットする方法のフロー図を示す。
図１７Ｂに示すように、この方法は、１７５０において、リセットラインを第１の状態にバイアスすることを含む。
一実施態様において、リセットラインは、当該リセットラインをローレベルに引き下げることによりバイアスされる（例えば、グラウンドに接続されたプルダウン抵抗器）。

１７５５において、Ｉ２Ｃルータは、リセット状況が存在するかどうかを判断する。
一実施態様において、リセット状況は、図１３および図１４について上述したような報告されたエラーを含む。

リセット状況が存在する場合、１７６０において、リセットラインは、所望の（例えば、あらかじめ定められた）時間の間、第２の状態にされる。
リセット状況が存在する場合、一実施態様において、Ｉ２Ｃルータはリセットラインをハイレベルにする。

リセットラインがローレベルにされる場合、１７６５において、リセットラインに接続されたデバイスは、リセットプロセスを実行する。
リセット状況が存在しないと判断された場合、または、リセットラインがリセット状況に応じてローレベルにされた後、この方法は、ステップ１７５５に戻る。

別の実施の形態では、存在およびリセットの機能が、単一のラインを利用して実施される。
さらに、本発明の実施の形態は、デバイスの存在を検出する方法のみを実施することもできるし、リセット状況の判断時にデバイスをリセットする方法のみを実施することもできるし、デバイスの存在を検出する方法および同デバイスまたは別のデバイスをリセットする方法の双方を実施することもできる。

したがって、本発明の実施の形態は、機能していないデバイスをリセットできるという利点を有する。
また、本発明の実施の形態は、Ｉ２Ｃバスの制御権を取得したデバイスをリセットできるという利点も有する。
デバイスのリセット時に、Ｉ２Ｃバスは解放される。
また、本発明の実施の形態は、応答しないデバイスを検出できるという利点も有する。
Ｉ２Ｃルータに接続されたデバイスを検出する機能および／またはリセットする機能により、システムのロバスト性が容易に改善される。

［Ｉ２Ｃルータの分析システムおよび分析方法］
本発明の実施の形態は、集積回路間（Ｉ２Ｃ）ルータを容易に分析してデバッグすることを提供する。
図１８を参照する。
図１８には、本発明の一実施の形態によるＩ２Ｃルータ１８０５のブロック図を示す。
図１８に示すように、Ｉ２Ｃルータ１８０５は、内部バス１８１０、複数のバスポート１８１５〜１８３０、制御ロジック１８４０、およびデバッグコネクタ１８６５を備える。
内部バス１８１０は、複数のバスポート１８１５〜１８３０および制御ロジック１８４０を通信接続する。
複数のバスポート１８１５〜１８３０は、高速外部バスポート１８１５および複数のＩ２Ｃバスポート１８２０〜１８３０（例えば、１６個のＩ２Ｃバスポート）を備える。

内部バス１８１０は、双方向高速通信パスおよび複数のデバッグラインを備える。
一実施の形態において、この高速通信パスは、双方向パラレルバス（例えば、スピードウェイ）などを備える。
一実施態様において、この双方向パラレルバスは、８本のデータライン、２本のアドレスライン、５本の制御ライン（例えば、読み出し、書き込み、イネーブル、割り込み、およびリセット）、ならびに４本の汎用入出力ラインを備える。
一実施の形態において、この汎用入出力ラインは、デバッグライン１８８０（例えば、デバッグ（０：３））として指定される。
内部バス１８１０の帯域幅は、Ｉ２Ｃルータ１８０５に接続されたデバイス（例えば、フィールド交換可能ユニット）間の高速通信を可能にするのに十分なものである。

制御ロジック１８４０は、複数のポートインターフェース１８１５〜１８３０上の通信を制御するロジックを実施する。
制御ロジック１８４０は、Ｉ２Ｃルータ１８０５内に集中化されてもよいし、複数のバスポート１８１５〜１８３０のそれぞれの間で分散されてもよい。

高速外部バスポートインターフェース１８１５は、Ｉ２Ｃルータ１８０５と高速外部バス１８４５との間の通信を制御するインターフェースを備える。
高速外部バス１８４５は、接続された外部デバイスとＩ２Ｃルータ１８０５との間の通信パスを備える。
高速外部バス１８４５は、パラレルバスであってもよいし、高速Ｉ２Ｃバス（例えば、１．４ＭＨｚ）などであってもよい。
それぞれのＩ２Ｃバスポート１８２０〜１８３０は、Ｉ２Ｃルータ１８０５と、対応する区画された（例えば、分離された）Ｉ２Ｃバス１８５５〜１８６０との間の通信を制御するインターフェースを備える。
それぞれのＩ２Ｃバスポート１８２０〜１８３０は、双方向通信を提供するシリアルデータライン（ＳＤＡ）１８６０およびシリアルクロックライン（ＳＤＬ）１８６５を備える。
Ｉ２Ｃバスは、それぞれ、１つまたは２つ以上の接続されたデバイスとＩ２Ｃルータ１８０５との間の通信パスを備える。
Ｉ２Ｃルータ１８０５は、複数のバスポート１８１５〜１８３０のいずれか１つにおいて１つまたは２つ以上のデータパケットを受信し、そのパケットを正しい宛先バスポート１８１５〜１８３０に転送する。
したがって、Ｉ２Ｃルータ１８０５は、高速外部バス１８１５に接続されたデバイスとＩ２Ｃバス１８２０〜１８３０のいずれか１つに接続されたデバイスとの間の通信、および／または、Ｉ２Ｃバス１８２０〜１８３０の第１のものに接続されたデバイスとＩ２Ｃバス１８２０〜１８３０の他のいずれかに接続された別のデバイスとの間の通信を提供する。

デバッグコネクタ１８６５は、ロジックアナライザ１８８５などを複数の分析ライン１８７０〜１８８０の１つまたは２つ以上のものに接続する。
また、デバッグコネクタ１８６５は、ロジックアナライザ１８８５を内部バス１８１０に接続することもできる。
複数の分析ライン１８７０〜１８８０は、複数のデバッグライン（例えば、デバッグ（０：３））１８８０、１つもしくは２つ以上の制御ロジック分析ライン１８７０、および／または１つもしくは２つ以上の高速外部バスポート分析ライン１８７５を備える。
したがって、デバッグコネクタ１８６５によって、Ｉ２Ｃルータ１８０５を通過してあらゆるバスポート１８１５〜１８３０に向かうトラフィックを標準的な方法でトラップして分析することが可能になる。
さらに、分析ライン１８７０〜１８８０上の信号を、ブレークポイントおよびトラップを設定するデバッグファームウェアによって生成することができる。
Ｉ２Ｃルータ１８０５は、内部バス（例えば、パラレルバス）１８１０およびデバッグコネクタ１８６５を備え、個々のバスポート１８１５〜１８３０へのトラフィックおよび／またはそれらのポートからのトラフィックの分離を容易に可能にし、そして、バイトごとのデータの便利な分析を容易に可能にする。
したがって、シリアル信号の分析に必要な複合状態の状況を生成して制御することは必要なくなる。

次に図１９を参照する。
図１９には、本発明の一実施の形態に従って、集積回路間（Ｉ２Ｃ）ルータのトラフィックを分析する方法のフロー図を示す。
図１９に示すように、この方法は、１９１０において、１つまたは２つ以上のバスポートに接続された複数のデバッグライン上で第１の組の信号を送信することを含む。
この送信することは、信号を送信することおよび／または信号を受信することを含む。
例示の一実施態様において、１つまたは２つ以上の信号が、デバッグライン上を送信され、それによって、１つまたは２つ以上のバスポートの１つまたは２つ以上の要素の状態が設定され、かつ／または、バスポートの１つまたは２つ以上のものの１つまたは２つ以上の要素の状態が判断される。

この方法は、１９１５において、１つまたは２つ以上の制御ロジック分析ライン上で第２の組の信号を送信することをさらに含むことができる。
例示の一実施態様において、１つまたは２つ以上の信号が、１つまたは２つ以上の制御ロジック分析ライン上を送信され、それによって、制御ロジックの１つまたは２つ以上の要素の状態が設定され、かつ／または、制御ロジックの１つまたは２つ以上の要素の状態が判断される。
この方法は、１９２０において、１つまたは２つ以上のバスポート分析ライン上で第３の組の信号を送信することをさらに含むことができる。
例示の一実施態様において、１つまたは２つ以上の信号が、１つまたは２つ以上のバスポート分析ライン上を送信され、それによって、バスポートの１つまたは２つ以上の要素の状態が設定され、かつ／または、バスポートの１つまたは２つ以上の要素の状態が判断される。

この方法は、１９２５において、１つまたは２つ以上のバスポートでデータパケットを送信することをさらに含むことができる。
これらのバスポートには、高速バスポートおよび／または複数のＩ２Ｃバスポートを含めることができる。
さらに、この方法の要素１９１０〜１９２５の１つまたは２つ以上のものは、個別に実行することもできるし、互いを直列に組み合わせて実行することもできるし、互いを並列に組み合わせて実行することもできるし、それらの実行を任意に組み合わせて実行することもできる。

したがって、本発明の実施の形態は、Ｉ２Ｃルータを通過する通信を容易に分析してデバッグできるという利点を有する。
本発明の実施の形態は、ブレークポイントおよびトラップの設定を可能にするという利点を有する。
また、本発明の実施の形態は、データパケットトラフィックの宛先アドレスおよび送信元アドレスを容易に検出することを可能にするという利点も有する。

以上のように、本発明の実施の形態は説明される。
本発明の実施の形態は、Ｉ２Ｃルータを通じた送信データに使用するのによく適しているが、本発明は、このような使用に限定されるものではなく、Ｉ２Ｃデータ送信の分離および制御が望まれる他の用途にも使用することができる。
本発明を特定の実施の形態で説明してきたが、本発明は、このような実施の形態によって限定されるものと解釈されるべきではなくて、むしろ、添付した特許請求の範囲に従って解釈されるべきであることが理解されるべきである。

従来技術による従来の集積回路間バスシステムのブロック図である。 本発明の一実施の形態による集積回路間ルータを備えた集積回路間バスシステムのブロック図である。 本発明の一実施の形態による集積回路間ルータのブロック図である。 本発明の一実施の形態に従って、Ｉ２Ｃルータでの通信を制御するプロセスのフロー図である。 本発明の一実施の形態による集積回路間ルータのブロック図である。 本発明の一実施の形態に従って、集積回路間ルータにおけるデータ通信を安全に制御するプロセスを示すフロー図である。 本発明の一実施の形態に従って、宛先アドレスを制御情報と比較するプロセスを示すフロー図である。 本発明の一実施の形態による例示のマスクレジスタ設定である。 本発明の一実施の形態による制御情報と宛先アドレスとの例示の比較である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じたデータ送信方法のフロー図である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じたデータ送信方法のフロー図である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じた代替的なデータ送信方法のフロー図である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じたデータ送信方法のフロー図である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じたデータ送信方法のフロー図である。 本発明の一実施の形態による、Ｉ２Ｃルータを通じた代替的なデータ送信方法のフロー図である。 本発明の一実施の形態による集積回路間（Ｉ２Ｃ）ルータエラー管理システムのブロック図である。 本発明の一実施の形態による相互接続ルータエラー管理方法のフローチャートである。 本発明の一実施の形態による個別の伝送速度をサポートする例示の集積回路間ルータのデータフロー図である。 本発明の実施の形態に従って、集積回路間ルータのポート間でデータを通信するプロセスを示すフロー図である。 本発明の実施の形態に従って、集積回路間ルータのポート間でデータを通信するプロセスを示すフロー図である。 本発明の実施の形態に従って、集積回路間ルータのポート間でデータを通信するプロセスを示すフロー図である。 本発明の一実施の形態によるＩ２Ｃルータのブロック図である。 本発明の一実施の形態に従って、Ｉ２Ｃルータに接続されたデバイスの存在を検出する方法のフロー図である。 本発明の一実施の形態に従って、Ｉ２Ｃルータに接続されたデバイスをリセットする方法のフロー図である。 本発明の一実施の形態によるＩ２Ｃルータのブロック図である。 本発明の一実施の形態に従って、Ｉ２Ｃルータのトラフィックを分析する方法のフロー図である。

符号の説明

２０１・・・管理プロセッサ、
２１０，２５３ａ〜２５３ｎ・・・ポート、
２５７ａ〜２５７ｎ・・・コントローラ、
２５９ａ〜２５９ｎ・・・電気コネクタ、
３５０・・・Ｉ２Ｃルータ、
３５１・・・制御ロジック、
３１０・・・ポート、
３５３ａ〜３５３ｎ・・・Ｉ２Ｃポート、
３７５・・・高速内部バス、
５４０・・・高速外部バス、
５１０・・・高速ポート、
５２０，５２１，５２２・・・バッファ、
５１５，５１６，５１７・・・制御ロジック、
５３０，５３１，５３２・・・マスク、
５５０，５６０・・・入出力ポート、
１２２０・・・高速ポート、
１２３０・・・デバッグコネクタ、
１２５０，１２７０・・・Ｉ２Ｃポート、
１２５１・・・制御ロジック、
１２５２・・・マスク、
１２５３・・・エラーレジスタ、
１５３Ａ，１５３Ｂ・・・フラグ、
１２５５・・・バッファ、
１２５７・・・システムイベントログ、
１２９０・・・パラレル／シリアルバスインターフェース、
１２９１・・・タイムアウトレジスタ、
１２９３・・・ステータスレジスタ、
１４０２・・・内部バス、
１４２２，１４３２・・・バッファ、
１４２０・・・Ｉ２Ｃポート、
１４３０・・・ポート、
１４２４・・・外部Ｉ２Ｃバス、
１４３４・・・外部バス、
１６０５・・・Ｉ２Ｃルータ、
１６１０・・・内部バス、
１６４０・・・制御ロジック、
１６１５・・・バスポート０（高速）、
１６４５・・・高速外部バス、
１６２０，１６２５，１６３０・・・バスポート、
１８０５・・・Ｉ２Ｃルータ、
１８１０・・・内部バス、
１８４０・・・制御ロジック、
１８６５・・・デバッグコネクタ、
１８８５・・・ロジックアナライザ、
１８１５・・・バスポート０（高速）、
１８４５・・・高速外部バス、

Claims (10)

1. 送信元ポートから宛先ポートへＩ２Ｃルータを通じてデータを送信する方法（９００）であって、
   前記Ｉ２Ｃルータであって、Ｉ２Ｃ宛先ポートおよび第２のＩ２Ｃ送信元ポートバッファをさらに備える前記Ｉ２Ｃルータの第１のＩ２Ｃ送信元ポートバッファにデータを受信すること（９０１）と、
   前記第１のＩ２Ｃ送信元ポートバッファがオーバーフローする前に、前記Ｉ２Ｃ宛先ポートを捕捉すること（９０２）と、
   前記第２のＩ２Ｃ送信元ポートバッファから前記Ｉ２Ｃ宛先ポートへの送信を制限すると同時に、前記第１のＩ２Ｃ送信元ポートバッファから前記Ｉ２Ｃ宛先ポートへ前記データを送信すること（９０３）と
   を含むデータを送信する方法。
2. 前記Ｉ２Ｃ宛先ポートを捕捉することは、
   前記第１のＩ２Ｃ送信元ポートバッファのすべてのデータが、前記Ｉ２Ｃ宛先ポートへ送信完了するまで、前記第２のＩ２Ｃ送信元ポートバッファをビジーに保持すること（８１６）
   を含む
   請求項１に記載のデータを送信する方法。
3. 前記Ｉ２Ｃ宛先ポートを捕捉することは、
   ０からなるバイトを前記第２のＩ２Ｃ送信元ポートバッファに送信すること
   を含む
   請求項１に記載のデータを送信する方法。
4. 前記第２のＩ２Ｃ送信元ポートバッファをビジーに保持することは、
   前記第２のＩ２Ｃ送信元ポートバッファのＳＤＡラインおよびＳＣＬラインを論理的なローレベルにアサートすること
   を含む
   請求項２に記載のデータを送信する方法。
5. 前記Ｉ２Ｃ宛先ポートを捕捉することは、
   前記第２のＩ２Ｃ送信元ポートバッファが、前記０からなるバイトを受信して現在の通信を停止してから現在の通信を再開するまでの間に、前記Ｉ２Ｃ宛先ポートの制御権を取得すること
   を含む
   請求項３に記載のデータを送信する方法。
6. 前記Ｉ２Ｃ宛先ポートを捕捉することは、前記第１のＩ２Ｃ送信元ポートバッファの前記データが、前記第１のＩ２Ｃ送信元ポートバッファの容量のあらかじめ設定された部分を超えた時に開始される
   請求項１に記載のデータを送信する方法。
7. 前記あらかじめ設定された部分は、前記第１のＩ２Ｃ送信元ポートバッファの容量の２分の１である
   請求項６に記載のデータを送信する方法。
8. Ｉ２Ｃルータ（５７０）であって、
   第１のＩ２Ｃ送信元ポートバッファ（５２１）と、
   前記第１のＩ２Ｃ送信元ポートバッファ（５２１）に接続されたＩ２Ｃ宛先ポート（５６０）と、
   前記Ｉ２Ｃ宛先ポート（５６０）に接続された第２のＩ２Ｃ送信元ポートバッファと
   を備え、
   該Ｉ２Ｃルータ（５７０）は、前記第１のＩ２Ｃ送信元ポートバッファ（５２１）にデータを受信すると、前記第２のＩ２Ｃ送信元ポートバッファから前記Ｉ２Ｃ宛先ポート（５６０）への送信を制限し、前記第１のＩ２Ｃ送信元ポートバッファ（５２１）がオーバーフローする前に前記Ｉ２Ｃ宛先ポート（５６０）を捕捉し、前記第１のＩ２Ｃ送信元ポートバッファ（５２１）から前記Ｉ２Ｃ宛先ポート（５６０）へ前記データを送信する
   Ｉ２Ｃルータ。
9. 前記Ｉ２Ｃルータ（５７０）は、前記第１のＩ２Ｃ送信元ポートバッファ（５２１）のすべてのデータが、前記Ｉ２Ｃ宛先ポート（５６０）へ送信完了するまで、前記第２のＩ２Ｃ送信元ポートバッファをビジーに保持することにより、前記Ｉ２Ｃ宛先ポート（５６０）を捕捉する
   請求項８に記載のＩ２Ｃルータ。
10. 前記Ｉ２Ｃルータ（５７０）は、０からなるバイトを前記第２のＩ２Ｃ送信元ポートバッファに送信することにより、前記Ｉ２Ｃ宛先ポート（５６０）を捕捉する
    請求項８に記載のＩ２Ｃルータ。

Images