JP2021519463A - システムオンチップ（ＳｏＣ）エージェントのリセットおよび電力管理のためのプロトコルレベル制御 - Google Patents

Abstract

【解決手段】システムオンチップ（ＳｏＣ）上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムが開示されている。ＩＰエージェントがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰエージェントとの間で行われる。各ＩＰエージェントは、他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセットから出ることができる。相互接続は、リセットの前、電力ダウンモードの時、または、動作不良時などに、動作不能である任意のＩＰエージェントの代理として構成されてよい。【選択図】図８

Description

関連出願への相互参照
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９（ＰＲＴＩＰ００１Ｐ）号および２０１８年６月２８日出願の米国仮出願第６２／６９１，１１７（ＰＲＴ１Ｐ００２Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。

本願は、システムオンチップ（ＳｏＣ）に関し、より具体的には、ＳｏＣ上でリセットおよび／または電力管理機能を一貫して実施し、ひいては、特に複数のＳｏＣファミリーにわたって、ＳｏＣのより一様なシステムソフトウェアビューを提供するシステムおよび方法に関する。

システムオンチップ（「ＳｏＣ」）は、複数のサブシステムを備える集積回路であり、しばしば、知的財産（「ＩＰ」）エージェントと呼ばれる。ＩＰエージェントは、典型的には、特定の機能を実装または実行するように設計された回路の「再利用可能な」ブロックである。ＩＰエージェントを用いることにより、複雑なＳｏＣを開発する時間およびコストを大幅に削減できる。

ＳｏＣは、典型的には、システムコントローラと、相互接続（バスまたはネットワークオンチップ（ＮｏＣ）など）と、を備える。システムコントローラは、システムソフトウェアを実行し、ＳｏＣの全体動作を管理するために提供される。様々なＩＰエージェントが、１以上のリンクを介して相互接続に接続されており、相互接続を介して互いに通信する。

ＳｏＣ開発者は、一般に、しばしば複数のベンダからの異なるＩＰエージェントを利用する。各ＩＰエージェントは、通常、リセットのための独自の手順を実装する。ＳｏＣ上のシステムコントローラおよび相互接続の観点から、これは、いくつかの理由で問題がある。

典型的なＳｏＣは、通常、相互接続に接続された複数のＩＰエージェントを有する。リセット後に、ＩＰエージェントの各々は、自身が用いる独自のリセット手順により、異なる時間にリセット状態から出る可能性がある。各ＩＰエージェントがリセットから出る時間が異なることで、重大な問題が起こりうる。送信元ＩＰエージェントが、まだリセット中である宛先ＩＰエージェントへのトランザクションを生成した場合、（１）宛先ＩＰエージェントは、要求を処理することができず、（２）送信元ＩＰエージェントは、応答を決して受信しない。結果として、システム全体が、ハングアップする場合があり、おそらくは、システム全体のリセットが必要となる。

ハングアップを防止するための１つの周知のアプローチは、相互接続と各ＩＰエージェントとの間の各リンクの中間に回路を設計して配置することである。この回路の目的は、相互接続に接続された全ＩＰエージェントが同じクロックサイクル中にリセットから出るのを確実にすることである。しかしながら、このアプローチには、いくつかの理由で欠点がある。
１．中間回路の設計には、時間および労力を要し、しばしば、ＳｏＣの開発を遅らせる。
２．中間回路は、ＳｏＣごとに、典型的には、異なる設計チームによって開発される。結果として、中間回路は、通常は、ＳｏＣごとに異なり、または、同じＳｏＣ上の異なるサブシステムの間ですら異なる。
３．回路の複雑さは、通常、所与の相互接続へ接続できるＩＰエージェントの数が制限されることを意味する。この制限の実際的な影響は、所与の数のＩＰエージェントを収容するために必要な相互接続レベルが多くなることである。したがって、ＳｏＣの全体の複雑さが増大する。

時々、ＩＰエージェントが正常に機能しない。例えば、ＩＰエージェントは、偽のトランザクションを相互接続へ投入する、受信したトランザクションへの応答に失敗して、例外メッセージを生成する、などの場合がある。いくつかの状況において、正常に機能しないＩＰエージェントは、リセットされる必要がありうる。現行のＳｏＣ相互接続規格では、標準ＩＰエージェントリセットメカニズムが存在しない。ＳｏＣ全体がリセットされなければならないか、もしくは、中間回路が、必要な隔離、リセット、および、システムへのＩＰの再導入などを実行するよう設計される必要があるか、のいずれかである。

電力管理も、特定の現行のＳｏＣ相互接続規格では対処されていない。アドバンスト・マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）プロトコルは、例えば、電力管理に対処せず、意図的に電力を落とすかまたはＩＰエージェントをオフにする方法を提供していない。この機能を提供するためには、電力管理機能は、典型的に、例えば、電力管理を扱うためにリンク上のさらなる中間回路を開発することによって、チップごとにＳｏＣへカスタム設計される必要がある。

複数のＳｏＣを提供する多くの企業が、製品化までの時間を短縮するために、類似したデバイスの間で或る程度のシステムソフトウェアを共有する。しかしながら、類似したＳｏＣでも、ソフトウェアは、典型的には、ＩＰエージェントが同じでありうる状況であっても、デバイスからデバイスへと簡単には移植できない。リセットおよび／または電力管理に用いられる任意の中間回路に小さい違いがあれば、システムソフトウェアは、各デバイスに向けて修正およびデバッグされる必要がありうる。

したがって、多数のＳｏＣを開発する企業の課題は、（１）各デバイスに対してリセットおよびおそらくは電力管理を実施するためのカスタマイズされた回路を開発すること、ならびに、（２）各デバイスに対してシステムソフトウェアを修正およびデバッグすること、である。複数のデバイスにわたるこの努力は、費用が掛かり、複雑で、時間が掛かるため、製品をすみやかに市場に出す能力を低下させる。

したがって、カスタマイゼーションの必要性を無くし、複数のＳＯＣの間の一貫したシステムソフトウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムが求められている。

カスタマイゼーションの必要性を無くし、複数のＳＯＣの間の一貫したシステムソフトウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムが開示されている。

一実施形態において、システムは、１以上のＩＰエージェントと、相互接続と、それぞれＩＰエージェントおよび相互接続の間の１以上のリンクと、を備える。ＩＰエージェントがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰエージェントとの間で行われる。個々のネゴシエーションでは、各ＩＰエージェントが、他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセットから出ることができる。リセットから出た後、各ＩＰエージェントは、「トランザクション準備完了状態」になり、相互接続に導入され、相互接続に接続された他の要素（システムコントローラなど）にとって可視になる。

別の実施形態において、相互接続は、動作不能である任意のＩＰエージェントの代理として構成されてよい。この特徴は、（１）トランザクション準備完了状態になる前、（２）動作不良時、および／または、（３）電力ダウン状態の時の動作不能時に、ＩＰエージェントがトランザクションの目標になった場合に起こりうるシステム全体のハングアップを防止するので有利である。相互接続が代理として機能する場合に、トランザクションを送信した送信元に、例外メッセージが送信されることで、送信元が目標ＩＰエージェントからの応答を無期限に待つことによって引き起こされるハングアップを防止することができる。

さらに別の実施形態において、相互接続がＩＰエージェントの代理として機能するように構成できることで、（１）ＩＰエージェントを個々にリセットすること、および、（２）ＩＰエージェントを節電状態にすることが可能になる。様々な実施形態において、節電状態は、低電力動作可能モード、状態情報の保持または非保持の低電力動作不能モード、もしくは、電力オフモードなど、いくつかのモードの内の１つを含みうる。

したがって、本発明は、多くの課題を解決する。本発明は、同じ時間／クロックサイクル中にリセットから出るように各ＩＰエージェントを管理するため、および、（２）ＩＰエージェントの電力管理のためのカスタム回路を作る必要性を排除する。代わりに、本発明は、これらの機能両方の一様な実施を有利に提供し、複数のＳｏＣの間の一貫したシステムソフトウェアビューをもたらす。この一貫したソフトウェアビューによれば、ＳｏＣのファミリーにわたるカスタム設計およびソフトウェア変更の多くが排除され、開発コストの節約、複雑さの低減、および、製品化までの時間短縮が達成される。

本願およびその利点については、添付の図面に関連して行う以下の説明を参照することによって最も良く理解できる。

非排他的実施形態に従って、システムオンチップ（ＳｏＣ）のための共有相互接続を示すブロック図。

非排他的実施形態に従って、トランザクションのパケットの例を示す図。

第１非排他的実施形態に従って、アービトレーション要素を示す論理図。

第２非排他的実施形態に従って、アービトレーション要素を示す論理図。

非排他的実施形態に従って、共有相互接続の仮想チャネルを介してトランザクションの部分をアービトレーションして送信するための動作工程を示すフローチャート。

非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第１例を示す図。

非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第２例を示す図。

本発明の別の非排他的実施形態に従って、二方向にトラフィックを扱うための２つの共有相互接続を示すブロック図。

本発明の非排他的実施形態に従って、リセット、電力管理、および、休止機能を有するＳｏＣを示すブロック図。

本発明の非排他的実施形態に従って、ＩＰエージェントのリセットシーケンスを示すフローチャート。

本発明の非排他的実施形態に従って、動作不良のＩＰエージェントのためのリセットシーケンスを示すフローチャート。

本発明の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。

本発明の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。

本発明のさらに別の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。

リンクを休止状態にするための工程を示すフローチャート。

ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。 ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。 ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。 ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。

図面において、同様の構造要素を指定するために、同様の符号が用いられることがある。

以下では、添付図面に例示された、いくつかの非排他的な実施形態を参照しつつ、本願の詳細な説明を行う。以下の説明では、本開示の完全な理解を促すために、数多くの具体的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本開示は、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。また、本開示が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造については、詳細な説明を省略した。

現在開発中の集積回路の多くは、非常に複雑である。結果として、多くのチップ設計者は、システムオンチップすなわち「ＳｏＣ」アプローチを用いて、単一のシリコン上に複数のサブシステムまたはＩＰエージェントを相互接続してきた。消費者デバイス（例えば、ハンドヘルド、携帯電話、タブレットコンピュータ、ラップトップおよびデスクトップコンピュータ、メデイア処理など）、仮想または拡張現実（例えば、ロボット工学、自律走行車、航空機など）、医療機器（例えば、イメージングなど）、工業、ホームオートメーション、工業（例えば、スマート家電、家庭用監視機器、など）およびデータセンター用途（例えば、ネットワークスイッチ、接続型ストレージデバイス、など）など、様々な用途のためのＳｏＣが、現在利用可能であるかまたは開発されている。

本願は、共有リソースへのアクセスをアービトレートするためのアービトレーションシステムおよび方法をおおむね対象にしている。かかる共有リソースは、例えば、バス相互接続、メモリリソース、処理リソース、または、複数の競争パーティの間で共有されたほぼ任意のその他のリソースでありうる。説明の便宜上、以下で詳述する共有リソースは、システムオンチップすなわち「ＳｏＣ」上の複数のサブシステムによって共有される相互接続であるとする。

ＳｏＣでは、後に詳述するように、トランザクションの形態で互いにトラフィックをやり取りする複数のサブシステムがあり、共有リソースは、物理的な相互接続であり、様々なトランザクションまたはその部分が、共有相互接続に関連する複数の仮想チャネルを介して伝送され、複数の異なるアービトレーションスキームおよび／または優先度の１つが、サブファンクションの間のトランザクションの伝送に向けた共有相互接続へのアクセスをアービトレートするために用いられてよい。

トランザクションクラス
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプまたはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。

Ｐｏｓｔｅｄトランザクション（書き込みなど）は、応答トランザクションを求めない。送信元がデータを指定された宛先に書き込むと、トランザクションが終了する。Ｎｏｎ−ｐｏｓｔｅｄトランザクション（読み出しまたは書き出しのいずれかなど）では、応答が求められる。しかしながら、応答は、別個のＣｏｍｐｌｅｔｉｏｎトランザクションとして分岐される。換言すると、読み出しでは、最初のトランザクションが読み出し動作のために用いられ、別個であるが関連するＣｏｍｐｌｅｔｉｏｎトランザクションが読み出しコンテンツを返すために用いられる。Ｎｏｎ−ｐｏｓｔｅｄ書き込みでは、最初のトランザクションが書き込みのために用いられ、一方、書き込みが完了すると、第２関連Ｃｏｍｐｌｅｔｉｏｎトランザクションが確認のために求められる。

トランザクションは、タイプに関わらず、１以上のパケットによって表すことができる。いくつかの状況では、トランザクションは、単一のパケットによって表されうる。別の状況においては、複数のパケットが、トランザクション全体を表すために必要とされうる。

ビートは、クロックサイクルあたりに共有相互接続を介して伝送できるデータの量である。例えば、共有相互接続が物理的に１２８ビット幅である場合、１２８ビットが、各ビートまたはクロックサイクルに伝送されうる。

いくつかの状況において、トランザクションは、伝送のために複数の部分に分割される必要がありうる。５１２ビット（６４バイト）であるペイロードを有する単一のパケットを有するトランザクションを考える。共有相互接続が１２８ビット幅（１６バイト）のみである場合、トランザクションは、４つの部分（例えば、４×１２８＝５１２）に分割され、４つのクロックサイクルまたはビートで伝送される必要がある。一方、トランザクションが１２８ビット幅未満である単一パケットのみである場合、トランザクション全体が、１つのクロックサイクルまたはビートで送信されうる。同じトランザクションがさらなるパケットをたまたま含む場合、さらなるクロックサイクルまたはビートが必要とされうる。

したがって、トランザクションの「部分」という用語は、所与のクロックサイクルまたはビート中に共有相互接続を介して転送できるデータの量である。部分のサイズは、共有相互接続の物理的な幅に応じて変わりうる。例えば、共有相互接続が物理的に６４データビット幅である場合、任意の１サイクルまたはビート中に転送できる最大ビット数は６４ビットである。所与のトランザクションが６４ビット以下のペイロードを有する場合、トランザクション全体が、単一部分で共有相互接続を介して送信されうる。一方、ペイロードがより大きい場合、パケットは、複数の部分で共有相互接続を介して送信されなければならない。１２８、２５６、または、５１２ビットのペイロードを有するトランザクションは、それぞれ、２、４、および、８の部分を必要とする。このように、「部分」という用語は、任意の所与のクロックサイクルまたはビート中に共有相互接続を介して送信されうるトランザクションの一部または全体のいずれかを意味すると広く解釈されるべきである。

ストリーム
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々な組み合わせを、以下の表２で詳述する。

上述したトランザクションクラスの数は、単に例示であり、限定として解釈すべきではないことに注意されたい。逆に、任意の数の仮想チャネルおよび／またはトランザクションクラスが用いられてよい。

共有相互接続の仮想チャネルでのアービトレーション
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非排他的実施形態において、アービトレーションシステムは、アップストリームサブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。

共有相互接続１２は、Ｎデータビット幅でありＭ個の制御ビットを含む物理的な相互接続である。また、共有相互接続１２は一方向性であり、これは、送信元（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）への方向にのみトラフィックを扱うことを意味する。

様々な代替例において、Ｎデータビットの数は、任意の整数であってよいが、典型的には、それぞれ、２のべき乗のビット幅である（例えば、２１、２２、２３、２４、２５、２６、２７、２８、２９など）または（２、４、６、８、１６、３２、６４、１２８、２５６など）。最も現実的な応用例では、Ｎビットの数は、３２、６４、１２８、２５６、または、５１２のいずれかである。ただし、これらの幅は、単に例示であり、どのようにも限定するものとして解釈すべきではないことを理解されたい。

制御ビットの数Ｍも、様々であり、任意の数であってよい。

１以上の論理チャネル（図示せず）（以降、「仮想チャネル」すなわち「ＶＣ」と呼ぶ）が、共有相互接続１２に関連付けられている。各仮想チャネルは、独立している。各仮想チャネルは、複数の独立ストリームに関連付けられてよい。仮想チャネルの数は、広く変化してよい。例えば、３２以上の数までの仮想チャネルが、規定されるか、または、共有相互接続１２に関連付けられてよい。

様々な代替実施形態において、各仮想チャネルは、異なる優先度を割り当てられてよい。１以上の仮想チャネルに、より高い優先度が割り当てられてよく、一方、１以上のその他の仮想チャネルに、より低い優先度が割り当てられてよい。高い優先度のチャネルは、低い優先度の仮想チャネルよりも高い共有相互接続１２へのアクセス権を与えられるまたはアービトレートされる。別の実施形態では、仮想チャネルの各々に、同じ優先度が与えられてもよく、その場合、共有相互接続１２へのアクセス権を与えるまたはアービトレートする時に、或る仮想チャネルを別の仮想チャネルより優先することがない。さらに別の実施形態において、仮想チャネルの内の１以上に割り当てられた優先度は、動的に変化してもよい。例えば、第１セットの状況において、仮想チャネルすべてに、同じ優先度が割り当てられてよいが、第２セットの状況において、特定の仮想チャネルに、その他の仮想チャネルよりも高い優先度が割り当てられてもよい。したがって、状況が変化するにつれて、仮想チャネルの間で用いられる優先度スキームは、現在の動作条件に最もよく合うように変更されうる。

サブシステム１４の各々は、典型的には、「再利用可能な」回路またはロジックのブロックであり、一般に、ＩＰコアまたはエージェントと呼ばれる。 ほとんどのＩＰエージェントは、特定の機能を実行するよう設計され、例えば、イーサネットポート、ディスプレイドライバ、ＳＤＲＡＭインターフェース、ＵＳＢポートなどの周辺デバイスのためのコントローラである。かかるＩＰエージェントは、一般に、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの集積回路（ＩＣ）上に提供された複雑なシステムの設計全体の中で必要なサブシステム機能を提供する「ビルディングブロック（構成要素）」として用いられる。利用可能なＩＰエージェントのライブラリを用いることにより、チップ設計者は、より複雑な集積回路の設計において様々なロジック機能を容易に「ボルト締め」することができるので、設計時間を削減すると共に開発コストを節約することができる。サブシステムエージェント１４は、専用ＩＰコアに関して上述したが、これは、必要条件ではないことを理解されたい。逆に、サブシステム１４は、単一のポート２０に接続されたまたはそれを共有するＩＰ機能のコレクションであってもよい。したがって、「エージェント」という用語は、サブシステムが単一の機能を実行するか、複数の機能を実行するかに関わらず、ポート２０に接続された任意のタイプのサブシステムとして広く解釈されるべきである。

一対のスイッチ１６および１８が、それぞれ、専用アクセスポート２０を介してサブシステムエージェント１４の各々と共有相互接続１２との間のアクセスを提供する。図の例示的実施形態では、
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。

スイッチ１６および１８は、多重化および逆多重化機能を実行する。スイッチ１６は、サブシステムエージェントＩＰ１、ＩＰ２、および／または、ＩＰ３によって生成されたアップストリームトラフィックを選択し、共有相互接続１２を介してトラフィックをダウンストリームに送信する。スイッチ１８では、逆多重化動作が実行され、トラフィックは、目標サブシステムエージェント（すなわち、ＩＰ４、ＩＰ５、または、ＩＰ６のいずれか）へ提供される。

各アクセスポート２０は、一意ポート識別子（ＩＤ）を有しており、各サブシステムエージェント１４の専用アクセスをスイッチ１６または１８のいずれかへ提供する。例えば、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスポートＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２に割り当てられる。同様に、サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、アクセスポートＰｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５に割り当てられる。

スイッチ１６、１８への／からの入口ポイントおよび出口ポイントを提供するのに加えて、一意ポートＩＤ２０は、サブシステムエージェント１４の間のトラフィックをアドレッシングするために用いられる。各ポート２０は、システムメモリ２４内に、特定の量の割り当てられたアドレス可能空間を有する。

いくつかの非排他的な実施形態において、アクセスポート２０の全部または一部に、一意ポートＩＤだけでなく、「グローバル」ポート識別子が割り当てられてもよい。トランザクションおよびその他のトラフィックが、グローバルポート識別子に割り当てられたアクセスポートの全部または一部に送信されうる。したがって、グローバル識別子を用いれば、トランザクションおよびその他のトラフィックが、アクセスポート２０の全部または一部へ広く発信またはブロードキャストすることができ、一意識別子を用いて各アクセスポート２０へ個別にアドレッシングする必要性を排除できる。

スイッチ１６は、さらに、アービトレーション要素２６、アドレス解決ロジック（ＡＲＬ）２８、および、アドレス解決ルックアップテーブル（ＬＵＴ）３０を備える。

動作中、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、トランザクションを生成する。各トランザクションが生成されると、送信側サブシステム１４によってパケット化され、次いで、パケット化されたトランザクションは、対応するポート２０を介してローカルスイッチ１６へ投入される。例えば、ＩＰ１、ＩＰ２、および、ＩＰ３によって生成されたトランザクションの部分は、それぞれ、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６に提供される。

ポート２０は各々、相互接続チャネル１２に関連付けられている仮想チャネルの各々に対して、複数の先入れ先出しバッファ（図示せず）を備える。非排他的実施形態において、４つの仮想チャネルが存在する。その場合、各仮想チャネルに対して１つで、各ポート２０は、４つのバッファを備える。再び、ポート２０に含まれる仮想チャネルおよびバッファの数は、様々であってよく、４に限定されないことを理解されたい。逆に、仮想チャネルおよびバッファの数は、４より多くても少なくてもよい。

所与のトランザクションが２つ（以上）の部分で表される場合、それらの部分は、同じバッファ内に維持される。例えば、相互接続１２が１２８データビット幅であり、トランザクションが５１２ビットのペイロードを含むパケットによって表される場合、トランザクションは、４クロックサイクルまたはビートで伝送される４つの部分に分割される必要がある。一方、トランザクションが６４ビットのペイロードを有する単一パケットによって表されうる場合、単一の部分は、１クロックサイクルまたはビートで伝送されうる。所与のトランザクションのすべての部分を同じバッファ内に維持することにより、仮想チャネルは、論理的に独立したままになる。換言すると、所与のトランザクションに関連するトラフィックすべてが、常に、ストリームと同じ仮想チャネルで送信され、複数の仮想チャネルを介して分岐されることがない。

アービトレーション要素２６は、様々なアクセスポート２０によって維持されたトランザクションの競合するバッファされた部分の間でアービトレートすることを担う。非排他的実施形態において、複数の競合トランザクションが利用可能であれば、アービトレーション要素２６は、クロックサイクルごとにアービトレーションを実行する。サイクルごとのアービトレーション勝者は、相互接続１２へのアクセスが認められて相互接続１２を介して伝送されるトランザクションの部分を、サブシステムＩＰ１、ＩＰ２、および、ＩＰ３の内の１つから生成する。

トランザクションを生成する時、送信元サブシステムＩＰ１、ＩＰ２、および、ＩＰ３は、通常、可能な宛先サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６についてアドレス空間内のアドレスを知っているが、宛先にトランザクションをルーティングするために必要な情報（例えば、ポートＩＤ２０および／または２２）を知らない。一実施形態において、ローカルアドレス解決ロジック（ＡＲＬ）２８は、既知の宛先アドレスを必要なルーティング情報に解決するために用いられる。換言すると、送信元サブエージェント１４は、システムメモリ２４内の所与のアドレスにアクセスしたいことを単に知りうる。したがって、ＡＲＬ２８は、ＬＵＴ３０へアクセスするタスクを課せられ、指定されたアドレスに対応する最終的な宛先への配信パスに沿ってポート２０／２２のアドレスルックアップを実行する。ポート２０／２２が知られると、この情報は、トランザクションのパケット内の宛先フィールドに挿入される。結果として、パケットは、配信パスに沿ってポート２０／２２へ配信される。原則として、要求された配信情報がすでに知られており、パケットの宛先フィールドに含まれているので、配信パスに沿ったダウンストリームノードが、さらなるルックアップを実行する必要はない。後に詳述するようにソースベースルーティング（ＳＢＲ）と呼ばれる他のタイプのトランザクションで、送信元Ｐエージェントは、宛先ポートアドレスを知る。結果として、ＡＲＬ２８によって実行されるルックアップは、典型的には、実行される必要がない。

代替実施形態において、相互接続内のすべてのノードがＡＲＬ２８およびＬＵＴ３０を必要とするわけではない。これらの要素を持たないノードについては、必要なルーティング情報のないトランザクションが、デフォルトノードへ転送されうる。デフォルトノードでは、ＡＲＬ２８およびＬＵＴ３０がアクセスされ、次いで、必要なルーティング情報が、トランザクションのパケットのヘッダに挿入されうる。デフォルトノードは、典型的には、ＡＲＬ２８およびＬＵＴ３０を持たないノードよりアップストリームにある。ただし、これは、決して必須ではない。１または複数のデフォルトノードは、ＳｏＣ上のどこに配置されてもよい。ＡＲＬ２８およびＬＵＴ３０をいくつかのノードから排除することにより、ノードの複雑さを低減できる。

ＡＲＬ２８は、トランザクションの勝利部分のための転送先のデコードに加えて、各仮想チャネル内のトランザクションの勝利部分のための順序を規定するので、「順序付けポイント」と呼ばれてもよい。各アービトレーションが解決されると、ＡＲＬ２８がアドレスポートルックアップを実行するために用いられるか否かに関わらず、トランザクションの勝利部分が各仮想チャネルに提供される先入れ先出しキューに挿入される。次いで、トランザクションの勝利部分は、バッファ内で相互接続１２を介した伝送の順番を待つ。

また、ＡＲＬ２８は、「アップストリーム」および「ダウンストリーム」トラフィックを規定するために用いられる。換言すると、スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）によって生成された任意のトランザクションは、ＡＲＬ２８に対してアップストリームにあると見なされる。ＡＲＬ２８後の（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６に伝送される）すべてのトランザクションが、ダウンストリームトラフィックと見なされる。

スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）は、直接的または間接的のいずれかで、互いに通信してトランザクションを互いに送信してよい。直接的な通信（しばしば、ソースベースルーティング（ＳＢＲ）と呼ばれる）により、ＩＰエージェント１４は、ピアツーピアモデルで互いにトランザクションを送信できる。このモデルでは、送信元ＩＰエージェトは、そのピアＩＰエージェント１４の一意ポートＩＤが知っており、ＬＵＴ３０にアクセスするためにＡＲＬ２８を用いる必要性を無くす。あるいは、スイッチ１６に関連付けられているＩＰエージェントの間のトランザクションは、ＡＲＬ２８を用いてルーティングされてもよい。このモデルでは、上述したのと同様に、送信元ＩＰエージェントは、宛先ＩＰエージェント１４のアドレスのみを知り、ルーティングに必要な情報は知らない。次いで、ＡＲＬ２８は、ＬＵＴ３０にアクセスし、対応するポートＩＤを見つけるために用いられ、その後、ポートＩＤは、トランザクションのパケットの宛先フィールドに挿入される。

パケットフォーマット
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマットを有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、または、ペイロードが全く無くてもよい。

図２を参照すると、パケットの例３２が示されている。パケット３２は、ヘッダ３４およびペイロード３６を備える。この特定の実施形態において、ヘッダ３４は、１６バイトのサイズである。このサイズは例示であり、より大きいサイズ（例えば、より多いバイト数）または小さいサイズ（例えば、より少ないバイト数）のパケットが用いられてもよいことを理解されたい。パケット３２のヘッダ３４は、必ずしもすべてが同じサイズである必要がないことも理解されたい。代替実施形態において、ＳｏＣにおけるパケットヘッダのサイズは、可変であってもよい。

ヘッダ３４は、宛先識別子（ＤＳＴ＿ＩＤ）、送信元識別子（ＳＲＣ＿ＩＤ）、ペイロードサイズインジケータ（ＰＬＤ＿ＳＺ）、予備フィールド（ＲＳＶＤ）、コマンドフィールド（ＣＭＤ）、ＴＡＧフィールド、ステータス（ＳＴＳ）、トランザクションＩＤフィールド（ＴＡＧ）、アドレスすなわちＡＤＤＲフィールド、ＵＳＤＲ／コンパクトペイロードフィールド、トランザクションクラスすなわちＴＣフィールド、フォーマットＦＭＴフィールド、および、バイトイネーブル（ＢＥ）フィールドなど、複数のフィールドを含む。ヘッダ３４の様々なフィールドについて、以下の表３で簡単に説明する。

ペイロード３６は、パケットのコンテンツを含む。ペイロードのサイズは、様々であってよい。いくつかの例において、ペイロードは大きくてよい。その他の例において、ペイロードは小さくてもよい。さらに別の例において、コンテンツが非常に小さいすなわち「コンパクト」である場合、ヘッダ３４のＵＳＲＤフィールド内で運ぶことができる。

トランザクションのタイプは、しばしば、トランザクションを表すために用いられる１以上のパケットがペイロードを持つか否かを示す。例えば、ＰｏｓｔｅｄまたはＮｏｎ−ｐｏｓｔｅｄ読み出しのどちらでも、パケットは、アクセスされるロケーションアドレスを指定するが、典型的には、ペイロードを持たない。しかしながら、関連するＣｏｍｐｌｅｔｉｏｎトランザクションのパケットは、読み出しコンテンツを含むペイロードを含む。ＰｏｓｔｅｄおよびＮｏｎ−ｐｏｓｔｅｄ書き込みトランザクションの両方で、パケットは、宛先に書き込まれるデータを含むペイロードを含む。Ｎｏｎ−ｐｏｓｔｅｄバージョンの書き込みでは、Ｃｏｍｐｌｅｔｉｏｎトランザクションのパケットは、通常、ペイロードを定義しない。しかしながら、一部の状況では、Ｃｏｍｐｌｅｔｉｏｎトランザクションが、ペイロードを規定する。

パケットの例および上述の説明は、パケットに含まれうる基本的なフィールドの多くを網羅している。さらなるフィールドが削除または追加されてもよいことを理解されたい。例えば、送信元および宛先がプライベートメッセージを共有できるように、プライベートシグナリングフィールドが用いられてもよい。

アービトレーション
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。

ＰＣＩ順位付けでは、各ポート２０は、各仮想チャネルおよびトランザクションクラス（Ｐ、ＮＰ、および、Ｃ）の組み合わせのための別個のバッファを備える。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ０１、ＶＣ２、および、ＶＣ３）がある場合、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２は各々、１２の先入れ先出しバッファを有する。換言すると、各ポート２０について、バッファが、各トランザクションクラス（Ｐ、ＮＰ、および、Ｃ）ならびに仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３０）の組み合わせに対して提供される。

各ＩＰエージェント１４（例えば、ＩＰ１、ＩＰ２、および、ＩＰ３）がトランザクションを生成すると、結果として得られるパケットが、それぞれ、対応するポート（例えば、ポート０、ポート１、および、ポート２）内で、トランザクションタイプに基づいて、適切なバッファに配置される。例えば、ＩＰ１によって生成されたＰｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションが、それぞれ、ポート０内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ−ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに配置される。ＩＰ２およびＩＰ３によって生成されたトランザクションは、同様の方法でポート１およびポート２内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ−ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに同様に配置される。

所与のトランザクションが複数のパケットによって表される場合、そのトランザクションのパケットすべてが、同じバッファ内に挿入される。結果として、トランザクションのパケットすべてが、最終的に同じ仮想チャネルで伝送される。このポリシーでは、仮想チャネルは独立したままであり、これは、同じトランザクションに関連する複数のパケットの伝送には、異なる仮想チャネルが用いられないことを意味する。

各ポート２０内で、多くの異なる方法で所与の仮想チャネルにパケットを割り当てることができる。例えば、割り当ては、無作為であってよい。あるいは、割り当ては、各仮想チャネルに対する作業負荷と未処理のトラフィックの量とに基づいてもよい。あるチャネルが非常にビジーであり、その他のチャネルがビジーではない場合、ポート２０は、しばしば、負荷のバランスを取ろうと試み、新たに生成されたトランザクショントラフィックを利用率の低い仮想チャネルに割り当てる。結果として、ルーティング効率が改善される。さらに別の代替例において、トランザクショントラフィックは、緊急性、セキュリティ、または、それら両方の組み合わせに基づいて、特定の仮想チャネルに割り当てられてもよい。特定の仮想チャネルが、他の仮想チャネルよりも高い優先度および／またはセキュリティを与えられた場合、高い優先度および／または安全なトラフィックが、より高い優先度の仮想チャネルに割り当てられる。さらに別の実施形態において、ポート２０は、ハードコードされてもよく、これは、ポート２０が、１つだけの仮想チャネルを有し、ポート２０によって生成されたすべてのトラフィックが、その１つの仮想チャネルを介して伝送されることを意味する。さらに別の実施形態において、割り当ては、宛先ポート２０に到達するように選択されたルートに基づきうる。

さらに別の実施形態において、仮想チャネルの割り当ては、送信元ＩＰエージェント１４によって、単独で、または、それに対応するポート２０と連携して、実施されてもよい。例えば、送信元ＩＰエージェント１４が、対応するポート２０への制御信号を生成して、所与のトランザクションのパケットが特定の仮想チャネルに割り当てられることを要求することができる。ＩＰエージェント１４も、上述のように、無作為である、ハードコードされる、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいた割り当て決定をなすことができる。

アービトレーション勝者の選択において、アービトレーション要素２６は、サイクルごとに複数のアービトレーション工程を実行する。これらのアービトレーション工程は、以下を含む。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。

上述の順序（１）、（２）、および、（３）は、固定ではない。逆に、上述の３つの工程は、任意の順序で完了されてよい。どの順序が用いられるかに関わらず、単一のアービトレーション勝者が各サイクルで選択される。次いで、勝利トランザクションは、相互接続１２に関連付けられている対応する仮想チャネルを介して伝送される。

アービトレーション要素２６によって実行される各アービトレーション（１）、（２）、および、（３）のために、複数のアービトレーションスキームまたはルールセットが用いられてよい。かかるアービトレーションスキームは、厳密または絶対優先度、４つの仮想チャネルの各々が特定の割合のトランザクショントラフックを割り当てられる重み付き優先度、もしくは、トランザクションが所定の順序で仮想チャネルに割り当てられるラウンドロビンスキーム、を含みうる。さらなる実施形態において、その他の優先度スキームが用いられてもよい。また、アービトレーション要素２６は、異なるアービトレーションスキームの間で時々動的に切り替えを行ってもよい、および／または、（１）、（２）、および、（３）アービトレーションの各々に対して同じまたは異なるアービトレーションスキームをそれぞれ用いてもよいことを理解されたい。

任意選択的な実施形態において、所与のアービトレーションサイクル中に考慮された未処理のトランザクションによって定義された宛先ポート２０の利用可能性が考慮される。宛先ポート２０に内のバッファが、所与のトランザクションを処理するために利用可能なリソースを持たない場合、対応する仮想チャネルは利用可能ではない。結果として、当該トランザクションは、アービトレーションで競合せず、むしろ、目標リソースが利用可能になる後続のアービトレーションサイクルまで待機する。一方、目標リソースが利用可能である場合、対応するトランザクションは、アービトレートされ、相互接続１２へのアクセスのために競合する。

宛先ポート２０の利用可能性は、上述した複数のアービトレーション工程（１）、（２）、および、（３）に関して、異なる時にチェックされてよい。例えば、利用可能性チェックは、アービトレーションサイクルの前に（すなわち、工程（１）、（２）、および、（３）のいずれかの完了の前に）実行できる。結果として、利用可能な宛先リソースを規定するトランザクションのみが、後続のアービトレーション中に考慮される。あるいは、アービトレーションチェックは、アービトレーション工程が実行される順序に関わらず、３つのアービトレーション工程（１）、（２）、および、（３）のいずれかの間に実行されてもよい。

アービトレーション処理中の早くまたは遅くに、宛先リソース利用可能性チェックを実行することには利点および不利点がある。早くチェックを実行することにより、トランザクションの競合の可能性のある部分は、それらの宛先が利用可能でない場合に競合から潜在的に排除されうる。しかしながら、利用可能性を早く知ることは、システムリソースへのかなりの量のオーバーヘッドを生み出しうる。結果として、状況に応じて、所与のアービトレーションサイクル中に利用可能性チェックをより遅く実行するのが、より実際的でありうる。

トランザクションクラスの選択を含むアービトレーション工程に対して、複数のルールが、Ｎ、ＮＰ、および、Ｃトランザクションの競合部分の間でアービトレートするために規定される。これらのルールは、以下を含む。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
−Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い越しえない。
−Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越すことができなければならない。
−Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ ｏｒｄｅｒ）モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要があり、ルールは緩めることができない。
−Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが、例外が認められうる。
Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
−Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
−Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
−Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。

以下の表４は、ＰＣＩ順序付けルールの概要を提供する。（ａ）および（ｂ）の選択肢のないボックスでは、厳密順序付けルールが従われる必要はない。（ａ）および（ｂ）の選択肢を有する表のボックスでは、ＲＯビットがリセットされるか設定されるかに依存して、それぞれ、厳密順序（ａ）ルールまたは緩和順序（ｂ）ルールのいずれかが適用されてよい。様々な代替実施形態において、ＲＯビットは、グローバルに、または、パケットレベルで個々に、設定または再設定されうる。

アービトレーション要素２６は、特定の順序なしに、それぞれ、競合ポート２０、仮想チャネル、および、トランザクションクラスのアービトレーションを実行することによって、最終的な勝利トランザクション部分を選択する。サイクルあたりの勝利部分は、共有相互接続１２にアクセスし、対応する仮想チャネルを介して伝送される。

図３Ｂを参照すると、デバイス順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。アービトレーション処理、および、おそらくは利用可能な宛先リソースの考慮は、２つの違いを除けは、上述したのと基本的に同じである。

第１に、デバイス順序付けでは、（ａ）すべての要求に対する応答が求められるＮｏｎ−ｐｏｓｔｅｄ読み出しまたは書き込みトランザクションと、（ｂ）要求された応答を規定したＣｏｍｐｌｅｔｉｏｎトランザクションとを含め、２つトランザクションクラスだけが定義される。トランザクションクラスが２つだけなので、各ポート２０において仮想チャネルごとに２つのバッファだけがある。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）がある場合、各ポート２０（例えば、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２）は、合計で８つのバッファを有する。

第２に、デバイス順序付けのトランザクションを選択するためのルールも、ＰＣＩ順序付けとは異なる。デバイス順序付けでは、オーバークラスを超える１つのクラスの選択に適用される厳密なルールは存在しない。逆に、いずれかのトランザクションクラスが任意に選択されうる。しかしながら、一般的な方法では、典型的には、Ｃｏｍｐｌｅｔｉｏｎトランザクションが解決するまで利用可能になりえないリソースを解放するように、好都合なＣｏｍｐｌｅｔｉｏｎトランザクションに要求する。

それ以外の点では、デバイス順序付けのためのアービトレーション処理は、基本的に上述したものと同じである。換言すると、各アービトレーションサイクルに対して、アービトレーション勝者を選択するために、アービトレーション工程（１）、（２）、および、（３）が、任意の特定の順で実行される。トランザクションクラスアービトレーションが実行される時、ＰＣＩ順序ルールよりはむしろデバイス順序が利用される。さらに、宛先リソースおよび／または仮想チャネルの利用可能性が、アービトレーション工程（１）、（２）、および、（３）のいずれかの前または間に考慮されてもよい。

動作フローチャート
先述したように、上述のアービトレーションスキームは、任意の共有リソースへのアクセスを共有するために利用されてよく、共有相互接続との利用だけに限定されない。かかる他の共有リソースは、ＡＲＬ２８、処理リソース、メモリリソース（ＬＵＴ３０など）、または、アクセスをめぐって競い合う複数のパーティの間で共有されるほぼ任意のその他のタイプのリソースを含みうる。

図４を参照すると、共有リソースへのアクセスをアービトレートするための動作工程を示すフローチャート４０が示されている。

工程４２において、様々な送信元サブシステムエージェント１４が、トランザクションを生成する。トランザクションは、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む３つのクラスのいずれかでありうる。

工程４４において、送信元サブシステムエージェント１４によって生成されたトランザクションの各々は、パケット化される。先述したように、所与のトランザクションのパケット化は、１以上のパケットをもたらしうる。パケットは、サイズが様々であってよく、一部のパケットは大きいペイロードを持ち、他のパケットは小さいペイロードを持つかまたは全く持たない。トランザクションが、相互接続１２の幅よりも小さいデータペイロード３６を有する単一のパケットによって表される状況では、トランザクションは、単一の部分によって表されうる。トランザクションが、共有リソースのアクセス幅よりも大きいデータペイロード３６を備えた複数のパケットまたは単一のパケットによって表される状況では、複数の部分が、トランザクションを表すために必要とされる。

工程４６において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、対応するポート２０を介してローカルスイッチ１６に投入される。ポート２０内で、各トランザクションのパケットは、仮想チャネルに割り当てられる。先述したように、割り当ては、無作為であるか、ハードコードされるか、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいてよい。

工程４８において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、それぞれ、両方のトランザクションクラスによっておよびそれらに割り当てられた仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）によって、適切な先入れ先出しバッファに格納される。先に述べたように、仮想チャネルは、厳密または絶対優先度、ラウンドロビン、重み付き優先度、最長時間未サービス（ｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｓｅｒｖｉｃｅｄ）など、多くの異なる優先度スキームの１つによって割り当てられてよい。所与のトランザクションが複数の部分を有する場合、各部分は、同じバッファ内に格納される。結果として、所与のトランザクションの複数の部分は、相互接続１２に関連付けられている同じ仮想チャネルで伝送される。トランザクション部分が投入されると、各バッファ内のコンテンツアイテム数を追跡するための対応するカウンタがデクリメントされる。特定のバッファが満たされた場合、そのカウンタはゼロにデクリメントされ、これは、バッファがさらなるコンテンツをもはや受け入れることができないことを意味する。

工程５０、５２、および、５４において、第１、第２、および、第３レベルアービトレーションが実行される。先述したように、ポート２０、仮想チャネル、および、トランザクションクラスの選択は、任意の順序で実行されてよい。

要素５６が、第１、第２、および、第３レベルのアービトレーションの実行に用いられるルールを維持するために用いられてよい。各ケースにおいて、要素５６は、アービトレーションレベルの各々を解決するのに必要に応じて用いられる。例えば、要素５６は、ＰＣＩおよび／またはデバイス順序付けルールを維持してよい。要素５６は、いくつかの優先度スキーム（厳密または絶対優先度、重み付き優先度、ラウンドロビンなど）を実行するためのルールと、所与のアービトレーションサイクルでどれを用いるかを決定するためのロジックまたはインテリジェンスと、を備えてもよい。

工程５８において、アービトレーションの勝者が決定される。工程６０において、勝利部分は、共有リソースにアクセスするために用いられるバッファ内に配置され、バッファに関連付けられているカウンタがデクリメントされる。

工程６２において、勝利部分に関連するバッファは、勝利部分がもはやバッファ内にはないのでインクリメントされる。

工程６４において、勝利部分は、共有リソースへアクセスする。アクセスが完了すると、共有リソースのためのバッファがインクリメントされる。

工程４２〜６４は、それぞれ、連続するクロックサイクル中に連続的に繰り返される。異なる勝利部分として、各々が共有リソースへアクセスする。

インターリービング−例１
トランザクションは、いくつかのモードの内の１つで相互接続１２を介して伝送されうる。

「ヘッダインライン（ｈｅａｄｅｒ ｉｎ−ｌｉｎｅ）」モードと呼ばれる１つのモードでは、トランザクションのパケット３２のヘッダ３４は、常に、それぞれ、別個の部分またはビートでペイロード３６の前に最初に伝送される。ヘッダインラインモードは、相互接続１２のデータビット数Ｎに対するヘッダ３４および／またはペイロード３６の相対サイズに応じて、相互接続１２で利用可能なビットを浪費する場合としない場合がある。例えば、５１２ビット幅（Ｎ＝５１２）である相互接続１２と、１２８ビットのヘッダおよび２５６ビットのペイロードを有するパケットと、を考える。このシナリオでは、１２８ビットのヘッダが第１部分またはビートで伝送され、相互接続１２の残りの３８４ビットの帯域幅は利用されない。第２部分またはビートでは、２５６ビットのペイロード３６が伝送され、相互接続１２の残りの２５６ビットは利用されない。この例では、相互接続の帯域幅のかなりの割合が、２つのビート中に利用されない。一方、トランザクションのパケットのほとんどが相互接続以上のサイズである場合、浪費される帯域幅の程度は、削減されるかあるいは解消される。例えば、３８４または５１２ビットであるヘッダおよび／またはペイロードでは、浪費の量は、大幅に削減されるか（例えば、３８４ビット）または全く解消される（例えば、５１２ビット）。

「ヘッダオンサイドバンド（ｈｅａｄｅｒ ｏｎ ｓｉｄｅ−ｂａｎｄ）」と呼ばれる別のモードでは、パケットのヘッダ３４は、データの「サイドで」伝送され、これは、ペイロード３６が相互接続１２のＮデータビットで伝送される間に、制御ビットＭを利用することを意味する。ヘッダオンサイドバンドモードでは、パケット３２のペイロード３６のビット数またはサイズは、所与の相互接続１２でパケットを伝送するのに必要なビート数を決定する。例えば、６４、１２８、２５６、または、５１２ビットのペイロード３６を有するパケット３２、ならびに、１２８データビット（Ｎ＝１２８）を有する相互接続１２の場合、パケットは、それぞれ、１、１、２、および、４ビートを必要とする。ビートの各々の伝送では、ヘッダ情報は、相互接続１２のＮデータビットでペイロードのデータと共にまたはその「サイドで」制御ビットＭで伝送される。

さらに別のモードにおいて、パケット３２のヘッダ３４は、ペイロードと同じように伝送されるが、ヘッダ３４およびペイロード３６が別個の部分またはビートで伝送されなければならない要件はない。パケット３２が、１２８ビットのヘッダ３４および１２８ビットのペイロード３６を有する場合、合計サイズは、２５６ビット（１２８＋１２８）である。相互接続１２のＮデータビットが、６４、１２８、２５６、および、５１２ビット幅である場合、２５６ビットのパケットは、それぞれ、４、２、１、および、１ビートで伝送される。別の例において、パケット３２は、１２８ビットのヘッダおよび２５６ビットのペイロード３６、すなわち、３８４ビット（１２８＋２５６）の合計パケットサイズを有する。６４、１２８、２５６、または、５１２幅のＮデータビットの同じ相互接続１２では、パケットは、それぞれ、６、３、２，または、１ビートで伝送される。このモードは、常に、上述のヘッダインラインモードと少なくとも同等以上の効率である。

図５を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第１例が図示されている。この例では、簡単のために、２つのトランザクションのみが示されている。２つのトランザクションは、この例では、１２８データビット幅（Ｎ＝１２８）である共有相互接続１２へのアクセスをめぐって競合している。２つのトランザクションの詳細は、以下を含む。
（１）トランザクション１（Ｔ１）：時刻Ｔ１に生成され、仮想チャネルＶＣ２に割り当てられている。Ｔ１のサイズは、４ビートであり、それらのビートは、Ｔ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄとして指定されている。
（２）トランザクション２（Ｔ２）：時刻Ｔ２（時刻Ｔ１の後）に生成され、仮想チャネルＶＣ０に割り当てられている。Ｔ２のサイズは、単一の部分またはビートである。

この例では、ＶＣＯに絶対または厳密優先度が割り当てられている。複数のサイクルにわたって、２つのトランザクションＴ１およびＴ２の部分が、以下に従って、図５に示すように、共有相互接続で伝送される。
サイクル１：Ｔ１のビートＴ１Ａは、唯一の利用可能なトランザクションであるので、ＶＣ２で伝送される。
サイクル２：Ｔ１のビートＴ１ＢおよびＴ２の単一部分は、相互接続１２へのアクセスをめぐって競合する。ＶＣＯは厳密優先度を有するので、Ｔ２が自動的に勝利する。したがって、Ｔ２のビートは、ＶＣ０で伝送される。
サイクル３：競合するトランザクションがないので、Ｔ１のビートＴ１ＢがＶＣ２で伝送される。
サイクル４：競合するトランザクションがないので、Ｔ１のビートＴ１ＣがＶＣ２で伝送される。
サイクル５：競合するトランザクションがないので、Ｔ１のビートＴ１ＤがＶＣ２で伝送される。

この例は、以下を示す。（１）絶対優先度を有する仮想チャネルでは、他のトラフィックが先に待っていたか否かに関わらず、トラフィックが利用可能になればいつでも、共有相互接続１２へのアクセス権が即座に与えられること、ならびに、（２）異なるトランザクションの勝利部分またはビートは、相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送されること。この例において、仮想チャネルＶＣＯは、絶対優先度を与えられている。絶対または厳密優先度スキームでは、仮想チャネルのいずれかが、最高優先度を割り当てられてよいことを理解されたい。

インターリービング−例２
図６を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第２例が図示されている。

この例において、相互接続１２へのアクセスのための優先度スキームは重み付けされており、これは、ＶＣＯが（４０％）の確率でアクセス権を与えられ、ＶＣ１〜ＶＣ３が各々（２０％）の確率でアクセス権を与えられることを意味する。また、相互接続は、１２８ビット幅である。

さらに、この例においては、４つの競合するトランザクションＴ１、Ｔ２、Ｔ３、および、Ｔ４が存在する。
−Ｔ１は、ＶＣ０に割り当てられ、４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄを含む。
−Ｔ２は、ＶＣ１に割り当てられ、２つの部分またはビートＴ２ＡおよびＴ２Ｂを含む。
−Ｔ３は、ＶＣ２に割り当てられ、２つの部分またはビートＴ３ＡおよびＴ３Ｂを含む。
−Ｔ４は、ＶＣ３に割り当てられ、２つの部分またはビートＴ４ＡおよびＴ４Ｂを含む。

この例では、優先度スキームは重み付けされる。結果として、各仮想チャネルは、その重みの比率に従って勝利する。換言すると、１０サイクルの間に、ＶＣ０は、４回勝利し、ＶＣ１、ＶＣ２、および、ＶＣ３は各々、２回勝利する。例えば、図６に示すように、
−Ｔ１の４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄは、１０サイクルのうちの４サイクル（４０％）（すなわち、サイクル１、４、７、および、１０）でＶＣＯを介して伝送される。
−Ｔ２の２つの部分またはビートＴ２ＡおよびＴ２Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル２およびサイクル６）でＶＣ１を介して伝送される。
−Ｔ３の２つの部分またはビートＴ３ＡおよびＴ３Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル５およびサイクル９）でＶＣ２を介して伝送される。
−Ｔ４の２つの部分またはビートＴ４ＡおよびＴ４Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル３およびサイクル８）でＶＣ３を介して伝送される。

したがって、この例は、以下を示す。（１）各仮想チャネルが所定の比率に基づいて相互接続１２へのアクセス権を与えられる重み付き優先度スキーム、ならびに、（２）異なるトランザクションの勝利部分が相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送される別の例。

この重み付けの例では、重み付け比率に従って様々な仮想チャネルにトランザクションの部分を割り当てられるのに十分なトラフィックがあることを理解されたい。その一方でトラフィックの量が不十分である場合、重み付け比率は、厳密に実施できる場合も厳密に実施できない場合もある。例えば、仮想チャネルＶＣ３に大きいトラフィックがあり、その他の仮想チャネルＶＣ０、ＶＣ１、および、ＶＣ２ではトラフィックが限られているか全くない場合、ＶＣ３は、重み付け比率が厳密に実施されれば、トラフィックの全部または大部分を運ぶことになる。しかしながら、結果として、すべてのクロックサイクルまたはビートでトランザクションの部分を送信できるわけではないので、相互接続１２は、十分に利用されえない。一方、重み付け比率が厳密に実施されない場合、相互接続の利用率をあげるために、トランザクショントラフィックを再割り当てすることが可能である（例えば、トラフィックが、より多い数のサイクルまたはビートで送信される）。

上記の２つの例は、上述した伝送モードのどれが利用されるかに関わらず適用可能である。トランザクションが部分またはビートに分割されると、それらは、本明細書で規定したアービトレーションスキームのいずれかを用いて共有相互接続１２でインターリーブされて伝送されうる。

上述したアービトレーションスキームは、ほんの数例である。その他の例では、低ジッタ、重み付け、厳密、ラウンドロビン、または、ほぼ任意のその他のアービトレーションスキームが用いられてもよい。したがって、本明細書に列挙または記載されたアービトレーションスキームは、例示であり、どのようにも限定と見なされるべきではない。

複数の同時アービトレーション
ここまで、簡単のために、単一のアービトレーションのみを記載していた。しかしながら、現実的な応用例（ＳｏＣ上など）では、複数のアービトレーションが同時に行われうることを理解されたい。

図７を参照すると、スイッチ１６、１８の間において２方向でトラフィックを処理するための２つの共有相互接続１２および１２Ｚのブロック図が示されている。上述したように、スイッチ１６は、共有相互接続１２を介して送信元サブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先サブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクショントラフィックを方向付ける。逆方向のトランザクショントラフィックを扱うために、スイッチ１８は、アービトレーション要素２６Ｚと、任意選択的にＡＲＬ２８Ｚと、を備える。動作中、要素２６ＺおよびＡＲＬ２８Ｚは、上述した動作と相補的に動作し、これは、送信元ＩＰエージェント１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）によって生成されたトランザクショントラフィックがアービトレートされて、共有相互接続１２Ｚを介して宛先ＩＰエージェント（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）へ送信されることを意味する。あるいは、アービトレーションは、ＡＲＬ２８Ｚなしに実行されてもよく、これは、アービトレーションが、単に競合ポート２０（例えば、Ｐｏｒｔ３、Ｐｏｒｔ３またはＰｏｒｔ５）の間で決定を行い、勝利ポートに関連するトランザクションの部分が、その部分の最終的な宛先に関わらず、相互接続１２で伝送されることを意味する。要素１２Ｚ、２６Ｚ、および、２８Ｚについては、すでに記載したので、簡単のために詳細な説明は、ここでは提供しない。

ＳｏＣには、複数レベルのサブファンクション１４および複数の共有相互接続１２が存在しうる。各々で、上述のアービトレーションスキームを用いて、様々なサブファンクションの間で相互接続１２を介して送信されるトランザクションの間のアービトレーションを同時に行うことができる。

ＩＰエージェントのリセットおよび電力管理
図８を参照すると、リセットおよび電力管理機能を有するＳｏＣ８００のブロック図が示されている。ＳｏＣ８００は、相互接続８０２と、複数のＩＰエージェント１４（例えば、エージェント１〜エージェントＮ）と、相互接続８０２にＩＰエージェント１４を接続または結合する１以上のリンク８０３と、システムコントローラ８０４と、を備える。図示していないが、各ＩＰエージェント１４は、リセット入力命令を受信するための１以上の専用「ハードワイヤ」入力も備えてよい。かかる命令は、複数のソースから（ＳｏＣの外から、システムコントローラ８０４から、または、別のＩＰエージェント１４から、など）もたれされてよい。

様々な実施形態において、ＩＰエージェント１４は、異なっていてよく、様々な異なる機能を実装してよい。

相互接続８０２は、ネットワークオンチップ（ＮｏＣ）、バス、スイッチネットワークなど、様々な異なるタイプの相互接続でありうる。

様々な実施形態において、リンク８０３は各々、各ＩＰエージェント１４と相互接続８０２との間の専用リンクまたはバスであってよい。あるいは、相互接続８０２へのアクセスが、１つのリンク８０３を用いて複数のＩＰエージェント１４の間で共有されてもよく、アービトレーションスキームが、競合ＩＰエージェント１４の間の選択に用いられる。さらに別の実施形態において、複数の仮想チャネルが、先述したように共有リンクに関連付けられている仮想チャネルのように、１以上のリンク８０３に関連付けられてもよい。

システムコントローラ８０４、ならびに、マネージャ８０６、８０８、および、８０９も、多くの異なる方法で実装されてよい。例えば、ＣＰＵまたはマイクロコントローラとして、プログラマブルロジックとして、ＳｏＣ８００上のすべてまたはほとんどのシステム制御機能を扱うための複雑な状態マシン、いくつかの例外状況を扱うための単純な状態マシン、または、それらの任意の組みあわせとして。システムコントローラ８０４は、図に示すように、ＳｏＣ８００上に存在してもよいし、あるいは、ＳｏＣ８００から離れて配置されてもよい（図示せず）。状態マシンが用いられる場合、状態と、状態の間の移行とは、典型的には、ＳｏＣ８００にハードコードされる。

さらに別の実施形態において、リセット、電力、および／または、休止のためのマネージャ８０６、８０８、および、８０９の内の１以上は各々、図に示すように、システムコントローラ８０４内に集中化されてよい。あるいは、各マネージャ８０６、８０８、および／または、８０９は、ＳｏＣ８００上またはＳｏＣ外で、様々な位置に分散化および分配されてもよい。リセットマネージャ８０６、電力マネージャ８０８、および、休止マネージャ８０９の各々は、ソフトウェア、ハードウェア、プログラマブルロジック、状態マシン、または、任意のその他の適切な手段で実装されうる。

リセットマネージャ８０６は、組織的に、リセットからＳｏＣ８００上の様々なＩＰエージェント１４が出る際の管理に関与する。ＩＰエージェント１４のリセットが、多くの状況下で求められるかまたは望まれうる。例えば、ＳｏＣ８００に供給される電力の除去または断絶、もしくは、ＳｏＣ８００のシステム全体のリセットの後に、「コールドリセット」が起きる。あるいは、ＩＰエージェント１４の内の１つ、１グループ、または、全部（コールドリセットと同様）がリセットされるが、電力がＳｏＣ８００から除去または断絶されない場合、「ウォームリセット」が起きる。ウォームリセットは、ＳｏＣ８００上または外部のいずれかに由来するシグナリングによって実施されうる。リセットが開始される方法に関わらず、リセットマネージャ８０６は、組織的に、リセットから１または複数のＩＰエージェント１４が出る際の管理に関与する。

ＩＰエージェント１４が何らかの理由で正常に動作しない場合、リセットする必要がありうる。ＩＰエージェント１４が正常に機能しない例としては、ＩＰエージェント１４が、応答しない、エラー状態である、または、活発にエラートランザクションを生成している状況が含まれる。さらに別の例において、ＩＰエージェント１４は、後述するいくつかの節電モードの１つなど低電力状態から抜けた後に、リセット動作を受ける必要がありうる。

電力マネージャ８０８は、様々なＩＰエージェント１４を低電力状態（典型的には、いくつかの節電モードの１つ）にする処理を管理する。モードに応じて、電力マネージャ８０８は、必要であればＩＰエージェントをリセットするために、リセットマネージャ８０６と連携して動作してよい。

休止マネージャ８０９は、システムコントローラ８０４、リセットマネージャ８０６、電力マネージャ８０８、および、相互接続８０２と連携して動作することで、（１）動作可能または動作不良のＩＰエージェント１４を、ＩＰエージェントが動作不能になるリセットまたは節電モードに移行させ、（２）相互接続とＩＰエージェント８０２との間のリンク８０３を休止状態にし、（３）動作不能の間にＩＰエージェントの代理として動作するように相互接続に指示する。

メモリ８１０は、揮発性および不揮発性タイプのメモリの両方を含みうる。さらに、メモリ８１０は、ＳｏＣ８００上に集中化されてもよいし、システムコントローラ８０４、相互接続８０２、リンク８０３、ならびに、マネージャ８０６、８０８、および／または、８０９の内のいずれか、の間に広く分散されてもよい。さらに別の実施形態において、メモリ８１０の一部または全部が、ＳｏＣ８００から離れて提供されてもよい。

メモリ８１０の揮発性部分は、典型的には、システムメモリに利用され、そこに、システムコントローラ８０４、マネージャ８０６、８０８、８０９、相互接続８０２、ＩＰエージェント１４などによって生成された現在のデータが格納される。かかるメモリは、様々なキャッシュ、ＳＲＡＭ、ＤＲＡＭなどを含みうる。

メモリ８１０の不揮発性または永続的部分は、典型的には、ＳｏＣ８００のための「ブートアップ」コードを格納するために用いられる。ブートコードは、マネージャ８０６、８０８、８０９、相互接続８０２、および、ＩＰエージェント１４を含め、システムコントローラ８０４が各々、電源をオンにした後に動作を開始するのに必要な通りに、オペレーティングシステムおよび／またはその他のシステムソフトウェアをロードすることを可能にする。リブート処理は、典型的には、複数のセルフテストを含み、テストは、完了時に、ＩＰエージェント１４の各々を含むシステム全体が、通常動作を実行することを可能にする。不揮発性または永続的部分は、ＮＶＲＡＭ（不揮発性ランダムアクセスメモリ）、ＥＥＰＲＯＭ（電気消去可能プログラマブルリードオンリーメモリ）、ハードドライブ、ＣＤ−ＲＯＭなどを用いて実装されてよい。

リセットマネージャ８０６は、組織的に、ＩＰエージェント１４のいずれかがリセットから出るのを調整するのに関与する。本明細書に記載のように、所与のＩＰエージェント１４のリセットは、（１）ＳｏＣ８００全体が、外部リセット、リスタートコマンド、または、電源オンイベントの後のリセットから出る時、または、（２）電力ダウンまたはスリープモードの後の動作不良によるＳｏＣ８００の動作中の個々のＩＰエージェント１４のリセットなど、様々な理由で起こりうる。理由に関わらず、所与のＩＰエージェント１４は、内部リセットシーケンスが完了すると、相互接続８０２にいつでも導入できる。リセットから出た後に、ネゴシエーションが、リンク８０３を介して相互接続８０２上でＩＰエージェント１４とそのＩＰポート２０との間で調整される。

図９を参照すると、ＩＰエージェント１４と相互接続８０２との間のＩＰエージェントリセットネゴシエーションシーケンスの一例を示すフローチャートが示されている。

最初の工程９０２において、ＩＰエージェント１４がリセットから出て相互接続８０２に導入される準備ができているか否かが判定される。リセットから出ると、相互接続８０２へＩＰエージェント１４を再導入するために、後続の工程９０４〜９１２が実行される。

工程９０４において、相互接続８０２は、定期的にＩＰエージェント１４についての問い合わせを生成する。各問い合わせで、相互接続８０２は、基本的に、「アウェイク」状態であるか否か（すなわち、トランザクション準備完了状態であるか、つまり、受信したトランザクションを送信または処理できるか否か）をＩＰエージェント１４に尋ねる。

判定９０６において、相互接続は、ＩＰエージェント１４から問い合わせへの肯定応答を受信したか否かを判定する。受信していない場合、相互接続８０２は、問い合わせを送信し続ける。受信した場合、それは、ＩＰエージェント１４が、そのリセットルーチンを部分的に完了して、次のネゴシエーション段階の準備が整っていることを、相互接続８０２に対して示す。

工程９０８において、相互接続８０２およびＩＰエージェント１４は、それぞれ、それらのクレジット情報を交換することによってネゴシエーションを続ける。相互接続８０２およびＩＰエージェント１４は各々、ビートの利用可能数（すなわち、クロックサイクルあたりにリンク８０３で伝送できるデータの量）を交換する。リンク８０３の両側の各パートナーは、交換後、このネゴシエーションの結果として他方が有するクレジットの利用可能数を知る。

任意選択的な工程９１０において、相互接続８０２およびＩＰエージェント１４は、セキュリティクレデンシャル、相互接続８０２およびＩＰエージェント１４を接続するリンク８０３に関連付けることのできる仮想チャネルの合意済みの数など、他の有用な情報を交換することによって、それらのネゴシエーションを続ける。

最後の工程９１２において、ネゴシエーションが完了すると、ＩＰエージェント１４は、「トランザクション準備完了」を宣言される。換言すると、ＩＰエージェント１４は、相互接続８０２から受信した受信トランザクションを処理するか、または、別の宛先へ相互接続８０２を介して送信トランザクション送信するか、いずれかの準備が整っている。ＩＰエージェント１４がトランザクション準備完了状態になると、ＩＰエージェント１４は、相互接続８０２、システムコントローラ８０４、ならびに、直接的に、または、中間回路、ロジック、または、その他の要素を通して間接的に、相互接続８０２に接続または他の方法で結合された任意のその他の要素にとって可視的になる。

また、リセットマネージャ８０６は、動作不良のＩＰエージェント１４のリセットの調整にも関与する。ＳｏＣ８００の動作中、ＩＰエージェント１４は、うまく動作しない場合がある（例えば、応答しなくなる、エラー状態に入る、トランザクションの生成でエラーを起こす、または、他の動作不良を起こす）。例えば、ＩＰエージェントは、受信したトランザクションを処理できない場合がある。結果として、トランザクションを送信する送信元ＩＰエージェントは、応答を待ってハングアップしうる。問題の深刻さによっては、ハングアップは、送信元ＩＰエージェント１４、宛先ＩＰエージェント１４だけに限定されうるが、最悪の場合のシナリオでは、他の部分またはＳｏＣ８００全体にまで、悪影響が及びうる。したがって、特定の状況においては、動作不良のＩＰエージェントは、問題を修正するためにリセットされる必要がありうる。

図１０を参照すると、動作不良のＩＰエージェントのためのリセットシーケンスを示すフローチャート１０００が示されている。

工程１００２では、ＳｏＣ８００上の様々なＩＰエージェント１４が、送信トランザクションを生成するおよび／または受信トランザクションを処理することによって正常に動作する。

判定工程１００４において、システムコントローラ８０４は、ＩＰエージェントの動作を監視する。問題が検出されなければ、ＩＰエージェント１４は、それらの通常動作を継続する。一方、何らかの理由で、ＩＰエージェント１４が正常に動作しない場合、リセットマネージャ８０６が、動作不良ＩＰエージェント１４としてそれにフラグを立てる。

工程１００５において、システムコントローラ８０４および相互接続８０２は、さらに、さらなる課題も問題もなしにＳｏＣ８００の残り部分が動作するのを助けるいくつかの処理を開始するよう協働する。これらのさらなる処理は、以下を含んでよい。
１．システムコントローラ８０４は、動作不良のＩＰエージェント１４によって任意のさらなるトランザクションが生成されることを相互接続８０２が許可しないように要求する。
２．動作不良のＩＰエージェント１４を目標とする未処理のトランザクションを追跡する。
３．相互接続８０２は、リセットネゴシエーション処理を受ける間に動作不良のＩＰエージェント１４の代理として機能し、そのＩＰエージェント１４を目標とする任意のトランザクションへ応答してよい。例えば、相互接続８０２は、未処理のトランザクションに応答して、例外メッセージを生成してよい。代理として機能することにより、トランザクションの送信側が動作不良のＩＰエージェント１４からの応答を決して受信しないためにシステム全体がハングアップするなど、潜在的にはるかに大きいシステム全体の問題が回避される。様々な実施形態において、例外メッセージは、ＩＰエージェント１４が利用できない、ＩＰエージェントは、低電力モードである、など、いくつかの異なるタイプであってよい。一般に、様々な異なるタイプの例外メッセージが用いられてよく、各々が、発生した状態またはエラーを示す。

工程１００６において、リセットマネージャ８０６は、動作不良のＩＰエージェント１４のためのリセット命令を生成する。

工程１００７において、リセットされるＩＰエージェント１４と相互接続８０２との間のリンク８０３は、休止状態にされる。この処理については、図１４に関してさらに説明する。

工程１００８において、動作不良のＩＰエージェント１４は、相互接続８０２を介して受信されるかまたは専用リセットワイヤを介して受信されてもよい命令に応答して、そのリセットルーチンを開始する。この処理は、図９に関して上述したように、ＩＰエージェント１４が、（１）自身のリセットプロトコルまたはルーチンを実行し、（２）相互接続８０２とネゴシエートすること、を含む。

判定工程１０１２において、ＩＰエージェント１４のリセットネゴシエーションが完了したか否かが判定される。完了すると、制御は、工程１００２に戻り、ＩＰエージェント１４およびＳｏＣ８００の動作が正常に再開する。上述のように、リセットされたＩＰエージェント１４は、リセットから出た後に、相互接続８０２およびシステムコントローラにとって可視的になり、トランザクション準備完了状態になる。最後に、工程１０１４において、現在リセットされたＩＰエージェント１４と相互接続８０２との間のリンク８０３は、休止モードを出る。この時点で、相互接続８０２はもはや、ＩＰエージェント１４の代理として機能する必要はない。

電力マネージャ８０８は、ＩＰエージェント１４をいくつかの電力ダウンモードの１つにすることによって、インテリジェントかつ選択的にＩＰエージェント１４を低電力状態にすることに関与する。ＩＰエージェント１４の電力ダウンまたは電力ダウンモードにすることは、様々な理由で実行されうる。

例えば、ＳｏＣ８００がバッテリ式のデバイスで利用される場合、電力マネージャ８０８は、限られたバッテリ電力を節約するために、ＩＰエージェントを電力ダウンモードにしてよい。あるいは、非バッテリ式のデバイスでも、電力マネージャ８０８は、オーバーヒートを防ぐために、重要でないＩＰエージェント１４を低電力モードにしてよい。これらは、電力管理を実施するための可能性のある理由のいくつかに過ぎない。その他の理由としては、１以上のＩＰエージェント１４が利用されていない場合に、それらを電力ダウンモードにすることが含まれうる。様々な代替実施形態において、電力ダウンモードは、以下を含む。
１．低電力モード、動作可能：一代替例において、ＩＰエージェント１４のクロック周波数が、該当する場合に低速化される。あるいは、供給電圧が、該当する場合に低減されてもよい。さらに別の実施形態において、クロック周波数および供給電圧の両方が、該当する場合に低減されて、さらに電力消費を削減してもよい。クロック周波数および／または供給電圧の低減は、該当する場合にのみなされるが、これは、すべてのＩＰエージェント１４が、低減されたクロック周波数、低減された供給電圧、または、それらの両方、のいずれかで動作することができるわけではないことを意味することを理解されたい。さらに別の実施形態において、クロックおよび／または供給電圧を低減するためのコマンドは、該当する場合、ＩＰエージェント１４が低電力動作モードを有することを条件に、システムコントローラ８０４またはＩＰエージェント１４自体から得られうる。
ＩＰエージェントが機能したままなので、相互接続８０２は、このモードでは重要な役割を果たさなくてよく、これは、ＩＰエージェント１４が自身で応答を生成できるので、相互接続８０２が、ＩＰエージェント１４の代理として機能して受信トランザクションのための応答を生成しなくてもよいことを意味する。ただし、ＩＰエージェント１４の実行能力が低クロック周波数での動作時には低下しうるので、システムコントローラ８０４および／または相互接続８０２は、ＩＰエージェント１４のためのリンク８０３の設定を再構成してもよい。おそらく変更されうる設定は、ＩＰエージェント１４のためのアービトレーション設定、または、許可された未処理のトランザクションのカウントの可能な削減を含む。ＩＰエージェントがこの低電力モードを出ると、電圧が（下げられていた場合）最初に上げられ、その後、（下げられていた場合）クロック周波数が増大され、（再構成されていた場合）リンク８０３の設定への任意の変更が通常動作モードに戻される。
２．低電力、動作不能モード、状態情報維持：このモードでは、クロックが停止され、電力供給が低減されるが、完全にはオフにされなくてよい。結果として、ＩＰエージェント１４のメモリ内に維持された状態情報が保持される。このモードに入る前に、相互接続８０２は、新しいトランザクションが開始されるのを防ぐと共に未処理のトランザクションの完了を待つことによって、ＩＰエージェントがすでに発行したトランザクションを「枯渇させる」。すべてのトランザクションが枯渇されると、相互接続８０２は、代理として機能して、動作不良のＩＰエージェント１４の再設定に関して上述したのと同様の処理（１）、（２）、および、（３）を実行してよい。ＩＰエージェントが通常に戻され、このモードを出ると、電圧が最初に上げられ、その後、クロック周波数が増大される。
３．低電力、動作不能モード−状態情報の保持なし：このモードは、ＩＰエージェント内に維持された状態情報が失われる程度まで電圧が下げられることを除けば、すぐ上で説明したモード２と同様である。相互接続８０２は、このモードでは上述したように代理として動作する。電力が戻されると、ＩＰエージェントは、図９に関して上述したのと同様のリセットネゴシエーション処理を受ける必要がある。
４．電力オフモード：このモードでは、クロックがオフにされ、電力は完全に除去される。相互接続８０２は、上述のように代理として動作する。電力アップ時に、供給電圧が最初に上昇され、その後、図９に関して上述したように、リセットネゴシエーション処理が実行される。

図１１は、ＩＰエージェント１４を「低電力、動作可能モード」に出入りさせるためのシーケンスを示すフローチャート１１００である。

最初の工程１１０２において、ＳｏＣ８００上のＩＰエージェント１４は、通常モードで動作するが、これは、標準クロック周波数および電圧が利用されることを意味する。

決定工程１１０４において、ＳｏＣ８００内の条件が、システムコントローラ８０４によって監視される。動作条件が比較的正常であるか、または、ＩＰエージェント１４の電力ダウンをトリガするイベントが発生しない場合、ＳｏＣおよびＩＰエージェント１４は、工程１１０２において通常モードで動作し続ける。しかしながら、トリガ条件が満たされた（例えば、バッテリ供給の低減、オーバーヒートなど）場合、電力マネージャ８０８は、ＩＰエージェント１４を低電力、動作可能モードにすることを選択してよい。

任意選択的な工程１１０６において、相互接続８０２は、リンク８０３を再構成することを選択してよい。再構成は、ＩＰエージェント１４のためのアービトレーション設定を変更すること、または、低電力モードでの動作時にＩＰエージェントの低い処理能力を考慮するために、可能性のある未処理のトランザクションのカウントを削減することを含んでよい。

工程１１０８において、ＩＰエージェント１４の動作クロック周波数が、該当する場合に下げられる。クロック周波数を下げれば、ＩＰエージェントの消費電力は低くなる。

工程１１１０において、ＩＰエージェントに供給される電圧が、該当する場合に下げられる。電圧を下げることにより、さらなる電力節約が実現されうる。

クロック周波数および／または電圧が下げられた状態で、ＩＰエージェント１４は、動作可能のままである。結果として、トラザクションを処理できるが、その標準クロック周波数および／または供給電圧で動作している時にはおそらく低速である。任意選択的な実施形態において、相互接続８０２は、上述したように代理として機能しうるか、もしくは、低電力モードでのＩＰエージェント１４の低い動作速度を考慮してサポートするように調整または再構成されうる。これらの代替例は任意選択的であるため、必ずしも実施する必要はない。

決定工程１１１２において、ＩＰエージェント１４は、通常動作を再開することが決定されるまでは低電力モードで動作する。その場合、ＩＰエージェント１４は、通常動作を再開するためのシーケンスを受ける。

任意選択的な工程１１１４において、電圧は、該当する場合に（すなわち、電圧が以前に下げられた場合に）、標準動作電圧に上げられる。

工程１１１６において、クロック周波数は、該当する場合に（すなわち、クロックが以前に下げられた場合に）、上げられる。工程１１１７において、ＩＰエージェントは、通常動作に戻る。

最後に、任意選択的な工程１１１８において、相互接続は、任意の再構成されている相互接続設定を通常に戻す。この時点で、ＩＰエージェントは、工程１１０２で提供したように、通常動作を再開する準備が整う。

図１２を参照すると、「低電圧、動作不能、状態情報維持モード」でＩＰエージェント１４の電力をダウン／アップさせるためのシーケンスを示すフローチャート１２００が示されている。

工程１２０２において、ＩＰエージェント１４は、その通常モードで動作する。

工程１２０４において、低電力、動作不能、状態情報維持モードでＩＰエージェント１４を動作させる決定がなされる。

工程１２０６において、リンク８０３は、休止状態にされ、相互接続８０２は、ＩＰエージェント１４の代理として動作するよう構成される。これは、典型的には、（１）任意の新しいトランザクションがＩＰエージェント１４によって生成されることを許可せず、（２）任意の未処理のトランザクションが完了するのを待ち、その後、（３）ＩＰエージェント１４を目標とした任意のトランザクションに応答することによって代理として機能することを含む。例えば、相互接続８０２は、非処理のトランザクションの送信元に除外メッセージを送信してよく、おそらく、トランザクションの送信側がＩＰエージェント１４から応答を受信することがないことから起きるハングアップ状況を防ぐ。

工程１２０８において、ＩＰエージェント１４のクロック周波数が、該当する場合に下げられる。

工程１２１０において、ＩＰエージェント１４の動作電圧が、該当する場合に下げられる。しかしながら、電圧は、ＩＰエージェント１４のメモリまたはストレージ要素がそれらの状態情報を維持するように適切なままである。

決定１２１２において、ＩＰエージェント１４は、通常動作を再開すると決定されるまでは低電力状態のままである。システムコントローラ８０４、ＳｏＣの外部のイベント（例えば、センサから受信した信号、外部ソースから受信した信号など）、タイマー、ＩＰエージェント自体、または、別のＩＰエージェントはすべて、ウェイクアップをトリガしうる。この決定がなされると、ＩＰエージェントは、通常動作を再開するためのシーケンスを受ける。

工程１２１４および１２１６において、ＩＰエージェント１４に提供される電圧およびクロック周波数の各々が、該当する場合に上げられる。状態情報が保持されているので、ＩＰエージェント１４は、工程１２１７で通常動作を再開する。

工程１２１８において、リンク８０３は、休止モードにあり、ＩＰエージェントは、トランザクション準備完了状態になり、相互接続８０２は、長く代理として機能する必要があることを通知される。

図１３を参照すると「低電圧、動作不能モード」のためのシーケンスを示すフローチャート１３００が示されている。このシーケンスでは、工程１２０２、１２０６、および、１２１２は、図１２に関して上述した工程と同じである。したがって、これらの工程について、ここでは繰り返し論じない。

工程１３０２において、ＩＰエージェント１４を電力ダウンする決定がなされる。その後、相互接続が代理として構成され（工程１２０６）、工程１３０４において、ＩＰエージェント１４のためのクロックが（該当する場合）完全にオフにされる、および／または、電圧が（該当する場合）状態情報の失われる程度まで大幅に下げられる。状態情報がなければ、工程１２１２において通常動作を再開する決定がなされた場合に、工程１３０６で、電圧は（該当する場合）上昇され、クロックが（該当する場合）オンにされる。その後、ＩＰエージェント１４は、図９に関して上述したように、リセット動作を受ける。リセットが完了すると、ＩＰエージェント１４は、トランザクション準備完了状態になる。次いで、システムは、リンクが工程１３１０で休止モードを出るのを待つ。モードを出ると、ＩＰエージェントは、相互接続８０２上で可視になる。その後、工程１３１２で、相互接続８０２は、もはやＩＰエージェント１４のための代理として機能しない。

最後に、電力オフモードについて、シーケンスは、単に下げられるのと対照的に、電力が完全にオフにされることを除けば、図１３と同じである。それ以外の点では、電力オフモードのシーケンスは同じである。このモードにおいて、ＩＰエージェント１４は、実質的に電力を消費せず、動作不能であり、相互接続８０２は、ＩＰエージェントのために代理として機能してよい。

図１４を参照すると、リンク８０３を休止状態にするための工程を示すフローチャート１４００が示されている。

最初の工程１４０２において、システムコントローラ８０４は、ＩＰエージェント１４がリセットされるべきであるかまたは動作不能な節電モードの１つにされるべきである旨の決定を行う。

工程１４０４において、ＩＰエージェント１４は、トランザクションの生成を停止するよう命令される。

判定１４０６において、システムは、すべての未処理のトランザクションが完了したか否かを判定する。すべての未処理のＮｏｎ−ｐｏｓｔｅｄトランザクションについては、Ｃｏｍｐｌｅｔｉｏｎトランザクションが受信されなければならない（すなわち、読み出しトランザクションでは、アクセスされたデータが返されなければならず、Ｎｏｎ−ｐｏｓｔｅｄ書き込みトランザクションでは、確認応答が受信されなければならない）。Ｐｏｓｔｅｄトランザクションでは、応答トランザクションは求められない。したがって、Ｐｏｓｔｅｄトランザクションは、ＩＰエージェントによって送信されると、「完了」と見なされる。

工程１４０８において、リンク８０３は、すべての未処理のトランザクションが完了した時に、休止状態にされる。その後、相互接続８０２は、ＩＰエージェント１４の代理として構成される。

工程１４１０において、ＩＰエージェントは、リセットまたは所望の動作不能低電力モードのいずれかにされる準備ができる。

図１５Ａ〜図１５Ｄは、ＩＰエージェント「ウェイクアップ」シーケンスのための様々なフローチャートを示す。

図１５Ａを参照すると、エージェントが開始する「ウェイクアップ」シーケンスを示すフローチャート１５００が示されている。この実施形態において、ウェイクアップシーケンスは、ＩＰエージェントによって開始されるが、システムコントローラ８０４によって実施される。

工程１５０２において、動作不能状態のＩＰエージェント１４が、ウェイクアップトリガイベントを検出する。ＩＰエージェントは、電力ダウンまたは「オフ」にされうるが、ウェイクアップトリガが発生した時に検出する能力を維持する意味では、少なくとも部分的には機能したままであってよい。ウェイクアップトリガは、多くの異なるタイプのイベントを含みうる。例えば、ＩＰエージェント１４を所定の期間の後にウェイクアップさせる内部タイマーであってもよいし、ＩＰエージェント１４と通信したい別のデバイスなど、ＳｏＣ８００の外部のイベントであってもよい。工程１５０４において、ＩＰエージェントは、そのリンク８０３を介して相互接続８０２に「ウェイクアップ」通信を送信する。再び、リンクは、それに対応するＩＰエージェント１４が動作不能状態にある時には休止状態であるが、ウェイクアップ信号を相互接続８０２へ送信することができる。

工程１５０６において、相互接続８０２は、動作不能なＩＰエージェントからのウェイクアップ信号を「リッスンする」よう構成される。信号が検出された場合、相互接続８０２は、システムコントローラ８０４へ通知する。

工程１５０８において、システムコントローラ８０４は、ＩＰエージェント１４がそのウェイクアップシーケンスを開始するためのコマンドを相互接続８０２を介して送信してよい。

工程１５１０において、ＩＰエージェントは、コマンドに応答して、ウェイクアップシーケンスを開始する。

上述の実施形態では、ＩＰエージェント１４は、ウェイクアップシーケンスを開始するようシステムコントローラに求める。システムコントローラからのウェイクアップコマンドに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。したがって、システムコントローラは、ＩＰエージェントが、動作不能状態を脱して、相互接続８０２上で可視になると、ＩＰエージェントの状態を知る。

図１５Ｂは、システムコントローラ８０４がＩＰエージェント１４のウェイクアップを開始する場合のシーケンスを示す。このシーケンスでは、システムコントローラ８０４が、工程１５０８でＩＰエージェントにウェイクアップコマンドを送信し、それに応答して、ＩＰエージェントは、工程１５１０で自身のウェイクアップシーケンスを開始する。この実施形態の変形例（図示せず）において、ウェイクアップは、システムコントローラ８０４を介してＳｏＣ８００の外から開始されてもよい。システムコントローラ８０４がコマンドを受信すると、上述の処理が開始される。

図１５Ｃは、ＩＰエージェント１４のためのウェイクアップコマンドが、ＳｏＣ８００の外に由来し、システムコントローラ８０４を通して実施される場合のシーケンスを示す。このシーケンスでは、システムコントローラ８０４は、工程１５１２でコマンドを受信する。それに応答して、システムコントローラは、工程１５０８でＩＰエージェントにウェイクアップコマンドを送信し、それに応答して、ＩＰエージェントは、工程１５１０で自身のウェイクアップシーケンスを開始する。ＳｏＣ８００の外からの直接ウェイクアップでは、コマンドは、ハードワイヤ入力を介してＩＰエージェント１４に直接提供される。それに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。

図１５Ｄを参照すると、ＩＰエージェントが開始して実施するウェイクアップシーケンスを示すフローチャート１５２０が示されている。この実施形態では、ウェイクアップ条件（上述した条件のいずれか、など）が、工程１５２２で発生する。それに応答して、ＩＰエージェントは、工程１５２４で自身のウェイクアップシーケンスを開始する。工程１５２６において、ウェイクアップシーケンスは完了する。その後、工程１５２８において、ＩＰエージェントは、そのアウェイク状態を、相互接続８０２およびシステムコントローラ８０４に、直接的にまたは相互接続８０２を介して通知する。

上記の例においては、簡単のために、単一のＩＰエージェントを上述の低電力モードの１つに移行させるシーケンスについて説明した。実際の実施形態においては、ＳｏＣ上の複数のＩＰエージェント１４が同時に電力ダウンされうる。２以上が同時にまたはほぼ同時に電力ダウンされる場合、各々が独立して、モードに応じて上述のシーケンスの１つを受ける。

いくつかの実施形態についてのみ詳細に説明したが、ここに提供した本開示の精神や範囲を逸脱することなしに多くの他の形態で本願を実施できることを理解されたい。したがって、これらの実施形態は、例示的なものであって、限定的なものではないとみなされ、本明細書に示した詳細に限定されず、添付の特許請求の範囲および等価物の範囲内で変形されてもよい。

Claims (57)

1. システムオンチップ（ＳｏＣ）であって、
   相互接続と、
   前記ＳｏＣ上に備えられ、前記相互接続と通信するよう構成されているＩＰエージェントと、
   前記ＩＰエージェントのリセットを開始するためのリセットマネージャと、を備え、前記リセットは、前記ＩＰエージェントがトランザクション準備完了状態になるようにする前記相互接続と前記ＩＰエージェントとの間のネゴシエーションを含む、ＳｏＣ。
2. 請求項１に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続が前記ＩＰエージェントに対する少なくとも１つの問い合わせを生成することを含み、前記少なくとも１つの問い合わせは、前記ＩＰエージェントの「アウェイク」状態を求める、ＳｏＣ。
3. 請求項１または２に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続が、前記ＩＰエージェントの「アウェイク」状態を各々求める前記ＩＰエージェントに対する複数の問い合わせを生成することを含み、前記複数の問い合わせは、それぞれ、定期的に送信される、ＳｏＣ。
4. 請求項１から３のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前記ＩＰエージェントが、前記ＩＰエージェントの「アウェイク」状態を求める前記相互接続からの問い合わせに応答して肯定応答を生成することを含み、前記肯定応答は、前記ＩＰエージェントがアウェイクしてトランザクション準備完了状態になった時に生成される、ＳｏＣ。
5. 請求項１から４のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続および前記ＩＰエージェントでそれぞれ利用可能なクレジットの交換を含む、ＳｏＣ。
6. 請求項１から５のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続および前記ＩＰエージェントがセキュリティ情報を共有することを含む、ＳｏＣ。
7. 請求項１から６のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続が、前記相互接続と前記ＩＰエージェントとを接続するリンクに関連付けられている複数の仮想チャネルを共有することを含む、ＳｏＣ。
8. 請求項１から７のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションが完了した後に、前記ＩＰエージェントの利用可能性が、システムコントローラを含む前記相互接続に接続された要素に知らされる、ＳｏＣ。
9. 請求項１から８のいずれか一項に記載のＳｏＣであって、さらに、前記相互接続と前記ＩＰエージェントとの間に接続されたリンクを備え、前記ネゴシエーションは、前記リンクを介して前記相互接続と前記ＩＰエージェントとの間で行われる、ＳｏＣ。
10. 請求項１から９のいずれか一項に記載のＳｏＣであって、複数の仮想チャネルが、前記リンクに関連付けられている、ＳｏＣ。
11. 請求項１から１０のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続と前記ＩＰエージェントとの間のリンクを介して伝送されるリンクレベル情報を用いて行われる、ＳｏＣ。
12. 請求項１１に記載のＳｏＣであって、前記リンクレベル情報は、前記相互接続と前記ＩＰエージェントとの間の前記リンクを介して伝送される１以上の制御パケットで伝達される、ＳｏＣ。
13. 請求項１２に記載のＳｏＣであって、前記１以上の制御パケットは、前記相互接続と前記ＩＰエージェントとの間の前記リンクを介して伝送され、別の宛先には転送されない、ＳｏＣ。
14. 請求項１から１３のいずれか一項に記載のＳｏＣであって、前記リセットマネージャは、リセットトリガイベントに応答して、前記ＩＰエージェントの前記リセットを開始する、ＳｏＣ。
15. 請求項１４に記載のＳｏＣであって、前記リセットトリガイベントは、
    前記ＳｏＣの電力アップ、
    前記ＩＰエージェントが動作不良を起こしたこと、または、
    前記ＩＰエージェントが低電力モードから出つつあること、
    の内の１つを含む、ＳｏＣ。
16. 請求項１から１５のいずれか一項に記載のＳｏＣであって、さらに、前記相互接続と前記ＩＰエージェントとの間のリンクを休止状態にするための休止マネージャを備える、ＳｏＣ。
17. 請求項１６に記載のＳｏＣであって、前記休止マネージャは、前記ＩＰエージェントによって生成されたすべての未処理のトランザクションが完了した後に、前記リンクを前記休止状態にするよう構成されている、ＳｏＣ。
18. 請求項１７に記載のＳｏＣであって、前記休止マネージャは、前記未処理のトランザクションが完了するのを待つ間、前記ＩＰエージェントが新しいトランザクションを生成するのを防ぐよう構成されている、ＳｏＣ。
19. 請求項１７に記載のＳｏＣであって、前記休止マネージャは、前記リセットマネージャが前記ＩＰエージェントの前記リセットを開始する前に、前記リンクを前記休止状態にするよう構成されている、ＳｏＣ。
20. システムオンチップ（ＳｏＣ）であって、
    相互接続と、
    複数のＩＰエージェントと、
    前記複数のＩＰエージェントのリセットを実施するよう構成されているリセットマネージャと、を備え、前記複数のＩＰエージェントの各々の前記リセットは、前記相互接続と前記複数のＩＰエージェントの各々との間の個々のネゴシエーションをそれぞれ含み、前記個々のネゴシエーションの結果、それぞれ、前記ＩＰエージェントの各々がトランザクション準備完了状態になる、ＳｏＣ。
21. 請求項２０に記載のＳｏＣであって、前記複数のＩＰエージェントの各々は、自身のリセットルーチンを用いる、ＳｏＣ。
22. 請求項２０または２１に記載のＳｏＣであって、前記複数のＩＰエージェントの各々は、それぞれ自身のタイムスケジュールでトランザクション準備完了状態になる、ＳｏＣ。
23. 請求項２０から２２のいずれか一項に記載のＳｏＣであって、前記複数のＩＰエージェントの各々は、他のＩＰエージェントから独立して、トランザクション準備完了状態になり、すべての前記ＩＰエージェントが、同時にトランザクション準備完了状態になる必要がない、ＳｏＣ。
24. 請求項２０から２３のいずれか一項に記載のＳｏＣであって、前記複数のＩＰ機能の各々のための前記個々のネゴシエーションは、前記ＩＰエージェントが異なるかどうかに関わらず、同じである、ＳｏＣ。
25. 請求項２０から２４のいずれか一項に記載のＳｏＣであって、前記相互接続は、さらに、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態になる前に、動作するよう構成されている、ＳｏＣ。
26. 請求項２５に記載のＳｏＣであって、前記相互接続は、前記少なくとも１つのＩＰエージェントにトランザクションを送信しようとする送信元への例外メッセージを生成することにより、トランザクション準備完了状態になる前の前記少なくとも１つのＩＰエージェントの前記代理として動作する、ＳｏＣ。
27. システムオンチップ（ＳｏＣ）であって、
    複数のＩＰエージェントと、
    前記複数のＩＰエージェントと通信する相互接続であって、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態ではない時に、動作するよう構成されている、相互接続と、
    を備える、ＳｏＣ。
28. 請求項２７に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、リセットを受けている時、トランザクション準備完了状態ではない、ＳｏＣ。
29. 請求項２７または２８に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、電力ダウンモード時には、トランザクション準備完了状態ではない、ＳｏＣ。
30. 請求項２７から２９のいずれか一項に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、動作不良時には、トランザクション準備完了状態ではない、ＳｏＣ。
31. 請求項２７から３０のいずれか一項に記載のＳｏＣであって、前記相互接続は、
    前記少なくとも１つのＩＰ機能がトランザクション準備完了状態ではないことを確認し、
    トランザクション準備完了状態ではない間に前記少なくとも１つのＩＰエージェントに送信元がトランザクションを送信したか否かを確認し、
    前記送信元に例外メッセージを送信して、前記少なくとも１つのＩＰエージェントが利用可能ではないことを前記送信元に通知することによって、前記少なくとも１つのＩＰエージェントの前記代理として機能する、ＳｏＣ。
32. 請求項２７から３１のいずれか一項に記載のＳｏＣであって、前記送信元は、前記例外メッセージに応答して、送信されたが宛先に配信されていないトランザクションについて、自身の応答手順を受ける、ＳｏＣ。
33. 請求項２７から３２のいずれか一項に記載のＳｏＣであって、さらに、前記複数のＩＰエージェントのリセットをそれぞれ開始するためのリセットマネージャを備える、ＳｏＣ。
34. 請求項２７から３３のいずれか一項に記載のＳｏＣであって、前記相互接続は、さらに、前記複数のＩＰエージェント各々がそれぞれリセットされる時に、前記複数のＩＰエージェントの各々との個々のネゴシエーションに関与するよう構成されている、ＳｏＣ。
35. 請求項２７から３４のいずれか一項に記載のＳｏＣであって、前記複数のＩＰエージェントの内の２以上のリセット後に、前記２以上のＩＰエージェントの各々は、それぞれ、個々にリセットし、他のＩＰエージェントから独立してトランザクション準備完了状態になるよう構成されている、ＳｏＣ。
36. 請求項３５に記載のＳｏＣであって、前記２以上のＩＰエージェントの各々は、前記２以上のＩＰエージェントが同時にトランザクション準備完了状態になる必要なしに、自身のタイムスケジュールで独立的にトランザクション準備完了状態になる、ＳｏＣ。
37. 請求項２７から３６のいずれか一項に記載のＳｏＣであって、さらに、システムコントローラを備え、少なくとも１つのＩＰエージェントが、トランザクション準備完了状態になった時に、前記システムコントローラにとって可視になる、ＳｏＣ。
38. システムオンチップ（ＳｏＣ）であって、
    複数のＩＰエージェントと、
    相互接続と、
    前記複数のＩＰエージェントを前記相互接続と接続する１以上のリンクと、
    前記複数のＩＰエージェントの少なくとも１つを選択的に低電力状態にすることによって、前記ＳｏＣによる電力消費を少なくとも部分的に管理するための電力マネージャと、
    を備え、
    前記相互接続は、（ａ）前記低電力状態にあり、かつ、（ｂ）トランザクションの処理に利用できない時に、前記少なくとも１つのＩＰエージェントの代理として機能し、前記相互接続は、前記少なくとも１つのＩＰエージェントに前記トランザクションを送信しようとする送信元へ例外メッセージを提供することによって前記代理として機能する、ＳｏＣ。
39. 請求項３８に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力状態に入る時に、自身の低電力シーケンスを実施する、ＳｏＣ。
40. 請求項３８または３９のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態のままである低電力モードを含む、ＳｏＣ。
41. 請求項４０に記載のＳｏＣであって、前記相互接続は、前記少なくとも１つのＩＰエージェントが前記低電力状態にあり、かつ、トランザクション準備完了状態のままである場合には、代理として機能せず、前記少なくとも１つのＩＰエージェントのためのクロック周波数および／または電圧の低減に対応するために、前記１以上のリンクの内の１つの設定を調整する、ＳｏＣ。
42. 請求項３８から４１のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントがもはやトランザクション準備完了状態ではない低電力モードを含む、ＳｏＣ。
43. 請求項４２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情報を保持する、ＳｏＣ。
44. 請求項４２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情報を保持しない、ＳｏＣ。
45. 請求項３８から４４のいずれか一項に記載のＳｏＣであって、前記低電力状態は、最小限の電力が前記少なくとも１つのＩＰエージェントに供給される電力オフモードを含む、ＳｏＣ。
46. 請求項３８から４５のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げることによって実施される、ＳｏＣ。
47. 請求項３８から４６のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントによって利用される電圧を下げることによって実行される、ＳｏＣ。
48. 請求項３８から４７のいずれか一項に記載のＳｏＣであって、前記低電力状態は、
    前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げ、
    前記動作クロック周波数を下げた後に、前記少なくとも１つのＩＰエージェントによって利用される供給電圧を下げることによって実行される、ＳｏＣ。
49. システムオンチップ（ＳｏＣ）であって、
    少なくとも１つのＩＰエージェントと、
    相互接続と、
    前記ＩＰエージェントと前記相互接続とを接続するリンクと、
    前記ＩＰエージェントを動作不能状態にするよう構成されている電力マネージャと、
    休止マネージャと、
    を備え、
    前記休止マネージャは、
    （ａ）トランザクションの生成を停止するよう前記ＩＰエージェントに命令し、
    （ｂ）前記ＩＰエージェントによって生成されたすべてのトランザクションが完了すると、前記リンクを休止状態にし、
    （ｃ）前記動作不能状態に入るためのシーケンスを前記ＩＰエージェントに開始させることによって、前記リンクを前記休止状態にするよう構成されている、ＳｏＣ。
50. 請求項４９に記載のＳｏＣであって、さらに、前記動作不能状態にある時に前記ＩＰエージェントの代理として前記相互接続を構成することを含む、ＳｏＣ。
51. 請求項５０に記載のＳｏＣであって、前記相互接続は、
    前記動作不能状態にある前記ＩＰエージェントに送信元がトランザクションを送信したか否かを確認し、
    前記送信元に例外メッセージを送信して、前記ＩＰエージェントが利用可能ではないことを前記送信元に通知することによって、前記ＩＰエージェントの前記代理として機能する、ＳｏＣ。
52. 請求項４９から５１のいずれか一項に記載のＳｏＣであって、前記ＩＰエージェントは、さらに、ウェイクアップトリガイベントに応答して、前記動作不能状態にある時に、「ウェイクアップ」シーケンスを開始するよう構成されている、ＳｏＣ。
53. 請求項５２に記載のＳｏＣであって、前記ウェイクアップトリガイベントは、
    （ａ）前記ＩＰエージェントが、前記ＳｏＣの外部の送信元から通信を受信すること、
    （ｂ）所定の期間が経過したこと、
    （ｃ）システムコントローラによって命令された時、または、
    （ｄ）有効なトランザクションが、前記動作不能状態の前記ＩＰエージェントを目標にすること、の内の１つを含む、ＳｏＣ。
54. 請求項５２に記載のＳｏＣであって、前記ウェイクアップシーケンスは、前記ＩＰエージェントが、前記ウェイクアップトリガイベントに応答して、前記リンクを介して前記相互接続にウェイクアップ通信を送信することを含む、ＳｏＣ。
55. 請求項５４に記載のＳｏＣであって、前記ウェイクアップシーケンスは、前記相互接続が前記ウェイクアップ通信をシステムコントローラに転送することを含む、ＳｏＣ。
56. 請求項５５に記載のＳｏＣであって、前記ウェイクアップシーケンスは、さらに、前記システムコントローラが、前記相互接続によって転送された前記ウェイクアップ通信を受信したことに応答して、ウェイクアップコマンドを前記ＩＰエージェントに送信することを含む、ＳｏＣ。
57. 請求項５６に記載のＳｏＣであって、前記ウェイクアップシーケンスは、さらに、前記ＩＰエージェントが、前記ウェイクアップコマンドに応答して、自身のウェイクアッププロトコルを開始することを含む、ＳｏＣ。

Images