步入新时代 | PCIe 4.0带来了哪些惊喜？

本文首发在[存储随笔]微信公众号平台: 点这里

自2010年PCIe 3.0发布之后，我们仿佛等待一个世纪，PCIe 4.0终于"千呼万唤始出来". PCI SIG组织，在我们的国庆节期间(算是国庆献礼么，O(∩_∩)O~)，10月5日，正式发布了PCIe 4.0 V1.0 spec。很多国内外媒体都在第一时间争相报道！

---

温馨提示: 以下内容可能需要有一定的PCIe背景，对PCIe不太了解的朋友可以先翻阅之前的"PCIe科普贴"，非常感谢！

---

相对PCIe 1.1/2.0/3.0，PCIe 4.0最突出的特点就是速度的飞跃，是PCIe 3.0的2倍，达到了16GT/s. 不过，与PCIe 3.0相同的一点是，PCIe 4.0依然采用128/130b编码。

PCIe 4.0速度的升级算是例行公事，除此之外，PCIe 4.0在其他方面带来了哪些惊喜呢？我们按照spec的顺序，挑选重要的，进行一一揭晓！(以下内容均是基于PCIe 3.0作为对比)

一、10-bit Tag Field(Section 2.2.6.2):

在PCIe协议中，事务发起者(Requester)发送的TLP需要有身份ID，这个就叫做Transaction ID，而Transaction ID由两部分构成，Requester ID和Tag。其中，Requester ID包含了Bus/Device/Function信息。而Tag则表示的是同一发起者(Requester)同时暂存TLP的数量。

注意：

1， 对于Posted TLP来说，Transaction ID其实没有多大意义，因为Requester也不需要有反馈，但是设备还得要支持Transaction ID的。

2， 对于Non-Posted TLP来说，Transaction ID就是必须的。不然在有Cpl包返回时，也不知道是哪个Requester的。

关于Tag：

1，Requester发送Non-Posted TLP之后，在没有收到Cpl报文之前，对应的Transaction ID不能被释放。同一Requester发送的Non-Posted TLP的Header中, Requster ID肯定是一样的。当一个Requster要发起多个Non-Posted TLPs时，Tag字段就有了施展才华的时刻。

2，Tag字段的大小决定了发送端可以暂存同一类型TLP的数量。PCIe 3.0 Spec中显示，默认是bit[4:0]，就是默认长度是5，当enable extend Tag bit后，Tag长度为8。也就是说在PCIe 3.0中，每个PCIe设备的发送端最多只能暂存256个TLPs，换句话说，对于同一发起者而言，此时PCIe链路上有其256个TLPs在传输。

3, 其实，PCIe设备的Function设定中也可以扩展Tag字段，这里不展开了。

其实，在大多数情况下，8-bit Tag已经够用了，但是对于一些特殊的高性能系统来说，这还不够。我们来看个算式：

BW = S * N / RTT

其中，BW = payload bandwidth，S = transaction payload size，N = number of outstanding NPRs(Non-Posted Request)，RTT = transaction round-trip time.

从上面的算式中，我们可以看到发起者暂存TLPs数目，也就是Tag字段的大小，与有效带宽成正比。为了配合高速传输的需求，PCIe 4.0将Tag字段从原来的8-bit扩展到10-bit。 

Tag字段扩展后，TLP Header的大小以及其他字段的定义保持不变。扩展的两个bits，bit[9]和bit[8]分别位于Byte1 Bit[7]和bit[3](这两个bits在之前是Reserved)。10-bit Tag对应的Header定义如下：

Tag[9:8]的有效取值包括01b, 10b, 11b。00b是无效取值。也就是说，10-bit Tag最大暂存TLP数目由原来的256扩大到了768.

二、Scaled Flow Control(Section 3.4.2):

在之前的文章"Flow Control概述"中，对Flow Control做了大致的介绍，"PCIe科普贴"中对Flow Control的实现原理也做了比较详细的介绍。在PCIe 3.0中，Flow Control Update Packets中可以看到(下图)，Header FC Field=8, Data FC Field=12, 这就意味着PCIe 3.0中Flow Control Credit有最大界限值：Header Credit最大为127，Data Credit最大为2047. (1 Credit=16B)

我们知道，Flow Control Credits代表的是接收端VC buffer的可用空间，这个值直接影响着PCIe Link的传输速度。就跟我们开车在路上类似，当前方的通行能力下降时，整个路况就会拥堵，行驶缓慢。所以，PCIe 3.0中Flow Control Credits的最大值，在PCIe 4.0 16GT/s传输速率下已经成为了瓶颈。

为了解决这个瓶颈，PCIe 4.0引入了"Scaled Flow Control"的概念。简单点说是对PCIe 3.0中的Credits大小进行成倍的放大。

Scaling Factor：

1，PCIe 3.0中，1 Credit代表16 Bytes；

2，PCIe 4.0中，1 Credit也是代表16 Bytes, 不过，PCIe 4.0提供了x1, x4, x16三种放大系数; 可以理解成PCIe 4.0中的‘Credit’是对PCIe 3.0中的Credit放大了1/4/16倍。

3，这样, 对于Header Flow Credit有 127/508/2032 credits三种选择，对于Data Flow Credit也有2047/8188/32752 credits三种选择。

在PCIe 4.0中，对TLP Header和Data如何选择相应的放大系数呢？怎么知道是x1,x4,x16呢？这就依赖于两个参数：Hdr Scale和Data Scale. 这两个参数就在FC DLLPs中，包括FC初始化DLLP: InitFC1 & InitFC2，FC Update DLLP:  UpdateFC，如下图.

当Scaled Flow Control功能处于Disabled状态时, 之后Hdr Scale和Data Scale的取值只能是00，这时，Flow Control Credits相关设定与PCIe 3.0一致。

 

当Scaled Flow Control功能被Enable之后，Hdr Scale和Data Scale的取值只能是三种：01,10,11，分别代表着放大系数x1,x4,x16.

引入"Scaled Flow Control"功能之后，PCIe的Data Link也发生了相应的变化。与PCIe 3.0相比, PCIe多了一个"DL_Feature"状态。

不过，要进入DL_Feature状态还是有条件的，需要在Data Link Feature Capabilities Register中enable "Data Link Feature Exchange" bit.

在Flow Control中，DL_Feature这个状态主要用于Scaled Flow Control功能的握手交互(专业名称叫做Handshake)。在这个过程中，会用到一个叫做"Data Link Feature DLLP"，这个DLLP也是PCIe 4.0新增的, 如下图。

Data Link Feature DLLP中Byte1 bit[7]是Feature Ack bit,就是用来握手的, Byte 3 bit[0]也就是Feature support的bit[0]代表Scaled Flow Control是否support，Feature support的其他bit[22:1]目前是保留的, 以备将来之用。

三、Simplified Protocol Timer(Section 3.6.2.1):

在之前的PCIe专题文章"数据链路层Ack/Nak机制"中提到，TLP传输过程中有一个重传(Replay)机制，当经过"一段时间"后，发送端仍然没有收到接收端返回的Ack或者Nak信息，就会触发重新发送TLP。这里的"一段时间"有个专业名字叫做"REPLAY_TIMER"。

在PCIe 3.0 Spec中，对于REPLAY_TIMER的定义,不偏不倚，2.5GT/s, 5GT/s, 8GT/s三个传输速率均有专属的定义，这里放个8GT/s的REPLAY_TIMER Table，大家感受一下：

看这一格表格就觉得很繁琐，加上每个速率都有定义，这对设计者来说太痛苦了。

到了PCIe 4.0，PCI-SIG协会自己都不想再为16GT/s单独增加另外一个REPLAY_TIMER Table。于是，提出了更加简便的REPLAY_TIMER Limits.

对于所有的速率的都一样，只有两种选择：

1，当Extend Synch bit=0时，REPLAY_TIMER Limits=24K~31K Symbol time;

2，当Extend Synch bit=1时，REPLAY_TIMER Limits=80K~100K Symbol time;

Extend Synch bit则在Link Control Register中设置：

对于这个简化的REPLAY_TIMER，当PCIe链路运行在2.5GT/5GT/8GT时，你也可以选择无视，依然选择原本的定义方式。但是，当PCIe链路运行在16GT/s时，你就别无选择咯，只能按照PCIe 4.0 Spec的要求，乖乖的实验简化RETPLAY_TIMER。

四、Link Equalization(Section 4.2.3):

在PCIe协议中, 2.5GT/s和5GT/s采用固定的"去加重(De-emphasis)"的方式降噪来提升信号传输的完整性。但是随着传输速率的提升，De-emphasis方式已经不能满足需要，8GT/s和16GT/s改用对Tx/Rx进行信号均衡化(Equalization, EQ)的方式提升信号质量，以满足高速的传输需求。

按照PCIe 4.0 Spec的要求，我们不能对16GT/s直接进行EQ操作，需要先完成8GT/s的EQ之后，才能进行16GT/s EQ操作。所以，在刚上电的时候，PCIe设备只能先跑在8GT/s，如下图：

当8GT/s EQ完成之后，就可以通过发送TS1切换到16GT/s进行EQ操作。

8GT/s和16GT/s的EQ过程都有四个阶段: Phase 0,1,2,3. 我们在这里对16GT/s EQ过程简单阐述一下(更详细内容请参考Spec).

Phase 0: 这个阶段是在8GT/s EQ之后，PCIe Link还没有跑到16GT/s.  此时，Downstream Post(DSP)向Upstream Port(USP)发送8GT EQ TS2 Ordered Sets, 这组Ordered Sets里面包含了16GT/s EQ用到的预设值(Presets).

Phase 1: 这个阶段就是采用Phase 0的预设值，DSP和USP之间通过发送TS1进行协商，期望达到效果是16GT/s最少可以维持24ms，同时，要求BER<=10^-4.

Phase 2/Phase 3: 基本原理一样，分别从DSP和USP角度对Tx/Rx信号进行微调，直到BER<=10^-12

五、Lane Margining(Section 4.2.13):

在PCIe 4.0协议中，16GT/s拥有一个特有的功能，叫做"Lane Margining"，因为是针对接收端的，也可以叫做"Rx Lane Margining". 当PCIe链路运行在2.5GT/s、5GT/s、8GT/s时，无法启动这个功能。当PCIe链路出于L0状态时，Lane Margining功能允许Host监控并修复接收端出现的信号偏差(包括电压和时间)，下图是针对时间轴进行Lane Margining的例子:

同时，Rx Lane Margining针对所有运行在16GT/s的Port口都是强制性，要注意的是，这里的Port也包括DSP和USP之间的Retimer，不过，PCIe 4.0 Spec规定, 在DSP和USP之间，最多支持2个Retimers，如下图。

此外，在PCIe 4.0 Spec, 针对DSP/USP和Retimer进行Rx Lane Margining的方式不同，看个简图：

1, 针对DSP/USP，Rx Lane Margining是通过Lane Margin Control and Status Register(简称CSR)实现。寄存器长度为32位，低16位是Control位，高16位是Satus. 

2, 针对Retimer，Rx Lane Margining则通过Control SKP OS实现

这里对CSR和Control SKP OS的定义不再展开, 有兴趣的话，请参考Spec.

写在最后

除了上面介绍的10-bit Tag、Scaled FC、Simplify Protocol Timer、Link EQ、Lane Margining这五个方面，PCIe 4.0 Spec还有很多细节的更新，在这里就不展开了。鉴于水平有限，如有阐述不当之处，敬请见谅！

更多精彩内容，敬请关注头条号【存储随笔】获取更多活动内容。
同时，也可以关注微信公众号: 存储随笔，Memory-logger. 

精彩推荐:

• PCIe SSD飞入寻常百姓家靠什么？
  

• SCM+MLC/TLC NAND混合SSD性能探究
  

• 浅析企业级SSD Multi-Stream Write技术
  

• 企业级SSD发展趋势
  

• 2D NAND和3D NAND横向对比
  

• 第二代3D TLC NAND原厂级深度评测

• 为QLC保驾护航 | 慧荣科技亮出最新LDPC技术

• SSD固态硬盘接口种类多，你了解多少？
  

• 写放大机制与影响因素详解

• 详解SSD之垃圾回收GC

• SSD为什么需要Trim？
  

• OP详解: 谁“偷”走了SSD的容量？

• SSD性能优化之4K对齐

• 文件系统全记录回顾
  

• 快来看，SATA秘籍惊现江湖！！！

• PCIe最全科普贴流出！不说了，赶快Mark！

• 独家发布 | Linux NVMe Driver学习笔记大合集
  

• 存储随笔《NVMe专题》大合集及PDF版正式发布！