ホーム > 特許ランキング > インテル・コーポレーション
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025009718
(43)【公開日】2025-01-20
(54)【発明の名称】ストリーミングファブリックインタフェース
(51)【国際特許分類】
G06F 13/10 20060101AFI20250109BHJP
G06F 13/42 20060101ALI20250109BHJP
G06F 13/36 20060101ALI20250109BHJP
G06F 13/12 20060101ALI20250109BHJP
【ＦＩ】
G06F13/10 310E
G06F13/42 310
G06F13/36 530B
G06F13/12 330A
【審査請求】未請求
【請求項の数】25
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023206569
(22)【出願日】2023-12-07
(31)【優先権主張番号】18/345,208
(32)【優先日】2023-06-30
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】591003943
【氏名又は名称】インテル・コーポレーション
(74)【代理人】
【識別番号】110000877
【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所
(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】
前記インタフェースは：
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、レーンの前記第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるデータチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される、請求項２２から２４のいずれか一項に記載の装置。
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、レーンの前記第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるデータチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される、請求項２２から２４のいずれか一項に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、コンピューティングシステム、特に（排他的でないが）ポイントツーポイントインターコネクトに関する。
【背景技術】
【0002】
半導体プロセッシング及びロジック設計における進歩は、集積回路デバイスに存在し得るロジック量の増加を可能にするに至った。当然の結果として、コンピュータシステム構成は、システム内の単一又は複数の集積回路から、個々の集積回路上にある複数のコア、複数のハードウェアスレッド、及び複数の論理プロセッサ、並びにそのようなプロセッサと統合された他のインタフェースへと進化した。プロセッサ又は集積回路は、典型的には単一の物理プロセッサダイを備え、プロセッサダイは、任意の数のコア、ハードウェアスレッド、論理プロセッサ、インタフェース、メモリ、コントローラハブなどを含んでよい。
【0003】
より小さなパッケージで、より大きな処理能力に適合できる、より高い能力の結果として、より小さなコンピューティングデバイスが人気を高めてきた。スマートフォン、タブレット、極薄ノートブック、及び他のユーザ機器が、飛躍的に成長してきた。しかしながら、これらのより小さなデバイスは、データストレージ及びフォームファクタを超過する複雑な処理の両方について、サーバに依存する。結果として、高性能コンピューティング市場（すなわち、サーバ空間）におけるニーズも増大した。例えば、現在のサーバにおいて、コンピューティング能力を増大させるには通常、複数のコアを持つシングルプロセッサだけでなく、複数の物理プロセッサ（複数のソケットとも称される）が存在する。しかしながら、コンピューティングシステム内のデバイス数と共に処理能力が増大するにつれ、ソケットと他のデバイス間の通信がより重要なものになっている。
【0004】
実際、インターコネクトは、電気通信を主に処理してきた従来型のマルチドロップバスから、高速通信を容易にする本格的なインターコネクトアーキテクチャへと成長した。残念ながら、はるかに使用効率の高い将来のプロセッサへのニーズがあり、対応する要求は、既存のインターコネクトアーキテクチャの機能に対しある。
【図面の簡単な説明】
【0005】
【図1】システムオンチップ（ＳｏＣ）デバイスの例示的な実施形態を示す簡易ブロックダイアグラムである。
【0006】
【図2】ストリーミングファブリックインタフェースの簡易ブロックダイアグラムである。
【0007】
【図3】別の例示的なストリーミングファブリックインタフェースの簡易ブロックダイアグラムである。
【0008】
【図4】例示的なコンピュートエクスプレスリンク（ＣＸＬ）トポロジーを示す簡易ブロックダイアグラムである。
【0009】
【図5】例示的なストリーミングファブリックインタフェースのチャネルの簡易ブロックダイアグラムである。
【0010】
【図6】例示的な受信機バッファを示す簡易ブロックダイアグラムである。
【0011】
【図7】ストリーミングファブリックインタフェースのヘッダチャネルについてのメタデータにおける例示的なフィールドの表現である。
【0012】
【図8】例示的なストリーミングファブリックインタフェースのヘッダチャネル上の例示的なデータフローを示すタイミングダイアグラムである。
【0013】
【図9】例示的なストリーミングファブリックインタフェースのデータチャネル上の例示的なデータフローを示すタイミングダイアグラムである。
【0014】
【図10】例示的なフレキシブルオンダイファブリックインタフェースについての例示的な初期化状態機械を示すダイアグラムである。
【0015】
【図11】例示的なフレキシブルオンダイファブリックインタフェースの初期化を示すタイミングダイアグラムである。
【0016】
【図12】例示的なフレキシブルオンダイファブリックインタフェースにおける切断フローの第１の例を示すタイミングダイアグラムである。
【0017】
【図13】例示的なフレキシブルオンダイファブリックインタフェースにおける切断フローの第２の例を示すタイミングダイアグラムである。
【0018】
【図14】例示的なコンピューティングシステムの簡易ブロックダイアグラムである。
【0019】
【図15A】フリットモードパケットのヘッダの例示的な部分を示す。
【図15B】フリットモードパケットのヘッダの例示的な部分を示す。
【図15C】フリットモードパケットのヘッダの例示的な部分を示す。
【図15D】フリットモードパケットのヘッダの例示的な部分を示す。
【0020】
【図16】例示的なパケットヘッダを示す。
【0021】
【図17】クレジットガスケットを含む例示的なコンピューティングシステムを示す。
【0022】
【図18】クレジットガスケットの例示的な使用を示すタイミングダイアグラムである。
【0023】
【0024】
【図20】例示的なクレジットガスケットのロジックを示すダイアグラムである。
【0025】
【図21】クレジットガスケットの例示的な使用を示すタイミングダイアグラムである。
【0026】
【0027】
【図23】バッファレスアービタを含む例示的なコンピューティングシステムの簡易ブロックダイアグラムである。
【0028】
【図24A】コンピューティングシステムにおけるアービタの例示的な使用を示すタイミングダイアグラムである。
【図24B】コンピューティングシステムにおけるアービタの例示的な使用を示すタイミングダイアグラムである。
【図24C】コンピューティングシステムにおけるアービタの例示的な使用を示すタイミングダイアグラムである。
【図24D】コンピューティングシステムにおけるアービタの例示的な使用を示すタイミングダイアグラムである。
【0029】
【図25】マルチコアプロセッサを含むコンピューティングシステムについてのブロックダイアグラムの実施形態を示す図である。
【0030】
【図26】コンピューティングシステムのためのブロックダイアグラムの別の実施形態を示す。
【発明を実施するための形態】
【0031】
以下の説明には、本開示の深い理解を与えるべく、多数の具体的な詳細が記載されている。例えば、複数の特定のタイプのプロセッサ及びシステム構成、特定のハードウェア構造、特定の設計上及びミクロ設計上の細部、特定のレジスタ構成、特定の命令タイプ、特定のシステムコンポーネント、特定の寸法／高さ、特定のプロセッサパイプライン段階、及び動作等の複数の例である。しかしながら、当業者にとって、これらの具体的な詳細は、本開示の実施形態を実施するために採用される必要がないことは明らかであろう。他の複数の例において、複数の特定及び代替的なプロセッサアーキテクチャ、記載された複数のアルゴリズム用の複数の特定のロジック回路／コード、特定のファームウェアコード、特定のインターコネクト動作、複数の特定のロジック構成、複数の特定の製造技術及び材料、複数の特定のコンパイラ実装、コード内の複数のアルゴリズムについての特定の表現、特定のパワーダウン及びゲーティング技術／ロジック並びにコンピュータシステムの他の特定の動作の詳細のような、複数の周知コンポーネント又は方法は、本開示を不必要に不明瞭にするのを回避すべく詳細には記載されていない。
【0032】
以下の実施形態は、コンピューティングプラットフォーム又はマイクロプロセッサなどの特定の集積回路における効率的な高速データ送信及び構成可能性を参照して説明され得るが、他の実施形態が他のタイプの集積回路及びロジックデバイスに適用可能である。本明細書で説明する実施形態の同様の技術及び教示内容を、より良いエネルギー効率及びエネルギー節約から、やはり恩恵を受け得る他の種類の回路又は半導体デバイスに適用することができる。例えば、開示された実施形態は、サーバ、ブレード、デスクトップコンピュータシステム、システムオンチップ（ＳｏＣ）デバイス、ハンドヘルドデバイス、タブレット、セットトップボックス、車載コンピューティングシステム、コンピュータビジョンシステム、ゲーミングシステム、機械学習システム、及び組み込み用途として具体化されるコンピューティングシステムに適用され得る。下の説明において容易に明らかになるように、本明細書において説明される方法、装置、及びシステムの実施形態は（ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせのいずれに関連する場合でも）、高性能コンピュータインターコネクト及びそれらのそれぞれのシステムの発展に有益である。
【0033】
コンピューティングシステムが進むにつれ、その中におけるコンポーネントはより複雑になっている。結果として、最適なコンポーネント動作のための帯域幅要件が満たされることを保証すべく、コンポーネント間の連結及び通信を行うためのインターコネクトアーキテクチャも複雑性が増している。更に、異なる複数の市場セグメントは市場ニーズに適合すべく、複数のインターコネクトアーキテクチャの異なる態様を要求する。例えば、複数のサーバがより高性能を要求する一方で、モバイルエコシステムは場合によっては、省電力化のために全体的な性能を犠牲にしてしまう可能性がある。その上、多くのファブリックの唯一の目的は、最大の省電力化を行いながら、最高の可能な性能を提供することである。以下に説明される複数のインターコネクトは、本明細書に記載される解決手段の態様から潜在的に利益を享受するであろう。
【0034】
１つの例示的なインターコネクトファブリックアーキテクチャ、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）エクスプレス（ＰＣＩｅ）アーキテクチャを含む。ＰＣＩｅの主目的は、複数の異なるベンダの複数のコンポーネント及びデバイスをクライアント（デスクトップとモバイル）、サーバ（標準及びエンタープライズ）、及び組み込み通信デバイス等、複数の市場セグメントにわたるオープンアーキテクチャで相互運用できるようにすることである。ＰＣＩ Ｅｘｐｒｅｓｓは、様々な将来の複数のコンピューティング及び通信プラットフォームのために定義された高性能で、汎用性のあるＩ／Ｏインターコネクトである。その利用モデル、ロード‐ストアアーキテクチャ、及びソフトウェアインタフェースのようないくつかのＰＣＩ属性が、その改訂版を通して維持されているが、これに対し、以前のパラレルバス実装は、高度に拡張可能な完全シリアルインタフェースによって置き換えられた。ＰＣＩ Ｅｘｐｒｅｓｓのより最近のバージョンでは、性能と複数の特徴に係る複数の新レベルを供給すべく、ポイントツーポイントインターコネクト、スイッチベースの技術、及びパケット化されたプロトコルにおける複数の利点を活用している。電力管理、サービス品質（ＱｏＳ）、ホットプラグ／ホットスワップサポート、データ整合性、及びエラー処理は、ＰＣＩ Ｅｘｐｒｅｓｓによってサポートされる高度な複数の特徴のうちいくつかである。
【0035】
ファブリックをプロトコルエージェントに結合するための従来のストリーミングインタフェースは概して、専用インタフェース（例えば、インテル（登録商標）オンチップシステムファブリック（ＩＯＳＦ（登録商標）））、コヒーレント又は順序付けられていないプロトコルのために開発されたインタフェース、及び、モダンなプロトコル及びアーキテクチャにおける進化するデータレートに対処するようにスケーリングすることに対して適応しにくい他のインタフェースを含み得る。例えば、専用インタフェースは、インタフェースの標準化を防止する、又は、次世代の帯域幅へのスケーリングに失敗するカスタム又はユースケース固有情報又は特徴を搬送し得る。一方、他の従来のインタフェースは、より一般的な方式で、例えば、パケットを搬送するためのデータバスとして定義され得る。しかしながら、特に、データレートが増加し、クロックサイクルあたり、より多くのパケットを処理できるようになるにつれて、従来のバス定義及びインタフェースは、特に、複数のフロー制御クラス又は仮想チャネルの存在下において、受信機デコード複雑性をもたらし得る。一例として、任意のチャネル又はフロー制御の４つの（又は更に多くの）パケットが所与のクロックサイクルで潜在的に到着し得、かつ、これらが共有バッファにアクセスしている場合、対応する４つの（又はより多くの）論理書き込みポートが受信機においてプロビジョニングされる必要があり得、過剰な表面積が、そのようなロジック（及びバッファ）を提供することに割り当てられるという結果となる。いくつかの事例において、従来のインタフェースは、単純にインタフェースの複数のコピーをスタンプすることによって（例えば、各フロー制御クラスあたり１）、（異なるフロー制御クラスの）サイクルあたり複数のパケットのユースケースに対処し、高いピンカウントをもたらす。追加的に、従来のストリーミングインタフェースは、同一の物理ワイヤ上で互いに続くヘッダ及びデータパケットを有し、レイテンシ最適化の可能性を限定する。いくつかの従来のインタフェースは、他の例示的な欠点の中でも特に、クレジットフローのために有効でフレキシブルな機構を提供することに失敗する。
【0036】
いくつかの実装において、改善されたスケーラブルなストリーミングインタフェースが、デバイス上のエージェントロジック及びファブリックの間で、例えば、プロトコル層、及び、ファブリックに結合された他のデバイス（例えば、ＣＰＵ、エンドポイントデバイス、スイッチなど）の間などで定義され得る。ストリーミングインタフェースは、他のロード／ストアプロトコルの中でも特に、ＰＣＩｅ、コンピュートエクスプレスリンク（ＣＸＬ）（例えば、ＣＸＬ．ｉｏ）などのロード／ストアプロトコルをサポートし得る。改善されたストリーミングインタフェースは、実装中に大きいチップ面積及びレイテンシの利点を可能にするためのインタフェース規則及びインタフェースのチャネルを定義し得、一方、他の例の中でも特に、ＰＣＩｅ Ｇｅｎ５における３２．０ＧＴ／ｓ、又は、ＰＣＩｅ Ｇｅｎ６及びＣＸＬ３．０から開始する６４．０ＧＴ／ｓデータレート以降への移行など、プロトコルがより高い速度に近づくにつれて、より一層重要となるであろう電力効率的な帯域幅スケーリングの利点を提供する。そのようなインタフェースは、ピンカウントと受信機デコード複雑性との間の最良のバランスを最適化し得る。いくつかの実装において、本明細書において論じられる改善されたストリーミングインタフェースは、受信機バッファ上の少ない数の論理書き込みポートを可能にし得、ここで、受信機バッファは、複数の仮想チャネル及びフロー制御クラスの間で共有される。更に、改善されたストリーミングインタフェースは、パケットのヘッダ及びデータを独立の物理チャネル（例えば、ヘッダチャネル及びデータチャネル）に分岐させ得、それにより、データがなおストリーミングされているときに受信機がヘッダの処理を開始することを可能にし、それにより、全体のレイテンシ及びバッファサイズ及び複雑性を低減することを助ける。更に、本明細書において論じられる改善されたストリーミングインタフェースは、ＩＰブロックのエコシステムが、従来の専用インタフェースではなく、スケーラブルで標準化されたインタフェースを採用しそれに発展することを可能にするために標準化され得、本明細書において論じられるものなどの他の例示的特徴及び利点の中でも特に、相互運用性のより多くの選択肢を可能にする。
【0037】
図１の簡易ブロックダイアグラム１００を参照すると、システムオンチップ（ＳｏＣ）デバイス１０５の単純化した例が示される。ＳｏＣが、コンピュータの複数のコンポーネント又はコンピューティングブロック（又は知的財産（ＩＰ）ブロック）を組み込む集積回路として実装され得る。そのようなブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）は、１又は複数のＣＰＵコンポーネント１１０、１１５、１２０、１２５（例えば、マイクロプロセッサ又はマイクロコントローラ）、特定用途向けプロセッサ１３０、１３５（例えば、グラフィックスプロセッシングユニット（ＧＰＵ）、イメージ信号プロセッサ（ＩＳＰ）、テンソルプロセッサユニット、アクセラレータデバイスなど）、メモリコンポーネント、入出力（Ｉ／Ｏ）ポート、セカンダリストレージブロック、及び、シリコンダイなどの単一ダイ又は基板上の他のコンピュートブロックなどのコンポーネントを含み得る。
【0038】
例示的なＳｏＣ１０５のコンピュートブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）は、ＳｏＣファブリック（例えば１５０）によってインターコネクトされ得る。ファブリック１５０は、コンピュートブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）の間の通信を容易にする１又は複数のＩＰブロックのセットを使用してそれ自体実装され得る。いくつかの実装において、ファブリック１５０は、１又は複数の回路ブロックで実装されたＮＯＣなど、ネットワークオンチップ（ＮＯＣ）として実装され得る。
【0039】
様々なブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）による通信は、ブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）上に提供されるプロトコルエージェント（例えば、１６０ａ～ｈ）を通じて促進され得る。各エージェント（例えば、１６０ａ～ｈ）は、対応するコンピュートブロックがシステムにおける他のコンピュートブロックと通信するための１又は複数のインターコネクトプロトコル（例えば、ＰＣＩｅ、コンピュートエクスプレスリンク（ＣＸＬ）、Ｇｅｎ－Ｚ、ＯｐｅｎＣＡＰＩ、インダイインタフェース、アクセラレータのためのキャッシュコヒーレントインターコネクト（ＣＣＩＸ）、ＵｌｔｒａＰａｔｈインターコネクト（ＵＰＩ）など）の層のすべて又はサブセットを実装するためのロジック（例えば、ハードウェア回路、ファームウェア及び／又はソフトウェアにおいて実装される）を含み得る。本明細書において論じられるように、エージェントは、それぞれのインタフェースを介してファブリック１５０に結合し得る。そのようなエージェントは従来、プロプライエタリなワイヤインタフェースを介してファブリックに結合され得るが、１又は複数のエージェント（例えば、１６０ａ～ｈ）は、構成可能でフレキシブルなオンダイワイヤインタフェースのそれぞれのインスタンスを利用し得、これらは、ＳｏＣ１０５の複数の異なるエージェントの複数の異なるプロトコルをサポートするためにデプロイされ得る。他の事例において、エージェント（例えば、１６０ａ～ｈ）間のインタフェースは、非コヒーレント及び／又はロード／ストアストリーミングプロトコルをサポートするためのものであり得、対応するストリーミングファブリックインタフェースが定義され、他の例示的な実装の中でも特に、ブロック（例えば、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５）及びファブリック１５０上で実装され得る。
【0040】
上で紹介されたように、改善されたストリーミングファブリックインタフェースアーキテクチャ（ＳＦＩ）が、システムのコンポーネント（例えば、システムのファブリックを実装するＩＰブロック及びコンポーネント）において提供され、エージェント及びファブリックの間でロード／ストアプロトコル（例えば、ＰＣＩｅ、ＣＸＬ．ｉｏ）をマッピングし得る。ＳＦＩインタフェースは、ロード／ストアプロトコルの高い帯域幅要件（そのようなプロトコルについての新しい次世代速度を含む）を維持し得るスケーラブルなストリーミングインタフェースを提供し得る。ＳＦＩインタフェースは、そのような高いデータレートを送信するとき、送信側及び受信側の両方における容易な実装を可能にし得る。追加的に、ＳＦＩインタフェースを実装するロジックは、（例えば、インタフェースによってサポートされるプロトコルにおいて定義されるものを超える）インタフェース上の通信のための規則を具体化、実現、及び施行し、他の例示的な特長の中でも特に、受信機上の読み取り／書き込みポートのコンテクストにおけるストレージオーバヘッドを大きく簡略化し得る。
【0041】
ＳＦＩインタフェースが、（例えばルートコンプレックスを通じた）ホストＣＰＵのコンテクスト、又は、デバイスエンドポイントのコンテクストの両方において採用され得る。両方の場合において、ＳＦＩは、異なるプロセッシングエンティティの間のプロトコル層（トランザクション層）固有情報を搬送するために機能する。一例として、デバイス側において、ＳＦＩは、ＰＣＩｅコントローラ及びアプリケーション層（例えば、コントローラ及びファブリックの間のファブリック又はガスケット層）の間でインタフェースするために使用され得る。同様に、ホスト側では、ＳＦＩは、ＰＣＩｅルートポート及びＣＰＵファブリックの間をインタフェースするために使用され得る。構成可能なパラメータがＳＦＩインタフェースにおいて定義され得、インタフェースのインスタンスが十分に広くパラメータ化されること、及び、サポートされるプロトコル及びシステムユースケースに従って、単一の伝送で複数のパケットを搬送することを可能にする。所与のＳＦＩインタフェース上で、データ伝送は単方向であり得る。したがって、いくつかの実装において、通信するブロック間の双方向データ伝送を利用して実装を促進するために、ＳＦＩインタフェースインスタンスのペアが提供され得る（各方向に１つ）。したがって、本明細書における例の多くは、ＳＦＩインタフェースの単一インスタンスについての送信機（ＴＸ）及び受信機（ＲＸ）ペアを論じる。
【0042】
ＳＦＩを仲介インタフェースとして使用して、異なる構成が有効化され得る。例えば、ＳＦＩインタフェースは、インタフェースの送信機及び受信機のプロトコル又は用途固有の役割に関して想定しないことがあり得る。むしろ、ＳＦＩインタフェースは単純に、高帯域幅パケット伝送のための機構及び規則を提供し得る。例えば、図２は、（例えばエージェントの）コントローラ２１０を（例えば、ファブリックを通じて実装される）アプリケーション層２１５に、２つのＳＦＩインタフェースインスタンス２０５ａ、２０５ｂを介して結合する例示的な実装を示す簡易ブロックダイアグラム２００である。コントローラ２１０は、特定のインターコネクトプロトコル（例えば、ＰＣＩｅ）に従ってリンク２２０を確立し、リンク２２０を通じて初期化、トレーニング、及び通信に参加するためのプロトコル回路又は他のロジックを含み得る。図２の例は、ＰＣＩｅ用途におけるＳＦＩの例示的ユースケースを表し得る。ＳＦＩインスタンス２０５ａは、ＰＣＩｅコントローラ２１０を送信機として、アプリケーション層要素２１５を受信機として扱い得る。したがって、アプリケーション層要素２１５は、フロー制御クレジット（ＳＦＩインタフェース２０５ａ）のチャネルについての共有クレジットを含む）を維持するのに使用するためのＳＦＩインタフェース２０５ａについての受信機バッファを含み得る。同様に、ＳＦＩインタフェース２０５ｂは、アプリケーション層要素２１５を送信機とみなし、ＰＣＩｅコントローラ２１０を受信機とみなし得る（そして、コントローラ２１０は、インタフェース２０５ｂと共に使用するための対応する受信機キュー又はバッファ２２５を含み得る）。
【0043】
ＳＦＩのいくつかの実装は、ＰＣＩｅベースのプロトコルのセマンティクス及びヘッダフォーマットを利用し得るが、ＳＦＩは、サポートされるＰＣＩｅベースのプロトコルに限定されない。更に、ＳＦＩは、新しいプロトコル定義を含まない。ＳＦＩセマンティクスは、様々な異なるプロトコルをサポートするために使用され得る。ただし、プロトコルは、他の例示的特徴の中でも特に、ＳＦＩが提供するフロー制御（ＦＣ）及び仮想チャネル（ＶＣ）セマンティクスにマッピング又は適応され得ることを条件とする。例えば、ＳＦＩは、（下でより詳細に論じられるものなどの）受信機キューについての０又は複数の共有クレジットプールのアドバタイズメントをサポートする。
【0044】
図３を参照すると、ＳＦＩインタフェースを利用する従来のルートコンプレックススタックを示す、簡易ブロックダイアグラム３００が示される。例えば、ＳＦＩインタフェース２０５ａ、２０５ｂは、プロトコルスタックロジック（例えば３０５、３１０）を非コヒーレント－コヒーレントプロトコルコンバータ３１５（例えば、システムのプロトコルスタックロジック及びインターコネクトファブリック２１５の間に位置し得る）に結合するために使用され得る。例えば、プロトコルスタックロジックは、特定の非コヒーレント、ロード／ストアインターコネクトプロトコル（例えば、ＰＣＩｅ、ＣＸＬ．ｉｏなど）についてのエージェント又はコントローラとして具体化され得、物理層ロジック及びリンク層ロジックを含むより低いレベルの層のロジック３０５を含み得る（例えば、回路において実装する）。トランザクション層ロジック３１０も提供され得、ＳＦＩインタフェース（例えば、２０５ａ、２０５ｂ）を通じてコンバータ３１５とインタフェースする層であり得る。バッファ２２５（例えば、Ｉ／Ｏ／キュー（ＩＯＱ））バッファが提供され、デバイス及びホストの間の物理リンクレイテンシを隠すために使用され得る。そのようなバッファ２２５の深度は典型的には浅く、必要な論理書き込みポートの数は、１つのクロックサイクルにおいてリンクから利用可能な同時パケットの数である。例えば、一例において、ＰＣＩｅ Ｇｅｎ５速度（３２ＧＴ／ｓ）については、最大４つのパケットが１つの１ＧＨｚサイクルにおいて到着し得るので、これらのパケットが潜在的に異なるフロー制御クラス及び／又は仮想チャネルであり得ると仮定すると、これらのパケットを同時に処理するべく、４つの論理ポートがそのような例において必要となる。一方、ファブリック側バッファ２３０（例えば、ＰｒｏｃＱバッファ）は、（例えば、オーナシップリクエストをフェッチしデータをコヒーレンシドメインにコミットするレイテンシに変換する、インバウンド書き込みについての）ＣＰＵファブリックレイテンシを隠すために使用されるディープバッファとして実装され得る。これらは、１又は複数の書き込みポートを含み得る。スプリットキューを用いた実装において、ＳＦＩセマンティクスは、（例えば、ＰｒｏｃＱ側で、トランザクションの「バッチ処理」を実行するために）更なる最適化を可能にし得る。実際、ＳＦＩセマンティクスは、様々なシステム構成におけるバッファ実装を改善するように適用され、他の例示的な特長の中でも特に、帯域幅スケーリング機能との、受信機の複雑性のバランスを提供する。
【0045】
例示的な改善されＳＦＩインタフェースにおいて採用される例示的な特徴の中でも特に、受信機デコードは簡略化され得、（例えば、４Ｂほどの小ささから、４ＫＢ（又はより大きい）までの大きさまで）広い範囲のデータペイロードをサポートするためにスケーリングするインタフェースを有する。改善されたストリーミングインタフェースは、複数のパケットが同じサイクルにおいて送達されることを可能にし得、セマンティクス及び順序付けの共通セット（例えば、ＰＣＩｅベースなど）を維持しながら、様々なペイロードサイズにわたるスケーラブルなインタフェースを可能にする。構成可能なパラメータは、受信機における論理書き込みポートの数（例えば１又は２）を含み得、これは、クロックサイクルにおいて送信される異なるパケット又はヘッダの数を、フロー制御クラス及び／又は仮想チャネルの対応する数の使用に制限するインタフェースについての規則を定義することによってサポートされ得る。受信機における論理書き込みポートの数を低減することによって、著しい面積及び複雑性を削減し得る。追加的に、上に留意されたように、改善されたストリーミングインタフェースは、レイテンシを改善する（例えば、ＣＰＵホストの場合、オーナシップリクエストレイテンシを、入ってくるデータストリームに重ねることを助ける）ために、データがストリーミングされながら、（例えば、専用ヘッダチャネルを通じて受信されるヘッダの）受信機におけるヘッダ処理を開始することを可能にし得る。
【0046】
コンピュートエクスプレスリンク又はＣＸＬは、コヒーレンシプロトコル（ＣＸＬ．ｃａｃｈｅ）、メモリアクセスプロトコル（ＣＸＬ．ｍｅｍ）、及びＩ／Ｏプロトコル（ＣＸＬ．ｉｏ）の動的プロトコル多重化（又はｍｕｘｉｎｇ）をサポートする、低レイテンシ、高帯域幅のディスクリート又はオンパッケージリンクである。ＣＸＬ．ｃａｃｈｅは、ホストメモリのデバイスキャッシングをサポートするエージェントコヒーレンシプロトコルであり、ＣＸＬ．ｍｅｍは、デバイスアタッチメモリをサポートするメモリアクセスプロトコルであり、ＣＸＬ．ｉｏは、アクセラレータサポートについての強化を有するＰＣＩｅベース非コヒーレントＩ／Ｏプロトコルである。ＣＸＬはそれにより、アクセラレータデバイスなど広い範囲のデバイスをサポートするために、プロトコルの豊富なセットを提供することが意図される。特定のアクセラレータ使用モデルに応じて、ＣＸＬプロトコル（ＣＸＬ．ｉｏ、ＣＸＬ．ｍｅｍ、ＣＸＬ．ｃａｃｈｅ）のすべて、又は、サブセットのみが、システムにアクセスするために、対応するコンピューティングブロック又はデバイス（例えば、アクセラレータ）についての低レイテンシ、高帯域幅パスを提供するように有効化され得る。
【0047】
上に記載されたように、いくつかの実装において、ＣＸＬ．ｉｏプロトコルを実装するために利用されるエージェントは、本明細書において説明されるものなどのＳＦＩインタフェースを利用してシステムファブリックに結合し得る。例えば、図４を参照すると、例示的なＣＸＬエージェント、及び、そのようなエージェントに対するファブリックの結合を示す、簡易ブロックダイアグラム４００が示される。図４は、ＣＸＬリンク４１５をサポートするポートについての例示的なシステムトポロジーを示す。例えば、ＣＸＬリンク４１５は、ＣＰＵホストデバイス４０５を別のデバイス４１０（例えば、メモリデバイス又はアクセラレータデバイス）に結合し得る。（デバイス４０５、４１０上の）各エージェントは、ＣＸＬのサブプロトコル（例えば、ＣＸＬ．ｉｏ、ＣＸＬ．ｍｅｍ、ＣＸＬ．ｃａｃｈｅ）の各々をサポートするためのリンク層ロジック（例えば、４２０ａ～ｂ、４２５ａ～ｂ）を含み得る。ＣＸＬ．ｍｅｍ及びＣＸＬ．ｃａｃｈｅの場合、共通のコントローラ（例えば、４２５ａ～ｂ）が利用され得る。ＣＸＬ．ｉｏについては、コヒーレントなＣＸＬ．ｍｅｍ及びＣＸＬ．ｃａｃｈｅのプロトコルとは別個であるコントローラ（４２０ａ～ｂ）が提供され得る。プロトコル多重化は、Ｆｌｅｘ Ｂｕｓ（登録商標）物理層（例えば、４３０ａ～ｂ）とインタフェースするＣＸＬ調停／多重化ロジック（例えば、ハードウェア回路において実装される４２５ａ～ｂ）を通じて促進され得る。Ｆｌｅｘ Ｂｕｓは、ＰＣＩｅ又はＣＸＬのいずれかをサポートするよう静的に構成されるフレキシブルな高速ポートとして実装され得る。Ｆｌｅｘ Ｂｕｓは、高帯域幅オフパッケージリンクを通じて送信されるＰＣＩｅプロトコル又はＣＸＬプロトコルのいずれかを可能にする。Ｆｌｅｘ Ｂｕｓ ＰＨＹ４３０ａ～ｂにおけるプロトコル選択は、アプリケーションに基づいて、自動ネゴシエーションを介してブート時間中に発生し得る。
【0048】
引き続き図４の例において、第１インタフェースタイプ４５０ａ、４５０ｂが、ＣＸＬ．ｃａｃｈｅ及びＣＸＬ．ｍｅｍなどのコヒーレントなプロトコルに使用され、ここで、別の異なるワイヤインタフェース定義（例えば、２０５'、２０５"）（例えば、ＳＦＩインタフェース）が、ＰＣＩｅ及びＣＸＬ．ｉｏのようなロード／ストアプロトコルに使用される。一例において、ＳＦＩ２０５'、２０５"は、仲介インタフェースとして機能し得、これは、送信機及び受信機の間のプロトコル又は用途固有の役割に関して想定せず、ロード／ストアプロトコル（例えば、ＰＣＩｅ、ＣＸＬ．ｉｏなど）の高い帯域幅要件を維持し得るスケーラブルなストリーミングインタフェースを提供する。ＳＦＩは、他の例及びインタフェース実装の中でも特に、スタンドアロンのプロトコル定義、フロー制御にマッピングされることができる異なるプロトコルをサポートするために提供されるＳＦＩセマンティクス、及び、ＳＦＩ定義によって提供される仮想チャネルセマンティクスを含まない。
【0049】
図４に示されるように、システムは、例示的なインタフェース４５０ａ、４５０ｂを採用し得、ワイヤがファブリックにおいて共有されることを可能にし、異なるコヒーレントなプロトコルが共通のワイヤを共有することを可能にすることによって、ファブリック及びエージェント周囲におけるワイヤ効率を実現する。例えば、エージェントから発生する様々なプロトコルのチャネルは、物理チャネル及び仮想チャネルの最小セットに慎重にマッピングされ得、その結果、エージェント及びプロトコルの帯域幅及びチャネル隔離要件は、最低の合計ワイヤカウントを用いて満たされる。インタフェース４５０ａ、４５０ｂは、他の例示的な実装の中でも特に、これらの複数のプロトコルをチャネルの共通セットにマッピングし、これらのチャネル上で共通のフロー制御及び仮想化特徴を使用し得る。
【0050】
いくつかの実装において、少なくとも部分的に、ＰＣＩｅ又はＰＣＩｅセマンティクスに基づいてロード／ストアプロトコル（例えば、ＰＣＩｅ又はＣＸＬ．ｉｏ）をサポートするように適応される、改善されたストリーミングインタフェースが実装され得る。例えば、サポートされるプロトコルは、ＰＣＩｅ定義フォーマットに基づくパケットフォーマットを利用し得る。追加的に、フロー制御仮想チャネルの概念が、ＰＣＩｅ定義から拡張され得る。他の追加のプロトコル（例えば、非ＰＣＩｅ又はＣＸＬプロトコル）が、そのようなＳＦＩインタフェースによってもサポートされ得ることが理解されるべきである。実際、本明細書において論じられる例の多くは、ＰＣＩｅ又はＣＸＬ．ｉｏベースプロトコル及び実装を参照するが、本明細書において論じられる原理、特徴、及び解決手段は、より一般的に、例えば、他の例示的なシステムの中でも特に、様々な他のストリーミング又はロード／ストアプロトコルに適用され得ると理解されるべきである。
【0051】
いくつかの実装において、ＳＦＩインタフェースは、ヘッダ（ＨＤＲ）及びデータバス又はチャネルを分離し得、その各々は、複数のパケットのヘッダ又はペイロードを同時に搬送し得る。更に、パケットがヘッダ及びデータインタフェース上でどのようにパッキング／アンパッキングされるかを統制するために、形式化された規則が、エージェントのロジックにセットされ、採用され得る。例えば、追加のメタデータチャネル、又はバスが、改善されたインタフェース上で提供され得、別個のヘッダ及びペイロードデータチャネル上でそれぞれ送信されるヘッダ／データをどのようにアンパッキングするかを受信機が識別することを可能にするためにメタデータを搬送する。別個の、平行なヘッダ及びデータチャネルを通じて、システム（例えば、ＣＰＵホストのルートコンプレックス）は、例えば、対応するペイロードが受信される前に、潜在的な複数のヘッダを受信することによって、レイテンシの利益を享受し得る。この結果のリードタイムは、ヘッダを処理し、複数のヘッダリクエストについてのキャッシュラインについてのオーナシップのフェッチを開始するために、システムによって使用され得、一方、それらのリクエストのデータはなおストリーミングされている。これは、他の例示的な特長の中でも特に、レイテンシを重ねることを助け、バッファレジデンシを低減することを助ける。
【0052】
図５を参照すると、ＳＦＩインタフェースの例示的な実装を示す簡易ブロックダイアグラム５００が示される。例えば、ＳＦＩインタフェースの各インスタンスにおいて、物理レーン（例えば、ワイヤ又は他のコンダクタ）のセットが提供され、様々なチャネルにアサインされ得、これにより、インタフェースについて定義されインタフェースのそれぞれの物理レーンにアサインされた信号の論理セットを具体化する。各デバイスは、例えばインタフェースのその終端（送信機又は受信機）を実装するために、（ハードウェア回路及び／又はソフトウェアで実装される）ピン及び対応するＳＦＩロジックを保有し、インタフェース上で送信機及び受信機の間の接続を具体化する物理レーンに結合し得る。ＳＦＩインタフェースインスタンスは、追加的に、送信機から受信機へパケット又は他のデータ伝送メッセージを送信するための２つのチャネルを定義し得る。具体的には、いくつかの実装において、ＳＦＩインタフェース２０５は、それぞれ、パケットについてのヘッダデータを送信するのに使用されるインタフェースの複数のレーンの第１セットである信号（例えば、５０５、５１５、５２０）のセットを具体化するヘッダ（ＨＤＲ）チャネルを含み得る。ＳＦＩインタフェースは追加的に、インタフェース２０５の複数のレーンの追加的なセットにマッピングされる、メッセージについてのペイロードデータを送信するのに使用される信号（例えば、５１０、５２５、５３０）の別のセットを具体化するデータ（ＤＡＴＡ）チャネルを含む。ＨＤＲチャネルの信号は、ヘッダ自体を搬送するためのメインＨＤＲ信号５０５、及び、ヘッダメタデータ信号５１５、及び、ヘッダクレジットリターン信号５２０（受信機から送信機へ誘導される）を含み得る。同様に、ＤＡＴＡチャネルはまた、他の例示的な信号の中でも特に、ペイロードデータを搬送するためのメインデータ信号５１０、及び、データメタデータ信号５２５、及び、データクレジットリターン信号５３０（また、受信機から送信機へ誘導される）を含み得る。いくつかの実装において、ＳＦＩインタフェース２０５は追加的に、インタフェースのすべての物理チャネル（例えば、ＨＤＲ及びＤＡＴＡ）にわたって適用する双方向制御信号を含むグローバルチャネル又は層（例えば５５０）を含み得る。例えば、グローバルチャネルは、他の特徴の中でも特に、インタフェースの初期化又はシャットダウンを実行し、インタフェースについての制御又はパラメータを通信するために使用され得るグローバル制御信号のセットを搬送し得る。
【0053】
ＨＤＲ及びＤＡＴＡチャネルの各々は、伝送の同じサイクルで、複数のパケットを搬送し得る。大部分のロード／ストアプロトコルは、順序付けセマンティクスに依存し得るので、ＳＦＩは、複数のパケットが同じサイクルで送信されるとき、暗黙的な順序付けを想定する。パケットは、例えば、最下位の位置から最上位の位置へ順序付けられ得る。例えば、ＴＬＰ０がヘッダ信号５０５のバイト０から開始し、かつ、ＴＬＰ１がヘッダ信号５０５のバイト１６から開始する場合、受信機は、そのような順序付けルールが適用されるときにＴＬＰ１がＴＬＰ０の後に順序付けられるとみなす。異なるクロックサイクル間の伝送では、関連プロトコルの順序付けルールに従う（例えば、ＳＦＩは、ＰＣＩｅに使用されるとき、すべてのＰＣＩｅ順序付けルールを持ち越す）。リンク細分化（例えば、リンクのレーン全体を、２又はより多くのより小さい幅のリンク（例えば、それぞれのルートポートに関連付けられる）に分割する）の場合、コントローラの観点からの異なるポートは、ＳＦＩ上の異なる仮想チャネルにマッピングする。例えば、そのような場合、実装は、（例えば、エージェント又はコントローラとして実装される）同一の物理ブロック内において複数のポート構成をサポートし得る。これらの場合において、他の例示的な実装の中でも特に、ＳＦＩの同一の物理チャネルは、異なるポートについてパケットを伝送するために使用され得、各ポートは、仮想チャネル（例えば、ポートあたり１又は複数の仮想チャネル）のそれ自体のセットにマッピングされる。
【0054】
インスタンスの態様を構成するために、パラメータのセットが、ＳＦＩインタフェースのインスタンスについて定義され得る。例えば、ＨＤＲ及びＤＡＴＡチャネルのメタデータ信号は、構成可能なパラメータの１又は複数に基づき得る。例えば、他の例示的な情報の中でも特に、パラメータは、メタデータ信号がどのようにメタデータを搬送して、単一の伝送において異なるパケットの位置についての情報を伝えるかを識別し得る。例えば、ＳＦＩにおいて、それに関連付けられたデータを有するパケットヘッダは、ＨＤＲチャネル上でパケットヘッダを送信し、ＤＡＴＡチャネル上で、関連付けられたデータを別々に送信する。ＤＡＴＡ及びＨＤＲチャネル伝送の間には、タイミング関係保証が無いことがあり得る。受信機は、各受信されたヘッダについて関連付けられたデータ長を追跡し、関連データサイズのみを処理すると想定する。データサイズは、パケットヘッダ情報と共に送信され得る（例えば、ＰＣＩｅ実装、ＰＣＩｅパケットヘッダフォーマットを使用することにより、ＰＣＩｅ ＴＬＰヘッダの長さフィールドにおけるデータ量を識別し、データのいくつの４バイトチャンクがそのヘッダに関連付けられているかを示す）。メタデータ信号を通じて送信されたメタデータにおける情報はまた、他の例示的な情報の中でも特に、どのヘッダをどのデータにマッピングするか（例えば、フロー制御及び仮想チャネルＩＤの組み合わせを通じて）、パリティ情報、ヘッダフォーマットについての情報（例えば、ヘッダサイズ）を決定するために、受信機によって使用され得る。
【0055】
信号（例えば、５５０）のグローバル層又はチャネルが、インタフェース２０５のすべての物理チャネルにわたって適用する信号、例えば、制御信号、ベンダ定義信号、及び、他の例の機能を有効化する他の信号などを搬送し得る。例えば、グローバルチャネル５５０は、（下で論じられる例などにおいて）インタフェースの初期化及びシャットダウンのためにも使用される信号を搬送し得る。表１は、例示的なＳＦＩインタフェースのグローバルチャネルの信号の例示的な実装を説明する。
表１：グローバル層の信号
【表1】
【0056】
ＨＤＲチャネルは、送信機から受信機へリクエストメッセージのヘッダを搬送する。様々な情報が、アドレス及び他のプロトコルレベルコマンド情報を含む、ＨＤＲチャネルを使用して送信されるヘッダの（プロトコル固有）フィールドにおいてカプセル化され得る。表２は、例示的なＳＦＩインタフェースのＨＤＲチャネルの信号の例示的な実装を説明する。
表２：ＨＤＲ層のフィールド
【表2】
【0057】
ヘッダサイズは、システムの期待される又は必要とされるピークに維持された帯域幅に基づく、予め定められたパラメータであり得る。ＳＦＩインタフェース（及び対応するロジック）は、同じサイクルの伝送でのパケットヘッダ開始及び終了など、ＨＤＲチャネルについての規則を施行し得る。複数のパケットヘッダは、それにもかかわらず、ヘッダ信号レーンの第１サブセット上でパケットヘッダの１つを、ヘッダ信号レーンの別のサブセット上で他のパケットヘッダを送信することによって、同じサイクル上で送信され得る。しかしながら、インタフェースは、有効ヘッダ伝送上の第１パケットが、（ヘッダ信号レーンによって論理的に表される）ヘッダフィールドのバイト０に対応するヘッダ信号のレーン上で開始すると定義し得る。
【0058】
ヘッダ有効信号（ｈｄｒ＿ｖａｌｉｄ）は、ヘッダ信号のレーン上の対応する有効値を示すために、アサートされ得る。いくつかの実装において、ヘッダ信号のレーンの数は、ヘッダ信号上で搬送されるプロトコルヘッダの１つのサイズに対応する、バイト単位のサブセット（例えば、各サブセットにおけるレーン幅の１６バイト又は３２バイト）に論理的に分割され得る。更に、各ヘッダ有効レーンは、サブセットの１つにマッピングされ得、ヘッダ信号のレーンのサブセットの対応する１つへ有効ヘッダデータが送信されていることを示す。追加的に、ヘッダメタデータ信号（ｈｄｒ＿ｉｎｆｏ＿ｂｙｔｅｓ）は、（例えば、ヘッダ信号上で搬送されるヘッダの１つとアラインされた）メタデータを搬送し得、対応するヘッダをデコードするために受信機によって使用され得る主な属性を説明する。
【0059】
ＳＦＩインタフェースのＤＡＴＡ物理チャネルは、それに関連付けられたデータを有するすべてのリクエストについてのペイロードデータを搬送するために使用され得る。ＳＦＩでは、ＨＤＲチャネル、及び、ＤＡＴＡチャネル上で搬送される関連付けられたデータの間に明確なタイミング関係又は要件は無いことがあり得る。しかしながら、送信機は、ＨＤＲチャネル上のヘッダデータ又はＤＡＴＡチャネル上のペイロードデータのいずれかをスケジューリングする前に、ＨＤＲチャネル及びＤＡＴＡチャネルクレジットの両方をチェックするためのロジックを備え得る。表３は、例示的なＳＦＩインタフェースのＤＡＴＡチャネルの信号の例示的な実装を説明する。
表３：ＤＡＴＡチャネルのフィールド
【表3】
【0060】
ＳＦＩインタフェースの実装において、ペイロードデータは、マルチバイト粒度（例えば、４バイト粒度）に従って、ＤＡＴＡチャネルのデータ信号上で送信され得る。したがって、任意のペイロードについてのデータは、データの特定の「チャンク」（例えば、特定の４バイトチャンク）で終了すると識別され得る。一例として、データ信号Ｄの幅が６４バイトである場合、潜在的なデータ終了位置の数は、ＤＥ＝６４／４＝１６であり、ｄａｔａ＿ｅｎｄ［０］はデータバイト［３：０］に対応し、ｄａｔａ＿ｅｎｄ［１］はデータバイト［７：４］に対応し、ｄａｔａ＿ｅｎｄ［ＤＥ－１］はデータバイト［Ｄ－１：Ｄ－４］に対応する、などである。データ信号の開始（ｄａｔａ＿ｓｔａｒｔ）は、データ信号の終了と同一又は異なる粒度を利用し得る。ＳＦＩインタフェースのインスタンスは、クロックサイクルにおける開始ＤＳの最大数をサポートする（及び、それに従って、ペイロード開始の数を限定する）ために、パラメータ化され得る。一例として、データ信号バスＤの幅が６４バイトであり、かつ、ＳＦＩインタフェースのインスタンスが、サイクルにおける開始の数を２に限定するよう構成されている場合、ＤＳ＝２であり、新たなペイロードの送信が開始し得る２つの３２バイトチャンクにデータバスを効果的に分割する。例えば、他の例の中でも特に、Ｄ＝６２かつＤＳ＝２である例において、ｄａｔａ＿ｓｔａｒｔ［０］は、データバイト［３２］で開始するデータのチャンクに対応する、データバイト［０］及びｄａｔａ＿ｓｔａｒｔ［１］で開始するデータのチャンクに対応する（データの開始及びデータチャンク（例えば、ＤＳ＞２）の終了における、より低い又は高い粒度、より小さい、又は、より大きいデータバスサイズなどを有する例を含む）。
【0061】
ＳＦＩインタフェースのＤＡＴＡチャネルの１つの例示的な実装において、データ開始信号の幅は、ＤＳに等しいことがあり得、信号は、マスクとして効果的に作用し、それぞれのペイロードの開始に対応する（例えば、同一のクロックサイクルにおいてアラインされた）データ信号上のデータの各対応するチャンクを識別し得る。更に、各データ開始ビットは、対応するペイロードについてのメタデータを示す、それと共に送信される関連付けられたｄａｔａ＿ｉｎｆｏ＿ｂｙｔｅ信号を有し得る。いくつかの実装において、他の例示的な実装の中でも特に、ｄａｔａ＿ｉｎｆｏ＿ｂｙｔｅは、（例えば、対応するデータ開始チャンク及びｄａｔａ＿ｓｔａｒｔ＿ｂｉｔを用いて）所与のペイロードについて１回のみ送信され、一方、他の事例において、メタデータは、同一のペイロードにおけるデータのすべてのチャンクに対応して送信（例えば、再送）され得る。一実装において、データ信号バスを通じて送信されるデータペイロードの処理において受信機によって使用するために、他の例示的な情報の中でも特に、ｄａｔａ＿ｉｎｆｏ＿ｂｙｔｅ信号は、（例えば、ＦＣ ＩＤを搬送する４ビット（例えば、ｄａｔａ＿ｉｎｆｏ＿ｂｙｔｅ［３：０］）、及び、ＶＣ ＩＤを搬送する別の４ビット（例えば、ｄａｔａ＿ｉｎｆｏ＿ｂｙｔｅ［７：４］）を用いて）対応するパケットのそれぞれのＦＣ ＩＤ及びＶＣ ＩＤを示し得る。
【0062】
ＨＤＲチャネルと異なり、ＤＡＴＡチャネルのいくつかの実装において、同一パケットからのデータチャンクは、複数のサイクルにわたって伝送され得る。例えば、ローデータバス幅は、サイクルあたり６４Ｂとして実装され得、１２８Ｂデータパケットが２クロックサイクルにわたって伝送されることを可能にする。いくつかの実装において、ペイロードの送信が開始すると、送信機は、ペイロードにおけるすべての関連データチャンクが、ＬＳＢからＭＳＢへ連続的に、連続するクロックにわたって（例えば、任意のギャップ又はバブル無しで）伝送されることを保証し得る。いくつかの実装において、特定のＦＣ ＩＤ／ＶＣ ＩＤの組み合わせの１つのパケットのみが、一度にインタフェース上で送信され得る（ＦＣ ＩＤ／ＶＣ ＩＤの組み合わせは、組み合わせを使用する前のパケットが送信を完了した後にのみ再使用される）。いくつかの実装において、他の例の中でも特に、異なるＦＣ ＩＤ／ＶＣ ＩＤの組み合わせを有するパケットは、ＳＦＩインタフェース上でインターリーブされ得る（例えば、１つのＦＣ ＩＤ／ＶＣ ＩＤの組み合わせのパケットは、別のＦＣ ＩＤ／ＶＣ ＩＤの組み合わせを用いてパケットの少なくとも一部を送信するために、割り込まれる）。
【0063】
ＤＡＴＡチャネル上のクレジットの粒度も（例えば、設計コンパイル時に）構成可能であり得、複数のＮバイトに対応し得る。例えば、一例において、粒度は、４バイトの倍数である必要があり得る。クレジット粒度が１６バイトに選択される場合、他の例示的な実装の中でも特に、伝送される４バイトデータパケットさえ、１つの１６バイト分のクレジットを使用する。
【0064】
図６は、例示的なＳＦＩインタフェースと共に使用するための受信機バッファの例示的な実装を示す簡易ブロックダイアグラム６００である。一例において、受信機バッファは、単一の書き込みポートと共にリンクリストとして実装され、１つのフロー制御クラス（ＦＣ０）の２つの仮想チャネル（例えば、ＶＣ０及びＶＣ１）の間で共有され得る。この例において、サイクルあたり４つのヘッダが対応するＳＦＩインタフェース上で受信され得る。リンクリストは、一度に４つのヘッダ位置のブロック（例えば、６３０ａ～ｃ）において管理される。リンクリストは、メモリにおいて論理的に連続するように見え得るが、物理ブロックは、非連続的に、又は、別個のストレージ要素においてさえ実装され得る。一例において、所与のブロック（例えば、６３０ａ）内のすべての位置は、次のブロック（例えば、６３０ｂ）に移動する前に充填される。バッファは、受信機によって、一度に１ブロック割り当てられ、したがって、対応する共有クレジットもブロック粒度であり得る。実装において、ブロック（例えば６３０ａ）における４ヘッダ（例えば６０５ａ～ｄ）のセットが実際には別個のストレージ構造から構成されている場合、これらのストレージカラムの各々は、単一の書き込みポートのみを用いて正常に実装され得る。例えば、図６のリンクリストバッファにおいて表されるカラムの各々は、それぞれの単一の書き込みポートを用いて、別個のバッファ／ストレージ要素として物理的に実装され得る。さらに、タイミングリリーフ及びパイプライン処理ポテンシャルは、リンクリストポインタ（例えば、６１５、６２０、６２５）の「ブロック」管理を使用することによってアンロックされ得る。なぜなら、（図６の例において）次のブロックポインタは、４ヘッダに１回ルックアップされるだけで良いからである。いくつかのストリーミングプロトコルにおいて、受信機は、一般的な場合において、サイクルあたり１つのみのＦＣ／ＶＣの組み合わせを想定できないので、したがって、複数の書き込みポートを備えるように設計され得る（例えば、異なるＦＣ／ＶＣのテールは、同一のストレージカラム内で衝突し得る）。
【0065】
上で論じられたように、ＳＦＩインタフェース（及び、インタフェースの半分を実装するために送信機及び／又は受信機によって利用される対応するロジック及びバッファトラッカ）は、データがストリーミングされる間に、ヘッダ処理のパイプライン処理を有効化し得る。実際、それによって実現されるレイテンシの節約は、ヘッダ処理の観点において、受信機におけるバッファの節約に直接つながる。ロード／ストアプロトコルのコンテクストにおいて、受信機は、任意の方式でヘッダ及びデータを内部で分離すると想定される。ヘッダは、制御パスによって大きく消費されるからである。ここで、大部分のデータは、データパスに隔離される。例示的なＳＦＩインタフェース上でヘッダ及びＤＡＴＡチャネルを分割することによって、後のリクエストのヘッダは、前のリクエストのデータをバイパスすることさえあり得、これにより、データ伝送が完了されている間に、受信機が、ヘッダの処理を開始することを可能にし得る。他の例示的なユースケース及び利点の中でも特に、ホストＣＰＵ処理インバウンド（デバイスからホスト）書き込みのコンテクストにおいて、これは、関連するキャッシュラインのオーナシップを取得するヘッドスタートをもたらし得る。実際、オーナシップのフェッチは、書き込みを処理するとき、レイテンシのもっとも大きい原動力の１つであるので、データストリーム中にこれを重ねることによって、ＣＰＵにおける全体のレイテンシ及びバッファを低減することを助け得る。デッドロックは、ヘッダ又はデータのいずれかを送信する前に、送信機がヘッダ及びデータクレジットの両方をチェックすることを確実にすることによって回避される。
【0066】
いくつかの実装において、ＳＦＩインタフェースについて定義された各ＶＣ及びＦＣは、任意のメッセージを送信し、受信機からクレジットリターンを収集するためにクレジットを使用するためのものである。ソースは、メッセージが完了するのに必要な完全なクレジットを消費し得る。送信機は、それぞれのチャネル上で対応するメッセージを受信機へ送信する前に、ＨＤＲチャネル及びＤＡＴＡチャネルクレジットの両方をチェックする。ＨＤＲ及びＤＡＴＡチャネルクレジットの粒度は、ＴＸ及びＲＸの間で予め定められる。例えば、ＤＡＴＡチャネル上のクレジットの粒度は、（例えば、設計コンパイル時に）複数のＮバイトのみに構成され得る。例えば、一例において、粒度は、４バイトの倍数である必要があり得る。クレジット粒度が１６バイトに選択される場合、他の例示的な実装の中でも特に、伝送される４バイトデータパケットさえ、１つの１６バイト分のクレジットを使用する。一例において、ＦＣ ＩＤは、他の例示的な実装の中でも特に、ＰＣＩｅセマンティクスに基づき得る（例えば、４'ｈ０＝ポステッド、４'ｈ１＝ノンポステッド、４'ｈ２＝完了）。更に、物理チャネル（例えば、ＤＡＴＡ及びＨＤＲ）の各々は、（受信機から送信機への残りのチャネルフローと異なり）専用クレジットリターンワイヤを備え得る。例えば、動作中に、受信機は、メッセージを処理した（又は、次のトランザクションについてのバッファ位置を保証した）ときはいつもクレジットを返す。
【0067】
いくつかの実装において、ＳＦＩは、異なるＦＣ及びＶＣ ＩＤの間のバッファの共有をサポートするための２つのスキームを可能にする。両方のスキームにおいて、受信機は、転送進行保証に必要な最小限の数の専用リソースをアドバタイズする。大きいパケット伝送については、これは、最大のペイロードサイズは専用クレジットアドバタイズメントに基づくことを意味する。共有クレジットが使用される場合、送信機及び受信機は、どのクレジットタイプ又はスキームが使用されるかを予め定められる。いくつかの実装において、この決定は、設計時に行われ得る。代替的な実装において、他の例の中でも特に、クレジットスキームは、（例えば、対応する構成レジスタに書き込まれるパラメータに基づいて）動的に決定され得る。
【0068】
クレジット共有のための２つのスキームのうち第１のものは、送信機によって管理され得る。このスキームにおいて、送信機は、受信機における共有バッファを管理することを担当する。１又は複数の共有クレジットプールは、スペアＶＣ ＩＤ／ＦＣ ＩＤエンコーディングを用いてアドバタイズ又は消費される。送信機が共有クレジットプールクレジットを消費するとき、対応するＶＣ ＩＤ／ＦＣ ＩＤエンコーディングを使用してパケットを送信する。受信機が、共有クレジットを使用したトランザクションを割り当て解除するとき、対応するＶＣ／ＦＣ ＩＤの組み合わせに対してクレジットリターンを行う。いくつかの実装において、クレジットが共有クレジットであるか又はそうでないかを示すために、（ＨＤＲチャネル上の対応する信号と共に）ビットがヘッダにおいて提供され得る。したがって、他の例の中でも特に、受信機は、パケットの実際のＶＣ ＩＤ又はＦＣ ＩＤを明示的に決定するためにヘッダパケットを更にデコードする必要があり得る。
【0069】
送信機によって管理されるクレジット共有の１つの例示的な実装において、（例えば、ＰＣＩｅベース実装において）受信機によってアドバタイズされる例示的な共有クレジットプールのマッピングは、リンク上で２つのＶＣをサポートし、表４に示される以下の例示的なマッピングを採用し得る。
表４：共有クレジットについての例示的エンコーディング
【表4】
【0070】
２つのクレジット共有スキームのうち別のものは、受信機によって管理され得る。受信機によって管理されるスキームにおいて、受信機は、共有バッファの管理を担当する。専用クレジットのみが送信機にアドバタイズされる。典型的には、アドバタイズされた専用クレジットは、ＳＦＩにわたるポイントツーポイントクレジットループをカバーし、共有クレジットは、より大きいクレジットループ（例えば、ＣＰＵファブリック又はアプリケーション層レイテンシ）をカバーするために使用される。特定のＦＣ／ＶＣ ＩＤトランザクションが受信され、共有クレジットが利用可能となった後に、クレジットは、（例えば、トランザクションが受信機キューから割り当て解除するまで待つことなく）そのＦＣ／ＶＣ ＩＤの組み合わせについて返され得る。これは、そのＦＣ／ＶＣ ＩＤに対して、共有バッファスポットを暗示的に与える。内部的には、受信機は、ＦＣ／ＶＣに基づいて送信機へ返されるクレジットを追跡し、更に、送信機によって現在消費されるクレジットを追跡する。この追跡により、受信機は、ＦＣ／ＶＣあたり最大数のバッファが使用されることを確実にし得る。受信機は、他の例示的な実装の中でも特に、転送進行保証のために、必要な専用リソースを保証し得る。
【0071】
異常なフロー制御の場合のエラー処理は、未定義の挙動をもたらし得る。したがって、エージェント及びファブリック上のＳＦＩインタフェースロジックは、異常な場合をチェックして、ＲＴＬにおいてアサーションをトリガし、また、ポストシリコンデバッグを可能にするためにフェイタルエラーを記録／シグナリングし得る。例えば、ＳＦＩは、ＨＤＲ及びデータストリームの間の一貫性を維持し得、これは、送信機が、対応するヘッダを送信するのと同一順序でデータペイロードを送信することを意味し、逆も同様である。いくつかの実装において、受信機ロジックは、他の例示的なエラー処理の特徴の中でも特に、違反についてフェイタルエラーを検出及びフラグ付けする機能を含み得る。いくつかの実装において、ＳＦＩは、データ伝送の終了時に送信されるデータポイズニングのためにプロビジョニングする。時折のエラーの場合、他の例の中でも特に、オーナシップリクエストは、修正無しで破棄／ライトバックされ得、又は、ホストは、関連するキャッシュラインをポイズニングし、更新されたデータを書き込むことを選択し得る。
【0072】
図７を参照すると、ヘッダメタデータ信号のレーン上で搬送され得る、例示的なメタデータフォーマット７００の表現が示される。最下位バイト及びビットは右に示される。Ｐ（７０５）は、対応するヘッダについてのパリティビットである。いくつかの実装において、パリティビットについてのサポートは、任意選択であり得る（例えば、及び、追加の予約ビットとして扱われるパリティビット７０５）。サポートされるとき、パリティは、例えば、パケットヘッダのビットの少なくともすべてをＸＯＲすることによってサポートされ得る。いくつかの実装において、他の例の中でも特に、パリティを決定するために、関連付けられたメタデータ７００のビット及び非パリティビットの両方はＸＯＲされ得る。ビットＤ（７１０）は、ヘッダがそれに関連付けられた対応するペイロードデータを有するかどうかを示す。すべての予約ビット（例えば、７１５）は受信機によって無視され得、又は、送信機によって０に駆動される必要があり得る。いくつかの実装において、スイッチ／ファブリックルータが、任意の修正無しでそのまま予約ビット７１５を伝搬するために必要であり得る。いくつかの実装において、他の例の中でも特に、予約ビット７１５は、ベンダ定義エンコーディング又は将来の情報のために利用され得る。例示的なメタデータ７００におけるヘッダサイズ（ＨＤＲ ＳＩＺＥ）７２５は、（例えば、４バイト粒度で）ヘッダのサイズを指定し得る。ヘッダサイズを計算するとき、ヘッダメタデータ（７００）の長さは無視され得る（ヘッダの一部とみなされない）。
【0073】
ＳＦＩインタフェースの実装において、インタフェース上で１つのサイクルにおいて送信され得る最大パケットヘッダの数は、予め定められ（例えば、及び、インタフェースの構成可能なパラメータに記録され）得る。サイクルあたりの最大パケットヘッダは、ヘッダ信号の幅（又はレーンの数）（Ｈ）及び最大パケットヘッダサイズによって決定され得る。ヘッダ幅（Ｈ）が、共通のケース使用が最大スループットを維持することを可能にするように、ＳＦＩインタフェースが実装（及び設計）され得る。一例として、共通のケースのアプリケーションヘッダサイズが１６バイトであり（例えば、ＰＣＩｅにおける４Ｄ－Ｗｏｒｄヘッダへのマッピング）、かつ、インタフェースがサイクルあたり２つのヘッダを維持すると想定すると、Ｈ＝２＊（１６）＝３２バイトである。対応する有効信号（及びレーン）は、所望のサイクルあたりのヘッダの数に対応するＨＤＲチャネルに含まれ得る。一例として、インタフェースがサイクルあたり最大２つのヘッダを維持することが望ましい場合、対応するＭ＝２の数の有効レーンが定義され得、サイクルにおける潜在的な２つのヘッダの各々について１つの有効信号をサポートする（例えば、ｈｄｒ＿ｖａｌｉｄ［０］は、ヘッダ信号のバイト０におけるヘッダ開始に対応し、ｈｄｒ＿ｖａｌｉｄ［１］は、ヘッダ信号のバイト１６におけるヘッダ開始に対応する）。いくつかの事例において、サポートされるプロトコルのヘッダフォーマットの１又は複数は、大きすぎ、ヘッダ信号において定義されたレーンのサブセットの１つのみで送信すること（及び、有効信号レーンのそれぞれの１つにアサインされること）ができないことがあり得、そのようなヘッダは、ヘッダ信号におけるレーンのサブセットの２又はより多くを送信に利用し得る（そして、２又はより多くの関連付けられた有効信号のうち第１のもの（最下位ビット）だけがアサートされ得る）ことを意味する。そのような事例において、他の例の中でも特に、サイクルあたりの最大ヘッダが２にセットされるとき、より大きいヘッダフォーマットがヘッダ信号上で送信される場合、１つのヘッダのみがそのサイクルにおいて伝送され得、ｈｄｒ＿ｖａｌｉｄ［１］はアサートされない。
【0074】
引き続き、図７の例において、ヘッダメタデータは追加的に、ヘッダ（及び関連パケット）のフロー制御において使用するための情報を含み得る。例えば、メタデータは、ヘッダについての仮想チャネル（ＶＣ）識別子（ＩＤ）７２０、及び、ヘッダについてのフロー制御クラス（ＦＣ）ＩＤ７３０を含み得る。いくつかの事例において、パケット順序付けは、パケットのＶＣ ＩＤ及びＦＣ ＩＤ（例えば、ＶＣ ＩＤ及びＦＣ ＩＤの組み合わせ）に従い得る。いくつかの実装において、ＳＦＩインタフェースのパラメータは、インタフェースについて、インタフェースの任意の所与の伝送サイクル（例えば、クロックサイクル）において使用が可能である、予め定められた数の最大ＦＣ及びＶＣ ＩＤの組み合わせをセットするよう構成され得る。この最大数のＦＣ－ＶＣの組み合わせは、（例えば、設計コンパイル時に）送信機及び受信機の両方のインタフェースロジックにおいてアドバタイズされ得る、又は、さもなければセットされ得る。この最大値は、例えば、サポートされるＦＣ及び／又はＶＣの間で受信機バッファが共有されるとき、受信機のストレージにおける書き込みポートを最小化することを支援するためにセットされ得る。一例として、インタフェースは、サイクルにおいて最大２つの異なるＦＣ－ＶＣの組み合わせを受け付けるためにパラメータ化され得、それにより、任意の所与のサイクルにおいて、伝送されるすべてのパケットヘッダは、同一のＶＣの中の最大２つの異なるＦＣ、２つの異なるＶＣについての同一のＦＣ、又は、同一のＦＣ－ＶＣの組み合わせに属する。
【0075】
送信機は、ＦＣ、ＶＣ、又はＦＣ－ＶＣの組み合わせに関連付けられたクレジットを利用して、パケットがチャネルを通じて送信され得るかどうかを判定し得る。例えば、パケットヘッダが、それに関連付けられたデータを有する場合、パケットヘッダはＨＤＲチャネル上で送信され、関連付けられたデータは、ＤＡＴＡチャネル上で送信される。ヘッダ又はペイロードデータの送信に先立ち、送信機は、ヘッダ又はペイロードデータ伝送をスケジューリングする前に、ヘッダ及びペイロードデータ（及び、対応するＨＤＲ及びＤＡＴＡチャネル）の両方についての利用可能なクレジットをチェックし得る（例えば、ローカルメモリにおける記録を追跡する）。いくつかの実装において、ヘッダチャネルについてのクレジット粒度は、最大のサポートされるヘッダサイズにセットされ得る。例えば、サポートされる最大のヘッダサイズが２０バイトである場合、ヘッダチャネル上の１つのクレジットは、受信機における２０バイト分のストレージに対応し得る。いくつかの事例において、他の例示的な同様の代替的フロー制御及びクレジット実装の中でも特に、１６バイトヘッダのみが送信される場合でも、完全な２０バイトに対応する１つの完全なクレジットが消費される。
【0076】
図８を参照すると、例示的なＳＦＩインタフェースのヘッダチャネルを使用するヘッダ伝送の例を示す、簡略化されたタイミングダイアグラム８００が示される。ヘッダチャネルは、クロックレーン、ヘッダ有効信号（例えば、８１０、８２５）専用の１又は複数のレーン、通信ヘッダメタデータ専用のレーン（例えば、８１５、８３０）、及び、ヘッダバス（例えば、８２０、８３５）の複数のバイトを実装するための専用のレーンを含み得る。図８の例において、ヘッダバスの対応するサブセクション上で有効なヘッダデータの送信を統制するために、複数の有効信号が提供される。例えば、ヘッダレーン８１０は、ヘッダバスのバイト０～１５を実装するレーン（例えば、８２０）に対応する有効信号を搬送し得、ヘッダレーン８２５は、ヘッダバスのバイト１６～３１を実装するレーン（例えば、８３５）に対応する有効信号を搬送し得る。したがって、有効信号８１０は、有効データが（例えば、クロックサイクル１、２、及び４において）ヘッダバスのバイト０～１５上で送信される限りアサートされ得、同様に、有効信号８２５は、バイト１６～３１上で送信される有効データに対応してアサートされ得る。一例において、図８のように、対応するヘッダデータが、対応するアサートされた有効信号として、アライメントされて（例えば、同一のクロックサイクル）送信され得、一方、代替的な実装において、他の例示的特徴及び実装の中でも特に、有効信号のアサーション及びヘッダデータの送信の間の遅延が定義され得る。
【0077】
引き続き図８の例において、ヘッダバスを実装するレーンのサブセクションも、それぞれのヘッダメタデータ（又はｈｄｒ＿ｉｎｆｏ）信号（例えば、８１５、８３０）に関連付けられ得る。例えば、ヘッダバイト０～１５（例えば、８２０）は、第１ヘッダメタデータ信号８１５に関連付けられ得、ヘッダバイト１６～３１は、第２ヘッダメタデータ信号８３０に関連付けられ得る。ヘッダメタデータ信号は、対応するヘッダバスレーン上で搬送されるヘッダの属性を説明するサイクルあたりのデータ（例えば、８バイト）を搬送し得る。いくつかの場合において、ヘッダバスの両方のサブセクションが、より大きいヘッダを搬送するために利用され得、結果として、所与のサイクル（例えば、クロックサイクル４）において、最大数より少ないサイクルあたりのヘッダが送信される。ヘッダバスの２又はより多くサブセクションが、単一のヘッダを送信するために使用されるとき、いくつかの実装において、対応するメタデータ信号のうち１つのみ（例えば、ヘッダの最下位バイトに対応する信号）がデータを搬送し得、一方、残りのメタデータ信号は、任意のメタデータを搬送しない。この方式において、他の例の中でも特に、受信機は、ヘッダバスレーンの１より多くのサブセットが、単一のヘッダを送信するために使用されると識別し得る（例えば、ヘッダを通信するために使用されるヘッダバスのサブセクションに対応する有効信号（例えば、８１０、８２５）の一方又は両方のアサーション）。
【0078】
図８の特定の単純化した例において、５つのトランザクション層パケット（ＴＬＰ）のヘッダは、例示的なＳＦＩヘッダチャネルを通じて送信されることが示される。例えば、ヘッダバスサブセクション８２０、８３５は各々、クロックサイクル１及び２において、２つの別個のＴＬＰのヘッダ（例えば、サイクル１におけるＴＬＰ０（８４０）及びＴＬＰ１（８４５）のヘッダ、及び、サイクル２におけるＴＬＰ２（８５０）及びＴＬＰ３（８５５）のヘッダ）を搬送し得る。これは、これらのそれぞれのパケットのヘッダサイズに基づいて可能となり得る。更に、対応するヘッダメタデータ（例えば、８６５、８７０、８７５、８８０）は、サイクル１及び２における対応するヘッダメタデータ信号８１５、８３０上で送信され得る。有効信号８１０、８２５は、サイクル３においてデアサートされ得、このサイクル中に、追加のヘッダデータを送信させない。
【0079】
サイクル４において、別のＴＬＰ、ＴＬＰ４のヘッダが送信される。この例において、単一のクロックサイクルにおいてＨＤＲチャネルでヘッダを通信するべく、ＴＬＰ４のヘッダのサイズは、ヘッダバスサブセクション８２０、８３５の両方でのトランスポートを必要とする。例えば、ＴＬＰ０～３のヘッダ（例えば、８４０、８４５、８５０、８５５）は、サイズＨＤＲ＿ＳＩＺＥ＝４であり得、一方、ＴＬＰ４ヘッダのサイズは、ＨＤＲ＿ＳＩＺＥ＝５である。したがって、この例において、ＴＬＰ４ヘッダ（８６０ａ～ｂ）のバイトは、ヘッダバスサブセクション８２０及び８３５両方のレーン上で送信される。この例において、ヘッダの開始（又は、最下位バイト）を搬送するヘッダバスのサブセクション（又はバイト）に対応する有効信号８１０のみがハイにアサートされ（８９０）、一方、他の有効信号８２５は、クロックサイクル４においてデアサートされたままである。同様に、ヘッダメタデータ信号（例えば、８１５）の１つのみが、ＴＬＰ４ヘッダについてのメタデータ情報を搬送するために使用され得、メタデータ信号（例えば、８３０）は、ヌル又は他の信号を搬送するヘッダの最上位バイトに対応する。一例において、ＴＬＰ０～４のヘッダは、ＰＣＩｅベースのプロトコルに従い得る。そのような事例において、ＴＬＰ Ｈｄｒバイトは、ＰＣＩ Ｅｘｐｒｅｓｓ Ｂａｓｅ仕様において説明されるフォーマットに従う。この例において、他の例示的な実装の中でも特に、ｈｄｒ＿ｓｔａｒｔ［０］は、ｈｅａｄｅｒ ｂｙｔｅ［０］に関連付けられ、ｈｄｒ＿ｓｔａｒｔ［１］は常に、ヘッダバイト［１６］に関連付けられる。
【0080】
いくつかの実装において、ＳＦＩインタフェースは、同期インタフェースとして実装され得、ここで、インタフェースの両方の側が、同一クロックで実行する。これにもかかわらず、送信機及び受信機は、各それぞれのデバイスにおいて、リセットを調整する必要ないことがあり得る。代わりに、いくつかの実装において、インタフェースについて定義された初期化フローは、トラフィックがインタフェース上で開始する前に、送信機及び受信機がインタフェースリセット及びフロー制御についての情報を交換すことを確実にするために、別個のハンドシェイクを定義し得る。
【0081】
図９を参照すると、例示的なＳＦＩインタフェースのＤＡＴＡチャネルを使用してデータ伝送の例を示す、簡略化されたタイミングダイアグラム９００が示されている。この例において、ＤＡＴＡチャネルは、クロック９０５、単一の有効信号９１０（例えば、チャネルの単一のレーン上）、及び、データバスの１又は複数のサブセクションを実装するレーン（例えば、９１５、９２０）のセットを含む。図９のこの特定の説明用の例において、Ｘ－１サブセクションが示される。有効信号９１０が（例えば、９４５において）アサートされるとき、データバス上に現れるデータ（及び、サポートする信号（例えば、９２５、９３０、９３５、９４０））は有効とみなされる。有効９１０が（例えば、９６６において）デアサートされるとき、データバス上のデータの送信は、有効が再アサートされるまで、停止又はストールする。
【0082】
ＳＦＩ ＤＡＴＡチャネルのいくつかの実装において、データ（又はｄａｔａ＿ｓｔａｒｔ）信号の開始が提供され得、これは、ｄａｔａ＿ｓｔａｒｔ信号のビットの対応する数を実装するためにレーンのセット上で実装される。例えば、ｄａｔａ＿ｓｔａｒｔ信号は、データバスにおけるバイトのそれぞれのバイト又はスパンにマッピングされる、対応するｄａｔａ＿ｓｔａｒｔレーン（例えば、９２５、９２６、９２８など）を有するビットベクトルとして実装され得る。例えば、各ｄａｔａ＿ｓｔａｒｔレーン（例えば、９２５、９２６、９２８など）が、データバスのＸ＋１サブセクションの対応する１つにマッピングし得る。例えば、データバスの８個のサブセクションがある例において、データ信号の開始は、８ビット又はレーンから構成され得、各ビットは、サブセクションの１つにマッピングされる。ペイロードの第１バイト（例えば、最下位バイトから最上位バイトまで測定される）が、特定のクロックサイクルにおいて通信されるとき、データ信号（例えば、９２５）の対応する開始は、（例えば、９５４で）アサートされ得、その第１ペイロードバイトが見つかり得るデータバスのサブセクション（又はチャンク）を識別する。これを通じて、受信機は、チャネル上で通信される２つのペイロードの間の境界を識別し得る。
【0083】
ＨＤＲチャネルの例のように、ＳＦＩ ＤＡＴＡチャネルはまた、データバス上で送信される対応するペイロードデータを説明するために、専用メタデータ（ｄａｔａ＿ｉｎｆｏ）信号レーン（例えば、９３０、９３５）上でメタデータを搬送し得る。いくつかの実装において、ペイロードについてのメタデータは、そのペイロードの開始と関連付けられて（例えば、ペイロードの第１バイト及び対応するｄａｔａ＿ｓｔａｒｔ信号とアラインされて）ＤＡＴＡチャネル上で通信され得る。実際、複数のメタデータ信号が定義され、ＤＡＴＡチャネル上で搬送され得、１つはデータバスのサブセクション（例えば、９１５、９２０）の対応する数の各々に対応する。いくつかの実装において、サブセクション又はチャンクは、ｄａｔａ＿ｓｔａｒｔ信号（及び／又はｄａｔａ＿ｅｎｄ信号９４０）において利用される同一の論理チャンクに対応し得る。例えば、特定のチャンクが新たなペイロードの第１バイトを搬送するとき、メタデータ信号（例えば、９３０、９３５）の対応する１つは、そのペイロードについての対応するメタデータを搬送することを担当する。一例として、図９に示されるように、クロックサイクル１において、ＴＬＰ０のペイロード（９５０）の開始は、データバスの第１サブセクション（例えば、９１５）上で開始し得る。したがって、ｄａｔａ＿ｓｔａｒｔ信号９２５は、（例えば、データバスのバイト０に対応する）サブセクションが、新たなペイロードの開始を搬送することを示し得る（９５４）。データバスの他のサブセクション（例えば、９２０）は、同一のペイロードの追加の他のチャンク（例えば、９５２）を通信するために使用され得る。追加的に、データバスの第１サブセクション（例えば、９１５）に対応するメタデータ信号（例えば、９３０）の１つは、ＴＬＰ０ペイロードについてのメタデータ（例えば、９５６）でエンコードされ得る。
【0084】
引き続き、図９の例において、ＴＬＰ０のペイロードデータ（例えば、９５０、９５２、９６０）は、すべて送信されるまで、データバス上で、複数のクロックサイクルにわたって送信を継続され得る。データの終了（又はｄａｔａ＿ｅｎｄ）信号９４０は、データ信号の開始と同様の方式で動作し得、ペイロードデータの最終チャンクが対応するクロックサイクル内において送信されたデータバスのサブセクションを識別するために、複数のレーン（例えば、９４０、９４２）がマッピングされる。ｄａｔａ＿ｅｎｄ信号によって参照されるサブセクション又はチャンクの粒度は、ｄａｔａ＿ｓｔａｒｔ及びメタデータ信号において使用されるものより高い又は低い、又は同一であり得る。一例において、他の例の中でも特に、ｄａｔａ＿ｅｎｄ信号９４０によって参照されるサブセクション又はチャンクは、４バイトであり得る。図９の特定の説明用の例において、ＴＬＰ０のペイロードの最終バイト／ビットは、ｄａｔａ＿ｅｎｄ信号について構成された粒度に従って測定されるように、データバスバイト及びレーンのサブセクション「Ｎ」において送信される。したがって、サブセクションＮにマッピングされたｄａｔａ＿ｅｎｄ信号のレーン（例えば、９４０）は、サブセクションＮがペイロードの終了を搬送することを識別するためにアサートされ得る。いくつかの実装において、他の例の中でも特に、データの開始、データの終了、及び、メタデータ信号によって使用されるデータバスサブセクション及びチャンクの粒度は、ＳＦＩインタフェースについての対応するパラメータセットを通じて構成され得る。
【0085】
引き続き、図９の例において、第２パケットの第２ペイロード（例えば、ＴＬＰ１）が、データバス上で送信され得る（例えば、第２パケットの開始がデータチャンク／サブセクション「Ｙ」において送信される）。いくつかの実装において、複数のパケットのペイロードが、（例えば、データバスのそれぞれのサブセクションを使用して）データバス上で同時に送信され得る。この例では、クロックサイクル２において、ＴＬＰ０のペイロードは終了し、ＴＬＰ１のペイロードは開始する。したがって、データ終了信号（例えば、９７０）及びデータ開始信号（例えば、９６４）の両方が同じサイクルにおいて送信され、データ開始信号９６４は、ペイロードの開始が現れるデータバスのサブセクション又はチャンク（例えば、サブセクション「Ｙ」、ここで、０＜Ｙ＜Ｘ）を示す。図９の例において、データ信号の開始は、１バイト粒度であり、具体的には、ペイロードが開始するデータバスにおけるバイト（例えば、ＴＬＰ０のペイロードについてはバイト０、ＴＬＰ１のペイロードについてはバイトＹなど）を識別し得る。したがって、データ開始及びデータ終了信号の幅は、使用されるそれぞれの粒度に基づき得る。更に、図９の例において、ＴＬＰ１のペイロードは、クロックサイクル２において送信を開始するが、送信は、有効信号９１０のデアサーションを通じて一時的に割り込まれ得（９６６）、残りのバイト（例えば、９７２、９７４）は、有効９１０が再アサートされるときに送信される。他の例において、他の例示的な実装の中でも特に、有効は、輸送中のペイロードのすべてのバイトが送信されるまで、アサートされたままである必要があり得る。図８及び９の例は、他の例の中でも特に、例示的なＳＦＩ ＨＤＲ及びＤＡＴＡチャネルにおいて実装され得る、より一般的な原理（及び代替的な実装）を示すことを目的として提供される、簡略化された、非限定的な例であることが理解されるべきである。
【0086】
いくつかの実装において、ＳＦＩインタフェースにおける定義された接続及び切断フローに参加するために、状態機械又は他のロジックが、エージェント及びファブリックデバイス上で提供され得る。例えば、そのようなフローは、他の例示的な状態又はイベントの中でも特に、低電力モードに入るとき、ブート／リセット中に呼び出され得る。いくつかの実装において、ＳＦＩは、接続が確立された後に受信機（ＲＸ）におけるクレジット利用可能性についての情報が送信機（ＴＸ）へ通信される初期化フェーズを定義する。いくつかの事例において、リセットは、ＳＦＩのエージェント及びファブリック側の間で独立にデアサートし得る。独立のリセットについては、初期化信号は、リセット時に（例えば、グローバルチャネル上で）切断済み状態に駆動され得、初期化が接続済み状態に到達するまでトラフィックは送信されないことがあり得る。切断フローは追加的に、例えば、クレジットを再構成して省電力を実現するために、エージェントによってサポートされ得る。このフロー無しで、第１接続が進行できる前に、すべてのＳＦＩクレジットが、最終値に構成され得る。
【0087】
初期化において、ＳＦＩインタフェースの送信機及び受信機側（例えば、エージェント及びファブリック側）は、ほぼ同時に又は同時にリセットから抜け出し得る。インタフェースの一端（例えば、リセットから抜け出た後）は、他の端がリセットから抜け出す必要があるときについて黙示的な要件を有しないことがあり得る。いくつかの実装において、ＳＦＩは、エージェント及びファブリックの間で初期化中に明示的なハンドシェイクを定義し得、任意のクレジット又はトランザクションがＵＦＩインタフェース上で送信される前に、両方のエンドポイント（及び、それらの間のすべてのパイプラインステージ）がリセットから抜け出すことを確実にする。したがって、リセット後、受信機は、送信機によって使用されるためのクレジットの送信を開始し得る。
【0088】
図１０は、ＳＦＩインタフェースの例示的な実装における初期化状態についての例示的な状態機械を示すダイアグラム１０００である。状態は、切断済み状態１０１０（リセット１００５に基づいて入り得る）、接続中状態１０１５、接続済み状態（１０２０、１０３５）、切断中状態１０２５、及び拒絶状態１０３０を含み得る。ｔｘｃｏｎ＿ｒｅｑ信号、ｒｘｃｏｎ ａｃｋ信号、及びｒｘｄｉｓｃｏｎ＿ｎａｃｋ信号の値の組み合わせは、それぞれの初期化状態を示し得る。一例として、切断中状態１０２５において、ｔｘｃｏｎ＿ｒｅｑ信号はＬＯＷであり得、ｒｘｃｏｎ ａｃｋ信号はＨＩＧＨであり得、ｒｘｄｉｓｃｏｎ＿ｎａｃｋはＬＯＷであり得る。信号値の特定の１つを変更することにより、１つの初期化状態から別のものへの遷移を引き起こし得る。例えば、他の例の中でも特に、図１０の状態機械の例に示されるように、切断中状態１０２５において、ｒｘｃｏｎ ａｃｋ信号をＨＩＧＨからＬＯＷに変更することは、切断済み状態１０１０への遷移を引き起こし得、一方、ｒｘｄｉｓｃｏｎ＿ｎａｃｋ信号をＬＯＷからＨＩＧＨに変更することは、拒絶状態１０３０への遷移を引き起こし得る。ＵＦＩインタフェースにおいて、それぞれの初期化状態が、下の表５において説明される例示的な動作などの、受信機及び送信機によって実行される動作を決定するために使用される。
表５：初期化状態動作
【表5】
【0089】
シグナリング規則が、グローバル初期化信号セットについて定義され得る。一例において、ｔｘｃｏｎ＿ｒｅｑ信号は、０から１への遷移が接続リクエストを反映し、１から０への遷移が切断リクエストを反映するように定義され得る。クレジットリターン信号が、例えば、クレジット有効（ｃｒｄ＿ｖａｌｉｄ）信号及びクレジット共有（ｃｒｄ＿ｓｈａｒｅｄ）信号と共に提供され得る。一例において、ｃｒｄ＿ｖａｌｉｄ＝１が、プロトコルＩＤ及び仮想チャネルＩＤについての専用メッセージクレジットをリリースすることを意味するために定義され得、一方、ｃｒｄ＿ｓｈａｒｅｄ＝１は、共有クレジットをリリースすることを意味する（これは、専用メッセージクレジットリターンと並行に発生し得る）。いくつかの実装において、クレジットリターンは、クレジットの第１初期化中に、クレジットのランタイムリターン中と同じ方式で挙動する。ｒｘ＿ｅｍｐｔｙ信号は、受信機から返されたすべてのチャネルクレジット、及び、すべての受信機キューが空であることを示す（ただし、他の例示的な問題の中でも特に、これは、輸送中の、又は、クロッククロッシングキューなどの仲介バッファにおけるメッセージは考慮しないことがあり得る）。いくつかの実装において、送信機は、切断を開始する前に、ｒｘ＿ｅｍｐｔｙをチェックし得る。チェックすることによって、（例えば、受信機においてまだ登録されていない、可能性のある輸送中のリクエストが存在しないとき）切断が迅速に受け付けられる確率を増加させる。いくつかの実装において、切断受付の確率を更に増加させるために、送信機は、最後の有効メッセージが送信された後に、タイマ遅延を実装し得、それにより、他の例示的特徴の中でも特に、受信機パイプラインは、受信機キューにドレインする時間を有する。いくつかの実装において、初期化中に、任意のクレジットが利用可能になるとすぐに、ｒｘ＿ｅｍｐｔｙアサーションに依存ぜずに、送信機はメッセージを送信し得る。代替的に、送信機は、ｒｘ＿ｅｍｐｔｙがアサートされるまで、初期化後に任意のパケットの送信をストールし得、送信機は、受信機がアドバタイズした全体のクレジットのインジケーションとして受信されたクレジットを使用し得る。ＳＦＩインタフェースの例示的な実装において、送信機は、受信機から十分なクレジットを受信するとき、パケットを送信し得る。送信機は、パケットが送信されることを識別し、送信開始前に、パケットについてそれぞれ十分なＨＤＲ及びデータクレジットがあると判定し得る。
【0090】
ＵＦＩ実装において定義され得るシグナリング規則の更なる例として、常に接続リクエストの後に続く接続ＡＣＫが定義され得る。上に記載されるように、接続リクエストが、０→１に遷移するｔｘｃｏｎ＿ｒｅｑによってシグナリングされ得る。この遷移は、送信機Ｔｘがクレジットを受信する準備ができており正常に動作していることのインジケーションとして機能する。ＡＣＫが、０→１に遷移するｒｘｃｏｎ＿ａｃｋによってシグナリングされ得る。ＡＣＫは、受信機が完了の準備ができるまで、任意の時間にわたってストールされ得る。同様に、切断リクエストの後に続く切断ＡＣＫ又はＮＡＣＫが定義され得る。切断リクエストが、１→０に遷移するｔｘｃｏｎ＿ｒｅｑによってシグナリングされ得る。切断ＡＣＫが、１→０に遷移するｒｘｃｏｎ＿ａｃｋによってシグナリングされ得る。切断ＮＡＣＫが、０→１に遷移するｒｘｄｉｓｃｏｎ＿ｎａｃｋによってシグナリングされ得る。他の例示的なポリシー及び実装の中でも特に、受信機が、それが受信する各切断リクエストに対してＡＣＫ又はＮＡＣＫのいずれかで応答することを必要とするための規則が定義され得る。
【0091】
図１１を参照すると、リセットから接続済み状態へのＳＦＩインタフェースの初期化のための例示的なタイミングダイアグラム１１００が示される。図１１に示される特定の例において、ＳＦＩインタフェースのグローバルチャネルにおける初期化信号を利用する例示的な初期化フローが示される。図１１に示されるように、初期化信号セットは、受信機切断ＮＡＣＫ信号１１１０、受信機接続ＡＣＫ信号１１１５、及び送信機接続リクエスト信号１１２０を含み得る。受信機リセット信号１１３０（エージェントをリセット状態に入らせる）、送信機リセット信号１１３５（ファブリックをリセット状態に入らせる）を含む、特定の特徴を示すための追加の信号が示される。ＳＦＩチャネルのクレジットリターン信号セット１１２５（例えば、ＨＤＲ及びＤＡＴＡチャネルの１又は複数についてのクレジット信号セット）の少なくとも１つの表現も示される。
【0092】
接続済み状態に入るために、送信機がリセットから抜け出すと、ｔｘｃｏｎ＿ｒｅｑ信号１１２０をアサートして、受信機へのリクエストを識別し得る。同様に、受信機がリセットから抜け出すと、ｔｘｃｏｎ＿ｒｅｑ信号１１２０上の接続リクエストを待つ。接続リクエストのアサーションは、リセット（例えば、１１３０）がアサートした後のサイクルの任意の数であり得る。接続が完了するまで、ｔｘｃｏｎ＿ｒｅｑ信号１１２０はアサートするままであり、切断フローの一部としてデアサートされるだけである。ｔｘｃｏｎ＿ｒｅｑ信号１１２０上で接続リクエストを受信すると、受信機は、ｒｘｃｏｎ＿ａｃｋ信号１１１５をアサートして、リクエストに確認応答し得る。ｒｘｃｏｎ＿ａｃｋ信号１１１５は、受信機及び送信機のリセット、及び、ｔｘｃｏｎ＿ｒｅｑ信号１１２０のアサーションの後にアサートされ得る。ｒｘｃｏｎ＿ａｃｋ信号１１１５は、アサートするままであり、切断フローのみにおいてまずデアサートされる。
【0093】
このシーケンスは、初期化リンク状態１１０５が切断済みから接続中、接続済み状態に進行することを可能にし得る。接続済み状態に入る（そして、ｒｘｃｏｎ＿ａｃｋ信号を送信する）と、受信機は、即時に（例えば、クレジットリターンワイヤ１１２５上で）クレジットを返し始め得る。実際、受信機は、ｒｘｃｏｎ＿ａｃｋ信号１１１５のアサーションと同時にクレジットを返し始める。したがって、送信機（例えば、エージェント）は、（例えば、クロックサイクルｘ４において）ｔｘｃｏｎ＿ｒｅｑ信号１１２０をアサートすると、クレジットリターンを受け付ける準備ができる。なぜなら、例えば、クレジットリターンは、仲介バッファ又はクロッククロッシングに起因して、Ａ２Ｆ＿ｒｘｃｏｎ＿ａｃｋの観察の前に観察され得るからである。パケットを送信するために最小限のクレジットを受信した後、送信機は、チャネル上でパケット又はメッセージを送信し始め得る。再接続フローは、本明細書において論じられるリセットフローからの接続と同様に実装され得るが、しかしながら、他の例示的な実装の中でも特に、新しいクレジット初期化を開始するために、受信機はまず、そのクレジットカウンタをリセット値にリセットし、送信機は、利用可能なクレジットのカウンタをゼロにリセットする。
【0094】
図１２を参照すると、例示的なＳＦＩインタフェースについての例示的な切断及び再接続フローを示す、例示的なタイミングダイアグラム１２００が示されている。この例において、送信機は、時間ｘ３において、ｔｘｃｏｎ＿ｒｅｑ信号１１２０をデアサートして、切断を促進し得る。いくつかの実装において、切断を進行させることを可能にするために、ｔｘｃｏｎ＿ｒｅｑ信号１１２０がデアサートされる前に、ｒｘｄｉｓｃｏｎ＿ｎａｃｋ信号１１１０はデアサートされる。切断がリクエストされるとき、送信機は、（例えば、ＣＨＡＮ＿ｉｓ＿ｖａｌｉｄ ｂｉｔ ａｓｓｅｒｔｉｏｎによって示される）任意のチャネル上でそれ以上メッセージを送信しない。送信機による切断フローの開始に基づいて、受信機は、切断を確認応答するか（ＡＣＫ）、又は、否定確認応答（ＮＡＣＫ又は拒絶）するかを決定する。切断を確認応答するために、受信機は、（リンク状態インジケータ１１０５によって反映されるように）切断済み状態に入ることをマークする、（例えば、クロックサイクルｘ４において）すべてのパイプラインが空であることを確実にした後に、ｒｘｃｏｎ＿ａｃｋ信号１１１５をデアサートし得る。いくつかの事例において、受信機はまた、すべてのクレジットが返されたことを確実にし得る。
【0095】
図１２のダイアグラム１２００は、切断リクエストが受信機によって肯定確認応答された事例を示す。図１３は、受信機が否定応答（又はＮＡＣＫ）で応答する反対の例を示す。例えば、否定確認応答を送信するべく、受信機は、（例えば、クロックサイクルｘ４において）ｒｘｄｉｓｃｏｎ＿ｎａｃｋ信号１１１０を代わりにアサートし得る。例えば、他の例示的な理由の中でも特に、デッドロックのリスク無しでそのパイプラインをドレインすることが不可能であると受信機が判定した場合に、否定応答が選択され得る。ＮＡＣＫの後に、送信機は、（例えば、クロックサイクルｘ６において）ｔｘｃｏｎ＿ｒｅｑ信号１１２０を再アサートする。受信機のＮＡＣＫの、送信機によるこの有効な確認応答を観察すると、（例えば、図１３の例においてクロックサイクルｘ６に示されるように）ｒｘｄｉｓｃｏｎ＿ｎａｃｋ信号１１１０がデアサートされ得る。
【0096】
いくつかの実装において、接続及び切断フローは、開始後の数マイクロ秒以内に完了すると期待される。いくつかの実装において、明示的又は暗示的にタイムアウトが定義され得る。例えば、受信機は、定義された、又は、推奨された時間のウィンドウの中で、ＡＣＫ又はＮＡＣＫで応答するよう構成され得る。例えば、エージェント、ファブリック、又はシステム（例えば、ＳｏＣ）は、この予想を施行するためのタイムアウト又は時間ウィンドウを定義し得る。
【0097】
いくつかの事例において、ＳＦＩインタフェースが接続済み状態にある間、エージェント又はファブリック要素がリセットされ得、サプライズリセットをもたらす。例えば、定義又は推奨されるフローは、リセット前に切断に入ることであり得る。一例として、ｒｘｃｏｎ＿ａｃｋ信号が、送信機のｔｘｃｏｎ＿ｒｅｑ信号の値が１である間に、リンクの受信機側でのサプライズリセットに起因して１→０に遷移し得る。そのような場合、送信機は、それ自体を強制的に切断済み状態にし、初期化を再開し得る。これが、送信機がアイドル状態にあるときに生じる場合、メッセージの損失無しにリカバーし得る。サプライズリセットの別の例として、ｒｘｃｏｎ＿ａｃｋが１である間に、リンクの送信機側でのサプライズリセットに起因して、ｔｘｃｏｎ＿ｒｅｑ信号が１→０に遷移する場合、標準の切断フローに従い得る。これが、受信機がアイドル状態にあるときに生じる場合、送信機がリセットに留まることを条件に、切断はＡＣＫを受信し、切断済み状態にきれいに到達するはずである。しかしながら、切断が受信機によって拒絶される（ＮＡＣＫ）場合、フェイタル又は異常なリンク状態（例えば、リカバリ不能エラー）が生じ得る。サプライズリセットの場合において、トラフィックがアクティブである（例えば、アイドルでない）場合、プロトコルメッセージの損失が生じ得、継続的な正常オペレーションにフェイタルであり得る。
【0098】
上で論じられたように、システムにおけるＳＦＩインタフェースは、様々なパラメータに従って構成可能であり得る。例えば、パラメータのセットは、特定のＳｏＣ設計など、所与のシステムのユースケース、特徴、プロトコル、及びトポロジーに従って具体的に定義され得る。そのようなパラメータは、例えば、他の例示的なパラメータの中でも特に、単一サイクルにおいて送信され得るヘッダの最大数、最大ヘッダサイズ、単一サイクルにおいて送信され得る異なるパケットのペイロードの最大数を定義し得る。パラメータ値が、例えば、インタフェースを通じて接続されたエージェント及びファブリックコンポーネントによる使用及び参照のために、構成レジスタ又は他のデータ構造において定義及び保存され得る。表６は、ＳＦＩインタフェースの一例においてセットされ得る、パラメータの例を提示する。
表６：サポートされるパラメータ
エンドツーエンド暗号化のための非フリットモードトンネリング
【表6】
エンドツーエンド暗号化のための非フリットモードトンネリング
【0099】
上で紹介されるように、ＰＣＩｅ／ＣＸＬ．ｉｏリンクが非フリットモード（ＮＦＭ）にトレーニングするときでも、ＳＦＩは、ＰＣＩｅフリットモード（ＦＭ）ヘッダフォーマット及びセマンティクスを利用し得る。例えば、ＰＣＩｅフリットモードがトランザクション層パケット（ＴＬＰ）グラマーを、（１）ゼロ又はより多くの１データワード（１ＤＷ）ローカルベンダ定義ＴＬＰプレフィックス、それに続く、（２）タイプ［７：０］フィールドによって示されるサイズを有するＴＬＰヘッダベース、それに続く、ＴＬＰヘッダベースにおけるＯＨＣ［４：０］フィールドによって示される直交ヘッダ内容（ＯＨＣ）の０～７ＤＷを用いて定義し得る。（３）０～１０２４ＤＷのＴＬＰデータペイロードは、ＴＬＰヘッダベースに続き得、（４）ＴＬＰトレーラ（ヘッダベースのＴＳ［２：０］フィールドによって示されるように存在する場合）、及び、その後の（５）ゼロ又はより多くの１ＤＷエンドツーエンドサフィックスが後に続く。リンクがＮＦＭにトレーニングするとき、ＳＦＩを使用するＩ／Ｏファブリック又はインターコネクトは、トランザクション層を利用して、ＦＭ／ＮＦＭ変換を実行して、ＦＭフォーマットのみがＳＦＩを通じて搬送されることを確実にする。しかしながら、ＮＦＭ予約済みフィールドを含む、すべてのＮＦＭフィールドがＦＭ同等物マッピングを有するわけではないので、これは、（例えば、ＣＸＬ ＴＬＰインテグリティ及びデータ暗号化（ＩＤＥ）などに従って）対応するデータを暗号化する試みを妨げ得る。従来の実装において、ＩＤＥ暗号化を通じたＮＦＭ－ＮＦＭ通信が、非ストリーミングインタフェースを用いてのみ利用可能である。いくつかの実装において、他の例示的な利益の中でも特に、（例えば、インタフェースを実装する回路において実装される）ロジックは、ＳＦＩファブリックの利益を維持したまま、２つのＮＦＭトレーニングされたリンクが通信し、カットスルールーティング及びフリットモードフォーマットの受信機デコードの単純性の利益を維持しながら、パケットインテグリティを損なわないことを可能にし得る。例えば、フリットフォーマット拡張は、ＦＭヘッダ構造を通じて、ＮＦＭ固有ヘッダ情報をトンネリングするために定義され得、ＮＦＭ－ＦＭ－ＮＦＭエンドツーエンド暗号化を可能にする。これは、他の例示的特徴の中でも特に、ＦＭ同等物を有しないすべてのＮＦＭ予約済みフィールド、ＦＭ同等物を有しないすべてのＮＦＭ非予約フィールド、及び、デコードされるパケットフォーマットへの変更の宛先を適宜に通知するための新しいヒントを含み得る。
【0100】
図１４を参照すると、非フリットモード（ＮＦＭ）にトレーニングした（例えば、ＰＣＩｅエンドポイント１４１０及びＰＣＩｅエンドポイント１４１５の間の）２つのＰＣＩｅリンクを接続するためのＳＦＩベースファブリック１４０５を実装するための例示的なトポロジーの簡易ブロックダイアグラム１４００が示される。ＳＦＩパケットフォーマットは、ＰＣＩｅフリットモード（ＦＭ）パケットフォーマットに従うので、ソース（例えば、１４１０）は、ＳＦＩ２０５ａを通じて送信する前に、（例えば、ＮＦＭ－ＦＭコンバータ１４２０を使用して）ＮＦＭヘッダをＦＭフォーマットにマッピングすることを担当する。同様に、宛先（例えば、１４１５）は、ＳＦＩ２０５ｂを通じて受信されたＦＭヘッダを（例えば、ＦＭ－ＮＦＭコンバータ１４３５を使用して）ＮＦＭフォーマットに再びマッピングすることを担当する。
【0101】
従来のデバイスは、ＳＦＩベースファブリック（例えば、１４０５）を通じて別のＮＦＭデバイス（例えば、１４１５）と通信するＮＦＭデバイス（例えば、１４１０）について選択的ＩＤＥストリームをサポートしない。既存のＳＦＩ機能を通じて、すべてのＮＦＭ固有フィールドをトンネリングするために、そのようなデバイスにおいてコンバータロジック（例えば、１４２０、１４２５）が提供され得、ＳＦＩインタフェースのストリーミングの利益を維持したまま、ファブリックにデコードの複雑性を追加することなく、エンドツーエンド暗号化を可能にする。一例において、ＮＦＭ－ＦＭコンバータ回路（例えば、１４２０）が、（例えば、ＰＣＩｅ６．０又は以降において定義されるような）すべてのＮＦＭフォーマット予約フィールドを識別し、ＦＭ同等物無しですべての（例えば、ＰＣＩｅ６．０）ＮＦＭフォーマットフィールドを識別し、ＮＦＭフィールドを宛先デバイス（例えば、１４１５）へトンネリングするためにＳＦＩフォーマット拡張を定義する。
【0102】
１つの例示的な実装によれば、表７は、すべてのフォーマット及びプレフィックスについてのＰＣＩｅ６．０ＮＦＭ予約済みフィールド、及び、それらをどのようにＳＦＩフォーマットにマッピングするかを列挙する。
表７：ＳＦＩへの予約ＮＦＭフィールドのマッピング
【表7】
【0103】
同様に、表８は、ＦＭ同等物を有しない、すべてのフォーマット及びプレフィックスについてのＰＣＩｅ６．０ＮＦＭフィールド、及び、それらをどのようにＳＦＩフォーマットにマッピングするかを一例において列挙する。
表８：ＳＦＩに対する、ＦＭ同等物を有しないＮＦＭフィールドのマッピング
【表8】
【0104】
図１５Ａを参照すると、ＳＦＩを通じてＮＦＭフィールドをトンネリングするのに使用される例示的なＮＦＭプレフィックス定義が示される。表９は、例示的なＮＦＭプレフィックス１５０５において示されるフィールドの説明を含む。
表９：ＮＦＭプレフィックスにおけるフィールドの説明
【表9】
【0105】
ＳＦＩを使用して、例示的なＮＦＭパケットの追加ビットを宛先へトンネリングするために、ＮＦＭプレフィックス（例えば、新しいＰＣＩｅ ＦＭベンダ定義ローカルＴＬＰプレフィックスとして定義される）が利用され得る。例えば、トンネリングがサポートされるとき、ＳＦＩ ＮＦＭプレフィックス（例えば、１５０５）が、任意の他のローカルＴＬＰプレフィックスの後、及び、プロトコルヘッダ（例えば、ＰＣＩｅフリットモードベースヘッダ）の残りの前に挿入され得る。一例において、ＮＦＭフィールド１５０６がＮＦＭプレフィックス１５０５に含まれる。ＮＦＭフィールドが「１」の値でエンコードされるとき、ベースヘッダにおけるアドレス［１：０］位置は、（例えば、すべてのフォーマットタイプについて）ＮＦＭフォーマットと同一の定義を有する。更に、ＮＦＭ＝１であるとき、フリットについてのアドレスタイプ（ＡＴ）ビットが、ＳＦＩ ＮＦＭプレフィックス１５０５のＡＴフィールド１５０７から提供される。しかしながら、ＮＦＭフィールド１５０６が「０」でエンコードされる場合、フリットのベースヘッダ及びＯＨＣフォーマットは、定義された（例えば、ＰＣＩｅ）ＦＭフォーマットに厳密に従う。
【0106】
いくつかの実装において、新しいプレフィックスの定義に加えて、ＳＦＩにおけるＮＦＭ／ＦＭ変換が、ＰＣＩｅ６．０ＦＭフォーマットの新しいＳＦＩ固有の拡張の定義を通じて更にサポートされ得、これは、（例えば、ＮＦＭ＝１であるとき）ＮＦＭプレフィックスのＮＦＭフィールド１５０６がデータのＮＦＭフォーマットを示すときに使用され得る。例えば、図１５Ｂから図１５Ｄは、ＰＣＩｅ ＦＭ定義直交ヘッダ内容（ＯＨＣ）への例示的な拡張を示す。例えば、図１５Ｂにおいて、ＰＣＩｅ ＯＨＣ－Ａ４定義への拡張が示され、ここで、１又は複数のビット（例えば、ビット２０～２１）が、メッセージフィールドについてのＮＦＭ ＰＡＳＩＤプレフィックスからの実行リクエスト（ＥＲ）フィールド１５１２、及び、メッセージについてのＮＦＭ ＰＡＳＩＤプレフィックスからの権限モードリクエスト（ＰＭＲ）フィールド１５１４などのＮＦＭ情報を搬送するために再利用される。別の例、図１５Ｃにおいて、ＰＣＩｅ ＯＨＣ－Ａ５定義への拡張が示され、ここで、１又は複数のビット（例えば、予約ビット２９）が、ＮＦＭ完了ヘッダ予約ビット（バイト１１、ビット７）１５１６などのＮＦＭ情報を搬送するために再利用される。別の例として、図１５Ｄに示されるように、（上で論じられるものなどの）他の例の中でも特に、ＰＣＩｅ ＯＨＣ－Ｂ定義への拡張が示され、ここで、ＮＦＭ ＴＰＨプレフィックス予約フィールド（バイト３、ビット７：０）１５２２などのＮＦＭ情報を保持するために、１又は複数のビット（例えば、予約ビット７：０）が再利用される。図１６は、他の例の中でも特に、２つの６４ビットメモリ書き込みプロトコルヘッダ１６０５、１６１０から成る例示的なＳＦＩヘッダ伝送１６００を示し、その両方とも、挿入されたＮＦＭプレフィックス１５０５ａ、１５０５ｂ、及び、ベースヘッダ１６１５及びＯＨＣ－Ｂ１６２０に対する関連するＳＦＩ拡張（例えば、１６１５、１６２０、１６２５、１６３０など）を有する。
バッファレス共有／専用クレジットガスケット
バッファレス共有／専用クレジットガスケット
【0107】
上で紹介されたように、ＳＦＩは、ＳＦＩインタフェースを通じた、受信されたＳＦＩ及びＳＦＩトランスミッタの間の通信のための共有及び専用クレジットの混合をサポートし得る。共有バッファを実装し、ブロックサイズオペレーションで動作してＳＦＩのストリーミングの利益を利用するＳＦＩ受信機は、いくつかの実装において、クレジットを共有できず代わりに専用クレジットに排他的に依存するＳＦＩトランスミッタとペア形成し通信し得る。そのような状況に対処するために、格納及び転送アプローチが試みられ得るが、そのような解決手段は両方とも、エリア及びレイテンシの観点からコストが高い（例えば、フロー制御（ＦＣ）又は仮想チャネル（ＶＣ）のサポートされるすべての組み合わせのために、少なくとも最小限のパケットサイズのサイズを有するクレジットを格納し転送する）。例えば、ＰＣＩｅにおいて、６種類の情報（例えば、ポステッドリクエストヘッダ（ＰＨ）；ポステッドリクエストデータペイロード（ＰＤ）；ノンポステッドリクエストヘッダ（ＮＰＨ）；ノンポステッドリクエストデータペイロード（ＮＰＤ）；完了ヘッダ（ＣｐｌＨ）；及び完了データペイロード（ＣｐｌＤ））が、各仮想チャネルについてのフロー制御によって追跡され得、その結果、各ＶＣについて６のＦＣ／ＶＣの組み合わせをもたらす。
【0108】
改善された実装において、軽量クレジット変換ガスケット（例えば、ＳＦＩインタフェースを実装するデバイスの回路において実装される）が提供され得、バッファレスであり、かつ、アンチスタベーション制御、及び、ＱｏＳ及び帯域幅形成アルゴリズムを、実装しながら、受信機から送信機への専用クレジットへの共有クレジットプール変換を管理する。例えば、ＳＦＩ受信機は、共有クレジットをクレジットガスケットロジックにアドバタイズし得る。クレジットガスケットは、受信機からのクレジットリターンを累積し、望ましいレベルのリンク利用を実現するために送信機における有効化された各ＦＣ／ＶＣによって必要とされるクレジットを追跡し得る。クレジットガスケットは、受信機占有を識別及び考慮し、アンチスタベーション保護のためにＦＣ／ＶＣ粒度で専用クレジットリターンをスロットルし得る。ブロックサイズにおける受信機クレジットを追跡及びアサインすることによって、クレジットガスケットは、ストレージの必要性を無くし、ヘッダ／データレイテンシへの影響を最小化し得る。リンク利用率モニタリングも、クレジットアサインを調整し、動的帯域幅割り当てを制御するために使用され得、受信機ストレージ要件を低減する。そのような解決手段が、エリア、レイテンシコスト、及び実装複雑性を最小化しながら、変動するクレジット機能のエージェントとの通信における柔軟性を提供するために、受信機についてのプラグアンドプレイ拡張として提供され得る。
【0109】
図１７は、例示的なＳＦＩ受信機（例えば、ＳＦＩエージェントＢ１７１０）及びＳＦＩトランスミッタ（例えば、ＳＦＩエージェントＡ１７０５上）の間のギャップを橋渡しし得る、ＳＦＩ準拠クレジットガスケット１７１５を有する例示的トポロジーを示す簡易ブロックダイアグラム１７００であり、ここで、送信機は、格納及び転送のための高コストのバッファの使用を回避しながら、（例えば、リンク上で実装される各ＦＣ／ＶＣの組み合わせについての専用クレジットプールを用いて）専用クレジットをサポートするだけである。いくつかの実装におけるクレジットガスケット１７１５は、（例えば、ＳＦＩエージェントＢ１７１０上で）対応するＳＦＩ受信機を実装するために使用されるものとは別個の回路ブロックとして実装され得、ＳＦＩに基づいて共有クレジットインタフェース１７２０を使用してエージェントブロック１７１０に結合し得る。他の実装において、クレジットガスケット１７１５ロジックが、受信機自体に実装され得る（例えば、結合された、対応するＳＦＩインタフェース１７１５を通じて通信する送信機の機能に基づいて有効化／無効化される）。クレジットガスケット１７１５は、ＳＦＩにおける共有クレジットレジーム及び専用クレジットレジームの間の変換ツールとして作用し得る。したがって、クレジットガスケット１７１５は、（ＳＦＩに基づいて）専用クレジットインタフェース１７２０を使用して専用クレジットをサポートするだけである送信機とインタフェースし得る。クレジットガスケット１７１５は、対応するＳＦＩ受信機（例えば、１７１０）から、共有されたクレジットリターンを受け付け、これら共有されたクレジットリターンを専用クレジットリターンに変換することを管理し、次に、ＳＦＩトランスミッタ（例えば、１７０５）に対応して、変換された専用クレジットをその有効化されたＦＣ／ＶＣの組み合わせに分配し得る。
【0110】
クレジットガスケット１７１５は、プログラム可能インタフェースを（例えば、システムソフトウェア又はファームウェアに）公開し、クレジットガスケットが、ＳＦＩトランスミッタにおけるどのＦＣ／ＶＣの組み合わせがアクティブであるか、及び、いくつの専用クレジットが各々（例えば、ＨＤＲ及びデータ層についてのクレジット）にそれぞれ割り当てられるべきかを通知されることを可能にし得る。割り当てられた専用クレジットの数は、他の例示的な考慮事項の中でも特に、各ＦＣ／ＶＣに望ましいリンク利用率、及び、リンクの遅延特性に依存し得る。例えば、単純化した例として、他の（潜在的に遥かに複雑な）例の中でも特に、１つのＦＣ／ＶＣのみが、４サイクルのクレジットループレイテンシを伴い、追加の制約を伴わず、サイクルあたり２つのヘッダを送信するよう構成されるＳＦＩリンクについてアクティブである場合、ガスケットは、そのＦＣ／ＶＣについて８の専用クレジットを追跡するよう構成される。
【0111】
専用クレジットへの共有クレジットの変換を促進するべく、他の例示的な情報の中でも特に、クレジットガスケット１７１５は、各ＦＣ／ＶＣについて、各ＦＣ／ＶＣのクレジット不足分及び保留中のクレジットリターンを、残りの共有クレジットプールのサイズと共に、追跡し得る。クレジット「不足分（ｄｅｆｉｃｉｔ）」は、所与のＦＣ／ＶＣにいくつのクレジットを提供するべきかを追跡するためにクレジットガスケットが使用する機構であり、ＦＣ／ＶＣによって現在要求されているクレジットと、割り当てられているものの差に関する。不足分が満たされると、（別の不足分が識別されるまで）他のクレジットはアサインされるべきでない。所与のＦＣ／ＶＣについて不足分が増加するとき、クレジットガスケットは、以前に又は元々割り当てられていたものより多くのクレジットがＦＣ／ＶＣに割り当てられるべきであると判定する。一例において、クレジットガスケット１７１５は、カウンタをプログラムされた値に初期化し、次に、そのＦＣ／ＶＣの組み合わせについて、すべてのクレジットリターンに対してデクリメントし、すべての有効ＳＦＩヘッダ又はデータ伝送に対してインクリメントすることによって、このＦＣ／ＶＣあたりの不足分を追跡する。
【0112】
例えば、図１８は、例示的な送信機１７０５及び受信機１７１０の間に配置されたクレジットガスケット１７１５の関与の例を示すタイミングダイアグラム１８００であり、ここで、送信機は、専用クレジットをサポートするだけであり、クレジットガスケットは、有効ＳＦＩ伝送に基づいて不足分を追跡する。例えば、送信機１７０５は、ＦＣ／ＶＣ［１］［２］についての第２ペアのヘッダ（例えば、１８１５、１８２０）が後に続くＦＣ／ＶＣ［１］［０］についての第１ペアのヘッダ（例えば、１８０５、１８１０）を送信し得る。クレジットガスケットは、ＳＦＩ Ａ１７０５からＳＦＩ Ｂ１７１０へのヘッダ１８０５、１８１０の送信を検出し、［１］［０］に割り当てられたものに対してクレジットの数（例えば、２クレジット）をカウントし（１８２５）、ヘッダ１８１５、１８２０の送信を同様に識別し、［１］［２］について割り当てられたものに対して、使用されるクレジットの数（例えば、２クレジット）をカウントする（１８３０）。ＦＣ／ＶＣ［１］［１］についてのヘッダクレジットを利用して送信が検出されていないので、ＦＣ／ＶＣ［１］［１］についてのクレジットトラッカに調整が行われない（１８３５）。いくつかの実装において、ＳＦＩ信号は、共有又は専用クレジットが使用されるかどうかを識別するための信号を含み得る。送信機１７０５は、（例えば、ｈｄｒ＿ｉｎｆｏ＿ｂｙｔｅｓ［１］（１８４０）において）情報を有するヘッダを送信して、専用クレジットを使用していることを示すので、クレジットガスケット１７１５は、受信機１７１０に配送される前にヘッダ情報を修正し得、代わりに、共有クレジットが使用されていることを示す（それにより、受信機が、送信機によって使用される専用クレジットレジーム、又は、クレジットガスケットによるクレジットレジームの操作と関係なく動作することを可能にする）。例えば、一例において、ＳＦＩ定義ｈｄｒ＿ｉｎｆｏ＿ｂｙｔｅｓの「ヘッダ使用共有クレジット」ビットは、専用又は共有クレジットが使用されるかどうかを示し得る。この場合、クレジットガスケットは、他の例の中でも特に、ＳＦＩ受信機１７１０の上流へ信号を転送する前に、「専用」を示す値（例えば、ｈｄｒ＿ｉｎｆｏ＿ｂｙｔｅｓ「０ｘ８１４０」）から、「共有」を示す別の値（例えば、ｈｄｒ＿ｉｎｆｏ＿ｂｙｔｅｓ「０ｘＡ１４０」）に「ヘッダ使用共有クレジット」ビットを反転させ得る。
【0113】
上に記載されたように、クレジットガスケット１７１５は、各ＦＣ／ＶＣの組み合わせに最初に割り当てられたクレジットの数を識別し、ＦＣ／ＶＣがクレジット不足分に属するかどうかを継続的にモニタリングし得る。例えば、任意のＦＣ／ＶＣの組み合わせが、プログラムに基づいて、不足していると判定される場合、クレジットガスケットは次に、クレジットの追加のブロックサイズのチャンクをアサインすることによって、クレジットアサインを調停するように作用し得る。図１９Ａの例において、アクティブＦＣ／ＶＣについての不足分がブロックサイズより小さいシナリオが示され、１９３５において余分なクレジットが（共有プールカウンタ１９３０によって追跡されるように）共有プールからリターン保留中カウンタ１９２５にアサインされていることを示す。例えば、図１９Ａのタイミングダイアグラム１９００ａに示されるように、受信機（例えば、１７１０）は、複数のクレジットリターン（例えば、１９０５）を送信し得、クレジットガスケット１７１５は、クレジットリターンを識別し、最初に、クレジットを（共有クレジットプールカウンタ１９２５を使用して追跡されるように）共有クレジットプールに返し得る。ＦＣ／ＶＣの専用クレジットプールが（対応するクレジット不足分カウンタ（例えば、１９２０など）と共に）調整されるとき、クレジット不足分条件が、（例えば、１９１８において）クレジットガスケットによってＦＣ／ＶＣについて識別され得る。クレジット不足分は、クレジット割り当ての初期化又は調整に起因して、又は、送信機が有効パケットを送信する（そして、クレジットガスケットは、それらのクレジットを補充するべきであると認識する）ことに起因して発生し得る。共有プールからのクレジットは、不足分（例えば、（１９２２において）１クレジット）を補うべく、再割り当てされ得る。不足分が満たされた後に、ブロックサイズのチャンクから任意の過剰なクレジットが残っている場合、これらは、特定のＦＣ／ＶＣ（例えば、ＦＣ／ＶＣ［１］［２］）にアサインされたが、ＳＦＩトランスミッタ１７０５にまだ返されていない共有クレジットを追跡する別個のリターン保留中カウンタ１９２５に格納され得る。より多くの共有クレジットリソースを消費するように調停する前に、その特定のＦＣ／ＶＣについての未来の不足分は、リターン保留中カウンタからクレジットを消費し得る。
【0114】
図１９Ｂを参照すると、例示的なクレジットガスケット１７１５を使用する、例示的なクレジット初期化及びリリースを示すタイミングダイアグラム１９００ｂが示される。例えば、初期化中に、ＳＦＩ受信機１７１０は、ＳＦＩ仕様において説明されるものなどのＳＦＩによって予約されたＦＣ／ＶＣの組み合わせを使用して、共有クレジットをアドバタイズする。クレジットガスケットは、このアドバタイズメントをインターセプトし、これらのリターンを使用して内部共有クレジットプールをインクリメントする（１９４０）。例えば、図１９Ｂの例において、初期化中の例示的なクレジット交換（例えば、最初の４０クレジット（例えば、「０ｘ１０」クレジットリターンの４ｘサイクル））が、後続のリリースと共に、専用クレジットとして示される（例えば、８クレジット不足分をカバーするために、２つの連続するサイクルで４クレジットをアドバタイズする）。初期化後、共有クレジットリターンがまず、ＳＦＩブロックサイズのチャンクにおけるクレジットを収集することを目的とするＦＣ／ＶＣあたりのアキュムレータにインクリメントされる。ブロックサイズのチャンクが収集されると、ガスケットは、ＦＣ／ＶＣが不足しているかどうかをチェックする。不足している場合、クレジットのブロックサイズのチャンクは、クレジットをそのＦＣ／ＶＣリターン保留中カウントに追加することによってＦＣ／ＶＣに直接アサインされる。不足していない場合、クレジットは、プログラム可能マッピングを使用して内部共有クレジットプールをインクリメントするために使用され、ＦＣ／ＶＣの組み合わせを共有プールに変換する。
【0115】
図２０を参照すると、クレジットガスケットの実装内の例示的論理フローを示す簡易ブロックダイアグラム２０００が示される。第１インタフェース２００５は、専用クレジットドメインを実装して、専用クレジットをサポートするだけである送信機を有するエージェントとインタフェースし得る。第２インタフェース２０１０は、共有クレジットドメインを実装して、共有クレジット（及び、潜在的に共有及び専用クレジットの混合）をサポートする受信機を有するエージェントとインタフェースし得る。クレジット変換ロジック２０１５は、専用クレジットレジーム及び共有クレジットレジームの間でクレジットがどのように変換されるかを決定し得る。クレジット変換ロジック２０１５は、クレジットリターン調停ロジック２０２０を含み得、これは、受信機の共有クレジットプールから、送信機によって理解される（及びクレジットガスケットによって仮想化される）ような潜在的な複数のＦＣ／ＶＣの組み合わせの専用クレジットプールへのクレジットのプロビジョニングを調停するために利用され得る。ヘッダなどの伝送は、クレジットガスケットにおける送信機から受信され得（２０２５）、専用クレジットが適用されることを示し得る。クレジットガスケットは、ＳＦＩインタフェースの適切なチャネルを通じて受信機へ転送する前に（２０３２）、そのようなフィールドを上書きし得（２０３０）、代わりに、共有クレジットが使用されることを受信機に示す。追加的に、データ伝送を受信すると、データ伝送のサイズ（及びデータ伝送のＦＣ／ＶＣ）に応じて、クレジットガスケットは、データ伝送に使用されるクレジットの数だけ不足分を増加させることによって、その特定のＦＣ／ＶＣについて追跡されるクレジット不足分を更新し得る２０３５。この更新に基づいて、クレジットガスケットは、ＦＣ／ＶＣ専用プールが不足の位置にあるか又は無いかを判定し得る（２０４０）。
【0116】
引き続き図２０の例において、受信機は、クレジットガスケットによって変換され送信機へ転送される（２０５０）クレジットリターンを発行し得る（２０４５）。クレジットが受信機によって返されるとき、クレジットリターンアキュムレータが、返されたクレジットの数に基づいてインクリメントされる。ＦＣ／ＶＣについてブロックサイズが（例えば初期化中に）決定され得、クレジットガスケットは、クレジットの数がブロックサイズより大きい又はそれに等しいかどうかを判定し得る（２０６０）。ＦＣ／ＶＣについて累積されたクレジットがブロックサイズより大きい場合、クレジットガスケットは次に、ＦＣ／ＶＣが不足している、又はそうでないかを判定する（２０４０）。ＦＣ／ＶＣが不足している場合、返されたクレジット（例えば、ブロックサイズ閾値の上）がクレジットリターン保留中カウンタをインクリメントする（２０６５）ために使用される（発行されたＦＣ／ＶＣへのリターンを待っているクレジットの数を示す）。しかしながら、ＦＣ／ＶＣが不足していない場合、これは、ＦＣ／ＶＣの使用中の状態を示し得、結果として、クレジットは代わりに、共有プール（カウンタはそれに従ってインクリメントされる（２０７０））へ再び割り当てられる。
【0117】
いくつかの実装において、クレジットガスケットは、クレジットガスケットカウンタのステータスを評価するために、構成可能なクレジットリターンアービトレータ２０２０を含み得、送信機によってサポートされる様々なＦＣ／ＶＣの組み合わせに対するクレジットの発行を調停し、受信機によってサポートされる共有クレジットプールが効率的方式で動的に割り当てられることを確実にする。例えば、クレジットリターンアービトレータ２０２０は、例えば、ＦＣ／ＶＣのクレジット不足分カウンタへの更新が発生するとき、保留中リターンクレジットカウンタ（２０７５）及び共有プールカウンタ（２０８０）から、クレジットリターンを再び送信機へ発行するかどうかを決定し得る（２０８５）。クレジットリターンアービトレータ２０２０は、他の例示的な実装の中でも特に、クレジットリターンを承諾する（２０５０）か、又は代わりに、ＦＣ／ＶＣに割り当てられたものからクレジットを引き戻す（２０３５）かを決定し得る。クレジットリターンアービタ２０２０は、ハードウェア回路において実装され得、他の例示的な実装の中でも特に、ソフトウェア又はファームウェアが、クレジットガスケットによってクレジットリターンをどのように調停するかを決定する上でクレジットリターンアービタ２０２０によって利用されるアルゴリズムを構成できるインタフェースを提供し得る。
【0118】
いくつかの実装において、有効化されたＦＣ／ＶＣについての初期化された不足分は、デッドロック回避のために、少なくとも完全に１つのパケットをカバーするべきであり（例えば、１ヘッダクレジット、最大ペイロードサイズ（ＭＰＳ）サイズデータクレジット）、（例えば、ソフトウェアによって命令されるように）静的又は動的であり得る。静的な場合において、初期化された不足分は、望ましいリンク利用率を実現するために必要な程度に高くセットされるべきである。複数のＦＣ／ＶＣの組み合わせがアクティブである場合、これは、受信機についてのより大きいストレージ需要をもたらし得る。これは、ＦＣ／ＶＣあたりのアクティビティが均一でない場合に程度を増し得、いくつかのＦＣ／ＶＣの組み合わせは、高アクティビティの期間及び低アクティビティの期間を経験する。これを緩和するべく、いくつかの実装において、クレジットガスケットは、ＦＣ／ＶＣアクティビティに応じて、追跡されたクレジット不足分を経時的に動的に調整し、受信機ストレージ需要を低減し、エリアを削減し得る。これは、アクティブＦＣ／ＶＣの間の動的なクレジット及び帯域幅割り当てを可能にする。このシナリオにおいて、不足分は、リセットにおけるＭＰＳサイズのパケットをカバーするためだけに初期化され、初期トラフィックフローを可能にする。リンクが（例えば、構成可能時間ウィンドウにおける所与のＦＣ／ＶＣからの有効なパケットの数をカウントすることによって検出される）ＦＣ／ＶＣによって使用されるとき、クレジットガスケットは、不足分を維持、増加、又は減少させることを選択し得る。ＦＣ／ＶＣからのアクティビティの増加に起因して不足分が増加する場合、より多くの共有プールクレジットリソースをＦＣ／ＶＣにアサインされるクレジットガスケット調停をもたらし得る。ＦＣ／ＶＣからアクティビティの低減に起因して不足分が減少する場合、クレジットガスケットが、ＦＣ／ＶＣにアサインされたクレジットの数を低減することをもたらす。例えば、図２１に示されるタイミングダイアグラム２１００は、ＦＣ／ＶＣからのアクティビティの増加に起因する不足分増加シナリオを示す。例えば、ＦＣ／ＶＣ［１］［０］上のより高いトラフィックを検出することに基づいて、クレジットガスケットは、不足分を増加させることによってクレジット割り当てを増加させ得（２１０５）、これにより、より高い数のクレジットが送信機へ返され、それによって使用されることを可能にし得る。
【0119】
クレジットが最初に所与のＦＣ／ＶＣに過剰に割り当てられたとクレジットガスケットが判定する場合、不足分低減を受けているＦＣ／ＶＣに既にリリースされた任意のクレジットは、既存のＳＦＩ機構によって取得できない。実装が、低減されたＦＣ／ＶＣからの未来のパケット伝送を保証する場合、そのクレジット低減を単純に追跡し、それを未来のクレジットリターンから控除することを選択し得る。代替的に、クレジットは、ＳＦＩの拡張を用いて、異なる方式でオンデマンドで取得され得る。例えば、受信機－送信機プル（ｐｕｌｌ）は、ＳＦＩに追加される新しい信号を組み込み、受信機が送信機からクレジットを戻すようにリクエストすること、及び、送信機がプル（又は低減）を確認応答することを可能にするために定義され得る。一例において、図２２Ａの例に示されるように、受信機１７１０は、既存のＳＦＩクレジットリターンワイヤ２２０５（例えば、＊ｆｃ＿ｉｄ、＊ｖｃ＿ｉｄ、＊ｖａｌｕｅ、＊ｄｅｄなど）を再利用して、（例えば、既存の＊ｃｒｄ＿ｒｔｎ＿ｖａｌｉｄの代わりに）新しい＊ｃｒｄ＿ｒｔｎ＿ｐｕｌｌ信号をアサートすることによって、前にアドバタイズされたクレジットを取り戻すことを希望することを送信機１７０５にシグナリングし得る（２２１０）。送信機１７０５は、プルが成功である場合は（例えば、信号２２２０を使用して）確認応答で、又は、失敗である場合は（例えば、信号２２２５を使用して）拒絶で、プルリクエスト２２１０に応答し得る。成功の確認応答時に（例えば、２２３０）、受信機１７１０は、前にアサインされたクレジットを取り戻し、それらを必要に応じて再アサインし得る。失敗又は拒絶の応答時に、受信機は、クレジットを再アサインできず、条件がなお適用する場合、後の時間にプルを再試行することを選択し得る。例えば、図２２Ｂの例において、受信機は、送信機１７０５が最初に拒絶し得る（２２４０）クレジット割り当て解除をリクエストし得る（２２３５）が、後に再試行し得る（２２４５）。この第２クレジット割り当て解除リクエスト２２４５は次に、送信機によって確認応答され得（２２５０）、受信機１７１０が次にクレジット（ｓ）を正常に取り戻すことを可能にする。表１０は、受信クレジットプルを促進するために利用され得る例示的なＳＦＩ信号を示す。
表１０：例示的なクレジットプル信号
【表10】
【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】
例３２は、例３１の主題を含み、ここで、前記Ｉ／Ｏインターコネクトプロトコルは、ペリフェラルコンポーネントインターコネクトエクスプレス（ＰＣＩｅ）ベースプロトコル又はコンピュートエクスプレスリンク（ＣＸＬ）ベースプロトコルの１つを含む。
【0198】
例３３は、例２９～３２のいずれか１つの主題を含み、ここで、前記インタフェースは、
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、前記レーンの第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるＤＡＴＡチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される。
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、前記レーンの第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるＤＡＴＡチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される。
【0199】
例３４は、例２９～３３のいずれか一項の主題を含み、ここで、フリットモード及び非フリットモードはＰＣＩｅベースのプロトコルに基づく。
【0200】
例３５は、例３４の主題を含み、ここで、前記１又は複数の非フリットモードフィールドは、マッピングに基づいて、前記フリットモードヘッダフォーマットのセットの前記１又は複数のフィールドにおいて搬送される。
【0201】
例３６は、例３４～３５のいずれか１つの主題を含み、ここで、前記フリットモードヘッダフォーマットのセットは、１又は複数の直交内容ヘッダを含み、前記１又は複数の直交内容ヘッダの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する。
【0202】
例３７は、例３４～３６のいずれか１つの主題を含み、ここで、前記フリットモードヘッダフォーマットのセットは、１又は複数のプレフィックスを含み、前記１又は複数のプレフィックスの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する。
【0203】
例３８は、例３７の主題を含み、ここで、前記特定のプレフィックスは、前記対応するパケットが非フリットモードパケットとして生じたことを示すためのモードフィールドを含む。
【0204】
例３９は、例３４～３８のいずれか一項の主題を含み、ここで、エンドツーエンド暗号化は、フリットモードに基づいてリンク上で提供される。
【0205】
例４０は、例３４～３９のいずれか一項の主題を含み、ここで、インタフェースは、ストリーミングファブリックインタフェース（ＳＦＩ）仕様に基づく。
【0206】
本明細書の全体にわたって、「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）」又は「実施形態（ａｎ ｅｍｂｏｄｉｍｅｎｔ）」への言及は、当該実施形態に関連して説明される特定の特徴、構造又は特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書を通して様々な箇所における「１つの実施形態において」又は「一実施形態において」という表現の出現は、必ずしもすべてが同一の実施形態を指すとは限らない。さらに、特定の特徴、構造又は特性は、１又は複数の実施形態において、任意の好適な態様で組み合わされてよい。
【0207】
上記の明細書において、詳細な説明が、特定の例示的な実施形態を参照して行われた。
しかしながら、添付の特許請求の範囲で説明されたより広い精神及び範囲から逸脱することなく、多様な修正及び変更をそれらに行ってよいことは明白であろう。従って、本明細書及び図面は、限定的な意味ではなく、例示的な意味で考えられるべきである。更に、実施形態及び他の例示的な言語の上記の使用は、必ずしも同じ実施形態又は同じ例を指しているとは限らず、異なる個別の実施形態及び潜在的に同じ実施形態を指してよい。
他の可能な項目
（項目１）
入出力（Ｉ／Ｏ）インターコネクトプロトコルを実装するためのプロトコル回路、ここで、前記Ｉ／Ｏインターコネクトプロトコルは、フリットモード及び非フリットモードを含み、ここで、前記フリットモードのときにフリットモードヘッダフォーマットのセットが使用され、前記非フリットモードのときに非フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードヘッダフォーマットのセットは、１又は複数の非フリットモードフィールドを含む；及び
ファブリックに結合するためのインタフェースを実装するためのインタフェース回路、ここで、前記インタフェース回路は、
前記非フリットモードに対してリンクがトレーニングされると決定し；
前記フリットモードヘッダフォーマットのセットに従ってヘッダを生成し、ここで、前記ヘッダは、対応するパケットが非フリットモードパケットとして生じたことを示すためのフィールドを含み、前記フリットモードヘッダフォーマットのセットの１又は複数のフィールドは、前記１又は複数の非フリットモードフィールドを搬送するために前記ヘッダにおいて再利用され；及び
前記インタフェースを通じて前記ヘッダを送信する、
を備える装置。
（項目２）
前記１又は複数の非フリットモードフィールドは、前記フリットモードヘッダフォーマットのセットに含まれない、項目１に記載の装置。
（項目３）
前記Ｉ／Ｏインターコネクトプロトコルは、ロード／ストアインターコネクトプロトコルを含む、項目１に記載の装置。
（項目４）
前記Ｉ／Ｏインターコネクトプロトコルは、ペリフェラルコンポーネントインターコネクトエクスプレス（ＰＣＩｅ）ベースプロトコル又はコンピュートエクスプレスリンク（ＣＸＬ）ベースプロトコルの１つを含む、項目３に記載の装置。
（項目５）
前記インタフェースは：
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、レーンの前記第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるデータチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される、項目１に記載の装置。
（項目６）
前記フリットモード及び前記非フリットモードは、ＰＣＩｅベースのプロトコルに基づく、項目１に記載の装置。
（項目７）
前記１又は複数の非フリットモードフィールドは、マッピングに基づいて、前記フリットモードヘッダフォーマットのセットの前記１又は複数のフィールドにおいて搬送される、項目６に記載の装置。
（項目８）
前記フリットモードヘッダフォーマットのセットは、１又は複数の直交内容ヘッダを含み、前記１又は複数の直交内容ヘッダの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する、項目６に記載の装置。
（項目９）
前記フリットモードヘッダフォーマットのセットは、１又は複数のプレフィックスを含み、前記１又は複数のプレフィックスの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する、項目６に記載の装置。
（項目１０）
前記特定のプレフィックスは、前記対応するパケットが非フリットモードパケットとして生じたことを示すためのモードフィールドを含む、項目９に記載の装置。
（項目１１）
エンドツーエンド暗号化が前記フリットモードに基づいて前記リンク上で提供される、項目１に記載の装置。
（項目１２）
前記インタフェースは、ストリーミングファブリックインタフェース（ＳＦＩ）仕様に基づく、項目１に記載の装置。
（項目１３）
パケットのヘッダを識別する段階、ここで、前記パケットの前記ヘッダは、ロード／ストアインターコネクトプロトコルの非フリットモードフォーマットに基づき、前記ロード／ストアインターコネクトプロトコルは更にフリットモードを定義し；
前記パケットの前記ヘッダのフリットモードバージョンを生成する段階、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンは、フリットモードフォーマットに基づき、前記非フリットモードフォーマットにおける第１サブセットのフィールドがまた、前記フリットモードフォーマットにおいて提供され、前記非フリットモードフォーマットにおける第２サブセットのフィールドが、前記フリットモードフォーマットにおいて除外され、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンを生成することは、前記フリットモードフォーマットにおいて定義される再利用フィールドにおいて、前記第２サブセットのフィールドにおける１又は複数のフィールドを搬送することを含み；
インタフェースを通じて、前記パケットの前記ヘッダの前記フリットモードバージョンをファブリックへ送信する段階、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンは、第１の複数の物理レーン上で実装されるヘッダチャネル上で送信される；及び
前記インタフェースを通じて、前記パケットのペイロードデータを前記ファブリックへ送信する段階、ここで、前記パケットの前記ペイロードデータは、別個の第２の複数の物理レーン上で実装されるデータチャネル上で送信される、
を備える方法。
（項目１４）
前記インタフェースは、ＳＦＩ仕様に従って定義され、前記ロード／ストアプロトコルは、ＰＣＩｅ又はＣＸＬ．ｉｏの１つを含む、項目１３に記載の方法。
（項目１５）
前記パケットの前記ヘッダの前記フリットモードバージョンは、前記第１の複数の物理レーンの第１サブセット上で送信され、前記方法は、
前記ヘッダチャネルの前記第２の複数の物理レーンの第２サブセットを使用して、前記インタフェース上でヘッダメタデータを送信する段階
を備える、項目１３に記載の方法。
（項目１６）
ファブリック；及び
前記ファブリックを通じて通信可能に結合される複数のコンピュートブロック、ここで、前記複数のコンピュートブロックにおける特定のコンピュートブロックは：
ロード／ストアインターコネクトプロトコルをサポートするエージェント回路、ここで、前記ロード／ストアプロトコルはフリットモード及び非フリットモードをサポートし、前記フリットモードのとき、フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードのとき、非フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードヘッダフォーマットのセットは、１又は複数の非フリットモードフィールドを含み；及び
前記ファブリックに結合するためのインタフェースを実装するためのインタフェース回路、ここで、前記インタフェース回路は：
リンクが前記非フリットモードに対してトレーニングされると決定し；
前記フリットモードヘッダフォーマットのセットに従ってヘッダを生成し、ここで、前記ヘッダは、対応するパケットが非フリットモードパケットとして生じたことを示すためのフィールドを含み、前記フリットモードヘッダフォーマットのセットの１又は複数のフィールドは、前記１又は複数の非フリットモードフィールドを搬送するために前記ヘッダにおいて再利用される；及び
前記インタフェースを通じて前記ヘッダを送信する
を含む、
を備えるシステム。
（項目１７）
前記インタフェース上の１対多接続を促進するためのバッファレスアービタを更に備える、項目１６に記載のシステム。
（項目１８）
前記コンピュートブロックの第１のものにおいて送信機によって使用される専用クレジットを、前記コンピュートブロックの第２のものにおいて受信機によって使用される共有クレジットに変換するためのクレジットガスケットを更に備える、項目１６に記載のシステム。
（項目１９）
前記ファブリックは、システムオンチップ（ＳｏＣ）デバイスのインターコネクトファブリックを含み、前記ＳｏＣデバイスは、前記複数のコンピュートブロックを含む、項目１６に記載のシステム。
（項目２０）
前記インタフェースは、パケットヘッダを通信するための専用物理レーンのセットを含むヘッダチャネルを含み、前記フリットモードは、前記ヘッダチャネル上で通信されるヘッダのために使用される、項目１６に記載のシステム。
しかしながら、添付の特許請求の範囲で説明されたより広い精神及び範囲から逸脱することなく、多様な修正及び変更をそれらに行ってよいことは明白であろう。従って、本明細書及び図面は、限定的な意味ではなく、例示的な意味で考えられるべきである。更に、実施形態及び他の例示的な言語の上記の使用は、必ずしも同じ実施形態又は同じ例を指しているとは限らず、異なる個別の実施形態及び潜在的に同じ実施形態を指してよい。
他の可能な項目
（項目１）
入出力（Ｉ／Ｏ）インターコネクトプロトコルを実装するためのプロトコル回路、ここで、前記Ｉ／Ｏインターコネクトプロトコルは、フリットモード及び非フリットモードを含み、ここで、前記フリットモードのときにフリットモードヘッダフォーマットのセットが使用され、前記非フリットモードのときに非フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードヘッダフォーマットのセットは、１又は複数の非フリットモードフィールドを含む；及び
ファブリックに結合するためのインタフェースを実装するためのインタフェース回路、ここで、前記インタフェース回路は、
前記非フリットモードに対してリンクがトレーニングされると決定し；
前記フリットモードヘッダフォーマットのセットに従ってヘッダを生成し、ここで、前記ヘッダは、対応するパケットが非フリットモードパケットとして生じたことを示すためのフィールドを含み、前記フリットモードヘッダフォーマットのセットの１又は複数のフィールドは、前記１又は複数の非フリットモードフィールドを搬送するために前記ヘッダにおいて再利用され；及び
前記インタフェースを通じて前記ヘッダを送信する、
を備える装置。
（項目２）
前記１又は複数の非フリットモードフィールドは、前記フリットモードヘッダフォーマットのセットに含まれない、項目１に記載の装置。
（項目３）
前記Ｉ／Ｏインターコネクトプロトコルは、ロード／ストアインターコネクトプロトコルを含む、項目１に記載の装置。
（項目４）
前記Ｉ／Ｏインターコネクトプロトコルは、ペリフェラルコンポーネントインターコネクトエクスプレス（ＰＣＩｅ）ベースプロトコル又はコンピュートエクスプレスリンク（ＣＸＬ）ベースプロトコルの１つを含む、項目３に記載の装置。
（項目５）
前記インタフェースは：
複数の物理レーンの第１サブセット上に実装されるヘッダチャネル、ここで、レーンの前記第１サブセットは、前記インターコネクトプロトコルに基づいてパケットヘッダを搬送するための第１レーン、及び、前記パケットヘッダについてのメタデータを搬送するための第２レーンを含む；及び
前記複数の物理レーンの別個の第２サブセット上に実装されるデータチャネル、ここで、レーンの前記第２サブセットは、パケットペイロードを搬送するための第３レーン、及び、前記パケットペイロードについてのメタデータを搬送するための第４レーンを含む、
を含み、
ここで、前記ヘッダは前記ヘッダチャネルを通じて送信される、項目１に記載の装置。
（項目６）
前記フリットモード及び前記非フリットモードは、ＰＣＩｅベースのプロトコルに基づく、項目１に記載の装置。
（項目７）
前記１又は複数の非フリットモードフィールドは、マッピングに基づいて、前記フリットモードヘッダフォーマットのセットの前記１又は複数のフィールドにおいて搬送される、項目６に記載の装置。
（項目８）
前記フリットモードヘッダフォーマットのセットは、１又は複数の直交内容ヘッダを含み、前記１又は複数の直交内容ヘッダの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する、項目６に記載の装置。
（項目９）
前記フリットモードヘッダフォーマットのセットは、１又は複数のプレフィックスを含み、前記１又は複数のプレフィックスの特定の１つにおける特定のフィールドは、前記１又は複数の非フリットモードフィールドにおける特定のフィールドを保持する、項目６に記載の装置。
（項目１０）
前記特定のプレフィックスは、前記対応するパケットが非フリットモードパケットとして生じたことを示すためのモードフィールドを含む、項目９に記載の装置。
（項目１１）
エンドツーエンド暗号化が前記フリットモードに基づいて前記リンク上で提供される、項目１に記載の装置。
（項目１２）
前記インタフェースは、ストリーミングファブリックインタフェース（ＳＦＩ）仕様に基づく、項目１に記載の装置。
（項目１３）
パケットのヘッダを識別する段階、ここで、前記パケットの前記ヘッダは、ロード／ストアインターコネクトプロトコルの非フリットモードフォーマットに基づき、前記ロード／ストアインターコネクトプロトコルは更にフリットモードを定義し；
前記パケットの前記ヘッダのフリットモードバージョンを生成する段階、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンは、フリットモードフォーマットに基づき、前記非フリットモードフォーマットにおける第１サブセットのフィールドがまた、前記フリットモードフォーマットにおいて提供され、前記非フリットモードフォーマットにおける第２サブセットのフィールドが、前記フリットモードフォーマットにおいて除外され、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンを生成することは、前記フリットモードフォーマットにおいて定義される再利用フィールドにおいて、前記第２サブセットのフィールドにおける１又は複数のフィールドを搬送することを含み；
インタフェースを通じて、前記パケットの前記ヘッダの前記フリットモードバージョンをファブリックへ送信する段階、ここで、前記パケットの前記ヘッダの前記フリットモードバージョンは、第１の複数の物理レーン上で実装されるヘッダチャネル上で送信される；及び
前記インタフェースを通じて、前記パケットのペイロードデータを前記ファブリックへ送信する段階、ここで、前記パケットの前記ペイロードデータは、別個の第２の複数の物理レーン上で実装されるデータチャネル上で送信される、
を備える方法。
（項目１４）
前記インタフェースは、ＳＦＩ仕様に従って定義され、前記ロード／ストアプロトコルは、ＰＣＩｅ又はＣＸＬ．ｉｏの１つを含む、項目１３に記載の方法。
（項目１５）
前記パケットの前記ヘッダの前記フリットモードバージョンは、前記第１の複数の物理レーンの第１サブセット上で送信され、前記方法は、
前記ヘッダチャネルの前記第２の複数の物理レーンの第２サブセットを使用して、前記インタフェース上でヘッダメタデータを送信する段階
を備える、項目１３に記載の方法。
（項目１６）
ファブリック；及び
前記ファブリックを通じて通信可能に結合される複数のコンピュートブロック、ここで、前記複数のコンピュートブロックにおける特定のコンピュートブロックは：
ロード／ストアインターコネクトプロトコルをサポートするエージェント回路、ここで、前記ロード／ストアプロトコルはフリットモード及び非フリットモードをサポートし、前記フリットモードのとき、フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードのとき、非フリットモードヘッダフォーマットのセットが使用され、前記非フリットモードヘッダフォーマットのセットは、１又は複数の非フリットモードフィールドを含み；及び
前記ファブリックに結合するためのインタフェースを実装するためのインタフェース回路、ここで、前記インタフェース回路は：
リンクが前記非フリットモードに対してトレーニングされると決定し；
前記フリットモードヘッダフォーマットのセットに従ってヘッダを生成し、ここで、前記ヘッダは、対応するパケットが非フリットモードパケットとして生じたことを示すためのフィールドを含み、前記フリットモードヘッダフォーマットのセットの１又は複数のフィールドは、前記１又は複数の非フリットモードフィールドを搬送するために前記ヘッダにおいて再利用される；及び
前記インタフェースを通じて前記ヘッダを送信する
を含む、
を備えるシステム。
（項目１７）
前記インタフェース上の１対多接続を促進するためのバッファレスアービタを更に備える、項目１６に記載のシステム。
（項目１８）
前記コンピュートブロックの第１のものにおいて送信機によって使用される専用クレジットを、前記コンピュートブロックの第２のものにおいて受信機によって使用される共有クレジットに変換するためのクレジットガスケットを更に備える、項目１６に記載のシステム。
（項目１９）
前記ファブリックは、システムオンチップ（ＳｏＣ）デバイスのインターコネクトファブリックを含み、前記ＳｏＣデバイスは、前記複数のコンピュートブロックを含む、項目１６に記載のシステム。
（項目２０）
前記インタフェースは、パケットヘッダを通信するための専用物理レーンのセットを含むヘッダチャネルを含み、前記フリットモードは、前記ヘッダチャネル上で通信されるヘッダのために使用される、項目１６に記載のシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15A】
【図15B】
【図15C】
【図15D】
【図16】
【図17】
【図18】
【図19A】
【図19B】
【図20】
【図21】
【図22A】
【図22B】
【図23】
【図24A】
【図24B】
【図24C】
【図24D】
【図25】
【図26】
【外国語明細書】