ホーム > 特許ランキング > Ｇｏｏｇｌｅ ＬＬＣ
知財求人 - 知財ポータルサイト「IP Force」
特開2024-20317システムオンチップ（ＳｏＣ）エージェントのリセットおよび電力管理のためのプロトコルレベル制御
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024020317
(43)【公開日】2024-02-14
(54)【発明の名称】システムオンチップ（ＳｏＣ）エージェントのリセットおよび電力管理のためのプロトコルレベル制御
(51)【国際特許分類】
G06F 13/42 20060101AFI20240206BHJP
G06F 13/36 20060101ALI20240206BHJP
G06F 15/78 20060101ALI20240206BHJP
【ＦＩ】
G06F13/42 320B
G06F13/36 520B
G06F15/78 530
G06F15/78 517
【審査請求】有
【請求項の数】22
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023190712
(22)【出願日】2023-11-08
(62)【分割の表示】P 2020552287の分割
【原出願日】2019-03-28
(31)【優先権主張番号】62/650,589
(32)【優先日】2018-03-30
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/691,117
(32)【優先日】2018-06-28
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】502208397
【氏名又は名称】グーグル エルエルシー
【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ
【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】デサイ・シャイレンドラ
(72)【発明者】
【氏名】ピアース・マーク
(72)【発明者】
【氏名】ジェイン・アミト
(72)【発明者】
【氏名】バット・ルトゥル
(72)【発明者】
【氏名】パテル・ジャイミン
(57)【要約】 （修正有）
【課題】カスタマイゼーションの必要性を無くし、複数のシステムオンチップ（ＳｏＣ）の間の一貫したシステムソフトウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムを提供する。
【解決手段】ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムであって、ＩＰエージェントがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰエージェントとの間で行われる。各ＩＰエージェントは、他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセットから出ることができる。相互接続は、リセットの前、電力ダウンモードの時、または、動作不良時などに、動作不能である任意のＩＰエージェントの代理として構成される。
【選択図】図８
【解決手段】ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫して実施するためのシステムであって、ＩＰエージェントがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰエージェントとの間で行われる。各ＩＰエージェントは、他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセットから出ることができる。相互接続は、リセットの前、電力ダウンモードの時、または、動作不良時などに、動作不能である任意のＩＰエージェントの代理として構成される。
【選択図】図８
【特許請求の範囲】
【請求項1】
システムオンチップ（ＳｏＣ）であって、
相互接続と、
前記ＳｏＣ上に備えられ、前記相互接続と通信するよう構成されているＩＰエージェン
トと、
前記ＩＰエージェントのリセットを開始するためのリセットマネージャと、を備え、前
記リセットは、前記ＩＰエージェントがトランザクション準備完了状態になるようにする
前記相互接続と前記ＩＰエージェントとの間のネゴシエーションを含む、ＳｏＣ。
相互接続と、
前記ＳｏＣ上に備えられ、前記相互接続と通信するよう構成されているＩＰエージェン
トと、
前記ＩＰエージェントのリセットを開始するためのリセットマネージャと、を備え、前
記リセットは、前記ＩＰエージェントがトランザクション準備完了状態になるようにする
前記相互接続と前記ＩＰエージェントとの間のネゴシエーションを含む、ＳｏＣ。
【請求項2】
請求項１に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続が前記ＩＰ
エージェントに対する少なくとも１つの問い合わせを生成することを含み、前記少なくと
も１つの問い合わせは、前記ＩＰエージェントの「アウェイク」状態を求める、ＳｏＣ。
エージェントに対する少なくとも１つの問い合わせを生成することを含み、前記少なくと
も１つの問い合わせは、前記ＩＰエージェントの「アウェイク」状態を求める、ＳｏＣ。
【請求項3】
請求項１または２に記載のＳｏＣであって、前記ネゴシエーションは、前記相互接続が
、前記ＩＰエージェントの「アウェイク」状態を各々求める前記ＩＰエージェントに対す
る複数の問い合わせを生成することを含み、前記複数の問い合わせは、それぞれ、定期的
に送信される、ＳｏＣ。
、前記ＩＰエージェントの「アウェイク」状態を各々求める前記ＩＰエージェントに対す
る複数の問い合わせを生成することを含み、前記複数の問い合わせは、それぞれ、定期的
に送信される、ＳｏＣ。
【請求項4】
請求項１から３のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前
記ＩＰエージェントが、前記ＩＰエージェントの「アウェイク」状態を求める前記相互接
続からの問い合わせに応答して肯定応答を生成することを含み、前記肯定応答は、前記Ｉ
Ｐエージェントがアウェイクしてトランザクション準備完了状態になった時に生成される
、ＳｏＣ。
記ＩＰエージェントが、前記ＩＰエージェントの「アウェイク」状態を求める前記相互接
続からの問い合わせに応答して肯定応答を生成することを含み、前記肯定応答は、前記Ｉ
Ｐエージェントがアウェイクしてトランザクション準備完了状態になった時に生成される
、ＳｏＣ。
【請求項5】
請求項１から４のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前
記相互接続および前記ＩＰエージェントでそれぞれ利用可能なクレジットの交換を含む、
ＳｏＣ。
記相互接続および前記ＩＰエージェントでそれぞれ利用可能なクレジットの交換を含む、
ＳｏＣ。
【請求項6】
請求項１から５のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前
記相互接続および前記ＩＰエージェントがセキュリティ情報を共有することを含む、Ｓｏ
Ｃ。
記相互接続および前記ＩＰエージェントがセキュリティ情報を共有することを含む、Ｓｏ
Ｃ。
【請求項7】
請求項１から６のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、前
記相互接続が、前記相互接続と前記ＩＰエージェントとを接続するリンクに関連付けられ
ている複数の仮想チャネルを共有することを含む、ＳｏＣ。
記相互接続が、前記相互接続と前記ＩＰエージェントとを接続するリンクに関連付けられ
ている複数の仮想チャネルを共有することを含む、ＳｏＣ。
【請求項8】
請求項１から７のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションが完了
した後に、前記ＩＰエージェントの利用可能性が、システムコントローラを含む前記相互
接続に接続された要素に知らされる、ＳｏＣ。
した後に、前記ＩＰエージェントの利用可能性が、システムコントローラを含む前記相互
接続に接続された要素に知らされる、ＳｏＣ。
【請求項9】
請求項１から８のいずれか一項に記載のＳｏＣであって、さらに、前記相互接続と前記
ＩＰエージェントとの間に接続されたリンクを備え、前記ネゴシエーションは、前記リン
クを介して前記相互接続と前記ＩＰエージェントとの間で行われる、ＳｏＣ。
ＩＰエージェントとの間に接続されたリンクを備え、前記ネゴシエーションは、前記リン
クを介して前記相互接続と前記ＩＰエージェントとの間で行われる、ＳｏＣ。
【請求項10】
請求項１から９のいずれか一項に記載のＳｏＣであって、複数の仮想チャネルが、前記
リンクに関連付けられている、ＳｏＣ。
リンクに関連付けられている、ＳｏＣ。
【請求項11】
請求項１から１０のいずれか一項に記載のＳｏＣであって、前記ネゴシエーションは、
前記相互接続と前記ＩＰエージェントとの間のリンクを介して伝送されるリンクレベル情
報を用いて行われる、ＳｏＣ。
前記相互接続と前記ＩＰエージェントとの間のリンクを介して伝送されるリンクレベル情
報を用いて行われる、ＳｏＣ。
【請求項12】
請求項１１に記載のＳｏＣであって、前記リンクレベル情報は、前記相互接続と前記Ｉ
Ｐエージェントとの間の前記リンクを介して伝送される１以上の制御パケットで伝達され
る、ＳｏＣ。
Ｐエージェントとの間の前記リンクを介して伝送される１以上の制御パケットで伝達され
る、ＳｏＣ。
【請求項13】
請求項１２に記載のＳｏＣであって、前記１以上の制御パケットは、前記相互接続と前
記ＩＰエージェントとの間の前記リンクを介して伝送され、別の宛先には転送されない、
ＳｏＣ。
記ＩＰエージェントとの間の前記リンクを介して伝送され、別の宛先には転送されない、
ＳｏＣ。
【請求項14】
請求項１から１３のいずれか一項に記載のＳｏＣであって、前記リセットマネージャは
、リセットトリガイベントに応答して、前記ＩＰエージェントの前記リセットを開始する
、ＳｏＣ。
、リセットトリガイベントに応答して、前記ＩＰエージェントの前記リセットを開始する
、ＳｏＣ。
【請求項15】
請求項１４に記載のＳｏＣであって、前記リセットトリガイベントは、
前記ＳｏＣの電力アップ、
前記ＩＰエージェントが動作不良を起こしたこと、または、
前記ＩＰエージェントが低電力モードから出つつあること、
の内の１つを含む、ＳｏＣ。
前記ＳｏＣの電力アップ、
前記ＩＰエージェントが動作不良を起こしたこと、または、
前記ＩＰエージェントが低電力モードから出つつあること、
の内の１つを含む、ＳｏＣ。
【請求項16】
請求項１から１５のいずれか一項に記載のＳｏＣであって、さらに、前記相互接続と前
記ＩＰエージェントとの間のリンクを休止状態にするための休止マネージャを備える、Ｓ
ｏＣ。
記ＩＰエージェントとの間のリンクを休止状態にするための休止マネージャを備える、Ｓ
ｏＣ。
【請求項17】
請求項１６に記載のＳｏＣであって、前記休止マネージャは、前記ＩＰエージェントに
よって生成されたすべての未処理のトランザクションが完了した後に、前記リンクを前記
休止状態にするよう構成されている、ＳｏＣ。
よって生成されたすべての未処理のトランザクションが完了した後に、前記リンクを前記
休止状態にするよう構成されている、ＳｏＣ。
【請求項18】
請求項１７に記載のＳｏＣであって、前記休止マネージャは、前記未処理のトランザク
ションが完了するのを待つ間、前記ＩＰエージェントが新しいトランザクションを生成す
るのを防ぐよう構成されている、ＳｏＣ。
ションが完了するのを待つ間、前記ＩＰエージェントが新しいトランザクションを生成す
るのを防ぐよう構成されている、ＳｏＣ。
【請求項19】
請求項１７に記載のＳｏＣであって、前記休止マネージャは、前記リセットマネージャ
が前記ＩＰエージェントの前記リセットを開始する前に、前記リンクを前記休止状態にす
るよう構成されている、ＳｏＣ。
が前記ＩＰエージェントの前記リセットを開始する前に、前記リンクを前記休止状態にす
るよう構成されている、ＳｏＣ。
【請求項20】
システムオンチップ（ＳｏＣ）であって、
相互接続と、
複数のＩＰエージェントと、
前記複数のＩＰエージェントのリセットを実施するよう構成されているリセットマネー
ジャと、を備え、前記複数のＩＰエージェントの各々の前記リセットは、前記相互接続と
前記複数のＩＰエージェントの各々との間の個々のネゴシエーションをそれぞれ含み、前
記個々のネゴシエーションの結果、それぞれ、前記ＩＰエージェントの各々がトランザク
ション準備完了状態になる、ＳｏＣ。
相互接続と、
複数のＩＰエージェントと、
前記複数のＩＰエージェントのリセットを実施するよう構成されているリセットマネー
ジャと、を備え、前記複数のＩＰエージェントの各々の前記リセットは、前記相互接続と
前記複数のＩＰエージェントの各々との間の個々のネゴシエーションをそれぞれ含み、前
記個々のネゴシエーションの結果、それぞれ、前記ＩＰエージェントの各々がトランザク
ション準備完了状態になる、ＳｏＣ。
【請求項21】
請求項２０に記載のＳｏＣであって、前記複数のＩＰエージェントの各々は、自身のリ
セットルーチンを用いる、ＳｏＣ。
セットルーチンを用いる、ＳｏＣ。
【請求項22】
請求項２０または２１に記載のＳｏＣであって、前記複数のＩＰエージェントの各々は
、それぞれ自身のタイムスケジュールでトランザクション準備完了状態になる、ＳｏＣ。
、それぞれ自身のタイムスケジュールでトランザクション準備完了状態になる、ＳｏＣ。
【請求項23】
請求項２０から２２のいずれか一項に記載のＳｏＣであって、前記複数のＩＰエージェ
ントの各々は、他のＩＰエージェントから独立して、トランザクション準備完了状態にな
り、すべての前記ＩＰエージェントが、同時にトランザクション準備完了状態になる必要
がない、ＳｏＣ。
ントの各々は、他のＩＰエージェントから独立して、トランザクション準備完了状態にな
り、すべての前記ＩＰエージェントが、同時にトランザクション準備完了状態になる必要
がない、ＳｏＣ。
【請求項24】
請求項２０から２３のいずれか一項に記載のＳｏＣであって、前記複数のＩＰ機能の各
々のための前記個々のネゴシエーションは、前記ＩＰエージェントが異なるかどうかに関
わらず、同じである、ＳｏＣ。
々のための前記個々のネゴシエーションは、前記ＩＰエージェントが異なるかどうかに関
わらず、同じである、ＳｏＣ。
【請求項25】
請求項２０から２４のいずれか一項に記載のＳｏＣであって、前記相互接続は、さらに
、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つ
のＩＰエージェントがトランザクション準備完了状態になる前に、動作するよう構成され
ている、ＳｏＣ。
、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つ
のＩＰエージェントがトランザクション準備完了状態になる前に、動作するよう構成され
ている、ＳｏＣ。
【請求項26】
請求項２５に記載のＳｏＣであって、前記相互接続は、前記少なくとも１つのＩＰエー
ジェントにトランザクションを送信しようとする送信元への例外メッセージを生成するこ
とにより、トランザクション準備完了状態になる前の前記少なくとも１つのＩＰエージェ
ントの前記代理として動作する、ＳｏＣ。
ジェントにトランザクションを送信しようとする送信元への例外メッセージを生成するこ
とにより、トランザクション準備完了状態になる前の前記少なくとも１つのＩＰエージェ
ントの前記代理として動作する、ＳｏＣ。
【請求項27】
システムオンチップ（ＳｏＣ）であって、
複数のＩＰエージェントと、
前記複数のＩＰエージェントと通信する相互接続であって、前記複数のＩＰエージェン
トの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトラン
ザクション準備完了状態ではない時に、動作するよう構成されている、相互接続と、
を備える、ＳｏＣ。
複数のＩＰエージェントと、
前記複数のＩＰエージェントと通信する相互接続であって、前記複数のＩＰエージェン
トの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトラン
ザクション準備完了状態ではない時に、動作するよう構成されている、相互接続と、
を備える、ＳｏＣ。
【請求項28】
請求項２７に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、リセ
ットを受けている時、トランザクション準備完了状態ではない、ＳｏＣ。
ットを受けている時、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項29】
請求項２７または２８に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェン
トは、電力ダウンモード時には、トランザクション準備完了状態ではない、ＳｏＣ。
トは、電力ダウンモード時には、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項30】
請求項２７から２９のいずれか一項に記載のＳｏＣであって、前記少なくとも１つのＩ
Ｐエージェントは、動作不良時には、トランザクション準備完了状態ではない、ＳｏＣ。
Ｐエージェントは、動作不良時には、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項31】
請求項２７から３０のいずれか一項に記載のＳｏＣであって、前記相互接続は、
前記少なくとも１つのＩＰ機能がトランザクション準備完了状態ではないことを確認し
、
トランザクション準備完了状態ではない間に前記少なくとも１つのＩＰエージェントに
送信元がトランザクションを送信したか否かを確認し、
前記送信元に例外メッセージを送信して、前記少なくとも１つのＩＰエージェントが利
用可能ではないことを前記送信元に通知することによって、前記少なくとも１つのＩＰエ
ージェントの前記代理として機能する、ＳｏＣ。
前記少なくとも１つのＩＰ機能がトランザクション準備完了状態ではないことを確認し
、
トランザクション準備完了状態ではない間に前記少なくとも１つのＩＰエージェントに
送信元がトランザクションを送信したか否かを確認し、
前記送信元に例外メッセージを送信して、前記少なくとも１つのＩＰエージェントが利
用可能ではないことを前記送信元に通知することによって、前記少なくとも１つのＩＰエ
ージェントの前記代理として機能する、ＳｏＣ。
【請求項32】
請求項２７から３１のいずれか一項に記載のＳｏＣであって、前記送信元は、前記例外
メッセージに応答して、送信されたが宛先に配信されていないトランザクションについて
、自身の応答手順を受ける、ＳｏＣ。
メッセージに応答して、送信されたが宛先に配信されていないトランザクションについて
、自身の応答手順を受ける、ＳｏＣ。
【請求項33】
請求項２７から３２のいずれか一項に記載のＳｏＣであって、さらに、前記複数のＩＰ
エージェントのリセットをそれぞれ開始するためのリセットマネージャを備える、ＳｏＣ
。
エージェントのリセットをそれぞれ開始するためのリセットマネージャを備える、ＳｏＣ
。
【請求項34】
請求項２７から３３のいずれか一項に記載のＳｏＣであって、前記相互接続は、さらに
、前記複数のＩＰエージェント各々がそれぞれリセットされる時に、前記複数のＩＰエー
ジェントの各々との個々のネゴシエーションに関与するよう構成されている、ＳｏＣ。
、前記複数のＩＰエージェント各々がそれぞれリセットされる時に、前記複数のＩＰエー
ジェントの各々との個々のネゴシエーションに関与するよう構成されている、ＳｏＣ。
【請求項35】
請求項２７から３４のいずれか一項に記載のＳｏＣであって、前記複数のＩＰエージェ
ントの内の２以上のリセット後に、前記２以上のＩＰエージェントの各々は、それぞれ、
個々にリセットし、他のＩＰエージェントから独立してトランザクション準備完了状態に
なるよう構成されている、ＳｏＣ。
ントの内の２以上のリセット後に、前記２以上のＩＰエージェントの各々は、それぞれ、
個々にリセットし、他のＩＰエージェントから独立してトランザクション準備完了状態に
なるよう構成されている、ＳｏＣ。
【請求項36】
請求項３５に記載のＳｏＣであって、前記２以上のＩＰエージェントの各々は、前記２
以上のＩＰエージェントが同時にトランザクション準備完了状態になる必要なしに、自身
のタイムスケジュールで独立的にトランザクション準備完了状態になる、ＳｏＣ。
以上のＩＰエージェントが同時にトランザクション準備完了状態になる必要なしに、自身
のタイムスケジュールで独立的にトランザクション準備完了状態になる、ＳｏＣ。
【請求項37】
請求項２７から３６のいずれか一項に記載のＳｏＣであって、さらに、システムコント
ローラを備え、少なくとも１つのＩＰエージェントが、トランザクション準備完了状態に
なった時に、前記システムコントローラにとって可視になる、ＳｏＣ。
ローラを備え、少なくとも１つのＩＰエージェントが、トランザクション準備完了状態に
なった時に、前記システムコントローラにとって可視になる、ＳｏＣ。
【請求項38】
システムオンチップ（ＳｏＣ）であって、
複数のＩＰエージェントと、
相互接続と、
前記複数のＩＰエージェントを前記相互接続と接続する１以上のリンクと、
前記複数のＩＰエージェントの少なくとも１つを選択的に低電力状態にすることによっ
て、前記ＳｏＣによる電力消費を少なくとも部分的に管理するための電力マネージャと、
を備え、
前記相互接続は、（ａ）前記低電力状態にあり、かつ、（ｂ）トランザクションの処理
に利用できない時に、前記少なくとも１つのＩＰエージェントの代理として機能し、前記
相互接続は、前記少なくとも１つのＩＰエージェントに前記トランザクションを送信しよ
うとする送信元へ例外メッセージを提供することによって前記代理として機能する、Ｓｏ
Ｃ。
複数のＩＰエージェントと、
相互接続と、
前記複数のＩＰエージェントを前記相互接続と接続する１以上のリンクと、
前記複数のＩＰエージェントの少なくとも１つを選択的に低電力状態にすることによっ
て、前記ＳｏＣによる電力消費を少なくとも部分的に管理するための電力マネージャと、
を備え、
前記相互接続は、（ａ）前記低電力状態にあり、かつ、（ｂ）トランザクションの処理
に利用できない時に、前記少なくとも１つのＩＰエージェントの代理として機能し、前記
相互接続は、前記少なくとも１つのＩＰエージェントに前記トランザクションを送信しよ
うとする送信元へ例外メッセージを提供することによって前記代理として機能する、Ｓｏ
Ｃ。
【請求項39】
請求項３８に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記
低電力状態に入る時に、自身の低電力シーケンスを実施する、ＳｏＣ。
低電力状態に入る時に、自身の低電力シーケンスを実施する、ＳｏＣ。
【請求項40】
請求項３８または３９のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前
記少なくとも１つのＩＰエージェントがトランザクション準備完了状態のままである低電
力モードを含む、ＳｏＣ。
記少なくとも１つのＩＰエージェントがトランザクション準備完了状態のままである低電
力モードを含む、ＳｏＣ。
【請求項41】
請求項４０に記載のＳｏＣであって、前記相互接続は、前記少なくとも１つのＩＰエー
ジェントが前記低電力状態にあり、かつ、トランザクション準備完了状態のままである場
合には、代理として機能せず、前記少なくとも１つのＩＰエージェントのためのクロック
周波数および／または電圧の低減に対応するために、前記１以上のリンクの内の１つの設
定を調整する、ＳｏＣ。
ジェントが前記低電力状態にあり、かつ、トランザクション準備完了状態のままである場
合には、代理として機能せず、前記少なくとも１つのＩＰエージェントのためのクロック
周波数および／または電圧の低減に対応するために、前記１以上のリンクの内の１つの設
定を調整する、ＳｏＣ。
【請求項42】
請求項３８から４１のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記
少なくとも１つのＩＰエージェントがもはやトランザクション準備完了状態ではない低電
力モードを含む、ＳｏＣ。
少なくとも１つのＩＰエージェントがもはやトランザクション準備完了状態ではない低電
力モードを含む、ＳｏＣ。
【請求項43】
請求項４２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記
低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情
報を保持する、ＳｏＣ。
低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情
報を保持する、ＳｏＣ。
【請求項44】
請求項４２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記
低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情
報を保持しない、ＳｏＣ。
低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情
報を保持しない、ＳｏＣ。
【請求項45】
請求項３８から４４のいずれか一項に記載のＳｏＣであって、前記低電力状態は、最小
限の電力が前記少なくとも１つのＩＰエージェントに供給される電力オフモードを含む、
ＳｏＣ。
限の電力が前記少なくとも１つのＩＰエージェントに供給される電力オフモードを含む、
ＳｏＣ。
【請求項46】
請求項３８から４５のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記
少なくとも１つのＩＰエージェントの動作クロック周波数を下げることによって実施され
る、ＳｏＣ。
少なくとも１つのＩＰエージェントの動作クロック周波数を下げることによって実施され
る、ＳｏＣ。
【請求項47】
請求項３８から４６のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記
少なくとも１つのＩＰエージェントによって利用される電圧を下げることによって実行さ
れる、ＳｏＣ。
少なくとも１つのＩＰエージェントによって利用される電圧を下げることによって実行さ
れる、ＳｏＣ。
【請求項48】
請求項３８から４７のいずれか一項に記載のＳｏＣであって、前記低電力状態は、
前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げ、
前記動作クロック周波数を下げた後に、前記少なくとも１つのＩＰエージェントによっ
て利用される供給電圧を下げることによって実行される、ＳｏＣ。
前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げ、
前記動作クロック周波数を下げた後に、前記少なくとも１つのＩＰエージェントによっ
て利用される供給電圧を下げることによって実行される、ＳｏＣ。
【請求項49】
システムオンチップ（ＳｏＣ）であって、
少なくとも１つのＩＰエージェントと、
相互接続と、
前記ＩＰエージェントと前記相互接続とを接続するリンクと、
前記ＩＰエージェントを動作不能状態にするよう構成されている電力マネージャと、
休止マネージャと、
を備え、
前記休止マネージャは、
（ａ）トランザクションの生成を停止するよう前記ＩＰエージェントに命令し、
（ｂ）前記ＩＰエージェントによって生成されたすべてのトランザクションが完了すると
、前記リンクを休止状態にし、
（ｃ）前記動作不能状態に入るためのシーケンスを前記ＩＰエージェントに開始させるこ
とによって、前記リンクを前記休止状態にするよう構成されている、ＳｏＣ。
少なくとも１つのＩＰエージェントと、
相互接続と、
前記ＩＰエージェントと前記相互接続とを接続するリンクと、
前記ＩＰエージェントを動作不能状態にするよう構成されている電力マネージャと、
休止マネージャと、
を備え、
前記休止マネージャは、
（ａ）トランザクションの生成を停止するよう前記ＩＰエージェントに命令し、
（ｂ）前記ＩＰエージェントによって生成されたすべてのトランザクションが完了すると
、前記リンクを休止状態にし、
（ｃ）前記動作不能状態に入るためのシーケンスを前記ＩＰエージェントに開始させるこ
とによって、前記リンクを前記休止状態にするよう構成されている、ＳｏＣ。
【請求項50】
請求項４９に記載のＳｏＣであって、さらに、前記動作不能状態にある時に前記ＩＰエ
ージェントの代理として前記相互接続を構成することを含む、ＳｏＣ。
ージェントの代理として前記相互接続を構成することを含む、ＳｏＣ。
【請求項51】
請求項５０に記載のＳｏＣであって、前記相互接続は、
前記動作不能状態にある前記ＩＰエージェントに送信元がトランザクションを送信した
か否かを確認し、
前記送信元に例外メッセージを送信して、前記ＩＰエージェントが利用可能ではないこ
とを前記送信元に通知することによって、前記ＩＰエージェントの前記代理として機能す
る、ＳｏＣ。
前記動作不能状態にある前記ＩＰエージェントに送信元がトランザクションを送信した
か否かを確認し、
前記送信元に例外メッセージを送信して、前記ＩＰエージェントが利用可能ではないこ
とを前記送信元に通知することによって、前記ＩＰエージェントの前記代理として機能す
る、ＳｏＣ。
【請求項52】
請求項４９から５１のいずれか一項に記載のＳｏＣであって、前記ＩＰエージェントは
、さらに、ウェイクアップトリガイベントに応答して、前記動作不能状態にある時に、「
ウェイクアップ」シーケンスを開始するよう構成されている、ＳｏＣ。
、さらに、ウェイクアップトリガイベントに応答して、前記動作不能状態にある時に、「
ウェイクアップ」シーケンスを開始するよう構成されている、ＳｏＣ。
【請求項53】
請求項５２に記載のＳｏＣであって、前記ウェイクアップトリガイベントは、
（ａ）前記ＩＰエージェントが、前記ＳｏＣの外部の送信元から通信を受信すること、
（ｂ）所定の期間が経過したこと、
（ｃ）システムコントローラによって命令された時、または、
（ｄ）有効なトランザクションが、前記動作不能状態の前記ＩＰエージェントを目標にす
ること、の内の１つを含む、ＳｏＣ。
（ａ）前記ＩＰエージェントが、前記ＳｏＣの外部の送信元から通信を受信すること、
（ｂ）所定の期間が経過したこと、
（ｃ）システムコントローラによって命令された時、または、
（ｄ）有効なトランザクションが、前記動作不能状態の前記ＩＰエージェントを目標にす
ること、の内の１つを含む、ＳｏＣ。
【請求項54】
請求項５２に記載のＳｏＣであって、前記ウェイクアップシーケンスは、前記ＩＰエー
ジェントが、前記ウェイクアップトリガイベントに応答して、前記リンクを介して前記相
互接続にウェイクアップ通信を送信することを含む、ＳｏＣ。
ジェントが、前記ウェイクアップトリガイベントに応答して、前記リンクを介して前記相
互接続にウェイクアップ通信を送信することを含む、ＳｏＣ。
【請求項55】
請求項５４に記載のＳｏＣであって、前記ウェイクアップシーケンスは、前記相互接続
が前記ウェイクアップ通信をシステムコントローラに転送することを含む、ＳｏＣ。
が前記ウェイクアップ通信をシステムコントローラに転送することを含む、ＳｏＣ。
【請求項56】
請求項５５に記載のＳｏＣであって、前記ウェイクアップシーケンスは、さらに、前記
システムコントローラが、前記相互接続によって転送された前記ウェイクアップ通信を受
信したことに応答して、ウェイクアップコマンドを前記ＩＰエージェントに送信すること
を含む、ＳｏＣ。
システムコントローラが、前記相互接続によって転送された前記ウェイクアップ通信を受
信したことに応答して、ウェイクアップコマンドを前記ＩＰエージェントに送信すること
を含む、ＳｏＣ。
【請求項57】
請求項５６に記載のＳｏＣであって、前記ウェイクアップシーケンスは、さらに、前記
ＩＰエージェントが、前記ウェイクアップコマンドに応答して、自身のウェイクアッププ
ロトコルを開始することを含む、ＳｏＣ。
ＩＰエージェントが、前記ウェイクアップコマンドに応答して、自身のウェイクアッププ
ロトコルを開始することを含む、ＳｏＣ。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願への相互参照
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９（ＰＲＴ
ＩＰ００１Ｐ）号および２０１８年６月２８日出願の米国仮出願第６２／６９１，１１７
（ＰＲＴ１Ｐ００２Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々
は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。
本願は、２０１８年３月３０日出願の米国仮特許出願第６２／６５０，５８９（ＰＲＴ
ＩＰ００１Ｐ）号および２０１８年６月２８日出願の米国仮出願第６２／６９１，１１７
（ＰＲＴ１Ｐ００２Ｐ）号に基づく優先権を主張する。これら優先権主張基礎出願の各々
は、すべての目的のためにその全体が参照によって本明細書に組み込まれる。
【0002】
本願は、システムオンチップ（ＳｏＣ）に関し、より具体的には、ＳｏＣ上でリセット
および／または電力管理機能を一貫して実施し、ひいては、特に複数のＳｏＣファミリー
にわたって、ＳｏＣのより一様なシステムソフトウェアビューを提供するシステムおよび
方法に関する。
および／または電力管理機能を一貫して実施し、ひいては、特に複数のＳｏＣファミリー
にわたって、ＳｏＣのより一様なシステムソフトウェアビューを提供するシステムおよび
方法に関する。
【背景技術】
【0003】
システムオンチップ（「ＳｏＣ」）は、複数のサブシステムを備える集積回路であり、
しばしば、知的財産（「ＩＰ」）エージェントと呼ばれる。ＩＰエージェントは、典型的
には、特定の機能を実装または実行するように設計された回路の「再利用可能な」ブロッ
クである。ＩＰエージェントを用いることにより、複雑なＳｏＣを開発する時間およびコ
ストを大幅に削減できる。
しばしば、知的財産（「ＩＰ」）エージェントと呼ばれる。ＩＰエージェントは、典型的
には、特定の機能を実装または実行するように設計された回路の「再利用可能な」ブロッ
クである。ＩＰエージェントを用いることにより、複雑なＳｏＣを開発する時間およびコ
ストを大幅に削減できる。
【0004】
ＳｏＣは、典型的には、システムコントローラと、相互接続（バスまたはネットワーク
オンチップ（ＮｏＣ）など）と、を備える。システムコントローラは、システムソフトウ
ェアを実行し、ＳｏＣの全体動作を管理するために提供される。様々なＩＰエージェント
が、１以上のリンクを介して相互接続に接続されており、相互接続を介して互いに通信す
る。
オンチップ（ＮｏＣ）など）と、を備える。システムコントローラは、システムソフトウ
ェアを実行し、ＳｏＣの全体動作を管理するために提供される。様々なＩＰエージェント
が、１以上のリンクを介して相互接続に接続されており、相互接続を介して互いに通信す
る。
【0005】
ＳｏＣ開発者は、一般に、しばしば複数のベンダからの異なるＩＰエージェントを利用
する。各ＩＰエージェントは、通常、リセットのための独自の手順を実装する。ＳｏＣ上
のシステムコントローラおよび相互接続の観点から、これは、いくつかの理由で問題があ
る。
する。各ＩＰエージェントは、通常、リセットのための独自の手順を実装する。ＳｏＣ上
のシステムコントローラおよび相互接続の観点から、これは、いくつかの理由で問題があ
る。
【0006】
典型的なＳｏＣは、通常、相互接続に接続された複数のＩＰエージェントを有する。リ
セット後に、ＩＰエージェントの各々は、自身が用いる独自のリセット手順により、異な
る時間にリセット状態から出る可能性がある。各ＩＰエージェントがリセットから出る時
間が異なることで、重大な問題が起こりうる。送信元ＩＰエージェントが、まだリセット
中である宛先ＩＰエージェントへのトランザクションを生成した場合、（１）宛先ＩＰエ
ージェントは、要求を処理することができず、（２）送信元ＩＰエージェントは、応答を
決して受信しない。結果として、システム全体が、ハングアップする場合があり、おそら
くは、システム全体のリセットが必要となる。
セット後に、ＩＰエージェントの各々は、自身が用いる独自のリセット手順により、異な
る時間にリセット状態から出る可能性がある。各ＩＰエージェントがリセットから出る時
間が異なることで、重大な問題が起こりうる。送信元ＩＰエージェントが、まだリセット
中である宛先ＩＰエージェントへのトランザクションを生成した場合、（１）宛先ＩＰエ
ージェントは、要求を処理することができず、（２）送信元ＩＰエージェントは、応答を
決して受信しない。結果として、システム全体が、ハングアップする場合があり、おそら
くは、システム全体のリセットが必要となる。
【0007】
ハングアップを防止するための１つの周知のアプローチは、相互接続と各ＩＰエージェ
ントとの間の各リンクの中間に回路を設計して配置することである。この回路の目的は、
相互接続に接続された全ＩＰエージェントが同じクロックサイクル中にリセットから出る
のを確実にすることである。しかしながら、このアプローチには、いくつかの理由で欠点
がある。
１．中間回路の設計には、時間および労力を要し、しばしば、ＳｏＣの開発を遅らせる。
２．中間回路は、ＳｏＣごとに、典型的には、異なる設計チームによって開発される。結
果として、中間回路は、通常は、ＳｏＣごとに異なり、または、同じＳｏＣ上の異なるサ
ブシステムの間ですら異なる。
３．回路の複雑さは、通常、所与の相互接続へ接続できるＩＰエージェントの数が制限さ
れることを意味する。この制限の実際的な影響は、所与の数のＩＰエージェントを収容す
るために必要な相互接続レベルが多くなることである。したがって、ＳｏＣの全体の複雑
さが増大する。
ントとの間の各リンクの中間に回路を設計して配置することである。この回路の目的は、
相互接続に接続された全ＩＰエージェントが同じクロックサイクル中にリセットから出る
のを確実にすることである。しかしながら、このアプローチには、いくつかの理由で欠点
がある。
１．中間回路の設計には、時間および労力を要し、しばしば、ＳｏＣの開発を遅らせる。
２．中間回路は、ＳｏＣごとに、典型的には、異なる設計チームによって開発される。結
果として、中間回路は、通常は、ＳｏＣごとに異なり、または、同じＳｏＣ上の異なるサ
ブシステムの間ですら異なる。
３．回路の複雑さは、通常、所与の相互接続へ接続できるＩＰエージェントの数が制限さ
れることを意味する。この制限の実際的な影響は、所与の数のＩＰエージェントを収容す
るために必要な相互接続レベルが多くなることである。したがって、ＳｏＣの全体の複雑
さが増大する。
【0008】
時々、ＩＰエージェントが正常に機能しない。例えば、ＩＰエージェントは、偽のトラ
ンザクションを相互接続へ投入する、受信したトランザクションへの応答に失敗して、例
外メッセージを生成する、などの場合がある。いくつかの状況において、正常に機能しな
いＩＰエージェントは、リセットされる必要がありうる。現行のＳｏＣ相互接続規格では
、標準ＩＰエージェントリセットメカニズムが存在しない。ＳｏＣ全体がリセットされな
ければならないか、もしくは、中間回路が、必要な隔離、リセット、および、システムへ
のＩＰの再導入などを実行するよう設計される必要があるか、のいずれかである。
ンザクションを相互接続へ投入する、受信したトランザクションへの応答に失敗して、例
外メッセージを生成する、などの場合がある。いくつかの状況において、正常に機能しな
いＩＰエージェントは、リセットされる必要がありうる。現行のＳｏＣ相互接続規格では
、標準ＩＰエージェントリセットメカニズムが存在しない。ＳｏＣ全体がリセットされな
ければならないか、もしくは、中間回路が、必要な隔離、リセット、および、システムへ
のＩＰの再導入などを実行するよう設計される必要があるか、のいずれかである。
【0009】
電力管理も、特定の現行のＳｏＣ相互接続規格では対処されていない。アドバンスト・
マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）プロトコルは、例えば、電力
管理に対処せず、意図的に電力を落とすかまたはＩＰエージェントをオフにする方法を提
供していない。この機能を提供するためには、電力管理機能は、典型的に、例えば、電力
管理を扱うためにリンク上のさらなる中間回路を開発することによって、チップごとにＳ
ｏＣへカスタム設計される必要がある。
マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）プロトコルは、例えば、電力
管理に対処せず、意図的に電力を落とすかまたはＩＰエージェントをオフにする方法を提
供していない。この機能を提供するためには、電力管理機能は、典型的に、例えば、電力
管理を扱うためにリンク上のさらなる中間回路を開発することによって、チップごとにＳ
ｏＣへカスタム設計される必要がある。
【0010】
複数のＳｏＣを提供する多くの企業が、製品化までの時間を短縮するために、類似した
デバイスの間で或る程度のシステムソフトウェアを共有する。しかしながら、類似したＳ
ｏＣでも、ソフトウェアは、典型的には、ＩＰエージェントが同じでありうる状況であっ
ても、デバイスからデバイスへと簡単には移植できない。リセットおよび／または電力管
理に用いられる任意の中間回路に小さい違いがあれば、システムソフトウェアは、各デバ
イスに向けて修正およびデバッグされる必要がありうる。
デバイスの間で或る程度のシステムソフトウェアを共有する。しかしながら、類似したＳ
ｏＣでも、ソフトウェアは、典型的には、ＩＰエージェントが同じでありうる状況であっ
ても、デバイスからデバイスへと簡単には移植できない。リセットおよび／または電力管
理に用いられる任意の中間回路に小さい違いがあれば、システムソフトウェアは、各デバ
イスに向けて修正およびデバッグされる必要がありうる。
【0011】
したがって、多数のＳｏＣを開発する企業の課題は、（１）各デバイスに対してリセッ
トおよびおそらくは電力管理を実施するためのカスタマイズされた回路を開発すること、
ならびに、（２）各デバイスに対してシステムソフトウェアを修正およびデバッグするこ
と、である。複数のデバイスにわたるこの努力は、費用が掛かり、複雑で、時間が掛かる
ため、製品をすみやかに市場に出す能力を低下させる。
トおよびおそらくは電力管理を実施するためのカスタマイズされた回路を開発すること、
ならびに、（２）各デバイスに対してシステムソフトウェアを修正およびデバッグするこ
と、である。複数のデバイスにわたるこの努力は、費用が掛かり、複雑で、時間が掛かる
ため、製品をすみやかに市場に出す能力を低下させる。
【0012】
したがって、カスタマイゼーションの必要性を無くし、複数のＳＯＣの間の一貫したシ
ステムソフトウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電
力管理を一貫して実施するためのシステムが求められている。
ステムソフトウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電
力管理を一貫して実施するためのシステムが求められている。
【発明の概要】
【0013】
カスタマイゼーションの必要性を無くし、複数のＳＯＣの間の一貫したシステムソフト
ウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫
して実施するためのシステムが開示されている。
ウェアビューにつながる、ＳｏＣ上のＩＰエージェントのリセットおよび電力管理を一貫
して実施するためのシステムが開示されている。
【0014】
一実施形態において、システムは、１以上のＩＰエージェントと、相互接続と、それぞ
れＩＰエージェントおよび相互接続の間の１以上のリンクと、を備える。ＩＰエージェン
トがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰ
エージェントとの間で行われる。個々のネゴシエーションでは、各ＩＰエージェントが、
他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセット
から出ることができる。リセットから出た後、各ＩＰエージェントは、「トランザクショ
ン準備完了状態」になり、相互接続に導入され、相互接続に接続された他の要素（システ
ムコントローラなど）にとって可視になる。
れＩＰエージェントおよび相互接続の間の１以上のリンクと、を備える。ＩＰエージェン
トがリセットを受ける時、個々のネゴシエーションが、リンクを介して相互接続と各ＩＰ
エージェントとの間で行われる。個々のネゴシエーションでは、各ＩＰエージェントが、
他のＩＰエージェントのタイミングから独立して、自身のタイムスケジュールでリセット
から出ることができる。リセットから出た後、各ＩＰエージェントは、「トランザクショ
ン準備完了状態」になり、相互接続に導入され、相互接続に接続された他の要素（システ
ムコントローラなど）にとって可視になる。
【0015】
別の実施形態において、相互接続は、動作不能である任意のＩＰエージェントの代理と
して構成されてよい。この特徴は、（１）トランザクション準備完了状態になる前、（２
）動作不良時、および／または、（３）電力ダウン状態の時の動作不能時に、ＩＰエージ
ェントがトランザクションの目標になった場合に起こりうるシステム全体のハングアップ
を防止するので有利である。相互接続が代理として機能する場合に、トランザクションを
送信した送信元に、例外メッセージが送信されることで、送信元が目標ＩＰエージェント
からの応答を無期限に待つことによって引き起こされるハングアップを防止することがで
きる。
して構成されてよい。この特徴は、（１）トランザクション準備完了状態になる前、（２
）動作不良時、および／または、（３）電力ダウン状態の時の動作不能時に、ＩＰエージ
ェントがトランザクションの目標になった場合に起こりうるシステム全体のハングアップ
を防止するので有利である。相互接続が代理として機能する場合に、トランザクションを
送信した送信元に、例外メッセージが送信されることで、送信元が目標ＩＰエージェント
からの応答を無期限に待つことによって引き起こされるハングアップを防止することがで
きる。
【0016】
さらに別の実施形態において、相互接続がＩＰエージェントの代理として機能するよう
に構成できることで、（１）ＩＰエージェントを個々にリセットすること、および、（２
）ＩＰエージェントを節電状態にすることが可能になる。様々な実施形態において、節電
状態は、低電力動作可能モード、状態情報の保持または非保持の低電力動作不能モード、
もしくは、電力オフモードなど、いくつかのモードの内の１つを含みうる。
に構成できることで、（１）ＩＰエージェントを個々にリセットすること、および、（２
）ＩＰエージェントを節電状態にすることが可能になる。様々な実施形態において、節電
状態は、低電力動作可能モード、状態情報の保持または非保持の低電力動作不能モード、
もしくは、電力オフモードなど、いくつかのモードの内の１つを含みうる。
【0017】
したがって、本発明は、多くの課題を解決する。本発明は、同じ時間／クロックサイク
ル中にリセットから出るように各ＩＰエージェントを管理するため、および、（２）ＩＰ
エージェントの電力管理のためのカスタム回路を作る必要性を排除する。代わりに、本発
明は、これらの機能両方の一様な実施を有利に提供し、複数のＳｏＣの間の一貫したシス
テムソフトウェアビューをもたらす。この一貫したソフトウェアビューによれば、ＳｏＣ
のファミリーにわたるカスタム設計およびソフトウェア変更の多くが排除され、開発コス
トの節約、複雑さの低減、および、製品化までの時間短縮が達成される。
ル中にリセットから出るように各ＩＰエージェントを管理するため、および、（２）ＩＰ
エージェントの電力管理のためのカスタム回路を作る必要性を排除する。代わりに、本発
明は、これらの機能両方の一様な実施を有利に提供し、複数のＳｏＣの間の一貫したシス
テムソフトウェアビューをもたらす。この一貫したソフトウェアビューによれば、ＳｏＣ
のファミリーにわたるカスタム設計およびソフトウェア変更の多くが排除され、開発コス
トの節約、複雑さの低減、および、製品化までの時間短縮が達成される。
【図面の簡単な説明】
【0018】
本願およびその利点については、添付の図面に関連して行う以下の説明を参照すること
によって最も良く理解できる。
によって最も良く理解できる。
【0019】
【図1】非排他的実施形態に従って、システムオンチップ（ＳｏＣ）のための共有相互接続を示すブロック図。
【0020】
【図2】非排他的実施形態に従って、トランザクションのパケットの例を示す図。
【0021】
【図3A】第１非排他的実施形態に従って、アービトレーション要素を示す論理図。
【0022】
【図3B】第２非排他的実施形態に従って、アービトレーション要素を示す論理図。
【0023】
【図4】非排他的実施形態に従って、共有相互接続の仮想チャネルを介してトランザクションの部分をアービトレーションして送信するための動作工程を示すフローチャート。
【0024】
【図5】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第１例を示す図。
【0025】
【図6】非排他的実施形態に従って、共有相互接続の仮想チャネルを介して異なるトランザクションの部分の伝送をインターリーブする第２例を示す図。
【0026】
【図7】本発明の別の非排他的実施形態に従って、二方向にトラフィックを扱うための２つの共有相互接続を示すブロック図。
【0027】
【図8】本発明の非排他的実施形態に従って、リセット、電力管理、および、休止機能を有するＳｏＣを示すブロック図。
【0028】
【図9】本発明の非排他的実施形態に従って、ＩＰエージェントのリセットシーケンスを示すフローチャート。
【0029】
【図10】本発明の非排他的実施形態に従って、動作不良のＩＰエージェントのためのリセットシーケンスを示すフローチャート。
【0030】
【図11】本発明の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。
【0031】
【図12】本発明の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。
【0032】
【図13】本発明のさらに別の非排他的実施形態に従って、ＩＰエージェントのための電力ダウン／アップシーケンスを示すフローチャート。
【0033】
【図14】リンクを休止状態にするための工程を示すフローチャート。
【0034】
【図15A】ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。
【図15B】ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。
【図15C】ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。
【図15D】ＩＰエージェントのための「ウェイクアップ」シーケンスを示すフローチャート。
【0035】
図面において、同様の構造要素を指定するために、同様の符号が用いられることがある
。
。
【発明を実施するための形態】
【0036】
以下では、添付図面に例示された、いくつかの非排他的な実施形態を参照しつつ、本願
の詳細な説明を行う。以下の説明では、本開示の完全な理解を促すために、数多くの具体
的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本開示は
、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。ま
た、本開示が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造
については、詳細な説明を省略した。
の詳細な説明を行う。以下の説明では、本開示の完全な理解を促すために、数多くの具体
的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本開示は
、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。ま
た、本開示が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造
については、詳細な説明を省略した。
【0037】
現在開発中の集積回路の多くは、非常に複雑である。結果として、多くのチップ設計者
は、システムオンチップすなわち「ＳｏＣ」アプローチを用いて、単一のシリコン上に複
数のサブシステムまたはＩＰエージェントを相互接続してきた。消費者デバイス（例えば
、ハンドヘルド、携帯電話、タブレットコンピュータ、ラップトップおよびデスクトップ
コンピュータ、メデイア処理など）、仮想または拡張現実（例えば、ロボット工学、自律
走行車、航空機など）、医療機器（例えば、イメージングなど）、工業、ホームオートメ
ーション、工業（例えば、スマート家電、家庭用監視機器、など）およびデータセンター
用途（例えば、ネットワークスイッチ、接続型ストレージデバイス、など）など、様々な
用途のためのＳｏＣが、現在利用可能であるかまたは開発されている。
は、システムオンチップすなわち「ＳｏＣ」アプローチを用いて、単一のシリコン上に複
数のサブシステムまたはＩＰエージェントを相互接続してきた。消費者デバイス（例えば
、ハンドヘルド、携帯電話、タブレットコンピュータ、ラップトップおよびデスクトップ
コンピュータ、メデイア処理など）、仮想または拡張現実（例えば、ロボット工学、自律
走行車、航空機など）、医療機器（例えば、イメージングなど）、工業、ホームオートメ
ーション、工業（例えば、スマート家電、家庭用監視機器、など）およびデータセンター
用途（例えば、ネットワークスイッチ、接続型ストレージデバイス、など）など、様々な
用途のためのＳｏＣが、現在利用可能であるかまたは開発されている。
【0038】
本願は、共有リソースへのアクセスをアービトレートするためのアービトレーションシ
ステムおよび方法をおおむね対象にしている。かかる共有リソースは、例えば、バス相互
接続、メモリリソース、処理リソース、または、複数の競争パーティの間で共有されたほ
ぼ任意のその他のリソースでありうる。説明の便宜上、以下で詳述する共有リソースは、
システムオンチップすなわち「ＳｏＣ」上の複数のサブシステムによって共有される相互
接続であるとする。
ステムおよび方法をおおむね対象にしている。かかる共有リソースは、例えば、バス相互
接続、メモリリソース、処理リソース、または、複数の競争パーティの間で共有されたほ
ぼ任意のその他のリソースでありうる。説明の便宜上、以下で詳述する共有リソースは、
システムオンチップすなわち「ＳｏＣ」上の複数のサブシステムによって共有される相互
接続であるとする。
【0039】
ＳｏＣでは、後に詳述するように、トランザクションの形態で互いにトラフィックをや
り取りする複数のサブシステムがあり、共有リソースは、物理的な相互接続であり、様々
なトランザクションまたはその部分が、共有相互接続に関連する複数の仮想チャネルを介
して伝送され、複数の異なるアービトレーションスキームおよび／または優先度の１つが
、サブファンクションの間のトランザクションの伝送に向けた共有相互接続へのアクセス
をアービトレートするために用いられてよい。
り取りする複数のサブシステムがあり、共有リソースは、物理的な相互接続であり、様々
なトランザクションまたはその部分が、共有相互接続に関連する複数の仮想チャネルを介
して伝送され、複数の異なるアービトレーションスキームおよび／または優先度の１つが
、サブファンクションの間のトランザクションの伝送に向けた共有相互接続へのアクセス
をアービトレートするために用いられてよい。
【0040】
トランザクションクラス
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓ
ｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプま
たはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。
ＳｏＣに用いられる上述の共有相互接続内には、Ｐｏｓｔｅｄ（Ｐ）、Ｎｏｎ－ｐｏｓ
ｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）を含む少なくとも３つのタイプま
たはクラスのトランザクションが存在する。各々の簡単な定義を以下の表１に提供する。
【表1】
【0041】
Ｐｏｓｔｅｄトランザクション（書き込みなど）は、応答トランザクションを求めない
。送信元がデータを指定された宛先に書き込むと、トランザクションが終了する。Ｎｏｎ
－ｐｏｓｔｅｄトランザクション（読み出しまたは書き出しのいずれかなど）では、応答
が求められる。しかしながら、応答は、別個のＣｏｍｐｌｅｔｉｏｎトランザクションと
して分岐される。換言すると、読み出しでは、最初のトランザクションが読み出し動作の
ために用いられ、別個であるが関連するＣｏｍｐｌｅｔｉｏｎトランザクションが読み出
しコンテンツを返すために用いられる。Ｎｏｎ－ｐｏｓｔｅｄ書き込みでは、最初のトラ
ンザクションが書き込みのために用いられ、一方、書き込みが完了すると、第２関連Ｃｏ
ｍｐｌｅｔｉｏｎトランザクションが確認のために求められる。
。送信元がデータを指定された宛先に書き込むと、トランザクションが終了する。Ｎｏｎ
－ｐｏｓｔｅｄトランザクション（読み出しまたは書き出しのいずれかなど）では、応答
が求められる。しかしながら、応答は、別個のＣｏｍｐｌｅｔｉｏｎトランザクションと
して分岐される。換言すると、読み出しでは、最初のトランザクションが読み出し動作の
ために用いられ、別個であるが関連するＣｏｍｐｌｅｔｉｏｎトランザクションが読み出
しコンテンツを返すために用いられる。Ｎｏｎ－ｐｏｓｔｅｄ書き込みでは、最初のトラ
ンザクションが書き込みのために用いられ、一方、書き込みが完了すると、第２関連Ｃｏ
ｍｐｌｅｔｉｏｎトランザクションが確認のために求められる。
【0042】
トランザクションは、タイプに関わらず、１以上のパケットによって表すことができる
。いくつかの状況では、トランザクションは、単一のパケットによって表されうる。別の
状況においては、複数のパケットが、トランザクション全体を表すために必要とされうる
。
。いくつかの状況では、トランザクションは、単一のパケットによって表されうる。別の
状況においては、複数のパケットが、トランザクション全体を表すために必要とされうる
。
【0043】
ビートは、クロックサイクルあたりに共有相互接続を介して伝送できるデータの量であ
る。例えば、共有相互接続が物理的に１２８ビット幅である場合、１２８ビットが、各ビ
ートまたはクロックサイクルに伝送されうる。
る。例えば、共有相互接続が物理的に１２８ビット幅である場合、１２８ビットが、各ビ
ートまたはクロックサイクルに伝送されうる。
【0044】
いくつかの状況において、トランザクションは、伝送のために複数の部分に分割される
必要がありうる。５１２ビット（６４バイト）であるペイロードを有する単一のパケット
を有するトランザクションを考える。共有相互接続が１２８ビット幅（１６バイト）のみ
である場合、トランザクションは、４つの部分（例えば、４×１２８＝５１２）に分割さ
れ、４つのクロックサイクルまたはビートで伝送される必要がある。一方、トランザクシ
ョンが１２８ビット幅未満である単一パケットのみである場合、トランザクション全体が
、１つのクロックサイクルまたはビートで送信されうる。同じトランザクションがさらな
るパケットをたまたま含む場合、さらなるクロックサイクルまたはビートが必要とされう
る。
必要がありうる。５１２ビット（６４バイト）であるペイロードを有する単一のパケット
を有するトランザクションを考える。共有相互接続が１２８ビット幅（１６バイト）のみ
である場合、トランザクションは、４つの部分（例えば、４×１２８＝５１２）に分割さ
れ、４つのクロックサイクルまたはビートで伝送される必要がある。一方、トランザクシ
ョンが１２８ビット幅未満である単一パケットのみである場合、トランザクション全体が
、１つのクロックサイクルまたはビートで送信されうる。同じトランザクションがさらな
るパケットをたまたま含む場合、さらなるクロックサイクルまたはビートが必要とされう
る。
【0045】
したがって、トランザクションの「部分」という用語は、所与のクロックサイクルまた
はビート中に共有相互接続を介して転送できるデータの量である。部分のサイズは、共有
相互接続の物理的な幅に応じて変わりうる。例えば、共有相互接続が物理的に６４データ
ビット幅である場合、任意の１サイクルまたはビート中に転送できる最大ビット数は６４
ビットである。所与のトランザクションが６４ビット以下のペイロードを有する場合、ト
ランザクション全体が、単一部分で共有相互接続を介して送信されうる。一方、ペイロー
ドがより大きい場合、パケットは、複数の部分で共有相互接続を介して送信されなければ
ならない。１２８、２５６、または、５１２ビットのペイロードを有するトランザクショ
ンは、それぞれ、２、４、および、８の部分を必要とする。このように、「部分」という
用語は、任意の所与のクロックサイクルまたはビート中に共有相互接続を介して送信され
うるトランザクションの一部または全体のいずれかを意味すると広く解釈されるべきであ
る。
はビート中に共有相互接続を介して転送できるデータの量である。部分のサイズは、共有
相互接続の物理的な幅に応じて変わりうる。例えば、共有相互接続が物理的に６４データ
ビット幅である場合、任意の１サイクルまたはビート中に転送できる最大ビット数は６４
ビットである。所与のトランザクションが６４ビット以下のペイロードを有する場合、ト
ランザクション全体が、単一部分で共有相互接続を介して送信されうる。一方、ペイロー
ドがより大きい場合、パケットは、複数の部分で共有相互接続を介して送信されなければ
ならない。１２８、２５６、または、５１２ビットのペイロードを有するトランザクショ
ンは、それぞれ、２、４、および、８の部分を必要とする。このように、「部分」という
用語は、任意の所与のクロックサイクルまたはビート中に共有相互接続を介して送信され
うるトランザクションの一部または全体のいずれかを意味すると広く解釈されるべきであ
る。
【0046】
ストリーム
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義さ
れる。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３
）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１
２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々
な組み合わせを、以下の表２で詳述する。
ストリームは、仮想チャネルおよびトランザクションクラスのペアリングとして定義さ
れる。例えば、４つの仮想チャネル（例えば、ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３
）、ならびに、３つのトランザクションクラス（Ｐ、ＮＰ、Ｃ）があった場合、最大で１
２の異なる可能なストリームがある。仮想チャネルおよびトランザクションクラスの様々
な組み合わせを、以下の表２で詳述する。
【表2】
【0047】
上述したトランザクションクラスの数は、単に例示であり、限定として解釈すべきでは
ないことに注意されたい。逆に、任意の数の仮想チャネルおよび／またはトランザクショ
ンクラスが用いられてよい。
ないことに注意されたい。逆に、任意の数の仮想チャネルおよび／またはトランザクショ
ンクラスが用いられてよい。
【0048】
共有相互接続の仮想チャネルでのアービトレーション
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非
排他的実施形態において、アービトレーションシステムは、アップストリームサブファン
クション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信
しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、Ｉ
Ｐ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。
図１を参照すると、アービトレーションシステム１０のブロック図が示されている。非
排他的実施形態において、アービトレーションシステムは、アップストリームサブファン
クション１４（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）へトランザクションを送信
しようと試みる複数のサブファンクション１４（すなわち、ＩＰ１、ＩＰ２、および、Ｉ
Ｐ３）による共有相互接続１２へのアクセスをアービトレートするために用いられる。
【0049】
共有相互接続１２は、Ｎデータビット幅でありＭ個の制御ビットを含む物理的な相互接
続である。また、共有相互接続１２は一方向性であり、これは、送信元（すなわち、ＩＰ
１、ＩＰ２、および、ＩＰ３）から宛先（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）
への方向にのみトラフィックを扱うことを意味する。
続である。また、共有相互接続１２は一方向性であり、これは、送信元（すなわち、ＩＰ
１、ＩＰ２、および、ＩＰ３）から宛先（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６）
への方向にのみトラフィックを扱うことを意味する。
【0050】
様々な代替例において、Ｎデータビットの数は、任意の整数であってよいが、典型的に
は、それぞれ、２のべき乗のビット幅である（例えば、２１、２２、２３、２４、２５、
２６、２７、２８、２９など）または（２、４、６、８、１６、３２、６４、１２８、２
５６など）。最も現実的な応用例では、Ｎビットの数は、３２、６４、１２８、２５６、
または、５１２のいずれかである。ただし、これらの幅は、単に例示であり、どのように
も限定するものとして解釈すべきではないことを理解されたい。
は、それぞれ、２のべき乗のビット幅である（例えば、２１、２２、２３、２４、２５、
２６、２７、２８、２９など）または（２、４、６、８、１６、３２、６４、１２８、２
５６など）。最も現実的な応用例では、Ｎビットの数は、３２、６４、１２８、２５６、
または、５１２のいずれかである。ただし、これらの幅は、単に例示であり、どのように
も限定するものとして解釈すべきではないことを理解されたい。
【0051】
制御ビットの数Ｍも、様々であり、任意の数であってよい。
【0052】
１以上の論理チャネル（図示せず）（以降、「仮想チャネル」すなわち「ＶＣ」と呼ぶ
）が、共有相互接続１２に関連付けられている。各仮想チャネルは、独立している。各仮
想チャネルは、複数の独立ストリームに関連付けられてよい。仮想チャネルの数は、広く
変化してよい。例えば、３２以上の数までの仮想チャネルが、規定されるか、または、共
有相互接続１２に関連付けられてよい。
）が、共有相互接続１２に関連付けられている。各仮想チャネルは、独立している。各仮
想チャネルは、複数の独立ストリームに関連付けられてよい。仮想チャネルの数は、広く
変化してよい。例えば、３２以上の数までの仮想チャネルが、規定されるか、または、共
有相互接続１２に関連付けられてよい。
【0053】
様々な代替実施形態において、各仮想チャネルは、異なる優先度を割り当てられてよい
。１以上の仮想チャネルに、より高い優先度が割り当てられてよく、一方、１以上のその
他の仮想チャネルに、より低い優先度が割り当てられてよい。高い優先度のチャネルは、
低い優先度の仮想チャネルよりも高い共有相互接続１２へのアクセス権を与えられるまた
はアービトレートされる。別の実施形態では、仮想チャネルの各々に、同じ優先度が与え
られてもよく、その場合、共有相互接続１２へのアクセス権を与えるまたはアービトレー
トする時に、或る仮想チャネルを別の仮想チャネルより優先することがない。さらに別の
実施形態において、仮想チャネルの内の１以上に割り当てられた優先度は、動的に変化し
てもよい。例えば、第１セットの状況において、仮想チャネルすべてに、同じ優先度が割
り当てられてよいが、第２セットの状況において、特定の仮想チャネルに、その他の仮想
チャネルよりも高い優先度が割り当てられてもよい。したがって、状況が変化するにつれ
て、仮想チャネルの間で用いられる優先度スキームは、現在の動作条件に最もよく合うよ
うに変更されうる。
。１以上の仮想チャネルに、より高い優先度が割り当てられてよく、一方、１以上のその
他の仮想チャネルに、より低い優先度が割り当てられてよい。高い優先度のチャネルは、
低い優先度の仮想チャネルよりも高い共有相互接続１２へのアクセス権を与えられるまた
はアービトレートされる。別の実施形態では、仮想チャネルの各々に、同じ優先度が与え
られてもよく、その場合、共有相互接続１２へのアクセス権を与えるまたはアービトレー
トする時に、或る仮想チャネルを別の仮想チャネルより優先することがない。さらに別の
実施形態において、仮想チャネルの内の１以上に割り当てられた優先度は、動的に変化し
てもよい。例えば、第１セットの状況において、仮想チャネルすべてに、同じ優先度が割
り当てられてよいが、第２セットの状況において、特定の仮想チャネルに、その他の仮想
チャネルよりも高い優先度が割り当てられてもよい。したがって、状況が変化するにつれ
て、仮想チャネルの間で用いられる優先度スキームは、現在の動作条件に最もよく合うよ
うに変更されうる。
【0054】
サブシステム１４の各々は、典型的には、「再利用可能な」回路またはロジックのブロ
ックであり、一般に、ＩＰコアまたはエージェントと呼ばれる。 ほとんどのＩＰエージ
ェントは、特定の機能を実行するよう設計され、例えば、イーサネットポート、ディスプ
レイドライバ、ＳＤＲＡＭインターフェース、ＵＳＢポートなどの周辺デバイスのための
コントローラである。かかるＩＰエージェントは、一般に、特定用途向け集積回路（ＡＳ
ＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの集積回路（ＩＣ
）上に提供された複雑なシステムの設計全体の中で必要なサブシステム機能を提供する「
ビルディングブロック（構成要素）」として用いられる。利用可能なＩＰエージェントの
ライブラリを用いることにより、チップ設計者は、より複雑な集積回路の設計において様
々なロジック機能を容易に「ボルト締め」することができるので、設計時間を削減すると
共に開発コストを節約することができる。サブシステムエージェント１４は、専用ＩＰコ
アに関して上述したが、これは、必要条件ではないことを理解されたい。逆に、サブシス
テム１４は、単一のポート２０に接続されたまたはそれを共有するＩＰ機能のコレクショ
ンであってもよい。したがって、「エージェント」という用語は、サブシステムが単一の
機能を実行するか、複数の機能を実行するかに関わらず、ポート２０に接続された任意の
タイプのサブシステムとして広く解釈されるべきである。
ックであり、一般に、ＩＰコアまたはエージェントと呼ばれる。 ほとんどのＩＰエージ
ェントは、特定の機能を実行するよう設計され、例えば、イーサネットポート、ディスプ
レイドライバ、ＳＤＲＡＭインターフェース、ＵＳＢポートなどの周辺デバイスのための
コントローラである。かかるＩＰエージェントは、一般に、特定用途向け集積回路（ＡＳ
ＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの集積回路（ＩＣ
）上に提供された複雑なシステムの設計全体の中で必要なサブシステム機能を提供する「
ビルディングブロック（構成要素）」として用いられる。利用可能なＩＰエージェントの
ライブラリを用いることにより、チップ設計者は、より複雑な集積回路の設計において様
々なロジック機能を容易に「ボルト締め」することができるので、設計時間を削減すると
共に開発コストを節約することができる。サブシステムエージェント１４は、専用ＩＰコ
アに関して上述したが、これは、必要条件ではないことを理解されたい。逆に、サブシス
テム１４は、単一のポート２０に接続されたまたはそれを共有するＩＰ機能のコレクショ
ンであってもよい。したがって、「エージェント」という用語は、サブシステムが単一の
機能を実行するか、複数の機能を実行するかに関わらず、ポート２０に接続された任意の
タイプのサブシステムとして広く解釈されるべきである。
【0055】
一対のスイッチ１６および１８が、それぞれ、専用アクセスポート２０を介してサブシ
ステムエージェント１４の各々と共有相互接続１２との間のアクセスを提供する。図の例
示的実施形態では、
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセ
スＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒ
ｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６
へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。
ステムエージェント１４の各々と共有相互接続１２との間のアクセスを提供する。図の例
示的実施形態では、
（１）サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセ
スＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２を介してスイッチ１６と接続する。
（２）サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、Ｐｏｒ
ｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５を介してスイッチ１８と接続する。
（３）さらに、アクセスポート２２が、相互接続１２を介して、全体としてスイッチ１６
へのサブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６のアクセスを提供する。
【0056】
スイッチ１６および１８は、多重化および逆多重化機能を実行する。スイッチ１６は、
サブシステムエージェントＩＰ１、ＩＰ２、および／または、ＩＰ３によって生成された
アップストリームトラフィックを選択し、共有相互接続１２を介してトラフィックをダウ
ンストリームに送信する。スイッチ１８では、逆多重化動作が実行され、トラフィックは
、目標サブシステムエージェント（すなわち、ＩＰ４、ＩＰ５、または、ＩＰ６のいずれ
か）へ提供される。
サブシステムエージェントＩＰ１、ＩＰ２、および／または、ＩＰ３によって生成された
アップストリームトラフィックを選択し、共有相互接続１２を介してトラフィックをダウ
ンストリームに送信する。スイッチ１８では、逆多重化動作が実行され、トラフィックは
、目標サブシステムエージェント（すなわち、ＩＰ４、ＩＰ５、または、ＩＰ６のいずれ
か）へ提供される。
【0057】
各アクセスポート２０は、一意ポート識別子（ＩＤ）を有しており、各サブシステムエ
ージェント１４の専用アクセスをスイッチ１６または１８のいずれかへ提供する。例えば
、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスポ
ートＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２に割り当てられる。同様に、サブシス
テムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、アクセスポートＰｏｒ
ｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５に割り当てられる。
ージェント１４の専用アクセスをスイッチ１６または１８のいずれかへ提供する。例えば
、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、それぞれ、アクセスポ
ートＰｏｒｔ０、Ｐｏｒｔ１、および、Ｐｏｒｔ２に割り当てられる。同様に、サブシス
テムエージェントＩＰ４、ＩＰ５、および、ＩＰ６は、それぞれ、アクセスポートＰｏｒ
ｔ３、Ｐｏｒｔ４、および、Ｐｏｒｔ５に割り当てられる。
【0058】
スイッチ１６、１８への／からの入口ポイントおよび出口ポイントを提供するのに加え
て、一意ポートＩＤ２０は、サブシステムエージェント１４の間のトラフィックをアドレ
ッシングするために用いられる。各ポート２０は、システムメモリ２４内に、特定の量の
割り当てられたアドレス可能空間を有する。
て、一意ポートＩＤ２０は、サブシステムエージェント１４の間のトラフィックをアドレ
ッシングするために用いられる。各ポート２０は、システムメモリ２４内に、特定の量の
割り当てられたアドレス可能空間を有する。
【0059】
いくつかの非排他的な実施形態において、アクセスポート２０の全部または一部に、一
意ポートＩＤだけでなく、「グローバル」ポート識別子が割り当てられてもよい。トラン
ザクションおよびその他のトラフィックが、グローバルポート識別子に割り当てられたア
クセスポートの全部または一部に送信されうる。したがって、グローバル識別子を用いれ
ば、トランザクションおよびその他のトラフィックが、アクセスポート２０の全部または
一部へ広く発信またはブロードキャストすることができ、一意識別子を用いて各アクセス
ポート２０へ個別にアドレッシングする必要性を排除できる。
意ポートＩＤだけでなく、「グローバル」ポート識別子が割り当てられてもよい。トラン
ザクションおよびその他のトラフィックが、グローバルポート識別子に割り当てられたア
クセスポートの全部または一部に送信されうる。したがって、グローバル識別子を用いれ
ば、トランザクションおよびその他のトラフィックが、アクセスポート２０の全部または
一部へ広く発信またはブロードキャストすることができ、一意識別子を用いて各アクセス
ポート２０へ個別にアドレッシングする必要性を排除できる。
【0060】
スイッチ１６は、さらに、アービトレーション要素２６、アドレス解決ロジック（ＡＲ
Ｌ）２８、および、アドレス解決ルックアップテーブル（ＬＵＴ）３０を備える。
Ｌ）２８、および、アドレス解決ルックアップテーブル（ＬＵＴ）３０を備える。
【0061】
動作中、サブシステムエージェントＩＰ１、ＩＰ２、および、ＩＰ３は、トランザクシ
ョンを生成する。各トランザクションが生成されると、送信側サブシステム１４によって
パケット化され、次いで、パケット化されたトランザクションは、対応するポート２０を
介してローカルスイッチ１６へ投入される。例えば、ＩＰ１、ＩＰ２、および、ＩＰ３に
よって生成されたトランザクションの部分は、それぞれ、Ｐｏｒｔ０、Ｐｏｒｔ１、およ
び、Ｐｏｒｔ２を介してスイッチ１６に提供される。
ョンを生成する。各トランザクションが生成されると、送信側サブシステム１４によって
パケット化され、次いで、パケット化されたトランザクションは、対応するポート２０を
介してローカルスイッチ１６へ投入される。例えば、ＩＰ１、ＩＰ２、および、ＩＰ３に
よって生成されたトランザクションの部分は、それぞれ、Ｐｏｒｔ０、Ｐｏｒｔ１、およ
び、Ｐｏｒｔ２を介してスイッチ１６に提供される。
【0062】
ポート２０は各々、相互接続チャネル１２に関連付けられている仮想チャネルの各々に
対して、複数の先入れ先出しバッファ（図示せず）を備える。非排他的実施形態において
、４つの仮想チャネルが存在する。その場合、各仮想チャネルに対して１つで、各ポート
２０は、４つのバッファを備える。再び、ポート２０に含まれる仮想チャネルおよびバッ
ファの数は、様々であってよく、４に限定されないことを理解されたい。逆に、仮想チャ
ネルおよびバッファの数は、４より多くても少なくてもよい。
対して、複数の先入れ先出しバッファ（図示せず）を備える。非排他的実施形態において
、４つの仮想チャネルが存在する。その場合、各仮想チャネルに対して１つで、各ポート
２０は、４つのバッファを備える。再び、ポート２０に含まれる仮想チャネルおよびバッ
ファの数は、様々であってよく、４に限定されないことを理解されたい。逆に、仮想チャ
ネルおよびバッファの数は、４より多くても少なくてもよい。
【0063】
所与のトランザクションが２つ（以上）の部分で表される場合、それらの部分は、同じ
バッファ内に維持される。例えば、相互接続１２が１２８データビット幅であり、トラン
ザクションが５１２ビットのペイロードを含むパケットによって表される場合、トランザ
クションは、４クロックサイクルまたはビートで伝送される４つの部分に分割される必要
がある。一方、トランザクションが６４ビットのペイロードを有する単一パケットによっ
て表されうる場合、単一の部分は、１クロックサイクルまたはビートで伝送されうる。所
与のトランザクションのすべての部分を同じバッファ内に維持することにより、仮想チャ
ネルは、論理的に独立したままになる。換言すると、所与のトランザクションに関連する
トラフィックすべてが、常に、ストリームと同じ仮想チャネルで送信され、複数の仮想チ
ャネルを介して分岐されることがない。
バッファ内に維持される。例えば、相互接続１２が１２８データビット幅であり、トラン
ザクションが５１２ビットのペイロードを含むパケットによって表される場合、トランザ
クションは、４クロックサイクルまたはビートで伝送される４つの部分に分割される必要
がある。一方、トランザクションが６４ビットのペイロードを有する単一パケットによっ
て表されうる場合、単一の部分は、１クロックサイクルまたはビートで伝送されうる。所
与のトランザクションのすべての部分を同じバッファ内に維持することにより、仮想チャ
ネルは、論理的に独立したままになる。換言すると、所与のトランザクションに関連する
トラフィックすべてが、常に、ストリームと同じ仮想チャネルで送信され、複数の仮想チ
ャネルを介して分岐されることがない。
【0064】
アービトレーション要素２６は、様々なアクセスポート２０によって維持されたトラン
ザクションの競合するバッファされた部分の間でアービトレートすることを担う。非排他
的実施形態において、複数の競合トランザクションが利用可能であれば、アービトレーシ
ョン要素２６は、クロックサイクルごとにアービトレーションを実行する。サイクルごと
のアービトレーション勝者は、相互接続１２へのアクセスが認められて相互接続１２を介
して伝送されるトランザクションの部分を、サブシステムＩＰ１、ＩＰ２、および、ＩＰ
３の内の１つから生成する。
ザクションの競合するバッファされた部分の間でアービトレートすることを担う。非排他
的実施形態において、複数の競合トランザクションが利用可能であれば、アービトレーシ
ョン要素２６は、クロックサイクルごとにアービトレーションを実行する。サイクルごと
のアービトレーション勝者は、相互接続１２へのアクセスが認められて相互接続１２を介
して伝送されるトランザクションの部分を、サブシステムＩＰ１、ＩＰ２、および、ＩＰ
３の内の１つから生成する。
【0065】
トランザクションを生成する時、送信元サブシステムＩＰ１、ＩＰ２、および、ＩＰ３
は、通常、可能な宛先サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６につい
てアドレス空間内のアドレスを知っているが、宛先にトランザクションをルーティングす
るために必要な情報（例えば、ポートＩＤ２０および／または２２）を知らない。一実施
形態において、ローカルアドレス解決ロジック（ＡＲＬ）２８は、既知の宛先アドレスを
必要なルーティング情報に解決するために用いられる。換言すると、送信元サブエージェ
ント１４は、システムメモリ２４内の所与のアドレスにアクセスしたいことを単に知りう
る。したがって、ＡＲＬ２８は、ＬＵＴ３０へアクセスするタスクを課せられ、指定され
たアドレスに対応する最終的な宛先への配信パスに沿ってポート２０／２２のアドレスル
ックアップを実行する。ポート２０／２２が知られると、この情報は、トランザクション
のパケット内の宛先フィールドに挿入される。結果として、パケットは、配信パスに沿っ
てポート２０／２２へ配信される。原則として、要求された配信情報がすでに知られてお
り、パケットの宛先フィールドに含まれているので、配信パスに沿ったダウンストリーム
ノードが、さらなるルックアップを実行する必要はない。後に詳述するようにソースベー
スルーティング（ＳＢＲ）と呼ばれる他のタイプのトランザクションで、送信元Ｐエージ
ェントは、宛先ポートアドレスを知る。結果として、ＡＲＬ２８によって実行されるルッ
クアップは、典型的には、実行される必要がない。
は、通常、可能な宛先サブシステムエージェントＩＰ４、ＩＰ５、および、ＩＰ６につい
てアドレス空間内のアドレスを知っているが、宛先にトランザクションをルーティングす
るために必要な情報（例えば、ポートＩＤ２０および／または２２）を知らない。一実施
形態において、ローカルアドレス解決ロジック（ＡＲＬ）２８は、既知の宛先アドレスを
必要なルーティング情報に解決するために用いられる。換言すると、送信元サブエージェ
ント１４は、システムメモリ２４内の所与のアドレスにアクセスしたいことを単に知りう
る。したがって、ＡＲＬ２８は、ＬＵＴ３０へアクセスするタスクを課せられ、指定され
たアドレスに対応する最終的な宛先への配信パスに沿ってポート２０／２２のアドレスル
ックアップを実行する。ポート２０／２２が知られると、この情報は、トランザクション
のパケット内の宛先フィールドに挿入される。結果として、パケットは、配信パスに沿っ
てポート２０／２２へ配信される。原則として、要求された配信情報がすでに知られてお
り、パケットの宛先フィールドに含まれているので、配信パスに沿ったダウンストリーム
ノードが、さらなるルックアップを実行する必要はない。後に詳述するようにソースベー
スルーティング（ＳＢＲ）と呼ばれる他のタイプのトランザクションで、送信元Ｐエージ
ェントは、宛先ポートアドレスを知る。結果として、ＡＲＬ２８によって実行されるルッ
クアップは、典型的には、実行される必要がない。
【0066】
代替実施形態において、相互接続内のすべてのノードがＡＲＬ２８およびＬＵＴ３０を
必要とするわけではない。これらの要素を持たないノードについては、必要なルーティン
グ情報のないトランザクションが、デフォルトノードへ転送されうる。デフォルトノード
では、ＡＲＬ２８およびＬＵＴ３０がアクセスされ、次いで、必要なルーティング情報が
、トランザクションのパケットのヘッダに挿入されうる。デフォルトノードは、典型的に
は、ＡＲＬ２８およびＬＵＴ３０を持たないノードよりアップストリームにある。ただし
、これは、決して必須ではない。１または複数のデフォルトノードは、ＳｏＣ上のどこに
配置されてもよい。ＡＲＬ２８およびＬＵＴ３０をいくつかのノードから排除することに
より、ノードの複雑さを低減できる。
必要とするわけではない。これらの要素を持たないノードについては、必要なルーティン
グ情報のないトランザクションが、デフォルトノードへ転送されうる。デフォルトノード
では、ＡＲＬ２８およびＬＵＴ３０がアクセスされ、次いで、必要なルーティング情報が
、トランザクションのパケットのヘッダに挿入されうる。デフォルトノードは、典型的に
は、ＡＲＬ２８およびＬＵＴ３０を持たないノードよりアップストリームにある。ただし
、これは、決して必須ではない。１または複数のデフォルトノードは、ＳｏＣ上のどこに
配置されてもよい。ＡＲＬ２８およびＬＵＴ３０をいくつかのノードから排除することに
より、ノードの複雑さを低減できる。
【0067】
ＡＲＬ２８は、トランザクションの勝利部分のための転送先のデコードに加えて、各仮
想チャネル内のトランザクションの勝利部分のための順序を規定するので、「順序付けポ
イント」と呼ばれてもよい。各アービトレーションが解決されると、ＡＲＬ２８がアドレ
スポートルックアップを実行するために用いられるか否かに関わらず、トランザクション
の勝利部分が各仮想チャネルに提供される先入れ先出しキューに挿入される。次いで、ト
ランザクションの勝利部分は、バッファ内で相互接続１２を介した伝送の順番を待つ。
想チャネル内のトランザクションの勝利部分のための順序を規定するので、「順序付けポ
イント」と呼ばれてもよい。各アービトレーションが解決されると、ＡＲＬ２８がアドレ
スポートルックアップを実行するために用いられるか否かに関わらず、トランザクション
の勝利部分が各仮想チャネルに提供される先入れ先出しキューに挿入される。次いで、ト
ランザクションの勝利部分は、バッファ内で相互接続１２を介した伝送の順番を待つ。
【0068】
また、ＡＲＬ２８は、「アップストリーム」および「ダウンストリーム」トラフィック
を規定するために用いられる。換言すると、スイッチ１６に関連付けられているＩＰエー
ジェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）によって生成された任意の
トランザクションは、ＡＲＬ２８に対してアップストリームにあると見なされる。ＡＲＬ
２８後の（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６に伝送される）すべてのトランザ
クションが、ダウンストリームトラフィックと見なされる。
を規定するために用いられる。換言すると、スイッチ１６に関連付けられているＩＰエー
ジェント１４（すなわち、ＩＰ１、ＩＰ２、および、ＩＰ３）によって生成された任意の
トランザクションは、ＡＲＬ２８に対してアップストリームにあると見なされる。ＡＲＬ
２８後の（すなわち、ＩＰ４、ＩＰ５、および、ＩＰ６に伝送される）すべてのトランザ
クションが、ダウンストリームトラフィックと見なされる。
【0069】
スイッチ１６に関連付けられているＩＰエージェント１４（すなわち、ＩＰ１、ＩＰ２
、および、ＩＰ３）は、直接的または間接的のいずれかで、互いに通信してトランザクシ
ョンを互いに送信してよい。直接的な通信（しばしば、ソースベースルーティング（ＳＢ
Ｒ）と呼ばれる）により、ＩＰエージェント１４は、ピアツーピアモデルで互いにトラン
ザクションを送信できる。このモデルでは、送信元ＩＰエージェトは、そのピアＩＰエー
ジェント１４の一意ポートＩＤが知っており、ＬＵＴ３０にアクセスするためにＡＲＬ２
８を用いる必要性を無くす。あるいは、スイッチ１６に関連付けられているＩＰエージェ
ントの間のトランザクションは、ＡＲＬ２８を用いてルーティングされてもよい。このモ
デルでは、上述したのと同様に、送信元ＩＰエージェントは、宛先ＩＰエージェント１４
のアドレスのみを知り、ルーティングに必要な情報は知らない。次いで、ＡＲＬ２８は、
ＬＵＴ３０にアクセスし、対応するポートＩＤを見つけるために用いられ、その後、ポー
トＩＤは、トランザクションのパケットの宛先フィールドに挿入される。
、および、ＩＰ３）は、直接的または間接的のいずれかで、互いに通信してトランザクシ
ョンを互いに送信してよい。直接的な通信（しばしば、ソースベースルーティング（ＳＢ
Ｒ）と呼ばれる）により、ＩＰエージェント１４は、ピアツーピアモデルで互いにトラン
ザクションを送信できる。このモデルでは、送信元ＩＰエージェトは、そのピアＩＰエー
ジェント１４の一意ポートＩＤが知っており、ＬＵＴ３０にアクセスするためにＡＲＬ２
８を用いる必要性を無くす。あるいは、スイッチ１６に関連付けられているＩＰエージェ
ントの間のトランザクションは、ＡＲＬ２８を用いてルーティングされてもよい。このモ
デルでは、上述したのと同様に、送信元ＩＰエージェントは、宛先ＩＰエージェント１４
のアドレスのみを知り、ルーティングに必要な情報は知らない。次いで、ＡＲＬ２８は、
ＬＵＴ３０にアクセスし、対応するポートＩＤを見つけるために用いられ、その後、ポー
トＩＤは、トランザクションのパケットの宛先フィールドに挿入される。
【0070】
パケットフォーマット
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられ
ている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパ
ケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマット
を有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。
別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、また
は、ペイロードが全く無くてもよい。
ＩＰエージェント１４は、トランザクションを生成して、相互接続１２に関連付けられ
ている仮想チャネルを通じて処理する。各トランザクションは、典型的には、１以上のパ
ケットで構成される。各パケットは、典型的には、固定ヘッダサイズおよびフォーマット
を有する。いくつかの例において、各パケットは、固定サイズペイロードを有してよい。
別の例において、パケットペイロードは、大から小まで様々なサイズであってよく、また
は、ペイロードが全く無くてもよい。
【0071】
図２を参照すると、パケットの例３２が示されている。パケット３２は、ヘッダ３４お
よびペイロード３６を備える。この特定の実施形態において、ヘッダ３４は、１６バイト
のサイズである。このサイズは例示であり、より大きいサイズ（例えば、より多いバイト
数）または小さいサイズ（例えば、より少ないバイト数）のパケットが用いられてもよい
ことを理解されたい。パケット３２のヘッダ３４は、必ずしもすべてが同じサイズである
必要がないことも理解されたい。代替実施形態において、ＳｏＣにおけるパケットヘッダ
のサイズは、可変であってもよい。
よびペイロード３６を備える。この特定の実施形態において、ヘッダ３４は、１６バイト
のサイズである。このサイズは例示であり、より大きいサイズ（例えば、より多いバイト
数）または小さいサイズ（例えば、より少ないバイト数）のパケットが用いられてもよい
ことを理解されたい。パケット３２のヘッダ３４は、必ずしもすべてが同じサイズである
必要がないことも理解されたい。代替実施形態において、ＳｏＣにおけるパケットヘッダ
のサイズは、可変であってもよい。
【0072】
ヘッダ３４は、宛先識別子（ＤＳＴ＿ＩＤ）、送信元識別子（ＳＲＣ＿ＩＤ）、ペイロ
ードサイズインジケータ（ＰＬＤ＿ＳＺ）、予備フィールド（ＲＳＶＤ）、コマンドフィ
ールド（ＣＭＤ）、ＴＡＧフィールド、ステータス（ＳＴＳ）、トランザクションＩＤフ
ィールド（ＴＡＧ）、アドレスすなわちＡＤＤＲフィールド、ＵＳＤＲ／コンパクトペイ
ロードフィールド、トランザクションクラスすなわちＴＣフィールド、フォーマットＦＭ
Ｔフィールド、および、バイトイネーブル（ＢＥ）フィールドなど、複数のフィールドを
含む。ヘッダ３４の様々なフィールドについて、以下の表３で簡単に説明する。
ードサイズインジケータ（ＰＬＤ＿ＳＺ）、予備フィールド（ＲＳＶＤ）、コマンドフィ
ールド（ＣＭＤ）、ＴＡＧフィールド、ステータス（ＳＴＳ）、トランザクションＩＤフ
ィールド（ＴＡＧ）、アドレスすなわちＡＤＤＲフィールド、ＵＳＤＲ／コンパクトペイ
ロードフィールド、トランザクションクラスすなわちＴＣフィールド、フォーマットＦＭ
Ｔフィールド、および、バイトイネーブル（ＢＥ）フィールドなど、複数のフィールドを
含む。ヘッダ３４の様々なフィールドについて、以下の表３で簡単に説明する。
【表3】
【0073】
ペイロード３６は、パケットのコンテンツを含む。ペイロードのサイズは、様々であっ
てよい。いくつかの例において、ペイロードは大きくてよい。その他の例において、ペイ
ロードは小さくてもよい。さらに別の例において、コンテンツが非常に小さいすなわち「
コンパクト」である場合、ヘッダ３４のＵＳＲＤフィールド内で運ぶことができる。
てよい。いくつかの例において、ペイロードは大きくてよい。その他の例において、ペイ
ロードは小さくてもよい。さらに別の例において、コンテンツが非常に小さいすなわち「
コンパクト」である場合、ヘッダ３４のＵＳＲＤフィールド内で運ぶことができる。
【0074】
トランザクションのタイプは、しばしば、トランザクションを表すために用いられる１
以上のパケットがペイロードを持つか否かを示す。例えば、ＰｏｓｔｅｄまたはＮｏｎ－
ｐｏｓｔｅｄ読み出しのどちらでも、パケットは、アクセスされるロケーションアドレス
を指定するが、典型的には、ペイロードを持たない。しかしながら、関連するＣｏｍｐｌ
ｅｔｉｏｎトランザクションのパケットは、読み出しコンテンツを含むペイロードを含む
。ＰｏｓｔｅｄおよびＮｏｎ－ｐｏｓｔｅｄ書き込みトランザクションの両方で、パケッ
トは、宛先に書き込まれるデータを含むペイロードを含む。Ｎｏｎ－ｐｏｓｔｅｄバージ
ョンの書き込みでは、Ｃｏｍｐｌｅｔｉｏｎトランザクションのパケットは、通常、ペイ
ロードを定義しない。しかしながら、一部の状況では、Ｃｏｍｐｌｅｔｉｏｎトランザク
ションが、ペイロードを規定する。
以上のパケットがペイロードを持つか否かを示す。例えば、ＰｏｓｔｅｄまたはＮｏｎ－
ｐｏｓｔｅｄ読み出しのどちらでも、パケットは、アクセスされるロケーションアドレス
を指定するが、典型的には、ペイロードを持たない。しかしながら、関連するＣｏｍｐｌ
ｅｔｉｏｎトランザクションのパケットは、読み出しコンテンツを含むペイロードを含む
。ＰｏｓｔｅｄおよびＮｏｎ－ｐｏｓｔｅｄ書き込みトランザクションの両方で、パケッ
トは、宛先に書き込まれるデータを含むペイロードを含む。Ｎｏｎ－ｐｏｓｔｅｄバージ
ョンの書き込みでは、Ｃｏｍｐｌｅｔｉｏｎトランザクションのパケットは、通常、ペイ
ロードを定義しない。しかしながら、一部の状況では、Ｃｏｍｐｌｅｔｉｏｎトランザク
ションが、ペイロードを規定する。
【0075】
パケットの例および上述の説明は、パケットに含まれうる基本的なフィールドの多くを
網羅している。さらなるフィールドが削除または追加されてもよいことを理解されたい。
例えば、送信元および宛先がプライベートメッセージを共有できるように、プライベート
シグナリングフィールドが用いられてもよい。
網羅している。さらなるフィールドが削除または追加されてもよいことを理解されたい。
例えば、送信元および宛先がプライベートメッセージを共有できるように、プライベート
シグナリングフィールドが用いられてもよい。
【0076】
アービトレーション
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付
けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す
論理図が示されている。
図３Ａを参照すると、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）順位付
けでアービトレーション要素２６によって実行されるアービトレーションロジックを示す
論理図が示されている。
【0077】
ＰＣＩ順位付けでは、各ポート２０は、各仮想チャネルおよびトランザクションクラス
（Ｐ、ＮＰ、および、Ｃ）の組み合わせのための別個のバッファを備える。例えば、４つ
の仮想チャネル（ＶＣ０、ＶＣ０１、ＶＣ２、および、ＶＣ３）がある場合、Ｐｏｒｔ０
、Ｐｏｒｔ１、および、Ｐｏｒｔ２は各々、１２の先入れ先出しバッファを有する。換言
すると、各ポート２０について、バッファが、各トランザクションクラス（Ｐ、ＮＰ、お
よび、Ｃ）ならびに仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３０）の組み
合わせに対して提供される。
（Ｐ、ＮＰ、および、Ｃ）の組み合わせのための別個のバッファを備える。例えば、４つ
の仮想チャネル（ＶＣ０、ＶＣ０１、ＶＣ２、および、ＶＣ３）がある場合、Ｐｏｒｔ０
、Ｐｏｒｔ１、および、Ｐｏｒｔ２は各々、１２の先入れ先出しバッファを有する。換言
すると、各ポート２０について、バッファが、各トランザクションクラス（Ｐ、ＮＰ、お
よび、Ｃ）ならびに仮想チャネル（ＶＣ０、ＶＣ１、ＶＣ２、および、ＶＣ３０）の組み
合わせに対して提供される。
【0078】
各ＩＰエージェント１４（例えば、ＩＰ１、ＩＰ２、および、ＩＰ３）がトランザクシ
ョンを生成すると、結果として得られるパケットが、それぞれ、対応するポート（例えば
、ポート０、ポート１、および、ポート２）内で、トランザクションタイプに基づいて、
適切なバッファに配置される。例えば、ＩＰ１によって生成されたＰｏｓｔｅｄ（Ｐ）、
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクション
が、それぞれ、ポート０内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏ
ｎ－ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに配置される。ＩＰ２および
ＩＰ３によって生成されたトランザクションは、同様の方法でポート１およびポート２内
で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ－ｐｏｓｔｅｄ、および
、Ｃｏｍｐｌｅｔｉｏｎバッファに同様に配置される。
ョンを生成すると、結果として得られるパケットが、それぞれ、対応するポート（例えば
、ポート０、ポート１、および、ポート２）内で、トランザクションタイプに基づいて、
適切なバッファに配置される。例えば、ＩＰ１によって生成されたＰｏｓｔｅｄ（Ｐ）、
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）、および、Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクション
が、それぞれ、ポート０内で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏ
ｎ－ｐｏｓｔｅｄ、および、Ｃｏｍｐｌｅｔｉｏｎバッファに配置される。ＩＰ２および
ＩＰ３によって生成されたトランザクションは、同様の方法でポート１およびポート２内
で、割り当てられた仮想チャネルのためのＰｏｓｔｅｄ、Ｎｏｎ－ｐｏｓｔｅｄ、および
、Ｃｏｍｐｌｅｔｉｏｎバッファに同様に配置される。
【0079】
所与のトランザクションが複数のパケットによって表される場合、そのトランザクショ
ンのパケットすべてが、同じバッファ内に挿入される。結果として、トランザクションの
パケットすべてが、最終的に同じ仮想チャネルで伝送される。このポリシーでは、仮想チ
ャネルは独立したままであり、これは、同じトランザクションに関連する複数のパケット
の伝送には、異なる仮想チャネルが用いられないことを意味する。
ンのパケットすべてが、同じバッファ内に挿入される。結果として、トランザクションの
パケットすべてが、最終的に同じ仮想チャネルで伝送される。このポリシーでは、仮想チ
ャネルは独立したままであり、これは、同じトランザクションに関連する複数のパケット
の伝送には、異なる仮想チャネルが用いられないことを意味する。
【0080】
各ポート２０内で、多くの異なる方法で所与の仮想チャネルにパケットを割り当てるこ
とができる。例えば、割り当ては、無作為であってよい。あるいは、割り当ては、各仮想
チャネルに対する作業負荷と未処理のトラフィックの量とに基づいてもよい。あるチャネ
ルが非常にビジーであり、その他のチャネルがビジーではない場合、ポート２０は、しば
しば、負荷のバランスを取ろうと試み、新たに生成されたトランザクショントラフィック
を利用率の低い仮想チャネルに割り当てる。結果として、ルーティング効率が改善される
。さらに別の代替例において、トランザクショントラフィックは、緊急性、セキュリティ
、または、それら両方の組み合わせに基づいて、特定の仮想チャネルに割り当てられても
よい。特定の仮想チャネルが、他の仮想チャネルよりも高い優先度および／またはセキュ
リティを与えられた場合、高い優先度および／または安全なトラフィックが、より高い優
先度の仮想チャネルに割り当てられる。さらに別の実施形態において、ポート２０は、ハ
ードコードされてもよく、これは、ポート２０が、１つだけの仮想チャネルを有し、ポー
ト２０によって生成されたすべてのトラフィックが、その１つの仮想チャネルを介して伝
送されることを意味する。さらに別の実施形態において、割り当ては、宛先ポート２０に
到達するように選択されたルートに基づきうる。
とができる。例えば、割り当ては、無作為であってよい。あるいは、割り当ては、各仮想
チャネルに対する作業負荷と未処理のトラフィックの量とに基づいてもよい。あるチャネ
ルが非常にビジーであり、その他のチャネルがビジーではない場合、ポート２０は、しば
しば、負荷のバランスを取ろうと試み、新たに生成されたトランザクショントラフィック
を利用率の低い仮想チャネルに割り当てる。結果として、ルーティング効率が改善される
。さらに別の代替例において、トランザクショントラフィックは、緊急性、セキュリティ
、または、それら両方の組み合わせに基づいて、特定の仮想チャネルに割り当てられても
よい。特定の仮想チャネルが、他の仮想チャネルよりも高い優先度および／またはセキュ
リティを与えられた場合、高い優先度および／または安全なトラフィックが、より高い優
先度の仮想チャネルに割り当てられる。さらに別の実施形態において、ポート２０は、ハ
ードコードされてもよく、これは、ポート２０が、１つだけの仮想チャネルを有し、ポー
ト２０によって生成されたすべてのトラフィックが、その１つの仮想チャネルを介して伝
送されることを意味する。さらに別の実施形態において、割り当ては、宛先ポート２０に
到達するように選択されたルートに基づきうる。
【0081】
さらに別の実施形態において、仮想チャネルの割り当ては、送信元ＩＰエージェント１
４によって、単独で、または、それに対応するポート２０と連携して、実施されてもよい
。例えば、送信元ＩＰエージェント１４が、対応するポート２０への制御信号を生成して
、所与のトランザクションのパケットが特定の仮想チャネルに割り当てられることを要求
することができる。ＩＰエージェント１４も、上述のように、無作為である、ハードコー
ドされる、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリテ
ィ、緊急性などに基づいた割り当て決定をなすことができる。
４によって、単独で、または、それに対応するポート２０と連携して、実施されてもよい
。例えば、送信元ＩＰエージェント１４が、対応するポート２０への制御信号を生成して
、所与のトランザクションのパケットが特定の仮想チャネルに割り当てられることを要求
することができる。ＩＰエージェント１４も、上述のように、無作為である、ハードコー
ドされる、または、すべての仮想チャネルにわたってバランスの取れた利用、セキュリテ
ィ、緊急性などに基づいた割り当て決定をなすことができる。
【0082】
アービトレーション勝者の選択において、アービトレーション要素２６は、サイクルご
とに複数のアービトレーション工程を実行する。これらのアービトレーション工程は、以
下を含む。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。
とに複数のアービトレーション工程を実行する。これらのアービトレーション工程は、以
下を含む。
（１）ポートを選択する工程、
（２）仮想チャネルを選択する工程、および
（３）トランザクションクラスを選択する工程。
【0083】
上述の順序（１）、（２）、および、（３）は、固定ではない。逆に、上述の３つの工
程は、任意の順序で完了されてよい。どの順序が用いられるかに関わらず、単一のアービ
トレーション勝者が各サイクルで選択される。次いで、勝利トランザクションは、相互接
続１２に関連付けられている対応する仮想チャネルを介して伝送される。
程は、任意の順序で完了されてよい。どの順序が用いられるかに関わらず、単一のアービ
トレーション勝者が各サイクルで選択される。次いで、勝利トランザクションは、相互接
続１２に関連付けられている対応する仮想チャネルを介して伝送される。
【0084】
アービトレーション要素２６によって実行される各アービトレーション（１）、（２）
、および、（３）のために、複数のアービトレーションスキームまたはルールセットが用
いられてよい。かかるアービトレーションスキームは、厳密または絶対優先度、４つの仮
想チャネルの各々が特定の割合のトランザクショントラフックを割り当てられる重み付き
優先度、もしくは、トランザクションが所定の順序で仮想チャネルに割り当てられるラウ
ンドロビンスキーム、を含みうる。さらなる実施形態において、その他の優先度スキーム
が用いられてもよい。また、アービトレーション要素２６は、異なるアービトレーション
スキームの間で時々動的に切り替えを行ってもよい、および／または、（１）、（２）、
および、（３）アービトレーションの各々に対して同じまたは異なるアービトレーション
スキームをそれぞれ用いてもよいことを理解されたい。
、および、（３）のために、複数のアービトレーションスキームまたはルールセットが用
いられてよい。かかるアービトレーションスキームは、厳密または絶対優先度、４つの仮
想チャネルの各々が特定の割合のトランザクショントラフックを割り当てられる重み付き
優先度、もしくは、トランザクションが所定の順序で仮想チャネルに割り当てられるラウ
ンドロビンスキーム、を含みうる。さらなる実施形態において、その他の優先度スキーム
が用いられてもよい。また、アービトレーション要素２６は、異なるアービトレーション
スキームの間で時々動的に切り替えを行ってもよい、および／または、（１）、（２）、
および、（３）アービトレーションの各々に対して同じまたは異なるアービトレーション
スキームをそれぞれ用いてもよいことを理解されたい。
【0085】
任意選択的な実施形態において、所与のアービトレーションサイクル中に考慮された未
処理のトランザクションによって定義された宛先ポート２０の利用可能性が考慮される。
宛先ポート２０に内のバッファが、所与のトランザクションを処理するために利用可能な
リソースを持たない場合、対応する仮想チャネルは利用可能ではない。結果として、当該
トランザクションは、アービトレーションで競合せず、むしろ、目標リソースが利用可能
になる後続のアービトレーションサイクルまで待機する。一方、目標リソースが利用可能
である場合、対応するトランザクションは、アービトレートされ、相互接続１２へのアク
セスのために競合する。
処理のトランザクションによって定義された宛先ポート２０の利用可能性が考慮される。
宛先ポート２０に内のバッファが、所与のトランザクションを処理するために利用可能な
リソースを持たない場合、対応する仮想チャネルは利用可能ではない。結果として、当該
トランザクションは、アービトレーションで競合せず、むしろ、目標リソースが利用可能
になる後続のアービトレーションサイクルまで待機する。一方、目標リソースが利用可能
である場合、対応するトランザクションは、アービトレートされ、相互接続１２へのアク
セスのために競合する。
【0086】
宛先ポート２０の利用可能性は、上述した複数のアービトレーション工程（１）、（２
）、および、（３）に関して、異なる時にチェックされてよい。例えば、利用可能性チェ
ックは、アービトレーションサイクルの前に（すなわち、工程（１）、（２）、および、
（３）のいずれかの完了の前に）実行できる。結果として、利用可能な宛先リソースを規
定するトランザクションのみが、後続のアービトレーション中に考慮される。あるいは、
アービトレーションチェックは、アービトレーション工程が実行される順序に関わらず、
３つのアービトレーション工程（１）、（２）、および、（３）のいずれかの間に実行さ
れてもよい。
）、および、（３）に関して、異なる時にチェックされてよい。例えば、利用可能性チェ
ックは、アービトレーションサイクルの前に（すなわち、工程（１）、（２）、および、
（３）のいずれかの完了の前に）実行できる。結果として、利用可能な宛先リソースを規
定するトランザクションのみが、後続のアービトレーション中に考慮される。あるいは、
アービトレーションチェックは、アービトレーション工程が実行される順序に関わらず、
３つのアービトレーション工程（１）、（２）、および、（３）のいずれかの間に実行さ
れてもよい。
【0087】
アービトレーション処理中の早くまたは遅くに、宛先リソース利用可能性チェックを実
行することには利点および不利点がある。早くチェックを実行することにより、トランザ
クションの競合の可能性のある部分は、それらの宛先が利用可能でない場合に競合から潜
在的に排除されうる。しかしながら、利用可能性を早く知ることは、システムリソースへ
のかなりの量のオーバーヘッドを生み出しうる。結果として、状況に応じて、所与のアー
ビトレーションサイクル中に利用可能性チェックをより遅く実行するのが、より実際的で
ありうる。
行することには利点および不利点がある。早くチェックを実行することにより、トランザ
クションの競合の可能性のある部分は、それらの宛先が利用可能でない場合に競合から潜
在的に排除されうる。しかしながら、利用可能性を早く知ることは、システムリソースへ
のかなりの量のオーバーヘッドを生み出しうる。結果として、状況に応じて、所与のアー
ビトレーションサイクル中に利用可能性チェックをより遅く実行するのが、より実際的で
ありうる。
【0088】
トランザクションクラスの選択を含むアービトレーション工程に対して、複数のルール
が、Ｎ、ＮＰ、および、Ｃトランザクションの競合部分の間でアービトレートするために
規定される。これらのルールは、以下を含む。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
－Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い
越しえない。
－Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ－ｐｏｓｔ
ｅｄトランザクション部分を追い越すことができなければならない。
－Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ ｏｒｄｅｒ）モ
ードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換
言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要が
あり、ルールは緩めることができない。
－Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ
Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越す
ことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが
、例外が認められうる。
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を
追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ－ｐｏｓｔｅｄトランザク
ション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、
Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれの
ＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが
、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザ
クション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有
する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須
ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ－ｐｏｓｔｅｄ
トランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有
する場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことを許可される
が、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。
が、Ｎ、ＮＰ、および、Ｃトランザクションの競合部分の間でアービトレートするために
規定される。これらのルールは、以下を含む。
Ｐｏｓｔｅｄ（Ｐ）トランザクションに対して、
－Ｐｏｓｔｅｄトランザクション部分は、別のＰｏｓｔｅｄトランザクション部分を追い
越しえない。
－Ｐｏｓｔｅｄトランザクション部分は、デッドロックを避けるためにＮｏｎ－ｐｏｓｔ
ｅｄトランザクション部分を追い越すことができなければならない。
－Ｐｏｓｔｅｄトランザクション部分は、両方が強順序（ｓｔｒｏｎｇ ｏｒｄｅｒ）モ
ードにある場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことができなければならない。換
言すると、強モードでは、トランザクションは、ルールに従って厳密に実行される必要が
あり、ルールは緩めることができない。
－Ｐｏｓｔｅｄ要求は、任意のトランザクション部分がそれの緩和順序（Ｒｅｌａｘｅｄ
Ｏｒｄｅｒ：ＲＯ）ビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越す
ことを許されるが、追い越しは必須ではない。緩和順序では、一般にルールが守られるが
、例外が認められうる。
Ｎｏｎ－ｐｏｓｔｅｄ（ＮＰ）トランザクションに対して、
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、Ｐｏｓｔｅｄトランザクション部分を
追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、別のＮｏｎ－ｐｏｓｔｅｄトランザク
ション部分を追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、両方が強順序モードにある場合には、
Ｃｏｍｐｌｅｔｉｏｎを追い越してはならない。
－Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分は、任意のトランザクション部分がそれの
ＲＯビットセットを有する場合には、Ｃｏｍｐｌｅｔｉｏｎを追い越すことを許されるが
、必須でない。
Ｃｏｍｐｌｅｔｉｏｎ（Ｃ）トランザクションに対して、
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｐｏｓｔｅｄトランザ
クション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有
する場合には、Ｐｏｓｔｅｄトランザクション部分を追い越すことを許可されるが、必須
ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、両方が強順序モードにある場合には、Ｎｏｎ－ｐｏｓｔｅｄ
トランザクション部分を追い越してはならない。
－Ｃｏｍｐｌｅｔｉｏｎは、任意のトランザクション部分がそれのＲＯビットセットを有
する場合には、Ｎｏｎ－ｐｏｓｔｅｄトランザクション部分を追い越すことを許可される
が、必須ではない。
－Ｃｏｍｐｌｅｔｉｏｎは、別のＣｏｍｐｌｅｔｉｏｎを追い越すことを許可されない。
【0089】
以下の表４は、ＰＣＩ順序付けルールの概要を提供する。（ａ）および（ｂ）の選択肢
のないボックスでは、厳密順序付けルールが従われる必要はない。（ａ）および（ｂ）の
選択肢を有する表のボックスでは、ＲＯビットがリセットされるか設定されるかに依存し
て、それぞれ、厳密順序（ａ）ルールまたは緩和順序（ｂ）ルールのいずれかが適用され
てよい。様々な代替実施形態において、ＲＯビットは、グローバルに、または、パケット
レベルで個々に、設定または再設定されうる。
のないボックスでは、厳密順序付けルールが従われる必要はない。（ａ）および（ｂ）の
選択肢を有する表のボックスでは、ＲＯビットがリセットされるか設定されるかに依存し
て、それぞれ、厳密順序（ａ）ルールまたは緩和順序（ｂ）ルールのいずれかが適用され
てよい。様々な代替実施形態において、ＲＯビットは、グローバルに、または、パケット
レベルで個々に、設定または再設定されうる。
【表4】
【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】
【0169】
工程１２０２において、ＩＰエージェント１４は、その通常モードで動作する。
【0170】
工程１２０４において、低電力、動作不能、状態情報維持モードでＩＰエージェント１
４を動作させる決定がなされる。
４を動作させる決定がなされる。
【0171】
工程１２０６において、リンク８０３は、休止状態にされ、相互接続８０２は、ＩＰエ
ージェント１４の代理として動作するよう構成される。これは、典型的には、（１）任意
の新しいトランザクションがＩＰエージェント１４によって生成されることを許可せず、
（２）任意の未処理のトランザクションが完了するのを待ち、その後、（３）ＩＰエージ
ェント１４を目標とした任意のトランザクションに応答することによって代理として機能
することを含む。例えば、相互接続８０２は、非処理のトランザクションの送信元に除外
メッセージを送信してよく、おそらく、トランザクションの送信側がＩＰエージェント１
４から応答を受信することがないことから起きるハングアップ状況を防ぐ。
ージェント１４の代理として動作するよう構成される。これは、典型的には、（１）任意
の新しいトランザクションがＩＰエージェント１４によって生成されることを許可せず、
（２）任意の未処理のトランザクションが完了するのを待ち、その後、（３）ＩＰエージ
ェント１４を目標とした任意のトランザクションに応答することによって代理として機能
することを含む。例えば、相互接続８０２は、非処理のトランザクションの送信元に除外
メッセージを送信してよく、おそらく、トランザクションの送信側がＩＰエージェント１
４から応答を受信することがないことから起きるハングアップ状況を防ぐ。
【0172】
工程１２０８において、ＩＰエージェント１４のクロック周波数が、該当する場合に下
げられる。
げられる。
【0173】
工程１２１０において、ＩＰエージェント１４の動作電圧が、該当する場合に下げられ
る。しかしながら、電圧は、ＩＰエージェント１４のメモリまたはストレージ要素がそれ
らの状態情報を維持するように適切なままである。
る。しかしながら、電圧は、ＩＰエージェント１４のメモリまたはストレージ要素がそれ
らの状態情報を維持するように適切なままである。
【0174】
決定１２１２において、ＩＰエージェント１４は、通常動作を再開すると決定されるま
では低電力状態のままである。システムコントローラ８０４、ＳｏＣの外部のイベント（
例えば、センサから受信した信号、外部ソースから受信した信号など）、タイマー、ＩＰ
エージェント自体、または、別のＩＰエージェントはすべて、ウェイクアップをトリガし
うる。この決定がなされると、ＩＰエージェントは、通常動作を再開するためのシーケン
スを受ける。
では低電力状態のままである。システムコントローラ８０４、ＳｏＣの外部のイベント（
例えば、センサから受信した信号、外部ソースから受信した信号など）、タイマー、ＩＰ
エージェント自体、または、別のＩＰエージェントはすべて、ウェイクアップをトリガし
うる。この決定がなされると、ＩＰエージェントは、通常動作を再開するためのシーケン
スを受ける。
【0175】
工程１２１４および１２１６において、ＩＰエージェント１４に提供される電圧および
クロック周波数の各々が、該当する場合に上げられる。状態情報が保持されているので、
ＩＰエージェント１４は、工程１２１７で通常動作を再開する。
クロック周波数の各々が、該当する場合に上げられる。状態情報が保持されているので、
ＩＰエージェント１４は、工程１２１７で通常動作を再開する。
【0176】
工程１２１８において、リンク８０３は、休止モードにあり、ＩＰエージェントは、ト
ランザクション準備完了状態になり、相互接続８０２は、長く代理として機能する必要が
あることを通知される。
ランザクション準備完了状態になり、相互接続８０２は、長く代理として機能する必要が
あることを通知される。
【0177】
図１３を参照すると「低電圧、動作不能モード」のためのシーケンスを示すフローチャ
ート１３００が示されている。このシーケンスでは、工程１２０２、１２０６、および、
１２１２は、図１２に関して上述した工程と同じである。したがって、これらの工程につ
いて、ここでは繰り返し論じない。
ート１３００が示されている。このシーケンスでは、工程１２０２、１２０６、および、
１２１２は、図１２に関して上述した工程と同じである。したがって、これらの工程につ
いて、ここでは繰り返し論じない。
【0178】
工程１３０２において、ＩＰエージェント１４を電力ダウンする決定がなされる。その
後、相互接続が代理として構成され（工程１２０６）、工程１３０４において、ＩＰエー
ジェント１４のためのクロックが（該当する場合）完全にオフにされる、および／または
、電圧が（該当する場合）状態情報の失われる程度まで大幅に下げられる。状態情報がな
ければ、工程１２１２において通常動作を再開する決定がなされた場合に、工程１３０６
で、電圧は（該当する場合）上昇され、クロックが（該当する場合）オンにされる。その
後、ＩＰエージェント１４は、図９に関して上述したように、リセット動作を受ける。リ
セットが完了すると、ＩＰエージェント１４は、トランザクション準備完了状態になる。
次いで、システムは、リンクが工程１３１０で休止モードを出るのを待つ。モードを出る
と、ＩＰエージェントは、相互接続８０２上で可視になる。その後、工程１３１２で、相
互接続８０２は、もはやＩＰエージェント１４のための代理として機能しない。
後、相互接続が代理として構成され（工程１２０６）、工程１３０４において、ＩＰエー
ジェント１４のためのクロックが（該当する場合）完全にオフにされる、および／または
、電圧が（該当する場合）状態情報の失われる程度まで大幅に下げられる。状態情報がな
ければ、工程１２１２において通常動作を再開する決定がなされた場合に、工程１３０６
で、電圧は（該当する場合）上昇され、クロックが（該当する場合）オンにされる。その
後、ＩＰエージェント１４は、図９に関して上述したように、リセット動作を受ける。リ
セットが完了すると、ＩＰエージェント１４は、トランザクション準備完了状態になる。
次いで、システムは、リンクが工程１３１０で休止モードを出るのを待つ。モードを出る
と、ＩＰエージェントは、相互接続８０２上で可視になる。その後、工程１３１２で、相
互接続８０２は、もはやＩＰエージェント１４のための代理として機能しない。
【0179】
最後に、電力オフモードについて、シーケンスは、単に下げられるのと対照的に、電力
が完全にオフにされることを除けば、図１３と同じである。それ以外の点では、電力オフ
モードのシーケンスは同じである。このモードにおいて、ＩＰエージェント１４は、実質
的に電力を消費せず、動作不能であり、相互接続８０２は、ＩＰエージェントのために代
理として機能してよい。
が完全にオフにされることを除けば、図１３と同じである。それ以外の点では、電力オフ
モードのシーケンスは同じである。このモードにおいて、ＩＰエージェント１４は、実質
的に電力を消費せず、動作不能であり、相互接続８０２は、ＩＰエージェントのために代
理として機能してよい。
【0180】
図１４を参照すると、リンク８０３を休止状態にするための工程を示すフローチャート
１４００が示されている。
１４００が示されている。
【0181】
最初の工程１４０２において、システムコントローラ８０４は、ＩＰエージェント１４
がリセットされるべきであるかまたは動作不能な節電モードの１つにされるべきである旨
の決定を行う。
がリセットされるべきであるかまたは動作不能な節電モードの１つにされるべきである旨
の決定を行う。
【0182】
工程１４０４において、ＩＰエージェント１４は、トランザクションの生成を停止する
よう命令される。
よう命令される。
【0183】
判定１４０６において、システムは、すべての未処理のトランザクションが完了したか
否かを判定する。すべての未処理のＮｏｎ－ｐｏｓｔｅｄトランザクションについては、
Ｃｏｍｐｌｅｔｉｏｎトランザクションが受信されなければならない（すなわち、読み出
しトランザクションでは、アクセスされたデータが返されなければならず、Ｎｏｎ－ｐｏ
ｓｔｅｄ書き込みトランザクションでは、確認応答が受信されなければならない）。Ｐｏ
ｓｔｅｄトランザクションでは、応答トランザクションは求められない。したがって、Ｐ
ｏｓｔｅｄトランザクションは、ＩＰエージェントによって送信されると、「完了」と見
なされる。
否かを判定する。すべての未処理のＮｏｎ－ｐｏｓｔｅｄトランザクションについては、
Ｃｏｍｐｌｅｔｉｏｎトランザクションが受信されなければならない（すなわち、読み出
しトランザクションでは、アクセスされたデータが返されなければならず、Ｎｏｎ－ｐｏ
ｓｔｅｄ書き込みトランザクションでは、確認応答が受信されなければならない）。Ｐｏ
ｓｔｅｄトランザクションでは、応答トランザクションは求められない。したがって、Ｐ
ｏｓｔｅｄトランザクションは、ＩＰエージェントによって送信されると、「完了」と見
なされる。
【0184】
工程１４０８において、リンク８０３は、すべての未処理のトランザクションが完了し
た時に、休止状態にされる。その後、相互接続８０２は、ＩＰエージェント１４の代理と
して構成される。
た時に、休止状態にされる。その後、相互接続８０２は、ＩＰエージェント１４の代理と
して構成される。
【0185】
工程１４１０において、ＩＰエージェントは、リセットまたは所望の動作不能低電力モ
ードのいずれかにされる準備ができる。
ードのいずれかにされる準備ができる。
【0186】
【0187】
図１５Ａを参照すると、エージェントが開始する「ウェイクアップ」シーケンスを示す
フローチャート１５００が示されている。この実施形態において、ウェイクアップシーケ
ンスは、ＩＰエージェントによって開始されるが、システムコントローラ８０４によって
実施される。
フローチャート１５００が示されている。この実施形態において、ウェイクアップシーケ
ンスは、ＩＰエージェントによって開始されるが、システムコントローラ８０４によって
実施される。
【0188】
工程１５０２において、動作不能状態のＩＰエージェント１４が、ウェイクアップトリ
ガイベントを検出する。ＩＰエージェントは、電力ダウンまたは「オフ」にされうるが、
ウェイクアップトリガが発生した時に検出する能力を維持する意味では、少なくとも部分
的には機能したままであってよい。ウェイクアップトリガは、多くの異なるタイプのイベ
ントを含みうる。例えば、ＩＰエージェント１４を所定の期間の後にウェイクアップさせ
る内部タイマーであってもよいし、ＩＰエージェント１４と通信したい別のデバイスなど
、ＳｏＣ８００の外部のイベントであってもよい。工程１５０４において、ＩＰエージェ
ントは、そのリンク８０３を介して相互接続８０２に「ウェイクアップ」通信を送信する
。再び、リンクは、それに対応するＩＰエージェント１４が動作不能状態にある時には休
止状態であるが、ウェイクアップ信号を相互接続８０２へ送信することができる。
ガイベントを検出する。ＩＰエージェントは、電力ダウンまたは「オフ」にされうるが、
ウェイクアップトリガが発生した時に検出する能力を維持する意味では、少なくとも部分
的には機能したままであってよい。ウェイクアップトリガは、多くの異なるタイプのイベ
ントを含みうる。例えば、ＩＰエージェント１４を所定の期間の後にウェイクアップさせ
る内部タイマーであってもよいし、ＩＰエージェント１４と通信したい別のデバイスなど
、ＳｏＣ８００の外部のイベントであってもよい。工程１５０４において、ＩＰエージェ
ントは、そのリンク８０３を介して相互接続８０２に「ウェイクアップ」通信を送信する
。再び、リンクは、それに対応するＩＰエージェント１４が動作不能状態にある時には休
止状態であるが、ウェイクアップ信号を相互接続８０２へ送信することができる。
【0189】
工程１５０６において、相互接続８０２は、動作不能なＩＰエージェントからのウェイ
クアップ信号を「リッスンする」よう構成される。信号が検出された場合、相互接続８０
２は、システムコントローラ８０４へ通知する。
クアップ信号を「リッスンする」よう構成される。信号が検出された場合、相互接続８０
２は、システムコントローラ８０４へ通知する。
【0190】
工程１５０８において、システムコントローラ８０４は、ＩＰエージェント１４がその
ウェイクアップシーケンスを開始するためのコマンドを相互接続８０２を介して送信して
よい。
ウェイクアップシーケンスを開始するためのコマンドを相互接続８０２を介して送信して
よい。
【0191】
工程１５１０において、ＩＰエージェントは、コマンドに応答して、ウェイクアップシ
ーケンスを開始する。
ーケンスを開始する。
【0192】
上述の実施形態では、ＩＰエージェント１４は、ウェイクアップシーケンスを開始する
ようシステムコントローラに求める。システムコントローラからのウェイクアップコマン
ドに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。した
がって、システムコントローラは、ＩＰエージェントが、動作不能状態を脱して、相互接
続８０２上で可視になると、ＩＰエージェントの状態を知る。
ようシステムコントローラに求める。システムコントローラからのウェイクアップコマン
ドに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。した
がって、システムコントローラは、ＩＰエージェントが、動作不能状態を脱して、相互接
続８０２上で可視になると、ＩＰエージェントの状態を知る。
【0193】
図１５Ｂは、システムコントローラ８０４がＩＰエージェント１４のウェイクアップを
開始する場合のシーケンスを示す。このシーケンスでは、システムコントローラ８０４が
、工程１５０８でＩＰエージェントにウェイクアップコマンドを送信し、それに応答して
、ＩＰエージェントは、工程１５１０で自身のウェイクアップシーケンスを開始する。こ
の実施形態の変形例（図示せず）において、ウェイクアップは、システムコントローラ８
０４を介してＳｏＣ８００の外から開始されてもよい。システムコントローラ８０４がコ
マンドを受信すると、上述の処理が開始される。
開始する場合のシーケンスを示す。このシーケンスでは、システムコントローラ８０４が
、工程１５０８でＩＰエージェントにウェイクアップコマンドを送信し、それに応答して
、ＩＰエージェントは、工程１５１０で自身のウェイクアップシーケンスを開始する。こ
の実施形態の変形例（図示せず）において、ウェイクアップは、システムコントローラ８
０４を介してＳｏＣ８００の外から開始されてもよい。システムコントローラ８０４がコ
マンドを受信すると、上述の処理が開始される。
【0194】
図１５Ｃは、ＩＰエージェント１４のためのウェイクアップコマンドが、ＳｏＣ８００
の外に由来し、システムコントローラ８０４を通して実施される場合のシーケンスを示す
。このシーケンスでは、システムコントローラ８０４は、工程１５１２でコマンドを受信
する。それに応答して、システムコントローラは、工程１５０８でＩＰエージェントにウ
ェイクアップコマンドを送信し、それに応答して、ＩＰエージェントは、工程１５１０で
自身のウェイクアップシーケンスを開始する。ＳｏＣ８００の外からの直接ウェイクアッ
プでは、コマンドは、ハードワイヤ入力を介してＩＰエージェント１４に直接提供される
。それに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。
の外に由来し、システムコントローラ８０４を通して実施される場合のシーケンスを示す
。このシーケンスでは、システムコントローラ８０４は、工程１５１２でコマンドを受信
する。それに応答して、システムコントローラは、工程１５０８でＩＰエージェントにウ
ェイクアップコマンドを送信し、それに応答して、ＩＰエージェントは、工程１５１０で
自身のウェイクアップシーケンスを開始する。ＳｏＣ８００の外からの直接ウェイクアッ
プでは、コマンドは、ハードワイヤ入力を介してＩＰエージェント１４に直接提供される
。それに応答して、ＩＰエージェントは、自身のウェイクアップシーケンスを開始する。
【0195】
図１５Ｄを参照すると、ＩＰエージェントが開始して実施するウェイクアップシーケン
スを示すフローチャート１５２０が示されている。この実施形態では、ウェイクアップ条
件（上述した条件のいずれか、など）が、工程１５２２で発生する。それに応答して、Ｉ
Ｐエージェントは、工程１５２４で自身のウェイクアップシーケンスを開始する。工程１
５２６において、ウェイクアップシーケンスは完了する。その後、工程１５２８において
、ＩＰエージェントは、そのアウェイク状態を、相互接続８０２およびシステムコントロ
ーラ８０４に、直接的にまたは相互接続８０２を介して通知する。
スを示すフローチャート１５２０が示されている。この実施形態では、ウェイクアップ条
件（上述した条件のいずれか、など）が、工程１５２２で発生する。それに応答して、Ｉ
Ｐエージェントは、工程１５２４で自身のウェイクアップシーケンスを開始する。工程１
５２６において、ウェイクアップシーケンスは完了する。その後、工程１５２８において
、ＩＰエージェントは、そのアウェイク状態を、相互接続８０２およびシステムコントロ
ーラ８０４に、直接的にまたは相互接続８０２を介して通知する。
【0196】
上記の例においては、簡単のために、単一のＩＰエージェントを上述の低電力モードの
１つに移行させるシーケンスについて説明した。実際の実施形態においては、ＳｏＣ上の
複数のＩＰエージェント１４が同時に電力ダウンされうる。２以上が同時にまたはほぼ同
時に電力ダウンされる場合、各々が独立して、モードに応じて上述のシーケンスの１つを
受ける。
１つに移行させるシーケンスについて説明した。実際の実施形態においては、ＳｏＣ上の
複数のＩＰエージェント１４が同時に電力ダウンされうる。２以上が同時にまたはほぼ同
時に電力ダウンされる場合、各々が独立して、モードに応じて上述のシーケンスの１つを
受ける。
【0197】
いくつかの実施形態についてのみ詳細に説明したが、ここに提供した本開示の精神や範
囲を逸脱することなしに多くの他の形態で本願を実施できることを理解されたい。したが
って、これらの実施形態は、例示的なものであって、限定的なものではないとみなされ、
本明細書に示した詳細に限定されず、添付の特許請求の範囲および等価物の範囲内で変形
されてもよい。
囲を逸脱することなしに多くの他の形態で本願を実施できることを理解されたい。したが
って、これらの実施形態は、例示的なものであって、限定的なものではないとみなされ、
本明細書に示した詳細に限定されず、添付の特許請求の範囲および等価物の範囲内で変形
されてもよい。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15A】
【図15B】
【図15C】
【図15D】
【手続補正書】
【提出日】2023-11-30
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
システムオンチップ（ＳｏＣ）であって、
複数のＩＰエージェントと、
前記複数のＩＰエージェントと通信する相互接続であって、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態ではない時に、動作するよう構成されている、相互接続と、
を備える、ＳｏＣ。
複数のＩＰエージェントと、
前記複数のＩＰエージェントと通信する相互接続であって、前記複数のＩＰエージェントの内の少なくとも１つの代理として、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態ではない時に、動作するよう構成されている、相互接続と、
を備える、ＳｏＣ。
【請求項2】
請求項１に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、リセットを受けている時、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項3】
請求項１または２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、電力ダウンモード時には、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項4】
請求項１から３のいずれか一項に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、動作不良時には、トランザクション準備完了状態ではない、ＳｏＣ。
【請求項5】
請求項１から４のいずれか一項に記載のＳｏＣであって、前記相互接続は、
前記少なくとも１つのＩＰ機能がトランザクション準備完了状態ではないことを確認し、
トランザクション準備完了状態ではない間に前記少なくとも１つのＩＰエージェントに送信元がトランザクションを送信したか否かを確認し、
前記送信元に例外メッセージを送信して、前記少なくとも１つのＩＰエージェントが利用可能ではないことを前記送信元に通知することによって、前記少なくとも１つのＩＰエージェントの前記代理として機能する、ＳｏＣ。
前記少なくとも１つのＩＰ機能がトランザクション準備完了状態ではないことを確認し、
トランザクション準備完了状態ではない間に前記少なくとも１つのＩＰエージェントに送信元がトランザクションを送信したか否かを確認し、
前記送信元に例外メッセージを送信して、前記少なくとも１つのＩＰエージェントが利用可能ではないことを前記送信元に通知することによって、前記少なくとも１つのＩＰエージェントの前記代理として機能する、ＳｏＣ。
【請求項6】
請求項１から５のいずれか一項に記載のＳｏＣであって、前記送信元は、前記例外メッセージに応答して、送信されたが宛先に配信されていないトランザクションについて、自身の応答手順を受ける、ＳｏＣ。
【請求項7】
請求項１から６のいずれか一項に記載のＳｏＣであって、さらに、前記複数のＩＰエージェントのリセットをそれぞれ開始するためのリセットマネージャを備える、ＳｏＣ。
【請求項8】
請求項１から７のいずれか一項に記載のＳｏＣであって、前記相互接続は、さらに、前記複数のＩＰエージェント各々がそれぞれリセットされる時に、前記複数のＩＰエージェントの各々との個々のネゴシエーションに関与するよう構成されている、ＳｏＣ。
【請求項9】
請求項１から８のいずれか一項に記載のＳｏＣであって、前記複数のＩＰエージェントの内の２以上のリセット後に、前記２以上のＩＰエージェントの各々は、それぞれ、個々にリセットし、他のＩＰエージェントから独立してトランザクション準備完了状態になるよう構成されている、ＳｏＣ。
【請求項10】
請求項９に記載のＳｏＣであって、前記２以上のＩＰエージェントの各々は、前記２以上のＩＰエージェントが同時にトランザクション準備完了状態になる必要なしに、自身のタイムスケジュールで独立的にトランザクション準備完了状態になる、ＳｏＣ。
【請求項11】
請求項１から１０のいずれか一項に記載のＳｏＣであって、さらに、システムコントローラを備え、少なくとも１つのＩＰエージェントが、トランザクション準備完了状態になった時に、前記システムコントローラにとって可視になる、ＳｏＣ。
【請求項12】
システムオンチップ（ＳｏＣ）であって、
複数のＩＰエージェントと、
相互接続と、
前記複数のＩＰエージェントを前記相互接続と接続する１以上のリンクと、
前記複数のＩＰエージェントの少なくとも１つを選択的に低電力状態にすることによって、前記ＳｏＣによる電力消費を少なくとも部分的に管理するための電力マネージャと、
を備え、
前記相互接続は、（ａ）前記低電力状態にあり、かつ、（ｂ）トランザクションの処理に利用できない時に、前記少なくとも１つのＩＰエージェントの代理として機能し、前記相互接続は、前記少なくとも１つのＩＰエージェントに前記トランザクションを送信しようとする送信元へ例外メッセージを提供することによって前記代理として機能する、ＳｏＣ。
複数のＩＰエージェントと、
相互接続と、
前記複数のＩＰエージェントを前記相互接続と接続する１以上のリンクと、
前記複数のＩＰエージェントの少なくとも１つを選択的に低電力状態にすることによって、前記ＳｏＣによる電力消費を少なくとも部分的に管理するための電力マネージャと、
を備え、
前記相互接続は、（ａ）前記低電力状態にあり、かつ、（ｂ）トランザクションの処理に利用できない時に、前記少なくとも１つのＩＰエージェントの代理として機能し、前記相互接続は、前記少なくとも１つのＩＰエージェントに前記トランザクションを送信しようとする送信元へ例外メッセージを提供することによって前記代理として機能する、ＳｏＣ。
【請求項13】
請求項１２に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力状態に入る時に、自身の低電力シーケンスを実施する、ＳｏＣ。
【請求項14】
請求項１２または１３のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントがトランザクション準備完了状態のままである低電力モードを含む、ＳｏＣ。
【請求項15】
請求項１４に記載のＳｏＣであって、前記相互接続は、前記少なくとも１つのＩＰエージェントが前記低電力状態にあり、かつ、トランザクション準備完了状態のままである場合には、代理として機能せず、前記少なくとも１つのＩＰエージェントのためのクロック周波数および／または電圧の低減に対応するために、前記１以上のリンクの内の１つの設定を調整する、ＳｏＣ。
【請求項16】
請求項１２から１５のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントがもはやトランザクション準備完了状態ではない低電力モードを含む、ＳｏＣ。
【請求項17】
請求項１６に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情報を保持する、ＳｏＣ。
【請求項18】
請求項１６に記載のＳｏＣであって、前記少なくとも１つのＩＰエージェントは、前記低電力モードにあり、かつ、もはやトランザクション準備完了状態ではない時に、状態情報を保持しない、ＳｏＣ。
【請求項19】
請求項１２から１８のいずれか一項に記載のＳｏＣであって、前記低電力状態は、最小限の電力が前記少なくとも１つのＩＰエージェントに供給される電力オフモードを含む、ＳｏＣ。
【請求項20】
請求項１２から１９のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げることによって実施される、ＳｏＣ。
【請求項21】
請求項１２から２０のいずれか一項に記載のＳｏＣであって、前記低電力状態は、前記少なくとも１つのＩＰエージェントによって利用される電圧を下げることによって実行される、ＳｏＣ。
【請求項22】
請求項１２から２１のいずれか一項に記載のＳｏＣであって、前記低電力状態は、
前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げ、
前記動作クロック周波数を下げた後に、前記少なくとも１つのＩＰエージェントによって利用される供給電圧を下げることによって実行される、ＳｏＣ。
前記少なくとも１つのＩＰエージェントの動作クロック周波数を下げ、
前記動作クロック周波数を下げた後に、前記少なくとも１つのＩＰエージェントによって利用される供給電圧を下げることによって実行される、ＳｏＣ。
【外国語明細書】