(57)【要約】【解決手段】複数のトランザクションの部分の間でアービトレートして、クロックサイクルごとに相互接続に関連付けられている複数の仮想チャネルの１つを介して勝利部分を送信することが開示されている。各クロックサイクルを繰り返し実行することにより、複数の勝利部分が、それぞれ、複数のクロックサイクルにわたって複数の仮想チャネルでインターリーブされて伝送される。【選択図】図４
2021519464.tif 000002
【特許請求の範囲】
【請求項１】
システムオンチップ（ＳｏＣ）で利用するためのアービトレーションシステムであって、
前記ＳｏＣ上の複数のサブシステムの間で共有されるよう構成されている相互接続と、前記サブシステムは前記相互接続を介して伝送するためにトランザクションを生成するよう構成されており、
アービトレーション要素と、
を備え、
前記アービトレーション要素は、クロックサイクルごとに、
（１）前記複数のサブシステムによって生成された複数のトランザクションの部分の間でアービトレートし、
（２）前記複数のトランザクションの前記部分の中から勝利部分を選択し、
（３）前記相互接続に関連付けられている複数の仮想チャネルの１つを介して前記勝利部分を伝送するよう構成されている、システム。
【請求項２】
請求項１に記載のアービトレーションシステムであって、前記複数の仮想チャネルの各々は、論理的に独立している、システム。
【請求項３】
請求項１または２に記載のアービトレーションシステムであって、前記複数のトランザクションの内の１トランザクションの第１勝利部分および第２勝利部分が、同じ仮想チャネルを介して伝送される、システム。
【請求項４】
請求項１から３のいずれか一項に記載のアービトレーションシステムであって、さらに、
複数の送信元ポートと、
前記複数の送信元ポートの各々に対して、複数のバッファと、
を備える、システム。
【請求項５】
請求項４に記載のアービトレーションシステムであって、前記複数の送信元ポートの各々に対する前記複数のバッファは、トランザクションクラスおよび前記複数の仮想チャネルの各組み合わせに対して、それぞれ提供される、システム。
【請求項６】
請求項４に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記複数の送信元ポートの間でアービトレーションを実行する、システム。
【請求項７】
請求項１から６のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記複数の仮想チャネルの間でアービトレーションを実行する、システム。
【請求項８】
請求項５に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記トランザクションクラスの間でアービトレーションを実行する、システム。
【請求項９】
請求項８に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記トランザクションクラスの間で前記アービトレーションを実行する時に、デバイス順序付けルールを利用する、システム。
【請求項１０】
請求項８に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記トランザクションクラスの間で前記アービトレーションを実行する時に、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順序ルールを利用する、システム。
【請求項１１】
請求項１から５のいずれか一項に記載のアービトレーションシステムであって、前記トランザクションクラスは、
応答を求めないＰｏｓｔｅｄトランザクションクラス、
アクセスされた送信元からの応答を求めるＮｏｎ−ｐｏｓｔｅｄトランザクションクラス、および、
Ｎｏｎ−ｐｏｓｔｅｄトランザクションへの応答のためのＣｏｍｐｌｅｔｉｏｎトランザクションクラス、
の内の１以上を含む、システム。
【請求項１２】
請求項１から５のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、
（１）前記複数の送信元ポートの間でのアービトレーション、
（２）前記複数の仮想チャネルの間でのアービトレーション、および、
（３）前記トランザクションクラスの間でのアービトレーション、
を実行することによって、前記クロックサイクルごとに、前記勝利部分を選択する、システム。
【請求項１３】
請求項９に記載のアービトレーションシステムであって、前記複数の送信元ポイント、前記複数の仮想チャネル、および、前記トランザクションクラスの間でのアービトレーションが、任意の順序で実行されうる、システム。
【請求項１４】
請求項１から１３のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーションは、前記複数のトランザクションの中で、利用できない宛先を規定する選択部分を、前記アービトレーションから除外する、システム。
【請求項１５】
請求項１から１３のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーションは、前記複数のトランザクションの中で、前記複数の仮想チャネルの内で利用できない１以上の仮想チャネルに関連する選択部分を、前記アービトレーションから除外する、システム。
【請求項１６】
請求項１から１５のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、さらに、複数の勝利部分が、クロックサイクルごとに、前記複数の仮想チャネルを介してそれぞれ伝送されるように、（１）から（３）を繰り返し実行するよう構成されている、システム。
【請求項１７】
請求項１６に記載のアービトレーションシステムであって、前記アービトレーション要素は、さらに、前記複数の仮想チャネルの中から選択された異なる仮想チャネル上で前記複数の勝利部分の前記伝送をそれぞれインターリーブするよう構成されている、システム。
【請求項１８】
請求項１６に記載のアービトレーションシステムであって、各クロックサイクルに転送されるデータの量は、少なくとも部分的には、前記相互接続のビット幅に依存する、システム。
【請求項１９】
請求項１から１８のいずれか一項に記載のアービトレーションシステムであって、さらに、前記複数のサブシステムにそれぞれ関連付けられている複数のポートを備え、前記複数のポートの各々は、前記相互接続に関連付けられている前記複数の仮想チャネルにそれぞれ対応する複数のバッファを備える、システム。
【請求項２０】
請求項１９に記載のアービトレーションシステムであって、所定のポートの前記複数のバッファは、前記対応するサブシステムによって生成された前記トランザクションの部分をバッファする、システム。
【請求項２１】
請求項１から２１のいずれか一項に記載のアービトレーションシステムであって、前記勝利部分は、前記アービトレーション要素によって、
前記複数の仮想チャネルの中から勝利仮想チャネルを選択するための第１レベルアービトレーションを実行し、
前記第１レベルアービトレーションによって選択された前記勝利仮想チャネルに各々割り当てられたトランザクションの競合部分の中から前記勝利部分を選択するための第２レベルアービトレーションを実行することにより、アービトレートされる、システム。
【請求項２２】
請求項２１に記載のアービトレーションシステムであって、前記アービトレーション要素は、デバイス順序アービトレーションルールを用いてアービトレートする、システム。
【請求項２３】
請求項２１に記載のアービトレーションシステムであって、前記アービトレーション要素は、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順序アービトレーションルールを用いてアービトレートする、システム。
【請求項２４】
請求項２１に記載のアービトレーションシステムであって、前記第１レベルアービトレーションは、利用可能な仮想チャネルの間でのみ実行される、システム。
【請求項２５】
請求項２１に記載のアービトレーションシステムであって、前記第１レベルアービトレーションは、前記競合トランザクションを処理するために利用可能な宛先をそれぞれ規定する前記トランザクションの前記競合部分の間でのみ実行される、システム。
【請求項２６】
請求項１から２６のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記複数の仮想チャネルの１つが他の仮想チャネルよりも絶対優先度を与えられる絶対アービトレーションスキームを用いて、前記複数の仮想チャネルの間でアービトレートする、システム。
【請求項２７】
請求項１から２５のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、ラウンドロビン優先度スキームを用いて、前記複数の仮想チャネルの間でアービトレートする、システム。
【請求項２８】
請求項１から２５のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、最長時間未サービスプロトコルを用いて、前記複数の仮想チャネルの間でアービトレートする、システム。
【請求項２９】
請求項１から２５のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、前記複数の仮想チャネルの各々にそれぞれ割り当てられた重み付け比率を用いて、前記複数の仮想チャネルの間でアービトレートする、システム。
【請求項３０】
請求項１から２９のいずれか一項に記載のアービトレーションシステムであって、前記複数のサブシステムは、前記相互接続を介して互いに通信するよう構成されている集積回路上のＩＰエージェントであり、前記アービトレーション要素は、それぞれ、複数のクロックサイクルにわたって、前記相互接続に関連付けられている前記複数の仮想チャネルを介して、前記複数のトランザクションの勝利部分をアービトレートしてインターリーブするよう構成されている、システム。
【請求項３１】
請求項１から３０のいずれか一項に記載のアービトレーションシステムであって、前記サブシステムは各々、規定された機能を実行する、システム。
【請求項３２】
請求項１から３１のいずれか一項に記載のアービトレーションシステムであって、前記複数のトランザクションの前記部分は、それぞれ、パケットまたはパケットの一部である、システム。
【請求項３３】
請求項１から３２のいずれか一項に記載のアービトレーションシステムであって、前記複数のトランザクションの各々は、それぞれ、１以上のパケットによって表される、システム。
【請求項３４】
請求項１に記載のアービトレーションシステムであって、前記複数のトランザクションの各々は、少なくとも１つのパケットによって表され、前記少なくとも１つのパケットは、１以上のフィールドを含み、前記１以上のフィールドは、
送信元識別子を含むための送信元フィールドと、
宛先識別子のための宛先フィールドと、
前記パケットに関連する任意のペイロードのサイズを規定するためのペイロードフィールドと、
宛先に関連するシステムメモリ空間内のアドレスを規定するためのアドレスフィールと、
を含む、システム。
【請求項３５】
請求項１から３４のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、少なくとも１つのスイッチと連携して動作し、前記スイッチは、前記複数のサブシステムの内の１以上のための１以上の入口／出口のポイントをそれぞれ規定する１以上のアクセスポートを備える、システム。
【請求項３６】
請求項１から３５のいずれか一項に記載のアービトレーションシステムであって、さらに、前記複数のサブシステムにそれぞれ関連付けられている複数のポートを備え、前記複数のポートの各々は、それぞれ関連するサブシステムにアクセスするために用いられる一意識別子（ＩＤ）を有する、システム。
【請求項３７】
請求項１から３６のいずれか一項に記載のアービトレーションシステムであって、前記アービトレーション要素は、アドレス解決ロジックと連携して動作し、前記アドレス解決ロジックは、
前記アービトレーションの結果として得られた前記勝利部分に含まれて、前記システムメモリ内のロケーションを特定するアドレスを特定し、
目標サブシステムに関連するアクセスポートを前記アドレスから確認し、
前記確認されたアクセスポートに対応するアクセスポートＩＤを、前記勝利部分に関連する少なくとも１つのパケットに挿入するよう構成されており、
前記アクセスポートＩＤの前記挿入は、前記勝利部分が前記目標サブシステムに配信されることを可能にする、システム。
【請求項３８】
請求項１から３７のいずれか一項に記載のアービトレーションシステムであって、前記サブシステムによって生成される前記トランザクションは、
宛先からの応答が求められるＮｏｎ−ｐｏｓｔｅｄクラス、
前記宛先からの応答が求められないＰｏｓｔｅｄクラス、または、
Ｎｏｎ−ｐｏｓｔｅｄトランザクションに応答して生成されるＣｏｍｐｌｅｔｉｏｎクラス、
の内の１つに分類される、システム。
【請求項３９】
請求項１から３８のいずれか一項に記載のアービトレーションシステムであって、前記サブシステムによって生成される前記トランザクションは各々、一方向性である、システム。
【請求項４０】
請求項１から３９のいずれか一項に記載のアービトレーションシステムであって、前記相互接続は、Ｎデータビット幅の物理的相互接続である、システム。
【請求項４１】
請求項１から４０のいずれか一項に記載のアービトレーションシステムであって、前記相互接続は、Ｍ個の制御ビットを含む物理的相互接続である、システム。
【請求項４２】
請求項１から４１のいずれか一項に記載のアービトレーションシステムであって、前記複数の仮想チャネルは、１個の仮想チャネルから３２個の仮想チャネルまでの任意の数を含む、システム。
【請求項４３】
請求項１から４２のいずれか一項に記載のアービトレーションシステムであって、前記相互接続は、一方向性であり、前記複数のトランザクションから選択された勝利部分を第１方向にのみ伝送するよう構成されている、システム。
【請求項４４】
請求項４３に記載のアービトレーションシステムであって、さらに、
一方向性の第２相互接続であって、前記第１方向とは反対の第２方向にのみ、他の勝利部分を伝送するよう構成されている第２相互接続と、
前記第２相互接続を介して伝送される前記他の勝利部分を選択するための第２アービトレーションと、
を備える、システム。
【請求項４５】
システムオンチップ（ＳｏＣ）であって、
前記ＳｏＣ上に配置された複数のサブシステムであって、複数のトランザクションを生成するよう構成されている複数のサブシステムと、
前記ＳｏＣ上に提供された共有相互接続であって、前記複数のサブシステムの間で前記複数のトランザクションを伝送するよう構成され、自身に関連付けられている複数の仮想チャネルを有する、共有相互接続と、
アービトレーション要素と、
を備え、
前記アービトレーション要素は、クロックサイクルごとに、
（１）前記複数のサブシステムによって生成された前記複数のトランザクションの競合部分の間でアービトレートし、
（２）前記複数のトランザクションの前記競合部分の中から勝利部分を選択するよう構成されており、
連続するクロックサイクル中に選択された前記複数のトランザクションの前記勝利部分は各々、前記複数の仮想チャネルの内の１つに割り当てられて、前記共有相互接続を介して伝送される、ＳｏＣ。
【請求項４６】
請求項４５に記載のＳｏＣであって、前記複数のトランザクションの前記勝利部分は、前記連続するクロックサイクル中に前記共有相互接続を介して伝送される際にインターリーブされる、ＳｏＣ。
【請求項４７】
請求項４５または４６のいずれかに記載のＳｏＣであって、前記複数の仮想チャネルの各々は、論理的に独立しており、所与のトランザクションの複数の部分の各々が、前記同じ仮想チャネルに割り当てられる、ＳｏＣ。
【請求項４８】
請求項４５から４７のいずれか一項に記載のＳｏＣであって、さらに、前記複数のサブシステムに関連付けられている複数のポートを備え、前記複数のポートの各々は、一意ポート識別子（ＩＤ）をそれぞれ割り当てられている、ＳｏＣ。
【請求項４９】
請求項４８に記載のＳｏＣであって、各ポートは、トランザクションクラスおよび前記複数の仮想チャネルの各組み合わせに対して、複数のバッファをそれぞれ備える、ＳｏＣ。
【請求項５０】
請求項４９に記載のＳｏＣであって、前記トランザクションクラスは、（ａ）Ｐｏｓｔｅｄトランザクション、（ｂ）Ｎｏｎ−ｐｏｓｔｅｄトランザクション、および、（ｃ）Ｃｏｍｐｌｅｔｉｏｎトランザクションを含む、ＳｏＣ。
【請求項５１】
請求項４９に記載のＳｏＣであって、前記トランザクションクラスは、（ａ）Ｎｏｎ−ｐｏｓｔｅｄトランザクション、および、（ｃ）Ｃｏｍｐｌｅｔｉｏｎトランザクションを含む、ＳｏＣ。
【請求項５２】
請求項４５から５１のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、クロックサイクルごとに、前記複数のサブシステムにそれぞれ関連付けられている複数のポートの間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５３】
請求項４５から５２のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、クロックサイクルごとに、それぞれ、前記複数の仮想チャネルの間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５４】
請求項４５から５３のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、クロックサイクルごとに、それぞれ、複数のトランザクションクラスの間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５５】
請求項５４に記載のＳｏＣであって、前記アービトレーション要素は、デバイス順序付けルールを用いて、前記複数のトランザクションクラスの間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５６】
請求項５４に記載のＳｏＣであって、前記アービトレーション要素は、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付けルールを用いて、前記複数のトランザクションクラスの間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５７】
請求項５４に記載のＳｏＣであって、前記アービトレーション要素は、クロックサイクルごとに、
（１）前記複数のサブシステムにそれぞれ関連付けられている複数のポート、
（２）複数のトランザクションクラス、および、
（３）前記複数の仮想チャネル、
の間で前記アービトレーションを実行する、ＳｏＣ。
【請求項５８】
請求項５７に記載のＳｏＣであって、（１）、（２）、および、（３）は、任意の順序で実行される、ＳｏＣ。
【請求項５９】
請求項４５から５８のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、さらに、クロックサイクルごとに、利用できない宛先リソースを規定する前記複数の競合トランザクションの選択部分を除外するよう構成されている、ＳｏＣ。
【請求項６０】
請求項４５から５９のいずれか一項に記載のＳｏＣであって、前記共有相互接続は、
（ａ）８データビット幅、
（ｂ）１６データビット幅、
（ｃ）３２データビット幅、
（ｄ）６４データビット幅、
（ｅ）１２８データビット幅、
（ｆ）２５６データビット幅、
（ｈ）５１２データビット幅、または
（ｉ）１０２４ビット幅、
の内の１つである、ＳｏＣ。
【請求項６１】
請求項４５から６０のいずれか一項に記載のＳｏＣであって、前記共有相互接続によって各クロックサイクルに転送されるデータの量は、少なくとも部分的には、前記共有相互接続のビット幅に依存する、ＳｏＣ。
【請求項６２】
請求項４５から６１のいずれか一項に記載のＳｏＣであって、前記複数のトランザクションの各々は、前記複数の仮想チャネルの内の１つに割り当てられる、ＳｏＣ。
【請求項６３】
請求項６２に記載のＳｏＣであって、前記割り当ては、
無作為の割り当て、
ハードコートされた割り当て、
前記複数の仮想チャネルにわたるバランシング、
安全なチャネル、または、
トランザクションの緊急性、
の内の１以上を用いることに基づく、ＳｏＣ。
【請求項６４】
請求項４５から６３のいずれか一項に記載のＳｏＣであって、前記複数のトランザクションの前記部分は、それぞれ、パケットまたはパケットの一部である、ＳｏＣ。
【請求項６５】
請求項４５から６４のいずれか一項に記載のＳｏＣであって、前記複数のトランザクションの各々は、それぞれ、１以上のパケットによって表される、ＳｏＣ。
【請求項６６】
請求項４５から６５のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、さらに、厳密または絶対優先度スキームを用いてアービトレートするよう構成されている、ＳｏＣ。
【請求項６７】
請求項４５から６５のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、さらに、重み付け比率アービトレーションスキームを用いてアービトレートするよう構成されている、ＳｏＣ。
【請求項６８】
請求項４５から６５のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、さらに、ラウンドロビンアービトレーションスキームを用いてアービトレートするよう構成されている、ＳｏＣ。
【請求項６９】
請求項４５から６５のいずれか一項に記載のＳｏＣであって、前記アービトレーション要素は、さらに、最長時間未サービスアービトレーションスキームを用いてアービトレートするよう構成されている、ＳｏＣ。
【請求項７０】
請求項４５から６９のいずれか一項に記載のＳｏＣであって、さらに、前記複数のトランザクションの内の１以上について、宛先アドレスをそれぞれ解決するためのアドレス解決ロジック（ＡＲＬ）ユニットを備える、ＳｏＣ。
【請求項７１】
請求項４５から７０のいずれか一項に記載のＳｏＣであって、さらに、前記トランザクションの勝利部分の間で前記共有相互接続へのアクセスを順序付けるための順序付けポイントを備える、ＳｏＣ。
【請求項７２】
請求項４５から７１のいずれか一項に記載のＳｏＣであって、前記相互接続は、Ｎビット幅であり、Ｎは、２のべき乗である、ＳｏＣ。
【請求項７３】
請求項４５から７２のいずれか一項に記載のＳｏＣであって、前記相互接続は、Ｍ個の制御ビットを備え、Ｍは、１以上の整数である、ＳｏＣ。
【請求項７４】
アービトレーションシステムであって、
共有リソースと、
アクセスされるリソースと、
競合する要素の間で前記共有リソースへのアクセスをアービトレートするよう構成されると共に、クロックサイクルごとに、前記共有リソースへのアクセスをアービトレートするよう構成されているアービトレーション要素と、
を備える、システム。
【請求項７５】
システムオンチップ（ＳｏＣ）であって、
相互接続ファブリックと、
前記相互接続ファブリックによって相互接続された複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、ブロードキャスト、マルチキャスト、読み出しマルチキャスト、または、エニーキャストタイプのトランザクションの内の１つであるトランザクションを生成して送信するよう構成され、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記トランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成されている、ＳｏＣ。
【請求項７６】
請求項７５に記載のＳｏＣであって、前記相互接続ファブリックは、前記相互接続ファブリックの２つのノードの間で共有相互接続を介して前記トランザクションの１つのインスタンス化を統合して送信することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、配信パスに沿って２以上の宛先ＩＰエージェントに至る、ＳｏＣ。
【請求項７７】
請求項７５または７６に記載のＳｏＣであって、前記相互接続ファブリックは、前記トランザクションに応答して生成された複数の受信済みの応答トランザクションを統合して、前記相互接続ファブリックのノードの間で共有相互接続を介して前記応答トランザクションの１つのインスタンス化を転送することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、応答配信パスに沿って前記応答トランザクションの宛先に至る、ＳｏＣ。
【請求項７８】
請求項７５から７７のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリーム上で複数のトランザクションの伝送をインターリーブするように、前記ルーティング決定を行うよう構成されており、（ａ）前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定され、（ｂ）所与のトランザクションの１以上の部分が、同じストリームを介して伝送される、ＳｏＣ。
【請求項７９】
請求項７５から７８のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリームの中の同じストリームを介して２以上の独立したトランザクションをルーティングするように、前記ルーティング決定を行うよう構成されており、前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定される、ＳｏＣ。
【請求項８０】
請求項７５から７９のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、共通の論理識別子を共有する重複物理リソースを備え、前記ルーティング決定は、（ａ）前記重複物理リソースの１つを選択することと、（ｂ）前記重複物理リソースの前記選択された１つを用いて前記トランザクションをルーティングすることと、を含む、ＳｏＣ。
【請求項８１】
請求項８０に記載のＳｏＣであって、前記重複物理リソースは、
（ａ）重複ＩＰエージェント、
（ｂ）前記相互接続ファブリックの２つのノードの間の重複共有相互接続、
（ｃ）ＩＰエージェントと前記相互接続ファブリックのノードとの間の共有ライン、
の内の１つを含む、ＳｏＣ。
【請求項８２】
請求項８０に記載のＳｏＣであって、前記ルーティング決定は、
（ａ）前記重複物理リソースの利用可能性、
（ｂ）前記重複物理リソースの間の相対的な混在状態、
（ｃ）前記重複物理リソースの間の負荷バランシング、
（ｄ）前記重複物理リソースの間のランダム選択、
（ｅ）前記重複物理リソースの間の最長時間未使用選択、
（ｆ）前記重複物理リソースの間の相対的な電力消費、
（ｇ）前記重複物理リソースの間で選択を行うためのハッシュ関数の利用、または、
（ｈ）（ａ）〜（ｇ）の任意の組み合わせ、
の内の１つに基づく、ＳｏＣ。
【請求項８３】
請求項７５から８２のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックを介して前記トランザクションをどのようにルーティングして配信するかについての前記ルーティング決定は、２以上の宛先ＩＰエージェントへの前記トランザクションの配信を同期させることを含む、ＳｏＣ。
【請求項８４】
請求項７５から８３のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックを介して前記トランザクションをどのようにルーティングして配信するかについての前記ルーティング決定は、２以上の宛先ＩＰエージェントへの前記トランザクションの配信が非同期的に起きるのを許容することを含む、ＳｏＣ。
【請求項８５】
請求項７５から８４のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記ノードの少なくとも１つは、前記トランザクション内で指定されたアドレスを前記１以上の宛先ＩＰエージェントの論理識別子に解決するためのルックアップテーブルを備える、ＳｏＣ。
【請求項８６】
請求項７５から８５のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記複数のノードの各々は、前記１以上の宛先ＩＰエージェントの論理識別子を、前記トランザクションをルーティングするために用いられる１以上のポート識別子に変換するためのテーブルを備える、ＳｏＣ。
【請求項８７】
請求項７５から８６のいずれか一項に記載のＳｏＣであって、前記トランザクションは、複数の一意的なコード化されたコマンドの内の１つを備え、前記一意的なコード化されたコマンドの各々は、前記トランザクションが、それぞれ、前記ブロードキャスト、前記マルチキャスト、前記読み出しマルチキャストトランザクション、または、前記エニーキャストタイプのトランザクションの内のいずれか１つであることを、前記相互接続ファブリックに示す、ＳｏＣ。
【請求項８８】
請求項７５から８７のいずれか一項に記載のＳｏＣであって、前記トランザクションは、一意的なアドレスを備え、前記一意的なドレスは、前記トランザクションが、それぞれ、前記ブロードキャスト、前記マルチキャスト、前記読み出しマルチキャストトランザクション、または、前記エニーキャストタイプのトランザクションの内のいずれか１つであることを、前記相互接続ファブリックに示す、ＳｏＣ。
【請求項８９】
請求項７５から８８のいずれか一項に記載のＳｏＣであって、前記トランザクションは、一意的なアドレスを備え、前記一意的なアドレスは、前記相互接続ファブリックによって、
（ａ）前記１以上の宛先ＩＰエージェントの論理識別子、
（ｂ）前記１以上の宛先ＩＰエージェントの論理識別子を指定する一意的なコード、および、
（ｃ）前記１以上の宛先ＩＰエージェントの論理識別子を表すビットのベクトル、
の内の１つに解決される、ＳｏＣ。
【請求項９０】
請求項７５から８９のいずれか一項に記載のＳｏＣであって、前記トランザクションは、ブロードキャストであり、前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの各々へ前記トランザクションをルーティングして配信するように、前記ルーティング決定を行う、ＳｏＣ。
【請求項９１】
請求項７５から８９のいずれか一項に記載のＳｏＣであって、前記トランザクションは、マルチキャストであり、前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの内の２以上へ前記トランザクションをルーティングして配信するように、前記ルーティング決定を行う、ＳｏＣ。
【請求項９２】
請求項７５から８９のいずれか一項に記載のＳｏＣであって、前記トランザクションは、読み出しマルチキャストトランザクションであり、前記トランザクションは、１つの宛先ＩＰエージェントに配信されるが、前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの内の２以上へ応答トランザクションをルーティングして配信する、ＳｏＣ。
【請求項９３】
請求項７５から８９のいずれか一項に記載のＳｏＣであって、前記トランザクションは、エニーキャストであり、前記相互接続ファブリックは、前記トランザクションの前記１以上の宛先ＩＰエージェントを選択する、ＳｏＣ。
【請求項９４】
請求項７５から９３のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、２以上の独立したトランザクションを同じストリームを介してル−ティングするように、前記ルーティング決定を行うよう構成されており、前記２以上の独立したトランザクションは各々、前記２以上の独立したトランザクションが前記同じストリームを介してルーティングされうるように、前記２以上の独立したトランザクションの各々のビートを前記相互接続ファブリックが追跡することを可能にする一意的なトランザクション識別子を割り当てられる、ＳｏＣ。
【請求項９５】
請求項９４に記載のＳｏＣであって、前記同じストリームを介してルーティングされた前記２以上の独立したトランザクションは、前記同じストリームを指定する共通の制御情報を共有するが、前記２以上の独立したトランザクションの各々の前記トランザクション識別子は一意的である、ＳｏＣ。
【請求項９６】
システムオンチップ（ＳｏＣ）であって、
相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成されている、ＳｏＣ。
【請求項９７】
請求項９６に記載のＳｏＣであって、前記ＳＢＲトランザクションは、前記ＳｏＣ上の前記１以上の宛先ＩＰエージェントを論理的に識別する識別子を前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定する、ＳｏＣ。
【請求項９８】
請求項９６または９７に記載のＳｏＣであって、前記ＳＢＲトランザクションは、一意的なコードを前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定し、前記一意的なコードは、前記ＳｏＣ上の前記１以上の宛先ＩＰエージェントを識別するために、前記相互接続ファブリック内で解決される、ＳｏＣ。
【請求項９９】
請求項９６から９８のいずれか一項に記載のＳｏＣであって、前記ＳＢＲトランザクションは、アドレスを前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定し、前記アドレスは、前記ＳｏＣ上の２以上の宛先ＩＰエージェントを識別するために、前記相互接続ファブリックによって解決される、ＳｏＣ。
【請求項１００】
請求項９６から９９のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、前記相互接続ファブリックの２つのノードの間で共有相互接続を介して前記ＳＢＲトランザクションの１つのインスタンス化を統合して送信することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、配信パスに沿って２以上の宛先ＩＰエージェントに至る、ＳｏＣ。
【請求項１０１】
請求項９６から１００のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、前記ＳＢＲトランザクションに応答して生成された複数の受信済みの応答トランザクションを統合して、前記相互接続ファブリックのノードの間で共有相互接続を介して前記応答トランザクションの１つのインスタンス化を転送することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、応答配信パスに沿って前記応答トランザクションの目標に至る、ＳｏＣ。
【請求項１０２】
請求項９６から１０１のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリーム上で複数のトランザクションの伝送をインターリーブするように、前記ルーティング決定を行うよう構成されており、（ａ）前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定され、（ｂ）同じトランザクションの１以上の部分が、同じストリームを介して伝送される、ＳｏＣ。
【請求項１０３】
請求項９６から１０２のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリームの中の同じストリームを介して２以上の独立したトランザクションをルーティングするように、前記ルーティング決定を行うよう構成されており、前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定される、ＳｏＣ。
【請求項１０４】
請求項９６から１０３のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、共通の論理識別子を共有する重複物理リソースを備え、前記ルーティング決定は、（ａ）前記重複物理リソースの１つを選択すること、（ｂ）前記重複物理リソースの前記選択された１つを用いて前記トランザクションをルーティングすること、とを含む、ＳｏＣ。
【請求項１０５】
請求項１０４に記載のＳｏＣであって、前記重複物理リソースは、
（ａ）前記重複物理リソースの利用可能性、
（ｂ）前記重複物理リソースの間の相対的な混在状態、
（ｃ）前記重複物理リソースの間の負荷バランシング、
（ｄ）前記重複物理リソースの間のランダム選択、
（ｅ）前記重複物理リソースの間の最長時間未使用選択、
（ｆ）前記重複物理リソースの間の相対的な電力消費、
（ｇ）前記重複物理リソースの間で選択を行うためのハッシュ関数の利用、または、
（ｈ）（ａ）〜（ｇ）の任意の組み合わせ、の内の１つを含む、ＳｏＣ。
【請求項１０６】
請求項９６から１０５のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記複数のノードの各々は、前記ＳＢＲトランザクション内で指定された１以上のアドレスを前記１以上の宛先ＩＰエージェントの１以上の論理識別子に解決するためのルックアップテーブルを備える、ＳｏＣ。
【請求項１０７】
請求項９６から１０６のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記複数のノードの各々は、前記１以上の宛先ＩＰエージェントの論理識別子を、前記トランザクションをルーティングするために用いられる１以上のポート識別子に変換するためのテーブルを備える、ＳｏＣ。
【請求項１０８】
請求項９６から１０７のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、さらに、２以上の独立したトランザクションを同じストリームを介してル−ティングするように、前記ルーティング決定を行うよう構成されており、前記２以上の独立したトランザクションは各々、前記２以上の独立したトランザクションが前記同じストリームを介してルーティングされうるように、前記２以上の独立したトランザクションの各々のビートを前記相互接続ファブリックが追跡することを可能にする一意的なトランザクション識別子を割り当てられる、ＳｏＣ。
【請求項１０９】
請求項１０８に記載のＳｏＣであって、前記同じストリームを介してルーティングされた前記２以上の独立したトランザクションは、前記同じストリームを指定する共通の制御情報を共有するが、前記２以上の独立したトランザクションの各々の前記トランザクション識別子は一意的である、ＳｏＣ。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９  （ＰＲＴＩＰ００１Ｐ）号および２０１９年２月４日出願の米国仮出願第６２／８００，８９７  （ＰＲＴ１Ｐ００３Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。
【０００２】
本願は、共有リソースへのアクセスをアービトレートすることに関し、特に、複数のトランザクションの部分の間でアービトレートして、クロックサイクルごとに相互接続に関連付けられている複数の仮想チャネルの１つを介して勝利部分を送信することに関する。
【背景技術】
【０００３】
システムオンチップ（「ＳｏＣ」）は、複数のサブシステムを備える集積回路であり、しばしば、知的財産（「ＩＰ」）エージェントまたはコアと呼ばれる。ＩＰエージェントは、典型的には、特定の機能を実装または実行するように設計された回路の「再利用可能な」ブロックである。ＳｏＣの開発者は、典型的には、複数のＩＰエージェントが互いに通信するように、チップ上にそれらのＩＰエージェントをレイアウトして相互接続する。ＩＰエージェントを用いることにより、複雑なＳｏＣを開発する時間およびコストを大幅に削減できる。
【０００４】
ＳｏＣの開発者が直面する課題の１つは、様々なＩＰエージェントが相互に動作するように、それらをチップ上で相互接続することである。この問題に対処するために、半導体業界では、相互接続規格を適応させてきた。
【０００５】
１つのかかる規格は、英国ケンブリッジにあるＡＲＭ社によって開発および普及されたアドバンスト・マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）である。ＡＭＢＡは、ＳｏＣ上の機能ＩＰエージェントの接続および管理のために幅広く利用されているバス相互接続規格である。
【０００６】
ＡＭＢＡでは、トランザクションが、要求を定義し、別個の応答トランザクションを要求する。書き込みトランザクションでは、送信元が、リモート宛先にデータを書き込むことを要求する。書き込み動作が実行されると、宛先は、確認応答トランザクションを送信元に送り返す。書き込み動作は、応答トランザクションが送信元によって受信された時にのみ完了したと見なされる。読み出しトランザクションでは、送信元が、リモートロケーションを読み出すためにアクセスを要求する。読み出しトランザクションは、応答トランザクション（すなわち、アクセスされたコンテンツ）が送信元に返された時にのみ完了する。
【０００７】
ＡＭＢＡでは、アービトレーション処理が、複数の競合トランザクションの間の相互接続バスへのアクセスを許可するために用いられる。所与のアービトレーションサイクル中に、競合トランザクションの１つが、勝者として選択される。次いで、相互接続バスは、勝利トランザクションのデータ部の持続期間にわたって制御される。次のアービトレーションサイクルは、現在のトランザクションのためのデータすべてが完了した後にのみ開始する。この処理は、相互接続へのアクセスを巡って競合する複数の未処理のトランザクションがあるという条件で、連続的に繰り返される。
【０００８】
ＡＭＢＡ規格の１つの問題は、待ち時間である。バス相互接続は、トランザクションごとにアービトレートされる。トランザクションの任意の部分の間に、トランザクションが読み出し、書き込み、または、応答のいずれであるかに関わらず、バスは、トランザクション全体に対して制御される。トランザクションが開始すると、中断できない。例えば、トランザクションのデータ部が４サイクル長である場合、別のトランザクションがバスへアクセスできる前に、すべての４サイクルが完了する必要がある。結果として、（１）トランザクションは、クロックサイクルごとにはアービトレートできず、（２）すべての非勝利競合トランザクションは、現在のトランザクションのデータ部が完了するまで待機する必要がある。これらの要因の両方が、相互接続の効率およびＳｏＣの全体パフォーマンスを下げる傾向がある。
【発明の概要】
【０００９】
システムオンチップすなわちＳｏＣ上の複数のサブシステムの間で共有相互接続へのアクセスをアービトレートするためのアービトレーションシステムおよび方法が開示されている。アービトレーションシステムおよび方法は、クロックサイクルごとに、（１）複数のサブシステムによって生成された複数のトランザクションの部分の間でアービトレートし、（２）複数のトランザクションの部分の中から勝利部分を選択し、（３）相互接続に関連付けられている複数の仮想チャネルの１つを介して勝利部分を伝送するよう構成されているアービトレーション要素を備える。
【００１０】
（１）〜（３）を繰り返し実行することにより、複数の勝利部分が、それぞれ、複数のクロックサイクルにわたってインターリーブされて複数の仮想チャネルを介して伝送される。クロックサイクルごとに複数の仮想チャネルを介して複数のトランザクション部分のアービトレーションを行うことで、待ち時間の削減、ならびに、相互接続の効率および利用率の上昇など、多くの利点が得られる。これらの属性により、本明細書に開示されたアービトレーションシステムおよび方法は、システムオンチップ（ＳｏＣ）上での相互接続へのアクセスをアービトレートするのに非常に適切になる。
【図面の簡単な説明】
【００１１】
本願およびその利点については、添付の図面に関連して行う以下の説明を参照することによって最も良く理解できる。
【００１２】
【図１】非排他的実施形態に従って、システムオンチップ（ＳｏＣ）のための共有相互接続を示すブロック図。
【００１３】
【図２】非排他的実施形態に従って、トランザクションのパケットの例を示す図。
【００１４】
【図３Ａ】第１非排他的実施形態に従って、アービトレーション要素を示す論理図。
【００１５】
【図３Ｂ】第２非排他的実施形態に従って、アービトレーション要素を示す論理図。
【００１６】
【図４】非排他的実施形態に従って、共有相互接続の仮想チャネルを介してトランザクションの部分をアービトレーションして送信するための動作工程を示すフローチャート。
【００１７】
【図５】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第１例を示す図。
【００１８】
【図６】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第２例を示す図。
【００１９】
【図７】本発明の別の非排他的実施形態に従って、二方向にトラフィックを扱うための２つの共有相互接続を示すブロック図。
【００２０】
【図８】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックの例を示すブロック図。
【００２１】
【図９Ａ】本発明の非排他的実施形態に従って、物理アドレスおよびソースベースルーティング（ＳＢＲ）アドレスの両方を１以上のＩＰポートに解決するために用いられるルックアップテーブル（ＬＵＴ）を示す図。
【００２２】
【図９Ｂ】本発明の非排他的実施形態に従って、利用できるハッシュ関数を示す図。
【００２３】
【図１０Ａ】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックを介して送信されるトランザクションの拡大および統合を示す図。
【図１０Ｂ】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックを介して送信されるトランザクションの拡大および統合を示す図。
【００２４】
【図１１Ａ】本発明の非排他的実施形態に従って、トランキングリンクと、トランキングリンクの中からの物理リンクの選択とを示す図。
【図１１Ｂ】本発明の非排他的実施形態に従って、トランキングリンクと、トランキングリンクの中からの物理リンクの選択とを示す図。
【００２５】
図面において、同様の構造要素を指定するために、同様の符号が用いられることがある。また、図中の描写は、図式的なものであり、必ずしも縮尺通りではないことを理解されたい。
【発明を実施するための形態】
【００２６】
以下では、添付図面に例示された、いくつかの非排他的な実施形態を参照しつつ、本願の詳細な説明を行う。以下の説明では、本開示の完全な理解を促すために、数多くの具体的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本開示は、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。また、本開示が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造については、詳細な説明を省略した。
【００２７】
現在開発中の集積回路の多くは、非常に複雑である。結果として、多くのチップ設計者は、システムオンチップすなわち「ＳｏＣ」アプローチを用いて、単一のシリコン上に複数のサブシステムまたはＩＰエージェントを相互接続してきた。消費者デバイス（例えば、ハンドヘルド、携帯電話、タブレットコンピュータ、ラップトップおよびデスクトップコンピュータ、メデイア処理など）、仮想または拡張現実（例えば、ロボット工学、自律走行車、航空機など）、医療機器（例えば、イメージングなど）、工業、ホームオートメーション、工業（例えば、スマート家電、家庭用監視機器、など）およびデータセンター用途（例えば、ネットワークスイッチ、接続型ストレージデバイス、など）など、様々な用途のためのＳｏＣが、現在利用可能であるかまたは開発されている。
【００２８】
本願は、共有リソースへのアクセスをアービトレートするためのアービトレーションシステムおよび方法をおおむね対象にしている。かかる共有リソースは、例えば、バス相互接続、メモリリソース、処理リソース、または、複数の競争パーティの間で共有されたほぼ任意のその他のリソースでありうる。説明の便宜上、以下で詳述する共有リソースは、システムオンチップすなわち「ＳｏＣ」上の複数のサブシステムによって共有される相互接続であるとする。
【００２９】
ＳｏＣでは、後に詳述するように、トランザクションの形態で互いにトラフィックをやり取りする複数のサブシステムがあり、共有リソースは、物理的な相互接続であり、様々なトランザクションまたはその部分が、共有相互接続に関連する複数の仮想チャネルを介して伝送され、複数の異なるアービトレーションスキームおよび／または優先度の１つが、サブファンクションの間のトランザクションの伝送に向けた共有相互接続へのアクセスをアービトレートするために用いられてよい。
【００３０】
トランザクションクラス
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプまたはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。
【表１】
2021519464.tif 000003
【００３１】
Ｐｏｓｔｅｄトランザクション（書き込みなど）は、応答トランザクションを求めない。送信元がデータを指定された宛先に書き込むと、トランザクションが終了する。Ｎｏｎ−ｐｏｓｔｅｄトランザクション（読み出しまたは書き出しのいずれかなど）では、応答が求められる。しかしながら、応答は、別個のＣｏｍｐｌｅｔｉｏｎトランザクションとして分岐される。換言すると、読み出しでは、最初のトランザクションが読み出し動作のために用いられ、別個であるが関連するＣｏｍｐｌｅｔｉｏｎトランザクションが読み出しコンテンツを返すために用いられる。Ｎｏｎ−ｐｏｓｔｅｄ書き込みでは、最初のトランザクションが書き込みのために用いられ、一方、書き込みが完了すると、第２関連Ｃｏｍｐｌｅｔｉｏｎトランザクションが確認のために求められる。
【００３２】
トランザクションは、タイプに関わらず、１以上のパケットによって表すことができる。いくつかの状況では、トランザクションは、単一のパケットによって表されうる。別の状況においては、複数のパケットが、トランザクション全体を表すために必要とされうる。
【００３３】
ビートは、クロックサイクルあたりに共有相互接続を介して伝送できるデータの量である。例えば、共有相互接続が物理的に１２８ビット幅である場合、１２８ビットが、各ビートまたはクロックサイクルに伝送されうる。
【００３４】
いくつかの状況において、トランザクションは、伝送のために複数の部分に分割される必要がありうる。５１２ビット（６４バイト）であるペイロードを有する単一のパケットを有するトランザクションを考える。共有相互接続が１２８ビット幅（１６バイト）のみである場合、トランザクションは、４つの部分（例えば、４×１２８＝５１２）に分割され、４つのクロックサイクルまたはビートで伝送される必要がある。一方、トランザクションが１２８ビット幅未満である単一パケットのみである場合、トランザクション全体が、１つのクロックサイクルまたはビートで送信されうる。同じトランザクションがさらなるパケットをたまたま含む場合、さらなるクロックサイクルまたはビートが必要とされうる。
【００３５】
したがって、トランザクションの「部分」という用語は、所与のクロックサイクルまたはビート中に共有相互接続を介して転送できるデータの量である。部分のサイズは、共有相互接続の物理的な幅に応じて変わりうる。例えば、共有相互接続が物理的に６４データビット幅である場合、任意の１サイクルまたはビート中に転送できる最大ビット数は６４ビットである。所与のトランザクションが６４ビット以下のペイロードを有する場合、トランザクション全体が、単一部分で共有相互接続を介して送信されうる。一方、ペイロードがより大きい場合、パケットは、複数の部分で共有相互接続を介して送信されなければならない。１２８、２５６、または、５１２ビットのペイロードを有するトランザクションは、それぞれ、２、４、および、８の部分を必要とする。このように、「部分」という用語は、任意の所与のクロックサイクルまたはビート中に共有相互接続を介して送信されうるトランザクションの一部または全体のいずれかを意味すると広く解釈されるべきである。
【００３６】
ストリーム
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々な組み合わせを、以下の表２で詳述する。
【表２】
2021519464.tif 000004
【００３７】
上述したトランザクションクラスの数は、単に例示であり、限定として解釈すべきではないことに注意されたい。逆に、任意の数の仮想チャネルおよび／またはトランザクションクラスが用いられてよい。
【００３８】
共有相互接続の仮想チャネルでのアービトレーション
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非排他的実施形態において、アービトレーションシステムは、アップストリームサブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。
【００３９】
共有相互接続１２は、Ｎデータビット幅でありＭ個の制御ビットを含む物理的な相互接続である。また、共有相互接続１２は一方向性であり、これは、送信元（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）への方向にのみトラフィックを扱うことを意味する。
【００４０】
様々な代替例において、Ｎデータビットの数は、任意の整数であってよいが、典型的には、それぞれ、２のべき乗のビット幅である（例えば、２１、２２、２３、２４、２５、２６、２７、２８、２９など）または（２、４、６、８、１６、３２、６４、１２８、２５６など）。最も現実的な応用例では、Ｎビットの数は、３２、６４、１２８、２５６、または、５１２のいずれかである。ただし、これらの幅は、単に例示であり、どのようにも限定するものとして解釈すべきではないことを理解されたい。
【００４１】
制御ビットの数Ｍも、様々であり、任意の数であってよい。
【００４２】
１以上の論理チャネル（図示せず）（以降、「仮想チャネル」すなわち「ＶＣ」と呼ぶ）が、共有相互接続１２に関連付けられている。各仮想チャネルは、独立している。各仮想チャネルは、複数の独立ストリームに関連付けられてよい。仮想チャネルの数は、広く変化してよい。例えば、３２以上の数までの仮想チャネルが、規定されるか、または、共有相互接続１２に関連付けられてよい。
【００４３】
様々な代替実施形態において、各仮想チャネルは、異なる優先度を割り当てられてよい。１以上の仮想チャネルに、より高い優先度が割り当てられてよく、一方、１以上のその他の仮想チャネルに、より低い優先度が割り当てられてよい。高い優先度のチャネルは、低い優先度の仮想チャネルよりも高い共有相互接続１２へのアクセス権を与えられるまたはアービトレートされる。別の実施形態では、仮想チャネルの各々に、同じ優先度が与えられてもよく、その場合、共有相互接続１２へのアクセス権を与えるまたはアービトレートする時に、或る仮想チャネルを別の仮想チャネルより優先することがない。さらに別の実施形態において、仮想チャネルの内の１以上に割り当てられた優先度は、動的に変化してもよい。例えば、第１セットの状況において、仮想チャネルすべてに、同じ優先度が割り当てられてよいが、第２セットの状況において、特定の仮想チャネルに、その他の仮想チャネルよりも高い優先度が割り当てられてもよい。したがって、状況が変化するにつれて、仮想チャネルの間で用いられる優先度スキームは、現在の動作条件に最もよく合うように変更されうる。
【００４４】
サブシステム１４の各々は、典型的には、「再利用可能な」回路またはロジックのブロックであり、一般に、ＩＰコアまたはエージェントと呼ばれる。ほとんどのＩＰエージェントは、特定の機能を実行するよう設計され、例えば、イーサネットポート、ディスプレイドライバ、ＳＤＲＡＭインターフェース、ＵＳＢポートなどの周辺デバイスのためのコントローラである。かかるＩＰエージェントは、一般に、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの集積回路（ＩＣ）上に提供された複雑なシステムの設計全体の中で必要なサブシステム機能を提供する「ビルディングブロック（構成要素）」として用いられる。利用可能なＩＰエージェントのライブラリを用いることにより、チップ設計者は、より複雑な集積回路の設計において様々なロジック機能を容易に「ボルト締め」することができるので、設計時間を削減すると共に開発コストを節約することができる。サブシステムエージェント１４は、専用ＩＰコアに関して上述したが、これは、必要条件ではないことを理解されたい。逆に、サブシステム１４は、単一のポート２０に接続されたまたはそれを共有するＩＰ機能のコレクションであってもよい。したがって、「エージェント」という用語は、サブシステムが単一の機能を実行するか、複数の機能を実行するかに関わらず、ポート２０に接続された任意のタイプのサブシステムとして広く解釈されるべきである。
【００４５】
一対のスイッチ１６および１８が、それぞれ、専用アクセスポート２０を介してサブシステムエージェント１４の各々と共有相互接続１２との間のアクセスを提供する。図の例示的実施形態では、
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。
【００４６】
スイッチ１６および１８は、多重化および逆多重化機能を実行する。スイッチ１６は、サブシステムエージェントＩＰ１、ＩＰ２、および／または、ＩＰ３によって生成されたアップストリームトラフィックを選択し、共有相互接続１２を介してトラフィックをダウンストリームに送信する。スイッチ１８では、逆多重化動作が実行され、トラフィックは、目標サブシステムエージェント（すなわち、ＩＰ４、ＩＰ５、または、ＩＰ６のいずれか）へ提供される。
【００４７】
各アクセスポート２０は、一意ポート識別子（ＩＤ）を有しており、各サブシステムエージェント１４の専用アクセスをスイッチ１６または１８のいずれかへ提供する。例えば、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスポートＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２に割り当てられる。同様に、サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、アクセスポートＰｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５に割り当てられる。
【００４８】
スイッチ１６、１８への／からの入口ポイントおよび出口ポイントを提供するのに加えて、一意ポートＩＤ２０は、サブシステムエージェント１４の間のトラフィックをアドレッシングするために用いられる。各ポート２０は、システムメモリ２４内に、特定の量の割り当てられたアドレス可能空間を有する。
【００４９】
いくつかの非排他的な実施形態において、アクセスポート２０の全部または一部に、一意ポートＩＤだけでなく、「グローバル」ポート識別子が割り当てられてもよい。トランザクションおよびその他のトラフィックが、グローバルポート識別子に割り当てられたアクセスポートの全部または一部に送信されうる。したがって、グローバル識別子を用いれば、トランザクションおよびその他のトラフィックが、アクセスポート２０の全部または一部へ広く発信またはブロードキャストすることができ、一意識別子を用いて各アクセスポート２０へ個別にアドレッシングする必要性を排除できる。
【００５０】
スイッチ１６は、さらに、アービトレーション要素２６、アドレス解決ロジック（ＡＲＬ）２８、および、アドレス解決ルックアップテーブル（ＬＵＴ）３０を備える。
【００５１】
動作中、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、トランザクションを生成する。各トランザクションが生成されると、送信側サブシステム１４によってパケット化され、次いで、パケット化されたトランザクションは、対応するポート２０を介してローカルスイッチ１６へ投入される。例えば、ＩＰ１、ＩＰ２、および、ＩＰ３によって生成されたトランザクションの部分は、それぞれ、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６に提供される。
【００５２】
ポート２０は各々、相互接続チャネル１２に関連付けられている仮想チャネルの各々に対して、複数の先入れ先出しバッファ（図示せず）を備える。非排他的実施形態において、４つの仮想チャネルが存在する。その場合、各仮想チャネルに対して１つで、各ポート２０は、４つのバッファを備える。再び、ポート２０に含まれる仮想チャネルおよびバッファの数は、様々であってよく、４に限定されないことを理解されたい。逆に、仮想チャネルおよびバッファの数は、４より多くても少なくてもよい。
【００５３】
所与のトランザクションが２つ（以上）の部分で表される場合、それらの部分は、同じバッファ内に維持される。例えば、相互接続１２が１２８データビット幅であり、トランザクションが５１２ビットのペイロードを含むパケットによって表される場合、トランザクションは、４クロックサイクルまたはビートで伝送される４つの部分に分割される必要がある。一方、トランザクションが６４ビットのペイロードを有する単一パケットによって表されうる場合、単一の部分は、１クロックサイクルまたはビートで伝送されうる。所与のトランザクションのすべての部分を同じバッファ内に維持することにより、仮想チャネルは、論理的に独立したままになる。換言すると、所与のトランザクションに関連するトラフィックすべてが、常に、ストリームと同じ仮想チャネルで送信され、複数の仮想チャネルを介して分岐されることがない。
【００５４】
アービトレーション要素２６は、様々なアクセスポート２０によって維持されたトランザクションの競合するバッファされた部分の間でアービトレートすることを担う。非排他的実施形態において、複数の競合トランザクションが利用可能であれば、アービトレーション要素２６は、クロックサイクルごとにアービトレーションを実行する。サイクルごとのアービトレーション勝者は、相互接続１２へのアクセスが認められて相互接続１２を介して伝送されるトランザクションの部分を、サブシステムＩＰ１、ＩＰ２、および、ＩＰ３の内の１つから生成する。
【００５５】
トランザクションを生成する時、送信元サブシステムＩＰ１、ＩＰ２、および、ＩＰ３は、通常、可能な宛先サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６についてアドレス空間内のアドレスを知っているが、宛先にトランザクションをルーティングするために必要な情報（例えば、ポートＩＤ２０および／または２２）を知らない。一実施形態において、ローカルアドレス解決ロジック（ＡＲＬ）２８は、既知の宛先アドレスを必要なルーティング情報に解決するために用いられる。換言すると、送信元サブエージェント１４は、システムメモリ２４内の所与のアドレスにアクセスしたいことを単に知りうる。したがって、ＡＲＬ２８は、ＬＵＴ３０へアクセスするタスクを課せられ、指定されたアドレスに対応する最終的な宛先への配信パスに沿ってポート２０／２２のアドレスルックアップを実行する。ポート２０／２２が知られると、この情報は、トランザクションのパケット内の宛先フィールドに挿入される。結果として、パケットは、配信パスに沿ってポート２０／２２へ配信される。原則として、要求された配信情報がすでに知られており、パケットの宛先フィールドに含まれているので、配信パスに沿ったダウンストリームノードが、さらなるルックアップを実行する必要はない。後に詳述するようにソースベースルーティング（ＳＢＲ）と呼ばれる他のタイプのトランザクションで、送信元Ｐエージェントは、宛先ポートアドレスを知る。結果として、ＡＲＬ２８によって実行されるルックアップは、典型的には、実行される必要がない。
【００５６】
代替実施形態において、相互接続内のすべてのノードがＡＲＬ２８およびＬＵＴ３０を必要とするわけではない。これらの要素を持たないノードについては、必要なルーティング情報のないトランザクションが、デフォルトノードへ転送されうる。デフォルトノードでは、ＡＲＬ２８およびＬＵＴ３０がアクセスされ、次いで、必要なルーティング情報が、トランザクションのパケットのヘッダに挿入されうる。デフォルトノードは、典型的には、ＡＲＬ２８およびＬＵＴ３０を持たないノードよりアップストリームにある。ただし、これは、決して必須ではない。１または複数のデフォルトノードは、ＳｏＣ上のどこに配置されてもよい。ＡＲＬ２８およびＬＵＴ３０をいくつかのノードから排除することにより、ノードの複雑さを低減できる。
【００５７】
ＡＲＬ２８は、トランザクションの勝利部分のための転送先のデコードに加えて、各仮想チャネル内のトランザクションの勝利部分のための順序を規定するので、「順序付けポイント」と呼ばれてもよい。各アービトレーションが解決されると、ＡＲＬ２８がアドレスポートルックアップを実行するために用いられるか否かに関わらず、トランザクションの勝利部分が各仮想チャネルに提供される先入れ先出しキューに挿入される。次いで、トランザクションの勝利部分は、バッファ内で相互接続１２を介した伝送の順番を待つ。
【００５８】
また、ＡＲＬ２８は、「アップストリーム」および「ダウンストリーム」トラフィックを規定するために用いられる。換言すると、スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）によって生成された任意のトランザクションは、ＡＲＬ２８に対してアップストリームにあると見なされる。ＡＲＬ２８後の（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６に伝送される）すべてのトランザクションが、ダウンストリームトラフィックと見なされる。
【００５９】
スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）は、直接的または間接的のいずれかで、互いに通信してトランザクションを互いに送信してよい。直接的な通信（しばしば、ソースベースルーティング（ＳＢＲ）と呼ばれる）により、ＩＰエージェント１４は、ピアツーピアモデルで互いにトランザクションを送信できる。このモデルでは、送信元ＩＰエージェトは、そのピアＩＰエージェント１４の一意ポートＩＤが知っており、ＬＵＴ３０にアクセスするためにＡＲＬ２８を用いる必要性を無くす。あるいは、スイッチ１６に関連付けられているＩＰエージェントの間のトランザクションは、ＡＲＬ２８を用いてルーティングされてもよい。このモデルでは、上述したのと同様に、送信元ＩＰエージェントは、宛先ＩＰエージェント１４のアドレスのみを知り、ルーティングに必要な情報は知らない。次いで、ＡＲＬ２８は、ＬＵＴ３０にアクセスし、対応するポートＩＤを見つけるために用いられ、その後、ポートＩＤは、トランザクションのパケットの宛先フィールドに挿入される。
【００６０】
パケットフォーマット
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマットを有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、または、ペイロードが全く無くてもよい。
【００６１】
図２を参照すると、パケットの例３２が示されている。パケット３２は、ヘッダ３４およびペイロード３６を備える。この特定の実施形態において、ヘッダ３４は、１６バイトのサイズである。このサイズは例示であり、より大きいサイズ（例えば、より多いバイト数）または小さいサイズ（例えば、より少ないバイト数）のパケットが用いられてもよいことを理解されたい。パケット３２のヘッダ３４は、必ずしもすべてが同じサイズである必要がないことも理解されたい。代替実施形態において、ＳｏＣにおけるパケットヘッダのサイズは、可変であってもよい。
【００６２】
ヘッダ３４は、宛先識別子（ＤＳＴ＿ＩＤ）、送信元識別子（ＳＲＣ＿ＩＤ）、ペイロードサイズインジケータ（ＰＬＤ＿ＳＺ）、予備フィールド（ＲＳＶＤ）、コマンドフィールド（ＣＭＤ）、ＴＡＧフィールド、ステータス（ＳＴＳ）、トランザクションＩＤフィールド（ＴＡＧ）、アドレスすなわちＡＤＤＲフィールド、ＵＳＤＲ／コンパクトペイロードフィールド、トランザクションクラスすなわちＴＣフィールド、フォーマットＦＭＴフィールド、および、バイトイネーブル（ＢＥ）フィールドなど、複数のフィールドを含む。ヘッダ３４の様々なフィールドについて、以下の表３で簡単に説明する。
【表３】
2021519464.tif 000005
【００６３】
ペイロード３６は、パケットのコンテンツを含む。ペイロードのサイズは、様々であってよい。いくつかの例において、ペイロードは大きくてよい。その他の例において、ペイロードは小さくてもよい。さらに別の例において、コンテンツが非常に小さいすなわち「コンパクト」である場合、ヘッダ３４のＵＳＲＤフィールド内で運ぶことができる。
【００６４】
トランザクションのタイプは、しばしば、トランザクションを表すために用いられる１以上のパケットがペイロードを持つか否かを示す。例えば、ＰｏｓｔｅｄまたはＮｏｎ−ｐｏｓｔｅｄ読み出しのどちらでも、パケットは、アクセスされるロケーションアドレスを指定するが、典型的には、ペイロードを持たない。しかしながら、関連するＣｏｍｐｌｅｔｉｏｎトランザクションのパケットは、読み出しコンテンツを含むペイロードを含む。ＰｏｓｔｅｄおよびＮｏｎ−ｐｏｓｔｅｄ書き込みトランザクションの両方で、パケットは、宛先に書き込まれるデータを含むペイロードを含む。Ｎｏｎ−ｐｏｓｔｅｄバージョンの書き込みでは、Ｃｏｍｐｌｅｔｉｏｎトランザクションのパケットは、通常、ペイロードを定義しない。しかしながら、一部の状況では、Ｃｏｍｐｌｅｔｉｏｎトランザクションが、ペイロードを規定する。
【００６５】
パケットの例および上述の説明は、パケットに含まれうる基本的なフィールドの多くを網羅している。さらなるフィールドが削除または追加されてもよいことを理解されたい。例えば、送信元および宛先がプライベートメッセージを共有できるように、プライベートシグナリングフィールドが用いられてもよい。
【００６６】
アービトレーション
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。
【００６７】
ＰＣＩ順位付けでは、各ポート２０は、各仮想チャネルおよびトランザクションクラス（Ｐ、ＮＰ、および、Ｃ）の組み合わせのための別個のバッファを備える。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ０１、ＶＣ２、および、ＶＣ３）がある場合、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２は各々、１２の先入れ先出しバッファを有する。換言すると、各ポート２０について、バッファが、各トランザクションクラス（Ｐ、ＮＰ、および、Ｃ）ならびに仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３０）の組み合わせに対して提供される。
【００６８】
各ＩＰエージェント１４（例えば、ＩＰ１、ＩＰ２、および、ＩＰ３）がトランザクションを生成すると、結果として得られるパケットが、それぞれ、対応するポート（例えば、ポート０、ポート１、および、ポート２）内で、トランザクションタイプに基づいて、適切なバッファに配置される。例えば、ＩＰ１によって生成されたＰｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションが、それぞれ、ポート０内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ−ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに配置される。ＩＰ２およびＩＰ３によって生成されたトランザクションは、同様の方法でポート１およびポート２内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ−ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに同様に配置される。
【００６９】
所与のトランザクションが複数のパケットによって表される場合、そのトランザクションのパケットすべてが、同じバッファ内に挿入される。結果として、トランザクションのパケットすべてが、最終的に同じ仮想チャネルを介して伝送される。このポリシーでは、仮想チャネルは独立したままであり、これは、同じトランザクションに関連する複数のパケットの伝送には、異なる仮想チャネルが用いられないことを意味する。
【００７０】
各ポート２０内で、多くの異なる方法で所与の仮想チャネルにパケットを割り当てることができる。例えば、割り当ては、無作為であってよい。あるいは、割り当ては、各仮想チャネルに対する作業負荷と未処理のトラフィックの量とに基づいてもよい。或るチャネルが非常にビジーであり、その他のチャネルがビジーではない場合、ポート２０は、しばしば、負荷のバランスを取ろうと試み、新たに生成されたトランザクショントラフィックを利用率の低い仮想チャネルに割り当てる。結果として、ルーティング効率が改善される。さらに別の代替例において、トランザクショントラフィックは、緊急性、セキュリティ、または、それら両方の組み合わせに基づいて、特定の仮想チャネルに割り当てられてもよい。特定の仮想チャネルが、他の仮想チャネルよりも高い優先度および／またはセキュリティを与えられた場合、高い優先度および／または安全なトラフィックが、より高い優先度の仮想チャネルに割り当てられる。さらに別の実施形態において、ポート２０は、ハードコードされてもよく、これは、ポート２０が、１つだけの仮想チャネルを有し、ポート２０によって生成されたすべてのトラフィックが、その１つの仮想チャネルを介して伝送されることを意味する。
【００７１】
さらに別の実施形態において、仮想チャネルの割り当ては、送信元ＩＰエージェント１４によって、単独で、または、それに対応するポート２０と連携して、実施されてもよい。例えば、送信元ＩＰエージェント１４が、対応するポート２０への制御信号を生成して、所与のトランザクションのパケットが特定の仮想チャネルに割り当てられることを要求することができる。ＩＰエージェント１４も、上述のように、無作為である、ハードコードされる、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいた割り当て決定をなすことができる。
【００７２】
アービトレーション勝者の選択において、アービトレーション要素２６は、サイクルごとに複数のアービトレーション工程を実行する。これらのアービトレーション工程は、以下を含む。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。
【００７３】
上述の順序（１）、（２）、および、（３）は、固定ではない。逆に、上述の３つの工程は、任意の順序で完了されてよい。どの順序が用いられるかに関わらず、単一のアービトレーション勝者が各サイクルで選択される。次いで、勝利トランザクションは、相互接続１２に関連付けられている対応する仮想チャネルを介して伝送される。
【００７４】
アービトレーション要素２６によって実行される各アービトレーション（１）、（２）、および、（３）のために、複数のアービトレーションスキームまたはルールセットが用いられてよい。かかるアービトレーションスキームは、厳密または絶対優先度、４つの仮想チャネルの各々が特定の割合のトランザクショントラフックを割り当てられる重み付き優先度、もしくは、トランザクションが所定の順序で仮想チャネルに割り当てられるラウンドロビンスキーム、を含みうる。さらなる実施形態において、その他の優先度スキームが用いられてもよい。また、アービトレーション要素２６は、異なるアービトレーションスキームの間で時々動的に切り替えを行ってもよい、および／または、（１）、（２）、および、（３）アービトレーションの各々に対して同じまたは異なるアービトレーションスキームをそれぞれ用いてもよいことを理解されたい。
【００７５】
任意選択的な実施形態において、所与のアービトレーションサイクル中に考慮された未処理のトランザクションによって定義された宛先ポート２０の利用可能性が考慮される。宛先ポート２０に内のバッファが、所与のトランザクションを処理するために利用可能なリソースを持たない場合、対応する仮想チャネルは利用可能ではない。結果として、当該トランザクションは、アービトレーションで競合せず、むしろ、目標リソースが利用可能になる後続のアービトレーションサイクルまで待機する。一方、目標リソースが利用可能である場合、対応するトランザクションは、アービトレートされ、相互接続１２へのアクセスのために競合する。
【００７６】
宛先ポート２０の利用可能性は、上述した複数のアービトレーション工程（１）、（２）、および、（３）に関して、異なる時にチェックされてよい。例えば、利用可能性チェックは、アービトレーションサイクルの前に（すなわち、工程（１）、（２）、および、（３）のいずれかの完了の前に）実行できる。結果として、利用可能な宛先リソースを規定するトランザクションのみが、後続のアービトレーション中に考慮される。あるいは、アービトレーションチェックは、アービトレーション工程が実行される順序に関わらず、３つのアービトレーション工程（１）、（２）、および、（３）のいずれかの間に実行されてもよい。
【００７７】
アービトレーション処理中の早くまたは遅くに、宛先リソース利用可能性チェックを実行することには利点および不利点がある。早くチェックを実行することにより、トランザクションの競合の可能性のある部分は、それらの宛先が利用可能でない場合に競合から潜在的に排除されうる。しかしながら、利用可能性を早く知ることは、システムリソースへのかなりの量のオーバーヘッドを生み出しうる。結果として、状況に応じて、所与のアービトレーションサイクル中に利用可能性チェックをより遅く実行するのが、より実際的でありうる。
【００７８】
トランザクションクラスの選択を含むアービトレーション工程に対して、複数のルールが、Ｎ、ＮＰ、および、Ｃトランザクションの競合部分の間でアービトレートするために規定される。これらのルールは、以下を含む。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
−Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い越しえない。 
−Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越すことができなければならない。
−Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ  ｏｒｄｅｒ）モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要があり、ルールは緩めることができない。
−Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ  Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが、例外が認められうる。
Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
−Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
−Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
−Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
−Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｎｏｎ−ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
−Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。
【００７９】
以下の表４は、ＰＣＩ順序付けルールの概要を提供する。（ａ）および（ｂ）の選択肢のないボックスでは、厳密順序付けルールが従われる必要はない。（ａ）および（ｂ）の選択肢を有する表のボックスでは、ＲＯビットがリセットされるか設定されるかに依存して、それぞれ、厳密順序（ａ）ルールまたは緩和順序（ｂ）ルールのいずれかが適用されてよい。様々な代替実施形態において、ＲＯビットは、グローバルに、または、パケットレベルで個々に、設定または再設定されうる。
【表４】
2021519464.tif 000006
【００８０】
アービトレーション要素２６は、特定の順序なしに、それぞれ、競合ポート２０、仮想チャネル、および、トランザクションクラスのアービトレーションを実行することによって、最終的な勝利トランザクション部分を選択する。サイクルあたりの勝利部分は、共有相互接続１２にアクセスし、対応する仮想チャネルを介して伝送される。
【００８１】
図３Ｂを参照すると、デバイス順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。アービトレーション処理、および、おそらくは利用可能な宛先リソースの考慮は、２つの違いを除けは、上述したのと基本的に同じである。
【００８２】
第１に、デバイス順序付けでは、（ａ）すべての要求に対する応答が求められるＮｏｎ−ｐｏｓｔｅｄ読み出しまたは書き込みトランザクションと、（ｂ）要求された応答を規定したＣｏｍｐｌｅｔｉｏｎトランザクションとを含め、２つトランザクションクラスだけが定義される。トランザクションクラスが２つだけなので、各ポート２０において仮想チャネルごとに２つのバッファだけがある。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）がある場合、各ポート２０（例えば、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２）は、合計で８つのバッファを有する。
【００８３】
第２に、デバイス順序付けのトランザクションを選択するためのルールも、ＰＣＩ順序付けとは異なる。デバイス順序付けでは、オーバークラスを超える１つのクラスの選択に適用される厳密なルールは存在しない。逆に、いずれかのトランザクションクラスが任意に選択されうる。しかしながら、一般的な方法では、典型的には、Ｃｏｍｐｌｅｔｉｏｎトランザクションが解決するまで利用可能になりえないリソースを解放するように、好都合なＣｏｍｐｌｅｔｉｏｎトランザクションに要求する。
【００８４】
それ以外の点では、デバイス順序付けのためのアービトレーション処理は、基本的に上述したものと同じである。換言すると、各アービトレーションサイクルに対して、アービトレーション勝者を選択するために、アービトレーション工程（１）、（２）、および、（３）が、任意の特定の順で実行される。トランザクションクラスアービトレーションが実行される時、ＰＣＩ順序ルールよりはむしろデバイス順序が利用される。さらに、宛先リソースおよび／または仮想チャネルの利用可能性が、アービトレーション工程（１）、（２）、および、（３）のいずれかの前または間に考慮されてもよい。
【００８５】
動作フローチャート
先述したように、上述のアービトレーションスキームは、任意の共有リソースへのアクセスを共有するために利用されてよく、共有相互接続との利用だけに限定されない。かかる他の共有リソースは、ＡＲＬ２８、処理リソース、メモリリソース（ＬＵＴ３０など）、または、アクセスをめぐって競い合う複数のパーティの間で共有されるほぼ任意のその他のタイプのリソースを含みうる。
【００８６】
図４を参照すると、共有リソースへのアクセスをアービトレートするための動作工程を示すフローチャート４０が示されている。
【００８７】
工程４２において、様々な送信元サブシステムエージェント１４が、トランザクションを生成する。トランザクションは、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む３つのクラスのいずれかでありうる。
【００８８】
工程４４において、送信元サブシステムエージェント１４によって生成されたトランザクションの各々は、パケット化される。先述したように、所与のトランザクションのパケット化は、１以上のパケットをもたらしうる。パケットは、サイズが様々であってよく、一部のパケットは大きいペイロードを持ち、他のパケットは小さいペイロードを持つかまたは全く持たない。トランザクションが、相互接続１２の幅よりも小さいデータペイロード３６を有する単一のパケットによって表される状況では、トランザクションは、単一の部分によって表されうる。トランザクションが、共有リソースのアクセス幅よりも大きいデータペイロード３６を備えた複数のパケットまたは単一のパケットによって表される状況では、複数の部分が、トランザクションを表すために必要とされる。
【００８９】
工程４６において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、対応するポート２０を介してローカルスイッチ１６に投入される。ポート２０内で、各トランザクションのパケットは、仮想チャネルに割り当てられる。先述したように、割り当ては、無作為であるか、ハードコードされるか、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいてよい。
【００９０】
工程４８において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、それぞれ、両方のトランザクションクラスによっておよびそれらに割り当てられた仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）によって、適切な先入れ先出しバッファに格納される。先に述べたように、仮想チャネルは、厳密または絶対優先度、ラウンドロビン、重み付き優先度、最長時間未サービス（ｌｅａｓｔ  ｒｅｃｅｎｔｌｙ  ｓｅｒｖｉｃｅｄ）など、多くの異なる優先度スキームの１つによって割り当てられてよい。所与のトランザクションが複数の部分を有する場合、各部分は、同じバッファ内に格納される。結果として、所与のトランザクションの複数の部分は、相互接続１２に関連付けられている同じ仮想チャネルで伝送される。トランザクション部分が投入されると、各バッファ内のコンテンツアイテム数を追跡するための対応するカウンタがデクリメントされる。特定のバッファが満たされた場合、そのカウンタはゼロにデクリメントされ、これは、バッファがさらなるコンテンツをもはや受け入れることができないことを意味する。
【００９１】
工程５０、５２、および、５４において、第１、第２、および、第３レベルアービトレーションが実行される。先述したように、ポート２０、仮想チャネル、および、トランザクションクラスの選択は、任意の順序で実行されてよい。
【００９２】
要素５６が、第１、第２、および、第３レベルのアービトレーションの実行に用いられるルールを維持するために用いられてよい。各ケースにおいて、要素５６は、アービトレーションレベルの各々を解決するのに必要に応じて用いられる。例えば、要素５６は、ＰＣＩおよび／またはデバイス順序付けルールを維持してよい。要素５６は、いくつかの優先度スキーム（厳密または絶対優先度、重み付き優先度、ラウンドロビンなど）を実行するためのルールと、所与のアービトレーションサイクルでどれを用いるかを決定するためのロジックまたはインテリジェンスと、を備えてもよい。
【００９３】
工程５８において、アービトレーションの勝者が決定される。工程６０において、勝利部分は、共有リソースにアクセスするために用いられるバッファ内に配置され、バッファに関連付けられているカウンタがデクリメントされる。
【００９４】
工程６２において、勝利部分に関連するバッファは、勝利部分がもはやバッファ内にはないのでインクリメントされる。
【００９５】
工程６４において、勝利部分は、共有リソースへアクセスする。アクセスが完了すると、共有リソースのためのバッファがインクリメントされる。
【００９６】
工程４２〜６４は、それぞれ、連続するクロックサイクル中に連続的に繰り返される。異なる勝利部分として、各々が共有リソースへアクセスする。
【００９７】
インターリービング−例１
トランザクションは、いくつかのモードの内の１つで相互接続１２を介して伝送されうる。
【００９８】
「ヘッダインライン（ｈｅａｄｅｒ  ｉｎ−ｌｉｎｅ）」モードと呼ばれる１つのモードでは、トランザクションのパケット３２のヘッダ３４は、常に、それぞれ、別個の部分またはビートでペイロード３６の前に最初に伝送される。ヘッダインラインモードは、相互接続１２のデータビット数Ｎに対するヘッダ３４および／またはペイロード３６の相対サイズに応じて、相互接続１２で利用可能なビットを浪費する場合としない場合がある。例えば、５１２ビット幅（Ｎ＝５１２）である相互接続１２と、１２８ビットのヘッダおよび２５６ビットのペイロードを有するパケットと、を考える。このシナリオでは、１２８ビットのヘッダが第１部分またはビートで伝送され、相互接続１２の残りの３８４ビットの帯域幅は利用されない。第２部分またはビートでは、２５６ビットのペイロード３６が伝送され、相互接続１２の残りの２５６ビットは利用されない。この例では、相互接続の帯域幅のかなりの割合が、２つのビート中に利用されない。一方、トランザクションのパケットのほとんどが相互接続以上のサイズである場合、浪費される帯域幅の程度は、削減されるかあるいは解消される。例えば、３８４または５１２ビットであるヘッダおよび／またはペイロードでは、浪費の量は、大幅に削減されるか（例えば、３８４ビット）または全く解消される（例えば、５１２ビット）。
【００９９】
「ヘッダオンサイドバンド（ｈｅａｄｅｒ  ｏｎ  ｓｉｄｅ−ｂａｎｄ）」と呼ばれる別のモードでは、パケットのヘッダ３４は、データの「サイドで」伝送され、これは、ペイロード３６が相互接続１２のＮデータビットで伝送される間に、制御ビットＭを利用することを意味する。ヘッダオンサイドバンドモードでは、パケット３２のペイロード３６のビット数またはサイズは、所与の相互接続１２でパケットを伝送するのに必要なビート数を決定する。例えば、６４、１２８、２５６、または、５１２ビットのペイロード３６を有するパケット３２、ならびに、１２８データビット（Ｎ＝１２８）を有する相互接続１２の場合、パケットは、それぞれ、１、１、２、および、４ビートを必要とする。ビートの各々の伝送では、ヘッダ情報は、相互接続１２のＮデータビットでペイロードのデータと共にまたはその「サイドで」制御ビットＭで伝送される。
【０１００】
さらに別のモードにおいて、パケット３２のヘッダ３４は、ペイロードと同じように伝送されるが、ヘッダ３４およびペイロード３６が別個の部分またはビートで伝送されなければならない要件はない。パケット３２が、１２８ビットのヘッダ３４および１２８ビットのペイロード３６を有する場合、合計サイズは、２５６ビット（１２８＋１２８）である。相互接続１２のＮデータビットが、６４、１２８、２５６、および、５１２ビット幅である場合、２５６ビットのパケットは、それぞれ、４、２、１、および、１ビートで伝送される。別の例において、パケット３２は、１２８ビットのヘッダおよび２５６ビットのペイロード３６、すなわち、３８４ビット（１２８＋２５６）の合計パケットサイズを有する。６４、１２８、２５６、または、５１２幅のＮデータビットの同じ相互接続１２では、パケットは、それぞれ、６、３、２，または、１ビートで伝送される。このモードは、常に、上述のヘッダインラインモードと少なくとも同等以上の効率である。
【０１０１】
図５を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第１例が図示されている。この例では、簡単のために、２つのトランザクションのみが示されている。２つのトランザクションは、この例では、１２８データビット幅（Ｎ＝１２８）である共有相互接続１２へのアクセスをめぐって競合している。２つのトランザクションの詳細は、以下を含む。
（１）トランザクション１（Ｔ１）：時刻Ｔ１に生成され、仮想チャネルＶＣ２に割り当てられている。Ｔ１のサイズは、４ビートであり、それらのビートは、Ｔ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄとして指定されている。
（２）トランザクション２（Ｔ２）：時刻Ｔ２（時刻Ｔ１の後）に生成され、仮想チャネルＶＣ０に割り当てられている。Ｔ２のサイズは、単一の部分またはビートである。
【０１０２】
この例では、ＶＣＯに絶対または厳密優先度が割り当てられている。複数のサイクルにわたって、２つのトランザクションＴ１およびＴ２の部分が、以下に従って、図５に示すように、共有相互接続で伝送される。
サイクル１：Ｔ１のビートＴ１Ａは、唯一の利用可能なトランザクションであるので、ＶＣ２で伝送される。
サイクル２：Ｔ１のビートＴ１ＢおよびＴ２の単一部分は、相互接続１２へのアクセスをめぐって競合する。ＶＣＯは厳密優先度を有するので、Ｔ２が自動的に勝利する。したがって、Ｔ２のビートは、ＶＣ０で伝送される。
サイクル３：競合するトランザクションがないので、Ｔ１のビートＴ１ＢがＶＣ２で伝送される。
サイクル４：競合するトランザクションがないので、Ｔ１のビートＴ１ＣがＶＣ２で伝送される。
サイクル５：競合するトランザクションがないので、Ｔ１のビートＴ１ＤがＶＣ２で伝送される。
【０１０３】
この例は、以下を示す。（１）絶対優先度を有する仮想チャネルでは、他のトラフィックが先に待っていたか否かに関わらず、トラフィックが利用可能になればいつでも、共有相互接続１２へのアクセス権が即座に与えられること、ならびに、（２）異なるトランザクションの勝利部分またはビートは、相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送されること。この例において、仮想チャネルＶＣＯは、絶対優先度を与えられている。絶対または厳密優先度スキームでは、仮想チャネルのいずれかが、最高優先度を割り当てられてよいことを理解されたい。
【０１０４】
インターリービング−例２
図６を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第２例が図示されている。
【０１０５】
この例において、相互接続１２へのアクセスのための優先度スキームは重み付けされており、これは、ＶＣＯが（４０％）の確率でアクセス権を与えられ、ＶＣ１〜ＶＣ３が各々（２０％）の確率でアクセス権を与えられることを意味する。また、相互接続は、１２８ビット幅である。
【０１０６】
さらに、この例においては、４つの競合するトランザクションＴ１、Ｔ２、Ｔ３、および、Ｔ４が存在する。
−Ｔ１は、ＶＣ０に割り当てられ、４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄを含む。
−Ｔ２は、ＶＣ１に割り当てられ、２つの部分またはビートＴ２ＡおよびＴ２Ｂを含む。
−Ｔ３は、ＶＣ２に割り当てられ、２つの部分またはビートＴ３ＡおよびＴ３Ｂを含む。
−Ｔ４は、ＶＣ３に割り当てられ、２つの部分またはビートＴ４ＡおよびＴ４Ｂを含む。
【０１０７】
この例では、優先度スキームは重み付けされる。結果として、各仮想チャネルは、その重みの比率に従って勝利する。換言すると、１０サイクルの間に、ＶＣ０は、４回勝利し、ＶＣ１、ＶＣ２、および、ＶＣ３は各々、２回勝利する。例えば、図６に示すように、
−Ｔ１の４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄは、１０サイクルのうちの４サイクル（４０％）（すなわち、サイクル１、４、７、および、１０）でＶＣＯを介して伝送され、
−Ｔ２の２つの部分またはビートＴ２ＡおよびＴ２Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル２およびサイクル６）でＶＣ１を介して伝送され、
−Ｔ３の２つの部分またはビートＴ３ＡおよびＴ３Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル５およびサイクル９）でＶＣ２を介して伝送され、
−Ｔ４の２つの部分またはビートＴ４ＡおよびＴ４Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル３およびサイクル８）でＶＣ３を介して伝送される。
【０１０８】
したがって、この例は、以下を示す。（１）各仮想チャネルが所定の比率に基づいて相互接続１２へのアクセス権を与えられる重み付き優先度スキーム、ならびに、（２）異なるトランザクションの勝利部分が相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送される別の例。
【０１０９】
この重み付けの例では、重み付け比率に従って様々な仮想チャネルにトランザクションの部分を割り当てられるのに十分なトラフィックがあることを理解されたい。その一方でトラフィックの量が不十分である場合、重み付け比率は、厳密に実施できる場合も厳密に実施できない場合もある。例えば、仮想チャネルＶＣ３に大きいトラフィックがあり、その他の仮想チャネルＶＣ０、ＶＣ１、および、ＶＣ２ではトラフィックが限られているか全くない場合、ＶＣ３は、重み付け比率が厳密に実施されれば、トラフィックの全部または大部分を運ぶことになる。しかしながら、結果として、すべてのクロックサイクルまたはビートでトランザクションの部分を送信できるわけではないので、相互接続１２は、十分に利用されえない。一方、重み付け比率が厳密に実施されない場合、相互接続の利用率をあげるために、トランザクショントラフィックを再割り当てすることが可能である（例えば、トラフィックが、より多い数のサイクルまたはビートで送信される）。
【０１１０】
上記の２つの例は、上述した伝送モードのどれが利用されるかに関わらず適用可能である。トランザクションが部分またはビートに分割されると、それらは、本明細書で規定したアービトレーションスキームのいずれかを用いて共有相互接続１２でインターリーブされて伝送されうる。
【０１１１】
上述したアービトレーションスキームは、ほんの数例である。その他の例では、低ジッタ、重み付け、厳密、ラウンドロビン、または、ほぼ任意のその他のアービトレーションスキームが用いられてもよい。したがって、本明細書に列挙または記載されたアービトレーションスキームは、例示であり、どのようにも限定と見なされるべきではない。
【０１１２】
複数の同時アービトレーション
ここまで、簡単のために、単一のアービトレーションのみを記載していた。しかしながら、現実的な応用例（ＳｏＣ上など）では、複数のアービトレーションが同時に行われうることを理解されたい。
【０１１３】
図７を参照すると、スイッチ１６、１８の間において２方向でトラフィックを処理するための２つの共有相互接続１２および１２Ｚのブロック図が示されている。上述したように、スイッチ１６は、共有相互接続１２を介して送信元サブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先サブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクショントラフィックを方向付ける。逆方向のトランザクショントラフィックを扱うために、スイッチ１８は、アービトレーション要素２６Ｚと、任意選択的にＡＲＬ２８Ｚと、を備える。動作中、要素２６ＺおよびＡＲＬ２８Ｚは、上述した動作と相補的に動作し、これは、送信元ＩＰエージェント１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）によって生成されたトランザクショントラフィックがアービトレートされて、共有相互接続１２Ｚを介して宛先ＩＰエージェント（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）へ送信されることを意味する。あるいは、アービトレーションは、ＡＲＬ２８Ｚなしに実行されてもよく、これは、アービトレーションが、単に競合ポート２０（例えば、Ｐｏｒｔ３、Ｐｏｒｔ３またはＰｏｒｔ５）の間で決定を行い、勝利ポートに関連するトランザクションの部分が、その部分の最終的な宛先に関わらず、相互接続１２で伝送されることを意味する。要素１２Ｚ、２６Ｚ、および、２８Ｚについては、すでに記載したので、簡単のために詳細な説明は、ここでは提供しない。
【０１１４】
ＳｏＣには、複数レベルのサブファンクション１４および複数の共有相互接続１２が存在しうる。各々で、上述のアービトレーションスキームを用いて、様々なサブファンクションの間で相互接続１２を介して送信されるトランザクションの間のアービトレーションを同時に行うことができる。
【０１１５】
相互接続ファブリック
図８を参照すると、ＳｏＣの例１００が示されている。ＳｏＣ１００は、複数のＩＰエージェント１４（ＩＰ１、ＩＰ２、ＩＰ３、．．．ＩＰＮ）を備える。各ＩＰエージェント１４は、いくつかのノード１０２の内の１つに接続されている。共有相互接続１２、１２Ｚは、逆方向であり、様々なノード１０２の間に提供されている。この構成では、トランザクションが、例えば、図７に関して上述したように、ノード１０２の各ペアの間で両方向に流れうる。
【０１１６】
非排他的な実施形態において、各ノード１０２は、様々なスイッチ１６、１８と、ローカルＩＰエージェント１４に接続するためのアクセスポート２０と、共有相互接続１２、１２Ｚに接続するためのアクセスポート２２と、アービトレーション要素２６と、任意選択的なＡＲＬ２８と、任意選択的なＬＵＴ３０と、を備える。代替実施形態において、ノードは、アービトレーション要素２６および／またはＡＲＬ２８を備えなくてもよい。これらの要素を持たないノード１０２については、必要なルーティング情報のないトランザクションが、上述のようにデフォルトノードへ転送されうる。これらの要素の各々については、図１に関して上述したので、簡単のために詳細な説明は、ここでは提供しない。
【０１１７】
集合的に、様々なノード１０２および双方向相互接続１２、１２Ｚは、ＳｏＣ１００のための相互接続ファブリック１０６を規定する。図に示した相互接続ファブリック１０６は、簡潔にするために比較的単純である。実際の実施形態においては、ＳｏＣ１００上の相互接続ファブリックは、数百または数千ものＩＰエージェント１４、複数レベルのノード１０２を備え、それらすべてが多数の相互接続１２、１２Ｚによって相互接続され、非常に複雑でありうることを理解されたい。
【０１１８】
ブロードキャスト、マルチキャスト、および、エニーキャスト
機械学習または人工知能など、いくつかの応用例では、１つのＩＰエージェント１４によって生成されたトランザクションが、ＳｏＣ１００上の複数のＩＰエージェント１４に広く発信されるのが普通である。複数のＩＰエージェント１４へ広く発信されるトランザクションは、ブロードキャスト、マルチキャスト、または、エニーキャストによって実施されうる。所与のＳｏＣ１００上で、ブロードキャスト、マルチキャスト、および／または、エニーキャストが各々、独自に実施されてもよいし、一緒に実施されてもよい。これらのタイプのトランザクションの各々の簡単な定義を以下に提供する。
・ブロードキャストは、ＳｏＣ１００上のすべてのＩＰエージェントに送信されるトランザクションである。例えば、図８に示したＳｏＣ１００において、ＩＰ１によってブロードキャストが送信された結果として、ＩＰ２〜ＩＰＮが各々、トランザクションを受信することになる。
・マルチキャストは、ＳｏＣ上のＩＰエージェントの内の２以上（潜在的には全部を含む）へ送信されるトランザクションである。例えば、ＩＰ１がＩＰ５、ＩＰ７、および、ＩＰ９を指定するマルチキャストトランザクションを生成した場合、これらのエージェント１４はトランザクションを受信するが、ＳｏＣ１００上の残りのＩＰエージェント１４は受信しない。マルチキャストがＩＰエージェント１４すべてに送信された場合、基本的にはブロードキャストと同じである。
・読み出し応答マルチキャストは、上述したマルチキャストトランザクションの変形例である。読み出し応答マルチキャストでは、単一のＩＰエージェント１４が、メモリロケーションのコンテンツを読み出してよい。開始ＩＰエージェント１４だけがコンテンツを受信するのではなく、多数の宛先ＩＰエージェント１４がコンテンツを受信する。読み出し結果を受信するＩＰエージェント１４は、２以上のＩＰエージェント１４からＳｏＣ１００上のすべてのＩＰエージェント１４までの範囲であってよい。
・エニーキャストは、ＩＰエージェント１４によって生成されるトランザクションである。しかしながら、送信側ＩＰエージェント１４は、目標ＩＰエージェント１４を全く指定しない。その代わり、相互接続ファブリック１０６（すなわち、ノード１０２の内の１以上）が、受信側ＩＰエージェント１４を決定する。例えば、ＩＰ１がエニーキャストトランザクションを生成した場合、ノード１０２の内の１以上のノードが、他のエージェントＩＰ２〜ＩＰＮのどれがトランザクションを受信するかを決定する。エニーキャストトランザクションの様々な実施例において、ＳｏＣ上のＩＰエージェント１４の内の１つ、複数、または、全部が、エニーキャストトランザクションを受信してよい。
【０１１９】
所与のトランザクションが、いくつかの方法で、ブロードキャスト、読み出し応答マルチキャストを含むマルチキャスト、または、エニーキャストとして開始されうる。簡単のために、以下では、これらのトランザクションを集合的に「ＢＭＡ」トランザクションと呼ぶこととし、これは、ブロードキャスト、マルチキャスト（読み出し応答マルチキャストを含む）、または、エニーキャストトランザクションを意味する。
【０１２０】
一実施形態において、ＩＰエージェント１４は、トランザクションを表すパケット３２のヘッダ３４のコマンドフィールドＣＭＤに挿入されたコード化されたコマンドを用いて、ＢＭＡトランザクションを開始してよい。コード化されたコマンドにより、ＳｏＣ１００の相互接続ファブリック１０６は、トランザクションが、１つの送信元および１つの宛先ＩＰエージェント１４を指定する通常のトランザクションではなく、ＢＭＡトランザクションであることを認識または理解する。例えば、ビットの独自の組み合せが、それぞれ、ブロードキャスト、マルチキャスト、読み出し応答マルチキャスト、または、エニーキャストのいずれかとして、所与のトランザクションを規定しうる。
【０１２１】
別の実施形態において、ＢＭＡトランザクションは、トランザクションを表すパケット３２のヘッダ３４のＡＤＤＲフィールドに規定されたＢＭＡアドレスを有する読み出しまたは書き込みしトランザクションを発行することによって実施されうる。ＢＭＡアドレスは、ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションの内の１つを示すものとして、ＳｏＣ１００のシステム内で指定される。結果として、ＢＭＡアドレスは、相互接続ファブリック１０６によって認識され、トランザクションは、ブロードキャスト、マルチキャスト、または、エニーキャストとして扱われる。
【０１２２】
さらに別の実施形態において、コマンドおよびＢＭＡアドレスは両方とも、ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションを指定するために利用できる。
【０１２３】
エニーキャストは、典型的には、送信元ＩＰエージェント１４が複数の宛先にトランザクションを送信したいが、１以上の好ましいまたは理想的な宛先ＩＰエージェント１４を選択するのに役立つ要素に気づかない状況で用いられる。例えば、送信元ＩＰエージェント１４は、各々がアクセラレータ機能を実装する複数のＩＰエージェントにトランザクションを送信しようとしうる。そのトランザクションをエニーキャストとして指定することにより、ノード１０２の内の１以上が、宛先ＩＰエージェント１４の選択に関与する。様々な実施形態において、選択基準は、幅広く変化してよく、混雑状態（ビジーであるＩＰエージェント対アイドル状態すなわちビジーではないＩＰエージェント）、ランダム選択関数、ハードワイヤロジック関数、ハッシュ関数、最長時間未使用の関数、電力消費の考慮、もしくは、任意のその他の決定関数または基準に基づいてよい。したがって、宛先ＩＰエージェント１４を選択する責任は、ノード１０２にシフトされ、ノード１０２は、送信元エージェント１４よりも良好なルーティング決定を行うために、より多くの情報を有しうる。
【０１２４】
図９Ａを参照すると、ＢＭＡアドレッシングをサポートするためのノード１０２のロジックを示す図９０が示されている。ロジック９０は、ＬＵＴ３０と、相互接続ファブリックＩＤ（ＩＦＩＤ）テーブル１２４と、任意選択的な物理リンクセレクタ１２６と、を備える。任意選択的な物理リンクセレクタ１２６は、後に詳述する単一の論理識別子を共有する２つ（以上）の重複物理リソースがある場合（トランキング状況など）に用いられる。
【０１２５】
ＩＦＩＤテーブルは、各ＩＰエージェント１４について、（ａ）ＳｏＣ１００内の各ＩＰエージェント１４を論理的に識別するための対応する論理ＩＰ  ＩＤと、（ｂ）対応するＩＰエージェント１４がノード１０２にローカルである場合のポート２０もしくは（ｃ）対応するＩＰエージェント１４への配信パスに沿って次のノード１０２につながる適切な相互接続１２または１２Ｚへのアクセスポート２２のいずれかと、を含む。この構成では、各ノードは、ＳｏＣ１００内の各ＩＰエージェント１４へトランザクションを配信するのに必要な物理ポート２０および／または２２のアイデンティティにアクセスできる。
【０１２６】
ファブリック１０６内の各ノード１０２のためのＩＦＩＤテーブル１２４は、相対的（すなわち、一意的）である。換言すると、各ＩＦＩＤテーブル１２４は、（１）そのローカルＩＰエージェント１４または（２）ノード１２０へローカルに接続されていないＳｏＣ内の他のＩＰエージェント１４への配信パスに沿った他のノード１０２への共有相互接続１２、１２Ｚ、のいずれかへトランザクションを配信するために必要なポート２０および／または２２のリストだけを含む。この構成では、各ノード１０２は、（１）宛先として指定されたそのローカルＩＰエージェント１４へトランザクションを配信するか、または、（２）別のノード１０２へ相互接続１２、１２Ｚを介してトランザクションを転送するか、のいずれかである。次のノードで、上述の処理が繰り返される。各ノード１０２でトランザクションをローカルに配信するかまたは転送することにより、最終的に、所与のトランザクションが、ＳｏＣ１００のための相互接続ファブリック１０６内の指定された宛先ＩＰエージェント１４すべてに配信される。
【０１２７】
ＬＵＴ３０は、従来のトランザクション（すなわち、単一の宛先ＩＰエージェント１４に送信されるトランザクション）のルーティングに用いられる第１部分１２０である。従来のトランザクションが生成されると、送信元ＩＰエージェント１４は、トランザクションを表すパケットヘッダのＡＤＤＲフィールド内にシステムメモリ２４内の宛先アドレスを規定する。次いで、トランザクションは、ルーティングのためにローカルノード１０２へ提供される。それに応じて、ＡＲＬ２８は、ＬＵＴ３０の第１部分１２０にアクセスして、宛先アドレスに対応する論理ＩＰ  ＩＤを見つける。次いで、ＩＦＩＤテーブル１２４は、（ａ）宛先ＩＰエージェント１４がノード１０２にローカルである場合のポート２０もしくは（ｂ）宛先ＩＰエージェント１４への配信パスに沿って次のノード１０２につながる適切な相互接続１２または１２Ｚへのアクセスポート２２、のいずれかを規定するために、アクセスされる。ＩＰ  ＩＤは、適切なポート２０または２２に沿って送信される前に、パケット３２のヘッダ３４のＤＳＴフィールドに配置される。
【０１２８】
ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションについて、ＬＵＴ３０の第２部分１２２は、複数のＢＭＡアドレス（例えば、ＢＭＡ  １〜ＢＭＡ  Ｎ、ここで、Ｎは、必要に応じてまたは適切に選択されうる任意の数）と、各ＢＭＡアドレスに対応する情報と、を含む。様々な実施形態において、対応する情報は、以下でありうる。
（１）１以上の固有ＩＰ  ＩＤ（例えば、ＢＭＡアドレス１に対してＩＰ４およびＩＰ７、ＢＭＡアドレス２に対してＩＰ５、ＩＰ１２、および、ＩＰ２４）。
（２）一意的なコード（例えば、ＢＭＡアドレス１０および１１に対してコード１およびコード２）。
（３）ビットベクトル（例えば、ＢＭＡアドレス２０および２１のためのビットベクトル）。
【０１２９】
各コードは、宛先ＩＰエージェントの異なるセットを一意的に識別する。例えば、第１コードは、宛先ＩＰエージェントの第１セット（例えば、ＩＰ１、ＩＰ１３、および、ＩＰ２１）を指定するために利用でき、第２コードは、宛先エージェントの別のセット（例えば、ＩＰ４、ＩＰ９、および、ＩＰ１７）を指定するために利用できる。
【０１３０】
ビットベクトルでは、各ビット位置が、ＳｏＣ１００上のＩＰエージェント１４に対応する。所与のビット位置が設定されたか再設定されたかに応じて、対応するＩＰエージェント１４は、それぞれ、宛先であるとしてまたは宛先ではないとして指定される。例として、（１０１０１１．．．１）のビットベクトルは、対応するＩＰエージェント１４（ＩＰ１、ＩＰ３、ＩＰ５、ＩＰ６、および、ＩＰＮ）が設定され、残りが再設定されることを示す。
【０１３１】
上述の実施形態の各々では、１以上の論理ＩＰ  ＩＤが、所与のトランザクションの宛先ＩＰエージェントとして識別される。ＩＦＩＤテーブル１２４は、論理識別子ＩＰ  ＩＤ値を、トランザクションをそれらの宛先にルーティングするのに必要な物理アクセスポート２０および／または２２に変換するために用いられる。ＢＭＡアドレスの場合、正しい物理アクセスポート２０および／または２２が必要とされることを決定するために、一意的なコードまたはビットベクトルが、ＩＰ  ＩＤ値の代わりに用いられてよい。
【０１３２】
コードおよびビットベクトルは両方とも、多数の宛先ＩＰエージェント１４を指定するために利用できる。ビットベクトルは、トランザクションを表すパケット３２のヘッダ３４の宛先フィールドＤＳＴの幅によっておそらくは制限されうる。例えば、宛先フィールドＤＳＴが、３２，６４、１２８、または、２５８ビット幅である場合、ＩＰエージェント１４の最大数は、それぞれ、３２、６４、１２８、および、２５６に制限される。所与のＳｏＣ上のＩＰエージェント１４の数が、宛先フィールドＤＳＴの幅によって特定されうる可能なＩＰエージェントの数をたまたま超えた場合、ヘッダ３４内のその他のフィールドが場合によっては用いられてよく、もしくは、ＤＳＴフィールドが拡張されてもよい。しかしながら、非常に複雑なＳｏＣ１００では、ＩＰエージェント１４の数は、ビットベクトル内で実際的に利用できる利用可能ビット数を超える場合がある。コードでは、任意の数の宛先ＩＰエージェントが指定されてよいので、この問題は回避される。
【０１３３】
図９Ａに関して提供された例は、本質的に例示であり、どのようにも限定を意図しないことを理解されたい。実際の実施形態において、ＳｏＣ１００で利用できるＢＭＡアドレスの数は、１から多数まで幅広く変化してよい。
【０１３４】
ソースベースルーティング（ＳＢＲ）
ソースベースルーティング（ＳＢＲ）は、以下の点で従来のルーティングとは異なる。
（１）送信元ＩＰエージェント１４は、トランザクションの発行時に、相互接続ファブリック１０６に与える何らかの知識または指示を有する。例えば、送信元ＩＰエージェント１４は、それがトランザクションを送信したい宛先ＩＰエージェント１４のＩＰ  ＩＤを知っている。
（２）送信元ＩＰエージェント１４は、トランザクションのパケット３２のパケットヘッダ３４のＡＤＤＲフィールドに通常は提供されるシステムメモリ２４内のアドレスに関心がないおよび／またはそれを知らない。
（３）相互接続ファブリック１０６内のノード１０２は、パケットのヘッダ３４のＡＤＤＲフィールド内のアドレスを単一の宛先ＩＰエージェントのための単一のＩＰ  ＩＤへ単に変換することとは異なる何かを実行することを知っている。
【０１３５】
ブロードキャストおよびマルチキャストは両方とも、おそらくＳＢＲトランザクションでありうるが必ずしもそうではないトランザクションの例である。送信元が、トランザクションのパケット３２のヘッダ３４内で（ａ）ブロードキャストおよび／またはマルチキャストコードおよび（ｂ）宛先ＩＰエージェント１４のいずれかを指定するブロードキャストまたはマルチキャストを発行する場合、トランザクションは、送信元ＩＰエージェントが宛先ＩＰエージェントを指定しているので、ソースベースであると見なされる。一方、送信元が、宛先の具体的な知識を全く持たずにＢＭＡアドレスを用いてブロードキャストまたはマルチキャストトランザクションを開始する場合、トランザクションは、非ソースベースであると見なされる。エニーキャストトランザクションは、宛先ＩＰエージェント１４を規定しないので、ソースベースとは見なされない。
【０１３６】
ハッシング
ハッシングでは、ハッシュ関数が、宛先または宛先までのルートを規定するために用いられる。いくつかの実施例において、ハッシング関数が、複数の宛先および／または複数の宛先までの複数のルートを丁寧に規定してよい。
【０１３７】
図９Ｂを参照すると、ルーティング決定を実施するためのハッシュ関数の利用を説明する図１４０が示されている。この実施形態において、ハッシュ値１４２が、トランザクションを表すパケット３２のヘッダ３４の任意の数のフィールド内に提供される。例えば、アドレスビット、コマンド、送信元エージェントＩＰ、または、ヘッダ３４に含まれる情報またはデータの任意の可能な組合せのサブセットが、ハッシュ値を規定するために用いられてよい。対応するローカルノード１０２内またはＳｏＣ１００上のどこかで、ハッシュ関数１４４が、ハッシュ値１４２に適用される。ハッシュ関数１４４に応答して、ルーティング決定がなされうる。例えば、宛先エージェント１４の１以上のＩＰ  ＩＤが規定されてよい。異なるハッシュ値を提供することにより、異なるルーティング決定が規定されてよい。ハッシングは、ＳｏＣ内での多くの他の用途に用いられてもよいことを理解されたい。１つのかかる用途は、トランキングのためのハッシュ関数の利用である。トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。後に詳述するように、ハッシュ関数は、重複物理リソースの中から選択するために利用できる。
【０１３８】
トランザクショントラフィックの最適化
機械学習、人工知能、データセンターなど、ＳｏＣのいくつかの応用例は、トランザクション集約的でありうる。これらのタイプの応用例は、ブロードキャスト、マルチキャスト、および、エニーキャストに依存する傾向にあり、それにより、トランザクショントラフィックをさらに増大させうる。
【０１３９】
ブロードキャストトランザクションは、相互接続ファブリック１０６を介して送信されるトラフィックの量を著しく増大させうる。
【０１４０】
ボトルネックの発生を低減するために、トランザクショントラフィックを削減する多くの手順が提案されている。かかる手順は、（１）ＳｏＣ１００の相互接続ファブリック１０６のノード１０２でトランザクションを拡大し、応答を統合すること、（２）それぞれ、ペアになった仮想チャネルトランザクションクラスの組み合せによって規定されるストリームで２以上のトランザクションをストリーム内でインターリービングすること、（３）ならびに、共通の論理リンクを共有するＩＰエージェントの間の２以上の物理リンクまたは共通の論理アドレスを共有する２以上の同一のＩＰエージェントを「トランキング」すること、を含む。
【０１４１】
トランザクションの拡大および応答の統合
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングは各々、ＳｏＣ１００上のＩＰエージェント１４の間のトランザクショントラフィックの量を著しく増大させうる。
【０１４２】
ＳｏＣ１００が２５のＩＰエージェントを有し、ＩＰエージェントの１つがブロードキャストトランザクションを生成する場合、最高２４までの個々のトランザクションが、典型的には、その他のＩＰエージェント１４へ相互接続ファブリックを介して送信される。Ｎｏｎ−ｐｏｓｔｅｄ（ＮＰ）トランザクションは、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションの形態の応答を求める。２４のＩＰエージェントへブロードキャストされるトランザクションがＮｏｎ−ｐｏｓｔｅｄである場合、別の２４のＣｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションが同様に生成される。この簡単な例で示すように、ブロードキャストは、相互接続ファブリック１０６で伝送されるトラフィックの量を急速に増大させうる。
【０１４３】
マルチキャストおよびエニーキャストトランザクションも、トラフィックの量を急速に拡大しうる。これらのトランザクションタイプの各々では、複数の受信側が指定されてよく、これは、複数のトランザクションが送信され、おそらくは、複数の完了応答トランザクションが相互接続ファブリック１０６を介して受信されることを意味する。読み出し応答マルチキャストトランザクションでも、読み出されたコンテンツは、複数の宛先ＩＰエージェント１４に送信されうる。結果として、トランザクション量は、これらのタイプのトランザクションでも著しく増大しうる。
【０１４４】
相互接続ファブリック１０６をより効果的に動作させるために、ノード１０２でのトランザクションを拡大して統合する技術を用いて、トラフィックの量を削減する。
【０１４５】
図１０Ａおよび図１０Ｂを参照すると、ＳｏＣの一例を説明する図が示されている。この例において、ＳｏＣは、５個の相互接続されたノード１０２Ａ〜１０２Ｅおよび１０個のＩＰエージェント１４（ＩＰ１〜ＩＰ１０）を備えた相互接続ファブリック１０６を備える。
【０１４６】
図１０Ａを参照すると、ＩＰ１は、Ｎｏｎ−ｐｏｓｔｅｄ書き込みトランザクションをその他のＩＰエージェントＩＰ２〜ＩＰ１０へブロードキャストする。拡大を用いることにより、単一のトランザクションだけが、各共有相互接続１２で送信される。各ダウンストリームノード１０２Ｂ〜１０２Ｅでは、ノードは、（１）トランザクションを任意のローカルＩＰエージェント１４へ提供し、（２）トランザクションを任意のアップストリームノード１０２へ転送する。したがって、この例では、
・ノード１０２Ｂは、トランザクションをＩＰ２に提供し、トランザクションの単一のインスタンス化をそれぞれノード１０２Ｃおよび１０２Ｄへ転送する。
・ノード１０２Ｃでは、トランザクションは、ローカルエージェントＩＰ３、ＩＰ４、および、ＩＰ５へ提供される。
・ノード１０２Ｄは、トランザクションをＩＰ７へ提供する。さらに、ノード１０２Ｄも、トランザクションの単一のインスタンス化をノード１０２Ｅへ転送する。
・ノード１０２Ｅで、トランザクションは、ＩＰ８、ＩＰ９、および、ＩＰ１０へ提供される。
【０１４７】
上記の例では、単一のトランザクションだけが、送信側ＩＰエージェント１４の下流にあるＩＰエージェント１の数に関わらず、各共有相互接続１２で送信される。
【０１４８】
図１０Ｂを参照して、応答トランザクションの統合について説明する。ブロードキャストトランザクションは、Ｎｏｎ−ｐｏｓｔｅｄ書き込みであったので、各宛先エージェントＩＰ２〜ＩＰ１０は、完了トランザクションを返す必要がある。統合では、各ノード１０２Ｂ〜１０２Ｅは、そのローカルＩＰエージェント１４から受信した完了トランザクションを統合し、その後、ノード１０２Ａへ向かって上流へ単一の完了トランザクションのみを送信する。換言すると、
・ノード１０２Ｅは、ＩＰ８〜ＩＰ１０から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２Ｄへ返す。
・ノード１０２Ｄでは、ＩＰ７およびノード１０２Ｅから受信した完了トランザクションが統合され、１つの完了トランザクションがノード１０２Ｂへ返される。
・同様に、ノード１０２Ｃは、ＩＰ３、ＩＰ４、および、ＩＰ５について単一の統合されたトランザクションを返す。
・最後に、ノード１０２Ｂは、ノード１０２Ｃ、１０２Ｄ、および、ＩＰ２から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２ＡおよびＩＰ１へ返す。
【０１４９】
上記の例は、拡大および統合の効率を説明する。拡大がなければ、９個の別個のトランザクション（エージェントＩＰ２〜ＩＰ１０の各々に対して１つずつ）が、相互接続ファブリック１０６を介して伝送される必要がある。しかし、拡大を用いることにより、様々な共有相互接続１２を介して伝送されるトランザクションの数は、４まで削減される。合計９の完了トランザクションも、４つに統合される。
【０１５０】
時々、エラーが発生する可能性があり、完了トランザクションが、受信側ＩＰエージェントＩＰ２〜ＩＰ１０の１以上によって生成されない。エラーは、多くの異なる方法で対処することができる。例えば、成功した完了だけを統合することができ、一方、エラー応答を組み合わせるおよび／または別個に送信することができる。さらに別の代替例において、成功した完了およびエラー完了の両方が統合されてもよいが、成功応答または失敗応答のいずれかを示すように、各々にフラグが付される。
【０１５１】
上記の記載はブロードキャストの文脈で提供されているが、トランザクションの拡大および統合は、マルチキャスティング、読み出し応答マルチキャスティング、および／または、エニーキャスティングで実施されてもよいことを理解されたい。
【０１５２】
ブロードキャスト、マルチキャスト、および、エニーキャストトランザクションが一般的である機械学習、人工知能、データセンターなどのトランザクション集約的な応用例において、拡大および統合することができれば、相互接続ファブリック１０６上のトランザクショントラフィックの量を大幅に削減して、ボトルネックを排除または低減すると共にシステム効率およびパフォーマンスを改善することができる。
【０１５３】
トランキング
ＳｏＣ１００の相互接続ファブリック１０６は、典型的には、各方向に対して、（ａ）ＩＰエージェント１４とローカルノード１０２との間、および、（ｂ）複数のノード１０２の間に、単一の物理リンクを備える。単一のリンクのみがある場合、物理リンクと、その物理リンクのためのアクセスポート２０または２２との間には、一対一の対応関係がある。同様に、ほとんどの相互接続ファブリック１０６で、物理ＩＰエージェント１４と、そのＩＰエージェント１４にアクセスするために用いられる論理ＩＰ  ＩＤとの間にも、一対一の対応関係がある。
【０１５４】
高パフォーマンスの応用例においては、トランキングと呼ばれる技術を用いることが有利でありうる。トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。物理リソースを重複させることにより、ボトルネックを回避することができ、システムの効率およびパフォーマスを向上させることができる。例えば、１つの物理リソースが、ビジーであるか、電源オフであるか、または、利用不可能である場合、重複リソースの１つが利用されうる。トランキングは、信頼性も改善できる。１つの物理リソース（例えば、相互接続またはＩＰエージェントなど）がダウンし、利用不可能になるか、または、何らかの理由で利用できない場合、その他の物理リソースが利用されうる。同じ論理識別子を用いて重複リソースをアドレッシングすることにより、ＳｏＣ１００上で利用される論理アドレッシングシステムを変更する必要なしに、重複物理リソースの利点を実現させることができる。しかしながら、重複物理リソースの内のどれを利用するのかを選択して追跡するのかが課題である。
【０１５５】
図１１Ａを参照すると、いくつかのトランキングの例を含むＳｏＣ１００の相互接続ファブリック１０６が示されている。この例において、相互接続ファブリック１０６は、３つのノード１０２Ａ、１０２Ｂ、および、１０２Ｃを備える。ノード１０２Ａは、２つのＩＰエージェント１４ｉおよび１４２を備える。ノード１０２Ｂは、２つのＩＰエージェント１４３および１４４を備える。ノード１０２Ｃは、１つのＩＰエージェント１４ｓを備える。相互接続ファブリック１０６は、以下のトランキングの例を含む。
・ノード１０２ＡとＩＰエージェント１４２との間の物理的な「トランク」ラインのペア。
・ノード１０２Ａから１０２Ｃの同方向の物理的な「トランク」相互接続１２（１）および１２（２）のペア。
・同一のＩＰエージェント１４ｓのペア。
【０１５６】
これらの例の各々では、論理識別子と物理リソースとの間に一対一の対応関係はない。逆に、２つの利用可能な物理リソースがあるので、どちらの物理リソースを利用するか選択を行う必要がある。
【０１５７】
図１１Ｂを参照すると、（図９Ａの）任意選択的な物理リンクセレクタ１２６を示す図が示されている。上述のように、トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。ＩＦＩＤテーブル１２４が、トランキング状況などで、重複物理リソースを有する論理ＩＰ  ＩＤを識別した時はいつでも、任意選択的な物理リンクセレクタ１２６が、選択を行うために用いられる。物理リンクセレクタ１２６は、物理リソースの利用可能性（またはその欠如）、混雑状態、負荷バランシング、ハッシュ関数、ランダム選択、最長時間未使用の選択、電力条件など、１以上の決定要素を用いて、その選択を行ってよい。例えば、或る物理リソースがビジーである、混雑している、および／または、利用不可能である場合、他の物理リソースが選択される。あるいは、或るリソースが電力消費を削減するために電源オフされている場合、他のリソースが選択されてよい。どのようになされるかに関わらず、選択は、選択された物理リソースにアクセスするために用いられる物理ポート２０または２２の識別につながる。
【０１５８】
非排他的実施形態において、物理リソースの選択は、動作が完了するまで利用されることが好ましい。一連の関連トランザクションが、送信元ＩＰエージェント１４と、宛先ＩＰエージェントの重複ペア（例えば、図１１Ａの２つのＩＰエージェントＩＰ５）との間で送信される場合、すべてのトランザクションが、動作の完了まで同じ宛先ＩＰエージェントに送信される。そうでなければ、データの破損またはその他の問題が発生しうる。重複物理リソースが相互接続である場合、典型的には、同様のアプローチが好ましい。応答（読み出しなど）を求めるトランザクションでは、読み出し要求トランザクションおよび結果応答の両方が、同じ相互接続を介して送信されることが好ましい。さらに、トランザクションのパケットの破損を避けるために、トランザクション全体、および、トランザクションのパケットが、同じパスで同じ宛先へルーティングされることが好ましい。パケットは、リンクを通るために数ビートを必要とし、おそらくは、他の仮想チャネルとインターリーブされうるので、パケットの終了までポートまたはリンクを変えないことが重要である。そうでなければ、パケットの複数のビートは、パケットの部分がシステムを通して移動する時に順序がばらばらになりうるので、それにより情報が破損しうる。要求と同じパスを介して応答をルーティングすることが通常は望ましいが、必須ではない。
【０１５９】
いくつかの非排他的実施形態において、各ビートと共に送信された順序付け情報を用いて、順不同でまたは異なるリソースから受信されたトランザクションのビートを再順序付けする機能を、宛先ＩＰエージェントに提供することが有利でありうる。例えば、制御ビットＭは、パケットの各ビートに対する固有の「ビートカウント数」を特定するために用いられてよい。次いで、パケットのビートは、各ビートと共に送信された固有のビートカウント数を用いて、正確な番号順で宛先ＩＰエージェントによって組み立てられうる。各ビートと共に送信されるビートカウント数を提供することにより、破損に関する上述の問題の多くが解決されうる。
【０１６０】
ストリーム内インターリービング
前述したように、ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。１２のストリームは、完全に独立している。ストリームは、独立しているので、例えば、相互接続ワイヤ１２および１２Ｚなどの共有リソース上でインターリーブされうる。各アービトレーション工程で、仮想チャネルのストリームが選択され、対応するポート２２は、そのトランザクションの残りに対してそのトランザクションにロックされる。別の仮想チャネルを選択して、トランザクションの伝送の完了前に同じポート上でインターリーブすることもできるが、トランザクションが完了するまでは、同じ仮想チャネルの別のストリームを選択することはできない。
【０１６１】
ストリーム内インターリービングは、２つのトランザクションが互いに独立しているという条件では、同じストリームを共有する２以上のトランザクションのインターリービングである。独立したトランザクションの例は、（１）２つの異なるＩＰエージェント１４が、同じストリームを共有するトランザクションを生成すること、および、（２）同じＩＰエージェント１４が、同じストリームを共有する２つのトランザクションを生成するが、生成するＩＰエージェント１４が２つのトランザクションを独立するものとしてマークすること、を含む。トランザクションを独立するものとしてマークすることにより、トランザクションを再順序付けして、インターリービングを用いて配信できることを意味する。ストリーム内インターリービングによれば、トランザクションが完了するまで仮想チャネルのストリームをポートにロックする上述の制約を緩和または排除することができる。ストリーム内インターリービングによれば、（１）２以上の独立したトランザクションをストリーム上でインターリーブすることができ、（２）同じ仮想チャネルに関連する異なるストリームもインターリーブできる。
【０１６２】
ストリーム内インターリービングでは、同じストリーム上でインターリーブされうる２つ（以上）の独立したトランザクションを示すために、さらなる情報が必要である。様々な実施形態において、これは、多くの異なる方法で達成されてよい。一実施形態において、独立したトランザクションのパケットのヘッダ３４は、一意的なトランザクション識別子すなわちＩＤを割り当てられる。一意的なトランザクション識別子を用いることにより、各トランザクションの各ビートは、独立するものとしてフラグを付される。各トランザクションに対する一意的なトランザクションＩＤを用いることにより、様々なノード１０２は、同じストリーム上でインターリーブされる複数の独立したトランザクションのビートを追跡する。
【０１６３】
インターリーブされたトランザクションの所与のペアについて、仮想チャネルおよびトランザクションクラスを指定するビットは同じであるが、各々のためのトランザクションＩＤを表すビットは異なる。
【０１６４】
したがって、制御ビットＭに含まれるさらなるトランザクションＩＤ情報は、送信元および宛先ＩＰエージェント１４の両方および相互接続ファブリック１０６が、同じストリーム上でインターリーブされた時に、或るトランザクションを他のトランザクションに対して認識または区別することを可能にする。
【０１６５】
同期配信対非同期配信
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングでは、同じトランザクションの複数のインスタンス化が、相互接続ファブリック１０６で伝送されてよい。目標となる宛先およびそれらの宛先までのパスの各々が利用可能である場合、各宛先ＩＰエージェント１４は、ネットワーク上で通常の待ち時間だけ遅延して、やがてトランザクションを受信する。一方、パスまたは宛先のいずれかが利用できない（例えば、リソースバッファが満杯である）場合、１以上の利用可能な宛先が、利用できない宛先の前にトランザクションを受信してよい。かかる状況下での異なる到達時間は、２つの異なる実施例の可能性を提起する。
【０１６６】
第１同期または「ブロッキング」実施形態においては、各宛先がほぼ同時にトランザクションを受信することを保証する努力がなされる。換言すると、利用不可能なリソースが利用可能になるまで、利用可能なリソースへのトランザクションの配信が、遅延すなわち「ブロック」されてよい。結果として、指定された受信側の各々によるトランザクションの受信が同期される。この実施形態は、ほぼ同時にトランザクションを受信することが受信側にとって重要である応用例で用いられてよい。
【０１６７】
第２非同期的または非ブロッキング実施形態においては、利用可能な宛先へのトランザクションの配信を遅延させるためのブロッキングの努力がなされない。その代わり、トランザクションの各インスタンス化が、利用可能性に基づいて配信され、これは、利用可能なリソースがトランザクションをすぐに受信する一方で、利用不可能なリソースは、利用可能になった時にトランザクションを受信することを意味する。結果として、非同期的すなわち異なる時間に配信が起こりうる。このアプローチの利点は、利用可能な宛先ＩＰエージェント１４が、すぐにトランザクションを処理でき、他のＩＰエージェントと同期するのを待ってブロックされることがないことである。結果として、遅延が回避される。
【０１６８】
いくつかの実施形態についてのみ詳細に説明したが、ここに提供した本開示の精神や範囲を逸脱することなしに多くの他の形態で本願を実施できることを理解されたい。したがって、これらの実施形態は、例示的なものであって、限定的なものではないとみなされ、本明細書に示した詳細に限定されず、添付の特許請求の範囲および等価物の範囲内で変形されてもよい。
【図１】
2021519464.tif 000007
【図２】
2021519464.tif 000008
【図３Ａ】
2021519464.tif 000009
【図３Ｂ】
2021519464.tif 000010
【図４】
2021519464.tif 000011
【図５】
2021519464.tif 000012
【図６】
2021519464.tif 000013
【図７】
2021519464.tif 000014
【図８】
2021519464.tif 000015
【図９Ａ】
2021519464.tif 000016
【図９Ｂ】
2021519464.tif 000017
【図１０Ａ】
2021519464.tif 000018
【図１０Ｂ】
2021519464.tif 000019
【図１１Ａ】
2021519464.tif 000020
【図１１Ｂ】
2021519464.tif 000021
【国際調査報告】
2021519464.tif 000022
2021519464.tif 000023
2021519464.tif 000024