AMBA-CHI协议详解（十）

在这里插入图片描述

AMBA-CHI协议详解（一）- Introduction
AMBA-CHI协议详解（二）- Channel fields / Read transactions
AMBA-CHI协议详解（三）- Write transactions
AMBA-CHI协议详解（四）- Other transactions
AMBA-CHI协议详解（五）- Transaction identifier fields
AMBA-CHI协议详解（六）- Transaction identifier field flows
AMBA-CHI协议详解（七）- Ordering
AMBA-CHI协议详解（八）- Address, Control, and Data
AMBA-CHI协议详解（九）- Data transfer
AMBA-CHI协议详解（十）- Retry

文章目录

- 2.9 Request Retry
- 2.9.1 Credit Return
- 2.9.2 Transaction Retry mechanism
- 2.9.3 Transaction Retry flow

2.9 Request Retry

该规范提供了一个Request Retry（请求重试）机制，确保当请求到达一个Completer 时，它要么被接受，要么被给予一个RetryAck响应，以防止阻塞REQ通道。
在这里插入图片描述

Request Retry不适用于PrefetchTgt事务。无法retry PrefetchTgt事务，因为没有与此请求相关联的响应。

RN需要保存请求的所有细节，直到它收到一个响应，表明请求已被接受或必须在稍后的时间点再次发送。为了满足这个要求，除了PrefetchTgt之外，AllowRetry字段必须在第一次发送事务时断言。

接收请求的Completer能够对它无法接受的请求给出RetryAck响应。
通常，当资源有限且存储空间不足，无法保存当前请求时，它将无法接受请求，直到一些较早的事务完成。

当Completer给出RetryAck响应时，它负责记录请求来自何处，这由请求的SrcID决定。Completer还负责确定和记录处理请求所需的协议信用（P-Credit）类型。RetryAck中的PCrdType字段编码将由Completer授予的P-Credit的类型。当所需的资源变得可用时，在稍后的时间点，Completer必须使用PCrdGrant响应向请求程序发送P-Credit。PCrdGrant响应向Requester表明可以retry事务。

——Note——————
没有明确的机制来请求信用。给予RetryAck响应的事务隐式地请求信用。
——————————

可以对响应进行重新排序，以便在接收到事务的RetryAck响应之前请求方接收到PCrdGrant。在这种情况下，请求方必须记录其收到的信用，包括信用类型，以便在收到RetryAck响应时可以适当地分配信用。

——Note——————
RetryAck和PCrdGrant响应之间的延迟通常要比互连重新排序造成的延迟长得多。对于RetryAck， PCrdGrant预计很少会被重排序。
——————————

当请求方收到一个Credit时，它可以重新发送请求，并指出它已被分配了一个Credit。这是通过取消AllowRetry字段来实现的。执行事务的第二次尝试保证被接受。

重新发送的事务必须具有与原始请求相同的字段值，除非该字段不适用或属于下列情况之一：
在这里插入图片描述
当请求方收到CopyBack Write请求的RetryAck响应时，该请求的数据被snoop置为无效，请求方可以：

放弃写请求并返回收到的信用证。
发送写请求时将AllowRetry设置为0，知道后续的数据响应将是CopyBackWrData_I。

Credits和特定事务之间没有固定的关系。如果Requester收到了多个针对不同事务的RetryAck响应，然后又收到了一个信用，那么就没有固定的信用分配。Requester可以从接收带有特定协议信用类型的RetryAck响应的事务列表中自由选择最合适的事务。

Retry机制最多支持16种不同的信用类型。这让Completer可以为不同的资源使用不同的信用类型。例如，Completer可能对与读事务相关的资源使用一种信用类型，而对写事务使用另一种信用类型。使用不同的信用类型使Completer能够通过控制Retry的请求中哪些可以再次发送来有效地管理其资源。

——Note——————
如果Completer只使用一种信用类型，建议使用PCrdType值0b0000。
——————————

提供RetryAck响应的Completer必须能够记录所有的RetryAck响应，以确保能够正确分配Credit。如果Completer使用多个信用类型，则必须记录每种信用类型的RetryAck响应。

Requester 必须限制它发出的事务，这样Completer就不需要跟踪超过1024个需要PCrdGrant响应的事务。这是通过将每个Requester的未完成事务的最大数量限制为1024来实现的。

事务从请求第一次发出的周期开始，直到：

事务完全完成，由以下所有预期的事务响应的返回来确定：
— ReadReceipt
— CompData
— RespSepData
— DataSepResp
— DBIDResp*
— Comp, CompCMO, CompPersist, and CompStashDone
— CompDBIDResp
它接收RetryAck和PCrdGrant，并且是：
— 使用适当PCrdType的信用重新Retry，然后根据所有响应的返回确定完全完成。
— Canceled并使用PCrdReturn消息返回收到的信用。

Requester可以重用请求使用的TxnID值：

一旦收到该请求的RetryAck响应。
一旦接收到该请求所需的所有响应（如果接收到的响应是Non-RetryAck响应）。

每个事务请求都包含一个QoS值，Completer可以使用该值在资源可用时影响信用的分配。

2.9.1 Credit Return

Requester获得的credits可能比它需要的要多。

本规范没有定义何时会发生这种情况，但有两种典型的情况：

在第一次尝试到可以用P-Credit重新发送的时间点之间，事务被取消。
随着QoS值的增加，事务被请求多次。但是，只需要完成一次事务。

——Note——————
如果Requester在第一个请求得到RetryAck响应之前发出第二个请求，则两个事务的发生必须是可接受的。然而，作为一个例子，这种行为对于访问外围Device来说通常是不可接受的。
——————————

Requester通过使用PCrdReturn事务返回信用。这实际上是一个使用不需要的信用的No Operation事务。该事务用于通知Completer，给定的PCrdType不再需要分配的资源。

任何不需要的Credit必须及时退还。

——Note——————
任何未使用的预分配Credit必须归还，以避免组件持有Credit，期望以后使用它们。这种行为很可能导致资源的低效使用，并使系统性能分析变得困难。
——————————

2.9.2 Transaction Retry mechanism

以下部分描述Retry机制使用的请求事务字段。

事务Retry机制不适用于PrefetchTgt事务。

AllowRetry
AllowRetry字段指示请求事务是否可以得到RetryAck响应。该字段指定发送请求时没有P-Credit，并且目标可以确定是否给出重试响应。
在这里插入图片描述
AllowRetry字段在以下情况下必须取消断言：

事务使用预先分配的P-Credit。
事务是PrefetchTgt。

PCrdType
PCrdType字段表示与请求关联的信用类型，确定方法如下：

对于请求事务：
— 如果断言AllowRetry字段，则PCrdType字段必须设置为0b0000。
— 如果取消AllowRetry字段，则必须将PCrdType字段设置为首次尝试事务时从Completer发回的RetryAck响应中返回的值。
PCrdReturn事务必须将信用类型设置为正在返回的信用类型的值。
对于具有单个信用类别或未实现信用类型分类的目的地，建议将PCrdType字段设置为0b0000。