【PCIe】UpdateFC 更新频率

MangoPapa

已于 2023-04-23 17:23:51 修改

阅读量2.6k

点赞数 7

分类专栏： PCIe 协议文章标签： pcie

于 2023-03-01 08:00:00 首次发布

本文链接：https://blog.csdn.net/weixin_40357487/article/details/129248152

版权

PCIe 协议专栏收录该内容

55 篇文章

订阅专栏

🔥点击查看精选 PCIe 系列文章🔥
🔥点击进入【芯片设计验证】社区，查看更多精彩内容🔥

📢 声明：

🥭 作者主页：【MangoPapa的CSDN主页】。
⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/129248152】。
⚠️ 本文目的为个人学习记录及知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
😄 欢迎大家指出文章错误，欢迎同行与我交流 ~
📧 邮箱：mangopapa@yeah.net
💬 直达博主：loveic_lovelife 。（搜索或点击扫码）

1. 简介

对于 Non-Infinite Credit 类型的流控，Rx 需要以某种频率将 Rx Buffer Credits 信息反馈给 Tx。具体操作中有较多规范，比如即时反馈、最大时延反馈及基于 Rx Max Payload Size (MPS) 及 LinkWidth 的更新频率计算。

即时反馈。常用于 Rx Buffer 剩余 Credit 不足以容纳 MPS TLP 的场景，在 Rx Buffer 释放出 Credit 后需要立即反馈 UpdateFC 给 Tx。

最大时延反馈。对于有扩展同步位情况，至少每 120 us (-0%~+50%) 发送一次 UpdateFC，对于没有扩展同步位的情况，至少每 30 us (-0%~+50%) 发送一次 UpdateFC。实际情况中，UpdateFC 的更新频率往往更高。

基于 MPS 及 LinkWidth 的更新频率计算。一方面，为了防止 Tx 端发送 TLP 时阻塞，Rx 需要及时通过 UpdateFC 流控包来通报 Rx FC Buffer 的 Credit 信息；另一方面，若 UpdateFC 通报又不能过于频繁，免得挤占过多有效数据带宽。为了平衡以上两点，同时为了选出最优的 Buffer Size 及 Rx MPS，很有必要对 UpdateFC 的更新频率进行精心设计。

2. Max UpdateFC Latency 计算

PCIe 协议提供了以下公式来约束 UpdateFC 的更新频率，两次 UpdateFC 之间的最大延时为：

$Max\ UpdateFC\ Latency=\frac{(Rx\_MPS\_Limit + TLP\ Overhead)\times UpdateFactor}{LinkWidth}+Internal Delay$

其中：

Rx_MPS_Limit，接收端一次允许接收的最大 Payload Size。对于 Multi-Function Device，每个 Function 的 MPS 或有不同，则选取其中较小的 MPS 作为该 Device 的 Rx_MPS_Limit。这样算出来的 Latency 能够满足所有 Function 的需要。
TLP Overhead，TLP 内除了 Data Payload 之外的开销，包括 TLP Prefix，Header，LCRC，Digest，Framing Symbol 等等。为了便于计算，所有速率下的 TLP Overhead 都按 28 Symbols 计算。
UpdateFactor（UF），更新因子，是指相邻两个 UpdateFC 之间能够发送的最大 Size 的 TLP 的数量，UF 用以平衡链路有效带宽及 Rx Buffer Size。
LinkWidth，链路宽度，x1, x2, x4, x8, x12, x16, x32。
Internal Delay，从接收到 TLP 到发出 DLLP 的内部处理时延，采用常数，19 Symbols@2.5GT/s，70@5.0GT/s，115@8.0+GT/s。

以上公式适用于 Non-Flit Mode 及 Flit Mode，UpdateFC 也仅在 L0 或 L0s 状态下且 Non-Infinite FC 情况下进行发送。以上公式仅仅是协议建议的对发送时延的最低约束，不包含 Retimer 引入的时延，也不包含 L0s、Recovery 期间引入的时延，也 不适用于需要即时反馈 Credit 的场景。

3. Update Factor

Update Factor 的值跟 Rx_MPS_Limit 及 LinkWidth 关系较大，跟链路速率没有关系。不同 MPS 及 LinkWidth 时的 UF 如表 1 所示。从表中可见，MPS 越小、LinkWidth 越大，UpdateFactor 越大，即两次 UpdateFC 之间发送的 Max Size TLP 数量越多。

▼ 表 1：不同 MPS/LinkWidth 对应的 UF

在这里插入图片描述

4. Max UpdateFC Latency 值

从上文公式的解释也能看出，Max UpdateFC Delay只是一个大致运算。我们以 2.5 GT/s、Rx_MPS_Limit=128、LinkWidth=x1 的 Device 举例，其 Max UpdateFC Latency = (128+28)*1.4/1+19 = 237.4，向下取整为 237 Symbols。依次类推，2.5 GT/s、5.0 GT/s 及 8.0+ GT/s 时的 Max UpdateFC Latency 分别如表 2~4 所示。

▼ 表 2：2.5 GT/s 时的 Max UpdateFC Latency (Symbol Time)

▼ 表 3：5.0 GT/s 时的 Max UpdateFC Latency (Symbol Time)

在这里插入图片描述

▼ 表 4：8.0 GT/s 及以上速率时的 Max UpdateFC Latency (Symbol Time)

在这里插入图片描述

从以上表格中计算出的 Max UpdateFC Latency 可以看出：

对于相同的 MPS 及 LinkWidth，不同速率之间的 Max UpdateFC Latency 相差固定值，即 5.0 比 2.5 高 51 Symbols，8.0+ 比 2.5 高 96 Symbols。
整体而言，MPS 越小、LinkWidth 越大，所需的时延越低，即 UpdateFC 需要发送的频率越快。