LTSSM – Configuration
|
|
0
|
PCIe
|
重新开始

11352 字
|
50 分钟

Configuration状态简介

Configuation是LTSSM中比较复杂的一个状态，按照协议篇幅，其内容仅次于Recovery状态。在这个状态，LTSSM主要是确定好link number和lane number，不过随着pcie协议的发展，功能逐渐增加，使得一些其它工作也必须放到Configuration状态来完成。根据pcie spec 6.2的描述，Configuration状态需要处理的事情包括(可能没列全，如有遗漏，欢迎补充):

  • link number和 lane number的确定
  • Flit模式协商(gen6 新增)
  • L0p协商(gen6新增)
  • 时钟模式协商(gen6新增)
  • 协议切换，是否支持其它协议
  • lane-to-lane deskew，消除lane与lane之间的数据偏差
  • 决定是否需要做EQ，以及EQ方式

Configuration又可细分为6个子状态，分别是

  • Configuration.Linkwidth.Start
  • Configuration.Linkwidth.Accept
  • Configuration.Lanenum.Wait
  • Configuration.Lanenum.Accept
  • Configuration.Complete
  • Configuration.Ilde

其中Configuration.Linkwidth.Start和Configuration.Linkwidth.Accept如名字所言，主要负责Link Number的确定，也还负责确定是否支持其它协议和Flit Mode的协商;Configuration.Lanenum.Wait和Configuration.Lanenum.Accpet主要负责Lane Number的确定，也还负责是否需要切换协议以及时钟模式的确定;Configuration.Complete状态需要再次确定协商好的link number和lane number，还包括lane-to-lane deskew和Flit Mode协商; Configurationi.Idle则需要做lane-to-lane deskew和是否需要做EQ以及EQ方式。

需要注意的是，Configuration状态涉及到link number和lane number的确定，中间有相当于有一个握手的过程，因此DSP和USP在不同的子状态行为会有所区别，具体的过程见下文。

Configuration.Linkwidth.Start

DSP Configuration.Linkwidth.Start时的行为

首先是最简单的情况，LTSSM初次进入Configuration.Linkwidth.Start时，此时LinkUp为0，表明链路还没有训练起来，发射机(DSP的TX方向)在所有active的Downstream lane上发送符合下列特征的TS1OS(后文该状态默认只关注link number和lane nubmer，如无特殊说明，其它symbol默认符合下列特征)

  • link number为特定的值(比如0)，lane number都是PAD
  • 速度标识(Symbol 4)必须是本端所有支持的速度，包括不打算用的
  • 其它symbol则按照TS1的要求发送

此时Active的lane定义为在Detect状态检测到接收机的lane。即初次训练(该状态是由Polling状态跳转而来)，该条lane在Detect状态检测到接收机存在，就是active的lane。如果不是初次训练(该状态是由Recovery状态跳转而来)，active的lane则定义为前一次经过Configuration.Complete后协商出来的lane。比如初次协商成了x8的link，在从Recovery进入到Configuration时，这8条lane都是active的lane，然后最后协商成了x4，在从Recovery进入Configuratoin时，只有这4条lane时active的lane，另外的4条lane则为inactive的lane。

对于inactive的lane的行为，协议对此没有明确说明，这里就有几种可能性

  • 对DSP而言:
    • 即可以啥也不发，这些lane处于电气空闲状态(Electical Idle，简称EI)
    • 或者发送link number和lane number都是PAD的TS1OS，DSP发起的升lane操作也会有此行为
    • 或者乱发一些数据，这种设计可以排除，实际没啥意义，排除掉
  • 对USP而言，
    • 可以啥也不发，这些lane处于EI，
    • 乱发一些数据，但是不能发送link number和lane number都是PAD的数据，因为USP正常工作时也会发送link number和lane number都为PAD的TS1OS。乱发对实际设计没啥意义，排除掉。

但是从协议里面推测，inactive的lane是需要处于电气空闲才是比较符合意图的。但是因为link number和lane number是一个协商的过程，所以即使有一方做的不是完全符合协议，最后也能协商成功。为了简化，后续如无特殊说明，所有/任意lane默认都是指active的lane，inactive的lane不在所有lane/任意lane的范畴

前面是初次进入Configuration的情况。接着情况会复杂一点，如果此时LinkUp为1，则该状态则只能是从Recovery进入，因为只有重新进入Detect，才会清掉LinkUp。此时发射机的行为取决于LTSSM是否需要升lane(提升链路宽度)。如果不需要升lane，则跟前面的行为一样，在Active的lane发送link number为特定的值和lane number是PAD的TS1OS。不需要升lane的情况分3种:

  • 一种是不支持升lane，即upconfigure_capable为0，
  • 一种是虽然upconfigure_capable为1，但是DSP LTSSM不打算升lane，对应协议中原话为(pcie spec6.2 p511)

    if the LTSSM is not initiating upconfiguration of the Link width.

  • 还有一种是upconfigure_capable为1，但是USP LTSSM不打算升lane。

最后就是upconfigure_capable为1，且LTSSM想要升lane，这里也得分两种情况讨论:

  • DSP发起的升lane操作
  • USP发起的升lane操作

如果是DSP发起的升lane操作，那DSP不光会在active的lane上发link number和lane number都为PAD的TS1OS，也会在想要active的lane上发link number和lane number都为PAD的TS1OS。想要active的lane就是降lane后又打算重新启用的lane，还是刚才的例子，x8降到x4，在正常发送TLP包/Idle的4条lane是active，另外4条是inactive的，但是为了提高带宽，这四条lane也需要利用起来，DSP就需要主动升lane(软件可以配置target_link_width)，先进Recovery，然后进入Configuration.Linkwidth.Start，在8条lane上都发送link number和lane number为PAD的TS1OS。

因为是DSP主动发起的升lane操作，所以DSP是知道哪些lane是需要用起来的，所以就在需要用起来的lane发送link number和lane number都为PAD的TS1OS。只有在发送link number和lane number都为PAD的lane上收到link number和lane number都是PAD的TS1OS之后(数量要求是2个)，才会在收到link number和lane number的lane上发送link number为特定值且lane number为PAD的TS1OS。如果一直都收不到link number和lane number为PAD的TS1OS呢，协议规定1ms超时后必须得发送link number为特定值，lane number为PAD的TS1OS。这个地方先抛出一个问题，既然是DSP发起的升lane，一刚开始就发送link number为特定值，lane number为PAD的TS1OS行不行？等到后面讲USP在Configuration.Linkwidth.Start时再来回到这个问题。

如果是USP发起的升lane操作，此时DSP并不知道哪些lane是需要active的，它只能推断，条件首先是某条lane认为对端是否退出了EI，本端收到了EIOS就会认为对端推出了EI，其次是该条lane是否收到了2个连续link number和lane number都是PAD的TS1OS。因为升lane如果是USP发起，那么USP会先进入Configuration.Linkwidth.Start，在USP想要active的lane上也发送link number和lane number都是PAD的TS1OS，此时DSP的inactive的lane就会收到n个连续link number和lane number都是PAD的TS1OS，DSP就认为这些lane是需要用起来的，然后在这些lane上也发送link number为特定值和lane number为PAD的TS1OS。

升lane操作需要把inactive的lane变成active，这个过程需要一定的时间，发射机必须等到TX共模电压稳定后才能退出EI，开始发送TS1OS。

如果某些lane能形成一组link，另外的一些lane能形成另外一组link，在这两组行能形成link的lane上发送的link number必须不同。协议举了一个例子:Downstream lane可以形成1个x8的port， 也可以接2个不同的设备，形成2个x4的port。当为后者时，DSP在其中4条lane发送link number为 N， lane number为PAD的TS1， 在另外4条 lane 发送 link number为N+1， lane number为PAD的TS1。这种做法其内部必须存在多个LTSSM来管理每个链路的状态，其实就是行为就是支持多端口的RC。

DSP在Configuration.Linkwidth.Start link number和lane number的发送规则基本已经讲完。在此状态TS1OS中symbol 4所声明的速度必须是所有支持的速度，包括不算用的，需要注意的是Flit Mode和Non Flit Mode，symbol 4的编码有变化。如果支持Flit Mode，则需要通过TS1OS中的symbol 4 bit[0]告知对方，在pcie5.0及以前，symbol 4 bit[0]保留，在pcie6.0的时候，如果该比特为1，则是在告知对方，本端支持Flit Mode。

如果不期望链路训练起来，比如要做loopback测试或者需要进入hot reset等，这个时候对DSP中TS1OS里面的Sybmol 5(TS参考)就有要求:

  • 如果需要进入到Hot Reset状态，DSP则需要把symobl 5的bit[0]置为1，具体做法通常是软件配置某个寄存器。
  • 如果需要进入到Disabled状态，DSP则需要把Sybmol 5的bit[1]置为1
  • 如果需要从进入Loopback状态，DSP则需要把Symbol 5的bit[2]置为1，主动进入Loopback的一方称为Loopback lead

USP Configuration.Linkwidth.Start时的行为

USP的发射机在Configuration.Linkwidth.Start也是发送TS1OS，但是TS1OS里面的内容跟DSP发送的会不太一样，USP发送的TS1OS需要满足下列要求:

  • link number和lane number都是PAD
  • 速度标识(Symbol 4)必须是本端所有支持的速度，包括不打算用的
  • 其它symbol则按照TS1的要求发送

因为有多少条link是由DSP来决定的，所以USP刚开始不能发送link number为特定值的TS1OS，只有在收到特定link number的TS1OS后，才能发送相同link number的TS1OS给对方。

首先还是最简单的情况，USP的LTSSM第一次进入Configuration.Linkwidth.Start，它在active的lane上发送link number和lane number都是PAD的TS1OS。

如果linkup为1，但是LTSSM不想升lane，USP还是在active的lane上发link number和lane number都是PAD的TS1OS。不想升lane包括以下三种情况:

  • USP不支持升lane，即USP的upconfigure_capable为0
  • USP的upconfigure_capable为1，但是USP不打算升lane
  • USP的upconfigure_capable为1，但是DSP不打算升lane

如果linkup为1且想要升lane，有以下两种情况:

  • DSP想要升lane
  • USP想要升lane

如果是DSP想要lane，则DSP会在所有active的lane和想要active的lane上发link number和lane number都是PAD的TS1OS， USP的这些inactive的lane会检测到对方退出了EI，并且收到了2个连续link number和lane number都是PAD的TS1OS后，USP才在这些inactive的lane发送link number和lane number都是PAD的TS1OS。这个地方就解释了前面的疑问，DSP发起的升lane操作必须刚开始发送link number和lane number都是PAD的TS1OS。如果不这样做，USP也严格按照协议做，最后可能导致升lane失败。因为虽然DSP想要把部分inactive的lane给active起来，因为USP没有收到link number和lane number都为PAD的TS1OS，USP可以认为这部分lane是不需要active的，UPS可以选择不active这部分lane，即不发link number和lane number都是PAD的TS1OS，并且也是不违反协议的。这里也说明inactive的lane应该是处于EI才是合理的。

如果是USP想要升lane，则USP会在所有active以及想要active的lane上发送link number和lane number都是PAD的TS1OS，具体过程跟前面DSP在Configuration.Linkwidth.Start时的行为一致，不做过多描述。

如果改变宽度的过程是自动的，即该状态不是由recovery状态超时而来，还必须要把TS1OS中的autonomous change设置为1(symbol 4 bit 6)，USP发送的其它symbol跟DSP行为一致，不做过多描述。

NOTE：协议在此章节还有部分描述，但是仔细观察就会发现这部分是针对进入Configuration.Linkwidth.Accept之后的行为。

Configuration.Linkwidth.Start状态跳转图

Configuration.Linkwidth.Start状态跳转

DSP Configuration.Linkwidth.Start状态跳转

正常训练时， DSP会收到来自USP发送的TS1OS，其link number和lane number都是PAD，任意一条收到link number和lane number都是TS1OS的lane，如果收到了link number跟DSP发送出去一致且lane number为PAD的TS1OS后，就跳转到下一个状态Configuration.Linkwidth.Accept。但是USP在Configuration.Linkwidth.Start时发送的TS1OS中link number和lane number都是PAD，DSP如何能接收到link numbeb跟发出去一致的TS1OS呢。所以这个地方就需要USP先到Configuration.Linkwidth.Accept去发送link number为特定值，lane number为PAD的TS1OS。所以正常训练中，USP会先进入Configuration.Linkwidth.Accept。

所以到目前这个阶段，DSP和USP的LTSSM先后关系如下:

  1. DSP/USP Configuration.Linkwidth.Start(刚开始不定)
  2. USP Configuration.Linkwidth.Accept

如果是DSP想要进入Disabled状态，则DSP可以直接从该状态进入Disabled状态，并且在所有lane上发送Disabled比特为1的TS1OS。进入Disabled的发起方只能是DSP，不能是USP，因为如果一方要进入Disabled，则另外一方也需要进入Disabled，然后双方互发disabled link为1的TS1OS，在进入Disabled状态后，软件就无法干预USP的行为了，即USP不能发起退出Disabled的操作，所以也不能发起进入Disabled的操作。状态跳转图中提到了一个crosslink，DSP可能会收到disabled link比特为1的TS1OS，这跟USP不能发起进入Disabled的操作不矛盾。

crosslink连接是一种比较特殊的连接方式，即DSP连接到DSP上，需要双方都支持crosslink才行。DSP接DSP，那岂不是在Configuration.Linkwidth.Start都是发送link number为特定值，lane number为PAD的TS1OS，刚开始的行为确是如此，协议规定支持crosslink必须先发送16到32个TS1OS。在非crosslink情况下，DSP应该收到link number和lane number都是PAD的TS1OS，如果DSP收到link number为非PAD值，lane number为PAD的TS1OS，这个时候就需要决定出来谁才能作为”真正”的DSP。做法大概如下:

  • 随机延迟一段时间，比如DSP 1先达到延迟时间
  • DSP 1达到设定的延迟时间，于是DSP 1就不再发送link number为特定值，lane number为PAD的TS1OS，而是发送link number和lane number都是PAD的TS1OS，后续所有DSP 1的行为就如同USP。
  • DSP 2收到link number和lane number都是PAD的TS1OS后，继续保持DSP的行为

据我了解，crosslink在实际中基本不会用到，后续如果状态跳转中出现了crosslink，默认跳过。不支持crosslink的设备，在往Configuration.Linkwidth.Accept跳转的先决条件之一总是满足。

任意收到link number和lane number都是PAD的的TS1OS

虽然DSP进入Disabled状态时，协议规定的是需要在所有lane上发送disabled比特为1的TS1OS，但是我只在部分lane上发送disabled比特为1的TS1OS行不行呢？答案是不行的，因为正常训练始终具有最高优先级，一般不会无缘无故进入Disabled或者Hot Reset或者Loopback，如果DSP只在部分lane上发送disabled比特为1的TS1OS，那么USP的某条lane可能收不到，这样USP就无法进入Disabled状态，不是预期的行为。

如果DSP是要想进入Loopback，那它可以直接从Configuration.Linkwidth.Start状态进入到Loopback，并在所有lane上发送loopback比特为1的TS1OS。由于loopback测试通常是做完测试后不需要在训练起来，跟进入Disalbed状态和Hot Reset状态不一致，所以就不存在只能由哪一方来发起的说法。那也可以是因为收到loopback比特为1的TS1OS进入Loopback状态。根据是部分lane还是所有lane，对收到的2个连续TS1OS的要求也不同:

  • 如果是所有lane，不要求symbol 5 bit[7:6] Enhanced Behavior control
  • 如果是任意一条lane，则需要Enhanced Behavior control为01b

如果port支持64.0GT/s，因为收到TS1OS而被动进入Loopback，那么此时收到的TS1OS中，可以出现symbol 4 bit[0]为1，然后速率编码bit[5:1]为10111b。因为做loopback测试，需要明确速度，而在Polling状态，如果不是需要进入Polling.Compliance，发出去的TS1OS中又不能支持声明高于32.0GT/s的速度，所以就只能在Configuration.Linkwidth.Start声明支持64.0GT/s。

如果LTSSM在24ms之内既不能跳到Configuration.Linkwidth.Accept，也不能跳到Disabled和Loopback，那么只能跳到Detect状态。举个例子，USP所有lane都不稳定，以至于DSP无法识别，且DSP也不打算去Disabled或者Loopback，那就只能跳到Detect去。

USP Configuration.Linkwidth.Start状态跳转

USP的任意一条lane收到2个连续的Link number不为PAD，lane number为PAD的TS1OS后，USP LTSSM进入Conifugration.Linkwidth.Accept。

USP进入Disabled只能是被动进入，即只能收收到disabled bit为1的TS1OS进入，进入Loopback和Detect的条件与DSP一致，跳过。

Configuration.Linkwidth.Accept

DSP Configuration.Linkwidth.Accept时的行为

DSP在Configuration.Linkwidth.Accept发送的TS1OS跟在Configuration.Linkwidth.Start是一样的。但是在这个状态，DSP会检查收到的TS1OS，在决定是否可以跳到Configuration.Lanenum.Wait状态。

NOTE：协议在这一块的描述花了不少篇幅，但是注意观察就会发现，这些描述都是针对DSP进入Configuration.Lanenum.Wait之后的行为。

USP Configuration.Linkwidth.Accept时的行为

USP进入到此状态的条件是任何一条lane接收到2个连续的TS1OS， 其中link numberPAD， lane number为PAD。在进入该状态后，USP就需要更新其发送TS1OS中的link number，link number设置为收到TS1OS中的link number。USP发送出去的TS1OS中，lane number仍为PAD，其它symbol跟在Configuration.Linkwidth.Start一致。

如果USP想要发起升lane，则USP需要等所有它想要active的lane也收到link number非PAD，lane number为PAD的TS1后，才会决定是否往下一个状态跳转，但是对等待时间是有要求的。万一DSP由于某些原因就不想升lane呢或者只想active部分laen呢，所以在进入Configuration.Linkwidth.Accpet后的1ms后，如果有些lane收到了link number非PAD，lane number为PAD的TS1OS，那USP就在这些lane发送特定link number和lane number为PAD的TS1OS。如果进入此状态1ms后，想要active的还是没有收到link number为非PAD，lane number为PAD的TS1OS，USP那就只能接着发link number和lane number都是PAD的TS1OS，但是此时状态机应该是已经跳转到下一个状态了。

对于一条link由多条lane组成，可能会遇到某些lane上收到的TS1OS有误，或者是128b/130b block alignment丢失或者是1b/1b下block/flit alignment丢失，在这些异常的情况下，为了防止形成的链路宽度可能比预期的低，协议是**推荐(不强制)**多判断一些TS1OS，以此来确保有些lane是真的无法形成link，而不是因为一些偶然的因素导致最后协商的链路宽度偏低。

具体需要多判断的TS1OS数量跟编码有关，本来在此状态只需要评估连续2个TS1OS就行了，如果发生了上述异常，在8b/10b编码下需要多评估2个或者以上，128b/130b编码或者1b/1b编码需要多判断34个或者更多，TS1OS数量上限没有规定，但是时间不能超过1ms。此处是协议推荐的做法，所以即使实际没有按这么做，也不算违反协议。

同DSP一样，协议在此处花了不少篇幅来描述，但是仔细观察也可以发现，这些行为是针对进入Configuration.Lanenum.Wait的。

Configuration.Linkwidth.Accept状态跳转图

Configuratioin.LinkWidth.Accept状态跳转

DSP Configuration.Linkwidth.Accept状态跳转

在Configuration.Linkwidth.Accept状态，不管是初次训练，还是升/降lane，DSP在这个状态都是期望能收到link number跟发出去一致且lane number为PAD的TS1OS。如果某些lane能收到lane number跟发出去一致且lane number为PAD的TS1OS，且这些lane可以形成link，下一个状态就是Configuration.Lanenum.Wait。这里能形成link是指能形成x1/x2/x4/x8/x16的link，形成不了link，就无法进入到Configuration.Lanenum.Wait状态去做lane number的协商。形成不了link的情况，比如说在Detect状态检测到了4条lane，然后DSP在Configuration.Linkwidth.Accept状态只有lane 2收到符合要求的TS1OS,因为无法只使用lane 2作为x1的link,所以这种情况无法形成link。

因为USP跳转到Configuration.Lanenum.Wait是要收到lane number非PAD都TS1OS,而DSP只有在Configuration.Lanenum.Wait才会发送lane number不为PAD的TS1OS,所以正常训练下，DSP先进入Configuration.Lanenum.Wait

到目前，DSP和USP ltssm的先后关系如下:

  1. DSP/USP Configuration.Linkwidth.Start(刚开始不定)
  2. USP Configuration.Linkwidth.Accept
  3. DSP Configuration.Linkwidth.Accept
  4. DSP Configuration.Lanenum.Wait

实际情况不能排除有些lane收到的TS1OS是合理的，有些TS1OS中是有错误的(比如128b/130b编码时TS1OS中parity校验位不对),或者128b/130b Block Alignment丢失或者1b/1b编码下Block/Flit Aligment丢失，为了避免在这些情况最后协商的宽度偏小，在跳转到Configuration.Lanenum.Wait前，协议推荐(不强制)需要评估更多的TS1OS，在8b/10b编码下需要额外评估2个或者更多，在128b/130b或者1b/1b编码下需要额外评估34个或者更多，但是评估时间不能超过1ms。

正常是期望能收到link number跟本端发出去一致且lane number为PAD的TS1OS，但是如果所有lane收到了link number和lane number都是PAD的TS1OS，那DSP只能跳转到Detect。这种情况对应于USP从Configuration.Linkwidth.Accept进入到了Detect，因为USP只有在Polling.Active和Configuration.Linkwidth.Start时，才是所有lane都发出link number和lane nubmer都是PAD的TS1OS。而只有USP先进入了Configuration.Linkwidth.Accept之后，DSP才能进入Configuration.Linkwidth.Accpet，且USP又不能从Configuration.Linkwidth.Accept跳转到Configuration.Linkwidth.Start，所以就只能USP从Configuration.Linwidth.Accept进入了Detect,然后很快就进入Polling.Active，在所有lane上link number和lane number都是PAD的TS1OS，由于USP都重新进入Detect，所以DSP也重新进入Detect。

不能形成link，也需要从Configuration.Linkwidth.Accept进入Detect，比如说在Detect状态检测到了4条lane存在，但是在Configuration.Linkwidth.Aceept时，lane 0和lane 3都没收到TS1OS，只有lane 1和lane 2收到了，这种情况下，用lane 1和lane 2也无法形成link，没必要进行后续lane number的协商了，也只能到回到Detect。

协议规定还有一个条件，DSP也可以从Configuration.Linkwidth.Accept进入到Detect，那就是2ms超时后，强制进入Detect。这种情况我理解的是所有lane都收不到TS1OS，因为如果某些lane能收到TS1OS，那么就可以从能收到TS1OS的这些lane中判断出来是否可以形成link，而不管能否形成link，都可以跳转到其他状态去。而所有lane都收不到TS1OS(或者是无法识别出来)，能否形成link就无法得知，就不能贸然跳到Detect去，万一一段时间后，有些lane就能收到或者识别出来TS1OS了呢。

USP Configuration.Linkwidth.Accept 状态跳转

USP要从Configuration.Linkwidth.Accept进入到Configuration.Lanenum.Wait对TS1OS的要求是link number和lane number都不是PAD，而只有DSP进入到Configuration.Lanenum.Wait后，才能发出lane nubmer不为PAD的TS1OS，所以正常训练中，DSP先进入Configuration.Lanenum.Wait。其它状态条件同DSP一样，跳过。

Configuration.Lanenum.Wait

DSP Configuration.Lanenum.Wait时的行为

协议此章节描述有不少篇幅，但是是针对在Configuration.Lanenum.Accept的。同样，该状态的部分行为是写在Configuration.Linkwidth.Accept状态的

DSP进入到Configuration.Lanenum.Wait时，就需要开始lane number的协商。本端发出去的TS1OS中lane number会有所变化。如果某些lane上收到的TS1OS中link number跟该条lane中发出去的link number一致，那DSP就会在这些lane上发送link number非PAD，然后lane number也非PAD的TS1OS。具体lane number的规则如下：

  1. 发送出去的TS1OS中lane number具体值跟物理lane有关
  2. lane number的取值范围为0到n-1，n最大为Detect状态检测到接收机数量
  3. lane number必须连续

对于某些lane，如果没收到TS1OS，或者收到的TS1OS中link number跟本端发出去的不一致，DSP需要在这些lane上发送link number和lane number都是PAD的TS1OS。

举个例子

比如DSP在Detect检测到了4条lane，在Configuration.Lanenum.Wait只有lane 0/1收到了TS1OS，lane2/3没收到TS1OS，那DSP在lane 0上发送link number为0，lane number为0的TS1OS，在lane 1上发送link number为0，lane number为1的TS1OS，在lane 2/3上发送link number和lane number都是PAD的TS1OS。

协议上没有提到降lane时的一些具体行为，但是根据推测RC发起降lane时，会在此状态，在不用的lane上发送link number和lane number为PAD的TS1OS。

在进入Configuration.Lanenum.Wait状态时，还肩负着根据接收的TS1OS来决定是否使用modified TS1/2OS和使用使能Flit Mode。

是否使用modified TS1/2OS由一个变量use_modified_TS1_TS2_Ordered_Set来决定，如果use_modified_TS1_TS2_Ordered_Set为1，就表明在后续协商过程中需要使用Modified TS1/2OS，否则就不使用Modified TS1/2OS。

只要同时满足以下三个条件是，才能把use_modified_TS1_TS2_Ordered_Set置为1：

  1. LinkUp = 0b, 因为涉及到协议切换，链路训练起来后不允许切换协议。
  2. 本端在进入Polling状态后，在Polling和Configuration状态发送的TS1OS和TS2OS中，Symbol 5 bit[7:6] Enhanced Link Behavior Control为11b。表明本端支持Modified TS1/2OS。
  3. 如果某一组lane可以形成link，在LTSSM从Polling.Configuration跳转到Configuration时，这些能形成link的所有lane上收到的8个连续TS2OS中symbol 5 bit[7:6] Enhanced Link Behavior Control为11b,并且symbol 4表明对方支持32.0GT/s的速度。这里就表明对方也是支持Modified TS1/2OS的。

上面的话简言之就是在初次训练时，如果两端都支持Modified TS1/2OS，那后面信息的交互就使用Modified TS1/2OS。这里有一个小的点，是能形成link的所有lane都要收到符合symbol 5 bit[7:6]为11b的TS2OS，如果能形成x4的link,但是只有3条lane收到了symbot 5 bit[7:6]为11b的TS2OS，按理说是不应该把use_modified_TS1_TS2_Ordered_Set置为1的。但是正常情况，所有lane发送TS2OS的symbol 5应该保持一致，如果不一致，说明某条lane上有异常，不把use_modified_TS1_TS2_Ordered_Set置1也合理。

对于Flit Mode的协商也是类似，在初始训练时，如果两端都支持Flit Mode，那后面就工作在Flit Mode下面。是否工作在Flit Mode下面是由Flit_Mode_Enabled来决定，为1表示工作在FLit Mode，为0表示工作在Non Flit Mode下面。Flit_Mode_Enabled置1的条件是：

  • LinkUp = 0b
  • 本端从进入Polling状态时，在Polling和Configuration状态发送的TS1/2OS中，Symbol 4 bit[0] Flit Mode Supported为1，即本端支持Flit Mode
  • 本端从Polling.Configuration跳转到Configuration时，在能形成link的所有lane上收到的TS2OS中Symbol 4 bit 0 Flit Mode Supported为1，这表明对方也是支持Flit Mode。

值得注意的是，use_modified_TS1_TS2_Ordered_Set和Flit_Mode_Enabled两个是正交的，即互不影响，没有必然关联，即存在4种组合，对USP也适用。

USP Configuration.Lanenum.Wait时的行为

协议针对USP在Configuration.Lanenum.Wait的行为是在Configuration.Linkwidth.Accept状态描述的

USP在进入此状态后，本端发送TS1OS中的lane number会有所变化，如果某些lane收到的TS1OS中link number和Lane Number都不是PAD，USP就会考虑这些lane能否形成link以及能形成多宽的链路。一个基本的规则是lane number必须从0往上连续增加。而在不能形成link的lane上发送link number和lane number都是PAD的TS1OS。

为了防止某些错误或者skew的原因导致最后宽度偏小, Upstream lane允许延迟1ms进入Configuration.Lanenum.Accept

举个例子：比如在EP是一个x16的设备，

  • lane 0到lane 15都收到了符合要求的TS1OS(连续2个link number非PAD,lane number非PAD的TS1OS)，那么USP就在lane 0上发送lane number为0的TS1OS,lane 1上发送lane number为1的TS1OS,…,lane 15上发送lane number为15的TS1OS。
  • 如果lane 8没有符合要求的TS1OS，那么最多就只能用lane 0到lane 7形成x8的链路，为了保持lane number的连续性，就在lane 0上发送lane number为0的TS1OS,lane 7上发送lan number为7的TS1OS。在lane 8到lane 15上发送link number和lane number都是PAD的TS1OS。
  • 如果lane 0没有收到符合要求的TS1OS，且本端不具有lane reversal(反转)的能力，则不能形成link，在所有lane上发送link number和lane number都是PAD的TS1OS。
  • 如果lane 0没有收到符合要求的TS1OS,且本端具有lane reversal的能力，那么就需要做lane reversal,使用lane 8 到lane 15来形成link,就在lane 15上发送lane number为0的TS1OS,lane 8上发送lane number为7的TS1OS，lane 0 到lane 7上发送link number和lane number都是PAD的TS1OS。

USP在进入此状态也需要判断use_modified_TS1_TS2_Ordered_Set和Flit_Mode_Enabled是否需要置为1，判断方法同DSP，略过。

Configuration.Lanenum.Wait状态跳转图

Configuration状态跳转

DSP Configuration.Lanenum.Wait状态跳转图

如果是初次训练,根据DSP和USP LTSSM的先后关系，可知DSP在初次进入Configuration.Lanenum.Wait时，收到的TS1OS中link number为非PAD,lane number为PAD，如果在此状态，任意一条lane收到的2个连续TS1OS中lane number不为PAD，那说明USP也进入了Configuration.Lanenum.Wait状态，DSP就需要进入Configuration.Lanenum.Accept进行Lane number的一个确认。实际上，对于正常的初次训练而言，DSP在进入Configuration.Lanenum.Wait时，发送给DSP的TS1OS中，link number和lane number就是跟DSP发送出去的一致。所以正常的初次训练中，DSP从Configuration.Lanenum.Wait跳转到Configuration.Lanenum.Accpet的两个条件是同时满足的。

DSP从Configuration.Lanenum.Wait跳转到Configuration.Lanenum.Accept的条件一中，ep发起降lane时也会发生收到的TS1OS中lane number与第一次进入Configuration.Lanenum.Wait时不一样。详细可参见最后的“例2 EP发起降lane的操作”

DSP异常跳转进Detect一个是2ms超时，另一个收到link number和lane number都是PAD的TS1OS，说明对端可能也进入了Detect。

USP Configuration.Lanenum.Wait状态跳转图

在正常的初次链路协商过程中，USP进入Configuration.Lanenum.Wait时，收到的TS1OS中，lane number不为PAD,是特定的值，且此后DSP不会改变其TS1OS中lane number的值，所以USP在初次训练中正常是因为收到TS2OS而进入的Configuration.Lanenum.Accept。

USP因收到的TS1OS中lane number与第一次进入Configuration.Lanenum.Wait而跳转到Configuration.Lanenum.Accpet时的情况在自后的“例2 EP发起降lane的操作”也有体现。

异常情况同DSP，略过。

Configuration.Lanenum.Accept

在此状态，如果在前面已经把变量use_modified_TS1_TS2_Ordered_Sets设置为1了，发射机必须发送Modified TS1OS而不是TS1OS，一方use_modified_TS1_TS2_Ordered_Sets为1，则另外一方也应该是1，接收方也必须检查收到的是不是Modified TS1OS。

DSP Configuration.Lanenum.Accept时的行为

DSP在此状态仍然是发送TS1OS,跟Configuration.lanenum.Wait一致。

  • Retimers 允许延迟跳转到 Configuration.Complete

USP Configuration.Lanenum.Accept时的行为

USP在此状态发送的TS1OS跟Configuration.Lanenum.Wait一致。

Configuration.Lanenum.Accept状态跳转图

Configuration.Lanenum.Accept状态跳转

DSP Configuration.Lanenum.Accept状态跳转图

当发送link number和lane number的所有lane都收到link number非PAD,lane number跟某条lane发送出的一致且不为PAD，DSP就会跳到Configuration.Complete。如果use_modified_TS1_TS2_Ordered_Sets为1且准备切协议时，需要延迟进入Configuration.Complete,延迟时间为10us或者收到来自对端的确认。

如果只有部分lane能收到符合上面要求的TS1OS，则需要判断能否形成link，如果这部分lane能形成link，那就需要重新进入Configuration.Lanenum.Wait来协商lane number。如果不能形成link，那就只有去Detect。

如果所有lane都收到link number和lane number都是PAD的TS1OS，那也只有去Detect

USP Configuration.Lanenum.Accept状态跳转图

USP Configuration.Lanenum.Accept往Configuration.Complete跳转时是收到TS2OS，而不是TS1OS,这一点与DSP有所不同，其他跳转条件同DSP一样，略过。所以正常训练时，DSP现在Configuration.Complete：

到目前，DSP和USP ltssm的先后关系如下:

  1. DSP/USP Configuration.Linkwidth.Start(刚开始不定)
  2. USP Configuration.Linkwidth.Accept
  3. DSP Configuration.Linkwidth.Accept
  4. DSP Configuration.Lanenum.Wait
  5. USP Configuration.Lanenum.Wait
  6. USP Configuration.Lanenum.Accept
  7. DSP Configuration.Lanenum.Accept
  8. DSP Configuration.Complete
  9. USP Configuration.Complete

Configuration.Complete

  • 通用的行为:
    • NOTE:如没有特殊说明，这些是对发射方向的要求，即发射机在进入时可以改变其TS2中的某些symbol，但是此后不允许在改变
    • port可以在进入该状态时允许改变支持的速度，但是在此状态不允许这些值(位于TS2中的symbol 4)
    • 如果Flit_Mode_Enabled为0且LinkUp为1，在进入此状态时，port可以改变它建议的Upconfigure(通过TS2)，但是在此状态不允许在改变这些值
    • 如果Flit_Mode_Enabled为1且LinkUp为0，在进入此状态时，port可以改变它建议的L0p Capability(通过TS2)，但是在此状态不允许改变这些值
    • 在此状态，如果变量use_modified_TS1_TS2_Ordered_sets为1:
      • 发射机必须发送Modified TS2有序集而不是TS2有序集
      • 接收机必须检查接收到的TS2类型，必须为Modified TS2而不是TS2

DSP Configuration.Complete时的行为

部分行为协议是写在Configuration.Lanenum.Accept章节。

在从Configuration.Lanenum.Accept跳转到Configuration.Complete时，还需要确定变量SRIS_Mode_Enabled(gen6新增)和寄存器Link Status寄存中Link Bandwidth Management Status和Link Autonomous
Bandwidth Status的值。

SRIS_Mode_Enabled在同时满足下面两个情况下需要设置为1：

  1. LinkUp = 0b
  2. port在进入Configuration以来，发送出去的TS1OS中SRIS Clocking(Symbol 4 bit 7)为1,这表明本段是支持SRIS的。

Link Bandwidth Management Status和Link Autonomous Bandwidth Status的更新原则如下：

  1. 如果DSP由于链路可靠性问题发起宽度切换，则必须设置Link Bandwidth Management Status为1
  2. 如果宽度改变不是由DSP发起，而是由USP发起，且DSP收到的2个连续TS1OS中，Autonomous change(Symbol 4 bit 6)为0，则DSP必须把Link Bandwidth Management Status设置为1
  3. 如果上面两个条件都不满足，则设置Link Autonomous Bandwidth Status为1

DSP在此状态需要发送TS2OS，TS2OS中的一些字段按照如下规则设置：

  • link number和lane number为前面协商好的值
  • 如果port支持Link upconfigure，则发送出去的TS2OS中，Link Upconfigure/L0p Capability(symbol 4 bit 6)必须设置1，TS2OS的symbol 4 bit 6是一个多功能位，在不同状态的会代表不同的意义。
  • 如果支持L0s，则N_FTS必须设置好，N_FTS在Flit Mode不需要。

如果当前编码是8b/10b编码，在离开该状态时，lane-to-lane de-skew必须完成，但是如果没有完成de-skew，并不影响状态跳转

有时为了debug使用，需要看到原始数据，就可以禁止加扰，如果所有lane收到的连续2个TS2OS中，Disable Scrambling为1，则不允许使用加扰。发送Disable Scrambling的Port也必须禁止加扰，否则两端数据不一致，无法正确解析。禁止加扰只允许在8b/10b编码下使用，其他编码下禁止使用。因为其他编码下，加扰还可以防止出现长0和长1。如果出现长0后，后面收到的1可能无法识别出来，而8b/10b编码中，8b/10b编码本身就能避免长0和长1的出现。

USP Configuration.Complete时的行为

USP在此状态也需要决定SRIS_Mode_Enabled的值，如果LinkUp为0且任意一条lane收到的连续2个TS1OS中，SRIS Clokcing为1，则需要设置SRIS_Mode_Enabled为1。其他行为跟DSP一样，略过。

Configuration.Complete状态跳转图

Configuration.Complete状态跳转

DSP Configuration.Complete状态跳转图

正常跳转是从Configuration.Complete跳转到Configuration.Idle,不超时进入就需要所有lane都收到lane number跟该条lane发送出去一致，且link number不为PAD，还要symbol 4也一样，相当于是在确认信息。

2ms超时后，还跟变量Idle_to_rlock_transitioned有关，该变量用用于表征从Configuration.Idle或者Recovery.Idle往Configuration跳转的次数，为gen3新增，跳转一次就加1，直到255，由于是gen3新增，所以gen1/2的时候，只要跳转一次，该值就直接加到255。

如果当场速度是2.5GT/s或者5.0GT/s，直接跳转到Detect，如果当前速度是8.0GT/s,变量Idle_to_rlock_transitioned小于255，则还允许继续尝试link number和lane number的协商，先跳转到Configuration.Idle，在从Configuration.Idle跳转到Configuration.Linkwidth.Start。

2ms超时后，不满足进入Configuration.Idle的条件就会进入Detect，比如8.0GT/s下，Idle_to_rlock_transitioned为255或者2.5GT/s，所有lane收到link number和lane number都是PAD的TS1OS。

USP Configuration.Complete状态跳转图

USP跳转条件同DSP,略过。

Configuration.Idle

Configuration.Idle时的行为

Configuration.Idle状态跳转

Configuration.Idle状态跳转

一些例子

linkwidth change发起的场景：

感谢@Alen的整理

PCie5：short方式降lane

VIP在L0阶段重新配置target_link_width， direct_link_width_change变量，VIP先进Recovery后，DUT被动进入Recovery。然后经过Recovery.RcvrLock ->Recovery.RcvrCfg -> Recovery.Idle ->Configuration.Linkwidth.Start（direct_link_width_change使进入configuration） ，随后在Configuration.Lanenum.Wait状态，对unactive的lane上发pad pad的TS1OS，来重新协商链路宽度。

PCie5：链路数据传输错误方式，从Recovery.Config跳转Configuration降lane。当DUT在Recovery.RcvrCfg状态，vip注错，发送不匹配link number/lane number的TS，进入Configuration状态，然后发送pad pad的TS1，使对端也跳转至Configuration。

PCIE6：Flit mode ，只允许在发生错误的情况下降lane

VIP发起：在L0阶段，或Recovery阶段，VIP的rx端收到了接收错误，VIP将在Recovery.RcvrCfg状态，对这些lane发送link number和lane number都是PAD的TS1，来声明降lane操作(相当于之前在Configutation阶段才会发的link number和lane number都为PAD的TS1OS提前发了，可能是为了兼容Gen6 1b/1b编码模式下，Recovery状态中TS1/2没有lanenum的标识符。故不能检查”不匹配的lanenum”这一条件。)对端在该状态收到link number和lane number为PAD的TS2OS后，从Recovery.RcvrCfg状态 -> Configuration.Linkwidth.Start，重新进行链路宽度的训练(只能降lane)。 （疑问：VIP自己是如何完成recovery.config状态 -> configuration.linkwidth.start的？）

DUT发起:同理，dut的rx端的某些lane，在接收到不预期的错误的时，将在Recovery.RcvrCfg状态，对主动在这些lane上发送link number和lane number都为PAD的TS1，来声明降lane操作。

例2 EP发起降lane的操作

EP x2降低到 x1

如有任何问题，欢饮共同探讨
PCIePL记录
暂无评论

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																					

							
							
						

										
					
											
						

	

		
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
（╯‵□′）╯︵┴─┴
￣﹃￣
(/ω＼)
∠( ᐛ 」∠)＿
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ｀)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ(￣∇￣o)
ヾ(´･ ･｀｡)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò｡)
Σ(っ °Д °;)っ
( ,,´･ω･)ﾉ"(´っω･｀｡)
╮(╯▽╰)╭
o(*////▽////*)q
＞﹏＜
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
	

	

		
颜文字
Emoji
小恐龙
花!
	


									

			

			
			
		

	






上一篇
下一篇