2.2 再次发送L0p请求

端口再次发送L0p请求的时间点是有要求的，满足以下任一条件时本端口方可以再次发送L0p请求：

•    不论上次L0p请求由谁发起，此刻距上次成功实现动态链路切换已过去1us。

•    上次L0p请求由本端口发起，但被拒绝了。

•    上次L0p请求由对端发起且本端口已回复ACK，若上次L0p请求请求上调链路宽度，无论本端口是否监测到对应lane退出电气闲，即无论上调是否成功完成，只要过去2us，本端口均可再次发送L0p请求。

•  （为什么没提到下调链路宽度呢？下调链路宽度是双方端口能够主动控制的，但是上调可就不是这么回事了，链路坏了还真就上调不了。）

2.3 L0p的进入和退出耗时

对于一直处于活跃状态的lane而言，上调和下调链路宽度对数据传输没有任何影响。

  当下调链路宽度时，对于要关闭的lane而言，考虑到要把SKP替换为EIOS才能进入电气闲，最差情况是2个SKP的间隔1.5ms；当上调链路宽度时，耗时跟从L1退出的耗时相同。

2.4 L0p对称性

大家知道，Tx和Rx可以单独进入和退出L0s状态，但是对于工作在Flit Mode且启用了L0p的PCIe 6.0设备，其Tx和Rx必须同时进入或退出L0p，且Tx和Rx的链路宽度相同，称之为L0p的对称性。为什么要这么做呢？减少设计的复杂度。考虑到USP及DSP的处理速度或许不同，DSP及USP在动态切换链路宽度的时候，或许存在短时间的链路宽度不同的情况，这是允许的，我们仍然称起是对称的。

3. 链路管理DLLP

目前链路管理DLLP类型只有L0p链路管理DLLP这一种，其格式如图5所示。

  各字段意义如下：

• Byte0：固定值 8’b00101000，用以指示当前为链路管理DLLP。

• Byte1：指示链路管理的类型，目前只有L0p DLLP这一种类型，值为8’b00000000。

• Byte2：bit[3:0]表示L0p的命令类型，0100 -> L0p 请求，0110 -> L0p ACK，0111 -> L0p NAK，1010 -> L0p链路上调训练完成；bit[4]在L0p命令为L0p请求时表示L0p请求的优先级，1为高优先级；bit[7:5]预留。

• Byte3：bit[3:0]及bit[7:4]均表示链路宽度，其中bit[3:0]是L0p请求或链路上调训练完成的链路宽度，bit[7:4]是L0p NAK/ACK的响应负载，0001b -> x1， 0010b -> x2，0100b -> x4，1000b -> x8，0000b -> x16。

▲ 图5 Link Management DLLP (Flit Mode)

 以下几种情况对应的链路管理DLLP无效，Rx收到后应予以忽略：

•    链路管理类型 或 L0p命令类型为保留字段。

•    链路管理类型 或 L0p命令类型正常，但L0p命令类型对应的链路宽度或响应负载为保留字段。

4. 进一步思考

4.1 为什么不继续采用FTS的方式了？

根据经验，为使设备工作在最坏的环境下仍能正常从L0s回退到L0，设计人员往往采用较大的N_FTS，复杂度增加是一方面，对降低功耗也不太友好。想必之下，从lane数较少的L0p回退到L0，采用EIEOS，方法更为简单直接有效。

4.2 那么切换速度可以进L0p吗？

怕是不行。不同速率下的信号质量不同，其对应的均衡、加重/去加重参数不同，每切换一种速度都需要重新进行均衡等，即需要进Recovery重新均衡后再切速。

5. 参考

1. The PCIe® 6.0 Specification Webinar Q&A: Leveling Up with L0p

2. 如何成功过渡到PCIe 6.0并应对芯片设计新挑战？

3. What Disruptive Changes to Expect from PCI Express Gen 6.0

4. PCIe 6.0时代下的IP挑战