エンドポイント・オーダとリクエスト・オーダー

CHIのトランザクションは、エンドポイント・オーダとリクエスト・オーダによって順序づけられる：

エンドポイント・オーダは、1つの Requester から1つの Subordinate のアドレス範囲へのトランザクションの順序を維持する。
- 例えば、エンドポイント・オーダでは、Subordinate のプログラマブル・レジスタ・バンクに複数のデバイス・アクセスが発行される。
リクエスト・オーダーは、同じアドレスに対する1つのRequesterからのトランザクションの順序を維持する。
- 例えば、Normal NC、Device-GRE、Device-nGREのような重複する非キャッシュ可能アドレスに複数のリクエストが発行される場合、順序付けが必要である。
- CHIは、リクエスト・オーダが設定されているとき、アドレスマッチングに正確な粒度を要求せず、粒度は実装によって定義される。
注意: エンドポイント・オーダを設定した場合、リクエスト・オーダは暗示される。

オーダーのタイプは、リクエストフリットのOrderフィールドによって制御される。

いくつかのリクエストタイプのみが、リクエスト・オーダとエンドポイント・オーダを使用できる。これらのリクエストタイプは以下のように分類される：

ReadNoSnp と何らかの ReadOnce タイプ:
- Requester は、オーダーを要求する ReadNoSnp または ReadOnce タイプのリクエストを発行する。
- Subordinate はリクエストを受け入れ、 ReadReceipt メッセージでレスポンスする。ReadReceiptは、次にオーダーされるリクエストが発行できることを示す。
- ReadReceipt レスポンスを発行することで、下位はリクエストを受け取った順番で維持することを保証する。
WriteNoSnp と WriteUnique タイプのリクエスト：
- Requester は、 WriteNoSnp または WriteNoSnp を発行する。
- Subordinate は、 DBIDResp メッセージでレスポンスし、メッセージを受け入れることができることを知らせる。 DBIDResp レスポンスは、データバッファスロットが書き込みデータを受け入れるために利用可能であることを通知し、Requesterは次のオーダーされたリクエストを発行することができる。
- DBIDResp を発行することで、 Subordinate はリクエストを受け取った順番に維持することを保証する。

リクエストタイプの詳細については、CHI仕様を参照のこと。

イベントの順序は以下の通りである：

Requesterは、 ReqOrder をセットした状態で、SubordinateにRead Request 1を開始する。
Requesterは、 ReqOrder が設定されているときに、同じくSubordinate にRead Request 2を発行するが、 Request 1がまだ未処理のため、Requesterはリクエストの送信をブロックされる。
Subordinate は、Request が受け入れられたことを示す、Read Request 1に対する ReadReceipt メッセージでレスポンスする。
以下は順序は問わない：
Requesterは、Read Request 2 を Subordinate に送信する。
Subordinate は、Read Request 1の読み取りデータをRequesterに返す。

リクエストの再試行

ターゲットノードがリクエストを受け入れるのに十分なリソースを持っていないことがある。

リソースが利用できないときにリクエストチャネルがブロックされるのを防ぐために、CHIはリクエスト再試行(Request Retry)メカニズムを提供する。リクエスト再試行の仕組みは、リソースの可用性を示すためにプロトコルクレジットを使用する。リクエストを処理するために必要なプロトコル・クレジット(PCrd)のタイプを決定し、記録することはSubordinate の責任である。

メカニズムは異なるリソースをトラッキングするために異なるタイプの Protocol Creditを使用できる。例えば、Read Requestsと Write Requestsは別々のData Bufferを使用することができるので、各バッファは可用性を示すために異なるタイプのProtocol Creditを使用することができる。異なるタイプのProtocol Creditの値は実装によって定義される。

以下の例では、リクエストの再試行(Request Retry)で送られるメッセージのシーケンスについて説明する。この例では、完了ノードがリクエストを受け入れられなかったので、Request Node1がリクエストを発行する。

以下に一連の流れを示す：

１. すべてのリクエストは最初にプロトコル・クレジットなしで発行される。リクエスト・フリットは AllowRetry という制御フィールドを持つ。リクエストが最初に送られるときにこのフィールドをYESに設定することは、リクエストがプロトコルクレジットを使用していないことを示す。 AllowRetry がYESのとき、リクエストの PCrdType フィールドは0でなければならない：

２．この例のターゲットは、Requesterバッファが一杯であるためリクエストを受け取ることができず、RetryAck メッセージでレスポンスする。

３．RetryAck レスポンス・フリットは、 PCrdType フィールドに、リクエストの再試行に必要なクレジットのタイプを示す値を設定する。この例では、図のように PCrdType の値は2である：

４．ターゲットがRequestを受け入れることができるとき、ターゲットはRSPチャネル上で PCrdGrant メッセージを送る。 PCrdGrant レスポンス・フリットは、利用可能になったプロトコル・クレジットのタイプを示すために PCrdType フィールドを使用する。 Requesterは、PCrdGrant メッセージのProtocolクレジットタイプと RetryAck レスポンスがマッチする場合にのみ、リクエストを再試行しなければならない。この例では、両方のフィールドに2が設定されなければならない。プロトコル・クレジットタイプがマッチする場合、ターゲットノードはそのリクエストを受け入れることができることを保証したことになる。

５．AllowRetryフィールドを0に設定して、Requesterはリクエストを再発行する。 AllowRetry フィールドを0に設定することは、ターゲットノードに対して、リクエストが付与されたプロトコルクレジットを使用していることを示す。