ホーム > 特許ランキング > Ｇｏｏｇｌｅ ＬＬＣ
知財求人 - 知財ポータルサイト「IP Force」
特許7457654システムオンチップ上の相互接続ファブリック内でソースベースルーティングを実施するための手順
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-19
(45)【発行日】2024-03-28
(54)【発明の名称】システムオンチップ上の相互接続ファブリック内でソースベースルーティングを実施するための手順
(51)【国際特許分類】
G06F 13/362 20060101AFI20240321BHJP
G06F 13/12 20060101ALI20240321BHJP
【ＦＩ】
G06F13/362
G06F13/12 310Z
【請求項の数】
13
(21)【出願番号】P 2020552300
(86)(22)【出願日】2019-03-19
(65)【公表番号】
(43)【公表日】2021-08-10
(86)【国際出願番号】 US2019023001
(87)【国際公開番号】W WO2019190827
(87)【国際公開日】2019-10-03
【審査請求日】2021-12-23
(31)【優先権主張番号】62/650,589
(32)【優先日】2018-03-30
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/800,897
(32)【優先日】2019-02-04
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】502208397
【氏名又は名称】グーグル エルエルシー
【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ
【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】デサイ・シャイレンドラ
(72)【発明者】
【氏名】ピアース・マーク
(72)【発明者】
【氏名】ジェイン・アミト
(72)【発明者】
【氏名】バット・ルトゥル
(72)【発明者】
【氏名】トッテ・ロバート
(72)【発明者】
【氏名】シエラ・ジュアン
(72)【発明者】
【氏名】ガイクワド・パリマル
【審査官】田名網 忠雄
(56)【参考文献】
【文献】国際公開第２０１０／１３７５７２（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１３／００８３７９４（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０２８９０６４（ＵＳ，Ａ１）
【文献】特開２０１４－２０９７６４（ＪＰ，Ａ）
【文献】国際公開第２０１０／０２２７６７（ＷＯ，Ａ１）
【文献】特開２００７－１１５２５２（ＪＰ，Ａ）
【文献】特表２０１７－５０２４２１（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １３／２０－１３／３７８
Ｇ０６Ｆ １３／１０－１４
(57)【特許請求の範囲】
【請求項1】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記ＳＢＲトランザクションは、アドレスを前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定し、前記アドレスは、前記ＳｏＣ上の２以上の宛先ＩＰエージェントを識別するために、前記相互接続ファブリックによって解決される、ＳｏＣ。
【請求項2】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、前記相互接続ファブリックの２つのノードの間で共有相互接続を介して前記ＳＢＲトランザクションの１つのインスタンス化を統合して送信することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、配信パスに沿って２以上の宛先ＩＰエージェントに至る、ＳｏＣ。
【請求項3】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、前記ＳＢＲトランザクションに応答して生成された複数の受信済みの応答トランザクションを統合して、前記相互接続ファブリックのノードの間で共有相互接続を介して前記応答トランザクションの１つのインスタンス化を転送することによって、前記相互接続ファブリックを介して送信されるトランザクショントラフィックを削減するように、前記ルーティング決定を行うよう構成されており、前記共有相互接続は、応答配信パスに沿って前記応答トランザクションの目標に至る、ＳｏＣ。
【請求項4】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリーム上で複数のトランザクションの伝送をインターリーブするように、前記ルーティング決定を行うよう構成されており、（ａ）前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定され、（ｂ）同じトランザクションの１以上の部分が、同じストリームを介して伝送される、ＳｏＣ。
【請求項5】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、さらに、共有相互接続に関連付けられている複数のストリームの中の同じストリームを介して２以上の独立したトランザクションをルーティングするように、前記ルーティング決定を行うよう構成されており、前記複数のストリームの各々は、仮想チャネルおよびトランザクションタイプの一意的な組み合わせによって規定される、ＳｏＣ。
【請求項6】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、共通の論理識別子を共有する重複物理リソースを備え、前記ルーティング決定は、（ａ）前記重複物理リソースの１つを選択すること、（ｂ）前記重複物理リソースの前記選択された１つを用いて前記トランザクションをルーティングすること、とを含む、ＳｏＣ。
【請求項7】
請求項６に記載のＳｏＣであって、前記ルーティング決定は、（ａ）前記重複物理リソースの利用可能性、
（ｂ）前記重複物理リソースの間の相対的な混在状態、
（ｃ）前記重複物理リソースの間の負荷バランシング、
（ｄ）前記重複物理リソースの間のランダム選択、
（ｅ）前記重複物理リソースの間の最長時間未使用選択、
（ｆ）前記重複物理リソースの間の相対的な電力消費、
（ｇ）前記重複物理リソースの間で選択を行うためのハッシュ関数の利用、または、
（ｈ）（ａ）～（ｇ）の任意の組み合わせ、の内の１つに基づく、ＳｏＣ。
【請求項8】
システムオンチップ（ＳｏＣ）であって、相互接続ファブリックと、
前記相互接続ファブリックによって相互接続されている複数のＩＰエージェントであって、前記ＩＰエージェントの間で前記相互接続ファブリックを介して伝送されるトランザクショントラフィックの送信元および宛先になるよう構成されている、複数のＩＰエージェントと、
を備え、
第１ＩＰエージェントは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の１以上の宛先ＩＰエージェントを特定するソースベースルーティング（ＳＢＲ）トランザクションを生成して送信するよう構成されており、
前記相互接続ファブリックは、前記ＳｏＣ上の前記複数のＩＰエージェントの中の前記１以上の宛先ＩＰエージェントへ前記相互接続ファブリックを介して前記ＳＢＲトランザクションをどのようにルーティングして配信するかについてルーティング決定を行うよう構成され、
前記相互接続ファブリックは、さらに、２以上の独立したトランザクションを同じストリームを介してル－ティングするように、前記ルーティング決定を行うよう構成されており、前記２以上の独立したトランザクションは各々、前記２以上の独立したトランザクションが前記同じストリームを介してルーティングされうるように、前記２以上の独立したトランザクションの各々のビートを前記相互接続ファブリックが追跡することを可能にする一意的なトランザクション識別子を割り当てられる、ＳｏＣ。
【請求項9】
請求項８に記載のＳｏＣであって、前記同じストリームを介してルーティングされた前記２以上の独立したトランザクションは、前記同じストリームを指定する共通の制御情報を共有するが、前記２以上の独立したトランザクションの各々の前記トランザクション識別子は一意的である、ＳｏＣ。
【請求項10】
請求項１から９のいずれか一項に記載のＳｏＣであって、前記ＳＢＲトランザクションは、前記ＳｏＣ上の前記１以上の宛先ＩＰエージェントを論理的に識別する識別子を前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定する、ＳｏＣ。
【請求項11】
請求項１から１０のいずれか一項に記載のＳｏＣであって、前記ＳＢＲトランザクションは、一意的なコードを前記トランザクションのヘッダ内に提供することによって、前記１以上の宛先ＩＰエージェントを特定し、前記一意的なコードは、前記ＳｏＣ上の前記１以上の宛先ＩＰエージェントを識別するために、前記相互接続ファブリック内で解決される、ＳｏＣ。
【請求項12】
請求項１から１１のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記複数のノードの各々は、前記ＳＢＲトランザクション内で指定された１以上のアドレスを前記１以上の宛先ＩＰエージェントの１以上の論理識別子に解決するためのルックアップテーブルを備える、ＳｏＣ。
【請求項13】
請求項１から１２のいずれか一項に記載のＳｏＣであって、前記相互接続ファブリックは、複数のノードを備え、前記複数のノードの各々は、前記１以上の宛先ＩＰエージェントの論理識別子を、前記トランザクションをルーティングするために用いられる１以上のポート識別子に変換するためのテーブルを備える、ＳｏＣ。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願への相互参照
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９ （ＰＲＴＩＰ００１Ｐ）号および２０１９年２月４日出願の米国仮出願第６２／８００，８９７ （ＰＲＴ１Ｐ００３Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９ （ＰＲＴＩＰ００１Ｐ）号および２０１９年２月４日出願の米国仮出願第６２／８００，８９７ （ＰＲＴ１Ｐ００３Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。
【0002】
本願は、共有リソースへのアクセスをアービトレートすることに関し、特に、複数のトランザクションの部分の間でアービトレートして、クロックサイクルごとに相互接続に関連付けられている複数の仮想チャネルの１つを介して勝利部分を送信することに関する。
【背景技術】
【0003】
システムオンチップ（「ＳｏＣ」）は、複数のサブシステムを備える集積回路であり、しばしば、知的財産（「ＩＰ」）エージェントまたはコアと呼ばれる。ＩＰエージェントは、典型的には、特定の機能を実装または実行するように設計された回路の「再利用可能な」ブロックである。ＳｏＣの開発者は、典型的には、複数のＩＰエージェントが互いに通信するように、チップ上にそれらのＩＰエージェントをレイアウトして相互接続する。ＩＰエージェントを用いることにより、複雑なＳｏＣを開発する時間およびコストを大幅に削減できる。
【0004】
ＳｏＣの開発者が直面する課題の１つは、様々なＩＰエージェントが相互に動作するように、それらをチップ上で相互接続することである。この問題に対処するために、半導体業界では、相互接続規格を適応させてきた。
【0005】
１つのかかる規格は、英国ケンブリッジにあるＡＲＭ社によって開発および普及されたアドバンスト・マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）である。ＡＭＢＡは、ＳｏＣ上の機能ＩＰエージェントの接続および管理のために幅広く利用されているバス相互接続規格である。
【0006】
ＡＭＢＡでは、トランザクションが、要求を定義し、別個の応答トランザクションを要求する。書き込みトランザクションでは、送信元が、リモート宛先にデータを書き込むことを要求する。書き込み動作が実行されると、宛先は、確認応答トランザクションを送信元に送り返す。書き込み動作は、応答トランザクションが送信元によって受信された時にのみ完了したと見なされる。読み出しトランザクションでは、送信元が、リモートロケーションを読み出すためにアクセスを要求する。読み出しトランザクションは、応答トランザクション（すなわち、アクセスされたコンテンツ）が送信元に返された時にのみ完了する。
【0007】
ＡＭＢＡでは、アービトレーション処理が、複数の競合トランザクションの間の相互接続バスへのアクセスを許可するために用いられる。所与のアービトレーションサイクル中に、競合トランザクションの１つが、勝者として選択される。次いで、相互接続バスは、勝利トランザクションのデータ部の持続期間にわたって制御される。次のアービトレーションサイクルは、現在のトランザクションのためのデータすべてが完了した後にのみ開始する。この処理は、相互接続へのアクセスを巡って競合する複数の未処理のトランザクションがあるという条件で、連続的に繰り返される。
【0008】
ＡＭＢＡ規格の１つの問題は、待ち時間である。バス相互接続は、トランザクションごとにアービトレートされる。トランザクションの任意の部分の間に、トランザクションが読み出し、書き込み、または、応答のいずれであるかに関わらず、バスは、トランザクション全体に対して制御される。トランザクションが開始すると、中断できない。例えば、トランザクションのデータ部が４サイクル長である場合、別のトランザクションがバスへアクセスできる前に、すべての４サイクルが完了する必要がある。結果として、（１）トランザクションは、クロックサイクルごとにはアービトレートできず、（２）すべての非勝利競合トランザクションは、現在のトランザクションのデータ部が完了するまで待機する必要がある。これらの要因の両方が、相互接続の効率およびＳｏＣの全体パフォーマンスを下げる傾向がある。
【発明の概要】
【0009】
システムオンチップすなわちＳｏＣ上の複数のサブシステムの間で共有相互接続へのアクセスをアービトレートするためのアービトレーションシステムおよび方法が開示されている。アービトレーションシステムおよび方法は、クロックサイクルごとに、（１）複数のサブシステムによって生成された複数のトランザクションの部分の間でアービトレートし、（２）複数のトランザクションの部分の中から勝利部分を選択し、（３）相互接続に関連付けられている複数の仮想チャネルの１つを介して勝利部分を伝送するよう構成されているアービトレーション要素を備える。
【0010】
（１）～（３）を繰り返し実行することにより、複数の勝利部分が、それぞれ、複数のクロックサイクルにわたってインターリーブされて複数の仮想チャネルを介して伝送される。クロックサイクルごとに複数の仮想チャネルを介して複数のトランザクション部分のアービトレーションを行うことで、待ち時間の削減、ならびに、相互接続の効率および利用率の上昇など、多くの利点が得られる。これらの属性により、本明細書に開示されたアービトレーションシステムおよび方法は、システムオンチップ（ＳｏＣ）上での相互接続へのアクセスをアービトレートするのに非常に適切になる。
【図面の簡単な説明】
【0011】
本願およびその利点については、添付の図面に関連して行う以下の説明を参照することによって最も良く理解できる。
【0012】
【図1】非排他的実施形態に従って、システムオンチップ（ＳｏＣ）のための共有相互接続を示すブロック図。
【0013】
【図2】非排他的実施形態に従って、トランザクションのパケットの例を示す図。
【0014】
【図3A】第１非排他的実施形態に従って、アービトレーション要素を示す論理図。
【0015】
【図3B】第２非排他的実施形態に従って、アービトレーション要素を示す論理図。
【0016】
【図4】非排他的実施形態に従って、共有相互接続の仮想チャネルを介してトランザクションの部分をアービトレーションして送信するための動作工程を示すフローチャート。
【0017】
【図5】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第１例を示す図。
【0018】
【図6】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第２例を示す図。
【0019】
【図7】本発明の別の非排他的実施形態に従って、二方向にトラフィックを扱うための２つの共有相互接続を示すブロック図。
【0020】
【図8】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックの例を示すブロック図。
【0021】
【図9A】本発明の非排他的実施形態に従って、物理アドレスおよびソースベースルーティング（ＳＢＲ）アドレスの両方を１以上のＩＰポートに解決するために用いられるルックアップテーブル（ＬＵＴ）を示す図。
【0022】
【図9B】本発明の非排他的実施形態に従って、利用できるハッシュ関数を示す図。
【0023】
【図10A】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックを介して送信されるトランザクションの拡大および統合を示す図。
【図10B】本発明の非排他的実施形態に従って、ＳｏＣの相互接続ファブリックを介して送信されるトランザクションの拡大および統合を示す図。
【0024】
【図11A】本発明の非排他的実施形態に従って、トランキングリンクと、トランキングリンクの中からの物理リンクの選択とを示す図。
【図11B】本発明の非排他的実施形態に従って、トランキングリンクと、トランキングリンクの中からの物理リンクの選択とを示す図。
【0025】
図面において、同様の構造要素を指定するために、同様の符号が用いられることがある。また、図中の描写は、図式的なものであり、必ずしも縮尺通りではないことを理解されたい。
【発明を実施するための形態】
【0026】
以下では、添付図面に例示された、いくつかの非排他的な実施形態を参照しつつ、本願の詳細な説明を行う。以下の説明では、本開示の完全な理解を促すために、数多くの具体的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本開示は、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。また、本開示が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造については、詳細な説明を省略した。
【0027】
現在開発中の集積回路の多くは、非常に複雑である。結果として、多くのチップ設計者は、システムオンチップすなわち「ＳｏＣ」アプローチを用いて、単一のシリコン上に複数のサブシステムまたはＩＰエージェントを相互接続してきた。消費者デバイス（例えば、ハンドヘルド、携帯電話、タブレットコンピュータ、ラップトップおよびデスクトップコンピュータ、メデイア処理など）、仮想または拡張現実（例えば、ロボット工学、自律走行車、航空機など）、医療機器（例えば、イメージングなど）、工業、ホームオートメーション、工業（例えば、スマート家電、家庭用監視機器、など）およびデータセンター用途（例えば、ネットワークスイッチ、接続型ストレージデバイス、など）など、様々な用途のためのＳｏＣが、現在利用可能であるかまたは開発されている。
【0028】
本願は、共有リソースへのアクセスをアービトレートするためのアービトレーションシステムおよび方法をおおむね対象にしている。かかる共有リソースは、例えば、バス相互接続、メモリリソース、処理リソース、または、複数の競争パーティの間で共有されたほぼ任意のその他のリソースでありうる。説明の便宜上、以下で詳述する共有リソースは、システムオンチップすなわち「ＳｏＣ」上の複数のサブシステムによって共有される相互接続であるとする。
【0029】
ＳｏＣでは、後に詳述するように、トランザクションの形態で互いにトラフィックをやり取りする複数のサブシステムがあり、共有リソースは、物理的な相互接続であり、様々なトランザクションまたはその部分が、共有相互接続に関連する複数の仮想チャネルを介して伝送され、複数の異なるアービトレーションスキームおよび／または優先度の１つが、サブファンクションの間のトランザクションの伝送に向けた共有相互接続へのアクセスをアービトレートするために用いられてよい。
【0030】
トランザクションクラス
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプまたはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプまたはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。
【表1】
【0031】
Ｐｏｓｔｅｄトランザクション（書き込みなど）は、応答トランザクションを求めない。送信元がデータを指定された宛先に書き込むと、トランザクションが終了する。Ｎｏｎ－ｐｏｓｔｅｄトランザクション（読み出しまたは書き出しのいずれかなど）では、応答が求められる。しかしながら、応答は、別個のＣｏｍｐｌｅｔｉｏｎトランザクションとして分岐される。換言すると、読み出しでは、最初のトランザクションが読み出し動作のために用いられ、別個であるが関連するＣｏｍｐｌｅｔｉｏｎトランザクションが読み出しコンテンツを返すために用いられる。Ｎｏｎ－ｐｏｓｔｅｄ書き込みでは、最初のトランザクションが書き込みのために用いられ、一方、書き込みが完了すると、第２関連Ｃｏｍｐｌｅｔｉｏｎトランザクションが確認のために求められる。
【0032】
トランザクションは、タイプに関わらず、１以上のパケットによって表すことができる。いくつかの状況では、トランザクションは、単一のパケットによって表されうる。別の状況においては、複数のパケットが、トランザクション全体を表すために必要とされうる。
【0033】
ビートは、クロックサイクルあたりに共有相互接続を介して伝送できるデータの量である。例えば、共有相互接続が物理的に１２８ビット幅である場合、１２８ビットが、各ビートまたはクロックサイクルに伝送されうる。
【0034】
いくつかの状況において、トランザクションは、伝送のために複数の部分に分割される必要がありうる。５１２ビット（６４バイト）であるペイロードを有する単一のパケットを有するトランザクションを考える。共有相互接続が１２８ビット幅（１６バイト）のみである場合、トランザクションは、４つの部分（例えば、４×１２８＝５１２）に分割され、４つのクロックサイクルまたはビートで伝送される必要がある。一方、トランザクションが１２８ビット幅未満である単一パケットのみである場合、トランザクション全体が、１つのクロックサイクルまたはビートで送信されうる。同じトランザクションがさらなるパケットをたまたま含む場合、さらなるクロックサイクルまたはビートが必要とされうる。
【0035】
したがって、トランザクションの「部分」という用語は、所与のクロックサイクルまたはビート中に共有相互接続を介して転送できるデータの量である。部分のサイズは、共有相互接続の物理的な幅に応じて変わりうる。例えば、共有相互接続が物理的に６４データビット幅である場合、任意の１サイクルまたはビート中に転送できる最大ビット数は６４ビットである。所与のトランザクションが６４ビット以下のペイロードを有する場合、トランザクション全体が、単一部分で共有相互接続を介して送信されうる。一方、ペイロードがより大きい場合、パケットは、複数の部分で共有相互接続を介して送信されなければならない。１２８、２５６、または、５１２ビットのペイロードを有するトランザクションは、それぞれ、２、４、および、８の部分を必要とする。このように、「部分」という用語は、任意の所与のクロックサイクルまたはビート中に共有相互接続を介して送信されうるトランザクションの一部または全体のいずれかを意味すると広く解釈されるべきである。
【0036】
ストリーム
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々な組み合わせを、以下の表２で詳述する。
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々な組み合わせを、以下の表２で詳述する。
【表2】
【0037】
上述したトランザクションクラスの数は、単に例示であり、限定として解釈すべきではないことに注意されたい。逆に、任意の数の仮想チャネルおよび／またはトランザクションクラスが用いられてよい。
【0038】
共有相互接続の仮想チャネルでのアービトレーション
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非排他的実施形態において、アービトレーションシステムは、アップストリームサブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非排他的実施形態において、アービトレーションシステムは、アップストリームサブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。
【0039】
共有相互接続１２は、Ｎデータビット幅でありＭ個の制御ビットを含む物理的な相互接続である。また、共有相互接続１２は一方向性であり、これは、送信元（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）への方向にのみトラフィックを扱うことを意味する。
【0040】
様々な代替例において、Ｎデータビットの数は、任意の整数であってよいが、典型的には、それぞれ、２のべき乗のビット幅である（例えば、２１、２２、２３、２４、２５、２６、２７、２８、２９など）または（２、４、６、８、１６、３２、６４、１２８、２５６など）。最も現実的な応用例では、Ｎビットの数は、３２、６４、１２８、２５６、または、５１２のいずれかである。ただし、これらの幅は、単に例示であり、どのようにも限定するものとして解釈すべきではないことを理解されたい。
【0041】
制御ビットの数Ｍも、様々であり、任意の数であってよい。
【0042】
１以上の論理チャネル（図示せず）（以降、「仮想チャネル」すなわち「ＶＣ」と呼ぶ）が、共有相互接続１２に関連付けられている。各仮想チャネルは、独立している。各仮想チャネルは、複数の独立ストリームに関連付けられてよい。仮想チャネルの数は、広く変化してよい。例えば、３２以上の数までの仮想チャネルが、規定されるか、または、共有相互接続１２に関連付けられてよい。
【0043】
様々な代替実施形態において、各仮想チャネルは、異なる優先度を割り当てられてよい。１以上の仮想チャネルに、より高い優先度が割り当てられてよく、一方、１以上のその他の仮想チャネルに、より低い優先度が割り当てられてよい。高い優先度のチャネルは、低い優先度の仮想チャネルよりも高い共有相互接続１２へのアクセス権を与えられるまたはアービトレートされる。別の実施形態では、仮想チャネルの各々に、同じ優先度が与えられてもよく、その場合、共有相互接続１２へのアクセス権を与えるまたはアービトレートする時に、或る仮想チャネルを別の仮想チャネルより優先することがない。さらに別の実施形態において、仮想チャネルの内の１以上に割り当てられた優先度は、動的に変化してもよい。例えば、第１セットの状況において、仮想チャネルすべてに、同じ優先度が割り当てられてよいが、第２セットの状況において、特定の仮想チャネルに、その他の仮想チャネルよりも高い優先度が割り当てられてもよい。したがって、状況が変化するにつれて、仮想チャネルの間で用いられる優先度スキームは、現在の動作条件に最もよく合うように変更されうる。
【0044】
サブシステム１４の各々は、典型的には、「再利用可能な」回路またはロジックのブロックであり、一般に、ＩＰコアまたはエージェントと呼ばれる。ほとんどのＩＰエージェントは、特定の機能を実行するよう設計され、例えば、イーサネットポート、ディスプレイドライバ、ＳＤＲＡＭインターフェース、ＵＳＢポートなどの周辺デバイスのためのコントローラである。かかるＩＰエージェントは、一般に、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの集積回路（ＩＣ）上に提供された複雑なシステムの設計全体の中で必要なサブシステム機能を提供する「ビルディングブロック（構成要素）」として用いられる。利用可能なＩＰエージェントのライブラリを用いることにより、チップ設計者は、より複雑な集積回路の設計において様々なロジック機能を容易に「ボルト締め」することができるので、設計時間を削減すると共に開発コストを節約することができる。サブシステムエージェント１４は、専用ＩＰコアに関して上述したが、これは、必要条件ではないことを理解されたい。逆に、サブシステム１４は、単一のポート２０に接続されたまたはそれを共有するＩＰ機能のコレクションであってもよい。したがって、「エージェント」という用語は、サブシステムが単一の機能を実行するか、複数の機能を実行するかに関わらず、ポート２０に接続された任意のタイプのサブシステムとして広く解釈されるべきである。
【0045】
一対のスイッチ１６および１８が、それぞれ、専用アクセスポート２０を介してサブシステムエージェント１４の各々と共有相互接続１２との間のアクセスを提供する。図の例示的実施形態では、
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。
【0046】
スイッチ１６および１８は、多重化および逆多重化機能を実行する。スイッチ１６は、サブシステムエージェントＩＰ１、ＩＰ２、および／または、ＩＰ３によって生成されたアップストリームトラフィックを選択し、共有相互接続１２を介してトラフィックをダウンストリームに送信する。スイッチ１８では、逆多重化動作が実行され、トラフィックは、目標サブシステムエージェント（すなわち、ＩＰ４、ＩＰ５、または、ＩＰ６のいずれか）へ提供される。
【0047】
各アクセスポート２０は、一意ポート識別子（ＩＤ）を有しており、各サブシステムエージェント１４の専用アクセスをスイッチ１６または１８のいずれかへ提供する。例えば、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスポートＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２に割り当てられる。同様に、サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、アクセスポートＰｏｒｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５に割り当てられる。
【0048】
スイッチ１６、１８への／からの入口ポイントおよび出口ポイントを提供するのに加えて、一意ポートＩＤ２０は、サブシステムエージェント１４の間のトラフィックをアドレッシングするために用いられる。各ポート２０は、システムメモリ２４内に、特定の量の割り当てられたアドレス可能空間を有する。
【0049】
いくつかの非排他的な実施形態において、アクセスポート２０の全部または一部に、一意ポートＩＤだけでなく、「グローバル」ポート識別子が割り当てられてもよい。トランザクションおよびその他のトラフィックが、グローバルポート識別子に割り当てられたアクセスポートの全部または一部に送信されうる。したがって、グローバル識別子を用いれば、トランザクションおよびその他のトラフィックが、アクセスポート２０の全部または一部へ広く発信またはブロードキャストすることができ、一意識別子を用いて各アクセスポート２０へ個別にアドレッシングする必要性を排除できる。
【0050】
スイッチ１６は、さらに、アービトレーション要素２６、アドレス解決ロジック（ＡＲＬ）２８、および、アドレス解決ルックアップテーブル（ＬＵＴ）３０を備える。
【0051】
動作中、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、トランザクションを生成する。各トランザクションが生成されると、送信側サブシステム１４によってパケット化され、次いで、パケット化されたトランザクションは、対応するポート２０を介してローカルスイッチ１６へ投入される。例えば、ＩＰ１、ＩＰ２、および、ＩＰ３によって生成されたトランザクションの部分は、それぞれ、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６に提供される。
【0052】
ポート２０は各々、相互接続チャネル１２に関連付けられている仮想チャネルの各々に対して、複数の先入れ先出しバッファ（図示せず）を備える。非排他的実施形態において、４つの仮想チャネルが存在する。その場合、各仮想チャネルに対して１つで、各ポート２０は、４つのバッファを備える。再び、ポート２０に含まれる仮想チャネルおよびバッファの数は、様々であってよく、４に限定されないことを理解されたい。逆に、仮想チャネルおよびバッファの数は、４より多くても少なくてもよい。
【0053】
所与のトランザクションが２つ（以上）の部分で表される場合、それらの部分は、同じバッファ内に維持される。例えば、相互接続１２が１２８データビット幅であり、トランザクションが５１２ビットのペイロードを含むパケットによって表される場合、トランザクションは、４クロックサイクルまたはビートで伝送される４つの部分に分割される必要がある。一方、トランザクションが６４ビットのペイロードを有する単一パケットによって表されうる場合、単一の部分は、１クロックサイクルまたはビートで伝送されうる。所与のトランザクションのすべての部分を同じバッファ内に維持することにより、仮想チャネルは、論理的に独立したままになる。換言すると、所与のトランザクションに関連するトラフィックすべてが、常に、ストリームと同じ仮想チャネルで送信され、複数の仮想チャネルを介して分岐されることがない。
【0054】
アービトレーション要素２６は、様々なアクセスポート２０によって維持されたトランザクションの競合するバッファされた部分の間でアービトレートすることを担う。非排他的実施形態において、複数の競合トランザクションが利用可能であれば、アービトレーション要素２６は、クロックサイクルごとにアービトレーションを実行する。サイクルごとのアービトレーション勝者は、相互接続１２へのアクセスが認められて相互接続１２を介して伝送されるトランザクションの部分を、サブシステムＩＰ１、ＩＰ２、および、ＩＰ３の内の１つから生成する。
【0055】
トランザクションを生成する時、送信元サブシステムＩＰ１、ＩＰ２、および、ＩＰ３は、通常、可能な宛先サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６についてアドレス空間内のアドレスを知っているが、宛先にトランザクションをルーティングするために必要な情報（例えば、ポートＩＤ２０および／または２２）を知らない。一実施形態において、ローカルアドレス解決ロジック（ＡＲＬ）２８は、既知の宛先アドレスを必要なルーティング情報に解決するために用いられる。換言すると、送信元サブエージェント１４は、システムメモリ２４内の所与のアドレスにアクセスしたいことを単に知りうる。したがって、ＡＲＬ２８は、ＬＵＴ３０へアクセスするタスクを課せられ、指定されたアドレスに対応する最終的な宛先への配信パスに沿ってポート２０／２２のアドレスルックアップを実行する。ポート２０／２２が知られると、この情報は、トランザクションのパケット内の宛先フィールドに挿入される。結果として、パケットは、配信パスに沿ってポート２０／２２へ配信される。原則として、要求された配信情報がすでに知られており、パケットの宛先フィールドに含まれているので、配信パスに沿ったダウンストリームノードが、さらなるルックアップを実行する必要はない。後に詳述するようにソースベースルーティング（ＳＢＲ）と呼ばれる他のタイプのトランザクションで、送信元Ｐエージェントは、宛先ポートアドレスを知る。結果として、ＡＲＬ２８によって実行されるルックアップは、典型的には、実行される必要がない。
【0056】
代替実施形態において、相互接続内のすべてのノードがＡＲＬ２８およびＬＵＴ３０を必要とするわけではない。これらの要素を持たないノードについては、必要なルーティング情報のないトランザクションが、デフォルトノードへ転送されうる。デフォルトノードでは、ＡＲＬ２８およびＬＵＴ３０がアクセスされ、次いで、必要なルーティング情報が、トランザクションのパケットのヘッダに挿入されうる。デフォルトノードは、典型的には、ＡＲＬ２８およびＬＵＴ３０を持たないノードよりアップストリームにある。ただし、これは、決して必須ではない。１または複数のデフォルトノードは、ＳｏＣ上のどこに配置されてもよい。ＡＲＬ２８およびＬＵＴ３０をいくつかのノードから排除することにより、ノードの複雑さを低減できる。
【0057】
ＡＲＬ２８は、トランザクションの勝利部分のための転送先のデコードに加えて、各仮想チャネル内のトランザクションの勝利部分のための順序を規定するので、「順序付けポイント」と呼ばれてもよい。各アービトレーションが解決されると、ＡＲＬ２８がアドレスポートルックアップを実行するために用いられるか否かに関わらず、トランザクションの勝利部分が各仮想チャネルに提供される先入れ先出しキューに挿入される。次いで、トランザクションの勝利部分は、バッファ内で相互接続１２を介した伝送の順番を待つ。
【0058】
また、ＡＲＬ２８は、「アップストリーム」および「ダウンストリーム」トラフィックを規定するために用いられる。換言すると、スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）によって生成された任意のトランザクションは、ＡＲＬ２８に対してアップストリームにあると見なされる。ＡＲＬ２８後の（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６に伝送される）すべてのトランザクションが、ダウンストリームトラフィックと見なされる。
【0059】
スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）は、直接的または間接的のいずれかで、互いに通信してトランザクションを互いに送信してよい。直接的な通信（しばしば、ソースベースルーティング（ＳＢＲ）と呼ばれる）により、ＩＰエージェント１４は、ピアツーピアモデルで互いにトランザクションを送信できる。このモデルでは、送信元ＩＰエージェトは、そのピアＩＰエージェント１４の一意ポートＩＤが知っており、ＬＵＴ３０にアクセスするためにＡＲＬ２８を用いる必要性を無くす。あるいは、スイッチ１６に関連付けられているＩＰエージェントの間のトランザクションは、ＡＲＬ２８を用いてルーティングされてもよい。このモデルでは、上述したのと同様に、送信元ＩＰエージェントは、宛先ＩＰエージェント１４のアドレスのみを知り、ルーティングに必要な情報は知らない。次いで、ＡＲＬ２８は、ＬＵＴ３０にアクセスし、対応するポートＩＤを見つけるために用いられ、その後、ポートＩＤは、トランザクションのパケットの宛先フィールドに挿入される。
【0060】
パケットフォーマット
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマットを有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、または、ペイロードが全く無くてもよい。
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマットを有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、または、ペイロードが全く無くてもよい。
【0061】
図２を参照すると、パケットの例３２が示されている。パケット３２は、ヘッダ３４およびペイロード３６を備える。この特定の実施形態において、ヘッダ３４は、１６バイトのサイズである。このサイズは例示であり、より大きいサイズ（例えば、より多いバイト数）または小さいサイズ（例えば、より少ないバイト数）のパケットが用いられてもよいことを理解されたい。パケット３２のヘッダ３４は、必ずしもすべてが同じサイズである必要がないことも理解されたい。代替実施形態において、ＳｏＣにおけるパケットヘッダのサイズは、可変であってもよい。
【0062】
ヘッダ３４は、宛先識別子（ＤＳＴ＿ＩＤ）、送信元識別子（ＳＲＣ＿ＩＤ）、ペイロードサイズインジケータ（ＰＬＤ＿ＳＺ）、予備フィールド（ＲＳＶＤ）、コマンドフィールド（ＣＭＤ）、ＴＡＧフィールド、ステータス（ＳＴＳ）、トランザクションＩＤフィールド（ＴＡＧ）、アドレスすなわちＡＤＤＲフィールド、ＵＳＤＲ／コンパクトペイロードフィールド、トランザクションクラスすなわちＴＣフィールド、フォーマットＦＭＴフィールド、および、バイトイネーブル（ＢＥ）フィールドなど、複数のフィールドを含む。ヘッダ３４の様々なフィールドについて、以下の表３で簡単に説明する。
【表3】
【0063】
ペイロード３６は、パケットのコンテンツを含む。ペイロードのサイズは、様々であってよい。いくつかの例において、ペイロードは大きくてよい。その他の例において、ペイロードは小さくてもよい。さらに別の例において、コンテンツが非常に小さいすなわち「コンパクト」である場合、ヘッダ３４のＵＳＲＤフィールド内で運ぶことができる。
【0064】
トランザクションのタイプは、しばしば、トランザクションを表すために用いられる１以上のパケットがペイロードを持つか否かを示す。例えば、ＰｏｓｔｅｄまたはＮｏｎ－ｐｏｓｔｅｄ読み出しのどちらでも、パケットは、アクセスされるロケーションアドレスを指定するが、典型的には、ペイロードを持たない。しかしながら、関連するＣｏｍｐｌｅｔｉｏｎトランザクションのパケットは、読み出しコンテンツを含むペイロードを含む。ＰｏｓｔｅｄおよびＮｏｎ－ｐｏｓｔｅｄ書き込みトランザクションの両方で、パケットは、宛先に書き込まれるデータを含むペイロードを含む。Ｎｏｎ－ｐｏｓｔｅｄバージョンの書き込みでは、Ｃｏｍｐｌｅｔｉｏｎトランザクションのパケットは、通常、ペイロードを定義しない。しかしながら、一部の状況では、Ｃｏｍｐｌｅｔｉｏｎトランザクションが、ペイロードを規定する。
【0065】
パケットの例および上述の説明は、パケットに含まれうる基本的なフィールドの多くを網羅している。さらなるフィールドが削除または追加されてもよいことを理解されたい。例えば、送信元および宛先がプライベートメッセージを共有できるように、プライベートシグナリングフィールドが用いられてもよい。
【0066】
アービトレーション
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。
【0067】
ＰＣＩ順位付けでは、各ポート２０は、各仮想チャネルおよびトランザクションクラス（Ｐ、ＮＰ、および、Ｃ）の組み合わせのための別個のバッファを備える。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ０１、ＶＣ２、および、ＶＣ３）がある場合、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２は各々、１２の先入れ先出しバッファを有する。換言すると、各ポート２０について、バッファが、各トランザクションクラス（Ｐ、ＮＰ、および、Ｃ）ならびに仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３０）の組み合わせに対して提供される。
【0068】
各ＩＰエージェント１４（例えば、ＩＰ１、ＩＰ２、および、ＩＰ３）がトランザクションを生成すると、結果として得られるパケットが、それぞれ、対応するポート（例えば、ポート０、ポート１、および、ポート２）内で、トランザクションタイプに基づいて、適切なバッファに配置される。例えば、ＩＰ１によって生成されたＰｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションが、それぞれ、ポート０内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ－ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに配置される。ＩＰ２およびＩＰ３によって生成されたトランザクションは、同様の方法でポート１およびポート２内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ－ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに同様に配置される。
【0069】
所与のトランザクションが複数のパケットによって表される場合、そのトランザクションのパケットすべてが、同じバッファ内に挿入される。結果として、トランザクションのパケットすべてが、最終的に同じ仮想チャネルを介して伝送される。このポリシーでは、仮想チャネルは独立したままであり、これは、同じトランザクションに関連する複数のパケットの伝送には、異なる仮想チャネルが用いられないことを意味する。
【0070】
各ポート２０内で、多くの異なる方法で所与の仮想チャネルにパケットを割り当てることができる。例えば、割り当ては、無作為であってよい。あるいは、割り当ては、各仮想チャネルに対する作業負荷と未処理のトラフィックの量とに基づいてもよい。或るチャネルが非常にビジーであり、その他のチャネルがビジーではない場合、ポート２０は、しばしば、負荷のバランスを取ろうと試み、新たに生成されたトランザクショントラフィックを利用率の低い仮想チャネルに割り当てる。結果として、ルーティング効率が改善される。さらに別の代替例において、トランザクショントラフィックは、緊急性、セキュリティ、または、それら両方の組み合わせに基づいて、特定の仮想チャネルに割り当てられてもよい。特定の仮想チャネルが、他の仮想チャネルよりも高い優先度および／またはセキュリティを与えられた場合、高い優先度および／または安全なトラフィックが、より高い優先度の仮想チャネルに割り当てられる。さらに別の実施形態において、ポート２０は、ハードコードされてもよく、これは、ポート２０が、１つだけの仮想チャネルを有し、ポート２０によって生成されたすべてのトラフィックが、その１つの仮想チャネルを介して伝送されることを意味する。
【0071】
さらに別の実施形態において、仮想チャネルの割り当ては、送信元ＩＰエージェント１４によって、単独で、または、それに対応するポート２０と連携して、実施されてもよい。例えば、送信元ＩＰエージェント１４が、対応するポート２０への制御信号を生成して、所与のトランザクションのパケットが特定の仮想チャネルに割り当てられることを要求することができる。ＩＰエージェント１４も、上述のように、無作為である、ハードコードされる、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいた割り当て決定をなすことができる。
【0072】
アービトレーション勝者の選択において、アービトレーション要素２６は、サイクルごとに複数のアービトレーション工程を実行する。これらのアービトレーション工程は、以下を含む。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。
【0073】
上述の順序（１）、（２）、および、（３）は、固定ではない。逆に、上述の３つの工程は、任意の順序で完了されてよい。どの順序が用いられるかに関わらず、単一のアービトレーション勝者が各サイクルで選択される。次いで、勝利トランザクションは、相互接続１２に関連付けられている対応する仮想チャネルを介して伝送される。
【0074】
アービトレーション要素２６によって実行される各アービトレーション（１）、（２）、および、（３）のために、複数のアービトレーションスキームまたはルールセットが用いられてよい。かかるアービトレーションスキームは、厳密または絶対優先度、４つの仮想チャネルの各々が特定の割合のトランザクショントラフックを割り当てられる重み付き優先度、もしくは、トランザクションが所定の順序で仮想チャネルに割り当てられるラウンドロビンスキーム、を含みうる。さらなる実施形態において、その他の優先度スキームが用いられてもよい。また、アービトレーション要素２６は、異なるアービトレーションスキームの間で時々動的に切り替えを行ってもよい、および／または、（１）、（２）、および、（３）アービトレーションの各々に対して同じまたは異なるアービトレーションスキームをそれぞれ用いてもよいことを理解されたい。
【0075】
任意選択的な実施形態において、所与のアービトレーションサイクル中に考慮された未処理のトランザクションによって定義された宛先ポート２０の利用可能性が考慮される。宛先ポート２０に内のバッファが、所与のトランザクションを処理するために利用可能なリソースを持たない場合、対応する仮想チャネルは利用可能ではない。結果として、当該トランザクションは、アービトレーションで競合せず、むしろ、目標リソースが利用可能になる後続のアービトレーションサイクルまで待機する。一方、目標リソースが利用可能である場合、対応するトランザクションは、アービトレートされ、相互接続１２へのアクセスのために競合する。
【0076】
宛先ポート２０の利用可能性は、上述した複数のアービトレーション工程（１）、（２）、および、（３）に関して、異なる時にチェックされてよい。例えば、利用可能性チェックは、アービトレーションサイクルの前に（すなわち、工程（１）、（２）、および、（３）のいずれかの完了の前に）実行できる。結果として、利用可能な宛先リソースを規定するトランザクションのみが、後続のアービトレーション中に考慮される。あるいは、アービトレーションチェックは、アービトレーション工程が実行される順序に関わらず、３つのアービトレーション工程（１）、（２）、および、（３）のいずれかの間に実行されてもよい。
【0077】
アービトレーション処理中の早くまたは遅くに、宛先リソース利用可能性チェックを実行することには利点および不利点がある。早くチェックを実行することにより、トランザクションの競合の可能性のある部分は、それらの宛先が利用可能でない場合に競合から潜在的に排除されうる。しかしながら、利用可能性を早く知ることは、システムリソースへのかなりの量のオーバーヘッドを生み出しうる。結果として、状況に応じて、所与のアービトレーションサイクル中に利用可能性チェックをより遅く実行するのが、より実際的でありうる。
【0078】
トランザクションクラスの選択を含むアービトレーション工程に対して、複数のルールが、Ｎ、ＮＰ、および、Ｃトランザクションの競合部分の間でアービトレートするために規定される。これらのルールは、以下を含む。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
－Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い越しえない。
－Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことができなければならない。
－Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ ｏｒｄｅｒ）モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要があり、ルールは緩めることができない。
－Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが、例外が認められうる。
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
－Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い越しえない。
－Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことができなければならない。
－Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ ｏｒｄｅｒ）モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要があり、ルールは緩めることができない。
－Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが、例外が認められうる。
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有する場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。
【0079】
以下の表４は、ＰＣＩ順序付けルールの概要を提供する。（ａ）および（ｂ）の選択肢のないボックスでは、厳密順序付けルールが従われる必要はない。（ａ）および（ｂ）の選択肢を有する表のボックスでは、ＲＯビットがリセットされるか設定されるかに依存して、それぞれ、厳密順序（ａ）ルールまたは緩和順序（ｂ）ルールのいずれかが適用されてよい。様々な代替実施形態において、ＲＯビットは、グローバルに、または、パケットレベルで個々に、設定または再設定されうる。
【表4】
【0080】
アービトレーション要素２６は、特定の順序なしに、それぞれ、競合ポート２０、仮想チャネル、および、トランザクションクラスのアービトレーションを実行することによって、最終的な勝利トランザクション部分を選択する。サイクルあたりの勝利部分は、共有相互接続１２にアクセスし、対応する仮想チャネルを介して伝送される。
【0081】
図３Ｂを参照すると、デバイス順位付けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す論理図が示されている。アービトレーション処理、および、おそらくは利用可能な宛先リソースの考慮は、２つの違いを除けは、上述したのと基本的に同じである。
【0082】
第１に、デバイス順序付けでは、（ａ）すべての要求に対する応答が求められるＮｏｎ－ｐｏｓｔｅｄ読み出しまたは書き込みトランザクションと、（ｂ）要求された応答を規定したＣｏｍｐｌｅｔｉｏｎトランザクションとを含め、２つトランザクションクラスだけが定義される。トランザクションクラスが２つだけなので、各ポート２０において仮想チャネルごとに２つのバッファだけがある。例えば、４つの仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）がある場合、各ポート２０（例えば、Ｐｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２）は、合計で８つのバッファを有する。
【0083】
第２に、デバイス順序付けのトランザクションを選択するためのルールも、ＰＣＩ順序付けとは異なる。デバイス順序付けでは、オーバークラスを超える１つのクラスの選択に適用される厳密なルールは存在しない。逆に、いずれかのトランザクションクラスが任意に選択されうる。しかしながら、一般的な方法では、典型的には、Ｃｏｍｐｌｅｔｉｏｎトランザクションが解決するまで利用可能になりえないリソースを解放するように、好都合なＣｏｍｐｌｅｔｉｏｎトランザクションに要求する。
【0084】
それ以外の点では、デバイス順序付けのためのアービトレーション処理は、基本的に上述したものと同じである。換言すると、各アービトレーションサイクルに対して、アービトレーション勝者を選択するために、アービトレーション工程（１）、（２）、および、（３）が、任意の特定の順で実行される。トランザクションクラスアービトレーションが実行される時、ＰＣＩ順序ルールよりはむしろデバイス順序が利用される。さらに、宛先リソースおよび／または仮想チャネルの利用可能性が、アービトレーション工程（１）、（２）、および、（３）のいずれかの前または間に考慮されてもよい。
【0085】
動作フローチャート
先述したように、上述のアービトレーションスキームは、任意の共有リソースへのアクセスを共有するために利用されてよく、共有相互接続との利用だけに限定されない。かかる他の共有リソースは、ＡＲＬ２８、処理リソース、メモリリソース（ＬＵＴ３０など）、または、アクセスをめぐって競い合う複数のパーティの間で共有されるほぼ任意のその他のタイプのリソースを含みうる。
先述したように、上述のアービトレーションスキームは、任意の共有リソースへのアクセスを共有するために利用されてよく、共有相互接続との利用だけに限定されない。かかる他の共有リソースは、ＡＲＬ２８、処理リソース、メモリリソース（ＬＵＴ３０など）、または、アクセスをめぐって競い合う複数のパーティの間で共有されるほぼ任意のその他のタイプのリソースを含みうる。
【0086】
図４を参照すると、共有リソースへのアクセスをアービトレートするための動作工程を示すフローチャート４０が示されている。
【0087】
工程４２において、様々な送信元サブシステムエージェント１４が、トランザクションを生成する。トランザクションは、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む３つのクラスのいずれかでありうる。
【0088】
工程４４において、送信元サブシステムエージェント１４によって生成されたトランザクションの各々は、パケット化される。先述したように、所与のトランザクションのパケット化は、１以上のパケットをもたらしうる。パケットは、サイズが様々であってよく、一部のパケットは大きいペイロードを持ち、他のパケットは小さいペイロードを持つかまたは全く持たない。トランザクションが、相互接続１２の幅よりも小さいデータペイロード３６を有する単一のパケットによって表される状況では、トランザクションは、単一の部分によって表されうる。トランザクションが、共有リソースのアクセス幅よりも大きいデータペイロード３６を備えた複数のパケットまたは単一のパケットによって表される状況では、複数の部分が、トランザクションを表すために必要とされる。
【0089】
工程４６において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、対応するポート２０を介してローカルスイッチ１６に投入される。ポート２０内で、各トランザクションのパケットは、仮想チャネルに割り当てられる。先述したように、割り当ては、無作為であるか、ハードコードされるか、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリティ、緊急性などに基づいてよい。
【0090】
工程４８において、サブシステムエージェント１４の各々によって生成されたパケット化トランザクションの部分は、それぞれ、両方のトランザクションクラスによっておよびそれらに割り当てられた仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）によって、適切な先入れ先出しバッファに格納される。先に述べたように、仮想チャネルは、厳密または絶対優先度、ラウンドロビン、重み付き優先度、最長時間未サービス（ｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｓｅｒｖｉｃｅｄ）など、多くの異なる優先度スキームの１つによって割り当てられてよい。所与のトランザクションが複数の部分を有する場合、各部分は、同じバッファ内に格納される。結果として、所与のトランザクションの複数の部分は、相互接続１２に関連付けられている同じ仮想チャネルで伝送される。トランザクション部分が投入されると、各バッファ内のコンテンツアイテム数を追跡するための対応するカウンタがデクリメントされる。特定のバッファが満たされた場合、そのカウンタはゼロにデクリメントされ、これは、バッファがさらなるコンテンツをもはや受け入れることができないことを意味する。
【0091】
工程５０、５２、および、５４において、第１、第２、および、第３レベルアービトレーションが実行される。先述したように、ポート２０、仮想チャネル、および、トランザクションクラスの選択は、任意の順序で実行されてよい。
【0092】
要素５６が、第１、第２、および、第３レベルのアービトレーションの実行に用いられるルールを維持するために用いられてよい。各ケースにおいて、要素５６は、アービトレーションレベルの各々を解決するのに必要に応じて用いられる。例えば、要素５６は、ＰＣＩおよび／またはデバイス順序付けルールを維持してよい。要素５６は、いくつかの優先度スキーム（厳密または絶対優先度、重み付き優先度、ラウンドロビンなど）を実行するためのルールと、所与のアービトレーションサイクルでどれを用いるかを決定するためのロジックまたはインテリジェンスと、を備えてもよい。
【0093】
工程５８において、アービトレーションの勝者が決定される。工程６０において、勝利部分は、共有リソースにアクセスするために用いられるバッファ内に配置され、バッファに関連付けられているカウンタがデクリメントされる。
【0094】
工程６２において、勝利部分に関連するバッファは、勝利部分がもはやバッファ内にはないのでインクリメントされる。
【0095】
工程６４において、勝利部分は、共有リソースへアクセスする。アクセスが完了すると、共有リソースのためのバッファがインクリメントされる。
【0096】
工程４２～６４は、それぞれ、連続するクロックサイクル中に連続的に繰り返される。異なる勝利部分として、各々が共有リソースへアクセスする。
【0097】
インターリービング－例１
トランザクションは、いくつかのモードの内の１つで相互接続１２を介して伝送されうる。
トランザクションは、いくつかのモードの内の１つで相互接続１２を介して伝送されうる。
【0098】
「ヘッダインライン（ｈｅａｄｅｒ ｉｎ－ｌｉｎｅ）」モードと呼ばれる１つのモードでは、トランザクションのパケット３２のヘッダ３４は、常に、それぞれ、別個の部分またはビートでペイロード３６の前に最初に伝送される。ヘッダインラインモードは、相互接続１２のデータビット数Ｎに対するヘッダ３４および／またはペイロード３６の相対サイズに応じて、相互接続１２で利用可能なビットを浪費する場合としない場合がある。例えば、５１２ビット幅（Ｎ＝５１２）である相互接続１２と、１２８ビットのヘッダおよび２５６ビットのペイロードを有するパケットと、を考える。このシナリオでは、１２８ビットのヘッダが第１部分またはビートで伝送され、相互接続１２の残りの３８４ビットの帯域幅は利用されない。第２部分またはビートでは、２５６ビットのペイロード３６が伝送され、相互接続１２の残りの２５６ビットは利用されない。この例では、相互接続の帯域幅のかなりの割合が、２つのビート中に利用されない。一方、トランザクションのパケットのほとんどが相互接続以上のサイズである場合、浪費される帯域幅の程度は、削減されるかあるいは解消される。例えば、３８４または５１２ビットであるヘッダおよび／またはペイロードでは、浪費の量は、大幅に削減されるか（例えば、３８４ビット）または全く解消される（例えば、５１２ビット）。
【0099】
「ヘッダオンサイドバンド（ｈｅａｄｅｒ ｏｎ ｓｉｄｅ－ｂａｎｄ）」と呼ばれる別のモードでは、パケットのヘッダ３４は、データの「サイドで」伝送され、これは、ペイロード３６が相互接続１２のＮデータビットで伝送される間に、制御ビットＭを利用することを意味する。ヘッダオンサイドバンドモードでは、パケット３２のペイロード３６のビット数またはサイズは、所与の相互接続１２でパケットを伝送するのに必要なビート数を決定する。例えば、６４、１２８、２５６、または、５１２ビットのペイロード３６を有するパケット３２、ならびに、１２８データビット（Ｎ＝１２８）を有する相互接続１２の場合、パケットは、それぞれ、１、１、２、および、４ビートを必要とする。ビートの各々の伝送では、ヘッダ情報は、相互接続１２のＮデータビットでペイロードのデータと共にまたはその「サイドで」制御ビットＭで伝送される。
【0100】
さらに別のモードにおいて、パケット３２のヘッダ３４は、ペイロードと同じように伝送されるが、ヘッダ３４およびペイロード３６が別個の部分またはビートで伝送されなければならない要件はない。パケット３２が、１２８ビットのヘッダ３４および１２８ビットのペイロード３６を有する場合、合計サイズは、２５６ビット（１２８＋１２８）である。相互接続１２のＮデータビットが、６４、１２８、２５６、および、５１２ビット幅である場合、２５６ビットのパケットは、それぞれ、４、２、１、および、１ビートで伝送される。別の例において、パケット３２は、１２８ビットのヘッダおよび２５６ビットのペイロード３６、すなわち、３８４ビット（１２８＋２５６）の合計パケットサイズを有する。６４、１２８、２５６、または、５１２幅のＮデータビットの同じ相互接続１２では、パケットは、それぞれ、６、３、２，または、１ビートで伝送される。このモードは、常に、上述のヘッダインラインモードと少なくとも同等以上の効率である。
【0101】
図５を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第１例が図示されている。この例では、簡単のために、２つのトランザクションのみが示されている。２つのトランザクションは、この例では、１２８データビット幅（Ｎ＝１２８）である共有相互接続１２へのアクセスをめぐって競合している。２つのトランザクションの詳細は、以下を含む。
（１）トランザクション１（Ｔ１）：時刻Ｔ１に生成され、仮想チャネルＶＣ２に割り当てられている。Ｔ１のサイズは、４ビートであり、それらのビートは、Ｔ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄとして指定されている。
（２）トランザクション２（Ｔ２）：時刻Ｔ２（時刻Ｔ１の後）に生成され、仮想チャネルＶＣ０に割り当てられている。Ｔ２のサイズは、単一の部分またはビートである。
（１）トランザクション１（Ｔ１）：時刻Ｔ１に生成され、仮想チャネルＶＣ２に割り当てられている。Ｔ１のサイズは、４ビートであり、それらのビートは、Ｔ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄとして指定されている。
（２）トランザクション２（Ｔ２）：時刻Ｔ２（時刻Ｔ１の後）に生成され、仮想チャネルＶＣ０に割り当てられている。Ｔ２のサイズは、単一の部分またはビートである。
【0102】
この例では、ＶＣＯに絶対または厳密優先度が割り当てられている。複数のサイクルにわたって、２つのトランザクションＴ１およびＴ２の部分が、以下に従って、図５に示すように、共有相互接続で伝送される。
サイクル１：Ｔ１のビートＴ１Ａは、唯一の利用可能なトランザクションであるので、ＶＣ２で伝送される。
サイクル２：Ｔ１のビートＴ１ＢおよびＴ２の単一部分は、相互接続１２へのアクセスをめぐって競合する。ＶＣＯは厳密優先度を有するので、Ｔ２が自動的に勝利する。したがって、Ｔ２のビートは、ＶＣ０で伝送される。
サイクル３：競合するトランザクションがないので、Ｔ１のビートＴ１ＢがＶＣ２で伝送される。
サイクル４：競合するトランザクションがないので、Ｔ１のビートＴ１ＣがＶＣ２で伝送される。
サイクル５：競合するトランザクションがないので、Ｔ１のビートＴ１ＤがＶＣ２で伝送される。
サイクル１：Ｔ１のビートＴ１Ａは、唯一の利用可能なトランザクションであるので、ＶＣ２で伝送される。
サイクル２：Ｔ１のビートＴ１ＢおよびＴ２の単一部分は、相互接続１２へのアクセスをめぐって競合する。ＶＣＯは厳密優先度を有するので、Ｔ２が自動的に勝利する。したがって、Ｔ２のビートは、ＶＣ０で伝送される。
サイクル３：競合するトランザクションがないので、Ｔ１のビートＴ１ＢがＶＣ２で伝送される。
サイクル４：競合するトランザクションがないので、Ｔ１のビートＴ１ＣがＶＣ２で伝送される。
サイクル５：競合するトランザクションがないので、Ｔ１のビートＴ１ＤがＶＣ２で伝送される。
【0103】
この例は、以下を示す。（１）絶対優先度を有する仮想チャネルでは、他のトラフィックが先に待っていたか否かに関わらず、トラフィックが利用可能になればいつでも、共有相互接続１２へのアクセス権が即座に与えられること、ならびに、（２）異なるトランザクションの勝利部分またはビートは、相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送されること。この例において、仮想チャネルＶＣＯは、絶対優先度を与えられている。絶対または厳密優先度スキームでは、仮想チャネルのいずれかが、最高優先度を割り当てられてよいことを理解されたい。
【0104】
インターリービング－例２
図６を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第２例が図示されている。
図６を参照すると、複数の仮想チャネル上での異なるトランザクションの部分のインターリービングの第２例が図示されている。
【0105】
この例において、相互接続１２へのアクセスのための優先度スキームは重み付けされており、これは、ＶＣＯが（４０％）の確率でアクセス権を与えられ、ＶＣ１～ＶＣ３が各々（２０％）の確率でアクセス権を与えられることを意味する。また、相互接続は、１２８ビット幅である。
【0106】
さらに、この例においては、４つの競合するトランザクションＴ１、Ｔ２、Ｔ３、および、Ｔ４が存在する。
－Ｔ１は、ＶＣ０に割り当てられ、４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄを含む。
－Ｔ２は、ＶＣ１に割り当てられ、２つの部分またはビートＴ２ＡおよびＴ２Ｂを含む。
－Ｔ３は、ＶＣ２に割り当てられ、２つの部分またはビートＴ３ＡおよびＴ３Ｂを含む。
－Ｔ４は、ＶＣ３に割り当てられ、２つの部分またはビートＴ４ＡおよびＴ４Ｂを含む。
－Ｔ１は、ＶＣ０に割り当てられ、４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄを含む。
－Ｔ２は、ＶＣ１に割り当てられ、２つの部分またはビートＴ２ＡおよびＴ２Ｂを含む。
－Ｔ３は、ＶＣ２に割り当てられ、２つの部分またはビートＴ３ＡおよびＴ３Ｂを含む。
－Ｔ４は、ＶＣ３に割り当てられ、２つの部分またはビートＴ４ＡおよびＴ４Ｂを含む。
【0107】
この例では、優先度スキームは重み付けされる。結果として、各仮想チャネルは、その重みの比率に従って勝利する。換言すると、１０サイクルの間に、ＶＣ０は、４回勝利し、ＶＣ１、ＶＣ２、および、ＶＣ３は各々、２回勝利する。例えば、図６に示すように、
－Ｔ１の４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄは、１０サイクルのうちの４サイクル（４０％）（すなわち、サイクル１、４、７、および、１０）でＶＣＯを介して伝送され、
－Ｔ２の２つの部分またはビートＴ２ＡおよびＴ２Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル２およびサイクル６）でＶＣ１を介して伝送され、
－Ｔ３の２つの部分またはビートＴ３ＡおよびＴ３Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル５およびサイクル９）でＶＣ２を介して伝送され、
－Ｔ４の２つの部分またはビートＴ４ＡおよびＴ４Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル３およびサイクル８）でＶＣ３を介して伝送される。
－Ｔ１の４つの部分またはビートＴ１Ａ、Ｔ１Ｂ、Ｔ１Ｃ、および、Ｔ１Ｄは、１０サイクルのうちの４サイクル（４０％）（すなわち、サイクル１、４、７、および、１０）でＶＣＯを介して伝送され、
－Ｔ２の２つの部分またはビートＴ２ＡおよびＴ２Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル２およびサイクル６）でＶＣ１を介して伝送され、
－Ｔ３の２つの部分またはビートＴ３ＡおよびＴ３Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル５およびサイクル９）でＶＣ２を介して伝送され、
－Ｔ４の２つの部分またはビートＴ４ＡおよびＴ４Ｂは、１０サイクルのうちの２サイクル（２０％）（すなわち、サイクル３およびサイクル８）でＶＣ３を介して伝送される。
【0108】
したがって、この例は、以下を示す。（１）各仮想チャネルが所定の比率に基づいて相互接続１２へのアクセス権を与えられる重み付き優先度スキーム、ならびに、（２）異なるトランザクションの勝利部分が相互接続１２に関連付けられている異なる仮想チャネルでインターリーブされて伝送される別の例。
【0109】
この重み付けの例では、重み付け比率に従って様々な仮想チャネルにトランザクションの部分を割り当てられるのに十分なトラフィックがあることを理解されたい。その一方でトラフィックの量が不十分である場合、重み付け比率は、厳密に実施できる場合も厳密に実施できない場合もある。例えば、仮想チャネルＶＣ３に大きいトラフィックがあり、その他の仮想チャネルＶＣ０、ＶＣ１、および、ＶＣ２ではトラフィックが限られているか全くない場合、ＶＣ３は、重み付け比率が厳密に実施されれば、トラフィックの全部または大部分を運ぶことになる。しかしながら、結果として、すべてのクロックサイクルまたはビートでトランザクションの部分を送信できるわけではないので、相互接続１２は、十分に利用されえない。一方、重み付け比率が厳密に実施されない場合、相互接続の利用率をあげるために、トランザクショントラフィックを再割り当てすることが可能である（例えば、トラフィックが、より多い数のサイクルまたはビートで送信される）。
【0110】
上記の２つの例は、上述した伝送モードのどれが利用されるかに関わらず適用可能である。トランザクションが部分またはビートに分割されると、それらは、本明細書で規定したアービトレーションスキームのいずれかを用いて共有相互接続１２でインターリーブされて伝送されうる。
【0111】
上述したアービトレーションスキームは、ほんの数例である。その他の例では、低ジッタ、重み付け、厳密、ラウンドロビン、または、ほぼ任意のその他のアービトレーションスキームが用いられてもよい。したがって、本明細書に列挙または記載されたアービトレーションスキームは、例示であり、どのようにも限定と見なされるべきではない。
【0112】
複数の同時アービトレーション
ここまで、簡単のために、単一のアービトレーションのみを記載していた。しかしながら、現実的な応用例（ＳｏＣ上など）では、複数のアービトレーションが同時に行われうることを理解されたい。
ここまで、簡単のために、単一のアービトレーションのみを記載していた。しかしながら、現実的な応用例（ＳｏＣ上など）では、複数のアービトレーションが同時に行われうることを理解されたい。
【0113】
図７を参照すると、スイッチ１６、１８の間において２方向でトラフィックを処理するための２つの共有相互接続１２および１２Ｚのブロック図が示されている。上述したように、スイッチ１６は、共有相互接続１２を介して送信元サブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）から宛先サブファンクション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクショントラフィックを方向付ける。逆方向のトランザクショントラフィックを扱うために、スイッチ１８は、アービトレーション要素２６Ｚと、任意選択的にＡＲＬ２８Ｚと、を備える。動作中、要素２６ＺおよびＡＲＬ２８Ｚは、上述した動作と相補的に動作し、これは、送信元ＩＰエージェント１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）によって生成されたトランザクショントラフィックがアービトレートされて、共有相互接続１２Ｚを介して宛先ＩＰエージェント（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）へ送信されることを意味する。あるいは、アービトレーションは、ＡＲＬ２８Ｚなしに実行されてもよく、これは、アービトレーションが、単に競合ポート２０（例えば、Ｐｏｒｔ３、Ｐｏｒｔ３またはＰｏｒｔ５）の間で決定を行い、勝利ポートに関連するトランザクションの部分が、その部分の最終的な宛先に関わらず、相互接続１２で伝送されることを意味する。要素１２Ｚ、２６Ｚ、および、２８Ｚについては、すでに記載したので、簡単のために詳細な説明は、ここでは提供しない。
【0114】
ＳｏＣには、複数レベルのサブファンクション１４および複数の共有相互接続１２が存在しうる。各々で、上述のアービトレーションスキームを用いて、様々なサブファンクションの間で相互接続１２を介して送信されるトランザクションの間のアービトレーションを同時に行うことができる。
【0115】
相互接続ファブリック
図８を参照すると、ＳｏＣの例１００が示されている。ＳｏＣ１００は、複数のＩＰエージェント１４（ＩＰ１、ＩＰ２、ＩＰ３、．．．ＩＰＮ）を備える。各ＩＰエージェント１４は、いくつかのノード１０２の内の１つに接続されている。共有相互接続１２、１２Ｚは、逆方向であり、様々なノード１０２の間に提供されている。この構成では、トランザクションが、例えば、図７に関して上述したように、ノード１０２の各ペアの間で両方向に流れうる。
図８を参照すると、ＳｏＣの例１００が示されている。ＳｏＣ１００は、複数のＩＰエージェント１４（ＩＰ１、ＩＰ２、ＩＰ３、．．．ＩＰＮ）を備える。各ＩＰエージェント１４は、いくつかのノード１０２の内の１つに接続されている。共有相互接続１２、１２Ｚは、逆方向であり、様々なノード１０２の間に提供されている。この構成では、トランザクションが、例えば、図７に関して上述したように、ノード１０２の各ペアの間で両方向に流れうる。
【0116】
非排他的な実施形態において、各ノード１０２は、様々なスイッチ１６、１８と、ローカルＩＰエージェント１４に接続するためのアクセスポート２０と、共有相互接続１２、１２Ｚに接続するためのアクセスポート２２と、アービトレーション要素２６と、任意選択的なＡＲＬ２８と、任意選択的なＬＵＴ３０と、を備える。代替実施形態において、ノードは、アービトレーション要素２６および／またはＡＲＬ２８を備えなくてもよい。これらの要素を持たないノード１０２については、必要なルーティング情報のないトランザクションが、上述のようにデフォルトノードへ転送されうる。これらの要素の各々については、図１に関して上述したので、簡単のために詳細な説明は、ここでは提供しない。
【0117】
集合的に、様々なノード１０２および双方向相互接続１２、１２Ｚは、ＳｏＣ１００のための相互接続ファブリック１０６を規定する。図に示した相互接続ファブリック１０６は、簡潔にするために比較的単純である。実際の実施形態においては、ＳｏＣ１００上の相互接続ファブリックは、数百または数千ものＩＰエージェント１４、複数レベルのノード１０２を備え、それらすべてが多数の相互接続１２、１２Ｚによって相互接続され、非常に複雑でありうることを理解されたい。
【0118】
ブロードキャスト、マルチキャスト、および、エニーキャスト
機械学習または人工知能など、いくつかの応用例では、１つのＩＰエージェント１４によって生成されたトランザクションが、ＳｏＣ１００上の複数のＩＰエージェント１４に広く発信されるのが普通である。複数のＩＰエージェント１４へ広く発信されるトランザクションは、ブロードキャスト、マルチキャスト、または、エニーキャストによって実施されうる。所与のＳｏＣ１００上で、ブロードキャスト、マルチキャスト、および／または、エニーキャストが各々、独自に実施されてもよいし、一緒に実施されてもよい。これらのタイプのトランザクションの各々の簡単な定義を以下に提供する。
・ブロードキャストは、ＳｏＣ１００上のすべてのＩＰエージェントに送信されるトランザクションである。例えば、図８に示したＳｏＣ１００において、ＩＰ１によってブロードキャストが送信された結果として、ＩＰ２～ＩＰＮが各々、トランザクションを受信することになる。
・マルチキャストは、ＳｏＣ上のＩＰエージェントの内の２以上（潜在的には全部を含む）へ送信されるトランザクションである。例えば、ＩＰ１がＩＰ５、ＩＰ７、および、ＩＰ９を指定するマルチキャストトランザクションを生成した場合、これらのエージェント１４はトランザクションを受信するが、ＳｏＣ１００上の残りのＩＰエージェント１４は受信しない。マルチキャストがＩＰエージェント１４すべてに送信された場合、基本的にはブロードキャストと同じである。
・読み出し応答マルチキャストは、上述したマルチキャストトランザクションの変形例である。読み出し応答マルチキャストでは、単一のＩＰエージェント１４が、メモリロケーションのコンテンツを読み出してよい。開始ＩＰエージェント１４だけがコンテンツを受信するのではなく、多数の宛先ＩＰエージェント１４がコンテンツを受信する。読み出し結果を受信するＩＰエージェント１４は、２以上のＩＰエージェント１４からＳｏＣ１００上のすべてのＩＰエージェント１４までの範囲であってよい。
・エニーキャストは、ＩＰエージェント１４によって生成されるトランザクションである。しかしながら、送信側ＩＰエージェント１４は、目標ＩＰエージェント１４を全く指定しない。その代わり、相互接続ファブリック１０６（すなわち、ノード１０２の内の１以上）が、受信側ＩＰエージェント１４を決定する。例えば、ＩＰ１がエニーキャストトランザクションを生成した場合、ノード１０２の内の１以上のノードが、他のエージェントＩＰ２～ＩＰＮのどれがトランザクションを受信するかを決定する。エニーキャストトランザクションの様々な実施例において、ＳｏＣ上のＩＰエージェント１４の内の１つ、複数、または、全部が、エニーキャストトランザクションを受信してよい。
機械学習または人工知能など、いくつかの応用例では、１つのＩＰエージェント１４によって生成されたトランザクションが、ＳｏＣ１００上の複数のＩＰエージェント１４に広く発信されるのが普通である。複数のＩＰエージェント１４へ広く発信されるトランザクションは、ブロードキャスト、マルチキャスト、または、エニーキャストによって実施されうる。所与のＳｏＣ１００上で、ブロードキャスト、マルチキャスト、および／または、エニーキャストが各々、独自に実施されてもよいし、一緒に実施されてもよい。これらのタイプのトランザクションの各々の簡単な定義を以下に提供する。
・ブロードキャストは、ＳｏＣ１００上のすべてのＩＰエージェントに送信されるトランザクションである。例えば、図８に示したＳｏＣ１００において、ＩＰ１によってブロードキャストが送信された結果として、ＩＰ２～ＩＰＮが各々、トランザクションを受信することになる。
・マルチキャストは、ＳｏＣ上のＩＰエージェントの内の２以上（潜在的には全部を含む）へ送信されるトランザクションである。例えば、ＩＰ１がＩＰ５、ＩＰ７、および、ＩＰ９を指定するマルチキャストトランザクションを生成した場合、これらのエージェント１４はトランザクションを受信するが、ＳｏＣ１００上の残りのＩＰエージェント１４は受信しない。マルチキャストがＩＰエージェント１４すべてに送信された場合、基本的にはブロードキャストと同じである。
・読み出し応答マルチキャストは、上述したマルチキャストトランザクションの変形例である。読み出し応答マルチキャストでは、単一のＩＰエージェント１４が、メモリロケーションのコンテンツを読み出してよい。開始ＩＰエージェント１４だけがコンテンツを受信するのではなく、多数の宛先ＩＰエージェント１４がコンテンツを受信する。読み出し結果を受信するＩＰエージェント１４は、２以上のＩＰエージェント１４からＳｏＣ１００上のすべてのＩＰエージェント１４までの範囲であってよい。
・エニーキャストは、ＩＰエージェント１４によって生成されるトランザクションである。しかしながら、送信側ＩＰエージェント１４は、目標ＩＰエージェント１４を全く指定しない。その代わり、相互接続ファブリック１０６（すなわち、ノード１０２の内の１以上）が、受信側ＩＰエージェント１４を決定する。例えば、ＩＰ１がエニーキャストトランザクションを生成した場合、ノード１０２の内の１以上のノードが、他のエージェントＩＰ２～ＩＰＮのどれがトランザクションを受信するかを決定する。エニーキャストトランザクションの様々な実施例において、ＳｏＣ上のＩＰエージェント１４の内の１つ、複数、または、全部が、エニーキャストトランザクションを受信してよい。
【0119】
所与のトランザクションが、いくつかの方法で、ブロードキャスト、読み出し応答マルチキャストを含むマルチキャスト、または、エニーキャストとして開始されうる。簡単のために、以下では、これらのトランザクションを集合的に「ＢＭＡ」トランザクションと呼ぶこととし、これは、ブロードキャスト、マルチキャスト（読み出し応答マルチキャストを含む）、または、エニーキャストトランザクションを意味する。
【0120】
一実施形態において、ＩＰエージェント１４は、トランザクションを表すパケット３２のヘッダ３４のコマンドフィールドＣＭＤに挿入されたコード化されたコマンドを用いて、ＢＭＡトランザクションを開始してよい。コード化されたコマンドにより、ＳｏＣ１００の相互接続ファブリック１０６は、トランザクションが、１つの送信元および１つの宛先ＩＰエージェント１４を指定する通常のトランザクションではなく、ＢＭＡトランザクションであることを認識または理解する。例えば、ビットの独自の組み合せが、それぞれ、ブロードキャスト、マルチキャスト、読み出し応答マルチキャスト、または、エニーキャストのいずれかとして、所与のトランザクションを規定しうる。
【0121】
別の実施形態において、ＢＭＡトランザクションは、トランザクションを表すパケット３２のヘッダ３４のＡＤＤＲフィールドに規定されたＢＭＡアドレスを有する読み出しまたは書き込みしトランザクションを発行することによって実施されうる。ＢＭＡアドレスは、ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションの内の１つを示すものとして、ＳｏＣ１００のシステム内で指定される。結果として、ＢＭＡアドレスは、相互接続ファブリック１０６によって認識され、トランザクションは、ブロードキャスト、マルチキャスト、または、エニーキャストとして扱われる。
【0122】
さらに別の実施形態において、コマンドおよびＢＭＡアドレスは両方とも、ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションを指定するために利用できる。
【0123】
エニーキャストは、典型的には、送信元ＩＰエージェント１４が複数の宛先にトランザクションを送信したいが、１以上の好ましいまたは理想的な宛先ＩＰエージェント１４を選択するのに役立つ要素に気づかない状況で用いられる。例えば、送信元ＩＰエージェント１４は、各々がアクセラレータ機能を実装する複数のＩＰエージェントにトランザクションを送信しようとしうる。そのトランザクションをエニーキャストとして指定することにより、ノード１０２の内の１以上が、宛先ＩＰエージェント１４の選択に関与する。様々な実施形態において、選択基準は、幅広く変化してよく、混雑状態（ビジーであるＩＰエージェント対アイドル状態すなわちビジーではないＩＰエージェント）、ランダム選択関数、ハードワイヤロジック関数、ハッシュ関数、最長時間未使用の関数、電力消費の考慮、もしくは、任意のその他の決定関数または基準に基づいてよい。したがって、宛先ＩＰエージェント１４を選択する責任は、ノード１０２にシフトされ、ノード１０２は、送信元エージェント１４よりも良好なルーティング決定を行うために、より多くの情報を有しうる。
【0124】
図９Ａを参照すると、ＢＭＡアドレッシングをサポートするためのノード１０２のロジックを示す図９０が示されている。ロジック９０は、ＬＵＴ３０と、相互接続ファブリックＩＤ（ＩＦＩＤ）テーブル１２４と、任意選択的な物理リンクセレクタ１２６と、を備える。任意選択的な物理リンクセレクタ１２６は、後に詳述する単一の論理識別子を共有する２つ（以上）の重複物理リソースがある場合（トランキング状況など）に用いられる。
【0125】
ＩＦＩＤテーブルは、各ＩＰエージェント１４について、（ａ）ＳｏＣ１００内の各ＩＰエージェント１４を論理的に識別するための対応する論理ＩＰ ＩＤと、（ｂ）対応するＩＰエージェント１４がノード１０２にローカルである場合のポート２０もしくは（ｃ）対応するＩＰエージェント１４への配信パスに沿って次のノード１０２につながる適切な相互接続１２または１２Ｚへのアクセスポート２２のいずれかと、を含む。この構成では、各ノードは、ＳｏＣ１００内の各ＩＰエージェント１４へトランザクションを配信するのに必要な物理ポート２０および／または２２のアイデンティティにアクセスできる。
【0126】
ファブリック１０６内の各ノード１０２のためのＩＦＩＤテーブル１２４は、相対的（すなわち、一意的）である。換言すると、各ＩＦＩＤテーブル１２４は、（１）そのローカルＩＰエージェント１４または（２）ノード１２０へローカルに接続されていないＳｏＣ内の他のＩＰエージェント１４への配信パスに沿った他のノード１０２への共有相互接続１２、１２Ｚ、のいずれかへトランザクションを配信するために必要なポート２０および／または２２のリストだけを含む。この構成では、各ノード１０２は、（１）宛先として指定されたそのローカルＩＰエージェント１４へトランザクションを配信するか、または、（２）別のノード１０２へ相互接続１２、１２Ｚを介してトランザクションを転送するか、のいずれかである。次のノードで、上述の処理が繰り返される。各ノード１０２でトランザクションをローカルに配信するかまたは転送することにより、最終的に、所与のトランザクションが、ＳｏＣ１００のための相互接続ファブリック１０６内の指定された宛先ＩＰエージェント１４すべてに配信される。
【0127】
ＬＵＴ３０は、従来のトランザクション（すなわち、単一の宛先ＩＰエージェント１４に送信されるトランザクション）のルーティングに用いられる第１部分１２０である。従来のトランザクションが生成されると、送信元ＩＰエージェント１４は、トランザクションを表すパケットヘッダのＡＤＤＲフィールド内にシステムメモリ２４内の宛先アドレスを規定する。次いで、トランザクションは、ルーティングのためにローカルノード１０２へ提供される。それに応じて、ＡＲＬ２８は、ＬＵＴ３０の第１部分１２０にアクセスして、宛先アドレスに対応する論理ＩＰ ＩＤを見つける。次いで、ＩＦＩＤテーブル１２４は、（ａ）宛先ＩＰエージェント１４がノード１０２にローカルである場合のポート２０もしくは（ｂ）宛先ＩＰエージェント１４への配信パスに沿って次のノード１０２につながる適切な相互接続１２または１２Ｚへのアクセスポート２２、のいずれかを規定するために、アクセスされる。ＩＰ ＩＤは、適切なポート２０または２２に沿って送信される前に、パケット３２のヘッダ３４のＤＳＴフィールドに配置される。
【0128】
ブロードキャスト、マルチキャスト、または、エニーキャストトランザクションについて、ＬＵＴ３０の第２部分１２２は、複数のＢＭＡアドレス（例えば、ＢＭＡ １～ＢＭＡ Ｎ、ここで、Ｎは、必要に応じてまたは適切に選択されうる任意の数）と、各ＢＭＡアドレスに対応する情報と、を含む。様々な実施形態において、対応する情報は、以下でありうる。
（１）１以上の固有ＩＰ ＩＤ（例えば、ＢＭＡアドレス１に対してＩＰ４およびＩＰ７、ＢＭＡアドレス２に対してＩＰ５、ＩＰ１２、および、ＩＰ２４）。
（２）一意的なコード（例えば、ＢＭＡアドレス１０および１１に対してコード１およびコード２）。
（３）ビットベクトル（例えば、ＢＭＡアドレス２０および２１のためのビットベクトル）。
（１）１以上の固有ＩＰ ＩＤ（例えば、ＢＭＡアドレス１に対してＩＰ４およびＩＰ７、ＢＭＡアドレス２に対してＩＰ５、ＩＰ１２、および、ＩＰ２４）。
（２）一意的なコード（例えば、ＢＭＡアドレス１０および１１に対してコード１およびコード２）。
（３）ビットベクトル（例えば、ＢＭＡアドレス２０および２１のためのビットベクトル）。
【0129】
各コードは、宛先ＩＰエージェントの異なるセットを一意的に識別する。例えば、第１コードは、宛先ＩＰエージェントの第１セット（例えば、ＩＰ１、ＩＰ１３、および、ＩＰ２１）を指定するために利用でき、第２コードは、宛先エージェントの別のセット（例えば、ＩＰ４、ＩＰ９、および、ＩＰ１７）を指定するために利用できる。
【0130】
ビットベクトルでは、各ビット位置が、ＳｏＣ１００上のＩＰエージェント１４に対応する。所与のビット位置が設定されたか再設定されたかに応じて、対応するＩＰエージェント１４は、それぞれ、宛先であるとしてまたは宛先ではないとして指定される。例として、（１０１０１１．．．１）のビットベクトルは、対応するＩＰエージェント１４（ＩＰ１、ＩＰ３、ＩＰ５、ＩＰ６、および、ＩＰＮ）が設定され、残りが再設定されることを示す。
【0131】
上述の実施形態の各々では、１以上の論理ＩＰ ＩＤが、所与のトランザクションの宛先ＩＰエージェントとして識別される。ＩＦＩＤテーブル１２４は、論理識別子ＩＰ ＩＤ値を、トランザクションをそれらの宛先にルーティングするのに必要な物理アクセスポート２０および／または２２に変換するために用いられる。ＢＭＡアドレスの場合、正しい物理アクセスポート２０および／または２２が必要とされることを決定するために、一意的なコードまたはビットベクトルが、ＩＰ ＩＤ値の代わりに用いられてよい。
【0132】
コードおよびビットベクトルは両方とも、多数の宛先ＩＰエージェント１４を指定するために利用できる。ビットベクトルは、トランザクションを表すパケット３２のヘッダ３４の宛先フィールドＤＳＴの幅によっておそらくは制限されうる。例えば、宛先フィールドＤＳＴが、３２，６４、１２８、または、２５８ビット幅である場合、ＩＰエージェント１４の最大数は、それぞれ、３２、６４、１２８、および、２５６に制限される。所与のＳｏＣ上のＩＰエージェント１４の数が、宛先フィールドＤＳＴの幅によって特定されうる可能なＩＰエージェントの数をたまたま超えた場合、ヘッダ３４内のその他のフィールドが場合によっては用いられてよく、もしくは、ＤＳＴフィールドが拡張されてもよい。しかしながら、非常に複雑なＳｏＣ１００では、ＩＰエージェント１４の数は、ビットベクトル内で実際的に利用できる利用可能ビット数を超える場合がある。コードでは、任意の数の宛先ＩＰエージェントが指定されてよいので、この問題は回避される。
【0133】
図９Ａに関して提供された例は、本質的に例示であり、どのようにも限定を意図しないことを理解されたい。実際の実施形態において、ＳｏＣ１００で利用できるＢＭＡアドレスの数は、１から多数まで幅広く変化してよい。
【0134】
ソースベースルーティング（ＳＢＲ）
ソースベースルーティング（ＳＢＲ）は、以下の点で従来のルーティングとは異なる。
（１）送信元ＩＰエージェント１４は、トランザクションの発行時に、相互接続ファブリック１０６に与える何らかの知識または指示を有する。例えば、送信元ＩＰエージェント１４は、それがトランザクションを送信したい宛先ＩＰエージェント１４のＩＰ ＩＤを知っている。
（２）送信元ＩＰエージェント１４は、トランザクションのパケット３２のパケットヘッダ３４のＡＤＤＲフィールドに通常は提供されるシステムメモリ２４内のアドレスに関心がないおよび／またはそれを知らない。
（３）相互接続ファブリック１０６内のノード１０２は、パケットのヘッダ３４のＡＤＤＲフィールド内のアドレスを単一の宛先ＩＰエージェントのための単一のＩＰ ＩＤへ単に変換することとは異なる何かを実行することを知っている。
ソースベースルーティング（ＳＢＲ）は、以下の点で従来のルーティングとは異なる。
（１）送信元ＩＰエージェント１４は、トランザクションの発行時に、相互接続ファブリック１０６に与える何らかの知識または指示を有する。例えば、送信元ＩＰエージェント１４は、それがトランザクションを送信したい宛先ＩＰエージェント１４のＩＰ ＩＤを知っている。
（２）送信元ＩＰエージェント１４は、トランザクションのパケット３２のパケットヘッダ３４のＡＤＤＲフィールドに通常は提供されるシステムメモリ２４内のアドレスに関心がないおよび／またはそれを知らない。
（３）相互接続ファブリック１０６内のノード１０２は、パケットのヘッダ３４のＡＤＤＲフィールド内のアドレスを単一の宛先ＩＰエージェントのための単一のＩＰ ＩＤへ単に変換することとは異なる何かを実行することを知っている。
【0135】
ブロードキャストおよびマルチキャストは両方とも、おそらくＳＢＲトランザクションでありうるが必ずしもそうではないトランザクションの例である。送信元が、トランザクションのパケット３２のヘッダ３４内で（ａ）ブロードキャストおよび／またはマルチキャストコードおよび（ｂ）宛先ＩＰエージェント１４のいずれかを指定するブロードキャストまたはマルチキャストを発行する場合、トランザクションは、送信元ＩＰエージェントが宛先ＩＰエージェントを指定しているので、ソースベースであると見なされる。一方、送信元が、宛先の具体的な知識を全く持たずにＢＭＡアドレスを用いてブロードキャストまたはマルチキャストトランザクションを開始する場合、トランザクションは、非ソースベースであると見なされる。エニーキャストトランザクションは、宛先ＩＰエージェント１４を規定しないので、ソースベースとは見なされない。
【0136】
ハッシング
ハッシングでは、ハッシュ関数が、宛先または宛先までのルートを規定するために用いられる。いくつかの実施例において、ハッシング関数が、複数の宛先および／または複数の宛先までの複数のルートを丁寧に規定してよい。
ハッシングでは、ハッシュ関数が、宛先または宛先までのルートを規定するために用いられる。いくつかの実施例において、ハッシング関数が、複数の宛先および／または複数の宛先までの複数のルートを丁寧に規定してよい。
【0137】
図９Ｂを参照すると、ルーティング決定を実施するためのハッシュ関数の利用を説明する図１４０が示されている。この実施形態において、ハッシュ値１４２が、トランザクションを表すパケット３２のヘッダ３４の任意の数のフィールド内に提供される。例えば、アドレスビット、コマンド、送信元エージェントＩＰ、または、ヘッダ３４に含まれる情報またはデータの任意の可能な組合せのサブセットが、ハッシュ値を規定するために用いられてよい。対応するローカルノード１０２内またはＳｏＣ１００上のどこかで、ハッシュ関数１４４が、ハッシュ値１４２に適用される。ハッシュ関数１４４に応答して、ルーティング決定がなされうる。例えば、宛先エージェント１４の１以上のＩＰ ＩＤが規定されてよい。異なるハッシュ値を提供することにより、異なるルーティング決定が規定されてよい。ハッシングは、ＳｏＣ内での多くの他の用途に用いられてもよいことを理解されたい。１つのかかる用途は、トランキングのためのハッシュ関数の利用である。トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。後に詳述するように、ハッシュ関数は、重複物理リソースの中から選択するために利用できる。
【0138】
トランザクショントラフィックの最適化
機械学習、人工知能、データセンターなど、ＳｏＣのいくつかの応用例は、トランザクション集約的でありうる。これらのタイプの応用例は、ブロードキャスト、マルチキャスト、および、エニーキャストに依存する傾向にあり、それにより、トランザクショントラフィックをさらに増大させうる。
機械学習、人工知能、データセンターなど、ＳｏＣのいくつかの応用例は、トランザクション集約的でありうる。これらのタイプの応用例は、ブロードキャスト、マルチキャスト、および、エニーキャストに依存する傾向にあり、それにより、トランザクショントラフィックをさらに増大させうる。
【0139】
ブロードキャストトランザクションは、相互接続ファブリック１０６を介して送信されるトラフィックの量を著しく増大させうる。
【0140】
ボトルネックの発生を低減するために、トランザクショントラフィックを削減する多くの手順が提案されている。かかる手順は、（１）ＳｏＣ１００の相互接続ファブリック１０６のノード１０２でトランザクションを拡大し、応答を統合すること、（２）それぞれ、ペアになった仮想チャネルトランザクションクラスの組み合せによって規定されるストリームで２以上のトランザクションをストリーム内でインターリービングすること、（３）ならびに、共通の論理リンクを共有するＩＰエージェントの間の２以上の物理リンクまたは共通の論理アドレスを共有する２以上の同一のＩＰエージェントを「トランキング」すること、を含む。
【0141】
トランザクションの拡大および応答の統合
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングは各々、ＳｏＣ１００上のＩＰエージェント１４の間のトランザクショントラフィックの量を著しく増大させうる。
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングは各々、ＳｏＣ１００上のＩＰエージェント１４の間のトランザクショントラフィックの量を著しく増大させうる。
【0142】
ＳｏＣ１００が２５のＩＰエージェントを有し、ＩＰエージェントの１つがブロードキャストトランザクションを生成する場合、最高２４までの個々のトランザクションが、典型的には、その他のＩＰエージェント１４へ相互接続ファブリックを介して送信される。Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）トランザクションは、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションの形態の応答を求める。２４のＩＰエージェントへブロードキャストされるトランザクションがＮｏｎ－ｐｏｓｔｅｄである場合、別の２４のＣｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションが同様に生成される。この簡単な例で示すように、ブロードキャストは、相互接続ファブリック１０６で伝送されるトラフィックの量を急速に増大させうる。
【0143】
マルチキャストおよびエニーキャストトランザクションも、トラフィックの量を急速に拡大しうる。これらのトランザクションタイプの各々では、複数の受信側が指定されてよく、これは、複数のトランザクションが送信され、おそらくは、複数の完了応答トランザクションが相互接続ファブリック１０６を介して受信されることを意味する。読み出し応答マルチキャストトランザクションでも、読み出されたコンテンツは、複数の宛先ＩＰエージェント１４に送信されうる。結果として、トランザクション量は、これらのタイプのトランザクションでも著しく増大しうる。
【0144】
相互接続ファブリック１０６をより効果的に動作させるために、ノード１０２でのトランザクションを拡大して統合する技術を用いて、トラフィックの量を削減する。
【0145】
図１０Ａおよび図１０Ｂを参照すると、ＳｏＣの一例を説明する図が示されている。この例において、ＳｏＣは、５個の相互接続されたノード１０２Ａ～１０２Ｅおよび１０個のＩＰエージェント１４（ＩＰ１～ＩＰ１０）を備えた相互接続ファブリック１０６を備える。
【0146】
図１０Ａを参照すると、ＩＰ１は、Ｎｏｎ－ｐｏｓｔｅｄ書き込みトランザクションをその他のＩＰエージェントＩＰ２～ＩＰ１０へブロードキャストする。拡大を用いることにより、単一のトランザクションだけが、各共有相互接続１２で送信される。各ダウンストリームノード１０２Ｂ～１０２Ｅでは、ノードは、（１）トランザクションを任意のローカルＩＰエージェント１４へ提供し、（２）トランザクションを任意のアップストリームノード１０２へ転送する。したがって、この例では、
・ノード１０２Ｂは、トランザクションをＩＰ２に提供し、トランザクションの単一のインスタンス化をそれぞれノード１０２Ｃおよび１０２Ｄへ転送する。
・ノード１０２Ｃでは、トランザクションは、ローカルエージェントＩＰ３、ＩＰ４、および、ＩＰ５へ提供される。
・ノード１０２Ｄは、トランザクションをＩＰ７へ提供する。さらに、ノード１０２Ｄも、トランザクションの単一のインスタンス化をノード１０２Ｅへ転送する。
・ノード１０２Ｅで、トランザクションは、ＩＰ８、ＩＰ９、および、ＩＰ１０へ提供される。
・ノード１０２Ｂは、トランザクションをＩＰ２に提供し、トランザクションの単一のインスタンス化をそれぞれノード１０２Ｃおよび１０２Ｄへ転送する。
・ノード１０２Ｃでは、トランザクションは、ローカルエージェントＩＰ３、ＩＰ４、および、ＩＰ５へ提供される。
・ノード１０２Ｄは、トランザクションをＩＰ７へ提供する。さらに、ノード１０２Ｄも、トランザクションの単一のインスタンス化をノード１０２Ｅへ転送する。
・ノード１０２Ｅで、トランザクションは、ＩＰ８、ＩＰ９、および、ＩＰ１０へ提供される。
【0147】
上記の例では、単一のトランザクションだけが、送信側ＩＰエージェント１４の下流にあるＩＰエージェント１の数に関わらず、各共有相互接続１２で送信される。
【0148】
図１０Ｂを参照して、応答トランザクションの統合について説明する。ブロードキャストトランザクションは、Ｎｏｎ－ｐｏｓｔｅｄ書き込みであったので、各宛先エージェントＩＰ２～ＩＰ１０は、完了トランザクションを返す必要がある。統合では、各ノード１０２Ｂ～１０２Ｅは、そのローカルＩＰエージェント１４から受信した完了トランザクションを統合し、その後、ノード１０２Ａへ向かって上流へ単一の完了トランザクションのみを送信する。換言すると、
・ノード１０２Ｅは、ＩＰ８～ＩＰ１０から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２Ｄへ返す。
・ノード１０２Ｄでは、ＩＰ７およびノード１０２Ｅから受信した完了トランザクションが統合され、１つの完了トランザクションがノード１０２Ｂへ返される。
・同様に、ノード１０２Ｃは、ＩＰ３、ＩＰ４、および、ＩＰ５について単一の統合されたトランザクションを返す。
・最後に、ノード１０２Ｂは、ノード１０２Ｃ、１０２Ｄ、および、ＩＰ２から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２ＡおよびＩＰ１へ返す。
・ノード１０２Ｅは、ＩＰ８～ＩＰ１０から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２Ｄへ返す。
・ノード１０２Ｄでは、ＩＰ７およびノード１０２Ｅから受信した完了トランザクションが統合され、１つの完了トランザクションがノード１０２Ｂへ返される。
・同様に、ノード１０２Ｃは、ＩＰ３、ＩＰ４、および、ＩＰ５について単一の統合されたトランザクションを返す。
・最後に、ノード１０２Ｂは、ノード１０２Ｃ、１０２Ｄ、および、ＩＰ２から受信した完了トランザクションを統合し、単一の完了トランザクションをノード１０２ＡおよびＩＰ１へ返す。
【0149】
上記の例は、拡大および統合の効率を説明する。拡大がなければ、９個の別個のトランザクション（エージェントＩＰ２～ＩＰ１０の各々に対して１つずつ）が、相互接続ファブリック１０６を介して伝送される必要がある。しかし、拡大を用いることにより、様々な共有相互接続１２を介して伝送されるトランザクションの数は、４まで削減される。合計９の完了トランザクションも、４つに統合される。
【0150】
時々、エラーが発生する可能性があり、完了トランザクションが、受信側ＩＰエージェントＩＰ２～ＩＰ１０の１以上によって生成されない。エラーは、多くの異なる方法で対処することができる。例えば、成功した完了だけを統合することができ、一方、エラー応答を組み合わせるおよび／または別個に送信することができる。さらに別の代替例において、成功した完了およびエラー完了の両方が統合されてもよいが、成功応答または失敗応答のいずれかを示すように、各々にフラグが付される。
【0151】
上記の記載はブロードキャストの文脈で提供されているが、トランザクションの拡大および統合は、マルチキャスティング、読み出し応答マルチキャスティング、および／または、エニーキャスティングで実施されてもよいことを理解されたい。
【0152】
ブロードキャスト、マルチキャスト、および、エニーキャストトランザクションが一般的である機械学習、人工知能、データセンターなどのトランザクション集約的な応用例において、拡大および統合することができれば、相互接続ファブリック１０６上のトランザクショントラフィックの量を大幅に削減して、ボトルネックを排除または低減すると共にシステム効率およびパフォーマンスを改善することができる。
【0153】
トランキング
ＳｏＣ１００の相互接続ファブリック１０６は、典型的には、各方向に対して、（ａ）ＩＰエージェント１４とローカルノード１０２との間、および、（ｂ）複数のノード１０２の間に、単一の物理リンクを備える。単一のリンクのみがある場合、物理リンクと、その物理リンクのためのアクセスポート２０または２２との間には、一対一の対応関係がある。同様に、ほとんどの相互接続ファブリック１０６で、物理ＩＰエージェント１４と、そのＩＰエージェント１４にアクセスするために用いられる論理ＩＰ ＩＤとの間にも、一対一の対応関係がある。
ＳｏＣ１００の相互接続ファブリック１０６は、典型的には、各方向に対して、（ａ）ＩＰエージェント１４とローカルノード１０２との間、および、（ｂ）複数のノード１０２の間に、単一の物理リンクを備える。単一のリンクのみがある場合、物理リンクと、その物理リンクのためのアクセスポート２０または２２との間には、一対一の対応関係がある。同様に、ほとんどの相互接続ファブリック１０６で、物理ＩＰエージェント１４と、そのＩＰエージェント１４にアクセスするために用いられる論理ＩＰ ＩＤとの間にも、一対一の対応関係がある。
【0154】
高パフォーマンスの応用例においては、トランキングと呼ばれる技術を用いることが有利でありうる。トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。物理リソースを重複させることにより、ボトルネックを回避することができ、システムの効率およびパフォーマスを向上させることができる。例えば、１つの物理リソースが、ビジーであるか、電源オフであるか、または、利用不可能である場合、重複リソースの１つが利用されうる。トランキングは、信頼性も改善できる。１つの物理リソース（例えば、相互接続またはＩＰエージェントなど）がダウンし、利用不可能になるか、または、何らかの理由で利用できない場合、その他の物理リソースが利用されうる。同じ論理識別子を用いて重複リソースをアドレッシングすることにより、ＳｏＣ１００上で利用される論理アドレッシングシステムを変更する必要なしに、重複物理リソースの利点を実現させることができる。しかしながら、重複物理リソースの内のどれを利用するのかを選択して追跡するのかが課題である。
【0155】
図１１Ａを参照すると、いくつかのトランキングの例を含むＳｏＣ１００の相互接続ファブリック１０６が示されている。この例において、相互接続ファブリック１０６は、３つのノード１０２Ａ、１０２Ｂ、および、１０２Ｃを備える。ノード１０２Ａは、２つのＩＰエージェント１４ｉおよび１４２を備える。ノード１０２Ｂは、２つのＩＰエージェント１４３および１４４を備える。ノード１０２Ｃは、１つのＩＰエージェント１４ｓを備える。相互接続ファブリック１０６は、以下のトランキングの例を含む。
・ノード１０２ＡとＩＰエージェント１４２との間の物理的な「トランク」ラインのペア。
・ノード１０２Ａから１０２Ｃの同方向の物理的な「トランク」相互接続１２（１）および１２（２）のペア。
・同一のＩＰエージェント１４ｓのペア。
・ノード１０２ＡとＩＰエージェント１４２との間の物理的な「トランク」ラインのペア。
・ノード１０２Ａから１０２Ｃの同方向の物理的な「トランク」相互接続１２（１）および１２（２）のペア。
・同一のＩＰエージェント１４ｓのペア。
【0156】
これらの例の各々では、論理識別子と物理リソースとの間に一対一の対応関係はない。逆に、２つの利用可能な物理リソースがあるので、どちらの物理リソースを利用するか選択を行う必要がある。
【0157】
図１１Ｂを参照すると、（図９Ａの）任意選択的な物理リンクセレクタ１２６を示す図が示されている。上述のように、トランキングでは、単一の論理識別子を共有する２つ（以上）の重複物理リソースが存在する。ＩＦＩＤテーブル１２４が、トランキング状況などで、重複物理リソースを有する論理ＩＰ ＩＤを識別した時はいつでも、任意選択的な物理リンクセレクタ１２６が、選択を行うために用いられる。物理リンクセレクタ１２６は、物理リソースの利用可能性（またはその欠如）、混雑状態、負荷バランシング、ハッシュ関数、ランダム選択、最長時間未使用の選択、電力条件など、１以上の決定要素を用いて、その選択を行ってよい。例えば、或る物理リソースがビジーである、混雑している、および／または、利用不可能である場合、他の物理リソースが選択される。あるいは、或るリソースが電力消費を削減するために電源オフされている場合、他のリソースが選択されてよい。どのようになされるかに関わらず、選択は、選択された物理リソースにアクセスするために用いられる物理ポート２０または２２の識別につながる。
【0158】
非排他的実施形態において、物理リソースの選択は、動作が完了するまで利用されることが好ましい。一連の関連トランザクションが、送信元ＩＰエージェント１４と、宛先ＩＰエージェントの重複ペア（例えば、図１１Ａの２つのＩＰエージェントＩＰ５）との間で送信される場合、すべてのトランザクションが、動作の完了まで同じ宛先ＩＰエージェントに送信される。そうでなければ、データの破損またはその他の問題が発生しうる。重複物理リソースが相互接続である場合、典型的には、同様のアプローチが好ましい。応答（読み出しなど）を求めるトランザクションでは、読み出し要求トランザクションおよび結果応答の両方が、同じ相互接続を介して送信されることが好ましい。さらに、トランザクションのパケットの破損を避けるために、トランザクション全体、および、トランザクションのパケットが、同じパスで同じ宛先へルーティングされることが好ましい。パケットは、リンクを通るために数ビートを必要とし、おそらくは、他の仮想チャネルとインターリーブされうるので、パケットの終了までポートまたはリンクを変えないことが重要である。そうでなければ、パケットの複数のビートは、パケットの部分がシステムを通して移動する時に順序がばらばらになりうるので、それにより情報が破損しうる。要求と同じパスを介して応答をルーティングすることが通常は望ましいが、必須ではない。
【0159】
いくつかの非排他的実施形態において、各ビートと共に送信された順序付け情報を用いて、順不同でまたは異なるリソースから受信されたトランザクションのビートを再順序付けする機能を、宛先ＩＰエージェントに提供することが有利でありうる。例えば、制御ビットＭは、パケットの各ビートに対する固有の「ビートカウント数」を特定するために用いられてよい。次いで、パケットのビートは、各ビートと共に送信された固有のビートカウント数を用いて、正確な番号順で宛先ＩＰエージェントによって組み立てられうる。各ビートと共に送信されるビートカウント数を提供することにより、破損に関する上述の問題の多くが解決されうる。
【0160】
ストリーム内インターリービング
前述したように、ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。１２のストリームは、完全に独立している。ストリームは、独立しているので、例えば、相互接続ワイヤ１２および１２Ｚなどの共有リソース上でインターリーブされうる。各アービトレーション工程で、仮想チャネルのストリームが選択され、対応するポート２２は、そのトランザクションの残りに対してそのトランザクションにロックされる。別の仮想チャネルを選択して、トランザクションの伝送の完了前に同じポート上でインターリーブすることもできるが、トランザクションが完了するまでは、同じ仮想チャネルの別のストリームを選択することはできない。
前述したように、ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義される。４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１２の異なる可能なストリームがある。１２のストリームは、完全に独立している。ストリームは、独立しているので、例えば、相互接続ワイヤ１２および１２Ｚなどの共有リソース上でインターリーブされうる。各アービトレーション工程で、仮想チャネルのストリームが選択され、対応するポート２２は、そのトランザクションの残りに対してそのトランザクションにロックされる。別の仮想チャネルを選択して、トランザクションの伝送の完了前に同じポート上でインターリーブすることもできるが、トランザクションが完了するまでは、同じ仮想チャネルの別のストリームを選択することはできない。
【0161】
ストリーム内インターリービングは、２つのトランザクションが互いに独立しているという条件では、同じストリームを共有する２以上のトランザクションのインターリービングである。独立したトランザクションの例は、（１）２つの異なるＩＰエージェント１４が、同じストリームを共有するトランザクションを生成すること、および、（２）同じＩＰエージェント１４が、同じストリームを共有する２つのトランザクションを生成するが、生成するＩＰエージェント１４が２つのトランザクションを独立するものとしてマークすること、を含む。トランザクションを独立するものとしてマークすることにより、トランザクションを再順序付けして、インターリービングを用いて配信できることを意味する。ストリーム内インターリービングによれば、トランザクションが完了するまで仮想チャネルのストリームをポートにロックする上述の制約を緩和または排除することができる。ストリーム内インターリービングによれば、（１）２以上の独立したトランザクションをストリーム上でインターリーブすることができ、（２）同じ仮想チャネルに関連する異なるストリームもインターリーブできる。
【0162】
ストリーム内インターリービングでは、同じストリーム上でインターリーブされうる２つ（以上）の独立したトランザクションを示すために、さらなる情報が必要である。様々な実施形態において、これは、多くの異なる方法で達成されてよい。一実施形態において、独立したトランザクションのパケットのヘッダ３４は、一意的なトランザクション識別子すなわちＩＤを割り当てられる。一意的なトランザクション識別子を用いることにより、各トランザクションの各ビートは、独立するものとしてフラグを付される。各トランザクションに対する一意的なトランザクションＩＤを用いることにより、様々なノード１０２は、同じストリーム上でインターリーブされる複数の独立したトランザクションのビートを追跡する。
【0163】
インターリーブされたトランザクションの所与のペアについて、仮想チャネルおよびトランザクションクラスを指定するビットは同じであるが、各々のためのトランザクションＩＤを表すビットは異なる。
【0164】
したがって、制御ビットＭに含まれるさらなるトランザクションＩＤ情報は、送信元および宛先ＩＰエージェント１４の両方および相互接続ファブリック１０６が、同じストリーム上でインターリーブされた時に、或るトランザクションを他のトランザクションに対して認識または区別することを可能にする。
【0165】
同期配信対非同期配信
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングでは、同じトランザクションの複数のインスタンス化が、相互接続ファブリック１０６で伝送されてよい。目標となる宛先およびそれらの宛先までのパスの各々が利用可能である場合、各宛先ＩＰエージェント１４は、ネットワーク上で通常の待ち時間だけ遅延して、やがてトランザクションを受信する。一方、パスまたは宛先のいずれかが利用できない（例えば、リソースバッファが満杯である）場合、１以上の利用可能な宛先が、利用できない宛先の前にトランザクションを受信してよい。かかる状況下での異なる到達時間は、２つの異なる実施例の可能性を提起する。
ブロードキャスティング、マルチキャスティング、読み出し応答マルチキャスティング、および、エニーキャスティングでは、同じトランザクションの複数のインスタンス化が、相互接続ファブリック１０６で伝送されてよい。目標となる宛先およびそれらの宛先までのパスの各々が利用可能である場合、各宛先ＩＰエージェント１４は、ネットワーク上で通常の待ち時間だけ遅延して、やがてトランザクションを受信する。一方、パスまたは宛先のいずれかが利用できない（例えば、リソースバッファが満杯である）場合、１以上の利用可能な宛先が、利用できない宛先の前にトランザクションを受信してよい。かかる状況下での異なる到達時間は、２つの異なる実施例の可能性を提起する。
【0166】
第１同期または「ブロッキング」実施形態においては、各宛先がほぼ同時にトランザクションを受信することを保証する努力がなされる。換言すると、利用不可能なリソースが利用可能になるまで、利用可能なリソースへのトランザクションの配信が、遅延すなわち「ブロック」されてよい。結果として、指定された受信側の各々によるトランザクションの受信が同期される。この実施形態は、ほぼ同時にトランザクションを受信することが受信側にとって重要である応用例で用いられてよい。
【0167】
第２非同期的または非ブロッキング実施形態においては、利用可能な宛先へのトランザクションの配信を遅延させるためのブロッキングの努力がなされない。その代わり、トランザクションの各インスタンス化が、利用可能性に基づいて配信され、これは、利用可能なリソースがトランザクションをすぐに受信する一方で、利用不可能なリソースは、利用可能になった時にトランザクションを受信することを意味する。結果として、非同期的すなわち異なる時間に配信が起こりうる。このアプローチの利点は、利用可能な宛先ＩＰエージェント１４が、すぐにトランザクションを処理でき、他のＩＰエージェントと同期するのを待ってブロックされることがないことである。結果として、遅延が回避される。
【0168】
いくつかの実施形態についてのみ詳細に説明したが、ここに提供した本開示の精神や範囲を逸脱することなしに多くの他の形態で本願を実施できることを理解されたい。したがって、これらの実施形態は、例示的なものであって、限定的なものではないとみなされ、本明細書に示した詳細に限定されず、添付の特許請求の範囲および等価物の範囲内で変形されてもよい。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図10A】
【図10B】
【図11A】
【図11B】