PCIE链路训练-状态机跳转

+徐火火+

已于 2024-10-21 23:19:25 修改

阅读量1.5k

点赞数 27

分类专栏： PCIE 文章标签： fpga开发

于 2023-11-23 00:12:19 首次发布

本文链接：https://blog.csdn.net/juvenilexhq/article/details/134565939

版权

PCIE 专栏收录该内容

17 篇文章

订阅专栏

detect状态下的跳转：

detect quite -> detect active

12ms超时，或者再任何lane上检测到Electrical Idle Exit；

B(待补充)：

1.发送“receiver detection”之后没有一个lane的接收逻辑被rx检测到

2.不满足条件c，比如两次detection出现差别；

detect active -> polling acive

如果所有通道上都正常检测到接收端，那么会进入下一个状态。注意如果是有个别lane被检测，但是这些lane的总数不是所有的lane数目，那么等待12ms再次 un-configured上执行Receiver Detection sequence，如果结果和第一次相同就进入polling状态，否则进入detect状态；

---------------------------------------------------------------------------------------------------------------------------------

polling状态下的跳转：

polling active -> polling configuration（满足条件1或2之一即可）

1.满足条件（1）和（2）

（1）TX向对端发送至少1024个TS1序列（序列的link num和lane num均为pad，针对所有lane）

（2）在detect阶段被detect到的任意lane，至少收到8个连续的training sequences，这些training sequences可以是（只要满足其中一个即可）

a：TS1序列，lane num和link num均为pad，Compliance Receive bit (bit 4 of Symbol 5) 是0；

b：TS1序列，lane num和link num均为pad，Loopback bit (bit 2 of Symbol 5)是1；

c：TS2序列，lane num和link num均为pad

~~2.如果经过24ms仍然不满足1，那么满足下列条件也可以进入Polling.Configuration状态：~~

~~（1）任何一个被detect为receiver的lane收到8个连续的序列，并且满足下列条件之一：~~

~~a：TS1序列，lane num和link num均为pad，Compliance Receive bit (bit 4 of Symbol 5) 是0；~~

~~b：TS1序列，lane num和link num均为pad，Loopback bit (bit 2 of Symbol 5)是1；~~

~~c：TS2序列，lane num和link num均为pad~~

~~（2）在收到一个TS1或TS2之后的任意通道上至少发送了1024个TS1.~~

2.~~如果任意lane仍然不满足条件2（实际上2和3是并行条件，满足其中一个即可），那么~~如果自进入 Polling.Active 状态以来，有一定数量的通道上检测到至少一次退出电气空闲的现象（这个数量是预先设定的，只有超过这个数目的lane满足条件才认为满足条件），那么也可以进入Polling.Configuration状态（这是为了防止一个或者多个失效的发送端或者接收端导致链路不能能进行配置）。

polling configuration -> config link width start

当任意收到连续的8个TS2（link nun和lane num均为pad）并且自从收到TS2序列后至少发送了16个TS2序列；

polling configuration -> detect

不满足E，48ms超时；

J（待补充）：

如果满足以下条件之一可以进入loopback状态：

（1）所有发送TS1的lane上，都收到了两个连续的Loopback为1的TS1。-dsp/usp均满足

（2）任意一共发送TS1的lane上收到了两个连续的loopback为1的TS1，同时Enhanced Link Behavior Control比特为1。-dsp/usp均满足

（3）一个能支持64GT/s的port收到了TS1，并且该TS1的Flit Mode Supported bit为1，the Supported Link Speeds域为10111b。-dsp/usp均满足

注意：任意发送 Loopback 比特置位的端口将变成 Loopback master，而收到他们的端口将变成 Loopback slave。

（4）上层指示要求在detect为receiver的lane上发送的TS1或TS2，其中让loopback bit置为1；-dsp/usp均满足

K（待补充）：

Dsp：上层指示要求在detect为receiver的lane上发送的TS1或TS2，其中让disable bit置为1；

Usp：任何TS1的lane上收到了两个连续的TS1，并且TS1的disable位为1；

---------------------------------------------------------------------------------------------------------------------------------

config状态下的跳转：

config.linkwidth.start -> config.linkwidth.accept

dsp：

（1）crosslink configuration不支持的情况下：任意lane，如果先收到了一个或者多个TS1，其link num和lane num都是pad，随后又收到两个连续的TS1，其中link num为具体数值，lane num为pad，那么满足进入Configuration.Linkwidth.Accept状态的条件；

（2）crosslink configuration支持，dsp可能转变为usp，转变后的状态跳转完全遵循usp的准则。

Usp（有问题？？）：

如果一些通道接收到了两个连续的链路编号有效，通道编号为填充符号的 TS1，那么这个端口就会进入 Configuration.Linkwidth.Accept 子状态.

在这个阶段中usp是要做接收到dsp发过来的TS1（link num不为pad，lane num为pad），收到以后再将其其发给dsp，是不是可以理解为usp开始发这种ts1的时候，发了一段时间以后就会进入linkwidth.accept.

config.linkwidth.start -> detect

-dsp/usp均满足

24ms超时；

config.linkwidth.accept -> config.lanenum.wait

Dsp：

dsp不会在 Configuration.Linkwidth.Accept 子状态长时间停留。一旦dsp收到了usp发送的必须数量的TS1（至少两个连续的TS1），明确了链路宽度之后，DSP 会更新一些必须的内部状态，发送通道编号不为填充字符的TS1，并立刻转为 Configuration.Lanenum.Wait 状态，等待 USP 确认通道编号分配。

Usp：

usp必须对dsp提出的通道编号分配做出响应。如果一个链路可以由多个link num和非pad TS1的通道合并组成，并且它们接收到两个连续 TS1，其中链路编号相等，通道编号非pad，那么usp应该在可行的情况下，发送通道编号相同的TS1表示接受分配，或者在必要的时候回应不同的编号值提议。（比如应用了选配的通道顺序翻转特性时）。随后跳入下个状态。

config.linkwidth.accept -> detect

-dsp/usp均满足

2ms超时或没有链路可以配置或者所有lane上都收到了两个连续的TS1，其中link num或者lane num钧设为pad

config.lanenum.wait -> config.lanenum.accept

Dsp：

如果下述两个条件之一满足，那么跳转到 Configuration.Lanenum.Accept 状态：

（1）如果在所有通道上都接收到连续两个TS1，它们携带的链路和通道编号都和dsp在这些通道上发送的一致。

（2）如果在任意一个检测到接收方的通道上，接收到连续两个TS1，它们的通道编号和首次进入到Configuration.Lanenum.Wait接收到的TS1中的数值不一致，并且至少有一些通道接收到了有效的链路编号（其实我理解就是usp对dsp发过来的lane num改动了）。

Usp：

如果下述两个条件之一满足，那么跳转到 Configuration.Lanenum.Accept 状态：

（1）如果在所有通道上都接收到连续两个 TS2。

（2）如果在任意一个检测到接收方的通道上，接收到连续两个 TS1，它们的通道编号和首次进入到Configuration.Lanenum.Wait时接收到的 TS1 中的数值不一致，并且至少有一些通道接收到了有效的链路编号（dsp收到usp改变lane num的TS1之后再次发给usp）。

config.lanenum.wait -> detect

触发了上述的 2ms 超时事件，或者所有通道接收到两个连续的 TS1，其链路和通道编号都为填充符号。-dsp/usp均满足

config.lanenum.accept -> config.complete

dsp:

如果dsp在所有通道上都接收到连续两个TS1，它们携带的链路和通道编号都和 dsp在这些通道上发送的数值一致，那么代表usp同意了dsp通告的链路编号和通道编号，dsp随之进入 Configuration.Complete 状态。

usp:

如果 USP在所有通道上都接收到连续两个TS2，它们携带的链路和通道编号都和 USP 在这些通道上发送的 TS1 中的数值一致，那么USP 进入 Configuration.Complete 状态。

config.lanenum.accept -> detect

如果当前link不能被config或者说收到了所有lane收到了两个连续的TS1，其中link num和lane num是pad；

config.complete -> config.idle

（1）当所有发送 TS2 的通道都接收到 8 个满足条件的 TS2 时（TS2中data rate匹配等，比如link up configure），并且在接收到一个 TS2 后该通道已经发送至少 16 个 TS2 后，状态机将跳转至下一个状态：Configuration.Idle。-dsp/usp均满足

（2）2ms超时后，如果当前速率大于等于8GT/s，并且idle_to_rlock_transitioned小于'hff。-dsp/usp均满足

config.complete -> detect

2ms timeout并且当前速率是2.5GT/s或者说5GT/s。-dsp/usp均满足

config.idle -> L0

当在non-flit模式下使用8b/10b编码的时候，那么在全部已配置通道上接收到 8 个连续的idle data，并且在收到一个空闲符号后已经发送了 16 个idle data symbol，进入 L0 状态。

当在non-flit模式下采用 128b/130b 编码方式，那么在全部已配置通道上接收到 8 个连续idle data symbol，并且在收到一个idle data symbol后已经发送了 16 个idle data symbol，并且不是在 Configuration.Complete 状态超时后下进入的本状态，那么跳转至 L0 状态。

config.idle -> detect或recovery

未满足上述条件，2ms 超时后：

如果变量 “idle_to_rlock_transitioned” 小于FFh，那么下一个跳转状态是 Recovery（Recovery.Rcvrlock）。跳转后：

（a）8.0 GT/s 时，变量 idle_to_rlock_transitioned 自增 1。

（b）2.5 或者 5.0 GT/s 时，变量 idle_to_rlock_transitioned 设置为 FFh。

注意：该变量记录了因为配置过程没有起作用，从而导致状态机从 Configuration.Idle 状态跳转到 Recovery 状态的次数。这可能是因为均衡设置不合适，或者当前选择的速率无法正常工作导致的，Recovery 状态内会采取措施尝试解决这些问题。该变量限制了从本状态跳转至 Recovery 状态的尝试次数，从而避免了永久的无限循环。如果链路在 256 次尝试后（变量计数至 FFh）仍然没法正常工作，那么跳转回 Detect 状态重新开始，并希望这次能有更好的结果。

否则，即 idle_to_rlock_transitioned 为 FFh 时，跳转至 Detect 状态。

---------------------------------------------------------------------------------------------------------------------------------

recovery状态下的跳转：

1. 不涉及equalization(eg gen1 -> gen2)：

recovery.rcvrlock -> recovery.rcvrcfg -> recovery.speed -> recovery.rcvrlock -> recovery.rcvrcfg -> recovery.idle -> L0

2. 涉及equalization(eg: gen1 -> gen3)：

gen1 L0 -> recovery.rcvrlock -> recovery.rcvrcfg -> recovery.speed -> recovery.rcvrlock -> recovery eq -> recovery.rcvrlock -> recovery.rcvrcfg -> recovery idle -> gen3 L0

3.Bypass equlization to highest rate

4.No equlization needed

5.Recovery.RcvrCfg -> Recovery.Idle

（1）8个连续的TS2在所有config的lane上都受到了，并且link num，lane num和tx发送的相同、data rate identidiers相同，并且满足下列条件之一：

rx收到的连续的TS2中的speed_change为0；

当前工作速率时2.5GT/s，rx收到的或者tx发送的TS2中没有5.0GT/s或更高的data rata；

（2）在收到一个TS2之后没有被任何EIEOS打断的情况下发送了16个TS2。

6.Recovery.RcvrCfg -> configuration

non-flit mode下，在config的lane上收到了八个连续的TS1，但是收到的TS1的link num或者lane num和自己的tx发送的不匹配，并且自从收到TS1之后已经发送16个TS2（无论使用8b/10b 还是128b/130b），并且满足以下条件之一：

（1）收到的TS1中的speed_change为0；

（2）当前的速率时2.5GT/s，但是rx收到的TS1中没有大于等于5.0GT/s的速率支持或者tx发送的TS2中没有大于等于5.0GT/s的速率支持；

6.Recovery.RcvrCfg -> Recovery.Speed

情况1：

（1）满足如下条件之一：

在任意config的lane上收到了8个连续的TS2，data rate identifiers相同+symbol6中的值相同+speed_change设为1，收到的TS2是标准的TS2（采用8b/10b或128b/130b编码）；

在所有config的lane上收到了8个连续的EQ TS2或128b/130bEQ TS2，data rate identifiers相同+symbol6中的值相同+speed_change设为1；

在任意config的lane上收到了8个连续的EQ TS2或128b/130bEQ TS2，data rate identifiers相同+symbol6中的值相同+speed_change设为1，并且自从任意config lane上收到了8个连续的TS2之后已经过去1ms了；

（2）当前工作速率大于等于2.5GT/s，或者说在tx发送的TS2或者rx收到的TS2中，data rate identifiers 是大于2.5GT/s的；

（3）对于8b/10b编码，在收到speed_change为1的TS2之后，至少发送了32个TS2，并且speed_change为1（并且要求在所有config的lane上+这个过程没有被EIEOS打断）；对于128b/130b编码来说，在收到speed_change为1的TS2之后，至少发送了32个TS2，并且speed_change为1（并且要求在所有config的lane上，没有EIEOS打断的要求）；

情况2：

（1）如果当前速率自从L0/L1进入recovery状态切到双方协商的速率（changed_speed_recovery = 1b），并且EIOS已经被检测到了/Electrical Idle的条件在任意config的lane被检测到了，并且自从进入Recovery.RcvrCfg状态后没有config的lane收到了TS2，那么状态跳转到recovery.speed；

（2）如果当前速率自从L0/L1进入recovery状态没有切到双方协商的速率（changed_speed_recovery = 0b），并且EIOS已经被检测到了/Electrical Idle的条件在任意config的lane被检测到了，并且当前工作速率高于2.5GT/s，并且自从进入Recovery.RcvrCfg状态后没有config的lane收到了TS2，那么状态跳转到recovery.speed；

这张情况下双方速率要回到2.5GT/s？？

7.Recovery.RcvrCfg -> detect

48ms timeout，并且当前工作速率在2.5GT/s或5.0GT/s；

8.Recovery.RcvrCfg -> recovery.idle

情况1：

（1）所有config的lane上收到连续8个TS2，TS2的link num，lane num和tx自己发送的相互匹配，data rate相互匹配，并且满足：

rx收到的TS2中speed_change为0；或者当前数据速率为2.5 GT/s且没有请求或支持更高的数据速率（tx和rx的TS2中均没有高于5.0GT/s的速率宣告）；

（2）在收到TS2之后已经发送了16个TS2，并且这个过程没有被EIEOS打断；

此外注意，这个过程中changed_speed_recovery和directed_speed_change在进入到recovery.idle状态下会被复位成0；N_FTS值会被改变用于将来的L0s状态；当使用8b/10b编码的情况下，lane-to-lane deskew必须在离开recovery.rcvrcfg状态去完成；

情况2：

48ms timeout，idle_to_rlock_transitioned < 'hff，当前速率大于等于8.0GT/s；

5.一些异常情况：

（1）recovery.rcvrlock <-> recovery.speed

lock -> speed(满足两个条件中的一个)：

如果当前速率设置高于 2.5 GT/s，但是自从进入 Recovery 状态后，从来没能在该速率下正常工作过，（变量 changed_speed_recovery 被清除为 0 揭示了这种现象）。此时，待离开 Recovery.Speed 状态后，速率会重新降低为 2.5 GT/s。
如果变量 changed_speed_recovery 被设置为 1，表示某个高于 2.5 GT/s 的速率已经能够正常工作，但是在切换到新的协商速率后，链路不能工作，这种情况下速率会被恢复为由 L0 或者 L1 进入 Recovery 状态前的数值。

speed -> lock:

通过timeout实现。

（2）recovery eq -> recovery speed（以down端举例）