[CHI] L-Credit和P-Credit_chi credit-优快云博客

AMBA的CHI协议相比于AXI协议在一致性方面有很多扩展, 其使用场景、交互方式、信息传递、拓扑结构等都有很多不同. 本着有更多交流的目的, 分享在学习中的见解和内容。

文章目录

前言
一、L-Credit
二、P-Credit
总结

前言

CHI有两种Credit的概念, L-Credit和P-Credit都与资源管理以及链路层的信息交互相关, 从这里作为切入点有助于我们理解CHI中的信息传递.

一、L-Credit

二、P-Credit

CHI中除了再次被retry的transaction和Prefetch transaction, 所有的transaction都支持AllowRetry filed设置为1, 即允许retry.
P-Credit的全称是Protocol Credit. 如果一个transaction因为Completer资源不足或是其他原因不能被执行, 就回resp一个RetryAck的响应. 当满足执行的条件时Completer可以发出PCrdGrant(P-Crdit), 第二次发出的transaction带着该P-Credit, 因为存在预先分配的资源是一定可以被执行的.
在这里插入图片描述
Retry flow如下:

Requester发出一个不带P-Credit(PCrdType=0000)的请求.(第一次发出的请求都不带P-Credit)
Completer返回一个retry resp即RetryAck给到Requester.
Completer返回一个protocol credit grant即PCrdGrant给到Requester. 通常情况下, PCrdGrant是在RetryAck之后一段时间发出的, 因为Completer需要对资源进行释放、预留. 但是也可以早于RetryAck, 协议中并没有强制要求该顺序.
Requester接到PCrdGrant之后有两种选择:
①重发原始请求并且带上credit. 重发的含义是原有的filed包括与PCrdGrant一样的PCrdType, QoS等.
②取消发送原始请求, 但需要返回credit(PCrdReturn transction).

Retry机制的作用:
Retry机制是为了确保request可以到达Completer, 无论是accept还是RetryAck, 都不会因为Completer不会因为资源不足而blocking requeset.
所以不需要resp的transaction也没有retry机制, 比如PrefetchTgt transaction.

P-Credit的分配:
P-Credit和L-Credit不同, 不是一个以数量为计量的单位, 比如一个QoS='hF的RD transaction发送到Completer, Completer可以设置一个read type的high priority的资源分组, 例如’hF<=QoS<'hD的read type的transaction的P-Credit都分配为’hA.
Completer可以去决定已经记录P-Credit, 当有对应的资源被释放时, 使用PCrdGrant发送P-Credit给Requester. 即P-Credit是Completer用来管理资源的一种方式, 没用固定的关系在credit和transaction之间.
虽然P-Credit由Completer控制, 但是Requster也需要限制发出的transaction数量, 使Completer不必track超过1024笔transaction.

P-Credit的释放:
Requster在收到RetryAck后可以选择是否再次发送该transaction, 如果选择不再发送, 仍然需要返回credit通过PCrdReturn transaction. 否则将会使Requster获取超过所需的credit, 同时Completer也会有一直不能释放的资源.