Credit协议

最新推荐文章于 2024-11-14 17:06:15 发布

小元元的小圆圆

最新推荐文章于 2024-11-14 17:06:15 发布

阅读量887

点赞数 12

文章标签：硬件架构 fpga开发

本文链接：https://blog.csdn.net/weixin_42330305/article/details/143764128

版权

1. Credit协议背景

芯片中的Credit机制通常用于流量控制，特别是在数据通信和总线系统中。这种机制有助于管理数据的传输速率，确保系统在高负载和高流量的情况下仍能保持稳定性。

Credit机制的基本原理是发送方和接收方之间维护一个“信用”值，该值表示接收方能够接受的数据量或者发送方还能够发送的数据量。当发送方要发送数据时，它会首先检查接收方的信用情况。如果接收方有足够的信用，发送方就可以将数据发送出去，并相应地减少接收方的信用。

一旦接收方成功接收到数据，它会向发送方发送一个确认，同时恢复一定量的信用，表示它仍然能够接受更多的数据。如果发送方在一段时间内没有收到确认，它可能会减少发送的数据量，以避免在网络拥塞或其他问题发生时引起问题。

这个Credit机制可以帮助避免数据包的丢失，确保通信的可靠性，并且在网络流量较大的情况下能够自适应调整数据的传输速率。这种机制在许多通信协议和总线架构中都有广泛的应用，例如PCI Express（PCIe）总线、ATM网络、CHI等。

Credit机制可以帮助避免突发问题的方式主要体现在两个方面：流量控制和拥塞管理。

流量控制： Credit机制允许接收方控制发送方的数据流量。通过维护信用值，接收方可以限制发送方发送的数据量，确保它在处理能力范围内。这样，即使在瞬时突发的情况下，接收方可以有效地控制和调整其处理速度，防止因为突发的大量数据而导致系统不稳定。
拥塞管理：当系统中的某一部分发生拥塞或流量过大时，Credit机制也能够帮助缓解这种情况。拥塞通常是由于网络或系统资源不足引起的，但通过Credit机制，系统可以自适应地减少流量，以适应当前的处理能力。接收方在信用不足时可以拒绝接收更多的数据，从而通知发送方降低发送速率，减轻拥塞的程度。

2. credit交换机制 & ready valid机制

当涉及到信号传输时，credit交换机制和ready valid机制是两种不同的握手方式。

Valid-Ready 握手（AXI）：

- 原理：在AXI协议中，数据传输通过"valid"和"ready"信号进行同步。发送方使用"valid"信号表明数据有效，接收方用"ready"信号表明准备接收数据。当"valid"和"ready"都是高电平时，数据被成功传输。
- 优点：
  - 简单性：实现起来简单，容易理解。
  - 低延迟：只要两个信号就绪，数据立即传输。
  - 确定性：简单的握手机制使得数据传输更加可预测。
- 缺点：
  - 低效率：在高并发或多主体环境下，可能造成信号冲突和等待，降低吞吐量。
  - 扩展性差：在大规模系统中，流量控制可能不够灵活。
Credit 机制（CHI）：
- 原理：在CHI协议中，接收方为发送方提供一组“信用”（credits），每当数据成功接收，消耗一个信用。当信用用完时，发送方必须停止发送数据，直到接收到新的信用。
- 优点：
  - 高吞吐量：可以进行更高效的数据传输。
  - 流量控制：通过动态信用分配，可以更精细地控制数据流。
  - 可扩展性：适用于大规模或复杂的系统架构。
- 缺点：
  - 复杂性高：需要更复杂的逻辑来管理信用和流量控制。
  - 调试难度：由于复杂性，找出问题和调试可能更困难。

Credit 机制（master counter）：

- 原理：Master端维护Credit Counter，Slave消耗掉一个Request，返回Credit Release
- 优点：
  - PPA：时序收敛/中间打拍更容易。
  - 流量控制：Master可以清楚的知道当前自己的发送能力，主动控制数据流。
- 缺点：
  - 局限性： 更适合master slave一对一
  - 调试难度：由于复杂性，找出问题和调试可能更困难。

3. 基本的Credit协议

3.1. 单通道的Credit协议

单通道的Credit协议，一般用于Master端向Slave端发送Request，Slave接收Request处理，不返回Response给Master。其中：

Master端维护Credit Counter来判断是否可以发送下一笔Request，每发1笔Request，Credit Counter减1；
Slave消耗掉一个Request，返回Credit Release，Master收到Credit Release信号后，Credit Counter加1：

值得思考的是，如果上面的设计，Slave通过FIFO状态产生Ready信号告诉Master是否可以接受Request，即通过Valid-Ready协议，看起来和Credit协议执行效果差不多。那在这种情况下，是否要使用Credit协议呢？Credit协议的优势是什么呢？

答案就是，Valid-Ready协议中，Master不知道自己当前的发送能力，只能一个一个的发送；而Credit协议中，Master可以清楚的知道当前自己的发送能力。在上面的简单操作中，这两个处理方式区别不大，但是在一些复杂的设计中，Master可以根据自己当前Credit情况选择更多的发送方式来实现更加复杂的设计意图；

RTL：valid -> req，credit -> credit_rls

3.2. Credit数目的设置

Credit协议中，该如何设置Credit数目是一个核心问题，基本原则：既要保证功能正确，也要尽可能隐藏Latency提高吞吐率。针对于上图的设计，我们假设Slave中FIFO深度为F，Master从发送一笔Request到接收到这笔Request对应的Credit Release的Latency为L，设置的Credit数目为N，那么需要满足：

Credit数目不能超过FIFO深度，这是个功能的需求。即 N <= F；
在不被堵塞的情况下，希望Master发送Request能够不断流，这是个性能的需求。那就需要：N >= L；
综上，理想情况下，L <= N <= F；其中Credit数目一定不能大于FIFO深度，不然功能会出现问题；

在最典型的Credit设计中，FIFO深度F和Latency L一般是设置为相同的，所以 N = F = L，同时满足功能和性能的需求；但是由于Latency一般随着PPA的改动，会出现波动，因此很多时候只需要保证N=F，在这个基础上尽可能覆盖Latency；

3.3. Credit协议叠加Valid-Ready协议

根据上面，只使用Credit协议既能够满足Master-Slave传递请求的功能需要，也能实现性能需要，为什么有些情况下的设计中在Credit协议上还要叠加Valid-Ready协议呢？根本原因就在于上一节的Credit 数目设置以及设计复用的问题上。

在上面的设计中，Master的设计很可能会被复用到连接不同的Slave，不同Slave的FIFO深度、Latency可能都不一样，那这样的话Master的Credit该怎么设置呢？

如果不使用Valid-Ready协议的话，只能取一个所有Slave FIFO深度的最小值来保证功能正确，但是很明显，这样性能不好；
通过额外借助于Valid-Ready协议的话，Credit则可以设置为一个最大值，同时满足所有Slave的功能和性能需求，如下图：

Credit叠加Valid-Ready的波形图如下：

总结就是，在Credit协议中叠加使用Valid-Ready协议，可以通过设置更大的Credit数值来追求更好的性能；同时，可以解耦Master的发送能力与Slave的接受能力的绑定，实现更高效的复用；如果不带Valid-Ready协议，则Credit数值需要保守设置来保证功能正确。这一规则也适用于下面所有的Credit变种。

3.4. 支持多Request、多Credit返还的单通道协议

在上面的基础上，根据Master发送能力以及Slave处理能力，会出现：Master可以一次发送多笔Request，Slave可以一次Release多个Credit给Master。例如：Master每次最多发2个Request给Slave，Slave一次最多可以处理2个Request，那么返回的Release Credit可能是1/2，这样的话，Request和Credit Release接口都需要通过Vld + Num两个信号来表明Credit使用情况。

如下图所示：

这种情况下，Master和Slave之间的传输增大了并行度，但是使得Slave端对于Credit Release的逻辑、以及Master发送Request的逻辑更加复杂，更加需要小心对待。

3.5. Request通道与Response通道并存的Credit协议

在Master发送完Request后，Slave需要返回Response的操作中，Credit协议一般有两种：

Request和Response各自使用独立的Credit Counter；
Request和Response共用同一套Credit Counter；

3.5.1. Request和Response独立Credit的协议

Request和Response独立Creidt的情况下，Request和Response可以看做两个独立的请求通道，各自维护自己的Credit，只是Response的Credit由Slave来管理。

其中，Request和Response的Credit Counter的值一般情况下会设置为一样。

3.5.2. Request和Response共享Credit的协议

在上面Request和Response各自独立的Credit的情况下，可以看出，Master的Response FIFO一旦被阻塞，可以反压Slave的Request FIFO，并最终反压Master的Request发送。因此，有些设计中会将Request和Response使用1份Credit来管控，这个Credit Counter放在Master中，在Master端监控发出的Request以及收到的Response数目来维护Credit，不再需要Master与Slave之间Credit Release接口，如下图：

但是，这种协议如果只使用Credit来管控的话，性能会比较差，因为Credit维护必须根据Response FIFO的Pop来对Credit数目增加，而不能是Response FIFO的Push，因此在Request FIFO和Response FIFO深度都为N的情况下，Credit只能设为N，这样无法掩盖完整通路Latency。

因此，为了能充分提高性能，这种机制一般需要搭配Valid-Ready一起工作，这样可以设置一个较大的Credit值来提高吞吐率。如下图所示：