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

8370 字
|
37 分钟

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想要进入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。

正常是期望能收到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.Linkwidht.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时的行为

  • 非 PAD 的 lane# 必须从 0 到 n-1 连续编号， 分配给接收到相同 link# 的 lane， 没有接收到 TS1OS 的 Downstream lanes 不得打断可以形成最宽 link 的序列， 剩下的 lane 必须传输 link# 和 lane# 都是 PAD 的 TS1OS.
  • note : spec 建议当 link 中的某些 lane 接受了错误的 TS1OS 或者 128b/130b 编码下丢失块锁定 (Block Alignment)， 对跳转到 Configuration.Linkwidth.Accept 的条件做更多评估， 以免过早的配置了链路宽度造成可能比实际的小. 当使用 8b/10b 编码时， 多检查 2 个或者更多的 TS1OS， 当 使用 128b/130b 编码时， 多检查 34 个或者更多的 TS1OS， 但是不能超过 1 ms
  • 如果下列所有条件都满足， 则将变量 use_modified_TS1_TS2_Ordered_Set 设为 1
    • LinkUp = 0b
    • 从进入 Polling 状态以来， 在 Polling 和 Configuration 状态传输的 TS1OS 和 TS2OS 中， Symbol 5 bit[7:6] (Enhanced Link Behavior Control ) 为 11b (支持 Modified TS1/TS2 Ordered Set)
    • 从 Polling.Configuration 状态跳转到 Configuration 状态时， 目前配置的 link 上所有 lane 都收到 8 个连续的 TS2OS， 其中 Symbol 5 bit[7:6] (Enhanced Link Behavior Configuration) 为 11b (支持 Modified TS1/TS2 Ordered Set)， 且 Symbol 4 bit[5] (支持 32.0 GT/s)要为 1b

USP Configuration.Lanenum.Wait时的行为

  • 如果， 则选择一个 link#， 在所有检测到接收机和接收到 2 个连续 TS1OS 的所有 lane 上发射 TS1OS， 其中 link# 为选定的一个， lane# 为 PAD， 剩下在 Detect 状态检测到接收机的 lane (可能不能接收到 2 个连续的 TS)发送 link# 和 lane# 都是 PAD 的 TS1OS
  • 如果此状态是从 Recovery 状态跳转而来， 并且不是由于 LTSSM 超时跳转， 如果发射机打算自动改变链路宽度， 在 Configuration 状态， 发射机必须设置 TS1OS 中的 Autonomous Change(Symbol 4 bit[6]) 为 1b
  • TS1OS 中的速度标识符(Symbol 4)是 port 支持的所有速度， 包括它不打算适用的
  • note : spec 建议当 link 中的某些 lane 接受了错误的 TS1OS 或者 128b/130b 编码下丢失块锁定 (Block Alignment)， 对跳转到 Configuration.Linkwidth.Accept 的条件做更多评估， 以免过早的配置了链路宽度造成可能比实际的小. 当使用 8b/10b 编码时， 多检查 2 个或者更多的 TS1OS， 当 使用 128b/130b 编码时， 多检查 34 个或者更多的 TS1OS， 但是不能超过 1 ms.
  • 激活任何 inactive lane 之后， 发射机在退出 Electrical Idle 后， 必须等到 TX 共模电压稳定后才可以发送 TS1OS
  • 可选， 如果 LinkUp 为 0 并且支持可选的 crosslinks 模式， 所有在 Detect 状态检测到接收机的 Upstream lane 首先要发送 16 – 32个 TS1OS， 其中 link# 和 lane# 都是 PAD. 在发送完之后， 如果任意一条 Upstream lane 首先收到 2 个连续的 TS1OS， 且 link# 和 lane# 为 PAD， 那么:
    • 发射机会持续发送 link# 和 lane# 都是 PAD 的 TS1OS
    • 如果任何 lane 收到 2 个连续的 TS1OS， 其中 link# 不同与 PAD， lane# 为 PAD， 在检测到接收机并且也接收到 2 个连续的 TS1OS 的所有 lane 发送特定 link# 和 lane# 为 PAD 的 TS1OS. 剩下在 Detect 状态检测到接收机的 lane 发送 link# 和 lane# 都是 PAD 的 TS1OS

Configuration.Lanenum.Wait状态跳转图

Configuration状态跳转

Configuration.Lanenum.Accept

DSP Configuration.Lanenum.Accept时的行为

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

USP Configuration.Lanenum.Accept时的行为

Configuration.Lanenum.Accept状态跳转图

Configuration.Lanenum.Accept状态跳转

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

Configuration.Complete状态跳转图

Configuration.Complete状态跳转

USP Configuration.Complete时的行为

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操作。

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

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																					

							
							
						

										
					
											
						

	

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

	

		
颜文字
Emoji
小恐龙
花!
	


									

			

			
			
		

	






上一篇
下一篇