[CHI] L-Credit和P-Credit

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


前言

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


一、L-Credit

L-Credit可以参考这篇 AXI和CHI握手机制

二、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如下:

  1. Requester发出一个不带P-Credit(PCrdType=0000)的请求.(第一次发出的请求都不带P-Credit)
  2. Completer返回一个retry resp即RetryAck给到Requester.
  3. Completer返回一个protocol credit grant即PCrdGrant给到Requester. 通常情况下, PCrdGrant是在RetryAck之后一段时间发出的, 因为Completer需要对资源进行释放、预留. 但是也可以早于RetryAck, 协议中并没有强制要求该顺序.
  4. 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也会有一直不能释放的资源.

总结

Retry机制主要是为了保证request的发送和接收不会因为资源不足而被block, 为了实现该机制增加了一些约束, 例如P-Credit的释放条件, retry transaction的field value, outstanding retry transaction数量等.

CHI(Coherent Hub Interface)协议中,信用机制是一种用于控制数据流确保系统稳定性的流量控制方法。该机制通过分配信用点(Credit)来管理设备间的数据传输请求,防止因请求过多导致的系统过载。 ### 信用机制的工作原理 信用机制的核心在于信用点的分配与使用。每个设备在发送请求之前需要获得相应的信用点,只有当设备拥有足够的信用点时,才能发送请求[^1]。信用点的分配通常基于设备间的连接特性预期的负载情况。当一个设备成功发送一个请求后,它的信用点会减少;而当它接收到响应或确认信息时,信用点会被恢复,从而允许设备再次发送新的请求。 ### 信用机制的应用场景 1. **多设备通信**:在一个包含多个设备的系统中,信用机制可以有效地避免所有设备同时发送请求造成的拥塞。通过限制每个设备可以发送的最大请求数量,信用机制确保了系统的稳定性响应性[^1]。 2. **资源分配**:信用机制还可以用于动态调整不同设备之间的资源分配。例如,在某些情况下,可以通过增加某个高优先级设备的信用点来提高其访问资源的能力。 ### 信用机制的优势 - **流量控制**:信用机制提供了一种有效的流量控制手段,能够防止网络中的数据包丢失延迟增加[^1]。 - **公平性**:通过合理分配信用点,可以确保所有设备都能公平地访问共享资源,避免某些设备独占资源的情况发生。 - **灵活性**:信用机制可以根据不同的应用场景需求进行调整,以适应不同的流量模式系统配置。 ### 代码示例 下面是一个简单的Python代码示例,模拟了信用机制的基本工作原理: ```python class Device: def __init__(self, name, credit): self.name = name self.credit = credit def send_request(self): if self.credit > 0: self.credit -= 1 print(f"{self.name} sent a request. Remaining credit: {self.credit}") else: print(f"{self.name} cannot send a request. No credit left.") def receive_response(self): self.credit += 1 print(f"{self.name} received a response. Credit restored: {self.credit}") # 创建两个设备实例 device1 = Device("Device1", 2) device2 = Device("Device2", 3) # 模拟设备发送请求接收响应的过程 device1.send_request() device1.send_request() device1.send_request() # 应该无法发送,因为信用不足 device1.receive_response() device1.send_request() # 现在可以发送,因为信用已恢复 device2.send_request() device2.send_request() device2.send_request() ``` ### 相关问题 1. CHI协议中信用机制的具体实现方式是什么? 2. 信用机制如何影响CHI协议中的数据传输效率? 3. 在CHI协议中,信用机制与其他流量控制机制相比有哪些优势? 4. 如何在实际应用中调整信用点的分配策略以优化系统性能? 5. 信用机制在多设备通信中的具体应用场景有哪些?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值